SRVCC

SRVCC – Single Radio Voice Call Continuity
FN 2008
1. VoLTE and NSN Implementation

2. SRVCC
For public use – IPR applies

1 © Nokia Siemens Networks CN60022EN50GLA0
VoLTE and NSN Implementation

LTE Implementation
• More than 100 operators have

invested in LTE networks
• LTE is answer for increased voice
and data capacity demand - coming
from growing smart phone segment -
providing at a significantly lower
cost per bit.
• Voice ARPU being driven down by When to offer Voice over LTE ?
low cost VoIP services offered by
internet players
• VoLTE is mandatory service to
maintain the current voice business
model in LTE
• New services opportunity on a
common service architecture
Drivers for LTE
“10x faster”
100
Mbps
42
~10 Mbps
• Demand for higher bandwidth HSPA HSPA+ LTE
• Lower latency Latency Latency

(Round trip delay)
(Rountripdelay) **
• Better spectral efficiency GSM/EDGE

GSM/EDGE
• New spectrum HSPA

HSPA Rel6
Rel6
HSPAevo
HSPAevo
• E2E All-IP flat architecture

(Rel 8)
LTELTE
0 20 40 60 80 100 120 140 160 180 200 ms
“capacity bands”: carriers up to 20MHz DSL (~20- 50 ms, depending on operator)
Bandwidth New and large bands:

LTE 2.6GHz • 2x70MHz paired
• 1x 50MHz unpaired
1900/2100 MHz
1800 MHz/AWS
Refarming
…
850/900 MHz
LTE 700/800MHz (Digital Dividend)
Coverage

Voice over LTE - why and how
Voice over LTE is mandatory

to preserve the operators services business model in LTE
Method Comments
IMS-VoLTE • 3GPP standard solution using IMS
Voice over LTE • Standard devices, inter-working and roaming procedures
• Open to deploy more multimedia services (RCS)
CSFB • LTE for data only (not really a VoLTE solution)
CS Fall Back • For voice calls the device connection falls back to 2G/3G
• Data session is interrupted during voice call
VoLGA • Tunnels CS calls to LTE devices – specific devices
V. o. LTE Gateway • Not a standard, did not find acceptance in the industry
Fast Track • Works on top of NSN’s mobile switching system MSS

Fast Track to IMS • Provides voice and SMS only  standard LTE devices
OTT • Uses Internet services over the data link (e.g. Skype)
Over the top • Operator maintains the bit pipe

VoLTE evolution
SMS over LTE connection, LTE Broadband VoIP

Over the air configuration, prepaid information
Dual radio terminals for CDMA /LTE operators

Voice over CDMA and data over LTE
MSS SR CS FallBack to 2G/3G

4.1 Voice over 2G/3G and data over 2G/3G or LTE
LTE voice technology take-off
times
VoLTE with QoS
Terminal and network Secured voice quality
requirements meet each
other MSS VoLTE with SRVCC
IMS SR
Seamless voice continuity
5.0
2010 2011 2012 2013

6 © Nokia Siemens Networks CN60022EN50GLA0 Dept. / Author / Date
LTE Features of MSS IMS System SR5.0 release
NSN introduces 3GPP IR.92 VoLTE capability
● LTE SRVCC
● SCC AS
● VoLTE IMS - CS Interworking
● Co-located multiple applications
● VoLTE with QoS
● GSMA VoLTE (IR.92)
● IP-SM-GW for SMS over IP
● Ut interface
● HD video over LTE (IR.94)
● Media Resource Function (MRF) for broadband voice
● CS Fullback Support (already in SR4.1)
* MSS VLR BU Solution General Availability (GA) granted for DX MSS M14.6 GCD10.3,
For public use – IPR applies M15.0 MP1.3, M15.1 MP2.3, Open MSS M16.0 EP1 MP2.0
LTE Target Architecture
and product portfolio
NVS as TAS
CMS-8200 with OneNDS for HSS Open to add more services
Subscriber data management
Applications
TAS
Applications
Applications
CMS-8200 Sh
+OneNDS ISC CFX-5000 for IMS core control
S6a Cx
CSCF, TRCF, MCF, …
MME
CFX-5000 SIP
S11 Gx H.248
PCS-5000 IP
Network
eNb
S/P-GW BGF
LTE
PCS-5000 for all Policy control
PCRF, SPDF, …
LTE and an all-IP transport network simplifies the core

VoLTE Evolution,
MSS and MGW reused
VoLTE Features
Drivers
1. CSFB Voice core Fixed
users • Seamless
2. VoLTE with QoS and SMSHLR SDM HSS SBC
MAG
2G/3G/LTE voice
GSMA VoLTE (IR.92) and video experience
(IR.94) • Fixed mobile
SCC AS SMSC
3. SRVCC mobility NVS TAS RCS convergence
MSS IMS IMS VAS support
Voice 2G/3G radio network • HD video for LTE
• QoS for VoIP
Sv/SGs • VoIP/RCS to
BSC / compete the OTT
BSS/NB MGW PSTN
RNC VoIP threat
PCRF
Single control point of
CSFBSRVCC signaling and media
MME plane
eNB SGW PGW Intern Long term all-IP
SMS Voice LTE radio network LTE Packet core et network architecture

MSS IMS SR5.0 functional contents
MSS IMS SR 5.0 Products and Functions SCP

RNC
MSC-S SRVCC CSFB MGCF
BSC
MSS SMS-C
TAS/MMTel IP-SM- HLR

