8 General network location procedures

23.1713GPPFunctional descriptionLocation Services (LCS)Release 1999Stage 2 (UMTS)TS

8.1 State description for GMLC

8.1.1 GMLC states

8.1.1.1 NULL State

In the NULL state, a particular location request from some LCS client either has not been received yet or has already been completed. After a location request is received from a LCS client, the GMLC remains in the NULL state while the identity of the client and nature of its location request are verified. While the NULL state exists conceptually, it need not be represented explicitly in the GMLC.

8.1.1.2 INTERROGATION State

In this state, the GMLC has sent an interrogation to the home HLR of the UE to be located and is awaiting a response giving the 3G-VMSC and/or 3G-SGSN address and IMSI for this UE.

8.1.1.3 LOCATION State

In this state, the GMLC has sent a location request to the 3G-VMSC/3G-SGSN serving the UE to be located and is awaiting a response containing a location estimate.

8.1.2 State functionality

8.1.2.1 State Transitions

Figure 8.1: State Transitions in the GMLC

Moving from NULL to INTERROGATION state:

If the GMLC does not know the 3G-VMSC/3G-SGSN address or IMSI when it receives a location service request from some LCS client, it moves from the NULL state to the INTERROGATION state and sends a request to the UE’s home HLR for the 3G-VMSC/3G-SGSN address and IMSI.

Moving from NULL to LOCATION state:

If the GMLC already knows both the 3G-VMSC/3G-SGSN address and UE IMSI when it receives a location service request from some LCS client (e.g. from information retained for an earlier location request for the same UE), it moves from the NULL state to the LOCATION state and sends a location request to the 3G-VMSC/3G-SGSN.

Moving from INTERROGATION to LOCATION state:

After the GMLC, in the INTERROGATION state, receives the 3G-VMSC/3G-SGSN address and IMSI from the home HLR, it enters the LOCATION state and sends a location request to the 3G-VMSC of the UE being located.

Moving from LOCATION to NULL state:

After the GMLC receives a location estimate response from the 3G-VMSC/3G-SGSN, it forwards the location estimate to the requesting LCS client and re-enters the NULL state.

8.1.2.2 INTERROGATION Timer Function

The GMLC runs a timer while in the INTERROGATION state to limit the amount of time waiting for an interrogation response from the HLR. If the timer expires before an interrogation response is received, the GMLC indicates a location failure to the LCS client and re-enters the NULL state.

8.1.2.3 LOCATION Timer Function

The GMLC runs a timer while in the LOCATION state to limit the amount of time waiting for a location estimate response from the 3G-VMSC/3G-SGSN. If the timer expires before a response is received, the GMLC indicates a location failure to the LCS client and re-enters the NULL state.

8.2 State description for 3G-VMSC/VLR

8.2.1 3G-VMSC States

8.2.1.1 LCS IDLE State

In this state, the 3G-VMSC location service is inactive for a particular UE. The UE may be known in the VLR (except for a USIM less or SIM less Emergency call or where the UE record has been cancelled or lost in the VLR), but there may not be an active Mobility Management or Radio Resource connection to the UE.

8.2.1.2 LOCATION State

In this state, the 3G-VMSC is awaiting a response from SRNC after requesting the location for a particular UE. In this state, a RRC and a Mobility Management connection and the LCS layer of the Connection Management connection to the target UE will be active – allowing the SRNC and UE to exchange positioning related messages for mobile based and mobile assisted position methods.

8.2.2 State Functionality

8.2.2.1 State Transitions

Figure 8.2: State Transitions in the 3G-VMSC

Moving from LCS IDLE to LOCATION state:

After a request has been received to locate a particular UE and the UE subscription options have been verified, a location request is sent to the SRNC associated with the serving cell of the UE to be located: the 3G-VMSC then enters the LOCATION state. Before entering this state, the 3G-VMSC must have setup a Mobility Management connection to the UE if none was previously active. The mobile is paged and authenticated before positioning.

Moving from LOCATION to LCS IDLE state:

After the return of a location estimate result from SRNC, the 3G-VMSC shall re-enter IDLE state.

8.2.2.2 LOCATION Timer Function

The 3G-VMSC runs a timer while in the LOCATION state to limit the amount of time waiting for a location response from the RNC. If the timer expires before such information is received, the 3G-VMSC indicates a location failure to the original requesting entity and re-enters IDLE state.

8.3 (void)

8.4 State description for RNC in UTRAN

The state description of RNC in UTRAN is specified in TS 25.305.

8.5 Iu Signaling Connection

Before 3G-MSC can request location information of a Target UE from SRNC, an Iu Signaling Connection must have been established between 3G-MSC and SRNC. The 3G-MSC sends a RANAP Location Reporting control message to the SRNC, SRNC determines the location of the target UE related to this Iu Signalling Connection and sends a Location Report to 3G-MSC over the same Iu Signalling Connection.

8.6 General Network Positioning Procedures

The generic network positioning procedure of providing the location information of an UE subscriber can be partitioned into the following procedures:

Location Preparation Procedure

