lesson3td-scdma性能指标监控处理与主要话统优化

学习完此课程，您将会：的内容、分析与定掌握网优工作日常性能位思路掌握一般性能指标优化的思想与工具字段理解并掌握TD-SCDMA话统接通率问题的原理、分析思路与优化方法理解并掌握TD-SCDMA话统掉话率问题的原理、分析思路与优化方法理解并掌握TD-SCDMA话统互操作成功率问题的原理、分析思路与优化方法目标Page

21.

《TD-SCDMA无线网络无线接通率优化指导书》2.

《TD-SCDMA无线网络CS接通率专题分析指导及报告模版v1.2》3.

《TD接通率提升参数优化经验（V2.0）》4.

《TD-SCDMA无线网络CS掉话率优化指导书》5.

《TD-SCDMA无线网络PS掉话率优化指导书》6.

《TD

SCDMA性能CS掉话率专题分析指导及报告模版V1.0》7.

《TD-SCDMA

2G3G互操作性能优化指导书》8.

《TD-SCDMA无线网络2G3G互操作性能优化指导》9.

《RNPS

GSM与TD-SCDMA互操作研究v1.2》参考资料Page

3Page4第1章

性能

与问题处理第2章CS/PS接通率第3章CS/PS掉话率第4章CS/PS互操作成功率全面网络性能

：主动发现问题话统PCHR1.业务量指标：CS话务量、PS业务量，零话务小区2.可接入性指标：RRC建立成功率、RAB建立成功率、CS/PS接入成功率3.可保持性指标：CS掉话率、PS掉线率4.可移动性指标：RNC内切换成功率、RNC间切换成功率、系统间切换成功率5.信道拥塞：RRC拥塞特性、RAB拥塞特性、PCH拥塞特性、传输信道拥塞6.信道特性：上行TS1/TS2时隙ISCP、UpPCH信道ISCP、上行业务信道BLER1.

VIP/VAP用户分析与

：接入、掉话、超短呼叫、VQI、PS速率、HTTP业务断链次数、重点小区分布2.覆盖分析：接入电平分布、MR报告电平3.邻区漏配分析：基于RNC漏配邻区检测算法4.终端性能统计：了解现网终端特性对整碗指标的影响5.特殊业务分析：并发业务特性、短消息特性、登记特性指标名称CS域无线接通率CS域无线掉话率PS域无线接通率PS域无线掉线率RNC内同频切换成功率RNC内异频切换成功率CS域3Gto2G切换成功率PS域3Gto2G切换成功率RNC间切换入成功率RNC间切换出成功率平均99.23%0.17%99.08%1.17%97.39%98.50%98.32%94.98%95.86%94.41%区域关键指标情况PCHR原型工具功能Page

5持续拉网性能测试：体验用户感受DT测试CQT测试1.空口覆盖状况，网络干扰状况：弱覆盖点与

扰区域优化2.网络配置状况：邻区、扰码、频点的优化配置3.4.基础感知评估：接通、掉话、语音质量评估、切换时延评估、PS速率评估、空闲态用户感知（ 、重选……）关键指标评估：系统内切换成功率、系统间切换成功率1.CS用户感知：AMR语音质量、VP质量、接入时延2.PS用户感知：PS速率、HTTP业务断链次数3.问题复现：终端侧log抓取将鼎力侧log与RNC侧log对照，是分段排查问题的有效

！鼎力侧信令RNC侧信令Page

6Page

7“TOP”与“分段”：问题分析的主要思想“TOP”思想是话统问题分析的基础：1TOP原因：影响指标的各原因值各占多少比例？主要原因是什么？各原因值数量分布比例是否正常？各RNC是否现象一致？3TOP

IMEI/IMSI状况：通过PCHR＋Excel筛选是否存在TOPIMEI/IMSI？TOP

IMEI/IMSI问题规律性如何？可否协调相应终端测试？能否

台 IMSI信息？TOP

IMSI/IMEI2TOP

Cell状况：是否存在TOP

Cell？TOPCell的业务量是否足够多？TOPCell有无设备类告警？TOP

Cell话统指标间关联关系如何？TOPCell实地测试结果如何？TOP

CellTOP原因“分段”思想是测试问题分析的基础：UE

NodeB①H速率低 ②空口良好

③来水量不足RNC④传输未拥塞CN④更换FTP服务器，搞定！性能工具与打点：问题分析与网络优化的利器工具/打点主要功能话统网络指标

与初步分析PCHRRNC呼叫日志，记录呼叫过程的NodeB

CHR以RL建立为起点记录的日志，结合PCHR，为性能问题定位提供NodeB

的相关信息MR根据终端、NODEB上报的

、公共测量报告，包括P

CHRSCP、上下行BLER、TA等数据，进行覆盖、邻区等信息分析寻呼日志嵌入

网CHR

记录5个模块156个字段，为定位寻呼相关问题提供信息CDT抓取通话过程中，RNC侧详细信息；可同时抓取业务面信息TPCwin除定位NodeB设备问题外，TPCwin还提供丰富的Tools以分析上下行空口相关信息频谱分析工具通过

log，可离线分析上行干扰问题MML核查工具CME集成工具，可自定义模版核查全网参数配置鼎力log终端侧空口、时间、信令等信息，可与系统侧信息对照，进行问题分析与定位在问题定位与分析的不同阶段，使用不同工具与打点信息RNC：话统PCHRMRCDTMML核查NodeB：NodeB

CHRTPCwin频谱分析CN：寻呼日志UE：鼎力logPage

8良好覆盖＋合理配置＋精细优化：构建精品网络市区主要道路覆盖99.32％部分区域存在大片待补站区域3.市区深度覆盖需要进一步补充覆盖提升参数基线是在

