MAC Partial Proposal for TGn
E N D
Presentation Transcript
MAC Partial Proposal for TGn Nokia Yousuf Saifullah Naveen Kakani Srinivas Sreemanthula Nico van Waes Nico van Waes, Nokia
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
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
Num Rates=3 RATE #1 OffsetRATE-1 # ofSTAs # ofSTAs RATE #2 OffsetRATE-2 OffsetRATE-3 # ofSTAs FCS RATE #3 STAInfo STAInfo STAInfo MRate-ACH MPDU1 MPDU2 Midamble MPDU3 MPDU4 Midamble MPDU5 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. Nico van Waes, Nokia
Exp No Rate (Mbps) M-Rate Scenario App1 users App2 Users % Ch Efficiency Improv. App3 Users % Ch Occupancy Improv. Total Users % Power Saving 126 1 0 1 2 1 11111100000 37.68 27.37 70.07 108 0 1 1 2 2 10011100110 39.98 28.56 57.09 96 0 1 1 2 3 00011111111 29.27 22.64 53.20 72 1 1 0 2 63 0 1 0 1 4 00011111000 30.90 23.60 60.02 54 0 0 1 1 5 11100001111 21.22 17.51 50.36 48 1 0 0 1 6 10101010101 40.00 24.24 47.39 36 0 0 1 1 7 11101010111 33.47 25.08 54.74 24 0 1 0 1 12 1 0 0 1 8 11100110011 24.12 19.43 51.27 6 1 0 0 1 9 11111111100 36.16 26.55 74.41 10 00111111100 36.67 25.75 67.46 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. Nico van Waes, Nokia
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 • With the High Throughput need and new applications (e.g. VoIP), MAC header (36 bytes) is becoming a significant overhead • 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 to 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 • MAC HC procedure is equally applicable for adhoc mode Nico van Waes, Nokia
FrameBody Seq Control QoSControl FrameControl Duration /ID Addr 3 Addr 4 Addr 2 Addr 1 FCS Advantages & Format • Starting compression from the very first MPDU • No overhead in transmitting full header MPDUs during data transfer • Making long lived (life of association) compression context to increase the compression efficiency • Applicable to MPDUs in Frame Aggregation (FA) or outside of FA • Applicable to management frames also. Existing MAC Header Octets: 2 2 6 6 6 2 6 2 n 4 CH-MPDU Octets: 2 1 1 2 2 2 n 4 FrameBody Duration /ID QoSControl Seq Control FrameControl FCS Rsrvd CID Nico van Waes, Nokia
Applications with Gain in MAC Throughput • Application with MSDU size =< 512 bytes show most gain • One application for each MSDU size is selected from TGn Usage Model document. Also, TCP ACK is selected. • Typical case of MAC header with 3 addresses are assumed, instead of max 4 addresses. Simple HC is used for compressing only the addresses. Nico van Waes, Nokia
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. 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 • A-ACK is an enhancement on BA • Differences from BA • A-ACK is sent, by the receiver of an aggregated frame, without any BA Request. • It doesn’t have any issue of receiving BAR and responding it within SIFS • A-ACK is sent indicating status of each received frame only in the aggregation • One A-ACK frame contains status of frames across TIDs. Thus, no need for sending multiple BA per TID. • BA Bitmap is compressed. 128 bytes of bitmap is a significant overhead. • In summary, a responder utilizes one compressed A-ACK frame to acknowledge all the frames received in an aggregation Nico van Waes, Nokia
A-ACK Format X octets 2 octets 2 octets 6 octets 6 octets 2*Num TIDs octets 2 octets 4 octets Frame Control Duration RA TA BA Control Starting Sequence Control BA Bitmap FCS Num MSDUs NumTIDs TID Rsrvd Bits : 4 4 2 6 Repeat “Num TIDs” times. Subsequent BA Control will have 4Rsrvd bits instead of Num TIDs. • “Num TIDs” indicates number of TIDs aggregated in one A-ACK frame • “Num MSDUs” indicates number of MSDUs represented in the BA Bitmap. This is used in calculating BA Bitmap size as follows: • No Fragmentation: “Num MSDUs” indicates number of valid BA MSDU Bitmap bits. BA bitmap is sent at byte boundary, & rest of the bits are don’t care, e.g. a value of 6 indicates a byte of BA MSDU bitmap with only first 7 bits valid. X = (Num MSDU/8+1) octets • Fragmentation: Each MSDU has two bytes of “BA Bitmap”, indicating the status of all possible 16 MPDUs, e.g. a value of 6 indicates 14 bytes of BA MPDU Bitmap. X = (Num MSDU +1) * 2 octets • “BA Bitmap” can take two definitions depending on the use of fragmentation • No Fragmentation: Each bit indicates the status of one MSDU with sequence number= Starting Sequence Number + bit position. • Fragmentation: In this case, it has the same definition as in 802.11e spec. Each MSDU has two bytes of bitmap, indicating the status of all possible 16 MPDUs. Nico van Waes, Nokia
A-ACK Format Considerations • It is likely that MSDU fragmentation will not be used in aggregation. However, a generic A-ACK structure is defined that is used for both fragmentation and/or no-fragmentation case. • No explicit need for negotiating fragmentation/no-fragmentation structure between receiver and originator. Based on fragmented/no-fragmented frames sent/received in aggregation, the originator/receiver decode/encode 1 bit/2 bytes per “Num MSDU” value. • The originator and receiver both know the “Num of TIDs”, “Num of MSDUs” per TID, and fragmentation/no-fragmentation received in an aggregated frame. Thus, can calculate the exact size of A-ACK from receiver, this helps in setting NAV accurately. Nico van Waes, Nokia
Aggregate ACK Benefit Analysis • Assuming • no-fragmentation • 24 MSDUs equally divided in 3 TIDS • A-ACK Overhead • Frame size of an A-ACK = 36 bytes • Normal ACK Overhead • Frame size of on ACK = 14 bytes • For 24 MSDUs, Frame size = 24*14 = 336 • Block ACK Overhead • Overhead due to 3 Block ACK Req/Block ACK = 3 (24 + 152) = 528 • A-ACK saves 89% over Normal ACK • A-ACK saves 93% over Block ACK Nico van Waes, Nokia
Conclusion • 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