LTE Quick Reference                                  Go Back To Index    Home : www.sharetechnote.com

 

 

 

 

SRVCC(Single Radio Voice Call Continuity)

 

SRVCC stands for Single Radio Voice Call Continuity. Putting it simple, it is a Handover technology between "VoIP over IMS in LTE" and Voice Call (CS) in a legacy system (e.g, WCDMA). It means it is for Handover between a Packet call in LTE and a Circuit Call in a legacy system (WCDMA).

 

 

 

Overall SRVCC Mechanism

 

The simplest use model can be illustrated as in < Case 1 > of the following figure showing the SRVCC between LTE and UMTS (The detailed mechanism would vary depending on what kind of legacy technology is involved). A little bit complicated use-model can be illustrated as in < Case 2 >. In < Case 2 >, user is doing VoIP while he is using another packet transaction (e.g, email, browsing etc). In this case, the radio bearer on WCDMA side should be a multiple Radio Bearer (CS + PS). There may be many different type of use model as well.

 

Overall procedure of SRVCC can be illustrated as follows. This is not the exact message sequence. This is just to give you a big picture of the flow. The exact sequence flow would vary depending on what kind of legacy technology gets involved.

 

 

Then you may ask "Why do we need this kind of technology when we already have Voice implementation in our LTE Network ?".

Let's think about this kind of situation.

A network operator has UMTS network covering all of its territory and it just started deploying LTE. But LTE deployment is not complete yet to cover the whole territory. Now a subscriber started voice call via IMS in the area with LTE network. And the it starts moving out of the LTE coverage. What would happen ? If the simplest possibility would be that the call would drop. But if the area is still strongly covered by a UMTS network, you can have another option than dropping the call. If you can hand the voice call over to the UMTS network, you can maintain the call even when you get out of the LTE network. This is a major motivation for SRVCC. Of course, different network opertor may have different motivation.

 

 

SRVCC Evolution

 

Even though SRVCC is relatively old concept, I don't see this feature is such a widely deployed as of now (Mar 2015). Also, the initial SRVCC mechanism is not so well optimized especially in terms of core network process. As a result, even before it is widely spread, we already see a lot of different evolutions for this technology. Followings are some of the list we often hear as of now, but the list would get longer.

 

Common Name

3GPP Release

Description

Basic SRVCC

Rel 8

Call Continuity from E-UTRAN to UTRAN/GRAN

aSRVCC

Rel 10

Packet switched to Circuit Switched call transfer during Alerting Phase

eSRVCC

Rel 10

Enhanced SRVCC (Support for MSC Server assisted Mid Call Feature)

vSRVCC

Rel 11

Video SRVCC

rSRVCC

Rel 11

SRVCC from UTRAN/GRAN to E-UTRAN

 

 

UE Capability Information for SRVCC : LTE RRC

 

It is hard to find clear indicator for SRVCC supportability and even though there are some optional and indirect indictor, I don't see many UEs properly set all those elements properly as of now (Mar 2015). I think it is because SRVCC is still an early stage of implementation.

 

Following is Information Elements of showing SRVCC supportability in UE Capability Information message (36.331 v12.03). As you see, all of these IEs are Optional and you may not see these IE set even though UE support SRVCC.

 

 

Following is part of FGI (Feature Group Indicator) in UE Capability Information which may give you some indirect indication for SRVCC Support. Since these fields are related to other features as well, it is not guaranteed that UE support SRVCC even though all of the these fields are set to 1.

 

 

 

< Protocol Sequence Example 1 - Basic SRVCC/Rel 8>

 

In terms of overal protocol flow, SRVCC is very similar to general Handover. But going into detail, you may have some questions. You may ask how network knows whether it has to initate SRVCC or general PS handover ? or How UE knows whether it should convert its IMS call to CS (AMR) call ? What would happen to the IMS/SIP call after SRVCC ? etc. In short, all these questions are about "Decision Making" process in UE and Network.

 

