# LoRaWAN Behaviour Analysis through Dataset Traffic Investigation
## 4 LoRaWAN Analysis
### End-Device Addressing and Activation  
In this section, we investigate the behaviour of the Over-the-Air Activation (OTAA) by looking at the device addresses and the real identifiers of the devices.  
The OTAA activation method foresees an exchange of join request/join accept messages between an ED and the NS. During this procedure, several network parameters could be set by the NS, including the DevAddress, a public ephemeral identifier for the ED, which will be sent as plaintext in every Confirmed/Unconfirmed Data Up packet.  
During its lifetime, an OTAA device, could assume several distinct values of a DevAddr. However, it has one and only DevEUI, which is a unique identifier for a LoRaWAN device. The DevEUI is assigned by the manufacturer in a similar way of a MAC address, containing information about the producer and the unique identifier for the ED.  
The DevEUI is not used in Confirmed/Unconfirmed traffic for several reasons including privacy [16] and, in general, it is not reported in public datasets. However, the DevEUI is sent as plaintext in a join request message. This opens us a possibility to fetch the DevEUI of the devices that performed an OTAA procedure in the LoED dataset.  
As stated earlier, the entries of LoED dataset do not have the DevEUI of the end-device that has sent the packet but we can retrieve the DevEUI from the payload of the join request messages. In order to retrieve the DevEUIs, we filter all the join request messages that we identify by looking at the _mtype_ field, that in the case of join request is equal to 000. Once  
Figure 11: Histogram representing the number of devices managed by each gateway in the network.  
we have identified a join request we consider its payload, and we extract a substring of 8 bytes, from the 8 th to the 15 th, as shown in Figure 12.  
By following this strategy, we counted the number \(N_{DevEUI}\) of distinct DevEUI in the dataset \(N_{DevEUI}=1481\). \(N_{DevEUI}\) represent the number of distinct devices which are present in the dataset and have gone through an OTAA procedure at least once. The number of distinct DevAddr is instead \(N_{DevAddr}\) = 49,876. We can compute the ratio between \(N_{DevAddr}\) and \(N_{Dev}\):  
\[\frac{N_{DevAddr}}{N_{Dev}}\simeq 33.68\]  
This ratio represents, on average, the number of DevAddress assumed by a single ED.  
We also have analysed the number of join request, rejoin request and join accept. We could easily filter them by the _mtype_ field, since these message types have _mtype_, respectively, set to 000, 001, and 110. Without considering the duplicate messages we have the following:  
* Number of join request: \(N_{JoinReq}\) = 170,476;
* Rejoin request: \(N_{RejoinReq}\) = 26,561;
* Join accept: \(N_{JoinAcc}\) = 20,660.  
We then count the average number of join procedures per device. To perform this counting, we have consider a completed join procedure per join accept. By the LoRaWAN standard, the response of a rejoin request is not always a join accept but it could be a normal downlink message with, for example, MAC commands setting network parameters. For that reason, we consider also a completed join procedure per rejoin request. Finally, to compute the average number of completed join procedures per device we apply the following relation:  
\[\frac{N_{JoinAcc}+N_{RejoinReq}}{N_{Dev}}\simeq 32\]  
So we have, on average, 32 completed join procedures per device during the period of packet collection of the dataset. Furthermore, we have analysed the ratio of the join accept messages to the observed number of DevAddr.  
\[\frac{N_{JoinAcc}}{N_{DevAddr}}=0.41\]  
The ratio of 0.41 highlights the fact that in the network we have more DevAddr than the number of completed join procedure. The extra number of Dev Address could be due to ABP devices (which do not require a join procedure) and/or devices which have already performed a join procedure before the start of the packet collection.