You are on page 1of 103

Adhoc and Sensor Networks

Year :2012-2013
IV Year B.Tech (CSE) II Sem
Unit-III PPT Slides

Text Books:
1. Ad Hoc and Sensor Networks Theory and Applications, Carlos Corderio
Dharma P.Aggarwal, World Scientific Publications, March 2006, ISBN 981
- 256-681-3
2. Wireless Sensor Networks: An Information Processing Approach, Feng
Zhao, Leonidas Guibas, Elsevier Science, ISBN 978-1-55860-914-3
( Morgan Kauffman)

Table of Contents

Introduction
The Broadcast Storm
Broadcasting in a MANET
Flooding-Generated Broadcast Storm
Redundancy Analysis
Rebroadcasting Schemes
Multicasting
Issues in Providing Multicast in a MANET
Multicast Routing Protocols
Comparison
Geocasting
Geocast Routing Protocols
Comparison
Conclusion and Future Directions

Routing Protocols
Topology-Based:
Depends on the information about existing links
Position-Based Approaches
Proactive (or table-driven)
Proactive (Table-driven) protocols
Traditional distributed shortest-path protocols
Maintain routes between every host pair at all
times
Based on periodic updates; High routing
overhead
Example: DSDV (destination sequenced distance
vector)
Reactive (On-Demand) protocols

Determine route if and when needed


Source initiates route discovery
Example: DSR (dynamic source routing)
Hybrid protocols
Adaptive: Combination of proactive and reactive
Example: ZRP (zone routing protocol)

Routing Approaches
Broadcasting
Is a common operation in many applications, e.g., graph-related and
distributed computing problems
It is also widely used to resolve many network layer problems
Multicasting
Transmission of datagrams to a group of hosts identified by a single
destination address
Hence is intended for group-oriented computing
Can efficiently support a variety of applications that are characterized
by close collaborative efforts
Geocasting
Aims at delivering data packets to a group of nodes located in a
specified geographical area
Can be seen as a variant of the conventional multicasting problem, and
distinguishes itself by specifying hosts as group members within a
specified geographical region
Since all these three do communication to a group of recipients, it is
imperative to determine what is the best way to provide these services in
an ad hoc (MANET) environment
Comparison of broadcast, multicast and geocast protocols for ad hoc
networks provided

The Broadcast Storm


MANET consists of a set of MHs that may communicate
with one another from time to time
No base stations are present
Each host is equipped with a CSMA/CA
Transmission of a message to all other MHs required
The broadcast is spontaneous
Due to MH mobility and lack of synchronization, any
kind of global topology knowledge is prohibitive
Little or no local information may be collected in
advance
The broadcast is frequently unreliable
Acknowledgement mechanism is rarely used
Distribute a broadcast message to as many MHs as
possible without putting too much effort
A MH may miss a broadcast message because it is offline, it is temporarily isolated from the network, or it
experiences repetitive collisions

The Broadcast Storm


Broadcast
Acknowledgements may cause serious medium contention
In many applications 100% reliable broadcast is
unnecessary
MH can detect duplicate broadcast messages
If flooding is used blindly, many redundant messages will be
sent and serious contention/collision will be incurred
Redundant rebroadcasts
When a MH decides to rebroadcast, all its neighbors may
already have the message
Contention
Transmissions from neighbors may severely contend with
each other
Collision
Due to absence of collision detection, collisions are more
likely to occur and cause more damage

Example (simple
flooding)
Source node
Rebroadcast node

Better Solution: Only


4 Rebroadcast nodes

3
3

5
1

9
8

1st step: S
2nd step: 1, 5, 6, 9
3rd step: 2, 3, 7, 8
4th step: 4
Total: 9 Rebroadcast nodes

9
8

Example broadcast
storm problem in a 13
4
Enode MANET
J
3
G
2
I and J

Average degree 2.6

1 2
2

1
1

D and E
contend at
step 2

A and D collide
at C at step 2

4
C

A
2

2
3

collide at M
at step 4

H and K contend
at step 5

Message still
propagates ..

Redundancy Analysis
S
1
S

1
2

2
2

2
D
D

Optimal Broadcast in MANETs

Randomly deployed MANET


Redundancy Analysis

Assume that the total area


covered by the radio signal
transmitted by a transceiver is a
circle of radius r
Intersection area of two circles of
radio r whose centers are d apart
be INTC(d)
Additional coverage provided by a
host to who rebroadcasts the
packet is equal to r2 INTC(d)
When d = r, the additional
coverage is approximately 0.61r2
(maximum)
Average additional coverage by
rebroadcasting from randomly
located host is 0.41r2
Expected additional coverage
provided by a hosts rebroadcast
after the same broadcast packet
received by host k times is denoted
by EAC(k)

r
r

Rebroadcasting Schemes
Minimize number of retransmissions of a broadcast
message
Attempt to deliver a broadcast packet to each and
every node in the network
Common Attributes of Broadcast Protocols
Jitter and Random Delay Timer (RDT)

Jitter allows one neighbor to acquire the channel first while


other neighbors detect that the channel is busy
RDT allows a node to keep track of redundant packets
received over a short time interval

Loop Prevention

Node rebroadcasts a given packet no more than one time by


caching original source node ID of the packet and the packet
ID

Categories of
Broadcasting Protocols
Simple flooding

A source node broadcasting a packet to all neighbors


The neighbors, upon receiving the broadcast packet,
rebroadcast the packet exactly once

Probability-based methods

Similar to ordinary flooding


Nodes only rebroadcast with a predetermined probability
In dense networks, multiple nodes share similar
transmission coverage
Counter-Based Scheme: relationship between number of
times a packet is received and the probability of a nodes
transmission to cover additional area on a rebroadcast

Area-based methods
Neighbor knowledge methods

