Zone Routing Protocol (ZPR) is a hybrid routing protocol that uses proactive and reactive routing. Using proactive and reactive routing protocols alone are inefficient in an ad hoc network. Proactive routing is known as a table driven protocol that keeps an up-to-date topological map of the entire network. Since proactive routing maintains information that is immediately available, the delay before sending a packet is minimal. Pure proactive routing scheme uses large amount of bandwidth to keep routing information up-to-date. Overall, proactive routing uses excess bandwidth to maintain routing information. On the other hand, reactive routing uses queries that are flooded throughout the network. Together with long setup delay, pure reactive routing scheme is less suitable for real time traffic. Reactive routing involves long route request delay. Zone Routing Protocol uses the best properties of proactive and reactive routing to have an efficient, reliable and scalable protocol.

Architecture:

ZRP is based on zone concept. A routing zone is defined for each node separately, and the zones of neighboring nodes overlap. There are two types of node in ZRP, the interior and peripheral nodes. Peripheral nodes are nodes whose minimum distance to the central node is exactly equal to the zone radius. Zone radius is defined by the number of hops. Nodes in the zone radius are the border nodes of the zone. Interior nodes are nodes whose minimum distance is less than the zone radius. The number of nodes in zone routing can be regulated by adjusting the transmission power of the nodes. However, forming a large zone can affect the redundancy and reachability of the nodes.

In the ZRP the proactive routing refers to IntrA-zone Routing Protocol (IARP) while the reactive routing refers to IntEr-zone Routing Protocol. The IARP maintains the routing information of the nodes within the zone. IERP main job is to provide routing to the nodes that are belonged to a different zone.

ZRP uses bordercasting when node of local zone communicates to the other nodes of a different zone. Since the topology of local zone is known, it is used to reduce traffic when finding global route. Bordercasting utilizes the routing information provided by IARP to direct request to the border of the zone. The bordercast packet delivery service is provided by the Bordercast Resolution Protocol (BRP). BRP uses a map of an extended routing zone to construct bordercast trees for the query packets. Alternatively, it uses source routing based on the normal routing zone [1].

In order to detect new neighbor nodes and route failures, ZRP uses Neighbor Discovery Protocol (NDP). NDP is provided by Media Access Control which sends hello packets at regular intervals. Neighbor nodes that receive the hello packets update its table. Nodes that are not heard a given time will be removed from the table.

Route updates are triggered by NDP, which notifies IARP when the neighbor table is updated. IERP uses the routing table of IARP to respond to route queries. IERP forwards queries with BRP. BRP uses the routing table of IARP to guide route queries away from the query source [1].

Routing:

Node that has packet to send checks whether the destination node is within the local zone using the information provided by the IARP. If the node is within the local zone it can be routed proactively. If the destination node is outside zone, reactive routing is used.

Reactive routing is divided in two phases, route request and route reply phases. In the route request phase, the source node sends a route request packets to the peripheral nodes using BRP. If the receiver node knows the destination of the route request packet, it responds by sending a route reply back to the source. Otherwise, it continues the process by bordercasting the packet. In bordercasting process, the bordercasting node sends a route request to each of its peripheral nodes. This multicast transmission is used to reduce the resource usage.

Any node that can provide route to the destination will send reply. Nodes use the route information packet to send reply back to the source. When the packet reaches the destination, the addresses use is reversed and copied to the route reply packet. The other approach is to use next-hop addresses in the nodes along the path. The forwarding node records routing information as next hop addresses, which is used to send reply to the source. This approach saves transmission resources as the request and reply packets are smaller.

Source:

[1] Nicklas Beijar, Zone Routing Protocol

http://www.tct.hut.fi/opetus/s38030/k02/Papers/08-Nicklas.pdf

