The Berlin RoofNet ProjectJ.-P. Redlich, A. Zubow, M. Kurth, R. Sombrutzki, J. Müller, M. Jeschke. Contact: zubow@informatik.hu-berlin.de.

IntroductionWireless multi-hop mesh networks play an increasingly im-portant role as community networks that provide Internet access in urban areas. A wireless community mesh net-work consists of nodes (mesh nodes and associated cli-ents) connected by wireless links. The nodes are free to or-ganize themselves arbitrarily; thus, the network’s wireless topology may change rapidly and unpredictably. Therefore self-organization is one of the key success factors.

Wireless Community NetworksIn the scenario of a wireless community multi-hop mesh network the households are equipped with so-called mesh nodes, which form the mesh network.

Internet

DSL

WiMax

MeshNetwork

Mesh node(BRN)

Client station(STA)

Typically only a subset of mesh nodes is directly connected to the Internet. These gateway nodes share their Internet access with other nodes in order to provide Internet con-nectivity to all participants. Therefore mesh nodes forward packets to the Internet gateways in a multi-hop fashion. End users use off-the-shelf devices like notebooks and PDAs to interact with the network.

Self-Organization as Main Requirement A community mesh network must be usable for inexpe-rienced end users. In practice, the user should not care about the problem of IP address allocation, Internet gate-way selection and software distribution. The goal is to of-fer an approach, where the client is doing no confi guration except to connect to the network [2].In order to achieve full self-organization, the following prob-lems must be addressed. Nodes may spontaneously join or leave; the mesh network should be able to react to struc-tural changes (unplanned growth). Resources needed for operation are not previously calculated and allocated. Fur-thermore, a central authority is not available, i.e. all serv-ices must run in a decentralized manner. This way the role of the operator changes from administration and mainte-nance to a provider for services like charging, billing, etc.

ArchitectureThe BRN [1] could be characterized as a wireless ad-hoc multi-hop mesh network. It has a 2-tier architecture: On the fi rst tier there is the BRN core network consisting of BRN mesh nodes and there are client stations on the sec-ond tier. This approach leads to two types of links: links between mesh nodes use BRN protocol, whereas IEEE 802.11 is used for links between client stations and mesh nodes. The advantage of this approach is that client sta-tions do not have to be modifi ed.

The BRN uses a rout-ing protocol based on Dynamic Source Routing (DSR) [3] enhanced with ETX [4] metric. It oper-ates on layer 2 and is therefore layer-3 agnostic. From the client’s point of view

the BRN network looks like a huge virtual Ethernet switch, i.e. it relays Ethernet frames from client stations.

Software Distribution PlatformIn the BRN the Software Distribution Platform (SDP) auto-matically updates all mesh nodes when new software be-comes available. It does not rely on any other service, in-stead a simple and robust infection-like algorithm is used. Each node periodically announces its software version. An out-of-date neighbor requests the new software via Trivial File Transfer Protocol (TFTP).

Self-Organization through P2PPeer-to-peer (P2P) systems are distributed systems with-out any centralized control. P2P systems offer advantages in scalability, robustness and availability. We based our so-lution on Chord [5], a distributed hash table (DHT) for fi le storage. DHT-based Realization of DHCP, ARP and GatewayIf a client station wants to communicate with another station it creates an ARP request to resolve the other’s MAC ad-dress. In BRN client stations do not communicate directly with each other. Instead they use mesh nodes, which in-tercept all ARP requests and resolve it using the DHT.

Client station Mesh node DHTARP request

DHT read

DHT replyARP reply

After a client station associates with one of the mesh nodes it tries to obtain an IP address using DHCP. The mesh nodes provide a distributed DHCP service, whereas the data is stored in the DHT.

Client station Mesh node DHTDHCP discover

DHT readDHT reply

DHCP offerDHCP request DHT write

DHT replyDHCP ACK

Furthermore, Internet gateways along with its metrics are stored in the DHT using a well-known key. All incoming packets with destination IP addresses outside the BRN are routed to gateways: the mesh node queries the DHT for the gateway key resulting in a list of available gateways, from which the gateway with the best metrics is chosen.

Evaluation in our TestbedFor the evaluation in a real world environment we used our campus testbed. The tests demonstrated the practical feasibility of our approach and validated the simulation outcomes. As mesh nodes we are using Netgear’s WGT634u router (MIPS/200MHz, 32MB RAM, Atheros IEEE 802.11b/g wifi card). The MIT’s Click-API is used as the basis for our routing protocols and services.

