1. TGn Sync MAC Questions for TGn
Month Year
doc.: IEEE yy/xxxxr0
May 2005
TGn Sync MAC Questions for TGn
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
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

2. Authors (continued): May 2005 Month Year doc.: IEEE 802.11-yy/xxxxr0
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

3. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Abstract
This document describes questions that the TGn Sync MAC team would like to ask of the TGn members.
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

4. Questions Changes to reverse direction protocols
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Questions
Changes to reverse direction protocols
Changes to pairwise spoofing
Changes to coexistence modes
Changes to Block Ack enhancements
Question related to power-saving support
Question related to introduction of RIFS bursting
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

5. Overview of Reverse Direction Protocol
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Overview of Reverse Direction Protocol
The current reverse direction protocol uses a 3-way handshake
The handshake allows for accurate pairwise spoofed protection
IAC
IAC
Data BA
CF-End
Advertise availability
Grant use
Request use
RAC BA
Data
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

6. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Simplified Protocol
Possible change: simply grant any remaining TXOP to the peer without the initial exchange
Impact:
Reduction in scheduling requirements (i.e. no need to decide on RDL/RDR/RDG)
Accurate spoofed protection would not be feasible with the current pairwise spoofing mechanism.
Without changes to the spoofing mechanism, usage would be limited to LongNAV protection (NAV with CF-End reset) or partially protected/unprotected exchanges
RTS
Data BA
CF-End
Grant use (piggyback with data or BAR)
RTS BA
Data
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

7. Simulation Methodology
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Simulation Methodology
All simulations use a simple heuristic that grants any unused TXOP to the peer
Simulations use LongNAV protection: RTS-CTS…CF-End
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

8. Simulation Results May 2005 Simplified reverse direction protocol
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Simulation Results
Simplified reverse direction protocol
Performance of simplified protocol
is similar to existing protocol
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

9. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Summary
Only a single bit of signaling is necessary (the “simple grant”) combined with the existing Duration/ID field.
The additional 1-bit could go in a number of different locations (i.e. IAC, Data, BAR)
Performance results are comparable to 3-way handshake
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

10. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Question
Should the 3-way handshake reverse direction protocol be replaced with a 1-way simple grant?
Yes 64
No 0
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

11. Current Pairwise Spoofing
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Current Pairwise Spoofing
PHY Layer Protection of Pairs of Packets
Effective Protection towards hidden nodes (OBSS)
Current e MAC Protection is weak towards OBSS
Need to advertise to the peer the length of the next packet
FPD/RDR fields of IAC/RAC are used for this purpose
Simplifications described next eliminates the need for these fields
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

12. Pairwise Spoofing Simplification – Option 1
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Pairwise Spoofing Simplification – Option 1
RTS/IAC Legacy SIGNAL field sets the spoofing duration to cover the transmission of the CTS/RAC by the Responder.
Even if the IAC fails, there is no medium wastage
The Duration field in the RTS/IAC informs the Responder the length of the spoofed duration to set in its Legacy SIGNAL field.
FPD/RDR is not required
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

13. Pairwise Spoofing Simplification – Option 1
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Pairwise Spoofing Simplification – Option 1
Initiator only extends spoofing if it receives RAC/CTS
Extension of spoofed duration beyond the initial spoofed duration is not guaranteed
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

14. Simplification for Pairwise Spoofing – Option 2
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Simplification for Pairwise Spoofing – Option 2
IAC only spoofed up to end of RAC/CTS frame
Even if the IAC fails, no medium wastage
Responder spoofs according to the duration value in the IAC frame
FPD/RDR is not required
Initiator only extend spoofing if it receives RAC/CTS
Spoofed duration end exactly one RAC longer than the responder spoofed duration
Spoofed duration can be extended
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

15. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Question
Possible change: replace pairwise spoofing with one of the mechanisms described here
Impact:
The impact on performance needs to be verified in simulations
Existing signaling is re-used to the maximum
There is a reduction in signaling complexity by removing the FPD mechanism, opening the way to further simplification of the IAC/RAC.
Question: should the pairwise spoofing mechanism be replaced with one of the mechanisms describe here?
Yes 42
No 3
More time 15
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

16. Mixed Mode Operations in the spec
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Mixed Mode Operations in the spec
Infrastructure BSS
Pure
Mixed Capable
Managed Mixed
Unmanaged Mixed
20 MHz-Base Managed Mixed
IBSS
Discoverable IBSS
Mixed IBSS
when a legacy device
associates, shifts to
when a legacy device
associates, shifts to
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

17. Management of coexistence
Month Year
doc.: IEEE yy/xxxxr0
May 2005
BSS Modes
Legacy in control ch.
Legacy in extension ch.
Management of coexistence
Pure
N/A
Mixed Capable
Managed Mixed 
AP base
Unmanaged Mixed
STA base
20 MHz-base managed mixed
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

18. Pros and Cons of BSS Mixed Modes
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Pros and Cons of BSS Mixed Modes
capable of legacy in extension
overhead in starting 40 phase
contention between 20 and 40
fairness of channel access
additional beacon mng
DLP between 40 and 20 in 20 MHz
Managed Mixed 0* -1
Unmanaged Mixed +1
20 MHz-Base Managed Mixed
* depends on AP scheduling
Pros in Pink, Cons in Blue
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

