A Reservation Scheme for WiMedia MAC Protocol by cuv18981

VIEWS: 41 PAGES: 22

									    A Reservation Scheme for WiMedia
             MAC Protocol
               (Wireless Network Report)




         Maryam Daneshi & Kazem Jahanbakhsh
                      April 2008




                          1
Contents:
1- Introduction to Ultra-Wideband (UWB)
     1-1- UWB Applications

     1-2- Problems of IEEE 802.15.3

     1-3- WIMEDIA MAC Protocol

     1-4- Superframe Structure



2- Distributed Reservation Protocol (DRP)
     2-1- SuperFrame Structure for DRP Allocation

     2-2- MAC Layer Rules

     2-3- Proposed Approach for Resource Reservation



3- Performance Evaluation
     3-1- Simulation Parameters

     3-2- Running Scenarios

     3-3- Performance Metrics

     3-4- Performance Results



4- Future Works




                                        2
1- Introduction
Ultra-wideband (UWB) is a radio technology that can be used at very low energy levels for
short-range high-bandwidth communications by using a larger portion of the radio spectrum.
UWB is used for transmitting information spread over a large bandwidth (>500 MHz). A
significant difference between traditional radio transmissions and UWB radio transmissions is
that traditional systems transmit information by varying the power level, frequency, and/or phase
of a sinusoidal wave. UWB transmissions transmit information by generating radio energy at
specific time instants and occupying large bandwidth thus enabling a pulse-position or time-
modulation. [1]

UWB devices are expected to operate at rates of up to 0.5 Gb/s and communicate with other
devices at a range of up to 10 m, thus enabling high-speed wireless personal area Networks
(WPANs). UWB devices are allowed to operate in an unlicensed manner in the 3–10 GHz band,
with low permitted transmission power. Due to the low transmit power, UWB devices do not
cause harmful interference, and therefore coexist with other users in the same band.


1-1- UWB Applications

The salient features of UWB networks — high-rate communications, low interference with other
radio systems, and low power consumption — bring many benefits to users, thus enabling
several new applications. The first application of UWB is likely to be wireless universal serial
bus (WUSB) for connecting personal computers (PCs) to their peripherals. The second
application for UWB will likely be in the consumer electronics (CE) sphere in people’s living
rooms. For instance, UWB will connect televisions to audio-visual CE components such as DVD
players and speakers.


1-2- Problems of IEEE 802.15.3

Originally, it was expected that WiMedia would define a new UWB PHY for the already existing
IEEE 802.15.3 MAC for WPANs. However, the current IEEE 802.15.3 MAC specification has
several drawbacks and does not provide good support for the application requirements mentioned
above. One of its main disadvantages is its centralized architecture. The IEEE 802.15.3 MAC
works with a central controller. Devices are associated with the central controller forming what
is known as a piconet. The central controller is called the piconet coordinator (PNC). The PNC is
elected dynamically; any device, portable or not, may become the PNC. Communications
between devices can only be carried out through the PNC. This causes several problems when
trying to support peer-to-peer (P2P) mobile applications. For example, if the PNC controller
disappears, either switched off manually by the user, due to mobility, or because of a device
failure, it may require several seconds before the rest of the devices reorganize and elect a new

                                               3
PNC. Even though communicating peer devices may still be functioning and within close
proximity, communication cannot be maintained during reorganization due to the lack of a PNC.
This would imply, for example, disruption of multimedia streams.


1-3- WIMEDIA MAC Protocol

