3G/UMTS-TDSCDMA

 

 

 

Protocol Sequence - Multi RAB (Two PDP + AMR)

 

This page shows a TD-SCDMA UE that carries two PS data sessions and then receives a voice call on top of them. At the end of the list, one RRC connection holds three RABs: two PS RABs for the PDP contexts and one CS RAB for AMR speech. This is what a multi RAB call means. The PS part follows the two PDP packet call. The CS part is a mobile terminated call, and it looks different from an ordinary voice call because the UE is already connected, normally in CELL_DCH, when the call arrives.

What does the multi RAB sequence look like ?

The list below is the message order that a test setup shows for this call. Steps 1 to 20 are the PS part and steps 21 to 34 are the CS part. Pay attention to the arrows in the CS part. The UE is the called party, so it sends CALL CONFIRMED, ALERTING and CONNECT, and the network sends SETUP and CONNECT ACK.

    (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 (1st PDP)

    (13) UE <-- NW : RADIO BEARER SETUP (Single Data Flow)

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

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

    (16) UE : < Make another Packet Call triggering 2nd PDP >

    (17) UE --> NW : ACTIVATE PDP CONTEXT REQUEST (2nd PDP)

    (18) UE <-- NW : RADIO BEARER SETUP (Two Data Flow)

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

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

    (21) NW : Incoming Voice call from other UE

    (22) UE <-- NW : PAGING TYPE 2

    (23) UE --> NW : PAGING RESPONSE

    (24) UE <-- NW : AUTHENTICATION REQUEST

    (25) UE --> NW : AUTHENTICATION RESPONSE

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

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

    (28) UE <-- NW : SETUP

    (29) UE --> NW : CALL CONFIRMED

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

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

    (32) UE --> NW : ALERTING

    (33) UE --> NW : CONNECT

    (34) UE <-- NW : CONNECT ACK

The call has three phases, and each one adds one RAB. The table below shows where each phase starts and which RAB it leaves behind.

 

Steps

Phase

CN domain

RAB added

1 - 15

First packet call from IDLE

PS

PS RAB of the 1st PDP context

16 - 20

Second packet call while connected

PS

PS RAB of the 2nd PDP context

21 - 34

Mobile terminated voice call while connected

CS

CS RAB for AMR speech

 

  • Only the first phase builds the RRC connection : steps 4 to 6 appear once, and the voice call uses the same connection.
  • The CS domain still needs its own security : steps 24 to 27 repeat authentication and security mode control, because the CS domain has its own keys.
  • The voice call is mobile terminated : the UE answers SETUP with CALL CONFIRMED, not with CALL PROCEEDING, and it is the UE that sends ALERTING and CONNECT.

How does the voice call reach a UE that is already connected ?

A UE in IDLE is paged with PAGING TYPE 1 on the PCCH. But this UE is in connected mode, normally CELL_DCH, so it does not read the paging channel. The network therefore uses a different message on a different channel.

25.331 subclause 8.1.11 calls this UE dedicated paging. For a UE in CELL_DCH, CELL_FACH or CELL_PCH, the network sends PAGING TYPE 2 on the DCCH using AM RLC. The message tells the UE which CN domain is calling and why, as the definition below shows.

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

PagingType2 ::= SEQUENCE {
    -- User equipment IEs
        rrc-TransactionIdentifier       RRC-TransactionIdentifier,
        pagingCause                 PagingCause,
    -- Core network IEs
        cn-DomainIdentity               CN-DomainIdentity,
        pagingRecordTypeID              PagingRecordTypeID,
        laterNonCriticalExtensions      SEQUENCE {
            -- Container for additional R99 extensions
            pagingType2-r3-add-ext          BIT STRING                      OPTIONAL,
            nonCriticalExtensions               SEQUENCE {}                 OPTIONAL
        }   OPTIONAL
}

In step 22 the cn-DomainIdentity is the CS domain, and the pagingCause is normally a terminating conversational call. The UE forwards both to its NAS. The RRC state does not change, and the data RABs keep running.

Step 23 is the answer. In 24.008 subclause 4.5.1.3.3, a UE in Iu mode answers CS paging with the PAGING RESPONSE message of 44.018, and it uses the RR protocol discriminator for backward compatibility. The UE has no CS signalling connection yet. So RRC carries this first CS message in an INITIAL DIRECT TRANSFER, which is the 25.331 procedure for opening a signalling connection to a CN domain.

Steps 24 to 27 then secure the new connection. The MSC authenticates the UE with the MM messages AUTHENTICATION REQUEST and AUTHENTICATION RESPONSE. These are the CS domain counterparts of the GMM messages in steps 8 and 9. After that, the RNC sends a second SECURITY MODE COMMAND. Its CN domain identity IE tells the UE which domain's ciphering and integrity keys to use.

  • A connected UE is paged on the DCCH : PAGING TYPE 2 replaces PAGING TYPE 1 for a UE in CELL_DCH, CELL_FACH or CELL_PCH.
  • PAGING RESPONSE opens the CS signalling connection : RRC sends it in INITIAL DIRECT TRANSFER, because the CS domain has no connection to the UE yet.
  • Each CN domain has its own keys : the second SECURITY MODE COMMAND is for the CS domain and does not replace the PS security.

How is the voice call set up on top of the data RABs ?

Once the CS connection is secure, call control starts. This is the mobile terminating procedure of 24.008 subclause 5.2.2, and it runs in parallel with the PS data. Let's follow it message by message.

In step 28 the network sends SETUP. The UE checks that it can accept the call, and in step 29 it answers with CALL CONFIRMED. CALL PROCEEDING belongs to the mobile originating call, where the network sends it. Next, the network sets up the CS RAB with RADIO BEARER SETUP in step 30, and the UE confirms it in step 31. The same message also has to reconfigure the transport channels, because the AMR flow now shares the dedicated channels with the two PS flows.

In step 32 the UE starts ringing and sends ALERTING. In step 33 the user answers, and the UE sends CONNECT. The network confirms with CONNECT ACK in step 34, and the call is active. From now on, the UE carries speech and two data sessions over one RRC connection.

The CS RAB also changes what the network can do with the UE later. 25.331 subclause 8.3.11 allows a cell change order to GSM only when the established RABs are from the PS domain. A UE with a CS signalling connection acts as if a CELL CHANGE ORDER FROM UTRAN was never received. So during this call the network has to use inter-RAT handover instead. The Cell Change Order - TD-SCDMA to GSM page shows the PS only case.

  • The called UE sends CALL CONFIRMED, ALERTING and CONNECT : 24.008 subclause 5.2.2 gives the network only SETUP and CONNECT ACKNOWLEDGE in this exchange.
  • The voice RAB is added, not swapped in : RADIO BEARER SETUP adds the CS RAB and keeps both PS RABs.
  • A CS RAB rules out cell change order : with a voice call active, mobility to GSM needs a handover.

Reference