29-3-2-1

A GNU Radio Based Testbed Implementation with IEEE 1609 WAVE Functionality
Scott Biddlestone and Keith A. Redmill

Abstract Wireless Access in Vehicular Environments

(WAVE) is comprised of multiple IEEE standards, including
1609.1 through 4 and 802.11p. In this paper, a testbed implementation of the 1609.3 and 1609.4 standards will be discussed.
GNU Radio and the USRP version 1 will be used to implement
a 802.11p-like physical layer, the application management of
1609.3, and the channelization features of the 1609.4 draft
which are unique to the WAVE stack. This implementation is
meant to provide a testbed for testing communication between
multiple single transceiver WAVE devices. GNU Radio allows
us to easily modify different layers in the protocol stack as the
drafts continue to be standardized and its modularity allows us
to easily breakdown the complex WAVE stack into manageable
pieces. While it should be possible to implement a standardcompliant version of 1609.4 (and above) with GNU Radio, only
a low bitrate version of the physical layer can be implemented
due to communication limitations between the processing PC
and the USRP.

GNU Radio is designed to be modular with each piece

called a block. Each block can have an input and output signature that defines what type of data that block will consume
or produce. A complicated block can be comprised of other
simpler blocks. GNU Radio already has multiple mixers, filters, amplifiers, modulators, and demodulators implemented
as blocks. A primary block, called the top block, determines
the ow of data through the blocks and determines if that
ow has multiple paths and that all blocks are connected
(are reachable). Independent paths of block will run in their
own threads. For example, our implementation has a receive
and transmit path that are given their own threads. Special
end-point blocks can act as sinks (end of path) or sources
(start of path). The USRP device can act as both a source
(receiver) and a sink (transmitter).

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.

Block Diagram of the Universal Software Radio Peripheral

The USRP version 1 communicates with a GNU Radio

program through USB2 and is capable of transmitting and
receiving at multiple frequencies depending on the installed
daughter cards. The newer version of the USRP uses gigabit
Ethernet instead of USB. For the rest of the paper, any
reference to the USRP will be to the USRP version 1. The
core components of the USRP are shown in Figure 1. The
USRP handles multiple frequencies by using daughter cards
that specially designed for a specific frequency range. These
daughter cards can be tuned to different center frequencies
within their design range and provide the signal to be
sampled by the high-speed ADCs or send the signal produced
by the high-speed DACs. The USRPs FPGA provides the
decimation, interpolation and filtering of the sent or received
samples.

Copyright 2009 IEEE

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

A PPDU is created by building a preamble of fixed length

(for 802.11p, this is 32 us) which is used for synchronization
at the receiver. After the preamble is a PLCP header using
Binary Phase Shift Keying (BPSK) and a fixed coding of
R=1/2. This header provides the receiver with coding rate,
modulation type, and length of the rest of the message.
The receiver can use these values to begin demodulating the
message. The next field is the service field, it contains the
scrambler seed that was used to randomize the message.
This is important for descrambling the message and undoing
the circular convolution.

Relationship of WAVE standards

802.11p[4] is an extension of 802.11[3] and details the

implementation of physical layer of the WAVE device.
1609.1[5] describes one possible interface between the applications and the 1609.3 network management layer, this exact
interface is considered optional. 1609.2[6] discusses security
techniques for encrypting the WAVE packets and will not be
discussed here. 1609.3[7] describes how different protocol
types are managed in the WAVE stack. 1609.4[8] describes
channelization and prioritization of different message types
in the MAC layer. To begin our implementation of WAVE
on GNU Radio, we will start with 802.11p and 1609.4 - the
two lowest level parts of WAVE. We then move on to the
more advanced 1609.3.
II. 802.11 P P HYSICAL L AYER
802.11p is an extension of the 802.11 standard[3] and
most closely resembles 802.11a. 802.11p uses orthogonal
frequency-division multiplexing ( OFDM ) in the 5.85-5.925
GHz range on 7 different channels. The channels will be
discussed in further detail in the next section on 1609.4.
802.11p contains a similar physical layer convergence procedure ( PLCP ) to 802.11a/b/g. 802.11p does not require
RTS/CTS handshaking, but does require acknowledgments
to unicast packets and support for fragmentation. 802.11p
uses OFDM with 48 subcarriers and 4 pilot carriers with a
nominal bandwidth of 10 MHz. 802.11p can use multiple
modulation schemes with OFDM to support bitrates from 3
Mbps to 27 Mbps. The frequency spacing is 10 Mhz/64 =
0.15625 MHz.
The first job of the OFDM PLCP sublayer is to create
a frame that can be easily be demodulated at the receiver.
This frame is called the PLCP protocol data unit (PPDU), a
breakdown of it is shown in Figure 3.

