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).
Let's follow SRVCC in the order an engineer usually meets it. The page first shows the idea and the releases that extended it. It then looks at how a UE shows SRVCC support, and at how the network decides to start SRVCC. Two protocol sequences with captured messages close the page. The first is a basic SRVCC during an active call, and the second is an aSRVCC during the alerting phase.
- Overall SRVCC Mechanism
- SRVCC Evolution
- UE Capability Information for SRVCC : LTE RRC
- How does the network decide to start SRVCC ?
- Protocol Sequence Example 1 - Basic SRVCC/Rel 8
- Protocol Sequence Example 2 - a SRVCC/Rel 10
- Reference
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 moves one voice call across domains : the call starts as VoIP over IMS in LTE and continues as a CS call in UTRAN or GERAN.The UE has a single radio : it cannot hold the LTE and the WCDMA connection at the same time, so the transfer happens inside one handover.Other packet traffic can move in parallel : in Case 2 of the diagram, the non-voice bearers go to the WCDMA packet domain together with the CS call.
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/GERAN |
|
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) |
|
bSRVCC |
SRVCC at Pre-Alerting Phase |
|
|
vSRVCC |
Rel 11 |
Video SRVCC |
|
rSRVCC |
Rel 11 |
SRVCC from UTRAN/GRAN to E-UTRAN |
Let's read the table in two groups. Most rows keep the direction of basic SRVCC, from PS voice in E-UTRAN to CS voice in UTRAN or GERAN. They change the call state or the media that can move. The last row reverses the direction.
aSRVCC and bSRVCC move a call that the user has not answered yet. 23.237 v19.0.0 defines the access transfer for an incoming or an outgoing call in the pre-alerting state or the alerting phase. Pre-alerting is the state where the UE can receive early media in the early dialogue phase. For an outgoing call, this is the time before the 180 Ringing arrives. So bSRVCC covers the call before the 180 Ringing, and aSRVCC covers it after.
vSRVCC moves a video call to UTRAN CS. In 23.216 v19.0.0, the MSC Server requests a BS30 bearer in UTRAN, which is a 64 kbps bearer for multimedia. If the target cell is GERAN, only the voice part of the call moves, with ordinary SRVCC. The last row, rSRVCC, is called CS to PS SRVCC in 23.216. It covers SRVCC from UTRAN to E-UTRAN, and from GERAN to UTRAN or E-UTRAN.
The list has grown since the table was written. 23.216 v19.0.0 adds 5G-SRVCC, which moves the voice part of an IMS session from NG-RAN to UTRAN. The AMF hands the request to an MME_SRVCC, and the MME_SRVCC then runs the SRVCC procedure towards the MSC Server over Sv. The IMS side also gained the ATCF, defined in 23.237. The ATCF sits in the serving network and anchors the media in an ATGW. An access transfer then updates only the media path to the ATGW, without updating the remote leg.
Most variants change the call state, not the direction : aSRVCC and bSRVCC transfer a call that is still ringing or still being set up.vSRVCC needs a multimedia CS bearer : the MSC Server asks UTRAN for BS30, and a GERAN target gets voice only.rSRVCC is CS to PS SRVCC : it brings a CS call back into IMS over E-UTRAN or UTRAN HSPA.5G-SRVCC reuses the E-UTRAN procedure : the AMF passes the handover to an MME_SRVCC, which runs the E-UTRAN procedure towards the MSC Server.
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.
Look closely at the field names in the listing above. They belong to IRAT-ParametersUTRA-v9c0, and 36.331 v19.3.0 still defines this IE in the same form. Each srvcc-FromUTRA field indicates SRVCC handover from UTRA PS HS to UTRA CS or to GERAN CS. In other words, these fields describe an SRVCC that starts in UTRAN HSPA, not in E-UTRAN. The fields voiceOverPS-HS-UTRA-FDD-r9 and voiceOverPS-HS-UTRA-TDD128-r9 say whether the UE supports voice over UTRA PS HS at all.
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.
The rows in the image come from Table B.1-1 in Annex B of 36.331. The current release keeps them, with small changes in wording. Bits 3 and 7 now refer to VoLTE, MCPTT, or both, and bit 9 now excludes category M1 and M2 UEs. The same table carries other SR-VCC rows that the image does not show. Bit 27 is E-UTRA RRC_CONNECTED to UTRA CELL_DCH CS handover. The UE can set it only when bit 8, the PS handover to UTRA, is also set and the UE supports SR-VCC from E-UTRA. Bit 40 is the same CS handover to UTRA TDD, for a UE that supports both UTRA FDD and UTRA TDD. Bit 11 is the handover to CDMA2000 1xRTT CS Active, which is also related to SR-VCC.
The radio capability is not the only indication. The UE also signals SRVCC support in NAS. The MS network capability IE of 24.008 v20.0.0 has a bit named SRVCC to GERAN/UTRAN capability. When the UE sets it to 1, SRVCC from UTRAN HSPA or E-UTRAN to GERAN/UTRAN is supported. The next section shows how the MME uses it.
The IRAT-ParametersUTRA-v9c0 fields are about UTRAN HSPA : they describe SRVCC from UTRA PS HS, not from E-UTRAN.FGI bits 27, 9 and 40 are the E-UTRA SR-VCC rows : they cover the CS handover to UTRA FDD, GERAN and UTRA TDD.NAS carries its own SRVCC bit : the MS network capability tells the MME that the UE supports SRVCC.
How does the network decide to start SRVCC ?
Example 1 below asks how the network knows that it must start SRVCC instead of a PS handover. It also asks how the UE knows that its IMS call becomes a CS call. 23.216 v19.0.0 answers both questions for the network side. The decision is prepared at attach, and the eNB takes it at handover time.
The preparation happens before any call. The UE signals its SRVCC capability in the MS network capability. The HSS sends the STN-SR and the C-MSISDN to the MME as part of the subscription data. If the STN-SR is present, the UE is SRVCC subscribed. The MME then includes the "SRVCC operation possible" indication in the S1-AP Initial Context Setup Request. This indication means that both the UE and the MME support SRVCC, and that the subscription includes the STN-SR and the C-MSISDN. The eNB can use it, together with an established QCI 1 bearer, to choose the neighbour cells that the UE measures.
The handover follows clause 6.2.2.2 of 23.216. The UE sends measurement reports. Based on them, the source E-UTRAN decides to trigger an SRVCC handover. It sends Handover Required to the source MME with an SRVCC HO Indication. The MME finds the voice bearer by its QCI 1 and splits it from all other PS bearers. It sends the voice bearer to the MSC Server in an SRVCC PS to CS Request over Sv. In parallel, it relocates the other bearers to the target SGSN as a normal PS handover.
The MSC Server prepares the CS handover in the target RNS or BSS. It also starts the session transfer towards IMS with the STN-SR. During the session transfer, the remote end is updated with the SDP of the CS access leg. When both relocations are ready, the MME sends Handover Command to the eNB. The eNB then sends the Mobility From EUTRA Command to the UE.
Compare this with the flow diagram in Overall SRVCC Mechanism. The diagram draws the decision making in the LTE core network and IMS. In 23.216, the eNB takes the handover decision, and the MME splits the bearers. The diagram is a big picture, as its own text says, so read its Decision Making box as the whole preparation between the MME, the MSC Server and IMS.
On the UE side, the Mobility From EUTRA Command answers the question. The UTRAN handover command inside it lists a RAB with cn-DomainIdentity cs-domain, and the capture in Example 1 shows this. The UE then continues the voice as a CS call in UTRAN. The session transfer in IMS is done by the MSC Server with the STN-SR, not by the UE.
The decision is prepared at attach : the MME sets SRVCC operation possible only when the UE, the MME and the subscription all allow SRVCC.The eNB triggers SRVCC : it adds the SRVCC HO Indication to Handover Required, based on the UE measurement reports.The MME splits the bearers by QCI : the QCI 1 voice bearer goes to the MSC Server, and the rest goes to the SGSN.The UE learns it from the handover command : a RAB in the CS domain tells the UE that its voice continues as a CS call.
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)
The core network side is specified in 23.216, and the section above walks through it. The captures below show what the UE itself sees.
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] RRC : 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.
Capture : rab-InformationSetupList, an excerpt of the HandoverToUTRANCommand inside Mobility From EUTRA Command, shown as a decoder tree. The values come from one recorded exchange and not from the specification.
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)
The two RABs carry different domains. Item 0 is the CS RAB, and the full message example maps it to three radio bearers, rb-Identity 5, 6 and 7, all in RLC TM. That is the usual layout of an AMR speech bearer in UTRA. Item 1 is the PS RAB, with RAB identity 5, and one radio bearer, rb-Identity 8. For the PS domain, the RAB identity is the NSAPI, so this RAB belongs to NSAPI 5. The voice moves to CS, and one PDP context keeps its radio bearer in the same handover.
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
Capture : GMM SERVICE REQUEST in uplinkDirectTransfer, shown as a decoder tree. The values come from one recorded exchange and not from the specification.
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
Why does the UE send a Service Request right after the handover ? The PDP Context Status shows NSAPI 5 and NSAPI 6 as active. NSAPI 5 already has its RAB from the handover command. NSAPI 6 does not, and the Uplink data status marks pending uplink data for NSAPI 6 only. So the UE asks the network for a radio bearer for that context, with service type Data.
Which bearer is NSAPI 6 ? With the Case 2 layout assumed above, the UE has two EPS bearers, the default bearer for SIP signalling and the dedicated bearer for voice. If NSAPI 6 is the voice bearer, a live network would not restore it. In 23.216, the source MME deactivates the voice bearer once the CS handover is complete. This capture comes from one test setup, and the sequence itself marks step 31 as optional.
32) [WCDMA] [UE <- NW] GMM : SERVICE ACCEPT
Capture : GMM SERVICE ACCEPT in downlinkDirectTransfer, shown as a decoder tree. The values come from one recorded exchange and not from the specification.
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] RRC : Radio Bearer Setup Complete
From the beginning of SRVCC (or CSFB 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.
One part of this is specified. 25.331 v19.0.1 lets the RRC CONNECTION RELEASE message carry the IE "E-UTRA target info", and this IE exists since Release 8. With it, the UE tries to camp on the listed E-UTRA frequencies after the release. This is the tool behind Case 4. The specification does not say which case a network should use, so the choice stays with the operator.
The CS RAB is the SRVCC marker : the Mobility From EUTRA Command carries a RAB with cn-DomainIdentity cs-domain for the voice.Not every PDP context gets a RAB in the handover : the UE sends a Service Request for the context that still has pending data.Returning to LTE is an operator choice : 25.331 offers redirection to E-UTRA, but no specification requires it.
Protocol Sequence Example 2 - a SRVCC/Rel 10
This example is an aSRVCC. The call is transferred while it is still ringing, before the user answers. The two captures show that the UE is the called party. After the handover, the UE sends CC CONNECT in the CS domain when the user answers, and the network answers with CONNECT ACKNOWLEDGE.
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 : PRACK
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
Capture : CC CONNECT in uplinkDirectTransfer, shown as a decoder tree. The values come from one recorded exchange and not from the specification.
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)
23.237 v19.0.0 describes this case for an incoming call in the pre-alerting or alerting phase. When the UE receives the handover command, it creates a CS call state from the SIP state. For a call that is alerting, that state is Call Received. The UE keeps alerting the user, and it sends the CS connect message when the user answers. The capture fits this. The TI flag is "allocated by receiver", so the network side allocated the transaction identifier, as it does for a mobile terminated call.
42) [WCDMA] [UE <- NW] CC : CONNECT ACKNOWLEDGE
Capture : CC CONNECT ACKNOWLEDGE in downlinkDirectTransfer, shown as a decoder tree. The values come from one recorded exchange and not from the specification.
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)
aSRVCC moves a call before it is answered : the 180 Ringing marks the alerting phase, and SRVCC starts from there.The answer happens in the CS domain : the UE sends CC CONNECT to the MSC, and not SIP 200 OK to IMS.The TI flag shows the call direction : allocated by receiver in the UE's CONNECT means a mobile terminated call.
Reference
- TS 23.216 v19.0.0 - Single Radio Voice Call Continuity, SRVCC; Stage 2
- TS 23.237 v19.0.0 - IP Multimedia Subsystem, IMS, Service Continuity; Stage 2
- TS 36.331 v19.3.0 - E-UTRA RRC, IRAT-ParametersUTRA-v9c0 and Annex B, Table B.1-1
- TS 24.008 v20.0.0 - Mobile radio interface Layer 3 specification, MS network capability
- TS 25.331 v19.0.1 - UTRA RRC, RRC CONNECTION RELEASE and E-UTRA target info
- TS 36.523-1 v19.3.0 - UE conformance, test cases 13.4.3.x, SRVCC