“安全”前提下的最优配置对于与参数基线配置有出入的配置，要求视情况尽量规范化配置优化通过右图两条折线对比，可以看到经过优化后，同一路段上切换次数显著减少，测试MOS分也相应提升：频繁切换会显著影响

DT测试MOS分，一次切换平均会降低

MOS分1分左右；因此，减少不必要的频繁切换，是提升MOS的重要

。RF调整前RF调整后MOS均值3.383.52①覆盖优化过程②配置优化过程③精细优化过程Page

9Page10第1章

性能

与问题处理第2章CS/PS接通率第3章CS/PS掉话率第4章CS/PS互操作成功率Page11第2章CS/PS接通率第1节接通率基础第2节接通率问题分析方法第3节接通率优化提升方法第4节接通率典型案例呼叫建立信令流程与话统规范中国移动规范：TD语音无线接通率=会话类业务

RRC建立成功率×语音业务RAB建立成功率无线接通率=

会话类业务RRC建立成功率×

业务RAB建立成功率PS域无线接通率=所有业务RRC建立成功率×PS域RAB建立成功率以上定义，PS无线接通率定义不合理，应该使用PS业务相关RRC建立成功率。UENodeB10

RAB建立(CS)RNC建立RRC连接建立CM连接CN1

RRC建立3

鉴权和加密（CS域）建立MM连接UENodeBRNCCN2

初始直传4

DCCH:Uplink

Direct

Transfer(SETUP)5

DCH:DCH

DATA

FRAME

(Uplink

Direct

Transfer)6

Direct

Transfer

(SETUP)7

Direct

Transfer

(CALL

PROCEEDING)8

DCH:DCH

DATA

FRAME(Downlink

Direct

Transfer)9

DCCH:Downlink

Direct

Transfer

(CALL

PROCEEDING)11

Direct

Transfer(ALERTING)12

DCH:DCH

DATA

FRAME(Downlink

Direct

Transfer)13

DCCH:

DownlinkDirect

Transfer

(ALERTING)14

Direct

Transfer

(CONNECT)15

DCH:DCH

DATA

FRAME(Downlink

Direct

Transfer)16

DCCH:

DownlinkDirect

Transfer19

Direct

Transfer

(CONNECT

ACK)18

DCH:DCH

DATA

FRAME(Uplink

Direct

Transfer)(CONNECT)17

DCCH:

Uplink

Direct

Transfer(CONNECT

ACK)CS主叫信令流程Page12RRC建立流程话统定义：RRC请求次数=RNC收到RRCConnection

Request次数RRC成功次数=RNC收到RRCConnectionSetupComplete次数空口一共三条消息，若第一条消息失败，不会有RRC请求；若第二、三条消息失败，在话统的表现均为

“NoReply”。因此，设备正常运转情况下“NoReply”应该是RRC建立失败的绝对主体UENodeBRNC3.

CCCH:RRC

Connection

Request4.

RACH：RACH

DATA

FRAME(RRC

Connection

Request)1.

SYNC_UL2.

FPACH

Burst5.

Radio

Link

Setup

Requeststart

RX6.

Radio

Link

Setup

Response9.

Downlink

Synchronisation10.

Uplink

Synchronisationstart

TX12.

CCCH:RRC

Connection

Setup11

FACH：FACH

DATA

FRAME(RRC

Connection

Setup)14.

Radio

Link

Restore

Indication15.

DCCH:RRC

Connection

Setup

Complete16.

DCH：DCH

DATA

FRAME(RRC

Connection

Setup

Complete)Allocate

RNTI

and

Select

L1

and

L2parameters7.

ALCAP

Iub

Establish

Request8.

ALCAP

Iub

Establish

Confirm13.

special

burstUEPage13NodeBRNC话统RRC指标细分1.

RRC共定义19种业务2.

业务

“5”在协议中是有的：“Originating4.Subscribed

traffic

Call”3.

部分业务有定义，但实际是没有业务发生的、系统间重选两类业务占RRC请求约50％5.

PS业务相关RRC请求约占25％6.

CS业务相关RRC约占15％7.

各业务的RRC建立成功率，可通过话统或PCHR进行评估业务业务类型请求次数成功次数请求次数占比1主叫类会话业务950594145.65%2主叫类流业务000.00%3主叫类交互业务172121716610.22%4主叫类背景业务282812822016.80%6被叫类会话业务805380314.78%7被叫类流业务180451799510.72%8被叫类交互式业务000.00%9被叫类背景业务000.00%10紧急呼叫770.00%11系统间小区重选321373198119.09%12系统间小区改变命令000.00%13416064131424.71%14IMSI分离136513190.81%主叫发起高优先级信令连接.77%主叫发起低优先级信令连接.47%17呼叫重建59560.04%18被叫发起高优先级信令连接000.00%19被叫发起低优先级信令连接20未知原因Page14RAB建立流程LCR4.1话统定义：RAB请求次数=RNC收到RABAssignment

Request次数RAB成功次数=RNC发出RABAssignment

Response，并显示为为成功的次数在无线资源充足的情况下，RNC收到RAB

Assignment

Request后不发RBSetup的可能性很低；当空口发生故障时，不论是RBSetup发下UE未收到，还是UE发回的RB

Setup

Complete消息RNC未收到，在话统体现的都是

“Failure

in

the

Radio

InterfaceProcedure”UENodeBRNCCN1

RANAP:

RAB

Assignment

Request

(Establishment)Select

L1,

L2

and

Iu

Data

Transport

Bearer

parameters2

ALCAP:

Iu

Establish

Request3

ALCAP

:

Iu

EstablishConfirm4

NBAP:

RadioLink

Reconfiguration

Prepare

5

NBAP

Radio

LinkReconfiguration

Ready6

ALCAp:

Iub

Establish

Request7

ALCAP

:Iub

Establish

Confirm8

Downlink

Synchronisation9