Ut SCCAS GW
DX HLR/NT HLR
MRFC MSS/NVS IM-SSF
Gm
H.24 ISC Mg, One NDS
8 P- Mj
I/S-CSCF BGCF
CSCF
ENUM
CFX-5000
eNodeB iNUM
Rx Cx
SGs,S PCRF HSS FE Legend

MME v
PCS-5000 CMS-8200 SR5.0 Function
S6a
Flexi NS H.24
Gx SR 5.0 Product
8
S-GW P-GW MRFP IMS-MGW R4 MGW
Function
Flexi NG MGW
Counterpart product

Dept. / Author / Date
The Open Core System example: VoLTE
Co-Located Multiple Application
MSS / NVS
VoLTE functionality in two CSFB,
cabinets MGCF, SCC-AS 11 11 1 11 1 111 1 11
12 3 45 6 78 9 1 2 345 6 7 89
01 23 4 56 0 123 4 56
HLR
Software upgrade from
MSS to NVS with re-use common
of existing blades and Hub blades
S-GW
network integration P-GW
11 1 1 1 1 1 11 1 1 1 1 1
12 3 45 6 78 9 12 3 45 6 78 9
01 2 3 4 5 6 01 2 3 4 5 6
Introduce IMS CSCF / HSS-FE
blades/shelf according to PCRF
traffic needs ENUM
MME
Re-balance resources MGW
from CS voice to the 1 2 34 5 6 7 89
1 1 11 111
0 1 23 456 12 3 45 6 78 9
11 1 1 1 1 1
01 2 3 4 5 6
VoLTE when traffic
requirements change
* for approx 600k subscribers with NSN traffic profile
VoLTE key products and programs
MSC Server System Program (MSS SR) – IMS and LTE
CSCF/ MSS/ PCRF EPC Radio

HSS / NVS/ (PCS) (NS,NG) (RL)
(IMS) MGW/
HLR
(M,U)
CFX-
5000
NVS, Flexi NS
CMS- PCS-
MSS, 5000 Flexi BS
8200 Flexi NG
MGW
IMS VoLTE

MSS IMS SR5.0 Main Product Component
Releases
Product Release
CFX-5000 (IMS) (Atca) IMS9.1
CMS-8200 (HSS) (Atca) IMS9.1
MGW (Atca) Ui5.0EP1
MGW (IPA) U5.0EP2
MSS/NVS (Atca) Ma16.1
MSS/NVS (DX) Md16.1
PCS-5000 (Atca) 6.3

LTE Deployment Options
Exploring the differences between

CSFB, VoLGA, IMS – VoLTE (Fast Track and Full IMS)

VoLTE Deployment Options (1)
Contents:
 CS Fallback (CSFB)
for Voice and SMS
 VoLGA
 IMS VoLTE (FastTrack and Full
IMS)

VoLTE Deployment Options
Introduction
• the LTE radio and EPC are IP only:
– there is no CS domain anymore; therefore
SRVCC
Voice must also be carried over IP.
▪ UE’s may fall back into the existing 2G/3G CS network (CSFB),
but this is less efficient from a radio resource point of view. LTE
cell
2G/3G
coverage
• Single Radio:
– most UEs will only be capable to have one active radio,
LTE or GSM/UMTS, but not both. Active radio means
being able to send and receive via this radio technology.
• Initially, there will only be Hot Spot Coverage:

– Voice over LTE coverage will be in hot-spots only, thus Voice over LTE
and CS Voice needs to be supported for the same user
– The same user experience is desired in 2G/3G CS and VoLTE.
– A solution for Voice Call Continuity (“handover”) between
LTE and CS is required.

Solutions
1. IMS based Voice over LTE
– includes the NSN IMS solution and the NSN FastTrack solution.
▪ both solutions are compliant to the One Voice VoLTE profile
defined in GSMA VoLTE IR.92.
▪ the NSN FastTrack is an initial step targeting a simple/easy
deployment solution, but only partially 3GPP IMS compliant.
– IMS is the main stream 3GPP solution for LTE/VoIP
2. No VoIP/LTE, but fallback to 2G/3G CS:

– 3GPP Interim Solution. IMS is not needed at
all for voice and SMS when CSFB is used.
▪ for voice: UE leaves LTE and uses 2G/3G CS to send/receive calls
▪ for SMS: SMS can be sent and received while staying in LTE
▪ it is all about timing: eventually LTE/IMS for VoIP and SMS
will substitute CSFB ... the question is when.
3. VoLGA formerly known as “CS over PS” (dead):

– this is not accepted in the standards-/operator communities.
▪ proprietary approach: CS and mobility signaling (Iu-CS)
is tunneled via IP/LTE access to the MSC.

VoLTE Deployment Options –
CS Fallback (CSFB) Solution
• Motivation:
– CSFB enables LTE introduction as a data-only type of network
in the beginning and makes the initial LTE investments smaller.
– IMS roaming agreements are not in place yet.
• Standards:
– 3GPP TS 23.272 describes CSFB
– 3GPP TS 29.118 describes the SGs-interface between the MSC and the MME
• Support in NSN MSC Server:

– SMS over SGs/LTE is supported in the M14.6 product release (MSS SR4.0)
– CSFB for Voice is supported in the M15.0 product release (MSS SR4.1)
Voice calls SMS

the terminal switches to the terminal can stay in
3G or 2G for voice LTE to send/receive SMS
LTE 3G 2G LTE

