Protocol Design and Implementation of Vehicular Ad-hoc Networks

Protocol Design and Implementation of Vehicular 

Ad-hoc Networks 

Ali Haroon Babri, Sayed Aziz, Khalid Liaqat and Muhammad Talha 

Electrical Engineering Dept, University of Engineering and Technology, Lahore 

Abstract- Vehicular ad-hoc networks (VANETs) 

incorporate vehicle-to-vehicle and vehicle-toinfrastructure 

communication to provide a host of 

applications which aim to provide, among other 

things, a reduction in traffic congestion, accident 

detection and entertainment. In this paper, we 

describe a small scale experimental model in 

which we have implemented two major 

applications of VANETs i.e. Congestion detection 

and Emergency Notification. We first design the 

entire protocol for communication and then build 

the hardware modules - Roadside and vehicular 

modules, with the former planted at stationary 

locations and the later mounted on moving 

vehicles. 

Keywords – Vehicle to vehicle 

communication, Vehicle to infrastructure, 

congestion detection, emergency warning. 

I. INTRODUCTION 

Vehicular ad-hoc Networks (VANETs), a 

subset of wireless mesh networks, is a developing 

technology which aims to create a mobile network 

using cars as nodes [1]. A VANET behaves as an 

ordinary wireless network would with the 

additional challenge of the mobility of nodes [2]. 

The network must be continuously reconfigured 

as vehicles move around, with some leaving and 

others joining the network from time to time. A 

major issue with VANETs is that the technology 

must be standardised so as to enable vehicles to 

communicate with each other and with 

infrastructure according to a defined protocol. 

This initial difficulty is bound to pay dividends in 

the end with a vast multitude of potential 

© ICCIT 2012 718 

applications providing various services for the 

comfort and convenience of the driver and 

passengers. 

Vehicular Networks, being a relatively new 

field with a very large potential for development 

and numerous possible applications, have 

attracted the attention of many researchers 

worldwide. Abdalla et al. [3] discuss current 

trends in VANETs, and an effective congestion 

control scheme was proposed in [4]. In [3] and [5] 

routing protocols for VANETs are discussed. The 

Car 2 Car Communication consortium, founded 

by leading European auto manufacturers aspires 

to establish a European standard that all 

manufacturers will conform to [6]. 

II. SYSTEM OVERVIEW 

In this section we present an overview of the 

system architecture. Our system uses FM for 

vehicles to communicate with each other and the 

infrastructure. The infrastructure consists of 

roadside stations placed strategically, with each 

roadside station covering an area corresponding to 

its radio range, and with a large number of 

stations forming a cellular structure with their 

ranges overlapping slightly at the edges. Two 

such radio stations are shown in Figure 1. Every 

roadside station continuously broadcasts 

information about the region as well as its identity 

and prompts vehicles in range to establish contact 

with it. The Roadside Station then enters each 

vehicle that responds in its list of vehicles 

currently registered with it. In this way, the 

roadside station maintains record of all vehicles in 

its range. 

Consider a typical scenario shown in Figure 1. 

Vehicle 1 enters the range of roadside station 1, 

responds to the signal it receives from it, and gets 

registered with the station. The vehicle also

eceives information about the region it has just 

entered into such as the number of vehicles in the 

vicinity and whether there are any accidents 

nearby. If the vehicle finds the vehicle count in 

the region to be unacceptable, indicating 

congestion, it may decide whether to continue 

down the same path or to take an alternate route, 

shown by the curved arrow. 

Range of station 2 

Vehicle 2 

Vehicle 1 

Range of station 1 

Figure 1 – System Overview 

Roadside 

station 2 

Roadside 

station 1 

Congested area 

III. COMMUNICATION PROTOCOL 

A. Communication Overview 

The protocol for communication is a modified 

version of the Dual Channel Vehicular 

Communication protocol described in [7]. We use 

two channels of the 434MHz unlicensed band for 

communication, with ch1 (channel 1) at 433MHz 

and ch2 (channel 2) at 439.75MHz. These are the 

end points of the bandwidth available, and this 

widest possible separation eliminates interference 

between the two channels. Having two channels 

significantly reduces data collision – in our model 

ch1 is mainly used for broadcasting while 

communication and transfer of data between 

vehicles and roadside stations is done in ch2. 

Each RM (Roadside Module) and VM 

(Vehicular Module) is assigned a unique 

identification number - sID (station ID) and vID 

(vehicle ID) respectively. Each RM transmits its 

sID periodically. A vehicle responds to this by 

sending its vID to the station if it is not already 

registered with it, meaning that it has just come 

719 

