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

Versions: 00 01 02 03 04 05 06 07 08 09

GEOPRIV                                                       M. Thomson
Internet-Draft                                           J. Winterbottom
Expires: August 25, 2007                                          Andrew
                                                       February 21, 2007


 Device Capability Negotiation for Device-Based Location Determination
                   and Location Measurements in HELD
             draft-thomson-geopriv-held-capabilities-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 August 25, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Thomson & Winterbottom   Expires August 25, 2007                [Page 1]


Internet-Draft              HELD Capabilities              February 2007


Abstract

   A framework for the exchange of capabilities in HELD is described.  A
   device is able to use this framework to notify a LIS of its location
   determination or location measurement capabilities.  A method based
   on this framework where the LIS can use the location determination
   capability of the device is described.  Guidelines for diverse
   location measurement technologies are included.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Capabilities Exchange  . . . . . . . . . . . . . . . . . . . .  5
   4.  The Capability Indication  . . . . . . . . . . . . . . . . . .  7
   5.  Capability Definitions . . . . . . . . . . . . . . . . . . . .  9
   6.  The Location Capability  . . . . . . . . . . . . . . . . . . . 10
     6.1.  LIS Capabilities . . . . . . . . . . . . . . . . . . . . . 10
     6.2.  Location Capability Summary  . . . . . . . . . . . . . . . 11
   7.  Application Schema . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:held:cap  . . . . . . . . . . . . . 15
     9.2.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:held:cap:location . . . . . . . . . 15
     9.3.  XML Schema Registration  . . . . . . . . . . . . . . . . . 16
   Appendix A.   Capabilities and SUPL (Informational)  . . . . . . . 17
   Appendix A.1. SUPL Overview  . . . . . . . . . . . . . . . . . . . 17
   Appendix A.2. Using SUPL with HELD . . . . . . . . . . . . . . . . 19
   Appendix A.3. Capabilities for HELD and SUPL . . . . . . . . . . . 19
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     10.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23














Thomson & Winterbottom   Expires August 25, 2007                [Page 2]


Internet-Draft              HELD Capabilities              February 2007


1.  Introduction

   A device is a good source of information about its location.  Even
   where a device is unable to independently determine its location, it
   can often make observations about its environment and network
   attachment that are of use in determining its position.  Making this
   information available to the Location Information Server (LIS) in the
   access network can improve the quality of location estimates for the
   device.  Having more information available to the LIS also improves
   yield, or the rate of success in determining location.

   Acquiring location measurements or information from a device is made
   difficult by the nature of the relationship between the LIS, or
   access network, and the device.  The relationship between a Location
   Information Server (LIS) and the devices that it serves is often
   transient.  A device is not necessarily a permanent part of an access
   network.

   HELD [I-D.winterbottom-http-location-delivery] provides a basis for
   the relationship between device and LIS, including discovery and
   session establishment.  This document relies on the concept of a HELD
   context and provides a means for the LIS to acquire information from
   the device.

   A device provides the LIS with a capabilities indication when it
   creates or updates its context data.  The LIS responds with a
   reciprocal indication, that includes which of these capabilities it
   might use.  Depending on the specific capabilities that were shared,
   the LIS is able to use some means to retrieve location information or
   location measurements from the device.

   This memo includes a sample capability that indicates that the device
   is able to determine its own location.  This is included because it
   is a unique and universal capability and it can be specified
   generically.  Further capabilities and their associated protocols
   need to be defined independently.















Thomson & Winterbottom   Expires August 25, 2007                [Page 3]


Internet-Draft              HELD Capabilities              February 2007


2.  Conventions used in this document

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

   The following terms are used in this document:

   LIS:  Location Information Server.  A server, or service responsible
      for providing location information within an access network.

   Device:  The Device is defined in [RFC3693].  The Device is also
      considered to be the Target of location determination; no reliable
      assertions about the location of a particular person can be made
      by a network that is only peripherally aware of the existence of a
      Device's user.

   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.  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 Determination:  The process of finding the location of a
      Device, either by calculation or correlation.  The many-varied
      processes for location determination are outside the scope of this
      document.

   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 innaccuracy and reduce the precision of location
      information.

   Yield:  Yield is a qualitative measure of how likely that location
      determination technology is able to produce a result.  Yield is
      determined statistically and is expressed as a probability.

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

   The terms Precision, Accuracy, Target and Context are used as defined
   in [RFC3693] and [I-D.winterbottom-http-location-delivery].




