[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 draft-ietf-geopriv-held-measurements

GEOPRIV                                                       M. Thomson
Internet-Draft                                           J. Winterbottom
Intended status: Standards Track                                  Andrew
Expires: November 5, 2009                                    May 4, 2009


    Using Device-provided Location-Related Measurements in Location
                        Configuration Protocols
               draft-thomson-geopriv-held-measurements-04

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 5, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Thomson & Winterbottom  Expires November 5, 2009                [Page 1]


Internet-Draft            Location Measurements                 May 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.














































Thomson & Winterbottom  Expires November 5, 2009                [Page 2]


Internet-Draft            Location Measurements                 May 2009


Abstract

   A method is described by which a Device is able to provide location-
   related measurement data to a LIS within a request for location
   information.  Location-related measurement information are
   observations concerning properties related to the position of a
   Device, which could be data about network attachment or about the
   physical environment.  When a LIS generates location information for
   a Device, information from the Device can improve the accuracy of the
   location estimate.  A basic set of location-related measurements are
   defined, including common modes of network attachment as well as
   assisted Global Navigation Satellite System (GNSS) parameters.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Conventions used in this document  . . . . . . . . . . . . . .  6
   3.  Location-Related Measurements in LCPs  . . . . . . . . . . . .  7
     3.1.  Using Location-Releated Measurement Data . . . . . . . . .  7
   4.  Location-Related Measurement Data Types  . . . . . . . . . . . 10
     4.1.  Common Location-Related Measurement Fields . . . . . . . . 10
       4.1.1.  Time of Measurement  . . . . . . . . . . . . . . . . . 10
       4.1.2.  Expiry Time on Location-Related Measurement Data . . . 10
       4.1.3.  RMS Error and Number of Samples  . . . . . . . . . . . 11
       4.1.4.  Time RMS Error . . . . . . . . . . . . . . . . . . . . 12
     4.2.  LLDP Measurements  . . . . . . . . . . . . . . . . . . . . 12
     4.3.  DHCP Relay Agent Information Measurements  . . . . . . . . 13
     4.4.  802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 13
     4.5.  Cellular Measurements  . . . . . . . . . . . . . . . . . . 15
     4.6.  GNSS Measurements  . . . . . . . . . . . . . . . . . . . . 19
       4.6.1.  GNSS System and Signal . . . . . . . . . . . . . . . . 20
       4.6.2.  Time . . . . . . . . . . . . . . . . . . . . . . . . . 21
       4.6.3.  Per-Satellite Measurement Data . . . . . . . . . . . . 21
     4.7.  DSL Measurements . . . . . . . . . . . . . . . . . . . . . 22
       4.7.1.  L2TP Measurements  . . . . . . . . . . . . . . . . . . 22
       4.7.2.  RADIUS Measurements  . . . . . . . . . . . . . . . . . 23
       4.7.3.  Ethernet VLAN Tag Measurements . . . . . . . . . . . . 23
       4.7.4.  ATM Virtual Circuit Measurements . . . . . . . . . . . 24
   5.  Measurement Schemas  . . . . . . . . . . . . . . . . . . . . . 25
     5.1.  Measurement Container Schema . . . . . . . . . . . . . . . 26
     5.2.  Base Type Schema . . . . . . . . . . . . . . . . . . . . . 27
     5.3.  LLDP Measurement Schema  . . . . . . . . . . . . . . . . . 29
     5.4.  DHCP Measurement Schema  . . . . . . . . . . . . . . . . . 30
     5.5.  WiFi Measurement Schema  . . . . . . . . . . . . . . . . . 32
     5.6.  Cellular Measurement Schema  . . . . . . . . . . . . . . . 34
     5.7.  GNSS Measurement Schema  . . . . . . . . . . . . . . . . . 36
     5.8.  DSL Measurement Schema . . . . . . . . . . . . . . . . . . 38



Thomson & Winterbottom  Expires November 5, 2009                [Page 3]


Internet-Draft            Location Measurements                 May 2009


   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 41
     7.1.  IANA Registry for GNSS Types . . . . . . . . . . . . . . . 41
     7.2.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:lm  . . . . . . . . . . . . 42
     7.3.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:lm:basetypes  . . . . . . . 43
     7.4.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 43
     7.5.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 44
     7.6.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 45
     7.7.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 45
     7.8.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 46
     7.9.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:lm:dsl  . . . . . . . . . . 47
     7.10. XML Schema Registration for Measurement Container
           Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 47
     7.11. XML Schema Registration for Base Types Schema  . . . . . . 48
     7.12. XML Schema Registration for LLDP Schema  . . . . . . . . . 48
     7.13. XML Schema Registration for DHCP Schema  . . . . . . . . . 48
     7.14. XML Schema Registration for WiFi Schema  . . . . . . . . . 48
     7.15. XML Schema Registration for Cellular Schema  . . . . . . . 49
     7.16. XML Schema Registration for GNSS Schema  . . . . . . . . . 49
     7.17. XML Schema Registration for DSL Schema . . . . . . . . . . 49
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 51
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 51
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53


















Thomson & Winterbottom  Expires November 5, 2009                [Page 4]


Internet-Draft            Location Measurements                 May 2009


1.  Introduction

   A location configuration protocol (LCP) provides a means for a Device
   to request information about its physical location from an access
   network.  A location information server (LIS) is the server that
   provides location information; information that is available due to
   the knowledge about the network and physical environment that is
   available to the LIS.

   As a part of the access network, the LIS is able to acquire
   measurement results from network Devices within the network that are
   related to Device location.  The LIS also has access to information
   about the network topology that can be used to turn measurement data
   into location information.  However, this information can be enhanced
   with information acquired from the Device itself.

   A Device is able to make observations about its network attachment,
   or its physical environment.  The location-related measurement data
   might be unavailable to the LIS; alternatively, the LIS might be able
   to acquire the data, but at a higher cost in time or otherwise.
   Providing measurement data gives the LIS more options in determining
   location, which could improve the quality of the service provided by
   the LIS.  Improvements in accuracy are one potential gain, but
   improved response times and lower error rates are also possible.

   This document describes a means for a Device to report location-
   related measurement data to the LIS.  Examples based on the HELD
   [I-D.ietf-geopriv-http-location-delivery] location configuration
   protocol are provided.






















Thomson & Winterbottom  Expires November 5, 2009                [Page 5]


Internet-Draft            Location Measurements                 May 2009


2.  Conventions used in this document

   The terms LIS and Device are used in this document in a manner
   consistent with the usage in
   [I-D.ietf-geopriv-http-location-delivery].

   This document also uses the following definitions:

   Location Measurement:  An observation about the physical properties
      of a particular Device's network access.  The result of a location
      measurement--"location-related measurement data", or simply
      "measurement data" given sufficient context--can be used to
      determine the location of a Device.  Location-related measurement
      data does not identify a Device; measurement data can change with
      time if the location of the Device also changes.

      Location-related measurement data does not necessarily contain
      location information directly, but it can be used in combination
      with contextual knowledge of the network, or algorithms to derive
      location information.  Examples of location-related measurement
      data are: radio signal strength or timing measurements, Ethernet
      switch and port identifiers.

      Location-related measurement data can be considered sighting
      information, based on the definition in [RFC3693].

   Location Estimate:  The result of location determination, a location
      estimate is an approximation of where the Device is located.
      Location estimates are subject to uncertainty, which arise from
      errors in measurement results.

   GNSS:  Global Navigation Satellite System.  A satellite-based system
      that provides positioning and time information.  For example, the
      US Global Positioning System (GPS) or the European Galileo system.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].













Thomson & Winterbottom  Expires November 5, 2009                [Page 6]


Internet-Draft            Location Measurements                 May 2009


3.  Location-Related Measurements in LCPs

   This document defines a standard container for the conveyance of
   location-related measurement parameters in location configuration
   protocols.  This is an XML container that identifies parameters by
   type and allows the Device to provide the results of any measurement
   it is able to perform.  A set of measurement schemas are also defined
   that can be carried in the generic container.

   The simplest example of measurement data conveyance is illustrated by
   the example message in Figure 1.  This shows a HELD location request
   message with an Ethernet switch and port measurement taken using LLDP
   [IEEE.8021AB].

     <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
       <locationType exact="true">civic</locationType>
       <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                     time="2008-04-29T14:33:58">
         <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
           <chassis type="4">0a01003c</chassis>
           <port type="6">c2</port>
         </lldp>
       </measurements>
     </locationRequest>

           Figure 1: HELD Location Request with Measurement Data

   Location-related measurement data need not be provided exclusively by
   Devices.  Intermediaries involved in cooperative location
   determination, such as a the second LIS in
   [I-D.winterbottom-geopriv-lis2lis-req], might provide a LIS with
   measurement data.

   Measurement data that the LIS does not support or understand can be
   ignored.  The measurements defined in this document follow this rule;
   extensions that could result in backward incompatibility MUST be
   added as new measurement definitions rather than extensions to
   existing types.

   Multiple sets of measurement data, either of the same type or from
   different sources can be included in the "measurements" element.  See
   Section 4.1.1 for details on repetition of this element.

