Chamber Cold And Thermal Shock Test Chamber Chamber Cold And Thermal Shock Test Chamber,Cold Thermal Shock Test Machine,Battery Thermal Shock Test Chamber,Thermal Performance Testing Test Chamber Wuxi Juxingyao Trading Co., Ltd , https://www.juxingyao.com
Several common network access methods based on lorawan protocol
OTAA (Over-The-Air Activation) is a network activation method used in LoRaWAN. When a node powers on and is not connected to a network, it must go through the joining process to communicate with the server. The process starts when the node sends a Join_Request message, requesting access to the network. The server then responds with a Join_Accept message, which contains the necessary communication parameters. Once the node parses this information, it can successfully communicate with the server.
By the way, here are some useful tools for developers:
- HEX/STRING conversion
- JSON validation tool
- BASE64 encoding/decoding
**OTAA Mode Connection Steps**
Before a device can connect using OTAA, it needs to be configured with three essential parameters:
1. **APPEUI**: A custom 8-byte address assigned to the node.
2. **APPKEY**: A shared secret key between the server and the node, used for encryption and decryption of the Join_Accept message.
3. **DevNonce**: A 2-byte random number used to generate the AppSKey and NwkSKey.
These parameters can be hardcoded into the firmware or provided via a serial interface or other configuration methods before the device goes online.
**Step 1: Node Sends Join_Request**
The node initiates the process by sending a Join_Request message. According to the LoRaWAN specification, this message is unencrypted and includes the following components:
- MType: Join Request
- DevEUI: The unique identifier of the device
- JoinNonce: A 3-byte random value generated by the node
This message is transmitted over the air and picked up by the Gateway (GW).
**Step 2: Gateway Uploads Data to Network Server (NS)**
The GW does not decode or parse the MAC layer data. Instead, it performs base64 encoding on the received packet and sends it as a JSON object to the Network Server. The raw MAC layer data is found in `rxpk.data`.
For example, the base64-encoded data might look like:
`000100002000c5262c1610162000774a00547b402de19a`
Decoding this gives the raw MAC payload, which includes the Join_Request message.
**Step 3: NS Forwards to Application Server (AS)**
The Network Server forwards the Join_Request to the Application Server. The AS decodes the base64 content and verifies the request. The data remains unchanged at this stage.
**Step 4: AS Accepts the Join Request**
If the AS approves the request, it sends a response back to the NS, indicating that the device is now part of the network.
**Step 5: NS Assigns MoteAddr**
The Network Server generates a unique device address (MoteAddr) and sends this information to the Application Server.
**Step 6: AS Generates Keys**
The Application Server generates the session keys (AppSKey and NwkSKey) and sends them back to the NS. The NwkSKey is sent in plain text because the NS does not perform decryption but uses it for validating uplink and downlink traffic.
**Step 7: NS Sends Join_Accept to the Node**
The Network Server sends the encrypted Join_Accept message to the Gateway, which then converts it into a MAC packet and transmits it to the node. The `txpk.data` field contains the encrypted Join_Accept message, which is base64 encoded and AES-encrypted.
**Step 8: Node Parses Join_Accept**
The node receives the Join_Accept message and decrypts it using the APPKEY. The decrypted message includes the device address (DevAddr), and the session keys (AppSKey and NwkSKey) are derived using the following formulas:
- **NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16)**
- **AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)**
Once these keys are generated, the node can securely communicate with the server using the LoRaWAN protocol.