KPI指标提升(RRC建立成功率篇).doc

RRC建立失败问题定位指导书 RRC建立成功率提升 （作者：南京KPI提升团队）Build Excellent TD-SCDMA Network 1 概述本文档主要用于指导KPI提升中对RRC建立成功率指标的提升，对于RRC建立中常见的问题进行分析并给出定位思路和解决方案，用于提升RRC建立成功率。2 背景知识正常情况下，RRC过程的典型流程图如下：3 定位思路使用CDLMR对一个RNC下的CDL进行分析，找到该下在该小区下进行小区详细跟踪或者收集问题小区的文件，对照典型流程确认问题出现在那一步，然后进入不同的分析流程。节号判断条件判断条件为是的处理方法判断条件为否的处理方法3.1信令跟踪（或者文件）未看到RRC CONNECTION REQUEST进入“未收到RRC CONNECTION REQUEST的定位”一节进入.2节3.2信令跟踪（或者文件）中看到RRC CONNECTION REQUEST消息，但是未看到RADIO LINK SETUP REQUEST消息进入“未发送RADIO LINK SETUP REQUEST的定位”一节进入.节；3.3信令跟踪（或者文件）中看到未发送RRC CONNECTION SETUP消息进入“发送RRC CONNECTION REJECT定位”一节进入.节3.4信令跟踪（或者文件）中看到发送RRC CONNECTION SETUP消息，但是基站的没有增加进入“未收到RRC CONNECTION SETUP消息”一节进入.节3.5未收到基站上报的RADIO LINK RESTORE INDICATION进入“未收到RADIO LINK RESTORE INDICATION的定位”一节进入.节3.6信令跟踪（或者文件）中收到RADIO LINK RESTORE INDICATION消息，但未收到终端返回的RRC CONNECTION SETUP COMPLETE进入“未收到RRC CONNECTION SETUP COMPLETE的定位”一节无4 定位方法4.1 未收到RRC CONNECTION REQUEST的定位4.1.1 首先判断小区状态，小区状态为非激活态，进行小区故障的定位过程，定位方法不在本文档范围，小区状态为激活状态（一般用户应该可以驻留在该小区），后续定位转入4.1.2；4.1.2 用户在问题小区进行拨打测试，对象树-逻辑频点-查询载波性能随即接入情况统计 查询FPACH响应数目是否一直增加（见图4.1.2 -1），如果计数不增加。需要检查以下两项，FPACH响应数目正常增加转入4.1.3；（1） 考虑随机接入功率配置问题：查看网络侧设置SYNC_UL的期望接收功率大小，过小则会影响基站SYNC_UL的接收性能，一般经验值设置90dbm；（2） 查看FPACH的发送功率设置大小，一般设置低于PCCPCH功率3db；（3） 确认设备运行正常，小区布配正确图4.1.2 -1 SYNC_UL 统计查询方法4.1.3 在基站侧和RNC侧进行RACH计数统计，基站侧RACH计数统计进行的收发统计抓取方法见“4.3.1 节基站抓取”；l 侧统计方法：在测小区所在的上抓取rnc_tpss_cell_statis_query（CellID，0），其中“ulCchFpRachRecvDataCntr”为计数；小区所在的确认：可以通过查询动态表rDanytableCellId中对应小区的RTPA DSP地址，确定小区所DSP。在计算小区所在单板和DSP方法：ulRTPABoardDSPAddr:2198274349=0x8307012D,12D就是1-2-13单板；07就是DSP ID。一般基站有增加的话，的也是有增加的，如果基站的有增加，但是侧RACH眉头增加，进入. 提取基站的公共日志和主控板所有日志（SCT/CCU）交由基站产品维护人员分析后，决定如何定位。4.2 未发送RADIO LINK SETUP REQUEST的定位这种情况一般是资源分配失败， RNC会发送RRC CONNECTION REJECT消息给终端，失败原因常见的是无线资源和本地资源两种，定位此类问题需要在中找到对应小区建立失败的用户信令，一般在RRC CONNECTION REQUEST消息后有一条资源分配失败的消息RRM_DCA_RESOURCES_ALLOCATION_FAILURE，根据消息中的EventPara字段查询“错误码表”给出的失败原因进一步定位，常见的原因有：（1） 上下行码资源判决失败/上行独立载波判决失败下行独立载波判决失败（对应的EventPara为0x080100060x08010007/0x080100110x08010012）：检查该小区下各载波状态和小区用户情况，如果载波状态正常，在线用户数所占用的资源总合小于小区总的无线资源，需要检查和算法设置是否合适，无异常的话收集出现失败的侧文件、小区详细跟踪、配置数据发给产品维护团队基站组组分析；如果载波状态异常，需要收集基站的公共日志和CCU的43、22000号日志发给产品维护团队基站组分析“载波故障的原因”。（2） 上行ATM资源判决失败下行ATM资源判决失败上行下行ATM资源判决都失败，需要检查该小区所在基站的数据链路参数配置中的带宽资源配置是否合适,一般情况一个载波大概对应2M的ATM资源,因此5载波小区应该有10M的数据链路带宽资源,如果和这个数据差距比较大的话,可能会出现这种带宽资源判决失败的情况；（3） 其他EventPara取值不常见，出现的话提供文件，数据配置文件发给产品维护团队分析定位；4.3 发送RRC CONNECTION REJECT定位（假拥塞）查看失败用户收集文件，对应小区下已经有RADIO LINK SETUP REQUEST消息，但是还是发送有RRC Connection Reject消息，此情况属于一种假拥塞的情况，根据消息中给出的EventPara查询“错误码表”，根据错误码表给出的原因进一步定位。4.3.1 0x09070100/0x090701002( FP配置过程中节点同步失败(发送到最大次数) FP配置过程中传输信道同步失败(发送到最大次数) 如果RRC Connection Reject消息消息中给出的错误码为“0x09070100/0x090701002”，一般情况下是0x09070100，那么就是节点（传输信道）同步失败导致的RRC建立失败。这种情况实际目前没有好的定位方案,只有在比较容易复现时可以定位,总的思路是在和基站作一些信息收集，发给产品团队进行数据分析，确认问题出在还是基站具体方法见下:（1） 确认问题小区所在的接口板架框槽信息以及小区数据链路对应的PVC 信息和信息。图一为承载方式，位置在“承载集”“信息集”问题小区对应的数据链路。图一承载方式数据链路信息图二为承载方式，位置在“承载集”“协议栈子层”问题小区对应通道。（2） 进行小区详细跟踪，确认由于节点同步失败导致RRC建立失败用户所在DSP，找到RRC CONNECTION REQUEST消息下倒数第二条RDBS_RDBS_LC_ALLOCATE_RSP_MSG，该消息种给出了用户分配的RTPA的架框槽和DSP信息。（3） 使用测试诊断命令进行RTPA和接口板之间的媒体面连通性测试，其中RTPA的架框槽和DSP信息就是（2）中得到的信息，接口板的架框槽信息是（1）中得到的，CPU选择2。多进行测试，如果测试不通过的话，需要检查RTPA 和接口板之间的物理连接，但是物理连接出问题的情况还是比较少的。媒体面连通性测试正常的话，说明RTPA到接口板之间的数据通道正常，需要进入（4）继续定位；（4） 如果以上排查后仍不能确认问题所在，需要抓取LOG给研发定位，RNC侧需要利用脚本生成工具生成一些脚本，运行(6) 节插件中给出的脚本生成工具，并按照（1）中给出的单板信息或者局内VPI，VCI信息（ATM方式），VLAN ID，端口号（IP方式）信息，这样在脚本生成工具所放目录会生成一个脚本批处理文件。比如：1-2-1-2_CASA_script.txt。RNC侧LOG 抓取：问题出现前RNC 侧小区所在执行1-2-1-2_CASA_script.txt同时进行小区详细跟踪，在问题复现后再次执行该脚本。基站测试LOG 抓取：1、 提取基站的公共日志和主控板所有日志2、 找出节点同步失败的频点在基站上对应的DSP，使用LMT-B连接基站，对象树-小区资源-查询载波FP信息，查看节点同步失败的DSP的计数，多次查询，查看本地频点收到的节点同步帧和收到后回给RNC的节点同步帧数目上是否对应。（5） 信令跟踪中获取用户RRC信令所建立的数据链路或IP通道信息的方法：进行小区详细跟踪，确认用户建立RRC时分配的PATH 和CID或者，找到RADIO LINK SETUP RESPONSE消息下的一条TNSS_NF_ESTABLISH_REQ消息，其中携带了需要的信息，其中图三为承载方式，图四为方式。图三承载方式的数据链路信息图四承载的通道信息（6） 运行脚本生成工具4.3.2 错误码为其它取值 当失败原因为其它取值时，主要可能和RNC相关，此时需要进行信令跟踪，并对应失败时刻收集CDL文件和运行日志。从运行日志和CDL中进一步分析深层原因。4.4 终端未收到RRC CONNECTION SETUP的定位由于RNC侧层二配置已经成功，此时终端没有收到RRC CONNECTION SETUP消息此时首先从基站侧查询确定基站是否收到RRC CONNECTION SETUP,查询方法见.1 查询小区主频点的RACH、FACH计数对象树-小区资源-逻辑频点-查询小区的FACH。信息，隔几S刷新一次，查看RACH增加过程中，FACH是否有增加。IUB口问题的可能性比较少，如果有增加，说明RNC正常下发了，此时如果UE没有收到，需要按照4.4.2节查看空口的问题,如果没有增加,需要提取基站告警日志,RNC侧信令跟踪,并按照4.3.1 节的方法生成脚本文件在接口板上执行( 问题出现前和出现后各执行1次).将发给产品维护团队定位4.4.2 检查空口问题首先需要从RRC CONNECTION REQUEST消息中确定该用户所在为位置和接入时刻的PCCPCH RSCP，消息中给出的是协议值，真实值和协议值的换算关系是：真实值=协议值-116 如果真实值小于-95的话，有可能和弱覆盖有关，此时需进一步提取该小区下的ISCP报表，因为上下行无线环境一般是一致的，因此上行时隙ISCP可以作为一个参考。4.5 未收到RADIO LINK RESTORE INDICATION的定位 此时基站没有检测到上行同步数据，需要收集该需要基站进一步定位1、 提取基站公共日志和业务失败频点对应的DSP所在板卡的50号日志。2、 提供业务失败的CRNC_CCID，发给基站产品维护定位。4.6 未收到RRC CONNECTION SETUP COMPLETE的定位 已经完成节点同步，说明终端收到了RRC CONNECTION SETUP消息，这种情况一种可能是终端发生了系统间或者系统内的小区重选，目前这种情况仅仅对于用户发生了内的小区重选可以定位，其它两种情况因为涉及到其它RNC和GSM,因此暂时没办法定位.具体定位方法见.6.1,如果还是无法定位，那么按照.6.2给出的方法进行LOG收集.4.6.1 终端重选到其它这个主要从CDL文件中分析,看看在终端出现问题的时间点后是否有相同的TMS/IMSI的RRC CONNECTIONREQUEST消息,例如下面从CDL的LOG可以看出：第一次RRC请求，网络已经收到，UE连接建立原因：OriginatingConversationalCall；Iub资源已经建好，并且下发FACH，其中FACH中携带的期望接收上行功率-102dbm；这里REQ测量的PCCPCH_RSCP是25；而40秒后，UE换小区在6692小区的RACH测量上报PCCPCH_RSCP是17，发生小区重选，同一时间RNC删除27661小区Iub资源；在6692小区又重选到27661小区发起接入，在27661小区接入成功。 一般这种情况需要检查小区下的小区选择和重选参数设置不合适: （1） 小区选择与重选-同频小区测量门限；（2） 小区选择与重选-异频小区测量门限；（3） 小区选择与重选-Gsm测量门限；（4）