針對 IEEE 802.15.3 個人無線區域網路系統之動態時間分配與回饋式控制排程方法

全文

(1)國立交通大學電子工程學系碩士論文. 針對 IEEE 802.15.3 個人無線區域網路系統之動態通道時間分配與回饋式排程控制方法. Dynamic Channel Time Reservation with Feedback Control Scheduling in IEEE 802.15.3. 研究生：李宜鍵指導教授：黃經堯. 博士. 蔣迪豪. 博士. 中華民國九十四年八月.

(2) 針對 IEEE 802.15.3 個人無線區域網路系統之動態通道時間分配與回饋式排程控制方法 Dynamic Channel Time Reservation with Feedback Control Scheduling in IEEE 802.15.3. 研究生: 李宜鍵指導教授: 黃經堯蔣迪豪. Student: Yi-Chien Lee Advisors：Ching-Yao Huang Ti-hao Chiang. 國立交通大學電子工程學系碩士論文 A Thesis Submitted to Department of Electronics Engineering & Institute of Electronics College of Electrical Engineering and Computer Science National Chiao Tung University in partial Fulfillment of the Requirements for the Degree of Master of Science in Electronics Engineering. August 2005. HsinChu, Taiwan, Republic of China. 中華民國九十四年八月.

(3) 針對 IEEE 802.15.3 個人無線區域網路系統之動態通道時間分配與回饋式排程控制方法. 學生：李宜鍵. 指導教授:黃經堯博士蔣迪豪博士. 國立交通大學電子工程學系電子研究所碩士班. 摘要為了達到短距離、高品質的影像/聲頻無線傳輸，由 IEEE 802.15.3 組織所訂立的超寬頻無線個人區域網路標準近年來十分受到矚目。此系統可以提供 11 至 55 Mbps 的傳輸速率，並且採用了基於分時多重接取技術的媒體接取控制協議。然而，因為缺少針對即時性可變動位元率服務所設計的通道時間分配機制，此系統對於該類型的資料傳輸支援性並不佳。此篇論文提出一個搭配回饋控制排程的動態通道時間分配策略，來試著解決這個窘境。我們建立了一模擬平台來評估此策略與原有系統在不同延遲限制下的表現，而模擬結果亦驗證所提出的方法可以大幅降低資料遺失的比率與傳輸延遲，同時得到較高的系統效能。. i.

(4) Dynamic Channel Time Reservation with Feedback Control Scheduling in IEEE 802.15.3. Student : Yi-Chien Lee. Advisor : Dr. Ching-Yao Huang. Department of Electronics Engineering Institute of Electronics National Chiao Tung University. Abstract. The Ultra Wide Band (UWB) standard, developed by IEEE 802.15.3 task group, is one of the popular candidates to achieve high quality video/audio wireless transmission within short range connection. Based on Time Division Multiple Access (TDMA), the data rates of 802.15.3 are ranged from 11 to 55Mbps. However, due to the lack of effective mechanism to reserve proper channel time for real time variable bit rate (rt-VBR) applications, the system cannot guarantee the quality of service (QoS). In this thesis, we propose a feedback control based dynamic channel time reservation scheme to achieve the QoS requirements for rt-VBR applications. A simulation platform is established to evaluate the performance of proposed and standard scheme under different QoS requirements. The simulation results show that with higher data throughput, the proposed method can still reduce the packet loss rate and delay significantly.. ii.

(5) 誌. 謝. 首先，我要感謝指導教授黃經堯老師，老師開明的態度和諄諄教誨，使我這兩年研究生涯受益良多，並能在充滿朝氣的環境下致力於研究，在此致上最深的謝意。感謝羅文嶽和蘇慧源學長在研究期間不斷給予我指引與建議，並且提供許多寶貴的經驗，使我的實驗能順利完成。同時感謝同實驗室的彥翔、雲懷、正達、建銘、裕隆、勇嵐，有了他們的幫忙與砥礪，使得研究過程不再枯燥乏味，而能以愉快心情面對。也要謝謝邱大瑜同學在技術上的協助，使研究能夠更加完整。最後，更是要感謝我的父母，感謝他們對我從小到大的栽培和養育，給予我在生活上的關心，在我情緒低潮時開導我，讓我全心完成學業；他們帶給了我最大的動力，也才能完成我的碩士論文，謝謝！. iii.

(6) Contents. CHAPTER 1 INTRODUCTION........................................................................ 1 1.1. INTRODUCTION ........................................................................................1. 1.2. THESIS ORGANIZATION ............................................................................3. CHAPTER 2 OVERVIEW OF IEEE 802.15.3 MAC PROTOCOL ................... 4 2.1. THE 802.15.3 PICONET AND ITS COMPONENTS ...........................................4. 2.2. THE 802.15.3 SUPERFRAME STRUCTURE ..................................................6. 2.3. 2.2.1. Basic Components .......................................................................6. 2.2.2. Static Superframe Structure.........................................................8. 2.2.3. Dynamic Superframe Structure ....................................................8. CHANNEL TIME MANAGEMENT ................................................................9 2.3.1. Isochronous stream management...............................................10. 2.3.2. Asynchronous channel time reservation .....................................13. CHAPTER 3 QOS ISSUE AND RELATED WORKS .................................... 15 3.1. INTRODUCTION TO QOS .........................................................................15. 3.2. QOS PROBLEM IN 802.15.3 STANDARD...................................................16 3.2.1. Issue in Superframe Structure....................................................16. 3.2.2. Issue in Channel Time Management ..........................................17. iv.

