A Dedicated Multi-Channel MAC Protocol Design for ... - IEEE Xplore

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the WCNC 2010 proceedings.

A Dedicated Multi-channel MAC Protocol Design for VANET with Adaptive Broadcasting Ning Lu1, Yusheng Ji2, Fuqiang Liu1, and Xinhong Wang1 1

Dept. of Electronics and Information Engineering, Tongji University, Shanghai, China 2 National Institute of Informatics, Tokyo, Japan Email: [email protected], [email protected], {liufuqiang, wangxinhong}@tongji.edu.cn

Abstract—Vehicular wireless communication should be able to provide vehicles with reliable and efficient data transmissions for various applications, especially safety applications. We present a dedicated multi-channel MAC protocol that has an adaptive broadcasting mechanism, specifically designed to provide collision-free and delay-bounded transmissions for safety applications under various traffic conditions. Besides defining the implementation of this protocol, we conducted simulation evaluations showing that it has promising performance on critical statistics. Keywords-Vehicular ad hoc network; Multi-channel MAC; IEEE 802.11p ; Broadcasting

I.

INTRODUCTION

Many advanced wireless technologies are being applied to transport systems to make them safe, intelligent, and efficient. In particular, the Vehicular ad hoc network (VANET) focuses on vehicle to vehicle (V2V) communication and vehicle to infrastructure (V2I) communication [1] and makes it possible to provide a variety of safety applications (such as collision warning and traffic coordination) and non-safety applications (such as Internet access and multi-media data transfer between vehicles). The MAC protocol for VANET is critical to provide efficient and reliable medium access and meanwhile is difficult to design due to fast topology changes, high node mobility [2] and different Quality of Service (QoS) requirements—safety applications require high reliability and bounded delay while non-safety applications are throughput sensitive [3]. In 1999, the U.S. Federal Communications Commission (FCC) allocated seven 10-MHz channels in the 5.9 GHz band, including one control channel (CCH) and six service channels (SCHs) for safety and non-safety applications respectively, and this move has encouraged researchers to design a multi-channel structure for the MAC protocol. By partitioning different services and terminals on different channels, a multi-channel MAC protocol can achieve higher communication throughput and lower network latency [4]. In this paper, we propose a dedicated multi-channel MAC protocol, called DMMAC, for VANET. DMMAC is based on a hybrid channel access mechanism exploiting both the advantages of TDMA and CSMA/CA. The essential part of DMMAC is a mechanism named adaptive broadcasting.

Adaptive broadcasting provides collision-free and delaybounded transmissions for safety messages, and it enhances the adaptability of the MAC protocol to different traffic density conditions. These two issues have not been well addressed in most of the existing multi-channel MAC designs. In DMMAC, all vehicles are equipped with a single half-duplex radio transceiver. This is not just a cost concern: multiple radios implemented with current hardware may suffer from too much cross-channel interference [5]. The rest of this paper is organized as follows. We review related work in section II. Section III outlines DMMAC, and section IV presents the details of adaptive broadcasting. Section V gives the performance evaluation and section VI concludes the paper. II.

RELATED WORK

The IEEE 802.11p protocol, which is being standardized as a new version of 802.11 for wireless access in the vehicular environment (WAVE), and the IEEE 1609.4 [6] provide an important multi-channel MAC design (WAVE MAC for short) for VANET. In WAVE MAC, the channel access time is divided into alternating fixed-length intervals called CCH interval and SCH interval. During the CCH interval, all vehicles must monitor the CCH for exchanging safety messages and other control packets. During the SCH interval, vehicles participating in the WAVE basic service set exchange the non-safety application data on SCHs. In spite of its great influence, the current version of WAVE MAC is not fully applicable to VANET because the pure contention-based channel access scheme cannot guarantee the QoS of safety and other real-time applications in high-density urban scenarios. Much research has gone into devising a more feasible multi-channel MAC protocol for VANET. The proposal in [7] is called the Vehicular MESH Network (VMESH) protocol. This protocol uses a distributed beaconing scheme and reservation-based channel access on SCHs to enhance channel usage efficiency. However, VMESH does not guarantee reliable delivery of safety messages and the devices in the network need centralized coordination. T.K. Mak et al. [8] proposed a centralized multi-channel MAC design with time division and spatial division schemes to enable every vehicle to send safety packets with short delay, and to avoid packet collisions from hidden terminals. Another approach to increase

