1 Introduction

Over the last decades, an ever-increasing rise in the number of vehicles, especially in metropolitan areas, has created multiple problems including traffic congestion, massive fuel consumption, high rates of accidents, and pollution. It is anticipated that by 2030 there will be around 2 billion cars on the roads in the world [1] which can affect daily life quality in urban areas negatively. The concept of Intelligent Transportation Systems (ITS) has been introduced to enhance the traffic efficiency and reduce the negative impacts of heavy traffic to people life. Despite the significant potential of these systems and their applications, still there are very few large scale deployment of ITS around the world. The huge cost associated with providing the infrastructure to transmit and collect the data on the roads from each point (cars, streets, lights, etc.) to a local or central locations is one of the major barriers.

However, recent advances in wireless technologies along with the emerging Internet of Things (IoT), opened up a new form of low-cost and wide-range communication which can reduce the challenges of immediate implementation of the ITS application. By integration with IoT, the ITS can apply advanced technologies in the processing, storing, and wireless communication to create the Internet of Vehicles (IoV) and Road Side Elements (IoRSE) [2, 3]. This allows the vehicles and the infrastructures to communicate effectively to collect the traffic data and improve the traffic conditions [4, 5].

On the other hand, increasing the volume, variety, and the speed of the generated data by IoT devices, causes several new challenges to collect, transfer, store, analysis, and make decisions based on the data in real world applications. For ITS applications, due to the huge amount of generated data by sensors installed on the vehicles or Road Side Units (RSUs), transferring them to cloud servers could lead to unnecessary communication overhead, high bandwidth consume, and higher response delay in sensitive traffic information [2, 6]. Recently, to address these challenges and reduce central computing power with less required data being transferred to the central location, various computing technologies have been introduced. These technologies are employed to solve services of processing, storing, and communication for the IoV such as: Cloud computing [7], cloudlets [8], edge computing [9], Mobile Edge Computing (MEC) [10], and fog computing.

During recent years, fog computing was introduced [11, 12] to spread the cloud processing to the network edge to provide computation, networking, and storage capabilities between vehicles and data centers. Fog devices locally process the collected traffic data and present real-time services such as efficient routing of vehicles, improving of the traffic conditions, and safety related applications. In the fog-based environment, the cloud sever is only required to process and store historical data. The fog-processing can improve the performance of these services significantly by eliminating the required huge data transferring and processing in cloud [13,14,15].

Considering the above-mentioned issues, in this paper a novel architecture for ITS applications has been proposed which employs the Low-Power Wide-Area Network (LPWAN) and fog-based communication and computing structure. This architecture examines the possibility of using cellular-based LPWAN communications, LTE-M, and Narrow band Internet of Things (NB-IoT) for ITS applications. Moreover, the performance in the realistic simulation environment is evaluated and compared. The main contributions of this paper could be summarized as:

  • A novel hybrid LPWAN-based backhaul architecture has been proposed.

  • ITS applications have been selected (traffic monitoring and emergency vehicle preemption) and a large-scale realistic simulation environment has been implemented.

  • The simulation environment consists of the Simulation of Urban MObility (SUMO) and a novel Python-based program for communication network performance evaluation with ability to exchange live data with SUMO.

  • The large-scale simulation results demonstrate the feasibility of using LPWAN for providing backhaul infrastructure for ITS application.

The rest of the paper is structured as follows: Sect. 2 presents related works. Section 3 provides on overview of LPWAN cellular based communication technology, LTE-M and NB-IoT. Section 4 describes our system design, and Sect. 5 presents the results and discussion. We conclude the paper in the Sect. 6.

2 Related work

There are a few studies that employed LPWAN in the ITS environments. The authors in [16] proposed an architecture based on WSN and LTE-M for gathering the data of air pollution in the ITS environment where they deployed LTE-M in the outdoor units and public vehicles such as buses, and they used the Zigbee sensors in the the buses’ stations. When a bus stops at the stations, LTE-Ms collect data from Zigbess and send them to the cloud computers to be analyzed.