Categories of
Broadcasting Protocols
Area-based methods
If a sender is located only one meter away, the additional area covered
by the retransmission by a receiving node rebroadcasts is quite low
Distance-based scheme compares the distance between itself and each
of its neighbor nodes that has previously rebroadcast a given packet
Location-based scheme uses a more precise estimation of expected
additional coverage area
Neighbor knowledge methods
Flooding with Self Pruning requires each node to have knowledge of
its one-hop neighbors
Scalable Broadcast Algorithm (SBA) requires that all nodes have
knowledge of their neighbors within a two-hop radius
Each node searches its neighbor tables for the maximum neighbor
degree of any neighbor node, say, dNmax
Calculates a Random Time Delay (RDT)
based on the ratio of
where dme is the number of current
neighbors for the node

d N max
d me

Categories of
Broadcasting Protocols
Neighbor knowledge methods..
Dominant Pruning: Uses two-hop neighbor knowledge, but
proactively choosing some or all of its one-hop neighbors as
rebroadcasting nodes
Multipoint Relaying: Similar to Dominant Pruning, but
rebroadcasting nodes, [Multipoint Relays (MPRs)] are explicitly
chosen by upstream senders

Algorithm for a node to choose its MPRs


1. Find all two-hop neighbors that can only be reached by one onehop neighbor and assign those one-hop neighbors as MPRs
2. Determine the resultant cover set (i.e., the set of two-hop
neighbors that will receive the packet from the current MPR set)
3. From the remaining one-hop neighbors not yet in the MPR set,
find the one that would cover the most two-hop neighbors not in
the cover set
4. Repeat from step 2 until all two-hop neighbors are covered

Categories of
Broadcasting
Protocols
Ad Hoc Broadcast
Protocol (AHBP)

Approach similar to Multipoint Relaying by designating nodes as a


Broadcast Relay Gateway (BRG)
AHBP differs from Multipoint Relaying in three ways:

1. A node using AHBP informs one-hop neighbors of the BRG


designation by a field in the header of each broadcast packet
as opposed to done by hello packets in Multipoint Relaying
2. In AHBP, when a node receives a broadcast packet listed as a
BRG, it uses two-hop neighbor knowledge to find which
neighbors
alsoSet-Based
received Broadcast
the broadcast
packet in the same
Connected
Dominating
Algorithm
A dominating
set for a graph
a set
vertices whose
neighbors,
along with themselves,
transmission
soisas
toofremove
from
the neighbor
graphconstitute
all the vertices in the graph
A3.
connected
dominating
set of minimum
size in a graph
vertices in thenetworks
dominating set to
AHBP
is extended
to account
forincludes
high mobility

be connected as well

Considers the set of higher priority BRGs selected by the previous sender

Dominated Set

If you allow all


members of
dominating set to
retransmit,
all MHs in the
network are
guaranteed to be
covered
The black vertices are the
member of Dominating Set

Connected Dominating
Set
A connected dominating set (CDS) of
A dominating set of a graph
G= (V, E) is a vertex subset
SV , such that every
vertex vV is either in S or
adjacent to a vertex of S

a graph G is a dominating set whose


induced graph is connected (this
enables any member to be within
communication range of another
member to enable broadcast)

Broadcast Nodes in
Large Networks?
Some nodes are highly

connected than others


Similarily, some nodes
are sparsely connected
than others
Some nodes are in
between
Dominating Set?
Complexity?
Global connectivity
knowledge?
Local knowledge: 2-hop
neighbors?
Some nodes highly
connected than other
neighbors?
Some nodes sparsely
connected than other
neighbors?
Quantify nodes based on
connectivity?

Categories of
Broadcasting Protocols
Connected Dominating Set-Based Broadcast Algorithm MHs into four groups based on local information as follows:
Group 1: Nodes with degrees larger than the degree of all
neighboring nodes, where connectivity represents the
number of neighbors within the directed transmitting
range of a reference node
Group 2: Nodes have a majority of neighbors with
smaller degree than the reference nodes
Group 3: Remaining nodes not belonging to groups 1, 2
and 4
Group 4: Nodes with degrees smaller than all the
neighbors
A message forwarder is assigned in a decreasing
probability order as p1, p2, p3 and p4

Connected Dominating
Set-Based Broadcast
If A be the area of theAlgorithm
MANET
N be the number of mobile nodes

r be the communication range of each mobile node with a


being the fraction of the area covered

r 2 and being the fraction


of area covered, then

A
The average number of neighboring nodes Nneighbors can be
given by
N
( N 1)
neighbors

The probability pi that a mobile node has i neighbors, can be


N 1
given by
1 N 1i i
pi
i

The probabilityi p1, p2, pN31,iand p4 can be given by

N 1

P1 pi
i
i 1

N 1

N 1

P3
i 1

i
k i / 2 k

i 1

i 1

1 p j

j 1
j 1

k
i k
N 1
i 1
p j p j


j i
j 1

N 1


k 1 k

P2 pi

i 1

N 1

P4 pi
i 1
i

N 1

j i
i

N 1

j i 1

N 1

i/2




N 1

i k

i 1

p
j 1

1 p j

j i 1

N 1i

Forwarding Probability

Group Forwarding
Probabilities for N=100
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0

P1
P2
P3
P4

0.2

0.4

0.6

0.8

: Fraction of area A covered by each node

1.2

Connected Dominating SetBased Broadcast Algorithm

Total number of forwarding steps, NF :

N F N 1 P1 2 P2 3 P3 4 P4
where i is the forwarding probability for the mobile node in group

Such a scheme does not provide 100% coverage of all MANET


nodes

A good coverage and excellent saving are achieved under mobility


and about 20% higher goodput is obtained than the conventional
AODV

Lightweight and Efficient Network-Wide Broadcast: Relies on twohop neighbor knowledge obtained from hello packets; however
instead of a node explicitly choosing other nodes to rebroadcast, the
decision is implicit

Lightweight and
Efficient Network Relies on two-hop
Wide
Broadcast
neighbor
knowledge obtained from

