ETSI TS 136 171 V15.1.0 (2020-04)

LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements for Support of Assisted Global Navigation Satellite System (A-GNSS) (3GPP TS 36.171 version 15.1.0 Release 15)

RTS/TSGR-0436171vf10

General Information

• Status: Published
• Publication Date: 16-Apr-2020
• Technical Committee: 3GPP RAN 4 - Specification for radio performance
• Current Stage: 12 - Completion
• Completion Date: 17-Apr-2020

Standards Content (Sample)

TECHNICAL SPECIFICATION
LTE;
Evolved Universal Terrestrial Radio Access (E-UTRA);
Requirements for Support of Assisted Global Navigation
Satellite System (A-GNSS)
(3GPP TS 36.171 version 15.1.0 Release 15)

3GPP TS 36.171 version 15.1.0 Release 15 1 ETSI TS 136 171 V15.1.0 (2020-04)

Reference
RTS/TSGR-0436171vf10
Keywords
LTE
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 2 ETSI TS 136 171 V15.1.0 (2020-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 (https://ipr.etsi.org/).
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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "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.
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 3 ETSI TS 136 171 V15.1.0 (2020-04)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
1 Scope . 7
2 References . 7
3 Definitions, symbols and abbreviations . 8
3.1 Definitions . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
3.4 Test tolerances . 9
4 General . 9
4.1 Introduction . 9
4.1.1 Applicability of requirements in this specification version . 9
4.2 Measurement parameters . 10
4.2.1 UE based A-GNSS measurement parameters . 10
4.2.2 UE assisted A-GNSS measurement parameters . 10
4.3 Response time . 10
4.4 Time assistance . 10
4.4.1 Use of fine time assistance . 10
4.5 RRC states . 11
4.6 Error definitions . 11
5 A-GNSS minimum performance requirements (UE supports A-GPS L1 C/A only) . 11
5.1 Sensitivity . 12
5.1.1 Coarse time assistance . 12
5.1.1.1 Minimum Requirements (Coarse time assistance) . 12
5.1.2 Fine time assistance . 12
5.1.2.1 Minimum Requirements (Fine time assistance) . 12
5.2 Nominal Accuracy . 13
5.2.1 Minimum requirements (nominal accuracy) . 13
5.3 Dynamic Range . 13
5.3.1 Minimum requirements (dynamic range) . 14
5.4 Multi-Path scenario . 14
5.4.1 Minimum Requirements (multi-path scenario) . 14
5.5 Moving scenario and periodic update . 14
5.5.1 Minimum Requirements (moving scenario and periodic update) . 15
6 A-GNSS minimum performance requirements (UE supports other or additional GNSSs) . 15
6.1 Sensitivity . 16
6.1.1 Coarse time assistance . 16
6.1.1.1 Minimum Requirements (Coarse time assistance) . 16
6.1.2 Fine time assistance . 17
6.1.2.1 Minimum Requirements (Fine time assistance) . 17
6.2 Nominal Accuracy . 17
6.2.1 Minimum requirements (nominal accuracy) . 18
6.3 Dynamic Range . 18
6.3.1 Minimum requirements (dynamic range) . 19
6.4 Multi-Path scenario . 19
6.4.1 Minimum Requirements (multi-path scenario) . 20
6.5 Moving scenario and periodic update . 20
6.5.1 Minimum Requirements (moving scenario and periodic update) . 21
Annex A (normative): Test cases . 22
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 4 ETSI TS 136 171 V15.1.0 (2020-04)
A.1 Conformance tests . 22
A.2 Requirement classification for statistical testing . 22
Annex B (normative): Test conditions. 23
B.1 General . 23
B.1.1 Parameter values . 23
B.1.2 Time assistance . 23
B.1.3 GNSS Reference Time . 23
B.1.4 Reference and UE locations . 24
B.1.5 Satellite constellation and assistance data . 24
B.1.5.1 UE supports A-GPS L1 C/A only . 24
B.1.5.2 UE supports other A-GNSSs . 24
B.1.6 Atmospheric delays . 24
B.1.7 E-UTRA Frequency and frequency error . 24
B.1.8 Information elements . 25
B.1.9 GNSS signals . 25
B.1.10 RESET UE POSITIONING STORED INFORMATION Message . 25
B.1.11 GNSS System Time Offsets . 25
B.1.12 Sensors . 25
Annex C (normative): Propagation conditions . 26
C.1 Static propagation conditions . 26
C.2 Multi-path Case . 26
Annex D (normative): Measurement sequence chart . 27
D.1 General . 27
D.2 TTFF Measurement Sequence Chart . 27
D.3 Moving Scenario And Periodic Update Measurement Sequence Chart . 28
Annex E (normative): Assistance data required for testing . 31
E.1 Introduction . 31
E.2 GNSS Assistance Data . 31
Annex F (normative): Converting UE-assisted measurement reports into position
estimates . 35
F.1 Introduction . 35
F.2 UE measurement reports . 35
F.3 WLS position solution . 36
Annex G (informative): Change history . 38
History . 39

ETSI
3GPP TS 36.171 version 15.1.0 Release 15 5 ETSI TS 136 171 V15.1.0 (2020-04)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
In the present document, modal verbs have the following meanings:
shall indicates a mandatory requirement to do something
shall not indicates an interdiction (prohibition) to do something
The constructions "shall" and "shall not" are confined to the context of normative provisions, and do not appear in
Technical Reports.
The constructions "must" and "must not" are not used as substitutes for "shall" and "shall not". Their use is avoided
insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced,
non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a
referenced document.
should indicates a recommendation to do something
should not indicates a recommendation not to do something
may indicates permission to do something
need not indicates permission not to do something
The construction "may not" is ambiguous and is not used in normative elements. The unambiguous constructions
"might not" or "shall not" are used instead, depending upon the meaning intended.
can indicates that something is possible
cannot indicates that something is impossible
The constructions "can" and "cannot" are not substitutes for "may" and "need not".
will indicates that something is certain or expected to happen as a result of action taken by an
agency the behaviour of which is outside the scope of the present document
will not indicates that something is certain or expected not to happen as a result of action taken by an
agency the behaviour of which is outside the scope of the present document
might indicates a likelihood that something will happen as a result of action taken by some agency the
behaviour of which is outside the scope of the present document
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 6 ETSI TS 136 171 V15.1.0 (2020-04)
might not indicates a likelihood that something will not happen as a result of action taken by some agency
the behaviour of which is outside the scope of the present document
In addition:
is (or any other verb in the indicative mood) indicates a statement of fact
is not (or any other negative verb in the indicative mood) indicates a statement of fact
The constructions "is" and "is not" do not indicate requirements.
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 7 ETSI TS 136 171 V15.1.0 (2020-04)
1 Scope
The present document establishes the minimum performance requirements for A-GNSS (including A-GPS) for FDD or
TDD mode of E-UTRA for the User Equipment (UE).
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TS 36.101: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE)
radio transmission and reception".
[2] 3GPP TS 36.104: "Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS)
radio transmission and reception".
[3] 3GPP TS 37.571-1: " User Equipment (UE) conformance specification for UE positioning; Part 1:
Terminal conformance".
[4] 3GPP TS 36.355: "Evolved Universal Terrestrial Radio Access (E-UTRA); LTE Positioning
Protocol (LPP)".
[5] 3GPP TS 36.302: "Evolved Universal Terrestrial Radio Access (E-UTRA); Services provided by
the physical layer".
[6] 3GPP TS 36.214: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer;
Measurements".
[7] ETSI TR 102 273-1-2: "Electromagnetic compatibility and Radio spectrum Matters (ERM);
Improvement on Radiated Methods of Measurement (using test site) and evaluation of the
corresponding measurement uncertainties; Part 1: Uncertainties in the measurement of mobile
radio equipment characteristics; Sub-part 2: Examples and annexes".
th
[8] IS-GPS-200, Revision D, Navstar GPS Space Segment/Navigation User Interfaces, March 7 ,
2006.
[9] P. Axelrad, R.G. Brown, "GPS Navigation Algorithms", in Chapter 9 of "Global Positioning
System: Theory and Applications", Volume 1, B.W. Parkinson, J.J. Spilker (Ed.), Am. Inst. of
Aeronautics and Astronautics Inc., 1996.
[10] S.K. Gupta, "Test and Evaluation Procedures for the GPS User Equipment", ION-GPS Red Book,
Volume 1, p. 119.
[11] 3GPP TS 36.509: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet
Core (EPC); Special conformance testing functions for User Equipment (UE)".
[12] IS-GPS-705, Navstar GPS Space Segment/User Segment L5 Interfaces, September 22, 2005.
[13] IS-GPS-800, Navstar GPS Space Segment/User Segment L1C Interfaces, September 4, 2008.
[14] IS-QZSS, Quasi Zenith Satellite System Navigation Service Interface Specifications for QZSS,
Ver.1.1, July 31, 2009.
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 8 ETSI TS 136 171 V15.1.0 (2020-04)
rd
[15] Galileo OS Signal in Space ICD (OS SIS ICD), Draft 0, Galileo Joint Undertaking, May 23 ,
2006.
[16] Global Navigation Satellite System GLONASS Interface Control Document, Version 5.1, 2008.
[17] Specification for the Wide Area Augmentation System (WAAS), US Department of
Transportation, Federal Aviation Administration, DTFA01-96-C-00025, 2001.
[18] BeiDou Navigation Satellite System Signal In Space Interface Control Document Open Service
Signal B1I(Version 1.0), China Satellite Navigation Office, December 2012.
[19] 3GPP TS 36.306: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE)
radio access capabilities".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TS 36.101 [1], 3GPP TS 36.104 [2]
and the following apply:
Horizontal Dilution Of Precision (HDOP): measure of position determination accuracy that is a function of the
geometrical layout of the satellites used for the fix, relative to the receiver antenna
3.2 Symbols
For the purposes of the present document, the following symbols apply:
B1I BeiDou B1I navigation signal with carrier frequency of 1561.098 MHz.
E1 Galileo E1 navigation signal with carrier frequency of 1575.420 MHz.
E5 Galileo E5 navigation signal with carrier frequency of 1191.795 MHz.
E6 Galileo E6 navigation signal with carrier frequency of 1278.750 MHz.
G1 GLONASS navigation signal in the L1 sub-bands with carrier frequencies 1602 MHz ± k × 562.5
kHz.
G2 GLONASS navigation signal in the L2 sub-bands with carrier frequencies 1246 MHz ± k × 437.5
kHz.
k GLONASS channel number, k = -7…13.
L1 C/A GPS or QZSS L1 navigation signal carrying the Coarse/Acquisition code with carrier frequency of
1575.420 MHz.
L1C GPS or QZSS L1 Civil navigation signal with carrier frequency of 1575.420 MHz.
L2C GPS or QZSS L2 Civil navigation signal with carrier frequency of 1227.600 MHz.
L5 GPS or QZSS L5 navigation signal with carrier frequency of 1176.450 MHz.
G Geometry Matrix.
ρ
GNSS ,i
m
Measured pseudo-range of satellite i of GNSS .
m
W Weighting Matrix.
GNSS ,i
m
Line of sight unit vector from the user to the satellite i of GNSS .
m
x
State vector of user position and clock bias.

