Content for TS 23.271 Word version: 17.0.0

1… 5… 6… 6.2… 7… 8… 9… 9.1.1A… 9.1.2… 9.1.5… 9.1.6… 9.1.8… 9.1.9… 9.1.12… 9.1.13… 9.1.15… 9.1.19… 9.2… 9.2.2… 9.2.3… 9.3… 9.4… 9.5… 9.6… 10… 11… A… B… E F…

5.1 LCS access interfaces 5.2 LCS Functional diagram, high level functions 5.3 LCS Client functional group 5.4 LCS Server functional group 5.4.1 Client handling component 5.4.2 System handling component 5.4.3 Subscriber handling Component 5.4.4 Positioning components 5.5 Information Flows between Client and Server 5.5.1 Location Service Request 5.5.2 Location Service Response 5.6 Information Flows between LCS Servers 5.6.1 Location Service Request 5.6.2 Location Service Response 5.7 Optimized Lgd Procedure
...

5 General LCS architecture p. 24

5.1 LCS access interfaces p. 24

One or more LCS Clients may access a Location Server via its Le interface. Location Servers, resident in the same or different PLMNs, may communicate with each other, indirectly, via the Lg interface to their associated MSC/SGSNs. Optionally, the Lr interface, as specified for direct GMLC to GMLC messaging, may be used for this purpose. For EPS, Location Servers, resident in the same PLMN, may communicate via the SLg interface to their associated MME. A fuller description of the LCS architecture, together with a diagram showing other LCS related interfaces, can be found in clause 6.

Reproduction of 3GPP TS 23.271, Fig. 5.1: LCS Access Interfaces and Reference Points

Figure 5.1: LCS Access Interfaces and Reference Points

5.2 LCS Functional diagram, high level functions p. 25

TS 22.071 describes LCS services from the LCS client point of view. In the present document, a more detailed description of LCS is given. The LCS functional diagram shown in Figure 5.2 depicts the interaction of the LCS client and the LCS server within the PLMN. The PLMN uses the various LCS components within the LCS server to provide the target UE Location Information to the LCS client.

Reproduction of 3GPP TS 23.271, Fig. 5.2: LCS capability server Functional Diagram

Figure 5.2: LCS capability server Functional Diagram

The following list gives the logical functional entities for the LCS. Two main functional groupings are defined which encompass a number of smaller functions.

The LCS Functional entities are grouped as follows:

the LCS Client functional group;
the LCS Server functional group consists of functions in the GSM, UMTS or EPS PLMN supporting LCS:
- client handling component;
- system handling component;
- subscriber handling component;
- positioning component.

The functions of the LCS Client and the LCS Server in the PLMN are described in more detail in this clause.

The allocation of LCS functions to network elements is specified in clause 6.

5.3 LCS Client functional group p. 26

An LCS client contains an LCS component with one or more client(s), which by using location information can provide location, based services.

An LCS client is a logical functional entity that requests from the LCS server in the PLMN location information for one or more than one target UE within a specified set of parameters such as Quality of Service (QoS). The LCS Client may reside in an entity (including the UE) within the PLMN or in an entity external to the PLMN.

The specification of the LCS Client's internal logic and its relation to the external use is outside the scope of the present document.

5.3.1 External Location Client Function (LCF) p. 26

The Location Client Function (LCF) provides a logical interface between the LCS client and the LCS server.

This function is responsible for requesting location information for one or more UEs, with a specified "QoS" and receiving a response, which contains either location information or a failure indicator.

5.4 LCS Server functional group p. 26

The LCS server functional group consists of the functions that are needed for GSM, UMTS and EPS to support Location Services.

5.4.1 Client handling component p. 26

5.4.1.1 Location Client Control Function (LCCF) p. 26

The Location Client Control Function (LCCF) manages the external interface towards LCF. The LCCF identifies the LCS client by requesting client verification and authorization (i.e. verifies that the LCS client is allowed to position the subscriber) through interaction with the Location Client Authorization Function (LCAF). The LCCF handles mobility management for location services (LCS) e.g., forwarding of positioning requests to VMSC, SGSN or MME. The LCCF determines if the final positioning estimate satisfies the QoS for the purpose of retry/reject. The LCCF provides flow control of positioning requests between simultaneous positioning requests. It may order the Location Client Co-ordinate Transformation Function (LCCTF) to perform a transformation to local co-ordinates. It may also order a transformation of local co-ordinates to network identities via the Location System Co-ordinate Transformation Function (LSCTF). It also generates charging and billing related data for LCS via the Location System Billing Function (LSBF).

