<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 16: Example DSL ATM Measurement

6. Privacy Considerations

Location-related measurement data can be as privacy sensitive as location information [RFC6280].

Measurement data is effectively equivalent to location information if the contextual knowledge necessary to generate one from the other is readily accessible. Even where contextual knowledge is difficult to acquire, there can be no assurance that an authorized recipient of the contextual knowledge is also authorized to receive location information.

In order to protect the privacy of the subject of location-related measurement data, measurement data MUST be protected with the same degree of protection as location information. The confidentiality and authentication provided by TLS MUST be used in order to convey measurement data over HELD [RFC5985]. Other protocols MUST provide comparable guarantees.

6.1. Measurement Data Privacy Model

It is not necessary to distribute measurement data in the same fashion as location information. Measurement data is less useful to location recipients than location information. A simple distribution model is described in this document.

In this simple model, the Device is the only entity that is able to distribute measurement data. To use an analogy from the GEOPRIV architecture, the Device - as the Location Generator, or the Measurement Data Generator - is the sole entity that can act for the role of both Rule Maker and Location Server.

A Device that provides location-related measurement data, MUST only do so as explicitly authorized by a Rule Maker. This depends on having an interface that allows Rule Makers (for instance, users or administrators) to control where and how measurement data is provided.

No entity is permitted to redistribute measurement data. The Device directs other entities in how measurement data is used and retained.

The GEOPRIV model [RFC6280] protects the location of a Target using direction provided by a Rule Maker. For the purposes of measurement data distribution, this model relies on the assumptions made in Section 3 of HELD [RFC5985]. These assumptions effectively declare the Device to be a proxy for both Target and Rule Maker.

6.2. LIS Privacy Requirements

A LIS MUST NOT reveal location-related measurement data to any other entity. A LIS MUST NOT reveal location information based on measurement data to any other entity unless directed to do so by the Device.

By adding measurement data to a request for location information, the Device implicitly grants permission for the LIS to generate the requested location information using the measurement data. Permission to use this data for any other purpose is not implied.

As long as measurement data is only used in serving the request that contains it, rules regarding data retention are not necessary. A LIS MUST discard location-related measurement data after servicing a request, unless the Device grants permission to use that information for other purposes.

6.3. Measurement Data and Location URIs

A LIS MAY use measurement data provided by the Device to serve requests to location URIs, if the Device permits it. A Device permits this by including measurement data in a request that explicitly requests a location URI. By requesting a location URI, the Device grants permission for the LIS to use the measurement data in serving requests to that location URI. The LIS cannot provide location recipients with measurement data, as defined in Section 6.1.

Note:

In HELD, the any type is not an explicit request for a location URI, though a location URI might be provided.

The usefulness of measurement data that is provided in this fashion is limited. The measurement data is only valid at the time that it was acquired by the Device. At the time that a request is made to a location URI, the Device might have moved, rendering the measurement data incorrect.

A Device is able to explicitly limit the time that a LIS retains measurement data by adding an expiry time to the measurement data. A LIS MUST NOT retain location-related measurement data in memory, storage or logs beyond the time indicated in the expires attribute (Section 4.1.2). A LIS MUST NOT retain measurement data if the expires attribute is absent.

6.4. Third-Party-Provided Measurement Data

An authorized third-party request for the location of a Device (see [RFC6155]) can include location-related measurement data. This is possible where the third-party is able to make observations about the Device.

A third-party that provides measurement data MUST be authorized to provide the specific measurement for the identified device. A third-party MUST either be trusted by the LIS for the purposes of providing measurement data of the provided type, or the measurement data MUST be validated (see Section 7.2.1) before being used.

How a third-party authenticates its identity or gains authorization to use measurement data is not covered by this document.

7. Security Considerations

Use of location-related measurement data has privacy considerations that are discussed in Section 6.

7.1. Threat Model

The threat model for location-related measurement data concentrates on the Device providing falsified, stolen or incorrect measurement data.

A Device that provides location-related measurement data might use data to:

• acquire the location of another Device, without authorization;
• extract information about network topology; or
• coerce the LIS into providing falsified location information based on the measurement data.