3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
A-GNSS Assisted Global Navigation Satellite System
A-GPS Assisted - Global Positioning System
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 9 ETSI TS 136 171 V15.1.0 (2020-04)
AWGN Additive White Gaussian Noise
BDS BeiDou Navigation Satellite System
C/A Coarse/Acquisition
DUT Device Under Test
ECEF Earth Centred, Earth Fixed
ECI Earth-Centered-Inertial
E-SMLC Enhanced Serving Mobile Location Centre
E-UTRA Evolved UMTS Terrestrial Radio Access
E-UTRAN Evolved UMTS Terrestrial Radio Access Network
eNB E-UTRAN Node B
FDD Frequency Division Duplex
GEO Geostationary Earth Orbit
GLONASS GLObal'naya NAvigatsionnaya Sputnikovaya Sistema (Engl.: Global Navigation Satellite System)
GNSS Global Navigation Satellite System
GPS Global Positioning System
GSS GPS System Simulator
HDOP Horizontal Dilution Of Precision
ICD Interface Control Document
IGSO Inclined Geosynchronous Satellite Orbit
IS Interface Specification
LOS Line Of Sight
LPP LTE Positioning Protocol
MEO Medium Earth Orbit
QZSS Quasi-Zenith Satellite System
RRC Radio Resource Control
SBAS Space Based Augmentation System
SFN System Frame Number
SS FDD System simulator
SV Space Vehicle
TDD Time Division Duplex
TLM TeLeMetry word. It contains an 8-bits preamble (10001011)
TOW Time Of Week
TTFF Time To First Fix
UE User Equipment
WLS Weighted Least Square
WGS-84 World Geodetic System 1984
3.4 Test tolerances
The requirements given in the present document make no allowance for measurement uncertainty. The test specification
3GPP TS 37.571-1 [3] defines test tolerances. These test tolerances are individually calculated for each test. The test
tolerances are then added to the limits in the present document to create test limits. The measurement results are
compared against the test limits as defined by the shared risk principle.
Shared Risk is defined in ETR 273-1-2 [7], subclause 6.5.
4 General
4.1 Introduction
The present document defines the minimum performance requirements for both UE based and UE assisted FDD or
TDD A-GNSS (including A-GPS) terminals.
4.1.1 Applicability of requirements in this specification version
For UE category M1 and UE category M2, unless otherwise stated, A-GNSS minimum performance requirements in
Section 5 and 6 are applicable only to UEs supporting VoLTE. UE Category M1, comprising both DL UE category M1
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 10 ETSI TS 136 171 V15.1.0 (2020-04)
and UL UE category M1, is defined in TS 36.306 [19]. UE Category M2, comprising both DL UE category M2 and UL
UE category M2, is defined in TS 36.306 [19].
4.2 Measurement parameters
4.2.1 UE based A-GNSS measurement parameters
In case of UE-based A-GNSS, the measurement parameters are contained in the GNSS-LocationInformation IE which is
included in the A-GNSS-ProvideLocationInformation IE provided in the LPP message of type PROVIDE LOCATION
INFORMATION. The measurement parameter in case of UE-based A-GNSS is the horizontal position estimate
reported by the UE and expressed in latitude/longitude.
4.2.2 UE assisted A-GNSS measurement parameters
In case of UE-assisted A-GNSS, the measurement parameters are contained in the
GNSS-SingnalMeasurementInformation IE which is included in the A-GNSS-ProvideLocationInformation IE provided
in the LPP message of type PROVIDE LOCATION INFORMATION. The measurement parameters in case of UE-
assisted A-GNSS are the UE GNSS code phase measurements, as specified in 3GPP TS 36.302 [5] and 3GPP TS
36.214 [6]. The UE GNSS code phase measurements are converted into a horizontal position estimate using the
procedure detailed in Annex F.
4.3 Response time
Max Response Time is defined as the time starting from the moment that the UE has received the LPP message of type
REQUEST LOCATION INFORMATION, and ending when the UE starts sending the LPP message of type PROVIDE
LOCATION INFORMATION on the Uu interface. The response times specified for all test cases are Time-to-First-Fix
(TTFF) unless otherwise stated, i.e. the UE shall not re-use any information on GNSS time, location or other aiding data
that was previously acquired or calculated and stored internally in the UE. A dedicated test message 'RESET UE
POSITIONING STORED INFORMATION' has been defined in TS 36.509 [11] clause 6.9 for the purpose of deleting
this information and is detailed in subclause B.1.10.
4.4 Time assistance
Time assistance is the provision of GNSS time to the UE from the network via LPP messages. Currently two different
GNSS time assistance methods can be provided by the network.
a) Coarse time assistance is always provided by the network and provides current GNSS time to the UE. The time
provided is within ±2 seconds of GNSS system time. It is signalled to the UE by means of the gnss-DayNumber
and gnss-TimeOfDay fields in the gnss-SystemTime IE.
b) Fine time assistance is optionally provided by the network and adds the provision to the UE of the relationship
between the GNSS system time and the current E-UTRAN time. The accuracy of this relationship is ±10 μs of
the actual relationship. This addresses the case when the network can provide an improved GNSS time accuracy.
It is signalled to the UE by means of the gnss-SystemTime IE and the gnss-ReferenceTimeForCells IE.
The specific GNSS system time is identified through the gnss-TimeID field of the GNSS-SystemTime IE. In case where
several GNSSs are used in the tests, only one gnss-TimeID is used to determine the Time of Day. For all the
constellations, the gnss-TimeModels IE shall be available at the system simulator, as specified in Annex E.
4.4.1 Use of fine time assistance
The use of fine time assistance to improve the GNSS performance of the UE is optional for the UE, even when fine
time assistance is signalled by the network. Thus, there are a set minimum performance requirements defined for all
UEs and additional minimum performance requirements that are valid for fine time assistance capable UEs only. These
requirements are specified in subclause 5.1.2 for UEs that support A-GPS L1 C/A only and in clause 6.1.2 for UEs that
support other GNSSs.
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 11 ETSI TS 136 171 V15.1.0 (2020-04)
4.5 RRC states
The minimum A-GNSS performance requirements are specified in clauses 5 and 6 for RRC_CONNECTED state. The
test and verification procedures are separately defined in annex B.
4.6 Error definitions
The 2D position error is defined by the horizontal difference in meters between the ellipsoid point reported or calculated
from the LPP message of type PROVIDE LOCATION INFORMATION and the actual position of the UE in the test
case considered.
4.7 UEs supporting multiple constellations
Minimum performance requirements are defined for each global GNSS constellation (GPS, Galileo, Modernized GPS,
GLONASS and BDS). UEs supporting multiple global constellations shall meet the minimum performance
requirements for a combined scenario where each UE supported constellation is simulated.
NOTE: For test cases where signals from “GPS” and “Modernized GPS” are included, “GPS” and “Modernized
GPS” are considered as a single constellation, unless otherwise specified.
4.8 UEs supporting multiple signals
For UEs supporting multiple signals, different minimum performance requirements may be associated with different
signals. The satellite simulator shall generate all signals supported by the UE. Signals not supported by the UE do not
need to be simulated. The relative power levels of each signal type for each GNSS are defined in Table 4.1. The
individual test scenarios in clause 6 define the reference signal power level for each satellite. The power level of each
simulated satellite signal type shall be set to the reference signal power level defined in each test scenario in clause 6
plus the relative power level defined in Table 4.1.
Table 4.1: Relative signal power levels for each signal type for each GNSS
Galileo GPS/Modernize GLONASS QZSS SBAS BDS
d GPS
Signal power E1 0 dB L1 0 dB G1 0 dB L1 0 dB L 0 dB B1I D1 0 dB
levels relative C/A C/A 1 D2 +5 dB
to reference
E6 +2 dB L1C +1.5 dB G2 -6 dB L1C +1.5 dB
power levels
E5 +2 dB L2C -1.5 dB  L2C -1.5 dB
L5 +3.6 dB  L5 +3.6 dB
NOTE 1: For test cases which involve “Modernized GPS”, the satellite simulator shall also generate the GPS L1
C/A signal if the UE supports “GPS” in addition to “Modernized GPS”.
NOTE 2: The signal power levels in the Test Parameter Tables represent the total signal power of the satellite per
channel not e.g. pilot and data channels separately.
NOTE 3: For test cases which involve "BDS", D1 represents MEO/IGSO satellites B1I signal type and D2
represents GEO satellites B1I signal type.