hello packets
Each node decides to rebroadcast based on
knowledge of which of its other one and two-hop
neighbors are expected to rebroadcast
Knowledge of which neighbors have received a packet
from the same source node, and which neighbors
have a higher priority for rebroadcasting
The priority is proportional to the number of
neighbors of a given node
The higher a nodes degree is, the higher is its priority

Multicasting v/s
Broadcastng?

Multicasting
Routing protocols offering efficient multicasting in wired
networks may fail to keep up with node movements and
frequent topological changes
Broadcast protocols cannot be used either as multicasting
requires a selected set of nodes to receive the message
All multicast algorithm depend on the topology of the
network
Majority of applications requiring rapid deployment and
dynamic reconfiguration, need multicasting such as
military battlefields, emergency search and rescue sites,
classrooms, and conventions
Crucial to reduce the transmission overhead and power
consumption
Multicasting in a MANET faces challenges such as
dynamic group membership and update of delivery path
due to MH movement

Multicast Routing
Protocols
Broadcast protocols cannot be used as
multicasting requires a selected set of MHs
to receive the message
Protocols are classified into four categories
based on how route to the members of the
group is created:
Tree-Based Approaches
Meshed-Based Approaches
Stateless Multicast
Hybrid Approaches

Illustration of TreeBased Multicast

Nodes not a part


of Multicast
group

Source
0
1

2
1

2
2
3

3
3

Tree-Based
Approaches
Extend tree-based
approach to provide multicast in a

MANET
A packet traverses each hop and node in a tree at most once
Very simple routing decisions at each node
Tree structure built representing shortest paths amongst
nodes, and a loop-free data distribution structure
Even a link failure could mean reconfiguration of entire tree
structure, could be a major drawback
Consider either a shared tree or establish a separate tree per
each source

For separate source trees, each router in multiple router groups


must maintain a list of pertinent information for each group
and such management per router is inefficient and not scalable
For shared trees, there is a potential that packets may not only
not traverse shorter paths, but routed on paths with much
longer distances

Tree-Based
Ad hoc Multicast Routing Protocol Utilizing Increasing Id-Numbers
Approaches

Utilizing Increasing id-numberS (AMRIS) is an on-demand protocol, which


constructs a shared multicast delivery tree to support multiple senders and
receivers in a multicast session
AMRIS dynamically assigns an id-number to each node in each multicast
session and a multicast delivery tree rooted at a special node with Sid
(Smallest-ID and is usually a source that initiates a multicast session) is
created and the id-number increases as the tree expands from the Sid
In case of multiple senders, a Sid is selected among the given set of senders
Once a Sid is identified, it sends a NEW-SESSION message to its neighbors
This message includes Sids msm-id (multicast session member id) and the
routing metrics
Nodes receiving the NEW-SESSION message generate their own msm-ids,
which is larger than the msm-id of the sender
In case a node receives multiple NEW-SESSION messages from different
nodes, it keeps the message with the best routing metrics and calculates its
msm-ids
To join an ongoing session, a node checks the NEW-SESSION message,
determines a parent with smallest msm-ids, and unicast a JOIN-REQ to its
potential parent node
If parent node is already in the multicast delivery tree, it replies with a
JOIN-ACK.
If a node is unable to find any potential parent node, it executes a branch
reconstruction (BR) process to rejoin the tree

Tree-Based Approaches

Ad hoc Multicast Routing Protocol Utilizing Increasing Id-Numbers


(AMRIS)
Packet forwarding example

Nodes X and 34 are sources


Nodes 11, 24, and 28 are recipients

Route Discovery and Join


for Multicast
Multicast Ad hoc On-Demand Distance Vector Protocol

Follows directly from the unicast AODV


Discovers multicast routes on-demand using a broadcast route
discovery mechanism employing the same Route Request (RREQ)
and Route Reply (RREP) messages
A MH originates a RREQ message when it wishes to join a
multicast group, or when it has data to send to a multicast group
but it does not have a route to that group
Only a member of the desired multicast group may respond to a
join RREQ
If the RREQ is not a join request, any node with a fresh enough
route to the multicast group may respond
As the RREQ is broadcasted across the network, nodes set up
pointers to establish the reverse route in their route tables
A node receiving a RREQ first, updates its route table to record the
sequence number
For join RREQs, an additional entry is added to the multicast route
table and is not activated unless the route is selected to be a part of
the multicast tree

Multicast AODV
Multicast Ad hoc On-Demand Distance Vector
Protocol
Follows directly from the unicast AODV

Multicast
Member

Core Node Selection and


Multicast Routing Protocol

Core
Tree
Mesh

Core-Based
Approaches
Lightweight Adaptive
Multicast (LAM)

Draws on the Core-Based Tree (CBT) protocol and the TORA


unicast routing algorithm
Each multicast group initialized and maintained by a multicast
server, or core
Any node which wants to communicate with a specific multicast
group can query the directory server
It is more efficient due to elimination of duplicated control
functionality between different protocol layers
LAM builds a group-shared multicast routing tree for each
multicast group centered at the CORE
A multicast tree is source-initiated and group-shared and nodes in
LAM maintain two variable, POTENTIAL-PARENT and
PARENT, and two lists POTENTIAL-CHILD-LIST and CHILDLIST
These potential data objects are used when the node is in a join
or rejoin waiting state
LAM is based on CBT approach to build the multicast delivery tree
With one CORE for a group, LAM is not very robust

Small Group Multicast


Location Guided Tree Construction Algorithm for Small Group
Multicast

This is a small group multicast schemes based on packet encapsulation


It builds an overlay multicast packet distribution tree on top of the
underlying unicast routing protocol
Based on two types of tree: location-guided k-array (LGK) tree and a
location-guided Steiner (LGS) tree
Geometric location information of the destination nodes is utilized to
construct the packet distribution tree without knowing the global
topology of the network
Protocol also supports an optimization mechanism through route caching
In LGK tree approach, the sender first selects nearest k destinations as
children nodes
The sender then groups the rest of the nodes to its k children as per the
closeness to geometric proximity
Once the group nodes are mapped to its corresponding child nodes, the
sender forwards a copy of the encapsulated packet to each of the k
children, with its corresponding subtree as destinations
Process stops when an in-coming packet has an empty destination list

