CS业务KPI指标分析指导书

1、cs业务kpi优化指导1 概述本文从话统与路测的角度深入分析了整个接入过程，并讨论了接入的性能指标优化及其影响因素，以及在实际网络规划中对接入过程分析步骤和可能遇到的相关问题的解决办法。cs业务kpi指标用来衡量cs业务的接入性能，是反映网络服务提供能力的重要指标之一。无线接通率体现网络端到端的接入性能，反映rnc或者小区的ue接纳能力，rrc连接建立成功意味着ue与网络建立了信令连接；rab连接建立成功表明ue与网络间用户面连接建立成功，用户面连接用于ue和cn之间传送语音、数据及多媒体业务。ue首先要完成rrc连接建立然后才能建立rab，当rab建立成功以后，一个基本的呼叫即建立，ue进入

2、通话过程。2 cs业务kpi指标定义cs无线接通率=cs域rab建立成功率*rrc连接建立成功率。3 整体分析流程4 网络信息收集4.1 网络基本信息网络基本信息收集主要包括以下几个方面：u rnc参数配置文件u nodeb参数配置文件收集u 基站工参表4.1.1 rnc参数配置文件了解网络中各rnc的软件实体与硬件实体配置情况，了解基本的网络参数配置与分布。4.1.2 nb参数配置文件了解网络中各nb的软件实体与硬件实体配置情况，了解基本的网络参数配置与分布。4.1.3 基站工参表了解网络的网元分布、传输配置、天馈系统分布与配置，为rf优化提供必要依据。4.2 网络kpi信息对网络的cs业务

3、kpi信息进行收集，主要收集路测与话统的cs业务接通率与掉话率指标，收集方法如下：4.2.1 路测kpi信息测试方法：采用专用测试终端，配合数据收集软件，按照中国移动要求的测试方法，沿制定号的测试路线进行路测。指标计算方法：指标名称指标定义无线网络覆盖指标pccpch rscp室外-95dbm的概率大于90,室内-85dbm的概率大于90 pccpch c/i室外c/i-3db的概率大于90 整体覆盖率采样点（pccpch rscp =-95dbm & c/i =-3db）/总采样点100cs业务接通率指标rrc连接建立请求次数ue发送的rrc connection request（原因码为o

4、riginatingcoversationalcall）总次数（如果是一次接入过程中重发的rrc connection request只算第一次）rrc连接建立成功次数统计rnc接收到的rrc connection complete信令总次数rrc连接建立成功率rrc connection complete信令总次数/rrc连接建立尝试次数rab建立成功次数rnc收到rab complete信令总次数rab指派次数rnc发送rab setup信令总次数rab连接建立成功率rab指派建立成功次数/rab建立请求次数无线接通率rab建立成功率*rrc连接建立成功率呼叫请求次数从ue侧统计信令，统计

5、rrcconnectionrequest信令总次数呼叫接通次数从ue侧统计信令，统计connect或connect ack信令总次数呼叫建立成功率用connect或connect ack信令总次数除以rrcconnectionrequest总次数得到端到端的语音呼叫成功率cs业时延指标rrc时延手机发送rrcconnectionrequest消息（如果有重发，只算最早的一条），到rnc收到rrc setup complete消息的间隔rab时延rnc发送rb setup消息，到rnc收到rb setup complete消息的间隔呼叫时延主叫手机发送rrcconnectionrequest消息

6、（如果有重发，只算最早的一条），到主叫手机收到alerting消息的间隔cs业掉话指标掉话次数在手机没主发disconnect信令或收到网络下发release信令情况下，手机收到rrc release消息或进入idle状态,算为一次掉话掉话率掉话率（主叫掉话+被叫掉话）/（主叫接通+被叫接通）100切换指标切换成功次数物理信道重配置成功次数切换次数物理信道重配置次数切换成功率物理信道重配置成功次数/物理信道重配置次数切换时延物理信道重配置成功时间与物理信道重配置成功时间差4.2.2 话统kpi信息计算rrc成功率需提取的counter: n rrc.succconnestab.1 n rrc.

7、succconnestab.6n rrc.attconnestab.1 n rrc.attconnestab.6计算方法：cs rrc连接建立成功率=(rrc.succconnestab.1 +rrc.succconnestab.6)/(rrc.attconnestab.1 +rrc.attconnestab.6)*100%计算rab成功率需提取的counter:n rab.succestabcsnoqueuing.conv n rab.succestabcsnoqueuing.strmn rab.succestabcsqueuing.conv n rab.succestabcsqueuing

