1. doc.: IEEE 802.11-05/0xxx0 Submission Summary of the CCC MMAC (M-22) Mathilde Benveniste, Avaya Labs Research benveniste@ieee.org Jeffrey Zhifeng Tao, Polytechnic University jefftao@photon.poly.edu References: IEEE 802.11-05-707r0, 877r3, 880r0, 904r2

2. doc.: IEEE 802.11-05/0xxx0 Submission September 2005 Avaya Labs, Polytechnic UniversitySlide 2 Summary of the CCC MMAC 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 IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs 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, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-09-16 Authors:

3. doc.: IEEE 802.11-05/0xxx0 Submission September 2005 Avaya Labs, Polytechnic UniversitySlide 3 Overview of the CCC MMAC Reservations are made through RTS/CTS, exchanged on control channel, for transmission of data on one of several channels –Mesh traffic can be sent on control channel –Reserving a channel other than the control channel for mesh traffic must be indicated on the RTS/CTS –The extended RTS/CTS called MRTS/MCTS –Transmission of data is based on EDCA A NAV is maintained for each usable channel –The duration field on the MRTS/MCTS is used to update the NAV for the channel reserved

4. doc.: IEEE 802.11-05/0xxx0 Submission September 2005 Avaya Labs, Polytechnic UniversitySlide 4 MPs reserve time on MT channels by exchanging MRTS/MCTS on the control channel Control channel can serve mesh traffic channels of diverse PHYs (11a/g/n) Reservations on control channel MCTS time Reserve MT channel 1 MRTS Reserve MT channel 3 MRTS Reserve MT channel 1 Reserve MT channel 2 MTXOP MCTS MT 2 Frequency MT 1 CC MT 3 CC: control channel MT: mesh traffic channel

5. doc.: IEEE 802.11-05/0xxx0 Submission September 2005 Avaya Labs, Polytechnic UniversitySlide 5 Benefits of CCC MMAC Load balancing across channels on per-TXOP basis –A channel does not sit idle if there is traffic buffered somewhere in the mesh Good channel utilization –No restriction on when channel may be used; no channel idle gaps Low end-to-end delay/jitter – enables VoIP –Ready access to traffic channels keep delay/jitter low Multicast/broadcast capability –A radio is always on the control channel for quick and efficient dissemination of information Can co-exist well with independent WLANs

6. doc.: IEEE 802.11-05/0xxx0 Submission September 2005 Avaya Labs, Polytechnic UniversitySlide 6 Why CCC is the simplest MMAC CCC does not require synchronization! –CCC is the only asynchronous MMAC presented CCC for single-radio MPs is simply EDCA Add 1 receiver (or full radio) + MRTS/MCTS for full CCC –Gain multi-channel throughput Additional radios per MP can be added for high-rate links (needed in large – e.g. corporate/municipal – meshes, especially near portal) –Multi-radio MPs can avoid adjacent channel interference (ACI) without loss of mesh capacity or the need for expensive hardware

7. doc.: IEEE 802.11-05/0xxx0 Submission September 2005 Avaya Labs, Polytechnic UniversitySlide 7 How CCC differs from other common control channel approaches

8. doc.: IEEE 802.11-05/0xxx0 Submission September 2005 Avaya Labs, Polytechnic UniversitySlide 8 Comparison with Wi-Mesh Proposal The DRCA MMAC protocol in Wi-Mesh uses the basic framework of CCC DRCA lacks some key features of CCC –DRCA multi-radio MPs cannot deal with adjacent channel interference without capacity loss or expensive hardware –No provision for the exposed node problem –Lacks other optional features of CCC 1 Summary description of CCC features

9. doc.: IEEE 802.11-05/0xxx0 Submission September 2005 Avaya Labs, Polytechnic UniversitySlide 9 Comparison with SEE-Mesh Proposal The CCF MMAC protocol in SEE-Mesh modified common control channel framework to allow use of a single radio on different channels Synchronization required of all MPs in CCF (both CCF and EDCA MPs) –EDCA MPs must implement CCW CCF has lower channel utilization & higher delay/jitter –Radio retuning delays impact CCF, but not CCC –Restriction on when channel can be used 1 Summary description of CCC features

10. doc.: IEEE 802.11-05/0xxx0 Submission September 2005 Avaya Labs, Polytechnic UniversitySlide 10 Comparison with SEE-Mesh Proposal - 2 CCF multi-radio MPs cannot deal with adjacent channel interference without capacity loss or expensive hardware To provide multicast/broadcast capability, CCF requires a new (undisclosed) priority-access protocol CCF cannot co-exist well with independent WLANs –a traffic channel reservation cannot be extended if channel busy – No control radio available! No provision made for the exposed node problem 1 Summary description of CCC features

11. doc.: IEEE 802.11-05/0xxx0 Submission September 2005 Avaya Labs, Polytechnic UniversitySlide 11 The End The CCC protocol is proposal M-22