# On the Feasibility of Using 802.11p for Communication of Electronic Toll Collection Systems

Authors: Mei-Wen Li; Tsung-Hsun Wu; Wei-Yen Lin; Kun-Chan Lan; Chien-Ming Chou; Chung-Hsien Hsu
Journal: ISRN Communications and Networking
 (2011)

---

## Abstract

In an 802.11p (the so-called DSRC) network, the WSMP protocol is used for the communication between OBU
and RSU. Unlike a wired network, an 802.11p wireless network is prone to fading, shadowing, and interferences, which might result in high error rates. However, there is no reliability mechanism embedded in the WSMP protocol, which can become an important issue for mission-critical ITS applications such as ETC (Electronic Toll Collection). In this work, we develop a protocol on top of WSMP to build a reliable session for the message exchanges between RSU and OBU. Our protocol uses a timer-based mechanism for the message retransmission in the case of message losses. In this paper, we first describe the design of our session protocol and evaluate its performance for ETC communication in simulations. We then discuss the implementation of our protocol on the ITRI WAVE box and evaluate its effectiveness on real roads.


---

## Body

## 1. Introduction

Since the first electronic-toll-collection (ETC) systems appeared around the early 1990s, the number of ETC systems in the world has grown rapidly worldwide, and there are now more than 80 important systems in operation in more than 25 countries [1]. Any ETC system must address the following four aspects to functioning properly: vehicle identification, vehicle classification, transaction processing for collecting the toll, and violation handling [2]. Moreover, vehicle identification can be further divided into a vehicle positioning system (VPS) and dedicated short-range communication (DSRC).The implementation of the VPS of an ETC system is typically based on Global Positioning System and mobile communication (e.g., GSM) technologies, in which the OBU receives the vehicle's positioning information from GPS, automatically calculates the vehicle's road usage, and sends fee data to the control center through the GSM. However, owing to the high precision requirement for vehicle positioning in ETC applications and problems associated with GPS signal outages, this technique is still not sufficiently mature for practical application [3]. The technologies used in DSRC-based ETC systems can be classified into two categories: infrared and microwave [4]. For communication between roadside units (RSU) and onboard units (OBU) in ETC systems, several different spectrums have been proposed to be utilized for such an application, such as 900 MHz, 2.45 GHz, 5.8 GHz, or 5.9 GHz for microwave-based DSRC, as well as 870 nm for infrared-based DSRC [5, 6].The advantage of using infrared is its simplicity. However, this technology has some drawbacks. For example, infrared signals are easily to be affected by environmental factors such as climate and windshield glass. In addition, the speed of passing cars cannot be too fast, and the transmission range is rather limited. For an ETC system, a sufficient communication duration is necessary to allow for complete transfer of all the information between an OBU and an RSU when vehicles are rapidly traveling through the communication area [1, 7]. Moreover, infrared can only handle cars in one lane, since line-of-sight transmission must be used. Recently, the DSRC-based ETC technique has been developed to increase the precision of the Multi-Lane Free Flow (MLFF) method [8, 9] and optimum configuration [10]. The objective of MLFF ETC is to reduce congestion at toll plazas, limit environmental pollution, and increase road safety. Currently, full electronic toll payment systems are being extensively implemented in countries such as Australia, USA, Chile, and Canada [11]. However, to the best of authors' knowledge, a practical MLFF system employing infrared is not yet available [5]. In contrast, microwave-based DSRC can handle cars from server lanes, and its radio range and transmission throughput are better than those achieved with infrared.In this work, we set out to understand the feasibility of using microwave-based DSRC for ETC applications via simulations and field experiments. Recently, several studies have been conducted to analyze and study the communication characteristics of 802.11 b/g or 802.15.4 (ZigBee-) based wireless networks [12–16], and the results have shown the unpredictability and wide variability of wireless links. However, to date, the 802.11p-based DSRC communication system has not yet been fully evaluated and analyzed through field experiments in a systematic manner for ITS applications. Meanwhile, the observations made based on WLAN technology cannot be applied to 802.11p-based wireless communication systems, due to the different spectrums used and several technical and environmental differences.The characteristics of DSRC wireless communication and its link-level behaviors thus remain unclear to the research community, which may hinder efficient design and rigorous evaluation of the ITS system. In this paper, we focus on one of the most important performance metrics for mission-critical ITS applications: reliability. The major aspect of communication performance of interest to researchers and engineers is the reliability of the 802.11p wireless communication itself, while end users (drivers) mainly care about whether ITS applications based on DSRC wireless communication can provide reliable and trustworthy application service. The objective of this paper is to design a protocol which is simple but can efficiently support critical and road-safety applications (e.g., hazard notification to drivers), as well as useful commercial applications over an 802.11p network. To achieve this goal, we propose a novel session-layer protocol to provide reliable communication between OBU and RSU. We implement our protocol on IWCU (ITRI WAVE/DSRC Communication Unit) [17] on test it on real roads.The rest of the paper is structured as follows. In Section2, we review the prior work. We describe a session-layer protocol for providing reliable communication between OBU and RSU in Section 3. In Sections 4 and 5, we first evaluate our protocol's performance in simulations and then verify its feasibility for ETC scenario with a number of field tests. Finally, we conclude this paper in Section 6 and briefly describe our future work.


