02_CSFB LTE Feature Training

1 © Nokia Siemens Networks

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)


Background information about the feature


Circuit Switched Fall Back (CSFB) in nutshell

2G/3G Coverage area

LTE data coverage areas

Enable superior LTE data rates while keeping the existing

2G/3G user’s experience.

Voice calls over CS

LTE UE LTE UE

eNodeB


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

Internet

LTE radio network

MME SAE GW

Operator IP network MSS Data

Laptop with

LTE data card

SMSC

NAS signalling transports SMS between the UE and the MME

Control plane interface (SGs) to

enable SMS over LTE

Simultaneous LTE data and SMS sending/receiving!

Devices without CS voice support execute specific

”sms-only” attachment to

network


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

PSTN/

PLMN

LTE radio network

MME SAE GW

Operator IP network

LTE voice-

oriented device

MSS Data

Laptop with

LTE data card

SMSC

Control plane interface (SGs) to

enable CSFB for LTE

MME support for CS voice paging (SMS as in previous phase)

ISUP SIP-I BICC

*) Depending on availability of DTM


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

2G 3G LTE

The terminal switches to 3G or 2G

SMS

LTE

The terminal stays in LTE where the SMS is

received or sent


CS Fallback for EPS Deployment view

MME

MSS MSS MSS

MME MME

SGs SGs

VLR

HLR

MAP

SMSC

MSS

Dedicated LTE SMS MSS MSS Existing MSS

network elements MSS

VLR

SGs

MME MME

SGs SGs

VLR

HLR

MAP

SMSC

SGs

MSS MSS MSS VLR

MME

SMS support can be introduced to a few MSS in the network

(note: Roaming networks need support as well)

Full CSFB support introduced to these

MSSs that cover same geographical

area than MMEs

(Note: MT roaming retry procedure)

Phase 1: SMS via SGs interface (M14.6) Phase 2: CS Fallback for EPS (M15.0)


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

Transparent SMS payload


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 functional units in DX MSS and in GISU functional units in Open MSS.

• BSU units are connected to internal LAN switching units as described in previous slide

• M14.6, M15.0 and M16.0: Maximum of ten SCTP associations can be configured 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

SGs

When SGs is configured to use

multihomed SCTP, then paths

are routed via separate physical

equipments

SCTP association

Primary path

Secondary path


IP configuration of BSU functional unit (DX MSS)

• SGs related BSUs need to have two IPv4 addresses for multihomed SCTP 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

• IP addresses are attached to individual Ethernet ports

• IP addresses needs to be allocated from different IP subnets

• BSU will execute VLAN tagging and setting of DSCP for SGs interface traffic

• BSUs acting as SCTP server for 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.

BSU

IP_A

IP_B

Eth0

Eth1

SGs

SWU

SWU


SGs association and related SCTP association configuration

• In M14.6, M15.0 and M16.0: SGs association can be divided into 1 or maximum of 10 SCTP associations

• In M15.1 and M16.1: with PDC09970, SGs association can be divided into 1 or maximum 64 SCTP associations.

• All SCTP associations within SGs association are connected to same VLR

• Multiple streams are supported within each SCTP association

• MSS is able to balance load of single SGs association across all configured SCTP associations in round-robin 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 cannot be used to load balance SGs interface traffic (SGsAP LB target is M17.0)

xSU-0

xSU-1

xSU-n

MME

SGs association

SCTP association n (1.. 64 streams)

VLRUs xSU-2

xSU-3

SCTP association 1 (1.. 64 streams)

xSU=BSU (DX MSS) xSU=GISU (Open MSS)


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



• 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



• 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 MSS/VLR via SGs interface

• HLR is updated normally in order to fetch subscription data as well as enable proper routing of terminating SMS

MAP Update location

MAP Update location ack

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 MSS/VLR (note)

– TA/LA change occur under same MME and same MSS/VLR (note)

• In this case VLR performs 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-REQUEST message, then its status is checked from the EIR.

– Ciphering is not started

Note: MME may not support more than one LAC for SMS over SGs use.. Depends on

implementation.

MAP Update location

MAP Update location ack

TAU Request Accept


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


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 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 flag is set for the subscriber

• The MSS then executes the Alert Procedure towards the MME for this subscriber in order to trigger MME to inform MSS/VLR when UE is again reachable

Note: MME may indicate that UE is unreachable by using either paging reject with UE-unreachable

cause or by using SGsAP-UNREACHABLE message

UE-Unreachable or

See Alert procedure


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

UE is active within EPS


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

• The MME sends a SGsAP-IMSI-DETACH-INDICATION message to the VLR

• The VLR responds with a SGsAP-DETACH-ACK message and moves the SGs association to SGs-NULL.

Detach Request

Detach Accept


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"

– "Combined UE initiated IMSI detach from non-EPS services“

• The VLR answers with a SGsAP-DETACH-ACK message and changes the SGs association of the UE to SGs-NULL.

• The UE record is then handled according to preconfigured rules (supercharger rules and purging)

Detach Request

Detach Accept


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 and has not executed 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).

For instance out of radio coverage


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


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.


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


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.


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

xSU-0

xSU-1

xSU-2

MME MSS

SCTP association 0

xSU-n

Unit-0

Unit-1

Unit-2

Unit-n

VLR

…



xSU-0

xSU-1

xSU-2

MME MSS

SCTP association 0

xSU-n

Unit-0

Unit-1

Unit-2

Unit-n

VLR

SCTP association 3

SCTP association 7

…

SCTP association 4



xSU-0

xSU-1

xSU-2

MME MSS

xSU-n

Centralized unit VLR

…


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

UEOverlay MSS/

VLRHLR

MSS/VLR w/ A/

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

Location Update Ack

Optional timer is run to

delay routing to new

MSS

MAP SRI

MAP PRN Res(MSRN)

MAP SRI Res (MSRN)

MAP Cancel Location

MAP PRN

Update Location started

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

UEOverlay MSS/

VLRHLR

MSS/VLR w/ A/

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

Location Update Ack

Optional timer is run to

delay routing to new

MSS

MAP PRN Res(MSRN)

MAP Send Identification

MAP PRN

Update Location started

IAM(MSRN)

Normal MT Call setup procedure over A/Iu

interface

MAP Send Identification Res


Next future release planned items related to CSFB

SGsAP Load Balancer (IPDU)

xSU-0

xSU-1

xSU-2

xSU-3

xSU-4

xSU-n

…

IPDU-0

IPDU-1

Secondary paths

Primary paths

SCTP association 1

SCTP association 2

EMB

Ethernet port (EL4 / EL5)

IPDU is N+1 redundantLinDXbased unit.


Few words about CSFB and Packet Core data connection interworking


CS fallback with data continuity in the UTRAN/Geran 1/2

MME

S/P-GW

MSS

SGs

Mobile receives MT call paging over LTE access

Data

services

LTE

UTRAN Geran

Data over LTE

A

B

CS call paging over SGs interface Data

Voice

Signaling

CSFB to UTRAN has two mobility options from EPC perspective:

• No PS HO support (CSFB with RRC Connection Release with redirect)

• PS HO supported – NGMN recommendation

CSFB to GSM has three options from EPC perspective:

• No PS HO support

• CSFB with RRC Connection Release with redirect – NGMN recommendation

• inter RAT cell change order with NACC

• PS HO supported


CS fallback with data continuity in the UTRAN/Geran 2/2

MME

S/P-GW

MSS

Data services

LTE

WCDMA Geran

Data continues over Utran/Geran

A

B

SGSN

Voice call over CS access

Data

Voice

Signaling

Network redirects mobile to 3G/2G access

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

Multi RAB or DTM 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

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

Operator benefits


Mobile Terminating Roaming Forwarding (MTRF)

Functionality:

1.) Incoming call to MSS-old triggers CSFB

2.) The UE is paged over SGs interface and UE initiates location update procedure to the MSS-new

3.) MSS-new sends MAP SendIdentification to inform the MSS-old that MTRF is supported

4.) MSS-new performs location update to HLR which cancels subscription from MSS-old

5.) MSS-new allocates MSRN and provides it to MSS-old as response to provide 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

MSS-old

MME

SAE GW

SGs

Data

LTE

2G/3G

CS voice

Fallback

MSS-new 2

1

4

3

5 6


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

Documents

02_CSFB LTE Feature Training