About link-layer handoff

wayne liu waynix at gmail.com
Tue Jul 26 21:39:42 EDT 2005


Hello All;

Here is my two pennies.
Aside from the implementation/platform specific factors (OS, driver,
Card),  which you can
strive to minimize, there is an architectural limitation to how fast
you can hand off.

First, you need to always have a fresh list of candidate APs to move
over to, whose dicovery takes radio resource from on-going traffic,
assuming you do not have redundant
radio interface.  My experience is that finding the new AP is the
biggest contributor to
the gap, if the new AP is not available at the time the old one is
lost, which would be the case if their coverage overlap is not
sufficient.
Additionally, the process to obtain PMK (for 802.1X) and 4-way
handshake, if WPA enabled, takes variable amount of time, depending on
how fast Radius server responds.

I do not have specific numbers, but I would be surprised to see a
"full featured" WPA
WLAN with sub-sec handoff. They must have proprietary solutions, such
as all APs and the STA cooperating with each other and with WLAN
switch to deliver a dynamic "radio map"
to the STA. Also some kind of pre-auth may be involved, and so on. 

The 802.11r TG is just getting into the draft stage of a fast handoff
Spec. which addresses
the latency associated with security. 

For practical appl such as VoIP (oWLAN), 100 msec gap would be
annoyingly noticeable.
So IMO, bare-WPA/802.11i WLAN is not good enough for VoWLAN.


On 7/20/05, 张 yf <zyf73518 at hotmail.com> wrote:
> I have made a test-bed, two AP made with hostap driver, a terminal with XP,
> NTP for synchronization, airopeek NX for sniffing. simulate the handoff
> process by shut down an AP,
> Open system used. the detect result shows a complete handoff process takes
> about 3.5 seconds. probe process take about 3.4 seconds, and auth and
> associate take just less than 10 ms.
> 
> I have test for about 6 times, and the result is very similar. also I take
> a notebook walking around our lab. The APs and pc card used come from
> Cisco, and I notice there happened a handover as I walk from AP 1 to AP 2.
> I didnot sniff the result, but I find a ping packet is lost (it's just a
> link-layer handover, no network-layer handover takes place, and the two
> real AP connect to the same switch), so the latency is about 2~3 seconds.
> 
> But from all the papers I have read, all authors claim the latency is about
> 200ms ~ 500ms, There is a big gap. WHY??
> 
> to be mentioned, I have found from a Sweden university's website, a guy
> also got the same result with me.
> 
> >From: JIE XIONG <g00220008 at gmail.com>
> >Reply-To: JIE XIONG <g00220008 at gmail.com>
> >To: 张 yf <zyf73518 at hotmail.com>
> >CC: hostap at shmoo.com
> >Subject: Re: About link-layer handoff
> >Date: Wed, 20 Jul 2005 18:50:59 +0800
> >
> >i also want to ask about it...
> >
> >Anyone can give a definition about what layer 2 handover is (no IP
> >address change?)
> >
> >And how long it will take for a normal layer handover
> >
> >How can we decrease the layer 2 handover (it depends on OS, kernel,
> >driver, wireless card??)
> >
> >please help, thanks!
> >
> >On 7/20/05, 张 yf <zyf73518 at hotmail.com> wrote:
> > > Can anyone give me some answer about what is the least time link-layer
> > > handoff needs to finish with hostap driver, even the driver is modified
> or
> > > crosslayer information is used?
> > >
> > > Thanks
> > >
> > > Mark Hsueh
> > >
> > > _________________________________________________________________
> > > 免费下载 MSN Explorer:   http://explorer.msn.com/lccn
> > >
> > >
> > >
> > > _______________________________________________
> > > HostAP mailing list
> > > HostAP at shmoo.com
> > > http://lists.shmoo.com/mailman/listinfo/hostap
> > >
> > >
> > >
> >
> >
> >--
> >regards,
> >Xiong Jie
> 
> _________________________________________________________________
> 与联机的朋友进行交流,请使用 MSN Messenger:  http://messenger.msn.com/cn
> 
> 
> 
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
> 
> 
>


More information about the HostAP mailing list