Lte To GSM Handover (SRVCC)

LTE to GSM Handover (SRVCC)
FUNCTION SPECIFICATION
Y
R
A
IN
IM
EL
PR
58/155 17-CSA 121 01/9 Uen PA17

Copyright
© Ericsson GmbH 2015. All rights reserved. No part of this document may be
reproduced in any form without the written permission of the copyright owner.
Disclaimer
The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use
Y
of this document.
R
Trademark List
All trademarks mentioned herein are the property of their respective owners.
A
These are shown in the document Trademark Information.
IN
IM
EL
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Contents
Contents
1 Revision Information 1
2 Overview 3
3 Function 7
Y
3.1 General 7
R
3.2 Traffic Handling 11
3.3 Interaction with Other Functions 75
A
4 Operational Conditions 91
4.1 Operation and Maintenance Reference Information 91
4.2
4.3
5
Charging
Capabilities IN
Appendix 1 - Example Call Flow
93
95
97
IM
Glossary 99
Reference List 103

EL
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Y
R
A
IN
IM
EL
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Revision Information
1 Revision Information
Changes in MSC 16A
This document is based on LTE to GSM Handover (SRVCC),

58/155 17-CSA 121 01/7 Uen, Rev. B.
Y
Other than editorial changes, this document has been revised as follows:
• Rev. A
R
0 LTE to GSM Handover (SRVCC)
• Support of SRVCC for originating call in pre-alerting state.
A
• Removal of the AXE customer parameter SRVCCALERTENBL.
‘‘SRVCC for call in alerting state’’ function becomes a basic part
of the feature.
IN
• The optional feature ‘‘Support of interworking with MMTel/IMS’’
becomes prerequisite of optional feature ‘‘LTE to GSM Handover
(SRVCC)’’.
• Handling of DTAP CONNECT and bothway through connection for
IM
a terminating call in alerting state is changed.
• Support of type 1 ‘‘orig-ioi’’ in P-Charging-Vector header for
session transfer to IMS.
• Support of SRVCC for a held call.
EL
• Support of SRVCC for active conference call.
Changes in MSC 14B

PR
This is a new document created for feature ‘‘LTE to GSM Handover (SRVCC)’’
in MSC 14B.
Other than editorial changes, this document has been revised as follows:
• Rev. B
0 Documentation Improvement
• Description of AXE customer parameter TMSILAIMSC has been
corrected.
• Rev. A
0 LTE to GSM Handover (SRVCC). This is a new document.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 1

Y
R
A
IN
IM
EL
PR
2 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Overview
2 Overview
The function ‘‘LTE to GSM Handover (SRVCC)’’ performs a handover of a call,

which is anchored in IMS and uses a single radio channel, from LTE access
to circuit switched GSM access. The UE which is changing the access from
LTE to GSM can be involved in two calls in PS domain before the initiation of
LTE to GSM handover.
Y
LTE to GSM Handover (SRVCC) is applicable for the following traffic cases:
R
• Active call (including emergency calls)
• Active conference call
A
• Held call
•
IN
Originating call in alerting state
Terminating call in alerting state
Originating call in pre-alerting state

IM
The operator can use ‘‘LTE to GSM Handover (SRVCC)’’ to provide voice call
continuity to the subscriber when changing from LTE access to circuit switched
GSM access.
EL
Two handover scenarios are possible, dependent on if the target cell, indicated
by the Target Cell ID, received by the MSC-S from the MME, for the voice call
to be handed over belongs to the MSC-S or a Neighboring MSC-S, as shown in
<PLACEHOLDER> and <PLACEHOLDER>, respectively.
PR
‘‘LTE to GSM Handover (SRVCC)’’ is applicable to the following access types:

GSM, LTE.
‘‘LTE to GSM Handover (SRVCC)’’ is applicable to the following

telecommunication standards: ANSI, ETSI/ITU-T, CCSA.
External Protocols
• BICC or ISUP
• BSSAP
• IPv4
• MAP version 2
• MAP version 3
• SIP
• Sv-Interface Protocol for SRVCC based on GTPv2-C
Prerequisites
• The feature ‘‘LTE to GSM Handover (SRVCC)’’ is available.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 3

• The feature ‘‘MGCF for Interworking with IMS’’ is available and active.
• The feature ‘‘WCDMA to GSM Handover’’ is available and active.
• The feature ‘‘Support of Interworking with MMTel/IMS’’ is available and
active.
• The feature ‘‘Positioning’’ is available and active.
Y
LTE
eNodeB GMLC HLR
R
S1-MME
Lg D
A
Sv
EPC
MSC-S/
MME MGCF A
Mw Mc/Mn
IN BSC
GSM
IM
A
IMS Mb
CSCF/
ATCF or MGW1
MGW
EATF
EL
Interface
Signaling
User Plane
Figure 1 Handover Scenario - Target Cell Belongs to MSC-S Supporting
the Sv-Interface
PR
4 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Overview
LTE
eNodeB GMLC HLR
S1-MME
Lg D
Y
Sv E
EPC
MSC-S/ Neighboring
MME MGCF MSC-S A
R
Mw Mc/Mn Mc
GSM
BSC
A
A
IMS Mb Nb
CSCF/
ATCF or MGW1 MGW2
MGW1
EATF
Interface
Signaling
IN
IM
User Plane
Figure 2 Handover Scenario - Target Cell Belongs to Neighboring MSC-S
Table 1 Lists the protocols used by the MSC-S, which correspond to the
interfaces shown in Figure 1 and Figure 2.
EL
Table 1 Overview of Interfaces and Protocols

Interface Protocol
A BSSAP
PR
D MAP V2 and V3
E MAP V2 and V3, BICC or ISUP
Lg MAP V2 and V3
Mc/Mn GCP
Mw SIP
Sv Sv-Interface protocol, based on
GTPv2-C
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 5

LTE to GSM Handover (SRVCC) Documentation Overview
Table 2
Function Specifications Procedural Information
LTE to GSM Handover (SRVCC) Sv-Interface Configuration and
Enabling of Single Radio Voice Call
Continuity
Sv-Interface, General Aspects, LTE to GSM Handover (SRVCC),
Y
Message Formats and Coding for Activate
SRVCC
PS to CS SRVCC for Additional Call LTE to GSM Handover (SRVCC),
R
Deactivate
A
IN
IM
EL
PR
6 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
3 Function
3.1 General
In the context of this document, the term:
• SRVCC Procedure refers to LTE to GSM Handover, including the handover
Y
of the radio access, the IMS session transfer of a single or first call, and
optional TMSI allocation and Location Update towards HLR.
• Handover refers to setting up the radio access in the circuit switched (CS)
R
radio domain by the MSC-S due to LTE to GSM Handover (SRVCC)
towards the target BSC. It comprises both, intra-MSC and inter-MSC
handover. For a detailed description of the Handover functions, refer to the
A
Function Specification UMTS to GSM Handover in MSC/VLR Server.
• Target BSC refers to the BSC to which the target cell belongs. This BSC
IN
can be controlled by the own MSC-S or by the Neighboring MSC-S. The
target cell is identified by the Target Cell ID Information Element (IE)
included in the SRVCC PS TO CS REQUEST message received from the
MME.
IM
• MSC-S state refers to the state of mobile access side.
EL
The function ‘‘LTE to GSM Handover (SRVCC)’’ uses the Sv-Interface protocol
for SRVCC, based on GTPv2-C, over UDP transport, for the communication
between the MSC-S and the MME. For a detailed description of the Sv-Interface
protocol refer to the Function Specification Sv-Interface, General Aspects,
Message Formats and Coding for SRVCC. For a detailed description of
the GTPv2-C protocol refer to the Function Specification GTP-C, Signaling
PR
Transport and to the Function Specification GTPv2-C, General Aspects,

Formats and Codes.
The MME is represented as Remote Host in the MSC-S and is connected to an

Area Cluster associated to a Service Area Identity (SAI). It is connected also to
a local UDP socket. For a detailed description of the administration of MMEs
and local UDP sockets in the MSC-S refer to the Function Specification Generic
Transport Function, Traffic, Administration and Maintenance.
For a detailed description of the Area Cluster Administration function, refer to

the Function Specification Area Cluster Administration in MSC/VLR Server. For
a detailed description of the administrative needs of the ‘‘LTE to GSM Handover
(SRVCC)’’ feature, refer to the User Guide Sv-Interface Configuration and
Enabling of Single Radio Voice Call Continuity.
Figure 3 provides an overview of the logical parts of the SRVCC Procedure

and their connections, excluding the interactions between MSC-S and MGW.
The interactions between MSC-S and MGW are described in Section 3.2.17
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 7

on page 48. The procedure progresses from the top of the figure towards the
bottom. Arrows show a sequence of the parts of the procedure.
All blocks in Figure 3 represent a logical part of the SRVCC Procedure. A

logical part needs to be finished before moving on to the next block, since the
last message in one logical part is the trigger for the next logical part, that is the
block from which the arrow starts must be finished, before certain actions are
possible in the block to which the arrow points. More than one arrow leaving
a block indicates the start of the logical parts in parallel, except in case of the
colored arrows. Colored arrows leaving a block indicate the start of alternative
Y
logical parts meaning that only one of these different traffic cases will be
processed as part of a SRVCC Procedure. Dashed arrows are not regarded
as main triggers, that is the block from which the arrow starts must be finished
R
before certain actions are possible in the block to which the arrow points.
Differences for SRVCC Procedure for Emergency Calls are described in
A
Section 3.2.18 on page 70.
IN
IM
EL
PR
8 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Y
R
A
IN
IM
EL
PR
Figure 3 General Flow of SRVCC Procedure
The following subsections correspond to the blocks shown on the figure above.
All subsections include a figure with the detailed flow of messages and
description of the part of the procedure.
Messages triggering the given part of the procedure are shown on the figures
(including interactions between MSC-S and MGW). If the subprocedure is
different depending on whether the target cell belongs to the MSC-S or
a Neighboring MSC-S, the subsections are split in order to describe the
differences.
The SRVCC Procedure consists of the following steps:
• Initiation of SRVCC, see Section 3.2.1 on page 11
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 9

• Handover Request, see Section 3.2.2 on page 11
• Response to MME, see Section 3.2.3 on page 15
• IMS Session Transfer, see Section 3.2.4 on page 16
• Handover Completion, see Section 3.2.5 on page 24
• SRVCC Complete Notification to MME, see Section 3.2.6 on page 26
Y
• TMSI Allocation (conditional), see Section 3.2.7 on page 28
• Location Update towards HLR (conditional), see Section 3.2.8 on page 31
R
The following additional steps are needed for the continuation of the service:
A
• Alerting for originating call in pre-alerting state (conditional), see Section
3.2.10 on page 35
•
IN
Call Acceptance for call in alerting state or originating call in pre-alerting
state (conditional), see Section 3.2.11 on page 36
Reception of Conference Call Information (conditional), see Section 3.2.12

IM
on page 41
The following additional step might be needed based on configuration option

for emergency calls:
EL
• Location Continuity (conditional), Section 3.2.18.7 on page 72
The following additional step may conditionally be applied during the SRVCC
Procedure:
PR
• Status Enquiry Procedure, see Section 3.2.9 on page 32
In addition, dedicated sections describe the followings:

• Conference Control after SRVCC transfer, see Section 3.2.13 on page 42
• Request from the MME to cancel an ongoing SRVCC Procedure, see
Section 3.2.14 on page 44
• Interactions between requests for SRVCC Procedure, see Section 3.2.15
on page 45
• Rejection of Requests for SRVCC Procedure by MSC-S, see Section
3.2.16 on page 45
• Interactions between MSC-S and MGW, see Section 3.2.17 on page 48
Note: In the following sections, in all figures, the messages displayed as red
lines represent the triggers for the specific part of the message flow.
SDP is not shown in the figures for the sake of simplicity. SIP PRACK
and SIP 200 OKPRACK messages shown are only send by MSC-S if
SIP 18x provisional response from IMS is sent reliably. Reliability of
provisional responses is supported on Mw interface.
10 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
3.2 Traffic Handling
3.2.1 Initiation of SRVCC

As shown in Figure 4, the MSC-S starts the SRVCC Procedure upon reception
of the Sv-Interface protocol SRVCC PS TO CS REQUEST message from the
MME, including a target cell for the voice call to be handed over. It uses the
International Mobile Subscriber Identity (IMSI) received in the Sv-Interface
protocol SRVCC PS TO CS REQUEST message to identify the subscriber
Y
for whom the SRVCC Procedure is requested. If the subscriber was not
registered in VLR before the reception of Sv-Interface protocol SRVCC PS TO
CS REQUEST message, the subscriber is registered in VLR.
R
MME Sv-Interface Protocol MSC-S
A
SRVCC PS TO CS REQUEST
Figure 4
IN
Reception of SRVCC PS TO CS REQUEST
IM
The MSC-S receives a set of security information, which is equivalent to a GSM
security context, the Tunnel Endpoint Identifier for Control Plane (TEID-C) of
the MME and an MME IP address to be used as destination IP address for a
EL
later Sv-Interface SRVCC PS TO CS COMPLETE NOTIFICATION message.

For a detailed description of the data received from the MME, refer to the
Function Specification Sv-Interface, General Aspects, Message Formats and
Coding for SRVCC.
PR
3.2.2 Handover Request

After the reception of the Sv-Interface protocol SRVCC PS TO CS REQUEST
message from the MME, the MSC-S triggers the seizure of the bearer
terminations, described in Section 3.2.17 on page 48.
The MSC-S also triggers the handover, as described below.
Handover Scenario 1: Target Cell Belongs to MSC-S
As shown in Figure 5, the MSC-S initiates an Intra-MSC Handover if the target

cell belongs to the MSC-S. For a detailed description of the WCDMA to GSM
Handover, refer to the Function Specification UMTS to GSM Handover in
MSC/VLR Server. However, as the handover performed does not originate
in an RNC of a circuit switched WCDMA network, but in a packet switched
access, the interactions between the source RNC and the MSC/VLR Server
described in the Function Specification UMTS to GSM Handover in MSC/VLR
Server are not applicable to SRVCC.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 11

Sv-Interface Protocol BSSMAP

Target
MME MSC-S
BSC
SRVCC PS TO CS REQUEST
HANDOVER
REQUEST
HANDOVER
REQUEST
ACKNOWLEDGE
Y
Figure 5 Handover Request
R
The MSC-S populates the BSSMAP HANDOVER REQUEST message with
the information from the Sv-Interface protocol SRVCC PS TO CS REQUEST
message as described in Table 3:
A
Table 3 Mapping of Information between Sv-Interface Protocol SRVCC PS
TO CS REQUEST Message and BSSMAP HANDOVER REQUEST
Message
Sv-Interface Protocol SRVCC PS
TO CS REQUEST
IN BSSMAP HANDOVER REQUEST
IM
IMSI IMSI
MM Context for E-UTRAN Classmark Information Type 2
SRVCC
Classmark Information Type 3
EL
(1)
MM Context for E-UTRAN Encryption Information
SRVCC (CKSRVCC - IKSRVCC)
Source to Target Old BSS to New BSS
Transparent Container Information
Target Cell ID
PR
Target Cell Identifier

(1) C3 Conversion function, for more information, refer to Function Specification Mobile
Subscriber Related Security Functions in MSC/VLR Server.
In addition, BSSMAP HANDOVER REQUEST message sent to the target BSC is

also populated with the following parameters:
• Uplink quality is included in the Cause field of the BSSMAP

HANDOVER REQUEST message.
• Speech is included in the Channel Type field of the BSSMAP HANDOVER

REQUEST message.
• IP is included in the supported bearer of Codec List field of the BSSMAP

HANDOVER REQUEST message, if A-Interface over IP is used.
• Default SAI administered on the Area Cluster is included in the Serving

Cell Identifier field of the BSSMAP HANDOVER REQUEST message.
12 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
A list of supported codecs is received in the Sv-Interface protocol SRVCC PS

TO CS REQUEST message from the MME. When functions Out of Band
Transcoder Control (OoBTC) and AMR-WB are not activated, MSC-S performs
telecommunication service analysis on this list and selects the codecs, which
are sent to target RAN. For the codec selection when OoBTC is activated refer
to Function Specification Out of Band Transcoder Control in MSC Server,
GMSC Server and TSC Server and when AMR-WB is activated refer to
Function Specification Support of AMR-WB Speech Codec.
For a detailed description of the sending of the BSSMAP message, refer to
Y
the Function Specification UMTS to GSM Handover in MSC/VLR Server and
to the Function Specification A-Interface, Section H: Base Station System
Management Application Part, BSSMAP Message Formats and Coding.
R
Handover Scenario 2: Target Cell Belongs to Neighboring MSC-S
A
As shown in Figure 6, the MSC-S initiates an Inter-MSC Handover if the
target cell received in the Sv-Interface protocol SRVCC PS TO CS REQUEST
IN
message belongs to a Neighboring MSC-S or Neighboring MSC Group.
For a detailed description of the WCDMA to GSM Handover and the

administration of Outer Cell, refer to the following Function Specifications:
IM
• UMTS to GSM Handover in MSC/VLR Server
• Inter-MSC Handover/Relocation to MSC Pool

EL
However, as the handover performed does not originate in an RNC of a circuit

switched WCDMA network, but in a packet switched access, the interactions
between the source RNC and the MSC/VLR Server described in the Function
Specification UMTS to GSM Handover in MSC/VLR Server, are not applicable
to SRVCC.
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 13

Sv-Interface
Protocol MAP Neighboring BSSMAP
Target
MME MSC-S MSC-S BSC
SRVCC PS TO
CS REQUEST
PREPARE
HANDOVER
request
HANDOVER
REQUEST
Y
HANDOVER
REQUEST
ACKNOWLEDGE
R
PREPARE
HANDOVER
response
A
Figure 6
IN
Handover Request, Neighboring MSC-S Scenario
The population of BSSMAP messages based on Sv-Interface protocol

messages is done as described for Case 1 on Page 11. However, in this case
IM
the BSSMAP messages are encapsulated in MAP messages for being sent
between the MSC-S and the Neighboring MSC-S with MAP Version 2 (MAPV2)
or MAP Version 3 (MAPV3). For a detailed description of the encapsulation,
refer to the Function Specification UMTS to GSM Handover in MSC/VLR Server
and to the Function Specifications Signalling System No.7, Mobile Application
EL
Part Version 2 for Inter-MSC Handover in MSC/VLR Server, and Signalling

System No.7, Mobile Application Part Version 3 for Inter-MSC Handover in
MSC/VLR Server,.
If MAP Version 2 (MAPV2) is used, the MSC-S populates the MAP PREPARE
PR
HANDOVER request message, carrying the BSSMAP HANDOVER REQUEST

message, with information from the Sv-Interface protocol SRVCC PS TO CS
REQUEST message as described in Table 4.
Table 4 Mapping of Information between Sv-Interface Protocol SRVCC PS

TO CS REQUEST Message and MAP PREPARE HANDOVER
Request Message with MAPV2
Sv-Interface Protocol SRVCC PS
TO CS REQUEST MAP PREPARE HANDOVER Request
Target Cell ID Target Cell ID
If MAP Version 3 (MAPV3) is used, the MSC-S populates the MAP PREPARE
HANDOVER request message, carrying the BSSMAP HANDOVER REQUEST
message, with information from the Sv-Interface protocol SRVCC PS TO CS
REQUEST message as described in Table 5:
14 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Table 5 Mapping of Information between Sv-Interface protocol SRVCC PS

TO CS REQUEST Message and MAP PREPARE HANDOVER
Request Message with MAPV3
Sv-Interface Protocol SRVCC PS MAP PREPARE HANDOVER Request
TO CS REQUEST
Target Cell ID Target Cell ID
IMSI IMSI
MM Context for E-UTRAN Integrity Protection
Y
(1)
SRVCC (IKSRVCC) Information
(1)
MM Context for E-UTRAN Encryption Information
R
SRVCC (CKSRVCC)
(1) C3 Conversion function, for more information, refer to Function Specification Mobile
Subscriber Related Security Functions in MSC/VLR Server.
A
When OoBTC and AMR-WB are not activated, the Neighboring MSC-S sends
the received, in MAP PREPARE HANDOVER request message, codecs towards
the RAN.
IN
For the codec selection when OoBTC is activated refer to Function Specification
Out of Band Transcoder Control in MSC Server, GMSC Server and TSC Server
IM
and when AMR-WB is activated refer to Function Specification Support of
AMR-WB Speech Codec
3.2.3 Response to MME

