A.3 Privacy related action selection rule for Rel-6 and later

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

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

In Rel-6 and later, the privacy checking function is moved from MSC/SGSN to H-GMLC/PPR of the target UE. This is also applied to EPS location request, i.e. privacy checking is done at H-GMLC/PPR of the target UE. H-GMLC/PPR selects one or two indicators of privacy check related action and sends the indicators to serving MSC/SGSN/MME as shown in the clause 9.5.4. If the user subscribes Service Types, the resulting privacy setting shall be compared with the result of Service Type privacy checking, and the looser condition shall be selected. The Service Type check result may be included in any of the two privacy indicators, provided that the MT-LR is allowed for the relative privacy class.

If the serving MSC/SGSN/MME receives the indicators from H-GMLC, the serving node selects the privacy related action according to the flow diagram shown in Fig. A-2.

Figure A.2: Privacy related action selection flow diagram of the serving node

NOTE 1: The UE originated call/session to the requesting LCS client is established and the address associated to the LCS client used by the UE in call/session set up matches with that contained in the location request.

NOTE 2: A prior change makes this check unnecessary; since the call unrelated indicator is mandatory therefore the result is always "YES".

Annex B (normative):
Presence of LCS client ID Components in MT-LR

The LCS client identity is composed of one or more than one of the following components: LCS client type, external identity, internal identity, call/session related identity, APN-NI, client name and Requestor Identity. For Value added LCS client type it may contain also Client name and Requestor ID type indicator. The LCS client type shall always be present and for each LCS client type the presence of the other components are defined as follows:

Component LCS Client type	External identity	Internal identity	Call/session related identity	Client name	Requestor Identity
Emergency	O	N.A.	N.A.	N.A.	N.A.
Value added	M	N.A.	O [Note]	M	O
PLMN operator	N.A.	M	N.A.	N.A.	N.A.
Lawful Intercept	N.A.	N.A.	N.A.	N.A.	N.A.

NOTE: This component shall be present if the MT-LR is associated to either CS call or PS session. If the MT-LR is associated with the CS call, the number dialled by UE is used. Otherwise if the MT-LR is associated with the PS session, the APN-NI is used.

Annex C (Informative):
Pseudo external ID

In case that UE’s privacy profile is stored and is checked in the GMLC (H-GMLC) or in the PPR, a pseudo-external identity may be selected as a result of the privacy check in GMLC/PPR.

The 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-related) and the required type of indication for each class. Operator allocates E.164 addresses for the pseudo-external identities. The pseudo-external identities are used for interworking with pre Rel-6 serving nodes.

Fourteen pseudo-external identities shall be defined. The pseudo-external identities are summarized in the Table C.1.

Table C.1: Pseudo-external identities

Pseudo-external identity	Privacy setting for Call/Session related class	Privacy setting for Call/Session unrelated class
Pseudo-external identity 1	N.A.	Location allowed without notification
Pseudo-external identity 2	N.A.	Location allowed with notification
Pseudo-external identity 3	N.A.	Location with notification and privacy verification; location allowed if no response
Pseudo-external identity 4	N.A.	Location with notification and privacy verification; location restricted if no response
Pseudo-external identity 5	Location with notification and privacy verification; location restricted if no response	Location not allowed
Pseudo-external identity 6 Indicator 6	Location with notification and privacy verification; location	Location not allowed
Pseudo-external identity 7	allowed if no response	Location with notification and privacy verification; location restricted if no response
Pseudo-external identity 8	Location allowed with notification	Location not allowed
Pseudo-external identity 9		Location with notification and privacy verification; location restricted if no response
Pseudo-external identity 10		Location with notification and privacy verification; location allowed if no response
Pseudo-external identity 11	Location allowed without notification	Location not allowed
Pseudo-external identity 12		Location with notification and privacy verification; location restricted if no response
Pseudo-external identity 13		Location with notification and privacy verification; location allowed if no response
Pseudo-external identity 14		Location allowed with notification

