Location Measurements for IEEE 802.16e Devices

Abstract

IEEE 802.16e defines means for true mobility within an 802.16 wireless network. Determining an accurate location for 802.16e devices requires information on radio parameters. A format is defined for location-related measurement data that can be provided by an 802.16e device. This measurement data can be used by a Location Information Server (LIS) to more accurately determine the location of the device. A separate measurement used for identifying WiMAX session-related parameters is also provided.

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on September 12, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions used in this document
• 3. 802.16e Radio Measurement Data
• 3.1. Measurement Request Parameters
• 4. WiMAX Session-Related Measurements
• 5. 802.16e Measurement Schema
• 6. Security Considerations
• 7. IANA Considerations
• 7.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:lm:802.16e
• 7.2. XML Schema Registration for 802.16e Measurement Schema
• 8. References
• Authors' Addresses

1. Introduction

Determining the location of a device in an IEEE 802.16e [IEEE.80216E] mobile wireless network requires information from the device to improve the accuracy of the final result. Radio timing information provided by the device can enable the calculation of a more accurate location estimate by a Location Information Server (LIS).

This document describes a standard format for 802.16e measurement data that is based on radio measurements made of base stations near the device.

2. Conventions used in this document

This document builds on [I-D.ietf-geopriv-held-measurements] and consequently uses the same set of terminology. Terminology from [IEEE.80216E] is used where appropriate.

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

3. 802.16e Radio Measurement Data

A subscriber station (SS) in an 802.16e network is able to observe radio signals from each base station (BS) in its proximity. By observing the timing and strength of these signals, a SS is able to provide a LIS with information that can be used to determine its location.

The most basic 802.16e measurement indicates the serving BS, as shown in Figure 1.

  <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
    <locationType exact="true">civic</locationType>
    <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm">
      <w16e xmlns="urn:ietf:params:xml:ns:geopriv:lm:802.16e">
	<servingBS id="00-21-43-65-87-a9"/>
      </w16e>
    </measurements>
  </locationRequest>

More measurement information can be provided, including timing measurement information for additional serving base stations (if fast base station switching (FBSS) or macro-diversity hand-over (MDHO) are in progress). Information on neighbouring base stations can be provided in addition to that for the serving BS.

     (V) _
      |   `- _ t[1]
      |       `- _       t[2]
      | BS1       ` . - - - - - - - - - - (V)
		   _|`.                    |
		  |U|  `. t[3]             |
		  |_|    `.            BS2 |
	      Target SS    `.
			     (V)
			      |
			      |
			      | BS3

The set of measurement data is chosen by the SS and the presence of specific elements will depend on the time the SS has available to acquire the measurements. The following measurement information may be provided:

id:

(Attribute) The base station identifier for the measured BS. Note that while this isn't a MAC address, it shares the encoding defined for the MAC address.

rssi:

Receive signal strength indicator, calculated as defined in [IEEE.80216E]. This value is measured in units of dBm. This datum optionally includes an RMS error in dB and sample count.

cinr:

Carrier inteference to noise ratio (signal to noise), calculated as defined in [IEEE.80216E]. This value is measured in units of dB. This datum optionally includes an RMS error and sample count.

rd:

Relative delay of the signal from the BS, measured relative to other base stations. Since this value is relative, it MUST be included on at least two BS measurements to be of any use. It is RECOMMENDED that this value be set to 0 for the first BS in the measured set. This datum optionally includes an RMS error and sample count. Figure 2, relative delay can be calculated based on the relative time that signals transmitted simultaneously (or with known relative times) by base stations can be calculated. If the time of receipt of the signal from each base station is t[x] and the relative delay for BS1 is set to zero, the relative time for each subsequent measured base station is t[x] - t[1].

rtd:

Round trip delay of the signal from the SS to the BS and back. This measurement datum is only applicable for each serving BS. This value is measured in seconds. This datum optionally includes an RMS error and sample count.

The rmsError attribute for signal to noise and received signal strength MAY be calculated using the continuous weighted average method described in [IEEE.80216E]. Values of alpha_AVG and k are selected by the SS.

The XML format described in this document provides a greater range of values than the Scanning Results Report (MOB_SCN-REP) or the Channel measurement Report Response (REP-RSP) message. This allows for the reporting of measurements in a manner less constrained by encoding. A greater range of values does not necessarily imply anything about the uncertainty in those measurements; the RMS error is used to indicate the magnitude of any error.

3.1. Measurement Request Parameters

A request that does not contain sufficient measurement data can result in an error response. [I-D.ietf-geopriv-held-measurements] defines a measurement request that indicates what parameters might be necessary to complete the request. These parameters might also be present in a response that includes an indication that the requested location quality [I-D.thomson-geopriv-location-quality] was not provided.

The elements present in a radio measurement are all optional. In order for a Device to know which of these is requested, the parameter element is defined for radio measurement data. This identifies each requested element using a qualified name.

The following example shows a HELD error response that indicates that RSSI and CINR measurement would aid in fulfilling the request.

  <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
	 code="locationUnknown">
    <message xml:lang="en">Insufficient measurement data</message>
    <measurementRequest
	xmlns="urn:ietf:params:xml:ns:geopriv:lm"
	xmlns:w16e="urn:ietf:params:xml:ns:geopriv:lm:802.16e">
      <measurement type="w16e:w16e">
	<w16e:parameter>w16e:rssi</wifi:parameter>
	<w16e:parameter>w16e:cinr</wifi:parameter>
      </measurement>
    </measurementRequest>
  </error>

4. WiMAX Session-Related Measurements

In Worldwide Interoperability for Microwave Access (WiMAX) networks [WiMAX.LBS], an SS might have a particular access network designated as a "home network". In some configurations the network is designed in such a way that the SS only has access to a location server in the home network, known as a home location server, or hLS. However, a server in the current (visited) access network - the vLS - could be the only server that is capable of communicating with the access network to determine the location of the SS. In this case the hLS provides WiMAX session information to the vLS, giving the vLS the information necessary to identify a session and generate location information.

Figure 4 shows an example measurement that contains information regarding a session. This contains the session identifier that is assigned by the anchor authenticator. The Network Access Identifier (NAI) [RFC4282] of the device and the address of the anchor authenticator is included.

  <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm">
    <wimaxSession xmlns="urn:ietf:params:xml:ns:geopriv:lm:802.16e">
      <sessionID>19abd9e9f923978f80310d</sessionID>
      <nai>user.206417@example.realm</nai>
      <anchor ip="2001:DB8::f:301">f-301.aa.example.com</anchor>
    </wimaxSession>
  </measurements>

Session parameters are used to identify a particular network attachment session:

sessionID:

A temporary identifier given to a particular session. This value is a binary value that is expressed in hexadecimal.

nai:

The NAI [RFC4282] used by the device to gain network authorization.

anchor:

The domain name of the anchor authenticator in the visited network. Optionally, this includes an attribute that indicates an IP address in addition to the domain name.

The formal grammar for NAI [RFC4282] permits invalid UTF-8, which cannot be expressed using XML. Therefore, this lexical representation of NAI permits escaping. Non-unicode characters (and any other character) are expressed using a backslash ('\') followed by two hexadecimal digits representing the value of a single octet.

The value-space representation of an NAI is the sequence of octets that is produced from the concatenation of UTF-8 encoded sequences of unescaped characters and octets derived from escaped components. This sequence MUST conform to the constraints in [RFC4282].

5. 802.16e Measurement Schema

Note:

The pattern for NAI has extra whitespace added to conform to formatting restrictions. The actual value does not contain whitespace.

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

  <xs:annotation>
    <xs:documentation source="https://www.ietf.org/rfc/rfcXXXX.txt">
      <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
	   published RFC and remove this note.]] -->
      This document defines a location-related measurement format
      for 802.16e mobile wireless devices.
    </xs:documentation>
  </xs:annotation>

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

  <xs:element name="w16e" type="w16e:w16eType"/>
  <xs:complexType name="w16eType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
	<xs:sequence>
	  <xs:choice>
	    <xs:element ref="w16e:servingBS" maxOccurs="unbounded"/>
	    <xs:element ref="w16e:neighbourBS"/>
	  </xs:choice>
	  <xs:element ref="w16e:neighbourBS"
		      minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="neighbourBS" type="w16e:bsType"/>

  <xs:complexType name="bsType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
	<xs:sequence>
	  <xs:element name="rssi" type="bt:doubleWithRMSError"
		      minOccurs="0"/>
	  <xs:element name="cinr" type="bt:doubleWithRMSError"
		      minOccurs="0"/>
	  <xs:element name="rd" type="bt:doubleWithRMSError"
		      minOccurs="0"/>
	  <xs:any namespace="##other" processContents="lax"
		  minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="id" type="bt:macAddressType"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="servingBS" type="w16e:servingBsType"/>

  <xs:complexType name="servingBsType">
    <xs:complexContent>
      <xs:extension base="w16e:bsType">
	<xs:sequence>
	  <xs:element name="rtd" type="bt:nnDoubleWithRMSError"
		      minOccurs="0"/>
	</xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="wimaxSession" type="w16e:wimaxSessionType"/>

  <xs:complexType name="wimaxSessionType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
	<xs:sequence>
	  <xs:element name="sessionID" type="xs:hexBinary"/>
	  <xs:element name="nai" type="w16e:naiType"/>
	  <xs:element name="anchor" type="w16e:anchorType"/>
	  <xs:any namespace="##other" processContents="lax"
		  minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="anchorType">
    <xs:simpleContent>
      <xs:extension base="w16e:domainType">
	<xs:attribute name="ip" type="bt:ipAddressType"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:simpleType name="domainType">
    <xs:restriction base="xs:token">
      <xs:pattern
	  value="([a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?\.?)+"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="naiType">
    <xs:restriction base="xs:token">
      <xs:pattern
	  value="([^\\]|\\[\dA-Fa-f]{2})*
		 (@([A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*\.)+
		  [A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*)?"/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

6. Security Considerations

The considerations of [I-D.ietf-geopriv-held-measurements] apply. The receiver of 802.16e measurement information requires knowledge of the location of base stations to make effective use of the information.

NAI is used as identification information for a device. The connection of this information with other session parameters provides a potential link between identity and location. In addition, unless care is taken to verify this information, this datum could be exploited by an attacker to gain access to another user's location information. See the privacy and security considerations of [I-D.ietf-geopriv-held-identity-extensions] for details on using identity parameters.

7. IANA Considerations

7.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:lm:802.16e

      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>802.16e Measurements</title>
	  </head>
	  <body>
	    <h1>Namespace for 802.16e Measurements</h1>
	    <h2>urn:ietf:params:xml:ns:held:lm:802.16e</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:held:lm:802.16e, following the guidelines in [RFC3688].

• URI: urn:ietf:params:xml:ns:held:lm
• Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
• XML:

7.2. XML Schema Registration for 802.16e Measurement Schema

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

URI:

urn:ietf:params:xml:schema:held:lm:802.16e

Registrant Contact:

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

Schema:

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

8. References

Authors' Addresses