A GNU Radio Based Testbed Implementation with IEEE 1609 WAVE Functionality

Scott Biddlestone and Keith A. Redmill

AbstractWireless Access in Vehicular Environments(WAVE) is comprised of multiple IEEE standards, including1609.1 through 4 and 802.11p. In this paper, a testbed imple-mentation of the 1609.3 and 1609.4 standards will be discussed.GNU Radio and the USRP version 1 will be used to implementa 802.11p-like physical layer, the application management of1609.3, and the channelization features of the 1609.4 draftwhich are unique to the WAVE stack. This implementation ismeant to provide a testbed for testing communication betweenmultiple single transceiver WAVE devices. GNU Radio allowsus to easily modify different layers in the protocol stack as thedrafts continue to be standardized and its modularity allows usto easily breakdown the complex WAVE stack into manageablepieces. While it should be possible to implement a standard-compliant version of 1609.4 (and above) with GNU Radio, onlya low bitrate version of the physical layer can be implementeddue to communication limitations between the processing PCand the USRP.

I. INTRODUCTION

At Ohio State Universitys Control and Intelligent Trans-portation Research Lab (CITR), multiple Vehicle to Vehicle(V2V) and Vehicle to Infrastructure (V2I) messaging spec-ifications are developed, implemented and studied. Thesespecifications can use very different encodings, frequenciesand modulations. To build a testbed for testing and teachingthese different messaging specifications, we have recentlyturned to software defined radio (SDR). SDR allows us toreconfigure a communication device for different messagingschemes in software. The software package we chose toattempt to implement the recent Wireless Access in VehicularEnvironments (WAVE) specification with is GNU Radio[1]and the hardware platform is the Universal Software RadioPeripheral (USRP). In this paper, we will propose a plan forimplementing unique parts of the WAVE network stack withGNU Radio and the USRP, coming as close to the standardsas possible.

A. GNU Radio and the USRP

GNU Radio is a software defined radio package designedto implement common radio functions that run on a hostcomputer. GNU Radio itself is not capable of transmitting orreceiving radio signals without the help of external hardware.GNU Radio recommends the use of the Universal SoftwareRadio Peripheral (USRP) which was especially designedfor use with GNU Radio. The USRP is made by EttusResearch[2].

The authors are with the Department of Electrical and ComputerEngineering, The Ohio State University, Columbus, OH 43210 USA.redmill@ece.osu.edu

GNU Radio is designed to be modular with each piececalled a block. Each block can have an input and output sig-nature that defines what type of data that block will consumeor produce. A complicated block can be comprised of othersimpler blocks. GNU Radio already has multiple mixers, fil-ters, amplifiers, modulators, and demodulators implementedas blocks. A primary block, called the top block, determinesthe ow of data through the blocks and determines if thatow has multiple paths and that all blocks are connected(are reachable). Independent paths of block will run in theirown threads. For example, our implementation has a receiveand transmit path that are given their own threads. Specialend-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).

Fig. 1. Block Diagram of the Universal Software Radio Peripheral

The USRP version 1 communicates with a GNU Radioprogram through USB2 and is capable of transmitting andreceiving at multiple frequencies depending on the installeddaughter cards. The newer version of the USRP uses gigabitEthernet instead of USB. For the rest of the paper, anyreference to the USRP will be to the USRP version 1. Thecore components of the USRP are shown in Figure 1. TheUSRP handles multiple frequencies by using daughter cardsthat specially designed for a specific frequency range. Thesedaughter cards can be tuned to different center frequencieswithin their design range and provide the signal to besampled by the high-speed ADCs or send the signal producedby the high-speed DACs. The USRPs FPGA provides thedecimation, interpolation and filtering of the sent or receivedsamples.

29-3-2-1

Copyright 2009 IEEE

B. WAVE Specification

The WAVE specification is broken into five different stan-dards. These IEEE Standards are 802.11p, 1609.1, 1609.2,1609.3, and 1609.4. The relationship of these standards inWAVE is shown in Figure 2.

Fig. 2. Relationship of WAVE standards

802.11p[4] is an extension of 802.11[3] and details theimplementation of physical layer of the WAVE device.1609.1[5] describes one possible interface between the appli-cations and the 1609.3 network management layer, this exactinterface is considered optional. 1609.2[6] discusses securitytechniques for encrypting the WAVE packets and will not bediscussed here. 1609.3[7] describes how different protocoltypes are managed in the WAVE stack. 1609.4[8] describeschannelization and prioritization of different message typesin the MAC layer. To begin our implementation of WAVEon GNU Radio, we will start with 802.11p and 1609.4 - thetwo lowest level parts of WAVE. We then move on to themore advanced 1609.3.

