10 Information storage

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

This clause describes information storage structures that are mandatory (M), conditional (C) or optional (O) for LCS, and the recovery and restoration procedures needed to maintain service if inconsistencies in databases occur and for lost or invalid database information. Information storage in RAN network elements is specified in UTRAN Stage 2 (TS 25.305 [1]) and GERAN Stage 2 (TS 43.059 [16]) specifications.

10.1 HLR and HSS

The HLR/HSS holds LCS data for both UE subscribers and LMUs. If the privacy profile data for UE subscribers are stored in H-GMLC/PPR, HLR/HSS needs to store the corresponding pseudo-external identities and MO-LR related subscription data shown in Table 10.4 and 10.5. The pseudo-external identities are stored in the privacy exception list shown in Table 10.2. The details of the pseudo-external identity are described in Annex C.

10.1.1 LCS Data in the HLR/HSS for an UE Subscriber

The IMSI is the primary key for LCS UE subscription data in the HLR/HSS. This subscription data may be stored in a Multiple Subscriber Profile (MSP), with the HLR/HSS able to hold a number of MSPs per IMSI.

For GSM and UMTS, the LCS UE subscription data includes a privacy exception list containing the privacy classes for which location of the target UE is permitted. Each privacy class is treated as a distinct supplementary service with its own supplementary service code. The following logical states are applicable to each privacy class (refer to TS 23.011 [22] for an explanation of the notation).

Table 10.1: Logical States for each LCS Privacy Class

Provisioning State	Registration State	Activation State	HLR Induction State
(Not Provisioned,	Not Applicable,	Not Active,	Not Induced)
(Provisioned,	Not Applicable,	Active and Operative,	Not Induced)

For each LCS privacy class, the HLR/HSS shall store the logical state of the class on a per-subscriber (or per subscriber MSP) basis. In addition, the permanent data indicated below shall be stored on a per subscriber (or per subscriber MSP) basis when the logical provisioning state of the associated LCS privacy class is "provisioned". For the meaning of each LCS privacy class, refer to clause 9 and to TS 22.071 [4].
Moreover a list of allowed service types may be stored. The meaning of service types is defined in TS 22.071 [4].

Table 10.2: LCS data stored in the HLR privacy exception list for an UE Subscriber
(or UE Subscriber MSP)

LCS Privacy Class	Status	Additional HLR Data when Class is provisioned
Universal Class	–	No additional data
Call/session Related Class	M O C O C	Indication of one of the following mutually exclusive options for any LCS client not in the external LCS client list: – Location not allowed – Location allowed without notification (default case) – Location allowed with notification – Location with notification and privacy verification; location allowed if no response – Location with notification and privacy verification; location restricted if no response External LCS client list: a list of zero or more LCS clients, with the following data stored for each LCS client in the list: – International E.164 address identifying a single LCS client or a single group of LCS clients that are permitted to locate this target UE – Restriction on the GMLC. If no value is stored for this data, there is no restriction on GMLC and any GMLC is allowed to request location information for the UE. Possible values are: – Identified GMLCs only – Any GMLC in the home country – Indication of one of the following mutually exclusive options: – Location allowed without notification (default case) – Location allowed with notification – Location with notification and privacy verification; location allowed if no response – Location with notification and privacy verification; location restricted if no response
Call/session Unrelated Class	M O C O C	Indication of one of the following mutually exclusive options for any LCS client not in the external LCS client list: – Location not allowed (default case) – Location allowed with notification – Location with notification and privacy verification; location allowed if no response – Location with notification and privacy verification; location restricted if no response External LCS client list: a list of zero or more LCS clients, with the following data stored for each LCS client in the list: – International E.164 address identifying a single LCS client or a single group of LCS clients that are permitted to locate this target UE – Restriction on the GMLC. If no value is stored for this data there is no restriction on GMLC and any GMLC is allowed to request location information for the UE. Possible values are: – Identified GMLCs only – Any GMLC in the home country – Indication of one of the following mutually exclusive options: – Location allowed without notification (default case) – Location allowed with notification – Location with notification and privacy verification; location allowed if no response – Location with notification and privacy verification; location restricted if no response
PLMN Operator Class	O	LCS client list: a list of one or more generic classes of LCS client that are allowed to locate the particular UE. The following classes are distinguished: – LCS client broadcasting location related information – O&M LCS client in the HPLMN – O&M LCS client in the VPLMN – LCS client recording anonymous location information – LCS Client supporting a bearer service, teleservice or supplementary service to the target UE