8、.strmn rab.attestabcs.conv n rab.attestabcs.strm计算方法：cs域rab建立成功率=（rab.succestabcsnoqueuing.conv +rab.succestabcsnoqueuing.strm+rab.succestabcsqueuing.conv +rab.succestabcsqueuing.strm）/（rab.attestabcs.conv +rab.attestabcs.strm）*100%cs无线接通率=cs域rab建立成功率*rrc连接建立成功率。5 网络状态评估网络状态评估的主要目的是：n 了解并确认全网rnc和nod

9、eb软件版本配置一致n 了解并确认全网各网元硬件配置符合规划设计n 了解并确认全网各网元工作状态n 根据话统与路测数据对网络进行基本评估，了解当前网络实际的运行状态n 利用获得的网络信息，评估网络状态，对一些基本情况进行排查。5.1 站点状态评估5.1.1 站点软件信息对网络站点状态评估，需明确当前网络各网元软件版本配置情况，确认当前站点的工作状态。网元版本补丁rncnodebomc5.1.2 站点工作状态采用站点健康检查工具，了解当前网络中各站点与小区的运行状态，确认各网元的运行稳定性。5.2 频点扰码核查频点扰码核查的主要目的是防止频点与扰码的使用不均衡性，避免某个频点或扰码被过多的使用或

10、不使用。最理想的扰码复用度小区个数/扰码数从上面统计可以看到：1） 个别扰码，像0扰码组只用了一次，复用很不好，这样造成扰码组17的复用很差，邻区中出现同频同码的概率增大；2） 11扰码组没有使用过一次，扰码资源浪费；3） 统计毛刺太多，不能平均，需要对个别扰码组进行地理平均。5.3 邻区核查邻区核查的目的是了解当前网络的各小区的邻区关系分布，排查单向邻区、超远邻区、漏配邻区状况。5.4 网络kpi数据分析结合路测数据与话统数据，对cs业务的kpi指标进行对比：话统kpi路测kpi备注对比结果1.话统kpi若好于路测kpi，需重点排查测试路线上的小区参数配置、邻区配置，根据路测log信令，确认

11、指标较低的原因。2.若路测kpi好于话统kpi，对话统数据进行分析，查找top小区，分析原因。3.话统kpi与路测kpi都较差，需重点排查网络小区的参数配置、与站点规划文件对比、根据数据分析原因。6 网络指标提升6.1 分析思路6.1.1 cs业务接通率（路测）cs业务接通率路（路测）的指标由于ue侧可以提供相关的log结合rnc侧log能够提供工程师一个可视化的界面，对于问题点的定位可以做到一目了然，因此，优化相对较直观。路测接通率可以从以下几方面分析落实：rrc阶段的影响主要表现为以下三类：a. 多次发送rrc请求无响应b. ue未收到rrc setup消息c. rnc未收到ue发送的ac

12、k消息对于问题a，可以检查prach信道和uppch信道的开环功控参数，根据ue侧log明确发起业务时所处位置的pccpch rscp c/i，结合地理位置环境排除干扰影响，对于载波存在干扰可能性的影响，可以通过rnc进行监测上行的iscp，排除干扰影响。主叫手机排除流程被叫手机排查流程对于问题b，首先检查rnc侧log是否收到ue的rrc请求并确认是否下发setup消息，若已经下发setup消息，检查pccpch rscp和c/i，排除弱覆盖影响，同时检查小区的fach信道功率设置，保证sccpch信道的覆盖范围与pccpch信道相匹配。对于问题c，检查ue侧log，确认ue是否已经上报ac

13、k消息，若ue已经上报该消息，检查dch开环功率设置。rb流程分为两个部分：utran在原来的dpch上发送rb setup消息给ue；ue在新的dpch上回复rb setup cmp消息给utran。原有的dpch一直处在内环功控中，并且ue和核心网在nas层消息也有过交互，因此下发rb setup消息出现问题的可能性并不是很大。从功能实现来讲，rb setup消息配置错误的概率也很低。因此问题一般都是出在ue回复rb setup cmp消息这一步上。ue在新的dpch上回复rb setup cmp之前，会先作专用信道同步。在进行专用信道同步时，ue会采用网络侧配置的初始功率来发送speci

