The Investigation of Queuing Models to Calculate Journey Times to Develop an Intelligent Transport System for Smart Cities ^†

Abstract

Intelligent transport systems are a major component of smart cities because their deployment should result in reduced journey times, less traffic congestion and a significant reduction in road deaths, which will greatly improve the quality of life of their citizens. New technologies such as vehicular networks allow more information be available in realtime, and this information can be used with new analytical models to obtain more accurate estimates of journey times. This would be extremely useful to drivers and will also enable transport authorities to optimise the transport network. This paper addresses these issues using a model-based approach to provide a new way of estimating the delay along specified routes. A journey is defined as the traversal of several road links and junctions from source to destination. The delay at the junctions is analysed using the zero-server Markov chain technique. This is then combined with the Jackson network to analyse the delay across multiple junctions. The delay at road links is analysed using an M/M/K/K model. The results were validated using two simulators: SUMO and VISSIM. A real scenario is also examined to determine the best route. The preliminary results of this model-based analysis look promising but more work is needed to make it useful for wide-scale deployment.

1. Introduction

There is now a growing interest in the development of smart cities [1]. These cities will provide ubiquitous communication, intelligent transport systems (ITS), advanced digital health platforms and urban and infrastructure management. ITS will be brought about by the fusion of communication and transport infrastructures to create city-wide vehicular networks that form digital ring roads around the city and will be realised through the deployment of satellite navigation systems, vehicular networking and connected and autonomous vehicles. This should result in less congestion, shorter journey times and a significantly reduced number of road deaths. The emergence of vehicular ad hoc networks (VANETs) that are deployed using roadside units (RSUs) along the road infrastructure and onboard units (OBUs) in vehicles represents another significant change. Information about vehicles, including their location, speed and state, as well as the source and destination of their journeys, is provided in real-time, allowing new traffic management algorithms to be developed [2]. Such detailed information combined with analytical models will allow more accurate estimates of journey times [3,4]. These systems will support current networking technologies including 5G and ITS-G5 and future technologies such as IEEE 802.11bd and 6G. A VANET network is shown in Figure 1.

Though we now have several experimental vehicular testbeds [6], in order to build an efficient ITS, it is necessary to develop better traffic management algorithms that will lead to reduced journey times and less traffic congestion. Thus, new techniques are required to analyse journey times in detail. This is the focus of this paper. In the solution approach, a journey is defined as the traversal of junctions and links. A technique called the zero-server Markov chain (ZSMC) is used to analyse delays at a junction. This is then combined with the Jackson network technique to analyse the delays at multiple junctions. The delay along road links is analysed using an M/M/K/K model. The results while traversing three junctions were compared with SUMO and VISSIM for the same scenario and showed an excellent comparison. Using this approach, Dijkstra’s algorithm was then used to analyse the different routes between a source and a destination to determine the best route [7].

In this paper, a junction is an intersection with four entrances and exits, as shown in Figure 2. Traffic lights are stationed at each entrance lane to the junction. This paper concentrates on a three-junction scenario.

The scenario being considered is on a weekday in the Thurmaston region of the city of Leicester in the U.K. The setup is shown in Figure 3. There are three junctions and each junction has four exits. The distance between Junction 1 and Junction 2 (Link 1) is 2000 m, while the distance between Junction 2 and Junction 3 (Link 2) is 2500 m.

The contributions of this paper can be summarised below:

• A technique called the zero-server Markov chain (ZSMC) is used to analyse delays at the junction.
• A new concept called lost service is introduced.
• An M/M/K/K model is used to analyse delays along the links.
• An analysis showing how the delay for a route containing three junctions and two links is demonstrated.
• The results are validated using two simulators: SUMO and VISSIM.
• An analysis of a real scenario is performed using Dijkstra’s algorithm and the new techniques.

The rest of the paper is organized as follows: In Section 2, an overview of related work is detailed, while Section 3 explains the zero-server Markov chain technique. Section 4 examines the solution approach and highlights the analysis of delays at junctions. Section 5 develops the Markov chain to analyse the delay along road links, while in Section 6, an analysis of three junctions is presented. In Section 7, SUMO and VISSIM are used to evaluate the analysis, and Section 8 examines a real-life journey to determine the shortest route. Section 9 discusses the benefits and limitations of this work. The paper concludes in Section 10.

2. Related Work

2.1. Current Transportation Management System