UplinkSynchronisation10

NBAP:

Radio

LinkReconfiguration

Commit11

DCH:

DCH

DATA

FRAME

(Radio

Bearer

Setup)12

DCCH:

Radio

Bearer

Setup13

Apply

new

transport

format

set14

DCCH:

Radio

Bearer

SetupComplete

15

DCH:

DCH

DATA

FRAME(Radio

Bearer

Setup

Complete)16

INITIALISATION17

INITIALISATION

ACK18

RANAP:RAB

Assignment

ResponsePage15UENodeBRNCCN话统RAB指标细分1.

上表为4.1C01版本中CS/PS域RAB建立失败的细分原因值2.

RAB失败的打点为“收到RAB

Assignment

Response”后，记录对应

原因3.

4.1C02版本新增加一项“.14”失败（Failurein

the

Radio

Interface

Procedure），对应场景为：RB

Setup下发后，直至定时器超时，未收到RB

Setup

Complete4.

与RRC建立失败的情况一样，在无线网络中，“.14”失败应该是主流的RAB失败原因RAB.FailEstabCsNoQueuing.19电路域无排队的RAB指配建立失败的RAB数目<无效的RAB参数>RAB.FailEstabCsNoQueuing.20电路域无排队的RAB指配建立失败的RAB数目<最大速率不支持>RAB.FailEstabCsNoQueuing.66电路域无排队的RAB指配建立失败的RAB数目<IU口传输连接建立失败>RAB.FailEstabCsNoQueuing.114电路域无排队的RAB指配建立失败的RAB数目<无可用资源>RAB.FailEstabCsNoQueuing.115电路域无排队的RAB指配建立失败的RAB数目<未知原因>RAB.FailEstabPsNoQueuing.19分组域无排队的RAB指配建立失败的RAB数目<无效RAB参数>RAB.FailEstabPsNoQueuing.20分组域无排队的RAB指配建立失败的RAB数目<最大速率不支持>RAB.FailEstabPsNoQueuing.66分组域无排队的RAB指配建立失败的RAB数目<IU口传输连接建立失败>RAB.FailEstabPsNoQueuing.114分组域无排队的RAB指配建立失败的RAB数目<无可用资源>RAB.FailEstabPsNoQueuing.115分组域无排队的RAB指配建立失败的RAB数目<未知错误>CS域RAB失败原因值：PS域RAB失败原因值：Page16接通率网上表现区域接通率周平均指标：CS域RRC连接建立成功率CS域RAB建立成功率CS域无线接通率PS域RRC连接建立成功率PS域RAB建立成功率PS域无线接通率五月99.50%

↑99.73%

↑99.23%

↑99.57%

↑99.51%

↑99.08%

↑三月99.48%99.65%99.13%99.56%99.44%98.97%PCHR异常原因值解析（以某局点数据为例）：接入流程分类信令失败错误编码次数原因解释信令失败错误编码RR_ERR_RNCAP_ALCFG_IU_AAL2_LOCAL_FAIL(184945361)1Iub口AAL2建立失败RR_ERR_RNCAP_RELOC_ABNORMAL_FAIL(184748169)1待考证RR_ERR_RNCAP_RELOC_SEC_RELOC_REQ_TIMEOUT(185272276)1待考证RR_ERR_RNCAP_RRC_UE_RSP_TIMEOUT(185468882)1427RRC建立等待UE响应超时RAB异常错误编码NULL730C02SPC600解决RAB异常信息块输出NULL问题RR_ERR_RNCAP_RB_CU_OVERLAP_BACK(185468906)25RAB建立过程与CellUpdate流程嵌套RR_ERR_RNCAP_RB_WAIT_UE_RB_CFG_TIMEOUT(185468904)127RAB建立过程等待UE响应超时RR_ERR_RNCAP_RRC_MAIN_ABNORMAL_ERR(184944605)3待考证RR_ERR_UU_INTERFACE_INVALID_CFG_ERR_NULL_TYPE(185468937)47呼叫早 、UE异常近两月接通率各项指标均有提升！接入失败主要发生在空口！Page17Page18第1章CS/PS接通率第1节接通率基础第2节接通率问题分析方法第3节接通率优化提升方法第4节接通率典型案例“TOP”思想在接通率问题中的运用TOP分析各过程，可进行交叉分析；如针对某TOP原因筛选所在的TOP小区、TOP终端接通率低！怎么办？TOP原因：根据话统、PCHR判断，影响接通率的主要因素是RRC阶段还是RAB阶段RRC阶段和RAB阶段的未接通，理清各失败原因值分布情况针对各阶段和失败原因值采取对应解决措施，优先处理非空口原因的接入失败TOP小区：根据话统、PCHR对发生未接通的TOP小区进行排序，查找TOP小区针对TOP小区的TOP原因，采取对应解决措施TOP小区的相关告警信息需要关注；根据PCHR过滤的框、槽、端口异常信息需要关注必要时可对TOP小区进行实地测试以发现、分析问题TOP

IMSI/IMEI：PCHR分析前先做“

UE标识”的操作根据PCHR筛选出RRC、RAB接入失败，自定义输出IMSI/IMEI等信息后，使用Excel数据

判断TOPIMSI/IMEI信息对RAB建立失败，可以通过“PCHR工具＋Excel”来找到TOP

IMSI和TOP

IMEI对RRC建立失败，若

UE标识后，仍然只能看到TMSI或P-TMSI，则需要手工找出与其对应的IMSI、IMEIPage19利用PCHR深入分析接通率问题RRC过程信息1.

接入小区2.

接入信道所在载频3.

接入信道所在时隙4.

接入时RRC状态5.

接入原因6.

信令失败错误编码RAB过程信息1.

RAB请求建立类型2.

RAB请求业务类型3.

RAB请求域业务指示4.

