A Rule-Based Data Transfer Protocol for On-Demand Data Exchange in Vehicular Environment

Abstract

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.

1. Introduction

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 [1]. 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 [2]. 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 above studies are designed for some specific situations. The proposed approaches are not flexible enough to be extended to new requirements. Therefore, a data transfer protocol is proposed in this paper. The protocol is mainly based on rule-based approach and request-forward-reply (RFR) principle. It is flexible since rules are easily to be modified for new requirements. In order to demonstrate the rule definition and operation, two typical situations are used as examples and shown in Figure 1. When a specific situation occurs, a request is sent by corresponding rules to nearby vehicles automatically for acquiring desired data. In Figures 1(a) and 1(b), an unoccluded image is acquired from the preceding vehicle in order to realize the front situation. In Figure 1(c), the image of the foremost vehicle is acquired to realize the reason causing the traffic jam. Sixteen rules are defined for handling the data exchange under the above two situations. Besides, three simulation tools, vehicle scenario generator (VSG), information dissemination simulation tool (IDST), and a network transmission tool, were implemented. The first two tools are used to demonstrate the operation of the proposed protocol. Multiple computers are used to simulate multiple vehicles under driving situations. The last tool is used to measure the network transmission of the proposed protocol under high density of vehicles.

Figure 1

Example of two typical situations: (a) the front view is occluded on the high way; (b) the front view is occluded on the ordinary road; (c) a traffic jam.

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.

2. Related Works

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 [2]. 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 [5]. 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 [6]. 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 [3]. 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 [4]. 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 [7]. 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.

3. Approach

The proposed protocol is mainly based on the RFR principle instead of the end-to-end approach proposed by previous research [8]. For a VANET formed by vehicles, the topology is changed dramatically, especially under high-mobility situation. Vehicles are connected occasionally. Therefore, it is impractical to design an end-to-end protocol. Oppositely, the proposed protocol is designed to exchange data efficiently. For a vehicle, a request is sent under a specific situation. When a vehicle receives a request, it determines to forward it to the neighbor vehicles or reply information desired by the requester. The data exchange is based on a set of predefined rules. The proposed protocol consists of the following parts.

• (1) Request types: the situations for data exchange must be defined firstly. They determine the possible types of requests sent by rules.

• (2) Vehicle information: the information of a vehicle is defined for the design of RFR rules.

• (3) 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.

According to the above two situations happened freqently, two request types are defined in the following.

• (1) 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.

• (2) 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 necessary vehicle information is defined for the operation of rules. The information include vehicle identifier (VID), vehicle type (VType), state (VState), current position (CurPos), driving direction (Dir), and source distance (SrcDist). The information is udpated per second and broadcasted to one-hop neighbor vehicles via hello message (HM). Every vehicle also records the information of one-hop neighbor vehicles in a neighbor table (NT). The format of vehicle information is the same as NT table and listed in Table 1.

Table 1 The format of vehicle information and NT table.

3.3. Operation Rules

Sixteen rules are defined for the sending, forwarding, or replying of requests under two typical situations. These rules can be classified into the following categories.

• (1) Rules for maintaining NT table, reasoning vehicle state, and sending a request:

  • (i) Rules 1 and 2: to determine whether a received HM to be included into NT table;

  • (ii) Rules 3 and 4: to determine the state of a vehicle under low or high speed according to its average speed;

  • (iii) Rules 5 and 6: to determine the sending of requests and .

• (2) Rules for determining IProvider and replying or forwarding a request:

  • (i) Rules 7 and 8: to determine whether a vehicle is responsible for disseminating information, that is, IProvider;

  • (ii) Rules 9 and 10: if this vehicle is an IProvider, the requested information is replied back to the following vehicles;

  • (iii) 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:

  • (i) Rules 15 and 16: to determine the correctness of a reply informaiton.

These rules are presented in the following.

Rule 1.

if HM.Dir – this.Dir 45 degrees, then HM is discarded.

Rule 2.

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.

Rule 3.

if AvgSpeed 30 Km/h, then this.VState = LSpeed3

Rule 4.

if AvgSpeed 30 Km/h, then this.VState = HSpeed.

In Rules 3 and 4, AvgSpeed is the average speed of a vehicle in recent 30 seconds. The state of a vehicle is set as LSpeed when AvgSpeed is smaller or equal to 30 Km/h. Otherwise, the state is set as HSpeed. The threshold, 30 Km/h, is determined based on empirical study. A route is planned to include the normal road, highway, and traffic jam. Then, we drive along the route to log GPS coordinates every second. The driving time is approximately 30 minutes. The speeds are computed from the logged GPS coordinates and depicted in Figure 2.There are two curves in the figure. One is the actual speed and the other is the average speed in recent 30 seconds used in Rules 3 and 4. By observing the curves in the first period on the normal road, the actual speed may be smaller than the threshold, 30 Km/h. However, the average speed is still larger than the threshold (see Mark 1) to prevent the unnecessary transition of VState. Two similar situations can be found on the curves (see Marks 2 and 3). Besides, the largest average speed is 21.6 Km/h in the period of the traffic jam. The vehicle state can keep on LSpeed. According to the above analysis, the threshold, 30 Km/h, is appropriate for determining the vehicle state and prevents unnecessary state transitions.

Figure 2

An empirical analysis of the threshold 30 Km/h.

Rule 5.

If this.VState = LSpeed, then send .

Rule 6.

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.

Rule 7.

If this.VState = LSpeed And the number of preceding vehicles = 0, then this.IProvider = True.

Rule 8.

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.

Rule 9.

if HM.RcvREQ = And this.VState = HSpeed And VID of exists in NT And this.IProvider = True, then send .

Rule 10.

if HM.RcvREQ = And this.VState = LSpeed And VID of exists in NT And this.IProvider = True, then send .

Rule 11.

if HM.RcvREQ = And this.SendREQ = And VID of exists in NT And is not received, then record .

Rule 12.

if HM.RcvREQ = And this.SendREQ = And VID of exists in NT And is not received, then record .

Rule 13.

if HM.RcvREQ = And this.SendREQ = And VID of exists in NT And is received, then forward received to recorded .

Rule 14.

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.

For Rules 11 to 14, two criteria are used to validate a received request:

• (1) the VID must exists in NT table;

• (2) 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:

Case 1.

The same type of the received request is sent by a vehicle, and the response has not been received by the vehicle.

Case 2.

The same type of the received is sent by a vehicle, and the response has been received by the vehicle.

Case 3.

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 1 is shown in Figure 3(a). V1 sends a request to V2, but V2 has sent the same request type to V3. Therefore, V2 will not forward this request to the neighbor vehicles according to Rules 11 and 12. The SendREQ field of V1 is only recorded in NT of V2. When V2 receives the response of this request, it will forward the response to V1 directly.

Figure 3

The handling of a received request (a) forward (b) reply of (c) reply of .

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.

Rule 15.

