# Worldwide Connectivity for the Internet of Things Through LoRaWAN
## 4 How an End Device Joins a LoRaWAN(tm) Network
### Flow Chart of the Join Procedure in Case of Roaming  
In contrast to the above example, we are now providing an example of the procedure an end device has to undergo in order to join a visiting network (or, equivalently, serving network), i.e., a network to which an end device is attached when it is out of coverage of its home network, thus in roaming. As a preliminary assumption, we consider that the regulation of the place where the device is roaming and the radio frequency parameters are the same as those in the country of origin. For example, let us consider the case of a device from a given European country, roaming into another European country. If the parameters [11] were not the same, there would be no way for the end device to retrieve the new radio frequency parameters. In fact, it is up to the manufacturer to build and certify end devices which are compliant with the regulations of the regions where they have been approved to operate. Moreover, the user of such a device needs to instruct it about the region wherein it is operating via some hardware switches or other means. The flow chart of such a procedure is provided in Figure 4, and it consists of the following steps. 1. The end device sends via LoRa radio link(s), i.e., through GW(s), a join-request message over the air and, not being under the coverage of the home network, the message will reach a visiting NS. 2. According to the specification [8], the message contains the JoinEUI and from that parameter and the DNS infrastructure provided by the LoRa alliance (see [10]) the visiting NS can determine the IP address of the join server for that particular end device. 3. The visiting NS asks the join server the address of the home NS for the specific end device. 4. The join server provides the address of the home NS for the specific end device to the visiting NS. 5. The visiting NS asks all the information available to the home NS about the specific end device to be forwarded to it. 6. The visiting NS gets all the information available to the home NS about the specific end device. 7. The visiting NS asks the home NS of the specific end device to take control of the end device itself and possibly to host the end device in its network. 8. The home NS passes the request as a JoinReq to the join server previously identified, including the DevEUI and other relevant parameters. 9. The join server, having all the necessary keys, derives the session keys for the control data and provide the home NS with them as a JoinAns. Figure 3: Flow chart of operations for joining the home network. JS and AS denote the join server and the application server, respectively. (10) The home NS forward the session keys to the visiting NS. * The visiting NS replies to the end device with a join-accept (via the radio interface, i.e., via the GWs) and set all of the radio parameters. * A user data packet is sent (via the radio interface, i.e., via the GWs) to the visiting NS. * The visiting NS, being the received packet made of user data, forwards it to the application server. * The application server gets the session keys for user data from the join server and decrypts the message making it available to the application layer. One can see from Figure 4 that the procedure for an end device to join a visiting network is not much more complicated than the one for the home network, as just a few more signaling messages are involved. A further remark is that, apart from the restriction to use the same radio frequency regulations, the visiting network can be anywhere in the world: no notion of distance is involved with respect to the home network. A final remark is related to the join server. As per the back-end specification [10], the LoRa Alliance is providing an IP based infrastructure allowing the different owners of the end devices to use different join servers, provided by third parties (as the security issues related to such a network element are quite stringent) which are usually well accustomed to provide certificates and similar trusted elements.