In the previous article, I introduced you to " how to choose the way to access the LoRaWAN terminal ". This article mainly introduces how the OTAA node accesses the network. This article is from the WeChat public account "Xiao Qi said LoRa", the content has been authorized by Xiao Qi teacher, Xiao Qi teacher is Tencent Cloud online course lecturer, click the link https://mp.weixin.qq.com/s/WvGmi81zBMzbAX8OUb-DpA You can watch the course video.
The full name of OTAA is Over The Air Activation . Its network access steps are as follows: the Join Request request sent by the node is forwarded to the server through the gateway, that is, NS; NS will make some judgment processing on the request, and then send the Join Accept response to the node through the gateway.
The main function of the gateway is to forward the data of the node and the data of the server to each other. Servers We can choose some online servers, such as TTN, Tencent Cloud IoT development platform, etc., we can also build open source servers , such as chirpstack, and we can also purchase some gateways that have built-in servers.
Whether it is TTN, Tencent Cloud Internet of Things development platform, chirpstack or built-in server, they are basically free to use. Tencent Cloud Internet of Things platform was upgraded to a partial charge model in January 2021, and the use of less than 1,000 devices is free.
The OTAA node needs to have two data interaction processes with the NS to enter the network . Once the node sends a join request request to the NS, and once the NS sends a join accept response to the node. Before the node sends the join request request, we need to prepare the three parameters DevEUI, AppEUI and AppKey of the OTAA node . After the node receives the join accept, the node needs to successfully parse the join accept before it is successfully connected to the network. Next, each step is explained in detail.
For OTAA nodes, how do we get the three parameters of DevEUI, AppEUI and AppKey ? Some manufacturers will post a QR code on the node, and these three parameters can be obtained by scanning the QR code; some manufacturers can obtain these three parameters through the at command, and the specific at command needs to check the manual provided by the manufacturer; Other manufacturers will only post devEUI on the node , and then send devEUI, appEUI, and appKey to customers in other ways to ensure the security of the three parameters.
DevEUI is the identity of the node, just like the ID of each of us in the enterprise.
AppEUI is the application ID , we can understand AppEUI as the department name in the enterprise. In the several NS servers we mentioned earlier, if you use the TTN server , you need to configure AppEUI ; if you use the Tencent Cloud IoT platform or chirpstack , the parameter node for AppEUI can be set to any value .
The AppKey is used by the node to calculate the session key. The node uses the AppKey to calculate the session key NwkSKey and AppSKey from the join accept for the communication after the node successfully connects to the network. This is a complete network access request process .
The node sends a Join request request, which is transparently transmitted to the NS server through the gateway. The NS judges whether the request is legal. If it is legal, the NS sends a join accept message to the gateway, and the gateway sends the message to the node. After the node receives the join accept, it will parse out devAddr, appSKey and nwkSKey from the join accept, and then the node can use the parsed three parameters to encrypt the data and send it to NS.
We use an example to illustrate the message format of the Join request request. A join request request contains the node's AppEUI parameter, DevEUI parameter, and a random value parameter called DevNonce .
In the LoRaWAN protocol, the first byte is called the Mac Header logo , or MHDR for short, to indicate the message type. 00 always means that this is a join request message. The 8 bytes from the second to the ninth are filled with AppEUI, the tenth to the seventeenth bytes are filled with DevEUI, and the eighteenth to nineteenth byte is a random value DevNonce. The last four bytes are the check value calculated for the data of AppEUI, DevEUI and DevNonce. Pay attention to the DevNonce parameter. Many friends who are doing development have stepped on a pit, and they are all related to this DevNonce. I will share it with you later.
A complete Join accept message format is as follows, the first byte is the MHDR protocol header we just mentioned, and the protocol header of the Join accept message is fixed to hexadecimal 0x20. Then followed by AppNonce, which is a random number generated by NS; NetID is a parameter of NS, which can be simply understood as the ID of NS; DevAddr is a short address generated by NS for the node. After the node Join is successful, DevAddr becomes the node at The unique identifier on the NS, there will be no two identical DevAddr in the same NS; DLSettings configures the receiving rate parameters of the two receiving windows of the node; RxDelay configures how long the node will open after the completion of sending data For a receiving window, this value is 1 second by default; CFList is an optional parameter, which can change the communication channel information of the node after successfully connecting to the network.
The join accept message sent by the NS to the node is an encrypted message , and the node needs to use the appKey to decrypt it before it can get the plaintext JoinAccept message. Then the node uses DevNonce, AppKey and appNonce parsed from Join accept to calculate two session keys nwkSKey and appSKey.
We have already introduced a complete interactive message of the OTAA process. In actual use, it is easy for you to encounter the problem of unsuccessful access to the network when you first contact LoRaWAN. There are many possible reasons for unsuccessful access to the network. The main reasons are summarized as the following three points:
- The three parameters of the node registered on the NS do not match the three parameters of the node configuration . If the devEUI or AppEUI configuration is inconsistent, the server will not send the Join Accept message; if the AppKey configuration is inconsistent, the node will not be able to successfully parse the Join Accept message. This mismatch is mainly due to human factors, and is generally caused by the user filling in the parameters incorrectly , which is relatively easy to troubleshoot.
- The Join Request sent by the node is not received by the gateway, which is generally caused by hardware failure or the environment that causes the wireless signal to be particularly poor . The probability of hardware failure is relatively low. Generally, it is necessary to focus on checking whether the wireless signal is poor. You can consider setting the distance between the node and the gateway a little closer, or try to clear the obstacles between the node and the gateway, and then try again.
- There is also a rare reason that is extremely difficult to troubleshoot. Many developers may write all the parameters in the Join Request in the code at the beginning of the learning stage , and the Devnonce is set to a fixed value in the code. This approach will cause the first Join to succeed and then join again and never succeed. . This is a pit drawn by the Devnonce we mentioned earlier.
NS will have a cache mechanism that will save the Devnonce in each Join request message of the same node. Within a certain period of time, if the Devnonce in the same node's network access request message is the same as the Devnonce in the NS cache, then NS will reject the terminal Of this network access request. NS does this to ensure the data security of the node. As long as the value of Devnonce is changed, the node can successfully join the network again.
In the next article, I will continue to share more LoRa-related knowledge, and I hope everyone will continue to pay attention to us.