Location Measurements for IEEE 802.16e Devices
draft-thomson-geopriv-wimax-measurements-02

Status of this Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on December 18, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

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.

Table of Contents

1.  Introduction
2.  Conventions used in this document
3.  802.16e Radio Measurement Data
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.  Normative References
§  Authors' Addresses

1.  Introduction

Determining the location of a device in an IEEE 802.16e [IEEE.80216E] (IEEE, “Air Interface for Fixed and Mobile Broadband Wireless Access Systems; Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands,” February 2006.) 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.thomson‑geopriv‑held‑measurements] (Thomson, M. and J. Winterbottom, “Using Device-provided Location-Related Measurements in Location Configuration Protocols,” October 2009.) and consequently uses the same set of terminology. Terminology from [IEEE.80216E] (IEEE, “Air Interface for Fixed and Mobile Broadband Wireless Access Systems; Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands,” February 2006.) 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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 (HELD Location Request with 802.16e Measurement Data).

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

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] (IEEE, “Air Interface for Fixed and Mobile Broadband Wireless Access Systems; Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands,” February 2006.). 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] (IEEE, “Air Interface for Fixed and Mobile Broadband Wireless Access Systems; Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands,” February 2006.). 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.

---

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

Figure 2: Relative Delay Example

---

Based on the example in Figure 2 (Relative Delay Example), 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] (IEEE, “Air Interface for Fixed and Mobile Broadband Wireless Access Systems; Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands,” February 2006.). 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.

4.  WiMAX Session-Related Measurements

In Worldwide Interoperability for Microwave Access (WiMAX) networks [WiMAX.LBS] (WiMAX Forum, “WiMAX Network Protocols and Architecture for Location Based Services,” November 2008.), 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 3 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) (Aboba, B., Beadles, M., Arkko, J., and P. Eronen, “The Network Access Identifier,” December 2005.) [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.

nai:

The NAI (Aboba, B., Beadles, M., Arkko, J., and P. Eronen, “The Network Access Identifier,” December 2005.) [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.

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="((((([-0-9a-zA-Z!#$%&amp;'*+/=?^_`{|}~]
                      |\P{IsBasicLatin}|\\.)+\.)*
                     ([-0-9a-zA-Z!#$%&amp;'*+/=?^_`{|}~]
                      |\P{IsBasicLatin}|\\.)+)
                   (\@([0-9a-zA-Z]([-0-9a-zA-Z]*[0-9a-zA-Z])?\.)*
                    ([0-9a-zA-Z]([-0-9a-zA-Z]*[0-9a-zA-Z])?))?)
                  |(\@([0-9a-zA-Z]([-0-9a-zA-Z]*[0-9a-zA-Z])?\.)*
                    ([0-9a-zA-Z]([-0-9a-zA-Z]*[0-9a-zA-Z])?)))"/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

6.  Security Considerations

The considerations of [I‑D.thomson‑geopriv‑held‑measurements] (Thomson, M. and J. Winterbottom, “Using Device-provided Location-Related Measurements in Location Configuration Protocols,” October 2009.) apply. However, 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.winterbottom‑geopriv‑held‑identity‑extensions] (Thomson, M., Tschofenig, H., Barnes, R., and J. Winterbottom, “Use of Target Identity in HTTP-Enabled Location Delivery (HELD),” August 2009.) 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

This section registers a new XML namespace, urn:ietf:params:xml:ns:held:lm:802.16e, following the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

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

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

XML:

      BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>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

7.2.  XML Schema Registration for 802.16e Measurement Schema

This section registers an XML schema following the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

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 (802.16e Measurement Schema) of this document.

8. Normative References

Authors' Addresses