Location Update GSM

LTE to GSM Handover (SRVCC)
FUNCTION SPECIFICATION
58/155 17-CSA 121 01/14 Uen A

Copyright
© Ericsson GmbH 2019. 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 of
this document.
Trademark List
All trademarks mentioned herein are the property of their respective owners.
These are shown in the document Trademark Information.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Contents
Contents
1 Revision Information 1
2 Overview 3
3 Function 5
3.1 General 5
3.2 Traffic Handling 7
3.2.1 Initiation of SRVCC 10
3.2.2 Handover Request 11
3.2.3 Response to MME 14
3.2.4 IMS Session Transfer 17
3.2.5 Handover Completion 26
3.2.6 SRVCC Complete Notification to MME 28
3.2.7 TMSI Allocation 30
3.2.8 Location Update Towards HLR 33
3.2.9 Status Enquiry Procedure 35
3.2.10 Alerting for Originating Calls in Pre-Alerting State 37
3.2.11 Call Acceptance for Calls in Alerting State or Originating Calls
in Pre-Alerting State 39
3.2.12 Reception of Conference Call Information 44
3.2.13 Cancellation of SRVCC Procedure 46
3.2.14 Interaction between Requests for SRVCC Procedure 47
3.2.15 Rejection of Requests for SRVCC Procedure 48
3.2.16 Interactions between MSC-S and MGW 52
3.2.17 SRVCC Procedure for Emergency Call 77
3.3 Interaction with Other Functions 83
3.3.1 Announcement at Call Disconnection 83
3.3.2 Announcement on No Reply or User Determined User Busy 83
3.3.3 Basic Mobile Switching Services 83
3.3.4 BSC Recording Initiation in MSC/VLR Server 84
3.3.5 BSS Trace Invocation in MSC/VLR Server 84
3.3.6 Call Forwarding on No Reply 84
3.3.7 Call Forwarding on User Busy 84
3.3.8 Call Hold 84
3.3.9 Call Re-establishment 86
3.3.10 Call Teardown 87
3.3.11 Call Waiting 88
3.3.12 CAMEL Based IMS Centralized Services 88
3.3.13 Channel Allocation Priority Level 88
3.3.14 Charging Audit 88
3.3.15 Connected Line Identification Services 88
3.3.16 DTMF Support 89
3.3.17 Enhanced MT Call Handling 89
3.3.18 Enhanced Multi-Level Precedence and Pre-emption 89
58/155 17-CSA 121 01/14 Uen A | 2019-06-19

3.3.19 Explicit Call Transfer 89

3.3.20 Handling of Location Numbers 90
3.3.21 I2 Based IMS Centralized Services for Originating Calls 90
3.3.22 Immediate Service Termination 90
3.3.23 IMSI Detach over DTAP 91
3.3.24 Location Services in MSC-S 91
3.3.25 MSC in Pool 93
3.3.26 Multi Party Supplementary Service 93
3.3.27 Network Initiated Unstructured Supplementary Service Data
(USSD) Message 95
3.3.28 NSS based Location Services 95
3.3.29 Parallel Transactions during SRVCC Procedure for an
Emergency Call 95
3.3.30 Roaming Priority Handling 96
3.3.31 Service Based Handover 96
3.3.32 SMS over SGs-Interface and LTE to CS Fallback 96
3.3.33 Short Message Service, Mobile Originating, Mobile
Terminating, Queuing in MSC-S 97
3.3.34 Single Personal Number at No Reply 98
3.3.35 Wireless Priority Service (WPS) 98
4 Operational Conditions 99
4.1 Operation and Maintenance Reference Information 99
4.2 Charging 101
4.3 Capabilities 103
5 Appendix 1 - Example Call Flow 105
Glossary 109
Reference List 113
58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Revision Information
1 Revision Information
Changes in MSC-S 18.3

This document is based on Function Specification LTE to GSM Handover (SRVCC),
58/155 17-CSA 121 01/11 Uen, Rev. C.
This document has been revised as follows:

— Rev. A
• Editorial changes only.
Changes in MSC-S 18A

58/155 17-CSA 121 01/10 Uen, Rev. C.

— Rev. C
• MSC Pool
— Interaction with ‘‘MSC Controlled Subscriber Redistribution’’ added.

• LTE to WCDMA handover (SRVCC)
— Configuration option added to delay the sending of SRVCC PS to CS
response until an answer to the SIP INVITE request is received
— Rev. B
— Rev. A
• IMS Centralized Services (ICS)

— Interaction with ‘‘ICS I2 for Originating Calls’’ feature is added.

58/155 17-CSA 121 01/9 Uen, Rev. B.

— Rev. B, C
— Rev. A
• LTE to GSM Handover (SRVCC)
— Provision of the served subscriber's location information to IMS.
— Handling of unspecified connection address for originating and
terminating calls in alerting state.
— Transfer of held conference as single or first call.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 1

— Interaction with Function Specification Support of IMS Conference

Control after SRVCC transfer added.
— SRVCC with priority support when Allocation/Retention
Priority is received in SRVCC PS to CS REQUEST.
— Handling for suppression of announcements in SIP trunk due to
unsuccessful SIP response to INVITE request is changed.
• Call Re-establishment
— Interaction of SRVCC with Call Re-establishment procedure.
• MGCF for Interworking with IMS
— Provision of priority information towards IMS in Resource-Priority
header.

58/155 17-CSA 121 01/7 Uen, Rev. B.
Other than editorial changes, this document has been revised as follows:
— Rev. B.
— Rev. A
• LTE to GSM Handover (SRVCC)
— Support of SRVCC for originating call in pre-alerting state.
— Removal of the AXE customer parameter SRVCCALERTENBL. ‘‘SRVCC
for call in alerting state’’ function becomes a basic part of the feature.
— 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 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.
— Support of SRVCC for active conference call.
2 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

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. This Function Specification covers the transfer of a single or first call
while for the transfer of an additional call, see Function Specification PS to CS
SRVCC for Additional Call. In case the single or first call is a conference call, see
Function Specification Support of IMS Conference Control after SRVCC transfer
for the handling of the conference call after SRVCC transfer.
‘‘LTE to GSM Handover (SRVCC)’’ is applicable for the following traffic cases:
— Active call (including emergency calls)
— Active conference call
— Held call
— Held conference call
— Originating call in alerting state
— Terminating call in alerting state
— Originating call in pre-alerting state
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.
Based on Robust SRVCC configuration option the MSC-S supports handover of

non-emergency calls in pre-alerting and alerting state in case IMS network or the
UE does not support handover of calls in early phases. Handover of Terminating
call in pre-alerting state is also supported that way.
External Protocols
— BICC or ISUP
— BSSAP
— MAP V2
— MAP V3
— SIP
— Sv-Interface Protocol for SRVCC based on GTPv2-C
Prerequisites
— The feature ‘‘LTE to GSM Handover (SRVCC)’’ is available.
— The feature ‘‘MGCF for Interworking with IMS’’ is available and active.
— The feature ‘‘WCDMA to GSM Handover’’ is available and active.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 3

— The feature ‘‘Support of Interworking with MMTel/IMS’’ is available and

active.
— The optional Location Continuity Procedure triggered during an emergency
call based on configuration option requires the feature ‘‘Positioning’’ to be
available and active.
— SRVCC with priority handling requires ‘‘Enhanced Multi-Level Precedence and
Pre-emption’’ (EMLPP) feature to be available.
LTE to GSM Handover (SRVCC) Documentation Overview
Table 1
Function Specifications Procedural Information
LTE to GSM Handover (SRVCC) Sv-Interface Configuration and
Enabling of Single Radio Voice Call
Continuity
PS to CS SRVCC for Additional Call LTE to GSM Handover (SRVCC),
Activate
Support of IMS Conference Control LTE to GSM Handover (SRVCC),
after SRVCC transfer Deactivate
4 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
3 Function
3.1 General
For the function ‘‘LTE to GSM Handover (SRVCC)’’ 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 Figure 1 and Figure 2, respectively.
The MSC-S initiates an Intra-MSC Handover or Inter-MSC Handover, respectively.

For a detailed description of the Handover functions, see the Function
Specification UMTS to GSM Handover in MSC/VLR Server.
LTE
eNodeB GMLC HLR
S1-MME
Lg D
Sv
EPC
MSC-S/
MME MGCF A
Mw Mc/Mn
GSM
BSC
A
IMS Mb
CSCF/
ATCF or MGW1
MGW
EATF
Interface
Signaling
User Plane
Figure 1 Handover Scenario - Target Cell Belongs to MSC-S Supporting the
Sv-Interface
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 5

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

Interface Protocol
A BSSAP
D MAP V2 and MAP 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
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
see the Function Specification Sv-Interface, General Aspects, Message Formats
and Coding for SRVCC. For a detailed description of the GTPv2-C protocol
6 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
see the Function Specification GTP-C, Signaling 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 see the Function Specification Generic Transport
Function, Traffic, Administration and Maintenance.
For a detailed description of the Area Cluster Administration function, see 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, see the User Guide Sv-Interface Configuration and Enabling
of Single Radio Voice Call Continuity.
In the context of this document, the term:

— SRVCC Procedure refers to LTE to GSM Handover, including the handover 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)
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.
— Target BSC refers to the BSC to which the target cell belongs. This BSC 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.
— MSC-S state refers to the state of mobile access side.
— Conference call refers to an instance of a multi-party conversation. More
specifically, conference call refers to the SRVCC transferred active or held
conference call for the served subscriber, that has initiated the conference in
IMS, acting as Conference Controller.
— Held call refers to an answered voice call between two subscribers without
a speech connection.
— Held conference call refers to an conference call without a speech connection
to the served subscriber acting as conference controller.
3.2 Traffic Handling

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.16 on page
51. 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
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 7

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 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 before certain actions
are possible in the block to which the arrow points.
Differences for SRVCC Procedure for Emergency Calls are described in Section
3.2.17 on page 77.
Figure 3 General Flow of SRVCC Procedure
Note: The response to MME could be handled at later point of time, based on
configuration option described in Section 3.2.3 on page 14.
The following subsections correspond to the blocks shown on the figure above.
8 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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 10
— Handover Request, see Section 3.2.2 on page 10
— Response to MME, see Section 3.2.3 on page 14
— IMS Session Transfer, see Section 3.2.4 on page 17
— Handover Completion, see Section 3.2.5 on page 26
— SRVCC Complete Notification to MME, see Section 3.2.6 on page 28
— TMSI Allocation (conditional), see Section 3.2.7 on page 30
— Location Update towards HLR (conditional), see Section 3.2.8 on page 33
The following additional steps are needed for the continuation of the service:
— Alerting for originating call in pre-alerting state (conditional), see Section

3.2.10 on page 37
— Call Acceptance for call in alerting state or originating call in pre-alerting state
(conditional), see Section 3.2.11 on page 39
— Reception of Conference Call Information (conditional), see Section 3.2.12

on page 44
The following additional step might be needed based on configuration option for
emergency calls:
— Location Continuity (conditional), Section 3.2.17.8 on page 79
The following additional step may conditionally be applied during the SRVCC
Procedure:
— Status Enquiry Procedure, see Section 3.2.9 on page 34
In addition, dedicated sections describe the followings:

— Request from the MME to cancel an ongoing SRVCC Procedure, see Section
3.2.13 on page 46
— Interactions between requests for SRVCC Procedure, see Section 3.2.14 on
page 47
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 9

— Rejection of Requests for SRVCC Procedure by MSC-S, see Section 3.2.15

on page 48
— Interactions between MSC-S and MGW, see Section 3.2.16 on page 51
Note: In the following sections, in all figures, the messages displayed as blue
dashed curved lines indicate dependencies between messages, and the
messages displayed as dashed lines represent that these messages are
optional. SDP is not shown in the figures for the sake of simplicity. SIP
PRACK and SIP 200 OKPRACK messages shown are only sent/received by
MSC-S if SIP 18x provisional response from IMS is sent reliably. Reliability
of provisional responses is supported on Mw interface.
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 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.
In case of SRVCC with priority handling, handover of the radio access side
and IMS Session Transfer can be treated with priority, if MME provides
Allocation/Retention Priority (ARP) IE in Sv-Interface protocol SRVCC PS
TO CS REQUEST message and EMLPP feature is enabled. If ARP IE is not received,
but ‘‘EMLPP’’ feature is enabled and/or ‘‘Roaming Priority Handling’’ feature is
active, call can still be treated with priority, as described in Function Specification
Enhanced Multi-Level Precedence and Pre-emption Service in MSC Server and
Function Specification Roaming Priority Handling in MSC Server.
MME Sv-Interface Protocol MSC-S
SRVCC PS TO CS REQUEST
Figure 4 Reception of SRVCC PS TO CS REQUEST
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 later
Sv-Interface SRVCC PS TO CS COMPLETE NOTIFICATION message. For a detailed
description of the data received from the MME, see the Function Specification
Sv-Interface, General Aspects, Message Formats and Coding for SRVCC.
10 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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.16 on page 51.
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, see 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 PS 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.
Sv-Interface Protocol BSSMAP

Target
MME MSC-S
BSC
SRVCC PS TO CS REQUEST
HANDOVER
REQUEST
HANDOVER
REQUEST
ACKNOWLEDGE
Figure 5 Handover Request
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:
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 BSSMAP HANDOVER REQUEST
CS REQUEST
IMSI IMSI
MM Context for E-UTRAN SRVCC Classmark Information Type 2
Classmark Information Type 3

(1)
MM Context for E-UTRAN SRVCC Encryption Information
(CKSRVCC - IKSRVCC)
Source to Target Transparent Old BSS to New BSS Information
Container
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 11

Sv-Interface Protocol SRVCC PS TO BSSMAP HANDOVER REQUEST

CS REQUEST
Target Cell ID Cell Identifier
Allocation/Retention Priority Priority
(2)
(ARP)
(1) C3 Conversion function, for more information, see Function Specification Mobile Subscriber
Related Security Functions in MSC/VLR Server.
(2) ARP is an optional IE
The association between ARP IE received within SRVCC PS TO CS REQUEST

message and Priority sent in BSSMAP Handover Request is the following.
— MSC-S sends Priority Level with the lowest priority value (14), and Queueing
Allowed Indicator (QAI) set to ‘‘queuing not allowed’’ (0), for all received ARP
Priority Level values. This can be changed by command. Commands MGAMC
and MGAMP are available to change and print which Priority Level and QAI are
sent for each ARP Priority Level received with ARP IE.
— Pre-emption Capability Indicator (PCI) and Pre-emption Vulnerability

Indicator (PVI) sent in Priority are set according to ARP PCI and PVI
received in ARP IE respectively, keeping the same meaning of the information
as received.
If queuing indication is received as response to a resource allocation due to

HANDOVER REQUEST it is ignored by the MSC-S.
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.
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
see Function Specification Out of Band Transcoder Control in MSC Server,
GMSC Server and TSC Server and when ‘‘AMR-WB’’ is activated see Function
Specification Support of AMR-WB Speech Codec.
12 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
For a detailed description of the sending of the BSSMAP message, see 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.
Handover Scenario 2: Target Cell Belongs to Neighboring MSC-S

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 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, see the following Function Specifications:
— UMTS to GSM Handover in MSC/VLR Server
— Inter-MSC Handover/Relocation to MSC Pool
However, as the handover performed does not originate in an RNC of a circuit

switched WCDMA network, but in a PS 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.
Sv-Interface
Protocol MAP Neighboring BSSMAP
Target
MME MSC-S MSC-S BSC
SRVCC PS TO
CS REQUEST
PREPARE
HANDOVER
request
HANDOVER
REQUEST
HANDOVER
REQUEST
ACKNOWLEDGE
PREPARE
HANDOVER
response
Figure 6 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 the BSSMAP
messages are encapsulated in MAP messages for being sent between the MSC-S
and the Neighboring MSC-S with MAP MAP V2 or MAP V3. For a detailed
description of the encapsulation, see the Function Specification UMTS to GSM
Handover in MSC/VLR Server and to the Function Specifications Signalling
System No.7, Mobile Application Part Version 2 for Inter-MSC Handover in
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 13

MSC/VLR Server, and Signalling System No.7, Mobile Application Part Version 3
for Inter-MSC Handover in MSC/VLR Server,
If MAP V2 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 4.
Table 4 Mapping of Information between Sv-Interface Protocol SRVCC PS

TO CS REQUEST Message and MAP PREPARE HANDOVER Request
Message with MAP V2
Sv-Interface Protocol SRVCC PS TO
CS REQUEST MAP PREPARE HANDOVER Request
Target Cell ID Target Cell ID
If MAP V3 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:
Table 5 Mapping of Information between Sv-Interface protocol SRVCC PS

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

This section describes the response sent by the MSC-S to the MME.
14 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Based on Robust SRVCC configuration option, controlled by the AXE Parameter

ROBUSTSRVCC from AXE Parameter Set GSM1APTC, the MSC-S either responds to the
MME immediately after receiving the BSSMAP HANDOVER REQUEST ACKNOWLEDGE,
or after receiving both the BSSMAP HANDOVER REQUEST ACKNOWLEDGE and a
response to the session transfer towards the IMS network (see Section 3.2.4 on
page 17):
— With ROBUSTSRVCC not activated, the MSC-S sends the Sv-Interface protocol
SRVCC PS to CS Response message to the MME according to one of the two
handover scenarios below.
— With ROBUSTSRVCC activated, and a
• positive response to the session transfer towards the IMS network, the
MSC-S sends the Sv-Interface protocol SRVCC PS to CS Response
message with a successful indication to the MME, according to one of
the two handover scenarios below.
• negative response to the session transfer towards the IMS network, the
MSC-S sends the Sv-Interface protocol SRVCC PS to CS Response
message with an unsuccessful indication to the MME, according to
Section 3.2.15 on page 48.
Handover Scenario 1: Target Cell belongs to MSC-S

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.
Figure 7 Response to MME
Based on Robust SRVCC configuration option, the MSC-S delays sending of

SRVCC PS TO CS RESPONSE message to the MME until reception of BSSMAP
HANDOVER REQUEST ACKNOWLEDGE message from the Target BSC and reception
of the following:
— SIP final response for IMS session transfer for an active or held call (for
successful SIP final response see SIP 200 OK INVITE message reception in
Figure 9) or
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 15

— SIP INFO message for IMSI session transfer of an originating call in alerting
or pre-alerting state (see SIP INFO message reception in Figure 10 and
Figure 11).
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 ACKNOWLEDGE Sv-Interface Protocol SRVCC
PS TO CS RESPONSE
Layer 3 Information Target to Source
Transparent Container
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 Plane field
of the Sv-Interface protocol SRVCC PS TO CS RESPONSE message.
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 of this retransmission time
period, see the Function Specification GTP-C, Signaling Transport.
In case reception of unsuccessful SIP final response to INVITE while response

to MME is delayed or for other unsuccessful cases occurrence before sending
response to MME, MSC-S sends SRVCC PS TO CS RESPONSE message indicating
unsuccessful result and terminates SRVCC procedure as described in Section
3.2.15 on page 48. In this case SRVCC PS TO CS REQUEST message which
initiated previously terminated SRVCC Procedure can be received afterwards and
it is again handled as described from Section 3.2.1 on page 10 onwards.

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
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. That is unless delayed by Robust SRVCC configuration option
until later point in time as described on Page 15.
16 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Figure 8 Response to MME, Neighboring MSC-S Scenario
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 Transaction Identifier (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
The reception of the BSSMAP HANDOVER REQUEST ACKNOWLEDGE message triggers

the MSC-S to initiate the session transfer towards the IMS network, 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 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 request. MSC-S populates the SIP
INVITE request 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,
see Function Specification Sv-Interface, 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 request
(1)
Sv-Interface Protocol SRVCC PS TO SIP INVITE
CS REQUEST
(2)
C-MSISDN From header
P-Asserted-Identity header
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 17

(1)
Sv-Interface Protocol SRVCC PS TO SIP INVITE
CS REQUEST
STN-SR To header
Request-URI
(4)
Allocation/Retention Priority Resource-Priority header
(3)
(ARP)
(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, see the Function Specification Session Initiation Protocol .
(3) ARP is an optional IE
(4) For a detailed description of Resource-Priority header syntax and handling, see Function
Specification Session Initiation Protocol
MSC-S sends Resource-Priority header with the q735 namespace and related
priority level value set to the granted eMLPP priority level value whereby q735
priority level 0 is sent for the granted eMLPP priority level values A and B.
Granted eMLPP priority level is set to ARP eMLPP Priority Level based on the
received ARP Priority Level in ARP IE. ARP eMLPP Priority Level is set to the
lowest priority value (value 4) for all received ARP Priority Level values. This can
be changed by command. Commands MGAMC and MGAMP are available to change
and print which ARP eMLPP Priority Level is assigned for each ARP Priority Level
received within ARP IE.
MSC-S supports sending of Resource-Priority header with ets and wps

namespaces as generic route parameter RPHSNS configuration option.
Priority level value sent with wps and ets namespaces is set to the granted eMLPP
priority level value, whereby wps and ets priority level 0 is sent for the granted
eMLPP priority level values A and B. Based on generic route parameter ETSPLS, the
priority level assigned with ets namespace can instead be set to the value defined
by AXE Parameter RPHNSPL from AXE Parameter Set SIPSUPPORTC or to value
0 for all granted eMLPP priority level values.
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 request.
Table 8 Additional Headers and Parameters in SIP INVITE request

Header Parameter
Allow INFO
(1)
REFER
(2)
NOTIFY
18 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Header Parameter
Accept application/vnd.3gpp.state-and-
event-info+xml
application/vnd.3gpp.mid-call+
xml
(3)
Contact +g.3gpp.icsi-ref="urn%3Aurn-7%3
A3gpp-service.ims.icsi.mmtel“;
+g.3gpp.srvcc-alerting;+g.3gpp.
ps2cs-srvcc-orig-pre-alerting;
+g.3gpp.mid-call
Accept-Contact +g.3gpp.icsi-ref="urn%3Aurn-7%3
A3gpp-service.ims.icsi.mmtel"
(4)
P-Asserted-Service urn:urn-7:3gpp-service.ims.ics
i.mmtel
Recv-Info +g.3gpp.state-and-event;
+g.3gpp.mid-call
Supported norefersub
(4)
P-Charging-Vector orig-ioi is of type 1 in the
header field
(4)
P-Access-Network-Info 3GPP-GERAN
(5)
cgi-3gpp
network-provided
(1) REFER message is used for a possible additional call transfer. For a detailed description of
REFER message reception, see Function Specification PS to CS SRVCC for Additional Call.
(2) NOTIFY message is received as an answer to a possible outgoing REFER message that requests
disconnection of a remote party. For more information see Function Specification Support of IMS
Conference Control after SRVCC transfer.
(3) 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 request.
(4) The route to IMS is considered as trusted route.
(5) cgi-3gpp parameter includes the target Cell Global Identification (CGI) as received in
Sv-Interface protocol SRVCC PS TO CS REQUEST message
MSC-S builds the SDP offer for the SIP INVITE request based on its configuration
and capabilities as for any other SIP voice call. See Function Specification
Session Initiation Protocol for further details. See 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, see User Guide Sv-Interface

Configuration and Enabling of Single Radio Voice Call Continuity.
Apart from the recommended P-Access-Network-Info header population shown

in Table 8, configuration option (PANI and PANIPRF generic route parameters)
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 19

exists to populate the header based on the location number as described in

Function Specification Session Initiation Protocol.
After the MSC-S has initiated the IMS session transfer, MSC-S includes
P-Access-Network-Info header as specified in Table 8, but with the actual UE
location information in subsequent SIP requests and responses as described
in Function Specification Session Initiation Protocol. If this happens after an
Inter-System handover to WCDMA access, P-Access-Network-Info header is
populated as for the session transfer described in Function Specification LTE to
WCDMA Handover (SRVCC), but with the actual UE location information.
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.
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 request)
described in Page 20
— Originating call in alerting state, and terminating call in alerting state

(indicated in the SIP INFO message), described in Page 22
— Originating call in pre-alerting state, (indicated in the SIP INFO message),

described in Page 23
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.
Session Transfer of an Active or Held Call

As shown in Figure 9, MSC-S receives the SIP 200 OK INVITE request (as answer
to the previously sent SIP INVITE request), 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 request, and configures the bearer termination towards the IMS network as
20 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
SIP BSSMAP
Target
IMS MSC-S
BSC
HANDOVER
REQUEST
ACKNOWLEDGE
INVITE
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.
— 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.
Note: If media directionality received in SDP answer is sendonly, this is

interpreted as call held by remote UE. This applies regardless the presence
of +g.3gpp.mid-call feature capability indicator in SIP 200 OK INVITE.
In case the SIP 200 OK INVITE request includes the isfocus media feature tag
in Contact header, then the served subscriber is a conference participant.
If the subscriber has initiated the conference call in IMS network, after the
acknowledgment of SIP 200 OK INVITE , MSC-S receives a SIP INFO message, as
At reception of SIP 200 OK INVITE MSC-S also handles any buffered DTAP message
reception events as described in Table 9.
DTAP message reception event buffering is described in Section 3.2.5 on page 26.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 21

Table 9 DTAP Message Handling for Active or Held Call

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 request, 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
request 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 request), and configures the bearer
termination towards the IMS network as described in Section 3.2.16 on page 51.
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 39, while the latter is
described below.
SIP BSSMAP
Target
IMS MSC-S
BSC
HANDOVER
REQUEST
ACKNOWLEDGE
INVITE
183 Session Progress
PRACK
200 OKPRACK
INFO
200 OKINFO
MSC-S in
Call Delivered or
Call Received state
Figure 10 Session Transfer of Call in Alerting State
22 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Note: The first SIP 183 Session Progress message received in MSC-S, after
SIP INVITE request, 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, the MSC-S expects a SIP 200 OKINVITE
request containing the actual SDP answer received in a dialog different to
the one created with the previous received SIP 183 Session Progress
message.
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-inf

o> 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, see 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.
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
After the reception of SIP INFO, MSC-S behaves according to its state.
Session Transfer of Originating Call in Pre-alerting State

As shown in Figure 11, MSC-S receives the SIP 183 Session Progress message
(as answer to the previously sent SIP INVITE request), and configures the bearer
termination towards the IMS network (if SDP body from remote side is received)
as described in Section 3.2.16 on page 51.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 23

IMS SIP MSC-S DTAP UE

BS
SM
AP Target
BSC
HANDOVER
REQUEST
ACKNOWLEDGE
INVITE
183 (Session Progress)
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
Note: DTAP PROGRESS message is sent after BSSMAP HANDOVER COMPLETE

message has been received. Reception of HANDOVER COMPLETE message
is described in Section 3.2.5 on page 26.
Note: The first SIP 183 Session Progress message received in MSC-S, after
SIP INVITE request, 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.
When MSC-S receives a SIP INFO message from the IMS network, MSC-S
acknowledges it.
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 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
24 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
to pre-alerting. For more information, see 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 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.
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, see 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.
At reception of SIP INFO, MSC-S also handles any buffered DTAP message
reception events as described in Table 11
Table 11 DTAP Message Handling for Originating Call in Pre-alerting State

Incoming DTAP Message Answer DTAP Message in Originating Pre-alerting Case
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.
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 message ACM or a BICC or ISUP 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.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 25

SIP MAP Neighboring BSSMAP

Target
IMS MSC-S MSC-S
BICC or BSC
ISUP
HANDOVER
REQUEST
ACKNOWLEDGE
PREPARE
HANDOVER
response
ACM or CON
INVITE
Figure 12 Session Transfer, Neighboring MSC-S Scenario
Session Transfer of Active or Held Call or Call in Alerting State

After sending the SIP INVITE request, the same messages are sent and expected
to be received by the MSC-S as shown in the following figures:
— Figure 9 for active or held call
— Figure 10 for call in alerting state
Session Transfer of Originating Call in Pre-alerting State

After sending the SIP INVITE request, 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 sending response to MME indicating the acceptance
of PS to CS request, the MSC-S waits for the BSSMAP HANDOVER DETECT message
or for the BSSMAP HANDOVER COMPLETE message. The reception of a BSSMAP
HANDOVER DETECT message is conditional.
26 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
BSSMAP
Target
MSC-S
BSC
HANDOVER
DETECT
HANDOVER
COMPLETE
Figure 13 Handover Completion
The completion of the Intra-MSC Handover is supervised by supervision timer

TIMUGHOINTRAM, defined by the AXE Parameter TIMUGHOINTRAM from AXE
Parameter Set GSM1APTC.
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 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 17.
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 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 26.
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.
The completion of the Inter-MSC Handover is supervised by supervision timer

TIMUGHOBASICM, defined by AXE Parameter TIMUGHOBASICM from AXE Parameter
Set GSM1APTC.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 27

MAP Neighboring BSSMAP

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

This section describes the SRVCC Complete Notification sent by the MSC-S to
the MME.

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, see the Function Specification
GTP-C, Signaling Transport.
28 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Sv-Interface Protocol BSSMAP

Target
MME MSC-S
BSC
HANDOVER
COMPLETE
SRVCC PS TO CS
COMPLETE NOTIFICATION
SRVCC PS TO CS
COMPLETE ACKNOWLEDGE
Figure 15 SRVCC Complete Notification to MME
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 when sending
the Sv-Interface protocol SRVCC PS TO CS COMPLETE NOTIFICATION message,
see the Function Specification Generic Transport Function, Traffic, Administration
and Maintenance.
When sending an Sv-Interface protocol SRVCC PS TO CS COMPLETE

NOTIFICATION message is not possible, the ongoing SRVCC Procedure continues
unaffected.
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.
After HANDOVER COMPLETE message has been received, the MSC-S is the anchor
MSC-S for any upcoming subsequent handover.
The Priority Level, PCI, PVI and QAIinformation derived from ARP IE as explained
in Section 3.2.2 on page 10 is used in the subsequent handover/relocation
procedures.
Note: The SRVCC Complete Notification is sent by the MSC-S to the MME
although there might be an additional call transfer ongoing. For a detailed
description of the additional call transfer, see 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 28.
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/14 Uen A | 2019-06-19 29

Sv-Interface
Protocol MAP Neighboring BSSMAP
Target
MME MSC-S MSC-S
BICC or ISUP BSC
HANDOVER
DETECT
PROCESS ACCESS
SIGNALLING
ANM
HANDOVER
COMPLETE
SEND END SIGNAL
SRVCC PS TO CS
COMPLETE
NOTIFICATION
SRVCC PS TO CS
COMPLETE
ACKNOWLEDGE
Figure 16 SRVCC Complete Notification to MME, Neighboring MSC-S Scenario
After HANDOVER COMPLETE message has been received, the MSC-S is the anchor
MSC-S for any upcoming subsequent handover.
3.2.7 TMSI Allocation

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
Parameter TMSIPAR from AXE Parameter Set GSMMMSC is set to determine that
TMSI allocation on all connections is performed in the MSC-S.

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
30 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
change of location area is configured by AXE Parameter TMSILAIMSC from

AXE Parameter Set GSMMMSC.

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 from
AXE Parameter Set GSMMMSC.
BSSMAP
Target
MSC-S
DTAP BSC
HANDOVER
COMPLETE
TMSI REALLOCATION
COMMAND
TMSI REALLOCATION
COMPLETE
Figure 17 TMSI Allocation
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:
— The LAI stored in VLR only if the conditions described in the last list item
of the list above are fulfilled
— 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:
— 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/relocation

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.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 31

The NB-LAI is configurable dependent on the administration method used:
Single NB-LAI administration method

The NB-LAI is administered by means of AXE Parameters
NBMCC, NBMNC and NBLAC from AXE Parameter Set
GSMMMSC for Mobile Country Code (MCC), Mobile Network
Code (MNC) and Location Area Code (LAC) respectively.
Enhanced NB-LAI administration method

The NB-LAI is administered by means of AXE Parameter
PLMNNBLAC from AXE Parameter Set GSMMMSC for LAC.
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.
The LAI that is derived from the target cell, is stored in the VLR upon successful
completion of TMSI reallocation procedure, in the following cases:

protocol SRVCC PS TO CS REQUEST message, but no LAI is stored in the VLR.
For a detailed description of the TMSI allocation procedure, see the Function
Specification Mobile Subscriber Related Security Functions in MSC/VLR Server.

Apart from the differences specified below, the TMSI Reallocation procedure is
initiated by the MSC-S as described in Page 30.
Allocation of a new TMSI at change of location area, which is determined by AXE

Parameter TMSILAIMSC from AXE 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 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 SIGNALLING and PROCESS
ACCESS SIGNALLING messages respectively, as shown in Figure 18.
32 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
MAP Neighboring BSSMAP

Target
MSC-S MSC-S DTAP BSC
HANDOVER
COMPLETE
SEND END SIGNAL
FORWARD ACCESS
SIGNALLING
TMSI REALLOCATION
COMMAND
TMSI REALLOCATION
COMPLETE
PROCESS ACCESS
SIGNALLING
Figure 18 TMSI Allocation, Neighboring MSC-S Scenario
The LAI is not stored in VLR if the target cell is administered as outer cell in the
MSC-S.
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.
3.2.8 Location Update Towards HLR
This section describes the Location Update procedure, initiated by the MSC-S.

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, see 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/14 Uen A | 2019-06-19 33

MAP DTAP
Target
HLR MSC-S
BSC
TMSI REALLOCATION
COMPLETE
UPDATE LOCATION
INSERT SUBSCRIBER
DATA
INSERT SUBSCRIBER
DATA RESULT
UPDATE LOCATION
RESULT
Figure 19 Location Update

Apart from the differences specified below, the Location Update procedure is
initiated by the MSC-S as described in Page 33.
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.
MAP MAP Neighboring Target

HLR MSC-S MSC-S
DTAP
BSC
TMSI REALLOCATION
COMPLETE
PROCESS ACCESS
SIGNALLING
UPDATE LOCATION
INSERT SUBSCRIBER
DATA
INSERT SUBSCRIBER
DATA RESULT
UPDATE LOCATION
RESULT
Figure 20 Location Update, Neighboring MSC-S Scenario
34 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

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 ENQUIRY
message to the UE and starting T322 timer at the reception of the following
messages:
— SIP INFO message for originating call in pre-alerting state or call in alerting
state
— SIP 200 OKINVITE request for active or held call
if the following conditions are fulfilled:
1. AXE Parameter SRVCCSTAENQENBL from AXE Parameter Set GSM1APTC

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

MSC-S stops timer T322, compares DTAP STATUS message 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 AXE
Parameter SRVCCSTAENQENBL from AXE Parameter Set GSM1APTC 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.
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
based on the same cause value.
Note: T322 timer is configured by AXE Parameter SRVCCSTAENQT322 from AXE

