[Battlemesh] Wifi-Opp [was: Still no ad-hoc in Android 4.0 "Ice Cream Sandwich"?]

F L legendre at tik.ee.ethz.ch
Thu Oct 20 08:21:40 UTC 2011


Comments inline:

On Oct 20, 2011, at 12:02 AM, Juliusz Chroboczek wrote:

>> We have proposed an alternative to WiFi Ad Hoc called WiFi-Opp, which
>> is more flexible and doesn't require pairing (as in WiFi Direct which
>> we tested on Galaxy SII).
>
> Very interesting work, although I'm not sure it's an alternative to
> ad-hoc.
Well, our goal is to allow "ad hoc" communications w/o WiFi ad hoc  
using stock phones (non routed/jailbreaked) and leveraging what is  
currently feasible with the Android API, especially the one related to  
WiFi.
We don't target geeks that root their phones but the masses.
>
> The tl;dr version: they're running in infrastructure mode, and  
> randomly
> switching between AP and STA.  There's a number of heuristics  
> involved,
> but they appear to have refined their algorithms to the point where  
> they
> claim to run a naive flooding protocol at 70% of the performance of
> ad-hoc mode, with 20% of the power usage.
Well we do the same with 10% of the power usage and at 90% of the  
flooding performances of what WiFi ad hoc would provide you. We use  
the same naive flooding approach.
The main difference is that we consider a completely mobile network  
(no mesh), i.e., people are switching randomly to AP mode and others  
are connecting to these random AP on the go.
>
> Unless I'm missing something, WiFi-Opp doesn't allow quickly scanning
> for all the peers in range (which can be done with just a few  
> multicast
> packets in ad-hoc), or communicating with multiple peers in quick suc-
> cession (which makes it unsuitable for something like a DHT algorithm,
> let alone a mesh network).  That's why I'm not so sure about the claim
> to being an "alternative" to Ad-Hoc.
True, we can't scan for all peers around as we're using the 802.11b/g  
infrastructure features but you might have one of the devices around  
you in AP mode through which you can discover all the peers connected  
to it.
Since we propose to have nodes randomly switch to AP mode,  after some  
time you'll see all the peers around you. Actually, we rather think in  
terms of content which can be on any peer, not specific peers. That's  
probably one big difference between mesh and opportunistic networking.  
In the former, you might care about peers, we care about content in  
the latter.
A DHT on a completely mobile network is not realistic. There are nice  
research papers on DHT for mesh if you want me to provide pointers.  
For a quick look at content on peers around you, please have a look  
at: http://podnet.ee.ethz.ch/ and related papers. A prototype is  
available for windows mobile, symbian and Android.
>
> I was also under the impression that the iPhone supports ad-hoc mode  
> out
> of the box, but the paper claims otherwise.
iPhones can connect to any already existing wifi ad hoc network...but  
cannot create one if none exists in the first place.
>
> Franck, could you please clarify two things?  First, you claim
> a five-fold decrease in power usage w.r.t. ad-hoc, but was that  
> measured
> with WiFi or with Bluetooth?  And second, when you speak of  
> "percentage
> of the dissemination performance", what is it exactly you're  
> measuring?
I clarified this above. Again we use only 10% of what ad hoc would be  
using (no Bluetooth). This is simply coming from the sleeping  
strategies used for WiFi on Android. You could even make this better  
using more advanced sleeping strategies. Ad Hoc is power hungry and  
remember how buggy 802.11b was at the beginning (e.g.,  
incompatibilities, etc). WiFi Ad Hoc has exactly the same flaws and  
will need 1-2 years to get to the same level of maturity.
>
> Thanks for the interesting read,
thanks for your interest and comments. Let me know if something still  
needs to be clarified.
--
Franck
>
> -- Juliusz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20111020/b81fc4a9/attachment.htm>


More information about the Battlemesh mailing list