Contents

 Introduction
 Volte
 IMS Registration
 Default and Dedicated bearers
 SRVCC Support
 SRVCC HO Initiation
 Types of SRVCC
 Call Flow- Success case, Notification procedure & Fail case
 Log Analysis
Introduction
Voice Support Options for LTE Networks

 CSFB : Transfer voice using an already existing access technology that supports the CS domain (CS Fallback (CSFB)). This
requires the device to leave LTE when a voice call is initiated and move to 2G/3G to support voice

 SRVCC: Single Radio Voice call Continuity (SRVCC) provides the ability to transition a voice call from VoIP/IMS domain to
the legacy circuit switch domain. Preferable in scenarios where E-UTRAN coverage will be limited and available only in
scattered strategic locations

Solution Pros Cons

Volte+SRVCC Uses Volte when available, Support for Requires Ubiquitous coverage
simultaneous voice and data, Requires IMS deployment
Less Call set up delay

CSFB Uses the existing CS technology, does Simultaneous voice and data possible
not need IMS only on 2G/3G , Call setup latency.
Lower data rates.
Why Voice over LTE (VoLTE)
 LTE networks are IP-only networks. Circuit switched connections are not supported. Ideally, both voice calls and data should
be carried on the same LTE network, just like in 2G/3G systems.
 Supporting voice on an IP-only LTE network => VOIP calls on LTE, or simply VoLTE
 VoLTE is an advantage to utilize the full potential of LTE and improve customer experience. LTE is designed to support high
quality voice efficiently.

For VoIP calls to be supported on LTE:

 IMS needs to be deployed and supported in the Operator Core Network and on the device
 End-to-end QoS needs to be supported
 Dedicated bearers (with QCI=1) are needed to transport PS voice

ATTACH ACCEPT:
 The EPS Network Feature Support IE presence indicates that IMS voice over PS (IMSVoPS bit set to 1)
IMS Registration
 Once the Network sends Attach complete, (assuming both UE and NW support IMS) ,UE will do IMS registration.
 IMS Registration can be done in two ways. 1) Through NV items 2) Through SIM CARD
 SIP is used to create, modify, and terminate a session within IMS. The "objects" addressed by SIP are users at hosts, identified by a SIP URL. The
SIP URL takes a form similar to a mailto or telnet URL, i.e., user@host. The user part is a user name or a telephone number. The host part is
either a domain name or a numeric network address. Here, the user name and host name will be given through either NV’s or hardcoded in SIM.
 Session Description Protocol is utilized within SIP to enable the characteristics of a session and the associated media to be specified.

Packet Switch IMS Core Network

UE -1 Domain

Power

PS Attach

Establish PDP context

REGISTER

401 Unauthorised

REGISTER

200 OK
Volte Session establishment procedure
 To make a Volte call, UE needs to go through Volte Session establishment procedure (assuming IMS registration successful).
Network will bring up dedicated bearer (GBR bearer) and UE will negotiate for particular QOS on this dedicated bearer. A
dedicated bearer will be established for Volte call once the negotiation is done. Search String: event_sip

UE - 1 IMS Core Network UE - 2

Invite (O1) Invite (O1)

180 Ringing (A1) 180 Ringing (A1)

PRACK (180) PRACK (180)

200 OK (PRACK) 200 OK (PRACK)

200 Ok (INVITE) 200 Ok (INVITE)

ACK ACK
Default and Dedicated bearers
 Both default and dedicated bearers share the same IP address and have the same APN.
 The dedicated bearer has the filter information which can be either DL or UL filter (TCP /UDP/ICMP
based). Whenever the incoming and outgoing data matches the filter, the network/UE will send the data
over dedicated bearer otherwise it will go through default bearer.
 For Volte, the dedicated bearer is brought up over the IMS bearer. It has QCI of 1. This ensures that delay is
minimum and NW also guarantees a bit rate ( GBR bearer).
 GBR bearers have minimum and maximum bit rate values for which dedicated transmission resources are
allocated (QCI 1-4). Non-GBR bearers do not guarantee fixed network resources and fixed data rate (to
support the desired codec bit rate for VoLTE) (QCI 5-8)
 Since VOIP packets are UDP packets (to further reduce delay on PS domain), the dedicated bearer has a UDP
filter to ensure all voice packets go over it so that voice packets experience minimum delay and are
prioritized over other data.
SRVCC
SRVCC Support
 As a part of Attach Request the UE will let the network know that whether its SRVCC capable or