CS Fallback (CSFB) Solution
• CSFB Procedure Overview:
– UE performes a combined attach (EPS/CS)
– Terminating Call: the MSC sends a paging request to the MME which is
then paging the terminal via eNB and request it to move to 2G/3G.
– Ongoing Data Sessions may remain active in 2G/3G PS,
possibly at a lower bit rate, or are interrupted.
6. the CS Voice Call is delivered

to the UE via 3G/3G access 2. Incoming Terminating CS Voice Call
5. The UE sends a
Paging Response via the
2G/3G access to the MSC
BSS
2G/3G coverage
MSC / VLR
3. MSC initiates Paging via MME/eNB
Handover
4. When receiving the Paging to 2G/3G
Request, the UE returns the HSS /
HLR
CSFB Indicator to the
MME/MSC and performs
the Handover to 2G/3G
LTE Cell eNB MME PDN-GW
1. UE performs Combined Attach (EPS/CS)

- includes Location Update from the MSC to the HLR/HSS
Contents:
for Voice and SMS
 VoLGA (dead)
IMS)

IMS based VoLTE: Deployment Options –
Voice over LTE via Generic Access (VoLGA)
• What is VoLGA:
– 2G/3G CS and mobility signaling are tunneled via IP/LTE access
to keep the mobile core stable (but be able to exploit LTE for voice).
• Based on Unlicensed Mobile

Access (UMA) Concept
for Mobility over WLAN.
• VAN Controller (VANC)
acts as interworking function.
• No impact on the MSC (that
just sees the A/Iu interface).
• supports CS voice and SMS.
• Proprietary solution.
• Kineto holds all relevant IPRs.

Contents:
for Voice and SMS
 VoLGA
IMS)

NSN FastTrack
• Motivation:
– enable the operator to use VoIP/LTE with standard IMS Phones;
but without that the operator has to deploy a full IMS.
– enable a stepwise deployment.
Provide standard interfaces Provide Unchanged interfaces

to the “new” LTE/IMS world to the “old” CS world
IMS Gm
UE OAM, Charging
FastTrack
Sv, SGs
Solution Nc
(MSS, NVS,
MME CFX5000) MSC-S
Gx
Mb Nb
SAE-GW MGW

HLR
NSN FastTrack
• Architecture:
– LTE functionality expansion to the existing NSN MSS
▪ NVS VoIP Server upgrade on the MSS
▪ deployment of the CFX5000/P-CSCF/PCRF
– 3GPP interfaces supported:

▪ the Sv interface enables SRVCC support FastTrack
▪ the SGs interface enables CSFB HLR
▪ the Gx interface enables
standard QoS Control. SIP MSS/NVS
CFX-5000
▪ the Gm interface allows the (P-CSCF/PCRF) (MSC-Server)
support of standard IMS Phones.
Sv, Gm, H.248

SGs Gx
Mobile Broadband Access
S11
S1-MME
SAE GW MGW
MME
RTP
Gm (SIP) S1-U RTCP
IPA 2800
eNB
GSMA PRD IR.92 – “IMS Profile for Voice and SMS”
• Specification Scope:
• the current 3GPP standards for Voice over LTE give

multiple alternatives for the Voice implementation and services
• NSN fine tunes / defines a clear profile for voice
and SMS and takes into account both:
requests from network and terminal vendors.
• While the technical profile is focused on LTE, the IMS/SIP
aspects of the profile are applicable to all cellular access types.
IMS VoLTE
Terminal Network
profile
Summary
1. IMS based Voice over LTE
– The NSN IMS solution
– SRVCC for 2G/3G handover
2. No VoIP/LTE, but fallback to 2G/3G CS:

– 3GPP Interim Solution.
– IMS is not needed for this.
3. VoLGA formerly known as “CS over PS”:

– this is not accepted in the
standards-/operator communities.

SRVCC – Single Radio Voice Call Continuity
FN 2008

SRVCC Single Radio Voice Call Continuity
SRVCC FN2008 is available for

• MSS DX200 in Md16.1 (SR5.0) and for
• MSS ATCA in Ma16.1 EP1 (SR5.0)
Feature code of license

3729 On/Off SRVCC Support in MSS
3284 On/Off Dynamic Payload Type restriction

Introduction – SRVCC
(Single Radio Voice Call Continuity)
• E-UTRAN (4G) access together with EPC will provide Packet

Switched services for Mobile subscribers, and is able to provide
sufficient QoS for VoIP calls as well.
– However, 4G access might be available only in spotted areas in the
first phases of introduction, which means that VoIP calls cannot be
maintained outside 4G coverage. In order to enable seamless voice
service from 4G access (VoIP) to 3G/2G (UTRAN/GERAN) access
(CS voice) the MSC Server SRVCC functionality has been specified
by 3GPP.

Introduction – SRVCC
•With SRVCC procedure the Mobile subscribers are able to

roam outside 4G coverage without the call being disconnected.
– The SRVCC functionality will cause challenges for the MSS enhanced
with SRVCC, called as MSS(SRVCC).The UE shall move in SRVCC
from 4G to 3G/2G with limited amount of information, no signaling
connection and not attached to any CS services. The SRVCC
procedure shall be also done in very short period of time during which
also user plane, charging and statistics shall be fixed.

Architecture – SRVCC
2G/3G IMS = IP Multimedia Subsystem

UE MSS(SRVCC) NVS = VoIP Server
IMS or NVS
Handover/Relocation Sv
SCC AS
SCC AS = Service Centralization and

Continuity Application Server
(Provides IMS-based mechanisms for
enabling service continuity of
multimedia sessions)
4G (LTE)
UE MME

