1. August 2004
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Timing Primitives for b]
Date Submitted: [10 August 2004]
Source: [Robert Poor, Edward Hill] Company [Ember Corporation]
Address [313 Congress Street, Boston MA 02210]
Voice:[ ], FAX: [ ], ieee . org]
Re: [ b-tg4b-call-proposals.doc]
Abstract: [This document proposes extensions to IEEE in support of a mechanism for sharing a time base among devices in devices.]
Purpose: [This document is intended to encourage discussion within the IEEE TG4b task group.]
Notice: This document has been prepared to assist the IEEE P 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 P
Robert Poor, Edward Hill (Ember Corporation)

2. Timing Primitives for 802.15.4b
August 2004
Timing Primitives for b
Robert Poor ieee . org>
Edward Hill ember . com>
Robert Poor, Edward Hill (Ember Corporation)

3. Motivation & Philosophy
<month year>
doc.: IEEE <doc#>
August 2004
Motivation & Philosophy
Motivation: A method for sharing a time base among nodes in a 15.4 network is useful for: time stamping of events; decentralized synchronization among nodes for advanced power management; secure key distribution; routing algorithms and others.
Design principles:
Make as few changes to IEEE as possible.
Build upon existing mechanisms whenever possible.
Use Symbol Clock as the fundamental time base.
Provide timing primitives for the higher layers, which will in turn implement timing and synchronization algorithms.
Robert Poor, Edward Hill (Ember Corporation)
<author>, <company>

4. Design Principles Make minimal changes to IEEE 802.15.4-2003.
August 2004
Design Principles
Make minimal changes to IEEE
Build upon existing mechanisms whenever possible.
Use Symbol Clock as the fundamental time base.
Provide synchronization primitives for beaconed and non-beaconed networks.
Provide timing primitives for the higher layers, leaving the actual choice of timing and synchronization to the higher layers.
Robert Poor, Edward Hill (Ember Corporation)

5. August 2004
Existing Mechanisms
Several useful components already exist in :
Timing: The MAC maintains TimeStamp, a symbol-rate clock with >= 20 bit resolution for stamping received beacon frames (c.f [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 )
Transmission: MCPS-DATA.confirm (msduHandle, status) message is passed from the MAC to the SSCS (c.f [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.
Robert Poor, Edward Hill (Ember Corporation)

6. August 2004
Extending the Spec
Transmission: Add a TimeStamp argument to the MCSP-DATA.confirm() primitive to indicate the time at which the message was transmitted.
Reception: Add a TimeStamp argument to the MCSP-DATA.indication() primitive to indicate when the 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.)
Robert Poor, Edward Hill (Ember Corporation)

7. Example Uses (Informative)
August 2004
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
Robert Poor, Edward Hill (Ember Corporation)

8. Synchronizing remote node to local node
August 2004
Synchronizing remote node to local node
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]).
Robert Poor, Edward Hill (Ember Corporation)

9. August 2004
Notes
A bit clock of 250KBPS is a symbol clock of 62.5KCPS (16 uSec), a 20 bit TimeStamp counter rolls over once every 16.7 seconds.
A 24 bit TimeStamp counter rolls over once every 4.47 minutes.
It is possible to use the existing beacon mechanism to create a distributed time base in a beaconed network (Beacon Node captures macBeaconTxTime and Beacon Sequence Numbers, other node replies with TimeStamp and BSN), but it is desirable to provide this functionality in a non-beaconed network.
The authors gratefully acknowledge useful input and discussion from Huai-Rong Shao of Mitsubishi Electric Research Labs and Robert Cragie od Jennic Corporation.
Robert Poor, Edward Hill (Ember Corporation)