Thomson & Winterbottom   Expires August 25, 2007                [Page 4]


Internet-Draft              HELD Capabilities              February 2007


3.  Capabilities Exchange

   When a device attaches to an access network, it establishes a
   transient relationship with the Access Network LIS.  This
   relationship is established by first identifying the LIS, which
   requires a discovery process.  A device that only requires location
   information is then able to make a request for a PIDF-LO [RFC4119]
   and the relationship ends.  However, it is possible that this
   relationship is maintained over a longer period.  Devices can
   establish state information at the LIS in the form of a context,
   which is required if the LIS provides a location URI.

   This document describes how the context can be used as the basis for
   cooperative location determination.  Additional parameters are
   defined for use in context-related messages that permit the device
   and LIS to share information about their capabilities.  Device
   capabilities include the ability to generate or acquire location
   information, or the ability to make observations about the mode of
   network attachment or environment.  For instance, a device with GNSS-
   capable hardware can determine its own position by taking a set of
   measurements and performing a calculation, or it can provide the raw
   measurement data.

   At its core, the capabilities exchange is simple.  The device sends a
   set of capabilities, each identified by a URN, to the LIS inside a
   HELD "createContext" request.  The LIS selects those capabilities
   that it is able to make use of and includes those in the
   "contextResponse" message.

     +--------+                    +-------+
     | Device |                    |  LIS  |
     +--------+                    +-------+
         |                             |
         |        createContext        |
         |--(capabilities = A, B, C)-->|
         |                             |
         |        updateContext        |
         |<---(capabilities = A, C)----|
         |                             |

                      Figure 1: Capabilities Exchange

   The set of capabilities that the LIS chooses to include in the
   response are a subset of the capabilities advertised by the Device,
   except as described in Section 6.1.

   Once a common set of capabilities are agreed upon, the LIS is able to
   make use of these capabilities to generate location information.  T



Thomson & Winterbottom   Expires August 25, 2007                [Page 5]


Internet-Draft              HELD Capabilities              February 2007


   his might be an ability to generate geodetic location information at
   the device, or the device might be able provide the LIS with location
   measurements.

   Each different capability is exercised in a different fashion, using
   a protocol that is selected when the capability is defined.  The LIS
   invokes this capability in response to a request for location
   information, which can be initiated by either the device, or a
   Location Recipient (LR).

     +--------+           +-------+           +---------+
     | Device |           |  LIS  |           |   LR    |
     +--------+           +-------+           +---------+
         |                    |                    |
         |                    |                    |
         |                    |<--locationRequest--|
         |      acquire       |                    |
         |<---measurements----|                    |
         |                    |                    |
         |      location      |                    |
         |----measurements--->|                    |
         |                    |                    |
         |                    |------PIDF-LO------>|
         |                    |                    |

                     Figure 2: Exercising Capabilities

   A capabilities exchange may contain additional information that is
   specific to the associated measurement acquisition method.  This
   additional information also enables more complex negotiation between
   the Device and LIS.  Capability exchanges that use more than two
   messages can use these two messages to bootstrap a separate
   capability exchange.

   Agreed capabilities are stored in the context created for the device
   at the LIS for later use.















Thomson & Winterbottom   Expires August 25, 2007                [Page 6]


Internet-Draft              HELD Capabilities              February 2007


