[Olsr-dev] Client Roaming Plugin

[Markus Kittenberger]

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/dbaa14d9/attachment.html>