Pre-deployed Decentralized Infrastructure

Besides rolling out additional infrastructure nodes on demand to create a wireless mesh net-work, the communication infrastructure can also be pre-deployed. Similar to the backbone-based concept, the wireless mesh routers are then installed on strategic locations as a precau-tion before a disaster strikes. In case of a disaster in that particular area, the infrastructure would be readily available. Disaster-affected areas that are not covered by such a network would be connected through additional roll-out infrastructure.

A pre-deployed decentralized infrastructure would be beneficial in regions where many people live, i.e., cities. In such regions, the infrastructure would be used for more than just disaster relief communication. Inhabitants could use the infrastructure for Internet access, for instance. Below, we present three prominent city-wide wireless mesh and community networking projects to be evaluated as supportive infrastructure in harsh environments. In general, such city-wide WiFi networks are also called municipal wireless networks and are primarily used to provide city-wide wireless Internet access.

MIT Roofnet project

One of the first experimental IEEE 801.11 mesh networks was the Grid Roofnet project on the campus of the Massachusetts Institute of Technology in Cambridge, MA [47]. The project started as a master’s thesis and developed into a production quality wireless ad-hoc network [6]. The resulting network provided broadband Internet access to users in Cam-bridge. In 2003, it consisted of over 35 nodes and covered an area of about two square kilometers. Each node of the Grid Roofnet project was a PC equipped with the Linux oper-ating system and two network interfaces: a wired network interface and a wireless network interface based on the IEEE 802.11b standard. The wireless network interface was con-nected to an omnidirectional antenna mounted on the roof of the building. These nodes were installed in several buildings of the MIT campus in Cambridge. They were intercon-nected, thus, creating the wireless mesh network from roof-to-roof. Several gateway nodes provided Internet access for the entire network.

The project used a proprietary routing protocol called SrcRR, based on the Dynamic Source Routing protocol (DSR) [99]. As opposed to the DSR protocol, SrcRR uses the Expected Transmission Count (ETX) metric to determine a route between two nodes. Access and transport of media is handled by the Extremely Opportunistic Routing (ExOR) algo-rithm [31]. Users were able to connect to each node and obtained an IP address to access the Internet. IP addresses were not routable, thus, network address translation (NAT) was used. A NAT allows multiple clients to access the Internet through a gateway node us-ing only one routable IP address. This also means that users connected to different Grid Roofnet nodes were not able to connect and communicate with to each other through the Grid Roofnet network.

The main goal of the Grid Roofnet network was to create a self-organized network for Internet access. The network was rather small and the project used specialized hardware to reach the goals. However, the project showed that mesh networks can cover a large geographical area with only few nodes if they are mounted on roofs.

3.1 Communication Infrastructure 25

Google WiFi

In Mountain View, CA, Google Inc. deployed a city-wide WiFi network for Internet ac-cess¹. The network consists of over 500 Tropos MetroMesh wireless routers. The routers are mounted primarily on city owned utility poles (i.e., light poles). Figure 7 shows the distribution of the Google WiFi routers in the city of Mountain View, CA². Google em-ployees, Citizens, and visitors can access the Internet via this mesh network. The service started in August 2006 and requires users to have a Google account. Connections can be established to the service set identifiers (SSID) “GoogleWiFi” (which has no encryption) or

“GoogleWiFiSecure” (providing WPA encryption). Google limits the data transfer rates to 1 Mbit/s per client.

Figure 7: Coverage Map of Google WiFi in Mountain View, CA (Screenshot)

In contrast to the Grid Roofnet network in Cambridge, NAT is not used in the Google WiFi network. Hence, every client receives a routable IP address from the DHCP Server. The IP address has a DHCP lease of one hour. The network uses a proprietary Tropos routing algorithm. There are three distinct wired gateways to access the Internet. All Internet traffic is routed to one of these three gateway nodes.

Afanasyev et al. measured the Google WiFi network in spring 2008 [4, 5]. Their findings about the mesh connectivity revealed that only 5% of the routers had a unique neighbor. The median router had at least four neighboring routers and 10% had more than eight neighbors.

1 Google WiFi website available online at http://wifi.google.com/. The “Google WiFi Terms of Service”

are available at http://wifi.google.com/terms.html (visited on April 3, 2014)

2 Screenshot taken from the “Google WiFi Mountain View Coverage Map” website: http://wifi.google.

com/city/mv/apmap.html(visited on April 3, 2014)

As of spring 2008, the network had between 1000 and 2500 simultaneously active users during the course of a single day. They produced roughly 500 Gbytes of data traffic. Further details of the network measurements can be obtain from the works of Afanasyev et al. [4, 5].

In 2007, Arjona and Takala from Nokia Networks investigated the Google WiFi network on its VoIP capabilities [13]. Their findings indicate the network to provide good link quality only in few spots, mainly in the downtown area. They state that the current router density is not sufficient for proper support of voice services.

As of the time writing this thesis, Google announced on their Google WiFi website (on April 3, 2014) to take down the WiFi network in Mountain View. They stated that the network would operate for 60 days (roughly until early May). They are planning to install a new outdoor WiFi network in downtown Mountain View, along Castro Street.

Freifunk

“Freifunk” networks are community driven networks provided and maintained by owners of wireless routers in cities and villages in Germany³. The Freifunk community is part of a global movement for free communication infrastructure and open frequencies. Their main goal is to provide a city-wide wireless mesh network to share files and services among citizens. Furthermore, Internet access can also be obtained through the Freifunk network provided community members share their Internet connection with the Freifunk community.

The most prominent and largest Freifunk networks in Germany are established in Berlin, Hamburg, Lübeck, and Leipzig, among others.

To join the Freifunk network, a user has to download a special router firmware called OpenWrt⁴. This firmware is based on the Linux operating system and is developed and provided by the Freifunk community for free. Besides normal WiFi routers, community members also install outdoor routers on their houses to increase the link quality and net-work range. In November 2006, measurements of the Freifunk netnet-work in Berlin revealed the network to have 316 nodes on average, varying between 199 and 416 [125, 126]. The number of links varied between 291 and 951 (633 on average). For routing, the network used OLSR [55] for a long time. Today, the Freifunk community claims that the B.A.T.M.A.N.

routing protocol [137] is increasingly used in their communities and achieves higher perfor-mance than OLSR.

As opposed to the Google and Cambridge WiFi networks, the Freifunk network is based on voluntary work and resource sharing. Community members all over Germany prove that there is an interest in a free and city-wide wireless community network. Sharing files, ser-vices, and Internet connectivity with others to increase the own network range in return is one of the main reasons to join such networks. However, the router firmware is not available for every router on the market. Also, installing the firmware requires deep techno-logical skills in many cases. This might be the main reason for the rather small number of participants in a city as big as Berlin.

3 Freifunk community website (visited on April 4, 2014): http://www.freifunk.net/

4 OpenWrt - Wireless Freedom website (visited on April 4, 2014): http://www.openwrt.org/

3.1 Communication Infrastructure 27