InterVehicular Communications

159
Courtesy: Jean Marie Zogg u-blox and uNAV Inter-Vehicular Communication Department of Information & Communication Technology ,MIT Manipal

description

PPT about IVC

Transcript of InterVehicular Communications

Courtesy: Jean Marie Zogg – u-blox and uNAV

Inter-Vehicular Communication

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

.A GPS fitted, aerial vehicle moves from Le Harve to Lyon. When the vehicle started at Le Harve, the readings on the GPS receiver were(* indicates degrees)

49*28’33.91’’ N0* 4’06.70” EAltitude = 30 MetersThe vehicle when landed in the Lyon, the GPS readings were 45*44’57.23”N 4*49’28.17” EAltitude – 120 Meters Compute the Distance covered by the Vehicle.

Given x = alt * cos(long) * sin(90 deg – lat)y = alt * sin(long) * sin(90 deg – lat)z = alt * cos(90 deg – lat)

Courtesy: Jean Marie Zogg – u-blox and uNAV

•Component of Intelligent Transportation System (ITS)•One of the concrete applications of MANETS-VANETs

Motivation•Improves road safety and efficiency by increasing the horizon of drivers

and on-board devices•Transmission of road-side information about emergencies, congestion, etc.

•Ability for inter-driver communication•Existing ad hoc networks protocols and experiences can actually be put

to practice

Inter vehicular Communication:

Courtesy: Jean Marie Zogg – u-blox and uNAV

Groups & Applications•Association of Electronic Technology for Automobile Traffic and Driving (JSK), Japan - early 1980’s•CarTALK, EU - 2000•FleetNet, Germany - 2000•PATH, California•Chauffeur, EU•DEMO 2000, Japan

Groups & Applications

Courtesy: Jean Marie Zogg – u-blox and uNAV

IVC – Main Applications

Information and Warning FunctionsDissemination of road information to distant vehicles

Communication-based Longitudinal ControlExploiting “look-through” capacity to avoid accidents, platooning vehicles, etc.

Co-operative Assistance SystemsCoordinating vehicles at critical points

Added-value ApplicationsInternet access, Location-based services, Multiplayer games

Courtesy: Jean Marie Zogg – u-blox and uNAV

•Both infrared and radio waves have been studied and employed•Radio waves: VHF, micro, and millimeter waves•VHF and microwaves are of broadcast type•Dedicated Short Range Communication (DSRC) spans 75MHz of

spectrum in the 5.9 GHz band•DEMO 2000, Chauffeur used 5.8 GHz DSRC•CarTALK, FleetNet use ULTRA TDD•JSK, PATH, CarTALK have used infrared, typically for cooperative driving

Radio Frequency Spectrum

Courtesy: Jean Marie Zogg – u-blox and uNAV

Definition: Wireless Networks

Refers to the use of infrared or radio frequencysignals to share information and resourcesbetween devices

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

Definition: Wireless Ad hoc Networks

is a Computer Network in which the communication linksare wireless. The network is Ad hoc because each node iswilling to forward data for other nodes, and so thedetermination of which nodes forward data is madedynamically based on the network connectivity

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

Routing In Adhoc networks(MANET)

Courtesy: Jean Marie Zogg – u-blox and uNAV

Routing in Wire Net

Link State

Distance Vector

Will it Work for MANET??

Courtesy: Jean Marie Zogg – u-blox and uNAV

Structural differences b/w Wired & Wireless

WIRELESS WIREDSl.No

Rate of topology change

High, due to mobility of nodes etc.

Very less, since nodes are stationary. Normally event driven.

1

Quality of LinkLess predictable, fluctuates considerably depending on network and environmental conditions.

Stable when compared to wireless Networks2

Link TypeWireless Links can be asymmetric and unidirectional.

Symmetric and bidirectional3

Courtesy: Jean Marie Zogg – u-blox and uNAV

Structural differences b/w Wired & Wireless

WIRELESS WIREDSl.No

Broadcast transmissions

Unreliable Does not exist4

Usage of resources -battery power, transmission bandwidth, CPU time

Presents technological limitations on usage of resources

Does not present more technological limitations

when compared to wireless networks.

5

SecurityWeak. Due to the nature of radio transmissions, in the absence of any authentication mechanism, a malicious node can easily corrupt route tables etc. Advertise false route information.

Much better than wireless Networks.

6

Courtesy: Jean Marie Zogg – u-blox and uNAV

How MANET different?

Bandwidth constraint

Power constraint

Short radio range (150-200 meter)

High mobility -> no fixed route

Courtesy: Jean Marie Zogg – u-blox and uNAV

Why Wired-solution not Work?

Link State:� Each node must know whole topology � Flooding of information for high mobility � Require consistency in the RIB

Distance Vector:� Maintain complete list of routes � Broadcast create high overhead for high mobility� Count to infinity, routing loop, convergence time

Courtesy: Jean Marie Zogg – u-blox and uNAV

Constraints in Mobile Ad-Hoc Networks Information about network flows is typically not available in

datagram networks.

Network topology can vary rapidly.

Incremental delay and residual capacity, change more quickly than the physical topology.

Even if a radio generates timely routing information that reflects changes in delay and capacity, the delay in propagating that information throughout the network may be such that the information is stale by the time it reaches a distant node.

Incremental delay and residual capacity of a radio link are affected by the traffic being carried on other radio links.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Routing and Mobility Management in Infrastructure Wireless N/W’s

Mobility Management

- consists of set of mechanisms by which location information is updated in response to terminal mobility.

Location tracking consists of 2 operations

- Updating (Registration)-- The process by which a mobile endpoint initiates a

change in the location database according to its new location.

- Finding (Paging)-- The process by which the network initiates a query

for an endpoint’s location to update the location databases.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Routing and Mobility Management Contd….

For Wired Environments

- Routing paths are fixed since terminals are static.- Location tracking is not required

For Infrastructure Wireless Networks

- Endpoint mobility within designated area is transparent to the network.

- Location tracking is required when an endpoint moves from one domain to another.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Updating the location database

Two strategies are used for updates.- Static update strategy- Dynamic update strategy

Static update strategy - Consists of predetermined set of areas in which

