掉话率指标及问题分析

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

掉话率指标及问题分析
1、集团拉网测试指标
2、KPI掉话率指标分析
2.1、掉话率指标定义:
掉话率= RNC主动发起的Iu释放个数(此Iu存在RAB)/RAB总建立成功个数2.2、掉话率指标解释:
2.2.1、话音业务RNC主动发起的Iu释放涉及以下计数器
2.2.2、计数器的计算公式如下:
公式英文表示:
语音12.2k业务掉话率:
100%*(($DT_RAB.RelReqCsPerTraffic.Conv.<1><1>$+$DT_RAB.RelReqCsPerTraffic.Conv.< 2><2>$)+($DT_IU.NbrRabCsRelIuConnPerTraffic.Conv.<1><1>$+$DT_IU.NbrRabCsRelIuCon nPerTraffic.Conv.<2><2>$))/(($DT_RAB.SuccEstabCsNoQueuing.Conv.<1><1>$+$DT_RAB.S uccEstabCsNoQueuing.Conv.<2><2>$)+($DT_RAB.SuccEstabCsQueuing.Conv.<1><1>$+$DT_ RAB.SuccEstabCsQueuing.Conv.<2><2>$))
VP视频电话业务掉话率:
100%*($DT_RAB.RelReqCsPerTraffic.Conv.<5><5>$+$DT_IU.NbrRabCsRelIuConnPerTraffic. Conv.<5><5>$)/($DT_RAB.SuccEstabCsNoQueuing.Conv.<5><5>$+$DT_RAB.SuccEstabCsQ ueuing.Conv.<5><5>$)
计数器表示:
语音业务掉话率:
(((R002_723-R002_709)+(R002_709))+((R005_174-R005_002)+(R005_002)))/(((R002_722-R00 2_002)+(R002_002))+((R027_002+R027_003+R027_004)+(R027_001)))*100%;
VP视频电话业务掉话率:
2.2.3、指标的详细解释:
3、UE链路释放信令流程分析3.1、UE释放流程分析:
3.1.1、UE正常的链路释放流程分析:
上面信令流程为UE发起的CS域呼叫释放的例子,包括Iub口释放,及RRC释放。

当UE和核心网首先主动发起链路释放时,一般不记为掉话或掉线,当RNC主动发起链路释放时,一般记为掉话或掉线。

3.1.2、UE异常释放分析:
当UE在进行业务过程中,由于无线链路失败,以及上下行失步触发小区更新,而小区更新失败,导致RNC主动向核心网发送Iu Release Request,导致掉线或掉话。

解决方案:
1)确认该终端所在位置,以及该区域信号覆盖是否良好(包括RSCP和C/I)
2)检查终端所占小区载波及时隙的ISCP值是否符合要求(载波ISCP值可以在LMT-B上
检查,时隙ISCP值可以在OMT上检查)
3)分析该终端出现此类掉话及掉线次数,确认该终端型号及其批次。

3.2、切换流程分析:
3.2.1、Intra-Node B切换:
3.2.1.1、接力切换正常流程:
信令流程说明:
1)RNC判决进行切换后向NB发送无线链路增加请求,为目标小区建立无线链路。

目标小区收到无线链路增加请求后,配置相应链路资源,配置完成后组织无线链路,
向RNC发送RL增加响应消息。

2)RNC收到目标小区的响应消息后,为目标小区建立Iub传输承载AAL2。

3)RNC通过源小区的信道向UE发送PHYSICAL CHANNEL RECONFIGURATION
消息,通知UE进行切换。

4)UE收到PHYSICAL CHANNEL RECONFIGURA TION消息后,根据接收到的切换
指令做相应配置及处理后,通过目标小区向RNC发送PHYSICAL CHANNEL
RECONFIGURA TION COMPLETE消息。

5)RNC收到该消息后删除源小区的无线链路和Iub传输承载,切换完成。