The WiMedia MAC architecture is completely distributed. It does not require a central controller
for operation. All devices perform equivalent functionality. This is essential to support the
mobile P2P or ad-hoc paradigm envisioned for the UWB applications. The problems described
above for the IEEE 802.15.3 MAC protocol, which are related to the mobility and availability of
the PNC, are no longer relevant.
As in other MAC protocols, medium time is divided into superframes, which describe periodic
intervals used to coordinate operation between devices. A superframe is divided into two parts: a
beacon period (BP) followed by a data transfer period (DTP).
Management and control information is exchanged in the form of beacon frames that are
transmitted during the BP. As a unique property of this MAC, all devices need to transmit a
beacon for resource allocation by using a slotted channel access protocol during the beacon
period. The transmission of beacons is the most fundamental and important mechanism of the
MAC. The BP provides the framework that guarantees orderly access to the wireless medium.
The BP allows for synchronization, mobility of devices, and fast device discovery. It includes
information to provide efficient support for power management and reservation of bandwidth. In
addition, it addresses the hidden node problem of the IEEE 802.11 and 802.15.3 protocols, and
permits spatial medium reuse. This will become clearer as we describe the different mechanisms
below. Data frames are transmitted during the DTP. The MAC provides asynchronous and
isochronous data communication services. The isochronous service is supported by the
Distributed Reservation Protocol (DRP), which allows bandwidth reservation to be handled in a
fully distributed manner. The asynchronous service is provided by a prioritized carrier sense
multiple access with collision avoidance (CSMA/CA) protocol called Prioritized Channel Access
(PCA).

1-4- Superframe structure

The superframe is a periodic interval of time with duration of 65.536 ms. The superframe is
divided into slots; in total there are 256 medium access slots (MASs), where each MAS duration
is 256 μs. Each superframe starts with a BP. The start of the first MAS in the BP, and the
superframe, is the BPST. The remaining MASs in the superframe are used for data transmission
using DRP or PCA.

The BP is divided into beacon slots of 85 μs. Each device chooses a beacon slot for transmission
of its beacon frame. Information included in a beacon frame is coded as information elements

                                               4
(IEs). Different IEs are defined for different functions. The Distributed Reservation Protocol
(DRP) IE includes information regarding a reservation of the superframe time in units of MAS;




                               Figure 1:  The WiMedia MAC superframe 




                                                 5
2- Distributed Reservation Protocol (DRP)

DRP is used by devices to negotiate and reserve bandwidth. A reservation, defined by a subset of
MASs during the superframe, guarantees a period of time for transmission during which the
reservation owner has exclusive access to the medium. A reservation may be used, for example,
to provide isochronous services for a particular streaming application. A device that wishes to
establish a reservation negotiates the channel time with its communication peer. There is no need
for a central entity that controls the reservation process. Admission to the medium using DRP is
granted in a first-in first-served (FIFS) manner; that is, a device can only establish a reservation
during the MASs that are not being used by another existing reservations. In a distributed
network, the resources must be available in both the transmitter and receiver beacon groups. A
limit on the maximum number of MASs that a device can reserve is imposed by policies defined
above the MAC. An example of reserved time during the superframe is shown in Fig. 2. The
negotiation process starts with the transmitter sending a reservation request to the receiver. The
request includes the set of MASs that the transmitter intends to reserve for transmission. The
request can be sent in the beacon in the form of a DRP IE or via special command frames
transmitted using DRP or PCA. Upon reception of the request, the receiver analyzes the channel
time utilization of its beacon group and responds, using one of the access methods mentioned,
indicating whether the reservation request is accepted. If the reservation cannot be accepted, the
receiver can provide additional information to the transmitter, such as a bitmap of the available
MASs in its beacon group. Once a reservation is successfully negotiated, the reservation is
announced in the beacons via the DRP IEs. Other devices become aware of the reservation by
reception of the beacons, and therefore defer access to the medium during the reserved MASs.[2]

2-1- SuperFrame Structure for DRP Allocation

According to UWB MAC layer standard [3] DRP allocation uses zone structure. The superframe
is split into 16 zones numbered from 0 to 15 starting from the BPST. Each zone contains 16
consecutive MASs, which are numbered from 0 to 15 within the zone. The zone Bitmap field
identifies the zones that contain reserved MASs. Figure 2 shows a Zone structure of a superframe




                                                 6
                                                                                               
                              Figure 2‐IsoZone structure in two‐dimensional view 

 
Whenever a device has traffic to send to a destination, during the beacon-period, the reservation
owner will send a request to the reservation target specifying its traffic characteristics.
The reservation target will try to fit in the request in to the superframe matrix. If it is possible it
will grant the resources to the reservation owner. After this request/grant procedure, the sender
can send traffic in the specified MASs with defined rate to the destination.

