5.2 Call establishment procedures

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

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 the present document 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.

In Iu mode, if the lower layers indicate the release of a radio access bearer, whereas the corresponding call is still active, the MS shall not automatically initiate the release of that call.

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 23.067 [88]. 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 subclause 4.5.1.7.

The mobile station supporting multicall that is initiating an emergency call shall release one or more existing call to ensure the emergency call can be established if the multicall supported information stored in the mobile station described in subclauses 5.2.1.2 and 5.2.2.1 indicates the network does not support multicall and some ongoing calls exists.

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.

NOTE 1: The Extended Local Emergency Numbers List (see 3GPP TS 24.301 [120]) does not apply in this specification.

The mobile station 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;

– EMERGENCY SETUP message shall contain the emergency category, if the emergency category is available at the MS.

If the mobile station supports multicall, it shall include the Stream Identifier (SI) information element. For the first call i.e. when there are no other ongoing calls the SI value shall be 1.

For speech calls the mobile station shall indicate all codecs that it supports for UTRAN in the Supported Codec List information element. Codecs for GERAN shall be indicated in the Bearer Capability information element, if this information element is included. Additionally, if the mobile station supports codecs for GERAN and UTRAN, it shall indicate the codecs for GERAN also in the Supported Codec List information element.

If the call is a redial attempt to switch from speech to multimedia or vice-versa, the SETUP message shall include the Redial information element.

NOTE 2: Redial attempt is defined in 3GPP TR 23.903: "Redial solution for voice-video switching"[115].

If the MS supports the enhanced network-initiated in-call modification procedure as specified in subclause 5.3.4.3, the MS shall indicate this in the Call Control Capabilities IE in the SETUP message.

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 subclause 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 subclause 5.2.1.3;

ii) an ALERTING message, it shall proceed as described in subclause 5.2.1.5;

iii) a CONNECT message, it shall proceed as described in subclause 5.2.1.6;

iv) a RELEASE COMPLETE message it shall proceed as described in subclause 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 subclause 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 subclause 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.

In Iu mode, network shall include the SI received in the SETUP message into the RABid and send it back to the mobile station. For RABid see 3GPP TS 25.413 [19c] and 3GPP TS 44.118 [111]. If the network receives the SETUP message with no SI, the network shall set the SI value to 1.

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 subclause 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 subclause 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 shall also contain the priority of the call in the case where the network supports eMLPP. 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.

NOTE: If the network supports only R98 or older versions of this protocol and the priority is not included in the CALL PROCEEDING message, this does not imply that the network does not support eMLPP.

– The CALL_PROCEEDING message shall contain the multicall supported information in the network call control capabilities in the case where the network supports multicall and there are no other ongoing calls to the MS. Mobile stations supporting multicall shall store this information until the call control state for all calls returns to null. Mobile stations not supporting multicall shall ignore this information if provided in a CALL PROCEEDING message. If the multicall supported information is not sent in the CALL_PROCEEDING message, the mobile station supporting multicall shall regard that the network doesn’t support multicall.

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 subclause 5.2.1.9 (early assignment).

For speech calls, if the SETUP message or EMERGENCY SETUP message contains a Supported Codec List information element, the network shall use this list to select the codec for UTRAN. If no Supported Codec List information element is received, then for UTRAN the network shall select the default UMTS speech codec according to subclause 5.2.1.11.

Codecs for GERAN shall be selected from the codecs indicated in the Supported Codec List information element or in the Bearer Capability information element. If neither a Supported Codec List information element nor a Bearer Capability information element is received, then for GERAN the network shall select GSM full rate speech version 1.

Codec information that does not apply to the currently serving radio access shall be used by the network if an inter-system change occurs.

Figure 5.2/3GPP TS 24.008 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 subclause 5.4.

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

5.2.1.4 Notification of progressing mobile originated call

In this subclause, 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 subclauses 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 subclause 5.5.6 for further reactions of the mobile station.

5.2.1.5 Alerting

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; and