Location Guided Tree


Location Guided Construction
Tree Construction Algorithm for Small
Group Multicast

Zone Routing based


Multicast Zone Routing Multicast

Takes into consideration the hierarchical structure used by the ZRP unicast
routing protocol
Network is partitioned into zones
Each node computes its own zone, determined by nodes lieing within a certain
radius of the node
ZRP is described as a hybrid approach between the proactive and reactive routing
protocols
Routing is proactive inside the zones and reactive between the zones
To create a zone, a MZR node A broadcasts an ADVERTISEMENT message with
a time-to-live (TTL) equal to a pre-configured ZONE-RADIUS
Node B within the zone radius decrements the TTL and forwards the message if
appropriate
Node B makes an entry in its routing table for node A, with the last hop of the
ADVERTISEMENT message as the next hop towards destination
Nodes ZONE-RADIUS hops away from node A become border nodes, and serve as
a gateway between node As zone and the rest of the network
MZR begins its search within the zone before extending outward
A source wants to start sending multicast traffic, it initiates the construction of a
multicast tree
A TREE-CREATE-ACK packet is sent back to the source and intermediate nodes
mark in their routing tables the last hop of the TREE-CREATE-ACK as a
downstream node

Multicast Zone
Routing

Border node unicasts a TREECREATE-ACK to the multicast


source to create a link between
the border node and the source
This sequence continues until
every node in the network
receives a TREE-CREATE
message
Routes in MZR are updated
through the use of TREEREFRESH packets
If a node on the multicast tree
fails to receive a
TREEREFRESH message after
a certain time, it deletes its
multicast entry
TREE-REFRESH packets
could be piggybacked on
multicast data whenever
possible

MZR creates a source specific, on-demand multicast tree with a minimal


amount of routing overhead
Hierarchical approach of MZR does not conserve bandwidth during the
initial TREE-CREATE flood

Source Specific
Multicast Tree
Multicast Optimized Link State Routing (MOLSR)

MOLSR creates a source specific multicast tree


MOLSR is dependent on OLSR as unicast routing algorithm
Routers periodically advertise their ability to route and build
multicast routes
MOLSR nodes can calculate shortest path routes to every potential
multicast source
This is done in the same manner seen in OLSR, except that now the
routes consist entirely of multicast-capable OLSR routers
Multicast routes are built in a backward manner similar to the
method used in MZR
A source that wants to send multicast traffic advertises its intentions
by broadcasting a SOURCE_CLAIM message to every node in the
network
A multicast source periodically sends a SOURCE_CLAIM message
to every node in the network for two reasons
First, it informs multicast receivers that the source is still sending
data
Second, it allows unattached hosts to join the multicast group

Other Protocols
The Associativity-Based Ad Hoc Multicast (ABAM)

This is an on-demand source-initiated multicast routing protocol


A multicast tree is built for each multicast group based on association stability
The link status of each node is monitored by its neighbors
ABAM deals with the network mobility on different levels according to varying mobility
effects: branch repair when the receiver moves, sub-tree repair when a branching node moves,
and full tree level repair when the source node moves

On-demand Location-Aware Multicast (OLAM) protocol

OLAM assumes each node to be equipped with GPS device


Each node can process and take a snapshot of the network topology and make up a multicast
tree (minimum spanning tree)
This protocol does not use any distributed data structures or ad hoc routing protocol as
foundation and full tree level repair when the source node moves

Adaptive Demand-Driven Multicast Routing (ADMR)

A protocol that attempts to reduce non-on-demand components


ADMR uses tree flood to enable packets to be forwarded following variant branches in the
multicast tree
A multicast packet in ADMR floods within the multicast distribution tree only towards the
groups receivers

The Spiral-fat-tree-based On-demand Multicast (SOM) protocol

A spiral fat tree is built as the multicast tree to increase the stability of the tree structure
By using link redundancy of the fat tree, failed links will be easily replaced.

Spiral-fat-tree-based
On-demand Multicast
(SOM)
protocol
A spiral fat tree is built to increase the
stability of the tree structure

Tree

Fat-Tree

Fat-Tree

Mesh based
Approach
multicast
protocols may

Mesh-based
have
multiple paths between any source and receiver
pairs
Mesh-based protocols seem to outperform treebased proposals due to availability of
alternative paths
A mesh has increased data-forwarding
overhead
The redundant forwarding consumes more
bandwidth
The probability of collisions is higher when a
larger number of packets are generated

Mesh based Approach


On-Demand Multicast Routing Protocol
Core-Assisted Mesh Protocol
Forwarding Group Multicast Protocol
Other Protocols

On-Demand Multicast
Routing
Protocol
Mesh-based protocol employing a forwarding group

concept
Only a subset of nodes forwards the multicast packets
A soft state approach is taken in ODMRP to maintain
multicast group members
No explicit control message is required to leave the
group
The group membership and multicast routes are
established and updated by the source on demand
If no route to the multicast group, a multicast source
broadcasts a Join-Query control packet to the entire
network
This Join-Query packet is periodically broadcasted to
refresh the membership information and updates routes

On-Demand Multicast
Routing Protocol
After
establishing
a
forwarding group and route
construction process, a source
can multicast packets to
receivers via selected routes
and forwarding groups
To leave the group, source
simply stops sending JoinQuery packets
If a receiver no longer wants
to receive from a particular
multicast group, it does not
send the Join-Reply for that
group

Core-Assisted Mesh
multicastingProtocol
by creating a shared mesh