3.2.1.2、异常流程1-NODE B失败
UE Node B RNC CN
异常流程说明:
1)当Node B不能按照要求为该用户增加RL时,向RNC返回RL Addition Failure消
息,并包含失败原因;
2)切换失败,UE继续在源小区进行通信或掉话;
实体处理方法:
1)检查目标小区告警及资源状态,可以从LMT-B查询;
2)检查对比RNC下发的RL Addition Request中携带的参数是否正确。

3.2.1.3、异常流程2-UE响应切换失败
RNC向UE发送Physical Channel Reconfiguration消息进行切换。

由于一些错误原因导致UE
向RNC发送物理信道重配置失败的响应。

导致UE发送失败响应的原因可能为:
1)UE收到的消息协议错;
2)Physical Channel Reconfiguration消息中包含无效的配置信息;
3)Physical Channel Reconfiguration消息中包含UE不支持的配置信息;
4)配置信息不匹配;
5)UE物理信道配置失败;
6)重配过程中无线链路失败等。

UE Node B RNC CN
异常流程说明:
1)当Iub接口无线链路以及AAL2连接建立完成以后,RNC向UE发送Physical Channel
Reconfiguration进行切换。

当上述某项原因出现时,UE向RNC返回Physical Channel Reconfiguration Failure消息。

2)RNC与Node B释放Iub接口的RL。

3)RNC与Node B释放Iub接口的AAL2连接。

4)切换过程失败,UE继续在源小区进行通信或产生掉话;
当UE回复切换失败原因中携带的原因值为无效配置和物理信道失败时:
1)对于该两类原因首先要确认RNC下发切换消息中携带的参数是否正确
2)确认UE的处理能力(可以从呼叫过程RRC建立完成消息中查到
3)检查目标邻小区参数配置是否正确
当UE回复切换失败原因中携带的原因值为TIMEOUT时,其解决方案:
1)确认UE所在的位置及该区域的信号覆盖(包括RSCP和C/I)是否良好;
2)检查源小区配置的邻区是否合适;
3)检查周围是否存在与目标小区同频同码的小区;
4)确认该小区邻小区的参数是否正确;
5)检查目标小区主载波ISCP值(可以从LMT-B上查询)和所占时隙ISCP值(可以从
OMT上查询);
6)确认所用终端的型号及批次;
7)检查源小区定时器参数:检查后可以适当延长下列几类定时器参数,该类参数的主要作
用在于避免由于网络定时器的超时,而主动拆链导致的切换失败,延长该类定时器可以
3.2.1.4、异常流程3-定时器超时失败
定时器超时,指的是RNC在给UE发送了空中接口的配置消息后,在一定的时间内既没有收到用户的成功响应消息,也没有收到失败消息,和UE失去了联系,此释放该用户的所有业务。

异常流程说明:
1)RNC在给UE发送了空中接口的配置消息后,在一定的时间内没有既没有收到用户的
成功响应消息,也没有收到失败消息。

2)若在目标小区已经完成RL同步,则Node B在目标小区向RNC发送Radio Link Failure
消息,原因为同步失败。

(Note (1))
3)Node B在源小区向RNC发送Radio Link Failure消息,原因为同步失败
4)RNC释放该用户的所有业务,包括:
a)RNC发起Iu连接的释放,释放Iu连接。

b)若为CS域RAB,Iu接口需释放AAL2数据传输承载。

c)RNC收回内部为该用户分配的无线资源。

d)RNC与Node B释放Iub接口的RL。

e)RNC与Node B释放Iub接口的AAL2连接。

f)RNC与UE释放Uu接口RRC连接。

5)切换过程失败。

Note (1):若在目标小区没有完成RL同步,则在目标小区没有此消息。

实体处理方法:
1)确认UE所在的位置及该区域的信号覆盖(包括RSCP和C/I)是否良好;
2)确认该小区邻小区的参数是否正确
3)检查目标小区主载波ISCP值(可以从LMT-B上查询)和所占时隙ISCP值(可以从
OMT上查询)
4)检查源小区配置的邻区是否合适
5)检查周围是否存在与目标小区同频同码的小区
6)确认所用终端的型号及批次;
3.2.2、Inter-NB\Intra-RNC切换
3.2.2.1、接力切换正常流程
Intra Node B切换与Inter Node B切换之间的主要区别在于,Intra Node B切换中目标小区与RNC之间为Radio Link Addition Request,而Inter Node B切换中目标小区与RNC之间为Radio Link Setup Request。

