4 Main concepts

23.2713GPPFunctional stage 2 description of Location Services (LCS)Release 17TS

A general description of location services and service requirements are given in the specification TS 22.071 [4]. The positioning of the UE is a service provided by the Access Network. In particular, all Access Networks (e.g. UTRAN, GERAN, E-UTRAN), that facilitate determination of the locations of User Equipments, shall be able to exchange location information with the core network as defined in the present document (when connected to a Core Network). Optionally, location information may also be communicated between GMLCs, located in the same or a different PLMN, via the specified GMLC to GMLC interface.

By making use of the radio signals the capability to determine the (geographic) location of the user equipment (UE) or mobile station (UE) shall be provided. The location information may be requested by and reported to a client (application) associated with the UE, or by a client within or attached to the Core Network. The location information may also be utilised internally in the system; for example, for location assisted handover or to support other features such as home location billing. The location information request may ask for the velocity of the UE as part of the positioning information. The position information shall be reported in standard, i.e. geographical co-ordinates, together with the time-of-day and the estimated errors (uncertainty) of the location of the UE according to specification TS 23.032 [11]. The velocity of the UE may be optionally returned in a format specified in TS 23.032 [11].

It shall be possible for the majority of the UE (active or idle) within a network to use the feature without compromising the radio transmission or signalling capabilities of the GSM/UMTS/EPS networks.

The UE and the network may support a number of different positioning methods and the UE may support or not support privacy invocation request and response. The UE informs the core network and radio access network about its LCS capabilities in this respect as defined in TS 24.008 [24] and TS 25.331 [25].

The uncertainty of the location measurement shall be network design (implementation) dependent at the choice of the network operator, this is further described in TS 25.305 [1], TS 36.305 [42], and TS 43.059 [16].

There are many different possible uses for the location information. The positioning feature may be used internally by the GSM/UMTS/EPS network (or attached networks), by value-added network services, by the UE itself or through the network, and by "third party" services. The positioning feature may also be used by an emergency service (which may be mandated or "value-added"), but the position service is not exclusively for emergencies.

There are regulatory requirements to support anonymity in location services in some countries.

4.1 Assumptions

As a basis for the further development work on LCS in GSM, UMTS and EPS the following assumptions apply:

– positioning methods are Access Network specific, although commonalties should be encouraged between Access Networks;

– commercial location services are only applicable for an UE with a valid SIM or USIM;

– the provision of the location services in the Access Network is optional through support of the specified method(s);

– the provision of location services is optional in MSC, SGSN and MME;

– 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 shall be applicable for both circuit switched and packet switched services;

– the location information may be used for internal system operations to improve system performance;

– it shall be possible to accommodate future techniques of measurement and processing to take advantage of advancing technology so as to meet new service requirements;

– it may be necessary to support LCS signalling between separate access networks via the core network. For UMTS, the Iur interface should be used if available;

– Provide positioning procedures through the circuit-switched domain are also applicable to GPRS UEs which are GPRS and IMSI attached;

– it shall be possible for more than one LCS Client to request and obtain the location of the same target UE at the same time.

4.2 Location Services Categories

Generally there are four categories of usage of the location service. These are the Commercial LCS, the Internal LCS, the Emergency LCS and the Lawful Intercept LCS. The definition of these services and their categories is outside the scope of the present document.

– The Commercial LCS (or Value Added Services) will typically be associated with an application that provides a value-added service to the subscriber of the service, through knowledge of the UE location (and optionally, velocity) and if available, and at the operator’s discretion, the positioning method used to obtain the location estimate. This may be, for example, a directory of restaurants in the local area of the UE, together with directions for reaching them from the current UE location.

– The Internal LCS will typically be developed to make use of the location information of the UE for Access Network internal operations. This may include; for example, location assisted handover and traffic and coverage measurement. This may also include support certain O&M related tasks, supplementary services, IN related services and GSM bearer services and teleservices.

– The Emergency LCS will typically be part of a service provided to assist subscribers who place emergency calls. In this service, the location of the UE caller and, if available, the positioning method used to obtain the location estimate is provided to the emergency service provider to assist them in their response. This service may be mandatory in some jurisdictions. In the United States, for example, this service is mandated for all mobile voice subscribers.

