Vehicle Safety Enhancement System: Sensing and Communication

With the substantial increase of vehicles on road, driving safety and transportation efficiency have become increasingly concerned focus from drivers, passengers, and governments. Wireless networks constructed by vehicles and infrastructures provide abundant information to share for the sake of both enhanced safety and network efficiency. This paper presents the systematic research to enhance the vehicle safety by wireless communication, in the aspects of information acquisition through vehicle sensing, vehicle-to-vehicle (V2V) routing protocol for the highly dynamic vehicle network, vehicle-to-infrastructure (V2I) routing protocol for a tradeoff in real-time performance and load balance, and hardware implementation of V2V system with on-road test. Simulations and experimental result validate the feasibility of the algorithms and communication system.


Introduction
Safety-on-road is an important concern by all the drivers and passengers. With the sharp increase of vehicles on road, this has become increasingly important and challenging due to the higher probability of accidents. There are two aspects which can help prevent the occurrence or the deterioration of an accident. (1) Notify the immediately following vehicles to prevent chained accidents. However, bad weathers, such as fog, will prevent the drivers from obtaining the accident occurrence on time if merely from vision. (2) Notify other vehicles which may take the path encountering the accident spot, so as to avoid traffic jam. However, the current radiobased broadcasting approach requires human interaction for both accident detection and broadcasting and thus cannot achieve satisfying real-time performance. Therefore, a realtime vehicle safety enhancement system is needed for collision detection and vehicle status information sharing with nearby vehicles.
Two subsystems are necessary in the vehicle safety enhancement system. One subsystem, vehicular information acquisition subsystem (VIAS), takes charge of vehicular status sensing, so as to detect the accident information (e.g., position, etc.), classify the severity level (e.g., slight bumping, rolling over, etc.), as well as to detect some hazardous driving behaviors (e.g., sudden slow down, S-shape driving, etc.). Current additive sensor technologies, (e.g., GPS, accelerometer, angular sensors, etc.), as well as the onboard vehicular signals (e.g., airbag deploying signal, brake pedal signal, vehicle speed signal, etc.), make possible the implementation of this subsystem.
The other subsystem, intervehicle wireless communication subsystem (IVWCS), is in charge of the intervehicular information sharing. Recent advances in wireless technologies have made vehicle-to-vehicle (V2V) communications and vehicle-to-infrastructure (V2I) communication possible by means of mobile ad hoc networks (MANETs) for intelligent transportation system (ITS). Vehicle ad hoc networks 2. Vehicular Information Acquisition [7] Traffic collisions are serious threats to human lives. It is estimated that 1.2 million people were killed in motor-vehicle accidents globally [8]. There are various factors, such as road and traffic environment, vehicle states, and drivers' behaviors. Vehicular information, if obtained and shared among surrounding vehicles, can reduce the risk of accidents.

Collision and Potentially Hazardous State Classification.
We classify and define the accidents or potential hazardous actions into 4 severity levels, as listed below.
Different severity levels should be processed differently. If sudden slow down occurs, the immediately following vehicles ought to be notified, so as to prevent collision. For a minor accident, a flexible traffic police, for example, motorcycle police, will be adequate, and the most urgent need is to recover the traffic. If the airbag is activated or there is rolling over, ambulance should be connected automatically and promptly to save the injured. Even more, for the rolling over case, a crane may also be needed to remove the vehicle in accident.

Sensors for Collision Detection.
During the driving, some real-time status signals are available inside the vehicle, such as airbag deployment signal. Aside of those, additional sensors are required to classify the signals into more delicate levels. These signals and sensors are listed in Table 1.

Sensor Data Fusion and Collision Estimation.
We adopt the Freescale9s12XEP100 as the core MCU controller for data gathering and analysis. It is configured with 16 bit HCS12X CPU, 512 Kbyte Flash EEPROM, and 32 Kbyte RAM for digital signal processing.
According to the sensor information obtained from vehicle, the real-time estimation of collision is conducted, as shown in Figure 1. Figure 2 illustrates the overall processing action flowchart for collision detection and dissemination.
International Journal of Distributed Sensor Networks 3

