To evaluate the VTLS using the pull, and the push-based modes, a set of simulations were carried out on a grid road map with seven horizontal roads and seven vertical roads. The simulation setup is presented in more detail next. Then, the results obtained in the simulations are shown and discussed.
5.1. Simulation Setup
The simulation setup regarding the used simulator, the road map configuration, the wireless communications, the VTLS implementation, the simulation parameters, and the simulation runs are presented in the following.
Simulator: It was used the simulator Veins-5.0, modified to allow pedestrian’s communications. Veins is a vehicular network simulation framework that couples the mobility simulator SUMO-0.32.0 with a wireless network simulator built on the discrete event simulator OMNeT++. Veins has a manager module to synchronize the mobility of the vehicles between the wireless network simulator and SUMO (simulation of urban mobility).
: The simulation was carried on a grid road map with a size of 7 × 7. The length of each road is around 200 m and each road connected to an intersection has a crossroad at that intersection, as shown in Figure 8
. The routes of the cars were generated with the SUMO traffic generator (randomTrips.py). This tool was configured to generate a car every 1.0 s to run a minimum trip distance of 2000 m with a maximum speed of 10.0 m/s. The pedestrians walk a maximum distance of 2000 m with a speed between 1.1 and 1.4 m/s. Cars and pedestrians leave the simulation after completing theirs trips.
Communications: The vehicles and pedestrians used the same communication parameters. All vehicles owned an OBU running WSMP over IEEE 802.11p. All pedestrians used a smartphone also provided with WSMP over IEEE 802.11p. The transmission power was 20 mW, which corresponds to a signal range of around 530 m. The total length of the MAC frames containing the messages was 166 bytes. The transmission bit rate was 6 Mbps, as this value has been generally assumed as the default channel bit rate. No channel switching was used. The simple path loss propagation model was used, and no buildings were considered in the simulation scenario.
Virtual semaphores: Simulations were carried out with twenty-five virtual semaphores, each one placed at the center of the intersection with four roads. For simplicity, the yellow light was not implemented in the semaphores.
: The values of the parameters used in the simulations are shown in Table 1
. The name of the parameter makes clear its meaning, except the parameters ndn_*, wsm_*, person_*, which are explained in the following.
In the pull mode (NDN), when a car is at a distance to the road end lower than the value specified in ndn_car_dst_to_road_end, it starts sending interests to the RSU with a periodicity of ndn_car_interest_mesg_period seconds. The RSU sends interests to the pedestrians with a periodicity of ndn_rsu_interest_mesg_period seconds. Only the pedestrians at a distance to the road end lower than person_dst_to_road_end or at a distance from the road beginning lower than person_dst_from_road_start reply to the interests. In this way, the RSU is able to know the pedestrians that are approaching the intersection and those that have crossed the intersection and are leaving it. In the push mode, when a pedestrian is at a distance to the road end lower than person_dst_to_road_end, the smartphone of the pedestrian starts sending interests to the RSU with a periodicity of wsm_person_mesg_period seconds. The RSU announces the state of the traffic lights to the cars with a periodicity of wsm_rsu_beacon_tx_period seconds.
So, according to the parameters defined in Table 1
, in the push mode, the pedestrians send a message to the RSU every 500 ms, when they are at a distance lower than 4 m to the crosswalk of the intersection. The RSU broadcasts to the nearby cars a message with the traffic light signals every 200 ms. In the pull mode (NDN), each RSU broadcasts an interest to the pedestrians every 500 ms. The pedestrian replies to the received interest when it is positioned at a distance lower than 4 m to the crosswalk of the intersection. Whenever a car is at a distance lower than 18 m to the crosswalk of the intersection, it sends an interest to the RSU every 500 ms asking for the traffic light signals.
Simulation runs. The simulations were ran during 500 s for each one of the three tested modes—notls, push, and pull, where notls (no TLS) means the absence of virtual traffic light signals, push refers to the push-based mode, and pull to the push-based mode (implemented by NDN). Six distinct ratios R of “number of pedestrian/number of cars” were considered: 2.5, 2.0, 1.5, 1.0, 0.5, and 0.25. For example, a ratio of 2.5 means that the number of pedestrians walking in the sidewalks is 2.5 times higher than the number of cars rolling in the map roads. The ratio R becomes relatively stable after a certain time (~150 s). The results were collected during this stabilized period, which is between 150 s and 500 s. In all simulations, a car enters in the simulation every 1.0 s. In order to obtain the specified ratios, the pedestrian generation period was respectively 0.26, 0.33, 0.44, 0.66, 1.32, and 2.64 s. For example, the generation pedestrian period of 0.26 means that a pedestrian enters in the simulation every 0.26 s. The pedestrian generation period (T) is related to the ratio (R) approximately by the equation: T = 0.66/R.
Eighteen (3 × 6) simulation runs were ran to build one set of results. The trips of cars and pedestrians were chosen randomly at the beginning of each set of simulations. However, the trips taken by the pedestrians and the cars do not change for each set of test modes (notls, push, pull) run in the simulation at a certain ratio R.
Simulations were run first without using the VTLS, i.e., it only used the native SUMO strategy to let pass pedestrians on the crosswalks, which have always priority over the cars in the crosswalks. This simulation sets a priori the optimal situation for the cars, in terms of lowest waiting time, to let the pedestrians pass in the intersections. Then, simulations were run using the push and the pull-based modes with the same traffic, and pedestrian mobility traces used in the run without VTLS. The simulations using the push and the pull-based modes were run with the native SUMO strategy turned off. In this way, the traffic at the intersections is only controlled by the VTLS in order to let the pedestrian pass safely in the crosswalks.
The results shown next represent the average values obtained after running 35 sets of simulations, where each set includes the notls, push, and pull test modes. So, these 35 sets of simulations corresponds to 35 × (3 × 6) individual simulation runs, and 35 × 6 distinct pedestrians, and cars trips.
This section presents the results obtained for the following metrics: traffic queue size, car trip distance, car stop time, and communication metrics: sent packets, and packet loss. The traffic queue size is the number of cars queued per road at the intersections. The car trip distance is the distance ran by all cars, i.e., the summation of the individual car trip distances, in kilometers. The car stop time is the total stopped time of all cars, i.e., the summation of the individual car stopped times, in minutes. The communication metrics are explained later.
Excepting the communication metrics, only the results obtained for the cars are presented next. The pedestrians were not considered in the results, because the virtual semaphores do not control the pedestrians. In the graphics presented next, pull is synonymous of pull-based mode, push means push-based mode, and notls denotes that no virtual semaphores were used. The ratio R is defined as: R = number of pedestrians/number of cars. Recall that the notls mode was used only as reference, because it indicates a priori the optimal performance regarding the mobility of the cars.
To have an idea of the number of pedestrians crossing the intersections, Figure 9
shows, for different ratios R, the maximum, average, and minimum number of persons that crossed the twenty-five intersections with RSUs during a simulation run of five hundred seconds. As in the simulation scenario the cars always give way to the pedestrians on the crosswalks (i.e., a pedestrian never stops at a crosswalk to give way to a car), the graphics are the same for notls, push, and pull test modes, because the same mobility trace of pedestrians is used in these three test modes.
5.2.1. Average and Maximum Traffic Queue Sizes
shows the maximum, and average traffic queue sizes found at each road connected to the twenty-five intersections with RSUs. These results were obtained immediately before the end of the simulation (i.e., t ≈ 500 s). The average traffic queue sizes show no significant difference between the push and pull modes. When R is above 1, the average traffic queue sizes become larger with the use of VTLS than without using it.
The results also show that, in the three test modes, there were roads at the intersections with queue sizes of eight cars at least.
5.2.2. Car Trip Distance
shows the average distance rolled by each car during the simulation. The graphic is normalized to 100%, which corresponds to 1483.4 m. As expected, the best results were obtained without using the VTLS, where the cars reached a longer distance than the cars controlled by virtual traffic light systems. Moreover, the difference between the push and pull modes is negligible. As expected, the distance travelled by the cars decreases with the increment of the number of pedestrians, since the cars tend to be stopped longer in the crossing to let pass the pedestrians. Such situation becomes more notorious with the use of VTLS than without using any VTLS. This shows that the algorithms used by VTLS are less efficient than the one used by SUMO in terms of traffic fluidity at the intersections.
5.2.3. Car Stop Time
shows the average time that each car was stopped at the intersections or jammed in the traffic queues during the simulations. The graphic is normalized to 100%, which corresponds to 106.4 s. Once again, there is no significant difference between the push and pull modes. Considering the results obtained for the trip distance, this is an expected result. Indeed, the stop time of the cars increases with the number of pedestrians, since the cars tend to be longer stopped in the crossing to let pass the pedestrians. This situation becomes more notorious with the use of VTLS than without using it.
5.3. Communication Metrics
The results obtained for the number of sent packets and packet loss are presented and discussed next. The curves for the case of using no VTLS are not shown in the graphics, because in this test mode the number of packets sent by the nodes is always zero.
5.3.1. Sent Packets
shows the total number of packets sent by all nodes (cars, pedestrians, RSUs), as well as the packets sent partially by the pedestrians, cars, and RSUs. The graphic is normalized to 100%, which corresponds to 190,742 packets. It observed that, globally, the pull mode generated, in average, 3.9 (±0.6) times more packets than the push mode in all ratios R.
The results show that in the pull mode, the RSUs are the nodes that generate more packets, followed by the cars. In the push mode, the pedestrians are the nodes that generate more packets, followed by the RSUs, and the cars generate no communication traffic. In the push mode, the number of packets sent by the RSU does not change with the increment of the ratio R.
5.3.2. Packet Loss
The signal-to-interference-plus-noise ratio (SNIR) lost packets indicates the number of lost packets due to bit errors, caused by packet collisions or noise interferences at the destination receivers. A TxRx lost packet is a packet that was not transmitted neither received, because a packet arrived to the wireless interface precisely when another packet was being sent by this wireless interface. So, the TxRx parameter evaluates how often a wireless interface is receiving and transmitting packets at the same time, causing the loss of both packets. The total number of lost (unreceived) packets by a node at the lower communication layers is the sum of the total SNIR lost packet plus the TxRx lost packets in that node. The percentage of lost packets by SNIR and TxRx problems is calculated by the expression: (SNIRlostPkts + TxRxLostPkts)/(SNIRlostPkts + TxRxLostPkts + recvdPkts) * 100%, where SNIRlostPkts is the number of SNIR lost packets, TxRxLostPkts is the number of TxRx lost packets, and recvdPkts is the number of packets received by the wireless node. This metric can be used as an indirect indication of the bandwidth occupancy of the wireless channel, in that the higher is its value, the more occupied is the wireless channel used by the wireless communication modules.
shows the average percentage of the SNIR + TxRx lost packets of all nodes (pedestrians, cars, RSUs), using the push, and pull modes. The results show indirectly that the wireless channel bandwidth globally available in the simulated scenario is more occupied in pull mode than in push mode. Indeed, the difference in the average SNIR + TxRx packet loss between the pull and push mode increases with the ratio R, from 1.3 percentage points (p.p.) (R = 0.25) to 1.9 p.p. (R = 2.5). The results also revealed that the packet losses were almost all caused by SNIR problems, as the losses caused by TxRx problems were really quite negligible (<0.002%).
5.3.3. Application Message Loss
The average percentage of messages lost at the application layer was calculated too. For simplicity, this metric considers only the messages sent by pedestrians and cars that failed to reach the application layer of the RSUs. The messages sent by the RSUs that failed to reach the application layers of the pedestrians and cars were not considered. The percentage of lost messages is calculated by the expression: (sentPktPed + sentPktCar − recvdPktRSU)/(sentPktPed + sentPktCar) * 100%, where sentPktPed and sentPktCar are the total number of messages sent respectively by all pedestrians and cars, and recvdPktRSU is the total number of messages received by all RSUs from the pedestrians and the cars, and not from other RSUs. So, in push mode, this metric indicates the messages lost by the RSUs from the nearby pedestrians. In pull mode, it measures the messages lost by the RSUs from the nearby pedestrians and cars. The messages received by the RSU from pedestrians and cars out of range are ignored in this metric.
shows the results of the average message loss, in percentage, obtained with the push, and pull modes. The average application message lost is lower in the push mode than in the pull mode. This result is somewhat expected taking in consideration the results obtained for the SNIR + TxRx lost packets. The difference in the average message loss between the pull and push mode increases with the ratio R, from 0.031 p.p. (R = 0.25) to 0.19 p.p. (R = 2.5).