Location-related measurement data describes the physical environment or network attachment of a Device. A third party adversary in the proximity of the Device might be able to alter the physical environment such that the Device provides measurement data that is controlled by the third party. This might be used to indirectly control the location information that is derived from measurement data.

7.1.1. Acquiring Location Information Without Authorization

Requiring authorization for location requests is an important part of privacy protections of a location protocol. A location configuration protocol usually operates under a restricted policy that allows a requester to obtain their own location. HELD identity extensions [RFC6155] allows other entities to be authorized, conditional on a Rule Maker providing sufficient authorization.

The intent of these protections is to ensure that a location recipient is authorized to acquire location information. Location-related measurement data could be used by an attacker to circumvent such authorization checks if the association between measurement data and Target Device is not validated by a LIS.

A LIS can be coerced into providing location information for a Device that a location recipient is not authorized to receive. A request identifies one Device (implicitly or explicitly), but measurement data is provided for another Device. If the LIS does not check that the measurement data is for the identified Device, it could incorrectly authorize the request.

By using unverified measurement data to generate a response, the LIS provides information about a Device without appropriate authorization.

The feasibility of this attack depends on the availability of information that links a Device with measurement data. In some cases, measurement data that is correlated with a target is readily available. For instance, LLDP measurements [lldp] are broadcast to all nodes on the same network segment. An attacker on that network segment can easily gain measurement data that relates a Device with measurements.

For some types of measurement data, it's necessary for an attacker to know the location of the target in order to determine what measurements to use. This attack is meaningless for types of measurement data that require that the attacker first know the location of the target before measurement data can be acquired or fabricated. GNSS measurements [gnss] share this trait with many wireless location determination methods.

7.1.2. Extracting Network Topology Data

Allowing requests with measurements might be used to collect information about network topology.

Network topology can be considered sensitive information by a network operator for commercial or security reasons. While it is impossible to completely prevent a Device from acquiring some knowledge of network topology if a location service is provided, a network operator might desire to limit how much of this information is made available.

Mapping a network topology does not require that an attacker be able to associate measurement data with a particular Device. If a requester is able to try a number of measurements, it is possible to acquire information about network topology.

It is not even necessary that the measurements are valid; random guesses are sufficient, provided that there is no penalty or cost associated with attempting to use the measurements.

7.1.3. Exposing Network Topology Data

A Device could reveal information about a network to entities outside of that network if it provides location measurement data to a LIS that is outside of that network. With the exception of GNSS measurements, the measurements in this document provide information about an access network that could reveal topology information to an unauthorized recipient.

A Device MUST NOT provide information about network topology without a clear signal that the recipient is authorized. A LIS that is discovered using DHCP as described in LIS discovery [RFC5986] can be considered to be authorized to receive information about the access network.

7.1.4. Lying By Proxy

Location information is a function of its inputs, which includes measurement data. Thus, falsified measurement data can be used to alter the location information that is provided by a LIS.

Some types of measurement data are relatively easy to falsify in a way that causes the resulting location information to be selected with little or no error. For instance, GNSS measurements are easy to use for this purpose because all the contextual information necessary to calculate a position using measurements is broadcast by the satellites [HARPER].

An attacker that falsifies measurement data gains little if they are the only recipients of the result. The attacker knows that the location information is bad. The attacker only gains if the information can somehow be attributed to the LIS by another location recipient. By coercing the LIS into providing falsified location information, any credibility that the LIS might have - that the attacker does not - is gained by the attacker.

A third-party that is reliant on the integrity of the location information might base an evaluation of the credibility of the information on the source of the information. If that third party is able to attribute location information to the LIS, then an attacker might gain.

Location information that is provided to the Device without any means to identify the LIS as its source is not subject to this attack. The Device is identified as the source of the data when it distributes the location information to location recipients.

Location information is attributed to the LIS either through the use of digital signatures or by having the location recipient directly interact with the LIS. A LIS that digitally signs location information becomes identifiable as the source of the data. Similarly, the LIS is identified as a source of data if a location recipient acquires information directly from a LIS using a location URI.

7.1.5. Measurement Replay

The value of some measured properties do not change over time for a single location. For properties of a network, time-invariance is often directly as a result of the practicalities of operating the network. Limiting the changes to a network ensures greater consistency of service. A largely static network also greatly simplifies the data management tasks involved with providing a location service. However, time invariant properties allow for simple replay attacks, where an attacker acquires measurements that can later be used without being detected as being invalid.

Measurement data is frequently an observation of an time-invariant property of the environment at the subject location. For measurements of this nature, nothing in the measurement itself is sufficient proof that the Device is present at the resulting location. Measurement data might have been previously acquired and reused.

For instance, the identity of a radio transmitter, if broadcast by that transmitter, can be collected and stored. An attacker that wishes it known that they exist at a particular location, can claim to observe this transmitter at any time. Nothing inherent in the claim reveals it to be false.

7.1.6. Environment Spoofing

Some types of measurement data can be altered or influenced by a third party so that a Device unwittingly provides falsified data. If it is possible for a third party to alter the measured phenomenon, then any location information that is derived from this data can be indirectly influenced.

Altering the environment in this fashion might not require involvement with either Device or LIS. Measurement that is passive - where the Device observes a signal or other phenomenon without direct interaction - are most susceptible to alteration by third parties.

Measurement of radio signal characteristics is especially vulnerable since an adversary need only be in the general vicinity of the Device and be able to transmit a signal. For instance, a GNSS spoofer is able to produce fake signals that claim to be transmitted by any satellite or set of satellites (see [GPS.SPOOF]).

Measurements that require direct interaction increases the complexity of the attack. For measurements relating to the communication medium, a third party cannot avoid direct interaction, they need only be on the communications path (that is, man in the middle).

Even if the entity that is interacted with is authenticated, this does not provide any assurance about the integrity of measurement data. For instance, the Device might authenticate the identity of a radio transmitter through the use of cryptographic means and obtain signal strength measurements for that transmitter. Radio signal strength is trivial for an attacker to increase simply by receiving and amplifying the raw signal; it is not necessary for the attacker to be able to understand the signal content.

Note:

This particular "attack" is more often completely legitimate. Radio repeaters are commonplace mechanism used to increase radio coverage.

Attacks that rely on altering the observed environment of a Device require countermeasures that affect the measurement process. For radio signals, countermeasures could include the use of authenticated signals, or altered receiver design. In general, countermeasures are highly specific to the individual measurement process. An exhaustive discussion of these issues is left to the relevant literature for each measurement technology.

A Device that provides measurement data is assumed to be responsible for applying appropriate countermeasures against this type of attack.

Where a Device is the sole recipient of location information derived from measurement data, a LIS might choose to provide location information without any validation. The responsibility for ensuring the veracity of the measurement data lies with the Device.

Measurement data that is susceptible to this sort of influence SHOULD be treated as though it were produced by an untrusted Device for those cases where a location recipient might attribute the location information to the LIS. GNSS measurements and radio signal strength measurements can be affected relatively cheaply, though almost all other measurement types can be affected with varying costs to an attacker, with the largest cost often being a requirement for physical access. To the extent that it is feasible, measurement data SHOULD be subjected to the same validation as for other types of attacks that rely on measurement falsification.

Note:

Altered measurement data might be provided by a Device that has no knowledge of the alteration. Thus, an otherwise trusted Device might still be an unreliable source of measurement data.

7.2. Mitigation

The following measures can be applied to limit or prevent attacks. The effectiveness of each depends on the type of measurement data and how that measurement data is acquired.

Two general approaches are identified for dealing with untrusted measurement data: Section 7.2.1, Section 7.2.2, and Section 7.2.3. The impact of attributing location information to sources is discussed in more detail in Section 7.2.4.

1. Require independent validation of measurement data or the location information that is produced.
2. Identify the types of sources that provided the measurement data that location information was derived from.

This section goes into more detail on the different forms of validation in

Any costs in validation are balanced against the degree of integrity desired from the resulting location information.

7.2.1. Measurement Validation

Detecting that measurement data has been falsified is difficult in the absence of integrity mechanisms.

Independent confirmation of the veracity of measurement data ensures that the measurement is accurate and that it applies to the correct Device. When it's possible to gather the same measurement data from a trusted and independent source without undue expense, the LIS can use the trusted data in place of what the untrusted Device has sent. In cases where that is impractical, the untrusted data can provide hints that allow corroboration of the data (see Section 7.2.1.1).

