September 2004

Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 1

doc.: IEEE 802.15-04-0528-00

Submission

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Submission Title: [Merged Timing and Synchronization]Date Submitted: [15 September, 2004]Source: [Robert Poor (1), Edward Hill (1), Huai-Rong Shao (2), Hui Dai (2), Jinyun Zhang (2)] Company [(1) Ember Corporation, (2) Mitsubishi Electric Research Labs]Address [(1) 343 Congress Street, 5th Floor, Boston, MA 02210 (2) 201 Broadway, Cambridge, MA 02139]Voice:[617 951-0200, 617 621-7517], FAX: [617 951-0999, 617 621 7550], E-Mail:[rpoor@ieee.org, shao@merl.com]

Re: [This document represents a merging of contributions from documents 15-04-0442 and 15-04-0446, in response to Call For Contributions 15-04-0239 and PAR 15-04-0037]

Abstract: [This document describes extensions to the 802.15.4-2003 specification in support of a method for shared time-base distribution]

Purpose: [This document is submitted for consideration for revisions to the 802.15.4-2003 specification.]

Notice: This document has been prepared to assist the IEEE P802.15. 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

September 2004

Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 2

doc.: IEEE 802.15-04-0528-00

Submission

Shared Time Base Distribution in 802.15.4

Robert Poor, Edward Hill (Ember Corporation)

Huai-Rong Shao, Hui Dai, Jinyun Zhang (Mitsubishi Electric Research Labs)

September 2004

Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 3

doc.: IEEE 802.15-04-0528-00

Submission

Motivation

Create a method for sharing a time base among nodes in a 15.4 network, useful for:

– Time stamping of user events– Maintaining slot synchronization– Advanced power management algorithms– Secure key generation – “Freshness” timers for networking algorithms– Loop free routing

September 2004

Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 4

doc.: IEEE 802.15-04-0528-00

Submission

Design Principles

• Make minimal changes to IEEE 802.15.4-2003.• Build upon existing mechanisms whenever possible. • Use Symbol Clock as the fundamental time base.• Provide synchronization primitives for beaconed and non-

beaconed networks.• Provide interface to adjust for hardware timing offset.

September 2004

Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 5

doc.: IEEE 802.15-04-0528-00

Submission

Some Assumptions

• Each node n is equipped with a free-running symbol clock Cn which can be latched when a packet is sent or received, but Cn cannot be set.

• Once the transmission of a packet has started, it is not possible to modify the contents of the packet.

• Over-the-air propagation delays are negligible. (Issues of finite propagation may be addressed at higher layers.)

September 2004

Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 6

doc.: IEEE 802.15-04-0528-00

Submission

Existing Mechanisms

Several useful components already exist in 802.15.4-2003:• Timing: The MAC maintains TimeStamp, a symbol-rate clock

with >= 20 bit resolution for stamping received beacon frames (c.f. 7.5.4.1 [p 151] and table 41 [p 77]).

• Time Stamping: The MLME timestamps each received beacon frame at the same symbol boundary within each frame, the location of which is implementation specific. (c.f. 7.5.4.1)

• Transmission: MCPS-DATA.confirm (msduHandle, status) message is passed from the MAC to the SSCS (c.f. 7.1.1.2.1 [p 59]).

• Reception: An MCPS-DATA.indication (SrcAddrMode, SrcPanID…) message is passed to the SSCS from the MAC when an incoming message is received by the MAC from the PHY.

September 2004

Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 7

doc.: IEEE 802.15-04-0528-00

Submission

Proposed Extensions (Normative)

• Transmission: Add a TimeStamp argument to the MCPS-DATA.confirm() primitive to indicate the time at which any data was transmitted.

• Reception: Add a TimeStamp argument to the MCPS-DATA.indication() primitive to indicate when the associated message was received.

• Add a MAC PIB entry, macSyncSymbolOffset, to indicate the symbol boundary within the frame at which the MLME captures the timestamp of each transmitted or received frame. (A macSyncSymbolOffset of zero corresponds to the onset of the first symbol past the SFD, namely the length field.)

September 2004

Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 8

doc.: IEEE 802.15-04-0528-00

Submission

Example Uses (Informative)

Some definitions:• T: A virtual “universal” real-time clock

• Ti: The value of T at a particular event i.

• Cn: A free-running symbol clock on node n

• Cni: A captured value of Cn at time Ti

• macSyncSymbolOffsetn: the value of macSyncSymbolOffset on node n.

September 2004

Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 9

doc.: IEEE 802.15-04-0528-00

Submission

Synchronizing using beacons

• At T1, node A transmits beacon 1 to node B.• At T1+macSyncSymbolOffsetA, node A latches CA1. The time CA1

is stored in macBeaconTxTime on node A • At T1+macSyncSymbolOffsetB, node B latches CB1. The time CB1

is passed via MLME-BEACON-NOTIFY message on node B• At time T2, node A transmits beacon 2 to node B, containing

[CA1-macSyncSymbolOffsetA] in the beacon payload.

Application code on B can now determine clock offset between node A and node B to be:

([CB1 - macSyncSymbolOffsetB] - [CA1-macSyncSymbolOffsetA]).

September 2004

Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 10

doc.: IEEE 802.15-04-0528-00

Submission

Synchronizing using data packets

• At T1, node A transmits message 1 to node B.• At T1+macSyncSymbolOffsetA, node A latches CA1. Application

code on node A is passed CA1 via MCPS-DATA.confirm() message.

• At T1+macSyncSymbolOffsetB, node B latches CB1. Application code on node B is passed CB1 via MCPS-DATA.indication() message.

• At time T2, node A transmits message 2 to node B, containing [CA1-macSyncSymbolOffsetA] in the payload.

Application code on B can now determine clock offset between node A and node B to be:

([CB1 - macSyncSymbolOffsetB] - [CA1-macSyncSymbolOffsetA]).