location updates may be generated.- Location update is generated only when endpoint enters one of these cells.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Static updating strategy in detail

Two approaches are used in updating.

- Location areas- Reporting cells

Location areas

- Also referred as paging or registration areas- Service area is partitioned into group of cells.- Each group is a location area.- Endpoint’s position is updated if and only if it changes location areas.

- When an endpoint needs to be located, paging is done over the most recent location area visited by endpoint

Courtesy: Jean Marie Zogg – u-blox and uNAV

Static update strategy Contd….

Reporting Cells

- Subset of cells is designated as the only one from which the endpoint location may be updated.

- When an endpoint needs to be located , search is conducted in the vicinity of the reporting cell, from which the most recent update was generated.

Drawbacks of static update strategy

- Do not accurately account for user mobility and frequency of incoming calls.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Updating location database Contd…Dynamic update strategy

- Update is generated by the endpoint based on its movement.

- Update may be generated in any cell.

Three dynamic strategies are described in which an endpoint generates a location update.

- Every T seconds (time based)- After every M cell crossings (movement based)- Whenever the distance covered (in terms of number

of cells) exceeds D (distance based).

Courtesy: Jean Marie Zogg – u-blox and uNAV

Location tracking in Internet

Mobile IP

- Protocol standardized by IETF - Provides support for mobile hosts in internet- Mobile nodes are allocated permanent IP addresses in home network.

- Mobile nodes are allocated new temporary forwarding addresses as it moves to a foreign network.

Two ways of obtaining forwarding address

- Through the foreign agent in the visited network.- Address discovery protocol such as DHCP.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Location tracking in internet Contd….

Data transfer

- A node wishing to send a message to a mobile node sends the message to the permanent address of the node.

- If the mobile node is in the foreign network (roaming away from home network), the message is encapsulated and tunneled to its new location.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Routing and Mobility Management in Mobile Wireless N/Ws

In mobile networks with mobile infrastructure, such as mobile radio networks, communication terminals are free to move, causing frequent change in routing paths.

Mobiles must keep track of each others locations and interconnectivity as they move.

Mobility management in MANET involve 3 mechanisms.Route discovery

- Initially mobile node consults its route cache for the presence of route.

- If the unexpired route to the destination does not exist, initiates route discovery procedure.

- Discovery procedure is completed when one or more routes are found or all possible route permutations are examined.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Routing and Mobility Management in Mobile Wireless N/Ws

Route selection

- Considers local or global information about the network state in selecting the next hop to the destination.

Route Maintenance

- Responsible for reacting to topological changes in the network so that in the event of a link failure the affected data sources are informed.

- Error in the link may be repaired locally at the point of failure with no further notification to affected source node.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Discovery

Three components are considered- Source Node

- Intermediate Nodes- Destination Node

Source Node

- Broadcasts (flooding) a query (Route Request) packet in order to discover the route to the destination.

- The packet is flooded through the network.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route discovery Contd….Intermediate Nodes

- Helps in propagating the requests if

-- The request has not been forwarded previously.-- The node is not the destination of the searching procedure.

- Extracts reachability information for the source node on receiving the route request.

-- This is accomplished by using the mobile node from which the query was obtained, as the next hop to reach the source node.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Discovery Contd….Destination Node

- On reception of query packet, a route reply message is sent back to the source indicating the route to destination.

Route reply travels in the reverse direction of the discovered route.

- Each intermediate node maintains route request table.- When a node receives a route reply, the matched route

request is retrieved from the route request table.- The route reply is then forwarded to the node (Source

node) from which the initial route request message was received.

Route reply contains route-cost information

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Discovery ….

Recipients can select routes based on specific costs.

Each recipient of the route reply may update its route to the destination using as next hop to the node from which the reply is obtained.

A node may also maintain multiple routes to other nodes, but route acceptance shall be done in a way as to guarantee freedom from loops.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Optimizations to flooding-based route searching

Two mechanisms are used for an efficient route discovery mechanism that reduces the excessive overhead induced by flooding.

- Query quenching- Expanding ring search

Query quenching

- Intermediate nodes on receiving the route query, may themselves reply to the query by sending a route reply message back to the source on behalf of destination, given that they maintain valid routing information for the destination in search.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Advantages & Disadvantages of Query quenching.

Advantages of Query quenching- Early quenching of the route search stops the spreading of the query flooding at some intermediate node.

- To a large extent query quenching may reduce the route discovery overhead and inherent route acquisition latency.

Disadvantages of Query quenching

- Since the route requests are not broadcasted end-to-end, the route constructed by the mechanism may not always be the optimum routes.

- The source node may be prevented from discovering the better route even if one exists.

- When up to date end-to-end information is required in proper route selection (such as end-to-end bandwidth availability, individual node energy reserve) , query quenching is not a desired option.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Optimizations to flood based route searching

Expanded Ring Search- Several route discovery attempts of limited scope are made before a

flooding is triggered.

- At each attempt the searching scope is increased by some factor.

- Process continues until

-- searching scope reaches maximum threshold after which query is flooded.

Or-- The node in search is successfully located

Drawbacks

- Increase in route discovery latency when the initial attempt to discover a route fails and a new route discovery cycle is initiated.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Selection and forwarding

In wired networks shortest path routing is preferred for packet forwarding.

In wireless mobile networks shortest path routing is not preferred since it does not differentiate between good links and bad links.

In wireless mobile networks a path with many forwarding hops may have better links and thus be of higher quality than a path with fewer, but worse-in-quality, links.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Maintenance

Route Maintenance

- It’s the mechanism that detects whether the network topology haschanged such that a data path is no longer viable and routereconstruction is required.

Detection of Broken Link

- Mechanism similar to beaconing protocols is used.- During the propagation of data traffic each forwarding node sends a

link layer acknowledgement to the previous hop node, confirming thepacket reception.

- If the node does not receive the link layer acknowledgement from thenext hop node after transmitting packets in maximum number oftimes, it indicates the link is broken.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Maintenance Contd….

Informing the source node about the broken route.- Route error message is sent by a node that detects the

broken route, to the source node.

At the source Node

- The source Node after receiving the route error message, removes the broken link from the cache.

- If the source node has another route to the destination in its route cache, it switches the flow over the new route immediately, else it may invoke a route discovery to find the new route.