Testing the performance and scalability of VANET protocols and applications is essential in metropolitan, suburban and rural scenarios. It’s also important to test and evaluate the message delay, coverage, and persistence in these three scenarios. Currently, deploying a large fleet of vehicles equipped with VANET technology to test protocols and applications would be too expensive and unpractical. So, a simulation is needed to model street topology, congestion, speed limits, communication channels, and spatio-temporal trends in traffic intensity on the performance and reliability of vehicle-to-vehicle networking (Mangharam, 2006). GrooveNet is designed to handle these situations with simulations of thousands of virtual vehicles that are equipped with global positioning systems (GPS) and wireless network interfaces.

GrooveNet has eight important features (Mangharam, 2006):

1)      It is a modular event-based simulator with well-defined model interfaces that allows users to add additional models.

2)      It supports multiple vehicle, trip, and mobility models over a numerous types of network link and physical models. Included are simple car-following, traffic lights, lane changing and simulated GPS models.

3)      It has an easy to use graphical interface that allows the user to auto-generate simulations with thousands of vehicles anywhere in the United States. Vehicles obey speed limits and can be followed by their current GPS coordinates.

4)      Three types of simulated nodes are supported: 1) multi-hopping data over multiple DSRC channels. 2) fixed infrastructure nodes and 3) mobile gateway communication between vehicles-to-vehicles and vehicle-to-infrastructure (RSUs).

5)      Multiple types of messages are supported such as GPS broadcasts to tell neighbors of vehicles’’ current positions, emergency and warning event with priorities and supports multiple rebroadcast policies to address and investigate broadcast storms issues.

6)      Multiple network interfaces can be used for vehicle-to-vehicle and vehicle-to-infrastructure communication. This means one interface can be 802.11g and another could be an EVDO cellular interface.

7)      It supports a hybrid VANET that can have simulated vehicles and real vehicles together in simulations. The simulated vehicles’ positions, direction, and messages are broadcast over a cellular interface from infrastructure nodes.

8)      It can connect to vehicles’’ on-board computers and read OBD-II diagnostic codes. This makes it able to monitor sudden deceleration, braking, air bag deployment and signals from the anti-lock braking system and send out alerts to neighboring vehicles.

GrooveNet operates in two modes: simulator mode and on-road test-bed or hybrid mode. Simulator mode models approximate vehicular communication and mobility to the first order and new custom models can be added. GrooveNet has four major components (Mangharam, 2006): 1) the simulator; 2) vehicle network emulator; 3) network and device interfaces; 4) vehicle operations director (VOD).  Hybrid mode is real vehicle test-bed with Linux-based laptops running GrooveNet. Each vehicle has a Denso-based DSRC interface, an EVDO cellular interface, a CSI-wireless Differential GPS receiver, and a headset for voice communication between vehicles (Mangharam, 2006).

Developing a realistic VANET simulation is important due to the costly deployment of a real-world environment. Simulations need to enable virtual vehicles to exchange active safety, transportation efficiency, and other application data. Most of these applications need to be tested on a large scale network with hundreds or thousands of vehicles. There needs to be repeatable experiments which are almost impossible in a real-world environment.

Most current VANET simulations are based on the Network Simulator version 2 (ns2), as the network simulator with a set of road mobility models. This, however, doesn’t reflect the true characteristics and features of VANETs. TraNS is designed to fix this issue by combining Simulation of Urban Mobility (SUMO), a traffic simulator, and ns2, a network simulator. This allows ns2 to use realistic mobility models and influence the behavior of SUMO, based on the communication between vehicles (Piorkowski, 2008). Active safety and traffic efficiency applications have also been implemented in the simulation. TraNS goal is to have simulation results that closely resemble real-world experiments.

TraNS has two modes of operation: network-centric and application-centric. Network-centric is used to evaluate VANET communication protocols that don’t influence in real-time the mobility of nodes like music or travel information (Piorkowski, 2008). Application-centric is used to evaluate VANET applications that influence node mobility in real-time and during traffic simulation runtime like active and public safety applications (Piorkowski, 2008). In network-centric mode, TraNS provides realistic mobility models to ns2 from SUMO. Its main component is the parser that resides in between the road traffic simulator and ns2. The parser translates the dump file of the road network map to a format readable for ns2.