14、al burst。nodeb也是采用网络侧的提供的初始发射功率进行special burst进行发射。ue在新的链路同步上以后，就可以采用闭环功控来进行功率调整，等激活时间生效，就可以采用新的功率在新的链路上发送rb setup cmp到utran。在此过程中，专用信道同步失败会导致ue建立rb失败。如果ue配置成功，同步也成功，但是在发送rb setup cmp后，utran收不到该消息，在统计时，也会统计为失败。另外，激活时间太短，导致ue那边来不及处理或者同步，也会导致rb建立失败。6.1.2 cs业务接通率（话统）cs业务接通率的分析思路主要是基于以下原则进行：1.区分业务统计cs业务

15、由amr语音业务和vp业务构成，在做相关指标统计分析时，因分别分析统计分析，最后综合cs业务整体kpi指标考虑。2.室内与室外业务分别统计分析。这样可以把问题隔离化，在优化时可以根据小区地理环境类型的不同采取相应的优化措施。3.落实问题结点。cs业务接通是由rrc接通率和rab接通率计算构成，因此，了解rrc接通率和rab接通率的状况，确定指标异常的出现点。4.topn小区处理。筛选对cs业务指标造成影响的topn小区，基于上述3个指标的分类统计结果，可以跟踪topn小区的u口信令，抓取相关信息分析确认。5.结合pchr数据联合分析定位，基于话统异常原因提示和pchr异常原因提示，分别对小区、

16、终端、rrc异常原因、rab异常原因归类分析。6.1.3 cs业务掉话率（路测）引起路测数据cs业务掉话的主要原因不外乎以下几类原因：n 覆盖覆盖优化主要时排除导频弱覆盖和dpch弱覆盖，同时关注导频污染，通过rf优化解决因覆盖问题造成的掉话。n 干扰干扰可以通过干扰排查工具，确认系统内或系统外的干扰源，对于系统内的干扰源，通过频点、扰码优化与rf优化解决，对于系统外的干扰，根据干扰源的类型分情况解决。n 切换异常（系统内与系统间）路测切换异常引起的掉话，需要核查问题点小区的邻区配置、切换关系的合理性等。6.1.4 cs业务掉话率（话统）话统中cs业务掉话率的统计可以采用与接通率相同的方式进行

17、，即：1.区分业务统计cs业务由amr语音业务和vp业务构成，在做相关指标统计分析时，因分别分析统计分析，最后综合cs业务整体kpi指标考虑。2.室内与室外业务分别统计分析。这样可以把问题隔离化，在优化时可以根据小区地理环境类型的不同采取相应的优化措施。3.topn小区处理。筛选对掉话次数较高的topn小区，可以跟踪topn小区的u口信令，抓取相关信息分析确认。4.结合pchr数据联合分析定位，基于话统异常原因提示和pchr异常原因提示，分别对小区、终端和掉话异常原因分布归类分析。6.2 参数核查参数核查主要包含以下几个方面：1. rnc配置参数核查。检查rnc配置参数是否使用了性能部推荐参数

18、，特别是针对一些rnc级的软参、开关等。2. 小区配置参数核查。邻区配置一致性检查尤为重要。6.3 话统指标分析6.3.1 分析目的采用话统数据对指标进行量化，可以采用rnc级指标对某一rnc的cs业务指标进行考核，采用cell级指标对小区级的cs业务考核，根据rnc级指标对整体性能评估，根据cell级指标对小区为单位的网元进行评估，并根据话统数据对问题小区进行筛选与定位。6.3.2 分析手段cs业务话统原始counter以及关联指标。6.3.3 分析流程1. 提取话统数据，采用话统专项处理工具，对话统数据进行处理2. 话统数据处理的结果，明确整体指标的状况，筛选top小区待处理3. 对与to

19、p小区，按着接入或掉话统计的相关关键信令点，参照话统数据的异常原因提示进行分析处理，必要时可以对问题小区进行信令跟踪，提供进一步分析与定位的依据。4. 根据分析结果，制定优化方案，实施验证。6.3.4 分析标准话统分析的标准对于cs业务接通率，我们首先基于cs接通率为基准筛选，选出接通率低于优化目标的小区，完后根据rrc接通率和rab接通分别进行原因定位，此时我们要考虑rrc失败次数和rab失败次数的影响，基于接通率较低筛选的top小区，可能业务量较少，虽然接通率较低，但产生的失败次数不足以对全局指标产生影响，该类型小区可不计入top小区。因此，对于接通率的优化，我们建议重点关注rrc和rab

