# Polling Mechanisms for Industrial IoT Applications in Long-Range Wide-Area Networks
## 3 Materials and Methods
### Polling on Class B  
When using Class B for polling under the standard, operation collisions may happen frequently. As the NS randomly assigns slots, a node can start answering the downlink message when the GW has already started sending another downlink. Moreover, a node may be in the middle of an uplink, which started when the GW's radio was free for reception, when a downlink scheduled slot should open. Figure 3: LoRaWAN Class B operation mode time parameters. In summary, the GW's radio cannot receive and transmit at the same time, so when a downlink and uplink events concur, the one started first takes priority and the other event is missed (see Figure 4). To prevent this and allow nodes to transmit efficiently, they should only transmit right after, and only after, receiving a downlink. This ensures that the GW's radio cannot be in transmission mode as it needs to wait a given time due to duty cycle regulations, and therefore it will be listening. It also ensures that no other node will occupy the channel and cause a possible collision. In order to achieve this particular implementation of a polling system, LoRaWAN Class B requires some configuration changes and optimization. Due to scalability issues in these types of networks, the standard Class B parameters of the beacon period, beacon window, and slot size are not fit for a usable polling system, as this introduces many packet losses and missed slots. In this case, the solution that enables a feasible polling system is achieved using the Adaptive Beacon Period Configurator (ABPC) for scalable LoRaWAN downlink applications. A detailed description of ABPC can be found in [18]. ABPC works by dynamically adjusting the beacon period of LoRaWAN gateways. The beacon period is the interval at which gateways transmit beacon frames. Beacon frames are used by end devices to synchronize their clocks and to learn about the available channels. ABPC can adjust the beacon period based on the following factors: the number of end devices in the network, the traffic load on the network, the channel conditions, battery constraints, or latency requirements. ABPC increases the beacon period when the network is congested or when the channel conditions are poor. This reduces the overhead of beacon frames and improves the performance of downlink traffic. ABPC decreases the beacon period when the network is not congested and when the channel conditions are good. This reduces the latency of downlink traffic. The results showed that ABPC significantly improves the scalability and performance of LoRaWANs with a large number of end devices. In summary, the ABPC algorithm operates as follows:  
1. Observe network conditions: The ABPC algorithm periodically observes the network conditions, such as the traffic density and the average message payload size. This information can be obtained from the network server. 2. Calculate the Class B beacon period: Based on the observed network conditions, the ABPC algorithm calculates the optimal beacon period and its derived ping slot length and _pingNb_ and \(k\) (see Figure 5). The optimal beacon period is the value that balances the energy consumption of the end devices with the downlink latency and Packet Delivery Ratio (PDR). 3. Adjust beacon period: The ABPC algorithm adjusts the beacon period in the gateway. The updated beacon period and ping slot length are then broadcasted to the end devices. Figure 4: Failed TX/RX events due to shared radio unavailability. The ABPC algorithm is based on the observation that the performance of the LoRaWAN downlink is affected by several factors, including the following:  
1. Traffic density: the higher the traffic density, either by number of devices or packets per device, the longer beacon period needed to support this traffic, which can increase the downlink latency. 2. Message payload size: a larger message payload means that the gateways need to transmit more data, which can increase the downlink latency and the probability of collision events (see Figure 4).