Supported by the Chinese Important National Science & Technology Specific Project (No. 2008ZX03003-005) and the National Natural Science Foundation of China (60904068/F030209)

978-1-4244-6398-5/10/$26.00 ©2010 IEEE


spatial reuse is that of VANET Multi-channel MAC (VMMAC) in [9]. By using the directional antenna and coordinating as in WAVE MAC, VMMAC, in spite of its implementation complexity, allows pairs of terminals with idle beams to connect in the same channel to overcome the limitation on the number of channels in realistic scenarios. The proposal in [10] is a clustering-based multi-channel MAC protocol with a QoS guarantee for safety and non-safety applications. The collection and forwarding of safety messages by cluster-head and real-time packets between cluster-heads help to improve performance. Reference [3] proposes a token ring MAC protocol, called MCTRP, for the inter-vehicle communications. Depending on the token ring coordination, MCTRP provides fast delivery of emergency messages and higher throughput. Nevertheless, the performance of the above two designs is achieved at the expense of equipping two radios on each vehicle. Although TMMAC in [11] is not directly designed for VANET, some relevant features are still applicable, including the TDMA-based communication window for reliable packet delivery and the channel negotiation scheme during the ATIM (Ad hoc Traffic Indication Messages) window. Since reliable broadcast on the common channel is disabled in TMMAC, such a design cannot be used for safety applications. III.

well as other details of adaptive broadcasting is presented in the Adaptive Broadcasting Implementation Protocol (ABIP) in the next section. The CRP uses CSMA/CA as its channel access scheme. During the CRP, vehicles negotiate and reserve the resources on SCHs for non-safety applications. Because of the fixedlength CCHI, the length of the CRP depends on the ABFL of the vehicle. Therefore, vehicles may enter the CRP asynchronously. To avoid potential collisions, such as a collision when vehicle 1 sends a packet to vehicle 2 during its CRP while vehicle 2 is still in the ABF, some vehicles may have several additional slots named Virtual Slots after entering the CRP. The Virtual Slot operation is described in the next section in relation to the ABF operation. The Contention-based Reservation Implementation Protocol (CRIP) describes the way in which vehicles conduct channel negotiation and selection. Despite that DMMAC and TMMAC have different channel selection algorithms, DMMAC’s channel negotiation is similar to TMMAC’s three-way handshake during the ATIM window. As shown in Figure 2, a pair of vehicles needs to exchange three types of packets, i.e., CRP-REQ, CRP-RES, and CRPACK, to complete one negotiation. Moreover, the vehicle can use the CRP-BRD packet for emergency safety announcements in the CRP. However, we shall not deal with CRIP in this paper and focus only on ABIP.

OVERVIEW OF DMMAC

Figure 1 shows the overall architecture of DMMAC. The channel coordination scheme is similar to WAVE MAC: the channel access time is equally divided into Sync Intervals, and each Sync Interval consists of a CCH Interval (CCHI) and an SCH Interval (SCHI) of the same length. In DMMAC, the CCHI is further divided into an Adaptive Broadcast Frame (ABF) and a Contention-based Reservation Period (CRP).

Figure 2. Channel negotiation between B and C in the CRP

SCHI also divides the channel access time into equal duration slots. All the slots on the same channel are grouped into one Non-Safety Application Frame (NSAF). Because of cross-channel interference, Available SCHs (ASCHs) are defined and represent a set of SCHs in which any two channels have negligible cross-channel interference. All NSAFs in one SCHI can be reserved during the CRP in the same Sync Interval for providing collision-free transmissions for nonsafety related data. IV.

Figure 1. Architecture of DMMAC