This generic procedure is concerned with verifying the privacy restrictions of the UE subscriber, reserving network resources, communicating with the UE to be located and determining the positioning method to be used for locating the UE subscriber based on the requested QoS and the UE and network capabilities.

Positioning Measurement Establishment Procedure

This procedure is concerned with performing measurements by involving the necessary network and/or UE resources. Depending on the positioning method to be used for locating the UE the internals of this procedure can be positioning method dependent. The procedure is completed with the end of the positioning measurements.

Location Calculation and Release Procedure

This generic procedure is initiated after the measurements are completed and is concerned with calculating the location of the UE and releasing all network and/or UE resources involved in the positioning.

8.7 Mobile Terminating Location Request

[Editorial note: The GPRS specification TS 23.060 requires periodical UE position reporting (GSM Phase 1 allows only a single response to one query). The MT signaling flows below should be enhanced to show "multiple responses to one query". It should be noted that the connection may be closed down between responses.]

8.7.1 Circuit Switched Mobile Terminating Location Request
(CS-MT-LR)

Figure 8.4 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.

Figure 8.4: General Network Positioning for a MT-LR

8.7.1.1 Location Preparation Procedure

  1. An external LCS client requests the current location of a target UE from a GMLC. The 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. For a call related location request, the GMLC obtains and authenticates the called party number of the LCS client [(refer to Annex A for further details)]. If location is required for more than one UE, or if periodic location is requested, steps 2 to 12 below may be repeated.
  2. If the GMLC already knows both the 3G-VMSC location and IMSI for the particular MSISDN (e.g. from a previous location request), this step and step 3 may be skipped. Otherwise, the GMLC sends a MAP_SEND_ROUTING_INFO_FOR_LCS message to the home HLR of the target UE to be located with either the IMSI or MSISDN of this UE.
  3. The HLR verifies that the calling party SCCP address of the GMLC corresponds to a known UMTS network element that is authorized to request UE location information. The HLR then returns the current 3G-VMSC address and whichever of the IMSI and MSISDN was not provided in step (2) for the particular UE.
  4. The GMLC sends a MAP_PROVIDE_ SUBSCRIBER _LOCATION message to the 3G-MSC indicated by the HLR. This message carries the type of location information requested (e.g. current location), 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 if available and, for a call unrelated location request, the identity of the LCS client. In other cases, inclusion of the client name and/or identity is optional.
  5. If the GMLC is located in another PLMN or another country, the 3G-VMSC first authenticates that a location request is allowed from this PLMN or from this country. If not, an error response is returned. The 3G-VMSC then verifies LCS barring restrictions in the UE user’s subscription profile in the VLR. 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. If the target UE supports any UE based or UE assisted positioning method(s), the UE will also provide the SRNC and MSC with the positioning method(s) it supports via controlled early classmark sending. If the UE is instead in dedicated mode, the VMSC will already have any early classmark information.

    [GSM LCS: If the target UE has an established circuit call other than speech, the location request may be denied and an error response is then returned to the GMLC. If the location request is allowed for a non-speech circuit call, it shall be up to the SRNC to decide, on the basis of the applicable position methods and requested QoS, whether positioning is possible. [this is FFS]]

  6. If the location request comes from a value added LCS client and 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 Classmark 2), an LCS Location Notification Invoke message is sent to the target UE indicating the type of location request (e.g. current location) and the identity of the LCS client and whether privacy verification is required. For a call related location request, the LCS client identity shall be set to the LCS client’s called party number if no separate LCS client identity was received from the GMLC.Optionally, the VMSC may after sending the LCS Location Notification Invoke message continue in parallel the location process, i.e. continue to step 8 without waiting for a LCS Location Notification Return Result message in step 7.
  7. 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 3G-VMSC 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 6, but before step 11. If the UE user does not respond after a predetermined time period, the VMSC shall infer a "no response" condition. The 3G-VMSC 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.
  8. The 3G-MSC sends a RANAP Reporting Control message to the SRNC. This message includes the type of location information requested, the UE’s location capabilities and requested QoS.

8.7.1.2 Positioning Measurement Establishment Procedure

  1. If the requested location information and the location accuracy within the QoS can be satisfied based on cell coverage, cell ID and, if available, RTT value, the SRNC may send a RANAP Location Report immediately. Otherwise, the SRNC determines the positioning method and instigates the particular message sequence for this method, as specified in UTRAN Stage 2 [1]. If the position method returns position measurements, the SRNC uses them to compute a location estimate. If there has been a failure to obtain position measurements, the SRNC may use the current cell information and, if available, RTT value to derive an approximate location estimate. If the UE returns an already computed location estimate to SRNC using an UE based position method, the SRNC may verify consistency with the current cell and, if available, RTT value. If the location estimate so obtained does not satisfy the requested accuracy or the location attempt failed, e.g. due to missing data, and sufficient response time still remains, the SRNC may instigate a further location attempt using the same (e.g. providing more assistance data to UE) or a different position method. If a vertical location co-ordinate is requested but the SRNC can only obtain horizontal co-ordinates, these may be returned.

    In case IPDL is used the SRNC may send a massage to the BS/Node B to configure the power cease period of the Node Bs involved in the positioning process. However, if the IPDL alignment is specified in lower layers e.g. layer 1 then the functional split of IPDL processing may partly included in network elements functionality.

