Doc.: IEEE 802.11-05/0880r1



IEEE P802.11

Wireless LANs

| CCC MMAC protocol framework and optional features |

|Date: 2005-09-19 |

|Author(s): |

|Name |Company |Address |Phone |email |

|Mathilde Benveniste |Avaya Labs |233 Mt Airy Road |+1-908-696-5296 |benveniste@ |

| | |Basking Ridge, NJ 07920 | | |

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

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.

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.

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

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.

[pic]

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

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

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, which is updated 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. If an independent AP powers on and chooses to operate on one of the permissible channels, that channel will be removed from the permissible 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.

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

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.

Using the EDCA protocol for MT channel access in the absence of independent WLAN users does not impose a substantial penalty with respect to channel utilization. According to the CSMA/CA rules, a node may access the channel without backoff delay if the frame pending transmission is generated while the channel is idle and it remains so for a time interval that depends on the access priority of the frame. As a consequence, MTXOP duration would increase by a time interval equal to the AIFS (arbitration inter-frame space) of the mesh traffic.

2 Control channel access

Prioritization of mesh traffic transmissions occurs during the reservation process on the control channel (i.e., during MRTS transmission to reserve a MT channel for a MTXOP). .

A MCTS is transmitted on the control channel following receipt of a MRTS after a SIFS idle interval

5 Merging mesh networks

Mesh networks can merge to form a larger mesh. Merging follows steps similar to the association of a MP to a mesh. If the original meshes have different control channels, one must change its control channel. A MP can demand the change of control channels by all MPs on a mesh. [See reference [4].]

Optional CCC Features

In addition to the basic protocol for mesh MAC, CCC can be enhanced with several optional features, which make it competitive with any other protocol. This section describes these optional features and the capabilities they provide are presented in Section 3.

1 Three-way reservation handshake

A reservation request is initiated by the forwarding MP when it sends a MRTS. A MCTS is sent by the receiving MP to indicate acceptance of a channel reservation request. In addition to indicating reservation acceptance, a MCTS can also optionally serve to either extend or explicitly decline a channel reservation request. The receiving MP may optionally extend the MTXOP Duration in order to receive the MTXOP at a lower Tx rate. The benefit of notifying the forwarding MP of the denial of a reservation request is that it provides specific information of the reason for the denial which is useful in determing the time and channel choice for another reservation attempt.

•

If the reservation request is accepted or extended, the Duration field is adjusted in the MCTS sent by the receiving MP. For the receiving MP to be able to extend the duration of a requested reservation, the transmission rate must be included in the MRTS and MCTS. If the reservation is extended, the Duration field is greater than the adjusted value of the Duration field in the MRTS received and the transmit rate is lower in the MCTS. Extension of a reservation by the receiving MP requires that, neighbors be notified of the longer reserved time. The forwarding MP in that case sends another MRTS with the Duration field.

If the reservation request is declined, the Duration field in a MCTS declining a reservation request is set to 0. Neighbors that have set their NAV for the requested channel according the MRTS may be optionally notified of the reservation denial through a second MRTS in order to reclaim the reserved channel time.

To convey to the forwarding MP the reason for the denial of the reservation request, additional fields can be added to the MCTS. These are: the Radio Counter and Busy Time.

The radio counter indicates the number of radios that remain idle at the receiving MP. If the radio counter is zero, the Busy Time field will show the time interval before a MT radio will become idle (cease transmitting or receiving). When a reservation is declined, the forwarding MP must wait for a time interval equal to the Busy Time value before sending another MRTS to the receiving MP. If the radio counter in a MCTS declining a reservation request is non-zero, the forwarding MP may attempt another reservation for the same MTXOP immediately using a different MT channel. The Busy Time field, in that case, indicates the setting of the NAV of the MT channel requested and is used to update the NAV for the requested MT channel at the forwarding MP.

The new frame contents are as follows.

• The MRTS frame contains the following fields: Forwarding MP address, Receiving MP address, Transmit channel, MTXOP Duration; and Access Priority. It can optionally include also the Number of Frames, Transmit rate; and other.

• The MCTS frame contents are: Forwarding MP address, Transmit channel, and Duration. It can optionally include also Number of Frames/Busy time; Transmit rate; Radio Counter; and other.

2 Mesh Ack

Following the successful transmission of a MTXOP, there are two choices in acknowledging the transmission. Acknowledgement may be sent either on the MT channel (similar to 802.11 and 802.11e), or on the control channel by sending a group acknowledgement, called M-ACK (Mesh-Acknowledgement). The M-ACK identifies the individual frames in a sequence of frames that were received successfully. The M-ACK is transmitted either when all frames expected in a MTXOP are received, regardless of errors, or when the reservation expires.

The advantage of using a M-ACK optional feature relates to avoidance of adjacent channel interference and to the exposed node problem, which are discussed later.

If a M-ACK is used for acknowledgement, it is assigned the highest priority access category. The same MP may transmit a MRTS within a SIFS idle interval of sending a M-ACK to acknowledge receipt of a MTXOP. A MRTS and a M-ACK may be piggybacked, provided they have the same destination.

The optional M-ACK acknowledgement frame contains the following: Receiving MP address; Forwarding MP address; Transmit channel; and MTXOP frame receipt status.

4 Enhanced NAV rules

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 NAV timer may also optionally be updated from NAV-setting requests heard over the MT radio. Such NAV updates from the MT radio become important if the wireless mesh co-exists with independent WLAN users. If MT channels are assigned dynamically, NAV synchronization can be achieved with greater certainty by tuning a radio to the selected MT channel as early as possible and no later than the generation of a MRTS or MCTS reserving that channel.

The mesh NAV (MNAV) timer, which is similar to the NAV timer used in 802.11, can be further enhanced with a few changes that address the hidden node and the exposed node problems.[1] A description of an enhanced mesh NAV and the background for the NAV specification below is provided in the sections covering the hidden and exposed node problem, Sections 4.2 and 4.3, respectively. The enhanced MNAV differs from the legacy NAV in two ways

