1. Splicing in a Mesh Network
Month Year
doc.: IEEE yy/xxxxr0
June 2005
Splicing in a Mesh Network
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Mathilde Benveniste, Avaya Labs
John Doe, Some Company

2. ‘Splicing’ in a mesh network
June 2005
‘Splicing’ in a mesh network
Mathilde Benveniste
Mathilde Benveniste, Avaya Labs

3. June 2005
Introduction
The CCC protocol that enables reservation of mesh traffic (MT) channels to be made on a single control channel monitored by all MPs is presented in Doc IEEE r0
We have discussed how interference from users of the same RF spectrum band in various BSSs associated with the mesh can be prevented
We are concerned here with interference caused by independent systems operating on the same RF spectrum or other sources
Such interference includes channel uses covered by h DFS provisions
Two types of interferers are considered:
Those operating on channels used for mesh traffic
Those operating on the mesh control channel
Mesh traffic channels serving independent co-channel users are avoided by limiting channel selection within a set of permissible channels for each mesh point
We show how the control channel can be changed, or “spliced” to operate on two different physical channels, in order to avoid interference from/to mesh-independent sources
Mathilde Benveniste, Avaya Labs

4. Permissible Set of MT channels
June 2005
Permissible Set of MT channels
APs that are independent of a mesh may operate in the neighborhood of mesh points on the same channel. As a consequence the channel should be avoided as either a control channel or a mesh traffic channel
A "permissible“ set of channels is maintained by an MP; the MP select its MT channels from the permissible set
The permissible set contains 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
802.11h DFS considerations may also cause a channel to be removed from the permissible set
Mathilde Benveniste, Avaya Labs

5. Control Channel Change
June 2005
Control Channel Change
Independent APs operating in the mesh area, on the same channel as the mesh control channel, may force a nearby MP to request a change of the control channel
802.11h DFS considerations may also require change of the control channel
A control channel change is accommodated either by forwarding the control channel change request to all MPs, or by “splicing” the channel
We show how these requests are performed
Mathilde Benveniste, Avaya Labs

6. Forwarding a request June 2005
1 independent AP, L, operates
in the mesh area on the same channel as the mesh control channel; MP G requests control
channel change. Request is forwarded by all MPs. Control channel is changed in mesh.
Forwarding MP
Control channel
Forwarding MP
Traffic channel B H
Authorizing MP A
Authorizing MP
Mesh point F F
Independent point L
Requesting MP
Authorizing MP G D
Authorizing MP E I
If a MP receives a request for control channel change, it may do one of the following:
Accept the request
Forward the request to all other neighbors, or
Decline the request
Mathilde Benveniste, Avaya Labs

7. Splicing: changing control channel
June 2005
Splicing: changing control channel
Splice
Authorizing MP
Control channel
1 independent AP, L,
operates in the mesh area
on the same channel as the
mesh control channel;
MP G requests control
channel change
Traffic channel B H A
Mesh point F F
Independent point
Authorizing MP L
Requesting MP G D
Authorizing MP E I
A MP may send requests to its mesh neighbors for permission to use a different control channel
If the request is authorized,
The requesting MP will tune its control radio to the requested channel
If an authorizing MP has no other mesh neighbors, it will tune its control radio to the requested channel
If an authorizing MP has other mesh neighbors it will tune a MT radio to the requested control channel
In that case, if the authorizing MP has no additional MT radios, it will use the control channels for mesh traffic to its mesh neighbors
Mathilde Benveniste, Avaya Labs

8. Procedure for Splicing
June 2005
A MP may request its mesh neighbors for permission to use a different control channel
If a MP receives a request for control channel change, it may do one of the following:
Accept the request
Forward the request, or
Decline the request
A MP that accepts or declines a request or receives notice that a request it forwarded is accepted will notify the mesh neighbor from which it received the request
A MP will consider its own or forwarded request accepted if all mesh neighbors to which it sent the request indicate that the request is accepted
A request is authorized if it is considered accepted by the requesting MP
If a request is authorized, the MP that submitted the request will determine the time the control channel will change and will forward this time to all MPs that accepted the control channel change
A MP that forwarded or submitted an authorized request will tune its control radio to the requested channel at the specified time
If a MP that accepted an authorized request has no mesh neighbors other than the MP that sent the request, it will tune its control radio to the requested channel at the specified time
If an authorizing MP has mesh neighbors other than the MP that sent it the request, it will tune a MT radio to the requested control channel at the specified time and use it for control traffic
In that case, if the authorizing MP has no additional MT radios, it will use the control channels for mesh traffic to its mesh neighbors
If the request is not authorized, the requesting MP may resubmit a request for a different control channel
Mathilde Benveniste, Avaya Labs