网优经验分享_RRC_CONNECTION_SETUP无响应问题定位手册.doc

RRC CONNECTION SETUP无响应问题定位手册 网优经验分享RRC CONNECTION SETUP无响应问题定位手册 （作者：网优双提升CS团队）Build Excellent TD-SCDMA Network 目录一、RRC无响应总体分类31.1、基站单站故障导致61.2、基站DSP的隐性故障导致61.3、弱覆盖、空口环境差导致61.4、商用终端问题导致61.5其它可能原因7二、RRC无响应整体排查思路82.1、参数核查82.2、基站排查82.3、特定终端排查92.4、弱覆盖、干扰排查92.5、典型小区筛选102.6、现场拨测的同时，进行fach监控102.7、RNC、NB、UE联合定位10三、基站BBU板卡DSP隐性故障的定位文档11四、Outum跟踪RRC中fach信令的说明文档21五、基站侧ATP软件跟踪物理层消息的方法文档31六、Mini_PTAS跟踪测试手机终端物理层消息的方法文档43通过了解全国现网大唐系的KPI指标可知，目前各地的接通率指标都已经提升到一个比较高的水平，接通率KPI的指标已超过99%，剩下不到1%的未接通主要集中在RRC无响应问题上。根据目前经验，RRC CONNECTION SETUP无响应大都是个别NB站点的稳定性问题，也有少部分是由于个别商用终端的软件版本存在问题（因为此类问题由我司RAN侧发出的RRC CONNECTION SETUP消息已确认无误可以判断），还有部分终端起呼时处于弱覆盖、强干扰地带。通过对以上几方面的检查和处理，可以有效的使RRC CONNECTION SETUP成功率稳定保持在一个较高的水平。需要说明的是，针对基站物理层的AOA算法中测量角度对RRC无响应问题的影响，双提升项目CS组的提升人员针对室外和室内（注：无室内信号覆盖的站点，应用室外信号在室内进行验证）典型站点进行了较为详细的测试，证明AOA测量角度准确。结论表明：AOA角度测量未影响到RRC的接通，其它项目遇到未接通的情况时请不用怀疑AOA算法。本文档针对已经暴露出来的问题，双提升项目CS指标提升组对已有的工作及积累的经验进行了较为详细的总结，给出了RRC无响应问题的整体排查思路，并且针对具体步骤以案例的形式给出了指导手册，以方便各地项目学习使用。此文档会根据后期问题的定位进展，不断补充内容、及时更新。一、RRC无响应总体分类正常情况下，RRC过程的典型流程图如下。RRC无响应的现象主要指，RNC向终端下发了“RRC Connection Setup”信令，但是终端没有按正常信令流程，向RNC发送“RRC Connection Setup Complete”信令。根据基站和RNC之间是否同步，RRC无响应问题首先要区分是否是失步造成的。第一种情况属于失步问题造成的无响应。判断方法是，在CDL信令中可以看到基站给RNC上发了“Radio link Restore indication”，并且紧接着可以看到“Radio link Failure indication”的信令，表明是基站和RNC之间出现了失步造成的。为了进一步验证基站和RNC之间是否真正出现了失步，可以在OMT上把问题小区的 “同步信息_连续同步指示”的参数由“1”改为“2”。继续观察，当再次出现无响应问题时查看CDL信令，如果仍然是先看到“Radio link Restore indication”，接着便是“Radio link Failure indication”的信令，表明确实是基站和RNC之间出现了失步造成的。否则属于第二种情况。第二种情况属于没有看到“Radio link Failure indication”信令，而是RNC向终端下发了“RRC Connection Setup”信令后，RNC接着又向基站下发了“Radio link Deletion Request”信令进行了删除链路的操作。这种情况是本文档关注的典型无响应情况，下文进行了较为详细的分类。1.1、基站单站故障导致这类问题多集中在高发站点，且比较有规律，大多为DSP不存活的故障，通过轮询工具及时轮询基站的DSP状态就可以发现。轮询工具的熟练应用可以快速提高问题响应、及时排查的效率。1.2、基站DSP的隐性故障导致这是一类DSP的隐性故障，通过基本的轮询方法无法发现，同时在基站侧的告警信息记录中也看不到22000号告警“DSP不存活”。因此，对于此类隐性DSP故障的判断，在此单独列出。此类问题的发现定位方法如下：通过OMT上的操作设置，将问题小区的业务全部限定到某一特定的载波上进行测试，通过在特定频点判断业务状态是否正常就可以推断出相应DSP是否存在故障，完成定位。1.3、弱覆盖、空口环境差导致此类问题建议在OMT上打开小区系统信息里IDLE态上报RSCP/ISCP的开关，开启后使用新版CDLMR分析工具分析数据，可以确认哪些小区RRC SETUP无响应更多是由于RSCP弱或者ISCP强导致的。针对此类问题，需要通知无线优化的同事对相关小区空口无线环境做进一步的优化处理。1.4、商用终端问题导致排除以上三类原因导致的无响应，并且还存在的RRCSETUP失败较多的小区，还有少部分是属于商用终端的问题。定位方法：建议携带一部8120/8130终端到问题小区现场，通过监视RRC中fach信令是否下发了RRC Connection SETUP，比对测试终端和商用终端是否都正常接收RRC Setup信令，进而确认问题原因。在昆明期间，经过定位，确认了两款TD无线座机终端存在问题，IMEI为86007200。型号1： 型号2： 1.5其它可能原因暂时没有发现其他原因导致的RRC CONNECTION SETUP无响应的问题，如有发现后续不断补充并及时归类、更新。也请联系CS指标提升团队：杨勇 139-9135-2127 或赵志伟 138-1087-9039 二、RRC无响应整体排查思路2.1、参数核查首先运用参数核查工具，通过轮询比对的方法，把问题基站和对应RNC侧的小区参数核查一遍，排除参数设置的问题。如果参数核查没有问题，则可进行第2步操作。2.2、基站排查KPI指标差，根据已有经验，往往主要集中在某几个特定的基站上，因此首先从小的网元入手进行排查。方法是通过查看问题基站的事件告警信息，分析问题小区的CDL，确定问题是否可以从基站层面定位并解决。需要注意的是，前边提到有一类基站的BBU板卡的DSP隐性故障，通过简单的告警分析，不容易判断，需要网优同事上站测试，联合机房对OMT的操作才能定位。这种DSP隐性故障的定位方法详见本文档第三部分基站BBU板卡DSP隐性故障的定位文档。如果经过分析，无法单从基站侧定位RRC无响应问题，则可进行第3步操作。2.3、特定终端排查通过目前应用的CDLMR工具分析至少一天的数据，可以较快分析出RRC无响应的具体分类，此时重点关注涉及到终端分类的统计。如果发现问题集中在某一款特定的终端或者特定的用户，在良好的无线环境下起呼仍然频出RRC SETUP无响应问题，可以如下处理。针对特定终端，可以尝试通过移动客户协调有嫌疑的问题终端，实地进行拨打测试进行复现并联系厂家定位；针对特定用户，则可以通过移动客户负责与用户沟通工作的同事对特定用户进行电话回访，确认问题具体原因。如果统计结果显示，问题终端、客户均分散，则可进行第4步操作。2.4、弱覆盖、干扰排查在OMT中，针对问题小区，开启小区的RSCP/ISCP上报功能。针对后续出现问题的时间点，分析提取到的CDL log，通过RSCP/ISCP的上报值，确认出问题时是否是弱覆盖或强干扰造成的。上报的RSCP和ISCP在UE跟踪中可以从RRC CONNECTION REQUEST消息中的相关IE读出，通过CDL可以在RRC CONNECTION REQUEST消息前的测量报告中的相关IE找到。如果以上操作排除掉弱覆盖、强干扰的可能，则可进行第5步操作。2.5、典型小区筛选在容易出问题的小区中，连续统计至少3天的KPI数据，列出问题小区列表，在其中查找问题出现频率高、话务量大的小区，安排好项目上的人力、物力资源，提前做好上站定位问题的准备。准备资源完毕，分配任务到人，制定好上站定位计划，则可进行第6步操作。2.6、现场拨测的同时，进行fach监控机房侧，专人进行小区级别的LDT跟踪；基站侧，在保证无线环境良好，基站天线可视的范围内，用测试终端跟踪所有发生在此小区的承载有RRC Connection Setup的fach信令。一旦机房侧通过LDT监控到商用终端RRC无响应问题出现，及时记录UEID和问题时间点后，电话联系基站上的同事，确认上站同事监控的8120/8130测试终端是否收到fach。Outum中跟踪RRC信令中fach信令的方法见本文档第四部分Outum跟踪RRC中fach信令的说明文档。如果商用终端fach信道没有收到RRC CONNECTON SETUP消息（通过该小区UE跟踪RRC请求消息中携带的RSCP/ISCP参数，确认RRC无响应时UE处于比较好的无线环境）、测试终端却可以正常接收，证明RNC和基站的处理没有问题，重点定位商用终端自身问题。如果商用终端没有收到fach、测试终端也没有收到fach，则可进行第7步操作。2.7、RNC、NB、UE联合定位此时不仅要使用测试终端跟fach，同时也需要RNC侧进行IUB口挂表，基站侧用ATP跟踪物理层的log，及时记录问题复现的时间点，并保存基站、RNC、机房LDT跟踪的所有log信息。基站侧ATP跟踪的log发回相应的研发同事（联系基站研发对外支持组张光、章贵即可）进行分析，联合定位。对于终端而言，当在定位过程中或者路测时发现问题，并且已经排除了基站自身问题，可使用MiniPTAS抓取终端的物理层log，发给联芯终端的技术支持进行分析。基站侧用ATP跟踪物理层log的方法见第五部分基站侧ATP软件跟踪物理层消息的方法文档。UE侧用MiniPTAS跟踪终端物理层高层log的方法见第六部分Mini_PTAS跟踪测试手机终端物理层消息的方法文档。IUB口挂仪表的使用方法，请参考当地移动许可仪表的使用说明。湾流是集团配给各省的指定仪表，全中文说明，很容易使用。三、基站BBU板卡DSP隐性故障的定位文档经过昆明、宁波等城市的实际案例积累，发现影响RRC指标的一种方式是基站的BBU板卡的某一个DSP故障导致的RRC无响应。此类问题的特点是：通过轮询方法无法发现，同时在基站侧的告警信息记录中看不到22000号告警“DSP不存活”。因此，对于此类隐性DSP故障的判断，就需要通过OMT上的操作设置，将问题小区的业务全部限定到某一特定的载波上进行测试。由于基站的每块BBU板卡有6块DSP，且每个载波都只工作在一个DSP上，因此通过判断此载波承载的业务状态是否正常，就可以推断相应DSP是否存在故障。目前定位的情况来看，一般存在DSP隐性故障的频点，其对应的8根天线通道都会在校准时上报22213“未接收到有效校准数据”，有些还会伴随有22215“接收功率过弱”的告警。这些只是线索可作为怀疑DSP隐性故障的参考提示，具体定位还需要结合实地测试的按文档进行。本文档旨在介绍通过修改OMT对应小区时隙的参数，在某一特定频点上进行业务测试，从而确认是否是单个DSP故障导致的RRC无响应失败的操作定位手册。3.1、基站侧确认小区对应频点的分配关系以昆明的官渡区文化馆_3小区为例，结合截图加以说明。在LMT-B中，点击“配置管理”“频点信息指示”，确认此小区所用的3个频点对应的频率值，以及所对应的BBU的DSP的位置。根据频点信息查询的结果，以“基站频点编号”为索引（上图用红黄绿三种颜色区分三个频点），最终确认三个小区所属频点在BBU板卡上的位置及与DSP的对应关系如下表所示。频点频率值对应BBU的DSP位置主频点100880框3槽第3个DSP辅频点1100800框4槽第2个DSP辅频点2101120框4槽第3个DSP后续要求网优同事到现场，在这个小区的三个频点分别进行拨打测试。每次锁定一个频点进行拨打测试（方法见3.2，OMT上的操作流程有详述），再根据测试结果，判断对应的DSP是否有问题。如果每次在同一个DSP上进行的业务总是失败的，即可重点怀疑这个DSP已经故障。3.2、在OMT侧设置锁定单一频点的操作方法首先，简要了解一下基本概念和几个基本参数。现网载波中的时隙的配置结构一般为：2上4下。即：时隙0，3，4，5，6为下行时隙，时隙1，2为上行时隙。时隙的状态包括两种：激活和未激活。处于激活状态时为可用，反之亦然。3.2.1限定在主频点10088上做业务通过，在OMT上查看配置参数，确认官渡区文化馆_3小区配置的主载波频点是10088，第一、二辅载波分别是10080、10112。要对主频点对应的载波进行测试，设置方法如下：主载波设置如下：“小区集”“官渡文化馆3_26703”“载波”“时隙”“载波1时隙1”“切换预留BRU数量”配置为0。“小区集”“官渡文化馆3_26703”“载波”“时隙”“载波1时隙2”“切换预留BRU数量”配置为0。第一辅载波参数修改如下:第二辅载波参数修改如下:至此，修改参数完毕，可以在此小区进行拨打测试，此时这个小区就只会在主频点进行业务。因此，通过业务的成功与否，就可以验证其所在的0框3槽位的第3个DSP是否有问题。3.2.2限定在第一辅频点10080上做业务主载波设置如下：将切换预留的BRU数量设置为16。第一辅载波参数修改如下:第二辅载波参数修改如下:这样设置的结果就是使主载波为切换接入，关闭第二辅载波，允许用户直接接入第一辅载波使用。至此，修改参数完毕，可以在此小区进行拨打测试，此时这个小区就只会在第一辅频点（10080）上进行业务。从而通过业务的成功与否，就可以验证其所在的0框4槽位的第2个DSP是否有问题。3.2.3限定在第二辅频点10112上做业务主载波设置如下：第一辅载波参数修改如下:第二辅载波参数修改如下:这样设置的结果就是使主载波为切换接入，关闭第一辅载波，允许用户直接接入第二辅载波使用。至此，修改参数完毕，可以在此小区进行拨打测试，此时这个小区就只会在第二辅频点（10112）上进行业务。从而通过业务的成功与否，就可以验证其所在的0框4槽位的第3个DSP是否有问题。3.3、验证后的结论及后续处理如果小区锁定某一个特定频点后，发现在此频点上的业务总是失败的，此时请做好记录，一般可以得出此DSP存在隐性故障的初步结论，需要更换BBU板卡。需要注意的是，待所有验证完毕后，需要将所有参数恢复到原来的设置状态。注意点：以上过程操作中，如果在基站侧的B上看到小区反复出现“激活”“去激活”的现象，需要在OMT上将以上操作对各时隙的参数恢复到操作前的默认状态，再根据手册重新进行设置，进行后续的验证。四、Outum跟踪RRC中fach信令的说明文档4.1、手机连接电脑，安装手机驱动。4.2、安装Outum软件，注意VCOM端口数建议选择安装15个或以上。4.3、连接手机，能在电脑桌面右下角看到MUX UI图标，双击后能看到端口可用。4.4、打开Outum程序，点击F8，进入控制界面，连接终端。 程序右下角的终端终端标示会由断开的红色变为连接上的绿色。 连接成功后，用手机锁定需要跟踪小区的频点码字，然后对手机进行PDP激活（此方法适用于联芯8120/8130终端，配置如下上行速率：16K；下行速率16K；业务类型：背景类）。4.5、在控制界面内，添加跟踪任务。4.6、在控制界面内，选择“室内测试”模式，并选择文件保存位置。4.7在控制界面内，开始进行跟踪。 还有另一种在手机上进行的操作方法，同样可以进行“PDP激活”： 首先，将手机的小区锁定到需要跟踪的小区，选择小区主频点和码字（CPI）即可。 然后，在手机（本文档以联芯8120为例，8130同理）的“PDP”界面中，“APN”选择“cmnet”，上行速率选择“16k”，下行速率选择“16k”，业务类型选择“背景类”，点击“激活”，进行PDP激活。4.8点击F5，进入信令界面，可以看到跟踪的信令，通过设置过滤条件，可以看到所有的下行fach信令。4.9跟踪完毕后，停止跟踪。4.10离线解析方法。 打开相应跟踪的log文件，选择6倍速度回放log，双击“RRC Connection Setup”信令，在消息解码栏中，选择“文本显示”模式，查找对应的UE_ID（log中为2进制数，需要用windows系统自带的计算器转换为10进制数），用此UE_ID与CDL跟踪得到的小区的UE_ID进行比对，重点比对CDL中RRC Connection Setup无响应的信令对应的UE_ID。看CDL中记录的UE_ID是否在终端Outum中跟踪到得fach数据中全部有承载。 如果有，表示测试终端已经正常接收到RRC Connection Serup，排除RNC和基站问题，重点怀疑商用终端本身存在问题。 如果没有，表示测试终端和商用终端一样，同样没有正常接收到RRC Connection Setup，需要首先确认RNC是否下发此消息，NB是否透传此消息，暂时不用怀疑终端本身问题。附：1、LDT中“RRC Connection Setup”筛选示意图。2、Outum和RNC时间差的问题。 Outum跟踪的log数据中的时间为跟踪终端log的电脑的时间，CDL为LDT记录的RNC的信令时间，两个时间之间有一个差值。注意记录好这个时间差，以方便后续出问题时对信令的快速查找。 本例中，UE的时间点为14：23：35，CDL中对应的时间点为14：25：48，因此UE的log对应的所有信令时间点始终比LDT跟踪到的CDL对应的信令时间点提前13秒。五、基站侧ATP软件跟踪物理层消息的方法文档5.1、跟踪消息前的设置准备电脑IP配置路由添加：route add mask 925.2、确认问题小区所属DSP位置以需要跟踪的第一个小区为例，由于此小区三个频点都集中在0机框4槽位的BBU，因此可以在“频点信息指示”中查到对应的BBU板卡的DSP位置，分别为第1、4、5个DSP，即需要跟踪的是DSP0、DSP3、DSP4。此信息至关重要，涉及到后续ATP中对跟踪频点的选择，请务必确认准确。如果验证的站点业务较忙，跟踪频点过多时很容易导致板卡数据量较大，导致板卡任务挂死，碰到这种情况可以减少跟踪的频点解决，本文档