NOTE: There are five privacy settings shown in Annex A.1 for each class (call/session unrelated class and call/session related class), so there are twenty-five possible combinations of the privacy settings. However, as shown in Annex A.2, even if the call/session related class criteria is met, the privacy setting for call/session unrelated class is selected when the privacy setting for the call/session unrelated class is looser than the privacy setting for the call/session related class. Therefore the twenty-five combinations can be reduced to the above fourteen combinations.

If the UE subscribes to the universal or PLMN class, H-GMLC/PPR sends the pseudo external identity 1 to the serving nodes.

Usage of the pseudo-external identities are as follows:

– The pseudo-external identities are registered in SLPP of the HLR/HSS.

– The SLPP is sent to the serving nodes, during the Insert Subscriber Data procedures.

– After the privacy check in the H-GMLC/PPR, the H-GMLC/PPR selects an appropriate pseudo-external identity according to the required privacy related actions (i.e. checking the on-going call/session and/or notification/verification procedures) in the serving node.

– H-GMLC sends Provide Subscriber Location message to the serving node, which includes the pseudo-external identity instead of the real external client identity. The real external client identity may be included in the additional information element and is sent to serving node. The pseudo-external identity is sent to the serving node directly from H-GMLC or via V-GMLC.

Table C.2 and C.3 shows how the pseudo-external identities are set in the SLPP in HLR/HSS.

Table C.2: Example of SLPP in HLR/HSS for Call/Session unrelated Class

Pseudo-external identity	Privacy Setting
Pseudo-external identity 1	Location allowed without notification
Pseudo-external identity 2	Location allowed with notification
Pseudo-external identity 3	Location with notification and privacy verification; location allowed if no response
Pseudo-external identity 4	Location with notification and privacy verification; location restricted if no response
Pseudo-external identity 5	Location not allowed
Pseudo-external identity 6	Location not allowed
Pseudo-external identity 7	Location with notification and privacy verification; location restricted if no response
Pseudo-external identity 8	Location not allowed
Pseudo-external identity 9	Location with notification and privacy verification; location restricted if no response
Pseudo-external identity 10	Location with notification and privacy verification; location allowed if no response
Pseudo-external identity 11	Location not allowed
Pseudo-external identity 12	Location with notification and privacy verification; location restricted if no response
Pseudo-external identity 13	Location with notification and privacy verification; location allowed if no response
Pseudo-external identity 14	Location allowed with notification

Table C.3: Example of SLPP in HLR/HSS for Call/Session related Class

Pseudo-external identity	Privacy Setting
Pseudo-external identity 5	Location with notification and privacy verification; location restricted if no response
Pseudo-external identity 6	Location with notification and privacy verification; location allowed if no response
Pseudo-external identity 7	Location with notification and privacy verification; location allowed if no response
Pseudo-external identity 8	Location allowed with notification
Pseudo-external identity 9	Location allowed with notification
Pseudo-external identity 10	Location allowed with notification
Pseudo-external identity 11	Location allowed without notification
Pseudo-external identity 12	Location allowed without notification
Pseudo-external identity 13	Location allowed without notification
Pseudo-external identity 14	Location allowed without notification

The selection of pseudo-external identity is based on the result of the privacy check in the H-GMLC/PPR. Table C.4 shows the relation between privacy check result and the pseudo-external identities.

Table C.4: Pseudo-external identity selection at H-GMLC/PPR

