A Performance Comparison Study Of Ad Hoc Wireless Multicast Protocols

1
A Performance Comparison Study Of Ad Hoc
Wireless Multicast Protocols

• Chen Chagashi
• December 2002

2
What Im gonna talk about

• Overview
• Principles of the following protocols
• ODMRP
• AMRoute
• CAMP
• AMRIS
• Comparison
• Conclusions

3
Characteristics of Wireless Ad Hoc Network..

• Loss of signals
• Dynamic (node mobility)
• Network topology changes frequently and
  unpredictably
• Multi-hop routes
• Limited battery power
• Relatively low bandwidth

4
Why Multicast in Ad Hoc?

• Forming an ad hoc network implies cooperativeness
  
• one to many applications
• Battlefield data dissemination
• Many-to-many
• search/rescue team communication

5
Why Dont We Just Use Existing Multicast Protocol
for Ad Hoc Network?

• Frequent tree reorganization
• Signaling overhead
• Collisions
• Loss of packets
• Protocol design
• Robustness vs. Efficiency

6
Several Multicast Protocols Exist

• Tree based
• AMRIS, AMRoute
• Core based
• CAMP
• Mesh based
• ODMRP, CAMP
• Forwarding group
• ODMRP

7
On-demand Multicast Routing Protocol (ODMRP)

• References
• M. Gerla G. Pei, S. J. Lee, and C. C. Chiang,
  On-demand multicast routing protocol, Internet
  Draft. (1998). www.ietf.org/internet-drafts/draft-
  ietf-manet-odmrp-00.txt.
• M. Gerla, G. Pei, S.J. Lee, and C.C. Chiang,On
  Demand Multicast Routing Protocol for Mobile
  Ad-Hoc Networks 1998
• C.-C. Chiang, M. Gerla, and L. Zhang. Forwarding
  Group Multicast Protocol (FGMP) for Multihop,
  Mobile Wireless Networks. 1998

8
ODMRP In a Nutshell

• On demand routing
• Mesh-based protocol
• Uses the concept of forwarding group
• Sender-initiated
• Soft state member nodes are refreshed as needed
  do not send explicit leave messages
• Unicast routing capability

9
ODMRP Group construction

• A sender node wishing to send multicast packets
  periodically broadcasts a Join Request(JR)
  throughput the network.
• A node receiving a non-duplicate JR
• stores the upstream node ID
• rebroadcasts the packet.

R
S
R
NR
R
R
Join Request (JR)
R
10
ODMRP Group Construction Cont.

• A multicast receiver, getting the JR creates or
  updates the source entry in its member table(MT).
• As long as valid entries in receivers MT, join
  reply (JR) are broadcasted periodically.

R
S
R
NR
R
R
join reply (JR)
R
11
ODMRP Mesh Creation

• An intermediate node, receiving the JR
• Compares its ID with the entries of that table
• If theres a match, it is a member of the
  forwarding group. It sets the FG_flag and
  broadcasts its JR

R
S
R
NR
R
R
R
12
ODMRP the Group Has Been Constructed..

• A multicast source can transmit packets to
  receivers via forwarding group.
• Periodic control packets are still present.

13
ODMRP the Group Has Been Constructed..

• When receiving a multicast data packet, a node
  forwards it ONLY IF
• It is not a duplicate
• The setting of the FG_flag for the multicast
  group has not expired
• This procedure minimizes traffic overhead and
  prevents sending packets through stale routes

14
Data Structure

• Member table (receiver)
• (Source ID, time stamp of join request)
• Routing table
• (Source,next_hop)
• Forwarding group table (FG member)
• (Multicast group ID, the timestamp FG_flag)
• Message Cache (each node)
• detect duplicates

15
ODMRP Characteristics

• No explicit control packet to leave the group
• Sender stop sending JOIN_REQUEST
• Receiver
• Remove (src,grp) entry from its member table
• Stop broadcasting JOIN_REPLY
• Dont need to be built on top of a unicast
  routing protocol

16
ODMRP Flooding and Channel Overhead Decrement