(7) 3.3. RELATED WORKS ....................................................................................20. CHAPTER 4 PROPOSED CHANNEL ALLOCATION SCHEME AND SCHEDULING ALGORITHM........................................................................ 24 4.1. DESIGN CONCEPTS .................................................................................24. 4.2. PROPOSED SOLUTION .............................................................................26. CHAPTER 5 SIMULATION RESULTS ......................................................... 34 5.1. SIMULATION MODEL..............................................................................34. 5.2. PERFORMANCE METRICS AND RESULTS DISCUSSION ..............................37 5.2.1 Performance Metrics........................................................................37 5.2.2 Simulation Results............................................................................38. CHAPTER 6 CONCLUSION......................................................................... 47 REFERENCE ................................................................................................ 48. v.

(8) List of Figures Figure. 2- 1: Network Topology of 802.15.3...............................................................5 Figure. 2- 2: Superframe Structure of 802.15.3...........................................................6 Figure. 2- 3: Static Superframe Structure....................................................................8 Figure. 2- 4: Gradual Superframe Structure ................................................................9 Figure. 2- 5: Isochronous Channel Time Request Procedure.....................................10 Figure. 2- 6: Time Unit with Imm-Ack Policy ..........................................................11 Figure. 2- 7: Dynamic CTA & Pseudo-static CTA ....................................................12 Figure. 2- 8: Asynchronous Channel Time Request Procedure..................................14 Figure. 3- 1 Drawback of Static Superframe Structure..............................................17 Figure. 3- 2: Isochronous channel time management with rt-VBR traffic..................19 Figure. 3- 3: Asynchronous channel time management with rt-VBR traffic ..............20 Figure. 4- 1: Proposed New Superframe Structure....................................................28 Figure. 4- 2: Flow chart of the proposed algorithm ...................................................33 Figure. 5- 1: Simulation Model.................................................................................34 Figure. 5- 2: Packet Loss Rate Comparison of Proposed Scheme and Asynchronous 39 Figure. 5- 3: Packet Loss Rate Comparison of Proposed Scheme and Isochronous ...40 Figure. 5- 4: Transmission Delay Comparison of Proposed Scheme and Asynchronous .........................................................................................................................42 Figure. 5- 5: Transfer Delay Comparison of Proposed Scheme and Isochronous.......42 Figure. 5- 6: Jitter Comparison of Proposed Scheme and Asynchronous...................43 Figure. 5- 7: Jitter Comparison of Proposed Scheme and Isochronous ......................43 Figure. 5- 8: Throughput Comparison of Proposed Scheme and Asynchronous.........45 Figure. 5- 9: Throughput Comparison of Proposed Scheme and Isochronous............46 Figure. 5- 10: Channel Utilization Comparison ........................................................46. vi.

(9) Chapter 1 Introduction 1.1 Introduction Recently, the demand on Personal Area Networks (PAN) has led to a new and specialized wireless standard. Bluetooth is the first WPAN technology. However, due to its low transmission rates, the capability to support burst data or real-time multimedia traffic is limited [1]. The requirements of high quality video/audio distribution and high data transmission have pushed for a new standard, such as 802.15.3 [2]. IEEE 802.15.3 is designed to provide high transmission rates and low power consuming solution for multimedia applications. It supports five PHY modes ranging from 11Mbps up to 55 Mbps. Recently, 802.15 task group 3a has considered an alternative PHY to achieve 480Mbps [3][4][5]. IEEE 802.15.3 is based on a centralized and connection oriented ad-hoc networking topology, with a master-slave hierarchy.. The. MAC. layer. employs. a. hybrid. (contention-based. and. non-contention-based) protocol, where superframe structure is composed of command transmission part and data transmission part. For command transmission, 802.15.3 uses a contention-based protocol, while for data transmission it uses time division multiple access (TDMA) based time slot allocations.. 1.

(10) The standard defines two kinds of superframe structure and two kinds of channel time allocation scheme: static and dynamic structure, isochronous and asynchronous data management, respectively. Once the superframe structure is chosen, we can allocate time slots to each user according to the channel time allocation scheme selected by the user. The drawback of the static structure is its poor channel utilization capability while the dynamic structure has the disadvantage in constant-bit-rate (CBR) treatment. In addition, as we discussed in the later chapter, both the channel time allocation scheme provided in the 802.15.3 standard cannot support real-time variable-bit-rate (rt-VBR) application well. This is because 802.15.3 MAC adopts a request-response scheme for changing the amount of the channel time reserved for data transmission. Thus the response time is not as short as that of 802.11e and may threaten the QoS of delay-sensitive traffic [6]. Several researches have paid attention to enhance or modify the existing MAC mechanism to solve this problem. [8] allocates the maximum channel time requirement for each frame transmission, while [9] inserts a single byte in the header to represent the user’s queue status. As we will discuss later, these methods have the drawbacks like wasting resources, trouble in estimating of maximum data size or out-of-date information. To resolve the above problems, two approaches are considered: 1. Enhance the channel utilizing capability of static superframe structure 2. Provide a fast and. 2.

