1. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 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 25 th 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.

2. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 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 for real-time applications (video-conferencing, interactive gaming, etc.) 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.

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

4. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 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

5. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 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: 1.Beaconing 2.GTS assignment 3.Downlink, uplink and peer-to-peer packet exchange 4.Packet retransmissions (with max. retry count set to 3) 5.Packet fragmentation 6.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.

6. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 6 MPEG-4 Frame Size Distribution Examples “Jurassic Park” Frame statistics (1 Hour sample) compression ratioYUV:MP49.92 # of Frames-89998 mean frame sizebyte3.8e+03 var frame size-5.1e+06 min frame sizebyte72 max frame sizebyte16745 Mean bit ratebit/sec7.7e+05 Peak bit ratebit/sec3.3e+06 Peak/Mean of bit rate-4.37 “The Firm” Frame statistics (1 Hour sample) compression ratioYUV:MP425.93 # of Frames-89998 mean frame sizebyte1.5e+03 var frame size-1.3e+06 min frame sizebyte32 max frame sizebyte10204 Mean bit ratebit/sec2.9e+05 Peak bit ratebit/sec2e+06 Peak/Mean of bit rate-6.96

7. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 7 Multimedia (MPEG-4) Traffic 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 Overload Average Underutilized Channel Frame size trace of Jurassic Park

8. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 8 802.15.3 Performance with MPEG-4 Traffic 1.With 10x4Mbps flows, the bandwidth required by the application layer is 40Mbps. 2.With 3 packets per GTS for each flow, the MAC and PHY overhead is approx. 26% (26Mbps). 3.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. 4.The average flow Job Failure Rate is 10% with no wireless channel error. 5.This graph shows the best possible average Job Failure Rate for 4Mbps MPEG-4 flows.

9. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 9 802.15.3 Performance with MPEG-4 Traffic (2) 1.No more than two 16Mbps flows can be permitted with a JFR below 10% 2.The channel bit error rate is 0. 3.Each of the N flows is given 100Mbps/N channel utilization which is greater than the average data rate required.

10. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 10 So how can we improve the 802.15.3 MAC? Frame size trace of “Jurassic Park” Frame size trace of “The Firm” 1.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) 2.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 3.We therefore need: a)A mechanism to communicate the transient overload to the PNC in the case of uplink or peer-to-peer traffic b)Need an scheduling algorithm that aggressively satisfies the overload, yet is fair in the long run

11. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 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.

12. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 12 Improved MAC Performance – 4Mbps flows with no channel errors ~95% Channel utilization 70% Average performance improvement over 802.15.3 MAC

13. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 13 MPEG-4 Frame Delivery  (Mean) Frame Size Number of frames Unused (idle) capacity by lowly loaded frames Successfully transmitted frames Reserved bandwidth Overloaded frames that can be serviced by smart packet scheduling Peak size frames that cannot be serviced due to maximum channel capacity limit

14. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 14 Comparison of Frames Delivered 1.Successfully transmitted frame size profile of one of four 8Mbps flows 2.The improved MAC is able to service larger size frames by allocating ALL idle capacity to the overloaded flows

15. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 15 Improved MAC Performance – 8Mbps flows with no channel errors

16. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 16 Improved MAC Performance – 16Mbps flows with no channel errors

17. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 17 Improved MAC Performance – 8Mbps flows with channel errors 46% Average performance improvement over 802.15.3 MAC

18. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 18 Shortest Remaining Processing Time Packet Scheduling 1.The idea is simple. By servicing the shortest jobs first the mean service response time is minimized[1]. 2.Once the queue size of a flow is known, the PNC can make more informed bandwidth allocation decisions in the next super frame. 3.The total instantaneous idle capacity is the sum of the unreserved bandwidth and the instantaneous unused reserved bandwidth by lowly loaded flows. 4.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). 5.All overloaded flows are always allocated at least their reserved utilization. Therefore, there is no unfairness. 6.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.

19. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 19 Flow Isolation (Fairness)

20. doc.: IEEE 802.15-02/297r1 Submission July 2002 Mangharam/Demirhan, Intel LabsSlide 20 Conclusion 1.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. 2.The Shortest Remaining Processing Time scheduling algorithm is the best, most aggressive and simplest packet scheduling algorithm for all traffic types.