Evaluation of Classical Routing Protocols in MANET [13]
The speed of vehicle moving on a freeway is fairly fast, at approximately 80 km/h in general. When the accident occurs on a freeway, the warning message must be instantly sent to other vehicles nearby via the VANET, so that the drivers nearby have enough time to avoid collision. In order to achieve reliable real-time communication, the performance of routing protocol used by the VANET is important [5,14]. Different routing protocols have different network characteristics [15][16][17]. VANET on the freeway is a fast and highly dynamic mobile ad hoc wireless network without fixed router, hosts, or wireless based stations. A significant challenge in the freeway VANET is how to select an efficient routing protocol among numerous protocols. Thus, three classical routing  [18]. These routing protocols are divided into two major classes based on the underlying routing information update mechanism employed, reactive (on-demand) or proactive (table-driven). For performance evaluation, we have compared three typical routing protocols in MANET for V2V application. Destination sequenced distance vector protocol (DSDV) is selected as an example for table-driven protocols, while both dynamic source routing (DSR) and ad hoc on-demand distance vector (AODV) protocols are selected as examples for on-demand protocols [19][20][21].
(1) DSDV. DSDV is based on the Bellman-Ford algorithm which can effectively solve routing loop problem [19]. Each node has a routing (2) DSR. DSR uses source routing instead of hop-by-hop packet routing in comparison with DSDV and has two major phases, which are route discovery and route maintenance [20]. Route discovery is used to set up a route from source node to destination by sending RouteRequest packet in the source node. If a node in the path moves away and breaks wireless communication, route maintenance will rebuild a route from source node to destination one by sending RouteError packet to the node adjacent to broken link. Each data packet carries corresponding routing information. Thus, it eliminates the need to periodically flood the network with table update messages which are required in a table-driven approach. However, DSR does not locally repair a broken link. The connection setup delay is higher than that of tabledriven protocols.
(3) AODV. AODV is very similar to DSR [21]. It sets up a route to the destination by sending a RouteRequest message. The source node and the intermediate nodes store the next hop information corresponding to each flow for data packet transmission. The major difference between AODV and other reactive routing protocols is that it uses a destination sequence number (DesSeqNum) to find the latest route to the destination. A node updates its path destination only if the DesSeqNum of the current packet received is greater than the last DesSeqNum stored at the node. However, AODV requires more time to set up a connection than some other approaches [15,17,21].

Simulation Environment and Performance Evaluation.
The simulator for evaluating three routing protocols is the Network Simulator (NS2, version 2.33). NS2 provides substantial support for simulation of wireless networks using discrete-event mode.
(1) Basic Scenario. The simulation scenario is designed according to the normal state of car running on a freeway shown in Figure 3. Assume that the freeway is 30 meters wide and 500 meters long. 40 vehicles are randomly distributed to the four bidirectional lanes of the freeway. Each vehicle is regarded as a mobile node moving forward in a random fashion. The maximum velocity of nodes is 35 m/s with simulation period of 200 seconds. The channel capacity is (2) Performance Evaluation. The performance evaluation of routing protocols is based on the measurement of the following parameters [16].
Packet Loss Rate (%). Packet loss occurs when one or more packets of data traveling across a VANET fail to reach their destinations. The packet loss rate is calculated as where and represent the number of data packet received and sent, respectively.
End-to-End Delay (ms). End-to-end delay is defined as the time taken for a data packet to be transmitted across the network from the source to the destination.
Packet Jitter (ms). Packet jitter is defined as the delay variation between two consecutively received packets belonging to the same stream. In general, it is expressed as an absolute value of delay variation.

Throughput (Kilobits per Second).
System throughput is the sum of the data rates that are delivered to all nodes in the network.
Protocol Overhead. Protocol overhead refers to the number of routing messages requested when a data packet is successfully delivered to the destination.

