MobileActive.org

The Internet has enabled people from all over the globe to communicate and share information. Yet over two-thirds of the world’s population remains disconnected from the Internet, and many of these people live in poor, remote areas in the developing world. Organizations struggle to cross the last mile to these communities that are difficult to reach geographically, are often only fluent in local languages, lack reading and writing proficiency, and have limited experience with information technology. Unidirectional broadcast media such as the radio, television, and written periodicals can be localized to a region or community, but they are not micro-local, demand-driven, and do not offer transparent space for feedback and community discussion. Local people may seek information from experts or others in their personal social networks, but misinformation abounds and advice is fragmented across multiple sources. There are few comprehensive, on-demand sources for relevant, high-quality knowledge. This is precisely what the Internet provides for those who have access.

There are different  scenarios where it is more desirable to have a method of communication that does not depend on cellular or Internet backbone infrastructure:

• Sometimes that infrastructure is down - for example due to natural disaster, or man-made "shocks" to the system,  from a terrorist attack to simply a massive gathering of people who want to communicate all at the same time, for example at a ball-game or in a conference hall.
• Sometimes infrastructure is just not there - like in some developing countries or regions, or rural areas.
• Sometimes, one is interested in circumventing censorship, in order to enable civic communications or in order to get news out of a country or conflict zone.
• Sometimes one just wants to save money and other costs - why use an expensive infrastructure that was made to get information to the other side of the world, and pay a service tax to the operator, when communication is local by nature? For example for internal communication in a rural village, campus, or enterprise.

Aside from the cases where infrastructure-based communication is not the best way to go, close proximity device-to-device communications offer several added advantages of their own:

• A broadcast can be targeted to a limited geographic area without the need to use heavy GIS servers and requiring all participating end points to report their absolute locations.
• Opportunistic communications with previously unknown parties, where the co-location serves as a discovery and bootstrap mechanism, and knowing absolute "global" addressing (email address, phone number, etc.) is not required in advance.
• Natural mobility patterns of people or vehicles carrying the mobile devices can be leveraged to physically rout information from place to place, or from source to destination. People and vehicles can become "data-mules", or a "sneaker-net". For example, a bus carrying wifi enabled device can act as a "data-mule" and collect information from schools or villages along its path, delivering it to the internet when it reaches a connected access point. People moving away from a natural disaster or a civic demonstration can carry with them pictures, messages, and news from the disconnected zone to the outside world.
• The mobile device can act as a sensor in the physical world - depending on the type of short-range radio used, it can sense peers who are physically proximate with varying accuracy.
• In some cases the close-proximity communication adds improved security and authenticity, since all parties must be within a certain physical range of one another.

For all of the above scenarios there is a set of common technical requirements and features. The idea behind Comm.unity is to unite them into one core framework that allows development of applications for all of these cases. Different scenarios would call for more specific adaptations (for example added security for some of the scenarios), so Comm.unity is designed to be very modular, and allow developers to use just what they need for the applications that they build on top of it. It is also designed to be extensible by the developer community, so new features and modules could be added. This system is not meant to replace infrastructure, but rather augment it.