Parameter Set GSM1APTC .
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/14 Uen A | 2019-06-19 35

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. No action.
Mobile Originatin MSC-S releases the call MSC-S triggers Call Connected
g call proceeding using cause code ‘‘message procedure to align the
(1)(2)
not compatible with states.
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 Session
Initiation Protocol.
Depending on route
configuration (MIS2 route
parameter) the SIP Reason
header is included based on
the same cause value.
Call Delivered MSC-S clears the call. MSC-S triggers ‘‘Call
Connected’’ procedure to
(1)(2)
align the states.
(2)
Connect Request MSC-S clears the call. No action.
Connect Active MSC-S clears the call. MSC-S enters ‘‘Active’’ state.
Indication
Call Delivered No action. No action.
Mobile Originatin No action. No action.
g Call Proceeding
Call Delivere Call Delivered No action. No action.
d (3)
Mobile Originatin MSC-S clears the call. MSC-S triggers ‘‘Alerting’’
(5)
g Call Proceeding or procedure to align the states.
(4)
No action. or
(4)
No action.
Mobile Mobile Originatin No action. No action.
Originating g Call Proceeding
Call
Call Delivered MSC-S clears the call. MSC-S enters ‘‘Call Delivered’’
Proceeding
state.
Call Received Call Received No action. No action.
36 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

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 Request No action. No action.
Request
Other state combinations MSC-S releases the call using cause code ‘‘message not
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
Session Initiation Protocol. Depending on route configuration
(MIS2 route parameter) the SIP Reason header is included
based on the same cause value.
(1) Due to this procedure the MSC-S changes state back to ‘Connect Indication’ and reaches state ‘‘Active’’ when
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’’.
(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
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.
For possible release sequence on SIP towards IMS, see Function Specification
Session Initiation Protocol.

Apart from the difference specified below, the Status Enquiry procedure is initiated
by the MSC-S as described in Page 35.
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/14 Uen A | 2019-06-19 37

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,
see Function Specification A/Iu-Interface, Section K: DTAP and RANAP/NAS,
Message Formats and Coding for Call Control and Call Related Supplementary
Service Procedures.
MSC-S in
Mobile Originating Call
Proceeding state
180 Ringing
PRACK
MSC-S in
Call Delivered
state
ALERTING
200 OKPRACK
Figure 21 Alerting for Originating Call in Pre-Alerting State
In this case, DTAP ALERTING message is encapsulated in MAP FORWARD ACCESS

SIGNALLING messages, as shown in Figure 22.
38 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
SIP MAP Neighboring DTAP

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

Scenario
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
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 connection in the
user plane, the call has to be answered.
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 request
indicates that the call is accepted. This triggers through connection as described
in Section 3.2.16 on page 51 .
As shown in Figure 23, MSC-S sends a DTAP CONNECT message to the UE to

indicate that the called party has accepted the call and the UE acknowledges it.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 39

200 OKINVITE
ACK
CONNECT
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.
— 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 17.
Upon reception of a DTAP CONNECT message, MSC-S triggers the bothway
through connection (see Section 3.2.16 on page 51), 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.
Note: For the traffic scenario that the MSC-S first receives a SIP 183 with
SDP bearing unspecified connection address, bothway through
connection is not triggered after reception of DTAP CONNECT message
from the UE and until reception of SIP 200 OKINVITE request with
valid remote connection address.
40 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
CONNECT
CONNECT
ACKNOWLEDGE
MSC-S in
Active
state
INFO
200 OKINFO
200 OKINVITE
ACK
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
In this case, after the reception of DTAP CONNECT message, MSC-S proceeds
with its handling, performs bothway through connection (see Section 3.2.16
on page 51), acknowledges the message with DTAP CONNECT ACK and enters
the Active state.
Note: For the traffic scenario that the MSC-S first receives a SIP 183 with
SDP bearing unspecified connection address, bothway through
connection is not triggered after reception of DTAP CONNECT message
from the UE and until reception of SIP 200 OKINVITE request with
valid remote connection address.
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 based on the same
cause value.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 41

CONNECT
CONNECT
ACKNOWLEDGE
MSC-S in
Active
state
INFO
200 OKINFO
INFO (Call Accepted)
200 OKINFO
200 OKINVITE
ACK
Figure 25 Call Acceptance of Terminating Alerting Call, DTAP CONNECT Is

Received Before SIP INFO
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 39.
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.
42 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
SIP MAP Neighboring DTAP

IMS MSC-S UE
MSC-S
200 OKINVITE
ACK
FORWARD ACCESS
SIGNALLING
CONNECT
CONNECT
ACKNOWLEDGE
PROCESS ACCESS
SIGNALLING
MSC-S in
Active
state
Figure 26 Call Acceptance of Originating Call, Neighboring MSC-S Scenario
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.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 43

SIP MAP Neighboring DTAP UE

IMS MSC-S MSC-S
CONNECT
PROCESS ACCESS
SIGNALLING
FORWARD ACCESS
SIGNALLING
CONNECT
ACKNOWLEDGE
MSC-S in
Active
state
INFO
200 OKINFO
200 OKINVITE
ACK
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 Figure 25, with messages
DTAP CONNECT and CONNECT ACKNOWLEDGE being encapsulated in MAP PROCESS
ACCESS SIGNALLING and FORWARD ACCESS SIGNALLING messages respectively.
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 request due to STN-SR included in the Contact
header the isfocus media feature tag.
— The first transferred session corresponds to an active or held call as described

in Page 20.
— The message includes the <mid-call> element including conference

participants list with the relevant Uniform Resource Identifier (URI)s.
— The number of the IMS conference participants included in SIP INFO message
is one-five.
MSC-S recognizes the transferred session as an active or held conference call and
assigns Transaction Identifier (TI)s to the IMS conference participants.
44 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

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

based on their order of presence in the list and based on the number of IMS
conference participants. 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 or held conference call as a multi-party call and acknowledges
the SIP INFO message by sending SIP 200 OK INFO.
The MSC-S is capable to manipulate the state of the transferred conference call, by
means of the existing multi-party supplementary service procedures as described
in Function Specification Support of IMS Conference Control after SRVCC transfer.
If timer T322 of the STATUS ENQUIRY procedure is running, it is stopped.
Figure 28 Reception of Conference Call Information
As the reception of DTAP messages is possible after handover completion to

target BSC, it is possible to receive DTAP messages before the TI values of the
conference call are assigned. Such a DTAP message received with unknown TI,
is immediately answered with DTAP RELEASE COMPLETE message with cause
code ‘‘Invalid Transaction Identifier Value’’. Additionally MSC-S memorizes
this as a disconnection event for the related TI. This is also valid for a received
DTAP RELEASE COMPLETE message, but with the difference that no response
is sent to the UE.
During the handling of SIP INFO, if one or more disconnection events are
memorized or additional DTAP disconnection requests are received, the MSC-S
behaves as follows:
— If no remaining IMS conference participants exist in the conference call,

the MSC-S positively acknowledges the SIP INFO with SIP 200 OKINFO,
acknowledges the DTAP disconnection requests received during the handling
of the SIP INFO message and releases the conference call leg towards
IMS with a SIP BYE request as described in Function Specification Session
Initiation Protocol. Depending on route configuration (MIS2 route parameter)
the SIP Reason header is included with cause code based on the one used for
the last IMS conference participant disconnection.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 45

— If at least one remaining IMS conference participant still exists in the

conference call, the MSC-S positively acknowledges the SIP INFO with SIP 200
OKINFO and the memorized disconnection event(s) or additional received DTAP
disconnection request is handled as a disconnection of an IMS conference
participant as described in Function Specification Support of IMS Conference
Control after SRVCC transfer.
Rejection of Transfer of an active or held conference call

The following Table 13 describes the MSC-S SIP final responses towards IMS
network after SIP INFO with conference call information has been received by
the MSC-S and the request is rejected.
Table 13 SIP final responses towards IMS network

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
received at SIP 200 OK INVITE request
During the transfer of an additional 403 Forbidden
call, SIP INFO request is received after
the reception of a SIP REFER indicating
(1)
additional session transfer
Congestion 503 Service Unavailable
Internal failure 500 Server Internal Error
(1) The MSC-S releases both SRVCC call legs using cause code ‘‘Interworking Unspecified’’. For
more details about the release of additional call, see Function Specification PS to CS SRVCC
for Additional Call.
In all the cases mentioned in Table 13, the MSC-S releases the conference call,
following the SIP release call procedures. For more information on release
sequence on SIP towards IMS, see Function Specification Session Initiation
Protocol.
3.2.13 Cancellation of SRVCC Procedure
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.
The MSC-S uses the received IMSI to correlate the received cancellation request
with the corresponding SRVCC Procedure.
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 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
46 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
CANCEL ACKNOWLEDGE message with the cause code ‘‘Request accepted’’, discards
any security key information present for the subscriber and disconnects the call
leg towards the target cell. For a detailed description of the release towards the
target cell, see 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 the same Sv-Interface protocol SRVCC PS TO CS CANCEL NOTIFICATION
message is received again. For a detailed description of this retransmission time
period, see the Function Specification GTP-C, Signaling Transport.
In addition, if a SIP INVITE request 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.
— 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, see the Function
Specification GTP-C, Signaling Transport.
For a description of further possible rejection cases, see 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.14 Interaction between Requests for SRVCC Procedure

The MSC-S is prepared to handle the reception of an Sv-Interface protocol 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.
— 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,
see the Function Specification GTP-C, Signaling Transport.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 47

— 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, see the Function Specification
GTP-C, Signaling Transport.
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, see 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.15 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 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.
Table 14 describes the cause codes and SRVCC reject causes, which are 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, see 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.
48 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Table 14 Cause Codes and SRVCC Reject Causes Indicated in the Sv-Interface protocol SRVCC
PS TO CS RESPONSE Message
CONDITION CAUSE CODE SRVCC REJECT CAUSE
The call leg between MSC and IMS Request rejected Permanent Session Leg
(1)
cannot be established. Establishment error
OR
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
another CM transaction is triggered.
At reception of Sv-Interface protocol Service not supported Handover/Relocation target
SRVCC PS TO CS REQUEST message not allowed
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.
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
procedure terminates unsuccessfully
with cause code ‘‘Semantic Error’’, or
‘‘Unspecified Failure’’.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 49

Table 14 Cause Codes and SRVCC Reject Causes Indicated in the Sv-Interface protocol SRVCC PS
TO CS RESPONSE Message
The BSSMAP HANDOVER REQUEST No resource available Unspecified
procedure terminates unsuccessfully
with cause code ‘‘No resource
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.
(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 values within the 0-255 range either to permanent or
temporary Session Leg Establishment error. For information on mapping SIP External Cause or SIP Status
Code values to AXE Internal Cause values, see Application Information List of Cause Code and Location
Information Mappings.
(2) Except Short Message Service (SMS) over SGs.
Rejection with Complete Notification Message

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.
50 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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 Establishment
(2)
IMS cannot be established or is error
disconnected due to a fault of
(1)
permanent nature.
The call leg between MSC-S and Temporary Session Leg Establishment
(2)
IMS cannot be established or is error
disconnected due to a fault of
(3)
temporary nature.
(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, see Function Specification 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 to ‘‘Temporary Session Leg Establishment error’’. PAPs determine the mapping of AXE
Internal Cause values within the 0-255 range either to permanent or temporary Session Leg
Establishment error. For information on mapping SIP External Cause or SIP Status
Code values to AXE Internal Cause values, see Application Information List of Cause
Code and Location Information Mappings.
(3) Any received SIP 408, 480 or 481 message is treated as temporary fault and causes the
termination of SRVCC Procedure.
The MSC-S does not trigger announcements at the reception of unsuccessful SIP
responses to initial SIP INVITE due to STN-SR causing termination of SRVCC
procedure.
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:
— 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.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 51

3.2.16 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 IP Multimedia Media Gateway Function (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.
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.
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
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.
The figures in the following subsections are examples covering indicated bearer
set-up directions.
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.16.1 Handover scenario1: Target Cell belongs to MSC-S
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 are
used to represent user plane connections.
52 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Figure 29 Final Configuration of Contexts and Terminations for active call,

originating call in alerting state, terminating call in alerting state,
originating call in pre-alerting state and active conference call; Target
BSC Belongs to MSC-S
The final configuration shown in Figure 29 is applicable for the following traffic
cases:
— Active call
— Active Conference call
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 and
held conference call; Target BSC Belongs to MSC-S
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 53

cases:
— Held call
— Held Conference 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.
SRVCC procedure with Robust SRVCC configuration option not being activated
is presented in the following figures.
Bearer Seizure for SRVCC Call
Sv-Interface Protocol BSSMAP Target

MME MSC-S BSC
SIP GCP
IMS MGW
SRVCC PS TO CS
REQUEST
ADD.req (Ctx=?,T=?,
strmMode=SR)
Reserve RTP
Connection Point ADD.rep (Ctx=1,T=T1)
HANDOVER
REQUEST
ADD.req (Ctx=1,T=?,
Reserve IMS strmMode=RO)
Connection Point
+ Change IMS ADD.rep (Ctx=1,T=T2)
Through Connection HANDOVER
REQUEST
ACKNOWLEDGE
MOD.req (Ctx=1,T=T1)
Configure RTP
Connection Point MOD.rep (Ctx=1,T=T1)
(GSM Side)
SRVCC PS TO CS
RESPONSE
INVITE
Figure 31 Bearer Seizure for SRVCC Call
54 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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
— 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 10. 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.
Through Connection of Active Call and Active Conference Call
IMS SIP BSSMAP Target

MSC-S BSC
GCP
MGW
INVITE
200 OKINVITE
MOD.req (Ctx=1, T=T2)

Configure IMS
Resources MOD.rep (Ctx=1, T=T2)
ACK
User Plane Backward

Through Connected
HANDOVER DETECT
MOD.req (Ctx=1, T=T2,
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 and Active Conference Call
As shown in Figure 32, when the SIP 200 OK INVITE request is received in the MSC-S
, as answer to the previously sent SIP INVITE request, the MSC-S configures the
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 55

bearer termination towards the IMS network, based on the data received in the
SIP 200 OK INVITE request, by initiating a GCP Configure IMS Resources procedure.
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.
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 GCP Configure IMS Resources procedure and the BSSMAP HANDOVER
COMPLETE message are received.
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 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 request. In that specific case, upon DTAP CONNECT reception,
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.
56 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Through Connection of Held Call and Held Conference Call
IMS SIP BSSMAP Target

MSC-S BSC
GCP
MGW
INVITE
200 OKINVITE
MOD.req (Ctx=1, T=T2

strmMode=SR)
Change IMS
HANDOVER DETECT
strmMode=Inactive)
Change
User Plane Inactive HANDOVER

Through Connected COMPLETE
Configure IMS
ACK
Figure 33 Through Connection of Held Call and Held Conference Call
As shown in Figure 33, when the SIP 200 OK INVITE request is received in
the MSC-S, as answer to the previously sent SIP INVITE request, 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 configures the bearer
termination towards the IMS network, based on the data received in the SIP 200
OK INVITE request, by initiating a GCP Configure IMS Resources procedure.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 57

Configuration of Bearer Resources for Call in Alerting State
Figure 34 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 sent SIP
INVITE request, 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.
It is instead possible to receive a SIP 183 Session Progress message with an

SDP answer containing an unspecified address, in this case the following applies
as shown in Figure 35.
58 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Figure 35 Configuration of Bearer Resources for Call in Alerting State after

reception of first SIP 183 with unspecified connection address
As shown in Figure 35, for a call in alerting state when the first SIP 183 Session
Progress message is received in the MSC-S, as answer to the previously sent SIP
INVITE request 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), the MSC-S changes the stream mode of
the bearer termination towards the 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
expects a SIP INFO message.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 59

Through Connection for Originating Call in Alerting State
Figure 36 Through Connection for Originating Call in Alerting State
As shown in Figure 36, for a originating call in alerting state, when the SIP 200
OK INVITE request is received in the MSC-S, as answer to the previously sent SIP
INVITE request, 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.
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.
It is instead possible to receive a SIP 200 OKINVITE request with different

connection address from previous SIP 183 Session Progress, which was
bearing SDP containing an unspecified address, as shown in Figure 37.
60 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Figure 37 Through Connection for Originating Call in Alerting State after reception of first SIP
183 with unspecified connection address
As shown in Figure 37, the MSC-S receives a SIP 200 OK with different dialog ID
and different SDP body compared to the previous SIP 183, which was bearing
unspecified connection address.
MSC-S changes the stream mode of the bearer termination towards the target
IMS network using a GCP Change IMS Through Connection procedure, changes
the stream mode of the bearer termination towards the target BSC using a GCP
Change Through Connection procedure and configures the bearer termination
towards the IMS network using a GCP Configure IMS Resources procedure. This
results in the backward through connection of the speech path. The handling
after sending SIP ACK as response to the SIP 200 OK INVITE request is the same as
originating call in alerting state, as shown in Figure 36.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 61

Through Connection for Terminating Call in Alerting State
For terminating call in alerting state three 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
— SIP INFO message is received in MSC-S before DTAP CONNECT message, in

case first SIP 183 received earlier was bearing unspecified connection address
62 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function

GCP
BSSMAP Target
MGW
BSC
INFO
200 OKINFO
MOD.req (Ctx=1, T=T2

strmMode=Inactive)
Change IMS
User Plane Inactive HANDOVER

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

Through Connected
200 OKINFO
200 OKINVITE

Configure IMS
ACK
Figure 38 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’’.
As shown in Figure 38, 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
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 63

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 the speech path
in both directions.
When the SIP 200 OK INVITE request is received in the MSC-S, as answer to the
previously sent SIP INVITE request, the MSC-S configures the bearer termination
towards the IMS network by initiating a GCP Configure IMS Resources procedure.
In case a HANDOVER COMPLETE message is received without having received a

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 HANDOVER COMPLETE message are
received
64 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function

GCP
Target
MGW BSSMAP
BSC
HANDOVER
DETECT
HANDOVER
COMPLETE
CONNECT
strmMode=SR)
Change IMS
Through Connection MOD.rep (Ctx=1, T=T2) CONNECT
ACKNOWLEDGE
User Plane Bothway

Through Connected
INFO
200 OKINFO
200 OKINFO
200 OKINVITE

Configure IMS
ACK
Figure 39 Through Connection for Terminating Calls in Alerting State in case SIP INFO message is
received in MSC-S after DTAP CONNECT message
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 see Function
Specification Interworking with IMS Multimedia Telephony.
As shown in Figure 39, 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.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 65

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 request is received in the MSC-S, as answer to the
previously sent SIP INVITE request, the MSC-S configures the bearer termination
towards the IMS network by initiating a GCP Configure IMS Resources procedure.
Figure 40 Through Connection for Terminating Calls in Alerting State in case first SIP 183 received
earlier was bearing unspecified connection address
As shown in Figure 40, SIP INFO message and BSSMAP HANDOVER DETECT are
received. Then when DTAP CONNECT message is received in the MSC-S, a SIP
INFO request with ‘‘Call Accepted’’ is sent. When the SIP 200 OK INVITE request
66 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
is received in the MSC-S with a different dialog ID, as answer to the previously
sent SIP INVITE request, the MSC-S changes the stream mode of the bearer
termination towards the BSC by initiating a GCP Change Through Connection
procedure and configures the bearer termination towards the IMS network by
initiating a GCP Configure IMS Resources procedure. This results in the through
connection of the speech path in both directions.
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
request, 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, the same way is done for
originating call in alerting state, as shown in Figure 34.
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 following
applies as shown in Figure 41.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 67

Figure 41 Configuration of Bearer resources for Originating Calls in Pre-alerting

State
68 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
As shown in Figure 41, 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 request 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), the MSC-S changes the
stream mode of the bearer termination towards the 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 expects a SIP INFO message.
The second SIP 183 Session Progress message with SDP answer 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, changes the stream mode of the
bearer termination towards the IMS network using a GCP Change IMS Through
Connection procedure and changes the stream mode of the bearer termination
towards the target BSC using a GCP Change Through Connection procedure. This
results in the backward through connection of the speech path.
Through Connection for Originating Calls in Pre-alerting State

Bothway through-connection for originating pre-alerting call is the same as
Through Connection for originating call in alerting state as shown in Figure 36 or
in Figure 37 if the first SIP 183 Session Progress was bearing SDP containing
an unspecified address.
3.2.16.2 Handover scenario 2: Target Cell belongs to Neighboring MSC-S
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 42 and Figure 43.
Note: Solid lines are used to represent signalling connections. Dotted lines are
used to represent bearer connections.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 69

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

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

originating call in alerting state, terminating call in alerting state,
originating call in pre-alerting state and active conference call; Target
Cell belongs to Neighboring MSC-S
cases:
— Active call
— Active Conference call

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

Network T4 T3 T2 T1
CTX2 CTX1 target
MGW1 MGW2 BSC
Figure 43 Final Configuration of Contexts and Terminations for held call and
held conference call; Target BSC Belongs to MSC-S
cases:
— Held call
— Held conference 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
70 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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.
Bearer Seizures for Active or Held Call
Figure 44 Bearer Seizures for Active or Held Call, Part1
Note: For active and held conference calls the same handling applies as for
active and held calls
As shown in Figure 44, the MSC-S seizes a bearer termination towards the IMS
network by initiating a GCP Reserve IMS Connection Point procedure upon
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 71

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 Prepare 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.
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 procedures
is received, the MSC-S sends an INITIAL ADDRESS MESSAGE to the Neighboring
MSC-S applying backward bearer setup.
72 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

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

strmMode=SR)
Establish Bearer (CN Side, IP) ADD.rep (Ctx=3, T=T2)