Table 10.3: LCS Service types stored in the HLR/HSS per UE subscriber

Service type indication

Status

Additional HLR data when the indication is stored

Service Types

Service types list: a list of one or more service types for which the LCS client is allowed to locate the particular UE. The possible service types are defined in TS 22.071 [4]. The following data may be present for each service type in the list:

– Restriction on the GMLC. If no value is stored for this data, there is no restriction on GMLC and any GMLC is allowed to request location information for the UE. Possible values are:

– Identified GMLCs only

– Any GMLC in the home country

– Indication of one of the following mutually exclusive options:

– Location allowed without notification (default case)

– Location allowed with notification

– Location with notification and privacy verification; location allowed if no response

– Location with notification and privacy verification; location restricted if no response

In case that UE’s privacy profile is stored and is checked in the GMLC (H-GMLC) or in the PPR, pseudo-external identities may be set in the external LCS client list of the HLR privacy exception list shown in Table 10.2. The pseudo-external identity is not the identity of real external LCS client but the identity which is used for notifying SGSN/MSC of the location request class (call/session related or non-call/session related) and the required type of indication for each class. Operator allocates E.164 addresses for the pseudo-external identities.

Fourteen pseudo-external identities are needed to be defined. The pseudo-external identities are summarized in the Table C.1. The pseudo-external identities are registered in SLPP of each UE in advance.

LCS UE subscription data may include a mobile originating list containing the LCS mobile originating classes that an UE is permitted to request. Each LCS mobile originating class is treated as a distinct supplementary service with its own supplementary service code. The following logical states are applicable to each mobile originating class (refer to TS 23.011 [22] for an explanation of the notation).

Table 10.4: Logical States for each Mobile Originating LCS Class

Provisioning State	Registration State	Activation State	HLR Induction State
(Not Provisioned,	Not Applicable,	Not Active,	Not Induced)
(Provisioned,	Not Applicable,	Active and Operative,	Not Induced)

For each LCS Mobile Originating class, the HLR/HSS shall store the logical state of the class on a per-subscriber (or per subscriber MSP) basis. In this version of LCS, there is no additional permanent data in the HLR. The table below shows the defined mobile originating classes. For the meaning of each LCS mobile originating class, refer to clause 8 and to TS 22.071 [4].

Table 10.5: Data stored in the HLR for the LCS Mobile Originating List for an UE
(or UE Subscriber MSP)

LCS Mobile Originating Class	Status	Additional HLR Data when Class is provisioned
Basic Self Location	–	No additional data
Autonomous Self Location	–	No additional data
Transfer to Third Party	–	No additional data

In addition to the privacy exception list, the following other data items may be stored in the UE subscription profile in the HLR to support LCS.

Table 10.6a: Temporary LCS data in the HLR

Other Data in the HLR	Status	Description
GMLC List	O	List of one or more E.164 addresses of the GMLCs from which a location request for an MT-LR is allowed, The addresses are only relevant to an LCS client that is restricted (in the UE privacy exception list) to making call/session related or call/session unrelated location requests.

To support broadcast of assistance data for E-UTRAN access where assistance data is ciphered, the following data items may be stored in the HSS for a UE subscriber.

Table 10.6b: Data stored in the HSS to support broadcast of ciphered assistance data for E-UTRAN access

Data in the HSS	Status	Description
List of Assistance Data Types	O	A list of one or more types of location assistance data for which ciphering keys should be provided to the UE if requested by the UE when the assistance data is broadcast using ciphering.

10.2 VLR/SGSN

The VLR/SGSN contains the same LCS permanent data for each registered UE subscriber, as does the HLR/HSS. This data is downloaded to the VLR/SGSN as part of the location update procedure between the VLR/SGSN and HLR/HSS for an UE subscriber.

10.2a MME

The MME contains the same LCS permanent data for each registered UE subscriber, as does the HSS. This data is downloaded to the MME as part of the Attach and Tracking Area Update procedures between the MME and HSS for a UE subscriber.

10.3 GMLC

10.3.1 LCS Data in the GMLC for a LCS Client

The GMLC holds data for a set of external LCS clients that may make call related or non-call related MT-LR requests to this GMLC. The permanent data administered for each LCS client is as follows.

Table10.7: GMLC Permanent Data for a LCS Client

