Global Time Distribution in 6TiSCH Networks

Time Synchronized Channel Hopping (TSCH) exploits node synchronization to build up deterministic access networks through scheduling . 6TiSCH defines a control plane architecture to enable IEEE802.15.4 TSCH networks to securely bootstrap and in a distributed manner self-organize in order to meet application traffic needs . The synchronization accuracy between the nodes' clocks in a 6TiSCH network is dependent on the network maintenance traffic (Keep Alives), application traffic, and MAC layer guard time duration. It is well-known that, for a given traffic, the smaller the guard time, the smaller the tolerated drift between two nodes, and hence, the more precise their synchronization. The concept of network synchronization is achieved through a virtual counter referred as Absolute Sequence Number (ASN). In a 6TiSCH network, each node updates its ASN at every slot, giving the nodes the same notion of time (with timeslot granularity). This time is relative to the moment the network started or reset and hence cannot be used to compare tagged events from different networks. This document defines a data structure to map ASN and absolute time. The document then defines the procedure to transport the structure to the 6TiSCH nodes: As an optional extension to the Constrained Join Protocol (CoJP) Join Response procedure within the Minimal Security Framework for 6TiSCH . As a CoAP Response to a global time service exposed by the Join Registrar/Cordinator (JRC).

In order to distribute global time information in a 6TiSCH network at least one component must be acting as a global time source and enabling nodes in the network to obtain the absolute time reference from it. The way global time is obtained and maintained in this network component is out of scope of this specification. As an example, this component can account for the global time in the network internally, can use an external source to obtain global time (e.g. GPS, NTP ) or, can be synchronized through a precision time protocol (PTP) such the IEEE-1588 to another network. We use the example network in throughout this specification for illustration. The Join Registrar/Coordinator (JRC) acts as the global time information source for a node when it joins. How the JRC obtains such global time information is out of scope of this specification. The JRC can be a component outside of the 6TiSCH network. However it is required to be synchronize to it through the ASN. How the JRC obtains such synchronization to the 6TiSCH network is out of the scope of this specification. This specification defines how the JRC formats and distributes the absolute time reference to the 6TiSCH nodes in the network.

A Pledge node obtains its global time reference during the Secure Join Process with the JRC . This specification extends the Join Response message with an optional data structure which includes the global time reference and optionally the period for absolute time updates. The global time reference is a mapping between the ASN of the network and the global time at the moment of processing the Join Response. After having obtained the global time reference, a 6TiSCH node maintains internally its timing until it updates it, resets or is disconnected from the network. Optionally, periodic refresh messages can be issued by the 6TiSCH node to the JRC using the JRC URI exposing the time service. These optional refresh messages MAY be used to cope with the clock drift caused by any possible imprecision between the configured timeslot length and the actual timeslot length. As an example, a timeslot can be configured to be 10ms long but because of the nature of the crystal in the device the timeslot becomes 10.1ms.

This document extends the Join Response message within the Constrained Join Protocol (CoJP) defined in with: A byte string containing the ASN at which the CoAP Response (e.g, Join Response) is processed at the JRC. The 5-byte ASN is carried in network byte order. An 8-bit unsigned integer containing an era counter. The era counter is used to account for wraps of the seconds counter. It starts at 0 and increments approximately every 136 years as per definition of era in NTP . Era 0 starts at 0h UTC 1st of January 1900. A 32-bit unsigned integer containing a timestamp in seconds, captured at the beginning of the timeslot at which the CoAP Response (e.g. Join Response) is processed. Carried in network byte order. The seconds and fraction fields are based on the specification described in the NTP standard for the Timestamp format. The seconds field accounts for seconds elapsed since the 0h on the 1 January 1900 UTC, as described by the NTP standard . A 32-bit unsigned integer containing the number of picoseconds elapsed after the last entire second at the beginning of the timeslot at which the CoAP Response (e.g. Join Response) is processed. Carried in network byte order. Its granularity is described in the NTP standard . Optionally, a byte string encoding a global time service URI in core-link format. The default value is 'gt'. Optionally, an unsigned word lease value indicating the number of minutes of freshness of the assigned global time information. If this value is not provided the lease time is considered to be infinite. If this value is 0, a node does not refresh the global time information.

To take into account possible leap seconds. An optional leap_second_option is defined by: An 8-bit unsigned integer containing the action to be performed when the next leap second day is reached. A 16-bit unsigned integer containing an offset in days to the beginning of the day (0 h UTC) when the next leap second must be applied. Carried in network byte order.

The optional leap_second_option defines a leap second indicator, which identifies the type of correction that needs to be applied once the next leap second day is reached. The types are described in Figure 9 of the RFC5905 . A leap_offset contains the offset in days to when the next leap second needs to be applied, following the action described in the leap second indicator. The global_time_option and the leap_second_option, if present, SHOULD be appended following the Join Response Payload and MUST be encoded as a CBOR map objects .

When a pledge receives the Join Response containing the global_time_option, it updates its internal absolute time clock/counter. If present, it also stores the gt_service link-format URI and the lease time. After correcting a leap second or when the lease period is reached, a node MAY want to update the global time information values to keep track of the next leap second correction event or to renew its global time synchronization lease. This resynchronization is conducted through a CoAP GET Request to the JRC address and gt_service URI. The request method is GET. The type is Non-confirmable (NON). The Proxy-Scheme option is set to "coap". The Uri-Host option is defined by the JRC URI. The Uri-Path option is set to gt_service. The payload is empty. The response is a CoAP Response Message with Response Code 2.05 (Content) containing the global_time_option as payload. The response MAY contain a leap_second_option in case a leap second update is needed. Both options if present are encoded as CBOR dictionaries.

When a 6TiSCH node receives a global time synchronization message and this response contains a leap_second_option, the node MUST store the values until the leap second offset is reached. When a leap second offset is reached, the leap second is corrected adding or substracting a second to the last minute of the day as indicated by the leap_indicator field.

The global time synchronization option is transported as part of the payload of the 6P Join Response message and secured by OSCORE (Object Security for Constrained RESTful Environments) as per . Since the JRC acts as the global time synchronization server, comprimising the JRC will result in a compromise of the transported information. A malicious 6N attacker may use a short lease time to generate high volumes of traffic in the network or even to try to denial the service to the JRC. Is up to the JRC to implement temporal blacklisting policies to avoid any DoS attack.