CSFB LTE Feature Training PDF

FN1914, CSFB LTE feature training
MSS SR4.0, MSS SR4.1, M14.6, M15.0, M15.1,
Phase 1 and Phase 2 :SGs interface for SMS and CSFB
Including MTRR (Mobile Terminating Roaming Retry and MTRF (Mobile

Terminating Roaming Forwarding, SR5.0)
1 © Nokia Siemens Networks

Background information about the feature

Circuit Switched Fall Back (CSFB) in nutshell
2G/3G Coverage area
LTE data coverage areas
Voice calls over CS

eNodeB
LTE UE
LTE UE
Enable superior LTE data rates while keeping the existing

2G/3G user’s experience.

CS Fallback for EPS in M14.6 and M15.0
Two-phased approach in NSN MSC Server system
• In the first phase SMS support is required in order to re-use existing services also
when using LTE access
 Data-oriented devices in LTE network
 Mobile originated and terminated SMS
 Use cases:
• Prevention of ”roaming bill shock” – EU legislation
• SMS communication between network and USIM application
• Delivering textual content to end user using mobile broadband data service
• Pre-paid topping
• Etc.
 M14.6 product release (MSS SR4.0)
• In the second phase more complete CS Fallback for EPS functionality is planned to
be introduced
 Voice-oriented devices in LTE network
 In addition to previous phase: Voice/Video call, location services, USSD and supplementary service
control
 Use cases:
• Emergency and priority calls
• Providing voice service while using LTE when roaming outside HPLMN
• Mobile terminated location enquiry
• USSD communication
• Supplementary service control (if Ut is not used)
 M15.0 product release (MSS SR4.1)

CS Fallback for EPS - Phase 1 (M14.6)
SMS delivery using SGs interface
• Nokia Siemens Networks’ CS fallback features in MME, MSC server and LTE eNB support
• SMS delivery over the LTE system (possible even without voice support as the initial phase of
solution)
• Introduction in data-only LTE deployments and perhaps in early phase with high frequency bands
NAS signalling Simultaneous LTE

transports SMS data and SMS
between the UE sending/receiving!
and the MME
MME
Laptop with SAE GW Internet
LTE data card
LTE radio
network
Data Operator
MSS IP network
Devices without Control plane
CS voice support interface
execute specific (SGs) to
”sms-only” enable SMS
attachment to over LTE
network

SMSC
CS Fallback for EPS - Phase 2 (M15.0)
Complete CS Fallback support
• More complete support for voice/video calls, SMS, USSD, LCS and
Supplementary service control
• Fallback for voice connections to 2G and 3G networks
• Data connection continued in target radio access (UTRAN/GERAN*)
MME support for

CS voice paging
(SMS as in previous
phase)
Laptop with MME

LTE data card
SAE GW
LTE radio
LTE voice- network
oriented device
Data Operator
MSS IP network
Control plane
interface
(SGs) to
enable CSFB ISUP
*) Depending for LTE SIP-I
on availability of PSTN/
SMSC BICC
DTM PLMN
CS Fallback for EPS
Functionality End-to-End
• Functionality
– Fallback for voice connections to 2G and 3G networks
– CSFB enables LTE introduction as a data only type of network in the beginning and makes the initial
LTE investments smaller.
– Handling of the emergency calls in early phase (LTE Emergency Call in 3GPP Release 9)
– Handling of the network roamers with LTE terminal when IMS roaming agreement not in the place yet.
– SMS delivery over the LTE system (possible even without voice support as the initial phase of solution)
Note late change for 3GPP Rel8 to support SMS delivery in more enhanced way with CSFB. Also
further improvements in 3GPP Rel9 planned to further enhance CSFB
Voice calls SMS
The terminal switches The terminal stays in

to 3G or 2G LTE where the SMS is
received or sent
LTE 3G 2G LTE

Dedicated
MSS MSS Existing MSS
CS Fallback for EPS LTE SMS

MSS network elements
Deployment view
Phase 1: SMS via SGs interface (M14.6) Phase 2: CS Fallback for EPS (M15.0)
HLR SMSC
HLR SMSC
MAP MAP
MSS MSS
MSS MSS
MSS
VLR
MSS VLR
MSS
VLR VLR
SGs SGs
SGs SGs SGs SGs
MME MME MME MME MME MME
SMS support can be Full CSFB support

introduced to a few introduced to these
MSS in the network MSSs that cover
(note: Roaming same geographical
networks need area than MMEs
support as well) (Note: MT roaming
retry procedure)

SMS over SGs in nutshell
• SMS over SGs enables

operator to deploy LTE but
also offer SMS service for
LTE attached UEs
• UE supporting SMS over
SGs procedure will inform Transparent SMS payload
core network in Evolved
Packet System (EPS)
attach phase by using
combined IMSI/EPS attach
procedure
• Evolved Packet Core
(EPC) will invoke location
update to selected
MSS/VLR via SGs
interface
• MO/MT SMS is transferred
via SGs interface within
Non-Access Stratum
signalling (NAS)

SGs interface
Overview
• SGs is SCTP based

interface between MME and
MSS/VLR
• SGs can consists of one or
multiple single -or
multihomed SCTP
associations
• It is established based on
configuration and is
maintained as long as
endpoints are up and
running
• SGs associations are
established as logical
connection between MME
and VLR via SGs by using
SGsAP protocol messages
• SGsAP is application part
that consists of messages
and information elements as
defined by 3GPP TS 29.118

SGs related IP connectivity solution for DX and
Open MSS
• Generic IP connectivity solution is described in system release
documentation updated per each system release
– Site Connectivity Guidelines, DN0582196
– DX MSS: Site Connectivity Configuration for MSS, DN0968207 (from M14.6
onwards)
– Open MSS: Site Connectivity Configuration for Open MSS, DN0988347 (from
M16.0 onwards)
• Nokia Siemens Networks has designed and documented generic IP site
solution in order to verify and ensure the resiliency and performance of
MSC Server system when integrated into IP infrastructure
• Additionally generic IP site solution enables Nokia Siemens Networks to
provide better support to help in IP related problems when faults can be
replicated in Nokia Siemens Networks premises
• Both MSC Server and MGW products are covered by site solution

Integrated MSC Server (DX MSS) site solution
• Each signalling unit is
internally cabled to two
integrated LAN Switch units
in MSC Server
– This ensures protection e.g.
against LAN switch failures
• Each integrated LAN switch
units are respectively
connected to external
Multilayer Switches in site
(One or Two)
• Nokia Siemens Networks
MSC Server can either
provide Layer 2 or 3
connection to site solution
– Layer 3 is separately
obtainable optional feature
requiring ESB26-A L3 LAN
units to MSC Server in
addition to L2 LAN switches
• Each traffic type is separated
by using Virtual LANs
(Control, O&M, Charging and
LI/OLCM)
• This is generic solution
(customer specific solutions
may exists that need to be
handled case by case)

Physical view of SGs interface in MSC Server
• SGs interface is located in BSU When SGs is
functional units in DX MSS and configured to use
in GISU functional units in Open SCTP multihomed
MSS. SCTP, then paths
association
• BSU units are connected to are routed via
internal LAN switching units as separate physical
described in previous slide equipments
• M14.6, M15.0 and M16.0:

Maximum of ten SCTP
associations can be configured SGs
for SGs association towards
each MME (to BSUs or GISUs).
•
M15.1 and M16.1: The max
number of SCTP associtions
extended to 64 SCTP
associations.
• DiffServ Code Point (DSCP) can
be set for SGsAP traffic to be
same as for other control plane
IP traffic (PRFILE parameter
53:9)
• Control plane related Virtual LAN
(VLAN) can be used for SGs
traffic
Primary path
Secondary path
IP configuration of BSU functional unit (DX MSS)
• SGs related BSUs need to have two
IPv4 addresses for multihomed SCTP SWU
traffic (IP_A, IP_B) for primary and
secondary paths
– SGs traffic is sent via primary path
but in case of failure then
secondary path will be activated
– Alarm will be set in case of failure BSU
• IP addresses are attached to
individual Ethernet ports IP_A Eth0
• IP addresses needs to be allocated
from different IP subnets SGs
• BSU will execute VLAN tagging and IP_B Eth1
setting of DSCP for SGs interface
traffic
• BSUs acting as SCTP server for SWU
SGs interface will use SCTP port
number 29118 and payload
protocol id 0
• Single BSU can handle multiple SCTP
associations related to different SGs
associations
• BSU handles the individual streams
within SCTP associations
• Note. With Open MSS (ATCA), GISU
unit is used instead of BSU to
terminate SGs IF.

SGs association and related SCTP association
configuration xSU-0
xSU=BSU (DX MSS)
• In M14.6, M15.0 and xSU=GISU (Open MSS)
M16.0: SGs association
can be divided into 1 or SCTP association 1
maximum of 10 SCTP
associations (1.. 64 streams)
• In M15.1 and M16.1: with
xSU-1
PDC09970, SGs
association can be divided SGs association
into 1 or maximum 64
SCTP associations.
• All SCTP associations
within SGs association are
connected to same VLR VLRUs xSU-2
• Multiple streams are
supported within each
SCTP association
• MSS is able to balance load
of single SGs association
across all configured SCTP xSU-3
associations in round-robin MME
manner
• It is recommended that
MME is able to load
balance in similar fashion
when multiple SCTP
associations are used in
SGs association
• At the moment IPDU unit xSU-n SCTP association n
cannot be used to load (1.. 64 streams)
balance SGs interface
traffic (SGsAP LB target is
M17.0)

Recommendations for SGs interface configuration
• Multi homed SCTP associations should be used for SGs associations

instead of single homed configuration
• Number of needed BSU/GISU functional units depends on amount of SGs
traffic but should be at least two BSU/GISUs / MME (for resiliency
purposes)
• Number of needed IP addresses for BSU/GISUs may need to be taken
into account when planning the configuration
• VLAN configuration for SGs traffic should be aligned with control plane
VLAN configuration
• Multiple streams per SCTP association should be used to gain benefits
from use of SCTP (default = 16 streams/SCTP association; maximum is
64 streams/SCTP association)
• IP addresses configured for primary and secondary paths of same SCTP
association should be allocated from different IP subnets in order to
ensure that
• Local IP based default gateway configuration can be used to simplify
routing configuration of MSS

SGs interface
SCTP configuration
• Nokia Siemens Networks SCTP implementation based on

RFC2960.
• Detailed configuration of SCTP associations used in SGs
interface:
– CRC32 checksum recommended
– Multihomed SCTP association recommended
– Ordered delivery mode supported only
– Symmetrical number of streams within SCTP association supported
only
 Number of streams / SCTP association is configurable
– IPv4 only (IPv6 planned in later releases)
– Values for RTO.init, RTO.min, RTO.max, SACK.period,
PATH.max.retrans, ASSOCIATION.max.retrans and HB.interval are
configurable per SCTP association based on IP planning

SGs interface
SCTP configuration
• RTO.Min
– RTO.Min can be configured per SCTP association basis.
– Value range is 10ms - 2 s
– Default value of RTO.Min parameter is 150 ms.
• RTO.Max
– RTO.Max can be configured per SCTP association basis.
– Value range is 10ms – 2 min
– Default value of the RTO.max parameter is 200 ms.
• RTO.Initial
– RTO.Initial can be configured per SCTP association basis.
– Value range is 10 ms – 60 s
– Default value of the RTO.Initial is 3s
• HB.Interval
– HB.Interval can be configured per SCTP association basis.
– Value range is 100ms – 300s
– Default value is 30s

SGs interface
SCTP configuration
• SACK period (10-500ms from your previous email.)

– SACK period can be configured per SCTP association basis.
– Value range is from 10 ms to 500 ms.
– The default value of the SACK period is 200 ms.
• Association.Max.Retrans
– Association.Max.Retrans can be configured per SCTP association basis.
– Value range is 1-15
– Default value of Association.Max.retrans is 10
• Path.Max.Retrans
– Path.Max.Retrans can be configured per SCTP association basis.
– Value range is 1-15
– Default value of Path.Max.retrans is 5
• Bundling support
– Bundling support can be configured per SCTP association basis.
– Default value of this parameter is “Yes” meaning that bundling is used.

Radio network configuration recommendations
• NSN recommends that LTE (4G) Location Areas are

separated from 2G/3G Location Areas. The recommendation
is e.g. for the following reasons:
 MSS pooling concept requires that LTE (4G) Location Areas are separated
from 2G/3G Location Areas.
 CSFB capable LTE terminal behaviour. If the 2G/3G and LTE(4G) uses
overlapping Location Areas, and if the CSFB is made to same MSS/VLR in
which the LTE terminal is registered, the SGs association remains active in
MSS/VLR after CSFB is made. It causes for a short time period after CSFB
call is ended, that the LTE terminal is not reachable via SGs interface 
CSFB capable LTE terminal seems NOT to listen LTE (4G) radio while
camping in 2G/3G radio.  So every MT call BEFORE the LTE terminal
makes new Location Update or returns to listen LTE radio, will fail. If the
2G/3G and LTE (4G) Location Areas would be separated, LTE terminal
would be forced to initiate Location Update procedure always when changing
the radio access from 2G/3G to LTE (4G) or vice versa. Summary: with this
concept, LTE terminal would be always reached in the current location
without any delay.

Related MML

Modified MML
GSM Network and Network Element Specific Number

Handling, WV Command Group
GPRS Network Handling, EJ Command Group

ZWVF - possible to change VLRFQDN
MODIFY NETWORK AND NETWORK ELEMENT SPECIFIC
NUMBER
A new parameter VLR FQDN address (VLRFQDN) has been

added to the execution printout text in MSC. The change is
related to feature/PDC: FN1914/PDC 7425
A new optional name-defined parameter VLR FQDN address
(VLRFQDN) has been added to the first parameter block in
MSC. The new VLRFQDN value is given as third parameter
in the position-defined second parameter block.
New syntax:WVF:VLRFQDN=<VLRFQDN>:,,<new
VLRFQDN value>; The command still works with the old
syntax. The change is related to feature/PDC:
FN1914/PDC7425
Possible values for VLRFQDN are text characters with up to
100 character given within quotation marks.
(EJ) GSNHAN - GPRS Network Handling
B CREATE MME CONFIGURATION - Feature(s): 1914

G MODIFY MME CONFIGURATION - Feature(s): 1914
Y DELETE MME CONFIGURATION - Feature(s): 1914
J OUTPUT MME CONFIGURATION - Feature(s): 1914
N HANDLE MME PARAMETER SET DATA - Feature(s):
1914
I INTERROGATE MME PARAMETER SET DATA -
Feature(s): 1914

ZOYX - Configuring the SGs interface
Create the SCTP association with the OYX command.

With this command, you can create the SCTP association between the
MSS/VLR and the MME for the SGs interface.
ZOYX:MME1:SGSAP:S:BSU,0:SGS:16;
MME1 :SCTP association name

SGSAP :User part for the SCTP association
S :Server role
BSU,0 :Unit identification
SGS :Parameter set
16 :Stream count of the SCTP association can have values of 1 - 64.
The recommended value is 16 - it is the default.
NOTE:A new parameter set can be created using the OYE command.

New MML parameter
Measurement Handling, T2 Command Group
Use the commands in this command group to handle statistical
measurements and statistical object lists.
The command group has been updated to include a measurement ID for
SGsAP SCTP measurement statistics.
(SCTP connections created with ZOYX are measured)
VLR and PLMN Parameter Handling, MX Command Group

Use the commands of the command group to define the settings of VLR and
PLMN operations. You can display and modify VLR-specific and PLMN-
specific parameters.
The retry and MME-search related parameters introduced in Phase 2 are
only visible if the Full CSFB support in SGs interface license has been set
to CONFIG or ON.
• MXN :modify PLMN parameters.
• MXP :display the current parameter values of one PLMN.

ZMXP - PLMN PARAMETERS
VISITOR PLMN MIDDLEEARTH IN NATIVE COUNTRY
INDEX: 8
CIPHERING: USED
TRIPLET RE-USE: USED
EMLPP DEFAULT PRIORITY LEVEL: NOT USED SUPPORT OF EMLPP: YES
COUNTRY CODE LENGTH: 3 NO RESPONSE EFFECT: ALLOW
MSRN GROUP: 02 BLACK LIST EFFECT: BLOCK
MSRN LIFE TIME: 75 SEC. GREY LIST EFFECT: TRACE
PNS TIME LIMIT: 20 SEC. UNKNOWN IMEI EFFECT: ALLOW
TRAFFIC TERMINATION ON CANCEL LOCATION: MOC, MTC, SS AND SMS
TERMINATED
SUPPORTED CAMEL PHASE: PHASE 4
PSI PAGING: ALLOWED
FRAUD OBSERVATION AND LIMITATION: USED
REGIONAL ROAMING: ALLOWED
ZONE CODES: F209 F20A F20B 0010 0011 0012 1C00 1C01
ZONE CODES FROM HLR: USED
EXACT MS CATEGORY USAGE: ALLOWED
TRIGGER SM TO NTMS: NOT ALLOWED
SUPPORT OF BOR: NOT ALLOWED
SUPPORT OF CNAP: NOT ALLOWED
USAGE OF PLMN SPECIFIC SS 253: NOT SUPPORTED
CS/PS COORDINATION REQUIRED: NO
PRE-PAGING SUPPORTED: NO
IGNORE CLIR FROM HLR: N
ACCESS RESTRICTION BY BS30: NO
NBR OF FETCHED VECTORS IF NONE AVAIL.: 2
ANY TIME INTERROGATION DELAY TIME: 100 (1000 MSEC)
----------------------------------------------------------------------
ADVICE OF CHARGE PARAMETERS
E1: 1,5 E2: 11,7 E3: 7,50

any time interrogation delay time, upon CSFB to other
MSS <option>
With this parameter you can set the time of delay before the
VLR sends an any time interrogation towards the HLR, when
a psi paging through the SGs interface caused that the
targeted LTE subscriber executed a CS Fallback to a
different MSS/VLR.
The time of delay can be set in 10 millisecond units, between
the range of 0 to 2000, hence the set delay time can range
from 0 to 20 seconds.
The parameter name is ATIDLY.

ZMXO - VLR PARAMETERS
TMSI: USED
IMPLICIT IMSI DETACH: USED
AUTHENTICATION: USED
AUTHENT RETRY: USED
TMSI AUTHENT RETRY: NOT USED
SECURITY KEY LIFETIME 2G: 10 MIN
SECURITY KEY LIFETIME 3G: 15 MIN
EMERGENCY CALL: AUTHENT NOT USED IMEI CHECKING NOT USED
ALLOW CCBS WHEN UDUB: YES
ALLOW CCBS WHEN CFB ACTIVE: NO
ALLOW LOCATION UPDATE WHILE SCP UNAVAILABLE: YES
ALLOW GAPPING IN IN-MM: NO
…
PAGE AND SEARCH
LIMIT FOR SIMULTANEOUS SEARCHES: 100
NUMBER OF SEARCH REPETITIONS: 2
SEARCH RESPONSE WAITING TIME: 1000 MSEC.
TMSI PAGE REPETITION IN MT CALL: USED
TMSI PAGE REPETITION IN MT SMS: USED
TMSI PAGE REPETITION IN MT USSD: USED
TMSI PAGE REPETITION IN MT LR: USED
MME SEARCH FOR MME SUBSCRIBERS: USED
PSI PAGING OVER SGS INTERFACE: MTLR
PSI PAGING ON LOCATION REQUEST: USED
……

ZMXM - new Parameter MMESRC
MME search for MME subscribers <option>

With this parameter you can enable performing an MME search when the
following criteria are met:
the subscriber's location area information is not available in the VLR (for
example, after a VLR restart)
a terminating non-SMS transaction is received
If the MMESRC parameter value is Y, the VLR allows the sending of paging
messages towards all the connected MMEs (that is, MME search over the
SGs interface) in parallel with the normal A/Iu interface searches in order
to find the subscriber.
The MME search over the SGs interface might significantly increase the
interface load.
The parameter can have the following values:
MMESRC Y MME search is enabled

N MME search is disabled

ZMXM - new Parameter PSIPGT
PSI paging support over SGs interface <option>

With this parameter you can define how the VLR sends a PSI
paging request through the SGs interface if a PSI request
arrives from the HLR to an LTE-associated subscriber. If this
parameter is set to NONE, the PSI request targeting an LTE
subscriber will not be forwarded, but the subscriber will be
assumed idle, and the appropriate answer will be sent to the
HLR. In other cases, the approprite cause code and the
required data will be forwarded.
PSIPGT NONE No PSI paging over SGs interface
CSC Circuit Switched Call
MTLR Mobile Terminated Location Request
NISS Network Initiated Supplementary
Service

ZMXM - new Parameter SGSPNL
allow PSI paging over SGs interface, when only location is

requested <option>
With this parameter you can define whether to start PSI paging
targeting an LTE subscriber when the paging request from
the HLR contains location identification, but no current
location is requested.
SGSPNL Y Allow PSI over SGs at location requests
without current location request
N Current location request needed for PSI
over SGs

ZMVO SUBSCRIBER INFORMATION:
INTERNATIONAL MOBILE SUBSCRIBER IDENTITY ...... 262030284280000
TEMPORARY MOBILE SUBSCRIBER IDENTITY .......... N
ACTIVATION STATUS ............................. A
MOBILE STATION CATEGORY ....................... OR
EXACT MOBILE STATION CATEGORY ......... UNK
ROUTING CATEGORY .............................. N
ADDITIONAL ROUTING CATEGORY ................ N
MOBILE COUNTRY CODE ........................... 0262D
MOBILE NETWORK CODE ........................... 0003D
LOCATION AREA CODE OF IMSI .............. 0AFAH/02810D
RADIO ACCESS INFO ............................. LTE
MOBILE NOT REACHABLE FLAG ..................... N
HLR FAILURE FLAG .............................. N
SUPPLEMENTARY SERVICE CHECK FLAG .............. N
IMSI DETACH FLAG .............................. N
DETACH CAUSE ..................................
LAST ACTIVATE DATE ............................ 01-13 11:46
LAST USED CELL ID ............................. N
HLR-ADDRESS ................................... 49177148
SECURITY CONTEXT TYPE.......................... UNK
INTELLIGENT NETWORK MOBILITY MANAGEMENT:
SCP ADDRESS ................................... N
DETECTION POINT NAME .......................... N
SERVICE KEY ................................... N
TRANSACTION TYPE .............................. N
INTELLIGENT NETWORK SHORT MESSAGE SERVICE:
SCP ADDRESS ................................... N
DETECTION POINT NAME .......................... N
SERVICE KEY ................................... N
TRIGGERING ALL MULTIPLE MESSAGES .... N
COMPLETION OF CALL TO BUSY SUBSCRIBER:
ORIGINATING CCBS .............................. N
TERMINATING CCBS .............................. N
CCBS MONITORED ................................ N
SUBSCRIBER FRAUD OBSERVATION:
NUMBER OF CALL TRANSFERS ...................... 0
NUMBER OF OBSERVATION ACTIVATIONS ............. 0
NUMBER OF SAMPLING PERIOD ..................... 0
SIMULTANEOUS CALL TRANSFER IN PROGRESS ........ 0
Continue ZMVO
FRAUD DETECTION AND LIMITATION:
TIME LIMIT OF MO CALLS ........................ DEF
ACTION PARAMETER FOR MO CALLS ................. DEF
TIME LIMIT OF CF CALLS ........................ DEF
ACTION PARAMETER FOR CF CALLS ................. DEF
TIME LIMIT OF CT CALLS ........................ DEF
ACTION PARAMETER FOR CT CALLS ................. DEF
MAX. NUMBER OF CT INVOCATIONS ................. DEF
ACTION PARAMETER FOR CT INVOCATIONS ........... DEF
ZONE CODES:
EMLPP PRIORITY INFORMATION:

EMLPP MAXIMUM ENTITLED PRIORITY................ N
EMLPP DEFAULT PRIORITY......................... N
SGSN ADDRESS .................................. N
CONFIRMED RADIO CONTACT VIA SGSN .............. N
MME PRIMARY IP ADDRESS .... 10.85.21.45
MME FQDN .................. mmec12.mmecgi23.mme.epc.mnc03.mcc262.3g
VLRU IDENTITY ................................. 0
MOBILE SUBSCRIBER INTERNATIONAL ISDN NUMBER ... 491774280000
MOBILE SUBSCRIBER ALTERNATE LINE SERVICE MSISDN
BASIC SERVICES:
T11 T21 T22
MULTISIM INFO:
OWN MSISDN .................................... N
SUPER-CHARGER:
AGE INDICATOR (HEX).............................N
SUPER-CHARGER STATE.............................ACTIVE
VLR UPDATE COUNTER..............................000
PLMN UPDATE COUNTER.............................000
COMMAND EXECUTED

New Alarms

Alarms
1346 SGSAP PROTOCOL DATA MISSING

In Phase 1, the alarm is introduced to handle scenarios where an information
element
is missing from the SGs interface message (SGsAP protocol) or an unknown SGsAP
message is received from the MME.
3293 SCTP PRIMARY PATH NOT AVAILABLE

In Phase 1, the alarm has been modified to incorporate the SGs interface related
changes.
3575 NO RETRY PROCEDURE SUPPORT

In Phase 2, the alarm is introduced to handle scenarios and is set when a Cancel
Location is received for a subscriber who is paged over the SGs interface, so MTRR
should be executed but RoamingRetry IE was not received in PRN for the same call.
For more information on these alarms, consult the Reference Information Services
portal in the NOLS Documentation Center

Feature presentation & scenarios in which
SGs interface is being used

Use cases of feature, SMS over SGs IF, phase 1
• Combined EPS/IMSI Attach Procedure

• Combined TA/LA Update Procedure
• Successful Paging Procedure in MT-SMS
• Unsuccessful Paging Procedure in MT-SMS- reject cause different from
UE-unreachable
• Unsuccessful Paging Procedure in MT-SMS- reject cause is UE-
unreachable
• Alert Procedure
• Explicit IMSI Detach for EPS Services
• Explicit IMSI Detach from non-EPS Services
• Implicit IMSI Detach from non-EPS Services
• VLR Failure Procedure
• MME Failure Procedure
• HSS/HLR Failure Procedure
• MM Information Procedure
• SMS Tunnelling Procedure (MO-SMS, MT-SMS)

Combined EPS/IMSI Attach Procedure
• This use case occurs
when UE attaches
into EPS by using
combined EPS/IMSI
attach procedure
• MME in EPC will
authenticate user and
finally execute
location update to MAP Update location
MSS/VLR via SGs MAP Update location ack

interface
• HLR is updated
normally in order to
fetch subscription
data as well as enable
proper routing of
terminating SMS Note: UE may use either ”SMS only” or
”CSFB” type of combined IMSI/EPS attach.

Combined TA/LA Update Procedure
• This use case occurs when
UE moves within EPS and
Tracking Area change
causes need to perform
Location Update change
towards MSS/VLR
– MME may change but
MSS/VLR stays same
– MME may change and
MSS/VLR changes as well
– TA/LA change occur under
same MME but different MAP Update location
MSS/VLR (note)
– TA/LA change occur under MAP Update location ack
same MME and same
MSS/VLR (note)
• In this case VLR performs TAU Request Accept
usual LU procedures with
exceptions:
– The user is not
authenticated.
– The IMEI check is not
executed. However, if the
IMEI is received from the
MME in the SGsAP-
LOCATION-UPDATE- Note: MME may not support more than one
REQUEST message, then
its status is checked from LAC for SMS over SGs use.. Depends on
the EIR.
– Ciphering is not started
implementation.

Successful Paging Procedure in MT-SMS
• When the UE is
paged, the MSS/VLR
sends a SGsAP-
PAGING-REQUEST
message indicating
paging reason to be
”SMS” over the SGs
interface
• As a paging response,
an SGsAP-SERVICE-
REQUEST message
over the SGs-
interface is received
when paging
succeeds
• If the response is
received, the VLR
stops the timer Ts5

Unsuccessful Paging Procedure in MT-SMS- reject cause
different from UE-unreachable
an SGsAP-PAGING-
REJECT message is
received with cause
different from UE-
unreachable (i.e. UE is
e.g. IMSI detached)
• In this case VLR stops
the timer Ts5, moves the
SGs association to SGs-
NULL and stores the
cause value received in
the message to the
association data
• Alert procedure is not
invoked in this case due
the fact that MME should
re-perform LU instead of
alert indication (need for
this waits more field
experience if Alert
needed in the future)

Unsuccessful Paging Procedure in MT-SMS- reject cause is
UE-unreachable
an SGsAP-PAGING-
REJECT message is
received with cause UE-
unreachable (i.e. UE is
unreachable from
MME’s point of view)
• The VLR stops the timer
Ts5 and the paging
procedure is stopped.
The SGs association
state is not affected in
the VLR but the MNRF UE-Unreachable or
flag is set for the
subscriber
• The MSS then executes See Alert procedure
the Alert Procedure
towards the MME for this
subscriber in order to
trigger MME to inform Note: MME may indicate that UE is unreachable
MSS/VLR when UE is by using either paging reject with UE-unreachable
again reachable cause or by using SGsAP-UNREACHABLE message

Alert Procedure
• With the Alert Procedure, the
VLR can request a report from
the MME about any activity of
the UE (even when the SGs
state is SGs-NULL).
• The VLR sends a SGsAP-
ALERT-REQUESTmessage to
the MME and starts the timer
Ts7.
• The alert indication is received
in a SGsAP-UE-ACTIVITY-
INDICATION message, or if
the UE’s signaling procedure
triggers VLR-related
procedures in the MME then UE is active within EPS
the request message of that
procedure is received. SGs
association state is not
affected by the SGsAP-UE-
ACTIVITY-INDICATION
message.
• If the MNRF flag is set for the
UE in the VLR, the
Ready_for_SM is sent to the
HLR when the SGsAP-UE-
ACTIVITY-INDICATION
message is received from the
MME. MNRF flag is cleared.

Explicit IMSI Detach for EPS Services
• The MME uses this
procedure to indicate
that the SGs
association of the UE
is removed as the UE
becomes IMSI
detached from EPS
services
Detach Request
• The MME sends a
SGsAP-IMSI-
DETACH-
INDICATION
message to the VLR Detach Accept
• The VLR responds
with a SGsAP-
DETACH-ACK
message and moves
the SGs association
to SGs-NULL.

Explicit IMSI Detach from non-EPS Services
• If the UE is indicating
IMSI detach or
combined EPS/IMSI
detach the MME shall
send an SGsAP-IMSI-
DETACH-INDICATION
message to the VLR
indicating
– "Explicit UE initiated
IMSI detach from non-
EPS service" Detach Request
– "Combined UE initiated
IMSI detach from non-
EPS services“
• The VLR answers with a
SGsAP-DETACH-ACK
message and changes Detach Accept
the SGs association of
the UE to SGs-NULL.
• The UE record is then
handled according to
preconfigured rules
(supercharger rules and
purging)

Implicit IMSI Detach from non-EPS Services
• The MME uses this
procedure to signal to
the VLR that the SGs
association is removed.
• This procedure is
triggered for instance
when UE is no longer
within radio coverage For instance out of radio
and has not executed coverage
periodical TAU
• The MME sends the
request with the
indication "Implicit MME
initiated IMSI detach
from non-EPS service".
• The VLR also sends a
SGsAP-IMSI-DETACH-
ACK message to the
MME that sent the
message.
• The UE record is then
handled according to
preconfigured rules
(supercharger rules and
purging).

VLR Failure Procedure
• If an event in the VLR
results in SGs Association
data loss, the VLR sets the
SGs association state to
SGs-NULL for every
involved UE
• If the VLR restarts, the
SGsAP-RESET-
INDICATION message is
sent to all the MMEs to
which the VLR established
SCTP associations and
starts the timer Ts11 and
waits for a response
• The MME responds with
the SGsAP-RESET-ACK
message and when the
response is received, the
VLR stops the timer Ts11

MME Failure Procedure
• When a failure in the
MME leads to the loss
of SGs association data
for the UEs, the MME
sends a SGsAP-
RESET-INDICATION
message to every VLR
that has SCTP
association established
with the MME over the
SGs interface.
• The SGs association
state for the affected
UEs is not changed.
• The VLR sends a
SGsAP-RESET-ACK
message to the MME.

HSS/HLR Failure Procedure
• When the MME
receives the HSS Reset
indication via S6a, the
MME implicitly sets
NEAF (Non-EPS Alert
Flag) for the UEs that
are affected by the HSS
Reset and that have
SGs association.
• When a UE from this set
performs any signaling
traffic to the MME, the
MME reports this to the
VLR according to the
normal Alert Procedure
(SGsAP-ACTIVITY-
INDICATION)

MM Information Procedure
• The MM Information Procedure
can be initiated by the VLR
only if the SGs association
state for the UE is SGs-
ASSOCIATED.
• The VLR sends an SGsAP-
MM-INFORMATION-
REQUEST in order to start the
procedure.
• This procedure is used to
transfer Network Information &
Time Zone (NITZ) information
to UE, if configured so in
MSS/VLR
• If the NITZ feature is active,
then after the finished attach
procedure the VLR sends the
NITZ info to the MME by using
the MM Information procedure
over the SGs interface
• Sending the NITZ info can be
controlled by FIFILE
parameter,
SUPR_NITZ_INFO_ON_SGS

SMS Tunnelling Procedure (MO-SMS, MT-SMS)
MO SMS:
• In the MO-SMS case, the UE sends the
SMS Message in a NAS message to
the MME.
• The MME forwards this NAS message
inside a SGsAP-UPLINK-UNITDATA
message to the MSS.
• The next steps apply the normal SMS
delivery logic as specified in 3GPP
23.040. The delivery report is
transparently sent from the MSS to the
MME in a SGsAP-DOWNLINK-
UNITDATA message.
MT SMS:
• In the MT-SMS case, the MSS sends a
paging request containing the SMS
indicator over the SGs interface
• The MSS sends the MT-SMS inside a
SGsAP-DOWNLINK-UNITDATA
message to the MME.
• The MME sends the delivery report to
the MSS in a SGsAP-UPLINK-
UNITDATA message.
Note: Message flows show only use of

SGsAP messages and not complete
SMS transfer message sequence.

Use cases of CSFB LTE feature, Full CSFB over
SGs IF, phase 2
• MO Call- GERAN/UTRAN cell and SGs association in E-UTRAN are controlled by the same
MSS
• MO Call- GERAN/UTRAN cell and SGs association in E-UTRAN are controlled by different
MSS
• Successful MT Call- Paging Response is received from UE
• Successful MT Call- Location Update is received from UE
• Successful MT Call- MT Roaming Retry is executed
• Successful MT Call- Pre-paging Request in PRN
• MT Call- Subscriber Data is not available in VLR
• Mobile Initiated Call-Independent Supplementary Service Procedure
• Network-Initiated Call Independent Supplementary Service Procedure
• Mobile Initiated Location Request Procedure
• Mobile Terminated Location Request Procedure
• Simultaneous MO Transaction and SMS Delivery
• Simultaneous MT Transaction and SMS Delivery
NOTE: phase 1 use cases are applicaple and preassumption for

phase 2 !

MO Call- GERAN/UTRAN cell and SGs association in
E-UTRAN are controlled by the same MSS
Precondition: The UE is
attached to EPS and non-
EPS services- the SGs
association state is SGs-
ASSOCIATED in the VLR.
Procedure:
1. The UE initiates CS
Fallback for MO Call purpose
by sending an Extended
Service
Request with CS Fallback
indication to the MME.
2. The MME instructs
E-UTRAN to initiate the move
of the UE to GERAN/UTRAN.
3. When the UE is
successfully camped on a
GERAN/UTRAN cell, the UE
sends a CM Service Request
to the MSS.
From this point, the call
establishment procedure is
identical to a standard CS MO
Call.
Note. If the LA changes

during CSFB, the MO-call is
started with LU procedure
before sending CM Service
Request (MO Call)!

MO Call- GERAN/UTRAN cell and SGs association in
E-UTRAN are controlled by different MSS
Precondition: The UE is attached

to EPS and non-EPS services- the
SGs association state is SGs-
Procedure:
1. The UE initiates CS Fallback for
MO Call purpose by sending an
Extended Service Request with
CS Fallback indication to the
MME.
2. The MME instructs E-UTRAN to
initiate the move of the UE to
GERAN/UTRAN.
3. When the UE is successfully
camped on a GERAN/UTRAN cell,
a Location Update is triggered as
the LAI of the cell is different than
the one stored on the UE. The LA
belongs to MSS2.
4. When the UE is successf.
registered in MSS2, it sends the
CM Service Request. From this
point, the call establishment
procedure is identical to a
standard CS MO Call.

Successful MT Call- Paging Response is received from UE
Precondition: The UE is attached to EPS and non-
EPS services- the SGs association
state is SGs-ASSOCIATED in the VLR.
Procedure:
1. An MT call arrives in the MSS/VLR for the
subscriber. The MSS/VLR sends an
SGsAP-PAGING-REQUEST to the MME indicating
that paging is for a CS Call. The Calling Line Identity
(CLI) is included in the request. Optionally, if eMLPP
is used in the call, the eMLPP information is sent.
2. If the UE is idle, the MME initiates a paging
procedure. If the UE is not idle or the paging is
successful, the MME sends an SGsAP-SERVICE-
REQUEST to the MSS/VLR.
3. The MSS/VLR handles the SGsAP-SERVICE-
REQUEST as an intermediate paging response.
The paging timer is stopped and a new timer is
started to supervise the final paging response from
the terminating subscriber.
4. If the subscriber accepts the call, the UE
changes access and camps on a GERAN/UTRAN
cell. In this use case, the location area of the
GERAN/UTRAN cell is the same as the one stored
in the UE so the UE sends the Paging Response to
the MSS.
5. From this point, the call establishment procedure
is identical to a standard CS MT Call.
Note: the use of MTRR can be reduced by using

multipoint A/Iu interface functionality in
conjunction with SGs interface.

Successful MT Call- Location Update is received from UE
Precondition: The UE is attached to EPS and non-
EPS services- the SGs association state is
SGs-ASSOCIATED in the VLR.
Procedure:
1. An MT call arrives in the MSS/VLR for the
subscriber. The MSS/VLR sends an
SGsAP-PAGING-REQUEST to the MME indicating
that paging is for a CS Call. The CLI is included in
the request. Optionally, if eMLPP is used in the call,
the eMLPP information is sent.
2. If the UE is idle, the MME initiates a paging
procedure. If the UE is not idle or the paging is
successful, the MME sends an SGsAP-SERVICE-
3. The MSS/VLR handles the SGsAP-SERVICE-
REQUEST as an intermediate paging response.
The paging timer is stopped. Also, a new timer is
started to supervise the final paging response from
the terminating subscriber as the subscriber may
have the option to decide at this point whether to
accept the call or not.
4. If the subscriber accepts the call, the UE changes
access and camps on a GERAN/UTRAN cell. In this
use case, the location area of the GERAN/UTRAN
cell is different from the one stored in the UE or the
UE cannot determine the location area of the
current cell so the UE initiates a Location Update
procedure.
5. As the result of a successful Location Update, the
SGs association state changes to SGs-NULL. The
MSS/VLR keeps the signaling connection used for
Location Update open and uses this connection for
further call setup procedures. From this point, the
call establishment procedure is identical to a
standard CS MT Call.

Successful MT Call- MT Roaming Retry is executed

Successful MT Call- Pre-paging Request in PRN
Precondition: The UE is attached
to EPS and non-EPS services-
the SGs association state is SGs-
ASSOCIATED in the VLR. The
HLR supports PRN pre-paging.
Procedure:
1. An MT call arrives in the GMSS
for the subscriber. The GMSS
executes an HLR inquiry for the
calling party by sending an SRI to
the HLR. The HLR includes pre-
paging request into the PRN,
either because it was received
from the GMSS in the SRI or
based on HLR’s own decision.
2. The MSS/VLR does not
execute pre-paging when the
PRN with pre-paging request is
received and the subscriber
should be paged over the SGs
interface. Paging over the SGs
interface would initiate a possibly
long procedure of CS Fallback,
which may risk that the PRN timer
in the HLR would expire and the
call would be cleared due to that
reason. The situation could be
even worse if the MTRR would be
triggered as the result of CS
Fallback in this phase, as we
have a pending PRN procedure in
the HLR. The MSS/VLR handles
this PRN as a PRN without pre-
paging request, and from this
point the call is handled as a
normal MT Call with CS Fallback
functionality, as defined in use
cases Successful MT Call-
Location Update is received from
UE and Successful MT Call- MT
Roaming Retry is executed.

MT Call- Subscriber Data is not available in VLR
Precondition: MSS/VLR does not know the subscriber but VMSS address in HLR points
to this MSS/VLR.
Procedure:
1. An MT call arrives to the MSS/VLR for the subscriber. The MSS/VLR does not have
the subscriber data (for example, due to a VLR restart).
• If the Feature 1881: VLR Backup is not activated, the MSS/VLR can restore subscription
data from the HLR only, which means that MME Name is not restored.
In this case, the MSS/VLR executes a Search procedure over the A, Iu and SGs
interfaces simultaneously. Search over the SGs interface means that the
MSS/VLR sends an SGsAP-PAGING-REQUEST to all the MMEs to which it has
connections. The execution of Search procedure over the SGs interface is configurable
with VLR parameter MMESRC.
Note: The Search procedure is only applicable in non-SMS scenarios.
• If the Feature 1881: VLR Backup functionality is activated, the MSS/VLR can
restore the MME Name information from the backup server and can send an
SGsAP-PAGING-REQUEST to that particular MME. If the paging fails over the
SGs interface, the MSS/VLR executes a Search procedure over the A and Iu
interfaces.
2. If the UE is found, the call establishment continues as in a standard MT Call with CS
Fallback.
Note:If the paging is rejected, the MSS/VLR handles the situation according to its own ‘UE not
reachable’ rules. That is, if the service is activated for the subscriber, Call Forwarding
Not Reachable is executed.
Note:If the call is rejected by the called party, the MSS/VLR handles the situation according
to its own ‘Busy’ rules. That is, if the service is activated for the subscriber, Call Forwarding
Busy is executed.
Note:If the search or the paging is successful over the SGs interface, that is, the SGsAPSERVICE-
REQUEST is received from MME but subscriber does not accept the call, the
UE does not perform a CS Fallback and the paging accept timer expires in the
MSS/VLR. In this case the call will be released.

Mobile Initiated Call-Independent Supplementary Service
Procedure
Precondition: The UE is attached to EPS and non-EPS services- the SGs association
state is SGs-ASSOCIATED in the VLR.
Procedure:
1. The UE performs CS Fallback as described in use cases MO Call- GERAN/UTRAN
cell and SGs association in E-UTRAN are controlled by the same MSS and MO Call-
GERAN/UTRAN cell and SGs association in E-UTRAN are controlled by different
MSS.
2. The UE performs the Mobile Initiated Call-Independent SS procedure after it has
successfully camped on a GERAN/UTRAN cell.

Network-Initiated Call Independent Supplementary Service
Procedure
Precondition: The UE is attached to
EPS and non-EPS services- the
SGs association state is SGs-
Procedure:
1. The Network Initiated Call
Independent Supplementary
Service procedure is triggered in the
MSS/VLR. The MSS/VLR sends an
SGsAP-PAGING-REQUEST to the
MME with an SS Code. The value
of the SS Code is read from the
configurable PRFILE parameter
SS_CODE_IN_LTE_PAGING.
2. If the UE is idle, the MME initiates
a paging procedure. If the UE is not
idle or the paging is successful, the
MME sends an SGsAP-SERVICE-
3. The MSS/VLR handles the
SGsAP-SERVICE-REQUEST as an
intermediate paging response. The
paging timer is stopped and a new
timer is started to supervise the final
paging response from the
terminating subscriber. The value of
this new timer is read from the
PRFILE parameter
PAGING_ACCEPT_TIMER.
4. The UE changes access and
camps on a GERAN/UTRAN cell. If
the target cell is handled by the
MSS/VLR which has initiated the
paging then the NW-Initiated Call
Independent SS operation is
executed.

Mobile Initiated Location Request Procedure
Precondition: The UE is attached to EPS and non-EPS services

the SGs association state is SGs-ASSOCIATED in the VLR.
Procedure:
1.The UE performs CS Fallback as described in MO Call 1 and
2.
2.The UE performs the Mobile Initiated Location Request
procedure after it has successfully camped on a GERAN/
UTRAN cell.

Mobile Terminated Location Request Procedure
Precondition: The UE is attached to
EPS and non-EPS services- the SGs
association state is SGs-ASSOCIATED
in the VLR.
Procedure:
1. A Mobile Terminated Location
Request procedure is triggered in the
MSS/VLR by receiving the Provide
Subscriber Location request. The
MSS/VLR sends an SGsAPPAGING-
REQUEST to the MME with LCS Client
ID.
2. If the UE is idle, the MME initiates a
paging procedure. If the UE is not idle
or the paging is successful, the MME
sends an SGsAP-SERVICE-
3. The MSS/VLR handles the SGsAP-
SERVICE-REQUEST as an
intermediate paging response. The
paging timer is stopped and a new
timer is started to supervise the final
paging response from the terminating
subscriber. The value of this new timer
is read from the PRFILE parameter
PAGING_ACCEPT_TIMER.
4. The UE changes access and camps
on a GERAN/UTRAN cell. If the target
cell is handled by the MSS/VLR which
has initiated the paging then the NW-
Initiated Call Independent SS operation
is executed.
Note:If the GERAN/UTRAN cell is
served by a different MSS, the paging
and the operation fail. There is no
MTRR-like operation for this use case.
Note:The UE may response to the
paging with a Location Update request
as well, like in an MT Call case.

Simultaneous MO Transaction and SMS Delivery
• Procedure:
If the UE performs CS Fallback while sending or receiving an
SMS, the SMS delivery fails. It is expected that the SMSC (in an
MT SMS case) or the UE (in an MO SMS case) take care of the
re-transmission of the SMS.

Simultaneous MT Transaction and SMS Delivery
• Precondition: The UE is attached to EPS and non-EPS

services- the SGs association state is SGs-ASSOCIATED in the
VLR. SMS is delivered to/from the UE over the SGs interface.
• Procedure:
An MT activity arrives to the MSS/VLR. The MSS/VLR sends an
SGsAP-PAGINGREQUEST to the MME over the SGs interface,
while an SMS delivery is still ongoing. The UE performs CS
Fallback as in the MT use cases described above. As a
consequence, the SMS delivery fails. It is expected that the
SMSC (in an MT SMS case) or the UE (in an MO SMS case)
take care of the re-transmission of the SMS.

CSFB feature items in M15.1 & MSS SR4.1

M15.1 & MSS SR4.1 – Support for MME element
with multiple hosts for SGs interface
•Supporting more flexible configuration method in SGs interface.
FC010163/PDC09970: Support for MME element with multiple hosts for
SGs interface. The following three (3) slides shows all the supported
configuration models having BSU (DX MSS) or GISU (Open MSS)
connectivity with SGs interface in MSS side.
• The SCTP associations are terminated in the BSU/GISU units. One
MME host and one BSU/GISU unit form a single SCTP association. The
MSS/VLR supports a maximum of 64 SCTP associations per between
one MME and one MSS/VLR.

M15.1 & MSS SR4.1 – Support for MME element with
multiple hosts for SGs interface, example model 1
MME MSS
Unit-0 xSU-0
SCTP association 0
Unit-1 xSU-1 VLR
Unit-2 xSU-2
…
Unit-n xSU-n

MME MSS
Unit-0 xSU-0
SCTP association 0
Unit-1 xSU-1 VLR
SCTP association 3
Unit-2 xSU-2
SCTP association 4
…
Unit-n xSU-n
SCTP association 7

MME MSS
xSU-0
Centralized unit
xSU-1 VLR
xSU-2
…
xSU-n

M15.1 & MSS SR4.1 - CSMT flag
Due to misalignments in E-UTRAN and GERAN/UTRAN it may happen that the UE falls back to
an MSS which is not the one that started the paging over SGs. This is the famous MTRR
situation, i.e. the call is released back to the GMSS and re-routed from there to the new MSS.
The UE executes Location Update procedure when it returns to a new MSS. In basic cases the
MSS releases the signaling connection to the UE once the LAU procedure is finished and there
is no other transaction related to the UE (for example incoming call or SMS).
Once the signaling connection is released, the UE may return anytime to the E-UTRAN
MTRR re-routing of the call from GMSS happens only after the Update Location procedure
between the new MSS and the HLR is finished, because HLR shall delay the processing of new
MAP SRI until the UL procedure is finished
Consequently, the call is re-routed from GMSS to the new MSS only after the Location Update
procedure is finished  the UE may return to E-UTRAN which means that the call will fail
CSMT flag is to overcome this situation. When a Rel9 compliant UE executes LAU after CSFB,
the UE sets the CSMT flag in the LAU Request. It is an indication for the new MSS that the LAU
is due to CSFB, and the MSS will keep the signaling connection to the UE after the LAU
procedure is finished, so the re-routed call can arrive to the new MSS before the UE could
return to E-UTRAN
Benefits are:
•better call success rate: the introduction of CSMT flag increased the call success rate from
10% to 100% at AT&T in MTRR situations
•lower call setup time: as the signaling connection is kept to the UE, there is no need for paging
in the new MSS

M15.1 & MSS SR4.1 – CSMT flag in action

M15.1 & MSS SR4.1 - Re-paging over A/Iu interface
• The UE may move in idle mode in the network so, that it goes to
GERAN/UTRAN without performing LAU to the MSC Server, because its
registered LAI remains the same during the movement. On top of this if Idle
Mode Signaling Reduction is not active, the UE will be removed from MME
when it moves to GERAN/UTRAN. As a consequence of these, the SGs
association state in the MSS is still SGs-ASSOCIATED, so the MSS will start
paging on the SGs interfcae.
• The paging over SGs will fail in this case, obviously. MME rejects the
request with “IMSI detached from EPS services” cause.
• The enhancement here is that MSS shall re-page the UE over A/Iu if such
paging rejection is received from the MME
• On top of the standard functionality, it is configurable in MSC Server for
which SGs cause values we execute re-paging on A/Iu interface

M15.1 & MSS SR4.1 - CSFB Overlay MSS support 1/4

•Overlay architecture for CSFB is required in order to introduce support for

CSFB without causing any significant impact (beyond e.g. routing
configurations or charging modifications to name a few) to existing mobile
CS core network.
• Overlay architecture means that a few MSC Servers, possibly running
different software release than in use within other MSC Servers/MSCs in
network, are introduced in order to provide SGs interface towards EPS.
SGs interface in this way is kind of centralized in similar fashion for complete
CSFB than it was originally possible for short message service over
LTE/SGs in the first phase.
• Use of such overlay architecture enables the possibility to introduce CSFB
also into multivendor circuit switched core network architecture where it is no
longer feasible/possible to introduce SGs interface or Mobile Terminating
Roaming Retry (MTRR) functionality into existing legacy MSCs serving
GERAN/UTRAN.

• As can be seen from the previous figure of MSS Overlay, MSC Server
having SGs interface towards MME is connected to HLR, MME and
remaining parts of circuit switched core networks by using existing signalling
interfaces (MAP, ISUP/BICC/SIP-I as well as SGs interface).
• MME will perform the location update to selected MSC Server as result of
combined IMSI/EPS attachment initiated by terminal. Selection logic for MSC
Server (SGs interface) is MME-dependent issue but it can be based on e.g.
mapping of Location Area (MSS/VLR) from currently used Tracking Area
(known by MME). No un-standardized mechanisms are needed in MME
because of overlay architecture.
• MSC Server acting as overlay SGs entity need to be configured with radio
access configuration that contains those Location Areas that can be used by
those MMEs which are connected to MSC Server via SGs (see slide 2). This
configuration is performed by using existing radio access network
configuration management of MSC Server. In case location areas are not
known by MSC Server in overlay architecture then location update via SGs
interface will be rejected.

Supported CSFB feature functionalities
• SMS over SGs interface

– Short messages service in overlay architecture is rather straightforward functionality.
Short messages are delivered via overlay MSC Server without performing any fallback to
legacy MSC/MSC Server architecture (GERAN/UTRAN).
• CSFB support for CS voice calls over SGs interface

– CS voice calls require that terminal performs CS fallback to GERAN/UTRAN for duration
of call. The CS fallback is performed always when paging is successfully performed via
SGs interface (MT voice call) or terminal itself initiates the voice call (MO voice call), the
rest of the signaling will use the existing 2/3G access network resources
Not supported CSFB feature functionalities
– USSD & MT-LR in overlay architecture 3GPP has not defined procedures to support
change of core network element, namely MSC Server for either network initiated USSD or
Mobile Terminating Location Request procedures according 3GPP TS 23.272. This
means that in overlay MSC Server architecture those procedures terminated to overlay
MSC Server when served subscriber has SGs association will be eventually considered
as failed paging due reception of MAP CANCEL LOCATION.

M15.1 & MSS SR4.1 – Pre-MTRF (1/3)
Pre-MTRF procedure (NSN proprietary solution, 3GPP based MTRF takes places in Md16.1 EP1)
An MT call is routed to the overlay MSS according to the standard call routing procedures.
Pre-MTRF procedure is executed in the overlay MSS.
When the UE performs fallback, the overlay MSS starts the LAU procedure to the
MSS/VLR with A/Iu interface. As a result, a MAP Send Identification is received from the
new VMSS or MAP Cancel Location request is received from the HLR. This way, the
overlay MSS is informed that the UE has performed CSFB to the new VMSS.
The overlay MSS also recognizes that MTRR is not supported by the GMSS/HLR as the
MTRR IE is not received in the PRN during MT call routing. The overlay MSS sends SRI
to the HLR to obtain MSRN from the new VMSS of the UE. When the MSRN is received,
the overlay MSS routes the call to the new VMSS.
The call rerouting from the overlay MSS to new VMSS is a special call forwarding. Pre-
MTRF procedure reuses the existing call forwarding framework of the MSS.
The cause for forwarding is transferred to the new leg and it is input for the attribute
analyses (IN, Routing, EOS, Service) and Extended Preanalysis.
Pre-MTRF procedure is independent from the call forwarding counter. The procedure is
not blocked by the maximum number of CF and it does not modify the value of the call
forwarding counter. Also, it does not require the activation of any standard CF service
for the subscriber. An optional PRFILE parameter controls routing delay in Pre-MTRF
scenarios.

M15.1 & MSS SR4.1 – Pre-MTRF (2/3)
Pre-MTRF procedure and IN services
IN services on the MTRF leg are managed, that is, suppressed or triggered, with an
optional PRFILE parameter. Therefore, any IN trigger can be restricted in the overlay
MSS.
IN services received from the HLR in the SRI response can also be suppressed by Attribute
Analysis. If IN services are not suppressed, the overlay MSS may send the original
CAMEL Call Reference in the IDP to the SCP together with the new VMSS address, so
the SCP would recognize the VMSS change for the same call and the SCP may release
the call if subscriber is not allowed to receive calls in that MSS/location. The overlay
MSS can also generate new CAMEL Call Reference for the SRI and the IDP.
If the overlay MSS uses the original CAMEL Call Reference in the SRI and if the VMSS
based IN service is triggered in the new VMSS, the SCP can correlate the GMSS and
VMSS services based on the CAMEL Call Reference.

M15.1 & MSS SR4.1 – Pre-MTRF (3/5)
Pre-MTRF procedure and IN services, continues…
DP Terminating Attempt Authorized based VMSS IN services are triggered in the

overlay MSS before paging starts over the SGs interface. DP Terminating Attempt
Authorized based VMSS IN services are aborted when rerouting is started by reporting
DP T-Abandon to the SCP. The originating IN services of the called party are also suppressed
on the Pre-MTRF leg. Even if Pre-MTRF is a type of call forwarding procedure,
the originating IN services of the called party are never triggered on the Pre-MTRF leg.
Note: If IN services are not suppressed with the possible configuration described above, the
same IN services can be triggered twice in one call– in the GMSS and in the overlay
MSS. This may cause problem in SCP.

M15.1 & MSS SR4.1 – Pre-MTRF (4/5), with MAP Cancel
Location procedure
Overlay MSS/ MSS/VLR w/ A/
HLR UE
VLR Iu interface
UE is registered for non-EPS services, MT Call comes to the UE. UE performs CS Fallback to a different MSS
Location Update Request
Update Location started
MAP Cancel Location
Optional timer is run to

delay routing to new
MSS
MAP SRI MAP PRN

Location Update Ack
MAP PRN Res(MSRN)
MAP SRI Res (MSRN)
IAM(MSRN)
Normal MT Call setup procedure over A/Iu

interface

M15.1 & MSS SR4.1 – Pre-MTRF (5/5), with MAP Send
Identification procedure
Overlay MSS/ MSS/VLR w/ A/
HLR UE
VLR Iu interface
UE is registered for non-EPS services, MT Call comes to the UE. UE performs CS Fallback to a different MSS
Location Update Request
MAP Send Identification
MAP Send Identification Res
Update Location started
Optional timer is run to

delay routing to new
MSS
MAP PRN
Location Update Ack
MAP PRN Res(MSRN)
IAM(MSRN)
Normal MT Call setup procedure over A/Iu

interface

Next future release planned items related to CSFB
SGsAP Load Balancer (IPDU)
EMB xSU-0
SCTP association 1
Primary
paths xSU-1
IPDU-0
xSU-2
SCTP association 2
xSU-3
xSU-4
IPDU-1
Secondary …
paths
xSU-n
IPDU is N+1
redundant LinDX Ethernet port (EL4 / EL5)
based unit.
Few words about CSFB and Packet Core
data connection interworking

CS fallback with data continuity in the
UTRAN/Geran 1/2
CSFB to UTRAN has two mobility options from EPC CSFB to GSM has three options from EPC perspective:
perspective: • No PS HO support
• No PS HO support (CSFB with RRC Connection • CSFB with RRC Connection Release with redirect –
Release with redirect) NGMN recommendation
• PS HO supported – NGMN recommendation • inter RAT cell change order with NACC
• PS HO supported
Mobile receives
MT call paging
over LTE access
MME
S/P-GW Data
B services
Data over LTE

LTE SGs
MSS
CS call paging
A over SGs
interface Data
UTRAN Voice
Geran Signaling
CS fallback with data continuity in the
UTRAN/Geran 2/2
When UE has been moved to UTRAN/Geran access it:
• It completes CS call setup for voice call
• It makes Routing area update (RAU) to continue data transfer
In both cases PS data services continue:

• in the UTRAN access simultaneously to voice call when 3G RAN has multi RAB support (available in all networks)
• In the Geran access simultaneously to voice call when 2G RAN has Dual Transfer Mode (DTM) support
Without DTM support PS services are suspended and PS session(s) are stored in the MME and SGW
MME
S/P-GW Data
services
Network LTE
redirects SGSN
mobile to Data
3G/2G continues
access over
MSS
Utran/Geran
B
Voice call
A over CS
WCDMA access Data
Geran Multi RAB or Voice
DTM Signaling
87 © Nokia Siemens Networks supported
MTRF – Mobile Terminating Roaming
Forwarding (SR 5.0)
FN 2028 requires FN1914 CSFB feature active

MTRF - Mobile Terminating Roaming Forwarding
FN 2028
Must be used together with CSFB concept to have faster call

setup process
CSFB update
Feature 1914: CSFB now 0-99 SGs interfaces could be
configured (old 0-49) MML - ZEJB

Software
The standard Mobile Terminating Roaming Forwarding (MTRF)

functionality requires support in the new Visited MSS, while the HLR’s
supporting the functionality is optional.
In Nokia Siemens Networks’ solution, it is possible to configure the network
elements so that MTRF is successful with only one MSS (with SGs
interface) supporting the MTRF functionality.
To use the MTRF feature, the following optional functionalities of Feature
1914: CS Fallback in EPS for MSS are required with the corresponding
licenses activated:
• Phase 1 - SMS support in SGs interface: FEA1691 capacity license
• Phase 2 - Full CS Fallback support in SGs interface: FEA1935 On/Off
license
MTRF support in the MSS is an optional functionality that is controlled with
the “MTRF support in MSC Server" FEA4302 On/Off license and the
MTRF PLMN parameter.

Mobile Terminating Roaming Forwarding (MTRF)
Challenge:
• MTRR requires call rerouting back to GMSS resulting lot of signaling traffic
• In roaming scenarios MTRR support is required both from home and visited PLMN
Solution:
• MTRF eliminates signaling between VMSS (visited network in case of roaming) and
GMSS (home network in case of roaming)
• HLR support for MTRF is optional
• Works for inbound roamers without difficulties
• MTRF is 3GPP standard solution
Operator benefits
MTRF support in MSS provides the following benefits:
• Faster call setup time in CSFB compared to cases when MTRR is used
• Simplify roaming support in CSFB situations

Mobile Terminating Roaming
Forwarding (MTRF)
Data MME
Functionality: SAE GW
1.) Incoming call to MSS-old triggers CSFB
2.) The UE is paged over SGs interface and
UE initiates location update procedure to LTE
the MSS-new Fallback
CS
3.) MSS-new sends MAP SendIdentification voice
SGs
2 MSS-new
to inform the MSS-old that MTRF is
supported
4.) MSS-new performs location update to 4
HLR which cancels subscription from 2G/3G 6 5
MSS-old
5.) MSS-new allocates MSRN and provides 3
it to MSS-old as response to provide MSS-old 1
roaming number request
6.) MSS-old routes the call directly to MSS-
new
Support required (e2e viewpoint):

• Both old and new MSS-es in serving PLMN need to support MTRF
• If TMSI is used in location update, HLR support is not needed; in case IMSI is used, HLR
support required
Benefit
This feature increases the success rate of certain MT calls in CS Fallback cases
when the UE switches MSSs during the transaction, and the call is to be routed to
a different MSS from the one that started the paging over the SGs interface.
The MTRF functionality ensures rerouting the call to the new Visited MSS of the UE
even without MTRF support in the called party’s HPLMN.
The MTRF functionality can be used together with PRN pre-paging. Together with the
PRN pre-page support over SGs interface enhancement, the call can be routed
directly from the GMSS to the new VMSS at a very early phase of the call setup.
In such cases the whole MTRF procedure is performed by the VLR of the old
VMSS, and the old VMSS does not reserve either MGW or call-related resources.

MTRF procedure with pre-paging support for CS
Fallback

The procedure is as follows:
• The GMSS sends a MAP SendRoutingInfo (SRI) message to the HLR to

obtain the roaming number in the usual way.
The HLR sends the MAP ProvideRoamingNumber (PRN) message with pre-
paging support towards the VLR of the old VMSS.
• As pre-paging is supported, the VLR already pages the UE at this phase
over the SGs interface instead of allocating the MSRN. From this point,
paging and CSFB is performed in the same way as described in section
MTRF procedure for CS Fallback.
•

Procedure cont.
When the MAP CancelLocation message arrives, the VLR of the old VMSS
relays the received MAP ProvideRoamingNumber request to the VLR of
the new VMSS thus acting as the HLR. When the pre-paging indicator is
set, and the CSMT flag is supported in both the UE and the new VMSS,
the new VMSS does not need to perform the pre-paging as the radio
channel is kept reserved because of the CSMT flag. The benefit of these
steps is that when IAM is received in the new VMSS, the paging has
already been executed.
• The roaming number is allocated by the new VMSS and returned to the old
VMSS in a PRN response, which is then relayed to the HLR.
Consequently, the call is routed directly from the GMSS to the new VMSS
based on the allocated roaming number.

IMPORTANT about the procedure
The following facts have to be taken into consideration related to pre-paging:

• Depending on the UE implementation, the subscriber might have the possibility to
decide whether to accept or reject the call when being paged over the SGs
interface. Therefore, at pre-paging phase the SRI response time can be enlarged
in the GMSS if the PRN pre-page over SGs interface functionality is used. During
this time, the calling party does not hear any tones or announcements, that is, the
UE is silent.
• After pre-paging over the SGs interface, when the received SRI is forwarded as
PRN towards the VLR in the VMSS, the PRN response timer value can be
maximum 30 sec on the MAP interface according to the standards (specified in
subclause 17.6.3 of 3GPP TS 29.002: Mobile Application Part (MAP) specification
/11/).
– This means that during this 30 sec, the following operations have to be performed:
 the UE-B has to be pre-paged
 the subscriber has to decide whether or not to accept the call
 MTRF has to be executed if needed (which involves the subscriber’s being prepaged again in the VLR of the new
VMSS)
– As a result, if the subscriber has the possibility to decide whether to accept the call during pre-paging,
there is maximum about 20-25 sec for the decision.

VLR and PLMN Parameter Handling, MX Command
Group
After activating the required licenses, you have to set the MTRF parameter of the
MXN MML command to value Y to activate the feature.
The execution printout of the MXP command shows whether or not MTRF is used.
The following parameters of the MXM command are relevant to the feature:
RDELAYSI This timer defines MT call rerouting delay after a MAP
SendIdentification message has been received.
RDELAYCLO This timer defines MT call rerouting delay after a MAP
CancelLocation message has been received.
FORCESIMTRF With this parameter you can force the MTRF execution at MAP
Send- Identification, independently from the MTRF information elements‘
presence.
ROAMPREF With this parameter, you can set the priority order for the
different MT call rerouting functionalities.
The execution printout of the MXO command contains all these parameters of the
MXM command.

Different rerouting options
MT call rerouting is needed in certain cases when the UE switches MSSs during a
mobile-terminating transaction due to the CS Fallback procedure. There have
been several solutions for MT call rerouting implemented by Nokia Siemens
Networks.
The following functionalities are offered:
• Mobile Terminating Roaming Retry (MTRR)
• Nokia Siemens Networks proprietary MTRF solution (Pre-MTRF)
• standardized Mobile Terminating Roaming Forwarding (MTRF)
The operator can set the priority order of these solutions to define in which order
these functionalities are tried to be used when MT call rerouting is needed.
The main difference between the solutions is in the way of call rerouting and, as a
consequence, in the requirements for different network elements’ supporting the
functionalities.

Interworking of SMS over SGs and Full
CSFB with other features

Interworking with features
• Network Information & Time Zone

– NITZ information can be delivered to LTE attached UE via SGs (note
geographical time zone alignments)
• Lawful Interception (OLCM/LAES/SORM)
– LI can be supported for LTE attached SGs if IMEISV is received from MME
• Multipoint A / IuCS interface
– MSS/VLR may embed Network Resource Identifier (NRI) within TMSI provided
to UE via SGs in Location Update accept (Note)
– Note: This is different than Multipoint in SGs interface (MME feature)
• Super charger
– VLR may withhold subscription information despite UE being served by other
VLR  Recommended feature to be used
• VLR Backup
– Key content of VLR is backed up into external database, which can be restored
in case of VLR failure (=> Enables traffic handling capability of MSS to resume
faster)
– Without this feature in case VLR has been restarted but HLR still points to that
VLR then MT SMS will fail until next mobile originating TA/LA update/attach

CSFB LTE Feature Training PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSFB LTE Feature Training PDF

Uploaded by

Copyright:

Available Formats

FN1914, CSFB LTE feature training

MSS SR4.0, MSS SR4.1, M14.6, M15.0, M15.1,

Phase 1 and Phase 2 :SGs interface for SMS and CSFB

Including MTRR (Mobile Terminating Roaming Retry and MTRF (Mobile

1 © Nokia Siemens Networks

2 © Nokia Siemens Networks

LTE data coverage areas

Voice calls over CS

Enable superior LTE data rates while keeping the existing

3 © Nokia Siemens Networks

4 © Nokia Siemens Networks

NAS signalling Simultaneous LTE

5 © Nokia Siemens Networks

MME support for

Laptop with MME

Voice calls SMS

The terminal switches The terminal stays in

7 © Nokia Siemens Networks

CS Fallback for EPS LTE SMS

MME MME MME MME MME MME

SMS support can be Full CSFB support

8 © Nokia Siemens Networks

• SMS over SGs enables

9 © Nokia Siemens Networks

• SGs is SCTP based

10 © Nokia Siemens Networks

11 © Nokia Siemens Networks

12 © Nokia Siemens Networks

• M14.6, M15.0 and M16.0:

14 © Nokia Siemens Networks

15 © Nokia Siemens Networks

• Multi homed SCTP associations should be used for SGs associations

16 © Nokia Siemens Networks

• Nokia Siemens Networks SCTP implementation based on

17 © Nokia Siemens Networks

18 © Nokia Siemens Networks

• SACK period (10-500ms from your previous email.)

19 © Nokia Siemens Networks

• NSN recommends that LTE (4G) Location Areas are

20 © Nokia Siemens Networks

21 © Nokia Siemens Networks

GSM Network and Network Element Specific Number

GPRS Network Handling, EJ Command Group

22 © Nokia Siemens Networks

A new parameter VLR FQDN address (VLRFQDN) has been

B CREATE MME CONFIGURATION - Feature(s): 1914

24 © Nokia Siemens Networks

Create the SCTP association with the OYX command.

MME1 :SCTP association name

25 © Nokia Siemens Networks

VLR and PLMN Parameter Handling, MX Command Group

26 © Nokia Siemens Networks

27 © Nokia Siemens Networks

28 © Nokia Siemens Networks

29 © Nokia Siemens Networks

MME search for MME subscribers <option>

MMESRC Y MME search is enabled

30 © Nokia Siemens Networks

PSI paging support over SGs interface <option>

31 © Nokia Siemens Networks

allow PSI paging over SGs interface, when only location is

32 © Nokia Siemens Networks

EMLPP PRIORITY INFORMATION: