1. Joint Proposal MAC Report
November 2005
doc.: IEEE /1095r0
November 2005
Joint Proposal MAC Report
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
Fischer (Broadcom), Stephens (Intel) et. al.
Fischer (Broadcom), Stephens (Intel) et. al.

2. November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

3. November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

4. November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

5. November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

6. November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

7. November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

8. November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

9. November 2005
Abstract
This document provides a detailed explanation of the current (as of ) status of the Joint Proposal MAC draft
Fischer (Broadcom), Stephens (Intel) et. al.

10. MAC Feature Architecture
November 2005
doc.: IEEE /1095r0
November 2005
MAC Feature Architecture
Fischer (Broadcom), Stephens (Intel) et. al.
Fischer (Broadcom), Stephens (Intel) et. al.

11. A-MSDU Mechanism to provide enhanced efficiency at the MAC layer
November 2005
A-MSDU
Mechanism to provide enhanced efficiency at the MAC layer
Frame Format
Length limitations
STA Capability
(Mandatory by all HT STA)
Fischer (Broadcom), Stephens (Intel) et. al.

12. A-MSDU Signaling QOS Control field bit 7 Bits 0-3 Bit 4 Bit 5-6 Bit 7
November 2005
A-MSDU Signaling
Bits
0-3
Bit 4
Bit 5-6
Bit 7
Bits 8-15
TID
EOSP
TXOP /
Queue
Size
Ack
Policy
A-MSDU
Present
TXOP limit
TXOP duration
QAP PS Buffer size
Queue Size
QOS Control field bit 7
Indicates the presence/absence of A-MSDU
Bit 7 is formerly reserved
Valid in DATA type/QOS Subtype frames:
QoS Data
QoS Data+CF-Ack
QoS Data+CF-Poll
QoS Data+CF-Ack+CF-Poll
Fischer (Broadcom), Stephens (Intel) et. al.

13. A-MSDU Frame Format Efficient Structure
November 2005
A-MSDU Frame Format
Efficient Structure
MSDUs of the same TID can be aggregated
MSDUs with differing SA/DA can be aggregated
Fischer (Broadcom), Stephens (Intel) et. al.

14. Subframe Header Fields
November 2005
A-MSDU DA/SA Fields
Subframe Header Fields
To DS
From DS
Address 1
Address 2
Address 3
Address 4 DA SA
BSSID
Not present
Reserved 1 RA TA
Fischer (Broadcom), Stephens (Intel) et. al.

15. A-MSDU limits Selectable STA capability: Maximum A-MSDU length
November 2005
A-MSDU limits
Selectable STA capability:
Maximum A-MSDU length
3839 bytes (default)
7935 bytes
Signaled in HT Capabilities Element
(Coming soon to a draft specification near you)
Fischer (Broadcom), Stephens (Intel) et. al.

16. A-MSDU Capability Mandatory feature of HT STA, because:
November 2005
A-MSDU Capability
Mandatory feature of HT STA, because:
Efficiency enhancement is significant
TGn PAR throughput requirement needs to be met
A-MSDU provides one of the simplest mechanisms available to assist in achieving the stated requirement
Provides value to many, but not all types of flows outlined in the simulation scenarios
Other benefits:
Reduced ISR load at receiver
Fischer (Broadcom), Stephens (Intel) et. al.

17. Value of A-MSDU – 1 November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

18. Value of A-MSDU - 2 November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

19. PSMP Power Save Multi Poll Properties of this mechanism: Frame Format
November 2005
PSMP
Power Save Multi Poll
Properties of this mechanism:
Minimizes wake times of power save devices
Enhances efficiency of MAC operations for power save devices
(Provides benefit to all STA in the BSS by having PS STA operate more efficiently)
Enhances network capacity by allowing the AP to statistically multiplex the retries of multiple STA during the allocated service interval
Avoids forcing the AP to make decisions trading STA power-saving for network capacity
Frame Format
Protocol rules
Fischer (Broadcom), Stephens (Intel) et. al.

20. PSMP Frame Format November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

21. PSMP Sequence November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

22. PSMP MTBA MTBA Multi-TID BA
November 2005
PSMP MTBA
MTBA
Multi-TID BA
Allows for single frame to respond to (implicit) BAR for multiple TID
Fischer (Broadcom), Stephens (Intel) et. al.

23. MTBA Frame Format November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

24. PSMP with MTBA MTBA efficiently carries BA for multiple TIDs
November 2005
PSMP with MTBA
MTBA efficiently carries BA for multiple TIDs
PSMP schedules when a STA receives and when it may transmit.
DL Acknowledgement scheduled in the uplink & vice versa
UL data acknowledged by following PSMP sequence
Fischer (Broadcom), Stephens (Intel) et. al.