A. 802.11p Physical Layer with GNU Radio and the USRP

To begin our work with GNU Radio, we started with
the 802.11b PLCP created by BBNs ADROIT project[9]
since this is the fastest and most complicated 802.11-like
Physical Layer for the USRP1. Using this PLCP and the
DSSS (802.11b modulation) that came with it, we were able
to approximate 802.11b with GNU Radio. To do this, we
started with the TUN/TAP interface provided by the Linux
kernel, which allowed us to appear with the same interface
as an Ethernet device. When a packet was routed through our
device we developed code to encapsulate this 802.2 packet
into an 802.11 packet (PLCP Service Data Unit - PSDU),
create a 802.11b PPDU (very similar to OFDM, except no
coding is used), modulate it and then send it to another GNU
Radio. The full path of the BBN transmitter is as follows:
encapsulate 802.2 packet with 802.11 header, encapsulate
the 802.11 packet in a PLCP header, scramble the bits of
this packet, encode to BPSK symbols, and transmit using
a raised cosine filter. The receiver code has a finite state
machine searching for the PPDU preamble, with a state for
processing each field in the PPDU after that. If any states
fail, it returns to searching for a new preamble.
We also developed a network allocation vector (NAV)
functionality to handle virtual carrier sensing in order to
further implement the 802.11 MAC layer. This thread reads
all received packets duration field and will not allow a new
packet to be sent until this duration has elapsed. RTS/CTS
handshaking is not a required part of the 802.11p standard,
so we will ignore it for now and add it if necessary.
Acknowledgment (ACK) and fragmentation are supported.
After a packet is sent the NAV thread will be notified and will
wait a specified amount of time. If the ACK is not received

Copyright 2009 IEEE

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.

sent and a high priority emergency message is created.

The arbitration interframe space number (AIFSN) number
indicates the minimum number of short interframe space
(SIFS) windows a packet of that priority will wait, this
number will be added to a random number between 1 and
the CW range when a packet reaches the head of the queue.
For example, a CCH packet with a Best Effort Priority could
get assigned a wait time of 6 through 13.

III. 1609.4 C HANNELIZATION OVERVIEW

Above the 802.11p physical layer in WAVE is the 1609.4
channelization [8] specification. This specification defines
the use of a control channel (CCH) and 6 service channels
(SCH). A WAVE device will be required to tune to the CCHs
frequency every UTM second and monitor the CCH for
messages for a set interval, after that interval has elapsed the
device is allowed to switch to a service channel if necessary.
These intervals are shown in Figure 4.

Fig. 5.

Prioritized access on control and service channels

The intervals also require the 1609.4 section to query the

physical layer (802.11p) regarding how much time will be
required to send a selected message on the current channel.
If the time required exceeds the current channel interval and
thus would interfere with the guard interval, the messages
will be buffered in the MAC layer and transmitted later upon
return to the correct channel. This effects the service channels
as well as the control channel.
Fig. 4.

Sync interval, guard interval, CCH interval, and SCH interval

The CCH only allows a new protocol called WAVE Short

Message Protocol, or WSMP. These messages are approximately 400 to 500 bytes and have a new EtherType (0x02)
to allow the WAVE network stack to handle them differently
then normal 802.2 frames. Service channels can use either
IPv6 protocols or WSMP. Both the CCH and SCHs use a
priority queuing scheme based on 802.11e EDCA.
Figure 5 shows the priority queues used on the channels.
Each queue represents the access category index or ACI.
Table I shows some of the parameters used for the CCH
(the SCHs use similar values). These values are used for
determining which message will be sent next. This is useful
if there are many queued regular priority messages to be