EL
This section describes the response sent by the MSC-S to the MME.
Handover Scenario 1: Target Cell belongs to MSC-S

PR
As shown in Figure 7, after receiving the BSSMAP HANDOVER REQUEST

ACKNOWLEDGE from the Target BSC, MSC-S replies to the MME by sending an
Sv-Interface protocol SRVCC PS TO CS RESPONSE message.
VC PTOEQUMvE
- QI O
I vI n t VVS e -
f MQaEO
SSR S Vr V
c or
l e o BA g Rc
c RHNRVf
e r Do A K WRBL R
Vc g r r G
- VG
fA
r VG
c RV- A o VR
Figure 7 Response to MME
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 15

The MSC-S populates the Sv-Interface protocol SRVCC PS TO CS RESPONSE

message with the information from the BSSMAP HANDOVER REQUEST
ACKNOWLEDGE message as described in Table 6.
Table 6 Mapping of Information between BSSMAP HANDOVER REQUEST

ACKNOWLEDGE Message and Sv-Interface protocol SRVCC PS
TO CS RESPONSE
BSSMAP HANDOVER REQUEST Sv-Interface Protocol SRVCC
ACKNOWLEDGE PS TO CS RESPONSE
Y
Layer 3 Information Target to Source
Transparent Container
R
In addition, the MSC-S allocates an own TEID-C being unique for one SRVCC
Procedure and includes it in the MSC Server Sv TEID for Control
A
Plane field of the Sv-Interface protocol SRVCC PS TO CS RESPONSE
message.
IN
The MSC-S is prepared to retransmit the sent Sv-Interface protocol SRVCC
PS TO CS RESPONSE message for a configured period of time, in case the
Sv-Interface protocol SRVCC PS TO CS REQUEST message which initiated
the ongoing SRVCC Procedure is received again. For a detailed description
IM
of this retransmission time period, refer to the Function Specification GTP-C,
Signaling Transport.

EL
Apart from the differences specified below, the response to MME is sent as
described in Page 15.
In this case the MSC-S replies to the MME by sending an Sv-Interface protocol
PR
SRVCC PS TO CS RESPONSE message after having received a BSSMAP

HANDOVER REQUEST ACKNOWLEDGE message encapsulated in a MAP
PREPARE HANDOVER response message and either a BICC or ISUP ADDRESS
COMPLETE message (ACM) or a BICC or ISUP CONNECT message (CON) from
the Neighboring MSC-S, as shown in Figure 8.
Sv-Interface
MME Protocol MSC-S BSSMAP Neighboring
BICC or ISUP MSC-S
PREPARE
HANDOVER
response
ACM or CON
SRVCC PS TO
CS RESPONSE
Figure 8 Response to MME, Neighboring MSC-S Scenario
16 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
3.2.4 IMS Session Transfer

This section describes the session transfer towards the IMS network, initiated
by the MSC-S.
MSC-S sets the transaction identifier to 0 and TI flag value as in terminated call
for a single or first call subject to SRVCC procedure.
3.2.4.1 Handover Scenario 1: Target Cell Belongs to MSC-S
Y
The reception of the BSSMAP HANDOVER REQUEST ACKNOWLEDGE message
triggers the MSC-S to initiate the session transfer towards the IMS network,
R
based on the B-number analysis of the Session Transfer Number for SRVCC
(STN-SR). The B-Number Origin (BO) used in the analysis function is derived
from IMSI series analysis. The Routing Origin (RO) used in the analysis function
A
is determined by the configuration of target cell. The SIP route associated to
trusted domain (TRUSTPL route parameter) is used for session transfer to IMS.
Session Transfer to IMS is initiated by sending a SIP INVITE message. MSC-S
IN
populates the SIP INVITE message with the information from the Sv-Interface
protocol SRVCC PS TO CS REQUEST message as described in Table 7. For
more information on the presence of below IEs in the Sv-Interface protocol
SRVCC PS TO CS REQUEST, refer to Function Specification Sv-Interface,
IM
General Aspects, Message Formats and Coding for SRVCC.
Table 7 Mapping of information between Sv-Interface protocol SRVCC PS

TO CS REQUEST Message and SIP INVITE Message
(1)
EL
Sv-Interface Protocol SRVCC PS SIP INVITE

TO CS REQUEST
(2)
C-MSISDN From header
P-Asserted-Identity header
PR
STN-SR To header
Request-URI
(1) E.164 numbers ported in SIP headers are transferred by SIP in global number format.
(2) The C-MSISDN is treated as calling party number. For a detailed description of the population
of the From header, refer to the Function Specification Session Initiation Protocol .
In addition to the mapped data from the Sv-Interface protocol SRVCC PS

TO CS REQUEST message, the MSC-S includes specifically for SRVCC
the following headers and parameters shown in Table 8 in the SIP INVITE
message.
Table 8 Additional Headers and Parameters in SIP INVITE Message

Header Parameter
Allow INFO
(1)
REFER
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 17

Header Parameter
Accept application/vnd.3gpp.state-
and-event-info+xml
application/vnd.3gpp.mid-ca
ll+xml
(2)
Contact +g.3gpp.icsi-ref="urn%3A
urn-7%3A3gpp-service.ims
.icsi.mmtel“; +g.3gpp.srv
Y
cc-alerting;+g.3gpp.ps2cs
-srvcc-orig-pre-alerting;
+g.3gpp.mid-call
R
Accept-Contact +g.3gpp.icsi-ref="urn%3Aurn
-7%3A3gpp-service.ims.icsi.
mmtel"
A
(3)
P-Asserted-Service urn:urn-7:3gpp-service.ims.
icsi.mmtel
Recv-Info
Supported
IN+g.3gpp.state-and-event;
+g.3gpp.mid-call
norefersub
IM
P-Charging-Vector orig-ioi is of type 1 in
the header field
(1) REFER message is used for a possible additional call transfer. For a detailed description
of REFER message reception, refer to Function Specification PS to CS SRVCC for
EL
Additional Call .
(2) The MSC-S Local Host Name in the form of Fully Qualified Domain Name (FQDN) is included
in the Contact header field of the SIP INVITE message.
(3) The route to IMS is considered as trusted route.
PR
MSC-S builds the SDP offer for the SIP INVITE request based on its
configuration and capabilities as for any other SIP voice call. Refer to Function
Specification Session Initiation Protocol for further details. Refer to Function
Specifications Out of Band Transcoder Control in MSC Server, GMSC Server
and TSC Server and TrFO Interworking with SIP and SIP-I for a description of
optimized codec handling available when corresponding features are active.
For a description of SIP route configuration, refer to User Guide Sv-Interface

Configuration and Enabling of Single Radio Voice Call Continuity.
SIP 18x and UPDATE messages received from IMS do not trigger DTAP
messages until the reception of the following message:
• SIP INFO in case of originating calls in pre-alerting state or calls in alerting
state
• SIP 200 OK INVITE in case of active or held calls
MSC-S does not differentiate between traffic cases before the reception of
either SIP 200 OKINVITE, or SIP INFO message.
18 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
The following subsections describe the Session Transfer message flows for
the following call cases:
• Active call or held call (indicated by the reception of SIP 200 OK INVITE
message) described in Page 19
• Originating call in alerting state, and terminating call in alerting state

(indicated in the SIP INFO message), described in Page 20
Y
• Originating call in pre-alerting state, (indicated in the SIP INFO message),
described in Page 22
R
Note: MSC-S sets the transaction identifier to 0 and TI flag as in mobile
terminated call for a single or first call subject to SRVCC procedure.
A
Session Transfer of an Active or Held Call
IN
As shown in Figure 9, MSC-S receives the SIP 200 OK INVITE message (as
answer to the previously sent SIP INVITE message), indicating that an active
or held call is transferred. A held call is considered an answered voice call
between two subscribers without a speech connection. MSC-S acknowledges
the SIP 200 OK INVITE message, and configures the bearer termination towards
IM
the IMS network as described in Section 3.2.17 on page 48.
SIP BSSMAP
Target
IMS MSC-S
EL
BSC
HANDOVER
REQUEST
ACKNOWLEDGE
INVITE
PR
200 OKINVITE
ACK
MSC-S in
Active state
Figure 9 Session Transfer for an Active or Held Call
If +g.3gpp.mid-call feature capability indicator is not present in SIP 200

OK INVITE, MSC-S considers the call as active call.
Otherwise, MSC-S based on +g.3gpp.mid-call feature capability indicator

and media directionality received in the SDP answer body of SIP 200 OK INVITE
identifies whether the transferred session is an active call or a held call.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 19

• If media directionality received in SDP answer is sendrecv or sendonly,

MSC-S considers the transferred session as an active call and sets its
state to active.
• If media directionality received in SDP answer is recvonly or inactive,
MSC-S considers the transferred session as call held by served UE or
call held by served and remote UE respectively. MSC-S sets its state to
active and its hold auxiliary state to held call. MSC-S will not populate
any announcement or tone related to call hold supplementary service.
Additionally no call hold outband notification is triggered towards the remote
party.
Y
Note: If media directionality received in SDP answer is sendonly, this is
interpreted as call held by remote UE. This applies regardless the
R
presence of +g.3gpp.mid-call feature capability indicator in SIP
200 OK INVITE.
A
In case the SIP 200 OK INVITE message includes the isfocus media feature
tag in Contact header, then the served subscriber is a conference call
participant. In addition, if the subscriber has initiated the conference call in IMS
IN
network, after the acknowledgment of SIP 200 OK INVITE , MSC-S receives a
SIP INFO message, as described in Section 3.2.12 on page 41.
For the context of this document, the SRVCC transferred active conference
IM
call for the served subscriber that has initiated the conference in IMS, acting
as conference controller, is called conference call.
At reception of SIP 200 OK INVITE MSC-S also handles any buffered DTAP
message reception events as described in Table 9.
EL
DTAP message reception event buffering is described in Section 3.2.5 on

page 24.
Table 9 DTAP Message Handling for Active or Held Call

PR
Incoming DTAP Message Answer DTAP Message

STATUS ENQUIRY STATUS
There is a case that MSC-S is already in active state when it receives the SIP
200 OK INVITE message, due to a received DTAP CONNECT message from UE.
If the transferred session is an active call, MSC-S acknowledges the SIP 200
OK INVITE message and remains in active state. Otherwise, MSC-S releases the
call with cause code ‘‘temporary failure’’.
After the reception of SIP 200 OK INVITE, MSC-S behaves according to its state.
Session Transfer of Call in Alerting State
As shown in Figure 10, MSC-S receives the SIP 183 Session Progress
message (as answer to the previously sent SIP INVITE message), and
configures the bearer termination towards the IMS network as described in
Section 3.2.17 on page 48.
20 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
In case of terminating call in alerting state, MSC-S can receive the DTAP
CONNECT message from UE before or after the reception of SIP INFO message
from IMS. The former case is described in Section 3.2.11 on page 36, while
the latter is described below.
SIP BSSMAP
Target
IMS MSC-S
BSC
HANDOVER
REQUEST
ACKNOWLEDGE
Y
INVITE
R
183 Session Progress
A
PRACK
200 OKPRACK
INFO
IN
IM
200 OKINFO
MSC-S in
EL
Call Delivered or
Call Received state
Figure 10 Session Transfer of Call in Alerting State

PR
If MSC-S receives a SIP INFO message from the IMS network, MSC-S
acknowledges it.
According to the <direction> element contained in the <state-and-event

-info> element of the SIP INFO request, the MSC-S identifies whether the
transferred session is an originating or terminating alerting call.
• If <direction> element is set to initiator and <state-info>

element is set to early the MSC-S considers the transferred session as
originating alerting call and enters ‘‘Call Delivered’’ MSC-S state.
• If <direction> element is set to receiver and <state-info> element

is set to early the MSC-S considers the transferred session as terminating
alerting call and enters ‘‘Call Received’’ MSC-S state.
For more information, refer to Function Specification Session Initiation Protocol.
At reception of SIP INFO, MSC-S also handles any buffered DTAP message
reception events as described in Table 10.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 21


page 24.
Table 10 DTAP Message Reception Event Handling for Calls in Alerting State
Incoming DTAP Answer DTAP Message in Answer DTAP Message in
Message Originating Case Terminating Case
STATUS ENQUIR
STATUS
Y
Y
After the reception of SIP INFO, MSC-S behaves according to its state.
R
Session Transfer of Originating Call in Pre-alerting State
As shown in Figure 11, MSC-S receives the SIP 183 Session Progress
A
message (as answer to the previously sent SIP INVITE message), and
configures the bearer termination towards the IMS network (if SDP body from
remote side is received) as described in Section 3.2.17 on page 48.
IMS SIP MSC-S

IN
BS
SM
AP
DTAP UE
IM
Target
BSC
HANDOVER
REQUEST
ACKNOWLEDGE
EL
INVITE
183 (Session Progress)

PR
PRACK
200 OKPRACK
INFO
200 OKINFO
MSC-S in Mobile
Originating Call
Proceeding state
PROGRESS
Figure 11 Session Transfer of Originating Call in Pre-alerting State
22 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Note: DTAP PROGRESS messages is send after HANDOVER COMPLETE

message has been received as described in Section 3.2.5 on page 24.
Note: The first SIP 183 Session Progress message received in MSC-S,
after SIP INVITE message, can contain connection address in SDP
answer set to the unspecified address (0.0.0.0 if IPv4, or domain name
within the ".invalid" DNS top-level domain in case of IPv6). After a SIP
INFO message has been received an additional SIP 183 Session
Progress early dialog forming message containing the actual SDP
answer is expected in MSC-S.
Y
When MSC-S receives a SIP INFO message from the IMS network,
acknowledges it.
R
According to the information contained in the state-and-event-info
element of the SIP INFO request the MSC-S identifies the call as originating
A
call in pre-alerting state and enters Mobile Originating Call Proceeding state.
This is the case if the direction element is set to initiator and the
state-info element is set to pre-alerting. For more information, refer to
IN
Function Specification Session Initiation Protocol.
After MSC-S has entered the state ‘‘Mobile Originating Call Proceeding’’ for
an originating pre-alerting call, it handles any SIP 1xx and 2xx messages
IM
received from IMS as for a normal originating call in ‘‘Mobile Originating
Call Proceeding’’ state. For more information, see Function Specification
MSC Server Interworking with External Networks using SIP and SIP with
encapsulated ISUP.
EL
MSC-S sends a DTAP PROGRESS message to the UE containing a progress

indicator set to ‘‘Call is end-to-end ISDN/PLMN’’. For more information, refer to
Function Specifications Session Initiation Protocol and A/Iu-Interface, Section
K: DTAP and RANAP/NAS, Message Formats and Coding for Call Control and
Call Related Supplementary Service Procedures,.
PR
At reception of SIP INFO, MSC-S also handles any buffered DTAP message
reception events as described in Table 11

page 24.
Table 11 DTAP Message Handling for Originating Call in Pre-alerting State

Incoming DTAP Message Answer DTAP Message in Originating Pre-alerting Case
STATUS ENQUIRY STATUS
After the reception of SIP INFO, MSC-S behaves according to its state.
3.2.4.2 Handover Scenario 2: Target Cell Belongs to Neighboring MSC-S
Apart from the differences specified below, the session transfer towards the IMS
network is initiated by the MSC-S as described in Section 3.2.4.1 on page 17.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 23

In this case, the reception of the MAP PREPARE HANDOVER response message
(encapsulating the BSSMAP HANDOVER REQUEST ACKNOWLEDGE message)
and either a BICC or ISUP ADDRESS COMPLETE message (ACM) or a BICC
or ISUP CONNECT message (CON) from the Neighboring MSC-S triggers the
MSC-S to initiate the session transfer towards the IMS network, as shown in
Figure 12. The RO used in the analysis function is determined by configuration
of the route of the Neighboring MSC-S.
SIP MAP Neighboring BSSMAP

Targe
IMS MSC-S MSC-S BSC
Y
BICC or
ISUP
HANDOVER
REQUEST
R
ACKNOWLEDGE
PREPARE
HANDOVER
response
A
ACM or CON
Figure 12
INVITE
IN
Session Transfer, Neighboring MSC-S Scenario
IM
Session Transfer of Active or Held Call or Call in Alerting State
After sending the SIP INVITE message, the same messages are sent and
EL
expected to be received by the MSC-S as shown the following figures:

• Figure 9 for active or held call
• Figure 10 for call in alerting state
PR
Session Transfer of Originating Call in Pre-alerting State
After sending the SIP INVITE message, the same messages are sent and
expected to be received by the MSC-S as shown in Figure 11.
DTAP PROGRESS message encapsulated in MAP FORWARD ACCESS

SIGNALLING message is sent towards the UE after a DTAP HANDOVER
COMPLETE message has been received in MSC-S as shown in Figure 14.
3.2.5 Handover Completion

This section describes the MSC-S behavior at completion of the Handover.
As shown in Figure 13, after receiving the BSSMAP HANDOVER REQUEST

ACKNOWLEDGE message, the MSC-S waits for a BSSMAP HANDOVER DETECT
24 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
message and a BSSMAP HANDOVER COMPLETE message. The reception of a

BSSMAP HANDOVER DETECT message is conditional.
BSSMAP
Target
MSC-S
BSC
HANDOVER
DETECT
Y
HANDOVER
COMPLETE
R
Figure 13 Handover Completion
A
The completion of the Intra-MSC Handover is supervised by supervision timer,
defined by the parameter TIMUGHOINTRAM.
IN
If a BSSMAP HANDOVER DETECT or a BSSMAP HANDOVER COMPLETE
message arrives before the MSC-S state is known, that is, before the arrival
of SIP INFO, SIP 200 OK INVITE or DTAP CONNECT message, DTAP STATUS
ENQUIRY message reception event is buffered from the reception of a BSSMAP
IM
HANDOVER DETECT or a BSSMAP HANDOVER COMPLETE message, since the
handling of DTAP messages depends on the MSC-S state.
The handling of buffered DTAP messages is described in Section 3.2.4 on

page 16.
EL
If the subscriber, for whom the SRVCC Procedure is performed, was registered
in VLR before the request for SRVCC Procedure, and is IMSI Detached or
Implicit Detached, then MSC-S marks subscriber IMSI Attached and stops
accordingly the implicit detach and the automatic deregistration timers. In this
PR
case, the subscriber roaming restrictions are not cleared.
Apart from the differences specified below, the MSC-S behavior at the
Completion of the Handover is as described in Page 24.
As shown in Figure 14, MSC-S waits for a BICC or ISUP ANSWER message
(ANM) in addition to the BSSMAP HANDOVER DETECT and HANDOVER
COMPLETE messages.
In this case, BSSMAP HANDOVER DETECT and HANDOVER COMPLETE

messages arrive encapsulated in MAP PROCESS ACCESS SIGNALLING and
SEND END SIGNAL messages from the Neighboring MSC-S, respectively.
DTAP messages also arrive encapsulated in MAP PROCESS ACCESS

SIGNALLING message.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 25

The completion of the Inter-MSC Handover is supervised by supervision timer,

defined by parameter TIMUGHOBASICM.
MAP Neighboring BSSMAP

Target
MSC-S MSC-S
BICC or ISUP BSC
HANDOVER
DETECT
PROCESS ACCESS
SIGNALLING
Y
ANM
HANDOVER
R
COMPLETE
SEND END SIGNAL
A
IN
IM
Figure 14 Handover Completion, Neighboring MSC-S Scenario
EL
3.2.6 SRVCC Complete Notification to MME

This section describes the SRVCC Complete Notification sent by the MSC-S
to the MME.
PR
As shown in Figure 15, after the reception of BSSMAP HANDOVER COMPLETE

message, the MSC-S sends an Sv-Interface protocol SRVCC PS TO CS
COMPLETE NOTIFICATION message to the MME containing the IMSI. After
sending Sv-Interface protocol SRVCC PS TO CS COMPLETE NOTIFICATION,
the MSC-S waits for an Sv-Interface protocol SRVCC PS TO CS COMPLETE
ACKNOWLEDGE message from the MME. The reception of the acknowledgement
from MME is time supervised. For a detailed description of this timer, refer to
the Function Specification GTP-C, Signaling Transport.
26 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Sv-Interface Protocol BSSMAP

