## 5 Elementary procedures for circuit-switched Call Control

04.083GPPMobile radio interface Layer 3 specificationRelease 1998TS

## 5.1 Overview

### 5.1.1 General

This sub-clause describes the call control (CC) protocol, which is one of the protocols of the Connection Management (CM) sublayer (see 3GPP TS 04.07).

Every mobile station must support the call control protocol. If a mobile station does not support any bearer capability at all then it shall respond to a SETUP message with a RELEASE COMPLETE message as specified in sub-clause 5.2.2.2.

In the call control protocol, more than one CC entity are defined. Each CC entity is independent from each other and shall communicate with the correspondent peer entity using its own MM connection. Different CC entities use different transaction identifiers.

With a few exceptions the present document describes the call control protocol only with regard to two peer entities. The call control entities are described as communicating finite state machines which exchange messages across the radio interface and communicate internally with other protocol (sub)layers. This description is only normative as far as the consequential externally observable behaviour is concerned.

Certain sequences of actions of the two peer entities compose "elementary procedures" which are used as a basis for the description in this sub-clause. These elementary procedures may be grouped into the following classes:

– call establishment procedures;

– call clearing procedures;

– call information phase procedures;

– miscellaneous procedures.

The terms "mobile originating" or "mobile originated" (MO) are used to describe a call initiated by the mobile station. The terms "mobile terminating" or "mobile terminated" (MT) are used to describe a call initiated by the network.

Figure 5.1a/3GPP TS 04.08 gives an overview of the main states and transitions on the mobile station side.

The MS side extension figure 5.1a.1/3GPP TS 04.08 shows how for the Network Initiated MO call the MS reaches state U1.0 from state U0 $(CCBS)$.

Figure 5.1b/3GPP TS 04.08 gives an overview of the main states and transitions on the network side.

The Network side extension figure 5.1b.1/3GPP TS 04.08 shows for Network Initiated MO Calls the Network reaches state N1.0 from state N0 $(CCBS)$.

Figure 5.1a/3GPP TS 04.08: Overview call control protocol/MS side

Figure5.1a.1/3GPP TS 04.08: Overview call control protocol/MS side, extension:

Figure 5.1b/3GPP TS 04.08: Overview call control protocol/Network side

Figure 5.1b.1/3GPP TS 04.08: Overview call control protocol/Network side, extension:

### 5.1.2 Call Control States

#### 5.1.2.1 Call states at the mobile station side of the interface

The states which may exist on the mobile station side of the radio interface are defined in this sub-clause.

NOTE: States U0.1, U0.2, U0.3, U0.4, U0.5, U0.6, U26, and U27 are GSM specific. All other states are ITU-T defined.

No call exists.

##### 5.1.2.1.2 MM Connection pending (U0.1)

This state exists for a mobile originating call, when the mobile station requests the establishment of a MM connection.

##### 5.1.2.1.2a CC prompt present (U0.2) $(CCBS)$

This state exists for a mobile originating call when the network has prompted the mobile station to establish a CC connection but the mobile station has not yet responded.

NOTE: This state is transient.

##### 5.1.2.1.2b Wait for network information (U0.3) $(CCBS)$

This state exists for a mobile originating call when the mobile station has responded to the prompt from the network to establish a CC connection and the mobile station is waiting for further information from the network.

##### 5.1.2.1.2c CC-Establishment present (U0.4) $(CCBS)$

This state exists for a mobile originating call when the mobile station has received a CC-establishment request but has not yet responded.

NOTE: This state is transient.

##### 5.1.2.1.2d CC-Establishment confirmed (U0.5) $(CCBS)$

This state exists for a mobile originating call when the mobile station has sent the acknowledgement that the mobile station has received all the CC information that is needed.

##### 5.1.2.1.2e Recall present (U0.6) $(CCBS)$

This state exists for a mobile originating call when the mobile station has received a recall request but has not yet responded.

NOTE: This state is transient.

##### 5.1.2.1.3 Call initiated (U1)

This state exists for a mobile originating call, when the MS requests call establishment from the network.

##### 5.1.2.1.4 Mobile originating call proceeding (U3)

This state exists for a mobile originating call when the mobile station has received acknowledgement that the network has received all call information necessary to effect call establishment.

##### 5.1.2.1.5 Call delivered (U4)

This state exists for a mobile originating call, when the calling mobile station has received an indication that remote user alerting has been initiated.

##### 5.1.2.1.6 Call present (U6)

This state exists for a mobile terminating call when the mobile station has received a call establishment request but has not yet responded.

This state exists for a mobile terminating call when the mobile station has indicated alerting but has not yet answered.

##### 5.1.2.1.8 Connect Request (U8)

This state exists for a mobile terminating call, when the mobile station has answered the call and is waiting to be awarded the call.

##### 5.1.2.1.9 Mobile terminating call confirmed (U9)

This state exists for a mobile terminating call when the mobile station has sent acknowledgement that the mobile station has received all call information necessary to effect call establishment.

##### 5.1.2.1.10 Active (U10)

This state exists for a mobile terminating call when the MS has answered the call. This state exists for a mobile originating call when the MS has received an indication that the remote user has answered the call.

##### 5.1.2.1.11 Disconnect request (U11)

This state exists when the mobile station has requested the network to clear the end-to-end connection (if any) and is waiting for a response.

##### 5.1.2.1.12 Disconnect indication (U12)

This state exists when the mobile station has received an invitation to disconnect because the network has disconnected the end-to-end connection (if any).

##### 5.1.2.1.13 Release request (U19)

This state exists when the MS has requested the network to release and is waiting for a response.

##### 5.1.2.1.14 Mobile originating modify (U26)

This state exists when the mobile station has sent a request to the network for a new mode but has not yet received an answer.

##### 5.1.2.1.15 Mobile terminating modify (U27)

This state exists when the mobile station has received a request from the network for a new mode and has not yet sent a response to this request.

#### 5.1.2.2 Network call states

NOTE: States N0.1, N0.2, N0.3, N0.4, N0.5, N0.6, N26, N27, N28, N3a, N4,a, N7a, and N9a are GSM specific. All other states are ITU-T defined.

The call states that may exist on the network side of the radio interface are defined in this sub-clause.

No call exists.

##### 5.1.2.2.2 MM connection pending (N0.1)

This state exists for a mobile terminating call, when the network requests the establishment of a MM connection.

##### 5.1.2.2.2a CC connection pending (N0.2) $(CCBS)$

This state exists for a mobile originating call when the network has requested the mobile station to establish a CC connection.

##### 5.1.2.2.2b Network answer pending (N0.3) $(CCBS)$

This state exists for a mobile originating call when the mobile station has established a CC connection upon the request of the network, but the network has not yet informed the mobile station of the reason for the network’s action.

##### 5.1.2.2.2c CC-Establishment present (N0.4) $(CCBS)$

This state exists for a mobile originating call when the network has sent a CC establishment request but has not yet received a satisfactory response.

##### 5.1.2.2.2d CC-Establishment confirmed (N0.5) $(CCBS)$

This state exists for a mobile originating call when the network has received acknowledgement that the mobile station has received all call information necessary to effect call establishment.5.1.2.2.2e Recall present (N0.6) $(CCBS)$

This state exists for a mobile originating call when the network has sent a recall request but has not yet received a satisfactory response.

##### 5.1.2.2.3 Call initiated (N1)

This state exists for a mobile originating call when the network has received a call establishment request but has not yet responded.

##### 5.1.2.2.4 Mobile originating call proceeding (N3)

This state exists for a mobile originating call when the network has sent acknowledgement that the network has received all call information necessary to effect call establishment.

##### 5.1.2.2.5 Call delivered (N4)

This state exists for a mobile originating call when the network has indicated that remote user alerting has been initiated.

##### 5.1.2.2.6 Call present (N6)

This state exists for a mobile terminating call when the network has sent a call establishment request but has not yet received a satisfactory response.

This state exists for a mobile terminating call when the network has received an indication that the mobile station is alerting but has not yet received an answer.

##### 5.1.2.2.8 Connect request (N8)

This state exists for a mobile terminating call when the network has received an answer but the network has not yet awarded the call.

##### 5.1.2.2.9 Mobile terminating call confirmed (N9)

This state exists for a mobile terminating call when the network has received acknowledgement that the mobile station has received all call information necessary to effect call establishment.

##### 5.1.2.2.10 Active (N10)

This state exists for a mobile terminating call when the network has awarded the call to the called mobile station. This state exists for a mobile originating call when the network has indicated that the remote user has answered the call.

##### 5.1.2.2.12 Disconnect indication (N12)

This state exists when the network has disconnected the end- to-end connection (if any) and has sent an invitation to disconnect the mobile station to network connection.

##### 5.1.2.2.13 Release request (N19)

This state exists when the network has requested the MS to release and is waiting for a response.

##### 5.1.2.2.14 Mobile originating modify (N26)

This state exists when the network has received a request from the mobile station for a new mode but has not yet sent a response.

##### 5.1.2.2.15 Mobile terminating modify (N27)

This state exists when the network has sent a request to the mobile station for a new mode but has not yet received an answer.

##### 5.1.2.2.16 Connect Indication (N28)

This state exists for a mobile originating call when the network has indicated that the remote user has answered the call and the network is waiting for acknowledgement by the mobile station.

## 5.2 Call establishment procedures

Establishment of a call is initiated by request of upper layer in either the mobile station or the network; it consists of:

– the establishment of a CC connection between the mobile station and the network;

– the activation of the codec or interworking function.

Whenever it is specified in 3GPP TS 04.08, clause 5 that the mobile station shall attach the user connection, this means that the mobile station shall activate the codec or interworking function as soon as an appropriate channel is available. The mobile station shall de-activate the codec or interworking function whenever an appropriate channel is no longer available. As soon as an appropriate channel is (again) available, the codec or interworking function shall be re-activated. If a new order to attach the user connection is received, the new order shall supersede the previous one.

A channel shall be considered as appropriate if it is consistent with the possibly negotiated bearer capability applicable for the actual phase of the call. The mobile station shall not consider a channel as not appropriate because the type of the channel (full rate/half rate) is not the preferred one. If:

– the user connection has to be attached but no appropriate channel is available for a contiguous time of 30 seconds; or if

– the codec or interworking function is de-activated for a contiguous time of 30 seconds;

then the mobile station may initiate call clearing.

Upon request of upper layers to establish a call, restricting conditions for the establishment of the call are examined. These restricting conditions concern the states of parallel CC entities and are defined elsewhere. If these restricting conditions are fulfilled, the call establishment is rejected. Otherwise a CC entity in state U0, "null", is selected to establish the call. It initiates the establishment by requesting the MM sublayer to establish an MM connection.

### 5.2.1 Mobile originating call establishment

The call control entity of the mobile station initiates establishment of a CC connection by requesting the MM sublayer to establish a mobile originating MM connection and entering the "MM connection pending" state. There are two kinds of a mobile originating call: basic call and emergency call. The request to establish an MM connection shall contain a parameter to specify whether the call is a basic or an emergency call. This information may lead to specific qualities of services to be provided by the MM sublayers. Timer T303 is started when the CM SERVICE REQUEST message is sent.

For mobile stations supporting eMLPP basic calls may optionally have an associated priority level as defined in 3GPP TS 03.67. This information may also lead to specified qualities of service to be provided by the MM sublayers.

While being in the "MM connection pending" state, the call entity of the mobile station may cancel the call prior to sending the first call control message according to the rules given in sub-clause 4.5.1.7.

Having entered the "MM connection pending" state, upon MM connection establishment, the call control entity of the mobile station sends a setup message to its peer entity. This setup message is

– a SETUP message, if the call to be established is a basic call, and

– an EMERGENCY SETUP message, if the call to be established is an emergency call.

It then enters the "call initiated" state. Timer T303 is not stopped.

The setup message shall contain all the information required by the network to process the call. In particular, the SETUP message shall contain the called party address information.

If timer T303 elapses in the "MM connection pending" state, the MM connection in progress shall be aborted and the user shall be informed about the rejection of the call.

#### 5.2.1.1 Call initiation

The "call initiated" state is supervised by timer T303.For normal MO calls, this timer will have already been started after entering the "MM connection pending" state. For network-initiated MO calls this timer will be started in the recall present state as defined in sub-clause 5.2.3.4.

When the call control entity of the mobile station is in the "call initiated" state and if it receives:

i) a CALL PROCEEDING message, it shall proceed as described in sub-clause 5.2.1.3;

ii) an ALERTING message, it shall proceed as described in sub-clause 5.2.1.5;

iii) a CONNECT message, it shall proceed as described in sub-clause 5.2.1.6;

iv) a RELEASE COMPLETE message it shall proceed as described in sub-clause 5.2.1.2.

Abnormal case:

– If timer T303 elapses in the "call initiated" state before any of the CALL PROCEEDING, ALERTING, CONNECT or RELEASE COMPLETE messages has been received, the clearing procedure described in sub-clause 5.4 is performed.

#### 5.2.1.2 Receipt of a setup message

In the "null" or "recall present" states, upon receipt of a setup message (a SETUP message or an EMERGENCY SETUP message, see sub-clause 5.2.1.1), the call control entity of the network enters the "call initiated" state. It shall then analyse the call information contained in the setup message.

i) If, following the receipt of the setup message, the call control entity of the network determines that the call information received from the mobile station is invalid (e.g. invalid number), then the network shall initiate call clearing as defined in sub-clause 5.4 with one of the following cause values:

# 1 "unassigned (unallocated) number"

# 3 "no route to destination"

# 22 "number changed"

# 28 "invalid number format (incomplete number)"

ii) If, following the receipt of the setup message, the call control entity of the network determines that a requested service is not authorized or is not available, it shall initiate call clearing in accordance with sub-clause 5.4.2 with one of the following cause values:

# 8 "operator determined barring",

# 57 "bearer capability not authorized",

# 58 "bearer capability not presently available",

# 63 "service or option not available, unspecified", or

# 65 "bearer service not implemented".

iii) Otherwise, the call control entity of the network shall either:

– send a CALL PROCEEDING message to its peer entity to indicate that the call is being processed; and enter the "mobile originating call proceeding" state.

– or: send an ALERTING message to its peer entity to indicate that alerting has been started at the called user side; and enter the "call received" state.

– or: send a CONNECT message to its peer entity to indicate that the call has been accepted at the called user side; and enter the "connect request" state.

The call control entity of the network may insert bearer capability information element(s) in the CALL PROCEEDING message to select options presented by the mobile station in the Bearer Capability information element(s) of the SETUP message. The bearer capability information element(s) shall contain the same parameters as received in the SETUP except those presenting a choice. Where choices were offered, appropriate parameters indicating the results of those choices shall be included.

The CALL_PROCEEDING message may also contain the priority of the call in the case where eMLPP is applied and where the network has assigned a different priority to the call than that requested by the user, or where the user has not requested a priority and the network has assigned a default priority. Mobile stations supporting eMLPP shall indicate this priority level to higher sublayers and store this information for the duration of the call for further action. Mobile stations not supporting eMLPP shall ignore this information element if provided in a CALL PROCEEDING message.

The call control entity of the network having entered the "mobile originating call proceeding" state, the network may initiate the assignment of a traffic channel according to sub-clause 5.2.1.9 (early assignment).

MS Network

+—————————–+

│ │

│ (EMERGENCY) SETUP │

│ ———————-> │

│ │

+—————————–+

CALL_PROCEEDING (i)

< – – – – – – – – – – – –

< – – – – – – – – – – – –

CONNECT (iii)

< – – – – – – – – – – – –

RELEASE COMPLETE (iv)

< – – – – – – – – – – – –

Figure 5.2/3GPP TS 04.08: Mobile originated call initiation and possible subsequent responses

#### 5.2.1.3 Receipt of a CALL PROCEEDING message

Having entered the "call initiated" state, when the call control entity of the mobile station receives a CALL PROCEEDING message, it shall stop timer T303; start timer T310 unless

– the CALL PROCEEDING message contains a progress indicator IE specifying progress description #1, #2, or #64; or

– it has received a PROGRESS message containing a progress indicator IE specifying progress description #1, #2, or #64 prior to the CALL PROCEEDING message

and enter the "mobile originating call proceeding" state.

Abnormal case:

If timer T310 elapses before any of the ALERTING, CONNECT or DISCONNECT messages has been received, the mobile station shall perform the clearing procedure described in sub-clause 5.4.

MS Network

+—————————+

│ │

│ CALL PROCEEDING │

│ <——————– │

│ │

+—————————+

Figure 5.3/3GPP TS 04.08: Call proceeding sequence at mobile originating call establishment

#### 5.2.1.4 Notification of progressing mobile originated call

In this sub-clause, the term "interworking" is used only in the meaning of interworking with a network other than PLMN or ISDN, not as interworking between PLMN and ISDN since this is the normal case. In this sense, PLMN and ISDN are seen within the same environment, called the PLMN/ISDN environment.

##### 5.2.1.4.1 Notification of interworking in connection with mobile originated call establishment

During call establishment, the call may leave a PLMN/ISDN environment; e.g., because of interworking with another network, with a non-PLMN/ISDN user, or with non-PLMN/ISDN equipment within the called user’s premises; the call may also return to a PLMN/ISDN environment. When such situations occur, the network may send a progress indicator information element to the calling mobile station either:

a) in an appropriate call control message, if a state change is required (e.g. ALERTING or CONNECT); or,

b) in the PROGRESS message, if no state change is appropriate.

This progress indicator information element shall contain one of the following progress description values:

a) #1 "call is not end-to-end PLMN/ISDN; further call progress information may be available in-band".

b) #2 "destination address is non-PLMN/ISDN".

c) #4 "call has returned to PLMN/ISDN.

See also sub-clauses 5.5.1 and 5.5.6 for further reactions of the mobile station.

##### 5.2.1.4.2 Call progress in the PLMN/ISDN environment

In order to inform the mobile station that the call is progressing in the PLMN/ISDN environment the network may send a progress indicator information element to the calling mobile station either:

a) in an appropriate call control message, if a state change is required (e.g., ALERTING or CONNECT); or

b) in the PROGRESS message, if no state change is appropriate.

