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

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

《CS业务KPI指标分析指导书.docx》由会员分享，可在线阅读，更多相关《CS业务KPI指标分析指导书.docx（45页珍藏版）》请在冰豆网上搜索。

CS业务KPI指标分析指导书

CS业务KPI优化指导

1概述

本文从话统与路测的角度深入分析了整个接入过程，并讨论了接入的性能指标优化及其影响因素，以及在实际网络规划中对接入过程分析步骤和可能遇到的相关问题的解决办法。

CS业务KPI指标用来衡量CS业务的接入性能，是反映网络服务提供能力的重要指标之一。

无线接通率体现网络端到端的接入性能，反映RNC或者小区的UE接纳能力，RRC连接建立成功意味着UE与网络建立了信令连接；RAB连接建立成功表明UE与网络间用户面连接建立成功，用户面连接用于UE和CN之间传送语音、数据及多媒体业务。

UE首先要完成RRC连接建立然后才能建立RAB，当RAB建立成功以后，一个基本的呼叫即建立，UE进入通话过程。

2CS业务KPI指标定义

CS无线接通率=CS域RAB建立成功率*RRC连接建立成功率。

3整体分析流程

4网络信息收集

4.1网络基本信息

网络基本信息收集主要包括以下几个方面：

◆RNC参数配置文件

◆NodeB参数配置文件收集

◆基站工参表

4.1.1RNC参数配置文件

了解网络中各RNC的软件实体与硬件实体配置情况，了解基本的网络参数配置与分布。

4.1.2NB参数配置文件

了解网络中各NB的软件实体与硬件实体配置情况，了解基本的网络参数配置与分布。

4.1.3基站工参表

了解网络的网元分布、传输配置、天馈系统分布与配置，为RF优化提供必要依据。

4.2网络KPI信息

对网络的CS业务KPI信息进行收集，主要收集路测与话统的CS业务接通率与掉话率指标，收集方法如下：

4.2.1路测KPI信息

测试方法：

采用专用测试终端，配合数据收集软件，按照中国移动要求的测试方法，沿制定号的测试路线进行路测。

指标计算方法：

指标名称

指标定义

无线网络覆盖指标

PCCPCHRSCP

室外>-95dBm的概率大于90％,室内>-85dBm的概率大于90％

PCCPCHC/I

室外C/I>-3dB的概率大于90％

整体覆盖率

采样点（PCCPCHRSCP>=-95dBm&C/I>=-3dB）/总采样点×100％

CS业务接通率指标

RRC连接建立请求次数

UE发送的RRCconnectionRequest（原因码为OriginatingCoversationalCall）总次数（如果是一次接入过程中重发的RRCconnectionRequest只算第一次）

RRC连接建立成功次数

统计RNC接收到的RRCconnectioncomplete信令总次数

RRC连接建立成功率

RRCconnectioncomplete信令总次数/RRC连接建立尝试次数

RAB建立成功次数

RNC收到RABcomplete信令总次数

RAB指派次数

RNC发送RABsetup信令总次数

RAB连接建立成功率

RAB指派建立成功次数/RAB建立请求次数

无线接通率

RAB建立成功率*RRC连接建立成功率

呼叫请求次数

从UE侧统计信令，统计rrcConnectionRequest信令总次数

呼叫接通次数

从UE侧统计信令，统计Connect或ConnectACK信令总次数

呼叫建立成功率

用Connect或ConnectACK信令总次数除以rrcConnectionRequest总次数得到端到端的语音呼叫成功率

CS业时延指标

RRC时延

手机发送rrcConnectionRequest消息（如果有重发，只算最早的一条），到RNC收到RRCSETUPCOMPLETE消息的间隔

RAB时延

RNC发送RBSETUP消息，到RNC收到RBSETUPCOMPLETE消息的间隔

呼叫时延

主叫手机发送rrcConnectionRequest消息（如果有重发，只算最早的一条），到主叫手机收到Alerting消息的间隔

CS业掉话指标

掉话次数

