MacIndex丢失导致的Connection掉线分析方法.doc

邮件： 各位领导、同事： 你们好！ 随着各地市对高速公路DO Connection掉线的解决，空口问题在掉线总数中的占比逐渐下降，随之而来的就是Macindex丢失类等异常问题占比越来越大，目前Macindex丢失类掉线占比已高达30%左右，但至今我们仍无法确定其确切的成因。 上月末已请中兴、华为公司研发介入，分别于常州、泰州为试点地市彻查该类掉线问题。于办公室，使用QXDM、网管后台信令跟踪、异常探针共同进行数据抓取。但截止至目前，中兴区的数据还未能抓取到。自动路测设备测得的老测试数据由于异常探针数据不全、中兴无法解析.rcu文件等原因无法使用。 因此，请中兴区各地市共同对该问题进行数据抓取： 1、可在办公室搭建测试环境，使用DO终端、QXDM软件（全信令抓取、发射功率、接收功率等关键指标抓取），结合网管后台信令跟踪、异常探针跟踪； 2、使用FTP软件下载5GB或更大文件，避免因下载时间过短，需要人工频繁操作； 3、每天早晨对QXDM数据进行筛选，找到Connection Release消息（非层三信令），并按附件的方法判断是否为Macindex丢失类掉线； 由于该工作的成功存在一定概率性，可能需要长时间对数据进行跟踪、分析，我会与领导申请对成功抓取问题信令的地市予以月度加分的奖励。 感谢各位！ 此致 敬礼！ 问题描述： 在自动路测系统测得的Connection Drop中，发现了由于基站侧释放在用的MacIndex而且未下发Connection Close消息，导致AT释放空口空口连接且原因值为2（System Lost）的情况。 如下图，为镇江一次MacIndex掉线。首先从手机的Connection Release消息里可看到释放原因值为2（System Lost）。 MacIndex丢失的另一个重要特征是在Connection Release消息与最近的一条QuickConfig（标蓝）消息之间，最多间隔两条信令：Sync、AccessParameters： 为验证是否的确为MacIndex丢失导致的掉线，可从Connection Release消息向上寻找最近的一条CDMA 1xEV-DO Pilot Sets, Ver 2（标蓝）消息，如下图。从图中可看到目前激活集中三路信号：PN234分给AT的MacIndex为120，PN309分配的MacIndex为114，PN339分配的MacIndex为120。其中要关注的是PN234、PN339分配的MacIndex虽然都是120，但这是不同扇区的不同MacIndex资源： 而在距离Connection Release向上最近的一条QuickConfig消息中，可看到该条消息为PN234下发，但其120号MacIndex状态为not valid（非占用），即基站侧已经将PN234分配给中端的MacIndex给释放掉了。 所以终端收到该QuickConfig消息后，发现基站已经把分给我的资源释放了，那我干脆也把空口给释放掉吧，但这次释放又不是我发起的，所以要说明一下，就报一个System Lost的原因值吧。这样就导致了这次掉线。 QXDM验证结果 首先在搜索中发现connectiong release消息，距离最近的QC消息只有两条信令（如图1），与最明显的特征不同的是，release与QC之间的两条信令不是Sync和AccessParameters，而是Sync和control config，其中Sync显示是unknown。 从Connection Release消息向上寻找最近的一条CDMA 1xEV-DO Pilot Sets, Ver 2（图2）消息。从图中可看到目前激活集中只有一路信号PN111，这与办公室的测试环境完全相同：PN111分给AT的MacIndex为112。 而在距离Connection Release向上最近的一条QuickConfig消息中，可看到该条消息为PN111下发，但其112号MacIndex状态为not valid（非占用），即基站侧已经将PN111分配给中端的MacIndex给释放掉了（图3）。 在Connection Release消息中发现释放原因为System lost，与特征相同（图4）。 图 1 release与QC之间只有两条信令 图 2 PN111分配给AT的Macindex为112 图 3 在Quick config消息里面发现Macindex112已经被释放 图 4 发生connection release，原因为System lost