This progress indicator information element shall contain progress description value #32 "Call is end-to-end ISDN/PLMN". See also sub-clause 5.5.6 for further reactions of the mobile station.

Having entered the "mobile originating call proceeding" state, upon receiving an indication that user alerting has been initiated at the called address, the call control entity of the network shall: send an ALERTING message to its peer entity at the calling mobile station and enter the "call delivered" state.

When the call control entity of the mobile station in the "call initiated" state or "mobile originating call proceeding" state receives an ALERTING message then, the call control entity of the mobile station shall stop timer T303 and T310 (if running) and shall enter the "call delivered" state. In this state, for speech calls:

– an alerting indication should be given to the user. If the mobile station has not attached the user connection then the mobile station shall internally generate an alerting indication. If the mobile station has attached the user connection then the network is responsible for generating the alerting indication and the mobile station need not generate one.

Abnormal cases:

On the mobile station side, if timer T310 expires, the call control entity of the mobile station shall initiate call clearing as described in sub-clause 5.4.

MS Network

+———————+

│ │

│ <————– │

│ │

+———————+

Figure 5.4/3GPP TS 04.08: Call confirmation at mobile originating call establishment

#### 5.2.1.6 Call connected

Upon receiving an indication that the call has been accepted, the call control entity of the network shall: through connect the traffic channel (including the connection of an interworking function, if required) and send a CONNECT message to its peer entity at the calling mobile station; start timer T313 and enter the "connect indication" state.

This message indicates to the call control entity of the calling mobile station that a connection has been established through the network.

The call control entity of the mobile station in the "call initiated" state, in the "mobile originating call proceeding" state or in the "call delivered" state, shall, upon receipt of a CONNECT message:

– attach the user connection;

– return a CONNECT ACKNOWLEDGE message;

– stop any locally generated alerting indication (if applied);

– stop timer T303 and T310 (if running);

– enter the "active" state.

Abnormal cases:

– On the mobile station side, if timer T303 or T310 expires, the call control entity of the mobile station shall initiate call clearing as described in sub-clause 5.4.

NOTE: The mobile station may have applied an additional internal alerting supervision which causes initiation of call clearing prior to the expiry of T303 or T310.

The call control of the network in the "connect indication" state, shall, upon receipt of a CONNECT ACKNOWLEDGE message:

– stop timer T313 and enter the "active" state.

Abnormal cases:

On the network side, if timer T313 elapses before a CONNECT ACKNOWLEDGE message has been received, the network shall perform the clearing procedure as described in sub-clause 5.4.

MS Network

+—————————–+

│ CONNECT │

│ <———————- │

│ CONNECT ACKNOWLEDGE │

│ ———————-> │

+—————————–+

Figure 5.5/3GPP TS 04.08: Call acceptance sequence at mobile originating call establishment

#### 5.2.1.7 Call rejection

Upon receiving an indication that the network or the called user is unable to accept the call, the network shall initiate call clearing at the radio interface to the mobile which originated the call, as described in sub-clause 5.4 using the cause provided by the terminating network or the called user.

#### 5.2.1.8 Transit network selection

NOTE: For further study.

#### 5.2.1.9 Traffic channel assignment at mobile originating call establishment

It is a network dependent decision when to initiate the assignment of an appropriate traffic channel during the mobile originating call establishment phase. Initiation of a suitable RR procedure to assign an appropriate traffic channel does neither change the state of a call control entity nor affect any call control timer.

NOTE: During certain phases of such an RR procedure, transmission of CC and MM messages may be suspended, see 3GPP TS 04.08, clause 3 and 3GPP TS 08.08.

The assignment procedure does not affect any call control timer.

#### 5.2.1.10 Call queuing at mobile originating call establishment

The conditions to apply queuing are described in 3GPP TS 03.01.

If an idle traffic channel is not available at the assignment instant, the network may place the traffic channel request in a queue. Calls arriving when all positions in the queue are occupied shall be cleared by the network using the cause #34 "no circuit/channel available".

The maximum queuing interval is supervised by the network. The limit is a network dependent choice. In case the network is not able to allocate a traffic channel within the queuing limit, the network will release the call using cause #34 "no circuit/channel available".

Optionally, e.g. if eMLPP is used, the network may decide to pre-empt existing calls or to place the traffic channel request at some preferential position within the queue.

Specific indications provided in the network to the remote user are a network dependent choice.

### 5.2.2 Mobile terminating call establishment

Before call establishment can be initiated in the mobile station, the MM connection must be established by the network.

#### 5.2.2.1 Call indication

After the arrival of a call from a remote user, the corresponding call control entity in the network shall: initiate the MM connection establishment according to clause 4 and enter the "MM connection pending" state. The request to establish the MM connection is passed from the CM sublayer to the MM sublayer. It contains the necessary routing information derived from the SETUP message.

Upon completion of the MM connection, the call control entity of the network shall: send the SETUP message to its peer entity at the mobile station, start timer T303 and enter the "call present" state.

Upon receipt of a SETUP message, the mobile station shall perform compatibility checking as described in 5.2.2.2. If the result of the compatibility checking was compatibility, the call control entity of the mobile station shall enter the "call present" state. An incompatible mobile station shall respond with a RELEASE COMPLETE message in accordance with sub-clause 5.2.2.3.4.

If no response to the SETUP message is received by the call control entity of the network before the expiry of timer T303, the procedures described in sub-clause 5.2.2.3.3 shall apply.

MS Network

+———————+

│ │

│ SETUP │

│ <————– │

│ │

+———————+

CALL_CONFIRMED (i)

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

RELEASE COMPLETE (ii)

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

Figure 5.6/3GPP TS 04.08: Mobile terminating call initiation and possible subsequent responses

#### 5.2.2.2 Compatibility checking

The mobile station receiving a SETUP message shall perform compatibility checking before responding to that SETUP message. Annex B defines compatibility checking to be performed by the mobile station upon receiving a SETUP message.

#### 5.2.2.3 Call confirmation

##### 5.2.2.3.1 Response to SETUP

Having entered the "call present state" the call control entity of the mobile station shall – with the exception of the cases described below – acknowledge the SETUP message by a CALL CONFIRMED message, and enter the "mobile terminating call confirmed" state.

The call control entity of the mobile station may include in the CALL CONFIRMED message to the network one or two bearer capability information elements to the network, either preselected in the mobile station or corresponding to a service dependent directory number (see 3GPP TS 09.07). The mobile station may also include one or two bearer capabilities in the CALL CONFIRMED message to define the radio channel requirements. In any case the rules specified in sub-clause 9.3.2.2 shall be followed.

NOTE: The possibility of alternative responses (e.g., in connection with supplementary services) is for further study.

A busy MS which satisfies the compatibility requirements indicated in the SETUP message shall respond either with a CALL CONFIRMED message if the call setup is allowed to continue or a RELEASE COMPLETE message if the call setup is not allowed to continue, both with cause #17 "user busy".

If the mobile user wishes to refuse the call, a RELEASE COMPLETE message shall be sent with the cause #21 "call rejected".

In the cases where the mobile station responds to a SETUP message with RELEASE COMPLETE message the mobile station shall release the MM connection and enter the "null" state after sending the RELEASE COMPLETE message.

The network shall process the RELEASE COMPLETE message in accordance with sub-clause 5.4.

##### 5.2.2.3.2 Receipt of CALL CONFIRMED and ALERTING by the network

The call control entity of the network in the "call present" state, shall, upon receipt of a CALL CONFIRMED message: stop timer T303, start timer T310 and enter the "mobile terminating call confirmed" state.

The call control entity of the mobile station having entered the "mobile terminating call confirmed" state, if the call is accepted at the called user side, the mobile station proceeds as described in 5.2.2.5. Otherwise, if the signal information element was present in the SETUP message user alerting is initiated at the mobile station side; if the signal information element was not present in the SETUP message, user alerting is initiated when an appropriate channel is available.

Here, initiation of user alerting means:

– the generation of an appropriate tone or indication at the mobile station; and

– sending of an ALERTING message by the call control entity of the MS to its peer entity in the network and entering the "call received" state.

The call control entity of the network in the "mobile terminated call confirmed" state shall, upon receipt of an ALERTING message: send a corresponding ALERTING indication to the calling user; stop timer T310; start timer T301, and enter the "call received" state.

In the "mobile terminating call confirmed" state or the "call received" state, if the user of a mobile station is User Determined User Busy then a DISCONNECT message shall be sent with cause #17 "user busy". In the "mobile terminating call confirmed" state, if the user of a mobile station wishes to reject the call then a DISCONNECT message shall be sent with cause #21 "call rejected".

##### 5.2.2.3.3 Call failure procedures

In case of abnormal behaviour the following call failure procedures apply:

i. If the network does not receive any response to the SETUP message prior to the expiration of timer T303, then the network shall: initiate clearing procedures towards the calling user with cause #18 "no user responding"; and initiate clearing procedures towards the called mobile station in accordance with 5.4.4 using cause #102 "recovery on timer expiry".

ii. If the network has received a CALL CONFIRMED message, but does not receive an ALERTING, CONNECT or DISCONNECT message prior to the expiration of timer T310, then the network shall:

– initiate clearing procedures towards the calling user with cause #18 "no user responding"; and

