A Distributed Position-Based Protocol for Emergency Messages Broadcasting in Vehicular Ad Hoc Networks

Vehicular ad hoc networks (VANETs) can help reduce traffic accidents through broadcasting emergency messages among vehicles in advance. However, it is a great challenge to timely deliver the emergency messages to the right vehicles which are interested in them. Some protocols require to collect nearby real-time information before broadcasting a message, which may result in an increased delivery latency. In this paper, we proposed an improved position-based protocol to disseminate emergency messages among a large scale vehicle networks. Specifically, defined by the proposed protocol, messages are only broadcasted along their regions of interest, and a rebroadcast of a message depends on the information including in the message it has received. The simulation results demonstrate that the proposed protocol can reduce unnecessary rebroadcasts considerably, and the collisions of broadcast can be effectively mitigated.


I. INTRODUCTION
T HE total volume of road traffic crash is far more sig- nificant than any deadly diseases or natural disasters.According to the World Health Organization (WHO) statistics, about 1.25 million people die from road traffic crashes each year around the world, and between 20 and 50 million people suffer non-fatal injuries, with many incurring a disability because of their injuries [1].Therefore, it is an important and urgent task to study how to effectively avoid road traffic crash using the latest communications technology.Many traffic safety projects have been launched by both automotive industry and academia from all over the world, such as the Japanese projects ITS-Safety 2010 [2] and the European projects CarTALK 2000, PRE-DRIVE C2X [3] and so on.Most of these projects are based on both vehicle-tovehicle (V2V) and vehicle-to-infrastructure (V2I) communication technologies.Generally, the underlying network structure of V2V communication refers to vehicular ad hoc networks (VANETs), which apply advanced communication technology, such as IEEE 802.11p, to exchange information among vehicles.Vehicular safety applications in VANETs mainly rely on broadcasting emergency messages among vehicles.If a vehicle detects a dangerous event, it immediately generates and broadcasts an emergency message to the vehicles in the region of interest (or target region with safety risks), such that the nearby vehicles can take effective actions to avoid traffic accident.In essence, the emergency message, which contains life-critical and time-sensitive information, should be disseminated to all targeted vehicles in a very efficient and effective way.For some emergency scenarios, such as landslide, the target region may stretch several kilometers long along the road, and multi-hops protocol should be used.However, in a multi-hop scenario, it is challenging to deliver such emergency messages timely and reliably because of the characteristics of decentralization, high mobility [4,5] and hidden terminal problem in VANETs.Particularly, The high mobility of vehicles may cause dramatic change of the vehicular network topology and cause frequent disconnections among vehicles.The hidden terminal problem may lead to message collisions over the same wireless channel, especially when the vehicle density is high.All of these challenges result in increased delay and reduced delivery rate of message dissemination.
So far, a number of schemes have been proposed to satisfy the requirements of reliability and low-delay of emergency messages broadcasting in the VANETs [6][7][8][9].In [10], the authors have shown that reducing vehicular message collisions can both increase the reliability and decrease transmission delay.In [11], the authors have also shown that the reliability vehicular broadcasting can be improved by retransmitting the messages, but it may increase the message collisions over the wireless channel, thereby increasing the delay of messages delivery.Therefore, it is a contradiction between improving reliability and decreasing delay.The existing vehicular broadcasting schemes can be classified into the following categories.1) In the probability-based schemes: the vehicle rebroadcast depends on a predefined probability.The primary challenge of this type of schemes is to assign an optimal (or reasonable) probability of rebroadcasting for each vehicle.For example, in [12], the vehicle that is far away from the forwarder will have a higher probability to forward the messages.2) Counter-based schemes [13]: a vehicle relays messages only when the number of message copies received is less than a threshold value.3) Distance-based schemes [14]: the vehicle that is far away from the previous forwarder has a higher priority to transmit the messages.Other type of broadcasting can be found in [13].Essentially, the common idea of the existing schemes is to limit the number of relay vehicles and differentiate the waiting time of forwarder candidates, which can help to reduce the message collisions over the wireless channel.
Although a variety of schemes have been proposed, there are still many urgent problems to be solved.First of all, some schemes [15,16] need forwarders to know the realtime information (such as positions, speeds and directions) of their neighbor vehicles before broadcasting messages.All of these schemes assumed that the forwarders can ideally collect their neighbor vehicles' real-time information by exchanging the beaconing messages.However, the frequent exchange of beaconing message may cause a large number of message collisions and thus it is difficult to maintain real-time information.Besides, the processing of beaconing messages collection increases the delay of emergency messages forwarding.Therefore, these schemes are difficult to put into practice.Second, in some schemes [15,17], the farthest neighbor vehicle of the previous forwarder has the highest priority to relay the messages and is selected as the next forwarder.These schemes require other vehicles to detect the transmission from the newly selected forwarder and completely suppress the scheduled transmissions of their own.However, these schemes cannot distinguish the vehicles which have similar distances to the previous forwarder, and they also do not distinguish the directions of the vehicles.For example, in Fig. 1, the vehicle V0 wants to broadcast its messages in a multi-hop fashion.Since V1-V6 are near the border of V0's communication range and have similar distances to V0, they have similar priorities to forward V0's messages.So it may cause redundant competition among V1-V6, thereby causing message collisions.Besides, it cannot guarantee the farthest vehicle to receive the messages from V0 due to the channel fading and packet loss, which may break the multi-hops broadcast.Furthermore, as these schemes do not consider the direction, they cannot avoid the forwarding loop.For instance, in Fig. 1, V0 chooses V1 as its next forwarder, and then V1 also can choose V0 (or V8) as its next forwarder.In the intersections, messages need to be forwarded to different directions, but these schemes cannot meet this requirement because only one vehicle is selected to be the next forwarder in these schemes.Third, most of the existing broadcast protocols are designed for either urban scenarios or highway scenarios, i.e., they are not suitable for both scenarios simultaneously.For example, the schemes in [10,18,19] are just suitable for highway scenarios, while [20,21] are designed for urban scenarios specially.Fourth, to the best of our knowledge, there are no schemes classifying the messages before broadcasting, that is to say, all of the messages are multi-hops broadcasted in the existing schemes.However, when a vehicle wants to change lane, it just needs to inform the nearest vehicles behind it, and the one-hop broadcast can realize this function.If this type of messages are multi-hops broadcasted, it must occupy more channel resource and increase the delay of other messages delivery.In this paper, we proposed a protocol as a solution to the problems mentioned above.The concept of the proposed protocol is to broadcast a message in its region of interest, so that the vehicles who are interested in the message can receive it, meanwhile, it can reduce unnecessary broadcast and effectively use channel resource.The proposed protocol is not only available for highway scenarios, but also applicable to urban environment, without need of infrastructure support.Besides, the proposed protocol is completely distributed, that is to say, a vehicle independently decides whether to broadcast a received message.
The rest of this paper is organized as follows.In the next section, related works on broadcast protocol in VANETs are presented.We show a paradigm of emergency messages classification and give a detailed description for our proposed broadcast protocol in Section III.The proposed protocol is evaluated in Section IV.Finally, some conclusions are drawn in Section V.

