Вы находитесь на странице: 1из 101

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

2 Nokia Siemens Networks


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 users experience.

3 Nokia Siemens Networks


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)

4 Nokia Siemens Networks


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

5 Nokia Siemens Networks


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
6 Nokia Siemens Networks
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

7 Nokia Siemens Networks


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)

8 Nokia Siemens Networks


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)

9 Nokia Siemens Networks


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

10 Nokia Siemens Networks


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

11 Nokia Siemens Networks


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)

12 Nokia Siemens Networks


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
13 Nokia Siemens Networks
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.

14 Nokia Siemens Networks


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)

15 Nokia Siemens Networks


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

16 Nokia Siemens Networks


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

17 Nokia Siemens Networks


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

18 Nokia Siemens Networks


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.

19 Nokia Siemens Networks


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.

20 Nokia Siemens Networks


Related MML

21 Nokia Siemens Networks


Modified MML

GSM Network and Network Element Specific Number


Handling, WV Command Group

GPRS Network Handling, EJ Command Group

22 Nokia Siemens Networks


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.
23 Nokia Siemens Networks
(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

24 Nokia Siemens Networks


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.

25 Nokia Siemens Networks


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.

26 Nokia Siemens Networks


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

27 Nokia Siemens Networks


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.

28 Nokia Siemens Networks


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

29 Nokia Siemens Networks


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

30 Nokia Siemens Networks


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.
The parameter can have the following values:
PSIPGT NONE No PSI paging over SGs interface
CSC Circuit Switched Call
MTLR Mobile Terminated Location Request
NISS Network Initiated Supplementary
Service

31 Nokia Siemens Networks


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.
The parameter can have the following values:
SGSPNL Y Allow PSI over SGs at location requests
without current location request
N Current location request needed for PSI
over SGs

32 Nokia Siemens Networks


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
33 Nokia Siemens Networks
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

34 Nokia Siemens Networks


New Alarms

35 Nokia Siemens Networks


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

36 Nokia Siemens Networks


Feature presentation & scenarios in which
SGs interface is being used

37 Nokia Siemens Networks


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)

38 Nokia Siemens Networks


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.

39 Nokia Siemens Networks


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.

40 Nokia Siemens Networks


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

41 Nokia Siemens Networks


Unsuccessful Paging Procedure in MT-SMS- reject cause
different from UE-unreachable
As a paging response,
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)

42 Nokia Siemens Networks


Unsuccessful Paging Procedure in MT-SMS- reject cause is
UE-unreachable
As a paging response,
an SGsAP-PAGING-
REJECT message is
received with cause UE-
unreachable (i.e. UE is
unreachable from
MMEs 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

43 Nokia Siemens Networks


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 UEs 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.

44 Nokia Siemens Networks


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.

45 Nokia Siemens Networks


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)

46 Nokia Siemens Networks


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).

47 Nokia Siemens Networks


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

48 Nokia Siemens Networks


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.

49 Nokia Siemens Networks


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)

50 Nokia Siemens Networks


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

51 Nokia Siemens Networks


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.

52 Nokia Siemens Networks


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 !

53 Nokia Siemens Networks


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)!

54 Nokia Siemens Networks


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-
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,
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.

55 Nokia Siemens Networks


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.

56 Nokia Siemens Networks


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-
REQUEST to the MSS/VLR.
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.

57 Nokia Siemens Networks


Successful MT Call- MT Roaming Retry is executed

58 Nokia Siemens Networks


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 HLRs 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.

59 Nokia Siemens Networks


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.

60 Nokia Siemens Networks


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.

61 Nokia Siemens Networks


Network-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 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-
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. 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.

62 Nokia Siemens Networks


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.

63 Nokia Siemens Networks


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-
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. 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.

64 Nokia Siemens Networks


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.

65 Nokia Siemens Networks


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.

66 Nokia Siemens Networks


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

67 Nokia Siemens Networks


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.

68 Nokia Siemens Networks


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

69 Nokia Siemens Networks


M15.1 & MSS SR4.1 Support for MME element with
multiple hosts for SGs interface, example model 2

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

70 Nokia Siemens Networks


M15.1 & MSS SR4.1 Support for MME element with
multiple hosts for SGs interface, example model 3

MME MSS
xSU-0

Centralized unit
xSU-1 VLR

xSU-2


xSU-n

71 Nokia Siemens Networks


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

72 Nokia Siemens Networks


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

73 Nokia Siemens Networks


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

74 Nokia Siemens Networks


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

75 Nokia Siemens Networks


M15.1 & MSS SR4.1 - CSFB Overlay MSS support 2/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.

76 Nokia Siemens Networks


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

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.

77 Nokia Siemens Networks


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

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.

78 Nokia Siemens Networks


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.

79 Nokia Siemens Networks


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.

80 Nokia Siemens Networks


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.

81 Nokia Siemens Networks


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

82 Nokia Siemens Networks


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

83 Nokia Siemens Networks


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.
84 Nokia Siemens Networks
Few words about CSFB and Packet Core
data connection interworking

85 Nokia Siemens Networks


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
86 Nokia Siemens Networks
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

88 Nokia Siemens Networks


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

89 Nokia Siemens Networks


Software

The standard Mobile Terminating Roaming Forwarding (MTRF)


functionality requires support in the new Visited MSS, while the HLRs
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.

90 Nokia Siemens Networks


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

91 Nokia Siemens Networks


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
92 Nokia Siemens Networks
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 partys 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.

93 Nokia Siemens Networks


MTRF procedure with pre-paging support for CS
Fallback

94 Nokia Siemens Networks


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.

95 Nokia Siemens Networks


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.

96 Nokia Siemens Networks


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 subscribers 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.

97 Nokia Siemens Networks


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.

98 Nokia Siemens Networks


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.

99 Nokia Siemens Networks


Interworking of SMS over SGs and Full
CSFB with other features

100 Nokia Siemens Networks


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

101 Nokia Siemens Networks