– initiate clearing procedures towards the called MS in accordance with sub-clause 5.4.4 using cause #102 "recovery on timer expiry".

iii. If the network has received an ALERTING message, but does not receive a CONNECT or DISCONNECT message prior to the expiry of timer T301 (or a corresponding internal alerting supervision timing function), then the network shall: initiate clearing procedures towards the calling user with cause #19 "user alerting, no answer"; and initiate clearing procedures towards the called mobile station in accordance with sub-clause 5.4.4, using cause #102 "recovery on timer expiry" or using cause #31 "normal, unspecified".

NOTE: The choice between cause #31 and cause #102 may have consequences on indications generated by the mobile station, see 3GPP TS 02.40.

##### 5.2.2.3.4 Called mobile station clearing during mobile terminating call establishment

See sub-clause 5.4.2.

#### 5.2.2.4 Notification of interworking in connection with mobile terminating call establishment

In this sub-clause, the term "interworking" is used only in the meaning of interworking with a network other than PLMN or ISDN, not as interworking between PLMN and ISDN since this is the normal case. In this sense, PLMN and ISDN are seen within the same environment, called the PLMN/ISDN environment.

During call establishment the call may enter an PLMN/ISDN environment, e.g., because of interworking with another network, with a non-PLMN/ISDN user, or with non-PLMN/ISDN equipment within the calling or called user’s premises. When this occurs, the network may include a progress indicator information element to be included in the SETUP message to be sent to the called mobile station specifying progress description value

a) #1 "call is not end-to-end PLMN/ISDN; further call progress information may be available in-band"; or

b) #3 "origination address is non-PLMN/ISDN".

#### 5.2.2.5 Call accept

In the "mobile terminating call confirmed" state or the "call received" state, the call control entity in the mobile station indicates acceptance of a mobile terminating call by:

– sending a CONNECT message to its peer entity in the network;

– starting Timer T313; and

– entering the "connect request" state.

#### 5.2.2.6 Active indication

In the "mobile terminated call confirmed" state or in the "call received" state, the call control entity of the network shall, upon receipt of a CONNECT message: through connect the traffic channel (including the connection of an interworking function, if required), stop timers T310, T303 or T301 (if running); send a CONNECT ACKNOWLEDGE message to its peer entity at the mobile station of the called user; initiate procedures to send a CONNECT message towards the calling user and enter the "active" state.

In the "connect request" state, the call control entity of the mobile station shall, upon receipt of a CONNECT ACKNOWLEDGE message: stop timer T313 and enter the "active" state.

When timer T313 expires prior to the receipt of a CONNECT ACKNOWLEDGE message, the mobile station shall initiate clearing in accordance with sub-clause 5.4.3.

MS Network

+————————+

│ CONNECT │

│ ———————> │

│ CONNECT ACKNOWLEDGE │

│ <——————– │

+————————+

Figure 5.7/3GPP TS 04.08: Call acceptance and active indication at mobile terminating call establishment

#### 5.2.2.7 Traffic channel assignment at mobile terminating call establishment

It is a network dependent decision when to initiate the assignment of a traffic channel during the mobile terminating call establishment phase.

Initiation of the assignment phase does not directly change the state of a CC entity nor affect any call control timer, but may have some secondary effects (see e.g. sub-clause 5.2.2.3.2).

#### 5.2.2.8 Call queuing at mobile terminating call establishment

The principles described in sub-clause 5.2.1.10 apply accordingly.

NOTE: The interworking to the fixed network has to fulfil the network specific requirements.

#### 5.2.2.9 User connection attachment during a mobile terminating call

For speech calls:

– The mobile station shall attach the user connection at latest when sending the connect message.

For data calls:

– The mobile station shall attach the user connection when receiving the CONNECT ACKNOWLEDGE message from the network.

### 5.2.3 Network initiated MO call $(CCBS)$

The procedures of sub-clause 5.2.3 are mandatory for mobile stations supporting "Network initiated MO call".

NOTE: The behaviour of a mobile station that does not support "Network initiated MO call" is described in sub-clause 4.

#### 5.2.3.1 Initiation

Before call establishment can be initiated in the mobile station, the MM connection shall be established by the network.

After the arrival of an appropriate stimulus (for example a Remote User Free Indication), the corresponding call control entity in the network shall initiate the MM connection establishment according to sub-clause 4, enter the "CC connection pending" state and start timer T331. The request to establish the MM connection is passed from the CM sublayer to the MM sublayer. It contains the necessary routing information derived from the received stimulus.

Upon completion of the MM connection, the call control entity of the mobile station shall send a START CC message to its peer entity in the network. The mobile station shall then enter the "Wait for network information" state and start timer T332.

If the network receives a START CC message while in the "CC connection pending" state, the network stops T331, sends the CC-ESTABLISHMENT message, starts timer T333 and enters the "CC-establishment present" state.

The MM connection establishment may be unsuccessful for a variety of reasons, in which case the MM sublayer in the network will inform the CC entity in the network with an indication of the reason for the failure. The CC entity shall then stop all running timers, enter the "Null" state and inform all appropriate entities within the network.

If timer T331 expires, the network shall abort the MM connection establishment attempt, stop all running CC timers, enter the "Null" state and inform all appropriate entities within the network.

#### 5.2.3.2 CC-Establishment present

In the "CC establishment present" state, the mobile station, upon receipt of the CC-ESTABLISHMENT message, shall stop timer T332.

The CC-ESTABLISHMENT message contains information which the mobile station shall use for the subsequent SETUP message (if any) related to this CC-ESTABLISHMENT.

The CC-ESTABLISHMENT message shall contain the Setup Container IE.

If no CC-ESTABLISHMENT message is received by the call control entity of the mobile station before the expiry of timer T332, then the mobile station shall initiate clearing procedures towards the network using a RELEASE COMPLETE message with cause #102 "recovery on timer expiry" and proceed in accordance with sub-clause 5.4.2.

Upon receipt of a CC-ESTABLISHMENT message the mobile station shall perform checks on the Setup Container IE in order to align the contained information with the mobile’s present capabilities and configuration. The "recall alignment procedure" is defined later on in this sub-clause.

If the recall alignment procedure has succeeded, the call control entity of the Mobile Station shall:

– form and store the SETUP message for sending later in the "Recall present" state;

– acknowledge the CC-ESTABLISHMENT message with a CC-ESTABLISHMENT CONFIRMED message;

– start timer T335; and

– enter the "CC-establishment confirmed" state.

Exception:

– A busy mobile station which has successfully performed the recall alignment procedure shall respond with a CC‑ESTABLISHMENT CONFIRMED message with cause #17 "user busy", and proceed as stated above.

A mobile station, for which the recall alignment procedure failed, shall respond with a RELEASE COMPLETE message in accordance with sub-clause 5.4.2 with the appropriate cause code as indicated in the description of the recall alignment procedure.

The SETUP message is constructed from the Setup Container IE received in the CC ESTABLISHMENT MESSAGE. The mobile station shall assume that the Setup Container IE contains an entire SETUP message with the exception of the Protocol Discriminator, Transaction ID and Message Type elements. The mobile station may assume that the contents of the Setup Container IE are the same as were sent from the subscriber in a previous SETUP message of the mobile originating call establishment attempt. The mobile station shall copy the Setup Container to the SETUP message and not modify the contents except as defined in the recall alignment procedure and as defined in exceptions below. The mobile station shall not add other Information Elements to the end of the SETUP message.

Exceptions:

Bearer Capability IE(s), HLC IE(s) and LLC (s) IE(s) (including Repeat Indicator(s), if there are 2 bearer capabilities) require handling as described in the recall alignment procedure below.

– If the CC Capabilities in the Setup Container IE is different to that supported by the mobile station, the mobile station shall modify the CC Capabilities in the SETUP message to indicate the true capabilities of the mobile station.

Facility IE(s) and SS Version IE(s) require handling as described in the recall alignment procedure.

If no response to the CC-ESTABLISHMENT message is received by the call control entity of the network before the expiry of timer T333, then the network shall initiate clearing procedures towards the called mobile station using a RELEASE COMPLETE message with cause #102 "recovery on timer expiry" and inform all appropriate entities within the network, proceeding in accordance with sub-clause 5.4.2.

MS Network

+—————————+

│ │

│ CC-ESTABLISHMENT │

│ <————– │

│ │

│ CC-ESTABLISHMENT_CONFIRMED│ (i)

│ – – – – – – – – – – – – > │

│ RELEASE COMPLETE │ (ii)

│ – – – – – – – – – – – – > │

+—————————+

Figure 5.7a/3GPP TS 04.08: Call initiation and possible subsequent responses

##### 5.2.3.2.1 Recall Alignment Procedure

The recall alignment procedure consists of two parts:

– basic service group alignment; and

– facility alignment.

Basic service group alignment:

The mobile station shall check that the Bearer Capability, HLC and LLC and Repeat Indicator fields, which are embedded in the Setup Container IE, match a basic service group supported by the mobile station.

If this check fails, then the recall alignment procedure has failed. The mobile station shall use the cause #88 "incompatible destination" afterwards.