The ABF consists of time slots, and each time slot is dynamically reserved by an active vehicle (the vehicle whose communication equipment has started working) as its Basic Channel (BCH) for collision-free delivery of the safety message or other control messages. The number of time slots contained in the ABF is called the ABF Length (ABFL). There is no uniform ABFL for the entire network. Although the ABFL of the vehicle must be an element of , , where and are predefined minimum and maximum ABFLs in the system, each vehicle can adjust its ABFL in every CCHI according to the network topology of its neighborhood. Such an adjustment as

ADAPTIVE BROADCASTING IMPLEMENTATION

The Adaptive Broadcasting Implementation Protocol is a set of rules for regulating vehicles’ access behaviors in the ABF, including how to reserve a slot as BCH, how to adjust the ABFL, how to determine whether to add virtual slots after the end of the ABF. A. BCH Reservation process Without centralized coordination, a distributed way is needed to let the vehicle reserve its BCH. RR-ALOHA [12] is such an approach for dynamic slot reservation, and we adopted some of its ideas to handle the BCH reservation problem. Before we present how reservation works, we should present some definitions. i represents the identifier of the vehicle. Let be the set of one-hop neighbors of vehicle i and , where is the set of all vehicles within onehop area of vehicle i. Similarly, denotes the set of all


neighbors of vehicle i within two hops and we have . Every active vehicle in the network should reserve a fixed slot in the ABF as its BCH for safety messages or other control packets delivery. It is obvious that a vehicle’s BCH cannot be reused by its neighbors within two hops, otherwise collisions will occur. To prevent this from happening, ABIP requires that every packet transmitted by the vehicle in the ABF should contain additional information, called Frame Information (FI). The content of FI is shown in Figure 3. ID indicates the identifier of the vehicle that sends this FI. Slot Information (SI) contains the status (FREE or BUSY) of the corresponding slot in the ABF recorded by the vehicle itself. There are SIs in FI mapping to slots in the ABF.

say FI-2 in slot 2 and FI-3 in slot 4, vehicle 1 could select an available slot for BCH in its ABF, e.g., slot 3. After that selection, vehicle 1 should keep listening to make sure slot 3 is still available until the end of slot 2. After its first transmission in slot 3, it will use this slot for packet delivery during its ABF if no collision occurs. After the transmission on its BCH has been completed, vehicle 1 can learn of the outcome of this transmission from all FIs it receives before its next transmission. Let denote the slot number of the BCH of vehicle i in the ABF. Rule 3. For every that vehicle i has received after its transmission and before the next one, if _ _ and _ _ do not hold, the transmission is considered to have failed. In this case, vehicle i should restart the BCH reservation process. It is easy to see that the vehicle can obtain the outcome of its packet delivery, not just the outcome of its transmission, but also whether its one-hop neighbors have successfully received the packet. Because of this high reliability, broadcasting in ABFs is suitable for delivering safety messages.

Figure 3. Information recorded in FI

Rule 1. Within one slot, if a packet has been successfully received or transmitted by the vehicle, this slot is marked as BUSY; otherwise, it is FREE. For the BUSY slot, FI also needs to contain the identifier of the transmitting vehicle. By listening through slots, vehicle i can learn the slot occupation of the ABF within its one-hop neighborhood. , records We indicate the FI sent by vehicle j as . the slot occupation within one-hop neighborhood of vehicle j. By receiving all , vehicle i can obtain slot occupation information within its two hops. Rule 2. To reserve a BCH not used within two hops, the vehicle without BCH should listen through slots to get the slot occupation information within its two hops and then compute its Length Information including the ABFL by perceiving the FIs it has received. After that, it randomly selects a FREE slot as its BCH from its ABF and keeps listening to check whether its BCH is still available before its first transmission. If not, the vehicle should restart this process. Rule 2 describes how the vehicle makes a reservation for BCH. The computation of ABFL is described in the next subsection. In the topology shown in Figure 4, vehicle 1 is a new active vehicle without BCH. The BCH reservation process of vehicle 1 is illustrated in Figure 5.