3.1.  Using Location-Releated Measurement Data

   Using location-related measurement data is at the discretion of the
   LIS, but the "method" parameter in the PIDF-LO SHOULD be adjusted to
   reflect the method used.



Thomson & Winterbottom  Expires November 5, 2009                [Page 7]


Internet-Draft            Location Measurements                 May 2009


   Location-related measurement data provides an attack vector for
   malicious Devices.  If it is in the interest of the Device to induce
   the LIS to provide false information about its location, measurement
   data can be indirectly used to influence the result that the LIS
   provides.  This is particularly important where the LIS provides
   certitude on the location information, either through digital
   signature or simply by serving a location reference.

   To prevent the propagation of indirectly falsified location
   information, the LIS SHOULD validate location-related measurements.
   The amount of verification might depend on the expected use of that
   data.  Any measurement data that is determined to be suspect is
   discarded.

   In one potential solution, the LIS validates any location information
   that is derived from Device-provided measurement data.  The resulting
   location information is compared against location information that
   the LIS is able to generate independently.  If the two results differ
   significantly, the measurement data is regarded as suspect and the
   results derived from that are discarded.  The allowable degree of
   difference is left to local configuration or implementation.

   Even with validation, falsified measurement data might be below a
   threshold where independent checks performed by the LIS do not reveal
   differences.  For instance, LIS might only be able to determine that
   the Device is within a certain suburb independently.  A falsified
   measurement might be provided such that the resulting location
   information is on the northern part of the suburb, when the Device is
   truly in the southern part.  The independent validation of the LIS
   might not be able to detect this attack.  However, in using
   independent validation, the LIS has limited the distance over which
   the malicious Device is able to move the result by falsifying
   measurement data.

   Whether measurement data is accepted and what validation are required
   is a matter for local policy.  For instance, different degrees of
   trust can be assigned to location-related measurement data based on
   the source of the data.  Unauthenticated Devices might be subjected
   to rigorous checking before being accepted, if the data is accepted
   at all.  Conversely, measurement data from trusted intermediaries
   might not be subjected to validation at all.

   If absolute certitude of the resulting location information is
   required, then the LIS MUST NOT use unverified information.  In this
   case, Device-provided measurement data is only of benefit if
   validation of measurement data is more efficient than collection.

   Given that the output of location determination is probabilistic, it



Thomson & Winterbottom  Expires November 5, 2009                [Page 8]


Internet-Draft            Location Measurements                 May 2009


   could be that accepting a finite probability of falsified measurement
   data is acceptable.  A decision on how much risk is accepted is left
   to local policy.

      Confidence [I-D.thomson-geopriv-uncertainty] is a measure of the
      probability that location information is correct.  [RFC5491]
      defines the confidence in PIDF-LO to be 95%.  A confidence of 95%
      allows for 5% of PIDF-LO documents to be incorrect.  Of course, it
      is understood that this 5% are statistical outliers that are still
      relatively close to the correct location.  However, this 5% also
      allows for fallibility and other errors, such as inadvertent
      mistakes arising from human error.  This might be extended to
      include an allowance for incorrect measurements, falsified or
      otherwise.





































Thomson & Winterbottom  Expires November 5, 2009                [Page 9]


Internet-Draft            Location Measurements                 May 2009


4.  Location-Related Measurement Data Types

   This document defines location-related measurement data types for a
   range of common network types.

4.1.  Common Location-Related Measurement Fields

   This section describes metadata that is common to a wide range of
   measurement data.  Time of measurement and expiry time apply to all
   measurements; RMS error and number of samples apply to selected
   measurement types.

4.1.1.  Time of Measurement

   The "time" attribute records the time that the measurement or
   observation was made.  This time can be different to the time that
   the measurement information was reported.  Time information can be
   used to populate a timestamp on the location result, or to determine
   if the measurement information is used.

   The "time" attribute is optional to avoid forcing an arbitrary choice
   of timestamp for relatively static types of measurement (for
   instance, the DSL measurements in Section 4.7) and for legacy Devices
   that don't record time information (such as the Home Location
   Register/Home Subscriber Server for cellular).  However, time SHOULD
   be provided whenever possible.

   The "time" attribute is attached to the root "measurement" element.
   If it is necessary to provide multiple sets of measurement data with
   different times, multiple "measurement" elements SHOULD be provided.

4.1.2.  Expiry Time on Location-Related Measurement Data

   A Device is able to indicate an expiry time in the location
   measurement using the "expires" attribute.  Nominally, this attribute
   indicates how long information is expected to be valid for, but it
   can also indicate a time limit on the retention and use of the
   measurement data.  A Device can use this attribute to prevent the LIS
   from retaining measurement data or limit the time that a LIS retains
   this information.

   Note:  Movement of a Device might result in the measurement data
      being invalidated before the expiry time.

   The LIS MUST NOT keep location-related measurement data beyond the
   time indicated in the "expires" attribute.  Where the "expires"
   attribute is not provided, the LIS MUST only use the location-related
   measurement data in serving the request that contained the data.



Thomson & Winterbottom  Expires November 5, 2009               [Page 10]


Internet-Draft            Location Measurements                 May 2009


   Figure 2 shows an example of a measurement that includes an expiry
   attribute.

     <lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
                      time="2008-04-29T14:33:58"
                      expires="2008-04-29T17:33:58">
       <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
         <servingWap>
           <ssid>wlan-home</ssid>
           <bssid>00-12-F0-A0-80-EF</bssid>
         </servingWap>
       </wifi>
     </lm:measurements>

                       Figure 2: Expiry Time Example

4.1.3.  RMS Error and Number of Samples

   Often a measurement is taken more than once over a period of time.
   Reporting the average of a number of measurement results mitigates
   the effects of random errors that occur in the measurement process.
   Typically, a mean value is reported at the end of the measurement
   interval, but additional information about the distribution of the
   results can be useful in determining location uncertainty.

   Two optional attributes are provided for certain measurement values:

   rmsError:  The root-mean-squared (RMS) error of the set of
      measurement values used in calculating the result.  RMS error is
      expressed in the same units as the measurement, unless otherwise
      stated.  If an accurate value for RMS error is not known, this
      value can be used to indicate an upper bound for the RMS error.

   samples:  The number of samples that were taken in determining the
      measurement value.  If omitted, this value can be assumed to be a
      very large value, so that the RMS error is an indication of the
      standard deviation of the sample set.

   For some measurement techniques, measurement error is largely
   dependent on the measurement technique employed.  In these cases,
   measurement error is largely a product of the measurement technique
   and not the specific circumstances, so RMS error does not need to be
   actively measured.  A fixed value MAY be provided for RMS error where
   appropriate.







Thomson & Winterbottom  Expires November 5, 2009               [Page 11]


Internet-Draft            Location Measurements                 May 2009


4.1.4.  Time RMS Error

   Measurement of time can be significant in certain circumstances.  The
   GNSS measurements included in this document are one such case where a
   small error in time can result in a large error in location.  Factors
   such as clock drift and errors in time sychronization can result in
   small, but significant, time errors.  Including an indication of the
   quality of the time can be helpful.

   An optional "timeError" attribute can be added to the "measurement"
   element to indicate the RMS error in time. "timeError" indicates an
   upper bound on the time RMS error in seconds.

   The "timeError" attribute does not apply where multiple samples of a
   measurement is taken over time.  If multiple samples are taken, each
   SHOULD be included in a different "measurement" element.

