Outline
This presentation is the property of its rightful owner.
Sponsored Links
1 / 27

Outline PowerPoint PPT Presentation


  • 119 Views
  • Uploaded on
  • Presentation posted in: General

Outline. Wireless introduction Wireless cellular (GSM, CDMA, UMTS) Wireless LANs, MAC layer Wireless Ad hoc networks routing: proactive routing, on-demand routing, scalable routing, geo-routing wireless Ad hoc multicast TCP in ad hoc networks QoS, adaptive voice/video apps

Download Presentation

Outline

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Outline

Outline

Wireless introduction

Wireless cellular (GSM, CDMA, UMTS)

Wireless LANs, MAC layer

Wireless Ad hoc networks

routing: proactive routing, on-demand routing, scalable routing, geo-routing

wireless Ad hoc multicast

TCP in ad hoc networks

QoS, adaptive voice/video apps

Sensor networks


Multicast ad hoc networks

Multicast ad hoc networks

  • Multicast in ad hoc nets

    • Review of Multicasting in wired networks

    • Tree based wireless multicast

    • Mesh based wireless multicast – ODMRP

    • Performance comparison

  • Scalable multicast

    • M-LANMAR

    • Backbone

  • Reliable, congestion controlled multicast

    • RALM, RALM with M-LANMAR


Wired ip multicast is dead

Wired IP Multicast is dead!

  • Wired IP multicast is far from wide deployment

    • Router upgrade, state scalability, access control, pricing ...

    • Data and non real time video multicast is now being replaced by web downloading

  • Internet “real time multicast” (eg, video conference, games, etc) is using “overlays”

    • Multicast routing and addressing managed by an “overlay” at the application (ie, Host) level; Hosts connected by virtual links (tunnels).

    • Several “overlay” topology design schemes (eg., Narada, Nice, etc)

    • Tools to “probe” the tunnels for capacity, delay, loss etc ( Over-probe project at UCLA)


Wireless multicast very much alive

Wireless Multicast: very much alive!

  • Multicast service critical in ad hoc nets:

    • Video, voice multicast is critical in collaborative, team oriented, ad hoc operations

    • Multicast (data + streaming) is the prevalent traffic in most ad hoc wireless network apps (eg, search and rescue; disaster recovery, etc)

  • Broadcast advantage of wireless over wire

  • Can we use web download or application “overlays”?

    • Conventional web serversnon practical, vulnerable, non real time in wireless scenarios

    • Application level overlaysdo not work well in ad hoc networks: difficult to maintain in the face of mobility


Outline

S2

S1

R2

R1

Per-Source Tree Multicast

  • Like DVMRP (Distance Vector Multicast Routing Protocol)and PIM-DM (Protocol Independent Multicast - Dense Mode)in wired net

  • Each source supports

    own separate tree

  • “Probing and Pruning”

    tree maintenance

  • Reverse Path Forwarding

  • “Fast Source” problem


Outline

RP-based Shared Tree Multicast

  • RP (Rendezvous Point) - based “Shared” tree

  • Similar to wired network CBT(Core Based Tree), PIM-SM (Sparse Mode)

  • Tree maintenance:

    • soft state

  • “off-center” RP

  • Longer paths than shortest path tree

RP

S1


Outline

Shared Tree vs. Per-source Tree

  • Shared Tree:

    • scalability

    • less sensitive to

      fast source

    • longer path

    • off center RP

  • Per-Source Tree:

    • shortest path

    • traffic distribution

    • no central node

    • scalability problem

    • fast source problem

R2

R3

RP

S1

R4

S2

R1


M aodv a shared tree multicast scheme

M-AODV: a shared tree multicast scheme

  • M-AODV: Multicast AODV

  • A shared tree, with common root, is shared by all sources and receivers

  • A designated node, or simply the first source or receiver that initializes the tree, becomes the root R, ie, the leader of group G

  • Initialization: application at R requests to join group G; M-AODV network layer at R floods a Route Request

  • If no response is received to several floods, node R becomes the leader of group G


M aodv cont

M-AODV (cont)

  • Periodically, say every 5 sec, the root node R floods a GROUP HELLO message to inform the network of the presence of group G

  • A new member wishing to join Gunicasts a JOIN REQUEST to root R; R returns a ROUTE REPLY, setting up the “forwarding tables” a laAODV along the path.

  • In the M-AODV tree, each node keeps track of upstream and downstream neighbors

  • A data packet is forwarded to all neighbors but the node from which the packet was received (unicast or broadcast may be used)


M aodv maintenance

M-AODV Maintenance

  • Link health is monitored:

    • By exchanging periodic HELLO’s with neighbors

    • By overhearing neighbors

  • If upstream link to root R is broken, a node will use “expanding ring” search to reconnect

  • If local reconnect does not work, the end nodes (sources/receivers) must reconnect.

  • Summary:

    • M-AODV keeps forwarding state like AODV, but it is receiver (instead of sender) oriented

    • M-AODV requires periodic HELLO messages (why did AODV could do without them?)

    • Repair is more complex than AODV (entire subtree below..)


Wireless tree multicast limitations in high mobility

RP