In Application-centric mode, ns2 is allowed to control the mobility of certain vehicles in the simulation runtime. Traffic Control Interface (TraCI) is an interface that is used to couple road traffic and networking simulators. This allows the user to evaluate VANET applications that influence the mobility of vehicles. TraCI runs on a feedback loop that makes it possible to modify mobility of individual vehicles due to information exchange within VANET (Piorkowski, 2008). It uses atomic mobility commands like stop, change lane, and change speed to manipulate vehicle’s mobility. This allows complex vehicle mobility patterns to be broken down into a set of consecutive atomic mobility actions.

In the upcoming versions of TraNS, there will be a simple driver behavior model which will take decisions upon reception of messages exchanged between vehicles (Piorkowski, 2008). It will allow more sophisticated behavior patterns of drivers. The next version will also support large-scale simulations of 10,000 nodes or more, as well as modeling the cost of implementing security into the VANET protocols. There will also be a comparison to other simulators with an objective benchmark of VANET simulators.

Link:

http://nsl.csie.nctu.edu.tw/NCTUnsReferences/trans_poster.pdf

I have started learning the basics of OPNET and have completed the first lab in the book that Sathya gave me.  The lab was based on an Ethernet network setup in a bus topology (below).  I also did some research on Ethernet networks to get a better understanding of the topic.

I then created an OPNET simulation that tested the throughput of the network under several traffic loads by adjusting the Traffic Generation time.  I then checked my results in the graph to see the maximum traffic load the network could handle before throughput diminished.(below)

• Describes aspects of Safety VANET (SVANET)
• Ideal features of an SVANET system
• Describe a Message Dispatcher(MD) architecture
• Illustrate successful implementation of MD

Safety Aspects of an SVANET

There has been much deliberation and debate as to which safety applications would provide the most benefits to drivers on the road.  The US Department of Transportation along with many other government and industry groups have identified the eight applications they see with the highest benefits:

1. Traffic signal violation warning
2. Curve speed warning
3. Emergency electronic brake lights
4. Pre-crash warning
5. Cooperative forward collision warning
6. Left turn assistant
7. Lane change warning
8. Stop sign movement assistance

The frequency of these applications range from 1-50 Hz and the size of data packets ranges from 250 to 500 bytes with a maximum communication range of 50 to 300 meters.  The Society of Automotive Engineers (SAE) has developed 70 data elements such as brake light status, acceleration, etc.  Of the 70 elements, 30 of the most commonly used elements are used for a common data set in a packet.

Since it is difficult and mostly unnecessary to maintain a topology of 2-3 hop neighbors, DSRC 1 hop broadcasting seems to be the best method for relaying safety messages to nearby vehicles.

Desirable Architecture Features

Future Proof:  The system will work with newly defined, created, or upgraded applications developed in the future.

Flexibility:  Be able to deal with differant sets of applications running on each vehicle.

Extensible:  Be able to add support for non standard applications and data elements.

Single Interface:  A single entity will run policies and protocols for each application in a vehicle as well as security and authentication measures.

Low Bandwidth Usage:  Use as little bandwidth as possible so heavy traffic areas do not overflow the channels.

Information Rate:  System should be able to recognize elements that do not change often (such as head light status) and only send this information when appropriate, lowering redundant messages.

Recognize vehicle capabilities:  Messages must reflect when a vehicle is not able to measure certain pieces of information.(Such as older vehicles lacking proper sensors)

Enable product differences:  As different car manufacturers offer unique applications for their consumers, the system should be able to support them without limiting them.

Message Dispatcher

The MD will handle all data exchange requirements of applications running on a vehicle by serving as an interface between the applications and the communication stack.

Basic MD Architecture:

1. Safety applications send messages to be broadcast to the MD
2. MD summarizes the data elements across each application and send a message containing the minimum number of data elements.
3. MD sends packet to DSRC radio for broadcasting.

Data Element Dictionary:

The SAE defined the 70 data elements mentioned earlier in a data element dictionary.  Each data element is defined using a standard name, a unique identifier, a unit of measure, the accuracy of the measure, the range of measure, size in bytes, and a description of the element.  The paper suggests grouping similar data elements(such as brake force, deceleration, anti-lock break status)  into a “Data frame” of elements commonly sent together which lowers overhead.

Implementation:

An MD was used in two Toyota Prius fitted with a Linux based mini PC, OBD-II vehicle interface a prototype DSRC radio and DGPS unit.  The vehicles ran an Emergency Break Warning(EBW) application and an Intersection Violation Warning(IVW) application at the same time.  After extensive testing, the channel loading of the MD was computed and found that the expected load would be far short of overflowing the channel.

Source:

Robinson, C. et al. “Efficient Coordination and Transmission if Data for Cooperative Vehicular Safety Applications”.  Advanced Wireless Networks Research Lab, VANET Tutorial Paper.

Link: http://awin.cs.ccu.edu.tw/vanet_tutorial.html

Mobility Modeling

Random Node Movement

This simulation is based on the random and unconstrained movement of nodes. One of the advantages of this type of simulation is it is easy to use. This simulation is far realistic because vehicles on the road do not move randomly.

Real World Mobility Trace

This technique uses node mobility based on set of prerecorded real-world mobility traces. The vehicle is tracked using on-board or subsidiary devices and the vehicle position recorded at regular intervals. Although this type of simulation is closest it can be to the real world, it also has some drawbacks. One of the drawbacks is that the simulation is based on set of pre recorded mobility traces. It is hard to changed and add some parameters in the scenario.

Artificial Mobility Traces

One of the difficulties in getting real-world data is time consuming and it requires many different kinds of scenarios to be able to get real world simulation. The Artificial Mobility Traces uses artificial movement traces in the simulation. The artificial mobility model has the advantage of providing simulations with very realistic mobility trace while at the same time allowing the mobility parameter to be freely adjusted in order examine their influence on a simulation out.

Bidirectional Couple Simulation

In this type of simulation two interdependent processes are running concurrently, namely the network attribute and road traffic simulator.

Network simulation

This type of simulation sends parameter changes to the road traffic simulation, altering driver behavior on road attributes and influencing vehicles routing decision.

Traffic Simulation

This simulation performs traffic computations based on new parameters and sends vehicle movement updates to the network simulation.

Source:

C. Sommer and F. Dressler. “Progressing Toward Realistic Mobility Models in VANET Simulation”. IEEE Communications Magazine. Nov. 2008.

This survey also mentioned an IEEE 802.11p work group that is trying to design a standard for VANETs that should be released by April of 2009, so I am going to read up on that, this survey is also almost 2 years old, so it would be good to see how much VANETs have progressed since this survey was written.  I also think this survey is useful to look at and improve upon towards our own paper.  For instance the paper does not discuss security, and has little mention of integration of cellular networks to increase connectivity.

Source:

Li, F. Wang, Y. ” Routing in Vehicular Ad Hoc Networks: A Survey”.  IEEE Vehicular Technology Magazine, June 2007, pg 12-22.

Link:

http://issuu.com/adioshun/docs/_____routing_in_vehicular_ad_hoc_networks?mode=embed&documentId=080513073204-0826eb95238a491b99dfa5a39da02122&layout=grey

Most of the research involving VANETs has been mainly focused in urban areas with large amount of vehicles close to each other.  This article discusses “packet delivery in a sparse, partially connected VANET” (Zhang, 2008). It introduces a border node-based routing protocol (BBR) that can “tolerate network partition due to low node density and high node mobility” (Zhang, 2008). The simulation environment is in Yellowstone National Park and the BBR protocol was implemented in OPNET Modeler.

VANETs are characterized by rapid topology changes and frequent fragmentation. Creating an efficient routing protocol is difficult due to high node mobility and movement constraints of mobile modes. An ideal routing protocol for rural VANETs would use ideal message exchange rules:

1.       Message hand offs would occur when moving vehicles are within radio range.