– for multimedia calls: if the mobile station has not attached the user connection then the mobile station may internally generate an alerting indication. If the mobile station supports multimedia CAT during the alerting phase of a mobile originated multimedia call establishment, the network may request the mobile station to attach the user connection and setup a H.324 call and generate multimedia CAT as specified in subclause 5.3.6.4, in which case the mobile station need not generatean alerting tone.

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 subclause 5.4.

Figure 5.4/3GPP TS 24.008 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);

– clear any H.324 call established to receive multimedia CAT during the alerting phase (if applied) , as specified in subclause 5.3.6.4

– 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 subclause 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 subclause 5.4.

Figure 5.5/3GPP TS 24.008 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 subclause 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

The mobile station supporting multicall includes the Stream Identifier (SI) in the SETUP message. The multicall supporting network shall interprets the SI value as follows:

a) Mobile station generates a new SI value at the initiation of an originating call, then a new traffic channel shall be assigned to the mobile originating call.

b) Mobile station indicates an existing SI value, then the indicated traffic channel shall be used for the mobile originating call.

Mobile station supporting multicall shall never send an additional SETUP with indication that a new traffic channel is requested to a network that does not support multicall.

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 44.018 [84], clause 3 and 3GPP TS 48.008 [85].

The assignment procedure does not affect any call control timer.

5.2.1.10 Call queuing at mobile originating call establishment

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.1.11 Speech Codec Selection

For speech calls, a mobile station implementing this version of the protocol shall indicate all codecs that it supports for UTRAN in the Supported Codec List information element. Codecs for GERAN shall be indicated in the Bearer Capability information element, if this information element is included. Additionally, if the mobile station supports codecs for GERAN and UTRAN, it shall indicate the codecs for GERAN also in the Supported Codec List information element.

If the network does not receive a Supported Codec List information element then for speech calls in UTRAN it shall select the default UMTS speech codec.

For speech calls in GERAN, if the network does not receive a Supported Codec List information element nor a Bearer Capability information element, the network shall select GSM full rate speech version 1.

The network shall determine the default UMTS speech codec by the following:

i) If no GSM Speech Version codepoints are received in the Supported Codec List IE or in octet 3a etc. of the Bearer Capabilities IE then a "UMTS only" terminal is assumed and the default UMTS speech codec shall be UMTS_AMR.

ii) If at least one GSM Speech Version codepoint is received in the Supported Codec List IE or in octet 3a etc. of the Bearer Capabilities IE then the ME supports GSM and UMTS and the default UMTS speech codec shall be UMTS_AMR_2.

NOTE 1: In case (ii), if the call is set up in A/Gb or GERAN Iu mode by a R99 ME, call control in the core network may treat the ME as a "GSM only" ME. The default UMTS speech codec will only become relevant when an intersystem handover to UTRAN Iu mode is initiated by the radio access network, and can be determined when this procedure is started.

If the Supported Codec List IE is received, then the network shall use this list to select the codec for Iu mode and indicate the selected codec to the ME via RANAP and RRC protocol in the NAS Synchronisation Indicator IE. See 3GPP TS 25.413 [19c], 3GPP TS 25.331 [23c] and 3GPP TS 44.118 [111].

The NAS Synchronisation Indicator IE shall be coded as the 4 least significant bits of the selected codec type (CoID) defined in 3GPP TS 26.103 [83], subclause 6.3.

The network shall determine the preference for the selected codec type; codec type prioritisation is not provided by the ME.

The ME shall activate the codec type received in the NAS Synchronisation Indicator IE.

If the mobile station does not receive the NAS Synchronisation Indicator IE (RRC protocol)

– during setup of a speech call;

– during inter-system handover of a speech call from A/Gb or GERAN Iu mode to UTRAN Iu mode;

– during an in-call modification from data to speech;

– during a SRVCC handover to UTRAN Iu mode; or

– during a 5G-SRVCC handover from NG-RAN to UTRAN Iu mode,

then it shall select the UMTS_AMR_2 speech codec.

NOTE 2: If the network does not support UMTS_AMR_2, it may activate the UMTS_AMR codec and indicate to the mobile station that it shall select UMTS_AMR_2. According to 3GPP TS 26.103 [83], subclause 5.4, no interworking problem will occur in this case.

If the mobile station has selected a speech codec for UTRAN Iu mode, it shall keep this codec until

– a new codec is requested by the network by sending a NAS Synchronisation Indicator IE (RRC protocol);

– a new codec is requested by the network during inter-system handover from UTRAN Iu mode to A/Gb or GERAN Iu mode; or

– an in-call modification from speech to data is performed.

For adaptive multirate codec types no indication of subsets of modes is supported in this protocol, from the mobile station or to the mobile station. It is a pre-condition that the support of such codec types by the mobile station implicitly includes all modes defined for that codec type.

5.2.1.12 Cellular Text telephone Modem (CTM) selection

The mobile station can send a CTM support indication in the Bearer Capability IE in call establishment messages to inform the network of the use of CTM text in the call.

When the mobile station indicates speech and support of CTM text telephony, the network shall select a speech codec and additionally CTM text telephony detection/conversion functions as specified in 3GPP TS 23.226 [92] and 3GPP TS 26.226 [93], if such functions are available.

NOTE: If CTM support is indicated by the mobile station, then it supports CTM text telephony together with any supported speech codec and for any supported radio access.

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.

The SETUP message shall contain the multicall supported information in the network call control capabilities in the case where the network supports multicall and there are no other ongoing calls to the MS. Mobile stations supporting multicall shall store this information until the call control state for all calls returns to null. Mobile stations not supporting multicall shall ignore this information if provided in a SETUP message. If the multicall supported information is not sent in the SETUP message, the mobile station supporting multicall shall regard that the network does not support multicall.

Upon receipt of a SETUP message, the mobile station shall perform compatibility checking as described in subclause 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 subclause 5.2.2.3.4.

If there are no bearer capability IEs in the SETUP message, the network may provide information about the requested service in the backup bearer capability IE.

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 subclause 5.2.2.3.3 shall apply.

Figure 5.6/3GPP TS 24.008 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. For a backup bearer capability IE received with a SETUP message the mobile station shall not perform compatibility checking as described in annex B.

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.

If the mobile station supports multicall, it shall include the Stream Identifier (SI) information element in the CALL CONFIRMED message.

If the mobile station is located in the network supporting multicall, it shall never include the SI that is in use and shall include with either of the following two values:

– SI="no bearer";

– SI=new value (not used by any of the existing bearers).

If the mobile station supporting multicall is located in the network not supporting multicall, it shall include the SI with value 1.

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 29.007 [38]). The mobile station may also use the backup bearer capability IE, if provided by the network, to deduce the requested service (see 3GPP TS 27.001 [36], subclause 8.3.3.1). 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 subclause 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 subclause 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.

In Iu mode, network shall include the SI received in the CALL CONFIRMED message into the RABid and send it back to the mobile station. For RABid see 3GPP TS 25.413 [19c] and 3GPP TS 44.118 [111]. If the network receives the CALL CONFIRMED message with no SI, the network shall set the SI value to 1.

For speech calls, if the CALL CONFIRMED message contains a Supported Codec List information element, the network shall use this list to select the codec for UTRAN. If no Supported Codec List information element is received, then for UTRAN the network shall select the default UMTS speech codec according to subclause 5.2.1.11.

Codec information that does not apply to the currently serving radio access shall be used by the network if an inter-system change occurs.

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 subclause 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 subclause 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 subclause 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 subclause 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 22.001 [8a].

5.2.2.3.4 Called mobile station clearing during mobile terminating call establishment

See subclause 5.4.2.

5.2.2.4 Notification of interworking in connection with mobile terminating call establishment

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

See also subclause 5.5.1 for further reactions of the mobile station.

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.

If the call control entity of the mobile station has indicated "No Bearer" as the SI value in the CALL CONFIRMED message, it shall assign the SI value and include the SI information element in the CONNECT message. Otherwise the SI information element shall not be included in the CONNECT message.

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 subclause 5.4.3.

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

5.2.2.7 Traffic channel assignment at mobile terminating call establishment

After receiving the SETUP message, the mobile station supporting multicall may either require a new traffic channel or reuse an existing traffic channel.

If a mobile station in the network supporting multicall requires a new traffic channel, it shall:

– send a CALL CONFIRMED message including the SI indicating a new value, not used by any of the existing traffic channels.

If a mobile station in the network supporting multicall does not require a new traffic channel, it shall:

– send a CALL CONFIRMED message including the SI equal to "no bearer".

After the mobile station has send the CALL CONFIRMED with SI="no bearer", the SI value in the CONNECT message will tell to the network if a user requests a new traffic channel or one of the existing ones will be re-uesd.

If a new traffic channel is requested by the user, the mobile station in the network supporting multicall shall:

– send a CONNECT message containing the SI with a new value, not used by any existing traffic channel.

If the user decides that an existing traffic channel will be reused, the mobile station in the network supporting multicall shall:

– send a CONNECT message with an SI indicating an existing value used by an existing traffic channel.

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. subclause 5.2.2.3.2).

5.2.2.8 Call queuing at mobile terminating call establishment

The principles described in subclause 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.2.10 Speech Codec Selection

The principles described in subclause 5.2.1.11 apply accordingly.

5.2.2.11 Cellular Text telephone Modem (CTM) selection

The principles described in subclause 5.2.1.12 apply accordingly.

5.2.3 Network initiated MO call $(CCBS)$

The procedures of subclause 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 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 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 subclause 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 subclause.

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.

For speech calls the mobile station shall indicate all codecs that it supports for UTRAN in the Supported Codec List information element of the CC-ESTABLISHMENT CONFIRMED message. Codecs for GERAN shall be indicated in the Bearer Capability information element. Additionally, if the mobile station supports codecs for GERAN and UTRAN, it shall indicate the codecs for GERAN also in the Supported Codec List information element.

A mobile station, for which the recall alignment procedure failed, shall respond with a RELEASE COMPLETE message in accordance with subclause 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 IE(s) (including Repeat Indicator(s), if there are 2 bearer capabilities), and the Supported Codec List IE 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.

Stream Identifier IE requires 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 subclause 5.4.2.

Figure 5.7a/3GPP TS 24.008 Call initiation and possible subsequent responses.

5.2.3.2.1 Recall Alignment Procedure

The recall alignment procedure consists of three parts:

– basic service group alignment,

– facility alignment, and

– stream identifier 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 codec version(s), the data rate, the radio channel requirement) provided that the basic service group is not changed. Furthermore, for speech calls the mobile station is allowed to add or remove the Supported Codec List Information Element, or to alter the contents of this information element dependent on the codecs supported by the mobile station. The result shall be that the mobile station has derived Bearer Capability, HLC, LLC, and Supported Codec List 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 24.010 [21] also apply.

The Facility IE is encoded as ‘simple recall alignment’, ‘advanced recall alignment’ or ‘recall alignment not essential’ (see 3GPP TS 24.010 [21]). 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 24.010 [21].

Stream identifier alignment:

The mobile station shall check whether the Stream Identifier field is contained in the Setup Container or not.

If the Stream Identifier is contained in the Setup Container, the mobile station shall behave as one of the following.

– the mobile station re-assign the Stream Identifier value, and modify the Stream Identifier field.

– the mobile station remove the Stream Identifier field.

If the Stream Identifier is not contained in the Setup Container, the mobile station may behave as follows.

– the mobile station assign the Stream Identifier value, and add the Stream Identifier IE to the end of the SETUP message.

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.

For speech calls, if the ESTABLISHMENT CONFIRMED message contains a Supported Codec List information element, the network shall use this list to select the codec for UMTS. If no Supported Codec List information element is received, then for UMTS the network shall select the default UMTS speech codec according to subclause 5.2.1.11.

Codec information that does not apply to the currently serving radio access shall be used by the network if an inter-system change occurs.

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.

Figure 5.7b/3GPP TS 24.008 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 subclause 5.2.1.1.