: (1) Two NAV components and (2) Two-step NAV-setting for MRTS.

5 Extending an on-going transmission

A MT channel reservation by a MP can be extended once mesh transmission has commenced. Such an extension may be necessary in the event the MT channel is busy because of independent WiFi users. To extend the reservation, another MRTS/MCTS is needed in order to notify all neighbors within interference range of the forwarding and receiving nodes. Extension of the reservation is guaranteed as long as the MRTS is transmitted prior to expiration of the NAV for the MT channel adjusted for AIFR (see Section 3.6).

6 Generalized Adaptive Prioritization

The goal of prioritisation is twofold: the reduction of latency and jitter for QoS applications and congestion control. The access category assigned to a MTXOP and its associated MRTS determines the priority with which a MP will access the control channel to transmit the MRTS. The channel access parameters (AIFSN, CWMin, CWMax) and MTXOP_limit employed in EDCA depend on the assigned AC. The access category assigned to a MRTS depends on three factors:

• MTXOP user priority

• Frame residual lifetime

• MP congestion level

1 User Priority

The MTXOP user priority is set to the highest user priority of the frames included in the MTXOP. Doing so does not delay time sensitive traffic and at the same time encourages grouping of mesh traffic into MTXOPs, which improve channel use efficiency.

2 Residual Lifetime

Access priority of a MRTS depends on the age of the frames in the MTXOP. Age of a frame is accounted for by the residual lifetime of a frame. The residual lifetime of a frame is the time remaining until its expiration, when it is discarded. Different applications have different tolerance for delay. For instance, voice packets are not useful if they are delayed beyond a given time. In contrast, frames of various file transfer applications would be more tolerant of delay. Hence, the residual lifetime assigned to a frame will depend on its user priority. If a frame is insensitive to delay, it will be assigned a long but finite maximum lifetime adequate to prevent looping when the frame is routed in a mesh.

Residual lifetime can be measured in different ways: either in local clock time units, or in the number of hops traversing the mesh. In the latter case, it is the same as the TTL (time to live) metric used to avoid looping in routing through a network. In the former case, when a frame enters the mesh the expiration time is included in the frame. The residual lifetime is the difference between the expiration time on the received frame and the MP clock time.[2] If residual lifetime is expressed as the number of hops remaining before the frame is discarded, its value is reduced by 1 every time it reaches a node in the mesh.

The MRTS access priority is adjusted for the residual life of the MTXOP frames. The MRTS for a MTXOP containing a frame with remaining lifetime below a specified threshold will have its access priority increased. Giving higher priority to frames based on age bounds the delay in traversing the mesh and increases throughput (reduces dropped-frame rate).

3 Congestion

Finally, the MRTS access category depends on the traffic load on a MP. MPs with fewer transmitting radios need more help to reduce congestion. Mesh bottlenecks are avoided by expediting channel access by MPs with heavier mesh traffic loads and fewer radios. The MP access priority depends on the queued traffic adjusted for the number of transmit radios at the MP.

7 NAV Time Filtering and AIFR

Access to the control channel for the transmission of a MRTS follows the EDCA protocol, subject to additional optional filtering of the time when backoff countdown and transmission are allowed. This filtering is driven by the availability of the MT channel being reserved, which is indicated by the NAV timer for the channel. [3] NAV time filtering increases priority differentiation. It also leads to better utilization of the MT channels because, as explained below, a MT channel does sit idle while a reservation is made on the control channel.

Advance reservation of the MT channel is not permitted in order to ensure proper prioritization of mesh traffic. However, a MRTS may be sent while the MT channel is busy, provided the MT channel becomes free when the MRTS/MCTS exchange is complete. A time interval AIFR (advance time for reservation) determines the earliest time a MRTS may be transmitted prior to the expiration of the NAV timer of the MT channel being reserved, as illustrated in Figure 2. A different AIFR length is specified for different access categories, with a longer AIFR used for a higher priority access category. The longest AIFR will not exceed the time needed for the transmission of a MRTS/MCTS, assuring that the channel will be available by the time reservation is accomplished. Superposition of NAV time filtering improves priority differentiation and increases utilization of MT channels.

A MRTS is generated when a MTXOP that requires forwarding arrives at a MP. It will contain a MT channel from the permissible set that is appropriate for the transmission of the MTXOP corresponding to the MRTS. Sometimes, a MRTS can be transmitted immediately following a M-ACK frame without contention. Specifically, a MRTS can be transmitted on the control channel within a SIFS idle period following the transmission of the acknowledgment of the MTXOP if the designated MT channel is idle or “nearly idle” (that is, if the NAV of the MT channel is less than AIFR), no other MRTS is queued at the forwarding MP, and the control channel is idle. If other MRTSs are queued at the MP, the MRTS will be queued for transmission according to EDCA. If the control channel is busy or the designated MT channel is busy and not within an AIFR time interval of becoming idle, transmission of the MRTS is postponed. A random backoff delay is drawn using the parameters associated with the AC assigned to the MRTS.

[pic]

Figure 2 NAV time filtering

The MRTS is transmitted when the following conditions are met:

i. backoff delay is decremented to 0,

ii. the control channel is idle, and

iii. an “appropriate” MT channel (that is, a permissible MT channel that is appropriate for the transmission of the MTXOP corresponding to the MRTS) is idle or nearly idle.

Backoff countdown at each EDCA queue (queue of MRTSs of the same access category) occurs only under conditions (ii) and (iii) above. If all appropriate MT channels cease to be idle or nearly idle, backoff countdown at an EDCA queue will stop, and will be resumed when an appropriate MT channel becomes idle or nearly idle. When the MRTS at the head of the queue is transmitted, it will contain, as the requested MT channel, an appropriate channel that is idle or nearly idle.

