1. [Multi-RTS Proposal] Date: 2010-09-12 Authors: September 2010
July 2009
doc.: IEEE /0xxxr0
September 2010
[Multi-RTS Proposal]
Date:
Authors:
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

2. Abstract SDMA brings challenges to MAC Protection
July 2009
doc.: IEEE /0xxxr0
September 2010
Abstract
SDMA brings challenges to MAC Protection
Can not rely on Duration/ID Field in MAC Header to provide NAV
Third party STAs may see long gap between SDMA Data and Ack, and cause collision
Two mechanisms are analyzed to mitigate these challenges
Polled Ack Mechanism
Multi RTS Mechanism
Because Multi RTS provides higher level of protection while maintaining the same overhead, it is concluded that this approach should be considered
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

3. Challenges of SDMA Protection #1
July 2009
doc.: IEEE /0xxxr0
September 2010
Challenges of SDMA Protection #1
SDMA brings great benefit in increasing system level throughput
However, SDMA also brings challenges in providing appropriate protection for collision avoidance
One major issue is that MAC Protection (NAV Setting through Duration/ID Field) can not be realized through SDMA Data frames
For example, STA X/Y in above figure, can not decode the Duration Field in Data Frame
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

4. Challenges of SDMA Protection #2
July 2009
doc.: IEEE /0xxxr0
September 2010
Challenges of SDMA Protection #2
Moreover, with DL SDMA, the Ack Frames must be sent sequentially, and for some third party STAs this creates a long gap between received Data and anticipated Ack
For example in the above figure, STA Z receives the Data frame from the AP, and sees media idle for 3xSIFS + 2xBA
In a non SDMA case, Ack Frames would be protected by the AIFS mechanism, but this will not work for SDMA
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

5. One Solution – Polled Ack
July 2009
doc.: IEEE /0xxxr0
September 2010
One Solution – Polled Ack
In order to overcome these challenges, a Polled Ack mechanism has been proposed
With this mechanism, the AP polls for the Ack from each receiving STAs
This solves the “gap” problem, but with high overhead
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

6. Another Solution – Multi RTS
July 2009
doc.: IEEE /0xxxr0
September 2010
Another Solution – Multi RTS
Another solution may be the a Multi RTS (M-RTS) approach
The AP schedules for multiple consecutive CTSs from receiving STAs listed in the M-RTS
CTS Offset may be predefined by ordering (1st STA send after SIFS, 2nd STA send after 2xSIFS+CTS, …) or explicitly scheduled (1st STA send after xx us, 2nd STA after yy us…)
The M-RTS and CTSs are all sent in legacy PPDU, so MAC protection can be provided to all surrounding third party STAs
No worry about the “gap” because MAC protection is already established up front
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

7. M-RTS Frame M-RTS frame could be very simple, similar to Data frame
July 2009
doc.: IEEE /0xxxr0
September 2010
M-RTS Frame
M-RTS frame could be very simple, similar to Data frame
With Frame Control, Duration, 2-5 Address Fields, and FCS
Could also have Group ID field if a fitting method is adopted
Could also have CTS Offset Field to explicitly schedule each CTS tx timing
M-RTS would prompt RX STAs for reception (i.e. receive beamforming)
CTS Responding Time is prefixed
RA1 would respond in SIFS, RA2 would respond in 2xSIFS+CTS…
Even if a CTS is missed, each RA responds at the specified time
AP can decide on whether to send data to the missing RA or cancel its transmission
NAV Reset should not be used because some third party STAs may not hear the Data Frame due to beamforming
Single RTS/CTS approach is dangerous in that regard
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

8. Comparison between Polled Ack vs. Multi RTS #1
July 2009
doc.: IEEE /0xxxr0
September 2010
Comparison between Polled Ack vs. Multi RTS #1
Polled ACK
Multi RTS
Polled Ack and Multi RTS has the exact same number of overhead packets
Overhead packets are non Data packets, e.g. RTS(M-RTS), CTS, BA, and Polling
So the overhead comparison is a tie
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

9. Comparison between Polled ACK vs. Multi RTS #2
July 2009
doc.: IEEE /0xxxr0
September 2010
Comparison between Polled ACK vs. Multi RTS #2
Multi RTS
Polled ACK
The above figure illustrates the MAC protected area
With Polled Ack mechanism, only one STA responds with the CTS, so MAC protection is not provided around the non responding STAs
With M-RTS all STAs respond with CTS so have full protection coverage
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

10. Analysis - M-RTS is better
July 2009
doc.: IEEE /0xxxr0
September 2010
Analysis - M-RTS is better
It has been shown that the M-RTS approach can provide better protection than the Polled Ack approach while maintaining equivalent overhead
In various submissions, MAC protection is discussed to be more important especially in SDMA favored scenarios (i.e. densely populated environment)
Because the Duration field will not serve its purpose in case of SDMA, it may be used for other purposes
It is clear the the M-RTS can be the favorable approach in some scenarios
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

11. Conclusion SDMA brings challenges to MAC Protection
July 2009
doc.: IEEE /0xxxr0
September 2010
Conclusion
SDMA brings challenges to MAC Protection
Can not rely on Duration/ID Field in MAC Header to provide NAV
Third party STAs may see long gap between SDMA Data and Ack, and cause collision
Two mechanisms were analyzed
Polled Ack Mechanism
Multi RTS Mechanism
Because Multi RTS provides higher level of protection while maintaining the same overhead, it is concluded that this approach should be considered
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

12. July 2009
doc.: IEEE /0xxxr0
September 2010
Strawpoll #1
Do you agree that MAC Protection (NAV setting through Durtion/ID Field in the MAC Header) does not work for DL SDMA Data Frames?
Yes/No/Abstain
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

13. July 2009
doc.: IEEE /0xxxr0
September 2010
Strawpoll #2
Do you agree that Multi RTS should be considered further as an additional protection mechanism for 11ac?
Yes/No/Abstain
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation

14. Thank you! September 2010 July 2009 doc.: IEEE 802.11-09/0xxxr0
Yuichi Morioka, Sony Corporation
Yuichi Morioka, Sony Corporation