Cell Change Order to GSM

This page shows how a TD-SCDMA network sends a UE with an active packet call to a GSM cell. The tool is the cell change order, CELL CHANGE ORDER FROM UTRAN in 25.331. It is not a handover. The network only names the target cell, and the UE then accesses that cell by itself and continues its PS session there. Below you will find the full sequence, two captured versions of the order, and what the UE does on the GSM side.

What does the TD-SCDMA to GSM cell change order sequence look like ?

The list below is the message order that a test setup shows for this case. Steps 1 to 16 are an ordinary packet call on the TD-SCDMA cell. Step 17 is the order itself, and steps 18 to 26 run on the GSM cell. Step 17 links to the captured messages further down.

(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) UE <-- NW : CELL CHANGE ORDER FROM UTRAN

(18) UE --> NW : CHANNEL REQUEST

(19) UE <-- NW : IMMEDIATE ASSIGNMENT

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

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

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

(23) UE <-- NW : IDENTITY REQUEST

(24) UE --> NW : IDENTITY RESPONSE

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

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

The steps fall into three groups, and each group is owned by a different specification. The table below shows the split.

Steps	Where it runs	What happens	Specification
1 - 16	TD-SCDMA cell	Packet call with one PDP context	25.331, 24.008
17	TD-SCDMA cell	Cell change order to the GSM cell	25.331 subclause 8.3.11
18 - 19	GSM cell	Random access and channel assignment	44.018
20 - 26	GSM cell	Routing area update	24.008 subclause 4.7.5

The UE needs a PS signalling connection and no CS one : 25.331 allows the order only when the established RABs are from the PS domain. That is why this list starts with a packet call.
The order is the last TD-SCDMA message : no RRC message follows it on the TD-SCDMA side when the change succeeds.
The UE sends the COMPLETE of the routing area update : ROUTING AREA UPDATE COMPLETE goes from the UE to the network, like every other COMPLETE message.

Step 17 - UE <-- NW : CELL CHANGE ORDER FROM UTRAN

The order is short, because the network only has to name the target cell. 25.331 subclause 8.3.11 allows it in CELL_DCH and CELL_FACH. The UE ignores the order if it has a CS signalling connection or no PS signalling connection. The current definition of the message is below.

Following is based on 25.331 v19.0.1 (Release 19)

CellChangeOrderFromUTRAN ::= CHOICE {
    r3                              SEQUENCE {
        cellChangeOrderFromUTRAN-IEs        CellChangeOrderFromUTRAN-r3-IEs,
        laterNonCriticalExtensions      SEQUENCE {
            -- Container for additional R99 extensions
            cellChangeOrderFromUTRAN-r3-add-ext     BIT STRING                      OPTIONAL,
            v590NonCriticalExtensions                   SEQUENCE {
                cellChangeOrderFromUTRAN-v590ext            CellChangeOrderFromUTRAN-v590ext-IEs,
                nonCriticalExtensions                       SEQUENCE {}             OPTIONAL
            }   OPTIONAL
        }   OPTIONAL
    },
    later-than-r3                   SEQUENCE {
        rrc-TransactionIdentifier       RRC-TransactionIdentifier,
        criticalExtensions              SEQUENCE {}
    }
}

CellChangeOrderFromUTRAN-r3-IEs ::= SEQUENCE {
    -- User equipment IEs
        rrc-TransactionIdentifier       RRC-TransactionIdentifier,
        -- dummy is not used in this version of the specification, it should
        -- not be sent and if received it should be ignored.
        dummy                           IntegrityProtectionModeInfo                 OPTIONAL,
        activationTime                  ActivationTime                                  OPTIONAL,
        -- the IE rab-InformationList is not used in this version of the specification, it should
        -- not be sent and if received it should be ignored. The IE may be used in a later
        -- version of the protocol and hence it is not changed into a dummy
        rab-InformationList         RAB-InformationList                         OPTIONAL,
        interRAT-TargetCellDescription  InterRAT-TargetCellDescription
}

CellChangeOrderFromUTRAN-v590ext-IEs ::= SEQUENCE {
        geran-SystemInfoType                CHOICE  {
            sI                                  GERAN-SystemInformation,
            pSI                                 GERAN-SystemInformation
        }       OPTIONAL
}

InterRAT-TargetCellDescription ::=  SEQUENCE {
    technologySpecificInfo              CHOICE {
        gsm                                 SEQUENCE {
            bsic                                BSIC,
            frequency-band                      Frequency-Band,
            bcch-ARFCN                          BCCH-ARFCN,
            ncMode                              NC-Mode             OPTIONAL
        },
        is-2000                             NULL,
        spare2                              NULL,
        spare1                              NULL
    }
}

GERAN-SystemInformation ::=         SEQUENCE (SIZE (1..maxGERAN-SI)) OF GERAN-SystemInfoBlock

GERAN-SystemInfoBlock ::=               OCTET STRING (SIZE (1..23))

NC-Mode ::=                         BIT STRING (SIZE (3))

The core of the message is interRAT-TargetCellDescription. For a GSM target it carries the BSIC, a band indicator, the BCCH ARFCN and an optional NC mode. The rab-InformationList and dummy fields are no longer used, and a UE ignores them. The Rel-5 extension v590 adds the GERAN system information, which network assisted cell change needs. The later-than-r3 branch holds only a transaction identifier and an empty criticalExtensions, so a message with content still uses r3.

Case 1 - Ordinary CCO

In the ordinary order the network gives the target cell and nothing else. Every optional field of r3-IEs is omitted, and laterNonCriticalExtensions is absent, so the r3 bit is 0. Every field in this capture still exists in 25.331 v19.0.1.

Captured CELL CHANGE ORDER FROM UTRAN, test equipment decode. Field values are from a live capture, not from the specification.

  +-message ::= CHOICE [cellChangeOrderFromUTRAN]
    +-cellChangeOrderFromUTRAN ::= CHOICE [r3]
      +-r3 ::= SEQUENCE [0]
        +-cellChangeOrderFromUTRAN-IEs ::= SEQUENCE [000]
        | +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
        | +-dummy ::= SEQUENCE OPTIONAL:Omit
        | +-activationTime ::= INTEGER OPTIONAL:Omit
        | +-rab-InformationList ::= SEQUENCE OF OPTIONAL:Omit
        | +-interRAT-TargetCellDescription ::= SEQUENCE
        |   +-technologySpecificInfo ::= CHOICE [gsm]
        |     +-gsm ::= SEQUENCE [1]
        |       +-bsic ::= SEQUENCE
        |       | +-ncc ::= INTEGER (0..7) [0]
        |       | +-bcc ::= INTEGER (0..7) [1]
        |       +-frequency-band ::= ENUMERATED [dcs1800BandUsed]
        |       +-bcch-ARFCN ::= INTEGER (0..1023) [5]
        |       +-ncMode ::= BIT STRING SIZE(3) [000] OPTIONAL:Exist
        +-laterNonCriticalExtensions ::= SEQUENCE OPTIONAL:Omit

Let's read the target cell description. The BSIC is NCC 0 and BCC 1. The BCCH ARFCN is 5, and in 45.005 Table 2-2 that is a P-GSM 900 channel. Its uplink is at 890 + 0.2 x 5 = 891.0 MHz, and its downlink is 45 MHz higher, at 936.0 MHz. The band indicator says dcs1800BandUsed, but it has no effect here. 25.331 uses it only to tell DCS 1800 from PCS 1900, whose ARFCNs overlap between 512 and 810.

The capture also sets ncMode to 000. When the network omits this IE, the UE reads the NC mode from the target cell. 25.331 defines the 3 bits as bits b1 to b3 of the NC mode IE in 44.018. In 44.018 v19.0.0 that IE, subclause 10.5.2.21c, is marked void. So the value cannot be decoded against the current release, and the capture is left as it is.

Case 2 - Network Assisted CCO

Network assisted cell change adds the system information of the target cell to the order. With it, the UE does not have to read the GSM BCCH before its first access, so the interruption of the data flow is shorter. 25.331 v19.0.1 still carries this information in the Rel-5 v590 extension.

Captured CELL CHANGE ORDER FROM UTRAN with GERAN system information, test equipment decode. Field values are from a live capture, not from the specification.

  +-message ::= CHOICE [cellChangeOrderFromUTRAN]
    +-cellChangeOrderFromUTRAN ::= CHOICE [r3]
      +-r3 ::= SEQUENCE [1]
        +-cellChangeOrderFromUTRAN-IEs ::= SEQUENCE [000]
        | +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
        | +-dummy ::= SEQUENCE OPTIONAL:Omit
        | +-activationTime ::= INTEGER OPTIONAL:Omit
        | +-rab-InformationList ::= SEQUENCE OF OPTIONAL:Omit
        | +-interRAT-TargetCellDescription ::= SEQUENCE
        |   +-technologySpecificInfo ::= CHOICE [gsm]
        |     +-gsm ::= SEQUENCE [1]
        |       +-bsic ::= SEQUENCE
        |       | +-ncc ::= INTEGER (0..7) [0]
        |       | +-bcc ::= INTEGER (0..7) [1]
        |       +-frequency-band ::= ENUMERATED [dcs1800BandUsed]
        |       +-bcch-ARFCN ::= INTEGER (0..1023) [5]
        |       +-ncMode ::= BIT STRING SIZE(3) [000] OPTIONAL:Exist
        +-laterNonCriticalExtensions ::= SEQUENCE [01] OPTIONAL:Exist
          +-cellChangeOrderFromUTRAN-r3-add-ext ::= BIT STRING OPTIONAL:Omit
          +-v590NonCriticalExtensions ::= SEQUENCE [0] OPTIONAL:Exist
            +-cellChangeOrderFromUTRAN-v590ext ::= SEQUENCE [1]
            | +-geran-SystemInfoType ::= CHOICE [sI] OPTIONAL:Exist
            |   +-sI ::= SEQUENCE OF SIZE(1..maxGERAN-SI[8]) [1]
                    // Put the system info block of Target GSM Cell here
            |     +-GERAN-SystemInfoBlock ::= OCTET STRING SIZE(1..23) [00]
            +-nonCriticalExtensions ::= SEQUENCE OPTIONAL:Omit

The target cell description is identical to Case 1. The difference is in the extension. The r3 bit is now 1, because laterNonCriticalExtensions is present. Inside it, v590NonCriticalExtensions carries geran-SystemInfoType with the choice sI. The line in red is the GERAN-SystemInfoBlock, and the green comment above it marks where the system information of the target GSM cell goes.

25.331 sets the rules for this field. The list holds up to maxGERAN-SI = 8 blocks, and each block is 1 to 23 octets. SI messages are encoded without their first 2 header octets, while PSI messages are encoded as they are. The UE uses the information only if it supports network assisted cell change and received the order in CELL_DCH. It also needs a correct and consistent set of SI or PSI messages. The capture holds one block with the single octet 00, which is a template value. A UE that receives it ignores the GERAN system information and continues the ordinary cell change order.

The target cell is BSIC plus ARFCN : the band indicator matters only for ARFCN 512 to 810.
NACC rides in the v590 extension : the r3 bit changes from 0 to 1 because laterNonCriticalExtensions becomes present.
Wrong GERAN system information is not fatal : the UE drops it and falls back to the ordinary cell change order.

What does the UE do on the GSM side ?

After step 17 the TD-SCDMA side is silent. Everything the UE does next follows GSM and GPRS procedures. One RRC timer still links the two sides.

On receipt of the order, the UE starts timer T309. 25.331 lets the network set it from 1 to 8 seconds, with 5 seconds as the default. The UE then accesses the GSM cell with CHANNEL REQUEST in step 18, and the network answers with IMMEDIATE ASSIGNMENT in step 19. 25.331 subclause 8.3.11.4 treats the response to the (PACKET) CHANNEL REQUEST as the successful end of the cell change order. So at step 19 the UE stops T309 and leaves UTRA RRC connected mode. HANDOVER ACCESS has no place here, because it belongs to the handover procedure.

If T309 expires first, or the access fails, the UE goes back. In CELL_DCH it restores the old TD-SCDMA configuration, and in CELL_FACH it returns to the old cell. It then reports CELL CHANGE ORDER FROM UTRAN FAILURE with the cause "physical channel failure".

Steps 20 to 26 are GMM. The UE is now in a different routing area and in A/Gb mode, so it starts a normal routing area update with ROUTING AREA UPDATE REQUEST. The network may authenticate the UE in steps 21 and 22 and ask for an identity in steps 23 and 24. At an inter-system change from Iu mode to A/Gb mode, 24.008 also allows ciphering to start without a new authentication. So steps 21 and 22 can be missing in another log. The UE returns ROUTING AREA UPDATE COMPLETE in step 26 when the ACCEPT carried a P-TMSI, a TMSI, receive N-PDU numbers or a request for inter-RAT handover information.

T309 guards the whole change : the UE has up to 8 seconds to get an answer on the GSM cell before it goes back.
IMMEDIATE ASSIGNMENT ends the procedure : from step 19 on, the UE is no longer RRC connected to the TD-SCDMA network.
The routing area update restores the PS service : the PDP context moves with the UE, so no new PDP context activation appears after step 26.
ROUTING AREA UPDATE COMPLETE is conditional : it appears only when the ACCEPT carries a new identity, N-PDU numbers or a request for inter-RAT handover information.

Reference

25.331 v19.0.1 : Radio Resource Control; Protocol specification. Subclauses 8.3.11, 10.2.5 and 10.3.3.43
24.008 v20.0.0 : Mobile radio interface Layer 3 specification; Core network protocols; Stage 3. Subclauses 4.7.5.1 and 4.7.7
44.018 v19.0.0 : Mobile radio interface layer 3 specification; Radio Resource Control protocol. Subclause 10.5.2.21c
45.005 v19.0.0 : Radio transmission and reception. Table 2-2