Simulation Results and Discussion.
Throughout the simulation, we discuss the results as below.
(1) Packet Loss Rate. Table 2 shows the packet loss rate incurred by DSDV, AODV, and DSR. Both DSR and AODV on-demand routing schemes have considerably less packet loss rate than DSDV. Because each node is fast mobile in a random fashion, the network topology often changes. These packets sent may be lost once the routing table is not timely updated in DSDV. This results in a higher packet loss rate of DSDV.
(2) End-to-End Delay. Figure 4 shows the end-to-end delay of data packets. The statistical values of them are (7.440 ± 4.157) ms (DSDV, confidence level = 0.95), (8.167 ± 9.210) ms (DSR, = 0.95), and (8.107 ± 5.026) ms (AODV, = 0.95), respectively. They have no significant difference in the mean values. However, as a whole, the margin of delay fluctuation in DSR is the highest among the three protocols. In DSR, a neighbor displacement is noticed only after a packet is sent explicitly to that node. The network reacts International Journal of Distributed Sensor Networks if an acknowledgement is not received. Consequently, this increases packet delay since the packet must wait until a new route is established.
(3) Packet Jitter. Figure 5 shows the jitter of data packets using three different routing protocols. The statistical values of them are (2.356 ± 4.199) ms (DSDV, = 0.95), (3.254 ± 10.630) ms (DSR, = 0.95), and (4.498 ± 4.498) ms (AODV, = 0.95), respectively. DSDV shows the most superiority than others. The average jitter of AODV is the biggest among the three protocols. Moreover, the standard deviation of jitter in AODV is larger than that in DSDV. Although the average jitter of DSR is not the largest among the three protocols, DSR has the largest jitter fluctuation among them. This means violent variation exists in the delay of a few data packets sent in DSR. The rapid change of jitter is attributed to the frequent change of network topology and the mechanism of inherent routing update. (4) Throughput. Figure 6 shows the throughput comparison of DSDV, DSR, and AODV. All throughputs are everincreasing with the time in general. This can be attributed to more active nodes to join network communication with time extension. The graph also reveals that AODV has higher throughput than DSR. In DSR, a route is chosen based on the short delay at the instance of route establishment. Although this path may be the best route at that instant, it may be also a route that lacks routing stability or has unacceptably high load. In contrast, AODV has a more robust update mechanism to avoid bottleneck and congestion and eventually improve throughput. In DSDV, high packet loss rate causes throughput to drop. Table 3 shows the overhead comparison of DSDV, AODV, and DSR. AODV has the highest overhead among three routing protocols due to three main reasons. Firstly, AODV allows broadcast. Although the discovery packets are broadcasted only when necessary, such as establishing a new route, link breakage, or route error, the broadcast instances will often appear for a fast mobile VANET. Secondly, AODV allows mobile nodes to respond to link breakages and changes in network topology in a timely manner. Thus, numerous routing messages are used to maintain an active route in AODV. Thirdly, AODV is derived from DSDV. It still has similar features of proactive routing protocols. When the network topology is often changed because of the fast mobility of nodes, proactive protocols must send more messages to maintain a valid routing table.
The experimental results are shown in Table 3. DSR has the best protocol overhead performance among the three protocols. The DSR protocol is composed of the two main mechanisms of "route discovery" and "route maintenance, " which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network. Some measures reducing overhead are adopted in the process of "Route Discovery" and "Route Maintenance" of DSR [21].

Conclusion.
Based on the simulation results, we discovered that DSDV achieves marginal better packet delay and packet jitter than AODV and DSR. However, it has significantly higher packet loss rate and the smallest throughout among them. Although DSR has the best protocol overhead performance among three routing protocols, it has poorer jitter and throughput than AODV. As a whole, AODV is more appropriate for the freeway VANET according to the quality of service and the real time of packet delivery. The inherent reason producing this result is the effect of node mobility on the performance of the routing protocol.

GPS Based AODV Protocol for V2V Communication [22]
As we can find through the previous protocol evaluation, AODV is appropriate for the dynamic structure with mobile vehicles. The source node will find a route to destination for data transmission. To find a route to the destination, the source broadcasts a route request packet (RREQ). The node receiving RREQ will reply a route reply packet (RREP) to the reverse path that RREQ went through if it is the destination of RREQ or if it has a recent route to the destination. Otherwise, the node will broadcast RREQ until either of the two situations above occurs. As RREP traverses back to the source, the nodes along the path enter the forward route into their routing tables. If a node leaves the network, the node that discovers this broken link will send a link failure notification (RERR) to the precursors. The RERR goes upstream until it reaches the source. The source will thereafter restart route discovery process if needed [23]. However, AODV is dedicated for MANET, and modification is necessary for VANET applications [24]. Since nodes in VANET are fast moving vehicles, the topology of the network changes all the time, making the position and velocity of the node critical factors while finding the routes. Therefore, besides conventional topology-based routing protocol (such as AODV), position-based routing protocol, which primarily uses the position information obtained by GPS to find a route, is applied in VANET [25].
In recent years, many researchers have tried to combine two types of routing together. In [26], Kim et al. proposed AODV-RRS which restricts the number of forwarding RREQs according to the concepts of stable zone and caution zone. PAODV [27] restricts the number of flooding RREQs based on the distance between current node and its neighbors. Both of them have similar mechanism and reduce the number of broken links. DAODV [28] establishes a route depending on the direction and position of source, intermediate, and destination node. Although it also reduces the number of broken links, DAODV assumes that source node knows the direction and position of all the nodes in the network. Actually this is impossible with the current GPS devices. We should find some mechanisms to get the geographic information of all the nodes. Thereby, in [29], Asenov and Hnatyshin proposed GeoAODV routing protocol. Each node will maintain an additional table, geotable, to keep track of the geographic information of all the nodes. RREQs are restricted flooding in the region determined by the geotable. However, it costs more resources to maintain two tables.
We go a step further in this section by proposing a GPS based AODV (GBAODV), which enhances the overall performance of AODV in VANET. In order to be attainable in physical implementation, GBAODV assumes that each node only knows its own position and velocity. Without maintaining a geotable [29], GBAODV is much more concise than GeoAODV.

