eMSC给华为MME返回“Unassigned Number”（或“No Resources Available”）-

【问题现象】

华为MME将切换请求发给eMSC后，eMSC返回“unassigned number”（或“no resources available”）的失败原因码，导致切换失败。
【原因定位】
1、MME从HSS处接收的STN-SR为：8613449924。

2、而MME发给eMSC（SRVCCIWF）的SRVCC PS to CS Request消息中携带的STN-SR为：198613449924。

3、eMSC（SRVCCIWF）不识别该格式的STN-SR号码，返回“unassigned number”（或“no resources available”）的失败原因码，导致切换失败。

4、MME为何要在STN-SR前加上19前缀送给eMSC？
查找3GPP规范可知：3GPPTS29.280协议中定义了MME发往eMSC的“SRVCC PS to CS Request”消息的相关信元结构，因为协议版本差异，不同版本中对STN-SR号码的格式定义前后有区别，两边网元遵循协议版本不一致，导致此问题发生。
1) 3GPP TS29.280 R10版本之前定义的STN-SR信元结构：

2) 3GPP TS29.280 R10版本定义的STN-SR信元结构：3GPP TS29.280 R10版本协议中，在STN-SR号码前新增了NANPI字段，即消息跟踪中多出来的“19”字。

5、当前华为MME侧改造方案中，Sv接口使用29280 R10版本协议格式对接，而eMSC侧默认支持R8版本协议格式（遵循前期浙江外场测试配置）。查询华为MME数据配置，确实在STN-SR号码携带了NANPI字段19：

MOD GTPCV2CMPT: MSGCLS=SV, SVMSGTYPE=PS_TO_CS_REQ, PSTOCSREQ=STN-SR, STNSR=CARRY;

MME MML帮助文档描述如下：STNSR参数含义：该参数用于指示USN9810发送的SRVCC PS to CS Request消息中STN-SR信元的编码方式，控制是否携带NANPI字段(Address and Numbering Plan Indicator)。
取值范围：

1) “NOT_CARRY(不携带NANPI字段)”：表示USN9810发出的SRVCC PS to CS Request消息中的STN-SR信元不携带NANPI字段。

2) “CARRY(携带NANPI字段)”：表示USN9810发出的SRVCC PS to CS Request消息中的STN-SR信元携带NANPI字段。

说明：当“PSTOCSREQ”取值为“STN-SR(Session Transfer Number for SRVCC)”时，该参数有效。在3GPP TS29.280的需求变更中，修改了编码方式，STN-SR信元中增加了NANPI字段。按照R10规范，推荐配置为“携带NANPI字段”，如果因为对端网元没有跟进协议导致的兼容性问题，可以配置为“不携带NANPI字段”。
【解决方案】

若VOLTE工程建设中遇到此问题，eMSC可与MME侧共同协商，一方做修改适配即可。

1、华为MME，可修改GTPCV2CMPT不携带NANPI字段（此配置为全局配置，无法针对具体eMSC设置）

ADD GTPCV2CMPT: IDX=“索引号”, MSGCLS=SV, SVMSGTYPE=PS_TO_CS_REQ, PSTOCSREQ=STN-SR, STNSR= NOT_CARRY

2、华为eMSC，可修改GTPPE中＂GTP对端实体能力列表＂，适配支持R10版本协议STN-SR格式。（可支持针对具体MME设置）

ADD GTPPE: GTPPENM=”GTP对端实体名称“, DSAI=”SRVCC通用服务区“, CSCNAME=”呼叫源名称“, GTPPEERENTITYCAPLIST=RSVBIT0-1;

3、根据调研各厂家MME、eMSC实现，最终按照集团要求MME和eMSC针对STN-SR信元结构都按照3GPP TS 29.280 R10版本来处理。

本文整理自网络，文章版权归原作者所有，如有侵权，请联系我们进行删除。小编微信（gprshome201101）