Measurement information might contain no inherent indication that it is falsified. On the contrary, it can be difficult to obtain information that would provide any degree of assurance that the measurement device is physically at any particular location. Measurements that are difficult to verify require other forms of assurance before they can be used.

7.2.1.1. Effectiveness

Measurement validation MUST be used if measurement data for a particular Device can be easily acquired by unauthorized location recipients, as described in Section 7.1.1. This prevents unauthorized access to location information using measurement data.

Validation of measurement data can be significantly more effective than independent acquisition of the same. For instance, a Device in a large Ethernet network could provide a measurement indicating its point of attachment using LLDP measurements. For a LIS, acquiring the same measurement data might require a request to all switches in that network. With the measurement data, validation can target the identified switch with a specific query.

Validation is effective in identifying falsified measurement data [lying], including attacks involving replay of measurement data [replay]. Validation also limits the amount of network topology information [topomap] made available to Devices to that portion of the network topology that they are directly attached.

Measurement validation has no effect if the underlying effect is being spoofed [environment].

7.2.1.2. Limitations (Unique Observer)

A Device is often in a unique position to make a measurement. It alone occupies the point in space-time that the location determination process seeks to determine. The Device becomes a unique observer for a particular property.

The ability of the Device to become a unique observer makes the Device invaluable to the location determination process. As a unique observer, it also makes the claims of a Device difficult to validate and easily to spoof.

As long as no other entity is capable of making the same measurements, there is also no other entity that can independently check that the measurements are correct and applicable to the Device. A LIS might be unable to validate all or part of the measurement data it receives from a unique observer. For instance, a signal strength measurement of the signal from a radio tower cannot be validated directly.

Some portion of the measurement data might still be independently verified, even if all information cannot. In the previous example, the radio tower might be able to provide verification that the Device is present if it is able to observe a radio signal sent by the Device.

If measurement data can only be partially validated, the extent to which it can be validated determines the effectiveness of validation against these attacks.

The advantage of having the Device as a unique observer is that it makes it difficult for an attacker to acquire measurements without the assistance of the Device. Attempts to use measurements to gain unauthorized access to measurement data [unauth] are largely ineffectual against a unique observer.

7.2.2. Location Validation

Location information that is derived from location-related measurement data can also be verified against trusted location information. Rather than validating inputs to the location determination process, suspect locations are identified at the output of the process.

Trusted location information is acquired using sources of measurement data that are trusted. Untrusted location information is acquired using measurement data provided from untrusted sources, which might include the Device. These two locations are compared. If the untrusted location agrees with the trusted location, the untrusted location information is used.

Algorithms for the comparison of location information are not included in this document. However, a simple comparison for agreement might require that the untrusted location be entirely contained within the uncertainty region of the trusted location.

There is little point in using a less accurate, less trusted location. Untrusted location information that has worse accuracy than trusted information can be immediately discarded. There are multiple factors that affect accuracy, uncertainty and currency being the most important. How location information is compared for accuracy is not defined in this document.

7.2.2.1. Effectiveness

Location validation limits the extent to which falsified - or erroneous - measurement data can cause an incorrect location to be reported.

Location validation can be more efficient than validation of inputs, particularly for a unique observer [uniqueobs].

Validating location ensures that the Device is at or near the resulting location. Location validation can be used to limit or prevent all of the attacks identified in this document.

7.2.2.2. Limitations

The trusted location that is used for validation is always less accurate than the location that is being checked. The amount by which the untrusted location is more accurate, is the same amount that an attacker can exploit.

For example, a trusted location might indicate a five kilometer radius uncertainty region. An untrusted location that describes a 100 meter uncertainty within the larger region might be accepted as more accurate. An attacker might still falsify measurement data to select any location within the larger uncertainty region. While the 100 meter uncertainty that is reported seems more accurate, a falsified location could be anywhere in the five kilometer region.

Where measurement data might have been falsified, the actual uncertainty is effectively much higher. Local policy might allow differing degrees of trust to location information derived from untrusted measurement data. This might be a boolean operation with only two possible outcomes: untrusted location information might be used entirely or not at all. Alternatively, untrusted location could be combined with trusted location information using different weightings, based on a value set in local policy.

7.2.3. Supporting Observations

