Fast Meshed Handoffs for Moving Clients (MIDs?).

[Transition Strategist (Greg)]

A team at John Hopkins University has developed a fast handoff
protocol for moving connectivity especially for VoIP use. They have
this live demonstration http://www.smesh.org/live.html . The below is
an excerpt from the pdf paper they've put out which I've uploaded to
our google groups files repository.

3. FAST HANDOFF PROTOCOL
Traditionally, hando is provided by using the default
DHCP settings. This makes the client broadcast a DHCP
request after T2 seconds (by default, 87% of the Lease time),
which allows a di erent access point to respond and become
the default gateway for the client. Even if T1 and T2 timers
are set to very small values (e.g. 2 seconds), hando can
still take a couple of seconds. Moreover, the client may con-
nect to an access point that has a weak connection, while
better nodes may be available. A hando of a few seconds
may seriously a ect some applications such as VoIP which
require packets to arrive within a limited time as low as
100ms before being considered lost.
Instead of letting the client \decide" when the hando
should take place by following the DHCP protocol, we make
the SMesh nodes track their connectivity to the clients and
force the client to change its access point when better con-
nectivity is available (avoiding oscillations is described be-
low). To achieve this without modifying anything on the
client side, we provide the illusion of a single global IP as
the default gateway of the client and use gratuitous ARP
messages to force hando to the SMesh node with the best
client connectivity.
When 802.11 devices are congured in \infrastructure mode"
they inherently do their own scanning for a better access
point. In order to avoid this behavior and control the hand-
o solely from the access points, we congure both the access
points and the mobile clients in \ad-hoc mode". This setting
is part of the normal setup of any 802.11 device.
The details of our hando protocol are described below.
These include the link quality metric used to determine the
best access point for each client, the use of multicast groups
for managing the clients, and the actual hando process.on

[Transition Strategist (Greg)]

I found the below which says smooth handoffs are currently working in
B.A.T.M.A.N. which open-mesh barely supports because Robin isn't doing
ad hoc yet. Antonio is rumoured to be making the move to support ad
hoc as well as ahdemo but these are only rumors.

Hi,

the wonderful people from graz.funkfeuer.at are simply the fastest in
terms of
realtime documentation of ongoing experiments.

see: https://wiki.graz.funkfeuer.at/BatmanTestbed
and particularly the smooth handover experiment when walking through
the
exhibition side (furnished with 20 mesh-routers) with an OLPC running
batman
(with a window size (NBRF) of 5 and an originator interval of 2
seconds).
The ping -R indicates the route changes, the life audio stream, does
not stop
until getting outside the building into kind of blind spot.

ciao,
axel

On May 22, 1:07 pm, "Transition Strategist (Greg)"

<redresonantea...@gmail.com> wrote:
> A team at John Hopkins University has developed a fast handoff
> protocol for moving connectivity especially for VoIP use. They have

> this live demonstrationhttp://www.smesh.org/live.html. The below is