LTE voice options
LTE used for data service only
Recommended
Step1: CSFB via
existing MSS
Voice via 3G/2G based on
standardized CS Fallback
Recommended Step2: VoLTE compliancy to

VoLTE via NVS upgrade Multimedia IMS-based VoLTE.
NVS as IMS TAS Sv ISC

SRVCC Configuration at network level
SMSC IMS
MSS
(SRVCC) SIP MGCF
MAP SIP-I
BICC.. SIP x-CSCF
HLR SCC AS
NVS or
• SRVCC enhanced MSC H.248 H.248 CFX5000/
Server {called as CMS8200
MSS(SRVCC)} function is
always in MSC/MSS MGW MGW
• SCC AS functionality is co-
located in NVS or in SIP/Gm
CFX5000 / CMS8200 Note. MGCF function is
(MCF) Sv needed with
MSS(SRVCC)
• All interfaces according to
only if ISUP/BICC
3GPP TS 23.216 (Single RTP signaling
Voice Call Continuity) RTCP is used as outgoing
signaling from
S11 MSS(SRVCC). If using
S1-MME SAE GW SIP signaling as outgoing
SIP/Gm MME signaling from
VoLTE MSS(SRVCC), the MGCF
UE function is not needed at
S1-U all.
eNb
LTE SRVCC SR5.0
SCC AS
Challenge
• LTE coverage will be limited by the time VoLTE is launched and therefore handover from
LTE to 2G/3G is necessary for keeping calls alive when people move during calls
• IMS will eventually handle VoIP in LTE and 2G and 3G remain circuit switched and this
brings SIP / CS change request in addition to change of used radio technology
• LTE terminals have only one radio active at the time => handover between LTE and
2G/3G are time critical functionality
Solution
• MSS implements the 3GPP release 8 standardized Single Radio Voice Call Continuity
(SRVCC) functionality, which enables call continuity from the LTE VoIP towards the
2G/3G CS core network
Operator benefits
• SRVCC makes it possible to introduce primary voice service in LTE so that
both operator voice and wideband data services are simultaneously available
• When moving from LTE coverage area to 2G/3G area voice and data calls
continues without interruption
• SRVCC secures high quality user experience, especially in the LTE
introduction phase when LTE access coverage is still sparse and limited

LTE SRVCC SR5.0
Functionality: SCC AS
Voice over CS for MGW
• Sv-interface between MME and MSS is introduced
for SRVCC purpose. 2G/3G access
• Terminal measures neighboring cells signal BSC MSS
strengths. When the intersystem access change (SRVC PSTN/
criteria from LTE to 2/3G are met, Node B initiates C) PLMN
handover toward MME. Based on subscription
information MME knows whether SRVCC can be NVS with colocated
applied to a terminal. While the intersystem change HLR
MAP
is needed and there exist a real-time bearer, MME SCC AS/T-ADS and
initiates a SRVCC toward the MSS. M
• MSS reserves the target cell resources from 2G/3G S

g TAS is the
v
access from same MSS, or through inter MSS anchoring point
handover. MSS also utilizes embedded MGCF
functionality (Mg) to makes a call towards the VCC MME
anchoring point (SCC AS) based on received Cx IP
Session Transfer Number (STN-SR). S1
IMS/ HSS services
1 Gx
• The anchoring point is responsible for the session CFX-5000
continuity from PS to CS bearer. After these actions
MSS sends a response to MME and the terminal is eNb SAE-GW
commanded to handover to the target cell.
Support required (e2e viewpoint): Voice over IP for LTE access
• The VoLTE call prior the SRVCC has been established with dedicated bearers (P-CSCF, PCRF)
• LTE-Node-B, MME and MSS need to be upgraded for supporting SRVCC
• LTE terminal supporting the SRVCC
• HSS/HLR is provisioned with STN-SR.
• No new functionality introduced to MGW but existing functionality is reused by SRVCC MSS
• The SRVCC is planned to be enhanced in SR5.0 PT-2 to support in addition to the transfer of
single active call also one inactive/held call (enhancement to MSS with SRVCC, SCC AS).
SCC AS for SRVCC SR5.0
Challenge: SR VCC
• LTE coverage will be limited by the time VoLTE is launched and therefore handover from LTE to
2G/3G is necessary for keeping calls alive when people move during calls
• IMS will eventually handle VoIP in LTE and 2G and 3G remain circuit switched and this brings SIP
/ CS change request in addition to change of used radio technology
• LTE terminals have only one radio active at the time => handover between LTE and 2G/3G are
time critical functionality
• New dedicated network elements to be avoided
Solution:
• NVS functionality of MSS implements the Service Centralization and Continuity Application
Server (SCC AS) role including Terminating Access Domain Selection (T-ADS) functionality
to support the 3GPP release 8 standardized Single Radio Voice Call Continuity (SRVCC)
solution, needed to enable call continuity from the LTE VoIP towards the 2G/3G CS core network
Operator benefits
• Existing elements upgraded by software upgrade only
• Scalable and integrated cost effective SCC AS/T-ADS functionality
• Optimized architecture for interfaces, signaling loads and service
interruption times
• Seamless interworking with existing O&M and statistical tools
• Geo redundancy supported