The MRTS reservation request will be accepted if the NAV of the MT channel being reserved, maintained at the MP receiving the MRTS, has expired or is due to expire within a time interval equal to (AIFR - MRTS_Tx - SIFS), where MRTS_Tx is the time needed for the transmission of the MRTS.

The MP transmits the MTXOP on the MT channel indicated in the MRTS once it receives a MCTS indicating acceptance of the reservation request. [See description of the acceptance condition in Section 2.1.1.] The MT channel NAV will not have changed when the MCTS arrives since AIFR is never longer than the time needed for a MRTS/MCTS exchange.

No NAV filtering is imposed on the transmission of a M-ACK. However, if a MRTS is to be transmitted by the same MP immediately following the transmission of a M-ACK, NAV filtering applies to the MRTS transmission.

Issues Addressed

1 Adjacent Channel Interference

Adjacent channel interference (ACI) is caused by energy on channels that are adjacent in the RF spectrum. ACI can be serious when a receiver is sufficiently close to a transmitter on an adjacent channel to render the interfering signal too strong. ACI is not a problem in a WLAN BSS because all BSS stations use a single radio. All radios in a BSS use the same channel, but at different times. ACI may be a problem in neighboring BSSs if they use adjacent channels and two stations in different BSSs are so close to one another that the signal received on the adjacent is sufficiently to corrupt the primary channel signal. Such proximity is rare.

Multiple radios are needed for high throughput at points of high traffic concentration, as for instance near the portal of a mesh. Multi-radio mesh points must thus operate on at least two different channels simultaneously. The selection of channels is limited by the following considerations. To avoid ACI, multi-radio MPs must either use non-adjacent channels, or if they use adjacent channels, they should not transmit or receive at once. In today’s unlicensed RF bands where WiFi operates, two channels in the 5 GHz band with center frequency spacing of 40 MHz would experience ACI if they did not have an additional isolation of 30 dB. [7] This suggests that, in the range where there are multiple bands (three or four bands, depending on the geographic region) of four or more channels, about three or four ACI-free channels exist between 5.150 – 5.825 GHz. The channels in the 2.4 GHz band would cause one another adjacent channel interference if used on the same MP.

The CCC protocol permits the use of adjacent channels on multiple radios in a mesh point without ACI as follows. First, since control channel traffic goes in both directions, in order to prevent ACI between control traffic and mesh traffic, the control channel is selected in one of the RF segments and the MT channels in the other. Figure 3 illustrates the channel apportionment by function. One of the RF bands provides the control channel (CC) and the other band(s) is used for the MT channels. This enables a multi-radio MP to use as MT channels all of the channels in a band, provided that all transmissions involving the MP are either incoming or outgoing. A MP can receive mesh traffic from one neighbor while exchanging MRTS/MCTS messages with another neighbor. Both the control and traffic channels may be selected in the 5 GHz range, where there exist multiple bands of channels.

Second, there are implications of ACI for mesh traffic transmission. A MP engaged in a transmission on one channel should not receive transmissions on another channel in the same RF segment. This means that a MP cannot receive mesh traffic from one neighbor while transmitting mesh traffic to another neighbor on a different radio. It also means that, if a MP is receiving mesh traffic on two MT channels, which as explained above may lie in the same RF band, acknowledgements cannot be sent on the MT channels as they would cause ACI to the mesh traffic on the adjacent channel. Acknowledgements must be sent on a non-adjacent channel. If the control channel enjoys sufficient RF spectrum separation from the MT channels, it can be used for acknowledgments. Therefore, the MACK must be implemented on multi-radio MPs and their mesh neighbors.

.

Figure 3 RF spectrum segments

2 Hidden terminal problem

A hidden node is one that can interfere with the receipt of a transmission that it cannot hear. In a WLAN where stations can hear one another, the hidden node problem is addressed by using RTS/CTS. If, however, the transmitting and receiving nodes are sufficiently separated, as in the case of MPs in a WLAN mesh, RTS/CTS is not effective because the interference range is longer than the transmit range.[4] Hidden nodes will be found within interference range of the destination of a transmission but outside of the transmit range. Consider the mesh illustrated in Figure 4. Node 1 sends a RTS to node 2 and node 2 responds with a CTS. Nodes 3 and 5, which are within interference range of node 2, are not within transmit range of node 2, so they do not hear the CTS.

[pic]

Figure 4 Hidden terminals in a mesh network

1 RTS/CTS

As in the case of a BSS, to protect against hidden nodes, RTS/CTS must be used. Because of the distance separating potentially interfering nodes, the RTS/CTS must be sent at a more robust PHY mode than mesh traffic frames. That is, the RTS/CTS would be transmitted either at higher transmit power or a lower data rate than mesh traffic. This way, the transmit range for RTS/CTS could be the same as the interference range of mesh transmissions.

Use of RTS/CTS to avoid hidden nodes gives rise to a problem in canceling reservations when transmitting a TXOP (a sequence of frames transmitted with a separation of a SIFS idle between them). According to the 802.11e draft, there are two ways to reserve channel time for the transmission of a TXOP. One is to reserve the channel for the duration of the entire TXOP and the other is to reserve the channel for one frame at a time. Since a RTS/CTS is needed, a single RTS/CTS will reserve the channel for the entire TXOP duration. If the reservation request is not accepted, the reservation for the TXOP must be cancelled in order to enable use of the reserved channel for another transmission.

In the proposed MMAC protocol, notification of denial of a reservation is communicated to all MPs by a second MRTS from the forwarding MP containing a Duration field set to 0. The forwarding MP is notified of the denial of the request when it receives a MCTS with Duration field set to 0. According to the 802.11 NAV rules, a node that hears a frame with a non-zero Duration field updates its NAV for the channel to account for the expiration of the new Duration value as well as all previous NAV-setting requests. A NAV is therefore the composite of multiple NAV-setting requests from different sources.

