-
Notifications
You must be signed in to change notification settings - Fork 3
Time Synchronization
Authors: Avik Dhupar, Jan Janak
There are a few of mechanisms for time synchronization in LoRaWAN. They differ in the level of cooperation required from the LoRaWAN network or the gateway and offer vastly different accuracy. Some methods only provide second-level accuracy suitable, e.g., to display the current date and time on an LCD screen. Other methods might provide sub-millisecond accuracy well suited for time-coordinated sensing, actuation, or device wakeup.
LoRaWAN Application Layer Clock Synchronization is the simplest and least accurate method. This method requires minimal support from the LoRaWAN network. It must only be supported by the application server (AS). It should only be used as a fallback method by devices that do not support no other (more accurate) methods.
The device requests time correction by sending an AppTimeReq message to the AS. The message includes a timestamp of the device’s clock (device time) taken at the time of transmission. Each gateway and the network server (NS) timestamp the received message (network time). The AS computes a time correction value in the form of a 32-bit signed integer expressed in seconds by subtracting the device time from the network time. The AS then schedules an AppTimeAns downlink for the device with the time correction value. The device applies the correction value to its clock.
The timestamps in AppTimeReq and AppTimeAns have a resolution of one second. Thus, this method provides second-level accuracy and is only suitable for a limited set of applications, e.g., for devices that want to display the time of day on an LCD screen.
This method can be entirely implemented in the application software and requires no special support from the LoRaWAN modem. Use this method only if no other method is available, e.g., if the LoRaWAN network is 1.0.2 or older, does not support class B operation, or if the AS does not support this method.
This method, introduced in LoRaWAN 1.0.3, is an improved version of the application layer method discussed in the previous section. This method is entirely implemented in the NS. It is often used to speed up the acquisition of class B beacons.
The device transmits a DeviceTimeReq uplink (which carries no payload) to the NS. The NS schedules a DeviceTimeAns MAC command to the device which is piggy-backed on the next downlink. The included timestamp represents the network time at the end of the uplink transmission. The timestamp consists of a 32-bit unsigned integer which represents the network time in seconds since the GPS Epoch and an 8-bit unsigned integer fractional value (1/256 second resolution).
The network time must be accurate to +/- 100ms for this method. This accuracy can easily be achieved with NTP. The downlink must be transmitted as a class A downlink, i.e., in either the RX1 or RX2 window. This is necessary for the device to be able to calculate the time difference between the uplink and the downlink.
This method has an accuracy of +/- 100 milliseconds and a resolution of 1/256 of a second. It requires NTP time synchronization on the LoRaWAN gateway for correct operation.
The most accurate time synchronization method available to LoRaWAN devices relies on the timestamps provided by LoRaWAN gateways in class B beacons. Class B beacons have strict timing requirements and must be transmitted with +/- 1 microsecond accuracy.
Since these beacons are transmitted by all LoRaWAN gateways on the same channel simultaneously, the transmission must be very accurately synchronized among the gateways to make sure that the radio signal generated by multiple gateways can be properly demodulated by the device. In practice, this requires time synchronization better than one microsecond on the gateways. This level of accuracy can only be achieved with a dedicated GPS receiver. Furthermore, the GPS receiver must provide a dedicated electrical (GPIO) time pulse signal to the LoRa transceiver. The accuracy of that signal is typically between 10 and 100 nanoseconds, depending on the quality of the GPS receiver and the number of visible satellites.
Class B beacons carry a timestamp expressed in the number of seconds since the GPS Epoch. The resolution of the timestamp is one second. The beacon is typically transmitted by the gateway roughly every two minutes (128 seconds), although the periodicity is configurable. Due to the one second resolution of the timestamp and the fact that it represents the transmission time of the beacon, beacons can only be transmitted at each whole second.
The accuracy that can be obtained on the device via the Class B time synchronization method depends largely on the interrupt service routine (ISR) latency of the MCU connected to the LoRa radio, which in the case of the Type ABZ module is 0.5µS. Upon receiving a class B beacon (or any downlink really), the LoRa radio raises an interrupt flag. The MCU must then record the timestamp of the received packet as quickly as possible. Note that there is additional timing overhead due to the GPIO and SPI communication that needs to take place between the LoRa radio and the MCU before the MCU timestamps the received packet.
This method requires GPS time synchronization at least on some LoRaWAN gateways used by the device. Furthermore, it requires that the device can switch to class B operation. In exchange, this method offers the best possible time synchronization accuracy on the order of 10 to 100 microseconds.
Class C time synchronization is an alternative method proposed for the The Things Network (TTN).
The device switches to class C and sends an empty unconfirmed uplink message to a remote controller application. Upon receiving the uplink, the controller schedules a downlink to be sent to the device exactly 10 seconds after the uplink. The downlink is scheduled via TTN’s MQTT API which lets the application specify an absolute time for a class C downlink. Upon receiving the downlink, the device knows that the message was transmitted precisely at the time represented by the UNIX timestamp in the message.
This method has two advantages: (1) it keeps track of leap seconds; (2) it requires no support from the NS or AS.
(1) Since this method is not based on the GPS time, the timestamp provided to the device can include leap-second corrections. Thus, the device does not need to keep track of how many leap seconds need to be added in order to obtain UTC time or local time. The device only needs to keep track of its time offset from UTC to calculate the local time.
(2) It appears that the server component for this method can be implemented entirely outside of the LoRaWAN network, e.g., in the form of an external application communicating with the AS over MQTT, as can bee seen here. The controller application simply instructs TTN to schedule a downlink to the device at a specific absolute time. The downlink carries a timestamp.
The downlink message carries a 32-bit UNIX timestamp that represents the transmission time of the message. The resolution is one second.
The accuracy of this method depends on the time accuracy on the LoRaWAN gateway that is chosen to transmit the downlink. If equipped with a GPS receiver, the downlink might be scheduled with an accuracy approaching the accuracy of the class B method. If the gateway has time synchronized via NTP only, the accuracy will probably be comparable to the DeviceTimeReq method.
Note: there is no guarantee that the gateway will be able to transmit the downlink at the requested time, especially if the gateway is participating in class B operation. It is possible that the controller requests that the downlink is transmitted during a beacon slot, in which case the gateway might reject the request. Even without class B, there could still be other applications trying to transmit downlinks at the same time. That would result in a scheduling conflict that cannot be predicted by the controller application. The example controller application tries to mitigate this problem by replacing the downlink message queue.