Target
MME MSC-S
BSC
HANDOVER
COMPLETE
SRVCC PS TO CS
COMPLETE NOTIFICATION
SRVCC PS TO CS
COMPLETE ACKNOWLEDGE
Y
Figure 15 SRVCC Complete Notification to MME
R
The MSC-S sends the message to the address received in the MME/SGSN Sv
Address for Control Plane IE within the Sv-Interface protocol SRVCC
PS TO CS REQUEST message. For a detailed description of the addressing
A
when sending the Sv-Interface protocol SRVCC PS TO CS COMPLETE
NOTIFICATION message, refer to the Function Specification Generic Transport
Function, Traffic, Administration and Maintenance.
IN
When sending an Sv-Interface protocol SRVCC PS TO CS COMPLETE
NOTIFICATION message is not possible, the ongoing SRVCC Procedure
continues unaffected.
IM
After successful completion of the SRVCC Procedure, the MSC-S replaces any
present security information with the set of data received in the Sv-Interface
protocol SRVCC PS TO CS REQUEST message.
EL
After completion of the SRVCC Procedure, the MSC-S is the anchor MSC-S for
any upcoming subsequent handover or supplementary service handling.
Note: The SRVCC Complete Notification is sent by the MSC-S to the MME
PR
although there might be an additional call transfer ongoing. For a

detailed description of the additional call transfer, refer to Function
Specification PS to CS SRVCC for Additional Call .
Apart from the differences specified below, the SRVCC Complete Notification
sent by the MSC-S to the MME is as described in Page 26.
In this case, the BSSMAP HANDOVER DETECT and the BSSMAP HANDOVER
COMPLETE message arrive encapsulated in MAP PROCESS ACCESS
SIGNALLING and MAP SEND END SIGNAL message respectively from the
Neighboring MSC-S.
As shown in Figure 16, after the reception of MAP SEND END SIGNAL
message and BICC or ISUP ANSWER message, the MSC-S sends an
Sv-Interface protocol SRVCC PS TO CS COMPLETE NOTIFICATION
message to the MME.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 27

Sv-Interface
Protocol MAP Neighboring BSSMAP
Target
MME MSC-S MSC-S
BICC or ISUP BSC
HANDOVER
DETECT
PROCESS ACCESS
SIGNALLING
ANM
HANDOVER
Y
COMPLETE
SEND END SIGNAL
R
SRVCC PS TO CS
COMPLETE
NOTIFICATION
A
SRVCC PS TO CS
COMPLETE
ACKNOWLEDGE
Figure 16
IN
SRVCC Complete Notification to MME, Neighboring MSC-S
Scenario
IM
3.2.7 TMSI Allocation
EL
This section describes the TMSI Reallocation procedure initiated by the

MSC-S.As a prerequisite of the function LTE to GSM Handover (SRVCC)
the AXE customer parameter TMSIPAR in parameter set GSMMMSC is set to
determine that TMSI allocation on all connections is performed in the MSC-S.
PR
As shown in Figure 17, the MSC-S initiates a TMSI allocation after the reception
of a BSSMAP HANDOVER COMPLETE message for the subscriber for whom the
SRVCC Procedure is performed, in the following cases:
• The subscriber is not registered in the VLR upon reception of the

Sv-Interface protocol SRVCC PS TO CS REQUEST message with IMSI
received within the request.
• The subscriber is registered in the VLR upon reception of the Sv-Interface

protocol SRVCC PS TO CS REQUEST message, but does not have a
TMSI allocated.

protocol SRVCC PS TO CS REQUEST message, TMSI is valid, no Location
Area Identity (LAI) is stored in the VLR, and allocation of a new TMSI at
change of location area is configured by AXE parameter TMSILAIMSC
in parameter set GSMMMSC.
28 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function

protocol SRVCC PS TO CS REQUEST message, TMSI is valid, LAI stored
in VLR is different from the LAI of target cell, and allocation of a new TMSI
at change of location area is configured by AXE parameter TMSILAIMSC
in parameter set GSMMMSC.
BSSMAP
Target
MSC-S
DTAP BSC
HANDOVER
Y
COMPLETE
TMSI REALLOCATION
R
COMMAND
TMSI REALLOCATION
A
COMPLETE
Figure 17 TMSI Allocation
IN
To force the UE to make a location update after the end of the call, the MSC-S
includes either of the following LAI in the DTAP TMSI REALLOCATION
COMMAND message:
IM
• The LAI stored in VLR only if the conditions described in the last list item
of the list above are fulfilled
EL
• The own Non Broadcast Location Area Identity (NB-LAI) in any other case
The location update described above results in the update of VLR data with
valid subscriber data from the HLR and is needed for the following reasons:
PR
• If the target cell belongs to a Neighboring MSC-S that served the UE

before, then the UE may not perform location update after the call and
HLR would have the wrong location.
• If the MSC-S is a member of an MSC pool, the UE may have a TMSI from
before pointing to a different pool member. The UE would not be triggered
to perform a location update if it is still in the same location area as before.
As consequence, HLR would have the wrong location.
• If target cell is served by anchor MSC and a subsequent handover occurs

during the call that is subject to SRVCC Procedure, the UE may then be
in a location it was registered before. The UE would not be triggered to
perform a location update if it is still in the same location area as before.
As consequence, HLR would have the wrong location after the call that
was subject to SRVCC Procedure, due to the location update location
performed by the anchor MSC during SRVCC Procedure.
The NB-LAI is configurable dependent on the administration method used:
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 29

Single NB-LAI administration method

The NB-LAI is administered by means of AXE
parameters NBMCC, NBMNC and NBLAC for Mobile
Country Code (MCC), Mobile Network Code (MNC) and
LAC respectively.
Enhanced NB-LAI administration method

The NB-LAI is administered by means of AXE parameter
PLMNNBLAC for LAC.
Y
Note: In the latter case the PLMN identity part (MCC-MNC) of the NB-LAI is
derived from the PLMN identity part of the target cell.
R
For a detailed description of the TMSI allocation procedure, refer to the Function
Specification Mobile Subscriber Related Security Functions in MSC/VLR
Server.
A
IN
Apart from the differences specified below, the TMSI Reallocation procedure
is initiated by the MSC-S as described in Page 28.
IM
Allocation of a new TMSI at change of location area, which is determined by
AXE parameter TMSILAIMSC in parameter set GSMMMSC, is not applicable
when the target cell belongs to a Neighboring MSC-S.
The MSC-S initiates a TMSI allocation after having received a BSSMAP

EL
HANDOVER COMPLETE message encapsulated in a MAP SEND END SIGNAL

message from the Neighboring MSC-S.
Also, DTAP TMSI REALLOCATION COMMAND and TMSI REALLOCATION

COMPLETE messages are encapsulated in MAP FORWARD ACCESS
PR
SIGNALLING and PROCESS ACCESS SIGNALLING messages respectively,

as shown in Figure 18.
30 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
MAP Neighboring BSSMAP

Target
MSC-S MSC-S DTAP BSC
HANDOVER
COMPLETE
SEND END SIGNAL
FORWARD ACCESS
SIGNALLING
Y
TMSI REALLOCATION
COMMAND
R
TMSI REALLOCATION
COMPLETE
PROCESS ACCESS
A
SIGNALLING
Figure 18 TMSI Allocation, Neighboring MSC-S Scenario
IN
The LAI is not stored in VLR if the target cell is administered as outer cell in
the MSC-S.
IM
In addition, when the enhanced NB-LAI administration method is used, the
PLMN identity part (MCC-MNC) of the NB-LAI is derived from the PLMN identity
part of the SAI connected to the Area Cluster defined for the concerned MME.
EL
3.2.8 Location Update Towards HLR
This section describes the Location Update procedure, initiated by the MSC-S.

PR
As shown in Figure 19, after reception of the BSSMAP HANDOVER COMPLETE

message and BSSMAP TMSI REALLOCATION COMPLETE message, the
MSC-S initiates a MAP UPDATE LOCATION towards the HLR, if the subscriber
was not registered in the VLR upon reception of the Sv-Interface protocol
SRVCC PS TO CS REQUEST message. Upon reception of MAP INSERT
SUBSCRIBER DATA message, the subscriber data is stored.
In case the subscriber for whom the SRVCC Procedure is performed has any
roaming restrictions, these restrictions are not relevant for the ongoing call. For
a detailed description of the MAP UPDATE LOCATION and the MAP INSERT
SUBSCRIBER DATA, refer to the Function Specification Location Updating in
MSC/VLR Server, and to the Function Specification Signalling System No.7,
Mobile Application Part Version 3 in MSC/VLR Server, respectively.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 31

MAP BSSMAP
Target
HLR MSC-S
BSC
TMSI REALLOCATION
COMPLETE
UPDATE LOCATION
INSERT SUBSCRIBER
DATA
Y
INSERT SUBSCRIBER
DATA RESULT
R
UPDATE LOCATION
RESULT
A
Figure 19 Location Update
IN
Apart from the differences specified below, the Location Update procedure is
initiated by the MSC-S as described in Page 31.
IM
In this case, the DTAP TMSI REALLOCATION COMPLETE message arrives
encapsulated in a MAP PROCESS ACCESS SIGNALLING message from the
Neighboring MSC-S, as shown in Figure 20.
EL
MAP MAP Neighboring Target

HLR MSC-S MSC-S
DTAP
BSC
TMSI REALLOCATION
COMPLETE
PR
PROCESS ACCESS
SIGNALLING
UPDATE LOCATION
INSERT SUBSCRIBER
DATA
INSERT SUBSCRIBER
DATA RESULT
UPDATE LOCATION
RESULT
Figure 20 Location Update, Neighboring MSC-S Scenario
32 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
3.2.9 Status Enquiry Procedure

This section describes the Status Enquiry procedure, initiated by the MSC-S,
in order to avoid a situation when due to a radio connection break during an
ongoing SRVCC Procedure, the states between the UE and the MSC-S are
not properly aligned.
MSC-S initiates the Status Enquiry procedure by sending a DTAP STATUS
Y
ENQUIRY message to the UE at the reception of the following messages:
• SIP INFO message for originating call in pre-alerting state or call in alerting
R
state
• SIP 200 OKINVITE message for active or held call
A
if the following conditions are fulfilled:
1. AXE parameter SRVCCSTAENQENBL indicates that Status Enquiry

Procedure will be performed.
IN
2. A DTAP CONNECT message has not been received from the UE.
IM
3. A DTAP STATUS ENQUIRY message has not been received from the UE.
When a STATUS message as answer to a STATUS ENQUIRY is received,

MSC-S compares it to the MSC-S state, and proceeds according to Table 12.
In case of a detected incompatible state between UE and MSC-S, the value of
EL
SRVCCSTAENQENBL AXE parameter determines the further call handling (call

clearing or alignment of the MSC-S state if possible).
If no answer arrives (before the T322 timer expires), MSC-S releases the call
using cause code ‘‘temporary failure’’ in the first DTAP call clearing message.
PR
The call leg towards IMS is released according to SIP release procedures as
described in Function Specification Session Initiation Protocol. Depending on
route configuration (MIS2 route parameter) the SIP Reason header is included.
Note: T322 timer is configured by AXE parameter SRVCCSTAENQT322.
A Permanent Application Parameter (PAP) can enable that DTAP

STATUS ENQUIRY message is retransmitted once after the first expiry
of T322 timer.
Note: The Status Enquiry procedure is executed in parallel to the SRVCC

Procedure execution.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 33

Table 12 Call Handling in Status Enquiry Procedure

State of the State of the MS/ Action
MSC-S UE
SRVCCSTAENQENBL=1 SRVCCSTAENQENBL=2
(received in
(call clearing) (state alignment)
STATUS)
Active Active No action.
Mobile Originatin MSC-S releases the MSC-S triggers ‘‘Call
g call proceeding call using cause code Connected’’ procedure to
(1)(2)
Y
‘‘message not compatible align the states.
with protocol state’’ in the
first clearing message.
R
The call leg towards
to IMS is released
according to SIP release
A
procedures as described
in Function Specification
Session Initiation Protocol.
Depending on route
configuration (MIS2
route parameter) the
SIP Reason header is
IN
IM
included.
Call Delivered MSC-S clears the call. MSC-S triggers ‘‘Call
Connected’’ procedure to
(1)(2)
align the states.
EL
(2)
Connect MSC-S clears the call. No action.
Request
Connect Active MSC-S clears the call. MSC-S enters ‘‘Active’’ state.
Indication
Call Delivered No action.
PR
Mobile Orig No action.

inating Call
Proceeding
Call Delivere Call Delivered No action.
d (3)
Mobile Orig MSC-S clears the call. MSC-S triggers ‘‘Alerting’’
(5)
inating Call or procedure to align the states.
(4)
Proceeding No action. or
(4)
No action
Mobile Mobile Orig No action.
Originating inating Call
Call Proceeding
Proceeding
Call Delivered MSC-S clears the call. MSC-S enters ‘‘Call Delivered’’
state.
Call Receive Call Received No action.
d
34 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Table 12 Call Handling in Status Enquiry Procedure

State of the State of the MS/ Action
MSC-S UE
SRVCCSTAENQENBL=1 SRVCCSTAENQENBL=2
(received in
(call clearing) (state alignment)
STATUS)
Connect Connect No action.
Request Request
Other state combinations MSC-S releases the call using cause code ‘‘message not
Y
compatible with protocol state’’ in the first clearing message.
The call leg towards to IMS is released according to SIP
release procedures as described in Function Specification
R
Session Initiation Protocol. Depending on route configuration
(MIS2 route parameter) the SIP Reason header is included.
(1) Due to this procedure the MSC-S changes state back to ‘Connect Indication’ and reaches state ‘‘Active’’ when
A
CONNECT ACKNOWLEDGE message is received.
(2) If MSC-S state misalignment is identified between UE and MSC-S, for the case of a held call, the MSC-S releases
the call sending DTAP RELEASE COMPLETE message with cause code ‘‘message not compatible with protocol state’’.
IN
(3) If Call Delivered (N3) state is entered due to SIP INFO request indicating originating alerting call and DTAP STATUS
as answer to DTAP STATUS ENQUIRY indicates Mobile originating call proceeding then the call shall be cleared.
(4) If Call Delivered state (N4) is entered for an originating pre-alerting call due to SIP 180 (Ringing), which is
received before DTAP STATUS, no state mismatch shall be triggered, if DTAP STATUS as answer to DTAP STATUS
IM
ENQUIRY indicates Mobile originating call proceeding (U3). This is because DTAP ALERTING will reach the UE.
(5) This action shall be done only if MSC entered Call Delivered state due to SIP INFO request indicating originating
alerting call.
EL
For possible release sequence on SIP towards IMS, refer to Function

Specification Session Initiation Protocol.

PR
Apart from the differences specified below, the Status Enquiry procedure is
initiated by the MSC-S as described in Page 33.
In this case, the DTAP STATUS ENQUIRY message is encapsulated in MAP

FORWARD ACCESS SIGNALLING message.
3.2.10 Alerting for Originating Calls in Pre-Alerting State

This section describes the MSC-S behavior at reception of an SIP 180
Ringing response for an originating pre-alerting call subject to SRVCC
Procedure.
In case of an originating pre-alerting call, optional SIP 180 Ringing response

to the SIP INVITE can be received.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 35

As shown in Figure 21 if MSC-S receives a SIP 180 RINGING message,

it answers with SIP PRACK message to IMS and sends a DTAP ALERTING
message to the UE without triggering the sending of ring back-tone. For more
information, refer to Function Specification A/Iu-Interface, Section K: DTAP and
RANAP/NAS, Message Formats and Coding for Call Control and Call Related
Supplementary Service Procedures.
IMS SIP MSC-S DTAP UE
MSC-S in Mobile
Y
Originating Call
Proceeding state
180 Ringing
R
PRACK
MSC-S in
A
Call Delivered
state
ALERTING
200 OKPRACK
Figure 21
IN
Alerting for Originating Call in Pre-Alerting State
IM
In this case, DTAP ALERTING message is encapsulated in MAP FORWARD

ACCESS SIGNALLING messages, as shown in Figure 22.
EL
SIP MAP Neighboring DTAP UE

IMS MSC-S MSC-S
MSC-S in Mobile
Originating Call
Proceeding state
PR
180 Ringing
PRACK
FORWARD ACCESS
SIGNALLING
MSC-S in
Call Delivered
state
200 OKPRACK
ALERTING
Figure 22 Alerting for Originating Call in Pre-Alerting State, Neighboring

MSC-S Scenario
36 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
3.2.11 Call Acceptance for Calls in Alerting State or Originating Calls in

Pre-Alerting State
This section describes the MSC-S behavior at the call acceptance of the
following call cases that are subject to SRVCC Procedure:
• Calls in alerting state
• Originating calls in pre-alerting state
Y
In case the SRVCC Procedure is performed for a call in alerting state or
originating call in pre-alerting state, in order to achieve bothway through
R
connection in the user plane, the call has to be answered.
A
Originating Call in Alerting State or Originating Calls in Pre-alerting state
In case of a Originating call, the reception of the SIP 200 OK INVITE message
IN
indicates that the call is accepted. This triggers through connection as
described in Section 3.2.17 on page 48 .
As shown in Figure 23, MSC-S sends a DTAP CONNECT message to the UE to

IM
indicate that the called party has accepted the call and the UE acknowledges it.

EL
200 OKINVITE
ACK
CONNECT
PR
CONNECT
ACKNOWLEDGE
MSC-S in
Active
state
Figure 23 Call Acceptance of Originating Call
Terminating Call in Alerting State
In case of a terminating call, the reception of the DTAP CONNECT message

indicates that the call is answered.
There are two cases, depending on the sequence by which MSC-S receives
SIP INFO and DTAP CONNECT messages.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 37

• MSC-S has already received the SIP INFO message when receiving the
DTAP CONNECT message
The reception of SIP INFO message is covered in Section 3.2.4 on page 16.
Upon reception of a DTAP CONNECT message, MSC-S triggers the bothway
through connection (see Section 3.2.17 on page 48), acknowledges the
message and enters in Active State. Then MSC-S sends SIP INFO to IMS
to indicate that the call has been accepted as shown in Figure 24.
Y
CONNECT
R
CONNECT
ACKNOWLEDGE
A
MSC-S in
Active
state
200 OKINFO
INFO IN
IM
200 OKINVITE
ACK
EL
Figure 24 Call Acceptance of Terminating Alerting Call, SIP INFO has already
been received
• MSC-S receives the SIP INFO message after receiving the DTAP CONNECT
message
PR
In this case, after the reception of DTAP CONNECT message, MSC-S

proceeds with its handling, performs bothway through connection (see
Section 3.2.17 on page 48), acknowledges the message with DTAP
CONNECT ACK and enters the Active state.
Afterwards, if MSC-S receives the SIP INFO message from IMS for a
terminating call in alerting state, it acknowledges it and sends SIP INFO to
IMS to indicate that the call has been accepted as shown in Figure 25.
If MSC-S receives a SIP INFO message from IMS indicating Originating

Call in Alerting or Pre-alerting State, it releases the call using cause code
"temporary failure" in the first DTAP call clearing message. The call leg
towards IMS is released according to SIP release procedures as described
in Function Specification Session Initiation Protocol. Depending on route
configuration (MIS2 route parameter) the SIP Reason header is included.
38 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
CONNECT
CONNECT
ACKNOWLEDGE
MSC-S in
Active
state
Y
INFO
200 OKINFO
R
INFO (Call Accepted)
A
200 OKINFO
200 OKINVITE
ACK IN
IM
Figure 25 Call Acceptance of Terminating Alerting Call, DTAP CONNECT is
received before SIP INFO

EL
Apart from the differences specified below, the MSC-S behavior at the call
acceptance of calls subject to SRVCC Procedure is as described in Section
3.2.11.1 on page 37.
PR
Originating Call in Alerting State or Originating Calls in Pre-alerting state
In this case, DTAP CONNECT and CONNECT ACKNOWLEDGE messages