4.  The Capability Indication

   A "capabilities" element is added to the extension part of a HELD
   request.  The device initiates the exchange, including the
   "capabilities" element in either the "createContext" or
   "updateContext" requests.  The "contextResponse" from the LIS
   indicates which of these capabilities might be used.

   A "capabilities" element contains a set of capability indications.  A
   single capability is represented by a "capind" element.  Each
   "capind" element has a mandatory "type" attribute that contains the
   URI that identifies the capability.

   The "capind" element may also contain arbitrary content, which means
   that the element is able to carry supplementary information that is
   specific to the capability.  This supplementary information could
   include addressing information, protocol selection, authentication
   details, or any data necessary for the successful retrieval of
   information.  Different supplementary information is provided by the
   Device and LIS.

   The "capind" element has an additional optional parameter that
   indicates the maximum expected time that exercising that particular
   capability takes.  This information assists the LIS in a decision on
   whether or not to use this particular capability.  Note that the
   Device is only able to quantify the time for its own involvement in
   the process; additional delays from network transmission and LIS
   processing need to be included in any decision to exercise a device
   capability.  The "responseTime" attribute includes this information
   as either a time in seconds, or a duration type as defined in
   [W3C.REC-xmlschema-2-20041028].  The "responseTime" attribute should
   not be specified in a response from a LIS.

   The following figure shows a capabilities indication that might be
   made by a device with GNSS capabilities.  This uses the location
   capability defined in Section 6, as well as a second capability that
   includes additional parameters.

     <capabilities xmlns="urn:ietf:params:xml:ns:geopriv:held:cap">
       <capind uri="urn:ietf:params:xml:ns:geopriv:held:cap:location"
               responseTime="PT45S">
       </capind>
       <capind uri="http://www.example.org/ns/gnss/pseudorange"
               xmlns:gnss="http://www.example.org/ns/gnss/pseudorange"
               responseTime="40">
         <gnss:constellation>GPS</gnss:constellation>
       </capind>
     </capabilities>



Thomson & Winterbottom   Expires August 25, 2007                [Page 7]


Internet-Draft              HELD Capabilities              February 2007


   !!Alternative: A possible alternative to the above configuration
   doesn't include an enclosing element for each capability indication.
   This acknowledges that there are rarely more than one capability to
   express.















































Thomson & Winterbottom   Expires August 25, 2007                [Page 8]


Internet-Draft              HELD Capabilities              February 2007


5.  Capability Definitions

   Capabilities can be defined for access network or location
   measurement technologies as required.  No special registration is
   required to define a capability; each capability is identified by a
   namespace URI.  When describing a capability, the definition should
   include the following information:

   URI:  A capability is identified by a URI, which need only be unique
      and persistent.  Common practice is to use an "http:" URI for a
      domain that is under the author's control.  An IETF document
      should use a URN [RFC2141] that is registered with the IANA.

   Capability Parameters:  Each capability may require additional
      information to be passed between LIS and device in order for it to
      be exercised.  This information must be described and defined as
      XML elements for inclusion in the "capind" element.  Separate
      descriptions and definitions should be provided for the Device to
      LIS indications and LIS to Device responses.

   Procedures for Exercising Capabilities:  Each capability must also
      include a description of how it can be exercised.  This includes
      the protocol that is used for any network exchanges, the impact of
      each parameter.

   Security and Privacy Implications:  A discussion of the security and
      the privacy implications associated with using the capability must
      be included with each definition.

   Author Contact:  Details on how to contact the individual or
      organization responsible for the capability definition should be
      available.



















Thomson & Winterbottom   Expires August 25, 2007                [Page 9]


Internet-Draft              HELD Capabilities              February 2007


6.  The Location Capability

   The ability to locate itself is a trait that is applicable to devices
   in a range of networks.  This includes automated location
   determination, like Global Navigation Satellite Systems (GNSS), user
   input, or a range of location techniques.  Because the device
   produces complete location information, there is no need for
   technology- or network-specific features in messages.  Therefore,
   this section describes how a device may advertise its capability to
   source its own location.

   This section defines a location capability, identified by the URN
   "urn:ietf:params:xml:ns:geopriv:held:cap:location".  This capability
   indicates that the device is able to provide location information to
   the LIS.

   The location capability includes a URI parameter that is passed in
   the request from Device to LIS.  This URI indicates where the LIS can
   retrieve location information.  Any URI scheme that can be trivially
   resolved may be used when expressing this capability.  It is
   recommended that this be an "https:" URI.  The Device should
   authenticate the LIS based on its X.509 certificate; the TLS
   [RFC2246] cipher suite "TLS_RSA_WITH_3DES_EDE_CBC_SHA" is
   recommended.  The LIS is then able to retrieve location information
   from this URI when it needs it.

   Due to varying network configurations and the existence of NAPT and
   firewalls within some access networks, this capability is not
   universally viable.  The LIS might not be able to resolve a URI
   provided by the Device.  This limits the applicability of this, and
   possibly other capabilities, however this might be able to be
   addressed in a number of ways.  Such workarounds are dependent on
   specific network configurations, but might be considered where device
   capabilities are important to the provision of precise location
   information.

