Scalable Network and Transport Protocols AINS Project review, Aug 4, 2004 - PowerPoint PPT Presentation

About This Presentation
Title:

Scalable Network and Transport Protocols AINS Project review, Aug 4, 2004

Description:

Students: Yeng Lee, JS Park, Guang Yang, Kelvin Zhang, Alok Nadan, Jiwei Chen, ... TCP Westwood; CapProbe; Ad Hoc Probe. Adaptive video streaming: ... – PowerPoint PPT presentation

Number of Views:36
Avg rating:3.0/5.0
Slides: 30
Provided by: yengzh
Category:

less

Transcript and Presenter's Notes

Title: Scalable Network and Transport Protocols AINS Project review, Aug 4, 2004


1
Scalable Network and Transport Protocols AINS
Project review, Aug 4, 2004
  • PI Mario Gerla
  • Students Yeng Lee, JS Park, Guang Yang, Kelvin
    Zhang, Alok Nadan, Jiwei Chen, Ling Jhy Chen,
    Tony Sun
  • Post Doc JJ Kong
  • CS Dept,UCLA
  • Network Research Lab
  • gerla_at_cs.ucla.edu
  • http//www.cs.ucla.edu/NRL

2
The challenges
  • Tens of thousands of (mobile) nodes
  • Group communications support
  • QoS requirements
  • Hostile environment
  • Project Goals
  • Scalable, robust and secure protocols (routing,
    multicast, TCP, video streaming)

3
Project Tasks
  • MAC Protocols
  • MIMO and Beamforming features
  • MIMO MAC SPACE MAC
  • Integration of MAC and Network Layer
  • Scalable Routing
  • Leverages group motion
  • Integration with mobile backbone
  • QoS support
  • Robust to mobility
  • Scalable Multicast
  • Team oriented, reliable multicast
  • TCP
  • fair behavior in an ad hoc environment (NRED)
  • TCP in mobile, disruptive environments
  • Delay tolerant delivery
  • TCP Westwood CapProbe Ad Hoc Probe
  • Adaptive video streaming
  • end to end and network feedback (VTP)
  • Security

4
What we will do with the left?
  • Delay tolerant networking
  • Robust transport (TCP, streaming) over mobile,
    unreliable nets
  • Will not do
  • Implementation of delay tolerant network
    protocols
  • Implementation of MIMO MAC protocols on MIMO
    radios
  • Integrated testing of video over dynamic, mobile
    nets
  • Integration with other efforts leading do
    integrated demo

5
TCP over Geo-routing in Mobile and Lossy Ad Hoc
Nets
Mario Gerla and Jiwei Chen
6
References
  • Brad Karp and H.T. Kung GPSR Greedy Perimeter
    Stateless Routing for Wireless Networks, Mobicom
    2000
  • M. Zorzi, R.R. Rao, Geographic Random
    Forwarding (GeRaF) for ad hoc and sensor
    networks energy and latency performance,'' IEEE
    Trans. on Mobile Computing, vol. 2, Oct.-Dec.
    2003
  • H. Dubois Ferriere et al Age Matters Efficient
    Route discovery in Mobile Ad Hoc Networks Using
    Encounter ages, Mobihoc June 2003

7
Georouting - Key Idea
  • Each node knows its geo-coordinates (eg, from GPS
    or Galileo)
  • Source knows destination geo-coordinates it
    stamps them in the packet
  • Geo-forwarding at each hop, the packet is
    forwarded to the neighbor closest to destination
  • Options
  • Each node keeps track of neighbor coordinates
  • Nodes know nothing about neighbor coordinates

8
Geo routing key elements
  • Greedy forwarding
  • Assume each nodes knows own coordinates
  • Source knows coordinates of destination
  • Greedy choice select the most forward node

9
Finding the most forward neighbor
  • Beaconing periodically each node broadcasts to
    neighbors own MAC ID, IP ID, geo coordinates
  • Each data packet piggybacks sender coordinates
  • Alternatively (for low energy, low duty cycle
    ops) the sender solicits beacons with neighbor
    request packets

10
Got stuck? Perimeter forwarding
11
Greedy Perimeter Stateless Routing (GPSR)
D is the destination x is the node where the
packet enters perimeter mode forwarding hops are
solid arrows
12
Case 1 vertical motion(nodes in each column
move up and down)
13
TCP over GPSR and AODV
Throughput (Kbps)
Speed(m/s)
14
Case 2 Random Motion
40 nodes in 1000mx1000m
15
TCP over GPSR, AODV, DSR and DSDV
Throughput (Kbps)
Speed(m/s)
16
Conclusions
  • Georouting is very robust to mobility
  • In a dense network, even when nodes move, there
    is always a neighbor in the right direction
  • TCP is extremely sensitive to path breakage
    (timeouts etc)
  • It does very well with georouting
  • Caveat georouting requires knowledge of
    destination geo coordinates

