Smart Traffic Lights over Vehicular Named Data Networking

Abstract

The existing traffic light system fails to deal with the increase in vehicular traffic requirements due to fixed time programming. Traffic flow suffers from vehicle delay and congestion. A new networking technology called vehicular ad hoc networking (VANET) offers a novel solution for vehicular traffic management. Nowadays, vehicles communicate with each other (V2V), infrastructure (V2I), or roadside units (V2R) using IP-based networks. Nevertheless, IP-based networks demonstrate low performance with moving nodes as they depend on communication with static nodes. Currently, the research community is studying a new networking architecture based on content name called named data networking (NDN) to implement it in VANET. NDN is suitable for VANET as it sends/receives information based on content name, not content address. In this paper, we present one of VANET’s network applications over NDN, a smart traffic light system. Our system solves the traffic congestion issue as well as reducing the waiting time of vehicles in road intersections. This system replaces the current conventional system with virtual traffic lights (VTLs). Instead of installing traffic lights at every intersection, we utilize a road side unit (RSU) to act as the intersection controller. Instead of a light signal, the RSU collects the orders of vehicles that have arrived or will arrive at the intersection. After processing the orders according to the priority policy, the RSU sends an instant message for every vehicle to pass the intersection or wait for a while. The proposed system mimics a human policeman intersection controlling. This approach is suitable for autonomous vehicles as they only receive signals from the RSU instead of processing many images. We provide a map of future work directions for enhancing this solution to take into account pedestrian and parking issues.

1. Introduction

Progression in vehicular communications system and the increase of vehicle numbers has created a need for industrial and research communities to tackle the emerging challenges. The conventional traffic light system has many limitations. Vehicles suffer from delays caused by fixed time cycles, specifically with low traffic conditions. In the case of traffic congestion, it is hard to route the traffic according to road capacity or vehicle priority. In addition to the rapid development in communication systems, it is expected that future vehicles will be smart enough to communicate with their surroundings in many ways. Many manufacturers such as Hyundai, Tesla, BMW and Google are moving towards autonomous cars. Therefore, research regarding vehicular communication systems is paying great attention to a new networking technology called vehicular ad hoc networking.

Vehicular ad hoc networking (VANET) is an emerging area with much research currently being undertaken [1]. Vehicle manufacturers take into consideration the information disseminated for future vehicles. Therefore, multiple applications are expected to be implemented in VANET. Traffic and parking status, weather conditions, fuel prices, bus schedules and entertainment applications are a part of upcoming vehicle applications [2]. In addition, vehicles are also expected to share with each other practical information such as location, direction, speed and the carried goods or passengers [3].

There are many types of vehicular network communications scenarios, such as vehicle to vehicle (V2V), vehicles to roadside unit (RSU) (V2R), vehicles to pedestrian (V2P) and vehicle to infrastructure (V2I) [4]. The communication between vehicles and other surrounding nodes in a VANET is based on a variety of advanced technologies such as dedicated short-range communications (DSRC), Wi-Fi, 3G, 4G, etc. [5]. However, IP addresses were originally proposed for wired technologies not for mobile technologies such as VANET. Therefore, VANET suffer from many inherited features such as intermittent connectivity, high dynamic network topologies, harsh propagation conditions and broadcast wireless channels. These features create significant challenges to presenting efficient and reliable content delivery solutions.

An efficient solution for VANET’s challenges is to shift focus from address-based networks to name-based networks. Named data networking (NDN) technology has recently been applied in VANET as a branch of the new emerging paradigm, information centric networking (ICN) [5]. NDN improves performance in currently popular data centric based applications such as video streaming, audio conferencing, data synchronizing, etc. [6]. The NDN router maintains three data structures: a content store (CS), a pending interest table (PIT) and a forwarding information base (FIB). These data structures have the following functions:

• CS caches the forwarded data through the router.
• PIT records the unsatisfied interests received by the router.
• FIB stores information about the interfaces that could satisfy the interest packets.

Instead of IP-based networking, NDN focuses on data delivery based on its name. The consumer expresses the required data with a uniquely named interest packet. The publisher replies with the corresponding data packets by tracking the reverse path of the interest packet. The NDN router caches the content along the forwarding path and the other routers that cache the content can also provide that content for new consumers. Moreover, NDN efficiently supports multicast forwarding when multiple users request the same data. Therefore, VANET can benefit from NDN, especially in data multicast dissemination [6].