+ Tunnel Information Down
+ Change Through Connection NOTIFY.req(Ctx=3,T=T2)
+ Tunnel Information Up NOTIFY.rep(Ctx=3,T=T2)
APM
MOD.req
(Ctx=2, T=T3)
Tunnel
Information MOD.rep
(Ctx=2, T=T3)
Down
Nb UP Init
NOTIFY.req
(Ctx=2,T=T3)
Tunnel
NOTIFY.rep
Information (Ctx=2,T=T3)
Up
APM
Tunnel MOD.req (Ctx=3, T=T2)
Information
Nb UP Init Ack Down
MOD.rep (Ctx=3, T=T2)
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 45 Bearer Seizures for Active or Held Call, Part 2
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 73

Note: For active and held conference calls the same handling applies as for
active and held calls
As shown in Figure 45, 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
The MSC-S and the Neighboring MSC-S continue with the establishment of the
bearer between MGW1 and MGW2.
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 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.
74 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Through Connection of Active Call and Active Conference Call
SIP MAP Neighboring BSSMAP Target

IMS MSC-S
BICC MSC-S BSC
GCP GCP
MGW1 MGW2
INVITE
200 OKINVITE
MOD.req
(Ctx=2,T=T4,)
Configure IMS MOD.rep
Resources (Ctx=2,T=T4)
User Plane Backward

Through Connected
ACK
HANDOVER
DETECT
PROCESS
ACCESS
SIGNALLING
ANM
MOD.req(Ctx=2,
T=T3,strmMode=SR)
Change Through MOD.rep
Connection (Ctx=2,T=T3)
User Plane Bothway HANDOVER

Through Connected COMPLETE
on All Call Legs
SEND END
SIGNAL
Figure 46 Through Connection of Active Call and Active Conference Call
As shown in Figure 46, when the SIP 200 OK INVITE request is received in the MSC-S
, as answer to the previously sent SIP INVITE request, the MSC-S configures the
bearer termination towards the IMS network, based on the data received in the
SIP 200 OK INVITE request, by initiating a GCP Configure IMS Resources procedure.
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
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 75

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 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 SEND END SIGNAL
message are received.
Through Connection of Held Call and Held Conference Call
Figure 47 Through Connection of Held Call and Held Conference Call
As shown in Figure 47, when the SIP 200 OK INVITE request is received in the
MSC-S, as answer to the previously sent SIP INVITE request, the MSC-S changes
the stream mode of the bearer termination in MGW1 towards MGW2 by initiating
76 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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 request, by initiating a GCP Configure IMS
Resources procedure.
3.2.17 SRVCC Procedure for Emergency Call

The subsections below contain the description of the SRVCC Procedure for
emergency calls that differ from the corresponding description when handling
non-emergency calls in active state.
The optional procedure Location Continuity, described in Section 3.2.17.8 on page

79, is applicable only to an emergency call.
3.2.17.1 Initiation of SRVCC
Apart from the differences specified below, the SRVCC Procedure is initiated as
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.
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,
— 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.
MSC-S ignores ARP IE possibly received in the Sv-Interface protocol SRVCC PS

TO CS REQUEST message from MME for an emergency call subject to SRVCC
Procedure.
3.2.17.2 Handover Request
Apart from the differences specified below, the handover is requested as described
in Section 3.2.2 on page 10.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 77

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, 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’’.
— Priority parameter is not set based on possibly received ARP IE.
3.2.17.3 Response to MME
The MSC-S responds to the MME immediately after receiving the BSSMAP
HANDOVER REQUEST ACKNOWLEDGE.
The response to MME is sent as described in Section 3.2.3 on page 14 with

the exception that Robust SRVCC configuration option is not applicable for
emergency calls.
3.2.17.4 IMS Session Transfer
Apart from the differences specified below, the emergency session transfer is
performed as described in Section 3.2.4 on page 17 and Page 20.
MSC-S initiates the session transfer towards the IMS network based on the
‘‘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 from AXE Parameter
Set GSMMSSC.
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 to Access
Transfer Control Function (ATCF), which is the route in case of a non-emergency
call.
The content of the SIP INVITE request has the following differences compared to
the content described in Table 7:
— 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.
— P-Asserted-Identity header:
78 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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, see
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’’.
— Request-URI parameter:
The E-STN-SR is used to populate this parameter.
— Resource-Priority header is not sent due to reception of ARP IE.
If a SIP 488 NOT ACCEPTABLE HERE message that contains SDP body is received
as response to the SIP INVITE request, 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, see Function Specification Session Initiation Protocol.
3.2.17.5 SRVCC Complete Notification to MME
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 28.
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 COMPLETE
NOTIFICATION message does not contain an IMSI.
3.2.17.6 TMSI Allocation
Apart from the differences specified below, TMSI allocation is performed as

If IMSI is not provided by the MME in the Sv-Interface protocol SRVCC PS TO CS

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

HLR is not performed.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 79