Replay attacks using previously acquired measurement data are particularly hard to detect without independent validation. Rather than validate the measurement data directly, supplementary data might be used to validate measurements or the location information derived from those measurements.

These supporting observations could be used to convey information that provides additional assurance that the Device was acquired at a specific time and place. In effect, the Device is requested to provide proof of its presence at the resulting location.

For instance, a Device that measures attributes of a radio signal could also be asked to provide a sample of the measured radio signal. If the LIS is able to observe the same signal, the two observations could be compared. Providing that the signal cannot be predicted in advance by the Device, this could be used to support the claim that the Device is able to receive the signal. Thus, the Device is likely to be within the range that the signal is transmitted. A LIS could use this to attribute a higher level of trust in the associated measurement data or resulting location.

7.2.3.1. Effectiveness

The use of supporting observations is limited by the ability of the LIS to acquire and validate these observations. The advantage of selecting observations independent of measurement data is that observations can be selected based on how readily available the data is for both LIS and Device. The amount and quality of the data can be selected based on the degree of assurance that is desired.

Use of supporting observations is similar to both measurement validation and location validation. All three methods rely on independent validation of one or more properties. Applicability of each method is similar.

Use of supporting observations can be used to limit or prevent all of the attacks identified in this document.

7.2.3.2. Limitations

The effectiveness of the validation method depends on the quality of the supporting observation: how hard it is to obtain at a different time or place, how difficult it is to guess, and what other costs might be involved in acquiring this data.

In the example of an observed radio signal, requesting a sample of the signal only provides an assurance that the Device is able to receive the signal transmitted by the measured radio transmitter. This only provides some assurance that the Device is within range of the transmitter.

As with location validation, a Device might still be able to provide falsified measurements that could alter the value of the location information as long as the result is within this region.

Requesting additional supporting observations can reduce the size of the region over which location information can be altered by an attacker, or increase trust in the result, but each additional measurement imposes an acquisition cost. Supporting observations contribute little or nothing toward the primary goal of determining the location of the Device.

7.2.4. Attribution

Lying by proxy [lying] relies on the location recipient being able to attribute location information to a LIS. The effectiveness of this attack is negated if location information is explicitly attributed to a particular source.

This requires an extension to the location object that explicitly identifies the source (or sources) of each item of location information.

Rather than relying on a process that seeks to ensure that location information is accurate, this approach instead provides a location recipient with the information necessary to reach their own conclusion about the trustworthiness of the location information.

Including an authenticated identity for all sources of measurement data presents a number of technical and operational challenges. It is possible that the LIS has a transient relationship with a Device. A Device is not expected to share authentication information with a LIS. There is no assurance that Device identification is usable by a potential location recipient. Privacy concerns might also prevent the sharing identification information, even if it were available and usable.

Identifying the type of measurement source allows a location recipient to make a decision about the trustworthiness of location information without depending on having authenticated identity information for each source. An element for this purpose is defined in Section 4.4.

When including location information that is based on measurement data from sources that might be untrusted, a LIS SHOULD include alternative location information that is derived from trusted sources of measurement data. Each item of location information can then be labelled with the source of that data.

A location recipient that is able to identify a specific source of measurement data (whether it be LIS or Device) can use this information to attribute location information to either or both entity. The location recipient is then better able to make decisions about trustworthiness based on the source of the data.

A location recipient that does not understand the source element is unable to make this distinction. When constructing a PIDF-LO document, trusted location information MUST be placed in the PIDF-LO so that it is given higher priority to any untrusted location information according to Rule #8 of [RFC5491].

Attribution of information does nothing to address attacks that alter the observed parameters that are used in location determination [environment].

7.2.5. Stateful Correlation of Location Requests

Stateful examination of requests can be used to prevent a Device from attempting to map network topology using requests for location information (Section 7.1.2).

Simply limiting the rate of requests from a single Device reduces the amount of data that a Device can acquire about network topology. A LIS could also make observations about the movements of a Device. A Device that is attempting to gather topology information is likely to be assigned a location that changes significantly between subsequent requests, possibly violating physical laws (or lower limits that might still be unlikely) with respect to speed and acceleration.

7.3. An Unauthorized or Compromised LIS