A node that hears notice of the cancellation of an earlier NAV-setting request cannot simply reset the NAV. Other NAV setting requests may be outstanding, as it is possible for a node to hear multiple NAV-setting requests for the same channel from nodes that cannot hear one another. Canceling a channel’s NAV could thus lead to collisions. A different way is described below for setting the NAV of a channel when reservation is sought through a MRTS; the new NAV setting approach obviates the need for resetting a NAV when a reservation is cancelled.

2 Two-step NAV setting

The NAV of a channel is set in two steps when hearing a MRTS. Upon receipt of initial MRTS, a MP updates the NAV for the specified MT channel for the time interval RTSHSHK needed to transmit a MCTS and another MRTS. If a cancellation MRTS is not received, a node then sets the NAV for the remaining Duration value indicated in the initial MRTS or the extended Duration value indicated in a subsequent MRTS. If the reservation is declined, the NAV expires without the need

for further action.

Using a two-component NAV (as described in Section 4.3.1), a

MP receiving a MRTS sets the MNAV_RTS of the MT channel indicated in two separate steps.

1. Upon receipt of the initial MRTS, the MNAV_RTS for the specified MT channel is updated for the time interval RTSHSHK (RTS handshake) needed to receive a MCTS and a second MRTS

2. If, during the interval RTSHSHK, a cancellation MRTS is not received (i.e., a second MRTS is not received from the same forwarding MP for the same MT channel, or a second MRTS is received within a SIFS idle time interval from the MCTS to extend the initial reservation), the MP sets the MNAV_RTS for the residual Duration from the initial or second MRTS.

Figure 5 illustrates how the NAV is set when a MP hears a MRTS. Two examples are shown. In Example 1, the initial reservation for MTXOP1 is cancelled when a second MRTS is heard from the same MP with Duration set to 0, and therefore the NAV is not extended beyond the initial setting of RTSHSHK. In Example 2, the reservation is not cancelled and therefore the NAV is extended to cover the entire reservation Duration in the initial MRTS.

[pic]

Figure 5 Two-step NAV setting

4 Exposed node problem

An ‘exposed node’ is one that is either (1) within the sensing range of the sender node but outside the interference range of the receiver node – therefore it could not receive a transmission from another node, but could transmit itself, or (2)

within the sensing range of the receiver node but outside the interference range of the sender node – therefore it could not transmit but it could receive another transmission directed to it. Figure 6 illustrates the two instances of an exposed node.

(1) [pic]

(2) [pic]

Figure 6 Exposed nodes

According to the IEEE 802.11 NAV rules, when a RTS or a CTS is heard by a node, its NAV is set and the node

cannot transmit or receive (that is, it cannot send a RTS or a CTS) on the channel until the NAV expires. For an exposed node, these rules are too conservative and lead to the underutilization of the channel. The problem is more common in mesh networks because of the separation between nodes. It is remedied with the modification of the NAV and by sending acknowledgement of the transmission of mesh traffic on the control channel.

1 Two NAV components

The

MNAV has two components: MNAV_RTS and MNAV_CTS. The MNAV_RTS is updated when receiving a MRTS with a non-zero Duration field. If MNAV_RTS is non-zero for a MT channel, a MP must decline a MRTS reservation request for that channel by sending a MCTS with Duration set to 0.

The MNAV_CTS is updated when receiving a MCTS with a non-zero Duration field. If MNAV_CTS is non-zero for a MT channel, a MP may not transmit on that channel. Both MNAV_RTS and MNAV_CTS are updated for all other NAV-setting requests.

2 Double NAV + MACK

An exposed node can either transmit or receive transmissions, but not both. Therefore, its NAV must distinguish which of the two it is can do. To this end, the NAV maintained by a MP for each MT channel has two components: the MNAV_RTS and the MNAV_CTS.

The MNAV_RTS is updated when receiving a MRTS with a non-zero Duration field. If MNAV_RTS is non-zero for a MT channel, a MP must decline a MRTS reservation request for that channel by sending a MCTS with Duration set to 0.

The MNAV_CTS is updated when receiving a MCTS with a non-zero Duration field. If MNAV_CTS is non-zero for a MT channel, a MP may not transmit on that channel. Both MNAV_RTS and MNAV_CTS are updated for all other NAV-setting requests.

The double NAV enables an exposed MP to either receive or transmit without interfering with the transmission for which the channel is reserved through the RTS/CTS. A transmission to or from an exposed MP would interfere however with the acknowledgment, which is transmitted in the opposite direction. To avoid such collisions, the acknowledgement can be transmitted on the control channel. In other words, use of the M-ACK, an acknowledgement transmitted on the control channel following transmission of a TXOP on a MT channel, would be needed for acknowledgement to enable a WLAN mesh to prevent exposed nodes.

5 Mixing BSS traffic and forwarding traffic

When a mesh point is also an AP, a MT channel can be the same physical channel as that used by the associated BSS. Similarly, a mesh point may be a station with its own application traffic in addition to the mesh (forwarding) traffic. The proposed MMAC protocol provides mechanisms that differentiate between BSS and mesh traffic and allow for congestion control and QoS management. Alternatively, a radio in a multi-radio MP may be shared by BSS or application traffic and mesh traffic.

1 Sharing the same channel

To avoid collisions between mesh traffic and BSS traffic of a mesh AP, channels can be shared in time. The MAP can reserve a MT channel for BSS traffic by sending a MCTS addressed to itself. The MCTS indicates the MT channel a MAP has selected for use in the BSS and the length of the time interval for which the BSS will have exclusive used of the MT channel. Stations in the BSS may transmit to the MAP, or among themselves, and the MAP may transmit frames to the stations during the reserved time interval. This time interval is made short, and the MAP does not reserve the channel again until some time has elapsed to permit others to use of the channel.

