T HESIS O RGANIZATION

The rest of the thesis is organized as follows: we will introduce the MAC functionality of 802.15.3 in Chapter 2. In Chapter 3, we will point out QoS problems of transmitting rt-VBR applications and discuss the drawbacks of some previous works. Our simulation model and the selection of parameters are addressed in Chapter 4. Simulation results and discussions are concluded in Chapter 5. Finally, conclusions are described in Chapter 6.

Chapter 2

Overview of IEEE 802.15.3 MAC Protocol

IEEE Std 802.15.3 was designed to enable wireless connectivity of high-speed, low-power, low-cost, multimedia-capable portable consumer electronic devices. This standard provides data rates from 11 to 55 Mb/s at distances within 10m while maintaining quality of service (QoS) for the data streams. In addition, this standard is designed to provide simple, ad-hoc connectivity that allows the devices to automatically form networks and exchange information without the direct intervention of the user. In this chapter, we will introduce the 802.15.3 MAC functionality and the standard channel time management.

2.1 The 802.15.3 piconet and its components

802.15.3 is based on a centralized and connection-oriented ad-hoc networking topology. This wireless ad hoc data communications system which allows a number of independent data devices (DEVs) to communicate with each other is called piconet. A piconet is distinguished from other types of data networks because communications are normally confined to a small area around person or object that typically covers at least 10m in all directions and envelops the person or a thing whether stationary or in motion. This is in contrast to local area network (LAN), metropolitan area network (MAN), and wide area network (WAN), each of which covers a successively larger

geographic area, such as a single building or a campus or that would interconnect facilities in different parts of a country or of the world.

An 802.15.3 piconet consists of several components, as shown in Figure 2-1. The basic component is the DEV. One DEV is required to assume the role of the piconet coordinator of the piconet (PNC). The PNC provides the basic timing for the piconet with the beacon. Additionally, the PNC manages the quality of service requirements, power save modes and access control to the piconet.

beac on

beacon data

Figure. 2- 1: Network Topology of 802.15.3

The 802.15.3 standard allows a DEV to request the formation of a subsidiary piconet. The original piconet is referred to as the parent piconet. The subsidiary piconet is referred to as either a child or neighbor piconet, depending on the method the DEV used to associate with the parent PNC. Child and neighbor piconets are also

referred to as dependent piconets since they rely on the parent PNC to allocate channel time for the operation of the dependent piconet. An independent piconet is a piconet that does not have any dependent piconets.

2.2 The 802.15.3 Superframe Structure

2.2.1 Basic Components

Timing in the 802.15.3 piconet is based on the superframe, which is illustrated in

Figure 2-2. The superframe is composed of three parts:

— The beacon, which is used to set the timing allocations and to communicate

management information for the piconet.

— The contention access period (CAP), which is used to communicate commands

and/or asynchronous data if it is present in the superframe.

— The channel time allocation period (CTAP), which is composed of channel time

allocations (CTAs), including management CTAs (MCTAs). CTAs are used for commands, isochronous streams and asynchronous data connections.

Figure. 2- 2: Superframe Structure of 802.15.3

The length of the CAP is determined by the PNC and communicated to the DEVs in the piconet via the beacon. The basic medium access mechanism during the CAP is carrier sense multiple access with collision avoidance (CSMA/CA). To minimize collisions, a transmitting DEV is required to first sense whether the medium is idle for a random length of time, called “backoff interframe space” (BIFS). Only if the medium is idle after BIFS shall the DEV start its transmission. This process of waiting before transmission is termed “backoff.” The backoff count is randomly selected from range [0,BW], where BW means backoff window chosen from the value set of [7, 15, 31, 63]. For the first transmission attempt of a frame, the BW value is set to the minimum number 7. If collision occurs, the BW value should be increased to the next larger value until reaching the maximum value 63. The DEV shall maintain a counter for backoff count which is decremented only when the medium is idle. Whenever the channel is busy, the backoff counter shall be suspended.

The channel shall be determined to be idle for the duration of a BIFS period before the backoff slot countdown is resumed. When the backoff counter reaches zero, the DEV may transmit a frame.

On the other hand, channel access in the CTAP is based on a TDMA method.

