GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew
Expires: November 9, 2008 May 8, 2008
Using Device-provided Location-Related Measurements in HELD
draft-thomson-geopriv-held-measurements-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 November 9, 2008.
Thomson & Winterbottom Expires November 9, 2008 [Page 1]
Internet-Draft Location Measurements for HELD May 2008
Abstract
A method is described by which a Device is able to provide location-
related measurement data to a LIS within a HELD request. Location-
related measurement information are observations concerning
properties related to the position of a Device, which could be data
about network attachment or about the physical environment 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 location-related measurements are defined,
including common modes of network attachment as well as assisted
Global Navigation Satellite System (GNSS) parameters.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Location-Related Measurements in HELD Requests . . . . . . . . 6
4. Location-Related Measurement Data Types . . . . . . . . . . . 7
4.1. Common Location-Related Measurement Fields . . . . . . . . 7
4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 7
4.1.2. Expiry Time on Location-Related Measurement Data . . . 7
4.1.3. RMS Error and Number of Samples . . . . . . . . . . . 8
4.2. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 8
4.3. DHCP Relay Agent Information Measurements . . . . . . . . 9
4.4. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 10
4.5. Cellular Measurements . . . . . . . . . . . . . . . . . . 11
4.6. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 13
4.6.1. GNSS System and Signal . . . . . . . . . . . . . . . . 14
4.6.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6.3. Per-Satellite Measurement Data . . . . . . . . . . . . 15
4.7. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 16
4.7.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 17
4.7.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 17
4.7.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 18
4.7.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 18
5. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 20
5.1. Measurement Container Schema . . . . . . . . . . . . . . . 20
5.2. Base Type Schema . . . . . . . . . . . . . . . . . . . . . 21
5.3. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 23
5.4. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 25
5.5. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 26
5.6. Cellular Measurement Schema . . . . . . . . . . . . . . . 27
5.7. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 29
5.8. DSL Measurement Schema . . . . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
Thomson & Winterbottom Expires November 9, 2008 [Page 2]
Internet-Draft Location Measurements for HELD May 2008
7.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 35
7.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 36
7.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 37
7.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 37
7.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 38
7.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 39
7.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 39
7.8. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 40
7.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 41
7.10. XML Schema Registration for Measurement Container
Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.11. XML Schema Registration for Base Types Schema . . . . . . 42
7.12. XML Schema Registration for LLDP Schema . . . . . . . . . 42
7.13. XML Schema Registration for DHCP Schema . . . . . . . . . 42
7.14. XML Schema Registration for WiFi Schema . . . . . . . . . 42
7.15. XML Schema Registration for Cellular Schema . . . . . . . 43
7.16. XML Schema Registration for GNSS Schema . . . . . . . . . 43
7.17. XML Schema Registration for DSL Schema . . . . . . . . . . 43
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.1. Normative References . . . . . . . . . . . . . . . . . . . 45
9.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 48
Thomson & Winterbottom Expires November 9, 2008 [Page 3]
Internet-Draft Location Measurements for HELD May 2008
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 measurement results from network devices
within the network that are related to Device location. The LIS also
has access to information about the network topology that can be used
to turn measurement data into location information. However, this
information can be enhanced with information acquired from the Device
itself.
This document describes a means for the Device to report location-
related measurement data to the LIS. This measurement data can be
used by the LIS to improve the quality of the location estimate it
produces.
Thomson & Winterbottom Expires November 9, 2008 [Page 4]
Internet-Draft Location Measurements for HELD May 2008
2. Conventions used in this document
The terms LIS and Device are used in this document in a manner
consistent with the usage in
[I-D.ietf-geopriv-http-location-delivery].
This document also uses the following definitions:
Location Measurement: An observation about the physical properties
of a particular device's network access. The result of a location
measurement -- "location-related measurement data", or simply
"measurement data" given sufficient context -- can be used to
determine the location of a device; however, location-related
measurement data does not identify a Device. Measurement data can
change with time if the location of the Device also changes.
A location-related measurement data does not necessarily contain
location information directly, but it can be used in combination
with contextual knowledge of the network, or algorithms to derive
location information. Examples of location-related measurement
data are: radio signal strength or timing measurements, Ethernet
switch and port identifiers.
Location-related measurement data can be considered sighting
information, based on the definition in [RFC3693].
Location Estimate: The result of location determination, a location
estimate is an approximation of where the Device is located.
Location estimates are subject to uncertainty, which arise from
errors in measurement results.
GNSS: Global Navigation Satellite System. A satellite-based system
that provides positioning and time information. For example, the
US Global Positioning System (GPS) or the European Galileo system.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Thomson & Winterbottom Expires November 9, 2008 [Page 5]
Internet-Draft Location Measurements for HELD May 2008
3. Location-Related Measurements in HELD Requests
This document defines a standard container for the conveyance of
location-related measurement parameters in HELD requests. This is an
XML container that identifies parameters by type and allows the
Device to provide the results of any measurement it is able to
perform. A set of measurement schemas are also defined that can be
carried in the generic container.
The simplest example of measurement data conveyance is illustrated by
the example message in Figure 1. This shows a HELD location request
message with an Ethernet switch and port measurement taken using LLDP
[IEEE.8021AB].
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">civic</locationType>
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
<chassis type="4">0a01003c</chassis>
<port type="6">c2</port>
</lldp>
</measurements>
</locationRequest>
Figure 1: HELD Location Request with Measurement Data
Measurement data that the LIS does not support or understand can be
ignored.
Multiple sets of measurement data, either of the same type or from
different sources can be included in the "measurements" element. See
Section 4.1.1 for details on repetition of this element.
The LIS SHOULD validate any location information that is derived from
measurement data provided by Devices. Location information generated
from measurement data SHOULD be compared against location information
that the LIS is able to generate independently. If the two results
differ significantly, the LIS SHOULD discard the result that is
derived from measurement data; the allowable degree of difference is
left to local configuration or implementation.
Using location-related measurement data is at the discretion of the
LIS, but the "method" parameter in the PIDF-LO SHOULD be adjusted to
reflect the method used.
Thomson & Winterbottom Expires November 9, 2008 [Page 6]
Internet-Draft Location Measurements for HELD May 2008
4. Location-Related Measurement Data Types
This document defines location-related measurement data types for a
range of common network types.
Note: Not all of these measurement data types are provided by a
Device; they may be acquired by other hosts in situations such as
those described in [I-D.winterbottom-geopriv-lis2lis-req].
4.1. Common Location-Related Measurement Fields
This section describes metadata that is common to a wide range of
measurement data. Time of measurement and expiry time apply to all
measurements; RMS error and number of samples apply to selected
measurement types.
4.1.1. Time of Measurement
The "time" attribute records the time that the measurement or
observation was made. This time can be different to the time that
the measurement information was reported. Time information can be
used to populate a timestamp on the location result, or to determine
if the measurement information is used.
The "time" attribute is optional to avoid forcing an arbitrary choice
of timestamp for relatively static types of measurement (for
instance, the DSL measurements in Section 4.7) and for legacy devices
that don't record time information (such as the Home Location
Register/Home Subscriber Server for cellular). However, it is
RECOMMENDED that it be provided whenever possible.
The "time" attribute is attached to the root "measurement" element.
If it is necessary to provide multiple sets of measurement data with
different times, multiple "measurement" elements SHOULD be provided.
4.1.2. Expiry Time on Location-Related Measurement Data
A Device is able to indicate a time in the location measurement using
the "expires" attribute. Nominally, this attribute indicates how
long information is expected to be valid for. A Device MAY use this
attribute to prevent the LIS from retaining measurement data or limit
the time that a LIS retains this information.
The LIS MUST NOT keep location-related measurement data beyond the
time indicated in the "expires" attribute. Where the "expires"
attribute is not provided, the LIS MUST discard location-related
measurement data immediately after servicing the current request.
Thomson & Winterbottom Expires November 9, 2008 [Page 7]
Internet-Draft Location Measurements for HELD May 2008
Figure 2 shows an example of a measurement that includes an expiry
attribute.
<lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"
expires="2008-04-29T17:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<servingWap>
<ssid>wlan-home</ssid>
<bssid>00-12-F0-A0-80-EF</bssid>
</servingWap>
</wifi>
</lm:measurements>
Figure 2: Expiry Time Example
4.1.3. RMS Error and Number of Samples
Often a measurement is taken more than once over a period of time.
Reporting the average of a number of measurement results mitigates
the effects of random errors that occur in the measurement process.
Typically, a mean value is reported, but additional information about
the measurement process can be useful in determining location
uncertainty. Two optional attributes are provided for certain
measurement values:
rmsError: The root-mean-squared (RMS) error of the set of
measurement values used in calculating the result. RMS error is
expressed in the same units as the measurement, unless otherwise
stated.
samples: The number of samples that were taken in determining the
measurement value. If omitted, this value can be assumed to be a
very large value, such that the RMS error is an indication of the
standard deviation of the sample set.
4.2. LLDP Measurements
LLDP messages are sent between adjacent nodes in an IEEE 802 network
(e.g. wired Ethernet, WiFi, 802.16). These messages all contain
identification information for the sending node, which can be used to
determine location information. A Device that receives LLDP messages
can report this information as a location-related measurement to the
LIS, which is then able to use the measurement data in determining
the location of the Device.
The Device MUST report the values directly as they were provided by
the adjacent node. Attempting to adjust or translate the type of
Thomson & Winterbottom Expires November 9, 2008 [Page 8]
Internet-Draft Location Measurements for HELD May 2008
identifier is likely to cause the measurement data to be useless.
Where a Device has received LLDP messages from multiple adjacent
nodes, it should provide information extracted from those messages by
repeating the "lldp" element.
An example of an LLDP measurement is shown in Figure 3. This shows
an adjacent node (chassis) that is identified by the IP address
192.0.2.45 (hexadecimal c000022d) and the port on that node is
numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
<chassis type="4">c000022d</chassis>
<port type="6">a2</port>
</lldp>
</measurements>
Figure 3: LLDP Measurement Example
IEEE 802 Devices that are able to obtain information about adjacent
network switches and their attachment to them by other means MAY use
this data type to convey this information.
4.3. DHCP Relay Agent Information Measurements
The DHCP Relay Agent Information option [RFC3046] provides
measurement data about the network attachment of a Device. This
measurement data can be included in the "dhcp-rai" element.
The elements in the DHCP relay agent information options are opaque
data types assigned by the DHCP relay agent. The three items are all
optional: circuit identifier ("circuit", [RFC3046]), remote
identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier
("subscriber", [RFC3993], [RFC4580]). The DHCPv6 remote identifier
has an associated enterprise number [IANA.enterprise] as an XML
attribute.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dhcp-rai xmlns="urn:ietf:params:xml:ns:geopriv:lm:dhcp">
<giaddr>::ffff:192.0.2.158</giaddr>
<circuit>108b</circuit>
</dhcp-rai>
</measurements>
Figure 4: DHCP Relay Agent Information Measurement Example
Thomson & Winterbottom Expires November 9, 2008 [Page 9]
Internet-Draft Location Measurements for HELD May 2008
4.4. 802.11 WLAN Measurements
In WiFi, or 802.11, networks a Device might be able to provide
information about the wireless access point (WAP) that it is attached
to, or other WiFi points it is able to see. This is provided using
the "wifi" element, as shown in Figure 5.
A wifi element is made up of a serving WAP, zero or more neighbouring
WAPs, and an optional "nicType" element. Each WAP element is
comprised of the following fields:
ssid: The service set identifier for the wireless network. This
parameter must be provided.
bssid: The basic service set identifier. This is the 48 bit
Ethernet MAC address of the wireless access point and it must be
provided.
wapname: The broadcast name for the wireless access point. This
element is optional.
rssi: The received signal strength indicator of the WAP as seen by
the wireless receiver. This value SHOULD be in units of dBm (with
RMS error in dB). If the units are unknown, the "dBm" attribute
MUST be set to "false". Signal strength reporting on current
hardware uses a range of different units; therefore, the value of
the "nicType" element SHOULD be included if the units are not
known to be in dBm and the value reported by the hardware should
be included without modification. This element is optional and
includes optional "rmsError" and "samples" attributes.
The "nicType" element is used to specify the make and model of the
wireless network interface card in the device. Different 802.11
chipsets report the signal strength in different ways, so the nic
type must be specified in order for the LIS to use signal strength
indicators as part of its location determination process.
Thomson & Winterbottom Expires November 9, 2008 [Page 10]
Internet-Draft Location Measurements for HELD May 2008
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<nicType>Intel(r)PRO/Wireless 2200BG</nicType>
<servingWap>
<ssid>wlan-home</ssid>
<bssid>00-12-F0-A0-80-EF</bssid>
<rssi dBm="false">95</rssi>
</servingWap>
<neighbourWap>
<ssid>wlan-home</ssid>
<bssid>00-12-F0-A0-80-F0</bssid>
<rssi dBm="false">15</rssi>
</neighbourWap>
<neighbourWap>
<ssid>wlan-home</ssid>
<bssid>00-12-F0-A0-80-F1</bssid>
<rssi dBm="false">12</rssi>
</neighbourWap>
<neighbourWap>
<ssid>wlan-home</ssid>
<bssid>00-12-F0-A0-80-F2</bssid>
<rssi dBm="false">5</rssi>
</neighbourWap>
</wifi>
</measurements>
Figure 5: 802.11 WLAN Measurement Example
4.5. Cellular Measurements
GSM and UMTS cellular devices are common throughout the world and
base station identifiers can provide a good source of coarse location
information. This information can be provided to a LIS run by the
cellar operator, or may be provided to an alternative LIS operator
that has access to one of several global cell-id to location mapping
databases. The cellular measurement set allows a device to report to
a LIS any UMTS or GSM cells that it is able to hear, cells are
reported using their global identifiers.
Thomson & Winterbottom Expires November 9, 2008 [Page 11]
Internet-Draft Location Measurements for HELD May 2008
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>123</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</servingCell>
</cellular>
</measurements>
Figure 6: Example GSM Cellular Measurement
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>456</mcc><mnc>20</mnc>
<rnc>2000</rnc><cid>65000</cid>
</servingCell>
<observedCell>
<mcc>123</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</observedCell>
</cellular>
</measurements>
Figure 7: Example UMTS Cellular Measurement
In general a cellular device will be attached to the cellular network
and so the notion of a serving cell exists. Cellular network also
provide overlap between neighbouring sites, so a mobile device can
hear more than one cell. The measurement schema supports sending
both the serving cell and any other cells that the mobile might be
able to hear. In some cases, the device may simply be listening to
cell information without actually attaching to the network, mobiles
without a SIM are an example of this. In this case the device may
simply report cells it can hear without flagging one as a serving
cell. An example of this is shown in Figure 8.
Thomson & Winterbottom Expires November 9, 2008 [Page 12]
Internet-Draft Location Measurements for HELD May 2008
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<observedCell>
<mcc>456</mcc><mnc>20</mnc>
<rnc>2000</rnc><cid>65000</cid>
</observedCell>
<observedCell>
<mcc>123</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</observedCell>
</cellular>
</measurements>
Figure 8: Example Observed Cellular Measurement
4.6. GNSS Measurements
GNSS use orbiting satellites to transmit signals. A Device with a
GNSS receiver is able to take measurements from the satellite
signals. The results of these measurements can be used to determine
time and the location of the Device.
Determining location and time in autonomous GNSS receivers follows
three steps:
Signal acquisition: During the signal acquisition stage, the
receiver searches for the repeating code that is sent by each GNSS
satellite. Successful operation typically requires measurement
data for a minimum of 5 satellites. At this stage, measurement
data is available to the device.
Navigation message decode: Once the signal has been acquired, the
receiver then receives information about the configuration of the
satellite constellation. This information is broadcast by each
satellite and is modulated with the base signal at a low rate; for
instance, GPS sends this information at about 50 bits per second.
Calculation: The measurement data is combined with the data on the
satellite constellation to determine the location of the receiver
and the current time.
A Device that uses a GNSS receiver is able to report measurements
after the first stage of this process. A LIS can use the results of
these measurements to determine a location. In the case where there
are fewer results available than the optimal minimum, the LIS might
be able to use other sources of measurement information and combine
these with the available measurement data to determine a position.
Thomson & Winterbottom Expires November 9, 2008 [Page 13]
Internet-Draft Location Measurements for HELD May 2008
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 9 shows an example of GNSS measurement data. The measurement
shown is for the GPS system and includes measurement data for three
satellites only.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<gnss xmlns="urn:ietf:params:xml:ns:geopriv:lm:gnss"
system="gps" signal="L1" coarsetime="false">
<sat num="19">
<doppler>499.9395</doppler>
<codephase rmsError="1.6e-9">0.87595747</codephase>
<cn0>45</cn0>
</sat>
<sat num="27">
<doppler>378.2657</doppler>
<codephase rmsError="1.6e-9">0.56639479</codephase>
<cn0>52</cn0>
</sat>
<sat num="20">
<doppler>-633.0309</doppler>
<codephase rmsError="1.6e-9">0.57016835</codephase>
<cn0>48</cn0>
</sat>
</gnss>
</measurements>
Figure 9: Example GNSS Measurement
Each "gnss" element represents a single set of GNSS measurement data,
taken at a single point in time. Measurements taken at different
times can be included in different "gnss" elements to enable
iterative refinement of results.
GNSS measurement parameters are described in more detail in the
following sections.
4.6.1. GNSS System and Signal
The GNSS measurement structure is designed to be generic and to apply
to different GNSS types. Different signals within those systems are
also accounted for and can be measured separately.
Thomson & Winterbottom Expires November 9, 2008 [Page 14]
Internet-Draft Location Measurements for HELD May 2008
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.
4.6.2. Time
Each set of GNSS measurements is taken at a specific point in time.
The "time" attribute is used to indicate the time that the
measurement was acquired, if the receiver knows how the time system
used by the GNSS relates to UTC time.
Alternative to (or in addition to) the measurement time, the
"gnssTime" element MAY be included. The "gnssTime" element includes
a relative time in milliseconds using the time system native to the
satellite system. For the GPS satellite system, the "gnssTime"
element includes the time of week in milliseconds. For the Galileo
system, the "gnssTime" element includes the time of day in
milliseconds.
The "gnss" element includes an attribute, "coarsetime", that
indicates whether or not the time was accurately recovered by the
receiver. The default value of "false" indicates that the
uncertainty of the time value provided (either in the measurement set
or in the the "gnssTime" element) is accurate to an uncertainty of
less than one millisecond. This parameter SHOULD be set to "true" if
the receiver does not determine an accurate time before reporting
measurement results. If the "coarse" attribute is set to "true", the
actual time is derived from the other measurement data; typically
this means that additional per-satellite measurements are required.
4.6.3. Per-Satellite Measurement Data
Multiple satellites are included in each set of GNSS measurements
using the "sat" element. Each satellite is identified by a number in
the "num" attribute. The satellite number is consistent with the
identifier used in the given GNSS.
Both the GPS and Galileo systems use satellite numbers between 1 and
64.
The GNSS receiver measures the following parameters for each
Thomson & Winterbottom Expires November 9, 2008 [Page 15]
Internet-Draft Location Measurements for HELD May 2008
satellite:
doppler: The observed Doppler shift of the satellite signal,
measured in metres per second. This is converted from a value in
Hertz.
codephase: The observed code phase for the satellite signal,
measured in milliseconds. This is converted from a value in chips
or wavelengths. Increasing values indicate increasing
pseudoranges. This value includes an optional RMS error
attribute, also measured in milliseconds.
cn0: The signal to noise ratio for the satellite signal, measured in
decibel-Hertz (dB-Hz). The expected range is between 20 and 50
dB-Hz.
mp: An estimation of the amount of error that multipath signals
contribute in metres. This parameter is optional.
cq: An indication of the carrier quality. Two attributes are
included: "continuous" may be either "true" or "false"; direct may
be either "direct" or "inverted". This parameter is optional.
adr: The accumulated Doppler range, measured in metres. This
parameter is optional and is not necessary unless multiple sets of
GNSS measurements are provided.
All values are converted from measures native to the satellite system
to generic measures to ensure consistency of interpretation. Unless
necessary, the schema does not constrain these values.
4.7. DSL Measurements
Digital Subscriber Line (DSL) networks rely on a range of network
technology. DSL deployments regularly require cooperation between
multiple organizations. These fall into two broad categories:
infrastructure providers and Internet service providers (ISPs).
Infrastructure providers manage the bulk of the physical
infrastructure including cabling. End users obtain their service
from an ISP, which manages all aspects visible to the end user
including IP address allocation and operation of a LIS. See
[DSL.TR025] and [DSL.TR101] for further information on DSL network
deployments.
Exchange of measurement information between these organizations is
necessary for location information to be correctly generated. The
ISP LIS needs to acquire location information from the infrastructure
provider. However, the infrastructure provider has no knowledge of
Thomson & Winterbottom Expires November 9, 2008 [Page 16]
Internet-Draft Location Measurements for HELD May 2008
Device identifiers, it can only identify a stream of data that is
sent to the ISP. This is resolved by passing measurement data
relating to the Device to a LIS operated by the infrastructure
provider.
4.7.1. L2TP Measurements
Layer 2 Tunneling Protocol (L2TP) is a common means of linking the
infrastructure provider and the ISP. The infrastructure provider LIS
requires measurement data that identifies a single L2TP tunnel, from
which it can generate location information. Figure 10 shows an
example L2TP measurement.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<l2tp>
<src>192.0.2.10</src>
<dest>192.0.2.61</dest>
<session>528</session>
</l2tp>
</dsl>
</measurements>
Figure 10: Example DSL L2TP Measurement
4.7.2. RADIUS Measurements
When authenticating network access, the infrastructure provider might
employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or
Access Node (AN). These messages provide the ISP RADIUS server with
an identifier for the DSLAM or AN, plus the slot and port that the
Device is attached on. These data can be provided as a measurement,
which allows the infrastructure provider LIS to generate location
information.
The format of the AN, slot and port identifiers are not defined in
the RADIUS protocol. Slot and port together identify a circuit on
the AN, analogous to the circuit identifier in [RFC3046]. These
items are provided directly, as they were in the RADIUS message. An
example is shown in Figure 11.
Thomson & Winterbottom Expires November 9, 2008 [Page 17]
Internet-Draft Location Measurements for HELD May 2008
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<an>AN-7692</an>
<slot>3</slot>
<port>06</port>
</dsl>
</measurements>
Figure 11: Example DSL RADIUS Measurement
4.7.3. Ethernet VLAN Tag Measurements
For Ethernet-based DSL access networks, the DSL Access Module (DSLAM)
or Access Node (AN) provide two VLAN tags on packets. A C-TAG is
used to identify the incoming residential circuit, while the S-TAG is
used to identify the DSLAM or AN. The C-TAG and S-TAG together can
be used to identify a single point of network attachment. An example
is shown in Figure 12.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<stag>613</stag>
<ctag>1097</ctag>
</dsl>
</measurements>
Figure 12: Example DSL VLAN Tag Measurement
Alternatively, the C-TAG can be replaced by data on the slot and port
that the Device is attached to. This information might be included
in RADIUS requests that are proxied from the infrastructure provider
to the ISP RADIUS server.
4.7.4. ATM Virtual Circuit Measurements
An ATM virtual circuit can be employed between the ISP and
infrastructure provider. Providing the virtual port ID (VPI) and
virtual circuit ID (VCI) for the virtual circuit gives the
infrastructure provider LIS the ability to identify a single data
stream. A sample measurement is shown in Figure 13.
Thomson & Winterbottom Expires November 9, 2008 [Page 18]
Internet-Draft Location Measurements for HELD May 2008
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<vpi>55</vpi>
<vci>6323</vci>
</dsl>
</measurements>
Figure 13: Example DSL ATM Measurement
Thomson & Winterbottom Expires November 9, 2008 [Page 19]
Internet-Draft Location Measurements for HELD May 2008
5. Measurement Schemas
The schema are broken up into their relative functions. There is a
base container schema into which all measurements are placed. There
is a basic types schema, that contains various base type definitions
for things such as the "rmsError" and "samples" attributes IPv4, IPv6
and MAC addresses. Then each of the specific measurement types is
defined in its own schema.
5.1. Measurement Container Schema
<?xml version="1.0"?>
<xs:schema
xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:lm">
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a framework for location measurements.
</xs:documentation>
</xs:annotation>
<xs:element name="measurements">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="time" type="xs:dateTime"/>
<xs:attribute name="expires" type="xs:dateTime"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:schema>
Thomson & Winterbottom Expires November 9, 2008 [Page 20]
Internet-Draft Location Measurements for HELD May 2008
Measurement Containment Schema
5.2. Base Type Schema
Note that the pattern rules in the following schema wrap due to
length constraints. None of the patterns contain whitespace.
<?xml version="1.0"?>
<xs:schema
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:basetypes">
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a set of base type elements.
</xs:documentation>
</xs:annotation>
<xs:simpleType name="byteType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="255"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="twoByteType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="nonNegativeDouble">
<xs:restriction base="xs:double">
<xs:minInclusive value="0.0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="positiveDouble">
<xs:restriction base="bt:nonNegativeDouble">
<xs:minExclusive value="0.0"/>
</xs:restriction>
Thomson & Winterbottom Expires November 9, 2008 [Page 21]
Internet-Draft Location Measurements for HELD May 2008
</xs:simpleType>
<xs:complexType name="doubleWithRMSError">
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:attribute name="rmsError" type="bt:positiveDouble"/>
<xs:attribute name="samples" type="xs:positiveInteger"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="nnDoubleWithRMSError">
<xs:simpleContent>
<xs:restriction base="bt:doubleWithRMSError">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="ipAddressType">
<xs:union memberTypes="bt:IPv6AddressType bt:IPv4AddressType"/>
</xs:simpleType>
<!-- IPv6 format definition -->
<xs:simpleType name="IPv6AddressType">
<xs:annotation>
<xs:documentation>
An IP version 6 address, based on RFC 4291.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:token">
<!-- Fully specified address -->
<xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
<!-- Double colon start -->
<xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
<!-- Double colon middle -->
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
(:[0-9A-Fa-f]{1,4}){1}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
(:[0-9A-Fa-f]{1,4}){1,2}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
(:[0-9A-Fa-f]{1,4}){1,3}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
(:[0-9A-Fa-f]{1,4}){1,4}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
(:[0-9A-Fa-f]{1,4}){1,5}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
(:[0-9A-Fa-f]{1,4}){1,6}"/>
<!-- Double colon end -->
Thomson & Winterbottom Expires November 9, 2008 [Page 22]
Internet-Draft Location Measurements for HELD May 2008
<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>
<!-- IEEE specifies a MAC address as having a -
between 2 hex digit pairs -->
<xs:simpleType name="macAddressType">
<xs:restriction base="xs:token">
<xs:pattern value="([0-9A-Fa-f]{2}-){5}([0-9A-Fa-f]{2})"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Base Type Schema
5.3. LLDP Measurement Schema
<?xml version="1.0"?>
<xs:schema
xmlns:lldp="urn:ietf:params:xml:ns:geopriv:lm:lldp"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:lldp"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
Thomson & Winterbottom Expires November 9, 2008 [Page 23]
Internet-Draft Location Measurements for HELD May 2008
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:lldp">
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a set of LLDP location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="lldp" type="lldp:lldpMeasurementType"/>
<xs:complexType name="lldpMeasurementType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="chassis" type="lldp:lldpDataType"/>
<xs:element name="port" type="lldp:lldpDataType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="lldpDataType">
<xs:simpleContent>
<xs:extension base="lldp:lldpOctetStringType">
<xs:attribute name="type" type="bt:byteType"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="lldpOctetStringType">
<xs:restriction base="xs:hexBinary">
<xs:minLength value="1"/>
<xs:maxLength value="255"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
LLDP measurement schema
Thomson & Winterbottom Expires November 9, 2008 [Page 24]
Internet-Draft Location Measurements for HELD May 2008
5.4. DHCP Measurement Schema
<?xml version="1.0"?>
<xs:schema
xmlns:dhcp="urn:ietf:params:xml:ns:geopriv:lm:dhcp"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dhcp"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:dhcp">
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a set of DHCP location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<!-- DHCP Relay Agent Information Option -->
<xs:element name="dhcp-rai" type="dhcp:dhcpType"/>
<xs:complexType name="dhcpType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="giaddr" type="bt:ipAddressType"/>
<xs:element name="circuit"
type="xs:hexBinary" minOccurs="0"/>
<xs:element name="remote"
type="dhcp:dhcpRemoteType" minOccurs="0"/>
<xs:element name="subscriber"
type="xs:hexBinary" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="dhcpRemoteType">
<xs:simpleContent>
<xs:extension base="xs:hexBinary">
Thomson & Winterbottom Expires November 9, 2008 [Page 25]
Internet-Draft Location Measurements for HELD May 2008
<xs:attribute name="enterprise" type="xs:positiveInteger"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
DHCP measurement schema
5.5. WiFi Measurement Schema
<?xml version="1.0"?>
<xs:schema
xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:wifi"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:wifi">
WiFi location measurements
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a basic set of WiFi location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="wifi" type="wifi:wifiNetworkType"/>
<xs:complexType name="wifiNetworkType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="nicType" type="xs:token"
minOccurs="0"/>
<xs:choice>
<xs:element name="servingWap" type="wifi:wifiType"/>
<xs:element name="neighbourWap" type="wifi:wifiType"/>
</xs:choice>
<xs:element name="neighbourWap" type="wifi:wifiType"
Thomson & Winterbottom Expires November 9, 2008 [Page 26]
Internet-Draft Location Measurements for HELD May 2008
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="wifiType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="ssid" type="wifi:ssidBaseType"/>
<xs:element name="bssid" type="bt:macAddressType"/>
<xs:element name="wapname" type="wifi:ssidBaseType"
minOccurs="0"/>
<xs:element name="rssi" type="wifi:rssiType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="ssidBaseType">
<xs:restriction base="xs:token">
<xs:maxLength value="32"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="rssiType">
<xs:simpleContent>
<xs:extension base="bt:doubleWithRMSError">
<xs:attribute name="dBm" type="xs:boolean" default="true"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
WiFi measurement schema
5.6. Cellular Measurement Schema
<?xml version="1.0"?>
<xs:schema
xmlns:cell="urn:ietf:params:xml:ns:geopriv:lm:cell"
Thomson & Winterbottom Expires November 9, 2008 [Page 27]
Internet-Draft Location Measurements for HELD May 2008
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:cell"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:cell">
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a set of cellular location measurements.
</xs:documentation>
</xs:annotation>
<xs:element name="cellular" type="cell:cellularType"/>
<xs:complexType name="cellularType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:choice>
<xs:element name="servingCell" type="cell:cellType"/>
<xs:element name="observedCell" type="cell:cellType"/>
</xs:choice>
<xs:element name="observedCell" type="cell:cellType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="cellType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:sequence>
<xs:element name="mcc" type="cell:mccType"/>
<xs:element name="mnc" type="cell:mncType"/>
<xs:choice>
<xs:element name="rnc" type="cell:cellIdType"/>
<xs:element name="lac" type="cell:cellIdType"/>
</xs:choice>
<xs:element name="cid" type="cell:cellIdType"/>
</xs:sequence>
<xs:any namespace="##other" processContents="lax"
Thomson & Winterbottom Expires November 9, 2008 [Page 28]
Internet-Draft Location Measurements for HELD May 2008
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="mccType">
<xs:restriction base="xs:token">
<xs:pattern value="[0-9]{3}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="mncType">
<xs:restriction base="xs:token">
<xs:pattern value="[0-9]{2,3}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="cellIdType">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Cellular measurement schema
5.7. GNSS Measurement Schema
<?xml version="1.0"?>
<xs:schema
xmlns:gnss="urn:ietf:params:xml:ns:geopriv:lm:gnss"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:gnss"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:gnss">
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a set of GNSS location measurements
</xs:documentation>
Thomson & Winterbottom Expires November 9, 2008 [Page 29]
Internet-Draft Location Measurements for HELD May 2008
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="gnss" type="gnss: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:element name="gnssTime" type="bt:nonNegativeDouble"
minOccurs="0"/>
<xs:element name="sat" type="gnss:gnssSatelliteType"
minOccurs="1" maxOccurs="64"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="system" type="xs:token" use="required"/>
<xs:attribute name="signal" type="xs:token"/>
<xs:attribute name="coarsetime" type="xs:boolean"
default="false"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="gnssSatelliteType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="doppler" type="xs:double"/>
<xs:element name="codephase" type="bt:nnDoubleWithRMSError"/>
<xs:element name="cn0" type="bt:nonNegativeDouble"/>
<xs:element name="mp" type="bt:positiveDouble"
minOccurs="0"/>
<xs:element name="cq" type="gnss:codePhaseQualityType"
minOccurs="0"/>
<xs:element name="adr" type="xs:double" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="num" type="xs:positiveInteger"
use="required"/>
</xs:restriction>
</xs:complexContent>
Thomson & Winterbottom Expires November 9, 2008 [Page 30]
Internet-Draft Location Measurements for HELD May 2008
</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>
</xs:simpleType>
</xs:attribute>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
GNSS measurement Schema
5.8. DSL Measurement Schema
<?xml version="1.0"?>
<xs:schema
xmlns:dsl="urn:ietf:params:xml:ns:geopriv:lm:dsl"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dsl"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:dsl">
DSL measurement definitions
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a basic set of DSL location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="dsl" type="dsl:dslVlanType"/>
Thomson & Winterbottom Expires November 9, 2008 [Page 31]
Internet-Draft Location Measurements for HELD May 2008
<xs:complexType name="dslVlanType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:element name="l2tp">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="src" type="bt:ipAddressType"/>
<xs:element name="dest" type="bt:ipAddressType"/>
<xs:element name="session"
type="xs:nonNegativeInteger"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:sequence>
<xs:element name="an" type="xs:token"/>
<xs:group ref="dsl:dslSlotPort"/>
</xs:sequence>
<xs:sequence>
<xs:element name="stag" type="dsl:vlanIDType"/>
<xs:choice>
<xs:sequence>
<xs:element name="ctag" type="dsl:vlanIDType"/>
<xs:group ref="dsl:dslSlotPort" minOccurs="0"/>
</xs:sequence>
<xs:group ref="dsl:dslSlotPort"/>
</xs:choice>
</xs:sequence>
<xs:sequence>
<xs:element name="vpi" type="bt:byteType"/>
<xs:element name="vci" type="bt:twoByteType"/>
</xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="vlanIDType">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="4095"/>
</xs:restriction>
</xs:simpleType>
Thomson & Winterbottom Expires November 9, 2008 [Page 32]
Internet-Draft Location Measurements for HELD May 2008
<xs:group name="dslSlotPort">
<xs:sequence>
<xs:element name="slot" type="xs:token"/>
<xs:element name="port" type="xs:token"/>
</xs:sequence>
</xs:group>
</xs:schema>
DSL measurement schema
Thomson & Winterbottom Expires November 9, 2008 [Page 33]
Internet-Draft Location Measurements for HELD May 2008
6. Security Considerations
Location-related measurement data are provided by the Device for the
sole purpose of generating more accurate location information. The
LIS SHOULD NOT retain location-related measurement data for any
longer than is necessary to generate location information.
A LIS MUST NOT reveal location-related measurement data to any other
entity unless given explicit permission by the Device. This document
does not include any means to indicate such permission.
A Device is able to explicitly limit the time that a LIS stores
measurement data by adding an expiry time to the measurement data,
see Section 4.1.2.
Thomson & Winterbottom Expires November 9, 2008 [Page 34]
Internet-Draft Location Measurements for HELD May 2008
7. IANA Considerations
This section creates a registry for GNSS types (Section 4.6) and
registers the schema from Section 5.
7.1. IANA Registry for GNSS Types
This document establishes a new IANA registry for Global Navigation
Satellite System (GNSS) types. The registry includes tokens for the
GNSS type and for each of the signals within that type. Referring to
[RFC2434], this registry operates under both "Expert Review" and
"Specification Required" rules. The IESG will appoint an Expert
Reviewer who will advise IANA promptly on each request for a new or
updated GNSS type.
Each entry in the registry requires the following information:
GNSS name: the name and a brief description of the GNSS
Brief description: the name and a brief description of the GNSS
GNSS token: a token that can be used to identify the GNSS
Signals: a set of tokens that represent each of the signals that the
system provides
Documentation reference: a reference to 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 November 9, 2008 [Page 35]
Internet-Draft Location Measurements for HELD May 2008
GNSS name: Galileo
Brief description: a system of satellites that operate in the same
spectrum as GPS, operated by the European Union for commercial
applications
GNSS Token: galileo
Signals: L1, E5A, E5B, E5A+B, E6
Documentation Reference: Galileo Open Service Signal In Space
Interface Control Document (SIS ICD) [Galileo.ICD]
7.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Measurement Container</title>
</head>
<body>
<h1>Namespace for Location Measurement Container</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
Thomson & Winterbottom Expires November 9, 2008 [Page 36]
Internet-Draft Location Measurements for HELD May 2008
7.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:basetypes
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines
in [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Base Device Types</title>
</head>
<body>
<h1>Namespace for Base Types</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:basetypes</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
7.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:lldp
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:lldp
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
Thomson & Winterbottom Expires November 9, 2008 [Page 37]
Internet-Draft Location Measurements for HELD May 2008
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>LLDP Measurement Set</title>
</head>
<body>
<h1>Namespace for LLDP Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:lldp</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
7.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>DHCP Measurement Set</title>
</head>
<body>
<h1>Namespace for DHCP Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:dhcp</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
Thomson & Winterbottom Expires November 9, 2008 [Page 38]
Internet-Draft Location Measurements for HELD May 2008
END
7.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:wifi
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>WiFi Measurement Set</title>
</head>
<body>
<h1>Namespace for WiFi Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:wifi</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
7.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:cell
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:cell
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
Thomson & Winterbottom Expires November 9, 2008 [Page 39]
Internet-Draft Location Measurements for HELD May 2008
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Cellular Measurement Set</title>
</head>
<body>
<h1>Namespace for Cellular Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:cell</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
7.8. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:gnss
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GNSS Measurement Set</title>
</head>
<body>
<h1>Namespace for GNSS Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:gnss</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
Thomson & Winterbottom Expires November 9, 2008 [Page 40]
Internet-Draft Location Measurements for HELD May 2008
END
7.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dsl
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:dsl
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>DSL Measurement Set</title>
</head>
<body>
<h1>Namespace for DSL Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:dsl</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
7.10. XML Schema Registration for Measurement Container Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 5.1 of this
document.
Thomson & Winterbottom Expires November 9, 2008 [Page 41]
Internet-Draft Location Measurements for HELD May 2008
7.11. XML Schema Registration for Base Types Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:basetypes
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 5.2 of this
document.
7.12. XML Schema Registration for LLDP Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:lldp
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 5.3 of this
document.
7.13. XML Schema Registration for DHCP Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:dhcp
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 5.4 of this
document.
7.14. XML Schema Registration for WiFi Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:wifi
Thomson & Winterbottom Expires November 9, 2008 [Page 42]
Internet-Draft Location Measurements for HELD May 2008
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 5.5 of this
document.
7.15. XML Schema Registration for Cellular Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:cellular
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 5.6 of this
document.
7.16. XML Schema Registration for GNSS Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:gnss
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 5.7 of this
document.
7.17. XML Schema Registration for DSL Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:dsl
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 5.8 of this
document.
Thomson & Winterbottom Expires November 9, 2008 [Page 43]
Internet-Draft Location Measurements for HELD May 2008
8. Acknowledgements
Thanks go to Simon Cox for his comments relating to terminology that
have helped ensure that this document is aligns with ongoing work in
the Open Geospatial Consortium (OGC). Thanks to Dr Neil Harper for
his review and comments on the GNSS sections of this document.
Thanks to Noor-E-Gagan Singh for his suggestions relating to the WiFi
section of this document.
Thomson & Winterbottom Expires November 9, 2008 [Page 44]
Internet-Draft Location Measurements for HELD May 2008
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[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-07 (work in
progress), April 2008.
9.2. Informative References
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
August 2006.
[IANA.enterprise]
IANA, "Private Enterprise Numbers",
<http://www.iana.org/assignments/enterprise-numbers>.
[RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
Suboption for the Dynamic Host Configuration Protocol
(DHCP) Relay Agent Option", RFC 3993, March 2005.
[RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
June 2006.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[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 November 9, 2008 [Page 45]
Internet-Draft Location Measurements for HELD May 2008
[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 November 9, 2008 [Page 46]
Internet-Draft Location Measurements for HELD May 2008
Authors' Addresses
Martin Thomson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
URI: http://www.andrew.com/
James Winterbottom
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Thomson & Winterbottom Expires November 9, 2008 [Page 47]
Internet-Draft Location Measurements for HELD May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Thomson & Winterbottom Expires November 9, 2008 [Page 48]