II. RELATED WORKS
Most of the existing schemes adopt the well-known "storecarry-forward" strategy due to the intermittent connectivity of VANETs [22].Flooding may be the simplest scheme among the existing broadcasting methods.However, in this scheme, it is easy to cause some problems such as high collisions and high data redundancy and even the storm problem, because each vehicle rebroadcasts the message to all of its neighbors after it receives a message, which results in increasing the delay and decreasing the reliability of message delivery.Besides, it is inefficiency in terms of radio resource usage.In [12], the influence of the broadcast storm problem was studied in the context of VANETs scenarios, and the authors have designed three suppression techniques by combining the probabilistic and timer-based methods.The schemes they proposed are distributed and just rely on the GPS information, and can effectively mitigate the storm problem.
As aforementioned, reducing message collisions can improve the reliability and decrease the delay of message transmissions.The concept of mitigating message collisions and the storm problem is to reducing the retransmissions.Most schemes allow only a small part of vehicles to rebroadcast messages and others suppress their own transmissions.In the cluster-based schemes [23], the network is divided into many clusters.In each cluster, only the cluster head is responsible for the messages rebroadcasting.Although this method can effectively reduce collisions, it is not easy to maintain the cluster structure because of the high speed move of vehicles.[13,24] presented two adaptive counter-based broadcast schemes, in which each vehicle can dynamically determine whether to rebroadcast messages or not only relying on the messages received from its neighbor vehicles.On the other hand, it also needs to differentiate the waiting time of the forwarder candidates to reduce message collisions, which is achieved by using the location information.In [15], the farthest vehicle away from the previous forwarder waits the shortest time to rebroadcast the messages, but the priorities of the forwarder candidates to retransmit messages are determined by the previous forwarder, i.e., this scheme is not distributed.The authors in [15] also analyzed the relationship between the message collisions and the minimum waiting time interval of two forwarders.[17] combines the distance-based and the probability-based methods to determine the waiting time for each forwarder candidates.If the timer of a vehicle expires, the vehicle keeps waiting another random time interval, which helps to mitigate the contentions, especially when several vehicles' timers expire simultaneously.Hafeez and Zhao presented a way to adaptively change the transmission range to reduce channel contention in [11].The transmission range is a function of network density, delay, data rate and sending rate.
In this scheme, the waiting time of each vehicle can adaptively change according to the network status.
In order to improve the reliability of message delivery and avoid the hidden terminal, Request-To-Broadcast (RTB) / Clear-To-Broadcast (CTB) handshake and acknowledgement (ACK) mechanisms are used in [20,25,26], which requires vehicles to keep sending beacon messages.But the RTB/CTB handshake may cause serious collisions because each vehicle repeatedly broadcasts its beacon message to guarantee its neighbors can receive its beacon, which may lead to unpredictable delay of messages delivery.[20] has presented a strategy that can adaptively control the beacon messages to overcome these drawbacks.More beacon control approaches can be found in [27,28].However, unicasting in 802.11 does not use RTS/CTS handshake when the message size is smaller than a threshold value (the default threshold value is 2347 bytes).Generally, the size of emergency message is smaller than the threshold value [29], that is to say, RTB/CTB handshake is not necessary when broadcasting emergency messages.
Additionally, some researchers proposed their broadcast protocols inspired by a certain biological mechanism.The basic epidemic routing scheme is shown in [30].Subsequently, various epidemic routing schemes are developed to improve the performance of the basic epidemic routing.In [31] the authors proposed an n-epidemic routing protocol, in which a vehicle rebroadcasts messages only when the number of its neighbors reaches a certain threshold.This scheme can greatly decrease the unnecessary retransmissions, especially in the dense networks.In [16], the authors considered vehicle speeds, directions and the infection cost in their scheme.They used attractor selection model to choose the optimal next forwarder.But this scheme relies on the information about  neighbor vehicles, and it is not a distributed method.

III. MESSAGE CLASSIFICATION AND PROTOCOL DESIGN A. Emergency Messages Classification
The reasons lead to traffic crashes are diverse, so the warning messages are also various.Vehicles need to identify each alarm message they have received so that they can take corresponding measure to avoid accident happening.That is to say, vehicles need to know what the received message is, which requires each emergency message to have a unique identifier to distinguish from other messages.Moreover, the identifiers of emergency messages is assumed to be standardized to ensure the compatibility by every vehicles.
Since not all the emergency messages' regions of interest overlay the whole roads or streets, in order to reduce unnecessary rebroadcast and effectively use channel resource, it is necessary to broadcast messages according to their regions of interest, instead of blindly multi-hops broadcasting them into the entire road.For example, 1) if a vehicle sharply slows down, it just needs to inform the nearest vehicle behind it to avoid rear-end collision, and one-hop broadcast is adequate in this scenario.2) As ambulances needs guaranteed priority in traffic, the information coming from ambulance should be forwarded multi-hops along the road so that the vehicles in front can give way in advance.3) It is easy to cause chain collision in severe weather once traffic crash happens, so the information of traffic crash ought to be backward multi-hops broadcast to inform the behind vehicles to slow down.Inspired by this idea, in the following, we will give a paradigm of emergency messages classification based on the region of interest of each message.As shown in Tab.I, we divided emergency messages into three types, i.e., one-hop broadcast, forward and backward multi-hops broadcast.We just used several common alarm messages for examples, more detailed classification should be studied in the future.Fig. 2 gives a schematic diagram of each type of emergency messages' target regions.