Services like ARP, DHCP, Gateway make use of the DHT which itself relies on routing. Only the software distribution sys-tem is independ-ent from routing and DHT.

The BRN testbed consists of nearly 50 most-ly indoor mesh nodes. It is used to validate results obtained from simulations in real world. Furthermore, the testbed is used by the students of the Humboldt University for internet access as well as for VoIP. There-fore a Virtual Private Network (VPN) solu-tion especially for mesh networks was de-signed and implemented.

Simulation ResultsWe used the network simulator (ns2) together with the Click-API for ns2 (NSClick). We chose the two-ray ground radio propagation model. Furthermore, the medium access is coordinated using the DCF of IEEE 802.11. The bit-rate was set to 54Mbit/s. The simulation scenario consists of a number of mesh nodes, to which a number of client sta-tions are connected to. Each client obtains an IP address via DHCP and periodically issues ARP requests.

Conclusions & Future WorkServices like DHCP, ARP, Internet gateway and SDP are necessary to achieve self-organization in wireless commu-nity mesh networks. We presented effi cient realizations of these services using a DHT. Furthermore, with the help of simulations and an evaluation in the BRN testbed we showed that using a DHT to realize services like DHCP and ARP that otherwise had used ineffi cient algorithms like fl ooding make sense and lead to more reliable, effi cient and responsive solutions. Our future work will concentrate on the realization of additional services like DNS as well as DHT improvements like the detection of node malfunc-tions and redundancy.

References[1] Berlin RoofNet Project. www.berlinroofnet.de. 2006.[2] Hattig. ZeroConf Requirements. Internet Draft. 2001.[3] Johnson, Maltz. Dynamic source routing in ad hoc wire-less networks. Mobile Computing, volume 353, 1996.[4] De Couto. High-throughput routing for multi-hop wire-less networks, 2004.[5] Stoica, Morris, Karger, Kaashoek, Balakrishnan. Chord: A scalable Peer-To-Peer lookup service for internet appli-cations. 2001.

The DHT-based approach outperforms traditional ap-proaches like fl ooding on the string topology (left). It has a higher response ratio, needs fewer transmissions, re-sponds faster and fewer packets collide. The simulation results using the grid topology (above) confi rm our obser-vations about the reliability and traffi c load from the string scenario. Again, the DHT needs fewer transmissions, pro-duces fewer collisions and is able to respond faster to an ARP request in relation to fl ooding.

MeshNode

ClientStation

Wireless Link

Mesh Network

2 4 16 25 36 49 640.7

0.8

0.9

1

Number of Nodes

Req

uest

/Res

pons

e R

atio

2 4 16 25 36 49 640

20

40

60

80

Number of Nodes

Pack

ets

per R

eque

st

2 4 16 25 36 49 640

0.5

1

1.5

2

2.5

3x 105

Number of Nodes

Col

lisio

ns

0 50 100 150 200 2500

0.2

0.4

0.6

0.8

1

Response Time

CD

F of

Res

pons

e Ti

me

DHT−25DHT−36DHT−49DHT−64Flooding−25Flooding−36Flooding−49Flooding−64

DHT−1DHT−4Flooding−1Flooding−4

DHT−1DHT−4Flooding−1Flooding−4

DHT−1DHT−4Flooding−1Flooding−4

(a) Request to Response Ratio (b) Number of Packets per Request

(c) Total number of Collisions (d) Distribution of Response Time

2 4 6 8 100.9

0.92

0.94

0.96

0.98

1

1.02

Number of Nodes

Req

uest

/Res

pons

e R

atio

2 4 6 8 100

5

10

15

Number of Nodes

Pack

ets

per R

eque

st

2 4 6 8 100

200

400

600

800

Number of Nodes

Col

lisio

ns

0 50 100 150 200 2500

0.2

0.4

0.6

0.8

1

Response Time (ms)

Cum

ulat

ive

Frac

tion

of R

eque

sts

DHT−1DHT−4DHT−16Flooding−1Flooding−4Flooding−16

DHT−1DHT−4DHT−16Flooding−1Flooding−4Flooding−16

DHT−1DHT−4DHT−16Flooding−1Flooding−4Flooding−16 Flooding−4

Flooding−8Flooding−10DHT−4DHT−8DHT−10

(a) Request to Response Ratio (b) Number of Packets per Request

(c) Total number of Collisions (d) Distribution of Response Time

www.berlinroofnet.de