• REFRESH_INTERVAL is critical
• Can efficiently adapt to mobility patterns and
  speeds by utilizing the location and movement
  information (need GPS)
• Mobility prediction will help to determine how
  frequent route will change
• Join queries are only flooded when route breaks
  of ongoing data sessions are imminent

17

• Adhoc Multicast Routing Protocol
• (AMRoute)

References AMRoute draft-talpade-manet-amroute-0
0.txt
18
Highlight of AMRoute

• Tree based and dynamic cores
• A bidirectional shared-tree (1 tree per group)
  improving its scalability
• Create a mesh to establish connectivity before
  tree creation
• Use virtual mesh links to establish the multicast
  tree
• As long as routes between tree member exist via
  mesh links, the tree need not be readjusted when
  network topology change

19
Highlight of AMRoute Cont.

• Only group sender and receiver are tree nodes
• Neighbors in the tree are connected using unicast
  tunnelling through the intermediate routers
• IP-in-IP encapsulation capability
• It is independent of the specific unicast protocol

20
AMRoute Core nodes

• At least one per group
• Only used for signaling (discover new member
  create tree)
• Dynamic migration of core node according to group
  membership and network connectivity
• Not a central point of distribution!

21
Mesh Creation - Join the Group

• Each group member declare itself as a core
• Each core Periodically floods Join-Reqs
• Replies Join Ack

22
Mesh Creation

• Upon receiving a JOIN-REQ
• If Im a core
• If the source of message is in my group and I
  dont have a mesh/tree link to it gt return a
  JOIN-ACK
• Otherwise, decrement the TTL and re-broadcast
• If Im a non-core member
• If the message is from my core or for another
  group gt decrement the TTL and re-broadcast
• If its from a different core (of my group) gt
  return JOIN-ACK and mark the source as a mesh
  neighbor

23
Message type

• Control message
• Join-REQdetect group member
• Join-ACKresponse for receiving JOIN-REQ from a
  different core
• Join-NAKleave the group
• Tree-createrefresh the tree
• Tree-create-NAKconvert tree link to mesh link

24
Mesh Creation(Join the group)
25
Tree Creation
26
Tree Creation
Join Nak
27
Tree Creation

• Each core periodically transmits Tree Create

28
Tree Creation

• The node receiving TCN marks the link as mesh
  link instead pf tree link

29
Leaving the group (node failure) case (1)
30
Leaving the group(node failure)case (1)
31
Leaving the group (node failure) case (2)
32
Leaving the group (node failure) case (2)
33
Data Structure

• One table for the mesh neighbors
• One table for the hop-count associated with each
  mesh link
• ID of logical core
• Updated by the periodic control message

34
AMRoutes Features

• Robust core failure does not hinder data flow
• Simple No need to handle node mobility (done by
  unicast protocol)
• Only two basic message types (JOIN_REQ and
  TREE_CREATE)
• Non-members need not support multicast

35
AMRoutes Features

• Efficient shared tree per group
• Can operate over any unicast routing protocol
  seamlessly over multiple domains

36
Core-Assisted Mesh Protocol (CAMP)
References The Core-Assisted Mesh Protocol
by Garcia-Luna-Aceves and Madruga
37
CAMP Overview

• Mesh-based protocol
• Receiver initiated
• On top of an existing unicast protocol
• Ensure reverse shortest paths from receivers to
  sources are part of a groups mesh
• Cores are used for the creation of multicast
  mesh. No more broadcasting!

38
CAMP Motivation

• Reduce channel overhead
• Using core(s) limits the traffic needed for a
  router to join a multicast group
• Better performance than ODMRP when the number of
  senders goes up and also when the number of
  members in a group goes up. (Better scalability)

39
Core in CAMP..

• Can have multiple cores for each mesh
• Cores need not to be part of mesh of their group
• The core disseminates out to the network, as part
  of group membership report, a mapping of
  multicast address to (one or more) core addresses

40
An Anchor

• An anchor is a neighbor router who is the next
  hop in the reverse shortest path to at least one
  source in the group
