# Polling Mechanisms for Industrial IoT Applications in Long-Range Wide-Area Networks
## 5 Conclusions and Future Work  
As LPWANs become more widespread and as their bandwidth increases, polling will become a more viable option for collecting data from a large number of devices. Additionally, the development of new techniques for reducing the bandwidth overhead of polling will make it even more efficient. Focusing on the LoRaWAN standard, up to now, applications were mainly focusing on uplink traffic. Trying to export polling as the data acquisition mechanism finds the challenge to optimize the downlink traffic, which is required to send the polling messages to nodes, while guaranteeing that uplink messages will arrive in time. This optimization becomes harder when network size or traffic load may be changing constantly, with periods when new nodes connect, and old nodes run out of batteries, alarm events are detected and trigger more frequent messaging, to provide some examples. Figure 14: Proposal of battery durations for Class B and Class C polling systems. To enable a polling system over LoRaWAN that can adapt to these requirements and ways of operation, configuring nodes with Class B or Class C was proposed and tested, with each option with unicast or multicast scheduling. The results obtained can help understanding the limits of this technology in terms of latency (or polling periods) to collect data and battery lifetime information. This information enables the network server to organize the network to fulfill different application requirements: when latency is not a hard limitation, polling in Class B offers the best energy/latency tradeoff, ensuring a high PDR and many months of operation, while polling in Class C offers unbeatable shorter latencies at the cost of requiring being mains-powered, or lasting only a few days, or less, whilst connected. The multicast option shows better results overall, as expected; however, this study considers also unicast configurations as an option for legacy devices or cheaper gateway options (the more channels available in the interface, the more expensive the device). In conclusion, the decision between LoRaWAN Class B and Class C is contingent upon the specific demands of the application and the imperative considerations of power consumption. Class B stands out as the optimal choice for scenarios where meticulous energy management is paramount and data transmissions occur intermittently. Its ability to schedule receive slots ensures efficient use of power resources, making it particularly well suited for applications like remote monitoring where periodic data reporting is the norm. On the other hand, Class C emerges as the preferred option in contexts where instantaneous responsiveness takes precedence over prolonged battery life. Its continuous polling capability facilitates real-time communication, making it indispensable for applications demanding low latency, such as security systems and dynamic asset tracking in fast-paced environments with consistently high data traffic. An optimal solution to benefit from both classes and polling modes relies on the possibility of changing modes on the fly. The network server can force nodes to operate in one class or another, depending on the conditions, switching between Class B and Class C. Ultimately, the coexistence of LoRaWAN Class B and Class C is a testament to the protocol's versatility, allowing for tailored solutions based on the unique requirements of diverse IIoT polling applications. As the landscape of IIoT continues to evolve, the sensible selection of LoRaWAN classes and polling mechanisms will play a pivotal role in optimizing the balance between energy efficiency and real-time responsiveness in the evolving realm of wireless connectivity. For future work, testing over a network deployed in a representative scenario with industrial requirements and providing situations for polling class switching will help validate the obtained results in a continuous scenario and characterize better the battery behavior in real hardware acquiring real data.