Timing Primitives for 802.14.5b

1
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 Voice1 617
951-0200, FAX [phone], E-Mailrpoor
_at_ ieee . org Re 15-04-0239-00-004b-tg4b-call-p
roposals.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.
2
Timing Primitives for 802.15.4b

• Robert Poor ltrpoor _at_ ieee . orggt
• Edward Hill ltedward.hill _at_ ember . comgt

3
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.

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 timing primitives for the higher layers,
  leaving the actual choice of timing and
  synchronization to the higher layers.

5
Existing Mechanisms

• Several useful components already exist in
  802.15.4-2003
• Timing The MAC maintains TimeStamp, a
  symbol-rate clock with gt 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.

6
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.)

7
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

8
Synchronizing remote node to local node

• At T1, node A transmits message 1 to node B.
• At T1macSyncSymbolOffsetA, node A latches CA1.
  Application code on node A is passed CA1 via
  MCPS-DATA.confirm() message.
• At T1macSyncSymbolOffsetB, 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).

9
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.