RAB掉话业务指示5.

RAB异常错误编码PCHR工具＋Excel＋UltraEdit1.

实现对TOP小区，TOP用户、TOP原因的汇总2.

结合“信令流程信息”和“前直传信令信息”可进一步定位呼叫失败的具体原因根据PCHR，可分析：1.

接入特性与接入电平分布的关系2.

接入特性与频繁登记的关系3.

接入特性与覆盖空洞的关系4.

……Page20Page21第1章CS/PS接通率第1节接通率基础第2节接通率问题分析方法第3节接通率优化提升方法第4节接通率典型案例接通率优化提升措施：场景优化主叫会话类RRC成功率低而被叫会话类RRC成功率高1.这是一个正常现象，但两者差异不能过大2.被叫时的“Paging

Tpye

1”消息为下行链路质量提供了保障3.对于两者差异过大的场景，可通过提升FACH功率进行优化类RRC建立成功率低系统间重选类RRC建立成功率差1.系统间重选的RRC有两种情况：PS域2G到3G切换、空闲态2G到3G后进行登记2.可见，系统间重选都发生在3G的覆盖边界3.

除通用的常规优化 外，该场景下可在2G侧提高重选3G侧电平门限1.

对于集中在LAC边界的 类RRC指标差，需通过实地测试找到弱覆盖边界，进行覆盖优化；或进行站点割接2.

对于短时集中于某个TMSI的 类RRC建立失败，可通过提高小区驻留电平、延长周期性位置更新时间进行优化并发业务RAB建立成功率低1.在帧分打开情况下，RB

Setup消息空口下发需要的时间比非帧分情况下长；因此，帧分打开时，可通过提高ACTTIMEDEFOFFVALFORSAMECELL来保证RB

Setup消息被UE顺利接收区分不同场景进行优化，是网络精细优化的必要动作Page22接通率优化提升措施：算法参数优化算法/参数作用建议措施时隙均分均衡时隙间业务量，减少由于业务过度集中在某时隙导致的干扰抬升打开载波均分均衡载波间业务量，减少由于业务过度集中在某载波导致的干扰抬升打开UpPTS

Shifting将Uppts时隙迁移到其后的上行时隙中，并将Uppts时隙迁移的信息通过系统消息5传递给UE，以规避上行UpPTS干扰打开DCCC开关打开时，则PS业务进行过程中可根据实际需求进行码资源分配，既保证用户需求，又节省码道资源RAB降速接入开关打开时，则PS业务以初始速率接入，占用较少码道资源；结合DCCC算法，可减少“最大速率不支持”的RAB建立失败打开RRCUERSPTMRRNC发出RRC

Connection

Setup后，等待UE返回RRC

ConnectionSetup

Complete消息的时间10000RBSETUPRSPTMRRNC发出RBSetup后，等待UE返回RBSetup

Complete消息的时间10000N300UE未收到RRCConnection

Setup，则重发RRC

ConnectionRequest；最多可发送N300＋1次7ULINTERFERERSV用于计算RRC、RAB建立过程中UE进行上行同步时的初始增大DLINTERFERERSV用于计算RRC、RAB建立过程中NodeB进行下行同步时的初始增大金银铜牌用户上行最大可调速率DCCC策略调整的给用户的最大上行可用速率；对于出现“最大速率不支持”的PS

RAB失败，可限制用户上行最大可调速率减小Page23LCR

4.1C02

&

5.0在接通率方面新特性新增话统打点：RAB.FailEstabCsPerCell.14对应协议原因为：Failurein

the

Radio

InterfaceProcedure常见场景为：RNC下发RBSetup后，没有收到UE返回的RBSetup

Complete消息价值信息：“UE收到Special

Burst的数量”，“UE收到block

data的数量”使用方法：NodeB收到上行SpecialBurst或者 block

data进行累加，链路删除时上报；最大254，超过254取最大值。如果出现组合业务，取所有业务的累加值。对呼叫早

的处理：RAB建立请求统计点后移干扰余量分场景设置：精细调整RRC、RAB阶段的初始“产品改进”与“网络优化”共同保证成功交付NodeBCHR共同构筑版本提升RAB新增话统打点参数设置话统打点改进Page24Page25第1章CS/PS接通率第1节接通率基础第2节接通率问题分析方法第3节接通率优化提升方法第4节接通率典型案例接通率提升案例-1现象A局点CS/PS接通率一直维持99.1～99.2左右，相对省内友商局点竞争压力较大，需要优化提升主要是因为RRC建立成功率较低，为99.2左右；，为99.85左右。因此，针对该局点，需要重点eply问题，当前版本暂时无法判断故障在上行取全面优化的策略，需要提升RRC建立过程的初立的同步流程和层三消息顺利进行。R配置一致，应该不是主要问题4.

下行干扰余量按照基线配置180，经过计算应该足够措施5.

上行干扰余量按照基线1.

提升上行干扰余量为192.

其它参数辅助：N300=效果以上措施，PS/CS接通配7率A局点全网无线接通率指标趋势99.10%99.20%99.30%99.40%99.50%99.60%99.00%98.90%98.80%2-

2-

2-

2-

2-

2-

2-

2-

2-

3-1

3-2

3-3

3-4

3-5

3-6

3-7

3-8

3-9

3-20

21

22

23

24

25

26

27

28

10CS无线接通率PS无线接通率A局点全网RRC指标趋势99.60%99.55%99.50%99.45%99.40%99.35%99.30%99.25%99.20%99.15%99.10%99.65%2-

2-

2-

2-

2-

2-

2-

2-

2-

3-1

3-2

3-3

3-4

3-5

3-6

3-7

3-8

3-9

3-20

21

22

23

24

25

26

27

28

10会话类RRC建立成功率总体RRC建立成功率Page26接通率提升案例-2现象B局点的CS接通率较低，主要因为RAB接通率较差。2月4日CS