3.2.2.2、异常流程-Node B失败
Node B间切换时Node B失败的两种情况:
1)目标基站无线链路建立失败;
2)目标基站无线链路建立成功后,目标基站的AAL2建立失败。

异常流程说明:
1)当目标基站不能成功建立无线链路或不能建立AAL2连接时,切换过程失败,UE仍保
持与源基站小区的通信连接。

2)若为AAL2建立失败的情况,需要删除与目标基站的RL。

实体处理方法:
1)检查目标小区告警及资源使用状态,可以从LMT-B查询;
2)检查对比RNC下发的RL Setup Request中携带的参数是否正确。

3.2.2.3、异常流程-UE响应切换失败
RNC向UE发送Physical Channel Reconfiguration消息进行切换。

由于一些错误原因导致UE 向RNC发送物理信道重配置失败的响应。

导致UE发送失败响应的原因可能为:
1)UE收到的消息协议错;
2)Physical Channel Reconfiguration消息中包含无效的配置信息;
3)Physical Channel Reconfiguration消息中包含UE不支持的配置信息;
4)配置信息不匹配;
5)UE物理信道配置失败;
6)重配过程中无线链路失败等。

Inter-Node B/Intra-RNC切换,UE响应切换失败
异常流程说明:
1)当Iub接口无线链路以及AAL2连接建立完成以后,RNC向UE发送Physical Channel
Reconfiguration进行切换。

当上述某项原因出现时,UE向RNC返回Physical Channel Reconfiguration Failure消息。

2)RNC与目标Node B释放Iub接口的RL。

3)RNC与目标Node B释放Iub接口的AAL2连接。

4)切换过程失败,UE继续在源Node B小区进行通信。

当UE回复切换失败原因中携带的原因值为无效配置和物理信道失败时:
1)对于该两类原因首先要确认RNC下发切换消息中携带的参数是否正确
2)确认UE的处理能力(可以从呼叫过程RRC建立完成消息中查到
3)检查目标邻小区参数配置是否正确
当UE回复切换失败原因中携带的原因值为TIMEOUT时,其解决方案:
1)确认UE所在的位置及该区域的信号覆盖(包括RSCP和C/I)是否良好;
2)检查源小区配置的邻区是否合适;
3)检查周围是否存在与目标小区同频同码的小区;
4)确认该小区邻小区的参数是否正确;
5)检查目标小区主载波ISCP值(可以从LMT-B上查询)和所占时隙ISCP值(可以从
OMT上查询);
6)确认所用终端的型号及批次;
7)检查源小区定时器参数:具体内容参见基站内切换分析
3.2.2.4、异常流程-定时器超时失败
定时器超时,指的是RNC在给UE发送了空中接口的配置消息后,在一定的时间内既没有收到用户的成功响应消息,也没有收到失败消息,和UE失去了联系,此释放该用户的所有业务。

异常流程说明:
1)RNC在给UE发送了空中接口的配置消息后,在一定的时间内既没有收到用户的成功
响应消息,也没有收到失败消息。

源Node B与目标Node B均向RNC发送Radio Link Failure消息,原因为同步失败。

2)RNC释放该用户的所有业务,包括:
a)RNC发起Iu连接的释放,释放Iu连接。

b)若为CS域RAB,Iu接口需释放AAL2数据传输承载。

c)RNC收回内部为该用户分配的无线资源。

d)RNC与源Node B释放Iub接口的RL。

e)RNC与源Node B释放Iub接口的AAL2连接。

f)RNC与目标Node B释放Iub接口的RL。

g)RNC与目标Node B释放Iub接口的AAL2连接。

h)RNC与UE释放Uu接口RRC连接。

3)切换过程失败。

