Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.271  Word version:  17.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.2  Circuit Switched Mobile Terminating Location Request (CS-MT-LR)p. 66

Figure 9.2 illustrates general network positioning for LCS clients external to the PLMN. In this scenario, it is assumed that the target UE is identified using either an MSISDN or IMSI.
Reproduction of 3GPP TS 23.271, Fig. 9.2: Network Positioning for a CS-MT-LR
Up

9.1.2.1  Location Preparation Procedurep. 67

Step 1.
Common PS and CS MT-LR procedure as described in clause 9.1.1.
Step 2.
The GMLC sends a PROVIDE_ SUBSCRIBER _LOCATION message to the MSC/MSC server indicated by the HLR/HSS. This message carries the type of location information requested (e.g. current location and optionally, velocity), the UE subscriber's IMSI, LCS QoS information (e.g. accuracy, response time) and an indication of whether the LCS client has the override capability. For a call related location request, the message also carries the LCS client's called party number. For a value added LCS client, the message shall carry the client name, the external identity of the LCS client (or the pseudo external identity) and the Requestor Identity (if that is both supported and available). Also the message may carry the type of the LCS client name and also the type of the Requestor identity if the requestor identity was included. For a PLMN operator LCS client, the message shall carry the internal identity of the LCS client. Moreover the message may also carry the Service Type. If the result of the privacy check at H-GMLC/PPR indicated that the codeword shall be sent to the UE user, the message may carry also the codeword received from the LCS client. For a PLMN operator LCS client, the message shall carry the internal identity of the LCS client. If the Requestor Identity is provided, the GMLC shall send it as separate information. In addition, in order to display the requestor identity in case of pre rel-5 network elements (i.e. MSC and/or UE), the requestor identity may be also added to the LCS client name by the GMLC. When the Requestor identity is added to the LCS client name the practise described in the Annex D should be followed. The message also shall carry the indicators of privacy related action which is described in clause 9.5.4 , if it is provided by H-GMLC.
Step 3.
If the GMLC is located in another PLMN or another country, the VMSC/MSC server first authenticates that a location request is allowed from this PLMN or from this country. If not, an error response is returned. If the PSL message from the GMLC contains the indicators of privacy related action, the VMSC/MSC server determines a required privacy related action as described in Annex A.3. If the PSL message from the GMLC does not include the indicators of privacy related action, the VMSC/MSC server then verifies LCS barring restrictions in the UE user's subscription profile in the MSC server. In verifying the barring restrictions, barring of the whole location request is assumed if any part of it is barred or any requisite condition is not satisfied. If LCS is to be barred without notifying the target UE and a LCS client accessing a GMLC in the same country does not have the override capability, an error response is returned to the GMLC.
Otherwise, if the UE is in idle mode, the Core Network performs paging, authentication and ciphering. The MSC will page a GPRS attached UE either through A/Iu or Gs interface, depending on the presence of the Gs interface (see Note 2). The UE will inform the network about its LCS capabilities, as described in clause 6.3.4. If the UE is instead in dedicated mode, the VMSC/MSC server will already have UE classmark information. In GSM this is supported by controlled early classmark sending.
Step 4.
If the location request comes from a value added LCS client and the indication of requested privacy related action or the UE subscription profile indicates that the UE must either be notified or notified with privacy verification and the UE supports notification of LCS (according to the UE Capability information), an LCS Location Notification Invoke message is sent to the target UE indicating the type of location request from the LCS Client (e.g. current location or "current or last known location") and the identity of the LCS client, the Requestor Identity (if that is both supported and available) and whether privacy verification is required. Also the message may indicate the type of the LCS client name and also the type of the Requestor identity if the requestor identity was included. Moreover, the message may carry also the service type and the codeword.
Optionally, the VMSC/MSC server may, after sending the LCS Location Notification Invoke message continue in parallel the location process, i.e. continue to step 6 without waiting for a LCS Location Notification Return Result message in step 5.
Step 5.
The target UE notifies the UE user of the location request. If privacy verification was requested, the target UE indicates to the UE user whether the location request will be allowed or not allowed in the absence of a response and waits for the user to grant or withhold permission. The UE then returns an LCS Location Notification Return Result to the VMSC/MSC server indicating, if privacy verification was requested, whether permission is granted or denied. Optionally, the LCS Location Notification Return Result message can be returned some time after step 4, but before step 9. If the UE user does not respond after a predetermined time period, the VMSC/MSC server shall infer a "no response" condition. The VMSC/MSC server shall return an error response to the GMLC if privacy verification was requested and either the UE user denies permission or there is no response with the UE subscription profile indicating barring of the location request in the absence of a response.
Step 6.
The MSC/MSC server sends a Location Request message to RAN. This message includes the type of location information requested and requested QoS and, in GSM, the UE's location capabilities.
Up