The authors in [17] used LTE-M technology to design urban rail transit systems and elaborated the advantages and disadvantages of this technology in such systems. Also, the work in [18] employed LTE-M technology accompanied in leaky coaxial cable as the main communication solution for future urban train systems. In other work [19] assessed the performance of LTE-M for Machine-to-Machine (M2M) communication. In [20] authors studied LPWAN technology in V2X communication and employed Long Range (LoRa) and LTE-M which are LPWAN based technology in V2X communication. The simulation result show LPWAN in V2I environment works better then V2V environment.

Shi et al. [21] used NB-IoT technology in smart parking systems for long battery lifetime, low deployment costs, and wide range. The work in [22] evaluated an opportunistic crowd-sensing scenario in which sensors transfer a huge amount of traffic data using NB-IoT. The work in [23] studied the performance of LTE, LTE-M, NB-IoT, and 5G to recognize gaps of LTE requirements and accessible performance to eschew analogous disagreements when 5G is deployed. In [24], to enable a direct V2V and V2X communication, the authors proposed a new architecture with LoRa wireless technology for V2X communications with a D2D based approach for improving the latency.

There are several limitations and disadvantages in the mentioned works. For example, using LoRa is not suitable for big data transferring where the payloads sizes are usually limited to 100 bytes. In the Table 1, we have summarized the focuses in some of the recent studies on LPWAN-based V2X architectures and their limitations.

Table 1 Research focus and limitations of State of the Art LPWAN V2X architectures
Full size table

3 Cellular-based LPWAN communication

With advances in the wireless communication systems, vehicles and infrastructures will be equipped with short-range radio technologies such as Dedicated Short-Range Communication (DSRC) and long-range radio technology such as LTE. In terms of cost, the LTE is more expensive due to high power consumption, high deployment costs and complex protocols. On the other hand, the DSRC technology is limited in the range communication. The IoT technology can be a complementary solutions where they can be deployed in the vehicles, traffic lights and other elements of road side. These devices and technology need to be simple, reliable, and accessible everywhere at any time. One of the wireless communication solutions is LPWAN which is designed to have a long battery life and a wide area coverage. LPWAN includes cellular (licensed band) and non-cellular (unlicensed) approaches [25,26,27]. NB-IoT and LTE-M are both LPWAN cellular-based communication technologies which are designed to reduce the device cost, increase the cell capacity, lessen the power, and widen the range to transmit/receive small amounts of data using lower bandwidth [28,29,30] and [31].

Increased requirements to improve power consumption and signal coverage, vehicles, traffic lights and other elements of roadside like RSU, Base Stations (BSs), that collecting real-time data related to traffic and air pollution, can be equipped with LPWAN. The LPWAN can be one of the promising approach in next-generation communications of the ITS. The low power consumption, low-cost hardware, and long-range communication are the major requirements for emerging ITS solutions.

The LTE-M is known as eMTC (enhanced Machine-Type Communication) created by 3GPP for IoT applications in long-range communications. This technology can improve the functions of roadside devices in terms of delay, and battery lifetime. The low power consumption of LTE-M enhances the battery up to 10 years. The bandwidth of LTE-M devices is 1.08MHz, which is equal to 6 LTE Physical Resource Blocks (PRBs). The cost of LTE-M systems is less than 2G/3G/4G technologies due to the reduced complexity of IoT road side elements. LTE-M can be used everywhere that LTE is used because, that is a transfiguration of LTE [19, 32, 33].

There are two types of Coverage Enhancement (CE) in the LTE-M architecture called Modes A and B. In each CE Modes, various repetition techniques for data channels and control channels are used. CE Mode A is the default mode of LTE-M devices and networks and are used when moderate CE and high data rates are needed such as voice call possibility and connected mode mobility.

CE Mode B is optional and can even further enhance the coverage at the expense of throughput and delay, and it was mainly designed to provide deep coverage within buildings. Hence, Mode B is intended more for stationary or pedestrian speeds applications that require limited data rates and less data per month. The maximum coverage Mode B provides is highly configurable (from 192 to 2048 repeats).