The resulting approach from applying NDN directly into VANET (dubbed “VNDN” in some research) is a potential solution to many issues in VANET. VNDN supports non-safety applications such as audio, video streaming, etc. With respect to the safety applications, we present in this paper a smart traffic light system as the first study towards applied VNDN in VANET application to the best of our knowledge.

Despite the proposal of various studies and applications by researchers such as [7,8], content centric vehicular networking (CCVN) [9,10], and VENDNET [11], VNDN still suffers from some in-built features. For example, sending the data packet to the consumer by tracking the reverse path of the interest packet is suitable for static networks but for vehicles more solutions to overcome this shortcoming are required. A geo-based location technique is one of these solutions as the packet name is included in the vehicle position.

We used a geolocation technique to introduce our novel smart traffic light system. Although many applications have been studied in VNDNs, smart traffic lights have not yet been studied. To the best of our knowledge, we propose the first design for smart traffic lights in a VNDN. The proposed system replaces the current conventional traffic light system with a smart and efficient system. Instead of installing traffic lights at every intersection, we can utilize the RSU to play the role of road controller. Instead of emitting a light signal, the RSU sends a data message to every vehicle arrived at the intersection to pass the intersection (green signal) or wait for a while (red signal). The system manages the road traffic in a decentralized manner. Each RSU deals only with the vehicles arrived at its intersection. However, the RSU could inform its neighbor RSUs about the expected vehicles that could arrive at their locations. Sharing information about the vehicles that will arrive at any RSU will give the RSUs adequate time to make decisions on road traffic management.

Beside the novelty of the proposed design in VNDN, our design solves many issues in current conventional traffic lights systems, such as the following.

• Real-time control: Controlling intersections according to road status is a real-time issue in our design. Transportation status information is collected and disseminated by the RSUs installed on the intersections. In addition, the information in any RSU is provided to other RSUs and drivers to spread awareness to the entire network regarding the traffic conditions or any traffic congestion at every point along the way.
• Low-traffic conditions: We can apply our system for low-traffic conditions during early morning or midnight at urban centers. This system allows drivers to move without stopping at intersections if no vehicle is crossing.
• Emergency vehicles: This system ensures priority for emergency vehicles by routing them within the direction to indicate its upcoming destination.
• Autonomous vehicles: Autonomous vehicles do not require capturing and processing images of light status continuously. RSU sends the vehicles either pass signal (green) or wait signal (red) only.
• Low vision: This method is a probable solution for the degradation in vision caused by snowing or fogging. The technique is also an appropriate alternative for the image processing methods used in various solutions.
• Power consumption: The traditional traffic system is controlled by fixed time. However, traffic lights continue to work even when intersections are empty. This traffic system consumes considerable energy, and the implementation of our system will alleviate such consumption.

In summary, the contributions of our design are as follows.

• To the best of our knowledge, our work is the first to present smart traffic light application over vehicular named data networking.
• We present a smart traffic light system in which the vehicle waiting time in intersections varies according to street capacity. In addition, a digital signal is sent to every vehicle at the intersection instead of emitting a light signal.

The rest of this paper is organized as follows. Section 2 illustrates works related to smart traffic light systems and ongoing investigations on VNDN. Section 3 explains the proposed system architecture and algorithm in detail. Section 4 discusses the experimental results and the simulation environment. Section 5 concludes this paper and presents future works.

2. Related Works

2.1. Smart Traffic Light System

Some researchers [12,13,14] suggested estimating the speed and number of vehicles by placing sensors for particular lengths at road sides. However, the proposed sensor systems are not perfect due to the difference between the estimated vehicle speeds and the exact arrival times at intersections. Yu et al. [15] suggested to provide vehicles with predictive data about traffic condition, but this solution fails to mitigate the congestion issue; for example, drivers who desire to reach any destination by choosing low-congestion roads could simultaneously select the same roads. Some researchers [16,17] proposed solutions for traffic light management by implementing image processing techniques to detect congestion in roads using cameras. However, such methods are costly and may be insufficient when vision and weather are poor.