Figure 4. Given topology for vehicles

Vehicle 1’s listening process runs from the beginning of slot 2 in CCHI n and to the end of slot 1 in CCHI n+1. By inspecting the FIs it has received from its one-hop neighbors,

Figure 5. BCH reservation process of vehicle 1

B. Computation of ABFL ABIP requires that vehicle i must stay in its ABF until all vehicles in have finished the reliable broadcast on their own BCH. After that, vehicle i ends its ABF and enters the CRP. For vehicle i, the Active Length (AL) is given as , . indicates that after slots from the beginning of the ABF, all the vehicles in have finished their transmissions in the current ABF. We can get directly from , i.e., the length from the first slot to the last slot labeled as BUSY. It seems that can be defined as for the reason that all vehicles in have finished the reliable broadcasting process. However, we cannot treat the AL as the ABFL. For a new element vehicle j in , if there is no available slot as BCH for vehicle j in , a FREE slot after is selected. Definitely, the ABF of vehicle i should , or else vehicle i cannot be guaranteed that it will contain . On the other hand, correctly receive the packet from vehicle j can reserve one of the slots after the maximum AL of vehicles in its one-hop area (MAL), because that slot has not been used within two hops of vehicle j. Since the one-hop neighborhood of vehicle j is within two hops of vehicle i, to let be in the ABF of vehicle i, we should have


, , where represents the number of slots prepared in advance for new reservations. How can we obtain the largest AL within two hops for vehicles? ABIP requires every vehicle to record the largest AL within its one-hop area in MAL of FI. The vehicle can easily get the MALs from FIs it has received. To do so, the vehicle can eventually obtain the largest AL within two hops just by comparing MALs from FIs. Let be the set of FIs sent by vehicles in . Rule 4. For vehicle i, should contain the value of : , if _ , _ , ; otherwise, . In the ABF of vehicle i, all vehicles in including new ones can conduct a reliable broadcast. In the topology in Figure 4, assume that all vehicles have finished the BCH reservation process. Figure 6 shows the status of channel access and the length information for each vehicle in the current CCHI. Take vehicle 1 for example. Vehicle 2 and vehicle 3 are one-hop neighbors of vehicle 1. So the ABFL of vehicle 1 in the current CCHI lies on the MAL of these three vehicles. Note that is used to set a limitation on the ABFL, so that DMMAC can guarantee the minimum CRP length. If the vehicle’s ABFL reaches , the vehicle should adjust its transmitting power to reduce its radio range because it cannot prolong its ABF for potential reservations.

Figure 6. Status of channel access and length information

C. Virtual Slot operation After the ABF, a vehicle entering the CRP can contend to send the CRP-REQ or CRP-BRD. The Virtual Slot operation at the beginning of the CRP acts as a coordination scheme for avoiding potential collisions caused by asynchronous ABFs. Rule 5. If vehicle i wants to send a packet during its CRP, it must wait at least until all vehicles in have ended their ABF. Rule 5 makes sense because if there is a one-hop neighbor that hasn’t finished its ABF yet, the current transmission of vehicle i would likely interfere with the adaptive broadcasting of that neighbor. Let be the maximum ABFL within onehop area of vehicle i. represents that after slots, vehicle i has the right to contend to send. During the period from the end of to the end of , vehicle i must keep silent. As a result, we call the time slots during this period as Mute Slots,