17
Direction forwarding for mobile, large scale
ad hoc networks
  • Mario Gerla, Yeng-Zhong Lee, Biao Zhou, Jason
    Chen
  • UCLA, CSD, Los Angeles CA
  • Antonio Caruso
  • University of Lecce, Italy

18
Distance Vector routing
  • Main routing scheme in the Internet
  • It is the foundation of all dissemination/advertis
    ing based schemes
  • LANMAR, AODV, DSDV, Directed Diffusion etc
  • It consists of dissemination of scouting pkts
    from sink this forms a Tree
  • the source follows shortest path in the grid

19
Distance Vector not robust to mobility
  • In Distance Vector Routing, node keeps pointer to
    predecessor

DV update
Predecessor
Data flow
Source
Sink
  • When the predecessor moves, the path is broken
  • Alternate paths, even when available, are not
    used
  • Current solution is to refresh more frequently -gt
    O/H!!!
  • Proposed solution direction forwarding

20
Direction Forwarding
  • Distance Vector update creates not only
    predecessor, but also direction entry

DV update
Predecessor
Data flow
Source
Sink
Direction to Sink
  • Select most productive neighbor in forward
    direction
  • If the network is reasonably dense, the path is
    salvaged

21
Direction Forwarding Protocol in action
Distance Vector advertisement
The direction to the sink
Data flow
Compute directions to the sink
Sink
Source
Data packet forwarding
If a predecessor to the sink is available, data
packets are routed directly to the predecessor
Else, data packets are direction forwarded to
the most productive node in the indicated
direction of the destination
22
How to compute the direction
  • Need stable local orientation system (say,
    virtual compass) to determine direction of update
  • GPS will do (e.g., neighbors exchange (X, Y)
    coordinates)
  • But, if I have GPS, I may as well use Geo Routing
    (more later)
  • Several non-GPS coordinate system have been
    recently proposed
  • Sextant Mobihoc 05 beacon DV RFIDs etc
  • Local (rather than global) reference is required
  • Local reference system must be refreshed fast
    enough to track avg local motion

23
Computing the direction(cont)
  • Compute direction to a destination when DV
    updates are received
  • The direction to the predecessor is used as the
    direction to the destination
  • If multiple DV updates received from different
    predecessors with same hop distance and seq
    for the destination
  • Take vector sum of directions
  • If a DV update packet with a more recent Seq or
    smaller hop distance is received
  • New direction replaces the old one

24
Computation of the direction
  • Suppose node A receives DV update packets from B
    C
  • Compute the directions to predecessors node B
    C, respectively,

Where the polar angle is the radian from the
x-axis that is used as the direction of the
predecessor node.
Directions to predecessors
Computation of the direction
  • Unit vectors are used to combine the two
    directions

25
Putting it all together
  • Apply the Distance Vector concept
  • A node saves not only the predecessor ID, but
    also the direction to the predecessor
  • Compute the direction to the predecessor based
    on local coordinate system
  • RFIDs or GPS
  • The direction can be used as a direction to
    destinations whose DV information are forwarded
    effectively by the predecessor.
  • Update the direction" to a destination
  • if more than one DV update packet received from
    different predecessors with same hop distance
    and seq for the destination
  • All directions to the destination combined by
    using the addition of unit vectors
  • If a DV update packet with a new Seq or smaller
    hop distance to the destination is received from
    a predecessor
  • The direction of the destination will be reset
    and then computer the direction to the
    predecessor.
  • Packet Forwarding Procedure
  • if a predecessor of a packet destination is
    found, the packet is routed directly to the
    predecessor
  • OW, the packet is direction forwarded to the
    most promising node in the indicated direction
    of the destination.

26
Illustration of the caches and routing tables
  • Two caches cache of neighbors coordinates and
    cache of Direction
  • Two routing tables Local routing table (LS)
    remote routing table (DV)

27
Illustration of the procedure for routing a data
packet
28
Direction Forwarding vs Geo routing
  • Geo-routing
  • Direction points to destination
  • This direction may be unfeasible (holes, etc)
  • Global geo-coordinates (eg, GPS)
  • Geo Location Server
  • Robust to mobility
  • Directional Forwarding
  • Direction of updates (always feasible)
  • Local position reference system
  • Advertisements from destination
  • Robust to mobility

