MDA Simulation Study: MDAOP Stretching and Other Concerns September 2007 doc.: IEEE 802.11-07/2537r0 September 2007 MDA Simulation Study: MDAOP Stretching and Other Concerns Date: 2007-09-18 Authors: Ye Chen, Motorola Ye Chen, Motorola

September 2007 doc.: IEEE 802.11-07/2537r0 September 2007 Abstract This document investigates challenges involved in restricting channel access to occur during deterministic intervals (e.g. an MDAOP), and explores the benefits of adding flexibility. Results from simulation experiments are presented to illustrate the issues involved. Additionally, modification to MDA channel access to address these issues are reviewed. Ye Chen, Motorola Ye Chen, Motorola

September 2007 Comments Received Comments received about the deterministic channel access mechanism specified in MDA include: Concerns about restriction that MDA TXOPs are not allowed to cross MDAOP boundaries, and how these restrictions complicate retransmission procedures Concerns about needing to reserve excess time so every MDAOP can accommodate one or more retransmissions Questions raised about whether time taken to access the channel should count towards the MDAOP length Questions about whether the use of a single set of channel access parameters both within and after the MDAOP should be prohibited Ye Chen, Motorola

September 2007 What have we done? Started looking into the details of MDA channel access using a simulation scenario to better understand Do the start of MDA TXOPs frequently get delayed? Do MDA TXOPs generally finish in time (e.g. before the end of the reserved MDAOP)? If we were to enforce the rule that MDA TXOPs must finish in time, how much excess time should each MDAOP include Note: this is not a question for which we would expect to find a simple answer Ye Chen, Motorola

September 2007 How did we do it? Started with MDA simulation model described in 11/07-356r0 Modified the model to collect some new MDA statistics Collected results for mixture of MDA and station traffic Mesh AP2 / Mesh Portal Mesh AP7 Mesh AP3 Mesh AP1 Mesh AP6 Wired DS Ye Chen, Motorola

New Statistics? Looking at two error cases: Normal MDAOP September 2007 New Statistics? Looking at two error cases: MDAOP TxOP Delayed Start Time Delayed in Completion time Normal MDAOP Case 1: Stretched MDAOP MDAOP TxOP Delayed Start Time Delayed in Completion time Case 2: Missed MDAOP Ye Chen, Motorola

Results Delayed Start Time Percentage of Missed/Stretched MDAOPs September 2007 Results Delayed Start Time Percentage of Missed/Stretched MDAOPs Delay in Completion Time Ye Chen, Motorola

Delayed Start Time (Portal AP2) September 2007 Delayed Start Time (Portal AP2) Each MDAOP contains 90 µs (10 slots) of extra time If Start Delay > 90 µs, then it’s a stretched MDAOP Reserved MDAOP = 340 µs If Start Delay > 340 µs, then it’s a missed MDAOP Even at low loads (e.g. 5 VoIP STA), the MDAOP is often stretched; issue for delay sensitive traffic Ye Chen, Motorola

Missed/Stretched MDAOPs (AP2 Portal) September 2007 Missed/Stretched MDAOPs (AP2 Portal) A significant number of the TXOPs do not complete on time; issue for delay sensitive traffic Ye Chen, Motorola

Delay in Completion Time (AP2 Portal) September 2007 Delay in Completion Time (AP2 Portal) Completion time can get pushed out due to: Delays in start time Hidden terminals Retransmissions Numbers shown are averages; size of MDAOP would need to be lengthened even more to keep losses low Ye Chen, Motorola

Discussion Results suggest issues with current MDA specification September 2007 Discussion Results suggest issues with current MDA specification Start times and completion times are frequently delayed A significant percentage of MDAOPs are either stretched or missed Factor preventing on-time completion include STA traffic, congestion, hidden terminals, retransmissions Changes recommended Recommend modifying MDA channel access to accommodate and work around conditions that prevent on-time completion Ye Chen, Motorola

Proposal Continue Negotiating MDAOP times with neighbors September 2007 Proposal Continue Negotiating MDAOP times with neighbors Use existing MDAOD setup and advertisement signaling Creation of schedule reduces collisions between mesh points that might be hidden from one another Modify MDA contention mechanism Restriction to complete transmissions within an MDAOP were in place to Avoid misuse of the MDA contention parameters Avoid fairness issues with nodes not deploying MDA Avoid contending for channel during the neighbors’ MDAOP Largest gain in performance due to scheduling, not specialized contention parameters Revert to utilizing EDCA during and after MDAOP Ye Chen, Motorola

Details of Proposed Changes September 2007 Details of Proposed Changes Modify 9.21 and specifically 9.21.10 to Transmit using EDCA channel access parameters associated with each frame instead of employing a special set of MDA parameters Replace restriction that (old) TXOP must complete within an MDOP, with (new) if MDAOP stretching or a missed MDAOP occurs then channel access is suspended during any neighbor’s MDAOPs Reuse EDCA retransmit procedures to recover from channel errors, subject to restriction above Continue to use existing MDAOD setup and advertisement signaling with enhanced access scheme Document 11-07/2536r0 describes suggested changes to the 802.11s draft 1.06 to address comments 1045, 1300, and 1538 Ye Chen, Motorola

September 2007 Questions? Ye Chen, Motorola

September 2007 Backup Ye Chen, Motorola

Current MDAOP Definition Modified MDAOP Definition September 2007 Case Study MDAOP Schedule MDAOP1 MDAOP2 MDAOP3 Current MDAOP Definition Dstart1 Dstart2 Channel busy Tx 3 Tx2 Time Tstart1 Tstart2 Channel error Modified MDAOP Definition Dstart1 Dstart2 Channel busy Tx 1 Tx2 Tx 3 reTx Time Channel error The MP with missed/stretched MDAOP can finish the MDA transmission if possible instead of waiting for the next MDAOP The same contention parameters within/outside the MDAOP simplifies the transition in/out MDAOP (no sudden contention parameter changes) Ye Chen, Motorola

CDF of Delayed Start time (AP2 Portal) September 2007 CDF of Delayed Start time (AP2 Portal) For 8 voice STAs, 5% of the frames have a delayed start time that exceeds 340 µs (missed MDAOP) For 13 voice STAs, 20% of the frames have a delayed start time in excess of 340 µs. (missed MDAOP) 8 Voice STAs 13 Voice STAs 340 µs ms Ye Chen, Motorola

CDF of Delayed Completion Time (AP2 Portal) September 2007 CDF of Delayed Completion Time (AP2 Portal) For 8 voice STAs, 10% of the frames have a completion time delay time that exceeds 400 us. For 13 voice STAs, 10% of the frames have a completion time that exceeds 1.5 ms The maximum delay in completion time for 8 voice STAs loading is about 2 ms. For 13 voice STAs loading it could be a long as 8 ms 8 Voice STAs 13 Voice STAs ms These trends can impact delay sensitive traffic Ye Chen, Motorola