Courtesy: Jean Marie Zogg – u-blox and uNAV

MANET Routing Decisions

ProactiveReactive/On-demandLocation aidedSingle / Multi-pathBest effort / Guarantee delivery

Courtesy: Jean Marie Zogg – u-blox and uNAV

MANET routing protocols

AD-HOC MOBILE ROUTING PROTOCOLS

ON-DEMAND-DRIVEN REACTIVE

HYBRIDDSDV

OLSR

TABLE DRIVEN/ PROACTIVE

DSR

AODV

ZRP

Courtesy: Jean Marie Zogg – u-blox and uNAV

Proactive Routing

Table DrivenEach node periodically floods status of its linksEach node re-broadcasts link state information received from its neighborEach node keeps track of link state information received from other nodesEach node uses above information to determine next hop to each destination

Courtesy: Jean Marie Zogg – u-blox and uNAV

Reactive Routing

Build route only when node needs to send data packetThe source flood the network by sending out a request to discover the destination and routeEach node keep a complete route to each active destination

Courtesy: Jean Marie Zogg – u-blox and uNAV

Reactive Protocols

�DSR�AODV

Courtesy: Jean Marie Zogg – u-blox and uNAV

Dynamic Source Routing (DSR)

On-demandProtocolRREQ: � route request

RREP: � route reply

RERR: � route error

S

D

5

62

1

4

3

RREQ (S)

RREQ (S)RREQ (S)

(S,5)

(S,6)

(S,2)

(S,6,4)(S,6,4,3)

(S,2,1)

Courtesy: Jean Marie Zogg – u-blox and uNAV

DSR

Route selection� Destination receive multiple RREQ� Shortest vs Fastest

Route cache� Promiscuous mode:A mode of operation in which nodes can

receive the packets that are neither broadcast nor addressed to itself

� Reduce floodingRouting data packet:� Use the route discovered during RREQ� Include the complete route inside data packet

Courtesy: Jean Marie Zogg – u-blox and uNAV

DSR: Route Maintenance

Perform only when route in useDetect out of range neighbor (failure)� Link layer feedback 802.11� Missing ACK

Send RERR back to original sender� How?� Route repair?

Courtesy: Jean Marie Zogg – u-blox and uNAV

ROUTE MAINTENANCE

1

5

4

2

3

7

8

12

6

10

11

14

15

9

13

Source ID

Destination ID

SELECTED PATH

ROUTE ERROR

BROKEN LINK

Courtesy: Jean Marie Zogg – u-blox and uNAV

Dynamic Source Routing: Advantages

Routes maintained only between nodes who need to communicate� reduces overhead of route maintenance

Route caching can further reduce route discovery overhead

A single route discovery may yield many routes to the destination, due to intermediate nodes replying from local caches

Courtesy: Jean Marie Zogg – u-blox and uNAV

Disadvantages

Packet header size grows with route length Flood of route requests may potentially reach all nodes in the networkCare must be taken to avoid collisions between route requests propagated by neighboring nodes� insertion of random delays before forwarding

RREQIncreased contention � Route Reply Storm problem� Reply storm may be eased by preventing a node from

sending RREP if it hears another RREP with a shorter route

Courtesy: Jean Marie Zogg – u-blox and uNAV

Disadvantages

An intermediate node may send Route Reply using a stale cached route, thus polluting other cachesThis problem can be eased if some mechanism to purge (potentially) invalid cached routes is incorporated. For some proposals for cache invalidation, see [Hu00Mobicom]� Static timeouts� Adaptive timeouts based on link stability

Courtesy: Jean Marie Zogg – u-blox and uNAV

Disadvantages of DSR

Excessive flooding to find routeHop-by-hop routeSecurity:� RREQ� Traceable route

Courtesy: Jean Marie Zogg – u-blox and uNAV

Ad Hoc On-Demand Distance Vector Routing

DSR includes source routes in packet headersResulting large headers can sometimes degrade performance� particularly when data contents of a packet are small

AODV attempts to improve on DSR by maintaining routing tables at the nodes, so that data packets do not have to contain routesAODV retains the desirable feature of DSR that routes are maintained only between nodes which need to communicate

Courtesy: Jean Marie Zogg – u-blox and uNAV

AODV

Route Requests (RREQ) are forwarded in a manner similar to DSRWhen a node re-broadcasts a Route Request, it sets up a reverse path pointing towards the source� AODV assumes symmetric (bi-directional) links

When the intended destination receives a Route Request, it replies by sending a Route ReplyRoute Reply travels along the reverse path set-up when Route Request is forwarded

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Requests in AODV

B

A

S EF

H

J

D

C

G

IK

Z

Y

Represents a node that has received RREQ for D from S

M

N

L

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Requests in AODV

B

A

S EF

H

J

D

C

G

IK

Represents transmission of RREQ

Z

YBroadcast transmission

M

N

L

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Requests in AODV

B

A

S EF

H

J

D

C

G

IK

Represents links on Reverse Path

Z

Y

M

N

L

Courtesy: Jean Marie Zogg – u-blox and uNAV

Reverse Path Setup in AODV

B

A

S EF

H

J

D

C

G

IK

• Node C receives RREQ from G and H, but does not forwardit again, because node C has already forwarded RREQ once

Z

Y

M

N

L

Courtesy: Jean Marie Zogg – u-blox and uNAV

Reverse Path Setup in AODV

B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L

Courtesy: Jean Marie Zogg – u-blox and uNAV

Reverse Path Setup in AODV

B

A

S EF

H

J

D

C

G

IK

Z

Y

• Node D does not forward RREQ, because node Dis the intended target of the RREQ

M

N

L

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Reply in AODV

B

A

S EF

H

J

D

C

G

IK

Z

Y

Represents links on path taken by RREP

M

N

L

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Reply in AODV

An intermediate node (not the destination) may also send a Route Reply (RREP) provided that it knows a more recent path than the one previously known to sender S

To determine whether the path known to an intermediate node is more recent, destination sequence numbers are used

The likelihood that an intermediate node will send a Route Reply when using AODV is not as high as DSR� A new Route Request by node S for a destination is assigned a higher

destination sequence number. An intermediate node which knows a route, but with a smaller sequence number, cannot send Route Reply

Courtesy: Jean Marie Zogg – u-blox and uNAV

Forward Path Setup in AODV

B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L

Forward links are setup when RREP travels alongthe reverse path

Represents a link on the forward path

Courtesy: Jean Marie Zogg – u-blox and uNAV

Data Delivery in AODV

B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L

Routing table entries used to forward data packet.

Route is not included in packet header.

DATA

Courtesy: Jean Marie Zogg – u-blox and uNAV

Timeouts

A routing table entry maintaining a reverse path is purged after a timeout interval� timeout should be long enough to allow RREP to come back

A routing table entry maintaining a forward path is purged if not used for a active_route_timeout interval� if no data is being sent using a particular routing table entry, that entry

will be deleted from the routing table (even if the route may actually still be valid)

Courtesy: Jean Marie Zogg – u-blox and uNAV

Link Failure Reporting

A neighbor of node X is considered active for a routing table entry if the neighbor sent a packet within active_route_timeout interval, which was forwarded using that entryWhen the next hop link in a routing table entry breaks, all active neighbors are informedLink failures are propagated by means of Route Error messages, which also update destination sequence numbers

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Error

When node X is unable to forward packet P (from node S to node D) on link (X,Y), it generates a RERR message

Node X increments the destination sequence number for D cached at node X

The incremented sequence number N is included in the RERR

When node S receives the RERR, it initiates a new route discovery for D using destination sequence number at least as large as N

Courtesy: Jean Marie Zogg – u-blox and uNAV

Destination Sequence Number

Continuing from the previous slide …

When node D receives the route request with destination sequence number N, node D will set its sequence number to N, unless it is already larger than N

Courtesy: Jean Marie Zogg – u-blox and uNAV

Link Failure Detection

Hello messages: Neighboring nodes periodically exchange hello message

Absence of hello message is used as an indication of link failure

Alternatively, failure to receive several MAC-level acknowledgement may be used as an indication of link failure

Courtesy: Jean Marie Zogg – u-blox and uNAV

Why Sequence Numbers in AODV

To avoid using old/broken routes� To determine which route is newer

To prevent formation of loops

� Assume that A does not know about failure of link C-D because RERR sent by C is lost

� Now C performs a route discovery for D. Node A receives the RREQ (say, via path C-E-A)

� Node A will reply since A knows a route to D via node B� Results in a loop (for instance, C-E-A-B-C )

A B C D

E

Courtesy: Jean Marie Zogg – u-blox and uNAV

Why Sequence Numbers in AODV

� Loop C-E-A-B-C

A B C D

E

Courtesy: Jean Marie Zogg – u-blox and uNAV

Optimization: Expanding Ring Search

Route Requests are initially sent with small Time-to-Live (TTL) field, to limit their propagation� DSR also includes a similar optimization

If no Route Reply is received, then larger TTL tried

Courtesy: Jean Marie Zogg – u-blox and uNAV

Summary: AODV

Routes need not be included in packet headersNodes maintain routing tables containing entries only for routes that are in active useAt most one next-hop per destination maintained at each node� DSR may maintain several routes for a single destination

Unused routes expire even if topology does not change

Courtesy: Jean Marie Zogg – u-blox and uNAV

Proactive Protocols

�OLSR�DSDV

Courtesy: Jean Marie Zogg – u-blox and uNAV

Optimized Link State Routing (OLSR)

The overhead of flooding link state information is reduced by requiring fewer nodes to forward the informationA broadcast from node X is only forwarded by its multipoint relaysMultipoint relays of node X are its neighbors such that each two-hop neighbor of X is a one-hop neighbor of at least one multipoint relay of X� Each node transmits its neighbor list in periodic beacons, so that

all nodes can know their 2-hop neighbors, in order to choose the multipoint relays

Courtesy: Jean Marie Zogg – u-blox and uNAV

Optimized Link State Routing (OLSR)

Nodes C and E are multipoint relays of node A

A

B F

C

D

E H

GK

J

Node that has broadcast state information from A

Courtesy: Jean Marie Zogg – u-blox and uNAV

Optimized Link State Routing (OLSR)

Nodes C and E forward information received from A

A

B F

C

D

E H

GK

J

Node that has broadcast state information from A

Courtesy: Jean Marie Zogg – u-blox and uNAV

Optimized Link State Routing (OLSR)

Nodes E and K are multipoint relays for node HNode K forwards information received from H� E has already forwarded the same information once

A

B F

C

D

E H

GK

J

Node that has broadcast state information from A

Courtesy: Jean Marie Zogg – u-blox and uNAV

1

5

4

2

3

7

8

12

6

10

11

14

15

9

13

Node 4 selects MPRset {2,3,10,12}

Node belonging to MPRset of node 4

Broadcast packets forwarded by members of MPRset

Courtesy: Jean Marie Zogg – u-blox and uNAV

OLSR

OLSR floods information through the multipoint relays

The flooded information itself is for links connecting nodes to respective multipoint relays

Routes used by OLSR only include multipoint relays as intermediate nodes

Courtesy: Jean Marie Zogg – u-blox and uNAV

Destination-Sequenced Distance-Vector

Each node maintains a routing table which stores� next hop towards each destination� a cost metric for the path to each destination� a destination sequence number that is created by the destination itself� Sequence numbers used to avoid formation of loops and distinguish stale

route from fresh ones

Each node periodically forwards the routing table to its neighbors� Each node increments and appends its sequence number when sending its

local routing table� This sequence number will be attached to route entries created for this node

A B C D

E

Courtesy: Jean Marie Zogg – u-blox and uNAV

Route Establishment

1

5

4

2

3

7

8

12

6

10

11

14

15

9

13

SourceID

Destination IDDESTINAT

IONNEXT NODE

DISTANCE SEQUENCE

NUMBER

2 2 1 22

3 2 2 26

4 5 2 32

5 5 1 134

6 6 1 144

7 2 3 162

8 5 3 170

9 2 4 186

10 6 2 142

11 6 3 176

12 5 3 190

13 5 4 198

14 6 3 214

15 5 4 256

Courtesy: Jean Marie Zogg – u-blox and uNAV

DSDV

Assume that node X receives routing information from Y about a route to node Z

Let S(X) and S(Y) denote the destination sequence number for node Z as stored at node X, and as sent by node Y with its routing table to node X, respectively

X Y Z

Courtesy: Jean Marie Zogg – u-blox and uNAV

DSDV

Node X takes the following steps:

� If S(X) > S(Y), then X ignores the routing information received from Y

� If S(X) = S(Y), and cost of going through Y is smaller than the route known to X, then X sets Y as the next hop to Z

� If S(X) < S(Y), then X sets Y as the next hop to Z, and S(X) is updated to equal S(Y)

X Y Z

Courtesy: Jean Marie Zogg – u-blox and uNAV

Hybrid Protocols

�ZRP

Courtesy: Jean Marie Zogg – u-blox and uNAV

Zone Routing Protocol (ZRP)

Zone routing protocol combines

Proactive protocol: which pro-actively updates network state and maintains route regardless of whether any data traffic exists or not

Reactive protocol: which only determines route to a destination if there is some data to be sent to the destination

Courtesy: Jean Marie Zogg – u-blox and uNAV

ZRP

All nodes within hop distance at most d from a node X are said to be in the routing zone of node X

All nodes at hop distance exactly d are said to be peripheral nodes of node X’s routing zone

Courtesy: Jean Marie Zogg – u-blox and uNAV

ZRP

Intra-zone routing: Pro-actively maintain state information for links within a short distance from any given node� Routes to nodes within short distance are thus maintained

proactively (using, say, link state or distance vector protocol)

Inter-zone routing: Use a route discovery protocol for determining routes to far away nodes. Route discovery is similar to DSR with the exception that route requests are propagated via peripheral nodes.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Routing Zone for NODE 8 in ZRP

1

5

4

2

3

7

8

12

6

10

11

14

15

9

13

SourceID

Destination ID

Courtesy: Jean Marie Zogg – u-blox and uNAV

ZRP: Example

SCA

EF

B

D

S performs routediscovery for D

Denotes route request

Zone Radius = d = 2

Courtesy: Jean Marie Zogg – u-blox and uNAV

ZRP: Example with d = 2

SCA

EF

B

D

S performs routediscovery for D

Denotes route replyE knows route from E to D, so route request need not beforwarded to D from E

Courtesy: Jean Marie Zogg – u-blox and uNAV

ZRP: Example with d = 2

SCA

EF

B

D

S performs routediscovery for D

Denotes route taken by Data

Courtesy: Jean Marie Zogg – u-blox and uNAV

Challenges

�Reactive v/s Proactive�Address Assignment

Courtesy: Jean Marie Zogg – u-blox and uNAV

Reactive versus Proactive

Choice of protocol depends on� Mobility characteristics of the nodes� Traffic characteristics

How to design adaptive protocols ?Existing proposals use a straightforward combination of reactive and proactive� Proactive within “radius” K� Reactive outside K� Choose K somehow

Courtesy: Jean Marie Zogg – u-blox and uNAV

Reactive versus Proactive

Need a more flexible way to manage protocol behavior

Assign proactive/reactive tag to each route (A,B) ?

How to determine when proactive behavior is better than reactive ?

Courtesy: Jean Marie Zogg – u-blox and uNAV

Address Assignment

How to assign addresses to nodes in an ad hoc network ?Static assignment� Easier to guarantee unique address

Dynamic assignment� How to guarantee unique addresses when partitions merge?

Do we need to guarantee unique addresses ?

Courtesy: Jean Marie Zogg – u-blox and uNAV

Summary

Plenty of interesting research problems

Research community disproportionately obsessed with routing protocols

Courtesy: Jean Marie Zogg – u-blox and uNAV

VEHICULAR ADHOC NETWORKS

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

VANETS???

Ad hoc network composed of vehicles.Provide communications among nearby vehicles.Communication between vehicles and nearby fixed equipment .

V2I (V2R) – Internet Access in vehicles.V2VOR IVC – Communication among vehicles.

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

NEED FOR VANETS….

SAFETY ON ROADS

- REDUCING ACCIDENTS- ALLEVIATING

TRAFFIC CONDITIONS- IMPROVING TRANSPORT EFFICIENCY- MONITORING TRAFFIC

ENVIRONMENT- REDUCE TRAFFIC CONGESTION- REDUCE POLLUTION

DRIVING COMFORT- DRIVING ASSISTANCE- INFOTAINMENT APPLICATIONS

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

ITS – IN BRIEF WHAT IS ITS?

Stands for INTELLIGENT TRANSPORTATION SYSTEM

ITS improves transportation safety and mobility

Enhances productivity through the use of advanced communications technologies.

Encompass a broad range of wireless and wire line communications-based information and electronics technologies.

The 5.9 GHz band has been designated by the FCC for vehicular communications using ITS.

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

CONTINUED….

ITS is made up of 16 types of technology based systems.

Systems are divided into two parts

Intelligent infrastructure systemsintelligent vehicle systems.

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

Intelligent Infrastructure

Department of Information & Communication Technology ,MIT Manipal

Arterial Management Freeway Management Transit Management Incident Management Emergency Management

Electronic Payment Traveler Information Information Mgmt Crash Prevention and safety

Roadway Operations and maintenance

Road Weather Management

Commercial Vehicle Operations Intermodal Freight

Courtesy: Jean Marie Zogg – u-blox and uNAV

Intelligent Vehicles

Department of Information & Communication Technology ,MIT Manipal

Collision Avoidance Systems

Collision Notification Systems

Driver Assistance Systems

Courtesy: Jean Marie Zogg – u-blox and uNAV

DSRC- An Overview� A wireless technology for vehicular traffic

� Road-to-vehicle communications by means of wireless is called“Dedicated Short-Range Communications (DSRC) developed by Japanfor ITS applications such as ETC, etc.

� Electronic Toll Collection (ETC) is a system for processing automatic tollcollection, using wireless communications between communicationequipment installed in toll gates and other units on passing vehicles.

� 5.8 GHz waveband planned for Dedicated Short Range Communication (DSRC) IN use inJapan.

� Existing DSRC in JAPAN of 5.8 GHz is meant for dedicated ITS applications and does notsupport future applications such as inter vehicular communications and general purposeapplications, and hence it has to be modified.

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

