CS业务KPI指标分析指导书.docx

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

2、个基本的呼叫即建立，UE进入通话过程。2 CS业务KPI指标定义CS无线接通率=CS域RAB建立成功率*RRC连接建立成功率。3 整体分析流程4 网络信息收集4.1 网络基本信息网络基本信息收集主要包括以下几个方面： RNC参数配置文件 NodeB参数配置文件收集 基站工参表4.1.1 RNC参数配置文件了解网络中各RNC的软件实体与硬件实体配置情况，了解基本的网络参数配置与分布。4.1.2 NB参数配置文件了解网络中各NB的软件实体与硬件实体配置情况，了解基本的网络参数配置与分布。4.1.3 基站工参表了解网络的网元分布、传输配置、天馈系统分布与配置，为RF优化提供必要依据。4.2 网络KP

3、I信息对网络的CS业务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 Re

4、quest（原因码为OriginatingCoversationalCall）总次数（如果是一次接入过程中重发的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连接建立成功率呼叫请求次数

5、从UE侧统计信令，统计rrcConnectionRequest信令总次数呼叫接通次数从UE侧统计信令，统计Connect或Connect ACK信令总次数呼叫建立成功率用Connect或Connect ACK信令总次数除以rrcConnectionRequest总次数得到端到端的语音呼叫成功率CS业时延指标RRC时延手机发送rrcConnectionRequest消息（如果有重发，只算最早的一条），到RNC收到RRC SETUP COMPLETE消息的间隔RAB时延RNC发送RB SETUP消息，到RNC收到RB SETUP COMPLETE消息的间隔呼叫时延主叫手机发送rrcConnecti

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

7、.1 RRC.SuccConnEstab.6 RRC.AttConnEstab.1 RRC.AttConnEstab.6计算方法：CS RRC连接建立成功率=(RRC.SuccConnEstab.1 +RRC.SuccConnEstab.6)/(RRC.AttConnEstab.1 +RRC.AttConnEstab.6)*100%计算RAB成功率需提取的counter: RAB.SuccEstabCSNoQueuing.Conv RAB.SuccEstabCSNoQueuing.Strm RAB.SuccEstabCSQueuing.Conv RAB.SuccEstabCSQueuing.S

8、trm RAB.AttEstabCS.Conv 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 网络状态评估网络状态评估的主要目的是： 了解并确认全网RNC和NODEB软件版本

9、配置一致 了解并确认全网各网元硬件配置符合规划设计 了解并确认全网各网元工作状态 根据话统与路测数据对网络进行基本评估，了解当前网络实际的运行状态 利用获得的网络信息，评估网络状态，对一些基本情况进行排查。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信令，确认指标较低的原因。2.

11、若路测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发送的ACK消息对于问题A，可

12、以检查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是否已经上报ACK消息，若UE已经上

13、报该消息，检查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会采用网络侧配置的初始功率来发送special burst。N

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

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

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

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

18、软参、开关等。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. 对与TOP小区，按着接入或掉话统计

19、的相关关键信令点，参照话统数据的异常原因提示进行分析处理，必要时可以对问题小区进行信令跟踪，提供进一步分析与定位的依据。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. 采用话统数据对TOP小区进行定位，

21、此时我们可以采用话统数据中与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指派消息中，RAB参数不符合

23、协议。这种原因基本不会出现。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接口的用户面是否有问题。同时可以跟踪NodeB那边，是否收到

25、了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/17171(4.66%)NBM

26、_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_SUPPORTED8/1717

27、1(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_ERR_IU_INTERF

28、ACE_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. 跟踪小区信令，抓取LOG4. 根据信令抓取的问

29、题现象，确认问题所在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次，UE终于回应了一条RRC

30、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 指标关联性分析6.4.1 分析目的在分析完CS业务自身的接入指标和掉话指标，我们可以参考与CS业务接通率和掉话率相关联的指标进行对比、参照、影响分析。6.4.2 分析手段与CS业务接通率和掉话率相关的话统指标和PCHR数据。6.4.3 关联指标选取标准关联指标对掉话率的影响，我们主要关注一些掉话次数较多的TOP小区，观察该小区关联的切换失败次数