3rd Generation Partnership Project;

3GPP TS 22.071
Technical Specification Group Services and System Aspects;
V18.0.1
Location Services (2024-03)
(LCS);
Service description;
Technical Stage 1
Specification

(Release 18)

The present document has been developed within the 3 rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organisational Partners accept no liability for any use of this
Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organisational Partners' Publications Offices.
Release 18 2 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Keywords
GSM, UMTS, LTE, location, stage 1

3GPP

Postal address

3GPP support office address

650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet
http://www.3gpp.org

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.

© 2024, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association

ETSI
Release 18 3 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Contents
Foreword..............................................................................................................................................6
1 Scope......................................................................................................................................... 7
2. References..................................................................................................................................7
2.1 Normative references.......................................................................................................................... 7
2.2 Informative references......................................................................................................................... 8
3 Definitions and abbreviations......................................................................................................8
3.1 Abbreviations...................................................................................................................................... 8
3.2 Definitions.......................................................................................................................................... 9
4 Functional Requirements..........................................................................................................10
4.1 High Level Requirements.................................................................................................................. 10
4.2 Location Information......................................................................................................................... 12
4.2.1 Geographic Location.................................................................................................................... 12
4.2.2 Velocity....................................................................................................................................... 12
4.2.3 Dispatchable Location................................................................................................................. 12
4.3 Quality of Service............................................................................................................................. 12
4.3.1 Horizontal Accuracy.................................................................................................................... 12
4.3.2 Vertical Accuracy........................................................................................................................ 14
4.3.3 Response Time............................................................................................................................ 14
4.3.4 LCS QoS Class............................................................................................................................ 15
4.3.5 Dispatchable Location accuracy................................................................................................... 15
4.4 Reliability......................................................................................................................................... 16
4.5 Priority.............................................................................................................................................. 16
4.6 Timestamp........................................................................................................................................ 16
4.7 Security............................................................................................................................................. 16
4.8 Privacy.............................................................................................................................................. 17
4.8.1 Service Type Privacy................................................................................................................... 18
4.8.1.1 Standardized Service Types.................................................................................................... 18
4.9 Service Authorization........................................................................................................................ 19
4.10 Service Activation and De-Activation............................................................................................... 19
4.11 Coverage........................................................................................................................................... 20
4.12 Roaming Target UE.......................................................................................................................... 20
4.13 Support for all UEs............................................................................................................................ 21
4.14 Support for Unauthorized UEs........................................................................................................... 21
4.15 Periodic Location Reporting.............................................................................................................. 21
4.16 UE-Based Location Calculation........................................................................................................ 22
4.17 UE_Assisted LCS Location Calculation............................................................................................22
4.18 Mobile Originating Location............................................................................................................. 22
4.19 Network support for LCS.................................................................................................................. 23
5 Logical Description...................................................................................................................23
5.1 Logical Reference Model.................................................................................................................. 23
5.2 Functional Entities............................................................................................................................ 24
5.2.1 LCS Client................................................................................................................................... 24
5.2.2 LCS Server.................................................................................................................................. 24
5.2.3 Positioning Function.................................................................................................................... 24
5.2.4 Target UE.................................................................................................................................... 25
5.3 Functional Interfaces......................................................................................................................... 25
5.3.1 LCS Client / LCS Server Interface............................................................................................... 25
5.3.1.1 Location Service Request....................................................................................................... 25
5.3.1.2 Location Service Response..................................................................................................... 26
5.3.1.3 Location Service Request Report............................................................................................26
5.4 Location information......................................................................................................................... 26
5.4.1 Sources of location information................................................................................................... 26

ETSI
Release 18 4 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

6 Service Provision......................................................................................................................26
6.1 Identification of a Target UE............................................................................................................. 26
6.2 Location Information Provided to the LCS Client..............................................................................27
6.3 LCS Client Subscription.................................................................................................................... 28
6.4 Target UE Subscription..................................................................................................................... 28
6.4.1 Privacy Subscription Options....................................................................................................... 28
6.4.2 Codeword.................................................................................................................................... 29
6.4.2.1 Enhanced codeword................................................................................................................ 29
6.4.3 Privacy Exception List................................................................................................................. 29
6.4.4 Privacy Override Indicator........................................................................................................... 30
6.4.5 Subscription to Mobile Originating Location................................................................................30
6.4.6 Void............................................................................................................................................. 31
6.4A Requestor.......................................................................................................................................... 31
6.5 Security............................................................................................................................................. 31
6.6 Charging........................................................................................................................................... 31
6.7 LCS Open Service Architecture and Application Programming Interface..........................................31
7 Provisioning and Administration...............................................................................................32
7.1 Procedures for an LCS Client............................................................................................................ 32
7.1.1 Provisioning................................................................................................................................. 32
7.1.2 Withdrawal.................................................................................................................................. 32
7.1.3 Invocation.................................................................................................................................... 32
7.2 Procedures for a Target UE............................................................................................................... 32
7.2.1 Provisioning................................................................................................................................. 32
7.2.2 Withdrawal.................................................................................................................................. 32
7.2.3 User Control................................................................................................................................ 33
7.3 Barring Capability of the Location Service........................................................................................33
8 Interactions with Bearer and Teleservices and Other Services....................................................33
9 Cross Phase Compatibility between releases..............................................................................33
9.1 Compatibility With Existing Standards..............................................................................................33
9.2 Compatibility With Future Releases.................................................................................................. 34
9.2.1 Void............................................................................................................................................. 34
9.2.2 Location determination in call or PDP context activation and release...........................................34
9.2.3 Void............................................................................................................................................. 34
9.2.4 Defined geographical areas.......................................................................................................... 34
9.2.5 Continuous check of location....................................................................................................... 34
9.2.6 Identification of a Target UE....................................................................................................... 34
9.2.7 Void............................................................................................................................................. 34
9.2.8 VHE............................................................................................................................................ 34

Annex A (informative): USA FCC Wireless E911 Rules.........................................................35

Annex B (informative): Descriptions of possible location based services................................38
B1 Public Safety Services....................................................................................................................... 38
B1.1 Emergency Services..................................................................................................................... 38
B1.1.1 Attributes................................................................................................................................ 38
B1.1.2 Emergency Alert Services............................................................................................................ 38
B2 Location Based Charging.................................................................................................................. 38
B2.1 Attributes..................................................................................................................................... 39
B2.1.1 Target Subscriber Notification................................................................................................ 39
B2.1.2 Charging................................................................................................................................. 39
B2.1.3 Roaming................................................................................................................................. 40
B3 Tracking Services.............................................................................................................................. 40
B3.1 Fleet and Asset Management Services..........................................................................................40
B3.2 Traffic Monitoring....................................................................................................................... 41
B3.2.1 Attributes................................................................................................................................ 41
B3.2.1.1 Privacy.............................................................................................................................. 41
B4 Enhanced Call Routing...................................................................................................................... 41
B5 Location Based Information Services................................................................................................ 41
B5.1 Navigation................................................................................................................................... 41
B5.2 City Sightseeing........................................................................................................................... 42

ETSI
Release 18 5 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

B5.3 Location Dependent Content Broadcast.......................................................................................42

B5.4 Mobile Yellow Pages................................................................................................................... 42
B5.5 Location Sensitive Internet........................................................................................................... 42
B6 Network Enhancing Services............................................................................................................. 42
B6.1 Applications for Network Planning..............................................................................................42
B6.2 Applications for Network QoS Improvements..............................................................................42
B6.3 Improved Radio Resource Management.......................................................................................43

Annex C (Informative): Attributes of Specific Services...........................................................44

Annex D (informative): Change history.....................................................................................54

ETSI
Release 18 6 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Foreword
This Technical Specification (TS) has been produced by the 3GPP.

The contents of this document are subject to continuing work within the TSG and may change following formal TSG
approval. Should the TSG modify the contents of this TS, 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 specification;

ETSI
Release 18 7 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

1 Scope
This document provides the Stage One description of Location Services (LCS). A Stage One description provides an
overall service description, primarily from the service subscriber's and user's points of view, but not dealing with the
details of the Man Machine Interface (MMI). This TS includes information applicable to network operators, service
providers and terminal, base station system, switch, and data base manufacturers.

NOTE: Location Services may be considered as a network provided enabling technology consisting of
standardized service capabilities which enable the provision of location-based applications. These
applications may be service provider specific. The description of the numerous and varied possible
location applications which are enabled by this technology are outside the scope of this specification.
However, clarifying examples of how the functionality being specified may be used to provide specific
location services is included in various sections of the specification.

This document provides core requirements to an extent sufficient to derive a complete definition of location services
at the service level. However, the present document also provides additional requirements which may suggest in a
non-normative manner certain ways the system may be implemented to support location services.

LCS can be offered without subscription to basic telecommunication services. LCS is available to the following
categories of LCS clients:

 Value Added Services LCS Clients – use LCS to support various value-added services. These clients can
include UE subscribers as well as non-subscribers to other services.

 PLMN Operator LCS Clients – use LCS to enhance or support certain O&M related tasks, supplementary
services, IN related services and bearer services and teleservices.

 Emergency Services LCS Clients – use LCS to enhance support for emergency calls from subscribers.

 Lawful Intercept LCS Clients – use LCS to support various legally required or sanctioned services.

LCS is applicable to any target UE whether or not the UE supports LCS, but with restrictions on choice of positioning
method or notification of a location request to the UE user when LCS or individual positioning methods, respectively,
are not supported by the UE.

LCS is being developed in phases with enhancements added in 3GPP releases.

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.

2.1 Normative references

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[2] 3GPP TS 23.032: "Universal Geographical Area Description".

[3] 3GPP TS 22.101: "Service principles".

ETSI
Release 18 8 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

[4] 3GPP TS 22.105: "Services and Service Capabilities".

[5] 3GPP TS 22.115: "Charging and Billing"

[6] Open Mobile Alliance (OMA): OMA-RD-Parlay_Service_Access-V1_0-20100427-A

[7] 3GPP TS 23.110: " UMTS Access Stratum; Services and Functions".

2.2 Informative references

[8] 3GPP TR 25.923: "Report on Location Services (LCS)".

[9] PD 30.lcs: "Project Plan for location services in UMTS".

[10] Third generation (3G) mobile communication system; Technical study report on the location
services and technologies, ARIB ST9 December 1998.

[11] The North American Interest Group of the GSM MoU ASSOCIATION: Location Based
Services, Service Requirements Document of the Services Working Group

[12] FCC, Fourth Report and Order: Wireless E911 Location Accuracy Requirements, February 3,
2015, https://www.fcc.gov/document/fcc-adopts-new-wireless-indoor-e911-location-accuracy-
requirements-0

[13] FCC, Erratum, Wireless E911 Location Accuracy Requirements, March 3, 2015,
https://apps.fcc.gov/edocs_public/index.do?document=332342

3 Definitions and abbreviations

3.1 Abbreviations
For the purposes of the present document, in addition to 3GPP TR.21.905, the following abbreviations apply:

BDS BeiDou Navigation Satellite System

BLE Bluetooth Low Energy
EGNOS European Geographic Navigation Overlay System
E-OTD Enhanced Observed Time Difference
GAGAN GPS Aided Geo Augmented Navigation (or GPS and Geo Augmented Navigation)
GLONASS GLObal NAvigation Satellite System
GNSS Global Navigation Satellite System
IPDL-OTDOA Idle Period Downlink- Observed Time Difference Of Arrival
LCS Location Service
MSAS Multi-functional Satellite Augmentation System
NA-ESRD North American Emergency Services Routing Digits
NA-ESRK North American Emergency Services Routing Key
NANP North American Numbering Plan
PSAP Public Safety Answering Point
QZSS Quasi Zenith Satellite System
SBAS Satellite Based Augmentation Systems
TBS Terrestrial Beacon Systems
U-TDOA Uplink Time Difference of Arrival
WAAS Wide Area Augmentation System

NOTE: In the present document, acronyms are used in the text as if they are read either in their fully expanded
form or in their alphabet names with no consistent principle.

3.2 Definitions
For the purposes of the present document the following definitions apply:

ETSI
Release 18 9 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Change of Area: is one event supported for deferred Location Requests. Change of Area means that the network is
required to report the location or the occurrence of the event of the requested subscriber in triggered fashion
immediately after the network (MSC/SGSN) processes the mobility event for the new location of the subscriber.
Usually new location is noticed after the Location Update, Tracking Area Update, Handover, RAU, Registration or
RANAP Location Report, e.g. when the SAI changes.

Codeword: access code, which is used by a Requestor or LCS Client in order to gain acceptance of a location request
for a Target UE. The codeword is part of the privacy information that may be registered by a Target UE user.

Current Location: after a location attempt has successfully delivered a location estimate or Dispatchable Location
and its associated time stamp, the location estimate or Dispatchable Location and time stamp are referred to as the
‘current location’ at that point in time.

Deferred location request: a location request where the location response (responses) is (are) required after specific
event has occurred. Event may or may not occur immediately. In addition, event may occur many times.

Dispatchable Location: The civic location of a UE and/or a valid Mobile Equipment (ME), expressed as civic data
(e.g. floor, street number, city.) The Dispatchable Location shall be represented in a well-defined universal format.
Regional regulations may specify the mandatory and optional elements in this universal format to be included in a
Dispatchable Location.

Immediate location request: a location request where a single location response only is required immediately.

Initial Location: in the context of an originating emergency call the location estimate or Dispatchable Location and
the associated time stamp at the commencement of the call set-up is referred to as ‘initial location’.

Last Known Location: The current location estimate or Dispatchable Location and the associated time stamp for
Target UE stored in the LCS Server is referred to as the ‘last known location’ and until replaced by a later location
estimate or Dispatchable Location and a new time stamp is referred to as the ‘last known location’.

LCS Client: a software and/or hardware entity that interacts with an LCS Server for the purpose of obtaining location
information for one or more Mobile Stations. LCS Clients subscribe to LCS in order to obtain location information.
LCS Clients may or may not interact with human users. The LCS Client is responsible for formatting and presenting
data and managing the user interface (dialogue). The LCS Client is identified by a unique international identification,
e.g. E.164.

NOTE: The LCS Client may reside inside or outside the PLMN.

LCS Client Access barring list: an optional list of MSISDNs per LCS Client where the LCS Client is not allowed to
locate any MSISDN therein.

LCS Client Subscription Profile: a collection of subscription attributes of LCS related parameters that have been
agreed for a contractual period of time between the LCS client and the service provider.