• Prevent routers that are required by their
  neighbors to forward packets from leaving groups
  prematurely

41
Join the Group

• If any of my neighbor is member of group?
• Yes- announce its membership using either CAMP
  update
• No- send a join request toward core
• Cores are not reachable gt expanding ring search
  (flooding)
• When response are sent back, choose any of these
  response to use as a path to the mesh

42
Leave the Group

• When
• It has no hosts that are members
• It has no neighbors for whom it is an anchor
• How
• Issue a quit notification (as part of MRU) to its
  neighbors, who in turn update their MRT
• No ACK needed
• Core can leave group as long as no one use it as
  an anchor

43
How to Ensure the Mesh Contains All the Reverse
Shortest Paths

• Use heartbeat message push join

44
How to Ensure the Mesh Contains All the Reverse
Shortest Paths

• Periodically, router look up to see the neighbor
  that relayed the packet is on the reverse
  shortest path(RSP) to source
• A heartbeat is sent to the successor in the RSP
  to the source
• That heartbeat triggers a push join (PJ) message
  when the successor is not a mesh member

45
Heartbeat Push Join..

• The PJ forces that specific successor and all
  routers in the path to the source to join the
  mesh.

46
Why Not CAMP?

• On top of an existing unicast protocol.
• Too much information has to be kept in every
  node. So every change in the mobile network needs
  a lot of data update! Not good for a high
  mobility ad hoc network.

47
Date Structure

• For router I
• Unicast routing table
• Cam mapping cores to mc group
• Packet-forwarding cache
• N(i,g,)
• Multicast routing table MRT(g,i)
• Anchor table AT(i)
• LS(g,i)
• LR(g,i)

48
Date Structure (1)

• For router I
• Unicast routing table destination jsuccessor
  s(i,j)distance (i,j)
• Cam A table mapping cores to multicast group
• Packet-forwarding cache cache(i)
• Maintain the ID of packets recently processed by
  the router

49
Date Structure (2)

• N(i,g,) contains all neighbors that through
  update are known to be mesh member of group g
• Even non-member router needs to keep this list
  updated (so it can become a member when receiving
  a join request, without the need to send the
  request any further)

50
Date Structure (3)

• Multicast routing table MRT(g,i)
• Statusgroupmodified_flag
• Status CORENON_COREDUPLEXSIMPLEXNON MEMBER
• Modified_flag whether an update has to be sent
  with information about group g

51
Date Structure (4)

• Anchor table AT(i)
• Two lists for AT a list of neighbors that have
  router i as their anchor a list of neighbors
  who are anchors to router I
• When MRT or AT is updated, send a multicast
  routing update (MRU) to all neighbors
• MRUgrpop_codemembership_notification
• Op_code quit , simplex , duplex
• Membership notification
• A list of anchors needed by router i
• A list of newly discovered source

52
Date Structure (5)

• LS(g,i) A list of sender that directly attached
  to router i
• LR(g,i) A list of receiver that directly
  attached to router i
• Help router i to know when its appropriate to
  terminate membership to the group
• When a newly discovered local sender is inserted
  into LS , a MRU is propagated to the mesh, and
  this entry will be timed out from LS if the data
  traffic doesnt keep coming

53
Topology Change

• Link/node failure less severe in CAMP due to
• Mesh structure
• ERS (expanded ring search) helps even no routes
  to core

54
Keep Mesh Connected..

• Mesh might be partitioned due to router mobility
  or network itself
• When a router loses connectivity with all cores
• Set a flag to remind itself to try to connect the
  cores again later
• When unicast RT indicates some core is reachable
  again gt send join request via reverse shortest
  path toward it to reconnect mesh

55
Keep Mesh Connected Cont.

• When 2 or more segments of the mesh has been
  partitioned
• Core explicit join (CEJ)
• To ensure 2 or more mesh components with cores
  will eventually merge
• All cores periodically send CEJ to each other

