- Research Article
- Open Access
A Rule-Based Data Transfer Protocol for On-Demand Data Exchange in Vehicular Environment
© H.-C. Liao andW.-L. Liao. 2009
- Received: 28 March 2008
- Accepted: 14 November 2008
- Published: 25 November 2008
The purpose of Intelligent Transport System (ITS) is mainly to increase the driving safety and efficiency. Data exchange is an important way to achieve the purpose. An on-demand data exchange is especially useful to assist a driver avoiding some emergent events. In order to handle the data exchange under dynamic situations, a rule-based data transfer protocol is proposed in this paper. A set of rules is designed according to the principle of request-forward-reply (RFR). That is, they are used to determine the timing of data broadcasting, forwarding, and replying automatically. Two typical situations are used to demonstrate the operation of rules. One is the front view of a driver occluded by other vehicles. The other is the traffic jam. The proposed protocol is flexible and extensible for unforeseen situations. Three simulation tools were also implemented to demonstrate the feasibility of the protocol and measure the network transmission under high density of vehicles. The simulation results show that the rule-based protocol is efficient on data exchange to increase the driving safety.
- Intelligent Transport System
- Differential Global Position System
- Differential Global Position System
- Space Division Multiple Access
- Operation Rule
The improvement of drivng safety and efficiency is the primary goal of research related to Intelligent Transport System (ITS). Many researchs attempt to develope systems to acquire data from sensors on a vehicle and produce useful information for driving assistance. A vehicle can even disseminate the information to nearby vehicles for the same purpose in vehicular environment. However, a driving vehicle is under highly dynamic and complex environemnt. It is very difficult to develop an automatic driving system to handle any exceptional situations. Therefore, some studies propose driving-assistant approaches to improve driving safety under emergent situations. For example, Toyota proposes a human-oriented image restructuring (HIR) system . The system reconstructs real-time image when a vehicle is under some emergent situations. For example, when a vehicle is ready to turn left at the intersection and another vehicle in the reverse direction is stop in front of it for waiting, the image behind the stop vehicle is transmitted and displayed on the front windshield glass to assist the driver on preventing possible accident, for example, the coming of a motorcycle suddenly. Besides, Sugiura and Dermawan proposed an intervehicle communication (IVC) and road-to-vehicle communication (RVC) system for providing information services in traffic jam area . The system utilizes Bluetooth technology to communicate with CCD cameras installed on this vehicle or the other vehicles. The Bluetooth technology is also used between the communcations of APs (access points) on the road and mobile server inside vehicles in RVC. In addition, Wischhof et al. and Saito et al. proposed a novel method for scalable information dissemination in highly mobile ad hoc networks to increase the driving safety [3, 4].
The rest of the paper is organized as follows. Section 2 presents some related works. Section 3 presents the proposed data transfer protocol. Section 4 presents the simulation study. Section 5 gives the conclusion of our research.
One important way of ITS to increase the driving safety focuses on the data exchange among vehicles. The exchange of appropriate data with desired vehicles is helpful to assist a driver realizing a situation or preventing possible accidents. Some previous studies related to data exchange are presented as follows.
Sugiura and Dermawan proposed an IVC-RVC system for real-time image transfer via Bluetooth communication . When the servers of two vehicles are connected to each other, the real-time image can be transferred. The whole system is connected to the Internet backbone for accessing information from a data center server. However, the authors focus on the design of the system structure. The system can only operate in the traffic jam area. The system cannot provide services under the other situations.
Kato et al. proposed the application of intervehicle communications for increasing the driving safety . It utilizes differential global positioning system (DGPS) for acquiring a precise position and speed information of a vehicle. A vehicle can communicate with the nearby vehicles via dedicated short range communication (DSRC) to exchange their position and speed. The exchanged information is useful to prevent the vehicle collision for some predefined situtations. The application is useful for the advanced vehicle control and safety systems (AVCSS), such as driver assistance systems. However, the data exchange is focused on the vehicles within the range of DSRC but not many vehicles related to a specific situation, for example, a traffic jam. That is, the applications of such intervehicle communication is still limited.
Blum and Eskandarian proposed a link-layer protocol, called adaptive space-division multiplexing (ASDM) for intervehicle communications . It is used to overcome the scalability challenge under high vehicle density and the problem of denial-of-service (DoS) attacks. Wischhof et al. also proposed a method, called segment-oriented data abstraction and dissemination (SODAD), for scalable information dissemination in highly mobile ad hoc networks . Information can be distributed even if only 1–3 percentages of vehicles equipped with an IVC system. Besides, a system, called self-organizing traffic-information system (SOTIS), is also proposed for collecting traffic information for its local area. Then, the information is distribued by using SODAD method. The simulation results show that the proposed methods are feasible. However, the situation or timing for requesting or replying information is not addressed in this research. It is also an important issue of data exchange.
In advance, the prevention of broadcast storm is an important issue of data exchange. Previous studies proposed different methods to overcome such problem. For example, Saito et al. proposed a method to solve the problem by adjusting the broadcast interval according to the number of receive errors . When the number of receive errors increases, it means a broadcast storm is being formed. Therefore, the broadcast interval is increased to prevent the occurrence of the broadcast storm. Bana and Varaiya proposed an alternative way, called Space Division Multiple Access (SDMA) for overcoming the problem of broadcast storm . SDMA divides geographical space into smaller spaces. Vehicles locate their space according to the position information in order to use the network bandwidth in turns. However, SDMA relies on a high clock accuracy among vehicles (within 100 nanosecond) that is difficult to achieve in practical environment.
In order to increase the flexibility and control the timing of data exchange, a rule-based approach is incorporated into the data transfer protocol for providing automatic data exchange services. The mechanism for preventing the broadcast storm is also considered in the design of the operation rules.
Request types: the situations for data exchange must be defined firstly. They determine the possible types of requests sent by rules.
Vehicle information: the information of a vehicle is defined for the design of RFR rules.
Operation rules: the design of rules is the primary task of the protocol. The rules for sending, forwarding, or replying requests are defined and represented in the following subsections.
3.1. Request Types
Traffic jam is a common situation while driving. It is caused by some reasons, such as traffic accident, road maintenance. However, the reason is usually unknown to a driver when the traffic jam is long. Besides, the front view of a driver is easily occluded by a heavy vehicle. It causes the response time not to be enough once an accident in front of the heavy vehicle occurs. For the above two situations, it is helpful to increase the driving safety if the real-time image captured by a specific vehicle can be disseminate to the on-demand vehicles.
Request-of-nonblocking ( ): when the average speed of a vehicle is lower than a predefined value, such as 30 Km/h, it means that there may be a traffic jam situation. A request, , is broadcasted for acquiring the real-time image of vehicles at the head of a traffic jam.
Request-of-nonocclusion ( ): when the average speed of a vehicle is higher than a predefined value, it means that the vehicle is driving smoothly. If the type of the front vehicle is larger than this vehicle, a request, , is broadcasted by the vehicle to acquire nonocclused image from the front one.
3.2. Vehicle Information
The format of vehicle information and NT table.
Vehicle state: LSpeed (low speed) or HSpeed (high speed)
A request sent by the vehicle
A reqeust received by the vehicle
A reply received by the vehicle
A vehicle is an information provider or not
The distance to the information source, that is, IProvider.
3.3. Operation Rules
- (1)Rules for maintaining NT table, reasoning vehicle state, and sending a request:
Rules 1 and 2: to determine whether a received HM to be included into NT table;
Rules 3 and 4: to determine the state of a vehicle under low or high speed according to its average speed;
Rules 5 and 6: to determine the sending of requests and .
- (2)Rules for determining IProvider and replying or forwarding a request:
Rules 7 and 8: to determine whether a vehicle is responsible for disseminating information, that is, IProvider;
Rules 9 and 10: if this vehicle is an IProvider, the requested information is replied back to the following vehicles;
Rules 11 to 14: if this vehicle is not an IProvider, it forwards a request to the preceding vehicles or forwards a response to the following vehicles.
- (3)Rules for handling a response and clearing temporal information:
Rules 15 and 16: to determine the correctness of a reply informaiton.
These rules are presented in the following.
if HM.Dir – this.Dir 45 degrees, then HM is discarded.
if HM.Dir – this.Dir 45 degrees, then HM is updated to NT.
In Rules 1 and 2, the driving direction of a received HM is compared with the direction of this vehicle. If the difference is smaller than a predefined value, for example, 45 degrees, it means that two vehicles are on the same way of the same road. Therefore, the vehicle information of the HM is updated to the NT table.
if AvgSpeed 30 Km/h, then this.VState = LSpeed3
if AvgSpeed 30 Km/h, then this.VState = HSpeed.
If this.VState = LSpeed, then send .
If this.VState = HSpeed And the preceding VType this.VType, then send .
In Rule 5, if the state of a vehicle is LSpeed, it means that the vehicle may be in a traffic jam or waiting for a traffic light. Therefore, is sent to acquire the image of vehicles at the head of a traffic jam. In Rule 6, if the state of a vehicle is HSpeed and the type of the preceding vehicle is larger than or equal to this vehicle, is sent to acquire nonocclused image from the front vehicle.
If this.VState = LSpeed And the number of preceding vehicles = 0, then this.IProvider = True.
If this.VState = HSpeed And HM.RcvREQ = And the preceding VType this.VType, then this.IProvider = True.
In Rules 7 and 8, they are used to determine this vehicle becoming an IProvider according to its state, received request, and the number of preceding vehicles in the NT. When is received, the state of a vehicle is LSpeed and there is no preceding vehicle in the NT under LSpeed state. It means that this vehicle is at the head of a traffic jam. It is set as an IProvider. Similarly, when is received and the state of the vehicle is HSpeed, the rule checks whether the type of the front vehicle is smaller than this vehicle. If the above condition is true, this vehicle is set as an IProvider. The role of IProvider is canceled when the state of the vehicle is changed. It is defined in Rule 16.
if HM.RcvREQ = And this.VState = HSpeed And VID of exists in NT And this.IProvider = True, then send .
if HM.RcvREQ = And this.VState = LSpeed And VID of exists in NT And this.IProvider = True, then send .
if HM.RcvREQ = And this.SendREQ = And VID of exists in NT And is not received, then record .
if HM.RcvREQ = And this.SendREQ = And VID of exists in NT And is not received, then record .
if HM.RcvREQ = And this.SendREQ = And VID of exists in NT And is received, then forward received to recorded .
if HM.RcvREQ = And this.SendREQ = And VID of exists in NT And is received And this.SrcDist within Forward Range, then forward received to recorded .
When a vehicle is an IProvider, Rules 9 and 10 are responsible for handling the reply of the received and separately. In Rules 11 and 12, they are designed to handle a received request when the vehicle is not an IProvider and the corresponding response is not received yet. In Rules 13 and 14, they are designed to handle the same situations as Rules 11 and 12 except a corresponding response which has been received already.
Besides, an extra condition "this.SrcDist within Forward Range" is defined specially for Rule 14. For the two requests, and , is used to acquire nonocclused image from the front vehicle. It is related to a few vehicles. Therefore, the network traffic is low. Oppositely, is used to acquire the real-time image of vehicles at the head of a traffic jam. It is usually related to a large number or high density of vehicles. The network traffic is possibly blocked by broadcast storm. In order to overcome such a problem, a forward range is defined and incorporated into Rule 14 to limit the broadcast of a received . A forward range is a specific distance near the maximum radio range. A vehicle can determine whether it is within the range according to its SrcDist, that is, the distance to the IProvider. A vehicle forwards a received to the following vehicles only when it is within the forward range.
the VID must exists in NT table;
the request must be consistent with the vehicle state. VState must be LSpeed or HSpeed for or , respectively.
When a request is validated correctly, it is handled according to the following three cases:
The same type of the received request is sent by a vehicle, and the response has not been received by the vehicle.
The same type of the received is sent by a vehicle, and the response has been received by the vehicle.
The same type of the received is sent by a vehicle. The response has been received by the vehicle and the vehicle is within the forward range.
The example of Case 2 is shown in Figure 3(b). V1 sends a request to V2, but V2 has received the response of the same request from V3. Therefore, V2 forwards the received response to V1 directly according to Rule 13. Similarly, the example of Case 3 is shown in Figure 3(c). V2 forwards the received to V1 since it is within the forward range of V3.
if HM.RcvREP = ( or ) And (this.SendREQ is empty Or VID of ( or ) does not exist in NT, then discard the received response.
if this.VState is changed, then clear the recorded requests and this.IProvider = False.
In Rule 15, the vehicle checks whether the same request is sent for the received response. If the request is not sent by the vehicle or VID of the response does not exist in NT table, it means that no vehicle needs the response. The response is discarded. In Rule 16, the recorded or is used for forwarding a response. When VState of a vehicle is changed, the request type is changed, too. Therefore, the recorded or is useless and cleared. The role of IProvider is also canceled for the same reason.
In order to demonstrate the operation and estimate the network transmission of the proposed protocol, three simulation tools were implemented by using Visual C# 2005. The tools and simulation results are presented in the following subsections.
4.1. Vsg and Idst Tools
According to the above simulations under local simulation and recorded trace modes, they demonstrate that the proposed rule-based data transfer protocol is feasible on data exchange.
4.2. Network Transmission Simulation of Request-of-Nonblocking
Simulation times: it is the number of iterations to execute a simulation under the same parameter settings.
Radio range: it is the maximum distance that two vehicles can communicate over.
Forward range: it is a specific distance near the maximum radio range. For example, if the radio range is 1000 m and forward range is 100 m, the actual ranges are 900~1000 m, 1900~2000 m, 2900~3000 m, and so on. A vehicle forwards a received only when its distance to IProvider is within one of the range.
Traffic jam length: it is the length of a traffic jam to be simulated.
Vehicle distance: it is a distance range between two vehicles. An actual distance is determined dynamically according to the setting of this parameter.
The head of a traffic jam is assumed on the left-hand side. When the "Start" button is pressed, the tool arranges vehicles dynamically in a road with three lanes according to the parameter settings. The number of vehicles is shown in the "vehicle size" of "results" panel. One fixed IProvider is assigned to the first vehicle as depicted in the figure. Then, a JPEG file is assumed as the response, , and broadcasted by IProvider. The overall transfer sizes of the response from IProvider to all the vehicles with and without the limitation of forward range are accumulated separately. The results are listed in the "original size" and "limited by FR" of the figure. The only parameter differs between two examples in Figure 8 is the forward range. The forward range is 200 m in Figure 8(a). Therefore, the number of vehicles in forward range which are marked by red dashed circle is larger than that in Figure 8(b).
The parameter setting of network transmission simulation.
10 for every combination of parameter setting
Default image Size
88.6 KB ( JPEG file)
Traffic jam length
30 m, 50 m, 100 m, 200 m
5~15 m, 5~20 m, 5~30 m
The results of network transmission simulation (VD: vehicle distance, FR: forward distance, unit: MB).
5~15 m (1.968 vehicles)
5~20 m (1.477 vehicles)
5~30 m (989 vehicles)
Limited by FR
Limited by FR
Limited by FR
The criteria for requesting, replying, or forwarding information can be defined explicitly. A rule is triggered when new fact is created and the criteria are satisfied. It enables the data to be exchanged efficiently.
The role of a vehicle and the timing of data exchange are determined according to the situation of the vehicle. The on-demand feature can reduce the burden on network bandwidth. It is also shown from the simulation study.
The operation rules can be extended easily to satisfy unforeseen services of data exchange without designing from scratch for new services.
Besides, IDST tool demonstrates that the data exchanged by the proposed protocol is helpful to increase the driving safety. The defined forward range is also useful to limit the network transmission in a very low percentage of the original size. Moreover, two requests discussed in this paper are situation-specific but not time-critical. They allow the delay from the sending of a request to the receiving of the response. The proposed protocol will be refined to provide time-critical data exchange services in the future.
- Toyota K, Fujii T, Kimoto T, Tanimoto M: A proposal of HIR (human-oriented image restructuring) system for ITS. Proceedings of the IEEE Intelligent Vehicles Symposium (IV '00), October 2000, Dearborn, Mich, USA 540-544.Google Scholar
- Sugiura A, Dermawan C: In traffic jam IVC-RVC system for ITS using bluetooth. IEEE Transactions on Intelligent Transportation Systems 2005, 6(3):302-313. 10.1109/TITS.2005.853704View ArticleGoogle Scholar
- Wischhof L, Ebner A, Rohling H: Information dissemination in self-organizing intervehicle networks. IEEE Transactions on Intelligent Transportation Systems 2005, 6(1):90-101. 10.1109/TITS.2004.842407View ArticleGoogle Scholar
- Saito M, Tsukamoto J, Umedu T, Higashino T: Design and evaluation of intervehicle dissemination protocol for propagation of preceding traffic information. IEEE Transactions on Intelligent Transportation Systems 2007, 8(3):379-390.View ArticleGoogle Scholar
- Kato S, Minobe N, Tsugawa S: Applications of inter-vehicle communications to driver assistance system. JSAE Review 2003, 24(1):9-15. 10.1016/S0389-4304(02)00254-0View ArticleGoogle Scholar
- Blum JJ, Eskandarian A: A reliable link-layer protocol for robust and scalable intervehicle communications. IEEE Transactions on Intelligent Transportation Systems 2007, 8(1):4-13.View ArticleGoogle Scholar
- Bana SV, Varaiya P: Space division multiple access (SDMA) for robust ad hoc vehicle communication networks. Proceedings of the 4th IEEE International Conference on Intelligent Transportation Systems (ITSC '01), August 2001, Oakland, Calif, USA 962-967.Google Scholar
- Taleb T, Sakhaee E, Jamalipour A, Hashimoto K, Kato N, Nemoto Y: A stable routing protocol to support ITS services in VANET networks. IEEE Transactions on Vehicular Technology 2007, 56(6, part 1):3337-3347.View ArticleGoogle Scholar
This article is published under license to BioMed Central Ltd. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.