not through the IE SRVCC to GERAN/UTRAN capability.
 In addition to this, it indicates Classmark 2 (if GERAN or UTRAN access or both are supported)
and supported Codecs IE (if GERAN or UTRAN access or both are supported)
 UE indicates support for SRVCC by enabling feature group indicators 8 and 27 in UE capability
transfer
8th bit –support for LTE -> UMTS PS HO
27th bit – support for LTE -> UMTS SRVCC
 If network indicates support for voice over IMS, this means that SRVCC is supported. There is no
other indication for the UE to know if SRVCC is supported
SRVCC HO Initiation
 Like any other IRAT procedure, NW can configure gaps/measurements to initiate
SRVCC
 E-UTRAN configures the RATs to be measured by UE by allocating Measurement Gaps
 NW can configure either B1/B2 ( support indicated by UE as part of cap).
 Blind HO (i.e., HO without measurement reports from UE) is possible.
 To Trigger SRVCC the following conditions should be satisfied
 NW and UE should be SRVCC capable
 UE should send measurement report (optional, NW can also do blind SRVCC)
 Bearer with QC1 should be up (this is the only way for the NW to know that Volte call is up
on LTE, otherwise NW might end up doing PSHO/redirection)
Types of SRVCC
 SRVCC to UTRAN without PS Handover/ CS only SRVCC
 In this case the data calls are not transferred to UTRAN PS domain via handover.
 UE shall re-establish the PS bearers after performing routing area update after successful
handover to the target cell

 SRVCC to UTRAN with PS Handover / CS + PS SRVCC

 In this case both data and voice bearers are mapped as part of handover
 Data should continue seamlessly after handover (no need to reestablish PS bearers separately)
Derivation of CS keys upon handover
 UE shall derive a confidentiality key CKSRVCC, and an integrity key IKSRVCC from
KASME of the current EPS security context and the selected NAS downlink COUNT
with the help of a one-way key derivation function KDF.
 The UE shall use the received 4 LSB of the selected NAS downlink COUNT(included
in HO command) and its stored NAS downlink COUNT to estimate the NAS downlink
COUNT selected by the MME.
 The UE shall replace all the stored UTRAN CS key parameters CK, IK, KSI, if any, with
CKSRVCC, IKSRVCC, and eKSI in both ME and USIM.
 UE shall revert back to EUTRAN security context in case of SRVCC failure.
SRVCC from EUTRAN to UTRAN – CS
only
SRVCC from EUTRAN to UTRAN – CS+PS
 SRVCC From EUTRAN to UTRAN –
Notification Procedure
Source Source Target Target IMS
UE MGW
EUTRAN MME MSC BSS (SCC AS)
1. Measurement
reports

2. Decision for HO
3. Handover
Required
4. Bearer splitting

5. PS to CS Req
6. Perp HO Req

7. HO Request/ACK

8. Prep HO Resp

9. Establish
circuit
10. Initiation of Session Transfer (STN-SR)

11. Session transfer

and update remote end

12. Handover
cancel
13. PS to CS cancel
notification

14. PS to CS
Cancel ACK
(SCC started)
15. Notification

16. Re-invite
 SRVCC from EUTRAN to UTRAN –
Failure Scenario
Source Source Target Target IMS
UE MGW
EUTRAN MME MSC BSS (SCC AS)
1. Measurement
reports

2. Decision for HO
3. Handover
Required
4. Bearer splitting

5. PS to CS Req
6. Perp HO Req

7. HO Request/ACK

8. Prep HO Resp

9. Establish
circuit
10. Initiation of Session Transfer (STN-SR)

11. Session transfer

and update remote end

12. PS to SC Resp
13. Handover
Command

14. HO failed