6.1.  LIS Capabilities

   A Device that is able to determine its own location might benefit
   from assistance from the LIS when it is generating location
   information.  If the Device indicates that it is capable of
   determining its own location, a LIS can provide additional
   capabilities in the response for the benefit of the device.

   The LIS advertises these capabilities without any need for feedback
   from the Device.  The Device is able to then utilize the capabilities
   provided by the LIS when it is determing its own location.  This is
   useful where the Device is not able (or willing) to respond to



Thomson & Winterbottom   Expires August 25, 2007               [Page 10]


Internet-Draft              HELD Capabilities              February 2007


   requests for location measurements, but still wishes to benefit from
   network-based assistance.  One possible use of this is for the LIS to
   indicate where the Device can acquire GNSS assistance data.

6.2.  Location Capability Summary

   The following summarizes the location capability following the
   outline of Section 5:

   URI:  urn:ietf:params:xml:ns:geopriv:held:cap:location

   Capability Parameters:  This capability has a single parameter, a URI
      that is included in a "uri" element.  The "uri" element is only
      used in the Device to LIS capabilities indication.

   Procedures for Exercising Capabilities:  This capability is exercised
      by resolving a URI.

   Security and Privacy Implications:  See Section 8 of this document.

   Author Contact:  The authors of this document.






























Thomson & Winterbottom   Expires August 25, 2007               [Page 11]


Internet-Draft              HELD Capabilities              February 2007


7.  Application Schema

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

     <xs:annotation>
       <xs:appinfo
           source="urn:ietf:params:xml:schema:geopriv:held:cap">
         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 capabilities negotiation
         in HELD.
       </xs:documentation>
     </xs:annotation>

     <xs:element name="capabilities">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="capind" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:complexType>

       <xs:unique name="capability">
         <xs:selector xpath="capind"/>
         <xs:field xpath="@uri"/>
       </xs:unique>
     </xs:element>

     <xs:element name="capind">
       <xs:complexType>
         <xs:sequence>
           <xs:any namespace="##any" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="uri" type="xs:anyURI" use="required"/>
         <xs:attribute name="responseTime" type="durationType"
                       use="optional"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:complexType>
     </xs:element>



Thomson & Winterbottom   Expires August 25, 2007               [Page 12]


Internet-Draft              HELD Capabilities              February 2007


     <xs:simpleType name="durationType">
       <xs:union>
         <xs:simpleType>
           <xs:restriction base="xs:decimal">
             <xs:minInclusive value="0.0"/>
           </xs:restriction>
         </xs:simpleType>
         <xs:simpleType>
           <xs:restriction base="xs:duration">
             <xs:minInclusive value="PT0S"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:union>
     </xs:simpleType>

     <!-- Location capability element -->
     <xs:element name="uri" type="xs:anyURI"/>

   </xs:schema>
































Thomson & Winterbottom   Expires August 25, 2007               [Page 13]


Internet-Draft              HELD Capabilities              February 2007


8.  Security Considerations

   Giving the LIS additional information about the location of a Device
   might consititute a compromise of privacy.  The LIS is able to
   resolve the location of the Device to a greater precision that would
   be otherwise possible without this assistance.  Information about the
   capabilities of a Device could also be considered sensitive.  A
   Device should offer a user the option to suppress the capability
   exchange and all associated functions.

   Any information that is provided to the LIS by the Device increases
   the impact of LIS impersonation.  Measures that mitigate the
   possibility of impersonation, as outlined in the appropriate
   discovery drafts [I-D.thomson-geopriv-lis-discovery], are more
   important for a Device that provides capability information to a LIS.
   Protocols used for the exchange of location information or location
   measurements should also provide protection from eavesdropping.

   The LIS is responsible for the accuracy of location information it
   provides, even when it relies on information that comes from the
   Device.  This is especially true when digital signatures are
   employed.  However, the LIS is not able to establish grounds for
   trust in this information.  A Device could provide erroneous
   measurements in an attempt to make the LIS provide certified,
   fraudulent location information.  The LIS should take measures to
   verify the information that is provided to it.  The LIS can use
   information from the network, or other trusted sources, to check that
   information provided by the Device is valid.























Thomson & Winterbottom   Expires August 25, 2007               [Page 14]


Internet-Draft              HELD Capabilities              February 2007


9.  IANA Considerations

9.1.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:cap

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

      URI: urn:ietf:params:xml:ns:held:cap

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

9.2.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:held:cap:location

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

      URI: urn:ietf:params:xml:ns:held:cap

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

      XML:





Thomson & Winterbottom   Expires August 25, 2007               [Page 15]


Internet-Draft              HELD Capabilities              February 2007


         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 Capabilities - Location Capability</title>
             </head>
             <body>
               <h1>Namespace for HELD Capabilities
                   - Location Capability</h1>
               <h2>urn:ietf:params:xml:ns:held:cap:location</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

9.3.  XML Schema Registration

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

   URI:  urn:ietf:params:xml:schema:held:cap

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

   Schema:  The XML for this schema can be found as the entirety of
      Section 7 of this document.




















Thomson & Winterbottom   Expires August 25, 2007               [Page 16]


Internet-Draft              HELD Capabilities              February 2007


Appendix A.  Capabilities and SUPL (Informational)

   This appendix is provided as an example only, to demonstrate how
   capabilities could be applied.  A formal specification of this
   capability is forthcoming.

   The Secure User Plane Location (SUPL) standard [OMA-LOC-SUPL-1.0]
   describes an architecture for location in cellular networks.  SUPL
   differentiates itself from the tightly integrated cellular location
   architectures (termed control plane) by using the IP network for the
   bulk of its messaging.  The primary advantage of SUPL is that it
   provides support for Assisted-GNSS.

   This appendix describes how the Assisted-GNSS feature of SUPL can be
   initiated using HELD capabilities.  The cellular-specific aspects of
   SUPL, such as network roaming, are specifically excluded.  This
   appendix is provided as an example only; the chosen namespace,
   "http://example.org/ns/held/supl" is used as a placeholder only.

Appendix A.1.  SUPL Overview

   How SUPL operates is particularly pertinent in discussing how to use
   capabilities to describe SUPL.  SUPL requires that a SUPL Enabled
   Terminal (SET) - the SUPL Device - establish a connection for the
   positioning procedure.  If the network requires a position, it can
   use a network-specific methods to trigger this; a Short Message
   Service (SMS) message, or Wireless Application Protocol (WAP) Push
   message are the available methods.  This limitation is introduced
   because a cellular device cannot be guaranteed to have IP
   connectivity all the time.  Each SET is also effectively hard-wired
   with a _Home_ server, or SUPL Location Platform (SLP) that it
   contacts.



















Thomson & Winterbottom   Expires August 25, 2007               [Page 17]


Internet-Draft              HELD Capabilities              February 2007


   In Network Initiated mode, the network triggers the positioning
   procedure with a SUPL INIT message over SMS or WAP Push.  The
   positioning procedure proper is started by the SET with a SUPL POS
   INIT.  The core of the message exchange comprises of SUPL POS
   messages, which include GNSS assistance data, measurement
   information, and location information.  The SUPL END is sent to
   signify the end of the transaction.

     +-------+                +-------+
     |  SET  |                |  SLP  |
     +-------+                +-------+
         |                        |
         |<------SUPL INIT--------|
         |                        |
         |-----SUPL POS INIT----->|
         |                        |
       +-+------------------------+-+
       |  <--    SUPL POS      -->  |
       |   Positioning Messages     |
       +-+------------------------+-+
         |                        |
         |-------SUPL END-------->|
         |                        |

                     Figure 7: Network Initiated SUPL

   A SET that wishes to locate itself, can initiate the positioning
   procedure directly.  The positioning procedure is identical for both
   methods.

     +-------+                +-------+
     |  SET  |                |  SLP  |
     +-------+                +-------+
         |                        |
         |------SUPL START------->|
         |                        |
         |<----SUPL RESPONSE------|
         |                        |
         |-----SUPL POS INIT----->|
         |                        |
       +-+------------------------+-+
       |  <--    SUPL POS      -->  |
       |   Positioning Messages     |
       +-+------------------------+-+
         |                        |
         |-------SUPL END-------->|
         |                        |




Thomson & Winterbottom   Expires August 25, 2007               [Page 18]


Internet-Draft              HELD Capabilities              February 2007


                       Figure 8: SET Initiated SUPL

