[Olsr-dev] Client Roaming Plugin

[marc fawzi]

Hi Markus,

It would seem right to think that ad-hoc mode is going to be supported as a
standard feature by the newer wi-fi chips, especially if a hot
market/applications is developed that depends on having it, like
voip-over-mesh.

Regarding the scenarios you've outlined, A thru D, I prefer A because B
sounds more complicated/more work to me on a gut-feeling level, as I don't
fully understand what is involved in either scenario. What I mean is that A
sounds like less work and less complicated as far as the changes you would
have to make in OLSR, and that's always the right thing to do, imo, because
it represents the minimum viable response to the feature being requested,
and I'm a fan of "minimum work" :-) Now if B is better or more robust with
respect to future vision then you may want to consider that in the roadmap,
and for now go with the simplest way to provide switching without loss of
connection for clients not having olsrd.

My own interest in the tech is to provide VoIP-over-mesh in densely
populated areas, starting with downtown/business district in Seattle.

I have VoIP-carrier-side business knowledge and SIP provider expertise so I
know that carrying and terminating traffic from mesh to regular phones or IP
phones outside the mesh can cost as low as $0.003 per minute or less (for
carriers with large local termination coverage and/or peering arrangements),
which can lead to "basically free" or "cheap" decent quality voice service
for mobile phones.

So, to me, it's about how fast I can deploy a "demo" mesh so I can start
working on the business side.  I am connected to many investors in this
space who will be very happy to see a demo voip-over-mesh work in 2-3 city
blocks and I know I can make that happen because I'm as excited about it as
everyone who wants to pay less for their phone bill (in 5-10 years from
now)


So "A" is best scenario for me if and only if it can work as well or better
than B and is less work/less complicated than B.

And like I said, if B is a solution that is more relevant to the olsr team's
vision and goals then you can always put it on the roadmap, and for now give
us A :) because it's the least amount of work/least complicated.

:)

Marc


On Fri, Jan 22, 2010 at 2:42 AM, Markus Kittenberger <
(spam-protected)> wrote:

>
> On Fri, Jan 22, 2010 at 1:39 AM, marc fawzi <(spam-protected)> wrote:
>
>> >>p.s. we can switch to german i think (-;
>>
>> :-(
>>
>> I think the idea of using olsrd to provide a way for mobile devices with
>> conventional wifi capability to switch between olsrd-enabled wifi
>> accesspoints without losing VoIP connection is a very important telephony
>> application of OLSR that seems to be very practical from a business
>> perspective in the near term.
>>
>
> practical for sure, but supporting voip (maybe even flickerfree) is not
> trivial
>
>
>> I'm keeping my fingers crossed and hoping that it can be done.
>>
> do you think that requiring/recommending adhoc-mode is a big hurdle aswell?
>
> it has 3 benefits,
>
> - we can reuse the wifis forming the mesh aswell to provide connectivity
> for clients, ap-mode requires dedicated wifis, or VAPs (but imho VAPs will
> not fulfill the requirements of raphaels approach)
>
> - and we do not have to switch hard (and fast) from one master to the
> other, as the client does not switch cell, it only switches it`s nexthop,
> this is also initiated from the new master, which at this time is already
> ready to provide the required connectivity
>
> - above also implies that the switch can go within zero time on the client
> (it just changes the mac-adress of its gateway)
> (at least if the new master is on same frequency, if the client need to
> switch frequency aswell, we have same situation as with raphaels approach)
>
> It's far easier from a business perspective than requiring mobile phones to
>> be in ad-hoc mode and running olsrd.
>>
> so there`s are 2 other options (in my mind) inbetween those two (A, D) you
> mentioned
>
> to summarize:
>
> A ap-mode, no software on client (using dhcp, and client decides when he
> switches network) (the client switches (based on its wifi-drivers decision
> to do so), and the mesh needs to react asap on this)
>
> B ad-hoc-mode, no software on client (we use initially dhcp and arp packets
> to switch the client to another master) (the olsr mesh initiates the switch
> of the gateway for the client, and the client could (theoretically) receive
> incoming traffic from multiple masters)
>
> C adhoc-mode a lightweight client, that can be installed as normal
> application (requires no root priviledges) (we still use arp to switch the
> client, but we can do better linksensing, and maybe even display topology,
> or other info on the client, and give the user methods of interacting, like
> choosing which internet gateway of the mesh he likes to use, and so on)
>
> D adhoc mode, full featured olsrd on client (the client gets a full router
> infact, (potentially using up his battery for routing other peoples
> traffic))
>
> ----
>
> imho C is much work (on potentially multiple plattforms) and i´m not sure
> how much benefits it has over D in real life
>
> D already exists for some phones
>
> but imho B is the most interesting one (as it will run on "any" existing
> wifi on a olsrd-mesh)
>
> (furthermore it shares quite much with A, so an A/B approach is reasonable
> from my point of view)
>
>
>> Sorry to interject my non-technical opinion,
>>
> no need to be sorry, as we have to keep users in mind aswell with this
> feature,..
>
>
>> but I would hope you guys continue in English ;-)
>>
>
> at least for a while,..
>
> Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100122/84703e3d/attachment.html>