8.7.1.3 Location Calculation and Release Procedure

  1. When a location estimate best satisfying the requested QoS has been obtained, the SRNC returns it to the 3G-MSC in a Location Report message. If a location estimate could not be obtained, the SRNC returns a Location Report message containing a failure cause and no location estimate.
  2. The 3G-MSC returns the location information and its age to the GMLC, if the VMSC has not initiated the Privacy Verification process in step 6. If step 6 has been performed for privacy verification, the VMSC returns the location information only, if it has received a LCS Location Notification Return Result indicating that permission is granted. If a LCS Location Notification Return Result message indicating that permission is not granted is received, or there is no response, with the UE subscription profile indicating barring of location in the absence of a response, the VMSC shall return an error response to the GMLC. If the SRNC did not return a successful location estimate, but the privacy checks in steps 6-7 were successfully executed, the 3G-VMSC 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 VLR may then release the Mobility Management connection to the UE, if the UE was previously idle, and the 3G-MSC may record billing information.
  3. The GMLC returns the UE location estimate to the requesting LCS client. If the LCS client requires it, the GMLC may first transform the universal location co-ordinates provided by the 3G-MSC into some local geographic system. The GMLC may record billing for both the LCS client and inter-network revenue charges from the 3G-MSC’s network.

8.7.1a MT-LR without HLR Query – applicable to North America Emergency Calls only

Figure 8.4a illustrates location for a North American Emergency Services call, where an emergency services client identifies the target UE using an IMSI, MSISDN or NA-ESRK plus, possibly IMEI, that were previously provided to it by the VMSC. The emergency services client also identifies the VMSC to the GMLC by providing an NA-ESRD or NA-ESRK or by referring to information for the target UE already stored in the GMLC. This allows the GMLC to request location from the VMSC without first querying the home HLR of the target UE. This is necessary when the home HLR either cannot be identified (e.g. client provides an NA-ESRK but not IMSI or MSISDN) or does not support the LCS query procedure.

Figure 8.4a: Positioning for a Emergency Services MT-LR without HLR Query

1) Same as step 1 in figure 8.4 but with the LCS client identifying first the target UE by an IMSI, MSISDN or NA-ESRK and possibly IMEI and, second, the VMSC by an NA-ESRK or NA-ESRD.

2) If the GMLC already has stored information for the target UE (e.g. from a prior location estimate delivery to the LCS client), the GMLC may determine the VMSC from this information. Otherwise, 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 IMSI, if available or MSISDN and, if provided, the 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.

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.

4) RAN performs positioning as for a normal MT-LR.

5) RAN returns a location estimate to the VMSC as for a normal MT-LR.

6) Same as steps 1-5 for a normal MT-LR.

7) Same as steps 1-6 for a normal MT-LR.

8.7.2 MT-LR and PS-MT-LR for a previously obtained location estimate

Every time the location estimate of a target UE subscriber is returned by the SRNC to the 3G-VMSC or 3G-SGSN, the 3G-VMSC or 3G-SGSN may store the location estimate together with a time stamp. The 3G-MSC may store this information in the subscriber’s VLR record.

The time stamp is the time at which the location estimate is stored at the VLR or 3G-SGSN i.e. after the SRNC returns the location estimate to the 3G-VMSC or 3G-SGSN. The time stamp indicates the "age" of the location estimate.

8.7.2.1 Initial Location

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".

8.7.2.2 Current Location

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.

8.7.2.3 Last known Location

The current location estimate and its associated time stamp are stored in MSC/VLR or 3G-SGSN 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.

8.7.2.4 Security and Privacy

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 3G-VMSC check the VLR status of the target UE (i.e. whether the UE is marked as attached or detached in the VLR) or the 3G-SGSN checks the status of the target UE.

8.7.2.5 Failing to locate the target UE

In case of a "Detached" or "Not Reachable" target UE, the last known location and a time stamp stored at the VLR or 3G-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 3G-VMSC or 3G-SGSN shall reject the location request.

NOTE: Due to CAMEL, the 3G-MSC/VLR may already be storing other location information parameters like location number, service area identity and VLR number in the subscriber’s VLR record.

When a request for location information is received at the 3G-VMSC or 3G-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 or 3G-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.

8.7.2.5.1 Target UE is "Not Reachable"

If the target UE is marked as "attached" in the VLR or 3G-SGSN, the 3G-VMSC or 3G-SGSN orders paging of the target UE. If paging fails, due to target UE being "not reachable" then 3G-VMSC or 3G-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 3G-VMSC or 3G-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 3G-VMSC or 3G-SGSN.

8.7.2.5.2 Target UE is "Detached"

If the target UE is marked as "detached" in the VLR or 3G-SGSN, the 3G-VMSC or 3G-SGSN 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 3G-VMSC or 3G-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 3G-VMSC or 3G-SGSN.

8.7.2.5.3 Target UE is Reachable but Positioning Fails