According to UWB Mac standard, [3] a reservation consists of a row component and a column
component.

Row component: A portion of a reservation that includes an equal number of MASs at the same
offset(s) within every zone, optionally excluding zone zero, as indicated in the DRP IEs.
Column component: The portion of the reservation that is not a row component.

Rules defined in standard apply independently to a device whether it is a reservation owner or a
reservation target. A device may consider contiguous reservation blocks from multiple column
components in the same zone as if they were a single reservation block in a single column
component. Also device shall not allocate more channel time than necessary for its optimal
operation. The reservation policies can be found on section [4].



                                                      7
2-2- MAC Layer Rules

    (1) In the row component of a reservation, the reservation owner shall select reservation
        blocks such that the lowest MAS number selected within a zone is maximized, except
        that the reservation owner is not required to use more than one reservation block per
        zone.
    (2) In the column component of a reservation, the reservation owner shall select reservation
        blocks that meet its requirements such that each block is located within the first eight
        MASs of its zone, if possible. If not possible, the reservation owner shall select
        reservation owner shall select reservation blocks that meet its requirements and that
        minimize the highest MAS number selected in any zone.
    (3) If multiple potential zone locations meet the previous requirements, the reservation owner
        shall select reservation blocks in zones such that the latest used set in the following
        ordered list of sets is as early as possible:
                [{8}, {4 or 12}, {2, 6, 10 or 14}, {1, 3, 5, 7, 9, 11, 13 or 15}]

    (4) If there are multiple possible zone locations that use the same latest set, the reservation
        owner should minimize the highest MAS number selected within the zones. The
        reservation owner shall place each reservation block at the earliest available location
        within its zone.

                                   Table 1‐ Reservation Block Size limit 




                                                    8
2-3- Proposed Approach for Resource Reservation

We got our main idea from the Wimedia logical link control protocol [4]. In annex B of this
protocol, they have proposed the guidelines for using TSPEC (traffic specification) for SIMA
(service interval-based MAS allocation)

Making a reservation of network resources using the DRP requires determining the number of
Medium Access Slots (MASs) and the locations of the MASs within the superframe. The number
of MASs per superframe depends on many factors such as traffic source bandwidth
characteristics, PHY transmission data rate, link condition and/or transmission distance, MSDU
sizes, and acknowledgement type. The location of the MASs within the superframe depends on
the total number of MASs, the service interval or latency requirement, traffic source burstiness,
etc. In addition, both the total number and the locations of MASs are constrained by MAC
reservation policies



The following main data structures have been used for reservation scheme:
Output: Allocation matrix of size 16
Input: Traffic TSPEC for request with the following parameters:

R: Mean data rate
P: Peak data rate
B: Maximum burst size
Ds: Delay bound: ds <= dq + SI
TTL: life time of current request




                                               9
Figure 4 illustrates the detail of finite state machine (FSM) for the proposed reservation protocol.




                                    Figure 3: FSM of Reservation Protocol 



The details of the FSM are provided in the following paragraph:

(1)
Initially simulation is in Init state and it transits to State 0 when simulation starts. The Clock
variable will be set to zero and all of the simulation parameters will be initialized.

(2)
By arriving new request we should do pre allocation steps and then transit to State 1.
Event: Arrival
Action: Pre_Allocation_TRY_1

When a new request arrives the following actions should be performed:


                                                     10
a. First of all we will deallocate all MAS locations whose corresponding requests are going to
leave.
b. Update utilization variable based on the last departure.
c. Set i (reservation bandwidth index) and j (block size index) to zero. Then calculate gmin and
gmax (lower and upper bound of reservation bandwidth) by using the following formulas:
                p
 g min =                (dq is set to its maximum value)
                  p−r
         1+ dq *
                   b
g max = p (when dq is set to zero)
                                  g + g max                                 g * 256
d. Calculate g i by using g i = min            formula and mi =                                for
                                        2                       physical _ bitrate * MAC _ OH