RRC成功率99.12%，CS

RAB成功率99.13%，CS接通率98.26。分析1.PCHR分析，RAB建立失败80％的原因为“RB建立等待UE响应超时”2.话统中发现CS

RAB的尝试次数比CS

RRC的尝试次数多5％左右，怀疑该局点并发业务量比较大3.PCHR进一步发现并发业务中CS

RAB的建立成功率为76.87％，现然非常低4.该局点打开了下行伴随信道二倍帧分，在先建立PS，再建立CS的并发业务中，下行伴随信道下发的信令会比不帧分情况下需要的时间更长；因此，需要增大ACTTIMEDEFOFFVALFORSAMECELL措施将ACTTIMEDEFOFFVALFORSAMECELL由原配置80修改为160效果修改该参说后，CS域RAB建立成功率由99.2％左右提升到99.7％左右Page27Page28第1章

性能

与问题处理第2章CS/PS接通率第3章CS/PS掉话率第4章CS/PS互操作成功率Page29第1章CS/PS掉话率第1节掉话率基础第2节掉话率问题分析方法第3节掉话率优化提升方法第4节掉话率典型案例掉话信令流程与话统规范1.

在业务进行过程中，RNC主动发出IuRelease

Request或RAB

ReleaseRequest 链路，则发生掉话2.

Iu 完成后，需要依次

RRC、RL3.

右图是一个典型的PS掉线中国移动指标规范：TD语音业务无线掉话率=（语音业务RABRAB次数）÷语音业务RAB建立成功次数业务无线掉话率=（

RA次数＋语音业务Iu

对应的次数＋

Iu

对应的RAB次数）÷

RAB建立成功次数PS域无线掉线率=（PS域RA

次数＋PS域I

对应的RAB次数）÷PS域RAB建立成功次数以上定义存在不足之处：分母应该添加“硬切换成功切入次数”Page30Page31话统中掉话原因细分CSRAB.RelReqCsPerCause.113RNC请求 的按原因分类的电路域RAB数目<OM干预>RAB.RelReqCsPerCause.40RNC请求 的按原因分类的电路域RAB数目<一定时间后，数据量很小>RAB.RelReqCsPerCause.16RNC请求 的按原因分类的电路域RAB数目<用户无响应>RAB.RelReqCsPerCause.1RNC请求 的按原因分类的电路域RAB数目<RAB抢占>RAB.RelReqCsPerCause.65RNC请求 的按原因分类的电路域RAB数目<AAL2失步>PSRAB.RelReqPsPerCause.113RNC请求 的按原因分类的分组域RAB数目<OM干预>RAB.RelReqPsPerCause.40RNC请求 的按原因分类的分组域RAB数目<一定时间后，数据量很小>RAB.RelReqPsPerCause.16RNC请求 的按原因分类的分组域RAB数目<用户无响应>RAB.RelReqPsPerCause.1RNC请求 的按原因分类的分组域RAB数目<RAB抢占>RAB.RelReqPsPerCause.RbResetRNC请求 的按原因分类的分组域RAB数目<RB复位>RAB.RelReqPsPerCause.GtpuLossRNC请求 的按原因分类的分组域RAB数目<GTPU失步>RAB

：CSIU.AttConnRelReqUtranCs.113RNC请求 电路域Iu连接次数<OM干预>IU.AttConnRelReqUtranCs.16RNC请求 电路域Iu连接次数<UE无响应>IU.AttConnRelReqUtranCs.RlFailRNC请求 电路域Iu连接次数<RL

失步>IU.AttConnRelReqUtranPs.113RNC请求 分组域Iu连接次数<OM干预>PSIU.AttConnRelReqUtranPs.16RNC请求 分组域Iu连接次数<UE无响应>IU.AttConnRelReqUtranPs.RlFailRNC请求 分组域Iu连接次数<RL失步>IU.NbrRabPsRelIuConnPerCause.113RNC请求 分组域Iu连接对应的RAB数目<OM干预>IU.NbrRabPsRelIuConnPerCause.40RNC请求 分组域Iu连接对应的RAB数目<一定时间后，数据量很小>IU.NbrRabPsRelIuConnPerCause.16RNC请求 分组域Iu连接对应的RAB数目<UE无响应>IU.NbrRabPsRelIuConnPerCause.RlFailRNC请求 分组域Iu连接对应的RAB数目<RL失步>IuPage32话统常见掉话原因解释CallDropRL

FailureSRBResetUserInactiveTRB

ResetRL

Failure：NodeB持续检测上行空口链路，当检测到NOUTSYNCIND个连续失步帧，启动TRLFAILURE，若该定时器超时仍未收到NINSYNCIND个同步帧，则判断上行失步，向RNC发出Radio

Link

Failure

Indication消息；RNC判断若经过了RLRSTRTMR

＋

N302×T302时间未收到NodeB发出的Radio

Link

Restore，则向

网发出Iu

ReleaseRequest

链路SRBReset：在RLC

AM模式下，某个PDU经过了Max_DAT-1次重传后，都没有成功发送，发送端因此发起一次RLC重置过程。若在TIMERRST时间内接收了到对端响应，则停止TIMERRST定时器。如果TIMERRST定时器超时，重新发起RLC重置过程，直至经过MAXRST后尝试后，发生掉话，RNC发出IuRelease

Request消息，携带原因值Connection

with

UElost；CDT显示的RLC层原因为SRB

Reset。User

Inactive：正常 ，不计如掉话TRB

Reset：针对AM模式的TRB，原理同SRB