Wireless Tree Multicast Limitations in High Mobility

  • In a mobile situation, tree is fragile: connectivity loss, multipath fading

  • Need to refresh paths very frequently

  • High control traffic overhead


Solution forwarding group multicast

Forwarding Group

FG

FG

FG

FG

FG

Solution: Forwarding Group Multicast

  • All the nodes inside the “bubble” forward the multicast packets via “restricted” flooding

  • Multicast Tree replaced by Multicast “Mesh”

  • Flooding redundancy overcomes displacements & fading

  • Forwarding Group nodes selected by tracing shortest paths between multicast members


Odmrp on demand multicast routing protocol

ODMRP (On Demand Multicast Routing Protocol)

  • Forwarding Group Multicast concept

  • Tree replaced by Mesh

  • On-demand approach

  • Soft state


Forwarding group concept

A set of nodes in charge of forwarding multicast packets

Supports shortest paths between any member pairs

Flooding helps overcome displacements and channel fading

Forwarding Group Concept


Mesh vs tree forwarding

Richer connectivity among multicast members

Unlike trees, frequent reconfigurations are not needed

Mesh vs Tree Forwarding


Fg maintenance on demand approach

A senderperiodicallyfloods ctrl msg when it has data to send

All intermediate nodes set up route to sender (backward pointer)

Receivers update Member Tables; periodically broadcast Join Tables

Nodes on path to sources set FG_Flag; FG nodes broadcast Join Tables

FG Maintenance (On-Demand Approach)


Soft state approach

Soft State Approach

  • No explicit messages required to join/leave multicast group (or FG)

  • An entry of a receiver’s Member Table expires if no Join Request is received from that sender entry during MEM_TIMEOUT

  • Nodes in the forwarding group are demoted to non-forwarding nodes if not refreshed (no Join Tables received) within FG_TIMEOUT


A performance comparison study of ad hoc wireless multicast protocols

A Performance Comparison Study of Ad Hoc Wireless Multicast Protocols

S.J. Lee, W. Su, J. Hsu, M. Gerla, and R. Bagrodia

Wireless Adaptive Mobility Laboratory

University of California, Los Angeles

http://www.cs.ucla.edu/NRL/wireless


Outline

Goal

  • Compare mesh- and tree-based multicast protocols

    • Mesh-based: ODMRP, CAMP, Flooding

    • Tree-based: AMRoute, AMRIS

  • Evaluate sensitivity to the following parameters:

    • Mobility (ie, speed)

    • Number of multicast sources

    • Multicast group size

    • Network traffic load


Simulation environment

Simulation Environment

  • Written in PARSEC within GloMoSim Library

  • 50 nodes placed in 1000m X 1000m space

  • Free space channel propagation model

  • Radio with capture ability

  • Radio propagation range: 250 m

  • Bandwidth: 2 Mb/s

  • MAC: IEEE 802.11 DCF

  • Underlying unicast : Wing Routing Prot (for AMRoute & CAMP)

  • Multicast members and sources are chosen randomly with uniform probabilities

  • Random mobility


Packet delivery ratio as a function of mobility speed

Packet Delivery Ratio as a Function of Mobility Speed

  • 20 members

  • 5 sources each send 2 pkt/sec

  • Mesh protocols outperform tree protocols

  • Multiple routes help overcome fading and node displacements


Packet delivery ratio as a function of of sources

Packet Delivery Ratio as a Function of # of Sources

  • 20 members

  • 1 m/sec of mobility speed

  • Total traffic load of 10 pkt/sec

  • Increasing the number of sender makes mesh richer for ODMRP and CAMP


Packet delivery ratio as a function of multicast group size

Packet Delivery Ratio as a Function of Multicast Group Size

  • 5 sources each send 2 pkt/sec

  • 1 m/sec of mobility speed

  • Flooding and ODMRP not affected by group size

  • CAMP builds massive mesh with growth of

    the members


Packet delivery ratio as a function of network load

Packet Delivery Ratio as a Function of Network Load

  • 20 members and 5 sources

  • no mobility

  • AMRIS is the most sensitive to traffic load due to large beacon transmissions

  • Why? Flooding is so good


Control bytes txed data byte delivered as a function of speed

Control Bytes Txed/Data Byte Delivered as a Function of Speed

  • 20 members

  • 5 sources each send 2 pkt/sec

  • Data packet header included in overhead

  • No updates triggered by mobility in ODMRP and Flooding

  • Why? Flooding is so good


Control bytes txed data byte delivered as a function of number of sources

Control Bytes Txed/Data Byte Delivered as a Function of Number of Sources

  • 20 members

  • 1 m/sec of mobility speed

  • Total traffic load of 10 pkt/sec

  • ODMRP’s overhead grows with the number of sources because of per-source mesh


Outline

Conclusions

  • Tree schemes:

    • Too fragile to mobility

    • lower throughput in heavy load

    • lower control O/H

  • Meshed Based scheme (CAMP):

    • Better than tree schemes (mesh more robust)

    • Mesh requires increasing maintenance with mobility

    • ODMRP:

      • most robust to mobility& lowerO/H

  • Lessons learned:

    • Mesh-based protocols outperform tree-based protocols

    • Multiple routes help overcome node displacements and fading


  • Login