(11) accurate method to help the system adjusts the amount of channel time according to the VBR traffic demands. As a result, how to estimate the requirement and provide QoS assurance are important for the decision. A feedback control algorithm is proposed to solve the problem.. 1.2 Thesis Organization 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.. 3.

(12) 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 4.

(13) 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.. be ac. on. be. ac. da. ta. on. 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. 5.

(14) 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. 6.

(15) 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. 7.

(16) 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 8.

(17) 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.. 9.

(18) 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 10.

(19) 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.. 11.

(20) 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. 12.

(21) 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. 13.

(22) 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. 14.

(23) 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.. 15.

(24) 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.. 16.

(25) 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.. 17.

(26) 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.. 18.

(27) 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 CTA Length 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 19.

(28) 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:. 20.

(29) TxTime(I MAX ) = [TxTime(one fragmented frame size) + SIFS + ACK ] × (n − 1) + TxTime( I MAX n ) + SIFS + ACK Where the function TxTime(x) represents the transmission time required to send a frame of size x, IMAX is the maximum sizes in bytes of I-frame, and n means that the I-frame is fragmented into n partition. The transmission time required to send an entire PMAX or BMAX frame can be calculated in the same way. Before requesting the channel time, a source DEV finds the maximum sizes of its I-frames, P-frames, and 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 every superframe, resources may be occupied excessively. However increasing bandwidth beyond what is needed does not give any QoS increase but simply waste resources. If one application requires more channel time that it actually needs, it would then prevent other applications from accessing the network [7]. Consequently, it is important to find the right trade-off between user satisfaction and network efficiency. The second difficulty is that this method can only works well when setting 21.

(30) the superframe length equals to the frame inter-arrival time. In the real situation, it is unreasonable to regulate superframe length forcibly to a solid value. If there are MPEG streams with different frame inter-arrival time needed to be sent in the piconet, the control scheme will be insufficient to support the QoS. [9] proposes a scheme that adds a single byte to the MAC header such that a source DEV can inform the PNC of its current queue size. Thus with every packet exchange, the PNC is ware of the instantaneous channel requirements of each flow, which may be temporarily more than the reserved bandwidth. Using the transient load information, the PNC can dynamically allocate the idle bandwidth of lowly-loaded nodes to the overloaded flows so that the system performance can be increased. Short Remaining Processing Time (SRPT) packet scheduling is adopted in this research to minimize the service response time. We can also enumerate two shortcomings of this algorithm. First, in order to prevent the queue size information from out of date, the paper assumes that the PNC can change the superframe length instantaneously to adapt to the network load. As we will discuss in the section 4.1, this assumption does not fit in with practical circumstances. When the PNC wishes to change its superframe duration, it shall insert this message into the beacon and broadcast for a certain amount of time. The superframe can only be changed after this interval. Consequently, the information of queue status PNC received is possibly overdue and. 22.

(31) error appears in the resource management. Second, because the overhead occur with every data exchange, if the fragmentation size is chosen small or the transmitting frame is large, the overhead would increase rapidly and waste the resource. [10] implements the IEEE 802.15.3 MAC in ns-2 simulator and investigates the impact of some operating parameters on the performance of real-time and best-effort traffic. In addition, it also present results concerning the fairness of the MAC’s contention channel access scheme under heavy load and the overheads of various ACK policies. [11] proposes a scheduling method called Maximum Traffic scheduling for 802.15.3. By calculating the relative position of all DEVs in the piconet [12], the PNC can divide DEVs into different independent transmit-receive pairs. It claims this method guarantees that total transmission data is maximum at any point of time and needed time slots for transmission is minimum.. 23.

(32) Chapter 4 Proposed channel allocation scheme and scheduling algorithm In this chapter, a new channel allocation scheme is proposed to eliminate the drawbacks of the standard channel allocation scheme mentioned in the previous chapter.. 4.1 Design Concepts Here we summarize the problem of transmitting rt-VBR traffic in IEEE 802.15.3: Both of the standard allocation schemes have their shortcomings in transmitting rt-VBR traffic. If isochronous stream management is adopted, the PNC can only allocate a fixed amount of channel time to the corresponding DEV after accessing the channel time request. If the data frame needs more channel time and there still have enough unallocated time slots in the superframe, the DEV needs to send a modify request to PNC to acquire proper channel time. However, the flow which requests larger CTA earlier may occupy excessive bandwidth and prevent other flows from requesting more channel time. On the other hand, if the asynchronous scheme is used, the consuming request-response procedure may cause intolerable delay to threaten the QoS of time-sensitive applications. The general way to overcome the problem is let the DEVs send back their. 24.