Many techniques, such as queue theory [18,19], fuzzy logic control [20,21,22], and genetic algorithm [23], have been exploited in traffic light control. Queue theory method deploys sensors at each intersection, and sensors collect the queue size to calculate the green light time. In fuzzy logic control, sensors are used to detect the number of vehicles on each road to establish the duration assigned to the vehicles when passing an intersection. By using the genetic algorithm, the optimal solution results can be obtained by determining the light phases and the total time of the green light. Therefore, the genetic algorithm optimizes the signal system because the light controller rapidly responds to decrease the number of vehicles passing the intersection by assigning additional time for the green signal.

2.2. Virtual Traffic Light System

Another solution has been raised for traffic light system called Virtual Traffic Light (VTL). The first VTL algorithm for VANET has been presented by Ferreira et al. [24]. In this algorithm, vehicles that move on the same direction are considered a cluster, which includes a cluster head and a cluster leader. The cluster head is the vehicle nearest to the intersection, and the cluster leader is the vehicle that moves farther from the intersection. The cluster leader is responsible for choosing the priorities and broadcasting the VTL messages. A new VTL leader is then elected when the VTL leader vehicle leaves the intersection.

Since the first works on VTL were published, many researchers have studied and introduced related simulations and performance analysis. Viriyasitavat et al. [25] proposed a coexistent model, wherein vehicles that are equipped with VTL can coincide with those without VTL. Chou et al. [26] proposed a scheme that adapted the cycle of VTL based on the existing traffic and vehicle type. This scheme comprises three stages: planning, managing, and operating stage. In the planning stage, each vehicle collects the neighbor information to select the leader of vehicles by receiving a beacon message containing the basic information of vehicle, such as location, speed, travel time, and identity. In the managing stage, the leader creates and maintains its own VTL. In the operating stage, the leader broadcasts the traffic signals to all vehicles. Munst et al. [27] utilized mobile communication and cloud computing technology to execute a VTL system that contains two phases. In the first phase, vehicles send their own information to be collected by the cloud data infrastructure. In the second phase, the cloud infrastructure sends the suggestion messages to all VTL vehicles to pass or wait at the intersection. Yapp et al. [28] indicated that VTL will introduce the framework of safety analysis by evaluating risks. They also suggested ways that the VTL can be improved to yield additional precise results and introduced the directions that can be extended when new VTL faults emerge.

Bazzi et al. [29] introduced an algorithm that defines the priorities of the road intersections with virtual VTL. This algorithm was implemented for VANET based on IEEE 802.11p. Vehicles exchange position information based on broadcast messages, whereas priority and traffic decision messages are sent based on unicast messages. All vehicles share common databases for the road map and VTL information. This algorithm works in two stages: priority definition stage and following priorities definition stage. In the first stage, the VTL algorithm gives the first priority to the vehicle that first arrives at the intersection. In the second stage, vehicle with priority grants the priority to the next one. This mechanism ensures that a single vehicle passes at a time.

Although the VTL scheme improves the average speed of vehicles compared with that of the traditional traffic lights, all research papers in VTL share the leader and header concept. Depending on such a moving node, the network becomes intermittent. Playing the role of the light controller is reliable based on a fixed node. Therefore, RSU is a better choice to be the controller of the traffic light.

2.3. Vehicular Named Data Networking

Various studies have applied NDN into VANET. Wang et al. [7] suggested inclusion of the geolocation information in data naming. Wang et al. [8] presented a simple VANET design for highway scenarios. Amadeo et al. [9] proposed the CCVN design by extending the CCN network to support content delivery on top of IEEE 802.11p technology. Grassi et al. [10] presented a VANET simulation in an urban area to disseminate packets in all directions by using a small-scale field test and a simple greedy forwarding strategy. Chen et al. [11] introduced the VENDNET design in a simple vehicular scenario featuring a single straight road. However, the authors discussed only the general idea of VANET and did not provide specific application details. Hence, applying the NDN-based VANET to safety and non-safety applications is still an open research area. In this paper, we study the traffic light system, which is one of the most significant applications in VANET.

3. Proposed System

3.1. Overview of VANET over NDN