实体处理方法:
1)确认UE所在的位置及该区域的信号覆盖(包括RSCP和C/I)是否良好;
2)确认所用终端的型号及批次;
3)确认该小区邻小区的参数是否正确
4)检查目标小区主载波ISCP值(可以从LMT-B上查询)和所占时隙ISCP值(可以从
OMT上查询)
3.2.3、Inter-RNC切换
3.2.3.1、正常切换流程
3.2.3.2、异常流程-源RNC对目标RNC的重定位准备失败
该过程描述的是,源RNC向CN发送RelocationRequired消息发起重定位时CN拒绝不能接收该重定位,可能的原因是:
1)T RELOCalloc超时;
2)目标RNC、目标CN或目标系统重定位失败;
3)目标RNC、目标系统不支持重定位;
4)不允许重定位至目标系统;
Inter -RNC切换,源RNC对目标RNC的重定位准备失败
异常流程说明:
1)RNC在收到CN的重定位准备失败消息后,重定位过程中止,源RNC仍为UE的服务
RNC。

实体处理方法:
1)确认该终端请求的业务和目标小区的资源状态;
2)检查目标小区的告警信息和小区状态。

3.2.3.3、异常流程-源RNC侧UE配置失败
该过程描述的是,重定位准备过程中,源RNC侧UE进行重定位时失败。

重定位过程失败,UE保持与源RNC进行通信。

异常流程说明及实体处理方法:
1)源RNC收到CN的重定位指令后,在Iub接口建立RL及AAL2传输承载,随后向UE
发送重配置消息,目标RNC收到由于UE侧原因返回的重配置失败消息
2)源RNC在Iu接口发送Relocation Cancel消息,取消重定位。

3)目标RNC向CN发送Relocation Failure消息,指示重定位失败。

4)源RNC与源Node B释放Iub接口RL。

5)源RNC与源Node B释放Iub接口AAL2承载。

6)CN与目标RNC释放Iu接口AAL2承载。

7)重定位过程失败,UE继续与源RNC进行通信。

当UE回复切换失败原因中携带的原因值为无效配置和物理信道失败时,其解决方案:
1)对于该两类原因首先要确认RNC下发切换消息中携带的参数是否正确
2)确认UE的处理能力(可以从呼叫过程RRC建立完成消息中查到
3)检查目标邻小区参数配置是否正确
当UE回复切换失败原因中携带的原因值为TIMEOUT时,其解决方案:
1)确认UE所在的位置及该区域的信号覆盖(包括RSCP和C/I)是否良好;
2)检查源小区配置的邻区是否合适;
3)检查周围是否存在与目标小区同频同码的小区;
4)确认该小区邻小区的参数是否正确;
5)检查目标小区主载波ISCP值(可以从LMT-B上查询)和所占时隙ISCP值(可以从
OMT上查询);
6)确认所用终端的型号及批次
3.2.3.4、异常流程-目标RNC侧Iub接口过程失败
该流程描述了重定位过程中三种发生在Iub接口两侧实体上的异常情况,由于在重定位过程中这三类异常Iu接口的表现是相同的,因此本流程中做同一描述。

异常情况分别为:
1)目标RNC侧无线资源无法满足(流程中的alt.1);
2)目标RNC侧无线链路建立失败(流程中的alt.2);
3)目标RNC侧Iub接口AAL2建立失败(流程中的alt.3);
Inter -RNC切换,目标RNC侧Iub接口过程失败
异常流程说明及实体处理方法:
1)(alt.1)目标RNC收到来自CN的Relocation Request消息后,本地配置无线资源失败。

2)(alt.2)目标RNC收到来自CN的Relocation Request消息后,本地配置无线资源,RL
建立失败。

3)(alt.3)目标RNC收到来自CN的Relocation Request消息后,本地配置无线资源,RL
建立,Iub接口AAL2建立失败。

4)目标RNC向CN返回Relocation Failure消息。

5)(alt.3)目标RNC与目标Node B删除无线链路。

6)CN向源RNC响应RelocationPreparation Failure消息,重定位过程失败。

7)UE继续与源RNC进行通信。

实体处理方法:
1)确认该终端请求的业务和目标小区的资源状态
2)检查目标小区的告警信息和小区状态。

3.2.4、Inter-RAT切换
3.2.
4.1、正常切换流程
UE由TD-SCDMA网络发起话音业务请求并成功接入后,RNC会根据小区的情况发起相应的测量控制。

