The Egypt/Big Game Problem
Protestors in Tahrir Square, sports fans leaving the big game, and users in isolated areas all face a similar difficulty: Smartphones provide the means for entirely local communication, but devices follow complex routing sequences that divert data to centralized nodes before delivering it to nearby recipients. This is problematic in at least three (non-emergency) situations: (1) at concerts, sports events, and other large gatherings when specific infrastructure is overloaded; (2) in dark spots and remote areas; and (3) when centralized control is undesirable, due to filtering or blocking by those in control.
The Intervention:
Imagine a smartphone app that allows protestors to coordinate action without worry that an unsympathetic government will throw a kill switch. Each person can support and add to a localized chat, which can be anonymous or even encrpyted for theoretically uncensorable point-to-point communications. Or, imagine an app that helps hikers in remote areas communicate, even if there is no existing wireless infrastructure.
Learn More:
Existing mesh networking protocols can run on (some) mobile platforms, and infrastructure independent applications can provide VoIP calls, SMS and other mobile services over WiFi. The Serval project in particular has shown the viability of this approach. Once software is made to run on a particular mobile platform, adoption can proceed incrementally, with specific users or groups selecting applications with a particular use in mind.
Links:
Serval – Device-to-device calling over WiFi without infrastructure for Android
Dovetail – Local chat for smart phones (in development) for Android and iOS
Musubi – Locally stored, encrypted communications app for Android
Auto-BAHN — Bluetooth-based emergency communications app for Android
I’m Getting Arrested – Application that alerts preselected contacts of arrest due to civil disobedience for Android
Twimight: Application that passes Tweets locally via Bluetooth until they can be sent to the cloud for Android
What’s Missing:
APIs: Developers working in this space report that feasibility is highly dependent on a phone’s operating system. Currently, application development is almost entirely limited to the Android OS. Even on Android, accessing a phone’s ad hoc mode requires root access, voiding the warranty. Demand by consumers, application developers, and/or a push by regulators to require flexible access to ad hoc wireless networking modes across operating systems would significantly lower the barriers to adoption.
Security: Authentication and identity are a problem in a ad hoc mesh network, and these applications should be could considered insecure. The asynchronous nature of some mesh communication intensifies these problems. However, the Musubi application and the theoretical approach suggested by Auto-BAHN’s developer demonstrate that even the encryption can be surmounted in this context.
Open Questions:
Power: Should the app start to run when standard connection is not available? This is the approach taken by Auto-BAHN, but it may drastically reduce battery life.
Network: Is WiFi the best transmission method for these applications? Tests run by the Serval project suggest that WiFi may be sufficiently robust for short-range mesh applications using routing protocols like OLSR or B.A.T.M.A.N. However, projects like Auto-BAHN that anticipate use in crowded urban areas instead use Bluetooth with message flooding for a less complex implementation. Ultimately, both solutions proceed under current spectrum constraints; the availability of unlicensed spectrum might allow the development of more sophisticated mesh networking applications on end devices.