# Polling Mechanisms for Industrial IoT Applications in Long-Range Wide-Area Networks
## 3 Materials and Methods
### Polling on Class B
The ABPC algorithm addresses these factors by dynamically adjusting the beacon period based on the observed network conditions. The ABPC algorithm can be used to improve the performance of the LoRaWAN downlink in a variety of scenarios, including the following:  
1. High-traffic scenarios: in high-traffic scenarios, the ABPC algorithm can reduce the downlink latency by adjusting the beacon period downwards. 2. Low-traffic scenarios: in low-traffic scenarios, the ABPC algorithm can improve the energy efficiency of the end devices by adjusting the beacon period upwards. 3. Scenarios with variable traffic density: in scenarios with variable traffic density, the ABPC algorithm can automatically adjust the beacon period to meet the changing demands of the network. A scheduler running this algorithm on the network server allows knowing in advance the performance of a Class B network and can increase or decrease the beacon period to respond to different network sizes while maintaining the application requirements, such as PDR or latency. For a polling system to work, downlink messages must be received by nodes to enable transmissions, so ABPC is used to ensure that the PDR is > 90% by adapting the beacon period. Figure 6 shows the polling system for Class B in unicast mode for a typical beacon period of 128 s. Note that the duration of the ping slot and the beacon period, after ABPC calculates the optimal values for this configuration, can differ from the standard. Figure 5: ABPC selection of parameters for a 256 s beacon period instead of standard 128 s [17]. Figure 6: Solution with unicast polling on Class B. Due to the pseudo-random channel access introduced by Class B ping slot offset selection at the beginning of each period (see Equations (4) and (5)), a PDR of 100% cannot be ensured. \[Rand=aes128 encrypt(Key,beaconTime\mid DevAddr\mid pad16) \tag{4}\]  
\[pingOffset=(\text{Rand}\ [0]+\text{Rand}\ [1]\times 256)\ \text{mod}(pingPeriod) \tag{5}\]  
A critical issue to address when using Class B is the possibility of having a node polled before its duty cycle guard time after the previous transmission is over. This can happen when the ToA and duty cycle time are longer than the beacon guard (\(b_{g}\)) plus the beacon reserved (\(b_{r}\)), which is 5.12 s, and the algorithm selects one of the first slots in the window. So, an additional step in the ABPC scheduler is added to calculate the required beacon guard time to ensure the slot will not be missed due to this problem. Taking the example of Figure 6, if one of the nodes is polled just before the beacon guard, even if it can correctly receive the downlink polling message at the start of a new period (because the gateway uses G3 sub-band enabling it to use 10 times more airtime), the node is unable to respond because it needs to wait until its duty cycle limitation is over. Hence, the scheduler running the ABPC needs to calculate the optimal beacon guard time to prevent this from happening (6), so the correct beacon period may be longer than 128 s. This is a required modification to the ABPC in order to support polling applications. \[b_{g}=DC_{up}-b_{r} \tag{6}\]  
If nodes and GW have multicast support, then downlink messages can be used to trigger the polling simultaneously on a group of nodes (as shown in Figure 7 with an example of 4 nodes in a 128 s period, before the calculation of optimal beacon guard time), which then transmit at the same time but on different channels; the number of these channels can be as large as supported by the GW and defined as \(n_{ch}\) from now on. This results in multicast groups of size \(n_{ch}\). Note that the possibility of using the synchronization beacon at the start of each period, regardless of unicast or multicast, is discarded. Modifying these beacons could break the compatibility for standard Class B nodes and other downlink messages that are non-polling-related.