Professional Documents
Culture Documents
A GNU Radio Based Testbed Implementation with IEEE 1609 WAVE Functionality
Scott Biddlestone and Keith A. Redmill
I. I NTRODUCTION
At Ohio State Universitys Control and Intelligent Transportation Research Lab (CITR), multiple Vehicle to Vehicle
(V2V) and Vehicle to Infrastructure (V2I) messaging specifications are developed, implemented and studied. These
specifications can use very different encodings, frequencies
and modulations. To build a testbed for testing and teaching
these different messaging specifications, we have recently
turned to software defined radio (SDR). SDR allows us to
reconfigure a communication device for different messaging
schemes in software. The software package we chose to
attempt to implement the recent Wireless Access in Vehicular
Environments (WAVE) specification with is GNU Radio[1]
and the hardware platform is the Universal Software Radio
Peripheral (USRP). In this paper, we will propose a plan for
implementing unique parts of the WAVE network stack with
GNU Radio and the USRP, coming as close to the standards
as possible.
A. GNU Radio and the USRP
GNU Radio is a software defined radio package designed
to implement common radio functions that run on a host
computer. GNU Radio itself is not capable of transmitting or
receiving radio signals without the help of external hardware.
GNU Radio recommends the use of the Universal Software
Radio Peripheral (USRP) which was especially designed
for use with GNU Radio. The USRP is made by Ettus
Research[2].
The authors are with the Department of Electrical and Computer
Engineering, The Ohio State University, Columbus, OH 43210 USA.
redmill@ece.osu.edu
Fig. 1.
29-3-2-2
B. WAVE Specification
The WAVE specification is broken into five different standards. These IEEE Standards are 802.11p, 1609.1, 1609.2,
1609.3, and 1609.4. The relationship of these standards in
WAVE is shown in Figure 2.
Fig. 3.
Fig. 2.
PPDU breakdown
29-3-2-3
before timeout then the packet will be retransmitted. When a
receiver finishes demodulating a packet it immediately builds
an acknowledgment packet and sends it. These features are
reusable for any 802.11 type network.
This implementation of 802.11b not compatible with a
real 802.11b system primarily due to speed constraints. USB
version 2.0 limits our maximum bitrate and simultaneous
sending and receiving reduces the rate even further. This
constraint also makes it extremely difficult to implement
OFDM using BPSK. However, if an OFDM scheme is created the 802.11b PLCP can be used as a base for constructing
and decoding 802.11p messages. The other major difference
this implementation will have with 802.11p is frequency.
We currently use 2.3-2.9 GHz daughter cards while 802.11p
calls for a 5.9 GHz transceiver. Unfortunately, due to USB
speed limitations between the processing PC and the USRP1
and a the lack of a daughtercard capable of transmitting and
receiving at 5.9 GHz, a full speed, standard-compliant WAVE
device will impossible to implement with the USRP1 at this
time.
Fig. 5.
29-3-2-4
TABLE I
EDCA PARAMETERS FOR CCH
ACI
1
0
2
3
AC
Background
Best Effort
Video
Voice
AIFSN
9
6
3
2
CW Range
15
7
3
3
Fig. 6.
29-3-2-5
The channel frequencies are as 2.42 GHz for the CCH,
2.44 GHz for the SCH and 2.46 GHz for the C2C channel.
These frequencies were chosen by using the spectrum analyzer, that is part of the GNURadio package, to determine
relatively unused frequencies around our lab.
Three test scenarios are described below. The first is to
show the proper operation of the priority queues using only
safety messages. The second scenario focuses on the amount
of data that can be transmitted during the service interval.
The third scenario includes both types of operations.
B. Test Scenario #1
Fig. 7.
for 100 ms and then the C2C is tuned to for 900 ms. If
a service announcement is received during the CCH period,
the SCH will be tuned to for 400 ms and the C2C for the
remaining 500 ms. This timing style is just an example and
the exibility of the timing application allows for different
timing schemes such as continuous switching every 50 ms.
The service application creates a TUN interface through
which external applications such as ssh and ping can communicate. Normal IP traffic through the TUN interface is
relayed through shared memory to the SCH priority queue
as described in the 1609.4 section. When a message is relayed, a computer configured as an RSU begins broadcasting
service announcements on the CCH and then switches to the
SCH. When an OBU configured computer receives a service
announcement, it begins switching to the SCH and relaying
messages through its own service application. In this fashion,
all normal 802.2 traffic is handled by the Linux kernel.
The OBU configured computer also generates and receives
safety messages to be sent on the C2C channel. These
messages are defined by the SAE J2735 specification[10].
Latitude and longitude values are generated to make the
OBU appear to be moving back and forth on a straight line.
These messages are generated at a rate of 10 Hz. These
messages are vital for vehicle position estimation in real
world applications and the main purpose of the GNU Radio
testbed is to study the effect on these messages when service
channel switching is allowed.
ACI Equivalent
Background
Best Effort
Video
Voice
Separate
(sec)
Ave:0.038
SD:0.015
Ave:0.029
SD:0.009
Ave:0.023
SD:0.005
Ave:0.023
SD:0.006
Runs
A. Testbed
Our current testbed setup includes three USRP version
1 units with 2.3-2.9 GHz range transceiver daughter cards
(RFX2400). The timing, service, and safety message handlers have been developed to make the USRPs behave like
roadside units (RSU) or on-board units (OBU). For example,
RSUs provide services, like intersection information or camera data. The OBUs applications generate safety messages
and subscribe to services provided by the RSU. For all the
scenarios and tests described below, the 3 USRPs are inside
our laboratory and approximately 3 meters apart.
29-3-2-6
--- 192.168.200.3 ping statistics --109 packets transmitted, 100 received,
+11 duplicates,8% packet loss,
time 107974ms rtt min/avg/max/mdev =
284.057/448.728/1436.807/216.784 ms
Fig. 10.
Fig. 8.
Safety message enqueued to Rx time interval with the same
priorities (four separate runs)
C. Test Scenario #2
In this scenario, two USRPs and their respective Linux
computers are also used. One is configured as an OBU and
the other as an RSU. The OBU is assigned an IP address
of 192.168.200.3 and the RSU is assigned an IP Adrress
of 192.168.200.2. The RSU issues service announcements
whenever a userland application on its Linux box attempts
to connect to an IP address in the 192.168.200.* range. All
packets are routed through the gr0 interface to our service
program and from there to the service channel priority queue.
Whenever a packet is received during the service interval it
is acknowledged if it was a unicast packet and then passed
to the service program through shared memory and written
to the gr0 interface so that the userland application program
can access the data. For the initial test we use ping as the
application program, then ssh, and finally scp. All service
packets use the same priority.
Figure 10 shows the final output of ping 192.168.200.3
from the RSU. The average round trip time is 448ms which
is reasonable considering that a packet sent near the end of
an SCH interval will not have a response for 600ms because
it remains in queue until the start of the next SCH interval
Before ping starts the RSU is not yet broadcasting the
1m34.350s
0m0.093s
0m0.018s
Scp command statistics for scenario 2 ( RSU to OBU )
29-3-2-7
[root@crl12 80211Tunnel]# time \
ssh biddless@192.168.200.3
biddless@192.168.200.3s password:
Last login: Thu Aug 6 10:54:31 \
2009 from 192.168.200.2
[biddless@tml-pdc ]$ ls -l *.dat
9922 Aug 6 10:56 ping2.dat
2059 Aug 6 10:56 ping3.dat
6990 Aug 6 10:56 ping.dat
16384 Aug 6 10:56 test2.dat
45056 Aug 6 10:57 test3.dat
24576 Aug 6 10:57 test.dat
[biddless@tml-pdc ]$ rm *.dat
[biddless@tml-pdc ]$ exit
Connection to 192.168.200.3 closed.
real
user
sys
0m59.949s
0m0.085s
0m0.021s
Fig. 12.
they will both tune to the SCH for 400 ms and then the C2C
for 500ms.
--- 192.168.200.3 ping statistics --105 packets transmitted, 96 received,
+20 duplicates,8% packet loss,
time 103985ms rtt min/avg/max/mdev =
222.974/333.369/1536.806/132.183 ms
Fig. 13.
Figure 13 shows that the service channel data was relatively similar to the scenario #2 tests (the average RTT is
actually lower), with a similar number of lost packets and
range of RTT. Table III contains the average and standard
deviations for the safety messages.
TABLE III
AVERAGE E NQUEUE TO R ECEIVE T IME I NTERVALS
Priority
0
1
2
3
Average (sec)
Ave: 0.043
Ave: 0.032
Ave: 0.025
Ave: 0.024
Standard Deviation
SD: 0.047
SD: 0.045
SD: 0.013
SD: 0.009