LCS Feature: the capability of a PLMN to support LCS Client/server interactions for locating Target UEs.

LCS Server: a software and/or hardware entity offering LCS capabilities. The LCS Server accepts requests, services
requests, and sends back responses to the received requests. The LCS server consists of LCS components which are
distributed to one or more PLMN and/or service provider.

Location Estimate: the geographic location of a UE and/or a valid Mobile Equipment (ME), expressed in latitude
and longitude data. The Location Estimate shall be represented in a well-defined universal format. Translation from
this universal format to another geographic location system may be supported, although the details are considered
outside the scope of the primitive services.

NG-RAN: a radio access network connecting to the 5G core network which uses NR, E-UTRA, or both.

North American Emergency Services Routing Digits (NA-ESRD): a telephone number in the North American
Numbering Plan (NANP) that can be used to identify a North American emergency services provider and its
associated LCS client. The ESRD also identifies the base station, cell site or sector from which a North American
emergency call originates.

North American Emergency Services Routing Key (NA-ESRK): a telephone number in the North American
Numbering Plan (NANP) assigned to an emergency services call by a North American VPLMN for the duration of
the call. The NA-ESRK is used to identify (e.g. route to) both the emergency services provider and the switch in the

ETSI
Release 18 10 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

VPLMN currently serving the emergency caller. During the lifetime of an emergency services call, the NA-ESRK
also identifies the calling mobile subscriber.

PLMN Access barring list: an optional list of MSISDN per PLMN where any LCS Client is not allowed to locate
any MSISDN therein except for certain exceptional cases.

Privacy Class: list of LCS Clients defined within a privacy exception class to which permission may be granted to
locate the target UE. The permission shall be granted either on activation by the target UE or permanently for a
contractual period of time agreed between the target UE and the service provider.

Service Identifier: A service provided by an LCS Client is identified by a Service Identifier. One LCS client may
have one or more services. The combination of the LCS client Identifier and the Service Identifier constitutes a
unique identification of a service.

Privacy Exception List: a list consisting of various types of privacy classes (i.e. operator related, personal etc.).
Certain types of classes may require agreement between the service provider and the target UE.

Requestor: an originating entity, which has requested the location of the target UE from the LCS client.

Target UE: The UE being positioned.

Target UE Subscription Profile: the profile detailing the subscription to various types of privacy classes.

UE available: deferred Location Request event in which the MSC/SGSN has established a contact with the UE. Note,
this event is considered to be applicable when the UE is temporarily unavailable due to inaction by the UE user,
temporarily loss of radio connectivity or IMSI detach and so on. Note that IMSI detach is only applicable in the case
UE has previously been registered and information is still kept in the node.

4 Functional Requirements

4.0 General
3GPP standards shall support location service features, to allow new and innovative location-based services to be
developed. It shall be possible to identify and report in a standard format (e.g. geographical co-ordinates) the current
location of the user’s terminal and to make the information available to the user, ME, network operator, service
provider, value added service providers and for PLMN internal operations.

The location is provided to identify the likely location of specific MEs. This is meant to be used for charging,
location-based services, lawful interception, emergency calls, etc., as well as the positioning services.

The standard shall support NG-RAN, E-UTRAN, GERAN and UTRAN to facilitate determination of the location of a
mobile station.

The following subsections provide general descriptions of attributes that can be used to describe or characterize
various location services.
The relative importance of these attributes varies from service to service. However, accuracy, coverage, privacy and
transaction rate may be considered the primary distinguishing attributes that define a value-added service. Briefly:
 accuracy is the difference between actual location and estimated location,
 coverage is an expression of the geographic area in which the UE user will receive an adequate
perceived quality of service,
 privacy describes the user’s perception of confidentiality of the location information, and
 transaction rate indicates how frequently network messaging is required to support the service.
A general comparison of the specific attributes of various location-based services is provided in Annex C of this
document.

4.1 High Level Requirements

The following high-level requirements are applicable:

ETSI
Release 18 11 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

1 The supporting mechanisms should incorporate flexible modular components with open interfaces that
facilitate equipment interoperability and the evolution of service providing capabilities.

2 The network should be sufficiently flexible to accommodate evolving enabling mechanisms and service
requirements to provide new and improved services.

3 It shall be possible to provide multiple layers of permissions to comply with local, national, and regional
privacy requirements.

4 Multiple positioning methods should be supported in the different Access Networks, including (but not limited
to):

- Modernized GPS;

- SBAS (Satellite Based Augmentation Systems: EGNOS, WAAS, GAGAN, MSAS);

- QZSS (Quasi Zenith Satellite System);

- GLONASS

- BDS

- Galileo

- U-TDOA

- E-OTD

- IPDL-OTDOA

- Network Assisted GNSS (e.g. Network Assisted GPS or Network Assisted GALILEO)

- UE ambient condition sensors-based positioning

- Motion sensors (e.g. accelerometers, gyroscopes)

- Environmental sensors (e.g. barometer)

- Position sensors (e.g. magnetometers, orientation sensors)

- TBS

- Beacon identity for location lookup (e.g. WiFi access points or BLE beacons)

- RF Pattern Matching

- Methods using cell site or sector information and Timing Advance or RoundTrip Time measurements.

5 The location determining process should be able to combine diverse positioning techniques and local
knowledge when considering quality of service parameters to provide an optimal positioning request response.

6 It should be possible to provide position information to location services applications existing within the
PLMN, external to the PLMN, or in Mobile Equipment;

7 Support should be provided for networks based on Intelligent Network architecture (i.e. with specific support
for CAMEL based Location Services).

8 Support may optionally be provided to enable the routing of emergency calls based on the geographic
coordinates (latitude and longitude) of the calling party.

9 It shall be possible to provide the originating party’s serving cell id to the LCS client.

ETSI
Release 18 12 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

4.2 Location Information

Location Information consists of Geographic Location, Velocity, Civic Location and Quality of Service information,
as described in the subsequent sections.

4.2.1 Geographic Location

Provision of the geographic location of a target UE is applicable to all LCS services.

Note: For services other than LCS the network may also determine within which Cell, Service Area, or
Tracking Area the Target UE is located ("Service Area" and "Tracking Area" are UTRAN and E-
UTRAN concepts respectively and both may consist of one (in R99) or more than one cell). The
Service or Tracking Area information or Cell ID may be used for routing of calls or for CAMEL
applications, if supported.

It should be noted that the Service and Tracking Area concepts are different from the Localized Service Area concept
used for SoLSA.

4.2.2 Velocity
Velocity is the combination of speed and direction of a Target UE. It shall be possible for a UE to provide its velocity
to the LCS server.

Note: This requirement only applies to satellite-based positioning systems.

For Value Added Services and PLMN Operator Services, the following is applicable:

Provision of the velocity of a target UE is application driven. Location Services may allow an LCS Client to
request or negotiate the provision of velocity.

For Emergency Services there is no requirement to provide velocity.

4.2.3 Dispatchable Location

Provision of the Dispatchable Location of a target UE in civic form is applicable to Emergency Services based on
regional regulatory requirements.

An example of Dispatchable Location regional regulatory requirements for the United States can be found in [12] and
[13].

4.3 Quality of Service

4.3.1 Horizontal Accuracy
The accuracy that can be provided with various positioning technologies depends on a number of factors, many of
which are dynamic in nature. As such the accuracy that will be realistically achievable in an operational system will
vary due to such factors as the dynamically varying radio environments (considering signal attenuation and multipath
propagation), network topography in terms of base station density and geography, and positioning equipment
available.
The accuracy for location services can be expressed in terms of a range of values that reflect the general accuracy
level needed for the application. Different services require different levels of positioning accuracy. The range may
vary from tens of meters (navigation services) to perhaps kilometers (fleet management).
The majority of attractive value-added location services are enabled when location accuracies of between 25m and
200m can be provided.

ETSI
Release 18 13 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Based on decreasing accuracy requirement some examples of location services are provided in table 4.1. The LCS
service shall provide techniques that allow operators to deploy networks that can provide at least the level of accuracy
required by the regional regulatory bodies (e.g. Annex A).

Table 4.1; Example of location services with decreasing accuracy requirement

· Location-independent Most existing cellular services, Stock prices, sports reports

· PLMN or country Services that are restricted to one country or one PLMN

· Regional (up to 200km) Weather reports, localized weather warnings, traffic information (pre-trip)

· District (up to 20km) Local news, traffic reports

· Up to 1 km Vehicle asset management, targeted congestion avoidance advice

· 500m to 1km Rural and suburban emergency services, manpower planning, information
services (where are?)

· 100m (67%) U.S. FCC mandate (99-245) for wireless emergency calls using network-
based positioning methods
· 300m (95%)

· 75m-125m Urban SOS, localized advertising, home zone pricing, network

maintenance, network demand monitoring, asset tracking, information
services (where is the nearest?)

· 50m (80%) U.S. FCC mandate [12] and [13] for wireless emergency calls

· 10m-50m Asset Location, route guidance, navigation

Accuracy may be independently considered with respect to horizontal and vertical positioning estimates. Some
location services may not require both, others may require both, but with different degrees of accuracy.
Given that the location estimate is the best possible within the bounds of required response time, the location
estimates of a fixed position UE (assuming several estimates are made) will reveal a ‘spread’ of estimates around the
actual UE position. The distribution of locations can be described by normal statistical parameters and suggests that a
small proportion of location estimates may lie outside of the acceptable Quality of Service (QoS) parameters for
specific services (as determined by the network operator).
It may be possible to provide information on the confidence that can be associated with a location estimate. This may
be used by location services to decide if a position update should be requested, for example, if the reported accuracy
falls below a threshold determined by the LCS Client or Network Operator for a specific service.
It may also be possible to determine velocity (speed and heading) information from a location request.
When delivered with a location estimate, the confidence region parameters, speed and heading may allow an
application to improve the service delivered to the UE user. Some examples are given below:
a) Confidence Region: Simple measure of uncertainty that specifies the size and orientation of the ellipse in
which an UE is likely to lie with a predetermined confidence (e.g. 67%). The size of the confidence region
may be used by the network operator or the LCS Client to request an updated location estimate.

b) Speed: enables e.g. congestion monitoring, and average travel time estimates between locations.

c) Heading: the location estimate of a vehicle may be improved to identify the appropriate side of the
highway. This may enable the provision of traffic information that relates only to the user's direction of
travel.

For Value Added Services and PLMN Operator Services, the following is applicable:

Accuracy is application driven and is one of the negotiable Quality of Service (QoS) parameters.

The precision of the location shall be network design dependent, i.e., should be an operator’s choice. This precision
requirement may vary from one part of a network to another.

ETSI
Release 18 14 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

The LCS shall allow an LCS Client to specify or negotiate the required horizontal accuracy. The LCS shall normally
attempt to satisfy or approach as closely as possible the requested or negotiated accuracy when other quality of
service parameters are not in conflict. The achieved accuracy level of location information shall be indicated using
the shapes and uncertainty areas defined in 3GPP TS 23.032 [2].

For Emergency Services (where required by local regulatory requirements) the following requirements shall be met:

- When providing a Location Estimate, the LCS Server shall attempt to obtain the horizontal location of the
calling UE, in terms of universal latitude and longitude coordinates, and shall provide this to an Emergency
Service Provider. The accuracy shall be defined by local regulatory requirements. Annex A shows such
requirements as exist in the United States.

- For Emergency Services within some countries, a network may be allowed to report accuracy at the cell id
level. If the UE and the serving network are capable of delivering a more accurate location, indication of this
capability may, as a national option, be supplied to the authorities along with the location. This indication will
notify the authorities that they are able to request location with a high accuracy QoS.

NOTE: The LCS Server provides the location service capabilities but the mechanism by which location is
reported to an emergency service provider is outside the scope of this service.

4.3.2 Vertical Accuracy

For Value Added Services, and PLMN Operator Services, the following is applicable:

- When providing a Location Estimate, the LCS Server may provide the vertical location of a UE in terms of
either absolute height/depth or relative height/depth to local ground level. The LCS Server shall allow an LCS
Client to specify or negotiate the required vertical accuracy. The LCS Server shall normally attempt to satisfy
or approach as closely as possible the requested or negotiated accuracy when other quality of service
parameters are not in conflict.

- The vertical accuracy may range from about three metres (e.g. to resolve within 1 floor of a building) to
hundreds of metres.

For Emergency Services (where vertical location is required by local regulatory requirements) the following is
applicable:

- The LCS Server shall attempt to obtain the vertical location or elevation of the calling UE and shall provide
this to an Emergency Service Provider.

- The vertical location of the UE shall be expressed in terms defined by local regulatory requirements which
may include absolute height/depth or relative height/depth to ground level.

- The vertical location accuracy shall be defined by local regulatory requirements. Annex A shows such
requirements that exist in the United States.

NOTE 1: The LCS Server provides the location service capabilities but the mechanism by which location is
reported to an emergency service provider is outside the scope of this service.

NOTE 2: The only known regulations for vertical accuracy for Emergency Services is in the United States (see
Annex A.) The vertical accuracy requirements in these regulations only apply to Emergency Services
usage over E-UTRAN and later defined access.

4.3.3 Response Time

Different location-based services, or different LCS Clients, may have different requirements (depending on the
urgency of the positioning request) for obtaining a response. The location server may need to make trade-offs
between requirements for positioning accuracy and response time.

For Value Added Services, and PLMN Operator Services, the following is applicable:

Response Time is one of the negotiable QoS parameters. Support of response time by a Public Land Mobile Network
(PLMN) is optional. The LCS Server may allow a LCS Client to specify or negotiate the required response time (in
the context of immediate location request, see table 1) either at provisioning or when the request is made. The LCS
Server may optionally ignore any response time specified by the LCS Client that was not negotiated. If response time

ETSI
Release 18 15 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

is not ignored, the LCS Server shall attempt to satisfy or approach it as closely as possible when other quality of
service parameters are not in conflict.

For immediate location request response time options are as follows:

a) “no delay”: the server should immediately return any location estimate or Dispatchable Location that it
currently has. The LCS Server shall return either the Initial or Last Known Location of the Target UE. If no
location estimate or Dispatchable Location is available, the LCS Server shall return the failure indication and
may optionally initiate procedures to obtain a location estimate or Dispatchable Location (e.g. to be available
for a later request).