Vehicles and other nodes in VNDN communicate with each other based on various interfaces, such as LTE, 802.11, and WiMax [5]. The communication system uses two types of packets, namely, interest and data packet. The interest packet is issued for a specific content identified by a name, and the data packet is issued with the corresponding content. The vehicle requesting an interest is called a consumer, and the vehicle providing the corresponding content is called a provider. Each vehicle generally maintains three data structures [5]: (1) content store (CS), which stores the incoming data packets; (2) forwarding information base (FIB), where the interest is forwarded through the outgoing interfaces; (3) pending interest table (PIT), in which the interests are stored to cache received packet in the CS or send to the consumer.

3.2. Proposed System Architecture

Our system architecture includes two types of nodes, namely, RSU (which represents the provider) and vehicle (which represents the consumer). RSU provides the data for passing allowance (data packet) while vehicles receive (or consume) the allowance passing the intersection (interest packet). However, RSU maintains two components: NDN node and traffic management unit (TMU). TMU is responsible for managing the vehicles passing the intersection. In RSU, CS stores all satisfied interests for already passed vehicles for a few minutes while PIT stores the interest that has already arrived but has not passed the intersection yet.

Vehicle maintains two components: NDN node and signal unit. The signal unit is responsible for changing the data packets of pass/wait messages into lighting signals. Vehicles periodically send interest messages to the RSU. As default NDN, the interest message contains the entire vehicle’s information, such as vehicle ID and nonce value. However, the nonce value is provided by the producer of interest message. In addition, this nonce value is combined with the data message that responds to the interest message. The overall framework of this system is shown in Figure 1.

When an interest arrives at RSU, the interest is looked up in CS; if matching is found, then the interest is discarded. If no matching is observed, then the interest is added to the PIT. Simultaneously, the interest is sent to the TMU to make the proper decision for vehicles to pass the intersection or wait. After decision making, the FIB forwards the data packet through the network based on the forwarding strategy. In the vehicle, CS stores all the received data packets for a few seconds to provide the status of intersection in a specific time. PIT stores all arrived interests of other vehicles that have not yet passed the intersection. FIB then forwards the interest or data packet through the network based on the forwarding strategy.

3.3. Forwarding Strategy

As previously mentioned in VANET, if the CS of NDN router does not satisfy the interest packet, then the interest is added to the PIT and forwarded by the FIB to the corresponding interface. By contrast, when the data arrive, the NDN router checks the PIT to find the interest that matches the arrived data. However, the table of FIB entries is unstable due to the fast movement of VANET vehicles. Therefore, each interest is flooded into the communication interface. Consequently, vehicles forward all the incoming interests and data packets. This forwarding strategy causes considerable conflicts and redundancy in communication. The alternative solution for packet forwarding strategy is to exploit the vehicle geolocation information. The vehicle position information is added to the issued packet name. The work introduced by [7] offers an appropriate scheme in forwarding based on location. The packet name in this scheme has the form: “App/Geo-location/Data_type”. “App” represents the application which requires the packet, “Geo-Location” represents the current vehicle position, and Data_type represents the type of required packet. For example, the interest with the name of /Traffic/A_Street/means that the vehicle moving in A_Street requests for passing the intersection in “Traffic” application. Therefore, the vehicle position is extracted from the packet name.

Moreover, the position of vehicles that could contribute to packet forwarding is required. Therefore, the so-called data structure neighbor table (NT) [6] is added to the vehicle. The NT stores the positions of neighbor vehicles. NT is also periodically updated by a locally broadcasted Hello interest named by the form: /Hello/Vehicle_ID/Geolocation. The Hello interest is recognized by the prefix of Hello. Afterward, the Vehicle_ID and geolocation information will be extracted and stored in NT. Interest and data packet forwarding depends on geo-location. Before forwarding an interest, each vehicle selects the proper next hop. If the vehicle moves in the RSU communication range, then the interest is directly forwarded to RSU by flooding strategy. Otherwise, the vehicle looks up the farthest neighbors in its NT that move close to the RSU and then adds these neighbors into the forwarder list.

In this approach, each RSU receives the interest packet of the vehicles that only move ahead to the intersection. The RSU collects all interests from the vehicle at lanes and streets to decide the required passing time for each street vehicle to the intersection. RSU gives the priority of intersection passing according to many aspects. The priority could be different on many levels. For example, the ambulance vehicles have the priority for passing the intersection. The priority could also be assigned based on the capacity of street and traffic congestion.