(33) current status to the PNC. Then, PNC can allocate enough channel time and arrange them in proper location according to this information. For most prior works [9][13][14][18], this sending back action is achieved by piggybacking method. In other words, the DEV’s buffer length or packet inter arrival rate information is attached to the MAC header. By exchanging every data, the information can be acquired by the PNC continuously. Unfortunately, this method has following problems: Ø. Overhead: Because the MAC header is transmitted with each fragmentation frame, this method would bring many excessive overhead when the packet size is large or the fragmentation size is chosen small. In order to reduce the overhead, the common way is to compress or encode this information.. Ø. Information Inconsistency: When the DEV complete its transmission in the given CTA in the current superframe, the information exchange will be terminated. If packets arrive after the given CTA duration, the actually buffer status in the DEVs may have inconsistency with the information received by PNC.. Ø. Limited application scope: The piggybacking method is only valid when transmission occurs between PNC and DEV. However, in most cases, transmissions are established between two DEVs, not including the PNC.. 25.

(34) For these situations, PNC still cannot obtain the information about DEV through piggybacking. To summarize, buffer status information has to be compressed, may get lost and is often partly outdated [15]. This is an important concern, especially for the variable bit rate traffic with stringent delay requirement. Since this type of traffic requires tracking of the instantaneous rate variation to estimate the channel time requirement in the next superframe. In order to avoid the flaw mentioned above, there should be a better method different from piggybacking to let the PNC obtain the precise information of DEV’s buffer status. Another related design topic is to choose a proper superframe structure. The disadvantage of static superframe structure is the low channel utilization capability while the flaw of the dynamic structure is the improper treatment to CBR flows. If we can modify the static superframe structure to utilize the wasted resources, better bandwidth efficiency can be achieved and the CBR traffic can be treated properly.. 4.2 Proposed Solution For reasons mentioned above, we choose the static superframe structure in our algorithm, and use the way follows to avoid its drawbacks: whenever there is unused channel time existing in the superframe, we let the DEV contends to access the. 26.

(35) medium if it has data frame to transmit. What we need to do is simply adding some information in the beacon and broadcast to DEVs in the piconet to let them know they can contend the wireless medium from the end of the last allocation CTA to the end of the superframe. Here comes the new problem: when the network loading increase, it is possible that some DEVs cannot obtain the transmission opportunity because of the keen contention. In this situation, it is important to guarantee these DEVs have enough channel time and higher priority in the next superframe. Otherwise, QoS of the timely-strict application might be threatened. We can solve this problem through the feedback control channel time allocation mechanism describes in the following paragraph. Instead of embedding the information in the MAC header, we reserve a small amount of channel time called TFB at the end of the superframe. Every active DEV should send back its buffer status information to the PNC in this reserved channel time interval. In other words, PNC can poll every active DEV at the end of current superframe and use this information to schedule and allocate proper channel time in the next superframe for each DEV. Since we collect the information at the end of the superframe, right before the new beacon of the next superframe, we can say that the information is up to date. Figure. 4-1 shows the new superframe structure we proposed here.. 27.

(36) Figure. 4- 1: Proposed New Superframe Structure. In order to guarantee the QoS of the application with stringent delay requirement, it is better that besides the channel time requirement, we should also send back some other information to help PNC schedule the location of the CTA. In real time scheduling theory, it has already proven that Earliest Deadline First (EDF) is optimal for most real time traffic [16]. For above reasons, we choose the below three parameters, Safter, Drelative, and TUreq in our reserved channel time to send back to PNC. Ø. Safter : This parameter represents the deadline of the first packet in the buffer in units of superframes.. Ø. Drelative : This parameter represents the relative deadline position of the packets whose deadlines fall in the same superframe (i.e. these packets have 28.

(37) same Safter value). Ø. TUreq : This parameters represents the number of TUs required in the next CTA.. The parameters are calculated by the following formula: D  S after =  f   Ls  Drelative =. TU req. D f − S after × Ls Ls 255.  ∑ Si   = i  f   . -. Df : deadline of the first packet in the buffer. -. Ls : the length of superframe. -. Pi : the data size of packet i. -. f : fragmentation frame size used in the transmission ( 512 ≦ f ≦ 2048 bytes). The deadline of the packet is calculated using the following formula: Di = Gi + DB − Ti Where Di means the deadline of packet i, Gi is the generating time of this packet i, DB means the delay bound and Ti is the required transmission time to finish the transmission packet i. The DEV should transmit its packet after less than Safter superframes. Otherwise, the packet will exceed its deadline and will be dropped. When PNC receives the Safter 29.

(38) parameter, it knows that DEVs with smaller Safter have comparatively urgent transmission demand. Thus these DEVs will have higher priority than the DEVs which have larger Safter. To further distinguish the priorities of the transmission order from the DEVs with the same Safter value, we use the second parameter, Drelative. The DEV with smaller Drelative represents that the deadline of its packet will be reached earlier than the larger Drelative ones. Therefore, after sorting the DEV transmission order with parameter Safter, PNC can further sort the transmission order of the DEVs which have the same Safter value by the parameter Drelative. The reason why the denominator term superframe length, Ls, divided by 255 is that we want to compress data size of the deadline information of each DEV to less than 1 byte. The 802.15.3 system uses micro-second as the time unit resolution. Hence if we take the deadline value directly without compressing, the overhead it caused is intolerable. The third parameter is Time Unit Requirement (TUreq). As we mentioned before, standard channel time allocation scheme can only distribute fixed amount of time and thus cannot adapt to the various output of variable bit rate traffic. For this reason, we make the DEV transmit the TUreq parameter to tell the PNC how many TUs needed to be reserved for this DEV.. 30.