5 A-GNSS minimum performance requirements (UE
supports A-GPS L1 C/A only)
The minimum performance requirements specified in clause 5 apply for UEs that support A-GPS L1 C/A only. The
requirements for UEs that support other or additional A-GNSSs are specified in clause 6.
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 12 ETSI TS 136 171 V15.1.0 (2020-04)
The A-GNSS minimum performance requirements are defined by assuming that all relevant and valid assistance data is
received by the UE in order to perform GPS L1 C/A measurements and/or position calculation. This clause does not
include nor consider delays occurring in the various signalling interfaces of the network.
In the following subclauses the minimum performance requirements are based on availability of the assistance data
information and messages defined in annexes D and E.
5.1 Sensitivity
A sensitivity requirement is essential for verifying the performance of A-GNSS receiver in weak satellite signal
conditions. In order to test the most stringent signal levels for the satellites the sensitivity test case is performed in
AWGN channel. This test case verifies the performance of the first position estimate, when the UE is provided with
only coarse time assistance and when it is additionally supplied with fine time assistance.
5.1.1 Coarse time assistance
In this test case 8 satellites are generated for the terminal. AWGN channel model is used.
Table 5.1: Test parameters
Parameters Unit Value
Number of generated satellites - 8
HDOP Range - 1.1 to 1.6
Propagation conditions - AWGN
GNSS Coarse time assistance error seconds
±2
range
GPS L1 C/A Signal for one satellites dBm -142
GPS L1 C/A Signal for remaining dBm -147
satellites
5.1.1.1 Minimum Requirements (Coarse time assistance)
The position estimates shall meet the accuracy and response time specified in Table 5.2.
Table 5.2: Minimum requirements (coarse time assistance)
Success rate 2-D position error Max response time
95 % 100 m 20 s
5.1.2 Fine time assistance
This requirement is only valid for fine time assistance capable UEs. In this requirement 8 satellites are generated for the
terminal. AWGN channel model is used.
Table 5.3: Test parameters for fine time assistance capable terminals
Parameters Unit Value
Number of generated satellites - 8
HDOP Range - 1.1 to 1.6
Propagation conditions - AWGN
GNSS Coarse time assistance error range seconds ±2
GPS L1 C/A Fine time assistance error
μs ±10
range
GPS L1 C/A Signal for all satellites dBm -147

