doc.: ieee 802.11-05/0422r0 submission may 2005 mathilde benveniste, avaya labsslide 1 a possible...

21
May 200 5 Mathi lde B enven Slide 1 doc.: IEEE 802.11-05/0422r0 Submission A possible architecture for the Mesh Coordination Function 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 <[email protected]> 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 Date: 2005-05-11 N am e C om pany A ddress Phone em ail M athilde Benveniste A vaya Labs 233 M tA iry R oad B asking Ridge, N J 07920 973 7616105 benveniste@ ieee.org Authors:

Upload: annis-ramsey

Post on 18-Jan-2016

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 1

doc.: IEEE 802.11-05/0422r0

Submission

A possible architecture for the Mesh Coordination Function

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 <[email protected]> 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 <[email protected]>.

Date: 2005-05-11

Name Company Address Phone email Mathilde Benveniste

Avaya Labs 233 Mt Airy Road Basking Ridge, NJ 07920

973 7616105 [email protected]

Authors:

Page 2: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 2

doc.: IEEE 802.11-05/0422r0

Submission

A possible architecture for the Mesh Coordination Function

Mathilde BenvenisteAvaya Labs - Research

Page 3: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 3

doc.: IEEE 802.11-05/0422r0

Submission

Common Control Channel (CCC) Protocol

CCC is “single-link” channel access protocol

• Provides a way for mesh points to access their assigned/selected channels in order to forward received frames to next hop

Discovery/topology/routing – determined independently

• It is assumed that the discovery, topology, and routing functions have determined how mesh traffic is routed

Transmit/receive capabilities - known

• The capabilities of a receiver and transmitter are known (determined by appropriate handshake during discovery); e.g.– PHY protocol/transmit rate– Antenna configuration/MIMO parameters

Page 4: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 4

doc.: IEEE 802.11-05/0422r0

Submission

Challenges met with the CCC protocol

One MCF protocol for all meshes - single and multi-radio Works for mixed number of radios

– No restrictions imposed on the type (w.r.t. radios) of mesh points participating in mesh – The protocol allows the efficiency of the mesh network to increase with more radios and

channels– It does not prevent mesh points with fewer channels or radios from participating

Good for either infrastructure (containing portal) or peer-to-peer mesh– CCC protocol applies independently of mesh point relationship (parent/offspring)

Applies to managed and unmanaged mesh– The same protocol can be used with both a distributed multi-vendor and a managed

mesh network

Mobility friendly– Avoids excessive mesh delay or loss of frames that may result from changing the spatial

relationships of mesh points

Robust to independent WLANs – Can co-exist with WiFi users operating in the same area as the mesh

QoS aware– Minimizes mesh transmit delay and jitter

Page 5: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 5

doc.: IEEE 802.11-05/0422r0

Submission

Definition of logical channels

“Control Channel”• There is a single control (logical) channel for control messaging*

• This channel is used by each MP for time reservations on MT channel(s)

• The control channel does not change dynamically (fast)

• The same control channel can serve diverse PHY MT channels (11b, g, a, …)

“Mesh Traffic Channel(s)”• The traffic channel is used by MPs to transmit mesh traffic to a mesh neighbor

• Each MP may either transmit on the same MT channel(s) always, or select MT channel on demand (dynamic channel assignment)

• A MT channel can be the channel used by a mesh AP

________________

* A complete mesh might have to be segmented into zones, where the control channel in one zone is different from the control channel in another, with a particular 'splice' MP using both channels, as a control and as MT channel [See Doc IEEE802.11-5-0454r0]

Page 6: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 6

doc.: IEEE 802.11-05/0422r0

Submission

CommonControlChannel

MTChannel 3

MTChannel 1

MTChannel 2

time

Control channel for reservations

• MPs reserve time on various mesh traffic (MT) channels by exchanging MRTS/MCTS pair on the control channel of the mesh

• The same control channel can serve diverse MT channels (11b, g, a, …)