20、失败次数较高的小区为标准。对于掉话率，建议以掉话次数为依据作为判断top小区的标准。6.3.5 分析结果输出可以采用性能话统专项处理工具，输出以下数据：6.3.5.1 rnc级指标输出6.3.5.2 接通率top小区cs域rrc接通率top小区语音电话rab接通率top小区视频电话rab接通率top小区6.3.5.3 掉话率top小区vp掉话率top小区amr掉话率top小区：6.3.6 话统top问题处理流程6.3.6.1 话统接通率处理流程基于上面的输出结果，我们对cs业务kpi指标和影响kpi指标的top小区已经了解并确认，接下来的主要问题时对top小区进行问题分析与定位。1. 采用话统

21、数据对top小区进行定位，此时我们可以采用话统数据中与cs业务接入和掉话相关的错误原因提示进行初步的分析。6.3.6.2 rab接入失败原因分析与定位cs rab失败counter含义分析rab.failrabassignestabcs.66电路域rab指配建立失败的rab数目在为用户建立iu接口的用户面时，出现了某种错误，导致iu接口的连接建立失败。出现了这种情况时，需检查iu口的通道是否正常。rab.failrabassignestabcs.5电路域rab指配建立失败的rab数目如果rnc支持排队抢占功能，当一个用户处于排队过程中，如果该用户排队时间过长，则把会出现由于排队超时导致rab建

22、立失败。如果出现这种问题，一般来说小区应该已经拥塞，在建网初期不会出现。rab.failrabassignestabcs.115电路域rab指配建立失败的rab数目无法归类到其他原因的rab失败，如果出现这种原因，需要跟踪该小区的log，特别是内部的消息，查看内部流程是到了哪一步失败。rab.failrabassignestabcs.114电路域rab指配建立失败的rab数目在小区拥塞、或者某种资源（比如hs）不足时，又不支持排队抢占，则会回复这种原因。在建网初期，这种情况不会出现rab.failrabassignestabcs.19电路域rab指配建立失败的rab数目cn发给rnc的rab指

23、派消息中，rab参数不符合协议。这种原因基本不会出现。rab.failrabassignestabcs.20电路域rab指配建立失败的rab数目rnc在为一个rab进行资源分配时，如果现有资源无法支持该rab的速率要求，又不支持排队抢占，则会上报最大速率不支持。在建网初期，该原因值不太容易出现。6.3.6.3 rrc接入失败原因与定位rrc失败counter（不区分业务）含义分析rrc.failconnestab.1rrc连接失败次数当ue 发rrc connection req，收不到setup消息，重发request消息，当达到n300次，还没收到setup，则rrc建立失败，原因置为“拥

24、塞”。在建网初期，基本上不会发生拥塞，如果出现这个原因，应该检查一下nodeb是否正常rrc.failconnestab.rlsetupfailrrc连接失败次数当iub口出现问题，或者nodeb直接回复rl建立失败，就会导致rl建立失败，从而导致rrc建立失败，原因置为”rl 建立失败”。如果出现这个原因，需检查一下nodeb是否正常。rrc.failconnestab.fpsynfailrrc连接失败次数在为用户建立iub接口用户面时，rnc建好了dch的fp之后，会发起fp同步过程，如果该过程失败，即认为rrc建立失败。如果出现fp同步失败，需检查iub接口的用户面是否有问题。同时可以跟

25、踪nodeb那边，是否收到了fp同步帧来确认上下行同步是在哪一步出现了问题。rrc.failconnestab.aal2setupfailrrc连接失败次数为用户建立iub接口的用户面时，需先建立aal2的链路。如果aal2链路建立失败，后续的fp、macd等都无法建立。如果出现aal2建立失败，同样需要检查iub接口的通道是否正常，比如path是否配置合理。2.结合pchr数据，对top小区的异常接入原因进一步明确，确认异常小区接入失败发生原因的信令点分布。接入失败原因:null34248/17171(199.45%)rr_err_rncap_rrc_ue_rsp_timeout801/17

26、171(4.66%)nbm_cra_cell_err_code_begin nbm_cra_cell_err_code_end635/17171(3.70%)rr_err_rncap_reloc_phy_ch_recfg_cmp_timeout25/17171(0.15%)rr_err_iu_interface_fail_in_radio_interf_proc13/17171(0.08%)rr_err_iu_interface_unknown_target_rnc8/17171(0.05%)rr_err_iub_interface_requested_configuration_not_su