the number of slots.
e. Start from isozone 0 and find the first free MAS location in the allocation matrix.
f. Use Table 1 to find the reservation block size limit (y) for the first MAS location we have
already found in step e.
g. b j = y (block size) & k j = mi / b j (number of required blocks).
h. Schedule the next arrival and go to State 1.

(3)
In State 1, we are going to search if there are k j columns with b j free MASs.
Event: Found_m_Free_Slots
Action: Pre_Allocation_TRY_2

If there is kj columns with bj free MASs we can go to State 2 and at the same time we should
allocate mi MASs for the incoming request temporarily.

(4)
In State 2, we are going to see if delay bound is satisfied or not.
Event: Delay_Bound_Condition_Satisfied
Action: Pre_Allocation_TRY_3

a. If dq + SI < ds (which means the delay boundary for the requested traffic is satisfied),
allocates the reserved MASs permanently in allocation Matrix for the current request.
b. Schedule the departure for this request (Tdepart = Tarrival + TTL)
c. Dequeue the next arrival from the event list table.
d. Update Rejection Rate variable.




                                                  11
(5)
In State 1, if we did not find the required number of MASs, we would not change our state.
Event: Not_Found_m_Free_Slots
Action: Find_Next_Free_MAS_Location

If there are not kj columns with bj free MASs and we have not scanned the whole of the
allocation matrix, it means that we should move and look at the next free block space in
allocation matrix. And we should perform the following actions as well:
a. j++ (increase block size index)
b. Find the next free MAS location in Allocation Matrix.
c. Use Table 1 to find the reservation block size limit (y) for the next MAS location we have
already found in step b.
d. b j = y (block size) & k j = mi / b j (number of required blocks).
In this situation, we don not need to change the state.

(6)
In State 2, if the delay bound is not satisfied, we should return to State 1 again for searching new
free space in allocation matrix.
Event: Delay_Bound_Condition_Not_Satisfied
Action: Find_Next_Free_MAS_Location

If dq + SI > ds, it means that we can not satisfy the delay constraint and we should return to State
1 and doing the following actions:
a. j++ (increase block size index)
b. Find the next free MAS location in Allocation Matrix.
c. Use Table 1 to find the reservation block size limit (y) for the next MAS location we have
already found in step b.
d. b j = y (block size) & k j = mi / b j (number of required blocks).
In this situation, we don not need to change the state.

(7)
If we searched the entire allocation matrix with the mi value, but we could not find any space
that satisfies our requirements, then we need to change the original g i value to a new value and
go to State 1.
Event: Reserved_BW_Change_Satisfied && Scenario_1
Action: Change_g_up:




                                                 12
If the entire of allocation matrix has been searched for mi value without any success and if the
first scenario is possible (it means that based on the allocation matrix we have decided to
increase the reserved bandwidth) and if g is also less than gmax, then do the following actions:
a. Set index j to zero and g old = g i and increase index i.
              g max − g old
b. g i = g old +
                    2
                     g * 256
c. mi =
        physical _ bitrate * MAC _ OH
d. Start from isozone 0 and find the first free MAS location in allocation matrix.
e. Use Table 1 to find the reservation block size limit (y) for the first MAS location we have
already found in step d.
f. b j = y (block size) & k j = mi / b j (number of required blocks).


(8)
If we searched the entire allocation matrix with the mi value, but we can not find any space that
satisfies our requirements, then we need to change the original gi value to a new value and then
go to State 1.
Event: Reserved_BW_Change_Satisfied && Scenario_2
Action: Change_g_down:

If the entire of allocation matrix has been searched for mi value without any success and if the
second scenario is possible (it means that based on the allocation matrix we have decided to
decrease the reserved bandwidth) and if g is also greater than gmin, then do the following
actions:
a. Set index j to zero and increase index i.
         gi + g min
b. g i =
             2
                      g * 256
c. mi =
         physical _ bitrate * MAC _ OH
d. Start from isozone 0 and find the first free MAS location in allocation matrix.
e. Use Table 1 to find the reservation block size limit (y) for the first MAS location we have
already found in step d.
f. b j = y (block size) & k j = mi / b j (number of required blocks).