The PNC divides the CTAP into channel time allocations (CTAs). A DEV with assigned directed CTA is guaranteed that no other DEVs will compete for the channel

during the indicated time duration of the CTA. A DEV with a CTA may or may not make use of all the allocated time duration within the CTA. The selection of a stream, command or asynchronous data for the transmission during the CTA is determined locally by the DEV depending on the number of pending frames and their priorities.

All CTAs have guaranteed transmission time slots.

2.2.2 Static Superframe Structure

Superframe structure in 802.15.3 network can be static or dynamic. In the case of static superframe formation, the PNC uses a constant superframe length. In other words, the beacons are broadcast periodically.

Figure. 2- 3: Static Superframe Structure

2.2.3 Dynamic Superframe Structure

To relieve the problem of static superframe structure, the 802.15.3 allows changing the length of the superframe gradually. Whenever the PNC wants to change the size of the superframe, it needs to attach the changing information in the beacon

and broadcast to the DEVs in its piconet. After an advertising period, the PNC can change superframe to the new length. Figure. 2-4 illustrates the gradual superframe sizing, where L1 and L2 represent the superframe length before changing and after changing relatively.

Figure. 2- 4: Gradual Superframe Structure

As we will discuss later, the reason why superframe length can be changed only after this advertising interval is the presence of pseudo-static channel time allocations, as described in 2.3.1. Because the pseudo-static CTA needed to be placed in the fixed location in the superframe, changing superframe length arbitrarily may lead to CTA location arrangement error.

2.3 Channel Time Management

All data in the 802.15.3 piconet is exchanged in a peer-to-peer manner. In this section, we will introduce the two major types of channel time management:

isochronous stream management and asynchronous channel time reservation.

2.3.1 Isochronous stream management

If the DEV needs channel time on a regular basis, it makes a request from the PNC for an isochronous channel time. If the resources are available, the PNC allocates a CTA time for the DEV. Figure. 2-3 illustrate the flows of successfully establishing a DEV-A to DEV-B stream in a piconet. The channel time request command should contain the desired number of TUs, the length of used TU, and the

frequency that PNC should assign the CTA. In the figure, the Imm-ACK means the

“Immediate Acknowledgement” policy, which provides an ACK process that each

frame is individually ACKed following the reception of each frame. If the requirements for the data change, then the DEV is able to request a change to the allocation. The source DEV, destination DEV, or the PNC can decide to terminate the stream.

Figure. 2- 5: Isochronous Channel Time Request Procedure

The DEV requests for amount of channel time for transmission and the PNC calculates whether the remaining resource called “Time Unit” (TU) is available. The TU represents the time length of the transmission time of a fragmentation frame, including ACKs. The DEV needs to inform PNC the TU length and the number of TU that are required for this transmission when sending the channel request command.

According to the information, PNC can check whether the unallocated TUs in the superframe are sufficient to support the request. If the unallocated TUs are not enough, the channel time request will be dropped. Figure. 2-4 shows an example of the channel time being requested for a CTA while Imm-ACKs are used. Here the SIFS means short interframe space, which is the duration that the destination DEV shall wait before starting transmitting the Imm-ACK frame after the end of each transmission.

Figure. 2- 6: Time Unit with Imm-Ack Policy

For regular CTAs, the PNC is able to change their position within the superframe.

The CTA which its location can be moved within the superframe on a superframe by superframe basis is called dynamic CTA. This allows the PNC has the flexibility to rearrange CTA assignments in order to optimize the utilization of the assignments.

The PNC moves a dynamic CTA by simply changing the CTA parameters in the beacon. Dynamic CTAs may be used for both asynchronous and isochronous streams.

If a DEV misses a beacon, it is unable to use the allocation for a regular CTA. To avoid lost throughput due to missed beacons, DEVs are allowed to request a special type of CTA called pseudo-static CTA. Unlike dynamic CTAs, pseudo-static CTAs have fixed location in the superframe. If the DEV is allocated a pseudo-static CTA, it is allowed to use the CTA for up to mMaxLost-Beacons missed beacons. The PNC can move the locations of these CTAs only after maintaining the CTA time for the old allocation for mMaxLost-Beacons superframes. Pseudo-static CTAs shall be allocated only for isochronous streams.