II. 802.11P PHYSICAL LAYER802.11p is an extension of the 802.11 standard[3] and

most closely resembles 802.11a. 802.11p uses orthogonalfrequency-division multiplexing ( OFDM ) in the 5.85-5.925GHz range on 7 different channels. The channels will bediscussed in further detail in the next section on 1609.4.802.11p contains a similar physical layer convergence pro-cedure ( PLCP ) to 802.11a/b/g. 802.11p does not requireRTS/CTS handshaking, but does require acknowledgmentsto unicast packets and support for fragmentation. 802.11puses OFDM with 48 subcarriers and 4 pilot carriers with anominal bandwidth of 10 MHz. 802.11p can use multiplemodulation schemes with OFDM to support bitrates from 3Mbps to 27 Mbps. The frequency spacing is 10 Mhz/64 =0.15625 MHz.

The first job of the OFDM PLCP sublayer is to createa frame that can be easily be demodulated at the receiver.This frame is called the PLCP protocol data unit (PPDU), abreakdown of it is shown in Figure 3.

Fig. 3. PPDU breakdown

A PPDU is created by building a preamble of fixed length(for 802.11p, this is 32 us) which is used for synchronizationat the receiver. After the preamble is a PLCP header usingBinary Phase Shift Keying (BPSK) and a fixed coding ofR=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 themessage. The next field is the service field, it contains thescrambler seed that was used to randomize the message.This is important for descrambling the message and undoingthe circular convolution.

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

To begin our work with GNU Radio, we started withthe 802.11b PLCP created by BBNs ADROIT project[9]since this is the fastest and most complicated 802.11-likePhysical Layer for the USRP1. Using this PLCP and theDSSS (802.11b modulation) that came with it, we were ableto approximate 802.11b with GNU Radio. To do this, westarted with the TUN/TAP interface provided by the Linuxkernel, which allowed us to appear with the same interfaceas an Ethernet device. When a packet was routed through ourdevice we developed code to encapsulate this 802.2 packetinto an 802.11 packet (PLCP Service Data Unit - PSDU),create a 802.11b PPDU (very similar to OFDM, except nocoding is used), modulate it and then send it to another GNURadio. The full path of the BBN transmitter is as follows:encapsulate 802.2 packet with 802.11 header, encapsulatethe 802.11 packet in a PLCP header, scramble the bits ofthis packet, encode to BPSK symbols, and transmit usinga raised cosine filter. The receiver code has a finite statemachine searching for the PPDU preamble, with a state forprocessing each field in the PPDU after that. If any statesfail, it returns to searching for a new preamble.

We also developed a network allocation vector (NAV)functionality to handle virtual carrier sensing in order tofurther implement the 802.11 MAC layer. This thread readsall received packets duration field and will not allow a newpacket to be sent until this duration has elapsed. RTS/CTShandshaking 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 willwait a specified amount of time. If the ACK is not received

29-3-2-2

Copyright 2009 IEEE

before timeout then the packet will be retransmitted. When areceiver finishes demodulating a packet it immediately buildsan acknowledgment packet and sends it. These features arereusable for any 802.11 type network.

This implementation of 802.11b not compatible with areal 802.11b system primarily due to speed constraints. USBversion 2.0 limits our maximum bitrate and simultaneoussending and receiving reduces the rate even further. Thisconstraint also makes it extremely difficult to implementOFDM using BPSK. However, if an OFDM scheme is cre-ated the 802.11b PLCP can be used as a base for constructingand decoding 802.11p messages. The other major differencethis implementation will have with 802.11p is frequency.We currently use 2.3-2.9 GHz daughter cards while 802.11pcalls for a 5.9 GHz transceiver. Unfortunately, due to USBspeed limitations between the processing PC and the USRP1and a the lack of a daughtercard capable of transmitting andreceiving at 5.9 GHz, a full speed, standard-compliant WAVEdevice will impossible to implement with the USRP1 at thistime.

III. 1609.4 CHANNELIZATION OVERVIEWAbove the 802.11p physical layer in WAVE is the 1609.4