are encapsulated in MAP FORWARD ACCESS SIGNALLING and PROCESS
ACCESS SIGNALLING messages respectively, as shown in Figure 26.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 39

SIP MAP Neighboring DTAP

IMS MSC-S UE
MSC-S
200 OKINVITE
ACK
FORWARD ACCESS
SIGNALLING
CONNECT
Y
CONNECT
ACKNOWLEDGE
R
PROCESS ACCESS
SIGNALLING
A
MSC-S in
Active
state
Figure 26 IN
Call Acceptance of Originating Call, Neighboring MSC-S Scenario
IM
Terminating Call in Alerting State
In this case, DTAP CONNECT and CONNECT ACKNOWLEDGE messages

are encapsulated in MAP PROCESS ACCESS SIGNALLING and FORWARD
ACCESS SIGNALLING messages respectively, as shown in Figure 27.
EL
PR
40 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
SIP MAP Neighboring DTAP UE

IMS MSC-S MSC-S
CONNECT
PROCESS ACCESS
SIGNALLING
FORWARD ACCESS
SIGNALLING
CONNECT
Y
ACKNOWLEDGE
MSC-S in
R
Active
state
A
INFO
200 OKINFO
200 OKINVITE
ACK
IN
IM
Figure 27 Call Acceptance of Terminating Alerting Call Neighboring MSC-S
Scenario
For the case that MSC-S receives the DTAP CONNECT message before
the reception of SIP INFO message from IMS, the call flow is similar to
EL
Figure 25, with messages DTAP CONNECT and CONNECT ACKNOWLEDGE

being encapsulated in MAP PROCESS ACCESS SIGNALLING and FORWARD
ACCESS SIGNALLING messages respectively.
PR
3.2.12 Reception of Conference Call Information

When MSC-S receives a SIP INFO message as shown in Figure 28 and all
the following conditions are fulfilled:
• The received SIP 200 OK INVITE message due to STN-SR included in the
Contact header the isfocus media feature tag.
• The first transferred session corresponds to an active call as described

in Page 19.
• The number of the conference call participants is one up to five.
• The message includes the <mid-call> element including conference

participants list.
MSC-S recognizes the transferred session as an active conference call and

assigns TIs to the conference participants.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 41

The TI values (0, 2, 3, 4, 5) are assigned to the conference participants based

on their order of presence in the list and their number. The TI flags are set as
for MT calls and MSC-S sets the multi-party auxiliary state to ‘‘Call in MPTY’’.
After that point MSC-S considers the transferred active conference call as a
multi-party call and acknowledges the SIP INFO message by sending SIP
200 OK INFO.
IMS SIP MSC-S
Y
Session transfer of an active
call with "isfocus"
INFO
R
200 OKINFO
A
Active Conference Call
Figure 28 Reception of Conference Call Information
IN
Rejection of Transfer of an active conference call
The following Table 13 describes the MSC-S SIP final responses towards
IM
IMS network after SIP INFO request related to the transfer of conference call
participants has been received by the MSC-S and the request is rejected.
Table 13 SIP final responses towards IMS network

EL
Condition SIP final response

More than five conference participants 403 ‘‘Forbidden’’
exists in <mid-call> element
The isfocus feature tag has not been 403 ‘‘Forbidden’’
PR
received at SIP 200 OK INVITE message

The first transferred session corresponds 403 ‘‘Forbidden’’
to a held call as described in Page 19
Congestion 503 ‘‘Service Unavailable’’
DTAP message has been received for 500 ‘‘Server Internal Error’’
a conference participant prior the TIs'
assignment
Internal failure 500 ‘‘Server Internal Error’’
In all the cases mentioned in Table 13, the MSC-S releases the IMS conference
call, following the SIP release call procedures. For more information on release
sequence on SIP towards IMS, refer to Function Specification Session Initiation
Protocol.
42 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
3.2.13 Conference Control after SRVCC transfer

Multi-party operations handling, after the call is identified as an active
conference call, is based on multi-party auxiliary state.
The MSC-S is capable to manipulate the state of the transferred conference

call, by means of the existing multi-party supplementary service procedures.
For more information on the multi-party supplementary service function, refer to
Function Specification Multi-Party Supplementary Service in MSC/VLR Server.
MSC-S can manipulate the invoked multi-party call as follows:
Y
• Add or remove a remote party after the served subscriber has
been transferred to CS domain by means of the existing multi-party
R
supplementary service procedures. When remote parties are added in
the multi-party call the maximum number of five participants must not be
exceeded. In case the IMS conference already includes five participants
A
or the IMS conference participants and the newly added remote parties
are already five, the request to add a new remote party is rejected with
cause ‘‘Maximum number of multi-party participants exceeded’’. For more
IN
information on the multi-party supplementary service function, refer to
Function Specification Multi-Party Supplementary Service in MSC/VLR
Server.
IM
• Put the multi-party call on hold.
• Retrieve the held multi-party call.
• Alternate between the multi-party call and a single CS call.

EL
• Disconnect the transferred IMS conference
0 In case MSC-S receives a DTAP call clearing message with TI

corresponding to an IMS participant of the invoked multi-party call, the
PR
MSC-S releases the IMS conference call, following the SIP release
call procedures. For more information on release sequence on SIP
towards IMS, refer to Function Specification Session Initiation Protocol.
In addition, MSC-S sends a DTAP DISCONNECT message for each of
the remaining TIs related to the IMS conference participants. DTAP
cause ‘‘normal unspecified’’ is populated. For more information on the
call clearing procedures, refer to Function Specification A-Interface,
Section B: Basic Call Control Procedures. In case remote parties have
been added to the multi-party call after the served subscriber has
been transferred to CS domain, they are not released but they remain
in the call.
• If MSC-S receives a disconnection indication from IMS side within a SIP

BYE request, it releases the IMS conference call, following the SIP release
call procedures. For more information on release sequence on SIP towards
IMS, refer to Function Specification Session Initiation Protocol. In addition,
MSC-S sends a DTAP DISCONNECT message for each of the remaining
TIs related to the IMS conference participants, mapping the cause code
received in SIP BYE request. In case remote parties have been added to
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 43

the multi-party call after the served subscriber has been transferred to CS
domain, they are not released but they remain in the call.
MSC-S upon reception of a DTAP FACILITY request for splitting a multi-party

call including IMS participants, it rejects this request by sending a DTAP
FACILITY message with cause ‘‘illegal SS operation’’.
No conference warning tone is played towards IMS on the call leg controlled
by the Mw-Interface.
Y
3.2.14 Cancellation of SRVCC Procedure
R
The MSC-S receives an Sv-Interface protocol SRVCC PS TO CS CANCEL
NOTIFICATION message from the MME, if a SRVCC Procedure is to be
discontinued.
A
The MSC-S uses the received IMSI to correlate the received cancellation
request with the corresponding SRVCC Procedure.
IN
The MSC-S cancels the SRVCC Procedure when the Sv-Interface protocol
SRVCC PS TO CS CANCEL NOTIFICATION message was received prior to
the reception of the BSSMAP HANDOVER COMPLETE message or the MAP
IM
SEND END SIGNAL message from the target BSC or from the Neighboring
MSC-S, respectively. The MSC-S replies to the MME by sending an
Sv-Interface protocol SRVCC PS TO CS CANCEL ACKNOWLEDGE message
with the cause code ‘‘Request accepted’’, discards any security key information
EL
present for the subscriber and disconnects the call leg towards the target cell.
For a detailed description of the release towards the target cell, refer to the
Function Specification UMTS to GSM Handover in MSC/VLR Server. The
MSC-S is prepared to retransmit the sent Sv-Interface protocol SRVCC PS TO
CS CANCEL ACKNOWLEDGE message for a configured period of time, in case
PR
the same Sv-Interface protocol SRVCC PS TO CS CANCEL NOTIFICATION

message is received again. For a detailed description of this retransmission
time period, refer to the Function Specification GTP-C, Signaling Transport.
In addition, if a SIP INVITE message was already sent by the MSC-S to

the IMS network during SRVCC Procedure execution, the MSC-S releases
the session transfer call leg, as described in Function Specification Session
Initiation Protocol. Depending on route configurable option (MIS2 route
parameter) the Reason header is included in this case with value ‘‘Normal
Unspecified’’. Furthermore, the MSC-S adds an indication in the Sv-Interface
protocol SRVCC PS TO CS CANCEL ACKNOWLEDGE message that the IMS
session transfer is ongoing.
The MSC-S rejects the cancellation request by sending an Sv-Interface

protocol SRVCC PS TO CS CANCEL ACKNOWLEDGE message with cause
code ‘‘Request rejected’’ in the following cases:
• There is neither an SRVCC Procedure, nor a CM transaction, ongoing

for the indicated IMSI.
44 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
• The MSC-S already received a BSSMAP HANDOVER COMPLETE message.
• The MME sending the cancellation request is different from the one sending
the request for the SRVCC Procedure before.
• The message is received after an Sv-Interface protocol SRVCC PS TO CS

CANCEL ACKNOWLEDGE message was sent and no time supervision is
running anymore. For a detailed description of the time supervision, refer to
the Function Specification GTP-C, Signaling Transport.
Y
For a description of further possible rejection cases, refer to the Function
Specification Sv-Interface, General Aspects, Message Formats and Coding
for SRVCC, and to the Function Specification GTPv2-C, General Aspects,
R
Formats and Codes.
A
3.2.15 Interaction between Requests for SRVCC Procedure
The MSC-S is prepared to handle the reception of an Sv-Interface protocol
IN
SRVCC PS TO CS REQUEST message, although an SRVCC Procedure is
already ongoing for the indicated IMSI. Relevant cases are as follows:
• The sending MME is different than the MME sending the original request.
IM
• The message is received with a different sequence number from the MME
that sent the original request. For a detailed description of the sequence
number, refer to the Function Specification GTP-C, Signaling Transport.
EL
• The message is received after an Sv-Interface protocol SRVCC PS TO CS

RESPONSE message was sent and no time supervision is running anymore.
For a detailed description of the time supervision, refer to the Function
Specification GTP-C, Signaling Transport.
PR
In these cases the MSC-S responds to the MME with an Sv-Interface protocol
SRVCC PS TO CS RESPONSE message, indicating an unsuccessful result with
cause code ‘‘Request rejected’’ and SRVCC reject cause ‘‘Unspecified’’. The
ongoing SRVCC Procedure continues unaffected.
For a description of further possible interaction cases, refer to the Function

Specification Sv-Interface, General Aspects, Message Formats and Coding
for SRVCC, and to the Function Specification GTPv2-C, General Aspects,
Formats and Codes.
3.2.16 Rejection of Requests for SRVCC Procedure

This section describes how the MSC-S rejects requests for SRVCC Procedure.
When terminating an SRVCC Procedure, the MSC-S cancels the establishment

of the call leg or disconnects the established call leg towards the target cell
if the target cell belongs to the MSC-S handling the SRVCC Procedure, or
towards the Neighboring MSC-S if the target cell belongs to a Neighboring
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 45

MSC-S. In case a TMSI (re)allocation was already successfully completed,

the HLR update is performed.
Rejection with Response Message
Under certain conditions the MSC-S rejects the request for SRVCC Procedure
by responding to the MME with an Sv-Interface protocol SRVCC PS TO
CS RESPONSE message indicating an unsuccessful result. In these cases
the MSC-S terminates the SRVCC Procedure and discards all security key
information which is present for the subscriber.
Y
Table 14 describes the cause codes and SRVCC reject causes, which are
R
included in the Sv-Interface protocol SRVCC PS TO CS RESPONSE message,
for each condition. For a description of possible unsuccessful cases related
to protocol handling, refer to the Function Specification Sv-Interface, General
A
Aspects, Message Formats and Coding for SRVCC, and to the Function
Specification GTPv2-C, General Aspects, Formats and Codes.
Table 14
CONDITION
SRVCC PS TO CS RESPONSE Message
CAUSE CODE
IN
Cause Codes and SRVCC Reject Causes Indicated in the Sv-Interface protocol
SRVCC REJECT CAUSE

IM
The call leg between MSC and IMS Request rejected Permanent Session Leg
(1)
cannot be established. Establishment error
OR
EL
Temporary Session Leg

(1)
Establishment error
The subscriber for whom the SRVCC Relocation failure Handover/Relocation failure
Procedure is already ongoing while with Target System
PR
another CM transaction is triggered.

At reception of Sv-Interface protocol Service not supported Handover/Relocation target
SRVCC PS TO CS REQUEST not allowed
message with target Cell ID,
the feature is deactivated or not
supported.
The target Cell ID received in the Request rejected Unknown target ID
Sv-Interface protocol SRVCC PS TO
CS REQUEST message is unknown
to the MSC-S.
The IP address of the MME, received Mandatory IE incorrect Unspecified
in the Sv-Interface protocol SRVCC
PS TO CS REQUEST message does
not match the administered MME
data.
46 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Table 14 Cause Codes and SRVCC Reject Causes Indicated in the Sv-Interface protocol
CONDITION CAUSE CODE SRVCC REJECT CAUSE
The subscriber for whom the Request rejected Unspecified
SRVCC Procedure is to be triggered
already has another CM transaction
(2)
ongoing.
The BSSMAP HANDOVER REQUEST Request rejected Unspecified
Y
procedure terminates unsuccessfully
with cause code ‘‘Semantic Error’’,
or ‘‘Unspecified Failure’’.
R
The BSSMAP HANDOVER REQUEST No resource available Unspecified
procedure terminates unsuccessfully
with cause code ‘‘No resource
A
available’’.
Any other not listed event occurs, Request rejected Unspecified
which leads to termination of SRVCC
Procedure, before the Sv-Interface
SRVCC PS TO CS RESPONSE is
sent.
IN
IM
(1) AXE Internal Cause values 1,7, and 10 are mapped to Permanent Session Leg Establishment error, the rest of
AXE Internal Cause values in the 0-255 range are mapped to Temporary Session Leg Establishment error. PAPs
determine the mapping of AXE Internal Cause codes within the 0-255 range either to permanent or temporary
Session Leg Establishment error. For information on mapping SIP External Cause values to AXE Internal
EL
Cause values, refer to Application Information Mapping of Cause Codes and Location Information.
(2) Except Short Message Service (SMS) over SGs.
Rejection with Complete Notification Message

PR
If setup of the session transfer call leg fails and MSC-S has already sent
Sv-Interface protocol SRVCC PS TO CS RESPONSE message, then the
Sv-Interface protocol SRVCC PS TO CS COMPLETE NOTIFICATION
message is sent to MME (after handover has been successfully completed)
with SRVCC post failure cause as indicated in Table 15.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 47

Table 15 SRVCC Post Failure Causes Indicated in the Sv-Interface Protocol

SRVCC PS TO CS COMPLETE NOTIFICATION Message
CONDITION SRVCC POST FAILURE CAUSE
The call leg between MSC-S and Permanent Session Leg
(2)
IMS cannot be established or is Establishment error
disconnected due to a fault of
(1)
permanent nature.
The call leg between MSC-S and Temporary Session Leg
(2)
Y
IMS cannot be established or is Establishment error
disconnected due to a fault of
(3)
temporary nature.
R
(1) Any received SIP 404, 410, 484 or 604 message is treated as permanent fault and causes
the termination of SRVCC Procedure. The reception SIP 488 message is not treated as
permanent fault. For more information on the handling of SIP 488, refer to Function Specification
A
Session Initiation Protocol.
(2) AXE Internal Cause values 1,7, and 10 are mapped to Permanent Session Leg
Establishment error, the rest of AXE Internal Cause values in the 0-255 range are mapped
IN
to Temporary Session Leg Establishment error. PAPs determine the mapping of AXE
Internal Cause codes within the 0-255 range either to permanent or temporary Session
Leg Establishment error. For information on mapping SIP External Cause values to AXE
Internal Cause values, refer to Application Information Mapping of Cause Codes and
IM
Location Information.
(3) Any received SIP 408, 480 or 481 message is treated as temporary fault and causes the
termination of SRVCC Procedure.
EL
Rejection after Complete Notification with No Further Indication to MME
The MSC-S disconnects the ongoing call towards the IMS without any
notification to the MME if one of the following events occurs:
PR
• No BSSMAP HANDOVER COMPLETE message is received in case the

target cell belongs to the MSC-S handling the SRVCC Procedure, or no
MAP SEND END SIGNAL message is received in case the target cell
belongs to a Neighboring MSC-S before expiry of the corresponding timer.
• The TMSI allocation fails for a subscriber who was not registered in VLR
upon the reception of Sv-Interface protocol SRVCC PS TO CS REQUEST
message, or the subscriber was registered and had no TMSI allocated.
• The MAP Update Location procedure towards the HLR fails.
• The call leg between MSC-S and IMS cannot be established or a DTAP call
clearing message is received after the Sv-Interface protocol SRVCC PS TO
CS COMPLETE NOTIFICATION message has already been sent.
48 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
3.2.17 Interactions between MSC-S and MGW

In this section the interactions between the MSC-S, or Neighboring MSC-S, and
the MGW are described. GCP is used on the Mc-Interface for communication
between the MSC-S and the MGW. GCP is also used on Mn interface
when MSC-S acts as MGCF in order to control IM-MGW. MGW selection is
performed by the MSC-S and Neighboring MSC-S as described in the Function
Specification Media Gateway Selection in MSC Server, GMSC Server and TSC
Server. The main focus in the figures is put on GCP messages.
Y
Other signalling messages are only shown if they serve as trigger for a GCP
message to be sent to the MGW, or if they are triggered by a GCP message
received in the MSC-S.
R
The MGW selection might not be optimized for the call subject to SRVCC
Procedure, in particular for the case when the target BSC belongs to the
A
Neighboring MSC-S and for which different configurable bearer set-up
directions are on the BICC call leg between the MSC-S with Sv-Interface to
MME and Neighboring MSC-S.
IN
The figures in the following subsections are examples covering indicated bearer
set-up directions.
IM
Note: In the following sections in all figures the through connection line
represents only the through connection of the part of the speech path
controlled by MSC-S.
3.2.17.1 Handover scenario1: Target Cell belongs to MSC-S

EL
The interactions between MSC-S and MGW result in a final configuration of

contexts and terminations as described in Figure 29 and Figure 30.
Note: Solid lines are used to represent signalling connections. Dotted lines
PR
are used to represent user plane connections.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 49

Y
R
Figure 29 Final Configuration of Contexts and Terminations for active call,
originating call in alerting state, terminating call in alerting state,
A
originating call in pre-alerting state and active conference call;
Target BSC Belongs to MSC-S
IN
The final configuration shown in Figure 29 is applicable for the following traffic
cases:
IM
• Active call
• Originating call in alerting state
• Terminating call in alerting state

EL
• Originating call in pre-alerting state
• Active Conference call

PR
MSC-S
SIP GCP BSSMAP
IMS RTP/UDP
Network T2 T1
CTX1 target
MGW BSC
Figure 30 Final Configuration of Contexts and Terminations for held call;

The final configuration shown in Figure 30 is applicable for the held call.
50 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
In the following figures the interactions between the MSC-S and the MGW,
leading to the described final configuration of contexts and terminations, are
shown in detail.
Bearer Seizure for SRVCC Call
Sv-Interface Protocol BSSMAP Target

MME MSC-S BSC
SIP GCP
IMS MGW
Y
SRVCC PS TO CS
R
REQUEST
ADD.req (Ctx=?,T=?,
A
strmMode=SR)
Reserve RTP
Connection Point ADD.rep (Ctx=1,T=T1)
IN ADD.req (Ctx=1,T=?,
HANDOVER
REQUEST
IM
Reserve IMS strmMode=RO)
Connection Point
+ Change IMS ADD.rep (Ctx=1,T=T2)
Through Connection HANDOVER
REQUEST
EL
ACKNOWLEDGE
MOD.req (Ctx=1,T=T1)
Configure RTP
Connection Point MOD.rep (Ctx=1,T=T1)
(GSM Side)
PR
SRVCC PS TO CS
RESPONSE
INVITE
Figure 31 Bearer Seizure for SRVCC Call
Note: Dashed lines are used to indicate dependencies.
Note: For active conference calls the same handling applies as for active calls
As shown in Figure 31 the MSC-S seizes two bearer terminations upon