NB-IoT is another cellular-based low power wide area protocol, and similar to LTE-M, the NB-IoT focuses on higher coverage, less energy consumption, and lower cost. However, the bandwidth of NB-IoT devices is 180 kHz (one PRB of LTE) [22, 34]. The geographical coverage in NB-IoT is higher than LTE-M. Table 2 describes difference between LTE-M and NB-IoT.

Table 2 Difference between LTE-M and NB-IoT
Full size table

4 Methodology

In this work, we proposed a novel hybrid architecture, ITS- Fog-based communication and computing, which uses the LPWAN cellular-based communication technology (NB-IoT and LTE-M) with target to reduce cost, higher cell capacity, and wide area coverage to transmit/receive small amounts of data using lower bandwidth. We evaluated the performance of using LTE-M and NB-IoT for providing backhaul communication infrastructure in a realistic simulation environment and compared for two applications with low and high delay requirements: road traffic monitoring and emergency vehicle management and preemption in terms of end-to-end latency per user.

To achieve these goals, first we provided the proposed system architecture alongside with mathematical modeling for the Data Transmission Latency (DTL) from vehicle to the Traffic Lights (TLs) and from there to the cloud. In addition, we developed a realistic traffic simulation environment using SUMO simulator and a Python-based program with the ability to communication performance evaluations. Furthermore, we calculated and compared the DTL for both LTE-M and NB-IoT and the simulation results illustrated the feasibility of using LPWAN for ITS backhaul infrastructure where it was in favor of the LTE-M over NB-IoT.

4.1 System design and architecture

Figure 1 illustrates the proposed system architecture which includes vehicles, TLs, RSUs, and Cellular BS or evolved Node B (eNodeB). Following section provides information and assumptions about each element.

  • TLs referred to a fixed element installed in intersections with connectivity capability and it controls in/out flow of vehicles in intersection with changing traffic signals [35, 36]. We assumed TLs are edge-node and able to process small amount of data with low complexity.

  • Road Side Unit RSU is a fixed element that is located in a different geographic location with the (x, y) coordinates on the road. RSUs have IEEE 802.11p/DSRC communication device to communicate with On-Board Units (OBUs) installed on vehicles and LPWAN communication devices to communicate with TLSs and LPWAN base station. In proposed architecture, RSUs are equipped with basic processing, storing and communication functionality acting as a fog node.

  • LPWAN BS The BS (e.g. eNodeB) installed on road similar to RSUs in a geographic location with the (x, y) coordinates. BSs have a much broader communication range compared to DSRC.

  • Vehicles The vehicle is a dynamic node that is equipped with OBU, computing and networking resource. An OBU is a transceiver which can be mounted on a vehicle. Vehicles know their position using GPS and can communicate with other vehicles (Vehicle-to-Vehicle communication), TLs and RSUs (Vehicle-to-Infrastructure communication).

Fig. 1
figure 1

Proposed system architecture

Full size image

Sensors installed on vehicles generate huge amounts of data and if we transfer the generated data to RSU or cloud using DSRC/LTE, it can cause a very long delay. Also, huge backhaul coverage and connectivity is required which accompanies with high installation and ongoing costs. Thus, in the proposed architecture, we divided the whole city map into several sub-road networks, called areas, and installed one RSU with processing capability in each area. We presented each RSU as a fog nodes that can pre-process traffic data or temporally store reiterative information. In addition, we placed several TLs equipped with the LTE-M/NB-IoT module in each area and we consider them as edge nodes in the network.

Moreover, in our architecture, we proposed installation of LPWAN base stations that covered several areas and while it equipped with LTE-M/NB-IoT modules, it was able to communicate with LTE network. The communication range of LPWAN BS can be denoted as the \(R_{c}\), which can cover several areas with multiple RSU connectivity.

The RSU has higher capabilities compare to TL and can offer services such as helping the vehicles with navigation, processing large traffic data, broadcasting real-time information, etc. On the other hand, TL can process traffic data in its own intersection in order to reduce transformation of data to LPWAN BS. Each intersection can be linked to several roads (\(R_i\) as input roads, \(R_o\) output roads, and each road having minimum one lane \(L_r\)).