channelization [8] specification. This specification definesthe use of a control channel (CCH) and 6 service channels(SCH). A WAVE device will be required to tune to the CCHsfrequency every UTM second and monitor the CCH formessages for a set interval, after that interval has elapsed thedevice is allowed to switch to a service channel if necessary.These intervals are shown in Figure 4.

Fig. 4. Sync interval, guard interval, CCH interval, and SCH interval

The CCH only allows a new protocol called WAVE ShortMessage Protocol, or WSMP. These messages are approxi-mately 400 to 500 bytes and have a new EtherType (0x02)to allow the WAVE network stack to handle them differentlythen normal 802.2 frames. Service channels can use eitherIPv6 protocols or WSMP. Both the CCH and SCHs use apriority 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 fordetermining which message will be sent next. This is usefulif there are many queued regular priority messages to be

sent and a high priority emergency message is created.The arbitration interframe space number (AIFSN) numberindicates the minimum number of short interframe space(SIFS) windows a packet of that priority will wait, thisnumber will be added to a random number between 1 andthe CW range when a packet reaches the head of the queue.For example, a CCH packet with a Best Effort Priority couldget assigned a wait time of 6 through 13.

Fig. 5. Prioritized access on control and service channels

The intervals also require the 1609.4 section to query thephysical layer (802.11p) regarding how much time will berequired to send a selected message on the current channel.If the time required exceeds the current channel interval andthus would interfere with the guard interval, the messageswill be buffered in the MAC layer and transmitted later uponreturn to the correct channel. This effects the service channelsas well as the control channel.

A. Channelization with GNU RadioDue to GNU Radios modularity and the fact that chan-

nelization occurs in the MAC, channelization in GNU Radiowas developed independently of the physical layer. Wecan test the channelization layer with the modified BBN802.11b physical layer described earlier or any other modu-lation scheme provided by GNU Radio like GMSK.

To begin, a new interface for creating, passing to, andreceiving WAVE short messages was created for GNU Radio.This will be described in the 1609.3 Network Managementsection. The 1609.3 layer provides priority values and SCHinformation to the channelization section for queuing. Re-ceived messages will be passed to and processed by the1609.3 layer.

29-3-2-3

Copyright 2009 IEEE

TABLE IEDCA PARAMETERS FOR CCH

ACI AC AIFSN CW Range1 Background 9 150 Best Effort 6 72 Video 3 33 Voice 2 3

This 1609.3 layer also assign messages ACIs and channelnumbers. Within GNU Radio, a series of message queueswere created for the CCH and the active SCH. All messagesthat do not correspond to either of those channels will bediscarded, as well as non-WSMP messages assigned to theCCH. A separate thread monitors these queues for availablemessages. To be fair to lower priority messages, a lowpriority message can beat a higher priority message if ithas been waiting long enough. This timeout value is differentfor each ACI category, with low priority messages having thelongest timeout values.

After a message has been selected, the thread determinesif there is enough time to send the message on the currentchannel time interval. If not, the message will stay in thequeue, otherwise the message is popped from the queueand passed on the the 802.11p layer for encoding andtransmission.

After the current channels time interval has expired, theUSRP is instructed to re-tune to the CCH or another SCH.If it is the start of the UTC second, then it will be theCCH. Otherwise, the next higher layer in the stack (1609.3)determines the next channel selection.

IV. 1609.3 NETWORK MANAGEMENT

The 1609.3 standard details how a WAVE system willrespond to service advertisements, what messages get whatpriority, and if this WAVE device should offer services ofits own. This standard does not necessarily need to beimplemented using GNU Radio structures, but the 1609.4processes need to be able to communicate with it.

1609.3 is a network management layer that decides whichSCH to tune into when a control interval is over. It does thisby interpreting and generating special WSMs called serviceannouncements. A WAVE service information announcement(WSIE) is sent by a WAVE device that has a service availablefor use by another WAVE device. The WSIE is made up ofthe service type and the SCH number that it will be availableon and an optional WAVE routing advertisement.

All applications that wish to provide or want to subscribeto a service must register themselves with the 1609.3 WAVEmanagement entity (WME). Each application will have anassigned priority and the higher priority has precedencewhen the 1609.3 layer is queried for the next SCH channelselection. During registration the application also providesinformation about service persistence and the number ofmessage repeats. If a service is persistent, that WSA createdfor it will be sent whenever the control interval is entered onthe CCH at the beginning of a UTC second. The number of

repeats defines the number of the same WSA messages thatmust be sent during the control channel interval. Persistenceand repeats are illustrated in Figure 6.

