7.6 General Network Positioning Procedures

03.713GPPFunctional descriptionLocation Services (LCS)Release 1999Stage 2TS

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

Location Preparation Procedure

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

Positioning Measurement Establishment Procedure

This procedure is concerned with performing measurements by involving the necessary network and/or MS resources. Depending on the positioning method to be used for locating the MS 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 MS and releasing all network and/or MS resources involved in the positioning.

7.6.1 Mobile Terminating Location Request (MT-LR)

Figure 29 illustrates general network positioning for LCS clients external to the PLMN. In this scenario, it is assumed that the target MS is identified using either an MSISDN or IMSI.

Figure 29: General Network Positioning for a MT-LR

7.6.1.1 Location Preparation Procedure

1) An external LCS client requests the current location of a target MS 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 MS 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 MS, or if periodic location is requested, steps 2 to 12 below may be repeated.

2) If the GMLC already knows both the 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 MS to be located with either the IMSI or MSISDN of this MS.

3) The HLR verifies that the SCCP calling party address of the GMLC, corresponds to a known GSM network element that is authorized to request MS location information. The HLR then returns the current VMSC address and whichever of the IMSI and MSISDN was not provided in step 2 for the particular MS.

4) The GMLC sends a MAP_PROVIDE_SUBSCRIBER_LOCATION message to the VMSC indicated by the HLR. This message carries the type of location information requested (e.g. current location), the MS 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 VMSC first authenticates that a location request is allowed from this PLMN or from this country. If not, an error response is returned. If the target MS 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 SMLC to decide, on the basis of the applicable position methods and requested QoS, whether positioning is possible. The VMSC then verifies LCS barring restrictions in the MS 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 MS 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 MS is in idle mode, the VLR performs paging, authentication and ciphering. The MSC will page a GPRS attached MS either through A or Gs interface, depending on the presence of the Gs interface (see Note). This procedure will provide the MS user’s current cell ID and certain location information that includes the TA value in the BSSMAP Complete layer 3 Information used to convey the Paging Response. If the target MS supports any MS based or MS assisted positioning method(s), the MS will also provide the BSC and MSC with the positioning method(s) it supports via controlled early classmark sending (see GSM 04.08 and 08.08). If the MS is instead in dedicated mode, the VMSC will already have any early classmark information and will have been supplied with the current cell ID from either the serving BSC or serving MSC in the case of an established call with MSC-MSC handover.

Note: In some network mode of operation, a GPRS capable MS may not receive the CS paging. In addition, upon receipt of a CS paging, a GPRS capable MS may immediately answer to the Paging Request or delay the answer, as defined in 3GPP TS 02.60 and 03.60. A GPRS MS in class B mode may also suspend its GPRS traffic, sending a GPRS Suspension Request to the network.

6) If the location request comes from a value added LCS client and the MS subscription profile indicates that the MS must either be notified or notified with privacy verification and the MS supports notification of LCS (according to the MS Classmark 2), a DTAP LCS Location Notification Invoke message is sent to the target MS indicating the type of location request (e.g. current location), 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 DTAP LCS Location Notification Invoke message continue in parallel the location process, i.e. continue to step 8 without waiting for a DTAP LCS Location Notification Return Result message in step 7.

7) The target MS notifies the MS user of the location request and, if privacy verification was requested, the target MS indicates to the MS 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 MS then returns a DTAP LCS Location Notification Return Result to the VMSC indicating, if privacy verification was requested, whether permission is granted or denied. Optionally, the DTAP LCS Location Notification Return Result message can be returned some time after step 6, but before step 15. If the MS user does not respond after a predetermined time period, the VMSC shall infer a "no response" condition. The VMSC shall return an error response to the GMLC if privacy verification was requested and either the MS user denies permission or there is no response with the MS subscription profile indicating barring of the location request in the absence of a response.

8) The VMSC sends a MAP_PERFORM_LOCATION message to the SMLC associated with the MS’s current cell location. The BSSMAP-LE message includes the type of location information requested, the MS’s location capabilities and currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the requested QoS and the current Cell ID and, if available, any location information including the TA value received in step 5.

9) If the SMLC is BSS based, the VMSC instead sends the BSSMAP PERFORM LOCATION message to the serving BSC for the target MS.