into range. The RM then enters the vehicle in its 

list of vehicles currently registered with it and 

sends an acknowledgement to the vehicle to 

inform it that it has registered. 

B. Framing of Data 

As opposed to the framing scheme proposed 

in [7], in our communication model, we use a 

somewhat different approach, and break down the 

data traffic into five basic data sets and we 

transmit each set of data in a unique frame. Each 

frame consists of 8 bits and is structured as 

follows (Figure 2): 

Valid E Type/TTL 

(1 bit) (1 bit) (2 bits) 

Figure 2 - Frame Format 

V data 

(2 bits) 

S data 

(2 bits) 

The first bit (MSB) is the valid bit. This bit is 

set upon transmission of a frame, and the receiver 

is notified of the arrival of new data when this bit 

changes from zero to one. The second field, E, is 

‘1’ if the frame is an E frame and ‘0’ otherwise. 

The next two bits of the frame identify one of the 

remaining four different types of frames, namely, 

SB, DR, VR and ACK and determine how the V 

data and S data fields are to be interpreted. If E = 

1, this field contains the TTL value of the E 

frame. A brief explanation of each of the five 

frames follows. 

The Station Broadcast (SB) frame [type=00] 

is transmitted by the RM every 0.1s. The V data 

field contains the number of vehicles registered to 

that Roadside Module and the S data field 

contains the station ID of that Roadside Module. 

The purpose of this frame is to broadcast the 

station ID of the RM regularly and prompt 

vehicles in range to establish contact with the RM 

upon reception of this frame. 

The Data Refresh (DR) frame [01] is 

transmitted by the Roadside Module every time it 

powers up and also after every 5 seconds. The V 

data and S data fields are the same as that of the 

SB frame, but the two frames differ in the way the 

vehicle responds upon receiving them. 

The Vehicle Response (VR) frame [10] is 

transmitted by Vehicle Modules to respond to a 

request made by a Roadside Module. The V data 

field contains the vehicle ID of the vehicle and the 

S data field contains the station ID of the RM it is 

currently registered with.

The Acknowledgement (ACK) frame [11] is 

transmitted by the Roadside Module to 

acknowledge reception of data from vehicles. The 

V data field contains the vehicle ID of the vehicle 

the frame is intended for and the S data field 

contains the station ID of the transmitting RM. 

The Emergency (E) frame [E=1] is generated 

by a vehicle when it encounters an emergency 

situation and is also retransmitted by other 

vehicles. The V data field contains the vehicle ID 

of the affected vehicle and the S data field 

contains the station ID of the RM the vehicle is 

registered to. The TTL field determines how 

many more times the E frame is to be forwarded. 

C. The Protocol 

The Roadside Module is split into two parts or 

units – the Broadcasting Unit (BU) and the 

Responding Unit (RU). The Broadcasting Unit of 

each RM broadcasts the SB frame continuously in 

ch1 (once every 0.1 seconds). When a vehicle 

enters the range of a Roadside Station for the first 

time, it listens at ch1 for the SB frame, and upon 

receiving it; it saves the sID of the station as the 

station it is currently registered to. The vehicle 

then transmits the VR frame in ch2. The RU of the 

station, always listening at this channel, receives 

the frame and enters the vID of the vehicle in its 

list of vehicles registered with the station. The RU 

then sends the ACK frame in the same channel 

(ch2) which informs the vehicle that it has 

successfully been registered, and this completes 

the registration process. If there is heavy traffic in 

the region, the RU being able to only process one 

request at a time, may not be able to respond to 

several VR frames arriving at the same instance. 

In this case, it will register only one vehicle and 

send it an ACK. The rest of the vehicles will wait 

for a certain time for the ACK frame, and upon not 

receiving it will attempt to get registered again on 

subsequent SB frames. Vehicles that are already 

registered with a station ignore all SB frames it 

may transmit. 

The RU also broadcasts the DR frame once 

every 5 seconds as well as when it is powered up. 

The purpose of the DR frame is to refresh the 

vehicle list maintained by the roadside station and 

remove entries of vehicles that have moved out of 

range. Thus, the roadside station clears its list of 

currently registered vehicles when it transmits a 

DR frame and awaits response from vehicles that 

are still in range. When a vehicle receives a DR 

720 

frame, in contrast to the SB frame, it only 

responds if it is already registered to the station. 

The response is to transmit a VR frame in ch2 and 

wait for an ACK frame from the RU. If and ACK 

is not received, the vehicle will continue to 

retransmit the VR frame until it receives an 

acknowledgement. 

D. Emergency Notification 

If a vehicle encounters an emergency situation 

