Chapter 3 The Proposed MAC Protocol
3.4 Safety Issue
Safety issue has always been a key point in VANETs development. For this reason, 802.11p designs half of synchronization interval to be CCH interval and in this interval all vehicles must return to Control Channel to learn about whether there is an important information or not. If there has been emergency event like car accident, vehicles can exchange safety information during CCH interval.
In our proposed MAC, when an emergency event happened, vehicle whose transmission is idle will send safety message to RSU in their specific slot directly. If vehicle’s transmission is busy, the vehicle will temporarily switch to Control Channel during its specific slot period to send safety message to RSU and then return to Service Channel to continue its original service. So when RSUs collect safety information, RSUs will broadcast collected information in the RSU’s specific slot.
Meanwhile, all vehicles will receive safety message because they must return to Control Channel during RSU’s specific slot. In this way, it can ensure our proposed
MAC still satisfies function of safety service.
Then we compare the performance of our proposed MAC protocol and 802.11p.
In the following, the delay time of safety messages will be analyzed. We define the delay time starts from the moment the accident happened to the time that neighboring vehicles all receive this safety message.
The parameters are listed below.
z delay time : the time from accident happened to the time that neighbor vehicles all receive it
z Ct : cycle duration
z D : average delay since a node starts to transmit during contention process z tb : duration of Beacon slot
z m : number of registration slot z tr : duration of registration slot z n : number of specific slot z ts : duration of specific slot
Average delay time of safety messages in 802.11p is shown as below:
(3)
Figure 7 : Vehicles’ channel states of emergency event in 802.11p
First part of left equation in (3) indicates that accident happened at SCH interval.
As shown as figure 7, if vehicle 1 has some emergency events at that time, so it switches to Control Channel and broadcasts safety messages constantly; however, vehicle 2 and 3 which stay in Service Channel will miss the message and could receive safety message at next CCH interval. Hence, the expected value of waiting time is half of CCH interval time, namely, quarter of Ct. Besides, D is average delay time when a node starts to transmit during contention process or back-off process. The second part of the left equation indicates that a vehicle which has accident wants to send safety message at CCH interval. Because at CCH interval all vehicles must stay in Control Channel, the delay time of safety message is only D. Usually, Ct is supposed to 100 (ms) and D is much less than Ct , so average delay time of 802.11p is approximately 12.5 (ms).
Figure 8 : Vehicles’ channel states of emergency event in our proposed MAC
Similarly, we discuss average delay time in two cases in our proposed MAC.
First, as shown in figure 8, if emergency event happened before vehicle’s own specific slot, this accidental vehicle could send safety message in its specific slot and then other vehicles could be informed in RSU’s specific slot. In this case, average delay time of safety message can be expressed as (4):
· ·
· · · (4)
The coefficient · · indicates the probability that emergency event happened before vehicle’s own specific slot, and later half part indicates expected value of delay time from emergency event happened to RSU’s specific slot.
Figure 9 : Vehicles’ channel states of emergency event in our proposed MAC
Second, as shown in figure 9, if emergency event happened after vehicle’s own specific slot in the same Beacon cycle, this accidental vehicle only can send safety message in next Beacon cycle during its specific slot and then other vehicles could be informed in next Beacon cycle during RSU’s specific slot. In this case, average delay time of safety message is expressed as (5):
· ·
· · · · (5)
The coefficient · · indicates the probability that emergency event happened after vehicle’s own specific slot, and later half part indicates expected value of delay time from emergency event happened to next RSU’s specific slot.
After calculating the sum of (4) and (5), we can get average delay time as (6):
· (6)
Because · is less than Ct more, if Ct is set as 100 (ms), the average delay time is about 50 (ms) in our proposed MAC. Even in heavy traffic situation discussed in previous registration phase, if there are 100 vehicles under a RSU’s transmission range, the average delay time is about 75 (ms). Although delay time in our proposed MAC is longer, it still does not influence safety. Studies shows maximum allowable delay of safety message is 100~150 milliseconds and driver’s perception time is 500~1000 milliseconds. So no matter it is 802.11p or our proposed MAC, they all satisfy safety requirements.
3.5 Throughput analysis
3.5.1 Throughput Analysis for 802.11p
In IEEE 802.11p, the analytical model developed by G.Bianchi [14] is adopted here. Follows are the parameters in this analysis:
Table 2 : Parameter settings in analysis
τ the probability that a device will transmit a packet at an arbitrarily chosen slot time
P the probability of a packet being collided
Ptr the probability of at least one device transmits at the considered slot Ps the probability a transmission is successful
pSlotTime average time that a slot being empty
Ts average time used for successful transmission Tc average time wasted by a packet collision S1609 saturation throughput of IEEE 1609/802.11p
According to bidimensional Markovian model in [14], the probability τ that a device will transmit a packet at an arbitrarily chosen slot time and the probability P of a packet being collided are shown as below:
∑ (7)
1 1 (8)
Then, we can calculate the probability at least one device transmits at the considered slot according to (7) and (8); obviously, the probability Ptr is total probability 1 subtract the probability that all n devices do not transmit at the considered slot. It can be expressed as follow:
1 1 (9)
Next, the probability that a transmission is successful indicates only one device transmits at considered slot and other n-1 devices do not transmit at the same slot. The probability Ps can be expressed as (10):
1
110
Based on above expressions, the saturation throughput of DCF MAC is given by:
(11)
The coefficient 1/2 in (11) indicates SCH interval is only half of the channel time.
The numerator represents transmission time for sending a data, and the denominator represents average time wasted for a transmission. The unit of saturation throughput is a percentage which means maximum useful time for transmitting a data in a reservation. Besides, let , , , and denote the time to transmit an RTS, CTS, DATA , and ACK. So Ts and Tc with RTS/CTS are shown as follows.
12
13
Ts and Tc without RTS/CTS are shown as follows.
14
15
3.5.2 Throughput Analysis for our proposed MAC
In our proposed MAC, the saturation throughput can be expressed as:
· · (16)
Similarly as analysis of 802.11p, the coefficient in (16) indicates available transmission time ratio during a Beacon cycle. As discussed in previous chapter, vehicles can switch to Service Channels to transmit data all the time except Beacon slot interval ( ) and RSU’s specific slot interval ( ).
That is the maximum number of packet can be transmitted in a reservation.
It is expressed as (17). The numerator is reservation time and the denominator indicates the total duration to transmit a packet.
(17)
Above saturation throughput analysis for both protocols can be extended to multiple SCHs environment. However, because RSUs only have one interface for SCHs, saturation throughput of R2V communications will not increase when service channel increase. In fact, other bandwidth can be used by V2V communications.
Chapter 4 Performance Evaluation
In this chapter, performance of our proposed MAC protocol and original 802.11p MAC are evaluated by C/C++ and the results will be compared and discussed later.
4.1 Simulation Environment
The simulation environment is a quadratic road system as shown in figure 7.
There are two lanes and each length of the edge is 0.5 (Km). Four RSUs are placed in the corner of square and their transmission range are 250 (m) so that four RSUs can cover all vehicular environment. And it is a closed system, no entrances or exits exist in the vehicular environment.
Figure 10 : Simulation environment
At the beginning of simulation, all vehicles are placed in the quadratic road system evenly, and move in anticlockwise direction. Speeds of vehicles are 60Km/hr and 80Km/hr respectively in outside lane and inside lane. Then, all vehicles request for streaming service through RSUs from the Internet. When a vehicle exits from its original RSU and enters the next RSU’s coverage range, it will request again to keep streaming service running. The bit rate of stream is set from 120Kbps to 440Kbps in different simulated situations and packet size of data is 1024 bytes. The download scheduling algorithm in RSU for 802.11p is round-robin for all vehicles, and FCFS for our proposed MAC. Namely, in our proposed MAC, RSU will finish a demand of the current vehicle and then serve the others. The reason is that 802.11p is a distributed protocol so that it can’t serve vehicles centralizedly. Next, in this simulation, in order to make it brief, we use two channels to transmit. One channel is for CCH and the other is for SCH. It can be easier to extend to multiple service channels in vehicular network environment.
The parameters used in the simulation are listed in table 3. Table 4 and 5 are EDCA parameter in 802.11p, and to calculate CWmin and CWmax the values aCWmin = 15 and aCWmax = 1023 have to be used. Here we adopt AC1 for streaming packets and AC3 for safety messages.
Table 3 : Simulation parameters
Stream bit rate 120~440 Kbps
Cycle time 100 ms
Slot interval (proposed MAC) 0.5 ms Registration slot number 10
Table 4: EDCA parameter set used on the CCH
AC aCWmin aCWmax AIFS
0 aCWmin aCWmax 9
1 (aCWmin+1)/2-1 aCWmin 6
2 (aCWmin+1)/4-1 (aCWmin+1)/2-1 3 3 (aCWmin+1)/4-1 (aCWmin+1)/2-1 2
Table 5 : EDCA parameter set on the SCH
AC aCWmin aCWmax AIFS
0 aCWmin aCWmax 9
1 aCWmin aCWmax 6
2 (aCWmin+1)/2-1 aCWmin 3
3 (aCWmin+1)/4-1 (aCWmin+1)/2-1 2
4.2 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 Work
In this thesis, we propose a novel MAC protocol to enhance system throughput.
The main improvement is that we enhance channel utilization compared with original 802.11p whose channel utilization is half at best. Then, we discuss registration process, channel reservation process, transmission data or safety message process, and analysis performance such as registration failure probability, delay time of safety message, and throughput. In our simulation, we prove that our throughput outperforms IEEE 802.11p. Moreover, compared in different situations, throughput and data receipt ratio in our proposed MAC are better. Besides, we also show average delay time of safety message in these two protocols. Results show the performance of 802.11p is better, but both simulation results are in accordance with our theoretical analysis and both are under maximum allowable latency.
In this thesis, we only consider V2R environment, i.e., there must be RSUs equipped on the road. However, it is impossible to equip RSUs everywhere, especially in rural area. In that case, one of the vehicles has to act as cluster head and manage all the registration and reservation. Therefore, how to coordinate between RSU-based and cluster-based environment will be a future work. Furthermore, because our proposed MAC is a centralized structure, scheduling algorithm and admission control will be critical issues. How to schedule different flows or make admission decision according to the characteristic of VANETs applications can also be future work, too.
References
[1] IEEE P1609.1, “Wireless Access in Vehicular Environments (WAVE) Resource Manager,” Draft Standard, 2007.
[2] IEEE P1609.2, “Wireless Access in Vehicular Environments (WAVE)
Security Services for Applications and Management Messages,” Draft Standard, 2007.
[3] IEEE P1609.3, “Wireless Access in Vehicular Environments (WAVE) Networking Services,” Draft Standard, 2007.
[4] IEEE P1609.4, “Wireless Access in Vehicular Environments (WAVE) Multi-Channel Operation,” Draft Standard, 2007.
[5] IEEE Standard for Information technology , “Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 3: Wireless Access in Vehicular Environments (WAVE),” IEEE Draft
Amendment P802.11p/D1.0, Feb, 2006.
[6] Vehicle Safety Communications Project, Final Report, DOT HS 810 591, April, 2006.
[7] Zang Y, Stibor L, Walke B, Reumerman HJ, Barroso, “A Novel MAC Protocol for Throughput Sensitive Applications in Vehicular Environments,” IEEE VTC, 2007,pp. 2580–2584.
[8] Biplab S, “A MAC Protocol for Vehicle to Roadside Networks,” IEEE ICC, 2008.
[9] Jin Z, Qian Z, Weijia J, “A Novel MAC Protocol for Cooperative Downloading in Vehicular Networks,” IEEE GLOBECOM, 2007.
[10] Ehsan K, Farid A, “A Modified 802.11-Base MAC Scheme to Assure Fair Access for Vehicle-to-Roadside Communication,” Computer Communication, VOL. 31,
July, 2008, pp. 2898-2906.
[11] Hang S, Xi Z, “Clustering-Based Multichannel MAC Protocols for QoS Provisionings Over Vehicular Ad Hoc Networks, ” IEEE JVT, VOL. 56, NOVEMBER, 2007, pp. 3309-3323.
[12] Zaydoun Y, “Media Access Technique for Cluster-Based Vehicular Ad Hoc Networks,” IEEE VTC, 2008.
[13] Fan Y, Subir B, “A Self-Organizing MAC Protocol for DSRC based Vehicular Ad Hoc Networks,” IEEE ICDCSW, 2007.
[14] Giuseppe B, “Performance Analysis of IEEE 802.11 Distributed Coordination Function,” IEEE JSAC, vol. 18, March, 2000.