In order to block use of the BSS channel by the BSS stations when it is not reserved, the MAP must send a frame that will set the NAV in the BSS and thus prevent all legacy and 11e stations from accessing the BSS channel for a specified time interval. At the same time, any MP radios listening to the BSS channel must not adjust their NAV for the BSS channel according to the Duration field of this frame. To do this, the MAP sends a QoS CF-Poll frame addressed to itself. The Duration field contains the time interval for which the BSS stations must refrain from accessing the BSS channel. Stations in the BSS will adjust their NAV accordingly. MPs will disregard such a frame. Therefore, MPs hearing a QoS CF-Poll with the same MAC address in Address1 and Address2 fields of the MAC header and non-zero Duration value will ignore such a frame, and not adjust their NAVs according to the Duration field.

The above approach also provides a means of addressing the problem of overlapping [co-channel] BSS using HCCA, which assumes contention-free access to the BSS channel.

2 Sharing the same radio

A MT radio can be shared between mesh traffic and BSS traffic of a MAP.

To switch a radio between serving the BSS and the mesh, a MAP can block BSS transmissions from its stations. As done, above, the MAP sends a QoS CF-Poll frame addressed to itself on the BSS channel, specifying in the Duration field the time interval for which the BSS must refrain from accessing the channel. Stations in the BSS will adjust their NAV accordingly. MPs will not adjust their NAV when they hear a QoS CF poll with the same MAC address in Address1 and Address2 fields of the MAC header and non-zero Duration value. During that time interval, the MAP radio can be set to any MT channel, reserved by an MRTS sent to a mesh neighbor, to transmit mesh traffic.

6 Co-existence of wireless mesh with independent WLANs

When a wireless mesh network is located in an area with independent wireless LAN use, they must share the wireless channels using existing channel access protocols. Mesh and independent WLAN traffic share channels as equals. Frames of forwarded mesh traffic streams will be transmitted using the EDCA access protocol, based on the user priority of the traffic, just like frames from an independent WLAN. In the event a reserved MT channel is occupied by an independent wireless LAN transmission, the MTXOP transmission will be delayed and the reservation will be extended. The forwarding MP can extend the reservation by sending a second MRTS before the original reservation expires.

An exception to equal access is mesh control traffic. Mesh control traffic will access the control channel with higher priority than the frames from independent WLANs. The reason for prioritizing control traffic is to expedite reservations for the MT channels, thus enabling forwarded traffic to contend for the MT channels on an equal footing with independent WLAN traffic. Prioritization of control traffic does not penalize independent traffic seriously because control traffic is light compared to mesh forwarded traffic (assuming that MTXOPs are long).

7 Tx power control

Transmit power control reduces battery drain. When MPs are sufficiently close to be able to deliver the required signal strength to one another with a reduced transmitted power level, they can engage in power control. [3] For fixed (immobile) MPs, the required transmit power level can be determined during link establishment. For mobile MPs, however, it is useful to be able to determine the required transmit power at the time of each transmission. This is achieved by transmitting the MRTS/MCTS at known power levels. This provides information to a pair of MPs on the signal attenuation between them. The attenuation is used to set the transmit power for the delivery of mesh traffic at the desired signal strength.

In addition to extending battery life, transmit power control helps increase MT channel reuse when control and mesh traffic are carried on separate channels. As MT channels are assigned on demand (based on the observed interference), they can be re-used at closer distances if MPs reduce transmit power.

Discussion

A mesh MAC protocol was described, which in its simplest form, the CCC framework, provides the simplest asynchronous MMAC protocol presented to 802.11 TGs. Optional features add more capabilities to the MMAC protocol, making CCC competitive with any other protocol. Table 1 gives a summary of the various features and the capabilities they add to a mesh network.

Table 1 Summary description of CCC features

|Feature |Description |Capability |

| |Common control channel – CCC framework (p 4) |Multi-channel capability (p 6) |

| |Three-way reservation handshake [optional] (p 7) |Reclaim unused reserved channel time (p 7) |

| | |Per MTXOP negotiation of PHY Tx rate (p 7) |

| | |Informed reservation retry (p 7) |

| |Mesh Ack [optional] (p 8) |Avoid adjacent Channel Interference (p 10) |

| | |Eliminate exposed node problem (p 13) |

| |Two-step NAV setting [optional] (p 12) |Eliminate hidden terminal problem (p 11) |

| |Two NAV components [optional] (p 14) |Eliminate exposed node problem (p 13) |

| |Extending an on-going transmission [optional] (p 8) |Co-existence of wireless mesh with independent WLANs (p 15) |

| |Generalized Adaptive Prioritization [optional] (p 8) |QoS and congestion control (p 8) |

| | Residual Lifetime [optional] (p 9) |Bounds the delay, increases throughput (reduces dropped-frame rate), |

| | |and eliminates looping (p 9) |

| | Congestion-aware ACs [optional] (p 9) |Eases bottlenecks (p 9) |

| |NAV Time Filtering and AIFR [optional] (p 9) |Improved priority differentiation (p 9) |

| | |Efficient utilization of MT channels (p 9) |

| |MCTS and QoS-CF-Poll to self [optional] (p 14) |Sharing radio and/or channel by BSS traffic and forwarding traffic |

| | |(p 14) |

The CCC protocol has multiple advantages. These are:

– Ease of administration/ implementation

Foremost is the simplicity of implementation and administration. Channel assignment, the determination of a channel to be used for the transmission of mesh forwarding traffic that occurs either upon initialisation of a mesh or when recovering from a MP outage, is made easy with CCC. In general, channel assignment is a tedious process for a managed mesh network, and difficult for an unmanaged mesh comprising a collection of MPs from different vendors. The selection of the control channel in CCC is straightforward. A MP can determine its mesh traffic channel on per-transmission basis. There are no complex re-use relationships to consider or any optimisation be performed in CCC. Good performance is a direct consequence of the flexibility afforded MPs in changing mesh traffic channels. .