4.2.  LLDP Measurements

   LLDP messages are sent between adjacent nodes in an IEEE 802 network
   (e.g. wired Ethernet, WiFi, 802.16).  These messages all contain
   identification information for the sending node, which can be used to
   determine location information.  A Device that receives LLDP messages
   can report this information as a location-related measurement to the
   LIS, which is then able to use the measurement data in determining
   the location of the Device.

   The Device MUST report the values directly as they were provided by
   the adjacent node.  Attempting to adjust or translate the type of
   identifier is likely to cause the measurement data to be useless.

   Where a Device has received LLDP messages from multiple adjacent
   nodes, it should provide information extracted from those messages by
   repeating the "lldp" element.

   An example of an LLDP measurement is shown in Figure 3.  This shows
   an adjacent node (chassis) that is identified by the IP address
   192.0.2.45 (hexadecimal c000022d) and the port on that node is
   numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
         <chassis type="4">c000022d</chassis>
         <port type="6">a2</port>
       </lldp>
     </measurements>




Thomson & Winterbottom  Expires November 5, 2009               [Page 12]


Internet-Draft            Location Measurements                 May 2009


                    Figure 3: LLDP Measurement Example

   IEEE 802 Devices that are able to obtain information about adjacent
   network switches and their attachment to them by other means MAY use
   this data type to convey this information.

4.3.  DHCP Relay Agent Information Measurements

   The DHCP Relay Agent Information option [RFC3046] provides
   measurement data about the network attachment of a Device.  This
   measurement data can be included in the "dhcp-rai" element.

   The elements in the DHCP relay agent information options are opaque
   data types assigned by the DHCP relay agent.  The three items are all
   optional: circuit identifier ("circuit", [RFC3046]), remote
   identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier
   ("subscriber", [RFC3993], [RFC4580]).  The DHCPv6 remote identifier
   has an associated enterprise number [IANA.enterprise] as an XML
   attribute.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <dhcp-rai xmlns="urn:ietf:params:xml:ns:geopriv:lm:dhcp">
         <giaddr>::ffff:192.0.2.158</giaddr>
         <circuit>108b</circuit>
       </dhcp-rai>
     </measurements>

        Figure 4: DHCP Relay Agent Information Measurement Example

   The "giaddr" is specified as a dotted quad IPv4 address or an RFC
   4291 [RFC4291] IPv6 address.  The enterprise number is specified as a
   decimal integer.  All other information is included verbatim from the
   DHCP request in hexadecimal format.

4.4.  802.11 WLAN Measurements

   In WiFi, or 802.11, networks a Device might be able to provide
   information about the wireless access point (WAP) that it is attached
   to, or other WiFi points it is able to see.  This is provided using
   the "wifi" element, as shown in Figure 5.










Thomson & Winterbottom  Expires November 5, 2009               [Page 13]


Internet-Draft            Location Measurements                 May 2009


     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
         <nicType>Example WiFi Device</nicType>
         <servingWap>
           <ssid>wlan-home</ssid>
           <bssid>00-12-F0-A0-80-EF</bssid>
           <channel>7</channel>
           <rssi>-55</rssi>
         </servingWap>
         <neighbourWap>
           <ssid>wlan-home</ssid>
           <bssid>00-12-F0-A0-80-F0</bssid>
           <rssi>-65</rssi>
         </neighbourWap>
         <neighbourWap>
           <ssid>vendordefault</ssid>
           <bssid>00-12-F0-A0-80-F1</bssid>
           <rssi>-68</rssi>
         </neighbourWap>
         <neighbourWap>
           <ssid>ironicname</ssid>
           <bssid>00-12-F0-A0-80-F2</bssid>
           <rssi>-75</rssi>
         </neighbourWap>
       </wifi>
     </measurements>

                 Figure 5: 802.11 WLAN Measurement Example

   A wifi element is made up of a serving WAP, zero or more neighbouring
   WAPs, and an optional "nicType" element.  Each WAP element is
   comprised of the following fields:

   ssid:  The service set identifier for the wireless network.  This
      parameter MAY be provided.

   bssid:  The basic service set identifier.  In an Infrastructure BSS
      network, the bssid is the 48 bit MAC address of the wireless
      access point, and it MUST be provided.

   wapname:  The broadcast name for the wireless access point.  This
      element is optional.

   location:  The location of the wireless access point, as reported
      using by the wireless access point.  This optional element
      contains GML geometry, following the restrictions described in
      [RFC5491].



Thomson & Winterbottom  Expires November 5, 2009               [Page 14]


Internet-Draft            Location Measurements                 May 2009


   type:  The network type for the network access.  This element
      includes the alphabetic suffix of the 802.11 specification that
      defines the radio interface; e.g. 'a', 'b', 'g', or 'n'.  This
      element is optional.

   channel:  The channel number (frequency) that the wireless access
      point operates on.  This element is optional.

   rssi:  The received signal strength indicator of the WAP as seen by
      the wireless receiver.  This value SHOULD be in units of dBm (with
      RMS error in dB).  If the units are unknown, the "dBm" attribute
      MUST be set to "false".  Signal strength reporting on current
      hardware uses a range of different units; therefore, the value of
      the "nicType" element SHOULD be included if the units are not
      known to be in dBm and the value reported by the hardware should
      be included without modification.  This element is optional and
      includes optional "rmsError" and "samples" attributes.

   snr:  The signal to noise ratio measured by the Device, in dBm.  This
      element is optional and includes optional "rmsError" and "samples"
      attributes.

   rtt:  The total round trip time from the time that a request is sent
      by the device to the time that it receives the response from the
      access point.  This measurement includes any delays that might
      occur between the time that the access point receives the message
      and the time that it sends the response.  If the delay at an
      access point is known, this value can be used to calculate an
      approximate distance between device and access point.  This
      element is optional and includes optional "rmsError" and "samples"
      attributes.

   The "nicType" element is used to specify the make and model of the
   wireless network interface in the Device.  Different 802.11 chipsets
   report the signal strength in different ways, so the network
   interface type must be specified in order for the LIS to use signal
   strength indicators as part of its location determination process.
   The content of this field is unconstrained and no mechanisms are
   specified to ensure uniqueness.

4.5.  Cellular Measurements

   Cellular Devices are common throughout the world and base station
   identifiers can provide a good source of coarse location information.
   This information can be provided to a LIS run by the cellar operator,
   or may be provided to an alternative LIS operator that has access to
   one of several global cell-id to location mapping databases.




Thomson & Winterbottom  Expires November 5, 2009               [Page 15]


Internet-Draft            Location Measurements                 May 2009


   A number of advanced location determination methods have been
   developed for cellular networks.  For these methods a range of
   measurement parameters can be collected by the network, Device, or
   both in cooperation.  This document includes a basic identifier for
   the wireless transmitter only; future efforts might define additional
   parameters that enabled more accurate location information to be
   determined.

   The cellular measurement set allows a Device to report to a LIS any
   LTE (Figure 6), UMTS (Figure 7), GSM (Figure 8) or CDMA (Figure 9)
   cells that it is able to hear.  Cells are reported using their global
   identifiers.  All 3GPP cells are identified by public land mobile
   network (PLMN), which is formed of mobile country code (MCC) and
   mobile network code (MNC); specific fields are added for each network
   type.  All other values are decimal integers.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
         <servingCell>
           <mcc>465</mcc><mnc>20</mnc>
           <csg>1234</csg><lcid>65000</lcid>
         </servingCell>
         <observedCell>
           <mcc>465</mcc><mnc>06</mnc>
           <gid>16383</gid><cbid>32767</cbid>
         </observedCell>
       </cellular>
     </measurements>

   Long term evolution (LTE) cells are identified by group id (gid) and
   cell broadcast id (cbid), or by closed subscription group (csg) and
   local cell id (lcid).

                Figure 6: Example LTE Cellular Measurement
















Thomson & Winterbottom  Expires November 5, 2009               [Page 16]


Internet-Draft            Location Measurements                 May 2009


     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
         <servingCell>
           <mcc>465</mcc><mnc>20</mnc>
           <rnc>2000</rnc><cid>65000</cid>
         </servingCell>
         <observedCell>
           <mcc>465</mcc><mnc>06</mnc>
           <lac>16383</lac><cid>32767</cid>
         </observedCell>
       </cellular>
     </measurements>

   Universal mobile telephony service (UMTS) cells are identified by
   radio network controller (rnc) and cell id (cid).

                Figure 7: Example UMTS Cellular Measurement


     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
         <servingCell>
           <mcc>465</mcc><mnc>06</mnc>
           <lac>16383</lac><cid>32767</cid>
         </servingCell>
       </cellular>
     </measurements>

   Groupe Spe'ciale Mobile (GSM) cells are identified by local radio
   network controller (rnc) and cell id (cid).

                Figure 8: Example GSM Cellular Measurement

















Thomson & Winterbottom  Expires November 5, 2009               [Page 17]