B. Broadcast Protocol Design
In section III.A, we have divided emergency messages into three types according to their regions of interest.In this section, we presented a protocol to adaptively broadcast emergency messages in their target regions.The purpose of this protocol is to make sure that the vehicles which are interested in a message can receive the message as soon as possible, meanwhile, redundant transmissions are effectively suppressed.In our scheme, whether a vehicle broadcasts a message or not is determined by itself completely, which just relies on the message it has received, i.e., without any assistances of other foreknowledge.In other words, our broadcast scheme is completely distributed.In order to realize our scheme, all the vehicles are needed to equip with sensing, communication, calculation and GPS modules.And we assumed that all the wireless communication devices have a same communication radius R.
1) Unified Message Format: In our protocol, the transmission schedule of each vehicle just depends on the received message, so the information included in the message is very important.The frame format of message used in our scheme is shown as in Fig. 3, which mainly includes source information, forwarding vehicle's information, broadcast control information and other optional information.The source information includes the identifier ID 0 and location (x 0 , y 0 ) of the source vehicle (we call the vehicle who generates the emergency message as source vehicle), and the identifier id , lifetime T , generation time t 0 and type type of the emergency message.The forwarding vehicle's information includes the identifier ID , previous location (x , y ) , current location (x, y) and azimuth angle ϕ of the previous forwarding vehicle, in addition, it also contains the time t when the message is broadcasted by the previous forwarder.The control information mainly contains the number of repeaters count who have forwarded the message since it is generated, and the mark f lag is used to denote the forwarding direction of the message.In the f lag field, we used "1" and "-1" to tell next forwarder that message should be forward-broadcast and backward-broadcast, respectively.Last but not least, our scheme can be extended in practice, so some optional fields The fields with blue background represent origin information.The fields with brown background represent the information of the previous forwarder.The fields with green background denote the broadcast control information.Some optional information can be added in the region with red background.
are contained.It is worth noting that the field of (x 0 , y 0 ) is the position of source vehicle at time t 0 .Since longitude and latitude can be transformed into the geodetic coordinates, the position of a vehicle is represented by geodetic coordinates in this paper.The value of ϕ denotes the azimuth angle from due north in clockwise direction with a unit of 2 degrees [32], for instance, "60" would be 120 degrees from due north in clockwise direction.
2) Selection of Next Forwarding Vehicles: We assume that there are N (t) vehicles in a road at time t, and they can form a set of Π(t).To a certain vehicle k (k ∈ Π(t)), its one-hop neighbor vehicles at time t is defined as a set of ) denotes the Euclidean distance between vehicle i and vehicle k .If vehicle k broadcasts an emergency message at time t, its one-hop neighbors may receive the message, sometimes only a part of its neighbors can receive the message due to the packet loss and channel fading.We defined the success rate of message transmission to be p.The vehicles who can receive the message form a set of Λ k (t)(Λ k (t) ⊆ S k (t)).As aforementioned, whether a vehicle i ∈ Λ k (t) rebroadcasts a message completely depends on the information included in the received message.If the type of a message is "0", which means the message does not need to be rebroadcasted, so the vehicles who have received the message keep silence.Otherwise, the message will be forwarded by means of the multi-hops broadcast manner.In the multi-hops broadcast scenarios, the main idea is to give higher priorities to some vehicles (in Λ k (t)) who can fastest propagate the message along the message's target region to rebroadcast message, meanwhile, other vehicles with lower priorities suppress their own retransmissions, which can help to reduce the unnecessary retransmissions and mitigate the message collisions.[33] shows that two adjacent forwarders keep a distance can help to reduce message collisions.Therefore, in our scheme, a vehicle has an opportunity to rebroadcast massage only when the distance between itself and its previous forwarder is larger than r(0 ≤ r ≤ R) .For example, in Fig. 4, only the vehicles in the set of {V1,V2,V4,V6,V7,V12} are forwarder candidates when V9 broadcasts messages.It would be noted that most existing protocols in VANET can be considered as particular scenario of our proposed protocol, i.e., r = 0 .The implementation of the multi-hops broadcast scheme is shown in the following.
In our scheme, each vehicle manages a schedule table shown as Tab.II.The contents of the "Messages" field can be found in Fig. 3.After a vehicle receives a new message, it adds the message to its schedule table.At the initial time, the "Forward", "hasSend" and "times" fields are set to be "0", and the "timer" field is set to be "infinite".In the "Forward" field, "1" denotes that the message will be relayed by current vehicle, and "0" denotes that current vehicle will not forward the message for the present.In the "hasSend" field, "1" and "0" represent the message has or has not been rebroadcasted by current vehicle, respectively.In our protocol, we assume that each forwarder can broadcast only one message at a time.Assume vehicle k broadcasts a message at time t, i ∈ Λ k (t).Upon receiving message from previous forwarder k, vehicle i calculates the distance dist(i, k) between itself and vehicle k.If dist(i, k) > r and dist(i, k) < R, vehicle i need to Algorithm 1 Decision process before broadcasting message Input: dist(i, k); Execute: 1: if dist(i, k) > r and cos φ = 0 then 2: if |φ| < ψ 0 or 180 − ψ 0 < |φ| < 180 + ψ 0 then 3: if Received f lag = 1 and cos θ cos φ < 0 then 4: Set "Forward=1"; 5: if cos θ > 0 then 6: Update f lag = −1; if Received f lag = −1 and cos θ cos φ > 0 then 10: Set "Forward=1"; 11: if cos θ < 0 then 12: Update f lag = 1; Set "Forward=1";  end if 25: else 26: Set "Forward=0"; 27: end if further judge whether itself is the next forwarder according to the Algorithm 1; otherwise, vehicle i does not rebroadcast the message and sets "Forward=0".In Algorithm 1, whether i is selected as the next forwarder is depended on the relative location between itself and the previous forwarder k, so vehicle i needs to obtain its own previous position (x i−pre , y i−pre ), current position (x i−cur , y i−cur ) and azimuth angle ϕ i firstly, and then to calculate the relative location between vehicle k and itself.As shown in Fig. 4, there is a local coordinate system x-y located at each vehicle, and the positive direction of the x axis is the same as the direction of speed.The geodetic coordinates (x, y) can be translated into local coordinates (X, Y ) (assuming the coordinate system is located on vehicle i) by the following formulas: In Fig.All of the vehicles in Λ k (t) update their "Forward" fields and propagation direction marks f lag according to the above process.If the "Forward" field of vehicle i is set to be "1", vehicle i starts a timer to wait for a period of time before broadcasting the message.The waiting time W T is determined by the following formula: where dist is the distance between vehicle i and vehicle k, a(a > 0) and m(0 < m < 1) are two constants used to distinguish the waiting time for vehicles in different directions, and W T 0 is also a constant.In this work, we set a = 1.15, m = 0.6 and W T 0 = 400µs.
During the waiting time, if vehicle i received a duplicate message from other forwarder j(j = k) , and vehicle i and j are located in a straight road segment, vehicle i will suppress its own rebroadcast and set "Forward=0".Otherwise, when the waiting time expires, vehicle i broadcasts the message if the channel is idle and sets "hasSend=1", the "Forward" field remains on "1"; if the channel is busy, vehicle i will wait another random period of time for an idle channel to broadcast the message.In our protocol, if the "hasSend" field is "1", vehicle i will repeatedly broadcast the corresponding massage to guarantee its one-hop neighbors can receive the message.Generally, the time takes for one-hop neighbor vehi-cles receiving a message is much shorter than the lifetime of the message.So every forwarder should limit the rebroadcast times of each message.The rebroadcast times can be simply calculated as follows.
where x denotes to get the minimum integer larger than x, U (0 < U < 1) is a predefined percentage of one-hop neighbor vehicles who can receive a message.In order to guarantee the proportion of vehicles who can receive message is larger than U , we required that each forwarder rebroadcasts a message at least five times.The value of "times" field decreases by one after vehicle i rebroadcasts the message once.The "Forward" will be set to be "0" when the value of "times" decreases to zero, and vehicle i does not broadcast the message any longer.