We used LPWAN for communication between RSUs and TLs that has much lower cost and lower complexity compared to DSRC. Therefore, the processed data by TL is sent to RSU at a lower volume and small size with the same LTE-M/NB-IoT module. To assign TL to RSU, we calculated the shortest direct distance using Euclidean formula [37] with collecting the x, y coordinates from SUMO traffic simulator. This distance defined as the direct path where the signal travel from the transmitter (TL) to receiver (RSU) and can be calculated as:

$$\begin{aligned} D = \sqrt{({\hbox {TL}}_x - {\hbox {RSU}}_x)^2 + ({\hbox {TL}}_y - {\hbox {RSU}}_y)^2} \end{aligned}$$

In addition to real-time data, we proposed that they should be several types fixed and historical data those can be stored on the cloud servers. The historical data are those sent to the cloud (core network) by LPWAN BS, and the fixed data such as the speed and capacity of roads are determined by transportation engineers and can be updated in certain interval.

In summary, in the proposed architecture, consist of vehicles those are generating various data (location, speed, etc.) and transferring them to their nearest TL using DSRC communication protocol. Then, the TLs calculates the congestion at the intersection using the collected data from vehicles and it sends the output of the calculated and processed congestion information to the RSU over LPWAN (LTE-M or NB-IoT communications) where RSU may perform different functionalities such as: processing the traffic status of area, proposing new routes to vehicles in the area, emergency vehicle preemption, broadcasting road information, etc. This architecture can support early implementation of various ITS applications in near future by providing cost effective communication, processing, and backhaul connectivity.

In the next section, we performed the modeling for the architecture with focus on end-to-end latency.

4.2 Modeling

In this section, we explain the latency from vehicles to the Traffic Management Center (TMC (remote servers)) on our scenarios.

4.2.1 Data transmission latency (DTL)

Figure 2 shows a diagram of end to end latency from vehicle to cloud in an ITS scenario. The expected total DTL from a vehicle to TL, the TL to RSU, and from RSU to cloud can be expressed by

$$\begin{aligned} \begin{aligned} DTL(t)&= \alpha . {PD^{V}(t)} + \beta . \left( { PD^{TL}(t) }+{ TD^{V2TL}(t) } \right. \\&\quad \left. + { PgD^{V2TL}(t) }\right) + \zeta . \left( { PD^{TL2RSU}(t) }\right. \\&\quad \left. +{ TD^{TL2RSU}(t) } + { PgD^{TL2RSU}(t) }\right) \\&\quad + \theta . \left( { PD^{RSU2Cloud}(t) } +{ TD^{RSU2Cloud}(t) } \right. \\&\quad \left. + { PgD^{RSU2Cloud}(t) }\right) \end{aligned} \end{aligned}$$
(1)

where \(\alpha\), \(\beta\) and \(\zeta\) defined as binary variables assigned for existence of the each communication delay i.e. DSRC, LTE-M, and cloud and \(\alpha + \beta + \zeta + \theta = 1\). Also, \(PD^{V}(t)\) defined as the processing delay happens at the vehicle v, where \(PD^{TL}(t)\), \(PD^{RSU} (t)\) and \(PD^{RSU2Cloud}(t)\) denotes the delay for processing in the TL, RSU and cloud respectively.

Fig. 2
figure 2

End-to-End latency from vehicle to cloud

Full size image

\(TD^{V2TL}(t)\), \(TD^{TL2RSU}(t)\) and \(TD^{RSU2Cloud}(t)\) are data transmission delay from a vehicle v to the TL with DSRC communication technology, from the TL to RSU with LTE-M/NB-IoT, and from the RSU to cloud with LTE respectively. \(PgD^{V2TL}(t)\), \(PgD^{TL2RSU}(t)\) and \(PgD^{RSU2Cloud}(t)\) denote propagation delay from the vehicle v to the TL with DSRC communication technology, from the TL to RSU with LTE-M/NB-IoT, and from the RSU to cloud with LTE respectively.

