# A Survey of LoRaWAN for IoT: From Technology to Application
## 7 LoRaWAN Improvements
### Synchronization and Scheduling for LoRaWAN  
ADR mechanism and different SFs and transmit power distribution will improve network scalability. However, still the main network scalability bottleneck is usage of Aloha based MAC protocol. In addition, the half-duplex operation of gateways as well as duty cycle limitation increased the negative impact on network scalability. To this end, other solutions to coordinate transmissions are being studied. Such solutions rely on low-power time synchronization and low-overhead traffic scheduling mechanisms. In [105], a lightweight scheduling mechanism to specify the allowed SFs and transmit powers at certain channels is introduced. The time is divided into frames and each frame is divided into \(I\) subframes, where \(I\) is the number of channels used. Each subframe starts with a beacon that includes the information such as allowed SFs and RSSI values for each communication channel. In the second part of subframe, end nodes can accesses channels using Aloha in order to transmit their uplink data [105]. The benefit of this approach is that the capture effect is reduced as well as inter-SF collisions are reduced as the end node will select the minimal SF and transmit power that reduce the negative impact to other end devices. The only constraint is that the uplink traffic should not interfere with beaconing traffic. However, the improvements in reliability compared to LoRaWAN are not that high, in the range of 4-5% fewer losses for 3500 end nodes in multi-gateway deployment. Another synchronization scheme for downlink transmissions is presented in [106]. The synchronization is based on beacons that are broadcasted by gateways and include the DevAddr of the end nodes for which the network has downlink packets. After the beacon transmission, the beacon window is divided in the downlink part and uplink part. In the downlink part, the end nodes will poll for the downlink packets sequentially based on the DevAddr order appeared in the beacon. In the uplink part of beacon window, the uplink communication happens like for normal Class A devices [106]. This approach will offer possibilities for downlink traffic as in Class B devices, while the power consumption will be less than in Class B devices as the downlink traffic is polled based. There is no need for end device to open receive windows at each beaconing period, decreasing the power consumption compared to Class B end devices. However, the uplink traffic performance will not be enhanced as end nodes still will use Aloha based channel access. Time synchronization of end devices with back-end is crucial for correct system functioning in case of tele-measurement applications in different domains of industry. In [107], a low power time synchronization mechanism for Class A end devices is presented. The time synchronization of end device happens a posteriori, after the event payload has been sent to the network. The end node will receive an ACK packet from the back-end after the main transmission. As a last step, end node will send a second packet that will inform the back-end with the time when the first packet was sent and when ACK was received according to the unsynchronized end node time. At the back-end side the uncertainty of the time-stamp can be calculated and the actual time of the event can be deducted. This mechanism requires low power as it asks only for another short packet to inform back-end for two timestamps. However, such a mechanism cannot function under heavy load, as if any of the packets (ACK or timestamp packet) are lost the system will malfunction. Moreover, the actual time is not known at end node but can be calculated only at the back-end. This implies that such a method cannot be used for traffic scheduling at proper time. In [108], a low-overhead synchronization and scheduling mechanism is proposed. In such a deployment, the time is divided into time slots, where time slots are maintained by the scheduling entity in the network server.