March 2002 doc IEEE 802 15 02297 r

March, 2002 doc. : IEEE 802. 15 -02/297 r 1 Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Performance and Simulation Analysis of 802. 15. 3 Qo. S] 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. 297 r 0] Abstract: [Simulation and analysis of 802. 15. 3 multimedia Qo. S support. ] Purpose: [Presents current protocol performance and suggests changes for better Qo. S support. Introduces a 802. 15. 3 simulation tool available for distribution. ] Notice: This document has been prepared to assist the IEEE P 802. 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 P 802. 15. Submission 1 Chuck Brabenac, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 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. Submission 2 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 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 Submission 3 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 Assumptions • For MPEG-4 flows, the frame rate is fixed to 30 ms. If a packet is not completely delivered to the receiver within 30 ms, 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 MPEG 4 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 100 Mbps and the preamble is assumed to be 15 s. • MAC overheads such as header size, guard times, a. First. GTSGap and SIFS are as per 802. 15. 3 Draft D 10. • We use a uniform bit error model Submission 4 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 802. 15. 3 MAC Simulation Model • We modeled and simulated the 802. 15. 3 MAC in ns. V 2. This is an open source network simulator available at http: //www. isi. edu/nsnam/ns/ • The 802. 15. 3 simulation model includes: 1. 2. 3. 4. 5. 6. 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. Submission 5 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 MPEG-4 Frame Size Distribution Examples “Jurassic Park” Frame statistics (1 Hour sample) compression ratio YUV: MP 4 9. 92 # of Frames - mean frame size byte 3. 8 e+03 var frame size - 5. 1 e+06 min frame size byte 72 max frame size byte 16745 Mean bit rate bit/sec 7. 7 e+05 Peak bit rate bit/sec 3. 3 e+06 Peak/Mean of bit rate - 89998 4. 37 “The Firm” Frame statistics (1 Hour sample) Submission compression ratio YUV: MP 4 25. 93 # of Frames - 89998 mean frame size byte 1. 5 e+03 var frame size - 1. 3 e+06 min frame size byte 32 max frame size byte 10204 Mean bit rate bit/sec 2. 9 e+05 Peak bit rate bit/sec 2 e+06 Peak/Mean of bit rate - 6 6. 96 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 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 Submission 7 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 802. 15. 3 Performance with MPEG-4 Traffic 1. With 10 x 4 Mbps flows, the bandwidth required by the application layer is 40 Mbps. 2. With 3 packets per GTS for each flow, the MAC and PHY overhead is approx. 26% (26 Mbps). 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 100 Mbps 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 4 Mbps MPEG-4 flows. Submission 8 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 802. 15. 3 Performance with MPEG-4 Traffic (2) 1. No more than two 16 Mbps 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 100 Mbps/N channel utilization which is greater than the average data rate required. Submission 9 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 So how can we improve the 802. 15. 3 MAC? 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 Frame size trace of “Jurassic Park” Submission 10 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 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 (2 KB), 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 @ 100 Mbps is <10 ns overhead which is considerably smaller than the PHY preamble. Submission 11 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 Improved MAC Performance – 4 Mbps flows with no channel errors 70% Average performance improvement over 802. 15. 3 MAC Submission 12 ~95% Channel utilization Mangharam/Demirhan, Intel Labs

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

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

July 2002 doc. : IEEE 802. 15 -02/297 r 1 Improved MAC Performance – 8 Mbps flows with no channel errors Submission 15 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 Improved MAC Performance – 16 Mbps flows with no channel errors Submission 16 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 Improved MAC Performance – 8 Mbps flows with channel errors 46% Average performance improvement over 802. 15. 3 MAC Submission 17 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 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. Submission 18 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 Flow Isolation (Fairness) Submission 19 Mangharam/Demirhan, Intel Labs

July 2002 doc. : IEEE 802. 15 -02/297 r 1 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. Submission 20 Mangharam/Demirhan, Intel Labs