routing for vehicle based dtn

8/3/2019 Routing for Vehicle Based DTN

1/5

ROUTING FOR VEHICLE BASED DISRUPTION TOLERANT

NETWORK

Pritam P. Kapse

Department of Computer Engineering

BDCE, SevagramWardha.

[email protected]

ABSTRACT

Disruption-tolerant networks (DTNs)

attempt to route network messages via

intermittently connected nodes. Routing in

such environments is difficult because peers

have little information about the state of the partitioned network and transfer opportunities

between peers are of limited duration.Moreover, it is not possible to find an end to end

path from source to a destination at any given

time instance. Therefore, routing of message in

DTNs is more challenging than in traditional

networks where the connectivity of nodes is

mostly stable and most of the time paths fromsource to destination do not change throughout

the message delivery.DTNs are effectively utilized in various

environments subject to disruption,

disconnection and long delay. It can be applied

to wireless sensor networks using intermittent

connectivity terrestrial wireless network with no-

end to end connectivity, satellite, under water

with long delay or periodic connectivity

underwater acoustic network with frequentinterruption and other commercial application

that allows long delay and intermittent

connectivity.

Vehicle-based routing is improve the intelligent

inter vehicle to vehicle communication without

any fixed infrastructure.

Key Words: DTN, end-to-end connectivity,Routing Protocol, Access Point.

1. INTRODUCTIONDisruption tolerant networks (DTNs) allow forrouting in networks where contemporaneousend-to-end paths are unstable or unlikely.

Unstable paths can be the result of several

challenges at the link layer, for example: high

node mobility, low node density, and short radio

range; intermittent power from energy

management schemes; environmental

interference and obstruction; and denial-of-

Swati S. Muley

Department of Computer Engineering

BDCE, SevagramWardha

[email protected]

service attacks. Such environments can exist in

undeveloped areas or when a stable infrastructure

is destroyed by natural disaster or military

efforts. DTNs are useful when the information

being routed retains its value longer than thedisrupted connectivity delays delivery.

Vehicles can provide substantial

electrical supplies and transport bulky hardware,

which may be inappropriate for use by non-

mechanized peers. A vehicle- based network isthat the nodes move more quickly, reducing the

amount of time they are in radio range of

one another. Accordingly, one limitedresource in a vehicle-based DTN is the

duration of time that nodes are able to

transfer data between one another as they

pass.

In vehicle based network almost all

nodes are vehicle. This makes available more

storage and power on each node, thus wider

transmission ranges and lager lifetime are

possible.

Figure a: Vehicle-based for routing in DTNs.

Figure (a) shows that vehicle-based for

routing in DTNs. Here user S sending themessage to destination D, this message first goes

to vehicle node. This node is transferred same

message to city A in radio range. City A send the

message to the internet, internet sends the

message to all nodes present in range. Then city

B send to original destination of the message i.e.
mailto:[email protected]:[email protected]


2/5

user D.

2 Literature Survey:

2. 1 Switch Based Architecture of

Vehicle Network:

Here introduce a switch-based

architecture for in-vehicle networks. The existing

in-vehicle network systems are diverse and

correspond to different protocols. However, they

typically share a common characteristic, i.e., bus-

based topology. Most of existing networks adopt

bus topology, implying a broadcast mode form

message transmission. In a bus-based in-vehiclenetwork, nodes are usually called Electronic

Control Units (ECUs). An ECU is composed of

both hardware and software. Usually, ECUs are

directly connected to sensors and actuators.

According to their different functions, ECUssend or receive different types of messages. In

early generations of in-vehicle networks, only

ECUs on the same bus communicate to eachother. However, with increasing demand for

onboard automotive electronic systems, sub-

systems may adopt different in-vehicle networks

and information needs to be exchanged among

them.

Figure b: Architecture of switch based in

vehicle network.

Figure (b) shows the architecture of

switch based in vehicle network. There are anumber of sub-networks, such as CAN, Flex

Ray, TTP/C or other bus-based sub-networks.

Sub-networks are then connected by a switch-

based backbone. This backbone relays messages

among these subnet work sand performs format

conversion if necessary.

2.2 Design of Switch:

Figure c: Workflow of a switch

Figure (c) presents the main workflow

of a switch, which includes message receiving

and buffering, routing table lookup,

protocol/format conversion1, and message relay.

Based on this workflow model, a switch consists

of the following major components:

2.2.1 Computing Resources:

Computing resources include basic

hardware such as processors, memories, storage,etc. These resources must meet the constraints on

cost, reliability, and real time.

2.2.2 Network Interface Controllers:

For different sub networks, the switches

need to use different types of network interface

controllers such as CAN controller or Flex Ray

controllers. The ports of a switch are interfacesto sub networks or other switches. Messages are

received from some ports and are relayed to

others. Usually, a port contains two message

buffers, i.e. a memory space of the FIFO for

incoming and outgoing messages.

2.2.3 Routing Table:

Different from the routing tables inInternet routers, routing schemes that use static

routing tables, which means that routing

information will not be changed at runtime and is

stored in solid memories, such as EPROM.

3 WORKING:

3.1Configuration of a Vehicle Peer:

Each vehicle node has a HaCom

Open Brick computer. This computer contains

P6- compatible 577 MHz CPU, 256MB RAM.

An 802.11b Access Point (AP) is attached toeach brick to provide access to passengers and

passersby. A second USB-based 802.11b

interface constantly scans the surrounding

area for other vehicle nodes. Each node also

has a GPS device attached to the brick. Each

brick runs Linux on a 40GB notebook hard drive.

They are installed behind the electric sign. Toenable vehicle-to-vehicle transfers, vehicle


3/5

beacon on a single channel once every 100ms.

Here programmed the bricks to transfer the

largest amount of data possible using TCP at

each transfer opportunity. Here installed two

Access points (APs), one for campus and one atthe vehicle garage. Whenever the vehicles have

web access, they retrieve software updates froma central server. At that time a vehicle provides

its current GPS location and MAC address, and it

uploads logs of its performance during the day,

including the throughput of bus-to-bus transfer

opportunities, APs contacted a record of

movement, and application records [1].

where N1 and N2 intermittent vehicles nodes.

S Source

D Destination

Dotted Line - Forwarding the Data

Figure d: Route traveled by the vehicle node.

3.2 Algorithm for vehicle bases

routing:

Route discovery and route delay in

RBVR at node ni.

Notation:

nS, nD: Identity of the source anddestination

Path, TempPath: The best and

temporary paths from nS to nD

|Path|: Path length

RS (ni): Road segment where node ni is

located

w: Waiting time parameter

RD: Route discovery packetRR: Route reply packet

Upon receiving RD (nS, nD, TempPath) from nj

1: if(ni == nD) & (|TempPath| < |Path|) then

2: Path = TempPath

3: Send RR (nD, nS, Path)

4: Return

5: end if

6: ifRD not seen before then

7: if (RS(ni) 6= RS(nj))&(RS(ni) /2

TempPath) then

8: Add RS(ni) to TempPath

9: end if

10: Set timer = w * distance (nj , ni)11: else

12:if

RS (ni) == RS (nj)then

13: Cancel timer /* nj is a better

broadcast node */

14: end if

15: end if

Upon timeout

16: Broadcast RD (nS, nD, TempPath)Upon receiving RR (nD, nS, Path) from nj :

17: ifni = = nS then

18: Store Path

19: Forward Data (Path)

20: else

21: Forward RR (nD, nS, Path)

22: end if

3.2.1 Route Discovery:

When a source node needs to send

information to a destination node, RBVT

initiates a route discovery process, is shown in

Fig. d.

Figure e: Route Establishment inRBVT

The source creates a route discovery

(RD) packet, whose header includes the address

and location of the source, the address of the

destination, and a sequence number. There have

unique addresses for nodes. RD is flooded in the

region around the source to discover a route

toward the destination. The flooding is necessary


4/5

because RBVT does not assume a location

service that can be queried to find out the

location of the destination. For scalability

reasons, the flooding region is limited by a Time

to live value set in the header. To reduce theeffects of the broadcast storm problem [7],

RBVT uses an improved flooding mechanismsimilar to [8]. If a node receives an RD packet

with the same source address and sequence

number with a previously received packet, it

discards it. When a node receives a new RD, it

does not directly rebroadcast this packet; the

node holds the packet for a period of timeinversely proportional to the distance between

itself and the sending node. Once the waiting

period is over, a node re-broadcasts the RD

packet only if it did not notice that this packet

was re-broadcasted by farther-away nodes

located on the same road segment. In this way,

farther away nodes can rebroadcast the request

first, thus ensuring faster progress and less trafficin the network. In RBVT, the route is built

gradually. Initially, the route stored in the RDpacket is an empty list. When a vehicle node

receives the RD packet for the first time, it

checks if it is located on a different road segment

from the transmitter of the packet. If so, the

receiving node appends to the route list the road

intersections that were traversed by the RD

packet from the transmitter position [4].

3.3.2 Route Reply:

Upon receiving the RD packet, the

