MTRF in MSS

Feature 2028: Mobile Terminating Roaming Forwarding Support in MSS 提高CSFB呼叫接通率
现象：UE在LTE边界区域内做被叫时，可能回落到非联合位置更新登记的MSC，不收到MT呼叫的 CSFB 为国际漫游提 MSC丌同，导致被叫无法成功。

供语音业务解决方案：MTRR和MTRF功能均可以解决上述问题，MTRR需要改造全网MSC和HLR；MTRF只需要改造LTE覆盖区及边界MSC（对本网用户不国漫入用户提供CSFB，改造要求相同。

）
UE跨MSC Pool回落，导致被叫失败
1. 现象描述
外场测试某区域，使用两部三星CSFB终端互拨，主叫端发起呼叫后正常回落，被叫端也正常回落至2G,但一直没有来电显示，也未振铃；主叫端等待一段时间无回铃音，之后
收到被叫用户无法接通的提示音。

2. 问题分析
主被叫两部终端均可正确回落，说明终端在LTE网络侧的CSFB相关流程执行正常，被叫失败是在终端接入GSM网络后因某环节出现异常导致的。

通过跟踪两部终端回落后的
各项操作，以及与GSM网络的信令交互过程，发现出现该问题的测试区域恰好位于MSC
PooL边界。

其中终端开机初始执行LTE联合附着/位置更新时，根据MME配置的TA-LA
映射表，注册在LA1对应的MSC1上，MSC1在MSC PooL1内。

而因终端拨打时位置在
MSC POOL边界，终端实际回落时选择接入的GSM小区为LA2，对应的MSC为MSC2，
MSC2在MSC PooL2内。

如下图所示：
图4-1 UE回落跨MSC Pool示意图
由于联合注册在MSC PooL1的MSC1，被叫呼叫一定接续到PooL1的MSC1，之后用户回落到MSC PooL2的MSC2，导致被叫失败。

3. 问题分类：网络覆盖条件
4. 解决方案
尽可能完善网络规划，合理配置GSM小区归属MSC PooL，将终端回落接入的GSM 小区尽量规划在终端联合注册的MSC PooL内，避免发生回落跨PooL场景，降低被叫失
败发生的概率，但这种方法无法彻底解决该问题，需通过部署MSC的MTRF功能才可真正
避免回落后跨PooL的被叫失败问题。

3GPP定义的MTRF（Mobile Terminating Roaming Forwarding），即可解决这种特殊场景下的异常问题。

通过引入该功能，可实现old MSC（联合位置更新附着的MSC）和
new MSC（回落的MSC）之间的呼叫前转，让被叫成功接续。

该方案实施需LTE覆盖范
围内全部MSC软件升级支持，影响范围广，改造量大，实施代价高，因此目前尚未部署，
只能通过无线规划的方式规避。

5. 效果评估
通过优化无线规划，合理设置GSM小区归属MSC PooL，尽量保证终端回落接入的GSM小区归属于终端注册的MSC PooL，可解决多数场景下回落跨PooL的被叫失败问题。

但在边界区域由于无线信号漂移，无法保证用户在同一区域每次都选择相同小区接入；也不可能同时照顾到PooL边界范围内所有用户，因此无法彻底解决用户被叫失败的问题。