– The Lawful Intercept LCS will use the location information to support various legally required or sanctioned services.

4.3 Positioning methods

The LCS feature utilises one or more positioning methods in order to determine the location of user equipment (UE). Determining the position of a UE involves two main steps:

– Radio signal measurements; and

– Position estimate computation based on the measurements.

The positioning methods for UTRAN are further described in TS 25.305 [1].

4.3.1 Standard LCS Methods in UTRAN

The specification TS 25.305 [1] UTRAN Stage 2 specifies the locating methods to be supported:

– cell coverage based positioning method;

– OTDOA positioning method;

– A-GNSS based positioning methods;

– UTDOA positioning method;

– Barometric pressure sensor method;

– WLAN method;

– Bluetooth method;

– Terrestrial Beacon System method.

For more details on these positioning methods, refer to TS 25.305 [1].

4.3.2 Standard LCS Methods in GERAN

The specification TS 43.059 [16] GERAN LCS Stage 2 specifies the locating methods to be supported in GERAN:

– cell coverage based positioning method;

– Enhanced Observed Time Difference (E-OTD) positioning method;

– A-GNSS based positioning methods;

– Uplink Time Difference of Arrival (UTDOA) positioning method.

4.3.3 Standard LCS Methods in E-UTRAN

Locating methods specified in TS 36.305 [42] applicable to E-UTRAN comprise:

– uplink and downlink cell coverage based positioning methods;

– OTDOA positioning method;

– A-GNSS based positioning methods;

– UTDOA positioning method;

– Barometric pressure sensor method;

– WLAN method;

– Bluetooth method;

– Terrestrial Beacon System methods.

Hybrid positioning using multiple methods from the list of positioning methods above is also supported.

In case of the Home eNodeB, applicable locating methods may be restricted, e.g. when a Home eNodeB is connected via Home eNodeB GW.

4.4 Types of Location Request

4.4.1 Immediate Location Request

Request for location where the LCS Server replies immediately to the LCS Client with the current location estimate if this could be obtained.

4.4.2 Deferred Location Request

Request for location contingent on some current or future events where the response from the LCS Server to the LCS Client may occur some time after the request was sent.

4.4.2.1 Types of event

a) UE available: Any event in which the MSC/SGSN/MME 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 user, temporarily loss of radio connectivity or IMSI detach and so on. Note that IMSI detach is only applicable in the case the UE has previously been registered and information is still kept in the node. The UE Available event only requires one response and after this response, the UE Available event is concluded.

b) Change of Area: An event where the UE enters or leaves a pre-defined geographical area or if the UE is currently within the pre-defined geographical area. Only one type of area event may be defined (i.e. entering, leaving or remaining within the area). The LCS client defines the target area as a geographical area, as an E.164 country code for a geographic area [35a], as a PLMN identity or as a geopolitical name of the area. The LCS server may translate and define the target area as the identities of one or more radio cells, location areas, routing areas, tracking areas, country code or PLMN identity. The target UE must not give the target UE user access to the area definitions and network identities. The change of area event may be reported one time only, or several times. The area event report must not be repeated more often than allowed by the LCS client. The change of area event report shall contain an indication of the event occurrence. The location estimate may be included in the report. If an area event is detected by the UE but an event report cannot be sent (e.g. because the UE cannot access the network or due to a minimum reporting interval), a report shall be sent later when possible irrespective of whether the area event still applies for the current UE location. For E-UTRAN access, area event reporting is controlled by a minimum and a maximum reporting time. The minimum reporting time defines the minimum allowed time between successive area events. The maximum reporting time defines the maximum time between successive reports. When a UE sends a report due to expiration of the maximum reporting time, the UE indicates expiration of the maximum reporting time as the trigger event. The maximum reporting time enables the LCS client, R-GMLC and H-GMLC to remain aware of continuing support by the UE for the area event (e.g. to detect if area event reporting may have been aborted due to UE power off).

