# A Study of LoRa: Long Range & Low Power Networks for the Internet of Things
## 5 LoRaWAN Analysis
### Estimation of the Collision Rate  
As of the current specification, the devices and the gateways can transmit at any time. There is no listen-before-talk or CSMAmechanism. This makes LoRaWAN very similar to ALOHA [24], but contrary to ALOHA with a variable packet length. Because of the legal duty-cycle limitations of 1% in the EU region where this analysis took place, 100 devices would have been needed to emulate a load of one, and this number would have grown proportionally to the maximum link load we wanted to test. As there were not this many devices on hand, simulations are used to evaluate LoRaWAN's behavior under load. A simulator was built to simulate the random process of packet emissions. Five-hundred-thousand packets were simulated for each data point. If the transmission time of two packets overlaps, we consider that a collision happens and that none of the two packets reaches the gateway. The collision rate is the number of packets that collided, divided by the total number of packets sent during the simulation. The channel capacity usage is computed as the amount of data that is successfully transferred during the simulation, divided by the theoretical maximum amount of data that could have been sent in the channel, which is the channel capacity multiplied by the simulation duration. The channel load is as defined in the previous Section 5.2, or equivalently, the sum of the duration of all of the packets sent during the simulation, divided by the duration of the simulation. The duration of the packets for the different payload sizes was computed using Semtech's LoRa Calculator, for a spreading factor of seven, a bandwidth of 125 kHz, a code rate of 5/4 and six symbols in the preamble. Assuming the packet arrivals are following a Poisson law and a uniform distribution of the payloads lengths between one and 51 bytes, the expected capacity usage and collision rate depending on the load for one logical channel can be plotted. The result is shown in Figure 10.  
The variable packet length does not greatly impact the performance of LoRaWAN, and all said and done, the observed behavior is very close to that of pure ALOHA. The maximum capacity usage is 18% of the channel capacity and is reached for a link load of 0.48. However, at this load, around 60% of the packets transmitted are dropped because of collisions. This may be an issue, because if the devices are not using confirmed messages, some messages will be lost (and increasing the number of times each message is sent by the devices is a bad solution, as it will increase the load on the link), and if the devices are using confirmed messages, they will have to retransmit most packets several times, which will in addition impact the battery life of the devices. LoRaWAN confirmed messages sent by the devices must be acknowledged by a packet sent during one of the two receive windows following the transmission, while confirmed messages sent by the gateway will be acknowledged during the next uplink transmission. The acknowledgment is only a flag in the packet header, and the setting of this flag acknowledges the last message received. As such, when using confirmed messages, a new packet should not be sent before the acknowledgment of the previous packet was received; otherwise, it will be impossible to know to which packet the next acknowledgment will be referring. The drawback of this mechanism is that a confirmed message requires two successive transmissions in order to be successful, thus increasing the collision probability with other messages and the number of retransmissions needed. As above, the probability of success and the link capacity usage when end-devices are sending confirmed messages can be plotted. For this simulation, we consider that the gateway does not send MAC commands to the device, so the acknowledgment message is always using a 13-byte MAC header and no payload.