Audio and video support by MCCA Month Year doc.: IEEE 802.11-yy/xxxxr0 July 2010 Audio and video support by MCCA Date: July 2010 Authors: Ivan Pustogarov, IITP RAS John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 July 2010 Abstract Audio and video traffic in mesh may degrade significantly when EDCA is used (due to high packet loss probability and delay). Audio and video traffic in mesh can be sent within MCCA TXOP to provide parameterized QoS. Even in perfect channel conditions, audio and video packet transmissions within MCCA TXOP may be unreliable. We propose to slightly modify MCCA procedure, so that voice and video traffic in mesh can be delivered more reliably. Ivan Pustogarov, IITP RAS John Doe, Some Company

Audio/Video support and EDCA July 2010 Audio/Video support and EDCA EDCA is unable to provide sufficient QoS support for time sensitive periodic traffic such as streaming media and voice over internet protocol (VOIP) in mesh. Example [1]: STA1 is not aware of whether STA3 is transmitting and starts its transmission which leads to collision on STA2. Intensive background traffic with long packets on link STA3-STA4 can completely suppress voice link STA1-STA2. Ivan Pustogarov, IITP RAS

Audio/Video support and MCCA July 2010 Audio/Video support and MCCA MCCA mechanism was initially designed to provide support for time sensitive periodic traffic such as streaming media and voice over internet protocol (VOIP) in mesh. BUT… Ivan Pustogarov, IITP RAS

Problem statement (1/2) July 2010 Although an MCCA-aware station is not allowed to start to transmit within MCCAOP, it can start to transmit shortly before MCCAOP. Hence, MCCAOP and EDCA packet transmission may overlap. This may lead to: 1)MCCA TXOP truncation or 2) collisions Ivan Pustogarov, IITP RAS

July 2010 Problem statement (2/2) The shorter the MCCAOP the higher the probability that a packet transmission within this MCCAOP will not occur at all due to MCCA TXOP truncation (case1) The longer the MCCAOP the higher the probability that a packet transmission within this MCCAOP will get into collision due to hidden terminal (case 2). Voice packets are short, hence MCCAOPs are short (e.g. iLBC packet is only 50 bytes on application layer). The question is how to eliminate MCCAOP and packet transmission overlap. Ivan Pustogarov, IITP RAS

Solution 1 July 2010 Each time the channel becomes free, a station which has a packet to transmit checks whether is has enough time to send this packet before the next MCCAOP. i.e. the station checks the inequality: DIFS+Backoff_Slots*σ+TDATA+TSIFS+TACK < tMCCA-current_time, where Backoff_Slots is the number of remaining backoff slots and tMCCA is the MCCAOP start time If “yes” the station continues to decrement its backoff counter. If “no” the station freezes its backoff counter and continues to decrement it only after the MCCAOP. Ivan Pustogarov, IITP RAS

Solution 2 July 2010 Just before its packet transmission, a station checks whether it has enough time to send this packet before the next MCCAOP. i.e. the station checks the inequality: TDATA+TSIFS+TACK < tMCCA - current_time where tMCCA is the MCCAOP start time If “yes” the station starts its transmission. If “no” the station does not transmit and chooses new backoff value after the MCCAOP. Ivan Pustogarov, IITP RAS

July 2010 Strawpoll In order to support audio&video transmission in mesh, should access during an MCCAOP by mesh STAs that are not the MCCAOP owner be changed according to the presentation? Yes (Solution 1): Yes (Solution 2): No: Abs.: Ivan Pustogarov, IITP RAS

References Acknowledgements July 2010 [1] Andrey Lyakhov, Ivan Pustogarov, Alexander Safonov, Mikhail Yakimov. Starvation Effect Study in IEEE 802.11 Mesh Networks. MeshTech"09 Third IEEE International Workshop on Enabling Technologies and Standards for Wireless Mesh Networking, October 12, 2009. Macau SAR, P.R. China Acknowledgements The proposal was made in the framework of FP7 project “Flavia”. Ivan Pustogarov, IITP RAS