Fig. 6. Repeats and persistence in WSA

When an application wishes to subscribe to a service, italso registers itself with the WME. After that, whenever aWSIE is received it will have its service information testedagainst the list of registered applications. If an applicationmatches and has a higher priority then the currently activeservice, the SCH specified in the WSIE is set as the nextactive service channel.

Two types of WAVE devices are supported, the roadsideunit (RSU) and the onboard unit (OBU). The RSU wouldtypically be a service provider deployed on the roadside thatwould provide map data like the geometric intersection data(GID) message. If it is connected to a traffic light it couldalso provide signal phase and timing (SPaT) messages. Bothmessage types are defined in [10]. The OBU is responsiblefor receiving data from RSUs and generating and receivingsafety messages that relay information about the vehiclescurrent state.

A. Implementation of 1609.3

Our implementation of 1609.3 is shown in Figure 7. Sincethe applications are known before runtime, the registrationof applications is currently not implemented. As previouslymentioned, 1609.3 does not necessarily need to be imple-mented within GNU Radios structures. In a normal GNURadio tunnel implementation, Ethernet frames are passedto GNU Radio through the Linux TUN/TAP interface, butWSMs need to be handled differently.

A shared memory interface was designed to link the C++applications for channel timing, service message passing, andsafety message passing. A special SCH was also createdfor safety messages, which we will refer to as the car-to-car (C2C) channel. The C2C channel is always tuned to byOBUs for relaying safety messages.

The timing application is responsible for enforcing thesynchronization with the CCH every second and switchingto the SCH or optional C2C channel during the 1 secondinterval. To ensure that multiple USRPs synchronize at thesame time, each computers uses an ntp daemon with ashared GPS time source. Currently, the CCH is tuned to

29-3-2-4

Copyright 2009 IEEE

Fig. 7. Applications used to implement 1609.3 Network Management

for 100 ms and then the C2C is tuned to for 900 ms. Ifa service announcement is received during the CCH period,the SCH will be tuned to for 400 ms and the C2C for theremaining 500 ms. This timing style is just an example andthe exibility of the timing application allows for differenttiming schemes such as continuous switching every 50 ms.

The service application creates a TUN interface throughwhich external applications such as ssh and ping can com-municate. Normal IP traffic through the TUN interface isrelayed through shared memory to the SCH priority queueas described in the 1609.4 section. When a message is re-layed, a computer configured as an RSU begins broadcastingservice announcements on the CCH and then switches to theSCH. When an OBU configured computer receives a serviceannouncement, it begins switching to the SCH and relayingmessages 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 receivessafety messages to be sent on the C2C channel. Thesemessages are defined by the SAE J2735 specification[10].Latitude and longitude values are generated to make theOBU appear to be moving back and forth on a straight line.These messages are generated at a rate of 10 Hz. Thesemessages are vital for vehicle position estimation in realworld applications and the main purpose of the GNU Radiotestbed is to study the effect on these messages when servicechannel switching is allowed.

V. TESTBED SETUP AND TEST SCENARIOS

A. Testbed

Our current testbed setup includes three USRP version1 units with 2.3-2.9 GHz range transceiver daughter cards(RFX2400). The timing, service, and safety message han-dlers have been developed to make the USRPs behave likeroadside units (RSU) or on-board units (OBU). For example,RSUs provide services, like intersection information or cam-era data. The OBUs applications generate safety messagesand subscribe to services provided by the RSU. For all thescenarios and tests described below, the 3 USRPs are insideour laboratory and approximately 3 meters apart.

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 ana-lyzer, that is part of the GNURadio package, to determinerelatively unused frequencies around our lab.

Three test scenarios are described below. The first is toshow the proper operation of the priority queues using onlysafety messages. The second scenario focuses on the amountof data that can be transmitted during the service interval.The third scenario includes both types of operations.

B. Test Scenario #1

In this scenario, we use two USRPs acting as OBUsbroadcasting safety messages. Since no RSU is providinga service, the OBUs tune to the CCH at the beginning ofevery second and stay there for 100ms. After that the radiois tuned to the C2C channel for 900 ms. During both timeintervals, an external program is generating and enqueuingsafety messages at 10Hz. These messages are sent duringthe C2C interval according to their priority level. Since allmessages are broadcasts, no IP address is assigned to theUSRPs.