Signalling and beacon monitoring also becomes easy in CCC. With all beacons transmitted on a single control channel, beacon scanning is simple and fast. MPs need not scan all channels and monitor each channel separately, sufficiently long, waiting for beacons.

– No adjacent channel interference

CCC enables the use of multi-radio MPs. The MACK (group acknowledgement on the control channel) avoids ACI that would have otherwise been caused if two radios operating simultaneously on the same MP received/sent acknowledgements on the same channel as the transmission.

– Solves ‘hidden’ and ‘exposed’ node problems

New NAV rules eliminate the hidden and exposed node problems. The benefit of the new NAV rules is greatest when the control channel is on a separate physical channel than mesh traffic. If, for instance, a single radio MP puts its traffic on the control channel, the acknowledgements it sends or receives may collide with transmissions to/from exposed nodes, which will be allowed under the new NAV rules. Other MAC protocols can benefit from using the proposed NAV rules, with some but not as great benefit, for the reasons just explained.

– Extends battery life

CCC helps preserve battery life in multi-radio battery-powered MPs. A MP needs to keep only the radio powered constantly, the one tuned to the control channel powered, where notice of all transmissions directed to the MP will arrive. It need not keep all radios powered in order to be able to receive transmissions destined to it, as required with other MMAC protocols.

– Self-healing

An unscheduled outage of a MP can cause loss of connectivity and loss of data. It is important to recover quickly from such a disruption. The need for channel re-assignment before any signalling can be exchanged would increase recovery time. CCC speeds up recovery as the shared control remains unchanged and ready to carry the signalling needed to establish new links. No channel assignment is needed for the MT channels.

– Robust to independent WiFi use

Control traffic needs to be transmitted promptly. In a dense WLAN area, interference-free mesh channel assignment may not be possible and contention by independent WLAN traffic would be heavy. By separating mesh traffic from mesh control traffic (MRTS/MCTS), control traffic does not compete with mesh traffic. With priority access over WLAN traffic, control traffic will be transmitted fast and reliably. Mesh traffic may be sent on different channels, as they become available. The greater flexibility in channel selection reduces delay and collisions.

– Accommodates mobility

When MPs move, the distances and interference relationships between them may change. These changes can disrupt the communication between established links and new links/paths must be established for forwarding traffic. CCC expedites reconfiguration of the mesh topology because the channel on which signalling traffic is transmitted, the common control channel, is always there. With other protocols, new channels may need to be established before any signalling can be exchanged by the MPs. Communication between mobile MPs may thus be temporarily lost.

– QoS aware

QoS is provided in CCC by QoS-aware access mechanisms at the BSS and expediting forwarding on the mesh backbone. QoS prioritisation at the BSS of a MAP follows either of the 802.11e access mechanisms, HCCA or EDCA. Forwarding on the mesh backbone is prioritized by both EDCA and an enhanced prioritization mechanism, NAV time filtering. Prioritization helps achieve the following: distinguish between applications with different QoS requirements, bound delays of jitter sensitive applications, and reduce forwarding delays by eliminating traffic bottlenecks.

– Good throughput

The increased flexibility of selecting channels for the transmission of mesh traffic helps utilize channels that would be otherwise sitting idle and thus increases MT channel utilization and decreases forwarding delays. Another reason for increased MT channel utilization in CCC is the shorter reuse distance that results when dynamic MT channel selections reflect reductions in transmit power, leading to shorter re-use distances. The increase in MT channel utilization compensates for the reduction in the number of MT channels when restricting one channel to control traffic.

– Applies to meshes with mix of single and multi-radio MPs

CCC is flexible with respect of the number of radios available at the MP joining a mesh. A MP with any number of radios can join. While not limiting what MP can participate in a mesh, the protocol helps the mesh realize the performance enhancements possible from an increased number of radios, by allowing, for example, MPs with multiple radios to transmit and receive at the same time.

References

[1] IEEE Std 802.11, 1999 Edition, Part 11.

[2] IEEE, “Medium Access Control (MAC) Quality of Service Enhancements”, P802.11e/D13.0, January 2005

[3] D. Qiao et al, “MiSer: An Optimal Low-Energy Transmission Strategy for IEEE 802.11/h”, Proceedings ACM

MobiCom 2003, San Diego, CA, Sept 2003

[4] M. Benveniste, “Splicing in a Mesh Network

“, Doc IEEE 802.11-05/0454r1

[5] M. Benveniste, “Short presentation on the CCC protocol for mesh MAC

”

, Doc IEEE 802.11-05/0707r0

[6] M. Benveniste and Jeffrey Z. Tao, “Performance Evaluation of the CCC MMAC Protocol for 802.11s Mesh Networks”, Doc IEEE 802.11-05/0877r0

[7] J. Winters, S.A. Mujtaba, and M. Benveniste, “

Adjacent channel interference and its impact on the Mesh MAC”, Doc IEEE 802.11-05/0916r0

Appendix I

Additional Supporting Material

|Number |Name |Definition |Coverage |Notes |References |

| | | |(Yes/No) | | |

|AD1 |Reference |A list of IEEE 802 submissions related to the | |First introduced the |[1] M. Benveniste, “A |

| |submissions |proposal, both documents and presentations. | |single control channel |possible architecture for |

| | | | |based medium access |the |

| | | | |control protocol |Mesh Coordination |

| | | | | |Function”, IEEE |

| | | |Yes | |presentation |

| | | | | |802.11-05/0422r0 |

| | | | |First described the |[2] M. Benveniste, |

| | | | |channel splicing for mesh |“Splicing in a Mesh |

| | | | | |Network”, IEEE presentation|

| | | | | |802.11-05/0454r0 |

| | | | |Revision of [2] |[3] M. Benveniste, |

| | | | | |“Splicing in a Mesh |

| | | | | |Network”, IEEE presentation|