1) Activating MTRF support in MSS
This optional functionality is controlled with the FEA4302 On/Off license and the MTRF PLMN parameter. Activate the functionality as follows:
1 Activate the FEA430
2 On/Off license.
ZW7M:FEA=4302:ON;
Where:
FEA Feature code
ON ON state
2 You can interrogate the feature state with the W7I command.
ZW7I:FEA,FULL:FEA=4302;
For more information, see Licence and Feature Handling, W7 Command Group.
3 Check whether MTRF is enabled on PLMN level with the MTRF parameter.
The default value of the MTRF PLMN parameter is Y meaning that MTRF is enabled
by default. In this case no manual setting is required.
You can check the value of the MTRF parameter with the MXP command.
ZMXP:NAME=<PLMN name>;
or
ZMXP:IND=<PLMN index>;
Example
ZMXP:NAME=OWNPLMN;
4 If the value of the MTRF parameter is not Y, set it to Y.
ZMXN:NAME=<PLMN name>::::::MTRF=Y;
or
ZMXN:IND=<PLMN index>::::::MTRF=Y;
Where:
NAME the name of the subscriber’s PLMN
IND the index of the subscriber’s PLMN
MTRF=Y MTRF is available for all the subscribers of the given PLMN
Example
ZMXN:NAME=OWNPLMN::::::MTRF=Y;
For more information, see VLR and PLMN Parameter Handling, MX Command
Group.
2) Configuring the SGs interface and the MME(No need)
3) Setting the routing delay timers and MTRF triggering
4) Defining MT rerouting delay timer at SendIdentification MAP operation
ZMXM::::::::::::::RDELAYSI=70;
The recommended value for the RDELAYSI parameter is 70 (0.7 sec), however, the value is operator-dependent.
5) Defining MT rerouting delay timer at CancelLocation MAP operation ZMXM::::::::::::::RDELAYCLO=0;
The recommended value for the RDELAYCLO parameter is 0, however, the value is
operator-dependent.
6) Configuring the usage of SCCP-level Calling Party Address at SendIdentification MAP
operation
With the FORCESIMTRF parameter you can force the MTRF execution at MAP SendIdentification,
independently from the MTRF information elements' presence. If the new MSS does not support MTRF, the SCCP-level Calling Party Address (CgPA) is used for the MT call's rerouting. However, if the new MSS supports MTRF, the standard information elements are used.
The possible values for the parameter are Y and N. The default value is N meaning that MTRF is not forced at the SendIdentification MAP operation.
Example
Set the FORCESIMTRF parameter to Y.
ZMXM::::::::::::::FORCESIMTRF=Y;
If the FORCESIMTRF parameter is activated, no MTRF support is needed on the HLR’s side.
YS: 如果北京实施MTRF则激活FN 1914 + FN2028 NewMSS、OldMSS必须支持。

而主叫局GMSC不需要支持MTRF，HLR为可选支持。