(9)
If we have already tried all of the possible g values without any success, it means that there is not
any possible solution for this request and we have to reject the request and move to State 0.
Event: Reservation_Failed

                                                 13
Action: Reject_Request

The following actions should be performed:
a. Update rejection rate variable.
b. Dequeue the next arrival from the event list table.


3- Performance Evaluation

In this project, Matlab software has been used as simulator to analyse the performance of the
proposed allocation mechanism. The most important goal at the first step for this project was to
simplify the original NP-hard allocation problem in order that make it possible to simulate the
allocation scheme in a finite time. The very simple queuing model has been used for the arrival
and departure times of the requests. It was assumed that the requests come based on a Poisson
arrival (exponential inter-arrival time) and every request use the system resources (here MASs)
for a duration time which follows exponential distribution as well. Moreover, a standard set of
parameters have been used to characterize the traffic sources. A token bucket has been used to
characterize traffic sources, based on which networking resources can be reserved for
parameterized QoS provisioning. The token bucket TSPEC is a quintuple of mean data rate (r),
peak data rate (p), maximum burst size (b), maximum packet size (M) and minimum policed unit
( m p ). The fluid twin token bucket model provides standard terminology for describing the
behavior of a network traffic source. As shown in Figure 4 [4], the model has three parameters,
mean rate r, peak rate p and maximum burst size b. A token bucket injects data into the network
only if there is an equivalent amount of tokens available and when a packet is transmitted, it
consumes and removes exactly the same number of tokens.




                                  Figure 4: Fluid twin token bucket model 




                                                    14
3-1- Simulation Parameters

The following parameters have been used for modeling the source traffics:

                                        Table 2‐ TSPEC parameters 

                          Parameter                     Distribution     Mean Value

                       Mean Data Rate (r)               Uniform [2, 6]     4.0 Mbps

                       Peak Data Rate (p)            Uniform [14, 16]     15.0 Mbps

                     Maximum Burst Size (b)                   -          131350 octets

                    Maximum packet size (M)                   -           1490 octets

                       Nominal packet size                    -           1427 octets

                           Delay (ds)                Uniform [60, 70]       65 ms




Base on the twin token bucket model, the minimum service rate g necessary to guarantee delay
bound d for a traffic specification with characteristics of {r,b,p} is given by:
          p
 g=                                                                                  (1)
             p−r
    1+ dq *
               b
The lower bound of reservation bandwidth g min can be achieved when choosing interval SI close
to 4ms, which leaves d q = d s − 4ms = 65 − 4 = 61ms . Therefore, the minimum reservation
bandwidth required is:
                   15
g min =                         = 9.2Mbps                                               (2)
                      15 − 4
        1 + 0.061 *
                    0.13135 * 8
The upper bound can be calculated when the queuing delay ( d q ) is relaxed to zero as the
following:
 g max = p = 15Mbps                                                                   (3)
Based on the proposed scheme for reservation the first try for reservation bandwidth will be
calculated as below:
       g + g max 15 + 9.2
 g = min          =         = 12.1Mbps                                                (4)
           2          2
Based on the MAC frame overhead, the number of required MASs for this bandwidth should be
                                 g * 256               12.1Mbps * 256
roughly about m =                                   =                    = 48MASs where
                    physical _ bit _ rate * MAC _ OH 106.7 Mbps * 0.6



                                                   15
 physical _ bit _ rate = 106.7 Mbps . Therefore, at the same time the maximum number of users
who can be services should be less than the following value:
     240
 n=       = 5users                                                                        (5)
      48
The calculation of maximum number of users which simultaneously can be serviced is based on
the average TSPEC’s values according to Table 2. This maximum number should be considered
to setup the arrival rate and service rate. In other words, according to Little’s Law the following
inequality should be satisfied at the same time:

    1
    μ           Service _ Time
        =                          <= n = 5                                               (6)
    1
    λ       Inter _ Arrival _ Time

3-2- Running Scenarios

The main focus on this project is on the reservation scheme and to identify the different issues
that we have to look at them to propose an efficient reservation scheme.
    1- At the first scenario, according to inequality (6) the Service_Time is fixed to 300 seconds
       and the Inter_Arrival_Time is changed from one minute to 16 minutes.
    2- For the second scenario, according to inequality (6) the Inter_Arrival_Time is fixed to
       240 seconds and the Service_Time is changed from 4 minutes to 21 minutes.