A. Channelization with GNU Radio

Due to GNU Radios modularity and the fact that channelization occurs in the MAC, channelization in GNU Radio
was developed independently of the physical layer. We
can test the channelization layer with the modified BBN
802.11b physical layer described earlier or any other modulation scheme provided by GNU Radio like GMSK.
To begin, a new interface for creating, passing to, and
receiving WAVE short messages was created for GNU Radio.
This will be described in the 1609.3 Network Management
section. The 1609.3 layer provides priority values and SCH
information to the channelization section for queuing. Received messages will be passed to and processed by the
1609.3 layer.

Copyright 2009 IEEE

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

repeats defines the number of the same WSA messages that

must be sent during the control channel interval. Persistence
and repeats are illustrated in Figure 6.

CW Range
15
7
3
3

This 1609.3 layer also assign messages ACIs and channel

numbers. Within GNU Radio, a series of message queues
were created for the CCH and the active SCH. All messages
that do not correspond to either of those channels will be
discarded, as well as non-WSMP messages assigned to the
CCH. A separate thread monitors these queues for available
messages. To be fair to lower priority messages, a low
priority message can beat a higher priority message if it
has been waiting long enough. This timeout value is different
for each ACI category, with low priority messages having the
longest timeout values.
After a message has been selected, the thread determines
if there is enough time to send the message on the current
channel time interval. If not, the message will stay in the
queue, otherwise the message is popped from the queue
and passed on the the 802.11p layer for encoding and
transmission.
After the current channels time interval has expired, the
USRP is instructed to re-tune to the CCH or another SCH.
If it is the start of the UTC second, then it will be the
CCH. Otherwise, the next higher layer in the stack (1609.3)
determines the next channel selection.
IV. 1609.3 N ETWORK M ANAGEMENT
The 1609.3 standard details how a WAVE system will
respond to service advertisements, what messages get what
priority, and if this WAVE device should offer services of
its own. This standard does not necessarily need to be
implemented using GNU Radio structures, but the 1609.4
processes need to be able to communicate with it.
1609.3 is a network management layer that decides which
SCH to tune into when a control interval is over. It does this
by interpreting and generating special WSMs called service
announcements. A WAVE service information announcement
(WSIE) is sent by a WAVE device that has a service available
for use by another WAVE device. The WSIE is made up of
the service type and the SCH number that it will be available
on and an optional WAVE routing advertisement.
All applications that wish to provide or want to subscribe
to a service must register themselves with the 1609.3 WAVE
management entity (WME). Each application will have an
assigned priority and the higher priority has precedence
when the 1609.3 layer is queried for the next SCH channel
selection. During registration the application also provides
information about service persistence and the number of
message repeats. If a service is persistent, that WSA created
for it will be sent whenever the control interval is entered on
the CCH at the beginning of a UTC second. The number of

Fig. 6.

Repeats and persistence in WSA

When an application wishes to subscribe to a service, it

also registers itself with the WME. After that, whenever a
WSIE is received it will have its service information tested
against the list of registered applications. If an application
matches and has a higher priority then the currently active
service, the SCH specified in the WSIE is set as the next
active service channel.
Two types of WAVE devices are supported, the roadside
unit (RSU) and the onboard unit (OBU). The RSU would
typically be a service provider deployed on the roadside that
would provide map data like the geometric intersection data
(GID) message. If it is connected to a traffic light it could
also provide signal phase and timing (SPaT) messages. Both
message types are defined in [10]. The OBU is responsible
for receiving data from RSUs and generating and receiving
safety messages that relay information about the vehicles
current state.
A. Implementation of 1609.3
Our implementation of 1609.3 is shown in Figure 7. Since
the applications are known before runtime, the registration
of applications is currently not implemented. As previously
mentioned, 1609.3 does not necessarily need to be implemented within GNU Radios structures. In a normal GNU
Radio tunnel implementation, Ethernet frames are passed
to GNU Radio through the Linux TUN/TAP interface, but
WSMs need to be handled differently.
A shared memory interface was designed to link the C++
applications for channel timing, service message passing, and
safety message passing. A special SCH was also created
for safety messages, which we will refer to as the car-tocar (C2C) channel. The C2C channel is always tuned to by
OBUs for relaying safety messages.
The timing application is responsible for enforcing the
synchronization with the CCH every second and switching
to the SCH or optional C2C channel during the 1 second
interval. To ensure that multiple USRPs synchronize at the
same time, each computers uses an ntp daemon with a
shared GPS time source. Currently, the CCH is tuned to