Internet-Draft            Location Measurements                 May 2009


     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
         <servingCell>
           <nid>4723</nid><sid>15892</sid><baseid>12</baseid>
         </servingCell>
         <observedCell>
           <nid>4723</nid><sid>15892</sid><baseid>13</baseid>
         </observedCell>
       </cellular>
     </measurements>

   Code division multiple access (CDMA) cells are not identified by
   PLMN, instead these use network id (nid), system id (sid) and base
   station id (baseid).

                Figure 9: Example CDMA Cellular Measurement

   In general a cellular Device will be attached to the cellular network
   and so the notion of a serving cell exists.  Cellular network also
   provide overlap between neighbouring sites, so a mobile Device can
   hear more than one cell.  The measurement schema supports sending
   both the serving cell and any other cells that the mobile might be
   able to hear.  In some cases, the Device may simply be listening to
   cell information without actually attaching to the network, mobiles
   without a SIM are an example of this.  In this case the Device may
   simply report cells it can hear without flagging one as a serving
   cell.  An example of this is shown in Figure 10.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
         <observedCell>
           <mcc>465</mcc><mnc>20</mnc>
           <rnc>2000</rnc><cid>65000</cid>
         </observedCell>
         <observedCell>
           <mcc>465</mcc><mnc>06</mnc>
           <lac>16383</lac><cid>32767</cid>
         </observedCell>
       </cellular>
     </measurements>

             Figure 10: Example Observed Cellular Measurement







Thomson & Winterbottom  Expires November 5, 2009               [Page 18]


Internet-Draft            Location Measurements                 May 2009


4.6.  GNSS Measurements

   GNSS use orbiting satellites to transmit signals.  A Device with a
   GNSS receiver is able to take measurements from the satellite
   signals.  The results of these measurements can be used to determine
   time and the location of the Device.

   Determining location and time in autonomous GNSS receivers follows
   three steps:

   Signal acquisition:  During the signal acquisition stage, the
      receiver searches for the repeating code that is sent by each GNSS
      satellite.  Successful operation typically requires measurement
      data for a minimum of 5 satellites.  At this stage, measurement
      data is available to the Device.

   Navigation message decode:  Once the signal has been acquired, the
      receiver then receives information about the configuration of the
      satellite constellation.  This information is broadcast by each
      satellite and is modulated with the base signal at a low rate; for
      instance, GPS sends this information at about 50 bits per second.

   Calculation:  The measurement data is combined with the data on the
      satellite constellation to determine the location of the receiver
      and the current time.

   A Device that uses a GNSS receiver is able to report measurements
   after the first stage of this process.  A LIS can use the results of
   these measurements to determine a location.  In the case where there
   are fewer results available than the optimal minimum, the LIS might
   be able to use other sources of measurement information and combine
   these with the available measurement data to determine a position.

      Note: The use of different sets of GNSS _assistance data_ can
      reduce the amount of time required for the signal acquisition
      stage and obviate the need for the receiver to extract data on the
      satellite constellation.  Provision of assistance data is outside
      the scope of this document.

   Figure 11 shows an example of GNSS measurement data.  The measurement
   shown is for the GPS system and includes measurement data for three
   satellites only.









Thomson & Winterbottom  Expires November 5, 2009               [Page 19]


Internet-Draft            Location Measurements                 May 2009


     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58" timeError="2e-5">
       <gnss xmlns="urn:ietf:params:xml:ns:geopriv:lm:gnss"
             system="gps" signal="L1">
         <sat num="19">
           <doppler>499.9395</doppler>
           <codephase rmsError="1.6e-9">0.87595747</codephase>
           <cn0>45</cn0>
         </sat>
         <sat num="27">
           <doppler>378.2657</doppler>
           <codephase rmsError="1.6e-9">0.56639479</codephase>
           <cn0>52</cn0>
         </sat>
         <sat num="20">
           <doppler>-633.0309</doppler>
           <codephase rmsError="1.6e-9">0.57016835</codephase>
           <cn0>48</cn0>
         </sat>
       </gnss>
     </measurements>

                    Figure 11: Example GNSS Measurement

   Each "gnss" element represents a single set of GNSS measurement data,
   taken at a single point in time.  Measurements taken at different
   times can be included in different "gnss" elements to enable
   iterative refinement of results.

   GNSS measurement parameters are described in more detail in the
   following sections.

4.6.1.  GNSS System and Signal

   The GNSS measurement structure is designed to be generic and to apply
   to different GNSS types.  Different signals within those systems are
   also accounted for and can be measured separately.

   The GNSS type determines the time system that is used.  An indication
   of the type of system and signal can ensure that the LIS is able to
   correctly use measurements.

   Measurements for multiple GNSS types and signals can be included by
   repeating the "gnss" element.

   This document creates an IANA registry for GNSS types.  Two satellite
   systems are registered by this document: GPS and Galileo.  Details
   for the registry are included in Section 7.1.



Thomson & Winterbottom  Expires November 5, 2009               [Page 20]


Internet-Draft            Location Measurements                 May 2009


4.6.2.  Time

   Each set of GNSS measurements is taken at a specific point in time.
   The "time" attribute is used to indicate the time that the
   measurement was acquired, if the receiver knows how the time system
   used by the GNSS relates to UTC time.

   Alternative to (or in addition to) the measurement time, the
   "gnssTime" element MAY be included.  The "gnssTime" element includes
   a relative time in milliseconds using the time system native to the
   satellite system.  For the GPS satellite system, the "gnssTime"
   element includes the time of week in milliseconds.  For the Galileo
   system, the "gnssTime" element includes the time of day in
   milliseconds.

   The accuracy of the time measurement provided is critical in
   determining the accuracy of the location information derived from
   GNSS measurements.  The receiver SHOULD indicate an estimated time
   error for any time that is provided.  An RMS error can be included
   for the "gnssTime" element, with a value in milliseconds.

4.6.3.  Per-Satellite Measurement Data

   Multiple satellites are included in each set of GNSS measurements
   using the "sat" element.  Each satellite is identified by a number in
   the "num" attribute.  The satellite number is consistent with the
   identifier used in the given GNSS.

   Both the GPS and Galileo systems use satellite numbers between 1 and
   64.

   The GNSS receiver measures the following parameters for each
   satellite:

   doppler:  The observed Doppler shift of the satellite signal,
      measured in metres per second.  This is converted from a value in
      Hertz.

   codephase:  The observed code phase for the satellite signal,
      measured in milliseconds.  This is converted from a value in chips
      or wavelengths.  Increasing values indicate increasing
      pseudoranges.  This value includes an optional RMS error
      attribute, also measured in milliseconds.

   cn0:  The signal to noise ratio for the satellite signal, measured in
      decibel-Hertz (dB-Hz).  The expected range is between 20 and 50
      dB-Hz.




Thomson & Winterbottom  Expires November 5, 2009               [Page 21]


Internet-Draft            Location Measurements                 May 2009


   mp:  An estimation of the amount of error that multipath signals
      contribute in metres.  This parameter is optional.

   cq:  An indication of the carrier quality.  Two attributes are
      included: "continuous" may be either "true" or "false"; direct may
      be either "direct" or "inverted".  This parameter is optional.

   adr:  The accumulated Doppler range, measured in metres.  This
      parameter is optional and is not necessary unless multiple sets of
      GNSS measurements are provided.

   All values are converted from measures native to the satellite system
   to generic measures to ensure consistency of interpretation.  Unless
   necessary, the schema does not constrain these values.

4.7.  DSL Measurements

   Digital Subscriber Line (DSL) networks rely on a range of network
   technology.  DSL deployments regularly require cooperation between
   multiple organizations.  These fall into two broad categories:
   infrastructure providers and Internet service providers (ISPs).
   Infrastructure providers manage the bulk of the physical
   infrastructure including cabling.  End users obtain their service
   from an ISP, which manages all aspects visible to the end user
   including IP address allocation and operation of a LIS.  See
   [DSL.TR025] and [DSL.TR101] for further information on DSL network
   deployments.

   Exchange of measurement information between these organizations is
   necessary for location information to be correctly generated.  The
   ISP LIS needs to acquire location information from the infrastructure
   provider.  However, the infrastructure provider has no knowledge of
   Device identifiers, it can only identify a stream of data that is
   sent to the ISP.  This is resolved by passing measurement data
   relating to the Device to a LIS operated by the infrastructure
   provider.

