5.5 Miscellaneous procedures

24.0083GPPCore network protocolsMobile radio interface Layer 3 specificationRelease 18Stage 3TS

5.5.1 In-band tones and announcements

When the network wants to make the mobile station attach the user connection (e.g. in order to provide in-band tones/announcement) before the mobile station has reached the "active" state of a call, the network may include a progress indicator IE indicating user attachment in a suitable CC message:

– Either it includes the IE in a SETUP, CALL PROCEEDING, ALERTING, or CONNECT message that is send during call establishment

– it sends a PROGRESS message containing the IE.

A progress indicator IE indicates user attachment if it specifies a progress description in the set {1, 2, 3} or in the set {6, 7, 8, …, 20}.

On reception of a SETUP, CALL PROCEEDING, ALERTING, CONNECT, or PROGRESS message the mobile station shall proceed as specified elsewhere in clause 5; if the progress indicator IE indicated user attachment and a speech mode traffic channel is appropriate for the call the mobile station shall in addition: attach the user connection for speech as soon as an appropriate channel in speech mode is available. (If a new order to attach the user connection is received before the attachment has been performed, the new order shall supersede the previous one.)

Under certain conditions the MS will have to attach the user connection before the CONNECT message. It is up to the network to ensure that no undesired end-to-end through connection takes place during the establishment of a MT call.

NOTE: This allows the use of progress indicator IEs independently from the channel modes appropriate for the call.

The network may generate multimedia CAT to a mobile station supporting multimedia CAT during the alerting phase of a mobile originated multimedia call establishment as specified in subclause 5.3.6.4.

5.5.2 Call collisions

Call collisions as such cannot occur at the network. Any simultaneous mobile originating or mobile terminating calls are dealt with separately assigned and different transaction identifiers.

5.5.3 Status procedures

5.5.3.1 Status enquiry procedure

Whenever a call control entity wishes to check the call state of its peer entity, it may initiate the status enquiry procedure.

NOTE: This may, in particular, apply to procedural error conditions described in clause 8.

A call control entity initiates the status enquiry procedure by sending the STATUS ENQUIRY message and starting timer T322. The value of T322 is implementation dependent in the MS and set in the network by the network operator. While timer T322 is running, the call control entity shall not send further STATUS ENQUIRY messages.

Upon receipt of a STATUS ENQUIRY message, the receiver shall respond with a STATUS message, reporting the current call state and cause value #30 "response to STATUS ENQUIRY". Receipt of the STATUS ENQUIRY shall not result in a state change relating to any protocol and connection of the receiver.

If a STATUS message is received that contains cause value #30 "response to status enquiry", timer T322 shall be stopped and further appropriate actions taken, based on the information in that STATUS message, relative to the current state of the receiver of the STATUS message. These further "appropriate actions" are implementation dependent. However, the actions prescribed in subclause 5.5.3.2 shall apply.

If a clearing message is received while timer T322 is running, timer T322 shall be stopped, and call clearing shall continue.

If timer T322 expires, the STATUS ENQUIRY message may be retransmitted maximally once. If T322 expires after the STATUS ENQUIRY has been transmitted the maximum number of times, clearing of the call shall be initiated with cause value #41, "temporary failure", in the first call clearing message.

5.5.3.2 Reception of a STATUS message by a CC entity

5.5.3.2.1 STATUS message with incompatible state

On receipt of a STATUS message reporting an incompatible call control state, the receiving entity shall clear the call by sending a RELEASE COMPLETE message with cause # 101 "message not compatible with protocol state". The reported call control state is incompatible if the combination of call control states at the sender and receiver side cannot occur, do not match or cannot be aligned by actions of the receiver; the exact definition is implementation dependent.

5.5.3.2.2 STATUS message with compatible state

A STATUS message may be received indicating a compatible call state but containing one of the following causes:

# 95 "semantically incorrect message"; or

# 96 "invalid mandatory information"; or