Reset除UserInactive外，其余主要掉话问题，都与空口质量有关掉话率网上表现RAB异常原因次数原因解释RR_ERR_RNCAP_RLC_FAILURE_SRB_RST651信令RB复位，CS、PS业务均会出现RR_ERR_RNCAP_RLC_FAILURE_TRB_RST405业务RB复位，PS业务会出现RR_ERR_RNCAP_RB_WAIT_UE_RB_CFG_TIMEOUT97DCCC过程，发出RB

RECFG后，等待UE返回RB

RECFG消息超时；PS业务专有RR_ERR_RNCAP_CU_WAIT_UE_RSP_TIMEOUT34收到UE的CellUpdate请求并响应，但是没有收到PHY

ChannelComplete消息RR_ERR_IUB_INTERFACE_PERMANENT_RL_FAILURE27NodeB检测到上行失步，在定时器超时后

IuRR_ERR_RNCAP_RB_CU_OVERLAP_BACK19RB重配置过程，未收到RBRECFG

Complete，收到CellUpdateRR_ERR_RNCAP_RELOC_PSOUT_IU_REL_CMD_TIMEOUT6PS从3G到2G切换，等待Iu

Release

Command超时RR_ERR_RNCAP_DEL_OLD_CCB4两种场景：（1）是UE掉话RNC侧没有

（原有CCB表没有删除），但UE同时又发起了接入流程，导致第一次接入被强制

；（2）当前子系统用户数满，此时新接入用户会剔除之前重连次数最多的用户RR_ERR_UU_INTERFACEPATIBLE_SIM_RECFG_ERR_NULL_TYPE1从PCHR中信令看，发生RB

RECFG

FAIL；判断应该与终端突发异常有关掉话问题主要发生在空口！PS域无线掉线率CS域无线掉话率五月1.17%

↑0.17%

↑三月1.48%0.22%近两月接通率各项指标均有提升！PCHR异常原因值解析（以某局点数据为例）：Page33Page34第1章CS/PS掉话率第1节掉话率基础第2节掉话率问题分析方法第3节掉话率优化提升方法第4节掉话率典型案例“TOP”思想在掉话率问题中的运用TOP分析各过程，可进行交叉分析；如针对某TOP原因筛选所在的TOP小区、TOP终端掉话率低！怎么办？TOP原因：根据话统判断，影响掉话率的主要原因有哪些？各占比例多少？根据PCHR分析，造成掉话的原因有哪些？各占比例多少？结合前面解释的话统掉话原因与PCHR掉话原因，优先处理非空口原因的接入失败TOP小区：根据话统、PCHR对发生掉话的TOP小区进行排序，查找TOP小区针对TOP小区的TOP原因，采取对应解决措施TOP小区的相关告警信息需要关注；根据PCHR过滤的框、槽、端口异常信息需要关注必要时可对TOP小区进行实地测试以发现、分析问题关注漏配邻区对掉话率的影响，必要时可使用RNC的漏配邻区检测功能TOP

IMSI/IMEI：PCHR分析前先做“

UE标识”的操作根据PCHR筛选出掉话呼叫，自定义输出IMSI/IMEI等信息后，使用Excel数据

判断TOP

IMSI/IMEI信息对于TOPIMSI/IMEI，可分析其业务特征：是否出现周期性掉话，是否出现超短呼叫，整个呼叫过程的上行链路质量等对于查找出的TOP

IMSI/IMEI，可采用该终端进行复测，或者直接IMSI的CDT和载频TPCwinPage35利用PCHR深入分析掉话率问题公共信息块1.

IMSI，IMEI2.

UE功率能力信令接入块1.

接入小区、载频、时隙2.

接入小区P CH

RSCPRAB信息块1.

RAB请求业务类型2.

RAB请求完成时间3.

RAB掉话域业务指示4.

链路质量信息（上行BLER等信息）5.

RAB异常错误编码DCCC信息块1.

DCCC是否成功统计块1.

同频硬切换发起、成功次数2.

异频硬切换发起、成功次数3.

CellUpdate发起、成功次数4.

RNC间切换发起、成功次数RRC

块1.时所在小区、载频、时隙2.

IU

具体原因3.

RRC

RF信息4.

信令流程根据PCHR，可分析：1.

掉话特性与接入电平的关系2.

掉话特性与超短呼叫的关系3.

掉话特性与链路质量信息的关系4.

掉话特性与DCCC的关系5.

掉话特性与频繁切换关系6.

……Page36Page37第1章CS/PS掉话率第1节掉话率基础第2节掉话率问题分析方法第3节掉话率优化提升方法第4节掉话率典型案例掉话率优化提升措施：场景优化系统内、系统间切换成功率1.

切换不成功或不及时，对掉话的影响很大2.

对于掉话率集中的小区，需要分析其对应的系统内、系统间切换成功率3.

通过PCHR可以分析呼叫

前发出的测量报告，以及发生切换的结果；据此可以将切换性能与掉话性能紧密联系起来帧分打开场景下PS掉线率的优化DCCC频繁导致的掉话1.

对于PS业务，频繁的DCCC会增大掉线风险，表现为RB重配置时等待UE响应超时2.

通过PCHR可以分析PS掉线与DCCC次数之间的关系，以此作为优化调整DCCC参数的依据3.

DCCC场景的优化，通常以降低DCCC次数为标杆；但合理的优化需要同时考虑用户体验1.

已知部分终端对帧分特新支持较差，打开网络侧帧分，会导致PS掉线抬升；根据PCHR可判断TOP

IMEI的影响2.

帧分打开场景下，需要关闭DOFFC功能3.

在5.0版本之前，可适当增大ACTTIMEDEFOFFVALFORUNCELLH以减少PHY

Channel

RECFG未被UE收到的情况频繁切换与若覆盖掉话1.

除了通过路测发现频繁切换以外，还可以通过PCHR来查找贫乏切换呼叫2.

PCHR中的HHO统计块包含丰富的信息（同频切换、异频切换、CellUpdate、RNC间切换的请求、成功次数）3.