SCC AS for SRVCC SR5.0
Functionality: SR VCC
• In order to support SRVCC requirements, the NVS TAS
is enhanced with call anchoring and session transfer
functionality
Voice over CS for MGW
• When VoLTE subscriber registers in IMS, the
corresponding NVS is triggered to provide it TAS/MRFC, 2G/3G access
PSTN/
IP-SM-GW and SCC AS/T-ADS functionalities. NVS can BSC PLMN
co-locate with the MSS implementing the SRVCC
MSS (SRVCC)
• The anchoring functionality is triggered when a user
initiates/receives a call and if the user has a Session
Continuity subscription in the HSS and NVS
HLR
• The MSS initiates the session transfer call towards the MAP
IMS using the session transfer number for single NVS

radio (STN-SR)
S
• The S-SCSF triggers the call to the corresponding v
NVS/SCC AS via ISC interface and NVS performs the

session transfer taking into account the possible need MME
for MGW resource. Cx IP
• The SRVCC is planned to be enhanced in SR5.0 PT-2 to S1 IMS/ services
HSS
support in addition to the transfer of single active call 1 Gx
CFX-5000
also one inactive/held call (impact to MSS with SRVCC,
SCC AS).
eNb SAE-GW
Support required (e2e viewpoint): Voice over IP for LTE access
• LTE-Node-B, MME and MSS upgraded for supporting SRVCC
• MSS is upgraded with SRVCC and NVS TAS upgraded with SCC AS/T-ADS functionality
• HSS/HLR supporting the SRVCC related information
• LTE terminal supporting the SRVCC
Overview – SRVCC
• The MSS(SRVCC) (=MSC Server Enhanced for SRVCC) shall

support the following additional functionalities for SRVCC:
– The Sv interface support between the MME/SGSN and the
MSS(SRVCC)
– Handling the relocation/handover request for the voice component
– Coordinating the CS relocation/handover and SIP session transfer
– Interworking with SIP session transfer procedure to CS
– Handling the Location Update instead of the terminal
• The feature shall be optional and shall be controlled with an
ON/OFF license and shall be applicable for both DX and
Open (ATCA) MSS.

Sv interface
• New interface Sv between MME and MSS with SRVCC function.
• The Sv interface is defined for SRVCC functionality by 3GPP TS 23.216
and 3GPP TS 29.280.
• Two nodes communicate with GTP tunnels over a GTP based interface. A
GTP tunnel is identified in each node with a Tunnel Endpoint Identifier
(TEID), an IP address and a UDP port number.
• The Sv interface establishes connection between the MSS and the
MME/SGSN to enable the SRVCC specific procedures.
• The MSS acts as a server and the MME/SGSN as a client.

Sv interface
•The receiving end side of a GTP tunnel locally assigns the transmitting side the TEID value to
use. The same tunnel is shared for the control messages related to the same UE operation.
GTP tunnels separate traffic into different communication flows. GTPv2-C messages are sent
per UE over the Sv interface.
• GTP tunnel with unique TEID value is SRVCC procedure specific !!! On top UDP/IP link,
there can be multiple GTP tunnels simultaneously for SRVCC procedures per
subscribers (limiting factor is SRVCC specific hand count in SV0PRB  1000
simultaneous SRVCC sessions per xSU)

Sv interface connectivity
•There can be max. 100 MME/SGSNs configured to one MSS/VLR. Every
MME/SGSN can have max. 32 UDP link address per one MSS/VLR. UDP
links from one MME cannot be configured to same signaling unit (BSU or
GISU)
• Links can be used “equally” within one SRVCC procedure
• “MME/SGSN configuration file” controlled by EJ MML command group, has
main MME/SGSN address data, link state, logical address of MSS signalling
unit(s), FQDN, MSS restart counter and index to parameter file.
• “MME/SGSN parameter file” controlled by EJ MML command group, has
common configuration data of one physical MME/SGSN. Record 0 is
reserved for default values. Data includes default SAI, echo handling
configuration, timers, retransmission timer and amount, control information.
Note: There can be max 100 SGs MME IP addresses configures and additional max
100 Sv MME IP addresses.

Sv interface connectivity model, example 1
MME/SGSN MSS
xSU-0
SV0 AIF
Centralized unit
xSU-1 VLR
SV0 AIF
xSU-2
SV0 AIF
…
SVEFIL config (EJ MML): xSU-n
MME_SGSN_index=0
SV0 AIF
(Unit-0)
UDP_link=0: xSU-0
UDP_link=1: xSU-1
UDP_link=2: xSU-2
UDP_link=3: xSU-n
Sv interface connectivity model, example 2
MME/SGSN MSS SVEFIL config (EJ MML):
Unit-0 xSU-0
UDP link 0 MME_SGSN_index=0 (Unit-0)
SV0 AIF
UDP_link=0: xSU-0
UDP_link=1: xSU-1
xSU-1 MME_SGSN_index=1 (Unit-1)
Unit-1 VLR UDP_link=0: xSU-0
SV0 AIF UDP_link=1: xSU-1
UDP link 1 MME_SGSN_index=2 (Unit-2)
UDP_link=0: xSU-2
xSU-2 UDP_link=1: xSU-n
Unit-2
MME_SGSN_index=n (Unit-n)
UDP link 0 SV0 AIF
UDP_link=0: xSU-2
UDP_link=1: xSU-n
…
xSU-n
Unit-n
SV0 AIF
UDP link 1

Create Sv interface configuration with the EJB
command.
ZEJB:TYPE=SV,NAME=MME1:ADDR="10.85.17.31",IND=0,PIND=0,
ASTATE=ACTIVE,FQDN="mmec12.mmecgi23.mme.epc.mnc03.mcc262.3g":;
TYPE interface type