If the target UE is reachable (e.g. paging succeeds), but the VMSC or 3G-SGSN is unable to obtain a current location estimate, the VMSC or 3G-SGSN 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 or 3G-SGSN includes the "last known location" together with the time stamp available in its response to the request for location information.

8.7.2.5.4 An indicator of "last known location" returned shall be marked at the CDR at VMSC or 3G‑SGSN.Target UE is "Purged"

If the target UE is marked as "Purged" in HLR, then an indication "Absent Subscriber" is returned to the GMLC.

8.7.3 Network Induced Location Request (NI-LR)

Figure 8.5 illustrates positioning for an emergency service call.

Figure 8.5: Positioning for a NI-LR Emergency Service Call

8.7.3.1 Location Preparation Procedure

1) An initially idle UE requests RRC setup (RACH) Service Request indicating a request for an Emergency Service call to the 3G-VMSC via the SRNC.

2) The SRNC shall convey the CM service request across the Iu-interface. (Before having a CM connection there must be a RRC connection.) The UE may identify itself using a TMSI, IMSI or IMEI.

3) The emergency call procedure is applied. The 3G-VMSC determines based on the serving cell the appropriate emergency services client. The 3G-VMSC, SRNC and UE continue the normal procedure for emergency call origination towards that emergency services client. Depending on local regulatory requirements, the sending of call setup information into the PSTN may be delayed until either the UE’s location has been obtained or the location attempt has failed or a PLMN defined timer has expired before location was obtained. If the serving cell serves an area that contains the service domain of multiple emergency services clients, the VMSC/MSC server may delay call setup and invoke location based routing procedures described in section 8.7.3A. Call setup information sent into the PSTN may include the UE location (if already obtained) plus information that will enable the emergency service provider to request UE location at a later time (e.g. NA-ESRD or NA-ESRK in North America).

4) At any time after step 2 and after sufficient time has been allowed to enable completion of early classmark sending to the SRNC and MSC where the UE supports any UE assisted or UE based positioning method(s), the 3G-VMSC may initiate procedures to obtain the UE’s location. These procedures may run in parallel with the emergency call origination. The 3G-VMSC sends a RANAP Location Reporting Control message to the SRNC associated with the UE’s current location area (see step 8 for a MT-LR). This message includes indication about the UE’s location capabilities, and the QoS required for an emergency call.

8.7.3.2 Positioning Measurement Establishment Procedure

5) The actions described under step 9 for a MT-LR are performed. If a speech compatible traffic channel is established, the same traffic channel may be used for both the positioning and the emergency call. In that case, the traffic channel may be allocated by either the positioning procedure or emergency call origination procedure.

8.7.3.3 Location Calculation and Release Procedure

6) When a location estimate best satisfying the requested QoS has been obtained, the SRNC returns it to the 3G-VMSC.

7) Depending on local regulatory requirements, the 3G-VMSC may send a MAP Subscriber Location report to a GMLC associated with the emergency services provider to which the emergency call has been or will be sent. This message shall carry any location estimate returned in step 6, the age of this estimate and may carry the MSISDN, IMSI and IMEI of the calling UE. In North America, any NA-ESRD and any NA-ESRK that may have been assigned by the 3G-VMSC shall be included. The message shall also indicate the event that triggered the location report. If location failed (i.e. an error result was returned by the SRNC in step 6), an indication of failure rather than a location estimate may be sent to the GMLC: the indication of failure is conveyed by not including a location estimate in the MAP Subscriber Location Report.

8) The GMLC acknowledges receipt of the location information. For a North American Emergency Services call, the GMLC shall store the location information for later retrieval by the emergency services LCS client.

9) The GMLC may optionally forward the information received in step 8 to the emergency services LCS client. For a North American emergency services call the client is expected to obtain the location information by requesting it from the GMLC.

10) At some later time, the emergency services call is released.

11) For a North American Emergency Services call, the 3G-MSC sends another MAP Subscriber Location Report to the GMLC. This message may include the same parameters as before except that there is no position estimate and an indication of emergency call termination is included.

12) The GMLC acknowledges the 3G-MSC notification and may then release all information previously stored for the emergency call.

8.7.3A NI-LR using Location Based Routing – applicable to North American Emergency Calls only

Figure 8.5A illustrates positioning for an emergency service call using location based routing.

Figure 8.5A: Positioning for a NI-LR Emergency Service Call using Location Based Routing

8.7.3A.1 Location Preparation Procedure

1) An initially idle UE requests RRC setup (RACH) Service Request indicating a request for an Emergency Service call to the 3G-VMSC via the SRNC.

2) The SRNC shall convey the CM service request across the Iu-interface. (Before having a CM connection there must be a RRC connection.) The UE may identify itself using a TMSI, IMSI or IMEI.

3) The 3G-VMSC determines that the serving cell serves an area that contains portions of multiple emergency services zones. Therefore, the 3G-VMSC delays call setup and initiates procedures to obtain the UE’s location for routing the emergency call to the emergency services LCS client. The 3G-VMSC sends a RANAP Location Reporting Control message to SRNC associated with the UE’s current location area. This message includes indication about the UE’s location capabilities and the QoS required for an emergency call.

8.7.3A.2 Positioning Measurement Establishment Procedure

