1. MAC Partial Proposal for TGn
Month 2002
doc.: IEEE /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

2. Month 2002
doc.: IEEE /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 n 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

3. 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

4. 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

5. 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
% 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

6. 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

7. 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
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

8. Advantages & Format Starting compression from the very first MPDU
September 2004
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
Frame Control
Duration
/ID
Addr 1
Seq
Control
Addr 4
QoS Control
Frame Body
FCS
Addr 2
Addr 3
CH-MPDU
Octets: 2 1 1 2 2 2 n 4
Frame Control
Duration
/ID
Seq
Control
QoS Control
Frame Body
Rsrvd
CID
FCS
Nico van Waes, Nokia

9. Applications with Gain in MAC Throughput
September 2004
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

10. 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. 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

11. Solution: Aggregate ACK
September 2004
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

12. A-ACK Format
September 2004
2 octets
2 octets
6 octets
6 octets
2*Num TIDs octets
2 octets
X octets
4 octets
Frame
Control
Duration RA TA
BA Control
Starting
Sequence Control BA
Bitmap
FCS
Num TIDs
TID
Rsrvd
Num MSDUs
Bits :
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 e spec. Each MSDU has two bytes of bitmap, indicating the status of all possible 16 MPDUs.
Nico van Waes, Nokia

13. A-ACK Format Considerations
September 2004
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

14. Aggregate ACK Benefit Analysis
September 2004
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 ( ) = 528
A-ACK saves 89% over Normal ACK
A-ACK saves 93% over Block ACK
Nico van Waes, Nokia

15. September 2004
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