27、pported8/17171(0.05%)rr_err_rncap_reloc_iu_req_security_mode_algor_not_supp5/17171(0.03%)rr_err_rncap_reloc_sec_reloc_req_timeout3/17171(0.02%)rr_err_iu_interface_timer_reloc_cmp_expiry3/17171(0.02%)rr_err_iu_interface_reloc_cancelled2/17171(0.01%)rr_err_rncap_rl_cause_nodeb_timeout1/17171(0.01%)rr_

28、err_iu_interface_normal_release1/17171(0.01%)3.跟踪top小区的u口信令，进一步了解接入失败发生的信令点，对问题小区进行明确化。4.综合上述问题的原因定位，落实优化策略，实施优化方案，验证优化思路。6.3.6.4 话统掉话率处理流程分析方法同接通率。6.3.7 话统top问题处理案例6.3.7.1 问题现象二期某局点话统指标优化，cs业务接通率优化目标为98%，话统连续统计观察指标，发现接通率只有96%左右，基于小区级指标筛选，发现如下问题（以某个小区为例）：6.3.7.2 定位思路1. 获取话统原因2. 现场cqt测试3. 跟踪小区信令，抓取lo

29、g4. 根据信令抓取的问题现象，确认问题所在6.3.7.3 排除过程小区的话统原因中对如此高的失败没有提示原因，因此决定进行现场配合测试，机房配合抓取log，进行信令分析，测试中发现， ue侧rrc连接完成消息不能及时送上来；一般都在rnc连续下发67条rrc连接建立后，才能收到ue上报的cmp消息。分析l3信令，rrc conn req发上来后，rnc立刻做了rl建立的处理，并且得到了nodeb响应；rnc给手机发送rrc conn setup，手机也收到了该消息；比较奇怪的是手机没有上发rrc conn setup cmp，而是等了2秒后重新发rrc conn req。如此反复了67次，u

30、e终于回应了一条rrc conn setup cmp消息。对比此处异常和正常rrc_conn_setup，只有ul-targetsir不一样；正常大约都在41，此处异常的则为3。此处的ul-targetsir，其计算公式为：上行期望发射功率路损上行干扰余量rnc下发消息中的ul-targetsir太小，因此检查该问题小区的上行干扰余量（ulinterferersv），发现该参数设置偏低，仅为15，造成ue在dch的上行初始功率太低。6.3.7.4 排查结果调整上行干扰余量到3，增加ue在dch上发送rrc conn setup cmp的初始发射功率，以让rnc及时的收到此消息。6.4 指标关联

31、性分析6.4.1 分析目的在分析完cs业务自身的接入指标和掉话指标，我们可以参考与cs业务接通率和掉话率相关联的指标进行对比、参照、影响分析。6.4.2 分析手段与cs业务接通率和掉话率相关的话统指标和pchr数据。6.4.3 关联指标选取标准关联指标对掉话率的影响，我们主要关注一些掉话次数较多的top小区，观察该小区关联的切换失败次数，若该小区的切换失败次数较多，可能会造成切换掉话，因此，需要对该关联指标进行重点关注。接通率仅做对比，排除因业务所在域不同的某个网元配置错误或异常引起某个业务的指标异常，无内在关联性。6.4.4 分析流程6.4.4.1 cs接通率关联指标cs接通率指标与其他指标

32、无强相关性，若cs业务接通率指标异常，可参照ps业务接通率指标对比，看问题小区的异常性是否与业务相关。6.4.4.2 cs掉话率关联指标与cs业务掉话率关联指标主要由于切换失败（rnc内切换和rnc间切换）、cs业务23g切换失败造成的掉话。排查流程：需检查的话统counter:rnc间硬切换切出成功次数hho.succoutinterrncrnc间硬切换切出尝试次数hho.attoutinterrncrnc间硬切换成功率(rnc切换出)hho.succoutinterrnc/hho.attoutinterrnc系统间电路域切换成功次数iratho.attoutcs系统间电路域切换尝试次数ir

33、atho.succoutcsrnc内同频接力切换尝试次数bho.attbhointrafreqintrarncrnc内同频接力切换成功次数bho.succbhointrafreqintrarncrnc内异频接力切换尝试次数bho.attbhointerfreqintrarncrnc内异频接力切换成功次数bho.succbhointerfreqintrarnc6.4.5 分析结果与输出需输出以下指标：优化项输出关联指标优化作用cs接通率（rnc级）ps接通率（rnc级）对比、参照，排除业务的影响cs业务rrc成功率（rnc级）ps业务rrc成功率（rnc级）对比信令关键阶段的差别cs业务rab成