9.1.2.2  Positioning Measurement Establishment Procedurep. 68

Step 7.
RAN determines the positioning method and instigates the particular message sequence for this method, as specified in UTRAN Stage 2, TS 25.305 and GERAN Stage 2, TS 43.059.

9.1.2.3  Location Calculation and Release Procedurep. 68

Step 8.
When a location estimate best satisfying the requested QoS has been obtained, RAN returns it to the MSC/MSC server in a Location Report message. RAN shall in its response include an indication whether the obtained location estimate satisfies the requested accuracy or not. The information about the positioning method used may be returned with the location estimate. If a location estimate could not be obtained, RAN returns a Location Report message containing a failure cause and no location estimate.
Step 9.
The MSC/MSC server returns the location information, its age and obtained accuracy indication to the GMLC, if the VMSC/MSC server has not initiated the Privacy Verification process in step 4. If step 4 has been performed for privacy verification, the VMSC/MSC server returns the location information only, if it has received a LCS Location Notification Return Result indicating that permission is granted. In these cases, the information about the positioning method used may be sent with the location information. If a LCS Location Notification Return Result message indicating that permission is not granted is received, or there is no response, with the requested privacy action or the UE subscription profile indicating barring of location in the absence of a response, the VMSC/MSC server shall return an error response to the GMLC. If RAN did not return a successful location estimate, but the privacy checks in steps 4 - 5 were successfully executed, the VMSC/MSC server may return the last known location of the target UE if this is known and the LCS client is requesting the current or last known location. The MSC/MSC server may then release the Mobility Management connection to the UE, if the UE was previously idle, and the MSC/MSC server may record charging information.
Step 10.
Common MT-LR procedure in PS and CS domain as described in clause 9.1.1.
Up

9.1.3  CS-MT-LR without HLR Queryp. 68

Figure 9.3 illustrates current or last known location requests for an emergency services call, where an emergency services client (i.e., a Public Safety Answering Point) identifies the target UE and the serving GMLC using correlation information that were previously provided to it by the VMSC. In North America, this correlation information is provided by either an NA-ESRK, or an MSISDN and NA-ESRD. In E.U. it is provided through the ISUP/BICC IAM message with location number parameter set to MSC number and the calling party number parameter set to MSISDN. The signalling used to provide the correlation information to the PSAP is out of scope of this TS, but is presumed to occur on the signalling for the call. This allows the requesting V-GMLC to request location from the VMSC without first querying the home HLR of the target UE. This scenario therefore supports location of emergency callers from roamers or SIM-less emergency calls, or non-registered (U)SIM emergency calls, and requires that the initial location, as well as UE and VMSC identifying information had been pushed to the GMLC as per clause 9.1.5 (or clause 9.1.5A for North America). In North America, additional requirements are found in [32].
Reproduction of 3GPP TS 23.271, Fig. 9.3: Positioning for a Emergency Services MT-LR without HLR Query
Up
Step 1.
Same as step 1 in Figure 9.1 but with the LCS client (PSAP) identifying first the target UE and the serving V-GMLC by previously supplied correlation information for the emergency call.
Step 2.
The GMLC may determine the VMSC from correlation information received from the PSAP, or from stored information for the target UE (e.g. from a prior location estimate delivery from the VMSC/MSC server). In North America, the GMLC determines the VMSC using the NA-ESRK or NA-ESRD - with use of the NA-ESRK taking priority over that of the NA ESRD. The MAP_PROVIDE_SUBSCRIBER_LOCATION message sent to the VMSC carries the MSISDN and, if provided, the IMSI and IMEI for the target UE, as well as the required QoS and an indication of a location request from an emergency services client. The VMSC identifies the target UE using the IMSI or MSISDN and, if provided, the IMEI. In case of a SIM-less emergency call, or non-registered (U)SIM emergency call, the IMEI shall be always sent and the MSISDN may be populated with a non-dialable callback number as specified in clause 6.4.3.
Step 3.
The MSC verifies that UE privacy is overridden by the emergency services provider and that positioning is not prevented for other reasons (e.g. unreachable UE, inapplicable call type to the UE). The VMSC then sends a Location Request to the RAN, as for a normal MT-LR.
Step 4.
RAN performs positioning as for a normal CS-MT-LR.
Step 5.
RAN returns a location estimate to the VMSC as for a normal CS-MT-LR.
Step 6.
Same as step 9 for a normal CS-MT-LR.
Step 7.
Same as step 10 for a normal CS-MT-LR.
Up

