We are used to communicate with anyone, everywhere and at any time: We’re addicted to communication. We imagined: what looks the situation like, if we are not able to communicate? We considered extreme situations like earthquakes or tsunamis. After such natural disasters become huge parts of the telecommunication destroyed or is excessively used and not available for everyone. But exactly those situations arouse the need for communication in an extreme way. We have developed a Prototype Lauffeuer, that enables people to communicate without mobile service or internet connection - decentralized communication with mobile devices.
How it works
Every device stores all messages, that the user wants to send. Two devices connect via Bluetooth or AdHoc-WiFi, as soon as they are close to each other (1 - 50m). Both devices exchange and store all messages of each other. That means: All messages are transmitted and stored - regardless of the recipient of a message. The devices move on and the connection gets canceled. Both devices will find new “sync-partners” because they are carried around by their owners. This method is called Epidemic Routing, because messages are spread through the network like a virus. This kind of routing ensures with a high probability, that the messages will be delivered (regardless of time and storage consumption). We’ve through about some mechanisms to reduce the number of total messages in the network due the limited storage capacity of devices:
- Delivery-Confirmation (an extremely small broadcast-message itself)
Delivery-Confirmation Every device will generate an automatic delivery-confirmation as soon as it receives a message. The confirmation can not be faked by other devices (see below). This confirmation is relatively small and short-lived, compared to “normal” messages (The TTL of the confirmation is set to the remaining TTL of the received message). Confirmation are transmitted like normal messages. Each device checks during a synchronization, if there is any message, that got already confirmed. Confirmed messages are deleted immediately, except for the confirmation itself, which will be broadcasted until the end of the TTL.
Prioritization We have to assume, that the connection between two devices lasts for a very limited time. The technical term is temporal and spontaneous networks. In consequence, we may not have enough time to exchange all the messages with our sync partner. This is why we prioritize the messages by age, number of transmissions, traveled distance, …
Mobile Devices We have developed an app for Windows Phone 7, but ported the source code from Silverlight to the “normal” .NET platform, so we could develop a daemon software for laptops: A proof-of-concept, that we can deliver messages via a network of heterogeneous hardware.
Communication - outside-in & inside-out We established communication inside the crisis area: A kind of human chain delivers messages from the sender to the receiver, whereas chain links don’t have to exist at the same time. But what about receivers, who are located outside the crisis area, or in another country or continent? We have developed a server for our system. We assume, that some users will get rescued and leave the crisis area, or will regains access to the internet, because the infrastructure is rebuilt in local limited spaces. As soon as a device has internet access, it will push all stored messages are pushed to the server, which will transmit the messages by email or any social platform. This is why we include email addresses in our messages.
We have decided to put all P2P-stuff in a framework (which we called Mercury). The application Lauffeuer provides the user interface to use the functionality of Mercury.
My focus was on the processing of packages (messages & confirmations generalized): It should be as modular and flexible as possible (see below).
Messages from user A to user B will be transmitted over user C. Obviously user C should not be able to read or modify this message. So we used the RSA-Library of the .NET framework. Messages are encrypted and signed. We use our dedicated message proxy as key server (mentioned above).
Messages are not direct visibly addressed to a user: We put a MagicWord (see Magic Number at the beginning of the message, which is encrypted with the public key of the receiver. The receiver can decrypt this initial sequence to the MagicWord and knows, that he is the recipient. Other users can determine, that two messages have the same recipient. But every user can “create a new identity” by creating a new key pair.
The delivery confirmations (mentioned above) are fraud resistant. Assume a user could fake receive confirmations: He could spread confirmations for every internal stored message. Other network participants will drop messages and the messages of the attacker will be delivered with high priority. We generate a RSA-key pair for every composed message (let’s call it package-key). We put the private package key into the part of the message that gets encrypted and the public package key in the meta-info of the message, so it is readable for everyone. A receive confirmation is a tuple of the hash of a message and the signature over that hash with the private package key. Every user that has the original message can check whether the confirmation is fake or valid, but only the sender and receiver of a message are able to generate a valid confirmation. Unfortunately we have a big overhead: put a 1024bit RSA key pair into each message, which takes place of 128 ASCII-Chars, which may be bigger than the message we want to transmit.
Structure of packets
We distinguish among packets that have a single recipient (a.k.a. private) and public messages.
The P2P framework had to be as flexible as possible, so we introduced different ContentTypes. A ContentType defines how to serialize and deserialize data. Applications can define their own ContentTypes (e.g. mp3 or png images). Mercury provides transparency for transmitted data. Some special ContentTypes are:
- PacketContentContainer - combines other contents in a container, is a content itself.
- SignContainer - to signing another content
- CryptContainer - to encrypt another content
Packets do always consist of a RoutingContent and exactly one content, which can be a PacketContentContainer, which holds other content instances. Every Content marks itself with a 4 bit mask at the beginning of it’s serialized format. All available content types are registered in the PacketContentDictionary, which receives serialized contents to deserialized. Depending on the first four bits, it calls the Deserialize method in the matching content class.
There are different actions that you want to apply on messages: Compose Create package key pair, create routing and meta information and encrypt the private segment of the message Synchronize Retrieve packages from local storage in the correct order, descending by their priority. Update routing information of each transmitted package. Store received packages. Check during synchronization and for every package, if it is addressed to this device. If that is the case: Create & send receive confirmation an decrypt the package.
We have found four pipelines in his task:
- Prioritize (all packages are re-prioritized)
- Secure (parts of packages are encrypted, if needed, create a package key pair)
- Pack (serialize packets)
We have developed these pipelines in Mercury in the way we need them for Lauffeuer. Pipelines consist of one of multiple Layer. Each Layer represents exactly one task, that is applied to a package (e.g. “increase/decrease priority of package according to age”).
Layer do have at least one follower, so they can be stacked to a pipeline:
A layer can have multiple followers, which enables us to have some pipeline elements parallelized:
Some Layers (that do very simple tasks) are implemented synchronus, others (e.g. DecryptLayer) inherits from the Thread class, which makes it’s call asynchronous.
We came across many restrictions during the implementation. The biggest disadvantage was the decision for the “Windows Phone 7” OS. C#.NET is really cool with its LINQ and other nice features, but….
AdHoc and Wp7
You can not create a AdHoc-Wifi or Bluetooth connection between two Windows Phone 7 devices, which makes our idea on that hardware kind of useless. You have to make a detour over laptops: Compose message on a phone, sync with a laptop, sync laptop with another phone. We stayed with Windows Phone 7 and developed a kind of Bluetooth simulation, which provides the typical Bluetooth API to Mercury, but uses WiFi (the normal one, not AdHoc) underneath.
You can not run a background process in Windows Phone 7. There are so called Background Workers, but they are very limited in connectivity. Devices can not look for others automatically, to exchange messages.
The capacity of the battery is a limiting factor of our app. State of the art devices do have a high energy consumption.
“Hopefully nobody has to use the app”
Users do have to install the app before the crisis. Who will do this? It is very unlikely in my option. An integration into some smartphone OS or side spread messengers (like Skype or whatsapp) would be the best, but are unrealistic, too.
Work of Others
We read some papers during our design phase. Here are some of them:
- Epidemic Routing for Partially-Connected Ad Hoc Networks - Amin Vahdat and David Becker
- Controlled Epidemic-style Dissemination Middleware for Mobile Ad Hoc Networks - Mirco Musolesi and Cecilia Mascolo
- Probabilistic Routing Protocol for Intermittently Connected Networks - A. Lindgren
- Routing in Hybrid Delay Tolerant Networks - Christoph P. Mayer and Oliver P. Waldhorst
- Performance Evaluation of Structured P2P over Wireless Multi-hop Networks - Marcel C. Castro et al.
- Age Matters: EfÎáÎñÎõcient Route Discovery in Mobile Ad Hoc Networks Using Encounter Ages - Henri Dubois-Ferriere et al.
We are (from right to the left): Philipp Serrer, Chau Nguyen, Vitali Kaiser and me (Tobias Sturm). The project was started during the hands on course “Practice of Software Development” at the KIT. We had to develop our idea with the waterfall model. The idea was developed by us. We want to thank Korbinian Molitorisz! We would not have been so successful on the ImagineCup without his advises. Thanks!
We participated in the Microsoft ImagineCup (Competition for students, organized by Microsoft). We took part in the national finals 2012 in Berlin and we got the second prize in the category “Windows Phone”. Nokia (one of the sponsors) invited us to speak at the MLOVE.
The MLOVE describes itself as follows:
The MLOVE ConFestival brings together CEOs, innovators and entrepreneurs from across multiple disciplines to share, learn and cross-pollinate ideas with an array of scientists, artists and other thought leaders. The event exposes the mobile industry to the best minds outside of mobile to maximize the opportunity of creating life-changing services and applications that can impact us all for the better.
Zukunftspreis Kommunikation 2012
Here are some downlads of documents we create curing the course and for the competitions: