LoRa city-scale Testbed

Testbed Topology

The LoRa testbed consists of one LoRa Gateway (GW ) that is deployed on the rooftop of our University’s premises and ten Sensing nodes that are scattered across the city of Volos, Greece. The end nodes feature various air quality probes, characterizing gas concentrations, dust particle con- centration, along with outdoor air temperature and humidity modules. We clearly observe that the testbed offers a wide range of wireless links that differentiate in terms of communication distance, elevation difference and LOS/NLOS conditions. For each node, we also note the amount of payload bytes transmitted when transferring the respective number of sensed parameters, which includes 5 Bytes per environ- mental parameter plus 9 Bytes of own protocol overhead, while it does not include the LoRa preamble, header and CRC, as specified in [5]. Below we present the custom developed GW and sensing devices, as well as the software toolkit for obtaining LoRa performance measurements.

LoRa Gateway: The GW is based on the BeagleBone Black Rev. C board [18] which is a low-cost, embedded plat- form characterized by su cient processing power capabili- ties (ARM Cortex-A8 Processor at 1 GHz with 512 MB RAM) and several I/O pins, while it also embeds an Ethernet port for communicating with the backbone network. On top of BeagleBone we attach a custom-designed PCB board (cape) that integrates our electronic components and features a slot for connecting a LoRa transceiver. More speci cally, the cape features the MK20DX128VLH5 micro-processor which is interfaced with the LoRa transceiver responsible to run all the requisite libraries for its operation. The micro- processor software is also responsible of implementing a polling mechanism to aquire measurements from the sensor nodes and also initiate the link quality experiments. For the LoRa transceiver we employ the SX1272 [19] chipset manufactured by Semtech, which is paired with a 4.5 dBi antenna.

LoRa Sensing Devices: The core module of our sensing devices is again the MK20DX128VLH5 [20]. The 32-bit ARM Cortex-M4 CPU, clocks up to 96 MHz and supports ultra-low power sleeping modes to allow for power e cient opera- tions. The node employs the same LoRa interface (SX1272) as the gateway device, attached to a 4.5 dBi omni-directional antenna. Each node is equipped with a varying set of sensors, as illustrated in Table 1, featuring 1, 3 or 7 sensors in total. The sensors utilized are gas concentrations probes (NO2, SO2, CO, NH3, O3), dust particle concentration PM2.5, PM10 and a temperature & humidity module. The micro-processor hosts a program that implements the sensor reading and collec- tion of measurements, and also the communication between itself and the SX1272 module. Fig.1(b) presents one sensor device attached with four gas concentration probes and a dust particle module.

Software Toolkit: Through the deployed list of devices, we continuously collect detailed air quality measurements, while also evaluate the performance of the employed LoRa communication links. The overall procedure is orchestrated at the GW level, which periodically polls the di erent sens- ing nodes that continuously remain in receive mode. Sensor polling is executed in a Round-robin fashion, instructing sensors to transmit collected air quality measurements (with an interval of 10 minutes) or to participate in a link quality evaluation experiment (executed twice per day). The two procedures are executed independently of each other, taking advantage of the employed polling approach, which enables us to avoid the impact of overlapping transmission inter- ference, when performing link quality experiments. Upon receiving a request for experiment, each sensing node trans- mits 10 consecutive packets at the data rate, payload length and transmission power that has been determined by the GW. The gateway sends the experiment settings embedded to the experiment request packet. The per-node link quality of the network is determined through the Packet Delivery Ratio (PDR) of the aforementioned experiments.

Sensor Device

Gateway Device

LoRa Agricultural Testbed

Testbed Topology

The LoRa Agricultural testbed consists of three LoRa Gateways (GW) that are deployed in three crop fields and 7 Sensing nodes that are scatted across the area of North Macedonia, Greece. The end nodes feature various sensors related with meteorological and agricultural measurements. We clearly observe that the testbed offers a wide range of wireless links that differentiate in terms of communication distance, elevation difference and LOS/NLOS conditions. For each node, we also note the amount of payload bytes transmitted when transferring the respective number of sensed parameters, which includes 5 Bytes per environmental parameter plus 9 Bytes of own protocol overhead, while it does not include the LoRa preamble, header and CRC. In Fig. 1 presents the topology of our testbed, while in Fig. 2 you can find the architecture of our system. Below we present the custom developed GW and sensing devices, as well as the software toolkit for obtaining LoRa performance measurements.