The answer to these questions may not be clearly stated in the specification and there might be some variations depending on Network Operator's requirement. But you can make some hints from 36.523-1 13.4.3.2 (Especially step 10 and 15)

 

In this example, I assume that the EPS Bearer Configuration for IMS/VoLTE is based on < Case 2 >. Depending on which EPS Bearer Configuration is used (usually determined by Network Operator's requirement), you would have a little bit different protocol sequence.

 

Case 1 :

 

 

Case 2 :

 

 

Case 3 :

 

 

Following is the overal Protocol Sequence for SRVCC.

    1) [   LTE   ]  RRC : PRACH Preamble

    2) [   LTE   ]  RRC : RACH Response

    3) [   LTE   ]  RRC : RRC Connection Request

    9) [   LTE   ]  RRC : RRC Connection Setup

    4) [   LTE   ]  RRC : RRC Connection Setup Complete

                      + NAS : Attach Request + ESM : PDN Connectivity Request

    5) [   LTE   ]  RRC : DL Information Transfer + NAS : Authentication Request

    6) [   LTE   ]  RRC : UL Information Transfer + NAS : Authentication Response

    7) [   LTE   ]  RRC : DL Information Transfer + NAS : Security Mode Command

    8) [   LTE   ]  RRC : UL Information Transfer + NAS : Security Mode Complete

    9) [   LTE   ]  RRC : Security M ode Command

    10) [   LTE   ]  RRC : Security Mode Complete

    11) [   LTE   ]  RRC : UE Capability Enquiry

    12) [   LTE   ]  RRC : UE Capability Information

    13) [   LTE   ]  RRC : RRC Connection Reconfiguration

                        + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req

    14) [   LTE   ] RRC : RRC Connection Reconfiguration Complete

                        + NAS : Attach Complete + NAS : Activate Default EPS Bearer Context Accept

    15) [   LTE   ] < UE Perform IMS Registration >

    16) [   LTE   ] < Make a VoLTE Call and Voice Traffic flows as a SIP traffic >

    17) [   LTE   ] < UE Movies Into WCDMA region which would trigger SRVCC >

    18) [   LTE   ] RRC : Mobility From EUTRA Command

    19) [WCDMA] RRC : HANDOVER To UTRAN Complete

    20) [WCDMA] RRC : Security Mode Command

    21) [WCDMA] RRC : Security Mode Complete

    22) [WCDMA] RRC : UTRAN Mobility Information

    23) [WCDMA] RRC : UTRAN Mobility Information Confirm

    24) [WCDMA] GMM : Routing Area Update Request

    25) [WCDMA] GMM : Authentication And Ciphering Request

    26) [WCDMA] GMM : Authentication And Ciphering Response

    27) [WCDMA] RRC : Security Mode Command

    28) [WCDMA] RRC : Security Mode Complete

    29) [WCDMA] GMM : Routing Area Update Accept

    30) [WCDMA] GMM : Routing Area Update Complete

    31) [WCDMA] [UE -> NW] GMM : SERVICE REQUEST // This may or may not happen depending on situation

    32) [WCDMA] [UE <- NW] GMM : SERVICE ACCEPT

    33) [WCDMA] [UE <- NW] RRC : Radio Bearer Setup // This is triggered by Step 31.

    34) [WCDMA] [UE -> NW] GMM : Radio Bearer Setup Complete

    35) [WCDMA] < Voice Call would redirected from LTE to WCDMA CS/AMR Bearer >

    36) [WCDMA] < Any non-voice IP traffic may redirected to WCDMA Packet Bearer >

    37) [WCDMA] < Disconnect (End) the voice call >

    38) What will happen ?

 

18) [   LTE   ] RRC : Mobility From EUTRA Command

 

This is pretty complicated message. This message triggers UE switch to WCDMA and inform UE of all the radio bearer setup information to perform CS voice call (and, depending on situation, radio bearer setup for packet data as well)