The vehicle disseminates an interest packet containing the following fields: vehicle ID, vehicle position, vehicle speed, vehicle destination, street ID, nonce value, and time of sending the interest. As shown in Figure 2, the yellow vehicle sends an interest message carrying the desired destination. According to the interest’s name and destination, the interest arrives at RSU directly if the vehicle moves in RSU communication range or transfers from node to node until it arrives at the RSU. RSU only receives the interest from one direction at every street; for example, the interest messages issued by the red vehicles in Figure 2 are discarded because they already exist in the CS of RSU. Vehicles that move away from the RSU (e.g., red vehicle) still send their interest packets to the next destination (next RSU).

When an interest packet arrives at RSU, the packet name is checked in the CS. If the interest already exists, then this interest will be discarded directly. Otherwise, RSU lookups the PIT to check whether this interest pack et already exists. If the packet exists, then the interest is updated with the new information. Otherwise, the interest is checked in the PIT. If the interest exists, then its time is updated and becomes priority. If the interest is unavailable, then it is added to the PIT. After collecting the interests, RSU sends the arrived interests to the traffic management unit (TMU). The traffic decision of the vehicle is made according to the traffic management algorithm in the RSU. The RSU then disseminates the corresponding data packets through the networks to each vehicle at the range of RSU. After forwarding the data packet, the interest is removed from the PIT. However, the interest packet is kept in CS for a while and forwarded to the other neighboring RSUs. This step provides the other RSUs with the pre-knowledge regarding the probable number of vehicles that could arrive at the intersection. Figure 3 demonstrates the process of receiving interest packets and sending data packets in RSU.

The related vehicles receive the response of their interest packet. Meanwhile, unrelated vehicles do not receive the same and discard the data packets from the other RSUs. Many vehicles could contribute to data packet forwarding. For example, the red vehicle in Figure 2 forwards the received data, which correspond to the interest packet of yellow vehicle. However, the data packet is a (pass message) for one or two directions and red signal (wait message) for the other directions according to the intersection policy or the time specified for each direction.

3.4. Traffic Management Algorithm

In this section, we illustrate our traffic light management algorithm. We consider the waiting time of vehicles in an intersection. The waiting time is divided between all street vehicles arriving at the intersection. When an interest arrives at RSU, its arriving time is recorded to estimate the street weight, which is calculated as the total time of all vehicles that already arrived and waiting at the intersection.

$$W={\sum }_{i=1}^n{V}_i,$$

(1)

where $V$ is the waiting time of the already arrived vehicle, and $n$ is the number of vehicles.

When streets weights are calculated, each street is allocated with a specific waiting time depending on the street weight. The green light time is distributed to the streets based on the weight; additional time is given when the street weight is large. The assigned time also depends on the total phase time, which is the period of time between two green light signals for the same street. The phase time is not fixed, unlike the conventional traffic light system. Each phase time in our design varies according to street capacity. We also consider the time required for every vehicle to pass the intersection. The required time for passing the intersection depends on the number of lanes and the distance between a vehicle and the intersection. Daily observation revealed that each vehicle requires an average of 5 s per lane to pass the entire intersection at 50 km/h. However, using the required time for each street is not always a suitable option, especially in high traffic conditions. Therefore, the required time determined for each street vehicle is 1 min for high traffic conditions. When one phase is completed, a new phase will start using the new weights. For the next phase, the new interests of vehicles that recently arrived and those still waiting from the previous phase are processed. The pseudo-code of the traffic management algorithm is as follows.

Pseudo-Code of Traffic Management for One Phase

Input: S table contains four types of streets vehicles interests A, B, C, and D. Output: “Pass” or “Wait” message. 1. While S is not empty repeat. 2.  Start the phase. 3.  Calculate $W_A$, $W_B, W_C$ and $W_D$ and put them in a descending order. 4.  Calculate the assigned time $T_A$, $T_B, T_C,T_D$ for each street. 5.  For $i$ = 1:4 do 6.   $Wi$ = max $W_A$, $W_B, W_C$, $W_D$} 7.   For all $Wi$ vehicles 8.    Send “Pass” data packet to all vehicles of the largest $Wi$ 9.    Send “Wait” data packet to all other vehicles. 10.     If vehicle passed 11.     Add data packet to CS 12.     Delete interest packet from S table 13.     else 14.     Add interest packet to the next phase S table. 15.     End if. 16.     Delete all satisfied interests in $Wi$ from S table. 17.    End For. 18.   End For. 19.  End the phase. 20.  Update S with new incoming and old interests. 21.  End while.