Otherwise, the mobile station is allowed to alter the content within the Bearer Capability, HLC and LLC Information Elements (e.g. the speech coder version(s), the data rate, the radio channel requirement) provided that the basic service group is not changed. The result shall be that the mobile station has derived Bearer Capability, HLC and LLC Information Elements, which it can use for a later call setup according to its configuration and capabilities.

Facility alignment:

– This only applies if the Setup Container contains 1 or more Facility IEs. Each Facility IE within the Setup Container will be associated with the common SS Version IE, if present. The handling for each Facility IE is defined below. The mobile station shall align each facility IE contained in the Setup Container. The rules defined in 3GPP TS 04.10 also apply.

The Facility IE is encoded as ‘simple recall alignment’, ‘advanced recall alignment’ or ‘recall alignment not essential’ (see 3GPP TS 04.10). If the encoding indicates, that:

– a simple recall alignment is required, the mobile station shall copy the Facility IE and the common SS version IE from the Setup Container to the SETUP message without modifying the content.

– an advanced recall alignment is required, the mobile station must recognise and support the operation defined in the facility. If the mobile station does not recognise or support the operation, then the recall alignment procedure has failed and the mobile station shall use the cause #29 "facility rejected" in the subsequent rejection of the CC establishment request.

– the recall alignment is not essential, then the facility operation is not an essential part of the SETUP. If the MS does not recognise the operation then the SS Version IE and Facility IE are discarded, and NOT copied into the SETUP message.

NOTE: A mobile station may include a Facility IE without an associated SS Version IE. This would indicate that the SS operation is encoded using Phase 1 protocols.

Further details on Facility handling are given in 3GPP TS 04.10.

#### 5.2.3.3 CC-Establishment confirmation

The call control entity of the network in the "CC-establishment present" state, shall, upon receipt of a CC-ESTABLISHMENT CONFIRMED message, stop timer T333 and enter the "CC-establishment confirmed" state.

In the "CC-establishment confirmed" state, the network sends a RECALL message. This message initiates user alerting and also shall include the Facility IE (providing additional information to be presented to the user for notification). The network starts timer T334 and enters the "recall present" state.

Upon reception of the RECALL message the Mobile station stops T335 and enters the "recall present" state.

MS Network

+———————+

│ │

│ RECALL │

│ <————– │

│ │

+———————+

Figure 5.7b/3GPP TS 04.08: Recall

#### 5.2.3.4 Recall present

In the "recall present" state, the call control entity in the mobile station waits for acceptance of the Recall by the user. Once confirmation is received, the mobile station indicates acceptance of a recall by:

– sending a SETUP message to its peer entity in the network;

– starting Timer T303; and

– entering the "call initiated" state and proceeding as described in sub-clause 5.2.1.1.

The MS shall ensure that the contents of the Bearer Capability IE(s) sent in the SETUP message are the same as the Bearer Capability IE(s) in the previous CC-ESTABLISHMENT CONFIRMED message related to this Network Initiated MO Call.

In the "recall-present" state, if the user of a mobile station is User Determined User Busy then a RELEASE COMPLETE message shall be sent with cause #17 "user busy" In the "recall-present" state. If the user of a mobile station wishes to reject the recall then a RELEASE COMPLETE message shall be sent with cause #21 "call rejected".

In either case, the mobile shall release the connection in accordance with sub-clause 5.4.2.

On receipt of the SETUP message in the "recall present" state, the network shall stop timer T334 and proceed as specified in sub-clause 5.2.1.2.

If the call control entity of the network does not receive a SETUP message before the expiry of timer T334, then the network shall send a RELEASE COMPLETE message to the mobile using cause #102 "recovery on timer expiry", release the MM connection, enter the "null" state and shall inform all appropriate entities within the network.

MS Network

+————————+

¦ SETUP ¦

¦ ———————> ¦

¦ RELEASE COMPLETE ¦

¦ ——————–> ¦

+————————+

Figure 5.7b/3GPP TS 04.08: Recall acceptance or rejection by user

#### 5.2.3.5 Traffic channel assignment during network initiated mobile originating call establishment

It is a network dependent decision whether or not to initiate the assignment of a traffic channel during the "CC-establishment confirmed" state.

## 5.3 Signalling procedures during the "active" state

The mobile terminating user notification procedure allows the network to notify a mobile station of any appropriate call-related event during the "active" state of a call. The procedure consists in the network sending a NOTIFY message to the mobile station. No state change occurs at any of the interface sides following the sending or the receipt of this message (but an appropriate indication may optionally be generated in the mobile station).

The mobile originating notification procedure allows the mobile station to notify the remote user of any appropriate call-related event during the "active" state of a call by sending a NOTIFY message containing a notification indicator to the network; upon receipt of this message, the network sends a NOTIFY message containing the same notify indicator to the other user involved in the call. No state change occurs at any of the interface sides following the sending or the receipt of this message.

### 5.3.2 Call rearrangements

Call rearrangements on the radio interface are not supported by explicit messages (e.g. SUSPEND and RESUME messages as defined in ETS 300 102-1). However if a remote non-PLMN user initiates call rearrangements, the network shall inform the mobile station by means of a NOTIFY message. In a similar way the mobile station can inform the network about rearrangements by sending a NOTIFY message (e.g. change of user equipment connected to the mobile station).

### 5.3.4 Support of Dual Services

The behaviour described in this sub-clause is used to realize the following required services throughout sub-clause 5.3.4. The mobile station is not obliged to support the network originated in-call modification procedure. In that case, the mobile station shall, when receiving a MODIFY message, treat the message as unknown and react as described in sub-clause 8.4. If the mobile station is already prepared to support the procedure in both directions, it shall act as described in this sub-clause.

a) Alternate Speech/Data (BS 61 according to 3GPP TS 02.02);

b) Speech followed by Data (BS 81 according to 3GPP TS 02.02);

c) Alternate Speech/Group 3 fax (Teleservice 61 according to 3GPP TS 02.03).

#### 5.3.4.1 Service Description

This circuit switched service allows the two users on a point-to-point connection to use the connection between them for different information transfer during the same call, but not at the same time.

If the negotiation during call establishment leads to the recognition of the above mentioned services, the in-call modification procedure is allowed to be executed within the current call by changing from one call mode to the other.

In some cases the in-call modification procedure makes it necessary to change the channel configuration by allocating a new channel and in other cases to change channel configuration parameters while keeping the previously allocated channel. This change is determined by the network, which initiates either the channel assignment procedure, handover procedure or channel mode modify procedure (see sub-clause 3).

The capability and the initial mode desired must be identified by the mobile station by identifying each mode of operation with a separate information element during call establishment. Further the type of change between the modes must be identified by means of the repeat indicator:

– mode 1 "alternate" mode 2; or

– mode 1 "and then" mode 2.

#### 5.3.4.2 Call establishment

For both mobile originating and mobile terminating calls, the normal call establishment procedures apply.

##### 5.3.4.2.1 Mobile Originating Establishment

The service is requested by the originating mobile station by transferring a SETUP message to the network containing the BC repeat indicator IE, the bearer capability 1 information element, and the bearer capability 2 information element. The first mode of operation ("call mode") shall be indicated by the bearer capability 1 information element and the second call mode by the bearer capability 2 information element.

A low layer compatibility may optionally be specified for each call mode in a low layer compatibility I and low layer compatibility II information element. In that case:

– the SETUP message shall contain the LLC repeat indicator IE and both low layer compatibility I and low layer compatibility II information elements. The low layer compatibility I information element then corresponds to the bearer capability 1 information element and the low layer compatibility II information element to the bearer capability 2 information element;

– if no low layer compatibility specification applies for one of the two call modes, the corresponding low layer compatibility IE (low layer compatibility I or low layer compatibility II) shall indicate "not applicable";

– the LLC repeat indicator shall specify the same repeat indication as the BC repeat indicator IE.

Similarly, a high layer compatibility may optionally be specified for each call mode in a high layer compatibility i and high layer compatibility ii information element. In that case:

– the SETUP message shall contain the HLC repeat indicator IE and both high layer compatibility i and high layer compatibility ii information elements. The high layer compatibility i information element then corresponds to the bearer capability 1 information element and the high layer compatibility ii information element to the bearer capability 2 information element;

– if no high layer compatibility specification applies for one of the two call modes, the corresponding high layer compatibility IE (high layer compatibility i or high layer compatibility ii) shall indicate "not applicable";

– the HLC repeat indicator shall specify the same repeat indication as the BC repeat indicator IE.

The receiving entity shall ignore whether the LLC repeat indicator IE or HLC repeat indicator are contained in the message or not; it shall also ignore the repeat indication of an LLC repeat indicator IE or HLC repeat indicator IE. If the low layer compatibility II IE is not contained in the message and the low layer compatibility I IE is contained in the message, the receiving entity shall relate it to a call mode indicated in the message that does not specify speech (if any). If the high layer compatibility ii IE is not contained in the message and the high layer compatibility i IE is contained in the message, the receiving entity shall relate it to a call mode indicated in the message that does not specify speech (if any).

The specific part of the network which is sensitive to the call mode shall examine each mode described in the bearer capabilities included in the SETUP message by performing compatibility checking as defined in Annex B. If as a result of this compatibility checking the network decides to reject the call, then the network shall initiate call clearing as specified in sub-clause 5.4 with the following causes:

a) #57 "bearer capability not authorized";

b) #58 "bearer capability not presently available";

c) #65 "bearer service not implemented";

d) #70 "only restricted digital information bearer capability is available".

##### 5.3.4.2.2 Mobile Terminating Establishment

The service is indicated to the called mobile station by a SETUP message coded in the same manner as in the mobile originating call establishment. As specified for normal terminating call establishment, the service may be indicated by the called mobile station in the CALL CONFIRMED message.

The destination mobile station shall perform the compatibility checking as defined in Annex B for both required modes if indicated in the SETUP message. If as a result of compatibility checking the mobile station decides to reject the call, the mobile station shall initiate call clearing according to the procedures of sub-clause 5.4 with one of the following causes:

a) #57 "bearer capability not authorized";

b) #58 "bearer capability not presently available";

c) #65 "bearer service not implemented";

d) #88 "incompatible destination".

The mobile station may accept the call if the first mode indicated is free irrespective of whether the other mode is free or busy.

#### 5.3.4.3 Changing the Call Mode

In order to change the call mode, the following in-call modification procedures shall be used.

Either side of the radio interface may act as the requesting user to invoke the in-call modification.

Upon each successful completion of the in-call modification procedure, the call changes to the next mode negotiated and agreed during the establishment phase of the call.

The in-call modification procedures are completely symmetrical at the radio interface.

NOTE: Considering a possible future evolution, in-call modification is specified as a symmetrical procedure.

##### 5.3.4.3.1 Initiation of in-call modification

The procedure is initiated by the requesting originating side in the "active" state of the call. It shall send a MODIFY message including the new mode to be changed to; start timer T323; and enter the "mobile originating modify" state (mobile station side) or the "mobile terminating modify" state (network side). Any internal resources necessary to support the next call mode shall be reserved. The new mode given in the MODIFY message shall be one of those already negotiated and agreed during the establishment phase of the call. If the data call direction is different from the direction of the call setup a reverse call setup direction IE shall be included in the MODIFY message; otherwise this IE shall not be included. The MODIFY originating side shall stop sending Bm-channel information; and stop interpreting received Bm-channel information according to the old call mode.

Upon receipt of the MODIFY message, the destination side shall check to ensure that the requested call mode can still be supported and if so, it shall initiate the reservation of any resources necessary to support the next call mode and enter the "mobile originating modify" (network side) or "mobile terminating modify" state (mobile station side).

##### 5.3.4.3.2 Successful completion of in-call modification

If the destination network/mobile station receives a MODIFY message with a new mode which is already the actual one of the call the network/mobile station shall remain in the "active" state; send a MODIFY COMPLETE message with the actual mode; and shall not initiate anything else.

If the requested mode is not the actual one and can be supported by the destination interface it shall change the channel configuration, if required, and step on to any internal resources necessary to support the next call mode. If the requested mode is a data or facsimile mode, it shall also perform the appropriate means to take the direction of the data call into account. After successful change of the channel configuration it shall start sending user information according to the next call mode and start interpreting received user channel information according to the next call mode; send a MODIFY COMPLETE message with the new call mode included and enter the "active" state (mobile station or network side). If the MODIFY message had contained a reverse call setup direction IE, the same IE shall be included in the MODIFY COMPLETE message.

In case of an alternate speech/data or alternate speech/facsimile group 3 service (refer to sub-clause 5.3.4) the old resources may still be kept reserved, in case of speech followed by data service they may be released.

Upon receipt of the MODIFY COMPLETE message the originating side shall: initiate the alternation to those resources necessary to support the next call mode; stop timer T323; and enter the "active" state (mobile station or network side). The reaction of the originating side if it had included a reverse call setup direction IE in the MODIFY message, but the destination side did not include the IE in the MODIFY COMPLETE message is implementation dependent.

##### 5.3.4.3.3 Change of the channel configuration

In case the requested bearer capability cannot be supported by the current channel configuration the network shall initiate the assignment procedure and change the channel configuration accordingly.

##### 5.3.4.3.4 Failure of in-call modification
###### 5.3.4.3.4.1 Network rejection of in-call modification

If the network cannot support the change to the requested call mode or if the change of the channel configuration fails the network shall: release the resources which had been reserved for the alternation: send a MODIFY REJECT message with the old bearer capability and with cause # 58 "bearer capability not presently available" to the initiating mobile station; and enter the "active" state. If the change of the channel configuration fails, the network shall return to the internal resources required for the old call mode.

Upon receipt of the MODIFY REJECT message with the old bearer capability the initiating mobile station shall: stop timer T323; release any resources which had been reserved for the alternation; resume sending user channel information according to the present call mode; resume interpreting received user channel information according to the present call mode; and enter the "active" state.

###### 5.3.4.3.4.2 Mobile station rejection of in-call modification

If the mobile station cannot support the change to the requested call mode, the mobile station shall: release any resources which had been reserved for the alternation; send a MODIFY REJECT message with the old bearer capability and cause # 58 "bearer capability not presently available", and enter the "active" state.

Upon receipt of the MODIFY REJECT message the network shall: stop timer T323, release any resources which had been reserved for the alternation.

###### 5.3.4.3.4.3 Time-out recovery

Upon expiration of T323 in either the mobile station or the network the procedures for call clearing shall be initiated with cause # 102 "recovery on timer expiry".

#### 5.3.4.4 Abnormal procedures

If a MODIFY, MODIFY COMPLETE or MODIFY REJECT message is received in the "disconnect indication", "disconnect request" (mobile station side only) or "release request" state then the received message shall be discarded and no action shall be taken.

If a MODIFY COMPLETE message indicating a call mode which does not correspond to the requested one is received or if a MODIFY REJECT message indicating a call mode which does not correspond to the actual one is received then the received message shall be discarded and no action shall be taken.

If a MODIFY message indicating a call mode which does not belong to those negotiated and agreed during the establishment phase of the call, is received, then a MODIFY REJECT message with the actual call mode and with cause # 57 "bearer capability not authorized" shall be sent back.

MS Network

+———————————–+

│ MOD │

│ ——————————-> │

│ │————│ │

│ │ assignment or channel mode modify

│ │————│ │

│ MOD COMP │

│ <—————————— │

│ MOD REJ │

│ <– — — — — — — — │

+———————————–+

Figure 5.10a/3GPP TS 04.08: In-call modification sequence initiated by MS

MS Network

+———————————–+

│ MOD │

│ <—————————— │

│ MOD COMP │

│ ——————————> │

│ MOD REJ │

│ — — — — — — — -> │

│ │————│ │

│ │ assignment or channel mode modify

│ │————│ │

+———————————–+

Figure 5.10b/3GPP TS 04.08: In-call modification sequence initiated by network

### 5.3.5 User initiated service level up- and downgrading

The user initiated service level up- and downgrading is applicable for non-transparent multislot data services, only. By means of this procedure the user can request a change of the "maximum number of traffic channels" and/or "wanted air interface user rate" parameters, to be assigned by the network.

#### 5.3.5.1 Initiation of service level up- and downgrading

The procedure is initiated by the mobile station in the "active" state of the call. It shall:

‑ send a MODIFY message including the wanted value of the "maximum number of traffic channels" and/or the "wanted air interface user rate" parameters;

‑ not change any of the other, possibly negotiated, parameters of the bearer capability information element;

‑ start timer T323; and

‑ enter the "mobile originating modify" state.

Any internal resources necessary to support the next service parameters shall be reserved. If a dual service was negotiated at call setup, the mobile station shall initiate the service level up- or down-grading only during the data phase of the dual service.

Upon receipt of the MODIFY message, the network shall check if the indicated maximum number of traffic channels can be supported and enter the "mobile originating modify" state.

#### 5.3.5.2 Successful completion of service level up- and downgrading

The network may upon reception of the MODIFY message initiate a change of the channel configuration assigned to the mobile station.

As a response to the MODIFY message the network sends a MODIFY COMPLETE message including the bearer capability negotiated at call setup and enters the "active" state.

Upon receipt of the MODIFY COMPLETE message the mobile station shall stop timer T323 and enter the "active" state.

#### 5.3.5.3 Rejection of service level up- and downgrading

If a change of bearer service is requested together with a change of the "maximum number of traffic channels" and/or the "wanted air interface user rate", or if the current used service is not a data service where up- and downgrading is applicable, or if the receiver chooses not to grant the request, the network shall:

‑ send a MODIFY REJECT message with bearer capability negotiated at call setup and with cause #58 "bearer capability not presently available";

‑ enter the "active" state.

Upon receipt of the MODIFY REJECT message with the bearer capability negotiated at call setup, the mobile station shall: stop timer T323 and enter the "active" state.

#### 5.3.5.4 Time-out recovery

Upon expiration of T323 in the mobile station the procedures for call clearing shall be initiated with cause #102 "recovery on timer expiry".

## 5.4 Call clearing

### 5.4.1 Terminology

The following terms are used in the present document in the description of clearing procedures:

– A traffic channel (see 3GPP TS 04.03) is "connected" when the channel is part of a circuit-switched connection established according to the present document.

– A traffic channel is "disconnected" when the channel is no longer part of a circuit-switched connection, but is not yet available for use in a new connection.

### 5.4.2 Exception conditions

