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

2. Month Year
doc.: IEEE 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

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