Network Server
Nitro ION Miner
The Nitro ION Miner forwards all received LoRaWAN radio packets to the Network Server that is connected through an IP back-bone. The Nitro ION Miner operates entirely at the physical layer. Its role is simply to decode uplink radio packets from the air and forward them unprocessed to the Network Server. Conversely, for downlinks, the Nitro ION Miner simply executes transmission requests coming from the Network Server without any interpretation of the payload.
LoRaWAN Network Server
The Network Server (NS) terminates the LoRaWAN MAC layer for the end-devices connected to the network. It is the center of the star topology. Each NS is identified by a unique NSID (an IEEE EUI64 identifier), and can be configured with one or more NetIDs.
Generic features of NS are:
• End-Device address check
• Frame authentication and frame counter checks
• Acknowledgements
• Data rate adaptation
• Responding to all MAC layer requests coming from the end-device
• Forwarding uplink application payloads to the appropriate Application Servers
• Queuing of downlink payloads coming from any Application Server to any End-connected to the network
• Forwarding Join-request and Join-accept messages between the end-devices and the Join Servers
In a roaming architecture, an NS may play three different roles depending on whether the end-device is in roaming situation or not, and the type of roaming that Serving NS (sNS) controls the MAC layer of the end-device.
Home NS (hNS) is where Device Profile, Service Profile, Routing Profile and DevEUI of the end-device are stored. hNS has a direct relation with the Join Server that will be used for the Join Procedure. It is connected to the Application Server (AS). When hNS and sNS are separated, they are in a roaming agreement. Uplink and downlink packets are forwarded between the sNS and the hNS.
Forwarding NS (fNS) is the NS managing the Radio Nitro ION Miners. When sNS and fNS are separated, they are in a roaming agreement. There may be one or more fNS serving the end-device. Uplink and downlink packets are forwarded between the fNS and the sNS.
Join the Network Server
The Join Server (JS) manages the Over-the-Air (OTA) end-device activation process. There may be several JSs connected to a NS, and a JS may connect to several NSs.
The end-device signals which JS should be interrogated through the JoinEUI field of the Join-request message. Each JS is identified by a unique JoinEUI value. Note that the App EUI field of the Join-request in LoRaWAN 1.0/1.0.2 [LW10, LW102] is renamed to JoinEUI field in LoRaWAN 1.1[LW11]. The term JoinEUI is used to refer to the AppEUI in the context of LoRaWAN 1.0/1.0.2 end-devices in this specification.
The JS knows the end-device’s Home Network Server identifier and provides that information to the other Network Servers when required by the roaming procedures.
The JS contains the required information to process uplink Join-request frames and generate the downlink Join-accept frames. It also performs the network and application session key derivations. It communicates the Network Session Key of the end-device to the NS, and the Application Session Key to the corresponding Application Server.
For that purpose the JS shall contain the following information for each end-device under its control :
• DevEUI
• AppKey
• NwkKey (only applicable to LoRaWAN 1.1 end-device)
• Home Network Server identifier
• Application Server identifier
• A way to select the preferred network in case several networks can serve the end-device
• LoRaWAN version of the end-device (LoRaWAN 1.0, 1.0.2, or 1.1)
The root keys NwkKey and AppKey are only available in the JS and the end-device, and they are never sent to the NS nor the AS.
Secure provisioning, storage, and usage of root keys NwkKey and AppKey on the end-device and the backend are intrinsic to the overall security of the solution. These are left to implementation and out of scope of this document. However, elements of this solution may include SE (Secure Elements) and HSM (Hardware Security Modules).
The way that information is actually programmed into the JS is outside the scope of this document and may vary from one JS to another. This may be through a web portal for example or via a set of APIs.
The JS and the NS shall be able to establish secure communication which provides end-point authentication, integrity & replay protection, and confidentiality. The JS shall also be able to securely deliver Application Session Key to the Application Server.
The JS may be connected to several Application Servers (AS), and an AS may be connected to several JSs.
The JS and the AS shall be able to establish secure communication which provides end-point authentication, integrity, replay protection, and confidentiality.
Application Server
The Application Server (AS) handles all the application layer payloads of the associated end-devices and provides the application-level service to the end-user. It also generates all the application layer downlink payloads towards the connected end-devices.
There may be multiple ASs connected to a NS, and an AS may be connected to several NSs (operating end-devices through several networks, for example). An AS may also be connected to multiple JSs.
The Home NS routes the uplinks toward the appropriate AS based on the DevEUI.
In addition to the aforementioned network elements, LoRaWAN architecture defines the following network interfaces among these entities:
hNS-JS: This interface is used for supporting the Join (Activation) Procedure between the JS and the NS.
vNS-JS: This interface is used for Roaming Activation Procedure. It is used to retrieve the NSID and NetID of the hNS associated with the end-device.
ED-NS: This interface is used for supporting LoRaWAN MAC-layer signaling and payload delivery between the end-device and the NS.
AS-hNS: This interface is used for supporting delivery of application payload and also the associated meta-data between the AS and the NS.
hNS-sNS: This interface is used for supporting roaming signaling and payload delivery between the hNS and the sNS.
sNS-fNS: This interface is used for supporting roaming signaling and payload delivery between the sNS and the fNS.
AS-JS: This interface is used for delivering Application Session Key from the JS to the AS.
Last updated