Department of Information & Communication Technology ,MIT Manipal

Spectrum of DSRC

Courtesy: Jean Marie Zogg – u-blox and uNAV

DSRC- type Inter Vehicular Communications (IVC)

DSRC type V2V enables

� Creation of ADHOC networks among vehicles.

� A person’s vehicle can communicate vehicle control information bi-directionally with other vehicles running nearby.

� A group of vehicles are configured which shares a communication service on a temporary basis.

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

DSRC- type Road to Vehicle Communication (V2R)

� Communication is done between wireless base stations located at the road-side and mobile stations.

� Service area environment will be on roads themselves or near roads.

� Service area is a pico-cell with a radius of approximately a few tens of meters or, at most a micro-cell with a radius of a few hundred meters.

� DSRC-type V2R systems, system design can be done on the basis of the following assumptions.

- Existence of “line of sight” communication paths- Multi-path propagation paths

� Capability of simultaneously providing multiple general purposeservices, in addition to ITS dedicated services such as VICS, ETC, AHS.

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

V2R General Purpose Services

� Mobile Communication Services.

� Satellite Broadcast Services.

� Large scale Data downloading Services.

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

DSRC and Other Communications

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

IEEE 802.11P

Department of Information & Communication Technology ,MIT Manipal

IEEE 802.11p is a standard in the IEEE 802.11 family.

IEEE 802.11p also referred to as Wireless Access for the Vehicular Environment (WAVE) defines enhancements to 802.11 required to support Intelligent Transportation Systems (ITS) applications.

Includes data exchange between high-speed vehicles and between the vehicles and the roadside infrastructure in the licensed ITS band of 5.9 GHz (5.85-5.925 GHz) for US.

IEEE802.11p is being standardized in the US and Europe.

Courtesy: Jean Marie Zogg – u-blox and uNAV

IEEE 802.11P

Department of Information & Communication Technology ,MIT Manipal

802.11p will be used as the groundwork for DSRC for US and Europe to support existing DSRC applications such as VICS,ETC etc as well as future applications.

The IEEE802.11p standard is being developed from IEEE802.11a.

Courtesy: Jean Marie Zogg – u-blox and uNAV

CHARACTERISTICS• VANETs are characterized by:

• Wide spectrum of applications (safety/non-safety)

• Self-organization and self-management (fully decentralized)

• Network protocol requirements (efficient geo-casting/flooding)

• Adverse medium conditions (congestion and radio channel)

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

Benefits and DrawbacksÆ Benefits

Ad-hoc vehicular networks provide ubiquitousenvironmentsAbundant information by C2C and C2IInteractiveness can provide location-based services,driving safety, and on-demand servicesNo practical limit on power and computationDrawbacks

– High mobility may restrict bandwidth– Security problems : identity, location privacy

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

Need for Data Validation

• Out-of-date informationVehicles move and change speedPackets may get lost in transitSolution: Data aging

• Malicious nodes can corrupt dataInject incorrect dataRefuse to forward dataModify data

• Solution: Probabilistic validation

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

Push v/s Pull

Most cars are interested in information about immediate neighboring road segment� “Push” mechanism is sufficient

How to get information about other roads?Broadcast is not scalable� Road segments are extensive in size� Traffic information is dynamic in nature

There is a need for “pull” i.e. On-Demand traffic query

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

On-demand Traffic Query Protocol

VITP – Vehicular Information Transfer Protocol� Location-sensitive queries and replies between nodes

of a VANET� VITP Peers – nodes that operate as

• Clients• Intermediates• Servers

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

Location-sensitive queries

Department of Information & Communication Technology ,MIT Manipal

Q uic kT im e™ and aT IF F ( Uncom press ed) decom pres sor

ar e nee ded t o se e t his pictu re.

Q uic kT im e™ and aT IF F ( Uncom press ed) decom pres sor

ar e nee ded t o se e t his pictu re.

Gas StationQuickTim e™ and aTIFF (LZW) decompressorare needed t o see t his pict ure.

Coffeeplace

QuickTim e™ and aTIFF (LZW) decompressorare needed t o see t his pict ure.

GSM Link

TrafficServer

Quic

kTim

e™ and a

TIF

F (U

ncompress

ed) decompres

sorare nee

ded to see this

picture.

Quic

kTim

e™ and a

TIF

F (U

ncompress

ed) decompres

sorare nee

ded to see this

picture.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Virtual Ad-Hoc Servers The server that computes the reply is a dynamic collection of VITP peers that:� Run on vehicles moving inside the target-location area

of Q.� Are willing and able to participate in Q’s resolution.

Department of Information & Communication Technology ,MIT Manipal

Gas StationQuickTim e™ and aTIFF (LZW) decompressorare needed t o see t his pict ure.

QuickTim e™ and aTIFF (LZW) decompressorare needed t o see t his pict ure.

Quic

kTim

e™ a

nd a

TIF

F (

Unc

ompr

ess

ed)

deco

mpr

esso

rar

e ne

ede

d to

se

e th

is p

ictu

re.

Courtesy: Jean Marie Zogg – u-blox and uNAV

VAHS (continued)

Established on the fly in an ad-hoc manner

Identified with a query and its target-location area.

Maintains no explicit knowledge (state) about its constituent VITP peers

Follows a best-effort approach in serving queries

VAHS members maintain no information about other members of the VAHS

Department of Information & Communication Technology ,MIT Manipal

Courtesy: Jean Marie Zogg – u-blox and uNAV

VITP transactions

Department of Information & Communication Technology ,MIT Manipal

VITP Peer

VANET node

VAHSQ

Q

Intermediary nodes

Q1Q2

Q3

Q4

Q5

Q6Q7

R

RR

Dispatch-query phaseVAHS-computation phaseDispatch-Reply phaseReply-delivery phase

Courtesy: Jean Marie Zogg – u-blox and uNAV

Department of Information & Communication Technology ,MIT Manipal

• Car manufacturers have massively invested in this area

• Security leads to a substantial overhead and must be taken into account from the beginning of the design process

• Plent of problems to address in ITS

CONCLUSION

Courtesy: Jean Marie Zogg – u-blox and uNAV