LoRa Gateway: The GW is based on the BeagleBone Black Rev. C board which is a low-cost, embedded platform characterized by sufficient processing power capabilities (ARM Cortex-A8 Processor at 1 GHz with 512 MB RAM) and several I/O pins. It also includes a USB port which is used for a 3G/4G interface for communicating with the backbone network. On top of BeagleBone we attach a custom-designed PCB board (cape) that integrates our electronic components and features a slot for connecting a LoRa transceiver. More specifically, the cape features the MK20DX128VLH5 micro-processor which is interfaced with the LoRa transceiver responsible to run all the requisite libraries for its operation. The micro-processor software is also responsible of implementing a polling mechanism to aquire measurements from the sensor nodes and also initiate the link quality experiments. For the LoRa transceiver we employ the SX1272 chipset manufactured by Semtech, which is paired with a 4.5 dBi antenna. Fig. 3(b) presents one LoRa Gateway device deployed in the field..

LoRa Sensing Devices: Our setup consists of two types of edge devices, the meteo and the agricultural. Both devices are power by Libelium’s Waspmote processing module an employs the same LoRa interface (SX1272) as the gateway device, attached to a 4.5 dBi omni-directional antenna. The meteo nodes features 9 sensors in total which provide measurements about temperature, humidity, atmospheric pressure, air speed, air direction, rainfall percentage and solar radiation. Also they utilize and the features from the agricultural nodes which are leaf wetness, soil moisture. The agricultural nodes features 5 sensors in total which provide measurements about temperature, humidity, atmospheric pressure, leaf wetness and soil moisture. The micro-processor hosts a program that implements the sensor reading and collection of measurements, and also the communication between itself and the SX1272 module. Finally, both sensing devices are battery powered and they are equipped also with a solar panel capable of recharging the batteries. The devices in every communication with the GW provide measurements about battery percentage and current provided by the solar panel in mA.Fig.3(a) presents one meteo device attached with a solar panel and the meteo sensors and Fig.3(c) presents an agricultural device attached with a solar panel and the agricultural sensors deployed in the field.

Software Toolkit: Through the deployed list of devices, we continuously collect detailed air quality measurements, while also evaluate the performance of the employed LoRa communication links. The overall procedure is orchestrated at the GW level, which periodically polls the different sensing nodes that continuously remain in receive mode. Sensor polling is executed in a Round-robin fashion, instructing sensors to transmit collected measurements (with an interval of 10 minutes) or to participate in a link quality evaluation experiment (executed once per day). The two procedures are executed independently of each other, taking advantage of the employed polling approach, which enables us to avoid the impact of overlapping transmission interference, when performing link quality experiments. Upon receiving a request for experiment, each sensing node transmits 10 consecutive packets at the data rate, payload length and transmission power that has been determined by the GW. The gateway sends the experiment settings embedded to the experiment request packet. The per-node link quality of the network is determined through the Packet Delivery Ratio (PDR) of the aforementioned experiments.

ITS Overview

NITOS is an Intelligent Transport System (ITS) compatible facility thanks to the implementation of the key components of the ITS protocol stack. The designed platform is given freely to the experimenters who want to conduct experiments with Vehicular Ad-Hoc Networks (VANETs).

The different sub-applications needed to run on our platform for real world experiments are

• the basic GeoNetworking protocol core,
• the Basic Transport Protocol (BTP) as a means of a Transport layer protocol,
• a minimal facility layer used to generate traffic,
• a minimal implementation of the ITS management layer
• the mobility emulation environment

Our implementation realizes the ETSI TS 102 636-4-1 for Geographical addressing and forwarding for point-to-point and point-to-multipoint communications, providing media independent functionality. The address format specified in the standard is using a 64-bit representation, comprised of a bit for distinguishing whether the address is set automatically or manualy, a 4-bit field representing the ITS station type (roadside unit or a vehicle), a 1-bit indicator of whether the station is a private or public transport vehicle, a 10-bit field indicating the country code and finally a 48-bit field with the MAC address of the station. Since our implementation targets at giving open access to the experimenters to a working GeoNetworking protocol, we use a configuration file as an input to the GeoNetworking daemon. As it is specified in the standard, a GeoNetworking implementation should be configured through a Management Information Base (MIB). We consider that provisioning a MIB is beyond our initial goals, so we expose some of the MIB parameters through an external configuration file. All these aforementioned parameters can be setup through the configuration file provided to the experimenter. Moreover, through the configuration file the experimenters can setup the communication parameters with the facility and management layer, in case they want to use their own implementation, and the primary interface that will be used for communication. It is worth to mention that we currently support only Ethernet and WiFi interfaces, but we intend to extend it to using WiMAX and LTE interfaces.