5.1.2.1 Minimum Requirements (Fine time assistance)
The position estimates shall meet the accuracy and response time requirements in Table 5.4.
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 13 ETSI TS 136 171 V15.1.0 (2020-04)
Table 5.4: Minimum requirements for fine time assistance capable terminals
Success rate 2-D position error Max response time
95 % 100 m 20 s
5.2 Nominal Accuracy
Nominal accuracy requirement verifies the accuracy of A-GNSS position estimate in ideal conditions. The primarily
aim of the test is to ensure good accuracy for a position estimate when satellite signal conditions allow it. This test case
verifies the performance of the first position estimate.
In this requirement 8 satellites are generated for the terminal. AWGN channel model is used.
Table 5.5: Test parameters
Parameters Unit Value
Number of generated satellites - 8
HDOP Range - 1.1 to 1.6
Propagation conditions - AWGN
GNSS Coarse time assistance error seconds
±2
range
GPS L1 C/A Signal for all satellites dBm -130

5.2.1 Minimum requirements (nominal accuracy)
The position estimates shall meet the accuracy and response time requirements in Table 5.6.
Table 5.6: Minimum requirements
Success rate 2-D position error Max response time
95 % 30 m 20 s
5.3 Dynamic Range
The aim of a dynamic range requirement is to ensure that a GNSS receiver performs well when visible satellites have
rather different signal levels. Strong satellites are likely to degrade the acquisition of weaker satellites due to their
cross-correlation products. Hence, it is important in this test case to keep use AWGN in order to avoid loosening the
requirements due to additional margin because of fading channels. This test case verifies the performance of the first
position estimate.
In this requirement 6 satellites are generated for the terminal. AWGN channel model is used.
Table 5.7: Test parameters
Parameters Unit Value
Number of generated satellites - 6
HDOP Range - 1.4 to 2.1
GNSS Coarse time assistance seconds
±2
error range
Propagation conditions - AWGN
st
dBm -129
GPS L1 C/A Signal for 1 satellite
nd
dBm -135
GPS L1 C/A Signal for 2 satellite
rd
dBm -141
GPS L1 C/A Signal for 3 satellite
th
dBm -147
GPS L1 C/A Signal for 4 satellite
th
dBm -147
GPS L1 C/A Signal for 5 satellite
th
dBm -147
GPS L1 C/A Signal for 6 satellite

