SKELETON - ETSI
ETSI TS 103 246-4 V0.0.6 (2015-09)
Satellite Earth Stations and Systems (SES);
GNSS-based Location Systems;
Part 4: Requirements for Location Data Exchange Protocols
<
TECHNICAL SPECIFICATION
Reference
DTS/SES-00348
Keywords
GNSS, location, MSS, navigation, performance, receiver, satellite, system, terminal
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at
If you find errors in the present document, please send your comment to one of the following services:
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute yyyy.
All rights reserved.
DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
3GPPTM and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
Contents
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server ().
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and Systems (SES).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "need not", "will", "will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
The increasing proliferation of location-based services is based on several trends in user applications and devices; these include notably the widespread adoption of multi-functional smart-phones etc., and the wider adoption of tracking devices (e.g. in transport). This need for new and innovative location-based services is generating a need for increasingly complex location systems. These systems are designed to deliver location-related information for one or more targets to user applications.
The wide spectrum of technical features identified in [i.1] calls for a new and broader concept for location systems, taking into account hybrid solutions in which GNSS technologies are complemented with other technology sensors to improve robustness and the performance.
Hence a set of standards for GNSS-based Location Systems (GBLS) is defined as follows, of which the present document is part 4:
Part 1: ETSI TS 103 246-1: GNSS-based Location Systems; Part 1: Functional requirements [1]
Part 2: ETSI TS 103 246-2: GNSS-based Location Systems; Part 2: Reference Architecture [2]
Part 3: ETSI TS 103 246-3: GNSS-based Location Systems; Part 3: Performance Requirements [3]
Part 4: ETSI TS 103 246-4: GNSS-based Location Systems; Part 4: Requirements for Location Data Exchange Protocols
Part 5: ETSI TS 103 246-5: GNSS-based Location Systems; Part 5: Performance Test Specification [i.2].
Scope
This document defines the requirements for data elements that may need to be exchanged within the GBLS and externally to applications using the GBLS.
The document also specifies data exchange models for these data elements which may form the basis of protocols (or for modification of protocols) and which may be used for the exchange of location-related data within the GNSS-based Location System (GBLS), as well as between the GBLS and external application modules.
In particular, this document defines the procedures and messages associated with these data exchange models
The GBLS data exchange models are defined to be independent of their underlying transport mechanisms.
References
1 General
References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
Referenced documents that are not found to be publicly available in the expected location might be found at .
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long-term validity.
2 Normative references
The following referenced documents are necessary for the application of the present document.
1] ETSI TS 103 246-1, “GNSS-based Location Systems; Part 1: Functional requirements ”
2] ETSI TS 103 246-2, “GNSS-based Location Systems; Part 2: Reference architecture ”
3] ETSI TS 103 246-3, “GNSS-based Location Systems; Part 3: Performance Requirements ”
4] OMA-TS-MLP-V3.5: "Mobile Location Protocol”
5] OMA-TS-LPPe-V2: "LPP Extensions Specification”
6] 3GPP TS 36.355, “LTE Positioning Protocol (LPP)”
3 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.
1] ETSI TR 103 183: “Satellite Earth Stations and Systems (SES); Global Navigation Satellite Systems (GNSS)-based applications and standardisation needs”.
2] ETSI TS 103 246-5, “GNSS-based Location Systems; Part 5: Performance Test Specification”
3] ETSI TS 122 071: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Location Services (LCS); Service description; Stage 1
4] OMA-TS-ULP-V3: "User Plane Location Protocol".
5] OMA-AD-LOCSIP-V1: “Location in SIP/IP core Architecture”
6] ETSI ES 201 915: Open Service Access (OSA); Application Programming Interface (API)
7] 3GPP2 C.S0022-B “Position Determination Service for cdma2000 Spread Spectrum Systems”
8] 3GPP TS 25.331: “Universal Mobile Telecommunications System (UMTS); Radio Resource Control (RRC) Protocol specification”
9] 3GPP TS 44.031: “Digital cellular telecommunications system (Phase 2+); Location Services (LCS); Mobile Station (MS) - Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP)”
10]
Definitions, symbols and abbreviations
RJM: Definitions, symbols and abbreviations should be in Part 1 of this specification.
1 Definitions
For the purposes of the present document, the following terms and definitions apply:
2 Symbols
For the purposes of the present document, the following symbols apply:
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
DTD Document Type Definition
EFLT Enhanced Forward Link Triangulation positioning method
E-OTD Enhanced Observed Time Difference (E-OTD)
EPDU External Protocol Data Unit
ESRK Emergency Services Routing Key
GANSS Galileo and Additional Global Navigation Satellite Systems
GEM General Error Message
GML Geography Markup Language
GMLC Gateway Mobile Location Centre
GMT Greenwich Mean Time
GNSS Global Navigation Satellite Systems
GPS Global Positioning System
HLR Home Location Register
HTTP Hypertext Transfer Protocol
HTTPS HTTP Secure
IE Information Element
IMSI International Mobile Station Identifier
LCS Location Services
LPP LTE Positioning Protocol
LPPe LTE Positioning Protocol Extensions
LSEP Location System External Protocol
LSIP Location System Internal Protocol
LTE Long-Term Evolution
MLC Mobile Location Centre
MLP Mobile Location Protocol
MS Mobile Station
MSID Mobile Station Identifier
OMA Open Mobile Alliance
OTDOA Observed Time Difference of Arrival
SLP Server Location Provider
SOAP Simple Object Access Protocol
SSL Secure Socket Layer
TLS Transport Layer Security
ULP User-plane Location Protocol
URL Uniform Resource Locator
U-TDOA Uplink Time Difference of Arrival
UTM Universal Transverse Mercator
WAP Wireless Application Protocol
WGS World Geodetic System
XML Extensible Markup Language
Data Exchange Requirements
1 Context
The GBLS data that shall or may be exchanged is defined in [2] in general terms for two main cases:
1) externally to applications using the GBLS, and
2) internally between modules of the GBLS.
The specific requirements for this data are defined further in Clause 7 below.
In addition, data exchange models are defined herein as a basis for protocols that may be used to transfer the GBLS data.
The diagram below shows these defined protocol models and their relevant interfaces applied to the GNSS-based Location System (GBLS) and its functional entities as defined in [2], within an end-to-end system.
Note: Throughout this document, the word “protocol” is used for brevity, when defining a GBLS “data exchange model”. The specifications herein are of data exchange models that may form the basis of protocols,.
[pic]
Figure 4-1: Use of LSEP and LSIP in the GBLS architecture
The protocols defined are:
• LSEP (Location System External Protocol): between the GBLS and an external application (requesting entity)
• LSIP (Location System Internal Protocol): between internal components of the GBLS.
These protocols shall transfer the location-related data defined in [2].
The Protocol definitions in the following clauses address the following aspects:
1) protocol procedures
3) message definitions from a semantic point of view i.e. the information they shall contain, and how this information is structured.
4) information elements within messages and a set of relationships between them.
The definitions do not cover:
• message syntax. Thus, no encoding scheme or data representation is given.
• underlying transport mechanisms for the messages.
2 Protocol Compatibility
1 Overview
In a practical GBLS implementation there are several candidates among standardised protocols for LSEP in next generation location systems including:
|Protocol |Plane |Transport Protocol |Network Protocol |
|3GPP LPP [6], TIA-801 [i.7], RRC [i.8], RRLP [i.9] |Control | | |
|OMA MLP [4] |User |XML/HTML |TCP/IP |
|OSA/PARLAY API [i.6] |User | |TCP/IP |
|OMA LOCSIP [i.5] |User |SIP |TCP/IP |
|OMA ULP [i.4] |User | |TCP/IP |
|OMA LPP/LPPe [5] |User | |TCP/IP |
Also several of these protocols combining their advantages may be used.
Some factors in the choice of location protocol for LSEP are:
• Whether the GBLS (i.e. the Positioning Module) incorporates a mobile terminal connected to a telecommumications network for alternative positioning etc. (3GPP, LTE etc.)
• the underlying transport protocol (SIP, html, TCP/IP, SMS) and whether the control (3G, 2G) or user plane (IP, etc.) will be used.
2 LSEP (MLP)
LSEP is based on the procedures, messages and elements of OMA MLP [4].
MLP is intended for a Mobile Location Service (MLS) Client (e.g. a GBLS external application) to obtain the related data of a location target (e.g. mobile terninal, GBLS Positioning Module, etc.) from a Location Server (e.g. the GBLS).
The MLP specification has been designed with extensibility in mind, notably allowing the addition of new messages and of new parameters to existing messages. Therefore LSEP defines extensions to MLP including any modifications or exceptions.
MLP is defined at the application layer of the protocol stack. Its messages are defined in XML and it is intended to be transported over HTTP or other protocols (e.g. SOAP). For security reasons Secure Socket Layer (SSL) or Transport Layer Security (TLS) cryptographic protocols can be used to carry HTTP (or HTTPS).
Annex A provides further information.
3 LSIP (LPPe)
LSIP is based on the procedures, messages and elements of OMA LPPe [5].
LPPe is based on 3GPP LPP [6], but in addition it allows convergence of both these positioning protocols over either User or Control Plane (and not only the Control Plane), thus removing potential bandwidth limitations and allowing messaging for new positioning technologies. LPPe is also suitable for transport over secure user-plane transport.
. Annex A provides further information.
LPPe is intended to provide transactions for location-related data in a client-server model, and specifically between a SET and SLP (“target” and “server” in LPPe). However LPPe allows many of its messages to be transacted in reversed mode also.
In the GBLS, LSIP is defined for interfaces between all internal functional blocks and hence two main solutions are foreseen:
1. either a single centralised server shall be implemented for communication with all blocks via relays through intermediate blocks, and the server shall provide all required GBLS data
2. or each interface shall implement a separate client-server model and each interface shall transact the relevant subset of the GBLS data.
In the latter case, an example of mapping of GBLS functional blocks to “server” and “target” roles defined by LPPe is shown in the tables below.
Table 4-1: “Server” and “target” roles of GBLS components in A-GNSS data transfer
|Standard |Interface |“Server” role |“Target” role |
|LPPe | |SLP, E-SMLC |SET, UE |
|LSIP |Interface 1 |Localisation Module |GNSS sensor |
|LSIP |Interface 2 |Localisation Module |Telecommunication module |
|LSIP |Interface 3 |Localisation Module |Inertial Navigation Sensor |
|LSIP |Interface 6 |Localisation Module |Beam Forming Antenna |
|LSIP |Interface 7 |Localisation Module |Map data base |
|LSIP |Interface 9 |Central Management module |Localisation Module |
|LSIP |Interface 10 |Central Facility |Positioning Module |
Table 4-2: “Server” and “target” roles of GBLS components in Location information transfer
|Standard |Interface |“Server” role |“Target” role |
|LPPe | |SLP, E-SMLC |SET, UE |
|LSIP |Interface 1 |Localisation Module |GNSS sensor |
|LSIP |Interface 2 |Localisation Module |Telecommunication module |
|LSIP |Interface 3 |Localisation Module |Inertial Navigation Sensor |
|LSIP |Interface 4 |Localisation Module |Magnetometer |
|LSIP |Interface 5 |Localisation Module |Odometer |
|LSIP |Interface 6 |Localisation Module |Beam Forming Antenna |
|LSIP |Interface 8 |Application Module Interface |Localisation Module |
|LSIP |Interface 9 |Central Management module |Localisation Module |
|LSIP |Interface 10 |Central Facility |Positioning Module |
Whichever client-server configuration is chosen for GBLS internal interfaces, LSIP as defined herein defines the global set of necessary location-related data required for the overall functioning of the GBLS as defined in [2]. In practical implementations the LSIP data set may be extended.
1 LSIP Data Exchange Requirements
A summary of data specific to LSIP (i.e. not included in LPPe) requiring to be transferred over the GBLS interfaces defined in [2] is as follows (defined for each type of LSIP procedure: Location information exchange and Assistance data exchange):
Table 4-3: GBLS LSIP supported procedures
|Interface ID | |
|Term |Definition |Term |Definition |
|MS |Mobile Station |Location Target |See definition in [2] |
| | |Positioning Module | |
|MSID |MS identifier |MSID |Identifier for location targets |
|Mobile |Owner of the MS who has subscribed to a |Location Target user |Optional and minor role in GBLS context. |
|subscriber |communication service. | |Target of the location service is the Location Target,|
| |Target of the Location service | |rather than its user. |
|MLS Client |The application, seen as a client of the Mobile |Application Module |See definition in [2] |
| |Location Service | | |
|LCS Client |The application, seen as a client of the |Application Module |See definition in [2] |
| |Location Service | | |
|Location Server|The server which provides location data of the |GBLS Location Server |The Server which provides location data of the |
| |MS to the Client (normal mode) | |Location Target to the Application, and the assistance|
| |or LPPe client (reversed mode) | |data to the Location target or Positioning Module |
| | | |or LPPe client (reversed mode) |
|Target (LPPe) |LPPe client (normal mode) |Location Target |See definition in [2] |
| |or LPPe server (reversed mode) |Positioning Module |or LPPe server (reversed mode) |
LSEP Requirements
1 LSEP Services and Procedures
LSEP data transactions shall use the service schemes as defined for MLP [4] including the messages:as follows:
1. Standard Location Immediate Service consisting:
▪ Standard Location Immediate Request
▪ Standard Location Immediate Answer
▪ Standard Location Immediate Report:
3. Emergency Location Immediate Service:
▪ Emergency Location Immediate Request
▪ Emergency Location Immediate Answer
▪ Emergency Location Immediate Report
4. Standard Location Reporting Service:
▪ Standard Location Report
▪ Standard Location Report Answer
5. Emergency Location Reporting Service
▪ Emergency Location Report
6. Triggered Location Reporting Service
▪ Triggered Location Reporting Request
▪ Triggered Location Reporting Answer
▪ Triggered Location Report
▪ Triggered Location Reporting Stop Request
▪ Triggered Location Reporting Stop Answer
▪ Triggered Location Reporting Pause Report
▪ Triggered Location Reporting Query Request
▪ Triggered Location Reporting Query Answer
▪ Triggered Location Query Report.
LSEP services shall be identical to those in MLP, with the following exceptions:
1) For the Triggered Location Reporting Service, analytic reports (a specific feature of MLP v3.5, see [4] clause 5.2.3.6) are not supported.
5) When an LSEP client (application) attempts to invoke a service not defined in this specification, the GBLS should return a General Error Message. The General Error Message is equivalent to that described in MLP (see [4] clause 5.2.3.7).
However the Information Elements of these services will be extended for the GBLS as defined in 7.
2 Extension of MLP for LSEP
The MLP specification has been designed with extensibility in mind. Examples of design principles employed to achieve this include:
- Separate DTDs for definitions that are common to all messages, e.g. client address and shapes, so they can be re-used.
- A message extension mechanism allowing the addition of new messages (specific for the HTTP mapping). This mechanism works by specifying an entity parameter, '%extension;', referring to an extension DTD. The extension DTD MUST contain another entity parameter, '%extension.message', containing the definition of the extension as a string together with the actual parameters being added
- A parameter extension mechanism allowing the addition of new parameters to existing messages. This mechanism works by specifying an entity parameter, '%extension;', referring to an extension DTD. The extension DTD MUST contain another entity parameter, ‘%extension.param’, containing the definition of the extension as a string together with the actual messages being added.
- Each extension parameters SHOULD have a vendor specific prefix in order to guarantee their uniqueness.
- Element names defined in MLP SHALL NOT be reused with a different definition.
In order to use the extension, the extension DTD has to be explicitly referenced in the XML document.
Duplication of information sent in MLP-based messages using MLP and LSEP shall be avoided by the GBLS and should be avoided by external entities.
The MLP Location Server should, and the LSEP Client shall, ignore any extension that is not recognised and process the message as if the extension is not available.
LSEP messages shall take precedence over any contradictory information (from MLP) received by the GBLS.
Example 1: Message extension
| |
| | | |
| |
| | | |
| |
| |
...
...
Example 2: Parameter extension (note that “trucko_codeword” is given with a vendor specific prefix as the element “codeword” has a different definition than in MLP)
| |
| | | |
| |
| | | |
| |
| |
| |
| |
...
...
KLM4583
6547
Duplication of information sent in “LPP Request” messages using LPPe and LSIP shall be avoided by the GBLS and should be avoided by external entities.
LSIP messages shall take precedence over any contradictiory information (e.g. from LPPe/LPP) received within an “LPP Provide” by a GBLS recipient.
LSIP Requirements
1 LSIP Services and Procedures
LSIP data transactions shall use the service schemes as defined for LPPe [5] as follows:
1. LPP Provide/Request Capabilities (plus LPPe reversed mode)
7. LPP Provide/Request Assistance Data
8. LPP Provide/Request Location Information (plus LPPe reversed mode)
9. LPP Abort
10. LPP Error
11. LPPe Periodic/Triggered Assistance Data Transfer with Update
12. LPPe Periodic/Triggered Location Information Transfer with Update
13. LPPe Segmented Assistance Data Transfer
14. LPPe Segmented Location Information Transfer
15. LPPe Broadcast of Assistance Data
16. LPPe Crowdsourcing
LSIP services shall be identical to those defined for LPPe. However the Information Elements of these services will be extended for the GBLS as defined in 6.2 and 8.
2 Extension of LPPe/LPP for LSIP
LSIP (and LPPe) makes use of the option included in LPP messages (particularly Request and Provision of Capabilities, Location Information and Assistance Data) to define extensions to these messages by means of the EPDU container. Within this EPDU, the Identifier is defined as follows:
• EPDU-ID: 2
• EPDU Defining entity ETSI TC SES
• Method name GBLS LSIP
• Reference LSIP
Duplication of information sent in LPP-based messages using LPPe and LSIP shall be avoided by the GBLS and should be avoided by external entities.
LSIP messages shall take precedence over any contradictory information (e.g. from LPPe/LPP) received by the GBLS.
LSEP Data Exchange Message Definition
The message content necessary to implement the services described in clause //4.1 are described in the sections below.
1 General
The contents of each LSEP message extension to MLP are specified in the following clauses, using ASN.1 to specify the syntax and using tables, when needed, to provide information on the fields and parameters in the message. The information elements carried within the message extensions are specified as Data Type Definitions (DTD’s) in clause 9.
LSEP re-uses, as far as possible, the data definitions from MLP in order to avoid duplication.
New LSEP data types and new parameters within MLP data types that are added are identified by including a ‘ver_LSEP” tag in their names.
2 Standard Location Immediate Request
| |
| |
The following rules apply to the message content and structure:
• - usage of “req_info”: a location request shall contain the structure “req_info” which indicate the type of location-related data required by the application module to the location system.
• - usage of “ReferencePoint”: Rules are defined in [4], clause 5.2.3.2.1, for relative location determination (horizontal position, altitude). The concept hereby defined extends to the following location-related data: relative velocity and relative acceleration.
• As a consequence, if required data “req_info” concerns heading and/or time synchronisation, “ReferencePoint” shall not be present on the location request.
•
3 Standard Location Immediate Answer
SAME DTD AS OMA MLP
| |
| |
In case of EMI localisation: location target identified “MSID” sent back by the GBLS to the client shall be set by the GBLS. It shall ensure that this identifier is unique all the along the GBLS lifecycle.
4 Standard Location Immediate Report
| |
| |
5 Triggered Location Reporting Request
| |
| |
The following rules apply to the message content and structure:
• - usage of “ReferencePoint”: refer to clause //6.1.1
6 Triggered Location Reporting Answer
| |
| |
7 Triggered Location Report
| |
| |
8 Triggered Location Reporting Stop Request
| |
| |
9 Triggered Location Reporting Stop Answer
| |
| |
10 Triggered Location Reporting Pause Report
| |
| |
11 Triggered Location Reporting Query Request
| |
| |
12 Triggered Location Reporting Query Answer
| |
| |
13 Triggered Location Query Report
| |
| |
14 General Error Message
| |
| |
LSIP Data Exchange Message Definition
editorial note :
Each of the 6 messages below (clause 6.2.1 to 6.2.6) is the result of :
- the concatenation of the LPP and LPPe information elements of the corresponding equivalent message (for instance : message “LSIP-RequestLocationInformation”, created in the frame of the present LSIP, contained IEs from message “RequestLocationInformation-r9-IEs” of LPP, and “OMA-LPPe-RequestLocationInformation” of LPPe)
- note that some LPP/LPPe IEs are modified in the present LSIP in order to adapt them to the GBLS framework. These are highlighted in blue
- it also contains new IEs, specific to GBLS framework, mainly to address the use of new sensors. They are highlighted in green.]
1 General
The contents of each LSIP message extension to LPPe are specified in the following clauses, using ASN.1 to specify the syntax and using tables, when needed, to provide information on the fields and parameters in the message. The information elements carried within the message extensions are specified as Data Type Definitions (DTD’s) in clause 10.
LSIP re-uses, as far as possible, the data definitions from LPPe in order to avoid duplication.
New LSIP data types and new parameters within LPPe data types that are added are identified by including a ‘ver_LSIP” tag in their names.
2 IE Extensions of LPPe for LSIP
The IE LSIP-MessageExtension carries version information and the message data carried in the extension. A single LSIP-MessageExtension carries one extension message and all the LSIP information associated with that type. One LSIP-MessageExtension data type is carried within one EPDU-Body OCTET STRING parameter in an LPP message.
-- ASN1START
LSIP-MessageExtension ::= SEQUENCE {
lsipCompatibilityLevel LSIP-LSIPCompatibilityLevel,
lsipVersion LSIP-LSIPVersion,
lsipMode LSIP-LSIPMode,
messageExtensionBody LSIP-MessageExtensionBody,
...
}
LSIP-LSIPCompatibilityLevel ::= INTEGER (0..15)
LSIP-LSIPVersion ::= SEQUENCE {
majorVersion INTEGER(0..255),
minorVersion INTEGER(0..255)
}
LSIP-LSIPMode ::= ENUMERATED {
normal,
reversed,
...
}
LSIP-MessageExtensionBody ::= CHOICE {
requestCapabilities OMA-LPPe-RequestCapabilities,
--Shall only be used in the EPDU in LPP RequestCapabilities
provideCapabilities OMA-LPPe-ProvideCapabilities,
--Shall only be used in the EPDU in LPP ProvideCapabilities
requestAssistanceData LSIP-RequestAssistanceData,
--Shall only be used in the EPDU in LPP RequestAssistanceData
provideAssistanceData LSIP-ProvideAssistanceData,
--Shall only be used in the EPDU in LPP ProvideAssistanceData
requestLocationInformation LSIP-RequestLocationInformation,
--Shall only be used in the EPDU in LPP RequestLocationInformation
provideLocationInformation LSIP-ProvideLocationInformation,
--Shall only be used in the EPDU in LPP ProvideLocationInformation
error LSIP-Error, --Shall only be used in the EPDU in LPP Error
abort LSIP-Abort, --Shall only be used in the EPDU in LPP Abort
...
}
-- ASN1STOP
|LSIP-Message Extension field descriptions |
|lsipCompatibilityLevel |
|This field provides the compatibility level of the LSIP Extensions Release. The compatibility level in this version of LSIP is zero. |
|lsipVersion |
|This field provides the version of LSIP Release that includes majorVersion and minorVersion |
|majorVersion is x element in the x,y version notation. The major version in this release is 0 |
|minorVersion is y element in the x,y version notation. The minor version in this release is 0 |
|messageExtensionBody |
|This parameter provides the body of the message extension for all LPP messages |
|lsipMode |
|This field qualifies the server and target roles defined in the LPP transaction ID. |
3 LSIP Messages
1 Request Assistance Data
The RequestAssistanceData message is used by the “target” entity to request assistance data from the “server” entity.
-- ASN1START
LSIP-RequestAssistanceData::= SEQUENCE {
commonIEsRequestAssistanceData OMA-LPPe-CommonIEsRequestAssistanceData OPTIONAL,
agnss-RequestAssistanceData OMA-LPPe-AGNSS-RequestAssistanceData OPTIONAL,
otdoa-RequestAssistanceData OMA-LPPe-OTDOA-RequestAssistanceData OPTIONAL,
eotd-RequestAssistanceData OMA-LPPe-EOTD-RequestAssistanceData OPTIONAL,
otdoa-utra-RequestAssistanceData OMA-LPPe-OTDOA-UTRA-RequestAssistanceData OPTIONAL,
ecid-lte-RequestAssistanceData OMA-LPPe-ECID-LTE-RequestAssistanceData OPTIONAL,
ecid-gsm-RequestAssistanceData OMA-LPPe-ECID-GSM-RequestAssistanceData OPTIONAL,
ecid-utra-RequestAssistanceData OMA-LPPe-ECID-UTRA-RequestAssistanceData OPTIONAL,
epdu-RequestAssistanceData EPDU-Sequence OPTIONAL,
wlan-ap-RequestAssistanceData OMA-LPPe-WLAN-AP-RequestAssistanceData OPTIONAL,
sensor-RequestAssistanceData OMA-LPPe-Sensor-RequestAssistanceData OPTIONAL,
srn-RequestAssistanceData OMA-LPPe-SRN-RequestAssistanceData OPTIONAL,
pdr-RequestAssistanceData OMA-LPPe-ver2-0-PDR-RequestAssistanceData OPTIONAL,
irb-RequestAssistanceData OMA-LPPe-ver2-0-IRB-RequestAssistanceData OPTIONAL,
...,
-- LSIP extension elements
inertialSensor-RequestAssistanceData LSIP-IntertialSensor-RequestAssistanceData OPTIONAL,
magnetometer-ProvideAssistanceData LSIP-Magnetometer-RequestAssistanceData OPTIONAL,
odometer-ProvideAssistanceData LSIP-Odometer-RequestAssistanceData OPTIONAL,
bfn-ProvideAssistanceData LSIP-BFN-RequestAssistanceData OPTIONAL,
...
}
-- ASN1STOP
Descriptions of the GPLS-RequestAssistanceData individual components are given in section 10
2 Provide Assistance Data
The ProvideAssistanceData message is used by the “server” entity to provide assistance data to the “target” entity either in response to a request from the “target” entity or in an unsolicited manner.
-- ASN1START
LSIP-ProvideAssistanceData::= SEQUENCE {
commonIEsProvideAssistanceData OMA-LPPe-CommonIEsProvideAssistanceData OPTIONAL,
agnss-ProvideAssistanceData OMA-LPPe-AGNSS-ProvideAssistanceData OPTIONAL,
otdoa-ProvideAssistanceData OMA-LPPe-OTDOA-ProvideAssistanceData OPTIONAL,
eotd-ProvideAssistanceData OMA-LPPe-EOTD-ProvideAssistanceData OPTIONAL,
otdoa-utra-ProvideAssistanceData OMA-LPPe-OTDOA-UTRA-ProvideAssistanceData OPTIONAL,
ecid-lte-ProvideAssistanceData OMA-LPPe-ECID-LTE-ProvideAssistanceData OPTIONAL,
ecid-gsm-ProvideAssistanceData OMA-LPPe-ECID-GSM-ProvideAssistanceData OPTIONAL,
ecid-utra-ProvideAssistanceData OMA-LPPe-ECID-UTRA-ProvideAssistanceData OPTIONAL,
epdu-ProvideAssistanceData EPDU-Sequence OPTIONAL
wlan-ap-ProvideAssistanceData OMA-LPPe-WLAN-AP-ProvideAssistanceData OPTIONAL,
sensor-ProvideAssistanceData OMA-LPPe-Sensor-ProvideAssistanceData OPTIONAL,
srn-ProvideAssistanceData OMA-LPPe-SRN-ProvideAssistanceData OPTIONAL,
pdr-ProvideAssistanceData OMA-LPPe-ver2-0-PDR-ProvideAssistanceData OPTIONAL,
irb-ProvideAssistanceData OMA-LPPe-ver2-0-IRB-ProvideAssistanceData OPTIONAL,
...,
-- LSIP extension elements
inertialSensor-ProvideAssistanceData LSIP-IntertialSensor-ProvideAssistanceData OPTIONAL,
magnetometer-ProvideAssistanceData LSIP-Magnetometer-ProvideAssistanceData OPTIONAL,
odometer-ProvideAssistanceData LSIP-Odometer-ProvideAssistanceData OPTIONAL,
bfn-ProvideAssistanceData LSIP-BFN-ProvideAssistanceData OPTIONAL,
...
}
-- ASN1STOP
Descriptions of the GPLS-ProvideAssistanceData individual components are given in section 10
3 Request Location Information
The RequestLocationInformation message is used by the “server” entity to request location-related data to “target” entity.
-- ASN1START
LSIP-RequestLocationInformation::= SEQUENCE {
commonIEsRequestLocationInformation OMA-LPPe-CommonIEsRequestLocationInformation OPTIONAL,
agnss-RequestLocationInformation OMA-LPPe-AGNSS-RequestLocationInformation OPTIONAL,
otdoa-RequestLocationInformation OMA-LPPe-OTDOA-RequestLocationInformation OPTIONAL,
eotd-RequestLocationInformation OMA-LPPe-EOTD-RequestLocationInformation OPTIONAL,
otdoa-utra-RequestLocationInformation OMA-LPPe-OTDOA-UTRA-RequestLocationInformation OPTIONAL,
ecid-lte-RequestLocationInformation OMA-LPPe-ECID-LTE-RequestLocationInformation OPTIONAL,
ecid-gsm-RequestLocationInformation OMA-LPPe-ECID-GSM-RequestLocationInformation OPTIONAL,
ecid-utra-RequestLocationInformation OMA-LPPe-ECID-UTRA-RequestLocationInformation OPTIONAL,
wlan-ap-RequestLocationInformation OMA-LPPe-WLAN-AP-RequestLocationInformation OPTIONAL,
ecid-wimax-RequestLocationInformation OMA-LPPe-ECID-WiMax-RequestLocationInformation OPTIONAL,
sensor-RequestLocationInformation OMA-LPPe-Sensor-RequestLocationInformation OPTIONAL,
srn-RequestLocationInformation OMA-LPPe-SRN-RequestLocationInformation OPTIONAL,
irb-RequestLocationInformation OMA-LPPe-ver2-0-IRB-RequestLocationInformation OPTIONAL,
pdr-RequestLocationInformation OMA-LPPe-ver2-0-PDR-RequestLocationInformation OPTIONAL,
crowdsourcing-RequestLocationInformation OMA-LPPe-ver2-0-Crowdsourcing- RequestLocationInformation OPTIONAL
...,
LSIP extension elements
inertialSensor-RequestLocationInformation LSIP-IntertialSensor-RequestLocationInformation OPTIONAL,
magnetometer-RequestLocationInformation LSIP-Magnetometer-RequestLocationInformation OPTIONAL,
odometer-RequestLocationInformation LSIP-Odometer-RequestLocationInformation OPTIONAL,
bfn-RequestLocationInformation LSIP-BFN-RequestLocationInformation OPTIONAL,
...
}
-- ASN1STOP
Descriptions of the GPLS-RequestLocationInformation components are given in section 10
4 Provide Location Information
The ProvideLocationInformation message is used by a “target” entity to provide location-related data to a “server” entity.
-- ASN1START
LSIP-ProvideLocationInformation::= SEQUENCE {
commonIEsProvideLocationInformation OMA-LPPe-CommonIEsProvideLocationInformation OPTIONAL,
a-gnss-ProvideLocationInformation OMA-LPPe-AGNSS-ProvideLocationInformation OPTIONAL,
otdoa-ProvideLocationInformation OMA-LPPe-OTDOA-ProvideLocationInformation OPTIONAL,
eotd-ProvideLocationInformation OMA-LPPe-EOTD-ProvideLocationInformation OPTIONAL,
otdoa-utra-ProvideLocationInformation OMA-LPPe-OTDOA-UTRA-ProvideLocationInformation OPTIONAL,
ecid-lte-ProvideLocationInformation OMA-LPPe-ECID-LTE-ProvideLocationInformation OPTIONAL,
ecid-gsm-ProvideLocationInformation OMA-LPPe-ECID-GSM-ProvideLocationInformation OPTIONAL,
ecid-utra-ProvideLocationInformation OMA-LPPe-ECID-UTRA-ProvideLocationInformation OPTIONAL,
wlan-ap-ProvideLocationInformastion OMA-LPPe-WLAN-AP-ProvideLocationInformation OPTIONAL,
ecid-wimax-ProvideLocationInformastion OMA-LPPe-ECID-WiMax-ProvideLocationInformation OPTIONAL,
sensor-ProvideLocationInformation OMA-LPPe-Sensor-ProvideLocationInformation OPTIONAL,
srn-ProvideLocationInformation OMA-LPPe-SRN-ProvideLocationInformation OPTIONAL,
irb-ProvideLocationInformation OMA-LPPe-ver2-0-IRB-ProvideLocationInformation OPTIONAL,
pdr-ProvideLocationInformation OMA-LPPe-ver2-0-PDR-ProvideLocationInformation OPTIONAL,
crowdsourcing-ProvideLocationInformation OMA-LPPe-ver2-0-Crowdsourcing-ProvideLocationInformation OPTIONAL,
...,
-- LSIP extension elements
inertialSensor-ProvideLocationInformation LSIP-IntertialSensor-ProvideLocationInformation OPTIONAL,
magnetometer-ProvideLocationInformation LSIP-Magnetometer-ProvideLocationInformation OPTIONAL,
odometer-ProvideLocationInformation LSIP-Odometer-ProvideLocationInformation OPTIONAL,
bfn-ProvideLocationInformation LSIP-BFN-ProvideLocationInformation OPTIONAL,
...
}
-- ASN1STOP
Descriptions of the GPLS-ProvideLocationInformation individual components are given in section 10
[tbd] [Editorial Note: add a few words on the OPTIONAL nature of each IEs.]
5 Abort
The LSIP-Abort message carries a request to abort an on-going LSIP positioning procedure.
-- ASN1START
LSIP-abort ::= SEQUENCE {
commonIEsAbort CommonIEsAbort OPTIONAL, -- Need ON
commonIEsAbort OMA-LPPe-CommonIEsAbort OPTIONAL,
agnssAbort OMA-LPPe-AGNSS-Abort OPTIONAL,
...,
}
-- ASN1STOP
Description of LSIP-abort components is given in section 10
6 Error
The LSIP-Error message carries information concerning a LSIP message that was received with errors.
-- ASN1START
LSIP-error ::= SEQUENCE {
commonIEsError CommonIEsError OPTIONAL, -- Need ON
commonIEsError OMA-LPPe-CommonIEsError OPTIONAL,}
-- ASN1STOP
Description of LSIP-error components is given in section 10
LSEP Information Elements
1 Overview
Elements composing the LSEP messages are defined in the following clauses, using DTD representation to keep consistency with content of clause //6.1 (LSEP messages).
Elements are defined from a semantic point of view only. As mentioned in introduction (refer to clause //4.1 (context)), this specification does not aim at providing normative content related to detailed syntax (variable type, encoding scheme, etc.), which is left up to protocol implementations. Some details corresponding to the detailed syntax are however provided in the sections below. These details are given under two possible scenarios:
• - they either concern simple elements, such as Boolean or character string, whose content is easily identifiable (i.e. with a predefined/limited number of values). In such case, element syntax definition is provided in the normative clauses below (//7.1.2 to //7.1.34).
• - for the other elements, no syntax definition is given. However, informative //annex A provides information derived from the elements definition, and which would contribute to the selection of a syntax in view of an implementation of LSEP. This information contains variable type, range and accuracy, all issued from technical constrains.
Semantic definition of LSEP elements used below but not listed in clauses //7.1.2 to //7.1.34 can be found in [4]. In such case, syntax proposed in [4] shall be ignored.
1 Identity elements
| |
| |
| |
| |
| |
2 Function elements
| |
3 Location elements
| |
| |
| |
| |requested_emidata ( POS_ONLY | POS_AND_BW ) |#IMPLIED> |
| |
| |
| |
| |
| |
| |
| |info_type ( LINEAR | ANGULAR ) |”LINEAR”> |
| |
| |
| |
| |
| | | |
| |
| |
| | | |
| |
| |
| || AFLT | EFLT | E-CID | UNKNOWN | OTHER) | |
| | | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
The following rules apply to the elements content and structure:
• - usage of “req_info”: this element, which describes the location-related data required to the location system, shall contain at least the element “geo_info”, this in order to ensure that the coordinate reference system to be used for location-related data determination is defined in the any location request.
• - usage of “req_emidata”: optional attribute req_emidata turns mandatory anytime the location request (slir or tlrr) identifies the location targets as being EMI sources (refer to clause //7.1.1.1 [identity elements]). It identifies the required EMI-related information.
• - usage of “auth_req”: when this flag is set to “YES” for element “geo_info” (resp. “alt_info”, “vel_info”, “accel_info”, “head_info” and/or “time_synch”) in a location request (slir or tlrr), the optional element “auth_flag” under “hor_qos” (resp. “alt_qos”, “vel_qos”, “accel_qos”, “head_qos” and/or “synch_status”) in the subsequent answer or report(s) (slia, slir or tlrep) become mandatory.
• - usage of “lev_conf “: a location request (slir, tlrr) can require a specific quality of position (defined in elements resp. eqop, qop).
17. - If optional element “h_conf_lev” (resp. “v_conf_lev” and/or “vel_conf_lev”) is present in such elements with attribute “conf_class” set to “ALERT”, it shall be interpreted as a request to the location system to implement integrity determination on the horizontal position (resp. vertical position and/or velocity). Integrity concept is defined in [3]. Element “h_conf_lev” (resp. “v_conf_lev” and/or “vel_conf_lev”) then defines the integrity risk required to be respected by the location system. Corresponding protection level determined by the GBLS is given as follows.
- for integrity of location target horizontal position, position shall be reported in the subsequent answer or report(s) through a “CircularArea” shape: protection level is given by the shape radius (element of the “CircularArea”). As a consequence, attribute “requested_positiondata” of element “geo_info” in the location request (slir or tlrr) shall have values “SHAPE” or “SHAPE_AND_CIVICLOC”.
- for integrity of location target vertical position , protection level shall be given by the element "alt_unc”
- for integrity of location target velocity, protection level shall be given by the element "vel_unc”
18. In addition, the element “lev_conf” under “hor_qos” (resp. “alt_qos” and/or “vel_qos”) in the subsequent answer or report(s) shall either be absent, or equal to the required integrity risk, i.e. “h_conf_lev” (resp. “v_conf_lev” and/or “vel_conf_lev”)
19. Finally, in case of an identified misleading information (i.e; causing mis-integrity), the GBLS shall inform the application module by sending element “h_int_alert” (resp. “v_int_alert” and/or “vel_int_alert”) under element “qos_status”.
20. - If optional element “h_conf_lev” (resp. “v_conf_lev”, “vel_conf_lev”) is present in such elements with attribute “conf_class” set to “INFO”, or element “accel_conf_lev” (resp. “head_conf_lev”, and/or “time_conf_lev”), it shall be interpreted as a request to the location system to provide an estimate of the horizontal position error (resp. vertical position error, velocity error, acceleration error, heading error and/or time synchronisation error).
- for horizontal position error estimation, the error estimate shall be reported in the subsequent answer or report(s) through a “CircularArea” shape: error estimate is given by the shape radius (element of the “CircularArea”). As a consequence, attribute “requested_positiondata” of element “geo_info” in the location request (slir or tlrr) shall have values “SHAPE” or “SHAPE_AND_CIVICLOC”.
- for other error estimation, the error estimate shall be given by the element “alt_unc” (resp. “vel_unc”, “accel_unc”, “head_unc” and/or “time_unc”)
21. Element “h_conf_lev” (resp. “v_conf_lev”, “vel_conf_lev”, “accel_conf_lev”, “head_conf_lev”, and/or “time_conf_lev”) is then the targeted level of reliability of the error estimate required to the location system. Level of reliability is defined as:
22. P(( > (*) (*) is the probability that the actual error exceeds the error estimate, and Lr is the level of reliability.
23. In case of necessity, the location system can provide an error estimate using a different level of reliability. In that case, element “lev_conf” under “hor_qos” (resp. “alt_qos”, “vel_qos”, “accel_qos”, “head_qos” and/or “synch_status”) in the subsequent answer or report(s) shall contain the confidence level achievable by the location system.
• - usage of “ll_acc“, “hor_acc”, “alt_acc”, “vel_acc” and “time_acc”: when present in a location request (under element “eqop” or “qop”), these elements:
24. - indicate the level of accuracy expected by the application module. Value of attribute “qos_class” indicate the expected behavior of the location system in case the location-related data does not fulfill the required accuracy. Refer to clause //5.x (qos_class definition).
25. - preclude integrity determination by the location system.
4 Quality of Position elements
| |
| | | |
| |
| | | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | | |
| |
| |
| |
| | | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | | |
The following rules apply to the elements content and structure:
• - usage of “h_int_alert” (resp. “v_int_alert” and/or “vel_int_alert”): refer to clause //7.1.1.4 (location elements).
• - usage of “h_acc_not_met” (resp “v_acc_not_met”, “vel_acc_not_met” and/or “time_acc_not_met”: refer to clause //7.1.1.4 (location elements)
2 accel
|Definition: |
|The acceleration of the location target, in m/s². When used for relative location, this parameter expresses the acceleration relative to the |
|Reference Point. |
|DTD type: |Element |
|Format: |Signed decimal value, suggested accuracy 0.1 [tbc] |
|Defined values: |Admitted range: [-50; 50] [tbc] |
|Default value: |N/A |
|Example in XML |2.5 |
|presentation: | |
|Note: |This element is present if required by element “req_info” in the corresponding location request. |
3 accel_conf_lev
|Definition: |
|This element is the level of reliability required by the application module regarding the acceleration accuracy estimate provided by the location|
|system. It is expressed as log10(Level of reliability). |
|DTD type: |Element |
|Format: |Negative decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [-10; 0] [tbc] |
|Default value: |- |
|Example in XML |-2 |
|presentation: | |
|Note: |When this element is present in a location request, it implicitely indicates that an estimate of the acceleration |
| |accuracy is required (this accuracy estimation being reliable with the required level of reliability). In the |
| |subsequent answer/report(s), the position information definition (element “pd”) shall contain element “accel_unc”, or|
| |an appropriate error message. |
4 accel_info
|Definition: |
|If present, this element indicates that the acceleration information of the location target identified by MSID is required |
|DTD type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML | |
|presentation: | |
|Note: |- |
1 auth_req
|Definition: |
|Indicates if the location system is required to provide the related (parent) location-related data with associated authentication information. |
|Type: |Attribute |
|Format: |Boolean |
|Defined values: |YES |Authenticity of the location-related data shall be determined and provided |
| |NO |Authenticity of the location-related data shall not be determined and provided |
|Default value: |NO |
|Example: |< accel_info auth_req ="NO" /> |
|Note: |- |
2 mot_type
|Definition: |
|Determines the type of motion required to be captured in the location-related data by the location system. |
|Type: |Attribute |
|Format: |Char string |
|Defined values: |LINEAR |Linear indicators are required (linear speed, linear acceleration) |
| |ANGULAR |Angular indicators are required (angular speed, angular acceleration) |
|Default value: |LINEAR |
|Example: |< accel_info mot_type ="ANGULAR" /> |
|Note: |- |
5 accel_unc
|Definition: |
|Estimate of the acceleration uncertainty or error, in m/s² |
|DTD type: |Element |
|Format: |Positive decimal value, admitted accuracy 0.1 [tbc] |
|Defined values: |Admitted range: [0; 10] |
|Default value: | |
|Example in XML |1 |
|presentation: | |
|Note: |Usage of this element is defined in clause //7.1.1.4 (location elements) |
6 alt_info
|Definition: |
|If present, this element indicates that the altitude information (or vertical position) of the location target identified by MSID is required |
|DTD type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML | |
|presentation: | |
|Note: |- |
1 auth_req
Refer to clause //7.1.4.1 (auth_req under accel_info)
7 alt_unc
|Definition: |
|Estimate of the altitude uncertainty or error, in m |
|DTD type: |Element |
|Format: |Positive decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [0 ; 100] [tbc] |
|Default value: |- |
|Example in XML |0.5 |
|presentation: | |
|Note: |Usage of this element, in particular regarding the integrity concept, is defined in clause //7.1.1.4 (location |
| |elements) |
NOTE: element with the same name exists in OMA MLP [4]. In the LSEP context, the above definition supersedes the one given in [4].
8 auth_flag
|Definition: |
|Defines the auuthentication status of a location-related data (horizontal or vertical position, velocity, acceleration, heading or time) |
|DTD Type: |Element |
|Format: |Char string |
|Defined values: |NO |Spoofing attempt is detected |
| |YES |Location-related data is authentic |
| |UNKNOWN |Authentication procedure could not conclude |
|Default value: |- |
|Example in XML |YES |
|presentation: | |
|Note: |- |
9 geo_info
Element “geo_info” used in LSEP has the same definition as in OMA MLP [4].
In addition, in order to fit GBLS specific context, the attributes “auth_req” and “requested_emidata” are added to element “geo_info” (see clause //7.1.1.4 (location elements)).
1 auth_req
Refer to clause //7.1.4.1 (auth_req under accel_info)
2 req_emidata
|Definition: |
|Used when location request concerns EMI sources. Determines the type of EMI information requested to the location system. |
|DTD Type: |Attribute |
|Format: |Char string |
|Defined values: |POS_ONLY |Only positions of EMI sources are required |
| |POS_AND_BW |Both positions and signal bandwidth estimation are required |
|Default value: |POS_ONLY |
|Example in XML |< geo_info req_emidata ="POS_ONLY"> |
|presentation: | |
|Note: |- |
10 h_acc_not_met
|Definition: |
|Indication that the requested horizontal position QoS was not met, if needed. |
|DTD Type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML |- |
|presentation: | |
|Note: |Only applicable if the request was for best effort class, i.e. a horizontal position estimate is returned (rather |
| |than an error) although the requested QoS requirement (given in ll_acc or hor_acc) could not be fulfilled. |
11 h_conf_lev
|Definition: |
|Depending on the value of attribute “conf_class”, it represents either the required integrity risk which shall be used by the location system in |
|its integrity determination process, or the preferred level of reliability of the horizontal position error estimate. It is expressed as |
|log10(Level of reliability) or log10(integrity risk). |
|Both integrity risk and level of reliability are defined in clause // 7.1.1.4 (location elements): |
|DTD Type: |Element |
|Format: |Negative decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [-10; 0] [tbc] |
|Default value: | |
|Example in XML |-2 |
|presentation: | |
|Note: |- |
1 conf_class
|Definition: |
|This attributes determines whether the parent confidence level provided shall be interpreted as an integrity risk or a level of reliability. |
|Both integrity risk and level of reliability are defined in clause // 7.1.1.4 (location elements): |
|DTD Type: |attribute |
|Format: |Char string |
|Defined values: |INFO |Parent confidence level shall be intepreted as the level of reliability of the required |
| | |error estimate. |
| |ALERT |Parent confidence level shall be intepreted as the integrity risk which shall be used by |
| | |the location system in its integrity determination process |
|Default value: |[INFO] |
|Example in XML |-2 |
|presentation: | |
|Note: |Value INFO shall be interpreted as a request to the location system to provide an horizontal position error estimate |
| |(resp. vertical position or velocity) |
| |Value ALERT shall be interpreted as a request to the location system to carry out integrity determination for |
| |horizontal position (resp. vertical position of velocity). |
12 h_int_alert
|Definition: |
|Indication that the location system detects location-related data mis-integrity. |
|DTD Type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML |- |
|presentation: | |
|Note: |Only applicable in case “conf_class” under “h_conf_lev” is set to “ALERT”. |
13 head_conf_lev
|Definition: |
|It represents the preferred level of reliability of the heading error estimate. It is expressed as log10(Level of reliability). |
|Level of reliability is defined in clause // 7.1.1.4 (location elements): |
|DTD Type: |Element |
|Format: |Negative decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [-10; 0] [tbc] |
|Default value: | |
|Example in XML |-2 |
|presentation: | |
|Note: |- |
14 head_info
|Definition: |
|If present, this element indicates that the heading information of the location target identified by MSID is required |
|DTD type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML | |
|presentation: | |
|Note: |- |
1 auth_req
Refer to clause //7.1.4.1 (auth_req under accel_info)
15 head_unc
|Definition: |
|Estimate of the heading uncertainty or error, in degrees |
|DTD type: |Element |
|Format: |Positive decimal value, admitted accuracy 0.1 [tbc] |
|Defined values: |Admitted range: [0; 10] [tbc] |
|Default value: |- |
|Example in XML |1 |
|presentation: | |
|Note: |Usage of this element is defined in clause //7.1.1.4 (location elements) |
16 high_freq
|Definition: |
|Higher frequency of the bandwidth in which EMI that are subject to location-related data determination by the GBLS are transmitting. It is |
|expressed in Hz. |
|DTD type: |Element |
|Format: |positive decimal value, admitted accuracy 1 [tbc] |
|Defined values: |Admitted range: [0; 2x109] [tbc] |
|Default value: |- |
|Example in XML |1,6x109 |
|presentation: | |
|Note: |- |
17 lev_conf
|Definition: |
|Confidence level associated to the location-related data provided by the locationsystem. It is expressed as log10(confidence level). |
|Interpretation of data contained in “lev_conf” is provided in clause // 7.1.1.4 (location elements): |
|DTD type: |Element |
|Format: |Negative decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [-10; 0] [tbc] |
|Default value: | |
|Example in XML |1 |
|presentation: | |
|Note: |In case location system executes location-related data integrity determination (i.e. “conf_class” is set to “ALERT”),|
| |“lev_conf” shall be equal to “h_conf_lev” (resp. “v_conf_lev” or “vel_conf_level”) given in the associated location |
| |request. |
| |In case location system provide location-related data error estimation (i.e. “conf_class” is set to “INFO”), |
| |“lev_conf” can have any value. |
NOTE: element with the same name exists in OMA MLP [4]. In the LSEP context, the above definition supersedes the one given in [4].
18 low_freq
|Definition: |
|Lower frequency of the bandwidth in which EMI that are subject to location-related data determination by the GBLS are transmitting. It is |
|expressed in Hz. |
|DTD type: |Element |
|Format: |positive decimal value, admitted accuracy 1 [tbc] |
|Defined values: |Admitted range: [0; 2x109] [tbc] |
|Default value: |- |
|Example in XML |1,55x109 |
|presentation: | |
|Note: |- |
19 pfa
|Definition: |
|This element is the probability of false-alarm applicable to the authentication function, , expressed as log10(Pfa) |
|DTD type: |Element |
|Format: |Negative decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [-10; 0] [tbc] |
|Default value: |- |
|Example in XML |-5,49 |
|presentation: | |
|Note: |- |
20 pmd
|Definition: |
|This element is the probability of mis-detection applicable to the authentication function, expressed as log10(Pmd) |
|DTD type: |Element |
|Format: |Negative decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [-10; 0] [tbc] |
|Default value: |- |
|Example in XML |-5,49 |
|presentation: | |
|Note: |- |
21 time_acc
|Definition: |
|Accuracy of requested time synchronisation in micro seconds. |
|DTD type: |Element |
|Format: |Positive decimal value, admitted accuracy 0.001 [tbc] |
|Defined values: |Admitted range: [0; 10000] [tbc] |
|Default value: |- |
|Example in XML |0.1 |
|presentation: | |
|Note: |- |
22 time_acc_not_met
|Definition: |
|Indication that the requested time synchronisation QoS was not met, if needed. |
|DTD Type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML |- |
|presentation: | |
|Note: |Only applicable if the request was for best effort class, i.e. a time synchronisation signal is provided (rather than|
| |an error) although the requested QoS requirement (given in time_acc) could not be fulfilled. |
23 time_conf_lev
|Definition: |
|This element is the level of reliability required by the application module regarding the time synchronisation accuracy estimate provided by the |
|location system. It is expressed as log10(Level of reliability). |
|Level of reliability is defined in clause // 7.1.1.4 (location elements): |
|DTD type: |Element |
|Format: |Negative decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [-10; 0] [tbc] |
|Default value: |- |
|Example in XML |-2 |
|presentation: | |
|Note: |When this element is present in a location request, it implicitely indicates that an estimate of the time |
| |synchronisation accuracy is required (this accuracy estimation being reliable with the required level of |
| |reliability). In the subsequent answer/report(s), the position information definition (element “pd”) shall contain |
| |element “time_unc”, or an appropriate error message. |
24 time_p
|Definition: |
|In a location answer this element indicates the precise time when the positioning was performed. |
|DTD type: |Element |
|Format: |Char string, with time stamp accuracy down to micro-second level [tbc] |
|Defined values: |- |
|Default value: |- |
|Example: |20141022142810630040 |
|Note: | |
25 time_unc
|Definition: |
|Estimate of the time synchronisation uncertainty or error, in µs |
|DTD type: |Element |
|Format: |Positive decimal value, admitted accuracy 0.001 [tbc] |
|Defined values: |Admitted range: [0; 10000] [tbc] |
|Default value: |- |
|Example in XML |1 |
|presentation: | |
|Note: |Usage of this element is defined in clause //7.1.1.4 (location elements) |
26 acc_not_met
|Definition: |
|Indication that the requested vertical position QoS was not met, if needed. |
|DTD Type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML |- |
|presentation: | |
|Note: |Only applicable if the request was for best effort class, i.e. a vertical position estimate is returned (rather than |
| |an error) although the requested QoS requirement (given in alt_acc) could not be fulfilled. |
27 v_conf_lev
|Definition: |
|Depending on the value of attribute “conf_class”, it represents either the required integrity risk which shall be used by the location system in |
|its integrity determination process, or the preferred level of reliability of the vertical position error estimate. It is expressed as |
|log10(Level of reliability) or log10(integrity risk). |
|Both integrity risk and level of reliability are defined in clause // 7.1.1.4 (location elements): |
|DTD Type: |Element |
|Format: |Negative decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [-10; 0] [tbc] |
|Default value: |- |
|Example in XML |-2 |
|presentation: | |
|Note: |- |
1 conf_class
Refer to clause //7.1.11.1 (conf_class under h_conf_lev)
28 v_int_alert
|Definition: |
|Indication that the location system detects location-related data mis-integrity. |
|DTD Type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML |- |
|presentation: | |
|Note: |Only applicable in case “conf_class” under “v_conf_lev” is set to “ALERT”. |
29 vel_acc
|Definition: |
|Accuracy of requested velocity in m/s. |
|DTD type: |Element |
|Format: |Positive decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [0; 5] [tbc] |
|Default value: |- |
|Example in XML |1 |
|presentation: | |
|Note: |- |
30 vel_acc_not_met
|Definition: |
|Indication that the requested velocity QoS was not met, if needed. |
|DTD Type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML |- |
|presentation: | |
|Note: |Only applicable if the request was for best effort class, i.e. a velocity estimate is provided (rather than an error)|
| |although the requested QoS requirement (given in vel_acc) could not be fulfilled. |
31 vel_conf_lev
|Definition: |
|Depending on the value of attribute “conf_class”, it represents either the required integrity risk which shall be used by the location system in |
|its integrity determination process, or the preferred level of reliability of the vertical position error estimate. It is expressed as |
|log10(Level of reliability) or log10(integrity risk). |
|Both integrity risk and level of reliability are defined in clause // 7.1.1.4 (location elements): |
|DTD Type: |Element |
|Format: |Negative decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [-10; 0] [tbc] |
|Default value: |- |
|Example in XML |-2 |
|presentation: | |
|Note: |- |
1 conf_class
Refer to clause //7.1.11.1 (conf_class under h_conf_lev)
32 vel_info
|Definition: |
|If present, this element indicates that the velocity information of the location target identified by MSID is required |
|DTD type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML | |
|presentation: | |
|Note: |- |
1 auth_req
Refer to clause //7.1.4.1 (auth_req under accel_info)
2 mot_type
Refer to clause //7.1.4.2 (mot_type under accel_info)
33 vel_int_alert
|Definition: |
|Indication that the location system detects location-related data mis-integrity. |
|DTD Type: |Element |
|Format: |Void |
|Defined values: |- |
|Default value: |- |
|Example in XML |- |
|presentation: | |
|Note: |Only applicable in case “conf_class” under “vel_conf_lev” is set to “ALERT”. |
34 vel_unc
|Definition: |
|Estimate of the velocity uncertainty or error, in m/s |
|DTD type: |Element |
|Format: |Positive decimal value, admitted accuracy 0.01 [tbc] |
|Defined values: |Admitted range: [0;5] [tbc] |
|Default value: |- |
|Example in XML |1 |
|presentation: | |
|Note: |Usage of this element is defined in clause //7.1.1.4 (location elements) |
35 Error codes
36 Provide Capabilities
37 Request Location Information
Attributes:
• Type of reporting:
o Event triggered
o Periodic
• ID of mobile target(s)
• Type of location-related data:
o Position
o Speed
o Acceleration
o requested QoS:
▪ Integrity (including required integrity risk)
▪ Authentication
LSIP Information Elements
1 LSIP Common IEs
This section defines common IEs that are applicable to more than one LSIP positioning method.
1 LSIP Common Low-Level IEs
1 GBLS-DirectionOfArrival
GBLS-DirectionOfArrival::= SEQUENCE {
azimuth INTEGER (0..511),
elevation INTEGER (0..127),}
azimuthEstError INTEGER (0..[tbd]),
elevationEstError INTEGER (0..[tbd]),
}
|GBLS-DirectionOfArrival field descriptions |
|azimuth |
|[tbd] |
|NB : as defined in 3GPP LPP (in GNSS-AcquisitionAssistElement) |
|elevation |
|[tbd] |
|NB : as defined in 3GPP LPP (in GNSS-AcquisitionAssistElement) |
|azimuthEstError |
|[tbd] |
|elevationEstError |
|[tbd] |
2 GBLS-ConfidenceLevels
-- ASN1START
GBLS-ConfidenceLevels::= SEQUENCE {
horizontalCL INTEGER(0..tbd) OPTIONAL, -- Cond
verticalCL INTEGER(0..tbd) OPTIONAL, -- Cond
velocityCL INTEGER(0..tbd) OPTIONAL, -- Cond
accelerationCL INTEGER(0..tbd) OPTIONAL, -- Cond
headingCL INTEGER(0..tbd) OPTIONAL, -- Cond
}
-- ASN1STOP
|Conditional presence |Explanation |
|xxx |[tbd] |
|… |… |
|GBLS-ConfidenceLevels field descriptions |
|horizontalCL |
|[tbd] |
|verticalCL |
|[tbd] |
|velocityCL |
|[tbd] |
|accelerationCL |
|[tbd] |
|headingCL |
|[tbd] |
3 GBLS-UncertaintyMeasures
-- ASN1START
GBLS-UncertaintyMeasures::= SEQUENCE {
accelerationUncertainty INTEGER(0..tbd) OPTIONAL, -- Cond
headingUncertainty INTEGER(0..tbd) OPTIONAL, -- Cond
}
-- ASN1STOP
|Conditional presence |Explanation |
|xxx |[tbd] |
|… |… |
|GBLS-UncertaintyMeasures field descriptions |
|accelerationUncertainty |
|[tbd] |
|headingUncertainty |
|[tbd] |
4 GBLS-QosIndicators
-- ASN1START
GBLS-QosIndicators::= SEQUENCE {
horizontalAccuracyNotMet BOOLEAN
verticalAccuracyNotMet BOOLEAN
velocityAccuracyNotMet BOOLEAN
headingAccuracyNotMet BOOLEAN
}
-- ASN1STOP
|GBLS-QosIndicators field descriptions |
|horizontalAccuracyNotMet |
|[tbd] |
|verticalAccuracyNotMet |
|[tbd] |
|velocityAccuracyNotMet |
|[tbd] |
|headingAccuracyNotMet |
|[tbd] |
5 GBLS-AuthenticationIndicators
-- ASN1START
GBLS-AuthenticationIndicators::= SEQUENCE {
horPosAuthentication BOOLEAN OPTIONAL, -- Cond
verticalPositionsAuthentication BOOLEAN OPTIONAL, -- Cond
velocityAuthentication BOOLEAN OPTIONAL, -- Cond
accelerationAuthentication BOOLEAN OPTIONAL, -- Cond
headingAuthentication BOOLEAN OPTIONAL, -- Cond
}
-- ASN1STOP
|Conditional presence |Explanation |
|xxx |[tbd] |
|… |… |
|GBLS-AuthenticationIndicators field descriptions |
|horPosAuthentication |
|[tbd] |
|verticalPositionAuthentication |
|[tbd] |
|velocityAuthentication |
|[tbd] |
|accelerationAuthentication |
|[tbd] |
|headingAuthentication |
|[tbd] |
6 GBLS-AuthenticationReq
-- ASN1START
GBLS-AuthenticationReq::= SEQUENCE {
authParameters AuthenticationParameters,
horPosAuthenticationReq BOOLEAN
verticalPositionAuthenticationReq BOOLEAN
velocityAuthenticationReq BOOLEAN
accelerationAuthenticationReq BOOLEAN
headingAuthenticationReq BOOLEAN
}
AuthenticationParameters::= SEQUENCE {
pmd INTEGER(0..tbd),
pfa INTEGER(0..tbd),
...
}
-- ASN1STOP
|GBLS-AuthenticationReq field descriptions |
|authParameters |
|[tbd] |
|pmd |
|pfa |
|horPosAuthenticationReq |
|[tbd] |
|verticalPositionAuthenticationReq |
|[tbd] |
|velocityAuthenticationReq |
|[tbd] |
|accelerationAuthenticationReq |
|[tbd] |
|headingAuthenticationReq |
|[tbd] |
2 LSIP Common Positioning-Related IEs
1 CommonIEsRequestLocationInformation
-- ASN1START
CommonIEsRequestLocationInformation ::= SEQUENCE {
locationInformationType LocationInformationType,
triggeredReporting TriggeredReportingCriteria OPTIONAL, -- Cond ECID
periodicalReporting PeriodicalReportingCriteria OPTIONAL, -- Need ON
additionalInformation AdditionalInformation OPTIONAL, -- Need ON
qos QoS OPTIONAL, -- Need ON
environment Environment OPTIONAL, -- Need ON
locationCoordinateTypes LocationCoordinateTypes OPTIONAL, -- Need ON
velocityTypes VelocityTypes OPTIONAL, -- Need ON
emiInventoryReq GBLS-EMISourceInventoryReq OPTIONALn -- Need ON
locatioTargetIdReq GBLS-LocationTargetIdReq OPTIONAL
...
}
LocationInformationType ::= ENUMERATED {
locationEstimateRequired,
locationMeasurementsRequired,
locationEstimatePreferred,
locationMeasurementsPreferred,
...
}
TriggeredReportingCriteria ::= SEQUENCE {
ChangeArea XX
distanceEvent XX
velocityEvent XX
cellChange BOOLEAN,
equidistanceEvent BOOLEAN,
reportingDuration ReportingDuration,
logicalTriggerCombination ENUMERATED {or, and, ...} OPTIONAL,
...
}
ReportingDuration ::= INTEGER (0..255)
PeriodicalReportingCriteria ::= SEQUENCE {
reportingAmount ENUMERATED {
ra1, ra2, ra4, ra8, ra16, ra32,
ra64, ra-Infinity
} DEFAULT ra-Infinity,
reportingInterval ENUMERATED {
noPeriodicalReporting, ri0-25,
ri0-5, ri1, ri2, ri4, ri8, ri16, ri32, ri64
}
}
AdditionalInformation ::= ENUMERATED {
onlyReturnInformationRequested,
mayReturnAditionalInformation,
...
}
QoS ::= SEQUENCE {
horizontalAccuracy HorizontalAccuracy OPTIONAL, -- Need ON
verticalCoordinateRequest BOOLEAN,
verticalAccuracy VerticalAccuracy OPTIONAL, -- Need ON
responseTime ResponseTime OPTIONAL, -- Need ON
velocityRequest BOOLEAN,
velocityAccuracy VelocityAccuracy OPTIONAL, -- Need ON
headingRequest BOOLEAN,
headingAccuracy HeadingAccuracy OPTIONAL, -- Need ON
accelerationRequest BOOLEAN,
accelerationAccuracy AccelerationAccuracy, OPTIONAL, -- Need ON
authenticationReq GBLS-AuthenticationReq OPTIONEL, -- Need ON
...
}
Environment ::= ENUMERATED {
badArea,
notBadArea,
mixedArea,
...
}
HorizontalAccuracy ::= SEQUENCE {
accuracy INTEGER(0..127), OPTIONAL, --targetAcc
confidence INTEGER(0..100),
confidenceClass ENUMERATED { INFO,
ALERT, ...}
qosClass ENUMERATED { ASSURED,
BEST_EFFORT, ...} OPTIONAL, --targetAcc
...
}
VerticalAccuracy ::= SEQUENCE {
accuracy INTEGER(0..127), OPTIONAL, --targetAcc
confidence INTEGER(0..100), OPTIONAL, --accEstReq
confidenceClass ENUMERATED { INFO,
ALERT, ...} OPTIONAL, --accEstReq
Qos class ENUMERATED { ASSURED,
BEST_EFFORT, ...} OPTIONAL, --targetAcc ...
}
ResponseTime ::= SEQUENCE {
time INTEGER (1..128),
...
}
VelocityAccuracy ::= SEQUENCE {
accuracy INTEGER(0..127), OPTIONAL, --targetAcc
confidence INTEGER(0..100), OPTIONAL, --accEstReq
confidenceClass ENUMERATED { INFO,
ALERT, ...} OPTIONAL, --accEstReq
Qos class ENUMERATED { ASSURED,
BEST_EFFORT, ...} OPTIONAL, --targetAcc
...
}
HeadingAccuracy ::= SEQUENCE {
accuracy INTEGER(0..127), OPTIONAL, --targetAcc
confidence INTEGER(0..100), OPTIONAL, --accEstReq
confidenceClass ENUMERATED { INFO,
ALERT, ...} OPTIONAL, --accEstReq
qos class ENUMERATED { ASSURED,
BEST_EFFORT, ...} OPTIONAL, --targetAcc
...
}
AccelerationAccuracy ::= SEQUENCE {
confidence INTEGER(0..100),
...
}
GBLS-InventoryReq ::= SEQUENCE {
frequenyBand GBLS-FrequencyBand,
targetArea CHOICE {
circle Ellipsoid-PointWithUncertaintyCircle,
ellipse EllipsoidPointWithUncertaintyEllipse,
Polygon Polygon,
...
}
...
}
GBLS-LocationTargetIdReq ::= SEQUENCE {
[tbd]
...
}
-- ASN1STOP
|Conditional presence |Explanation |
|ECID |The field is optionally present, need ON, if ECID is requested. Otherwise it is not present. |
|targetAcc |The field shall be absent in case field “confidence” and “confidenceClass” are specified in the same “QoS” |
| |IE. |
|accEstReq |The field shall be absent in case field “accuracy” and “qos_class” are specified in the same “QoS” IE.. |
|CommonIEsRequestLocationInformation field descriptions |
|locationInformationType |
|As per 3GPP LPP [6] |
|triggeredReporting |
|[tbd] |
|periodicalReporting |
|As per 3GPP LPP [6] |
|additionalInformation |
|As per 3GPP LPP [6] |
|qos |
|[tbd] |
| |
|horizontalAccuracy : see table below |
|verticalAccuracy: see table below |
|velocityAccuracy: see table below |
|headingAccuracy: see table below |
|verticalCoordinateRequest: [tbd] |
|responseTime: [tbd] |
|velocityRequest: [tbd] |
|headingRequest: [tbd] |
|accelerationRequest: [tbd] |
|accelerationAccuracy: [tbd] |
|authenticationReq: [tbd] |
| |
|The table below indicates how IE related to “xxAcuracy” are structured. |
| |
| |
|accuracy field |
|confidence field |
|confidenceClass field |
|qosClass field |
|Explanation |
| |
|Case 1 |
|present |
|absent |
|absent |
|ASSURED |
|Targeted measure accuracy is specified, and only measure complying with targeted accuracy shall be provided. |
| |
|Case 2 |
|present |
|absent |
|absent |
|BEST EFFORT |
|Targeted measure accuracy is specified, and measure not complying with targeted accuracy shall be flagged in the subsequent answer (using IE |
|“GBLS-QosIndicators”). |
| |
|Case 3 |
|absent |
|present |
|INFO |
|absent |
|Estimation of the measure accuracy is required. Accuracy estimate should comply with the required confidence level. In CL cannot be met, it shall be |
|indicated in the subsequent answer (using IE “GBLS-ConfidenceLevels”). |
| |
|Case 4 |
|absent |
|present |
|ALERT |
|absent |
|Estimation of the measure accuracy is required. Accuracy estimate shall comply with the required confidence level. In case estimated accuracy cannot |
|compy with the required CL it shall be reported in the subsequent answer to the “server” entity (using IE “GBLS-IntegrityAlerts”). |
| |
| |
|All other combinations shall not be used. |
| |
|environment |
|As per 3GPP LPP [6] |
|locationCoordinateTypes |
|As per 3GPP LPP [6] |
|velocityTypes |
|As per 3GPP LPP [6] |
|emiInventoryReq |
|[tbd] |
|locationTargetIdReq |
|[tbd] |
|[Editorial note : while locationTargetIdReq, in “Common location information request”, can cover a group of targets, the locationTargetId in “Common |
|location information provide”points on a single target id. |
|We indeed assume that the “common location information provide” message contains information for a single target, while the “request” message can |
|contain information request related to several targets] |
2 OMA-LPPe-CommonIEsRequestLocationInformation
-- ASN1START
OMA-LPPe-CommonIEsRequestLocationInformation ::= SEQUENCE {
iP-Address-Request OMA-LPPe-IP-Address-Request OPTIONAL,
locationInformationContainerRequest OMA-LPPe-LocationInformationContainerRequest OPTIONAL,
requestPeriodicLocInfoWithUpdate OMA-LPPe-RequestPeriodicLocInfoWithUpdate OPTIONAL,
--Cond RequestPeriodicLocInfoWithUpdate
relativeLocationChange-Request OMA-LPPe-RelativeLocationChange-Request OPTIONAL,
localPositionRequest OMA-LPPe-LocalPositionRequest OPTIONAL,
scheduledLocation-Request OMA-LPPe-ScheduledLocation-Request OPTIONAL,
accessTypeRequest OMA-LPPe-AccessTypeRequest OPTIONAL,
segmentedLIpreference ENUMERATED {useBasic, useResume, ...} OPTIONAL,
segmentedLIResume OMA-LPPe-SegmentedLIResume OPTIONAL,
--Cond segmentedTransferResume
locationSourceReq OMA-LPPe-LocationSource OPTIONAL --Cond LocationSource
...
}
OMA-LPPe-IP-Address-Request ::= SEQUENCE {
...
}
OMA-LPPe-RequestPeriodicLocInfoWithUpdate ::= SEQUENCE {
session-ID OCTET STRING (SIZE(4)),
typeOfLocInfoRequest OMA-LPPe-TypeOfLocInfoRequest,
...
}
OMA-LPPe-TypeOfLocInfoRequest ::= ENUMERATED {
initialRequest,
updateAndContinueIfUpdateFails,
updateAndAbortIfUpdateFails,
...
}
OMA-LPPe-RelativeLocationChange-Request ::= SEQUENCE {
numberOfChanges INTEGER (1..5) OPTIONAL,
...
}
OMA-LPPe-LocalPositionRequest ::= SEQUENCE {
typeOfRequest ENUMERATED { localOptional, localMandatory, localOnly, ... },
referencePointReq SEQUENCE (SIZE (1..8)) OF
OMA-LPPe-ReferencePointUniqueID OPTIONAL,
...
}
OMA-LPPe-ScheduledLocation-Request ::= SEQUENCE {
gnssTime GNSS-SystemTime OPTIONAL, --Cond AtLeastOne
networkTime NetworkTime OPTIONAL, --Cond AtLeastOne
relativeTime INTEGER (1..1024) OPTIONAL, --Cond AtLeastOne
windowSize INTEGER (1..1024) OPTIONAL,
...
}
OMA-LPPe-AccessTypeRequest ::= SEQUENCE {
...
}
OMA-LPPe-SegmentedLIResume ::= SEQUENCE {
segmentedLI-session-ID INTEGER (1..256),
next-segment-number INTEGER (1..4096)}
OMA-LPPe-LocationSource ::= SEQUENCE {
agnss NULL OPTIONAL,
otdoa NULL OPTIONAL,
eotd NULL OPTIONAL,
otdoaUTRA NULL OPTIONAL,
ecidLTE NULL OPTIONAL,
ecidGSM NULL OPTIONAL,
ecidUTRA NULL OPTIONAL,
wlanAP NULL OPTIONAL,
srn NULL OPTIONAL,
sensors NULL OPTIONAL,
inertialSensor NULL OPTIONAL,
magnetometer NULL OPTIONAL,
odometer NULL OPTIONAL,
bfa NULL OPTIONAL,
...
}
-- ASN1STOP
|Conditional presence |Explanation |
|RequestPeriodicLocInfoWithUpdate |As per OMA LPPe [5]. |
|AtLeastOne |As per OMA LPPe [5]. |
|segmentedTransferResume |As per OMA LPPe [5]. |
|OMA-LPPe-CommonIEsRequestLocationInformation field descriptions |
|iP-Address-Request |
|As per OMA LPPe [5]. |
|locationInformationContainerRequest |
|As per OMA LPPe [5]. |
|requestPeriodicLocInfoWithUpdate |
|As per OMA LPPe [5]. |
|relativeLocationChange-Request |
|As per OMA LPPe [5]. |
|localPositionRequest |
|As per OMA LPPe [5]. |
|scheduledLocation-Request |
|As per OMA LPPe [5]. |
|accessTypeRequest |
|As per OMA LPPe [5]. |
|segmentedLIpreference |
|As per OMA LPPe [5]. |
|segmentedLIResume |
|As per OMA LPPe [5]. |
|locationSourceReq |
|[tbd]. |
3 CommonIEsProvideLocationInformation
-- ASN1START
CommonIEsProvideLocationInformation ::= SEQUENCE {
locationEstimate LocationCoordinates OPTIONAL,
velocityEstimate Velocity OPTIONAL,
accelerationEstimate GBLS-Acceleration OPTIONAL,
headingEstimate GBLS-Heading OPTIONAL,
reportedQoS GBLS-ReportedQoS OPTIONAL,
locationError LocationError OPTIONAL,
alerts GBLS-IntegrityAlerts OPTIONA
locatioTargetId GBLS-LocationTargetId OPTIONAL
...
}
LocationCoordinates ::= CHOICE {
ellipsoidPoint Ellipsoid-Point,
ellipsoidPointWithUncertaintyCircle Ellipsoid-PointWithUncertaintyCircle,
ellipsoidPointWithUncertaintyEllipse EllipsoidPointWithUncertaintyEllipse,
polygon Polygon,
ellipsoidPointWithAltitude EllipsoidPointWithAltitude,
ellipsoidPointWithAltitudeAndUncertaintyEllipsoid EllipsoidPointWithAltitudeAndUncertaintyEllipsoid,
ellipsoidArc EllipsoidArc,
...
}
Velocity ::= CHOICE {
horizontalVelocity HorizontalVelocity,
horizontalWithVerticalVelocity HorizontalWithVerticalVelocity,
horizontalVelocityWithUncertainty HorizontalVelocityWithUncertainty,
horizontalWithVerticalVelocityAndUncertainty HorizontalWithVerticalVelocityAndUncertainty,
...
}
GBLS-Acceleration ::= CHOICE {
acceleration INTEGER(0..[tbd])
...
}
GBLS-Heading ::= CHOICE {
heading INTEGER(0..[tbd])
...
}
GBLS-ReportedQoS::= SEQUENCE {
confidenceLevels GBLS-ConfidenceLevels OPTIONAL, -- clReporting
uncertaintyMeasures GBLS-UncertaintyMeasures OPTIONAL, -- uncerMeasuresReq
qosIndicators GBLS-QosIndicators OPTIONAL, -- targetAccuracyReq
authenticationIndicators GBLS-AuthenticationIndicators OPTIONAL, -- authReq
}
LocationError ::= SEQUENCE {
locationfailurecause LocationFailureCause,
...
}
LocationFailureCause ::= ENUMERATED {
undefined,
requestedMethodNotSupported,
positionMethodFailure,
periodicLocationMeasurementsNotAvailable,
...
}
GBLS-IntegrityAlerts ::= SEQUENCE {
hplAlert HplALert OPTIONAL,
vplAlert VplAlert OPTIONAL,
velocityAlert VelocityALert OPTIONAL,
headingAlert HeadingAlert OPTIONAL,
...
}
HplALert ::= CHOICE {
DoNotUse BOOLEAN,
NotMonitored BOOLEAN,
...
}
VplALert ::= CHOICE {
DoNotUse BOOLEAN,
NotMonitored BOOLEAN,
...
}
VelocityALert ::= CHOICE {
DoNotUse BOOLEAN,
NotMonitored BOOLEAN,
...
}
HeadingALert ::= CHOICE {
DoNotUse BOOLEAN,
NotMonitored BOOLEAN,
...
}
GBLS-LocationTargetId ::= SEQUENCE {
[tbd]
...
}
-- ASN1STOP
|Conditional presence |Explanation |
|clReporting |This field is mandatory present if the associated location information request requires for one or several |
| |measure accuracy estimates (among horizontal position, vertical position, velocity, acceleration and |
| |heading), with “confidence class” set to “INFO”, |
| |It can be equal to the “confidence” set in the location information request, or lower in case the measure |
| |accuracy estimate computed cannot meet the required confidence level. |
|uncerMeasuresReq |This field is mandatory present if the associated location information request requires for one or several |
| |measure accuracy estimates among acceleration and heading, with “confidence class” set to “INFO” or “ALERT”, |
|targetAccuracyReq |This field is mandatory present if the associated location information request requires for a targeted |
| |accuracy for one or several measures (among horizontal position, vertical position, velocity and heading), |
| |with “qosclass” set to “BEST EFFORT”, |
|authReq |This field is mandatory present if the associated location information request requires for one or several |
| |authenticated measures (among horizontal position, vertical position, velocity, acceleration and heading). |
|CommonIEsProvideLocationInformation field descriptions |
|locationEstimate |
|As per 3GPP LPP [6] |
|velocityEstimate |
|As per 3GPP LPP [6] |
|accelerationEstimate |
|[tbd] |
|headingEstimate |
|[tbd] |
|reportedQoS |
|[tbd] |
|confidenceLevels |
|uncertaintyMeasures |
|qosIndicators |
|authenticationIndicators |
|locationError |
|As per 3GPP LPP [6] |
|alerts |
|[tbd] |
|locationTargetId |
|[tbd] |
|[Editorial note : while locationTargetIdReq, in “Common location information request”, can cover a group of targets, the locationTargetId in |
|“Common location information provide”points on a single target id. |
|We indeed assume that the “common location information provide” message contains information for a single target, while the “request” message |
|can contain information request related to several targets] |
4 OMA-LPPe-CommonIEsProvideLocationInformation
-- ASN1START
OMA-LPPe-CommonIEsProvideLocationInformation ::= SEQUENCE {
highAccuracy3Dposition OMA-LPPe-HighAccuracy3Dposition OPTIONAL,
--Cond HighAccuracy
localPosition OMA-LPPe-LocalPosition OPTIONAL,
highAccuracy3Dvelocity OMA-LPPe-HighAccuracy3Dvelocity OPTIONAL,
--Cond HighAccuracy
iP-Address-List OMA-LPPe-IP-Address-List OPTIONAL,
locationInformationContainer OMA-LPPe-LocationInformationContainer OPTIONAL,
providePeriodicLocInfoWithUpdate OMA-LPPe-ProvidePeriodicLocInfowithUpdate OPTIONAL,
--Cond ProvidePeriodicLocInfoWithUpdate
relativeLocationChangeList OMA-LPPe-RelativeLocationChangeList OPTIONAL,
scheduledLocation OMA-LPPe-ScheduledLocation OPTIONAL,
--Cond ScheduledLocationRequested
accessTypes OMA-LPPe-AccessTypes OPTIONAL,
segmentedLITransfer OMA-LPPe-SegmentedLITransfer OPTIONAL,
--Cond segmentedTransferWithResume
locationInformationTimeStamp OMA-LPPe-TimeStamp OPTIONAL,
...,
locationSource OMA-LPPe-LocationSource OPTIONAL --Cond LocationSource
}
OMA-LPPe-LocalPosition ::= SEQUENCE {
referencePoint OMA-LPPe-ReferencePointUniqueID,
subjectLocation OMA-LPPe-RelativeLocation OPTIONAL,
...
}
OMA-LPPe-IP-Address-List ::= SEQUENCE (SIZE (1..maxIPAddress)) OF OMA-LPPe-IP-Address
maxIPAddress INTEGER ::= 5
OMA-LPPe-IP-Address ::= SEQUENCE {
local-IP-Address CHOICE {
iPv4 BIT STRING (SIZE(32)),
iPv6 BIT STRING (SIZE(128)),
...
},
bearer OMA-LPPe-Bearer,
nat BOOLEAN OPTIONAL,
...
}
OMA-LPPe-Bearer ::= ENUMERATED {
unknown,
gsm,
utran,
lte,
wlan,
wimax,
dsl,
pktcable,
other,
...
}
OMA-LPPe-ProvidePeriodicLocInfowithUpdate ::= SEQUENCE {
session-ID OCTET STRING (SIZE(4)),
typeOfLocInfoProvide OMA-LPPe-TypeOfLocInfoProvide,
...
}
OMA-LPPe-TypeOfLocInfoProvide ::= ENUMERATED {
responseToInitialRequest,
providePeriodicLocInfo,
responseToServerUpdateRequest,
targetUpdate,
...
}
OMA-LPPe-RelativeLocationChangeList ::= SEQUENCE (SIZE (1..maxRelativeLocation)) OF
OMA-LPPe-RelativeLocationChange
OMA-LPPe-RelativeLocationChange ::= SEQUENCE {
relativeTime INTEGER (0..65535) OPTIONAL,
transactionID INTEGER (0..255) OPTIONAL,
relativeLocation OMA-LPPe-RelativeLocation,
...
}
maxRelativeLocation INTEGER ::= 5
OMA-LPPe-ScheduledLocation ::= SEQUENCE {
disposition ENUMERATED {withinWindow,
outsideWindowOrNoWindow,
notSupportedDueToNoCapability,
notSupportedDueToNoTimeReference,
notSupportedDueToConflictWithAnotherRequest,
notSupportedForOtherReasons,
... },
actualWindow SEQUENCE {
start INTEGER (-512..511),
duration INTEGER (0..2047)
} OPTIONAL,
...
}
OMA-LPPe-AccessTypes ::= SEQUENCE {
accessTypeUnknown NULL OPTIONAL,
fixedAccessTypes OMA-LPPe-FixedAccessTypes OPTIONAL,
wirelessAccessTypes OMA-LPPe-WirelessAccessTypes OPTIONAL,
...
}
OMA-LPPe-SegmentedLITransfer ::= SEQUENCE {
segmentedLI-session-ID INTEGER (1..256),
segment-number INTEGER (1..4096),
...
}
OMA-LPPe-TimeStamp ::= CHOICE {
gnssTime GNSS-SystemTime,
networkTime NetworkTime,
relativeTime INTEGER (0..1024),
...
}
OMA-LPPe-LocationSource ::= SEQUENCE {
agnss NULL OPTIONAL,
otdoa NULL OPTIONAL,
eotd NULL OPTIONAL,
otdoaUTRA NULL OPTIONAL,
ecidLTE NULL OPTIONAL,
ecidGSM NULL OPTIONAL,
ecidUTRA NULL OPTIONAL,
wlanAP NULL OPTIONAL,
srn NULL OPTIONAL,
sensors NULL OPTIONAL,
inertialSensor NULL OPTIONAL,
magnetometer NULL OPTIONAL,
odometer NULL OPTIONAL,
bfa NULL OPTIONAL,
...
}
-- ASN1STOP
|Conditional presence |Explanation |
|HighAccuracy |As per OMA LPPe [5]. |
|ProvidePeriodicLocInfoWithUpdate |As per OMA LPPe [5]. |
|ScheduledLocationRequested |As per OMA LPPe [5]. |
|segmentedTransferWithResume |As per OMA LPPe [5]. |
|LocationSource |As per OMA LPPe [5]. |
|OMA-LPPe-CommonIEsProvideLocationInformation field descriptions |
|highaccuracy3Dposition |
|As per OMA LPPe [5]. |
|localPosition |
|As per OMA LPPe [5]. |
|highaccuracy3Dvelocity |
|As per OMA LPPe [5]. |
|iP-Address-List |
|As per OMA LPPe [5]. |
|locationInformationContainer |
|As per OMA LPPe [5]. |
|providePeriodicLocInfoWithUpdate |
|As per OMA LPPe [5]. |
|relativeLocationChangeList |
|As per OMA LPPe [5]. |
|scheduledLocation |
|As per OMA LPPe [5]. |
|accessTypes |
|As per OMA LPPe [5]. |
|segmentedLITransfer |
|As per OMA LPPe [5]. |
|referencePoint |
|As per OMA LPPe [5]. |
|subjectLocation |
|As per OMA LPPe [5]. |
|local-IP-Address |
|As per OMA LPPe [5]. |
|bearer |
|As per OMA LPPe [5]. |
|nat |
|As per OMA LPPe [5]. |
|session-ID |
|As per OMA LPPe [5]. |
|typeOfLocInfoProvide |
|As per OMA LPPe [5]. |
|relativeTime |
|As per OMA LPPe [5]. |
|transactionID |
|As per OMA LPPe [5]. |
|relativeLocation |
|As per OMA LPPe [5]. |
|locationInformationTimestamp |
|As per OMA LPPe [5]. |
|locationSource |
|[tbd] |
|OMA says : This parameter indicates the positioning technologies involved in calculating a UE-based position estimate sent by the target to the |
|server. The parameter is encoded as a bitmap and lists the following positioning technologies: |
| |
|agnss: Assisted-GNSS |
|otdoa: OTDOA on LTE |
|eotd: E-OTD (GSM) |
|otdoaUTRA: OTDOA on UTRA |
|ecidLTE: E-CID on LTE |
|ecidGSM: E-CID on GSM |
|ecidUTRA: E-CID on UTRA |
|wlanAP: WLAN AP |
|srn: SRN |
|sensors: Sensors |
| |
|If more than one positioning technology is indicated, the target calculated a final position result reported to the server by appropriately combining|
|individual position results (hybrid positioning). |
2 Specific Positioning Method IEs
1 AGNSS Positioning
1 OMA-LPPe-AGNSS-ProvideAssistanceData
-- ASN1START
OMA-LPPe-AGNSS-ProvideAssistanceData ::= SEQUENCE {
commonAssistData OMA-LPPe-AGNSS-CommonAssistData OPTIONAL,
genericAssistData OMA-LPPe-AGNSS-GenericAssistData OPTIONAL,
error OMA-LPPe-AGNSS-Error OPTIONAL,
...
}
-- ASN1STOP
2 OMA-LPPe-AGNSS-CommonAssistData
-- ASN1START
OMA-LPPe-AGNSS-CommonAssistData::= SEQUENCE {
ionosphericModel OMA-LPPe-AGNSS-IonosphericModel OPTIONAL,
troposphereModel OMA-LPPe-AGNSS-TroposphereModel OPTIONAL,
altitudeAssistance OMA-LPPe-AGNSS-AltitudeAssistanceList OPTIONAL,
solarRadiation OMA-LPPe-AGNSS-SolarRadiation OPTIONAL,
ccpAssistCommonProvide OMA-LPPe-AGNSS-CCPassistCommonProvide OPTIONAL,
dllCommandAssistCommonProvide GBLS-AGNSS-DLLCommandAssistCommonProvide OPTIONAL,
pllCommandAssistCommonProvide GBLS-AGNSS-PLLCommandAssistCommonProvide OPTIONAL,
...
}
-- ASN1STOP
|OMA-LPPe-AGNSS-CommonAssistanceDataReq field descriptions |
|ionosphericModel |
|As per OMA LPPe [5] |
|troposphereModel |
|As per OMA LPPe [5] |
|altitudeAssistance |
|As per OMA LPPe [5] |
|solarRadiation |
|As per OMA LPPe [5] |
|ccpAssistCommonProvide |
|As per OMA LPPe [5] |
|dllCommandAssistCommonProvide |
|[tbd] |
|pllCommandAssistCommonProvide |
|[tbd] |
3 OMA-LPPe-AGNSS-GenericAssistData
-- ASN1START
OMA-LPPe-AGNSS-GenericAssistData ::= SEQUENCE (SIZE (1..16)) OF OMA-LPPe-AGNSS-GenericAssistDataElement
OMA-LPPe-AGNSS-GenericAssistDataElement ::= SEQUENCE {
gnss-ID GNSS-ID,
wideAreaIonoSurfacePerSVlist OMA-LPPe-AGNSS-WideAreaIonoSurfacePerSVlist OPTIONAL,
mechanicsForAllSVs OMA-LPPe-AGNSS-MechanicsForAllSVs OPTIONAL,
dcbsForAllSVs OMA-LPPe-AGNSS-DCBsForAllSVs OPTIONAL,
navModelDegradationModel OMA-LPPe-AGNSS-NavModelDegradationModelList OPTIONAL,
ccpAssistProvide OMA-LPPe-AGNSS-CCPassistGenericProvide OPTIONAL, --Cond CCP
navModelList OMA-LPPe-AGNSS-NavModelList OPTIONAL,
dllCommandAssistProvide GBLS-AGNSS-DLLCommandAssistGenericProvide OPTIONAL, --Cond DLL
pllCommandAssistProvide GBLS-AGNSS-PLLCommandAssistGenericProvide OPTIONAL, --Cond PLL
...
}
-- ASN1STOP
|Conditional presence |Explanation |
|CCP |The field is mandatory present, when providing continuous carrier phase assistance and reference time is included |
| |in the IE AGNSS-CCPassistCommonProvide. Otherwise the field shall not be present. |
|DLL |[tbd] [same as for CCP] |
|PLL |[tbd] [same as for CCP] |
|OMA-LPPe-AGNSS-GenericAssistData field descriptions |
|gnss-ID |
|As per OMA LPPe [5] |
|wideAreaIonoSurfacePerSVlist |
|As per OMA LPPe [5] |
|mechanicsForAllSVs |
|As per OMA LPPe [5] |
|dcbsForAllSVs |
|As per OMA LPPe [5] |
|navModelDegradationModel |
|As per OMA LPPe [5] |
|ccpAssistProvide |
|As per OMA LPPe [5] |
|navModelList |
|As per OMA LPPe [5] |
|dllCommandAssistProvide |
|[tbd] |
|pllCommandAssistProvide |
|[tbd] |
4 AGNSS Assistance Data Elements
-- ASN1START
GBLS-AGNSS-DLLCommandAssistCommonProvide::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
GBLS-AGNSS-PLLCommandAssistCommonProvide
-- ASN1START
GBLS-AGNSS-PLLCommandAssistCommonProvide::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
GBLS-AGNSS-DLLCommandAssistGenericProvide
-- ASN1START
GBLS-DLLCommandAssistGenericProvide::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
GBLS-AGNSS-PLLCommandAssistGenericProvide
-- ASN1START
GBLS-PLLCommandAssistGenericProvide::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
5 AGNSS Assistance Data Request
OMA-LPPe-AGNSS-RequestAssistanceData
-- ASN1START
OMA-LPPe-AGNSS-RequestAssistanceData::= SEQUENCE {
commonAssistDataReq OMA-LPPe-AGNSS-CommonAssistanceDataReq OPTIONAL,
genericAssistDataReq OMA-LPPe-AGNSS-GenericAssistanceDataReq OPTIONAL,
...
}
-- ASN1STOP
OMA-LPPe-AGNSS-CommonAssistanceDataReq
-- ASN1START
OMA-LPPe-AGNSS-CommonAssistanceDataReq ::= SEQUENCE {
ionosphericModelReq OMA-LPPe-AGNSS-IonosphericModelReq OPTIONAL,
troposphereModelReq OMA-LPPe-AGNSS-TroposphereModelReq OPTIONAL,
altitudeAssistanceReq OMA-LPPe-AGNSS-AltitudeAssistanceReq OPTIONAL,
solarRadiationRequest OMA-LPPe-AGNSS-SolarRadiationReq OPTIONAL,
ccpRequestControlParameters OMA-LPPe-AGNSS-CCPrequestControlParameters OPTIONAL,
dllCommandReqControlParameter GBLS-AGNSS-dllCommandReqControlParameter OPTIONAL,
pllCommandReqControlParameter GBLS-AGNSS-pllCommandReqControlParameter OPTIONAL,
...
}
-- ASN1STOP
|OMA-LPPe-AGNSS-CommonAssistanceDataReq field descriptions |
|ionosphereModelReq |
|As per OMA LPPe [5] |
|troposphereModelReq |
|As per OMA LPPe [5] |
|altitudeAssistanceReq |
|As per OMA LPPe [5] |
|solarRadiationReq |
|As per OMA LPPe [5] |
|ccpRequestControlParameters |
|As per OMA LPPe [5] |
|dllCommandReqControlParameter |
|[tbd] |
|pllCommandReqControlParameter |
|[tbd] |
OMA-LPPe-AGNSS-GenericAssistanceDataReq
-- ASN1START
OMA-LPPe-AGNSS-GenericAssistanceDataReq ::= SEQUENCE (SIZE (1..16)) OF
OMA-LPPe-AGNSS-GenericAssistDataReqElement
OMA-LPPe-AGNSS-GenericAssistDataReqElement ::= SEQUENCE {
gnss-ID GNSS-ID,
waIonoSurfaceReq OMA-LPPe-AGNSS-WaIonoSurfaceRequest OPTIONAL, --Cond WAiono
mechanicsReq OMA-LPPe-AGNSS-MechanicsReq OPTIONAL,
dcbReq OMA-LPPe-AGNSS-DCBreq OPTIONAL,
navModelDegradationModelReq OMA-LPPe-AGNSS-NavModelDegradationModelReq OPTIONAL,
ccpAssistGenericReq OMA-LPPe-AGNSS-CCPassistGenericReq OPTIONAL, --Cond CCPreq
navigationModelReq OMA-LPPe-AGNSS-NavigationModelReq OPTIONAL,
dllCommandAssistGenericReq GBLS-AGNSS-dllCommandAssistGenericReq OPTIONAL, --Cond dllreq
pllCommandAssistGenericReq GBLS-AGNSS-pllCommandAssistGenericReq OPTIONAL, --Cond pllreq
...
}
-- ASN1STOP
|Conditional presence |Explanation |
|WAiono |As per OMA LPPe [5] |
|CCPreq |As per OMA LPPe [5] |
|dllreq |[tbd] |
|pllreq |[tbd] |
|OMA-LPPe-AGNSS-GenericAssistanceDataReq field descriptions |
|waIonoSurfaceReq |
|As per OMA LPPe [5] |
|mechanicsReq |
|As per OMA LPPe [5] |
|dcbReq |
|As per OMA LPPe [5] |
|navModelDegradationModelReq |
|As per OMA LPPe [5] |
|ccpAssistGenericReq |
|As per OMA LPPe [5] |
|navigationModelReq |
|As per OMA LPPe [5] |
|dllCommandAssistGenericReq |
|[tbd] |
|pllCommandAssistGenericReq |
|[tbd] |
6 AGNSS Assistance Data Elements
GBLS-AGNSS-DLLCommandAssistCommonProvide
-- ASN1START
GBLS-AGNSS-DLLCommandAssistCommonProvide::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
GBLS-AGNSS-PLLCommandAssistCommonProvide
-- ASN1START
GBLS-AGNSS-PLLCommandAssistCommonProvide::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
GBLS-AGNSS-DLLCommandAssistGenericProvide
-- ASN1START
GBLS-DLLCommandAssistGenericProvide::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
GBLS-AGNSS-PLLCommandAssistGenericProvide
-- ASN1START
GBLS-PLLCommandAssistGenericProvide::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
7 AGNSS Assistance Data Request
OMA-LPPe-AGNSS-RequestAssistanceData
-- ASN1START
OMA-LPPe-AGNSS-RequestAssistanceData::= SEQUENCE {
commonAssistDataReq OMA-LPPe-AGNSS-CommonAssistanceDataReq OPTIONAL,
genericAssistDataReq OMA-LPPe-AGNSS-GenericAssistanceDataReq OPTIONAL,
...
}
-- ASN1STOP
OMA-LPPe-AGNSS-CommonAssistanceDataReq
-- ASN1START
OMA-LPPe-AGNSS-CommonAssistanceDataReq ::= SEQUENCE {
ionosphericModelReq OMA-LPPe-AGNSS-IonosphericModelReq OPTIONAL,
troposphereModelReq OMA-LPPe-AGNSS-TroposphereModelReq OPTIONAL,
altitudeAssistanceReq OMA-LPPe-AGNSS-AltitudeAssistanceReq OPTIONAL,
solarRadiationRequest OMA-LPPe-AGNSS-SolarRadiationReq OPTIONAL,
ccpRequestControlParameters OMA-LPPe-AGNSS-CCPrequestControlParameters OPTIONAL,
dllCommandReqControlParameter GBLS-AGNSS-dllCommandReqControlParameter OPTIONAL,
pllCommandReqControlParameter GBLS-AGNSS-pllCommandReqControlParameter OPTIONAL,
...
}
-- ASN1STOP
|OMA-LPPe-AGNSS-CommonAssistanceDataReq field descriptions |
|ionosphereModelReq |
|As per OMA LPPe [5] |
|troposphereModelReq |
|As per OMA LPPe [5] |
|altitudeAssistanceReq |
|As per OMA LPPe [5] |
|solarRadiationReq |
|As per OMA LPPe [5] |
|ccpRequestControlParameters |
|As per OMA LPPe [5] |
|dllCommandReqControlParameter |
|[tbd] |
|pllCommandReqControlParameter |
|[tbd] |
OMA-LPPe-AGNSS-GenericAssistanceDataReq
-- ASN1START
OMA-LPPe-AGNSS-GenericAssistanceDataReq ::= SEQUENCE (SIZE (1..16)) OF
OMA-LPPe-AGNSS-GenericAssistDataReqElement
OMA-LPPe-AGNSS-GenericAssistDataReqElement ::= SEQUENCE {
gnss-ID GNSS-ID,
waIonoSurfaceReq OMA-LPPe-AGNSS-WaIonoSurfaceRequest OPTIONAL, --Cond WAiono
mechanicsReq OMA-LPPe-AGNSS-MechanicsReq OPTIONAL,
dcbReq OMA-LPPe-AGNSS-DCBreq OPTIONAL,
navModelDegradationModelReq OMA-LPPe-AGNSS-NavModelDegradationModelReq OPTIONAL,
ccpAssistGenericReq OMA-LPPe-AGNSS-CCPassistGenericReq OPTIONAL, --Cond CCPreq
navigationModelReq OMA-LPPe-AGNSS-NavigationModelReq OPTIONAL,
dllCommandAssistGenericReq GBLS-AGNSS-dllCommandAssistGenericReq OPTIONAL, --Cond dllreq
pllCommandAssistGenericReq GBLS-AGNSS-pllCommandAssistGenericReq OPTIONAL, --Cond pllreq
...
}
-- ASN1STOP
|Conditional presence |Explanation |
|WAiono |As per OMA LPPe [5] |
|CCPreq |As per OMA LPPe [5] |
|dllreq |[tbd] |
|pllreq |[tbd] |
|OMA-LPPe-AGNSS-GenericAssistanceDataReq field descriptions |
|waIonoSurfaceReq |
|As per OMA LPPe [5] |
|mechanicsReq |
|As per OMA LPPe [5] |
|dcbReq |
|As per OMA LPPe [5] |
|navModelDegradationModelReq |
|As per OMA LPPe [5] |
|ccpAssistGenericReq |
|As per OMA LPPe [5] |
|navigationModelReq |
|As per OMA LPPe [5] |
|dllCommandAssistGenericReq |
|[tbd] |
|pllCommandAssistGenericReq |
|[tbd] |
8 AGNSS Assistance Data Request Elements
GBLS-dllCommandReqControlParameter
-- ASN1START
GBLS-AGNSS-dllCommandReqControlParameter::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
GBLS-pllCommandReqControlParameter
-- ASN1START
GBLS-AGNSS-pllCommandReqControlParameter::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
GBLS-dllCommandAssistGenericReq
-- ASN1START
GBLS-AGNSS-dllCommandAssistGenericReq ::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
GBLS-pllCommandAssistGenericReq
-- ASN1START
GBLS-AGNSS-pllCommandAssistGenericReq ::= SEQUENCE {
xx xx xx
...
}
-- ASN1STOP
9 AGNSS Location Information
OMA-LPPe-AGNSS-ProvideLocationInformation
-- ASN1START
OMA-LPPe-AGNSS-ProvideLocationInformation ::= SEQUENCE {
highAccuracyReferenceTime GNSS-SystemTime OPTIONAL, --Cond HighAccuracy
highAccuracyMeasurements OMA-LPPe-AGNSS-HAgnssProvide OPTIONAL,
ionosphereMeasurements OMA-LPPe-AGNSS-IonosphereMeasurements OPTIONAL,
localSurfaceMeasurements OMA-LPPe-AGNSS-LocalSurfaceMeasurements OPTIONAL,
rfSamplingMeasurements GBLS-GNSS-RfSamples OPTIONAL,
error OMA-LPPe-AGNSS-Error OPTIONAL,
...
}
-- ASN1STOP
10 AGNSS Location Information elements
GBLS-GNSS-RfSamples
-- ASN1START
GBLS-GNSS-RfSamples ::= SEQUENCE {
[tdb],
...
}
-- ASN1STOP
OMA-LPPe-AGNSS-RequestLocationInformation
-- ASN1START
OMA-LPPe-AGNSS-RequestLocationInformation ::= SEQUENCE {
positioningInstructions OMA-LPPe-AGNSS-PositioningInstructions OPTIONAL,
ionosphereMeasurementsReq BIT STRING {tecPerSV(0), zenithTEC(1) }(SIZE(1..8)) OPTIONAL,
localSurfaceMeasurementReq OMA-LPPe-AGNSS-LocalSurfaceMeasurementReq OPTIONAL,
...
}
-- ASN1STOP
|OMA-LPPe-AGNSS-RequestLocationInformation field descriptions |
|positioningInstructions |
|[tbd] |
|ionosphereMeasurementsReq |
|As per OMA LPPe [5] |
|localSurfaceMeasurementReq |
|As per OMA LPPe [5] |
11 AGNSS Location Information Request elements
OMA-LPPe-AGNSS-PositioningInstructions
-- ASN1START
OMA-LPPe-AGNSS-PositioningInstructions ::= SEQUENCE {
highAccuracyMethodRequested BOOLEAN,
haGNSSreq OMA-LPPe-AGNSS-HAgnssRequestControlParameters OPTIONAL, --Cond HAgnssReq
rfSamplesRequested BOOLEAN
rfSamplesParameters GBLS-RFSamplesControlParameters OPTIONAL, --Cond RFsampReq
...
}
-- ASN1STOP
|Conditional presence |Explanation |
|HAgnssReq |As per OMA LPPe [5] |
|RDsampReq |[tbd] |
|highAccuracyMethodRequested |
|As per OMA LPPe [5] |
|haGNSSreq |
|As per OMA LPPe [5] |
|rfSamplesParameters |
|[tbd] |
|rfSamplesRequested |
|[tbd] |
GBLS-RFSamplesControlParameters
-- ASN1START
GBLS-RFSamplesControlParameters ::= SEQUENCE {
[tbd] ,
...
}
-- ASN1STOP
12 GNSS Timing Information
-- ASN1START
GNSS-ProvideTimingInformation ::= SEQUENCE {
reportedTimingQoS ReportedTimingQoS OPTIONAL,
timingError TimingError OPTIONAL,
...
}
ReportedTimingQoS::= SEQUENCE {
TimingUncertainty INTEGER(0..[tbd]) OPTIONAL, -- timeUncertReq
TimingCL INTEGER(0..100) OPTIONAL, -- timeCLReporting
TimingAccuracyNotMet BOOLEAN OPTIONAL, -- timeTargetAccReq
TimingAuthentication BOOLEAN OPTIONAL, -- timeAuthReq
...
}
-- ASN1STOP
|Conditional presence |Explanation |
|timeUncertReq |This field is mandatory present if the associated timing information request requires for time accuracy |
| |estimate. |
|timeCLReporting |This field is mandatory present if the associated timing information request requires for time accuracy |
| |estimates. |
| |It can be equal to the “confidence” set in the timing information request, or lower in case the timing |
| |accuracy estimate computed cannot meet the required confidence level. |
|timeTargetAccReq |This field is mandatory present if the associated timing information request requires for a targeted timing |
| |accuracy, with “qosclass” set to “BEST EFFORT”, |
|timeAuthReq |This field is mandatory present if the associated timing information request requires for authenticated |
| |timing. |
|GNSS-ProvideTimingInformation field descriptions |
|reportedTimingQoS |
|[tbd] |
|TimingUncertainty |
|TimingCL |
|TimingAccuracyNotMet |
|TimingAuthentication |
|timingError |
|[tbd] |
13 GNSS Timing Information Request
-- ASN1START
GNSS-RequestTimingInformation ::= SEQUENCE {
timingInformationType timingInformationType,
timeTransferMethod ENUMERATED { pTPrequired,
pTPpreferred,
iRIGBrequired,
iRIGBpreferred,
nTPrequired,
nTPpreferred,
sNTPrequired,
sNTPpreferred,
pPStimeTagingRequered,
pPStimeTagingPreferred,
},
timingQoS TimingQoS OPTIONAL,
...
}
timingInformationType ::= SEQUENCE {
gnss-Methods GNSS-ID-Bitmap
multiFreqMeasReq BOOLEAN,
assistanceAvailability BOOLEAN,
timeAccuracyEstimate BOOLEAN
...
}
TimingQoS ::= SEQUENCE {
synchroAccuracy SynchroAccuracy OPTIONAL
synchroAuthentication BOOLEAN,
...
}
SynchroAccuracy n::= SEQUENCE {
accuracy INTEGER(0..127), OPTIONAL
confidence INTEGER(0..100), OPTIONAL
Qos class ENUMERATED { ASSURED,
BEST_EFFORT, ...} OPTIONAL
...
}
-- ASN1STOP
|GNSS-RequestTimingInformation field descriptions |
|timingInformationType |
|[tbd] |
|timeTransferMethod |
|[tbd] |
|timingQoS |
|[tbd] |
|synchroAccuracy : see table below |
|synchroAuthentication : [tbd] |
| |
|The table below indicates how IE synchroAccuracy is structured : |
| |
| |
|accuracy field |
|confidence field |
|qosClass field |
|Explanation |
| |
|Case 1 |
|present |
|absent |
|ASSURED |
|Targeted synchronization accuracy is specified, and only synchronization signal complying with targeted accuracy shall be provided. |
| |
|Case 2 |
|present |
|absent |
|BEST EFFORT |
|Targeted synchronization accuracy is specified, and synchronization signal not complying with targeted accuracy shall be flagged in the subsequent |
|answer (using IE “GBLS-QosIndicators”). |
| |
|Case 3 |
|absent |
|present |
|absent |
|Estimation of the measure accuracy is required. Accuracy estimate should comply with the required confidence level. In CL cannot be met, it shall be |
|indicated in the subsequent answer (using IE “GBLS-ConfidenceLevels”). |
| |
| |
14 AGNSS Error
OMA-LPPe-AGNSS-Error
-- ASN1START
OMA-LPPe-AGNSS-Error ::= CHOICE {
agnss-locationServerErrorCauses OMA-LPPe-AGNSS-LocationServerErrorCauses,
agnss-targetDeviceErrorCauses OMA-LPPe-AGNSS-TargetDeviceErrorCauses,
...
}
-- ASN1STOP
[add in IE above new potential error message, for instance Timing Error]
2 Inertial Sensor positioning
1 Inertial Sensor Assistance Data
GBLS-IntertialSensor-ProvideAssistanceData
-- ASN1START
GBLS-IntertialSensor-ProvideAssistanceData::= SEQUENCE {
motionStateList OMA-LPPe-Sensor-MotionStateList OPTIONAL,
sensorError OMA-LPPe-Sensor-Error OPTIONAL,
}
-- ASN1STOP
2 Inertial Sensor Assistance Data Request
GBLS-IntertialSensor-RequestAssistanceData
-- ASN1START
GBLS-IntertialSensor-RequestAssistanceData::= SEQUENCE {
motionStateReq OMA-LPPe-Sensor-MotionStateRequest OPTIONAL, --Cond MotionSateReq
}
-- ASN1STOP
|Conditional presence |Explanation |
|MotionStateReq |The field is mandatory present if the sensor requests for primary motion state measurements; otherwise it is not |
| |present. |
3 Inertial Sensor Location Information Request
GBLS-IntertialSensor-RequestLocationInformation
-- ASN1START
GBLS-IntertialSensor-RequestLocationInformation::= SEQUENCE {
sensorGyroInformationReq GBLS-GyroInformationRequest OPTIONAL
sensorAccelerometerInformationReq GBLS-AccelerometerInformationRequest OPTIONAL
}
-- ASN1STOP
4 Inertial Sensor Location Information Request elements
GBLS-GyroInformationRequest
-- ASN1START
GBLS-GyroInformationRequest::= SEQUENCE {
gyroXReq BOOLEAN,
gyroYReq BOOLEAN,
gyroZReq BOOLEAN,
}
-- ASN1STOP
GBLS-AccelerometerInformationRequest
-- ASN1START
GBLS-AccelerometerInformationRequest::= SEQUENCE {
AccelXReq BOOLEAN,
AccelYReq BOOLEAN,
AccelZReq BOOLEAN,
}
-- ASN1STOP
5 Inertial Sensor Location Information
GBLS-InertialSensor-ProvideLocationInformation
-- ASN1START
GBLS-InertialSensor-ProvideLocationInformation::= SEQUENCE {
sensorCaseCRM OMA-LPPe-Orientation OPTIONAL
sensoBodyCRM OMA-LPPe-Orientation OPTIONAL
sensorGyroInformation GBLS-GyroInformation OPTIONAL
sensorAccelerometerInformation GBLS-AccelerometerInformation OPTIONAL
}
-- ASN1STOP
6 Inertial Sensor Location Information elements
GBLS-GyroInformation
-- ASN1START
GBLS-GyroInformation::= SEQUENCE {
sensorGyroMeasurments GBLS-GyroMeasurementInformation OPTIONAL
...
}
-- ASN1STOP
GBLS-GyroMeasurementInformation
-- ASN1START
GBLS-GyroMeasurementInformation::= SEQUENCE {
SensorX INTEGER(-tbd..tbd) OPTIONAL Cond
SensorY INTEGER(-tbd..tbd) OPTIONAL Cond
SensorZ INTEGER(-tbd..tbd) OPTIONAL Cond
SensorErrEstX INTEGER(-tbd..tbd) OPTIONAL Cond
SensorErrEstY INTEGER(-tbd..tbd) OPTIONAL Cond
SensorErrEstZ INTEGER(-tbd..tbd) OPTIONAL Cond
...
}
-- ASN1STOP
GBLS-AccelerometerInformation
-- ASN1START
GBLS-AccelerometerInformation::= SEQUENCE {
sensorAccelerometerMeasurments GBLS-AccelerometerMeasurementInformation OPTIONAL
...
}
-- ASN1STOP
GBLS-AccelerometerMeasurementInformation
-- ASN1START
GBLS-AccelerometerMeasurementInformation::= SEQUENCE {
SensorX INTEGER(-tbd..tbd) OPTIONAL
SensorY INTEGER(-tbd..tbd) OPTIONAL
SensorZ INTEGER(-tbd..tbd) OPTIONAL
SensorErrEstX INTEGER(-tbd..tbd) OPTIONAL
SensorErrEstY INTEGER(-tbd..tbd) OPTIONAL
SensorErrEstZ INTEGER(-tbd..tbd) OPTIONAL
...
}
-- ASN1STOP
3 Magnetometer positioning
1 Magnetometer Assistance Data
GBLS-Magnetometer-ProvideAssistanceData
-- ASN1START
GBLS-Magnetometer-ProvideAssistanceData::= SEQUENCE {
magnetoTemperature GBLS-MagnetometerTemperature OPTIONAL Cond
}
-- ASN1STOP
2 Magnetometer Assistance Data elements
GBLS-MagnetometerTemperature
-- ASN1START
GBLS-MagnetometerTemperature::= SEQUENCE {
temperature INTEGER (-64..63)
temperatureUnit ENUMERATED{ celsius, kelvin, ... },
}
-- ASN1STOP
3 Magnetometer Assistance Data Request
GBLS-Magnetometer-RequestAssistanceData
-- ASN1START
GBLS-Magnetometer-RequestAssistanceData::= SEQUENCE {
magnetoTemperatuReq GBLS-MagnetometerTemperatureRequest OPTIONAL
}
-- ASN1STOP
4 Magnetometer Assistance Data Request elements
GBLS-MagnetometerTemperatureRequest
-- ASN1START
GBLS-MagnetometerTemperatureRequest::= SEQUENCE {
temperatureUnit ENUMERATED{ celsius, kelvin, ... }, OPTIONAL
}
-- ASN1STOP
5 Magnetometer Location Information
GBLS-Magnetometer-ProvideLocationInformation
-- ASN1START
GBLS-Magnetometer-ProvideLocationInformation::= SEQUENCE {
sensorCaseCRM OMA-LPPe-Orientation OPTIONAL
sensoBodyCRM OMA-LPPe-Orientation OPTIONAL
sensorMagnetometerInformation GBLS-MagnetometerInformation OPTIONAL
}
-- ASN1STOP
6 Magnetometer Location Information elements
GBLS-MagnetometerInformation
-- ASN1START
GBLS-MagnetometerInformation::= SEQUENCE {
sensorCaseCRM OMA-LPPe-Orientation OPTIONAL
sensoBodyCRM OMA-LPPe-Orientation OPTIONAL
sensorMagnetometerMeasurments GBLS-MagnetometerMeasurementInformation OPTIONAL
...
}
-- ASN1STOP
|GBLS-MagnetometerInformation field descriptions |
| |
| |
| |
| |
| |
GBLS-MagnetometerMeasurementInformation
-- ASN1START
GBLS-MagnetometerMeasurementInformation::= SEQUENCE {
xMagField INTEGER(-tbd..tbd) OPTIONAL, Cond
yMagField INTEGER(-tbd..tbd) OPTIONAL, Cond
zMagField INTEGER(-tbd..tbd) OPTIONAL, Cond
heading INTEGER(-tbd..tbd) OPTIONAL, Cond
MagFieldStrength INTEGER(-tbd..tbd) OPTIONAL, Cond
xMagFieldErrEst INTEGER(-tbd..tbd) OPTIONAL, Cond
yMagFieldErrEst INTEGER(-tbd..tbd) OPTIONAL, Cond
zMagFieldErrEst INTEGER(-tbd..tbd) OPTIONAL, Cond
headingErrEst INTEGER(-tbd..tbd) OPTIONAL, Cond
MagFieldStrengthErrEst INTEGER(-tbd..tbd) OPTIONAL, Cond
}
-- ASN1STOP
|GBLS- MagnetometerMeasurementInformation field descriptions |
| |
| |
| |
7 Magnetometer Location Information Request
GBLS-Magnetometer-RequestLocationInformation
-- ASN1START
GBLS-Magnetometer-RequestLocationInformation::= SEQUENCE {
magnetometerInformationType GBLS-MagnetometerInformationType OPTIONAL
}
-- ASN1STOP
8 Magnetometer Location Information Request elements
GBLS-MagnetometerInformationType
-- ASN1START
GBLS-MagnetometerInformationType::= SEQUENCE {
xMagFieldReq BOOLEAN,
yMagFieldReq BOOLEAN,
zMagFieldReq BOOLEAN,
headingReq BOOLEAN,
MagFieldStrengthReq BOOLEAN,
}
-- ASN1STOP
4 Odometer positioning
1 Odometer Assistance Data
GBLS-Odometer-ProvideAssistanceData
-- ASN1START
GBLS-Odometer-ProvideAssistanceData::= SEQUENCE {
wheeleInformation GBLS-WheeleInformation OPTIONAL Cond
}
-- ASN1STOP
2 Odometer Assistance Data Elements
GBLS-WheeleInformation
-- ASN1START
GBLS-WheeleInformation::= SEQUENCE {
wheeleSize INTEGER (0..[tbd])
sizeUnit ENUMERATED{ meter, inch, ... },
}
-- ASN1STOP
3 Odometer Assistance Data Request
GBLS-Odometer-RequestAssistanceData
-- ASN1START
GBLS-Odometer-RequestAssistanceData::= SEQUENCE {
wheeleInformationReq GBLS-WheeleInformationReq OPTIONAL
}
-- ASN1STOP
4 Odometer Assistance Data Request elements
GBLS-WheeleInformationReq
-- ASN1START
GBLS-Wheele-InformationReq::= SEQUENCE {
sizeUnit ENUMERATED{ meter, inch, ... }, OPTIONAL
}
-- ASN1STOP
5 Odometer Location Information
GBLS-Odometer-ProvideLocationInformation
-- ASN1START
GBLS-Odometer-ProvideLocationInformation::= SEQUENCE {
travelledDistance INTEGER (0..[tbd]) OPTIONAL, Cond odomDistReq
odomVelocity INTEGER (0..[tbd]) OPTIONAL, Cond odomVelReq
reverseFlag BOOLEAN
}
-- ASN1STOP
|Conditional presence |Explanation |
|odomDistReq |[tbd] |
|odomVelReq |[tbd] |
|GBLS-Odometer-ProvideLocationInformation field descriptions |
|travelledDistance |
|[tbd] |
|odomVelocity |
|[tbd] |
|reverseFlag |
|[tbd] |
|NB : mandatory present, since it accompanies the travelled distance and/of velocity information from the odometer |
6 Odometer Location Information Request
GBLS-Odometer-RequestLocationInformation
-- ASN1START
GBLS-Odometer-RequestLocationInformation::= SEQUENCE {
odometerInformationType SEQUENCE{
travelledDistanceReq BOOLEAN
odomVelocityReq BOOLEAN
}
}
-- ASN1STOP
|GBLS-Odometer-RequestLocationInformation field descriptions |
|odometerInformationType |
|[tbd] |
|travelledDistanceReq |
|[tbd] |
|odomVelocityReq |
|[tbd] |
5 Beam Forming Antenna Positioning
1 GBLS-BFN-ProvideAssistanceData
-- ASN1START
GBLS-BFN-ProvideAssistanceData::= SEQUENCE {
inertialMeasurement GBLS-InertialAssistance OPTIONAL Need ON
velocityEstimate Velocity OPTIONAL Need ON
headingEstimate GBLS-Heading OPTIONAL Need ON
gnss-NavigationModel GNSS-NavigationModel OPTIONAL Need ON
gnss-Almanac GNSS-Almanac OPTIONAL Need ON
}
-- ASN1STOP
|GBLS-BFN-ProvideAssistanceData field descriptions |
|inertialMeasurement |
|[tbd] |
|velocityEstimate |
|[tbd] |
|headingEstimate |
|[tbd] |
|gnss-NavigationModel |
|[tbd] |
|gnss-Almanac |
|[tbd] |
2 GBLS-InertialAssistance
-- ASN1START
GBLS-InertialAssistance::= SEQUENCE {
sensorCaseCRM OMA-LPPe-Orientation OPTIONAL, Cond
sensoBodyCRM OMA-LPPe-Orientation OPTIONAL, Cond
sensorGyroInformation GBLS-GyroInformation OPTIONAL, Cond
sensorAccelerometerInformation GBLS-AccelerometerInformation OPTIONAL, Cond
}
-- ASN1STOP
|Conditional presence |Explanation |
|Cond |[tbd] |
|Cond |[tbd] |
|Cond |[tbd] |
|Cond |[tbd] |
|GBLS-InertialAssistance field descriptions |
|sensorCaseCRM |
|[tbd] |
|sensoBodyCRM |
|[tbd] |
|sensorGyroInformation |
|[tbd] |
|sensorAccelerometerInformation |
|[tbd] |
3 BFA Assistance Data Request
-- ASN1START
GBLS-BFN-RequestAssistanceData::= SEQUENCE {
inertialMeasurementReq GBLS-InertialAssistanceReq OPTIONAL -- Need ON
velocityEstimateReq BOOLEAN OPTIONAL -- Need ON
headingEstimateReq BOOLEAN OPTIONAL -- Need ON
gnss-NavigationModelReq GNSS-NavigationModelReq OPTIONAL -- Need ON
gnss-Alamanc GNSS-AlmanacReq OPTIONAL -- Need ON
}
-- ASN1STOP
|GBLS-BFN-RequestAssistanceData field descriptions |
|inertialMeasurementReq |
|[tbd] |
|velocityEstimateReq |
|[tbd] |
|headingEstimateReq |
|[tbd] |
|gnss-NavigationModelReq |
|[tbd] |
|GNSS-AlmanacReq |
|[tbd] |
4 GBLS-InertialAssistanceReq
-- ASN1START
GBLS-InertialAssistanceReq::= SEQUENCE {
sensorGyroInformationReq GBLS-GyroInformationRequest OPTIONAL -- Need ON
sensorAccelerometerInformationReq GBLS-AccelerometerInformationRequest OPTIONAL -- Need ON
}
-- ASN1STOP
|GBLS-InertialAssistanceReq field descriptions |
|sensorGyroInformationReq |
|[tbd] |
|sensorAccelerometerInformationReq |
|[tbd] |
5 BFA Location Information
-- ASN1START
GBLS-BFN-ProvideLocationInformation::= SEQUENCE {
sensorBodyCRM OMA-LPPe-Orientation OPTIONAL
detectedNbrOfJammers INTEGER (1.. maxNbrJammer) OPTIONAL
jammerList SEQUENCE (SIZE (1..maxNbrJammer) OF GBLS-JammerSignal OPTIONAL
detectedNbrOfEchos INTEGER (1.. maxNbrEcho) OPTIONAL
multipathList SEQUENCE (SIZE (1..maxNbrEcho) OF GBLS-EchoSignal OPTIONAL
}
maxNbrJammer INTEGER ::= [tbd]
maxNbrEcho INTEGER ::= [tbd]
-- ASN1STOP
|GBLS-JammerSignal field descriptions |
|sensorBodyCRM |
|[tbd] |
|detectedNbrOfJammers |
|[tbd] |
|jammerList |
|[tbd] |
|detectedNbrOfEchos |
|[tbd] |
|multipathList |
|[tbd] |
|maxNbrJammer |
|[tbd] |
|NB : absolute maximum number of jammer allowed by the data model definition |
|maxNbrEcho |
|[tbd] |
|NB : absolute maximum number of jammer allowed by the data model definition |
1 GBLS-JammerSignal
-- ASN1START
GBLS-JammerSignal::= SEQUENCE {
receivedPower GBLS-JammingReceivedPower OPTIONAL
estimatedFrequency GBLS-JammingFrequency OPTIONAL
esimtaedBandwidth GBLS-JammingBandwidth OPTIONAL
jammerEstimatedDoA GBLS-DirectionOfArrival OPTIONAL
}
GBLS-JammingReceivedPower::= SEQUENCE {
powerEstimate INTEGER (1..[tbd]) OPTIONAL
powerEstError INTEGER (1..[tbd]) OPTIONAL
}
GBLS-JammingFrequency::= SEQUENCE {
frequencyEstimate INTEGER (1..[tbd]) OPTIONAL
frequencyEstError INTEGER (1..[tbd]) OPTIONAL
}
GBLS-JammingBandwidth::= SEQUENCE {
bwEstimate INTEGER (1..[tbd]) OPTIONAL
bwEstError INTEGER (1..[tbd]) OPTIONAL
}
-- ASN1STOP
|GBLS-JammerSignal field descriptions |
|receivedPower |
|[tbd] |
|estimatedFrequency |
|[tbd] |
|estimatedBandwidth |
|[tbd] |
|jammerEstimatedDoA |
|[tbd] |
|powerEstimate |
|[tbd] |
|powerEstError |
|[tbd] |
|frequencyEstimate |
|[tbd] |
|frequencyEstError |
|[tbd] |
|bwEstimate |
|[tbd] |
|bwEstError |
|[tbd] |
2 GBLS-EchoSignal
-- ASN1START
GBLS-EchoSignal::= SEQUENCE {
relativePower GBLS-EchoRelativePower OPTIONAL
delay GBLS-EchoDelay OPTIONAL
carrierDopplerFreq GBLS-EchoCarrierDopplerFreq OPTIONAL
echoEstimatedDoA GBLS-DirectionOfArrival OPTIONAL
}
GBLS-EchoRelativePower::= SEQUENCE {
relativePowerEstimate INTEGER (1..[tbd]) OPTIONAL
relativePowerEstError INTEGER (1..[tbd]) OPTIONAL
}
GBLS-EchoDelay::= SEQUENCE {
delayEstimate INTEGER (1..[tbd]) OPTIONAL
delayEstError INTEGER (1..[tbd]) OPTIONAL
}
GBLS-EchoCarrierDopplerFreq::= SEQUENCE {
carDopFreqEstimate INTEGER (1..[tbd]) OPTIONAL
carDopFreqEstError INTEGER (1..[tbd]) OPTIONAL
}
-- ASN1STOP
|GBLS-JammerSignal field descriptions |
|relativePower |
|[tbd] |
|delay |
|[tbd] |
|carrierDopplerFreq |
|[tbd] |
|echoEstimatedDoA |
|[tbd] |
|relativePowerEstimate |
|[tbd] |
|relativePowerEstError |
|[tbd] |
|delayEstimate |
|[tbd] |
|delayEstError |
|[tbd] |
|carDopFreqEstimate |
|[tbd] |
|carDopFreqEstError |
|[tbd] |
3 GBLS-BFN-RequestLocationInformation
-- ASN1START
GBLS-BFN-RequestLocationInformation::= SEQUENCE {
jammerProcessingReq GBLS-JammerProcessingReq
multipathProcessingReq GBLS-MultipathProcessingReq
...
}
-- ASN1STOP
|GBLS-JammerSignal field descriptions |
|jammerProcessingReq |
|[tbd] |
|multipathProcessingReq |
|[tbd] |
4 GBLS-JammerProcessingReq
-- ASN1START
GBLS-JammerProcessingReq::= SEQUENCE {
requestedMaxNbrOfJammers INTEGER (1..[tbd]) OPTIONAL
rxPowerReq BOOLEAN
frequencyReq BOOLEAN
bwReq BOOLEAN
doAReq BOOLEAN
...
}
-- ASN1STOP
6 GBLS-MultipathProcessingReq
-- ASN1START
GBLS-MultipathProcessingReq::= SEQUENCE {
requestedMaxNbrOfEchos INTEGER (1..[tbd]) OPTIONAL
relPowerReq BOOLEAN
delayReq BOOLEAN
carDopplerFreqReq BOOLEAN
doAReq BOOLEAN
...
}
-- ASN1STOP
6 Mapping Positioning
[FFS]
1 (informative):
Rationale for LSEP/MLP and LSIP/LPPe
1 Basis for LSEP/MLP
• Explain why MLP is the most appropriate protocol to start from
• List the most relevant MLP procedures for LSEP
• Explain the necessary changes to the MLP messages
2 Basis for LSIP/LPPe
• Explain why LPP/LPPe is the most appropriate protocol to start from
• List the most relevant LPP/LPPe procedures for LSIP
• Explain the necessary changes to the LPP/LPPe messages
2 (informative):
LSEP element technical characteristics
The table below provides information derived from the elements definition, and which would contribute to the selection of a syntax in view of an implementation of LSEP. This information contains variable type, range and accuracy, all issued from technical constrains.
Table A-1: LSEP element characteristics
|Name |Unit |Type |Suggested |Admitted range |Default values |
| | | |accuracy | | |
|accel |m/s² |signed decimal |0,1 [tbc] |[-50 ; 50] [tbc] |n/a |
|accel_conf_lev |- |negative decimal |0,01 [tbc] |[-10 ; 0] |n/a |
|accel_info |- |- |- |- |- |
|auth_req |- |boolean |- |[YES / NO] |NO |
|mot_type |- |char. string |- |[LINEAR, ANGULAR] |[LINEAR] |
|accel_unc |m/s² |positive decimal |0,1 [tbc] |[0 ; 10] [tbc] |n/a |
|alt_info |- |- |- |- |- |
|alt_unc |m |positive decimal |0,01 [tbc] |[0 ; 100] [tbc] | |
|auth_flag |- |char. string |- |[NO, YES, UNKNOWN] |- |
|req_emidata |- |char. string |- |[POS_ONLY, POS_AND_BW] |[POS_ONLY] |
|h_acc_not_met |- |- |- |- |- |
|h_conf_lev |- |negative decimal |0,01 [tbc] |[-10 ; 0] |n/a |
|conf_class |- |char. string |- |[INFO , ALERT] |[INFO] |
|h_int_alert |- |- |- |- |- |
|head_conf_lev |- |negative decimal |0,01 [tbc] |[-10 ; 0] |n/a |
|head_info |- |- |- |- |- |
|head_unc |degree |positive decimal |0,1 [tbc] |[0 ; 10] [tbc] |n/a |
|high_freq |Hz |positive decimal |1 [tbc] |[0 ; 2e9] [tbc] |n/a |
|lev_conf |- |negative decimal |0,01 [tbc] |[-10 ; 0] |n/a |
|low_frfeq |Hz |positive decimal |1 [tbc] |[0 ; 2e9] [tbc] |n/a |
|pfa |- |negative decimal |0,01 [tbc] |[-10 ; 0] |n/a |
|pmd |- |negative decimal |0,01 [tbc] |[-10 ; 0] |n/a |
|time_acc |µs |positive decimal |0.001 [tbc] |[0 ; 10000] [tbc] |n/a |
|time_acc_not_met |- |- |- |- |- |
|time_conf_lev |- |negative decimal |0,01 [tbc] |[-10 ; 0] |n/a |
|time_p |date |char. String / date |1 µs [tbc] |- |n/a |
|time_unc |µs |positive decimal |0.001 [tbc] |[0 ; 10000] [tbc] |n/a |
|v_acc_not_met |- |- |- |- |- |
|v_conf_lev |- |negative decimal |0,01 [tbc] |[-10 ; 0] |n/a |
|v_int_alert |- |- |- |- |- |
|vel_acc |m/s |positive decimal |0,01 [tbc] |[0 , 5] [tbd] |n/a |
|vel_acc_not_met |- |- |- |- |- |
|vel_conf_lev |- |negative decimal |0,01 [tbc] |[-10 ; 0] |n/a |
|vel_info |- |- |- |- |- |
|vel_int_alert |- |- |- |- |- |
|vel_unc |m/s |positive decimal |0,01 [tbc] |[0 , 5] [tbd] |n/a |
History
|Document history |
|V0.0.1 |June 2014 |First Draft |
|V0.0.2 |August 2014 |Update of Annex Headings and corrected scope, introduction etc. |
|V0.0.3 |Jan 2015 |New title and more content. |
|V0.0.4 |Feb 2015 |LSEP and MLP and LSIP an LPP/LPPe content |
|V0.0.5 |April 2015 |Edits following WG meeting and subsequent discussion |
|V0.0.6 |2015 | |
| | | |
| | | |
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- skeleton flashcards
- cut out skeleton template bones
- free printable skeleton bones
- free skeleton cut out printables
- large skeleton cut out template
- human skeleton worksheet printable
- paper skeleton template
- skeleton print out sheet
- build a skeleton printable
- cut out skeleton printable
- printable skeleton pieces
- printable skeleton template for kids