Issue link: https://read.uberflip.com/i/1539840
Developing LoRaWAN Devices Technical Recommendation TR007-1.1 ©2021-2025 LoRa Alliance ® Page 23 of 28 The authors reserve the right to change documents without notice. 4.19.2 Recommended Practice 734 End-devices MAY use Class B beacons (regardless of the end-device Class), to detect 735 changes in the set of gateways connecting it to the network. Class B beacons MAY contain 736 gateway-specific fields, including GPS coordinates of the gateway, a NetID, and GatewayID 737 or other proprietary extensions. If this technique is used to detect cell changes, the end-device 738 SHOULD keep a list of recent gateway identifiers. This list SHOULD be sized to track a 739 reasonable number of local gateways. If a new gateway identifier is added to the list, the end- 740 device SHOULD send an uplink frame to allow the network to update its cell location. The end- 741 device SHOULD age entries out of this list if no beacon containing the entry's gateway ID has 742 been received for a long period of time. 743 For end-devices operating in areas where beacons (or beacons with gateway-specific fields 744 identifying the gateway), are not available, cell change detection is not possible. If the end- 745 device includes an accelerometer, GPS/GNSS or other means to detect that it has moved to 746 a new location, the end-device MAY elect to transmit an uplink frame to inform the network of 747 a possible cell change. The end-device SHOULD send such a frame only if it detects that a 748 sufficiently large change in location may have occurred. 749 All end-devices operating in Class B or Class C mode SHOULD send periodic uplink 750 messages to keep the network informed of its cell location. The periodicity of these messages 751 MAY be very low if the above event triggered messages are also implemented. 752 4.20 Maintaining Time Synchronization 753 4.20.1 Description 754 End-devices MAY require that they maintain time synchronization with the network (all Class 755 B-enabled devices SHALL maintain time synchronization with the network). LoRaWAN 756 defines the Class B Beacon as a mechanism by which an end-device MAY maintain such time 757 synchronization. A Class B Beacon, like most beacons in general, is not cryptographically 758 protected (it is protected only from incidental RF corruption via CRC fields). This is because 759 any form of cryptographic protection requires the use of a credential to verify the beacon, and 760 distribution of this credential prior to discovering the beacon, in addition to the increased size 761 of the beacon, can pose a number of challenges. As such, an attacker may send beacons with 762 any values for the Time and GwSpecific fields they chose. In addition, an attacker may shift 763 the beacon delivery time by jamming the original beacons and slowly shifting a replayed 764 beacon to the end-device at a slightly different time than is required by specification. 765 There are several techniques the end-device and the network can use to mitigate the time- 766 based element of these attacks, however these techniques will not mitigate against 767 modification of the beacon GwSpecific field. The techniques employed by the end-device 768 and network are application- and situation-specific. The beacon is best used as a mechanism 769 to deliver hints to end-devices, which would require an end-device to take further action to 770 validate that information. 771