LTE to WCDMA CSFB

When a UE camps on LTE without VoLTE, a voice call still needs the CS domain of a 2G or 3G network. CS Fallback moves the UE from LTE to WCDMA at the moment the call starts, and this page follows that move one message at a time.

Before you go through this, I recommend you to read through CS Fallback page if you are totally new to the concept of CS Fallback.

There are several variations in CS Fallback. (NOTE : All of these are based on the assumption that VoLTE is not supported)

i) Somebody make a voice call to you when you are in <Idle in LTE>. (CSFB is triggered by Paging message)

ii) You make a voice call when you are in <Idle in LTE>

iii) Somebody make a voice call to you while you are in <Connected Mode in LTE> and you switch to a legacy network by Redirection.

iv) Somebody make a voice call to you while you are in <Connected Mode in LTE> and you switch to a legacy network by Handover.

v) You make a voice call when you are in <Connected Mode in LTE> and you switch to a legacy network by Redirection.

vi) You make a voice call when you are in <Connected Mode in LTE> and you switch to a legacy network by Handover.

The page follows variation iii): a mobile terminating call arrives while the UE is in connected mode, and the network moves the UE by redirection. 23.272 v20.0.0 clause 7.4 describes this case, a mobile terminating call in active mode without PS handover support.

Followings are the topics to be covered in this page.

CSFB Sequence Example

What does a complete CSFB call look like from the UE side? The table below lists every step of one test sequence, from power on in the LTE cell to the end of the voice call in the WCDMA cell. Cell 1 is the LTE cell and Cell 2 is the WCDMA cell.

Following is an example of CS Fallback from LTE to WCDMA Voice Call triggered by MT Voice Call. (If you remove Step 11, 12, it is almost same as MO CSFB sequence)

Step	Direction	Message	Target Cell	Memo
1	UE <---> SS	< Power On >	Cell 1
2	UE <---> SS	< PRACH and RACH Response >	Cell 1
3	UE ---> SS	RRC Connection Request	Cell 1
4	UE <--- SS	RRC Connection Setup	Cell 1
5	UE ---> SS	RRC Connection Setup Complete + Attach Request + PDN Conn Req	Cell 1
6	UE <---> SS	< NAS : Security Mode Establishment >	Cell 1
7	UE ---> SS	< RRC : Security Mode Establishment >	Cell 1
8	UE <--- SS	RRC Connection Reconfiguration + Attach Accept + ...	Cell 1
9	UE ---> SS	RRCConnectionReconfigurationComplete / Attach Complete / ...	Cell 1
10	UE <---> SS	< Packet Data Transaction >	Cell 1
11	SS	LTE Network Gets CS Notification from WCDMA NW
12	UE <--- SS	CS Service Notification with Paging Identity	Cell 1
13	UE ---> SS	Extended Service Request	Cell 1
14	UE <--- SS	RRC Connection Release with Redirected Carrier Info	Cell 1
15	UE <---> SS	< RRC Connection Setup with cause of terminatingConversationCall >	Cell 2
16	UE ---> SS	Routing Area Update Request	Cell 2
17	UE <---> SS	< Authentication >	Cell 2
18	UE <---> SS	< Voice Call Setup >	Cell 2
19	UE <---> SS	< End Voice Call >	Cell 2
20		What will happen here ?

Steps 1 to 10 are an ordinary LTE attach with one difference. The Attach Request asks for a combined EPS/IMSI attach, so the MME registers the UE with the MSC/VLR as well. The next section explains that step, because the rest of the sequence depends on it.

Steps 11 to 14 follow 23.272 clause 7.4. The MSC receives the incoming call and sends a Paging Request to the MME over the SGs interface. The UE is already connected, so the MME does not page it on the radio interface. It sends a CS Service Notification on the existing connection instead. The UE answers with an Extended Service Request, and the eNB releases the RRC connection with a redirection to the WCDMA carrier.

Steps 15 to 19 happen in the WCDMA cell. The UE sets up an RRC connection with the cause terminatingConversationCall, updates its routing area, and completes the call. Step 20 is the open question of where the UE goes after the call. The last section of this page covers it.

Steps 3 to 9 : combined EPS/IMSI attach, the precondition for CSFB.
Steps 11 to 14 : CS paging over SGs, CS Service Notification, Extended Service Request and release with redirection.
Steps 15 to 19 : the voice call in the WCDMA cell.

Combined EPS/IMSI Attach

CSFB only works if the MSC knows that it can reach the UE through the MME. The combined EPS/IMSI attach creates that link during the LTE attach, so a UE that attached for EPS services only can never be paged for a CS call over LTE.

One important thing to notice is that 'EPS/IMSI combined Attach' process should be properly completed during the attach process (Step 3 ~ 9).

If I decribe the combined attach process including core network activity, it goes as follows.

i) UE send the Attach Request to MME. In this message, the attach type should be 'EPS/IMSI Combined Attach' and this means that UE is capable and configured to use CS fallback. If UE support SMS only in CS domain and does not support CSFB, UE have to indicate 'SMS-only'.

ii) MME allocate a default LAI and derives the VLR number based on the allocated LAI and IMSI.

iii) MME sends a Location Update Request message to VLR. This Location Update Request message contains new LAI, IMSI, MME name, Location Update Type etc.

iv) The VLR stores the MME name

v) The VLR performs Location Updating procedure in CS domain

vi) The VLR sends Location Update Accept with TMSI to the MME

vii) The MME send Attach Accept carrying LAI and TMSI. The existence of LAI and TMSI in the Attach Accept message indicates successful attach to CS domain.

These steps follow 23.272 v20.0.0 clause 5.2. The MME allocates the new LAI, derives the VLR number from it, and starts the location update after it receives the subscriber data from the HSS. The Location Update Request carries the MME name, which is an FQDN string, and the VLR creates the SGs association by storing that name.

The Attach Accept can also limit the result. If the network supports SGs only for SMS, the MME indicates that the IMSI attach is for SMS only, and the UE then cannot use CSFB. The network can also accept the combined attach but add a CSFB Not Preferred indication. A UE that sees neither restriction, together with the LAI and TMSI, can expect CSFB to work.

Attach type combined EPS/IMSI attach : the UE is capable and configured for CSFB.
LAI and TMSI in the Attach Accept : successful attach to the CS domain.
SMS-only or CSFB Not Preferred : the network limits or discourages CSFB.

Messages Triggering CSFB

Two NAS messages start the fallback in this sequence. The network tells the UE about the incoming call, and the UE answers that it accepts it. Both travel inside RRC information transfer messages, because the UE is already in connected mode.

Followings are the two messages that triggers CSFB process.

CS Service Notification

The CS Service Notification replaces paging for a UE that is already connected. 24.301 v20.0.0 clause 8.2.9 defines it as the message the network sends when a paging request with a CS call indicator arrives over SGs and a NAS signalling connection already exists.

Decoded RRC message, tester tree format. Field values are from a captured message, not from the specification.

    +-c1 ::= CHOICE [dlInformationTransfer]
      +-dlInformationTransfer ::= SEQUENCE
        +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
        +-criticalExtensions ::= CHOICE [c1]
          +-c1 ::= CHOICE [dlInformationTransfer-r8]
            +-dlInformationTransfer-r8 ::= SEQUENCE [0]
              +-dedicatedInfoType ::= CHOICE [dedicatedInfoNAS]
              | +-dedicatedInfoNAS ::= OCTET STRING SIZE(ALIGNED) [270DCBC04504076401]
              +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

Decoded NAS message, tester tree format. Field values are from a captured message, not from the specification.

CS service notification ::= DIVISION
  +-Security header type ::= V
  | +-Security header type ::= CHOICE [Plain NAS message, not security protected]
  +-EPS mobility management protocol discriminator ::= V
  | +-Protocol discriminator ::= PD [7]
  +-CS service notification message identity ::= V
  | +-Message type ::= MSG [64]
  +-Paging identity ::= V
  | +-Octet1 ::= DIVISION
  |   +-spare ::= FIX [0]
  |   +-Paging identity value ::= CHOICE [TMSI]
  +-CLI ::= TLV OPTIONAL:Omit
  | +-Octet1 ::= DIVISION
  | | +-CLI IEI ::= IEI [60]
  | +-Octet2 ::= DIVISION
  | | +-Length of CLI ::= LEN (0..255) [0]
  | +-Octet3 ::= DIVISION
  | | +-ext ::= EXT (0..1) [1]
  | | +-type of number ::= INT (0..7) [0]
  | | +-Numbering plan identification ::= INT (0..15) [0]
  | +-Octet3a ::= DIVISION
  | | +-ext ::= EXT1 [1]
  | | +-presentation indicator ::= CHOICE [Presentation allowed]
  | | +-spare ::= FIX [0]
  | | +-screening indicator ::= CHOICE [User-provided, not screened]
  | +-Octet4-12 ::= DIVISION
  |   +-Number digit ::= DIGIT SIZE(0..10)
  +-SS Code ::= TV OPTIONAL:Omit
  | +-Octet1 ::= DIVISION
  | | +-SS Code IEI ::= IEI [61]
  | +-Octet2 ::= DIVISION
  |   +-SS Code value ::= CHOICE [allSS]
  +-LCS indicator ::= TV OPTIONAL:Omit
  | +-Octet1 ::= DIVISION
  | | +-LCS indicator IEI ::= IEI [62]
  | +-Octet2 ::= DIVISION
  |   +-LCS indicator value ::= CHOICE [MT-LR]
  +-LCS client identity ::= TLV OPTIONAL:Omit
    +-Octet1 ::= DIVISION
    | +-LCS client identity IEI ::= IEI [63]
    +-Octet2 ::= DIVISION
    | +-Length of LCS client identity ::= LEN (0..255) [0]
    +-Octet3- ::= DIVISION
      +-LCS client identity(value part) ::= OCTETARRAY SIZE(0..255) [00]

The RRC capture starts at the c1 choice, so the outer DL-DCCH-Message lines are not shown. The dedicatedInfoNAS value 270DCBC04504076401 opens with 27, which is security header type 2, integrity protected and ciphered, with protocol discriminator 7 for EMM. Next come the 4-octet MAC 0DCBC045 and the sequence number 04. The inner plain message is 07 64 01: message type 64 is CS service notification, and paging identity 1 means TMSI.

The optional CLI, SS Code, LCS indicator and LCS client identity are all omitted, so the message ends after the paging identity. The CLI is the caller number. 24.301 says the network sends it if it came over SGs, so this test network did not provide it.

Extended Service Request

The Extended Service Request is the UE's answer. It tells the MME that the UE accepts the CS call, and the MME then asks the eNB to move the UE to WCDMA with the CS Fallback Indicator.

Decoded RRC message, tester tree format. Field values are from a captured message, not from the specification.

+-c1 ::= CHOICE [ulInformationTransfer]
      +-ulInformationTransfer ::= SEQUENCE
        +-criticalExtensions ::= CHOICE [c1]
          +-c1 ::= CHOICE [ulInformationTransfer-r8]
            +-ulInformationTransfer-r8 ::= SEQUENCE [0]
              +-dedicatedInfoType ::= CHOICE [dedicatedInfoNAS]
              | +-dedicatedInfoNAS ::= OCTET STRING SIZE(ALIGNED) [274D83AB1F04074C0105F400000001B1]
              +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

Decoded NAS message, tester tree format. Field values are from a captured message, not from the specification.

NAS_LTE:EMM,Extended service request
Extended service request ::= DIVISION
  +-Security header type ::= V
  | +-Security header type ::= CHOICE [Plain NAS message, not security protected]
  +-EPS mobility management protocol discriminator ::= V
  | +-Protocol discriminator ::= PD [7]
  +-Extended service request message identity ::= V
  | +-Message type ::= MSG [4C]
  +-NAS key set identifier ::= V
  | +-TSC ::= CHOICE [native security context (for KSI ASME)]
  | +-NAS key set identifier ::= CHOICE [possible values for the NAS key set identifier 0]
  +-Service type ::= V
  | +-Service type value ::= CHOICE [mobile terminating CS fallback or 1xCS fallback]
  +-M-TMSI ::= LV
  | +-Octet1 ::= DIVISION
  | | +-Length of mobile identity contents ::= LEN (0..255) [5]
  | +-Octet2 ::= DIVISION
  | | +-Identity digit 1 ::= INT (0..15) [15]
  | | +-Odd/even indication ::= CHOICE 
                                [even number of identity digits and also when the TMSI/P-TMSI is used]
  | | +-Type of identity ::= CHOICE [TMSI/P-TMSI/M-TMSI]
  | +-Octet3-Octet6 ::= DIVISION
  |   +-Identity digit p ::= OCTETARRAY SIZE(0..4) [00000001]
  +-CSFB response ::= TV OPTIONAL:Exist
    +-Octet1 ::= DIVISION
      +-CSFB response IEI ::= IEI [B-]
      +-spare ::= FIX [0]
      +-CSFB response value ::= CHOICE [CS fallback accepted by the UE]

The dedicatedInfoNAS value decodes as follows against 24.301 v20.0.0 Table 8.2.15.1. The service type and the CSFB response are the two fields that turn this into a CSFB answer.

Octets	Field	Value
27	Security header type, protocol discriminator	2, integrity protected and ciphered; 7, EMM
4D83AB1F	Message authentication code	MAC of the protected message
04	Sequence number	4
07	Security header type, protocol discriminator	0, plain NAS message; 7, EMM
4C	Message type	Extended service request
01	NAS key set identifier, service type	KSI 0 native; service type 1, mobile terminating CS fallback or 1xCS fallback
05 F4 00000001	M-TMSI	length 5, type TMSI, value 00000001
B1	CSFB response	IEI B, value 1, CS fallback accepted by the UE

The CSFB response is included only when the service type is mobile terminating CS fallback. With value 0, the UE would reject the call, and the MME would send a paging reject to the MSC instead of starting the fallback (23.272 clause 7.4, step 1c).

CS Service Notification : paging for a CS call on an existing connection, message type 64.
Extended Service Request : service type 1 and CSFB response 1 accept the call.
Both are protected NAS messages : security header type 2 inside the RRC transfer.

RRC Connection Release for Redirection

One of the important steps of CSFB is to optimize 'RRC Release' message from LTE network. (This is step 14 in the example sequence of this section). This is important step because the time delay (Redirection Delay) between LTE RRC Release and UMTS PRACH may vary depending on how much detailed information that this message carries. As far as I experienced, there may be several different types of RRC Release message as shown below (These are only examples)

The three captures below differ in how much they tell the UE about the target cell. The more the release carries, the less the UE has to read in the WCDMA cell before it can send its first PRACH.

RRC Connection Release - Release 8

The Release 8 form carries only the target carrier. The UE has to search the carrier for a cell and read its system information before it can access it, which is the slowest of the three.

Decoded RRC message, tester tree format. Field values are from a captured message, not from the specification.

DL-DCCH-Message ::= SEQUENCE
  +-message ::= CHOICE [c1]
    +-c1 ::= CHOICE [rrcConnectionRelease]
      +-rrcConnectionRelease ::= SEQUENCE
        +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
        +-criticalExtensions ::= CHOICE [c1]
          +-c1 ::= CHOICE [rrcConnectionRelease-r8]
            +-rrcConnectionRelease-r8 ::= SEQUENCE [100]
              +-releaseCause ::= ENUMERATED [other]
              +-redirectedCarrierInfo ::= CHOICE [utra-FDD] OPTIONAL:Exist
              | +-utra-FDD ::= INTEGER (0..16383) [9900]
              +-idleModeMobilityControlInfo ::= SEQUENCE OPTIONAL:Omit
              +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

redirectedCarrierInfo is utra-FDD 9900, the UARFCN of a WCDMA downlink carrier. Divided by 5, it gives 1980 MHz, in operating band II. The releaseCause is other, the normal value for a CSFB redirection that has no high priority.

RRC Connection Release - Release 9 with PCI only and No BCCH Information

Release 9 adds cellInfoList-r9 in the RRCConnectionRelease-v920-IEs extension. This capture uses it to name the target cell, but it gives no system information for that cell.

Decoded RRC message, tester tree format. Field values are from a captured message, not from the specification.

DL-DCCH-Message ::= SEQUENCE
  +-message ::= CHOICE [c1]
    +-c1 ::= CHOICE [rrcConnectionRelease]
      +-rrcConnectionRelease ::= SEQUENCE
        +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
        +-criticalExtensions ::= CHOICE [c1]
          +-c1 ::= CHOICE [rrcConnectionRelease-r8]
            +-rrcConnectionRelease-r8 ::= SEQUENCE [101]
              +-releaseCause ::= ENUMERATED [other]
              +-redirectedCarrierInfo ::= CHOICE [utra-FDD] OPTIONAL:Exist
              | +-utra-FDD ::= INTEGER (0..16383) [9900]
              +-idleModeMobilityControlInfo ::= SEQUENCE OPTIONAL:Omit
              +-nonCriticalExtension ::= SEQUENCE [01] OPTIONAL:Exist
                +-lateNonCriticalExtension ::= OCTET STRING OPTIONAL:Omit
                +-nonCriticalExtension ::= SEQUENCE [10] OPTIONAL:Exist
                  +-cellInfoList-r9 ::= CHOICE [utra-FDD-r9] OPTIONAL:Exist
                  | +-utra-FDD-r9 ::= SEQUENCE OF SIZE(1..maxCellInfoUTRA-r9[16]) [1]
                  |   +-CellInfoUTRA-FDD-r9 ::= SEQUENCE
                  |     +-physCellId-r9 ::= INTEGER (0..511) [202]
                  |     +-utra-BCCH-Container-r9 ::= OCTET STRING SIZE(ALIGNED)
                  +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

physCellId-r9 = 202 is the primary scrambling code of the target cell. The utra-BCCH-Container-r9 field is mandatory in CellInfoUTRA-FDD-r9, so it is present here but empty. The UE still has to read the system information itself, but it can skip the search for the cell.

RRC Connection Release - Release 9 with PCI and BCCH Information

The full Release 9 form adds the system information of the target cell as well. This is the redirection with Multi Cell System Information of 23.272 clause 6.3, step 3c, and it is the fastest of the three.

Decoded RRC message, tester tree format. Field values are from a captured message, not from the specification.

DL-DCCH-Message ::= SEQUENCE
  +-message ::= CHOICE [c1]
    +-c1 ::= CHOICE [rrcConnectionRelease]
      +-rrcConnectionRelease ::= SEQUENCE
        +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
        +-criticalExtensions ::= CHOICE [c1]
          +-c1 ::= CHOICE [rrcConnectionRelease-r8]
            +-rrcConnectionRelease-r8 ::= SEQUENCE [101]
              +-releaseCause ::= ENUMERATED [loadBalancingTAUrequired]
              +-redirectedCarrierInfo ::= CHOICE [utra-FDD] OPTIONAL:Exist
              | +-utra-FDD ::= INTEGER (0..16383) [9900]
              +-idleModeMobilityControlInfo ::= SEQUENCE OPTIONAL:Omit
              +-nonCriticalExtension ::= SEQUENCE [01] OPTIONAL:Exist
                +-lateNonCriticalExtension ::= OCTET STRING OPTIONAL:Omit
                +-nonCriticalExtension ::= SEQUENCE [10] OPTIONAL:Exist
                  +-cellInfoList-r9 ::= CHOICE [utra-FDD-r9] OPTIONAL:Exist
                  | +-utra-FDD-r9 ::= SEQUENCE OF SIZE(1..maxCellInfoUTRA-r9[16]) [1]
                  |   +-CellInfoUTRA-FDD-r9 ::= SEQUENCE
                  |     +-physCellId-r9 ::= INTEGER (0..511) [9]
                  |     +-utra-BCCH-Container-r9 ::= OCTET STRING SIZE(ALIGNED) [285084403C...00]
                  +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

For the fully decoded example of this message, see this file.

Here the utra-BCCH-Container-r9 carries the System Information Container message of 25.331 for scrambling code 9. The UE can then access the cell without reading its broadcast channel. One detail is unusual. The releaseCause is loadBalancingTAUrequired, which 36.331 ties to a tracking area update after the release. A CSFB redirection normally uses other or cs-FallbackHighPriority.

RRCConnectionRelease in 36.331 v19.3.0

The captures above predate several extensions. The current definitions below show where each captured field sits in 36.331 v19.3.0, and which fields later releases added around it, from Release 10 causes to Release 19 carriers.

Following is based on 36.331 v19.3.0 (Release 19)

RRCConnectionRelease-r8-IEs ::=     SEQUENCE {
    releaseCause                        ReleaseCause,
    redirectedCarrierInfo               RedirectedCarrierInfo               OPTIONAL,   -- Need ON
    idleModeMobilityControlInfo         IdleModeMobilityControlInfo         OPTIONAL,   -- Need OP
    nonCriticalExtension                RRCConnectionRelease-v890-IEs       OPTIONAL
}

RRCConnectionRelease-v890-IEs ::=   SEQUENCE {
    lateNonCriticalExtension            OCTET STRING (CONTAINING RRCConnectionRelease-v9e0-IEs) OPTIONAL,
    nonCriticalExtension                RRCConnectionRelease-v920-IEs       OPTIONAL
}

RRCConnectionRelease-v920-IEs ::=   SEQUENCE {
    cellInfoList-r9                 CHOICE {
        geran-r9                        CellInfoListGERAN-r9,
        utra-FDD-r9                     CellInfoListUTRA-FDD-r9,
        utra-TDD-r9                     CellInfoListUTRA-TDD-r9,
        ...,
        utra-TDD-r10                    CellInfoListUTRA-TDD-r10
    }                                                           OPTIONAL,   -- Cond Redirection
    nonCriticalExtension            RRCConnectionRelease-v1020-IEs      OPTIONAL
}

CellInfoListUTRA-FDD-r9 ::=         SEQUENCE (SIZE (1..maxCellInfoUTRA-r9)) OF CellInfoUTRA-FDD-r9

CellInfoUTRA-FDD-r9 ::=             SEQUENCE {
    physCellId-r9                       PhysCellIdUTRA-FDD,
    utra-BCCH-Container-r9              OCTET STRING
}

RedirectedCarrierInfo ::=           CHOICE {
    eutra                               ARFCN-ValueEUTRA,
    geran                               CarrierFreqsGERAN,
    utra-FDD                            ARFCN-ValueUTRA,
    utra-TDD                            ARFCN-ValueUTRA,
    cdma2000-HRPD                       CarrierFreqCDMA2000,
    cdma2000-1xRTT                      CarrierFreqCDMA2000,
    ...,
    utra-TDD-r10                        CarrierFreqListUTRA-TDD-r10,
    nr-r15                              CarrierInfoNR-r15,
    nr-r17                              CarrierInfoNR-r17,
    nr-NTN-r19                          CarrierInfoNR-r19,
    eutra-NTN-r19                       CarrierInfoEUTRA-r19,
    nbiot-NTN-r19                       CarrierInfoNB-r19
}

ReleaseCause ::=                ENUMERATED {loadBalancingTAUrequired,
                                            other, cs-FallbackHighPriority-v1020, rrc-Suspend-v1320}

cellInfoList-r9 is conditional on Redirection: it may be present only when redirectedCarrierInfo is set to geran, utra-FDD, utra-TDD or utra-TDD-r10. It holds at most maxCellInfoUTRA-r9 = 16 cells. ReleaseCause gained cs-FallbackHighPriority in Release 10, which the eNB sets when the S1AP request carries CSFB High Priority. RedirectedCarrierInfo later gained NR carriers and, in Release 19, NTN carriers.

Release 8 : carrier only, the UE searches and reads the cell.
Release 9, PCI only : the UE knows the cell but reads its system information.
Release 9 with BCCH container : the UE can access the cell at once.
cs-FallbackHighPriority : Release 10 cause for priority CSFB to UTRA.

Step 20 - What will happen ?

The call ends in the WCDMA cell, but the UE came from LTE and would normally be better served there. What moves it back, and how quickly, decides how long the UE stays on the older network after every CSFB call.

From the beginning of SRVCC (or SCFB as well), there has been many questions about this. What will or What should happen when the voice call is finished.

As far as I know there is no 3GPP specifiction on what should happen at this stage. I think it is all up to UE implementation and Network Operator's requirement.

First, let's think of all the possible scenarios that can happen at this stage. Followings are the list that I can think of

Case 1 : If any packet data is established along with the voice call, UE (Network) keep staying at WCDMA connection mode until the packet call is finished.
Case 2 : (If there is no background packet call). Network sends 'RRC Connection Release' when the voice call ends and UE goes to WCDMA Idle and stay in WCDMA Idle.
Case 3 : (If there is no background packet call). Network sends 'RRC Connection Release' when the voice call ends and UE goes to WCDMA Idle and UE performs cell reselction to LTE cell (Usually in this case, LTE cell is set to be preferred cell in UE setting or Network assigns LTE with higher priority)
Case 4 : (Regardless of whether this is background packet call or not). Network sends RRC Connection Release with Redirection to LTE cell and UE is forced to go back to LTE cell as soon as it finish the voice call.

23.272 v20.0.0 clause 6.5 confirms that there is no CSFB-specific mechanism for the return. Once the CS service ends, existing mechanisms move the UE to E-UTRAN. The MSC should tell the RNC that the call was set up by CS fallback. The RNC can use that to choose, for example, an RRC Connection Release with redirection back to E-UTRAN, which is Case 4 above (clause 4.3.7). Back in LTE, the UE sends a TAU Request, and the MME resumes any suspended EPS bearers.

No CSFB-specific return procedure : 23.272 clause 6.5.
The MSC marks the call as CSFB : so the RNC can redirect the UE to LTE.
TAU on return : resumes suspended EPS bearers.

Reference

[1] 3GPP TS 23.272 v20.0.0 - clauses 5.2, 6.3, 6.5 and 7.4, Circuit Switched Fallback in EPS

[2] 3GPP TS 24.301 v20.0.0 - clauses 8.2.9 and 8.2.15, CS SERVICE NOTIFICATION and EXTENDED SERVICE REQUEST

[3] 3GPP TS 36.331 v19.3.0 - RRCConnectionRelease

[4] CS Fallback