Among the long list of the RRC message, probably the following two components (especially the first item (Item 0) will be the critical factors to inform UE on whether it has to do PS handover or SRVCC.

 

rab-InformationSetupList: 2 items

    Item 0

        RAB-InformationSetup-r8

            rab-Info

                rab-Identity: gsm-MAP-RAB-Identity (0)

                    gsm-MAP-RAB-Identity: 01 [bit length 8, 0000 0001 decimal value 1]

                cn-DomainIdentity: cs-domain (0)

                re-EstablishmentTimer: useT314 (0)

 

 

    Item 1

        RAB-InformationSetup-r8

            rab-Info

                rab-Identity: gsm-MAP-RAB-Identity (0)

                    gsm-MAP-RAB-Identity: 05 [bit length 8, 0000 0101 decimal value 5]

                cn-DomainIdentity: ps-domain (1)

                re-EstablishmentTimer: useT315 (1)

 

 

19) [WCDMA] RRC : HANDOVER To UTRAN Complete

 

If Handover (SRVCC) is successful, UE send Handover to Utran Complete message from WCDMA Cell.

 

31) [WCDMA] [UE -> NW] GMM : SERVICE REQUEST

 

UL-DCCH-Message

    integrityCheckInfo

        messageAuthenticationCode: 0f3ff3e9

        rrc-MessageSequenceNumber: 4

    message: uplinkDirectTransfer (27)

        uplinkDirectTransfer

            cn-DomainIdentity: ps-domain (1)

            nas-Message: 080c1005f4000000803202600036024000

            GSM A-I/F DTAP - Service Request

                Protocol Discriminator: GPRS mobility management messages

                    .... 1000 = Protocol discriminator: GPRS mobility management messages (0x08)

                    0000 .... = Skip Indicator: No indication of selected PLMN (0)

                DTAP GPRS Mobility Management Message Type: Service Request (0x0c)

                Service Type

                    0... .... = Spare bit(s): 0

                    .001 .... = Service type: Data (1)

                    .... 0... = Spare bit(s): 0

                    .... .000 = Ciphering key sequence number: 0

                Mobile Identity - TMSI/P-TMSI (0x0080)

                    Length: 5

                    1111 .... = Unused: 0x0f

                    .... 0... = Odd/even indication: Even number of identity digits

                    .... .100 = Mobile Identity Type: TMSI/P-TMSI/M-TMSI (4)

                    TMSI/P-TMSI: 0x00000080

                PDP Context Status

                    Element ID: 0x32

                    Length: 2

                    PDP Context Status

                        NSAPI 0: PDP-INACTIVE (0)

                        NSAPI 1: PDP-INACTIVE (0)

                        NSAPI 2: PDP-INACTIVE (0)

                        NSAPI 3: PDP-INACTIVE (0)

                        NSAPI 4: PDP-INACTIVE (0)

                        NSAPI 5: PDP-ACTIVE (1)

                        NSAPI 6: PDP-ACTIVE (1)

                        NSAPI 7: PDP-INACTIVE (0)

                        NSAPI 8: PDP-INACTIVE (0)

                        NSAPI 9: PDP-INACTIVE (0)

                        NSAPI 10: PDP-INACTIVE (0)

                        NSAPI 11: PDP-INACTIVE (0)

                        NSAPI 12: PDP-INACTIVE (0)

                        NSAPI 13: PDP-INACTIVE (0)

                        NSAPI 14: PDP-INACTIVE (0)

                        NSAPI 15: PDP-INACTIVE (0)

                Uplink data status

                    Element ID: 0x36

                    Length: 2

                    0... .... = NSAPI(7) uplink status:

                                  no uplink data are pending for the preserved PDP context

                                  or the PDP context is PDP-INACTIVE or is PDP-ACTIVE with

                                  a RAB already established

                    .1.. .... = NSAPI(6) uplink status: uplink data are pending

                                  for the preserved PDP context

                    ..0. .... = NSAPI(5) uplink status: no uplink data are pending

                                  for the preserved PDP context or the PDP context is

                                  PDP-INACTIVE or is PDP-ACTIVE with a RAB already established

                    ...0 0000 = Spare bit(s): 0

                    0... .... = NSAPI(15) uplink status: no uplink data are pending

                                  for the preserved PDP context or the PDP context is

                                  PDP-INACTIVE or is PDP-ACTIVE with a RAB already established

                    .0.. .... = NSAPI(14) uplink status: no uplink data are pending

                                  for the preserved PDP context or the PDP context is

                                  PDP-INACTIVE or is PDP-ACTIVE with a RAB already established

                    ..0. .... = NSAPI(13) uplink status: no uplink data are pending

                                  for the preserved PDP context or the PDP context is

                                  PDP-INACTIVE or is PDP-ACTIVE with a RAB already established

                    ...0 .... = NSAPI(12) uplink status: no uplink data are pending

                                  for the preserved PDP context or the PDP context is

                                  PDP-INACTIVE or is PDP-ACTIVE with a RAB already established

                    .... 0... = NSAPI(11) uplink status: no uplink data are pending

                                  for the preserved PDP context or the PDP context is

                                  PDP-INACTIVE or is PDP-ACTIVE with a RAB already established

                    .... .0.. = NSAPI(10) uplink status: no uplink data are pending

                                  for the preserved PDP context or the PDP context is

                                  PDP-INACTIVE or is PDP-ACTIVE with a RAB already established

                    .... ..0. = NSAPI(9) uplink status: no uplink data are pending

                                  for the preserved PDP context or the PDP context is

                                  PDP-INACTIVE or is PDP-ACTIVE with a RAB already established

                    .... ...0 = NSAPI(8) uplink status: no uplink data are pending

                                  for the preserved PDP context or the PDP context is

                                  PDP-INACTIVE or is PDP-ACTIVE with a RAB already established

 

 

