MAC Partial Proposal for TGn Month 2002 doc.: IEEE 802.11-02/xxxr0 September 2004 MAC Partial Proposal for TGn Nokia Yousuf Saifullah Naveen Kakani Srinivas Sreemanthula Nico van Waes Nico van Waes, Nokia John Doe, His Company

Month 2002 doc.: IEEE 802.11-02/xxxr0 September 2004 Introduction MAC efficiency is an important aspect of the goal of achieving 100 Mbps at the MAC SAP in a robust, economically attractive fashion. Power Efficiency is a critical aspect of making 802.11n suitable for the handset market. The following MAC features are proposed for achieving these goals: Multi data rate frame aggregation Power Efficiency in aggregation MAC Header Compression Aggregate ACK Nico van Waes, Nokia John Doe, His Company

Multi Data Rate Frame Aggregation September 2004 Multi Data Rate Frame Aggregation STAs use different data rates due to different radio environment. Performing aggregation on multi rate increases the usability of aggregation. Thus, increases the data throughput. Experiment results show improvement is Channel Efficiency (Data Throughput), Channel Occupancy, and Power Savings, over Single Rate Aggregation. Introduce Num Rates, RATE #x, and Offset RATE-x in Aggregation Control Header (ACH). Could be introduced in the PHY or MAC Header. Nico van Waes, Nokia

Multi Data Rate Frame Aggregation September 2004 Multi Data Rate Frame Aggregation Codecs need to be emptied and reset between two different MCS. This interruption (one OFDM symbol) is filled with single symbol Midamble for improvement of channel estimation. Proposed structure allows flexible insertion of different size preamble (including full preamble copy) in rare cases when MCS change requires this. RATE #1 # of STAs Offset RATE-1 STA Info Num Rates=3 FCS MPDU2 Midamble MPDU1 MPDU4 MPDU3 MPDU5 MRate-ACH #2 Offset RATE-2 #3 Offset RATE-3 Nico van Waes, Nokia

M-Rate Aggregation Performance Results September 2004 M-Rate Aggregation Performance Results Experiments are run with a a mix of users at different rates and different application traffic mix Table-1: Appl User 1, MSDU=50; Appl User 2, MSDU=120; Appl User 3, MSDU=1500 bytes; Table-2 shows an M-Rate scenario with results. Each bit under M-Rate Scenario indicates the inclusion (1) or exclusion (0) of the data rate rows in Table-1. Top row is indicated by MSB. Exp No 1 2 3 4 5 6 7 8 9 10 M-Rate Scenario 11111100000 10011100110 00011111111 00011111000 11100001111 10101010101 11101010111 11100110011 11111111100 00111111100 % Ch Efficiency Improv. 37.68 39.98 29.27 30.90 21.22 40.00 33.47 24.12 36.16 36.67 % Ch Occupancy Improv. 27.37 28.56 22.64 23.60 17.51 24.24 25.08 19.43 26.55 25.75 % Power Saving 70.07 57.09 53.20 60.02 50.36 47.39 54.74 51.27 74.41 67.46 Rate (Mbps) 126 108 96 72 63 54 48 36 24 12 6 App1 users 1 App2 Users App3 Users Total Users 2 Nico van Waes, Nokia

September 2004 Power Efficiency Power efficiency is important for small handheld devices. These devices will be an important segment of WLAN High Throughput products. Power efficiency should not be compromised in Frame Aggregation. Provide power efficiency by placing MPDU lengths along with the receiving STA’s MAC address in the ACH. Doesn’t compromise MAC throughput efficiency A STA reads ACH determines the position of its MPDUs and reads them only without reading MPDUs of other STAs. Nico van Waes, Nokia

MAC Header Compression September 2004 MAC Header Compression With the High Throughput need and new applications (e.g. VoIP), MAC header (36 bytes) is becoming a significant overhead Nokia proposes a very efficient MAC Header Compression method by Starting compression from the very first MPDU, Making long lived compression context, and equally applicable on MPDUs in Frame Aggregation (FA) MAC Header Compression Procedure An AP creates a mapping between 1 byte unique Compression ID (CID) and the set of addresses in the MAC Header (Addr 1 through 4). AP establishes the same CID in the non-AP STA by introducing “CID Association” procedure. For example: AP and STA exchange a CID Association Request followed by ACK. The CID is established prior to exchanging any data frames AP and STA start exchanging Compressed Header (CH) MPDU Nico van Waes, Nokia

Compressed Header MPDU Format September 2004 Compressed Header MPDU Format MAC HC procedure is applicable for adhoc mode CID has to be unique between two STAs performing MAC HC BSSID (infra) is added in first frame (FA) to remove ambiguity in cases where same CID is used in neighboring APs for different STAs RA (adhoc) is added in the first frame to remove ambiguity between two pairs of STAs Octets: 2 2 6 6 6 2 6 2 n 4 Frame Control Duration /ID Addr 1 Seq Control Addr 4 QoS Control Frame Body FCS Addr 2 Addr 3 Existing MAC Header Octets: 2 2 1 2 2 n 4 Frame Control Duration /ID Seq Control QoS Control Frame Body CID FCS CH-MPDU Octets: 2 2 2 1 2 2 n 4 Frame Control Duration /ID BSSID /RA Seq Control QoS Control Frame Body CID FCS CH-MPDU with BSSID/RA Nico van Waes, Nokia

MAC HC Benefit Analysis September 2004 MAC HC Benefit Analysis Assumptions 5 individual MPDUs, each in “n” aggregated frames Only 3 MAC Header address fields compressed Without MAC HC MAC Header bytes in n aggregated frames are n* 5*36. For n=10, MAC header bytes are 1800. With MAC HC One time signaling overhead is 41 bytes: CID Establishment Request is 27 bytes and ACK is 14 bytes. For each 5 MPDUs in one aggregated frame First 2 are “CH-MPDU with AP MAC Address”. Robustness assumption: 2 such MPDUs sent. Each MPDU saves (12-1) bytes, and 2 MPDUs save 22 bytes. Next 3 MPDUs (CH-MPDU) have savings of 3*(18-1) = 51 bytes Total savings in one aggregated frame: 22+51= 73 bytes For “n” aggregated frames: -41+ n*73; For n=10, Total savings = 689 bytes This provides 38% savings in the MAC header bytes over no MAC header compression in 50 MPDUs. The higher the number of MPDUs exchanged the more will be the savings. Nico van Waes, Nokia

September 2004 ACK aggregation Frame Aggregation (FA) feature sends multiple MPDUs together. For the MPDUs needing ACK, the receiving STAs could send either Block ACK or Normal ACK in the reverse link. There is significant redundancy in using both, even if FA is used in the reverse link. Normal ACK adds considerable overhead in the traffic, even in an aggregated frame, since an ACK frame (14 bytes) is sent for each MPDU A Block ACK frame size is 152 bytes. It has additional signaling overhead needed for adding, requesting, and deleting Block ACK. Moreover, Block ACK is defined on a TID basis. An aggregated frame may contain MPDUs with different TIDs for a STA. This would still result into multiple Block ACK Req and Block ACK per STA. Nico van Waes, Nokia

Solution: Aggregate ACK September 2004 Solution: Aggregate ACK Aggregate-ACK (A-ACK) retains frame format as Normal ACK but adds 2 additional fields to acknowledge individual MPDU within an aggregated frame A-ACK follows the Normal ACK rules in 802.11 MAC. Thus, it doesn’t have any signaling overhead like Block ACK Nico van Waes, Nokia

Aggregate ACK Benefit Analysis September 2004 Aggregate ACK Benefit Analysis A-ACK Overhead Frame size of an A-ACK = 14 + 1 + n*3. For n=10, overhead = 45 bytes Normal ACK Overhead Frame size of on ACK = 14 bytes For n MPDUs, Frame size = n*14. For n=10, overhead = 140 bytes Block ACK Overhead Assume n MPDUs in 3 TIDs, requiring Block ACK. Exclude ADD/DEL BA signaling overhead. Overhead due to 3 Block ACK Req/Block ACK = 3 (24 + 152) = 528 A-ACK saves 68% over Normal ACK A-ACK saves 91% over Block ACK Nico van Waes, Nokia

Aggregate ACK Benefit Analysis September 2004 Aggregate ACK Benefit Analysis The proposed MAC features substantially improve MAC throughput, as well as power efficiency, which is critical for handset applications The features can be introduced easily by modifying/enhancing the existing procedures and frame structures Analysis has been provided to show the benefit Nico van Waes, Nokia