Document

TS003-2.0.0 Application Layer Clock Synchronization

Issue link: https://read.uberflip.com/i/1464682

Contents of this Issue

Navigation

Page 4 of 12

LoRaWAN ® Application Layer Clock Synchronization Specification TS003-2.0.0 ©2022 LoRa Alliance ® Page 5 of 13 The authors reserve the right to change specifications without notice. 2 Introduction 120 121 This document proposes an application layer messaging package running over LoRaWAN to 122 synchronize the real-time clock of an end-device to the network's Global Positioning System 123 (GPS) clock with near-second accuracy. Synchronizing the clock of end-devices is very 124 useful for many applications, such as: 125 • Get all end-devices of a multicast group to enable Class C temporarily and 126 synchronously at the beginning of the time slot. 127 • Get many sensors to synchronously perform a measurement (e.g., get water meter 128 readings of all meters at midnight every day). 129 Note: The intent of this example application is to indicate that 130 measurements can be synchronized, however it is still important that 131 LoRaWAN transmissions not be synchronized. An end-device 132 intending to perform synchronous measurements should use a random 133 timer, with a value proportional to the number of devices that are 134 performing the synchronous measurements, in order to delay the 135 transmissions that are reporting the measured results and avoid 136 packet collisions. 137 • Enable end-devices to perform scheduled actions (e.g., unlock the front door at 8:00 138 a.m. every morning). 139 This package is useful for end-devices that do not have access to another accurate time 140 source. An end-device using LoRaWAN 1.0.3 or above (refer to the LoRaWAN Link Layer 141 Specification [TS001]) MAY use the DeviceTimeReq MAC command instead of this 142 package. Class B-enabled end-devices have a more efficient way of synchronizing their 143 clock, the Class B network beacon. These devices MAY directly use the beacon time 144 information. In addition, end-devices with an accurate external clock source (e.g., GPS) 145 MAY use that clock source instead. 146 147 All messages described in this document are transported as application layer messages. As 148 such, all unicast messages (uplink or downlink) are encrypted by the LoRaWAN MAC layer 149 using the end-device's AppSKey. 150 151 This package uses a dedicated port to separate its traffic from the rest of the application 152 traffic. Packages are discoverable using the LoRaWAN Multi-Package Access Protocol 153 Specification [TS007]. 154 The major benefit of using this package compared to using the DeviceTimeReq MAC 155 command is that, most of the time, the Application Server is not required to answer the 156 AppTimeReq command from the end-device. A downlink is only required when the end- 157 device clock is outside the accuracy requirement that is targeted by the application. In 158 contrast, every DeviceTimeReq MAC command sent by the end-device requires an answer 159 from the Network Server. 160

Articles in this issue

view archives of Document - TS003-2.0.0 Application Layer Clock Synchronization