HUMBOLDT-UNIVERSITÄT ZU BERLIN
COMPUTER SCIENCE DEPARTMENT
Systems Architecture Group

Head: Prof. Dr. Jens-Peter Redlich
Secretary:  Silvia Schoch
Phone: +49(30)2093-41150

 

     

Berlin Roof Net (BRN)

Contacts:  Prof. Jens-Peter Redlich, Dipl. Inf. Anatolij Zubow.

Abstract:

Wireless multi-hop mesh networks play an increasingly important role as backbones for sensor networks and as community networks that provide Internet access in urban areas. The MIT RoofNet project (http://www.pdos.lcs.mit.edu/roofnet/) has demonstrated that it is possible to supply a large city, such as Boston, with IP network access over an 802.11-based wireless mesh network. The Berlin Roof Net project investigates if a similar (even larger) network can be setup in the city of Berlin and whether such a network can be build in a completely self-organizing/self-configuring way. The Berlin Roof Net project is run by volunteer students of the Computer Science Department at Humboldt University Berlin. Mesh nodes are run independently by the students with their own equipment.

Realizing a wireless mesh network turns out to be non-trivial. One of their biggest challenges is the insufficient scalability with increasing number of nodes and users. The most important reason for this phenomenon can be found in the structure of a multi-hop network: a node is responsible not only for the transmission of its own data, but also for forwarding packets of other nodes. No less significant is the fact that wireless network nodes in close proximity interfere with each other because they share the same medium. With the help of our Berlin RoofNet testbed we can develop, test and evaluate new routing protocols for wireless multi-hop mesh networks (e.g. MCExOR protocol).

A community network must be usable for inexperienced end users; thus self-organization is essential. On the one hand, we are working on protocols for ad-hoc wireless multi hop mesh networks, where the client is fully freed from such mundane tasks as IP configuration, etc. On the other hand, the community mesh network itself shall be fully self-organized thus no operator or provider is required.

BRN Technology Attributes:

Typical architecture of a wireless mesh network like the BRN.

Indoor Testbed at the Computer Science Department of Humboldt University Berlin.

    The Berlin Roof Net is ...

  • an ad-hoc network
    The network evolves spontaneously, without explicit prior planning. It does not require (and does not have) a central administrative authority, like an operator. The structure/topology of the network is controlled by factors outside the BRN technology (i.e. there is no operator to determine optimal placement of nodes, who would deploy nodes at those locations). Network topology can change suddenly, as a result of un-announced and un-coordinated actions of individual nodes (i.e. there is no operator to ensure that nodes abide by previously agreed rules or follow strategies).
     
  • a wireless network
    BRN nodes (access points) communicate wirelessly with each other and with client stations, such as laptops. Inexpensive Commercial Off-The Shelf (COTS) hardware is used, such as IEEE 802.11g WLAN, that operates in the unlicenzed radio spectrum, such as the 2.4 GHz ISM band.
    Option: Some links may be wired (e.g. Ethernet), but without changing the nature of the network.

     
  • a 2-tier network
    A BRN network has 2 types of nodes: BRN nodes (BRN wireless routers) and STA nodes (e.g. laptops). Tier 1: BRN nodes communicate with other BRN nodes using a proprietary BRN protocol, to form the network's core/backbone. Tier 2: BRN nodes and STA nodes communicate with each other according to the IEEE 802.11 specification (where the BRN node assumes the role of the access point). There are no direct communication links between STA nodes.
    Note: No BRN software is required on STA nodes - those are regular 802.11 client's (e.g. laptops) without any modifications for BRN. BRN nodes run our proprietary software.

     
  • a multi-hop network
    A BRN network covers areas that are potentially larger than the length of an IEEE 802.11 communication link, i.e. some nodes are not able to communicate directly. In such case a message needs to be transmitted in multiple steps (hops) from one node to the next, along a forwarding path, until it reaches its intended destination. Each node may assign priorities to packets when performing forwarding functions.
     
  • a mesh network
    A 'mesh' is a specific network structure where there (usually) exist multiple paths between any two nodes. Mesh networks are usually multi-hop networks, but multi-hop networks are not necessarily mesh-networks (alternatively, they could be star / bus / ring / tree -structured networks).
     
  • a layer-2 network
    Tier 1 of a BRN network is like a huge (virtual) Ethernet Switch: It receives Ethernet frames from a source STA and delivers them to the appropriate destination STAs (on tier-2). The process of forwarding Ethernet frames inside the BRN core (tier 1) is transparent to STA clients. Its is, however, more intelligent than flooding along spanning trees (IEEE 802.1d) and may include support for VLANs in the near future. Since BRN acts like a (virtual) Ethernet switch, it is agnostic to layer 3 protocols (i.e.  it can support any of IPv4, IPv6, Appletalk, ...).
     
  • a de-centralized system
    BRN services are provided by (large groups of) cooperating BRN nodes. Every BRN node makes a small contribution to a service, but without the service depending on any individual node. Every BRN node may be switched off, without prior notice, without significantly disrupting the service (however, a service might be disrupted and data might be lost if too many nodes disappear simultaneous). Consequently, BRN has no central servers, not even for basic services like DHCP, DNS or file storage.
     
  • a self-organizing system
    The BRN network does not have the benefit of an (intelligent, human) operator who can configure the network and monitor its ongoing operation. BRN nodes discover neighboring BRN nodes automatically and integrate them, automatically, into the BRN network. Configuration parameters are determined (and later adjusted) automatically, through auto-config or zero-config mechanisms, i.e. without help from a human administrator. BRN networks (must) adjust to changes in the environment automatically.
    Note: This includes harmonization of the software versions on the individual BRN nodes.
     
  • an opportunistic system
    A BRN network tries to take advantage of BRN nodes which happen to be in its vicinity (in communication range). Resources are not previously calculated, allocated or provisioned. Rather, BRN tries to do its best with what it currently finds is available. Owners of BRN nodes usually don't know each other and do not coordinate their actions (such as installing a BRN node). If, by chance, a sufficient number of nodes happen to be available in an area, the opportunity to establish a BRN network presents itself, of which the BRN nodes spontaneously take advantage (obviously, this only works with powerful self-organization mechanisms - see previous paragraph). Nodes may join or leave suddenly, as a result of un-announced and un-coordinated actions of individual node owners.
    Note: This is in contrast to planned deployments, where the placement of nodes is planned in advance, and only those planned-for nodes are used.
     
  • NOT a high mobility network
    There are limits on the speed at which the network may dynamically change its topology. BRN nodes may move slowly; they may be added/removed to/from the network at a "decent frequency". The network will automatically and quickly reconfigure to adjust for added/removed nodes. However, there are limits on how quickly this adaptation can be done. BRN nodes inside fast moving cars, or large numbers of BRN nodes being added/removed every second, would be beyond the capabilities of current BRN technology.
     

Hardware used by the BRN:

    

Applications:

Nuggets:

Publications:

  • SAR-PR-2006-11
    Multi-Channel Opportunistic Routing in Multi-Hop Wireless Networks. Anatolij Zubow, Mathias Kurth, Jens-Peter Redlich, 20 pages.
    [SAR-PR-2006-11.pdf] [Abstract]
  • SAR-PR-2006-10
    Self-Organization in Community Mesh Networks: The Berlin RoofNet. Robert Sombrutzki, Anatolij Zubow, Mathias Kurth, Jens-Peter Redlich, Proceedings of IEEE OpComm2006, 11 pages.
    [Release Pending] [Abstract]
  • SAR-PR-2006-02
    Multi-Channel Link-level Measurements in 802.11 Mesh Networks. Mathias Kurth, Anatolij Zubow, Jens Peter Redlich. IWCMC 2006 - International Conference on Wireless Ad Hoc and Sensor Networks, Vancouver, Canada, July 3-6, 2006.
    [Release Pending] [Abstract]
  • SAR-PR-2006-01
    Development of a Software Distribution Platform for the Berlin Roof Net (Diplomarbeit / Masters Thesis). Bernhard Wiedemann. 73 pages.
    [SAR-PR-2006-01.pdf]

Legal disclaimer. .  © 2024 Humboldt-Universität zu Berlin, Computer Science Department, Systems Architecture Group. Contact: sar@informatik.hu-berlin.de .