Privacy related actions as a result of privacy check	Pseudo-external identity
Location request is allowed without notification, regardless of on-going call/session.	Pseudo-external identity 1
Location request is allowed with notification, regardless of on-going call/session,	Pseudo-external identity 2
Location request is allowed with notification and privacy verification, regardless of on-going call/session. Location request is allowed even if there is no response from UE.	Pseudo-external identity 3
Location request is allowed with notification and privacy verification, regardless of on-going call/session. Location request is restricted if there is no response from UE.	Pseudo-external identity 4
If there is call/session with the client, location request is allowed with notification and privacy verification. Location request is restricted if there is no response from UE. If there is no call/session with the client, location request is restricted.	Pseudo-external identity 5
If there is call/session with the client, location request is allowed with notification and privacy verification. Location request is allowed even if there is no response from UE. If there is no call/session with the client, location request is restricted.	Pseudo-external identity 6
If there is call/session with the client, location request is allowed with notification and privacy verification. Location request is allowed even if there is no response from UE. If there is no call/session with the client, location request is allowed with notification and privacy verification. Location request is restricted if no response.	Pseudo-external identity 7
If there is call/session with the client, location request is allowed with notification. If there is no call/session with the client, location request is restricted.	Pseudo-external identity 8
If there is call/session with the client, location request is allowed with notification. If there is no call/session with the client, location request is with notification and privacy verification. Location request is restricted if no response.	Pseudo-external identity 9
If there is call/session with the client, location request is allowed with notification. If there is no call/session with the client, location request is allowed even if there is no response from UE.	Pseudo-external identity 10
If there is call/session with the client, location request is allowed without notification. If there is no call/session with the client, location request is restricted.	Pseudo-external identity 11
If there is call/session with the client, location request is allowed without notification. If there is no call/session with the client, location request is with notification and privacy verification. Location request is restricted if no response.	Pseudo-external identity 12
If there is call/session with the client, location request is allowed without notification. If there is no call/session with the client, location request is allowed even if there is no response from UE.	Pseudo-external identity 13
If there is call/session with the client, location request is allowed without notification. If there is no call/session with the client, location request is allowed with notification.	Pseudo-external identity 14

Annex D (normative):
including Requestor identity to LCS client name

In case the MSC/SGSN or the UE is pre Rel-5 then there is no possibility to send the Requestor identity to the UE in a new separate parameter. To obtain this backward compatibility the GMLC can add the Requestor identity to LCS client name.

In order to offer best possible service for the end user the UE should be able to differentiate LCS client name and Requestor ID when they are included in to a same parameter. Also it is important that the LCS client name and the Requestor ID are separated with a consistent manner. Therefore there is a need to define a rule how the GMLC should separate LCS client name and Requestor identity. In the box below is described the practice how the LCS client name and Requestor identity should be separated.

LCS clientName==RequestorIdentity

LCS client name and Requestor identity are separated with two equal signs.

NOTE: It is possible that the Requestor identity does not fit into the LCS client name field. In that case as many characters as possible from the beginning is added to the LCS client name field.

Annex E (Informative):
Handling of pseudonyms in location services

There is a requirement in place on anonymity for both the requestor and the target in the LCS Stage 1, TS 22.071, and there are or will be regulatory requirements to support anonymity in location services in some countries. It is seen as a basic service requirement that the user should be able to request anonymity at will.

There are various methods available for providing anonymity-support for LCS. One model has been described by the GSM Association in the LS in TD S2-021104 to 3GPP. In short, GSMA’s model introduces the following logical architecture.

Figure E.1: GSMA logical model to support anonymity

In this PUSH model the pseudonym of the target UE is always generated for certain LCS clients on behalf of the terminal’s subscriber without a specific request.

The PUSH model describes the case when the target UE requests its own location using e.g. SMS or WAP. SMS and WAP functions currently have problems in supporting anonymity, because the SMS/WAP gateways forward the originating MSISDN to the receiver. This weakness may be resolved in practise e.g. such that the SMS or WAP Gateway requests pseudonyms from a common device (PMD), as shown in Figure E.1. In this process the gateway requests a pseudonym from PMD in signalling step 2 and in signalling step 3 the gateway uses the pseudonym in the service request that it sends to the LCS client. The gateway includes the requesting terminal’s verinym, i.e. the MSISDN, in the service response it sends to the terminal in step 9. In this way the LCS client only knows the pseudonym of the terminal and not the verinym. This solution is not LCS specific, since the SMS/WAP gateway inserts pseudonyms in all SMS/WAP messages, which the gateway forwards to the receivers (LCS clients) defined by the operator in advance.