ETSI
3GPP TS 36.171 version 15.1.0 Release 15 14 ETSI TS 136 171 V15.1.0 (2020-04)
5.3.1 Minimum requirements (dynamic range)
The position estimates shall meet the accuracy and response time requirements in Table 5.8.
Table 5.8: Minimum requirements
Success rate 2-D position error Max response time
95 % 100 m 20 s
5.4 Multi-Path scenario
The purpose of the test case is to verify the receiver's tolerance to multipath while keeping the test setup simple. This
test case verifies the performance of the first position estimate.
In this requirement 5 satellites are generated for the terminal. Two of the satellites have one tap channel representing
Line-Of-Sight (LOS) signal. The three other satellites have two-tap channel, where the first tap represents LOS signal
and the second reflected and attenuated signal as specified in Annex C.2.
Table 5.9: Test parameters
Parameters Unit Value
Number of generated satellites (Satellites 1, 2 - 5
unaffected by multi-path)
(Satellites 3, 4, 5 affected by multi-path)
GNSS Coarse time assistance error range seconds
±2
HDOP Range - 1.8 to 2.5
GPS L1 C/A Signal for satellite 1, 2 dBm -130
GPS L1 C/A Signal for satellite 3, 4, 5 dBm LOS signal of -130 dBm, multi-
path signal of -136 dBm
5.4.1 Minimum Requirements (multi-path scenario)
The position estimates shall meet the accuracy and response time requirements in Table 5.10.
Table 5.10: Minimum requirements
Success rate 2-D position error Max response time
95 % 100 m 20 s
5.5 Moving scenario and periodic update
The purpose of the test case is to verify the receiver's capability to produce GNSS measurements or location fixes on a
regular basis, and to follow when it is located in a vehicle that slows down, turns or accelerates. A good tracking
performance is essential for a certain location services. A moving scenario with periodic update is well suited for
verifying the tracking capabilities of an A-GNSS receiver in changing UE speed and direction. In the requirement the
UE moves on a rectangular trajectory, which imitates urban streets. AWGN channel model is used. This test is not
performed as a Time to First Fix (TTFF) test.
In this requirement 5 satellites are generated for the terminal. The UE is requested to use periodical reporting with a
reporting interval of 2 seconds.
The UE moves on a rectangular trajectory of 940 m by 1 440 m with rounded corner defined in Figure 5.1. The initial
reference is first defined followed by acceleration to final speed of 100 km/h in 250 m. The UE then maintains the
speed for 400 m. This is followed by deceleration to final speed of 25 km/h in 250 m. The UE then turn 90 degrees with
turning radius of 20 m at 25 km/h. This is followed by acceleration to final speed of 100 km/h in 250 m. The sequence
is repeated to complete the rectangle.
ETSI
3GPP TS 36.171 version 15.1.0 Release 15 15 ETSI TS 136 171 V15.1.0 (2020-04)
Table 5.11: Trajectory Parameters
Parameter Distance (m) Speed (km/h)
l , l , l , l 20 25
11 15 21 25
l , l , l , l 250 25 to 100 and 100 to 25
12 14 22 24
l
400 100
l 900 100
l
l
1 440 m
l
940 m
r = 20 m
l
l
l l
l l l
21 23 24 25
Figure 5.1: Rectangular trajectory of the moving scenario and periodic update test case
Table 5.12: Test Parameters
Parameters Unit Value
Number of generated satellites - 5
HDOP Range - 1.8 to 2.5
Propagation condition - AWGN
GPS L1 C/A signal for all dBm -130
satellites
5.5.1 Minimum Requirements (moving scenario and periodic update)
The position estimates shall meet the accuracy requirement of Table 5.13 with the periodical reporting interval defined
in Table 5.13 after the first reported position estimates.
NOTE: In the actual testing the UE may report error messages until it has been able to acquire GNSS measured
results or a position estimate. The test equipment shall only consider the first measurement report
different from an error message as the first position estimate in the requirement in Table 5.13.
Table 5.13: Minimum requirements
Success Rate 2-D position error Periodical reporting interval
95 % 100 m 2 s
6 A-GNSS minimum performance requirements (UE
supports other or additional GNSSs)
The minimum performance requirements specified in clause 6 apply for UEs that support other A-GNSSs than GPS L1
C/A, or multiple A-GNSSs which may or may not include GPS L1 C/A. The requirements for UEs that support A-GPS
L1 C/A only a
...