在手机没主发disconnect信令或收到网络下发Release信令情况下，手机收到RRCRELEASE消息或进入IDLE状态,算为一次掉话

掉话率

掉话率＝（主叫掉话+被叫掉话）/（主叫接通+被叫接通）×100％

切换指标

切换成功次数

物理信道重配置成功次数

切换次数

物理信道重配置次数

切换成功率

物理信道重配置成功次数/物理信道重配置次数

切换时延

物理信道重配置成功时间与物理信道重配置成功时间差

4.2.2话统KPI信息

计算RRC成功率需提取的counter:

⏹RRC.SuccConnEstab.1

⏹RRC.SuccConnEstab.6

⏹RRC.AttConnEstab.1

⏹RRC.AttConnEstab.6

计算方法：

CSRRC连接建立成功率=（（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.Strm

⏹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软件版本配置一致

⏹了解并确认全网各网元硬件配置符合规划设计

⏹了解并确认全网各网元工作状态

⏹根据话统与路测数据对网络进行基本评估，了解当前网络实际的运行状态

⏹利用获得的网络信息，评估网络状态，对一些基本情况进行排查。

5.1站点状态评估

5.1.1站点软件信息

对网络站点状态评估，需明确当前网络各网元软件版本配置情况，确认当前站点的工作状态。

网元

版本

补丁

RNC

NodeB

OMC

5.1.2站点工作状态

采用站点健康检查工具，了解当前网络中各站点与小区的运行状态，确认各网元的运行稳定性。

5.2频点扰码核查

频点扰码核查的主要目的是防止频点与扰码的使用不均衡性，避免某个频点或扰码被过多的使用或不使用。

最理想的扰码复用度＝小区个数/扰码数

从上面统计可以看到：

1）个别扰码，像0扰码组只用了一次，复用很不好，这样造成扰码组17的复用很差，邻区中出现同频同码的概率增大；

2）11扰码组没有使用过一次，扰码资源浪费；

3）统计毛刺太多，不能平均，需要对个别扰码组进行地理平均。

5.3邻区核查

邻区核查的目的是了解当前网络的各小区的邻区关系分布，排查单向邻区、超远邻区、漏配邻区状况。

5.4网络KPI数据分析

结合路测数据与话统数据，对CS业务的KPI指标进行对比：

话统KPI

路测KPI

备注

对比结果

1.话统KPI若好于路测KPI，需重点排查测试路线上的小区参数配置、邻区配置，根据路测LOG信令，确认指标较低的原因。

2.若路测KPI好于话统KPI，对话统数据进行分析，查找TOP小区，分析原因。

3.话统KPI与路测KPI都较差，需重点排查网络小区的参数配置、与站点规划文件对比、根据数据分析原因。

6网络指标提升

6.1分析思路

6.1.1CS业务接通率（路测）

CS业务接通率路（路测）的指标由于UE侧可以提供相关的LOG结合RNC侧LOG能够提供工程师一个可视化的界面，对于问题点的定位可以做到一目了然，因此，优化相对较直观。

路测接通率可以从以下几方面分析落实：

RRC阶段的影响主要表现为以下三类：

A.多次发送RRC请求无响应

B.UE未收到RRCSETUP消息

C.RNC未收到UE发送的ACK消息

对于问题A，可以检查PRACH信道和UPPCH信道的开环功控参数，根据UE侧LOG明确发起业务时所处位置的PCCPCHRSCPC/I，结合地理位置环境排除干扰影响，对于载波存在干扰可能性的影响，可以通过RNC进行监测上行的ISCP，排除干扰影响。

主叫手机排除流程

被叫手机排查流程

对于问题B，首先检查RNC侧LOG是否收到UE的RRC请求并确认是否下发SETUP消息，若已经下发SETUP消息，检查PCCPCHRSCP和C/I，排除弱覆盖影响，同时检查小区的FACH信道功率设置，保证SCCPCH信道的覆盖范围与PCCPCH信道相匹配。

对于问题C，检查UE侧LOG，确认UE是否已经上报ACK消息，若UE已经上报该消息，检查DCH开环功率设置。