3.2.17.8 Location Continuity
As shown in Figure 48, 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.
MAP BSSMAP
Target
GMLC MSC-S
BSC
HANDOVER
COMPLETE
SUBSCRIBER
LOCATION REPORT
Figure 48 Location Continuity Procedure
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.
Table 16 MAP SUBSCRIBER LOCATION REPORT

Parameters of MAP SUBSCRIBER Information Included in the MAP
LOCATION REPORT Message SUBSCRIBER LOCATION REPORT
Message
Location Services (LCS) event type ‘‘Emergency call handover’’
(lcs-Event)
LCS client type (lcsClientType), ‘‘Emergency services’’
which is included in LCS client ID
(1)
(lcs-ClientID)
LCS location info (lcsLocationInfo) Network Node-Number containing the
MSC number
(2)
MSISDN • C-MSISDN
• non-dialable callback number, which
is a special number that consists of
a configurable prefix comprising 3
digits, and the last 7 digits of the
(3)
provided IMEI
(2)
IMSI IMSI
80 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Parameters of MAP SUBSCRIBER Information Included in the MAP

LOCATION REPORT Message SUBSCRIBER LOCATION REPORT
Message
IMEI IMEI
Target Serving Node for Handover MSC number
(targetServingNodeForHandover)
(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 from AXE Parameter Set GSMLSSC.
For a detailed description of the data received from the MME, see the Function
Specification Sv-Interface, General Aspects, Message Formats and Coding for
SRVCC.
As shown in Figure 49, 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.
Figure 49 Location Continuity Procedure, Neighboring MSC-S Scenario
3.2.17.9 Cancellation of SRVCC Procedure
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.13 on page 46.
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 Sv-Interface protocol SRVCC
PS TO CS CANCEL ACKNOWLEDGE message with cause code ‘‘Request rejected’’.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 81

3.2.17.10 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.14 on page 47.
3.2.17.11 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.15 on page 48.
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.15 on page 48.
Table 17 Cause Codes and SRVCC Reject Causes indicated in the Sv-Interface protocol SRVCC
PS TO CS RESPONSE Message
E-STN-SR is not configured. Service not supported Permanent Session Leg
Establishment error
If IMSI is not provided by Service not supported Unspecified
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
exchange parameter.
Rejection after Complete Notification with No Further Indication to MME

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.17.12 Interactions between MSC-S and MGW
Apart from the differences specified below, the MSC-S and MGW interact as
described in Section 3.2.16 on page 51 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
82 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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.
3.3.1 Announcement at Call Disconnection
Announcement at Call Disconnection is not supported for calls that are subject
to SRVCC Procedure.
For more information on the Announcement at Call Disconnection function, see

Function Specification Announcement at Call Disconnection in MSC/VLR Server.
3.3.2 Announcement on No Reply or User Determined User Busy
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.
3.3.3 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.
The same handling applies if a Location Update request is received over Gs or

SGs interface.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 83

The BSSMAP COMPLETE LAYER 3 INFORMATION message can carry CM Service

Request, Location Updating Request or IMSI Detach Indication.
3.3.4 BSC Recording Initiation in MSC/VLR Server
BSC Recording Initiation is not supported for calls that are subject to SRVCC
Procedure.
For more information on the BSC Recording Initiation function, see Function
Specification BSC Recording Initiation in MSC/VLR Server.
3.3.5 BSS Trace Invocation in MSC/VLR Server
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.
For more information on the BSS Trace Invocation function, see Function
Specification BSS Trace Invocation in MSC/VLR Server.
3.3.6 Call Forwarding on No Reply

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.
3.3.7 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.8 Call Hold

DTAP HOLD
During SRVCC procedure, if MSC-S receives a DTAP HOLD request from the served
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 from
UE but before it receives a SIP 200 OK INVITE from IMS, the request is rejected
with cause code ‘‘temporary failure’’.
84 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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:
— Cause code ‘‘facility rejected’’ if the subscriber was registered in VLR and was
subscribed to the supplementary service (SS) before the SRVCC Procedure,
— 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.
If none of the above mentioned cases applies, DTAP HOLD request received during
or after SRVCC procedure is handled as described in Function Specification Call
Hold in MSC/VLR Server.
Note: No call hold announcement or hold tone is played from MSC-S towards
IMS on the call leg controlled by the Mw interface.
When the MSC-S receives a hold request from the IMS for the served 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.
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 the served 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 SS before the SRVCC Procedure,
— 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 to be subscribed with

Call Hold SS, since the session is already on hold when the user was in
PS domain.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 85

In case of alternation between two parallel calls, where one of the calls was
subject to SRVCC Procedure with priority handling based on ARP IE, no Subsequent
Assignment is initiated at call hold retrieval of a call if the two calls have the same
granted eMLPP priority level value which results that Priority Information (Priority
Level, PVI, PCI, QAI) for former active call remains applicable.
For details of setting the granted eMLPP priority level and Priority Information
for SRVCC with priority handling based on ARP IE, see Section 3.2.4 on page 17
and Section 3.2.2 on page 10. Otherwise, see Function Specification Enhanced
Multi-Level Precedence and Pre-emption Service in MSC Server or Roaming
Priority Handling in MSC Server.
For more information on the Call Hold function, see Function Specification Call
Hold in MSC/VLR Server.
3.3.9 Call Re-establishment
If a BSSMAP CLEAR REQUEST or a DTAP CM RE-ESTABLISHMENT REQUEST

message is received during an ongoing SRVCC procedure, MSC-S does not initiate
Call Re-establishment procedure.
Instead, if Sv-Interface protocol SRVCC PS TO CS RESPONSE message has not

been sent yet, MSC-S sends Sv-Interface protocol SRVCC PS TO CS RESPONSE
with cause code ‘‘request rejected’’, aborts the SRVCC procedure, and disconnects
the session transfer call leg if SIP INVITE has already been sent. In case the
Sv-Interface protocol SRVCC PS TO CS RESPONSE message was already sent,
MSC-S aborts the SRVCC procedure and disconnects the session transfer call
leg if INVITE has already been sent.
In case a DTAP CM RE-ESTABLISHMENT REQUEST message is received during an

ongoing SRVCC procedure, it is rejected as described in Function Specification
Call Re-establishment.
After the SRVCC procedure is finished, if a BSSMAP CLEAR REQUEST or a

DTAP CM RE-ESTABLISHMENT REQUEST message is received, MSC-S initiates
Call Re-establishment procedure as described in Function Specification Call
Re-establishment given that the call is either an active or held call or an active or
held conference call. In the specific case of a conference call, MSC-S proceeds with
Call Re-establishment procedure if no disconnection event has been received for
any of the conference participants. If a disconnection event has been received and
is ongoing for at least one of the conference participants then MSC-S proceeds
with conference call disconnection without initiating Call Re-establishment
procedure. In case a DTAP CM RE-ESTABLISHMENT REQUEST message has been
received, it is rejected as described in Function Specification Call Re-establishment.
If a SIP INFO message with conference call information is received while a Call
Re-establishment procedure is ongoing, the Call Re-establishment procedure
continues unaffected and the SIP INFO message is processes as described in
Section 3.2.12 on page 44
86 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
After the SRVCC procedure is finished for a Neighboring MSC-S scenario, if a

BSSMAP CLEAR REQUEST message is received in the Neighboring MSC-S, the
MSC-S does not proceed with the Call Re-establishment procedure and the call is
released. If a DTAP CM RE-ESTABLISHMENT REQUEST message is received either
in the MSC-S or in the Neighboring MSC-S, the message is rejected as described in
Function Specification Call Re-establishment.
Timer T322 of the STATUS ENQUIRY procedure is suspended during Call

Re-establishment procedure and it is resumed when the procedure is finished. If a
DTAP STATUS message as answer to a DTAP STATUS ENQUIRY message is received
after T322 timer has started running again, MSC-S proceeds according to Table 12.
Upon T322 timer expiry and given that Call Re-establishment procedure is finished
successfully, if the MSC-S state is ‘‘Connect Indication’’ it is assumed that the
DTAP STATUS message as answer to DTAP STATUS ENQUIRY message could not
be received in MSC-S due to the occurrence of a radio link failure as specified
in Function Specification Call Re-establishment. In this case, state alignment
due to Call Re-establishment function takes place and the MSC-S state changes
to ‘‘Active’’ . Moreover, there is no retransmission of DTAP STATUS ENQUIRY
message, even if it is configured to be enabled.
Priority level information sent in ASSIGNMENT REQUEST during Call

Re-establishment procedure is mapped from ARP IE on the same way as priority
information sent in HANDOVER REQUEST that is described in Section 3.2.4 on page
17 if ARP IE has been received in SRVCC PS TO CS REQUEST.
For more information on the Call Re-establishment function see Function

Specification Call Re-establishment.
3.3.10 Call Teardown

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 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.
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.
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 from
AXE Parameter Set GSM1APTC with the exception of emergency calls.
For more information on the ‘‘Call Teardown’’ function see Function Specification
Call Teardown in MSC/VLR.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 87

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 see Function Specification
Call Waiting in MSC/VLR Server.
3.3.12 CAMEL Based IMS Centralized Services

For the case the served subscriber is an ICS user and CAMEL based architecture is
applied for the ICS calls, 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 request.
3.3.13 Channel Allocation Priority Level
In case an SRVCC PS TO CS REQUEST is received, and ‘‘Channel Allocation Priority

Level (CAPL)’’Channel Allocation Priority Level (CAPL)CAPL function is active in
MSC-S, then priority information is not sent towards target BSC.
For more information on the CAPL function, see Function Specification Handling
of Channel Allocation Priority Level in MSC/VLR.
3.3.14 Charging Audit
Charging Audit is not supported for calls that are subject to SRVCC Procedure.
For more information on the ‘‘Charging Audit’’ function, see Function Specification
Charging Audit.
3.3.15 Connected Line Identification Services

The Connected Line Identification Presentation (COLP) is supported for
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.
88 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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 request from IMS for an active call or an originating call in
alerting or pre-alerting state, the request is rejected with cause code ‘‘temporary
failure’’.
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 ‘‘temporary failure’’.
If a DTAP STOP DTMF request message is received from the UE while waiting for
the SIP 200 OK INVITE request from IMS during an ongoing SRVCC Procedure,
the request is acknowledged.
For more information on the ‘‘DTMF Support’’ function, see Function Specification
DTMF Support.
3.3.17 Enhanced MT Call Handling

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 case the Sv-Interface protocol SRVCC PS TO CS REQUEST message is 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, see Function
Specification Enhanced MT Call Handling in MSC.
3.3.18 Enhanced Multi-Level Precedence and Pre-emption
If ARP IE is not received in Sv-interface protocol SRVCC PS TO CS REQUEST

message but ‘‘EMLPP’’ feature is enabled then call can still be treated with
priority, as described in Function Specification Enhanced Multi-Level Precedence
and Pre-emption Service in MSC Server.
3.3.19 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’’.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 89

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 transferred is created due to the SRVCC Procedure.
3.3.20 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 50, when target cell is served by the Neighboring MSC-S
location number is inherited in the following order:
— The Location Number is derived from the one connected to the Area Cluster
administered for the MME.
— 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.
Own MSC-S
SAI-Level Area Cluster for MME
Figure 50 Inheritance Principle Used in SRVCC Procedure when Target Cell

Belongs to Neighboring MSC-S
3.3.21 I2 Based IMS Centralized Services for Originating Calls

For the case the served subscriber is an ICS user and ICS I2 network solution
applies, after the SRVCC procedure is finished, new originated calls (enquiry
calls) from the served subscriber are handled according to the ICS I2 network
solution specified in Function Specification I2 Based IMS Centralized Services for
Originating Calls.
3.3.22 Immediate Service Termination

For calls subject to SRVCC Procedure, Periodic Reporting Mechanism is not
supported.
In case an Immediate Service Termination (IST) message (IST command) is

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

indicated IMSI.
90 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
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, see

Function Specification Immediate Service Termination in GMSC and MSC/VLR
Server.
3.3.23 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 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, see Function
Specification IMSI Attach and Detach in MSC/VLR.
3.3.24 Location Services in MSC-S
Mobile Terminating Location Request

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 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 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.
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
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.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 91

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 see Function Specification Location Services in MSC Server.
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.
Successful completion of the Handover is considered as an additional MS activity

becoming the subscriber MS reachable. Further actions are as described at section
‘‘Detection of “MS available” Event’’ in Function Specification Deferred Mobile
Terminating Location Request in MSC/VLR Server.
If notification has to be performed, the request is rejected with 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.
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.
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.
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, see Function

Specification Location Services in MSC Server.
92 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
3.3.25 MSC in Pool
MSC Pool Redistribution
MSC node level redistribution, RAN node level redistribution, Subscriber level
redistribution
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 when the third phase of redistribution is applied, TMSI generated during
SRVCC Procedure contains Null NRI and an own NB-LAI. In any other case, when
the MSC-S interworks in Pool environment, the TMSI generated during SRVCC
Procedure contains Null-NRI or own- 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.
MSC Controlled Subscriber Redistribution

In case MSC-S interworks in pool environment and the subscriber is registered in
VLR during reception of the request for SRVCC procedure and MSC controlled
subscriber redistribution session is ongoing with 100% (full move) or less than
100% (partial move) of subscribers to be redistributed, TMSI included in the TMSI
REALLOCATION COMMAND generated during SRVCC procedure contains the target
NRI based on Redistribution Factor Table in the NRI field and the own NB LAI.
The same handling applies if the subscriber is not registered in VLR during
reception of the request for SRVCC procedure and MSC controlled subscriber
redistribution session is ongoing with 100% (full move). If the subscriber is not
registered in VLR during reception of the request for SRVCC procedure and
MSC controlled subscriber redistribution session is ongoing with less than 100%
(partial move) of subscribers to be redistributed, TMSI included in the TMSI
REALLOCATION COMMAND generated during SRVCC procedure contains the target
NRI value with own or null-NRI, based on exchange data for preferred NRI option
on a per Area Cluster (MME) basis, in the NRI field and the own NB-LAI.
For more information on the ‘‘MSC in Pool’’ function, see Function Specification
MSC/VLR Server in MSC Pool.
3.3.26 Multi Party Supplementary Service

During SRVCC procedure, if MSC-S receives a DTAP FACILITY request from the
served UE related to multi-party supplementary service before the MSC-S state
is known, that is before the reception of SIP INFO, SIP 200 OKINVITE or DTAP
CONNECT message, 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 Failure’’ is used.
In case a DTAP FACILITY message related to multi-party supplementary service

is received for a transferred held or active conference call after the SRVCC
transfer, the request is handled according to Function Specification Support of
IMS Conference Control after SRVCC transfer.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 93

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 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
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.
If none of the above mentioned cases applies, any DTAP FACILITY request related
to multi party supplementary services received during or after SRVCC procedure is
handled as described in 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.
When a new multi-party call is built, the highest granted eMLPP priority level of
all calls of the multi-party call is taken as granted eMLPP priority level of the
multi-party call. The Priority Information (Priority Level, QAI, PVI and PCI) is used
for the traffic channel assignment and associated to the multi-party call.
For details of setting the granted eMLPP priority level and Priority Information
for SRVCC with priority handling based on ARP IE see Section 3.2.4 on page 17
and Section 3.2.2 on page 10 respectively. Otherwise see Function Specifications
Enhanced Multi-Level Precedence and Pre-emption Service in MSC Server or
Roaming Priority Handling in MSC Server.
When a new multi party call is built, where one of the calls was subject to SRVCC
with priority handling based on ARP IE, no Subsequent Assignment is initiated if
the two calls have the same granted eMLPP priority level. This results that Priority
Information of the former active call remains applicable and it is associated with
the multi-party call.
When adding a new single call with higher granted eMLPP priority level, granted
eMLPP priority level of the multi-party call is set to the granted eMLPP priority
level of the single call.
In case a new call is added to a multi-party call whose granted eMLPP priority
level is set based on ARP IE, no Subsequent Assignment is initiated if the new call
has the same granted eMLPP priority level. This results that Priority Information
of the former active call (either multi-party or single call) remains applicable and it
is associated with the multi-party call.
In case of alternation between a single call and a multi-party call whose granted
eMLPP priority level is set based on ARP IE, no Subsequent Assignment is initiated
at retrieval of single or multi-party call if the two calls have the same granted
eMLPP priority level which results that Priority Information of the former active
call remains applicable.
94 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
For more information on the ‘‘Multi Party Supplementary Service’’ function, see
Function Specification Multi-Party Supplementary Service in MSC/VLR Server.
3.3.27 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’’ .
For more information on the ‘‘Network Initiated Unstructured Supplementary

Service Data Message’’ function, see Function Specification Handling of
Unstructured Supplementary Service Data Procedures in MSC/VLR Server.
3.3.28 NSS based Location Services

If MSC-S receives an Network Switching System (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 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, respectively.
If the Handover is not completed successfully, the request is rejected and error
‘‘Position Failure’’ is returned to the GMLC.
If MSC-S receives an NSS based Location Request for a subscriber that is not
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.
For more information on the ‘‘NSS based location services’’ function, see Function
Specification NSS Based Location Services in MSC/VLR Server.
3.3.29 Parallel Transactions during SRVCC Procedure for an Emergency Call
Location Services transaction

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 from AXE Parameter Set GSMMMSC, see Section 3.3.24 on page 91.
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’’.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 95

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’’.
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.33 on page 97. A PAP can enable establishment of SMS transactions
in parallel to an existing emergency call.
For more information on the handling of parallel transactions, see Function

Specification Handling of Parallel Transactions in MSC/VLR Server.
3.3.30 Roaming Priority Handling

If ARP IE is not received in Sv-interface protocol SRVCC PS TO CS REQUEST
message, but ‘‘Roaming Priority Handling’’ feature is active then call can still be
treated with priority, as described in Function Specification Roaming Priority
Handling in MSC Server.
3.3.31 Service Based Handover

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 analysis and IMSI
number series analysis. For more information on Service Based Handover, see
Function Specification Service Based Handover in MSC/VLR Server.
3.3.32 SMS over SGs-Interface and LTE to CS Fallback

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 from AXE Parameter Set GSMMMSC.
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 disconnected, if SIP
INVITE has already been sent. The received message is processed as if SRVCC
96 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Function
Procedure has never occurred 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, see
Function Specification SGs-Interface for SGsAP Procedures.
3.3.33 Short Message Service, Mobile Originating, Mobile Terminating, Queuing

in MSC-S
Mobile Originating Short Message Service

When the MSC-S receives an Mobile Originating Short Message (MO-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.
When the MSC-S receives an MO-SMS from a subscriber that is involved in 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 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 MO-SMS from a subscriber that is involved in an

emergency call subject to an ongoing SRVCC Procedure, the MSC-S 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.
Mobile Terminating Short Message Service

When the MSC-S receives a Mobile Terminating Short Message (MT-SMS) for a
subscriber that is still involved in a non-emergency call subject to an ongoing
SRVCC Procedure and ‘‘SMS queuing’’ functionality is active, the SMS is queued
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 97

and is delivered after completion of the SRVCC Procedure and unqueuing timer
expiry.
When the MSC-S receives an 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 an 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.
— 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 Short
Message Service, Mobile Terminated, Queuing in MSC/VLR Server.
3.3.34 Single Personal Number at No Reply
MSC-S does not invoke service ‘‘Single Personal Number at No Reply’’, for a
terminating call in alerting state that is subject to SRVCC Procedure.
3.3.35 Wireless Priority Service (WPS)

For information on interaction with SRVCC with ARP based priority handling, see
Function SpecificationWireless Priority Service.
98 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Operational Conditions
4 Operational Conditions
4.1 Operation and Maintenance Reference Information

Input Elements
Table 18 AXE Parameters

LCSONEMERG
LOCANCTDSTATUSM
LTETOGSMSGSDTCH
NBLAC
NBMCC
NBMNC
NONDIALPREFIX
PLMNNBLAC
ROBUSTSRVCC
SRVCCEMERGBO
SRVCCSTAENQENBL
TMSILAIMSC
TMSIPAR
Table 19 Route Parameters

TRUSTPL
MIS2
RPHSNS
ETSPLS
PANI
PANIPRF
Table 20 Changeable Exchange Parameters

EMCNOIMSI
SSEM2
Table 21
(1)(2)(3)
Commands
MGAAI
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 99

(1)(2)(3)
Commands
MGAAC
MGAAE
MGAAP
MGEPC
MGEPP
MGESI
MGESE
MGESP
MGGMI
MGGME
MGGMP
MGAMC
MGAMP
(1) For the commands related to the administration of the MME and UDP port numbers, see
the Function Specification Generic Transport Function, Traffic, Administration and
Maintenance.
(2) For a detailed description of the Area Cluster Administration function, see the Function
Specification Area Cluster Administration in MSC/VLR Server.
(3) For a detailed description of the commands related to handling of Location Numbers, see the
Function Specification Handling of Location Numbers in MSC/VLR Server and GMSC
Server (GSM).
Table 22 Timers
T322 SRVCCSTAENQT322
TIMUGHOBASICM TIMUGHOBASICM
TIMUGHOINTRAM TIMUGHOINTRAM
Output Elements
Table 23
(1)
Printouts
EMERGENCY SESSION TRANSFER Answer Printout
NUMBER
MT GMLC ADDRESS DATA FOR SRVCC Answer Printout
MT AREA CLUSTER DATA Answer Printout
100 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

(1)
Printouts
MT EXCHANGE PROPERTY DATA Answer Printout
MT ALLOCATION RETENTION Answer Printout
PRIORITY MAPPING DATA
(1) For the printouts of Generic Transport related data see the Function Specification Generic
Transport Function, Traffic, Administration and Maintenance and for the printout of
Area Cluster Data, see the Function Specification Area Cluster Administration in MSC/VLR
Server.
4.2 Charging
For a detailed description of the general principles for charging, see 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.
The MSC-S generates a Mobile Originating (MO) Call Data Record (CDR) which is
identified as SRVCC specific based on the SRVCC indicator. Also MSC-S generates
a Handover Event Module. In the MO CDR, the following existing parameters are
populated with information derived from SRVCC:
— Originating Location Number (ITU) or Location number (ANSI) as explained

in Section 3.3.20 on page 90.
— 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

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

protocol SRVCC PS TO CS REQUEST message
MO CDR PARAMETER VALUE
(1)
Calling Party Number C-MSISDN
(2)
Called Party Number STN-SR
(3)
Calling Subscriber IMEI (ITU) MEI
IMEI (ANSI)
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 101

MO CDR PARAMETER VALUE

(3)
Calling Subscriber IMEISV MEI
(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 Table 25.
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
MME Identity
(1)
Originating call in alerting state SRVCC Indicator
(2)
SRVCC Alerting Indicator
MME Identity
(1)
Terminating call in alerting state SRVCC Indicator
(3)
SRVCC Alerting Indicator
MME Identity
(1)
Originating call in pre-alerting state SRVCC Indicator
SRVCC Originating Pre-alerting

Indicator
MME Identity
102 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

(1)
Active conference call SRVCC Indicator
SRVCC Conference Indicator
MME Identity
(1)
Held conference call SRVCC Indicator
SRVCC Call Hold Indicator
SRVCC Conference Indicator
MME Identity
(1) The value of parameter is E-UTRAN ‘‘0’’
(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
request 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.
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 request.
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 request from IMS if received after HANDOVER
COMPLETE, and the cause code that is sent in BSSMAP HANDOVER REQUEST
message towards target cell. Otherwise the time of reception of HANDOVER
COMPLETE is included.
For SRVCC with priority handling based on ARP IE, CDR parameter
eMLPPPriorityLevel contains the granted eMLPP priority level value. The
granted eMLPP priority level is set to the configured ARP eMLPP Priority Level
based on the received ARP Priority Level in ARP IE.
4.3 Capabilities
One SAI can be defined in an Area Cluster with connected MME-ID.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 103

One E-STN-SR can be configured in the MSC-S to support the emergency session
transfer towards IMS.
One GMLC address can be defined in the MSC-S to be used for the Location
Continuity Procedure.
104 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

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

Figure 51 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.
Note: If multiple curved dashed lines start from the same received message,
that message is the trigger for all connected messages. If multiple
curved dashed lines end on a message sent by the MSC-S, all connected
messages are conditions for that message to be sent.
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 105

Figure 51 Example Call Flow, Part 1
106 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Appendix 1 - Example Call Flow
Neighboring Target
MME Sv-Interface Protocol MSC-S MAP BICC BSSAP
MSC-S BSC
MAP
SIP GCP GCP
IMS MGW1 HLR MGW2
SRVCC ACM
PS TO CS
RESPONSE
INVITE
183 SESSION
PROGRESS
Configure
MOD.req&rep IMS Connection
Point (Ctx=2,T=T4)
PRACK
200 OKPRACK
INFO
200 OKINFO
Tunnel Information
MOD.req&rep Down (Ctx=2,T=T3)
Change IMS Through
MOD.req&rep Connection (Ctx=2,T=T4)
PROCESS HANDOVER
ACCESS DETECT
SIGNALLING
SRVCC ANM HANDOVER
PS TO CS SEND END COMPLETE
COMPLETE SIGNAL
NOTIFICATION
SRVCC PS TO CS
COMPLETE
ACKNOWLEDGE
CONNECT
... ... ... ... ... ... ... ...

Note: Based on a configuration option (see Section 3.2.3 on page 14) the
sending of SRVCC PS to CS RESPONSE can be delayed after the reception
of 200OK or INFO as response to the shown INVITE..
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 107

Neighboring Target
MME Sv-Interface Protocol MSC-S MAP BICC BSSAP
MSC-S BSC
MAP
SIP GCP GCP
IMS MGW1 HLR MGW2
PROCESS
ACCESS
SIGNALLING
FORWARD
ACCESS
SIGNALLING CONNECT
ACKNOWLEDGE
Change IMS Through
MOD.req&rep Connection (Ctx=2,T=T4)
INFO
200 OKINFO
200 OKINVITE
ACK
Configure
MOD.req&rep IMS Connection
Point (Ctx=2,T=T4)
FORWARD
ACCESS TMSI
SIGNALLING REALLOCATION
COMMAND
TMSI
REALLOCATION
SEND END COMPLETE
SIGNAL
UPDATE LOCATION
INSERT
SUBSCRIBER
DATA
INSERT
SUBSCRIBER
DATA RESULT
UPDATE
LOCATION
RESULT
108 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Glossary
Glossary
AMR-WB CO
Adaptive Multi-Rate Wideband Charging Origin
ANM COLP
Answer message Connected Line Identification Presentation
APM COLR
Application Transport Message Connected Line Identification Restriction
ARP CS
Allocation Retention Priority Circuit Switched
ATCF CTX
Access Transfer Control Function Context
BICC DNS
Bearer Independent Call Control Domain Name System
BO E-STN-SR
B-Number Origin Emergency Session Transfer Number for SRVCC
BSC EATF
Base Station Controller Emergency Access Transfer Function
BSSMAP EMLPP
Base Station Subsystem Mobile Application Enhanced Multi-Level Precedence and
Part Pre-emption
C-MSISDN EPC
Correlation MSISDN Evolved Packet Core
CAPL EPS
Channel Allocation Priority Level Evolved Packet System
CDR FQDN
Call Data Record Fully Qualified Domain Name
CGI GCP
Cell Global Identification Gateway Control Protocol
CM GMLC
Connection Management Gateway Mobile Location Center
CN GPRS
Core Network General Packet Radio Service
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 109

GSM ISUP
Global System for Mobile Communications ISDN User Part
GTP ITU
GPRS Tunneling Protocol Calling Subscriber IMEI
GTPv2-C LAC
(GTP) version 2 for Control plane Location Area Code
GW LAI
Gateway Location Area Identity
HLR LCS
Home Location Register Location Services
I2 LTE
I2 reference point Long Term Evolution
IAM MAP
Initial Address Message Mobile Application Part
ICID MAPV2
IMS Charging Identity MAP Version 2
ICS MAPV3
IMS Centralized Services MAP Version 3
ID MCC
Identity Mobile Country Code
IE MEI
Information Element Mobile Equipment Identity
IM-MGW MGCF
IP Multimedia Media Gateway Function Media Gateway Control Function
IMEI MGW
International Mobile Equipment Identity Media Gateway
IMEISV MME
IMEI including Software Version Mobility Management Entity
IMS MME-ID
Internet Protocol Multimedia Subsystem MME Identity
IMSI MNC
International Mobile Subscriber Identity Mobile Network Code
IP MO
Internet Protocol Mobile Originating
IST MO-LR
Immediate Service Termination Mobile Originating Location Request
110 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Glossary
MO-SMS PVI
Mobile Originating Short Message Pre-emption Vulnerability Indicator
MPTY QAI
Multiparty Queueing Allowed Indicator
MSC RAN
Mobile Switching Center Radio Access Network
MSC-S RNC
Mobile Switching Center Server Radio Network Controller
MSISDN RO
Mobile Subscriber ISDN Number Routing Origin
MT SA
Mobile Terminating Service Area
MT-LR SAI
Mobile Terminating Location Request Service Area Identity
MT-SMS SDP
Mobile Terminating Short Message Session Description Protocol
NAS SIM
Non-Access Stratum Subscriber Identity Module
NB-LAI SIP
Non-Broadcast Location Area Information Session Initiation Protocol
NRI SMS
Network Resource Identifier Short Message Service
NSS SRVCC
Network Switching System Single Radio Voice Call Continuity
OoBTC SS
Out of Band Transcoder Control Supplementary Service
PAP STN-SR
Permanent Application Parameter Session Transfer Number for SRVCC
PCI T
Pre-emption Capability Indicator Termination
PDN-GW TEID
Packet Data Network Gateway Tunnel Endpoint Identifier
PLMN TEID-C
Public Land Mobile Network Tunnel Endpoint Identifier for Control Plane
PS TI
Packet Switched Transaction Identifier
58/155 17-CSA 121 01/14 Uen A | 2019-06-19 111

TMSI
Temporary Mobile Subscriber Identity
TrFO
Transcoder Free Operation
UDP
User Datagram Protocol
UDUB
User Determined User Busy
UE
User Equipment
UICC
Universal Integrated Circuit Card
URI
Uniform Resource Identifier
USSD
Unstructured Supplementary Service Data
WCDMA
Wideband Code Division Multiple Access
WPS
Wireless Priority Service
112 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Reference List
Reference List
[1] A-Interface, Section H: Base Station System Management Application Part,

BSSMAP Message Formats and Coding
[2] A/Iu-Interface, Section I: DTAP And RANAP/NAS, Message Formats And

Coding For Mobility Management
[3] A/Iu-Interface, Section J: DTAP and RANAP/NAS, Message Formats and

Coding for Short Message Service
[4] A/Iu-Interface, Section K: DTAP and RANAP/NAS, Message Formats and

Coding for Call Control and Call Related Supplementary Service Procedures
[5] A/Iu-Interface, Section L: DTAP and RANAP Message Formats and Coding
for Call Independent Supplementary Service Procedures
[6] Announcement at Call Disconnection in MSC/VLR Server

[7] Area Cluster Administration in MSC/VLR Server

[8] BSC Recording Initiation in MSC/VLR Server

[9] BSS Trace Invocation in MSC/VLR Server

[10] Call Hold in MSC/VLR Server

[11] Call Re-establishment

[12] Call Teardown in MSC/VLR

[13] Call Waiting in MSC/VLR Server

[14] CAMEL Based IMS Centralized Services

58/155 17-CSA 121 01/14 Uen A | 2019-06-19 113

[15] Charging Audit

[16] Charging in a PLMN

[17] Deferred Mobile Terminating Location Request in MSC/VLR Server

[18] DTMF Support

[19] Emergency Call in MSC/VLR Server (Japan)

[20] Enhanced MT Call Handling in MSC

[21] Enhanced Multi-Level Precedence and Pre-emption Service in MSC Server

[22] Generic Transport Function, Traffic, Administration and Maintenance

[23] Glossary of Terms and Acronyms

GLOSSARY
[24] GTPv2-C, General Aspects, Formats and Codes

[25] GTP-C, Signaling Transport

[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] I2 Based IMS Centralized Services for Originating Calls

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

114 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Reference List
[32] IMSI Attach and Detach in MSC/VLR

[33] Inter-MSC Handover/Relocation to MSC Pool

[34] Interworking with IMS Multimedia Telephony

[35] List of Cause Code and Location Information Mappings

APPLICATION INFORMATION
[36] Location Services in MSC Server

[37] Location Updating in MSC/VLR Server

[38] LTE to WCDMA Handover (SRVCC)

[39] Media Gateway Selection in MSC Server, GMSC Server and TSC Server
[40] Mobile Subscriber Related Security Functions in MSC/VLR Server

[41] MSC Server Interworking with External Networks Using SIP and SIP with
Encapsulated ISUP
[42] MSC/VLR Server in MSC Pool

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

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

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

[47] Roaming Priority Handling in MSC Server

[48] Service Based Handover in MSC/VLR Server

58/155 17-CSA 121 01/14 Uen A | 2019-06-19 115

[49] Session Description Protocol

[50] Session Initiation Protocol

[51] SGs-Interface for SGsAP Procedures

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

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

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

Server
[56] Signalling System No.7, Mobile Application Part Version 3 for Inter-MSC
Handover in MSC/VLR Server
[57] Support of AMR-WB Speech Codec

[58] Support of IMS Conference Control after SRVCC transfer

[59] Sv-Interface Configuration and Enabling of Single Radio Voice Call

Continuity
USER GUIDE
[60] Sv-Interface, General Aspects, Message Formats and Coding for SRVCC
[61] TrFO Interworking with SIP and SIP-I

[62] UMTS to GSM Handover in MSC/VLR Server

[63] Wireless Priority Service

116 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Location Update GSM

Uploaded by

Copyright:

Available Formats

Location Update GSM

Uploaded by

Document Information

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

Location Update GSM

Uploaded by

Copyright:

Available Formats

LTE to GSM Handover (SRVCC)

58/155 17-CSA 121 01/14 Uen A

58/155 17-CSA 121 01/14 Uen A | 2019-06-19

58/155 17-CSA 121 01/14 Uen A | 2019-06-19

3.3.19 Explicit Call Transfer 89

5 Appendix 1 - Example Call Flow 105

Reference List 113

58/155 17-CSA 121 01/14 Uen A | 2019-06-19

Changes in MSC-S 18.3

This document has been revised as follows:

Changes in MSC-S 18A

This document has been revised as follows:

— Interaction with ‘‘MSC Controlled Subscriber Redistribution’’ added.

• IMS Centralized Services (ICS)

Changes in MSC-S 17A

This document has been revised as follows:

58/155 17-CSA 121 01/14 Uen A | 2019-06-19 1

— Interaction with Function Specification Support of IMS Conference

Changes in MSC-S 16A

2 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

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

— Active call (including emergency calls)

— Active conference call

— Held conference call

— Originating call in alerting state

— Terminating call in alerting state

— Originating call in pre-alerting state

Based on Robust SRVCC configuration option the MSC-S supports handover of

58/155 17-CSA 121 01/14 Uen A | 2019-06-19 3

— The feature ‘‘Support of Interworking with MMTel/IMS’’ is available and

LTE to GSM Handover (SRVCC) Documentation Overview

4 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

The MSC-S initiates an Intra-MSC Handover or Inter-MSC Handover, respectively.

58/155 17-CSA 121 01/14 Uen A | 2019-06-19 5

Table 2 Overview of Interfaces and Protocols

6 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

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

In the context of this document, the term:

3.2 Traffic Handling

58/155 17-CSA 121 01/14 Uen A | 2019-06-19 7

Figure 3 General Flow of SRVCC Procedure

8 58/155 17-CSA 121 01/14 Uen A | 2019-06-19

The SRVCC Procedure consists of the following steps:

— Initiation of SRVCC, see Section 3.2.1 on page 10

— Handover Request, see Section 3.2.2 on page 10

— Response to MME, see Section 3.2.3 on page 14

— IMS Session Transfer, see Section 3.2.4 on page 17

— Handover Completion, see Section 3.2.5 on page 26

— SRVCC Complete Notification to MME, see Section 3.2.6 on page 28

— TMSI Allocation (conditional), see Section 3.2.7 on page 30

— Location Update towards HLR (conditional), see Section 3.2.8 on page 33

— Alerting for originating call in pre-alerting state (conditional), see Section

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

— Location Continuity (conditional), Section 3.2.17.8 on page 79

— Status Enquiry Procedure, see Section 3.2.9 on page 34

In addition, dedicated sections describe the followings:

58/155 17-CSA 121 01/14 Uen A | 2019-06-19 9

— Rejection of Requests for SRVCC Procedure by MSC-S, see Section 3.2.15

3.2.1 Initiation of SRVCC

MME Sv-Interface Protocol MSC-S