(i.e. has an accident), the vehicle transmits the E 

frame in both channels (ch1 and ch2). The frame 

contains the vID of the affected vehicle and the 

sID of the station it is registered with. The TTL 

field is given the binary value of ‘11’. Nearby 

vehicles, listening at ch2 when idle, receive the 

frame and rebroadcast it in the same channel 

(ch2). Due to a large number of vehicles that may 

be present in any given region, and given that 

every vehicle retransmits any E frame it may 

receive, a vehicle will receive multiple duplicate E 

frames. A simple check for this is for the vehicle 

module to maintain an emergency list containing a 

record of recently received E frames, with each 

entry expiring after 30s. Thus, whenever a vehicle 

receives an E frame, it first checks the vID of the 

frame against entries in the emergency list. If 

record of that E frame already exists, that frame is 

ignored. Otherwise, if the frame is determined to 

be original, the vID of the frame is entered in the 

emergency list and the frame retransmitted in ch2 

after first decrementing the TTL field. If the TTL 

value of a received E frame is zero then that frame 

is not retransmitted. 

The RU of the Roadside Module, always 

listening at ch2 also receives the Emergency 

frame. It sends an ACK frame back in the same 

channel (ch2) in response. The Roadside Module 

then, after having being informed of an 

emergency in its vicinity may then alert the 

respective emergency service via GSM though 

this is not implemented in the model. 

IV. HARDWARE DESIGN 

The basic building block of our system, which 

we shall call a “Unit”, is constructed using the 

following main components: An AVR ATmega8 

microcontroller and an RFM12B FSK transceiver. 

A jumper wire of 17.6cm serves as an antenna for 

the radio transceiver. The microcontroller is 

interfaced to the radio transceiver using SPI

(Serial Peripheral Interface). There are a total of 

five connections between the two, as can be seen 

in Figure 3. The MOSI (Master Out, Slave In) and 

MISO (Master In, Slave Out) pins of the 

microcontroller are connected to the SDI (Serial 

Data Input) and SDO (Serial Data Output) pins of 

the RFM12 module respectively. These constitute 

the data lines providing two-way communication 

between the microcontroller and the FM 

transceiver. The nIRQ (Interrupt request output) 

pin of the RFM12 goes low when the FM module 

is ready signalling to the microcontroller that it is 

ready to receive further instructions or data. This 

pin is connected to the INT0 (interrupt-0) pin of 

the microcontroller. The SCK (data clock, used to 

time the transfer) pin is connected to a general 

purpose pin of the microcontroller. We have used 

the bit-banging approach to transfer data from 

microcontroller to the FM module, and each bit is 

clocked into the module one at a time. The nSEL 

pin is chip select, and when it is made low the 

module is enabled. 

SDO SDI nIRQ SCK nSEL 

Data INT-0 Control 

VM Microcontroller 

7 segment display 

(VM-disp1) 

Radio transceiver 


(VM-disp2) 

Antenna 

Emergency 

signal 

Figure 3 – Block diagram of the Vehicular Module 

The entire system consists of two types of 

modules - the Vehicular Module and the Roadside 

Module. The block diagrams of both are shown in 

Figures 3 and 4 respectively. The vehicular 

module consists of a single Unit to which two 

seven segment displays have been attached 

(labelled VM-disp1 and VM-disp2). The 

Emergency signal provided to the microcontroller 

in the event of an emergency may be generated in 

any number of ways. In our model, we have used 

a simple switch to simulate an emergency event. 

The roadside module (also called the roadside 

station or station) is constructed using two units 

as shown in Figure 4. 

721 




BU 

Microcontroller 


(RM-disp1) 

The microcontrollers in each unit are 

connected through the UART (Universal 

Asynchronous Receiver Transmitter) interface. 

The two Units in the RM are called the 

Broadcasting Unit (BU) and the Responding Unit 

(RU). The RM also includes two seven segment 

displays, connected as shown in Figure 4 and 

labelled RM-disp1 and RM-disp2. 

V. DESIGN DETAILS 

A. The RFM12 module 

The RFM12, a picture of which is shown in 

Figure 5, is a low cost FSK transceiver IC with 

multiple integrated RF features. It supports a 

command interface which allows us to vary a 

number of parameters such as carrier frequency 

and data rate without any changes to hardware. A 

list of commands is given in the RF12 

programming guide [8]. 

Figure 5 – RFM12 

Antenna Antenna 

Rx 

Data 

Interrupt 

lines 




RU 

Microcontroller 

Commands are input to the transceiver by the 

microcontroller through the SDI line. Each 

command is 2bytes long and is sent one bit at a 