3-3- Performance Metrics

a. System Utilization

Definition: the proportion of time that a server is busy. Observed server utilization, ρ , is defined
                                                                                       ˆ
over a specified time interval [0,T]. Long-run server utilization is ρ . For systems with long-run
stability: ρ → ρ as T → ∞ .
           ˆ




                                              Figure 5: Server Utilization 


                                                          16
As per the above picture, the system utilization is:

                              No _ of _ Allocated _ MAS
    Ti (total _ busy _ time) *
                                           240                 ∞ T * ρi
 ρ=
 ˆ                                                        = ∑i =1 i                      (7)
                        T (Total _ Time)                            T
The system utilization is estimation for how much the reservation scheme works efficiently. In
ideal case, the desired value for this performance metric is one.

b. Reject Percentage

When a new traffic request comes into system, the resource allocation algorithm tries to find a
proper place (MAS locations) in the allocation matrix to meet the requested QoS. If it can not
find the MAS locations for the requested TSPEC, it means that MAC will reject this new traffic.
Therefore, the following formula is used for calculation of rejection percentage formula:

                           No _ of _ Re jected _ Re quests
Re jection _ Percentage =                                                                  (8)
                               Total _ No _ Re quests
The rejection percentage shows how many requests are rejected, and in the ideal case it should
be zero.

c. Reservation Bandwidth Overhead

Based on Token bucket model for QoS provisioning, the reserved bandwidth is
          p
g=                  and the bandwidth overhead should be calculated as follow:
            p−r
    1+ dq *
             b
            g − g min
BW _ OH =                                                                          (9)
              g min

In the ideal case the bandwidth overhead should be close to zero as much as possible.




                                                 17
3-4- Performance Results

This section includes all of the performance results. We ran the simulation for different scenarios
by using different seeds. Moreover, for each scenario we ran the simulation three times and then
took the average of those results for measuring the performance metric values. The MAC
utilization is an important metric that shows how much the proposed scheme can utilize the
resources. In our simulation the physical data rate is set to 106.7 Mbps. Figure 6 shows the
system utilization for different inter arrival time changing from 1 minute to 16 minutes (for a
fixed TTL = 5 minutes). The tendency of the plot shows that by increasing the inter arrival time
(reducing the traffic rate), we will have less utilization. The maximum achieved utilization is
around 0.5 because our reservation protocol has missed some opportunities for reservation based
on our simplifications. For example, if the first try for g does not work, we could try other
bandwidth rates based on the state of allocation matrix. Moreover, because the requested MAS
slots are in the order of 40 to 50, the probability that the last user (the fifth user) can not allocate
successfully is high. One solution to have more granularities is to increase the physical bit rates,
but reducing the number of MASs with a solid requirement for SI and the MAC rules can not be
achieved at the same time. This issue shows itself as an optimization problem that can help us to
improve the efficiency of reservation scheme.



                                                 MAC Utilization (TTL = 5 min)

                          0.5


                          0.4
            Utilization




                          0.3


                          0.2


                          0.1


                           0
                                0   2        4        6         8        10          12   14       16   18
                                                          Inter-Arrival Time (min)
                                                                                                              
                                    Figure 6: Utilization of MAC Reservation Protocol (TTL=5minutes) 




Similarly, the rejection rate is shown in Fig 5 by changing inter arrival time from 1 minute to 16
minutes (for a fixed TTL = 5 minutes). The tendency of this curve is also matches the queuing
theory principles because by increasing the traffic rate the dropping probability is increasing.




                                                                    18
                                                                         Rejection Rate (TTL = 5 min)

                          0.5


                          0.4
         Rejection Rate




                          0.3


                          0.2


                          0.1


                            0
                                         0              2           4           6          8           10        12        14        16        18
                                                                                    Inter-Arrival Time (min)
                                                                                                                                                     
                                                                                                

                                                                        Figure 7: Rejection Rate (TTL = 5 minutes) 