34、功率（rnc级）ps业务rab成功率（rnc级）对比信令关键阶段的差别cs接通率（cell级）ps接通率（cell级）top小区分析对比，排除业务的影响cs业务rrc成功率（cell级）ps业务rrc成功率（cell级）top小区分析对比，排除业务的影响cs业务rab成功率（cell级）ps业务rab成功率（cell级）top小区分析对比，排除业务的影响cs业务掉话率top小区分析切换成功率（系统内、与top小区关联）切换失败次数较多，可影响掉话率cs业务掉话率top小区分析切换成功率（系统间、与top小区关联）切换失败次数较多，可影响掉话率cs业务掉话率top小区分析切换成功率（跨rnc、与

35、top小区关联）切换失败次数较多，可影响掉话率6.4.6 分析结果处理流程6.4.6.1 cs接通率关联指标处理6.4.6.2 cs掉话率关联指标处理6.4.7 指标关联处理案例6.4.7.1 问题现象某局点客户投诉，cs业务无法建立，现象为cs业务基本无法使用。6.4.7.2 定位思路1. 由于客户仅投诉cs业务使用不正常，因此，观察ps业务是否正常2. 拨打cs业务，机房配合抓取rnc侧log，定位信令流程点3. 分析信令，确定问题所在6.4.7.3 排除过程1. ps业务拨打正常，无异常现象发生2. 拨打cs业务，发现cs业务无法正常建立3. 分析rnc侧log，发现ue在rrc阶段流程

36、正常，但在初始直传消息上报以后，cn未能正常下发common_id消息给rnc，造成呼叫失败。6.4.7.4 排查结果与cn工程师进行联合检查，发现是cn工程师对cs域的配置错误造成，修改后，业务可以正常建立，指标恢复正常。6.5 pchr数据分析6.5.1 分析目的采用pchr数据可以有效起到对话统统计异常kpi原因定位的补充作用。pchr数据可以实现对接通和掉话基于小区、终端类型、用户等统计，通过对pchr数据的分析，可以明确造成指标异常的原因所在。6.5.2 分析手段pchr统计数据。6.5.3 分析流程根据指标的异常情况，结合信令关键点，我们可以采用pchr数据做进一步分析，借助pch

37、r数据我们首先要排除终端异常的影响，完后与top小区和top原因分析结果结合，对影响指标的关键原因所在，落实到点，根据问题结点所在进行优化方案的制定。6.5.4 分析结果与输出6.5.4.1 cs掉话率分析（基于业务掉话原因统计）cs_amr业务:rr_err_rncap_rlc_failure_srb_rst26/54(48.15%)无掉话原因14/54(25.93%)rr_err_rncap_alcfg_iub_aal2_failure11/54(20.37%)rr_err_rncap_del_old_ccb3/54(5.56%)cs_vp业务:cs_other业务:6.5.4.2 cs掉

38、话率分析（基于小区的掉话原因统计）掉话原因:1036:37113:rr_err_rncap_rb_wait_ue_rb_cfg_timeout2/3(66.67%)无掉话原因1/3(33.33%)6.5.4.3 cs掉话率分析（基于imei的掉话统计）按手机统计:掉话率:860108003/6(50.00%)860103001/2(50.00%)8601090012/29(41.38%)869002003/8(37.50%)860158001/3(33.33%)869007008/27(29.63%)86003900197/797(24.72%)8600160037/173(21.39%)6.

39、5.4.4 cs掉话率分析（基于imei的掉话原因统计）掉话原因:86010900:nbm_cra_cell_err_code_begin nbm_cra_cell_err_code_end5/11(45.45%)rr_err_rncap_alcfg_iub_aal2_failure3/11(27.27%)nbm_iub_reset nbm_iub_check1/11(9.09%)rr_err_iub_interface_permanent_rl_failure1/11(9.09%)rr_err_rncap_rlc_failure_srb_rst1/11(9.09%)6.5.4.5 cs接通率

40、分析（基于接入失败原因）接入失败原因:null30356/18056(168.12%)rr_err_rncap_rrc_ue_rsp_timeout1935/18056(10.72%)nbm_cra_cell_err_code_begin nbm_cra_cell_err_code_end711/18056(3.94%)rr_err_iub_interface_requested_configuration_not_supported82/18056(0.45%)rr_err_iu_interface_requested_info_not_avail19/18056(0.11%)rr_err_