15. Re-invite
Log Analysis
2012 Aug 23 17:38:20.395 [00] 0xB0ED LTE NAS EMM Plain OTA Outgoing Message -- Attach request Msg
pkt_version = 1 (0x1)
rel_number = 9 (0x9)
prot_disc = 7 (0x7) (EPS mobility management messages)
msg_type = 65 (0x41) (Attach request)
lte_emm_msg
emm_attach_request
tsc = 0 (0x0) (cached sec context)
nas_key_set_id = 7 (0x7)
att_type = 2 (0x2) (combined EPS/IMSI attach)
PS inter-RAT HO from GERAN to UTRAN Iu mode capability = 0 (0x0)
PS inter-RAT HO from GERAN to E-UTRAN S1 mode capability = 0 (0x0)
EMM Combined procedures Capability = 1 (0x1)
ISR support = 1 (0x1)
SRVCC to GERAN/UTRAN capability = 1 (0x1)
ms_class_mark2_incl = 1 (0x1)
ms_class_mark2
ms_class_mark3_incl = 0 (0x0)
supp_codecs_incl = 1 (0x1)
Log Analysis
supp_codecs
num_codecs = 2 (0x2)
codecs[0]
sysid = 4 (0x4)  UMTS
length = 2 (0x2)
bitmap[0] = 96 (0x60)
bitmap[1] = 4 (0x4)
codecs[1]
sysid = 0 (0x0)  GSM
length = 2 (0x2)
bitmap[0] = 31 (0x1f)
bitmap[1] = 2 (0x2)
add_update_type_incl = 0 (0x0)
voice_domain_pref_incl = 1 (0x1)
voice_domain_pref
length = 1 (0x1)
UE_usage_setting = 0 (0x0) (Voice centric)
voice_domain_pref_for_EUTRAN = 3 (0x3) (IMS PS Voice preferred, CS Voice as secondary)
dev_properties_incl = 0 (0x0)
old_guti_incl = 1 (0x1)
old_guti
guti_type = 0 (0x0) (Native GUTI)
 Attach Accept Log analysis
2012 Oct 17 22:47:06.296 [00] 0xB0EC LTE NAS EMM Plain OTA Incoming Message -- Attach accept Msg
eps_netwk_feature_support_incl = 1 (0x1)
eps_netwk_feature_support
length = 1 (0x1)
IMSVoPS = 1 (0x1) (IMS Vo PS Session in S1 Mode supported)

2012 Oct 17 22:47:06.296 [00] 0xB0E2 LTE NAS ESM Plain OTA Incoming Message -- Activate default EPS bearer context request Msg
msg_type = 193 (0xc1) (Activate default EPS bearer context request)
lte_esm_msg
act_def_eps_bearer_context_req
eps_qos
qci = 8 (0x8) (QC8)
guar_bitrate_uplink = 86 (0x56) (240 kbps)
guar_bitrate_downlink = 86 (0x56) (240 kbps)

2012 Oct 17 22:47:06.300 [00] 0xB0E2 LTE NAS ESM Plain OTA Incoming Message -- Activate dedicated EPS bearer context request Msg