如果需要对相邻GSM小区测量,则相应的在测量控制消息中添加Inter-RAT 测量信息,当满足测量上报条件时UE将向RNC报告测量结果。

RNC中的RRM对测量结果进行处理判决并确定切换的目标小区,如果需要切换的目标小区为GSM小区,则执行TD-SCDMA向GSM切换过程,见下图
3.2.
4.2、异常流程-Relocation preparation过程失败
在Relocation preparation过程中,可能会有多种原因导致失败,比如CN不支持向2G网络的切换,核心网间、核心网与BSC接口或者BSS内部协议过程失败,目标GSM小区没有足够的资源等。

3.2.
4.3、异常流程-Inter-RAT handover from UTRAN过程失败
当UE接收到HANDOVER FROM UTRAN COMMAND消息后,如果不能够成功的向目标GSM小区切换,则可以重新回到源TD-SCDMA小区,并使用原有资源进行数据传输。

UE向RNC发送HANDOVER CANCEL消息,通过核心网告诉目标BSC将目标GSM小区资源释放。

当RNC接收到RELOCA TION CANCEL ACKNOWLEDGE后过程结束。

处理方法:
1)对于该两类原因首先要确认RNC下发切换消息中携带的参数是否正确
2)确认UE的处理能力(可以从呼叫过程RRC建立完成消息中查到)
3)检查目标G网邻小区参数配置是否正确;
4)确认终端在切换时的门限值是否合理;
5)确认所用终端的型号及批次。

4、CDL文件掉话失败原因分析
4.1、cdl分析关注要点
目前的CDL文件使用LDT分析后,UE掉话对应的有“掉话事件”和“掉话原因”,掉话原因为关注的重点,具体掉话原因对应的有:
1)RL failure or RLC error timer expiry。

RB建立后,掉话;
2)Receive Ue TimerOut Response Message In DTD Proc。

RB建立失败,影响接通;
3)切换过程中发生RL失败引起的掉话。

切换失败导致掉话;
4)未知原因引起的掉话。

切换失败导致掉话;
5)failed because cell update occurs。

小区更新失败导致掉话;
6)Receive Ue Timeout Msg during HO。

切换失败导致掉话;
7)小区更新超时。

实为切换失败掉话;
8)RL Failure引起的掉话。

无线链路失败触发小区更新,导致掉话;
9)user or link forece release。

UE在cs域和ps域中建立RAB,kpi中会统计为掉话或接入
失败;
10)RA THO, as waiting lu timer expire message, received a cell change order from utran failure
message。

系统间切换失败导致掉线;
11)rolled Fail during HO。

小区更新导致切换失败掉话;
12)The reason for the action is expiry of timer TRELOCoverall.。

系统间切换失败导致掉话;
13)RRC release when INTEGRITY CHECK fail。

RAB建立失败
14)Cell Update Confirm 超时。

小区更新,掉线;
15)Receive Ue Failure Response Message In DTD Proc。

RB建立失败;
16)Release is initiated due to UTRAN generated reason.。

重定位失败;
17)网络优化。

在重选过程中,无RB建立;
18)切换超时UE无响应。

在重选过程中,无RB建立;
19)Release requested due to UE generated signalling connection release。

在重选过程中;
20)re-access release。

在RRC建立完成和RAB请求之间,无RAB建立,不影响kpi;
21)The action of ue failure result RRC release。

无RAB建立,不影响kpi
4.2、掉话原因具体分析
4.2.1、RL failure or RLC error timer expiry
UE在通话过程中,NB向RNC上发RL失败指示(原因:synchronisation_failur),相隔
20s后,RNC向MSC上发IU Release Request
解决方案:具体解决方案参见UE异常释放分析
4.2.2、Receive Ue TimerOut Response Message In DTD Proc
UE在接入过程中,RNC下发RB Setup后,相隔10sUE向RNC回RB Setup Failure,原因值为Timeout。

可能为无线环境较差导致,影响kpi接通率。

该过程为接入失败,具体解决方案可以参考接通率手册。