Copyright 2009 IEEE

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.

Applications used to implement 1609.3 Network Management

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.

In this scenario, we use two USRPs acting as OBUs

broadcasting safety messages. Since no RSU is providing
a service, the OBUs tune to the CCH at the beginning of
every second and stay there for 100ms. After that the radio
is tuned to the C2C channel for 900 ms. During both time
intervals, an external program is generating and enqueuing
safety messages at 10Hz. These messages are sent during
the C2C interval according to their priority level. Since all
messages are broadcasts, no IP address is assigned to the
USRPs.
The priorities related to the ACI are shown in Table I,
where priority 0 is the lowest or Background and priority
3 is the highest or Voice. Table II shows this relationship
in columns 1 and 2. Columns 3 and 4 refer to the average
and standard deviation of the enqueue to received time
intervals for each test. As expected the highest priority
has the lowest average and the lowest variation (its CW
range is smaller). During the random broadcasts, the highest
priority (3) messages retains the same average and variance
as in the separated cases. This comes at the expense of the
other priority messages average and variance time interval
measurements.
TABLE II
AVERAGE E NQUEUE TO R ECEIVE T IME I NTERVALS
Priority
0

ACI Equivalent
Background

Best Effort

Video

Voice

V. T ESTBED SETUP AND T EST S CENARIOS

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

Randomly Intermixed (sec)

Ave:0.039
SD:0.016
Ave:0.029
SD:0.009
Ave:0.025
SD:0.011
Ave:0.024
SD:0.009

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.

In Figure 8, all safety messages are sent with a the same

priority level for approximately 30 seconds. There is no
contention between priorities, so the enqueue to received
time interval is relatively similar for all messages of the same
type.
In Figure 9, the enqueued to receive time interval is shown
for safety messages generated at 10 Hz with a random
priority value between 0 and 3. Priority 3 has a similar
pattern to the separate test, but the other priorities show more
variance, particularly priority 2.

Copyright 2009 IEEE

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)

Fig. 9. Safety message enqueued to Rx time interval with random priorities

(single run)

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

Ping statistics for scenario 2 (RSU to OBU)

WSA, so the OBU will not be switching to the SCH. After

the first packet is received through the TUN interface, the
RSU begins broadcasting the WSA 3 times every CCH
interval; this is similar to Figure 6. After the OBU receives a
WSA during the CCH interval, it then switches to the SCH
for 400 ms and then to the C2C channel for 500 ms and
finally retunes to the CCH. If no WSA is received in the new
CCH interval, the OBU will not switch to the SCH again.
The RSU will stop sending WSAs when their has been no
activity on the gr0 TUN interface for 60 seconds.
Figure 11 shows the amount of time required to secure
copy some data files of various sizes using the service
channel. The actual data transmission occurs very quickly as
seen in the transmission rates, however the initial connection,
password and disconnection are very slow (hence the 1
minute process time). Since scp is not aware that its packets
can be delayed for up 600ms (the application timeouts are not
tuned to match the SCH) a large number of retransmissions
due to timeouts occur.
[root@crl12 80211Tunnel]# time \
scp *.dat biddless@192.168.200.3:
biddless@192.168.200.3s password:
ping2.dat 100% 9922
9.7KB/s 00:00
ping3.dat 100% 2059
2.0KB/s 00:00
ping.dat 100% 6990
6.8KB/s 00:00
test2.dat 100% 16KB 16.0KB/s 00:00
test3.dat 100% 44KB 44.0KB/s 00:00
test.dat 100% 24KB 24.0KB/s 00:00
real
user
sys
Fig. 11.

1m34.350s
0m0.093s
0m0.018s
Scp command statistics for scenario 2 ( RSU to OBU )

Figure 12 shows a listing of the copied data files using

