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

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

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

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

11. 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 MAC. Thus, it doesn’t have any signaling overhead like Block ACK
Nico van Waes, Nokia

12. Aggregate ACK Benefit Analysis
September 2004
Aggregate ACK Benefit Analysis
A-ACK Overhead
Frame size of an A-ACK = 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 ( ) = 528
A-ACK saves 68% over Normal ACK
A-ACK saves 91% over Block ACK
Nico van Waes, Nokia

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