4.7.1.  L2TP Measurements

   Layer 2 Tunneling Protocol (L2TP) is a common means of linking the
   infrastructure provider and the ISP.  The infrastructure provider LIS
   requires measurement data that identifies a single L2TP tunnel, from
   which it can generate location information.  Figure 12 shows an
   example L2TP measurement.







Thomson & Winterbottom  Expires November 5, 2009               [Page 22]


Internet-Draft            Location Measurements                 May 2009


     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
         <l2tp>
           <src>192.0.2.10</src>
           <dest>192.0.2.61</dest>
           <session>528</session>
         </l2tp>
       </dsl>
     </measurements>

                  Figure 12: Example DSL L2TP Measurement

4.7.2.  RADIUS Measurements

   When authenticating network access, the infrastructure provider might
   employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or
   Access Node (AN).  These messages provide the ISP RADIUS server with
   an identifier for the DSLAM or AN, plus the slot and port that the
   Device is attached on.  These data can be provided as a measurement,
   which allows the infrastructure provider LIS to generate location
   information.

   The format of the AN, slot and port identifiers are not defined in
   the RADIUS protocol.  Slot and port together identify a circuit on
   the AN, analogous to the circuit identifier in [RFC3046].  These
   items are provided directly, as they were in the RADIUS message.  An
   example is shown in Figure 13.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
         <an>AN-7692</an>
         <slot>3</slot>
         <port>06</port>
       </dsl>
     </measurements>

                 Figure 13: Example DSL RADIUS Measurement

4.7.3.  Ethernet VLAN Tag Measurements

   For Ethernet-based DSL access networks, the DSL Access Module (DSLAM)
   or Access Node (AN) provide two VLAN tags on packets.  A C-TAG is
   used to identify the incoming residential circuit, while the S-TAG is
   used to identify the DSLAM or AN.  The C-TAG and S-TAG together can
   be used to identify a single point of network attachment.  An example
   is shown in Figure 14.



Thomson & Winterbottom  Expires November 5, 2009               [Page 23]


Internet-Draft            Location Measurements                 May 2009


     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
         <stag>613</stag>
         <ctag>1097</ctag>
       </dsl>
     </measurements>

                Figure 14: Example DSL VLAN Tag Measurement

   Alternatively, the C-TAG can be replaced by data on the slot and port
   that the Device is attached to.  This information might be included
   in RADIUS requests that are proxied from the infrastructure provider
   to the ISP RADIUS server.

4.7.4.  ATM Virtual Circuit Measurements

   An ATM virtual circuit can be employed between the ISP and
   infrastructure provider.  Providing the virtual port ID (VPI) and
   virtual circuit ID (VCI) for the virtual circuit gives the
   infrastructure provider LIS the ability to identify a single data
   stream.  A sample measurement is shown in Figure 15.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58">
       <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
         <vpi>55</vpi>
         <vci>6323</vci>
       </dsl>
     </measurements>

                  Figure 15: Example DSL ATM Measurement



















Thomson & Winterbottom  Expires November 5, 2009               [Page 24]


Internet-Draft            Location Measurements                 May 2009


5.  Measurement Schemas

   The schema are broken up into their relative functions.  There is a
   base container schema into which all measurements are placed.  There
   is a basic types schema, that contains various base type definitions
   for things such as the "rmsError" and "samples" attributes IPv4, IPv6
   and MAC addresses.  Then each of the specific measurement types is
   defined in its own schema.











































Thomson & Winterbottom  Expires November 5, 2009               [Page 25]


Internet-Draft            Location Measurements                 May 2009


5.1.  Measurement Container Schema

  <?xml version="1.0"?>
  <xs:schema
      xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      targetNamespace="urn:ietf:params:xml:ns:geopriv:lm"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">

    <xs:annotation>
      <xs:appinfo
          source="urn:ietf:params:xml:schema:geopriv:held:lm">
      </xs:appinfo>
      <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
        <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
             published RFC and remove this note.]] -->
        This schema defines a framework for location measurements.
      </xs:documentation>
    </xs:annotation>

    <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>

    <xs:element name="measurements">
      <xs:complexType>
        <xs:complexContent>
          <xs:restriction base="xs:anyType">
            <xs:sequence>
              <xs:any namespace="##other" processContents="lax"
                      minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute name="time" type="xs:dateTime"/>
            <xs:attribute name="timeError" type="bt:positiveDouble"/>
            <xs:attribute name="expires" type="xs:dateTime"/>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:restriction>
        </xs:complexContent>
      </xs:complexType>
    </xs:element>

  </xs:schema>

                      Measurement Containment Schema








Thomson & Winterbottom  Expires November 5, 2009               [Page 26]


Internet-Draft            Location Measurements                 May 2009


5.2.  Base Type Schema

   Note that the pattern rules in the following schema wrap due to
   length constraints.  None of the patterns contain whitespace.

 <?xml version="1.0"?>
 <xs:schema
   xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
   elementFormDefault="qualified"
   attributeFormDefault="unqualified">

   <xs:annotation>
     <xs:appinfo
         source="urn:ietf:params:xml:schema:geopriv:lm:basetypes">
     </xs:appinfo>
     <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
       <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
            published RFC and remove this note.]] -->
       This schema defines a set of base type elements.
     </xs:documentation>
   </xs:annotation>

   <xs:simpleType name="byteType">
     <xs:restriction base="xs:integer">
       <xs:minInclusive value="0"/>
       <xs:maxInclusive value="255"/>
     </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="twoByteType">
     <xs:restriction base="xs:integer">
       <xs:minInclusive value="0"/>
       <xs:maxInclusive value="65535"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="nonNegativeDouble">
     <xs:restriction base="xs:double">
       <xs:minInclusive value="0.0"/>
     </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="positiveDouble">
     <xs:restriction base="bt:nonNegativeDouble">
       <xs:minExclusive value="0.0"/>
     </xs:restriction>
   </xs:simpleType>




Thomson & Winterbottom  Expires November 5, 2009               [Page 27]


Internet-Draft            Location Measurements                 May 2009


   <xs:complexType name="doubleWithRMSError">
     <xs:simpleContent>
       <xs:extension base="xs:double">
         <xs:attribute name="rmsError" type="bt:positiveDouble"/>
         <xs:attribute name="samples" type="xs:positiveInteger"/>
       </xs:extension>
     </xs:simpleContent>
   </xs:complexType>
   <xs:complexType name="nnDoubleWithRMSError">
     <xs:simpleContent>
       <xs:restriction base="bt:doubleWithRMSError">
         <xs:minInclusive value="0"/>
       </xs:restriction>
     </xs:simpleContent>
   </xs:complexType>

   <xs:simpleType name="ipAddressType">
     <xs:union memberTypes="bt:IPv6AddressType bt:IPv4AddressType"/>
   </xs:simpleType>

   <!-- IPv6 format definition -->
   <xs:simpleType name="IPv6AddressType">
     <xs:annotation>
       <xs:documentation>
         An IP version 6 address, based on RFC 4291.
       </xs:documentation>
     </xs:annotation>
     <xs:restriction base="xs:token">
       <!-- Fully specified address -->
       <xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
       <!-- Double colon start -->
       <xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
       <!-- Double colon middle -->
       <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
                          (:[0-9A-Fa-f]{1,4}){1}"/>
       <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
                          (:[0-9A-Fa-f]{1,4}){1,2}"/>
       <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
                          (:[0-9A-Fa-f]{1,4}){1,3}"/>
       <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
                          (:[0-9A-Fa-f]{1,4}){1,4}"/>
       <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
                          (:[0-9A-Fa-f]{1,4}){1,5}"/>
       <xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
                          (:[0-9A-Fa-f]{1,4}){1,6}"/>
       <!-- Double colon end -->
       <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/>
       <!-- IPv4-Compatible and IPv4-Mapped Addresses -->



Thomson & Winterbottom  Expires November 5, 2009               [Page 28]


