September 2005 Performance Evaluation of the CCC MMAC Protocol for 802.11s Mesh Networks Date: 2005-09-12 Authors: Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Avaya Labs, Polytechnic University

September 2005 Performance Evaluation of the CCC MMAC Protocol for 802.11s Mesh Networks Mathilde Benveniste, Avaya Labs Research benveniste@ieee.org Jeffrey Zhifeng Tao, Polytechnic University jefftao@photon.poly.edu Avaya Labs, Polytechnic University

Outline Overview of IEEE 802.11s September 2005 Outline Overview of IEEE 802.11s Common Control Channel (CCC) MMAC Protocol Performance Evaluation Conclusion and Discussion Avaya Labs, Polytechnic University

IEEE 802.11s: Mesh Networking September 2005 IEEE 802.11s: Mesh Networking Major applications: Public access Enterprise network Home network Military/Public Security Emergency/Rescue . . . Router BSS 1 BSS 2 BSS 3 Internet Mesh networking Portal Router BSS 1 BSS 2 BSS 3 Internet Legacy WLAN deployment Wireless Avaya Labs, Polytechnic University

CCC MMAC Framework References: IEEE 802.11-05/707, 05/880 September 2005 CCC MMAC Framework References: IEEE 802.11-05/707, 05/880 Two logical channels Common control channel (CC) One or multiple mesh traffic (MT) channels Agnostic to the number of physical radios Single radio Both CC and MT share the same physical radio/frequency band Multiple radios A radio is dedicated to control channel Other radios carry multiple mesh traffic channels Dynamic channel assignment The handshake at the control channel can readily achieve dynamic channel assignment Avaya Labs, Polytechnic University

CCC MMAC: Illustration September 2005 CCC MMAC: Illustration Reserve MT channel 2 Reserve MT channel 1 MRTS MCTS MRTS MCTS MRTS MCTS MRTS Reserve MT channel 1 MCTS Reserve MT channel 3 CC 2437 GHz MT 1 MTXOP MTXOP 5220 GHz MT 2 MTXOP 5260 GHz MT 3 MTXOP 5300 GHz time Frequency Avaya Labs, Polytechnic University

Performance Evaluation September 2005 Performance Evaluation Study 1: Saturation load Primary objective: demonstrate the effect of PHY rate and TXOP size on network goodput, under the saturation load Study 2: Queueing and access delay – important for QoS Primary objective: demonstrate the effect of the CCC protocol under a fixed offered load Avaya Labs, Polytechnic University

Collected Statistics Goodput Delay September 2005 Defer, Backoff, Transmit, Retransmit Buffer MSDU from LLC T0 T3 T1 Transmitter Receiver Wireless Channel Queueing Delay (T1 – T0) Media Access (T2 – T1) to LLC T2 Goodput PHY Hdr MAC Hdr Goodput Payload bits correctly received at the intended recipient per unit time Excludes the PHY and MAC headers Delay Queueing delay Channel access delay MSDU: MAC Service Data Unit PPDU: PHY Protocol Data Unit Avaya Labs, Polytechnic University

Channel Configuration September 2005 Simulation Scenarios Simulation Scenario Channel Configuration EDCF Control and data frames share the same channel CCC 2 MT 1 control channel, 2 data channels … CCC n MT 1 control channel, n data channels Radios: 1 transceiver and 1 receiver Avaya Labs, Polytechnic University

Study 1: Saturation load September 2005 Study 1: Saturation load Avaya Labs, Polytechnic University

Simulation Settings September 2005 Case I: 4 traffic streams Constant payload size: 1500 bytes Exponential frame inter-arrival Physical layer rates DATA/ACK @ 24Mbps and 54Mbps MRTS/MCTS @ 6Mbps Access parameters CWmin 32; CWmax 1024; AIFS DIFS TXOP sizes 10 and 15 frames Avaya Labs, Polytechnic University

Goodput -- 15 frames/TXOP September 2005 Goodput -- 15 frames/TXOP EDCF (1 MT) CCC (2 MTs) (3 MTs) (4 MTs) Goodput increases linearly with the number of data channels The control channel is not a bottleneck Control channel at 6 Mbps; 4 traffic streams Avaya Labs, Polytechnic University

Goodput -- 10 frames/TXOP September 2005 Goodput -- 10 frames/TXOP EDCF (1 MT) CCC (2 MTs) (3 MTs) (4 MTs) Shorter TXOP increased control traffic by 50% Goodput still increases linearly with the number of data channels The control channel is not a bottleneck Control channel at 6 Mbps; 4 traffic streams Avaya Labs, Polytechnic University

Goodput – no TXOP Overstressing the control channel! September 2005 Goodput – no TXOP Overstressing the control channel! EDCF (1 MT) CCC (2 MTs) (3 MTs) (4 MTs) Without TXOPs, control traffic increases by 1,000% Goodput still increases Typically, traffic in a large mesh will be forwarded as TXOPs 15.36 EDC 27.32 2MT 40.02 45.84 4MT Avaya Labs, Polytechnic University