(39) The length of one Time Unit is calculated as follows:. TU Length = Preamble + PHY header + MAC _ header + Header Check Sequence + 2 × SIFS + ACK +. Fragmentation Frame Size Channel Bit Rate. Different DEVs may use different time unit length depending on the fragmentation frame size it adopts. Now we consider the overhead introduced by the extra reserved channel time and compare with the piggybacking method. Since the value of Safter is usually small, we can stuff the Safter information into the MAC_Header’s 11th bit to 15th bit. These bits are not used originally in the standard and are reserved to exploit by ourselves. Therefore, the Safter parameter will not bring any overhead. As to the Drelative and TUreq, each of them has 1 byte data size. We assume that we transmit these parameters at the channel bit rate 22 Mb/s, the same as the transmission rate of MAC_Header. The time needed to finish transmitting 2 bytes at 22 Mb/s is about 0.72μs, which is considerably small compare to the total superframe length (is usually set at 30 to 40 ms). Since we do not design a call admission control algorithm to suit our design, we must take the following situation into consideration: when the number of flows increase, it is possible that the total resource is not enough to satisfy every DEV’s requirement. In order to let the PNC keep tracking of DEV’s status, we make the reserved channel time TFB has higher priority than the normal channel time allocation. 31.

(40) In other words, the PNC first reserves TFB and then distribute the remaining unallocated TUs to the active DEVs according the scheduling method mentioned before. If the remaining unallocated TUs are not enough, those DEVs which cannot be distributed enough channel time as requirement TUreq can only give up the transmission this time and send back its current status in TFB. Because we schedule the channel time allocations with Safter, the DEVs which do not transmit successfully in the current superframe will have smaller Safter value and could be served first in the next superframe. Figure. 4-2 illustrates a sketchy flow path of our algorithm.. 32.

(41) Figure. 4- 2: Flow chart of the proposed algorithm. 33.

(42) Chapter 5 Simulation Results This chapter describes the simulation results in order to examine the performance of the algorithm presented above. First, we introduce the simulation model and the simulation parameters. Then the performance metrics and achieved results are described.. 5.1 Simulation Model. Beaco n. Be a con. Figure. 5- 1: Simulation Model. 34.

(43) Figure. 5-1 shows the simulation model we applied. To evaluate the performance of the rt-VBR application in our simulation experiment, we use the MPEG-4 traffic generator which is built referring to the [17]. Six videos are encoded in QCIF format and have 25 frames per second. Traffic generator will choose one video randomly and put the encoded packet into the buffer. The CTA control block contains the function that what time the CTA belongs to this DEV should begin and finish, so that the DEV can transmit in the given duration without interfering with other DEV’s transmission. The CAP control block contains the function of back off procedure and knows the start and end time of contention access period. This allows device transmitting data by contending the medium when it is not in its allocated CTA. The feedback control block is responsible for calculating the Safter, Drelative and TUreq parameters according to the packets in the buffer. It also takes charge of the start and end time of TFB. To focus on the performance of the access mechanism only, the wireless channel is assumed to be ideal in that there is no distortion, noise, or other interference for data transmission. Once receiving a data from the channel, the decoder will identify which type of data it is. If it is a beacon, the decoder will send the timing information to CTA control, CAP control and feedback control blocks. If it is a traffic data, it will be de-fragmented and put into the receiving data buffer. If it is the send back information and receiver is PNC, this information will be sent to the CTA management block to. 35.

(44) help PNC allocate and schedule the CTA. Note that the CTA management, information buffer and beacon generator blocks are only essential in the DEV which is capable to be a PNC. To further verify our system, we design our simulation model on the platform proposed in [19]. By transforming each functional block to the finite state machine, the simulation model can be created according to some translation rules. Based on our study, the simulation efficiency is superior to the simple simulator without the platform. With integrating the ARMulator instruction set simulator, the software codes on the platform can be compiled with ARM instructions and verified with other hardware models. System parameters used in the simulation are listed in Table 1. The simulation is run for 200 seconds and repeated 200 times for each point, which turns out to be long enough to ensure the accurate simulation results. Table 1 Simulation Parameters. Value. Channel Bit Rate. 55 Mbps. Superframe Length. 40ms. Delay Bound. 40/80/120ms. Packet Inter Arrival Time. 40ms. Max bit rate of rt-VBR. 4.4 Mbps. Mean bit rate of rt-VBR. 1.17 Mbps 8.6 μs. Initial Preamble. 0.73 / 3.6 μs. PHY header / MAC header Header Check Sequence. 0.73 μs. Fragmentation frame size. 1024 bytes. SIFS/BIFS. 10/17.3 μs 36.