Internet-Draft            Location Measurements                 May 2009


       <xs:pattern value="((:(:0{1,4}){0,3}:[fF]{4})|(0{1,4}:
                          (:0{1,4}){0,2}:[fF]{4})|((0{1,4}:){2}
                          (:0{1,4})?:[fF]{4})|((0{1,4}:){3}:[fF]{4})
                          |((0{1,4}:){4}[fF]{4})):(25[0-5]|2[0-4][0-9]|
                          [0-1]?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]
                          ?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
                          [0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
                          [0-9]?[0-9])"/>
       <!-- The unspecified address -->
       <xs:pattern value="::"/>
     </xs:restriction>
   </xs:simpleType>

   <!-- IPv4 format definition -->
   <xs:simpleType name="IPv4AddressType">
     <xs:restriction base="xs:token">
       <xs:pattern value="(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
                          (25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
                          (25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
                          (25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])"/>
     </xs:restriction>
   </xs:simpleType>

   <!-- IEEE specifies a MAC address as having a -
        between 2 hex digit pairs -->
   <xs:simpleType name="macAddressType">
     <xs:restriction base="xs:token">
       <xs:pattern value="([0-9A-Fa-f]{2}-){5}([0-9A-Fa-f]{2})"/>
     </xs:restriction>
   </xs:simpleType>

 </xs:schema>

                             Base Type Schema

5.3.  LLDP Measurement Schema

  <?xml version="1.0"?>
  <xs:schema
      xmlns:lldp="urn:ietf:params:xml:ns:geopriv:lm:lldp"
      xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:lldp"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">

    <xs:annotation>
      <xs:appinfo



Thomson & Winterbottom  Expires November 5, 2009               [Page 29]


Internet-Draft            Location Measurements                 May 2009


          source="urn:ietf:params:xml:schema:geopriv:lm:lldp">
      </xs:appinfo>
      <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
        <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
             published RFC and remove this note.]] -->
        This schema defines a set of LLDP location measurements.
      </xs:documentation>
    </xs:annotation>

    <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>

    <xs:element name="lldp" type="lldp:lldpMeasurementType"/>
    <xs:complexType name="lldpMeasurementType">
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:sequence>
            <xs:element name="chassis" type="lldp:lldpDataType"/>
            <xs:element name="port" type="lldp:lldpDataType"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:anyAttribute namespace="##any" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>

    <xs:complexType name="lldpDataType">
      <xs:simpleContent>
        <xs:extension base="lldp:lldpOctetStringType">
          <xs:attribute name="type" type="bt:byteType"
                        use="required"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>

    <xs:simpleType name="lldpOctetStringType">
      <xs:restriction base="xs:hexBinary">
        <xs:minLength value="1"/>
        <xs:maxLength value="255"/>
      </xs:restriction>
    </xs:simpleType>

  </xs:schema>

                          LLDP measurement schema

5.4.  DHCP Measurement Schema




Thomson & Winterbottom  Expires November 5, 2009               [Page 30]


Internet-Draft            Location Measurements                 May 2009


  <?xml version="1.0"?>
  <xs:schema
      xmlns:dhcp="urn:ietf:params:xml:ns:geopriv:lm:dhcp"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
      targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dhcp"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">

    <xs:annotation>
      <xs:appinfo
          source="urn:ietf:params:xml:schema:geopriv:lm:dhcp">
      </xs:appinfo>
      <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
        <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
             published RFC and remove this note.]] -->
        This schema defines a set of DHCP location measurements.
      </xs:documentation>
    </xs:annotation>

    <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>

    <!-- DHCP Relay Agent Information Option -->
    <xs:element name="dhcp-rai" type="dhcp:dhcpType"/>
    <xs:complexType name="dhcpType">
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:sequence>
            <xs:element name="giaddr" type="bt:ipAddressType"/>
            <xs:element name="circuit"
                        type="xs:hexBinary" minOccurs="0"/>
            <xs:element name="remote"
                        type="dhcp:dhcpRemoteType" minOccurs="0"/>
            <xs:element name="subscriber"
                        type="xs:hexBinary" minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:anyAttribute namespace="##any" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>

    <xs:complexType name="dhcpRemoteType">
      <xs:simpleContent>
        <xs:extension base="xs:hexBinary">
          <xs:attribute name="enterprise" type="xs:positiveInteger"
                        use="optional"/>



Thomson & Winterbottom  Expires November 5, 2009               [Page 31]


Internet-Draft            Location Measurements                 May 2009


        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>

  </xs:schema>

                          DHCP measurement schema

5.5.  WiFi Measurement Schema

  <?xml version="1.0"?>
  <xs:schema
      xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi"
      xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
      xmlns:gml="http://www.opengis.net/gml"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:wifi"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">

    <xs:annotation>
      <xs:appinfo
          source="urn:ietf:params:xml:schema:geopriv:lm:wifi">
        WiFi location measurements
      </xs:appinfo>
      <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
        <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
             published RFC and remove this note.]] -->
        This schema defines a basic set of WiFi location measurements.
      </xs:documentation>
    </xs:annotation>

    <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
    <xs:import namespace="http://www.opengis.net/gml"/>

    <xs:element name="wifi" type="wifi:wifiNetworkType"/>

    <xs:complexType name="wifiNetworkType">
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:sequence>
            <xs:element name="nicType" type="xs:token"
                        minOccurs="0"/>
            <xs:choice>
              <xs:element name="servingWap" type="wifi:wifiType"/>
              <xs:element name="neighbourWap" type="wifi:wifiType"/>
            </xs:choice>
            <xs:element name="neighbourWap" type="wifi:wifiType"



Thomson & Winterbottom  Expires November 5, 2009               [Page 32]


Internet-Draft            Location Measurements                 May 2009


                        minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:anyAttribute namespace="##any" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>

    <xs:complexType name="wifiType">
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:sequence>
            <xs:element name="ssid" type="wifi:ssidBaseType"
                        minOccurs="0"/>
            <xs:element name="bssid" type="bt:macAddressType"/>
            <xs:element name="wapname" type="wifi:ssidBaseType"
                        minOccurs="0"/>
            <xs:element name="location" minOccurs="0"
                        type="gml:GeometryPropertyType"/>
            <xs:element name="type" type="wifi:networkType"
                        minOccurs="0"/>
            <xs:element name="channel" type="xs:nonNegativeInteger"
                        minOccurs="0"/>
            <xs:element name="rssi" type="wifi:rssiType"
                        minOccurs="0"/>
            <xs:element name="snr" type="bt:doubleWithRMSError"
                        minOccurs="0"/>
            <xs:element name="rtt" type="bt:doubleWithRMSError"
                        minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:anyAttribute namespace="##any" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>

    <xs:simpleType name="ssidBaseType">
      <xs:restriction base="xs:token">
        <xs:maxLength value="32"/>
      </xs:restriction>
    </xs:simpleType>

    <xs:simpleType name="networkType">
      <xs:restriction base="xs:token">
        <xs:pattern value="[a-zA-Z]+"/>
      </xs:restriction>
    </xs:simpleType>




Thomson & Winterbottom  Expires November 5, 2009               [Page 33]


Internet-Draft            Location Measurements                 May 2009


    <xs:complexType name="rssiType">
      <xs:simpleContent>
        <xs:extension base="bt:doubleWithRMSError">
          <xs:attribute name="dBm" type="xs:boolean" default="true"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>

  </xs:schema>

                          WiFi measurement schema

5.6.  Cellular Measurement Schema

   <?xml version="1.0"?>
   <xs:schema
       xmlns:cell="urn:ietf:params:xml:ns:geopriv:lm:cell"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:cell"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified">

     <xs:annotation>
       <xs:appinfo
           source="urn:ietf:params:xml:schema:geopriv:lm:cell">
       </xs:appinfo>
       <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
         <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
              published RFC and remove this note.]] -->
         This schema defines a set of cellular location measurements.
       </xs:documentation>
     </xs:annotation>

     <xs:element name="cellular" type="cell:cellularType"/>

     <xs:complexType name="cellularType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:choice>
               <xs:element name="servingCell" type="cell:cellType"/>
               <xs:element name="observedCell" type="cell:cellType"/>
             </xs:choice>
             <xs:element name="observedCell" type="cell:cellType"
                         minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:restriction>



Thomson & Winterbottom  Expires November 5, 2009               [Page 34]


Internet-Draft            Location Measurements                 May 2009


       </xs:complexContent>
     </xs:complexType>

     <xs:complexType name="cellType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:choice>
             <xs:sequence>
               <xs:element name="mcc" type="cell:mccType"/>
               <xs:element name="mnc" type="cell:mncType"/>
               <xs:choice>
                 <xs:sequence>
                   <xs:choice>
                     <xs:element name="rnc" type="cell:cellIdType"/>
                     <xs:element name="lac" type="cell:cellIdType"/>
                   </xs:choice>
                   <xs:element name="cid" type="cell:cellIdType"/>
                 </xs:sequence>
                 <xs:sequence>
                   <xs:element name="gid" type="cell:cellIdType"/>
                   <xs:element name="cbid" type="cell:cellIdType"/>
                 </xs:sequence>
                 <xs:sequence>
                   <xs:element name="csg" type="cell:cellIdType"/>
                   <xs:element name="lcid" type="cell:cellIdType"/>
                 </xs:sequence>
               </xs:choice>
               <xs:any namespace="##other" processContents="lax"
                       minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
             <xs:sequence>
               <xs:element name="nid" type="cell:cellIdType"/>
               <xs:element name="sid" type="cell:cellIdType"/>
               <xs:element name="baseid" type="cell:cellIdType"/>
               <xs:any namespace="##other" processContents="lax"
                       minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
           </xs:choice>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:simpleType name="mccType">
       <xs:restriction base="xs:token">
         <xs:pattern value="[0-9]{3}"/>
       </xs:restriction>