32) [WCDMA] [UE <- NW] GMM : SERVICE ACCEPT

 

DL-DCCH-Message

    integrityCheckInfo

        messageAuthenticationCode: 20175482

        rrc-MessageSequenceNumber: 3

    message: downlinkDirectTransfer (5)

        downlinkDirectTransfer: r3 (0)

            r3

                downlinkDirectTransfer-r3

                    rrc-TransactionIdentifier: 0

                    cn-DomainIdentity: ps-domain (1)

                    nas-Message: 080d

                    GSM A-I/F DTAP - Service Accept

                        Protocol Discriminator: GPRS mobility management messages

                            .... 1000 = Protocol discriminator:

                                       GPRS mobility management messages (0x08)

                            0000 .... = Skip Indicator: No indication of selected PLMN (0)

                        DTAP GPRS Mobility Management Message Type: Service Accept (0x0d)

 

 

33) [WCDMA] [UE <- NW] RRC : Radio Bearer Setup

 

 

34) [WCDMA] [UE -> NW] GMM : Radio Bearer Setup Complete

 

 

38) What would happen ?

 

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.

 

 

< Protocol Sequence Example 2 - a SRVCC/Rel 10>

 

    1) [   LTE   ]  RRC : PRACH Preamble

    2) [   LTE   ]  RRC : RACH Response

    3) [   LTE   ]  RRC : RRC Connection Request

    9) [   LTE   ]  RRC : RRC Connection Setup

    4) [   LTE   ]  RRC : RRC Connection Setup Complete

                      + NAS : Attach Request + ESM : PDN Connectivity Request

    5) [   LTE   ]  RRC : DL Information Transfer + NAS : Authentication Request

    6) [   LTE   ]  RRC : UL Information Transfer + NAS : Authentication Response

    7) [   LTE   ]  RRC : DL Information Transfer + NAS : Security Mode Command

    8) [   LTE   ]  RRC : UL Information Transfer + NAS : Security Mode Complete

    9) [   LTE   ]  RRC : Security M ode Command

    10) [   LTE   ]  RRC : Security Mode Complete

    11) [   LTE   ]  RRC : UE Capability Enquiry

    12) [   LTE   ]  RRC : UE Capability Information

    13) [   LTE   ]  RRC : RRC Connection Reconfiguration

                        + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req

    14) [   LTE   ] RRC : RRC Connection Reconfiguration Complete

                        + NAS : Attach Complete + NAS : Activate Default EPS Bearer Context Accept

    15) [   LTE   ] < UE Perform IMS Registration >

    16) [   LTE   ] < Initiate a VoLTE Call  >

    17) [   LTE   ] SIP : INVITE

    18) [   LTE   ] SIP : 100 Trying

    19) [   LTE   ] SIP : 183 Session Progress // This is the trigger for NW to establish Dedicated EPS Bearer

    20) [   LTE   ] SIP : PRACK

    21) [   LTE   ] SIP : 200 OK

    22) [   LTE   ] < Dedicated EPS Bearer Setup >

    23) [   LTE   ] SIP : UPDATE

    24) [   LTE   ] SIP : 200 OK

    25) [   LTE   ] SIP : 180 Ringing  // This is the trigger for NW to initiate SRVCC

    26) [   LTE   ] SIP : PRACH

    27) [   LTE   ] SIP : 200 OK

    28) [   LTE   ] RRC : Mobility From EUTRA Command

    29) [WCDMA] RRC : HANDOVER To UTRAN Complete

    30) [WCDMA] RRC : Security Mode Command

    31) [WCDMA] RRC : Security Mode Complete

    32) [WCDMA] RRC : UTRAN Mobility Information

    33) [WCDMA] RRC : UTRAN Mobility Information Confirm

    34) [WCDMA] GMM : Routing Area Update Request

    35) [WCDMA] GMM : Authentication And Ciphering Request

    36) [WCDMA] GMM : Authentication And Ciphering Response

    37) [WCDMA] RRC : Security Mode Command

    38) [WCDMA] RRC : Security Mode Complete

    39) [WCDMA] GMM : Routing Area Update Accept

    40) [WCDMA] GMM : Routing Area Update Complete

    41) [WCDMA] [UE -> NW] CC : CONNECT

    42) [WCDMA] [UE <- NW] CC : CONNECT ACKNOWLEDGE

    43) [WCDMA] < Voice Call would redirected from LTE to WCDMA CS/AMR Bearer >

    44) [WCDMA] < Any non-voice IP traffic may redirected to WCDMA Packet Bearer >

    45) [WCDMA] < Disconnect (End) the voice call >

    46) What will happen ?

 

 