## 2. Related Works

To combat road fatalities, the US Federal Communication Commission (FCC) has allocated a 75 MHz spectrum at 5.9 GHz for vehicle-to-vehicle (V-to-V) and vehicle-to-infrastructure (V-to-I) communications. The proposed vehicular communication technology, known as the Dedicated Short Range Communication (DSRC), is currently being standardized by the IEEE [18, 19] and is known as 802.11p. Many major car manufacturers have responded positively and are actively working together to develop practical application of this promising technology [20, 21]. Although the primary purpose of 802.11p is to enable communication-based automotive safety applications, such as cooperative collision warning (CCW), this new standard also facilitates for a range of nonsafety applications, from electronic toll collection to multimedia downloading. The motivation for allowing nonsafety applications over 802.11p is to create commercial opportunities, thereby making the DSRC technology more cost-effective. Commercial operators wishing to conduct business over DSRC will be expected to acquire the appropriate spectrum licenses.The 802.11p standard defines a MAC-layer operational mode for wireless access in vehicular environments (referred to as the WAVE model). It is designed to cooperate with the IEEE 1609 standard family [22–25], which defines the application layer and network layer for a WAVE-mode network. The 802.11p, IEEE 1609.3, and 1609.4 standards together define the operation of a WBSS (WAVE basic service set) in vehicular networks. The communication in a WBSS is carried out in a one-hop manner, for example, data exchanges are only allowed between a WBSS user and the WBSS provider, or between two neighboring WBSS users.The V-to-I architecture allows vehicles to communicate with some roadway infrastructure and can enable many promising ITS applications. For example, the speed and location of a vehicle can be transmitted to a central server by directly or indirectly connected to the road side unit. This server will track the speed and location of all vehicles and will aggregate this data for ITS applications, such as determining the fastest path from a vehicle's current location to its destination or identifying the location of an incident, among other applications [26]. There are also many applications that can be supported by a V-to-I communication network, such as web surfing, multimedia streaming, and real time car navigation. For example, some prior studies [27] have focused on the use of V-to-I for web applications.Although there have been many studies focusing on DSRC, most of these have used simulations for their evaluations. Böhm and Jonsson [28] proposed a V-to-I communication solution by extending IEEE 802.11p. They introduced a collision-free MAC protocol with an enhanced prioritization mechanism based on vehicle positions and the overall road traffic density and evaluated their protocol's performance using Matlab. In [29, 30], the researchers used NS-2 to undertake a detailed simulation study of the performance of both DSRC and WiFi for vehicular networks and proposed a practical approach for IEEE 802.11 rate adaptation. In [31], an OMNeT++ simulator was used to evaluate the collision probability, throughput and delay of 802.11p. In [32], they used a QualNet simulator to compare two systems (WiMAX and 802.11p) for V-to-I communication under different vehicle speeds, traffic data rates, and network topologies.To the best of our knowledge, very few DSRC testbeds have been implemented. Keeratiwintakorn et al. [33] implemented XBee/Zigbee-based OBE (on-board equipment) and RSE (road-side equipment) for vehicle communication (V-to-V and V-to-I). In [34], the authors used an Aeroflex 3416 box to collect DSRC measurement data. Cohda Wireless [35] completed 700 DSRC trials for 15 distinct DSRC use-case scenarios in USA, Italy, and Australia. Their V-to-I scenarios were executed with the RSU mounted at intersections while a car traveled at 60 km/h, through and beyond an intersection with buildings on all corners. They compared the performance of the Cohda Radio to radios using WiFi chipsets configured for DSRC operation from several different manufacturers. They showed that the connection provided by the radio using a WiFi chipset is limited in range and capacity for data transmissions, making it unattractive for multiple user access.Many session-layer protocols that have been previously developed. For example, OSI has defined X.215, X.225 (connection-oriented session protocol), and X.235 (connectionless session protocol) [36–38]. For the TCP/IP suite, protocols such as SIP [39], SDP [40], and SAP [41] have been proposed and now standardized. Others like ADSP [42] and PAP [43] for AppleTalk and NWLink [44] for IPX were also developed for different contexts. However, these existing session protocols were mostly designed for a (unicast-type) wired network, like the Internet, and are not suitable for a lossy wireless environment. When using existing protocols in a wireless environment, data/ACK implosion might occur, which further introduces excessive collisions, packet losses, long delays, and so on. These problems could all affect system reliability, which is one of the most important performance metrics for mission-critical ITS applications. Therefore, given that there is no reliability mechanism embedded in the WSMP protocol, in this work, we design a novel session-layer protocol on top of 802.11p for reliable vehicular network communication in an error-prone wireless environment. We also implement our protocol using the IWCU made by Industrial Technology Research Institute (ITRI), which implements the IEEE 802.11p standard and operates at 5.85–5.925 GHz with built-in GPS capability. Furthermore, we evaluate the performance of our protocol for ETC applications via extensive simulations and field experiments.