4) The actions described under step 9 for a MT-LR are performed.

8.7.3A.3 Location Calculation and Release Procedure

5) When a location estimate best satisfying the requested QoS has been obtained, RAN returns it to the 3G-VMSC. If a failure is received, the 3G-VMSC initiates emergency call setup using the normal NI-LR procedures.

6) The 3G-VMSC sends a MAP Subscriber Location Report to a GMLC associated with the emergency services client to which the emergency call will be sent. This message shall carry any location estimate returned in step 5, the age of this estimate and may carry the MSISDN, IMSI and IMEI of the calling UE. Any NA-ESRD and NA-ESRK that was assigned by the 3G-VMSC shall be included. The message shall also include a request for an NA-ESRK value based on the UE position.

7) The GMLC translates the location estimate into a zone identity and assigns a NA-ESRK, which was requested by the 3G-VMSC. The GMLC shall include the NA-ESRK value in the MAP Subscriber Location Report ack and send it to the 3G-VMSC. The GMLC stores the assigned NA- ESRK and any NA-ESRD that was sent by the 3G-VMSC in step 6.

8.7.3A.4 Location Preparation Procedure

8) The emergency call procedure is applied. The 3G-VMSC, RAN and UE continue the normal procedure for emergency call origination towards the appropriate emergency services client. Call setup information sent into the PSTN may include the UE location plus information that will enable the emergency service provider to request UE location at a later time (NA-ESRD or NA-ESRK in North America). The NA-ESRK used shall be the one received from the GMLC. If a NA-ESRK is not received from the GMLC then the 3G-VMSC shall use the default NA-ESRK for the call as in 8.7.3.1 step 3.

9) At any time after step 6, the GMLC may send a MAP Provide Subscriber Location message to the 3G-VMSC. This message includes a QoS with higher delay and higher accuracy required for an emergency call.

If the GMLC is capable of determining whether the initial location satisfies the higher accuracy requirements for an emergency call, then the GMLC may not need to request for a higher accuracy location.

10) The 3G-VMSC sends a RANAP Location Reporting Control message to SRNC. This message includes the type of location information requested, the UE’s location capabilities and requested higher accuracy QoS.

8.7.3A.5 Positioning Measurement Establishment Procedure

11) same as step 4.

8.7.3A.6 Location Calculation and Release Procedure

12) same as step 5.

13) The 3G-VMSC returns the location information and its age to the GMLC. The GMLC shall replace the previously stored low accuracy location information with the higher accuracy information for later retrieval by the emergency services LCS client.

14) same as step 10 for normal NI-LR.

15) same as step 11 for normal NI-LR.

16) same as step 12 for normal NI-LR.

8.7.4 Network Induced Location Request (NI-LR and PS-NI-LR) from a Serving RNC for a target UE in dedicated mode

Figure 8.6 illustrates how a serving RNC may obtain the location of a target UE that is already in dedicated mode1) on behalf of some PLMN operator LCS client – e.g. to support handover. The procedure is valid for SRNC when local regulatory requirements do not require privacy checking for PLMN operator initiated location. The procedure is valid in PS and CS modes.

1) "Dedicated mode" is defined in TS 25.331.

Figure 8.6: Network Induced Location Request from a Serving RNC

8.7.4.1 Location Preparation Procedure

1) A LCS client within the SRNC requests the current location of a target UE from the SRNC.

8.7.4.2 Positioning Measurement Establishment Procedure

2) Refer to step 9 for a MT-LR or step 10 in PS-MT-LR.

8.7.4.3 Location Calculation and Release Procedure

3) The SRNC returns the UE location estimate to the requesting LCS client.

8.7.5 (void)

8.8 Mobile Originating Location Request

8.8.1 Mobile Originating Location Request, Circuit Switched (CS-MO-LR)

The following procedure shown in Figure 8.8 allows an UE to request either its own location, location assistance data or broadcast assistance data message ciphering keys from the network. Location assistance data may be used subsequently by the UE to compute its own location throughout an extended interval using a mobile based position method. The ciphering key enables the UE to decipher other location assistance data broadcast periodically by the network. The MO‑LR after location update request may be used to request ciphering keys or GPS assistance data using the follow-on procedure described in TS 24.008. The procedure may also be used to enable an UE to request that its own location be sent to an external LCS client.

Figure 8.8:General Network Positioning for MO-LR

8.8.1.1 Location Preparation Procedure

1) If the UE is in idle mode, the UE requests an RACH and sends a CM service request indicating a request for a call independent supplementary services to the 3G-VMSC via the SRNC.

2) The SRNC shall convey the CM service request across the Iu-interface. If the UE is in dedicated mode, the UE sends a CM Service Request on the already established RACH.

3) The 3G-VMSC instigates authentication and ciphering if the UE was in idle mode or returns a Direct Transfer CM Service Accept if the UE was in dedicated mode. If the target UE supports any UE based or UE assisted positioning method(s), the UE will provide the SRNC and 3G-MSC with the positioning method(s) it supports via controlled early classmark sending.