The Liberty Alliance Project has standardized methods that can be used to ensure the anonymity of the target UE in location services using pseudonyms as shown by the example in Figure E.2 below. The specifications of the Liberty Alliance project are publicly available at http://www.projectliberty.org/.

Figure E.2: Logical model to support anonymity

In this PULL model the LCS client requests the pseudonym from the Gateway before accepting the service request from the terminal. The proxy/gateway is a so-called Liberty Enabled Client/Proxy, which also may support standard WAP proxy/gateway functions as described in the appropriate WAP Forum specifications.

1. The terminal (UE) sends a standard Wireless Transport Protocol (WTP) –request to the Proxy/Gateway.

2. The proxy/gateway converts the service request into an HTTP-request with a dynamic IP address. This HTTP-request does not contain the MSISDN of the terminal, so it is totally anonymous to the LCS-client.

3. The LCS-client needs to get an assertion, i.e. a pseudonym, before it can accept to provide location services to the terminal, so it sends a HTTP-response to the Proxy/Gateway, which includes a request for a pseudonym.

4. The proxy/gateway maps the LCS client’s HTTP-response to the HTTP-request it sent in step 2 and thus the proxy/gateway also knows to which terminal the LCS client’s HTTP-response is related. The proxy/gateway intercepts and interprets the HTTP-response and finds the pseudonym request. It forwards the pseudonym request to PMD and attaches the terminal’s MSISDN to allow the PMD to provide a pseudonym related to this MSISDN. In case PMD needs to contact the target UE user for some reason, e.g. to ask for consent to deliver the pseudonym to this specific LCS-client, this interaction is fully supported in the Liberty Enabled Client/Proxy specification.

5. The proxy/gateway sends an HTTP-request containing the pseudonym to the LCS-client.

6. The LCS-client sends a location service request to GMLC using the pseudonym of the target terminal.

7. The PMD may include the MSISDN in the pseudonym by encrypting it in such a way that GMLC is able to determine the MSISDN itself and in such a case step 7 is not needed. In case GMLC cannot find out the verinym of the terminal itself, it requests from PMD the MSISDN that corresponds to the pseudonym it received from the LCS-client.

8. GMLC provides location information to the LCS-client using the pseudonym of the target terminal.

9. The LCS-client sends an HTTP-response to the proxy/gateway containing the requested location specific service content.

10. The proxy/gateway maps the response to the outstanding request sent in step 1 and delivers the result to the correct terminal using MSISDN.

Note that the mechanism described above is a generalized solution to the problem of transporting something from party 1 (PMD) to party 3 (GMLC) so that intermediate party 2 (LCS-client) cannot find out the real content transferred between party 1 and party 3 (verinym in this case). Also note that since the proxy/gateway does not push any pseudonym in step 2, it is not required to understand the destination application and what information it may need. Step 3 allows any application to request a pseudonym or any information it may need, thus making this a generalized solution, which may be used for many types of applications, not only LCS.

It is to be noted that the Liberty release 1.1 specification has been carefully studied by the EU article 29 committee and found to be in accordance with the current EU privacy requirements. It is stressed, however, that it is the responsibility of someone implementing or deploying a system in accordance with the Liberty Alliance specifications to comply with EU directives and requirements on privacy.

For roaming cases clause 9.1.1 in this specification describes the cases where the pseudonym contains the address(es) of the target UE’s Home-GMLC so that the Requesting-GMLC can forward the location request to H-GMLC, which may determine the corresponding verinym itself or request the verinym from its associated PMD.

Annex F (Informative):
Mechanism for performing Change of Area Event Detection

Note: the classification (i.e. normative or informative) of this Annex is FFS.

As described in clause 9.1.9 that there may be alternative mechanisms to transfer the deferred MT-LR with Area Event request to the UE. This annex illustrates one mechanism. In this mechanism a Short Message Service (SMS) is used to transfer, to the UE/(U)SIM, the Area event detection request via an (U)SIM Application Toolkit application.