act_dedicated_eps_bearer_context_req
eps_bearer_id = 5 (0x5) (EPS bearer identity value 5)
eps_qos
qci = 1 (0x1) (QC1)
guaranteed_bit_rate_ul = 134 (0x86) (960 kbps)
guaranteed_bit_rate_dl = 134 (0x86) (960 kbps)
num_packet_filters = 1 (0x1)
rec[0]
pkt_filter_dir = 3 (0x3) (unknown)
pkt_filter_id = 11 (0xb)
eval_prec = 254 (0xfe)
filter_len = 7 (0x7)
num_components = 2 (0x2)
components[0]
component_type_id = 48 (0x30) (prot Id/Next header)
prot_id_or_next_header = 6 (0x6)
components[1]
component_type_id = 65 (0x41) (local port range)
port_low_limit = 5001 (0x1389)
port_high_limit = 5002 (0x138a)
Log Analysis
17:44:26.164 [00] 0xB0C0 LTE RRC OTA Packet -- UL_DCCH
PktVersion = 2 RRC Release Number.Major.minor = 9.10.0 Radio Bearer ID = 1, Physical Cell ID = 495
Freq = 5790 SysFrameNum = N/A, SubFrameNum = 0 PDU Number = UL_DCCH Message,Msg Length = 161
Interpreted PDU:
value UL-DCCH-Message ::=
message c1 : ueCapabilityInformation :
featureGroupIndicators '01111111 01001111 11111110 10111000'B, 8th and 27th bits should be set to 1
interRAT-Parameters
{ utraFDD
{ supportedBandListUTRA-FDD
{
bandI, bandII, bandVIII
}
},
geran
{ supportedBandListGERAN
{
gsm1800
},
interRAT-PS-HO-ToGERAN FALSE
}
Log Analysis – CS only SRVCC
17:44:26.219 [00] 0xB0C0 LTE RRC OTA Packet -- DL_DCCH
RRC Release Number.Major.minor = 9.10.0 Radio Bearer ID = 1, Physical Cell ID = 495
Freq = 5790 SysFrameNum = N/A, SubFrameNum = 0
PDU Number = DL_DCCH Message, Msg Length = 270
value DL-DCCH-Message ::=
{
message c1 : mobilityFromEUTRACommand :
{
rrc-TransactionIdentifier 3,
criticalExtensions c1 : mobilityFromEUTRACommand-r8 :
cs-FallbackIndicator FALSE,
purpose handover :

targetRAT-Type utra ,
Interpreted PDU:
value HandoverToUTRANCommand ::= criticalExtensions : criticalExtensions : criticalExtensions : criticalExtensions : criticalExtensions :
r8 :
{handoverToUTRANCommand-r8
srb-InformationSetupList
rb-Identity 1,
Log Analysis
rb-Identity 2,
rb-Identity 3,
rb-Identity 4,
rb-Identity 5,
rb-Identity 6,
rb-Identity 7,
{

}
frequencyInfo
{
modeSpecificInfo fdd :
{
uarfcn-DL 9830
}
}
},
maxAllowedUL-TX-Power 24
}
}
CS+PS SRVCC
Along with the above 7 radio bearers, there will be an extra radio bearer
information which is for the data bearer in case of CS+PS SRVCC

 rab-Info
{
rab-Identity gsm-MAP-RAB-Identity : '00000111'B,
cn-DomainIdentity ps-domain,
re-EstablishmentTimer useT315
},
rb-InformationSetupList
{
rb-Identity 16,
 SRVCC Protocol Architecture Control Signaling Protocol
Stack

Circuit Switched Connection management

Packet Switched
(CM)

EPS Session Management

(ESM)

Session
Call Control Notification
Non- Management
(CC) procedure
Access (SM)
SRVCC
Stratum
completed
MM connection establishment
Due to SRVCC handover

GPRS Mobility
SRVCC EPS Mobility
Mobility Management Management (GMM)
completed Management (EMM)
(MM)

SRVCC completed
LTE
UMTS
RRC
RRC HO command
PDCP
Access
RLC Channel
Stratum
RLC measurements

MAC
MAC
Physical Layer (L1)
Physical Layer (L1)
22:47:38.643 LTE RRC/Medium/CFG lte_rrc_config.c 02450 Mobility from EUTRA Message received from Message Handler
22:47:38.662 WCDMA RRC/High rrciho.c 07133 LTOW_PSHO:Rcvd HO To UTRAN from EUTRAN
MSG [03005/02] WCDMA RRC/High 22:47:38.688 rrcllcpcie.c 16375 Freq 9830 in PCS band
22:47:38.776 NAS MM/High mmcoord.c 08129 MM: received RRC_ACTIVATION_IND activating, enter i-RAT from
LTE to W/T
22:47:38.776 NAS MM/High mm_multimode_handler.c 00505 EMM: received MM_AS_LTOW_SRVCC_CS_HANDOVER

22:47:38.779 NAS SM/High esm_utils.c 00788 ESM: ESM sent MM_CM_ACT_DRB_RELEASED_IND

22:47:38.781 Call Manager/High cmwcall.c 11168 RXD: CM_NAS_SRVCC_HANDOVER_COMPLETE_IND
22:47:38.784 Data Services/High qmi_voice_cm_if.c 17249 CALL EVENT RECEIVED from CM : id = 65641, name =
CM_CALL_EVENT_SRVCC_COMPLETE_IND
22:47:38.784 Data Services/Medium qmi_voice_cm_if.c 12317 SRVCC call mode change from L->W/G voice call (id: 2)
MSG [00051/02] IMS/High 22:47:38.787 qipcallh.c 13861 SRVCC notification from Handoff type: 1
MSG [00051/02] IMS/High 22:47:38.787 qipcallh.c 16902 Active call. Indicate end cause as SRVCC
OTA LOG [0x412F/001/004]DCCH UL/Handover To UTRAN Complete 22:47:38.793 Radio Bearer ID: 2, Length: 7
22:47:38.792 NAS SM/High esmtask.c 01420 ESM: RAT change - Abort pending ESM procedure
22:47:38.794 NAS MN/High mn_process_cnm_cc_msgs.c 03394 Handover completed, MVS enabled
Voice call status after SRVCC
MsgType = QMI_VOICE_ALL_CALL_STATUS_IND
MsgLength = 30
Tlvs[0] {
Type = 1
Length = 8
CallInfo Tlv {
NumberInstances = 1
Instance[0] {
CallId = 1
CallState = CONVERSATION
CallType = VOICE
Direction = MO: Mobile Originated Call
Mode = UMTS
IsEmpty = FALSE
Als = LINE1(default)
}
}
}
Questions?

https://support.cdmatech.com