1. 802.11 TGs MAC Enhancement Proposal
July 2005
doc.: IEEE /0608r0
July 2005
TGs MAC Enhancement Proposal
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Rakesh Taori, et al., Samsung
Rakesh Taori, et al., Samsung

2. July 2005
doc.: IEEE /0608r0
July 2005
Abstract
This document describes Samsung’s proposal to TGs, which deals with MAC enhancements for facilitating high performance.
A common channel framework is introduced that makes it possible for devices with single radio interfaces to benefit from multi-channel MAC.
Documents relevant to this proposal
- IEEE /0589r0
- IEEE /0608r0 (this document)
Rakesh Taori, et al., Samsung
Rakesh Taori, et al., Samsung

3. Per node bandwidth degrades as # of nodes increases
July 2005
Why Multi-Channel? N1 N2 N3 N4 N1 N2 N3 N4 N5 N6 N7 N8 N5 N6 N7 N8
Multiple channels can be dynamically allocated to node pairs (or groups) enabling simultaneous transmission
Per node bandwidth degrades as # of nodes increases
Adding multi-channel capabilities can provide a good basis for enhancing performance
Rakesh Taori, et al., Samsung

4. Multi-Channel MAC Based on Common Channel
July 2005
Multi-Channel MAC Based on Common Channel
MP3
MP1
MP4
MP2
RTS
DIFS
Switching Delay
CTS
SIFS
RTS
DIFS
CTS
SIFS
CTS
SIFS
DIFS
DATA
Switching Delay
Common Channel
RTS
ACK
SIFS
DATA
Switching Delay
DIFS
Data Channel n
Data Channel m
ACK
SIFS
Rakesh Taori, et al., Samsung

5. Issues in Multi-Channel MAC for Single Radio Interfaces
July 2005
Issues in Multi-Channel MAC for Single Radio Interfaces
Coping with missing control information when an MP is communicating with another MP
Coping with missing control information when an MAP is communicating with its STAs
Establishing contact with an arbitrary MP
MP1
MP2
MAP1
MP2
STAs
MP3
Rakesh Taori, et al., Samsung

6. Single Radio Support: How?
July 2005
Single Radio Support: How?
Rakesh Taori, et al., Samsung

7. July 2005
The Common Channel (CC) Framework for Supporting Single Radio Interface
Rakesh Taori, et al., Samsung

8. Coordination Mechanism on the Common Channel
July 2005
Coordination Mechanism on the Common Channel
All MPs tune to the CC at the start of CCW
This facilitates two MPs to get connected
MPs can stay tuned to the CC beyond CCW duration
Channel utilization states are reset prior to CCW
P is the period with which CCW occurs
MPs should initiate transmission that end before P
P and CCW are carried in beacon frames
Rakesh Taori, et al., Samsung

9. Assigning and distributing P and CCW
July 2005
Assigning and distributing P and CCW
Upon power-on, an MP scans for beacon frames
If no beacon frames are found, it shall transmit beacon frames with P and CCW.
Each MP carries an offset () in addition to P and CCW
 is the time elapsed after P (in modulo P)
MPs relay P and CCW, and compute their own 
Rakesh Taori, et al., Samsung

10. MAC mechanism for the CC
July 2005
MAC mechanism for the CC
Using RTS, the transmitter suggests a data channel.
Receiver accepts/declines suggested channel using CTS.
After a successful RTS and CTS exchange, the transmitter and receiver switch to the data channel.
When all available data channels are used up
Option 1: Wait until next CCW
Option 2: Transmit on CC
(Both options are simulated)
Rakesh Taori, et al., Samsung

11. Accommodating Legacy Behavior
July 2005
Accommodating Legacy Behavior
CC can be used for data transmission.
An MAP with a single radio may use CC for WDS as well as BSS traffic
Dynamic data channel selection is restricted to MAP-MAP, MAP-MP, and MP-MP
CCA is performed for DIFS time after switching
Rakesh Taori, et al., Samsung

12. July 2005
Simulation Results
Rakesh Taori, et al., Samsung

13. Simulation Setup All nodes are in radio range CCW and P are known
July 2005
Simulation Setup
All nodes are in radio range
CCW and P are known
One channel is reserved for CC (known a priori)
.11a parameters
up to 8 data channels
24Mbit/s (DATA/ACK), 6Mbit/s (RTS/CTS)
.11b parameters
up to 2 data channels
11Mbit/s (DATA/ACK), 1Mbit/s (RTS/CTS)
Fixed destination
Channel switching delay is 100s
Rakesh Taori, et al., Samsung

14. Scenario 1: Decentralized WDS traffic
July 2005
Scenario 1: Decentralized WDS traffic
Rakesh Taori, et al., Samsung

15. Topologies for Scenario 1
July 2005
Topologies for Scenario 1
MP1
MP3
MP5
MP1
MP3
MP1
MP2
MP4
MP6
MP2
MP4
MP2
3 Pairs
2 Pairs
1 Pairs
MP6
MP4
MP8
MP2
MP4
MP5
4 Pairs
MP3
MP7
MP1
MP3
MP2
MP1
MP9
MP10
MP15
MP11
MP7
MP5
MP13
MP16
MP12
MP8
MP6
MP14
8 Pairs
Rakesh Taori, et al., Samsung

