August 2004 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Timing Primitives for 802.15.4b] Date Submitted: [10 August 2004] Source: [Robert Poor, Edward Hill] Company [Ember Corporation] Address [313 Congress Street, Boston MA 02210] Voice:[+1 617 951-0200], FAX: [+1 617 951-0999], E-Mail:[rpoor @ ieee . org] Re: [15-04-0239-00-004b-tg4b-call-proposals.doc] Abstract: [This document proposes extensions to IEEE 802.15.4-2003 in support of a mechanism for sharing a time base among devices in 802.15.4 devices.] Purpose: [This document is intended to encourage discussion within the IEEE 802.15.4 TG4b task group.] 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. Robert Poor, Edward Hill (Ember Corporation)

Timing Primitives for 802.15.4b August 2004 Timing Primitives for 802.15.4b Robert Poor <rpoor @ ieee . org> Edward Hill <edward.hill @ ember . com> Robert Poor, Edward Hill (Ember Corporation)

Motivation & Philosophy <month year> doc.: IEEE 802.15-<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 802.15.4-2003 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>

Design Principles Make minimal changes to IEEE 802.15.4-2003. August 2004 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 timing primitives for the higher layers, leaving the actual choice of timing and synchronization to the higher layers. Robert Poor, Edward Hill (Ember Corporation)

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

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)

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)

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)

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)