29
Case study apply Direct Forwarding (DFR) to
LANMAR Routing
  • LANMAR builds upon existing routing protocols
  • (1) local routing algorithm that keeps
    accurate routes within local scope lt k hops
    (e.g., OLSR, FSR)
  • (2) Landmark routes advertised to all mobiles
    using a Distance Vector approach

30
LANMAR (cont)
  • A packet to local destination is routed
    directly using local tables
  • A packet to remote destination is routed to
    Landmark corresponding to logical address
  • Once the landmark is in sight, the direct route
    to destination is found in local tables.

31
LANMAR DFR
  • LANMAR has proved to be very scalable to size
  • However, as speed increases, performance
    degrades, even with group mobility!
  • Problem was traced to failure of DV route
    advertising in high mobility
  • We first tried to refresh more frequently it did
    not work!
  • Next step try DFR

32
How to route in LANMAR DFR?
  • Local Link State (LS) Routing Table
  • The packet is routed directly to a predecessor if
    the packet destination is within its 2-Hop scope
  • How to select the best forwarder if more than one
    is available?
  • DV Routing Table for remote destinations
  • If a predecessor of the destination is found, the
    packet is routed directly to the predecessor.
  • Else, the packet is direction forwarded to the
    most promising node in the indicated direction
    of the destination.
  • How to select a next hop along the direction of
    the destination?

33
Local routing Next-hop selection using a
robust shortest path
  • Link State routing in a 2-hop scope
  • First available path with shortest distance
  • vs.
  • the longest link is the minimum over all
    available paths.

34
"Direction" Fine tuning
  • Direction forwarded to the most promising
    node in the indicated direction of the
    destination.

Suppose A has data packets needed to be sent to
Node D, but predecessor C moves away
  • A simple selection of the most forward node may
    lead to a loop (e.g., A loop between A B)
  • Find a virtual destination among 2-hop neighbors
    based on direction at reference points
  • Consult the local routing table and find an
    efficient next hop (E) to the virtual
    destination.
  • the next hop is the most promising for the
    destination

A Loop between node A and node B
Next Hop
Virtual destination
Reference point
35
Simulation Experiments
  • Simulator QualNet 3.8
  • Standard IEEE 802.11 radio with a channel rate of
    2Mbps and transmission range of 367 meters.
  • Network field size 2250m by 2250m
  • LANMAR is the protocol hosting DFR
  • 225 nodes (or 360 nodes) equally distributed in 9
    groups
  • Mobility model Group Mobility model
  • Traffic CBR, 1 packets/sec, 512 bytes/packet
  • The of source-destination pairs is varied in
    the simulations to vary the offered traffic load

36
Simulation Results (cont)
  • Metrics
  • 1) Data packet delivery ratio 2) Aggregated
    throughput
  • 3) Average end-to-end packet delay 4) Routing
    overhead in kbit/s
  • Two sets of experiments
  • (1) Performance as a function of speed
  • Varying mobile speed from 0m/s to 16m/s
  • (2) Performance under varying loads
  • Varying of CBR connections from 20 to 80

37
Performance as a function of speed
DFR
LANMAR
Delivery ratio vs. speed (Including packet loss
due to disconnected destination)
38
Performance as a function of speed (cont.)
DFR
LANMAR
Delivery ratio vs. speed (Excluding packet loss
due to disconnected destination)
39
Performance as a function of speed (cont.)
Aggregated throughput vs. speed
40
Performance as a function of speed (cont.)
LANMAR
DFR
Average data packet delay vs. speed
41
Performance as a function of speed (cont.)
LANMAR
DFR
Routing overhead in kbit/s (per node) vs. speed
42
Performance under varying loads
Delivery ratio vs. traffic load (excluding packet
loss due to disconnected destination)
43
Performance under varying loads (cont.)
Average data packet delay vs. traffic load
44
Performance under varying loads (cont.)
Average routing overhead in kbit/s (per node) vs.
traffic load
45
Conclusions and Future Work
  • DFR new forwarding strategy for table driven
    routing
  • Direction Forwarding can improve LANMAR
    performance dramatically at high speeds
  • Future Work
  • Test LANMAR DFR under local reference system
  • Apply DFR concept to AODV
  • TCP over LANMAR, AODV DFR
  • Compare DFR with other backup route schemes
  • Test DFR under more general mobility models

46
  • Thank You !!!
  • http//www.cs.ucla.edu/NRL
Write a Comment
User Comments (0)
About PowerShow.com