reception of an Sv-Interface protocol SRVCC PS TO CS REQUEST message:
• One bearer termination towards the BSC to which the target cell belongs,
by initiating a GCP Reserve RTP connection point procedure
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 51

• One bearer termination towards the IMS network by initiating GCP Reserve
IMS Connection Point and Change IMS Through Connection procedures
The MSC-S continues with triggering the Handover of the subscriber as

described in Section 3.2.2 on page 11. When the BSSMAP HANDOVER
REQUEST ACKNOWLEDGE message is received, the MSC-S configures the
termination towards the target BSC by initiating a GCP Configure RTP
Connection Point procedure.
Y
Through Connection of Active Call
Target
R
IMS SIP MSC-S BSSMAP
BSC
GCP
MGW
A
INVITE
200 OKINVITE
IN
MOD.req (Ctx=1, T=T2)
IM
Configure IMS
Resources MOD.rep (Ctx=1, T=T2)
ACK
EL
User Plane Backward

Through Connected
HANDOVER DETECT
MOD.req (Ctx=1, T=T2,
PR
strmMode=SR)
Change IMS
Through Connection MOD.rep (Ctx=1, T=T2)
User Plane Bothway

Through Connected
HANDOVER COMPLETE
Figure 32 Through Connection of Active Call
As shown in Figure 32, when the SIP 200 OK INVITE message is received in the
MSC-S , as answer to the previously sent SIP INVITE message, the MSC-S
configures the bearer termination towards the IMS network, based on the data
received in the SIP 200 OK INVITE message, by initiating a GCP Configure
IMS Resources procedure.
52 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Note: The Configure IMS Resources procedure can also be triggered by a SIP
183 Session Progress message, if it contains the SDP answer.
When the MOD reply message as part of the GCP Configure IMS Resources
procedure, and a BSSMAP HANDOVER DETECT message are received in
the MSC-S, the MSC-S changes the stream mode of the bearer termination
towards the IMS network by initiating a GCP Change IMS Through Connection
procedure. This results in the through connection of the speech path in both
directions.
Y
In case a BSSMAP HANDOVER COMPLETE message is received without
having received a BSSMAP HANDOVER DETECT message before, the MSC-S
initiates the GCP Change IMS Through Connection procedure as soon as the
R
MOD reply message of GCP Configure IMS Resources procedure and the
BSSMAP HANDOVER COMPLETE message are received.
A
Note: Figure 32 does not consider the following case. Set-up of the call
leg to IMS happens in parallel to the LTE to GSM handover. In case
LTE to GSM handover finishes before set-up of the call leg to IMS, it
IN
can happen that UE sends a DTAP CONNECT message to both, IMS
and MSC-S, so MSC-S can receive first DTAP CONNECT message
and then SIP 200 OKINVITE message. In that specific case, upon
DTAP CONNECT reception, the MSC-S changes the stream mode of
IM
the bearer termination towards the IMS network by initiating a GCP
Change IMS Through Connection procedure. This results in the
through connection of the speech path in both directions.
EL
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 53

Through Connection of Held Call
IMS SIP RANAP Target

MSC-S RNC
GCP
MGW
INVITE
200 OKINVITE
Y
MOD.req (Ctx=1, T=T2
strmMode=SR)
R
Change IMS
A
RELOCATION DETECT
strmMode=Inactive)
Change
Through Connection IN
MOD.rep (Ctx=1, T=T1)
User Plane Inactive

IM
RELOCATION
Through Connected COMPLETE
Configure IMS
EL
ACK
Figure 33 Through Connection of Held Call

PR
MSC-S, as answer to the previously sent SIP INVITE message, the MSC-S
changes the stream mode of the bearer termination towards the IMS network
and as well as the bearer termination towards the target BSC by initiating GCP
Change IMS Through Connection and Change Through Connection procedures
correspondingly. This results in inactive through connection of the speech path.
When the MOD reply message as part of the GCP Change Through
Connection procedure towards the target BSC is received, the MSC-S
54 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Configuration of Bearer Resources for Call in Alerting State
IMS SIP MSC-S GCP MGW
INVITE

strmMode=RO)
Y
Configure IMS
R
User Plane Backward
Through Connected
A
PRACK
Figure 34
IN
Configuration of Bearer Resources for Call in Alerting State
As shown in Figure 34, for a call in alerting state, when the SIP 183 Session
Progress message is received in the MSC-S, as answer to the previously
IM
sent SIP INVITE message, the MSC-S configures the bearer termination
towards the IMS network, based on the data received in the SIP 183 Session
Progress message, by initiating a GCP Configure IMS Resources procedure.
EL
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 55

Through Connection for Originating Call in Alerting State
IMS SIP BSSMAP Tsrmet

MSC-S BSC
GCP
MGW
200 OKINVITE
Y
Configure IMS
R
ACK
A
HANDOVER DETECT
otrd Mage=SR)
Change IMS
Through Connection IN
User Plane Bothway

IM
Through Connected HANDOVER
COMPLETE
Figure 35 Through Connection for Originating Call in Alerting State

EL
As shown in Figure 35, for a originating call in alerting state, when the SIP 200
OK INVITE message is received in the MSC-S, as answer to the previously sent
SIP INVITE message, the MSC-S configures the bearer termination towards
the IMS network based on the data received in SIP 200 OK INVITE by initiating a
GCP Configure IMS Resources procedure.
PR
When the MOD reply message as part of the GCP Configure IMS Resources
procedure, and a BSSMAP HANDOVER DETECT message are received in
the MSC-S, the MSC-S changes the stream mode of the bearer termination
towards the IMS network by initiating a GCP Change IMS Through Connection
procedure. This results in the through connection of the speech path in both
directions.
In case a BSSMAP HANDOVER COMPLETE message is received without having

received a BSSMAP HANDOVER DETECT message before, the MSC-S initiates
the GCP Change IMS Through Connection procedure as soon as the MOD
reply message of the GCP Configure IMS Resources procedure and the
BSSMAP HANDOVER COMPLETE message are received.
56 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Through Connection for Terminating Call in Alerting State
For terminating call in alerting state two traffic cases are considered in this
subsection:
• SIP INFO message is received in MSC-S before DTAP CONNECT message
• SIP INFO message is received in MSC-S after DTAP CONNECT message
Y
GCP
BSSMAP Target
MGW
BSC
R
INFO
200 OKINFO
A
strmMode=Inactive)
Change IMS
IN
User Plane Inactive
Through Connected
HANDOVER
DETECT
IM
HANDOVER
COMPLETE
CONNECT
strmMode=SR)
EL
Change IMS
Through Connection MOD.rep (Ctx=1, T=T2) CONNECT
ACKNOWLEDGE
User Plane Bothway

Through Connected
PR

200 OKINFO
200 OKINVITE

Configure IMS
ACK
Figure 36 Through Connection for Terminating Calls in Alerting State in case

SIP INFO message is received in MSC-S before DTAP CONNECT
message
Note: Bothway Through Connection will be established when negotiated

SDP media direction attribute, before DTAP CONNECT reception, is
"sendrecv".
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 57

As shown in Figure 36, for a terminating call in alerting state, when the SIP
INFO message is received before DTAP CONNECT message, the MSC-S
changes the stream mode of the bearer termination towards the IMS network
by initiating a GCP Change IMS Through Connection procedure. This results in
an inactive through connection of the speech path.
When the DTAP CONNECT message and a BSSMAP HANDOVER DETECT

message are received in the MSC-S, the MSC-S changes the stream mode of
the bearer termination towards the IMS network by initiating a GCP Change
IMS Through Connection procedure. This results in the through connection of
Y
the speech path in both directions.
When the SIP 200 OK INVITE message is received in the MSC-S, as answer
R
to the previously sent SIP INVITE message, the MSC-S configures the
bearer termination towards the IMS network by initiating a GCP Configure
A
In case a HANDOVER COMPLETE message is received without having received
a HANDOVER DETECT message before, the MSC-S initiates the GCP Change
IN
IMS Through Connection procedure as soon as the MOD reply message of
the GCP Configure IMS Resources procedure and the HANDOVER COMPLETE
message are received
IM
EL
PR
58 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function

GCP
Target
MGW BSSMAP
BSC
HANDOVER
DETECT
HANDOVER
COMPLETE
CONNECT
Y
strmMode=SR)
Change IMS
Through Connection MOD.rep (Ctx=1, T=T2) CONNECT
ACKNOWLEDGE
R
User Plane Bothway
Through Connected
A
INFO
200 OKINFO
200 OKINFO
200 OKINVITE
IN
IM
Configure IMS
ACK
EL
Figure 37 Through Connection for Terminating Calls in Alerting State in case

SIP INFO message is received in MSC-S after DTAP CONNECT
message
PR
Note: The Bothway Through Connection will be established if the negotiated

SDP media direction attribute, before DTAP CONNECT reception, is
"sendrecv" and either P-Early-Media header is not received or it
is received and has value "sendrecv". For more information refer to
Function Specification Interworking with IMS Multimedia Telephony.
As shown in Figure 37, when the DTAP CONNECT message and a BSSMAP
HANDOVER DETECT message are received in the MSC-S, the MSC-S changes
the stream mode of the bearer termination towards the IMS network by initiating
a GCP Change IMS Through Connection procedure. This results in the through
connection of the speech path in both directions.
For a terminating call in alerting state, when the SIP INFO message is received
in the MSC-S after DTAP CONNECT message, the MSC-S does not change the
stream mode of the bearer termination towards the IMS network by initiate a
GCP Change IMS Through Connection procedure.
When the SIP 200 OK INVITE message is received in the MSC-S, as answer
to the previously sent SIP INVITE message, the MSC-S configures the
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 59

bearer termination towards the IMS network by initiating a GCP Configure

Configuration of Bearer Resources for Originating Call in Pre-Alerting

State
For a originating call in pre-alerting state when the SIP 183 Session
Progress message is received in the MSC-S, as answer to the previously
sent SIP INVITE message, the MSC-S configures the bearer termination
towards the IMS network, based on the data received in the SIP 183 Session
Y
Progress message, by initiating a GCP Configure IMS Resources procedure,
the same way is done for originating call in alerting state, as shown in Figure 34.
R
It is instead possible to receive a first SIP 183 Session Progress message
with an SDP answer containing an unspecified address, in this case the
A
following applies as shown in Figure 38.
IN
IM
EL
PR
60 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
IMS SIP MSC-S GCP MGW
INVITE
([SDP Answer with
c=0.0.0.0], Dialog D1)
strmMode=SR)
Conf i gure
Y
I oM
SRi ouCSf f gscUSf
strmMode=inactive)
R
Conf i guI oMSRi o
CSf f gscUSf MOD.rep (Ctx=1, T=T1)
A
CSf hUi RMgure
t gl SRMsgl
PRACK (Dialog D1)

IN
Pl gMua Bnf guk nswd nMT

I oMSRi ouCSf f gscgT
IM
200 OKPRACK (Dialog D1)
INFO (Dialog D1)

EL
200 OKINFO (Dialog D1)

([SDP Answer], Dialog D2)
PR
strmMode=RO)
Conf i gure
I oM
SRi ouCSf f gscUSf
strmMode=SR)
Conf i guI oMSRi o
CSf f gscUSf MOD.rep (Ctx=1, T=T1)

CSf hUi RMgure
t gl SRMsgl MOD.rep (Ctx=1, T=T2)
Pl gMua Bnf guk nswd nMT

PRACK (Dialog D2) I oMSRi ouCSf f gscgT
Figure 38 Configuration of Bearer resources for Originating Calls in

Pre-alerting State
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 61

As shown in Figure 38, for a originating call in pre-alerting state when the SIP
183 Session Progress message is received in the MSC-S, as answer to
the previously sent SIP INVITE message with an SDP answer:
• with connection address in SDP answer set to the unspecified address

(0.0.0.0 if IPv4, or domain name within the ".invalid" DNS top-level domain
in case of IPv6)
Y
• including media of media types received in SDP offer
the MSC-S changes the stream mode of the bearer termination towards the
R
BSC to inactive by initiating a GCP Change Through Connection procedure.
This results in an inactive through connection of the speech path. After the
reception of SIP 200 OKPRACK message the MSC-S is expecting a SIP INFO
A
message.
The second SIP 183 Session Progress message with SDP answer
IN
received within a new early dialog contains the remote UE media data based on
which MSC-S configures the bearer termination towards the IMS network using
a GCP Configure IMS Resources procedure and changes the stream mode of
the bearer termination towards the target BSC using a GCP Change Through
IM
Connection procedure. This results in the backward through connection of
the speech path.
Through Connection for Originating Calls in Pre-alerting State

EL
For bothway through-connection for originating pre-alerting call is the same as

Through Connection for originating call in alerting state as shown in Figure 35.
3.2.17.2 Handover scenario 2: Target Cell belongs to Neighboring MSC-S

PR
In the following the interactions between MSC-S and MGW are described
exemplary using BICC for call control between MSC-S and Neighboring MSC-S,
and applying backward bearer setup. This results in a final configuration of
contexts and terminations as described in Figure 39 and Figure 40.
Note: Solid lines are used to represent signalling connections. Dotted lines
are used to represent bearer connections.
62 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
neighb.
MSC-S MSC-S
MAP
BICC
SIP GCP GCP BSSMAP
IMS RTP/UDP NbUP AUP

Network T4 T3 T2 T1
CTX2 CTX1 target
Y
MGW1 MGW2 BSC
Figure 39 Final Configuration of Contexts and Terminations for active call,

originating call in alerting state, terminating call in alerting state,
R
originating call in pre-alerting state and active conference call;
Target Cell belongs to Neighboring MSC-S
A
The final configuration shown in Figure 39 is applicable for the following traffic
cases:
•
Active call
Originating call in alerting state

IN
IM
• Terminating call in alerting state
• Originating call in pre-alerting state

EL
• Active Conference call

neighb.
MSC-S MSC-S
MAP
PR
BICC
SIP GCP GCP BSSMAP
IMS RTP/UDP AUP

Network T4 T3 T2 T1
CTX2 CTX1 target
MGW1 MGW2 BSC
Figure 40 Final Configuration of Contexts and Terminations for held call;

The final configuration shown in Figure 40 is applicable for the held call.
In the following figures the interactions between the MSC-S and the MGW,
leading to the described final configuration of contexts and terminations, are
shown in detail. The figures do not contain all NbUP messages, all AUP
messages, and all messages between the target BSC and the Neighboring
MSC-S.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 63

Bearer Seizures for Active or Held Call
MME
Sv-Interface Protocol
MSC-S
MAP Neighboring BSSMAP Target
BICC or ISUP MSC-S BSC
GCP
GCP
MGW1 MGW2
SRVCC PS TO CS
REQUEST
PREPARE
HANDOVER
REQUEST
Y
ADD.req (Ctx=?,T=?,
strmMode=SR)
Reserve IMS
ADD.rep (Ctx=2, T=T4)
R
Connection Point ADD.req (Ctx=?,T=?,
strmMode=SR)
Prepare Bearer
(GSM side, IP) ADD.rep (Ctx=1,T=T1)
A
HANDOVER
REQUEST
HANDOVER
REQUEST
IN
Configure RTP
Connection Point
MOD.req (Ctx=1,T=T1)
MOD.rep (Ctx=1,T=T1)
ACKNOWLEDGE
IM
(GSM Side)
PREPARE
HANDOVER
RESPONE
Prepare Bearer ADD.req (Ctx=2,T=?,
(CN side, IP)+ strmMode=SO)
EL
Tunnel Information
Down + ADD.rep (Ctx=2, T=T3)
Tunnel Information
Up
IAM
PR
Figure 41 Bearer Seizures for Active or Held Call, Part1
As shown in Figure 41, the MSC-S seizes a bearer termination towards the
IMS network by initiating a GCP Reserve IMS Connection Point procedure
upon reception of the Sv-Interface protocol SRVCC PS TO CS REQUEST
message and sends a MAP PREPARE HANDOVER request message towards
the Neighboring MSC-S.
The Neighboring MSC-S in turn seizes a bearer termination towards the target
BSC, by initiating a GCP Prerare Bearer procedure upon reception of this MAP
message. When the BSSMAP HANDOVER REQUEST ACKNOWLEDGE message
is received in the Neighboring MSC-S, the Neighboring MSC-S configures
the termination towards the target BSC by initiating a GCP Configure RTP
Connection Point procedure.
64 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
When the ADD reply message as part of the GCP Reserve IMS Connection
Point procedure, and the MAP PREPARE HANDOVER response message are
received in the MSC-S, the MSC-S seizes a bearer termination in MGW1
towards MGW2 by initiating the following GCP procedures:
• Prepare Bearer
• Tunnel Information Down
• Tunnel Information Up
As soon as the ADD reply message as part of the above listed GCP
Y
procedures is received, the MSC-S sends an INITIAL ADDRESS MESSAGE to
the Neighboring MSC-S applying backward bearer setup.
R
A
IN
IM
EL
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 65

SIP
Neighboring
IMS MSC-S BICC or ISUP
MSC-S
Sv-Interface
Protocol GCP
GCP
MME MGW1 Nb UP MGW2
ADD.req (Ctx=?, T=?

Establish Bearer (CN Side, IP) strmMode=SR)
+ Tunnel Information Down
+ Change Through Connection ADD.rep (Ctx=3, T=T2)
Y
+ Tunnel Information Up
NOTIFY.req(Ctx=3,T=T2)
NOTIFY.rep(Ctx=3,T=T2)
R
APM
MOD.req
A
(Ctx=2, T=T3)
Tunnel
Information MOD.rep
(Ctx=2, T=T3)
Down
Nb UP Init
NOTIFY.req
(Ctx=2,T=T3)
IN
IM
Tunnel
NOTIFY.rep
Information (Ctx=2,T=T3)
Up
APM
Tunnel
EL

Information
Nb UP Init Ack Down
PR
NOTIFY.req(Ctx=3,T=T2)
Bearer
Established NOTIFY.rep(Ctx=3,T=T2)
MOV.req(Ctx=1,T=T3)
Join Bearer
Termination MOV.rep(Ctx=1,T=T3)
SRVCC ACM
PS TO CS
RESPONSE
INVITE
Figure 42 Bearer Seizures for Active or Held Call, Part 2
66 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
As shown in Figure 42, the Neighboring MSC-S continues with seizing the
bearer termination in MGW2 towards MGW1 by initiating the following GCP
procedures upon the reception of BICC INITIAL ADDRESS MESSAGE:
• Establish Bearer
• Tunnel Information Down
• Change Through Connection
• Tunnel Information Up
Y
The MSC-S and the Neighboring MSC-S continue with the establishment of the
bearer between MGW1 and MGW2.
R
As soon as the Neighboring MSC-S is informed by MGW2 that the bearer
connection towards MGW1 is established by means of a GCP Bearer
A
Established procedure, it joins both bearer connections into one context by
means of a GCP Join Bearer Termination procedure and sends a BICC
ADDRESS COMPLETE message towards the MSC-S.
IN
IM
EL
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 67

Through Connection of Active Call
SIP MAP Neighboring BSSMAP Target

IMS MSC-S
BICC or ISUP MSC-S BSC
GCP GCP
MGW1 MGW2
INVITE
200 OKINVITE
Y
MOD.req
(Ctx=2,T=T4,)
Configure IMS
R
MOD.rep
Resources (Ctx=2,T=T4)
A
User Plane Backward
Through Connected
ACK
IN PROCESS
ACCESS
SIGNALLING
HANDOVER
DETECT
IM
ANM
MOD.req(Ctx=2,
T=T3,strmMode=SR)
Change Through MOD.rep
EL
Connection (Ctx=2,T=T3)
User Plane Bothway HANDOVER