10) In the case of a BSS based SMLC, the BSC forwards the BSSMAP-LE PERFORM LOCATION request received in step 9 to the SMLC. The BSC may add additional measurement data to the message to assist with positioning. The message is transported inside an SCCP connection request.

7.6.1.2 Positioning Measurement Establishment Procedure

11) If the requested location information and the location accuracy within the QoS can be satisfied by the reported cell ID and, if available, TA value, the SMLC may send a MAP_PERFORM_LOCATION ack. immediately. Otherwise, the SMLC determines the positioning method and instigates the particular message sequence for this method defined in subsequent sections. If the position method returns position measurements, the SMLC uses them to compute a location estimate. If there has been a failure to obtain position measurements, the SMLC may use the current cell ID and, if available, TA value to derive an approximate location estimate. If an already computed location estimate is returned for an MS based position method, the SMLC may verify consistency with the current cell ID and, if available, TA 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 SMLC may instigate a further location attempt using the same (e.g. providing more assistance data to MS) or a different position method. If a vertical location coordinate is requested but the SMLC can only obtain horizontal coordinates, these may be returned.

Restrictions on the geographic shape encoded within the “position information” parameter may exist for certain LCS client types. The SMLC shall comply with any restrictions defined in GSM and, in a particular country, with any restrictions defined for a specific LCS client type in relevant national standards. For example, in the US, national interim standard TIA/EIA/IS-J-STD-036 restricts the geographic shape for an emergency services LCS client to minimally either an “ellipsoid point” or an “ellipsoid point with uncertainty circle” as defined in 3GPP TS 23.032.

7.6.1.3 Location Calculation and Release Procedure

12) When location information best satisfying the requested location type and QoS has been obtained, the SMLC returns it to the VMSC in a Perform Location response if the SMLC is NSS based. If a location estimate could not be obtained, the SMLC returns a Perform Location response containing a failure cause and no location estimate.

13) For a BSS based SMLC, the location information is instead returned to the serving BSC.

14) In the case of a BSS based SMLC, the BSC forwards the BSSMAP PERFORM LOCATION response received in step 13 to the VMSC.

15) The VMSC 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 DTAP LCS Location Notification Return Result indicating that permission is granted. If a DTAP LCS Location Notification Return Result message indicating that permission is not granted is received, or there is no response with the MS subscription profile indicating barring of location in the absence of a response, the VMSC shall return an error response to the GMLC. If the SMLC did not return a successful location estimate, but the privacy checks in steps 5-7 were successfully executed, the VMSC may return the last known location of the target MS 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 MS, if the MS was previously idle, and the VMSC may record billing information.

16) The GMLC returns the MS location information to the requesting LCS client. If the LCS client requires it, the GMLC may first transform the universal location coordinates provided by the VMSC into some local geographic system. The GMLC may record billing for both the LCS client and inter-network revenue charges from the VMSC’s network.

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

Figure 30 illustrates location for a North American Emergency Services call, where an emergency services client identifies the target MS using an IMSI, MSISDN or NA-ESRK plus, possibly IMEI, that were previously provided to it by the VMSC (e.g. see section 7.6.4). 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 MS already stored in the GMLC. This allows the GMLC to request location from the VMSC without first querying the home HLR of the target MS. 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 30: Positioning for a Emergency Services MT-LR without HLR Query

1) Same as step 1 in figure 29 but with the LCS client identifying first the target MS 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 MS (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 MS, as well as the required QoS and an indication of a location request from an emergency services client. The VMSC identifies the target MS using the IMSI or MSISDN and, if provided, the IMEI.

3) The VMSC verifies that MS privacy is overridden by the emergency services provider and that positioning is not prevented for other reasons (e.g. unreachable MS, inapplicable call type to the MS). The VMSC then sends a BSSMAP-LE Perform Location Request to the SMLC, either directly or via the BSC, as in steps 8-10 for a normal MT-LR.

4) The SMLC performs positioning as in step 11 for a normal MT-LR.

5) The SMLC returns a location estimate to the VMSC either directly or via the BSC as in steps 12-14 for a normal MT-LR.

6) to (7) Same as steps 15 to 16 for a normal MT-LR.

7.6.3 MT-LR for a previously obtained location estimate

Every time the location estimate of a target MS subscriber is returned by the SMLC to the VMSC, the VMSC may store the location estimate together with a time stamp in the subscriber’s VLR record.

