WiMesh: Leveraging Mesh Networking For Disaster Communication in Poor Regions of the World
Usman Ashraf, Amir Khwaja, Junaid Qadir, Stefano Avallone, Chau Yuen
11 WiMesh: Leveraging Mesh Networking For DisasterCommunication in Poor Regions of the World
Usman Ashraf , Amir Khwaja , Junaid Qadir , Stefano Avallone , Chau Yuen Abstract —This paper discusses the design, implementation andfield trials of WiMesh - a resilient Wireless Mesh Network(WMN) based disaster communication system purpose-built forunderdeveloped and rural parts of the world. Mesh networkingis a mature area, and the focus of this paper is not on proposingnovel models, protocols or other mesh solutions. Instead, thepaper focuses on the identification of important design con-siderations and justifications for several design trade offs inthe context of mesh networking for disaster communication indeveloping countries with very limited resources. These trade-offs are discussed in the context of key desirable traits includingsecurity, low cost, low power, size, availability, customization,portability, ease of installation and deployment, and coveragearea among others. We discuss at length the design, implementa-tion, and field trial results of the WiMesh system which enablesusers spread over large geographical regions, to communicatewith each other despite the lack of cellular coverage, power,and other communication infrastructure by leveraging multi-hopmesh networking and Wi-Fi equipped handheld devices. Lessonslearned along with real-world results are shared for WiMeshdeployment in a remote rural mountainous village of Pakistan,and the source code is shared with the research community.
Index Terms —Wireless mesh networks, Disaster communica-tion, Multi-hop network.
I. I
NTRODUCTION W hile natural disasters have long been a scourge forhumanity, our ability to respond to such emergencieshas gradually been improving with the aid of technology. Inrecent times, a new powerful trend of “digital humanitarism”[1] is emerging in which digital communication facilities arebeing used along with big data and crowdsourcing techniquesto scale up humanitarian response to natural disasters andother crisis situations [2]. The availability of communicationservices in crisis-hit situations is essential due to the facilityit provides in coordination between the various stakeholders.Wireless networking in particular has revolutionized com-munication by offering innovative, flexible, and cost-effectiveuntethered solutions. Due to the significant benefits of thewireless technology, today we have a diverse range of wirelesstechnologies at our disposal. Cellular technologies can be U. Ashraf is with the college of Computer Science and Information Tech-nology, King Faisal University, Saudi Arabia [email protected] A. Khwaja is with the Department of Information Systems, King FaisalUniversity, Saudi Arabia [email protected] J. Qadir is with the Department of Electrical Engineering atthe Information Technology University (ITU) in Lahore, Pakistan [email protected] S. Avallone is with the Department of Computer Engineering at theUniversity of Napoli Federico II, Italy [email protected] C. Yuen is with Department of Engineering Product Development(EPD), Singapore University of Technology and Design, Singapore 138682 [email protected] perhaps at the forefront of this wireless revolution and havepenetrated even remote areas around the world. However,there are still some scenarios where these technologies fail.In particular, the cellular infrastructure as well as the existingPublic Switched Telephone Network (PSTN) may be destroyedduring disasters and alternate means may need to be investi-gated for disaster communication. Moreover, despite its deeppenetration, there are still sizable areas of population at remotelocations where the low return on investment (ROI) alongwith the difficulty of terrain have made deployment of cellularinfrastructure infeasible. In addition, cellular technologies havealso found it difficult to break into rural and low-incomeregions because common models of operations require a highAverage Revenue Per User (ARPU), which rural areas cannotsupport since rural areas are sparsely populated [3].South-East Asia, and Pakistan in particular, is a disaster-prone area that has suffered a number of calamities that havewreaked havoc and created misery. This research work isparticularly motivated by the increasing frequency of disastersin Pakistan in the last decade or so. On October 8th, 2005,there was the Kashmir earthquake that resulted in 80,000fatalities and 3.5 million homeless people [4] [5]. On October29th, 2008, the Ziarat earthquake hit the Pakistan province ofBalochistan resulting in 215 fatalities and 120,000 homelesspeople [6] [7]. During the earthquakes, the traditional telecom-munication infrastructure, including towers and transmissionlines, were destroyed rendering communication difficult andin many cases impossible. This region is also home to severalunderdeveloped remote villages and tiny communities wherecellular penetration has not reached. Even the areas with cover-age were badly damaged by the earthquakes and rehabilitationis still going on several years later.Responding to emergency situations is not only difficult butcan sometimes be life-threatening. One of the most difficultaspects of rescue is ensuring efficient coordination amongrescue team members on hostile terrain in an unfamiliarterritory, such as crumbled buildings during an earthquakeand buildings on fire. Rescue workers, separated by evena couple of hundred of meters of hostile terrain, can faceproblem in communicating. Moreover, communication in suchscenarios is not necessarily restricted to radio communicationbut may also involve text messages, live video feeds, geograph-ical positioning information, and triggered warning messagesamong others. A dire need was felt for an appropriate wirelessdisaster communication system for these areas in respondingto emergency situations for on-site coordination among themembers of the rescue teams. In addition, such a system couldalso help in the post-disaster rehabilitation process spanning a r X i v : . [ c s . N I] J a n several months or even years.An effective and successful disaster communication systemshould have the following desirable characteristics: • Should be cheap, rugged, easy to build, and easy todeploy (especially for rural deployments in developingcountries); • Should have secure communication as well as protectionagainst unauthorized access; • Should have inbuilt fault tolerance and resiliency throughredundancy at all levels including multiple communica-tion paths; • Should be flexible enough to effectively provide wirelesscoverage over diverse terrains; and • Should continue to work even when the the power gridor the conventional communication infrastructure (PSTNand cellular) is disrupted.There are existing disaster communication systems thathave been around for decades, however, each have somelimitations. For instance, satellite phones provide universalcoverage, however, during the earthquake of 2005 in North-Pakistan, the high cost of satellite phones prohibited theirregular use. Radio-based communication has the limitationsof range, bandwidth, and functionality and only provides poorquality audio broadcast. Several wireless base stations and var-ious communication cables were destroyed during HurricaneKatrina and the remaining network was not able to supportcommunication services to first responders [8]. The legacyand tethered emergency response systems either are severelylimited or completely destroyed in disaster struck regions dueto their over dependence on the terrestrial infrastructure [9]and may not be able to support high bandwidth requirementsfor multimedia communication needed for disaster communi-cation.This paper presents the
WiMesh system , a secure andresilient wireless mesh network based disaster communica-tion system designed, developed, and deployed at a con-glomeration of remote and underdeveloped villages and tinycities in the mountainous South-West region of Pakistan.The WiMesh system comprises of a two-tier architecture:the first tier consists of a portable, battery-powered wirelessmesh network which is auto-configuring, self-healing, andrapidly-deployable; whereas the second tier consists of mobilehandheld phones carried by rescue workers which connectautomatically with the nearest mesh access point through Wi-Fi enabling the workers to communicate and coordinate withother team members. A prominent feature of the WiMeshsystem is that it is a complete product, and provides severaluseful features including audio communication (one-to-one aswell as broadcast mode), SMS messaging facility, ability to seethe live geographical positions of other members at all times,and multimedia streaming facility. These features, and thecost-effectiveness of the proposed approach, make the WiMeshsystem appealing for use in disaster areas or an alternative totraditional communication in remote areas.The major contributions of the paper are as follows:1) WiMesh system details — a secure and resilient disas-ter communication system based on multi-radio, multi- channel 802.11n wireless mesh nodes — that providesaudio, video, and text communication by exploiting theWi-Fi capability of mobile phones in disaster-affectedor remote and under-privileged areas where traditionalcommunication and power infrastructure is non-existentor damaged;2) The design and implementation details of the clientand server applications, security considerations, routingprotocols, and the resilient routing metric in light of thevarious design trade offs with respect to the constraintsimposed by the infrastructure, equipment availability,and budget for developing countries. The feasibility andthe performance of the WiMesh system is demonstratedusing a thorough performance evaluation using both anindoor test bed and in a real-world outdoor setting; and3) A discussion on common implementation challenges andpitfalls and sharing of general lessons that can guideresearchers and practitioners in designing and develop-ing future such systems. In addition, the source code,design specifications, and implementation guidelines forthe WiMesh system are also shared publicly to facilitatecommunity development and knowledge sharing.The focus of this paper is not to propose yet another meshmodeling or routing protocol, but instead we believe that thestate-of-the-art for mesh networks is quite mature and we focusinstead on applying the research to solve a real-world problemwhile trying to balance several unique constraint imposedin the context of countries with very limited resources andsemi-literate populace in remote villages who need a plug-and-play solution. We do share some experimental results,but those serve more as validation of the concept ratherthan focus on providing deep insights on the functioning ofthe system. We target remote villages and rural areas withlittle to no communication and power-grid infrastructure tostart with. Additionally, in contrast to the disaster commu-nication systems designed for developed countries, financialconstraints and scarcity of resources were the primary designconsiderations for WiMesh. Moreover, the end-users of theWiMesh system comprise mostly of rural population withlittle to no knowledge or technical expertise. Thus, several ofthe design decisions were motivated by the cost constraints,availability of technology, and with a plug-and-play approach.The paper also provides rare insights into how modern wirelesscommunication technology is deployed and adopted by therural population in Ziarat, a disaster-struck and harsh remotemountainous region in South-West Pakistan with its uniquecenturies old traditions and values. The paper also sharesactual field results from the experiments conducted in Ziaratafter WiMesh was deployed following the earth quake of 2008in Ziarat with its unique geographic diversity.The rest of the paper is organized as follows. Section IIsummarizes a review of the literature and the state of the art.The key differences are highlighted from existing works andthe motivation for this work is discussed. Section III identifieskey disaster communication system features and discussesdesign choices for these features. Section IV provides theWiMesh system details including its overview, design con- siderations, architecture, and various components. Section Vprovides results from field trials for the performance evaluationof the WiMesh system along with challenges and problemsfaced during the development and deployment. The majorinsights and lessons learned are summarized in Section VI.Section VII concludes the paper.II. R
ELATED W ORK
Rising fatalities across the world, from natural and men-made disasters, have attracted significant research attentionfor disaster communication systems. Commonly deployedwireless disaster communication systems may be classifiedinto three categories: cellular, hybrid, and mesh/ad hoc disastercommunication systems. The cellular infrastructure has beenwidely used in several disaster communication systems [10][11] since it can provide significant coverage for areas with anexisting and intact cellular infrastructure without the require-ment of installing any additional hardware. However, thesesolutions are vulnerable as natural disasters often cause partialor complete damage to the telecommunication infrastructure.Moreover, the telecommunication infrastructure may not ex-ist in remote areas of developing countries. Hybrid disastercommunication systems [12] leverage satellite connectivity inaddition to the terrestrial infrastructure. As previously men-tioned, the terrestrial infrastructure is vulnerable to disasterswhereas the satellite subscription and equipment is costly,as was evidenced during the rescue operations in the 2005Kashmir earthquake in the Northern Pakistan region [4] [5]in which satellite phones could only sparingly be used. Themesh or ad hoc disaster communication systems [13]–[19] arebased on leveraging wireless mesh and ad hoc networking toachieve rapid wireless multi-hop connectivity on disaster sites.Wireless mesh and ad hoc networks have several interestingfeatures that make them an attractive option for disaster com-munication. Mesh networks offer wireless multihop connectiv-ity, rapid deployment, minimal configuration, self-healing, andmost importantly, these networks can often be built from off-the-shelf equipment. Due to these interesting features, meshand ad hoc networking appears to be ideal candidates fordisaster communication and, therefore, this section has focusedon evaluating only mesh and ad hoc related network solutions.
WIISARD [13] is an emergency response system for pro-viding medical triage services by mobile first responders. Thesystem initially used Ad hoc On-Demand Distance Vector(AODV), but later switched to a gossip-based communicationprotocol for delay tolerant networking. The main contributionof this research work is the characterization of wireless linksand human mobility patterns during medial triage amongmobile first responders. The research work presented in [13]showed that network partition may occur and, therefore, pro-posed a gossip protocol for delay tolerant communication inthe mesh IEEE SYSTEMS 3 backbone. One of the limitationsof WIISARD system is that it uses a rudimentary routingmetric of hop count that has been shown to perform sub-optimally [19].
DistressNet [14] is an emergency response system for UrbanSearch and Rescue (USR) in disaster struck areas. Low-powered COTS (Commercial Off-the-Shelf) devices, such as smartphones and sensors, are used to assist in disaster com-munication. DistressNet uses IPv6 based routing protocol forlow-power and lossy networks (RPL). The major contributionsinclude file storage and social networking services offeredover a delay tolerant network. DistressNet also supports avibration sensing application that helps detect victims trappedunder rubble. The main limitation of this solution is that theperformance evaluation is performed on a piecemeal basis andlacks results for a holistic and comprehensive performanceevaluation.
OEMAN (On-the-fly Establishment of Multihop wirelessAccess Networks) [15] is a novel approach for disastercommunications. This system leverages the availability ofcommodity mobile devices at disaster sites, turning them intovirtual apps to extend Internet connectivity for disaster sites.There are several limitations including implementation andevaluation in a limited indoor building setting, support for onlyroot top AP route discovery without any support for node-to-node communication, and scalability problems.
CHORIST (Communications for enHanced envirOnmentalRISk management and citizens safeTy) [16] system forms aWiMAX based mesh Vehicular Ad hoc NETwork (VANET)between rescue vehicles. Mobile first responders who arelocated at the edge of the network can connect to thisbackbone through Wi-Fi. The system offers voice servicesand video surveillance for disaster sites. A layer 2.5 labelswitching approach is used for data communication. The mainlimitation of this solution is that it requires expensive and timeconsuming WiMAX base stations infrastructure setup for thewireless backbone and the availability of abundant vehicles.Moreover, the cost of the WiMAX licensed band may alsolimit the utility of this approach.
WIDENS (WIreless DEployable Network System) [17] usesa reliable communication system for real-time applications indisaster situations. This system adopts a cross-layered, cluster-based approach to provide high speed communication throughhotspots and exploits the high bandwidth and wireless rangeof the MIMO (Multiple Input Multiple Output) at the physicallayer. This system introduces the concept of “Terminodes” inwhich each node in the network can perform the functionsof a cluster-head, relay, router, or gateway, thereby, offeringflexibility. The routing protocol used by the proposed solutionis based on secure source routing, which addresses some secu-rity limitations in other similar systems. The main limitationof this solution, however, is that it uses licensed frequencybands, which may limit its use or may introduce excessivecosts in some countries.
SALICE (Satellite-Assisted Localization and Communica-tion system for Emergency services) system [18] uses a hybriddisaster communication comprising of ground infrastructure aswell as satellite connectivity. This work employs several differ-ent concepts including satellite-assisted localization, Software-Defined Radios (SDR), Cognitive Radios (CR), and satellite-assisted enhanced reachability for rescue workers. Due to thesepowerful and diverse technologies, the SALICE system offerscomprehensive functionality with flexibility and heterogeneityfor emergency situations. This research work highlights thebenefits of the SDR technology for addressing the dynamic
TABLE I: Disaster Communication Systems Comparison
Features WIISARD DistressNet OEMAN CHORIST WIDENS SALICE SEDCOS WIMESH
Services First respondermedical triage;Services forvictims Urban searchand rescue;Internetconnectivity forsocial networkingbetween rescueworkers Search and rescue;Internet connect-ivity for socialnetworking amongrescue workers;Communicationamong victims viamobile devices Voice services;Applications forpublic safety Reliablecommunication forreal-timeapplications indisaster situations;Security andvideo surveillance Emergencycommunication,navigationand localizationservicefor very largegeographic areas Security,communication,authenticationand confidentiality Secure andresilient servicesincludingmultimedia(audio/video/SMS)and navigation andlocalization.SystemArchitecture Distributed, flexibleand modulararchitecture Distributed Fully centralized Mainly centralizedwith somedistributedcomponents Mainly centralizedwith somedistributedcomponents Mainly centralizedwith somedistributedcomponents Completelydistributed Decentralizeddistributedarchitecture.WirelessNetwork:Structure,Technology,and Coverage 802.11 for meshnetworking;Medium range 802.11 for meshnetworking;802.15.4 forsensing;Short to mediumrange 802.11n for Wi-Fi;Medium range 802.11n for edgemobile firstresponders;WiMax forvehicular backbone;Long range OFDMA;MIMO;Long range IEEE 802.11;DVB-SH;Very long range Bluetooth;Very short range IEEE 802.11nmesh networkingtechnology; Longrange.Routing Delay tolerantnetworking;Gossip basedcommunicationprotocol (WCP);Hop count metric;AODV routing RPL routingprotocol for lowpower and lossynetworks Tree-basedunidirectionalforwarding fromroot to leaf nodes;No node-to-noderouting Layer 2-5 labelswitching approach Secured sourcedrouting extensionof OLSR protocol Extension ofODMRP routingprotocol Delay tolerantnetworkingdevice-to-device OLSR routingprotocol withExpected LinkPerformance(ELP) metric.Security &Resilience Delay tolerantnetworking;Immune to comm.delays;No specialsecurity measures Tolerant againstdelays and disruptionssocial networkingensured at all times;No special securitymeasures Limited faulttolerance due tocentralized model;No special securitymeasures Resilient backbonebased on WiMax;High security Tolerance tolink and nodefailuresby using secureOLSR protocol;Highly secureprotocol Reliable centralizedbackbone;Highly secure Resilient toDenial of Serviceattacks throughepidemicdissemination;Specially designfor securityagainst DoS attacks Secure andResilient. Uses(i) authentication;(ii) encryption(using WPA2-AES); (iii) resilientrouting using ELPmetric.PowerRequirement Low Low Low High High High High LowSoftware& OperatingSystem MultipleOS support (Linux,WinXP, Max OS) Multiple OSsupport (TinyOS,SOS, LiteOS,Mantis, Linux,Windows) Windows OS Commercialproprietary software Embedded OS(PHY/MAC) Linux Ubuntu Embedded OS(PHY/MAC) OpenWRT (MeshNodes); AndroidOS (WiMeshclients).Hardware Triage devices(Nokia mobiles);Mid-tier (Tablet PC);Mesh boxes (Alixx86);RFID tags Mobile phones;Sensors;Wireless APs Laptops;Mobile phones Base stationequipment PCMCIA Adapters Software-definedradios, laptops,mobile basestations Software-definedradios, laptops,mobile basestations UbiquitiPicostation andthe Nanostationdevices.Size andPortability Small size;Light;Highly portable Small size;Light;Highly portable Small size;Light;Highly portable Large size;Heavy;Portability difficult -requires vehicles Small size;Light;Highly portable Not portable,requiresinfrastructure Not portable,requiresinfrastructure Highly Portable.InstallationComplexity Low Low Low High Medium High High LowCost Low Low Low High Low High High LowAvailability Commercial Off-the-Shelf (COTS);Digital tags maybe difficult toacquire in develop-ing countries COTS COTS Required hardwarefor base stationsand associatednetwork may bedifficult to acquireat remote sites Custom hardwareand software Customhardware Customhardware Relatively cheapand easily availableequipment is used.MajorContributions Mitigates networkpartitions due tomobility of rescueworkers using DTN;Characterization oflink quality andhuman mobilitypatterns duringmedical triageamong mobile firstresponders Offers file storage;Provides socialnetworking despitenetwork delaysand disruptions;Mobile vibrationsensing applicationdetecting victimsunder rubble withimproved accuracy Convertscommodity mobiledevices into VirtualAccess Points(VAPs);Supports extensionsof Internetconnectivity todisaster sites Provides videosurveillance andvoice communica-tion for disastersites by providinga WiMax VANETsfor vehicles towhich mobile firstresponders connectthrough Wi-Fi Cross-layeredapproach for highdata rate service;Terminode conceptwhere each nodeperforms thefunction of clusterhead, relay, router,or gateway;Secured sourcerouting Platform basedon SDRtechnology foremergencyservices;Integration ofdifferentcomponents andtechnologies. Platform basedon SDRtechnology foremergencyservices;Integration ofdifferentcomponents andtechnologies. A resilient WMNbased disastercommunicationsystem for under-developed/ruralareas using low-cost, highlyavailable, portableequipment.Limitations Sub optimalrouting metrichop count Limited experimen-tal evaluationsperformed indoorsonly using a piece-wise approach e.g.mobility algorithm,sensing, etc. Internet extensionsonly for rescue staff;Limited indoorevaluation only;Does not supportpeer-to-peercommunication,only root-to-node;Does not performload balancing, usesa single AP Expensive;Uses licensedfrequency bands Uses licensedfrequency bands Platform offerslimited through-put due to thelimitations of theUSRP in NLOSconditions Platform offerslimited through-put due to thelimitations of theUSRP in NLOSconditions Due to its specificdesign for disastercommunicationscenarios, itmay not workwell for otherhigh-performancerequirements. nature of emergency situations allowing new communicationlinks or adoption of modulation schemes based on the groundsituation. The main limitation of this solution is its lack ofcost-effectiveness due to a comprehensive infrastructure.
SEDCOS (A Secure Device-to-Device Communication Sys-tem for Disaster Scenarios) [20] has been especially designedwith security considerations. It adopts an adversary basedmodel and employs secure key management and resilientcommunication to counter denial of service (DoS) attacks.It does not discuss classical disaster communication servicessuch as audio message and voice calls, rather contributestowards modern disaster communication systems.Table I provides a comparative analysis of the disastercommunication systems presented in this section.A number of mesh network based disaster communicationsystems are evaluated above. While these systems have posi-tively contributed in the overall mesh network based disastercommunication research, all of these systems have limitationsas was highlighted in the above evaluation. The proposedWiMesh system is expected to provide similar benefits whileattempting to overcome some of these limitations.III. D
ESIGN C ONSIDERATIONS FOR C OMPONENTS OF D ISASTER C OMMUNICATION S YSTEMS
Designing efficient and effective disaster communicationsystems involves several diverse components of the systemworking seamlessly to provide the required performance. To-wards this end, this section provides details on various keycomponents of disaster communication systems and discussespossible design choices along with trade-offs.
A. Services
Disaster communication systems are expected to providefollowing services:1) User registration and authentication - User registration isrequired at the server whereas authentication is neededboth at the server and the client level;2) Audio call - Audio calls can be either one-to-one orone-to-many (broadcast). One-to-one audio calls may bebetween admin and users or among users;3) SMS - SMS may also be either one-to-one or one-to-many (broadcast). Like audio call, one-to-one SMS maybe between admin and users or among users;4) File transfer - File transfer may also be either one-to-oneor one-to-many. Like audio call, one-to-one file transfermay be between admin and users or among users;5) Live video streaming - Live video streaming function-ality may consist of following types: sending live videostream to client, sending live video stream to server,receiving live video stream by client, and receiving livevideo stream by server. All live video streams are usuallyone-to-one between two users;6) Navigation - The navigation functionality allows usersto view the geographical location of other peers/users ona map with some necessary information. User can alsoview his own position on the same map relative to theother peers/users; and 7) Network performance monitoring - Disaster communi-cation systems need capability for monitoring, logging,and viewing user and network statistics to ensure QoSfor the coordinated relief efforts among geographicallydispersed clients in adverse situations.
B. System Architecture
The system architecture plays an important role in theoverall performance of any disaster communication system.The specific choice of architecture may be influenced byseveral external factors including terrain, weather, existinginfrastructure, and cost.Broadly, there can be three categories for system archi-tecture: centralized, distributed, and hybrid. In general, theloosely coupled distributed architecture is the best choice fordisaster communication due to a number of reasons includingflexibility, fault tolerance, autonomy, and scalability. More-over, logistic reasons, such as difficult terrains, also dictatethat autonomous distributed components are more likely tosurvive the stringent requirements of disaster communication.However, the distributed architecture do introduce some secu-rity concerns due to lack of control. Popular solutions in thedistributed architecture category include WIISARD [13] andDistressNet [14]. At the other end of the spectrum, centralizedsolutions, such as OEMAN [15], even with some limitations,offer certain appealing features such as ease of use, control,and security. Some solutions [16]–[18] offer a compromiseby combining the strengths of both these approaches. Ingeneral, these solutions have a fixed backbone (e.g., WiMAXor cellular) and a mobile mesh based last-mile. These solutionsdo offer a trade-off, however, the centralized architectureimposes the same limitations of scalability, flexibility, and cost.
C. Wireless Network: Structure, Technology, and Coverage
The wireless network is perhaps the most fundamentalcomponent of the disaster communication system and consistsof several key aspects including its structure, technology, andcoverage. The structure of a wireless network can either becentralized, distributed or hybrid. Distributed structures, suchas ad hoc and mesh networks [13]–[15], offer the inherentadvantages of multi-hop networking, while a hybrid approach[16]–[18] combines some form of a centralized backbone net-work (e.g. satellite or cellular) along with a mesh component.Another important decision in the design of the WiMeshsystem is the choice of the wireless technology. Technologieslike WiMAX or 4G offer certain advantages, however, havethe limitation of infrastructure and licensing costs. Similarly,different technologies offer a trade-off in terms of wirelesscoverage as well. For instance, installing WiMAX or cellulartowers can significantly increase the wireless reach of thenetwork, however, have cost and logistic difficulty offsets.Similarly, off-the-shelf technologies like 802.11 are free andrequire minimal setup, however, have coverage limitations. InWi-Fi technologies, the IEEE 802.11n standard uses Multiple-Input and Multiple-Output (MIMO), and provides significantlybetter performance by exploiting spatial and temporal diversity through multi-path propagation and offers impressive datarates of up to 600 Mbps. Therefore, IEEE 802.11n based radiosare a natural choice for the mesh backhaul as well as offeringaccess to clients.
D. Routing
Routing forms the backbone of any disaster communicationsystem and the routing protocol and metric used play adecisive role in the overall system performance. Towards thisend, there are choices of several routing protocols and metricsincluding proactive, reactive, and hybrid routing solutions.Some completely centralized solutions employ static routing,but by and large, most disaster communication systems need astrong proactive or dynamic routing protocol. Popular choicesin this category include OLSR and DSR routing protocols.Proactive protocols such as OLSR offer quick routes, however,create messaging overhead that can be burdensome if theequipment is battery powered. On the other hand, the reactiverouting approaches do not provide quick routes, however, canoffer overhead savings. Another important criteria is that ofthe routing metric as the metric needs to be dynamic andintegrates fault-tolerance and adaptability to changing networkconditions. This is especially important in disaster situationssince the network may experience failures and faults dueto users moving out or range, environmental factors, andpower draining. State-of-the-art metrics such as [21] can offerefficient routing metric solutions which cater to changing linkqualities, bandwidth, and node failures.
E. Security and Resilience
Disaster communication system, by virtue of its application,may have several diverse clients connected to its network.These clients may consist of mobile devices such as smartphones, laptops, tablets, and other communication gadgets ofeither official rescue workers or personal users. These devicesmay be used for rescue communications and data sharing orpeople requesting for aid or other emergency services. Dueto this wireless, cooperative, and decentralized nature, thesesystems are vulnerable to various security attacks such asrelief communication disruption by terrorists by injecting falsemessages, denial-of-service (DoS), and unintentional cloggingof the network by spamming from people in panic [20]. More-over, malicious attacks could damage strategic nodes or linksin the network and, therefore, the underlying routing protocolsand metrics should be designed to introduce resilience againstthese types of attacks. Hence, effective disaster systems mustprovide user authentication, message integrity, secure routing,confidential end-to-end communication and resilient routing.
F. Power Requirement
Since disaster communication systems are envisaged to bedeployed in rural and disaster-struck areas, an implicit assump-tion is that electrical supply will be limited or unavailable.To solve this problem, renewable energy systems, such assolar power, may be considered to power the nodes. This implies that the designed system must be energy-efficient.Moreover, the software on the mobile phones must be designedto minimize the energy drain.
G. Software and Operating System
There are three main parts of disaster communication soft-ware system including the server, the clients, and the wirelessback haul network OS/firmware.
1) OS for Wireless Network:
Proprietary OS and firmwareprovide a user-friendly graphical user interface. However,there is little control over different network components suchas the routing protocol, the routing metric, and dynamicrate adaptation. Therefore, disaster communication systemsshould consider the adaptability and flexibility of open-sourcesoftware.
OpenEmbedded [22] is an open-source cross-compilationenvironment for building Linux distributions for embeddedapplications. It offers support for multiple hardware, cus-tomization, and rapid development. A set of rules and in-structions, called a “recipe,” is used to generate architecturespecific applications and packages. However, OpenEmbeddedis difficult to use due to its complexity.
Linux From Scratch (LFS) [23] offers a powerful paradigmfor building custom Linux distributions from the source. Theresult is a compact, flexible, and secure system with a betterunderstanding of the internal working of the OS. However,building LFS requires significant Linux proficiency to sort outthe configuration dependencies and compilation errors.
DD-WRT [24] is a Linux based firmware for wireless routersand access points. DD-WRT provides a custom firmwareoption with several features and functionalities such as accesscontrol, bandwidth monitoring, quality of service, DynamicDNS, universal plug-and-play, and many others.
OpenWRT [25] is an open-source Linux for embeddeddevices for routing network traffic. OpenWRT uses a smallerµClibc C library to reduce the memory footprint, which makesit possible to run on various types of devices, such as homerouters, residential gateways, smartphones, pocket computers,and laptops. OpenWRT offers a built-in package managerthat allows the installation of packages from a comprehensivesoftware repository. OpenWRT can be used as an SSH server,a Bit-Torrent client, and VPN. OpenWRT offers significantflexibility and has an extensive support base.
2) Software for Clients:
There are several mobile applica-tion development platforms available for the client OS. TheMobile Information Device Profile (MIDP) [26] is the toolkitfrom Sun for creating mobile applications and is consideredquite easy to learn and use. The Symbian OS [27] is anotherpopular platform for mobile phones and is used by Nokiain their mobile phones. Symbian OS is significantly morecomplex compared to MIDP. The iPhone OS is the operatingsystem used in Apples iPhone and iPod touch. iOS is designedto be extremely efficient on mobile devices, using less thanhalf a gigabyte of memory [28]. The BlackBerry platform [29]uses Java for application development and runs applications inprotected run-time environment. It has several libraries with sound inter-operability. BlackBerry has acceptable level ofrobustness and reliability, however, the BlackBerry platformdoes not allow programmers controlling the GPS and scanningof cell towers or Wi-Fi access points (APs) programmati-cally. Moreover, it is not very memory efficient. The PocketPC/Windows Mobile OS is a mobile version of the desktopWindows OS. It has been designed mainly for Pocket PCand Smartphone devices and as such limits the third partydevelopment opportunities.
3) Software for Server:
Every disaster communication sys-tem requires the usage of VoIP technology to support messag-ing and audio communication. While there are several dozenVoIP servers available, to limit the scope of discussion, thispaper only considers the two major VoIP servers, Asterisk [30]and OpenSIPS [31]. Asterisk is a software implementationof the telephone Private Branch Exchange (PBX). Asteriskenables telephone calls between users connected to Asteriskas well as to other telephone services such as the PSTN andVoIP services. Asterisk is compatible with several operatingsystems including NetBSD, OpenBSD, FreeBSD, macOS, andSolaris. Asterisk supports several standard VoIP protocols,including the Media Gateway Control Protocol (MGCP), Ses-sion Initiation Protocol (SIP), and H.323. The OpenSIPS isbasically a multifunctional, multi-purpose signaling SIP serverfor VoIP that can handle voice, text, and video communication.OpenSIPS can handle thousands of calls simultaneously. Thefundamental difference between the two VoIP servers is thatAsterisk is basically a media server, whereas OpenSIPS isessentially a SIP proxy server. While Asterisk has a bettersupport for multimedia communication, the robustness, flexi-bility, adherence to SIP standards, makes OpenSIPS a suitablechoice for the disaster communication systems.
H. Hardware
The major choice of hardware is in the realm of theinfrastructure of the wireless network side including AccessPoints (APs) and antennas among others. The backbone fordisaster communication can be created ranging from relativelysimple off-the-shelf wireless access points to powerful networkboards like Gateworks Cambria boards [32]. The higher endnetwork boards are more powerful, rugged, and typically havemulti-radio support, however, are more expensive and com-plex. Here, it is important to realize that there are importantaspects including the cost, energy consumption, availabilityand robustness of the hardware which may play an importantrole in decision making. It is hard to deploy a solution whichaddresses problems of underdeveloped countries but requiresimporting expensive equipment that is not readily available.Moreover, the mesh nodes should also be easily portable andrugged since the equipment may need to be rapidly deployedover difficult geographical terrain. The mesh nodes should alsobe energy-efficient and would need to be solar-powered out inthe field due to the likely destruction or non-availability ofpower grid in the disaster areas.
I. Size and Portability
Since disaster communication systems may be used overunfamiliar and uneven terrain, under hostile circumstances,and in inclement weather conditions, these systems should beeasy to assemble, disassemble, carry, and move around. Oftenvehicles are not available or offer limited maneuverability.Hence, such systems need to be designed considering smallersize, lighter weight, and high portability.
J. Installation Complexity
A major factor which can dictate the eventual adoptionand success of disaster communication systems is the instal-lation complexity of the complete system. The installationcomplexity may include the physical deployment as well asconfiguring the server and client software. For disaster-struck,underdeveloped areas, it may be difficult to have highly skilledpeople. It would be pointless to add to the list of problemsthe complexity of deploying and configuring the disastercommunication systems. A plug-and-play approach for allcomponents of the system should be followed and extensiveuse of automated scripts for accomplishing repetitive tasksincluding bootstrapping common settings is recommended.
K. Cost
Since these disaster communication systems are expected tobe used in developing and underdeveloped countries, the costis an important factor to be considered in the design of suchsystems. Cost factor may consist of hardware equipment cost,software cost, maintenance cost, and skills cost. The choiceof the hardware equipment should be as such that the costis minimal and affordable in the developing countries. TheSoftware cost may be minimized or eliminated by selectingopen source and freeware software. The design of the systemshould be flexible and adaptable so that maintenance costis minimal. The system should be easy to setup and use toeliminate need of highly skillful operators.
L. Availability
Availability of the equipment is an important considerationespecially for the developing countries. Often there is achoice of employing state-of-the-art equipment which is highlyefficient and effective, however, their availability may notbe as widespread. For instance, the Avila Gateworks board[33] is considered a powerful solution for outdoor wirelessnetworking, however, is not easily available in developingcountries. IV. T HE W I M ESH S YSTEM
This section presents architectural, component design, andimplementation details of the WiMesh system. In addition,design choices for the WiMesh system are presented for thesystem features identified in section III.
A. Design Choices for WiMesh1) Services:
Based on the key services identified in sectionIII-A for disaster communication systems, following serviceswere selected to be incorporated in the WiMesh system: audiocalls in both unicast and broadcast modes; multimedia dataexchanges such as images, video, data files, and SMS inboth unicast and broadcast modes; sending and receiving livevideo streaming to/from clients and server; and geographicalposition viewing of the WiMesh users. Moreover, the WiMeshcontroller provides additional services such as remotely mon-itoring, configuring, and controlling the entire network evenat the wireless interface level. Additionally, the server alsoprovides user registration and authentication services.
2) System Architecture:
For the WiMesh system, a decen-tralized architecture was selected to avoid the inherent limita-tions of centralized networks. The decentralized architecturewas combined with the power of mesh networking, exploitingits traditional strength areas such as multiple available routes,adaptability of changing requirements, and flexibility. Thus,the WiMesh system has been designed to enable loose cou-pling among autonomously working components in order toavoid a purely centralized approach. The server does intro-duce some centralized components, however, the routing inthe mesh backbone itself is highly flexible, independent andadaptable to changing environment and network conditions.
3) Wireless Technology and Coverage:
For the wirelesstechnology, the off-the-shelf license free IEEE 802.11n tech-nology was selected for the WiMesh system. There is thetrade-off of limited wireless coverage at hand, however, by us-ing 802.11n technology and powerful outdoor multiple sectorantennas, the wireless range issues can be somewhat mitigated.
4) Routing:
The OLSR protocol was selected for routing inthe WiMesh network since it is a proactive protocol allowingfor real-time routing decisions. Moreover, there are severalimplementations available for this protocol. For the routingmetric, the Expected Link Performance (ELP) routing metricwas integrated since it provides state-of-the-art performanceby incorporating aspects such as resilience, link qualities,interference,load, and link asymmetries.
5) Security and Resilience:
The WiMesh server securityand resilience was designed from three aspects. First andforemost, the WiMesh system registers and authenticates users(Authentication API module) in order to ensure that only au-thorized users access the services (there is a special emergencymode available which allows all users to register and connectwithout authentication). Second, the wireless communicationis completely encrypted using WPA2-AES encryption for thewireless state-of-the-art encryption standards. Third, the ELPmetric introduces resilience in the overall routing approachin the sense that nodes and link failures would be mitigatedthrough the use of efficient and dynamic estimation of routequalities.
6) Power Requirement:
The WiMesh system is designed tofunction in remote areas through the use of batteries and solarpanels. This has been demonstrated through several experi-ments that none of the equipment is particularly power hungryincluding the server, controllers, and the mesh nodes and thesystem can function perfectly off-the-grid. Additionally, the WiMesh system conserves energy by minimizing the usage ofthe GPS module through periodic sleeping.
7) Software and Operating System:
For the wireless back-haul network, the obvious choice for the WiMesh system wasan open-source Linux distribution like OpenWRT or DD-WRTbecause these OS/firmware are easy to control, modify, andextend. Significant changes can be made to the protocol stackfor designing efficient protocols and integrating customizedcode and scripts. Therefore, OpenWRT was used as the Linuxdistribution for the mesh nodes.For the server software, Asterisk has a better support formultimedia communication, robustness, flexibility, and adher-ence to SIP standards. However, it seemed that the speedand call capacity of the OpenSIPS server, along with itstremendous scalability capacity, makes it an ideal choice forthe WiMesh server.The Android OS [34] open-source development platformwas selected for the WiMesh mobile clients. Android OSoffers component-based architecture, built-in APIs, automaticlifecycle management, and high portability.
8) Hardware:
The principal hardware considerations werecost effectiveness, off-the-shelf availability, and open-sourceprogrammability for full control over device functionality.Hence, the hardware choice for this project was the UbiquitiPicostation and the Nanostation devices [35].
9) Size and Portability:
Highly portable equipment wasselected, e.g., extensible poles that can be quickly extendedor collapsed. The wireless APs and other devices were alsolightweight and portable. No heavy installations were required,making the WiMesh system a highly portable solution.
10) Installation Complexity:
Extensive use of bootstrappedautomated scripts were used to ensure common settings andeasy deployment. The OpenSIPS server and the server soft-ware was almost plug-and-play. The final product was aprofessionally assembled unit with LEDs and simply requiredturning it on. For the clients, an android application wasdeveloped which could be easily installed.
11) Cost:
Instead of importing expensive wireless equip-ment, the project instead relied on cost-effective equipmentlocally available. Redundancy was introduced to offset someof the quality trade-offs in the solution. For example, insteadof power Avila Gateworks boards with multiple Wi-Fi cardssupport [33], multiple Ubiquiti wireless APs [35] with multiplesector antennas were used per mesh node.
12) Availability:
Avila Gateworks boards [33] were notavailable locally and had to be imported, which were costlyand would pose problems for additional parts replacementproblems down the road. Therefore, it was decided to userelatively cheap and easily available equipment, e.g., UbiquitiNanostations and Picostations [35] and antennas that werereadily available. The trade-off was quality and performance,but redundancy (multiple APs per mesh node and more densedeployment) was used to overcome these limitations.
B. WiMesh Architecture and Overview
Figure 1 shows the WiMesh system architecture with itsthree main components: server module, client module, and the
Fig. 1: WiMesh Architecturebackhaul mesh network. The WiMesh server module is respon-sible for the overall management of the WiMesh system. Theserver module provides mechanisms for all communicationsbetween clients and rest of the WiMesh network includingaudio, video, messaging, file exchange, and live geographicalpositioning of clients. The server also handles user registrationand authentication. In addition, the server module monitors,collects, and logs user data and the performance statistics ofthe WiMesh backhaul network. The server module is typicallyhosted on a desktop machine. The WiMesh client module isinstalled on mobile devices carried by the users and enablesmultimedia communication and live geographical positioningwith other clients and the WiMesh server. The WiMeshbackhaul network is a multi-radio, multi-channel wireless (Wi-Fi) backhaul mesh network that forms the core of the WiMeshnetwork. The backhaul mesh network creates a wireless multi-hop backbone infrastructure enabling mobile users, spreadover large geographical regions, to communicate with eachother. The WiMesh backhaul network uses the Optimized LinkState Routing (OLSR) protocol, which is integrated with acustom WiMesh routing metric to provide efficient customrouting for performance improvement.
C. WiMesh Server
The WiMesh server is an important part of the WiMeshsystem, which handles communication among clients as wellas the overall system including the mesh backhaul network.The core functionalities offered by the server include: • Overall management of the system; • Audio calls in broadcast mode with WiMesh clients; • Multimedia exchanges (image, video, data files, SMS)with clients; • Geographical position viewing of the WiMesh users; • Registration and authentication of WiMesh clients; and • User data and mesh network statistics monitoring andlogging via WiMesh Controller.Some of the functionalities such as audio calls, multime-dia exchanges, and geographical positions viewing requireinteractions with the clients and, hence, are repeated in theWiMesh client modules as well. The client-side part of thesefunctionalities will be discussed in the client module section. Fig. 2: WiMesh Server ArchitectureFigure 2 shows the main components of the WiMesh servermodule. The server module hosts an application server, anOpenSIPS VoIP server, and a WiMesh controller. Both theapplication and the OpenSIPS VoIP servers are hosted on thesame machine with an underlying protocol stack consisting ofvarious transport services. The server module is programmedin the Java programming language running on top of a JavaVirtual Machine (JVM) in a Linux operating system environ-ment. In addition to these main components, the server modulealso consists of a database module, graphical user interface(GUI) components, and various configurations files.
1) Application Server:
The application server comprisesof the different service APIs. These APIs consist of VoIP,text, file, video and the location/navigation API. In addition,the application server also contains a communication modulethat comprises of Mesh APIs for interfacing with the meshnetwork and managing the overall operation of the server.Finally, an authentication module provides client registrationand authentication functionality.
Call APIs : The call APIs handle audio communicationbetween the server and the OpenSIPS server. The audiocommunication supported by the application server is of twotypes: the real-time one-to-one VoIP call mode and the audiobroadcast mode. The real-time one-to-one VoIP call is onlysupported on the WiMesh clients, such as mobile phones,whereas the audio broadcast mode is used on the WiMeshserver by the administrator to send out a broadcast audio toall users through a radio-like functionality. For the broadcastaudio messages, the administrator on the WiMesh serverpresses and holds a “record” button to record audio messagesof up to two minutes. The audio message is encoded usingAdaptive Multi-Rate audio codec and transmitted using HTTPLive Streaming (HLS) to clients. The VoIP APIs are implemented on top of open-sourceMobicents Application Server platform, which is a high-performance, scalable, and fault tolerant service level execu-tion environment. The VoIP API implementation focuses onenabling the establishment and maintenance of audio commu-nication between mobile users. From the implementation pointof view, the VoIP API uses the Mobicents Application Server’sSIP module and the SIP protocol for voice communication. Asub-module of the VoIP API allows the command and controlstation to communicate with the mobile users.
Multimedia APIs : The multimedia APIs allow sending afile or a message to users from the WiMesh server. Usingthese APIs, the administrator can send a message or a fileto a specific user or broadcast to all users. In addition, themultimedia APIs allow streaming live video from WiMeshserver to the clients. The purpose of this functionality is tofacilitate monitoring of real-time ground situation.For the file and text APIs, as soon as a text message isreceived from a user destined for another user, the serverchecks if the destination is available. If so, the message issent and a copy is queued. In case no ACK is received withina certain time frame, the message is re-sent. Resending ofmessage is attempted for a maximum of three times. If thedestination is not available, then the message is routed to an-other queue for later delivery. Along with the implementationof new code, these APIs make use of the Netty open-sourceprotocol framework. The implementation makes use of threepackages of the Netty framework: HTTP and web sockets,sockets and datagram, and Large File Transfer package.Similar to the VoIP APIs, the Video APIs are also im-plemented on top of the open-source Mobicents ApplicationServer platform and uses the Mobicents Asterisk package forvideo communication. The Video API enables reception andtransmission of video between command and control stationand mobile users.
Navigation APIs : The navigation APIs collect locationstatistics of all the WiMesh clients and display these locationspecific statistics on a map on the server. The navigation APIsdeal with locating specific users and, if needed, navigatingto the required user(s) using Google maps API. The GPSmodule in the mobile phone gets the precise location of theuser in terms of latitude and longitude and then passes thisinformation to the Client Navigation API which passes thisinformation to the Server Navigation API.
SIP Server APIs : The job of the SIP server APIs is tointerface the WiMesh system with the OpenSIPS server. TheseAPIs relay audio requests and data from the WiMesh clientsto the OpenSIPS server. These APIs also relay SMS betweenWiMesh clients and the OpenSIPS server.
Communication APIs : The communication APIs provide thecommunication interface between the WiMesh server and themesh backhaul, OpenSIPS, and the clients. Any communica-tion from other components of the system to theWiMesh servertakes place through these APIs. These APIs also handle thesocket creation, maintenance, and destruction.
Authentication APIs : The authentication APIs provide userregistration and authentication functionality. The WiMesh sys-tem supports two levels of security: the first level is “open access” in which no registration or authentication is required;whereas the second level requires user registration and login tothe WiMesh system. The password can be saved at the clientside for automatic authentication for subsequent logins.
2) WiMesh Controller:
The WiMesh controller performsmesh network management, monitoring, and logging. It pro-vides the following salient functionalities: • Listing the current nodes status (up, down, restarting); • Live statistics on routes, gateway, flags, and metric; • Information on all the executing processes; • Information logs such as router ID, router IP, receivedpackets, transmitted packets, lost packets, interface ID,interface IP, and transmission queue length; • Files and folders upload and download; • Backup of the current state of all the network routers; • Network restore to a previous state; • Single screen remote shell access for fine-tuned control; • Remote editing of the files on any router; and • Remote modification of the radio interfaces of any router.The WiMesh controller performs the management, monitor-ing, and logging of the mesh network. While there are somecomprehensive and useful management tools available, theWiMesh system requirements were so diverse that no singletool met all the requirements. This motivated the developmentof a custom-built WiMesh controller using the Java program-ming language. The WiMesh controller has a user-friendlyinterface for monitoring the mesh network, collecting statistics,and logging network traffic. The tool uses JSch (Java SecureChannel), which is a Java implementation of the SSH2, foropening sockets to the mesh nodes. The JSch facilitates secureremote login, secure file transfer, and secure TCP/IP and X11forwarding. The home page and the network configurationpage of the WiMesh Controller can be seen in Figure 3.
3) OpenSIPS VoIP Server:
The OpenSIPS VoIP sever isan open-source, multi-functional, multi-purpose signaling SIPproxy server [31]. The application server interfaces with theOpenSIPS VoIP server to relay voice, text, files, and videoamong WiMesh clients and the OpenSIPS sever.
4) The Protocol Stack:
The protocol stack is based onthe Asynchronous Event-Driven Network Application Frame-work. The WiMesh server requires multi-threading approachto handle multiple client connections simultaneously. Researchshows that the traditional multi-threading approaches performpoorly and usually incur significant overhead [36] especiallyfor a performance driven system. Hence, the WiMesh systemuses a more efficient approach, Staged Event-Driven Archi-tecture (SEDA) [36], that avoids the high overhead associatedwith thread-based concurrency models and decouples eventand thread scheduling from application logic. By performingadmission control on each event queue, the service can bewell conditioned to load, preventing resources from beingovercommitted when demand exceeds service capacity.
D. WiMesh Client
The WiMesh client module is installed on mobile devicescarried by the users and enables multimedia communication Fig. 3: WiMesh Controller Homepage and Network Configuration Pagewith other clients and the WiMesh server. The client moduleconsists of the Mesh API, the client application, socket, andthe Android stack, as shown in Figure 4.
Mesh APIs : The Mesh API interfaces with the mesh networkand is used to transmit and receive client data and controlpackets to and from the mesh network. The Mesh API createsmessage headers for packets containing client information andthe services required such as voice, video, or text. The clientMesh APIs are implemented to ensure the periodic sending oflocal information to the server including the local IP addressand the GPS co-ordinates of the clients.The client application module includes VoIP APIs, TextAPIs, File APIs, Video APIs and the Navigation APIs.
VoIP APIs : The VoIP APIs provide audio communicationand are implemented to allow mobile users to make voice callsbetween each other as well with the command and controlstation. The VoIP APIs use the Android SIP package.
Video APIs : The Video APIs provide video communicationand are implemented to enable the transmission of captured orlive video feeds to the command and control station as wellas to the other users. The video APIs use the services of theAndroid media package for video communication.
Text and File APIs : The Text and the File APIs provide textcommunication and file upload/download capability betweenthe mobile users as well as with the command and controlstation. Both APIs use UDP and TCP sockets along withAndroid HTTP package for communication. UDP socket isused for efficiency. However, to ensure reliability in the case aFig. 4: WiMesh Client Architecture UDP packet is lost, code is implemented so that the destinationsends an ACK for a text message received. In the case, theACK is not received within a timer period, the packet isconsidered lost and the application layer asks the UDP tore-send the packet again. Reliability is also included for filetransfer over the unreliable UDP. Since the packet will berelayed by the server to the destined mobile user, a custompacket is used in which the IP address of the eventual mobileuser is included along with the IP of the server to which thepacket will be forwarded as the next step.
Navigation APIs : The Navigation APIs periodically sendGPS coordinates of the client to the server. The NavigationAPIs are built on top of the Google Maps APIs.The socket and the Android stack are already implementedmodules and the aforementioned APIs will use their servicesthrough well-defined interfaces. The socket provides the inter-face for networking, enabling the client to communicate withother clients and the server over the mesh.
E. WiMesh Backhaul Network
The core of the WiMesh system is formed by the wire-less backhaul network which creates the wireless multihopbackbone, enabling mobile users to communicate with eachother spread over a region. There were several aspects relatedto the design of the wireless mesh backhaul network. Thenext subsections describe the design choices made and themotivation for those choices.
1) Mesh Nodes and Associated Hardware:
The projectuses two different types of mesh nodes: PicoMesh node andNanoMesh node. The mesh hardware selected for the projectwas the Ubiquiti PicoStation M2HP and Nano-Station M2models [35]. The PicoStation is a 600mW, 2.4 GHz, highpower outdoor access point, equipped with an Atheros MIPS24KC, 400 MHz processor, 32MB SDRAM, 8 MB Flash,one 10/100 Ethernet port, and a 6 dBi outdoor omni-antenna.Weighing a mere 100 g, with dimensions of 136x20x39 mm,and the ability to withstand extreme temperatures (-20 °C to70 °C), the PicoStation is portable, rugged, and provides omnicoverage of up to 1 km in open areas while consuming only 6Watts. This specification makes the PicoStation a good choice Fig. 5: A typical PicoMesh nodefor use in meshing or as an access point to which mobilenodes can connect. The NanoStation is a more powerful devicecomprising of a 200mW 2x2 MIMO radio with an integrateddual polarity 13 dBi sector antenna, a horizontal beamwidthof 90, and providing outdoor coverage of up to 10 Km.Every node comprises of an extensible stand (up to 25 feet),a 12 Volt, 7 AH dry battery, a small TP-Link (model TL-SF1005D) Switch, and modified Power over Ethernet (PoE)units (to enable direct connection to 12 V battery instead of220 V DC supply) or 12 Volt PoEInjector units to power themesh node. In addition, portable custom-made mesh-boxes areused at each node to house the various hardware componentsand for protection from weather conditions. The server meshnode additionally hosts the WiMesh Server in addition to thestandard hardware.The PicoMesh node comprises of two PicoStation devicesconnected through the switch. One PicoStation at each nodeoperates in the access point mode and allows mobile devices toconnect. The second PicoStation operates in the ad-hoc mode,runs the mesh OLSR protocol, and forms the wireless multihopbackbone. The two devices are tuned to non-overlappingchannels to avoid interference between the mesh backboneand the access network. The PicoStation has a relativelylimited range but provides omnidirectional coverage. Hence,the PicoMesh node is used when a higher degree of meshingis required in a smaller area with problems of line-of-sighton the terrain, requiring multiple alternate routes to bypassobstacles such as dense foliage and small mountains.The NanoMesh node comprises of two NanoStation devicesand a single PicoStation device connected through the switch.Since the NanoStations provide sectorized wireless coverage,two devices are required at a minimum to enable the wirelessreach to other nodes. Another noteworthy difference from thePicoMesh is that NanoMesh requires some alignment due tothe sector coverage whereas the PicoMesh provides omni-coverage and does not require the deployment positions tobe constrained if the mesh node is within the coverage ofat least another node. As in the case of PicoMesh node,the PicoStation device is used to provide access to mobile Fig. 6: WiMesh Network Stackdevices since it offers omni-coverage. The NanoMesh nodeis the node of choice for covering large regions with asfew nodes as possible. This is the typical usage pattern forrural areas or for disaster situations, in which a large areaneeds to be covered with a clear line-of-sight using a fewnodes. Together, the two NanoStation devices can connectmesh nodes separated as far as 20 km. Figure 5 showsa typical PicoMesh node with batteries, switch, associatedcabling, the WiMesh server/controller, and a mobile client.The server and the controller housed by the laptop was laterreplaced by Intel NUC device. The mesh-box (not shown infigure) is waterproof, rugged, and enables easy portability anddeployment of the WiMesh System.
2) Mesh Performance Metric and Routing Protocol:
Figure6 shows the WiMesh backhaul network stack which consistsof a Mesh Module on top of a Linux kernel running on anembedded hardware platform. The performance of the meshmodule determines, to a large extent, the overall performanceof the system. The primary job of the Mesh Module is tointerconnect the clients and the server over a wireless multihopinfrastructure. There are three main sub-components of theMesh Module: Route Selector, Route Maintainer, and the QoSModule. While there are several areas where performance canbe improved for a mesh network, two areas are particularly im-portant from the perspective of providing QoS for multimediatraffic: route selection and route maintenance.
Resilient Route Selector : The route selection portion dealswith selecting stable, high performing end-to-end communi-cation routes in the mesh network between the source anddestination pair to provide an acceptable level of quality ofservice (QoS) for multimedia flows. Route selection has beenshown [19] to bring substantial performance improvements,particularly in the achievable end-to-end throughput. Thetraditional hop count metric is not a good approach [37] anda realistic metric needs to consider multiple factors pertaininglink quality. In our previous contribution, the ELP metric [21]was proposed which addresses several limitations of existing Fig. 7: Sample Multimedia Performance Evaluation Tool Sessionrouting metrics including asymmetry of the links, radio inter-ference, logical interference, as well as inter-flow and intra-flow interference. ELP solves the problems of asymmetry andinaccurate probe-approximation by introducing a correctiveconstant in the calculation to bias the estimation in favor oflink loss ratios in the forward direction (data packets).ELP explicitly incorporates the Channel Contention Interfer-ence (CCI) arising from the CSMA-CA based MAC by usingthe promiscuous listening mode [38]–[40] of IEEE 802.11.A node can observe the channel states using the NIC card.ELP also takes into consideration the link capacities as highercapacity links can transmit data at a higher rate and, therefore,occupy the medium for a shorter period. Low capacity links,however, take longer time and will create interference fornodes in vicinity and even for far away nodes that are outsidecarrier sensing range. In ELP, links with higher bandwidth(radio transmission rate) are given a lower link cost. Further,a few existing routing metrics cater to the problems whichcan be caused by frequently changing routing metrics whichcause excessive routing overhead and frequent route shifting(or route oscillations). This is avoided in ELP in addition tooffering quick recovery from failed nodes in ELP to offera more resilient communication solution. Formally, the ELPmetric for a link e is defined as: ELP(e) = Link Loss Ratio(e) × Link Interference(e) × Link Capacity(e)
The ELP metric for a path p is defined as: ELP(p) = (cid:88) link e ∈ p ELP(e)
Overall, ELP enables the selection of high performingend-to-end routes across the mesh network, enabling betterperformance for multimedia flows. More details about theproposed routing metric ELP can be found in [21].
Route Maintainer : The route maintenance component dealswith maintaining end-to-end routes for the duration of the flow.In CSMA-CA based wireless multihop networks, such as IEEE802.11, routes are fragile and often break down because oftransitory interference problems on any of the intermediatewireless links [41]. These problems are particularly severe when several flows traverse the network, creating a highdegree of interference. Route maintenance aims to providestability to the end-to-end route despite the link instabilitiesof wireless links. Efficient route maintenance can providesubstantial performance improvement in mesh networks interms of reducing route breakages. In IEEE 802.11 basednetworks, the standard mandates a retry limit of seven [42]. Ifthere are eight consecutive failed transmission attempts (onetry and seven retries) to the next-hop node, then the link layersends a failure notification to the network layer. Protocols,such as AODV, systematically translate a link breakage into aroute breakage and the intermediate node notifies the sourcenode to find new routes. The Route Maintainer mitigates thisproblem and considers the long-term link performance [41] tooffer a resilient solution.
QoS Module : The main job of the QoS module is to keepan estimate of the available bandwidth in the wireless meshnetwork and to perform admission control for incoming flowsbased on the bandwidth availability on the wireless multihoppath. This bandwidth management is necessary because al-though the system is designed to accommodate the maximumnumber of flows possible, too many flows can overwhelm thewireless mesh networks and cause performance degradationfor existing flows. Bandwidth estimation is primarily based ona hybrid approach involving using a model as well as actualchannel measurements using promiscuous listening at the datalink layer to be as accurate as possible.
F. Additional WiMesh System Components
In addition to the main components, the WiMesh systemconsists of some auxiliary components. One such componentis the performance evaluation tool for the multimedia traffic ofthe WiMesh network. Performance evaluation tools are impor-tant in designing, evaluating, and analyzing the performanceof multimedia traffic of mesh-based wireless network due tothe high bandwidth requirements of such traffic.This performance tool is installed on end stations connectedto the mesh network. The end stations are connected tocameras or microphones. This tool is used for streaming livemultimedia traffic (audio and video) from connected clients to the server and analyzing statistical data of these live streams ina wireless mesh network. The server aggregates data from allvideo/audio flows. The statistical data consist of throughput,delay, jitter, packet loss, video quality, and audio quality andcan be visually viewed in terms of graphs. The server isaware of the connected clients and can separately send remotecommands to each connected client to (1) select video deviceof the client; (2) select video codec of the feed; (3) selectframes per second of the video feed; (4) select audio device;(5) select audio codec; and (6) start or stop the live feed.The tool provides session management and data loggingcapabilities for scheduling experiments and storing the trafficmetrics during the actual transfer of the data. The resultsobtained are used in the final evaluation of mesh routing pro-tocols, metrics, and other communication related mechanisms.The tool uses UDP protocol at the transport layer. Figure 7shows two snapshots of the performance tool session.V. W I M ESH S YSTEM D EPLOYMENT E XPERIENCE
Several tests were carried out on both indoor and outdoorsetup to evaluate the functionality and performance of theWiMesh system. More than a dozen of field trials wereconducted at different times and places. Moreover, due tothe diverse equipment involved, several outdoor visits wererequired to properly setup, power the devices, and to ensureproper interconnections between components.
A. Indoor Testbed
This section describes the experience gained during thedeployment of the indoor testbed for the WiMesh system aswell as the results of the experimental performance evaluationof the WiMesh system.
1) Testbed Environment:
Before designing a testbed, itis essential to physically survey the site to determine itssuitability to host the proposed testbed. There are severalfactors to consider: • Offer easy physical access : The actual act of deploymentinvolves several physical activities including installingwires, putting the mesh node in place, and securing theenclosures among others. Moreover, nodes in any testbedare known to be error-prone and it is sometimes requiredto remove a node or change its connections; • Offer easy wired access : Despite being a wireless net-work, wired connection is eventually needed from acentral switch to each node to facilitate controlling andmanipulating the nodes remotely. This is an impor-tant constraint because installing wires require ducting,drilling, and administrative permissions. Moreover, thecosts become higher as the length of deployed wiresbecome longer. Thus, locations of nodes were selectedfor ease of wired installation and proximity to existingducts where possible; • Offer protection from weather conditions : Weather pro-tection was important as the proposed testbed was notentirely in rooms, but rather in corridors. Therefore, it wasnecessary to select a location where devices are protectedfrom rain and direct sunlight during summers; • Offer relative protection against theft : It was important toselect locations where normal students or visitors cannoteasily access the device physically. This does not meanthat nodes must be in a very difficult to reach place,however, the selected location should require the helpof ladders and other tools to access the device. Someexcellent locations had to be left out because the nodewould become easily approachable by visitors or students.Based on the above factors, most of the nodes were de-ployed on the three-storey A-Block of the Computer ScienceDepartment of Air University, Islamabad, Pakistan.
2) Testbed Design:
A 43 node testbed was deployed, whichis a decent size for indoor wireless experimentation. Thenodes were distributed across different departments of theAir University, however, the larger concentration of nodes(22 out of 43 nodes) was in A-Block, as shown in Figure8. TP-Link WDR4300 routers, running OpenWRT embeddedLinux firmware, based on IEEE 802.11n (MIMO) were usedwith data rates of 300 Mbps. The Power-Over-Ethernet (PoE)technology was used to power each of the routers sinceinstalling power sockets was impractical and dangerous.
3) Deployment of the Testbed:
Deploying the indoor testbedwas a long and grueling process that involved several aspectsincluding purchase of diverse equipment, supervision of on-site labor and technicians, and administrative logistics. TableII shows the testbed specifications.TABLE II: Indoor Testbed Specification
Parameters Description/Value
Numberof Nodes 22CoveredFloors/Area 3 Floors; Covered Area = 16000 sq. ftNodeHardware TP-Link WDR4300,Dual-Radio, Dual-Band (2.4 GHz and 5 GHz),routers with aggregate throughputof up to 750 Mbps, 2 USB portsFrequency 2.4 GHz and 5 GHzPower Source Power Over EthernetOperating System OpenWRT
Since the design of the complete system was well thought-out, the integration of the WiMesh system with the testbedwas straightforward. A laptop or any other device was attachedwhich was configured with the WiMesh server and the asso-ciated services and software. The attached device was usedto monitor the multihop capability of the mesh testbed to seehow it performed. There were some issues regarding the inter-operability of the mesh testbed technologies and the WiMeshserver, however, it was handled appropriately.
4) Lessons Learned:
Despite comprehensive planning,closely overseeing the project, and a “hands-on” approach,a few problems arose: • It was observed that using a monitoring software likethe mesh controller was extremely useful since some-times wireless interfaces on routers malfunctioned or hadconfiguration settings problems, leading to routing andperformance problems. Fig. 8: Routers deployment in the A-Block of Air University • It is important to have error-checking scripts which peri-odically checked active routers for a possibility of “brick-ing,” i.e., sometimes due to erroneous settings, the portsinside a router became internally connected in a loop andmade access impossible. This was especially true when areboot/shutdown remote call was given for routers. Tomitigate this, scripts were installed which queried therouters periodically and removed those specific bridges. • Wiring was a surprisingly difficult issue since using astar topology would have resulted in several kilometersof wires. Therefore, an efficient cabling plan was used. Arelated problem was that the Ethernet wire has a physicallimit of carrying PoE signals for up to 100 meters. Tosolve this problem, switches were installed at requiredlocations that acted as repeaters to regenerate the signals,especially between the buildings.
5) Testbed Results:
Figure 9 shows the performance eval-uation results of the WiMesh system on the indoor testbed.The graphs have been plotted for 95% confidence intervals toshow the variation of results across different scenarios. Figure9(a) shows the Packet Delivery Ratio (PDR) for 1-20 callswhile varying the background load from 2-20 simultaneouscalls. As seen in the figure, the performance of the WiMeshsystem stays acceptable, i.e.,
P DR > even when areasonable load of 40 concurrent calls was placed. There isa dense mesh deployment in the experiment leading to a
90 95 100 105 0 4 8 12 16 20 P a ck e t D e li v e r y ( % ) Background Load (Mbps) (a) Packet Delivery Ratio D e l a y ( m s ) Background Load (Calls) (b) Delay
Fig. 9:
Indoor Testbed Performance Metrics significant number of alternate wireless links due to both, thelarge number of nodes, and the availability of multiple radiosand channels. The high density and multi-channel availabilityresult in high performance of the WiMesh system in terms ofPDR. Similarly, as shown in Figure 9(b), the end-to-end delayis also within acceptable bounds, i.e., < ms . The delaybecomes slightly bigger for higher number of calls since thetraffic load increases compared to the lesser load scenario.Overall, the results show promising performance. B. Outdoor Testbed
This section describes the experience during the deploymentof the outdoor testbed as well as performance evaluation ofthe WiMesh system. This section presents the results obtainedfrom the testbed deployed in the Fatima Jinnah park, locatednearby the Air University, Islamabad, Pakistan. The park wasselected as the site for most of the field trials due to geographicproximity and ease of equipment portability. However, insightsobtained from field trials in other settings are also discussed.
1) Testbed Environment:
For the outdoor testbed, the mainconcern was to ensure that performance evaluation of thesystem was carried out over a relatively large geographicregion with varying terrain. Two nodes located on rooftopsof Air University were also included in the testbed to extendthe wireless range over a larger region.
2) Testbed Design:
Due to logistic restrictions, the exper-iments were carried out for a seven node testbed. Based onvarying needs of wireless antenna height, an extensible stand(up to 14 feet) was used. However, light-weight stands wereused for portability. Wireless coverage was an important issue Fig. 10: Output Testbed Setupand both PicoStations and NanoSations were used for outdoormesh nodes depending on their utility. For mesh nodes withNanoStations, three nodes were deployed in circular patternto cover wider area. A random topology was used with fivenodes deployed randomly in the park while two nodes weredeployed on Air University rooftops, as shown in Figure 10.In order to ensure relatively large distance between nodes,the average distance between nodes was around 0.75 km withsome wireless links spanning 2 km. Similar to the indoortestbed, the OpenWRT embedded Linux OS was installed onthe PicoStations and NanoStations. PoE was used to powerthe mesh nodes. This decision was even more pertinent for theoutdoor testbed in order to avoid the dangers of live electricity,especially on wet terrains. Dry portable batteries were used topower outdoor mesh nodes in order to avoid battery refillingand spillage. Custom-built outdoor cabinets were used for therooftop nodes since these installations were permanent andrequired protection from weather. The cabinets were installedwith horizontal slits on sides for ventilation.
3) Lessons Learned:
Several visits were performed to theoutdoor Fatimah Jinnah Park field site to test various featuresof the WiMesh system. The initial field trials resulted inseveral problems that prevented successful execution of theWiMesh system. Results were recorded only for the final fieldtrials. Some of the problems observed during field trials andsubsequent improvements to the WiMesh system were: • When high antennas were used, they were sometimesunstable due to wind. This problem was mitigated byinstalling small hard pads on end of pole legs and thenembedding these legs in the ground. • Ethernet switches sometimes malfunctioned, especiallywhen there was even a slight difference in the appliedvoltage (applied ∼ volts vs. ∼ − volts) normal range.The malfunctioning did not cause the mesh nodes to stopcommunicating, but rather started a never-ending cycleof disconnections and re-connections which resulted inintermittent connections to server over the mesh. Thishardware fault was discovered after much difficulty asthe root cause was not obvious; • A communication problem was discovered that somemesh nodes were not aware of the existence of the serverunless specifically advertised by the server mesh router. This issue was handled by providing Host-Network As-sociation (HNA) announcements in the routing protocolconfiguration. The scripts were appropriately updated; • The range of some of the wireless hardware was ex-tremely poor in outdoor scenarios. More notably, theUbiquiti PicoStation performed quite poorly in outdoorsfor distances greater than half a kilometer; • Sometimes, a user would be online, however, he would beshown offline. This user offline issue was due to the factthat the periodic update mechanism was flawed wherebyeach node was required to send data periodically to theserver. The socket destruction technique was employedfor detecting out of range users to solve this problem; • There was previously no mechanism of acknowledgingSMS texts, so the sender party had no informationwhether the text had been delivered or not. This problemwas resolved by including notification as soon as messageis successfully received at the other end; and • When a user sent a video stream request, the sendinguser did not know whether the destination had acceptedthe request or not. This was fixed by the sender gettinga confirmation from the receiver.
4) Testbed Results:
The experiments were repeated underdifferent timings and traffic load conditions. Figure 11 showsthe performance evaluation graphs for 95% confidence inter-vals. It is pertinent to note for all metrics, the results areslightly worse than the indoor case and this is due to severalreasons including long outdoor wireless links with fading, in-terference and even weather conditions. Figure 11(a) shows thePacket Delivery Ratio (PDR) for varying background loads vs.varying number of calls. As the results show, the performancedegrades as the load increases, however, the performance stillremains acceptable. Figure 11(b) shows the Packet Loss Ratio(PLR) which corresponds indirectly to the PLR and showssimilar trend of increasing loss with increased load. Figure11(c) shows the end-to-end delay which are elevated comparedto the indoor scenario. Figure 11(d) shows the jitter observedfor the calls, which is again considered acceptable. Overall, theresults show that the performance degrades slightly comparedto the indoor case, however, given the long wireless linksand the outdoor environmental factors, such degradation isexpected.
C. Ziarat Deployment
WiMesh system was deployed in the Ziarat mountaniousregion of Pakistan after the Ziarat earthquake disaster [6] [7].This section shares WiMesh deployment experience, perfor-mance evaluation results, and the lessons learned during theZiarat deployment.Ziarat is a remote mountainous region in South-West Pak-istan with several villages and small towns scattered over theSuleiman mountain range stretching for hundreds of kilome-ters. It is sparsely populated and modern amenities such aselectricity and telecommunication are sporadically available.Ziarat was hit by a catastrophic earthquake of magnitude of6.4 in 2008. The WiMesh system was deployed after theearthquake.
85 90 95 100 105 0 2 4 6 8 10 12 P a ck e t D e li v e r y ( % ) Background Load (Calls) (a) Packet Delivery Ratio P a ck e t Lo ss ( % ) Background Load (Calls) (b) Packet Loss Ratio D e l a y ( m s ) Background Load (Calls) (c) Delay J i tt e r ( m s ) Background Load (Calls) (d) Jitter
Fig. 11:
Outdoor Testbed Performance Metrics
Apart from the problems of disaster and the subsequentrehabilitation, the major problem faced by these villagerswas the fact that they had no mechanism of communicationwith each other and there was no cellular coverage in thisregion. This was particularly troublesome during an emergencysituation where the men working in their gardens and fieldscould not be reached immediately. Before the WiMesh de-ployment, the mechanism that they used was that a personhad to go physically to the fields and informed them of anyemergency situation. However, since the mountain ran acrossits length and divided the residential areas from the fields,it made accessibility to villagers working in the fields evenharder for any emergency situation. Another problem facedby the villages was the lack of communication between thewater supply room (generator powered) and the villagers.Since the time for water for the fields was rationed amongdifferent villagers, so it would have been immensely helpfulfor coordination if people could somehow communicate.These problems provided an ideal situation and a stringenttest for the WiMesh deployment. In particular, two villagesin Ziarat, Ahmadun and Gogi, were visited several times forpractical testing and final WiMesh deployment.
1) Deployment Logistics:
There were several aspects thatwere unique and challenging in deploying WiMesh to Ziarat.Perhaps the most interesting aspects were rather non-technical.The first mission was to take the villagers in confidence aboutthe strange equipment and techies that would be roamingabout. To put things into perspective, a 300 years old villagenamed “Gogi” was selected for the deployment, which is en-trenched deep inside the mountains in Ziarat with a population of around 2000-3000. It is shouldered on two sides by massivemountains and a semi-paved 20 km road is the only accessoff the main Ziarat road. The tribal people of this regionare known through centuries for their bravery, pride, andhospitality. Fortunately, the lead author had personal contactwith some people in the village to gain access for deploy-ment. In addition, an agreement was signed with the Provin-cial Disaster Management Authority (PDMA), BalochistanProvince of Pakistan, to become WiMesh deployment officialpartner and to help with logistics, regulation compliance, andother aspects of deployment. PDMA’s help in overcomingthe regulatory compliance was important because the nationaltelecommunication authority has strict regulations over thetransmission power/range of outdoor Wi-Fi devices, and theWiMesh deployment plan was to use the maximum powerpossible in this remote region for optimal communication.Information exchange sessions were held where the villagersshared their vows due to the earthquake and, in general,they were provided awareness about the WiMesh system (inlayman terms) and how it could help ease communicationproblems. The village itself has a small mountain dividing thevillage into two lateral sections with one area covered withhectares of apples, cherry, and apricot farms while the othersection contained the housing. Even though, a heavenly town(frequented yearly by the lead author), it is plagued by severalproblems which have worsened after the earthquake.The deployment team was informed that one of the prob-lems was that when men worked in the fields, the womenback home could not contact them in case of emergencies orjust for communication since there is no telecommunication (a) Ziarat Mountain Range (b) WiMesh Deployment Team(c) WiMesh Ready for Deployment (d) Villagers Gathered for WiMesh Demonstration Fig. 12:
Ziarat Deployment coverage and electricity is rarely available especially after theearthquake. It was demonstrated to the villagers how WiMeshcould help by starting with an initial deployment of two meshnodes nearly 1.5 km apart on top of the small mountains anddemonstrated to the utmost joy of the villagers how they couldmake calls to each other and how solar panels with batteriescould be used to power the nodes indefinitely.Other logistic concerns included portability of equipmentsince even the roads inside the village are tough to trek ordrive on and it is not easy to carry heavy equipment.
2) Performance Results:
Figure 13 shows the performancemetrics for three calls in the Ziarat deployment. Figure 13(a)shows the Packet Delivery Ratio (PDR) for varying back-ground loads. As the results show, the performance degradesas the load increases, however, the performance still remainsacceptable. Figure 13(b) shows the end-to-end delay for threecalls load.
3) Lessons Learned and Challenges:
Some of the mainlessons learned during the Ziarat deployment include: • The WiMesh team was pleasantly surprised at the extremehospitality of the villagers and the way they welcomed the team into their homes and their lives. Most of thedeployment was straightforward and automated, however,there were still aspects of deployment that needed somemanual labour such as hoisting the poles (as shown inFigure 12(b)) and fixing solar panels. Due to the prioragreements, connections, and villagers full support, thevillagers were willing to provide any kind of cooperationincluding providing man-power for the manual labour thatwas very helpful in the success of the deployment. • The WiMesh team faced several challenges with PDMApartnership mainly due to the fact that it is a pure govern-mental organization with its specific channels and stan-dard operating procedures, some of which can be quitetime consuming. Good deployment planning, however,helped overcome some of these limitations. The moreserious problem was the fact that during the 19 months ofthis project, the PDMA Balochistan had seen the changeof about five Director Generals. Each time, the PrincipalInvestigator had to work from scratch on developinglinkage with the new Director General, explaining to him (a) Ziarat PDR (b) Ziarat Delay Fig. 13:
Ziarat Deployment Performance Metrics the motivation and utility of the project and the progressmade so far. Some were considerate and helpful, whilesome were not interested and this required significanteffort on part of the Principal Investigator to keep themin loop and motivate them. • The plug-and-play nature of WiMesh did make deploy-ment quite easy, as it was realized that any kind oflast minute “tweaks” and adjustments would have beenimpossible or extremely difficult without this feature.Moreover, sometimes the network needed to be restarteddue to energy depletion (explained below) or some tech-nical fault and it was a big advantage that simple villagerscould simply press a few buttons and our automatedscripts would render the system in a functioning statewithout any specialized intervention. • It was realized that assumption of indefinite power supplythrough a combination of solar panels and batteries didnot hold true since this region had mostly cloudy weatherwith sparse sunshine throughout the year except for thefew months of summer. The region has long and harshwinters and few months of sunny summers. It was learnedthat solar panels still generate electricity even in thecloudy weather, albeit in significantly smaller quantities.Therefore, the project team decided to use better qualitysolar panels and bigger batteries, however, this cameat the cost of compromising the cost-effectiveness. Inaddition, the team modified the routing protocol andmetric to further restrict unnecessary routing messagesto conserve energy. Despite all these changes, a 24/7operation could not be guaranteed. Thus, the network wasprimarily used during the days. However, this limitationhad minimal implication as the villagers had a naturallifestyle and slept early around 7pm in winters and 8pmin summers. The plug-and-play nature of WiMesh againhelped in making sure that villagers were able to easilyrestart the network if it went down during the long winternights. • Since, the poles were of varying heights (and sometimes makeshift), the project team resorted to designing the Eth-ernet cables of varying lengths themselves and installingthe RJ-45 connectors. Due to the custom design of theconnectors and cables, sometimes these connectors wouldbecome loose due to rough handling and caused all kindof connectivity issues. This situation was exacerbated bythe harsh deployment scenarios. To add to the complexity,the connectivity issues could be partial or time-varying aswell, i.e., instead of a complete disconnection, we couldget partial connectivity or high packet losses. Sometimesseveral hours would be wasted in diagnosing connectivityissues. This was particularly true for the mesh nodehosting the server which could bring down the completenetwork. An effective and simple solution that eventuallysolved our problem was to use off-the-shelf Ethernetcables with professionally installed connectors, which donot come loose despite rough handling. This solved mostof our connectivity problems. • Due to the success of WiMesh deployment, the villagersrequested to further extend the scope of the project andto connect the WiMesh network to a Base TransceiverStation (BTS) several kilometers away. The team in-vestigated and did an initial feasibility analysis for thisrequest. It turned out that there was an open-source soft-ware called OpenBTS which offered open-source BTSfunctionality for remote regions and has been deployed inimpoverished areas of Africa [43]. The team investigatedthe complexities of integrating WiMesh with OpenBTSand interfacing with the commercial telecommunicationsprovider. Due to the lack of time and sufficient resources,the team eventually decided to pursue it as a futureproject.VI. G
ENERAL I NSIGHTS AND L ESSONS L EARNT
This section reports some of the salient insights, distilledfrom the project experience in developing and deploying theWiMesh system. A valuable contribution of this work is thatdifferent kinds of unexpected causes of failure were docu- mented that may occur when deploying wireless technologiesfor emergency management, which are expected to benefitresearchers undertaking such deployments in the future. Inparticular, the section describes how these insights add to thebody of knowledge and also report where these findings arealigned with or discordant with existing wisdom. This sectioncomplements the earlier discussions in Sections V-A4 andV-B3 on the salient lessons learned during the experimentationwith the indoor and the outdoor testbeds, respectively. A. Sustainability of Wireless Based Emergency Networking
To develop a sustainable solution, it is important to factor inthe unique requirements of the particular deployment area. Itis well known in the ICT for development (ICTD) communitythat it is a real challenge to keep a rural wireless networkrunning for long-term. Most projects fail to go beyond thepilot stage [44] and techniques such as resource pooling [45]can help. Since WiMesh is low-cost, rugged, and customizedfor the environment, therefore, the system is still operationalin some villages, which supports its sustainability aspect.
B. Power Related Issues
Apart from the lack of a sustainable financial model, themost common operational cause underlying the lack of sus-tainability of most wireless networking projects in the ruralareas is the high cost of dealing with the poor quality ofpower, which is a very common issue in rural areas of thedeveloping world [44]. The poor power quality also leads tohigher failure rates of components, which means that “the realcost of power is not the grid cost, but is the cost of overcomingpoor power quality problems” [44]. This is because low-quality power necessitates an additional burden of deployingadditional infrastructure such as the use of power controllers,batteries, and solar-powered backup power solutions.
C. Anticipating Malfunctions and Fault Diagnosis
For building a sustainable solution, it is important to havethe ability to anticipate malfunctions and diagnose faults. Anumber of authors have written about simplifying and automat-ing fault diagnosis, and interested readers are referred to [46]and [47]. Subramanian et al. [48] have shown that low-costcommunity wireless networks can malfunction in a myriadways from complete failures (such as hardware board failures,corruption of the flash memory cards, and lightning strikes) aswell gradual degradation over time (such as interference fromexternal sources, effects of unreliable power, and rainfall).As noted in Sections V-A4 and V-B3, it was also discoveredthrough this project experience the great utility of having afeatured monitoring software since it is very common forwireless interfaces on low-cost devices to malfunction (oftendue to imperfect power supply). This malfunction then leadsto knock-on problems such as intermittent performance, cyclicloop of disconnections and reconnections, or routing issuesthat are hard to troubleshoot back to the offending cause.
D. Open-Source Community Software Contribution
We believe that it is necessary for the wireless networkingfor emergency community that we develop an ecosystem thatencourages sharing of insights and the communal reuse ofbasic building blocks, which practitioners and researchers canuse to develop customized solutions more efficiently, morequickly, and with lesser resources. In the same spirit, we haveleveraged existing open-source solutions where available, andare releasing the custom-developed source code of the WiMeshsystem, as well as detailed instructions and usage guidelines.These resources can be accessed publicly at the website of theWiMesh project (https://sites.google.com/site/wikiwimesh/).VII. A
CKNOWLEDGEMENT
The authors would like to extend their thanks to the NationalICT R & D Fund Pakistan for providing the financial supporttowards this project.VIII. C
ONCLUSION
This paper presented the WiMesh disaster communicationsystem including its conception, design, implementation andfield trials. The WiMesh system leverages the wireless multi-hop capability of the mesh network and the Wi-Fi accessibilityof mobile devices to connect to the nearest mesh node. Due tothe nature of their application domain, disaster communicationsystems need to have specific traits of size, portability, power,cost, customization, ease of installation, wireless coverage,and availability of hardware and software. Some of thesetraits, such as cost and availability, are especially critical fordeployment in developing and third world countries. Thesefeatures were considered important during the design anddevelopment of the WiMesh system. Furthermore, as discussedin the paper, the WiMesh system meets all of these criteria.The paper provided architectural and design details of theWiMesh system including design trade-offs, pitfalls, and chal-lenges faced during the design, development, and deployment.Extensive indoor and outdoor field trials were carried outto demonstrate the functionality and to collect performancemetrics for the WiMesh system. Details of these field trialsalong with performance metrics results were also presented inthe paper. These field trial results demonstrate that the WiMeshsystem can handle several dozen concurrent VoIP calls withoutnoticeable performance degradation, even in the presence ofsignificant background traffic. There are a number of areasthat can be further improved. For instance, 5G technology ismaking inroads in the wireless ecosystem and it would beimportant to leverage that strength into the WiMesh solution.R
EFERENCES[1] P. Meier,
Digital humanitarians: how big data is changing the face ofhumanitarian response . Routledge, 2015.[2] J. Qadir, A. Ali, R. ur Rasool, A. Zwitter, A. Sathiaseelan, andJ. Crowcroft, “Crisis analytics: big data-driven crisis response,”
Journalof International Humanitarian Action , vol. 1, no. 1, p. 12, 2016.[3] O. Onireti, J. Qadir, M. A. Imran, and A. Sathiaseelan, “Will 5G see itsblind side? evolving 5G for universal internet access,” in
Workshop onGlobal Access to the Internet for All , pp. 1–6, ACM, 2016. IEEE Internet Computing ,vol. 12, no. 1, 2008.[9] Y. Zhang, N. Ansari, and H. Tsunoda, “Wireless telemedicine servicesover integrated IEEE 802.11/WLAN and IEEE 802.16/WiMAX net-works,”
IEEE Wireless Communications , vol. 17, no. 1, 2010.[10] Z. Shao, Y. Liu, Y. Wu, and L. Shen, “A rapid and reliable disaster emer-gency mobile communication system via aerial ad hoc bs networks,” in , pp. 1–4, IEEE, 2011.[11] U. Zakia, M. W. Turza, E. Karim, T. Z. Moumita, and T. A. Khan,“A navigation system for rescue operation during disaster managementusing LTE advanced network and WPAN,” in
Information Technology,Electronics and Mobile Communication Conference (IEMCON), 2016IEEE 7th Annual , pp. 1–6, IEEE, 2016.[12] Z. O. N. Martinez, O. M. Arias, P. A. L´opez, and S. A. Ugarte,“Hybrid wireless ad hoc network design based on WIFI technology forfacing seismic catastrophes,” in
Electrical and Computer Engineering(CCECE), 2016 IEEE Canadian Conference on , pp. 1–6, IEEE, 2016.[13] O. Chipara, W. G. Griswold, A. N. Plymoth, R. Huang, F. Liu, P. Jo-hansson, R. Rao, T. Chan, and C. Buono, “WIISARD: a measurementstudy of network properties and protocol reliability during an emergencyresponse,” in
Proceedings of the 10th International Conference onMobile Systems, Applications, and Services , pp. 407–420, ACM, 2012.[14] S. M. George, W. Zhou, H. Chenji, M. Won, Y. O. Lee, A. Pazarloglou,R. Stoleru, and P. Barooah, “DistressNet: a wireless ad hoc and sensornetwork architecture for situation management in disaster response,”
IEEE Communications Magazine , vol. 48, no. 3, 2010.[15] Q. T. Minh, K. Nguyen, C. Borcea, and S. Yamada, “On-the-fly estab-lishment of multihop wireless access networks for disaster recovery,”
IEEE Communications Magazine , vol. 52, no. 10, pp. 60–66, 2014.[16] H. Aiache, R. Knopp, K. Koufos, H. Salovuori, and P. Simon, “Increas-ing public safety communications interoperability: the CHORIST broad-band and wideband rapidly deployable systems,” in
IEEE InternationalConference on Communications , pp. 1–6, IEEE, 2009.[17] H. A¨ıache, V. Conan, G. Guib´e, J. Leguay, C. Le Martret, J. M. Barcelo,L. Cerda, J. Garcia, R. Knopp, N. Nikaein, et al. , “WIDENS: Advancedwireless ad-hoc networks for public safety,”
IST Mobile and WirelessCommunications Summit (IST Summit), Dresden, Germany , 2005.[18] E. Del Re, S. Morosi, S. Jayousi, and C. Sacchi, “Salice-satellite-assistedlocalization and communication systems for emergency services,” in
Wireless Communication, Vehicular Technology, Information Theory andAerospace & Electronic Systems Technology, 2009. Wireless VITAE2009. 1st International Conference on , pp. 544–548, IEEE, 2009.[19] D. S. De Couto, D. Aguayo, J. Bicket, and R. Morris, “A high-throughputpath metric for multi-hop wireless routing,”
Wireless Networks , vol. 11,no. 4, pp. 419–434, 2005.[20] F. Kohnh¨auser, M. Stute, L. Baumg¨artner, L. Almon, S. Katzenbeisser,M. Hollick, and B. Freisleben, “SEDCOS: A secure device-to-devicecommunication system for disaster scenarios,” in
Local Computer Net-works (LCN), 2017 IEEE 42nd Conference on , pp. 195–198, IEEE, 2017.[21] U. Ashraf, S. Abdellatif, and G. Juanole, “Route selection in IEEE802.11 wireless mesh networks,”
Telecommunication Systems
ACM SIGOPS OperatingSystems Review , vol. 35, pp. 230–243, ACM, 2001.[37] D. S. De Couto, D. Aguayo, B. A. Chambers, and R. Morris, “Per-formance of multihop wireless networks: Shortest path is not enough,”
ACM SIGCOMM Comp. Comm. Review , vol. 33, no. 1, pp. 83–88, 2003.[38] Y. Yang and R. Kravets, “Contention-aware admission control for adhoc networks,”
IEEE Transactions on Mobile Computing , vol. 4, no. 4,pp. 363–377, 2005.[39] L. Chen and W. B. Heinzelman, “QoS-aware routing based on bandwidthestimation for mobile ad hoc networks,”
IEEE Journal on Selected Areasin Communications , vol. 23, no. 3, pp. 561–572, 2005.[40] K.-H. Kim and K. G. Shin, “On accurate measurement of link qualityin multi-hop wireless mesh networks,” in
Proc. of the 12th Annual Intl.Conf. on Mobile Computing and Networking , pp. 38–49, ACM, 2006.[41] U. Ashraf, S. Abdellatif, and G. Juanole, “Route maintenance in IEEE802.11 wireless mesh networks,”
Computer Communications , vol. 34,no. 13, pp. 1604–1621, 2011.[42] LAN/MAN Standards Committee and Others, “Part 11: Wireless LANmedium access control (MAC) and physical layer (PHY) specifications,”
IEEE-SA Standards Board , 2003.[43] J. Mpala and G. van Stam, “Open BTS, a GSM experiment in ruralZambia,” in
International Conference on e-Infrastructure and e-Servicesfor Developing Countries , pp. 65–73, Springer, 2012.[44] S. Surana, R. K. Patra, S. Nedevschi, M. Ramos, L. Subramanian,Y. Ben-David, and E. A. Brewer, “Beyond pilots: Keeping rural wirelessnetworks alive,” in
NSDI , vol. 8, pp. 119–132, 2008.[45] J. Qadir, A. Sathiaseelan, L. Wang, and J. Crowcroft, “Resource pool-ing for wireless networks: Solutions for the developing world,”
ACMSIGCOMM Computer Comm. Review , vol. 46, no. 4, pp. 30–35, 2016.[46] S. Surana, R. Patra, and E. Brewer, “Simplifying fault diagnosis inlocally managed rural wifi networks,” in
Proceedings of the Workshopon Networked systems for developing regions , p. 1, ACM, 2007.[47] V. Gabale, R. Mehta, J. Patani, K. Ramakrishnan, and B. Raman,“Deployments made easy: essentials of managing a (rural) wireless meshnetwork,” in
Proceedings of the 3rd ACM Symposium on Computing forDevelopment , p. 10, ACM, 2013.[48] L. Subramanian, S. Surana, R. Patra, M. Ho, A. Sheth, and E. Brewer,“Rethinking wireless for the developing world,”