c) Periodic Location: An event where a defined periodic timer expires in the UE and activates a location report or a location request. If a periodic event is detected by the UE but an event report cannot be sent (e.g. because the UE cannot access the network temporarily), a report shall be sent later when possible and the periodic timer for the next event shall then be started. The reporting duration for periodic location shall equal the requested number of reports multiplied by the periodic interval even when reports are delayed.

d) Motion: An event where the UE moves by more than some predefined linear distance from a previous location. The motion event may be reported one time only, or several times. The motion event report shall contain an indication of the event occurrence. A location estimate may be included in the report if requested by the LCS client. For successive motion event reports, motion is determined relative to the UE location corresponding to the immediately preceding event report (including an event report triggered by expiration of the maximum reporting time). If a motion event is detected by the UE but an event report is deferred (e.g. because the UE cannot access the network temporarily), a report shall be sent later when possible irrespective of whether the motion event still applies to the current UE location. Motion reporting is controlled by a minimum and a maximum reporting time. The minimum reporting time defines the minimum allowed time between successive event reports. The maximum reporting time defines the maximum time between successive reports. When a UE sends a report due to expiration of the maximum reporting time, the UE indicates expiration of the maximum reporting time as the trigger event. The maximum reporting time enables the LCS client, R-GMLC and H-GMLC to remain aware of continuing support by the UE for the motion event (e.g. to detect if motion event reporting may have been aborted due to UE power off).

e) Other events are FFS.

4.5 Concurrent Location Requests

The LCS Server is enabled to support concurrent location requests for the same target UE. The following principles apply.

1. Under certain conditions, an entity may combine concurrent location requests by fully executing one request and using the ensuing location estimate result(s) to satisfy the other request(s) without fully executing the latter and as allowed by QoS requirements. The allowed conditions for each type of entity are defined below:

a) An R‑GMLC may combine concurrent MT‑LR requests for the same target UE‑LCS Client pair.

b) An H‑GMLC may combine concurrent MT‑LR requests for the same target UE if privacy requirements can be fully resolved by the H‑GMLC (e.g. no notification or verification needed for the UE for any MT‑LR that will not be fully executed).

c) A V‑GMLC may combine concurrent MT‑LR and NI‑LR related location requests for the same target UE provided it is clear and unambiguous for any MT‑LR that will not be fully executed (e.g. from the contents of any MAP Provide Subscriber Location request received from the H‑GMLC) that no outstanding privacy related actions are required for the UE (e.g. no privacy notification and/or privacy verification interaction with the UE and no privacy subscription verification in the VLR, SGSN or MME).

d) An MSC, MSC server, SGSN or MME may combine concurrent MT‑LR, MO‑LR and NI‑LR location requests once any needed privacy related actions (e.g. UE notification and verification) have been performed for each MT‑LR.

e) A UE may combine concurrent MO‑LR requests for LCS Clients internal to or associated with the UE.

2. Except under the conditions permitted in (1), different concurrent location requests shall be treated separately and shall not be visibly combined or made dependent on one another by any entity within the LCS Server. This means that the procedures defined here in clause 9 continue to apply to each separate location request and do not visibly impact one another.

3. Implementation limitations are allowed whereby an entity that, either itself or in association with another entity, cannot support concurrent location requests or more than a certain number of concurrent location requests is allowed to reject or defer a new concurrent request or cancel one or more existing requests. When concurrent location requests are supported, each entity needs to ensure it correlates each location/position response with the associated request.

4. In support of principles 1, 2 and 3, an entity (e.g. GMLC, MSC, MSC server, SGSN, MME, UE) that receives a new location request (e.g. MT‑LR, MO‑LR, NI‑LR) while already supporting previous location requests for the same target UE may reject the new location request, defer (i.e. queue) the new request, cancel one or more previous requests (where a procedure for cancellation has been defined), allow the new location request to proceed concurrently with and separately from the previous requests if allowed on applicable interfaces or, for the specific cases defined in principle 1, combine the new request with one or more previous requests if this will not impair or affect service support for the new request (e.g. privacy and QoS).

5. In support of principle 4, LCS Client priority and any other relevant priority information (e.g. UE subscription preferences) should be considered. In particular, location requests associated with emergency services or lawful interception clients should be given priority over other location requests.