RB流程分为两个部分：

UTRAN在原来的DPCH上发送RBSETUP消息给UE；UE在新的DPCH上回复RBSETUPCMP消息给UTRAN。

原有的DPCH一直处在内环功控中，并且UE和核心网在NAS层消息也有过交互，因此下发RBSETUP消息出现问题的可能性并不是很大。

从功能实现来讲，RBSETUP消息配置错误的概率也很低。

因此问题一般都是出在UE回复RBSETUPCMP消息这一步上。

UE在新的DPCH上回复RBSETUPCMP之前，会先作专用信道同步。

在进行专用信道同步时，UE会采用网络侧配置的初始功率来发送specialburst。

NodeB也是采用网络侧的提供的初始发射功率进行specialburst进行发射。

UE在新的链路同步上以后，就可以采用闭环功控来进行功率调整，等激活时间生效，就可以采用新的功率在新的链路上发送RBSETUPCMP到UTRAN。

在此过程中，专用信道同步失败会导致UE建立RB失败。

如果UE配置成功，同步也成功，但是在发送RBSETUPCMP后，UTRAN收不到该消息，在统计时，也会统计为失败。

另外，激活时间太短，导致UE那边来不及处理或者同步，也会导致RB建立失败。

6.1.2CS业务接通率（话统）

CS业务接通率的分析思路主要是基于以下原则进行：

1.区分业务统计

CS业务由AMR语音业务和VP业务构成，在做相关指标统计分析时，因分别分析统计分析，最后综合CS业务整体KPI指标考虑。

2.室内与室外业务分别统计分析。

这样可以把问题隔离化，在优化时可以根据小区地理环境类型的不同采取相应的优化措施。

3.落实问题结点。

CS业务接通是由RRC接通率和RAB接通率计算构成，因此，了解RRC接通率和RAB接通率的状况，确定指标异常的出现点。

4.TOPN小区处理。

筛选对CS业务指标造成影响的TOPN小区，基于上述3个指标的分类统计结果，可以跟踪TOPN小区的U口信令，抓取相关信息分析确认。

5.结合PCHR数据联合分析定位，基于话统异常原因提示和PCHR异常原因提示，分别对小区、终端、RRC异常原因、RAB异常原因归类分析。

6.1.3CS业务掉话率（路测）

引起路测数据CS业务掉话的主要原因不外乎以下几类原因：

⏹覆盖

覆盖优化主要时排除导频弱覆盖和DPCH弱覆盖，同时关注导频污染，通过RF优化解决因覆盖问题造成的掉话。

⏹干扰

干扰可以通过干扰排查工具，确认系统内或系统外的干扰源，对于系统内的干扰源，通过频点、扰码优化与RF优化解决，对于系统外的干扰，根据干扰源的类型分情况解决。

⏹切换异常（系统内与系统间）

路测切换异常引起的掉话，需要核查问题点小区的邻区配置、切换关系的合理性等。

6.1.4CS业务掉话率（话统）

话统中CS业务掉话率的统计可以采用与接通率相同的方式进行，即：

1.区分业务统计

CS业务由AMR语音业务和VP业务构成，在做相关指标统计分析时，因分别分析统计分析，最后综合CS业务整体KPI指标考虑。

2.室内与室外业务分别统计分析。

这样可以把问题隔离化，在优化时可以根据小区地理环境类型的不同采取相应的优化措施。

3.TOPN小区处理。

筛选对掉话次数较高的TOPN小区，可以跟踪TOPN小区的U口信令，抓取相关信息分析确认。

4.结合PCHR数据联合分析定位，基于话统异常原因提示和PCHR异常原因提示，分别对小区、终端和掉话异常原因分布归类分析。

6.2参数核查

参数核查主要包含以下几个方面：

1.RNC配置参数核查。

检查RNC配置参数是否使用了性能部推荐参数，特别是针对一些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.对与TOP小区，按着接入或掉话统计的相关关键信令点，参照话统数据的异常原因提示进行分析处理，必要时可以对问题小区进行信令跟踪，提供进一步分析与定位的依据。