Transport in urban areas is largely managed by placing sensors and actuators in the road infrastructure. For example, the split cycle offset optimisation technique (SCOOT) [8] is a real-time adaptive traffic control system for coordinating and controlling traffic signals across an urban road network. Recently, these systems have been augmented with video and cheaper display technology. The emergence of automatic number plate recognition (ANPR) systems with induction loops allowed good estimations of journey times to be made because of the widespread use of ANPR systems along major highways such the M25 in London [9]. With the widespread deployment of the global positioning system (GPS), floating car data (FCD), which records the location and mobility of vehicles, are now used by Google and TomTom systems to warn drivers about possible congestion on their routes [10,11]. Current transport models are highly dependent on historical data from road systems combined with the use of Bayesian network techniques to calculate delays along roads and at traffic lights [12]. These systems can be described as knowledge-based models as they are dependent on large datasets [13]. Model-based systems depend more on analytical models and are useful where historical data are non-existent, such as on new roads and highways for smart cities or in remote country areas where there is a lack of historical data. This paper uses a model-based approach.

2.2. Google Maps

Google Maps [11] is a popular web-based mapping and navigational service that provides estimates of journey times. Google does not publish any formal numbers on the performance of Google Maps, so we need to examine the work of others. In [14], the authors compared the results from Google Maps and an ITS system in which data was sent through the road infrastructure between key routes in major parts of Hong Kong; i.e., Hong Kong Island (HK), Kowloon Peninsula (KL) and New Territories (NT). The time average difference for all the routes was 1.69 min on weekdays and 1.32 min on weekends. If we divided this by the average route distance, we get 0.45 and 0.34, respectively. These are extremely busy routes in Hong Kong. The authors in [15] showed how travel time can also be investigated with the Google API Data using the colours of Google Maps for the city of Krefeld in Germany. The results showed that the deviation of this method from the measured values is less than 6 percent.

Perhaps the most recent study on this issue was conducted by Ancoris [16]. This company is a Google Cloud Partner and a Google Maps Premier Partner and has also achieved Google’s Location-Based Services Partner Specialisation. The evaluation of Google Maps by Ancoris was conducted over 56 journeys of varying lengths with an average of 18.0 miles, which is 28.8 km. The average difference between the estimated time by Google Maps and the actual time was 1.8 min. The average journey time was 32 min, so the percentage difference is $(1.8/32)$, which gives an accuracy of 5.6 percent. This is close to the findings of the Krefled study.

2.3. Research Methodology in Transport Research

2.3.1. Work on Testbeds

The development of vehicular testbeds with V2X communications [17] has played a significant part in the development of ITS. The authors in [18] developed a vehicular testbed to explore the communication dynamics of vehicular systems to understand how to provide seamless connectivity in these highly mobile environments by analysing the network dwell time. The results showed that network connectivity was related to the frequency and length of the beacon from the roadside units (RSUs) as well as the velocity of the vehicle. This testbed was later used to study service migration in vehicular networks [19]. Co-operative intelligent transport systems (C-ITS) allow road users and traffic managers to share information and use it to coordinate their actions. C-ITS works in association with the communication between systems where one vehicle interacts with another vehicle or with the road infrastructure through a VANET network, leading to better transport safety systems [20].

2.3.2. Use of Simulation

Simulation has also been used extensively in transport research. In [21], the authors used two simulators to integrate road traffic data and network communications. These were SUMO and Network Simulator (NS3) for testing the VANET protocol. NS3 can support a large set of simulation scenarios where the number of nodes can be up to 20,000, thus making the simulation results more realistic. In recent years, simulation technology has played a very important role in VANET research. The authors in [22] tried to integrate real vehicle traces into simulation systems. Data was imported from real maps and vehicle traces were restricted to road topology. In this case, the origin and destination of each journey were randomly generated. The authors could not address the traffic problems dynamically in the simulator and, therefore, focused on two aspects. The first was to develop a protocol for communication between NS3 and SUMO and the second was the wireless routing protocol and its effect on vehicular travel.

2.3.3. Analytical Models

There has been an increased use of queuing theory [23,24] to provide better performance analysis of emerging networks. In [25], the authors used M/M/K models to analyse SDN networks where routes could be dynamically allocated to help meet quality of service (QoS) requirements as the network traffic changes. The findings showed that this approach resulted in increased network utilisation.

Queuing models have also been extensively used in traffic systems. In classical or multiserver systems, the servers are fixed while clients come to the servers for service. In the road network, such models cannot be used to analyse service at junctions as, here, the server is not always serving a particular queue. Hence, servers with vacation periods [26] or cyclic service [27,28] must be considered. Though it is possible to use a vacation model, to examine the delay at junctions, these systems are difficult to apply to cyclic systems as, strictly speaking, the server is not on vacation because it is servicing other queues. Hence, cyclic queueing systems have their own models.

