1 / 19

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ Performance and Simulation Analysis of 802.15.3 QoS ] Date Submitted: [ July 7, 2002 ] Source: [ Rahul Mangharam, Mustafa Demirhan ] Company: [ Intel ]

zareh
Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Performance and Simulation Analysis of 802.15.3 QoS] Date Submitted: [July 7, 2002] Source: [Rahul Mangharam, Mustafa Demirhan] Company: [Intel] Address: [2111 NE 25th Ave, Hillsboro, OR 97124] Voice: [503-712-7914], FAX: [503-264-6619], E-Mail: [rahul.mangharam@intel.com mustafa.demirhan@intel.com] Re: [Doc. 297r0] Abstract: [Simulation and analysis of 802.15.3 multimedia QoS support.] Purpose: [Presents current protocol performance and suggests changes for better QoS support. Introduces a 802.15.3 simulation tool available for distribution.] Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that these viewgraphs becomes the property of IEEE and may be made publicly available by P802.15. Mangharam/Demirhan, Intel Labs

  2. What this talk is about • Objective analysis of the 802.15.3 MAC in servicing multi-media (MPEG-4) traffic in the uplink (node to PNC) or peer-to-peer mode • Analysis of the good points and limitations of a dynamic-TDMA MAC • Simulation results for CBR and MPEG-4 performance at different loads and error rates • Proposal for a ~60% improvement in MAC performance – with an addition of only a single byte • Present an 802.15.3 simulator. It is open source. Mangharam/Demirhan, Intel Labs

  3. 802.15.3 Performance Analysis • Analysis of 802.15.3 MAC in terms of: • Job Failure Rate (JFR) for Constant Bit Rate (CBR) and MPEG-4 traffic • JFR is the rate at which packets are dropped due to missing their deadlines • Effect of channel utilization on JFR • Channel utilization is defined as the ratio of the average frame size (with protocol overhead) and the average frame inter-arrival time • Performance of multimedia traffic for different error rates • Packet error rate is the effective error rate seen by the MAC after error correction but does not include the effect of retransmissions. • Improved 802.15.3 MAC – with queue state information • Performance comparison to 802.15.3 MAC • Evaluation of aggressive packet scheduling for all traffic types Mangharam/Demirhan, Intel Labs

  4. Assumptions • For MPEG-4 flows, the frame rate is fixed to 30ms. If a packet is not completely delivered to the receiver within 30ms, it is dropped • We use an MPEG-4 traffic generator that generates traffic which has the same first and second order statistics as an original MPEG4 trace. The code can be found at http://www.tik.ee.ethz.ch/~fiedler/provisioning.html • All CBR flows are well behaved with a fixed packet size and fixed inter-arrival times • The physical layer data rate is 100Mbps and the preamble is assumed to be 15s. • MAC overheads such as header size, guard times, aFirstGTSGap and SIFS are as per 802.15.3 Draft D10. • We use a uniform bit error model Mangharam/Demirhan, Intel Labs

  5. 802.15.3 MAC Simulation Model • We modeled and simulated the 802.15.3 MAC in nsV2. This is an open source network simulator available at http://www.isi.edu/nsnam/ns/ • The 802.15.3 simulation model includes: • Beaconing • GTS assignment • Downlink, uplink and peer-to-peer packet exchange • Packet retransmissions (with max. retry count set to 3) • Packet fragmentation • Flexible super-frame size • Various traffic types (TCP/UDP/RTP) and applications (CBR/MPEG) can be simulated • Various error modules can be used • The 802.15.3 MAC source code is available. Contact authors for more information. Mangharam/Demirhan, Intel Labs

  6. MPEG-4 Frame Size Distribution Examples Mangharam/Demirhan, Intel Labs

  7. Multimedia (MPEG-4) Traffic Frame size trace of Jurassic Park Overload Average Underutilized Channel Source: Frank H.P. Fitzek, Martin Reisslein, "MPEG-4 and H.263 Video Traces for Network Performance Evaluation“, IEEE Network Vol. 15, No. 6, pages 40-54, Dec 2001. http://www-tkn.ee.tu-berlin.de/~fitzek/TRACE/trace.html Mangharam/Demirhan, Intel Labs

  8. 802.15.3 Performance with MPEG-4 Traffic • With 10x4Mbps flows, the bandwidth required by the application layer is 40Mbps. • With 3 packets per GTS for each flow, the MAC and PHY overhead is approx. 26% (26Mbps). • The total network load is ~66% and we allocate the remaining 34% of channel capacity equally among all flows. Thus we allocate the entire 100Mbps for the given number of flows. • The average flow Job Failure Rate is 10% with no wireless channel error. • This graph shows the best possible average Job Failure Rate for 4Mbps MPEG-4 flows. Mangharam/Demirhan, Intel Labs

  9. 802.15.3 Performance with MPEG-4 Traffic (2) • No more than two 16Mbps flows can be permitted with a JFR below 10% • The channel bit error rate is 0. • Each of the N flows is given 100Mbps/N channel utilization which is greater than the average data rate required. Mangharam/Demirhan, Intel Labs

  10. Frame size trace of “The Firm” Frame size trace of “Jurassic Park” So how can we improve the 802.15.3 MAC? • MPEG-4 instantaneous data rate requirements oscillate widely about the mean data rate. The peak to mean data rate ratio varies from 3 to more than 10 (depending on the scenario and quality) • Since it would be wasteful to statically reserve the peak data rate, we must dynamically allocate resources to those flows experiencing overload. This must be done while maintaining fairness • We therefore need: • A mechanism to communicate the transient overload to the PNC in the case of uplink or peer-to-peer traffic • Need an scheduling algorithm that aggressively satisfies the overload, yet is fair in the long run Mangharam/Demirhan, Intel Labs

  11. The 1 Byte Solution • Mechanism: • By adding a single byte to the MAC header, a node can inform the PNC of its current queue size. • Queue size information can possibly be encoded in bytes, Max. size packets (2KB), or according to a well defined table of queue size ranges. • Thus, with every packet exchange, the PNC is aware of the instantaneous channel requirement (which may be temporarily more than the reserved bandwidth) of each flow. • Packet Scheduling: • With the transient load information, the PNC can schedule the overloaded flows in the next superframe by assigning them the idle bandwidth. • Furthermore, the PNC can dynamically allocate the idle bandwidth of no load or lowly loaded nodes to the overloaded flows. • 1 byte @ 100Mbps is <10ns overhead which is considerably smaller than the PHY preamble. Mangharam/Demirhan, Intel Labs

  12. 70% Average performance improvement over 802.15.3 MAC ~95% Channel utilization Improved MAC Performance – 4Mbps flows with no channel errors Mangharam/Demirhan, Intel Labs

  13. Comparison of Frames Delivered • Successfully transmitted frame size profile of one of four 8Mbps flows • The improved MAC is able to service larger size frames by allocating ALL idle capacity to the overloaded flows Mangharam/Demirhan, Intel Labs

  14. Improved MAC Performance – 8Mbps flows with no channel errors Mangharam/Demirhan, Intel Labs

  15. Improved MAC Performance – 16Mbps flows with no channel errors Mangharam/Demirhan, Intel Labs

  16. Improved MAC Performance – 8Mbps flows with channel errors 46% Average performance improvement over 802.15.3 MAC Mangharam/Demirhan, Intel Labs

  17. Shortest Remaining Processing Time Packet Scheduling • The idea is simple. By servicing the shortest jobs first the mean service response time is minimized[1]. • Once the queue size of a flow is known, the PNC can make more informed bandwidth allocation decisions in the next super frame. • The total instantaneous idle capacity is the sum of the unreserved bandwidth and the instantaneous unused reserved bandwidth by lowly loaded flows. • The overloaded flows are allocated excess capacity in the ascending order of their overload queue size (number of packets in excess of the reserved utilization). • All overloaded flows are always allocated at least their reserved utilization. Therefore, there is no unfairness. • All no-load or lowly loaded flows are given enough time to only communicate their queue size in the next superframe. 1. Linus E. Schrage and Louis W. Miller. The queue M/G/1 with the shortest remaining processing time discipline. Operations Research, 14:670--684, 1966. Mangharam/Demirhan, Intel Labs

  18. Flow Isolation (Fairness) Mangharam/Demirhan, Intel Labs

  19. Conclusion • With just 1 more byte in the MAC header, we can improve the 802.15.3 MAC performance by ~60% in terms of Job Failure Rate for multimedia traffic. • The Shortest Remaining Processing Time scheduling algorithm is the best, most aggressive and simplest packet scheduling algorithm for all traffic types. Mangharam/Demirhan, Intel Labs

More Related