Commercial in confidence

DESCRIPTION 1 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

IMS Call Flow

 Commercial in confidence
DESCRIPTION 2 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

IMS Call Flow

1 Introduction ....................................................................................... 3
2 Survey of Included Functions ............................................................ 3
2.1 Introduction ....................................................................................... 3
2.1.1 ICS call origination............................................................................. 3
2.1.2 ICS call termination ........................................................................... 4
2.2 System Overview .............................................................................. 4
2.2.1 ICS with MSC without ICS support .................................................... 4
2.2.2 Service Domain Selection (SDS) ....................................................... 7
3 ICS Detailed Descriptions .................................................................. 8
3.1 ICS Call Origination ........................................................................... 8
3.1.1 Functional Description ....................................................................... 8
3.1.2 Main Scenarios.................................................................................. 8
3.2 ICS Call Termination ....................................................................... 10
3.2.1 Functional Description ..................................................................... 10
3.2.2 Main Scenarios................................................................................ 10
3.3 Data model ...................................................................................... 15
3.3.1 Non ICS enhanced MSC ................................................................. 15
3.3.2 IMS Routing Number (IMRN) ........................................................... 15
4 SRVCC Detailed Descriptions ......................................................... 16
4.1 SRVCC Access Transfer ................................................................. 16
4.1.1 Functional Description ..................................................................... 16
4.1.2 Main Scenarios................................................................................ 16
4.2 SRVCC without ICS......................................................................... 38
4.3 SRVCC support by components external to IMS ............................. 38
 Commercial in confidence
DESCRIPTION 3 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

1 Introduction

2 Survey of Included Functions

2.1 Introduction

2.1.1 ICS call origination

The overall architecture for an originating call with ICS is shown in Figure 1.

O-SDS
CS performs
O-ADS is
O-SDS
performed by UE
Call routed to IMS
CS via I2 or via ISUP
Access CS Core
O-ADS

PS IMS
Access Core
Terminating
Network

Figure 1 SDS and ADS during originating call

The UE determines the access network to use for the call (Originating Access Domain
Selection (O-ADS)). O-ADS is not described in this document as it is performed by the UE. O-
ADS is described in 3GPP TS 23.221.

If the UE uses the CS access network, the CS network must identify that the user is an ICS
user and CS originating services must not be invoked, and the call shall be routed to IMS for
originating services (O-SDS).
 Commercial in confidence
DESCRIPTION 4 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

2.1.2 ICS call termination