41) [WCDMA] [UE -> NW] CC : CONNECT

 

UL-DCCH-Message

    integrityCheckInfo

        messageAuthenticationCode: a336349c

        rrc-MessageSequenceNumber: 4

    message: uplinkDirectTransfer (27)

        uplinkDirectTransfer

            cn-DomainIdentity: cs-domain (0)

            nas-Message: 8307

            GSM A-I/F DTAP - Connect

                Protocol Discriminator: Call Control; call related SS messages

                    .... 0011 = Protocol discriminator: Call Control;

                                                        call related SS messages (0x03)

                    1... .... = TI flag: allocated by receiver

                    .000 .... = TIO: 0

                00.. .... = Sequence number: 0

                ..00 0111 = DTAP Call Control Message Type: Connect (0x07)

 

 

42) [WCDMA] [UE <- NW] CC : CONNECT ACKNOWLEDGE

 

DL-DCCH-Message

    integrityCheckInfo

        messageAuthenticationCode: 650cef87

        rrc-MessageSequenceNumber: 3

    message: downlinkDirectTransfer (5)

        downlinkDirectTransfer: r3 (0)

            r3

                downlinkDirectTransfer-r3

                    rrc-TransactionIdentifier: 0

                    cn-DomainIdentity: cs-domain (0)

                    nas-Message: 030f

                    GSM A-I/F DTAP - Connect Acknowledge

                        Protocol Discriminator: Call Control; call related SS messages

                            .... 0011 = Protocol discriminator: Call Control;

                                                     call related SS messages (0x03)

                            0... .... = TI flag: allocated by sender

                            .000 .... = TIO: 0

                        00.. .... = Sequence number: 0

                        ..00 1111 = DTAP Call Control Message Type: Connect Acknowledge (0x0f)