The time stamp is the time at which the location estimate is stored at the VLR i.e. after the SMLC returns the location estimate to the VMSC. The time stamp indicates the ‘age’ of the location estimate.

7.6.3.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’.

7.6.3.2 Current Location

After a location attempt has succesfully del;ivered a location estimate and its assocoiated time stamp, the location estimate and time stamp is referred to as the ‘current location’ at that point in time.

7.6.3.3 Last known Location

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

7.6.3.4 Security and Privacy

The handling of security and privacy of the target MS with regard to returning the last known or initial location estimate of the target MS shall be the same as when the target MS is reachable for positioning. (i.e. the requesting LCS client is authorized and the privacy of the target MS is secured before the VMSC check the VLR status of the target MS (i.e. whether the MS is marked as attached or detached in the VLR).

7.6.3.5 Failing to locate the target MS

In case of a ‘Detached’ or ‘Not Reachable’ target MS, the last known location and a time stamp stored at the VLR, 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 MS subscribes to notification of the location request: if the notification cannot be performed, the VMSC shall reject the location request.

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

When a request for location information is received at the VMSC, the request shall indicate whether the ‘last known location of the target MS’ should be returned in case of a ‘detached’ or ‘not reachable’ target MS.

If the VLR has a valid copy of the subscriber’s permanent data and the target MS’s privacy settings are such that positioning is allowed, then the following cases can occur.

7.6.3.5.1 Target MS is ‘Not Reachable’

If the target MS is marked as ‘attached’ in the VLR, the VMSC orders paging of the target MS. If paging fails, due to target MS being ‘not reachable’ then VMSC shall check whether the LCS client has requested ‘last known location’ in case of ‘not reachable’ target MS.

If such a request exists and notification to the target MS does not apply for a value added LCS client, the VMSC 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.

7.6.3.5.2 Target MS is ‘Detached’

If the target MS is marked as ‘detached’ in the VLR, the VMSC shall check whether the LCS client has requested ‘last known location’ in case of ‘detached’ target MS.

If such a request exists and notification to the target MS does not apply for a value added LCS client, the VMSC 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.

7.6.3.5.3 Target MS is Reachable but Positioning Fails

If the target MS is reachable (e.g. paging succeeds), but the VMSC is unable to obtain a current location estimate, the VMSC shall check whether the LCS client has requested ‘last known location’.

If such a request exists and notification to the target MS either does not apply or was successfully executed for a value added LCS client, the VMSC 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.

7.6.3.5.4 Target MS is ‘Purged’

If the target MS is marked as ‘Purged’ in HLR, then an indication ‘Absent Subscriber’ is returned to the GMLC.

7.6.4 Network Induced Location Request (NI-LR)

Figure 31 illustrates positioning for an emergency service call.

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

7.6.4.1 Location Preparation Procedure

1) An initially idle MS requests an SDCCH and sends a DTAP CM Service Request indicating a request for an Emergency Service call to the VMSC via the BSC.

2) The BSC includes the current cell ID and may include certain other location information (e.g. the TA value) within the BSSMAP Complete Layer 3 Information message used to convey the CM service request across the A-interface. The MS may identify itself using a TMSI, IMSI or IMEI.

3) The VMSC determines based on the serving cell the appropriate emergency services client. The VMSC, BSC and MS 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 MS’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 may delay call setup and invoke location based routing procedures described in section 7.6.4A. Call setup information sent into the PSTN may include the MS location (if already obtained) plus information that will enable the emergency service provider to request MS 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 BSC and MSC where the MS supports any MS assisted or MS based positioning method(s), the VMSC may initiate procedures to obtain the MS’s location. These procedures may run in parallel with the emergency call origination. The VMSC sends a BSSMAP-LE :Perform Location Request message to the SMLC associated with the MS’s current location area – either directly or via the serving BSC (see steps 8-10 for an MT-LR). This message includes the MS’s location capabilities and currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS required for an emergency call and the current Cell ID and any location information including the TA value received in step 2.

7.6.4.2 Positioning Measurement Establishment Procedure

5) The actions described under step 11 for a MT-LR are performed. If a speech compatible traffic channel is required for network based positioning (e.g. TOA), 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.

7.6.4.3 Location Calculation and Release Procedure

6) When a location estimate best satisfying the requested QoS has been obtained, the SMLC returns it to the VMSC – either directly or via the serving BSC (see steps 12-14 for an MT-LR).