time over one clock period using the bit-banging 

approach. With each bit that is sent to the FM 

module, a bit is also received at the same time. 

Thus, when a 2 byte command is sent to the 

Tx 


(RM-disp2) 

Figure 4 – Block diagram of the Roadside Module

module, a 2 byte value is also received though it 

may not be used in some cases. 

When the system is first powered up, a 

function is called which initializes the RMF12 

module by giving it a number of commands to 

bring it to the desired settings and enabling all 

required features. To transmit a byte of data, the 

FM module is given the command “B8XXH” 

where XX is the byte to be transmitted. Before 

transmitting our data payload, we must first 

transmit the preamble “AAAAAAH” followed by 

the synchronization bit sequence “2DD4H” [8]. 

When the module receives a byte of data, it stores 

it in its receiver FIFO register. To read this 

register, the module is given the command 

B000H. The data will be in the lower byte of the 

two byte data received. The received data must be 

read immediately after receiving; otherwise the 

register will be overwritten if more data is 

received. 

B. Protocol Details 

The RFM12 module is only capable of 

performing one function at a time; that is, it is 

unable to transmit and receive at the same time. 

Thus, it is only put into transmitting mode when 

some data is to be sent, and then shifted back to 

receiving or listening mode. Another point of 

importance is the switching of the module 

between channels. With channel 1 at 433MHz and 

channel 2 at 439.75MHz, The FM transceiver is 

tuned to listen at the channel where the next frame 

is expected to arrive. 

The Broadcasting Unit of the Roadside 

Module is programmed to transmit a DR frame 

followed by 49 SB frames with delays of 100ms 

between them and the cycle is repeated 

continuously. This results in a DR frame being 

transmitted once every 5 seconds, and at this 

moment, the BU triggers an interrupt on the 

Responding Unit. The RU then opens up the 

UART connection between it and the 

Broadcasting Unit and the BU obtains the vehicle 

count in the region from the RU over the 

connection. The BU then uses this updated value 

in the DR and SB frames it is broadcasting. The 

BU does not expect to receive anything so it 

remains in the transmitting mode. Also, all the 

frames it transmits are in ch1. 

It is the job of the Responding Unit of the 

Roadside Module to wait for vehicles to contact it, 

and when they do, to acknowledge their 

transmission. The RU keeps a one byte global 

722 

variable rx_frame which is initially initialized to 

zero. When the FM transceiver receives data, the 

nIRQ pin of the module goes low and this triggers 

an interrupt on the microcontroller. The Interrupt 

service routine calls a function which stores the 

received frame in the rx_frame variable. The RU 

only expects to receive frames in channel2. 

Therefore, it initially tunes to ch2 in the receiving 

mode and waits, continuously polling the valid bit 

of rx_frame. The valid bit going high indicates a 

frame being received, and the RU saves the 

required data from the frame before clearing it to 

make it ready for the next received frame. If the 

received frame is a VR frame, the RU will enter 

the transmission mode briefly to transmit the ACK 

frame (in ch2) and enter the vID of the vehicle in 

the array v_list. This array contains entries of 

vehicles registered to the station. The RU will also 

trigger an interrupt on the BU signalling it to 

listen to the UART connection opened by the RU, 

over which the RU will send the updated vehicle 

count to the BU. It may be possible that the 

vehicle may not receive an ACK for some reason, 

in which case it will transmit the VR frame. The 

RU must detect and ignore duplicate VR frames. 

The RU treats E frames in a similar manner. It 

maintains an emergency list where it keeps 

records of vehicles facing an emergency. Each 

entry is valid only for 30s after which it is 

removed. 

The Vehicular Module is undoubtedly the 

most complex of the three. It must listen at both 

the channels for specific frames as well as 

properly handle and forward Emergency frames. 

The VM initially listens at ch1 for the SB, DR or 

E frame and remains in this state for the majority 

of the time. To transmit the VR frame, the VM 

switches to ch2. It then starts a timer and waits for 

the ACK frame. If it is received before the timer 

overflows, the VM saves the sID of the station. As 

soon as an ACK is received, or the timer 

overflows, the VM will switch back to ch1 and 

continue listening. If the vehicle receives an E 

frame, and the frame is found not to be a 

duplicate, the VM will enter the vID of the 

received frame in its emergency list. It will then 

check the TTL value of the frame, and if it is zero, 

it will take no further action. If the TTL value is 

non-zero, the VM will decrement it and transmit 

the modified E frame in ch1 where it will be 

received by other nearby vehicles and 

retransmitted. If a vehicle has an accident it will

transmit an E frame in ch1 where is will be 