4) The UE sends a LCS MO-LR Location Services invoke to the 3G-VMSC. Different types of location services can be requested: location of the UE, location of the UE to be sent to an external LCS client, location assistance data or broadcast assistance data message ciphering keys. If the UE is requesting its own location or that its own location be sent to an external LCS client, this message carries LCS requested QoS information (e.g. accuracy, response time). If the UE is requesting that its location be sent to an external LCS client, the message shall include the identity of the LCS client and may include the address of the GMLC through which the LCS client should be accessed. If a GMLC address is not included, the 3G-VMSC may assign a GMLC address stored in the 3G-VMSC. If a GMLC address is not available for this case, the 3G-VMSC shall reject the location request. If the UE is instead requesting location assistance data or ciphering keys, the message specifies the type of assistance data or deciphering keys and the positioning method for which the assistance data or ciphering applies. The 3G-VMSC verifies in the UE’s subscription profile that the UE has permission to request its own location, request that its location be sent to an external LCS client or request location assistance data or deciphering keys (whichever applies). If the UE is requesting positioning and has an established call, the 3G-VMSC may reject the request for certain non-speech call types.

5) The 3G-VMSC sends a RANAP Location Reporting Control message to the SRNC associated with the Target UE. The RANAP message indicates whether a location estimate or location assistance data is requested and includes the UE’s location capabilities. If the UE’s location is requested, the message also includes the requested QoS. If location assistance data is requested, the message carries the requested types of location assistance data.

8.8.1.2 Positioning Measurement Establishment Procedure

6) If the UE is requesting its own location, the actions described under step 9 for a MT-LR are performed. If the UE is instead requesting location assistance data, the SRNC transfers this data to the UE as described in subsequent sections. The SRNC determines the exact location assistance data to transfer according to the type of data specified by the UE, the UE location capabilities and the current cell.

8.8.1.3 Location Calculation and Release Procedure

7) When a location estimate best satisfying the requested QoS has been obtained or when the requested location assistance data has been transferred to the UE, the SRNC returns a RANAP Location Report to the 3G-VMSC. This message carries the location estimate or ciphering keys if this was obtained. If a location estimate or deciphering keys were not successfully obtained or if the requested location assistance data could not be transferred successfully to the UE, a failure cause is included in the Location Report.

8) If the UE requested transfer of its location to an external LCS client and a location estimate was successfully obtained, the 3G-VMSC shall send a MAP Subscriber Location Report to the GMLC obtained in step 4 carrying the MSISDN of the UE, the identity of the LCS client, the event causing the location estimate (MO-LR) and the location estimate and its age.

9) The GMLC shall acknowledge receipt of the location estimate provided that is serves the identified LCS client and the client is accessible.

10) The GMLC transfers the location information to the LCS client.

11) The 3G-VMSC returns an LCS MO-LR Return Result to the UE carrying any location estimate requested by the UE, ciphering keys or a confirmation that a location estimate was successfully transferred to the GMLC serving an LCS client.

12) The 3G-VMSC may release the CM, MM and RRC connections to the UE, if the UE was previously idle, and the 3G-VMSC may record billing information.

8.8.2 (void)

8.9 LCS signaling procedures specified in UTRAN Stage 2, TS 35.305

The following signaling procedures are specified in UTRAN LCS Stage 2, reference [1]:

1) Common Procedures to Support Positioning. These procedures are:

– Information Transfer between SRNC and a Target UE

– LCS Information Transfer between SRNC and other RNCs

2) Common Procedures to Support Access to an LMU:

– The information transfer between SRNC and an LMU associated with Node B

– The information transfer between SRNC and a standalone LMU

3) Common Control Procedures for LMUs:

– The LMU Reset Procedure

– LMU Status Query Procedure

– LMU Status Update Procedures

4) LCS signaling interactions between SRNC and other RNCs.

8.10 Exception Procedures

The procedures in this subclause apply to all variants of an MT-LR, NI-LR and MO-LR where a RANAP Location reporting control message has been sent to an SRNC requesting some location service (e.g. provision of a location estimate for a target UE or transfer of assistance data to a target UE).

8.10.1 Procedures in the VMSC

After the VMSC has requested a location service for a particular UE from the SRNC, certain events may occur that may temporarily or permanently interfere with the location service attempt. For each such event notified to the VMSC, the VMSC shall employ one of the following error recovery actions.

Restart the Location Service

This action shall be employed for any event that temporarily impedes a location service attempt and cannot be delayed until the location service attempt is complete. When such an event is notified to the 3G-VMSC, it shall immediately cancel the location service attempt and the associated RANAP dialogue with SRNC, if this still exists by releasing all resources specifically allocated for the location attempt and ignoring the location attempt response when received.

After aborting the location request dialogue with the SRNC, the 3G-VMSC may queue the location service request until the event causing the restart has terminated (if not already terminated). The 3G-VMSC may optionally wait for an additional time period (e.g. if the queuing delay is minimal) to ensure that any resources allocated in and by the SRNC have time to be released. The 3G-VMSC may then send another location service request to the SRNC associated with the target UE.

Abort the Location Service

