Issue link: https://read.uberflip.com/i/1539840
Developing LoRaWAN Devices Technical Recommendation TR007-1.1 ©2021-2025 LoRa Alliance ® Page 8 of 28 The authors reserve the right to change documents without notice. If the network operator does not follow this guideline and uses another network operator's 211 NetID when allocating DevAddrs, there are two consequences. First, it is impossible to 212 efficiently filter traffic at the gateway, creating additional backhaul usage and requiring filtering 213 at the Network Server itself. Second, uplink frames of the misidentified device received by 214 another network operator will not be forwarded to the real home network of the device. Instead, 215 they will be forwarded to the network of the real owner of the NetID, which prevents the device 216 from ever being able to take advantage of roaming network coverage. 217 3.3 Security Keys 218 In the LoRaWAN Link Layer specification, all security keys are 128-bits wide. Root keys are 219 used only by OTAA provisioning to derive session keys, and in the Join-Request and Join- 220 Accept messages. Session keys are used to form Message Integrity Codes (MICs) and to 221 encrypt and decrypt all messages other than the Join-Request and Join-Accept messages. 222 3.4 OTAA Device Provisioning 223 OTAA devices must join a network to gain connectivity. The join process consists of a Join- 224 Request issued by the end-device, followed by a Join-Accept from the network (granting 225 access and providing a DevAddr and session key derivation material), and finally confirmed 226 by the first uplink from the end-device using the new session keys. This section will describe 227 what must be provisioned on the end-device and network to support OTAA operation. 228 3.4.1 Device EUI (DevEUI) 229 The DevEUI is a globally unique EUI-64, legitimately allocated to the end-device by the 230 organization owning the OUI. The DevEUI SHALL be allocated according to the rules defined 231 in Section 3.1. 232 3.4.2 Join Server EUI (JoinEUI) 233 The JoinEUI (also known as AppEUI in earlier versions of the specifications), is the EUI-64 234 address of the Join Server that has been provisioned with the root key material paired with the 235 end-device. The Join Server SHALL support (at minimum), the configuration of 236 DevEUI/JoinEUI pairs with the device's associated root key(s). The Join Server is 237 responsible for validating the end-device's Join-Request, including the cryptographic material 238 (DevNonce, JoinNonce). The JoinEUI is used by the end-device to address the Join- 239 Request message. 240 The JoinEUI SHALL be allocated according to the rules defined in Section 3.1. 241 Provisioning and storage of the JoinEUI in the end-device SHOULD be flexible to allow 242 replacement of a default Join Server with a different JS. The JoinEUI provisioned on the end- 243 device SHALL identify a JS that is provisioned with the root keys of the end-device if the end- 244 device ever roams or if the Network Server and JS are separated. 245