Traditional cyclic models have the limitation that they solve the state equations only when the server is at the queue, which is referred to as a scan instant. Hence, with this approach, the state of a queue is only valid when the server is at the queue. This limits the usefulness of these models, as we have to know exactly when the server is at the queue for different types of systems. However, another approach, as explained in [29], allocates a separate Markov chain, the zero-server Markov chain (ZSMC), which represents the situation when the server is not at the queue. The ZSMC model removes the need to look at the queue only at scan instants and can, therefore, be used to present all the states of a cyclic system using Markov chains. Hence, we can use normal interactive techniques to solve the system equations instead of using complex Laplace functions. Finally, we can represent every state in the system; thus, the ZSMC approach can be used to solve cyclic systems with different service disciplines, including non-exhaustive service and gated systems. We have, therefore, decided to use the zero-server Markov approach in this paper.

2.3.4. ML and AI in Traffic Management

Increasingly, we are seeing the use of ML and AI techniques in traffic management [30]. Several genetic algorithms, which are discussed below, have been developed to reduce traffic congestion and shorten journey times.

2.4. Current Analysis of Journey Times

In [31], the authors considered an adaptive genetic algorithm for reducing the average waiting time at traffic lights. In this work, they used SUMO for the implementation. The genetic algorithm required a number of iterations and, hence, there are issues around scalability and its use in real-time systems. In [32], the authors looked at improving Dijkstra’s algorithm for vehicular routes in urban areas, in which two different Dijkstra systems are combined: the first is for distance and the second is for traffic. This method was used between two paths and there are scalability issues for heavy traffic systems. In [33], the authors looked at how we can use VANET network traffic to predict traffic flow on the road. The system uses two algorithms. The first is random forest (RF), which is a machine learning algorithm, to analyse the network traffic, and the second is the gated recurrent unit (GRU) algorithm, which is a deep learning algorithm, to analyse the road traffic. The system did improve the overall traffic, but there are scalability issues and it may not be suitable for real-time traffic situations. In [34], the authors attempted to analyse and manage regional traffic flows using a traffic classifier and a genetic algorithm. There are scalability issues but the results could be used to drive a mathematical model. Finally, in [35], the authors tried to optimise a multi-junction traffic light control system using a genetic algorithm and by classifying the traffic as light, medium, heavy or very heavy. The algorithm shows improvement but cannot adapt to the changing nature of traffic. A summary of these systems is shown below in

Table 1. Current Analysis of Journey Times.

Research Paper	Type of Model	Analysis of Links	Analysis of Junctions	Journey Time	Evaluation
Adaptive Genetic for Reducing Average Waiting Time for Road Traffic Signals [31]	Adaptive Genetic Algorithm	No	Single	No	Uses several iterations therefore scalability issues
Implementation of Dikkstra Algorithm in Vehicle Routing to Improve Traffic Issues in Urban Areas [32]	Uses two types of Dijkstra algorithms based on distance and traffuc	Working between two paths	No	No	Scalability issues for large traffic systems
Network Traffic Prediction Model Considering Road Traffic Parameters Using AI Methods in VANET [33]	Random Forest- used to analyse the VANET traffic. Gated Recurrent used to analyse the road traffic	No	No	No	Scalability issues. May not be suitable for real-time traffic
Time-allocation Optimization of Regional Traffic Computer Control Based on Distributed Algorithm [34]	Uses a traffic Classifier followed by Genetic Algorithm with cross sectional analysis	Regional Links	No	No	Results could be used to drive a mathematical model. Scalability issues
Optimization of Multi-Junction Traffic Light Control Using the Classic Genetic Algorithm [35]	Genetic Algorithm using light, medium, heavy or very heavy traffic	No	Multiple Junctions	No	Algorithm shows improvement but cannot adapt to to the changing nature of traffic.
Developing traffic predictions from Source to Destination using Stochastic Modelling (Our Model)	Based on Queuing theory and looks at new models for delays at links and junctions	Yes	Multiple Junctions	Yes	High Accuracy

.

2.5. Research Gap

As shown above, all the models presented had issues relating to scalability, performance and use in real-time systems. In contrast, our approach is to use analytical models based on queuing theory to analyse individual journeys using real-time readings from the transport network such as the Middlesex VANET testbed. This facilitates a more model-based approach allowing new queueing models to be developed that are less dependent on historical data. In the paper, we treat the queuing model of the junctions as a cyclic queuing system. In particular, this work will give a highly accurate model using the zero-server Markov chain (ZSMC) technique to determine the delays at the junction.

We know this approach should be effective as it was used to analyse intelligent service migration in vehicular networks [36] in which vehicles are handing over to different road-side units (RSUs) and, hence, service is not available during handover. In our work, we are trying to obtain a detailed picture of the delays at the traffic light or junction where, when the light is red, service is not available because the vehicle cannot proceed, and when it is green, the service is available because the vehicle can proceed. Hence, the ZSMC technique can be used to give a detailed analysis of the delays at the junction. We will also look at an M/M/K/K queuing model to analyse the links between junctions. Finally, we will combine this with the Jackson network technique and Dijkstra algorithm [37] to find the delays from source to destination. Our approach is also summarised in Table 1.

3. The Zero-Server Markov Chain