Under normal conditions, the call control entity of the mobile station or of the network initiates call clearing by sending a DISCONNECT message to its peer entity; then both entities follow the procedures defined in sub-clauses 5.4.3 and 5.4.4 respectively.

As an exception to the above rule, the call control entity of the mobile station or of the network, in response to a SETUP or START CC or CC-ESTABLISHMENT CC-ESTABLISHMENT CONFIRMED or RECALL message, can reject a call by stopping all running call control timers, responding with a RELEASE COMPLETE message, releasing the MM connection, and returning to the "null" state, provided no other response has previously been sent.

As a further exception, the call control entity of the network may initiate call clearing by stopping all running call control timers, sending a RELEASE message, starting timer T308, and entering the "release request" state.

NOTE 1: This way to initiate call clearing by sending a RELEASE message should not be used by the network:

– if in-band tones/announcements are provided and the network decides to use the procedure described in sub-clauses 5.4.4.1.1.1 or 5.4.4.2.1;

– if the network wants to have the opportunity to respond to information sent by the mobile station during call clearing, e.g. when the network indicates that "CCBS activation is possible".

A call control entity shall accept an incoming RELEASE COMPLETE message used to initiate the call clearing even though the cause information element is not included.

A control entity shall accept an incoming RELEASE message used to initiate the call clearing even though the cause information element is not included.

Furthermore, a call control entity shall regard an incoming RELEASE COMPLETE message as consistent with any of its states; a call control entity shall regard an incoming RELEASE message as consistent with any of its states except the null state: a call control entity of the mobile station shall regard an incoming DISCONNECT message as consistent with any of its call control states except the "null" state, the "release request" state, and the "disconnect indication" state; a call control entity of the network shall regard an incoming DISCONNECT message as consistent with any of its call control states except the "null" state and the "release request" state.

NOTE 2: This allows the introduction of shorter call clearing procedures in the future.

### 5.4.3 Clearing initiated by the mobile station

#### 5.4.3.1 Initiation of call clearing

Apart from the exceptions identified in sub-clause 5.4.2, the call control entity of the mobile station shall initiate clearing by: stopping all running call control timers, sending a DISCONNECT message; starting timer T305; and entering the "disconnect request" state.

#### 5.4.3.2 Receipt of a DISCONNECT message from the mobile station

The call control entity in the network in any state except the "null" state and the "release request" state shall, upon receipt of a DISCONNECT message:

– stop all running call control timers;

– initiate procedures to clear the network connection and the call to the remote user;

– send a RELEASE message to its peer entity;

– start timer T308; and

– enter the "release request" state.

NOTE: The RELEASE message has only local significance and does not imply an acknowledgement of clearing from the remote user.

#### 5.4.3.3 Receipt of a RELEASE message from the network

The call control entity of the mobile station in any state except the "null" state and the "release request" state, shall, upon receipt of a RELEASE message: stop all running call control timers; send a RELEASE COMPLETE message; release the MM connection; and return to the "null" state.

#### 5.4.3.4 Receipt of a RELEASE COMPLETE message from the mobile station

A call control entity of the network in any call control state shall, upon receipt of a RELEASE COMPLETE message from its peer entity in the mobile station: stop all running call control timers; release the MM connection; and return to the "null" state.

#### 5.4.3.5 Abnormal cases

The call control entity of the mobile station in the "disconnect request" state, shall upon expiry of timer T305: send a RELEASE message to the network with the cause number originally contained in the DISCONNECT message and optionally, a second cause information element with cause #102 "recovery on timer expiry", start timer T308, and enter the "release request" state.

The call control entity of the network in the "release request" state, shall, at first expiry of timer T308, retransmit the RELEASE message, start timer T308, and stay in the "release request" state. At second expiry of timer T308, the call control entity of the network shall: release the MM connection; and return to the "null" state.

### 5.4.4 Clearing initiated by the network

Apart from the exception conditions identified in sub-clause 5.4.2, the call control entity of the network shall initiate clearing by: sending a DISCONNECT message; and entering the "disconnect indication" state. The DISCONNECT message is a local invitation to clear the call.

NOTE: When the network initiates clearing by sending a RELEASE message, the procedures described in sub-clauses 5.4.3., 5.4.3.4 and 5.4.3.5 are followed.

A mobile station that does not support the "Prolonged Clearing Procedure" shall comply with the requirements of sub-clause 5.4.4.1 and shall ignore sub-clause 5.4.4.2. A mobile station that supports the "Prolonged Clearing Procedure" shall comply with the requirements of sub-clause 5.4.4.2 and shall ignore sub-clause 5.4.4.1.

#### 5.4.4.1 Clearing initiated by the network: mobile does not support "Prolonged Clearing Procedure"

Sub-clause 5.4.4.1 only applies to mobile stations that do not support the "Prolonged Clearing Procedure" option.

##### 5.4.4.1.1 Clearing when tones/announcements provided

When in-band tones/announcements are provided (see sub-clause 5.5.1), the call control entity of the network may initiate clearing by sending a DISCONNECT message containing progress indicator #8 "in-band information or appropriate pattern now available", starting timer T306, and entering the "disconnect indication" state.

5.4.4.1.1.1 Receipt of a DISCONNECT message with progress indicator #8 from the network

The call control entity of the MS in any state except the "null" state, the "disconnect indication" state, and the "release request" state, shall, upon receipt of a DISCONNECT message with progress indicator #8:

i) if an appropriate speech traffic channel is not connected, continue clearing as defined in sub-clause 5.4.4.1.2.1 without connecting to the in-band tone/announcement;

ii) if an appropriate speech traffic channel is connected, attach the user connection for speech if it is not yet attached and enter the "disconnect indication" state. In that state, if upper layers request the clearing of the call, the call control entity of the MS shall proceed as defined in sub-clause 5.4.4.1.2.1.

5.4.4.1.1.2 Expiry of timer T306

The call control entity of the network, having entered the "disconnect indication" state after sending a disconnect message with the progress indicator #8, shall, upon expiry of timer T306, continue clearing by sending a RELEASE message with the cause number originally contained in the DISCONNECT message; starting timer T308; and entering the "release request" state.

##### 5.4.4.1.2 Clearing when tones/announcements not provided

When in-band tones and announcements are not provided, the call control entity of the network shall initiate call clearing by stopping all running call control timers, sending a DISCONNECT message without progress indicator, starting timer T305 and entering the "disconnect indication" state.

5.4.4.1.2.1 Receipt of a DISCONNECT message without progress indicator or with progress indicator different from #8 from the network

The call control entity of the mobile station in any state except the "null" state, the "disconnect indication" state, and the "release request" state, shall, upon the receipt of a DISCONNECT message without progress indicator information element or with progress indicator different from #8:

– stop all running call control timers;

– send a RELEASE message;

– start timer T308; and

– enter the "release request" state.

5.4.4.1.2.2 Receipt of a RELEASE message from the mobile station

The call control entity of the network in any state except the "null" state and the "release request" state, shall, upon receipt of a RELEASE message: stop all running call control timers; send a RELEASE COMPLETE message; release the MM connection; and return to the "null" state.

5.4.4.1.2.3 Abnormal cases

The call control entity of the network, having entered the "disconnect indication" state after sending a DISCONNECT message without progress indicator or with progress indicator different from #8, shall upon expiry of timer T305: send a RELEASE message to the mobile station with the cause number originally contained in the DISCONNECT message; start timer T308; and enter the "release request" state. In addition to the original clearing cause, the RELEASE message may contain a second cause information element with cause #102 "recovery on timer expiry".

##### 5.4.4.1.3 Completion of clearing

A call control entity of the mobile station in any call control state shall, upon receipt of a RELEASE COMPLETE message from its peer entity in the network: stop all running call control timers ; release the MM connection; and return to the "null" state.

5.4.4.1.3.1 Abnormal cases

The call control entity of the mobile station in the "release request" state shall at first expiry of timer T308 retransmit the RELEASE message and restart timer T308. At second expiry of timer T308, the call control entity of the mobile station shall: release the MM connection; and return to the "null" state.

#### 5.4.4.2 Clearing initiated by the network: mobile supports "Prolonged Clearing Procedure"

Sub-clause 5.4.4.2 only applies to mobile stations that support the "Prolonged Clearing Procedure" option.

##### 5.4.4.2.1 Clearing when tones/announcements provided and the network does not indicate that "CCBS activation is possible"

When in-band tones/announcements are provided (see sub-clause 5.5.1) and CCBS is not applicable, the call control entity of the network may initiate clearing by sending a DISCONNECT message containing progress indicator #8 "in-band information or appropriate pattern now available", either not containing an Allowed Actions IE or containing an Allowed Actions IE indicating "CCBS activation is not possible", starting timer T306, and entering the "disconnect indication" state.

5.4.4.2.1.1 Receipt of a DISCONNECT message

The call control entity of the MS in any state except the "null" state, the "disconnect indication" state, and the "release request" state, shall, upon receipt of a DISCONNECT message with progress indicator #8 and, either not containing an Allowed Actions IE or containing an Allowed Actions IE indicating "CCBS activation is not possible":

i) if an appropriate speech traffic channel is not connected:

– stop all running call control timers;

– send a RELEASE message;