Inter Vehicular Communication Applications

Courtesy: Jean Marie Zogg – u-blox and uNAV

Why do we need IVC Applications??

Informing about traffic situations.

Informing about the things happening in that region when a vehicle passes through that region.

Getting all the information needed from the gateway node ( Information like latest news updates, latest score updates….etc). The gateways are connected to the internet.

Courtesy: Jean Marie Zogg – u-blox and uNAV

IVC ApplicationsInfoShare ( Information Sharing Application for IVNs)

- Application which is used to share data between thevehicles moving along the road.- Does not use any routing algorithm.- Query message is broadcasted in a multihop fashion.

InfoGeo- Built upon infoshare.- Uses Georoute routing algorithm.

Courtesy: Jean Marie Zogg – u-blox and uNAV

A simple Scenario • Gateway nodes are present at the roadends which are connected to the internetand which contain all the information items.

•When a vehicle passes through a gatewaynode, it downloads all the information fromthe gateway node.

•When a vehicle is far away from agateway node and if it needs someinformation, it tries to get the informationwith the help of other vehicles. ( The othervehicles act as the relays).

Courtesy: Jean Marie Zogg – u-blox and uNAV

A Simple Scenario

•For example, in the figure shown, ifthe violet car wants some information,it is away from both the gatewaynodes. So, it broadcasts the querymessage and other vehicles receivethis query message. If that vehiclehas the required information, it replieswith the required information. If itdosen’t have, it also broadcasts thequery.

•So, in this example, blue, pink andred vehicles receive the query fromviolet car when it needs someinformation. So, these cars act asrelays.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Requirements for these applicationsVehicles to be equipped with high bit rate radiointerface and gigabytes of storage supporting lots ofapplications.Sensible dissemination and caching policy is needed.A set of information categories that users may beinterested in, and that they “pull” from the network.Access points or gateway nodes feed passing cars theinformation they require.To maximize the chance of getting fresh information,we assume that vehicles are capable of cooperating todisseminate the information that was pulled fromgateways, in order to reach farther vehicles by formingan ad hoc network.

Courtesy: Jean Marie Zogg – u-blox and uNAV

INFOSHARE DETAILS

Courtesy: Jean Marie Zogg – u-blox and uNAV

Infoshare

An application which is used to share multiple small pieces of information between vehicles moving along the road.

Infoshare works as follows:� A vehicle which requires some information sends a request

message.� This request message is broadcasted until a vehicle carrying

desired information is found.� The information is sent back following the same return path.� Then the vehicle stores this information for a certain period of

time and then discards it later.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Infoshare Query Message FormatA query message generated by a vehicle has the following information:� Information ID : The identifier of the requested piece of

information, among the N available ones.� Sequence Number : current number of the request performed

by the application. This is incremented at each newly generated query, and it is used by nodes receiving the query message to distinguish among copies of the same query.

� Source Address : The address of the node that generated the query.

� Next Hop Address: the address of the node that sent this query message. when the query is generated first time, this is same as the source address.

� Time to live: field contains the maximum number of hops allowed for the current message.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Infoshare Query Spreading

Query spreading is totally performed through broadcast in a multihop fashion.The query is broadcasted by the source vehicle.The other vehicles that receive the query have a query list.Each query in the query list is described by:� Information ID� Sequence number� Next hop address : This is the address of the node from which

the query was received.� Status : PENDING or SOLVED.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Infoshare Query Spreading

If the application does not have the requestedinformation in its cache and the TTL field in the querymessage is not zero, the vehicle acts as a relay,forwarding the query.Before retransmitting the query, the node replaces thecontent of the next hop address field with its ownaddress.It waits for a flooding.query lag interval of time, prior to checking whether thequery status is still PENDING: thus it limits query

Courtesy: Jean Marie Zogg – u-blox and uNAV

Infoshare Information Retrieval and Transmission

When the query is received by a node which has theinformation, then that node transmits this informationto the next hop indicated in the received query.

The next hop vehicle that receives this informationupdates the status of the query to “solved” and thentransmits it to the next hop and this continues till theinformation reaches the sender.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Simple Scenario to explain Infoshare

Car1 - RedCar2 - GreenCar3 – BlueCar4- PinkAccess points at each road ends - Black

Courtesy: Jean Marie Zogg – u-blox and uNAV

Simple Scenario to explain InfoshareCar3 (Blue) needs some information (ID = k).It broadcasts the query message with Information ID =k and next hop address= addr of car3, source addr =addr of car3.Assume car2 and car 4 are in range of car3. Theyreceive the query from car3. If they don’t have therequested information in cache,� They check the TTL field. If it is not zero, then they act as relays.� It adds this query in the query list (with status pending)� They replace the Next hop addr with their own addr and they

broadcast the query again.( for example in this secnario, car4 replaces next hop addr to addr

of car4 and broadcasts the query again).

Courtesy: Jean Marie Zogg – u-blox and uNAV

Simple Scenario to explain InfoshareThis query from car4 will be received by the gatewaynode.So, it replies with the required information to node4(using the next hop address in the query).Car4 then updates the status of this query to SOLVEDin the query list and forwards this information to Car3(using the next hop address in the query).Car3 which is the source finally receives the requiredinformation.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Problems with Infoshare

The information that is required is returned back to thesource using the same path as explained in theprevious slides ( Using next hop address). But sincethe network formed is adhoc, a node(car) in the pathmay not be present while the information is beingreturned back to the source.

Since it does not use any routing, ( simple broadcastmechanism is used) the network traffic will be veryhigh.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Why InfoGeo ?

To apply a geographical routing protocol such asGeoRoute to a modified version of the Infoshareapplication in order to maximize of informationretrieval, while limiting the flooding of informationqueries.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Greedy Perimeter Stateless Routing Protocol (GPSR)

A position based routing

Courtesy: Jean Marie Zogg – u-blox and uNAV

GPSR

The algorithm consists of two methods for forwarding packets:

� Greedy forwarding, which is used wherever possible, and

� Perimeter forwarding, which is used in the regions greedy

forwarding cannot be.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Greedy Forwarding� Under GPSR, packets are marked by their originator with their

destinations’ locations.

� As a result, a forwarding node can make a locally optimal, greedy choice in choosing a packet’s next hop.