| | | | | |802.11-05/0454r1 |

| | | | |MMAC proposal |[4] M. Benveniste, “The CCC|

| | | | | |Mesh MAC Protocol |

| | | | | |”, IEEE presentation |

| | | | | |802.11-05/0610r0 |

|AD2 |Simulation and/or |Any proposal submission that includes simulation | |Simulation results and the| |

| |experimental |results must include a description of the | |corresponding methodology | |

| |methodology |simulation methodology used for mesh simulations.| |description will be | |

| | |The simulation methodology documentation should | |provided later on. | |

| | |provide enough information to, in principle, |Yes | | |

| | |reproduce the simulation (e.g., including node | | | |

| | |positions, traffic and propagation model | | | |

| | |(including PHY assumptions), packet sizes, etc.).| | | |

Coverage of Minimum Functional Requirements

|Number |Category |Name |Coverage |Notes |References |

| | | |(Complete /Partial/ | | |

| | | |None) | | |

|FR1 |TOPO_RT_FWD |Mesh Topology Discovery|None | | |

|FR2 |TOPO_RT_FWD |Mesh Routing Protocol |None | | |

|FR3 |TOPO_RT_FWD |Extensible Mesh Routing|None | | |

| | |Architecture | | | |

|FR4 |TOPO_RT_FWD |Mesh Broadcast Data |Partial |The proposal does not deal with | |

| | |Delivery | |topology, routing, or forwarding. The| |

| | | | |proposed MMAC protocol can be used | |

| | | | |for multicast/ broadcast traffic | |

|FR5 |TOPO_RT_FWD |Mesh Unicast Data |Complete |The proposal does not deal with | |

| | |Delivery | |topology, routing, or forwarding. The| |

| | | | |proposed MMAC protocol can be used | |

| | | | |for unicast traffic | |

|FR6 |TOPO_RT_FWD |Support for Single and |Complete |The proposed MMAC protocol can be |P 3 |

| | |Multiple Radios | |used for by single and multiple radio| |

| | | | |MPs | |

|FR7 |TOPO_RT_FWD |Mesh Network Size |Complete |The proposed MMAC protocol can be | |

| | | | |used in a wireless mesh of any size | |

|FR8 |SECURITY |Mesh Security |None | | |

|FR9 |MEAS |Radio-Aware Routing |Complete |The proposed MMAC protocol employs |P 6 |

| | |Metrics | |radio aware channel assignment | |

|FR10 |SERV_CMP |Backwards compatibility| |The proposed MMAC protocol is |P 11 |

| | |with legacy BSS and STA| |backward compatible with both legacy | |

| | | |Complete |BSS and legacy STA | |

|FR11 |SERV_CMP |Use of WDS 4-Addr Frame| |The proposed MMAC protocol uses WDS |P 4 |

| | |or Extension | |4-address frame format with certain | |

| | | |Complete |extensions | |

|FR12 |DISC_ASSOC |Discovery and | |The proposed MMAC protocol is |P 3 |

| | |Association with a WLAN|Partial |compatible with a variety of | |

| | |Mesh | |Discovery and Association methods | |

|FR13 |MMAC |Amendment to MAC with |Complete |The proposed MMAC protocol addresses |P 3 |

| | |no PHY changes required| |the problems encountered in the mesh | |

| | | | |environment, and is agnostic to PHY | |

| | | | |technologies | |

|FR14 |INTRWRK |Compatibility with |Partial |The proposed MMAC protocol does not | |

| | |higher-layer protocols | |make any assumption about | |

| | | | |higher-layer protocols and hence is | |

| | | | |compatible with them. | |

Coverage of In-Scope Functions (Informative)

|Number |Name |Coverage |Notes |References |

| | |Yes / No / N/A | | |

|Mesh Medium Access Coordination (MMAC) |

| MMAC_SCP1 |Mitigate performance degradation caused by |Yes |Use MRTS/ MCTS and 2-step |P 5, 9-10 |

| |hidden nodes | |NAV setting to address the| |

| | | |hidden node problem. | |

|MMAC_SCP2 |Mitigate performance degradation caused by |Yes |Use MRTS/ MCTS, and a |P 10 |

| |exposed nodes | |double NAV, in conjunction| |

| | | |with M-ACK | |

| | | |(acknowledgement on a | |

| | | |separate control channel) | |

| | | |to address the exposed | |

| | | |node problem | |

|MMAC_SCP3 |Flow control over multi-hop paths to avoid |Yes |“Residual lifetime” helps |P 7 - 8 |

| |performance degradation and/or meet QoS goals.| |in flow control and | |

| | | |prioritized access of MRTS| |

| | | |incl SIFS access expedite | |

| | | |reservations | |

|MMAC_SCP4 |Coordinating channel access across multiple |Yes |SIFS access of MRTS and |P 7 - 8 |

| |nodes to avoid performance degradation and/or | |prioritised access helps | |

| |meet QoS goals in the multi-hop network. | |reduce delay | |

|MMAC_SCP5 |Traffic prioritization within a WLAN Mesh |Yes |Based on EDCA with |P 7 |

| | | |enhanced access priority | |

| | | |definition. | |

| | | |Prioritization is further | |

| | | |enhanced with “NAV time | |

| | | |filtering” | |

|MMAC_SCP6 |Enhancements to make the MAC work well across |Yes |The common control channel| |

| |a range of different network sizes, usage | |approach helps coordinate | |

| |models, etc. | |channel access in all | |

| | | |types/sizes of mesh | |

| | | |networks | |

|MMAC_SCP7 |Mesh link communication coordination |Yes |The common control channel| |

| | | |approach helps | |

| | | |coordinating channel | |

| | | |access | |

|MMAC_SCP8 |Support for admission control to determine if |No | | |

| |a particular flow can be admitted into the | | | |

| |mesh network based on the availability of | | | |

| |resources and existing usages. | | | |