\(TD^{TL2RSU}(t)\) consists of the reception of downlink control information (DCI), transmission of data, and transmission or reception of the acknowledgment. We formulate the data transmission delay in the downlink (DL) and the uplink (UL) transmission as follows [37]:

$$\begin{aligned} TD^{TL2RSU}_{DL}(t)&= \left( PDCCH_{dur} + t_D + PDSCH_{dur} + t_{DUS} \right. \\&\quad \left. +ULACK_{dur} * \left\lceil \frac{DataLen}{TBS(MCS;RBU)}\right\rceil \right) \end{aligned}$$
(2)
$$\begin{aligned} TD^{TL2RSU}_{UL}(t)&=\left( PDCCH_{ dur} + t_{DUS} + PUSCH_{ dur} + t_{UDS} \right. \\&\quad \left. + DLACK_{ dur} * \left\lceil \frac{DataLen}{TBS(MCS;RBU)} \right\rceil \right) \end{aligned}$$
(3)

Communication latency in LTE-M/NB-IoT depends on the Transport Block Size (TBS) and the number of repetitions, \(N_R\). In Eq. (2) and Eq. (3), \(\frac{DataLen}{TBS(MCS;RBU)}\) is the total number of transport blocks needed to transmit the TL’s data to RSU. TBS is the transport block size that depends on MCS and the allocated RB per user (RBU) and the size of data per user denoted as DataLen. The transmission latency per transport block depends on Physical Uplink Shared Channel (PUSCH), Physical Downlink Control Channel (PDCCH) duration, and Physical Downlink Shared Channel (PDSCH) [37], where the PDCCH duration is \(N_R * TT_{CF}\). Here TT is the transmission time needed to transmit the control information and PDSCH, and PUSCH duration are equal to \(N_R * TT_{TBS}\). \(TT_{TBS}\) is the transmission time needed to transmit one transport block on PDSCH and PUSCH, respectively.

DLACK and ULACK are downlink acknowledgement and uplink acknowledgement respectively. The values of number of repetitions depend on maximum coupling loss (MCL). In addition, the \(t_D\) is the cross sub-frame delay, \(t_{DUS}\) and \(t_{UDS}\) are the radio frequency (RF) tuning delay for switching from DL to UL and UL to DL channels, respectively. For simplicity, we assume that there are no repetitions in DCI and \(N_R\) = 0 and the \(t_{UDS}\) and \(DLACK_{Dur}\) are set to zero. Therefore, we can rewrite Eqs. (2) and (3) as follow (similar to work reported in [37]):

$$\begin{aligned} TD^{TL2RSU}_{DL}(t)= & {} \left( t_D + PDSCH_{Dur} + * \left\lceil \frac{DataLen}{TBS(MCS;RBU)}\right\rceil \right) \end{aligned}$$
(4)
$$\begin{aligned} TD^{TL2RSU}_{UL}(t)= & {} \left( t_{DUS} + PUSCH_{Dur} * \left\lceil \frac{DataLen}{TBS(MCS;RBU)} \right\rceil \right) \end{aligned}$$
(5)

The total latency in LTE-M / NB-IoT is

$$\begin{aligned} TD^{TL2RSU}(t) = TD^{TL2RSU}_{UL}(t) + TD^{TL2RSU}_{DL}(t) \end{aligned}$$
(6)

For simplicity, we considered \(\alpha = 0\), \(\beta = 0\), \(\zeta = 1\) and \(\theta = 0\). Consequently, the delay for one RSU area \(RSU_r\) can be expressed by

$$\begin{aligned} DTL^{RSU_r} = \sum _{TL^i_{n=1}}^{TL^i_N} TD^{TL2RSU}(t) \end{aligned}$$
(7)

The latency in the road network can be expressed by

$$\begin{aligned} D^{Net}_{Total} = DTL^{RSU_1} + DTL^{RSU_2} + ... + DTL^{RSU_R} = \sum _{r=1}^{R} DTL^{RSU_r} \end{aligned}$$
(8)

5 Results and discussion

