dataesr/scientific-paragraphs-categorization huggingface dataset:
The schedule We call schedule a series of frames containing transmissions (slots) from all the nodes in the network. Nodes' transmission(s) are accommodated in one or more slots. TS-LoRa does not perform any scheduling since the nodes are serially placed into slots as soon as they register with the gateway using the minimum (energy-wise) possible SF. In our current problem, we can still follow the same rationale but this is not enough. This strategy could lead to long data collection times since some frames might be overcrowded. For example, if many nodes are placed close to the gateway, all of them would most likely use SF7 resulting to a large number of slots in that specific frame (See Figure  3a ). To tackle that issue, scheduling is performed to find a better arrangement of nodes to slots (other than the serial one) so as to minimise the data collection time without violating duty cycle regulations (whenever they are applied).
Assuming that nodes typically have more than one packet to send, transmissions from each particular node have a minimum periodicity limited by the duty cycle regulations as it is already mentioned. The time slots in between this periodicity can, therefore, be used to schedule transmissions from other nodes. In general, if the airtime (i. e. , transmission time) for a SF is   and the duty cycle is 1%, the minimum period of time between two successive transmissions of the same node is   • 100 and approximately   = 99    +2 transmissions from other nodes with the same SF can be scheduled in the meantime, where  is the guard time at the beginning and at the end of a slot. If more nodes need to be assigned, the frame for SF  is extended. Moreover, a scheduler follows always a simple rule. A node (or transmission) is allocated to the frame that leads to the earliest completion of the data collection.
In this case, the schedule will be optimal only for the given settings but not globally optimal. Since most of the transmissions are accommodated in the SF7 frame, the value of Γ is selected through a trial and error method so that the frame of SF7 is large enough to find the optimal schedule. Nevertheless, the linear program still requires to test a high number of variables per transmission, upper-bounded by  Γ| |, which may limit the practicality of the computational solution to low node numbers only. For deployments with many nodes, time-efficient heuristics such as Light and Global can be used  [33]. The two heuristics differ in the way they handle transmissions and how they divide the schedule into frames. The first algorithm, called Light, schedules only the first transmission for each node and repeats that in subsequent frames.
In the Aloha-based approaches, the nodes use the minimum reliable SF that allows them to reach the gateway, which actually demonstrates the standard Adaptive Data Rate (ADR) mechanism of LoRaWAN. We allow the nodes to periodically send data with the optimal rate   as derived by solving the optimisation problem in Eq. (2-5) for both Pure and Slotted-Aloha cases. This optimization problem is solved using exhausting search as with  [34]. In this way, we guarantee a packet delivery ratio of at least 90% for all nodes in the network. In Pure Aloha, each node transmits at a constant rate which may vary for a few seconds from transmission to transmission in order to avoid repeated collisions. In Slotted-Aloha, each node chooses randomly a slot to transmit; this slots changes at every transmission also to avoid repeated collisions.
In collision-free approaches (i. e. , scheduled ones), the maximum allowed data rate as this is dictated by the duty cycle rules and the scheduler is followed. All scheduling algorithms are implemented in the Perl programming language 1  , taking into account the path-loss and fading of the signal and the capture effect at the gateway. The Aloha-based approaches are implemented on a LoRaWAN simulator 2  whose effectiveness and correctness have been verified by experiments  [34]. The simulator has been adapted to the needs of the bulk data collection and inherits the following capabilities and features from the initial simulator: • Multiple half-duplex gateways • 1% radio duty cycle for uplink transmissions • 1 or 10% radio duty cycle for downlink transmissions • Two receive windows (RX1, RX2) for ACKs and commands • Non-orthogonal SF transmissions • Capture effect • Path-loss signal attenuation model • Multiple channels (however a single channel was used in this paper) • Collision handling for both uplink+downlink transmissions • Node energy consumption calculation (uplink+downlink) Table  2  shows the values used for the simulation parameters.
The linear program was implemented in the Java programming language and solved using the IBM CPLEX solver 12. 8 on an Intel Core i7-5500U CPU, 2. 40 GHz, 32 Gb RAM computer running the Linux Fedora operating system. The sensitivity of the solver's optimality gap has been set to 1 -7 to have enough precision to detect the optimal schedule length. Due to the complexity of the model, we have computed the optimal schedule only for network sizes between 10 to 50 nodes for fixed and variable node buffered data sizes. For the rest of the simulations, we vary the number of nodes from 100 to 1000 and we measure the data collection time, the packet delivery ratio (PDR), and the energy consumption of the nodes. We generate 50 instances per simulation run and the average results are presented along with the 95% confidence intervals.
As it has been shown  [1] , it is more energy efficient to use large packet sizes for all SFs to perform the data collection. This is due to the increased overhead that small packet sizes cause at the MAC layer, thus, delaying the data collection process and increasing energy consumption. On the other hand, in a network with high error rate, very large packet size would cause a high loss of data or high energy cost in case of re-transmissions. Hence, in this work a packet size in the midpoint between the lowest (8B) and the highest (255B) packet size is chosen.
Comparison with Other Approaches 6. 3. 1 Fixed Data Sizes. Simulation results with node numbers from 100 to 1000 are presented in Figure  5. The results do not include the schedule transmission overhead, however, this is almost negligible compared to the total values. The overhead varies from 3 to 7% (worst case) of the total data collection time and energy consumption. As we can observe, the impact of the collision-free transmissions in the data collection time is obvious. The performance in terms of data collection time is at least 10 times higher using an Aloha MAC approach such as LoRaWAN. Slotted-Aloha performs better, however, still far from the collision-free method. In our simulations, all the approaches achieved a packet delivery ratio over 90% while the collision-free ones exceeded 95%.
The Aloha approaches achieved those PDR values only at the expense of much longer data collection times. This shows the superiority of collision-free time-slotted communications as the number of nodes increases. Moreover, the scheduling of transmissions over different slots and SFs leads to much lower data collection time compared to TS-LoRa (non-scheduling approach). The improvement seems to be higher when the number of nodes increases. However, in terms of energy consumption, this action causes an increased trend in energy cost. This happens due to two reasons. Firstly, as the number of nodes increases, more and more nodes are switched to higher SFs. Higher SFs cause longer transmission times and, thus, higher energy consumption. Secondly, the nodes periodically turn on their radio to receive the sync packet from the gateway, increasing the average consumption during a round.
Thus, we limit the purpose of the experiments to assess the following practical issues: (1) to assess the feasibility of using time-slotted scheduling algorithms under real conditions, (2) to assess the downlink transmission time of the schedule, (3) to assess the feasibility of computing the schedule on the nodes instead of computing it centrally on the gateway and then disseminating it to the nodes, and (4) to assess confirmed transmissions. LoRa-enabled devices from Pycom where used for the purpose of the experiments. For experimental efficiency, an amount of data was already generated and loaded onto the nodes' storage module. Each node position was initially evaluated for its connectivity requirements in terms of transmit power and SF. We did this test manually, however LoRaWAN's ADR mechanism can be used to automatically calculate and adjust the SF according to the latest conditions  3.
We run each experiment 10 times and the average results are presented along with the minimum and the maximum values. We measure the schedule transmission time, the data collection time, the active radio time, and the packet delivery ratio for the 10-node testbed. Data transmissions are performed in the allocated time slots using the assigned SFs as computed by the scheduler. The nodes have their radio off during the rest of the period, however, they periodically need to turn on their radio to receive synchronisation packets from the gateway. The synchronisation is achieved using an additional slot at the end of a frame as it was presented in Section 4. 1. The reader can find more information about this mechanism in  [32].
Transmission of the schedule Here, we present experimental results related to the transmission of the schedule. This includes an evaluation of the capability of the gateway to efficiently compute and encode the schedule. No physical presence of the nodes themselves is required. As a consequence, we can experiment with more than 10 nodes. In Light, the schedule consists of a set of tuples indicating the node id, the SF, and the slot number (i. e. , [id, sf, slot]). For example, in our 10-node deployment this results in a 70-Byte schedule. Some extra bytes are added to indicate the gateway id, the guard time, and the sync packet rate. 78 Bytes are sent in total. In terms of transmission time this translates to 35ms with SF7 or 698ms with SF12. Global uses a more sophisticated data encoding to represent the repetition of the frames in the schedule.
]. In our experiments, the total schedule length with Global is 154 Bytes. In terms of transmission time this translates to 6. 3ms and 1. 23s with SF7 and SF12, respectively. Every node that receives the schedule, decodes the data and calculates the frame length for its assigned SF. In Global, this must be done for all the assigned SFs which incurs additional coding effort. The schedule transmission is followed by a very short init packet which actually initiates the data collection process. In the Aloha-based approach, the schedule transmission is omitted, thus, only the init packet is used. Table  4  illustrates the total theoretical schedule transmission time for different node populations using SF7. We examine the scenario where the schedule is sent based on an ideal setup where no duty cycle restrictions are imposed as well as when the duty cycle rules are followed.
Confirmed vs Non-confirmed traffic Finally, in the last experiment, we assess the behaviour of the approaches when re-transmissions can occur. For the needs of these experiments, we also developed approaches that allow re-transmissions of packets in order to capture the effect of acknowledgments in the data collection time and in other measurements. All the nodes transmit 100 unique packets, while maximum 3 retransmissions per packet are allowed before the packet gets dropped. For the time-slotted approaches (i. e. , Slotted-Aloha, Light, Global, and TS-LoRa) the acknowledgments are sent in groups during the SACK packet. The periodicity of the SACK packet is communicated to the nodes at the beginning of the process. In the Pure Aloha approach, acknowledgements are sent similarly to LoRaWAN, using two receive windows.
nodes, all collision-free approaches presented identical results. Thus, the label "CF" refers to all these approaches, while the label "CF-ACK" refers to their confirmed version. Moreover, we must mention that the two heuristic scheduling approaches were able to generate optimal schedules. The results reveal that in terms of data collection time, there is a 10% overhead due to synchronisation compared to the optimal solution. This overhead is apparently higher in case of re-transmissions. The two Aloha approaches present the highest overhead due to higher number of collisions and, thus, more time is required because of the re-transmissions. As it was expected, the PDR is very high for the collision-free approaches and ranges from 98 to 99. 8%. Because no intra-network collisions occur, some packets were lost due to the path-loss effects and the presence of external interference.
CONCLUSIONS & FUTURE DIRECTIONS In this work, we studied the problem of bulk data collections in LoRa-based networks for situations where a gateway is not available to receive data at all times due to the lack of a permanent power source or the lack of coverage (e. g. , in satellite IoT systems). We showed that traditional Aloha-based networks suffer from very long data collection times in order to achieve a satisfactory data delivery ratio. Here, we explored the possibility of using collision-free time-slotted LoRa communications together with SF and slot scheduling to accelerate the data collection. We mathematically formulated and solved the corresponding scheduling problem of finding the best SF and slot allocations that optimise the data collection time. The comparison with heuristics for small data sets showed only a slight performance gap in data collection time compared to the optimum approach.
We implemented our methods using real deployments and we examined critical components of the bulk data collection such as the transmission of the schedule. Despite the duty cycle and power limitations, the results demonstrated the significant advantage of using the proposed synchronous approaches to achieve fast data collection especially with hundreds of nodes. For future work, we intend to investigate the possibility of using medium sensing techniques for data offloading in dense node situations and see their effect on the data collection time. More specifically, we intend to assess the use of the Channel Activity Detection (CAD) mechanism of LoRa transceivers in scenarios where a high packet rate is required, and also develop a feedback and re-transmission mechanism for those scenarios.
ACKNOWLEDGMENTS This publication has emanated from research conducted with the financial support of  Science Foundation Ireland (SFI)  and is co-funded under the  European Regional Development Fund  under Grant Number  13/RC/2077 , the  CONFIRM  fund under Grant Number  16/RC/3918 , and the  European Union 's  Horizon 2020 research and innovation programme  under the  Marie Skłodowska-Curie  grant agreement No. 713567.
Section 3 overviews the architecture and information flow of the ACCA service. Section 4 describes the implementation of the experimental OBU to fulfil the requirements of the ACCA service, including its hardware components, V2X communication protocols, interface with the in-vehicle sensors and actuators network, and software architecture. Section 5 presents the validation of the functionalities and V2X communication interfaces of the OBU, together with performance evaluation results. Section 6 provides insights on the OBU's effectiveness of interoperability in V2X communication. Finally, Section 7 concludes the paper with proposals for future extensions.
e. , applications, facilities, networking, transport and security) are reused from the ETSI C-ITS and DSRC standards. This, in turn, allows one-to-one mapping of the existing applications that were already developed using ETSI C-ITS or DSRC and ensures interoperability with the emerging C-V2X ITS applications. In this work, we have developed an experimental OBU based on OpenC2X. This choice is motivated by the flexibility provided by OpenC2X's modularised architecture, the existing implementation of a Local Dynamic Map (LDM) for data persistence, and the interface to reading a vehicle's speed through an On-Board Diagnostics (OBD) adapter. We have extended OpenC2X incorporating several new key software modules that require fulfiling the requirements of the ACCA service described in the next section.
Software Architecture The software architecture of the experimental OBU shows in Figure  6. As depicted in the figure, the software architecture consists of decoupled modules that communicate with each other using the asynchronous ZeroMQ messaging library. In what follows, we describe the core functionalities of the OBU software modules. Web Interface: This module provides the GUI that operates as the HMI of the OBU, facilitating the interaction between the driver and the OBU. Through the Web Interface controllers, the driver is able to: (i) select the V2X protocol to communicate with the backend service (UDP/HTTP or MQTT); (ii) initiate the registration and authentication process with the backend service; (iii) configure the subscription parameters to an ROI; (iv) initiate a new subscription to an ROI or a sequence of periodic subscriptions; and, (v) emulate the detection of a road hazard by triggering the transmission of a DENM towards the backend service.
In addition, the Web Interface shows the position of the vehicle on a map based on OpenStreetMap, including the locations of road hazards and other vehicles. Furthermore, the Web Interface displays warning messages when the OBU receives DENMs about roadside incidents. HTTP Server: The HTTP server module acts as a middleware between the GUI and the rest of the modules of the OBU. The HTTP server implements a lightweight RESTful web service that translates the GUI-triggered REST commands into ZeroMQ compatible format and then forwards them to the target module. As can be seen in Figure  6 , the HTTP server interacts with: (i) the Registration and Authentication module, (ii) the Subscription module, (iii) the DENM module, to trigger the transmission of a new DENM associated to an emulated road hazard, and (iv) the LDM module, to query the positions of the vehicle, road hazards, and other vehicles.
Local Dynamic Map (LDM): This implements the connectivity to an SQL database, which stores the relevant information extracted from incoming CAM and DENM messages. In addition, the information of CAM and DENM are purged from the database once a pre-defined validity period is expired. The validity period of the information is defined based on the vehicular application requirements. Global Positioning System (GPS): An external GPS receiver is used to acquire the geographical coordinates of the vehicle (i. e. , latitude, longitude, and altitude) and then forwards these information to the CAM, DENM, and JSON/MQTT Client modules.
OBD2-CAN: The OBD2-CAN module implements the connectivity to the in-vehicle sensors and actuators network either through an OBD or a CAN interface, as described in Section 4. 3. Hence, the OBD2-CAN module is configured at run-time based on the availability of either OBD2 or CAN interface. The module retrieves the speed and acceleration of the vehicle and subsequently feeds these data into the CAM and DENM Services. If the module is configured to the CAN bus, then it can retrieve the detected events by on-board smart sensors for collision avoidance. Upon the detection of a road hazard, the OBD2-CAN module notifies the DENM service to trigger the transmission of a DENM. DENM Service: The DENM module is responsible for encoding and decoding DENM messages. The DENMs are event-triggered and can be generated upon the detection of road hazards as well as emulated though the Web Interface.
The module fills the fields of DENM message, including geographical coordinates of the hazard and other in-vehicle sensory information provided by GPS and OBD2-CAN modules, respectively, as defined by the ETSI ITS specification  [27]. The DENM message is passed to the V2X Message Manager to add the GeoNetworking and BTP headers. Upon reception of DENMs from the backend service, the DENM module extracts the GeoNetworking and BTP headers, decodes the fields of the DENM message, and forwards the relevant information of the event (type, position) to the LDM module. CAM Service: The CAM module is responsible for encoding and decoding CAM messages. The CAMs are generated periodically and included vehicle's dynamic parameters, attributes, location information, etc. The position of the vehicle is provided by the GPS module and the speed is provided by the OBD2-CAN module.
The module fills the fields of CAM message at the facilities layer, as defined by the ETSI ITS specification  [26] , and passes it to the V2X Message Manager module where the GeoNetworking and BTP headers are added. The module also receives CAMs from the V2X Message Manager that are transmitted by other vehicles, extracts the relevant data, and forwards these data to the LDM module. V2X Message Manager: The V2X Message Manager module implements UDP-based communication interface between CAM and DENM modules and the backend service. The module inserts ETSI ITS compliant GeoNetworking and BTP headers into ASN. 1 encoded CAM/DENM messages, encapsulates these messages into UDP packets, and then sends them in unicast to a UDP server allocated in the backend. Upon reception of UDP packets from the backend, the module decapsulates CAM and DENM messages, extracts the GeoNetworking and BTP headers, and forwards CAMs and DENMs to the respective CAM and DENM modules.
JSON and MQTT Client: These two modules operate in concert upon selection of the MQTT-based communication mode. This, in turn, provides the seamless interoperability to establish connectivity with backend services, such as centralised traffic management systems or other vehicular services deployed outside of the edge cloud infrastructure, which are accessible through the public Internet. Importantly, these services may not be offered within the ACCA service, but operating as third-party services, e. g. , a regional or a countrywide traffic management systems. The MQTT client implementation leverages the JSON encoding functionality to encode CAM and DENM messages and exchange with the interested parties over the MQTT protocol. We employ a direct translation of ASN. 1 formatted CAM and DENM objects into JSON encoded messages.
MQTT-Based Communications In this test case, both OBUs (1 and 2) use the MQTT protocol to communicate through the Edge MQTT broker. First, the MQTT Client of each OBU is connected to the Edge MQTT broker and both OBUs subscribe to the same topic that is associated with a geographical ROI. Subsequently, OBU 1 triggers the transmission of a DENM message towards the Edge MQTT broker, which subsequently distributes the DENM message to OBU 2. In the opposite direction, OBU 1 is notified by the Edge MQTT broker upon the reception of a DENM transmitted by OBU 2. The warnings are displayed on the web interface of each OBU. Listing 1 shows an extract of a JSON encode DENM message transmitted by one of the OBUs.
Conclusions and Future Work In this work, we have developed and functionally validated an experimental vehicular on-board unit (OBU) based on an open-source software implementation of the ETSI C-ITS protocol stack. Moreover, we have used the OBU to experimentally evaluate the application-level latency for V2X information exchange within an anticipated cooperative collision avoidance (ACCA) service while demonstrating the effectiveness of interoperability in V2X communication between OBUs from different vehicle original equipment manufacturers (OEMs). Our experimental OBU can readily be integrated into any vehicle, and it can use as a driver-assistance system in collision avoidance use cases. The OBU offers the flexibility to inter-work between different V2X protocols to seamlessly communicate with heterogeneous edge-/cloud-hosted services provided by different vehicle OEMs and Mobile Network Operators (MNOs).