(45) 5.2 Performance Metrics and Results Discussion 5.2.1 Performance Metrics The focus of the current study is to understand the extent to which the proposed protocol guarantees the real-time constraint of rt-VBR traffic. To this end, we change the delay bound of the packet between 40/80/120 msec and observe the success rate of packet transmission with/without our algorithm. Because the standard does not specify how to schedule the CTA, the first come first serve method is considered in the standard CTA allocation scheme simulation. In addition, we assume that the nodes do not move during the simulation. The performance metrics used in our simulation are defined as follows: n. Packet Loss Ratio: The packet loss ratio is defined as the number of packets dropped per total number of packets. Since we assume the channel is error free, the packet loss only occurs when the packet expire its delay bound.. n. Packet Transfer Delay: The packet transfer delay is defined as the time between the packet generation and its transmission completion. Dropped packets are not taken into account when calculating the delay.. n. Jitter: Jitter is defined as the standard deviation of the packet transfer delay. If the MPEG application is not interactive one, jitter may be a more critical issue than packet transfer delay, as the receiving DEV can buffer the MPEG. 37.

(46) frames and playbacks them with a fixed amount of delay[8]. n. Channel Utilization: Channel utilization is defined as the average time length used for transmission per total length of a superframe.. n. Throughput: Throughput is defined as the total amount of packet size that can be successfully transmitted per second.. 5.2.2 Simulation Results The effect of the feedback control dynamic channel time allocation can be clearly verified in Figure. 5-2 and Figure. 5-3. In the figures of this chapter, we denote the standard asynchronous allocation and the standard fixed length CTA scheme for an isochronous traffic as Async and Isoch. We can find in the figure that the packet loss rate of the isochronous scheme increases rapidly when the number of the traffic flow exceeds 20. This is because the flows which request more bandwidth first may obstruct the channel-time modify request of the flows which have slower data size variation. Thus these flows cannot obtain enough channel time and packet loss occurs continuously. As for the asynchronous scheme, when the delay bound is chosen small, the packet loss rate becomes awful because DEV needs to send request before acquiring the medium. If the PNC cannot allocate CTA in time, packet drop occurs. We can see that when we set the delay bound at 120ms, the restriction to the request-response time is relieved and hence packet loss rate reduced. On the other. 38.

(47) hand, our algorithm shows that the packet loss rate is significantly reduced to less than 5% in average. Because we let the DEV informs the PNC how long the channel time it needs and set up the additional contention access period to allow DEV transmits packets when it is not in its allocated CTA, every packet can be transmitted as soon as possible after generated.. 120. Packet Loss Rate (%). 100. 80. 60. 40. 20. 0. 0. 5. 10. 15. 20. 25. 30. 35. 40. Number of rt-VBR flows Proposed Scheme Delay_Bound=40 Proposed Scheme Delay_Bound=80 Proposed Scheme Delay_Bound=120 Async Delay_Bound=40 Async Delay_Bound=80 Async Delay_Bound=120. Figure. 5- 2: Packet Loss Rate Comparison of Proposed Scheme and Asynchronous. 39.

(48) 25. Packet Loss Rate (%). 20. 15. 10. 5. 0. 0. 5. 10. 15. 20. 25. 30. 35. 40. Number of rt-VBR flows Proposed Scheme Delay_Bound=40 Proposed Scheme Delay_Bound=80 Proposed Scheme Delay_Bound=120 Isoch Delay_Bound=40 Isoch Delay_Bound=80 Isoch Delay_Bound=120. Figure. 5- 3: Packet Loss Rate Comparison of Proposed Scheme and Isochronous. Figure. 5-4, 5-5, 5-6, 5-7 show the transfer delay and jitter performance versus the number of rt-VBR flows. We can notice that when the delay bound of the asynchronous method is set at 40ms, the packet loss rate reaches nearly 100%. In this situation, it is meaningless to discuss its delay because we do not consider the dropped packets. Therefore, we do not plot this line in the following figures. As can be seen from the figures, the transfer delay and jitter in both isochronous and asynchronous schemes slightly increases with the number of flows. However, the transfer delay of the isochronous scheme is about 45ms lower than asynchronous scheme because isochronous scheme do not need to send request for every data 40.

(49) transmission. Note that with higher delay bound, we also obtain higher transfer delay and jitter. The reason is that when the delay bound is long, we need to take more packets into account because the packet loss rate decreases. Thus packets with higher delay are also count in and raise the values of mean delay and jitter. We can also explain the phenomenon in asynchronous scheme case with the same reason. For the proposed dynamic channel reservation system, meanwhile, the corresponding packet transfer delay reduced to only 2ms which is significantly low compare to that for both isochronous and asynchronous systems and slightly increased with the number of offered traffic flows. This is because when the number of traffic flow increases, the DEV will become more and more difficult to get the opportunity to transmit through competition. Therefore, the transfer delay will become longer if the traffic flow number increases. Then we observe the jitter performance in the proposed scheme. The isochronous scheme has the value of 9/ 12/ 13ms while our algorithm shows a relatively small value of 2.5/ 2/ 1.1ms. Note that in the Figure. 5-4 and 5-6, the curve of the asynchronous scheme with delay bound value setting at 120ms rise rapidly when the number of flows increases. The reason is that when there are many flows, the contention of the channel-time request becomes severe and hence the delay increase. From these observations, we can conclude that the proposed scheme outperforms the standard system in both packet loss and delay for rt-VBR traffic.. 41.