Through Connected COMPLETE
on All Call Legs
PR
SEND END
SIGNAL
Figure 43 Through Connection of Active Call
MSC-S , as answer to the previously sent SIP INVITE message, the MSC-S
68 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
After the reception of the BICC ANSWER message in addition to the GCP MOD
reply message of the GCP Configure IMS Resources procedure, the MSC-S
changes the stream mode of the bearer termination in MGW1 towards MGW2
by initiating a GCP Change Through Connection procedure. This results in the
through connection of the speech path in both directions. A PAP can disable
that the received BICC ANSWER message triggers both way through connection
on the speech path if the MAP PROCESS ACCESS SIGNALLING message has
not been received yet.
In case a MAP SEND END SIGNAL message is received without having
Y
received a MAP PROCESS ACCESS SIGNALLING message before, the MSC-S
initiates the GCP Change Through Connection procedure as soon as the MOD
reply message of the GCP Configure IMS Resources procedure and the MAP
R
SEND END SIGNAL message are received.
A
Through Connection of Held Call
IMS SIP MSC-S MAP Neighboring BSSMAP Target
MGW1
GCP
INVITE
INBICC or ISUP
MGW2 GCP
MSC-S BSC
IM
200 OKINVITE
MOD.req(Ctx=2,T=T3,
strmMode=Inactive)
CvsaeMSl vIh ev MOD.rep
ChaaMt Ugha (Ctx=2,T=T3)
EL
i cMISf RsaMSTast UgPM

l vIh evSChaaMt UMd
MOD.req(Ctx=2,
T=T3,strmMode=SR)
Change IMSTr o MOD.rep
u Mch It Mc (Ctx=2,T=T3)
PR
ACK
HANDOVER
DETECT
PROCESS
ACCESS
SIGNALLING
ANM
HANDOVER
COMPLETE
SEND END
SIGNAL
Figure 44 Through Connection of Held Call
MSC-S, as answer to the previously sent SIP INVITE message, the MSC-S
changes the stream mode of the bearer termination in MGW1 towards MGW2
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 69

by initiating GCP Change Through Connection procedure. This results in

inactive through connection of the speech path.
When the MOD reply message as part of the GCP Change Through
Connection procedure in MGW1 bearer termination towards MGW2 is received,
the MSC-S configures the bearer termination towards the IMS network, based
on the data received in the SIP 200 OK INVITE message, by initiating a GCP
Configure IMS Resources procedure.
Y
3.2.18 SRVCC Procedure for Emergency Call
The subsections below contain the description of the SRVCC Procedure for
R
emergency calls that differ from the corresponding description when handling
non-emergency calls in active state.
A
The optional procedure Location Continuity, described in Section 3.2.18.7 on
page 72, is applicable only to an emergency call.
3.2.18.1 Initiation of SRVCC

IN
Apart from the differences specified below, the SRVCC Procedure is initiated
as described in Section 3.2.1 on page 11.
IM
MSC-S detects that the transfer request concerns an emergency call based on
the presence of EmInd in Sv Flags IE as received in the Sv-Interface protocol
SRVCC PS TO CS REQUEST message from MME.
EL
To identify the mobile subscriber involved in the SRVCC Procedure, the MSC-S
uses the following identifier provided by the MME in the Sv-Interface protocol
SRVCC PS TO CS REQUEST message:
• IMSI if it is provided,
PR
• IMEI if IMSI is not provided. In case of emergency calls, IMEI is always

included in this message.
In both cases, if the subscriber was not registered in VLR before the reception
of the Sv-Interface protocol SRVCC PS TO CS REQUEST message, then the
subscriber is temporary registered in VLR.
3.2.18.2 Handover Request
Apart from the differences specified below, the handover is requested as

described in Section 3.2.2 on page 11.
If IMSI is not received from the MME in the Sv-Interface protocol SRVCC PS
TO CS REQUEST message, the following handling is applied:
• If the target cell belongs to the MSC-S handling the SRVCC Procedure, the
IMSI IE is not included in the BSSMAP HANDOVER REQUEST message,
70 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
and the Encryption Information IE, which is included in the message,

is set to ‘‘No encryption’’.
• If the target cell belongs to a Neighboring MSC-S and MAPV3 is used

to encapsulate the BSSMAP messages, the IMSI and Integrity
Protection Information IEs are not included in the MAP PREPARE
HANDOVER request message, and the Encryption Information IE,
which is included in the message, is set to ‘‘No encryption’’.
3.2.18.3 IMS Session Transfer
Y
Apart from the differences specified below, the emergency session transfer is
R
performed as described in Section 3.2.4 on page 16 and Page 19.
MSC-S initiates the session transfer towards the IMS network based on the
A
B-number analysis of Emergency Session Transfer Number for SRVCC
(E-STN-SR) administered in MSC-S. The origin for B-number analysis is
determined by the setting of AXE parameter SRVCCEMERGBO in parameter
set GSMMSSC.
IN
The SIP route for connection to the Emergency Access Transfer Function
(EATF) in IMS uses the same attributes for route parameters as the SIP route
IM
to ATCF, which is the route in case of a non-emergency call.
The content of the SIP INVITE message has the following differences
compared to the content described in Table 7:
EL
• From header:
If no C-MSISDN is received from the MME in the Sv-Interface protocol

SRVCC PS TO CS REQUEST message, the value ‘‘unavailable user
identity’’ is used in this header.
PR
• P-Asserted-Identity header:
If no C-MSISDN is received from the MME in the Sv-Interface protocol

SRVCC PS TO CS REQUEST message, this header is not populated.
• Contact header:
MSC-S populates the sip.instance media feature tag in this header

based on the received MEI IE provided by the MME. For more information,
refer to Function Specification Session Initiation Protocol.
• To header:
The E-STN-SR is used to populate this header.
• Priority header:
MSC-S includes this header with value ‘‘emergency’’.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 71

• Request-URI parameter:
The E-STN-SR is used to populate this parameter.
If a SIP 488 NOT ACCEPTABLE HERE message that contains SDP body is
received as response to the SIP INVITE message, the session transfer towards
IMS can be reinitiated. In case of reinitiation, the call is not disconnected and
the SRVCC Procedure is not terminated. For more details on the conditions for
such reinitiation of the session transfer, refer to Function Specification Session
Initiation Protocol.
Y
3.2.18.4 SRVCC Complete Notification to MME
R
Apart from the differences specified below, the notification of MME about the
completion of SRVCC is performed as described in Section 3.2.6 on page 26.
A
If IMSI is not provided by the MME in the Sv-Interface protocol SRVCC PS
TO CS REQUEST message, the Sv-Interface protocol SRVCC PS TO CS
3.2.18.5 TMSI Allocation

IN
COMPLETE NOTIFICATION message does not contain an IMSI.
IM
Apart from the differences specified below, TMSI allocation is performed as
described in Section 3.2.7 on page 28.
If IMSI is not provided by the MME in the Sv-Interface protocol SRVCC PS TO

CS REQUEST message, TMSI allocation is not performed.
EL
3.2.18.6 Location Update Towards HLR
In case of an emergency call subject to SRVCC Procedure, location update

PR
towards HLR is not performed.
3.2.18.7 Location Continuity
As shown in Figure 45, after the reception of the BSSMAP HANDOVER

COMPLETE message, depending on configuration option, the MSC-S sends
the MAP SUBSCRIBER LOCATION REPORT message carrying the identity of
the MSC-S towards a dedicated GMLC over Lg-Interface to support location
continuity. This GMLC needs to be associated with the emergency service
client handling the emergency call, and its address is configured by command
in the MSC-S.
The sending of MAP SUBSCRIBER LOCATION REPORT message is

configurable in MSC-S based on the Area Cluster administered for an MME. By
default MSC-S is set to send this message.
72 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
MAP BSSMAP
Target
GMLC MSC-S
BSC
HANDOVER
COMPLETE
SUBSCRIBER
LOCATION REPORT
Y
Figure 45 Location Continuity Procedure
R
The contents of the MAP SUBSCRIBER LOCATION REPORT message sent by
the MSC-S and the origin of included data are shown in Table 16.
A
Table 16 MAP SUBSCRIBER LOCATION REPORT
Parameters of MAP SUBSCRIBER Information Included in the MAP
LOCATION REPORT Message SUBSCRIBER LOCATION REPORT
Location Services (LCS) event type

(lcs-Event)
IN Message
‘‘Emergency call handover’’
IM
LCS client type (lcsClientType), ‘‘Emergency services’’
which is included in LCS client ID
(1)
(lcs-ClientID)
LCS location info (lcsLocationIn NetworkNode-Number containing the
EL
fo) MSC number

(2)
MSISDN • C-MSISDN
• non-dialable callback number,
which is a special number that
PR
consists of a configurable prefix

comprising 3 digits, and the last 7
(3)
digits of the provided IMEI
(2)
IMSI IMSI
IMEI IMEI
Target Serving Node for Handover MSC number
(targetServingNodeForHandov
er)
(1) lcsClientExternalID and lcsClientDialledByMS are not specified and are not
included in the message.
(2) This number is included if provided by MME in the Sv-Interface protocol SRVCC PS TO CS
REQUEST message.
(3) This number is only used if IMSI and C-MSISDN are not provided in the Sv-Interface protocol
SRVCC PS TO CS REQUEST message. The value of the prefix is determined by the setting of
AXE parameter NONDIALPREFIX in parameter set GSMLSSC.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 73

For a detailed description of the data received from the MME, refer to the
Function Specification Sv-Interface, General Aspects, Message Formats and
Coding for SRVCC.
As shown in Figure 46, if the target cell belongs to a Neighboring MSC-S, the
Location Continuity Procedure is triggered if configured, after the reception of
MAP SEND END SIGNAL message from the Neighboring MSC-S encapsulating
the BSSMAP HANDOVER COMPLETE message.
r hLgI Ui LGg Nei ghb
Y
RMDC MBA MSC-S MBA PSSMBA
MSC-S PSC
o Br n T a t H
R
CT MADt Nt
SOPSCHVPt H
DT CBNVT r EHt AT HN
A
SOPSCHVPt H
DT CBNVT r EHt AT HN
3.2.18.8
Figure 46
IN
Location Continuity Procedure, Neighboring MSC-S Scenario
Cancellation of SRVCC Procedure

IM
Apart from the differences specified below, a request from the MME to cancel
an ongoing SRVCC Procedure is handled as described in Section 3.2.14 on
page 44.
EL
If IMSI is not provided by the MME in the Sv-Interface protocol SRVCC PS

TO CS REQUEST message, MSC-S uses the received IMEI to correlate the
received cancellation request with the corresponding SRVCC Procedure. In
case there is neither an SRVCC Procedure, nor a CM transaction, ongoing
for an indicated IMEI, MSC-S rejects the cancellation request by sending an
PR
Sv-Interface protocol SRVCC PS TO CS CANCEL ACKNOWLEDGE message

with cause code ‘‘Request rejected’’.
3.2.18.9 Interaction between Requests for SRVCC Procedure
If an Sv-Interface protocol SRVCC PS TO CS REQUEST message is received

from the MME containing IMEI and no IMSI, and an SRVCC Procedure is
already ongoing for the indicated IMEI, the handling of the request is the same
as the handling of a request with IMSI for which an SRVCC Procedure is
already ongoing, see Section 3.2.15 on page 45.
3.2.18.10 Rejection of Requests for SRVCC Procedure
Apart from the differences specified below, the SRVCC Procedure is terminated
as described in the corresponding part of Section 3.2.16 on page 45.
74 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Rejection with Response Message
Table 17 contains the conditions at the reception of a Sv-Interface protocol

SRVCC PS TO CS REQUEST message that cause the rejection of the
handover request, and is only relevant for an emergency call. The procedure
of rejection is performed as described in the corresponding part in Section
3.2.16 on page 45.
Table 17 Cause Codes and SRVCC Reject Causes indicated in the Sv-Interface protocol
Y
CONDITION CAUSE CODE SRVCC REJECT CAUSE
E-STN-SR is not configured. Service not supported Permanent Session Leg
R
Establishment error
If IMSI is not provided by Service not supported Unspecified
A
the MME in the Sv-Interface
protocol SRVCC PS TO CS
REQUEST message and
an emergency call without
IMSI is not allowed to be
set up based on the setting
of EMCNOIMSI changeable
IN
IM
exchange parameter.
Rejection after Complete Notification with No Further Indication to MME

EL
If the TMSI allocation, the Location Continuity Procedure, or a location update

towards HLR fails, MSC-S does not disconnect the emergency call.
3.2.18.11 Interactions between MSC-S and MGW

PR
Apart from the differences specified below, the MSC-S and MGW interact as
described in Section 3.2.17 on page 48 for an active call.
In case the target cell belongs to the MSC-S handling the SRVCC Procedure,
when the bearer termination towards the target cell is seized, Emergency Call
Indication is provided to allow a preference handling in the MGW. In case
the target cell belongs to a Neighboring MSC-S, no emergency indication is
provided by the MSC-S handling the SRVCC Procedure to the Neighboring
MSC-S.
When the bearer termination towards IMS is seized, Emergency Call Indication
is provided to allow a preference handling in the MGW.
3.3 Interaction with Other Functions

All services are suppressed during an ongoing SRVCC Procedure. Exceptions
from this rule are described in this section.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 75

3.3.1 Alternate Speech/Fax
If a DTAP MODIFY request message, trying to switch between speech and fax,
is received from the UE while waiting for the SIP 200 OK INVITE message from
IMS during an ongoing SRVCC Procedure, the request is rejected. In case of
a call in alerting state or originating call in pre-alerting state, the request is
rejected with cause code ‘‘message type not compatible with protocol state’’,
otherwise with cause code ‘‘temporary failure’’.
If the SIP 200 OK INVITE message has already been received, the request is
Y
rejected with cause code ‘‘BC not presently available’’.
For more information on the Alternate Speech/Fax function, refer to Function
R
Specification Alternate Speech/Fax Gr.3 Transparent In MSC/VLR Server.
A
3.3.2 Announcement at Call Disconnection
Announcement at Call Disconnection is not supported for calls that are subject
to SRVCC Procedure.
IN
For more information on the Announcement at Call Disconnection function,
refer to Function Specification Announcement at Call Disconnection in
IM
MSC/VLR Server.
3.3.3 Announcement on No Reply or User Determined User Busy

EL
MSC-S does not invoke service ‘‘Announcement on no reply’’ for a terminating

call in alerting state that is subject to SRVCC Procedure.
MSC-S does not invoke service ‘‘Announcement at UDUB’’ for a terminating

call in alerting state that is subject to SRVCC Procedure.
PR
3.3.4 Basic Mobile Switching Services

When the MSC-S receives a terminating call for a subscriber involved in an
ongoing SRVCC Procedure, it rejects it with cause code ‘‘subscriber absent’’.
If a BSSMAP COMPLETE LAYER 3 INFORMATION or RANAP INITIAL UE

MESSAGE message is received during an ongoing SRVCC Procedure, and
Sv-Interface protocol SRVCC PS TO CS RESPONSE has not been sent yet,
then Sv-Interface protocol SRVCC PS TO CS RESPONSE is sent with cause
code ‘‘relocation failure’’ and SRVCC cause code ‘‘handover/relocation failure
with target system’’. Then SRVCC Procedure is aborted and the session
transfer call leg is disconnected if SIP INVITE has already been sent.
If a BSSMAP COMPLETE LAYER 3 INFORMATION message is received after

the Sv-Interface protocol SRVCC PS TO CS RESPONSE is sent, the SRVCC
Procedure is aborted. Additionally, the session transfer call leg is disconnected
if SIP INVITE has already been sent.
76 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
The same handling applies if a Location Update request is received over Gs

or SGs interface.
The BSSMAP COMPLETE LAYER 3 INFORMATION message can carry CM

Service Request, Location Updating Request or IMSI Detach
Indication.
3.3.5 BSC Recording Initiation in MSC/VLR Server
Y
BSC Recording Initiation is not supported for calls that are subject to SRVCC
Procedure.
R
For more information on the BSC Recording Initiation function, refer to Function
Specification BSC Recording Initiation in MSC/VLR Server.
A
3.3.6 BSS Trace Invocation in MSC/VLR Server
IN
The SRVCC Procedure is not used as a trigger for BSS Trace Invocation.
MSC-S based trace invocation and HLR based trace invocation apply to parallel
transactions after SRVCC Procedure.
IM
For more information on the BSS Trace Invocation function, refer to Function
Specification BSS Trace Invocation in MSC/VLR Server.
3.3.7 Call Forwarding on No Reply

EL
MSC-S does not invoke the service ‘‘Call forwarding on no reply’’ when a
terminating call in alerting state that was subject to SRVCC Procedure is not
answered.
PR
3.3.8 Call Forwarding on User Busy

MSC-S does not invoke the service ‘‘Call forwarding on user busy’’ when
a terminating call in alerting state that was subject to SRVCC Procedure is
rejected with reason ‘‘user busy’’.
3.3.9 Call Hold

DTAP HOLD
During SRVCC procedure, if MSC-S receives a DTAP HOLD request from a

local UE for a call before the MSC-S state is known, that is before the reception
of SIP INFO, SIP 200 OK INVITE or DTAP CONNECT message, the request is
rejected with cause code ‘‘temporary failure’’.
In case of a terminating call in alerting state, if a DTAP HOLD request is received

during SRVCC procedure after MSC-S receives a DTAP CONNECT message
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 77

from UE but before it receives a SIP 200 OK INVITE from IMS, the request is
rejected with cause code ‘‘temporary failure’’.
In case the MSC-S state for a terminating call in alerting state, or for an
originating call is alerting or pre-alerting state is known, but has not yet reached
the active MSC-S state, the request is rejected with cause code ‘‘message type
not compatible with protocol state’’.
In case of emergency calls, the request is rejected during SRVCC procedure

with the following cause code:
Y
• Cause code ‘‘facility rejected’’ if the subscriber was registered in VLR and
R
was subscribed to the supplementary service (SS) before the SRVCC
Procedure,
A
• Cause code ‘‘requested facility not subscribed’’ if the subscriber was not
subscribed to the supplementary service or was not registered in VLR
before the SRVCC Procedure.
IN
If non of the above mentioned cases applies, DTAP HOLD request received
during or after SRVCC procedure is accepted as described in Function
Specification Call Hold in MSC/VLR Server.
IM
Note: No call hold announcement or hold tone is played from MSC-S towards
IMS on the call leg controlled by the Mw interface.
EL
When the MSC-S receives a hold request from the IMS for a local UE that is
involved in an ongoing SRVCC Procedure and the call is in alerting state or
originating call in pre-alerting state, MSC-S sends a DTAP FACILITY message
with call hold/retrieve notification to the UE.
PR
Note: MSC-S does not order the generation of hold tone towards the held
party.
DTAP RETRIEVE
When the MSC-S receives a retrieve request from a local UE that is involved
in an ongoing SRVCC Procedure, the request is rejected with cause code
‘‘temporary failure’’.
In case the call is in alerting state, the request is rejected with cause code
‘‘message type not compatible with protocol state’’.
In case of emergency calls, the request is rejected with the following cause
code:
• Cause code ‘‘facility rejected’’ if the subscriber was registered in VLR and
was subscribed to the supplementary service (SS) before the SRVCC
Procedure,
78 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
• Cause code ‘‘requested facility not subscribed’’ if the subscriber was not
subscribed to the supplementary service or was not registered in VLR
before the SRVCC Procedure.
In case of held call, the retrieve request is accepted and handled as described
in Function Specification Call Hold in MSC/VLR Server.
Note: In case of a held call, the subscriber is assumed that is subscribed

with Call Hold SS since, the session is already on hold when the user
was in PS domain.
Y
For more information on the Call Hold function, refer to Function Specification
Call Hold in MSC/VLR Server.
R
3.3.10 Call Teardown
A
When a call teardown request is ordered by command for a subscriber for
whom an SRVCC Procedure is performed before MSC-S has sent Sv-Interface
IN
protocol SRVCC PS TO CS RESPONSE message, the SRVCC Procedure is
terminated immediately with the exception of emergency calls, and Sv-Interface
protocol SRVCC PS TO CS RESPONSE with cause code ‘‘“request rejected” ’’
is sent.
IM
When a call teardown is ordered by command for a subscriber for whom an
SRVCC Procedure is performed after MSC-S has sent Sv-Interface protocol
SRVCC PS TO CS RESPONSE, then the SRVCC Procedure is terminated with
the exception of emergency calls.
EL
When a MAP Cancel Location message is received from HLR for

a subscriber for whom an SRVCC Procedure is performed, the SRVCC
Procedure may be terminated immediately depending on AXE parameter
LOCANCTDSTATUSM in parameter set GSM1APTC with the exception of
PR
emergency calls.
For more information on the Call Teardown function refer to Function

