1. doc.: IEEE 802.15-04-0528-00 Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 1 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.

2. doc.: IEEE 802.15-04-0528-00 Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 2 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)

3. doc.: IEEE 802.15-04-0528-00 Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 3 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

4. doc.: IEEE 802.15-04-0528-00 Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 4 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.

5. doc.: IEEE 802.15-04-0528-00 Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 5 Some Assumptions Each node n is equipped with a free-running symbol clock C n which can be latched when a packet is sent or received, but C n 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.)

6. doc.: IEEE 802.15-04-0528-00 Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 6 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.

7. doc.: IEEE 802.15-04-0528-00 Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 7 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.)

8. doc.: IEEE 802.15-04-0528-00 Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 8 Example Uses (Informative) Some definitions: T: A virtual “universal” real-time clock T i : The value of T at a particular event i. C n : A free-running symbol clock on node n C ni : A captured value of C n at time T i macSyncSymbolOffset n : the value of macSyncSymbolOffset on node n.

9. doc.: IEEE 802.15-04-0528-00 Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 9 Synchronizing using beacons At T 1, node A transmits beacon 1 to node B. At T 1 +macSyncSymbolOffset A, node A latches C A1. The time C A1 is stored in macBeaconTxTime on node A At T 1 +macSyncSymbolOffset B, node B latches C B1. The time C B1 is passed via MLME-BEACON-NOTIFY message on node B At time T 2, node A transmits beacon 2 to node B, containing [C A1 -macSyncSymbolOffset A ] in the beacon payload. Application code on B can now determine clock offset between node A and node B to be: ([C B1 - macSyncSymbolOffset B ] - [C A1 -macSyncSymbolOffset A ] ).

10. doc.: IEEE 802.15-04-0528-00 Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 10 Synchronizing using data packets At T 1, node A transmits message 1 to node B. At T 1 +macSyncSymbolOffset A, node A latches C A1. Application code on node A is passed C A1 via MCPS-DATA.confirm() message. At T 1 +macSyncSymbolOffset B, node B latches C B1. Application code on node B is passed C B1 via MCPS-DATA.indication() message. At time T 2, node A transmits message 2 to node B, containing [C A1 -macSyncSymbolOffset A ] in the payload. Application code on B can now determine clock offset between node A and node B to be: ([C B1 - macSyncSymbolOffset B ] - [C A1 -macSyncSymbolOffset A ] ).