(50) 100x103. Transfer Delay (us). 80x103. 60x103. 40x103. 20x103. 0. 0. 5. 10. 15. 20. 25. 30. 35. 40. Number of rt-VBR flows Proposed Scheme Delay_Bound=40 Proposed Scheme Delay_Bound=80 Proposed Scheme Delay_Bound=120 Async Delay_Bound=80 Async Delay_Bound=120. Figure. 5- 4: Transmission Delay Comparison of Proposed Scheme and Asynchronous. 20x10 3. Transfer Delay (us). 15x10 3. 10x10 3. 5x10 3. 0. 0. 5. 10. 15. 20. 25. 30. 35. 40. Number of rt-VBR flows Proposed Scheme Delay_Bound=40 Proposed Scheme Delay_Bound=80 Proposed Scheme Delay_Bound=120 Isoch Delay_Bound=40 Isoch Delay_Bound=80 Isoch Delay_Bound=120. Figure. 5- 5: Transfer Delay Comparison of Proposed Scheme and Isochronous 42.

(51) 25x103. 20x103. Jitter (us). 15x103. 10x103. 5x103. 0. 0. 5. 10. 15. 20. 25. 30. 35. 40. Number of rt-VBR flows Proposed Scheme Delay_Bound=40 Proposed Scheme Delay_Bound=80 Proposed Scheme Delay_Bound=120 Async Delay_Bound=80 Async Delay_Bound=120. Figure. 5- 6: Jitter Comparison of Proposed Scheme and Asynchronous. 18x103 16x103 14x103. Jitter (us). 12x103 10x103 8x103 6x103 4x103 2x103 0. 0. 5. 10. 15. 20. 25. 30. 35. 40. Number of rt-VBR flows Proposed Scheme Delay_Bound=40 Proposed Scheme Delay_Bound=80 Proposed Scheme Delay_Bound=120 Isoch Delay_Bound=40 Isoch Delay_Bound=80 Isoch Delay_Bound=120. Figure. 5- 7: Jitter Comparison of Proposed Scheme and Isochronous 43.

(52) Figure. 5-8 and 5-9 show the aggregate throughput of the standard and dynamic channel time reservation system, respectively. Note that the throughput is measured at the application level, not at the MAC level. In other words, if some packets exceed the deadline, the entire frame is regarded as a missing one and not included in the throughput measurement. We can find that proposed scheme outperforms the standard scheme. The aggregate throughput in our algorithm can be achieved to 1.15 Mbps which is very close to the mean data rate of our used MPEG-4 traffic. The isochronous system, however, shows much less throughput and the difference between the throughputs of the two systems is getting wider as the number of flows increase. As for asynchronous system, if PNC can response the channel time request in time, it can allocate enough CTA length according to the request. Thus when we set high delay bound value to the asynchronous system, it can achieve similar throughput close to the proposed scheme. Figure. 5-10 shows the channel utilization of the three systems. We do not count in the length of beacon, CAP and SIFS/BIFS. Since the purpose of this metric is to observe the channel usage characteristics of each system, we set the delay bound only at 120ms. We can find that our algorithm has better channel utilizing ability since we set up the additional contention access period to allow DEV transmits packets between the last allocated CTA and the start of TFB. The curve of asynchronous. 44.

(53) scheme is very close to the proposed scheme. On the other hand, the isochronous scheme can only transmit packets in its allocated CTA and hence the remaining channel time in the current superframe is wasted. Moreover, the DEV which requests more channel time first may occupy excessive channel time thus the bandwidth cannot be utilized in an efficient way. For above reason, the curve of the isochronous scheme will be lower than the proposed scheme when the loading is heavy.. 40. Throughput (Mbps). 30. 20. 10. 0. 0. 5. 10. 15. 20. 25. 30. 35. 40. Number of rt-VBR flows Proposed Scheme Delay_Bound=40 Proposed Scheme Delay_Bound=80 Proposed Scheme Delay_Bound=120 Async Delay_Bound=80 Async Delay_Bound=120. Figure. 5- 8: Throughput Comparison of Proposed Scheme and Asynchronous. 45.

(54) 40. Throughput (Mbps). 30. 20. 10. 0. 0. 5. 10. 15. 20. 25. 30. 35. 40. Number of rt-VBR flows Proposed Scheme Delay_Bound=40 Proposed Scheme Delay_Bound=80 Proposed Scheme Delay_Bound=120 Isoch Delay_Bound=40 Isoch Delay_Bound=80 Isoch Delay_Bound=120. Figure. 5- 9: Throughput Comparison of Proposed Scheme and Isochronous. 100. Channel Utilization (%). 80. 60. 40. 20. 0. 0. 5. 10. 15. 20. 25. 30. 35. 40. Number of rt-VBR flows Proposed Scheme Delay_Bound=120ms Async Delay_Bound=120ms Isoch Delay_Bound=120ms. Figure. 5- 10: Channel Utilization Comparison. 46.

