Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.271  Word version:  18.0.0

Top   Top   Up   Prev   Next
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… 
9.1.1A Common MT-LR procedure in PS and CS domain for Emergency MT-LR  9.1.1.1 LCS Authorisation request  9.1.1.2 LCS Privacy Profile Update  9.1.1.3 LCS identity request 
...

 

9.1.1A  Common MT-LR procedure in PS and CS domain for Emergency MT-LR |R6|  p. 62

This clause describes how an emergency location request may be handled similarly to a normal location request. This method should be restricted to those countries where there is not a national requirement to provide location for callers who are either roaming or making a SIM-less emergency call, or making a non-registered (U)SIM emergency call. It is also appropriate to use this method to provide location for lawful intercept services where allowed by national regulation.
Reproduction of 3GPP TS 23.271, Fig. 9.1A: Network Positioning for an Emergency MT-LR
Figure 9.1A: Network Positioning for an Emergency MT-LR
Up
Step 1.
An external LCS client which has the privacy override capability, (e.g. Emergency service provider), requests the location of a target UE from a GMLC. The R-GMLC verifies the identity of the LCS client and its subscription to the LCS service requested and derives the MSISDN or IMSI of the target UE to be located and the LCS QoS from either subscription data or data supplied by the LCS client.
Step 2.
If the R-GMLC already knows IMSI for the particular MSISDN, (e.g. from a previous location request) and the VMSC/MSC server address, SGSN address or MME address, this step and step 3 may be skipped. Otherwise, the R-GMLC sends a SEND_ROUTING_INFO_FOR_LCS message to the home HLR/HSS of the target UE to be located with the IMSI or MSISDN of this UE.
Step 3.
The HLR/HSS verifies whether the R-GMLC is authorized to request UE location information. If not, an error response is returned.
Otherwise the HLR/HSS returns one or several of the network addresses of the current SGSN and/or VMSC/MSC server and/or current MME and whichever of the IMSI and MSISDN that was not provided in step 2. The HLR/HSS also returns the address of the V-GMLC associated with the serving nodes, if available.
Step 4.
In the cases when the R-GMLC did not receive the address of the V-GMLC, or when the V-GMLC address is the same as the R-GMLC address, or when both PLMN operators agree not to use the Lr interface, the R-GMLC does not send the location request to the V-GMLC and the step 6 is skipped. In this case, the R-GMLC sends the location service request message directly to the serving node.
If the R-GMLC received the address of the V-GMLC from the HLR/HSS and the V-GMLC address is different from the R-GMLC address, the R-GMLC sends the location request to the V-GMLC. The location request shall contain one or several of the network addresses of the current SGSN and/or MSC/VLR, the IMSI and MSISDN of the target UE and the privacy override indicator. The V-GMLC first authenticates that the location request is allowed from this GMLC, PLMN or from this country. If not, the positioning request is rejected and an error response is returned. Otherwise, it sets the privacy indicator to "not allowed" and includes it with the POI in the Provide Subscriber Location message.
Step 5.
If the GMLC receives only the MSC/VLR address, the MT LR proceeds as the CS-MT-LR procedure described in clause 9.1.2. If the GMLC receives only the SGSN address, the MT LR proceeds as the PS-MT-LR procedure described in clause 9.1.6. If the GMLC receives only the MME address, the MT LR proceeds as the EPC-MT-LR procedure described in clause 9.1.15. If the GMLC receives several of the following addresses, SGSN, VMSC, MSC Server and/or MME, it has to decide where to send the location request. In any case the serving node checks for POI applicability.
Step 6.
The V-GMLC sends the location service response to the R-GMLC. The location service response may contain the information about the positioning method used. The V-GMLC may record charging information.
Step 7.
R-GMLC sends the location service response to the LCS client. If the LCS client requires it, the R-GMLC may first transform the universal location co-ordinates provided by the SGSN or MSC/MSC server into some local geographic system. The location service response from the GMLC to the LCS client may contain the information about the positioning method used. After receiving (stage 3) acknowledgement from the LCS client, the R-GMLC may record charging information both for the LCS client and inter-network revenue charges from the SGSN or MSC/MSC server's network.
The detailed CS-MT-LR, PS-MT-LR and EPC-MT-LR procedures in step 5 of Figure 9.1A are described in clauses 9.1.2, 9.1.6 and 9.1.15.
Up

