eNodeBID冲突导致掉线陡增

1、eNodeBID冲突导致掉线陡增提交人：司天云提交时间：2015.081 问题描述8月11日开始新开通的站点万里客酒店（enodebid：634963）3个小区e-rab掉线率陡增，达到90%左右，一天发生上万次掉线，导致全网E-rab掉线率恶化。开始时间ECGI901175:E-RAB掉线分子901176:E-RAB掉线分母900300:E-RAB掉线率2015-08-11 00:00:00460-11-634963-49376704205289.58%2015-08-11 00:00:00460-11-634963-50262952910390.35%2015-08-11 00:00:00

2、460-11-634963-51219622514587.34%2015-08-12 00:00:00460-11-634963-49628667145587.98%2015-08-12 00:00:00460-11-634963-50536835956890.12%2015-08-12 00:00:00460-11-634963-51272373181485.61%2015-08-13 00:00:00460-11-634963-49189392158787.73%2015-08-13 00:00:00460-11-634963-50194262125591.39%2015-08-13 00

3、:00:00460-11-634963-516408757084.65%2 问题分析通过观察e-rab异常释放原因，主要是由于小区关断或复位和S1链路故障发起释放引起的，怀疑问题跟核心网或者传输有关。2.1 故障分析8月11日通过检查基站告警发现存在大量的告警，告警名为小区被人工关断，如下图所示：通过以上的问题分析认为，由于该告警导致基站不停闪断，因而导致E-rab掉线率陡增。究其原因，咨询了华为的传输人员，当天其A设备存在闪断，于是先由华为处理故障。8月12日故障被清除，直到8月13日观察指标依然掉线率极高，通过告警查询无法看到任何告警。但通过后台的指标查询，存在大量的SCTP链路断链：开始

4、时间查询粒度网元C373920000:SCTP链路断链次数2015-08-11 00:00:001天63496366462015-08-11 00:00:001天63496366462015-08-12 00:00:001天63496366082015-08-12 00:00:001天63496366082015-08-13 00:00:001天63496331162015-08-13 00:00:001天6349633115为此通过动态管理功能查询SCTP偶联的链路状态，发现0号和15号的SCTP偶联链路时而正常时而故障：对链路进行拆链之后重新建链，刚开始正常，单过一段时间仍然会出现故障，无

5、法解决问题。2.2 核心网侧排查0号和15号SCTP偶联是eNodeB与MME之间的链路，对无线侧的SCTP偶联数据进行检查之后确认无误之后，需要核心网侧进行排查。基站的基本信息如下：网元名称eNodeBIDIP地址成都金牛鑫万里客酒店F-eNodeB634963(634963)6349639.0.107.155核心网侧查询该基站的信息如下：命令 (No.1): SHOW ENODEB INFO:MCC="460",MNC="11",ENODEBID=634963;移动国家码(MCC)-460-记录数 1移动网号(MNC)-11-记录数 1eNodeB局

6、向号-634963-记录数 1eNodeB名称-记录数 1跟踪区列表-460-11-9b12-记录数 1CSG数量-0-记录数 1CSG列表-记录数 1偶联号-59580-记录数 1模块号-5-记录数 1本地端口号-36412-记录数 1对端端口号-36412-记录数 1本地IP地址列表-IPv4: 6.44.0.254-记录数 1对端IP地址列表-IPv4: 9.0.19.132通过核心网侧查询到该eNodeBID对应的IP地址为9.0.19.132并非在基站本地配置的IP地址9.0.107.155，于是我们推测，现网中有一个相同的eNodeBID的基站使用了9.0.19.132这个IP，M

7、ME中查询到的并不是万里客酒店的IP地址，而是这个”未知”站点的IP。这样就会导致在相同的MME内有重复的eNodeBID，引发冲突。3 问题处理通过局方获取到了成都现网大唐，华为和我司所有的基站信息进行确认是否有eNodeBID重复，检查之后并无重复的eNodeBID。于是检查之前的现网数据，发现存在一个站点如下：经过局方确认，该站点已拆出，网管数据已经删除，并且为了节约eNodeBID资源，将该eNodeBID留给了后续新开通的站点，由于前期发现部分站点网管删除数据之后，设备并没有下电，因此怀疑，核心网查询到的这个重复的IP地址正是晶泽印象在使用。后续处理办法如下：1. 将万里客酒店更换一个新的eNodeBID，避免冲突；2. 派人前往现场核实，8月14日工程队前往现场确认该站点的确还在运行，未下电；4 处理结果13日夜间对万里客酒店重新配置了数据，eNodeBID更换为638084，观察14日指标，已经恢复正常，如下图所示：5 总结1. 该问题容易被前面的告警现