– start timer T308; and

– enter the "release request" state.

– not connect to the in-band tone/announcement;

ii) if an appropriate speech traffic channel is connected, attach the user connection for speech if it is not yet attached and enter the "disconnect indication" state. In that state, if upper layers request the clearing of the call, the call control entity of the MS shall:

– stop all running call control timers;

– send a RELEASE message;

– start timer T308; and

– enter the "release request" state.

5.4.4.2.1.2 Expiry of timer T306

The call control entity of the network, having entered the "disconnect indication, shall, upon expiry of timer T306, continue clearing by sending a RELEASE message with the cause number originally contained in the DISCONNECT message; starting timer T308; and entering the "release request" state.

##### 5.4.4.2.2 Clearing when the network indicates that "CCBS activation is possible"

When Activation of CCBS is possible, the call control entity of the network may initiate clearing by sending a DISCONNECT message containing the Allowed Actions IE with an indication that "Activation of CCBS is possible" and starting T338. Optionally, progress indicator #8 "in-band information or appropriate pattern now available" may also be contained in the DISCONNECT message (in which case, T338 shall not be greater than T306).

5.4.4.2.2.1 Receipt of a DISCONNECT

Relative to the current state the following procedures apply:

– The call control entity of the MS in the "null" state, the "disconnect indication" state and the "release request" state, shall, upon receipt of a DISCONNECT message react as described in sub-clause 8.

– The call control entity of the MS in the "disconnect request" state, shall, upon receipt of a DISCONNECT message:

– stop all running call control timers;

– send a RELEASE message;

– start timer T308; and

– enter the "release request" state.

– The call control entity of the MS in any other states, shall, upon receipt of a DISCONNECT message with an Allowed Actions IE indicating "Activation of CCBS is possible" pass the "Activation of CCBS is possible" indication to the upper layer, enter the "disconnect indication" state, stop all running call control timers and await a response from the upper layers.

If the DISCONNECT message contained the progress indicator #8 "in-band information or appropriate pattern now available" and an appropriate speech traffic channel is connected, then the MS shall attach the user connection for speech if it is not yet attached. If the DISCONNECT message did not contain the progress indicator #8 "in-band information or appropriate pattern now available" any connected speech traffic channel shall be disconnected.

Response from the upper layers:

i) If the upper layers request the clearing of the call, the call control entity of the MS shall:

– stop all running call control timers;

– send a RELEASE message;

– start timer T308; and

– enter the "release request" state.

ii) If the upper layers request that the "CCBS activation is to be attempted" then the MS shall

– send a RELEASE message containing a Facility IE including an Invoke=CCBSRequest to the network;

– stop all running call control timers;

– start timer T308; and

– enter the "release request" state.

If an appropriate speech traffic channel is connected, transmission of this RELEASE message shall not cause it to be disconnected.

5.4.4.2.2.2 Expiry of timer T338

The call control entity of the network, having entered the "disconnect indication" state after sending a DISCONNECT message with an Allowed Actions IE indicating "Activation of CCBS is possible" shall, upon expiry of timer T338, continue clearing by sending a RELEASE message with the cause number originally contained in the DISCONNECT message; starting timer T308; and entering the "release request" state.

##### 5.4.4.2.3 Clearing when tones/announcements are not provided and the network does not indicate that "CCBS activation is possible"

When in-band tones and announcements are not provided, and, the network does not wish to indicate in the Allowed Actions IE that "CCBS is possible", the call control entity of the network shall initiate call clearing by stopping all running call control timers, sending a DISCONNECT message without progress indicator, either without the Allowed Actions IE or with the Allowed Actions IE indicating that "CCBS is not possible", starting timer T305 and entering the "disconnect indication" state.

5.4.4.2.3.1 Receipt of a DISCONNECT message

The call control entity of the mobile station in any state except the "null" state, the "disconnect indication" state, and the "release request" state, shall, upon the receipt of a DISCONNECT message either without progress indicator information element or with progress indicator different from #8, and, either without the Allowed Actions IE or with the Allowed Actions IE indicating that "CCBS is not possible":

– stop all running call control timers;

– send a RELEASE message;

– start timer T308; and

– enter the "release request" state.

5.4.4.2.3.2 Abnormal cases

The call control entity of the network, having entered the "disconnect indication", shall upon expiry of timer T305: send a RELEASE message to the mobile station with the cause number originally contained in the DISCONNECT message; start timer T308; and enter the "release request" state.

##### 5.4.4.2.4 Receipt of a RELEASE message from the mobile station

5.4.4.2.4.1 Release, CCBS not requested

For a network that does not support the "CCBS activation" option:

The call control entity of the network in any state except the "null" state and the "release request" state, shall, upon receipt of a RELEASE message: stop all running call control timers; send a RELEASE COMPLETE message; release the MM connection; and return to the "null" state.

For a network that does support the "CCBS activation" option:

The call control entity of the network in any state except the "null" state and the "release request" state, shall, upon receipt of a RELEASE message without a Facility IE including an Invoke=CCBSRequest: stop all running call control timers; send a RELEASE COMPLETE message; release the MM connection; and return to the "null" state.

5.4.4.2.4.2 Release, CCBS Requested

For a network that does not support the "CCBS activation" option:

The call control entity of the network in any state except the "null" state and the "release request" state, shall, upon receipt of a RELEASE message: stop all running call control timers; send a RELEASE COMPLETE message; release the MM connection; and return to the "null" state.

For a network that does support the "CCBS activation" option:

The call control entity of the network in any state except the "null" state and the "release request" state, shall, upon receipt of a RELEASE message containing a Facility IE including an Invoke=CCBSRequest: stop all running call control timers; then attempt to activate the recall; then send a RELEASE COMPLETE message indicating the success or failure of the recall activation attempt; release the MM connection; and return to the "null" state.

##### 5.4.4.2.5 Completion of clearing

A call control entity of the mobile station in any call control state shall, upon receipt of a RELEASE COMPLETE message from its peer entity in the network: stop all running call control timers ; release the MM connection; and return to the "null" state.

5.4.4.2.5.1 Abnormal cases

The call control entity of the mobile station in the "release request" state shall at first expiry of timer T308 retransmit the RELEASE message and restart timer T308. At second expiry of timer T308, the call control entity of the mobile station shall: release the MM connection; and return to the "null" state.

The retransmitted RELEASE message need not contain the Facility IE including an Invoke=CCBSRequest, even if the original RELEASE message did contain this IE.

### 5.4.5 Clear collision

Clear collision occurs when both the mobile station and the network simultaneously transfer DISCONNECT messages specifying the same call.

The behaviour of the network call control entity receiving a DISCONNECT message whilst in the "disconnect indication" state is specified in sub-clause 5.4.3. The behaviour of the MS call control entity receiving a DISCONNECT message whilst in the "disconnect request" state is defined in sub-clause 5.4.4.

Clear collision can also occur when both sides simultaneously transfer RELEASE messages related to the same call. The entity receiving such a RELEASE message whilst within the "release request" state shall: stop timer T308; release the MM connection; and enter the "null" state (without sending a RELEASE COMPLETE message).

## 5.5 Miscellaneous procedures

### 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 sub-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.

### 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 sub-clause 8.

A call control entity initiates the status enquiry procedure by sending the STATUS ENQUIRY message and starting timer T322. 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 sub-clause 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.

### 5.5.4 Call re-establishment, mobile station side

This sub-clause 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 sub-clause 4.5.1.6.

### 5.5.5 Call re-establishment, network side

This sub-clause 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 sub-clause 5.2.1.1.3.

MS Network

PROGRESS
<————–

Figure 5.11/3GPP TS 04.08: 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 03.14.

The mobile station shall be capable of transmitting DTMF messages 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.

#### 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.

#### 5.5.7.2 Start DTMF response by the network

Upon receiving the START DTMF message the network will reconvert the received digit back into a DTMF tone which is applied toward the remote user and returns 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.

#### 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.

#### 5.5.7.4 Stop DTMF response by the network

Upon receiving the STOP DTMF message the network will stop sending the DTMF tone and return a STOP DTMF ACKNOWLEDGE message to the mobile station.

#### 5.5.7.5 Sequencing of subsequent start DTMF requests by the mobile station

The minimum length of tone generated by the network should be according to CEPT recommendation T/CS 46-02.

The minimum gap between two subsequent tones should be according to CEPT recommendation T/CS 46‑02.

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 1: 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.

NOTE 2: The transmission time of the messages over the radio interface on FACCH/F or FACCH/H, see 3GPP TS 05.02, ensures that the minimum length of tones and minimum gap between tones according to T/CS 46-02 are fulfilled.

Mobile Station Network

START DTMF

———————————–>

START DTMF ACK

<———————————–

STOP DTMF ß

———————————–>

STOP DTMF ACK

<———————————–

Figure 5.8/3GPP TS 04.08: Single DTMF transmission

Mobile Station Network

START DTMF (x)

———————————–>

START DTMF ACK

<———————————–

STOP DTMF ß

———————————–>

STOP DTMF ACK

<———————————–

START DTMF (y) ß

———————————–>

START DTMF ACK

<———————————-

.

.

.

Figure 5.9/3GPP TS 04.08: Multiple DTMF transmission