Overview of GBAODV.
With current GPS device, we can obtain the longitude ( coordinate) and latitude ( coordinate) of current node, and calculate the speed in each direction with two successive sets of coordinates. Without maintaining a geotable, we add geographic information into routing table to make the algorithm concise.
There are two main features in GBAODV. First is to reduce the number of RREQs. The node receiving an RREQ packet will check the distance and motion trend between the precursor and itself, so as to decide if this RREQ should be broadcasted. By restricting these flooding RREQs, it will avoid lots of packet collisions in the network. As a result, the packet delivery ratio and throughput of the network can be raised. Second is to mark the route according to the positions and velocities of source, intermediate, and destination. Higher mark means higher stability. Consequently, every node will choose a route with higher mark.
These two features require specifying flooding rules and marking standards, as well as some modifications in the routing table and routing packets.

Modified Structure of Routing Table, RREQ, and RREP
(1) Modified Routing Table. Original routing table contains the IP addresses of next hop and destination, sequence number of destination, and total hops. The routing table will update if the sequence number of destination is larger or total hops is less. We added the position and velocity of the destination node and the mark of this route into the routing table. Besides the two conditions above, the routing table will update when the mark is larger, which means that the route path is more stable.
(2) Modified Frame Structure of RREQ. We inserted position ( , coordinates) and velocity ( , direction) of the source and current node into RREQ packet. We also applied a reserved segment to record the mark of the route link from source to precursor.  Figure 7: B, C, and D will broadcast RREQ received from P.
applied a reserved segment to record the mark of the route from destination to current node.

Flooding Rules and Marking Standards
(1) Flooding Rules. Let stand for the distance between the precursor and current node and stand for the maximum transmission distance of the wireless card. The flooding rules are as follows.
The coefficients 0.4 and 0.8 are chosen empirically. We conducted simulations with the combinations of these coefficients to study numbers of RREQs and RERRs, packet loss ratio, and average end-to-end delay. Results show that the combination of 0.4 and 0.8 is the best among all.
In Figure 7, B, C, and D will broadcast the RREQ received from P, while A and E will discard it.
(2) Marking Standards. As illustrated in Figure 8, let stand for the current distance between node and node , stand for this distance a moment later, stand for the current distance between node and node , and stand for this distance a moment later. We specify the marking standards as follows: where sgn() is a signum function. is a constant: −3 is chosen experimentally according to simulations.
Since the transmission distance of wireless LAN card is limited, geographic distance of each hop is the key factor that affects the quality of communication. If the distance stays unchanged, then the route is really stable so that the source and destination can communicate steadily. If the distance is increasing, it is possible that one node in this route will exceed the transmission distance soon. If the distance is decreasing, then after some time, the two nodes may cross over and start to depart. It is better than increasing distance, but not as good as unchanged distance. So we set two values for each changed distance: 0 for each decreasing distance and −2 for each increasing distance, as shown in (2).
To find a path to the destination, the source broadcasts an RREQ containing the position and velocity of source and preset a standard mark value.
As illustrated in Figure 9, when a node receives an RREQ the following will occur.
(i) If it does not have a route to the source node, it will insert the route RREQ into its routing table.
(ii) If it has a route in routing table but the route needs to be updated, it will update routing table.
(iii) If it is the destination or has a route to destination, it will create an RREP in which the mark is a standard value (if it is the destination) or is obtained from routing table (if it has a route to destination).
(iv) If it is a node besides (3) and satisfies the broadcasting conditions (refer to flooding rules), it will add the mark of source → precursor → current to the present mark in RREQ. It will also update the position and velocity of current node in RREQ.
As illustrated in Figure 10, when a node receives an RREP the following will occur.
(i) If it does not have a route to the destination, it will insert the route, which RREP goes through, into its routing table.
(ii) If it has a route in routing table but the route needs to be updated, it will update routing table.
(iii) If it is the destination of RREP (i.e., the source of RREQ), it will insert the route into routing table.
(iv) If it is a forwarding node, before unicasting RREQ, it will add the mark of source → precursor → current  to the present mark in RREP. It will also update the position and velocity of current node in RREQ.