� Specifically, if a node knows its radio neighbors’ positions, the locally optimal choice of next hop is the neighbor geographically closest to the packet’s destination.

� Forwarding in this regime follows successively closer geographic hops, until the destination is reached.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Example

xy

D

x forwards the Packet to y as distance between y and D is less than any of x’s other neighbor. This forwarding repeats until packet reaches D

Courtesy: Jean Marie Zogg – u-blox and uNAV

Greedy forwarding Failure

xy

w

vz

D

x is closer to D than its neighbors w and y. Although there exist two paths (x-y-z-D) and

(x-w-v-D), but x will not choose to forward to w or y using greedy forwarding. x is a local

maximum in its proximity to D.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Need for Perimeter Forwarding

Intersection of x's radio range and the circle about D of radius xD is empty of

neighbors. The shaded region without nodes is called void.

If x seeks to forward a packet to destination D beyond the edge of this void. Intuitively,

x seeks to route around the void, if a path to D exists from x.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Concept behind Perimeter Forwarding

Right hand rule• It traverse the interior of a closed polygon region (a face) in clock

wise edge order

Example: x receives a packet from y forwards it to z

1.

2.

3.

y

x z

Courtesy: Jean Marie Zogg – u-blox and uNAV

Perimeter Forwarding

s t

Forwarding is shown only for exposition of perimeter mode

Courtesy: Jean Marie Zogg – u-blox and uNAV

Combining Greedy & Perimeter Forwarding (GPSR Algorithm)

All packets are forwarded in greedy mode

Forward packet to neighbor closest to Destination

If greedy fails, switch to perimeter mode

• Mark packet with current location

• Forward along successively closer faces by right-hand rule until reaching

Destination or

Reach a node closer to Destination than perimeter mode entry point

• Return to greedy forwarding mode

Traverse face closer to Destination (D) along xD (line joining

forwarding node x and D) by right-hand rule.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Limitation in GPSR

Looping

Moving away from destination (wrong direction), in case of perimeter mode.

Many hops.

Courtesy: Jean Marie Zogg – u-blox and uNAV

State Diagram for GPSR operation

Courtesy: Jean Marie Zogg – u-blox and uNAV

INFOGEO DETAILS

Courtesy: Jean Marie Zogg – u-blox and uNAV

InfoGeo

InfoGeo which is built upon infoshare makes use ofGeoRoute.Consists of two phases:

Phase1: broadcast phase (Similar to InfoShareapplication)Phase2: makes use of GeoRoute routing algorithm.

NOTE:1. It is assumed that every vehicle is equipped with

GPS (To know it’s own coordinates).2. Whenever a vehicle passes through a gateway, it

gets the location of the next nearest gateway.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Georoute

Routing protocol to deliver the information packets to destination “D” with known geographical coordinates (Xd, Yd).A transmitter node should know it’s own coordinates and the coordinates of the destination node as well. (Position aware routing protocol).

Courtesy: Jean Marie Zogg – u-blox and uNAV

Georoute Header

Packet Identifier: local identifier of the packet.Flow ID: Identifier of the flow message in the case where the sender has more than one active message flow.Hop CounterSNC, DNC,CSNC (source, destination, current node coordinates).

Courtesy: Jean Marie Zogg – u-blox and uNAV

Selection of relay nodes

Weighted progression factor G = f(Dp,Dc) where the function G is defined as (Dp-Dc).

Dp-Distance between the previous hop node and the destination.

Dc-Distance between the current hop node and the destination.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Relaying

If the node realizes to be suitable as a relay, i.e., G >0, it stores the following fields, PID, SNC, FID andDNC in a small cache, used to avoid forwarding thesame packet more than once.

Then, the node, after a time interval inverselyproportional to the value of its progress factor,forwards the data packet replacing in the packetheader the coordinates of the current transmitter node(CSNC) with its own coordinates and increases thehop counter (HC) by one.

Courtesy: Jean Marie Zogg – u-blox and uNAV

Scenario to explain GeoRoute

Courtesy: Jean Marie Zogg – u-blox and uNAV

Source – Car BDestination – Car E

Assume Car A and Car C are in the range of Car B.so, the query message from B will be received by A and C.At car A: Dp = 700,

Dc = 1000 (from fig)Therefore G at car A = Dp-Dc = 700-1000 < 0.So, according to Georoute, carA will cancel

relay(will not act as relay node).

Scenario to explain GeoRoute

Courtesy: Jean Marie Zogg – u-blox and uNAV

At car C,Dp = 700Dc = 500 (from fig)G = Dp-Dc = 700-500 = 200 > 0.

Therefore according to Georoute, Car C will act as relay.

Scenario to explain GeoRoute

Courtesy: Jean Marie Zogg – u-blox and uNAV

InfoGeo (phase 1)

� Phase 1 is called broadcast phase.� A node wishing to retrieve an information item generates

a query message and broadcasts the requests to itsneighbors, i.e., the nodes within its coverage range.

� The query broadcast is performed using the samemechanisms specified by the Infoshare application.

� A query list is created at each node and the query statusis first set to PENDING

� The TTL field is set to 1 so that only one hop is allowed.� A new flag, called BROADCAST is introduced, which is

set to 1

Courtesy: Jean Marie Zogg – u-blox and uNAV

If the query reaches a vehicle that owns the desiredinformation, this will immediately send back theinformation.

If no reply is received within a given timeout, the noderequesting the information item enters the secondphase of the InfoGeo scheme.

InfoGeo (phase 1)

Courtesy: Jean Marie Zogg – u-blox and uNAV

InfoGeo (Phase2)The second phase is performed when the Broadcastphase fails, i.e., the timeout timer expires and thequery status at the requesting node is still PENDINGand the corresponding BROADCAST flag is set to 1.

The vehicle generates a new, unicast query, reportingits own coordinates, the address of the nearestgateway along the road as destination address, andthe gateway coordinates.

Courtesy: Jean Marie Zogg – u-blox and uNAV

The query will be routed towards the destinationgateway according to the GeoRoute policy.

When the gateway receives the query, it replies withthe desired information message sent through a(possibly different) unicast path to the vehicle thatgenerated the query.

InfoGeo (Phase2)