LCS Client data in GMLC	Status	Description
LCS Client Type	M	Identifies the type LCS client from among the following: – Emergency Services – Value Added Services – PLMN Operator Services – Lawful Intercept Services
External identity	O	A list of one or more identifiers used to identify an external LCS client. The identity may be used when making an MT-LR and/or MO-LR. The format of the identity is an international E.164 address [35a]. Each external identity shall be associated with a logical client name.
Authentication data	M	Data employed to authenticate the identity of an LCS client – details are outside the scope of the present document
Call/session related identity	O	A list of one or more international E.164 addresses [35a], which are used to make calls by mobile subscribers, or APN-NIs (see NOTE) to identify the client for a call related MT-LR In case the LCS client was reached via IN or abbreviated number routing (e.g. toll free number or emergency call routing), the E.164 number(s) stored in the GMLC shall be the number(s) that the UE has to dial to reach the LCS Client. In these cases the E.164 number is not to be in international format. The country in which the national specific number(s) is (are) applicable is (are) also stored (or implied) in this case. Each call related identity may be associated with a specific external identity. Each call/session-related identity shall be associated with a logical client name.
Internal identity	O	Identifies the type PLMN operator services and the following classes are distinguished: – LCS client broadcasting location related information – O&M LCS client in the HPLMN – O&M LCS client in the VPLMN – LCS client recording anonymous location information – LCS Client supporting a bearer service, teleservice or supplementary service to the target UE This identity is applicable only to PLMN Operator Services.
Client name	O	An address string which is associated with LCS client’s external identity (i.e., E.164 address). See note 2.
Client name type	O	Indication what is the type of the LCS client name. The type of the LCS client name can be one of the following: – Logical name – MSISDN – E-mail address (RFC 2396 [33]) – URL (RFC 2396 [33]) – SIP URL (RFC 3261 [34]) – IMS public identity (TS 23.228 [35])
Override capability	O	Indication of whether the LCS client possesses the override capability (not applicable to a value added and PLMN operator service)
Authorized UE List	O	A list of MSISDNs or groups of MSISDN for which the LCS client may issue a non-call related MT-LR. Separate lists of MSISDNs and groups of MSISDN may be associated with each distinct external or non-call related client identity.
Priority	M	The priority of the LCS client – to be treated as either the default priority when priority is not negotiated between the LCS server and client or the highest allowed priority when priority is negotiated
QoS parameters	M	The default QoS requirements for the LCS client, comprising: – Accuracy – Response time – LCS QoS Class Separate default QoS parameters may be maintained for each distinct LCS client identity (external, non-call related, call related)
Service Coverage	O	A list of E.164 country codes for geographic areas [35a] where the LCS client offers its location services.
Allowed LCS Request Types	M	Indicates which of the following are allowed: – Non-call related CS-MT-LR/PS-MT-LR/EPC-MT-LR – Call/session related CS-MT-LR/PS-MT-LR/EPC-MT-LR – Specification or negotiation of priority – Specification or negotiation of QoS parameters – Specification or negotiation of Service Coverage parameter – Request of current location – Request of current or last known location
Local Co-ordinate System	O	Definition of the co-ordinate system(s) in which a location estimate shall be provided – details are outside the scope of the present document
Access Barring List(s)	O	List(s) of MSISDNs or groups of MSISDN for which a location request is barred
Service Identities	O	List of service identities allowed for the LCS client.
Maximum Target UE Number	O	The maximum number of the Target UEs in one LCS request. For a specific LCS Client, this parameter may have different values for different service identities.

NOTE 1: The LCS Client is identified with E.164 number or APN-NI. APN-NI is specified in TS 23.003 [17].

NOTE 2: The LCS Client name should not contain two equal signs, because those characters are used to separate LCS client name from Requestor ID when GMLC includes them into the same field.

10.3.2 LCS Data in the GMLC/PPR for a UE Subscriber

The GMLC (H-GMLC) or PPR may store LCS UE subscription data. This clause describes Rel-5 based privacy profile data stored in GMLC/PPR. If the home network operator uses Rel-5 compatible privacy profile data, the profiles shown in this clause may be stored in GMLC/PPR. If the home network operator supports Rel‑6 or later compatible privacy profile data, the profiles stored in the GMLC/PPR may be related to different geographic areas, i.e. subscribers may have different privacy profiles depending on subscribers’ locations.