Supports
for
each multicast group
Meshes thus created, helps in maintaining the
connectivity to the multicast users, even in case of node
mobility
It borrows concepts from CBT, but the core nodes are
used for control traffic needed to join multicast groups
Assumes a mapping service by building and maintaining
the multicast mesh
Nodes are classified as: simplex, duplex and non-member
CAMP uses a receiver-initiated method for routers to
join a multicast group
CAMP ensures the mesh to contain all reverse shortest
paths between a source and the recipients

Mesh based Approach


Forwarding Group Multicast Protocol

Can be viewed as flooding with limited scope


Flooding is contained within a selected
forwarding group (FG) nodes
Makes innovative use of flags and an associated
timer to forward multicast packets
Uses two approaches to elect and maintain FG
of forwarding nodes: FGMP-RA (Receiver
Advertising) and FGMP-SA (Sender
Advertising)

Mesh based Approach


Other Protocols

A local routing scheme is proposed in the Neighbor


Supporting ad hoc Multicast routing Protocol (NSMP)
Two types of route discovery: flooding route discovery and
local route discovery
Intelligent On-Demand Multicast Routing Protocol (IODMRP) is a modified version of CAMP by employing an ondemand receiver initiated procedure to dynamically build
routes and maintain multicast group membership instead of
using cores
Source Routing-based Multicast Protocol (SRMP) applies
the source routing mechanism defined by the DSR unicast
protocol in a modified manner, decreasing the size of the
packet header
Protocol operates in a loop-free manner, minimizing channel
overhead and making efficient use of network resources

Stateless Approaches
Differential Destination Multicast

Meant for small-multicast groups operating in dynamic networks of


any size
DDM lets source to control multicast group membership
Each node along the forwarding path remembers the destinations to
which the packet has been forwarded last time and its next hop
information
At each node, there is one Forwarding Set (FS) for each multicast
session
The nodes also maintain a Direction Set (DS) to record the particular
next hop to which multicast destination data are forwarded
Source node, FS contains the same set of nodes as the multicast
Member List (ML)
In the intermediate nodes, the FS is the union of several subsets
based on the data stream received from upstream neighbors
Associated with each set FS_k, there is a sequence number
SEQ(FS_k) which is used to record the last DDM Block Sequence
Number seen in a received DDM data packet from an upstream
neighbor k

Stateless Approaches
DSR Simple
Protocol

Multicast

and

Broadcast

Designed to provide multicast and broadcast


functionality
It utilizes the Route Discovery mechanism
defined by the DSR unicast protocol to flood the
data packets in the network
It can be implemented as a stand-alone protocol
In fact, it does not rely on unicast routing to
operate
If DSR has already been implemented on the
network, minor modifications are required to
enable this protocol

Hybrid Approaches
Ad hoc Multicast Routing Protocol

Creates a bi-directional, shared tree by using only group


senders and receivers as tree nodes for data distribution
The protocol has two main components: mesh creation and
tree setup
The mesh creation identifies and designates certain nodes
as logical cores and these are responsible for initiating the
signaling operation and maintaining the multicast tree to
the rest of the group members
A non-core node only responds to messages from the core
nodes and serves as a passive agent
The selection of logical core in AMRoute is dynamic and
can migrate to any other member node, depending on the
network dynamics and the group membership
AMRoute does not address network dynamics and assumes
the underlying unicast protocol to take care

Hybrid Approaches
Ad hoc Multicast Routing Protocol

Hybrid Approaches
Multicast Core-Extraction Distributed Ad Hoc
Routing

The main idea is to provide the efficiency of the tree-based


forwarding protocols and robustness of mesh-based
protocols by combining these two approaches
The infrastructure is robust and data forwarding
occurs at minimum height trees

Mobility-based Hybrid Multicast Routing

Designed to provide multicast and broadcast functionality


Built on top of the mobility-based clustering
infrastructure
The structure is hierarchical in nature
The mobility and positioning information is provided via
a GPS for each node
Cores are employed in both AMRoute and MCEDAR, as
well as in many tree and mesh multicast algorithms

Comparison of Multicast
Approaches

Geocasting
Geocasting is a variant of the conventional multicasting
problem
Group members are within a specified geographical region
Whenever a node in the geocast region receives a geocast
packet, it floods the geocast packet to all its neighbors
A geocast protocol works if at least one node in the geocast
region receives the geocast packet
Protocols use a jitter technique in order to avoid two packets
colliding with each other by a broadcast
Existing geocast protocols divided into two categories: datatransmission oriented protocols and routing creation oriented
protocols
The difference is how they transmit information from a source
to one or more nodes in the geocast region

Data-Transmission
Oriented Geocast
Location-Based
Routing
Multicast Protocols

Extends the LAR unicast routing algorithm for


geocasting
Utilize location information to improve the
performance of a unicast routing protocol
The goal is to decrease delivery overhead of
geocast packets by reducing the forwarding space
for geocast packets, while maintaining accuracy
of data delivery
The algorithm is based upon a flooding approach
while a node determines whether to forward a
geocast packet further via one of two schemes

LBM Scheme 1

A node receives a
geocast packet, it
forwards the packet to
its neighbors if it is
within a forwarding zone
The size of the
forwarding zone
depends on (i) the size of
the geocast region and
(ii) the location of the
sender
A parameter d provides
additional control on
the size of the
forwarding zone
Box forwarding zone: Rectangle covering
source and the forwarding zone

LBM Scheme 2
Does not have a
forwarding zone explicitly
Forwarding is based on
the position of the sender
node and the position of
the geocast region
Node B forwards a geocast
packet from node A if
node B is at least d
closer to the center of the
geocast region
Node K will, however,
discard a geocast packet
transmitted by node B

Voronoi Diagram
The Voronoi diagram
partitions the area in
to a set of convex
polygons such that all
polygon edges are
equidistance

Geo
area

Voronoi Diagram Based


Geocasting

The goal is to enhance


the success rate and
decrease the hop count
and flooding rate
The forwarding zone
defined in LMB may
be a partitioned
network between the
source node and the
geocast region

Voronoi Diagram and


