[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: June 13, 2008                                 December 11, 2007


          Using Device-provided Location Measurements in HELD
             draft-thomson-geopriv-held-measurements-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 June 13, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Thomson & Winterbottom    Expires June 13, 2008                 [Page 1]


Internet-Draft       Location Measurements for HELD        December 2007


Abstract

   A method is described by which a Device is able to provide
   measurement data to a LIS within a HELD request.  Measurement
   information are observations about the position of a Device, which
   could be data about network attachment or about the physical
   environment around the LIS.  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 measurements are
   defined, including common modes of network attachment as well as
   assisted Global Navigation Satellite System (GNSS) parameters.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Location Measurements in HELD Requests . . . . . . . . . . . .  5
   4.  Measurement Types  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  LLDP Measurements  . . . . . . . . . . . . . . . . . . . .  6
     4.2.  DHCP Measurements  . . . . . . . . . . . . . . . . . . . .  7
     4.3.  802.11 SSID Measurement  . . . . . . . . . . . . . . . . .  7
     4.4.  GNSS Measurements  . . . . . . . . . . . . . . . . . . . .  7
       4.4.1.  GNSS System and Signal . . . . . . . . . . . . . . . .  9
       4.4.2.  Time . . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.4.3.  Per-Satellite Measurements . . . . . . . . . . . . . . 10
     4.5.  DSL Measurements . . . . . . . . . . . . . . . . . . . . . 11
       4.5.1.  L2TP Measurements  . . . . . . . . . . . . . . . . . . 11
       4.5.2.  RADIUS Measurements  . . . . . . . . . . . . . . . . . 12
       4.5.3.  Ethernet VLAN Tag Measurements . . . . . . . . . . . . 12
       4.5.4.  ATM Virtual Circuit Measurements . . . . . . . . . . . 13
   5.  Measurement Schema . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
     6.1.  Expiry Time on Measurements  . . . . . . . . . . . . . . . 21
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
     7.1.  IANA Registry for GNSS Types . . . . . . . . . . . . . . . 22
     7.2.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:held:lm . . . . . . . . . . . . . . 23
     7.3.  XML Schema Registration for Measurement Schema . . . . . . 23
     7.4.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:ip  . . . . . . . . . . . . . . . . 24
     7.5.  XML Schema Registration for IP Address Type Schema . . . . 24
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
   Intellectual Property and Copyright Statements . . . . . . . . . . 29




Thomson & Winterbottom    Expires June 13, 2008                 [Page 2]


Internet-Draft       Location Measurements for HELD        December 2007


1.  Introduction

   HELD [I-D.ietf-geopriv-http-location-delivery] describes a means for
   a device to request location information from an access network.  The
   LIS is expected to be able to retrieve the information necessary to
   generate location information.  As a part of the access network, the
   LIS is able to acquire measurements from network devices within the
   network to determine location information.  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.

   This document describes a means for the Device to report location
   measurements to the LIS.  These measurements can be used by the LIS
   to improve the quality of the location estimate it produces.



































Thomson & Winterbottom    Expires June 13, 2008                 [Page 3]


Internet-Draft       Location Measurements for HELD        December 2007


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.  A location measurement
      can be used to determine the location of a device; however,
      location measurements do not identify a Device.  Location
      measurements can change with time if the location of the Device
      also changes.

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

      Location measurements 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
      measurement errors.

   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 June 13, 2008                 [Page 4]


Internet-Draft       Location Measurements for HELD        December 2007


3.  Location Measurements in HELD Requests

   This document defines a standard container for the conveyance of
   measurement parameters in HELD requests.  This is an XML container
   that identifies measurements by type and allows the Device to provide
   any measurements it has.

   The simplest example of measurement 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:held:lm">
         <lldp>
           <chassis type="4">0a01003c</chassis>
           <port type="6">c2</port>
         </lldp>
       </measurements>
     </locationRequest>

             Figure 1: HELD Location Request with Measurement

   Measurements that the LIS does not support or understand can be
   ignored.

   Multiple measurements, either of the same type or from different
   sources can be included in the "measurements" element.  The
   "measurements" element SHOULD NOT be repeated.

   The LIS SHOULD validate any location information derived based on
   Device-provided measurements.  Any measurements that produce location
   information that is significantly different to location information
   that the LIS is able to generate independently SHOULD be discarded.
   The allowable degree of difference is left to local configuration or
   implementation.

   Using measurements is at the discretion of the LIS, but the "method"
   parameter in the PIDF-LO SHOULD be adjusted reflect the method used.











Thomson & Winterbottom    Expires June 13, 2008                 [Page 5]


Internet-Draft       Location Measurements for HELD        December 2007


4.  Measurement Types

   This document defines measurements for a range of common network
   types.

   Note:  Not all of these measurement types are provided by the Device;
      they may be acquired by other hosts in situations such as those
      described in [I-D.winterbottom-geopriv-lis2lis-req].

4.1.  LLDP Measurements

   LLDP messages are sent between adjacent nodes in an 802.x network
   (e.g. wired Ethernet, WiFi, WiMAX).  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 measurement to the LIS, which is
   then able to use the measurement 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 the type of identifier is
   likely to cause the measurement 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 2.  This shows
   an adjacent node (chassis) that is identified by the IP address
   192.0.2.45 and the port on that node is numbered using an agent
   circuit ID [RFC3046] of 162.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
       <lldp>
         <chassis type="4">c000022d</chassis>
         <port type="6">a2</port>
       </lldp>
     </measurements>

                    Figure 2: LLDP Measurement Example

   802.x 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.







Thomson & Winterbottom    Expires June 13, 2008                 [Page 6]


Internet-Draft       Location Measurements for HELD        December 2007


4.2.  DHCP Measurements

   The DHCP Relay Agent Information option [RFC3046] provides
   measurement information about a Device.  This measurement information
   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:held:lm">
       <dhcp-rai>
         <giaddr>2001:DB8::215:c5ff:fee1:505e</giaddr>
         <remote enterprise="331">108b</remote>
       </dhcp-rai>
     </measurements>

        Figure 3: DHCP Relay Agent Information Measurement Example

4.3.  802.11 SSID Measurement

   In WiFi, or 802.11, networks a Device might be able to provide the
   service set identifier (SSID) of the wireless network that it is
   attached to.  This is provided using the "ssid" element, as shown in
   Figure 4.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
       <ssid>wlan-home</ssid>
     </measurements>

                 Figure 4: 802.11 SSID Measurement Example

4.4.  GNSS Measurements

   GNSS use orbiting satellites to transmit signals.  A Device with a
   GNSS receiver is able to take measurements from the satellite
   signals.  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:






Thomson & Winterbottom    Expires June 13, 2008                 [Page 7]


Internet-Draft       Location Measurements for HELD        December 2007


   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 measurements
      for a minimum of 5 satellites.  At this stage, measurement
      information 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 information 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 these
   measurements to determine a location.  In the case where there are
   fewer measurements available than the optimal minimum, the LIS might
   be able to use other sources of measurement information and combine
   the measurements 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 5 shows an example GNSS measurement.  The measurement shown is
   for the GPS system and includes measurements for three satellites
   only.



















Thomson & Winterbottom    Expires June 13, 2008                 [Page 8]


Internet-Draft       Location Measurements for HELD        December 2007


     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
       <gnss system="gps" signal="L1">
         <time coarse="false">98375200</time>
         <sat num="19">
           <doppler>499.9395</doppler><codephase>0.87595747</codephase>
           <cn0>45</cn0><err>0.5</err>
         </sat>
         <sat num="27">
           <doppler>378.2657</doppler><codephase>0.56639479</codephase>
           <cn0>52</cn0><err>0.5</err>
         </sat>
         <sat num="20">
           <doppler>-633.0309</doppler><codephase>0.57016835</codephase>
           <cn0>48</cn0><err>0.5</err>
         </sat>
      </gnss>
     </measurements>

                    Figure 5: 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.4.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 June 13, 2008                 [Page 9]


Internet-Draft       Location Measurements for HELD        December 2007


4.4.2.  Time

   Each set of GNSS measurements is taken at a specific point in time.
   The "time" element includes a relative time in milliseconds using the
   time system native to the satellite system.

   For the GPS satellite system, the "time" element includes the time of
   week in milliseconds.  For the Galileo system, the "time" element
   includes the time of day in milliseconds.

   Alternatively, a specific instant of time can be specified using the
   "abstime" element.  This element includes an ISO 8601 formatted date
   and time, which SHOULD be measured to within one millisecond.

   The "time" element includes an attribute, "coarse", that indicates
   whether or not the time was accurately recovered by the receiver.
   This parameter SHOULD be set to "false" if the receiver does not
   determine the time accurate to within a millisecond.  If the "coarse"
   attribute is set to "false", the actual time is derived from the
   other measurement data; typically this means that additional per-
   satellite measurements are required.

4.4.3.  Per-Satellite Measurements

   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 meters 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.

   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 June 13, 2008                [Page 10]


Internet-Draft       Location Measurements for HELD        December 2007


   err:  The estimated RMS error for the code phase measurement; i.e. an
      estimate of code phase uncertainty.  This value is measured in
      meters.

   mp:  An estimation of the amount of error that multipath signals
      contribute in meters.  This measurement 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 measurement parameter is
      optional.

   adr:  The accumulated Doppler range, measured in meters.  This
      measurement parameter is optional and should not be included
      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.5.  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 information
   relating to the Device to a LIS operated by the infrastructure
   provider.

4.5.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 a measurement that identifies a single L2TP tunnel, from
   which it can generate location information.  Figure 6 shows an



Thomson & Winterbottom    Expires June 13, 2008                [Page 11]


Internet-Draft       Location Measurements for HELD        December 2007


   example L2TP measurement.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
       <dsl>
         <l2tp>
           <src>192.0.2.10</src>
           <dest>192.0.2.61</dest>
           <session>528</session>
         </l2tp>
       </dsl>
     </measurements>

                  Figure 6: Example DSL L2TP Measurement

4.5.2.  RADIUS Measurements

   When authenticating network access, the infrastructure provider might
   employ RADIUS [RFC2865] proxying 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, analagous to the circuit identifier in [RFC3046].  These
   items are provided directly, as they were in the RADIUS message.  An
   example is shown in Figure 7.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
       <dsl>
         <an>AN-7692</an>
         <slot>3</slot>
         <port>06</port>
       </dsl>
     </measurements>

                 Figure 7: Example DSL RADIUS Measurement

4.5.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 8.



Thomson & Winterbottom    Expires June 13, 2008                [Page 12]


Internet-Draft       Location Measurements for HELD        December 2007


     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
       <dsl>
         <stag>613</stag>
         <ctag>1097</ctag>
       </dsl>
     </measurements>

                Figure 8: 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.5.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 9.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
       <dsl>
         <vpi>55</vpi>
         <vci>6323</vci>
       </dsl>
     </measurements>

                   Figure 9: Example DSL ATM Measurement





















Thomson & Winterbottom    Expires June 13, 2008                [Page 13]


Internet-Draft       Location Measurements for HELD        December 2007


5.  Measurement Schema

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

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

     <xs:annotation>
       <xs:appinfo
           source="urn:ietf:params:xml:schema:geopriv:held:lm">
         HELD Capabilities
       </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
         in HELD and several measurement formats.
       </xs:documentation>
     </xs:annotation>

     <xs:element name="measurements">
       <xs:complexType>
         <xs:complexContent>
           <xs:restriction base="xs:anyType">
             <xs:sequence>
               <xs:element ref="lm:lldp" minOccurs="0"/>
               <xs:element ref="lm:dhcp-rai" minOccurs="0"/>
               <xs:element ref="lm:ssid" minOccurs="0"/>
               <xs:element ref="lm:gnss" minOccurs="0"/>
               <xs:element ref="lm:dsl" 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:element>

     <!-- LLDP -->
     <xs:element name="lldp" type="lm:lldpMeasurementType"/>
     <xs:complexType name="lldpMeasurementType">



Thomson & Winterbottom    Expires June 13, 2008                [Page 14]


Internet-Draft       Location Measurements for HELD        December 2007


       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:element name="chassis" type="lm:lldpDataType"/>
             <xs:element name="port" type="lm: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="lm:lldpOctetStringType">
           <xs:attribute name="type" type="lm: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>

     <!-- DHCP Relay Agent Information Option -->
     <xs:element name="dhcp-rai" type="lm:dhcpType"/>
     <xs:complexType name="dhcpType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:element name="giaddr" type="lm:ipAddressType"/>
             <xs:element name="circuit"
                         type="xs:hexBinary" minOccurs="0"/>
             <xs:element name="remote"
                         type="lm: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>



Thomson & Winterbottom    Expires June 13, 2008                [Page 15]


Internet-Draft       Location Measurements for HELD        December 2007


     </xs:complexType>

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

     <!-- 802.11 SSID -->
     <xs:element name="ssid" type="lm:ssidType"/>
     <xs:simpleType name="ssidType">
       <xs:restriction base="xs:token">
         <xs:maxLength value="32"/>
       </xs:restriction>
     </xs:simpleType>

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

     <xs:complexType name="gnssMeasurementType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:choice>
               <xs:element name="abstime" type="lm:gnssAbsoluteTime"/>
               <xs:element name="time" type="lm:gnssTime"/>
             </xs:choice>
             <xs:element name="sat" type="lm: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="##other" processContents="lax"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:complexType name="gnssAbsoluteTime">



Thomson & Winterbottom    Expires June 13, 2008                [Page 16]


Internet-Draft       Location Measurements for HELD        December 2007


       <xs:simpleContent>
         <xs:extension base="xs:dateTime">
           <xs:attribute name="coarse" type="xs:boolean"
                         default="false"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <xs:complexType name="gnssTime">
       <xs:simpleContent>
         <xs:extension base="lm:nonNegativeDecimal">
           <xs:attribute name="coarse" type="xs:boolean"
                         default="false"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <xs:complexType name="gnssSatelliteType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:element name="doppler" type="xs:decimal"/>
             <xs:element name="codephase" type="lm:nonNegativeDecimal"/>
             <xs:element name="cn0" type="xs:nonNegativeInteger"/>
             <xs:element name="err" type="lm:nonNegativeDecimal"/>
             <xs:element name="mp" type="xs:positiveInteger"
                         minOccurs="0"/>
             <xs:element name="cq" type="lm:codePhaseQualityType"
                         minOccurs="0"/>
             <xs:element name="adr" type="xs:decimal" 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"/>
                 <xs:enumeration value="inverted"/>
               </xs:restriction>



Thomson & Winterbottom    Expires June 13, 2008                [Page 17]


Internet-Draft       Location Measurements for HELD        December 2007


             </xs:simpleType>
           </xs:attribute>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <!-- DSL Measurements -->
     <xs:element name="dsl" type="lm: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="lm:ipAddressType"/>
                       <xs:element name="dest" type="lm:ipAddressType"/>
                       <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="lm:dslSlotPort"/>
             </xs:sequence>
             <xs:sequence>
               <xs:element name="stag" type="lm:vlanIDType"/>
               <xs:choice>
                 <xs:sequence>
                   <xs:element name="ctag" type="lm:vlanIDType"/>
                   <xs:group ref="lm:dslSlotPort" minOccurs="0"/>
                 </xs:sequence>
                 <xs:group ref="lm:dslSlotPort"/>
               </xs:choice>
             </xs:sequence>
             <xs:sequence>
               <xs:element name="vpi" type="lm:byteType"/>
               <xs:element name="vci" type="lm:twoByteType"/>
             </xs:sequence>
             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
           </xs:choice>
           <xs:anyAttribute namespace="##other" processContents="lax"/>



Thomson & Winterbottom    Expires June 13, 2008                [Page 18]


Internet-Draft       Location Measurements for HELD        December 2007


         </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>

     <!-- Common Data Types -->
     <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="nonNegativeDecimal">
       <xs:restriction base="xs:decimal">
         <xs:minInclusive value="0.0"/>
       </xs:restriction>
     </xs:simpleType>

     <xs:simpleType name="ipAddressType">
       <xs:union memberTypes="lm:IPv6AddressType lm: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 -->



Thomson & Winterbottom    Expires June 13, 2008                [Page 19]


Internet-Draft       Location Measurements for HELD        December 2007


         <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 -->
         <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>
   </xs:schema>








Thomson & Winterbottom    Expires June 13, 2008                [Page 20]


Internet-Draft       Location Measurements for HELD        December 2007


6.  Security Considerations

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

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

6.1.  Expiry Time on Measurements

   A Device is able to indicate a time in the location measurement using
   the "expires" attribute.  Nominally, this attribute indicates how
   long information is expected to be valid for, but a Device MAY use
   this attribute to prevent the LIS from retaining measurement data.

   The LIS MUST NOT keep location measurements beyond the time indicated
   in the "expires" attribute.  Where the "expires" attribute is not
   provided, the LIS MUST discard location measurements immediately
   after servicing the current request.





























Thomson & Winterbottom    Expires June 13, 2008                [Page 21]


Internet-Draft       Location Measurements for HELD        December 2007


7.  IANA Considerations

   This section creates a registry for GNSS types (Section 4.4) 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 a stable, public
      specification that outlines usage of the GNSS, including (but not
      limited to) signal specifications and time systems; additionally
      assistance data formats and supporting protocols can be specified

   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 June 13, 2008                [Page 22]


Internet-Draft       Location Measurements for HELD        December 2007


   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:held:lm

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

      URI: urn:ietf:params:xml:ns:held: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>HELD Measurements</title>
             </head>
             <body>
               <h1>Namespace for HELD Measurements</h1>
               <h2>urn:ietf:params:xml:ns:held: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

7.3.  XML Schema Registration for Measurement Schema

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




Thomson & Winterbottom    Expires June 13, 2008                [Page 23]


Internet-Draft       Location Measurements for HELD        December 2007


   URI:  urn:ietf:params:xml:schema:held: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 of this
      document.

7.4.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:ip

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

      URI: urn:ietf:params:xml:ns:ip

      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>IP Address Types</title>
             </head>
             <body>
               <h1>Namespace for IP Address Types</h1>
               <h2>urn:ietf:params:xml:ns:ip</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.  XML Schema Registration for IP Address Type Schema

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

   URI:  urn:ietf:params:xml:schema:ip







Thomson & Winterbottom    Expires June 13, 2008                [Page 24]


Internet-Draft       Location Measurements for HELD        December 2007


   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 of this
      document.














































Thomson & Winterbottom    Expires June 13, 2008                [Page 25]


Internet-Draft       Location Measurements for HELD        December 2007


8.  References

8.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.

   [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-03 (work in
              progress), November 2007.

8.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.

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



Thomson & Winterbottom    Expires June 13, 2008                [Page 26]


Internet-Draft       Location Measurements for HELD        December 2007


   [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.




























Thomson & Winterbottom    Expires June 13, 2008                [Page 27]


Internet-Draft       Location Measurements for HELD        December 2007


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 June 13, 2008                [Page 28]


Internet-Draft       Location Measurements for HELD        December 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Thomson & Winterbottom    Expires June 13, 2008                [Page 29]


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