


















Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
This project report is part of degree completion in computer science at Ambedkar University, Delhi. Its main points are: Audio, Video, Streaming, MANET, Fourth, Generation, Wireless, Networks, Routing, Protocol
Typology: Study Guides, Projects, Research
1 / 26
This page cannot be seen from the preview
Don't miss anything!
New wireless communication technologies are expected to significantly influence the design and implementation of MANETs. Since the future technology combining wireless local networks and cellular networks is more and more being referred to, and defined as the fourth generation (4G) of communication systems, it is critical to understand the meaning of 4G and its potential in influencing wireless networks, particularly MANET. 4G could be an answer to offer significant solutions for mobile MANETs to achieve high quality transmissions and constant connectivity. The challenge in the design of protocol architectures for MANETs is to efficiently convey information using an unreliable physical channel within a highly dynamic set of mobile, limited- range, limited-energy, half-duplex radios without the support of any infrastructure. An efficient network protocol should jointly optimize the throughput, delay, and energy dissipation of the network without sacrificing fairness, robustness, and Quality of Service (QoS).
Figure 1 High quality transmission & connectivity
A routing protocol specifies how routers communicate with each other to disseminate information that allows them to select routes between any two nodes on a network. Typically, each router has a prior knowledge only of its immediate neighbors. A routing protocol shares this information so that routers have knowledge of the network topology at large.
Figure 2 Ad-hoc & Infrastructural networks
Due to mobility of nodes, the performance of a MANET is dependent upon the capability of the routing protocol to conform to the frequently changing network topology. Moreover, the problem of frequent route switching and low bandwidth links makes routing more challenging in MANETs as compared to other traditional types of networks. The ad hoc protocol should be capable of finding stable routes despite mobility, decreasing routing-related overhead and finding short routes to destinations.
Unicast routing protocols
Unicast routing protocols into many categories based on different criteria, categorization based on route discovery. There are three types of unicast routing protocols: Reactive routing Proactive routing Hybrid routing
Figure 4 Routing Protocols for MANETs
Ad-Hoc Protocols
Table Driven/Proactive On-Demand/Reactive
i / HybridH b id d/
Reactive Routing Protocol:
In reactive routing protocols, a node initiates the route discovery process only when a route to a destination is required. Once a route has been established, it is maintained by a route maintenance procedure until the route is no longer desired. As the routes are calculated only when a request exists, so the initial route discovery time is relatively large but the overall traffic overhead on the network is reduced. The key advantage is increased bandwidth capability and less power consumption by the mobile nodes.
There are many different types of reactive routing protocols available. Some of the examples are Ad hoc On Demand Distance Vector (AODV), Dynamic Source Routing (DSR) etc.
Ad hoc On Demand Distance Vector (AODV)
In AODV, like all reactive protocols, the topology information is only transmitted by nodes on- demand. When a node wishes to transmit traffic to a host to which it has no route, it will generate a Route Request (RREQ) message that will be flooded to other nodes. When a node re- broadcasts a Route Request, it sets up a reverse path pointing towards the source. When the intended destination receives the Route Request, it replies by sending a Route Reply (RREP) and does not forward the RREQ message to other nodes as it is the intended target of the RREQ.
If a route exists, the router simply forwards the message to the next hop. Otherwise, it saves the message in a message queue, and then it initiates a Route Request to determine a route. The flow chart in Figure 2.2 illustrates this process:
Figure 6 Route discovery in AODV
Proactive Routing Protocol
By broadcasting control packets containing routing table information (e.g. distance vectors), proactive routing protocols endeavor to maintain up-to-date routing information from each node to every other node. The table update may be,
Event-driven: only if a change is recognized Periodically
To maintain up-to-date routing information, topology information needs to be exchanged between nodes on a regular basis, leading to relatively high overhead on the network. On the other hand, routes to any destination in the network will be readily available on request at the cost of elevated power consumption by the nodes.
Examples of proactive routing protocols are Optimized Link State Routing (OLSR), Destination Sequenced Distance Vector (DSDV) etc.
Optimized Link State Routing (OLSR)
OLSR is a table-driven pro-active protocol. In a classic link-state algorithm, link-state information is flooded throughout the network. OLSR uses this approach as well, but since the protocol runs in wireless multi-hop scenarios the message flooding in OLSR is optimized to preserve bandwidth. The optimization is based on a technique called Multi Point Relaying in which only selected nodes forward the control messages.
Multipoint relays (MPR) of a node A are its neighbors such that every two-hop neighbor of A is a one-hop neighbor of one multipoint relay of A. Nodes exchange neighbor lists to know their 2- hop neighbors and choose the multipoint relays. The data in routing tables is maintained based on received control traffic. The route calculation itself is also driven by the routing tables.
Figure 7 MPR functionality
Multicast routing protocols
In multicasting, one or more source nodes convey information to the members of a multicast group, possibly through the use of non-multicast group member nodes within the network.
Multicast routing of voice traffic within a mobile ad hoc network has many applications, especially in military communications.
There are two types of multicast routing approaches:
Tree-based approach Mesh-based approach
Tree-based approach
Tree-based approaches create trees originating at the source and terminating at multicast group members with an objective of minimizing a cost function. For example, shortest path tree algorithms create trees originating at the source with an objective of minimizing the distance between the source and every destination in the multicast group individually. Minimum cost tree algorithms minimize the cost function associated with the global multicast tree as a whole to create multicast trees.
A multicast protocol for ad hoc wireless networks (AMRIS)
A multicast protocol for ad hoc wireless networks (AMRIS) constructs a shared delivery tree rooted at one of the nodes with IDs increasing as they radiate from the source. Local route recovery is made possible due to this property of IDs, hence reducing the route discovery time and also confining route recovery overhead to the proximity of the link failure.
Figure 9 AMRIS protocol
NACK (negative acknowledgment) Oriented Reliable Multicast (NORM) The NORM protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgement (NACK) mechanism for transport reliability and offers additional protocol mechanisms to conduct reliable multicast sessions with limited "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) from the senders to receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways.
Figure 11 NORM protocol
Broadcast routing protocols
Real-time data broadcasting is an important service in mobile ad hoc networks. In many applications, real-time data need to be broadcast throughout the entire network in a multi-hop fashion. There are three main categories of broadcast routing: fully coordinated non-coordinated partially coordinated
set tracefd [open simple.tr w]
set windowVsTime2 [open win5.tr w]
set namtrace [open simwrls.nam w]
$ns trace-all $tracefd
$ns namtrace-all-wireless $namtrace $val(x) $val(y)
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)
create-god $val(nn)
$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac)
-ifqType $val(ifq)
-ifqLen $val(ifqlen)
-antType $val(ant)
-propType $val(prop)
-phyType $val(netif)
-channelType $val(chan)
-topoInstance $topo
-angentTrace ON
-routerTrace ON
-macTrace ON
-movementTrace ON
for {set i 0} {$i < $val(nn)} { incr i } { set node_($i) [$ns node]}
$node_(0) set X_ 100.
$node_(0) set Y_ 50.
$node_(0) set Z_ 0.
$node_(1) set X_ 200.
$ns at 110.0 "$node_(4) setdest 120.0 170.0 5.0"
$ns at 10.0 "$node_(3) setdest 100.0 160.0 5.0"
set tcp [new Agent/TCP/Newreno]
$tcp set class_ 2
$tcp set window_ 3
Agent/TCPSink/DelAck set interval_ 150ms
set sink [new Agent/TCPSink/DelAck]
$ns attach-agent $node_(0) $tcp
$ns attach-agent $node_(1) $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 1.0 "$ftp start"
set tcp [new Agent/TCP/Newreno]
$tcp set class_ 2
$tcp set window_ 3
Agent/TCPSink/DelAck set interval_ 150ms
set sink [new Agent/TCPSink/DelAck]
$ns attach-agent $node_(2) $tcp
$ns attach-agent $node_(4) $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 1.0 "$ftp start"
set tcp [new Agent/TCP/Newreno]
$tcp set class_ 2
$tcp set window_ 3
Agent/TCPSink/DelAck set interval_ 150ms
set sink [new Agent/TCPSink/DelAck]
$ns attach-agent $node_(3) $tcp
$ns attach-agent $node_(0) $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 1.0 "$ftp start"