Gateway Selection in Rural Wireless Mesh Networks

http://www.octavetech.com/blog/wpcontent/uploads/2008/03/long-range-wireless.jpg

Team: Lara Deek, Arvin Faruque, David Johnson

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)

Image from http://www.cse.iitk.ac.in/users/braman/dgp.html

OLPC Project: Each XO-1 will operate as a WMN node

Image from http://laptop.org/en/lapto p/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)
A B F

D C G X E

A wants to reach X

B.A.T.M.A.N. (2)

A:10 A B F

A:9 C

D G X E

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)
A B A:8 D C A:7 G X E D Final routing table TO A VIA B F

A:7
D BATMAN routing table TO A 8 A 7 C VIA B Q

B.A.T.M.A.N. (4)
A B A:0 F

D C A:4 E G BATMAN routing table TO A VIA D Q

A:6 G A:7 X

G Final routing table TO A VIA E

6
A 7 E

B.A.T.M.A.N. (5)
A
B F

D C G

A:5
X

E X BATMAN routing table TO A VIA G Q

A:6 X Final routing table TO A VIA E

5
A 6 E

B.A.T.M.A.N. (6)
A B F

D C G X E X BATMAN routing table TO A VIA G Q E BATMAN routing table TO A 7 E 6 A 4 D VIA C Q C BATMAN routing table TO A VIA A Q

5
A

Current GW selection techniques

GW2

Minimum hop count to gateways Used by routing protocols like AODV Creates single over congested gateways

D C E G X

GW1

Current GW selection techniques

GW2 2 F 1 3 C D G 1 X

2.2 A 1.5 B

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

GW1

Current GW selection techniques

256 kbps GW2 9 F 4 3 C 8 D G 7 E 10 512 kbps GW1 X

10 A 7 B

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

Proposed Solution: Introducing intelligence to the core of the WMN

Introduce information about gateway performance into the network

Nodesatintelligenceboundaryhavegatewayperformanceinformation,needto transfer this information to the other nodes Transferthisinformationvia:Batsignalpacketsthatarefloodedthroughthenetwork

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:

Pr ospective_ VPN _ Capacity

Total _ Capacity # VPNs 1

Example:

1 Pr ospective_ VPN _ BW Total _ BW 3

1 Pr ospective_ VPN _ BW Total _ BW 2

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

Proposed Solution: Batsignals

1. 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 Forward a received bat-signal to its neighbors (if it has not expired) Update their own gateway preference tables

2.

All other nodes

Batsignal Packet
Field GWID TS DB VPNs TTL Description Gateway ID (0-255) Time stamp

Node Gateway Preference Table

GWID 1 Metric Total down BW # VPNs Timestamp

Total download bandwidth Number of VPNs on gateway Packet time to live Etc

Proposed Solution: Using Batsignal data to pick a gateway

Gateway Preference Table
GWID 1 Etc Metric Total down BW # VPNs Timestamp

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

GW _ Capacity Link _ Quality # VPNs 1 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) Metric

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 GWs. 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