Slide title
The overall
minimum
Terminating call
32 ptarchitecture for a terminating call with ICS is shown in Figure 2.
(32 pt makes 2 rows

T-SDS is performed in CS Network.

Text and bullet level 1
minimum 24 pt Call routed IMS

Bullets level 2-5 T-SDS

minimum 20 pt

!"#$%&'()*+,-
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRST
UVWXYZ[\]^_`abcdefghijklmnopqrstuvwxy
z{|}~¡¢£¤¥¦§¨©ª«¬®¯°±²³´¶·¸¹º»¼½ÀÁÂÃÄÅÆÇÈËÌÍ
CS CS CS
ÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñ
òóôõö÷øùúûüýþÿĀāĂăąĆćĊċČĎďĐđĒĖėĘęĚě
ĞğĠġĢģĪīĮįİıĶķĹĺĻļĽľŁłŃńŅņŇňŌŐőŒœŔŕŖŗŘřŚśŞş
ŠšŢţŤťŪūŮůŰűŲųŴŵŶŷŸŹźŻżŽžƒȘșˆˇ˘˙˚˛˜˝ẀẁẃẄẅ
Core Access
Ỳỳ–—‘’‚“”„†‡•…‰‹›⁄€™−≤≥fifl
ĀĀĂĂĄĄĆĆĊĊČČĎĎĐĐĒĒĖĖĘĘĚĚĞĞĠĠĢĢĪĪĮĮİĶ
ĶĹĹĻĻĽĽŃŃŅŅŇŇŌŌŐŐŔŔŖŖŘŘŚŚŞŞŢŢŤŤŪŪŮŮ
ŰŰŲŲŴŴŶŶŹŹŻŻȘș
ΆΈΉΊΌΎΏΐΑΒΓΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΪΫΆΈΉΊ
ΰαβγδεζηθικλνξορςΣΤΥΦΧΨΩΪΫΌΎΏ
ЁЂЃЄЅІЇЈЉЊЋЌЎЏАБВГДЕЖЗИЙКЛМНОПРСТУФ
ХЦЧШЩЪЫЬЭЮЯАБВГДЕЖЗИЙКЛМНОПРСТУФХ
ЦЧШЩЪЫЬЭЮЯЁЂЃЄЅІЇЈЉЊЋЌЎЏѢѢѲѲѴѴҐҐә T-ADS
ǽẀẁẂẃẄẅỲỳ№

IMS
IMS PS
Core Access

T-ADS is performed in IMS Network.

Call routed to CS if UE is connected via CS.

Do not add objects or

text in the footer area
Figure 2 SDS and ADS during terminating call

A terminating call delivered from the originating network can be routed from IMS or CS directly
into the terminating IMS network1 or into the terminating CS network. A call routed into the
terminating CS network must be rerouted to IMS; the terminating CS network performs T-SDS
to identify that the call must be routed to IMS.

3GPP TS 23.292 Release 10 describes a number of mechanisms how this can be achieved.
The choice of solution depends on the capabilities and requirements of the network.

During the call the network has to determine the access network(s) the call shall be delivered
to. This process is called T-ADS.

2.2 System Overview

2.2.1 ICS with MSC without ICS support

When the MSC does not support ICS, the MSC communicates with IMS via an MGCF. The
MGCF converts the ISUP signaling to SIP and vice versa. MGCF has an Mg interface towards
the IMS core (I-CSCF and S-CSCF).

MSC has a CAPv2 interface towards an SCP in SCC AS to retrieve routing information for the
call.

1Whether or not an terminating call from the originating IMS and/or CS are routed to the terminating IMS or CS
network depends on the configurations, policies and agreements between the originating and terminating network.
 Commercial in confidence
DESCRIPTION 5 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

The UE should have a connection towards an Aggregation Proxy (AP) in IMS using the Ut
interface for self-administration of IMS services. This is a data connection, therefore the MSC
is not involved.

2.2.1.1 ICS with MSC without ICS support, Originating calls

The subscriber data in the HLR contains originating CAMEL subscription information (O-CSI)
which indicates MSC to trigger the invocation of the SCP in SCC AS via the CAPv2 interface.
The SCC AS replaces the B number with an IMS routing number (IMRN) from a pool of
available numbers; SCC AS stores a mapping from the assigned IMRN to the B number and
other additional data as A number, privacy and location; SCC AS replies back to the MSC.
The IMRN is used by the MSC for routing the call towards IMS via an MGCF.

The user profile also indicates that originating CS services shall not be performed by MSC, as
originating services will be performed by IMS.

In IMS, the IMRN is used as a PSI, and it is used to route towards the SCC AS/SCP which
assigned the IMRN. This SCC AS generates an originating INVITE based on the incoming
INVITE; the B-number stored when the IMRN was assigned is used as Request-URI for the
new originating INVITE; other information stored when IMRN was assigned is also included in
the INVITE. SCC AS sends the new INVITE to the S-CSCF.

The S-CSCF retrieves the user profile for A subscriber and invokes the AS according to the
iFC. The SCC AS is the first AS which is invoked for originating calls. SCC AS updates
information related to T-ADS for future use. The originating telephony services are executed in
the MMTel AS and the call is delivered to the terminating network.

Ut/XCAP

Sh

MME/ T-ADS
HSS
SGSN

SCP SCC
AS TAS
CAP v2
ISC ISC

24.008 ISUP Mg/SIP SIP

GMSC MGCF CSCF

CS CS Mb/RTP
Remote
End
MGW

Figure 3 MSC without ICS support originating call

 Commercial in confidence
DESCRIPTION 6 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

2.2.1.2 ICS with MSC without ICS support, Terminating calls

For terminating calls, SCC AS is the last AS invoked. The T-ADS in SCC AS determines that
the call is to be terminated on CS domain. As there is no registration via an eMSC, the
terminating call breaks out to CS via an MGCF in the IMS network towards a GMSC in the CS
network.

Based on the T-ADS ‘breakout to CS policy’, there exists following listed CS breakout
procedures

 Prefix based: SCC AS adds a prefix to the B-number, and may also
optionally add a prefix to A-number, for the IMS Core to route the call
towards CS domain. BGCF in S-CSCF analyzes the prefix and routes the
call towards an MGCF. MGCF may remove the B-number prefix (or may
be kept to avoid that the CS network routes the call back to IMS) and
sends an IAM message towards a GMSC.

 CSRN/MSRN based: SCC AS performs ‘Sh Pull’ request towards HSS for
CSRN. HSS makes an MSRN query towards HLR (with or without ‘pre-
paging’ support request based on configuration). HSS uses the MSRN
response from the HLR to answer the CSRN ‘Sh Pull’ request. S-CSCF
uses the retrieved MSRN as new Request URI to route the call towards
BGCF. BGCF routes the call towards MGCF. MGCF finally routes the call
towards Circuit Switch network.

The call is forwarded towards an MSC which retrieves the subscriber information from an HLR
if the MSC does not already have a copy of the subscriber data. The subscriber information
indicates that terminating services shall not be performed by the MSC; terminating services
were performed by IMS.

Ut/XCAP

Sh

MME/ T-ADS
HSS
SGSN

SCC TAS
AS
ISC ISC

24.008 ISUP Mg/SIP SIP

MSC GMSC CSCF

Originating
MGCF
Remote
CS Mb/RTP
CS End
Terminating
MGW
UE

Serving PLMN HPLMN

Figure 4 MSC without ICS support terminating call

 Commercial in confidence
DESCRIPTION 7 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

2.2.2 Service Domain Selection (SDS)

Originating or Terminating Service Domain Selection is performed in the CS network to be

able to identify that a call has to be forwarded to IMS for services execution.

The MSC obtains the subscriber information from the HLR, which contains a CAMEL profile
indicating that SCP in SCC AS has to be invoked and that services shall not be performed by
the CS network. The SCP returns an IMRN (O-SDS) or adds a prefix to the B-number
(T-SDS) for MSC/GMSC to route the call towards IMS via MGCF.

Services are executed in IMS by the MMTel AS.

In case the T-ADS in SCC AS determines that the call shall be routed back to the CS domain,
the prefixes added to B and A numbers (A number prefix is optional) by SCC AS can be used
by the CS network to avoid that the call is routed to IMS; the CS network should route the call
towards the UE.
 Commercial in confidence
DESCRIPTION 8 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

3 ICS Detailed Descriptions

3.1 ICS Call Origination

3.1.1 Functional Description

A UE initiates a call which is routed into IMS. If the UE is connected via CS, no services2 are
executed in the CS access. The SCC AS anchors the call to determine if calls are ongoing. An
ongoing call (or recently completed call) determines the most recently access network for an
SCC UE.
Originating calls from fixed UEs don't need to be anchored in SCC AS. This is achieved by
configuring the iFC based on PANI so that only originating calls with:
 PANI set to the 3GPP-E-UTRAN or 3GPP-GERAN access type
 a contact media header set to g.3gpp.ics=”server”
 a contact media header set to g.3gpp.accesstype=”cellular”
 or a contact media header set to g.3gpp.accesstype=”wlan”
will trigger the sending of the INVITE to the SCC AS.

3.1.2 Main Scenarios

3.1.2.1 UE originates over CS via non-enhanced MSC; O-SDS

The architecture for O-SDS is described in Figure 3.

A UE in a CS access originates a call. The originating call is routed via a MSC without ICS
support which performs O-SDS and retrieves the subscription information for the A subscriber
from the HLR. The information contains an originating CAMEL subscription information (O-
CSI) which triggers the invocation of the SCP via CAPv2. The SCP in SCC AS analyzes the
call and if conditions are met returns an IMRN for routing the call towards IMS.

The call is routed towards IMS for performing originating services.

2 Technically speaking, CS services are executed in the MSC, according to the HLR profile, however, the settings in
the HLR profile are such that they do not interfere with the service as configured in IMS.
 Commercial in confidence
DESCRIPTION 9 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Orig SCC AS/ Term

MSC HLR MGCF I-CSCF S-CSCF HSS SCC AS AS
UE SCP Network
1. IAM
2. CAPv2 IDP (B, A)
3. CAPv2 Connect (IMRN)
4. IAM 5. INVITE 6. LIR (IMRN)
7. LIA (SCC AS)
8. INVITE (IMRN)
9. INVITE (B)
10. INVITE (B)
11. INVITE (B)
12. INVITE (B)
13. INVITE (B)

Figure 5 Originating call with non-enhanced MSC

Step Description
1 The UE performs O-ADS and uses the CS access network to
establish a new call
2 The MSC checks the subscriber information. The subscriber
information includes originating CAMEL information (O-CSI)
indicating that SCP in SCC AS must be contacted for further
information.
The subscriber information also indicates that originating services
shall not be performed in the CS network.
MSC sends a CAPv2 Query towards SCP in SCC AS.
3 The SCP analyses the call and determines if the call shall be
routed towards IMS. Based on the media type of the call, whether
the UE is roaming, the dialed number is a local number or the
dialed number contains an escape code the SCP determines to
route to IMS.
To route the call to IMS the SCP replaces the B-number with an
IMRN and sends a Connect message to the MSC with the IMRN.
Otherwise the SCP may return a CAP Continue message (i.e. no
rerouting towards IMS) or indicate an error condition.
4 MSC sends an IAM towards GMSC which sends it to MGCF.
5 MGCF sends in INVITE towards the I-CSCF; the IMRN in the
INVITE is a PSI.
6-7 I-CSCF retrieves from the HSS information about to which SCC
AS the INVITE for the PSI shall be sent.
 Commercial in confidence
DESCRIPTION 10 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
8 I-CSCF sends the INVITE towards the SCC AS (SCP).
9 The SCC AS replaces the IMRN with the B-number previously
stored and sends and INVITE for B-number with orig parameter to
the I-CSCF.
10 The I-CSCF forwards the INVITE for the B-number to the S-CSCF
serving the A subscriber
11 S-CSCF sends the INVITE to the SCC AS assigned to the
A-number. The SCC AS is the first AS invoked for the call.
12 SCC AS anchors the call and sends an INVITE to the CSCF
13 S-CSCF sends the INVITE to the next AS specified in the user
profile. The call establishment is continued as usual.

3.2 ICS Call Termination

3.2.1 Functional Description

Terminating calls are handled as generic voice call terminations regarding MMTel service
execution. T-SDS is used to route the call to IMS if necessary. After execution of the
terminating services, the SCC AS is invoked as last AS to execute T-ADS. The T-ADS
function determines which access to try for session delivery. T-ADS ensure that for a SCC UE
only one of PS access or CS access is used, and that other registered user’s UEs are always
called.

3.2.2 Main Scenarios

3.2.2.1 Terminate on CS via MSC without ICS support; break out call

A terminating call is received in IMS. The SCC UE may have a LTE PS registration, but this
does not assures that the UE can be reached on LTE PS access. T-ADS in the SCC AS
determines that the call to the UE shall be terminated on CS. The UE does not have a
registration via eMSC; therefore the call has to be break out to CS network based on ‘CS
breakout policy’.
 Commercial in confidence
DESCRIPTION 11 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Originating
UE MSC MGCF SCC AS HSS-HLR MMTel AS S-CSCF
Network

1. SIP INVITE B
2. SIP INVITE B
3. Execute B’s
Terminating Services
4. SIP INVITE B

5. SIP INVITE B

6. Execute T-ADS and

CS break out
7a. SIP INVITE CSRNprefix+B,
Select prefix+A
Only Inbox and
case Either
type. Control
of prefixed 7a or 7b. Sh pull/resp for
handles change
based CS of (7b and CSRN query
width & height
7c)
break outbox.
7c. SIP INVITE CSRNprefix+B

8. SIP INVITE ’prefix+B’ or CSRN

9. Remove the prefix

10. IAM B
or CSRN
11. Retrive CSRN of B
number
12. IAM
CSRN

Figure 6 Terminating call with non-enhanced MSC

Step Description
1 Terminating S-CSCF receives and INVITE from originating side
2-4 S-CSCF contacts other AS which can perform terminating
services for the call
5 S-CSCF contacts SCC AS as the last AS in the chain.
6 SCC AS performs T-ADS to find the location of the terminating
UE. The UE is on CS network, and the call has to be break out to
reach the UE based on the CS breakout policy,
 Prefix based (step 7a) or
 CSRN based (step 7b-7c)
7a In case of prefix based CS breakout policy, SCC AS adds a prefix
to B to break out the call to CS, and a prefix to A; the prefixes to B
and A numbers can be used to prevent that CS, due to T-SDS,
routes the call back to IMS. Also based on the ICS indication
configuration, SCC AS can add ICS capacity indicator to the SIP
INVITE request as the feature tag “g.3gpp.ics”.
 Commercial in confidence
DESCRIPTION 12 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
7b-7c In case of CSRN/MSRN based CS breakout policy, SCC AS
retrieves CSRN from HSS/HLR performing ‘Sh pull request’. The
retrieved CSRN is used as the new R-URI by the SCC AS for the
INVITE towards CS network. Also based on the ICS indication
configuration, SCC AS can add ICS capacity indicator to the SIP
INVITE request as the feature tag “g.3gpp.ics”.
Note: the ICS capacity indicator is added both to SIP INVITE
requests as well as to SIP 200 reponses to the INVITE requests.
8 BGCF in S-CSCF analyzes
 the B-number prefix (for prefixed base CS breakout) or
 CSRN (for CSRN based CS breakout )
and routes the call towards the MGCF
9 In case of prefix based CS routing, MGCF may remove the prefix
from B-number before sending an IAM to the CS network. The
prefix is not removed if it is necessary for CAMEL suppression
and/or announcement suppression in the CS network, that is, to
not route the call back to IMS.
10 MGCF sends an IAM to the MSC. Also MGCF can, based on
presence of the ICS indication in the incoming INVITE, trigger
announcement suppression from CS in order to prevent double
announcements (from IMS and CS). The announcement
suppression is then preformed in VMSC.
11 In case of prefix based CS routing, MSC requests routing
information from HLR to reach the UE
12 MSC sends an IAM towards the UE.

3.2.2.2 Terminating Service Domain Selection (T-SDS)

A terminating call may arrive to the CS domain. The CS domain will have to route the call
towards IMS if the B subscriber is an IMS user for performing terminating services.

The overall architecture when the IMS network receives the terminating call, from a CS
network and delivers the call to IMS termination is shown in Figure 7.
 Commercial in confidence
DESCRIPTION 13 (38)
Prepared (Subject resp) No.

Thanh Vu Q
ApprovedSlide title
(Document resp)
ICS, SDS in terminating network for an
Checked Date Rev Reference
minimum 32 pt
(32 pt makes 2 rows ICS user 2016-11-02 PA1

Text and bullet level 1

SDS enables to route the call
minimum 24 pt
from MSC to IMS for ICS user
(then IMS, terminating services
Bullets level 2-5
are executed including T-ADS
minimum 20 pt
for ICS user)
SDS Sh
!"#$%&'()*+,-
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRST
T-ADS
UVWXYZ[\]^_`abcdefghijklmnopqrstuvwxy
z{|}~¡¢£¤¥¦§¨©ª«¬®¯°±²³´¶·¸¹º»¼½ÀÁÂÃÄÅÆÇÈËÌÍ SCP HSS/
ÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñ
òóôõö÷øùúûüýþÿĀāĂăąĆćĊċČĎďĐđĒĖėĘęĚě
HLR
ĞğĠġĢģĪīĮįİıĶķĹĺĻļĽľŁłŃńŅņŇňŌŐőŒœŔŕŖŗŘřŚśŞş
ŠšŢţŤťŪūŮůŰűŲųŴŵŶŷŸŹźŻżŽžƒȘșˆˇ˘˙˚˛˜˝ẀẁẃẄẅ

AP
Ỳỳ–—‘’‚“”„†‡•…‰‹›⁄€™−≤≥fifl
ĀĀĂĂĄĄĆĆĊĊČČĎĎĐĐĒĒĖĖĘĘĚĚĞĞĠĠĢĢĪĪĮĮİĶ MMTel SCC

M
ĶĹĹĻĻĽĽŃŃŅŅŇŇŌŌŐŐŔŔŖŖŘŘŚŚŞŞŢŢŤŤŪŪŮŮ
ŰŰŲŲŴŴŶŶŹŹŻŻȘș CAP v2 AS AS
ΆΈΉΊΌΎΏΐΑΒΓΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΪΫΆΈΉΊ
ΰαβγδεζηθικλνξορςΣΤΥΦΧΨΩΪΫΌΎΏ
ЁЂЃЄЅІЇЈЉЊЋЌЎЏАБВГДЕЖЗИЙКЛМНОПРСТУФ
ISC
ХЦЧШЩЪЫЬЭЮЯАБВГДЕЖЗИЙКЛМНОПРСТУФХ
ЦЧШЩЪЫЬЭЮЯЁЂЃЄЅІЇЈЉЊЋЌЎЏѢѢѲѲѴѴҐҐә
ǽẀẁẂẃẄẅỲỳ№ ISUP Mg/SIP SIP
ISUP
MGCF
CSCF
MSC/
GMSC
CS Mb/RTP Terminating/
B party
MGW

Originating
Network Terminating Network

Do not add objects or Figure 7 : ICS: T-SDS in terminating network for an ICS user on CS
text in the footer area

The terminating call is routed via the GMSC which retrieves subscriber data for the B-number
from the HLR. The subscriber data has CAMEL subscription information for terminating calls
(T-CSI) which triggers invocation of the SCP in SCC AS via CAP v2. The SCP adds a routing
prefix to the B number. The MSC/GMSC/MGCF routes the call based on the routing prefix of
the B number to the IMS network and removes the prefix.

The SCP in the SCC AS can decide to route to IMS based on the media call types (.e.g.
allow/reject voice, video, fax, data etc..)

Then IMS services are executed as an ICS terminating call. The terminating initial filter criteria
for the B number are triggered.
 Commercial in confidence
DESCRIPTION 14 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Orig MSC/ SCC AS/ Term

HLR MGCF I-CSCF S-CSCF HSS SCC AS AS
Network GMSC SCP Network
1. IAM
2. MAP Get subscriber information
3. MAP Subscriber information (CAMEL)
4. CAPv2 IDP (B, A)
5. CAPv2 Connect (Prefix+B, A)
6. IAM 7. INVITE 8. LIR (B)
9. LIA
10. INVITE (IMRN)
11. INVITE (B, A)
12. INVITE (B, A)
13. INVITE (B, A)

T-ADS
14. INVITE (B, A)

15. Terminate
Call

Figure 8 Originating call with non-enhanced MSC

Step Description
1 The terminating call arrives to the CS terminating domain.
2/3 The MSC retrieves the B subscriber information from the HLR.
The subscriber information includes terminating CAMEL
information (T-CSI) indicating that SCP in SCC AS must be
contacted for further information.
The subscriber information also indicates that terminating services
shall not be performed in the CS network.
4 MSC sends a CAPv2 Query towards SCP in SCC AS.
5 The SCP analyses the media type of the call (e.g. voice, video,
data, fax etc) and may add a prefix to the B-number in the
Connect message to the MSC to route the call towards IMS.
6 MSC sends an IAM towards GMSC which sends it to MGCF.
7 MGCF removes the prefix from the B-number and sends the
INVITE towards the I-CSCF.
8-9 I-CSCF retrieves from the HSS information about which S-CSCF
is serving the B subscriber.
10 I-CSCF sends the INVITE towards S-CSCF.
11-12 S-CSCF invokes the AS specified in the iFC for the user which
perform terminating services for the call.
 Commercial in confidence
DESCRIPTION 15 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
13 S-CSCF sends the INVITE to the SCC AS assigned to the B user.
The SCC AS is the last AS invoked in the terminating call.
14 SCC AS performs T-ADS and sends an INVITE to the CSCF
15 S-CSCF receives the INVITE from SCC AS. S-CSCF terminates
the call routing it to the access indicated by SCC AS. The call
might be terminated on LTE, or might be routed back to the CS
domain.

3.3 Data model

3.3.1 Non ICS enhanced MSC

To support SCC UE connected to a non ICS enhanced MSC one of the above data model is
used.

The user profile in CS (stored in the HLR) shall have the following properties:
1 CAMEL subscriber information for originating calls (O-CSI), to invoke SCP in
SCC AS for originating cases
2 CAMEL subscriber information for terminating calls (T-CSI), to invoke SCP in
SCC AS for SDS during terminating call from CS.
3 Supplementary Service provisioned in accordance with section Error!
Reference source not found..

3.3.2 IMS Routing Number (IMRN)

Call origination based on originating CAMEL trigger will send an InitialDP CAPv2 message to
SCP in SCC AS. One IMRN (E.164) from the pool of configured IMRN for this SCC AS
(CAMEL) instance is returned in response (pointing to IMS and this specific SCC AS instance
by PSI configuration in HSS).

SCC AS stores A, B (A and B party), and other data against this IMRN instance and other
information.

The SCC AS instance triggered via the initial filter criteria for the user in the IMS network must
match the CAMEL trigger information (O-CSI/T-CSI) in the subscriber data in the HLR.

The IMRNs pool for each SCC AS (CAMEL) instance is recommended to be as wild card PSIs
(a range) as this will have lower performance penalties in HSS.

It is recommended that the order of allocation of IMRNs is reversed upon each re-start to
minimize the risk of re-allocation of an IMRN instance that been just used before a complete
node crash.

SCC AS generates an alarm/notification at re-start also.

 Commercial in confidence
DESCRIPTION 16 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

4 SRVCC Detailed Descriptions

4.1 SRVCC Access Transfer

SRVCC access transfer is needed for the transfer of voice sessions when the mobile moves
from LTE to GSM/WCDMA CS coverage. Access transfer of calls from GSM/WCDMA to LTE
is not supported.

4.1.1 Functional Description

This function starts when the LTE radio network detects that the UE is about to leave the
coverage area.

When measurement reports between the UE and the E-UTRAN indicate low signal strength of
the LTE radio access network, a message is sent to the MME node that a transfer to the
GSM/WCDMA access is required. Only voice bearers are included in the handover message
and thus only voice calls will end up in the CS domain. This implies that after successful voice
access transfer from LTE to CS, only the voice part of a video communication will be kept.

The MME serving the LTE network uses the Sv interface to inform the MSC of the CS network
that access transfer is needed. The MSC is addressed by an IP address that is manually
configured in the MME.

The MSC prepares the CS radio network for the access transfer and initiates a new call leg
addressed to the STN-SR, which points to the ATCF who anchored the session.

The anchoring node (ATCF) identifies the user using the C-MSISDN received in PAI.

ATCF locally redirects the media in the ATGW (from LTE to CS) and informs the SCC AS
about the access transfer.3

4.1.2 Main Scenarios

4.1.2.1 Pre-conditions

The UE is involved in an ongoing voice session and is about to leave the LTE coverage area.

The UE includes the SRVCC capability indication as part of the "MS Network Capability" in the
Attach Request message and in Tracking Area Updates. This information is needed by the
MME for the SRVCC.

3In case no local media switching in the ATGW can take place, ATCF will inform SCC AS who will initiate an SDP re-
negotiation with the remote end.
 Commercial in confidence
DESCRIPTION 17 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

In HSS, the EPS profile of the subscriber must contain an STN-SR4 value which is stored as
an IMS PSI in the HSS.

The MME has received (pushed from the HSS) the STN-SR and the C-MSISDN as part of the
attachment and/or the Registration process.

The MSC Server, the MME and the eNodeB are enhanced for SRVCC.

4.1.2.2 Successful SRVCC Access Transfer

The below sequence shows an overview of the SRVCC transfer for the network parts external
to IMS. The sequence shown and the associated description is taken from 3GPP 23.216 and
may or may not reflect the Ericsson implementation. The IMS part, the target of this document
(step 9), is detailed in Figure 10.

4The STN-SR must not be changed in the EPS profile while the user is registered. This as neither SCC AS nor ATCF
will be notified of the STN-SR modifications in HSS and a change can result in the selection of another instance of the
SCC AS or ATCF meaning that the call to handover to CS is not found.
 Commercial in confidence
DESCRIPTION 18 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

MSC Server Target Target

UE E-UTRAN MME IMS
MGW MSC BSS

1: Measurement Reports

Decision for Handover

2: HO Required
3: PS to CS Req
(Target ID, STN-SR,
IMSI; C MSISDN...)

4: Prep HO Req

5: HO Req/Ack

6: Prep HO Resp.

7: Establish Circuit

8: Initiation of Session Transfer (STN-SR)

10: PS to CS Resp.

11: Handover Command 9. Session transfer and

release of IMS access leg.
12: HO from E-UTRAN Command

13: UE tunes to
GERAN

14: Handover Detection

15: HO Complete

16: HO Complete

17: Answer

18: PS to CS Complete/Ack

Figure 9 SRVCC Access Transfer

Step Description
1 The UE sends measurement reports to E-UTRAN.
2 Based on UE measurement reports, the source E-UTRAN
decides to trigger an SRVCC access transfer to the CS domain.
E-UTRAN sends Required message having Target ID and
SRVCC HO Indication to the MME. The SRVCC HO indicator
indicates to the MME that this is an SRVCC access transfer
operation for the voice part towards the CS domain.
3 The MME splits the voice bearer from the non-voice bearers and
initiates, for the voice bearer, the PS-CS access transfer
procedure towards the MSC Server.
The MME sends a SRVCC PS to CS Request with necessary
IMSI, Target ID, STN-SR and C-MSISDN to the MSC Server.
(The address to the MSC Server is configured in the MME.)
 Commercial in confidence
DESCRIPTION 19 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
4 In this example, the MSC Server is not the MSC serving the area
the UE is within. The MSC Server therefore anchors the call and
sends a Prepare Handover Request message to the target MSC.
5 The target MSC performs resource allocation with the target BSS
by exchanging Handover Request/Acknowledge messages.
6 The target MSC sends a Prepare Handover Response message
to the MSC Server.
7 Establishment of circuit connection between the target MSC and
the MGW associated with the MSC Server e.g. using ISUP IAM
and ACM messages.
8 The MSC Server initiates the Session Transfer by using the STN-
SR towards the IMS (the SRVCC notification can be sent from the
MSC Server to IMS directly on SIP, or through an ISUP IAM
message via an external MGCF).
9 A new access leg is established by the MSC Server toward the
IMS. IMS executes the Access Transfer procedure towards this
new access leg.
The downlink flow of VoIP packets is switched towards the CS
access leg at this point.
The source IMS access leg is released now.
10 The MSC Server sends a SRVCC PS to CS Response message
to the MME.
11 The MME sends a Handover Command message to the E-
UTRAN.
12 The E-UTRAN now sends a Handover Command message to the
UE.
13 The UE tunes to the new CS Network.
14 Handover Detection at the target BSS occurs.
15 The target BSS sends a Handover Complete message to the
target MSC.
16 The target MSC sends an SES (Handover Complete) message to
the MSC Server. The speech circuit is through connected in the
MSC Server/MGW.
17 Completion of the establishment procedure with ISUP Answer
message to the MSC Server.
 Commercial in confidence
DESCRIPTION 20 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
18 The MSC Server sends an SRVCC PS to CS Complete
Notification message to the MME. Informing it that the UE has
arrived on the target side. The MME acknowledges the
information by sending an SRVCC PS to CS Complete
Acknowledge message to the MSC Server.

The IMS part of the sequence is, for an ongoing call, opened up and detailed in Figure 10.
The figure describes the case when SIP (INVITE) is used as notification from the MSC Server
to IMS5.

This also implies that the PSIs are globally routable and that the ATCF hosting the PSI can be
invoked as a terminating Application Server directly from the I-CSCF via information stored in
the HSS. That is the PSIs must be provisioned in the HSS.

The PSIs are stored in the HSS as distinct PSIs. Wildcarded PSIs are not used together with
SRVCC.

During an SRVCC access transfer the MME deletes the PS bearer used for voice media. The
Policy and Charging Rules Function (PCRF) is notified of the loss of bearer and in turn
informs the P-CSCF that this loss of bearer is due to SRVCC and hence part of the mobility
procedure.

5 If not SIP, then the MSC Server will send an ISUP IAM message to an external MGCF that will map the IAM to
INVITE.
 Commercial in confidence
DESCRIPTION 21 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

MSC Server HSS I-CSCF S-CSCF P-CSCF ATCF SCC AS

The UE has a session

towards remote end, and
an SR-VCC HO has been
triggered (Step 1-7 in figure 10).
8: INVITE
R-URI: STN-SR, PAI: C-MSISDN

9a: LIR/LIA

Direct PSI routing

using STN-SR. 9b: INVITE
R-URI: STN-SR
PAI: C-MSISDN

C-MSISDN is used to
find the correct session.
ATGW is ordered to redirect
media from LTE to CS.
9c: Modify

9d: Modify Reply ATGW

9f: 200 OK 9e: 200 OK

9g: ACK
9h: Modify

9i: Modify Reply ATGW

9j: INVITE (Target-Dialog)

R-URI: ATU-STI
PAI: C-MSISDN

9k: 200 OK
9l: Modify

9m: Modify Reply ATGW

A: RAR/ASR 9n: ACK

PCRF B: RAA/ASA

9o: Start fallback timer.

9p: ACR (start)

9q: ACA (start) CDF

9r: Fallback timer expires.

9s: BYE 9s: BYE

9t: Start BYE timer.

9u: BYE
UE

9v: BYE timer expires.

9w: 408 9x: 408 Timeout

C: STR

PCRF D: STA
9y: Modify / Modify Reply
ATGW

Figure 10 IMS details during an eSRVCC Access Transfer

 Commercial in confidence
DESCRIPTION 22 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
1-7 The E-UTRAN initiates the SRVCC access transfer, for details
see Figure 9.
8 The MSC Server initiates the Session Transfer by sending an
INVITE addressed to the STN-SR with the C-MSISDN as PAI
towards the IMS (the I-CSCF).
9a ATCF is selected after a location query to the HSS by the I-CSCF
(direct PSI routing).
(The provisioned PSI must direct the request to the P-
CSCF/ATCF “foreign network” port.)
9b The INVITE is sent to the ATCF where ATCF uses the C-MSISDN
to find the correct session.
The Session expiry supervision is not supported for the sessions
over CS network. If Session-Expires and / or Min-SE headers are
received, they are silently ignored. The CS sessions can be
supervised with Maximum non-supervised session duration timer.
(See Figure 11 for a description on how the ATCF proxy the
INVITE to the SCC AS when an update of the remote end is
needed.)
9c-9d ATGW is ordered to redirect the media from LTE PS to CS.
9e-9f The 200 OK is sent back from the ATCF in the dialogue to the
MSC Server as an acknowledgement to the initial INVITE.
9g The MSC Server sends an ACK to the ATCF.
9h The ATCF sends a MODIFY to ATGW to query the currently used
codec for IMS Core side which is indicated by ‘a=codec-
changed:0’.
9i The ATGW replies the MODIFY with currently used codec
parameters in the direction to IMS Core.
 Commercial in confidence
DESCRIPTION 23 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
9j The ATCF updates the SCC AS that a transfer has taken place by
sending a new initial SIP INVITE request to the SCC AS, creating
a new remote leg dialog, using the stored ATU-STI as R-URI.
Session to be transferred is identified by Target-Dialog header.
(The UE may have several sessions and Target-Dialog points to
the session to be transferred.)
The SBG/ATCF binds the new remote leg dialog (between
SBG/ATCF and SCC AS) to the CS access dialog between MSC
and SBG/ATCF.
The ATCF needs to send the INVITE(ATU-STI) to the SCC AS
with the currently used media.

Information of currently used media is stored in the ATGW, not in

the SBG/ATCF. Thus, the ATGW provides the currently used
codec on the Core when requested from the ATCF. ATCF uses
the information to formulate the SDP in the INVITE(ATU-STI).
The assumption is therefore that the media in the access transfer
INVITE is the same as currently used media and that SCC AS
therefore do not need to re-negotiate SDP with remote party.
The ATU-STI can either be a SIP URI or a TEL URI, and the
ATCF can either be located in the home- or the visited network as
described in the below four cases:
1. SIP URI; this is the recommended format and a DNS
query is being made by the ATCF using the FQDN (of the
SIP URI) resulting in the SCC-AS address. The P-
CSCF/ATCF will route directly to SCC-AS.
 If the DNS query fails, the ATCF uses the
configured address which can be an I-CSCF
address (for PSI routing using HSS with SCC AS
as server identity for the PSI (ATU-STI)) or the
SCC AS address (for direct routing).
Note: The direct routing is not recommended to be
used in networks with more than one SCC AS.
2. TEL URI; the P-CSCF/ATCF will map the TEL-URI to a
SIP URI using the FQDN of the registration request. The
routing now follows the same step as outlined for the SIP
URI above.
 Commercial in confidence
DESCRIPTION 24 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
3. Roaming(SIP-URI); in a roaming case where the served
P-CSCF/ATCF is in a visited network and the SCC AS in
the home network, the SIP INVITE cannot directly be sent
to SCC-AS (as the topology of the home network is not
known to the internal DNS of the visited network).

Therefore, in the roaming case, the internal DNS query in

the visited network from the ATCF will result in the
address of the exit IBCF. The exit IBCF will query the
external DNS resulting in the address of the default entry
IBCF of the home network. The SIP INVITE is sent
through the IBCFs of the home network.
 If the internal DNS query fails, the ATCF uses the
configured address. If there is only inbound
roaming users for this P-CSCF/ATCF, the
configured address should be the exit IBCF
address. Note: In a network where own users are
mixed in the same P-CSCF with inbound roamers,
the configured address must be an I-CSCF
address. The I-CSCF either uses PSI routing (with
exit IBCF stored as server identity for the PSI
(ATU-STI)) or uses sub-domain routing to the exit
IBCF address. Routing from this exit IBCF is done
as previously described.
In the home network, the IBCF can either be configured
with a default I-CSCF address, or not configured with any
address.
 In case of a configured I-CSCF address, The SIP
INVITE is sent to the I-CSCF who makes a location
query to the HSS. Either the provided R-URI (ATU-
STI) is stored as a PSI in HSS with SCC AS as
server identity for the PSI, or (if no PSI is
provisioned and HSS answers with unknown user)
I-CSCF uses sub-domain routing where a DNS
query is being made to find the SCC AS. In either
case, I-CSCF sends the INVITE to the selected
SCC AS (using direct PSI, or sub-domain routing).
 If the home IBCF does not have any configured
address, it will route using the DNS to resolve the
FQDN in the Request-URI (that is the FQDN in
ATU-STI). Using DNS, the IBCF is able to route
directly to SCC AS.
 Commercial in confidence
DESCRIPTION 25 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
4. Roaming(TEL-URI); the served P-CSCF/ATCF in the
visited network will map the TEL-URI to a SIP URI using
the FQDN of the registration request. An internal DNS
lookup will result in the address of the exit IBCF. The
routing now follows the same step as outlined for the
roaming(SIP URI) case above. The home network I-CSCF
will convert the SIP-URI back to a TEL-URI before the
HSS query. The ATU-STI must in this case be provisioned
as a PSI in HSS.
Only the latest active speech media in the selected session is
transferred during the access transfer.
If there are more audio components towards remote end, then
SCC AS selects the first active audio component (a=sendrecv)
matching the codec in SDP of INVITE(ATU-STI).
If no proper media component found then INVITE(ATU-STI) is
rejected with "404 Not Found" response.
The other media components are removed by the SCC AS by
means of re-INVITE request towards remote end which contains
an SDP offer. In the SDP offer the port value of the unwanted
media streams are set to 0.
If the Target-Dialog header is not present in the INVITE, or if the
received SDP offer is updated, then the SCC AS fall back to the
SRVCC procedure as described in 24.237 Release 9. It means,
the SCC AS updates the remote end with a new SDP offer and
forwards the SDP answer in the response to the INVITE towards
the ATCF.
9k A 200 OK response is sent back to the ATCF from the SCC AS.
If ATCF receives a changed remote SDP in the response, ATCF
sends a MODIFY to the ATGW with the new remote media port
information in accordance with RFC 3264 chapter 8.3 "Modifying
a Media Stream".
9l If ATCF receives a changed remote SDP in the response, ATCF
sends a MODIFY to the ATGW with the remote SDP received in
step 9k.
9m The ATGW replies to the codec selection MODIFY. If the MODIFY
is rejected by BGF or if timeout occurs, the ATCF will release the
CS session.
9n The ATCF Acknowledge the 200 OK with an ACK.
 Commercial in confidence
DESCRIPTION 26 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
A The PCRF sends ASR or RAR to SBG depending on if only audio
bearer is released or all the bearers are released. The Abort-
Cause in ASR or RAR indicates that the release is due to PS to
CS handover (PS_TO_CS_HANDOVER).
B If RAR is received in the previous step, the SBG answers it with
RAA and continues with next step.
If ASR is received in the previous step, SBG releases the Rx
session with an STR. However, the PS and CS sessions will
continue as normal. This behavior is not shown in the use case.
9o A fallback timer is started in SCC AS. The purpose of this timer is
to keep the old PS leg for an operator defined time allowing the
UE to fallback to PS.
9p The SCC AS sends an ACR start for the offline charging.
9q SCC AS receives an ACA charging response to the start ACR
request.
9r The fallback timer expires.
9s BYE is sent towards P-CSCF/ATCF to release the old PS leg.
The BYE is sent as a result of an expired fallback timer.
9t A P-CSCF BYE timer is started.
9u The SBG sends the BYE to the served UE in the PS network.
9v The BYE will either timeout or the P-CSCF will receive a
response from the served UE depending on whether the UE lost
PS connectivity or not. The assumption in this sequence is that
the UE has lost the connection and therefore the BYE timer
expires in the P-CSCF.
(If the UE was still connected, then the BYE would have been
answered with a 200 OK.)
9w- The P-CSCF answers the BYE received from the SCC AS with
9x either 408 (Request Timeout) or 200 OK.
The assumption in this sequence is that the BYE sent to the UE
timed out and therefore a 408 is sent to the SCC AS.
C P-CSCF sends STR to PCRF to close the Diameter session.
D PCRF answers the STR with STA.
 Commercial in confidence
DESCRIPTION 27 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
9y The ATCF sends the MODIFY command to the ATGW to release
all the streams in the multimedia session except for the access
transferred audio stream. The CS session continues to use the
H.248 context for the access transferred audio stream.
The ATGW releases the resources and replies to the MODIFY
command.
If charging is configured for the PS session, the P-CSCF stops the
charging session by sending an ACR [stop] request towards the
CDF. The ACR [stop] will not include the media statistics for the
access transferred audio stream. This is not shown in the figure.
10-18 Not shown in the Figure 10. See Figure 9.

When the switching of media in the ATGW cannot be used, an SDP re-negotiation towards
the remote end must take place. Note however that the normal behavior for Release 10
access transfer is that ATCF/ATGW handles media changes with transcoding or payload type
re-mapping, and the speech media stays the same toward the remote side.

In Figure 11, no ATCF is included at REGISTER (the roaming network did for example not
support ATCF) and hence the STN-SR used as R-URI in the INVITE from the MSC will be
routed, via PSI routing in I-CSCF and HSS, to the SCC AS.
 Commercial in confidence
DESCRIPTION 28 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

MSC Server
HSS P-CSCF I-CSCF S-CSCF SCC AS MMTel AS Remote end
MGW

The UE has a session

towards remote end, and
an SR-VCC HO has been
triggered (Step 1-7 in figure 9). 8: INVITE
SIP: STN-SR
PAI: C-MSISDN
SDP: MGw

9a: LIR/LIA

Direct PSI routing. 9b: INVITE

SIP: STN-SR
PAI: C-MSISDN
SDP: MGw

C-MSISDN is used to
find the correct session.

9c: Re-INVITE

9d: Re-INVITE

9e: Re-INVITE

9f: Re-INVITE

9g: 200 OK

9h: 200 OK

9i: 200 OK

9j: 200 OK
9k: 200 OK
Contact,
SDP B

9l: ACK

9m: ACR (start)

CDF
9n: ACK

9o: ACK

9p: ACK

9q: ACK

9r: Start fallback timer.

9s: ACA (start)

CDF

9t: Fallback timer expires.

9u: BYE

CDF
UE 9v: 200 OK

9x: ACR (event)

9y: ACA (event) CDF

Figure 11 IMS details during an SRVCC Access Transfer, SDP re-negotiation towards remote end needed
 Commercial in confidence
DESCRIPTION 29 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
1-7 The E-UTRAN initiates the SRVCC access transfer.
8 The MSC Server initiates the Session Transfer by sending an
INVITE addressed to the STN-SR with the C-MSISDN as PAI
towards the IMS (the I-CSCF).
9a SCC AS is selected after a location query to the HSS by the I-
CSCF (direct PSI routing).
9b The INVITE is sent to the SCC AS.
9c The SCC AS uses the C-MSISDN to find the correct session.
The SCC AS verifies that the SDP offer is changed compared with
when the session was anchored. A changed SDP offer means
that an SDP re-negotiation with the remote end must take place.
A re-INVITE is sent to the S-CSCF to establish a new access leg.
9d The S-CSCF forwards the re-INVITE to the next AS in the chain
(the MMTel AS).
9e The MMTel AS acts as a B2BUA and sends the re-INVITE back to
the S-CSCF.
9f S-CSCF now sends the re-INVITE to the remote end.
9g The remote end answers with a 200 OK.
9h-9k The 200 OK is sent back in the dialogue, through the ASs and the
I-CSCF to the MSC Server as an acknowledgement to the initial
INVITE.
9l The MSC Server sends an ACK to the SCC AS.
9m The SCC AS sends an ACR start for the offline charging.
9n-9q SCC AS forwards the previously received ACK to the remote end.
9r SCC AS starts the fallback timer.
9s SCC AS receives an ACA charging response to the start ACR
request.
9t The fallback timer expires.
9u BYE is sent from the SCC AS to the UE to terminate the old PS
source leg.
9v 200 OK is sent from the UE as an acknowledgement to the BYE.
9x-9y The SCC AS generates charging records.
10-18 Not shown in the Figure 11. See Figure 9.
 Commercial in confidence
DESCRIPTION 30 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

An access transfer of a call in alerting state requires that the UE, the ATCF, the SCC AS and
the MSC all support the alerting capabilities.

This means that when the UE-A on LTE originates a call, support for SRVCC in alerting state
is indicated with Contact header feature tag g.3gpp.srvcc-alerting. SCC AS indicates support
of the alerting state by adding g.3gpp.srvcc-alerting in the Feature-Caps header of the 18x
response.

Note: In order for “alerting” to work, the QCI=1 bearer must be in use for the MME to trigger
the handover. Preconditions signaling is therefore required for that, else QCI=5 is going to be
used.

The below figure show the sequence when the originating UE-A is the subject to an SRVCC
Access Transfer has sent an INVITE request, but the remote end (UE-B) has not yet
answered the call (200 OK on the INVITE).

The sequence is simplified; use Figure 11 for additional details.

 Commercial in confidence
DESCRIPTION 31 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

S-CSCF UE-B
MSC Server P-CSCF ATCF SCC AS
(terminating) (remote-end)

The UE-A has an alerting session

towards remote end, and
an SR-VCC HO has been
triggered (Step 1-7 in figure 10).

8: INVITE
R-URI: STN-SR, PAI: C-MSISDN, SDP
9: INVITE
R-URI: ATU-STI, PAI: C-MSISDN, SDP

10: Start fallback timer.

11: 183 Session Progress (SDP)

12: 183 Session Progress (SDP)

13: PRACK

14: PRACK

15: 200 OK (PRACK)

16: 200 OK (PRACK)

17: INFO

18: INFO

19: 200 OK

20: 200 OK
21: MSC in call delivered state.
26: UE-B answers the call.

23: 200 OK (INVITE)

24: 200 OK (INVITE)

25: 200 OK (access transfer)

26: 200 OK (access transfer)

27: ACK

28: ACK

29: ACK

30: ACK

31: Fallback timer expires.

32: 404 (Not Found)

source access leg
33: 404 (Not Found)
source access leg
UE-A on
34: ACK
PS
35: ACK

Figure 12 Successfule SRVCC Access Transfer for an originating call in alerting state
 Commercial in confidence
DESCRIPTION 32 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
1-7 The E-UTRAN initiates the SRVCC access transfer.
8 The MSC Server initiates the Session Transfer by sending an
INVITE addressed to the STN-SR with the C-MSISDN as PAI
towards the IMS (the ATCF).
9 The transferable session is in alerting state meaning that the
ATCF acts as proxy and sets the Request-URI in the received SIP
INVITE to ATU-STI and forwards the INVITE to SCC AS.
10 SRVCC for calls in alerting state is supported by served UE-A,
MSC and SCC AS. SCC AS correlates the INVITE, based on C-
MSISDN, to the session(s) in early alerting state between UE-A
and remote end.
The PS fallback timer is started.
11 SCC AS sends a 183 (Session Progress) containing the SDP
answer as received in 200 OK.
12 183 received by MSC.
13 MSC responds with a PRACK.
14 PRACK received by SCC AS.
15 200 OK on PRACK sent from SCC AS.
16 200 OK on PRACK received by MSC.
17 SCC AS sends a SIP INFO request to MSC in the dialog created
by the SIP INVITE request due to static STN with
application/vnd.3gpp.state-and-event-info content that the call is
in originating alerting state.
18 SIP INFO received by MSC.
19-20 MSC acknowledges with 200 OK.
21 MSC enters Call delivered state.
22 User on UE-B answers the call.
23 UE-B sends a 200 OK.
24 S-CSCF proxies the response in the backward direction to SCC
AS.
25 SCC AS sends 200 OK on access transfer towards the MSC. Also
(not shown in the figure), an ACR[start] to the CDF is triggered on
the CS charging session, and ACA[start] responded back from the
CDF.
 Commercial in confidence
DESCRIPTION 33 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
26 200 OK on access transfer received by MSC.
Not shown in the figure, but the MSC now indicates to the UE-A
that the far end has accepted the call with a CS CONNECT. And
UE A acknowledges the CS CONNECT.
27-30 MSC acknowledges 200 OK with SIP ACK request.
31 The PS fallback timer in SCC AS expires.
32 SCC AS releases the source access leg by sending a SIP 404
(Not Found) response to ATCF. Also, not shown in the figure, an
ACR[event] to the CDF is triggered on the PS charging session,
and ACA[event] responded back from the CDF.
33 UE A, if still using the PS access, receives SIP 404 on the PS
access leg.
34 ACK may be received by ATCF (if UE-A is still on PS access).
35 ACK received by SCC AS (if ACK was sent by UE-A).
Note: The SCC AS discards any SIP 1xx or SIP 200 (OK) response to the initial SIP INVITE
request received from the remote UE to the MSC server until the SIP 200 (OK) response to
the INFO request is received from the MSC server (step 24).
 SIP 1xx responses sent reliably and the SIP 200 (OK) response to the initial
SIP INVITE request will be retransmitted by the remote UE if the responses
are dropped by the SCC AS.

4.1.2.3 Successful SRVCC Access Transfer for an originating call in pre-alerting state

Note: In order for “pre-alerting” to work, the QCI=1 bearer must be in use for the MME to
trigger the handover. Preconditions signaling is therefore required for that, else QCI=5 is
going to be used.

An access transfer of a call in pre-alerting state requires that the UE, the ATCF, the SCC AS
and the MSC all support the pre-alerting capabilities.

This means that already during a UE-A Registration, the ATCF will add to the SIP REGISTER
a Feature-Caps header field with the g.3gpp.ps2cs-srvcc-orig-pre-alerting indicator.

When the UE-A originates a call, support for SRVCC in pre-alerting state is included by
adding the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag in the SIP INVITE.
The SCC AS will, if pre-alerting is supported, add in the SIP 1xx response a Feature-Caps
header with g.3gpp.ps2cs-srvcc-orig-pre-alerting.

The call sequence is similar to the Figure 12. But the UE-A is in pre-alerting state at the time
of the SRVCC Access Transfer. I.e. the UE to be subjected to an SRVCC Access Transfer
has sent an originating INVITE request, but neither a final SIP response nor a SIP 180
(Ringing) response has yet been received.
 Commercial in confidence
DESCRIPTION 34 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

4.1.2.4 Successful SRVCC Access Transfer for a terminating call in alerting state

An access transfer of a call in alerting state requires that the UE, the ATCF, the SCC AS and
the MSC all support the alerting capabilities.

This means that SCC AS adds g.3gpp.srvcc-alerting in the Feature-Caps header in the
terminating INVITE sent towards the LTE network. Terminating UE indicates support of the
alerting state by adding a g.3gpp.srvcc-alerting feature tag to the Contact header of the 180
response.

Note: In order for “alerting” to work, the QCI=1 bearer must be in use for the MME to trigger
the handover. Preconditions signaling is therefore required for that, else QCI=5 is going to be
used.

The below figure show the sequence when the UE-B that is subjected to an SRVCC Access
Transfer has received an INVITE request, but not yet answered the call (200 OK on the
INVITE).

The sequence is simplified.

 Commercial in confidence
DESCRIPTION 35 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

MSC Server P-CSCF ATCF SCC AS UE-A

The UE-B has a terminating alerting

session towards UE-A, and
an SR-VCC HO has been
triggered (Step 1-7 in figure 10).
8: INVITE
R-URI: STN-SR, PAI: C-MSISDN, SDP
9: INVITE
R-URI: ATU-STI, PAI: C-MSISDN, SDP
10: UPDATE R-URI: UE-A,
PAI: UE-B, SDP

11: 200 OK (SDP)

12: Start fallback timer.

13: 183 Session Progress (SDP)

14: 183 Session Progress (SDP)

15: PRACK

16: PRACK

17: 200 OK (PRACK)

18: 200 OK (PRACK)

19: INFO

20: INFO

21: MSC in call received state.

22: 200 OK 23: 200 OK

UE-B on PS 24: 200 OK 25: 200 OK
answers the
call.

26: CC CONNECT

27: INFO

28: INFO

29: 200 OK (INFO)

31: 200 OK
UE-B on CS. 30: 200 OK (INFO) (UE-B answered the call)
32: 200 OK
(access transfer)
33: 200 OK
(access transfer) 35: ACK
34: CC CONNECT
ACK

36: ACK

37: ACK

38: ACK

UE-B on PS 39: ACK

40: Fallback timer expires.

41: BYE

42: 200 OK
 Commercial in confidence
DESCRIPTION 36 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Figure 13 Successful SRVCC Access Transfer for a terminating call in alerting state

Step Description
1-7 The E-UTRAN initiates the SRVCC access transfer.
8 The MSC Server initiates the Session Transfer by sending an
INVITE addressed to the STN-SR with the C-MSISDN as PAI
towards the IMS (the ATCF).
9 The transferable session is in alerting state meaning that the
ATCF acts as proxy and sets the Request-URI in the received SIP
INVITE to ATU-STI and forwards the INVITE to SCC AS.
10 SRVCC for calls in alerting state is supported by served UE-B,
MSC and SCC AS. SCC AS correlates the INVITE, based on C-
MSISDN, to the session in early alerting state between UE-B and
remote end. SCC AS generates a SIP UPDATE towards the
remote end (UE-A) based upon information in received INVITE
and the information previously stored against this session.
11 UE A responds with 200 OK.
12 The PS fallback timer is started.
13 SCC AS sends a 183 (Session Progress) containing the SDP
answer as received from UE-A.
14 183 received by MSC.
15 MSC responds with a PRACK.
16 PRACK received by SCC AS.
17 200 OK on PRACK sent from SCC AS.
18 200 OK on PRACK received by MSC.
19 SCC AS sends a SIP INFO request to MSC with
application/vnd.3gpp.state-and-event-info content that the call is
in terminating alerting state.
20 SIP INFO received by MSC.
21 MSC enters Call delivered state.
22-23 MSC acknowledges with 200 OK.
24 User on UE-B answers the call when the UE is still in the LTE/PS
access and the served UE sends a 200 OK response to the initial
INVITE.
 Commercial in confidence
DESCRIPTION 37 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

Step Description
25 SCC AS receives the 200 OK response to the initial INVITE. At
this point SCC AS does not act on the 200 OK. It waits until
access transfer is eventually completed (in step 38).
26 Served UE B receives handover command from E-UTRAN and
returnes to 3G successfully, sends a CC CONNECT to MSC.
27 MSC sends a SIP INFO with application/vnd.3gpp.state-and-
event-info content that the call is accepted.
28 SCC AS receives the SIP INFO.
29 The SIP INFO is acknowledged with a 200 OK.
30 The 200 OK is received by MSC.
31 A 200 OK is sent to remote end (UE-A) that the call is answered.
Not shown in the figure, an ACR[start] to the CDF is triggered on
the PS charging session, and ACA[start] responded back from the
CDF.
32 A 200 OK is sent to MSC to indicate a successful access transfer.
Not shown in the figure, an ACR[start] to the CDF is triggered on
the CS charging session, and ACA[start] responded back from the
CDF.
33 MSC receives 200 OK.
34 MSC sends CC CONNECT ACK to UE B on CS.
35 UE-A acknowledges with ACK.
36 The MSC acknowledges the 200 OK from SCC AS.
37 ACK received by SCC AS.
38 The 200 OK on initial INVITE (step 25) is acknowledged with
ACK.
39 The ACK is sent to served UE on PS access. At this time the ACK
will probably never reach the served UE-B as it has tuned to CS.
40 The PS fallback timer expires.
41 SCC AS terminates the PS access dialog towards served UE-B.
42 ATCF (or P-CSCF) responds with 200 OK.

4.1.2.5 Transfer of terminating call in alerting state – user answers on CS

This is the same case as Figure 13 with the difference that the call is answered on CS. There
is no 200 OK from served UE on PS (steps 24, 25), no ACK from SCC AS (steps 38, 39) and
CANCEL instead of BYE (step 41).
 Commercial in confidence
DESCRIPTION 38 (38)
Prepared (Subject resp) No.

Thanh Vu Q
Approved (Document resp) Checked Date Rev Reference

2016-11-02 PA1

4.2 SRVCC without ICS

After an SRVCC access transfer from VoLTE to CS, additional originating calls from this
VoLTE UE will, while connected to the CS network, use CS as the service engine.

However, terminating services will be/may be provided by the domain where the calling party
is. If the calling party is in the CS domain then terminating services is provided by CS. If the
calling party is using VoLTE then terminating services is provided by IMS. If user is camping
on CS when terminating call arrives in IMS and ICS is not used, the call may

a. time out when trying to reach UE over LTE (CFNR may be triggered if
provisioned) or

b. run into terminating unregistered services (in case the IMS registration
has timed out).

4.3 SRVCC support by components external to IMS

For SRVCC to work, the following must be supported by components external to IMS (UE,
eNodeB, MME and MSC):

 UEs with SRVCC capability must be used.

 The eNodeB must be able to trigger an SRVCC access transfer at the

border of the LTE coverage area by sending an SRVCC HO indicator to
the MME.

 The MME must be able to download and store SRVCC specific data
during E-UTRAN attach.

 The Sv reference point is needed for MME signaling including the

handling of relocation preparation procedure requests from the MME to
the MSC.

 The MSC must be able to invoke the access transfer procedure from the
LTE PS access to the CS access (to also support SRVCC access transfer
of not only ongoing voice calls, but also calls on hold and calls in the
alerting state, support of the I2 reference point is needed in the MSC). If
MSC in pool is used, then only some MSCs in the pool need to be
updated to support SRVCC and a gradual upgrade of the MSCs in the
pool based on capacity can be done. A minimum of two MSC Servers per
pool must be upgraded for redundancy reason.