## 3. Protocol

Achieving high reliability is a challenging issue for automotive safety and nonsafety applications, such as collision warning and electronic toll collection. Although 802.11p has become an emerging standard for vehicular communication, it does not provide any reliability mechanism to handle situations in which packet loss occurs. In this work, we propose a simple session-layer protocol on top of 802.11p for reliable vehicular network communication. The protocol can be divided into three phases: session creation, data transmission, and session closing/suspension. We define ten session messages in this protocol, and their formats are shown as in the appendix.A session management agent runs on top of 802.11p/WSMP (WAVE short message protocol) on the OBU and RSU. This agent is responsible for tracking the connection state of the session and provides a reliability mechanism for data retransmission when packets are lost. The architecture of our protocol is shown in Figure1. The normal protocol operations can be divided into three phases: session creation, data transmission, and session closing/suspension as follows.Figure 1
The architecture of our protocol.


### 3.1. Session Creation

In this protocol, we use a three-way handshake to create a session. First, RSU periodically broadcasts <INVITE> and its ownRid. When any OBU hears <INVITE>, they can reply an <ACCEPT> with its Vid (vehicle ID). Once RSU hears <ACCEPT>, it will create a corresponding state for [Vid, sno], where sno is session number and broadcast <SESSION> message to the air so that the OBU knows a session is created. A session timer (sRTT) will be initialized when each session is created. The value of sRTT is also embedded in the <SESSION> message broadcast by the RSU.


### 3.2. Data Transmission

After the session is created, RSU and OBU can then start sending <DATA> to each other and wait for an <ACK> back from the other side. <ACK> and <DATA> can be piggybacked.


### 3.3. Close Session

Either OBU or RSU can send <BYE> to close the session. After the session is closed, the state info for [Vid, sno] will be removed. RSU also can close the session after N (say, three) retransmissions without receiving ACK from the OBU.


### 3.4. Suspend Session

RSU can send a message <SUSPEND> to OBU to temporarily suspend the session. After hearing <SUSPEND>, the data transmission and session timer on OBU will be suspended. If OBU hears any <DATA> that targets it, the session timer on OBU can be reactivated. The reliability of data transmission is achieved through the use of a session timer for data retransmission, as described below.


### 3.5. Data Retransmission