Markov chains, which use the concept of arrival and service rates, can be applied to yield steady-state system probabilities. However, though an ordinary Markov chain can be used to analyse when the client can communicate with the server, in mobile environments, a new type of Markov must be used to analyse the system as the server will not always be available. Thus, a zero-server Markov chain (ZSMC), in which only arrivals occur, as shown in Figure 4, must be employed to deal with these situations.

A zero-server Markov chain is inherently unstable because after a long time, the length of the queue will go to infinity. In order for the system to become stable, the ZSMC must be coupled with another service-based Markov chain (SBMC) that serves customers/packets, allowing them to leave the system. Thus, the system must be represented by two chains, the ZSMC and the SBMC. The state of the system is given by N,M where N is the number of requests and M is the number of servers. For the ZSMC, M is zero, so the state is given by N, 0 with probability $P_{N,0}$. An example of an SBMC is an exhaustive service model in which when the server arrives at the queue, it serves exhaustively until there is no one left in the queue before it moves to the other queues. This is explored fully in [29].

3.1. Obtaining the Equations

It is worth noting that in this approach, both the ZSMC and the SBMC are Markov chains where the arrival process, the server time and the transitions between the ZSMC and SBMC are assumed to be exponentially distributed. This means that it is only necessary to know the probability of possible present states to work out the probability of the next state using steady-state analysis. This approach allows equations to be developed that can be solved using an iterative approach. It is recognised that real transport systems use more complex processes and so more work will be needed to fully take that into account.

Figure 5 shows the situation when the server does not serve exhaustively. The symbols are explained in

Table 2. Understanding the symbols for the analysis.

Symbol	Description	Meaning
$\lambda$	Arrival rate of requests	The rate at which requests are made
$\mu$	Service rate	The rate at which requests are served
$P_{n,0}$	State probability in Chain 0	System in ZSMC
$P_{n,1}$	State probability in Chain 1	System in SBMC
$v_1$	Transition rate from Chain 1 to Chain 0	Moving from SBMC to ZSMC
$v_2$	Transition rate from Chain 0 to Chain 1	Moving from ZSMC to SBMC

. Using steady-state Markov chain analysis, we obtain the following results:

$$P_{n,0}=(\lambda /\left(\mu (\lambda +v_2)\right))((\mu +v_1)P_{n-1,0}+v_1{P}_{n-1,1})$$

(1)

$$P_{(n,1)}=(\lambda /\mu )(P_{(n-1,1)}+P_{(n-1,0)})$$

(2)

3.2. Handling a System with Capacity K

For a system with a limited capacity, K, Equation (2) is valid, but Equation (1) must be modified as there is no forward rate (i.e., no $\lambda P_{K,0}$). Hence, we get

$$\begin{array}{c}\hfill P_{K,0}=(\lambda /\left(\mu v_2\right))((\mu +v_1)P_{K-1,0}+v_1{P}_{K-1,1})\end{array}$$

(3)

3.3. New Concept: Lost Service

In this section, we introduce the concept of lost service, which occurs when there are customers in the queue to be served but the server is not available. This is expressed as the probability of any customers being in the zero-server Markov chain. Hence, it is the sum of $P(N,0)$ where N goes from 1 to ∞ or from 1 to K, where K is the capacity of the system. Lost service is, therefore, a new parameter that measures the effect of the server not being at the queue in cyclic queuing systems.

4. Summary of Previous Work

In this section, we briefly summarise the previous work conducted in [38].

4.1. Journey Analysis

A journey is defined as the need to traverse a series of links (M) and a number of junctions (N). The denotations are as follows:

• A journey is given by JO(i)
• A link is given by (Li)
• A junction is given by (Ji)

$$JO\left(i\right)=M\left(Li\right)+N\left(Ji\right)$$

(4)

Thus, we can now write that the time for journey as

$$T\left(JO\right(i\left)\right)=MT\left(Li\right)+NT\left(Ji\right)$$

(5)

4.2. Analysis of Delays at Junctions

In order to analyse the delay at the junction, we use the zero-server Markov chain (ZSMC) technique described above. In this case, we are considering that when the traffic light is green, vehicles can move forward at the junction and, hence, are served by the junction. Hence, when the light is green, this can be viewed as the situation when the server is at the queue serving its customers, because when the light is green, vehicles can travel across the junction. However, when the traffic light is red, vehicles cannot proceed past the junction because the service is not available at the time. Thus, the situation of the junction can be modelled using a zero-server Markov chain. Hence, the parameters are as follows:

$\lambda$ = Arrival rate of vehicles to the junction

$\mu$ = Service rate of vehicles traversing the junction

$v_1$ = (1/T) (green signal to red signal)

$v_2$ = (1/T) (red signal to green signal)

4.3. The Analysis of One Junction

Initially, the results were carried out for one junction on a weekday in the city of Leicester, U.K. It was at the Thurmaston Roundabout where the vehicles were moving in all directions. The start time was 6:00 am and the calculation of the vehicles began. Firstly, results were observed for the total number of cars that turned left, the total number of cars that turned right and the total number of cars that went straight ahead. At the junction exits, the total number of cars exiting the junction was calculated. These input values were obtained every minute for 15 min and then used to calculate the arrival rate of the vehicles along each lane going into the junction. Thereafter, these values were used as input to Equations (1) and (2).

4.4. Scenario 1: Turning Left

The arrival rate is calculated in order to check how many cars are turning left at the junction. For different scenarios, the service rate changes. The service rate will be given as $1/T$ where T is the time for the vehicle to turn left at the junction. The time T was set to 3 s.

4.5. Scenario 2: Going Straight

In the second scenario, the cars considered are the ones moving straight ahead at the junction. Again, 06:00 h was the start time. Data were obtained every minute as to how many vehicles were going straight ahead. Data were updated at the end of 15 min. Once the data were updated at the end of 15 min, values were calculated in seconds. The service rate to go straight on will be given as be given as $1/(2\ast T)$.

4.6. Scenario 3: Turning Right

In the third scenario, the cars will be turning right at the junction. The time slots and duration, etc., are considered the same as in the previous scenario. The service rate to leave the third exit or to turn right will be given as $1/(3\ast T)$.

Figure 6 shows the graph of one junction where on the X-axis is the number of vehicles approaching the junction or the capacity of the system, K, within the area. The Y-axis shows the average response time in seconds for cars turning left, going straight and turning right. The results show that turning left is quickest and turning right has the largest response time as it takes the more time to turn right. What is surprising is that only a small value of K is needed to achieve the maximum response time and, hence, the maximum throughput is quickly achieved, after which there is a minimal effect of increasing K.

4.7. Analysis of the Two-Junction Scenarios

In this section, the technique used above is extended to look at two-junction scenarios, as shown in Figure 7. The parameters for the traffic lights were the same for each junction.

4.8. Jackson Network Analysis

The Jackson network technique allows us to explore delays at multiple junctions because the technique states that the input rate into the junction is equal to the output rate of the previous junction. Hence for a two-junction system, the input rate of traffic into the second junction is equal to the output rate of the first junction [39].

After using the ZSMC technique for a single junction, we combine this with the Jackson network model to explore the delay at multiple junctions. Once the values have been captured from the exit of the first junction using the ZSMC model, it is possible to use the Jackson network model to obtain results for multiple junctions. This can be used to find the delays along routes from source to destination.

Figure 8 shows the resultant graph for two junctions where on the X-axis is the number of vehicles approaching the junction within the area, and on the Y-axis is the average response time in seconds for vehicles turning left, going straight and turning right, which is the time taken to travel along two junctions. These results show that there are further delays going through the two junctions, but the overall observation is similar to that obtained at Junction 1; however, the slope of the initial sections is steeper and longer for the two-junction scenario. This points to a greater variation in delay for the two junctions compared to the single junction.

5. Analysing the Delay Along the Road Using a Markov Model

In this section, we develop a Markov model to calculate the delay along the road links.

Let the length of the road $=L\left(Road\right)$.

Length of the vehicle $=L\left(VEH\right)$.

The capacity of the road is $K\left(Road\right)$ which is the total number of cars that can be travelling on the road at the same time.

Hence, $K\left(Road\right)$ is given by

$$K\left(Road\right)=L\left(Road\right)/L\left(VEH\right)$$

(6)

However, K vehicles can travel along the road at the same time. Thus, K vehicles can be served simultaneously. Hence, the road has K servers, so this is an M/M/K/K model. Hence, we can represent this by the Markov chain shown in Figure 9.

Applying Markov balance for states 0, 1, 2 and 3, we get the general equation

$$P_n=(1/n!){(\lambda /\mu )}^n{P}_0$$

(7)

Thus, we sum the probabilities to get the value of $P_0$; then, we obtain the average number of customers/vehicles in the system as well as the response time of the vehicles in the system given by $T\left(VEH\right)$.

5.1. Understanding the System Time Parameter

For the Jackson network, we need to also express the system time $T\left(SYS\right)$, which is the time as seen by someone measuring the time at which vehicles are leaving the road. Since there are K servers, K vehicles can be served simultaneously. Hence, this time is given by

$$T\left(SYS\right)=T\left(VEH\right)/K$$

(8)

A simple C program was used to calculate these values for different arrival times and service rates as well as the capacity of the road.

This scenario is shown in Figure 10.

5.2. Analysis of Second Junction with Interconnecting Links

In this section, we consider the scenario of two junctions separated by the road examined above. In this case, the rate of arrival into the second junction from the road is equal to the inverse of the sum of the response time at Junction 1 and the time along the road.

