gateway selection in rural wireless mesh networks team: lara deek, arvin faruque, david johnson ...
TRANSCRIPT
Gateway Selection in Rural Wireless Mesh Networks
Team: Lara Deek, Arvin Faruque, David Johnson
http://www.octavetech.com/blog/wp-content/uploads/2008/03/long-range-wireless.jpg
Introduction: Rural Wireless Mesh Networks (WMNs) A mesh network comprised of multiple, commodity devices that
provides Internet access to rural areas Topology differs from hub-and-spoke wireless networks
Applications: Education, health care Benefits: cost, robustness, infrastructure requirement
Introduction: Rural WMN Examples Digital Gangetic Plains (India)
OLPC Project:
Each XO-1 will operate as a WMN node
Image from http://www.cse.iitk.ac.in/users/braman/dgp.html
Image from http://laptop.org/en/laptop/hardware/specs.shtml
Introduction: Mesh Network Gateway Selection Mesh networks connect to the rest of the Internet via gateways Rural and municipal WMNs have different bandwidth constraints
• Municipal: bottleneck is wireless links
• Rural: bottleneck is at gateways
Problem: Inefficiently utilized gateways WMN can have severe consequences in rural areas
Our goal: modify an existing mesh routing protocol attempt to optimally select gateways
B.A.T.M.A.N.(1)
B F
C
A
E
D
X
G
A wants to reach X
B.A.T.M.A.N. (2)
B F
C
A
E
D
X
G
A:10
A:9
Nodes broadcast originator messages (OGM's) every second OGM's are rebroadcast Other nodes measure how many OGM's are received in a fixed
time window
B.A.T.M.A.N. (3)
B F
C
A
E
D
X
G
A:8
A:7
D BATMAN routing table
TO VIA QA B 8A C 7
D Final routing table
TO VIA A B
A:7
B.A.T.M.A.N. (4)
B F
C
A
E
D
X
G
A:6
G BATMAN routing table
TO VIA QA D 6
A E 7
G Final routing table
TO VIA A E
A:0
A:4A:7
B.A.T.M.A.N. (5)
B F
C
A
E
D
X
G A:5
A:6
X BATMAN routing table
TO VIA QA G 5
A E 6
X Final routing table
TO VIA A E
B.A.T.M.A.N. (6)
B F
C
A
E
D
X
G
X BATMAN routing table
TO VIA QA G 5
A E 6
E BATMAN routing table
TO VIA QA C 7
A D 4
C BATMAN routing table
TO VIA QA A 9
Current GW selection techniques
Minimum hop count to gateways
Used by routing protocols like AODV
Creates single over congested gateways
B F
C
A
E
D
XG
GW1
GW2
Current GW selection techniques
Best link quality to GW Used by
source routing protocols like MIT Srcr
Link state protocols like OLSR
Prevents congested links to GW
Not global optimum of GW BW usage
B F
C
A
E
D
XG
GW1
GW2
2.2
1.5
3
1
11
1
2
1
Current GW selection techniques
BATMAN has advanced a little further
GW can advertise downlink speed
User can choose GW selection based on GW with best BW Stable GW (need
history) GWBW x LQ
Can't trust advertised GW BW
Doesn't achieve fairness
B F
C
A
E
D
XG
GW1
GW2
10
7
3
10
4
9
7
256 kbps
512 kbps
8 7
Proposed Solution: Introducing intelligence to the core of the WMN Introduce information about gateway performance into the network
Nodes at “intelligence boundary” have gateway performance information, need to transfer this information to the other nodes
Transfer this information via: “Batsignal” packets that are flooded through the network
Proposed Solution: What does the boundary node measure? When nodes will select gateways, they will need to estimate the amount of bandwidth
they will get:
Example:
Hence, boundary nodes must transmit current total gateway bandwidth and current # of VPNs
Total gateway capacity is the sum of
• Measured extra bandwidth (measured through active probes)
• The sum of the current bandwidths of the VPNs
Prospective _VPN _Capacity Total _Capacity
#VPNs1
Prospective_VPN _BW 1
3Total _BW
Prospective_VPN _BW 1
2Total _BW
Proposed Solution: Batsignals1. A node at the intelligence boundary periodically
Record gateway measurement If the measurement is not drastically different than a previous value, then transmit a
Batsignal packet only if we have not recently transmitted a batsignal packet If the measurement is drastically different from a previous value, immediately transmit a
Batsignal packet
2. All other nodes Forward a received bat-signal to its neighbors (if it has not expired) Update their own gateway preference tables
Packet time to liveTTL
Number of VPNs on gatewayVPNs
Total download bandwidthDB
Time stampTS
Gateway ID (0-255)GWID
DescriptionField
Batsignal Packet Node Gateway Preference TableGWID Metric Total
down BW
# VPNs Time-stamp
1
Etc…
Proposed Solution: Using Batsignal data to pick a gateway
To choose a gateway, the following metric based on table data and link quality (computed only when current_time - timestamp is below a threshold) is used
Gateway flapping: When a gateway comes up and goes down frequently, a large number of conflicting Batsignal's will be broadcasted to the WMN nodes.
The VPN will not switch to another gateway until all the flows within it have terminated (Srcr)
Gateway Preference TableGWID Metric Total down
BW# VPNs Timestam
p
1
Etc…
Metric GW _Capacity
#VPNs1Link _Quality
Evaluation: UCSB Meshnet status
Evaluation: The massive mesh in South Africa
7x7 grid of 49 wireless nodes using 802.11 a/b/g radios
Each node network boots off a central server
Makes use of 30dB attenuators on radios to achieve multiple hops in small space
Has been used for extensive mesh network protocol benchmarking
Complete remote control of experiments possible
Evaluation Environment I
Parameters at the Gateway and Mesh Nodes Technologies Used
Load: traffic/congestion. Loss: signal weakness,
obstacles. Delay: . Bandwidth: of the available
communication channels between mesh nodes or between mesh nodes and gateways.
Throughput: between mesh nodes and a test server outside the mesh network.
tc: linux traffic control. iperf: TCP/UDP bandwidth
measurement tool. iptables: defines packet
processing schemes.
Evaluation Environment II
Metrics Measurement Methodology
Gateway efficiency: measures how effectively we match the throughput generated by the VPNs to the capacities of the gateways.
Gateway fairness: measures how fairly the aggregate gateway throughput is distributed among VPN flows.
Gateway Flapping: measures the frequency a mesh node switches between utilization of multiple gateways.
Measure VPN flows at each GW Have capacity of all GW’s.
Measure VPN flows. What is the time window? Average over time.
Parse BatSignals for each node and record the timestamp for each GW usage. How much hysteresis?
How are we using technologies to determine fundamental parameters?
Active Probing to determine GW throughput using a decentralized, distributed approach via trusted internet mesh nodes that form the intelligence boundary {B1, B2}.
Current Progress (from Proposal) We are in Week 4.
1. Formulate a set of preliminary evaluation metrics for the protocol. (Week 1 - Week 3). Done
2. Formulate a measurement procedure to test the efficacy of the protocol. (Week 1 - Week 2) Done
3. Emulate a gateway on a UCSB MeshNet node using Linux tools such as tc and iptables. (Week 2 - Week 3) Have developed scripts to control TC and iptables. Need to develop remote control for this script.
4. Run and evaluate the latest developers release of B.A.T.M.A.N. on the UCSB MeshNet. (Week 1 - Week 4) Have evaluated BATMAN on 3 mesh UCSB MeshNet nodes. Need to transition massive mesh (has been done before).
5. Implement solutions to Goals 1, 2, 3, and 4 and measure performance using the measurement process described in (2) and evaluation metrics described in (1) (Week 3 – Week 6) In progress, analyzing code.
Nifty Animations