This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
• 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
• 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)
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
• 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
• 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
• 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.
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.
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.
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
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.
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
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
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
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
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
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
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.
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 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.
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
• 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.
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.
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.
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.
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.
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.
• 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.
• 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.
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.
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
• 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
•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.
– 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.
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.
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.
• 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.
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.
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.
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.
• 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