$$\lambda =1/(TJunction1+TSYS(Road\left)\right)$$

(9)

$\lambda$ = 1/(22.677 + 0.3636).

$\lambda$ = 1/23.0406.

$\lambda$ = 0.0434.

5.3. Obtaining a Proper Estimate of K for the Second Junction

For the calculation of the delay at second junction, we need to obtain an effective value of K. We know that K has a maximum value, the maximum number of cars that can traverse on the road, which is 500. However, we can use our model of the link to obtain a realistic value of K. From our model, the M/M/K/K model, the average number of vehicles on the road was 7.99; therefore, we can use values of K between 1 and 15.

6. Analysis of Three-Junction Scenarios

The model for this scenario is shown in Figure 11; the parameters for the traffic lights were the same for each junction. In the previous section, we considered Junction 1 and Junction 2 connected via road and link and showed how we calculated the delay in such a system. In this section, we will extend the work to consider a three-junction scenario and, hence, we introduce Junction 3 as well as the second link between Junction 2 and Junction 3 shown in Figure 12.

Therefore, we now calculate the delay on the road between Junction 2 and Junction 3.

VMAX Speed = 40 km/h.

L(Road) = 2500 m between Junction 2 and Junction 3.

The value of T(Road) is given as

$$T\left(Road\right)=L\left(Road\right)/(VMAXSpeed\ast 3600)$$

(10)

T(Road) = 225 s.

Therefore, the service rate per vehicle $\mu$ is given by

$$\mu =1/T\left(Road\right)=1/225$$

(11)

Let K be the capacity of the road link in terms of the number of vehicles that fit on the road.

$$K=L\left(Road\right)/L\left(VEH\right)$$

(12)

The value of K = 625.

The arrival rate of the vehicles going from Junction 2 to Junction 3 is given by

$$\lambda =1/(TJunction1+TSYS(Link1)+TJunction2)=0.0146$$

(13)

Using the algorithm to calculate the delay on the road, we obtain the following:

Average number of vehicles on the road = 3.288;

Average time to traverse the road = 225.225 s;

Average response time for the system = 0.3603 s;

Blocking probability = 0.

6.1. To Find the Delay at Third Junction

To calculate the delay at third junction, we say that rate into Junction 3 is given by the following:

$\mu$ = rate of going straight at Junction 3

$\mu$ = 0.1667

$K=15$

$$\lambda =1/(TJunction1+TSYS(Link1)+TJunction2+TSYS(Link2\left)\right)$$

(14)

$\lambda$ = 1/(22.677 + 0.3636 + 45.208 + 0.3603)

$\lambda$ = 0.01457

6.2. Finding the Actual Journey Time

To find the actual journey time between the source and the destination, we need to find the exact time that the vehicle takes to travel along the link as well as the time it takes to navigate the junctions. In this scenario, the journey time is equal to

Actual journey time = (T Junction 1) + (traversal delay of Link 1) + (T Junction 2) + (traversal delay of Link 2) + (T Junction 3).

Actual journey time = 22.677 + 181.818 + 45.7577 + 225.225 + 26.657.

Actual journey time = 501.954 s.

Therefore, the actual journey time from source to destination is 501.954 s.

6.3. Comparison of Three Junction Scenarios

The results for the three-junction scenario without links and the results for the three-junction scenario with links are shown in

Table 3. Three Junctions without Links $\lambda$ = 0.0177 $\mu$ = 0.1667 V1 = 0.05 V2 = 0.05.

Value of K	Number of Request	Average Repsonse	Lost Service	Blocking Probability
1	0.26618	15.03865	0.18826	0.26618
2	0.3896	22.0114	0.2019	0.091
3	0.4472	25.2687	0.2065	0.03305
4	0.4736	26.7616	0.2018	0.0121
5	0.4854	27.4274	0.2087	0.0045
6	0.4905	27.7170	0.2090	0.0016
7	0.4927	27.8404	0.2090	0.0006
9	0.4940	27.9136	0.2091	0
11	0.4942	27.9260	0.2091	0
13	0.4943	27.9280	0.2091	0
15	0.4943	27.9283	0.2091	0

and

Table 4. Three Junctions with Links $\lambda$ = 0.01457 $\mu$ = 0.1667 V1 = 0.05 V2 = 0.05.

Value of K	Number of Request	Average Repsonse	Lost Service	Blocking Probability
1	0.2319	15.9187	0.1648	0.2319
2	0.3261	22.3822	0.1758	0.0688
3	0.36422	22.9984	0.17904	0.0215
4	0.37920	26.0308	0.18003	0.0068
5	0.38502	26.4261	0.1803	0.00218
6	0.3871	26.5736	0.1804	0.0006
7	0.3879	26.6274	0.1804	0.0002
9	0.3883	26.6537	0.1805	0.00002
11	0.3883	26.6570	0.1805	0
13	0.3883	26.6570	0.1805	0
15	0.3883	26.6570	0.1805	0