56
Ad Hoc Multicast routing Protocol utilizing
Increasing id-number(AMRIS)(working in progress)
57
AMRIS Overview

• On demand protocol
• Constructs shared delivery tree
• Assign each node in a multicast session an
  id-number
• Significance of msm-id provides each node with
  the indication of its logical height in the
  multicast delivery tree

58
AMRIS Overview Cont.

• Nodes id-number increases as they radiate from
  the root
• Repairs to broken link are performed locally

59
Tree Initialization

• Determine which node will assume the role of
  Sid(core node)
• If single sender multiple receiver
• -gtSid is the single sender
• If multiple sender multiple receiver-gtSid may be
  selected among the senders

60
Tree Initialization

• Sid initiates a multicast session by broadcasting
  NEW SESSION message to its neighbors

61
Tree Initialization
I node
I node
I node
JOIN REQ
62
Tree Initialization
I node
I node
I node
JOIN ACK
63
Tree Initialization

• All nodes that receive NEW-SESSION, generate
  their own msm-id, a value larger and not
  consecutive, so that there are gaps between
  msm-ids of sender and receiver

64
Tree Initialization

• Useful for quick local repair of the delivery
  tree
• Rebroadcast NEW-SESSION with its msm-id

65
Multicast Beacon

• Each node broadcasts it to its neighbors
• A message sent to detect link breakage within a
  fixed time
• Node id
• msm-id status (member/non-member, lifetime)
• Parent id
• Child id
• Partition-id (can be used to merge two partition)

66
Join the Tree

• If the requesting node X has a neighbor who is
  already on the tree
• Send JOIN-REQ to that neighbor Y
• Neighbor Y will send back JOIN-ACK to confirm now
  X is its child

67
Join the Tree
68
Join the Tree
69
Join the Tree
70
Join the Tree

• If the neighbors are not on the tree,
• X send JOIN-REQ to one of the neighbor Y
• If X fails to receive Ack or receives Nak, it
  performs branch reconstruction (BR)
• It is executed in an ERS until the node succeeds
  in joining the multicast session

71
When Link Is Broken

• If a link breaks between two nodes, the child X
  (the one with larger msm-id) should initiate the
  recovery by entering broadcasting mode

72
Comparison
73
(No Transcript)
74
Simulation model

• GloMoSim
• 50 mobile hosts
• 1000m 1000m area
• Radio propagation range 250m
• 2 Mbit/sec
• 600 secs of simulation time

75
Simulation Modelmore

• Used the IEEE 802.11 MAC.
• CAMP and AMRoute unicast protocol is WRP.
• Size of the data payload is 512B.
• The member nodes join the multicast session at
  the beginning of the simulation and remain as
  members throughout the simulation.

76
Metrics

• Packet delivery ratio
• Ratio of packets actually delivered vs. The
  amount of packets supposed to be delivered
• Number of data packets transmitted per data
  packet delivered
• Count of each individual data transmission from
  every node of entire network
• Always greater than or equal to one in unicast
  but in multicast could be less than one

77
Metrics Continue

• Number of control bytes transmitted per data
  bytes delivered
• Control packets acknowledgments, route updates,
  beacons, join requests, header bytes are counted
  as control and payload is added to data byte
  section
• Number of control and data packets transmitted
  per data packet delivered
• Efficiency in terms of channel access

78
Scenarios

• Varying the mobility speed
• Increasing the number of senders
• Fixed speed, fixed transmission rate
• Multicast group size
• Fixed speed, fixed transmission rate, fixed
  senders
• Network traffic
• No mobility
• Buffer overflows
• Collisions

79
Results Mobility Speed - Packet Delivery Ratio
ODMRP CAMP AMRIS AMRoute
80
Results Mobility Speed - Packet Delivery Ratio

• ODMRP provides redundant routes the chances of
  packet delivery is high.
• CAMP uses a mesh too. In CAMP the paths to
  distant destination have fewer redundant paths
  than those closer to the center of the mesh.
• The tree based shows poor delivery ratio.

81
Results Mobility Speed - of data transmissions
/ data delivery