In this paper, a novel architecture for backhaul communication for ITS application based on LPWAN has been proposed. In previous section, we defined the architecture and demonstrated a mathematical modeling for latency as one of the important aspects of the backhaul communication. In this section, we will evaluate the latency performance of the architecture in two realistic ITS applications. We used network simulator to implement the proposed architecture and we generated realistic traffic and movement environment by employing traffic simulator. Next section provides details about the simulation setup.

5.1 Simulation setup

In order to evaluate the performance of proposed architecture, we used the realistic maps of New York city and Toronto with the characteristics summarized in Table 3.

Table 3 Characteristic of the maps
Full size table

We performed the simulations using microscopic traffic simulator, SUMO [38] and its built-in client/server architecture, Traffic Control Interface (TraCI). In the traffic simulation, the TraCI acts as communication medium between SUMO and any external software, where SUMO generates a realistic traffic environments and the external software acts as the client with the capability of impacting the simulation, movements and speed of the cars, etc. [39].

In this paper, a novel Python-based program was developed to simulate the wireless network environment which was able to interact with SUMO. In our program, the traffic and movement of the cars was generated in SUMO, and the wireless network and characteristics was prepared externally with the Python program. We also employed open source PyLTE library [40] to emulate the LTE network with User Equipment (UE) and Base Station (BS). In our developed program, the vehicles are defined as UE and are able to communicate with TLs and RSUs, and the TLs have wireless connectivity with RSUs and LTE base station.

To define RSUs in SUMO, we employed the method used in [3] where the dimensions of simulated area was extracted from the map, then RSUs was added with the Python program with a unique ID and coordinates of (x, y). Around each RSU, we drew a virtual radius within the map and the size equal to 1000m and we assumed the RSUs are equipped with LTE-M or NB-IoT device, where we implemented the LTE-M and NB-IoT connectivity by employing and improving the PyLTE.

For the performance evaluations, we implemented two realistic ITS applications those are the traffic monitoring scenarios, and emergency vehicle preemption. In each scenario, we divided the map of New York city and Toronto to seven areas, and we added an RSU in each one, where the area also included several TLs as summarized in the Table 4.

Table 4 The number of TLs in each RSU’s area
Full size table

5.2 Traffic monitoring

In the first scenario, we simulated the environment where all vehicles are broadcasting the speed, direction, acceleration, location, and vehicles’ ID, and the TL can get the these data for the vehicles on its own intersection. In the simulation, considering these information, the TLs performed a basic analysis and compute (count) the number of the vehicles on each street to recognize the possible congestion at the intersection. After pre-processing the traffic data, it sent the outcomes and the traffic information for the particular intersection to the RSU using LTE-M or NB-IoT module.

Using the described simulation tools, we developed a program that runs a realistic simulation which generated the traffic information of vehicles traveling on the map of New York city and Toronto. Then, each vehicle broadcasted data to TLs, and the TLs send the data to RSUs using the LTE-M or NB-IoT. A sample snapshot of realistic maps of city of New York city and Toronto presented in Fig. 3.

figure a
Fig. 3
figure 3

A sample snapshot of the realistic maps used in the simulations

Full size image

We summarized the steps of simulation in the Algorithm 1. During the simulation, in each 600s, we listed the vehicles those are on the road network and retrieved the position of vehicles. Then we inserted the vehicles as UE with indicators of x,y,and id to the network simulator where the vehicles are connected to the nearest TL and we calculated the number of vehicles in the area of the TL, in addition to the number of vehicles that the TL will have in every 600s \(N_{user}\). We also calculated the delays of each area in lines 16 and 17.

Using 1000 vehicles in the city of New York, and 2000 vehicles in map of Toronto, two simulations was performed using LTE-M and NB-IoT as the option for the backhaul connectivity. Also, the total end-to-end latency was calculated and summarized in Figs. 4 and 5 for the RSUs, where each TL calculated the congestion and sent the results as a message to RSU. As can be seen in these figures, the LTE-M outperformed the NB-IoT in all the RSUs. As an example, in RSU 4, end-to-end uplink latency of the LTE-M is less than end-to-end uplink latency of the NB-IoT in both New York and Toronto simulations.

Fig. 4
figure 4