Neighbors that are
closest
Request
Zone
in the direction of the

destination forms the


forwarding zone
Can be implemented with
a Voronoi diagram for a
set of nodes in a given
nodes neighborhood
VDG reduces the flooding
rates of LBM Scheme 1,
as fewer packets should
be transmitted
VDG may offer little
improvement over LBM
Scheme

GeoGRID
GeoGRID protocol uses location information in defining
forwarding zone and elects a special host in each grid
area responsible for forwarding geocast packets
The forwarding zone in LBM incurs unnecessary packet
transmissions
A tree-based solution is prohibitive in terms of control
overhead
GeoGRID partitions the geographic area into twodimensional logical grids of size d X d
Two schemes on how to send geocast packets in
GeoGRID: Flooding-Based GeoGRID and Ticket-Based
GeoGRID.

Flooding-Based
GeoGRID
Only gateways in every
grid within the
forwarding zone
rebroadcast the received
geocast packets
A total of m + n tickets
are created by the source
if the geocast region is a
rectangle of m X n grid

Flooding-Based
GeoGRID

Route Creation Oriented


GeoTORA: reduce the
overhead of transmitting
geocast packets via flooding
techniques, while
maintaining high accuracy
Mesh-based Geocast Routing
Protocol: uses a mesh for
geocasting to provide
redundant paths between
source and group members

Conclusions and
Future Directions
Scalability
Applications for broadcast, multicast,
and geocast over MANETs
QoS
Address configuration
Security
Power control

Table of
Introduction
Contents
TCP Protocol
Overview

Designed and Fine-Tuned to Wired Networks


TCP Basics
TCP Header Format
Congestion Control
Round-Trip Time Estimation

TCP and MANETs

Effects of Partitions on TCP


Impact of Lower Layers on TCP

Solutions for TCP over Ad Hoc

Mobility-Related
Fairness-Related

Conclusions and Future Directions

Introduction
TCP most widely used transport protocol
Ad hoc networks composed exclusively of wireless
links
All nodes can move freely and unpredictably
TCP needs to distinguish the nature of errors

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

67

Designed and Fine


Tuned to Wired
Network

Design heavily influenced by end-to-end argument

Excessive intelligence in physical and link layers to handle error


control, encryption or flow control
Performance often dependant on flow control and congestion control
Time outs and retransmission handle error control
It is important to incorporate link layer acknowledgement and error
detection/correction functionality
High error rates, longer delays and mobility makes MANET
environments extremely challenging
Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

68

TCP Basics
Byte Stream Delivery: TCP interfaces between the application
layer above and the network layer below and TCP decides
whether to segment or delineate the byte stream in order to
transmit data in manageable pieces to the receiver, hence called
byte stream delivery service
Connection-Oriented: Two communicating TCP entities (the
sender and the receiver) must first agree upon the willingness to
communicate
Full-Duplex: TCP almost always operates in full-duplex mode,
and TCP exhibit asymmetric behavior only during connection
start and close sequences (i.e., data transfer in the forward
direction but not in the reverse, or vice versa)
Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

69

Reliable TCP guarantees


A number of mechanisms help provide the guarantees:

Checksums: All TCP segments carry a checksum,used by the receiver


to detect errors with either the TCP header or data

Duplicate data detection:TCP keeps track of bytes received in order to


discard duplicate copies of data that has already been received

Retransmissions: TCP must implement retransmission schemes for


data that may be lost or damaged and the lack of positive
acknowledgements, coupled with a timeout period calls for a
retransmission

Sequencing: It is TCP's job to properly sequence segments it receives


so that it can deliver the byte stream data to an application in order

Timers: TCP maintains various static and dynamic timers on data sent
and if the timer expires before receiving an acknowledgement, the
sender can retransmit the segment

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

70

TCP Header Format

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

71

TCP Frame Details


Source Port: This is a 16-bit number identifying the application where the
TCP segment originated from within the sending host
Destination Port: A 16-bit number identifying the application the TCP
segment is destined for on a receiving host
Sequence Number: A 32-bit number, identifying the current position of the
first data byte in the segment and after reaching 2 32 -1, this number will
wrap around to 0
Acknowledgement Number: A 32-bit number identifying the next data byte
the sender expects from the receiver and is one greater than the most
recently received data byte
Header Length: A 4-bit field that specifies the total TCP header length in 32bit words (or in multiples of 4 bytes), with the largest TCP header of 60 bytes
Reserved: A 6-bit field currently unused and reserved for future use

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

72

Control Bits
Urgent Pointer (URG) If this bit field is set, the receiving TCP should
interpret the urgent pointer field
Acknowledgement (ACK) If this bit is set, the acknowledgment field is valid
Push Function (PSH) If this bit is set, the receiver should deliver this segment
to the receiving application as soon as possible
Reset Connection (RST) If this bit is present, it signals the receiver that the
sender is aborting the connection and all the associated queued data and
allocated buffers can be freely relinquished
Synchronize (SYN) When present, this bit field signifies that the sender is
attempting to synchronize sequence numbers
No More Data from Sender (FIN) If set, this bit field tells the receiver that the
sender has reached the end of its byte stream for the current TCP connection
Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

73

TCP Details
Window: This is a 16-bit integer used by TCP for flow control in the form
of a data transmission window size
Checksum: A sender computes the checksum value of 16-bits, based on the
contents of the TCP header and data fields and is compared with the value
the receiver generates using the same computation
Urgent Pointer: This 16-bit field tells the receiver when the last byte of
urgent data in the segment ends
Options: Depending on the option(s) used, the length of this field varies in
size, but it cannot be larger than 40 bytes due to the maximum size of the
header length field (4 bits)
Padding:It may be necessary to pad the TCP header with zeroes so that
the segment ends on a 32-bit word boundary as defined by the standard
Data: This variable length field carries the application data from TCP
sender to receiver and this field coupled with the TCP header fields
constitutes a TCP segment
Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

74