The reservation bandwidth overhead for our reservation is shown in Fig 8. In ideal case we want
this metric to be as low as possible (to be close to g min ).


                                                             Reservation Bandwidth Overhead (TTL = 5 min)

                                         0.148
                                         0.146
                                         0.144
                                         0.142
                           BW-Overhead




                                             0.14
                                         0.138
                                         0.136
                                         0.134
                                         0.132
                                             0.13
                                         0.128
                                                    0           2           4          6           8        10        12        14        16
                                                                                      Arrival Rate (minutes)
                                                                                                                                                
                                                            Figure 8:  Reservation Bandwidth Overhead (TTL = 5 minutes) 




                                                                                           19
For the second scenario, we tried to change the service time from 4 minutes to 21 minutes and at
the same time the inter arrival time is set to 4 minutes. The corresponding figures for MAC
utilization, rejection rate and bandwidth overhead are shown in Fig 9, 10 and 11.


                                                       MAC Utilization (Inter-Arrival Time = 4 min)

                              0.6


                              0.5


                              0.4
           Utilization




                              0.3


                              0.2


                              0.1


                                     0
                                         0                5                10                15               20               25
                                                                                TTL (min)


                                         Figure 9: Utilization of MAC Reservation Protocol (Inter_Arrival_Time = 4minutes) 




                                                    Rejection Percentage (Inter-Arrival Time = 4 min)

                                     0.5


                                     0.4
                    Rejection Rate




                                     0.3


                                     0.2


                                     0.1


                                         0
                                             0             5               10               15               20               25
                                                                                TTL (min)


                                                    Figure 10: Rejection Rate (Inter_Arrival_Time = 4minutes) 




                                                                                20
                                 Reservation Bandwidth Overhead (Inter-Arrival Time = 4 min)

                         0.148

                         0.146

                         0.144
           BW-Overhead




                         0.142

                          0.14

                         0.138

                         0.136

                         0.134

                         0.132
                                 0               5               10               15             20           25
                                                                      TTL (min)


                                 Figure 11: Reservation Bandwidth Overhead (Inter_Arrival_Time = 4minutes) 




4- Future Works


For this project the main focus was on how to find the number of required MASs and their
locations in the superframe to meet the TSPEC requirements. For doing this we have assumed
that all of the requests arrive the base node and that node is responsible for running the allocation
algorithm. For the next step we are going to propose the distributed form of this reservation
scheme by exchanging some types of hello messages between nodes to make sure that all of the
nodes have the same and a real time view of the current superframe.
Currently, we only try one average g for reservation bandwidth, and if the first try does not work,
we do not change the reserved bandwidth. As a result, this causes us to have more rejection rate
and at the same time less utilization. As a future work we can modify our current scheme to try
different values for g. In other words, if the first g (the average of maximum and minimum
reservation bandwidth) does not work, two approaches can be taken based on the current state of
allocation matrix. As the first approach we can decrease the g (reservation bandwidth) to get a
smaller value for m (number of required MAS slots) and increasing the chance of allocation. The
side effect of this issue is that at the same time by decreasing g we will have more dq (queuing
delay); as a result, we will need less SI (service interval time) which will show itself as a
constraint to us. For the second approach we can increase the g which means less chance for
allocation, but this time the SI can be relaxed and will not show itself as a constraint. We need


                                                                      21
some type of decision making to be able to find the best approach when a new traffic arrives.
This decision making should be based on the state of allocation matrix. We should define a
function that returns some weight for the efficiency of two approaches and then based on the
provided weight we will be able to choose one of the two approaches.



Reference:
[1] http://en.wikipedia.org/wiki/Ultra-wideband

[2] J. Pavón, “The MBOA-WiMedia Specification for Ultra Wideband Distributed Networks”,
Standard Report, IEEE Communications Magazine, June 2006
[3]Standard ECMA-368, “High Rate Ultra Wideband PHY and MAC Standard”, 2nd edition,
December 2007
[4] Wimedia Alliance, “Wimedia logical link control protocol”, WLP Specification, August 2007




                                               22

								
To top