Monitoring systems have definitely evolved since the emergence of the Internet of Things (IoT) paradigm [1
]. Old-fashion complex supervision systems are now being replaced by more recent wireless cost-effective solutions that permit control and observation of a wide range of elements or events, almost in real-time and from any place with a connection to the Internet. Many technological advances have contributed to improvements in this field, but two have been decisive for its quick implantation, namely: (i) The development of low-cost and energy-efficient monitoring devices, and (ii) the progress of communication technologies to match the requirements of these systems, such as long-range and robust transmissions.
Cheap and easy-to-use hardware platforms are now available on the market, and are reaching the general public. Example of these devices are the Arduino or Raspberry Pi boards, which are capable of performing functions that only some years ago needed industrial hardware. Thereby, these platforms allow easy monitoring of physical events by themselves, or they may be connected to larger systems with the aim of extracting monitoring data. Thereafter, the collected data are forwarded to centralized control systems, usually through wireless links. Thus, regarding the wireless transmission technologies employed in these architectures, some features are of prominent importance in order to boost the deployment of both reliable and practical monitoring systems. These characteristics are related to the need of having long-range communication solutions with very low energy consumption for end-devices, because they are usually powered by batteries. Another desirable feature is system scalability, as it is envisioned that billions of end-devices will be simultaneously connected within future IoT architectures [2
]. In this line, one communication technology that meets these demands, and that is fully integrated within the IoT ecosystem since its inception, is the Low Power-Wide Area Network (LPWAN). This recently-proposed communication alternative promises long transmission distances (over 15 km in rural environments), long end-device lifetime in years, and high scalability, which permits the connection of hundreds or even thousands of end-nodes concurrently to a single base station [3
]. For these reasons, LPWAN solutions are attracting the attention of both the research community and industry [4
]. Among the different technologies following the LPWAN paradigm, LoRaWAN (Long Range Wide Area Network) has become one of the most adopted solutions, due to its flexibility and characterization possibilities [3
One vertical that is experiencing a considerable revitalization since the appearance of IoT-related services and the upcoming 5G is the vehicular sector [6
]. Under the umbrella of Intelligent Transportation Systems (ITS) and Internet of Vehicles (IoV) paradigms, many novel services will take advantage of the rich variety of connectivity options that vehicles will present in the near future [7
]. The integration of different communication technologies on-board vehicles will enable the development of solutions in many areas, such as safety, green transport, goods or fleet monitoring, and traffic analysis, among others. Although some efforts were done in these directions some years ago, during the emergence of IEEE 802.11p-based technologies, the need for deploying dedicated infrastructures, together with the limited range of Vehicle-to-Vehicle (V2V) communications and the penetration rate issue, lead to a deceleration of these initiatives [8
]. For that reason, the integration of a series of Radio Access Technologies (RAT) in a single on-board control system has been envisioned as a promising step in gathering all of the services and applications mentioned above, which are highly related to the concept of smart cities or, in general, smart spaces [9
]. While the integration of cellular technologies in the vehicular ecosystem has been deeply studied in the past years [10
], the use of LPWAN-based solutions in this area has not been exploited yet [13
], and they could present a real alternative for battery-constrained transport means, such as scooters or bikes.
Therefore, in this work we focus on the concept introduced in Figure 1
and propose a flexible and extensible end-to-end monitoring platform for vehicles, taking advantage of LPWAN as either the sole communication technology, or hybridized with others. We have developed the different modules of a system, that ranges from data extraction by using the On-Board Diagnostics II (OBD-II) protocol (telemetry application), to their presentation by developing a cloud-based dashboard system. As depicted in Figure 1
, the data transmission from the On-Board Unit (OBU) to the infrastructure has been carried out by means of an LPWAN solution, namely LoRaWAN, with the aim of obtaining a long-distance and reliable monitoring system. In addition, we have designed and implemented a generic network interface for Linux-based systems, that permits the sending of application-layer packets through the LPWAN link using IPv6 and UDP, and using a compression mechanism based on IETF, works for these kind of networks. To the authors’ knowledge, this is the first implementation of an LPWAN-oriented network interface ready to use in normal operating systems. An experimental test-bench has been deployed, in order to demonstrate the validity of the proposed monitoring platform, which enables the tracking of vehicle position as well as mechanical status, among others. Thus, the main contributions of this work are the following: (i) A real monitoring platform for vehicles using LPWAN has been designed and developed, (ii) a performance study of LoRaWAN technology in vehicular scenarios has been conducted, and (iii) a generic Linux interface that enables direct and seamless transmission of application-layer data has been implemented.
The rest of the document is organized as follows: Section 2
reviews the related work regarding on-line monitoring systems for vehicles. An initial review of the main technologies used in the solution is given in Section 3
, including LoRaWAN and IETF LPWAN compression. Next, Section 4
explores the proposed architecture. Section 5
describes the implemented development, as well as the test-bench employed for obtaining the validation results, which are showed and discussed in Section 6
. Finally, the paper is concluded in Section 7
, summarizing the main achievements and including future research lines.
2. Related Work
Monitoring vehicles, to locate or manage them, is a field that has recently been widely explored. However, most of the proposed systems are based on short- or medium-range communication technologies, such as IEEE 802.11p [15
], cellular-based solutions [17
], or even Radio-Frequency Identification (RFID) [19
]. These transmission technologies present important drawbacks, related to their limited coverage range. In the case of short-range alternatives, such as the extensively studied IEEE 802.11p protocol, the vehicles need to support each other in order to forward the generated data toward the infrastructure elements, namely road side units (RSU), which give access to these data from the outside world (e.g., by the internet). This fact severely increases the complexity of the network management, as well as its instability due to the difficulties of 802.11p to properly work in highly dense scenarios [20
]. In turn, the use of cellular-based alternatives (e.g., 4G or the upcoming 5G) has been also used for providing vehicles with seamless connectivity [21
]. This technology has been especially exploited in the last ten years for fleet management purposes. However, although the previous approaches present acceptable coverage levels in urban environments [6
], they are not able to cover large extensions per base station, especially in rural areas due to the lack of a pre-existent and expensive cellular infrastructure.
In turn, the application of LPWAN communication systems for vehicle monitoring may overcome the coverage limitations of the transmission technologies employed so far. Thus, the deployment of LPWAN networks will allow better monitoring of vehicles in remote areas, due to the long distances covered by a single gateway [4
]. In fact, some European countries (such as Spain, France, and the Netherlands, among others) are now fully covered by the LPWAN solution called Sigfox [23
]. Although LPWAN technologies were not designed for this specific scenario, they present interesting characteristics that make them suitable for employment in vehicular monitoring, such as great communication link budget, resilience to interference, and good performance at low power, while being robust to multi-path propagation fading and the Doppler effect. In fact, some works have evaluated LPWAN-based solutions in different network configurations valid for the vehicular ecosystem, such as single-hop [4
], multi-hop [24
], or Device-to-Device (D2D) [14
] architectures. Thus, works in Refs. [4
] presented two different extensive performance evaluations of LoRaWAN in different experimental scenarios, with the aim of exploring the maximum transmission distances reached depending on the environmental conditions. Authors of Ref. [4
] found a maximum range of 18 km in rural areas without obstacles. In addition, authors of Ref. [5
] also evidenced the robustness of LoRa against the Doppler effect. Authors of Refs. [24
] focused on deploying multi-hop uplinks, in order to extend the communication capabilities of end-devices towards the gateway. Concretely, these works studied the optimum network routing organization, with the aim of finding the routes with the lowest energy consumption for the end-devices acting as relays. Observe that this architecture may be also valid for vehicular scenarios, as one vehicle could help another to reach the gateway. Further, considering this network topology, the number of deployed gateways may be reduced with the aim of reducing infrastructure costs. Finally, work in Ref. [14
] also explored the application of LoRaWAN in vehicular scenarios, but under the opportunistic/intermittent network paradigm. The attained simulation-based results demonstrated better performance of LoRaWAN, in comparison with WiFi technology, in this type of scenario. This solution may be also valid, together with a multi-hop strategy, in order to transmit delay-tolerant data.
As a difference, with the work presented in this paper, none of the studies mentioned above deployed an end-to-end monitoring platform, neither including real data extracted from the vehicle nor a visualization system nor, as a prime advance, integrating a generic UNIX-based network interface for LPWAN. In fact, we explore the entire process as follows: (i) Vehicle data collection by means of an OBD-II interface, (ii) data compression by using the novel IETF Static Context Header Compression (SCHC) scheme, (iii) data transmission via the LoRaWAN link, through the developed LPWAN UNIX network interface, and (iv) data visualization from a data server hosted in the cloud, by means of a web-based dashboard.
3. Technological Background
A brief technological introduction is given first, with the aim of improving understanding of the proposal. This is focused on LoRaWAN and the compression and fragmentation mechanism for LPWAN defined by the IETF, namely SCHC.
LoRaWAN is one of the most prominent LPWAN-based technologies. Concretely, it is based on LoRa, which is a modulation based on the Chirp Spread Spectrum (CSS) modulation technique and developed by Semtech [26
]. LoRa follows the following precepts: (i) Reduced transmission bit-rates, (ii) use of low-frequency bands (sub-GHz bands), and (iii) limited end-device communication capabilities, in order to enable long transmission distances (of more than 15 km) with reduced power consumption, that permits battery lifetimes of years [3
]. Thereby, LoRa uses reduced data rates of just a few kilobits per second (kbps), which permits the development of receiving modules with high sensitivity. This fact permits the receiving equipment to decode the received signal at very low power-levels. This transmission robustness is further improved by the CSS-based modulation, as stated above [26
]. In addition, LoRa uses unlicensed low-frequency bands, that is, Industrial, Medical, and Scientific (ISM) bands (such as 868 MHz and 911 MHz in Europe and America, respectively). The use of sub-GHz bands improves penetration and transmission distances, in comparison with other typical, higher-frequency, bands, such as 2.4 GHz. Aiming at saving energy in the end-devices, the communications in LoRaWAN systems are limited in both the number of transmissions per node per day, and the length of each transmission [27
]. This is also related to the use of unlicensed frequency bands, so the number of transmissions and their duration need to be controlled, in order to avoid overuse by certain applications or nodes.
Regarding the architecture of LoRaWAN networks, as shown in Figure 2
, there is another layer on top of the PHY level (LoRa) that gives the name to the whole system, LoRaWAN. Actually, it defines the MAC-layer mechanisms and other architectural aspects, such as network security and its organization. Regarding the latter, LoRaWAN makes use of a star or star-of-stars topology (Figure 3
). This architecture permits simple and direct communication between end-devices and the gateway, hence avoiding other configurations with higher complexity (such as mesh networks). Observe in Figure 3
that end-devices directly transmit to the gateway in one single hop (i.e., without the help of the rest of the network).
Considering mobility issues, end-devices transmit LoRaWAN messages in broadcast mode regardless of their position, movement, or speed. This means that any LoRaWAN gateway that hears the message will forward it to the correspondent network server (network service in Figure 3
); this way, changes or hand-overs among gateways are completely seamless for end-devices.
Finally, an interesting feature of LoRaWAN is the possibility of adapting its PHY parameters, namely LoRa parameters, depending on the transmission conditions. Therefore, LoRa has three different configuration parameters: Spreading Factor (SF), Coding Rate (CR), and bandwidth (BW). The SF adjusts the spreading level of the transmitted signal, in comparison with the original one. By enlarging transmission spreading, the link robustness is increased at the expense of reducing the data-rate. The transmission robustness may be additionally increased by including redundant information in each frame. The CR defines the number of redundant bits, in comparison with the useful data, and may be tuned using different pre-defined values in the European 868 MHz ISM band. Finally, LoRa transmissions usually employ a BW of 125 kHz, but other configurations are supported as well (such as 250 kHz or 500 kHz).
A key technological enabler to send IPv6 datagrams over an LPWAN network is the SCHC scheme [28
], recently drafted by the IETF lpwan work-group. The base proposal enables the compression and fragmentation of IPv6/UDP packets over any LPWAN network. To this end, communication peers share a pre-provided context that indicates how to compress and decompress the packets received. This context remains static during the life-time of the device, and contains a number of compression and fragmentation rules to be applied to different kind of packets. Thus, a short RuleID that is known beforehand is included in the packet header, instead of sending longer header fields.
In the scheme considered in this work, both the vehicle on-board unit and an application gateway have to agree on the SCHC compression rule applied. Hence, this approach is mainly applicable to the LPWAN communication and packet management segment, with the great advantage of interconnecting vehicles to the Internet in the uplink and downlink directions seamlessly for both ends of the communication. This is an interesting feature, aimed at integrating LoRaWAN end-devices within the IPv6 ecosystem, increasing their communication capabilities.
The potential of SCHC was initially evaluated in our previous work in Ref. [29
], providing promising results by transmitting Internet Control Message Protocol version 6 (ICMPv6) packets in a real environment. In this paper, this work is extended by addition of a data gathering platform (that uses OBD-II for the case of regular cars), a monitoring web-based interface and, above all, a remarkable development of a generic UNIX network interface to transmit IPv6/UDP packets over LPWAN.
4. Architecture of the Proposal
In this Section, the details of the architecture for remote monitoring in the field of road vehicles is presented. This architecture, briefly introduced in Figure 1
, and now detailed in Figure 4
, comprises an LPWAN-enabled access network in which end-nodes (i.e., the vehicles) directly communicate with a communication gateway, by means of long-range links established by an LPWAN technology. This communication is abstracted to applications, thanks to a new network interface that appears to the user as a regular UNIX one. As depicted in Figure 4
, this new interface acts as an LPWAN tunnel that transports UDP/IPv6 datagrams, which finally reach an application gateway after passing through the wireless LPWAN medium. The network server deals with MAC-level LPWAN packets, while the application gateway is in charge of interconnecting with IPv6 Internet and forwards the packets to a processing node in the cloud, which provides processed information to final services, or in a dashboard fashion. As can be seen in the diagram, the interconnection with IPv6 Internet is possible thanks to the use of SCHC, which adapts packets to traverse the constrained LPWAN network domain.
Although there is a direct application of the architecture in the regular car domain, it is important to emphasize the potential of the system presented to monitor new-age personal mobility vehicles, given the advantages of the synergy between embedded hardware platforms and LPWAN communications. For these vehicles, an embedded hardware platform can benefit from the solution, providing monitoring capabilities at low energy cost. Given that a great part of energy consumption in mobile devices is from the communication module, the usage of LPWAN technologies bring power savings within a new mobile IoT domain.
A detailed description of the generic UNIX interface embedded in the solution is given in Figure 5
. It is assumed that the on-board computer is provided with a UNIX-based operating system, and it is attached with the LPWAN modem within the same enclosure or a different one. In the diagram, LoRaWAN is showed, as it is the LPWAN technology used in the proof of concept.
The data flow starts in the OBU application, which collects data and sends them to the remote server through the internet, using the LPWAN link as a wireless last-mile network access. The data collected (or the information to be transmitted) is packed and sent using a common UNIX socket, programmed in our OBU. This is possible thanks to a new tunnel (TUN) interface, which captures the packets and adapts them to be transmitted through the LPWAN network. Our middleware compresses and fragments data using SCHC, following a context previously agreed, as explained above. Then the adapted packet, or a set of fragments, are passed to the modem for their transmission.
The design showed in Figure 5
includes a set of interfaces between the main software modules, which are detailed next:
Socket Interface: Allows the creation of transport-level packets and their transmission through the communication stack.
Routing Interface (RI): Applies layer-three rules to the packets received by the interface, such as filtering and routing to enter the tunnel interface.
Packet interface (PA): Moves packets to be transmitted to the SCHC compression and framing module.
Modem Interface (MI): Takes care of modem configuration commands and sends/receives the SCHC packets.
Controller Interface (CI): Forwards LPWAN packets and modem configuration commands to the PHY radio unit.
Radio interface (RA): Sends information through the radio medium using LPWAN modulation and coding.
UDP is chosen as the transport protocol for the Socket Interface, given the communication constraints imposed by LPWAN technologies, which make it impractical to consider connection-oriented protocols, such as TCP. Low data rates, an asymmetric performance of the uplink and downlink channels, and significant delays are the main reasons why datagram-based protocols are preferable. It is important to note that our network interface is designed to be adapted to different LPWAN technologies. For this, the MI interface should be implemented to communicate with the modem used, as well as the CI (if this is not implemented by the same modem). As said above, our reference implementation uses LoRaWAN, and MI uses AT commands to talk with the modem. CI is implemented with SPI communication within the LoRa transceiver.
Although the LPWAN network interface is mainly described from a sender point of view, it is important to note that the inverse process is needed when an LPWAN packet is received from the wireless medium. The RI interface prevents the OBU from receiving packets from unauthorized senders. Moreover, when an entering packet is received, a server socket is supposed to be listening in a proper port.
In this section we first present the scenario and context of our validation tests. Thereafter, the equipment employed for the experimental setup is comprehensively explored.
As explained before, the designed and implemented system is devoted to monitor and report the current status of road vehicles. Concretely, our validation test has been contextualized in the task of monitoring the vehicles employed for providing public services within the University of Murcia (Spain) campus, e.g., postal service or internal transport. As shown in Figure 6
, the main road in the campus is a ring that links the different faculties or service buildings. The major axis of this ring is 1 km long. This scenario presents high tree areas, buildings of up to five floors, and other obstacles for the wireless propagation, which convert this scenario in a realistic test-bench for our real-time vehicle monitoring platform. Please, note that the gateway location has been indicated as well in Figure 6
, which was affixed on the roof of an annex building of the Computer Engineering Faculty. This is an elevated position with respect to the ring area, which was the main region of study in our tests.
Following the architecture presented in Figure 4
, during the tests the data transmitted from the vehicle were received and forwarded by the gateway towards a central data server in the cloud, which processed and presented this information by means of a web-based dashboard. Moreover, the signal strength of the LoRa channel, in terms of Received Signal Strength Indicator (RSSI), was evaluated along the testing path.
Finally, regarding system scalability, please note that this work aims to present a proof of concept of the developed and deployed architecture, by using one transmitting vehicle at a time. In the case of having many vehicles concurrently transmitting data-packets to a common gateway, a planning study should be carried out, in order to estimate the number of simultaneous vehicles that can be hosted by a single gateway, depending on the frequency of the transmissions and LoRa parameters, such as SF, CR, BW, and packet length. For further information regarding LoRaWAN scalability, please refer to the detailed analyses presented in Refs. [27
5.2. Equipment and Implementation
The system architecture presented in Figure 4
has been developed to enable the validation and testing of the proposal. This has involved both a software development and a hardware set-up. The implementation has been released as open source (https://github.com/n0p/loratun
), and it is available for replicating the experiments carried out in this work, or for use in other projects.
Regarding the UNIX network interface for LPWAN, the RI interface has been implemented using the ip
UNIX command, in order to establish the forwarding rules to enable the transmission of packets through the new interface. No packet filtering has been established for incoming communications. The PA interface has been achieved by cloning the UNIX /dev/net/tun
interface into a new tunneling interface to be controlled with ioctl
calls. The flags IFF_TUN
have been used in the ioctl
interface request ifreq
. When the packets are captured by our middleware through this new interface, they are processed and sent to the SCHC software module, which is an evolution of the implementation presented in Ref. [29
] whcih now supports UDP/IPv6 compression. The MI interface with the modem is based on serial port communication, using a block-based device and an interface of type /dev/ttyUSB*
, given that a USB-to-serial converter is used.
As stated above, and further discussed in Ref. [31
], the restrictions posed by the LPWAN link leads to the need of employing compression schemes with the aim of optimizing the size of the packets to be sent in this constrained transmission channel. To address this need, our SCHC module has been developed on the basis of the guidelines described in Ref. [28
]. In SCHC, the end-node and application gateway (Figure 4
) share a common pre-provided context that indicates how to manage the information contained in the protocol headers, in order to remove them from the packet sent over the LPWAN link. Thereby, Figure 7
illustrates the original packet, and the one outputted by the SCHC module of our solution. The SCHC rule applies the compression action for all of the header fields. This is possible thanks to knowing, in this case, the IPv6 addresses, UDP ports, and other static configurations of both ends (pre-provided context). This way, the 40 Bytes of the IPv6 Header, and the 8 Bytes of the UDP header, are compressed down to 1 Byte, by including a new SCHC header called RuleID, which indicates the way to proceed with the packet once it reaches the application gateway. As can be seen, the application payload remains untouched.
A regular laptop with the Ubuntu operating system was used in the tests, and was connected with the OBD-II port of a 2003 Honda Civic 1.6 i-VTEC with petrol engine. A Bluetooth GPS was used for gathering positioning data, and an ELM327-based OBD-II device was employed for obtaining car diagnosis data. The OBD-II device was connected with the laptop using Bluetooth. A software was developed, aimed at periodically obtaining the position in NMEA format and a set of OBD parameter identifiers (PIDs), and sending application-level packets with these data to the IPv6-addressed data server, by using the LPWAN UNIX interface. The communication with our UNIX interface is a regular AF_INET6 SOCK_DGRAM
socket supporting IPv6/UDP. The data sent in the packets can be seen in Figure 7
within the application payload. From the OBD device, the engine load, RPM, and speed are used, and the latitude, longitude, and speed are taken from the GPS receiver.
In our case, we have used LoRaWAN as the communication technology, and the modem was comprised of an Arduino board provided with an RN2483 radio module by Microchip. It operates in LoRaWAN Class A mode, using the ISM 868 MHz frequency band. An ommnidirectional 2.2 dBi antenna has been attached to this device, to transmit at 14 dBm power. The other end of the LoRaWAN channel was a RisingHF RHF2S008 base-station gateway, using Semtech’s SX1301 chip. In this case, an omnidirectional antenna of 5 dBi was used.
The LoRa parameters were statically set with SF 12, CR 4/5, and BW 125 kHz; the adaptive data rate (ADR) feature of LoRaWAN was disabled for the testing activities. The rest of the configurations employed in the experimental tests are shown in Table 1
. Regarding LoRaWAN security, its functions were kept untouched, and so end-to-end AES encryption was attained [26
]. Please note that the encryption/decryption process was transparent for us, as it was automatically performed by the LoRaWAN modules in both the end-nodes and the gateway. Further, the joining procedure followed by the motes in order to gain connectivity through the gateway was the Over The Air Activation (OTAA), defined by the LoRaWAN specification.
Packets received by the gateway are forwarded to the network server, which deals with LoRaWAN MAC encapsulation and sends the SCHC packet to the application gateway. This is in charge of decompressing and reassembling fragments, with the aim of finally obtaining the original IPv6 datagram to be forwarded to the data server (Figure 4
The data server receives the UDP data messages and feeds an InfluxDB database. This server also hosts a dashboard, implemented with Grafana [32
], which takes data from the database to show all vehicle parameters in real-time. A set of plots, with their corresponding database queries, have been included in the interface to show, among others, the path followed by a vehicle, individual OBD parameters, or a mix of them, and alerts attending to pre-configured events or thresholds.
A clear view of good operation of our platform can be seen in the data collected from the vehicle, both in real time and in a historical fashion. Figure 8
includes a screen-shot of the Grafana platform hosted by the data server. An OpenStreetMap component has been used to highlight the path followed by our Honda Civic within the campus. A different color is used to indicate the stretches where the car drove at higher speeds (consider that the campus has a speed limit of 20 km/h). The screen-shot in Figure 9
shows a more general view of the capabilities of the monitoring application. Here, apart from the path followed by the car, the raw parameters received and both real-time and historical records of the OBD data are shown. In the plot on the right, the engine load, revolutions per minute, and speed are shown.
An interesting issue, detected when gathering the vehicle speed, was the difference between OBD and GPS data. Figure 10
shows the speed reported in one of the tests. It can be seen that GPS speed values are delayed, as compared with the OBD data. This is attributed to two factors: The positioning algorithm, which uses cumulative data to compute fixes, and the buffering carried out by the GPS UNIX daemon used (gpsd
), which saves the last computed position to serve requests from the OBU data gathering application.
In order to validate our proposal in a real scenario from a communications perspective, a performance evaluation of LoRaWAN was also conducted around the university campus, obtaining the results shown in Figure 11
. Concretely, the LoRaWAN-enabled OBU periodically transmitted data packets to the gateway with the aim of finding non-covered zones. The RSSI, measured by the gateway in dBm, is plotted on the campus map, indicating good operation of the system around the ring. It can be seen that lower RSSI values are obtained in the lower right corner, which represents a location at 1.4 km away from the gateway. The effect of buildings is noticeable, observing the greatest RSSI values, which are not obtained at the nearest area. This is due to a group of buildings, south-east of the gateway location. In fact, as expected, the best coverage is obtained when a direct line of sight is obtained through the buildings (blue spots). Overall, observe that the lowest RSSI level attained was
dBm, far from the gateway receiving sensitivity; around
Although it can be seen in Figure 11
that the performance level of the system is high, in terms of channel reliability (no shadow zones), the Packet Delivery Ratio (PDR) was also studied in this scenario. Thereby, with the selected LoRa configuration (SF = 12, CR = 4/5, and BW = 125 kHz), we obtained a PDR of 95%. This is an acceptable figure, which permits continuous vehicle monitoring with trustworthiness and stability. Regarding the focus of this validation study, with this deployment the institutional service vehicles can be perfectly tracked, all around the university campus. In addition, one should consider that these vehicles are usually electrically-powered; hence, they present important energetic restrictions. With the use of this LPWAN-based solution, the battery energy can be greatly saved by substituting our laptop with an embedded computer platform.
After the whole evaluation, we have checked the operation of the system and its potential to monitor vehicles using our generic LPWAN communication system. We have validated its operation, extracting OBD parameters from regular cars and GPS, showing its usefulness for such applications as fleet management or monitoring and prediction of vehicle malfunction. A low-power communication device is used as a modem and, although our on-board application is hosted by a regular laptop, our system shows an enormous potential to create embedded devices to monitor a wide range of vehicles, including power-constrained ones such as motorbikes, or even personal mobility vehicles such as bikes and scooters. This currently an on-going study, that plans to extend our work in the area [33
]. Additionally, by tuning LoRa communication parameters, it is possible to reduce the data rate in favour of extending the coverage. This could be highly beneficial when large areas must be monitored using IoT communications. In any case, our deployment shows good performance at locations 1.5 km away from the gateway with the considered configuration, which means that at least an area of 7 km
could be efficiently covered. In the same way, this tuning could be also applied to cover crowded areas, such as urban zones, with the aim of supporting more terminals at the expense of reducing the coverage area. Nevertheless, it is important to remark that LPWAN technologies can provide concurrent connectivity to many devices but with some limitations, given that they have emission restrictions determined by the unlicensed band duty cycles that prevent devices from flooding the network. In this line, additional work is necessary in order to estimate the number of vehicles that can be covered by a single LPWAN gateway without collision or interference-related issues. In order to face this challange, depending on the LPWAN technology employed, different solutions may be applied, such as employing different LoRa SF in the end-devices, time synchronization techniques such as in Narrow Band-Internet of Things (NB-IoT), and so on.
Intelligent transportation systems are experiencing a big revolution, due to the emergence of novel communication paradigms. One of these technologies gaining momentum is LPWAN, which can boost the synergy between ITS and IoT. Following this line, in this work we have presented an end-to-end monitoring platform for vehicles, based on LPWAN and following a data collection architecture, that enables the provision of a number of ITS services.
The platform presented involves a holistic solution that covers the next stages of a new-age ITS monitoring solution:
Vehicle data extraction, by means of an OBD-II interface.
Data compression, using a state-of-the-art IETF compression scheme, SCHC.
Data delivery through an LPWAN link, using an LPWAN-capable UNIX network interface implemented from scratch.
Storage of the retrieved data in a cloud data server, and presentation of information to end-users by means of a web-based dashboard.
The attained results confirm the validity of the proposal, which permits successful remote monitoring, almost in real-time, of vehicle position and other metrics such as its mechanical status. A validation test has been conducted in a real scenario, showing the full coverage of a university campus with transmission distances up to 1.5 km. Besides the real LoRaWAN architecture deployed to perform the experiments, it is also worth noting the implementation of the generic network interface for UNIX systems, which allows the seamless transmission of application-layer UDP/IPv6 packets through the LPWAN link. To the authors’ knowledge, this is the first development of a network interface that permits the direct transmission of data over an LPWAN-based technology, for a general-purpose operative system. In addition, the reliability of the communications over this constrained link has been studied as well, obtaining notable packet delivery ratios over 95% under motion conditions.
Future research lines include the study of this proposal in other environments, such as highways or dense urban areas, with a multitude of vehicles involved in the experiments. The UNIX LPWAN interface will be exploited in our active research lines in the fields of packet compression, fragmentation, and security for LPWAN.
Conceptualization, J.S., R.S.-I., and A.F.S.; Data curation, P.R.-R. and L.B.-E.; Funding acquisition, J.S., R.S.-I., and A.F.S.; Investigation, J.S., R.S.-I., P.R.-R., and L.B.-E.; Methodology, J.S. and R.S.-I.; Software, P.R.-R. and L.B.-E.; Supervision, J.S., R.S.-I., and A.F.S.; Validation, P.R.-R. and L.B.-E.; Visualization, P.R.-R. and L.B.-E.; Writing—original draft, J.S. and R.S.-I.; Writing—review & editing, J.S. and R.S.-I.
This work has been supported by the European Union under the framework of the H2020 IoTCrawler (contract 779852) and 5G-MOBIX (contract 825496); the Spanish Ministry of Economy and Competitiveness, through the PERSEIDES project (ref. TIN2017-86885-R) and the Ramón y Cajal Program (RYC-2017-23823); and the BBVA Foundation, under the 2018 Leonardo Grant for Researchers and Cultural Creators.
Conflicts of Interest
The authors declare no conflict of interest. The founding sponsors had no role in the design of the study; in the collection, analyses or interpretation of data; in the writing of the manuscript; nor in the decision to publish the results.
The following abbreviations are used in this manuscript:
|CSS||Chirp Spread Spectrum|
|DTN||Delay Tolerant Network|
|GPS||Global Positioning System|
|GSM||Global System for Mobile communications|
|ITS||Intelligent Transportation Systems|
|ICMPv6||Internet Control Message Protocol version 6|
|IoV||Internet of Vehicles|
|IoT||Internet of Things|
|IPv6||Internet Protocol version 6|
|ISM||Industrial, Scientific, and Medical|
|LPWAN||Low Power-Wide Area Network|
|LoRaWAN||Long Range Wide Area Network|
|OBD-II||On-Board Diagnostics II|
|PDR||Packet Delivery Ratio|
|RAT||Radio Access Technology|
|RSU||Road Side Unit|
|RSSI||Received Signal Strength Indicator|
|SCHC||Static Context Header Compression|
|UDP||User Datagram Protocol|
|V2V||Vehicle to Vehicle|
- Javed, F.; Afzal, M.K.; Sharif, M.; Kim, B.S. Internet of Things (IoT) Operating Systems Support, Networking Technologies, Applications, and Challenges: A Comparative Review. Commun. Surv. Tutor. 2018, 20, 2062–2100. [Google Scholar] [CrossRef]
- Ericsson. Internet of Things Forecast. 2018. Available online: https://www.ericsson.com/en/mobility-report/internet-of-things-forecast (accessed on 10 January 2019).
- Sanchez-Iborra, R.; Cano, M.D. State of the art in LP-WAN solutions for industrial IoT services. Sensors 2016, 16, 708. [Google Scholar] [CrossRef] [PubMed]
- Sanchez-Iborra, R.; Sanchez-Gomez, J.; Ballesta-Viñas, J.; Cano, M.D.; Skarmeta, A.F. Performance Evaluation of LoRa Considering Scenario Conditions. Sensors 2018, 18. [Google Scholar] [CrossRef] [PubMed]
- Petäjäjärvi, J.; Mikhaylov, K.; Pettissalo, M.; Janhunen, J.; Iinatti, J. Performance of a low-power wide-area network based on LoRa technology: Doppler robustness, scalability, and coverage. Int. J. Distrib. Sens. Netw. 2017, 13, 1–16. [Google Scholar] [CrossRef]
- Kombate, D. The Internet of Vehicles based on 5G communications. In Proceedings of the IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), Chengdu, China, 15–18 December 2016; pp. 445–448. [Google Scholar] [CrossRef]
- Kaiwartya, O.; Abdullah, A.H.; Cao, Y.; Altameem, A.; Prasad, M.; Lin, C.T.; Liu, X. Internet of Vehicles: Motivation, Layered Architecture, network model, challenges, and future aspects. IEEE Access 2016, 4, 5356–5373. [Google Scholar] [CrossRef]
- Wang, Y.; Duan, X.; Tian, D.; Lu, G.; Yu, H. Throughput and Delay Limits of 802.11p and its Influence on Highway Capacity. Proc. Soc. Behav. 2013, 96, 2096–2104. [Google Scholar] [CrossRef][Green Version]
- Katsaros, K.; Dianati, M. A Conceptual 5G Vehicular Networking Architecture. In 5G Mobile Communications; Springer International Publishing: Cham, Switzerland, 2017; pp. 595–623. [Google Scholar]
- Ge, X.; Li, Z.; Li, S. 5G Software Defined Vehicular Networks. IEEE Commun. Mag. 2017, 55, 87–93. [Google Scholar] [CrossRef][Green Version]
- Chiti, F.; Fantacci, R.; Giuli, D.; Paganelli, F.; Rigazzi, G. Communications Protocol Design for 5G Vehicular Networks. In 5G Mobile Communications; Springer International Publishing: Cham, Switzerland, 2017; pp. 625–649. [Google Scholar]
- Dong, P.; Zheng, T.; Yu, S.; Zhang, H.; Yan, X. Enhancing Vehicular Communication Using 5G-Enabled Smart Collaborative Networking. Wirel. Commun. 2017, 24, 72–79. [Google Scholar] [CrossRef]
- Sanchez-Iborra, R.; Sánchez-Gómez, J.; Santa, J.; Fernandez, P.; Skarmeta, A. Integrating LP-WAN Communications within the Vehicular Ecosystem. J. Internet Serv. Inf. Secur. 2017, 4, 45–56. [Google Scholar]
- Herrera-Tapia, J.; Hernandez-Orallo, E.; Tomas, A.; Calafate, C.; Cano, J.C.; Zennaro, M.; Manzoni, P. Evaluating the use of sub-gigahertz wireless technologies to improve message delivery in opportunistic networks. In Proceedings of the 14th IEEE International Conference on Networking, Sensing and Control (ICNSC 2017), Calabria, Italy, 16–18 May 2017. [Google Scholar]
- Agarwal, Y.; Jain, K.; Karabasoglu, O. Smart vehicle monitoring and assistance using cloud computing in vehicular Ad Hoc networks. Int. J. Transp. Sci. Technol. 2018, 7, 60–73. [Google Scholar] [CrossRef]
- Khandelwal, S.A.; Abhale, A.B. Monitoring vehicles and pollution on road using vehicular cloud environment. In Proceedings of the 2015 International Conference on Technologies for Sustainable Development (ICTSD), Mumbai, India, 4–6 February 2015; pp. 1–6. [Google Scholar]
- Zingirian, N.; Maresca, M.; Valenti, C. The Click & Find Remote Vehicle Monitoring and Control platform: Architecture, interfaces, applications. In Proceedings of the 2011 IEEE 16th Conference on Emerging Technologies & Factory Automation (ETFA2011), Toulouse, France, 5–9 September 2011; pp. 1–4. [Google Scholar]
- Chakole, S.S.; Kapur, V.R.; Suryawanshi, Y.A. ARM Hardware Plaform for Vehicular Monitoring and Tracking. In Proceedings of the 2013 International Conference on Communication Systems and Network Technologies, Gwalior, India, 6–8 April 2013; pp. 757–761. [Google Scholar]
- Tian, S.; Shi, S.; Gu, X. Framework design of monitoring system for traffic based on embedded and RFID technology. In Proceedings of the 2015 International Wireless Communications and Mobile Computing Conference (IWCMC), Dubrovnik, Croatia, 24–28 August 2015; pp. 975–980. [Google Scholar]
- Mori, K.; Shagdar, O.; Matsuura, S.; Tsukada, M.; Ernst, T.; Fujikawa, K. Experimental Study on Channel Congestion using IEEE 802.11p Communication System. In Proceedings of the 2013 IPSJ Technical Workshop on Mobile Computing and Ubiquitous Communications, Kyoto, Japan, 22–26 July 2013. [Google Scholar]
- Abboud, K.; Omar, H.A.; Zhuang, W. Interworking of DSRC and Cellular Network Technologies for V2X Communications: A Survey. IEEE Trans. Veh. Technol. 2016, 65, 9457–9470. [Google Scholar] [CrossRef]
- Tseng, Y.L. LTE-Advanced enhancement for vehicular communication. Wirel. Commun. 2015, 22, 4–7. [Google Scholar] [CrossRef]
- Sigfox Coverage. 2018. Available online: https://www.sigfox.com/en/coverage (accessed on 10 January 2019).
- Barrachina-Muñoz, S.; Bellalta, B.; Adame, T.; Bel, A. Multi-hop communication in the uplink for LPWANs. Comput. Netw. 2017, 123, 153–168. [Google Scholar] [CrossRef][Green Version]
- Adame, T.; Barrachina, S.; Bellalta, B.; Bel, A. HARE: Supporting efficient uplink multi-hop communications in self-organizing LPWANs. Sensors 2018, 18, 115. [Google Scholar]
- Sornin, N.; Luis, M.; Eirich, T.; Kramp, T.; Hersent, O. LoRaWAN Specification v1.0.2; Technical Report; LoRa Alliance: Fremont, CA, USA, 2016. [Google Scholar]
- Adelantado, F.; Vilajosana, X.; Tuset-Peiro, P.; Martinez, B.; Melia-Segui, J.; Watteyne, T. Understanding the limits of LoRaWAN. IEEE Commun. Mag. 2017, 55, 34–40. [Google Scholar] [CrossRef]
- Minaburo, A.; Toutain, L.; Gomez, C.; Barthel, D. LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP. 2018. Available online: https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-18 (accessed on 10 January 2019).
- Sanchez-Iborra, R.; Sánchez-Gómez, J.; Santa, J.; Fernández, P.J.; Skarmeta, A.F. IPv6 communications over LoRa for future IoV services. In Proceedings of the 2018 IEEE 4th World Forum on Internet of Things (WF-IoT), Singapore, 5–8 February 2018; pp. 92–97. [Google Scholar]
- Van den Abeele, F.; Haxhibeqiri, J.; Moerman, I.; Hoebeke, J. Scalability Analysis of Large-Scale LoRaWAN Networks in ns-3. IEEE Internet Things J. 2017, 4, 2186–2198. [Google Scholar] [CrossRef][Green Version]
- Sanchez-Iborra, R.; Sanchez-Gomez, J.; Skarmeta, A. Evolving IoT networks by the confluence of MEC and LP-WAN paradigms. Future Gener. Comput. Syst. 2018, 88, 199–208. [Google Scholar] [CrossRef]
- Grafana. 2018. Available online: https://grafana.com/ (accessed on 10 January 2019).
- Santa, J.; Fernandez, P.J. Seamless IPv6 connectivity for two-wheelers. Pervasive Mob. Comput. 2017, 42, 526–541. [Google Scholar] [CrossRef]
Concept of the proposal for monitoring vehicles using LPWAN.
Concept of the proposal for monitoring vehicles using LPWAN.
LoRaWAN network architecture.
LoRaWAN network architecture.
Overall system architecture.
Overall system architecture.
Design of the network interface solution for LPWAN.
Design of the network interface solution for LPWAN.
SCHC compression of data packets sent by vehicles.
SCHC compression of data packets sent by vehicles.
Visualization of the path followed by the vehicle in the Grafana dashboard.
Visualization of the path followed by the vehicle in the Grafana dashboard.
Main view of the Grafana dashboard.
Main view of the Grafana dashboard.
OBD and GPS speed.
OBD and GPS speed.
Study of the LoRaWAN signal strength.
Study of the LoRaWAN signal strength.
|Transmission power||14 dBm|
|Spreading Factor (SF)||12|
|Coding Rate (CR)||4/5|
|Bandwidth (BW)||125 kHz|
|Packet length||14 Bytes|
|Packet rate||0.33 packets per second|
|Adaptive Data Rate (ADR)||No|
© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).