5 Location service support procedures

04.713GPPLocation Services (LCS)Mobile radio interface Layer 3 specificationRelease 1998TS

5.1 General

This clause describes the location service support procedures at the radio interface. These procedures are provided by the location service support entity defined in 3GPP TS 04.07. The location service support procedures provide the means to transfer messages for the location service procedures. These procedures are regarded as the user of the location service support.

5.2 Location service support establishment

At the beginning of each location service procedure a location service support must be established.

5.2.1 Location service support establishment at the originating side

If the entity that uses the location support procedures needs to send a REGISTER message, the location service support entity shall first request the establishment of an MM‑connection. This MM‑connection is established according to 3GPP TS 04.08 and 04.07. If the network is the initiating side then MM‑connection establishment may involve paging the LMU.

The location service support entity shall send the REGISTER message as the first CM‑message on the MM‑connection. The REGISTER message is sent to the corresponding peer entity on the MM‑connection and the location service support shall be regarded as being established.

5.2.2 Location service support establishment at the terminating side

At the terminating side a location service support is regarded as being established when an MM‑connection is established. According 3GPP TS 04.08 this can be ascertained by the receipt of the first message, with a new transaction identifier. For successful establishment of location service support this message shall be a REGISTER message.

If the terminating side needs to reject the establishment of location services support then it may be immediately initiate location services support release (see subclause 5.4).

5.3 Location service support information transfer phase

After the establishment of the location service support both users may exchange FACILITY messages by use of the location service support.

5.4 Location service support release

At the end of each location service procedure the established location service support is released, if a permanent connection is not used.

The side closing the transaction shall release the transaction by sending the RELEASE COMPLETE message to its corresponding peer entity.

Both location service support entities release the MM‑connection locally.

5.5 Recovery procedures

The location service support does not provide recovery procedures, i.e. the operations are transparent to the location service support.

5.6 Message flow (single operation example)

This subclause contains examples of message flows for a single transaction consisting of a single operation. These examples may not show all possibilities.

5.6.1 LMU initiated location service transaction

LMU Network

REGISTER

————————————————————————————————————————————>

Facility (Invoke = Operation (Location service code, Parameter(s)))

RELEASE COMPLETE or FACILITY

<————————————————————————————————————————————

Facility (Return result = Operation (Parameter(s)))

RELEASE COMPLETE or FACILITY

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Return error (Error))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Reject (Invoke_problem))

RELEASE COMPLETE (note)

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

RELEASE COMPLETE (note)

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – >

NOTE: To prevent transactions being kept open following exceptional cases, either side of the transaction may release it by sending a RELEASE COMPETE message without a Facility IE.

Figure 3.1: LMU initiated location service transaction

5.6.2 Network initiated location service transaction

LMU Network

REGISTER

<————————————————————————————————————————————

Facility (Invoke = Operation (Location service code, Parameter(s)))

RELEASE COMPLETE or FACILITY (note 1)

————————————————————————————————————————————>

Facility (Return result = Operation (Parameter(s))

RELEASE COMPLETE or FACILITY (note 1)

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – ->

Facility (Return error (Error))

RELEASE COMPLETE (note 1)

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – ->

Facility (Reject (Invoke_problem))

RELEASE COMPLETE (note 1, note 2)

– – – – — – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – ->

RELEASE COMPLETE (note 2)

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

NOTE 1: If the network initiated operation does not require a result, reject or error to be returned then the LMU may release the transaction by sending a RELEASE COMPLETE message without a Facility Information Element and release of transaction by LMU is allowed (i.e. Release Forbidden has not been present in Register message). If release is not allowed by LMU, the LMU sends the result using Facility message.

NOTE 2: To prevent transactions being kept open following exceptional cases, either side of the transaction may release it by sending a RELEASE COMPETE message without a Facility IE.

Figure 3.2: Network initiated location service transaction

5.7 Handling of unknown, unforeseen, and erroneous protocol data

5.7.1 General

These procedures only apply to messages where the protocol discriminator is set to indicate LCS operations according to the rules in 3GPP TS 04.07 and this specification. Messages that do not meet this criteria are treated according to other GSM technical specifications.

This subclause specifies procedures for handling of unknown, unforeseen and erroneous protocol data by the receiving entity. The procedures are called "error handling procedures", but they also define a compatibility mechanism for future extension of the protocol.

Most error handling procedures are mandatory in the LMU, but optional in the network. Detailed error handling procedures may vary from PLMN to PLMN.

In this subclause, the following terminology is used:

– An IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved" in this specification or 3GPP TS 04.08. However, it is not a syntactical error if a type 4 IE specifies a length indicator greater than that defined. The component part of the Facility information element is handled by a separate mechanism, and errors in the component part are not covered by this subclause.

The following procedures are listed in order of precedence.

Handling of errors in the contents of the Facility IE is described in subclause 4.2.6, and is outside the scope of this subclause.

5.7.2 Message too short

When a message is received that is too short to contain a complete message type information element, that message shall be ignored.

5.7.3 Unknown or unforeseen transaction identifier

The LMU shall ignore messages with the transaction identifier value set to "111".

If the transaction identifier value is not "111" the following procedures shall apply to the LMU:

a) If a RELEASE COMPLETE message is received specifying a transaction identifier that is not recognized as relating to a LCS transaction that is in progress then the message shall be ignored.

b) If a FACILITY message is received specifying a transaction identifier that is not recognized as relating to a LCS transaction that is in progress then a RELEASE COMPLETE message shall be sent.

c) If a REGISTER message is received specifying a transaction identifier that is not recognized as relating to a LCS transaction that is in progress and with a transaction identifier flag incorrectly set to "1", this message shall be ignored.

The network may follow the same procedures.

5.7.4 Unknown or unforeseen message type

If the LMU receives a message type not defined for the protocol discriminator or not implemented by the receiver, then a RELEASE COMPLETE message shall be sent with cause value #97 "message type non‑existent or not implemented".

If the LMU receives a message type not consistent with the transaction state then a RELEASE COMPLETE message shall be sent with cause value #98 "message not compatible with control state".

The network may follow the same procedures.

5.7.5 Non‑semantical mandatory Information Element Error

When on receipt of a message:

– an "imperative message part" error; or

– a "missing mandatory IE" error;

is diagnosed, or when a message containing:

– a syntactically incorrect mandatory IE; or

– an IE unknown in the message, but encoded as "comprehension required" (see 3GPP TS 04.08); or

– an out of sequence IE encoded as "comprehension required";

is received, the LMU shall proceed as follows:

a) If the message is not RELEASE COMPLETE it shall send a RELEASE COMPLETE message with cause "#96 ‑ Invalid mandatory information".

b) If the message is RELEASE COMPLETE, it shall be treated as a normal RELEASE COMPLETE message.

The network may follow the same procedures.

5.7.6 Unknown and Unforeseen IEs in the non‑imperative part

5.7.6.1 IEIs unknown in the message

The LMU shall ignore all IEs unknown in the message which are not encoded as "comprehension required". The network shall take the same approach.

5.7.6.2 Out of sequence IEs

The LMU shall ignore all out of sequence IEs in a message which are not encoded as "comprehension required".

The network may take the same approach.

5.7.6.3 Repeated IEs

If an information element with format T, TV or TLV (see 3GPP TS 04.07) is repeated in a message in which repetition of the information element is not specified, only the contents of the information element appearing first shall be handled and all subsequent repetitions of the information element shall be ignored. When repetition of information elements is specified, only the contents of specified repeated information elements shall be handled. If the limit on repetition of information elements is exceeded, the contents of information elements appearing first up to the limit of repetitions shall be handled and all subsequent repetitions of the information element shall be ignored.

The network may follow the same procedures.

5.7.7 Non‑imperative message part errors

This category includes:

– syntactically incorrect optional IEs;

– conditional IE errors.

Errors in the content of the Facility IE are handled according to subclause 4.2.6.

5.7.7.1 Syntactically incorrect optional IEs (other than Facility)

The LMU shall treat all optional IEs that are syntactically incorrect in a message as not present in the message

The network shall take the same approach.

5.7.7.2 Conditional IE errors

When the LMU upon receipt of a message diagnoses a "missing conditional IE" error, or an "unexpected conditional IE error", or when it receives a message containing at least one syntactically incorrect conditional IE (other than Facility), it shall send a RELEASE COMPLETE message with cause #100 "conditional IE error".

The network may follow the same procedure.