This action shall be employed for any event that permanently impedes a location service attempt, such as loss of the dedicated signaling channel to the target MS. When such an event is notified to the 3G-VMSC, it shall cancel the current location service attempt and the associated RANAP dialogue with the SRNC, if still existing, by releasing all resources specifically allocated for the location attempt and ignoring the location attempt response when received. The 3G-VMSC shall then return an error response to the client or network entity from which the location request was originally received.

The following table indicates the appropriate error recovery procedure for certain events. For events not listed in the table, the 3G-VMSC need take no action.

Table 8.1: LCS Error Recovery Procedures in the VMSC for certain Events

Event

VMSC Error Recovery

Release of radio channel to the UE

Abort

Any error response from the SRNC, except for inter-SRNC or inter-MSC handover

Abort

Inter RNC hard handovers, SRNC relocation, inter- MSC handovers and InterSystem handovers

Abort on Iu level

Restart after process is completed

If the RNC is in an overload condition, it may reject a location request by indicating congestion. The MSC may reduce the frequency of future location service requests until rejection due to overload has ceased.

8.10.2 Handover handling

In case of hard handovers, e.g. inter RNC hard handover, or Serving RNC relocation, and inter- MSC handovers, the ongoing positioning process is aborted on Iu level. In soft handovers where the Serving RNS and Iu are relocated, any ongoing positioning process is also aborted on Iu level. The VMSC shall restart the Iu aborted location requests with the new Serving RNC. During intra and inter RNC soft and softer handovers where there is no SRNS relocation the existing RRC connection can normally be used without any need to abort the on-going positioning process on Iu level.

8.10.2.1 MSC procedure for Inter-MSC handover

When a location estimate is required for a target UE with an established call in a state of inter-MSC handover, the serving location area ID shall be used by the visited MSC to identify the correct SRNC to serve the location request. All location request related messages shall be sent via MAP/E interface piggy-backed in MAP_FORWARD_ACCESS_SIGNALLING and MAP PROCESS_ACCESS_SIGNALLING between the visited and serving MSCs.

8.10.2.2 Handling of an ongoing handover while a request for positioning arrives

If during an ongoing handover procedure a request for location information arrives, the request shall be suspended until the handover is completed. On completion of the handover, the location preparation procedure shall continue.

8.11 Privacy

8.11.1 Privacy Override Indicator (POI)

The POI is used to determine whether the privacy settings of the subscriber to be positioned shall be overridden by the request for location services. The assignment of a POI value with an "override" or "not override" value in the LCS client profile is done during the LCS client provisioning. The type of LCS client requesting location information (i.e. emergency, law-enforcement etc.) shall determine the value of the POI assigned to the LCS client profile.

There are two distinct cases regarding the handling of the privacy override indicator.

Procedure A: If the subscriber to be positioned is in the same country as the GMLC then the POI shall override the subscriber’s privacy options, as allowed by regulatory requirements.

Procedure B: Otherwise the POI shall not override the subscriber’s privacy options.

8.11.2 Privacy Procedures

The SLPP shall contain the privacy options defined in the HLR of the UE subscriber.

The SLPP shall be downloaded to the VMSC together with the rest of his subscription information in the existing MAP operation INSERT_SUBSCRIBER_DATA. It will be deleted with the existing MAP operation DELETE_SUBSCRIBER_DATA.

The POI is transferred from the GMLC to the VMSC in the location request. Based on the location of the GMLC the VMSC evaluates whether to accept or ignore the received POI according to the definition in subclause 8.11.3.

If the POI is accepted the location requested is unconditionally performed. Otherwise if the POI is ignored the VMSC evaluates the privacy options in the UE subscriber’s subscription profile (assuming this is held in the VLR). If the VLR does not contain the UE subscription profile, LCS will rely on the existing GSM recovery mechanisms to obtain the profile.

Note: If more than one privacy class are subscribed for the UE, the privacy class for an MT-LR is selected according to the rule described in the informative ANNEX A.

If the location request is allowed by the privacy options the location request is performed. Otherwise, if the location request is barred by the privacy options, the location request is refused an error response is returned to the GMLC with a cause code indicating that the request was rejected by the subscriber.

8.11.3 UE Privacy Options

The UE privacy options in the SLPP apply to an MT-LR or NI-LR and either indicate that no MT-LR or NI-LR is allowed for the UE (except as may be overridden by the POI or local regulatory requirements) or define the particular classes of LCS client for which an MT-LR or NI-LR for location are allowed, with the following classes being possible:

a) Universal Class – allow positioning by all LCS clients

b) Call related Class – comprises any LCS client to which the UE originated a call that is currently established. For all clients in the call related class, one of the following subscription options shall apply:

– positioning allowed without notifying the UE user (default case)

– positioning allowed with notification to the UE user

– positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user or if there is no response to the notification

– positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user

c) Non-Call related Class – allow positioning by specific identified LCS Clients or groups of LCS Client with the following restrictions allowed for each identified LCS Client or group of LCS Clients

– Location request allowed only from GMLCs identified in the SLPP

– Location request allowed only from a GMLC in the home country

– Location request allowed from any GMLC (default case)

For each identified value added LCS client in the privacy exception list, one of the following subscription options shall apply:

– positioning allowed without notifying the UE user (default case)

– positioning allowed with notification to the UE user

– positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user or if there is no response to the notification

– positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user

For all value added LCS clients sending a non-call related MT-LR that are not identified in the privacy exception list, one of the following subscription option shall apply:

– positioning not allowed (default case)

– positioning allowed with notification to the UE user

– positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user or if there is no response to the notification

– positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user

d) PLMN operator Class – allow positioning by specific types of client within or associated with the VPLMN, with the following types of client identified:

– clients providing a location related broadcast service

– O&M client in the HPLMN (when the UE is currently being served by the HPLMN)

– O&M client in the VPLMN

– Clients recording anonymous location information without any UE identifier

– Clients enhancing or supporting any supplementary service, IN service, bearer service or teleservice subscribed to by the target UE subscriber

If the UE subscribes to the universal class, any MT-LR or NI-LR shall be allowed by the VMSC. If local regulatory requirements mandate it, any MT-LR for an emergency services LCS client and any NI-LR for an emergency services call origination shall be allowed by the VMSC.

If the UE subscribes to the call-related class, an MT-LR may be allowed if the UE previously originated a call that is still established and the called party number dialled by the UE matches the called party number received from the GMLC. If the called party number conditions are satisfied, the MT-LR shall be allowed if the UE user subscribes to either location without notification or location with notification. If the UE user subscribes to location with notification and privacy verification, the MT-LR shall be allowed following notification to the UE if the UE user either returns a response indicating that location is allowed or returns no response but subscribes to allowing location in the absence of a response. In all other cases, the MT-LR shall be restricted.

If the UE subscribes to the non-call related class, an MT-LR may be allowed by the network if the identity of the LCS client or LCS client group supplied by the GMLC matches the identity of any LCS Client or LCS Client group contained in the UE’s SLPP and any other GMLC restrictions associated with this LCS Client identity in the SLPP are also met.

If the LCS client is correctly matched in this way and any GMLC restrictions are satisfied, the MT-LR shall be allowed if the UE user subscribes to either location without notification or location with notification. If the UE user subscribes to location with notification and privacy verification, the MT-LR shall be allowed following notification to the UE if the UE user either returns a response indicating that location is allowed or returns no response but subscribes to location in the absence of a response. In all other cases, the MT-LR shall be restricted.

If the UE subscribes to the non-call related class, an MT-LR from an LCS client that is not contained in the UE’s SLPP shall allowed or restricted according to the following conditions. For any non-matched LCS client, the MT-LR shall be allowed if the UE user subscribes to location with notification. If the UE user subscribes to location with notification and privacy verification, the MT-LR shall be allowed following notification to the UE if the UE user either returns a response indicating that location is allowed or returns no response but subscribes to location in the absence of a response. In all other cases, the MT-LR shall be restricted.

If the UE subscribes to the PLMN class, an NI-LR or MT-LR shall be allowed if the client within the VPLMN, for an NI-LR, or the client identified by the GMLC, for an MT-LR, either matches a generic type of client contained in the UE’s SLPP or is otherwise authorized by local regulatory requirements to locate the UE.

Note: If more than one privacy class are subscribed for the UE, the privacy class for an MT-LR is selected according to the rule described in the informative ANNEX A.

In evaluating privacy where any address "A" associated with the LCS client (e.g. LCS client ID or GMLC address) needs to be compared with a corresponding address "B" in the target UE’s SLPP, a match shall be determined if a match is found for each of the following components of each address:

a) Numbering Plan

b) Nature of Address Indicator

c) Corresponding address digits for all digits in "B" (the digits or initial digits in "A" must match all the digits in "B", but "A" may contain additional digits beyond those in "B")

All addresses shall be transferred to the MSC/VLR in international format, except for the called party number received from the GMLC during a Call Related MT-LR when the LCS client was reached via IN or abbreviated number routing (e.g. toll free number or emergency call routing). In these cases it is up to the GMLC to use the valid national specific number of the visited country.

8.12 Mobile Originating Location

An UE may subscribe to any of the following classes of mobile originating location:

A) Basic Self Location

B) Autonomous Self Location

C) Transfer to Third Party

An MO-LR shall be allowed by the VMSC if the type of request is supported by the appropriate subscription according to the following table.

Table 8.2: Required UE Subscription Options for MO-LR Requests

Type of MO-LR Request

Required UE Subscription

UE requests own location

Basic Self Location

UE requests location assistance data

Autonomous Self Location

UE requests transfer of own location to another LCS Client

Transfer to Third Party

8.13 CM Procedures

8.13.1 Location request for a mobile in idle-mode

When a request for location information is received at the VMSC the LCS-layer shall order paging of the UE subscriber. In case of first unsuccessful paging, normal paging procedures should apply. After successful paging the LCS-layer shall invoke the location preparation procedure.

8.13.2 Location request for a mobile in dedicated-mode

When a request for location information is received at the VMSC, if the UE is already busy on CM level, the LCS-layer shall attempt to establish a parallel transaction to the existing one. If successful, the LCS-layer shall invoke the location preparation procedure.