After the session is created, if RSU has any data to send to OBU, it can then send this in the form of <DATA, seq, sno, Vid, rssi>, where seq is the sequence number of the data and rssi is the RSSI value recorded at the most recently received packet from OBU. If RSU does not hear an <ACK> back from OBU after the session timer is expired, the data is resent. The same mechanism is also implanted on the OBU. In addition, DATA and ACK can be piggybacked.


### 3.6. Session Timer

The session timer is setup based on the measured RTT between OBU and RSU. Session timer is used to decide when OBU/RSU should retransmit the data. RSU remeasures the RTT for every data exchange with OBU, and the session timer is reset as follows:(1)sRTT=α⋅RTTnew+=(1-α)⋅sRTTold.


### 3.7. SIGNAL and RSSI Messages

In this protocol, we also use the measured signal strength level (RSSI) to estimate the distance between OBU and RSU, assuming the distance between them decreases as the measured RSSI value increases. RSU can query the RSSI level of the link by broadcasting an <RSSI> message. When OBU hears <RSSI>, it will reply with a <SIGNAL> message together with its (sno, Vid) and the rssi value, it hears the <RSSI> message. Our protocol can be used for a delay- and loss-sensitive ITS services, like ETC applications. Currently, ETC service in Taiwan is operated over infrared, but the line-of-sight requirement of this system makes it unsuitable for multilane ETC operations. Our protocol can provide a practical solution for ETC applications, and one possible scenario is as follows. Assume that during an ETC transaction four messages need to be exchanged between RSU and OBU. After the first three messages have been exchanged, the RSU can then issue a <SIGNAL> message to suspend the session. After some time, when RSU detects there is an OBU approaching the gate, RSU can broadcast the <RSSI> message to check which OBU is closest to the RSU and exchange the last ETC message with the approaching OBU. The protocol operation is shown in Figure 2.Figure 2
Traffic model.In a 802.11p wireless network, packet loss might occur due to fading, shadowing, and interference. Existing session protocols are mostly designed for wired networks, like the Internet, and not suitable for a lossy wireless environment. Here, we use a timer-based protocol to ensure the reliability of data transmission in a 802.11p network. Furthermore, to reduce the possible packet collision, we implement a backoff mechanism in our protocol. When OBU overhears there is an ongoing session message targeting the same RSU with a lower session number, it will delay its transmission fort milliseconds, where t is taken from the round-trip delay distribution from previous RTT measurements during message exchanges. As an example, Figure 3 shows a flow chart for the ETC message exchange scenario using our protocol.Figure 3
The protocol operation flow chart.


## 3.1. Session Creation

In this protocol, we use a three-way handshake to create a session. First, RSU periodically broadcasts <INVITE> and its ownRid. When any OBU hears <INVITE>, they can reply an <ACCEPT> with its Vid (vehicle ID). Once RSU hears <ACCEPT>, it will create a corresponding state for [Vid, sno], where sno is session number and broadcast <SESSION> message to the air so that the OBU knows a session is created. A session timer (sRTT) will be initialized when each session is created. The value of sRTT is also embedded in the <SESSION> message broadcast by the RSU.


## 3.2. Data Transmission

After the session is created, RSU and OBU can then start sending <DATA> to each other and wait for an <ACK> back from the other side. <ACK> and <DATA> can be piggybacked.


## 3.3. Close Session

Either OBU or RSU can send <BYE> to close the session. After the session is closed, the state info for [Vid, sno] will be removed. RSU also can close the session after N (say, three) retransmissions without receiving ACK from the OBU.


## 3.4. Suspend Session

RSU can send a message <SUSPEND> to OBU to temporarily suspend the session. After hearing <SUSPEND>, the data transmission and session timer on OBU will be suspended. If OBU hears any <DATA> that targets it, the session timer on OBU can be reactivated. The reliability of data transmission is achieved through the use of a session timer for data retransmission, as described below.


## 3.5. Data Retransmission

After the session is created, if RSU has any data to send to OBU, it can then send this in the form of <DATA, seq, sno, Vid, rssi>, where seq is the sequence number of the data and rssi is the RSSI value recorded at the most recently received packet from OBU. If RSU does not hear an <ACK> back from OBU after the session timer is expired, the data is resent. The same mechanism is also implanted on the OBU. In addition, DATA and ACK can be piggybacked.


