IEEE P802.11 Wireless Lans s65

May 2007 doc.: IEEE 802.11-07/0685r0

IEEE P802.11 Wireless LANs

Comment Resolution for Synchronization

Date: 2007-05-14

Author(s): Name Company Address Phone email Hrishikesh 1064 Greenwood Blvd, Suite Motorola 407-562-4093 Hrishikesh.Gossain@ Gossain 400, Lake Mary, FL: 32746 motorola.com 1301 East Algonquin Rd., Steve Emeott Motorola 847-576-8268 Steve.Emeott@motor Schaumburg, IL 60008 ola.com

Abstract This document provides comment resolution for a set of CIDs relevant to synchronization in MPs. The CIDs and the corresponding section are

11A.8.1: 761, 1127, 5535, 5536 11A.8.2: 687, 1310, 4691 11A.8.2.1: 763, 1124, 3566, 3888 11A.8.2.2: 60, 688, 764, 1574, 4444, 4692, 5541, 5663

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 .

Submission page 1 Steve Emeott, Motorola Inc. May 2007 doc.: IEEE 802.11-07/0685r0

Summary of Changes

This document provides the comment resolution relevant to synchronization clause of TGs draft. It clarifies the definition of synchronizing and unsynchronizing MPs. It removes the transitions between synchronzing and unsynchronizing modes. Now an MP would be either operating as a synchronizing or unsynchronizing mode. In synchronizing mode an MP could possibly operate in three states namely Active, Transient and Standby states. Out of these three states, an MP needs to actively synchronize with its peers only if it’s operating in Active or Transient state, which localizes the effect of synchronization in the mesh. To illustrate this behaviour please refer to Figure xxx. Figure xxx gives an example of state transition of four synchronizing MP. In the example, when MP 2 receives a synchronization request from MP 1 it transitions to Transient state where as MP 1 which is requesting synchronization from its peers transitions to Active state. MP 3 and 4 which are out of range of MP 1 continues to operate in Standby state. By localizing the effect of synchronization, MPs which are operating in Standby state does not need to maintain extra state information relevant to synchronization. For example, they do not need to track Mesh TSF or maintain offset information unless needed. In a way the behaviour of Standby MP is similar to the behaviour of unsynchronizing MP.

1 2 3 4

Standby Standby Standby Standby

(a) Initially all the MPs are in Standby state ,

1 2 3 4

Active Transient Standby Standby (b) MP 2 transitions to transient state after a synchronization request from 1. MP 3 and 4 which are out of range of 1 stay in Standby state.

Figure xxx – Example state transition in Synchronizing MP based on peer request

Proposed Changes:

Replace section 11A.10.1 and 11A.10.2 of D1.03 as follows

11A.1010 Mesh Beaconing and Synchronization

11A.10.1 Synchronization

Mesh synchronization and beacon generation services are based upon the procedures defined in clause 11.1 for Infrastructure and IBSS modes of operation.

Two synchronization modes are defined for MP, namely unsynchronizing and synchronizing. The synchronization mode of each MP shall be advertised in the Synchronization Capability fields of its WLAN Mesh Capability element, as described in clauses 11A.10.1.1 and 11A.10.1.2

Peer links can be established between synchronizing MPs, between unsynchronizing MPs and between synchronizing and unsynchronizing MPs.

When a peer link is established between synchronizing and unsynchronizing MP, synchronizing MP shall track both the mesh TSF timer and the TSF timer of any unsynchronizing MP with which it has an established peer link.

11A.10.1.1 Unsynchronizing MPs

An unsynchronizing MP is a MP that maintains an independent TSF timer and does not update the value of its TSF timer based on time stamps and offsets received in beacons or probe responses from other MPs. It starts its TSF timer independent of other MPs. An MP that sets its Supporting Synchronization bit of Synchronization Capabiliy field to 0 shall be an unsynchronizing MP.

11A.10.1.2 Synchronizing MPs

An MP that updates its TSF timer based on the time stamps and offsets received from peer MP is a synchronizing MP. Synchronizing MPs shall maintain a common TSF time called the Mesh TSF time and should always set the Supporting Synchronization bit of Synchronizaiton Capabililty Field to 1. In case MP requires synchronization from its peers it should set the “Request Synchronization from Peer” sub-field of Synchronization Capability field to 1.

An MP that supports mesh synchronization operates in one of three synchronization states: Active, Transient, and Standby. Figure xxx below outlines the state transition diagram of a synchronizing MP.

Active Transient Standby

Figure xxx –State transition diagram of an MP operating in Synchronizing Mode

In Table xxx, each row represents state transitions from a given synchroning state to all other states. It is to be noted that the state transition from one synchronization state to another is triggered by SME. SME at a

Submission page 3 Steve Emeott, Motorola Inc. May 2007 doc.: IEEE 802.11-07/0685r0 given MP can autonomously decide to transition from one synchronizing state to another by using the MLME-SAP depending on its application requirements and synchronization requirements of its peers.

Table xxx – MP Synchronization state transition based on SME request

To State

Active Transient Standby e t Active - (1) MLME-SYNCH.Request (6) MLME- a t

S (SS =1, SP = 1, RS = 0) SYNCH.Request (SS =1,

m SP = 0, RS = 0) o r F Transient (4) MLME- - (2) MLME- SYNCH.Request (SS =1, SP SYNCH.Request (SS =1, = 1, RS = 1) SP = 0, RS = 0)

Standby (5) MLME- (3) MLME-SYNCH.Request - SYNCH.Request (SS =1, SP (SS =1, SP = 1, RS = 0) = 1, RS = 1)

SS: Supporting Synchronization bit, SP: Synchronized with Peer bit, RS: Requesting Synchronization bit

11A.10.1.2.1 Active State

MPs relying upon mesh synchronization to deliver MPDU and MMPDU to peer MPs during a mutually agreed upon time period should operate in Active synchronization state. Synchronization Capability field of such MPs are shown in Table xxx.

MPs operating in Active state shall transition to Transient state if it no longer requires mesh synchronization but one of its peers does (Step 1 in Figure xxx). MPs operating in Active state shall transition to Standby state if neither it nor any of its peers require mesh synchronization (Step 6 in Figure xxx).

Table xxx – Synchronizaiton Capability Field of an MP at different synchronizing states

Synchronizing Supporting Synchronized Requesting States Synchronization with Peer Synchronization

Active 1 1 1

Transient 1 1 0

Standby 1 0 0

11A.10.1.2.2 Transient State

An MP should operate in Transient state if it does not require mesh synchronization but atleast one of its peers requires mesh synchronization. Synchronization Capability field of such MPs are shown in Table xxx.

MP operating in Transient state can transition to Active state if the MP later on requires mesh synchronization to deliver MPDU and MMPDU (Step 4 in Figure xxx). MP operating in Transient state can transition to Standby state if its peers no longer need mesh synchronization (Step 2 in Figure xxx).

11A.10.1.2.3 Standby State

An MP should operate in Standby state if neither it nor any of its peers require mesh synchronization to deliver its MPDU and MMPDU. Synchronization Capability field of such MPs are shown in Table xxx.

MP can transition from Standby state to Active state if it needs mesh synchronization to deliver MPDU and MMPDU (Step 5 in Figure xxx). It can also transition to Transient state if any of its peers requires mesh synchronization to deliver their MPDU and MMPDU (Step 3 in Figure xxx).

11A.10.1.3 Mesh TSF

Synchronizing MPs translate the received time stamps and offsets (if any) from beacons and probe responses from other synchronizing MPs to their own timer base, and update their timer as described as follows:

Translated time stamp = Received time stamp + Received offset (if any) – Receiver’s offset (if any);

Any synchronizing MP shall adopt the translated time stamp as its own if it is later than the timer value of self as described in clause 11.1 for IBSS mode of synchronization.

Synchronizing MPs may choose to update their offsets instead of their timers. The offset update process in this case is as below.

If (received time stamp + received offset) > (self time + self offset)

New self offset value = received time stamp + received offset – self time.

Note that the “Received offset” above is the “self offset” in the received Beacon Timing IE from the neighbor MP, and the “Receiver’s offset” is the receiving MP’s own self offset.

A MAP maintains the mesh TSF in terms of its TSF timer and its self TBTT offset such that the sum of the self TSF timer and the self TBTT offset equals the mesh TSF time. All beacons and probe responses by such MAPs carry the Beacon Timing IE to advertise its self offset value relative to the Mesh TSF time.

Add the following after Clause 10.3.41:

10.3.42 SynchronizationStateTransition

The following primitives describe how a mesh entity changes its synchronization state.

10.3.42.1 MLME-SYNCH.request

10.3.42.1.1 Function

This primitive requests that the mesh entity should transition to a given synchronization state.

10.3.42.1.2 Semantics of the service primitive

The primitive parameters are as follows: MLME-SYNCH.request( Support Synchronization, Synchronized with Peers, Request Synchronization )

Name Type Valid range Description Support Boolean (True, False) Specifies if the MP can support synchronization. Synchronization

Synchronized with Boolean (True, False) Specifies if the MP is currently synchronized with Peers any of its peers. Request Boolean (True, False) Specifies if the MP should request synchronization Synchronization with its peers.

10.3.42.1.2 When generated

This primitive is generated when the mesh entity wishes to change it synchronization state.

10.3.42.1.3 Effect of receipt

This primitive initiates a change of synchronization state. The MLME subsequently issues an MLME- SYNCH.confirm that reflects the results.

10.3.42.2 MLME-SYNCH.confirm

10.3.42.2.1 Function

This primitive reports the results of a change of synchronization state request.

10.3.42.2.2 Semantics of the service primitive

The primitive parameters are as follows: MLME-SYNCH.confirm( ResultCode, )

Name Type Valid range Description ResultCode Enumeration SUCCESS, Indicates the result of the MLME- FAIL SYNCH.request.

10.3.42.2.2 When generated

This primitive is generated as a result of an MLME-SYNCH.request.

10.3.42.2.2 Effect of receipt

The SME is notified of the results of the synchronization state change request.

References:

Submission page 7 Steve Emeott, Motorola Inc.