4 Generic procedures for the control of location services
3GPP44.071GSM/EDGE Location Services (LCS)Mobile radio interface layer 3 LCS specificationRelease 17TS
4.1 Overview of the generic protocol and its scope
One generic protocol is defined for the control of location services at the radio interface. This protocol operates at layer 3 of the radio interface and assumes the use of layers 1 and 2 conform to 3GPP TS 45‑series and 3GPP TS 44.004, 3GPP TS 44.005 and 3GPP TS 44.006. The generic protocol uses the acknowledged information transfer service available at the layer 2 ‑ layer 3 interface.
The Functional protocol is based on the use of the Facility information element and the FACILITY message as well as other specific functional messages specified in the present document.
4.2 Functional procedures for the control of location services
4.2.1 General
This subclause specifies the functional signalling procedures for the control of location services at the radio interface.
The functional protocol utilizes functions and services defined in 3GPP TS 24.008, 3GPP TS 44.018 and the functions of the data link layer as defined in 3GPP TS 44.006. This protocol utilizes also definitions in 3GPP TS 24.007.
The Common Information Element Category utilizes the Facility information element to transport the protocol defined in the present document. The use of the Facility information element is common to many services, and its contents indicates what type of procedure is being requested. This category can be signalled both in the LMU to network and the network to LMU directions.
The correlation of location service operations and their responses, is provided by the combination of the transaction identifier of the messages containing the Facility information element and the Invoke identifier present within the Facility information element itself.
4.2.2 Common Information Element Category
The Common Information Element Category uses operations defined in the present document for location services signalling. Procedures are initiated by sending an operation including an invoke component. The invoke component may yield a Return Error, Return Result or Reject component (also included in an operation) depending on the outcome of the procedure.
The operation state machines, and procedures for management of Invoke IDs specified in ITU-T Recommendation Q.774 White Book are used.
A REGISTER message, a FACILITY message or RELEASE COMPLETE message is used to carry the Facility information element which includes these operations. These operations request, acknowledge or reject the desired location service procedure.
4.2.3 Location service procedures
4.2.3.1 Introduction
For location service procedures independent of any call, the initiating side must establish a MM‑connection between the network and the LMU according to the rules given in 3GPP TS 24.007 and 3GPP TS 24.008. The LMU or the network starts the transaction by transferring a REGISTER message across the radio interface. This transaction is identified by the transaction identifier associated with the REGISTER message present in the component part of the Facility information element. Following the REGISTER message one or more FACILITY messages may be transmitted, all of them related by the use of the same transaction identifier. If the transaction is no longer used, it shall be released by sending a RELEASE COMPLETE message. This procedure is specified in detail in clause 5, and the text in clause 5 takes precedence over this introduction.
To convey the location service invocation, the Facility information element is used. The Facility information element present either in the REGISTER message or a subsequent message identifies the location service involved and the type of component (i.e. Invoke, Return result, Return error or Reject component).
When the REGISTER or FACILITY message contains a Facility information element and the requested service is available, a FACILITY message containing a Facility information element may be returned. One or more exchanges of FACILITY messages may subsequently occur. To terminate the service interaction and release the transaction identifier value, a RELEASE COMPLETE message is sent as specified for the specific location service procedure. The RELEASE COMPLETE message may also contain the Facility information element.
4.2.3.2 Handling of protocol errors in LCS procedures
Messages containing a Facility information element shall be checked for protocol errors before the contents of the Facility IE is acted on. The checks shall be performed in the following order:
1) The message carrying the Facility IE shall be checked for protocol errors as specified in subclause 5.7. If a protocol error is found then the procedures in subclause 5.7 apply.
2) The contents of the Facility IE shall be checked for protocol errors as specified in subclause 4.2.6. If a protocol error is found then the procedures in subclause 4.2.6 apply.
4.2.3.3 Handling of other errors in LCS procedures
If the tests specified in subclause 4.2.3.2 have been passed without the detection of a protocol error, the receiver will attempt to process the contents of the Facility Information Element. If errors occur during this processing (e.g. system failure, or information in the Facility IE is incompatible with the requested operation) then the procedures specified in the individual service specifications apply.
An example of the behaviour that could occur in this case is:
– the LMU or network sends a Facility information element containing a return error component in a FACILITY or RELEASE COMPLETE message. If the FACILITY message is used then the MM Connection may continue to be used for further signalling.
4.2.4 Multiple location service invocations
It is possible for several LCS transactions to be used simultaneously. LCS transactions can also exist in parallel with other CM‑Layer and MM transactions. The handling of multiple MM connections is defined in 3GPP TS 24.007 and 3GPP TS 24.008.
A single Facility Information Element shall not contain more than one component.
4.2.5 Recovery procedures
In case a transaction is not terminated according to the normal procedure as described in the present document the network side has to ensure that the transaction is terminated e.g. by a supervision timer.
4.2.6 Generic protocol error handling for the component part of location services operations
If a location service operation is to be rejected the operation will be denied, and provided the transaction is still in progress, an appropriate reject component will be returned in a Facility Information Element.
4.2.6.1 Single component errors
The reject component shall be sent in a RELEASE COMPLETE message.
If the component containing the error was itself sent in a RELEASE COMPLETE message then the contents of the component shall be ignored, and no reject component is sent.
4.2.6.2 Multiple component errors
If a single Facility IE contains more than one component then a RELEASE COMPLETE message with the cause "Facility rejected" and without any component shall be sent.