## 3.6. Session Timer

The session timer is setup based on the measured RTT between OBU and RSU. Session timer is used to decide when OBU/RSU should retransmit the data. RSU remeasures the RTT for every data exchange with OBU, and the session timer is reset as follows:(1)sRTT=α⋅RTTnew+=(1-α)⋅sRTTold.


## 3.7. SIGNAL and RSSI Messages

In this protocol, we also use the measured signal strength level (RSSI) to estimate the distance between OBU and RSU, assuming the distance between them decreases as the measured RSSI value increases. RSU can query the RSSI level of the link by broadcasting an <RSSI> message. When OBU hears <RSSI>, it will reply with a <SIGNAL> message together with its (sno, Vid) and the rssi value, it hears the <RSSI> message. Our protocol can be used for a delay- and loss-sensitive ITS services, like ETC applications. Currently, ETC service in Taiwan is operated over infrared, but the line-of-sight requirement of this system makes it unsuitable for multilane ETC operations. Our protocol can provide a practical solution for ETC applications, and one possible scenario is as follows. Assume that during an ETC transaction four messages need to be exchanged between RSU and OBU. After the first three messages have been exchanged, the RSU can then issue a <SIGNAL> message to suspend the session. After some time, when RSU detects there is an OBU approaching the gate, RSU can broadcast the <RSSI> message to check which OBU is closest to the RSU and exchange the last ETC message with the approaching OBU. The protocol operation is shown in Figure 2.Figure 2
Traffic model.In a 802.11p wireless network, packet loss might occur due to fading, shadowing, and interference. Existing session protocols are mostly designed for wired networks, like the Internet, and not suitable for a lossy wireless environment. Here, we use a timer-based protocol to ensure the reliability of data transmission in a 802.11p network. Furthermore, to reduce the possible packet collision, we implement a backoff mechanism in our protocol. When OBU overhears there is an ongoing session message targeting the same RSU with a lower session number, it will delay its transmission fort milliseconds, where t is taken from the round-trip delay distribution from previous RTT measurements during message exchanges. As an example, Figure 3 shows a flow chart for the ETC message exchange scenario using our protocol.Figure 3
The protocol operation flow chart.


## 4. Evaluation Using Simulations

In order to evaluate the performance of our protocol for ITS applications, we perform extensive simulations for a variety of scenarios using NS-2 [45]. Here, we consider the application of our protocol for ETC (Electronic Toll Collection). The simulation environment is shown in Figure 4. There are three lanes for each direction. Each lane consists of fifty cars which are equipped with OBU. The total length of each lane is 2000 m, and the RSU is located at the middle point of the lane. The width of each lane is 3.5 m, and the radio range is 150 m. In this work, we consider the effect of three factors on the protocol performance: packet size, intercar distance, and car speed.Figure 4
Simulation environment.As shown in Figures5 and 6, the success rate generally is reduced when the intercar distance is small or when cars are moving at high speed. A small intercar distance suggests a high network density, which might result in a higher probability of packet collision. On the other hand, it is likely a car will be out of radio range quickly when it is moving at high speed. In addition, we observe that using a larger packet size can result in a lower success rate. This is due to two reasons. First, when a larger packet size is employed, the RSU needs to spend more time transmitting/receiving the packet and therefore might drop the newly incoming packets. Second, a larger packet has a higher probability to collide with other packets in the air, which was observed in some previous studies [46].Figure 5
Success rate with a packet size of 100 bytes at varying speeds.Figure 6
Success rate with a packet size of 1000 bytes at varying speeds.We find that most of the failures in simulations can be divided into two cases. The first is because there are too many collisions so that the packet is retransmitted over and over again until finally the maximum number of retransmissions (N=3 in our simulation) is reached and the packet is dropped. The other case is because, although the retransmission is successful, the car is already out of radio range when the packet is retransmitted, as the car is traveling at a high speed.


## 5. Field Test