NAME MME/SGSN name
NBR MME/SGSN number
ADDR MME/SGSN primary IP address
IND unit index in the MSS
PIND MME/SGSN parameter set index
ASTATE administrative state of the UDP link
FQDN MME/SGSN fully qualified domain name

Interrogate Sv interface configuration with the EJJ
command.
ZEJJ:TYPE=SV,NAME=MME1;
OUTPUT SV INTERFACE CONFIGURATION
SGSN/MME NAME .................(NAME).. :MME1
SGSN/MME NUMBER ...............(NBR)... :0
FULLY QUALIFIED DOMAIN NAME ...(FQDN).. :mmec12.mmecgi23.mme.epc.mnc03.mcc262.3g
PARAMETER SET INDEX ...........(PIND).. :0
RESTART COUNTER FOR UDP LINKS..(RECNT). :0
SV INTERFACE CONNECTIONS
========================
SGSN/MME IPV4 ADDRESSES UNIT INDEX ASTATE OSTATE
----------------------- ---- ----- ------ ------
10.85.17.31 BSU 0 ACTIVE DOWN
SGSN/MME IPV6 ADDRESSES UNIT INDEX ASTATE OSTATE

----------------------- ---- ----- ------ ------
NONE

Sv interface messages
SRVCC procedure specific messages:

• SRVCC PS to CS Request
• SRVCC PS to CS Response
• SRVCC PS to CS Complete Notification
• SRVCC PS to CS Complete Acknowledge
• SRVCC PS to CS Cancel Notification
• SRVCC PS to CS Cancel Acknowledge
GTP protocol specific messages:

• Echo Request
• Echo Request Acknowledgement
• Version Not Support

High level concepts for SRVCC
from E-UTRAN to UTRAN/GERAN

SRVCC Function
When the subscriber moves from LTE to 2G/3G, the SRVCC capable terminal
measures the signal strength of the neighboring cells and sends measurement
reports to E-UTRAN.
When the inter-system access change criteria from LTE to 2G/3G are met, the
eNodeB initiates PS to CS handover request to the MME.
Based on the Session Transfer Number for SRVCC (STN-SR), that is, SRVCC-
specific subscription information stored in the HSS and the HLR, the MME knows
whether the SRVCC procedure can be applied to the terminal and hence to the
subscriber.
If the subscriber is entitled for SRVCC based on STN-SR information, radio access
change is required based on the measurement reports, and also a real-time bearer
exists, the MME triggers the SRVCC procedure for the voice component with
the MSS enhanced for SRVCC over the Sv interface.

SRVCC Function
The MSS enhanced for SRVCC coordinates the SRVCC procedure with the CS
handover procedure.
The MSS enhanced for SRVCC can reserve the target cell resources from 2G/3G
access in the same MSS or with an inter-MSS handover from a target MSS.
The MSS enhanced for SRVCC also initiates the session transfer procedure to
the Voice Call Continuity anchoring point. The anchoring point is responsible for
the session continuity from PS to CS bearer. For facilitating session transfer of the
voice component to the CS domain, IMS multimedia telephony sessions need to be
anchored in the IMS and in the Service Centralization and Continuity Application
Server (SCC AS).
In the Nokia Siemens Networks VoLTE solution, the SCC AS function resides in the
NVS.
The MSS enhanced for SRVCC then sends PS to CS handover response to the
MME, which includes the necessary CS handover command information for the UE
to access UTRAN/GERAN.

SRVCC Function
Handling of any non-voice PS bearer is managed by the PS bearer

splitting function in the MME.
The MME starts the handover of non-voice PS bearer during the SRVCC
procedure based on the information received from E-UTRAN.
The handover of non-voice PS bearers, if performed, is done according to
Inter RAT handover procedure as defined in 3GPP TS 23.401.
The MME is responsible for coordinating the Forward Relocation Response
from SRVCC and PS handover procedure.

PS to CS SRVCC relocation/handover to MSS(SRVCC) UTRAN/GERAN
(1) User Plane termination reserved from target MGW

for A/Iu resource towards target BSC/RNC
(2) User Plane

termination reserved
from anchor MGW for
outgoing Call Control
leg towards IMS (this
is anchor termination
for whole SRVCC
call).
(3) User Plane through connection for speech path !

PS to CS SRVCC relocation/handover to target MSS UTRAN/ GERAN
(1) User Plane termination reserved

from target MGW for A/Iu resource
(2) User Plane
towards target BSC/RNC
termination reserved
from anchor MGW for
outgoing resource
towards Target MSS
(this is target leg
(3) User Plane termination reserved
termination)
(4) User Plane from target MGW reserved for incoming
termination reserved Call Control leg.
from anchor MGW for
outgoing Call Control
leg towards IMS (this
is anchor termination
for whole SRVCC
call).
Note1. Steps (1), (2) and (3) are

always repeated if the UE
continues the movement to next
target MSS with subsequent
Inter-MSS handovers/relocations.
Note2. In case of SIP between

(5) User Plane through connection
MSS(SRVCC)
for speech path ! and Target MSS(CC call leg), the SIP
messages (INVITE/200 OK/ACK) are
used instead of ISUP/BICC messages
(IAM/ACM/ANSWER).

Failure before SRVCC PS to CS Response

Failure after SRVCC PS to CS Response

Location update rejected after successful SRVCC handover
(or call is continued, see below)
Procedure:
1.The MSS (SRVCC) starts a Location Update procedure.

