Issue link: https://read.uberflip.com/i/1464682
LoRaWAN ® Application Layer Clock Synchronization Specification TS003-2.0.0 ©2022 LoRa Alliance ® Page 9 of 13 The authors reserve the right to change specifications without notice. 271 In case the end-device clock cannot be adjusted in a single AppTimeAns message, e.g., 272 when the time delta correction value (TimeCorrection) cannot be encoded in a signed 273 32-bit integer value, the Application Server SHALL send the maximum/minimum possible 274 value (i.e., 0x7FFFFFFF and 0x8000000) in the TimeCorrection field of the 275 AppTimeAns message. The end-device that receives a TimeCorrection set to a 276 maximum/minimum value assumes its clock needs another correction and it SHALL send 277 another AppTimeReq to apply another adjustment to its clock. 278 Example: On 2050-01-01 00:00:00 UTC, if an end-device boots with 279 DeviceTime=0, the TimeCorrection would be +2208643200 280 (0x83A53880). This value is too large for the TimeCorrection 281 field. The Application Server will send a first TimeCorrection = 282 0x7FFFFFFF and the remaining TimeCorrection = 0x03A53881 283 with the next AppTimeReq message. 284 3.2.1 DeviceTimeReq Equivalence 285 286 For end-devices with LoRaWAN version less than or equal to LoRaWAN 1.0.2, the 287 DeviceTimeReq MAC command is not available. The end-devices can nevertheless mimic 288 the DeviceTimeReq MAC command using this package. An end-device intending to achieve 289 similar functionality as the DeviceTimeReq MAC command SHOULD send the 290 AppTimeReq command in confirmed mode, without retransmissions. 291 292 This DeviceTimeReq equivalence solution does not benefit from the network efficiency of 293 AppTimeReq, as a confirmed message will be acknowledged by the network, but the 294 acknowledgement increases the accuracy of the clock synchronization function on the end- 295 device. 296 3.3 Application Device Time Periodicity Commands 297 (DeviceAppTimePeriodicityReq, DeviceAppTimePeriodicityAns) 298 299 Each end-device's application may come with a different default periodicity for the 300 transmission of the AppTimeReq message. 301 302 The DeviceAppTimePeriodicityReq command is used by the Application Server to modify 303 this periodicity and/or get an instant reading of the end-device's clock value. The message 304 payload is: 305 306 Size (octets) 1 Field Periodicity Table 8: DeviceAppTimePeriodicityReq 307 Where: 308 Bits 7:4 3:0 Periodicity Fields RFU Period Table 9: DeviceAppTimePeriodicityReq Periodicity format 309 Period encodes the periodicity of the AppTimeReq transmissions. The actual periodicity, 310 in seconds, is 128×2 + (30), where (30) is a random integer in the ±30 311 range, varying with each transmission. 312