Download A Routing Protocol for k

A Routing Protocol
for k-hop Networks
William List & Nitin Vaidya
University of Illinois – Urbana Champaign
Outline






Observations
Goals
The k-hop
Architecture
Routing
Simulations
Results
5/25/2017




Analysis
Conclusions
Related Work
Testbed
A Routing Protocol for k-hop Networks
2
Motivation

Ad-hoc networks are better-suited as "range
extensions” for wired networks
 Performance decreases as paths get longer
 Latency
 Overhead
 Success rate
 Most evident in highly dynamic networks

Wireless LANs are cheap and can be extended to
multiple hops for increased coverage
 Reduce
5/25/2017
dead spots in the network
A Routing Protocol for k-hop Networks
3
Goals

Assuming a network with a bound placed
on wireless paths, we would like to
 Improve

Even in high mobility scenarios
 Reduce

latency
Particularly for initial route setup
 Operate
5/25/2017
path reliability
with low overhead
A Routing Protocol for k-hop Networks
4
More Goals

Design and implement a testbed to verify
the feasibility of experimental routing
protocols
5/25/2017
A Routing Protocol for k-hop Networks
5
The k-hop Architecture

A k-hop network is a network that
 Supports
a maximum of k hops between two
wireless clients or a wireless client and a
gateway
 2k wireless hops possible if both wireless
endpoints are far apart and using gateways
 A mobile client is in-network if

5/25/2017
Within k-hops distance from a gateway AND there
is a mobile client to relay its packets
A Routing Protocol for k-hop Networks
6
Example k-hop Network (k=2)
Gateway
Mobile Clients
5/25/2017
A Routing Protocol for k-hop Networks
7
Routing




Want all mobile clients to be aware of their
surrounding gateways at all times
Want to support multiple paths to a destination
Want fast recovery in the case of route breakages
Two-tiered routing structure
 Between
mobile clients and between gateways
 What combination of pro/reactivity should we use?
5/25/2017
A Routing Protocol for k-hop Networks
8
Routing cont.

Gateways share information about routes to
mobile clients via
 Message
exchanges or
 A shared memory space

Mobile clients store learnt paths to gateways in
its Gateway List (GL)
 Think

of as multiple “default” routes
Use AODV-style sequence numbers to keep
messages in-order
5/25/2017
A Routing Protocol for k-hop Networks
9
Beaconing

A way for a gateway to notify all nearby
mobile clients of its presence.
 Periodic
(every x seconds)
 Broadcast up to k hops using a counter-based
scheme

Which mobile clients send a RREP
 Those
adding the gateway to their GL
 Those that have ongoing connections
5/25/2017
A Routing Protocol for k-hop Networks
10
Route Discovery (Mobile Client)
If route exists, send data right away
 Else, broadcast RREQ with TTL=k

 If
no reply, forward data packets to nearest
gateway
 If no gateway is known, send a special RREQ
to discover new gateways
5/25/2017
A Routing Protocol for k-hop Networks
11
Route Discovery (Gateway)

When data packets arrive
 Look
up shortest path in the global routing
table and forward packets

If path is stale at remote gateway

 If
It sends out a new RREQ for the destination to acquire
fresh path
no path is known or stale path is invalid
Page – RREQ sent by all gateways with TTL=k
 If destination is in-network, it should respond

5/25/2017
A Routing Protocol for k-hop Networks
12
Route Discovery cont.

Resulting connection is
 Local
if a direct path is found
 Remote if a gateway is used

Connection can migrate from remote to local
 A route
is overheard to the destination as a byproduct
of beaconing
 Gratuitous RREP sent to the destination to establish
reverse path
5/25/2017
A Routing Protocol for k-hop Networks
13
Route Recovery (Mobile Client)

If the connection was remote
 Switch
to a different gateway
 If no other gateway is available, page for new
gateways

If the connection was local
First try to send a RREQ with k to find a new route to
the destination
 If no route is found, use a gateway; connection is now
remote

5/25/2017
A Routing Protocol for k-hop Networks
14
Route Recovery (Gateway)

If path to destination fails
 Forward
to different gateway that has path
If no other gateway has a path, send local RREQ
with TTL=k
 On failure have all gateways page for the
destination to see if it is in-network

5/25/2017
A Routing Protocol for k-hop Networks
15
Simulation Setup





ns2 simulator
100 mobile clients in 2400 m x 600 m area
Gateways every 600 m (300 m from edges)
Multiple mobility patterns
CBR traffic between mobile clients
 64
byte packets with 200 ms spacing (2.5kb/s)
 Similar to traffic loads in previous works

Comparison to DSDV for local routing
5/25/2017
A Routing Protocol for k-hop Networks
16
Metrics

Packet Delivery Ratio
 Number
of received packets / number of
packets sent

End-to-end Path Latency
 Time
it takes for a packet to reach its
destination

Routing Overhead
 Measured
5/25/2017
per node in the network
A Routing Protocol for k-hop Networks
17
Simulations

30 connections between mobile clients
 In
other words, 60% of mobile clients are in a
connection
k = 2 and k = 3
 Speeds of 1, 5, 10 and 20 m/s

5/25/2017
A Routing Protocol for k-hop Networks
18
Packet Delivery Ratio (%)
Packet Delivery Ratio
100
95
90
85
80
75
0
5
10
15
20
Mobility (m/s)
k-Hop (k=2)
5/25/2017
k-Hop (k=3)
DSDV (k=2)
A Routing Protocol for k-hop Networks
DSDV (k=3)
19
Overhead
Overhead per Node (kbps)
1.2
1
0.8
0.6
0.4
0.2
0
0
5
10
15
20
Mobility (m/s)
k-Hop (k=2)
5/25/2017
k-Hop (k=3)
DSDV (k=2)
A Routing Protocol for k-hop Networks
DSDV (k=3)
20
Packet Latency
Path Latency (s)
0.2
0.15
0.1
0.05
0
0
5
10
15
20
Mobility (m/s)
k-Hop (k=2)
5/25/2017
k-Hop (k=3)
DSDV (k=2)
A Routing Protocol for k-hop Networks
DSDV (k=3)
21
Analysis