Specification Call Teardown in MSC/VLR.
3.3.11 Call Waiting
Call Waiting is not invoked and terminating call is rejected during SRVCC
Procedure with cause code ‘‘subscriber absent’’, when the MSC-S receives
a terminating call for a subscriber that is involved in an ongoing SRVCC
Procedure.
For more information on the Call Waiting function refer to Function Specification
Call Waiting in MSC/VLR Server.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 79

3.3.12 Camel Based IMS Centralized Services
For the case the served subscriber is an IMS Centralized Services (ICS)
subscriber, after the SRVCC procedure is finished, new originated calls
(enquiry calls) from the served subscriber or new terminating calls to the served
subscriber are handled according to the ICS procedures specified in Function
Specification CAMEL Based IMS Centralized Services
For the call that is subject to SRVCC procedure, MSC-S ignores the +g.3gpp.ics
feature capability indicator when it is received in SIP 200 OK INVITE message.
Y
3.3.13 Channel Allocation Priority Level
R
In case an SRVCC PS TO CS REQUEST is received, and CAPL function is
A
active in MSC-S, then priority information is not sent towards target BSC.
For more information on the CAPL function, refer to Function Specification
3.3.14 Charging Audit

IN
Handling of Channel Allocation Priority Level in MSC/VLR.
IM
Charging Audit is not supported for calls that are subject to SRVCC Procedure.
For more information on the Charging Audit function, refer to Function

Specification Charging Audit.
EL
3.3.15 Connected Line Identification Services

The Connected Line Identification Presentation (COLP) is supported for
PR
originating calls in alerting state or originating calls in pre-alerting state that are
subject to SRVCC procedure. The existence of subscription data for COLP is
checked before DTAP CONNECT is sent to the UE. If the subscription data for
COLP is not available, then it is assumed to be not active. This situation can
happen when a location update procedure towards HLR is ongoing, running in
parallel to the call set-up and subscription data has not been stored in VLR yet.
The Connected Line Identification Presentation and Connected Line

Identification Restriction (COLR) are not supported for terminating calls in
alerting state that are subject to SRVCC Procedure.
3.3.16 DTMF Support

If a DTAP START DTMF request message is received from the UE while waiting
for the SIP 200 OK INVITE message from IMS for an active call or an originating
call in alerting or pre-alerting state, the request is rejected with cause code
80 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
If a DTAP START DTMF request message is received from the UE before

the MSC-S has sent a SIP INFO request with “call accepted” indication, for
a terminating call in alerting state, the request is rejected with cause code
If a DTAP STOP DTMF request message is received from the UE while waiting
for the SIP 200 OK INVITE message from IMS during an ongoing SRVCC
Procedure, the request is acknowledged.
For more information on the DTMF Support function, refer to Function
Y
Specification DTMF Support.
R
3.3.17 Enhanced MT Call Handling
A
When during an SRVCC Procedure a new LAI is stored in VLR for the
subscriber, then this LAI is subject to replication to buddy MSC according also
to other conditions described in Function Specification Enhanced MT Call
Handling in MSC.
IN
The buddy MSC contains replicated VLR data (IMSI and LAI) of the mobile
subscribers registered in the primary MSC. The primary MSC is the MSC of the
IM
pool where the subscriber is registered. The primary MSC replicates specific
VLR data (IMSI and LAI) of its subscribers to the buddy MSC. In case of primary
MSC failure, the terminating transactions are routed to the buddy MSC.
EL
Note: The terms ‘‘primary MSC’’ and ‘‘buddy MSC’’ shall not be confused
with the terms ‘‘primary MSC blade’’ and ‘‘buddy MSC blade’’ used
for MSC-S Blade Cluster.
In case the Sv-Interface protocol SRVCC PS TO CS REQUEST message is

PR
received by a Buddy MSC and the IMSI is connected to the shadow VLR, the
subscriber is deregistered from the shadow VLR when the Location Update
towards HLR is completed successfully.
For more information on the ‘‘Enhanced MT Call Handling’’ function, refer to

Function Specification Enhanced MT Call Handling in MSC.
3.3.18 Explicit Call Transfer

When the MSC-S receives a request for Explicit Call Transfer from a UE that is
involved in an ongoing SRVCC Procedure, the request for Explicit Call Transfer
is rejected with error code ‘‘System Failure’’.
After successful completion of the SRVCC Procedure, during the call, any
request for Explicit Call Transfer from a UE is rejected with error code ‘‘System
Failure’’ if one of the call legs to be transfered is created due to the SRVCC
Procedure.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 81

3.3.19 Handling of Location Numbers
When target cell is served by the MSC-S that handles the SRVCC Procedure,
the valid Location Number is determined based on the target cell or according
to the inheritance principles described in the Function Specification Handling of
Location Numbers in MSC/VLR Server and GMSC Server (GSM).
As shown in Figure 47, when target cell is served by the Neighboring MSC-S,
the location number is inherited in the following order:
Y
• The Location Number is derived from the one connected to the Area
Cluster administered for the MME.
R
• If no Location number is connected to the Area Cluster administered for the
MME, then the Location Number for the own MSC-S is used.
A
Own MSC-S
SAI-Level Area Cluster for MME
Figure 47
IN
Inheritance Principle Used in SRVCC Procedure when Target Cell
Belongs to Neighboring MSC-S
IM
3.3.20 Immediate Service Termination
For calls subject to SRVCC Procedure, Periodic Reporting Mechanism is not
EL
supported.
In case an Immediate Service Termination (IST) message (IST command) is

received from HLR, the following applies:
PR
• A non-emergency call subject to SRVCC Procedure is disconnected for the

indicated IMSI.
Additionally, in case it is received before MSC-S has sent an Sv-Interface

protocol SRVCC PS TO CS RESPONSE, then Sv-Interface protocol SRVCC
PS TO CS RESPONSE is sent with cause code ‘‘request rejected’’.
• An emergency call subject to SRVCC Procedure is not disconnected since

emergency calls are not monitored.
For more information on the Immediate Service Termination function, refer

to Function Specification , Immediate Service Termination in GMSC and
MSC/VLR Server.
3.3.21 IMSI Detach over DTAP

In case an IMSI Detach message is received over DTAP while SRVCC
Procedure is ongoing, the SRVCC Procedure is terminated. Furthermore, if
82 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
the subscriber was registered in VLR before SRVCC Procedure started, it is

marked as IMSI detached. If the subscriber was not registered in VLR before
SRVCC Procedure started, it is deregistered.
IMSI DETACH over DTAP may be received after HANDOVER COMPLETE

message, while TMSI reallocation or sending of Update Location towards HLR
is ongoing for SRVCC.
For more information on the IMSI Attach and Detach function, refer to Function
Specification , IMSI Attach and Detach in MSC/VLR.
Y
3.3.22 Location Services in MSC-S
R
Mobile Terminating Location Request
A
If MSC-S receives an MT-LR for a registered subscriber that is involved in a
non-emergency call subject to an ongoing SRVCC Procedure, no notification
IN
has to be performed, and call related class is not applied, MSC-S proceeds
with the request as a parallel transaction. The Location Acquisition procedure
is delayed until the BSSMAP HANDOVER COMPLETE message, or the MAP
SEND END SIGNAL message from the Neighboring MSC-S encapsulating the
IM
BSSMAP HANDOVER COMPLETE message is received, respectively.
If notification has to be performed, the request is rejected and an error (‘‘System

Failure’’) is returned to GMLC.
EL
If call related privacy class is applied in the MT-LR, the request is rejected and
an error (‘‘Unauthorized LCS client: No additional information’’) is returned
to GMLC.
If the Handover is not successfully completed and the request type was ‘‘current
PR
location’’, the request is rejected and error ‘‘System Failure’’ is returned to

the GMLC.
If the request type was ‘‘current or last known’’, the last known location and age
of location stored in the subscriber VLR record (if available) is returned to the
GMLC. If there is no location stored in subscriber VLR record the request is
rejected and error ‘‘System Failure’’ is returned to the GMLC.
If MSC-S receives an MT-LR for a non-registered subscriber that is involved in

a non-emergency call subject to an ongoing SRVCC procedure, the request
is rejected and an error (‘‘Absent subscriber: IMSI detached’’) is returned to
the GMLC.
If the MSC-S receives an MT-LR for a subscriber who is temporary registered

in VLR and is involved in an emergency call subject to an ongoing SRVCC
Procedure, MSC-S handles the MT-LR as ‘‘MT-LR for non-registered
subscriber’’, for its description refer to Function Specification Location Services
in MSC Server.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 83

Deferred Mobile Terminating Location Request
If the MSC-S receives a deferred MT-LR for a registered subscriber that is

involved in a non-emergency call subject to an ongoing SRVCC Procedure,
which can be already satisfied, no other positioning request is ongoing, and
no notification has to be performed, the MSC-S proceeds with the request as
a parallel transaction. The Location Acquisition procedure is delayed until the
BSSMAP HANDOVER COMPLETE message, or the MAP SEND END SIGNAL
message from the Neighboring MSC-S encapsulating the BSSMAP HANDOVER
COMPLETE message is received.
Y
Successful completion of the Handover is considered as an additional
MS activity becoming the subscriber MS reachable. Further actions are
R
as described at section ‘‘Detection of “MS available” Event’’ in Function
Specification Deferred Mobile Terminating Location Request in MSC/VLR
Server.
A
If notification has to be performed, the request is rejected with a MAP
IN
SUBSCRIBER LOCATION REPORT message, which carries the LCS reference
number corresponding to the received request and the termination cause ‘‘Error
Undefined’’, is returned to the GMLC.
IM
If the Handover is not successfully completed and the request type was ‘‘activate
deferred location’’, a MAP SUBSCRIBER LOCATION REPORT message, which
carries the LCS reference number corresponding to the received request and
the termination cause ‘‘Error Undefined’’, is returned to the GMLC.
EL
If MSC-S receives a deferred MT-LR for a non-registered subscriber that is

involved in a non-emergency call subject to an ongoing SRVCC procedure,
the request is rejected and an error (‘‘Absent subscriber: IMSI detached’’) is
returned to the GMLC.
PR
Mobile Originating Location Request (MO-LR)
If MSC-S receives an MO-LR for a registered subscriber that is involved in a

non-emergency call subject to an ongoing SRVCC Procedure, the MSC-S
rejects the request with the error ‘‘service or option temporarily out of order’’.
For more information on the Location Services function, refer to Function

Specification Location Services in MSC Server.
3.3.23 MSC in Pool

In case the MSC-S interworks in Pool environment and the subscriber was
registered in VLR before the reception of the request for SRVCC Procedure,
then as soon as the third phase of redistribution is applied, TMSI generated
during SRVCC Procedure contains Null NRI and an ownNB-LAI . In any other
case, when the MSC-S interworks in Pool environment, the TMSI generated
during SRVCC Procedure contains null-NRI or own-Network Resource Identifier
84 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
(NRI), based on exchange data for preferred NRI option on a per Area Cluster
(MME) basis. When no null-NRI is administered, then own NRI is used.
For more information on the MSC in Pool function, refer to Function

Specification MSC/VLR Server in MSC Pool.
3.3.24 Multi Party Supplementary Service

When during an ongoing SRVCC transfer a DTAP FACILITY message is
Y
received from the UE related to multi-party supplementary service, the request
is rejected. For a call in alerting state or for an originating call in pre-alerting
state, error code ‘‘Illegal SS Operation’’ is used, otherwise error code ‘‘System
R
Failure’’ is used.
In case a DTAP FACILITY message related to multi-party supplementary
A
service is received while the served subscriber is involved in a transferred
active conference call, the request is handled as it is described in Section
3.2.13 on page 42.
IN
If a BuildMPTY request is received from the subscriber inside a DTAP
FACILITY message after the completion of the SRVCC procedure, then
this request is rejected with error code ‘‘system failure’’, in case the served
IM
subscriber was a conference participant in IMS network but not the conference
controller.
Note: The presence of isfocus media feature tag in SIP 200 OK INVITE
EL
response without the provision afterwards of the <mid-call> element

with information about the number of conference participants in INFO
message for the SRVCC call leg means that the transferred UE is a
conference participant.
PR
After the completion of the SRVCC procedure for a subscriber that was not
involved in the transfer of an active conference call from IMS network, any
DTAP FACILITY message that is received from the subscriber and is related
to multi-party supplementary service, it is handled according to Function
Specification Multi-Party Supplementary Service in MSC/VLR Server.
No conference warning tone is played towards IMS on the call leg controlled
by the Mw-Interface.
For more information on the Multi Party Supplementary Service function, refer to
Function Specification Multi-Party Supplementary Service in MSC/VLR Server.
3.3.25 Network Initiated Unstructured Supplementary Service Data (USSD)

Message
Network initiated Unstructured Supplementary Service Data (USSD) operations
towards a mobile subscriber, who is involved in an ongoing SRVCC Procedure,
are terminated in the MSC-S with error code ‘‘System Failure’’ .
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 85

For more information on the Network Initiated Unstructured Supplementary

Service Data Message function, refer to Function Specification Handling of
Unstructured Supplementary Service Data Procedures in MSC/VLR Server.
3.3.26 NSS based Location Services

If MSC-S receives an NSS based Location Request for a registered subscriber
that is involved in a non-emergency call subject to an ongoing SRVCC
Procedure, MSC-S proceeds with the request as a parallel transaction. The
Y
Location Acquisition procedure is delayed until the BSSMAP HANDOVER
COMPLETE message, or the MAP SEND END SIGNAL message from the
Neighboring MSC-S encapsulating the BSSMAP HANDOVER COMPLETE
R
message is received, respectively.
If the Handover is not completed successfully, the request is rejected and error
A
‘‘Position Failure’’ is returned to the GMLC.
If MSC-S receives an NSS based Location Request for a subscriber that is not
IN
registered in VLR and is involved in a non-emergency call subject to an ongoing
SRVCC Procedure, the request is rejected and error ‘‘Absent Subscriber’’ is
returned to the GMLC.
IM
For more information on the NSS based location services function, refer to
Function Specification Nss Based Location Services in MSC/VLR Server.
EL
3.3.27 Parallel Transactions during SRVCC Procedure for an Emergency

Call
Location Services transaction

PR
If the MSC-S receives an MT-LR during an emergency call subject to an ongoing

SRVCC Procedure, the MT-LR can be accepted based on AXE parameter
LCSONEMERG in parameter set GSMMMSC, see Section 3.3.22 on page 83.
If MSC-S receives an MO-LR either during an emergency call subject to an

ongoing SRVCC Procedure, or during the emergency call after the completion
of an SRVCC Procedure, the MO-LR is rejected with cause code ‘‘message
type not compatible with the protocol state’’.
Supplementary Service transaction
If the MSC-S receives an MT parallel SS transaction during an emergency call

subject to an ongoing SRVCC Procedure, the transaction can be accepted
based on changeable exchange parameter SSEM2.
If the MSC-S receives an MO parallel SS transaction during an emergency call

subject to an ongoing SRVCC Procedure, the transaction is rejected with cause
code ‘‘message type not compatible with the protocol state’’.
86 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
Short Message Service transaction
If the MSC-S receives an MO or MT SMS transaction during an emergency call

subject to an ongoing SRVCC Procedure, the SMS transaction is rejected,
see Section 3.3.30 on page 87. A PAP can enable establishment of SMS
transactions in parallel to an existing emergency call.
For more information on the handling of parallel transactions, refer to Function

Specification Handling of Parallel Transactions in MSC/VLR Server.
Y
3.3.28 Service Based Handover
R
The MSC-S determines whether the BSSMAP Service Handover IE, or the
RANAP Service Handover IE, or both are to be sent to the target radio
access or Neighboring MSC-S based on main telecommunication service
A
analysis and IMSI number series analysis. For more information on Service
Based Handover, refer to Function Specification Service Based Handover in
MSC/VLR Server.
3.3.29
IN
SMS over SGs-Interface and LTE to CS Fallback
IM
For a subscriber already EPS-Attached in VLR, before the SRVCC Procedure
was started, MSC-S marks this subscriber EPS-Detached upon reception of
the BSSMAP HANDOVER COMPLETE message, depending on AXE parameter
LTETOGSMSGSDTCH.
EL
When during an ongoing SRVCC Procedure before the MSC-S has sent SRVCC
PS TO CS RESPONSE, a location update is received over the SGs-Interface,
then the SRVCC Procedure is aborted and SRVCC PS TO CS RESPONSE is
sent to MME with cause code ‘‘relocation failure’’ and SRVCC cause code
‘‘handover/relocation failure with target system’’. The session transfer call leg is
PR
disconnected, if SIP INVITE has already been sent. The received message is
processed as if SRVCC Procedure has never occured as described in Function
Specification SGs-Interface for SGsAP Procedures.
When during an ongoing SRVCC Procedure, after the MSC-S has sent SRVCC
PS TO CS RESPONSE, a location update is received over SGs-Interface then
the SRVCC Procedure is aborted. The session transfer call leg is disconnected,
if SIP INVITE has already been sent. The received message is processed as if
SRVCC Procedure has never occurred as described in Function Specification
SGs-Interface for SGsAP Procedures.
SRVCC Procedure is performed irrespective of any Mobile Originating SMS

over SGs-Interface or Mobile Terminating SMS over SGs-Interface .
For more information on the SGs-Interface for SGsAP procedures function,

refer to Function Specification SGs-Interface for SGsAP Procedures.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 87

3.3.30 Short Message Service, Mobile Originating, Mobile Terminating,

Queuing in MSC-S
Mobile Originating Short Message Service (MO SMS)
When the MSC-S receives an MO Short Message Service (SMS) from a

UE that is involved in a non-emergency call subject to an ongoing SRVCC
Procedure and the BSSMAP HANDOVER COMPLETE message has already
been received in the MSC-S, the MSC-S indicates ‘‘service option temporarily
out of order’’ to the UE.
Y
When the MSC-S receives an MO SMS from a subscriber that is involved in
R
an emergency call, regardless the status of the SRVCC Procedure affecting
the call (ongoing or completed), the MSC-S indicates ‘‘message type not
compatible with the protocol state’’ to the UE.
A
A PAP can enable establishment of SMS transactions in parallel to an existing
emergency call. If parallel SMS transactions are accepted during emergency
call, the handing is as follows:
•
IN
When the MSC-S receives a MO SMS from a subscriber that is involved in
an emergency call subject to an ongoing SRVCC Procedure, the MSC-S
IM
indicates ‘‘service option temporarily out of order’’ to the UE.
• When the MSC-S receives a MO SMS from a subscriber that is involved

in an emergency call after the completion of an SRVCC Procedure, the
SMS is accepted.
EL
Mobile Terminating Short Message Service (MT SMS)
When the MSC-S receives a MT SMS for a subscriber that is still involved
PR
in a non-emergency call subject to an ongoing SRVCC Procedure and SMS

queuing functionality is active, the SMS is queued and is delivered after
completion of the SRVCC Procedure and unqueuing timer expiry.
When the MSC-S receives a MT SMS for a subscriber that is involved in an

emergency call subject to an ongoing SRVCC Procedure, the SMS is queued
if queuing is active. After the completion of the SRVCC Procedure, the SMS
is unqueued and rejected with cause code ‘‘subscriber busy for MT-SMS’’. If
the MT SMS is received after the completion of an SRVCC Procedure, the
SMS is queued if queuing is active.
A PAP can enable establishment of SMS transactions in parallel to an existing

emergency call. If parallel SMS transactions are accepted during emergency
call, the handing is as follows:
• When the MSC-S receives a MT SMS for a subscriber that is involved in

an emergency call subject to an ongoing SRVCC Procedure, the SMS is
queued if queuing is active. After the completion of the SRVCC Procedure,
the SMS is unqueued and accepted.
88 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Function
• When the MSC-S receives an MT SMS for a subscriber that is involved in