We implement our protocol using the IWCU made by Industrial Technology Research Institute (ITRI) on top of the IEEE 802.11p standard. In this section, we first look at some basic 802.11p performance measurements. We then use four IWCU boxes to simulate the ETC scenario in order to understand the performance of our protocol in the real world.We first look at the latency of 802.11p and compare it with that of WiFi. As shown in Table1, we find that the latency is generally lower than 2 ms when the vehicle is moving at a speed lower than 60 km/hr and RSU is within the radio range. We also measure how long a car can maintain a connection with the RSU when it passes the unit. Here, we define the contact duration as the longest interval between when the first packet was sent by the car and the time when the last packet was received by the RSU. We start the car at a position where it is out of the radio range of RSU, gradually increasing the car's speed and achieving the desired speed at the “start” point. The same speed is maintained from the “start” to “end” points. The distance between “start” and “end” is 200 m.Table 1
V-to-I latency evaluation.
802.11aDelayLoss802.11pDelayLoss20 Km/h2 ms0%20 Km/h1.5 ms0%40 Km/h2 ms10%40 Km/h1.5 ms0%60 Km/h2.5 ms10%60 Km/h2 ms0%As there is no authentication/association process in 802.11p, it can set up a connection with the AP much faster than 802.11a can, as shown in Table2. This means that a 802.11p-equipped car can send much more data to the road-side unit than when 802.11a is used. At the speed of 60 Km/hr, the contact duration can be as long as 14 seconds, which is able to support some TCP-based applications like email or instant messaging (e.g., MSN). As shown in Figure 7, the probability of having consecutive packet loss for 802.11p is also significantly lower than that of WiFi, for either line-of-sight (LOS) or non-LOS (NLOS) condition. The throughput of 802.11p depends on the underlying modulation used.Table 2
Contact time.
802.11aTime (sec)802.11pTime (sec)20 Km/h4.520 Km/h38.540 Km/h040 Km/h1960 Km/h060 Km/h14Figure 7
The distribution of consecutive packet losses.Four different modulations are currently supported by 802.11p, namely, BPSK (1/2), QPSK (1/2), 16QAM (1/2), and 64QAM (3/4). Theoretically, their corresponding data rates are 3 Mbps, 6 Mbps, 12 Mbps, and 27 Mbps, respectively. We measured the throughput of 802.11p based on different modulation schemes for various distances. We used 16 dbm (with 5 dbi omnidirectional antenna gain) as the transmission power level due to hardware limitations. The parameter settings are shown in Table3. To avoid disturbance from passers-by and moving cars, we collected our measurements at midnight. We placed the RSU at a height of 3 m on top of a pole. To understand the performance of 802.11p under different bit rates, we measured the throughput of 802.11p over various distances. Theoretically, different modulations have different sensitivity levels. The sensitivity level is defined as(2)Sensitivity=Rx⋅noisefloor+SNRmin⁡,
where the SNRmin is the minimum SNR needed to obtain the wanted BER. A higher bit rate requires a higher SNR; hence, the transmitted signal experiences degradation as the distance between the sender and receiver increases, as a receiver with a high bit rate is not available to decode bits, and this may introduce high bit error rate. As shown in Figure 8, the achievable throughput of 802.11p is significantly lower than its theoretical counterpart (here we use the log-normal path loss model to model the radio propagation and calculate the theoretical throughput), although their curves are quite similar. The highest achievable data rate using 64QAM is about 18 M when the car is very close to the road side unit (<25 m). The longest distance we can achieve with a throughput greater than 2 M is 150 m, when BPSK is employed. In addition, we observe the variation of throughput becomes larger when we increase the data rate from BPSK to QAM, which is particularly obvious when the car and the road side unit are at a closer distance, as shown in Figure 8(b).Table 3
Parameter settings.
ParameterSettingModulationBPSK, QPSK, 16QAM, 64QAMTransmit power16 dbmSending rate*127 MbpsSending time3 minutesPacket size*21400 bytesPacket typeWSMPTrafficCBR, one-way*1maximum data rate.*2maximum packet size of WSM explained on [24].Comparison of theoretical and measurement throughputs for different modulations over various distances.
(a)
Theoretical throughput(b)
Measurement throughputFinally, we consider the relation between RSSI and distance. One possible way to infer if the OBU is approaching RSU is by examining the obtained RSSI value. Theoretically, when the distance between RSU and OBU is shorter, the RSSI value is bigger. Our results, as shown in Figure9, indicate that there is a decreasing trend between the RSSI value and the distance, and the car's speed does not affect the RSSI value significantly.Figure 9
RSSI value in different distances with different speeds.We implemented our protocol on the ITRI IWCU box and perform the following experiments on a local road to evaluate the success rate of the proposed protocol. The parameter setting of IWCU box is shown in Table4. Due to the hardware limitations, we used four IWCU boxes to simulate the ETC scenario. The maximum allowable speed of the road is 60 km/hr. Each experiment was performed for ten times.Table 4
The common parameter setting of all experiment.
Channel number172 CH: (5860 MHz)Data rate6 (Mbps)Transmission power16 dBmDATA packet size100 BytesTable 5(i) INVITE messages formatProtocol Version∣Timestamps∣“INVITE”∣RSU ID(ii) ACCEPT messages formatProtocol Version∣Timestamps∣“ACCEPT”∣OBU ID(iii) SESSION messages formatProtocol Version∣Timestamps∣“SESSION”∣SESSION ID∣RSU ID∣OBU ID(iv) DATA messages formatVersion∣Timestamps∣“DATA”∣SESSION ID∣OBU ID∣Message ID∣RSSI∣Palyload(v) ACKDATA messages formatVersion∣Timestamps∣“DATA”∣SESSION ID∣OBU ID∣Message ID∣ACK ID∣RSSI∣Palyload(vi) ACK messages formatVersion∣Timestamps∣“ACK”∣SESSION ID∣OBU ID∣ACK ID∣RSSI(vii) SUSPEND messages formatProtocol Version∣Timestamps∣“SUSPEND”∣SESSION ID∣OBU ID(viii) SIGNAL messages formatProtocol Version∣Timestamps∣“SIGNAL”∣RSU ID(ix) RSSI messages formatVersion∣Timestamps∣“RSSI”∣SESSION ID∣OBU ID∣RSSI(x) BYE messages formatProtocol Version∣Timestamps∣“BYE”∣SESSION ID∣OBU ID


