INCLUDE_DATA

Following up yesterday’s post about mesh networking in disaster situations, The Register had a story about doing just that–and a project that was being coordinated in Australia to provide mesh communications via Android handsets.

The Serval Project (named after the African cat) seeks to create a method by which communications networks can be quickly resurrected after disaster situations through a combination of mobile-to-mobile mesh and air-dropped communications ‘towers’.  They’ve put together a demonstration system capable of relaying VOIP (which seems to be their focus) in areas without connectivity, and their project scope indicates that they also plan to deploy the project to create mobile networks in areas without any connectivity.

One of the interesting details that they’ve noted is their plan to allow users to dial other users with the same phone number that they would normally make use of were regular connectivity available; they focus on disaster recovery situations and note that having to remember a new number in such a situation to contact a loved one would be unnecessary stress.

They plan to release their code under a (not specified at this time) open source license, and as implied above their target audience appears to be Android handset users–though given the open-source nature of the project, a bit of scope creep is likely inevitable; porting to other mobile operating systems (or providing compatibility to non-mobile VOIP programs) is likely, as is expansion of capabilities to text.

Hopefully, this project will succeed; there have been a number of projects over the years to research mesh networking, but none of them have gotten that far off the ground–the majority appear to have been University projects; allegedly, Microsoft has a department focusing on developing meshnets as a useful networking tool as well.  MITRE did release some code several years ago, but unfortunately that project looks to have been abandoned; the last date on the page is 2006, and the code appears to have been aimed at the 2.2 kernel–not exactly modern stuff.

The chief difficulty that appears to arise is the inability to gain enough adoption to create and perpetuate the network.  Without widespread adoption, there’s not enough mesh to make the network usable; without a reason to adopt, there’s no widespread adoption–meshnet geeks are relatively few and far between on the ground.  While this would be supremely useful in a disaster situation, unless it was deployed before the disaster it would likely not get a chance to be used–after all, if you can’t access the regular networks, you can’t obtain the app to access the irregular networks.

Adding it as a capability to the stock Android OS would be one route to take, though this is unlikely to work–the handset manufacturers would be unlikely to allow deployment to existing handsets.  Adding it to the market as an app still brings up the ‘critical mass’ problem; without enough people, the app is more or less useless.  Targeting specific groups (hikers trying to keep in touch; people who want to be prepared for a disaster) still brings up a limited audience, though successful use might spur adoption in a wider sense.  Tying it into a social network might have some promise–given that the mesh involves sharing transmission resources to communicate.  Perhaps an exclusive beta targeted to people who live geographically close to each other might allow enoiugh adoption to seed a critical mass?

Whichever route is taken, though, it would be in the best interests of many people for Serval to succeed.  With communications already an essential part of life, interruptions in such will just become more and more disruptive over time.

Communications are important.  Living in today’s world, most people expect to have instant or near-instant access to communication networks, whether by cellphone, computer, smartphone, or other device.  These networks depend on extensive infrastructure, maintained by the various organizations and companies that have an interest in ensuring that the communications flow freely.  These are weak points; in cases of extensive disasters–fires, floods, earthquakes, hurricanes and the like–or in the case of man-made interruptions–terrorism or blackouts–the infrastructure becomes compromised.  With this interruption in communications, there are difficulties not only to the people who live in the affected area but to the emergency workers trying to help them.

To make matters worse, if communications are only partially interrupted, the remaining nodes will quickly become overloaded due to the high demand that far outstrips the supply.  Communications between rescue workers might suffer intermittent outages; text messages may be delayed; members of the public may become panicked over the inability to contact loved ones.  These difficulties can be mitigated:  individuals can be instructed to reserve use of the available communications for emergency personnel; portable communications nodes can be provided; alternate means of communications–radios operating on emergency or commercial frequencies–can be issued.  

This provides certain difficulties:  by nature, the radios are restricted to emergency personnel; they need to be stockpiled and issued after the fact; they add expense to an already expensive undertaking.  Smartphones are widespread and useful in situations other than emergencies and available to the general public, but usually rely on the cellular infrastructure for communications.

However, smartphones do have certain advantages that other radio devices do not have–namely, diversity in programming and in frequency usage that can be potentially leveraged to provide for at least some communications in areas that have been deprived of their primary communications infrastructure.

Generally, smartphones are posessed of three radios: one for the cellular network (which may itself operate on more than one band, but that is not relevant at this time), one for 802.11 networks (“wifi”), and one for bluetooth communications.  Numerous programs already exist that leverage the use of wifi networks to avoid connection charges that might exist on the cellular network; this functionality is not new–though it is somewhat limited to a couple hundred feet from an access point, depending on local conditions, and usually relies on an active internet connection for functionality.  

Wifi does have an alternative mode, however, that could have potential for at least short-range communications.  Ad-hoc networking allows two or more devices to interface without the infrastructure normally required to set up an effective network connection (though, as of this writing, it appears that this mode is not officially supported by various smartphone operating systems).  Extensive research has been done in the means to set up such networks, and they have been (in the case of mine communications) been used for VOIP.

Setting up such a system would require that the smartphone handsets be populated with an app to support the routing required; said app would need to set up an ad-hoc access point and connect to any systems within range.  As handsets are inherently more mobile than fixed access points, these connections would not necessarily be stable; VOIP instantiations may not be entirely practical as they require an unbroken chain.  Text, conversely, can be cached and forwarded when a usable route is found.  In combination with multicast capabilities, it may be possible to discover practical routes from one handset to another in a relatively small-scale mesh network with minimal delay; in combination with routers at the edges of the affected areas providing connectivity to standard internet resources, communications with the outside world can be restored as quickly as a route can be built.

The app to enable these communications would require certain functionalities:  setting up and maintaining an ad-hoc access point; caching traffic in the case of connectivity interruption; agile route discovery; QoS reporting to assist other devices in their route discovery; and, naturally, originating and forwarding traffic.  Ensuring widespread distribution before the disaster or service interruption would be necessary; therefore, partnering with an organization such as the Red Cross or allowing the use of said app to create small-scale social meshes to encourage uptake would be required.  Post-disaster, it would be more difficult to load the app onto devices, so the ability to install the app onto handsets from computers would be helpful–the Android OS allows the user to allow apps from arbitrary sources, so it would be most suitable for this effort.

Creating, near-instantly, a communications network in a disaster area would help to save lives and to speed the recovery of the area, as well as reducing panic and distributing valuable information to persons affected.  Leveraging the existing resources that most persons would already have would make the implementation much less expensive; the humanitarian nature of the cause would be attractive to a number of open-source developers, and development costs would be reduced accordingly.