ROUTING FOR VEHICLE BASED DISRUPTION TOLERANT NETWORK

Pritam P. Kapse Department of Computer Engineering BDCE, Sevagram Wardha. [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 from source 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 noend to end connectivity, satellite, under water with long delay or periodic connectivity underwater acoustic network with frequent interruption 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.

Swati S. Muley Department of Computer Engineering BDCE, Sevagram Wardha [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 the disrupted connectivity delays delivery. Vehicles can provide substantial electrical supplies and transport bulky hardware, which may be inappropriate for use by nonmechanized peers. A vehicle- based network is that the nodes move more quickly, reducing the amount of time they are in radio range of one another. Accordingly, one limited resource 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.

1. INTRODUCTION
Disruption tolerant networks (DTNs) allow for routing in networks where contemporaneous end-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-

Figure a: Vehicle-based for routing in DTNs. Figure (a) shows that vehicle-based for routing in DTNs. Here user S sending the message 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.

user D.

2.2 Design of Switch:

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., busbased topology. Most of existing networks adopt bus topology, implying a broadcast mode form message transmission. In a bus-based in-vehicle network, 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, ECUs send or receive different types of messages. In early generations of in-vehicle networks, only ECUs on the same bus communicate to each other. However, with increasing demand for onboard automotive electronic systems, subsystems may adopt different in-vehicle networks and information needs to be exchanged among them. 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 interfaces to 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 in Internet 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:
Figure b: Architecture of switch based in vehicle network. Figure (b) shows the architecture of switch based in vehicle network. There are a number of sub-networks, such as CAN, Flex Ray, TTP/C or other bus-based sub-networks. Sub-networks are then connected by a switchbased backbone. This backbone relays messages among these subnet work sand performs format conversion if necessary. 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 to each 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. To enable vehicle-to-vehicle transfers, vehicle

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 at the vehicle garage. Whenever the vehicles have web access, they retrieve software updates from a 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].

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: if ni = = 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: where N1 and N2 intermittent vehicles nodes. S Source D Destination Dotted Line - Forwarding the Data Figure d: Route traveled by the vehicle node. When a source node needs to send information to a destination node, RBVT initiates a route discovery process, is shown in Fig. d.

3.2 Algorithm routing:

for

vehicle

bases

Route discovery and route delay in RBVR at node ni. Notation: nS, nD: Identity of the source and destination 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 packet RR: 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: if RD not seen before then

Figure e: Route Establishment in RBVT 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

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 the effects of the broadcast storm problem [7], RBVT uses an improved flooding mechanism similar 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 time inversely 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 traffic in the network. In RBVT, the route is built gradually. Initially, the route stored in the RD packet 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.

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 by the intersections stored in its header. Geographical forwarding is used between intersections 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 of intersections, 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 there are 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 tabledriven algorithm based on the classical BellmanFord routing mechanism. The Cluster-head Gateway Switch Routing (CGSR) protocol defines several heuristic routing schemes in a clustered 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, message retransmission list (MRL) table. Optimized Link State Routing Protocol (OLSR) is also a kind of proactive protocol [5].

5.0 Merits of vehicle based routing:

Figure e: route reply in RBVT Each node contains one GPS, to get its

own geographic position like speed, movement direction, position. The mobility of vehicle, roads are mapped and digitally available and driving rules can be electronically represented. Improving the passengers comfort level through 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 in the networks. Because moving of the vehicle node is increases the connection between the other nodes and give the fast message delivery to the destination.

[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 world applied 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 TimeTriggered 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 American Control Conference, pp. 4897-4902, 2004.

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, Duke University, 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.