. The results show that the effect of the links is to slow the rate of traffic going unto Junction 3, hence reducing the overall response time through Junction 3. This was similar to the results previously obtained for two-junction scenario.

7. Testing and Evaluation

The analytical model was validated using simulation. Two simulations were used, SUMO and VISSIM. Both models were used to simulate the Leicester testbed as described in Figure 3. This was a three-junction scenario. Each junction had four exits. Link 1 between Junction 1 and 2 was 2000 m long while Link 2 between Junction 2 and Junction 3 was 2500 m long. For each junction, the number of cars approaching the junction was measured, as was the number of cars turning left, going straight on and turning right. The remaining details are provided in [38].

7.1. SUMO

SUMO, source forge 2013, is a powerful simulator used in extensively in academic research. SUMO has powerful graphics and researchers could benefit more from SUMO, which has statistical files in various forms, such as output coupled to traffic, which selects from the traffic control interface (TraCI) performance parameters [40,41].

7.1.1. SUMO Terms

The simulation flow rate is the maximum hourly volume that can pass through an intersection between lanes if that lane was allocated a constant green light over the course of an hour. Lost time is the portion of the cycle length that is not being completely utilised. In other words, because the traffic light alternates the right-of-way between conflicting movements, traffic flows are continuously started and stopped. Every time this happens, there is a lag due to drivers reacting to the change in the traffic light signal. This lag at the beginning and the end of green and yellow signal intervals results in a portion of that interval not being completely utilised. This lag is known as lost time. SUMO is a car-following model based on the Dijkstra 1972 algorithm and random walk for its path modelling.

7.1.2. SUMO Simulation Procedure

A road network consists of nodes (junctions) and edges (i.e., roads that connect various junctions). Each node features coordinators (x,y). First, the node file is created. The extension of the node file is (.nod.XML). Then, after this, the edge file is created and the file extension is (.edg.XML). Then, after this, the edge-type file is created with file extension (.type.XML). Then, after this, the route file is created with file extension (.rou.XML). The node files, edge files and type file, when combined, will generate the whole network file (.net.XML). After creating the net file, we need to create the route file defining the acceleration, deceleration, vehicle type, length and max speed. Finally, the configuration file has to be added, in which the beginning value is 0 s and the end value is 5000 s. These values can be changed. The input parameters below were used in the SUMO simulation.

• Length of Car: 4 m
• Junction Type: Three-Junction
• Vehicle Type: Car
• Vehicle Colour: Yellow
• Traffic Signal Time: 0.05 s

Each lane has a unique ID to show the cars travelling in that lane. SUMO creates the trips on its own by editing the parameters. Once the trips are calculated, it will run the simulation. Once the simulation is run, as seen in Figure 13, the vehicles are moved along the journey from Point A to Point B. The simulation ran for 503 s and was then stopped to show that all vehicles in the system have completed their journey. The resulting time from the SUMO simulation, to go from Junction 1 to Junction 3, was 500 s, while the resulting time using analytical modelling was 501.954 s.

7.2. The VISSIM Simulator

The VISSIM simulator was created by the PTV Group [42] and is used extensively in the transport industry.

VISSIM Procedure

In the VISSIM simulator, there are different types of graphs. Click on the Network Editor button, then click on Map Provider. From there, you can select any type of background map you wish to use. After this, the link display parameter will appear on the screen. Then, choose the lanes for the three different junctions. After choosing the lanes, select the link between the junctions. Junctions, links and lanes are created and are combined to generate a network object. We can select the behaviour of the network as a type of road shown below:

• Urban Road (Motorised)
• A Road
• B Road
• Cycle Track
• Free Land Selection

After the selection of the network, select the type of vehicle; you can also enter the number of vehicles. In this case, we entered different numbers depending on link and junction and delays between junctions and links. The parameters used for the VISSIM simulation were as follows:

• Length of Car: 4 m
• junction Type: Three-Junction
• Vehicle Type: Car
• Vehicle Colour: Blue
• Traffic Signal Time: 0.05 s
• Each lane has a unique ID

After this, click on the Menu bar and then click on Traffic; choose the vehicle type and speed of the vehicle. Save the simulation details and then start the simulation. In VISSIM, we can set priority rules as well; in our case, we did not set any priority rules. After selection, run the simulation for data collection; click on Data Collection from the network object. The resulting time from the VISSIM simulation, to go from Junction 1 to Junction 3, was 503 s. This compares well with 500 s for SUMO and 501.954 s for the analytical model.

7.3. Final Results

The results are summarised in

Table 5. Summary of results.

