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.
Comm.unity is a software framework in development, which is intended to allow developers and researchers to easily create applications that are proximity aware and socially aware, and can run on a large set of existing consumer devices. It implements a wireless, device-to-device information system that bypasses the need for any centralized servers, coordination, or administration. It is designed to span an extensible set of radio interfaces (WiFi, Bluetooth, IR, etc.).
Comm.unity is targeted for field deployment as well as for supporting advanced mobile-phone-based research. The feature-set for field deployment consists of a basic set of functionalities that are simple and explicitly defined. The research aspects include additional features that are more experimental, or support collection of research data - for example modules for performing logging a user's behavior and other sensor data, performing data-mining, machine learning and other types of on-device learning of a user's context and social activity.
- Communications unity: The current state of the close proximity networking space is very fragmented - Many different standards and technologies, and even devices with similar radios (e.g. Bluetooth or wi-fi) are not always able to communicate directly to each other due to limitations imposed by vendor, service provider, or simply lack of appropriate software. Comm.unity aims to resolve that by creating software and protocols that could run on a large set of different mobile and stationary devices, and allow them to directly talk to one another as long as they have similar physical radio interfaces. This means, for example, that iPhones would be able to discover and communicate with Nokia Symbian phones or Android phones via Bluetooth, no matter what mobile operator they belong to, and a WinMobile phone could connect to any Windows, Mac, or Linux computer via wi-fi without any special issues.
- Unifying close-proximity technologies: There is a growing number of technologies that support close-proximity and device-to-device radio communications, wi-fi (802.11), Bluetooth, Zigbee, near-field technologies, wi-bree, or infrared technolgies, to name a few. If we abstract the common actions that applications using these technologies need to perform, we could define a common set of functionalities, for example: device discovery, sending a short message, or sending a file. With these and similar primitives, a programmer could write an application that can very easily be adapted to run on different network interface technologies.
- Reusable codebase (sample modules: peer-to-peer networking, social awareness, logging, ...)
- Extensible Architecture - Modular building blocks
- Modular Runtime - Not all modules have to be loaded in runtime, this way strong devices could run high-processing load activities, while weaker mobile devices could run a minimal set of features.
Comm.unity Locations
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.
Comm.unity is a software framework in development, which is intended to allow developers and researchers to easily create applications that are proximity aware and socially aware, and can run on a large set of existing consumer devices. It implements a wireless, device-to-device information system that bypasses the need for any centralized servers, coordination, or administration. It is designed to span an extensible set of radio interfaces (WiFi, Bluetooth, IR, etc.).
Comm.unity is targeted for field deployment as well as for supporting advanced mobile-phone-based research. The feature-set for field deployment consists of a basic set of functionalities that are simple and explicitly defined. The research aspects include additional features that are more experimental, or support collection of research data - for example modules for performing logging a user's behavior and other sensor data, performing data-mining, machine learning and other types of on-device learning of a user's context and social activity.
- Communications unity: The current state of the close proximity networking space is very fragmented - Many different standards and technologies, and even devices with similar radios (e.g. Bluetooth or wi-fi) are not always able to communicate directly to each other due to limitations imposed by vendor, service provider, or simply lack of appropriate software. Comm.unity aims to resolve that by creating software and protocols that could run on a large set of different mobile and stationary devices, and allow them to directly talk to one another as long as they have similar physical radio interfaces. This means, for example, that iPhones would be able to discover and communicate with Nokia Symbian phones or Android phones via Bluetooth, no matter what mobile operator they belong to, and a WinMobile phone could connect to any Windows, Mac, or Linux computer via wi-fi without any special issues.
- Unifying close-proximity technologies: There is a growing number of technologies that support close-proximity and device-to-device radio communications, wi-fi (802.11), Bluetooth, Zigbee, near-field technologies, wi-bree, or infrared technolgies, to name a few. If we abstract the common actions that applications using these technologies need to perform, we could define a common set of functionalities, for example: device discovery, sending a short message, or sending a file. With these and similar primitives, a programmer could write an application that can very easily be adapted to run on different network interface technologies.
- Reusable codebase (sample modules: peer-to-peer networking, social awareness, logging, ...)
- Extensible Architecture - Modular building blocks
- Modular Runtime - Not all modules have to be loaded in runtime, this way strong devices could run high-processing load activities, while weaker mobile devices could run a minimal set of features.
Post new comment