September 2005 doc.: IEEE 802.11-05/0880r0
IEEE P802.11
Wireless LANs
Date: 2005-09-12
Author(s):
Name / Company / Address / Phone / email
Mathilde Benveniste / Avaya Labs / 233 Mt Airy Road
Basking Ridge, NJ 07920 / +1-908-696-5296 /
Table of Contents
1 Introduction 4
2 CCC Protocol Overview 4
2.1 CCC Framework 4
2.1.1 MT channel reservation procedure 5
2.1.2 Single and Multi-radio MPs 6
2.2 Channel Assignment 6
2.2.1 Permissible MT channel set 6
2.3 Channel access 6
2.3.1 MT Channel Access 7
2.3.2 Control channel access 7
2.4 Merging mesh networks 7
3 Optional CCC Features 7
3.1 Three-way reservation handshake 7
3.2 Mesh Ack 8
3.3 Enhanced NAV rules 8
3.4 Extending an on-going transmission 8
3.5 Generalized Adaptive Prioritization 8
3.5.1 User Priority 9
3.5.2 Residual Lifetime 9
3.5.3 Congestion 9
3.6 NAV Time Filtering and AIFR 9
4 Issues Addressed 10
4.1 Adjacent Channel Interference 10
4.2 Hidden terminal problem 11
4.2.1 RTS/CTS 12
4.2.2 Two-step NAV setting 12
4.3 Exposed node problem 13
4.3.1 Two NAV components 14
4.3.2 Double NAV + MACK 14
4.4 Mixing BSS traffic and forwarding traffic 14
4.4.1 Sharing the same channel 14
4.4.2 Sharing the same radio 15
4.5 Co-existence of wireless mesh with independent WLANs 15
4.6 Tx power control 15
5 Discussion 15
References 18
Appendix I 19
Additional Supporting Material 19
Coverage of Minimum Functional Requirements 20
Coverage of In-Scope Functions (Informative) 21
List of Figures
Figure 1 Reservation of MT channels 5
Figure 2 NAV time filtering 10
Figure 3 RF spectrum segments 11
Figure 4 Hidden terminals in a mesh network 12
Figure 5 Two-step NAV setting 13
Figure 6 Exposed nodes 13
List of Tables
Table 1 Summary description of CCC features 15
1 Introduction
The Mesh Media Access Coordination (MMAC) function enables Mesh Points (MPs) to resolve contention and share the wireless medium efficiently with both frames forwarded across the multi-hop WLAN Mesh and with traffic in WLANs associated with Mesh APs (MAPs). A mesh must be able to operate in the existing unlicensed RF bands used by WLANs. If multiple radios (transceivers) are employed in a MP device, adjacent channel interference must be avoided. If a WLAN mesh operates in the neighborhood of independent WLANs, it must be able to avoid and resolve collisions with the WLAN traffic. Two problems prevalent in mesh networks, the “hidden node” and “exposed node” problems must be addressed.
In this paper we present a distributed protocol for the MMAC function that addresses these concerns. It is based on the use of a common channel for control traffic, hence its name Common Control Channel (CCC) protocol. The proposed protocol is QoS and congestion aware. It is simple to administer, preserves battery life, and accommodates MP mobility.
Section 2 describes the protocol in its simplest form; we refer to this protocol as the CCC ‘framework’. Section 3 deals with additional features that provide more capabilities to the mesh user. These features are optional and would be adopted if the capability each brings to the mesh were desirable. Section 4 explains how each of the optional features help address specific problems that may be encountered in a mesh. Section 5 is a discussion of merits of the CCC framework and of the individual optional features.
2 CCC Protocol Overview
The proposed MMAC protocol applies to both infrastructure and ad hoc mesh networks. An infrastructure mesh network provides access to the Distribution System (DS), through a gateway – known as the “portal”. It enables traffic to originate or terminate at a station not on the mesh. An ad hoc mesh does not connect to the DS. The end points of the traffic are stations on the mesh network. Stations associated with a mesh network use the 802.11 and 802.11e MAC protocols to communicate with their associated AP – known as the mesh AP (MAP). Mesh points relay the traffic between MAPs or between MAPs and portals. For simplicity of presentation of the MMAC protocol, we refer in this paper to all nodes of a mesh network – that is, mesh points, mesh APs, and portals – as “mesh points” (MPs).
The proposed MMAC protocol is distributed, which enables MPs of different vendors to be put together in a mesh. It provides a way for MPs to access their assigned/ selected channels to forward received frames to the next hop. It also enables multicasting and broadcasting of data. Topology discovery, link establishment and routing are determined independently. It is assumed in this paper that the destination of the transmission has been established through the routing function. The routing function invokes the MMAC function at each hop of a multi-hop path. Transmit/receive capabilities have been determined through handshake during discovery (e.g. PHY protocol/transmit rate, antenna configuration/MIMO parameters, or other parameters are known).
The proposed protocol uses a common control channel ‘framework’. The CCC framework is the simplest mesh MAC presented to TGs to date. Like EDCA, CCC does not require synchronization. Other common control channel protocols require synchronization, and their performance suffers with clock drift. Therefore, CCC also offers the simplest asynchronous MMAC protocol presented. In addition, it makes possible several optional features, which make it competitive with any other protocol. The following section describes the CCC framework. The optional features and the capabilities they provide are presented in Section 3.
2.1 CCC Framework
The CCC framework consists of reservations made through RTS/CTS, exchanged on the control channel, for the transmission of data along a link. The end points of the link are referred to as the “forwarding MP” and the “receiving MP”. Mesh traffic is transmitted in groups of frames separated by idle spaces of length SIFS, much like the 802.11e TXOP, thus requiring a single contention (as no other standard protocol will seize a channel that is idle for as little as SIFS). Such a group is called MTXOP (mesh TXOP).
Mesh traffic can be sent either on the control channel or any other channel. A channel, other than the control channel, that is used for mesh traffic is called a mesh traffic (MT) channel. A MT channel can be chosen dynamically based on availability.
The control and a MT channel can have different PHY protocols, and the same control channel can be used for reservation of diverse MT channels (e.g., channels with 11b, 11g, or 11 PHY layers).
2.1.1 MT channel reservation procedure
The forwarding and receiving MPs exchange a RTS/CTS on the control channel in order to reserve a MT channel for a MTXOP. Reserving a channel other than the control channel for mesh traffic must be indicated on the RTS/CTS. The extended RTS/CTS is called MRTS (mesh RTS) /MCTS (mesh CTS). The new frame contents are as follows.
· The MRTS frame contains the following fields: Forwarding MP address, Receiving MP address, Transmit channel, and MTXOP Duration.
·
·
·
· The MCTS frame contents are: Forwarding MP address, Transmit channel, and MTXOP Duration.
Figure 1 illustrates the CCC reservation procedure involving three MT channels using the control channel. Both the forwarding and receiving MP maintain a NAV for each usable channel. A MP monitors the control channel and keeps track of all reservations made by other MPs to determine the busy/idle status of MT channels, and when they will become available. The duration field on the MRTS/MCTS is used to update the NAV for the channel reserved. A reservation request is declined if the receiving MP deems the requested channel busy, or if all its radios are busy.
·
·
·
·
·
·
·
·
·
·
·
·
·
The MT channel reserved for the transmission of a MTXOP is selected from among a set of “permissible” channels maintained by a MP. The reservation exchange may start while MT channel is busy, but the MT channel must be idle when the reservation process is completed. Advance reservation of the MT channel is not permitted in order to ensure proper prioritization of mesh traffic. That is, higher-priority frames will be transmitted before lower-priority frames that may have arrived earlier.
Figure 1 Reservation of MT channels
The receiving MP responds with a MCTS within a time interval of length SIFS. A MCTS is sent to indicate acceptance of a channel reservation request. The Duration field is copied in the MCTS sent by the receiving MP. If a MCTS is not received, the forwarding MP assumes that the reservation request is declined. A reservation is accepted if the MT channel indicated in the MRTS will become idle within a pre-specified time interval, according to the NAV maintained by the receiving MP and if the receiving MP has available radios to receive the transmission.1, 3
Successful receipt of a mesh transmission is followed by an acknowledgement sent on the MT channel according to EDCA rules.
Section 3 describes additional features of CCC and their associated capabilities.
2.1.2 Single and Multi-radio MPs
For mesh points with a single radio, the 802.11 legacy RTS/CTS can be used for reservations and CCC is simply EDCA. In that form MPs can be used in homes to extend the reach of a BSS. Existing silicon can be employed for single-radio MPs.
While using EDCA, single radio MPs can still benefit from some of the optional features discussed later.
With an additional receiver and MRTS/MCTS frames, one has full CCC capability. This brings multi-channel throughput, and high-rate links if additional radios are added per MP. The latter are needed in large – e.g. corporate/municipal – meshes, especially near the portal.
While a multi-radio MP may transmit and receive traffic on different MT channels simultaneously it need not keep all radios constantly powered – as required by other protocols – in order to be able to receive notice of transmissions destined to it. It is sufficient to keep only the radio tuned to the control channel powered, where notice of all transmissions directed to the MP will arrive. This way, the proposed MMAC protocol helps preserve battery life in multi-radio battery-powered MPs.
2.2 Channel Assignment
The proposed MMAC protocol makes channel assignment very simple. A single control channel is assigned; it is selected when a mesh starts. Mesh points inherit the selection for the control channel as they associate with the mesh. If two mesh networks merge to form a single combined mesh, one of the mesh networks changes its control channel. Which of the two merging mesh networks is the one to change control channel can be determined in a distributed way. The beacon time stamp of a mesh network will indicate its age. The newer of two merging mesh networks will change its control channel to coincide with that of the mesh network started first. A procedure for changing control channel is described in reference. [4]
A change in control channel may be necessary also in order to comply with 802.11h DFS requirements.
MT channel assignment can employ either dynamic channel assignment or fixed channel assignment. The former is simpler from an administration perspective. A MT channel is assigned on a channel availability basis, per-MTXOP. A MP that has a MTXOP to transmit checks the availability of the MT channels in a “permissible channel set” and selects an available MT channel that is appropriate for the transmission of the MTXOP. In general, different MT channels may be appropriate for different receiving MPs depending on their radios and environmental considerations. If an appropriate channel is not available, the MP will select the channel that will become available first according to the NAV. More intelligence may be added to the selection of an MT channel from the permissible set. Fixed channel assignment can be implemented by limiting the permissible set to one appropriate channel for each mesh neighbor.
According to the proposed MMAC protocol, channel assignment does not add administrative complexity when dealing with mobility or recovery from MP failures. Adjustments to a new mesh topology are fast as control communication continues on the same control channel and only one channel, the control channel, needs to be scanned for beacons.
2.2.1 Permissible MT channel set
Each MP maintains a set of “permissible” channels. This set consists of channels that have low noise and are lightly loaded. A MP monitors channels regularly in order to add channels to the permissible set or eliminate unacceptable channels from the permissible set, whichisupdated over time. Signal strength and other metrics indicating traffic load and congestion (e.g., channel utilization and number of collisions) are measured. The permissible channels meet 802.11h DFS requirements. Ifan independentAPpowers on andchooses tooperateon one of the permissible channels,that channelwill be removed from thepermissible set. Permissible channels may be ranked in order of desirability of the channel, using different metrics. One such metric would be traffic load, to avoid co-channel interference and collisions with other users of the channel.
2.3 Channel access
The proposed MMAC protocol is a multi-channel generalization of CSMA/CA. MPs with a single radio, which would use the same physical channel for the control and MT logical channel functions, access the wireless medium through the 802.11e EDCA protocol using MRTS/MCTS for reservations.
When a separate physical channel is used for mesh traffic and control traffic, the access mechanism is differentiated accordingly. The two access methods are described below.
2.3.1 MT Channel Access
Access to the MT channel follows the 802.11e EDCA protocol. Prioritized access, as provided by EDCA, enables mesh traffic to compete with independent WLAN traffic for access to the MT channel on the basis of the priority of the MTXOP.
If a mesh network were located in an area without any independent WLAN users, it would have sufficed to access the channel without prior carrier sensing, as co-channel use in a BSS associated with a MAP can be coordinated to avoid overlap in time. Carrier sensing becomes necessary only because independent WLAN stations are unaware of the mesh presence and, more importantly, may not be equipped to communicate with the mesh network.