b) “low delay”: fulfilment of the response time requirement takes precedence over fulfilment of the accuracy
requirement. The LCS Server shall return the Current Location with minimum delay. The LCS shall attempt to
fulfil any accuracy requirement, but in doing so shall not add any additional delay (i.e. a quick response with
lower accuracy is more desirable than waiting for a more accurate response).

c) “delay tolerant”: fulfilment of the accuracy requirement takes precedence over fulfilment of the response time
requirement. If necessary, the server should delay providing a response until the accuracy requirement of the
requesting application is met. The LCS Server shall obtain a Current Location with regard to fulfilling the
accuracy requirement.

For Emergency Services (where required by local regulatory requirements) there may be no requirement to support
negotiation of response time. The network shall then provide a response as quickly as possible with minimum delay.
Response time supervision is implementation dependent.

4.3.4 LCS QoS Class

The LCS QoS Class defines the degree of adherence by the Location Service to the quality of service parameters
(Accuracy and Response Time).

For Value Added Services and PLMN Operator Services, the following is applicable:

LCS QoS Class is a non-negotiable QoS parameter. Support of QoS Class by a Public Land Mobile Network (PLMN)
is optional. The LCS Service may allow a LCS Client to specify the required QoS Class (in the context of immediate
location request) either at provisioning or when the request is made. The LCS Service shall attempt to satisfy as
closely as possible the other quality of service parameters regardless of the use of QoS Class.

For immediate location request response, LCS QoS Class options are:

a) “Assured”: The other QoS parameters shall be adhered to strictly. The LCS Service shall obtain a Current
Location with regard to fulfilling the requirements set by the other QoS parameters. If the location request
response does not satisfy the other QoS parameters, the response shall be discarded by the LCS Service.

b) “Best Effort”: The other QoS parameters do not have to be adhered to strictly. The LCS Service shall obtain a
Current Location, using only one attempt with a single technology, with regard to fulfilling the requirements
set by the other QoS parameters. Even if the location request response does not satisfy the other QoS
parameters, the response may be forwarded to the LCS Client.

4.3.5 Dispatchable Location accuracy

Dispatchable Location accuracy can be expressed in terms of civic location granularity.

Dispatchable Location granularity refers to the specificity of the elements of civic location obtained. For example, a
civic address with a street number, street name, city, state and country provides a less specific civic location than
apartment number, floor, street number, street name, city, state and country. The expression of civic location
granularity is in terms of the mandatory civic location elements such as:

- City or Town

- Street number and name

- Floor number within a building

- Apartment, Suite, or Room number within a building

ETSI
Release 18 16 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

An example of regional regulatory requirements for Dispatchable Location granularity applicable to Emergency
Services can be found in [12] and [13].

For Emergency Services (where required by local regulatory requirements) the following requirements shall be met:

- When providing a Dispatchable Location, the LCS Server shall attempt to obtain the civic location of the calling
UE in terms of civic information elements (i.e. country, street name, floor), and shall provide this to an
Emergency Service Provider. The accuracy (granularity) shall be defined by local regulatory requirements.
Annex A shows such requirements as exist in the United States.

4.4 Reliability
Reliability provides a measure of how often positioning requests that satisfy QoS requirements are successful. For
some applications, such as cross-country vehicle tracking, this may not be especially critical. If a positioning attempt
fails, due to lack of coverage or transient radio conditions, etc, another positioning attempt may be made. This
attempt should be specified in Location Service Request. (see the section 5.3.1.1). However, for other services,
perhaps such as child tracking, reliability may be more important.
The network shall provide statistical reporting of reliability (QoS parameters) data.

4.5 Priority
Location requests for different services may be processed with different levels of priority.

For Value Added Services, and PLMN Operator Services, the following is applicable:

The LCS Server may allow different location requests to be assigned different levels of priority. A location request
with a higher priority may be accorded faster access to resources than one with a lower priority and may receive a
faster, more reliable and/or more accurate location estimate.

For Emergency Services (where required by local regulatory requirements) the location request shall be processed
with the highest priority level.

4.6 Timestamp
For Value Added Services, and PLMN Operator Services, and Emergency Services (where required by local
regulatory requirements), the LCS Server shall timestamp all location estimates or Dispatchable Location provided to
a LCS Client indicating the time at which the estimate was obtained.

4.7 Security
Specific local, national, and regional security regulations must be complied with.
Position information should be safeguarded against unapproved disclosure or usage. Position information should also
be provided in a secure and reliable manner that ensures the information is neither lost nor corrupted. Audit records
should be maintained of positioning requests and responses to facilitate resolution of security violations.

The LCS Client may be authorized by the LCS Server. Existing security mechanisms as well as security mechanisms
of the LCS Server shall be used for authorizing the LCS Client and its request for location information.

The target UE user shall be authenticated before being allowed to access (to modify/query) her personal data or
query/cancel an LCS request.

For Value Added Services, the following is applicable:

Only authorized LCS Clients shall be able to access the LCS Server. Before providing the location of a Target UE to
any authorized LCS Client, the LCS Server shall verify both the identity and authorization privileges of the LCS
Client .

Once the LCS Server has verified that a particular LCS Client is authorized to locate a particular Target UE, any
location estimate or Dispatchable Location requested shall be provided to the LCS Client in a secure and reliable

ETSI
Release 18 17 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

manner, such that the location information is neither lost, corrupted nor made available to any unauthorized third
party.

For PLMN operator services, location information shall be provided in a secure and reliable manner. The ability to
obtain location information shall depend on local regulatory laws and requirements in conjunction with requirements
for UE privacy.

For Emergency Services (where required by local regulatory requirements) the following requirements shall be met:

Position information shall be provided to the Emergency Services Network as an authorized LCS client. Target UE
authorization checks normally performed for value added services are not applicable (privacy is over-ridden). The
position information shall be provided to the Emergency Services Network in a secure and reliable manner, such that
the location information is neither lost, corrupted, nor made available to any unauthorized third party.

4.8 Privacy
Specific local, national, and regional privacy regulations must be complied with, and multiple layers of permissions
may be required.
Location information must always be available to the network service provider.
Means shall be provided for the UE subscriber to control privacy for value added services.
The user shall be able to change the setting of the Privacy exception list at any time.
Unless required by local regulatory requirements, or overridden by the target UE User, the target UE may be
positioned only if allowed in the UE subscription profile. In general, for valued added location services, the target UE
being positioned should be afforded the maximum possible privacy, and should not be positioned unless the
positioning attempt is explicitly authorized. In the absence of specific permission to position the target UE, the target
UE should not be positioned.
It may also be possible for a target UE to authorize positioning attempts after the target UE is notified of a
positioning request and the target UE grants permission for positioning. It shall also be possible to make the
notification conditional on the current location of the target UE. In this case the notification shall be performed after
the target UE is positioned but before reporting the location of target UE to LCS Client. This notification condition
(notification with privacy verification) shall be specified in the Target UE Subscription Profile. (See the subsequent
"target subscriber notification" section of this document for charging and billing aspects.) The operator shall be able
to determine the location of the target UE (e.g. for lawful interception or emergency call).

The privacy of an inanimate asset for an embedded target UE may be completely defined by the UE subscriber.
Additionally, specific privacy exceptions may exist for compliance with mandated location-based services (such as
for emergency services or lawful intercept) which are required by national or local regulatory requirements.

For Value Added Services, the following is applicable:

The Target UE Subscriber shall be able to restrict access to the Location Information (permanently or on a per
attempt basis). The LCS Client access shall be restricted unless otherwise stated in the Target UE Subscription
Profile. The home network shall have the capability of defining the default circumstances in which the Target UE’s
Location Information is allowed to be provided - as required by various administrations and/or network requirements.

The privacy check shall be performed in the Home Environment of the target UE subscriber. This makes it possible
for operators to ensure the privacy of their own subscribers i.e. the privacy settings that are used for privacy checks
are always up to date and as specified by the Home Environment of the target UE subscriber. It shall be possible for
privacy check to take into account Home Environment specific information such as time of day, subscriber location.
It shall be possible to ensure that privacy checks are performed according to the latest information as available in the
Home Environment.
It shall be possible for location services to support conditional positioning. Under these conditions, an application that
is granted conditional positioning authorization must notify and obtain positioning authorization from the user of the
target UE prior to performing the positioning process. Thus, the user of the target UE shall be able to accept or reject
the positioning attempt.

It shall be possible for location services to support conditional reporting if the target UE is within specified
geographical areas. Under these conditions, an application that is granted conditional positioning authorization must

ETSI
Release 18 18 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

notify and obtain positioning authorization from the user of the target UE after the positioning process is preformed
but before reporting the location of the target UE to the LCS Client

The default treatment, which is applicable in the absence of a response from the Target UE, shall be specified in the
Target UE Subscription Profile. Thus, for some location services the default treatment may be to accept the
positioning request, whereas for other location services the default treatment may be to reject the positioning attempt.

However, considering that in general, users shall be afforded the maximum possible privacy, and shall not be
positioned unless the target subscriber authorizes the requesting location application to perform positioning, the
default condition shall normally be to deny the positioning attempt.

For PLMN operator services, the target UE subscriber may be able to restrict access to location information used to
enhance or support particular types of service. The LCS client access shall be restricted unless stated otherwise in the
Target UE subscription profile. The target UE user shall not be notified of any authorized location attempt.

For Emergency Services (where required by local regulatory requirements) Target UEs making an emergency call
may be positioned regardless of the privacy attribute value of the subscriber associated with the Target UE (or ME)
making the call.

For Lawful Interception Services (where required by local regulatory requirements), target UEs may be positioned
under all circumstances required by local regulatory requirements. The target UE user shall not be notified of any
location attempt.

All location requests (LRs) shall be done with a privacy check except for the following:

- LRs relating to lawful interception

- LRs related to emergency calls

- LRs from the serving network related to anonymous tracking for statistical and O&M purposes

- LRs from the home network as requested by the home network operator for its own internal purposes. The
home network operator should not use the UE location information, which was obtained from the visited
network without privacy checks, for value added services or to forward such location information to any third
party (except for the cases of lawful interception or emergency calls).

4.8.1 Service Type Privacy

The user may wish to differentiate between privacy requirements even with one LCS Client, depending on which
service the user requests from this LCS client or which service the LCS client offers to the user.

The users shall be able to allow or deny their location information to be given to LCS clients providing an indicated
type of service. The user could e.g. allow all dating type services to get location information but decline other types
of services to get the user’s location. The location request message issued by the LCS client may include a service
identity, and the LCS Server may interpret that the indicated service belongs to a certain Service Type. The
subscriber shall be able to define and set privacy rules based on service type, so that services belonging to that service
type shall be handled according to the corresponding service type privacy setting.

It shall be possible to verify that the service type indicated by the LCS client is correct. The service type privacy
check may be done by the LCS server or by the user of the target mobile.

The LCS Server shall be aware of what service types a certain LCS Client supports. The LCS Server shall map the
service identity given by the LCS client to a service type, as described below. The PLMN operator defines to what
service type the given service identity belongs to.

4.8.1.1 Standardized Service Types

Annex C lists the attributes of specific location-based services as determined by the GSM Alliance Services Working
Group. The standardized Service Types to be used in privacy checking are listed in table 4.2 and are based on the
services listed in Annex C. It is noted that not all services listed in Annex C need belong to a standardized service
type.

It should be noted that only the names and identities (number) of the Service Types are standardized.

ETSI
Release 18 19 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

It shall be possible for the network operator/service provider to define additional, non-standardised service types that
need not be globally unique.

Table 4.2, Standardized Service Types

Location based services Standardized

categories Service Types
Public Safety Services Emergency Services

Emergency Alert Services

Location Sensitive Charging
Tracking Services Person Tracking
Fleet Management.
Asset Management

Traffic Monitoring Traffic Congestion Reporting

Enhanced Call Routing Roadside Assistance

Routing to Nearest
Commercial Enterprise
Location Based Traffic and public
Information Services transportation information
City Sightseeing
Localized Advertising
Mobile Yellow Pages
Weather
Asset and Service Finding
Entertainment and Gaming
Community Services Find Your Friend
Dating
Chatting
Route Finding
Where-am-I
Service Provider
Specific Services

Note: It should not be possible for the target UE subscriber to block the emergency services Service Type, so
maybe this Service Type is not needed, this is FFS.

4.9 Service Authorization

Requests for positioning information should be processed only if the requesting application is authorized. The identity
and authorization privileges of the requesting application should be verified prior to processing positioning requests.

4.10 Service Activation and De-Activation

To maximize the adoption of location services, the service activation process must be simple. Three types of service
package, may be distinguished, each of which may require a different service activation process:

1 On Demand: the user accesses services only when required.

2 Period Subscription: the subscriber requires periodic availability of the service

3 Mixed: some services provided on subscription and the remainder on-demand.

The process of activation + service delivery + deactivation may be provided in a single transaction. It may be
possible for a subscriber to activate a location service on one occasion before deactivating an existing invocation.

ETSI
Release 18 20 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Furthermore, a location service may be ‘enabled’ at the point of sale as part of the service package purchased by the
UE subscriber. The use of Over-The-Air (OTA) provisioning may allow the location feature to be enabled for UE-
based positioning methods.

4.11 Coverage
In general a UE user should be able to access a location service anywhere within the operator’s coverage area, or
within the roaming area. Three levels of coverage may be considered:
1 Home Network - Complete

2 Home Network - Partial

3 Roaming Networks

Considering network topography and dynamically varying environmental factors, a network operator may not be able
to guarantee homogeneous service quality across the entire home network geographic area, or roaming partners'
networks. Even within those areas where service is offered, the provided quality of service may vary due to dynamic
environmental (i.e. radio) conditions. Additionally, the location method may have an accuracy that depends on the
UE location, for example due to varying radio conditions, cell configuration and cell density in different areas, and
geometric dilution of precision.
Furthermore, the roaming partner's network may not accept a similar location method to that experienced by the user
in the home network.
Finally, the service may not be available in a roaming partner’s network despite technical interoperability between
the location method supported by the UE and the network.
Therefore, coverage may be considered not only to be a technical attribute, but may also be related to roaming
contracts between network operators. In general, provided that a roaming agreement exists, any properly authorized
location-based service may position a Target UE in either the Home PLMN (HPLMN) or a Visited PLMN (VPLMN).
It may also be noteworthy that some location-based services (such as location-based information services) may be
especially attractive to subscribers roaming outside their home networks.

4.12 Roaming Target UE

