常见FAIL原因分析.docx

1 性能监控1.1 概述本文的 error! reference source not found. 、 error! reference source not found. 、 error! reference source not found. 3大章节要是从路测的角度来阐述umts ran kpi的监控与优化的方法，在 error! reference source not found. 章节从方法论的角度阐述了性能分析的总体思路和方法步骤。本章节将通过对rnc、cell级各项kpi的分析，指导一线如何分析整个网络的无线性能状况。本章节介绍的分析方法涉及的输入数据包含以下几类，数据的获取请参考 error! reference source not found. 章节：l 网络配置数据，包含rnc和nodeb的配置数据l rnc的话统数据l rnc的pchr数据l rnc的告警信息本章节kpi涉及的指标是经验参考指标，仅用于指导网优工程师明确kpi监控目标，并不适应于实际项目。针对不同项目，指标数目会有所不同，具体指标取舍和指标取值需要取决于合同的约定。1.2 accessibility analysis1.2.1 rrc analysis1. rrc scenario analysisrrc建立的原因主要有注册、异系统小区重选、主叫、被叫等4类rrc建立原因值，可以将这几类场景下rrc建立的次数进行比较，确认信令资源在哪种类型中消耗比重较大，进一步确认优化的目标。假设注册类rrc的比例为r，小区重选比例为s，那么当满足下述条件时可以认为rrc建立原因比较合理，否则需要优化：( r 30% ) & ( s 30% ) & ( ( r +s ) 50% )优化的手段可以从减少重选次数、增强覆盖等方面考虑。2. rrc success rate analysisrrc建立成功率是运营商比较关注的指标之一，从网络监控的角度来看，该kpi需要在维持设备稳定的基础上，尽量减少话务冲击、版本升级等重大事件对该kpi带来的影响。针对该kpi（假设为r），通用判断条件与判断结果如下：l 条件1：整个rnc的指标满足 98% r，判断为 good。l 条件2：整个rnc的指标满足 95% r 98%，判断为 normal。l 条件3：整个rnc的指标满足 r 95%，判断为bad。满足条件3时，可以认为指标异常，需要通过各种手段来解决问题。3. rrc success rate in different scenario针对该项指标，主要是对比注册、异系统小区重选、主叫、被叫等各个场景下rrc接入指标是否有异常。对于该指标（假设为ri），通用判断条件如下：l 条件1：各个场景下rrc建立成功率指标满足 98% ri，判断为 good。l 条件2：整个rnc的指标满足 95% ri 98%，判断为 normal。l 条件3：整个rnc的指标满足 ri 95%，判断为bad。针对inter-rat cell reselection rrc topn cell analysis，主要是覆盖差的区域，可以从增强覆盖入手，如调整功率配比、调整工程参数、加站等；同时也可以考虑减少异系统小区重选次数和更改异系统小区重选门限来考虑。针对registration rrc topn cell analysis，可以从调整定时器参数，调整覆盖，以及优化lac划分等。4. rrc fail topn cell analysis对于rrc建立失败，包含rrc建立失败以及rrc拒绝2种情况。前者主要是覆盖引起；后者主要是传输、资源拥塞等引起，需要考虑2种失败原因的比值，通用判断条件如下：l （rrc拒绝次数：rrc建立失败） 1:10：rrc失败主要是资源拥塞引起，需要结合pchr、告警文件进一步定位，有针对性的解决资源拥塞问题，比如调整参数，传输资源扩容，ce扩容等。1.2.2 rrc fail常见原因针对rrc建立失败常见的counter，下表给出对应的原因，供参考。表 1-1 rrc fail 常见原因counter中文描述原因vs.rrc.rej.rl.fail小区中rl建立失败导致rrc连接建立决绝的次数可能是nodeb出现故障或者nodeb资源不足，针对ce资源可进一步在关联话统指标中查询此时的小区下行最大ce数，若小于20，则话务量不高，为nodeb设备异常vs.rrc.rej.fp.fail小区中fp建立失败导致rrc连接建立决绝的次数一般是传输故障或者设备故障，需要查看相关基站的告警vs.rrc.rej.aal2.fail小区中aal2建立失败导致rrc连接建立决绝的次数；大部分为传输拥塞导致一般是传输资源不足或者传输出现问题，可进一步在关联话统指标中查询此时的小区下行吞吐量，若低于200kbps，则可能为传输故障vs.rrc.rej.power.cong因功率拥塞而拒绝rrc连接请求的次数rrm准入判决无法建立新的rrc连接，这主要因为小区无线负载太高所致，需查询此时的小区的最大rtwp和最大tcp，确认上行还是下行拥塞，判断是否需要扩容，同时还要查看相关准入策略设置是否合理，比如dccc等vs.rrc.rej.ul.ce.cong vs.rrc.rej.dl.ce.cong小区上行ce资源申请失败小区下行ce资源申请失败rnc内部上行ce资源准入拥塞，需查询关联参数中小区上行ce数，判断是否需要扩容ce。若小于20，则话务量不高，可能为nodeb设备异常rnc内部下行ce资源准入拥塞，需查询关联参数中小区下行ce数，判断是否需要扩容ce。若小于40，则话务量不高，可能为nodeb设备异常。此外，rnc和nodeb的能力不一致等原因也会导致nodeb rl建立失败vs.rrc.rej.code.cong码资源申请失败rrc连接建立时分配码资源失败。这个一般是网络用户太多引起，在室内等微蜂窝覆盖的高业务量场景下，可能出现。可进一步在关联话统指标中查询此时的码有效利用率，若低于30%，则可能码分配算法异常vs.rrc.rej.other.cong因其他拥塞而拒绝rrc连接请求的次数一般为未知的资源不足导致的拥塞，如license资源、cpu占用率高导致流控，fmr处理能力不够等，另外e1故障也出现过该原因值打点；其他原因导致rrc拒绝 异常原因导致，需结合rnc日志进行深入定位，已知问题有网络打开了系统重定向功能，重定向时由于手机不支持gsm导致失败拒绝，rrc.failconnestab.noreply小区中因无应答而导致rrc连接失败的次数一般为覆盖较弱导致，主要是下行的fach信道和rach信道覆盖不平衡1.2.3 rab analysis1. rab scenario analysisrab建立根据不同的场景，可以划分为amr、vp、ps（r99）、hsdpa、hsupa等，可以通过各场景的对比，了解网络的业务状况，分析网络中各种业务的比重。2. rab success rate analysis通常情况下，运营商对于rab建立成功率的要求与对rrc建立成功率的要求基本接近，针对该kpi（假设为r），通用判断条件与判断结果如下：l 条件1：整个rnc的指标满足 98% r，判断为 good。l 条件2：整个rnc的指标满足 95% r 98%，判断为 normal。l 条件3：整个rnc的指标满足 r 95%，判断为bad。上述指标适用于各种业务的建立，包含amr、vp、r99 ps、hspa等，判断为bad的优化措施可以参考下述topn cell分析。3. amr rab fail topn analysis针对amr rab建立失败，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时，需要结合设备告警信息、pchr数据，以及相关网络参数调整等信息入手分析。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：（topn小区的amr rab失败失败 ： 总amr rab失败次数） 25%对于amr rab建立失败的小区，需要结合具体问题具体分析，请参考 cs rab fail 常见原因 。常见的有空口导致的失败、other原因引起的失败：l 针对空口导致的rab失败，需要通过覆盖优化解决。l 对于other原因导致的失败，需要结合chr进一步分析。4. vp rab fail topn analysis针对vp rab建立失败，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：（topn小区的vp rab失败失败 ： 总vp rab失败次数） 25%一般网络中cs amr失败主要以amr rab失败为主，vp rab不是关注的重点。若是vp rab建立成功率异常，分析方法可以参考amr rab的问题定位。5. ps rab fail topn analysis针对ps rab建立失败，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：（topn小区的ps rab失败失败 ： 总ps rab失败次数） 25%对于ps rab建立失败的小区，需要结合具体问题具体分析，请参考 ps rab fail 常见原因 。6. hsdpa rab fail topn analysis针对hsdpa rab建立失败，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：（topn小区的hsdpa rab失败失败 ： 总hsdpa rab失败次数） = 99%2. soft ho fail topn analysis针对soft ho失败，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时，需要结合设备告警信息、pchr数据，以及相关网络参数调整等信息入手分析。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：（topn小区的soft ho失败 ： 总soft ho失败次数） = 99%4. hsdpa serving cell change success rate analysis针对hsdpa serving cell change 成功率，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：一天的hsdpa serving cell change成功率 = 99%5. hsdpa serving cell change fail topn analysis针对hsdpa serving cell change失败，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时，需要结合设备告警信息、pchr数据，以及相关网络参数调整等信息入手分析。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：（topn小区的soft ho失败 ： 总soft ho失败次数） 25%对于hsdpa serving cell change失败的小区，需要结合具体问题具体分析，主要通过告警分析、chr分析定位问题，优化手段有覆盖优化、检查漏配邻区等。6. sho factor analysis针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：sho factor 40%对于sho factor的优化，主要有覆盖优化、调整邻区官须来降低sho factor。1.3.2 hard handover analysis1. hard ho success rate analysis针对hard ho成功率，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。针对该kpi（假设为r），通用判断条件与判断结果如下：l 条件1：整个rnc的指标满足 90% r，判断为 good。l 条件2：整个rnc的指标满足 85% r 90%，判断为 normal。l 条件3：整个rnc的指标满足 r 85%，判断为bad。2. hard ho fail topn analysis针对hard ho失败，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时，需要结合设备告警信息、pchr数据，以及相关网络参数调整等信息入手分析。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：（topn小区的hard ho失败 ： 总hard ho失败次数） 25%对于hard ho失败的小区，需要结合具体问题具体分析，请参考 ho fail 常见原因 。1.3.3 inter-rat handover analysis1. cs inter-rat ho success rate analysis针对cs inter-rat ho成功率，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。针对该kpi（假设为r），通用判断条件与判断结果如下：l 条件1：整个rnc的指标满足 90% r，判断为 good。l 条件2：整个rnc的指标满足 85% r 90%，判断为 normal。l 条件3：整个rnc的指标满足 r 85%，判断为bad。2. cs inter-rat ho fail topn analysis针对hard ho失败，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时，需要结合设备告警信息、pchr数据，以及相关网络参数调整等信息入手分析。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：（topn小区的hard ho失败 ： 总hard ho失败次数） 25%对于hard ho失败的小区，需要结合具体问题具体分析，请参考 ho fail 常见原因 。主要手段有优化网络覆盖，调整cs异系统切换参数，检查gsm邻区配置等。3. ps inter-rat ho success rate analysis针对ps inter-rat ho成功率，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。针对该kpi（假设为r），通用判断条件与判断结果如下：l 条件1：整个rnc的指标满足 90% r，判断为 good。l 条件2：整个rnc的指标满足 85% r 90%，判断为 normal。l 条件3：整个rnc的指标满足 r 85%，判断为bad。4. ps inter-rat ho fail topn analysis针对ps inter-rat ho失败，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时，需要结合设备告警信息、pchr数据，以及相关网络参数调整等信息入手分析。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：（topn小区的hard ho失败 ： 总hard ho失败次数） 25%对于hard ho失败的小区，需要结合具体问题具体分析，请参考 ho fail 常见原因 。主要手段有优化网络覆盖，调整cs异系统切换参数，检查gsm邻区配置等。1.3.4 ho fail常见原因针对ho失败常见的counter，下表给出对应的原因，供参考。表 1-4 ho fail 常见原因分类counter中文描述原因shosho.failrladdueside.cfgunsup配置不支持导致软切换无线链路增加失败ue认为rnc增加/删除链路的活动集更新的内容不支持。这种场景在商用中基本不会出现sho.failrladdueside.isr不支持的同步重配置导致软切换无线链路增加失败ue反馈rnc增加/删除链路的更软/软切换过程与其他并发过程不兼容。rnc在流程处理的时候已经保证了串行处理，出现这种情况主要是一些手机自身处理出现问题sho.failrladdueside.invcfg非法配置导致软切换无线链路增加失败ue认为rnc增加/删除链路的活动集更新的内容非法。这种场景在商用中基本不会出现sho.failrladdueside.noreplyue无响应导致更软切换无线链路删除失败rnc没有收到增加/删除链路的活动集更新命令响应。这个在网络中是更软/软切换失败的主要原因，主要是发生在覆盖比较差或者切换区比较小的区域，需要rf优化vs.sho.fail.other.cell其他原因导致软/更软切换失败结合chr进一步定位问题hhovs.hho.interfreqout.cfgunsupp配置不支持ue认为硬切换出小区的命令不支持，一般为手机兼容性问题vs.hho.interfreqout.pyhchfail物理信道失败可能为覆盖较差或者干扰较严重vs.hho.interfreqout.failusr同步重配置不支持ue反馈硬切换过程与其他并发过程不兼容，可能为手机自身兼容性问题vs.hho.interfreqout.cellupdt出现小区更新在硬切换出小区的过程中，发生了小区更新，这种流程嵌套导致了硬切换出小区失败vs.hho.interfreqout.cfginvalid非法配置(ue认为硬切换出小区的命令非法，一般为手机兼容性问题vs.hho.interfreqout.noreplyue无响应主要由覆盖比较差或者手机问题引起vs.hho.interfreqout.dlcoderej下行码资源分配失败导致的异频硬切换出本小区失败结合chr进一步定位问题vs.hho.interfreqout.uladmsndeny上行准入拒绝导致的异频硬切换出本小区失败可以查看ce，rtwp，小区退服，小区支持能力，话务量等资源是否不足。vs.hho.interfreqout.dladmsndeny下行准入拒绝导致的异频硬切换出本小区失败可以查看ce，tcp，小区退服，小区支持能力，话务量等资源是否不足。需要考虑是否存在覆盖越区严重和切换区不合理，考虑是否需要加强覆盖区域内的高话务区域的室内覆盖vs.hho.interfreq.failother其他原因结合chr进一步定位问题cs interrat hhoiratho.failoutcs.cfgunsupp配置不支持ue认为硬切换伴随迁移出小区的命令不支持，一般为手机兼容性问题iratho.failoutcs.phychfail失败原因为物理信道失败主要是2g信号比较弱或者干扰比较严重导致ue接入失败vs.iratho.failoutcs.other其他。需要根据rnc的日志及核心网与bss的信令跟踪进行进一步的分析ps interrat hhoiratho.failoutpsutran.cfgunsupp配置不支持ue认为硬切换伴随迁移出小区的命令不支持，一般为手机兼容性问题iratho.failoutpsutran.phychfail失败原因为物理信道失败主要是2g信号比较弱或者干扰比较严重导致ue接入失败vs.iratho.failoutpsutran.other其他。需要根据rnc的日志及核心网与bss的信令跟踪进行进一步的分析1.4 reliability analysis1.4.1 call drop rate analysis通常情况下，运营商比较关注cdr。针对该kpi（假设为r），cs的通用判断条件与判断结果如下：l 条件1：整个rnc的amr或者vp的cdr指标满足 r 1% ，判断为 good。l 条件2：整个rnc的amr或者vp的cdr指标满足 1% r 1.5% ，判断为 normal。l 条件3：整个rnc的amr或者vp的cdr指标满足 1.5% r，判断为bad。针对该kpi（假设为r），r99 ps的通用判断条件与判断结果如下：l 条件1：整个rnc的r99 ps的cdr指标满足 r 1% ，判断为 good。l 条件2：整个rnc的r99 ps的cdr指标满足 1% r 3% ，判断为 normal。l 条件3：整个rnc的r99 ps的cdr指标满足 3% r，判断为bad。针对该kpi（假设为r），hsdpa cdr的通用判断条件与判断结果如下：l 条件1：整个rnc的r99 ps的cdr指标满足 r 3% ，判断为 good。l 条件2：整个rnc的r99 ps的cdr指标满足 3% r 5% ，判断为 normal。l 条件3：整个rnc的r99 ps的cdr指标满足 5% r，判断为bad。1.4.2 amr call drop rate topn analysis针对amr cdr，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。需要结合设备告警信息、pchr数据，以及相关网络参数调整等信息入手分析。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：(topn小区的amr cdr失败 ： 总amr cdr失败次数) 25%对于amr cdr失败的小区，需要结合具体问题具体分析，请参考 cs cdr常见原因 。主要手段有优化网络覆盖，检查邻区配置，检查设备是否存在异常等。1.4.3 vp call drop rate topn analysis针对vp cdr，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。需要结合设备告警信息、pchr数据，以及相关网络参数调整等信息入手分析。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：(topn小区的vp cdr失败 ： 总vp cdr失败次数) 25%对于vp cdr失败的小区，需要结合具体问题具体分析，请参考 cs cdr常见原因 。主要手段有优化网络覆盖，检查邻区配置，检查设备是否存在异常等。.1.4.4 r99 ps call drop rate topn analysis针对r99 ps cdr，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。需要结合设备告警信息、pchr数据，以及相关网络参数调整等信息入手分析。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：(topn小区的r99 ps cdr失败 ： 总r99 ps cdr失败次数) 25%对于r99 ps cdr失败的小区，需要结合具体问题具体分析，请参考 ps cdr常见原因 。主要手段有优化网络覆盖，检查邻区配置，检查设备是否存在异常等。1.4.5 hsdpa call drop rate topn analysis针对hsdpa cdr，可以按照天来分析，找出成功率低的时间，时间粒度一般需要定位到小时。需要结合设备告警信息、pchr数据，以及相关网络参数调整等信息入手分析。针对该kpi，如果满足下述条件，可以认为分布比较合理，否则需要优化：（topn小区的hsdpa cdr失败 ： 总hsdpa cdr失败次数） 25%对于hsdpa cdr失败的小区，需要结合具体问题具体分析，请参考 ps cdr常见原因 。主要手段有优化网络覆盖，检查邻区配置，检查设备是否存在异常等。1.4.6 cdr 常见原因针对cdr常见的counter，下表给出对应的原因，供参考。表 1-5 cs cdr常见原因counter中文描述原因vs.rab.relreqcs.omom干预导致的掉话数操作维护工作导致的掉话，比如：在lmt上执行trg rabrel导致用户被释放vs.rab.relreqcs.rabpreemptrab抢占导致的掉话数高优先级用户准入拒绝时抢占低优先级用户，引起链路释放。这种掉话在负载和资源不足的时候发生，根据发生的次数确定是否扩容vs.rab.relreqcs.utrangenutran产生的原因导致的掉话数小区中utran产生的原因导致链路异常释放。这种情况一般对应着处理异常，需要通过cdl进一步分析vs.rab.loss.cs.rf.rlcrstrlc复位导致的掉话数上行或者下行信令rb达到最大重传次数发生复位，引起链路释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况）vs.rab.loss.cs.rf.ulsync上行链路失步引起的异常释放rnc收到nodeb上报的rl failure，引起链路异常释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况），导致ue异常关闭发射机或者上行解调失步vs.rab.loss.cs.rf.dlsync下行链路失步引起的异常释放收到手机上报的cell update消息，原因为下行rl failure，引起链路异常释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况），导致ue异常关闭发射机或者上行解调失步vs.rab.loss.cs.rf.uunoreplyuu口无响应导致的掉话数ue空口无响应系统发出的命令，覆盖不好导致vs.rab.loss.cs.rf.oth其他rf原因导致的掉话数射频原因，均属于覆盖质量不好vs.rab.loss.cs.aal2lossaal2链路异常导致的掉话数rnc发现iu cs接口aal2 path异常，发起了异常释放，可能为iu接口的传输设备异常，已知问题有rb建立过程中马上正常释放被话统统计为该原因异常释放vs.call.drop.cs.other其他原因导致的掉话数可能为流程交互或小区更新中的掉话而话统没有打点，或iub接口的传输故障、rnc内部原因、bug等导致的异常掉话、小区闭塞等，也可能是异常原因掉话，需结合rnc日志进行分析，已知有因上行信号发生了剧烈的变化（拐角效应或是从楼宇阴影区驱车出来）而导致的掉话被统计到该原因。表 1-6 ps cdr常见原因counter中文描述原因vs.rab.relreqps.omom干预导致的掉话数操作维护工作导致的掉