Method	Result (s)	Difference (s)	%
VISSIM	503	0	0
Analytical Model	501.594	−1.406	−0.28
SUMO	500	−3.0	−0.60

below.

8. Analysing Real Journeys

In this section, we look at a journey shown in Figure 14. There are three different routes to the destination. The algorithms developed in the previous sections are now used to calculate the delays along the different routes to determine which is the shortest route for the journey. All three routes use the same link, called the common route, to get to the first junction. It is assumed that this road is not busy as it is a side-road and, so, there is no congestion. Hence, the delay on this link is the length of the road divided by the maximum speed allowed on the link. If there is delay along this road, the calculation of all three routes will be affected in the same way.

8.1. Route 1

Route 1: Green Colour.

Route 1 starts from Source A to Junction 1; then, there is a separate route leading straight to the destination.

The journey time along the common route is 36 s.

The time to go across Junction 1 is 22.67 s.

The time to go along the road to the destination is 724.6376 s.

The total time for Route 1 is 783.3076 s.

8.2. Route 2

Route 2: Black Colour.

Route 2 starts from Source A to Junction 1 then proceeds to Junction 2; from there, there is a direct route to the destination.

The journey time along the common route is 36 s.

The time to turn right at Junction 1 is 30.67 s.

The time to traverse the link from Junction 1 to Junction 2 is 181.81 s.

The time to go across Junction 2 is 29.500 s.

The time to go along the road to the destination is 480.769 s.

The total time for Route 2 is 758.0871 s.

8.3. Route 3

Route 3: Orange Colour.

Route 3 starts from Source A to Junction 1, then goes through Junctions 2 and 3; then, we get a direct route to the destination.

The journey time along the common route is 36 s.

The time to turn right at Junction 1 is 30.67 s.

The time to traverse the link from Junction 1 to Junction 2 is 181.81 s.

The time at Junction 2 is 35.8073 s.

The time to go along the link from Junction 2 to Junction 3 is 227.2727 s.

The time to traverse Junction 3 is 17.5756 s.

The time taken to go on the road to the final destination is 240.3846 s.

The total time along Route 3 is 769.5277 s.

8.4. Final Results

The final results for each route to the destination are shown in

Table 6. Final travel time for different routes.

Route	Travel Time (s)
Route 1	783.3076 s
Route 2	758.0871 s
Route 3	769.5277 s

. The results show that Route 2 is the fastest by 11.52 s, while Route 3 was faster than Route 1 by 13.8 s. This scenario clearly shows that the model can be used to find the best route for different routes with different numbers of junctions and links as well as different speeds along the links.

9. Benefits and Limitations of This Work

9.1. Benefits

This work presented in this paper is a new way of calculating journey times using queuing theory mechanisms. This paper has detailed the new approach, which has been validated by two simulations. This work uses a model-based approach and, therefore, is less dependent of large datasets of historical data. The relative equations can be solved using an interactive technique and, so, it is fast. A new concept of lost service has also been introduced. The results obtained using this approach compare favourably with well-known applications such as Google Maps, but more work is needed to integrate this work with other methods of calculating journey times.

9.2. Limitations of This Work

This work is based on queuing theory models and, hence, the probabilistic nature of this type of analysis raises many issues including the fact that, for this kind of approach to be useful, actual distributions for traffic as well as proper average rates of traffic along roads and on junctions must be obtained in real-time. It is assumed that these parameters are available via a modern VANET network which can monitor all the vehicles and road infrastructure in real-time. The cost of deploying such a network over a wide network may be prohibitive. Secondly, in this work, the exponential distribution is assumed at the junctions and along the links. This is a simplistic assumption and more work is needed to look at actual traffic distributions, which, we know, are dependent on the day, time of day, layout of the local infrastructure and length of the links between junctions. More work is needed to look at accurate distributions of arrival and service rates along links and at junctions.

10. Conclusions and Future Work

This paper has explored new techniques for calculating journey times by first representing a journey as a traversal of links and junctions. The analysis of the junction was performed using the zero-server Markov chain technique, while the analysis of links was performed using a M/M/K/K model. These techniques were combined with the Jackson network technique to analyse journey times in an urban environment. SUMO, an open source vehicular simulator, and VISSIM, a commercially developed simulator, were used to validate the results, which clearly show that there was a close comparison between the simulations and the analytical model. This technique was then applied to a real scenario to calculate the shortest path between the source and the destination. It is hoped that this new model-based technique will be used in new traffic models to help reduce overall journey time and to reduce traffic congestion on our roads, leading to an improved quality of life for all. This model-based approach can also make full use of the data being made available by modern vehicular networks, which will allow data on the vehicles to be gathered in real-time. However, as a first step, this work can be used to complement traditional knowledge-based traffic congestion models. Finally, it is important to develop AI and ML algorithms [43] based on this work and to integrate them into mobile edge environments [44] to support ITS for smart cities.