RAN2435 SRVCC from LTE and CSFB with HO

Marek Wojtyna
MBB CS Network Engineering

For internal use

1 © Nokia Siemens Networks 2013
 Introduction Table of Contents
WCDMA – LTE Interworking from WCDMA perspective

• RAN2067 LTE Interworking (RU20 On Top)

WCDMA - LTE Interworking overview
• Cell reselection from WCDMA to LTE when UE is in idle
mode, Cell_PCH or URA_PCH state in WCDMA layer.
• The UE, on operator’s preference, selects to camp on
LTE layer based on absolute layers’ priorities once
coverage is available.
• RAN2176 LTE PS Handover (RU20 On Top)
Cell_DCH RRC_CONNECTED • Seamless handover of data services to WCDMA when
leaving the LTE coverage with minimal interruption time.
• Multi-RAB handover is supported.
Cell_FACH • RAN2264 Smart LTE Handover (RU50)
• WCDMA-LTE outgoing PS handover once LTE
coverage is available (without delay of changing state to
Cell_PCH
Idle, Cell_PCH or URA_PCH).
URA_PCH • RAN2435 SRVCC from LTE and CSFB with HO (RU40)
• Single Radio Voice Call Continuity from LTE to WCDMA
allows LTE VoIP call to be handed over to WCDMA as a
normal CS voice call.
• CS Fallback support (if VoLTE call cannot be setup, for
UTRA_IDLE RRC_IDLE realization of the voice call the UE is handed over to
WCDMA for CS connection setup)
• RAN2717 Smart LTE Layering (RU40)
• Efficient mechanisms for moving active UEs to the LTE
layer (RRC Connection Release with Redirection
* Procedure selection (SRVCC or CS FB) depends on VoLTE availability in E-UTRAN command to LTE).

For internal use

2 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 Introduction Table of Contents
With and without RAN2435 SRVCC from LTE and CSFB with HO

RAN2435 RAN2435
Not activated Activated

• There are no means of continuing the VoLTE call anchored in IMS when the • This feature enables Single Radio Voice Call Continuity (SRVCC) – voice call
UE is leaving LTE coverage while WCDMA coverage is available. cointinuity between IP Multimedia Subsystem (IMS) over Packet Switched
• Voice Call drops beyond the LTE cell edge (PS) access and Circuit Switched (CS) access when UE is
trasmitting/receiving on only one of those access network at a given time.
• When UE requests the CS call and CSFB via PSHO procedure is supported
on the LTE side but not on the WCDMA side, CSFB via redirection is • All non-voice services are also handed over to WCDMA PS domain (Multi-
executed (the data call is suspended and UE is redirected to UTRAN via RRC RAB handover CS + PS support).
Connection Release) • This feature allows CSFB to be executed via PS HO instead of via
Redirection.
No means of seamless hand over of a voice call from LTE to WCDMA Seamless handovers of voice and packet calls from LTE to WCDMA

CSFB allows LTE deployment

as a data only network

Ongoing Ongoing Voice Call Continuity

VoLTE call Call Drop VoLTE call in WCDMA CS domain

For internal use

3 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 Technical details Table of Contents
What is CS Fallback and SRVCC?

Service Driven Procedure

• CSFB
• Initial LTE deployments may be established as a data-only access (voice services via PS
LTE capable UE
Conversational bearers delivered later on). This is different to WCDMA which supports both circuit switches to CS
switched and packet switched services. It naturally impacts the technical solution for how to deliver capable network to
voice to LTE users. perform voice call

• Circuit Switch Fallback is a soultion for providing voice services for multimode terminals being attached
to LTE. IMS is not a part of this solution. If voice services based on QCI=1 bearers are not supported in
LTE, a temporary inter-system switch is used to serve the user in the network where CS services are
available.

Coverage Driven Procedure