Appendix A.2.  Using SUPL with HELD

   The core set of messages in the above scenarios comprises of a SUPL
   POS INIT, one or more SUPL POS messages, and a SUPL END.  The initial
   messages are only used to establish a common set of capabilities and
   to trigger the entire procedure.

   Two options exist for using the SUPL positioning procedure.  The
   first uses the location capability described in Section 6; this
   requires no changes - a device can independently contact its Home SLP
   and perform the standard SUPL SET initiated procedure to determine
   its own location.  The limitation with this is that the local network
   needs to provide an SLP; the local (or Visited) SLP needs to be able
   to communicate with the Home SLP, which implies a pre-arranged trust
   relationship.

   The second option provides additional flexibility in how the LIS
   operates, and makes the raw measurement data available.  In this
   configuration, the device exchanges SLP messages with the local LIS.
   This increases the location determination options available to the
   LIS and helps protect against location fraud.

   In order to use this positioning procedure, a number of changes are
   made to the SUPL procedures.

   o  The SET needs to be triggered using a TCP or UDP message.  The
      SUPL INIT from the Network Initiated procedure is sent over an IP
      network, since there is no support for SMS or WAP Push.

      Note: A TCP-based SUPL INIT has been considered a number of times
      for SUPL, and is likely to be included in SUPL 2.0.

   o  The SET needs to be able to contact an arbitrary SLP.  The LIS
      includes an SLP address in its capability response.

      Note that this requires a different TLS cipher suite to the pre-
      shared key scheme recommended in [OMA-LOC-SUPL-1.0] because there
      is no prior trust arrangement between the SET and SLP.  The
      standard "TLS_RSA_WITH_3DES_EDE_CBC_SHA" cipher suite is suggested
      with client authentication for when the SLP contacts the SET.

Appendix A.3.  Capabilities for HELD and SUPL

   The SUPL Network Initiated procedure is used as the basis of a new
   capability.




Thomson & Winterbottom   Expires August 25, 2007               [Page 19]


Internet-Draft              HELD Capabilities              February 2007


   For Device capabilities, the SET might need to indicate a port
   number, if this is different from that in the SUPL standard (59910).
   The capabilities indication from the SET does not need to include any
   additional parameters; the SUPL messaging can include all of the
   necessary information.  However, the SET capabilities information can
   be used by the LIS to make more intelligent decisions about when to
   request SUPL positioning.  Therefore, SET capabilities are included
   as optional parameters.

   A Device capabilities indication then look like the following:

     <capabilities xmlns="urn:ietf:params:xml:ns:geopriv:held:cap">
       <capind uri="http://example.org/ns/held/supl/cap">
               xmlns:supl="http://www.example.org/ns/held/supl">
         <supl:ulpPort>17332</supl:ulpPort>
         <supl:setcap>
           <supl:tech>SET-assisted_A-GNSS SET-based_A-GNSS</supl:tech>
           <supl:preferred>SET-assisted_A-GNSS</supl:preferred>
           <supl:protocol>RRLP</supl:protocol>
         </supl:setcap>
       </capind>
     </capabilities>

   In the response from a LIS, the capabilities include the SLP name, as
   a Fully Qualified Domain Name:

     <capabilities xmlns="urn:ietf:params:xml:ns:geopriv:held:cap">
       <capind uri="http://example.org/ns/held/supl/cap">
               xmlns:supl="http://www.example.org/ns/held/supl">
         <supl:slp>slp.local.example.net</supl:slp>
       </capind>
     </capabilities>



















Thomson & Winterbottom   Expires August 25, 2007               [Page 20]


Internet-Draft              HELD Capabilities              February 2007


10.  References

10.1.  Normative References

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

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [I-D.winterbottom-http-location-delivery]
              Winterbottom, J., "HTTP Enabled Location Delivery (HELD)",
              draft-winterbottom-http-location-delivery-04 (work in
              progress), October 2006.

   [I-D.thomson-geopriv-lis-discovery]
              Thomson, M. and J. Winterbottom, "Discovering the Local
              Location Information Server (LIS)",
              draft-thomson-geopriv-lis-discovery-00 (work in progress),
              February 2007.

   [W3C.REC-xmlschema-2-20041028]
              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
              Second Edition", World Wide Web Consortium
              Recommendation REC-xmlschema-2-20041028, October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

10.2.  Informative References

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997.

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

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

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

   [OMA-LOC-SUPL-1.0]
              OMA, "Secure User Plane Location (SUPL) 1.0", SUPL
              Enabler 1.0, Jan 2006.








Thomson & Winterbottom   Expires August 25, 2007               [Page 21]


Internet-Draft              HELD Capabilities              February 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 August 25, 2007               [Page 22]


Internet-Draft              HELD Capabilities              February 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 August 25, 2007               [Page 23]


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