Figure. 2- 7: Dynamic CTA & Pseudo-static CTA

As we mentioned before, although the existence of pseudo-static CTA reduces the negative influence of throughput from missing beacons, it also brings the inconvenience to the dynamic superframe formation described in section 2.2.3. Since the PNC must reserve pseudo-static CTA for up to mMaxLost-Beacons, the PNC cannot change the superframe length before finishing assigning the pseudo-static CTA.

2.3.2 Asynchronous channel time reservation

Asynchronous allocation is slightly different from isochronous stream. Rather than requesting recurring channel time, an asynchronous channel time request is a request for a total amount of time to transfer its data. The PNC then schedules the channel time for this request if the resource is available. If the DEV needs to transmit another asynchronous data frame, it has to send a new request again. What merits attention is that there is no absolute guarantee of the length of the delay between the time of the request and the reception of a beacon containing the requested CTA. If the DEV does not get its requested CTA in the beacon until the data frame’s time out interval expires, transmission time out occurs and this frame will be dumped. Unlike an isochronous allocation, only the source DEV or PNC are allowed to terminate an asynchronous allocation. Figure. 2-6 shows an example of successfully reserving the

channel time for the exchange of asynchronous data between DEV-A and DEV-B in a piconet.

Figure. 2- 8: Asynchronous Channel Time Request Procedure

Chapter 3

QoS Issue and Related Works

We will have the discussion on the QoS topics in this chapter. Section 3.1 is a brief introduction to the QoS. Some related works and the QoS problems that the 802.15.3 standard do not addressed is described in the section 3.2.

3.1 Introduction to QoS

The QoS is a concept which is general but difficult to make comprehensive explanation. The statement which is apt to let people understand is “Quality of Service, which is the performance specification of a communication channel or system which customers judge transmission by qualifiers.” It is a general term that incorporates bandwidth, latency, and jitter to describe a network's ability to customize the treatment of specific classes of data.” Most existing researches provided to ensure the QoS requirements can be divided into two classifications: service differentiation and resource management. The main concept of the service differentiation is to adjust the probability of obtaining the medium to transmit via assigning different traffic with different priorities. The policy of assigning the priority is on the basis of the following criteria: customer payment, traffic types, traffic demand, etc. Note that the priority does not provide any QoS guarantee actually. It only guarantees that the traffic with higher priority can acquire the resource more easily than the lower priority traffics.

There are many studies for resource management. Among them, the most are focusing on call admission control and bandwidth allocation schemes. The purpose of call admission control is to decide whether to accept or reject the new coming users according to different criteria. If accept the new user will cause intolerable negative influence to the current serving applications, the new user should be rejected. On the other hand, bandwidth reservation control mechanisms take the responsibility of how to reserve enough bandwidth or resource to an accepted traffic.

3.2 QoS Problem in 802.15.3 Standard

3.2.1 Issue in Superframe Structure

As mentioned in 2.2.2 and 2.2.3, we can categorize the superframe formation method to static structure and dynamic structure. Static superframe structure adopts fixed superframe length; therefore it is easy for CBR flow to synchronize its packet generation with superframes. As shown in the Figure. 3-X, the disadvantage of the static structure is the appearance of the wasted time slots. If the DEV has data transmission requirement after the duration of the current CTA, it cannot exploit the unallocated slots and need to wait for its CTA in the next superframe. Thus the channel utilizing capability of static structure is poor.

Figure. 3- 1 Drawback of Static Superframe Structure

Dynamic superframe structure can change the superframe length to adapt to the network load, trying to achieve better channel utilization. However, the superframe length can be changed only after an advertising period. The length of advertising period is decided according to the current superframe lenght and might be relatively long in some cases. Thus, the reaction of the superframe sizing to network load fluctuation is not instantaneous. In addition, when the size of the superframe changes, the CTA of the constant bit rate (CBR) flows need to adjust its length and location to keep the constant-bit-rate characteristics. Nevertheless, adjusting the CTA to achieve good bandwidth efficiency and low delay at the same time is difficult. As in [13]

shows, the delay variation (or jitter) of CBR flow in the dynamic superframe structure is 12% higher than the CBR flow in static superframe structure.