IV. PERFORMANCE VERIFICATION AND SIMULATION RESULTS
We validated the efficiency of our protocol through simulations.The scenario of our simulation is shown in Fig. 6.In the scenario, each road has one lane per direction.The length of AA1 is 4 km, and the lengths of OA, BC, B1C1 are 2 km.We deployed 570 vehicles in the roads uniformly, and the speeds of vehicles are distributed in the range of [20,30] m/s.Initially, the source vehicle is located at the point O.We assumed that the source vehicle broadcasts a message whose region of interest forward (or backward) stretches 2 km along the road.And we placed a receiver at the six ends, respectively.It can prove that a message has fully covered the region of interest if the receivers A1, B1 and C1 (or A, B and C) can receive the message.In addition, we set the communication radius R to be 300m and changed the value of parameter r (r = 0m, r = 120m, r = 180m and r = 240m) in simulation settings.The time taking for each message transmission was fixed to be 3ms, and the time interval of each forwarder rebroadcasts message was set to be 0.1s.We set U = 0.99 , that is to say, 99% vehicles of a forwarder's one-hop neighbors can receive the message sent by the forwarder.The time step was 0.01ms and the simulation process would not stop until the receivers A1, B1 and C1 (or A, B and C) receive the message.In each simulation setting, the simulation process was repeated 100 times.
We compared our protocol with the UV-CAST protocol presented in [21] and the simple flooding protocol in the simulation.Fig. 7 (a) and (b) shows the results of two simulations in which different types of messages broadcasted by the proposed protocol, the types of messages are "1" and "2", respectively.We can see that the messages are broadcasted along their target regions and do not cover the entire roads.However, both of the two kinds of messages fully cover the roads when broadcasted by the UV-CAST and flooding protocols (as shown in Fig. 7 (c) and (d)), because the two protocols do not consider broadcast direction.Fig. 8 shows the average number of vehicles that can receive the message in simulations.In the proposed, UV-CAST and flooding protocols, about 290, 535 and 540 vehicles can receive the message, respectively.Under all of the three protocols, about 96% vehicles in the region of interest can receive message.The reason why this percentage is less than 99% is that a few new forwarders had not rebroadcast the message many times before the simulation stopped.Obviously, in the UV-CAST and flooding protocol, many vehicles who can receive the message are not interested in the message, that is to say, there are many unnecessary transmissions in the UV-CAST and flooding protocol, but this situation can be well improved through the proposed protocol.
In the following, we will further demonstrate the performances of our protocol.The delivery latency is a very important performance metric of broadcast protocols, which is defined as the interval from the time when the source vehicle broadcast a message to the time when the receivers A, B and C receive the message (we just show the results of backward-broadcasted message in the following).Fig. 9 shows the influence that the success rate of transmission has on the deliver latency.We can see that under ideal transmission condition (i.e. when the success rate of transmission is 100%), no matter what value of r is, the proposed protocol takes the least time (27ms) to delivery the message, and the flooding protocol can deliver a message faster than the UV-CAST protocol.For the proposed protocol, the deliver latency is very close to that of the flooding protocol when the success rate of transmission p > 60% and r ≤ 180m.But when r = 240m, the deliver latency sharply increases from 27ms to more than 0.4s when the success rate of transmission decreases from 100% to 20%.This demonstrates that deliver latency increases if the transmission condition gets worse, furthermore, it also enunciates that deliver latency increases with r increasing, which is because there are fewer and fewer vehicles becoming forwarder candidates when the parameter r becomes larger and larger, and it will take much time for them to successfully receive the message if the success rate of transmission is very low.Since the UV-CAST protocol needs a forwarder to collect its neighbours' information, its deliver latency is larger than that of the proposed protocol when r ≤ 120m and p > 40%.
The flooding protocol is a luxury protocol though it has lower deliver latency.From Fig. 10(a), it can be found that the number of vehicles that take part in broadcasting message under UV-CAST protocol is more than twice as large as that under the proposed protocol, but both are fewer than that under the flooding protocol.For the UV-CAST and flooding protocol, there are at least 110 (19%) vehicles take part in broadcasting the message when the success rate of transmission is 100%, however, there are 85 (15%) vehicles taking part in broadcasting message at most under the proposed protocol, and no more than 50 (9%) vehicles taking part in broadcasting message when r = 240m.We also can find from Fig. 10(a), for the proposed protocol, there are fewer  vehicles take part in broadcasting message if the value of r is larger.Fig. 10(b) shows the total times that all the forwarders tried to broadcast the message in each setting.In our simulations, each forwarder detect whether the channel is idle before broadcasting message.If the channel is idle, the forwarder broadcast the message immediately, else it will try again to broadcast the message after waiting a random time interval in the range of [0.02, 0.05] ms.It can be found that the total times decreases under each protocol with success rate of transmission increasing, because it takes less time to deliver the message and fewer vehicles take part in broadcasting the message under a high success rate of transmission.The total broadcast times under UV-CAST and flooding protocols are more than eight times as many as that under the proposed protocol, the main reason is that there are more vehicles broadcast the message.As aforementioned, half of the rebroadcasts are unnecessary for both of the UV-CAST and flooding protocols, and redundancy broadcast is a waste of channel resource.Additionally, there are so many vehicles tried to broadcast message in such a short time under the UV-CAST and flooding protocols, it must cause a lot of collisions.As seen in Fig. 10(c), we used the average broadcast times that forwarders tried to broadcast the message in a unit time to reflect the intensity of transmission competitions.It can be found that the average broadcast times under proposed protocol is no more than 9500, which is much fewer than that under the UV-CAST (about 60000) and flooding protocols (more than 80000).This suggests the competitions in the proposed protocol can be greatly relieved.In each simulation setting, the times that forwarders broadcast message successfully is shown in Fig. 11(a), we can calculate the proportion between the times that forwarders successfully broadcasted message and the total times that forwarders attempted to broadcast message.The proportions of the UV-CAST and flooding protocols are 4.3% and 4.2%, respectively, that is to say, about 96% attempts are failed because of the collisions; while under the proposed protocol, the proportions are 23.8%,29.7%, 38.0% and 56.8% when r increases from 0m to 240m, which indicates that the proposed protocol is more efficient than the UV-CAST protocol.What's more, for the proposed protocol, it is clearly that increasing the parameter r can help to reduce the average broadcast times per unit time and improve broadcast efficiency.But if the value of r is too large, the deliver latency will sharply increase as shown in Fig. 9.So it needs to select an appropriate parameter r for the proposed protocol, so that it can effectively mitigate competitions and has low deliver latency at the same time.According to the simulation results, we can see that r = 120m is a good choice when p > 40%, while r = 0m is better in poor transmission conditions.We also verified the performance of the proposed protocol in different traffic scenarios, where the number of vehicles are 200, 270, 370, 470 and 570 respectively (and the traffic densities range from 12.5 to 35.6 vehicles/km/lane correspondingly).As shown in Fig. 11(b), the delay increases very quickly with the traffic density decreasing.In order to guarantee a low delay, the parameter r should be set to be r = 0m when the traffic density is low.

