Vehicular Adhoc Network (VANET) is an outgrowth of Mobile Adhoc Network (MANET), in which the mobile vehicles on road and the stationary roadside units (RSU) constitutes the nodes and communicate with each other on the fly (Fig. 1); Vehicle to Vehicle (V2V) and Vehicle to Roadside Unit (V2R). VANET can be categorised under hybrid architecture that consists of both infrastructure and infrastructure less features. VANET nodes are capable of self organising and managing the information in a distributed fashion with or without any centralised authority. Road Side Units (RSU) supported by DSRC standard [2] acts as gateways or fixed access points to vehicles in mobility and provides interim connectivity to vehicles. One of the major advantages of VANETs over MANETs is the unlimited battery power generated on the fly. VANET plays a major role in defining safety measures by streaming communication between vehicles, infotainment and telematics.
In any generic network phenomena the concept of routing and its characteristics are highly linked with Quality of Service (QoS). The United Nations Consultative Committee for International Telephony and Telegraphy (CCITT) Recommendation E.800 has defined QoS as: “The collective effect of service performance which determines the degree of satisfaction of a user of the service”. The major concern of VANET routing is that whether the performance can satisfy the throughput and delay requirements of such media streaming applications. Unavailability of efficient routing algorithms for the VANET scenario, force the researchers to use the MANET routing algorithms. An analysis of VANET routing protocols shows that its performance is not acceptable due to the feature of very high mobility in terms of speed[3]. Its adverse effect leads to broken links, with high packet drop and overhead due to missing route repairs or failure. This phenomenon leads to low throughput ratio and high delay in transmission.
Figure 1. A VANET Scenario.
This research work proposes an improved version of REDEM, a reliable QoS aware routing scheme for dynamic vehicular ad hoc network ( REDEM), which focuses on identifying optimal paths. The outcome of the research work is compared with the performance of AODV, based on simulation test beds using ns2 simulator. The proposed routing scheme has been designed and implemented as per the DSRC specifications [4] and IEEE 802.11p MAC.
The aim of the research work focuses on:
 Analysis and identify the required optimal QoS for
P.R. Subramaniam et al. / IRRIT, Vol. 1, No. 3, pp. 58-62, September 2011 59 media streaming services over VANET.
 To provide an optimal QoS for highly congested VANET test bed.
 To find a QoS validated route between highly “on mobile” vehicles using REDEM.
The simulated results show that REDEM protocol’s performance is better than the AODV protocol for VANET.
2. QoS issues in VANET
Most of the car manufacturers are involved in implementing wireless connectivity between vehicles and road side units and also between vehicles for the purpose of safety, driving assistance and entertainment. This vehicular network has constraints such as road type, mobility pattern, speed, number of vehicles on road, etc. Providing QoS for media streaming applications in VANET is highly challenging due to highly dynamic vehicle mobility, unpredictable driver’s behaviour which leads to frequent link breakage (short life time of node connection).
A QoS extension for AODV routing packets has been proposed by Perkins [9] to provide QoS. This extension specifies the service requirements which must be met by nodes whilst (re)broadcasting a route request or route reply. In particular it specifies to ensure a delay that does not exceed a maximum value or to ensure a certain amount of network capacity (bandwidth) is made available along a route between communication partners. Another QoS routing protocol based on AODV [10], has used only bandwidth as QoS metric for a route that is identified.
In VANETs, the support for QoS is to be thought as an inherent necessity rather adding such features as an afterthought. Following are the reasons that insist on the need for QoS enabled routing algorithms:
a) Limited bandwidth availability results in rapid fluctuation of wireless channel that severely affects multi-hop flows.
b) Very high speed node mobility may affect the network topology to change frequently that will have an impact on packets contending for the shared media.
c) Interference can affect transmission on adjacent links and nodes beyond neighbours.
3. REDEM modelling and design
REDEM is modelled as a set of high speed vehicles on a straight highway in which any vehicle can establish connectivity with any other vehicle(s) travelling in same direction or opposite direction. Vehicles within communication range can act as intermediate nodes and participate in forwarding the data packets to be transmitted between the source and destination. Periodic “hello” packets floated by the nodes in the network degrades the performance of the VANET by increasing overhead and congestion.
Geographical routing protocols, such as GPSR [5], GPR [6], require geographical node positions to route data between end-points. Receiver based hop selection is proposed for most of the routing protocols [8] at routing layer or at MAC layer [2] [7]. REDEM proposes a distributed, receiver-based next-hop selection routing protocol to minimise the overhead. REDEM metrics are primary to identify the optimal QoS on-demand for various types of services between different nodes in communication. REDEM uses the following metrics:
 Bandwidth
 Delay
 Packet Loss
