Redirection to GSM

This page follows a TD-SCDMA packet call that the network moves to GSM by redirection. Redirection is the simplest way to leave a TD-SCDMA cell. The network releases the RRC connection and tells the UE which GSM cell to look for. The UE then selects that cell by itself and registers there, so the GSM side needs no handover preparation. The cost is a short break in the data flow, because the UE passes through idle mode on the way.

Let's walk through the call flow first. Then we look at the one message that carries the redirection, and at what the UE does once it reaches the GSM cell.

What does the call flow look like?

The sequence below comes from one test run, and it has three parts. Steps 1 to 16 set up an ordinary PS data call on TD-SCDMA. Steps 17 to 21 release the RRC connection with redirection information. Steps 22 to 30 happen on the GSM cell, where the UE gets a channel and updates its routing area.

(1) UE <--> NW : Registration (Combined or Non-Combined)

(2) UE <--> NW : < IDLE >

(3) UE : < Make a MO Packet Call >

(4) UE --> NW : RRC CONNECTION REQUEST

(5) UE <-- NW : RRC CONNECTION SETUP

(6) UE --> NW : RRC CONNECTION SETUP COMPLETE

(7) UE --> NW : GMM SERVICE REQUEST

(8) UE <-- NW : AUTHENTICATION AND CIPHERING REQUEST

(9) UE --> NW : AUTHENTICATION AND CIPHERING RESPONSE

(10) UE <-- NW : SECURITY MODE COMMAND

(11) UE --> NW : SECURITY MODE COMPLETE

(12) UE --> NW : ACTIVATE PDP CONTEXT REQUEST

(13) UE <-- NW : RADIO BEARER SETUP

(14) UE --> NW : RADIO BEARER SETUP COMPLETE

(15) UE <-- NW : ACTIVATE PDP CONTEXT ACCEPT

(16) UE <--> NW : < User Data Flow >

(17) NW : Trigger for Redirection

(18) UE <-- NW : RRC CONNECTION RELEASE

(19) UE --> NW : RRC CONNECTION RELEASE COMPLETE

(20) UE --> NW : RRC CONNECTION RELEASE COMPLETE

(21) UE --> NW : RRC CONNECTION RELEASE COMPLETE

(22) UE --> NW : CHANNEL REQUEST/HANDOVER ACCESS

(23) UE <-- NW : IMMEDIATE ASSIGNMENT

(24) UE --> NW : ROUTING AREA UPDATE REQUEST

(25) UE <-- NW : AUTHENTICATION AND CIPHERING REQUEST

(26) UE --> NW : AUTHENTICATION AND CIPHERING RESPONSE

(27) UE <-- NW : IDENTITY REQUEST

(28) UE --> NW : IDENTITY RESPONSE

(29) UE <-- NW : ROUTING AREA UPDATE ACCEPT

(30) UE --> NW : ROUTING AREA UPDATE COMPLETE

The trigger in step 17 is a network decision, and the network does not signal it to the UE as a separate message. In a live network, a Measurement Report that shows a usable GSM cell often comes before it. The Measurement - GSM Meas in TDSCDMA page shows such a report for the same GSM cell, ARFCN 20 with NCC 1 and BCC 5.

Steps 19 to 21 are three copies of the same RRC CONNECTION RELEASE COMPLETE, and this is expected. In CELL_DCH the UE sends this message on unacknowledged mode RLC, so it gets no RLC acknowledgement. 25.331 clause 8.1.4.3 has the UE send the message once and start timer T308. Each time T308 expires, clause 8.1.4.6 has the UE send it again, until the counter V308 is greater than N308. The RRC CONNECTION RELEASE below sets n-308 to 2. So the UE sends one original and two repetitions.

Redirection is a release, not a handover : the UE leaves CELL_DCH, passes through idle mode and selects the GSM cell by itself.
Three RELEASE COMPLETE messages are normal : with n-308 set to 2, the UE sends one original and two repetitions over UM RLC.
The GSM part starts with random access : the UE has no dedicated resources on GSM until the network answers its CHANNEL REQUEST.

RRC Connection Release

One message carries the whole redirection. It is an ordinary RRC CONNECTION RELEASE with one extra IE. So the questions are where that IE sits and what it tells the UE. The capture below marks the GSM target cell in red.

Decoded RRC message from a tester log, captured. Field values are from a live capture, not from the specification.

  +-message ::= CHOICE [rrcConnectionRelease]
    +-rrcConnectionRelease ::= CHOICE [later-than-r3]
      +-later-than-r3 ::= SEQUENCE
        +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
        +-criticalExtensions ::= CHOICE [r4]
          +-r4 ::= SEQUENCE [1]
            +-rrcConnectionRelease-r4 ::= SEQUENCE [10]
            | +-n-308 ::= INTEGER (1..8) [2] OPTIONAL:Exist
            | +-releaseCause ::= ENUMERATED [normalEvent]
            | +-rplmn-information ::= SEQUENCE OPTIONAL:Omit
            +-v4d0NonCriticalExtensions ::= SEQUENCE [01] OPTIONAL:Exist
              +-rrcConnectionRelease-r4-add-ext ::= BIT STRING OPTIONAL:Omit
              +-v690NonCriticalExtensions ::= SEQUENCE [0] OPTIONAL:Exist
                +-rrcConnectionRelease-v690ext ::= SEQUENCE [1]
                | +-redirectionInfo-v690ext ::= CHOICE [interRATInfo] OPTIONAL:Exist
                |   +-interRATInfo ::= SEQUENCE [1]
                |     +-rat ::= ENUMERATED [gsm]
                |     +-gsm-TargetCellInfoList ::= [1] OPTIONAL:Exist
                |       +-GSM-TargetCellInfo ::= SEQUENCE [1]
                |         +-bcch-ARFCN ::= INTEGER (0..1023) [20]
                |         +-frequency-band ::= ENUMERATED [dcs1800BandUsed]
                |         +-bsic ::= SEQUENCE OPTIONAL:Exist
                |           +-ncc ::= INTEGER (0..7) [1]
                |           +-bcc ::= INTEGER (0..7) [5]
                +-v770NonCriticalExtensions ::= SEQUENCE OPTIONAL:Omit

The release part is short. The rrc-TransactionIdentifier is 0, and the releaseCause is normalEvent. The n-308 value is 2, which sets the number of RELEASE COMPLETE repetitions described above. 25.331 makes n-308 conditional on the UE state, and it is present here because the UE is in CELL_DCH. The rplmn-information IE is omitted.

The redirection sits in a non-critical extension, because the r4 body has no field for it. The network therefore adds v4d0NonCriticalExtensions and, inside it, v690NonCriticalExtensions. There, redirectionInfo-v690ext is a CHOICE between frequencyInfo and interRATInfo. This message selects interRATInfo and sets rat to gsm. The optional gsm-TargetCellInfoList then names one GSM cell. 25.331 allows up to 32 cells in this list.

The target cell has three fields, all marked in red. The bcch-ARFCN is 20. The frequency-band field is dcs1800BandUsed, and 25.331 clause 10.3.8.4g says only that it indicates how to interpret the BCCH ARFCN. It changes the result only for ARFCN 512 to 810, which DCS 1800 and PCS 1900 share. ARFCN 20 is a P-GSM 900 channel, because 45.005 Table 2-2 places P-GSM 900 at ARFCN 1 to 124. So the indicator has no effect here. The optional BSIC is present, with NCC 1 and BCC 5. It lets the UE check that it has found the intended cell and not another cell on the same carrier.

The capture stops at v770NonCriticalExtensions, which is omitted. In the current release the same chain continues. The v860 extension can redirect the UE to E-UTRA through redirectionInfo, and later extensions add extendedWaitTime and more E-UTRA target frequency information. None of them is needed for a redirection to GSM.

The target cell lives in the v690 extension : redirectionInfo-v690ext, CHOICE interRATInfo, rat gsm and gsm-TargetCellInfoList.
The band indicator does not matter for ARFCN 20 : it only separates DCS 1800 and PCS 1900 in the ARFCN range they share.
Include the BSIC when you know it : it is optional, but it lets the UE confirm the cell on that carrier.

What does the UE do after it reaches GSM?

After the release, the UE is in idle mode and has no radio resources on either system. It has to find the GSM cell, get a channel, and tell the core network where it is now. Steps 22 to 30 cover these three tasks.

The UE first selects the cell. 25.331 clause 8.5.2 says that, when GSM target cell info is present, the UE attempts to camp on a suitable cell from that list. If no listed cell is suitable within 10 s, the UE attempts to camp on any suitable GSM cell. So the target list guides the UE, but a wrong entry does not leave the UE without service.

Next, the UE needs a channel for signalling. It sends CHANNEL REQUEST on the RACH, and the network answers with IMMEDIATE ASSIGNMENT on the CCCH. 44.018 clause 3.5.2.1.2 describes this start of the packet access procedure. Step 22 is labelled CHANNEL REQUEST/HANDOVER ACCESS, but only CHANNEL REQUEST applies in this flow. The UE sends HANDOVER ACCESS only after a HANDOVER COMMAND, as 44.018 clause 3.4.4.2 describes, and a redirection has no HANDOVER COMMAND.

Finally, the UE registers its new location. In this log the UE starts a normal routing area update, which 24.008 clause 4.7.5.1 triggers when the MS detects a change of routing area. The network then runs two GMM common procedures before it accepts the update. Steps 25 and 26 are authentication and ciphering, and steps 27 and 28 are identification. 24.008 clause 4.7.5.1.2 allows the network to run such procedures during the update. The UE returns ROUTING AREA UPDATE COMPLETE in step 30. Clause 4.7.5.1.3 requires this answer when the ACCEPT carries a new P-TMSI or TMSI, receive N-PDU numbers, or a request for inter-RAT handover information.

The target list is tried first, for 10 s : after that the UE may camp on any suitable GSM cell.
Access on GSM starts from the beginning : CHANNEL REQUEST and IMMEDIATE ASSIGNMENT, with no handover reference.
The routing area update closes the procedure : the network may authenticate and identify the UE before the ACCEPT, and the UE answers with COMPLETE.

Reference

3GPP TS 25.331 v19.0.1 : clauses 8.1.4.3, 8.1.4.6, 8.5.2 and 10.3.8.4g, and the ASN.1 of RRCConnectionRelease, RedirectionInfo-r6 and GSM-TargetCellInfo in clause 11
3GPP TS 24.008 v20.0.0 : clauses 4.7.5.1, 4.7.5.1.2 and 4.7.5.1.3, the routing area updating procedure
3GPP TS 44.018 v19.0.0 : clause 3.5.2.1.2, packet access by CHANNEL REQUEST, and clause 3.4.4.2, HANDOVER ACCESS
3GPP TS 45.005 v19.0.0 : Table 2-2, fixed designation of ARFCN