A compromised LIS, or a compromise in LIS discovery [RFC5986] could lead to an unathorized entity obtaining measurement data. This information could then be used or redistributed. A Device MUST ensure that it authenticate a LIS, as described in Section 9 of [RFC5985].

An entity that is able to acquire measurement data can, in addition to using those measurements to learn the location of a Device, also use that information for other purposes. This information can be used to provide insight into network topology [topomap].

Measurement data might also be exploited in other ways. For example, revealing the type of 802.11 transceiver that a Device uses could allow an attacker to use specific vulnerabilities to attack a Device. Similarly, revealing information about network elements could enable targeted attacks on that infrastructure.

8. Measurement Schemas

The schema are broken up into their respective functions. There is a base container schema into which all measurements are placed, plus definitions for a measurement request (Section 8.1). A PIDF-LO extension is defined in a separate schema (Section 8.2). 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 (Section 8.3). Then each of the specific measurement types is defined in its own schema.

8.1. Measurement Container Schema

<?xml version="1.0"?>
<xs:schema
    xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
    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"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">

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

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

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

  <xs:element name="measurementRequest"
	      type="lm:measurementRequestType"/>
  <xs:complexType name="measurementRequestType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
	<xs:sequence>
	  <xs:element ref="lm:measurement"
		      minOccurs="0" maxOccurs="unbounded"/>
	  <xs:any namespace="##other" processContents="lax"
		  minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="measurement" type="lm:measurementType"/>
  <xs:complexType name="measurementType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
	<xs:sequence>
	  <xs:any namespace="##other" processContents="lax"
		  minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="type" type="xs:QName" use="required"/>
	<xs:attribute name="samples" type="xs:positiveInteger"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <!-- PIDF-LO extension for source -->
  <xs:element name="source" type="lm:sourceType"/>
  <xs:simpleType name="sourceType">
    <xs:list>
      <xs:simpleType>
	<xs:restriction base="xs:token">
	  <xs:enumeration value="lis"/>
	  <xs:enumeration value="device"/>
	  <xs:enumeration value="other"/>
	</xs:restriction>
      </xs:simpleType>
    </xs:list>
  </xs:simpleType>
</xs:schema>

Measurement Container Schema

8.2. Measurement Source Schema

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

  <xs:annotation>
    <xs:appinfo
	source="urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc">
    </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 an extension to PIDF-LO that indicates the
      type of source that produced the measurement data used in
      generating the associated location information.
    </xs:documentation>
  </xs:annotation>

  <xs:element name="source" type="lmsrc:sourceType"/>
  <xs:simpleType name="sourceType">
    <xs:list>
      <xs:simpleType>
	<xs:restriction base="xs:token">
	  <xs:enumeration value="lis"/>
	  <xs:enumeration value="device"/>
	  <xs:enumeration value="other"/>
	</xs:restriction>
      </xs:simpleType>
    </xs:list>
  </xs:simpleType>
</xs:schema>

Measurement Source PIDF-LO Extension Schema

8.3. Base Type Schema

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

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

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

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

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

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

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

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

  <!-- MAC address (EUI-48) or EUI-64 address -->
  <xs:simpleType name="macAddressType">
    <xs:restriction base="xs:token">
      <xs:pattern
  value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

Base Type Schema

8.4. LLDP Measurement Schema

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

  <xs:annotation>
    <xs:appinfo
	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

8.5. 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">
	<xs:attribute name="enterprise" type="xs:positiveInteger"
		      use="optional"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

</xs:schema>

DHCP measurement schema