2.The Location Update is rejected.
3.As a result, depending on the operator settings, the call is either cleared (DISCONNECT to UE)
or the call will be continued (CALLINT parameter setting):
Modify the Sv parameter set with EJN command to the required value if needed.
ZEJN:MODIFY:TYPE=SV,PNAME=<parameter set name>:CALLINT=<YES/NO>;
Note. If the call is not cleared, the supplementary services (for example, call waiting) can
not be supported by the MSS (SRVCC).

SRVCC handover using TFO/WB-AMR

SRVCC handover using TrFO/WB-AMR

Other supported procedures with SRVCC
• TMSI reallocation with SRVCC

1. The SRVCC handover procedure is successful.
2. The MSS enhanced with SRVCC performs a location update procedure.
• The IMSI is unknown to the MSS/VLR.
• The MSS(SRVCC) performs a TMSI reallocation procedure toward the UE
using a nonbroadcast LAI and its own NRI if the MSS(SRVCC) and other
MSS/VLRs serve the same (target) LAI.
• MAP Update Location is sent to the HLR after the TMSI reallocation procedure.
• Signalling unit reset
1. The Sv interface UDP/IP control plane connection is established between the EMSS
and the MME.
2. Spontaneous reset of the signalling unit can happen in the MSS(SRVCC) in the
following scenarios:
• while the Sv interface is established between the MSS(SRVCC) and the MME
• during an ongoing SRVCC handover procedure
Note 1: All ongoing active procedures/dialogs are aborted in the unit under reset.
Note 2: After the reset, the Sv interface connection is established between the MSS(SRVCC) and the MME.

• Signalling unit switchover

1. The Sv interface UDP/IP control plane connection is established between
the EMSS and the MME.
2. Switchover of the signalling unit in the MSS(SRVCC) can happen in the
following scenarios:
• while the Sv interface is established between the MSS(SRVCC) and the MME
• during an ongoing SRVCC handover procedure
Note 1: The new active signalling unit takes over all ongoing active procedures/dialogs after the switchover.
Note 2: The new active signalling unit takes over the Sv interface connection between the EMSS
and the MME after the switchover.

Supplementary Services with SRVCC
• All traditional 2G/3G related Supplementary Services are

supported but those are applicaple only after the successful
SRVCC procedure (after successful LU procedure generated by
MSS in the end of SRVCC procedure completion).

SRVCC in Pool concept
Location update and TMSI reallocation in MSS configurations
LAI of SRVCC default SAI is configurable with the EJN command.

Non-broadcast LAI is configurable with the E3E command.
Both LAI part of SRVCC default SAI and non-broadcast LAI must be defined
in the MSS radio network configuration but cannot be identical to any real
radio network LAI.

Statistics with SRVCC
Traffic category measurement report (20/14H)
• Traffic category “SRVCC originating calls” is included in the measurement.
Handover measurement report, part 1 (81/51H)

• The SRVCC procedures and their success ratio are included in the handover measurement
report.
VLR measurement report (82/52H)

• The SRVCC Location update procedure initiated in the MSS(SRVCC) is included separately in
the VLR measurement. The following two counters are introduced:
• Number of attempted SRVCC Location Update procedures
• Number of successful SRVCC Location Update procedures
Destination measurement reports (17/11H, 24/18H, 25/19H, 385/181H)

• The reports display STN-SR number as destination number in the MSS(SRVCC). The layout of these
measurements is unchanged.
MSC observation report (96/60H)

• The MSC Observation report can indicate if the call is coming from LTE to GSM/UMTS
access using SRVCC. The MME IP address initiating the SRVCC procedure is also
available in the MSC Observation report.

Statistics with SRVCC
Handover observation report (97/61H)

• The Handover observation report includes:
• SRVCC-related values in Handover Type field:
• SRVCC TO MSS(SRVCC) GSM/UMTS
• SRVCC TO TARGET MSS GSM/UMTS
• MME address
The report includes the IP address of the MME initiating the SRVCC procedure.
Location update observation report (90/5AH)
• The Location update observation report (90/5AH) includes
• SRVCC-related value SRVCC LOCATION UPDATE in location update type field
• The MME IP ADDRESS field displays the address of MME initiating the SRVCC procedure.
For more information on statistical reports, see NSS Statistics, Reports.
For more information on counters, consult the Reference Information Services portal of
Product Information Center (PIC).

Charging with SRVCC
MGW SCP
RNC
CDR
MSS
(SRVCC)
Orinating/
CDR
BSC MGCF HLR Terminating
CDR network
P/I/S-
eNB HSS
CSCF
MME NVS/SCC-
SCP
AS
PCRF CDR TDM
SAE-GW TDM/IP
IP MGW
MGW
SR-VCC signalling in LTE (before SRVCC)
SR-VCC signaling in CS (after SRVCC)
User plane before SRVCC
User plane after SRVCC
Charging with SRVCC
• TO BE NOTE: The main control of charging is in IMS side (in where the voice call was
anchored) !! The following describes only the SRVCC related charging actions in MSS side with
SRVCC.
The following CDR fields have been modified to increment SRVCC functionality:
• CALL_TYPE
• The field contains the type of the call.
• The field has been extended with the following value:
14 Voice Call Continuity
• The field is available in MOC, MTC, FORW, ROAM, SMMO, SMMT, POC, PTC, PBXO, PBXT, DOC,
RCC, SMMF, SOC, STC, SOM, and STM CDRs.
• LOC_UP_INDICATOR
• The field indicates the type of location update.
• The field has been extended with the following values:
00H Location update
01H GPRS location update (Note. This value is valid only in CDRs generated by the HLR.)
02H Location update due to Voice Call Continuity . (Note. This value is valid only in CDRs generated by the
MSS/VLR, and is only available if Feature 2008:
SRVCC Support in MSS is activated.)
The field is available in LOCA and SIPR CDRs