Simulation Setup
(1) Simulation Tools. We chose VanetMobiSim 1.1 [30] for traffic simulation. This software can generate a traffic flow in the format suitable for NS2 [31], which can load GBAODV for network simulation.
With VanetMobiSim, we import maps from the US Census Bureau TIGER/Line database [32], which includes complete coverage of the United States, Puerto Rico, and so forth. Moreover, VanetMobiSim supports for multilane roads, differentiated speed constraints, and traffic light signals at intersections. All the vehicles can be set to Intelligent Driver Model with Lane Changing (IDM LC) [33,34]. For these reasons, the scenario in traffic layer is quite authentic, which makes the simulation in network layer reliable.
(2) Parameter Settings. In our simulation, we observed two types of traffic models: downtown and highway. TGR11001 [

Simulation Results
(1) Downtown Model. Figure 11 illustrates that the number of RREQs received per node per second is reduced by about 50%. This is caused by the application of flooding rules. In addition, we can notice that although it is normalized by the number of nodes, the number of RREQs still increases with the number of nodes. This means larger number of nodes induces larger amount of RREQs broadcasted in the whole network. Therefore, it is significant to reduce the broadcasted RREQs especially in high density traffic. Figure 12 illustrates the number of RERRs sent per connection. The number of RERRs is also reduced a lot which means broken links have decreased a lot. This is an attribute to the application of marking standards since we choose every connection with high stability. Figures 13 and 14 illustrate the packet loss ratio and average end-to-end delay. Compared with Figures 11 and  12, they show that packet loss ratio and average end-to-end delay are positive correlated to the numbers of RREQs and RERRs, because reducing the number of RREQs contributes to avoiding large amount of packet collisions in the network. Meanwhile, reducing the number of RERRs (i.e., broken links) could smooth communication.
(2) Highway Model. The number of RREQs received per node per second is reduced by more than 50% (illustrated in Figure 15). Figure 16 shows that the number of RERRs sent per connection is also reduced. We also note that with the increase of number of nodes, the reduction of RERRs (i.e., broken links) increases. This means GBAODV is more efficient in high density traffic scenario. The conclusion is verified by Figure 17 (packet loss ratio) and Figure 18 (average end-to-end delay). Compared with Figures 13 and 14, the improvement of network performance is not as sharp as that which we obtained in downtown model.
The main reason is that the node density in highway model is relatively low. Firstly, lower node density leads to less number of RREQs flooding in the network (referring to Figures 11 and 15). The number of RREQs received per node per second in highway model is about 80% of that in downtown model. Therefore, packet collision in highway is slighter than in downtown. Although GBAODV weakens packet collision, it achieves no big improvement. Secondly, lower node density provides fewer choices of stable routes. If we restrict the number of RREQs, the effect caused by skipping some stable routes is larger than that in downtown model. That is the reason why the reduction of the number of RERRs in highway model is less than that in downtown model (referring to Figures 12 and 16).
To conclude, GBAODV is much better than AODV in both models. It releases the load of the network (less number of RREQs), reduces broken links and packet loss ratio, and shortens average end-to-end delay.

Vehicle Information Sinking Network Based on Mobile Nodes [35]
Aside of the mobile V2V network, the information from the vehicles should also be sent to the sink node, which will be normally performed by the roadside infrastructure. However, the construction of these infrastructure networks is expensive in both funding and time. Hence, mobile node acted by vehicles can firstly serve as the sinking port. This section elaborates a data gathering algorithm based on swarm intelligence. Although the computational resource and energy source of the on-board computer in vehicles, compared to field wireless sensor nodes, is abundant, applications may need to be extended to bicycle riders, with limited energy source. The transmitted information in the future will be extended as there will be applications aside of accident reporting, such as cloud computation, media access, and entertainment through the V2V and V2I network. Hence, in order to maximize the overall network efficiency, communication load of each vehicle node ought to be balanced.
Much reference can be made from the current research on hand-held devices such as 3G mobile phone and PDA, which play role as mobile sink of wireless sensor network (WSN) node in applications [36,37]. Thus the algorithm for the data gathering application should support the sink node mobility. It is a challenge in WSN algorithm design.
Based on the application of the sensor network, the data delivery model to the sink node can be categorized into three types: query-driven, event-driven, and continuous. In query-driven model, the sink node generates a query, and then a temporary route is built. The node which is checked receives query and returns result, for instance, DD [38] and ACQUIRE [39]. In event-driven model, because the event rate is much lower without temporal and spacial information, the event node triggers the data transmission and temporary route building, such as Rumor routing [40] and TTDD [41]. Focusing on these two types of data transmission model, the routes are temporary, so the sink node mobility has little influence on data transmission. In the continuous delivery model, each sensor collects data periodically and sends data to the sink node for gathering. In data gathering application, the sink node builds the route usually; for instance, it has been concluded in TEEN [42], APTEEN [43], and MINA [44]. However, movement of the sink node often results in broken links. If the route is rebuilt frequently, not only the network energy consumption will be large, but also the regular data transmission will be blocked by the network storm, which will result in massive broadcasting messages.
Sink mobility brings new challenges in data gathering application, although some protocols and mechanisms have been proposed in recent years, such as TDD, SEAD [45], CODE [46], and others in [47,48]. TTDD uses a grid structure so that only sensor located at the grid points needs to acquire the forwarding information. The route path for the moving sink node is maintained and refreshed by agent nodes. When there are several data sources in the network, the overhead is large. Meanwhile, the route needs to be rebuilt when the sink node moves out of the grid. SEAD protocol designs a dormancy mechanism for the nodes in grid to reduce energy consumption. The current route extends and recovers by itself while the sink node moves, but time delay remains a problem. CODE does not need to rebuild global path, but it needs other routing protocols to support, so the protocol is more complex. A local routing restoring mechanism is proposed in [47] that the sink node sends Sink Claim message periodically. This message is used for the sink node detection. The sensor node would change its status according to this message. The main problem of this method is the large consumption caused in sending the Sink Claim message in high frequency. Meanwhile, the throughput becomes smaller. As described in above, TTDD, SEAD, CODE, and others in [47,48], they are all designed for query-driven or event-driven transmission model, so these methods are not much suitable for data gathering application.
For data gathering application in V2I, this section studies the equilibrium mechanism and proposes a swam intelligence data gathering algorithm for mobile sink (SIDGMS). The idea of SIDGMS algorithm is derived from swarm intelligence such as ants. In this algorithm, each vehicle node is a smart individual but with limited knowledge. SIDGMS defines two simple rules to describe the data forwarding. The problem how to choose next hop becomes multiobjective programming, which considers both the delay and load of the network. To solve link-break problem, a method of the power control for the Sink beacon message is proposed.

SIDGMS Algorithm.
The idea of SIDGMS algorithm is derived from swarm intelligence. The preying behavior, as a typical behavior of swarm intelligence, has simple rules. If an individual discovers food, others will observe and study local behavior from the individuals in the region. As a result, everyone in group can find food.
Each node in a wireless sensor network (WSN) system has limited computational ability, memory space, energy, and wireless transmission range, so the nodes can only exchange information with neighbor nodes within the wireless communication range.
Sink Figure 19: The structural relationship between the sink and vehicles.
Sink node can be regarded as food source, and the process of data gathering can be regarded as swarm foraging action. The sink node and other nodes are mapped on Figure 19.
The principle of data gathering works as below.
(i) The sink node broadcasts beacon periodically, which contains its current location information.
(ii) The internal nodes discover the sink node directly and start the data transmission with the sink node.
(iii) Meanwhile, the external nodes detect the data transmission between the internal nodes and the sink node, which helps the external nodes discover the sink indirectly and triggers the data transmission between them if needed.
(1) SIDGMS Algorithm Mechanism. In this algorithm, the nodes in WSN system can be separated into two types, the sink node with mobility and the sensor nodes. Two messages are defined as below.
Message 1. SINK BEACON (sinkInfo), which is sent by the sink node to inform sensor nodes. sinkInfo includes the location component ( , ) and sequence number seq, which is incremental.
Message 2. SENSOR DATA (nextAddr, data, sinkInfo, load-Info), which is sent by sensor node. The sensor node collects its vehicular information (data) and then forwards it to nexthop node (nextAddr). The latest sink location component (sinkInfo) and load information component (loadInfo) are included in this message. During the data transmission period, the sensor node saves location component of the sink node and refreshes this component once it receives a new one, which could be identified by the sequence number component (seq). At the same time, the sensor node changes its status according to the SINK BEACON message. The status of sensor node is defined as follows International Journal of Distributed Sensor Networks 13 Definition 1. If sensor node receives the SINK BEACON message at a interval time ( is the periodic time of SINK BEACON), the sensor node marks its status as Sink Adjacent (SA). Otherwise, it marks its status as Nonsink Adjacent (NSA).
According to different status of the sensor node, the algorithm has different data forwarding rules, which are listed as follows.
Rule 1. If the sensor node status is SA, the data is forwarded to the sink node directly.

Rule 2.
For any sensor node in NSA status, it has two criteria to choose next hop. The first criterion is for less delay, and the other is for load balance of the network.
Generally, the sensor node which is closer to the sink node has less jumping hops, so its delay is smaller.
For any sensor node , the distance from the sink node is calculated according to (4) as below: For any sensor node which is in NSA status, the best sensor node for next hop considering the fast transmission is solved according to (5): where ( ) denotes the neighbor nodes of the node . It is a complicated problem to calculate the loading of each sensor node. However, it can be estimated in two ways. In one hand, the key to maximize the WSN lifetime is to reduce energy consumption in each sensor node. We assume that each sensor node has the same hardware equipment. Thus the remaining battery energy in each node should be considered.
On the other hand, the time to forward messages in a WSN system is closely related to the network performance, such as the packet loss rate, time delay, and network congestion. Therefore, the total time of forwarding action could be used as indicator of the network loading. It could be denoted by the number of package buffer queue.
This mathematical model is elaborated as below.
Definition 2. The loading of sensor node in WSN system is where ( ) denotes the loading of the sensor node , ( ) is the battery dump energy, ( ) is the mean number of the packages in the buffer queue, and is scale factor.
For any sensor node which is in NSA status, the best sensor node for next hop considering the load balance is calculated by Sink J  is defined as the distance weight coefficient with the sink node, and is defined as the loading weight coefficient for the sensor node.
The final optimization considers both the aspects of faster transmission and power balance, as below: where 0 is the minimum distance and 0 is minimum loading. The distance weight coefficient and the loading weight coefficient are interrelated with application. For some applications which require high real-time response, would be increased. For some applications which focus on the energy equilibrium, will be increased. ( ) < ( ) to prevent looping back.

Power Control Strategy
(1) Node Coverage Radius. The sink node broadcasts SINK BEACON periodically. However, no matter how frequently the sink node broadcasts the SINK BEACON message, packet loss would happen. That is because the linkage between the sink node and a sensor node in boundary area is fragile, due to the movement of the sink node. This case is shown in Figure 20, in which all the sensor nodes and sink node have the same transmission radii.
In order to solve this problem, we propose a new strategy to avoid link breaking, as shown in Figure 21. The transmission radius of the sink node is smaller than that of the sensor nodes. At present, most of the microcontrollers for WSN can support this by power control, such as CC2430, CC1100, and MC132x.
How to determine the transmission radius of the SINK BEACON? As proposed in [49], with assumptions that the density of nodes is uniform and all nodes in WSN domain are subject to the Poisson distribution, the probability that nodes exist in area is Therefore, the problem of radius could be translated into (10) as follows: where is the confidence, which denotes the probability that SA node appears. Finally, the radius can be determined as (2) Cycle Time of SINK BEACON. It is shown in Figure 22. In this case, we assume the movement velocity of the sink node is , the transmission radius of SENSOR DATA message is , and the transmission radius of SINK BEACON message is ( < ). Hence, cycle time of the SINK BEACON message should satisfy this condition: ≤ − . Therefore, the cycle time of the SINK BEACON is calculated as follows: For example, if the transmission radius of SEN-SOR DATA is 100 m, the transmission radius of SINK BEA-CON is 50 m, and the moving velocity of the Sink node is 10 m/s, representing that the sinking vehicle moves slowly on the road; the max cycle time of SINK BEACON is 5 s.

Experiment and Analysis.
The simulation for evaluating SIDG-MS algorithm is implemented with NS2.
(1) Implementation of SIDG-MS Algorithm. The sink node takes charge of sending SINK BEACON and data gathering. The pseudocode is listed in Pseudocode 1.
The sensor node collects vehicular data and forwards to the sink. It runs in distributed mode and the pseudocode in every node listed in Pseudocode 2.
(2) Test Scenario. The simulation scenario is designed according to a plane area, which is 800 meters wide and 800 meters long. There are totally 401 nodes in this WSN system,  including 1 sink node and 400 sensor nodes. The sink node moves randomly in the network with a constant speed 10 m/s. The sensor node collects the sensor data at a time interval every 10 s and its initialization energy is 50 J. Other simulation parameters are listed in Table 6. We assume the energy consumption for collecting data is 1 × 10 −5 J, the energy consumption for receiving data is 5 × 10 −5 J, and the energy consumption for transmitting data is 1 × 10 −4 J. The value of SINK BEACON transmitting radius calculated according to (11) is larger than 50 meters ( ≥ 50 m); in this simulation it is initialized as 80 meter. The transmission radius of the sensor node for SEN-SOR DATA message is initialized as 150 m. The periodic time of SINK BEACON calculated according to (12) is smaller than 7 s ( ≤ 7 s), so is initialized as 5 seconds.
(3) Simulation Result and Analysis. The more incoming and outgoing message in MAC layer, the larger energy consumption will be. Therefore, we calculate the network energy consumption of every interval by counting the communication message in MAC layer is. The simulation result is shown in Figure 24, which illustrates the energy consumption character of SIDGMS, Huang et al. [47], and Lee et al. [48] algorithms. When the sink node is in motion, the energy consumption in literature [47] increases because the route path increases. In the algorithm of literature [48], the route path to the sink node is checked during each message packet transmission, so the energy consumption runs at a constantly high level. In SIDGMS algorithm, the location of the sink node could be refreshed during the motion. Thus this strategy has less energy consumption. The network lifetime is defined as the time period until one of the nodes dies. The simulation result with different methods is shown in Figure 23. The lifetime in literature [48] is the shortest due to the large energy consumption, such as many refreshing actions for route path. The lifetime in literature [47] is shorter than SIDGMS algorithm because there is no optimization for load balance. Some node's loadings are too heavy to support long lifetime.
Time delay is an important factor of WSN system, we analyze it by monitoring the CBR stream. The simulation result is shown in Figure 25. Time delay with the SIDGMS algorithm is significantly lower than the other two algorithms.

System Integration and Experiments [7]
To test the communication system, we developed a series of hardware as experimental platforms.
6.1. Platform Integration Architecture. Figure 26 shows the system architecture including two major components: onboard integration subsystem and V2V portable subsystem.

Integration for Onboard Subsystem.
Onboard subsystem is full version for collision detection and classification, so all sensors as shown in Table 1 are installed onboard. Some main sensors are shown in Figure 27.

Integration for V2V Portable Subsystem.
In order to design low cost platform for V2V application, we also need to develop a portable system to be installed on others test car. A series of portable V2V nodes have been developed and used for real road test, as shown in Figure 28.
Currently, we implement GBAODV based on AODV-UU [50]. Two threads are running under one main process. One is for routing in the network and the other is for reading GPS data through serial port directly.

Road Test Scene.
In this section, different experiments are conducted to demonstrate the functions and performance    Table 7. GBAODV performs better than AODV in general. Although the packet loss ratio is large, this is acceptable. Since there are barriers, such as buildings, in the experiment environment, the signal attenuates rapidly. The packet loss ratio after one hop is approximately 20%. PING is round trip message. If source and destination cannot communicate directly, PING message traverses at least 4 hops. Therefore, the packet loss ratio is at least 1 − (1 − 0.2) 4 = 0.5904.
This is close to the experiment results. If the environment is clear enough, the results should be better.

Conclusion
In this paper, we presented a vehicle safety enhancement system based on wireless communication. The system can obtain vehicular signals, classify hazardous information, and make decision to trigger different actions to prevent the accident from occurrence or deterioration. To enhance the network performance, we evaluated DSDV, DSR, and AODV protocols and adopted AODV as the benchmark protocol. Thereafter, GPS information is integrated into AODV to further upgrade to GBAODV, which reduces packet loss rate and end-to-end delay, especially for downtown application in VANET. This paper also addresses V2I routing, by proposing the SIDGMS, which balances delay and network load. Simulation validates the V2I algorithm. Finally, we evaluate the V2V system by on-road test.