# Worldwide Connectivity for the Internet of Things Through LoRaWAN
## 5 The Rationale of LoRaWAN(tm) Architecture for a Global Roaming of Things  
Having introduced the join procedure for an end device, we can now describe what a customer should do before the node is switched on a certain network. In other words, so far we assumed the different servers (in particular, the join server) know all the relevant security keys. The question we ask ourselves in this section is:  
\"How do the servers get to know the keys?\"  
By answering this question, the crucial enabling characteristics of the LoRaWAN(tm) architecture for a global roaming will become apparent:  
1. having a trusted third-party repository (i.e., the join server) for the original keys of an end device which can be reached by any LoRaWAN(tm) network;
2. having the home NS that knows the details of the subscription for an end device;
3. having an application server to which the data generated by the end device are delivered, and to which the user data intended to be delivered to the end device must be provided.  
Let us consider a customer that wants its end device to work on a certain LoRaWAN(tm) network with roaming capabilities (which, of course, depend on the deals his network operator has with other network operators, like in cellular phones). They must first provide the join server with the following information:  
* the DevEUI;
* the AppKey;
* the NwkKey;
* the home NS identifier;
* the application server identifier.  
The transfer of this information is usually done via some out-of-band procedure, i.e., not using the LoRaWAN(tm) network. Usually companies running the join server(s) provide, for example, a secure web portal where customers can upload the information for a single end device or for a batch of devices using a file with an agreed upon file format.  
Now, the whole rationale of LoRaWAN(tm) architecture is clear, and can be described in the following points.  
1. The join server is the owner of the secret keys of each end device. It is not part of any LoRaWAN(tm) network operator, and since it is a crucial part of the architecture it is supposed to be run by a trusted third party (different from the operator). The join server releases the session keys to the application server and the home NS (and then to the visiting NS in case of roaming, see Figure 4), so that the original secret keys never get compromised. That is the motivation of recommending to renew the session keys, just in case an attacker could get hold of the session keys.
2. The network server of the home network or a visiting (serving) network can get its session keys once again from the join server. We want to remark that the DevEUI is sent in clear text to the home NS (via the GWs) or the visiting NS (in case of roaming), which then can interrogate the join server and ask for the specific session keys.
3. The home or visiting NS is finally able to direct and receive the user information to the right application server, since the home or visiting NS can get to know the identifier of the application server, as said above. Furthermore, the application server can get the session key to decrypt/encrypt the traffic from/to end device from the join server. The major point of the presented architecture is to  
1. not give the secret keys to the network operators and applications servers, but deliver them to a trusted third party, enabling the roaming between different network operators;2. decoupling the security of the control information (e.g., MAC commands, for which the end point is the NS) and the user information (for which the end point is the application server).