received and forwarded by nearby vehicles. It will 

also transmit an E frame in ch2 intended for the 

responding unit of the station. After transmitting, 

the VM will start a timer for 25ms and wait for an 

ACK from the RU. If it is not received within this 

time, it will continue to transmit the E frame until 

it receives an ack. 

VI. EXPERIMENTAL VERIFICATION 

The architectural and hardware design we 

have proposed in this paper was implemented 

using three vehicles and two roadside stations. 

The vehicular modules were strapped onto 

remote-controlled cars and the roadside stations 

simply placed on the ground. One major difficulty 

was the initial configuration of the RFM12 

module because of much of the available data 

being incorrect and the official programming 

guide [8] containing many errors. However, this 

was resolved after extensive troubleshooting. We 

first strove to establish wireless contact between 

the modules and this was done by generating and 

transmitting a random number sequence using any 

one module, and receiving and displaying the 

numbers at the other module. With this working 

as desired, we were satisfied that the FM module 

was configured correctly, meaning we could now 

proceed with testing the protocol. 

The following tests determine the working of 

the protocol: (a) A vehicle comes into range of an 

RM. VM-disp1 on the vehicle will immediately 

show the sID of the station and VM-disp2 will 

show the vehicle count (indicating the amount of 

congestion). This is the normal state of the 

displays of a vehicle. (b) A vehicle goes out of 

range of an RM. An RM detects the leaving of a 

vehicle within 5 seconds of it leaving, and this is 

shown by the change in RM-disp2, which displays 

the vehicle count. (c) A vehicle has an accident. 

VM-disp2 of the affected vehicle will display the 

letter ‘E’. RM-disp1 will display the vID of the 

vehicle. VM-disp1 and VM-disp2 of nearby 

vehicles will show ‘E’ and the vID of the affected 

vehicle respectively for 5 seconds before reverting 

back to the normal state, described above. This 

effect spreads onto vehicles farther away as the E 

frame propagates. 

There was no need for an error checking 

scheme as the data is refreshed regularly. Our 

prototype system makes an effective platform for 

723 

further enhancements in future, for example, by 

expanding the frame size and increasing data 

volume to support more features. The security 

aspect was also neglected in this preliminary 

model, making the system vulnerable to attacks 

by malicious vehicles, possibly jamming the 

roadside station. However, further developments 

can make the system impervious to such attacks. 

VII. REFERENCES 

[1] A. Shastri, R. Dadhich, Ramesh C. Poonia. 

“Performance Analysis of On-Demand 

Routing Protocols for Vehicular Ad-hoc 

Networks,” International Journal of Wireless 

& Mobile Networks (IJWMN) Vol. 3, No. 4, 

pages 103-111, August 2011. 

[2] Yue Liu, Jun Bi and Ju Yang. "Research on 

Vehicular Ad Hoc Networks," Control and 

Decision Conference. CCDC '09. Chinese, 

pp.4430-4435, June 2009. 

[3] Ghassan M. T. Abdalla, Mosa Ali Abu- 

Rgheff and Sidi Mohammed Senousi. 

“Current Trends in Vehicular Ad Hoc 

Networks,” Ubiquitous Computing and 

Communication Journal, 1-9 (2007). 

[4] Bilal Munir Mughal, Asif Ali Wagan and 

Halabi Hasbullah. “Efficient congestion 

control in VANET for safety messaging," In: 

4th International Symposium on Information 

Technology (ITSim'10), pages 654-659, June 

2010. 

[5] Lochert, C.; Hartenstein, H.; Tian, J.; Fussler, 

H.; Hermann, D.; Mauve, M.; , "A routing 

strategy for vehicular ad hoc networks in city 

environments," Intelligent Vehicles 

Symposium. Proceedings. IEEE, pp.156- 161, 

June 2003. 

[6] C2C-CC: CAR 2 CAR Communication 

Consortium. http://www.car-to-car.org/ 

[7] Sumaya Iqbal, Shihabur Rahman Chowdhury, 

Chowdhury Syeed Hyder, Athanasios V. 

Vasilakos and Cheng-Xiang Wang. 

“Vehicular Communication: Protocol Design, 

Testbed Implementation and Performance 

Analysis,” In IWCMC '09 Proceedings of the 

2009 International Conference on Wireless 

Communications and Mobile Computing: 

Connecting the World Wirelessly, pages 410- 

415. 2009. 

[8] Hope Microelectronics CO.,LTD. RF12 

Programming guide, 2006.

Protocol Design and Implementation of Vehicular Ad-hoc Networks

Create successful ePaper yourself

Delete template?

Save as template?