16. Aggregate throughput (.11a) as a function of #communicating MP pairs
July 2005
Aggregate throughput (.11a) as a function of #communicating MP pairs
Channel Utilization (%)
Throughput (Mbit/s)
Number of MP Pairs
SC throughput: ~16.05 Mbit/s
CC: Common Channel Utilization
DC: Data Channel Utilization
Rakesh Taori, et al., Samsung

17. Fixed #MP pairs, Variable #channels
July 2005
Fixed #MP pairs, Variable #channels
Throughput (Mbit/s)
#MP-pairs is fixed to 4
Number of Channels (including CC)
Rakesh Taori, et al., Samsung

18. Channel Utilization Statistics
July 2005
Channel Utilization Statistics
CC Channel Utilization (%)
Number of Channels (including CC)
Rakesh Taori, et al., Samsung

19. Aggregate throughput (.11b) as a function of #communicating MP pairs
July 2005
Aggregate throughput (.11b) as a function of #communicating MP pairs
Throughput (Mbit/s)
Channel Utilization (%)
Number of MP Pairs
CC: Common Channel Utilization
DC: Data Channel Utilization
SC throughput: ~4.75 Mbit/s
Rakesh Taori, et al., Samsung

20. July 2005
Impact of allowing MPs to perform data transmission on the CC (.11b case)
Throughput (Mbit/s)
Number of MP Pairs
Rakesh Taori, et al., Samsung

21. Adding STAs in Scenario 1
July 2005
Adding STAs in Scenario 1
Rakesh Taori, et al., Samsung

22. Scenario 1 with STAs July 2005 STA STA STA MP2 STA STA MP1 STA MAP1
(6 MPs, 2 STAs)
(4 MPs, 4 STAs)
MP2
STA
STA
STA
STA
STA
MP1
STA
MAP1
MAP1
MAP2
MP7
MAP2
STA
STA
STA
MP8
STA
STA
STA
(4 MPs, 4 STAs)
(0 MP, 8 STAs)
Rakesh Taori, et al., Samsung

23. Impact of Adding STAs (.11a)
July 2005
Impact of Adding STAs (.11a)
Rakesh Taori, et al., Samsung

24. .11a Channel Utilization (with STAs)
July 2005
.11a Channel Utilization (with STAs)
CC Channel Utilization (%)
Number of Channels
(MP, STA)
Rakesh Taori, et al., Samsung

25. Scenario 2: BSS-Heavy Traffic
July 2005
Scenario 2: BSS-Heavy Traffic
Rakesh Taori, et al., Samsung

26. Simulation Setup for Scenario 2
July 2005
Simulation Setup for Scenario 2
Rakesh Taori, et al., Samsung

27. Simulation Configuration for Scenario 2
July 2005
Simulation Configuration for Scenario 2
1 or 2 MAPs
2 or 4 STAs per MAP
MAPs switch channels only after CCW
With and without (Virtual) CTS-to-self
Rakesh Taori, et al., Samsung

28. Results of Scenario 2 July 2005 11a (1Ch: 16.05Mbit/s)
11b (1Ch: 4.76Mbit/s)
Rakesh Taori, et al., Samsung

29. Simulation Results Show
July 2005
Simulation Results Show
Significant performance gains can be obtained without the need to increase the number of radios
Throughput increases with number of channels
Impact on STAs is limited
STAs transmit/receive on common channel
MPs need CC for RTS/CTS exchange
After succesful RTS/CTS exchange CC is free for STAs
Framework can accommodate several traffic scenarios
Decentralized WDS traffic (with and without STAs)
BSS-heavy (during P, after CCW, same as UCG of SEE-Mesh proposal)
WDS-heavy (not shown using simulations)
Rakesh Taori, et al., Samsung

30. Hooks We Need Common Channel (CC) Scheduling
July 2005
Hooks We Need
Common Channel (CC)
Scheduling
Will enable single radio support
Add Beacon IE containing P, CCW and 
Upper bound on switching time
Will enable efficient multi-channel operation
Modifications to RTS and CTS
Rakesh Taori, et al., Samsung

31. Summary Multi-Channel MAC is proposed for enhancing MAC performance.
July 2005
Summary
Multi-Channel MAC is proposed for enhancing MAC performance.
A common channel framework is proposed for facilitating single radio interface implementations.
Simulation results in support of the proposal are presented
Rakesh Taori, et al., Samsung

32. July 2005
Backup Slides
Rakesh Taori, et al., Samsung

33. Channel Utilization Statistics (.11b case)
July 2005
Channel Utilization Statistics (.11b case)
CC Channel Utilization (%)
Number of MP Pairs
Rakesh Taori, et al., Samsung

34. Impact of Adding STAs in Scenario 1 (.11b)
July 2005
Impact of Adding STAs in Scenario 1 (.11b)
Rakesh Taori, et al., Samsung

35. .11b Channel Utilization with STAs in Scenario 1
July 2005
.11b Channel Utilization with STAs in Scenario 1
CC Channel Utilization (%)
Number of Channels
(MP, STA)
Rakesh Taori, et al., Samsung

36. WDS Heavy Traffic Pattern
July 2005
WDS Heavy Traffic Pattern
Suitable for MP clustering
Management frame
smaller switching overhead
Similar to UCG of SEE-Mesh proposal but not requiring multiple radio interfaces
Rakesh Taori, et al., Samsung