# 97 "message type non-existent or not implemented"; or

# 98 "message type not compatible with protocol state"; or

# 99 "information element non-existent or not implemented"; or

# 100 "conditional IE error".

This indicates that the transmitter of the STATUS message was unable to accept some information sent by the recipient of the STATUS message. This allow the recipient to retransmit some or all of the information. Other actions are possible and are implementation dependent; they may include releasing the call.

In the case the MS receives a STATUS message with the cause #100 due to the presence of a Repeat Indicator with the value "service change and fallback" in a SETUP message, it may then resend a new SETUP message with a single BC-IE (no Repeat Indicator is included). The actual behaviour is dependent on the implementation.

In the case the network receives a STATUS message with the cause #100 due to the presence of a Repeat Indicator with the value "service change and fallback" in a SETUP message, it shall then resend a new SETUP message, with either the BC-IE of the preferred service or the speech BC-IE (fallback to speech) as the only BC (no Repeat Indicator is included). The preferred behaviour is decided by configuration.

5.5.4 Call re-establishment, mobile station side

This subclause describes the internal handling in the mobile station as far as call control is concerned.

5.5.4.1 Indication from the mobility management sublayer

When a MM connection is active, an indication may be given by the MM sublayer to the call control entity to announce that the current MM connection has been interrupted but might be re-established on request of call control.

5.5.4.2 Reaction of call control

Depending whether call re-establishment is allowed or not and on its actual state, call control shall decide to either request re-establishment or to release the MM connection.

a) Re-establishment not required

If the call is in the call establishment or call clearing phase, i.e. any state other than the "active" state or the "mobile originating modify" state, call control shall release the MM connection

b) Re-establishment required

If the call is in the "active" state or "mobile originating modify" state, the indication from MM that re-establishment is possible shall cause call control to request re-establishment from the MM connection, suspend any further message to be sent and await the completion of the re-establishment procedure.

5.5.4.3 Completion of re-establishment

Call Control is notified when the MM connection is re-established and shall then resume the transmission of possibly suspended messages and resume user data exchange when an appropriate channel is available.

5.5.4.4 Unsuccessful outcome

If the attempt to re-establish the connection was unsuccessful, the MM connection will be released and a release indication will be given to call control, see subclause 4.5.1.6.

5.5.5 Call re-establishment, network side

This subclause describes the handling in the network as far as call control is concerned.

5.5.5.1 State alignment

After a successful call re-establishment it is a network responsibility to identify (e.g. by using the status enquiry procedure, if needed, and resolve, if possible, any call state or auxiliary state mismatch between the network and the mobile station.

5.5.6 Progress

At any time during the establishment or release of a call and during an active call the network may send a PROGRESS message to the mobile station.

On receipt of a PROGRESS message during the establishment or release of a call the mobile station shall stop all call control timers related to that call.

NOTE: If the PROGRESS has been received before the receipt of a CALL PROCEEDING message, the mobile station will not start timer T310 on receipt of a CALL PROCEEDING message, see subclause 5.2.1.1.3.

Figure 5.11/3GPP TS 24.008 Progress

5.5.7 DTMF protocol control procedure

Dual Tone Multi Frequency (DTMF) is an inband one out of four plus one out of four signalling system primarily used from terminal instruments in telecommunication networks. The support of DTMF in the network is described in 3GPP TS 23.014 [12].

The mobile station shall be capable of transmitting DTMF messages as specified in this subclause if and only if the mobile station has the user connection for speech attached and an appropriate channel is available.

The transaction identifier used by the DTMF messages shall be that of the attached speech call.

NOTE 1: The present document means that DTMF messages can generally be sent in the active state of a call in speech transmission mode or when a traffic channel is available during setup or release and the progress indicator IE has been received.

NOTE 2: Since the DTMF protocol messages are sent in a store and forward mode on the signalling channels the control of the device at the far end may be delayed dependent on the load or quality of the channels.

NOTE 3: The procedures described in this paragraph support DTMF only in the direction mobile station to network.

A mobile station supporting multimedia CAT during the alerting phase of a mobile originated multimedia call establishment should also be capable of transmitting DTMFs during a multimedia call as specified in subclause 5.3.6.5.

5.5.7.1 Start DTMF request by the mobile station

A user may cause a DTMF tone to be generated e.g. by depression of a key in the mobile station. The relevant action is interpreted by the mobile station as a requirement for a DTMF digit to be sent in a START DTMF message on an established FACCH. This message contains the value of the digit to be transmitted (0, 1, …, 9, A, B, C, D, *, #).

Only a single digit will be transferred in each START DTMF message.

On sending a START DTMF message the MS shall start timer T336.

Where a previous START DTMF message has been sent, another START DTMF message shall only be sent by the MS following receipt of its STOP DTMF ACKNOWLEDGE message (see subclause 5.5.7.4) or a START DTMF REJECT message from the network (see subclause 5.5.7.2) or following the expiry of timers T336 and T337.

If timer T336 expires, the MS shall terminate the ongoing DTMF procedure without any retransmissions, and is free to begin another DTMF procedure (e.g. another START DTMF message).

5.5.7.2 Start DTMF response by the network

Upon receiving the START DTMF message the network shall either:

– convert the received digit into a DTMF tone which is applied toward the remote user, or

– send the DTMF digit as an out-of-band message (see 3GPP TS 23.205 [96])

and return a START DTMF ACKNOWLEDGE message to the mobile station. This acknowledgement may be used in the mobile station to generate an indication as a feedback for a successful transmission.

If the network cannot accept the START DTMF message a START DTMF REJECT message will be sent to the mobile station. Upon receipt of a START DTMF ACK message or a START DTMF REJECT message, the MS shall stop timer T336.

5.5.7.3 Stop DTMF request by the mobile station

When the user indicates that the DTMF sending should cease e.g. by releasing the key the mobile station will send a STOP DTMF message to the network.

On sending a STOP DTMF message the MS shall start timer T337.

The MS shall only send a STOP DTMF message if a START DTMF ACKNOWLEDGE message has been received from the network (see subclause 5.5.7.2).

If timer T337 expires, the MS shall terminate the ongoing DTMF procedure without any retransmissions, and is free to begin another DTMF procedure. (e.g. another START DTMF message).

5.5.7.4 Stop DTMF response by the network

Upon receiving the STOP DTMF message the network shall either:

– stop sending the DTMF tone if applied by the network, or

– initiate a suitable out-of-band message (see 3GPP TS 23.205 [96])

and return a STOP DTMF ACKNOWLEDGE message to the mobile station. Upon receipt of a STOP DTMF ACKNOWLEDGE message, the MS shall stop timer T337.

5.5.7.5 Sequencing of subsequent start DTMF requests by the mobile station

If the network is generating DTMF tones it shall ensure that the minimum length of tone and the minimum gap between two subsequent tones (according to ETSI ES 201 235-2 [12a]) is achieved.

NOTE 1: In ETSI ES 201 235-2 [12a] the minimum duration of a DTMF tone is 65ms.

NOTE 2: In ETSI ES 201 235-2 [12a] the minimum gap between DTMF tones is 65ms.

There is no defined maximum length to the tone, which will normally cease when a STOP DTMF message is received from the MS. However, the operator may choose to put a pre-defined time limit on the duration of tones sent.

The appropriate sequencing of DTMF control messages is shown in figures 5.8 and 5.9.

NOTE 3: The network may implement the time limit option where the DTMF tone duration is controlled by the network irrespective of the receipt of a STOP DTMF message from the mobile station.

Figure 5.8/3GPP TS 24.008 Single DTMF transmission

Figure 5.9/3GPP TS 24.008 Multiple DTMF transmission