The priorities related to the ACI are shown in Table I,where priority 0 is the lowest or Background and priority3 is the highest or Voice. Table II shows this relationshipin columns 1 and 2. Columns 3 and 4 refer to the averageand standard deviation of the enqueue to received timeintervals for each test. As expected the highest priorityhas the lowest average and the lowest variation (its CWrange is smaller). During the random broadcasts, the highestpriority (3) messages retains the same average and varianceas in the separated cases. This comes at the expense of theother priority messages average and variance time intervalmeasurements.

TABLE IIAVERAGE ENQUEUE TO RECEIVE TIME INTERVALS

Priority ACI Equiva-lent

Separate Runs(sec)

Randomly Inter-mixed (sec)

0 Background Ave:0.038SD:0.015

Ave:0.039SD:0.016

1 Best Effort Ave:0.029SD:0.009

Ave:0.029SD:0.009

2 Video Ave:0.023SD:0.005

Ave:0.025SD:0.011

3 Voice Ave:0.023SD:0.006

Ave:0.024SD:0.009

In Figure 8, all safety messages are sent with a the samepriority level for approximately 30 seconds. There is nocontention between priorities, so the enqueue to receivedtime interval is relatively similar for all messages of the sametype.

In Figure 9, the enqueued to receive time interval is shownfor safety messages generated at 10 Hz with a randompriority value between 0 and 3. Priority 3 has a similarpattern to the separate test, but the other priorities show morevariance, particularly priority 2.

29-3-2-5

Copyright 2009 IEEE