Multi-channel generalization of CSMA/CA

Reserve MT channel 1

MR

TS

MR

TS

MR

TS

Reserve MT channel 3

MR

TSReserve MT channel 1

Reserve MT channel 2

MTXOPMTXOP

MTXOP MTXOP

MTXOP MTXOP

MC

TS

MC

TS

MC

TS

MC

TS

Page 7: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 7

doc.: IEEE 802.11-05/0422r0

Submission

CCC summary

Summary• A MP transmits mesh traffic on its assigned/selected channel, the mesh traffic

(MT) channel. (The selection of the MT channel for transmission is independent of this protocol. See slide 9.)

• A MP monitors the control channel, where mesh traffic channel reservations are made

• The source MP requests a reservation on a specific channel; the destination MP accepts, extends, or declines the channel reservation request

• A reservation request is declined if the destination MP deems the requested channel busy, or if it has no available radios to receive the transmission

• If the reservation request is declined, but the destination MP has available radios, a different channel may be selected for reservation by the source MP

Page 8: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 8

doc.: IEEE 802.11-05/0422r0

Submission

Channel access

Control Channel AccessA MP will follow the rules of the prioritized contention-based channel access

protocol (like the EDCA protocol of 802.11e)– User priority and the congestion conditions at the AP determine access priority (See

Slide 15)

MT Channel Access• A MP transmits mesh traffic on a MT channel on which a reservation has

been secured • If no independent APs operate on the same channel, in the same area, the

transmission will start after a PIFS time interval– Provided the CCS indication on the MT channel is idle, the MP will transmit after a

PIFS idle

• Contention based access is used for transmission on the MT channel in order to avoid collisions with independent WLAN(s) operating in the same area, on the same channel – In the event of a collision due to independent transmissions on the MT channel, the

MP will attempt re-transmission using the rules of the CSMA/CA protocol

Page 9: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 9

doc.: IEEE 802.11-05/0422r0

Submission

Permissible Set of MT channels

A "permissible” set of channels is maintained by an MP; the MP select its MT channels from the permissible setThe permissible set contains clean channels that are not heavily loaded with

non-mesh traffic or traffic from a non-mesh-associated BSS

Channels are monitored regularly in order to avoid such channels from being included in the permissible set, which is updated over time  If an independent AP powers on and chooses to operate on one of the

permissible channels, that channel is removed from the permissible set.  

Permissible channels may be ranked in order of desirability of the channel, using different metricsOne such metric metric would be traffic load, to avoid co-channel interference

(i.e. collisions with other users of the channel)

Page 10: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 10

doc.: IEEE 802.11-05/0422r0

Submission

MCF overview Mesh Transmit Opportunity (MTXOP)• A sequence of frames can be transmitted from one MP to another with a single

contention – A MP with frames to transmit to another MP will contend on the control channel using EDCA to

reserve its assigned MT channel for the transmission of the frame sequence

MT Channel State• A MP maintains a MNAV for each of the permissible MT channels; in the absence

of any restrictions, all channels are monitored– MNAV[MT] is the timer indicating when the MT channel will become idle– A positive MNAV[MT] value indicates that the MT channel is busy

• The MNAV for a MT channel is set by tracking the following: – the NAV-setting requests of the MRTS and MCTS exchanged on the control channel for

reservation of the MT of the MT channel and – the NAV-setting requests received on a MT channel while a MT radio is tuned to that channel

Radio Counter• A MP will maintain the Radio Counter for the number of radios it has available to

receive a mesh transmission. – Example: When a reservation is made to send mesh traffic to a MP, its Radio Counter is

decremented by 1. When the reservation expires, the Radio Counter is incremented by 1

Page 11: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 11

doc.: IEEE 802.11-05/0422r0

Submission

MCF overview - 2MT Channel Reservation • The source MP will reserve its chosen MT channel for an MTXOP by