5.4.1.2 Location Client Authorization Function (LCAF) p. 26

The Location Client Authorization Function (LCAF) is responsible for providing access and subscription authorization to a client. Specifically, it provides authorization to a LCS client requesting access to the network and authorizes the subscription of a client. LCAF provides authorization to a LCS client requesting Location Information of a specific UE.

5.4.1.2.1 Access Subfunction p. 26

An Access Subfunction enables LCS clients to access LCS services. This subfunction provides verification and authorization of the requesting client.

When a LCS is requested, the Access Subfunction uses the information stored in the LCS client subscription profile to verify that:

the LCS client is registered; and
the LCS client is authorized to use the specified LCS request type;
the LCS client is allowed to request location information for the subscriber(s) specified in the LCS request.

5.4.1.2.2 Subscription Subfunction p. 27

The LCS client Subscription profile shall contain a minimum set of parameters assigned on per LCS client basis for an agreed contractual period. The LCS client profile shall contain the following set of access parameters:

LCS client identity;
allowed LCS request types (i.e. LIR, LDR or both) (see note);
maximum number of subscribers allowed in a single LCS request;
priority;
position override indicator;
state(s);
event(s) (applicable to LDR requests only);
local coordinate system;
LCS client access barring list (optional);
PLMN access barring list applicability.

For certain authorized LCS client internal to the PLMN, a subscription profile is unnecessary. These clients are empowered to access any defined service that is not barred for an UE subscriber. This permits positioning of emergency calls without the need for pre-subscription.

5.4.1.3 Location Client Co-ordinate Transformation Function (LCCTF) p. 27

The Location Client Co-ordinate Transformation Function (LCCTF) provides conversion of a location estimate expressed according to a universal latitude and longitude system into an estimate expressed according to a local geographic system understood by the LCF and known as location information. The local system required for a particular LCF will be either known from subscription information or explicitly indicated by the LCF. The LCCTF also provides the conversion of a target area to either a shape as defined in TS 23.032, a PLMN, or country code. This is performed only if target area information is received from the LCS Client.

5.4.1.4 Location Client Zone Transformation Function (LCZTF) p. 27

The Location Client Zone Transformation Function (LCZTF) performs transformations of a location (latitude and longitude) into a zone identity, which in North America identifies a particular emergency services zone.

5.4.2 System handling component p. 27

5.4.2.1 Location System Control Function(LSCF) p. 27

The Location System Control Function (LSCF) is responsible for co-ordinating location requests. This function manages call-related and non-call-related positioning requests of LCS and allocates network resources for handling them. The LSCF retrieves UE classmark information for the purpose of determining the LCS capabilities of UE.

The LSCF performs call setup if required as part of a LCS e.g., putting the UE on dedicated radio resources. It also caters for co-ordinating resources and activities with regard to requests related to providing assistance data needed for positioning. This function interfaces with the LCCF, LSPF, LSBF and PRCF. Using these interfaces, it conveys positioning requests to the PRCF, relays positioning data to the LCCF and passes charging related data to the LSBF.

The U-LSCF for UTRAN is further described in TS 25.305, LSCF for GERAN is described in TS 43.059.

5.4.2.2 Location System Billing Function (LSBF) p. 28

The Location System Billing Function (LSBF) is responsible for charging and billing activity within the network related to location services (LCS). This includes charging and billing of both clients and subscribers. Specifically, it collects charging related data and data for accounting between PLMNs.

5.4.2.3 Location System Operations Function (LSOF) p. 28

The Location System Operations Function (LSOF) is responsible for provisioning of data, positioning capabilities, data related to clients and subscription (LCS client data and UE data), validation, fault management and performance management of LCS.

An LSOF may be associated with each entity.

5.4.2.4 Location System Broadcast Function (LSBcF) p. 28

The Location System Broadcast Function (LSBcF) provides broadcast capability. The LSBcF capability is only used when broadcast data is required for E-OTD, OTDOA or A-GNSS positioning methods.

5.4.2.5 Location System Co-ordinate Transformation Function (LSCTF) |R6| p. 28