7) Depending on local regulatory requirements, the 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 MS. In North America, any NA-ESRD and any NA-ESRK that may have been assigned by the 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 SMLC in step 8), 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 7 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 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 MSC notification and may then release all information previously stored for the emergency call.

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

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

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

7.6.4A.1 Location Preparation Procedure

1) An initially idle MS requests an SDCCH and sends a DTAP CM Service Request indicating a request for an Emergency Service call to the VMSC via the BSC.

2) The BSC includes the current cell ID and may include certain other location information (e.g. the TA value) within the BSSMAP Complete Layer 3 Information message used to convey the CM service request across the A-interface. The MS may identify itself using a TMSI, IMSI or IMEI.

3) The VMSC determines that the serving cell serves an area that contains portions of multiple emergency services zones. Therefore, the VMSC delays call setup and initiates procedures to obtain the MS’s location for routing the emergency call to the emergency services LCS client. The VMSC sends a BSSMAP-LE: Perform Location Request message to the SMLC associated with the MS’s current location area – either directly or via the serving BSC. This message includes the MS’s location capabilities and currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS required for an emergency call and the current Cell ID.

7.6.4A.2 Positioning Measurement Establishment Procedure

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

7.6.4A.3 Location Calculation and Release Procedure

5) When a location estimate best satisfying the requested QoS has been obtained, the SMLC returns it to the VMSC – either directly or via the serving BSC. If a failure is received, the VMSC initiates emergency call setup using the normal NI-LR procedures.

6) The 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 MS. Any NA-ESRD and NA-ESRK that was assigned by the VMSC shall be included. The message shall also include a request for an NA-ESRK value based on the MS position.

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

7.6.4A.4 Location Preparation Procedure

8) The emergency call procedure is applied. The VMSC, BSC and MS continue the normal procedure for emergency call origination towards the appropriate emergency services client. Call setup information sent into the PSTN may include the MS location plus information that will enable the emergency service provider to request MS 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 VMSC shall use the default NA-ESRK for the call as in 7.6.4 step 3.

9) At any time after step 6, the GMLC may send a MAP Provide Subscriber Location message to the 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 VMSC sends a BSSMAP-LE: Perform Location Request message to the SMLC. This message includes the type of location information requested, the MS’s location capabilities and requested higher accuracy QoS.

7.6.4A.5 Positioning Measurement Establishment Procedure

11) Same as step 4.

7.6.4A.6 Location Calculation and Release Procedure

12) Same as step 5.

13) The 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.

7.6.5 Network Induced Location Request (NI-LR) from a Serving BSC for a target MS in dedicated mode

Figure 32 illustrates how a serving BSC may obtain the location of a target MS that is already in dedicated mode on behalf of some PLMN operator LCS client – e.g. to support handover. The procedure is valid for an NSS based SMLC in all circumstances and for a BSS based SMLC when local regulatory requirements do not require privacy checking for PLMN operator initiated location.

Figure 32: Network Induced Location Request from a Serving BSC

7.6.5.1 Location Preparation Procedure

1) An LCS client within the BSC or within the PLMN requests the current location of a target MS from the serving BSC

2) The BSC sends a BSSMAP-LE PERFORM LOCATION request message to the SMLC if this is BSS based. The BSSMAP-LE message includes the MS’s location capabilities and currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the requested QoS and the current Cell ID. The message may also contain additional measurements available to the BSC (e.g. TA value).

3) If the SMLC is NSS based, the BSC instead sends the BSSMAP Perform Location Request to its serving MSC with the type of PLMN operator LCS client.

4) In the case of an NSS based SMLC, the MSC verifies in the subscription profile of the target MS that the MS permits location by the indicated type of LCS client. The MSC then forwards the BSSMAP-LE PERFORM LOCATION request received in step 3 to the SMLC.

7.6.5.2 Positioning Measurement Establishment Procedure

5) Refer to step 11 for an MT-LR.

7.6.5.3 Location Calculation and Release Procedure

6) When a location estimate best satisfying the requested QoS has been obtained, the SMLC returns it to the BSC if the SMLC is BSS based.

7) If the SMLC is NSS based, the BSC instead returns the location estimate to the MSC.

8) In the case of a NSS based SMLC, the MSC forwards the BSSMAP PERFORM LOCATION response received in step 7 to the BSC.