19. Question Proposed change: remove pure mode? Impact
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Question
Proposed change: remove pure mode?
Impact
We need to find a way to allow only HT STAs to associate, otherwise legacy STA may attempt association only to be rejected by the HT AP.
Question: should pure mode operation be removed?
Yes 25
No 13
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

20. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Question
Possible change: remove the distinction between pure, managed mixed and unmanaged mixed modes at the STA, replace with dynamic basic rate set updates
Impact:
Removal of this distinction requires dynamic updates to the basic rate set to achieve control of protection as legacy devices come and go, and when the AP decides to manage contention between different classes of device.
Some simplification of control state is possible at the STA at the expense of responding to dynamic changes to the basic rate set in the beacon
Question: should the distinction between mixed capable, managed mixed and unmanaged mixed modes be removed?
Yes 14
No 8
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

21. IBSS Modes Mode Beacon format Legacy exist? Direct communication
Month Year
doc.: IEEE yy/xxxxr0
May 2005
IBSS Modes
Mode
Beacon format
Legacy exist?
Direct communication
Discoverable IBSS
Legacy No
Yes
Mixed
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

22. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Question
Possible change: remove the distinction between discoverable IBSS and mixed modes, replace with dynamic basic rate set updates
Impact
Simplifies state behavior in the STA at the expense of responding to changes in the basic rate set.
But need to reword meaning of basic rate in an IBSS, because this is currently a constant property shared by all STA in an IBSS
Question: remove the distinction between discoverable IBSS and mixed modes?
Yes 6
No 10
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

23. Questions Related to Block Ack
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Questions Related to Block Ack
Background
The TGn Sync proposal includes three optimizations of e block ack:
Compression of bitmap by factor of 16 when fragmentation is not employed
Compression of bitmap to negotiated max number of MSDUs
State reduction – i.e. only keep acknowledgement state from previous aggregation
Implicit Block Ack Request
We would like to test the level of support for simplification and improvement
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

24. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Question
Possible change: remove negotiation of the number of MSDUs in the bitmap at BA setup time?
Impact
In the unfragmented case, there is little impact. But if the transmitter wishes to use fragmentation, then this change reduces throughput by 1-5% (estimate).
Simplification of the proposal by removing the nMSDUs field in the BA setup frames. BA MPDUs are then one of two sizes with a bitmap length of 8 (non-fragmented) or 128 (fragmented) bytes.
Question: should negotiation of the number of MSDUs in the bitmap at BA setup time be removed?
Yes 41
No 4
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

25. Question Possible change: remove BA state restrictions Impact
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Question
Possible change: remove BA state restrictions
The BA state restrictions mean that a STA keeps bitmap state only from the previous aggregate (per TA). This change would restore current e rules for keeping state.
Impact
Depending on the implementation, the change may increase buffer size, but would simplify logic for an implementation that also supports legacy e BA.
There may be a small performance improvement, because the current proposal requires a successful BA be received before a new aggregate can be transmitted to the same RA.
Question: should the BA state restrictions be removed?
Yes 47
No 12
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

26. Question Possible change: remove implicit BAR (block ack request)
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Question
Possible change: remove implicit BAR (block ack request)
When receiving an aggregate containing data sent under the BA ack policy, the responder always generates a BA response.
The alternatives are:
Explicit BAR MPDU
Define an encoding for the Ack Policy of a QoS Data MPDU that carries a block ack request flag
Impact
Gives originator precise control of Ack generation. Removal of the implicit BAR should allow a performance improvement ~5% (rough estimate).
Complexity of the proposal is not significantly altered
Question: should the implicit BAR mechanism be removed?
Yes 52
No 10
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

27. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Question
The challenge: Is e APSD sufficient support for power-saving?
The TGn Sync proposal includes the MMP mechanism that provides for both multiple responses and power-saving of those STA involved in the following sequence, and also 3rd party STA
Could simplify this by removing the Rx Offset and Rx Duration fields. MMP still distinguishes MRA/SRA aggregation and provides uplink scheduling.
Impact
This would have a very slight performance improvement as the MMP frame is sent at a basic rate, and simplifies MMP and its description.
Question: should the the Rx Offset and Duration fields be removed from the MMP frame?
Yes 27
No 25
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

28. Question Possible change: add the RIFS PPDU bursting feature Impact
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Question
Possible change: add the RIFS PPDU bursting feature
RIFS PPDU bursting is a feature that has been identified by commenters in the reasons and cures as a possible improvement of the proposal.
A RIFS PPDU burst would take place within an MMP sequence
A burst of PPDUs separated by RIFS is considered a single PPDU for MAC scheduling purposes
Impact
A PLCP signal field bit is required to indicate ‘end of burst’
Small performance improvement (14us per PPDU)
Very small complexity impact in the MAC and PHY
Question: should the RIFS PPDU bursting feature be added?
Yes 66
No 5
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company

29. References 11-04-0889-04 TGn Sync Proposal Technical Specification
Month Year
doc.: IEEE yy/xxxxr0
May 2005
References
TGn Sync Proposal Technical Specification
TGn Sync Complete Proposal
Adrian Stephens, Intel Corporation, et al
John Doe, Some Company