GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew
Expires: January 7, 2008 July 6, 2007
Device Capability Negotiation for Device-Based Location Determination
and Location Measurements in HELD
draft-thomson-geopriv-held-capabilities-02.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 January 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Thomson & Winterbottom Expires January 7, 2008 [Page 1]
Internet-Draft HELD Capabilities July 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 . . . . . . . . . . . . . . . . . . . . 6
4. The Capability Indication . . . . . . . . . . . . . . . . . . 8
5. Capability Definitions . . . . . . . . . . . . . . . . . . . . 10
6. The Location Capability . . . . . . . . . . . . . . . . . . . 11
6.1. LCS Capabilities . . . . . . . . . . . . . . . . . . . . . 11
6.2. Location Capability Summary . . . . . . . . . . . . . . . 12
7. Application Schema . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:cap . . . . . . . . . . . . . 16
9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:cap:location . . . . . . . . . 16
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 17
Appendix A. Capabilities and SUPL (Informational) . . . . . . . 18
Appendix A.1. SUPL Overview . . . . . . . . . . . . . . . . . . . 18
Appendix A.2. Using SUPL with HELD . . . . . . . . . . . . . . . . 20
Appendix A.3. Capabilities for HELD and SUPL . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Thomson & Winterbottom Expires January 7, 2008 [Page 2]
Internet-Draft HELD Capabilities July 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 Configuration Server (LCS) in
the access network can improve the quality of location estimates for
the device. Having more information available to the LCS 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 LCS, or
access network, and the device. The relationship between a Location
Configuration Server (LCS) and the devices that it serves is often
transient. A device is not necessarily a permanent part of an access
network.
HELD [I-D.ietf-geopriv-http-location-delivery] provides a basis for
the relationship between device and LCS, including discovery and
session establishment. The relationship is extended to allow state-
based information to contained on the LCS in the form of context
using the extensions defined [I-D.winterbottom-geopriv-held-context].
This document relies on the concept of a HELD context and provides a
means for the LCS to acquire information from the device.
A device provides the LCS with a capabilities indication when it
creates or updates its context data. The LCS responds with a
reciprocal indication, that includes which of these capabilities it
might use. Depending on the specific capabilities that were shared,
the LCS 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 January 7, 2008 [Page 3]
Internet-Draft HELD Capabilities July 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:
LCS: Location Configuration 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 and Target are used as defined in
[RFC3693] and [I-D.ietf-geopriv-http-location-delivery]. The term
Thomson & Winterbottom Expires January 7, 2008 [Page 4]
Internet-Draft HELD Capabilities July 2007
Location Configuration Protocol (LCP) where used is as defined in
[I-D.ietf-geopriv-l7-lcp-ps]. The term context is used as defined in
[I-D.winterbottom-geopriv-held-context].
Thomson & Winterbottom Expires January 7, 2008 [Page 5]
Internet-Draft HELD Capabilities July 2007
3. Capabilities Exchange
When a device attaches to an access network, it establishes a
transient relationship with the Access Network LCS. This
relationship is established by first identifying the LCS, 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 LCS in the form of a context,
which is desirable if the LCS 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 LCS 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 LCS inside a
HELD "createContext" request. The LCS selects those capabilities
that it is able to make use of and includes those in the
"contextResponse" message.
+--------+ +-------+
| Device | | LCS |
+--------+ +-------+
| |
| createContext |
|--(capabilities = A, B, C)-->|
| |
| contextResponse |
|<---(capabilities = A, C)----|
| |
Figure 1: Capabilities Exchange
The set of capabilities that the LCS 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 LCS is able to
make use of these capabilities to generate location information.
Thomson & Winterbottom Expires January 7, 2008 [Page 6]
Internet-Draft HELD Capabilities July 2007
This 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 LCS
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 | | LCS | | 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 LCS. 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 LCS for later use.
Thomson & Winterbottom Expires January 7, 2008 [Page 7]
Internet-Draft HELD Capabilities July 2007
4. The Capability Indication
A "capabilities" element is added to the context manegement 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 LCS
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 LCS.
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 LCS
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 LCS.
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 January 7, 2008 [Page 8]
Internet-Draft HELD Capabilities July 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 January 7, 2008 [Page 9]
Internet-Draft HELD Capabilities July 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
LCS indications and LCS 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 January 7, 2008 [Page 10]
Internet-Draft HELD Capabilities July 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 LCS.
The location capability includes a URI parameter that is passed in
the request from Device to LCS. This URI indicates where the LCS 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 LCS based on its X.509 certificate; the TLS
[RFC2246] cipher suite "TLS_RSA_WITH_3DES_EDE_CBC_SHA" is
recommended. The LCS 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 LCS 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. LCS Capabilities
A Device that is able to determine its own location might benefit
from assistance from the LCS when it is generating location
information. If the Device indicates that it is capable of
determining its own location, a LCS can provide additional
capabilities in the response for the benefit of the device.
The LCS advertises these capabilities without any need for feedback
from the Device. The Device is able to then utilize the capabilities
provided by the LCS when it is determing its own location. This is
useful where the Device is not able (or willing) to respond to
Thomson & Winterbottom Expires January 7, 2008 [Page 11]
Internet-Draft HELD Capabilities July 2007
requests for location measurements, but still wishes to benefit from
network-based assistance. One possible use of this is for the LCS 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 January 7, 2008 [Page 12]
Internet-Draft HELD Capabilities July 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 January 7, 2008 [Page 13]
Internet-Draft HELD Capabilities July 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 January 7, 2008 [Page 14]
Internet-Draft HELD Capabilities July 2007
8. Security Considerations
Giving the LCS additional information about the location of a Device
might consititute a compromise of privacy. The LCS 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.
Capabilities MUST only be exchanged with the LCS in the scope of
context. This precaution provides the Device with a means to void
access to these capabilities at any time. The LCS MUST reject any
attempt by the Device to exchange capabilities with the LCS outside
the scope of a context by returning an empty capabilities set in the
contextResponse.
Any information that is provided to the LCS by the Device increases
the impact of LCS 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 LCS.
Protocols used for the exchange of location information or location
measurements should also provide protection from eavesdropping.
The LCS 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 LCS is not able to establish grounds for
trust in this information. A Device could provide erroneous
measurements in an attempt to make the LCS provide certified,
fraudulent location information. The LCS should take measures to
verify the information that is provided to it. The LCS can use
information from the network, or other trusted sources, to check that
information provided by the Device is valid.
Thomson & Winterbottom Expires January 7, 2008 [Page 15]
Internet-Draft HELD Capabilities July 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 January 7, 2008 [Page 16]
Internet-Draft HELD Capabilities July 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 January 7, 2008 [Page 17]
Internet-Draft HELD Capabilities July 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 January 7, 2008 [Page 18]
Internet-Draft HELD Capabilities July 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 January 7, 2008 [Page 19]
Internet-Draft HELD Capabilities July 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 may require a different TLS cipher suite to the
pre-shared key scheme recommended in [OMA-LOC-SUPL-1.0] to ensure
a trust arrangement between the SET and SLP. Alternatively a pre-
shared key can be returned in the capabilities response from the
LCS to the SET. The standard "TLS_RSA_WITH_3DES_EDE_CBC_SHA"
cipher suite is suggested with client authentication for when the
SLP contacts the SET.
Thomson & Winterbottom Expires January 7, 2008 [Page 20]
Internet-Draft HELD Capabilities July 2007
Appendix A.3. Capabilities for HELD and SUPL
The SUPL Network Initiated procedure is used as the basis of a new
capability.
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 LCS 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 LCS, the capabilities include the SLP name, as
a Fully Qualified Domain Name, and a pre-shared key for cryptographic
secturity:
<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>
<supl:psk>hdsjchew83n8938s89389</supl:psk>
</capind>
</capabilities>
Thomson & Winterbottom Expires January 7, 2008 [Page 21]
Internet-Draft HELD Capabilities July 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.ietf-geopriv-http-location-delivery]
Barnes, M., "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-00 (work in
progress), June 2007.
[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]
Malhotra, A. and P. Biron, "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>.
[I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in
progress), April 2007.
[I-D.winterbottom-geopriv-held-context]
Winterbottom, J., "HELD Protocol Context Management
Extensions", draft-winterbottom-geopriv-held-context-00
(work in progress), June 2007.
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.
Thomson & Winterbottom Expires January 7, 2008 [Page 22]
Internet-Draft HELD Capabilities July 2007
[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 January 7, 2008 [Page 23]
Internet-Draft HELD Capabilities July 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 January 7, 2008 [Page 24]
Internet-Draft HELD Capabilities July 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 January 7, 2008 [Page 25]