Simulation Results

The performance is evaluated by throughput, receipt ratio, registration times, and delay of safety messages. We set different stream bit rate and vehicle density in both protocols to compare performances.

Figure 8 shows the saturated transmission rate of RSU versus simulation time.

The saturated transmission rate means maximum available data rate that a device can send or receive in our proposed MAC and original 802.11p. We can see that simulation results are close to theoretical values, and our performance is twice more than 802.11p because our proposed MAC fully utilizes service channel; besides, vehicles need not send RTS/CTS to avoid collision. The gaps between theoretical results and simulated results in our proposed MAC are caused by mobility of vehicles and channel switch. For example, vehicles which move out of RSU’s transmission range will miss transmitting packet and vehicles which return to Control channel during RSU’s specific slot will lose transmitting packet, too. With regard to 802.11p, the gap is also caused by mobility of vehicles. In addition, we suppose random back off numbers in theoretical analysis are always the minimum number, so the theoretical results are optimal results, and that is the another reason causing the gap.

Figure 11 : Saturated transmission rate of RSUs versus simulation time

Figure 12 : Average throughput versus vehicle ID

Average throughput of each vehicle is shown in figure 9. In this simulation, vehicle density is 20 (vehicles/km/lane) and streaming bit rate is set as 280 (Kbps). It appears that average throughput of our proposed MAC almost meets demand of bit rate and outperforms 802.11p a lot. Similarly, figure 10 shows receipt ratio of demand.

When the request of streaming bit rate is 280 Kbps, our proposed MAC can receive

90% and original 802.11p only obtains 40% of total data amount. The phenomenon of uneven performances among different vehicles is caused by scheduling algorithm, which common FCFS is used in our proposed MAC in this simulation. In some cases, if a vehicle enters a high-load area of RSU, it might not get chance to satisfy its requirements before it exits. That is why the performances of some vehicles are poorer.

However, the difference of them is within 5%.

Figure 13 : Receipt ratio versus vehicle ID

Next, figure 11 and figure 12 show throughput and receipt ratio versus request streaming bandwidth. In this simulation, vehicle density is 20 (vehicles/km/lane), and each vehicle request 120~440 (Kbps) stream service. Obviously, our proposed MAC could offer more than 250 (Kbps) data rate, so receive ratio of 120 and 200 (Kbps) stream could achieve near 100%. However, in 802.11p, maximum throughput of each vehicle couldn’t get more than 120 (Kbps) and does not satisfy for all situations. In fact, most streaming video applications need more than 100 (Kbps) bandwidth.

High-quality videos even need 200 or 300 (Kbps) to support QoS. Therefore, in

current 802.11p protocol, in urban area where there are many vehicles, it is more difficult to offer entertainment service to most vehicles, and modifying 802.11p to enhance throughput requirement is necessary.

Figure 14 : Average throughput versus streaming bandwidth

Figure 15 : Receipt ratio versus streaming bandwidth

Now, we discuss the relationship between vehicle density and the performance.

Figure 13 shows average throughput in different vehicle density. In this simulation, streaming bit rate is set as 360 (Kbps). As vehicle density increases, the decrease in throughput is reasonable. It is because more vehicles share the total resources. Figure 14 is corresponding receive ratio results, and similarly, our proposed MAC is better than 802.11p. Regardless of vehicle density, performance of our proposed MAC is about twice better than the original 802.11p protocol.

Figure 16 : Average throughput versus vehicle density

Figure 17 : Receipt ratio versus vehicle density

In the following, we discuss how many times vehicles need to register to a new RSU till success. In figure 14, the index of y-axis indicates average registration times when a vehicle meets its n-th RSU. This is, the RSU which vehicle meets first is the vehicle’s first RSU, and then after the vehicle exits, the vehicle will meet its second RSU. At the beginning of simulation, all vehicles have not yet registered to RSUs, so they need to content with all the others to register successfully. As a result, the average number is higher than later RSUs which they would meet. As vehicle density increases, registration times would increase as well. Thereafter, when vehicles meet their second RSU, they need not content with so many vehicles for registration. When a vehicle meets its first and second RSU, other vehicles have not all finished their first registration, it can be regarded as initial state. After initial state, all vehicles have finished their first registration, so new coming vehicles just need to contend with other new coming vehicles and it will become a stable situation. In figure 18, we can observe that vehicles only need to register for approximately one time for the third

RSU and fourth RSU which can be regarded as stable state above. The results are consistent with our analysis in previous chapter. In our simulated environment, there can not be more than two vehicles entering a RSU’ range simultaneously in a cycle time. Here we set registration slots as 10 which is enough to handle in most cases, so the factor of vehicle density does not influence the result.

Figure 18 : Average registration times versus vehicle density

In figure 19, average delay of safety messages is shown as follow. This period is defined from the time an accident happened to the time all neighboring vehicles receive messages successfully. Simulation results show delay time in our proposed MAC is about 50 (ms) in average traffic situation and delay time in 802.11p is approximately 10 (ms). The value of 802.11p is less because the original protocol aims at reducing accidents, and that is why half of cycle time would be designed as CCH for high priority messages. As our previous analysis, average delay of safety messages is direct proportion with vehicle density, but vehicle density in our simulation is not heavy so that it does not reflect on the result well. The result of delay time is about half of cycle time, which is 50 (ms). However, 50 (ms) of delay time is under maximum allowable latency of safety messages (100 ms to 150 ms), which

shows the pursuit of safety would not be sacrificed to enhance throughput in our proposed MAC.

Figure 19 : Average delay of safety messages versus vehicle density

Chapter 5 Conclusion and Future