The MS shall ensure that the contents of the Bearer Capability IE(s) and Supported Codec List IE sent in the SETUP message are the same as the Bearer Capability IE(s) and Supported Codec List IE 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 subclause 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 subclause 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.

Figure 5.7b/3GPP TS 24.008 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.2.4 Call establishment for SRVCC or vSRVCC

5.2.4.1 General

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

At PS to CS domain change from S1 mode or Iu mode due to SRVCC handover or vSRVCC handover (see 3GPP TS 23.216 [126]), the RR sublayer in the MS indicates to the MM layer if a voice only SRVCC handover or a voice and video SRVCC handover was completed successfully. At reception of this indication, the MS that supports SRVCC or vSRVCC shall establish an MM connection as specified in subclause 4.5.1.8 and either proceeds with subclause 5.2.4.2 if the indication is that voice only SRVCC was completed successfully or proceeds with subclause 5.2.4.2a if the indication is that voice and video SRVCC was completed successfully.

At 5G-SRVCC handover from NG-RAN to UTRAN (see 3GPP TS 23.216 [126]), the RR sublayer in the MS indicates to the MM layer if 5G-SRVCC handover from NG-RAN to UTRAN was completed successfully. At reception of this indication, the MS that supports 5G-SRVCC handover from NG-RAN to UTRAN shall establish an MM connection as specified in subclause 4.5.1.8 and proceeds with subclause 5.2.4.2 if the indication is that 5G-SRVCC handover from NG-RAN to UTRAN was completed successfully.

5.2.4.2 Call activation for SRVCC

If the MS

– supports SRVCC and the MS has a voice media stream previously carried over the PS domain that is handed over to the CS domain via SRVCC;

– supports SRVCC or vSRVCC and the MS has a voice media stream and a video media stream of a single session previously in S1 mode carried over the PS domain and only the voice media stream is handed over to the CS domain via SRVCC; or

– supports 5G-SRVCC handover from NG-RAN to UTRAN and the MS has a voice media stream previously in the N1 mode that is handed over to the CS domain via 5G-SRVCC handover from NG-RAN to UTRAN

and the session is in the "confirmed" state (defined in IETF RFC 3261 [137]), and the call control entity in "null" state receives indication "MM connection establishment due to SRVCC handover", the call control entity of the MS shall enter the "active" state, set the auxiliary state (defined in 3GPP TS 24.083 [27]) to "idle", set the multi party auxiliary state (defined in 3GPP TS 24.084 [28]) to "idle" and indicate the call establishment to upper layers. The MS and the network shall locally set the TI value of the call to "000" and the TI flag value as in mobile terminated call. If a single voice media stream is handed over and:

– if the session is on hold, the setting of the auxiliary state (as defined in 3GPP TS 24.083 [27]) is described in 3GPP TS 24.237 [136]; and

– if the session is a conferencing session, the setting of the multi party auxiliary state (as defined in 3GPP TS 24.084 [28]) is described in 3GPP TS 24.237 [136].

If the MS supports single radio PS to CS access transfer for calls in alerting state as specified in 3GPP TS 24.237 [136] subclause 12.2.3B, and the MS has a single voice media stream over the PS domain that is handed over to the CS domain via SRVCC, and the call control entity of the MS in the "null" state receives an indication "MM connection establishment due to SRVCC handover" then:

– the call control entity shall indicate to the upper layers that call establishment is due to SRVCC handover;

– if the upper layers indicate that the media stream(s) is/are associated with a mobile originated session in the "early" state (defined in IETF RFC 3261 [137]) according to the conditions specified in 3GPP TS 24.237 [136] subclause 12.2.3B.3.2, the call control entity of the MS shall enter the "call delivered" state for this transaction. The MS and the network shall locally set the TI value of the call to "000" and the TI flag value as in mobile terminated call; and

– if the upper layers indicate that the media stream(s) is/are associated with a mobile terminating session in the "early" state (defined in IETF RFC 3261 [137]) according to the conditions specified in 3GPP TS 24.237 [136] subclause 12.2.3B.3.1, the call control entity of the MS shall enter the "call received" state for this transaction. The MS and the network shall locally set the TI value of the call to "000" and the TI flag value as in mobile terminated call.

If the MS supports single radio PS to CS SRVCC for originating calls in pre-alerting phase as specified in 3GPP TS 24.237 [136] subclause 12.2.3B, and the MS has a single voice media stream over the PS domain that is handed over to the CS domain via SRVCC, and the call control entity of the MS in the "null" state receives an indication "MM connection establishment due to SRVCC handover" then:

– the call control entity shall indicate to the upper layers that call establishment is due to SRVCC handover; and

– if the upper layers indicate that the media stream(s) is/are associated with a mobile originated session in the "early" state (defined in IETF RFC 3261 [137]) according to the conditions specified in 3GPP TS 24.237 [136] subclause 12.2.3B.3.3, the call control entity of the MS shall enter the "mobile originating call proceeding" state for this transaction. The MS and the network shall locally set the TI value of the call to "000" and the TI flag value as in mobile terminated call.

If the MS supports single radio PS to CS SRVCC for terminating calls in pre-alerting phase as specified in 3GPP TS 24.237 [136] subclause 12.2.3B, and the MS has a single voice media stream over the PS domain that is handed over to the CS domain via SRVCC, and the call control entity of the MS in the "null" state receives an indication "MM connection establishment due to SRVCC handover" then:

– the call control entity shall indicate to the upper layers that call establishment is due to SRVCC handover; and

– if the upper layers indicate that the media stream(s) is/are associated with a mobile terminated session in the "early" state (defined in IETF RFC 3261 [137]) according to the conditions specified in 3GPP TS 24.237 [136] subclause 12.2.3B.3.2, the call control entity of the MS shall enter the "call present" state for this transaction. The MS and the network shall locally set the TI value of the call to "000" and the TI flag value as in mobile terminated call.

NOTE: As the MS is entering "call present" state, it must send a CALL CONFIRMED message to the network, even even the call context (including codecs) is already available at the MSC in order to enter "mobile terminating call confirmed" state.

If the MS has additional voice media streams carried over the PS domain that are handed over to the CS domain via SRVCC, the call states for the transactions and the setting of the TI value and TI flag for these additional media streams are described in 3GPP TS 24.237 [136].

If the MS supports multicall, the MS shall locally set SI value to "1" and the MS shall assume that the network does not support multicall. The network shall also locally set SI value to "1".

If the MS has a mobile originating session in the "early" state (as defined in IETF RFC 3261 [137]) and is providing an internally generated alerting indication to the user prior to the SRVCC handover, then after transitioning from the PS domain, the MS shall continue to provide the internal alerting indication to the user. The alerting indication is stopped when the user connection is attached.

If the MS has a mobile originated session established upon a request from the upper layers to establish an eCall over IMS, then after transitioning from the PS domain, the MS shall support inband transfer of the updated MSD according to 3GPP TS 26.267 [161].

5.2.4.2a Call activation for vSRVCC

If the MS supports vSRVCC, the MS has a voice media stream and a video media stream of a single session previously in S1 mode carried over the PS domain that are handed over to the CS domain via vSRVCC, the session associated with these media streams is in the "confirmed" state (defined in IETF RFC 3261 [137]), and the call control entity in "null" state receives indication "MM connection establishment due to vSRVCC handover", then the call control entity of the MS shall enter the "active" state, set the auxiliary state (defined in 3GPP TS 24.083 [27]) to "idle", set the multi party auxiliary state (defined in 3GPP TS 24.084 [28]) to "idle" and indicate the call establishment is due to vSRVCC handover to the upper layers. The MS and the network shall locally set the TI value of the call to "000" and the TI flag value as in mobile terminated call.

If the MS supports single radio PS to CS access transfer for calls in alerting state as specified in 3GPP TS 24.237 [136] subclause 12.2.3B, and the MS has a single voice media stream and a single video media stream carried over the PS domain that is handed over to the CS domain via vSRVCC, and the call control entity of the MS in the "null" state receives indication "MM connection establishment due to vSRVCC handover" then:

– the call control entity shall indicate to the upper layers that call establishment is due to vSRVCC handover;

If the MS supports single radio PS to CS SRVCC for originating calls in pre-alerting phase as specified in 3GPP TS 24.237 [136] subclause 12.2.3B, and the MS has a single voice media stream and a single video media stream carried over the PS domain that is handed over to the CS domain via vSRVCC, and the call control entity of the MS in the "null" state receives indication "MM connection establishment due to vSRVCC handover" then:

– the call control entity shall indicate to the upper layers that call establishment is due to vSRVCC handover; and

– if the upper layers indicate that the media stream(s) is/are associated with a mobile originated session in the "early" state (defined in IETF RFC 3261 [137]) according to the conditions specified in 3GPP TS 24.237 [136] subclause 12.2.3B.3.3, the call control entity of the MS shall enter the "mobile originating call proceeding" state for this transaction. The MS and the network shall locally set the TI value of the call to "000" and the TI flag value as in mobile terminated call.

If the MS supports single radio PS to CS SRVCC for terminating calls in pre-alerting phase as specified in 3GPP TS 24.237 [136] subclause 12.2.3B, and the MS has a single voice media stream and a single video media stream carried over the PS domain that is handed over to the CS domain via vSRVCC, and the call control entity of the MS in the "null" state receives indication "MM connection establishment due to vSRVCC handover" then:

– the call control entity shall indicate to the upper layers that call establishment is due to vSRVCC handover; and

– if the upper layers indicate that the media stream(s) is/are associated with a mobile originated session in the "early" state (defined in IETF RFC 3261 [137]) according to the conditions specified in 3GPP TS 24.237 [136] subclause 12.2.3B.3.2, the call control entity of the MS shall enter the "call present" state for this transaction. The MS and the network shall locally set the TI value of the call to "000" and the TI flag value as in mobile terminated call.

If the MS supports multicall, the MS shall locally set SI value to "1" and the MS shall assume that the network does not support multicall. The network shall also locally set SI value to "1".If the MS has a mobile originating session in the "early" state (as defined in IETF RFC 3261 [137]) and is providing an internally generated alerting indication to the user prior to the vSRVCC handover, then after transitioning from the PS domain, the MS shall continue to provide the internal alerting indication to the user. The alerting indication is stopped when the user connection is attached.

5.2.4.2b Multimedia CAT and vSRVCC handover

If the MS has a mobile originating session in the "early" state (as defined in IETF RFC 3261 [137]) and is receiving multimedia CAT over the PS domain prior to the vSRVCC handover, then after transitioning from the PS domain, the MS stops providing the early media to the user and may internally generate an alerting indication. The alerting indication is stopped when the user connection is attached.

5.2.4.3 Traffic channel assignment and user connection attachment

An appropriate traffic channel for the call is assigned in SRVCC handover, vSRVCC handover or 5G-SRVCC handover from NG-RAN to UTRAN.

For SRVCC handover or 5G-SRVCC handover from NG-RAN to UTRAN, the mobile station shall attach the user connection:

– when the call control entity enters the "active" state or the "call received" state;

– when the call control entity enters the "call delivered" state, if prior to SRVCC the MS in the PS domain was receiving media for the session subjected to SRVCC handover or 5G-SRVCC handover from NG-RAN to UTRAN; and

– when the call control entity enters the "mobile originating call proceeding" state, if prior to SRVCC the MS in the PS domain was receiving media for the session subjected to SRVCC handover5G-SRVCC handover from NG-RAN to UTRAN.

NOTE: The attachment of the user connection prior to entering the "active" state allows the network to provide in-band tones and announcements to the UE.

For vSRVCC handover, the mobile station shall attach the user connection when the call control entity enters the "active" state.

For SRVCC or vSRVCC handover to a speech call, the principles of speech codec selection are described in subclause 5.2.1.11.

For vSRVCC handover to a circuit-switched multimedia call, further requirements are specified in subclause 5.3.6.6.

5.2.4.4 State verification

The network may check the call and auxiliary states of its peer entity as specified in subclause 5.5.3.1 when the PS to CS access transfer is complete.