# LoRaWAN Behaviour Analysis through Dataset Traffic Investigation
## 5 Discussion  
In this section, we give a brief discussion on the tests we have performed with the proposed methodology. The very first observation is that all the obtained results are coherent with the LoRaWAN specifications: the relationships among the different analyses confirm that the observed performance respect the required behaviour. In the first analysis in Section 4.1 we have analysed the \(RSSI\) and \(SF\) of all the packets exchanged into the network. These parameters are all in the expected ranges, i.e., the \(RSSI\) is greater than \(-120\) dBm and the \(SF\) in the range [7; 12]. As discussed in Section 4.1, the behaviour of the values of the \(RSSI\) and \(SF\) are coherent with the geographical position of the gateways. Although the majority of the packets are forwarded with \(SF\) 7 and \(SF\) 12 for GW8 and GW9, the \(RSSI\) is more variable. In fact, in the adaptive data rate mechanism, before changing the \(SF\) value, the LoRaWAN devices try to adapt the power to attain a given \(RSSI\) and maintain a good transmission quality. In Section 4.2, we exploited the packet field FCount to count the number of lost packets per device. All the tested devices have a packet loss percentage lower than 45% while on average the packet loss percentage is 28.3%. We notice that it is fundamental to have this measure in order to face issues that may arise for some applications for which loosing 28.3% of the packets could be critical. However, this is part of the existing trade-off when we want to use a low power consumption network on one side and a reliable transmission on the other side. Looking at the \(RSSI\) behaviour represented in Figure 6, it is clear that all the gateways try to set the transmission parameters in order to guarantee the best forwarding conditions. What we can also observe is (Section 4.3) the number of devices captured by the gateways, that is strictly related to the position of the gateway and its activity time. In fact, the gateway that managed more devices are the GW5 and GW6 that are also the ones which were up and running for the longest time period, 552 and 573 days, respectively. Looking at GW4 and GW7, they have the same activity time period, 15 and 17 days, respectively, but GW7 has managed 12,969 different devices while GW4 only 31. This because the GW4 is placed in a very bad position with a very constrained line of sight. Another key function in a LoRaWAN is the join procedure, that is the procedure through which LoRaWAN end-devices can join the network. In Section 4.4, we firstly found the ratio between the number of DevAddr and number of distinct physical devices measured by counting the distinct DevEUI. This ratio is 33.68 which means that on average for each physical end-device there are 33.68 different DevAddrs. To confirm that, we also measure the ratio between the number of completed join procedures and number of physical devices obtaining 32 completed join procedures per device. The last interesting aspect we have noticed, by observing the join messages, is that the ratio between the number of join-accept packets and the number of physical devices is of about 0.41. That means that only 41% of the devices in the network join the network for the first time or through OTAA procedure. The remaining 59% was already in the network before starting collecting packets in the dataset or have joined the network through ABP. One of the parameter imposed in the LoRaWAN protocol is the duty-cycle. In Section 4.5, we have measured the duty-cycle per device following the specific procedure performing the three steps detailed in Section 4.5. We have found that all the devices observed in the network respect the constraint of 1% duty-cycle. The last properties we focused on is the de-duplication window time. This is the time that a NS spends waiting for duplicates packets.