Suppose that RSU in Figure 2 receives a number of packet interests for vehicles during a specific period of time, as shown in

Table 1. Number of vehicles arriving at RSU during a period of time (in seconds).

	5 s	10 s	15 s	20 s	30 s	40 s	60 s	>90 s	Vehicle Number	Weight(s)
A	2	4	2	2	4	5	2	0	21	560
B	3	2	5	3	2	1	1	0	17	330
C	5	3	2	1	2	3	2	1	19	495
D	1	2	4	5	2	6	2	0	22	605

. According to Equation (1), the weights of A, B, C, and D streets are 560, 330, 495, and 605 s, respectively. In this example, the required times for each street vehicles are 52.5, 42.5, 47.5, and 55 s. In this case, RSU sends “pass” data packets to all vehicles in D Street with the assigned time for 55 s. Simultaneously, RSU sends “wait” data packets to all other vehicles. RSU then sends “pass” data packets to all vehicles in A Street for 52.5 s and “wait” data packets to all other vehicles.

4. Experimental Results

4.1. Simulation Environment

Using NDN Simulator (ndnSIM) [30], we implemented the NDN forwarding daemon and the IEEE 802.11p protocol for RSU and vehicles, respectively. The traffic management algorithm is also installed on RSU. We used the ns-3 simulator [31] to establish the connections between the mobility nodes. We then implemented the GPSR to work in the request–response manner. The maximum distance of communication between vehicles and RSU is 300 m. Apart from the NDN structures, the NT structure, which supports our design, was executed. We modified the default interest and data packets to support our system features. The total number of vehicles moving in our simulation is randomly set between 5 vehicles for low condition and 200 vehicles for high condition per 1 min with random speeds between 10 and 50 km/h. Each vehicle sends the interest packet every 3 s to inquire the intersection light status.

Our design is simulated for 5 min on a simple scenario, which includes four streets intersecting at one point as depicted in Figure 3. The first 2 min is simulated with low traffic condition while the last 3 min with high traffic condition. We considered that many factors could affect traffic flow system. Each street direction has two lanes as depicted in Figure 3. The average time of vehicles to cross the intersection is estimated to be from 3 s to 5 s when the intersection length is 12 m. Therefore, each vehicle requires between 0.86 and 4.4 s for crossing the entire intersection. If the signal is green for any street, then each vehicle has three choices to transfer the intersection: keep moving straight, turn left, or turn right. The maximum time allocated for green light is set to 90 s.

4.2. Results and Discussion

As discussed earlier, our study includes two aspects. We study the NDN forwarding in VANET for traffic light system and simultaneously simulate a novel design for the traffic light system on VNDN. We chose the distributed VTL [29] as a benchmark for our design. In addition, we take the adaptive VTL [26] as a benchmark for total time consumption of each vehicle to pass the intersection. Therefore, the performance metrics are defined as follows:

• Packet delivery rate: the number of packets that are exchanged between vehicles and the RSU to all interest and data packets forwarded by the RSU and vehicles;
• Packet delay time: the time between sending the interest packet by the vehicle and receiving the data packet from the RSU;
• Total consumption time: the total time for all vehicles waiting for the green signal at the intersection.

The vehicle disseminates an interest packet carrying the vehicle ID, current position, sending time, and road destination, which are needed for the vehicle to pass during its transfer to the intersection. For example: /traffic/ADS-1233/22.32,11.23/10:32:12/A_Street, where “traffic” is the traffic application, “ADS-1233” is the vehicle ID, “22.32, 11.23” is the vehicle position, “10:32:12” is the sending time, and “A_Street” is the name of destination street. The nearest vehicle will receive this interest and forward it again to its neighboring nodes.

