[要約] RFC 7105は、デバイスが提供する位置関連の測定値を使用するためのプロトコルに関するものです。このRFCの目的は、位置情報の設定プロトコルにおいて、デバイスが提供する測定値を活用する方法を提案することです。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 7105 Mozilla
Category: Standards Track J. Winterbottom
ISSN: 2070-1721 Unaffiliated
January 2014
Using Device-Provided Location-Related Measurements in Location Configuration Protocols
ロケーション構成プロトコルでのデバイス提供のロケーション関連測定の使用
Abstract
概要
This document describes a protocol for a Device to provide location-related measurement data to a Location Information Server (LIS) within a request for location information. Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment. A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.
このドキュメントでは、デバイスが位置情報の要求内で位置情報サーバー（LIS）に位置関連の測定データを提供するためのプロトコルについて説明します。ロケーション関連の測定情報は、デバイスの位置に関連するプロパティに関する観測を提供します。この情報は、ネットワーク接続または物理環境に関するデータである可能性があります。 LISは位置関連の測定データを使用して、デバイスに提供する位置推定の精度を向上させることができます。ネットワーク接続の一般的なモードや、支援されたグローバルナビゲーション衛星システム（GNSS）パラメーターなど、位置関連の測定の基本セットが定義されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7105.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7105で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
3. Location-Related Measurements in LCPs ...........................6
4. Location-Related Measurement Data Types .........................7
4.1. Measurement Container ......................................7
4.1.1. Time of Measurement .................................8
4.1.2. Expiry Time on Location-Related Measurement Data ....8
4.2. RMS Error and Number of Samples ............................9
4.2.1. Time RMS Error ......................................9
4.3. Measurement Request .......................................10
4.4. Identifying Location Provenance ...........................11
5. Location-Related Measurement Data Types ........................13
5.1. LLDP Measurements .........................................13
5.2. DHCP Relay Agent Information Measurements .................14
5.3. 802.11 WLAN Measurements ..................................15
5.3.1. WiFi Measurement Requests ..........................18
5.4. Cellular Measurements .....................................18
5.4.1. Cellular Measurement Requests ......................22
5.5. GNSS Measurements .........................................22
5.5.1. GNSS: System Type and Signal .......................23
5.5.2. Time ...............................................24
5.5.3. Per-Satellite Measurement Data .....................24
5.5.4. GNSS Measurement Requests ..........................25
5.6. DSL Measurements ..........................................25
5.6.1. L2TP Measurements ..................................26
5.6.2. RADIUS Measurements ................................26
5.6.3. Ethernet VLAN Tag Measurements .....................27
5.6.4. ATM Virtual Circuit Measurements ...................28
6. Privacy Considerations .........................................28
6.1. Measurement Data Privacy Model ............................28
6.2. LIS Privacy Requirements ..................................29
6.3. Measurement Data and Location URIs ........................29
6.4. Measurement Data Provided by a Third Party ................30
7. Security Considerations ........................................30
7.1. Threat Model ..............................................30
7.1.1. Acquiring Location Information without
Authorization ......................................31
7.1.2. Extracting Network Topology Data ...................32
7.1.3. Exposing Network Topology Data .....................32
7.1.4. Lying by Proxy .....................................33
7.1.5. Measurement Replay .................................33
7.1.6. Environment Spoofing ...............................34
7.2. Mitigation ................................................35
7.2.1. Measurement Validation .............................36
7.2.1.1. Effectiveness .............................36
7.2.1.2. Limitations (Unique Observer) .............37
7.2.2. Location Validation ................................38
7.2.2.1. Effectiveness .............................38
7.2.2.2. Limitations ...............................39
7.2.3. Supporting Observations ............................39
7.2.3.1. Effectiveness .............................40
7.2.3.2. Limitations ...............................40
7.2.4. Attribution ........................................40
7.2.5. Stateful Correlation of Location Requests ..........42
7.3. An Unauthorized or Compromised LIS ........................42
8. Measurement Schemas ............................................42
8.1. Measurement Container Schema ..............................43
8.2. Measurement Source Schema .................................45
8.3. Base Types Schema .........................................46
8.4. LLDP Measurement Schema ...................................49
8.5. DHCP Measurement Schema ...................................50
8.6. WiFi Measurement Schema ...................................51
8.7. Cellular Measurement Schema ...............................55
8.8. GNSS Measurement Schema ...................................57
8.9. DSL Measurement Schema ....................................59
9. IANA Considerations ............................................61
9.1. IANA Registry for GNSS Types ..............................61
9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc ...............62
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm .........................63
9.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:basetypes ...............63
9.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:lldp ....................64
9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp ....................65
9.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi ....................65
9.8. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:cell ....................66
9.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss ....................67
9.10. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dsl ....................67
9.11. XML Schema Registration for Measurement Source Schema ....68
9.12. XML Schema Registration for Measurement Container
Schema ...................................................68
9.13. XML Schema Registration for Base Types Schema ............69
9.14. XML Schema Registration for LLDP Schema ..................69
9.15. XML Schema Registration for DHCP Schema ..................69
9.16. XML Schema Registration for WiFi Schema ..................69
9.17. XML Schema Registration for Cellular Schema ..............70
9.18. XML Schema Registration for GNSS Schema ..................70
9.19. XML Schema Registration for DSL Schema ...................70
10. Acknowledgements ..............................................70
11. References ....................................................71
11.1. Normative References .....................................71
11.2. Informative References ...................................73
A Location Configuration Protocol (LCP) provides a means for a Device to request information about its physical location from an access network. A Location Information Server (LIS) is the server that provides location information that is available due to the knowledge it has about the network and physical environment.
ロケーション構成プロトコル（LCP）は、デバイスが物理的な場所に関する情報をアクセスネットワークから要求する手段を提供します。ロケーション情報サーバー（LIS）は、ネットワークと物理環境に関する知識があるために利用できるロケーション情報を提供するサーバーです。
As a part of the access network, the LIS is able to acquire measurement results related to Device location from network elements. The LIS also has access to information about the network topology that can be used to turn measurement data into location information. This information can be further enhanced with information acquired from the Device itself.
LISは、アクセスネットワークの一部として、デバイスの位置に関連する測定結果をネットワーク要素から取得できます。 LISは、測定データを位置情報に変換するために使用できるネットワークトポロジーに関する情報にもアクセスできます。この情報は、デバイス自体から取得した情報でさらに強化できます。
A Device is able to make observations about its network attachment, or its physical environment. The location-related measurement data might be unavailable to the LIS; alternatively, the LIS might be able to acquire the data, but at a higher cost in terms of time or some other metric. Providing measurement data gives the LIS more options in determining location; this could in turn improve the quality of the service provided by the LIS. Improvements in accuracy are one potential gain, but improved response times and lower error rates are also possible.
デバイスは、ネットワークアタッチメントまたは物理環境について観察することができます。ロケーション関連の測定データはLISで使用できない場合があります。あるいは、LISはデータを取得できる可能性がありますが、時間やその他のメトリックの点でコストが高くなります。測定データを提供することで、LISは場所を決定する際により多くのオプションを利用できます。これにより、LISによって提供されるサービスの品質が向上する可能性があります。精度の向上は1つの潜在的な利益ですが、応答時間の向上とエラー率の低下も可能です。
This document describes a means for a Device to report location-related measurement data to the LIS. Examples based on the HTTP-Enabled Location Delivery (HELD) [RFC5985] location configuration protocol are provided.
このドキュメントでは、デバイスが位置関連の測定データをLISに報告する方法について説明します。 HTTP対応ロケーション配信（HELD）[RFC5985]ロケーション構成プロトコルに基づく例が提供されています。
The terms "LIS" and "Device" are used in this document in a manner consistent with the usage in [RFC5985].
このドキュメントでは、「LIS」および「デバイス」という用語は、[RFC5985]での使用と一貫した方法で使用されています。
This document also uses the following definitions:
このドキュメントでは、次の定義も使用しています。
Location Measurement: An observation about the physical properties of a particular Device's position in time and space. The result of a location measurement -- "location-related measurement data", or simply "measurement data" given sufficient context -- can be used to determine the location of a Device. Location-related measurement data does not directly identify a Device, though it could do so indirectly. Measurement data can change with time if the location of the Device also changes.
位置測定：時間と空間における特定のデバイスの位置の物理的特性に関する観察。ロケーション測定の結果（「ロケーション関連の測定データ」、または十分なコンテキストが与えられた場合の「測定データ」）は、デバイスのロケーションを判別するために使用できます。位置に関連する測定データは、間接的に特定することはできますが、デバイスを直接特定することはありません。デバイスの場所も変わると、測定データは時間とともに変化する可能性があります。
Location-related measurement data does not necessarily contain location information directly, but it can be used in combination with contextual knowledge and/or algorithms to derive location information. Examples of location-related measurement data are radio signal strength or timing measurements, Ethernet switch identifiers, and port identifiers.
ロケーション関連の測定データには、必ずしもロケーション情報が直接含まれているとは限りませんが、コンテキスト情報やアルゴリズムと組み合わせて使用して、ロケーション情報を導出できます。ロケーション関連の測定データの例は、無線信号強度またはタイミング測定、イーサネットスイッチ識別子、およびポート識別子です。
Location-related measurement data can be considered sighting information, based on the definition in [RFC3693].
ロケーション関連の測定データは、[RFC3693]の定義に基づいて、目撃情報と見なすことができます。
Location Estimate: An approximation of where the Device is located. Location estimates are derived from location measurements. Location estimates are subject to uncertainty, which arises from errors in measurement results.
ロケーション推定：デバイスが配置されている場所の概算。ロケーション推定値は、ロケーション測定から導出されます。位置の推定は、測定結果の誤差から生じる不確実性の影響を受けます。
GNSS: Global Navigation Satellite System. A satellite-based system that provides positioning and time information -- for example, the US Global Positioning System (GPS) or the European Galileo system.
GNSS：Global Navigation Satellite System。位置情報と時刻情報を提供する衛星ベースのシステム-たとえば、米国の全地球測位システム（GPS）またはヨーロッパのガリレオシステム。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document defines a standard container for the conveyance of location-related measurement parameters in location configuration protocols. This is an XML container that identifies parameters by type and allows the Device to provide the results of any measurement it is able to perform. A set of measurement schemas are also defined that can be carried in the generic container.
このドキュメントでは、ロケーション構成プロトコルでロケーション関連の測定パラメーターを伝達するための標準コンテナーを定義しています。これは、タイプごとにパラメーターを識別し、デバイスが実行可能な測定の結果を提供できるようにするXMLコンテナーです。汎用コンテナで運ぶことができる測定スキーマのセットも定義されています。
A simple example of measurement data conveyance is illustrated by the example message in Figure 1. This shows a HELD location request message with an Ethernet switch and port measurement taken using the Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB].
測定データの伝達の簡単な例を図1のメッセージ例に示します。これは、イーサネットスイッチとHELD位置要求メッセージと、Link-Layer Discovery Protocol（LLDP）[IEEE.8021AB]を使用して行われたポート測定を示しています。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">civic</locationType>
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
<chassis type="4">0a01003c</chassis>
<port type="6">c2</port>
</lldp>
</measurements>
</locationRequest>
Figure 1: HELD Location Request with Measurement Data
図1：測定データを含むHELDロケーション要求
This LIS can ignore measurement data that it does not support or understand. The measurements defined in this document follow this rule: extensions that could result in backward incompatibility MUST be added as new measurement definitions rather than extensions to existing types.
このLISは、サポートまたは理解していない測定データを無視できます。このドキュメントで定義されている測定値は、次の規則に従います。下位互換性が失われる可能性のある拡張機能は、既存の型の拡張ではなく、新しい測定定義として追加する必要があります。
Multiple sets of measurement data, either of the same type or from different sources, can be included in the "measurements" element. See Section 4.1.1 for details on repetition of this element.
「測定」要素には、同じタイプまたは異なるソースからの測定データの複数のセットを含めることができます。この要素の繰り返しの詳細については、セクション4.1.1を参照してください。
A LIS can choose to use or ignore location-related measurement data in determining location, as long as rules regarding use and retention (Section 6) are respected. The "method" parameter in the Presence Information Data Format - Location Object (PIDF-LO) [RFC4119] SHOULD be adjusted to reflect the method used. A correct "method" can assist location recipients in assessing the quality (both accuracy and integrity) of location information, though there could be reasons to withhold information about the source of data.
LISは、使用と保持に関する規則（セクション6）が順守されている限り、位置を決定する際に位置関連の測定データを使用するか無視するかを選択できます。プレゼンス情報データ形式-ロケーションオブジェクト（PIDF-LO）の「メソッド」パラメータ[RFC4119]は、使用するメソッドを反映するように調整する必要があります。正しい「方法」は、ロケーションの受信者がロケーション情報の品質（精度と完全性の両方）を評価するのに役立ちますが、データのソースに関する情報を保留する理由がある場合もあります。
Measurement data is typically only used to serve the request in which it is included. There may be exceptions, particularly with respect to location URIs. Section 6 provides more information on usage rules.
通常、測定データは、それが含まれている要求を処理するためにのみ使用されます。特にロケーションURIに関しては例外がある場合があります。セクション6では、使用規則について詳しく説明します。
Location-related measurement data need not be provided exclusively by Devices. A third-party location requester (for example, see [RFC6155]) can request location information using measurement data, if the requester is able to acquire measurement data and authorized to distribute it. There are specific privacy considerations relating to the use of measurements by third parties, which are discussed in Section 6.4.
位置関連の測定データは、デバイスのみが提供する必要はありません。サードパーティの位置要求者（たとえば、[RFC6155]を参照）は、要求者が測定データを取得でき、それを配布する権限がある場合、測定データを使用して位置情報を要求できます。サードパーティによる測定の使用に関連するプライバシーに関する特別な考慮事項があります。これについては、セクション6.4で説明します。
Location-related measurement data and its use present a number of privacy and security challenges. These are described in more detail in Sections 6 and 7.
ロケーション関連の測定データとその使用には、プライバシーとセキュリティに関する多くの課題があります。これらについては、セクション6および7で詳しく説明します。
A common container is defined for the expression of location measurement data, as well as a simple means of identifying specific types of measurement data for the purposes of requesting them.
共通のコンテナは、ロケーション測定データの表現と、特定のタイプの測定データを要求する目的でそれらを識別する簡単な手段のために定義されています。
The following example shows a measurement container with measurement time and expiration time included. A WiFi measurement is enclosed.
次の例は、測定時間と有効期限が含まれた測定コンテナを示しています。 WiFi測定が同梱されています。
<lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"
expires="2008-04-29T17:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<ap serving="true">
<bssid>00-12-F0-A0-80-EF</bssid>
<ssid>wlan-home</ssid>
</ap>
</wifi>
</lm:measurements>
Figure 2: Measurement Example
図2：測定例
The "measurements" element is used to encapsulate measurement data that is collected at a certain point in time. It contains time-based attributes that are common to all forms of measurement data, and it permits the inclusion of arbitrary measurement data. The elements that are included within the "measurements" element are generically referred to as "measurement elements".
「measurements」要素は、特定の時点で収集された測定データをカプセル化するために使用されます。これには、すべての形式の測定データに共通する時間ベースの属性が含まれており、任意の測定データを含めることができます。 「計測」要素に含まれる要素を総称して「計測要素」と呼ぶ。
This container can be added to a request for location information in any protocol capable of carrying XML, such as a HELD location request [RFC5985].
このコンテナは、HELDロケーションリクエスト[RFC5985]など、XMLを伝送できる任意のプロトコルのロケーション情報のリクエストに追加できます。
The "time" attribute records the time that the measurement or observation was made. This time can be different from the time that the measurement information was reported. Time information can be used to populate a timestamp on the location result or to determine if the measurement information is used.
「時間」属性は、測定または観測が行われた時間を記録します。この時間は、測定情報が報告された時間とは異なる場合があります。時間情報を使用して、場所の結果にタイムスタンプを入力したり、測定情報を使用するかどうかを決定したりできます。
The "time" attribute SHOULD be provided whenever possible. This allows a LIS to avoid selecting an arbitrary timestamp. Exceptions to this, where omitting time might make sense, include relatively static types of measurement (for instance, the DSL measurements in Section 5.6) or for legacy Devices that don't record time information (such as the Home Location Register/Home Subscriber Server for cellular).
「時間」属性は、可能な限り提供する必要があります。これにより、LISは任意のタイムスタンプの選択を回避できます。時間の省略が理にかなっている可能性があるこの例外には、比較的静的なタイプの測定（たとえば、セクション5.6のDSL測定）または時間情報を記録しないレガシーデバイス（Home Location Register / Home Subscriber Serverなど）が含まれます。携帯電話用）。
The "time" attribute is attached to the root "measurement" element. Multiple measurements can often be given the same timestamp, even when the measurements were not actually taken at the same time (consider a set of measurements taken sequentially, where the difference in time between observations is not significant). Measurements cannot be grouped if they have different types or if there is a need for independent time values on each measurement. In these instances, multiple measurement sets are necessary.
「time」属性は、ルートの「measurement」要素に関連付けられています。測定が実際に同時に行われなかった場合でも、複数の測定に同じタイムスタンプが与えられることがよくあります（観測間の時間差が重要ではない、連続して行われた一連の測定を考えてください）。タイプが異なる場合、または各測定で独立した時間値が必要な場合、測定をグループ化することはできません。これらの例では、複数の測定セットが必要です。
A Device is able to indicate an expiry time in the location measurement using the "expires" attribute. Nominally, this attribute indicates how long information is expected to be valid, but it can also indicate a time limit on the retention and use of the measurement data. A Device can use this attribute to request that the LIS not retain measurement data beyond the indicated time.
デバイスは、「expires」属性を使用して、ロケーション測定で有効期限を示すことができます。名目上、この属性は、情報が有効であると予想される期間を示しますが、測定データの保持と使用に関する時間制限を示すこともあります。デバイスはこの属性を使用して、LISが指定された時間を超えて測定データを保持しないように要求できます。
Note: Movement of the Device might result in the measurement data being invalidated before the expiry time.
注：デバイスを移動すると、有効期限が切れる前に測定データが無効になる場合があります。
A Device is advised to set the "expires" attribute to the earlier of the time that measurements are likely to be unusable and the time that it desires to have measurements discarded by the LIS. A Device that does not desire measurement data to be retained can omit the "expires" attribute. Section 6 describes more specific rules regarding measurement data retention.
デバイスは、「expires」属性を、測定値が使用できなくなる可能性が高い時間、およびLISが測定値を破棄することを望む時間に設定することをお勧めします。測定データの保持を望まないデバイスは、「expires」属性を省略できます。セクション6では、測定データの保持に関するより具体的なルールについて説明します。
Often a measurement is taken more than once. Reporting the average of a number of measurement results mitigates the effects of random errors that occur in the measurement process.
多くの場合、測定は複数回行われます。多数の測定結果の平均を報告することで、測定プロセスで発生するランダムエラーの影響を軽減できます。
Reporting each measurement individually can be the most effective method of reporting multiple measurements. This is achieved by providing multiple measurement elements for different times.
各測定を個別に報告することは、複数の測定を報告する最も効果的な方法です。これは、異なる時間に複数の測定要素を提供することによって達成されます。
The alternative is to aggregate multiple measurements and report a mean value across the set of measurements. Additional information about the distribution of the results can be useful in determining location uncertainty.
別の方法として、複数の測定値を集計し、一連の測定値の平均値を報告します。結果の分布に関する追加情報は、場所の不確実性を判断するのに役立ちます。
Two attributes are provided for use on some measurement values:
一部の測定値で使用するために、2つの属性が用意されています。
rmsError: The root-mean-squared (RMS) error of the set of measurement values used in calculating the result. RMS error is expressed in the same units as the measurement, unless otherwise stated. If an accurate value for the RMS error is not known, this value can be used to indicate an upper bound or estimate for the RMS error.
rmsError：結果の計算に使用される測定値のセットの二乗平均（RMS）誤差。 RMSエラーは、特に明記されていない限り、測定値と同じ単位で表されます。 RMSエラーの正確な値がわからない場合、この値を使用して、RMSエラーの上限または推定値を示すことができます。
samples: The number of samples that were taken in determining the measurement value. If omitted, this value can be assumed to be large enough that the RMS error is an indication of the standard deviation of the sample set.
サンプル：測定値を決定するために取得されたサンプルの数。省略した場合、この値は、RMSエラーがサンプルセットの標準偏差を示すのに十分な大きさであると想定できます。
For some measurement techniques, measurement error is largely dependent on the measurement technique employed. In these cases, measurement error is largely a product of the measurement technique and not the specific circumstances, so the RMS error does not need to be actively measured. A fixed value MAY be provided for the RMS error where appropriate.
一部の測定手法では、測定誤差は採用する測定手法に大きく依存します。これらの場合、測定誤差は主に測定技術の結果であり、特定の状況ではないため、RMS誤差を積極的に測定する必要はありません。必要に応じて、RMSエラーに固定値を指定できます。
The "rmsError" and "samples" elements are added as attributes of specific measurement data types.
「rmsError」および「samples」要素は、特定の測定データタイプの属性として追加されます。
Measurement of time can be significant in certain circumstances. The GNSS measurements included in this document are one such case where a small error in time can result in a large error in location. Factors such as clock drift and errors in time synchronization can result in small, but significant, time errors. Including an indication of the quality of time measurements can be helpful.
時間の測定は、特定の状況で重要になる場合があります。このドキュメントに含まれているGNSS測定は、時間の小さな誤差が場所の大きな誤差につながる可能性がある1つのケースです。クロックのドリフトや時間同期のエラーなどの要因により、小さいが重大な時間エラーが発生する可能性があります。時間測定の質の指標を含めると役立ちます。
A "timeError" attribute MAY be added to the "measurement" element to indicate the RMS error in time. "timeError" indicates an upper bound on the time RMS error in seconds.
「timeError」属性を「measurement」要素に追加して、RMSエラーを時間で示すことができます。 「timeError」は、秒単位の時間RMSエラーの上限を示します。
The "timeError" attribute does not apply where multiple samples of a measurement are taken over time. If multiple samples are taken, each SHOULD be included in a different "measurement" element.
「timeError」属性は、時間の経過とともに測定の複数のサンプルが取得される場合には適用されません。複数のサンプルを取得する場合は、それぞれを別の「測定」要素に含める必要があります（SHOULD）。
A measurement request is used by a protocol peer to describe a set of measurement data that it desires. A "measurementRequest" element is defined that can be included in a protocol exchange.
プロトコルピアは、測定要求を使用して、必要な測定データのセットを記述します。プロトコル交換に含めることができる「measurementRequest」要素が定義されています。
For instance, a LIS can use a measurement request in HELD responses. If the LIS is unable to provide location information, but it believes that a particular measurement type would enable it to provide a location, it can include a measurement request in an error response.
たとえば、LISはHELD応答で測定要求を使用できます。 LISが位置情報を提供できないが、特定の測定タイプで位置情報を提供できると考えている場合、LISは測定応答をエラー応答に含めることができます。
The "measurement" element of the measurement request identifies the type of measurement that is requested. The "type" attribute of this element indicates the type of measurement, as identified by an XML qualified name. A "samples" attribute MAY be used to indicate how many samples of the identified measurement are requested.
測定要求の「測定」要素は、要求された測定のタイプを識別します。この要素の「type」属性は、XML修飾名で識別される測定のタイプを示します。 「samples」属性を使用して、識別された測定の要求されたサンプルの数を示すことができます。
The "measurement" element can be repeated to request multiple (or alternative) measurement types.
「測定」要素を繰り返して、複数の（または代替の）測定タイプを要求できます。
Additional XML content might be defined for a particular measurement type that is used to further refine a request. These elements either constrain what is requested or specify non-mandatory components of the measurement data that are needed. These are defined along with the specific measurement type.
リクエストをさらに絞り込むために使用される特定の測定タイプに対して、追加のXMLコンテンツが定義される場合があります。これらの要素は、要求されるものを制約するか、必要な測定データの必須ではないコンポーネントを指定します。これらは、特定の測定タイプとともに定義されます。
In the HELD protocol, the inclusion of a measurement request in an error response with a code of "locationUnknown" indicates that providing measurements would increase the likelihood of a subsequent request being successful.
HELDプロトコルでは、コード "locationUnknown"のエラー応答に測定要求を含めることは、測定を提供すると後続の要求が成功する可能性が高まることを示しています。
The following example shows a HELD error response that indicates that WiFi measurement data would be useful if a later request were made. Additional elements indicate that received signal strength for an 802.11n access point is requested.
次の例は、後で要求が行われた場合にWiFi測定データが役立つことを示すHELDエラー応答を示しています。追加の要素は、802.11nアクセスポイントの受信信号強度が要求されていることを示します。
<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:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<measurement type="wifi:wifi">
<wifi:type>n</wifi:type>
<wifi:parameter context="ap">wifi:rcpi</wifi:parameter>
</measurement>
</measurementRequest>
</error>
Figure 3: HELD Error Requesting Measurement Data
図3：測定データを要求するHELDエラー
A measurement request that is included in other HELD messages has undefined semantics and can be safely ignored. Other specifications might define semantics for measurement requests under other conditions.
他のHELDメッセージに含まれている測定要求には、定義されていないセマンティクスがあり、無視しても問題ありません。他の仕様では、他の条件下での測定要求のセマンティクスを定義する場合があります。
An extension is made to the PIDF-LO [RFC4119] that allows a location recipient to identify the source (or sources) of location information and the measurement data that was used to determine that location information.
PIDF-LO [RFC4119]が拡張され、ロケーション受信者がロケーション情報のソース（複数可）とそのロケーション情報を決定するために使用された測定データを識別できるようになりました。
The "source" element is added to the "geopriv" element of the PIDF-LO. This element does not identify specific entities. Instead, it identifies the type of measurement source.
「source」要素がPIDF-LOの「geopriv」要素に追加されます。この要素は特定のエンティティを識別しません。代わりに、測定ソースのタイプを識別します。
The following values are defined for the "source" element:
「source」要素には次の値が定義されています。
lis: Location information is based on measurement data that the LIS or sources that it trusts have acquired. This label MAY be used if measurement data provided by the Device has been completely validated by the LIS.
lis：位置情報は、信頼できるLISまたは信頼できるソースが取得した測定データに基づいています。このラベルは、デバイスによって提供される測定データがLISによって完全に検証されている場合に使用できます。
device: A LIS MUST include this value if the location information is based (in whole or in part) on measurement data provided by the Device and if the measurement data isn't completely validated.
デバイス：LISは、位置情報がデバイスによって提供された測定データに（全体的または部分的に）基づいている場合、および測定データが完全に検証されていない場合に、この値を含める必要があります。
other: Location information is based on measurement data that a third party has provided. This might be an authorized third party that uses identity parameters [RFC6155] or any other entity. The LIS MUST include this, unless the third party is trusted by the LIS to provide measurement data.
その他：位置情報は、第三者が提供した測定データに基づいています。これは、IDパラメータ[RFC6155]またはその他のエンティティを使用する承認済みのサードパーティである可能性があります。第三者がLISから信頼されて測定データを提供していない限り、LISにこれを含める必要があります。
No assertion is made about the veracity of the measurement data from sources other than the LIS. A combination of tags MAY be included to indicate that measurement data from multiple types of sources was used.
LIS以外のソースからの測定データの信憑性については、何も言明されていません。複数のタイプのソースからの測定データが使用されたことを示すために、タグの組み合わせが含まれる場合があります。
For example, the first tuple of the following PIDF-LO indicates that measurement data from a LIS and a Device was combined to produce the result; the second tuple was produced by the LIS alone.
たとえば、次のPIDF-LOの最初のタプルは、LISとデバイスからの測定データが結合されて結果が生成されたことを示しています。 2番目のタプルはLISのみによって生成されました。
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
entity="pres:lm@example.com">
<tuple id="deviceLoc">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>7.34324 134.47162</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<gp:method>OTDOA</gp:method>
<lmsrc:source>lis device</lmsrc:source>
</gp:geopriv>
</status>
</tuple>
<tuple id="lisLoc">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>7.34379 134.46484</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
9000
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Cell</gp:method>
<lmsrc:source>lis</lmsrc:source>
</gp:geopriv>
</status>
</tuple>
</presence>
PIDF-LO Document with Source Labels
ソースラベル付きPIDF-LOドキュメント
This document defines location-related measurement data types for a range of common network types.
このドキュメントでは、さまざまな一般的なネットワークタイプの場所に関連する測定データタイプを定義します。
All included measurement data definitions allow for arbitrary extension in the corresponding schema. New parameters that are applicable to location determination are added as new XML elements in a unique namespace, not by adding elements to an existing namespace.
含まれているすべての測定データ定義により、対応するスキーマで任意の拡張が可能になります。場所の決定に適用される新しいパラメーターは、既存の名前空間に要素を追加するのではなく、一意の名前空間に新しいXML要素として追加されます。
Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent between adjacent nodes in an IEEE 802 network (e.g., wired Ethernet, WiFi, 802.16). These messages all contain identification information for the sending node; the identification information can be used to determine location information. A Device that receives LLDP messages can report this information as a location-related measurement to the LIS, which is then able to use the measurement data in determining the location of the Device.
リンク層発見プロトコル（LLDP）[IEEE.8021AB]メッセージは、IEEE 802ネットワーク（有線イーサネット、WiFi、802.16など）の隣接ノード間で送信されます。これらのメッセージにはすべて、送信ノードの識別情報が含まれています。識別情報は、位置情報を決定するために使用できます。 LLDPメッセージを受信するデバイスは、この情報を位置関連の測定値としてLISに報告できます。これにより、測定データを使用してデバイスの位置を特定できます。
Note: The LLDP extensions defined in LLDP Media Endpoint Discovery (LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location information directly from an LLDP endpoint. Where this information is available, it might be unnecessary to use any other form of location configuration.
注：LLDP Media Endpoint Discovery（LLDP-MED）[ANSI-TIA-1057]で定義されたLLDP拡張機能は、LLDPエンドポイントから直接位置情報を取得する機能を提供します。この情報が利用可能な場合は、他の形式のロケーション構成を使用する必要がない場合があります。
Values are provided as hexadecimal sequences. The Device MUST report the values directly as they were provided by the adjacent node. Attempting to adjust or translate the type of identifier is likely to cause the measurement data to be useless.
値は16進数のシーケンスとして提供されます。デバイスは、隣接ノードから提供された値を直接報告する必要があります。識別子のタイプを調整または変換しようとすると、測定データが役に立たなくなる可能性があります。
Where a Device has received LLDP messages from multiple adjacent nodes, it should provide information extracted from those messages by repeating the "lldp" element.
デバイスが複数の隣接ノードからLLDPメッセージを受信した場合、「lldp」要素を繰り返すことにより、それらのメッセージから抽出された情報を提供する必要があります。
An example of an LLDP measurement is shown in Figure 4. This shows an adjacent node (chassis) that is identified by the IP address 192.0.2.45 (hexadecimal c000022d), and the port on that node is numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).
LLDP測定の例を図4に示します。これは、IPアドレス192.0.2.45（16進数のc000022d）で識別される隣接ノード（シャーシ）を示し、そのノードのポートはエージェント回路ID [RFC3046 ]の162（16進数のa2）。
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
<chassis type="4">c000022d</chassis>
<port type="6">a2</port>
</lldp>
</measurements>
Figure 4: LLDP Measurement Example
図4：LLDP測定の例
IEEE 802 Devices that are able to obtain information about adjacent network switches and their attachment to them by other means MAY use this data type to convey this information.
隣接するネットワークスイッチとそれらへの接続に関する情報を他の方法で取得できるIEEE 802デバイスは、このデータタイプを使用してこの情報を伝えることができます。
The DHCP Relay Agent Information option [RFC3046] provides measurement data about the network attachment of a Device. This measurement data can be included in the "dhcp-rai" element.
DHCPリレーエージェント情報オプション[RFC3046]は、デバイスのネットワーク接続に関する測定データを提供します。この測定データは、「dhcp-rai」要素に含めることができます。
The elements in the DHCP relay agent information options are opaque data types assigned by the DHCP relay agent. The three items MAY be omitted if unknown: circuit identifier ("circuit", circuit [RFC3046], or Interface-Id [RFC3315]), remote identifier ("remote", Remote ID [RFC3046], or remote-id [RFC4649]), and subscriber identifier ("subscriber", subscriber-id [RFC3993], or Subscriber-ID [RFC4580]). The DHCPv6 remote-id has an associated enterprise number [IANA.enterprise] as an XML attribute.
DHCPリレーエージェント情報オプションの要素は、DHCPリレーエージェントによって割り当てられる不透明なデータタイプです。不明な場合は3つの項目を省略できます：回路識別子（「回路」、回路[RFC3046]、またはインターフェイスID [RFC3315]）、リモート識別子（「リモート」、リモートID [RFC3046]、またはリモートID [RFC4649] ）、およびサブスクライバーID（「サブスクライバー」、サブスクライバーID [RFC3993]、またはサブスクライバーID [RFC4580]）。 DHCPv6リモートIDには、XML属性として関連付けられたエンタープライズ番号[IANA.enterprise]があります。
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dhcp-rai xmlns="urn:ietf:params:xml:ns:geopriv:lm:dhcp">
<giaddr>192.0.2.158</giaddr>
<circuit>108b</circuit>
</dhcp-rai>
</measurements>
Figure 5: DHCP Relay Agent Information Measurement Example
図5：DHCPリレーエージェント情報の測定例
The "giaddr" element is specified as a dotted quad IPv4 address or an RFC 4291 [RFC4291] IPv6 address, using the forms defined in [RFC3986]; IPv6 addresses SHOULD use the form described in [RFC5952]. The enterprise number is specified as a decimal integer. All other information is included verbatim from the DHCP request in hexadecimal format.
「giaddr」要素は、[RFC3986]で定義された形式を使用して、ドット付きクワッドIPv4アドレスまたはRFC 4291 [RFC4291] IPv6アドレスとして指定されます。 IPv6アドレスは、[RFC5952]で説明されている形式を使用する必要があります（SHOULD）。企業番号は10進整数として指定されます。他のすべての情報は、DHCP要求からそのまま16進数形式で含まれています。
The "subscriber" element could be considered sensitive. This information MUST NOT be provided to a LIS that is not authorized to receive information about the access network. See Section 7.1.3 for more details.
「subscriber」要素は機密と見なされる可能性があります。この情報は、アクセスネットワークに関する情報の受信を許可されていないLISに提供してはなりません（MUST NOT）。詳細については、セクション7.1.3を参照してください。
In WiFi, or 802.11 [IEEE.80211], networks, a Device might be able to provide information about the access point (AP) to which it is attached, or other WiFi points it is able to see. This is provided using the "wifi" element, as shown in Figure 6, which shows a single complete measurement for a single access point.
WiFi、または802.11 [IEEE.80211]ネットワークでは、デバイスは、それが接続されているアクセスポイント（AP）、またはそれが見ることができる他のWiFiポイントに関する情報を提供できる場合があります。これは、図6に示すように「wifi」要素を使用して提供されます。これは、単一のアクセスポイントの単一の完全な測定を示しています。
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2011-04-29T14:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<nicType>Intel(r)PRO/Wireless 2200BG</nicType>
<ap serving="true">
<bssid>AB-CD-EF-AB-CD-EF</bssid>
<ssid>example</ssid>
<channel>5</channel>
<location>
<gml:Point xmlns:gml="http://opengis.net/gml">
<gml:pos>-34.4 150.8</gml:pos>
</gml:Point>
</location>
<type>a</type>
<band>5</band>
<regclass country="AU">2</regclass>
<antenna>2</antenna>
<flightTime rmsError="4e-9" samples="1">2.56e-9</flightTime>
<apSignal>
<transmit>23</transmit>
<gain>5</gain>
<rcpi dBm="true" rmsError="12" samples="1">-59</rcpi>
<rsni rmsError="15" samples="1">23</rsni>
</apSignal>
<deviceSignal>
<transmit>10</transmit>
<gain>9</gain>
<rcpi dBm="true" rmsError="9.5" samples="1">-98.5</rcpi>
<rsni rmsError="6" samples="1">7.5</rsni>
</deviceSignal>
</ap>
</wifi>
</measurements>
Figure 6: 802.11 WLAN Measurement Example
図6：802.11 WLAN測定の例
A "wifi" element is made up of one or more access points, and a "nicType" element, which MAY be omitted. Each access point is described using the "ap" element, which is comprised of the following fields:
「wifi」要素は、1つ以上のアクセスポイントと「nicType」要素で構成されます。これらは省略してもかまいません。各アクセスポイントは、次のフィールドで構成される「ap」要素を使用して記述されます。
bssid: The Basic Service Set (BSS) identifier. In an Infrastructure BSS network, the bssid is the 48-bit MAC address of the access point.
bssid：基本サービスセット（BSS）識別子。インフラストラクチャBSSネットワークでは、bssidはアクセスポイントの48ビットMACアドレスです。
The "verified" attribute of this element describes whether the Device has verified the MAC address or it authenticated the access point or the network operating the access point (for example, a captive portal accessed through the access point has been authenticated). This attribute defaults to a value of "false" when omitted.
この要素の「検証済み」属性は、デバイスがMACアドレスを検証したか、それともアクセスポイントまたはアクセスポイントを操作するネットワークを認証したか（たとえば、アクセスポイントを介してアクセスされるキャプティブポータルが認証されたか）を示します。省略した場合、この属性のデフォルト値は「false」です。
ssid: The service set identifier (SSID) for the wireless network served by the access point.
ssid：アクセスポイントがサービスを提供するワイヤレスネットワークのサービスセット識別子（SSID）。
The SSID is a 32-octet identifier that is commonly represented as an ASCII [ASCII] or UTF-8 [RFC3629] encoded string. To represent octets that cannot be directly included in an XML element, escaping is used. Sequences of octets that do not represent a valid UTF-8 encoding can be escaped using a backslash ('\') followed by two case-insensitive hexadecimal digits representing the value of a single octet.
SSIDは、ASCII [ASCII]またはUTF-8 [RFC3629]でエンコードされた文字列として一般的に表される32オクテットの識別子です。 XML要素に直接含めることができないオクテットを表すには、エスケープが使用されます。有効なUTF-8エンコーディングを表さないオクテットのシーケンスは、バックスラッシュ（ '\'）を使用してエスケープでき、その後に1つのオクテットの値を表す2つの大文字と小文字を区別しない16進数字が続きます。
The canonical or value-space form of an SSID is a sequence of up to 32 octets that is produced from the concatenation of UTF-8 encoded sequences of unescaped characters and octets derived from escaped components.
SSIDの正規形式または値空間形式は、エスケープされていない文字のUTF-8エンコードされたシーケンスとエスケープされたコンポーネントから派生したオクテットの連結から生成される、最大32オクテットのシーケンスです。
channel: The channel number (frequency) on which the access point operates.
チャネル：アクセスポイントが動作するチャネル番号（周波数）。
location: The location of the access point, as reported by the access point. This element contains any valid location, using the rules for a "location-info" element, as described in [RFC5491].
location：アクセスポイントによって報告されるアクセスポイントの場所。この要素には、[RFC5491]で説明されている「location-info」要素の規則を使用して、有効な場所が含まれます。
type: The network type for the network access. This element includes the alphabetic suffix of the 802.11 specification that introduced the radio interface, or PHY, e.g., "a", "b", "g", or "n".
type：ネットワークアクセスのネットワークタイプ。この要素には、「a」、「b」、「g」、「n」など、無線インターフェースまたはPHYを導入した802.11仕様のアルファベットのサフィックスが含まれています。
band: The frequency band for the radio, in gigahertz (GHz). 802.11 [IEEE.80211] specifies PHY layers that use 2.4, 3.7, and 5 gigahertz frequency bands.
band：ギガヘルツ（GHz）単位の無線の周波数帯域。 802.11 [IEEE.80211]は、2.4、3.7、および5ギガヘルツの周波数帯域を使用するPHY層を指定しています。
regclass: The operating class (regulatory domain and class in older versions of 802.11); see Annex E of [IEEE.80211]. The "country" attribute optionally includes the applicable two-character country identifier (dot11CountryString), which can be followed by an 'O', 'I', or 'X'. The element text content includes the value of the regulatory class: an 8-bit integer in decimal form.
regclass：オペレーティングクラス（802.11の古いバージョンの規制ドメインとクラス）。 [IEEE.80211]の付録Eを参照してください。 「country」属性には、必要に応じて、該当する2文字の国識別子（dot11CountryString）を含め、その後に「O」、「I」、または「X」を続けることができます。要素のテキストコンテンツには、規制クラスの値が含まれます。10進数形式の8ビット整数です。
antenna: The antenna identifier for the antenna that the access point is using to transmit the measured signals.
アンテナ：アクセスポイントが測定信号の送信に使用しているアンテナのアンテナ識別子。
flightTime: Flight time is the difference between the time of departure (TOD) of signal from a transmitting station and time of arrival (TOA) of signal at a receiving station, as defined in [IEEE.80211]. Measurement of this value requires that stations synchronize their clocks. This value can be measured by an access point or Device; because the flight time is assumed to be the same in either direction -- aside from measurement errors -- only a single element is provided. This element permits the use of the "rmsError" and "samples" attributes. RMS error might be derived from the reported RMS error in TOD and TOA.
flightTime：飛行時間は、[IEEE.80211]で定義されている、送信局からの信号の出発時刻（TOD）と受信局での信号の到着時刻（TOA）との差です。この値を測定するには、ステーションがクロックを同期する必要があります。この値は、アクセスポイントまたはデバイスで測定できます。飛行時間はどちらの方向でも同じであると想定されているため、測定誤差は別として、単一の要素のみが提供されます。この要素は、「rmsError」および「samples」属性の使用を許可します。 RMSエラーは、TODおよびTOAで報告されたRMSエラーから導出される場合があります。
apSignal: Measurement information for the signal transmitted by the access point, as observed by the Device. Some of these values are derived from 802.11v [IEEE.80211] messages exchanged between the Device and access point. The contents of this element include:
apSignal：デバイスによって監視される、アクセスポイントによって送信された信号の測定情報。これらの値の一部は、デバイスとアクセスポイント間で交換される802.11v [IEEE.80211]メッセージから導出されます。この要素の内容は次のとおりです。
transmit: The transmit power reported by the access point, in dBm.
transmit：アクセスポイントから報告された送信電力（dBm）。
gain: The gain of the access point antenna reported by the access point, in dB.
ゲイン：アクセスポイントから報告されたアクセスポイントアンテナのゲイン（dB）。
rcpi: The received channel power indicator for the access point signal, as measured by the Device. This value SHOULD be in units of dBm (with RMS error in dB). If power is measured in a different fashion, the "dBm" attribute MUST be set to "false". Signal strength reporting on current hardware uses a range of different mechanisms; therefore, the value of the "nicType" element SHOULD be included if the units are not known to be in dBm, and the value reported by the hardware should be included without modification. This element permits the use of the "rmsError" and "samples" attributes.
rcpi：デバイスによって測定された、アクセスポイント信号の受信チャネル電力インジケーター。この値は、dBmの単位にする必要があります（RMSエラーはdB）。電力が別の方法で測定される場合、「dBm」属性を「false」に設定する必要があります。現在のハードウェアの信号強度レポートは、さまざまなメカニズムを使用しています。したがって、単位がdBmであることがわからない場合は、「nicType」要素の値を含めるべきであり、ハードウェアによって報告された値を変更せずに含める必要があります。この要素は、「rmsError」および「samples」属性の使用を許可します。
rsni: The received signal-to-noise indicator in dB. This element permits the use of the "rmsError" and "samples" attributes.
rsni：受信した信号対雑音指標（dB）。この要素は、「rmsError」および「samples」属性の使用を許可します。
deviceSignal: Measurement information for the signal transmitted by the Device, as reported by the access point. This element contains the same child elements as the "ap" element, with the access point and Device roles reversed.
deviceSignal：アクセスポイントによって報告された、デバイスによって送信された信号の測定情報。この要素には、「ap」要素と同じ子要素が含まれ、アクセスポイントとデバイスの役割が逆になります。
The only mandatory element in this structure is "bssid".
この構造の唯一の必須要素は「bssid」です。
The "nicType" element is used to specify the make and model of the wireless network interface in the Device. Different 802.11 chipsets report measurements in different ways, so knowing the network interface type aids the LIS in determining how to use the provided measurement data. The content of this field is unconstrained, and no mechanisms are specified to ensure uniqueness. This field is unlikely to be useful, except under tightly controlled circumstances.
「nicType」要素は、デバイスのワイヤレスネットワークインターフェイスのメーカーとモデルを指定するために使用されます。異なる802.11チップセットは異なる方法で測定を報告するため、ネットワークインターフェイスの種類を知ることは、提供された測定データの使用方法をLISが決定するのに役立ちます。このフィールドの内容には制約がなく、一意性を保証するメカニズムは指定されていません。このフィールドは、厳密に制御された状況下を除いて、有用である可能性は低いです。
Two elements are defined for requesting WiFi measurements in a measurement request:
測定要求でWiFi測定を要求するために2つの要素が定義されています。
type: The "type" element identifies the desired type (or types that are requested).
type：「type」要素は、目的のタイプ（または要求されたタイプ）を識別します。
parameter: The "parameter" element identifies measurements that are requested for each measured access point. An element is identified by its qualified name. The "context" parameter can be used to specify if an element is included as a child of the "ap" or "device" elements; omission indicates that it applies to both.
parameter：「parameter」要素は、測定されたアクセスポイントごとに要求される測定を識別します。要素はその修飾名で識別されます。 「context」パラメータを使用して、要素が「ap」または「device」要素の子として含まれるかどうかを指定できます。省略は、両方に適用されることを示します。
Multiple types or parameters can be requested by repeating either element.
いずれかの要素を繰り返すことにより、複数のタイプまたはパラメーターを要求できます。
Cellular Devices are common throughout the world, and base station identifiers can provide a good source of coarse location information. Cellular measurements can be provided to a LIS run by the cellular operator, or may be provided to an alternative LIS operator that has access to one of several global cell-id to location mapping databases.
セルラーデバイスは世界中で一般的であり、基地局識別子は大まかな位置情報の優れたソースを提供できます。セルラー測定は、セルラーオペレーターが実行するLISに提供できます。または、いくつかのグローバルセルIDからロケーションマッピングデータベースへのアクセス権を持つ代替LISオペレーターに提供することもできます。
A number of advanced location determination methods have been developed for cellular networks. For these methods, a range of measurement parameters can be collected by the network, Device, or both in cooperation. This document includes a basic identifier for the wireless transmitter only; future efforts might define additional parameters that enable more accurate methods of location determination.
セルラーネットワーク用に、多くの高度な位置決定方法が開発されています。これらの方法では、ネットワーク、デバイス、またはその両方が連携して、さまざまな測定パラメーターを収集できます。このドキュメントには、ワイヤレストランスミッターのみの基本的な識別子が含まれています。今後の取り組みでは、位置決定のより正確な方法を可能にする追加のパラメーターを定義する可能性があります。
The cellular measurement set allows a Device to report to a LIS any LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9), or CDMA (Figure 10) cells that it is able to observe. Cells are reported using their global identifiers. All Third Generation Partnership Project (3GPP) cells are identified by a public land mobile network (PLMN), which comprises a mobile country code (MCC) and mobile network code (MNC); specific fields are added for each network type.
セルラー測定セットを使用すると、デバイスはLES（図7）、UMTS（図8）、GSM（図9）、またはCDMA（図10）のセルを観察することができます。セルは、グローバル識別子を使用して報告されます。すべての第3世代パートナーシッププロジェクト（3GPP）セルは、モバイルランドコード（MCC）とモバイルネットワークコード（MNC）で構成されるパブリックランドモバイルネットワーク（PLMN）によって識別されます。ネットワークタイプごとに特定のフィールドが追加されます。
Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003]. Bit-level formats for CDMA cell identifiers are described in [TIA-2000.5]; decimal representations are used.
3GPPセル識別子のフォーマットは、[TS.3GPP.23.003]で説明されています。 CDMAセル識別子のビットレベルフォーマットは、[TIA-2000.5]で説明されています。 10進数表現が使用されます。
MCC and MNC are provided as decimal digit sequences; a leading zero in an MCC or MNC is significant. All other values are decimal integers.
MCCおよびMNCは、10進数のシーケンスとして提供されます。 MCCまたはMNCの先行ゼロは重要です。他のすべての値は10進整数です。
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>465</mcc><mnc>20</mnc><eucid>80936424</eucid>
</servingCell>
<observedCell>
<mcc>465</mcc><mnc>06</mnc><eucid>10736789</eucid>
</observedCell>
</cellular>
</measurements>
Long term evolution (LTE) cells are identified by a 28-bit cell identifier (eucid).
長期進化（LTE）セルは、28ビットのセル識別子（eucid）で識別されます。
Figure 7: Example LTE Cellular Measurement
図7：LTEセルラー測定の例
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>465</mcc><mnc>20</mnc>
<rnc>2000</rnc><cid>65000</cid>
</servingCell>
<observedCell>
<mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</observedCell>
</cellular>
</measurements>
Universal mobile telephony service (UMTS) cells are identified by a 12- or 16-bit radio network controller (rnc) id and a 16-bit cell id (cid).
ユニバーサルモバイルテレフォニーサービス（UMTS）セルは、12ビットまたは16ビットの無線ネットワークコントローラー（rnc）IDと16ビットのセルID（cid）で識別されます。
Figure 8: Example UMTS Cellular Measurement
図8：UMTSセルラー測定の例
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</servingCell>
</cellular>
</measurements>
Global System for Mobile communication (GSM) cells are identified by a 16-bit location area code (lac) and a 16-bit cell id (cid).
Global System for Mobile Communication（GSM）セルは、16ビットのロケーションエリアコード（lac）と16ビットのセルID（cid）で識別されます。
Figure 9: Example GSM Cellular Measurement
図9：GSMセルラー測定の例
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<sid>15892</sid><nid>4723</nid><baseid>12</baseid>
</servingCell>
<observedCell>
<sid>15892</sid><nid>4723</nid><baseid>13</baseid>
</observedCell>
</cellular>
</measurements>
Code division multiple access (CDMA) cells are not identified by a PLMN; instead, these use a 15-bit system id (sid), a 16-bit network id (nid), and a 16-bit base station id (baseid).
コード分割多重アクセス（CDMA）セルはPLMNによって識別されません。代わりに、これらは15ビットのシステムID（sid）、16ビットのネットワークID（nid）、および16ビットの基地局ID（baseid）を使用します。
Figure 10: Example CDMA Cellular Measurement
図10：CDMAセルラー測定の例
In general, a cellular Device will be attached to the cellular network, so the notion of a serving cell exists. Cellular networks also provide overlap between neighboring sites, so a mobile Device can hear more than one cell. The measurement schema supports sending both the serving cell and any other cells that the mobile might be able to hear. In some cases, the Device could simply be listening to cell information without actually attaching to the network; mobiles without a SIM are an example of this. In this case, the Device could report cells it can hear without identifying any particular cell as a serving cell. An example of this is shown in Figure 11.
一般に、セルラーデバイスはセルラーネットワークに接続されるため、サービングセルの概念が存在します。セルラーネットワークは、隣接サイト間のオーバーラップも提供するため、モバイルデバイスは複数のセルを聞くことができます。測定スキーマは、サービングセルとモバイルが聞くことができる他のセルの両方の送信をサポートします。場合によっては、デバイスが実際にネットワークに接続せずに、単にセル情報をリッスンしている可能性があります。 SIMのない携帯電話はこの例です。この場合、デバイスは、特定のセルをサービングセルとして識別せずに、聞こえるセルを報告できます。この例を図11に示します。
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<observedCell>
<mcc>465</mcc><mnc>20</mnc>
<rnc>2000</rnc><cid>65000</cid>
</observedCell>
<observedCell>
<mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</observedCell>
</cellular>
</measurements>
Figure 11: Example Observed Cellular Measurement
図11：観察された細胞測定の例
Two elements can be used in measurement requests for cellular measurements:
細胞測定の測定要求では、2つの要素を使用できます。
type: A label indicating the type of identifier to provide: one of "gsm", "umts", "lte", or "cdma".
type：提供する識別子のタイプを示すラベル：「gsm」、「umts」、「lte」、または「cdma」のいずれか。
network: The network portion of the cell identifier. For 3GPP networks, this is the combination of MCC and MNC; for CDMA, this is the network identifier.
network：セル識別子のネットワーク部分。 3GPPネットワークの場合、これはMCCとMNCの組み合わせです。 CDMAの場合、これはネットワーク識別子です。
Multiple identifier types or networks can be identified by repeating either element.
複数の識別子タイプまたはネットワークは、いずれかの要素を繰り返すことで識別できます。
A Global Navigation Satellite System (GNSS) uses orbiting satellites to transmit signals. A Device with a GNSS receiver is able to take measurements from the satellite signals. The results of these measurements can be used to determine time and the location of the Device.
グローバルナビゲーションサテライトシステム（GNSS）は、軌道衛星を使用して信号を送信します。 GNSS受信機を備えたデバイスは、衛星信号から測定を行うことができます。これらの測定結果を使用して、デバイスの時間と場所を特定できます。
Determining location and time in autonomous GNSS receivers follows three steps:
自律GNSS受信機での位置と時間の決定は、3つのステップに従います。
Signal acquisition: During the signal acquisition stage, the receiver searches for the repeating code that is sent by each GNSS satellite. Successful operation typically requires measurement data for a minimum of 5 satellites. At this stage, measurement data is available to the Device.
信号の取得：信号の取得段階では、受信機は各GNSS衛星から送信される繰り返しコードを検索します。通常、運用を成功させるには、最低5つの衛星の測定データが必要です。この段階で、デバイスは測定データを利用できます。
Navigation message decode: Once the signal has been acquired, the receiver then receives information about the configuration of the satellite constellation. This information is broadcast by each satellite and is modulated with the base signal at a low rate; for instance, GPS sends this information at about 50 bits per second.
ナビゲーションメッセージのデコード：信号が取得されると、受信機は衛星コンステレーションの構成に関する情報を受信します。この情報は、各衛星によってブロードキャストされ、低レートでベース信号で変調されます。たとえば、GPSはこの情報を毎秒約50ビットで送信します。
Calculation: The measurement data is combined with the data on the satellite constellation to determine the location of the receiver and the current time.
計算：測定データは、衛星配置に関するデータと組み合わされて、受信機の位置と現在時刻が決定されます。
A Device that uses a GNSS receiver is able to report measurements after the first stage of this process. A LIS can use the results of these measurements to determine a location. In the case where there are fewer results available than the optimal minimum, the LIS might be able to use other sources of measurement information and combine these with the available measurement data to determine a position.
GNSS受信機を使用するデバイスは、このプロセスの最初の段階の後で測定を報告できます。 LISは、これらの測定結果を使用して場所を特定できます。最適な最小値よりも使用可能な結果が少ない場合、LISは他の測定情報ソースを使用し、これらを使用可能な測定データと組み合わせて位置を決定できる場合があります。
Note: The use of different sets of GNSS assistance data can reduce the amount of time required for the signal acquisition stage and obviate the need for the receiver to extract data on the satellite constellation. Provision of assistance data is outside the scope of this document.
注：GNSS支援データの異なるセットを使用すると、信号取得ステージに必要な時間を短縮でき、受信機が衛星群のデータを抽出する必要がなくなります。支援データの提供は、このドキュメントの範囲外です。
Figure 12 shows an example of GNSS measurement data. The measurement shown is for the GPS satellite system and includes measurement data for three satellites only.
図12は、GNSS測定データの例を示しています。表示されている測定値はGPS衛星システムのもので、3つの衛星のみの測定データが含まれています。
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58" timeError="2e-5">
<gnss xmlns="urn:ietf:params:xml:ns:geopriv:lm:gnss"
system="gps" signal="L1">
<sat num="19">
<doppler>499.9395</doppler>
<codephase rmsError="1.6e-9">0.87595747</codephase>
<cn0>45</cn0>
</sat>
<sat num="27">
<doppler>378.2657</doppler>
<codephase rmsError="1.6e-9">0.56639479</codephase>
<cn0>52</cn0>
</sat>
<sat num="20">
<doppler>-633.0309</doppler>
<codephase rmsError="1.6e-9">0.57016835</codephase>
<cn0>48</cn0>
</sat>
</gnss>
</measurements>
Figure 12: Example GNSS Measurement
図12：GNSS測定の例
Each "gnss" element represents a single set of GNSS measurement data, taken at a single point in time. Measurements taken at different times can be included in different "gnss" elements to enable iterative refinement of results.
各「gnss」要素は、単一の時点で取得されたGNSS測定データの単一のセットを表します。異なる時間に行われた測定は、異なる "gnss"要素に含めることができ、結果の反復的な改善を可能にします。
GNSS measurement parameters are described in more detail in the following sections.
GNSS測定パラメーターについては、次のセクションで詳しく説明します。
The GNSS measurement structure is designed to be generic and to apply to different GNSS types. Different signals within those systems are also accounted for and can be measured separately.
GNSS測定構造は、汎用的で、さまざまなGNSSタイプに適用できるように設計されています。これらのシステム内のさまざまな信号も考慮され、個別に測定できます。
The GNSS type determines the time system that is used. An indication of the type of system and signal can ensure that the LIS is able to correctly use measurements.
GNSSタイプは、使用される時間システムを決定します。システムと信号のタイプを示すことで、LISが測定を正しく使用できるようになります。
Measurements for multiple GNSS types and signals can be included by repeating the "gnss" element.
「gnss」要素を繰り返すことにより、複数のGNSSタイプおよび信号の測定値を含めることができます。
This document creates an IANA registry for GNSS types. Two satellite systems are registered by this document: GPS [GPS.ICD] and Galileo [Galileo.ICD]. Details for the registry are included in Section 9.1.
このドキュメントでは、GNSSタイプのIANAレジストリを作成します。このドキュメントでは、GPS [GPS.ICD]とGalileo [Galileo.ICD]の2つの衛星システムが登録されています。レジストリの詳細はセクション9.1に含まれています。
Each set of GNSS measurements is taken at a specific point in time. The "time" attribute is used to indicate the time that the measurement was acquired, if the receiver knows how the time system used by the GNSS relates to UTC time.
GNSS測定の各セットは、特定の時点で取得されます。 「time」属性は、GNSSによって使用される時間システムがUTC時間にどのように関連するかを受信機が知っている場合に、測定が取得された時間を示すために使用されます。
Alternative to (or in addition to) the measurement time, the "gnssTime" element MAY be included. The "gnssTime" element includes a relative time in milliseconds using the time system native to the satellite system. For the GPS satellite system, the "gnssTime" element includes the time of week in milliseconds. For the Galileo system, the "gnssTime" element includes the time of day in milliseconds.
測定時間の代わりに（またはそれに加えて）、「gnssTime」要素を含めることができます（MAY）。 「gnssTime」要素には、衛星システムに固有の時間システムを使用したミリ秒単位の相対時間が含まれます。 GPS衛星システムの場合、「gnssTime」要素には、ミリ秒単位の曜日が含まれます。 Galileoシステムの場合、「gnssTime」要素には、ミリ秒単位の時刻が含まれます。
The accuracy of the time measurement provided is critical in determining the accuracy of the location information derived from GNSS measurements. The receiver SHOULD indicate an estimated time error for any time that is provided. An RMS error can be included for the "gnssTime" element, with a value in milliseconds.
提供される時間測定の精度は、GNSS測定から得られる位置情報の精度を決定する上で重要です。受信者は、提供された任意の時間の推定時間エラーを示す必要があります。 「gnssTime」要素のRMSエラーは、ミリ秒単位の値で含めることができます。
Multiple satellites are included in each set of GNSS measurements using the "sat" element. Each satellite is identified by a number in the "num" attribute. The satellite number is consistent with the identifier used in the given GNSS.
複数の衛星は、「sat」要素を使用してGNSS測定の各セットに含まれています。各衛星は、「num」属性の番号で識別されます。衛星番号は、特定のGNSSで使用されている識別子と一致しています。
Both the GPS and Galileo systems use satellite numbers between 1 and 64.
GPSシステムとGalileoシステムはどちらも1〜64の衛星番号を使用します。
The GNSS receiver measures the following parameters for each satellite:
GNSS受信機は、衛星ごとに次のパラメーターを測定します。
doppler: The observed Doppler shift of the satellite signal, measured in meters per second. This is converted from a value in Hertz by the receiver to allow the measurement to be used without knowledge of the carrier frequency of the satellite system. This value permits the use of RMS error attributes, also measured in meters per second.
ドップラー：衛星信号の観測されたドップラーシフト。メートル/秒で測定されます。これは、受信機によってヘルツ単位の値から変換され、衛星システムの搬送周波数を知らなくても測定を使用できるようになります。この値により、RMSエラー属性を使用できます。これもメートル/秒単位で測定されます。
codephase: The observed code phase for the satellite signal, measured in milliseconds. This is converted from the system-specific value of chips or wavelengths into a system-independent value. Larger values indicate larger distances from satellite to receiver. This value permits the use of RMS error attributes, also measured in milliseconds.
codephase：衛星信号の観測されたコードフェーズ（ミリ秒単位）。これは、チップまたは波長のシステム固有の値からシステムに依存しない値に変換されます。値が大きいほど、衛星から受信機までの距離が長いことを示します。この値は、RMSエラー属性の使用を許可します。これもミリ秒単位で測定されます。
cn0: The signal-to-noise ratio for the satellite signal, measured in decibel-Hertz (dB-Hz). The expected range is between 20 and 50 dB-Hz.
cn0：デシベルヘルツ（dB-Hz）で測定された衛星信号の信号対雑音比。予想される範囲は20〜50 dB-Hzです。
mp: An estimation of the amount of error that multipath signals contribute in meters. This parameter MAY be omitted.
mp：マルチパス信号がメートル単位で寄与するエラー量の推定。このパラメーターは省略してもかまいません。
cq: An indication of the carrier quality. Two attributes are included: "continuous" (which can be either "true" or "false") and "direct" (which can be either "direct" or "inverted"). This parameter MAY be omitted.
cq：キャリア品質の指標。 2つの属性が含まれています：「連続」（「true」または「false」のいずれか）および「直接」（「直接」または「反転」のいずれか）。このパラメーターは省略してもかまいません。
adr: The accumulated Doppler range, measured in meters. This parameter MAY be omitted and is not useful unless multiple sets of GNSS measurements are provided or differential positioning is being performed.
adr：メートル単位で測定された累積ドップラー範囲。このパラメータは省略してもよいし、複数のGNSS測定値のセットが提供されているか、または差分測位が実行されている場合を除いて、役に立ちません。
All values are converted from measures native to the satellite system to generic measures to ensure consistency of interpretation. Unless necessary, the schema does not constrain these values.
すべての値は、衛星システムに固有のメジャーから一般的なメジャーに変換され、解釈の一貫性が確保されます。必要でない限り、スキーマはこれらの値を制約しません。
Measurement requests can include a "gnss" element, which includes the "system" and "signal" attributes. Multiple elements can be included to indicate requests for GNSS measurements from multiple systems or signals.
測定リクエストには、「system」属性と「signal」属性を含む「gnss」要素を含めることができます。複数の要素を含めて、複数のシステムまたは信号からのGNSS測定の要求を示すことができます。
Digital Subscriber Line (DSL) networks rely on a range of network technologies. DSL deployments regularly require cooperation between multiple organizations. These fall into two broad categories: infrastructure providers and Internet service providers (ISPs). For the same end user, an infrastructure and Internet service can be provided by different entities. Infrastructure providers manage the bulk of the physical infrastructure, including cabling. End users obtain their service from an ISP, which manages all aspects visible to the end user, including IP address allocation and operation of a LIS. See [DSL.TR025] and [DSL.TR101] for further information on DSL network deployments and the parameters that are available.
デジタル加入者線（DSL）ネットワークは、さまざまなネットワーク技術に依存しています。 DSLの導入には、定期的に複数の組織間の協力が必要です。これらは、インフラストラクチャプロバイダーとインターネットサービスプロバイダー（ISP）の2つの大きなカテゴリに分類されます。同じエンドユーザーに対して、インフラストラクチャとインターネットサービスを異なるエンティティで提供できます。インフラストラクチャプロバイダーは、ケーブル配線を含む物理インフラストラクチャの大部分を管理します。エンドユーザーは、ISPからサービスを取得します。ISPは、IPアドレスの割り当てやLISの操作など、エンドユーザーに見えるすべての側面を管理します。 DSLネットワークの展開と利用可能なパラメーターの詳細については、[DSL.TR025]と[DSL.TR101]を参照してください。
Exchange of measurement information between these organizations is necessary for location information to be correctly generated. The ISP LIS needs to acquire location information from the infrastructure provider. However, since the infrastructure provider could have no knowledge of Device identifiers, it can only identify a stream of data that is sent to the ISP. This is resolved by passing measurement data relating to the Device to a LIS operated by the infrastructure provider.
位置情報を正しく生成するには、これらの組織間の測定情報の交換が必要です。 ISP LISは、インフラストラクチャプロバイダーから位置情報を取得する必要があります。ただし、インフラストラクチャプロバイダーはデバイス識別子を認識できないため、ISPに送信されるデータストリームしか識別できません。これは、デバイスに関連する測定データをインフラストラクチャプロバイダーが運営するLISに渡すことで解決されます。
The Layer 2 Tunneling Protocol (L2TP) [RFC2661] is a common means of linking the infrastructure provider and the ISP. The infrastructure provider LIS requires measurement data that identifies a single L2TP tunnel, from which it can generate location information. Figure 13 shows an example L2TP measurement.
レイヤー2トンネリングプロトコル（L2TP）[RFC2661]は、インフラストラクチャプロバイダーとISPをリンクする一般的な方法です。インフラストラクチャプロバイダーLISは、単一のL2TPトンネルを識別する測定データを必要とします。これから、ロケーション情報を生成できます。図13に、L2TP測定の例を示します。
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<l2tp>
<src>192.0.2.10</src>
<dest>192.0.2.61</dest>
<session>528</session>
</l2tp>
</dsl>
</measurements>
Figure 13: Example DSL L2TP Measurement
図13：DSL L2TP測定の例
When authenticating network access, the infrastructure provider might employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or Access Node (AN). These messages provide the ISP RADIUS server with an identifier for the DSLAM or AN, plus the slot and port to which the Device is attached. These data can be provided as a measurement that allows the infrastructure provider LIS to generate location information.
ネットワークアクセスを認証するとき、インフラストラクチャプロバイダーは、DSLアクセスモジュール（DSLAM）またはアクセスノード（AN）でRADIUS [RFC2865]プロキシを使用する場合があります。これらのメッセージは、ISP RADIUSサーバーにDSLAMまたはANの識別子、およびデバイスが接続されているスロットとポートを提供します。これらのデータは、インフラストラクチャプロバイダーLISが位置情報を生成できるようにする測定値として提供できます。
The format of the AN, slot, and port identifiers is not defined in the RADIUS protocol. The slot and port together identify a circuit on the AN, analogous to the circuit identifier in [RFC3046]. These items are provided directly, as they would be in the RADIUS message. An example is shown in Figure 14.
AN、スロット、およびポートの識別子の形式は、RADIUSプロトコルでは定義されていません。スロットとポートは、[RFC3046]の回路識別子と同様に、AN上の回路を一緒に識別します。これらの項目は、RADIUSメッセージに含まれるため、直接提供されます。図14に例を示します。
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<an>AN-7692</an>
<slot>3</slot>
<port>06</port>
</dsl>
</measurements>
Figure 14: Example DSL RADIUS Measurement
図14：DSL RADIUS測定の例
For Ethernet-based DSL access networks, the DSLAM or AN provides two VLAN tags on packets. A C-TAG is used to identify the incoming residential circuit, while the S-TAG is used to identify the DSLAM or AN. The C-TAG and S-TAG together can be used to identify a single point of network attachment. An example is shown in Figure 15.
イーサネットベースのDSLアクセスネットワークの場合、DSLAMまたはANはパケットに2つのVLANタグを提供します。 C-TAGは着信住宅回路の識別に使用され、S-TAGはDSLAMまたはANの識別に使用されます。 C-TAGとS-TAGを一緒に使用して、ネットワーク接続の単一ポイントを識別できます。図15に例を示します。
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<stag>613</stag>
<ctag>1097</ctag>
</dsl>
</measurements>
Figure 15: Example DSL VLAN Tag Measurement
図15：DSL VLANタグ測定の例
Alternatively, the C-TAG can be replaced by data on the slot and port to which the Device is attached. This information might be included in RADIUS requests that are proxied from the infrastructure provider to the ISP RADIUS server.
または、C-TAGは、デバイスが接続されているスロットとポートのデータで置き換えることができます。この情報は、インフラストラクチャプロバイダーからISP RADIUSサーバーにプロキシされるRADIUS要求に含まれている可能性があります。
An ATM virtual circuit can be employed between the ISP and infrastructure provider. Providing the virtual port ID (VPI) and virtual circuit ID (VCI) for the virtual circuit gives the infrastructure provider LIS the ability to identify a single data stream. A sample measurement is shown in Figure 16.
ATM仮想回線は、ISPとインフラストラクチャプロバイダーの間で使用できます。仮想回線の仮想ポートID（VPI）と仮想回線ID（VCI）を提供することで、インフラストラクチャプロバイダーLISは単一のデータストリームを識別できます。測定例を図16に示します。
<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
図16：DSL ATM測定の例
Location-related measurement data can be as privacy sensitive as location information [RFC6280].
位置関連の測定データは、位置情報と同様にプライバシーに配慮する必要があります[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 Transport Layer Security (TLS) MUST be used in order to convey measurement data over HELD [RFC5985]. Other protocols MUST provide comparable guarantees.
位置関連の測定データの主題のプライバシーを保護するために、測定データは位置情報と同じ程度の保護で保護されなければなりません。 HELD [RFC5985]を介して測定データを伝達するために、トランスポート層セキュリティ（TLS）によって提供される機密性と認証を使用する必要があります。他のプロトコルは同等の保証を提供しなければなりません。
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 in the role of both Rule Maker and Location Server.
この単純なモデルでは、デバイスは測定データを配信できる唯一のエンティティです。 GEOPRIVアーキテクチャーからの類推を使用するには、ロケーションジェネレーターまたは測定データジェネレーターとしてのデバイスが、ルールメーカーとロケーションサーバーの両方の役割を果たすことができる唯一のエンティティです。
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 regarding 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.
GEOPRIVモデル[RFC6280]は、ルールメーカーが提供する方向を使用してターゲットの場所を保護します。測定データの分布のために、このモデルはHELD [RFC5985]のセクション3で行われた仮定に依存しています。これらの仮定は、デバイスがターゲットメーカーとルールメーカーの両方のプロキシであることを効果的に宣言します。
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.
LISは、位置関連の測定データを他のエンティティに開示してはなりません。 LISは、デバイスから指示されない限り、測定データに基づく位置情報を他のエンティティに公開してはなりません。
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.
位置情報の要求に測定データを追加することにより、デバイスは暗黙的にLISに測定データを使用して要求された位置情報を生成する許可を与えます。このデータを他の目的で使用することを許可するものではありません。
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.
測定データがそれを含むリクエストの処理にのみ使用される限り、データ保持に関するルールは必要ありません。 LISは、デバイスが他の目的でその情報を使用する許可を与えない限り、要求に応じた後、位置関連の測定データを破棄する必要があります。
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.
LISは、デバイスが提供する測定データを使用して、デバイスが許可している場合、ロケーションURIへのリクエストを処理できます。デバイスは、ロケーションURIを明示的に要求する要求に測定データを含めることでこれを許可します。デバイスは、ロケーションURIを要求することにより、LISがそのロケーションURIへの要求を処理する際に測定データを使用することを許可します。セクション6.1で定義されているように、LISはロケーション受信者に測定データを提供できません。
Note: In HELD, the "any" type is not an explicit request for a location URI, though a location URI might be provided.
注：HELDでは、「any」タイプはロケーションURIの明示的な要求ではありませんが、ロケーションURIが提供される場合があります。
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.
この方法で提供される測定データの有用性は限られています。測定データは、デバイスによって取得されたときのみ有効です。ロケーションURIにリクエストが送信されたときに、デバイスが移動し、測定データが正しくない可能性があります。
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.
デバイスは、有効期限を測定データに追加することにより、LISが測定データを保持する時間を明示的に制限できます。 LISは、「expires」属性（セクション4.1.2）で指定された時間を超えて、ロケーション関連の測定データをメモリ、ストレージ、またはログに保持してはなりません（MUST NOT）。 「expires」属性がない場合、LISは測定データを保持してはならない（MUST NOT）。
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.
デバイス（[RFC6155]を参照）の場所の承認されたサードパーティ要求には、場所関連の測定データを含めることができます。これは、サードパーティがデバイスについて観察できる場合に可能です。
A third party that provides measurement data MUST be authorized to provide the specific measurement for the identified Device. Either a third party MUST 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.
測定データを提供する第三者は、識別されたデバイスの特定の測定を提供することを許可されなければなりません。提供されたタイプの測定データを提供する目的でLISが第三者を信頼する必要があるか、または使用する前に測定データを検証する必要があります（セクション7.2.1を参照）。
How a third party authenticates its identity or gains authorization to use measurement data is not covered by this document.
第三者がIDを認証する方法、または測定データの使用を承認する方法は、このドキュメントでは扱いません。
The use of location-related measurement data has privacy considerations that are discussed in Section 6.
ロケーション関連の測定データの使用には、セクション6で説明するプライバシーに関する考慮事項があります。
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:
ロケーション関連の測定データを提供するデバイスは、データを使用して以下を行うことができます。
o acquire the location of another Device, without authorization;
o 許可なしに別のデバイスの場所を取得する。
o extract information about network topology; or
o ネットワークトポロジーに関する情報を抽出します。または
o coerce the LIS into providing falsified location information based on the measurement data.
o LISを強制して、測定データに基づいて改ざんされた位置情報を提供します。
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.
ロケーション関連の測定データは、デバイスの物理環境またはネットワーク接続を記述します。デバイスの近くにいる第三者の攻撃者は、デバイスが第三者によって制御される測定データを提供するように、物理環境を変更できる可能性があります。これは、測定データから得られる位置情報を間接的に制御するために使用される場合があります。
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] allow other entities to be authorized, conditional on a Rule Maker providing sufficient authorization.
ロケーション要求の承認を要求することは、ロケーションプロトコルのプライバシー保護の重要な部分です。ロケーション構成プロトコルは通常、リクエスターが独自のロケーションを取得できるようにする制限付きポリシーの下で動作します。 HELDアイデンティティ拡張[RFC6155]は、十分な承認を提供するルールメーカーを条件として、他のエンティティを承認できるようにします。
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.
これらの保護の目的は、ロケーション受信者がロケーション情報を取得することを許可されていることを確認することです。攻撃者は、位置関連の測定データを使用して、測定データとターゲットデバイス間の関連付けが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.
LISは、ロケーション受信者が受信を許可されていないデバイスにロケーション情報を提供するように強制できます。要求は1つのデバイスを（暗黙的または明示的に）識別しますが、測定データは別のデバイスに提供されます。 LISが測定データが識別されたデバイスのものであることを確認しない場合、誤ってリクエストを承認する可能性があります。
By using unverified measurement data to generate a response, the LIS provides information about a Device without appropriate authorization.
検証されていない測定データを使用して応答を生成することにより、LISは適切な許可なしにデバイスに関する情報を提供します。
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 (Section 5.1) are
この攻撃の実現可能性は、デバイスと測定データをリンクする情報の可用性に依存します。場合によっては、ターゲットに関連付けられた測定データがすぐに利用できます。たとえば、LLDP測定（セクション5.1）は
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 (Section 5.5) share this trait with many wireless location determination methods.
一部のタイプの測定データでは、使用する測定を決定するために、攻撃者がターゲットの場所を知る必要があります。この攻撃は、測定データを取得または作成する前に攻撃者が最初にターゲットの場所を知る必要がある種類の測定データには意味がありません。 GNSS測定（セクション5.5）は、この特性を多くのワイヤレス位置特定方法と共有しています。
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.
測定が有効である必要はありません。測定値の使用を試行することに関連するペナルティまたはコストがなければ、ランダムな推測で十分です。
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.
デバイスは、そのネットワークの外部にあるLISに位置測定データを提供する場合、そのネットワークの外部のエンティティにネットワークに関する情報を公開する可能性があります。 GNSS測定を除いて、このドキュメントの測定は、不正な受信者にトポロジー情報を明らかにする可能性があるアクセスネットワークに関する情報を提供します。
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.
デバイスは、受信者が承認されているという明確な信号なしに、ネットワークトポロジに関する情報を提供してはなりません（MUST NOT）。 LIS検出[RFC5986]で説明されているようにDHCPを使用して検出されたLISは、アクセスネットワークに関する情報を受信することを許可されていると見なすことができます。
Location information, which includes measurement data, is a function of its inputs. Thus, falsified measurement data can be used to alter the location information that is provided by a LIS.
測定データを含む位置情報は、その入力の関数です。したがって、改ざんされた測定データを使用して、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].
一部のタイプの測定データは、結果の位置情報がほとんどまたはまったくエラーなしで選択されるように、比較的簡単に改ざんできます。たとえば、GNSS測定はこの目的で簡単に使用できます。これは、測定を使用して位置を計算するために必要なすべてのコンテキスト情報が衛星[HARPER]によってブロードキャストされるためです。
An attacker that falsifies measurement data gains little if they are the only recipient 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.
測定データを改ざんする攻撃者は、結果の唯一の受信者である場合、ほとんど効果がありません。攻撃者は、位置情報が悪いことを知っています。攻撃者は、情報が別の場所の受信者によって何らかの形でLISに起因している場合にのみ獲得します。偽造された位置情報を提供するようにLISを強制することにより、LISが持っている可能性がある信頼性（攻撃者にはない）が攻撃者によって取得されます。
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.
位置情報の完全性に依存しているサードパーティは、情報の信頼性の評価を情報源に基づいている可能性があります。そのサードパーティが位置情報をLISに帰することができる場合、攻撃者はそれを得る可能性があります。
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.
ソースとしてLISを識別する手段なしにデバイスに提供される位置情報は、この攻撃の対象ではありません。デバイスは、ロケーション情報をロケーション受信者に配布するときに、データのソースとして識別されます。
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.
ロケーション情報は、デジタル署名を使用するか、ロケーションの受信者にLISと直接対話させることにより、LISに帰属します。位置情報にデジタル署名するLISは、データのソースとして識別可能になります。同様に、ロケーション受信者がロケーションURIを使用してLISから直接情報を取得する場合、LISはデータのソースとして識別されます。
The values of some measured properties do not change over time for a single location. The time invariance of network properties is often a direct 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.
一部の測定されたプロパティの値は、1つの場所について時間の経過とともに変化しません。多くの場合、ネットワークプロパティの時間の不変性は、ネットワークの運用の実用性の直接的な結果です。ネットワークへの変更を制限することで、サービスの一貫性が向上します。ほぼ静的なネットワークは、位置情報サービスの提供に関連するデータ管理タスクも大幅に簡素化します。
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 a 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.
たとえば、無線送信機のIDは、その送信機によってブロードキャストされた場合、収集して保存できます。特定の場所に存在することを知らせたい攻撃者は、いつでもこのトランスミッタを監視すると主張することができます。主張に内在するものは何もそれが偽であることを明らかにしません。
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 a Device or LIS. Measurement that is passive -- where the Device observes a signal or other phenomenon without direct interaction -- is most susceptible to alteration by third parties.
この方法で環境を変更する場合、デバイスまたはLISの関与は必要ありません。パッシブな測定-デバイスが直接的な相互作用なしに信号またはその他の現象を観測する測定-は、第三者による変更の影響を最も受けやすくなります。
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]).
敵はデバイスの一般的な近くにいて、信号を送信できる必要があるだけなので、無線信号特性の測定は特に脆弱です。たとえば、GNSSスプーファーは、任意の衛星または衛星のセットによって送信されると主張する偽の信号を生成することができます（[GPS.SPOOF]を参照）。
Measurements that require direct interaction increase 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.
相互作用するエンティティが認証された場合でも、測定データの完全性については保証されません。たとえば、デバイスは暗号化手段を使用して無線送信機のIDを認証し、その送信機の信号強度測定値を取得する場合があります。攻撃者が生の信号を受信して増幅するだけで無線信号の強度を上げることは簡単です。攻撃者が信号の内容を理解できる必要はありません。
Note: This particular "attack" is more often completely legitimate. Radio repeaters are a 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.
デバイスが測定データから導出された位置情報の唯一の受信者である場合、LISは検証なしで位置情報を提供することを選択できます。測定データの信憑性を確保する責任はデバイスにあります。
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.
この種の影響を受けやすい測定データは、ロケーションの受信者がロケーション情報をLISに帰属させる可能性がある場合に、信頼できないデバイスによって生成されたものとして扱われる必要があります。 GNSS測定と無線信号強度測定は比較的安価に影響を受ける可能性がありますが、他のほとんどすべての測定タイプは、攻撃者にとってさまざまなコストで影響を受ける可能性があり、最大のコストは物理アクセスの要件であることがよくあります。可能な限り、測定データは、測定の改ざんに依存する他のタイプの攻撃と同じ検証を受ける必要があります。
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.
注：変更された測定データは、変更を認識していないデバイスによって提供される場合があります。したがって、他の方法で信頼されたデバイスは、測定データの信頼できないソースである可能性があります。
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:
信頼できない測定データを処理するための2つの一般的なアプローチが確認されています。
1. Require independent validation of measurement data or the location information that is produced.
1. 生成された測定データまたは位置情報の独立した検証が必要です。
2. Identify the types of sources that provided the measurement data from which that location information was derived.
2. その位置情報の導出元である測定データを提供したソースのタイプを特定します。
This section goes into more detail on the different forms of validation in Sections 7.2.1, 7.2.2, and 7.2.3. The impact of attributing location information to sources is discussed in more detail in Section 7.2.4.
このセクションでは、セクション7.2.1、7.2.2、および7.2.3のさまざまな形式の検証について詳しく説明します。位置情報をソースに帰属させることの影響については、セクション7.2.4で詳しく説明します。
Any costs in validation are balanced against the degree of integrity desired from the resulting location information.
検証にかかるコストは、結果として得られる位置情報から求められる完全性の程度とバランスが取れています。
Recognizing 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).
測定データの信憑性を個別に確認することにより、測定が正確であり、正しいデバイスに適用されることが保証されます。過度の費用をかけずに信頼できる独立したソースから同じ測定データを収集できる場合、LISは信頼できないデバイスが送信したものの代わりに信頼できるデータを使用できます。それが実際的でない場合、信頼できないデータは、データの裏付けを可能にするヒントを提供する可能性があります（セクション7.2.1.1を参照）。
Measurement information might not contain any inherent indication that it is falsified. In addition, 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.
測定情報には、それが改ざんされているという固有の表示が含まれていない場合があります。さらに、測定デバイスが物理的に特定の場所にあるという保証をある程度提供する情報を取得することは難しい場合があります。検証が難しい測定では、使用する前に他の形式の保証が必要です。
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.
セクション7.1.1で説明されているように、特定のデバイスの測定データを不正な場所の受信者が簡単に取得できる場合は、測定検証を使用する必要があります。これにより、測定データを使用した位置情報への不正アクセスを防止します。
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.
測定データの検証は、データを個別に取得するよりもはるかに効果的です。たとえば、大規模なイーサネットネットワークのデバイスは、LLDP測定を使用して、接続点を示す測定値を提供できます。 LISの場合、同じ測定データを取得するには、そのネットワーク内のすべてのスイッチへの要求が必要になる場合があります。検証では、測定データを使用して、特定のクエリで特定されたスイッチをターゲットにできます。
Validation is effective in identifying falsified measurement data (Section 7.1.4), including attacks involving replay of measurement data (Section 7.1.5). Validation also limits the amount of network topology information (Section 7.1.2) made available to Devices to that portion of the network topology to which they are directly attached.
検証は、測定データの再生を伴う攻撃（セクション7.1.5）を含む、偽造された測定データ（セクション7.1.4）を識別するのに効果的です。検証では、デバイスが利用できるネットワークトポロジ情報（セクション7.1.2）の量を、デバイスが直接接続されているネットワークトポロジのその部分に制限します。
Measurement validation has no effect if the underlying environment is being altered (Section 7.1.6).
基礎となる環境が変更されている場合、測定の検証は効果がありません（セクション7.1.6）。
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 easy 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.
他のエンティティが同じ測定を行うことができない限り、測定が正しく、デバイスに適用可能であることを個別に確認できる他のエンティティもありません。 LISは、一意のオブザーバーから受け取った測定データのすべてまたは一部を検証できない場合があります。たとえば、電波塔からの信号の信号強度測定値を直接検証することはできません。
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 (Section 7.1.1) are largely ineffectual against a unique observer.
デバイスをユニークなオブザーバーとして持つことの利点は、デバイスの支援なしに攻撃者が測定値を取得することが困難になることです。測定を使用して測定データに無許可でアクセスしようとする試み（セクション7.1.1）は、一意の観測者に対してはほとんど効果がありません。
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.
信頼できる位置情報は、信頼できる測定データのソースを使用して取得されます。信頼できない場所の情報は、デバイスを含む信頼できないソースから提供される測定データを使用して取得されます。これら2つの場所が比較されます。信頼できない場所が信頼できる場所と一致する場合、信頼できない場所の情報が使用されます。
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.
正確性や信頼性の低い場所を使用しても意味がありません。信頼できる情報よりも精度が低い信頼できない位置情報は、すぐに破棄できます。正確性、不確実性、通貨が最も重要であることに影響する複数の要因があります。位置情報を正確に比較する方法は、このドキュメントでは定義されていません。
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 (Section 7.2.1.2).
場所の検証は、特に一意のオブザーバー（セクション7.2.1.2）の場合、入力の検証よりも効率的です。
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.
場所を検証することで、デバイスが結果の場所またはその近くにあることを確認します。ロケーション検証を使用して、このドキュメントで識別されているすべての攻撃を制限または防止できます。
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 an uncertainty region with a radius of five kilometers. 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.
たとえば、信頼できる場所は、半径5キロメートルの不確実な領域を示す場合があります。より大きな領域内の100メートルの不確実性を表す信頼できない場所は、より正確なものとして受け入れられる場合があります。攻撃者は依然として、測定データを改ざんして、より大きな不確実性領域内の任意の場所を選択する可能性があります。報告された100メートルの不確実性はより正確に思えますが、改ざんされた場所は5キロメートルの領域のどこかにある可能性があります。
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 information could be combined with trusted location information using different weightings, based on a value set in local policy.
測定データが改ざんされている可能性がある場合、実際の不確実性は事実上はるかに高くなります。ローカルポリシーでは、信頼できない測定データから派生した位置情報に対してさまざまな程度の信頼を許可する場合があります。これはブール演算であり、結果は2つしかありません。信頼できない位置情報が完全に使用されるか、まったく使用されない可能性があります。または、ローカルポリシーで設定された値に基づいて、異なる重み付けを使用して、信頼できない場所情報を信頼できる場所情報と組み合わせることができます。
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 measurement data from 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.
たとえば、無線信号の属性を測定するデバイスは、測定された無線信号のサンプルを提供するように要求されることもあります。 LISが同じ信号を観測できる場合、2つの観測を比較できます。デバイスが信号を事前に予測できない場合、これはデバイスが信号を受信できるという主張をサポートするために使用できます。したがって、デバイスは信号が送信される範囲内にある可能性があります。 LISはこれを使用して、関連付けられた測定データまたは結果の場所に、より高いレベルの信頼を与えることができます。
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.
サポートする観測の使用は、これらの観測を取得して検証するLISの機能によって制限されます。測定データとは無関係に観測を選択することの利点は、LISとデバイスの両方でデータがどれだけ容易に利用できるかに基づいて観測を選択できることです。データの量と質は、必要な保証の程度に基づいて選択できます。
The 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. The applicability of each method is similar.
サポートする観測の使用は、測定の検証と場所の検証の両方に似ています。 3つの方法はすべて、1つ以上のプロパティの独立した検証に依存しています。各方法の適用性は似ています。
The use of supporting observations can be used to limit or prevent all of the attacks identified in this document.
サポート観測の使用は、このドキュメントで識別されたすべての攻撃を制限または防止するために使用できます。
The effectiveness of the validation method depends on the quality of the supporting observation: how hard it is for the entity performing the validation to obtain the data 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.
追加のサポート観測を要求すると、攻撃者が位置情報を変更できる領域のサイズを小さくしたり、結果に対する信頼を高めることができますが、追加の測定ごとに取得コストがかかります。デバイスの位置を決定するという主な目的に対して、サポートする観測はほとんどまたはまったく貢献しません。
Lying by proxy (Section 7.1.4) 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.
プロキシによる嘘（セクション7.1.4）は、ロケーションの受信者がLISにロケーション情報を関連付けることができることに依存しています。ロケーション情報が特定のソースに明示的に起因している場合、この攻撃の効果は無効になります。
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 of identification information, even if it were available and usable.
測定データのすべてのソースに認証済みIDを含めることは、技術的および運用上の多くの課題を提示します。 LISがデバイスと一時的な関係を持つ可能性があります。デバイスはLISと認証情報を共有することは想定されていません。潜在的な場所の受信者がデバイスの識別情報を使用できるという保証はありません。プライバシーの問題により、利用可能で使用可能であっても、識別情報の共有が妨げられる可能性があります。
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.
測定ソースのタイプを識別すると、ロケーションの受信者は、各ソースの認証済みID情報に依存することなく、ロケーション情報の信頼性について決定を下すことができます。この目的のための要素は、セクション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 labeled with the source of that data.
信頼できないソースからの測定データに基づく位置情報を含める場合、LISは信頼できる測定データのソースから派生した代替の位置情報を含める必要があります（SHOULD）。次に、位置情報の各アイテムに、そのデータのソースでラベルを付けることができます。
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 entity or to both entities. The location recipient is then better able to make decisions about trustworthiness based on the source of the data.
測定データの特定のソース（LISでもデバイスでも）を識別できるロケーション受信者は、この情報を使用して、ロケーション情報をいずれかのエンティティまたは両方のエンティティに関連付けることができます。これにより、場所の受信者は、データのソースに基づいて信頼性についてより適切に決定できます。
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].
「ソース」要素を理解していない場所の受信者は、この区別を行うことができません。 [RFC5491]のルール＃8に従って、信頼できない位置情報よりも高い優先順位が与えられるように、PIDF-LOドキュメントを構築する場合、信頼できる位置情報をPIDF-LOに配置する必要があります。
Attribution of information does nothing to address attacks that alter the observed parameters that are used in location determination (Section 7.1.6).
情報の帰属は、場所の決定に使用される観測されたパラメーターを変更する攻撃に対処するためには何もしません（セクション7.1.6）。
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).
リクエストのステートフルな検査を使用して、デバイスがロケーション情報のリクエストを使用してネットワークトポロジをマップしようとするのを防ぐことができます（セクション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.
単一のデバイスからのリクエストのレートを制限するだけで、ネットワークトポロジーに関してデバイスが取得できるデータの量が減少します。 LISは、デバイスの動きについて観察することもできます。トポロジ情報を収集しようとしているデバイスには、後続のリクエスト間で大幅に変化する場所が割り当てられている可能性が高く、速度と加速に関して物理法則（または可能性が低い下限）に違反している可能性があります。
A compromised LIS, or a compromise in LIS discovery [RFC5986], could lead to an unauthorized entity obtaining measurement data. This information could then be used or redistributed. A Device MUST ensure that it authenticates a LIS, as described in Section 9 of [RFC5985].
侵害されたLIS、またはLIS発見の侵害[RFC5986]は、不正なエンティティが測定データを取得する可能性があります。その後、この情報を使用または再配布できます。 [RFC5985]のセクション9で説明されているように、デバイスはLISを認証する必要があります。
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 (Section 7.1.2).
測定データを取得できるエンティティは、それらの測定値を使用してデバイスの場所を知ることに加えて、その情報を他の目的に使用することもできます。この情報を使用して、ネットワークトポロジーに関する情報を提供できます（セクション7.1.2）。
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.
測定データは他の方法で悪用される可能性もあります。たとえば、デバイスが使用する802.11トランシーバーのタイプを明らかにすると、攻撃者は特定の脆弱性を使用してデバイスを攻撃できるようになります。同様に、ネットワーク要素に関する情報を明らかにすると、そのインフラストラクチャに対する標的型攻撃が可能になる可能性があります。
The schemas are broken up into their respective functions. A base container schema into which all measurements are placed is defined, including the definition of a measurement request (Section 8.1). A PIDF-LO extension is defined in a separate schema (Section 8.2). A basic Types Schema contains common definitions, including the "rmsError" and "samples" attributes, plus types for IPv4, IPv6, and MAC addresses (Section 8.3). Each of the specific measurement types is defined in a separate schema.
スキーマはそれぞれの機能に分割されます。すべての測定が配置される基本コンテナースキーマが定義されます（測定要求の定義を含む）（セクション8.1）。 PIDF-LO拡張は、別のスキーマで定義されています（セクション8.2）。基本的なタイプスキーマには、「rmsError」や「samples」属性などの一般的な定義に加えて、IPv4、IPv6、およびMACアドレスのタイプが含まれています（セクション8.3）。特定の測定タイプのそれぞれは、個別のスキーマで定義されます。
<?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.rfc-editor.org/rfc/rfc7105.txt">
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
測定コンテナスキーマ
<?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.rfc-editor.org/rfc/rfc7105.txt">
This schema defines an extension to PIDF-LO that indicates
the type of measurement 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
測定ソースPIDF-LO拡張スキーマ
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.rfc-editor.org/rfc/rfc7105.txt">
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 Types 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.rfc-editor.org/rfc/rfc7105.txt">
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
LLDP測定スキーマ
<?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.rfc-editor.org/rfc/rfc7105.txt">
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
DHCP測定スキーマ
<?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.rfc-editor.org/rfc/rfc7105.txt">
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 an 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
WiFi測定スキーマ
<?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.rfc-editor.org/rfc/rfc7105.txt">
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
セルラー測定スキーマ
<?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.rfc-editor.org/rfc/rfc7105.txt">
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
GNSS測定スキーマ
<?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.rfc-editor.org/rfc/rfc7105.txt">
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
DSL測定スキーマ
This section creates a registry for GNSS types (Section 5.5) and registers the namespaces and schemas defined in Section 8.
このセクションでは、GNSSタイプ（セクション5.5）のレジストリを作成し、セクション8で定義された名前空間とスキーマを登録します。
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.
このドキュメントでは、「グローバルナビゲーションサテライトシステム（GNSS）」タイプの新しいIANAレジストリを確立します。レジストリには、GNSSタイプおよびそのタイプ内の各信号のトークンが含まれています。 [RFC5226]を参照すると、このレジストリは「必要な仕様」のルールの下で動作します。 IESGは、新しいまたは更新されたGNSSタイプのリクエストごとにIANAに助言するエキスパートレビューアを任命します。
Each entry in the registry requires the following information:
レジストリの各エントリには、次の情報が必要です。
GNSS Name: the name of the GNSS
GNSS名：GNSSの名前
Brief Description: a brief description of the GNSS
簡単な説明：GNSSの簡単な説明
GNSS Token: a token that can be used to identify the GNSS
GNSSトークン：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
ドキュメンテーションリファレンス：GNSSの使用法を概説する1つ以上の安定した公開仕様への参照。
The registry initially includes two registrations:
レジストリには、最初に2つの登録が含まれています。
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名：全地球測位システム（GPS）簡単な説明：スペクトル拡散送信を使用する衛星のシステム。商用および軍事用に米軍が運用しています。
GNSS Token: gps
Ｇんっｓ とけん： ｇｐｓ
Signals: L1, L2, L1C, L2C, L5
信号：L1、L2、L1C、L2C、L5
Documentation Reference: Navstar GPS Space Segment/Navigation User Interface [GPS.ICD]
ドキュメントリファレンス：Navstar GPSスペースセグメント/ナビゲーションユーザーインターフェイス[GPS.ICD]
GNSS Name: Galileo
GNSS名：ガリレオ
Brief Description: a system of satellites that operate in the same spectrum as GPS, operated by the European Union for commercial applications
簡単な説明：GPSと同じスペクトルで動作する衛星システム。商用利用のために欧州連合が運営しています。
GNSS Token: galileo
GNSSトークン：galileo
Signals: L1, E5A, E5B, E5A+B, E6
信号：L1、E5A、E5B、E5A + B、E6
Documentation Reference: Galileo Open Service Signal In Space Interface Control Document (SIS ICD) [Galileo.ICD]
ドキュメントリファレンス：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
This section registers a new XML namespace, "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：pidf：geopriv10：lmsrc」を登録します。
URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Measurement Source for PIDF-LO</title>
</head>
<body>
<h1>Namespace for Location Measurement Source</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：geopriv：lm」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:lm
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Measurement Container</title>
</head>
<body>
<h1>Namespace for Location Measurement Container</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END
9.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:basetypes
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：geopriv：lm：basetypes」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
URI：urn：ietf：params：xml：ns：geopriv：lm：basetypes登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Base Device Types</title>
</head>
<body>
<h1>Namespace for Base Types</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:basetypes</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END
9.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:lldp
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in [RFC3688].
このセクションは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：geopriv：lm：lldp」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:lm:lldp
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
XML:
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>LLDP Measurement Set</title>
</head>
<body>
<h1>Namespace for LLDP Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:lldp</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END
9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：geopriv：lm：dhcp」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>DHCP Measurement Set</title>
</head>
<body>
<h1>Namespace for DHCP Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:dhcp</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END
9.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：geopriv：lm：wifi」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:lm:wifi Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
URI：urn：ietf：params：xml：ns：geopriv：lm：wifi登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>WiFi Measurement Set</title>
</head>
<body>
<h1>Namespace for WiFi Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:wifi</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END
9.8. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:cell
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：geopriv：lm：cell」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:lm:cell
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
XML:
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>Cellular Measurement Set</title>
</head>
<body>
<h1>Namespace for Cellular Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:cell</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END
9.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：geopriv：lm：gnss」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:lm:gnss
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GNSS Measurement Set</title>
</head>
<body>
<h1>Namespace for GNSS Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:gnss</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END
9.10. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dsl
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：geopriv：lm：dsl」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:lm:dsl Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
URI：urn：ietf：params：xml：ns：geopriv：lm：dsl登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>DSL Measurement Set</title>
</head>
<body>
<h1>Namespace for DSL Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:dsl</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
Schema: The XML for this schema can be found in Section 8.2 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション8.2にあります。
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:lm
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
Schema: The XML for this schema can be found in Section 8.1 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション8.1にあります。
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:lm:basetypes
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
Schema: The XML for this schema can be found in Section 8.3 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション8.3にあります。
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:lm:lldp
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
Schema: The XML for this schema can be found in Section 8.4 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション8.4にあります。
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:lm:dhcp
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
Schema: The XML for this schema can be found in Section 8.5 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション8.5にあります。
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:lm:wifi
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
Schema: The XML for this schema can be found in Section 8.6 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション8.6にあります。
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:lm:cell
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
Schema: The XML for this schema can be found in Section 8.7 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション8.7にあります。
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:lm:gnss
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
Schema: The XML for this schema can be found in Section 8.8 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション8.8にあります。
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:lm:dsl
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@gmail.com）。
Schema: The XML for this schema can be found in Section 8.9 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション8.9にあります。
Thanks go to Simon Cox for his comments relating to terminology; his comments 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 and Darren Pawson provided expert LTE knowledge.
用語に関するコメントを寄せてくれたSimon Coxに感謝します。彼のコメントは、このドキュメントがOpen Geospatial Consortium（OGC）で進行中の作業と整合するようにするのに役立ちました。このドキュメントのGNSSセクションに関するレビューとコメントをくれたNeil Harperに感謝します。 802.11の測定値への重要な情報の入力と改善のためのアドバイスを提供してくれたNoor-E-Gagan Singh、Gabor Bajko、Russell Priebe、およびKhalid Al-Muftiに感謝します。フィードバックと提案をしてくれたCullen Jenningsに感謝します。 Bernard Abobaは、一連の測定データ定義についてレビューとフィードバックを提供しました。 Mary BarnesとGeoff Thompsonがレビューと修正を提供しました。 David WaitzmanとJohn Bresslerはどちらも、802.11測定の欠点を指摘しました。 Keith DrageとDarren Pawsonは、LTEの専門知識を提供しました。
[ASCII] ANSI, "US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986", 1986.
[ASCII] ANSI、「US-ASCII。コード化文字セット-情報交換のための7ビットのアメリカ標準コード。標準ANSI X3.4-1986」、1986。
[GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface", ICD GPS-200, April 2000.
[GPS.ICD]「Navstar GPS Space Segment / Navigation User Interface」、ICD GPS-200、2000年4月。
[Galileo.ICD] GJU, "Galileo Open Service Signal In Space Interface Control Document (SIS ICD)", May 2006.
[Galileo.ICD] GJU、「Galileo Open Service Signal In Space Interface Control Document（SIS ICD）」、2006年5月。
[IANA.enterprise] IANA, "Private Enterprise Numbers", 2014, <http://www.iana.org/assignments/enterprise-numbers>.
[IANA.enterprise] IANA、 "Private Enterprise Numbers"、2014、<http://www.iana.org/assignments/enterprise-numbers>。
[IEEE.80211] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2012, March 2012.
[IEEE.80211] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2012, March 2012.
[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.8021AB] IEEE、「IEEE Standard for Local and Metropolitan Area Networks、Station and Media Access Control Connectivity Discovery」、IEEE Std 802.1AB-2009、2009年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[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.
[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.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[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.
[RFC3993] Johnson、R.、Palaniappan、T。、およびM. Stapp、「動的ホスト構成プロトコル（DHCP）リレーエージェントオプションのサブスクライバーIDサブオプション」、RFC 3993、2005年3月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「A Presence-based GEOPRIV Location Object Format」、RFC 4119、2005年12月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June 2006.
[RFC4580] Volz、B。、「IPv6の動的ホスト構成プロトコル（DHCPv6）リレーエージェントサブスクライバIDオプション」、RFC 4580、2006年6月。
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
[RFC4649] Volz、B。、「IPv6の動的ホスト構成プロトコル（DHCPv6）リレーエージェントリモートIDオプション」、RFC 4649、2006年8月。
[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.
[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「GEOPRIV Presence Information Data Format Location Object（PIDF-LO）Usage Clarification、Considerations、and Recommendations」、RFC 5491、2009年3月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[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.
[RFC5985] Barnes、M。、「HTTP-Enabled Location Delivery（HELD）」、RFC 5985、2010年9月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986] Thomson、M.およびJ. Winterbottom、「Discovering the Local Location Information Server（LIS）」、RFC 5986、2010年9月。
[TIA-2000.5] TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for cdma2000(R) Spread Spectrum Systems", TR-45.5 / TSG-C TIA-2000.5-E / C.S0005-E v1.0, September 2009.
[TIA-2000.5] TIA / EIA、「cdma2000（R）スペクトラム拡散システムの上位層（レイヤー3）信号規格」、TR-45.5 / TSG-C TIA-2000.5-E / C.S0005-E v1.0、 2009年9月。
[TS.3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 12.0.0, September 2013, <http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.
[TS.3GPP.23.003] 3GPP、「番号付け、アドレス指定および識別」、3GPP TS 23.003 12.0.0、2013年9月、<http://www.3gpp.org/ftp/Specs/html-info/23003.htm> 。
[ANSI-TIA-1057] ANSI/TIA, "Link Layer Discovery Protocol for Media Endpoint Devices", TIA 1057, April 2006.
[ANSI-TIA-1057] ANSI / TIA、「Link Endpoint Discovery Protocol for Media Endpoint Devices」、TIA 1057、2006年4月。
[DSL.TR025] Wang, R., "Core Network Architecture Recommendations for Access to Legacy Data Networks over ADSL", September 1999.
[DSL.TR025] Wang、R。、「ADSLを介したレガシーデータネットワークへのアクセスに関するコアネットワークアーキテクチャの推奨事項」、1999年9月。
[DSL.TR101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL Aggregation", April 2006.
[DSL.TR101] Cohen、A。およびE. Shrum、「Migration to Ethernet-Based DSL Aggregation」、2006年4月。
[GPS.SPOOF] Scott, L., "Anti-Spoofing and Authenticated Signal Architectures for Civil Navigation Signals", ION-GNSS Portland, Oregon, 2003.
[GPS.SPOOF]スコット、L。、「民間ナビゲーション信号のスプーフィング防止および認証済み信号アーキテクチャ」、ION-GNSSポートランド、オレゴン、2003年。
[HARPER] Harper, N., "Server-side GPS and Assisted-GPS in Java", December 2009.
[HARPER] Harper, N., "Server-side GPS and Assisted-GPS in Java", December 2009.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]タウンズリー、W。、バレンシア、A。、ルーベンス、A。、ポール、G。、ゾーン、G。、およびB.パルター、「レイヤー2トンネリングプロトコル "L2TP"」、RFC 2661、1999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 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.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, March 2011.
[RFC6155] Winterbottom、J.、Thomson、M.、Tschofenig、H。、およびR. Barnes、「Use-Device Identity in HTTP-Enabled Location Delivery（HELD）」、RFC 6155、2011年3月。
[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.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月。
Authors' Addresses
著者のアドレス
Martin Thomson Mozilla Suite 300 650 Castro Street Mountain View, CA 94041 US
Martin Thomson Mozilla Suite 300 650 Castro Street Mountain View, CA 94041 US
EMail: martin.thomson@gmail.com
James Winterbottom Unaffiliated AU
ジェームズウィンターボトムアフィリエイトオーストラリア
EMail: a.james.winterbottom@gmail.com