Thomson & Winterbottom  Expires November 5, 2009               [Page 35]


Internet-Draft            Location Measurements                 May 2009


     </xs:simpleType>

     <xs:simpleType name="mncType">
       <xs:restriction base="xs:token">
         <xs:pattern value="[0-9]{2,3}"/>
       </xs:restriction>
     </xs:simpleType>

     <xs:simpleType name="cellIdType">
       <xs:restriction base="xs:nonNegativeInteger">
         <xs:maxInclusive value="134217728"/> <!-- 2^27 (csg) -->
       </xs:restriction>
     </xs:simpleType>

   </xs:schema>

                        Cellular measurement schema

5.7.  GNSS Measurement Schema

 <?xml version="1.0"?>
 <xs:schema
     xmlns:gnss="urn:ietf:params:xml:ns:geopriv:lm:gnss"
     xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:gnss"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">

   <xs:annotation>
     <xs:appinfo
         source="urn:ietf:params:xml:schema:geopriv:lm:gnss">
     </xs:appinfo>
     <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
       <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
            published RFC and remove this note.]] -->
       This schema defines a set of GNSS location measurements
     </xs:documentation>
   </xs:annotation>

   <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>

   <!-- GNSS -->
   <xs:element name="gnss" type="gnss:gnssMeasurementType">
     <xs:unique name="gnssSatellite">
       <xs:selector xpath="sat"/>
       <xs:field xpath="@num"/>
     </xs:unique>



Thomson & Winterbottom  Expires November 5, 2009               [Page 36]


Internet-Draft            Location Measurements                 May 2009


   </xs:element>

   <xs:complexType name="gnssMeasurementType">
     <xs:complexContent>
       <xs:restriction base="xs:anyType">
         <xs:sequence>
           <xs:element name="gnssTime" type="bt:nnDoubleWithRMSError"
                       minOccurs="0"/>
           <xs:element name="sat" type="gnss:gnssSatelliteType"
                       minOccurs="1" maxOccurs="64"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="system" type="xs:token" use="required"/>
         <xs:attribute name="signal" type="xs:token"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:restriction>
     </xs:complexContent>
   </xs:complexType>

   <xs:complexType name="gnssSatelliteType">
     <xs:complexContent>
       <xs:restriction base="xs:anyType">
         <xs:sequence>
           <xs:element name="doppler" type="xs:double"/>
           <xs:element name="codephase" type="bt:nnDoubleWithRMSError"/>
           <xs:element name="cn0" type="bt:nonNegativeDouble"/>
           <xs:element name="mp" type="bt:positiveDouble"
                       minOccurs="0"/>
           <xs:element name="cq" type="gnss:codePhaseQualityType"
                       minOccurs="0"/>
           <xs:element name="adr" type="xs:double" minOccurs="0"/>
         </xs:sequence>
         <xs:attribute name="num" type="xs:positiveInteger"
                       use="required"/>
       </xs:restriction>
     </xs:complexContent>
   </xs:complexType>

   <xs:complexType name="codePhaseQualityType">
     <xs:complexContent>
       <xs:restriction base="xs:anyType">
         <xs:attribute name="continuous" type="xs:boolean"
                       default="true"/>
         <xs:attribute name="direct" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:token">
               <xs:enumeration value="direct"/>



Thomson & Winterbottom  Expires November 5, 2009               [Page 37]


Internet-Draft            Location Measurements                 May 2009


               <xs:enumeration value="inverted"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:restriction>
     </xs:complexContent>
   </xs:complexType>
 </xs:schema>

                          GNSS measurement Schema

5.8.  DSL Measurement Schema

  <?xml version="1.0"?>
  <xs:schema
      xmlns:dsl="urn:ietf:params:xml:ns:geopriv:lm:dsl"
      xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dsl"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">

    <xs:annotation>
      <xs:appinfo
          source="urn:ietf:params:xml:schema:geopriv:lm:dsl">
        DSL measurement definitions
      </xs:appinfo>
      <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
        <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
             published RFC and remove this note.]] -->
        This schema defines a basic set of DSL location measurements.
      </xs:documentation>
    </xs:annotation>

    <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>

    <xs:element name="dsl" type="dsl:dslVlanType"/>
    <xs:complexType name="dslVlanType">
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:choice>
            <xs:element name="l2tp">
              <xs:complexType>
                <xs:complexContent>
                  <xs:restriction base="xs:anyType">
                    <xs:sequence>
                      <xs:element name="src" type="bt:ipAddressType"/>
                      <xs:element name="dest" type="bt:ipAddressType"/>



Thomson & Winterbottom  Expires November 5, 2009               [Page 38]


Internet-Draft            Location Measurements                 May 2009


                      <xs:element name="session"
                                  type="xs:nonNegativeInteger"/>
                    </xs:sequence>
                  </xs:restriction>
                </xs:complexContent>
              </xs:complexType>
            </xs:element>
            <xs:sequence>
              <xs:element name="an" type="xs:token"/>
              <xs:group ref="dsl:dslSlotPort"/>
            </xs:sequence>
            <xs:sequence>
              <xs:element name="stag" type="dsl:vlanIDType"/>
              <xs:choice>
                <xs:sequence>
                  <xs:element name="ctag" type="dsl:vlanIDType"/>
                  <xs:group ref="dsl:dslSlotPort" minOccurs="0"/>
                </xs:sequence>
                <xs:group ref="dsl:dslSlotPort"/>
              </xs:choice>
            </xs:sequence>
            <xs:sequence>
              <xs:element name="vpi" type="bt:byteType"/>
              <xs:element name="vci" type="bt:twoByteType"/>
            </xs:sequence>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:choice>
          <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>
    <xs:simpleType name="vlanIDType">
      <xs:restriction base="xs:nonNegativeInteger">
        <xs:maxInclusive value="4095"/>
      </xs:restriction>
    </xs:simpleType>
    <xs:group name="dslSlotPort">
      <xs:sequence>
        <xs:element name="slot" type="xs:token"/>
        <xs:element name="port" type="xs:token"/>
      </xs:sequence>
    </xs:group>

  </xs:schema>

                          DSL measurement schema




Thomson & Winterbottom  Expires November 5, 2009               [Page 39]


Internet-Draft            Location Measurements                 May 2009


6.  Security Considerations

   Location-related measurement data are provided by the Device for the
   sole purpose of generating more accurate location information.  The
   LIS SHOULD NOT retain location-related measurement data for any
   longer than is necessary to generate location information.

   A LIS MUST NOT reveal location-related measurement data to any other
   entity unless given explicit permission by the Device.  This document
   does not include any means to indicate such permission.

   A Device is able to explicitly limit the time that a LIS stores
   measurement data by adding an expiry time to the measurement data,
   see Section 4.1.2.

   Use of measurement data provides an opportunity for a malicious
   Device to include falsified information in the hopes of causing the
   LIS to provide a fake, or spoofed, location.  If any degree of
   certitude is assigned to the location provided by the LIS--above that
   assigned to location provided by the device--the LIS SHOULD verify
   that the measurement data is correct.  Section 3.1 discusses the
   risks and limitations involved in the use of measurement data.





























Thomson & Winterbottom  Expires November 5, 2009               [Page 40]


Internet-Draft            Location Measurements                 May 2009


7.  IANA Considerations

   This section creates a registry for GNSS types (Section 4.6) and
   registers the schema from Section 5.