9.1.4  CS-MT-LR and PS-MT-LR for a previously obtained location estimatep. 69

Every time the location estimate of a target UE subscriber is returned by the RAN to the VMSC, MSC Server or SGSN, the corresponding entity may store the location estimate together with a time stamp. The MSC/MSC server may store this information in the subscriber's MSC server record. Also when the location estimate of a target UE subscriber is returned to the H-GMLC, the H-GMLC may store the location estimate together with the age in the subscriber's record.
The time stamp is the time at which the location estimate is stored at the corresponding entity i.e. after the RAN returns the location estimate to the VMSC, MSC Server or SGSN. The time stamp indicates the "age" of the location estimate.
Up

9.1.4.1  Initial Locationp. 70

In the context of an originating emergency call the location estimate and the associated time stamp at the commencement of the call set-up is referred to as "initial location".

9.1.4.2  Current Locationp. 70

After a location attempt has successfully delivered a location estimate and its associated time stamp, the location estimate and time stamp is referred to as the "current location" at that point in time.

9.1.4.3  Last known Locationp. 70

Depending on national regulations, the current location estimate and its associated time stamp may be stored in MSC/VLR, MSC Server, SGSN, or in H-GMLC and until replaced by a later location estimate and a new time stamp is referred to as the "last known location". The last known location may be distinct from the initial location - i.e. more recent.

9.1.4.4  Security and Privacyp. 70

The collection and/or the release of the last known and initial location estimate of the target UE may not be allowed by national option. The handling of security and privacy of the target UE with regard to returning the last known or initial location estimate of the target UE shall be the same as when the target UE is reachable for positioning. (i.e. the requesting LCS client is authorized and the privacy of the target UE is secured before the VMSC/MSC server check the MSC server status of the target UE (i.e. whether the UE is marked as attached or detached in the MSC server). A similar status check apply for SGSN and MSC Server.
Up

9.1.4.5  Failing to locate the target UEp. 70

In case of a "Detached" or "Not Reachable" target UE, the last known location and a time stamp stored at the VLR, MSC Server or SGSN, may be returned to a LCS client requesting location information if the LCS client specifically requested the current or last known location. This does not apply to a value added LCS client where the target UE subscribes to notification of the location request: if the notification cannot be performed, the VMSC, MSC Server or SGSN shall reject the location request.
When a request for location information is received at the VMSC, MSC Server or SGSN, the request shall indicate whether the "last known location of the target UE" should be returned in case of a "detached" or "not reachable" target UE.
If the VLR, MSC Server or SGSN has a valid copy of the subscriber's permanent data and the target UE's privacy settings are such that positioning is allowed, then the following two cases can occur.
Up
9.1.4.5.1  Target UE is "Not Reachable"p. 70
If the target UE is marked as "attached" in the VLR, MSC Server or SGSN, the corresponding entity orders paging of the target UE. If paging fails, due to target UE being "not reachable" then the corresponding VMSC, MSC Server or SGSN shall check whether the LCS client has requested "last known location" in case of "not reachable" target UE.
If such a request exists and notification to the target UE does not apply for a value added LCS client, the VMSC, MSC Server or SGSN shall include the last known location together with the time stamp available in its response to the request for location information.
An indicator of "last known location" returned shall be marked at the CDR at VMSC, MSC Server or SGSN correspondingly.
Up
9.1.4.5.2  Target UE is "Detached"p. 71
If the target UE is marked as "detached" in the VLR, MSC Server or SGSN, the corresponding entity shall check whether the LCS client has requested "last known location" in case of "detached" target UE.
If such a request exists and notification to the target UE does not apply for a value added LCS client, the VMSC, MSC Server or SGSN includes the "last known location" together with the time stamp available in its response to the request for location information.
An indicator of "last known location" returned shall be marked at the CDR at VMSC, MSC Server or SGSN.
Up
9.1.4.5.3  Target UE is Reachable but Positioning Failsp. 71
If the target UE is reachable (e.g. paging succeeds), but the VMSC, MSC Server or SGSN is unable to obtain a current location estimate, then the corresponding entity shall check whether the LCS client has requested "last known location".
If such a request exists and notification to the target UE either does not apply or was successfully executed for a value added LCS client, the VMSC, MSC Server or SGSN includes the "last known location" together with the time stamp available in its response to the request for location information. An indicator of "last known location" returned shall be marked at the CDR at VMSC.
Up
9.1.4.5.4  MSC Server or SGSN Target UE is "Purged"p. 71
If the target UE is marked as "Purged" in HLR/HSS, then an indication "Absent Subscriber" is returned to the GMLC.

Up   Top   ToC