The original VNDN design in low-density and high-speed vehicles demonstrates low performance in packet delivery rate due to the increasing number of vehicles [2]. By contrast, our design demonstrates good performance under low vehicle density due to the small communication area required for packet exchange between the vehicle and RSU. Another factor that enhances the communication performance under low vehicle density is the sufficient reply time of the interest when the vehicle enters the RSU communication range. Furthermore, the high-speed scenario rarely occurs due to the low speed policy of vehicles in urban areas. Figure 4 shows the time delay when various numbers of vehicles move during the simulation process for our design and the distributed VTL. The delay is the duration between the sending of the interest packet by the vehicle and the receipt of the data packet from the RSU. The message exchange and name lookup processes will increase with the number of vehicles. Therefore, the increasing time delay is a consequence of the increasing number of vehicles. Packet delivery rate is the number of packets exchanged between vehicles and the RSU to all interest packets issued by the vehicles. Notably, the packet delivery rate degrades when the vehicle number is larger than the threshold or vehicles move out of the RSU range. Therefore, the increasing number of vehicles leads to an increase in packet delivery rate within the threshold as shown in Figure 5. With use of our algorithm, the influence from the opposite direction vehicles is avoided, and the packet is delivered perfectly to the RSU. In addition, the implemented geo-based strategy [6] continues to forward the packets until they are delivered to the requester or another node takes over. Therefore, this strategy enhances the packet delivery rate.

First, we fixed the duration of the traffic lights by assigning 30 s for the green signal and 3 s for the yellow signal in each direction. However, the fixed time leads to poor performance in traffic flow for simulation of 10 min. Given the variable number of vehicles arriving at each direction and the fixed time programming of the light traffic system, the total wasted time of all vehicles stopping at the intersection is high for low and high traffic conditions. Such time consumption is excessive for drivers, especially in the absence of vehicle transfer in intersections. Therefore, our design alleviates this issue with limited time consumption.

Second, we evaluate the application performance of our design and the adaptive VTL. By implementing our traffic management algorithm, the total wasted time is reduced under high and low traffic conditions. Vehicles in our design respectively consume 15% and 20% of the total stopping time in case of the fixed time lights and adaptive VTL for low traffic condition. In total, only 8 vehicles consume the time that 51 vehicles in fixed light traffic could consume and that consumed by 41 vehicles in adaptive VTL when passing the intersection for all streets as depicted in Figure 6. In case of high traffic condition, the total wasted time of vehicles represents 72% and 81% of the time with use of fixed time programming and adaptive VTL, respectively. This finding means that 610 vehicles consume time in fixed light traffic similar to that in 840 vehicles when passing the intersection, as depicted in Figure 7, for all streets. Notably, our design presents a significant improvement in reducing the waiting time for low traffic condition more than that in high traffic condition. This finding is due to the need for the RSU to distribute the time between all directions under high traffic condition unlike that in low traffic condition, where some directions could be empty.

5. Conclusions and Future Work

5.1. Conclusions

NDN introduces new service applications in VANET, such as weather, safety, and entertainment applications. Traffic lights area significant part of transportation systems and require additional consideration when utilizing VANET. NDN is suitable for VANET because it sends/receives information based on content name, not content address. The existing traffic light system fails to deal with the increase in vehicular traffic requirements due to the fixed time cycles. The new networking technology called VANET offers a novel solution for vehicular traffic management. In this work, we present a smart traffic lights system, which is one of the network applications of VANET over NDN. Our system solves the traffic congestion issue and reduces the waiting time of vehicles in road intersections. This system also replaces the current conventional system with a smart digital one. Instead of installing traffic lights at every intersection, we utilize the RSU to act as the road controller. Instead of light signals, instant messages are sent (by the RSU) for every vehicle to pass the intersection or wait for a while. We use a geolocation-based forwarding strategy in our design to disseminate packets. The proposed system mimics a human’s means of intersection control. Experimental results show a high performance in delivery rate and low delay time during packet exchange between vehicles and RSU. The delivery rate and delay time with our design make VNDN an efficient solution for traffic light systems.

5.2. Future Work

Although we present a smart traffic application in VNDN, some deficiency still exists. In the future work, considering additional time and vehicles for simulation, we will examine efficient forwarding strategies with multiple connected RSUs. In addition, some research works that study the caching policy in traffic light using VNDN are available. Supposing that traffic light is eliminated, pedestrian and bicycles require additional investigation in our future work. The length of vehicles should also be considered during this simulation for future works. We also intend to extend our work to include additional RSUs and vehicles, covering a large area. With respect to the traffic light controlling optimization, we will study many algorithms and choose the sufficient one.