Fig. 8. Safety message enqueued to Rx time interval with the samepriorities (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 Linuxcomputers are also used. One is configured as an OBU andthe other as an RSU. The OBU is assigned an IP addressof 192.168.200.3 and the RSU is assigned an IP Adrressof 192.168.200.2. The RSU issues service announcementswhenever a userland application on its Linux box attemptsto connect to an IP address in the 192.168.200.* range. Allpackets are routed through the gr0 interface to our serviceprogram and from there to the service channel priority queue.Whenever a packet is received during the service interval itis acknowledged if it was a unicast packet and then passedto the service program through shared memory and writtento the gr0 interface so that the userland application programcan access the data. For the initial test we use ping as theapplication program, then ssh, and finally scp. All servicepackets use the same priority.

Figure 10 shows the final output of ping 192.168.200.3from the RSU. The average round trip time is 448ms whichis reasonable considering that a packet sent near the end ofan SCH interval will not have a response for 600ms becauseit remains in queue until the start of the next SCH interval

Before ping starts the RSU is not yet broadcasting the

--- 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. Ping statistics for scenario 2 (RSU to OBU)

WSA, so the OBU will not be switching to the SCH. Afterthe first packet is received through the TUN interface, theRSU begins broadcasting the WSA 3 times every CCHinterval; this is similar to Figure 6. After the OBU receives aWSA during the CCH interval, it then switches to the SCHfor 400 ms and then to the C2C channel for 500 ms andfinally retunes to the CCH. If no WSA is received in the newCCH interval, the OBU will not switch to the SCH again.The RSU will stop sending WSAs when their has been noactivity on the gr0 TUN interface for 60 seconds.

Figure 11 shows the amount of time required to securecopy some data files of various sizes using the servicechannel. The actual data transmission occurs very quickly asseen in the transmission rates, however the initial connection,password and disconnection are very slow (hence the 1minute process time). Since scp is not aware that its packetscan be delayed for up 600ms (the application timeouts are nottuned to match the SCH) a large number of retransmissionsdue 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:00ping3.dat 100% 2059 2.0KB/s 00:00ping.dat 100% 6990 6.8KB/s 00:00test2.dat 100% 16KB 16.0KB/s 00:00test3.dat 100% 44KB 44.0KB/s 00:00test.dat 100% 24KB 24.0KB/s 00:00

real 1m34.350suser 0m0.093ssys 0m0.018s

Fig. 11. Scp command statistics for scenario 2 ( RSU to OBU )

Figure 12 shows a listing of the copied data files usingthe service channel and ssh.

D. Test Scenario #3

In this scenario, three USRPs and their respective Linuxcomputer boxes are used. Two are configured as an OBU andthe third as an RSU. The first OBU is assigned an IP addressof 192.168.200.3, the second OBU is assigned an IP addressof 192.168.200.4, and the RSU is assigned 192.168.200.2.The RSU issues the same ping command as before to thefirst OBU (192.168.200.3) while the second OBU createsand sends random priority safety messages during the C2Cinterval. Since both OBUs receive the WSAs from the RSU,

29-3-2-6

Copyright 2009 IEEE

[root@crl12 80211Tunnel]# time \ssh biddless@192.168.200.3biddless@192.168.200.3s password:Last login: Thu Aug 6 10:54:31 \2009 from 192.168.200.2[biddless@tml-pdc ]$ ls -l *.dat9922 Aug 6 10:56 ping2.dat2059 Aug 6 10:56 ping3.dat6990 Aug 6 10:56 ping.dat16384 Aug 6 10:56 test2.dat45056 Aug 6 10:57 test3.dat24576 Aug 6 10:57 test.dat[biddless@tml-pdc ]$ rm *.dat[biddless@tml-pdc ]$ exitConnection to 192.168.200.3 closed.

real 0m59.949suser 0m0.085ssys 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 C2Cfor 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 rela-tively similar to the scenario #2 tests (the average RTT isactually lower), with a similar number of lost packets andrange of RTT. Table III contains the average and standarddeviations for the safety messages.

TABLE IIIAVERAGE ENQUEUE TO RECEIVE TIME INTERVALS

Priority Average (sec) Standard Deviation0 Ave: 0.043 SD: 0.0471 Ave: 0.032 SD: 0.0452 Ave: 0.025 SD: 0.0133 Ave: 0.024 SD: 0.009

Here the packets show a similar average but a much largervariance ( except Priority 3 which will always get sent assoon as possible ) due to the higher volume of CCH ( WSA) and SCH traffic.

VI. CONCLUSION

Our initial testbed uses the BBN 802.11b based physicallayer with 802.11 NAV and ACK additions with 1609.4channelization and the timing, service, and safety messagehandlers described above. We currently use a frequency

in the 2.4 GHz band and a bitrate of around 500kbps.Service and safety applications and the 1609.3 layer are alsoimplemented. The USRP and GNU Radio allow us to inspectand test errors and performance at a much lower level thanan off-the-shelf DSRC radio system; all the way down to thePLCP state machine.

Further experiments are planned for a different switchingscheme, such switching channels every 50 ms to avoid thelong wait times queued SCH and C2C packets experiencewhen enqueued outside their interval. Also, to completethe full WAVE stack, 1609.3 Application Registration and1609.2 security may also be implemented.

To further approach the real WAVE standard, we mayeventually purchase the new 5 GHz ISM band daughtercards. These may not reach the 5.9 GHZ needed for 802.11p,but can definitely reach 802.11a frequency range.

VII. ACKNOWLEDGMENTS

We would like to acknowledge Dr. Umit Ozguner and Dr.Eylem Ekici for initiating this project at the Ohio State Uni-versity and the OSU Center for Automotive Researchs V2VConsortium for support. We would also like to acknowledgeAllen Chang for his work on the priority queue structure.

REFERENCES

[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- telecommunica-tions and information exchange between systems- local andmetropolitan area networks- specific requirements Part II: wire-less LAN medium access control (MAC) and physical layer(PHY) specifications, IEEE Std 802.11g-2003 (Amendment toIEEE Std 802.11, 1999 Edn. (Reaff 2003) as amended by IEEEStds 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 WirelessAccess in Vehicular Environments (WAVE) - Resource Man-ager, IEEE Std 1609.1-2006 , vol., no., pp. c1-63, 2006

[6] IEEE Trial-Use Standard for Wireless Access in VehicularEnvironments - Security Services for Applications and Manage-ment Messages, IEEE Std 1609.2-2006 , vol., no., pp. 1-105,2006

[7] IEEE Trial-Use Standard for Wireless Access in Vehicular En-vironments (WAVE) - Networking Services, IEEE Std 1609.3-2007 , vol., no., pp.c1-87, April 20 2007

[8] IEEE Trial-Use Standard for Wireless Access in VehicularEnvironments (WAVE) - Multi-channel Operation, IEEE Std1609.4-2006 , vol., no., pp.c1-74, 2006

[9] ADROIT GNU Radio Development,https://acert.ir.bbn.com/projects/adroitgrdevel/, BBNTechnologies

[10] DRAFT SAE J2735 Dedicated Short Range Communications(DSRC) Message Set Dictionary Rev 29, SAE International,available at http://www.itsware.net/ITSschemas/DSRC/

29-3-2-7

Copyright 2009 IEEE