|MMAC_SCP9 |Management of multiple classes of traffic, for|Yes |A combination of MRTS and |P 11 |

| |example when both BSS traffic and mesh | |legacy CTS enables | |

| |forwarding traffic are present in one device | |management of co-existing | |

| |(e.g. in a Mesh AP). | |BSS and mesh traffic on | |

| | | |the same MAP | |

|MMAC_SCP10 |Rate control enhancements for efficient |No | | |

| |multicasting and broadcasting in a mesh | | | |

| |network. | | | |

|MMAC_SCP11 |Improving spatial reuse in a mesh network. |Yes |A separate common control |P 9-11 |

| | | |channel and resolving the | |

| | | |exposed node problem helps| |

| | | |improve the spatial reuse.| |

| | | |Also TX power control in | |

| | | |conjunction with a | |

| | | |separate common control | |

| | | |channel further improves | |

| | | |spatial channel reuse | |

|MMAC_SCP_Other | |N/A | | |

|Compatibility to 802.11 Services (SERV_CMP) |

|SERV_CMP_SCP1 |Mesh Point DS Services (DSS) Integration |Yes |Reuse the corresponding | |

| | | |parts of the legacy | |

| | | |protocol for these | |

| | | |aspects | |

|SERV_CMP_SCP2 |WLAN Mesh compatibility with STA |Partial |The common control |P 12 |

| |mobility/roaming | |channel facilitates | |

| | | |rapid communication when| |

| | | |spatial channel reuse | |

| | | |relations change as a | |

| | | |result of mobility | |

|SERV_CMP_SCP3 |Techniques to allow WLAN Mesh to meet 802.11r | | | |

| |system requirements |No | | |

|SERV_CMP_SCP4 |Dissemination of STA-to- destination MeshAP | | | |

| |or STA-to-destination Mesh Portal routing |No | | |

| |information in the WLAN Mesh. | | | |

|SERV_CMP_Other | |N/A | | |

|Mesh Interworking (INTRWRK) |

| INTRWRK_SCP1 |Allow a WLAN Mesh to interface with higher | | | |

| |layer protocols |No | | |

|INTRWRK_SCP2 |Interfacing a WLAN Mesh with other IEEE 802 |No | | |

| |LANs | | | |

|INTRWRK_SCP3 |Support for interfacing a WLAN Mesh with other| | | |

| |IEEE 802 LANs using 802.1D |No | | |

|INTRWRK_SCP4 |Support for efficient utilization of multiple | | | |

| |Mesh Portals in a single WLAN Mesh. |No | | |

|INTRWRK_SCP_Other | |N/A | | |

|Mesh Configuration and Management (CFG_MGMT) |

|CFG_MGMT_SCP1 |Protocol extensions to support | |Channel monitoring and |P 6 |

| |self-configuring formation of a WLAN Mesh |yes |maintaining NAVs on | |

| |network | |permissible channel sets| |

| | | |enables distributed | |

| | | |channel assignment (self| |

| | | |RF engineering) | |

|CFG_MGMT_SCP2 |Interfaces to support 802.11h DFS compliancy |No | | |

|CFG_MGMT_SCP3 |Interfaces and parameter exchange to enable RF| | | |

| |auto configuration support |No | | |

|CFG_MGMT_SCP4 |Support for managed network management model |yes |The proposed MMAC | |

| | | |protocol can be used and| |

| | | |enhanced by a network | |

| | | |manager/ controller | |

|CFG_MGMT_SCP5 |Support for unmanaged network management model|yes |The proposed MMAC | |

| | | |protocol can be used by | |

| | | |an unmanaged mesh | |

| | | |consisting of | |

| | | |multi-vendor mesh points| |

|CFG_MGMT_SCP6 |Interfaces and parameter exchange to exchange |No | | |

| |information about the capabilities of Mesh | | | |

| |Point devices | | | |

|CFG_MGMT_SCP7 |Mesh network channel selection |Yes |The common control |P 6 |

| | | |channel approach | |

| | | |naturally provides a | |

| | | |mechanism for dynamic | |

| | | |channel assignment | |

|CFG_MGMT_SCP8 |Mesh network Tx power control |yes |MRTS/MCTS provide the |P 11 |

| | | |information needed for | |

| | | |Tx power control on mesh| |

| | | |traffic transmissions | |

|CFG_MGMT_SCP9 |QoS policy and management |Yes |Use enhanced prioritised|P 6-8 |

| | | |access (EDCA plus NAV | |

| | | |time filtering), in | |

| | | |conjunction with | |

| | | |“residual lifetime” | |

|CFG_MGMT_SCP10 |Support for time synchronization of Mesh |yes |The TSF function for |P 8 |

| |Points if required by mesh services | |IBSS can be used with | |

| | | |the common control | |

| | | |channel approach | |

|CFG_MGMT_SCP_Other | |N/A | | |

-----------------------

[1] For a description of the legacy NAV see Clause IEEE 802.11-1999 standard in [1]

[2] MPs can synchronize their local clocks by the method used for TSF synchronization in an IBSS (IEEE 802.11-1999 standard).

[3] The NAV timer of a channel indicates the time that must elapse before the channel becomes idle.

[4] The transmit range is the range within which all nodes can hear the transmission and are able to decode it.

-----------------------

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

Abstract

A protocol is presented for wireless mesh networks, encompassing channel assignment, medium access, and priority management . The central features of this protocol include a universally shared channel for control signals and an enhanced channel-access-control system. Particular strengths are ease of implementation, modest computational requirements, tolerance for mobility of mesh points and changes in radio environment, accommodation of QoS needs and throughput maintenance when overloaded. Optional protocol features enable the avoidance of adjacent channel interference and the exposed node and hidden node problems, and provide congestion control.

Simulation results on the performance of the protocol, called the Common Control Channel (CCC) MMAC protocol appear in reference [6].

I

II

MT channels

CC

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download