Average end to end latency per user in traffic monitoring scenario (Newyork)

Full size image

In addition to the latency, we investigated one of the most important parameters in the cellular communication which is the Block Error Rate (BLER). BLER is referred to the ratio of the number of erroneous blocks to the total number of blocks transmitted over the wireless channel. To evaluate BLER, we performed a series of simulations in the NB-IoT NPUSCH BLER versus various Signal to Noise Ratios (SNRs). We used the MATLAB LTE Toolbox in addition to our simulation and we illustrated the results in Fig. 6 for SNR {-20, -18, -15, -12.5, -10, -6.4, -3.5, 0.7, 2}, and the length of 5 UL-SCH transport blocks in different repetitions {2, 16, 64}.

Fig. 5
figure 5

Average end to end latency per user in traffic monitoring scenario (Toronto)

Full size image

5.3 Emergency vehicle preemption

We also performed another simulation to understand the possibility of using the LPWAN for backhaul in safety critical applications which is emergency vehicle preemption and evaluated its performance. As can be seen in Fig. 7, in this scenario, we assumed that an emergency vehicle needs to travel from point A to point B which includes several intersection and TLs. We also assumed that the vehicle can broadcast its information (location, speed, the route it is going to take, ID, etc.) to the first TL in its path.

Fig. 6
figure 6

NB-IoT NPUSCH BLER Vs. SNR

Full size image

We proposed that using the received information, the first TL not only changes its signal to green for the emergency vehicle, it also sends the received information to neighbouring TLs where they can take similar actions to change their status to green for emergency vehicle and they provide a “green wave” for it.

Fig. 7
figure 7

Emergency vehicle scenario

Full size image

We developed a program that can simulate the proposed scenario in realistic environment. We used the same structure of simulation explained in the previous section and used the map of New York city. We summarized the implementation procedure in algorithm 2. We defined the lines 1–3 similar to the algorithm 1 for traffic monitoring. In the line 16, we defined the connectivity between emergency vehicle and the nearest TL, and then in line 17, we calculated the latency from the transmitted signal at the emergency vehicle to the received signal at the TL. Similarly, in the line 18, we calculated the latency from the mentioned TL to its neighboring TLs (line 19).

figure b
Table 5 Emergency vehicle scenario in New york city and Toronto
Full size table
Table 6 Total road network end to end delay in New york city and Toronto
Full size table

Similar simulation scenarios with 1000 vehicles in the city of New York was performed where an additional 50 emergency vehicles was added with a route of 5 km and 6 TLs to the simulations. Then, the average communication latency was calculated for these 50 vehicles both in LTE-M and NB-IoT ajd the results was summarized in Table 5. We also calculated the end-to-end delay between TLs on the UL in comparison with NB-IoT and the results is illustrated in Table 6. In this scenario, each TL changes the signal to green, then sends a message to its neighbour TL to provide the green wave. Despite the fact that the LTE-M performed better in terms of delay compared with NB-IoT, the average delay in TLs communications might not be perfect for emergency vehicle preemption applications. The proposed architecture could provide basic functionality for emergency vehicles management to help with first step ITS applications. However, it can be replaced with other technologies in the future.

6 Conclusion

In this work, a new backhaul architecture for ITS applications using the LPWAN technology was proposed which it can help with early implementation of the ITS applications in real world cases in near future. To do so, we studied the LTE-M and NB-IoT as a viable cellular-based LPWAN communication technologies. The performance of LTE-M and NB-IoT for ITS in two scenarios was evaluated for traffic monitoring, and emergency vehicle preemption and end to end delay was evaluated. In the simulations, we used the realistic map of city of New York and Toronto where we divided them into several areas with the possibility of vehicles sending their location, speed, and other data to the traffic lights. Then, in the proposed scenarios, the traffic lights computed the congestion of their own intersection and sent the results to RSU. Therefore, the size of the required data being transferred to RSU has been reduced. The results of the simulation demonstrated that LTE-M performs better compared with NB-IoT in terms of latency. These technologies can help to solve the big data challenge in ITS and provide early implementation in real world scenarios.