1. Month Year
doc.: IEEE yy/xxxxr0
May 2005
TGn Sync MAC Response to Reasons and Cures Relating to Reverse Direction
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Robert Stacey, Intel
John Doe, Some Company

2. Authors (continued): May 2005 Month Year doc.: IEEE 802.11-yy/xxxxr0
Robert Stacey, Intel
John Doe, Some Company

3. Reasons and Cures Feedback for Reverse Direction
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Reasons and Cures Feedback for Reverse Direction
General support for piggybacking data with ack
Concern regarding complexity (#49, #64, #85.1, #92)
No benefit to RD under HCCA (#77)
Concern that RD is introducing HCCA-like scheduling to EDCA (#77)
Cures suggested in comments:
Remove RD altogether (#49)
Simplify protocol, e.g. allow single data frame response (#41.2)
Follow TXOP with short response TXOP (#64)
Piggyback data with CTS in subsequent TXOP (#64)
Robert Stacey, Intel
John Doe, Some Company

4. Discussion of Benefit We like contention based access
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Discussion of Benefit
We like contention based access
It provides a robust, efficient, simple mechanism for sharing network bandwidth
TGe TXOP and Block Ack provided significant efficiency gain while retaining the benefits of contention based access
Aggregation improves efficiency within TXOP (broad agreement)
RD provides significant additional gain under EDCA by
Piggybacking BA with data
Improving TXOP utilization
Reducing contention
Robert Stacey, Intel
John Doe, Some Company

5. Discussion of Benefit Network traffic is asymmetric
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Discussion of Benefit
Network traffic is asymmetric
Over short periods the majority of the traffic is in one direction with small amounts in the reverse direction
The majority of traffic is to or from a single node – the AP
 TXOPs are often underutilized in one direction
Consider two scenarios:
Traffic from one STA to another
Traffic from AP to multiple STAs
Robert Stacey, Intel
John Doe, Some Company

6. Immediate BA May 2005 Month Year doc.: IEEE 802.11-yy/xxxxr0 STA1 (AP)
TXOP
TXOP
TXOP
TXOP
TXOP
STA1 (AP)
RA2
RA2
RA2
STA2
RA1
RA1
TXOPs are often underutilized (especially uplink)
Radio turnaround per data block for BA
TXOP
TXOP
TXOP
TXOP
TXOP
TXOP
STA1 (AP)
RA2
RA3
RA4
STA2
RA1
STA3
RA1
STA4
RA1
Contention [+ collision detect]
Data BA
Robert Stacey, Intel
John Doe, Some Company

7. No Ack BA May 2005 No Ack BA Allows BA to be aggregated with data
Month Year
doc.: IEEE yy/xxxxr0
May 2005
No Ack BA
TXOP
TXOP
TXOP
TXOP
TXOP
STA1 (AP)
RA2
RA2
RA2
STA2
RA1
RA1
Radio turnaround for BA eliminated and BA piggybacked with data improving TXOP efficiency, but…
TXOP
TXOP
TXOP
TXOP
TXOP
TXOP
TXOP
STA1 (AP)
RA2
RA3
RA2
RA3
RA4
STA2
RA1
RA1
STA3
RA1
RA1
STA4
RA1
…the uplink TXOP is still frequently underutilized
No Ack BA
Allows BA to be aggregated with data
But TXOPs are frequently underutilized
Contention [+ collision detect]
Data BA
Robert Stacey, Intel
John Doe, Some Company

8. Reverse Direction May 2005 Reverse Direction
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Reverse Direction
All TXOPs are efficiently utilized…
TXOP
TXOP
TXOP
TXOP
STA1 (AP)
RA2
RA2
RA2
RA2
STA2
RA1
RA1
…either with pure downlink traffic…
… or with mixed uplink and downlink traffic
TXOP
TXOP
TXOP
TXOP
STA1 (AP)
RA2
RA3
RA4
RA2
STA2
RA1
RA1
STA3
RA1
STA4
RA1
Reverse Direction
Allows BA to be aggregated with data
And improves TXOP utilization
Contention [+ collision detect]
Data BA
Robert Stacey, Intel
John Doe, Some Company

9. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Power Efficiency
downlink
Medium Busy
Medium Busy
Medium Busy
uplink
U-APSD STA Awake
A PS STA wants to complete exchange in as short a time as possible
No guarantees, but reverse direction data has potential for completion in single TXOP with 3 PPDUs
Robert Stacey, Intel
John Doe, Some Company

10. Additional Simulation Results
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Additional Simulation Results
An attempt was made to reuse 11e CF-Poll semantics to achieve equivalent to reverse direction data
Remainder of TXOP is transferred (TT) to peer using CF-Poll
TT Ack = CF-Poll is ACKed
TT Simple = CF-Poll ACK is piggybacked on data
Compared with existing reverse direction data protocol
Example sequences shown
Robert Stacey, Intel
John Doe, Some Company

11. Additional Simulation Results
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Additional Simulation Results
All simulations use same simple heuristic
If the initiator can’t use the full TXOP limit, offer the remainder to the responder
The responder opportunistically uses the offered period if it has data to transmit
Protection using LongNAV
Robert Stacey, Intel
John Doe, Some Company

12. Additional Simulation Results
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Additional Simulation Results
Gain is significantly reduced with CF-Poll like semantics
Robert Stacey, Intel
John Doe, Some Company

13. Addressing Concerns Complexity No benefit from RD under HCCA
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Addressing Concerns
Complexity
Optional in proposal, but still relatively simple to implement
Simulations use a simple heuristic that advertises and then grants any remaining TXOP to peer
Peer opportunistically uses advertised duration if it has data to send
No benefit from RD under HCCA
Largely True – benefit derives primarily from improved TXOP utilization mitigating contention overhead
RD introduces HCCA-like scheduling to EDCA
Disagree – simple heuristics provide significant gain
There are simplifications that have been discussed and will be put before the members in a straw poll
Robert Stacey, Intel
John Doe, Some Company

14. May 2005
References
n-tgnsync-mac-response-to-reasons-and-cures.xls
Robert Stacey, Intel