4.根据分析结果，制定优化方案，实施验证。

6.3.4分析标准

话统分析的标准对于CS业务接通率，我们首先基于CS接通率为基准筛选，选出接通率低于优化目标的小区，完后根据RRC接通率和RAB接通分别进行原因定位，此时我们要考虑RRC失败次数和RAB失败次数的影响，基于接通率较低筛选的TOP小区，可能业务量较少，虽然接通率较低，但产生的失败次数不足以对全局指标产生影响，该类型小区可不计入TOP小区。

因此，对于接通率的优化，我们建议重点关注RRC和RAB失败次数较高的小区为标准。

对于掉话率，建议以掉话次数为依据作为判断TOP小区的标准。

6.3.5分析结果输出

可以采用性能话统专项处理工具，输出以下数据：

6.3.5.1RNC级指标输出

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小区进行定位，此时我们可以采用话统数据中与CS业务接入和掉话相关的错误原因提示进行初步的分析。

6.3.6.2RAB接入失败原因分析与定位

CSRAB失败counter

含义

分析

RAB.FailRabAssignEstabCS.66

电路域RAB指配建立失败的RAB数目

在为用户建立IU接口的用户面时，出现了某种错误，导致IU接口的连接建立失败。

出现了这种情况时，需检查IU口的通道是否正常。

RAB.FailRabAssignEstabCS.5

电路域RAB指配建立失败的RAB数目<排队定时器超时>

如果RNC支持排队抢占功能，当一个用户处于排队过程中，如果该用户排队时间过长，则把会出现由于排队超时导致RAB建立失败。

如果出现这种问题，一般来说小区应该已经拥塞，在建网初期不会出现。

RAB.FailRabAssignEstabCS.115

电路域RAB指配建立失败的RAB数目<未知错误>

无法归类到其他原因的RAB失败，如果出现这种原因，需要跟踪该小区的log，特别是内部的消息，查看内部流程是到了哪一步失败。

RAB.FailRabAssignEstabCS.114

电路域RAB指配建立失败的RAB数目<无可用资源>

在小区拥塞、或者某种资源（比如HS）不足时，又不支持排队抢占，则会回复这种原因。

在建网初期，这种情况不会出现

RAB.FailRabAssignEstabCS.19

电路域RAB指配建立失败的RAB数目<无效的RAB参数>

CN发给RNC的RAB指派消息中，RAB参数不符合协议。

这种原因基本不会出现。

RAB.FailRabAssignEstabCS.20

电路域RAB指配建立失败的RAB数目<最大速率不支持>

RNC在为一个RAB进行资源分配时，如果现有资源无法支持该RAB的速率要求，又不支持排队抢占，则会上报最大速率不支持。

在建网初期，该原因值不太容易出现。

6.3.6.3RRC接入失败原因与定位

RRC失败counter（不区分业务）

含义

分析

RRC.FailConnEstab.1

RRC连接失败次数<拥塞>

当UE发RRCCONNECTIONREQ，收不到SETUP消息，重发REQUEST消息，当达到N300次，还没收到SETUP，则RRC建立失败，原因置为“拥塞”。

在建网初期，基本上不会发生拥塞，如果出现这个原因，应该检查一下NodeB是否正常

RRC.FailConnEstab.RlSetupFail

RRC连接失败次数

当Iub口出现问题，或者NodeB直接回复RL建立失败，就会导致RL建立失败，从而导致RRC建立失败，原因置为”RL建立失败”。

如果出现这个原因，需检查一下NodeB是否正常。

RRC.FailConnEstab.FPSynFail

RRC连接失败次数

在为用户建立IUB接口用户面时，RNC建好了DCH的FP之后，会发起FP同步过程，如果该过程失败，即认为RRC建立失败。

如果出现FP同步失败，需检查IUB接口的用户面是否有问题。

同时可以跟踪NodeB那边，是否收到了FP同步帧来确认上下行同步是在哪一步出现了问题。