9.1.1.1  LCS Authorisation request  p. 64

If the UE subscribers LCS privacy information is kept in the PPR the GMLC (H-GMLC) shall send a LCS Authorisation request to PPR, see Figure 9.1B.
Reproduction of 3GPP TS 23.271, Fig. 9.1B: LCS authorisation in PPR
Figure 9.1B: LCS authorisation in PPR
Up
Step 1.
The GMLC sends the LCS authorisation request to the PPR. The LCS authorisation request carries the type of location information requested (e.g. current location), the LCS client type, the UE subscriber's identity and indication whether the request is call/session related or call/session unrelated. The UE subscriber's identity can be one or both of MSISDN and IMSI. If PMD functionality is integrated in PPR, the LCS authorization request may carry the pseudonym of the target UE, instead of the verinym. In case GMLC received the LCS client's called party number or the APN-NI of the target mobile's session, GMLC shall request both call/session related and call/session unrelated privacy checks in PPR. In case GMLC did not receive the LCS client's called party number or the APN-NI of the target mobile's session, GMLC requests only a call/session unrelated privacy check in PPR. For a value added LCS client, the message shall carry the client's name, the external identity of the LCS client and the requestor identity (if that is both supported and available). Moreover the message may also carry the Service Type and the Codeword. This message shall also carry the LCS capabilities of the SGSN or VMSC/MSC server.
In case the additional privacy check was requested to be performed after the positioning procedure the LCS Authorisation Request shall also include the location estimate.
Step 2.
If the LCS authorization request contains the pseudonym of the target UE, the PPR with PMD functionality seeks to determine the verinym of the target UE. PPR performs the privacy check based on the target UE's privacy profile. The result of that privacy check is sent to GMLC in the LCS Authorisation response. If the location request is to be barred, the PPR shall send an indication of this within the LCS Authorisation response and no other indicators. If requested by the GMLC the PPR shall include two privacy check results for the LCS Authorisation response, both call/session related and call/session unrelated privacy check results. The response may also contain information if an additional privacy check is needed when the GMLC has received the location information of the target UE (e.g. if the target UE allows its location information to be given to the LCS client only when it is located in certain areas).
If the LCS authorisation request contains the pseudonym of the target UE and the PPR has integrated PMD functionality, the PPR shall return the target UE's IMSI and/or MSISDN corresponding to the pseudonym in the LCS authorisation response.
If PPR received information that the visited MSC/SGSN is pre Rel-6 it shall select a pseudo external ID which shall carry the response of the privacy check. For more information on pseudo external Ids, see Annex C.
Up

9.1.1.2  LCS Privacy Profile Update  p. 65

If the UE subscribers privacy information has been changed in the PPR the LCS Privacy Profile Update shall be send to the GMLC (H-GMLC), see Figure 9.1C.
Reproduction of 3GPP TS 23.271, Fig. 9.1C: PPR notification to GMLC about LCS privacy profile change
Figure 9.1C: PPR notification to GMLC about LCS privacy profile change
Up
Step 1.
In case subscriber changed his privacy profile information in the PPR the LCS Privacy Profile Update shall be send to the GMLC (H-GMLC). The message shall carry the identity of the UE subscriber.
Step 2.
GMLC acknowledges that it received the notification

9.1.1.3  LCS identity request  p. 65

The GMLC may request the verinym of the UE from the PMD, see Figure 9.1D.
Reproduction of 3GPP TS 23.271, Fig. 9.1D: LCS identity request
Figure 9.1D: LCS identity request
Up
Step 1.
The GMLC sends the pseudonym to its associated PMD and requests the corresponding verinym of the target UE from PMD.
Step 2.
The PMD shall map or decrypt (e.g. using the private key of the operator) the target UE's pseudonym to the corresponding verinym, i.e. IMSI and /or MSISDN, to be included in the Identity Response.

Up   Top   ToC