根据这些信息，结合呼叫时常，可判断掉话与切换、CellUpdate的关系Page38Page39第1章CS/PS掉话率第1节掉话率基础第2节掉话率问题分析方法第3节掉话率优化提升方法第4节掉话率典型案例话统掉话率提升案例现象、、、3等PS掉话率比较高，通过话统几天的话统看小区掉话次数也多分析1.

通过分析小区40644的PCHRLog，发现很多呼叫在短时间内发生了很多次切换，如下图，不到5分钟的呼叫切换了22次2.

查看PCHR最后15条信令也是由于切换物理信道重配过程中的掉话3.

通过PCHR提取出该小区的Top掉话IMSI， 标口消息，证实用户不断在做乒乓切换，两次切换只间隔9s4.

用同样方法也找到4667也是由于乒乓切换而导致的掉话高措施为了防止小区4667和48053，58053和40644乒乓切换，将CELLINDIVIDALOFFSET从0改为-10效果修改参数后，掉话率得到明显好转N454CellNamePS业务掉话率PS业务掉话次数PS业务RAB建立成功次数406440.1033324580530.061017446670.14322Page40Page41第1章

性能

与问题处理第2章CS/PS接通率第3章CS/PS掉话率第4章CS/PS互操作成功率Page42第1章CS/PS互操作成功率第1节互操作基础第2节互操作问题分析方法第3节互操作优化提升方法第4节互操作典型案例CS互操作信令流程与话统规范中国移动指标规范：系统间CS域切换成功率（TD-SCDMA->GSM）=(电路域系统间切换出请求次数（3G->GSM）-电路域系统间切换出失败次数（3G->GSM）)/电路域系统间切换出请求次数（3G->GSM）*100%MAP/EMAP/E2.

PREPARE

HANDOVERBSSMAPBSSMAP4.

HANDOVER

REQUESTACKRANAPRANAP13.

IU

RELEASE

COMPLETEBSSMAPBSSMAP3.

HANDOVER

REQUESTMAP/EMAP/E5.

PREPARE

HANDOVERRESPONSERANAPRANAP6.

RELOCATION

COMMANDBSSMAPBSSMAP8.

HANDOVER

DETECTBSSMAPBSSMAP10.

HANDOVER

COMPLETEMAP/EMAP/E11.

SEND

END

SIGNALREQUESTMAP/EMAP/E14.

SEND

END

SIGNALRANAPRANAP1.

RELOCATION

REQUIREDUENodeBSRNCCNGSM/MSCGSM/BSCRRC7.DCCH

:

HANDOVER

FROM

UTRAN

COMMANDRRC[Hard

Handover]RR9.

HANDOVER

COMPLETERRRANAPPage43RANAP12.

IU

RELEASE

COMMANDRESPONSEPS互操作信令流程与话统规范中国移动指标规范：系统间PS域切换成功率（TD-SCDMA->GPRS，UTRAN发起）=(网络侧发起分组域系统间切换出请求次数（TD-SCDMA->GPRS）-分组域系统间切换出失败次数（TD-SCDMA->GPRS）)/网络侧发起分组域系统间切换出请求次数（TD-SCDMA->GPRS）*100%Page44Page45指标含义IRATHO.FailOutCs.1原因为<配置不支持>的电路域系统间小区间切换出失败次数(TD-SCDMA->GSM)IRATHO.FailOutCs.2原因为<物理信道失败>的电路域系统间小区间切换出失败次数(TD-SCDMA->GSM)IRATHO.FailOutCs.3原因为<协议错误>的电路域系统间小区间切换出失败次数(TD-SCDMA->GSM)IRATHO.FailOutCs.4原因为<系统间协议错误>的电路域系统间小区间切换出失败次数(TD-SCDMA->GSM)IRATHO.FailOutCs.5原因为<不可知错误>的电路域系统间小区间切换出失败次数(TD-SCDMA->GSM)IRATHO.FailOutCs.NoRsp原因为<无响应>的电路域系统间小区间切换出失败次数(TD-SCDMA->GSM)IRATHO.FailOutCs.RelocAbort原因为<迁移流程中止>的电路域系统间小区间切换出失败次数(TD-SCDMA->GSM)指标含义IRATHO.FailOutPsUtran.1原因为<配置不支持>的分组域系统间小区间切换出失败次数(TD-SCDMA->GPRS)IRATHO.FailOutPsUtran.2原因为<物理信道失败>的分组域系统间小区间切换出失败次数(TD-SCDMA->GPRS)IRATHO.FailOutPsUtran.3原因为<协议错误>的分组域系统间小区间切换出失败次数(TD-SCDMA->GPRS)IRATHO.FailOutPsUtran.4原因为<不可知错误>的分组域系统间小区间切换出失败次数(TD-SCDMA->GPRS)IRATHO.FailOutPsUtran.NoRsp原因为<无响应>的分组域系统间小区间切换出失败次数(TD-SCDMA->GPRS)CS域互操作失败原因：PS域互操作失败原因：互操作话统指标细分Page46CS互操作常见失败原因之“物理信道失败”现象：TD网络侧在下发HANDOVER

FROM

UTRAN之后，终端回复了HANDOVER

FROMUTRANFAILURE，其中携带的原因值是物理信道失败，在互操作失败原因统计中，该原因是当前CS互操作失败的top1原因，占70％以上。原因：目标GSM小区原因：干扰较大或者存在快衰，终端与GSM小区同步和接入过程失败终端测量原因：(1)GSM邻小区存在同频邻小区，导致终端测量的GSM目标小区RSSI值虚高；(2)在配置GSM同频邻小区的情况下，部分终端不能正确解析BISC码，导致上报的邻区和实际切换不是同一个小区，展讯和联芯都存在此问题配置错误：GSM邻小区信息未正确配置导致终端在上报测量报告后，网络侧资源准备完成，但是在同步时不能成功；终端本身bug：展讯2G网络“伪频点”配置导致终端死机现象；终端上报RSSI值很小的GSM邻区，导致切换失败；终端不支持A5-2加密算法，导致切换流程失败；终端能力上报不支持1800M的GSM，导致切换失败；CS互操作常见失败原因之“迁移流程终止”现象：TD网络侧在下发HANDOVERFROMUTRAN之后，并未收到终端回复的任何信息，随后

