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

Abstract SDMA brings challenges to MAC Protection July 2009 doc.: IEEE 802.11-09/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

Challenges of SDMA Protection #1 July 2009 doc.: IEEE 802.11-09/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

Challenges of SDMA Protection #2 July 2009 doc.: IEEE 802.11-09/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

One Solution – Polled Ack July 2009 doc.: IEEE 802.11-09/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

Another Solution – Multi RTS July 2009 doc.: IEEE 802.11-09/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

M-RTS Frame M-RTS frame could be very simple, similar to Data frame July 2009 doc.: IEEE 802.11-09/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

Comparison between Polled Ack vs. Multi RTS #1 July 2009 doc.: IEEE 802.11-09/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

Comparison between Polled ACK vs. Multi RTS #2 July 2009 doc.: IEEE 802.11-09/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

Analysis - M-RTS is better July 2009 doc.: IEEE 802.11-09/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

Conclusion SDMA brings challenges to MAC Protection July 2009 doc.: IEEE 802.11-09/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

July 2009 doc.: IEEE 802.11-09/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

July 2009 doc.: IEEE 802.11-09/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

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