Issue link: https://read.uberflip.com/i/1539840
Developing LoRaWAN Devices Technical Recommendation TR007-1.1 ©2021-2025 LoRa Alliance ® Page 24 of 28 The authors reserve the right to change documents without notice. 4.20.2 Recommended Practice 772 4.20.2.1 Periodic Validation 773 End-devices that leverage the Class B Beacon for time synchronization SHALL periodically 774 solicit the current network time by issuing a DeviceTimeReq and receiving a DeviceTimeAns. 775 If the received time is consistently contradictory to the time received in the beacon, the end- 776 device knows the beacon is unreliable and another source of time synchronization is 777 REQUIRED. 778 4.20.2.2 Downlink ping 779 Class B end-devices are able to use the reception time of valid unicast downlink ping 780 messages to confirm the network time (as these are precisely scheduled). It remains possible 781 for an attacker to shift these messages over time, and as result, recommendation 4.20.2.1is 782 still REQUIRED to confirm the time remains in sync. 783 The unicast downlink ping message SHALL contain either an implicit or explicit value that 784 confirms the current time to the end-device. An example of an implicit value is an application- 785 layer MIC that is salted with the ping-slot time. An example of an explicit value is the contents 786 of the DeviceTimeAns corresponding to the ping-slot time in the body of the message. 787 4.20.2.3 Multicast-group Beaconing 788 End-device may join a multicast group whose downlink ping messages include the current 789 time. These messages are cryptographically protected and therefore securely deliver time to 790 the end-devices in the group. An example of this technique is described in [TR012] Section 791 4.3.2. 792