# LoRaWAN Behaviour Analysis through Dataset Traffic Investigation
## 2 LoRaWAN in a Nutshell
### LoRaWAN
In Class A devices, in order to establish bidirectional communication, each uplink transmission is followed by two short receiving windows during which the end-device listens for possible downlink traffic. It is the end-device to trigger the downlink communication. The two receiving windows start at 1 s and 2 s, respectively, after the end of the uplink transmission. Class B devices open other receiving windows at scheduled times, in order to increase the downlink capability. The Gateway transmits beacons to synchronize downlink communication between network server and Class B end-devices. Class C devices are all the time available to receive downlink communication, except when they transmit. Class A devices consume less power, since most of the time they are asleep. Instead, Class C are the ones with highest power consumption, since they are always active. Before starting to exchange information in a LoRaWAN, each end-device has to be personalized and activated. The activation of an end-device can be completed in two ways: via Over-The-Air Activation (OTAA) or via Activation By Personalization (ABP). To join the network through OTAA, an end-device needs to perform a join procedure before starting to exchange information with the network server. A very important point is that an end-device needs to perform a new join procedure each time it looses the session context information. Before starting the join procedure the end-device has to be personalized with the following information:  
* DevEUI: It is a global end-device ID in IEEE EUI64 address space that uniquely identifies the ED. DevEUI is the recommended unique device identifier by Network Servers, whatever activation procedure is used, to identify a device roaming across networks;
* JoinEUI: The JoinEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the Join Server that is able to assist in the processing of the Join procedure and the session keys derivation;
* NwkKey and AppKey: They are AES-128 root keys specific to the end-device that are assigned to the ED during fabrication. The OTAA procedure can be resumed in five steps and graphically represented as in the scheme in Figure 2.  
The join procedure is always initiated by the end-device by sending a join request message (in Figure 3) that is a message that contains the JoinEUI and DevEUI of the end-device followed by a nonce of 2 octets (DevNonce). When the network server receives a join request, it performs the replay attack prevention process based on the validity of the DevNonce that needs to be such that a pair (JoinEUI, DevNonce) is a unique pair. If the join request is a valid one, the server performs the authentication of the end-device and if the ED passes the authentication, the NS generates the keys Nwk_SKey and an App_SKey. Once all the security checks are completed, the end-device is permitted to join the network, so the network server will respond with join-accept message, in Figure 4.  
The JoinNonce is a device specific unique counter value provided by the Join Server and used by the end-device to derive the session keys FNwkSIntKey, SNwkSIntKey, NwkSEncKey, and AppSKey. JoinNonce is incremented with every Join-accept message. When receiving a join-response the end-device verifies that is a valid message by looking at the JoinNonce and if it is a valid one it stores the DevAddr in itself. The DevAddr is a 32-bit ephemeral device address, that will identify the end-device during a session. When an end-device close or lost its session connection, its DevAddr becomes free and it will be reassigned another end-device, and if an end-device re-join the network a new DevAddr is assigned. Each end-device uses its DevAddr to derive the keys it has to use to send messages through the network. Activation by penalization (ABP) directly ties an end-device to a specific network by-passing the join request-join accept procedure. In this case, the end-device already contains all what it needs to derive the keys to starting send messages.