sending a MRTS frame to the destination MP on the control channel – The MT channel is selected from among a set of “permissible” channels

maintained by a MP

• The Channel_State indication for the MT channel must be idle when transmission starts on the MT channel

• The MRTS is an expanded RTS; it includes: – The MT channel– The Duration field, whose value will be at least the time needed for the MTXOP

transmission, and the number of frames in the MTXOP

The destination MP sends a MCTS within a time interval of SIFS, as the reservation response

A reservation request is accepted if – The destination MP has an expired MNAV timer for MT channel indicated in the

MRTS, and– The destination MP has available radios to receive the transmission; i.e. the Radio

Counter is non-zero

Page 12: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 12

doc.: IEEE 802.11-05/0422r0

Submission

MCF overview - 3MT Channel Reservation Response• If the reservation request is accepted,

– the Duration field is adjusted and the number of frames in the MTXOP is repeated in the MCTS sent by the destination MP

– the MCTS includes also the number of its radios that remain available to receive traffic – that is the Radio Counter

– the destination MP updates its NAV

• If the reservation request is declined, – the Duration field in the MCTS is set to 0– the destination MP does not update its NAV – the source MP in that case sends another MRTS with a Duration field set to 0 to

cancel the NAV set by neighbors for the requested MT channel; no MCTS is returned to such an MRTS

• If the reservation is extended, – The Duration field is greater than the adjusted value of the Duration field in the

MRTS received– The source MP in that case sends another MRTS with the Duration containing the

extended value, and the Number of frames field set to 0 to signal that no MCTS is needed in reply

Page 13: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 13

doc.: IEEE 802.11-05/0422r0

Submission

MCF overview - 4MT channel transmission• If a MP receives a MCTS indicating the requested MT channel in response

to a MRTS it sent, it will transmit on a MT channel if the MCTS contains a nonzero value in the Duration field

Acknowledgement• The destination MP will acknowledge the status of the transmitted

sequence • Acknowledgement may be sent either

– on the MT channel (as done in 802.11 and 802.11e), or

– on the control channel, by sending a group acknowledgement, called MACK

Page 14: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 14

doc.: IEEE 802.11-05/0422r0

Submission

CCC, Dynamic channel assignment, and Mobility

The CCC MCF enables dynamic channel assignment and facilitates mobility

Dynamic channel assignmentIf the most desirable channel is unavailable (busy), the MP can select another

permissible channel to transmit mesh data

A MP will tune a MT radio to the new MT channel as soon as possible, and no later than when it sends a MRTS or receives a MRTS on which it is the destination MP and contains a nonzero value in the Duration field, if the MRTS is accepted

MobilityAs MPs move possibly relative to one another, their changed separation and

interference relationships may cause channels to be no longer permissible

By maintaining MNAVs for the permissible MT channels, a MP can determine the availability of a MT channel without the need to scan multiple channels

Page 15: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 15

doc.: IEEE 802.11-05/0422r0

Submission

B

A

C

D

E

F

G

H

I

J

No interference-free link

CCC and independent WLANs

Figure illustrates a mesh co-existing with independent WLAN traffic when 3 channels are available

No interference-free mesh channel assignment in dense WLAN area

Solution: Separate mesh (data) traffic from mesh control traffic (RTS/CTS)

Advantages: • Control traffic is light; can co-exist with

independent WLAN traffic • Mesh traffic may be sent on different channels,

as they become available; the greater flexibility in channel selection reduces collisions

• By monitoring the control channel, mobile MPs have current status of the availability of traffic channels at all times

Independent AP

Page 16: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 16

doc.: IEEE 802.11-05/0422r0

Submission

Frames Definitions

MTXOP (mesh transmit sequence) = a sequence of frames transmitted between a pair of MPs following a single contention for the channel

Source MP = the MP initiating a MTXOPDestination MP = the MP receiving a MTXOP

FRAMESMRTS: used by a MP initiating a MTXOP