3.1. REDEM Architectural Design
Fig. 2 shows the architecture of REDEM. The six modules shown in the architecture interact with each other, discover and update the optimal route between the source and destination nodes involved in media streaming. The following are the six modules:
1. Network manager
2. Reverse route identification and neighbour discovery
3. QoS manager
4. Resource manager
5. Optimal route discovery
6. Route update
These six modules make use of two tables – routing table and neighbours table, where the information about the discovered routes and neighbours are stored respectively. The functions performed by these six modules are discussed in 3.2.
Figure 2. A REDEM Architecture.
The labels on the edges connecting the various modules in the architecture are numbers that indicate the sequence of operations carried out by REDEM. Brief description of the operations carried out are by the various modules is given below in the same sequence.
1. Send and receive the RREQ and RREP packets between the source and destination vehicles.
2. Transfer the received packets to the reverse route identification module.
2.1 Update neighbours table with the received frames.
2.2 Create a reverse route entry in the routing table to the source vehicle.
3. Initiate the optimal route discovery.
Vehicle
Vehicle
Vehicle
Network Manager
Route Update
Reverse Route Identification
QoS Manager
Route Discovery
Resource Manager
Routing Table
Neighbors Table
5
1
1
RREQ
RREP
1
2
7
Delay
Pkt Loss
Bandwidth
Speed
Bandwidth
Queue model
Signal Strength
3
3.1
2.1
2.2
7.1
6.1
6
4.1
4
P.R. Subramaniam et al. / IRRIT, Vol. 1, No. 3, pp. 58-62, September 2011 60
3.1 Retrieve the existing neighbours’ information from the neighbours table.
4. Transfer of route requests and replies between the resource manager and the QoS manager.
4.1 Allocation of resources by the resource manager along the optimal route to the destination using neighbours table.
5. Forward route requests to route discovery and receive route replies from it.
6. Send the optimal route information to route update.
6.1 Retrieves the routing table information to identify the optimal route.
7. Inform the network manager about the optimal route.
7.1 Update the routing table with the optimal route
3.2. REDEM Modular Design
Module 1: Network Manager
1. This module exchanges the RREQ and RREP packets with the vehicles.
2. Collects the following information from the nodes in the networks:
i. Speed of the vehicle ii. Bandwidth utilised by the vehicle iii. Delay of the service iv. Packet loss of the service
v. Number of vehicles in the network
Module 2: Reverse Route Identification & Neighbour Discovery
When a RREQ control message was received, this module will create a reverse route to the vehicle from which the packet was received.
Algorithm to identify Reverse Route
1. Receive RREQ
2. If RREQ source available in Neighbours table {
If duplicate RREQ {
Discard RREQ
}
}
Else {
Add that source to the Neighbours table
Add a reverse route to the source
}
Information about the vehicle from which the control packet was received, will be added to the Neighbours table. This Neighbours table will provide information during the optimal route discovery process.
Module 3: QoS Manager
1. Negotiate on the QoS parameters required by the source to provide the service or application.
2. Check whether an intermediate vehicle receiving a RREP has sufficient resources to provide that service.
3. Initiates a request to the Resource Manager to identify an optimal route.
QoS Parameters Negotiation
Based on the application requirements by the source, the QoS parameters need to be negotiated with the QoS Manager.
If application == VI {
// VI = Video; AU = Audio; CF = Conference;
// MS = Text Message
Req.Bandwidth(RBW) = 2 Mbps
Req.Delay(RDL) = 50 ms
Req.PacketLoss(RPL) = 5%
}
Before forwarding a RREQ or RREP to the next neighbour, the vehicle has to check whether it has sufficient resources to be a part of that route.
Receive RREP
If Rep.Bandwidth