25. November 2005
PSMP Rules
AP only includes STA within PSMP if STA is capable, as advertised in HT Capabilities
AP obeys minimum DLT2ULT. Value is TBD.
AP may set bits in “TID set” field to provide recommendation to STA for use of ULT
AP uses EOSP bit to signal end of DATA delivery to STA
i.e. permission to return to sleep
Ack Policy setting in DLT frames is “no explicit acknowledgement”
Within PSMP, implies ACK/BA to appear in ULT vs immediate
Service Interval granularity
Advertised by AP to allow STA to determine appropriate TSPEC service interval request to match AP PSMP service intervals
PSMP may be used in context of U-APSD or S-APSD
Fischer (Broadcom), Stephens (Intel) et. al.

26. PSMP resource request example
November 2005
PSMP resource request example
Fischer (Broadcom), Stephens (Intel) et. al.

27. PSMP retransmission example
November 2005
PSMP retransmission example
Fischer (Broadcom), Stephens (Intel) et. al.

28. Reverse Direction (RD)
November 2005
Reverse Direction (RD)
Reverse Direction Protocol
Allows a STA to share its TXOP with another STA
Significant benefit if this reduces the number of channel access attempts
Some benefit from aggregating BA and Data together
Grantor Rules
Grantee Rules
Signaling TBD
Pending further discussions regarding HT Control Field
Fischer (Broadcom), Stephens (Intel) et. al.

29. RD Basic Rules Transmission by initiator Response
November 2005
RD Basic Rules
Transmission by initiator
Response
An aggregate or non-aggregate PPDU containing one or more unicast frames addressed to the receiver with the RDG field set to 1.
A response burst consisting of one or more aggregated or non-aggregated PPDUs starting a SIFS after the end of the initiator's transmission, and lasting no longer than the RDG duration (less a SIFS).
The PPDUs of a response burst shall be separated by no more than SIFS.
Fischer (Broadcom), Stephens (Intel) et. al.

30. November 2005
RD Initiator rules (1)
The initiator shall ensure that its PPDU transmission and any expected/granted responses fit entirely within the current TXOP (this is implicit in e).
The responder shall ensure that its PPDU transmission(s) and any expected responses fit entirely within the RDG duration.
When the initiator sets the RDG flag to 1, it shall set the AC Constraint field according to the AC of the current EDCA TXOP
For HCCA, the initiator shall set the AC Constraint field to the value 4 (any TID).
The responder may only transmit Data MPDUs of the same AC as the AC Constraint Field (for values 0-3) or of any TID (for value 4).
Fischer (Broadcom), Stephens (Intel) et. al.

31. November 2005
RD Initiator Rules (2)
The responder shall not transmit any MPDUs that are not addressed to the initiator (RA).
Subject to TXOP constraints, after transmitting a PPDU containing a reverse direction grant, the initiator may transmit its next PPDU a minimum of a SIFS after receiving a response PPDU with the "More PPDU" flag set to 0.
I.e. Initiator still owns TXOP if Grantee is done and TXOP limit has not been exceeded
PIFS recovery rule for GRANTOR
I.e. if responder does not respond, then Grantor may invoke recovery
Fischer (Broadcom), Stephens (Intel) et. al.

32. November 2005
RD Responder rules
The first PPDU of any response burst shall contain all response MPDUs (e.g. Ack, BA) as required to respond to the previous PPDU.
Only the last PPDU of a response burst may contain an MPDU requiring an immediate response (e.g. Normal ack, BA with immediate response).
The presence of any frame in a response PPDU requiring an immediate response is an implicit indication of "More PPDU==0".
If the transmission of a frame in a response PPDU requiring an immediate response fails, the responder has to wait until it has the next opportunity to transmit to the initiator before it can retry the transmission.
I.e. initiator owns the TXOP and all rights to recovery
Fischer (Broadcom), Stephens (Intel) et. al.

33. RD Example Exchange November 2005
Fischer (Broadcom), Stephens (Intel) et. al.

34. November 2005
Value of RD – 1
Fischer (Broadcom), Stephens (Intel) et. al.

35. November 2005
Value of RD – 2
Fischer (Broadcom), Stephens (Intel) et. al.

36. References 11-05/1095r01 “Joint Proposal MAC Specification”
November 2005
References
11-05/1095r01
“Joint Proposal MAC Specification”
Fischer (Broadcom), Stephens (Intel) et. al.