(55) Chapter 6 Conclusion In this thesis, the properties of 802.15.3 MAC protocol were investigated. In order to achieve a high quality transmission of rt-VBR applications, we proposed a feedback control based MAC mechanism to allow PNC to allocate the channel time dynamically according to each DEV’s traffic demand and exploit the remaining idle bandwidth. The performance of the proposed mechanism has been analyzed and compared to the standard protocol. Simulation results show that our scheme not only guarantees the required delay of rt-VBR applications but also the packet loss performance significantly can be improved. Furthermore, the average delay performance and jitter also have great improvement. Finally, a better channel utilization and higher aggregate throughput have been achieved by the proposed method.. 47.

(56) Reference [1] J.. Karaoguz,. “High-rate. wireless. personal. area. networks,”. IEEE. Communications magazine, pp. 96-102, Dec. 2001 [2] IEEE 802.15.3 Working Group, “Part 15.3: Wireless medium access control (MAC) and physical layer (PHY) specifications for high rate wireless personal area networks (WPAN),” IEEE Standard, Sept. 2003. [3] J. Foerster, E. Green, S. Somayazulu and D. Leeper, “Ultra wideband technology for short or medium range wireless communications,” in Intel technology journal, 2nd quarter, 2001 [4] M. Z. Win and R. A. Scholtz, “Impulse radio: How it works,” IEEE Commun. Lett., Feb. 1998, Vol. 2, pp. 36-38 [5] A. Batra, J. Balakrishnan, A. Dabak, R. Gharpurey, P. Fontaine, J. Lin, J. M. Ho, S. Lee, “Physical Layer Submission to 802.15 task group 3a: Time-Frequency Interleaved Orthogonal Frequency Division Multiplexing,” Texas Instrument, Mar. 2003 [6] X. Wang, Y. Ren, J. Zhao, Z. Guo, R. Yao “Comparison of IEEE 802.11e and IEEE 802.15.3 MAC,” Emerging Technologies: Frontiers of Mobile and Wireless Communication, 2004. Proceedings of the IEEE 6th Circuits and Systems Symposium, Vol.2, June 2004, pp.675-680 [7] XtremeSpectrum, “Trade-off analysis (802.11e versus 802.15.3 QoS mechanism) white paper,” July. 2002 [8] S.H. Rhee, K. Chung, Y. Kim, W. Yoon, K.S. Chang, “An application-aware MAC scheme for IEEE 802.15.3 High-Rate WPAN,” WCNC 2004, IEEE Vol.2, Mar. 2004 48.

(57) [9] R. Mangharam, M. Demirhan, “Performance and simulation analysis of 802.15.3 QoS,” IEEE 802.15-02/297r1, Jul. 2002 [10] Kwan-Wu Chin, Darryn Lowe, “A simulation study of the IEEE 802.15.3 MAC,” Australian Telecommunications and Network Applications Conference (ATNAC), Sydney, Australia, Dec. 2004. [11] Yi-Hsien Tseng, Eric Hsiao-kuang Wu, Gen-Huey Chen, “Maximum traffic scheduling and capacity analysis for IEEE 802.15.3 high data rate MAC protocol,” VTC 2003-Fall. 2003 IEEE 58th , Vol. 3, Oct. 2003 [12] “The optimum MAC/PHY combination for multimedia consumer applications,” White Paper, Xtreme Spectrum, Sep. 2001 [13] Vajda, L., Torok, A., Youn Kyu-Jung, Sun-Do, J., “Hierarchical superframe formation in 802.15.3 networks,” Communications, 2004 IEEE International Conference on , Vol.7 , June. 2004 [14] S. K. Biswas, D. Reininger, and D. Raychaudhuri, “UPC based bandwidth allocation for VBR video in wireless ATM links,” in Proc. INFOCOM’ 97, pp. 1073-1079 [15] C. G. Kang, C. W. Ahn, K. H. Jang, W. S. Kang, “Contention-Free Distributed Dynamic Reservation MAC Protocol with Deterministic Scheduling (C-FD3R MAC) for Wireless ATM Networks”, IEEE Journal on Selected Areas in Communications, Vol. 18 Issue: 9, Sept. 2000, pp 1623-1635 [16] L. Chenyang, J. A. Stankovic, G.. Tao, S.H. Son, “Design and evaluation of a feedback control EDF scheduling algorithm,” IEEE Real-Time Systems Symposium Proceedings. Dec. 1999, pp.56 – 67 [17] Frank H.P. Fitzek, Martin Reisslein, “MPEG-4 and H.263 Video Traces for Network Performance Evaluation”, IEEE Network Vol. 15, No. 6, pp 40-54, Dec. 2001 http://www-tkn.ee.tu-berlin.de/research/trace/trace.html 49.

(58) [18] Torok, A., Vajda, L., Kyu-Jung Youn, Sun-Do June, “Superframe formation algorithms in 802.15.3 networks,” IEEE WCNC. 2004, Vol. 2, Mar. 2004 [19] D.Y. Chiu, Y.C. Sun, and C.Y. Huang, “A Development and Verification Platform for Communication SoC Designs,” VLSI/CAD Technical Program, June. 2005. 50.

(59)