The standard specifies six different types of packets;
1) Beacons

2) Single Hop Broadcast (SHB)

3) Topologically Scoped Broadcast (TSB)

4) GeoBroadcast/GeoAnycast

5) GeoUnicast

6) Location Service packets

Our implementation is able to support all GeoNetworking type of packets, except for the creation of the Location Service packets. These type of packets are triggered when no entry of the location of a specified host is found in the Location Table (LocT). Beacon packets are exchanged when a specific timer expires, which is reset each time that the GeoNetworking enabled station sends a packet of a different type. This feature explicitly defines that Beacon packets are sent only when no other communication involving the specific station takes place, so as for it to advertise its location. The rest type of packets are triggered when receiving an appropriate indication by the facility layer. TSB messages are used for broadcasting messages to nodes located more than one hop away. GeoBroadcast messages are used in the case of broadcasting/anycasting messages inside a geographical region, and are used mainly for road safety and event information applications implemented in the application layer. Finally, GeoUnicast messages are used for transmitting messages to a specific host whose location information is already known.

Our daemon is written in a way that can scale in terms of heavy node network congestion. It is multi-threaded, using different threads for the process of beaconing, receiving packets from the network, receiving packet requests from the facility layer, receiving management messages from the management layer, holding the location table and finally for invalidating expired entries in the LocT. The threads responsible for receiving messages are subsequently forked in the case that a transmission of a packet is required, either when the station is a transmitter and the network packet has been received from a higher layer or when the station is a forwarder of a packet already received from the Link Layer. Furthermore, since the GeoNetworking protocol is built so as to maximize the spreading of information in a geographical area, each packet might be retransmitted several times within it. Typical examples are the TSB and GeoBroadcast packets, where each receiving host will retransmit the packet if either the hop count is greater than zero or the host is inside a defined geographical area. For this reason, a duplicate packet detection mechanism has to be used. The packets which are meant to be retransmitted bear a sequence number (SN) incremented by one each time that such a packet is triggered.

By retaining an entry in the LocT with the last SN received from each neighbour, each host manages to keep track of the packets received per host. Using this kind of mechanism, GeoNetworking core is able to detect duplicate packets and discard them without any further processing. In order to accomplish true communication using location information, we used the definitions of a geographical area as defined in the ETSI EN 302 931 standard. The standard defines three different types of geographical areas; circular, rectangular and elliptical. Each one of the areas is defined using two points and the azimuth angle of the longest axis.
The GeoNetworking protocol is using this information in the cases of GeoBroadcast and GeoAnycast messages only and should totally be agnostic to these parameters; the protocol receives these parameters by means of a data request received from the facility layer.

Mobility Emulation Framework

Since the nodes comprising the testbed are static, we had to create an environment that would emulate the mobility at least at the GeoNetworking layer. To this aim, we employed the gpsfake and the gpsd applications. The former is used for parsing a file with NMEA sentences and feeding this data directly to the latter. Gpsd is the state-of-the-art application in UNIX systems for parsing data from a GPS device. Any application can query a running gpsd instance for position information which is returned to it in a JSON format. 

Our Management layer is using this exact procedure; queries the gpsd daemon, parses the JSON file and creates the appropriate position update message for the GeoNetworking daemon. By using this approach, we have managed to emulate mobility in the Network layer of the NITOS nodes. The validity of our approach has been verified through our experimental framework where the nodes inside a geographical area only retransmit the GeoBroadcast packets in the case that they are all located inside it. However, action has to be taken in order to have a fully working mobility setup in the Link layer as well, so as the nodes defined under different geographical areas are outside each other’s coverage area. We are able to currently support this action manually by carefully selecting the nodes that comprise our experiment and change their transmission power. Using the ath5k driver we are able to configure the transmission power of the WiFi card with a value between 0-27dBm. Although this process takes place by issuing the appropriate commands, we are currently in the process of extending this kind of support by using UNIX debugfs filesystem. Directly from the management layer we will inform the wireless driver about the node’s position to appropriately adjust its transmission power, thus enhancing our framework with a cross-layer approach.