Subject: Re: [paws] [STDS-802-11-TGAF] About LCI format in .11af spec

From: Gerald Chouinard <[email-masked]>
Date: Tue, 25 Oct 2011 15:09:10 -0400

Gabor,

Wouldn't it be easier for the master WSD to simply forward the NMEA string 
that it would have obtained from the GPS device rather than having to 
re-format it?  NMEA 0183 is more friendly with any geolocation technology 
than DHCP.

Gerald

At 18:55 25-10-11 +0000, [email-masked] wrote:
>I know it is rather confusing that this binary encoding of location was 
>defined as part of a dhcp option. It was done the same way in RFC3825 as 
>well. But 802.11 never intended to use the dhcp option code itself, only 
>the location encoding format. The same assumption applies to RFC6225 as 
>well, ie use only the binary encoding part of the location. This binary 
>encoding can be transmitted using any protocol, being that 802.11 frame, a 
>dhcp option field, or sg else.
>
>The document does use uncertainty, that is actually the major improvement 
>over the previous format (defined in rfc3825). Confidence even though it 
>is mentioned, it is not elaborated. I think it is assumed to be 95%, which 
>is an industry wide accepted value.
>
>-Gabor
>
>
>-----Original Message-----
>From: ext Gerald Chouinard [mailto:[email-masked]]
>Sent: Tuesday, October 25, 2011 9:54 AM
>To: Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]
>Subject: Re: [STDS-802-11-TGAF] About LCI format in .11af spec
>
>Gabor, all,
>
>It should be pointed out that the IEEE 802.22 Standard contains primitives 
>for the database interface, as presented during the Quebec City meeting, 
>that propose to use the NMEA 0183 strings to document the geolocation of 
>the WSDs. Such strings are more in line with the various existing 
>geo-positioning technologies such as GPS (e.g., most GPS professional and 
>consumer devices output their data using NMEA strings.
>
>Using a DHCP-based protocol to provide the WSD geolocation seems to result 
>in a catch-22, that is a DHCP message can only be transmitted to a device 
>that is associated to a network while the geolocation of a WSD needs to be 
>provided to the database before the device can be considered associated to 
>the network so that the database can confirm which channels can be used by 
>this device before it starts to operate. This apparent conundrum needs to 
>be resolved somehow.
>
>Finally, the enhanced DHCP protocol described in RFC6225 does not contain 
>parameters such as the 'uncertainty' and the 'confidence level'.  Although 
>the NMEA strings include some information that can be used to deduce this 
>information (e.g., number of satellites in view), the master WSD would 
>need to translate it into the required parameters which, in passing, may 
>be different from one regulatory domain to another.
>
>My 2-cents ...
>
>Gerald
>
>
>At 14:59 25-10-11 +0000, Gabor Bajko wrote:
>
> >Yes, I brought up this LCI topic for discussion both in TGv and TGmb, a
> >while ago. The conclusion was that even though LCI based on RFC3825 has
> >known deficiencies, if used within 802.11, we can live with it. And
> >since there was significant resistance to make the change, there was no
> >motion brought to the floor.
> >
> >
> >
> >What is different now is that the location of the STA encoded in the
> >802.11 L2, in some of the 11af use cases, will need to be converted by
> >an AP to XML before sent to the DB.  And there is no mathematical
> >formula I know of, which can be used to convert an RFC3825 LCI or the
> >11af defined extended location encoding into XML. The newly published
> >RFC6225 is backward compatible with LCI as used in 802.11y, field wise,
> >but the fields have different meaning and the encoding is different.
> >And there is an easy formula on how to convert it to XML.
> >
> >
> >
> >Therefore, I felt it is time LCI as defined in RFC3825 is not
> >propagated to new 802.11 amendments but rather the format defined in 
> RFC6225 is used.
> >
> >
> >
> >-Gabor
> >
> >
> >
> >From: *** 802.11 TGaf - TV White Spaces OperationTask Group ***
> >[mailto:[email-masked]] On Behalf Of ext Hamilton, Mark
> >Sent: Monday, October 24, 2011 1:52 PM
> >To: [email-masked]
> >Subject: Re: [STDS-802-11-TGAF] About LCI format in .11af spec
> >
> >
> >
> >Is the proposal being made here suggesting the TGaf needs a different
> >LCI format, or that the base text s current LCI format be modified per
> >the updated RFC?
> >
> >
> >
> >For those who didn t know, this has been discussed in TGmb (and TGv, I
> >believe) for a while.  Both groups decided to wait until the IETF had
> >settled on a way forward, and then to evaluate what we thought.  Along
> >the way, comments have been made that the new format will be (is?)
> >backward compatible with the RFC 3825 format.  I gather from Paul s
> >description that this can be the case, as RFC 6225 has specified
> >multiple formats to superset RFC 3825.  If the intent is to replace the
> >baseline 802.11 LCI format with a new format, those discussions should 
> be given consideration.
> >
> >
> >
> >Mark
> >
> >
> >
> >From: *** 802.11 TGaf - TV White Spaces OperationTask Group ***
> >[mailto:[email-masked]] On Behalf Of Paul Lambert
> >Sent: Monday, October 24, 2011 1:52 PM
> >To: [email-masked]
> >Subject: Re: [STDS-802-11-TGAF] About LCI format in .11af spec
> >
> >
> >
> >Three formats are defined in RFC 6225, one of which is identical to the
> >current format we ve used from RFC 3825.
> >
> >
> >
> >Uncertainty versus resolution look like just an improvement in naming.
> >The Res field also has been carved up to include Version.
> >
> >
> >
> >Which specific RFC 6225 format are you proposing (I d assume Code 144 yes) ?
> >
> >
> >
> >Paul
> >
> >
> >
> > > correct binary LCI format so that it can be converted to XML format
> > expected to be
> >
> > >used for device to GDB interface, e.g. by IETF PAWS protocol.
> >
> >
> >
> >
> >
> >Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141
> >
> >
> >
> >From: *** 802.11 TGaf - TV White Spaces OperationTask Group ***
> >[mailto:[email-masked]] On Behalf Of Padam Kafle
> >Sent: Monday, October 24, 2011 10:49 AM
> >To: [email-masked]
> >Subject: [STDS-802-11-TGAF] About LCI format in .11af spec
> >
> >
> >
> >Hi All,
> >
> >
> >
> >I would like to bring to the attention of this group about the use of
> >location information in .11af. In my opinion, the format for device
> >location information in .11af specification needs to be fixed. We have
> >been referring to RFC 3825 for LCI format, which has already been
> >obsoleted by a new RFC 6225. One problem with this is the LCI format
> >used currently in .11af is not current, and not likely to be adopted
> >industry wise. The encoding has been revised by the new RFC 6225 (see
> ><http://tools.ietf.org/html/rfc6225>http://tools.ietf.org/html/rfc6225 ).
> >
> >
> >
> >I think TGaf should revise the current device location information and
> >device position information IEs to align with the RFC 6225 instead of
> >referring to RFC 3825. The main difference is use of uncertainty
> >instead of resolution for latitude, longitude and altitude, the length
> >of the fields are otherwise same. One important reason is that we need
> >to use correct binary LCI format so that it can be converted to XML
> >format expected to be used for device to GDB interface, e.g. by IETF 
> PAWS protocol.
> >
> >
> >
> >Please have a look to the RFC from the referred link. If there is time,
> >we can discuss this issue briefly in the TGaf telco tomorrow. I will be
> >uploading the proposed text (11-11-1402r0) before the call.
> >
> >
> >
> >Regards,
> >
> >
> >
> >Padam Kafle
> >
> >Nokia
> >
> >
> >
> >From: *** 802.11 TGaf - TV White Spaces OperationTask Group ***
> >[mailto:[email-masked]] On Behalf Of ext Richard Kennedy
> >Sent: Monday, October 17, 2011 9:31 PM
> >To:
> ><mailto:[email-masked]>[email-masked]
> >EE.ORG
> >Subject: [STDS-802-11-TGAF] FW: Tuesday's Teleconference
> >
> >
> >
> >
> >
> >
> >
> >Rich Kennedy
> >
> >Standards Manager
> >
> >Research In Motion Corporation
> >
> >mobile: +1 (972) 207-3554
> >
> >office: +1 (972) 910-3448
> >
> ><mailto:[email-masked]>[email-masked]
> >
> >
> >
> >IEEE 802.11 TGaf Chair
> >
> >IEEE 802.11 to 802.18 Liaison
> >
> >IEEE 802.11 Regulatory Standing Committee Chair
> >
> >Wi-Fi Alliance Spectrum & Regulatory Task Group Chair
> >
> >
> >
> >From: Richard Kennedy
> >Sent: Tuesday, October 18, 2011 10:26 AM
> >To: [email-masked]'
> >Subject: Tuesday's Teleconference
> >
> >
> >
> >All:
> >
> >
> >
> >I have just uploaded a teleconference plan and agenda for the call at:
> ><https://mentor.ieee.org/802.11/dcn/11/11-11-1381-00-00af-october-18th-te 
> leconference-plan-and-agenda.ppt>https://mentor.ieee.org/802.11/dcn/11/11-11-1381-00-00af-october-18th-teleconference-plan-and-agenda.ppt.
> >
> >
> >
> >I am in Taipei for the Wi-Fi Alliance meeting, so Peter will act as
> >Chair for this session.  Time is running out for comment resolutions if
> >we intend to finish in November.  Please get the resolutions done and
> >provide inputs to the remaining teleconferences.
> >
> >
> >
> >Teleconference details:
> >
> >Topic: 11af
> >Date: Every Tuesday, from Tuesday, October 4, 2011 to Tuesday, November
> >22, 2011
> >Time: 6:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting
> >Number: 207 473 454 Meeting Password: 11af
> >
> >
> >-------------------------------------------------------
> >To join the online meeting (Now from mobile devices!)
> >-------------------------------------------------------
> >1. Go to
> ><https://ciscosales.webex.com/ciscosales/j.php?ED=175158422&UID=1630286>7 
> 92&PW=NZTgyYmE4OThl&RT=MiM0>https://ciscosales.webex.com/ciscosales/j.
> >php?ED=175158422&UID=1630286792&PW=NZTgyYmE4OThl&RT=MiM0
> >
> >2. Enter your name and email address.
> >3. Enter the meeting password: 11af
> >4. Click "Join Now".
> >
> >To view in other time zones or languages, please click the link:
> ><https://ciscosales.webex.com/ciscosales/j.php?ED=175158422&UID=1630286>7 
> 92&PW=NZTgyYmE4OThl&ORT=MiM0>https://ciscosales.webex.com/ciscosales/j
> >.php?ED=175158422&UID=1630286792&PW=NZTgyYmE4OThl&ORT=MiM0
> >
> >
> >----------------------------------------------------------------
> >ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
> >----------------------------------------------------------------
> >
> >The affected toll free numbers are: (866) 432-9903 for the San
> >Jose/Milpitas area and (866) 349-3520 for the RTP area.
> >
> >Please dial the local access number for your area from the list below:
> >- San Jose/Milpitas (408) area: 525-6800
> >- RTP (919) area: 392-3330
> >
> >-------------------------------------------------------
> >To join the teleconference only
> >-------------------------------------------------------
> >1. Dial into Cisco WebEx (view all Global Access Numbers at
> ><http://cisco.com/en/US/about/doing_business/conferencing/index.html>ht
> >tp://cisco.com/en/US/about/doing_business/conferencing/index.html
> >
> >2. Follow the prompts to enter the Meeting Number (listed above) or
> >Access Code followed by the # sign.
> >
> >San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
> >
> >US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
> >
> >India: +91.80.4350.1111 Germany: +49.619.6773.9002
> >
> >Japan: +81.3.5763.9394 China: +86.10.8515.5666
> >
> >-------------------------------------------------------
> >For assistance
> >-------------------------------------------------------
> >1. Go to
> ><https://ciscosales.webex.com/ciscosales/mc>https://ciscosales.webex.co
> >m/ciscosales/mc
> >
> >2. On the left navigation bar, click "Support".
> >
> >You can contact me at:
> ><mailto:[email-masked]>[email-masked]
> >1-408-527 0815
> >
> >To add this meeting to your calendar program (for example Microsoft
> >Outlook), click this link:
> ><https://ciscosales.webex.com/ciscosales/j.php?ED=175158422&UID=1630286>7 
> 92&ICS=MI&LD=1&RD=2&ST=1&SHA2=jDwVsaHy/ACC2OzP5RIU8ktKab3T8gKl5fA6i3r0
> >CRY=&RT=MiM0>https://ciscosales.webex.com/ciscosales/j.php?ED=175158422
> >&UID=1630286792&ICS=MI&LD=1&RD=2&ST=1&SHA2=jDwVsaHy/ACC2OzP5RIU8ktKab3T
> >8gKl5fA6i3r0CRY=&RT=MiM0
> >
> >
> >The playback of UCF (Universal Communications Format) rich media files
> >requires appropriate players. To view this type of rich media files in
> >the meeting, please check whether you have the players installed on
> >your computer by going to
> ><https://ciscosales.webex.com/ciscosales/systemdiagnosis.php>https://ci
> >scosales.webex.com/ciscosales/systemdiagnosis.php
> >
> >
> >Sign up for a free trial of WebEx
> ><http://www.webex.com/go/mcemfreetrial>http://www.webex.com/go/mcemfree
> >trial
> >
> >http://www.webex.com
> >
> >CCP:+14085256800x207473454#
> >
> >IMPORTANT NOTICE: This WebEx service includes a feature that allows
> >audio and any documents and other materials exchanged or viewed during
> >the session to be recorded. By joining this session, you automatically
> >consent to such recordings. If you do not consent to the recording,
> >discuss your concerns with the meeting host prior to the start of the
> >recording or do not join the session. Please note that any such
> >recordings may be subject to discovery in the event of litigation.
> >
> >
> >
> >
> >
> >Thank you.
> >
> >
> >
> >Rich Kennedy
> >
> >Standards Manager
> >
> >Research In Motion Corporation
> >
> >mobile: +1 (972) 207-3554
> >
> >office: +1 (972) 910-3448
> >
> ><mailto:[email-masked]>[email-masked]
> >
> >
> >
> >IEEE 802.11 TGaf Chair
> >
> >IEEE 802.11 to 802.18 Liaison
> >
> >IEEE 802.11 Regulatory Standing Committee Chair
> >
> >Wi-Fi Alliance Spectrum & Regulatory Task Group Chair
> >
> >