Charging with SRVCC
• MME_IP_ADDRESS
• The field contains the IP address of the Serving MME.
• If the CDR is generated due to Tracking Area Update, the field
contains the IP address of the target MME.
• If the CDR is generated due to SRVCC, the field contains the IP
address of the MME which initiating the SRVCC procedure.
• The field is available in LOCA CDR.
For more information on CDRs and charging, see CDR Field Descriptions in
M16.1 and Charging, Functional Area Description.

3GPP SRVCC specifications
(Relevant for MSS)
• TS 23.216 – Rel 8 
– Single Radio Voice Call Continuity (SRVCC); Stage 2
• TS 29.280 – Rel 8 
– Evolved Packet System (EPS); 3GPP Sv interface (MME to MSC, and
SGSN to MSC) for SRVCC
• TS 29.274 – Rel 8 
– 3GPP Evolved Packet System (EPS); Evolved General Packet Radio
Service (GPRS) Tunneling Protocol for Control plane (GTPv2-C);
Stage 3

Standardization steps with SRVCC
• Rel-8 – Officially part of GSMA IR.92 – current baseline
– All basic SRVCC functionality (PS->CS domain transfer) for single active call
• Rel-9 – Commercial pressure increasing to have this as soon as possible… similarly as with CSFB
– Support for PS->CS domain transfer for active and held calls in stable state
– Calls in alerting phase are discontinued
– Mid-call assisted call transfer
▪ MSC Server assisted mid-call feature can only be triggered if UE, MSC Server, and SCC AS support the MSC Server
assisted mid-call feature
▪ Requires “M-AGCF”/ICS enhanced MSC server functionality in network element that performs SRVCC role
• Rel-10
– Enhancement for SR-VCC performance by implementation of media anchoring in serving network with “Visited Access
Transfer Functionality (VATF)”
▪ Co-located in visited/home P-CSCF to anchor media plane with “GW” functionality
– Support for video telephony PS->CS->PS domain transfer (vSR-VCC)
– Support for alerting phase domain transfers
• Rel-11
– Support for CS->PS domain transfer (rSR-VCC)
Rel-10 functionality is the first release to meet the existing functionality of mobile CS networks!
• SRVCC defined also for VoIP/HSPA->CS (Rel8) and vice versa (Rel10) but that business need for that
functionality is unclear

Changes with Sv interface connectivity in M17.0 
Sv interface using IPDU Load Balancer
EMB xSU-0
UDP/IP link 1
xSU-1
IPDU-0
xSU-2
UDP/IP link 2
xSU-3
UDP/IP
link 3
xSU-4
IPDU-1
…
UDP/IP link n
xSU-n
IPDU is N+1
redundant LinDX
Ethernet port (EL4 / EL5)
based unit.


SRVCC

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRVCC

Uploaded by

Copyright:

Available Formats

SRVCC – Single Radio Voice Call Continuity

1. VoLTE and NSN Implementation

For public use – IPR applies

For public use – IPR applies

• More than 100 operators have

• Lower latency Latency Latency

• Better spectral efficiency GSM/EDGE

• New spectrum HSPA

• E2E All-IP flat architecture

“capacity bands”: carriers up to 20MHz DSL (~20- 50 ms, depending on operator)

Bandwidth New and large bands:

For public use – IPR applies

Voice over LTE is mandatory

Fast Track • Works on top of NSN’s mobile switching system MSS

For public use – IPR applies

SMS over LTE connection, LTE Broadband VoIP

Dual radio terminals for CDMA /LTE operators

MSS SR CS FallBack to 2G/3G

2010 2011 2012 2013

NSN introduces 3GPP IR.92 VoLTE capability

LTE and an all-IP transport network simplifies the core

For public use – IPR applies

For public use – IPR applies

MSS IMS SR 5.0 Products and Functions SCP

TAS/MMTel IP-SM- HLR

SGs,S PCRF HSS FE Legend

For public use – IPR applies

MSC Server System Program (MSS SR) – IMS and LTE

CSCF/ MSS/ PCRF EPC Radio

For public use – IPR applies

For public use – IPR applies

Exploring the differences between

For public use – IPR applies

For public use – IPR applies

• Initially, there will only be Hot Spot Coverage:

For public use – IPR applies

2. No VoIP/LTE, but fallback to 2G/3G CS:

3. VoLGA formerly known as “CS over PS” (dead):

For public use – IPR applies

• Support in NSN MSC Server:

Voice calls SMS

For public use – IPR applies

6. the CS Voice Call is delivered

LTE Cell eNB MME PDN-GW

1. UE performs Combined Attach (EPS/CS)

For public use – IPR applies

• Based on Unlicensed Mobile

For public use – IPR applies

For public use – IPR applies

Provide standard interfaces Provide Unchanged interfaces

For public use – IPR applies

– 3GPP interfaces supported:

Sv, Gm, H.248

Mobile Broadband Access

• the current 3GPP standards for Voice over LTE give

2. No VoIP/LTE, but fallback to 2G/3G CS:

3. VoLGA formerly known as “CS over PS”:

For public use – IPR applies

For public use – IPR applies

SRVCC FN2008 is available for

Feature code of license

For public use – IPR applies

• E-UTRAN (4G) access together with EPC will provide Packet