Congestion Control
Slow Start: (A mechanism to control the transmission rate) Whenever a
TCP connection starts, the Slow Start algorithm at the sender initializes a
congestion window (CWND) to one segment and the congestion window
increases by one segment for each acknowledgement returned
Congestion Avoidance: When Slow Start forces a network to drop one or
more packets due to overload or congestion, Congestion Avoidance is used
to reduce the transmission rate
Fast Retransmit: When a duplicate ACK is received, the sender does not
know if this is because a TCP segment was lost or because a segment was
delayed and received out of order at the receiver and if more than two
duplicate ACKs are received by the sender, it does not even wait for the
Retransmission Timeout to expire and retransmits the segment (as
indicated by the position of the duplicate ACK in the byte stream)
Fast Recovery: The sender has implicit knowledge that there is data still
flowing to the receiver since duplicate ACKs can only be generated when a
segment is received and the sender only enters Congestion Avoidance mode
Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

75

Time Estimation
Round-Trip Time Estimation: When a host transmits a TCP packet to
its peer, and the reply does not come within the expected period, the
packet is assumed to have been lost and the data is retransmitted
Over an Ethernet, no more than a few microseconds should be needed
for a reply
This process called Round-Trip Time (RTT) estimation
If the RTT estimate is too low, packets are retransmitted
unnecessarily; if too high, the connection can sit idle while the host
waits to timeout

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

76

TCP and Manets


Challenges
As the topology changes, the path is interrupted and TCP goes into repeated,
exponentially increasing time-outs, with severe performance impact
TCP performance in ad hoc multi-hop environment depends critically on the
congestion window in use
Significant TCP unfairness
TCP injects packets at an increasing rate into the network until a packet loss
is detected and then, the sender shrinks its CWND, retransmits the lost
packet and resumes transmission at a lower increasing rate
If the losses persist at every retransmission, the sender doubles its wait timer
(i.e., the RTO) so that it can wait longer for the ACK of the current packet
being transmitted and is known as the exponential back off strategy

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

77

awback of TCP Exponential Back

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

78

Efects of Partitions on TCP

Node 5 moves away from node 3 (short-term partition)

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

79

Long Term Partition

Node 5 moves away from node 3 (long-term partition)

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

80

Reestablishing Path
5

6
4
The routing protocol reestablishes the path through node 6

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

81

Long Term Network


Partition

No communication between the partitions

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

82

Impact of Lower Layers on


TCP
MAC Layer Impact:
It is intended for providing an efficient shared broadcast channel through
which the involved mobile nodes can communicate

In IEEE 802.11, RTS/CTS handshake is only employed when the DATA


packet size exceeds some predefined threshold

Each of these frames carries the remaining duration of time for the
transmission completion, so that other nodes in the vicinity can hear it
and postpone their transmissions

The nodes must await an IFS interval and then contend for the medium
again

The contention is carried out by means of a binary exponential backoff


mechanism which imposes a further random interval

At every unsuccessful attempt, this random interval tends to become


higher

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

83

Issues at the MAC


Layer

Consider a linear topology in which each node can only communicate with its
adjacent neighbors
In addition, consider that in Figures 7.7(a) and 7.7(b) there exist a single TCP
connection running between nodes 1 and 5

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

84

TCP Throughput
Larger the number of nodes a TCP connection needs to span, lower is
the end-to-end throughput, as there will be more medium contention
taking place in several regions of the network

TCP throughput is inversely proportional to the


number of hops

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

85

Capture Conditions

In Figure 7.7(c) where there are two independent connections,


(connection 2-3) (connection 4-5)
Assuming that connection 2-3 experiences collision due to the
hidden node problem caused by the active connection 4-5 , node 2
will back off and retransmit the lost frame
At every retransmission, the binary exponential backoff
mechanism imposes an increasingly backoff interval, and
implicitly, this is actually decreasing the possibility of success for
the connection 2-3 to send a packet as connection 4-5 will
dominate the medium access once it has lower backoff value
In consequence, the connection 2-3 will hardly obtain access to the
medium while connection 4-5 will capture it
Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

86

Network Layer Impact


Routing strategies play a key role on TCP performance
There have been a lot of proposed routing schemes and,
typically, each of them have different effects on the TCP
performance

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

87

DSR
DSR protocol operates on an on-demand basis in which a node
wishing to find a new route broadcasts a RREQ packet
The problem with this approach concerns the high probability of
stale routes in environments where high mobility as well as
medium constraints may be normally present
The problem is exacerbated by the fact that other nodes can
overhear the invalid route reply and populate their buffers with
stale route information
It can be mitigated by either manipulating TCP to tolerate such
a delay or by making the delay shorter so that the TCP can deal
with them smoothly
Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

88

TORA
TORA has been designed to be highly dynamic by establishing
routes quickly and concentrating control messages within a small set
of nodes close to the place where the topological change has
occurred
TORA makes use of directed acyclic graphs, where every node has a
path to a given destination and established initially
This protocol can also suffer from stale route problem similar to the
DSR protocol
The problem occurs mainly because TORA does not prioritize
shorter paths, which can yield considerable amount of out-ofsequence packets for the TCP receiver, triggering retransmission of
packets

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

89

Path Asymmetry Impact


In ad hoc networks, asymmetry can occur by different reasons
including lower layer strategies
Loss Rate Asymmetry: It takes place when the backward path is
significantly more error prone than the forward path
Bandwidth Asymmetry: Here, forward and backward data follow
distinct paths with different speeds and this can happen in ad hoc
networks as well, since all nodes need not have the same interface
speed
Media Access Asymmetry: This type of asymmetry may occur due to
characteristics of the wireless shared medium as TCP ACKs may have
to contend for the medium along with TCP data, which may cause
excessive delay as well as drops of TCP ACK packets
Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

90

Route Assymetry

Route asymmetry implies in distinct paths in both directions