an emergency call after the completion of an SRVCC Procedure, the SMS
is accepted.
When queuing needs to be applied in all of the above cases, but queuing is
inactive, the SMS transaction is rejected with ‘‘Subscriber busy for MT-SMS’’
for a subscriber that is registered in VLR, or with ‘‘Undefined Subscriber’’ for
a subscriber that is temporary registered in VLR.
Delivery of the SMS after the queuing is described in Function Specification
Y
Short Message Service, Mobile Terminated, Queuing in MSC/VLR Server.
R
3.3.31 Single Personal Number at No Reply
MSC-S does not invoke service ‘‘Single Personal Number at No Reply’’, for a
A
terminating call in alerting state that is subject to SRVCC Procedure.
IN
IM
EL
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 89

Y
R
A
IN
IM
EL
PR
90 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Operational Conditions
4 Operational Conditions
4.1 Operation and Maintenance Reference Information

Input Elements
Y
Table 18
AXE Parameters
R
LCSONEMERG
LOCANCTDSTATUSM
A
LTETOGSMHOACT
LTETOGSMSGSDTCH
NBLAC
NBMCC
NBMNC
IN
IM
NONDIALPREFIX
PLMNNBLAC
SRVCCEMERGBO
SRVCCSTAENQENBL
EL
TIMUGHOBASICM
TMSILAIMSC
TMSIPAR
PR
Table 19
Route Parameters
TRUSTPL
MIS2
Table 20
Changeable Exchange Parameters
EMCNOIMSI
SSEM2
Table 21
(1)(2)(3)
Commands
MGAAI
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 91

(1)(2)(3)
Commands
MGAAC
MGAAE
MGAAP
MGEPC
MGEPP
MGESI
Y
MGESE
MGESP
R
MGGMI
MGGME
A
MGGMP
(1) For the commands related to the administration of the MME and UDP port numbers, refer
to the Function Specification Generic Transport Function, Traffic, Administration
and Maintenance.
IN
(2) For a detailed description of the Area Cluster Administration function, refer to the Function
Specification Area Cluster Administration in MSC/VLR Server.
(3) For a detailed description of the commands related to handling of Location Numbers, refer to
IM
the Function Specification Handling of Location Numbers in MSC/VLR Server and
GMSC Server (GSM).
Table 22
EL
Timers
T322 SRVCCSTAENQT322
TIMUGHOINTRAM TIMUGHOINTRAM
PR
Output Elements
Table 23
(1)
Printouts
EMERGENCY SESSION TRANSFER Answer Printout
NUMBER
MT GMLC ADDRESS DATA FOR Answer Printout
SRVCC
MT AREA CLUSTER DATA Answer Printout
MT EXCHANGE PROPERTY DATA Answer Printout
(1) For the printouts of Generic Transport related data refer to the Function Specification
Generic Transport Function, Traffic, Administration and Maintenance and
for the printout of Area Cluster Data, refer to the Function Specification Area Cluster
Administration in MSC/VLR Server.
92 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

4.2 Charging
For a detailed description of the general principles for charging, refer to the
Function Specification Charging in a PLMN.
Charging Origin (CO) used for charging analysis is determined by either the
configuration of the target cell if the target cell belongs to the MSC-S handling
the SRVCC Procedure, or the configuration of the route of the Neighboring
MSC-S if the target cell belongs to a Neighboring MSC-S.
Y
The MSC-S generates a Mobile Originating (MO) Call Data Record (CDR)
which is identified as SRVCC specific based on the SRVCC indicator. Also
R
MSC-S generates a Handover Event Module. In the MO CDR, the following
existing parameters are populated with information derived from SRVCC:
A
• Originating Location Number (ITU) or Location number (ANSI) as explained
in Section 3.3.19 on page 81.
•
IN
First Assigned Speech Coder Version as the first speech coder
version that was assigned for the SRVCC call in the MSC-S.
In the MO CDR the following existing parameters are populated with

IM
corresponding values from the Sv-Interface protocol SRVCC PS TO CS
REQUEST message as described in Page 93:
Table 24 MO CDR Parameters populated with Values from Sv-Interface

EL
protocol SRVCC PS TO CS REQUEST message

MO CDR PARAMETER VALUE
(1)
Calling Party Number C-MSISDN
(2)
Called Party Number STN-SR
PR
(3)
Calling Subscriber IMEI MEI
(ITU)
IMEI (ANSI)
(3)
Calling Subscriber MEI
IMEISV
(4)
TeleserviceCode EmergencyCall
(1) If C-MSISDN is not provided by the MME in the Sv-Interface protocol SRVCC PS TO
REQUEST message, the value is the non-dialable callback number, see Table 16.
(2) In case of emergency calls, the E-STN-SR is used as Called party Number.
(3) The value of MEI is used if provided by MME in the Sv-Interface protocol SRVCC PS TO CS
REQUEST message.
(4) This parameter is populated only in case of emergency calls that are subject to SRVCC
Procedure.
In the MO CDR the following parameters are populated with SRVCC specific
information as shown in Page 94.
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 93

Table 25 MO CDR Parameters being SRVCC specific

TRAFFIC CASE MO CDR PARAMETER
(1)
Active call SRVCC Indicator
MME Identity
(1)
Held call SRVCC Indicator
SRVCC Call Hold Indicator
Y
MME Identity
(1)
Originating call in alerting state SRVCC Indicator
R
(2)
SRVCC Alerting Indicator
MME Identity
A
(1)
Terminating call in alerting state SRVCC Indicator
(3)
SRVCC Alerting Indicator
Originating call in pre-alerting state

IN MME Identity
SRVCC Indicator
(1)
IM
SRVCC Originating
Pre-alerting Indicator
MME Identity
(1)
EL
Active conference call SRVCC Indicator

SRVCC Conference Indicator
MME Identity
(1) The value of parameter is E-UTRAN ‘‘0’’
PR
(2) The value of parameter is originating call in alerting state "0".

(3) The value of parameter is terminating call in alerting state "1".
CDR parameter field outgoingPChargingVector contains type 1 orig-ioi

parameter which is sent as part of P-Charging-Vector header in initial
INVITE message for all SRVCC calls. Type 1 orig-ioi parameter contains
the Network Identity in which the local host resides prefixed with string "Type
1". In case that type 1 orig-ioi parameter exceeds 63 characters, the
leftmost 63 characters will be seen as output in MO CDR generated due to
SRVCC procedure.
The parameter P-Charging Vector Related contains the value of the

parameters Related-ICID and Related-ICID-generated-at returned
as part of P-Charging-Vector header in 2xx response to the initial SIP
INVITE request to facilitate correlation with CDRs generated for the original
call leg by IMS.
94 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

The parameters First (Calling) Location Information and RNC ID of First RNC
are not included in the MO CDR for calls that are subject to SRVCC Procedure.
Charging is started at reception of the SIP 200 OK message from the IMS
network as answer to the SIP INVITE message.
A Handover event module is created for calls that were subject to SRVCC
Procedure in the MO CDR, indicating among other parameters, the time
of reception of the SIP 200 OKINVITE message from IMS if received after
HANDOVER COMPLETE, and the cause code that is sent in BSSMAP HANDOVER
Y
REQUEST message towards target cell. Otherwise the time of reception of
HANDOVER COMPLETE is included.
R
4.3 Capabilities
A
One SAI can be defined in an Area Cluster with connected MME-ID.
One E-STN-SR can be configured in the MSC-S to support the emergency

session transfer towards IMS.
IN
One GMLC address can be defined in the MSC-S to be used for the Location
Continuity Procedure.
IM
EL
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 95

Y
R
A
IN
IM
EL
PR
96 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Appendix 1 - Example Call Flow
5 Appendix 1 - Example Call Flow

Figure 48 shows as an example the call flow of an SRVCC procedure for a
terminating call in alerting state, assuming the following conditions and options:
• Backward bearer setup is used for the session transfer to IMS.
• The Target Cell belongs to a Neighboring MSC-S.
• The subscriber is not registered in the VLR upon reception of the
Y
Sv-Interface protocol SRVCC PS TO CS REQUEST message.
R
Note: Dashed lines show which received messages are the triggers for
messages sent by the MSC-S. If multiple dashed lines start from the
same received message, that message is the trigger for all connected
A
messages. If multiple dashed lines end on a message sent by the
MSC-S, all connected messages are conditions for that message to
be sent.
IN
IM
EL
PR
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 97

Neighboring Targe
MME Sv-Interface Protocol MSC-S MAP BICC or ISUP BSSMAP
MSC-S BSC
MAP
SIP GCP GCP
IMS MGW1 HLR MGW2
SRVCC
PS TO CS
REQUEST PREPARE
HANDOVER
Reserve IMS REQUEST
Connection Point,
Y
Change INS Prepare Bearer
Through Connection ADD.req&rep (Ctx=1,T=T1) ADD.req&rep
(Ctx=2,T=T4) HANDOVER
R
Establish Bearer ADD.req&rep REQUEST
(Ctx=2,T=T3) HANDOVER
REQUEST
PREPARE
A
ACKNOWLEDGE
HANDOVER
RESPONSE
FORWARD
IN
ACCESS
SIGNALLING
PROCESS
ACCESS
IM
SIGNALLING
IAM
Prepare Bearer ADD.req&rep

Tunnel Information Down
EL
(Ctx=3,T=T2) NOTIFY
req&rep
APM
MOD.req&rep Tunnel Information Down

Tunnel Information Up
PR
NOTIFY
req&rep (Ctx=2,T=T3)
APM
Tunnel Information Down
(Ctx=2,T=T3) MOD.req&rep
Bearer Established NOTIFY
(Ctx=3,T=T2) req&rep
Join Bearer
Termination MOV.req&rep
(Ctx=1,T=T2)
... ... ... ... ... ... ... ...
Neighboring BSSMAP Targe
MME Sv-Interface Protocol MSC-S MAP BICC or ISUP
MSC-S BSC
MAP
SIP GCP GCP
IMS MGW1 HLR MGW2
SRVCC ACM
PS TO CS
RESPONSE
INVITE
183 SESSION
98 PROGRESS 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08
Configure
MOD.req&rep IMS Connection
Point (Ctx=2,T=T4)
Glossary
Glossary
AMR-WB EPC
Adaptive Multi-Rate Wideband Evolved Packet Core
ANM EPS
Answer message Evolved Packet System
Y
APM E-STN-SR
Application Transport Message Emergency Session Transfer Number for
R
SRVCC
BICC
Bearer Independent Call Control FQDN
A
Fully Qualified Domain Name
BO
B-Number Origin GCP
BSC
Base Station Controller
IN
Gateway Control Protocol
GMLC
Gateway Mobile Location Center
IM
BSSMAP
Base Station Subsystem Mobile Application GSM
Part Global System for Mobile Communications
C-MSISDN GPRS
EL
Correlation MSISDN General Packet Radio Service
CDR GTP
Call Data Record GPRS Tunneling Protocol
PR
CM GTPv2-C
Connection Management (GTP) version 2 for Control plane
CN GW
Core Network Gateway
CO HLR
Charging Origin Home Location Register
CS IAM
Circuit Switched Initial Address Message
CTX ICID
Context IMS Charging Identity
EATF ID
Emergency Access Transfer Function Identity
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 99

IMEI MME
International Mobile Equipment Identity Mobility Management Entity
IMEISV MME-ID
IMEI including Software Version MME Identity
IMS MNC
Internet Protocol Multimedia Subsystem Mobile Network Code
IMSI MO
Y
International Mobile Subscriber Identity Mobile Originating
IP MO-LR
R
Internet Protocol Mobile Originating Location Request
IST MPTY
A
Immediate Service Termination Multiparty
ISUP MSC
ISDN User Part
LAC
Location Area Code
MSC-SIN
Mobile Switching Center
Mobile Switching Center Server

IM
LAI MSC-S BC
Location Area Identity MSC-S Blade Cluster
LCS MSISDN
EL
Location Services Mobile Subscriber ISDN Number
LTE MT
Long Term Evolution Mobile Terminating
MAP MT-LR
PR
Mobile Application Part Mobile Terminating Location Request
MAPV2 NAS
MAP Version 2 Non-Access Stratum
MAPV3 NB-LAI
MAP Version 3 Non-Broadcast Location Area Information
MCC NRI
Mobile Country Code Network Resource Identifier
MEI OoBTC
Mobile Equipment Identity Out of Band Transcoder Control
MGCF PDN-GW
Media Gateway Control Function Packet Data Network Gateway
MGW PLMN
Media Gateway Public Land Mobile Network
100 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Glossary
PS UE
Packet Switched User Equipment
RO UICC
Routing Origin Universal Integrated Circuit Card
SA USSD
Service Area Unstructured Supplementary Service Data
SAI
Y
Service Area Identity
SIM
R
Subscriber Identity Module
SIP
A
Session Initiation Protocol
SMS
Short Message Service
SRVCC
Single Radio Voice Call Continuity
IN
IM
STN-SR
Session Transfer Number for SRVCC
SS
EL
Supplementary Service
T
Termination
TEID
PR
Tunnel Endpoint Identifier
TEID-C
Tunnel Endpoint Identifier for Control Plane
TMSI
Temporary Mobile Subscriber Identity
TI
Transaction Identifier
TrFO
Transcoder Free Operation
UDP
User Datagram Protocol
UDUB
User Determined User Busy
58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 101

Y
R
A
IN
IM
EL
PR
102 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Reference List
Reference List
[1] A-Interface, Section B: Basic Call Control Procedures

[2] A-Interface, Section H: Base Station System Management Application

Part, BSSMAP Message Formats and Coding
Y
[3] A/Iu-Interface, Section I: DTAP And RANAP/NAS, Message Formats And
R
Coding For Mobility Management
A
[4] A/Iu-Interface, Section J: DTAP and RANAP/NAS, Message Formats and
Coding for Short Message Service
[5] IN
A/Iu-Interface, Section K: DTAP and RANAP/NAS, Message Formats
and Coding for Call Control and Call Related Supplementary Service
Procedures
IM
[6] A/Iu-Interface, Section L: DTAP and RANAP Message Formats and

Coding for Call Independent Supplementary Service Procedures
EL
[7] Alternate Speech/Fax Gr.3 Transparent In MSC/VLR Server

[8] Announcement at Call Disconnection in MSC/VLR Server

PR
[9] Area Cluster Administration in MSC/VLR Server

[10] BSC Recording Initiation in MSC/VLR Server

[11] BSS Trace Invocation in MSC/VLR Server

[12] Call Hold in MSC/VLR Server

[13] Call Teardown in MSC/VLR

[14] Call Waiting in MSC/VLR Server

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 103

[15] CAMEL Based IMS Centralized Services

[16] Charging Audit

[17] Charging in a PLMN

[18] Deferred Mobile Terminating Location Request in MSC/VLR Server
Y
[19] DTMF Support
R
[20] Emergency Call in MSC/VLR Server (Japan)
A
[21] Enhanced MT Call Handling in MSC

IN
[22] Generic Transport Function, Traffic, Administration and Maintenance
IM
[23] Glossary of Terms and Acronyms
GLOSSARY
[24] GTPv2-C, General Aspects, Formats and Codes

EL
[25] GTP-C, Signaling Transport

PR
[26] Handling of Channel Allocation Priority Level in MSC/VLR

[27] Handling of Location Numbers in MSC/VLR Server and GMSC Server

(GSM)
[28] Handling of Parallel Transactions in MSC/VLR Server

[29] Handling of Unstructured Supplementary Service Data Procedures in

MSC/VLR Server
[30] Immediate Service Termination in GMSC and MSC/VLR Server

[31] IMSI Attach and Detach in MSC/VLR

104 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Reference List
[32] Inter-MSC Handover/Relocation to MSC Pool

[33] Interworking with IMS Multimedia Telephony

[34] Location Services in MSC Server

[35] Location Updating in MSC/VLR Server
Y
[36] Mapping of Cause Codes and Location Information
R
APPLICATION INFORMATION
[37] Media Gateway Selection in MSC Server, GMSC Server and TSC Server
A
[38] Mobile Subscriber Related Security Functions in MSC/VLR Server

IN
[39] MSC Server Interworking with External Networks using SIP and SIP with
encapsulated ISUP
IM
[40] MSC/VLR Server in MSC Pool

EL
[41] Multi-Party Supplementary Service in MSC/VLR Server

[42] NSS Based Location Services in MSC/VLR Server

PR
[43] Out of Band Transcoder Control in MSC Server, GMSC Server and TSC
Server
[44] PS to CS SRVCC for Additional Call

[45] Service Based Handover in MSC/VLR Server

[46] Session Initiation Protocol

[47] SGs-Interface for SGsAP Procedures

[48] Short Message Service, Mobile Terminated, Queuing in MSC/VLR Server

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 105

[49] Signalling System No.7, Mobile Application Part Version 2 in MSC/VLR

Server
[50] Signalling System No.7, Mobile Application Part Version 2 for Inter-MSC
Handover in MSC/VLR Server
[51] Signalling System No.7, Mobile Application Part Version 3 in MSC/VLR

Server
Y
[52] Signalling System No.7, Mobile Application Part Version 3 for Inter-MSC
R
Handover in MSC/VLR Server
A
[53] Support of AMR-WB Speech Codec
Continuity
USER GUIDE
IN
[54] Sv-Interface Configuration and Enabling of Single Radio Voice Call
IM
[55] Sv-Interface, General Aspects, Message Formats and Coding for SRVCC
[56] TrFO Interworking with SIP and SIP-I

EL
[57] UMTS to GSM Handover in MSC/VLR Server

PR
106 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Lte To GSM Handover (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

Lte To GSM Handover (SRVCC)

Uploaded by

Copyright:

Available Formats

LTE to GSM Handover (SRVCC)

58/155 17-CSA 121 01/9 Uen PA17

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Reference List 103

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Changes in MSC 16A

This document is based on LTE to GSM Handover (SRVCC),

• Support of SRVCC for active conference call.

Changes in MSC 14B

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 1

2 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

The function ‘‘LTE to GSM Handover (SRVCC)’’ performs a handover of a call,

• Active conference call

Terminating call in alerting state

Originating call in pre-alerting state

‘‘LTE to GSM Handover (SRVCC)’’ is applicable to the following access types:

‘‘LTE to GSM Handover (SRVCC)’’ is applicable to the following

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 3

4 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Table 1 Overview of Interfaces and Protocols

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 5

LTE to GSM Handover (SRVCC) Documentation Overview

6 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Transport and to the Function Specification GTPv2-C, General Aspects,

The MME is represented as Remote Host in the MSC-S and is connected to an

For a detailed description of the Area Cluster Administration function, refer to

Figure 3 provides an overview of the logical parts of the SRVCC Procedure

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 7

All blocks in Figure 3 represent a logical part of the SRVCC Procedure. A

Differences for SRVCC Procedure for Emergency Calls are described in

8 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

Figure 3 General Flow of SRVCC Procedure

The SRVCC Procedure consists of the following steps:

• Initiation of SRVCC, see Section 3.2.1 on page 11

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 9

• Handover Request, see Section 3.2.2 on page 11

• Response to MME, see Section 3.2.3 on page 15

• IMS Session Transfer, see Section 3.2.4 on page 16

• Handover Completion, see Section 3.2.5 on page 24

• SRVCC Complete Notification to MME, see Section 3.2.6 on page 26

• Location Update towards HLR (conditional), see Section 3.2.8 on page 31

Reception of Conference Call Information (conditional), see Section 3.2.12

The following additional step might be needed based on configuration option

• Location Continuity (conditional), Section 3.2.18.7 on page 72

• Status Enquiry Procedure, see Section 3.2.9 on page 32

In addition, dedicated sections describe the followings:

10 58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08

3.2 Traffic Handling

3.2.1 Initiation of SRVCC

later Sv-Interface SRVCC PS TO CS COMPLETE NOTIFICATION message.

3.2.2 Handover Request

The MSC-S also triggers the handover, as described below.

Handover Scenario 1: Target Cell Belongs to MSC-S

As shown in Figure 5, the MSC-S initiates an Intra-MSC Handover if the target

58/155 17-CSA 121 01/9 Uen PA17 | 2015-11-08 11

Sv-Interface Protocol BSSMAP

Target Cell Identifier

In addition, BSSMAP HANDOVER REQUEST message sent to the target BSC is

• Uplink quality is included in the Cause field of the BSSMAP

• Speech is included in the Channel Type field of the BSSMAP HANDOVER

• IP is included in the supported bearer of Codec List field of the BSSMAP

• Default SAI administered on the Area Cluster is included in the Serving