7) Setting the PRN relay timer when no pre-paging is performed
Patching this UTPFIL, you can define how long the Old VMSS is waiting for the PRN acknowledgement from the New VMSS at PRN relay.
The default value of the timer is 30 sec. For the patching, you have to give the timer value in tens of milliseconds in hexadecimal format.
Instructions
Set UTPFIL record 0x0136 0x0418 to xxxx xxxx.
Where:
xxxx xxxx is the timer value in tens of milliseconds in hexadecimal format (that is, if xxxx xxxx is zzzz in decimal format, the delay will be zzzz x 10 ms).
Example
If you want to set the delay timer to 35 sec, you have to calculate the value to be patched in the following way:
35 sec = 35 000 ms = 3 500 x 10 ms
3 500D = DACH, therefore, the value to be patched is 0DAC 0000. This value is used in
the examples of the patching procedure below.
The UTPFIL files are to be patched in the corresponding unit(s), if they exist:
UTP_SSMX / 05AC0018 / BSU
UTP_ICMX / 05AC0007 / CCSU
UTP_0YMX / 05AC015C / SIGU
Parameter value:
•Parameter family: OC2_SSMX, 0x0136
•Parameter index: 0x0418
•Parameter value in word format: for example, 0DAC 0000
Patching instructions:
•Patch as word format.
•The new value takes effect in maximum 1 minute.
If the file is patched in the CMM, it can be distributed to the corresponding units, using the MML interface.
Activation
In the following patching procedure, value 0DAC is patched, which sets the delay timer to 35 sec. In the case of any other required timer value, 0DAC has to be substituted with the appropriate hexadecimal value.
Patch the UTPFIL record with the content: 0136 0418 0DAC 0000.
1 Identify the active CMM:
ZUSI:CMM;
The printout of this command contains the identifier of the active CMM.
WORKING STATE OF UNITS
UNIT PHYS STATE LOCATION INFO
CMM-0 0004 SP-EX -
CMM-1 0005 WO-EX -
TOTAL OF 2 UNITS
In the above printout, CMM-0 is the spare unit and CMM-1 is the working unit.
2 Check whether the BSU-UTPFIL in the active CMM has a record starting with 0136 0418. If not, identify the first free record (a record full of zeros).
Use the following MML command:
ZDFD:CMM,<working unit id>:5AC0018,,,W;
where:
5AC0018 BSU-UTPFIL file number
Example
ZDFD:CMM,1:5AC0018,,,W;
Example printout
CMM-1 FILE N:O 05AC0018 RECORD N:O 00000000
00A4 0003 0001 0000
CMM-1 FILE N:O 05AC0018 RECORD N:O 00000001
0013 0005 0001 0000
CMM-1 FILE N:O 05AC0018 RECORD N:O 00000002
0180 0004 0000 0000
CMM-1 FILE N:O 05AC0018 RECORD N:O 00000003
0000 0000 0000 0000
In this example, record number 3 is the first free record, therefore, this is the record to be patched.
3 Give the patching command:
ZDFS:CMM,<working unit id>:5AC0018,<record to be patched>,,W;
Example
ZDFS:CMM,1:5AC0018,3,,W;
4 Enable patching and distribution to the other units, via the MML interface:
The following prompt appears, after giving the patching command:
DO YOU WANT THE SPARE UNIT TO BE UPDATED ?
( Y = YES, N = NO ): Y
DO YOU WANT THESE SUBSTITUTIONS TO BE UPDATED ON DISK ?
( Y = YES, N = NO ): Y
DO YOU WANT THESE SUBSTITUTIONS TO BE DISTRIBUTED ?
( Y = YES, N = NO ): Y
5 After enabling the changes and the distribution, the patching interface appears. Give the desired values (in hexadecimal).
Example printout
CMM-1 FILE N:O 05AC0018 RECORD N:O 00000003 DISPLACEMENT
00000000
0000-
Here, write: 136 (press space) 418 (press space) DAC (press space) 0 (press space). Example
CMM-1 FILE N:O 05AC0018 RECORD N:O 00000003 DISPLACEMENT
00000000
0000-136 0000-418 0000-DAC 0000-0
6 Save the changes.
The following prompt appears:
DO YOU WANT THIS SUBSTITUTION TO BE MADE ?
( Y = YES, N = NO ): Y
7 Check whether the patch was successful by interrogating the patched file.
ZDFD:CMM,<working unit id>:5AC0018,<patched record>,,W;
Example
ZDFD:CMM,1:5AC0018,3,,W;
Example printout
CMM-1 FILE N:O 05AC0018 RECORD N:O 00000003
0136 0418 0DAC 0000
8 Repeat this process for the CCSU and SIGU units as well.
8) Setting the PRN relay timer when pre-paging is performed (No need)
9) Setting the roaming preference order
With the ROAMPREF parameter, you can set the priority order for the following MT rerouting functionalities: •Mobile Terminating Roaming Retry (MTRR)
•Nokia Siemens Networks proprietary MTRF solution (SGs Overlay MSS Solution)
(Pre-MTRF)
•standardized Mobile Terminating Roaming Forwarding (MTRF)
Example
Set the following priority order for the different MT rerouting solutions:
1. MTRF
2. Pre-MTRF
3. MTRR
ZMXM::::::::::::::ROAMPREF=MTRF-PREMTRF-MTRR;
For more information, see VLR and PLMN Parameter Handling, MX Command Group.
10) C onfiguring EOS analysis for MTRF
1 Configure the EOS analysis for the event code of MTRF.
ZRXC:1034:ALL,CMANAL,,,<analysis tree>,<charging origin>,,,;
Where:
1034 MTRF event code
ALL analysis result group
CMANAL analysis result identifier; CMANAL = execute digit analysis
analysis tree the tree in which the digit analysis is made
charging origin the charging origin of the call
Example
ZRXC:1034:ALL,CMANAL,,,50,0,,,;
For more information, see End-of-Selection and Function Analysis Handling, RX
Command Group.
11) I N Attribute Analysis, Service Attribute Analysis, Routing Attribute
Analysis, EOS Attribute Analysis and Extended
Preanalysis(optional)
12) C onfiguring charging - Suppressing CDRs generated by call
redirection in case of MTRF(optional)
It is possible to suppress the FORW CDR generated due to call redirection in case of
MTRF with a configurable parameter.
1 Use the following MML command to suppress forwarding CDR generation in MTRF cases:
ZGTM:EVE:12,<FORW/NONE>;
Where:
EVE event group; EVE = call events
12 event; 12 = suppress CDR for MTRF
FORW FORW CDR is suppressed
NONE CDR suppression is not active at all
For more information, see Detailed Charging Handling, GT Command Group.。