V. CONCLUSION
In this paper, we have proposed a position-based broadcast protocol for emergency messages propagation in VANETs environment.Unlike most of the existing protocols, the proposed protocol does not require vehicles to collect the real-time information of their one-hop neighbors before they broadcast a message.In other words, vehicles just depend on the information including in a received message to judge whether to rebroadcast the message, which can reduce the deliver latency and drivers will have more time to take actions to avoid accident happening.Since messages are just broadcasted along their regions of interest, the proposed protocol can efficiently reduce unnecessary rebroadcasts and collisions, which helps to improve the utilization ratio of wireless channel.Additionally, the proposed protocol can deliver messages with low delay and few collisions by changing the parameter r to adapt to the transmission conditions.Last but not the least, the proposed protocol is suitable for both urban and highway environment, because it is a distributed protocol and more than one vehicles can be chosen as the next forwarders.

Fig. 1 .
Fig. 1.A schematic diagram of message broadcasted in road.

Fig. 2 .
Fig. 2. Schematic diagram of different types of messages' region of interest.(a)Region of interest of one-hop broadcasted messages typed by "0"; (b)Region of interest of forward multi-hop broadcasted messages typed by "1"; (c)Region of interest of backward multi-hop broadcasted messages typed by "2".

Fig. 3 .
Fig.3.Unified frame format of messages used in the proposed protocol.The fields with blue background represent origin information.The fields with brown background represent the information of the previous forwarder.The fields with green background denote the broadcast control information.Some optional information can be added in the region with red background.

