SN添加失败触发锚点掉线掉话问题

最佳实践上报表（省公司版）

问题名称：SN添加失败触发锚点掉线/掉话问题

现象描述：SEQ平台统计延安市宝塔区FDD1800小区从3月22日VoLTE掉话次数从1天5次以下突发恶化到30次左右，VoLTE掉话率突发恶化到3.5%，连续多天恶化未恢复，触发平台VoLTE高掉话工单。

问题原因分析：

（1）小区覆盖及告警分析

查询基站告警，无异常告警，S1断链为核心网操作导致，无影响。查询小区在服时长指标，没有异常退服情况。

（2）网管KPI分析

查询小区指标：

网管掉线率和V oLTE掉话率均出现了明显劣化，与SEQ平台一致，其余指标未发现明显异常。

小区覆盖质量类指标正常，小区覆盖并未发生明显变化。

由于掉话次数较少，重点针对掉线原因值进行分析如下：从上可以看出为其他原因导致的掉线增长导致，空口及切换失败引起的掉线并未增长，结合覆盖指标，初步排除小区无线质量问题。

（3）信令分析

分析SEQ失败终端信息，发现全部为5G手机：

分析SEQ失败信令，用户上下文异常释放主要发生在E-RABMODIFICATIONINDICATION后500ms.

跟踪无线侧信令进行分析，抓取到2次失败，现象与SEQ一致，均为5G终端的掉线，流程如下：

（1）用户从附近小区FDD1800_197 S1切换入本站FDD1800_67,携带的PCEID为11563286，对应的5G站为**工业区NR；

（2）在本站FDD1800_67下给用户下发B1，并触发SN添加流程；

（3）SN添加完成的PCEID为11563345，对应5G站为XXXNR；

（4）由于PCEID发生了变更，触发eRAB修改流程；

（5）由于核心网500ms都未响应eRAB修改流程，无线侧主动发起上下文释放，触发掉话。

由此可以判定是由于MME迟迟不响应ERAB修改导致的无线侧释放。

（4）核心网分析反馈

将问题反馈诺基亚MME，MME答复如下：

目前诺基亚处理HO和ERAB两个流程不能同时触发，要在一个流程结束之后再发起另一个流程，否则会引起冲突。

诺基亚新版本处理机制在遇到该冲突时，会中止ERAB流程，旧版本是中止HO流程。- Collision handling between ERAB Modification Indication and HO corrected as follows:

1) ERAB Modification (ongoing) / Handover (incoming) - Drop ongoing Continue Incoming.

2) Handover (ongoing) / ERAB Modification (incoming) - Drop incoming Continue Ongoing. 由此可以确定是由于诺基亚无法同时处理HO和ERAB流程，目前诺基亚策略是对ERAB流程不处理，导致ERAB流程超时后，无线侧释放。

（5）现网统计情况

从诺基亚反馈看，该问题应为现网普遍问题。故统计现网，统计可以看出只有锚1个5G 站点的FDD1800站点才不存在eRAB修改失败（不存在eRAB修改流程），其余均多少存在eRAB修改失败，为一个普遍现象。

统计现网eRAB修改失败导致的SN添加失败，约占整体SN添加失败的7%。

由于诺基亚无法同时处理HO和ERAB流程，如果同时出现2个流程，目前诺基亚策略是对ERAB流程不处理，导致ERAB修改流程超时，SN添加失败，无线侧释放。该问题目前贡献了现网SN添加失败的约7%的失败。

针对该问题，尝试2种方案：

（1）删除与周边NR站点的锚点关系，使该FDD1800站点只锚1个5G站，不会触发eRAB修改流程；（规避eRAB修改流程）

（2）补足附近FDD1800站点间的X2关系，让其走X2切换流程，不走S1切换流程，观察是否有改善；（不走S1流程）

解决效果：

（1）删除锚点效果：掉线明显恢复。

（2）添加FDD1800间X2，使其切换走X2切换流程

添加后，S1切换明显减少转换为X2切换，规避了核心网HO和ERAB修改冲突问题，掉线率明显恢复。