|
IMS |
||||||||||||||||||||||
|
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).
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.
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.
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 >
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
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
< 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 >
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)
|
||||||||||||||||||||||