19 :then 20 :
if vehicle i is moving far away from the line determined by the previous and current positions of vehicle k Update f lag = 1; 21:

Fig. 7 .Fig. 6 .
Fig. 7.The results of message propagation under different protocols.The blue and mauve nodes denote that they have not and have receive message, respectively; The green node is the source vehicle, and the red nodes are the receivers.(a) Propagation result of a message typed by "1" under the proposed protocol.(b) Propagation result of a message typed by "2" under the proposed protocol.(c) and (d) are the propagation results of a message under UV-CAST and flooding protocols respectively, no matter what type of the message is.

Fig. 8 .
Fig. 8.The number of vehicles that have received message during the simulation time under different protocols with different transmission conditions.

Fig. 9 .
Fig. 9.The deliver latency under each protocol with different transmission conditions observed at the receiver A, B and C, respectively.(a)Observed at receiver A. (b) Observed at receiver B. (c) Observed at receiver C.

Fig. 10 .
Fig. 10.(a) The number of vehicles that have taken part in broadcasting message during the simulation time.(b) The total times that vehicles tried to broadcast message under each protocol with different transmission conditions during the simulation time.(c) The average times that vehicles tried to broadcast message per second under the three protocols with different transmission conditions.

Fig. 11 .
Fig. 11.(a) The total times that forwarders broadcasted the message successfully during the simulation time under different protocols with different transmission conditions.(b) The deliver latency observed at the receiver A under different r with different traffic flow densities, and p was set to be 0.6 in the simulation.

