1. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 1 Joint Proposal MAC Report Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-11-14 Authors:

2. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 2

3. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 3

4. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 4

5. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 5

6. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 6

7. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 7

8. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 8

9. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 9 Abstract  This document provides a detailed explanation of the current (as of 11/14/2005) status of the Joint Proposal MAC draft

10. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 10 MAC Feature Architecture

11. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 11 A-MSDU  Mechanism to provide enhanced efficiency at the MAC layer ■ Frame Format ■ Length limitations ■ STA Capability (Mandatory by all HT STA)

12. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 12 A-MSDU Signaling  QOS Control field bit 7 ■ Indicates the presence/absence of A-MSDU ■ Bit 7 is formerly reserved ■ QOS control field exists in DATA type/QOS Subtype frames: QoS Data QoS Data+CF-Ack QoS Data+CF-Poll QoS Data+CF-Ack+CF-Poll Bits 0-3 Bit 4Bit 5-6Bit 7Bits 8-15 TIDEOSP TXOP / Queue Size Ack Policy A-MSDU Present TXOP limit TXOP duration QAP PS Buffer size Queue Size

13. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 13 A-MSDU Frame Format Efficient Structure MSDUs of the same TID can be aggregated MSDUs with differing SA/DA can be aggregated

14. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 14 A-MSDU DA/SA Fields Subframe Header Fields To DSFrom DSAddress 1 Address 2 Address 3 Address 4 DASA 00DASABSSIDNot present Reserved 01DABSSID Not present ReservedSA 10BSSIDSABSSIDNot present DAReserved 11RATABSSID ReservedDASA

15. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 15 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)

16. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 16 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

17. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 17 Value of A-MSDU – 1

18. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 18 Value of A-MSDU - 2

19. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 19 PSMP  Power Save Multi Poll ■ Mechanism to: Minimize wake times of power save devices Enhance efficiency of MAC operations for power save devices –(Provides benefit to all STA in the BSS by having PS STA operate more efficiently) ■ Frame Format ■ Protocol rules

20. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 20 PSMP Frame Format

21. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 21 PSMP Sequence

22. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 22 PSMP MTBA  MTBA ■ Multi-TID BA ■ Allows for single frame to respond to (implicit) BAR for multiple TID

23. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 23 MTBA Frame Format

24. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 24 PSMP with MTBA

25. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 25 PSMP Rules  AP only includes STA within PSMP if STA is capable, as advertised in HT Capabilities  AP obeys minimum DLT2ULT per STA ■ Each STA advertises minimum DLT2ULT  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

26. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 26 PSMP resource request example

27. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 27 PSMP retransmission example

28. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 28 RD  Reverse Direction Protocol ■ Allows a STA to share its TXOP with another STA ■ Grantor Rules ■ Grantee Rules ■ Signaling TBD Pending further discussions regarding HT Control Field

29. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 29 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.

30. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 30 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 802.11e).  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).

31. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 31 RD Initiator Rules (2)  The responder shall not transmit any MPDUs that are not addressed to the initiator.  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

32. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 32 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

33. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 33 RD Example Exchange

34. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 34 Value of RD – 1

35. doc.: IEEE 802.11-05/1165r0 Submission November 2005 Fischer (Broadcom), Stephens (Intel) et. al.Slide 35 Value of RD – 2