Overall
 Higher
packet delivery success rate as
compared to DSDV
 Less overhead
 Slightly higher end-to-end packet latencies
Interesting optimization: skip the local RREQ step
and latency improves dramatically
 Tradeoff: Average path length tends to be slightly
longer, especially as k increases

5/25/2017
A Routing Protocol for k-hop Networks
22
Analysis cont.

Beaconing incurs high instantaneous contention
in the network
 Data
packets get dropped during this period
 Scalability an issue as the number of connections
increases


More mobile clients respond to beacons in order to keep
reverse paths fresh
Routing tables for mobile clients remain small
 Only
have to store paths to nearest gateway and per
active destination
5/25/2017
A Routing Protocol for k-hop Networks
23
Analysis cont.

Temporary non-optimal paths are possible
 Gateways
prefer newer routes over those that have
expired, even if they are longer




Can overwrite a perfectly valid shorter path
Problem of updating “too much”
Needs strict comparison to Hierarchical AODV
Not clear whether mobile clients should do a
local search first for route discovery
5/25/2017
A Routing Protocol for k-hop Networks
24
Analysis cont.

Many variables that can be optimized
 Beacon
interval
 Count variable for broadcasting

Many variations that can be tested
 Route
recovery by all nodes
 Adding Multiple paths
 When to respond to a beacon
5/25/2017
A Routing Protocol for k-hop Networks
25
Conclusions
Supplementing an on-demand protocol
with pro-activity does not necessary
improve performance
 Extension of network only as good as the
density of mobile clients

 Inexpensive,
fixed relays could server better
as extensions
5/25/2017
A Routing Protocol for k-hop Networks
26
Conclusions cont.

Needs comparison with AODV/DSDV (or
FSR) implementations
 With/without

gateways, see related work
Overhead increases at high rate as the
number of end-to-end connections
increases
 As
seen when comparing to only 10
simultaneous connections
5/25/2017
A Routing Protocol for k-hop Networks
27
Conclusions cont.

Have to be careful with sequence numbers
when mixing paths to local destinations
and gateways
 Remember
that in a remote connection, the
source’s path to destination == gateway

Can get tricky when the destination moves within
local range
 Gotcha
– gateways passing data packets back
and forth for a destination
5/25/2017
A Routing Protocol for k-hop Networks
28
Testbed
Array of Linux laptops
 Framework written in C/C++.
 Adopts a modular approach to protocol
development
 Uses the ASL library to customize the
Linux kernel routing table.

5/25/2017
A Routing Protocol for k-hop Networks
29
Testbed Framework
User-space
Routing
Table
Kernel
ASL
Routing
Protocol
Engine
Packet
Dispatcher
Routing
Table
Sockets
TCP/IP
Stack
5/25/2017
Link
Manager
A Routing Protocol for k-hop Networks
Wireless
tools
30
Routing Protocol Engine





The core of the testbed that talks to other
components
Responsible for packet processing/creation
Controls routes with the User-space Routing
Table
Receives/sends packets from/to the Packet
Dispatcher.
Listens for events from the Link Manager.
5/25/2017
A Routing Protocol for k-hop Networks
31
Routing Table
Controlled by the Routing Protocol Engine
 Interfaces with the kernel routing table via
ASL

 ASL provides
functionality to
Capture outgoing packets with destinations not in
the kernel routing table.
 Insert/update/delete routes

5/25/2017
A Routing Protocol for k-hop Networks
32
Link Manager
Reports broken links to the Routing
Protocol Engine
 Can provides link information in some
cases, such as signal strength

 Uses
wireless tools event extensions
 Information received via a raw socket
5/25/2017
A Routing Protocol for k-hop Networks
33
Packet Dispatcher
Handles creation/management of UDP
sockets, including socket polling
 Able to send packets from the Routing
Protocol Engine and invoke callbacks for
packets it receives
 Event-driven model

5/25/2017
A Routing Protocol for k-hop Networks
34
Related Work

1997 – Y.B. Ko and N. Vaidya
 Super-MHs
(gateways) & Mini-MHs (clients)
 Multi-phase reactive route discovery process
Local flood (Super-MHs respond)
 Local flood by nearest Super-MHs
 Flood by ALL Super-MHs

 Time-intensive
5/25/2017
A Routing Protocol for k-hop Networks
35
Related Work cont.

2002 – K. Xu, X. Hong and M. Gerla
 LANMAR routing
(Local – FSR; Remote – DSDV)
 Clustering algorithm for backbone node (BN)
selection

Backbone nodes not the same as landmarks
 Mobile
nodes learn to route through BNs to take
advantage of shorter paths
 Relies on addresses to define subnets

5/25/2017
Mobile nodes must store entries for all nodes in the network
A Routing Protocol for k-hop Networks
36
Related Work cont.

2002 – C. Tschudin and R. Gold
 LUNAR is
simple protocol designed for
small-hop environments
5/25/2017
A Routing Protocol for k-hop Networks
37
Related Work cont.

2002 – K. Xu and M. Gerla
 Dynamic

Cluster-heads use long-range radios as backbone links
 Two

clustering algorithm
protocol combinations tested (intra/inter cluster)
AODV/AODV and DSDV/AODV
 DSDV/AODV
has lowest delay and highest packet
delivery success rate

5/25/2017
Note: clusters are single-hop, so DSDV does well
A Routing Protocol for k-hop Networks
38