Summary of Goodput Results September 2005 Summary of Goodput Results 10 frames/TXOP Number of MT channels Data PHY rate @ 24Mbps Data PHY rate @ 54Mbps 1 (i.e., EDCF) 20.2 Mbps 39.3 Mbps 2 39.0 Mbps 73.3 Mbps 3 58.6 Mbps 109.5 Mbps 4 78.0 Mbps 143.8 Mbps 15 frames/TXOP Number of MT channels Data PHY rate @ 24Mbps Data PHY rate @ 54Mbps 1 (i.e., EDCF) 20.6 Mbps 40.2 Mbps 2 39.6 Mbps 75.3 Mbps 3 59.6 Mbps 112.6 Mbps 4 79.2 Mbps 149.4 Mbps MT channel: mesh traffic channel Control channel at 6 Mbps; 4 traffic streams Avaya Labs, Polytechnic University

Simulation Settings September 2005 Case I: 8 traffic streams Constant payload size: 1500 bytes Exponential frame inter-arrival Physical layer rates DATA/ACK @ 24Mbps and 54Mbps MRTS/MCTS @ 6Mbps Access parameters CWmin 32; CWmax 1024; AIFS DIFS TXOP sizes 10 and 15 frames Avaya Labs, Polytechnic University

Goodput -- 15 frames/TXOP September 2005 Goodput -- 15 frames/TXOP EDCF (1 MT) CCC (2 MTs) (4 MTs) (6 MTs) (8 MTs) Goodput increases linearly with the number of data channels The control channel is not a bottleneck Control channel at 6 Mbps; 8 traffic streams Avaya Labs, Polytechnic University

Goodput -- 10 frames/TXOP September 2005 Goodput -- 10 frames/TXOP EDCF (1 MT) CCC (2 MTs) (4 MTs) (6 MTs) (8 MTs) Shorter TXOP increased control traffic by 50% Goodput still increases linearly with the number of data channels The control channel is not a bottleneck Control channel at 6 Mbps; 8 traffic streams Avaya Labs, Polytechnic University

Summary of Goodput Results September 2005 Summary of Goodput Results 10 frames/TXOP Number of MT channels Data PHY rate @ 24Mbps Data PHY rate @ 54Mbps 1 (i.e., EDCF) 20.2 Mbps 39.3 Mbps 2 39.1 Mbps 73.3 Mbps 4 78.1 Mbps 145.3 Mbps 6 117.0 Mbps 217.0 Mbps 8 154.4 Mbps 280.3 Mbps 15 frames/TXOP Number of MT channels Data PHY rate @ 24Mbps Data PHY rate @ 54Mbps 1 (i.e., EDCF) 20.5 Mbps 40.3 Mbps 2 39.7 Mbps 75.2 Mbps 4 79.3 Mbps 149.9 Mbps 6 118.9 Mbps 224.2 Mbps 8 157.5 Mbps 293.8 Mbps Control channel at 6 Mbps; 8 traffic streams Avaya Labs, Polytechnic University

Study 2: Queueing and access delay September 2005 Study 2: Queueing and access delay Avaya Labs, Polytechnic University

Average Queueing Delay September 2005 Data PHY rate: 24Mbps Load: 15 Mbps Data PHY rate: 54Mbps Load: 24 Mbps 15 ms of delay for EDCA reduced to <1ms by CCC 13 ms of delay for EDCA reduced to <0.5ms by CCC Control channel at 6 Mbps; 4 traffic streams; 1 frame/TXOP Avaya Labs, Polytechnic University

Average Channel Access Delay September 2005 Average Channel Access Delay Data PHY rate: 24Mbps Load: 15 Mbps Data PHY rate: 54Mbps Load: 24 Mbps Control channel at 6 Mbps; 4 traffic streams; 1 frame/TXOP Avaya Labs, Polytechnic University

Average Queueing & Access Delays September 2005 Average Queueing & Access Delays Data PHY rate: 24Mbps Load: 19 Mbps Queueing Delay Access Delay 60 ms of delay by EDCA reduced to 3.5 ms by CCC Control channel at 6 Mbps; 8 traffic streams; 10 frames/TXOP Avaya Labs, Polytechnic University

CDF Queueing & Access Delays September 2005 CDF Queueing & Access Delays Data PHY rate: 24Mbps Load: 19 Mbps Queueing Delay Access Delay Control channel at 6 Mbps; 8 traffic streams; 10 frames/TXOP Avaya Labs, Polytechnic University

September 2005 Conclusions CCC multi-channel MMAC performs significantly better than EDCF higher goodput lower delay Goodput increases linearly as the number of available MT channels increases The control channel is not a bottleneck, even at 6 Mbps Avaya Labs, Polytechnic University