41、rncap_reloc_phy_ch_recfg_cmp_timeout18/18056(0.10%)rr_err_iu_interface_timer_reloc_cmp_expiry13/18056(0.07%)rr_err_iu_interface_fail_in_radio_interf_proc12/18056(0.07%)rr_err_rncap_rl_cause_nodeb_timeout8/18056(0.04%)l2err_fpmdc_errorcode_base l2err_fpmdc_assemble_tm_dl_dch_tbs_faile3/18056(0.02%)rr

42、_err_rncap_alcfg_iub_aal2_local_fail3/18056(0.02%)rr_err_rncap_reloc_sec_reloc_req_timeout1/18056(0.01%)6.5.4.6 cs接通率分析（基于top小区的接入失败原因）684:37261:rr_err_rncap_rrc_ue_rsp_timeout260/1(26000.00%)6.5.4.7 cs接通率分析（基于imei的统计）按手机统计:小区号接入成功率:352372024/5(80.00%)86004000401/490(81.84%)86900500378/438(86.30%)86

43、007500639/719(88.87%)6.5.4.8 cs接通率分析（基于imei的接入原因统计）接入失败原因:86004000:null284/120(236.67%)rr_err_rncap_rrc_ue_rsp_timeout89/120(74.17%)6.5.5 分析结果处理流程6.5.5.1 典型pchr输出接入异常原因排查方案接入失败原因:原因分析rr_err_rncap_rrc_ue_rsp_timeoutrrc建立过程中，网络侧发送rrc connection setup消息给ue，同时启动“rrc建立ue响应定时器”，如果在定义的时间内仍然没有收到rrc connecti

44、on setup complete消息，则生成该原因值。此原因所占比例最多。需优化dpch开环功控参数和rf优化。nbm_cra_cell_err_code_begin nbm_cra_cell_err_code_end码资源分配错误，请检查nb和iub设置rr_err_iub_interface_requested_configuration_not_supported由于rnc申请的功率等级，传输格式，物理信道参数等配置信息nodeb不能支持，nodeb向rnc发送radio link setup failure，携带的原因值为requested configuration not sup

45、ported。检查rnc和nb参数设置与一致性检查6.5.5.2 典型pchr输出掉话异常原因排查方案掉话原因:排查方法rr_err_rncap_rlc_failure_srb_rst待srb复位重传功能验证。rr_err_rncap_alcfg_iub_aal2_failure与上行rl同步相关，检查上行同步检测设置rr_err_rncap_rb_wait_ue_rb_cfg_timeout该释放原因值可能出现在rb建立过程中，也可能出现在rb重配置过程中。在rb建立过程中是系统侧等待radio bearer setup complete消息超时，在rb重配置过程中是等待radio bear

46、er reconfiguration complete超时。rr_err_rncap_del_old_ccb产生本释放原因可能有以下两种情况：一种是在侧没有释放（原有ccb表没有删除），但同时又发起了接入流程，导致第一次接入被强制释放。这种一般都是由于侧断链，但是没有上报，也没有检测到的情况下才会发生。当前子系统用户数满，此时新接入用户会剔除之前重连次数最多的用户。rr_err_iub_interface_cause_radio_nw_unspecified若node收到rnc的rl连接建立请求后无法满足支持，nodeb会回radio link setup failure消息给rnc，检查nb

47、相关设置。rr_err_rncap_rb_cu_overlap_back在rb重配置过程中，若ue同时发起了小区更新，这时系统会终止重配置流程，进行小区更新流程，这时ue会发送重配置失败消息6.5.6 pchr数据处理案例6.5.6.1 问题现象在某局点优化过程中，我们发现采用pchr数据统计的掉话原因中，srb复位原因对掉话的贡献较大。cs_amr业务:rr_err_rncap_rlc_failure_srb_rst26/54(48.15%)rr_err_rncap_alcfg_iub_aal2_failure11/54(20.37%)rr_err_rncap_del_old_ccb3/54

48、(5.56%)cs_vp业务:cs_other业务:6.5.6.2 定位思路经与产品开发厂商确认，srb复位引起的掉话是与采用am模式的信令相关，即采用am模式的信令在传输时，由于无线环境或其他的问题引起该信令没有被有效传输，在基于rlc的重传机制后，仍没有有效解决，进行复位流程，若没有复位成功，输出错误原因为srb复位引起的掉话原因码。6.5.6.3 排除过程咨询开发部门同事，发现目前系统对于am模式信令的传输机制是重传maxdat后不丢弃模式，达到maxdat重传次数后进行srb复位，目前系统支持的srb复位次数仅支持1次，因此在重传流程进行完毕后，复位失败而引起掉话。问题根结为系统不支持