and the total number of such slots is . Like the calculation of , vehicle i can get from the FIs. Rule 6. For vehicle i, should contain the value of : _ , . After the mute slots, the vehicle can send the CRP-BRD packet without collision. However, when it comes to the CRPREQ packet, if the receiver gets a CRP-REQ packet in a mute slot, it cannot send a CRP-RES packet to the sender as a response. Consequently, if vehicle i wants to send a CRP-REQ during the CRP to any of its neighbors, it must wait at least until all vehicles in have ended their ABF. This is because when all vehicles within two hops of vehicle i end their ABF, the one-hop neighbors of vehicle i must have finished their mute slots if they have any. Let be the maximum ABFL within the two hops of vehicle i. Similarly, vehicle i can get from the FIs: _ , . From the end of to the end of , vehicle i can only send the CRP-REQ to part of its one-hop neighbors. As a result, we call the time slots during this period as Limited Slots, and the total number of limited slots is . Rule 7. Vehicle i can send the CRP-REQ to vehicle j, , slots from the beginning of the ABF. after Mute slots and limited slots are called Virtual Slots, because the vehicle has actually ended the TDMA process in these slots. The function of virtual slots is to coordinate the transmissions of vehicles entering the CRP asynchronously. For example, in Figure 6, vehicle 4 has two mute slots after its ABF and no limited slots. Vehicle 4 should keep silent in mute slots to make sure it does not interfere with the ABF of vehicle 3. Vehicle 5 has two limited slots, and it can send a CRP-BRD or CRP-REQ to vehicle 6 during limited slots. However, according to Rule 7, it cannot send the CRP-REQ to vehicle 4. D. Active Re-Reservation process When a vehicle leaves the current network, its BCH might be available for others to use. ABIP requests the vehicle in the network to conduct the Active Re-Reservation (ARR) process to adjust its BCH to the one with the smaller slot number. From the perspective of the whole network, the ARR process makes the network adjust its ABF to a relatively short one when network density is low. The ABFL is directly related to the AL, and the vehicle in the network should make its AL as short as possible. It is clear that depending on its own ARR process, the vehicle can shorten its AL only when its BCH happens to be the last occupied slot in the ABF of the vehicle. This limitation stated in Rule 8 reduces the unnecessary ARR processes of vehicles. Rule 8. If vehicle i detects an available slot, marked as , and the conditions , and are satisfied, vehicle i will start its ARR process by sending with _ , _ _ , and _ _ . If a new vehicle within two hops of vehicle i wants to reserve as its BCH at the same time, a collision will occur. To prevent collisions, vehicle i should declare its ARR process in . should be labeled as BUSY to let the new vehicles within the one-hop area know that is not available. For two-hop new neighbors, Rule 9 can help to eliminate conflicts.


Rule 9. For every that vehicle j has received, if and _ _ , vehicle j sets 1, _ _ and _ _ . that vehicle i has received from the Rule 10. For every start of its ARR process to the next , if _ _ and _ _ , the reservation for is successful; otherwise, the ARR process of vehicle i fails.

The simulation scenario is a mobile one with a start as the sparse scenario shown in Figure 8 and an end as the dense scenario shown in Figure 9. At the beginning, the distance between the vehicles is 150 m. The vehicles move at the speed of 30 m/s until the distance between the vehicles becomes 10 m at the end. Totally, there are 30 vehicles in the simulation.

Figure 8. Sparse scenario

Figure 7. Three cases of potential conflict

V.

PERFORMANCE EVALUATION

In this section, we evaluated the performance of the adaptive broadcasting mechanism in DMMAC in NS-2 [13] and got promising results. The parameters for simulation environment are listed in Table I. TABLE I. Channel bandwidth Sync Interval CCH Interval

SYSTEM PARAMETERS FOR SIMULATION 10 Mbps 100 ms 50 ms

Transmission range Vehicle velocity Slot duration

250 m 30 m/s 1 ms

Figure 9. Dense scenario

Although ABIP can provide each vehicle with a contentionfree opportunity for data transmission in CCHI without collision, the vehicles still need to contend for slot reservation, especially when many vehicles want to reserve the BCH at the same time. As a result, it may take several Sync Intervals for the vehicle to complete the BCH reservation process. In order to learn the status of the system—how many vehicles have finished slot reservation with time flies—in different traffic density, static scenarios as shown in Figure 8 and Figure 9 are both used for simulation. 30

Average number of vehicles that have successfully accessed on the BCH

25

20

15

10

SFR=2• SFR=3• SFR=2• SFR=3• SFR=3• SFR=4•

5

0 0

5

ABFLmin=10 ABFLmin=10 ABFLmin=15 ABFLmin=15 ABFLmin=20 ABFLmin=20

10 15 20 Number of Sync Intervals past in the simulation

25

30

Figure 10. Results of BCH reservation in sparse scenario 30 Average number of vehicles that have successfully accessed on the BCH

Figure 7 shows the slot occupation information in CCHI n+1. According to Rule 9, after vehicle A started the ARR process in CCHI n, _ 3 _ and _ 3 _ need to be labeled as and respectively in case 1. When vehicle E sends its first FI in slot 3 in CCHI n+1, clearly in _ 3 _ will be rewritten as according to Rule 1. By receiving in CCHI n+1, vehicle A can learn of the failure of its ARR process from Rule 10. In case 2, vehicle E wants reserve slot 6 as its BCH in CCHI n+1. However, it will find that slot 6 is not available from for _ 6_ according to Rule 2. In case 3, vehicle E is not a new vehicle but one wants to change its BCH to slot 6 in CCHI n, like vehicle A. In this circumstance, _ 6 _ is labeled as once vehicle B receives in CCHI n. Hence, the subsequent reception of by vehicle B cannot change _ 6 _ from to according to Rule 9. Consequently, vehicle A will get the right to adjust its BCH to slot 6. We can see from the whole ARR process that the vehicle should wait for all of its one-hop neighbors’ feedback to check whether the new BCH is available and such coordination is critical for avoiding conflicts. ABIP enables all vehicles in the network to adjust the length of their ABFs in accordance with network density. As network density increases, the time used for reliable broadcast in CCHI will increase, which leads to there being a relatively short period for the CRP. When network density decreases, vehicles will have more time to negotiate for non-safety applications. This topology-dependent nature of ABIP makes it a viable solution for VANET.

25 20 15 SFR=2• SFR=3• SFR=2• SFR=3• SFR=3• SFR=4•

10 5 0 0

10

ABFLmin=10 ABFLmin=10 ABFLmin=15 ABFLmin=15 ABFLmin=20 ABFLmin=20

20 30 40 50 60 70 80 Number of Sync Intervals past in the simulation

90

Figure 11. Results of BCH reservation in dense scenario

100


From Figure 10 and Figure 11, we can see that and are two critical parameters for the BCH reservation process. In the sparse scenario, although there is little difference among the results of different cases, it is obvious that it takes a relatively shorter time for all vehicles to complete the BCH reservation with a larger . This is because a large initially makes the reservation less competitive. Since works in the same way as in the sparse scenario, we focus on the function of in the dense scenario. In the case of 2, the average number of vehicles that have reserved the BCH reaches a constant value less than the total number of vehicles. The fact that some vehicle cannot complete the reservation represents continuous conflicts in the slots prepared for new reservations, as mentioned in Section IIIB. With the increment of , such slots become able to accommodate all new reservations. As shown in Figure 11, the system has a very good performance when 4 and 20. 30 Average number of one-hop neighbors 20

ABFL

45

30

10

Average ABFL ABFL of one vehicle SFR=3, ABFLmin=15 ABFLmax=45

15 0

100

200 300 400 500 Number of Sync Intervals past in the simulation

Average number of one-hop neighbors

60

0 600

Figure 12. Average ABFL and number of one-hop neighbors

fluctuation in the safety messages delivery ratio through the simulation time. As network density increases, the performance of DMMAC decreases slightly only when the vehicles rereserve the BCH because of the change in network topology. In contrast, the performance of WAVE MAC grows steadily worse. VI.

This paper presented a dedicated multi-channel MAC (DMMAC) protocol for VANET. DMMAC’s adaptive broadcasting mechanism enables every vehicle in the network to have a chance to conduct collision-free and delay-bounded transmission for safety applications. DMMAC can adapt itself to different traffic conditions because it has a dynamic TDMA length in CCHI. Simulations show that DMMAC’s adaptive broadcasting mechanism performs well. Moreover, simulation results prove that DMMAC outperforms current WAVE MAC in terms of delivery ratio of safety packets. We are currently conducting a more accurate quantitative analysis of the DMMAC protocol. REFERENCES [1]