Route asymmetry is associated with the possibility of different
transmission ranges for the nodes
The inconvenience with different transmission ranges is that it can
lead to conditions in which the forward data follow a considerably
shorter path than the backward data (TCP ACK) due to lack of power
in one (or more) of the nodes in the backward path
However, multi-hop paths are prone to have low throughput and TCP
ACKs may face considerable disruptions

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

91

Solutions for TCP over Ad


Hoc
Mobility-Related
TCP-Feedback

TCP sender can effectively distinguish between route failure and


network congestion by receiving Route Failure Notification (RFN)
messages from intermediate nodes

Upon receipt of a Route Re-establishment Notification (RRN)


message from the routing protocol, the sender leaves the frozen state
and resumes transmission using the same variables values prior to
the interruption

A route failure timer is employed to prevent infinite wait for RRN


messages, is started whenever a RFN is received and upon expiration
of this timer, the frozen timers of TCP are reset hence allowing the
TCP congestion control to be invoked normally

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

92

The ELFN Approach


Explicit Link Failure Notification (ELFN) is a cross-layer proposal in
which TCP also interacts with the routing protocol in order to detect route
failure and take appropriate actions
ELFN messages are sent back to the TCP sender from the node detecting
the failure
ELFN messages contain sender and receiver addresses and ports, as well
as the TCP sequence number
Whenever the TCP sender receives an ELFN message, it enters a standby mode in which its timers are disabled and probe packets are sent
regularly towards the destination in order to detect route restoration
Upon receiving an ACK packet, the sender leaves the stand-by mode
and resumes transmission using its previous timer values and state
variables
Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

93

Fixed Retransmission
Timeout (RTO)
Relies on the idea that routing error recovery should be
accomplished in a fast fashion by the routing algorithm
It disables such a mechanism whenever two successive
retransmissions due to timeout occur, assuming that it
actually indicates route failure
TCP sender doubles the RTO once and if the missing packet
does not arrive before the second RTO expires, the packet is
retransmitted again and again, but the RTO is no longer
increased

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

94

The ATCP Protocol


The Ad hoc TCP (ATCP) protocol does not impose changes to
the standard TCP itself and instead, it implements an
intermediate layer between the network and the transport
layers in order to provide an enhanced performance to TCP
ATCP relies on the ICMP protocol and on the Explicit
Congestion Notification (ECN) scheme to detect / distinguish
network partition and congestion, respectively
The intermediate layer keeps track of the packets to and from
the transport layer so that the TCP congestion control is not
invoked when it is not really needed

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

95

TCP-DOOR
(Detection Out-OfOrder and Response )

Mobility in MANETs is extremely frequent and the packet


usually arrive out-of-order (OOO) at the destination
The TCP-DOOR (Detection of Out-Of-Order and Response)
protocol focuses on the idea that OOO delivery of packets
can happen frequently in MANETs as a result of nodes
mobility
TCP-DOOR implements a detection of such deliveries at
both entities: TCP sender and TCP receiver

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

96

Main Drawbacks
The approaches that rely on feedback information from inside the
network (TCP-F, ELFN-based, ATCP) may fail in situations where
TCP sender is unable to receive data from the next hop node
The usage of explicit notification by the intermediate nodes, such
as ECN, raises many security concerns
The assumption in TCP-DOOR that OOO packets are exclusive
results of route disturbance may not be true in a quite a few
scenarios
The main concern addressed by the approaches presented so far is
how to avoid the TCP exponential backoff mechanism when losses
take place by factors other than congestion

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

97

FairnessRelated

COPAS
A protocol called COPAS (COntention-based PAth
Selection) has been proposed to address TCP performance
drop due to the capture problem and resulting unfairness
COPAS implements two novel routing techniques in order
to contention-balance the network, namely, the use of
disjoint forward (for TCP data) and reverse (for TCP
ACK) paths to reduce the conflicts between TCP packets
traveling in opposite directions

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

98

Route Establishment in
COPAS
TCP ACK
B

2
8

5
7
D

S
3

1
I

(a) Network contention


perceived at node D

TCP Data

(b) Routes selected by node D

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

99

Average Aggregate
Throughput

50 Nodes

100 Nodes

Simulation results of COPAS applied to scenario of 50 and 100 nodes


Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

100

Neighborhood RED
(Randomly Early
Two unique
features of ad hoc wireless networks are the key to
Detection)
understand unfair TCP behaviors: Spatial reuse constraint and the
location dependency

View a node and its interfering neighbors to form a neighborhood (the


neighborhood of a node X is formed by all nodes within communication
range of X)
Flows get different feedback in terms of packet loss rate and packet delay
when congestion happens
The main achievement of NRED is the ability to detect early congestion
and drop packets proportionally to a flows channel bandwidth
utilization

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

101

Node As
Neighborhood
and Distributed
Queue

Keep estimating the size of


neighborhood queue
Once queue size exceeds certain
threshold, a drop probability is
computed
This is propogated to provide
cooperative packet drop

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

102

Conclusions and Future


Directions
Concerning the error-detection
strategies used in each approach, they

may be classified as network detection and end node detection


Each approach has its advantages and disadvantages, and ideally, it is
better to combine the advantages of each one
The interactions between TCP and MAC protocols could be improved
by using either using smaller values for the maximum TCP window size
or larger MAC IFS intervals, respectively
It might be useful to investigate the possibility of increasing the
maximum number of possible retransmissions at the MAC layer as an
attempt to increase the probability of success of the local retransmission
scheme
With regards to multipath routing strategies, further evaluation
towards improvements with respect to TCP support is needed
Power management is a very important topic within MANETs, as they
are supposed to be composed mostly of battery powered devices
Thus, power aware approaches offer increasing interest while little has
been done with regards to TCP, as is not power aware
Interoperation between wireless mobile ad hoc networks and wired
networks is another subject that has not been adequately addressed
from TCP perspective
Security considerations have become nowadays a hot issue in wireless
environments as wireless mediums are much more susceptible to
malicious users than the wired ones

Copyright 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved.

103