排查并处理共享站点S1用户面路径不可用告警

共享站点S1用户面路径不可用告警排查处理

某区域在12月14-15日开通共建共享后，运营商A部分4G基站上出现S1用户面路径不可用告警告警，同时E-RAB释放次数（S1链路故障原因）次数增多明显增多，如图1所示。

图 1 电信4G基站告警

1. 通过对基站告警进行分析后发现，出现告警的S1用户面路径不可用告警，对端IP地址为10.100.33.X，如图2所示。

图2 对端IP地址

2.10.100.33.X均为运营商B核心网配置地址段，初步判断为运营商B业务异常导致在运营商A共享站点上上报的告警。现场分PLMN统计S1链路故障发起的释放次数，其中新增原因均为运营商B用户引起，如图3所示。

图3 运营商B用户业务异常

3.核查运营商A站点配置的共享运营商B参数，无异常。由于故障为运营商B用户和运营商B用户面链路故障引起，需要运营商B核心网信令跟踪判断。

4.在运营商B的MME上对一个有S1用户面路径不可用告警的运营商A共享站监双五（7.65.227.114）抓包，发现在handoverrequest消息中携带的IP为10.100.33.X，如图4所示。

图4 Handoverrequest消息中携带的IP为10.100.33.X

5.根据抓包获取的时间，在SEQ中回溯找到了MME在servicerequest过程中给运营商A共享站发出的SGWS1-U地址是10.100.33.X的场景，如图5所示。

图5 SGWS1-U地址是10.100.33.X的场景

6.查看这个用户的相关流程，发现当其在运营商B站点森兰名轩东区下时，S1-U地址是正确的10.100.32.X。而当用户切往换到运营商A共享站监双五时，MME下发的SGWS1-U地址发生了改变，是错误的10.100.33.X，如图6所示。

图6 SGWS1-U地址变化

7.从SEQ中，回溯发现S1-U地址发生改变前，终端从运营商B站点森兰名轩东区切往运营商A共享站监双五，从森兰名轩东区发出的S1HO请求中，携带了错误的目标TAC5B0D(23309)。而这个切换目标监双五配置的TAC应该是5D97(23959)。

MME是根据TAC来选择SGW的，根据切换目标TAC=5BXX，MME会从DNS解析中获得外省市运营商B的SGW地址，并从外地SGW中获得10.100.33.X的S1-U地址，下发给运营商A共享站，而导致运营商A共享站出现S1-U地址面不通的告警，如图7所示。

图7 错误的目标TAC5B0D(23309)

8.核查运营商B站点森兰名轩东区配置，发现其邻区中确实有TAC5B0D(23309)的邻区，如图8所示。

图8 TAC5B0D(23309)邻区

9.运营商A侧12月15号凌晨1点38已经完成TAC修改，如图9所示。

图9 完成TAC修改

核查运营商B侧邻区TAC信息与运营商A侧实际配置不一致，应当是ANR在锚点共享时已经添加此邻区，读取到的TAC即为5B0D(23309)。而后当运营商A侧共享出的TAC更改为5D97(23959)后，因终端上报的PCI在邻区列表中已存在，无法再次触发ANR后续流程，运营商B侧TAC未更新且未及时手动更新导致故障。

运营商B侧删除5BXX的邻区关系及外部邻区定义后，通过让ANR重新自动添加邻区。观察运营商A侧S1告警消失，E-RAB指标恢复正常，如图10所示。

图10 告警消失

集团要求4G共享基站的TAC统一为5DXX号段，对于承建方由于之前5G锚点共享已经添加共享方邻区（非5DXX段）场景下，在共享方开启4G共享后需要承建方及时更新对应TAC。

建议共享站开通时即按集团标准TAC进行配置开站。

涉及共享站操作需通知对方，同步修改相关邻区等操作。