9) The BSC returns the MS location estimate to the requesting LCS client.

7.6.6 Mobile Originating Location Request (MO-LR)

The following procedure allows an MS 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 MS to compute its own location throughout an extended interval using a mobile based position method. The ciphering key enables the MS 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 GSM 04.08. The procedure may also be used to enable an MS to request that its own location be sent to another LCS client.

Figure 33: General Network Positioning for MO-LR

7.6.6.1 Location Preparation Procedure

1) If the MS is in idle mode, the MS requests an SDCCH and sends a DTAP CM service request indicating a request for call independent supplementary services to the BSC.

2) The BSC includes the current cell ID and TA value within the BSSMAP Complete Layer 3 Information message used to convey the CM service request across the A-interface. If the MS is instead in dedicated mode, the MS sends a DTAP CM Service Request on the already established SACCH: the VMSC will then already have been supplied with the current cell ID from either the serving BSC or serving MSC in the case of an established call with MSC-MSC handover.

3) The VMSC instigates authentication and ciphering if the MS was in idle mode or returns a DTAP CM Service Accept if the MS was in dedicated mode. If the target MS supports any MS based or MS assisted positioning method(s), the MS will provide the BSC and MSC with the positioning method(s) it supports via controlled early classmark sending (see GSM 04.08 and 08.08).

4) The MS sends a DTAP LCS MO-LR invoke to the VMSC. If the MS is requesting its own location or that its own location be sent to another LCS client, this message carries LCS QoS information (e.g. accuracy, response time). If the MS is requesting that its location be sent to another 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 VMSC may assign its own GMLC address and may verify that the identified LCS client is supported by this GMLC. If a GMLC address is not available for this case, the VMSC shall reject the location request. If the MS 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 deciphering applies. The VMSC verifies in the MS’s subscription profile that the MS has permission to request its own location, request that its location be sent to another LCS client or request location assistance data or deciphering keys (whichever applies). If the MS is requesting positioning and has an established call, the VMSC may reject the request for certain non-speech call types.

5) The VMSC sends a BSSMAP-LE PERFORM LOCATION request message to the SMLC associated with the MS’s current cell location if the SMLC is NSS based. This message is transported using SCCP connection oriented signaling inside an SCCP Connection Request message The BSSMAP-LE message indicates whether a location estimate or location assistance data is requested and includes the MS’s location capabilities and current cell ID. If the MS’s location is requested, the message also includes the currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the requested QoS and, if available and any location measurement information including the TA value received from the BSC in step 2. If location assistance data is instead requested, the message carries the requested types of location assistance data.

6) If the SMLC is BSS based, the VMSC instead sends the BSSMAP PERFORM LOCATION message to the serving BSC for the target MS.

7) In the case of a BSS based SMLC, the BSC forwards the BSSMAP-LE PERFORM LOCATION request received in step 6 to the SMLC. If the MS’s location is requested, the BSC may add additional measurement data to the message to assist with positioning. The message is transported inside an SCCP connection request.

7.6.6.2 Positioning Measurement Establishment Procedure

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

7.6.6.3 Location Calculation and Release Procedure

9) When a location estimate best satisfying the requested QoS has been obtained or when the requested location assistance data has been transferred to the MS, the SMLC returns a BSSMAP-LE Perform Location response to the VMSC if the SMLC is NSS based. 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 MS, a failure cause is included in the Perform Location response.

Restrictions on the geographic shape encoded within the “position information” parameter may exist for certain LCS client types. The SMLC shall comply with any restrictions defined in GSM and, in a particular country, with any restrictions defined for a specific LCS client type in relevant national standards. For example, in the US, national interim standard TIA/EIA/IS-J-STD-036 restricts the geographic shape for an emergency services LCS client to minimally either an “ellipsoid point” or an “ellipsoid point with uncertainty circle” as defined in 3GPP TS 23.032.

10) For a BSS based SMLC, the BSSMAP-LE Perform Location response is instead returned to the serving BSC.

11) In the case of a BSS based SMLC, the BSC forwards the BSSMAP PERFORM LOCATION response received in step 10 to the VMSC.

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

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

14) The GMLC transfers the location information to the LCS client either immediately or upon request from the client.

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

16) The VMSC may release the CM, MM and RR connections to the MS, if the MS was previously idle, and the VMSC may record billing information.