TABLE I A
PARADIGM OF EMERGENCY MESSAGE CLASSIFICATION

TABLE II A
PARADIGM OF SCHEDULE TABLE USED FOR BROADCAST MESSAGE 0 or 180−ψ 0 < |φ| < 180+ψ 0 ( ψ 0 is a predetermined parameter used to correct the difference, because the direction of speeds are not always parallel to road centerline, and road may not be strictly straight.In this work, ψ 0 was set to be 10 degrees), we say vehicle i and vehicle k are located in a straight road segment.As the emergence message received from vehicle k should be forward or backward forwarded, vehicle i needs to compute its own position relative to vehicle k by computing cos θ cos φ, herein, cos θ = it indicates vehicle i is behind vehicle k (i.e., vehicle i is located in the second or third quadrant of vehicle k ); else if cos θ cos φ < 0, vehicle i is in front of vehicle k (i.e., vehicle i is located in the first or fourth quadrant of vehicle k ).Then vehicle i can decide whether to rebroadcast message according to cos θ cos φ and the received propagation direction mark f lag.Subsequently, vehicle i needs to update the f lag field of the message to tell the propagation direction to the next forwarder who receives message from vehicle i.
5, P (X k , Y k ) and P (X k , Y k ) represent the previous forwarder's previous and current location, O (X pre , Y pre ) and O(X cur , Y cur ) denote the previous and current location of vehicle i, respectively.Vehicle i calculates φ = |ϕ i − ϕ k | (ϕ k is the azimuth angles of vehicle k ) to judge whether itself and vehicle k are located in a straight road segment.1) If it satisfies |φ| < ψ Vehicle i updates f lag according to the value of cos θ. 2) If vehicle i and k are not in a straight road, vehicle i sets "Forward=1" immediately, and then continues to update the f lag field.If O and O are located in the same side of line P P , we compare the lengths of the two line segments |OD| and |O D |, here |OD| and |O D | denote the distances from O and O to line P P , respectively.When |OD| < |O D |, it suggests that vehicle i is moving close to line P P , it should backward-broadcast message, so the propagation direction is set to be f lag = −1; else if vehicle i is moving far away from line P P (when |OD| > |O D | or the point O and O are not located in the same side of line P P ), it should forwardbroadcast the message, and the f lag field should be set to be "1".