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