Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted)

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 5 Jul 2006 14:48:45 -0700

Hi Peter,

One data point below...

On 6/30/06, [email-masked] <[email-masked]> wrote:
>
>
> Hi Rohan,
>
>
> > LLDP-MED does not work in an 802.11 wireless LAN environment.  The
> assumptions
> > made in LLDP-MED about link reliability, authentication, bandwidth
> availability, timing,
> > and lack of mobility are grossly inappropriate in a WLAN environment.
>
> Actually, LLDP-MED can be used in WLAN scenarios for location, with the
> constraint that it can only locate to the AP today.  See LLDP-MED spec,
> Annex C for discussion of this.  At this point in time, there is no solution
> in WLAN to resolve closer than the AP.
>

I am aware of several shipping implementations that do much better than
this.  All of these can do at least 10m accuracy and one is doing 3m
accuracy in well engineered deployments.

 To your points... If the wireless link becomes unreliable, then all methods
> are off.  Auth is not really a strong requirement (IMHO) in this scenario,
> at least in enterprise.  And, bw availability & timing are non-issues due to
> the very small size and periodic advertisements inherent in LLDP -- the
> other proposed methods use more bw and/or have difficulty getting updates on
> the fly.  (Don't understand what you mean by "lack of mobility".)  Yes, an
> imperfect solution, however reasonably practical at this time.
>
> > I am personally much more interested in location (emergency and
> otherwise) for wireless
> > LAN devices than for wired devices.  The user of a wireless LAN device
> is much less
> > likely to know their own location than a user of a wired LAN devices.
>  This is a fast
> > growing market segment because people want mobility once the price is
> right and the
> > quality is good enough.  Yes, we need to solve wired location, but lets
> not forget the
> > wireless communities.
>
> I both agree and disagree here.  Wired ethernet is by far the dominant
> case today in enterprise scenarios, therefore this is the biggest interest
> for me at this point in time.  LLDP-MED is already being supported by
> several vendors in enterprise space, and is proving to be pretty easy to
> work with, so makes a good choice there IMHO.   Of course I do very much
> agree we need to fully solve WLAN also, both enterprise and public, however
> it is lagging in large part due to lack of a well agreed / standardized
> method of doing the actual location (triangulation or otherwise).  The work
> is ongoing, but will take time.
>
> Thanks for aiming at the IEEE work.  I was aware, but have not been able
> to keep up with it in detail.  If I understand correctly (may be dubious) it
> appears that yet a 4th location method might be required to support this.
>  (I can hear Brian groaning as I type ;-)
>

your welcome.  thanks for the pointer to LLDP-MED. I seems I keep having to
refind it from time to time.

thanks,
-rohan
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: [email-masked]
Date: Thu, 6 Jul 2006 08:39:52 -0400

Hi Rohan, all, 

>>> assumptions made in LLDP-MED about link reliability, authentication, 
>>> bandwidth availability, timing, and lack of mobility are grossly 
>>> inappropriate in a WLAN environment. 
>>
>> Actually, LLDP-MED can be used in WLAN scenarios for location, with 
>> the constraint that it can only locate to the AP today.  See 
>> LLDP-MED spec, Annex C for discussion of this.  At this point in 
>> time, there is no solution in WLAN to resolve closer than the AP. 
>
> I am aware of several shipping implementations that do much better 
> than this.  All of these can do at least 10m accuracy and one is 
> doing 3m accuracy in well engineered deployments.

Yup.  Oops, should have thrown the word "standardized" in there.  For 
ECS purposes, I believe it absolutely needs to be a fully open 
standards-based solution.  WLANs i think will always be somewhat 
problematic, just due to the laws of physics and large number of 
variables which can affect accuracy.  10m is not there yet for an 
enterprise setting, especially vertically (oops, wrong floor!), 3m only 
barely.  And "well engineered" tends to mean "hard to get right" in 
practice. 

Anyhow, this is now well off track relative to original intent of this 
thread.  I'll stop typing now, unless someone cares to throw in 
something related to what location methods should be included in the 
Phone BCP. 

See y'all in Montreal, 

-- Peter

[snip]