49、srb多次复位所致（srb复位掉话也与覆盖相关，采用多次复位重传机制可以减少一部分掉话，但不能全部解决，也需无线侧进行排查）。6.5.6.4 排查结果待rnc支持多次复位重传机制解决部分掉话问题，提升掉话率。6.6 top小区分析6.6.1 分析目的top小区的分析可以查找引起网络指标恶化的小区分布，是全局性问题还是局部小区问题，对于全局性问题，检查rnc级资源与参数配置，对于局部性问题，进行小区排查与测试，确认问题所在。6.6.2 分析手段top小区的分析手段可以采用pchr数据和话统数据结合的方式。对问题严重的top小区采用信令跟踪方式，抓取问题关键信令分析并定位。6.6.3 分析流程to

50、p小区的获取我们可以借助pchr数据和话统数据进行筛选，我们建议采用两者工具的结合进行，这样可以互相起到辅助作用，对各工具筛选的top小区提供进一步的分析依据，做到问题一步定位。6.6.4 分析结果输出pchr输出的top小区与掉话原因：掉话原因:1036:30211:rr_err_rncap_alcfg_iub_aal2_failure1/1(100.00%)1036:37113:rr_err_rncap_rb_wait_ue_rb_cfg_timeout2/3(66.67%)无掉话原因1/3(33.33%)1036:38711:rr_err_rncap_rlc_failure_srb_rs

51、t1/1(100.00%)1036:34412:无掉话原因1/1(100.00%)1036:34612:rr_err_rncap_rb_wait_ue_rb_cfg_timeout1/2(50.00%)无掉话原因1/2(50.00%)1036:44212:rr_err_rncap_rb_wait_ue_rb_cfg_timeout1/1(100.00%)6.6.5 top小区处理与解决对于top小区的处理，可以根据实际发生的原因采取排除法逐一排除，落实问题的最根本的原因，对于接通问题，结合rnc侧log，确定问题发生的关键信令流程点（pchr数据可以提供一部分原因），排除网络侧的网元设备工作状

52、态问题，检查干扰、参数核查，对于问题严重的小区可以采用现场测试的办法解决。6.6.6 top小区处理与解决案例6.6.6.1 问题现象某局点一个rnc下的某个室内小区连续多天rrc成功率较低，严重影响cs接通率指标统计日期小区idrrc建立失败次数rrc建立成功率2009-08-113619118063.19%2009-08-123619113256.00%2009-08-133619137644.05%2009-08-143619114372.61%2009-08-173619119860.87%6.6.6.2 定位思路1. 网元问题隔离。确认是ue还是网元设备引起的异常。2. 干扰影响排除

53、3. 异常覆盖范围缩小定位。由于是室内小区，采用的信源是rru268的多个path覆盖，这样的应用可能是某个path异常引起，或某个楼层存在问题。4. 组网系统隔离，确认问题所在6.6.6.3 排查过程1. 网元问题隔离。确认是ue还是网元设备引起的异常。-pchr数据分析，无特殊终端引起指标恶化-业务指标联动观察，观察ps业务接通率情况，ps业务接通和参数现象一致。-告警数据分析，设备网元工作正常。2. 干扰影响排除- rrc_conn_req消息在主频点（10063）上承载，rrc_conn_setup_cmp消息在辅频点（10071）上承载，现场测试发现眼科t1（10071/39）信号外

54、泄到国际金融，电平在80dbm左右，存在较强同频干扰。但调整频点的效果并不明显。3. 异常覆盖范围缩小定位。由于是室内小区，采用的信源是rru268的多个path覆盖，这样的应用可能是某个path异常引起，或某个楼层存在问题。-1个268 rru3个path覆盖整栋大楼。path 1覆盖24f到38f其中26f到38f层；path2 覆盖2f到23f层，且为干放覆盖区域；path3 覆盖1f、mf层。该站点为干放覆盖。因此，不排查干放问题。现场测试未发现信号外泄，因此， rrc建立失败的用户场景发生在大厦内，关闭path1测试，用户数从12个减少到7个，但rrc建立失败问题没有缓解。关闭path2测试，用户数从7个减少到0个。因此，用户集中在