• SRVCC
• SRVCC service for LTE comes into the picture when a single radio UE accessing IMS-anchored voice
call services switches from LTE PS domain to the Circiut Switched domain (WCDMA) – while it is able Ongoing VoLTE
to transmit or receive on only one of these access networks at a given time. call; The UE leaves
LTE coverage
• Measurement gaps are needed to allow the UE to find the target layer to switch onto. In LTE the eNB
schedules measurement gap patterns and provides it via RRC dedicated signaling (this is the same
concept as "Compressed Mode„ in WCDMA).
• Implementation of two RF tranciever (for WCDMA and LTE) on UE brings practical problems: cost
issue and possible interference between the current frequency and target frequency especially when
they are close to each other.

For internal use

4 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 Technical details Table of Contents
Complexity

• SRVCC and CSFB features are complex End-to-end functionalities that require support from both Target and Source RANs (LTE and WCDMA). Support
from the Core Network is essential as well.
• For SRVCC:
• Mobile Switching Center (MSC) needs to be upgraded to support SRVCC: Sv interface with MME and functionalities to receive the HO-requests from
the MME,
• MME upgrade to Flexi NS 2.2 providing SRVCC (Rel. 9)
• NetAct OSS5.4 CD3 supporting SRVCC features.
• For CS Fallback:
• Evolved Packet Core (EPC) must support CS inter-working for mobility management and paging
• SGs interface between MME and MSC is needed
• Interworking between SGSN and MME and PDN-GW via S3/S4 interfaces (or via pre-Rel.8 Gn interface).

UTRAN Iu-ps SGSN Gn GGSN

Uu
Gb Iu-cs
UE Um GERAN A MSC
S3
Gn Sv
LTE-Uu SGs S4
Gn
E-UTRAN S1-MME MME
PDN-GW
S1-U S11
S5/S8
S-GW

For internal use

5 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 Technical details Table of Contents
Possible scenarios

• Under some conditions, user scenarios related to this feature can be divided in to two groups depending on the VoLTE availability** in
E-UTRAN:
VoLTE available LTE LTE network does not support VoLTE

• Continuity of VoLTE (QCI=1 bearers) call started in E- • Circuit Switched Fallback with ongoing PS data service
UTRAN started in E-UTRAN
• Continuity of VoLTE (QCI=1 bearers) call and PS data • Circuit Switched Fallback Emergency Call Handling (with
service started in E-UTRAN ongoing PS data service started in E-UTRAN)
• Continuity of Emergency Call started in E-UTRAN

• Customer scenarios related to this feature:

• **CS Fallback may be triggered regardles of VoLTE availability in E-UTRAN, e.g.:
• QCI=1 bearer cannot be granted to the UE due to congestion
• UE is not VoLTE capable and requests Voice service in E-UTRAN
• That is why the operator may have both CSFB and SRVCC features anabled.
• CS Fallback allows LTE deployments as data-only network
• SRVCC with PS HO enables Multi-RAB handover between LTE and WCDMA

For internal use

6 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 SRVCC from LTE and CSFB with HO Table of Contents
SRVCC procedure (coverage driven trigger)

• The DL and UL data is carried via the source eNodeB

• The UE has an ongoing VoLTE session over the IP
UE Source eNB Target NodeB Target RNC MME Core Network Multimedia Subsystem together with Packet Switched
(PS) data service (over E-UTRAN access network).
VoLTE call with PS Data Service; • SRVCC consists of the following sub-procedures:
UE sends measurement reports
to E-UTRAN • Handover Decision
• Handover Preparation
Based on trigger, the E-UTRAN
makes a decision to iniciate an • Handover Execution
Inter-technology Handover Handover decidion • Handover Completion
• The Handover Decision is made based on trigger:
• Measurement events in LTE
• A2 event – serving LTE cell signal strenght falls
a2 event b2 event
below a certain value (over the defined time
period - a2 event related timer) that triggers start
a1TimeToTriggerDeactInterMeasm
of WCDMA layer measurements

WCDMA RSCP [dBm]

-140 + threshold2a
• B2 event – target WCDMA cell signal strenght is
LTE RSRP [dBm]

-140 + threshold2Wcdma higher than trigger point and serving LTE cell
-140 + b2Threshold1Utra signal strenght is lower than trigger point (over
the defined time period - b2 event related timer).
a2TimeToTriggerActWcdmaMeas
b2TimeToTriggerUtraMeas
• Further details on handover decision, see NEI SRVCC
-115 + b2Threshold2UtraRscp to WCDMA, SRVCC to GSM LTE 872, LTE 873 by
Dariusz Tomeczko.
UE measures WCDMA
according to the list of the Handover procedure started
measurement objects

Time [s]
Hystereses equlas 0 assumed

For internal use

7 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 SRVCC from LTE and CSFB with HO Table of Contents
SRVCC procedure (coverage driven trigger)

• Handover Preparation
• This phase is started once the Source eNB sends
UE Source eNB Target NodeB Target RNC MME Core Network Handover Required message towars the Mobility
Management Entity (MME). This message contains
VoLTE call with PS Data Service; SRVCC indication and generic Source to Target
UE sends measurement reports Transparent Container.
to E-UTRAN
• SRVCC indication tells MME that the handover of a
Based on trigger, the E-UTRAN voice call is towards Circuit Switched domain.
makes a decision to iniciate an • Bearer Spliting
Inter-technology Handover Handover decidion
• The MME needs to split voice bearers from
non-voice bearers (voice bearers are assigned
S1-AP: HANDOVER REQUIRED Handover preparation QCI=1). After that the MME initiates the PS-
CS handover for split voice bearer via sending
the message towards the Mobile Switching
Bearer spliting
Center (MSC) Server.
Voice bearers (assigned QCI=1)
are splitted from non-voice ones • Data bearers are handed over according to
LTE – WCDMA PS handover (RAN2176 LTE
PS HO and LTE56: IRAT HO WCDMA)
SRVCC PS-CS Request • PS-CS Handover coordination
• The MSC Server coordinates PS-CS
Handover. It sends Prepare Handover
MSC Server coordinates PS-CS Request message to the target MSC.
Handover (SRVCC)
Data Bearers are handed over
• CS Core Network start resource allocation
according to existing mechanisms procedure on WCDMA side.

For internal use

8 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 Technical Details Table of Contents
Handover Required message

For internal use

9 © Nokia Siemens Networks 2013
 SRVCC from LTE and CSFB with HO Table of Contents
SRVCC procedure (coverage driven trigger)

• Handover Preparation cont.

• CS and PS Core Network sends RANAP:
UE Source eNB Target NodeB Target RNC MME Core Network RELOCATION REQUEST messages to the Target
RNC in order to allocate the resources. Each of these
MSC Server coordinates PS-CS
messages contains an indication of Number of Iu
Handover (SRVCC) Instances. In this case equals 2.
Data Bearers are handed over • Upon receiving first message and reading this
according to existing mechanisms number, the RNC waits for the second message. It
may happen that relocation request message from PS
RANAP: RELOCATION REQUEST from CS comes first.
• Addmision decision
RANAP: RELOCATION REQUEST from PS • RANAP: RELOCATION REQUEST message
contains UE History Information
information element. It indicates E-UTRAN as
a last visited cell. The target RNC knows that
this is an SRVCC procedure and accepts the
request only if the following conditions are
RNC satisfied:
RELOCATION • ISHO from LTE license exists
REQUEST from CS 1. Does ISHO from LTE license
Last visited Cell E- exists? Accept the • RAN2176 LTE PS HO is activated in
UTRAN Relocation Request
2. Is RAN2176 LTE PS HO activated? and start allocating target cell (parameter
Admission decision WCEL/IncomingLTEISHO set to
3. Is feature RAN2345 SRVCC from resources
LTE and CSFB with HO activated? Enabled)
• RAN2345 SRVCC from LTE and
CSFB with HO is activated in the RNC
If the answer for at least one question is NO If the answer for all question is YES (parameter RNFC/SRVCCEnabled set
RELOCATION FAILURE
to Enabled)
For internal use
10 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 SRVCC from LTE and CSFB with HO Table of Contents
SRVCC procedure (coverage driven trigger)

• Addmision decision cont.

• The cell specific admission control does the power
UE Source eNB Target NodeB Target RNC MME Core Network estimation and admission decision for the RBs.
• During SRVCC the RNC follows normal channel type
Admission Control Algorithm
selection algorithm to allocate resources for the CS
Voice:
• Allocate HSPA resources if
RNC

RELOCATION
REQUEST from
CS
Last
[Link] ISHO from LTE

HSPAQoSEnabled parameter has appropraite

visited license exists?
Cell E-UTRAN

Accept the Relocation

[Link] RAN2176 LTE PS Request and start
HO activated? Admissio allocating resources
[Link] feature RAN2345 n decision
SRVCC from LTE and
CSFB with HO
activated?
value*
RELOCATION FAILURE
If the answer for at least one question is NO
If the answer for all question is YES
• If E-DCH allocation fails, DCH allocation is
attempted directly
NBAP: RADIO LINK SETUP
• The RNC sends the NBAP: RADIO LINK SETUP to the
NodeB
• The NodeB allocates the necessary resources and
NBAP: RADIO LINK SETUP RESP.
responses with NBAP: RADIO LINK SETUP RESPONSE
• When resources in target system are allocated, the RNC
RANAP: RELOCATION REQUEST ACK to CS
sends RANAP: RELOCATION REQUEST ACK to CS and PS
Core Network
• This message contains the information about the
Complete specification of Radio Link allocated resources. Complete specification is used
and Radio Bearer is sent instead of Default configuration (GSM -> WCDMA CS
Handover case). That means, complete specification
RANAP: RELOCATION REQUEST ACK to PS about Radio Link and Radio Bearer is provided.
*The so called CS over HSPA can be allocated (RAN1689)
The PS Conversational RAB will be supported by RAN715 in RU50EP1 (according to current roadmap)
Check back-up slides for details on CS over HSPA

For internal use

11 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 SRVCC from LTE and CSFB with HO Table of Contents
SRVCC procedure (coverage driven trigger)

• The MSC Server sends SRVCC PS to CS response to the

Source MME (Target to Source transparent Container)
UE Source eNB Target NodeB Target RNC MME Core Network • The Source MME sends Handover Command to the E-
UTRAN
RANAP: RELOCATION REQUEST ACK to CS • E-UTRAN order the UE to achive uplink synchronization on
the WCDMA Uu interface
• Once the UE tunes to the new system, Handover Detection
Complete specification of Radio Link
and Radio Bearer is sent
at target UTRAN occurs. This is signalized to PS and CS
Core Networks via RANAP: Relocation Detect
message.
RANAP: RELOCATION REQUEST ACK to PS
• The UE sends RRC: HANDOVER TO TO UTRAN COMPLETE
message
SRVCC PS-CS Resp
• The RNC informs PS and CS Cores about the completion of
Handover preparation
handover via RANAP: RELOCATION COMPLETE messages
• The Target MSC sends Handover Complete message to
the MSC Server and it sends SRVCC PS to CS Complete
S1-AP: Handover Command Handover execution
Notification to the Source MME.
S1-AP: HO from E- • Source MME releases resources on E-UTRAN side.
UTRAN Command
• Meanwhile the target system performs security procedures
RANAP: RELOCATION DETECT to CS such as integrity protection.
• Eventually, the UE starts intra-frequency measurements in
RANAP: RELOCATION DETECT to PS
UTRAN.

RRC: HANDOVER TO UTRAN COMPLETE Handover completion

For internal use

12 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 SRVCC from LTE and CSFB with HO Table of Contents
SRVCC procedure (coverage driven trigger)

• The MSC Server sends SRVCC PS to CS response to the

Source MME (Target to Source transparent Container)
UE Source eNB Target NodeB Target RNC MME Core Network • The Source MME sends Handover Command to the E-
UTRAN
• E-UTRAN order the UE to achive uplink synchronization on
RRC: HANDOVER TO UTRAN COMPLETE Handover completion the WCDMA Uu interface
• Once the UE tunes to the new system, Handover Detection
RANAP: RELOCATION COMPLETE to CS
at target UTRAN occurs. This is signalized to PS and CS
Core Networks via RANAP: Relocation Detect
message.
RANAP: RELOCATION COMPLETE to PS
• The UE sends RRC: HANDOVER TO TO UTRAN COMPLETE
message
SRVCC PS-CS • The RNC informs PS and CS Cores about the completion of
Complete
handover via RANAP: RELOCATION COMPLETE messages
• The Target MSC sends Handover Complete message to
the MSC Server and it sends SRVCC PS to CS Complete
The MME releases resources
on E-UTRAN side. Notification to the Source MME.
• Source MME releases resources on E-UTRAN side.
• Meanwhile the target system performs security procedures
UTRAN performs integrity protection procedure
such as integrity protection.
• Eventually, the UE starts intra-frequency measurements in
UTRAN.
RRC: MEASUREMENT CONTROL

For internal use

13 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 SRVCC from LTE and CSFB with HO Table of Contents
CSFB with PSHO procedure (service driven trigger)

• The DL and UL data is carried via the source eNodeB

• The UE has an ongoing Packet Switched (PS) data
UE Source eNB Target NodeB Target RNC MME Core Network service (over E-UTRAN access network).
• CSFB consists of the following sub-procedures:
PS Data Service; • Relocation Decision
• Relocation Preparation
Based on trigger, the E-UTRAN
makes a decision to iniciate an • Relocation Execution
Inter-technology Handover
• Relocation Completion
Handover decidion
• The Handover Decision is made based on trigger:
• UE originated CS call or UE terminated CS call
• E-UTRAN access network cannot provide
QCI=1 PS Conversational bearer (VoLTE
b1 measurements Handover procedure started
missing; UE does not support VoLTE; Cell
b1TimeToTriggerCSFBUtraMeas congested).
• For InterRAT PS Handover to WCDMA

WCDMA RSCP [dBm]

b1ThresholdCSFBUtraRscp
(supported by RAN2176) Event B2 is used
LTE RSRP [dBm]

b1SupervisionTimer The UE send measurement (serving layer becomes worse than threshold
report as there is a least one
eNB has ordered the UE to cell on Target Cell List that and inter RAT neighbor becomes better than
perform b1 measurements and fulfills b1 criteria threshold). However LTE radio conditions are
waits b1SupervisionTimer
seconds for the report meaningless in case of CS Fallback to UTRAN
If no suitable cell is found during
b1SupervisionTimmer the CSFB as UE must leave E-UTRAN anyway (regardless
via redirection is tried of the signal strength). For this reason Event B1
Time [s] is used which consider only other RAT radio
Hystereses equlas 0 assumed
conditions.
Upon receiving measurement results eNB decides whether CS Fallback will be performed via PS HO or Redirection • Further details on handover decision, see NEI CS
– if TCL (Target Cell List) is not empty eNB will trigger CSFB via PS HO. Otherwise CSFB via Redirection will be triggered Fallback to UTRAN LTE 736 by Mateusz Raczkowiak.

For internal use

14 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 SRVCC from LTE and CSFB with HO Table of Contents
CSFB with PSHO procedure (service driven trigger)

• Handover Preparation
• This phase is started once the Source eNB sends
UE Source eNB Target NodeB Target RNC MME Core Network Handover Required message towars the Mobility
Management Entity (MME). This message contains
CSFB indication and generic Source to Target
PS Data Service;
Transparent Container.
Based on trigger, the E-UTRAN • CSFB indication is included in PS Handover Request
makes a decision to iniciate an message from the MME to the PS Core Network.
Inter-technology Handover
Handover decidion • PS Handover coordination
• The PS Core Network coordinates PS
Handover preparation
Handover and sends RANAP: RELOCATION
S1-AP: HANDOVER REQUIRED
REQUEST messages to the Target RNC in
order to allocate the resources.
PS Handover Request • Addmision decision
• RANAP: RELOCATION REQUEST message
contains UE History Information
RANAP: RELOCATION REQUEST from PS information element. It indicates E-UTRAN as
a last visited cell.
Admission Control Algorithm
• The target RNC knows that this is a CSFB
triggered handover if:
RANAP:RELOCATION REQUEST Radio
RNC

RELOCATION
REQUEST from
CS
Last

visited
[Link] ISHO from LTE
Network Layer Cause Extension IE has been
Cell E-UTRAN

Accept the Relocation

license exists? Admissio
Request and start
allocating resources
[Link] RAN2176 LTE PS
HO activated? n decision
set to value CS Fallback Triggered or Source
If the answer for at least one question is NO
If the answer for all question is YES
RNC to Target RNC Transparent Container IE
contains CSFB Information IE
RELOCATION FAILURE

For internal use

15 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 SRVCC from LTE and CSFB with HO Table of Contents
CSFB with PSHO procedure (service driven trigger)

• Addmision decision
• ISHO from LTE license exists?
UE MME
Source eNB Target NodeB Target RNC Core Network
• RAN2176 LTE PS HO is activated in target
cell (parameter WCEL/IncomingLTEISHO set
Admission Control Algorithm to Enabled)?
RNC • RAN2345 SRVCC from LTE and CSFB with
HO is activated in the RNC (parameter
RELOCATION
REQUEST from
CS
Last

visited
Cell E-UTRAN
[Link] ISHO from LTE Accept the Relocation
license exists?
[Link] RAN2176 LTE PS
HO activated?
Admissio
n decision
Request and start
allocating resources
RNFC/CSFBEnabled set to Enabled)?
• In case of CSFB, all PS RABs (RT or NRT) are always
RELOCATION FAILURE
If the answer for at least one question is NO
If the answer for all question is YES

allocated to DCH 0/0. DCH/DCH is allocated for SRBs

only (based on SRBBitRateRRCSetupEC parameter
value related to establishment cause “originating
NBAP: RADIO LINK SETUP
conversational call”).
• Relocation is accepted when the PS RAB is allocated
NBAP: RADIO LINK SETUP RESP. DCH0/0 and the SRB is mapped to DCH/DCH during
resource allocation.
RANAP: RELOCATION REQUEST ACK to PS • The RNC sends the NBAP: RADIO LINK SETUP to the
NodeB

Complete specification of Radio Link

• The NodeB allocates the necessary resources and
and Radio Bearer is sent responses with NBAP: RADIO LINK SETUP RESPONSE
• When resources in target system are allocated, the RNC
Handover preparation sends RANAP: RELOCATION REQUEST ACK to PS CN
• Complete specification is used instead of Default
Handover execution configuration (GSM -> WCDMA PS Handover case).
That means, complete specification about Radio Link
and Radio Bearer is provided.

For internal use

16 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 SRVCC from LTE and CSFB with HO Table of Contents
CSFB with PSHO procedure (service driven trigger)

• The PS Core Network sends PS Handover Response to the

Source MME (Target to Source transparent Container)
UE Source eNB Target NodeB Target RNC MME Core Network • The Source MME sends Handover Command to the E-
UTRAN
RANAP: RELOCATION REQUEST ACK to PS • E-UTRAN order the UE to achive uplink synchronization on
the WCDMA Uu interface
Handover preparation
• Once the UE tunes to the new system, Handover Detection
at target UTRAN occurs. This is signalized to PS Core
S1-AP: Handover Command Handover execution Networks via RANAP: Relocation Detect message.
• The UE sends RRC: HANDOVER TO TO UTRAN COMPLETE
S1-AP: HO from E-
UTRAN Command
message

RANAP: RELOCATION DETECT to PS

• The RNC informs PS Core about the completion of handover
via RANAP: RELOCATION COMPLETE messages
• PS Core Network sends PS Handover Complete
message to the Source MME.
Handover completion
RRC: HANDOVER TO UTRAN COMPLETE • Source MME releases resources on E-UTRAN side.
• The UE requests CS call via 3G network only after the
RANAP: RELOCATION COMPLETE to PS handover is successful.

PS Handover
Complete

The MME releases resources

on E-UTRAN side.

For internal use

17 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 Configuration Management Table of Contents
Parameters

• RAN2435 SRVCC from LTE and CSFB with HO introduces the following set of parameters that can be used to deceide which interworking procedures are
accepted by UTRAN.

RNFC • There are no specific configuration parameters for SRVCC on WCDMA side.
Radio Network Feature Controll
• All parametrization work should be done at LTE side using:
• LTE872 SRVCC to WCDMA and
CSFB Enabled
• LTE736 CS Fallback to UTRAN
related parameters. For details please check LTE NEIs: CSFB NEI and SRVCC NEI
SRVCC Enabled

CSFB Enabled / SRVCC Enabled

Abbreviated name CSFBEnabled / SRVCCEnabled

MOC RNFC These parameters indicate whether CS

Fallback and/or SRVCC functionalities are
Data type Enumeration enabled in the RNC or not.
Description Functionalities works at the cell level only
Parameter group Handover Control Configuration if WCEL/IncomingLTEISHO is in state
Enabled in target cell.
Range and step Disabled (0), Enabled (1) .

Default value Disabled (0)

For internal use

18 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 Deployment Aspects Table of Contents
Licenses Keys and activation

• RAN2435 SRVCC from LTE and CSFB with HO is controlled by „ISHO from LTE” license . This license controls RAN2176 LTE PS Handover as well.

License Name: ISHO from LTE • The SRVCC functionality is enabled in RNC by the RNFC/SRVCCEnabled parameter.
License Type: Long-term Capacity • The CSFB functionality is enabled in RNC by the RNFC/CSFBEnabled parameter.
• Both SRVCC and CSFB are activated in in the cell by setting WCEL/IncomingLTEISHO parameter to Enabled.
It is possible to set SRVCC
and CSFB related parameters • The change of the IncomingLTEISHO parameter to Enabled consumes license in terms of number of cells.
Description: to Enabled value when • The change of the IncomingLTEISHO parameter to Disabled frees license in terms of number of cells.
license exists and the state is
ON.
• Upon receving the RANAP: Relocation Request from CS CN due SRVCC from LTE or from PS CN due to
CSFB from LTE, RNC accepts the request only if the following conditions are satisfied:

ISHO from LTE Number of 1. License of „ISHO from LTE” exists and the state is „On”.
WCEL/IncomingLTEISHO
CAPACITY VALUE
parameters set to Enabled 2. Management parameter WCEL/IncomingLTEISHO is set to Enabled for the corresponding target cell
under target RNC.
100 84 3. For SRVCC management parameter RNC-SRVCCEnabled is set to Enabled. For CSFB management
parameter RNFC-CSFBEnabled is set to Enabled.
Number of activated cells must not exceed
the capacity of „ISHO from LTE” license.
• For SRVCC, the RNC will check the value of the parameters when receiving incoming relocation request from
ISHO from LTE Number of CS domain and the source system is LTE. If the IncomingLTEISHO or SRVCCEnabled has value Disabled,
WCEL/IncomingLTEISHO
CAPACITY VALUE
parameters set to Enabled
the relocation is rejected.
• For CSFB, the RNC will check the value of the parameters when receiving incoming relocation request from PS
100 103 domain and the source system is LTE. If the IncomingLTEISHO or CSFBEnabled has value Disabled, the
relocation is rejected.

For internal use

19 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 Performance Aspects Table of Contents
Counters for SRVCC

• For SRVCC monitoring purposes the following

counters are provided:
UE Source eNB Target NodeB Target RNC MME Core Network

M1009C288 +1 Counter is updated only if identified as

RANAP: RELOCATION REQUEST from CS
LTE originating (IE UE History Information
RANAP: RELOCATION REQUEST ACK to CS
indicates LTE cell as last visited cell; all causes are
included except „CS Fallback”)
RANAP: RELOCATION Failure to CS
M1009C289 + 1 Counter is updated only if the request
RANAP: RELOCATION DETECT to CS was identified as SRVCC from LTE procedure

RANAP: RELOCATION COMPLETE to CS

M1009C286 +1 or M1009C290 +1 or M1009C291 +1 or
M1009C292+1 or M1009C293 +1 or M1009C294 +1
Counters are updated depending on the detaild reason
• M1009C288 LTE CS HHO IN PREP REQ (incoming relocation request) causing the relocation failure.
• M1009C289 LTE CS HHO IN PREP SUCC (succesful relocation preparation)
• M1009C290 LTE CS HHO IN PREP FAIL TRANS (failure due to transport layer cause) M1009C295 +1 Counter is updated only if relocation
• M1009C286 LTE CS HHO IN PREP FAIL DUE TO RNL (failure due to radio network layer cause) considers SRVCC from LTE ISHO
• M1009C291 LTE CS HHO IN PREP FAIL DUE TO NAS (failure due to non-access startum cause)
• M1009C292 LTE CS HHO IN PREP FAIL DUE TO PROT (failure due to protocol cause) M1009C296 + 1 Counter is updated only if relocation
considers SRVCC from LTE ISHO
• M1009C293 LTE CS HHO IN PREP FAIL DUE TO MISC (failure due to non-standard cause)
• M1009C294 LTE CS HHO IN PREP FAIL DUE TO NON STAN (failure due to non-standard cause)
• M1009C295 LTE CS HHO IN DETECT (relocation detection)
Also old CS ISHO counters (M1009C243…M1009C250, M1009C259)
• M1009C296 LTE CS HHO IN COMPLETE (relocation completion)
are updated along with these LTE ISHO counters
For internal use
20 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 Performance Aspects Table of Contents
Counters for CS Fallback

• For CS Fallback monitoring purposes the following

counters are provided:
UE Source eNB Target NodeB Target RNC MME Core Network
M1009C297 +1 Counter is updated only if identified as
RANAP: RELOCATION REQUEST from PS LTE originating (IE UE History Information
indicates LTE cell as last visited cell and IE Radio
RANAP: RELOCATION REQUEST ACK to PS Network Layer Cause Extension has been set to
CS Fallback
RANAP: RELOCATION Failure to PS

M1009C298 + 1 Counter is updated only if the request

RANAP: RELOCATION DETECT to PS was identified as CS Fallback from LTE procedure

RANAP: RELOCATION COMPLETE to PS

M1009C299 +1 or M1009C300 +1 or M1009C301 +1 or
M1009C302+1 or M1009C303 +1 or M1009C304 +1
Counters are updated depending on the detaild reason
• M1009C297 LTE CS Fallback IN PREP REQ (incoming relocation request) causing the relocation failure.
• M1009C298 LTE CS Fallback IN PREP SUCC (succesful relocation preparation)
• M1009C300 LTE CS Fallback IN PREP FAIL TRANS (failure due to transport layer cause) M1009C305 +1 Counter is updated only if relocation
• M1009C299 LTE CS Fallback IN PREP FAIL DUE TO RNL (failure due to radio network layer cause) considers SRVCC from LTE ISHO
• M1009C301 LTE CS Fallback IN PREP FAIL DUE TO NAS (failure due to non-access startum cause)
• M1009C302 LTE CS Fallback IN PREP FAIL DUE TO PROT (failure due to protocol cause) M1009C306 + 1 Counter is updated only if relocation
considers SRVCC from LTE ISHO
• M1009C303 LTE CS Fallback IN PREP FAIL DUE TO MISC (failure due to non-standard cause)
• M1009C304 LTE CS Fallback IN PREP FAIL DUE TO NON STAN (failure due to non-standard cause)
• M1009C305 LTE CS Fallback IN DETECT (relocation detection)
Also old PS ISHO counters (M1009C276…M1009C285) are updated
• M1009C306 LTE CS Fallback IN COMPLETE (relocation completion)
along with these LTE ISHO counters
For internal use
21 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna
 Performance Aspects Table of Contents
Counters for CS Fallback EMERGENCY CALL

• For EMERGENCY CALL CS Fallback monitoring

UE Source eNB Target NodeB Target RNC MME Core Network
purposes the following counters are provided:

RANAP: RELOCATION REQUEST from PS M1009C307+1 Counter is updated only if identified as

LTE originating (IE UE History Information
indicates LTE cell as last visited cell and IE Radio
Network Layer Cause Extension has been set to
RANAP: RELOCATION Failure to PS
CS Fallback triggered and Source RNC to
Target RNC Transparent Container IE contains
CSFB Information IE with value CSFB High
Priority

Together with this counter, M1009C297 is also updated.

• M1009C307 LTE CS Fallback IN PREP REQ (incoming relocation request)

• M1009C308 LTE CS Fallback IN PREP SUCC (succesful relocation preparation) M1009C308 + 1 Counter is updated only if the request
was identified as CS Fallback EMERGENCY CALL from
LTE procedure

Together with this counter, depending on the detaild

reason causing the relocation failure,
M1009C299 or M1009C300 or M1009C301 or
M1009C302 or M1009C303 or M1009C304 is updated.

For internal use

22 © Nokia Siemens Networks 2013 MBB CS Network Engineering / Marek Wojtyna