RRC.FailConnEstab.AAL2SetupFail

RRC连接失败次数

为用户建立IUB接口的用户面时，需先建立AAL2的链路。

如果AAL2链路建立失败，后续的FP、MACD等都无法建立。

如果出现AAL2建立失败，同样需要检查IUB接口的通道是否正常，比如PATH是否配置合理。

2.结合PCHR数据，对TOP小区的异常接入原因进一步明确，确认异常小区接入失败发生原因的信令点分布。

接入失败原因:

NULL

34248/17171（199.45%）

RR_ERR_RNCAP_RRC_UE_RSP_TIMEOUT

801/17171（4.66%）

NBM_CRA_CELL_ERR_CODE_BEGIN~NBM_CRA_CELL_ERR_CODE_END

635/17171（3.70%）

RR_ERR_RNCAP_RELOC_PHY_CH_RECFG_CMP_TIMEOUT

25/17171（0.15%）

RR_ERR_IU_INTERFACE_FAIL_IN_RADIO_INTERF_PROC

13/17171（0.08%）

RR_ERR_IU_INTERFACE_UNKNOWN_TARGET_RNC

8/17171（0.05%）

RR_ERR_IUB_INTERFACE_REQUESTED_CONFIGURATION_NOT_SUPPORTED

8/17171（0.05%）

RR_ERR_RNCAP_RELOC_IU_REQ_SECURITY_MODE_ALGOR_NOT_SUPP

5/17171（0.03%）

RR_ERR_RNCAP_RELOC_SEC_RELOC_REQ_TIMEOUT

3/17171（0.02%）

RR_ERR_IU_INTERFACE_TIMER_RELOC_CMP_EXPIRY

3/17171（0.02%）

RR_ERR_IU_INTERFACE_RELOC_CANCELLED

2/17171（0.01%）

RR_ERR_RNCAP_RL_CAUSE_NODEB_TIMEOUT

1/17171（0.01%）

RR_ERR_IU_INTERFACE_NORMAL_RELEASE

1/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.跟踪小区信令，抓取LOG

4.根据信令抓取的问题现象，确认问题所在

6.3.7.3排除过程

小区的话统原因中对如此高的失败没有提示原因，因此决定进行现场配合测试，机房配合抓取LOG，进行信令分析，测试中发现，UE侧RRC连接完成消息不能及时送上来；一般都在RNC连续下发6～7条RRC连接建立后，才能收到UE上报的CMP消息。

分析L3信令，RRCCONNREQ发上来后，RNC立刻做了RL建立的处理，并且得到了NODEB响应；RNC给手机发送RRCCONNSETUP，手机也收到了该消息；比较奇怪的是手机没有上发RRCCONNSETUPCMP，而是等了2秒后重新发RRCCONNREQ。

如此反复了6～7次，UE终于回应了一条RRCCONNSETUPCMP消息。

对比此处异常和正常RRC_CONN_SETUP，只有ul-TargetSIR不一样；正常大约都在41，此处异常的则为3。

此处的ul-TargetSIR，其计算公式为：

上行期望发射功率＋路损＋上行干扰余量

RNC下发消息中的ul-TargetSIR太小，因此检查该问题小区的上行干扰余量（ULINTERFERERSV），发现该参数设置偏低，仅为－15，造成UE在DCH的上行初始功率太低。

6.3.7.4排查结果

调整上行干扰余量到3，增加UE在DCH上发送RRCCONNSETUPCMP的初始发射功率，以让RNC及时的收到此消息。

6.4指标关联性分析

6.4.1分析目的

在分析完CS业务自身的接入指标和掉话指标，我们可以参考与CS业务接通率和掉话率相关联的指标进行对比、参照、影响分析。

6.4.2分析手段

与CS业务接通率和掉话率相关的话统指标和PCHR数据。

6.4.3关联指标选取标准

关联指标对掉话率的影响，我们主要关注一些掉话次数较多的TOP小区，观察该小区关联的切换失败次数