The IMSI or MSISDN is the primary key for LCS UE subscription data in the GMLC/PPR. This subscription data may be stored in a Multiple Subscriber Profile (MSP), with the GMLC/PPR able to hold a number of MSPs per IMSI.

LCS UE subscription data includes a privacy exception list containing the privacy classes for which location of the target UE is permitted. Each privacy class is treated as a distinct supplementary service with its own supplementary service code. The following logical states are applicable to each privacy class (refer to TS 23.011 [22] for an explanation of the notation).

Table 10.9: Logical States for each LCS Privacy Class

Provisioning State	Registration State	Activation State	HLR Induction State
(Not Provisioned,	Not Applicable,	Not Active,	Not Induced)
(Provisioned,	Not Applicable,	Active and Operative,	Not Induced)

For each LCS privacy class, the GMLC/PPR shall store the logical state of the class on a per-subscriber (or per subscriber MSP) basis. In addition, the permanent data indicated in Table 10.10 may be stored on a per subscriber (or per subscriber MSP) basis when the logical provisioning state of the associated LCS privacy class is "provisioned". For the meaning of each LCS privacy class, refer to clause 9 and to TS 22.071 [4].
Moreover a list of allowed service types may be stored. The meaning of service types is defined in TS 22.071 [4]. The numbers assigned to service types are defined in Annex G.

Table 10.10: LCS data stored in the GMLC/PPR privacy exception list for an UE Subscriber
(or UE Subscriber MSP)

Service Types

Service types list: a list of one or more service types for which the LCS client is allowed to locate the particular UE. The possible service types are defined in TS 22.071 [4] and the assigned numbers are shown in Annex G. The following data may be present for each service type in the list:

– Restriction on the GMLC. If no value is stored for this data, there is no restriction on GMLC and any GMLC is allowed to request location information for the UE. Possible values are:

– Identified GMLCs only

– Any GMLC in the home country

– Indication of one of the following mutually exclusive options:

– Location allowed without notification (default case)

– Location allowed with notification

– Location with notification and privacy verification; location allowed if no response

– Location with notification and privacy verification; location restricted if no response

Table 10.11: LCS Service types stored in the GMLC per UE subscriber

Service type indication

Status

Additional HLR data when the indication is stored

Service Types

Indication of one of the following mutually exclusive options for any service type not in the service type list:

– Location not allowed (default case)

– Location allowed with notification

– Location with notification and privacy verification; location allowed if no response

– Location with notification and privacy verification; location restricted if no response

– Restriction on the GMLC. If no value is stored for this data, there is no restriction on GMLC and any GMLC is allowed to request location information for the UE. Possible values are:

– Identified GMLCs only

– Any GMLC in the home country

– Indication of one of the following mutually exclusive options:

– Location allowed without notification (default case)

– Location allowed with notification

– Location with notification and privacy verification; location allowed if no response

Location with notification and privacy verification; location restricted if no response

In case that UE’s privacy profile is stored and is checked in the GMLC (H-GMLC) or in the PPR, the GMLC/PPR shall store the same pseudo-external identity table with HLR, which is shown in Annex C.

GMLC (H-GMLC) or PPR may store codeword handling information and a list of codewords given by the UE subscriber in order not to get the location request rejected.

Table 10.12a: Codeword handling information stored in the GMLC

Other Data in the GMLC

Status

Description

Codeword handling information

Indication of one of the following mutually exclusive options for codeword:

– codeword shall be checked in network.

– codeword shall be sent to UE

Table 10.12b: LCS data stored in the GMLC for a UE Subscriber

LCS Privacy profile	Status	Additional GMLC data when profile is provisioned
Codeword	O	A list of codeword.

The GMLC (H-GMLC) or the PPR may store additional privacy information in order protect UE users privacy. The details of the additional privacy check are defined by each network operator and are outside the scope of this specification.

10.4 Recovery and Restoration Procedures

The LCS recovery and restoration procedures allow temporary data to be recovered or reinitialized following loss or corruption of data, such that normal LCS service is rapidly restored and inconsistency between the data held by different LCS network elements is removed. For a full description, refer to TS 23.007 [23].

10.5 Interworking between network nodes in different releases