7.1.  IANA Registry for GNSS Types

   This document establishes a new IANA registry for Global Navigation
   Satellite System (GNSS) types.  The registry includes tokens for the
   GNSS type and for each of the signals within that type.  Referring to
   [RFC2434], this registry operates under both "Expert Review" and
   "Specification Required" rules.  The IESG will appoint an Expert
   Reviewer who will advise IANA promptly on each request for a new or
   updated GNSS type.

   Each entry in the registry requires the following information:

   GNSS name:  the name and a brief description of the GNSS

   Brief description:  the name and a brief description of the GNSS

   GNSS token:  a token that can be used to identify the GNSS

   Signals:  a set of tokens that represent each of the signals that the
      system provides

   Documentation reference:  a reference to one or more stable, public
      specifications that outline usage of the GNSS, including (but not
      limited to) signal specifications and time systems

   The registry initially includes two registrations:

   GNSS name:  Global Positioning System (GPS)

   Brief description:  a system of satellites that use spread-spectrum
      transmission, operated by the US military for commercial and
      military applications

   GNSS token:  gps

   Signals:  L1, L2, L1C, L2C, L5

   Documentation reference:  Navstar GPS Space Segment/Navigation User
      Interface [GPS.ICD]







Thomson & Winterbottom  Expires November 5, 2009               [Page 41]


Internet-Draft            Location Measurements                 May 2009


   GNSS name:  Galileo

   Brief description:  a system of satellites that operate in the same
      spectrum as GPS, operated by the European Union for commercial
      applications

   GNSS Token:  galileo

   Signals:  L1, E5A, E5B, E5A+B, E6

   Documentation Reference:  Galileo Open Service Signal In Space
      Interface Control Document (SIS ICD) [Galileo.ICD]

7.2.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:lm

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in
   [RFC3688].

      URI: urn:ietf:params:xml:ns:geopriv:lm

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>Measurement Container</title>
             </head>
             <body>
               <h1>Namespace for Location Measurement Container</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:lm</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END







Thomson & Winterbottom  Expires November 5, 2009               [Page 42]


Internet-Draft            Location Measurements                 May 2009


7.3.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:lm:basetypes

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines
   in [RFC3688].

      URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>Base Device Types</title>
             </head>
             <body>
               <h1>Namespace for Base Types</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:lm:basetypes</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END

7.4.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:lm:lldp

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in
   [RFC3688].

      URI: urn:ietf:params:xml:ns:geopriv:lm:lldp

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

      XML:






Thomson & Winterbottom  Expires November 5, 2009               [Page 43]


Internet-Draft            Location Measurements                 May 2009


         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>LLDP Measurement Set</title>
             </head>
             <body>
               <h1>Namespace for LLDP Measurement Set</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:lm:lldp</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END

7.5.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:lm:dhcp

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in
   [RFC3688].

      URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>DHCP Measurement Set</title>
             </head>
             <body>
               <h1>Namespace for DHCP Measurement Set</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:lm:dhcp</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>



Thomson & Winterbottom  Expires November 5, 2009               [Page 44]


Internet-Draft            Location Measurements                 May 2009


         END

7.6.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:lm:wifi

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in
   [RFC3688].

      URI: urn:ietf:params:xml:ns:geopriv:lm:wifi

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>WiFi Measurement Set</title>
             </head>
             <body>
               <h1>Namespace for WiFi Measurement Set</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:lm:wifi</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END

7.7.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:lm:cell

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in
   [RFC3688].

      URI: urn:ietf:params:xml:ns:geopriv:lm:cell

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

      XML:




Thomson & Winterbottom  Expires November 5, 2009               [Page 45]


Internet-Draft            Location Measurements                 May 2009


         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>Cellular Measurement Set</title>
             </head>
             <body>
               <h1>Namespace for Cellular Measurement Set</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:lm:cell</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END

7.8.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:lm:gnss

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in
   [RFC3688].

      URI: urn:ietf:params:xml:ns:geopriv:lm:gnss

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>GNSS Measurement Set</title>
             </head>
             <body>
               <h1>Namespace for GNSS Measurement Set</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:lm:gnss</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>



Thomson & Winterbottom  Expires November 5, 2009               [Page 46]


Internet-Draft            Location Measurements                 May 2009


         END

7.9.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:lm:dsl

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in
   [RFC3688].

      URI: urn:ietf:params:xml:ns:geopriv:lm:dsl

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>DSL Measurement Set</title>
             </head>
             <body>
               <h1>Namespace for DSL Measurement Set</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:lm:dsl</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END

7.10.  XML Schema Registration for Measurement Container Schema

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:lm

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   Schema:  The XML for this schema can be found in Section 5.1 of this
      document.





Thomson & Winterbottom  Expires November 5, 2009               [Page 47]


Internet-Draft            Location Measurements                 May 2009


7.11.  XML Schema Registration for Base Types Schema

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:lm:basetypes

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   Schema:  The XML for this schema can be found in Section 5.2 of this
      document.

7.12.  XML Schema Registration for LLDP Schema

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:lm:lldp

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   Schema:  The XML for this schema can be found in Section 5.3 of this
      document.

7.13.  XML Schema Registration for DHCP Schema

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:lm:dhcp

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   Schema:  The XML for this schema can be found in Section 5.4 of this
      document.

7.14.  XML Schema Registration for WiFi Schema

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:lm:wifi






Thomson & Winterbottom  Expires November 5, 2009               [Page 48]


Internet-Draft            Location Measurements                 May 2009


   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   Schema:  The XML for this schema can be found in Section 5.5 of this
      document.

7.15.  XML Schema Registration for Cellular Schema

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:lm:cellular

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   Schema:  The XML for this schema can be found in Section 5.6 of this
      document.

7.16.  XML Schema Registration for GNSS Schema

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:lm:gnss

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   Schema:  The XML for this schema can be found in Section 5.7 of this
      document.

7.17.  XML Schema Registration for DSL Schema

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:lm:dsl

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   Schema:  The XML for this schema can be found in Section 5.8 of this
      document.







Thomson & Winterbottom  Expires November 5, 2009               [Page 49]


Internet-Draft            Location Measurements                 May 2009


8.  Acknowledgements

   Thanks go to Simon Cox for his comments relating to terminology that
   have helped ensure that this document is aligns with ongoing work in
   the Open Geospatial Consortium (OGC).  Thanks to Neil Harper for his
   review and comments on the GNSS sections of this document.  Thanks to
   Noor-E-Gagan Singh and Gabor Bajko for independent suggestions for
   improving the parameters associated with 802.11 measurements.











































Thomson & Winterbottom  Expires November 5, 2009               [Page 50]


Internet-Draft            Location Measurements                 May 2009


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC5491]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
              Presence Information Data Format Location Object (PIDF-LO)
              Usage Clarification, Considerations, and Recommendations",
              RFC 5491, March 2009.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-13 (work in
              progress), February 2009.

9.2.  Informative References

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC4649]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
              August 2006.

   [IANA.enterprise]
              IANA, "Private Enterprise Numbers",
              <http://www.iana.org/assignments/enterprise-numbers>.

   [RFC3993]  Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
              Suboption for the Dynamic Host Configuration Protocol
              (DHCP) Relay Agent Option", RFC 3993, March 2005.

   [RFC4580]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
              June 2006.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.



Thomson & Winterbottom  Expires November 5, 2009               [Page 51]


Internet-Draft            Location Measurements                 May 2009


   [IEEE.8021AB]
              IEEE, "IEEE Standard for Local and Metropolitan area
              networks, Station and Media Access Control Connectivity
              Discovery",  802.1AB, June 2005.

   [GPS.ICD]  "Navstar GPS Space Segment/Navigation User Interface",
              ICD GPS-200, Apr 2000.

   [Galileo.ICD]
              GJU, "Galileo Open Service Signal In Space Interface
              Control Document (SIS ICD)", May 2006.

   [I-D.winterbottom-geopriv-lis2lis-req]
              Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
              Requirements", draft-winterbottom-geopriv-lis2lis-req-01
              (work in progress), November 2007.

   [DSL.TR025]
              Wang, R., "Core Network Architecture Recommendations for
              Access to Legacy Data Networks over ADSL", September 1999.

   [DSL.TR101]
              Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
              Aggregation", April 2006.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [I-D.thomson-geopriv-uncertainty]
              Thomson, M. and J. Winterbottom, "Representation of
              Uncertainty and Confidence in PIDF-LO",
              draft-thomson-geopriv-uncertainty-02 (work in progress),
              November 2008.














Thomson & Winterbottom  Expires November 5, 2009               [Page 52]


Internet-Draft            Location Measurements                 May 2009


Authors' Addresses

   Martin Thomson
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2915
   Email: martin.thomson@andrew.com
   URI:   http://www.andrew.com/


   James Winterbottom
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2938
   Email: james.winterbottom@andrew.com
   URI:   http://www.andrew.com/





























Thomson & Winterbottom  Expires November 5, 2009               [Page 53]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/