TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 23, 2008.
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.
1.
Introduction
2.
Conventions used in this document
3.
802.16e Measurement Data
4.
802.16e Measurement Schema
5.
Security Considerations
6.
IANA Considerations
6.1.
URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:lm:802.16e
6.2.
XML Schema Registration for 802.16e Measurement Schema
7.
Normative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
TOC |
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.
TOC |
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.).
TOC |
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>
Figure 1: HELD Location Request with 802.16e Measurement Data |
More measurement information can be provided, including timing measurement information for additional serving base stations (if fast base station switching or macro-diversity hand-over are in progress). Information on neighbouring base stations can be provided in addition to that for the serving BS, or instead of if the SS is not currently attached to the 802.16e interface.
The set measurement data that is included is chosen by the SS and will depend on the time it has available to acquire the measurements. The following measurement information may be provided:
- id:
- (Attribute) The base station identifier for the serving or neighbour BS. Note that while this isn't a MAC address, it shares the encoding defined for the MAC address.
- rssi:
- The 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:
- The signal to noise ratio, 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 value is measured in seconds, but measurement uncertainty for a single sample is expected to be approximately one sample. 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, but measurement uncertainty for a single sample is expected to be approximately one sample. 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.
TOC |
<?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: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:schema>
TOC |
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.
TOC |
TOC |
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
TOC |
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 4 (802.16e Measurement Schema) of this document.
TOC |
[RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
[RFC3688] | Mealling, M., “The IETF XML Registry,” BCP 81, RFC 3688, January 2004 (TXT). |
[I-D.thomson-geopriv-held-measurements] | Thomson, M. and J. Winterbottom, “Using Device-provided Location-Related Measurements in Location Configuration Protocols,” draft-thomson-geopriv-held-measurements-05 (work in progress), October 2009 (TXT). |
[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,” Std 802.16E, February 2006. |
TOC |
Martin Thomson | |
Andrew | |
PO Box U40 | |
Wollongong University Campus, NSW 2500 | |
AU | |
Phone: | +61 2 4221 2915 |
Email: | martin.thomson@andrew.com |
URI: | http://www.andrew.com/ |
James Winterbottom | |
Andrew | |
PO Box U40 | |
Wollongong University Campus, NSW 2500 | |
AU | |
Phone: | +61 2 4221 2938 |
Email: | james.winterbottom@andrew.com |
URI: | http://www.andrew.com/ |
TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.