• ODMRP
• CAMP
• AMRIS
• AMRoute

82
Results Mobility Speed - of data transmissions
/ data delivery

• AMRoute has the highest number of transmissions
  loops
• The meshes protocols ODMRP CAMP transmit more
  data packets than AMRIS

83
Results Mobility Speed control bytes overhead
/ data byte

• ODMRP
• CAMP
• AMRIS
• AMRoute

84
Results Mobility Speed control bytes overhead
/ data byte

• Data packet header is include in control overhead
• AMRIS shows a low control overhead it transmits
  less data packets
• WRP suffers from exponential growth in control
  traffic overhead under increasing mobility
• AMRoute has the highest ratio because of the loops

85
Results of Senders Packet Delivery Ratio

• ODMRP
• CAMP
• AMRIS
• AMRoute

86
Results of Senders Packet Delivery Ratio

• ODMRP is the best
• More forwarding nodes gt path redundancy
• Collision is limited due to suppression for
  JOIN-REQ
• CAMP also show improved performance
• Increase the number of anchors required. gt More
  nodes are forced to join the mesh gt better path
  redundancy
• Tree-based protocol like AMRIS AMRoute are not
  affected

87
Results of Senders control bytes overhead /
data byte

• ODMRP
• CAMP
• AMRIS
• AMRoute

88
Results of Senders control bytes overhead /
data byte

• Every protocol except ODMRP shows a constant
  value
• ODMRP builds per source meshes
• ODMRP may be inefficient in networks where a
  large number of nodes are multicast sources

89
Results Multicast Group Size Packet Delivery
Ratio

• ODMRP
• CAMP
• AMRIS
• AMRoute

90
Results Multicast Group Size Packet Delivery
Ratio

• ODMRP/flooding are not affected
• CAMP improve its performance as the number of
  receivers increases
• The mesh become massive with the growth of the
  member gt more redundant paths

91
Results Multicast Group Size Packet Delivery
Ratio

• AMroute critical links increase as tree links
  increase
• Critical link the wireless link which might
  become temporarily unidirectional because node
  movement (affected by node speed and mobility
  pattern ) gt packet might lose at these critical
  links
• No alternate route in AMRoute since it uses a
  shared tree to forward data

92
Results Traffic Load Packet Delivery Ratio

• ODMRP
• CAMP
• AMRIS
• AMRoute

93
Results Traffic Load Packet Delivery Ratio

• AMRISmost sensitive. Suffer from collision when
  the transmission and size of beacon increases
• AMRoute buffer overflow
• CAMP when of collision increases, which in
  turn cause control packets dropped, delay anchor
  construction
• Flooding every data packet is flooded and the
  number of collisions grows
• ODMRP less control overhead, less buffer
  overflow then CAMP

94
Protocol Analysis AMRoute

• Simple and scalable in the number of senders
• Not good in a mobile environment
• Other drawbacks
• Loops
• Inefficient formation of trees

95
Protocol Analysis ODMRP

• Providing redundant paths by mesh
• Robust to mobility
• Low overhead in high mobility because no control
  packets are triggered by link breaks
• Control overhead when there are a large number of
  senders

96
Protocol Analysis AMRIS

• Sensitive to mobility and traffic loads
• Transmissions and size of beacons
• Collisions even if the nodes are stationary
• Dense networks- perform worse
• If the beacon is sent only when no packets has
  been transmitted the number of beacons can be
  reduced

97
Protocol Analysis CAMP

• Good control traffic scalability for increasing
  group size
• Join-Req propagate until they reach a mesh member
  not exponential growth of multicast updates
• but
• WRP response to link breaks is not immediate
• Improved by using an on demand routing protocol
  as a unicast protocol

98
Conclusions

• In a mobile scenario mesh-based protocols
  outperformed tree-based
• The availability of alternate routes provided
  robustness to mobility
• CAMP suffers from control overhead cased by
  congestion and collisions
• ODMRP was effective and efficient in most of the
  simulation scenarios except for when the number
  of sender increased

99
Thank You!