This clause describes possible scenarios for interworking between network nodes in different releases. It is noted that LCS is only supported in A-mode and Iu-mode in the CS domain in Rel-99. LCS is supported in A-mode and Iu-mode in UTRAN CS and PS domains, but not in Gb-mode, in Rel-4. LCS is supported in A/Gb mode and Iu mode in CS and PS domains for UTRAN and GERAN in Rel-5, Rel-6, Rel-7 and Rel-8. LCS is supported in A/Gb mode and Iu mode in CS and PS domains for UTRAN and GERAN and in the PS domain for E‑UTRAN in Rel-9 onwards.

The concept of LCS capability set is introduced in Rel-4, so it does not appear in the specifications for R98 and R99 LCS.

10.5.1 LCS capability set

The following LCS capabilities are identified in the current version of this specification. The HLR/HSS is notified the LCS capability of the serving node by an indication, which indicates all the LCS the serving node supports, from the serving node during location update procedure.

– LCS capability set 1: R98 and R99 LCS (pre-Rel’4 LCS)

– LCS capability set 2: Rel’4 LCS

– LCS capability set 3: Rel’5 LCS

– LCS capability set 4: Rel’6 LCS

– LCS capability set 5: Rel’7 or later LCS

NOTE 1: the concept of LCS capability set is introduced in Rel4 so that R98 and R99 serving nodes do not notify HLR/HSS this parameter. Therefore, even if this parameter is absent the serving node may support at most LCS capability set 1.

NOTE 2: For E-UTRAN access, LCS capability sets 1 through 4 are not applicable. An MME that does not signal an LCS capability to the HSS shall be assumed to provide no LCS support.

The serving node, which notified the HLR/HSS that it supports LCS capability set 2, shall be able to handle the extended LCS Client list and LCS Client List for call-related class from the HLR/HSS.

The serving node, which notified the HLR/HSS that it supports LCS capability set 3, shall support the following capabilities:

– capability to perform the service type privacy check.

– capability to send the codeword to target UE for notification/verification.

– capability to send the requestor ID to target UE for notification/verification.

The serving node, which notified the HLR/HSS that it supports LCS capability set 4, shall support the following capability:

– capability to perform the privacy related action (i.e. checking the on-going call/session and/or notification/verification procedures) which is requested by H-GMLC.

The serving node, which notified the HLR/HSS that it supports LCS capability set 5, shall support the following capability:

– capability to perform the privacy related action (i.e. checking the on-going call/session and/or notification/verification procedures) for notification based on current location which is requested by H-GMLC.

10.5.2 Interworking between pre Rel-4 serving node and Rel-4 or later HLR/HSS

The serving node that supports only pre-Rel’4 LCS cannot handle the extended privacy control for call-related/call-unrelated class of the Rel’4 and later LCS. That is, the serving node cannot provide the extended call-related/call-unrelated class service to the user who subscribes to the Rel’4 LCS. Therefore HLR does not send the LCS subscriber data on call-related/call-unrelated class for users who subscribe to the call-related class of Rel’4 LCS to the serving node that supports only pre-Rel’4 LCS.

10.5.3 Interworking between pre Rel-5 serving node and Rel-5 or later HLR/HSS

If the HLR/HSS is notified that the LCS capability set 3 is not supported by the serving node, it may decide not to send the LCS subscriber data to the serving node, in order to protect user privacy.

In addition, if the HLR/HSS is notified that the serving node does not support the LCS capability set 2, the procedures described in 10.5.2 also shall be applied.

10.5.4 Interworking between pre Rel-6 network nodes and Rel-6 or later HLR/HSS

In addition to the procedures in this clause, if the HLR/HSS is notified that the serving node does not support the LCS capability set 2 and/or set 3, the procedures described in 10.5.3 shall be also taken into consideration.

10.5.4.1 Rel-6 or later HLR/HSS with pre Rel-6 serving node

The Rel-6 or later HLR/HSS notifies the H-GMLC about the all LCS capability set supported by the serving node.

In accordance with the notified LCS capability of the serving node and the privacy profile of the target UE, the H-GMLC decides whether the location estimation process can be continued or not.

In order to request the privacy related action (i.e. checking the on-going call/session and/or notification/verification procedures) to the pre Rel-6 serving node, H-GMLC may send the Provide Subscriber Location request message to the serving node with the pseudo-external identity. The detail of the pseudo-external identity is described in Annex C.

10.6 LIMS-IWF

As the LIMS-IWF is a simple interworking function that provides routing of LCS service requests and responses based on the target UE’s SIP-URI and mapping of SIP-URI to MSISDN it must not store user or LCS Client specific data during or after a location request procedure.