3.2.2 Issue in Channel Time Management

As we mentioned in section 2.3.1 and 2.3.2, 802.15.3 specifies two types of channel time management. What we want to discuss here is that which type of channel time management is suitable for the real time variable bit rate (rt-VBR) traffic.

If we choose the isochronous stream method, since the PNC can allocate the CTA regularly according to the DEV’s reqeust without sending channel-time request command for each transmission, the timing restrictions can get better assurance.

However, as we illustrate in the Figure. 3-1, the isochronous channel time management cannot adapt to the various output of VBR applications. This is because unlike Wireless LAN or Wireless ATM networks, all data in the 802.15.3 piconet is exchanged in a peer-to-peer manner. The PNC has only the responsibility of network and resource management, without packet forwarding functionality. Therefore once after the PNC receives the channel request from the DEV and allocates the CTA with response command, the PNC has no information about the DEV’s current status. From the MPEG-4 traffic trace study in [17], we can find that the video frame size changes dramatically with frame index.

It can be seen obviously that fixed amount of channel time is allocated every superframe, but the DEV generates variable sizes of frame sequences. It should be noticed that if the time required sending an entire frame is longer than the allocated CTA, the remaining segments of the frame should be transmitted in the next superframe. It causes a transfer delay and may deteriorate the video quality. If the DEV wants to request more bandwidth to transmit or has lower traffic than prior request to send, it has to send channel request again to ask for bandwidth adjustment.

However there is no absolute guarantee of the length delay between the time of the request and the reception of a beacon containing the requested CTA. Thus the PNC’s response time to the request may still threaten the QoS of delay-sensitive traffic and result in poor bandwidth utilization. Even if the PNC grants the requirement, it usually brings another problem: the DEV may occupy excessive bandwidth (as shown in Figure. 3-1) and prevent other DEVs from requesting more channel time.

Allocated CTALength

Figure. 3- 2: Isochronous channel time management with rt-VBR traffic

As for asynchronous channel time management, because DEV need to send channel time request every time before starting transmitting, the PNC can distribute just appropriate length CTA according the request. Therefore, the adaptation to the variable data size is better than the isochronous stream method. As we illustrate in the Figure. 3-2, because there is no guarantee of the delay between the time of the request and the reception of the beacon containing the requested CTA, if the data frame’s deadline expires while waiting for its requested CTA, transmission time out occurs and this frame will be dumped. Hence the asynchronous channel time management is

not suitable for delay sensitive traffic.

Figure. 3- 3: Asynchronous channel time management with rt-VBR traffic From the above discussion, we can conclude that either isochronous stream or asynchronous channel time management has its drawbacks and both of them can not assure the QoS of rt-VBR applications.

3.3 Related Works

As today, only a few researches have made their efforts to solve the problem mentioned above. The author of [8] proposed a simple application-aware MAC scheme for the 802.15.3 in order to achieve a high quality VBR video transmission of MPEG-4 stream. The main idea is let DEV informs PNC the maximum sizes of its I-frame, P-frame, and B-frame in the channel time requests before each creation of the isochronous stream and the PNC allocates a channel time for the DEV according to the predefined frame sequence. For example, if the size of Group of Pictures (GOP) is 12, and its typical structure is IBBPBBPBBPBB, the total time required to transmit an I-frame is given by:

[ ( ) ] ( 1) ( )

n

MAX

MAX

TxTime(I ) TxTime one fragmented frame size SIFS ACK n

TxTime I SIFS ACK B-frames in bytes, and computes the amount of time to send those entire frames using the above equation. Three different amounts of time, which are required to transmit the entire IMAX, PMAX, BMAX frames are determined by the DEV, and the PNC allows dynamic sizes of CTA based on the GOP structure.

In fact, there are two difficulties to realize this scheme. First, it is extremely hard to identify the maximum sizes of each of the frame type before the MPEG transmissions. Besides, since the PNC always allocate the maximum length CTA in

In fact, there are two difficulties to realize this scheme. First, it is extremely hard to identify the maximum sizes of each of the frame type before the MPEG transmissions. Besides, since the PNC always allocate the maximum length CTA in