destination node creates a route reply (RR)packet for the source. The route recorded in the

RD header is copied in RR header. Is shown in

Fig. e.

Figure e: route reply in RBVT

This route defines a connected path,

composed of road intersections, from source to

destination. The destination also adds its current

position in the RR header. The RR packet is

forwarded along the road segments defined bythe intersections stored in its header.

Geographical forwarding is used betweenintersections to take advantage of every available

node on the path. The destination may receive

duplicates of an RD packet. A new reply is

generated only if the newly received packet

contains a better quality route. In the current

implementation, the fewer the number ofintersections, the better the route. Upon receiving

the RR packet, the source starts sending data.

Each data packet stores the route in its header

and it is geographically forwarded along this

route. Protocol 1 presents the pseudo-code for

the route discovery and route reply phases.

4 Comparisons with previous

Protocol:

4.1 Table-driven routing protocol:

Table driven routing protocols attempt

to maintain consistent, up-to-date routing

information by broadcasting transmission that

requires each node to maintain one or more

tables to store routing information. Once thereare changes in network topology, propagating

update information throughout the whole

network has to be performed in order to maintain

a consistent network view. For instance, the

Destination Sequenced Distance Vector Routing

protocol (DSDV) described is a famous table-

driven algorithm based on the classical Bellman-

Ford routing mechanism. The Cluster-headGateway Switch Routing (CGSR) protocol

defines several heuristic routing schemes in aclustered multi-hop mobile wireless network.

The Wireless Routing Protocol (WRP) is another

table-based protocol with the goal of keeping

routing information consistent among all nodes

in the network. Each node in the network is

responsible for maintaining four tables: distance

table, routing table link-cost table, messageretransmission list (MRL) table. Optimized LinkState Routing Protocol (OLSR) is also a kind of

proactive protocol [5].

5.0 Merits of vehicle based routing:

Each node contains one GPS, to get its


5/5

own geographic position like speed,

movement direction, position.

The mobility of vehicle, roads are

mapped and digitally available anddriving rules can be electronically

represented.

Improving the passengers comfort levelthrough optimized route to destination

like traffic information, weather

information, petrol station.

6.0 Demerits of vehicle based routing:

Vehicle based network node move more

quickly, reducing the amount of time

they are in radio range of one another.

Vehicle based routing create the

problem with the pickup the data and

delivery.

7 Conclusions:

In this paper, we study how routing for

vehicle based in DTNs is useful for routing the

message. The goal of routing for vehicle based is

to maximize the message delivery. It has the

main characteristic of the high moving speed inthe networks. Because moving of the vehicle

node is increases the connection between the

other nodes and give the fast message delivery to

the destination.

8 Future Works:

In future to a developed a technique to

solve the problem of vehicle based network is

that the node move more quickly, reducing the

time are in the radio range of one another.

9 References:

[1] J. Burgess, B. Gallagher, D Jensen, and B. N.

Levine. MaxProp Routing for

Vehicle-Based Disruption-Tolerant Networks.

In proc .IEEE Infocom, pages 454-465 April

2006.

[2] A. Vahdat and D. Becker. Epidemic

Routing for Partially-Connected Ad Hoc

Networks. Technical Report CS-2000-06, DukeUniversity, July 2000

[3] B. Burns, O. Brock, and B.N. Levine. MV

routing and capacity building in Disruption

Tolerant networks. In Proc. IEEE INFOCOM,

pages 398- 408, March 2005.

[4] J. Nzouonta, N. Rajgure, G. Wang. VANET

routing on city roads using real time vehicular

traffic information. In IEEE Infocom, April

2005.

[5] L.Khan, N. Ayub and A.Saeed. Anucat based routing in vehicular Adhoc networks

(VANETS) using Vanetmobisim. In worldapplied sciences journal 7. page. no. 1341-1352,

august 2009.

[6] W. Zhao, M. Ammar, and E. Zegura.

Controlling the mobility of multiple data

transport ferries in a delay-tolerant network. In

IEEE INFOCOM, page no.567-578, July 2005.[7] J. Fonseca, E. Martins, L. Almeida, P.

Pedreiras, and P. Neves, Flexible Time-

Triggered Protocol for CAN New Scheduling

and Dispatching Solutions, in Proceedings of

7th International CAN Conference, Oct. 2000.

[8] P. F. Hokayem and C. T. Abdallah, Inherent

Issues in Networked Control Systems: A

Survey, in Proceedings of 2004 AmericanControl Conference, pp. 4897-4902, 2004.

routing for vehicle based dtn

Documents