The Location System Co-ordinate Transformation Function (LSCTF) provides the conversion of an area definition, expressed in a geographic shape as defined in TS 23.032, to network identities recognised only within a PLMN (such as Cell Identity, Location Area Identity). The area definition may convert to more than one network identity such as a collection of Cell Global Identities.

5.4.2.6 Location IMS - Interworking Function (LIMS-IWF) |R6| p. 28

The Location IMS - Interworking Function (LIMS-IWF) in the requesting network provides the capability to route LCS service requests based on an IMS Public User Identity (SIP-URI) to the home network of the target user. The LIMS-IWF in the home network of the target user is responsible to determine the appropriate HSS and to obtain the MSISDN associated with a IMS Public User Identity from the HSS.

5.4.3 Subscriber handling Component p. 28

5.4.3.1 Location Subscriber Authorization Function (LSAF) p. 28

The Location Subscriber Authorization Function (LSAF) is responsible for authorizing the provision of a location service (LCS) for a particular mobile station (UE with SIM/USIM). Specifically, this function validates that a LCS can be applied to a given subscriber. In case LCF is in the UE then LSAF verifies that the UE subscriber has subscribed to the requested LCS service. LSAF also detects if the identity used to address the target UE is a pseudonym. If the identity used is detected as a pseudonym, the LSAF can then call the Location Subscriber Translation Function to perform the translation to verinym.

5.4.3.2 Location Subscriber Translation Function (LSTF) p. 28

The Location Subscriber Translation Function (LSTF) is responsible for the mapping between pseudonyms and verinyms of the target UE.

5.4.3.3 Location Subscriber Privacy Function (LSPF) |R6| p. 28

The Location Subscriber Privacy function is responsible performs all privacy related authorizations. For a target UE it shall authorize the positioning request versus the privacy options of the target UE, if any.

5.4.4 Positioning components p. 28

The positioning components Positioning Radio Co-ordination Function (PRCF), Positioning Calculation Function (PCF), Positioning Signal Measurement Function (PSMF) and Positioning Radio Resource Management (PRRM) are described in documents specific to each Access Network type.

For location services for GSM and UMTS, the Access Network shall send the result of the positioning to the core network in geographical co-ordinates as defined in TS 23.032. For location services for EPS (for E-UTRAN access), the E-SMLC shall determine the result of the positioning in geographical co-ordinates as defined in TS 23.032. If requested and if available, the positioning result may also include the velocity of the UE as defined in TS 23.032. The Access Network or E-SMLC shall map the cell(s) the Target UE is associated with into geographical co-ordinates, but this mapping is not standardized.

These entities are defined in TS 36.305 for E-UTRAN, TS 25.305 for UTRAN and in TS 43.059 for GERAN.

5.5 Information Flows between Client and Server p. 29

Other types of national specific information flows may be supported in addition to the information flow specified here.

Any of the information flows here indicated may not be externally realized if the information does not flow over an open interface.

5.5.1 Location Service Request p. 29

Via the Location Service Request, the LCS client communicates with the LCS server to request for the location information of one or more than one UE within a specified quality of service. There exist two types of location service requests:

Location Immediate Request (LIR); and
Location Deferred Request (LDR).

The attributes for the information exchange between the LCS Client and the LCS Server have been standardized by OMA in MLP [31].

The following attributes are identified for Location Service Request information flow:

Target UE identity (either verinym or pseudonym);
LCS Client identity;
Service identity, if needed;
Response method (SYNC or ASYNC), if needed;
Codeword, if needed;
Requestor identity, if needed (and type of Requestor identity if available);
Number dialled by the target mobile user or APN-NI, if the request is call or session related;
Type of Event definition, i.e. UE available, change of area, motion or periodic location, applicable to deferred location requests only;
Definitions for change of area type deferred location requests. Following parameters may be defined, if needed;
1. Indication for event trigger, i.e. UE enters, leaves or is within requested target area;
2. Indication of either a single event report or multiple event reports;
3. Minimum time interval between area event reports, if multiple event reports are requested;
4. Indication of the requested location estimate; i.e. whether the location estimate of the target UE should be contained in the change of area event report;
5. Duration of event reporting;
6. For EPC access, the maximum time interval between reports;
7. For EPC access, the maximum sampling time for event detection;
Definitions for motion type deferred location requests. Following parameters may be defined, if needed;
1. Linear distance threshold;
2. Indication of either a single event report or multiple event reports;
3. Minimum time interval between motion event reports, if multiple event reports are requested;
4. Indication of the requested location estimate; i.e. whether the location estimate of the target UE should be contained in the motion event report;
5. Duration of event reporting;
6. Maximum time interval between reports;
7. Maximum sampling time for event detection;
Definitions for periodic location type deferred location requests. Following parameters may be defined, if needed:
1. Time interval between successive location reports;
2. Total number of reports;
Start time, stop time (i.e. specifying the validity time of LCS request), if needed;
Interval, applicable to periodical requests only;
Requested Quality of Service information, if needed, i.e. accuracy, response time and LCS QoS Class;
Requested type of location, i.e. "current location", "current or last known location" or "initial location" applicable to LIR only (current location is only available for LDR);
Velocity of the UE, if needed;
Priority, if needed;
Service coverage (i.e. E.164 country codes for geographic areas [35a]), if needed;
Requested maximum age of location, if needed;
Local coordinate reference system, if needed;
Target area, i.e. geographical area expressed as one of the following format, if needed.
1. a shape defined in TS 23.032
2. local coordinate system
3. E.164 country code for a geographic area [35a]
4. PLMN identity
5. geopolitical name of the area (e.g. London)
Some of the information may be stored in GMLC and the LCS client does not need to include such information in the location service request.

5.5.2 Location Service Response p. 30

The LCS server (GMLC) sends the Location Service Response to the LCS client either as an:

Immediate Response; or a
Deferred Response, these deferred responses can be either single or periodic.

The following attributes are identified for the Location Service Response information flow:

Location indication of UE in geographical coordinates expressed as a shape as defined in TS 23.032 or local coordinate system;
Velocity of the UE as defined in TS 23.032, if requested and if available;
The information about the positioning method used to obtain the location estimate of the UE, if it is available at the LCS server and if needed;
Time stamp of location estimate;
Indication when UE enters, is within or leaves the Geographical area, if needed;
Acknowledgement for a deferred location request, if needed.
Request id, if needed.
LDR reference number, if needed.
Indication that the requested QoS was not met, if needed, only applicable if the request was for best effort class
Indication of a periodic event.
Indication of a motion event.
Indication that a deferred location request has been activated in a UE.
Indication of expiration of the maximum reporting interval for the area event or motion event.

In addition the information attributes of the location service request may be used also in the location service response.

5.6 Information Flows between LCS Servers |R6| p. 31

Other types of national specific information flows may be supported in addition to the information flow specified here.

Any of the information flows here indicated may not be externally realized if the information does not flow over an open interface.

When the LCS server's associated GMLC uses the Lr interface then this interface shall conform to the procedures defined in clause 9 of the current specification.

5.6.1 Location Service Request p. 31

Via the Location Service Request, the source LCS server communicates with the destination LCS server to request for the location information of one UE within a specified quality of service. There exist two types of location service requests:

Location Immediate Request (LIR); and
Location Deferred Request (LDR).

The attributes for the information exchange between the LCS Servers have been standardized by OMA in RLP [36].

The following attributes are identified for Location Service Request information flow:

Target UE identity, (either one or both of MSISDN and IMSI, or SIP-URI, or pseudonym);
LCS Client identity, i.e. LCS client external identity or internal identity;
LCS Client type, (i.e. Value added, Emergency, PLMN operator or Lawful interception);
LCS Client name, if needed (and type of LCS client name if available);
Service type, if needed;
Response method (SYNC or ASYNC), if needed;
Codeword, if needed;
Requestor identity, if needed (and type of Requestor identity if available);
Number dialled by the target mobile user or APN-NI, if the request is call or session related;
Type of Event definition, i.e. UE available, change of area, motion or periodic location, applicable to deferred location requests only;
Definitions for change of area type deferred location requests. Following parameters may be defined, if needed;
1. Indication for event trigger, i.e. UE enters, leaves or is within requested target area;
2. Indication of either a single event report or multiple event reports;
3. Minimum time interval between area event reports;
4. Start time, stop time, i.e. specifying the validity time of LCS area event request;
5. Indication of the requested location estimate; i.e. whether the location estimate of the target UE should be contained in the change of area event report;
6. Duration of event reporting;
7. For EPC access, the maximum time interval between reports;
8. For EPC access, the maximum sampling time for event detection;
Definitions for periodic location type deferred location requests. Following parameters may be defined, if needed:
1. Time interval between successive location reports;
2. Total number of reports;
3. Indication of whether MO-LR Short Circuit is permitted (not applicable to EPC access);
4. Reporting PLMN list;
Definitions for motion type deferred location requests. Following parameters may be defined, if needed;
1. Linear distance threshold;
2. Indication of either a single event report or multiple event reports;
3. Minimum time interval between motion event reports, if multiple event reports are requested;
4. Indication of the requested location estimate; i.e. whether the location estimate of the target UE should be contained in the motion event report;
5. Duration of event reporting;
6. Maximum time interval between reports;
7. Maximum sampling time for event detection;
Requested Quality of Service information, if needed, i.e. accuracy, response time and LCS QoS Class;
Requested type of location, i.e. "current location", "current or last known location" or "initial location" applicable to LIR only (current location is only available for LDR);
Velocity of the UE, if needed;
Priority, if needed;
Requested maximum age of location, if needed;
Privacy override indicator, if needed;
Service coverage (i.e. E.164 country codes for geographic areas [35a]), if needed;
Indicator of privacy check related actions, if needed;
Supported GAD shapes, if needed;
HPLMN LCS server address, i.e. H-GMLC address, if needed;
VPLMN LCS server address, i.e. V-GMLC address, if needed;
Network address of Privacy Profile Register, if needed;
Network numbers of serving nodes;
LCS capability sets of serving nodes, if needed.
Target area, i.e. geographical area expressed as one of the following format, if needed.
1. a shape defined in TS 23.032
2. E.164 country code for a geographic area [35a]
3. PLMN identity
LDR reference number, if needed.

5.6.2 Location Service Response p. 33

The Location Service Response is sent to the source LCS server as the result of the Location Service Request by the destination LCS Server:

Immediate Response; or a
Deferred Response, these deferred responses can be either single or periodic.

The following attributes are identified for the Location Service Response information flow:

Location indication of UE in geographical coordinates expressed as a shape as defined in TS 23.032;
Velocity of the UE as defined in TS 23.032, if requested and if available;
Indication when UE enters, is within or leaves the geographical area, if needed;
The information about the positioning method used to obtain the location estimate of the UE, if it is available at the LCS server and needed;
Age of location estimate;
Acknowledgement for a deferred location request, if needed.
Request id, if needed
Indication that the requested QoS was not met, if needed, only applicable if the request was for best effort QoS class
Indication of a periodic event.
Indication of a motion event.
Indication that a deferred location request has been activated in a UE.
Indication of expiration of the maximum reporting interval for the area event or motion event.

In addition the information attributes of the location service request may be used also in the location service response.

5.7 Optimized Lgd Procedure |R12| p. 34

Optimized Lgd is an optional feature, applicable when Lgd is used, which allows signalling savings for when the GMLC needs the location information from the UE served by a combined MME/SGSN. It requires support from the following network elements:

Combined MME / SGSN when both MME and SGSN parts of the combined MME / SGSN are serving the UE.
HSS.
GMLC.

A combined MME/SGSN supporting this feature shall indicate its support to the HSS via 'Optimized Lgd' indicator during Update Location Request procedures when network supports ISR, as specified in TS 29.272.

An HSS supporting this feature shall indicate its support to the GMLC via 'Optimized Lgd' indicator in response to Send Routing Info for LCS request if the combined MME/SGSN registered for the given UE has indicated support for this procedure as specified in TS 29.173. Upon receipt of 'Optimized Lgd' indicator from the HSS, and if the GMLC supports this feature, then the GMLC shall consider this feature as activated for a given LCS Service Request procedure.

Once the GMLC receives "Optimized Lgd" indicator from the HSS indicating support for this feature, and the GMLC has received both MME and SGSN addresses from the HSS, and the GMLC has determined to execute either PS-MT-LR or EPS-MT-LR procedures, and the GMLC has determined to not execute deferred location procedures, then the GMLC shall send only a single Provide Subscriber Location request to the combined MME/SGSN. When the combined MME/SGSN receives a single Provide Subscriber Location request, it shall perform either EPC-MT-LR or PS-MT-LR procedure depending upon the knowledge of the current RAT type of the UE. e.g. if the UE is in connected mode in E-UTRAN, the combined MME/SGSN performs only EPC-MT-LR procedure; if the ISR activated UE is in idle mode, the combined MME/SGSN performs the paging procedure followed by either EPC-MT-LR or PS-MT-LR procedure (depending upon the RAT where the UE is active).