MANES could support mobile ad hoc network based applications. When thinking about mobile ad hoc networks, the most important feature to keep in mind is that it does not rely on infrastructure networks. No 3G, no Internet. As long as there are a few devices in communication range, they could talk to each other. This feature enables convenient networking when infrastructure networks are not available---e.g., in rural areas, natural disasters, and emergency shutdowns such as the 2011's event in Egypt. Mobile ad hoc networks are also a better alternative when the infrastructure networks are not safe, e.g., when local governments are imposing strong censorship on Internet, which is becoming a more and more common practice nowadays.
Because of their scalability problem, mobile ad hoc networks are most appropriate for networking within local areas. This would enable novel local based services.
Please note that MANES is not true mobile ad hoc networks. It still bases on the infrastructure network. However, our ultimate goal is to replace MANES with true mobile ad hoc networks, which are private, secure, and censorship resistant (please checkout the WHISPER project). We have designed MANES in a way to minimize the cost for applications developers to migrate from MANES to WHISPER.
We have listed a few half-baked application ideas.
This idea wants to help people to find friends with common interest in the local area.
One approach is each device advertises its owner's interests. The application collects interests information from other devices and try to match up with its owner's interest. For example, if multiple people are interested in playing Frisbee, the app could suggest these people to take a study break and go out to play Frisbee.
Another simpler approach is someone explicitly sends a message asking for company. For example, you are studying in the library for EECS 281 and would like to find someone else to form a study group. You could broadcast this message through a mobile ad hoc network and if anyone of interest happens to pass by and receive this message, they could reply to you and study with you.
Technical challenges:
We could broadcast it to one-hop neighborhood, then only people with one-hop range (around 50m indoor) could hear the message. We could also write some protocol to let the message travel for multiple hops, and have larger range to find friends.
We could deliver the reply only to the initiator through some kind of routing protocol. We could also broadcast the reply, which may become bothering to other people who are not interested in this event, though.
Threaded-view comment systems on websites (e.g., news article comments systems, Reddit comments, Slashdot comments, etc.) are good tools for facilitating discussion between users. Imagine sharing similar text-based discussions with other attendees at live events. At a political debate, attendees could commiserate over the asinine proposals of one candidate or point out flaws in the "facts" shared by another.
Pretend you are sitting in the nosebleeds at a football game and the line judge appears to make a bad call--- it sure looked from here like Junior Hemingway got one foot down in-bounds and maintained possession as he fell out. Most of the Big House sounds like it agrees. You quickly filter the attendee commentary on your smartphone to reveal the comments coming in from fans on the sideline--- turns out it was a good call. No need to get too upset after all; save that anger for bad calls in the end-zone that cost us games at Iowa.
This app would involve the implementation of (up to) three primary components:
A simple, easy-to-implement method is naive flooding: each phone that hears a message rebroadcasts it.
A thread-view like on the Reddit mobile site (m.reddit.com) could be a good starting point, design-wise.
Finding relevant and interesting comment chains is a hard problem on devices with full-sized screens and even more so on smartphones. Possible options could include:
or more-sophisticated options that take additional advantage of the location information available in an ad-hoc network
This idea wants to enable everyone in a party (or other events) to upload their music to a public playlist. The set-up will be simple: just a central computer that plays music and multiple client smartphones that upload music to the central computer to play.
Technical challenges:
The simplest idea is just one-hop broadcast. A client upload the music to the central computer only if they are in transmission range, e.g., 50m. Or more sophisticated routing protocols can be applied.
There are multiple options. The client could upload the MP3 file, for example. The client could just tell the name of the song to the central computer, who will then try to find it locally or online. Or the central computer could give the clients a list of music that it has and the client gets to choose from this list.
We could order the music simply according to their arrival times. We could order the music according to how many people have chosen them. We could also show people the current play-list and let them vote, and order the music according to their votes.