1. Introduction
The Internet of Things (IoT) refers to the network of different devices, designed to provide smart services and applications without the need of human intervention. It is one of the key technologies of the near future [
1]. Essentially, IoT is a “system” where the network itself and all the connected devices have “less of everything”: less memory, less processing power, less available bandwidth, less available energy etc. [
2]. Notwithstanding, the set of sensors and devices connected to the IoT is continuously increasing. It has been estimated that 50 billion devices will be connected by 2020 [
3].
IoT offers a wide range of possible applications. Actually, the basis of IoT is the pervasive, continuous, and efficient real data collection. Data can be acquired, transmitted, stored, and aggregated for different purposes [
4,
5,
6]. The future will be a world where the objects will become “smart” and integrated into a large information network exploiting the global connectivity. Services will also be available to interact with these “smart objects”, query and change their state and any information associated with them, taking into account security and privacy issues as well.
The set of “smart objects” (both sensors and equipment) by which IoT is made of, constitutes a wide Distributed Measurement System (DMS) [
7]. Among the infinite range of possibilities that IoT is able to offer, one of the most important is related to implement smart cities, with pollution and environmental monitoring, and transportation control [
8]. In particular, the real-time, efficient, and distributed monitoring of environmental pollution and meteorological parameters (such as temperature, atmospheric pressure, and humidity), also known as Environmental IoT (EIoT) [
9], is one of the goals that most cities are trying to achieve for various purposes. Although standard observation stations have been used for decades, they present some limitations for measurements with a higher spatial resolution. Indeed, they pretend to monitor large areas but the collected data ends up being the average of numerous contributions, not allowing to precisely identifying critical zones (e.g., small and defined areas more subject to pollution problems) and not giving the possibility to improve the performances of the local meteorological and weather forecasting models.
Of course, ad-hoc instrumented vehicles would be too expensive. However, it has been already proved that standard vehicles can be used as meteorological integrated sensors; they can be either properly equipped with a specific monitoring station [
10,
11,
12] or they can even use the set of sensors currently installed on them [
13]. A valid means to realize a capillary and distributed monitoring system is represented by the city’s public transport fleet. In fact, according to the European Metropolitan Transport Authorities (EMTA) Barometer 2015, 11° Edition, public transportation covers, on average, an area of 1432 km
2 of urbanized surface [
14], corresponding to the area that can be monitored. A report of, Italian National Institute of Statistics (ISTAT, Istituto Nazionale di Statistica) from Italy from 2015 shows that the public transport system has more than 200 vehicles distributed over the municipal territory of the biggest Italian cities (e.g., Milan, Turin) [
15]. Continuously moving within the entire city area, vehicles are able to provide a near real-time map of air quality and environmental parameters as well as detailed statistics defining hourly and daily trends.
Some experimental Wireless Sensor Networks (WSNs) for similar purposes were already proposed. For example, [
16,
17] presents WSNs based on Zigbee. However, they are not based on Low Power Wide Area Network (LPWAN) technologies [
2].
LoRa is only one of many LPWAN technologies. Among the others, we have: Sigfox [
18], which offers longer-range communication with respect to LoRa but has service subscription costs; NarrowBand IoT [
19] (NB-IoT) that differs with respect to LoRa since it is a cellular, and then SIM-based technology [
20]. Other technologies are also Weightless, 5by5 Wireless, HaLow, and so on.
Among the main advantages of LoRa with respect to traditional technologies, are its long-range capabilities (up to 15 km), battery life optimization, easy deployment, and robustness to interference [
21]. These features make LoRa the ideal choice for a vast number of IoT applications. A detailed study about LoRa, including the report of different tests, is documented in [
22] where some possible solutions for performance enhancements of a IoT network based on the LoRa technology are also proposed.
While most implementations built with these technologies are single-hop networks used to connect only end-devices to gateways and relying on the Internet for the remaining part, there are examples of multi-hop networks based on LoRa. In [
23], a multi-hop linear network is deployed, with nodes forming a line topology and packets travelling from a node to the next in the line. In [
24], the focus is on the effects of concurrent transmission in a multi-hop network, in order to ensure network reliability. The proposed network has a very simple multi-hop structure with respect to other proposed solutions for IoT, including, among the others, clustering [
25], adaptive clustering [
26], and specific routing clustering algorithms [
27]. However, we believe that the proposed approach, even if simple, is suitable for the application of a DMS using public transport. A future further extension of this approach to other vehicles, can be also used to improve address problem of interest, energy and physical-aware coalition formation and resource management in smart IoT applications [
28,
29].
The Low-Power Wide Area Network (LPWAN) presented in this work is realized with LoRa technology, a wireless communication technology (working on free-of-charge unlicensed spectrum) that uses Chirp Spread Spectrum (CSS) modulation to encode information.
The prototypal network includes three types of nodes, which differ in their role but not in their hardware. On the public transport vehicles, the sensor nodes are installed on the vehicles themselves; they transmit air-quality sensors’ and weather-parameters sensors’ data to the gateway, together with position, date, and time information. Gateways spread around the city receive the information and relay it to the supergateway, a central node which processes this information. The supergateway may display the data, keep track of the correct operation of end-nodes and gateways belonging to the network, reporting any possible malfunction.
Figure 1 is an example of potential installation in the city of Turin, Italy.
After a brief presentation of the LoRa technology (
Section 2), we focus on the theoretical analysis of propagation performance (
Section 3). We describe the networking solutions that could be properly adopted for the realization of a LoRa-based WSN using public transport (
Section 4) and the software implementation (
Section 5). Conclusions and outlooks are given in the last section.
2. LoRa Technology
LoRa is a proprietary wireless communication technology featuring long-range capabilities, with low-power consumption, although with low data rates. Developed by Cycleo and acquired by Semtech in 2012, it uses license-free sub-gigahertz radio frequency bands. Its characteristics make it suitable for IoT and Machine to Machine (M2M) communication over wide areas, requiring a modest amount of exchanged traffic. The LoRa modulation scheme derives from the Chirp Spread Spectrum (CSS) modulation technique, which encodes the information in chirps [
30]. As the expression spread spectrum implies, this technique uses the entire allocated bandwidth to transmit the signal. For this reason, it exhibits robustness to noise and other channel degradation mechanisms such as multi-path fading (urban applications). It also mitigates the Doppler Effect (mobile applications).
In particular, the Doppler aspect is very important for the present prototypal LPWAN. According to [
31] the CSS modulation set for LoRa allows a frequency offset between the transmitter and the receiver up to 20%, which should be enough to avoid problems due to the velocity of the LoRa transceiver in our application. The results presented in [
32] show that some communication problems may arise at around 40 km/h and that the number of lost packets increases according to the increasing speed, reaching up to 33% packet loss when the velocity of a car reaches 100 km/h. In any case, the speed limit inside urban centers (valid also for public transport) is between 30 km/h and 50 km/h in most European cities. At those speeds, the success ratio for correctly transmitted and received packets is significantly higher. Hence, the LoRa technology is suitable for this kind of mobile application.
There are limitations, such as the restrictions and regulations on the duty-cycle, the possibility to send only sparse datagrams, and the already mentioned limited data rate. These constraints do not negatively influence the use of LoRa for the proposed applications.
LoRa is the physical (PHY) layer (the lowest layer in OSI communication stack) implementation and it works regardless of the technology operating on upper layers. In this respect, the LoRa Alliance™ has developed the open-source LoRaWAN specification [
33]: an infrastructure consisting of media access control (MAC), network, and application layers built on top of LoRa. LoRaWAN is organized in a star-of-stars topology in which gateways relay messages between end-devices and a central network server; gateways are connected to the network server via standard IP connections, while end-nodes use single-hop LoRa communication to reach gateways.
For our purposes, both LoRa and LoRaWAN technologies can be used, but only LoRa was preferred since it does not enforce the gateways (see next section) to be connected to the Internet, giving the possibility to create an entire ad-hoc network using plain LoRa communication. However, to provide basic medium access control (MAC) features, a carrier sense mechanism was implemented in software to reduce collisions as much as possible. It is possible to configure different LoRa in order to adapt the technology to the working scenario and needs of the network to be realized. These parameters are
the bandwidth, to be chosen from 125, 250, and 500 KHz, defines how wide the transmitted signal is;
the spreading factor, a number in the range 6–12 which indicates how many bits are used to encode each symbol;
the code rate, from 4/5 to 4/8, specifies the proportion of useful transmitted bits (non-redundant).
According to the results presented in [
34], a properly configured LoRa-based network allows one to reach a communication range of 15 km with an average successful packet delivery ratio of up to 97%. Of course, for the presented application, we need a shorter communication range.
3. Theoretical Analysis of Propagation Performance
In order to get deeper insight into the maximum distance that could be covered in urban areas at the frequency on which LoRa modules operate in Europe, a theoretical analysis of the propagation performance in term of range and received power was performed. Wireless channel characterization is determined by path loss, shadowing, and multipath fading, where the last two quantities are extremely important in an urban environment and may heavily affect the propagation performance of a radio link.
This analysis is also useful to estimate the maximum distance at which end-nodes, gateways, and supergateways can be installed, taking into account different values of transmitted power.
In general,
indicates the power radiated by the transmitter, expressed in dBm,
and
denote the antenna gains, respectively, of the transmitter and receiver expressed in dB, and
denotes the path loss attenuation, expressed in dB, caused by both the distance between transmitter and receiver and the different characteristics of the surrounding environment. The received power
can be calculated as:
At present, there is no specific path loss model for the LoRa technology in order to estimate
. However, there is a large number of different empirical propagation models which were developed and/or derived from experimental measurements using different standards, different frequencies, and in various propagation conditions. Some of them can be used for the frequency band dedicated to LoRa in Europe. For instance, in [
35], the Erceg model [
36] is used with promising results compared with experimental measurements with a maximum difference 100 m in the useful range. The problem is that the Erceg model tends to overestimate the distances in urban environments due to dampening by buildings and other urban structures. In [
32], the authors present an analysis and possible optimizations of the Lee propagation model [
37], which can be used for both area-to-area, and point-to-point communications. The model is used to predict the path loss over flat terrain but, according to some arrangements and optimizations, it is possible to adapt it to urban areas. The applicability of Lee’s propagation model is efficient as soon as a proper variant is determined for each specific city but, in the case of Turin, this information is not available. However, by similarity, it could be possible to use the standard parameters defined for urban areas and already applied in some cities (e.g., Newark, USA, [
33]), considering the obtained results as indicators of propagation performance.
When dealing with transmissions between 100 and 1500 MHz in urban areas, the empirical Okumura–Hata model [
38] can be used with good results since it has been specifically developed for wireless communication in urban environments. Equation (2) yields the path loss
by knowing the operating frequency
in MHz, the transmitter and receiver heights
and
expressed in meters, the correction parameter
, Equation (3), due to the area type (urban area or, even, country area), and the distance
between transmitter and receiver expressed in kilometers.
Even if a LoRa receiver can have a sensitivity up to −157 dBm [
39], a lower reasonable limit for received power
has been set to −120 dBm. It is a receiver hypothetical sensitivity value that ensures correct reception with a good margin, including all the possible sources of additive path losses. A 0-dB gain antenna for both transmitter and receiver antennae is assumed, in order to simulate them as omnidirectional sources because we do not know their orientation, and by varying the transmitted power it is possible to obtain different distances covered by the signal.
According to LoRa specifications and European regulations, the transmitter power can vary from a minimum value of 0 dBm up to maximum value of 14 dBm. The LoRa operating frequency is 868 MHz. At first, the heights of transmitter and receiver are supposed to both equal 3 m and then the receiver height was assumed at 20 m in order to simulate a different possible scenario of installations in an urban environment. By means of Equations (1)–(3), we can evaluate the maximum communication ranges reported in
Table 1, assuming a real antenna with gains = 3.16 dB.
The results are reasonable for the deployment of a DMS based on the LoRa technology in an urban area. The LoRa end-node installed on a public transport vehicle can communicate with the nearest gateway at less than 500 m apart if operating in the lower possible power consumption mode (transmitting only 0 dBm). Of course, this range can be increased using proper antenna with a gain greater than 0 dB. In that case, the maximum distance between nodes and gateways can be around half a kilometer: An example of tentative installation of gateways in Turin is reported in
Figure 1. It appears that the maximum distance between two bus stops, where the first level gateways will be installed, does not exceed some hundreds of meters.
A comparison between the theoretical results obtained with the Okumura–Hata model and some experimental measurements is given in [
40], where some preliminary propagation tests using both a point-to-point and a star topology network are introduced. The tests demonstrate the capability of the system to correctly receive data, in terms of both received power and packet error rate, over a range of about 800 m. They demonstrate that LoRa can be used in a noisy urban environment.
4. Network Architecture
The network to be realized should cover a metropolitan city. The sensor nodes (also referred as end-nodes) will have to be installed on public transport vehicles. They will acquire information about environmental parameters through the installed sensors and will send data to the gateways. Gateways receive this information and relay it to the supergateway. The supergateway receives all the information and keeps track of the correct operation of end-nodes and gateways in the network, reporting any possible malfunction. The supergateway is connected to a computer equipped with an ad-hoc processing software and both a database server and a web server for storing and displaying the data measured by each node.
Since the network will be realized with LoRa technology without using the LoRaWAN protocol, a proper algorithm for both addressing and routing has been implemented. In general, addressing and routing can be implemented in either a static or a dynamic manner. Given the intrinsically static configuration of our scenario, this is reflected in the defined setup of the network. The best solution in terms of minimum exchanged traffic, throughput, and fault-tolerance turned out to be a multi-layer topology (which translates either into a star-of-stars or tree topology, depending on the position of the supergateway in the network). In this multilayer topology, gateways are organized in layers depending on their distance from the central hub. Considering the city of Turin, for instance, a possible configuration of the network is represented in
Figure 2. The distance between the central node and the gateways satisfies the propagation considerations and measurement results reported in the following sections.
As shown in
Figure 3, packets always travel from higher layers to lower layers reaching the supergateway, which is ideally at the zero level. The packets are transmitted in two different ways depending on whether the communication is from an end-node to a gateway or from a gateway to another gateway.
It is important to highlight that the transmission of a single packet, according to the chosen SF of LoRa modulation, may be as long as some seconds. It means that the communication between the end-node and a specific gateway receiving the packet must be ensured for the entire transmission of the packet. However, this is not a problem, since the distances of the gateways from the end-nodes (that are in movement) are properly designed to avoid the needs for roaming operations.
First mode: the end-node sends a broadcast message looking for a gateway nearby; gateways receiving this request inform the end-node about their availability to handle the packet. The end-node will forward it to the first gateway answering its initial query. In the unfortunate event that there are no gateways nearby, the end-nodes keeps trying and looking for another available gateway.
Second mode: a gateway, which receives a packet, does not behave as an end-node (looking for gateways nearby and sending the packet to one of them); it instead realizes a multicast communication directed to all gateways of the lower layer, thus allowing the packet to reach the supergateway. It is straightforward that such an implementation results in some redundancy in the network, but this phenomenon can be limited by properly arranging gateways in space. This apparent disadvantage can be also exploited to keep track of working nodes in the network and detect possible faults (
Figure 4). This operation is carried out by the supergateway. Before discarding duplicated packets, it checks the path they followed and infers, based on the knowledge of the entire topology of the network, which gateways may not be working correctly. Since end-nodes are expected to collect data from sensors and transmit them at regular time intervals, the supergateway is able to identify malfunctioning end-nodes as well.
Similarly, the end-nodes–gateways communication can be analyzed for fault detection. Apart from leading to a higher level of redundancy without consistently improving the performance and robustness of the network, this implementation may solve another major problem. If, by chance, no gateway happens to be in proximity of the end-node at the time of the transmission, the information would not be lost; in fact, in the current implementation, the end-node repeatedly sends its request-for-transmission packet until a gateway replies.
Concerning the power consumption, since the gateways need to be always listening for incoming messages, they must always be on. According to [
33], their mean supply current in receiver mode is about 11 mA.
To save power, different solutions may be adopted, according to different installation scenarios. Among them, it is possible to highlight the following two strategies:
To save power during transmission, it is possible to send a lower number of packets by adding two or more messages coming from nodes in a single packet. It depends on the size of the received packets. In this case, the time-on-air of a single packet will be higher but the number of transmissions will be lower, hence saving power.
If gateways are located at bus stops, the power system could be improved by including small photovoltaic solar panels to generate electricity and charge the battery powering the gateway.
Another alternative could be activating the gateways only during specific periods of time: however, this strategy is not recommended since there will be a high probability of not hearing the incoming packets (it depends on the network deployment, the geographic distribution of the gateways, the number of end-nodes transmitting, and how often the end-nodes are transmitting). It may happen that if any of the gateways receive the broadcast message, the end-nodes will keep sending messages looking for another gateway, which means that the power required at the first mode will be higher.
It is also to be noted that the network proposed in this feasibility analysis is based on LoRa technology. The applicable restrictions regarding the time-on-air depend only on the frequency sub-band in use. For the frequency in use (868–868.6 MHz), the regulatory regulations for Europe are given by the European Telecommunications Standards Institute ETSI under the ETSI EN 300 220-2 Standard [
41] and ERC Recommendation 70-03 as follows [
42] as reported in
Table 2. Based on that information, time-on-air restriction policies will be applied to comply with the regulations.
5. Software Implementation and Description
A preliminary version of a software to manage the network has been developed and tested. The software to control the entire network, and specifically end-nodes, gateways, and supergateways, was written with the Arduino IDE and is based on the SX1272 library developed by Libelium, properly modified and adapted. This choice is based on the fact that Arduino is an open source platform that can be adapted to different purposes and control different potential sensors of a DMS. Since many aspects of software were common to all three types of nodes, a new library was created to improve modularity, code reuse, and maintenance. Of course, in this way, a significant reduction of the development time and costs has been achieved.
LoRa reserves one byte for the specification of the network address of a node, with the special value 0 used for broadcast communication and therefore unassignable to any node. Since having a unique address for each end-node is an impracticable solution, they all share the same network address. This does not cause any conflict in the network, but has the downside of making end-nodes undistinguishable from each other. Consequently, there is the need to reserve some space in the packet payload for the indication of a unique sensor ID, in order to identify end-nodes appropriately. As opposed to these terminal nodes, the supergateway is unique and it has address 1, while five addressing classes are devised for the five levels of gateways (
Table 3). Additional addresses, one for each level, are reserved for the multicast communication previously described: they target all gateways belonging a certain level, and this mechanism allows the flowing of data packets from higher layers to the central hub.
The generic data packet is created at the end-node, which populates it with the measured data (including position and timing) and sends it to the first gateway it encounters. Each gateway adds the required information to allow the supergateway to know which path has been followed by the packet. Since the maximum number of levels has been limited to 5, this implementation choice does not cause any problem of exceeded packet size and respects the LoRa specification.
The structure of the packet payload is reported in
Table 4. The meaning of the definitions is as follow:
TYPE is an integer defining the type of packet; as descripted in the previous section, the implementation provides not only for data packets but also for control information packets.
TRIP lists the path of intermediate gateways traversed, and it is there to allow the supergateway to discover malfunctioning gateways.
SID contains the sensor ID of the end-node that generated the packet.
TS is the date and time (timestamp) when the measurement was made.
POS reports the position (GPS coordinates) of the vehicle at the time that data from sensors were collected.
MSG contains the formatted sensor data, composed of environmental pollution information and meteorological parameters.