4.2.3、切换过程中发生RL失败引起的掉话
UE在通话过程中,UE向RNC发送测量报告,发起切换,RNC向目标NB发送RL Setup Request,相隔9s后源NB向RNC回复RL Failure indication,原因值synchronisation_failure,UE与网络失步导致,可能为无线环境较差导致。

后UE回复物理信道重配失败,失败原因值:Timeout。

解决方案:具体解决方案请参考异常流程-UE响应切换失败
4.2.4、未知原因引起的掉话
此类现象CDL中记录为未知原因引起的掉话,但其实为切换失败导致的掉话。

切换失败的原因值为Timeout,源NB向RNC发送的RL Failure indication原因值synchronisation_failure,可能为无线环境较差导致。

解决方案:具体解决方案请参考异常流程-UE响应切换失败
4.2.5、failed because cell update occurs
1)UE在做PS业务时,当rnc下发rb setup后,相隔5s后触发小区更新,小区更新原因
为radiolink failure,后rnc向GSSN发起iu release request,导致接入失败。

2)UE在作ps业务时,rab建立成功后,相隔100s左右,SGSN下发RAB release。

4s后
UE发起小区更新,导致rnc向sgsn发起Iu口释放请求,该类原因为无线环境较差触发小区更新。

解决方案:一般情况下,当终端进行彩信业务是,当UE不主动发起释放时,核心网会主动会下发RAB释放,但上述原因上下行失步,导致触发小区更新,导致UE向核心网发送Iu
Release Request,导致掉线。

具体解决方案请参考UE异常释放分析
4.2.6、Receive Ue Timeout Msg during HO
UE在ps业务中,收到RNC下发的Transport Channel Reconfiguration,相隔10s后UE 回复Transport Channel Reconfiguration Failure,原因值Timeout,导致掉线。

解决方案:具体解决方案请参考异常流程-UE响应切换失败
4.2.7、小区更新超时
UE在做PS业务时,UE发生一次小区更新,小区更新成功后,UE上报测量报告发起切换,RNC下发Transport Channel Reconfiguration,UE回复Transport Channel Reconfiguration failure。

原因值为:timeout,该掉线应该为切换掉话,cdl统计为小区更新超时导致的掉话。

解决方案:具体解决方案请参考异常流程-UE响应切换失败
4.2.8、RL Failure引起的掉话
UE在做PS业务时,RAB建立完成后,触发小区更新,更新原因为: radiolinkFailure ,当RNC 向UE发送cellupda confirm,10s后NB向RNC发送RL失败指示,20s后RNC向SGSN发送IU RELEASE REQUEST,原因值为RL failure or RLC error timer expiry。

解决方案:具体解决方案请参考UE异常释放分析
4.2.9、user or link forece release
1)UE发起rrc建立请求,请求原因为:registration,后MSC和SGSN分别在cs域和ps 域发起RAB建立请求,在RNC向UE发送RB建立后1s左右,RNC向MSC发起Iu release request,原因值为user or link forece release,该类在kpi中可能统计为接入失败。

解决方案:具体解决方案请参考未接通手册
4.2.10、RATHO, as waiting lu timer expire message, received a cell change order from utran failure message
UE在建立RRC,原因值为:originatingInteractiveCall,当达到系统间切换门限时,UE上发测量报告,RNC向UE发送CELL CHANGE ORDER FROM UTRAN。

9s后NB向RNC发送RL失败指示,11s后UE上发CELL CHANGE ORDER UTRAN FAILURE,然后RNC发
送IU释放请求,导致掉线。

解决方案:具体解决方案请参考Inter-RAT handover from UTRAN过程失败
4.2.11、rolled Fail during HO
UE在做PS业务时,UE上报测量报告,RNC下发Transport Channel Reconfiguration ,ue 触发小区更新,原因为无线链路失败,RNC向SGSN发送IU RELEASE REQUEST,释放链路,统计为掉线。

