[Multi-RTS Proposal]

[Multi-RTS Proposal] Authors: Date: 2010-09-12 Yuichi Morioka, Sony Corporation

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

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

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

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

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

M-RTSFrame • 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

Comparison between Polled Ack vs. Multi RTS #1 • 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 Polled ACK Multi RTS Yuichi Morioka, Sony Corporation

Comparison between Polled ACK vs. Multi RTS #2 Multi RTS • 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 Polled ACK Yuichi Morioka, Sony Corporation

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

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

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

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

Thank you! Yuichi Morioka, Sony Corporation

[Multi-RTS Proposal]