if HM.RcvREP = ( or ) And (this.SendREQ is empty Or VID of ( or ) does not exist in NT, then discard the received response.

Rule 16.

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.

4. Simulation Studies

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

Vehicle scenario generator (VSG) and Information Dissemination Simulation Tool (IDST) are used to demonstrate the rule operation. VSG is used to generate the mobility script of vehicles on a road. The mobility is also influenced by a predefined traffic light as shown on the left-hand side of Figure 4. The script parameters include the vehicle number, traffic light interval, GPS update interval, and total simulation time. The generated script includes the vehicle ID, type, position, speed, and direction with respect to the simulation time as shown on the right-hand side of Figure 4. The parameters and generated scripts are saved for the simulation of IDST.

Figure 4

The screen shot of VSG tool.

IDST tool is used to test the operation of rules based on the generated mobility script. In order to increase the convenience and reality of the simulation, the simulation is separated into two modes: local simulation and recorded trace as shown in Figure 5. For the local simulation mode, all the scripts are processed and simulated in a single computer. An additional parameter, radio range, can be set before starting the simulation as show in Figure 5(a). Oppositely, the scripts are simulated by different computers under the recorded trace mode. That is, every computer is assumed as a mobile server equipped in a vehicle. All the information is transmitted over the physical communication network. The hello message (HM) is broadcasted to the other computers every second. The transmission of the requests and replies of and is also transmitted in the same way. When the mobility script is replaced by the real sensors, such as speed, GPS receiver, the computers can operate in the physical vehicle as expected.

Figure 5

The screen shot of parameter setting in IDST tool.

The mobility script generated by VSG tool is verified in the local simulation mode to ensure the correctness of data exchange controlled by the operation rules. Then, a set of computers is used to simulate the mobility scripts under recorded trace mode to ensure the correctness of data exchange in the physical network environment. A screen shot of IDST tool under local simulation mode is shown in Figure 6. It is captured when the simulation time is at 30 seconds. All the NT tables of six vehicles are listed on the right-hand side of the figure. According to the NT tables, six vehicles are separated into two groups. For the group formed by V5 and V6, two vehicles are under high-speed state (see Mark 1) and their vehicle types are the same. The front view of V6 is occluded by V5. Therefore, a request is sent from V6 to V5 (see Mark 2) and V5 becomes an IProvider as shown in their NT tables (see Mark 3). Similarly, the front view of V3 and V4 is occluded by V2. Therefore, V2 becomes an IProvider after receiving the request from V3 (see Mark 4). Besides, V3 have sent to V2 (see Mark 5). It does not forward the from V4 to V2. Only of V3 is recorded on the vehicle information of V2.

Figure 6

The screen shot of IDST tool under the local simulation mode.

In advance, the simulation of IDST tool under the recorded trace is shown in Figure 7. The screen shots of V2, V3, and V4 are shown in Figure 7(a), 7(b), and 7(c), respectively. The image on the left-hand side of the screen shot is assumed to be captured from the camera installed on the front of a vehicle. And the image on the right-hand side is received from the preceding vehicle. In Figure 7(b), V3 is occluded by V2 and the response of a request is received and shown on the right-hand part. The same request is sent by V4; therefore, the received response of V3 is forwarded to V4 as shown on the right-hand side of Figure 7(c).

Figure 7

The screen shots of IDST tool executed under the recorded trace mode (a) V2 (b) V3 (c) V4.

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

As mentioned in Rule 14 of Section 3.3, request-of-nonblocking () 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 a high density of vehicles. The network traffic is possibly blocked by the broadcast storm. A forward range is defined to prevent the occurrence of such problem. In order to evaluate the effectiveness of forward range, a simulation tool was implemented to measure the overall size of transmitting a response. Two screen shots of the simulation tool are shown in Figure 8. The parameters include simulation times, radio range, forward range, traffic jam length, and vehicle distance. They are described as follows.

Figure 8

The screen shot of the network transmission simulation tool (a) forward range = 200 m; (b) forward range = 50 m.

• (i) Simulation times: it is the number of iterations to execute a simulation under the same parameter settings.

• (ii) Radio range: it is the maximum distance that two vehicles can communicate over.

• (iii) 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.

• (vi) Traffic jam length: it is the length of a traffic jam to be simulated.

• (v) 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 is listed in Table 2. For every combination of parameter setting, the simulation times is ten. The result is the average of the ten simulations. Although the size of a JPEG file is possible from several kilobytes to hundreds of kilobytes, it will be eliminated on computing the percentage of transfer size. The default image size is assumed as 88.6 KB for a JPEG file. Besides, the length of a traffic jam is five kilometers. The radio range of vehicle-to-vehicle (V2V) communications, such as IEEE 802.16e, IEEE 802.20, or 5.9 GHz dedicated short range communications (DSRC), is from several hundreds of meters to several kilometers. The radio range in the simulation is set to one kilometer. Four different forward ranges and three vehicle distances are used to understand their influences on network transmission.

Table 2 The parameter setting of network transmission simulation.

The simulation results are listed in Table 3. The average number of vehicles is decreased from 1968 to 989 as the increasing of vehicle distance from 5~15 m to 5~30 m. The decreasing of vehicles also causes the quick decreasing of original transfer size to less than one-third of 5~15 m's original size. The original size is independent of the forward range. The transfer size limited by the forward range is decreased as the decreasing of the forward range. Therefore, the percentage of the size limited by the forward range to the original size is decreased as the decreasing of the forward range. In addition, when the vehicle distance is small, that is, the average number of vehicles is large, the percentage is low, too. For all the three different vehicle distances, the percentage is only from 0.009 to 0.11. It shows that the proposed rule-based data transfer protocol is useful to prevent the occurrence of broadcast storm by incorporating the location information and the limitation of forward range.

Table 3 The results of network transmission simulation (VD: vehicle distance, FR: forward distance, unit: MB).

Besides, the design of a system based on the proposed protocol is shown in Figure 9. The data received from vehicle sensors, GPS receiver, or wireless communication may be packaged as a camera image or a fact, and updating the NT table. The generation of a new fact triggers the operation of reasoning engine based on the operation rules and NT table. The reasoning result may allow a received image to be displayed on the user interface or activate the RFR operation (request, reply, or forward). The block diagram is helpful on fulfilling the proposed protocol in a vehicular system.

Figure 9

The block diagram of a system based on the proposed protocol.

5. Conclusion

In this paper, a protocol based on a set of operation rules is defined for the on-demand data exchange in vehicular environment. When two or more vehicles are close to each other, the protocol can be operated automatically to enable the data exchange among vehicles. The contributions of this paper are listed as follows.

• (1) 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.

• (2) 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.

• (3) 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.