8.6. WiFi Measurement Schema

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

  <xs:annotation>
    <xs:appinfo
	source="urn:ietf:params:xml:schema:geopriv:lm:wifi">
      802.11 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 802.11 location measurements.
    </xs:documentation>
  </xs:annotation>

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

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

  <xs:complexType name="wifiNetworkType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
	<xs:sequence>
	  <xs:element name="nicType" type="xs:token"
		      minOccurs="0"/>
	  <xs:element name="ap" type="wifi:wifiType"
		      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="bssid" type="wifi:bssidType"/>
	  <xs:element name="ssid" type="wifi:ssidType"
		      minOccurs="0"/>
	  <xs:element name="channel" type="xs:nonNegativeInteger"
		      minOccurs="0"/>
	  <xs:element name="location" minOccurs="0"
		      type="xs:anyType"/>
	  <xs:element name="type" type="wifi:networkType"
		      minOccurs="0"/>
	  <xs:element name="regclass" type="wifi:regclassType"
		      minOccurs="0"/>
	  <xs:element name="antenna" type="wifi:octetType"
		      minOccurs="0"/>
	  <xs:element name="flightTime" minOccurs="0"
		      type="bt:nnDoubleWithRMSError"/>
	  <xs:element name="apSignal" type="wifi:signalType"
		      minOccurs="0"/>
	  <xs:element name="deviceSignal" type="wifi:signalType"
		      minOccurs="0"/>
	  <xs:any namespace="##other" processContents="lax"
		  minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="serving" type="xs:boolean"
		      default="false"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="bssidType">
    <xs:simpleContent>
      <xs:extension base="bt:macAddressType">
	<xs:attribute name="verified" type="xs:boolean"
		      default="false"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <!-- Note that this pattern does not prevent multibyte UTF-8
       sequences that result in a SSID longer than 32 octets. -->
  <xs:simpleType name="ssidType">
    <xs:restriction base="xs:token">
      <xs:pattern value="(\\[\da-fA-F]{2}|[^\\]){0,32}"/>
    </xs:restriction>
  </xs:simpleType>

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

  <xs:complexType name="regclassType">
    <xs:simpleContent>
      <xs:extension base="wifi:octetType">
	<xs:attribute name="country">
	  <xs:simpleType>
	    <xs:restriction base="xs:token">
	      <xs:pattern value="[A-Z]{2}[OIX]?"/>
	    </xs:restriction>
	  </xs:simpleType>
	</xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:simpleType name="octetType">
    <xs:restriction base="xs:nonNegativeInteger">
      <xs:maxInclusive value="255"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="signalType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
	<xs:sequence>
	  <xs:element name="transmit" type="xs:double"
		      minOccurs="0"/>
	  <xs:element name="gain" type="xs:double" minOccurs="0"/>
	  <xs:element name="rcpi" type="wifi:rssiType"
		      minOccurs="0"/>
	  <xs:element name="rsni" type="bt:doubleWithRMSError"
		      minOccurs="0"/>
	  <xs:any namespace="##other" processContents="lax"
		  minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

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

  <!-- Measurement Request elements -->
  <xs:element name="type" type="wifi:networkType"/>
  <xs:element name="parameter" type="wifi:parameterType"/>

  <xs:complexType name="parameterType">
    <xs:simpleContent>
      <xs:extension base="xs:QName">
	<xs:attribute name="context" use="optional">
	  <xs:simpleType>
	    <xs:restriction base="xs:token">
	      <xs:enumeration value="ap"/>
	      <xs:enumeration value="device"/>
	    </xs:restriction>
	  </xs:simpleType>
	</xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

</xs:schema>

WiFi measurement schema

8.7. Cellular Measurement Schema

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

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

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

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

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

  <xs:simpleType name="mccType">
    <xs:restriction base="xs:token">
      <xs:pattern value="[0-9]{3}"/>
    </xs:restriction>
  </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="268435455"/> <!-- 2^28 (eucid) -->
    </xs:restriction>
  </xs:simpleType>

  <!-- Measurement Request elements -->

  <xs:element name="type" type="cell:typeType"/>
  <xs:simpleType name="typeType">
    <xs:restriction base="xs:token">
      <xs:enumeration value="gsm"/>
      <xs:enumeration value="umts"/>
      <xs:enumeration value="lte"/>
      <xs:enumeration value="cdma"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:element name="network" type="cell:networkType"/>
  <xs:complexType name="networkType">
    <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:sequence>
	  <xs:element name="nid" type="cell:cellIdType"/>
	</xs:choice>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>

Cellular measurement schema

8.8. GNSS Measurement Schema

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

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

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

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

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

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

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

GNSS measurement Schema

8.9. DSL Measurement Schema

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

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

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

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

</xs:schema>

DSL measurement schema

9. IANA Considerations

This section creates a registry for GNSS types [gnss] and registers the namespaces and schema defined in Section 8.

9.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 [RFC5226], this registry operates under "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 of the GNSS

Brief description:

a brief description of the GNSS

GNSS token:

a token that can be used to identify the GNSS

Signals:

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

Documentation reference:

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

The registry initially includes two registrations:

GNSS name:

Global Positioning System (GPS)

Brief description:

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

GNSS token:

gps

Signals:

L1, L2, L1C, L2C, L5

Documentation reference:

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

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]

9.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc

      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 Source for PIDF-LO</title>
	  </head>
	  <body>
	    <h1>Namespace for Location Measurement Source</h1>
	    <h2>urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc</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
      

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

• URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
• Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
• XML:

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

      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
      

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@commscope.com).
• XML:

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

      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
      

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@commscope.com).
• XML:

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

      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
      

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@commscope.com).
• XML:

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

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

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@commscope.com).
• XML:

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

      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
      

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@commscope.com).
• XML:

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

      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
      

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@commscope.com).
• XML:

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

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

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@commscope.com).
• XML:

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

      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
      

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@commscope.com).
• XML:

9.11. XML Schema Registration for Measurement Source Schema

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

URI:

urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).

Schema:

The XML for this schema can be found in Section 8.2 of this document.

9.12. 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@commscope.com).

Schema:

The XML for this schema can be found in Section 8.1 of this document.

9.13. 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@commscope.com).

Schema:

The XML for this schema can be found in Section 8.3 of this document.

9.14. 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@commscope.com).

Schema:

The XML for this schema can be found in Section 8.4 of this document.

9.15. 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@commscope.com).

Schema:

The XML for this schema can be found in Section 8.5 of this document.

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

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).

Schema:

The XML for this schema can be found in Section 8.6 of this document.

9.17. 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@commscope.com).

Schema:

The XML for this schema can be found in Section 8.7 of this document.

9.18. 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@commscope.com).

Schema:

The XML for this schema can be found in Section 8.8 of this document.

9.19. 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@commscope.com).

Schema:

The XML for this schema can be found in Section 8.9 of this document.

10. Acknowledgements

Thanks go to Simon Cox for his comments relating to terminology that have helped ensure that this document is aligned with ongoing work in the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his review and comments on the GNSS sections of this document. Thanks to Noor-E-Gagan Singh, Gabor Bajko, Russell Priebe, and Khalid Al-Mufti for their significant input to and suggestions for improving the 802.11 measurements. Thanks to Cullen Jennings for feedback and suggestions. Bernard Aboba provided review and feedback on a range of measurement data definitions. Mary Barnes and Geoff Thompson provided a review and corrections. David Waitzman and John Bressler both noted shortcomings with 802.11 measurements. Keith Drage, Darren Pawson provided expert LTE knowledge.

11. References

11.1. Normative References

, ", "

[ASCII]	US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.", .
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046]	Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3315]	Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3629]	Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3986]	Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[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.
[RFC4119]	Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4291]	Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4580]	Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June 2006.
[RFC4649]	Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
[RFC5491]	Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5952]	Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5985]	Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5986]	Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[TS.3GPP.23.003]	3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 9.4.0, September 2010.
[TIA-2000.5]	TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for cdma2000(R) Spread Spectrum Systems", TIA-2000.5-D, March 2004.
[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.
[IANA.enterprise]	IANA, "Private Enterprise Numbers", 2011.
[IEEE.8021AB]	IEEE, "IEEE Standard for Local and Metropolitan area networks, Station and Media Access Control Connectivity Discovery", IEEE Std 802.1AB-2009, September 2009.
[IEEE.80211]	IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Std 802.11-2012, March 2012.

11.2. Informative References

[RFC2661]	Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2865]	Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[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.
[RFC5226]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC6155]	Winterbottom, J., Thomson, M., Tschofenig, H. and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, March 2011.
[RFC6280]	Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H. and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[ANSI-TIA-1057]	ANSI/TIA, "Link Layer Discovery Protocol for Media Endpoint Devices", TIA 1057, April 2006.
[GPS.SPOOF]	Scott, L., "Anti-Spoofing and Authenticated Signal Architectures for Civil Navigation Signals", ION-GNSS Portland, Oregon, 2003.
[HARPER]	Harper, N., Dawson, M. and D. Evans, "Server-side spoofing and detection for Assisted-GPS", Proceedings of International Global Navigation Satellite Systems Society (IGNSS) Symposium 2009 16, December 2009.
[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.

Authors' Addresses