Contents: source MP; destination MP; source MP transmit channel; Duration; Number of Frames in MTXOP; other

MCTS: used by a MP accepting a MTXOPContents: source MP; source MP transmit channel; Duration; Number of Frames in

MTXOP; Radio Counter; other

MACK: identifies the individual frame in a sequence of frames that were received successfully (similar to 802.11e Group Ack)Contents: destination MP; source MP; source MP transmit channel; MTXOP frame receipt

status

Page 17: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 17

doc.: IEEE 802.11-05/0422r0

Submission

Prioritization of mesh traffic

• A priority-based MAC protocol will be employed (e.g. EDCA, 802.11e) by the MRTS when contending to get on the control channel– The MRTS used to reserve channel time for an MTXOP has an associated priority, which

determines the channel access parameters

• The MRTS priority will be a combination of the two priorities: – MTXOP user priority is specific to the MTXOP contents

– Mesh point priority reflects the congestion condition at the MP

The source MP has the information needed to determine the MRTS priority

Page 18: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 18

doc.: IEEE 802.11-05/0422r0

Submission

QOS – MTXOP user priority

User priority• The MRTS reserving MT channel time for a MTXOP will be assigned a

priority that will depend on the user priority of frames in the MTXOP in order to give priority to time-sensitive frames in a congested mesh– Based on the user priority, frames are assigned an AC (access category); the channel

access parameters (AIFSN, CWMin, CWMax) and MTXOPLimit are specified for an AC

– The MTXOP user priority is derived from the priority of the frames included in the MTXOP

Page 19: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 19

doc.: IEEE 802.11-05/0422r0

Submission

QOS – MTXOP user priority

Residual lifetime• The MRTS channel access parameters will be adjusted for the residual life of

the MXTS frames (as frames close to being dropped may take on greater urgency to transmit depending on the AC); the adjustment will thus depend on the remaining lifetime

• When a frame enters the mesh at a MAP, it starts a timer, which is set to the frame age after which it will be dropped. This timer gives the residual lifetime of the frame as the frame travels from node to node across the mesh

• The MRTS for a MTXOP containing a frame with remaining lifetime below a specified threshold will have its priority increased

Page 20: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 20

doc.: IEEE 802.11-05/0422r0

Submission

QOS – Mesh point priorityCongestion control• The mesh traffic load on different MPs will vary; backed up queues cause excessive

delays and bottlenecks – For example, a MP closer to a portal has typically more traffic to transmit than a MP further

away; therefore, it will be allowed faster channel access• Mesh bottlenecks are avoided by expediting channel access by MPs with heavy mesh

traffic loads

– An MRTS of a given MTXOP user priority will be able to gain access to the control channel faster if its source MP has long mesh traffic queues

• A mesh point priority is combined with the MTXOP user priority to determine the access parameters of a MRTS – Different source MPs will have different mesh priority, which may change over time– The mesh priority will depend on the queued traffic adjusted for the number of transmit

radios at the MP• The mesh priority will be higher for MPs with longer queues • To balance loads across all channels, MPs with fewer transmitting radios need more help to reduce

congestion

• When multiple queues are used for prioritization purposes (as in EDCA), a weighted queue size will be used favoring higher-priority queues

Page 21: Doc.: IEEE 802.11-05/0422r0 Submission May 2005 Mathilde Benveniste, Avaya LabsSlide 1 A possible architecture for the Mesh Coordination Function Notice:

May 2005

Mathilde Benveniste, Avaya Labs

Slide 21

doc.: IEEE 802.11-05/0422r0

Submission

Attributes of CCC ProtocolMulti-channel generalization of CSMA/CA

Increased throughput– Makes use of all available channel capacity through flexible channel assignment

– Avoids collisions by tracking channel use on control channel

Provides a seamless solution for mobility

Works with any number of radios

Works for both managed and unmanaged mesh networks

Works with either infrastructure or peer-to-peer mesh networks

Provides prioritization of QoS