Content for TS 44.071 Word version: 18.0.0

3.1 Definitions 3.2 Abbreviations 4.1 Overview of the generic protocol and its scope 4.2 Functional procedures for the control of location services
...

1 Scope p. 7

The present document contains the coding of information necessary for support of location service operation on the mobile radio interface layer 3 between the LMU and SMLC.

Clause 4 defines generic procedures for the control of location services. In clause 5 location service support procedures are defined. Clause 6 gives the functional definitions and contents of messages for location service operations. Clause 7 gives the general format and coding for messages used for location service and the format and coding of information elements used for location service operations. Clause 6 gives the detailed message format and information elements coding between the LMU and SMLC.

Clause 8 gives the specification of the LMU LCS Protocol (LLP) operations. In clause 9 LMU - SMLC messages, data types and identifiers are given.

This version does not support segmentation of messages.

2 References p. 7

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 44.006: "Mobile Station - Base Station System (MS - BSS) interface Data Link (DL) layer specification".

[3]

TS 24.007: "Mobile radio interface signalling layer 3; General aspects".

[4]

TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control Protocol".

[5]

TS 43.059: "Functional Stage 2 Description of Location Services (LCS) in GERAN".

[6]

TS 29.002: "Mobile Application Part (MAP) specification".

[7]

ITU-T Recommendation X.691 (1997) | ISO/IEC 8825-2 (1998): "Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)".

[8]

ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1 (1998): "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)".

[9]

ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1 (1998): "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation".

[10]

ITU-T Recommendation Q.773: "Transaction capabilities formats and encoding".

[11] (void)

[12]

TS 44.004: "Layer 1; General requirements".

[13]

TS 44.005: "Data Link (DL) layer General aspects".

[14]

TS 24.008: "Mobile radio interface layer 3 specification; Core Network Protocols; Stage 3".

[15]

TS 45.002: "Multiplexing and Multiple Access on the Radio Path".

[16]

TS 52.071: "Location Services (LCS); Location services management".
→ to date, withdrawn by 3GPP

3 Definitions and abbreviations p. 8

3.1 Definitions p. 8

For the purposes of the present document, the following terms and definitions apply:

E-OTD Assistance Data Message:

contains the RTD and BTS coordinates of the neighbours that should be used in E-OTD measurements. This E-OTD Assistance Data is broadcasted using CBCH channel using SMSCB DRX service. The reception of this broadcast message enables MS to calculate its own location.

GPS Assistance Data Message:

contains GPS differential corrections. The reception of this broadcast message enables MS to have calculate more accurate location estimate.

GANSS Assistance Data Message:

contains GANSS differential corrections. The reception of this broadcast message enables MS to have calculate more accurate location estimate.

3.2 Abbreviations p. 8

For the purposes of the present document, the abbreviations given in TR 21.905 and TS 43.059.

4 Generic procedures for the control of location services p. 8

4.1 Overview of the generic protocol and its scope p. 8

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 TS 44.004, TS 44.005 and 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 p. 8

4.2.1 General p. 8

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 TS 24.008, TS 44.018 and the functions of the data link layer as defined in TS 44.006. This protocol utilizes also definitions in 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 p. 9

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 p. 9

4.2.3.1 Introduction p. 9

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 TS 24.007 and 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 p. 9

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:

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.
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 p. 9

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 p. 10

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 TS 24.007 and TS 24.008.

A single Facility Information Element shall not contain more than one component.

4.2.5 Recovery procedures p. 10

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 p. 10

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 p. 10

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 p. 10

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.