2.       Information exchange is instantaneous when two nodes are within radio range.

The following would be ideal in the simulation:

1.  There would be no message-processing time in each node.

2.  Vehicles would keep the message when they move on.

3. There would be a constant number of vehicles in the VANET during the simulation.

4. The simulation would end as soon as the message reached its destination.

5. Vehicles would move in accordance with predefined trajectories.

The BBR protocol uses the store-and-forward approach and is based on broadcast. A flooding control scheme is used with only one-hop neighbor information and it is specifically designed to handle the effects of node mobility on data delivery. It is “designed for sending messages from any node to any other node (unicast) or from one node to all other nodes (broadcast)” (Zhang, 2008). This is to “optimize the broadcast behavior for low node density and high mobility networks and to deliver messages with high reliability while minimizing delivery delay” (Zhang, 2008). The protocol has two functions: (a) neighbor discovery algorithm which collects current one-hop neighbor information and (b) border node selection algorithm which selects the right candidates for packet forwarding.

The simulation was run 15 times with different random number seeds. The radio transmission range varied from 8 to 800 meters. The results showed that when the radio transmission range increased, the packet delivery ratio greatly increased. Then at 80 meters, the packet delivery ratio stayed at 90 percent and then slowly reached 99 percent. This shows that the BBR can have a high delivery ratio even with a partially connected network. However, when the radio transmission range is very close together (10-50m), huge packet delivery delay occurs. This is caused by the nodes forwarding packets instead of using wireless communication among the nodes because the VANET is partially connected or highly partitioned.

The study for a rural VANET routing protocol is really important because a lot of the United States population live outside of cities and it will connect travelers in the remote areas.

Source:

Zhang, M., & R. Wolff. “Routing Protocols for Vehicular Ad Hoc Networks in Rural Areas”. IEEE Communications Magazine, Nov. 2008, pp. 126-131

Papadimitratos, P. , et. al. “Secure Vehicular Communication Systems: Design and Architecture”.  IEEE Communications Magazine, Nov. 2008, pp. 100-109

This paper discusses security threats for vehicular communications(VC) systems as well as security requirements and mechanisms for securing VC systems.  The authors also stress the importance of providing extremely secure VC or the benefits provided by these systems can be nullified.  For example a contaminated vehicle can send false signals, making itself appear as an emergency vehicle, or circulate false road conditions and hazards through all surrounding traffic.  It is also important to maintain anonymity so that messages can not track user transactions or whereabouts.

Adversaries

VC systems have only two types of entities, correct or benign.  Correct entities comply with protocol whereas benign entities are either faulty(errors that occur in normal conditions or equipment failure)  or adversarial.  The paper focuses on adversarial entities due to the fact that they are attacks on security and can cause larger sets of faults.  This paper discusses two types of adversaries.

1. Active:  These types of attackers have modified systems that can forge or repeat previous messages and inject them into the system.  They can also modify messages that they receive before they send to the next node or halt communications between nearby vehicles altogether.
2. Inactive: Attackers that are inactive simply learn and store information from surrounding entities but do not alter or form messages.

Security Requirements

• Message authentication and integrity: Provide protection against message alteration and confirm the sender.
• Message non-repudiation: Makes sure that the entity that sent the message cannot deny that it was the sender.
• Entity Authentication: Ensure that received message was generated by the sender in real time.
• Access Control: Determine actions that different nodes are allowed to perform.
• Message Confidentiality: Protect content of messages from those not authorized to view it.
• Accountability: Map security related events to system entities.
• Privacy Protection: Protect sensitive information of user in VC systems and maintain anonymity.

The  paper further outlines the overall design of a secure VC system wherein all nodes must be registered to a certification authority (CA) and numerous CAs exist to cover separate regions.(Counties, states, etc.)  Each node will also have a hardware security module(HSM) which will physically protect the node’s information.    To ensure secure communication, each node will have multiple public keys that are only known by the CA to ensure security and anonymity.  These public keys will also change often to further ensure the user’s privacy.