### 5.1. 3RSU-1OBU

This scenario is shown in Figure10. The car maintains its speed at 60 km/hr when within the radio range. The OBU only communicates with the RSU1. The other two RSU periodically send <INVITE> message to create interference. We adjust the frequency of <INVITE> message from 1 sec, 0.1 sec, 0.01 sec, to 0.001 sec to simulate different levels of interference. A higher frequency suggests higher interference and higher probability for packet collision.Figure 10
Experiment scenario diagram (3RSU-1OBU).


### 5.2. 1RSU-3OBU

This scenario is to test if one RSU can handle several OBU at the same time, as shown in Figure11.Figure 11
Experiment scenario diagram (1RSU-3OBU).In all of the above experiments, our field tests showed promising results, and we achieved a 100% success rate for all the scenarios we tested.


## 5.1. 3RSU-1OBU

This scenario is shown in Figure10. The car maintains its speed at 60 km/hr when within the radio range. The OBU only communicates with the RSU1. The other two RSU periodically send <INVITE> message to create interference. We adjust the frequency of <INVITE> message from 1 sec, 0.1 sec, 0.01 sec, to 0.001 sec to simulate different levels of interference. A higher frequency suggests higher interference and higher probability for packet collision.Figure 10
Experiment scenario diagram (3RSU-1OBU).


## 5.2. 1RSU-3OBU

This scenario is to test if one RSU can handle several OBU at the same time, as shown in Figure11.Figure 11
Experiment scenario diagram (1RSU-3OBU).In all of the above experiments, our field tests showed promising results, and we achieved a 100% success rate for all the scenarios we tested.


## 6. Conclusion and Future Work

In this work, we proposed a reliable session-level protocol on top of 802.11p for V2I communication. Such a protocol can be used for mission-critical ITS applications such as ETC. We perform extensive simulations and field tests to evaluate the performance of our protocol, and the results show that it is feasible to use the proposed protocol for ETC communication. Due to hardware and manpower limitations, we employed only four cars in our field tests. As future work, we plan to measure the performance of our protocol using a large-scale vehicle testbed (>100 nodes) by cooperating with ITRI [47] and ARTC [48] to better understand the effects of interference and packet collision in a more realistic ETC scenario.



---

*Source: 723814-2011-10-11.xml*