With respect to roaming, specific local, national, and regional privacy regulations must be complied with, and
multiple layers of permissions may be required.
Many location-based services may be especially attractive to subscribers roaming outside their home PLMN. As such,
support should be provided for the transparent and consistent provision of location-based services to the fullest extent
possible. Consideration for roaming support should be provided with the following priorities:

1. Roaming between 3GPP networks.

2. Roaming between 3GPP systems and IMT 2000 family networks.

3. Roaming between 3GPP and ANSI-41 or other systems.

If the location capability in the VPLMN is compatible with that provided in the HPLMN, the same parameters must
be provided to the location server in the VPLMN that would be provided to the server in the HPLMN to enable
provision of the same services.

For Value Added Services, the following is applicable:

Provided that a roaming agreement exists, the LCS feature shall allow any properly authorized LCS client to request
and receive the location of a particular Target UE when the Target UE is either located in its Home PLMN (HPLMN)
or Visited PLMN (VPLMN). The LCS client shall be authorised by the HPLMN of the subscriber whose UE is the
target of the location attempt. Any PLMN not supporting the LCS feature shall return a suitable error response to any
other PLMN from which an LCS request is received. The requesting PLMN shall then infer that the LCS feature is
not supported and provide a suitable error response in turn to the requesting LCS Client.

For PLMN Operator Services, location of any roaming target UE shall be supported in the VPLMN as allowed by
both local regulatory requirements and considerations, where applicable, of UE privacy.

ETSI
Release 18 21 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

For Emergency Services (where required by local regulatory requirements) the Serving PLMN shall support the
positioning of all Target UEs including roaming Target UEs currently serviced by that serving PLMN. There is no
requirement for a HPLMN to position Target UEs that have roamed outside the HPLMN.

4.13 Support for all UEs

For value added services, and PLMN operator services, the LCS feature may be supported for all UEs.

For Emergency Services (where required by local regulatory requirements), positioning shall be supported for all UEs
(i.e. including legacy UEs) where coverage is provided, and also UEs without a SIM/USIM. In such a case, the
location of the caller may be determined using the identity associated with the Mobile Equipment (ME) involved in
the call.

Both “active” and “idle” UEs shall be capable of being positioned.

4.14 Support for Unauthorized UEs

For value added services, support of unauthorized UEs may be provided by the PLMN.

For PLMN operator services, positioning of unauthorized UEs may be provided by the PLMN as required by local
regulatory requirements.

For Emergency Services (where required by local regulatory requirements), the PLMN shall support positioning for
unauthorized UEs (i.e. including stolen UEs and UEs without a SIM/USIM).

NOTE: A subscriber is in general identified as a UE containing in it the SIM/USIM associated with the
subscriber. In some exceptional cases (e.g., an Emergency call), a UE without a valid subscription
recognized in the PLMN can become a Target UE. In such a case, the subscriber may be identified by
the identity associated with the Mobile Equipment (ME) involved in the call.

4.15 Periodic Location Reporting

Periodic location reporting is the act of the LCS Server initiating multiple position locations spread over a period of
time.

The periodic reporting function is generally applicable for asset management services and exists as several variants,
each applicable to different value-added services:

· Location reporting only within predetermined e.g. commercial asset tracking and, subject to
period provision of privacy, manpower planning.

· Periodic location reporting within specified e.g. high value asset security, stolen vehicle
period and reporting triggered by a specific monitoring, home zone charging.
event

· Periodic location reporting triggered by a e.g. 24hr depot management, transit passenger
specific event information systems

Periodic location determination and reporting increases network traffic. However, scheduling the periods of location
monitoring and reporting will reduce this. Finally, event-based logic provided by the network operator that monitors
the asset (location and status) and only reports events that meet conditions agreed with the application may reduce
network traffic further without reducing the QoS.
If this event-based or time-based decision process is the responsibility of the application and not the network operator
then all of the above services can be regarded as periodic location reporting.

For value added services, and PLMN operator services, support of periodic location reporting may be provided by the
PLMN.

ETSI
Release 18 22 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

When an LCS client activates Periodic Location Reporting, the LCS server shall be able to inform the target UE of
this activation according to the Privacy Exception List.

Optionally, it may be possible for the target UE at any time to query the LCS server about any valid requests
activated for that target UE, and/or cancel the request.

When a request is cancelled by the target UE, the LCS server shall inform the LCS client of this cancellation.

It should be possible for more than one LCS client to activate requests for the same target UE.

For Emergency Services (where required by local regulatory requirements), there is no requirement for the PLMN to
support periodic location reporting.

4.16 UE-Based Location Calculation

UE-Based Location Calculation may be supported on either a per-request basis or semi-autonomously whereby a
single request from a UE subscriber enables UE based location calculation over an extended period without further
interaction with the PLMN.

For Commercial Services, the following may be applicable for semi-autonomous location:

The network may broadcast location assistance information to mobiles, which enables mobiles to
calculate their own location. The network may encrypt the location assistance information. If the
location assistance information is encrypted, a single common standardized encryption algorithm
shall be used.

The location assistance information may be available to the UE at all times, continuously in idle
mode and during a call, without additional point to point signalling. The network may request
location information from the UE for operator or for service provider applications. For this purpose,
a point to point signalling connection must be established.

4.17 UE_Assisted LCS Location Calculation

The UE-Assisted Location Calculation is accomplished by network resources based upon radio ranging measurements
provided by the UE.

For Commercial Services, the following may be applicable for UE-Assisted location services:

The network may broadcast assistance information to mobiles, which enables mobiles to obtain the appropriate
radio ranging measurements. The network may encrypt the assistance information. If the assistance
information is encrypted, a single common standardized encryption algorithm shall be used.

The assistance information may be available to the UE at all times, continuously in idle mode and during a
call, without additional point to point signalling. The network may request radio ranging measurement data
from the UE for operator or for service provider applications. For this purpose, a point to point signalling
connection must be established. Optionally, this point to point connection can be used to deliver the resulting
location to the UE.

4.18 Mobile Originating Location

Mobile Originating Location is the capability of the mobile station to obtain its own geographical location or have its
own geographic location transferred to another LCS client.

For Value Added Services, the following may be applicable:

There are three classes of mobile originating location:

Basic Self Location - The mobile station needs to interact with the network for each separate location request

Semi-autonomous Self Location - One interaction with the network assists the mobile station to obtain multiple
location positionings over a predetermined period of time.

ETSI
Release 18 23 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

NOTE: Autonomous Self Location – The mobile needs no interaction with the network and is therefore
considered to be outside the scope of this technical specification.

Transfer to Third Party – The location of the mobile station is transferred by request of the mobile station to another
specified LCS client.

4.19 Network support for LCS

The provision of location services shall be possible without significantly adversely impacting the radio transmission
or the signalling capabilities of the network.

5 Logical Description

5.1 Logical Reference Model

Figure 1 shows the logical reference model for LCS whereby an LCS Client is enabled to request location
information for one or more certain target UEs from the LCS Server supported by a PLMN. The LCS Server employs
a positioning function to obtain the location information and furnish the information to the LCS Client. The particular
requirements and characteristics of an LCS Client are made known to the LCS Server by its LCS Client Subscription
Profile. The particular LCS-related restrictions associated with each Target UE are detailed in the Target UE
Subscription Profile. The LCS feature shall allow a Target UE to be positioned within a specified Quality of Service.
The LCS feature shall allow the location of a Target UE to be determined at any time whilst the UE is attached.

The LCS feature shall support conveyance of both the location Quality of Service (QoS) requirements of the LCS
Client and the location information returned to the LCS Client in a universal standard format.

Figure 1. LCS Logical Reference Model

ETSI
Release 18 24 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

5.2 Functional Entities

5.2.1 LCS Client
An LCS Client is a logical functional entity that makes a request to the PLMN LCS server for the location
information of one or more than one target UEs within a specified set of parameters such as QoS. The LCS Client
may reside in an entity (including an UE) within the PLMN or in an entity external to the PLMN. When the LCS
client resides in an entity external to the PLMN, the LCS client may be connected to several Requestors who
originate the location requests. The specification of the LCS Client’s internal logic and its relationship to any external
user (e.g. Requestor) is outside the scope of this document.

5.2.2 LCS Server

An LCS server consists of a number of location service components and bearers needed to serve the LCS clients. The
LCS server shall provide a platform which will enable the support of location based services in parallel to other
telecommunication services such as speech, data, messaging, other teleservices, user applications and supplementary
services and therefore enable the market for services to be determined by users and service providers. The LCS server
may respond to a location request from a properly authorized LCS client with location information for the target UEs
specified by the LCS client if considerations of target UE privacy are satisfied. The LCS server may enable an LCS
client to determine the services provided to it by the LCS server through a process of provisioning.

5.2.3 Positioning Function

Positioning is the basic function that performs the actual positioning of a specific target UE. The input to this
function is a positioning request from a LCS Client with a set of parameters such as QoS requirements. The end
results of this function are the location information for the positioned target UE.

5.2.4 Target UE
The Target UE is the object to be positioned by the LCS Server. For network-based positioning methods, no support
for LCS is required by the target UE. For mobile assisted and mobile based positioning methods, the target UE
actively supports LCS. For all positioning methods, the ability to control privacy may be required to be given to the
UE user for each location request and/or to the UE subscriber through the Target UE subscription profile to satisfy
local regulatory requirements (see the previous section on Privacy).

5.3 Functional Interfaces

5.3.1 LCS Client / LCS Server Interface
The LCS client/server use LCS messages to exchange information. Each LCS message contains a set of parameters.

In the case of UE Based positioning methods, if the LCS Client is located in the UE, then an internal LCS Client
/LCS Server interface may be supported.

NOTE: Further regional/national specific interfaces between LCS clients and servers may need to be supported
in addition to the interfaces described here.

5.3.1.1 Location Service Request

Using the Location Service Request, an LCS client communicates with the LCS server to request the location
information for one or more target UEs within a specified set of quality of service parameters.

As shown in Table 1, a location service may be specified as immediate or deferred.

ETSI
Release 18 25 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Table 1: Location Service Requests

Request Type Response Time Number of

Responses
Immediate Immediate Single
Deferred Delayed (event One or More
driven)

If a positioning attempt fails, the LCS server may make another positioning attempt. This attempt should be made
when the target UE can be detected by the network. It may be possible for the LCS client to set this action as an
option. This optional action should be applied for both request types.

Note: This functionality may be provided using one or more of the existing toolkits, including but not limited
to CAMEL and OSA.

When using the Deferred type (event driven), the LCS client shall be able to set the following items:

- Time interval of positioning

- Number of responses (if needed)

- Valid period of the request (if needed)

- Type of event

Currently following events are introduced:

- UE available

- Change of Area

It shall be possible for the LCS client to cancel the pre-arranged request.

It shall be possible for the LCS server to set the minimum time interval of positioning allowed.

It shall be possible to limit the area where the Change of Area event will be reported e.g use the OSA messages
defined in 3GPP TS 29.198.

For Emergency Services, LCS shall support requests for the initial, the current (updated), or the last known position
of an ME while a voice connection is established.

5.3.1.2 Location Service Response

The Location Service Response provides the result of a Location Service Request from the LCS Server to the LCS
Client.

A LCS response is either ‘immediate’ or ‘deferred’. The LCS Request indicates the type of response the LCS Client
wishes to receive. The two types of location response are described in table 2.

Table 2: Types of LCS Response