解决方案:具体解决方案请参考异常流程-定时器超时失败
4.2.12、The reason for the action is expiry of timer TRELOCoverall.
UE发起RRC建立请求,发起原因为:12.2k语音业务,当cs域RAB建立成功后,UE又建立PS域rab链路,后UE上发3a测量报告,切换成功后,MSC释放cs域IU口,后SGSN 向RNC发送SRNS CONTEXT REQUEST,8s后NB向RNC发送RL失败指示,12s后CPSS
向IUC发送Iu timer abnormity,rnc向SGSN发送IU RELEASE REQUEST,原因值为:The reason for the action is expiry of timer TRELOCoverall。

UE发起RRC建立请求,发起原因为:12.2k语音业务,当cs域RAB建立成功后,UE 上发3a测量报告,RNC向UE发送Handover From UTRAN Command to GSM,9s后NB向rnc 发送RL失败指示,UE向RNC发送切换失败信令,RNC向MSC发送IU RELEASE REQUEST,原因值为:The reason for the action is expiry of timer TRELOCoverall。

解决方案:具体解决方案请参考Inter-RAT handover from UTRAN过程失败
4.2.13、RRC release when INTEGRITY CHECK fail
UE发起RRC建立请求,原因值:originatingBackgroundCall,RNC下发RB setup,8s后RNC 上发IU release request,原因值为:RRC release when INTEGRITY CHECK fail。

解决方案:具体解决方案请参考未接通分析手册
4.2.14、Cell Update Confirm 超时
UE发起RRC建立请求,建立原因:originatingInteractiveCall,RAB建立成功后,在小区21193上触发了两次小区更新,更新过程中RRM_ALLOCATE_RESOURCES_FAILURE.
解决方案:具体解决方案请参考UE异常释放分析
4.2.15、Receive Ue Failure Response Message In DTD Proc
UE发起RRC建立请求,发起原因为:12.2k语音业务,当cs域RAB建立成功后,UE又开始建立PS域rab链路,当rnc下发rb setup后,UE回复rb 建立失败,原因值为:physical channel failure,RNC向核心网发送IU release request,释放cs域和ps域,原因值为:Receive Ue Failure Response Message In DTD Proc。

为RAB建立失败。

解决方案:具体解决方案请参考未接通分析手册
4.2.16、网络优化
该类原因一般发生在重选过程中,SMC失败,原因值Timeout,同时RNC向MSC发起Iu realease request,原因值为:The action of ue failure result RRC release;该类过程无RB建立,kpi不做统计,不影响kpi。

4.2.17、切换超时UE无响应
该过程发生于小区重选过程中,无RAB建立,不影响kpi掉话率。

4.2.18、Release requested due to UE generated signalling connection release
该类原因已从kpi中剔除。

4.2.19、re-access release
UE发起RRC建立请求,请求原因为:terminatingConversationalCall ,在RNC向UE发送SMC信令,9s后NB向RNC发送RL失败指示,RNC向MSC发起Iu release request,原因值为re-access release ,MSC向RNC发送IU release command,原因值:Release is initiated due to UTRAN generated reason. 无RAB建立,不影响kpi。

4.2.20、The action of ue failure result RRC release
UE发起RRC建立请求,建立原因为terminatingHighPrioritySignalling,后在SMC过程中,ue回复SMC失败,原因为Timeout,RNC向MSC发起IU口的释放,释放原因为The action of ue failure result RRC release,MSC回复IU RELEASE COMMAND,其原因值为The UTRAN or the UE is unable to support the request。

该类原因无RAB建立,不影响kpi统计。

4.2.21、Release is initiated due to UTRAN generated reason
UE在重定位过程中,核心网向RNC下发PS域和CS域的重定位请求,但RNC向SGSN 上发IU RELEASE REQUEST,原因值为:r elocation is requested for time critical reason.
5、附录:
5.1、文档依据:
i.《无线KPI指标统计模版(V4.10.10)_V1.2》
ii.《性能测量参数数据需求-RNC分册(V2.0.0)_应答》
iii.《090508-中国移动td网络重点指标及算法v1 7》
iv.《无线接入网性能测量参数规范(d2.0.0)_20090213》
v.《TDR3000性能计数器设计报告》
5.2、CDL掉话原因及处理建议。

相关文档
最新文档