[2]

[3]

[4]

1

[5]

Delivery ratio of safety packets

+ DMMAC

0.8

for average

0.6

[6]

0.4

[7]

0.2

0 0

x WAVE MAC

[8] 100

200 300 400 500 Number of Sync Intervals past in the simulation

600

Figure 13. Delivery ratio of safety packets

The mobile scenario is utilized to obtain the status of the ABFL adjustment with the changes of network topology for all vehicles. Figure 12 shows the topology changes in terms of average number of one-hop neighbors. Correspondingly, Figure 12 also shows the ABFL of every vehicle and the average ABFL in the network through the simulation time. The peaks of the average ABFL curve represent the increase in ABFL as the network becomes denser and the slopes after the peaks reflect the decrease in ABFL due to the ARR process. It can be seen that the ABFL for reliable broadcasting can be adjusted well in accordance with the network topology changes. We also compared DMMAC with WAVE MAC in terms of their safety packets delivery performance. Figure 13 shows the

CONCLUSION

[9]

[10]

[11]

[12]

[13]

Y. Toor, P. Muhlethaler, and A. Laouiti, “Vehicle Ad Hoc networks: applications and related technical issues,” IEEE Communications Surveys & Tutorials, vol.10, No.3, 3rd quarter 2008. H. Menouar, F. Filali, and M. Lenardi, “A survey and qualitative analysis of MAC protocols for vehicular ad hoc networks,” IEEE Wireless Communications, vol. 13, No. 5, pp. 30-35, 2006. Y. Bi, K.H. Liu, X. Shen, and H. Zhao, "A Multi-Channel Token Ring MAC Protocol for Inter-Vehicle Communications", in Proc. IEEE Globecom '08, New Orleans, LA, USA, Nov. 30 - Dec. 4, 2008. J. Mo, H.-S.W. So, and J. Walrand, “Comparison of Multichannel MAC Protocols,” IEEE Transactions on Mobile Computing, vol. 7, No. 1, pp. 50-65, January 2008. V.Rai, F. Bai, J. Kenney, and K. Laberteaux, “Cross-Channel Interference Test Results: A report from the VSC-A project,” IEEE 802.11 11-07-2133-00-000p, July 2007. IEEE P1609.4-2006, IEEE Trial-Use Standard for Wireless Access in Vehicular Environments－Multi-channel Operation, November, 2006. Y. Zang, L. Stibor, B. Walke, H.-J. Reumerman, and A. Barroso, "A Novel MAC Protocol for Throughput Sensitive Applications in Vehicular Environments," in Proc. IEEE 65th Vehicular Technology Conference, pp. 2580-2584, 2007. T.K. Mak, K.P. Laberteaux, R. Sengupta, and M. Ergen, “Multichannel Medium Access Control for Dedicated Short-Range Communications,” IEEE Transcation on Vehicular Technology, vol. 58, issue 1, pp. 349366, Jan 2009. X. Xie, F. Wang, K. Li, P. Zhang, and H. Wang, "Improvement of Multi-Channel MAC Protocol for Dense VANET with Directional Antennas," in Proc. IEEE WCNC '09, April, 2009. Hang Su, Xi Zhang, “Clustering-Based Multichannel MAC Protocols for QoS Provisionings Over Vehicular Ad Hoc Networks,” IEEE Transactions on Vehicular Technology, vol. 56, No. 6, pp. 3309--3323, November 2007. J. Zhang, G. Zhou, C. Huang, S. Son, and J. Stankovic, “TMMAC: An Energy Efficient Multi-Channel MAC Protocol for Ad Hoc Networks,” in Proc. IEEE ICC '07, pp. 3554-3561, June 2007. F. Borgonovo et al., “ADHOC MAC: A New MAC Architecture for Ad Hoc Networks Providing Efficient and Reliable Point-to-Point and Broadcast Services,” Wireless Networks, July 2004. “The network simulator (NS2),” http://www.isi.edu/nsnam/ns/.