发起由于

lpete定时器超时导致的IUReleaseCommand，从用户感受角度，直接掉话；从话统角度，由于是

网主动发起

，只是一次切换失败，不会记为掉话。该原因是当前CS互操作失败的top2原因，占20％左右。原因：终端本身bug，例如酷派6168，无线固话等等；终端bug导致切换时迁移流程终止；终端没有收到切换命令切换失败回到TD，TD没有收到Page47PS常见失败原因之“物理信道失败”现象:RNC向UE发送CELLCHANGEORDER消息后，UE由于无法重选入GSM小区，回退到TD网络时向网络回CELLCHANGEORDERFAILURE消息，携带原因为物理信道失败，该原因是当前CS互操作失败的top1原因，占90％以上。原因：由于PS切换没有资源预留过程，如果目标小区负载较高，PS业务切换到目标小区时可能被准入

，导致切换失败；其他原因同CS切换失败Page48互操作成功率网上表现区域接通率周平均指标：CS域3Gto2G切换成功率PS3Gto2G切换成功率五月98.32%

↑94.98%

↑三月98.00%94.11%PCHR异常原因值解析（以某局点数据为例）：近两月互操作成功率逐步提升！切换域互操作切换结果次数原因解释CSRR_ERR_UU_IRHFC_IRHFC_PHY_CHANEL_FAIL(185468956)1883物理信道失败RR_ERR_IU_INTERFACE_TIMER_RELOC_CMP_EXPIRY(185272289)763迁移流程终止，联芯已定位终端存在bugRR_ERR_RNCAP_RELOC_SYS_HO_UU_HO_FAIL(185468901)1833A测量报告后伴随CELL

UPDATE流程,与空口环境相关。RR_ERR_IU_INTERFACE_REQUESTED_INFO_NOT_AVAIL(185272327)1242准备失败，不计入切换统计，5.0版本解决该问题PSRR_ERR_UU_IRCFC_PHY_CHANEL_FAIL(185468992)3111物理信道失败RR_ERR_RNCAP_RELOC_SYS_HO_UU_HO_FAIL(185468901)8313A测量报告后伴随CELL

UPDATE流程,与空口环境相关。RR_ERR_RNCAP_RELOC_PSOUT_IU_REL_CMD_TIMEOUT(185272280)231无响应RR_ERR_UU_IRCFC_CONF_UNACCEPT(185468991)93终端问题：大唐DT800H数据卡、

贝尔

ASB

T920Page49Page50第1章CS/PS互操作成功率第1节互操作基础第2节互操作问题分析方法第3节互操作优化提升方法第4节互操作典型案例CS互操作分析流程根据checklist检查基本参数配置是否正确根据话统cell-gcell表，分析切换失败的top小区（取一周的话统cell-gcell数据，根据top小区分析原则选取top小区）结合话统cell-gcell表和PCHR数据，分析切换失败的top原因物理信道失败迁移流程终止终端原因或者用户行为原因判断方法：1、根据PCHR分析，找出top终端类型，和互操作问题终端比较；2、同一IMSI在不同小区经常切换失败，而其他IMSI在这些小区切换正常，；解决方法：1、展讯终端问题，参照展讯终端问题解决方法；2、中兴U110终端问题，参照U110解决方法;3、针对top

IMSI，

用户，判断是否由于用户行为导致切换失败，必要时可以进行回访等终端原因判断方法：RNC下发切换指令后，终端尝试切换到2G失败，但返回TD也失败（没有回复“Handover

From

UTRAN

Failure”消息），最终

网IU接口保护定时器超时，下发IU

Release

Command消息，原因值为“Trelocco

mplete－expire”。解决方法：通过降低本系统门限规避CS互操作成功率<98%?是分析整网CS互操作次数是否突变，若有突变，分析各RNC

CS互操作次数是否突变，判断是否由于参数调整、移动业务推广等因素导致切换次数增加或减少，成功率下降开始CS互操作成功率〉98%，每天跟踪指标变化趋势，若发生突变否邻区配置不合理或者邻区干扰大判断方法：1、同一IMSI切换到某一个邻区失败，而切换到其他小区成功；2、所有切入该2G邻区的成功率偏低解决方法：1、调低该邻区的CIO2、提高3A异系统门限；3、结合2G话统分析，如果900M邻区干扰较大，直接删除该2G邻区或者用1800M小区替换；CS互操作指标分析流程Page51结合话统cell-gcell表和PCHR数据，分析切换失败的top原因无响应不可知错误物理信道失败解决方法：检查

RELOCIURELCMDTMR定时器设置是否为60000，若不是，则进行修改解决方法：分析DCCC参数设置，若设置策略为快升快降，调整为慢升慢降策略解决方法：1、同CS处理方法2、系统间切换失败惩罚门限/AMNTOFINTERRATCELLPELS设置为1根据checklist检查基本参数配置是否正确分析整网PS互操作次数是否突变，若有突变，分析各RNCPS互操作次数是否突变，判断是否由于参数调整、移动业务推广等因素导致切换次数增加或减少，成功率下降开始PS互操作成功率〉93%，每天跟踪指标变化趋势，若发生突变PS互操作成功率<93%?否是PS互操作指标分析流程Page52PS互操作分析流程“TOP”思想在互操