Response Description
Immediate A Location Response is referred to as ‘immediate`, when a response to a request for location
information is answered immediately (within a set time). The response shall be single and not
dependent to any event.
Deferred A Location Response is referred to as ‘deferred’, when a response to a request for location
information is returned after the occurrence of an event specified by the LCS client. The
response can be single or periodic.

When the location positioning for the target UE has failed, the LCS server may be able to report the reason for failure
and Last Known Location with the relevant timestamp.

ETSI
Release 18 26 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

5.3.1.3 Location Service Request Report

The Location Service Request Report provides the result of a deferred Location Service Request from the LCS Server
to the LCS Client. The report is provided using a dialog between the LCS Client and the LCS Server that is initiated
by the LCS Server.

5.4 Location information

5.4.1 Sources of location information
It shall be possible for the location determining process to make use of several sources of information in determining
the location. Propagation and deployment conditions may limit the number or quality of measurements or additional
measurements may be possible. Some ME may also have additional (independent) sources of position information.
The LCS shall be capable of making use of the restricted or the extra information as appropriate for the service being
requested.

6 Service Provision

6.1 Identification of a Target UE

For value added services, the following is applicable:

The LCS client shall identify a target UE using the MSISDN or SIP URL.

The LCS Client shall be able to identify the target UE using IP addressing.

For PLMN operator services, the LCS client may identify a target UE using any of the following:

MSISDN

SIP URL

IMSI

An identifier internal to the PLMN

For emergency services (where required by local regulatory requirements), the LCS client may identify a target UE
using any one of the following:

MSISDN

SIP URL

IMSI

NA-ESRK + (optionally) IMEI, applicable for regions using the ANSI standards

IMEI, applicable for regions using the ETSI standards

IMEI is used for unauthorized UEs or UEs without SIM/USIM. In regions using ETSI standards it shall be
indicated that the use of this identification is triggered by an emergency call.

It shall be possible for the target mobile’s user to hide her true identity from the requestor and the LCS client and
replace it with an alias. The alias shall be a unique identification that has a one-to-one relationship to the true identity
of the subscriber and may be permanent or temporary. The target mobile user shall be able to know her own alias so
that she can pass the alias to the LCS client, e.g. when invoking a location-based service.

ETSI
Release 18 27 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

6.2 Location Information Provided to the LCS Client

For value added services, the following is applicable:

The LCS Server shall provide, on request, the current or most recent Location Information (if available) of the Target
UE or, if positioning fails, an error indication plus optional reason for the failure.

For PLMN operator services (where allowed by local regulatory requirements and restrictions on UE privacy),
Location Information for a particular target UE may be provided to a PLMN operator LCS client either on request or
on the occurrence of an event in the LCS server that has been defined to equate to such a request.

For emergency services (where required by local regulatory requirements), the geographic location or Dispatchable
Location may be provided to an emergency services LCS Client either without any request from the client at certain
points in an emergency services call (e.g. following receipt of the emergency call request, when the call is answered,
when the call is released) or following an explicit request from the client. The former type of provision is referred to
as a “push” while the latter is known as a “pull”. In the case of a “pull”, the emergency service LCS Client shall
identify the Target UE as defined in section 6.1. Table 3 shows the information that may be provided to the client for
either a “push” or a “pull”.

Table 3: Location related information provided to an emergency services LCS Client

Type of Access Information Items

Push Current Dispatchable Location (if available)
Current Geographic Location (if available)
MSISDN
SIP URL
IMSI
IMEI
NA-ESRK
NA-ESRD
State of emergency call – unanswered, answered,
released (note 1)
Pull Dispatchable Location (note 2), either:
Current civic location or
Initial civic location at start of emergency call
Geographic location (note 2), either:
Current location or
initial location at start of emergency call
Both Dispatchable Location and geographic location
(note 2), either:
Current location or
initial location at start of emergency call

NOTE 1: indication of call release means that any NA-ESRK will no longer identify the calling UE subscriber

NOTE 2: which type of location is required will be indicated by the LCS Client

6.3 LCS Client Subscription

It shall be possible for an LCS Client to subscribe to the LCS feature for third-party location with or without
subscription to other services. An LCS Client may subscribe to one or more service providers’ LCS feature in one or
more PLMNs. The LCS Client Subscription Profile of a client may contain the range of QoS and subscriptions that
the LCS Client is allowed to request.

For certain authorized LCS Clients internal to the PLMN, a subscription profile may be unnecessary. For these LCS
Clients subscription to LCS feature is given implicitly as a result of subscription to an authorized PLMN service (e.g.
supplementary services). These LCS Clients are empowered to access the LCS Server and request location
information for a Target UE.

For emergency services, the subscription requirements to the LCS feature may not be needed.

ETSI
Release 18 28 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

6.4 Target UE Subscription

6.4.1 Privacy Subscription Options
It shall be possible for a Target UE Subscriber to subscribe to various types of privacy classes. The default treatment
in the absence of the information to the contrary in the Target UE Subscription Profile shall be to assume that access
is restricted to all LCS Clients (unless using privacy overriding, or otherwise overridden by local regulatory
requirements).

Privacy Attributes consist of:

Codeword: an additional level of security that may be set by a Target UE user to determine which Requestors
are allowed to request location information;

Privacy Exception List: determines which LCS Clients, services and classes of LCS Clients may position a
Target UE;

Service Type Privacy: determines whether the service type allows the LCS Clients to get the position of a
Target UE;

Privacy Override Indicator: determines applicability of the Privacy Exception List.

6.4.2 Codeword
It shall be possible for a Requestor and an LCS client to request location information by indicating a Codeword
associated with the Target UE user. The codeword shall be either checked by the Target UE/user or by the LCS
server in the home network. In the former case, the codeword supplied by the requestor and forwarded by the LCS
client with the request shall be forwarded to the Target UE/user for verification and acceptance. In the latter case, the
codeword shall be registered with the LCS server by the Target UE user (or subscriber) in advance. Optionally, the
UE and/or network may have the capability to generate and/or distribute codewords. The generation of codewords
and the distribution of those codewords are out of scope of this specification. A comparison of the codeword sent by
the Requestor and the registered codeword shall be performed. A location request shall only be accepted if this
comparison is successful. In the case where the Target UE/user does not check the codeword, the codeword need not
be sent to the Target UE/user. In the case where the codeword is checked by the Target UE/user, the Target UE
subscriber need not register the codeword in advance.

The other privacy settings should also be checked even when the codeword has been checked.

The Target UE Subscriber may register multiple codewords for multiple requestors. Once the codeword has been set
and properly distributed, the Target UE user would be protected against location requests from third parties, which do
not know the appropriate codeword.

It should be possible for a Target UE subscriber to enable and disable codeword checking for each of the LCS
Clients.

The codeword is applicable to the value-added services only.

6.4.2.1 Enhanced codeword

It shall be possible for the target UE/ user to secure the codeword from being misused. Only the intended requestor or
LCS client shall be able to use the secured codeword.

It shall be possible for the target UE/user to ensure that the secured codeword can be used only within a specific time
period, as determined by the target UE/user. It shall be possible for the target UE/user to ensure that a secured
codeword can be used only a specific number of times, as determined by the target UE/user.

The user of the target UE shall not need to be involved in checking the validity of the secured codeword during the
location service request. The secured codeword shall be checked by the LCS server.

ETSI
Release 18 29 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

6.4.3 Privacy Exception List

To support privacy, the LCS Server shall enable each Target UE Subscriber to subscribe to a “privacy exception list”
containing the LCS Client identifiers, the service identifiers, classes of LCS Clients, the target subscriber notification
setting (with/without notification) and the default treatment, which is applicable in the absence of a response from the
Target UE for each LCS Client and service identifiers.

The privacy exception list shall support a minimum of 20 clients. For each client the privacy exception list shall
support a minimum of 10 services. The maximum number of clients and services shall be determined by
implementation constraints.

If the target subscriber notification is set as “notification with verification”, each positioning request from the LCS
Client or the service shall be notified to the target UE before positioning. If the target subscriber notification is set as
“notification with verification based on current location”, positioning requests from the LCS Client or the service
shall be notified to the target UE after positioning is performed if the current location of the target UE is within the
areas specified to require notification. The treatment for location request from the LCS Client or service, which is not
registered in the privacy exception list, shall also be specified in the privacy exception list. An empty privacy
exception list shall signify an intent to withhold location from all LCS Clients.

The classes that can be included are as follows.

- Universal Class: location services may be provided to all LCS Clients;

- Call/session-related Class: location services may be provided to any value added LCS clients or a particular
value added LCS client or a particular service or particular group of value added LCS Clients – where each
LCS Client, service or group of LCS Clients is identified by a unique international identification, e.g. E.164 -
that currently has a temporary association with the Target UE in the form of an established voice, data call or
PS session originated by the Target UE. For each identified LCS Client, service or group of LCS Clients, one
of the following geographical restrictions shall apply:

a) Location request allowed from an LCS Client or service served by identified PLMN only;

b) Location request allowed from an LCS Client or service served in the home country only;

c) Location request allowed from any LCS Client or service;

- Call/session-unrelated Class; location services may be provided to a particular value added LCS Client or a
particular service or particular group of value added LCS Clients – where each LCS Client, service or group of
LCS Clients is identified by a unique international identification, e.g. E.164. For each identified LCS Client,
service or group of LCS Clients, one of the following geographical restrictions shall apply:

a) Location request allowed from an LCS Client or service served by identified PLMN only;

b) Location request allowed from an LCS Client or service served in the home country only;

c) Location request allowed from any LCS Client or service;

- PLMN Operator Class – location services may be provided by particular types of LCS clients supported within
the HPLMN or VPLMN. The following types of clients are distinguished (see note):

a) Clients broadcasting location related information to the UEs in a particular geographic area – e.g. on
weather, traffic, hotels, restaurants;

b) O&M client (e.g. an Operations System) in the HPLMN

c) O&M client (e.g. an Operations System) in the VPLMN

d) Clients recording anonymous location information (i.e. without any UE identifiers) – e.g. for traffic
engineering and statistical purposes

e) Clients enhancing or supporting any supplementary service, IN service, bearer service or teleservice
subscribed to by the target UE subscriber.

ETSI
Release 18 30 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

NOTE: The definitions of the various PLMN operator categories may be supplemented by more precise
language in contractual agreements both between UE subscribers and their home service providers and
between individual network operators with inter-PLMN roaming agreements. Such classification of the
PLMN operator categories is outside the scope of this specification.

6.4.4 Privacy Override Indicator

The privacy override indicator is applicable to lawful intercept and emergency services as allowed by local regulatory
requirements. It is not applicable to value added and PLMN operator services. The Privacy Override Indicator shall
be used to determine whether Subscriber Privacy of the Target UE subscriber should be overridden or not. This
indicator will be set for certain special LCS Clients when it is justified. Each LCS Client shall be associated with a
particular value of a position privacy override indicator during the LCS Client provisioning. The privacy override
indicator is normally only valid when the LCS Server for the LCS client is located in the same country of the Target
UE. If agreed by bi-lateral agreements between operators, the privacy override indicator shall also be valid when the
LCS client is not located in the same country as the Target UE.

6.4.5 Subscription to Mobile Originating Location

The UE subscriber may subscribe to the following types of Mobile Originating Location (as defined in section 4):

A) Basic Self Location

B) Semi-autonomous Self Location

C) Transfer to Third Party

6.4.6 Void

6.4A Requestor
The Location Request issued by the LCS client to GMLC shall optionally include also the identity of the originator of
the location request, i.e. the Requestor, not only the identity of the LCS client.

The requestor shall be authenticated by the LCS client and/or the network.

The identity of the Requestor shall be included in the privacy interrogation request. It may be either checked by an
entity in the network, the Target UE or the user.

It shall be possible for the requestor to use an alias, so that the true identity of the requestor is unknown to the LCS
client. The alias shall be a unique identification that has a one-to-one relationship to the true identity of the requestor
and may be permanent or temporary. The LCS client shall indicate the requestor alias instead of the real requestor
identity in the location request. The target mobile user in this case authorizes the requestor based on the requestor’s
true identity, after it has been decrypted in the requestor’s operator’s network.

6.5 Security
The LCS Server may authorize the LCS Client. There may be security mechanisms to authorize the LCS Client’s
request for locating a Target UE based on:

LCS Client access barring list(s),

PLMN/SP access barring list,

Point of origin of a location request.

ETSI
Release 18 31 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

6.6 Charging
The LCS Server shall enable a PLMN to charge LCS Clients for the LCS features that the PLMN provides. . The
information that the operator uses to generate a bill to an LCS Client is operator or service provider specific. The
charging information may be collected both for the LCS Client and for inter-network revenue sharing.

To support charging and billing for location services, additional information will need to be provided in call detail
records.
Charging for value added location services may be provided on a transaction basis, periodically, or a mixture of both.
To support transaction-based charging where applicable, service associated call detail records may need to include (as
a minimum) the following additional information (depending on the specific service):
 Type and Identity of the LCS Client;
 Identity of the target UE;
 Results (e.g. success/failure, method used, position, response time, accuracy)
 Time Stamp;
 Type of coordinate system used.

6.7 LCS Open Service Architecture and Application Programming

Interface
Note: LCS information may be accessible through the Open Service Architecture (OSA) standardized
Application Programming Interface (API). OSA service aspects of LCS are described in 22.127. [6]

7 Provisioning and Administration

7.1 Procedures for an LCS Client

These procedures are concerned with the LCS client’s provisioning and administration to the LCS feature.

7.1.1 Provisioning
Provisioning is an action to make the LCS feature available to a subscriber.

Provisioning may be:

- General: where the service may be made available to all subscribers without prior arrangements being
made with the service provider (i.e. emergency calls).

- Pre-arranged: where the service is made available to an individual LCS Client only after the necessary
arrangements have been made with the service provider.

7.1.2 Withdrawal
Withdrawal is an action taken by the service provider to remove an available LCS feature from a LCS Client’s
subscription profile.

Withdrawal may be:

- General: where the LCS feature is removed from all LCS Clients.

- Specific: where the LCS feature is removed on an individual basis per LCS Client.

ETSI
Release 18 32 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

7.1.3 Invocation
Invocation is an action to invoke the LCS feature, taken by the LCS Client (e.g. issuing a location request) or
automatically by the LCS server as a result of a particular condition (e.g. periodic location request, mobile originating
emergency call, etc.).

7.2 Procedures for a Target UE

These procedures are concerned with a Target UE’s privacy exception list. For emergency services, provisioning and
withdrawal for Target UEs may not apply.

7.2.1 Provisioning
Provisioning is an an action to make the privacy exception list with its privacy classes available to a Target UE. The
provision may be:

- General: where the list is made available to all Target UE’s without prior arrangements being made with
the service provider. The list shall contain the default privacy class.

- Pre-arranged: where any extra privacy permission class (--granting permission to locate an UE Client) shall
be capable of being independently provisioned for a target UE as agreed with the service provider for a
certain contractual period.

7.2.2 Withdrawal
Withdrawal is an action taken by the service provider to remove an available privacy class from a target UE’s PEL.
Withdrawal may be:

- General: where a privacy class is removed from all target UEs provided with this privacy class.

- Specific: where each of the privacy classes in the privacy exception list shall be independently withdrawn at
the subscriber’s request or for administrative reasons.

7.2.3 User Control

The user shall be able to change the following settings in the privacy exception list:

- the LCS Client and/or group of LCS Clients list

- the codeword

- the requestor

- the service types

- the target subscriber notification setting (with/without notification)

- the default treatment, which is applicable in the absence of a response from the Target UE for each LCS Client
identifiers.

7.3 Barring Capability of the Location Service

It shall be possible for operators to bar the Location Service of a specific user at any time. i.e. any location requests
towards the user’s Target UE and her own location requests towards her own Target UE are barred.

If the LCS request fails due to barring, then an error cause is returned to the LCS Requestor.

For Emergency Services and other services where required by local regulatory requirements, and for PLMN operator
Services, the location request shall be processed with the highest priority level regardless of the barring status of LCS.

ETSI
Release 18 33 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

8 Interactions with Bearer and Teleservices and Other

Services
LCS shall support location of any Target UE that is idle or has established any CS teleservice, bearer service or PS
session.

Location of a GPRS terminal or a UE using SMS may be supported.

Provision of location services to assist supplementary services and CAMEL is outside the scope of this specification.
The operation of location services shall be independent of other services - including Number Portability, private
numbering, CAMEL, supplementary services, teleservices, and bearer services.

9 Cross Phase Compatibility between releases

This section details the cross-phase compatibility requirements relating to the service requirements in this document.

Note: when a change is introduced which affects the 3GPP specifications, it is said to be 'backward compatible' if
existing equipment can continue to operate and perform correctly with equipment that conforms to the new
implementation.

9.1 Compatibility with existing standards

Where the service and operational requirements in this document relate to a core network functionality, compatibility
is required.

UTRAN, E-UTRAN, and NG-RAN LCS shall be developed to maximise synergies with earlier LCS phases.

9.2 Compatibility with future releases

It is envisaged that 3GPP standards will evolve in future releases, for example with the addition of new service
requirements. The standards which define the technical implementation of LCS should be developed in such a way
that it is practical to add the requirements in this section in a backward compatible manner.

Following chapters include requirements that are foreseen for future release.

9.2.1 Void

9.2.2 Location determination in call or PDP context activation and release

A possible future enhancement in LCS is that location information of a specific target UE may be obtained at the
activation of a Call or PDP Context. A corresponding mechanism to obtain the location information of a specific
target UE at the release of a Call or PDP Context may also be feasible.

9.2.3 Void

9.2.4 Defined geographical areas

It shall be possible to specify a geographical area as ellipse to a resolution that will be limited by the accuracy
capability of the part of the serving network where the user is registered.

It may be possible to identify and report when the user’s terminal enters or leaves a specified geographic area.

In order to enable ME to determine itself if it enters or leaves a defined geographical area information about the
defined geographical area shall be made available to client. The method is FFS, one alternative is that cells covering
parts of the geographical area broadcasts information about the geographical area.

ETSI
Release 18 34 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

9.2.5 Continuous check of location

The client may continuously check its current location with or without requesting signalling support from the network
using the Self Location feature. In this way the client may become aware of entering or leaving a predefined
geographical area, as defined above, and/ or it can supply the user or an application with real-time tracking
information.

9.2.6 Identification of a target UE

In future releases usage of IP addresses for UE identification shall be supported by the standard.

9.2.7 Void

9.2.8 VHE
LCS shall support VHE 22.121 [6].

ETSI
Release 18 35 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Annex A (informative):
USA FCC Wireless E911 Rules
Action was taken by the FCC on January 29, 2015, with respect to E911 location technology by the Fourth Report
and Order (FCC 15-9).The following revisions to the wireless E911 rules (see [12] and [13] for the specific rules) are
reproduced from the Fourth Report and Order (revisions on compliance, enforcement, testing, test bed, reporting,
submission of plans and reports is not included):

 Location Delivery Latency (Time to First Fix) is set at a maximum of 30 seconds from the time the user
initiates an emergency service call to the time it is available at the location information center.

 Defines the following:

1. Dispatchable location: A location delivered to the PSAP by the network with an emergency service
call that consists of the street address of the calling party, plus additional information such as suite,
apartment or similar information necessary to adequately identify the location of the calling party.
The street address of the calling party must be validated and, to the extent possible, corroborated
against other location information prior to delivery of dispatchable location information by the
PLMN operator to the PSAP.

2. National Emergency Address Database (NEAD): A database that utilizes MAC address information
to identify a dispatchable location for nearby wireless devices within the PLMN operator's coverage
area.

3. Nationwide PLMN operator: a PLMN operator whose service extends to a majority of the
population and land area of the United States.

4. Non-nationwide PLMN operator: Any PLMN operator other than a nationwide PLMN operator.

 Sets the following indoor location accuracy standards for 911 calls:

1. For horizontal location

A. Nationwide PLMN operators shall provide either a dispatchable location or

x/y location within 50 meters for the following percentages of wireless
emergency service calls within the following timeframes from the effective
date of the adoption of these rules

a. Within 2 years: 40% of all wireless emergency service calls

b. Within 3 years: 50% of all wireless emergency service calls

c. Within 5 years: 70% of all wireless emergency service calls

d. Within 6 years: 80% of all wireless emergency service calls

B. Non-nationwide PLMN operators shall provide either a dispatchable location

or x/y location within 50 meters for the following percentages of wireless
emergency service calls within the following timeframes from the effective
date of the adoption of these rules

a. Within 2 years: 40% of all wireless emergency service calls

b. Within 3 years: 50% of all wireless emergency service calls

c. Within 5 years or within 6 months of deploying VoLTE whichever is

later: 70% of all wireless service calls

d. Within 6 years or within one year of deploying VoLTE, whichever is

later: 80% of all wireless emergency service calls

ETSI
Release 18 36 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

2. For vertical location, PLMN operators shall provide vertical location information with
wireless emergency service calls within the following timeframes from the effective date of
the adoption of these rules

A. Within 3 years: All PLMN operators shall make uncompensated

barometric data available to PSAPs with respect to any 911 call placed
from any UE with the capability to deliver barometric sensor information

B. Within 3 years: Nationwide PLMN operators shall develop one or more z-

axis metrics validated by an independently administered and transparent
test bed process and shall submit the proposed metrics and testing results to
the FCC for approval.

C. Within 6 years: In each of the top 25 Cellular Market Areas (CMA),

nationwide PLMN operators shall deploy either dispatchable location or z-
axis technology in compliance with any z-axis accuracy metric that has
been approved by the FCC.

a. In each CMA where dispatchable location is used: nationwide

PLMN operators must ensure that the NEAD is populated with a
sufficient number of total dispatchable location reference points to
equal 25% of the CMA population.

b. In each CMA where z-axis is used: nationwide PLMN operators

must deploy z-axis technology to cover 80% of the CMA
population.

D. Within 8 years: In each of the top 50 CMAs, nationwide PLMN operators

shall deploy either dispatchable location or such z-axis technology in
compliance with any z-axis accuracy metric that has been approved by the
FCC.

E. Non-nationwide PLMN operators that serve any of the top 25 or 50 CMAs

will have an additional year to meet the vertical location benchmarks in C
& D.

 Specifies the delivery of location confidence and uncertainty data

1. PLMN operators shall provide for all wireless emergency service calls, whether
from outdoor or indoor locations, x- and y-axis confidence and uncertainty
information on a per-call basis upon the request of a PSAP. The data shall specify
the caller's location with a uniform confidence level of 90 percent and the radius
in meters from the reported position at the same confidence level. All entities
responsible for transporting confidence and uncertainty between CMRS providers
and PSAPs including PLMN operators, owners of E911 networks and emergency
service providers, must enable the transmission of confidence and uncertainty data
provided by PLMN operators to the requesting PSAP.

2. Upon meeting the 3 year timeframe for the horizontal location standards, PLMN
operators shall provide with emergency service calls that have a dispatchable
location the confidence and uncertainty data for the x- and y- axis required in
these regulations.

3. Upon meeting the 6 year timeframe for the horizontal location standards, PLMN
operators shall provide with wireless emergency service calls that have a
dispatchable location the confidence and uncertainty data for the x- and y- axis
required in these regulations.

 Specifies the live emergency service call data recording requirements

1. PLMN operators must record information on all live emergency calls

including, but not limited to, the positioning source method used to
provide a location fix associated with the call. PLMN operators must also
record the confidence and uncertainty data they provide. This information

ETSI
Release 18 37 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

must be made available to PSAPs upon request, and shall be retained for
a period of two years.

 Defines when the requirements of the location accuracy regulations apply

1. The requirements shall be applicable only to the extent that the

administrator of the applicable designated PSAP has requested
the services required under these regulations and the PSAP is
capable of receiving and utilizing the requested data elements
and has a mechanism for recovering the PSAP's costs associated
with them.

ETSI
Release 18 38 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Annex B (informative):
Descriptions of possible location based services

B1 Public Safety Services

Service providers offer these location-based services for the good of the public. They are made available without
requiring pre-subscription.

B1.1 Emergency Services

Specific consideration of mandated Emergency Services is outside the scope of this specification. Such requirements
may be regionally or nationally specific.

B1.1.1 Attributes
Specific consideration of the attributes for mandated Emergency Services is outside the scope of this specification.
However, the current requirements specified by the U.S. FCC [12] and [13] may be useful as examples.
The FCC's Fourth Report and Order (FCC 15-9) in the matter of Wireless E911 Location Accuracy
Requirements (PS Docket No. 07-114), adopted January 29, 2015, is reproduced here:

All CMRS providers must provide (1) dispatchable location, or (2) x/y location within 50 meters, for the
following percentages of wireless 911 calls within the following timeframes, measured from the effective date
of rules adopted in this Order (“Effective Date”):
 Within 2 years: 40 percent of all wireless 911 calls.
 Within 3 years: 50 percent of all wireless 911 calls.
 Within 5 years: 70 percent of all wireless 911 calls.
 Within 6 years: 80 percent of all wireless 911 calls.
Within 6 years: Nationwide CMRS provides must deploy either (1) dispatchable location, or (2) z-axis
technology that achieves the Commission-approved z-axis metric, in each of the top 25 Cellular Market
Areas
Within 8 years: Nationwide CMRS providers must deploy dispatchable location or z-axis technology in
accordance with the above benchmarks in each of the top 50 CMAs.

Note 1: The Fourth Report and Order definition of a dispatchable location as reproduced here:
Dispatchable location is the street address of the calling party plus additional information such as
floor, suite, apartment or similar information that may be needed to adequately identify the location of
the calling party. See the Report and Order [12] for more information.

The network should be sufficiently flexible to accommodate evolving enabling mechanisms and service requirements
to provide new and improved services.

B1.1.2 Emergency Alert Services

Emergency Alert Services may be enabled to notify wireless subscribers within a specific geographic location of
emergency alerts. This may include such alerts as tornado warnings, pending volcano eruptions, etc.
No requirements currently exist for Emergency Alert Services, and they may be considered for further study.

B2 Location Based Charging

Location Based Charging allows a subscriber to be charged different rates depending on the subscriber's location or
geographic zone, or changes in location or zone. The rates charged may be applicable to the entire duration of the
call, or to only a part of call's duration. This service may be provided on an individual subscriber basis, or on a group
basis.

ETSI
Release 18 39 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

For example, when provided on an individual basis this service could apply reduced rates to those areas most often
frequented by the subscriber by taking into consideration the subscriber's daily route and lifestyle. Different rates may
be applied at country clubs, golf courses, or shopping malls. For example, a "home" zone may be defined which is
centered around a user’s home, an agreed larger area, work or travel corridor or some unrelated zone. The zone may
vary in size and shape from a cell (or sector) coverage area to a precisely defined polygon completely independent of
cell coverage.
Additionally, different rates may be applied in different zones based on the time of day or week.
In addition to being applicable on an individual basis, this service may be applicable on a group basis, which may be
desirable for example, for business groups. Locations may be defined for business groups to include corporate
campuses, work zones or business zones with different tiers of charging rates.
Individual and group subscribers should be notified of the zone or billing rate currently applicable, and be notified
when the rate changes. Location Based Charging may be invoked upon initial registration. A charging zone would
then be associated with the subscriber's location. When the subscriber moves to a different zone, the subscriber would
be notified.
This service should be transparently provided to the subscriber (i.e. independent of existing voice calls, data, or other
services being provided).

B2.1 Attributes
Normal service operation includes invocation upon initial registration, autonomous registration, call origination, and
call termination. Location-Based Charging should analyze location information to compare against service zones
established for the subscriber. The service would notify the subscriber of their relative location to the established
service zone, indicating either "in" or "out" of zone. As the subscriber changes location or predefined location service
area they should be notified of their location-based charging service opportunity, being "in" or "out" of a subscribed
zone. Except for subscriber notification, the user should experience transparency in interaction with other services
(Voice, Data, SMS, etc).

This service may, as an option, be activated/de-activated using special feature codes on a subscriber or business
customer basis.

B2.1.1 Target Subscriber Notification

The user needs to be informed on an ongoing basis which zone and billing rate is currently applicable.
Users should be enabled to make an informed decision on expected call charges and therefore need to be provided
charging zone information accurately, and in a timely manner, being notified which zone they are in when a call is set
up. Notification to the subscriber/user could be provided in several forms including tone, announcement, or short
message.
The billing system will need to consider the following possible scenarios:
1. For the duration of the call, the subscriber remains in a single charging zone

2. During the call, the charging zones may change

2.1. The user may initiate a call in one zone, then move to a different zone where the call is terminated.

2.2. The user may cross back and forth between zones multiple times during the duration of a call, and the call
may terminate in the zone it was originated from, or in a different zone.

Notification to the user may be via the UE MMI prior to initiation of the call and, during the call.

B2.1.2 Charging
To support appropriate charging, call detail records may need to include the following additional information:

1 Location Service (Location Based Charging) Identification

2 Location Information

3 Zone Information

ETSI
Release 18 40 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

4 Type of Event

5 Duration of Event

B2.1.3 Roaming
If a subscriber with active location-based charging roams into a system that does not support the service, the
subscriber may be notified of an "out of coverage zone" notification using the best possible method (UE display,
SMS, etc.).

B3 Tracking Services
Although Fleet and Asset Management services may be offered as separate services, within this document they are
described as a single service category. In a similar manner, Person Tracking may be viewed as a form of personal
asset tracking.

B3.1 Fleet and Asset Management Services

Fleet and Asset Management services allow the tracking of location and status of specific service group users.
Examples may include a supervisor of a delivery service who needs to know the location and status of employees,
parents who need to know where their children are, animal tracking, and tracking of assets.
The service may be invoked by the managing entity, or the entity being managed, depending on the service being
provided.
Fleet Management may enable an enterprise or a public organization to track the location of vehicles (cars, trucks,
etc.) and use location information to optimize services.
Asset management services, for example, may range from asset visualization (general reporting of position) to stolen
vehicle location and geofencing (reporting of location when an asset leaves or enters a defined zone). The range of
attributes for these services is wide.
For Fleet and Asset Management services, a distinction may be made between the manager of the fleet/assets in
charge of tracking, and the entities being tracked (service group users, etc). The tracking service may make use of
mobile station handsets with possible specialized functions (Web browsers, etc) to allow for tracking and specific
methods for communicating with the managing entity. A managing entity would be able to access one or several
managed entities' location and status information through a specified communication interface (Internet, Interactive
Voice Response, Data service, etc). The managing entity would be able to access both real-time and recent location
and status results of managed entities.
The network shall provide the capability to provide the last known location and timestamp. In cases where the service
group user's mobile station is not registered (i.e. Inactive, out of coverage) the last known location information and
timestamp may optionally be provided. If this information is unavailable in real-time, a reason for why the
information is unattainable may be provided. The managing entity may also be able to relay messages to service
group users through the appropriate interface, as well as receive messages originated by the service group users.
Activation of Fleet and Asset Management services could be performed via subscriber provisioning by the service
provider, as well as by offering subscriber-based service activation codes to the service group user/subscriber. The
managing entity could also initiate service via requests to a provisioning system through Interactive Voice Response
or Internet request. A feature code may optionally also be provided to allow for specific mobile user group subscriber
activation by the managing entity (*FC + Mobile ID). A specific user group mobile could also be able to self-activate
through the use of a feature code.

ETSI
Release 18 41 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

B3.2 Traffic Monitoring

Mobiles in automobiles on freeways anonymously sampled to determine average velocity of vehicles. Congestion
detected and reported.
Congestion, average flow rates, vehicle occupancy and related traffic information can be gathered from a variety of
sources including roadside telematic sensors, roadside assistance organizations and ad-hoc reports from individual
drivers. In addition, average link speeds can be computed through anonymous random sampling of UE locations.

B3.2.1 Attributes

B3.2.1.1 Privacy
Anonymous sampling of target UE requires all unique information relating to the UE location to be retained by the
network operator. Depending on the capabilities of the location method (ref. section 3.4) traffic behavior described
above can only be determined if a UE is sampled at least twice within a finite predetermined period.
The UE identification must be sufficiently unique to allow time separated measurements to be paired before
discarding the source UE identification.
The level of uniqueness can be a highly truncated form of the UE-IMSI (or equivalent). For example, maintaining
1000 unattached location estimates for subsequent pairing with future estimates will only require 3 least significant
digits of the IMSI. Ambiguity in matching will occur but at a low (detectable) rate. Finally, all unattached estimates
can be set to expire after a preset time.

B4 Enhanced Call Routing

Enhanced Call Routing (ECR) allows subscriber or user calls to be routed to the closest service client based on the
location of the originating and terminating calls of the user. The user may optionally dial a feature or service code to
invoke the service (*GAS for closest gas station, etc).
In addition to routing the call based on location, ECR should be capable of delivering the location information to the
associated service client. For example, this capability may be needed for services such as Emergency Roadside
Service. This could be used for the purpose of dispatching service agents for ECR service clients that can make use of
this information.
ECR services may be offered, for example, through menu driven access allowing users to interactively select from a
variety of services.

B5 Location-Based Information Services

Location-Based Information services allow subscribers to access information for which the information is filtered and
tailored based on the location of the requesting user. Service requests may be initiated on demand by subscribers, or
automatically when triggering conditions are met, and may be a singular request or result in periodic responses.
The following subsections provide some examples of possible location-based information services.

B5.1 Navigation
The purpose of the navigation application is to guide the handset user to his/her destination. The destination can be
input to the terminal, which gives guidance how to reach the destination. The guidance information can be e.g. plain
text, symbols with text information (e.g. turn + distance) or symbols on the map display. If the handset’s velocity is
available in addition to its position, real-time, adaptable turn-by-turn directions can be provided. The instructions may
also be given verbally to the users by using a voice call.
Note: this may involve a service provider giving verbal directions to a lost motorist or providing periodic
short text messages (possibly using SMS), in addition to, or as an alternative to the provision of a
graphic map.

ETSI
Release 18 42 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

This can be accomplished through carrying a mobile phone that has location technology capabilities down to a few
feet. Less granularity impedes the applicability of this functionality.
This service can either be menu driven from a handset using SIM Application Toolkit or a WAP based terminal with
a map application running – similar to a GPS system. A central server may handle all mapping of locations, and may
save specific locations (i.e., favorite fishing holes).

B5.2 City Sightseeing

City Sightseeing would enable the delivery of location specific information to a sightseer. Such information might
consist of combinations of the services described throughout this document to describe historical sites, providing
navigation directions between sites, facilitate finding the nearest restaurant, bank, airport, bus terminal, restroom
facility, etc.

B5.3 Location Dependent Content Broadcast

The main characteristic of this service category is that the network automatically broadcasts information to terminals
in a certain geographical area. The information may be broadcast to all terminals in a given area, or only to members
of specific group (perhaps only to members of a specific organization). The user may disable the functionality totally
from the terminal or select only the information categories that the user is interested in.
An example of such a service may be localized advertising. For example, merchants could broadcast advertisements
to passersby based on location / demographic / psychographic information (for example "today only, 30% off on blue
jeans").

B5.4 Mobile Yellow Pages

The internet has also changed how people find phone numbers. Instead of thumbing through the yellow pages or
calling Directory assistance you simply go online and search the number. The need for paper copy phonebooks is
gone. Wireless takes this one step further by adding the location of the subscriber to the search. Now the phone
number of the nearest location can be ascertained as opposed to all locations within a 50-mile area.
Mobile Yellow Pages services provide the user with the location of the nearest service point, e.g. Italian restaurant.
The result of the query may be a list of service points fulfilling the criteria (e.g. Italian restaurants within three
kilometers). The information can be provided to the users in text format (e.g. name of the restaurant, address and
telephone number) or in graphical format (map showing the location of the user and the restaurants).

B5.5 Location Sensitive Internet

Location Sensitive Internet is for further study.

B6 Network Enhancing Services

The Network Enhancing Services described in this section are for further study and privacy issues will require further
consideration.

B6.1 Applications for Network Planning

The network operator may be able to use location information to aid network planning. The operator may be able to
locate calls in certain areas to estimate the distribution of calls and user mobility for network planning purposes.
These applications may be used for hot spot detection and user behavior modeling

B6.2 Applications for Network QoS Improvements

The network operator may be able to use location services to improve the Quality of Service of the network. The
location system may be used to track dropped calls to identify problematic areas. The system may also be used to
identify poor quality areas.

ETSI
Release 18 43 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

B6.3 Improved Radio Resource Management

The location of the handset may be used for more intelligent handovers and more efficient channel allocation
techniques.

ETSI
Release 18 44 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Annex C (Informative):
Attributes of Specific Services
The following table (provided by the GSM Alliance Services Working Group) depicts ranges of values that may be expected for various attributes of location based services.

Requirement -> Service Privacy Target Horizontal Vertic Respo Reliab Securi Period Servic Servic Servic Servic Roami Servic Intera
Authoriza Subscri Accuracy al nse ility ty ic e e e De- e ng e ctions
tion ber Accur Time Locati Regist Activa Activa Invoc Specif With
Notific acy on ration tion tion ation ic Other
ation Repor Consi Wirele
ting derati ss
Service ons Servic
Category es

Public Safety Services

Emergency None Implied Not Network n/a 5 sec. Same Same Requi None None Not Keystr Requi Lat
Services req’d when require now as as red req’d requir Allow oke or red if and
dialing d
based: GSM GSM Period ed ed Dialed emerg Long.
911 info (5- TBD string ency To
provided 100m 15m sugge (911) call PSAP
to safety (67%) future st 1- can be
organiza ? 10 made
tions minut
300m es
(95%)

Handset
based:

50m
(67%)

150m
(95%)

ETSI
Release 18 45 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)
Requirement -> Service Privacy Target Horizontal Vertic Respo Reliab Securi Period Servic Servic Servic Servic Roami Servic Intera
Authoriza Subscri Accuracy al nse ility ty ic e e e De- e ng e ctions
tion ber Accur Time Locati Regist Activa Activa Invoc Specif With
Notific acy on ration tion tion ation ic Other
ation Repor Consi Wirele
ting derati ss
Service ons Servic
Category es

Emergency Req’d Info Not 125 m n/a 5 sec. Same Same Requi Req’d By By Auto Prefer Lat &
Alert Services only require now as as red menu, menu, matic red Long
passed d (10 m GSM GSM Period keystr keystr where to
to future?) (5- TBD oke, oke, roami Servic
subscrib 15m sugge intera intera ng is e
ed to future st 1- ctive ctive allowe Provid
service ? 10 or live or live d er
provider minut operat operat
es or or Live,
SMS
or
other
data
servic
e
(WAP
,GPRS
)
return
msg.

Location Sensitive Charging

Home-Zone Req’d Info Not Depends n/a Depen Same Same Requi Req’d Intera Intera Auto n/a Lat &
Billing only require on billing ds on as as red ctive ctive matic Long
passed d zone (5m- incre GSM GSM depen with with to
to 300m) ments ds on Carrie Carrie Carrie
subscrib of billing r r r
ed to billing incre
carrier . ment
and
covera
ge
zone

ETSI
Release 18 46 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)
Requirement -> Service Privacy Target Horizontal Vertic Respo Reliab Securi Period Servic Servic Servic Servic Roami Servic Intera
Authoriza Subscri Accuracy al nse ility ty ic e e e De- e ng e ctions
tion ber Accur Time Locati Regist Activa Activa Invoc Specif With
Notific acy on ration tion tion ation ic Other
ation Repor Consi Wirele
ting derati ss
Service ons Servic
Category es

Tracking Services

Fleet Mgment. Req’d Info Not 125m-Cell n/a 5 sec. Same Same Requi Req’d Intera Intera Intera Prefer Lat &
only require ID as as red (1- ctive ctive ctive red Long
passed d GSM GSM 10 or live or live or live where to
to minut operat operat operat roami Servic
subscrib es) or or or ng is e
ed to allowe Provid
service d er
provider
To
reques
ting
custo
mer’s
interfa
ce (e-
mail,
Web
or live
operat
or

Asset Mgment Req’d Info Not 10m-125m n/a 5 sec. Same Same Requi Req’d Intera Intera Intera Prefer Specia Lat &
only require as as red (1- ctive ctive ctive red l Long
passed d (5- GSM GSM 10 or live or live or live where Termi to
to 15m minut operat operat operat roami nal Servic
subscrib future es) or or or ng is e
ed to ? allowe Provid
service d er
provider
To
reques
ting
custo
mer’s
interfa
ce (e-
mail,
Web
or live
operat
or

ETSI
Release 18 47 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)
Requirement -> Service Privacy Target Horizontal Vertic Respo Reliab Securi Period Servic Servic Servic Servic Roami Servic Intera
Authoriza Subscri Accuracy al nse ility ty ic e e e De- e ng e ctions
tion ber Accur Time Locati Regist Activa Activa Invoc Specif With
Notific acy on ration tion tion ation ic Other
ation Repor Consi Wirele
ting derati ss
Service ons Servic
Category es

Person Req’d Info May be 10m-125m n/a 5 sec. Same Same Requi Req’d Intera Intera Intera Prefer Lat &
Tracking only require as as red (1- ctive ctive ctive red Long
passed d (5- GSM GSM 10 or live or live or live where to
to 15m minut operat operat operat roami Servic
subscrib (Child future es) or or or ng is e
ed to versus ? allowe Provid
service Emplo d er
provider yee?)
To
reques
ting
custo
mer’s
interfa
ce (e-
mail,
Web
or live
operat
or

Pet Tracking Req’d Info Not 10m-125m n/a 5 sec. Same Same Requi Req’d Intera Intera Intera Prefer Specia Lat &
only require as as red (1- ctive ctive ctive red l Long
passed d (5- GSM GSM 10 or live or live or live where Termi to
to 15m minut operat operat operat roami nal Servic
subscrib future es) or or or ng is e
ed to ? allowe Provid
service d er
provider
To
reques
ting
custo
mer’s
interfa
ce (e-
mail,
Web
or live
operat
or

Traffic Monitoring

ETSI
Release 18 48 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)
Requirement -> Service Privacy Target Horizontal Vertic Respo Reliab Securi Period Servic Servic Servic Servic Roami Servic Intera
Authoriza Subscri Accuracy al nse ility ty ic e e e De- e ng e ctions
tion ber Accur Time Locati Regist Activa Activa Invoc Specif With
Notific acy on ration tion tion ation ic Other
ation Repor Consi Wirele
ting derati ss
Service ons Servic
Category es

Traffic Req’d No Not 10-40m May 5 sec. Same Same Requi Req’d By By By Prefer High Lat &
Congestion specific require Hi- res. be as as red (1- menu, menu, menu, red bandw Long
Reporting Target d req’d muti- req’d GSM GSM 2 keystr keystr keystr where idth to
UE info near for minut oke, oke, oke, roami req on Servic
allowed proximity over- es) intera intera intera ng is netwo e
lanes passes ctive ctive ctive allowe rk. Provid
or live or live or live d er
(opposing operat operat operat
and or or or Live
adjacent) or
SMS
return
msg.

Enhanced Call Routing

Routing to Req’d Info Not 10m-125m n/a 5 sec. Same Same Not Req’d By By By Prefer Lat &
Nearest only require as as requir menu, menu, menu, red Long
Commercial passed d GSM GSM ed keystr keystr keystr where to
Enterprise to oke, oke, oke, roami Servic
subscrib intera intera intera ng is e
ed to ctive ctive ctive allowe Provid
service or live or live or live d er
provider operat operat operat
or or or

Roadside Req’d Info Not 10m-125m n/a 5 sec. Same Same Not Req’d By By By Prefer Lat &
Assistance only require as as requir menu, menu, menu, red Long
passed d GSM GSM ed keystr keystr keystr where to
to oke, oke, oke, roami Servic
subscrib intera intera intera ng is e
ed to ctive ctive ctive allowe Provid
service or live or live or live d er
provider operat operat operat
or or or Live
or
SMS
return
msg.

ETSI
Release 18 49 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)
Requirement -> Service Privacy Target Horizontal Vertic Respo Reliab Securi Period Servic Servic Servic Servic Roami Servic Intera
Authoriza Subscri Accuracy al nse ility ty ic e e e De- e ng e ctions
tion ber Accur Time Locati Regist Activa Activa Invoc Specif With
Notific acy on ration tion tion ation ic Other
ation Repor Consi Wirele
ting derati ss
Service ons Servic
Category es

Location Based Information Services

Navigation Req’d Info Requir 10m-125m n/a 5 sec. Same Same Requi Req’d By By By Prefer Lat &
only ed as as red (1- menu, menu, menu, red Long
passed GSM GSM 10 keystr keystr keystr where to
to minut oke, oke, oke, roami Servic
subscrib es) intera intera intera ng is e
ed to ctive ctive ctive allowe Provid
service or live or live or live d er
provider operat operat operat
or or or Live,
SMS
or
other
data
servic
e
(WAP
,GPRS
)
return
msg.

City Req’d Info Not 10m-125m n/a 5 sec. Same Same Not Req’d By By By Prefer Lat &
Sightseeing only require as as requir menu, menu, menu, red Long
passed d GSM GSM ed keystr keystr keystr where to
to oke, oke, oke, roami Servic
subscrib intera intera intera ng is e
ed to ctive ctive ctive allowe Provid
service or live or live or live d er
provider operat operat operat
or or or Live,
SMS
or
other
data
servic
e
(WAP
,GPRS
)
return
msg.

ETSI
Release 18 50 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)
Requirement -> Service Privacy Target Horizontal Vertic Respo Reliab Securi Period Servic Servic Servic Servic Roami Servic Intera
Authoriza Subscri Accuracy al nse ility ty ic e e e De- e ng e ctions
tion ber Accur Time Locati Regist Activa Activa Invoc Specif With
Notific acy on ration tion tion ation ic Other
ation Repor Consi Wirele
ting derati ss
Service ons Servic
Category es

Localized Req’d Info Not 125m-Cell n/a Not Same Same Not Req’d By By By Prefer Lat &
Advertising only require ID sensiti as as requir menu, menu, menu, red Long
passed d ve GSM GSM ed keystr keystr keystr where to
to (defau oke, oke, oke, roami Servic
subscrib lt to 5 intera intera intera ng is e
ed to sec.) ctive ctive ctive allowe Provid
service or live or live or live d er
provider operat operat operat
or or or SMS
return
msg.

Mobile Yellow Req’d Info Not 125m-Cell n/a 5 sec. Same Same Not Req’d By By By Prefer Lat &
Pages only require ID as as requir menu, menu, menu, red Long
passed d GSM GSM ed keystr keystr keystr where to
to oke, oke, oke, roami Servic
subscrib intera intera intera ng is e
ed to ctive ctive ctive allowe Provid
service or live or live or live d er
provider operat operat operat
or or or Live,
SMS
or
other
data
servic
e
(WAP
,GPRS
)
return
msg.

Service Provider Specific Services

Network Not Specific Not 10m-Cell n/a 5 sec. Same Same Requi Not N/a n/a n/a n/a n/a
Planning Req’d Target Requir ID as as red (1 Req’d
UE info ed GSM GSM minut
allowed e)

ETSI
Release 18 51 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)
Requirement -> Service Privacy Target Horizontal Vertic Respo Reliab Securi Period Servic Servic Servic Servic Roami Servic Intera
Authoriza Subscri Accuracy al nse ility ty ic e e e De- e ng e ctions
tion ber Accur Time Locati Regist Activa Activa Invoc Specif With
Notific acy on ration tion tion ation ic Other
ation Repor Consi Wirele
ting derati ss
Service ons Servic
Category es

Dynamic Not Specific Not 10m-Cell n/a 5 sec. Same Same Requi Not N/a n/a n/a n/a n/a
Network Req’d Target Requir ID as as red (1 Req’d
Control UE info ed GSM GSM minut
allowed e)

ETSI
Release 18 52 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

Annex D (informative):
Change history

Change history
TSG SA# SA Doc. SA1 Doc Spec CR Rev Rel Cat Subject/Comment Old New WI
Jun 1999 GSM Transferred to 3GPP SA1 7.0.0
02.71
SP-04 22.071 3.0.0
SP-05 SP-99486 S1-99831 22.071 0001 1 R99 C UMTS LCS service requirements 3.0.0 3.1.0
support for mobile originated
positioning requests, and velocity
as a service parameter
SP-05 SP-99438 S1-99832 22.071 0002 R99 B UMTS LCS service requirements 3.0.0 3.1.0
SP-05 SP-99438 S1-99833 22.071 0003 R99 C LCS accuracy requirements 3.0.0 3.1.0
SP-05 SP-99479 S1-99625 22.071 0004 R99 D Editorial changes for alignment 3.0.0 3.1.0
SP-06 SP-99522 S1-99955 22.071 0005 R99 D U.S. specific Emergency 3.1.0 3.2.0
Services requirements included
as an informative annex.
SP-08 SP-000212 S1-000338 22.071 0006 R00 C Incorporation of TSG SA1#8 LCS 3.2.0 4.0.0
Contributions and email
contributions
SP-09 SP-000378 S1-000484 22.071 0008 R4 F Correction to LCS Service 4.0.0 4.1.0
Description Stage 1 Document
(R’00)
SP-09 SP-000392 S1-000667 22.071 0009 R4 C Provision of Velocity for Location 4.0.0 4.1.0
Services
SP-09 SP-000392 S1-000670 22.071 0010 R4 B External LCS client identity 4.0.0 4.1.0
SP-09 SP-000392 S1-000671 22.071 0011 R4 B Privacy Control for LCS 4.0.0 4.1.0
SP-09 SP-000392 S1-000672 22.071 0012 R4 F Privacy Control for LCS 4.0.0 4.1.0
SP-09 SP-000392 S1-000673 22.071 0013 R4 D Clarifications to LCS on privacy 4.0.0 4.1.0
and Service response
SP-09 SP-000392 S1-000674 22.071 0014 R4 F LCS: Geographic Location 4.0.0 4.1.0
SP-09 SP-000392 S1-000675 22.071 0015 R4 D Adding statement on “active” and 4.0.0 4.1.0
“idle” UE in chapter 4.13
SP-09 SP-000392 S1-000676 22.071 0016 R4 D Radio Access Network support 4.0.0 4.1.0
for LCS
SP-09 SP-000392 S1-000677 22.071 0017 R4 D LCS, Identification of a Target UE 4.0.0 4.1.0
using IP addresses
SP-09 SP-000392 S1-000678 22.071 0018 R4 D LCS: LCS Open Service 4.0.0 4.1.0
Architecture (OSA) and
Application Programming
Interface.
SP-10 SP-000544 S1-000787 22.071 0019 Rel-4 B Privacy Exception List 4.1.0 4.2.0 LCS
SP-10 SP-000544 S1-000788 22.071 0020 Rel-4 B Periodic Location Reporting 4.1.0 4.2.0 LCS
SP-10 SP-000544 S1-000791 22.071 0021 Rel-4 B Location Service Request 4.1.0 4.2.0 LCS
SP-10 SP-000544 S1-000851 22.071 0022 Rel-4 C Periodic Location Reporting 4.1.0 4.2.0 LCS1
amendment
SP-10 SP-000544 S1-000803 22.071 0023 Rel-4 C Addition of achieved location 4.1.0 4.2.0 LCS1
information accuracy with
reference to TS 23.032
SP-11 SP-010044 S1-010235 22.071 0024 Rel-4 C Quality level negation 4.2.0 4.3.0 LCS1
SP-11 SP-010044 S1-010239 22.071 0025 Rel-4 C Location determination in call or 4.2.0 4.3.0 LCS1-PS
PDP context activation and
release
SP-11 SP-010044 S1-010237 22.071 0026 Rel-4 C OSA support for LCS 4.2.0 4.3.0 LCS1
SP-11 SP-010044 S1-010218 22.071 0027 Rel-4 D Editorial Cleanup 4.2.0 4.3.0 LCS1
SP-11 SP-010044 S1-010269 22.071 0028 Rel-4 C Number of LCS Clients 4.2.0 4.3.0 LCS1
SP-14 SP-010673 S1-011285 22.071 0029 Rel-5 C Privacy Override Indicator 4.3.0 5.0.0 LCS1
SP-15 SP-020047 S1-020467 22.071 0030 Rel-5 B CR 22.071 Rel.5 B Requestor 5.0.0 5.1.0 LCS1

ETSI
Release 18 53 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

SP-15 SP-020047 S1-020478 22.071 0031 Rel-5 B CR 22.071 Rel.5 B Introducing 5.0.0 5.1.0 LCS1
service type privacy for location
services
SP-15 SP-020047 S1-020479 22.071 0032 Rel-5 C Introduction of a Codeword 5.0.0 5.1.0 LCS1
Setting
SP-15 SP-020047 S1-020632 22.071 0033 Rel-5 B CR to 22.071 on Clarifying 5.0.0 5.1.0 LCS1
checking of requester ID
SP-15 SP-020043 S1-020455 22.071 0036 Rel-5 A CR 22.071 Rel-5 A Closure of a 5.0.0 5.1.0 TEI
loophole in the privacy settings
SP-15 SP-020047 S1-020466 22.071 0037 Rel-5 B CR 22.071 Rel.5 B Deferred 5.0.0 5.1.0 LCS1
Location Request with Change of
Area Event
SP-15 SP-020045 S1-020457 22.071 0039 - Rel-5 A Editorial CR to correct terms and 5.0.0 5.1.0 CORRECT
references
22.071 - - Rel-5 Editorial to change page layout 5.1.0 5.1.1
for Annex C
SP-16 SP-020254 S1-020864 22.071 0040 Rel-6 C CR to TS 22.071 Rel-6 Privacy 5.1.1 6.0.0 LCS1
control in HPLMN
SP-16 SP-020254 S1-020922 22.071 0041 Rel-6 C Enhancement of Codeword 5.1.1 6.0.0 LCS1
Requirements for LCS
SP-17 SP-020556 S1-021662 22.071 0042 Rel-6 D CR to 22.071: Too big file size 6.0.0 6.1.0 LCS1
SP-17 SP-020556 S1-021794 22.071 0043 Rel-6 B CR to 22.071 on LCS 6.0.0 6.1.0 LCS1
Anonymous requestor and
anonymous target mobile (REL6)
SP-17 SP-020556 S1-021490 22.071 0044 Rel-6 B CR to 22.071 on LCS Codeword 6.0.0 6.1.0 LCS1
improvements (REL6)
SP-17 SP-020556 S1-021491 22.071 0045 Rel-6 B LCS extended user privacy 6.0.0 6.1.0 LCS1
SP-17 SP-020556 S1-021799 22.071 0046 Rel-6 C Update to 22.071 for regional 6.0.0 6.1.0 LCS
specific location accuracy
requirements
SP-18 SP-020657 S1-022013 22.071 0047 Rel-6 C CR to LCS stage 1 'Service 6.1.0 6.2.0 LCS2
Type'
SP-18 SP-020657 S1-022299 22.071 0048 Rel-6 C Handling of privacy checks for 6.1.0 6.2.0 LCS2
Network Induced Location
Requests
SP-19 SP-030020 S1-030277 22.071 0049 - Rel-6 B Applicability of barring capability 6.2.0 6.3.0 LCS2
to the Location Service
SP-20 SP-030252 S1-030526 22.071 0050 - Rel-6 B Introduction of codeword 6.3.0 6.4.0 LCS
generation by network or UE
SP-20 SP-030252 S1-030392 22.071 0051 - Rel-6 B LCS in IMS 6.3.0 6.4.0 LCS
SP-20 SP-030252 S1-030557 22.071 0052 Rel-6 F Clarification of requirement 6.3.0 6.4.0 LCS
regarding ‘Query, Cancel of
activated location requests for
the Target UE’
SP-20 SP-030322 S1-030650 22.071 0053 Rel-6 B Routing of Emergency Calls 6.3.0 6.4.0 LCS2
based on Geographic
Coordinates
SP-21 SP-030455 S1-030945 22.071 0056 - Rel-6 A Correction of requirements on the 6.4.0 6.5.0 TEI
identity format of LCS clients
SP-21 SP-030459 S1-030946 22.071 0057 - Rel-6 C Clarification of Mobile Originating 6.4.0 6.5.0 TEI6
Location
SP-21 SP-030459 S1-030947 22.071 0058 - Rel-6 B A requirement of authentication 6.4.0 6.5.0 LCS
to the Target UE user
SP-21 SP-030459 S1-030948 22.071 0059 - Rel-6 B Introduction of LCS QoS Classes 6.4.0 6.5.0 LCS2
SP-22 SP-030690 S1-031328 22.071 0062 - Rel-6 A Removal of misleading and 6.5.0 6.6.0 LCS1
obsolete text
SP-22 SP-030697 S1-031272 22.071 0063 - Rel-6 F Correction of "velocity" 6.5.0 6.6.0 LCS1
requirements
SP-22 SP-030697 S1-031329 22.071 0064 - Rel-6 B Cell ID 6.5.0 6.6.0 LCS
SP-23 SP-040090 S1-040199 22.071 0069 - Rel-6 F Inclusion of U-TDOA positioning 6.6.0 6.7.0 LCS
method
SP-24 SP-040300 S1-040514 22.071 0070 - Rel-7 C Accuracy of information 6.7.0 7.0.0 LCS2;
Indication of capability EMC1
SP-26 SP-040907 22.071 0072 1 Rel-7 C Velocity Service Description 7.0.0 7.1.0 LCS-R7
SP-28 SP-050221 S1-050531 22.071 0073 - Rel-7 C Introducing notification based on 7.1.0 7.2.0 LCS3
current location of target UE
SP-29 SP-050584 - 22.071 0071 1 Rel-7 C Introducing A-GNSS concept to 7.2.0 7.3.0 A-GNSS
extend A-GPS to include
GALILEO
SP-30 SP-050749 S1-051127 22.071 0074 2 Rel-7 B Identification of the UE based on 7.3.0 7.4.0 LCS3
the IMEI
SP-38 SP-070855 S1-071669 22.071 0075 1 Rel-8 C E-UTRAN support for location 7.4.0 8.0.0 AIPN-SAE
services

ETSI
Release 18 54 ETSI 3GPP TS 22.071 V18.0.1 (2024-03)

SP-42 SP-080775 S1-083376 22.071 0077 2 Rel-8 C Support for Additional Navigation 8.0.0 8.1.0 TEI8
Satellite Systems (ANSS) for
LCS
SP-46 - - - - - - - Updated to Rel-9 by MCC 8.1.0 9.0.0
Removal of references to 3GPP
SP-49 SP-100575 S1-102049 22.071 0079 - Rel-9 D OSA 9.0.0 9.1.0 TEI9
2011-03 - - - - - - - Update to Rel-10 version (MCC) 9.1.0 10.0.0
2012-09 - - - - - - - Updated to Rel-11 by MCC 10.0.0 11.0.0
2014-10 - - - - - - - Update to Rel-12 version (MCC) 11.0.0 12.0.0
Update to Rel-13 version (MCC)
because of the creation of Rel-14
2015-06 - -- - - - - - (see SP-150271) 12.0.0 13.0.0
SP-68 SP-150271 S1-151488 22.071 80 2 Rel-14 C Addition of Z-axis requirements 12.0.0 14.0.0 ELIOT
for emergency calls
SP-68 SP-150271 S1-151454 22.071 81 1 Rel-14 C Revise Annex A to reflect new 12.0.0 14.0.0 ELIOT
FCC Emergency Service
Location Accuracy Regulations
SP-69 SP-150538 S1-152739 22.071 82 2 Rel-14 B Addition of civic location reporting 14.0.0 14.1.0 ELIOT
for Emergency Services
2018-06 - - - - - - - Update to Rel-15 version (MCC) 14.1.0 15.0.0
2020-03 SP-200121 S1-201075 22.071 0083 1 Rel-15 F Add “NG-RAN” to the Location 15.0.0 15.1.0 TEI15
Service stage 1
SA#88e - - - - - - - Update to Rel-16 version (MCC) 15.1.0 16.0.0
2022-03 - - - - - - - Updated to Rel-17 by MCC 16.0.0 17.0.0
2024-03 - - - - - - - Updated to Rel-18 by MCC (and 17.0.0 18.0.1
issue with v.18.0.0 upload)

ETSI