the service channel and ssh.
D. Test Scenario #3
In this scenario, three USRPs and their respective Linux
computer boxes are used. Two are configured as an OBU and
the third as an RSU. The first OBU is assigned an IP address
of 192.168.200.3, the second OBU is assigned an IP address
of 192.168.200.4, and the RSU is assigned 192.168.200.2.
The RSU issues the same ping command as before to the
first OBU (192.168.200.3) while the second OBU creates
and sends random priority safety messages during the C2C
interval. Since both OBUs receive the WSAs from the RSU,

Copyright 2009 IEEE

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.

Ssh command statistics for scenario 2 ( RSU to OBU )

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.

Ping statistics for scenario 3

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

Here the packets show a similar average but a much larger

variance ( except Priority 3 which will always get sent as
soon as possible ) due to the higher volume of CCH ( WSA
) and SCH traffic.
VI. C ONCLUSION

in the 2.4 GHz band and a bitrate of around 500kbps.

Service and safety applications and the 1609.3 layer are also
implemented. The USRP and GNU Radio allow us to inspect
and test errors and performance at a much lower level than
an off-the-shelf DSRC radio system; all the way down to the
PLCP state machine.
Further experiments are planned for a different switching
scheme, such switching channels every 50 ms to avoid the
long wait times queued SCH and C2C packets experience
when enqueued outside their interval. Also, to complete
the full WAVE stack, 1609.3 Application Registration and
1609.2 security may also be implemented.
To further approach the real WAVE standard, we may
eventually purchase the new 5 GHz ISM band daughter
cards. These may not reach the 5.9 GHZ needed for 802.11p,
but can definitely reach 802.11a frequency range.
VII. ACKNOWLEDGMENTS
uner and Dr.

We would like to acknowledge Dr. Umit

Ozg
Eylem Ekici for initiating this project at the Ohio State University and the OSU Center for Automotive Researchs V2V
Consortium for support. We would also like to acknowledge
Allen Chang for his work on the priority queue structure.
R EFERENCES
[1] GNU
Radio
The
GNU
Software
Radio,
http://www.gnu.org/software/gnuradio/
[2] Ettus Research Universal Software Radio Peripheral (USRP),
http://www.ettus.com
[3] IEEE standard for information technology- telecommunications and information exchange between systems- local and
metropolitan area networks- specific requirements Part II: wireless LAN medium access control (MAC) and physical layer
(PHY) specifications, IEEE Std 802.11g-2003 (Amendment to
IEEE Std 802.11, 1999 Edn. (Reaff 2003) as amended by IEEE
Stds 802.11a-1999, 802.11b-1999, 802.11b-1999/Cor 1-2001,
and 802.11d-2001) , vol., no., pp.i-67, 2003
[4] IEEE P802.11p/D3.05, Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY), March 2008
[5] IEEE Std. 1609.1 - 2006 IEEE Trial-Use Standard for Wireless
Access in Vehicular Environments (WAVE) - Resource Manager, IEEE Std 1609.1-2006 , vol., no., pp. c1-63, 2006
[6] IEEE Trial-Use Standard for Wireless Access in Vehicular
Environments - Security Services for Applications and Management Messages, IEEE Std 1609.2-2006 , vol., no., pp. 1-105,
2006
[7] IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services, IEEE Std 1609.32007 , vol., no., pp.c1-87, April 20 2007
[8] IEEE Trial-Use Standard for Wireless Access in Vehicular
Environments (WAVE) - Multi-channel Operation, IEEE Std
1609.4-2006 , vol., no., pp.c1-74, 2006
[9] ADROIT
GNU
Radio
Development,
https://acert.ir.bbn.com/projects/adroitgrdevel/,
BBN
Technologies
[10] DRAFT SAE J2735 Dedicated Short Range Communications
(DSRC) Message Set Dictionary Rev 29, SAE International,
available at http://www.itsware.net/ITSschemas/DSRC/

Our initial testbed uses the BBN 802.11b based physical

layer with 802.11 NAV and ACK additions with 1609.4
channelization and the timing, service, and safety message
handlers described above. We currently use a frequency
Copyright 2009 IEEE