掉话率指标及问题分析Word文件下载.docx
《掉话率指标及问题分析Word文件下载.docx》由会员分享，可在线阅读，更多相关《掉话率指标及问题分析Word文件下载.docx（51页珍藏版）》请在冰豆网上搜索。
掉话率=RNC主动发起的Iu释放个数（此Iu存在RAB）/RAB总建立成功个数
2.2、掉话率指标解释：
2.2.1、话音业务RNC主动发起的Iu释放涉及以下计数器
指标编码
英文名称
指标解释
RNCHC07
IU.NbrRabCsRelIuConnPerCause.Cause；
统计RNC请求释放电路域Iu连接对应的RAB数目
RNCHC09
IU.NbrRabCsRelIuConnPerTraffic.Conv
IU.NbrRabCsRelIuConnPerTraffic.Conv.<
1>
<
2>
4>
5>
IU.NbrRabCsRelIuConnPerTraffic.Strm
IU.NbrRabCsRelIuConnPerTraffic.Bgrd；
统计RNC请求释放电路域Iu连接根据业务速率细分的RAB数目
2.2.2、计数器的计算公式如下：
公式英文表示：
语音12.2k业务掉话率：
100%*（（$DT_RAB.RelReqCsPerTraffic.Conv.<
$+$DT_RAB.RelReqCsPerTraffic.Conv.<
$）+（$DT_IU.NbrRabCsRelIuConnPerTraffic.Conv.<
$+$DT_IU.NbrRabCsRelIuConnPerTraffic.Conv.<
$））/（（$DT_RAB.SuccEstabCsNoQueuing.Conv.<
$+$DT_RAB.SuccEstabCsNoQueuing.Conv.<
$）+（$DT_RAB.SuccEstabCsQueuing.Conv.<
$+$DT_RAB.SuccEstabCsQueuing.Conv.<
$））
VP视频电话业务掉话率：
100%*（$DT_RAB.RelReqCsPerTraffic.Conv.<
$）/（$DT_RAB.SuccEstabCsNoQueuing.Conv.<
$）
计数器表示：
语音业务掉话率：
（（（R002_723-R002_709）+（R002_709））+（（R005_174-R005_002）+（R005_002）））/（（（R002_722-R002_002）+（R002_002））+（（R027_002+R027_003+R027_004）+（R027_001）））*100%；
（（R002_714）+（R005_012））/（（R002_082）+（R027_006））*100%；
计数器
计数器详细说明
R002_723
RAB释放请求次数
R002_709
RAB释放请求次数（CS会话类（12.2k））
R005_174
存在RAB时RNC发给CS域Iu释放请求次数（CS会话类（AMR））
R005_002
存在RAB时RNC发给CS域Iu释放请求次数{存在RAB时RNC发给CS域Iu释放请求次数}
R002_722
RAB建立成功次数
R002_002
RAB建立成功次数（CS会话类（12.2k）
R027_002
有排队的RAB建立成功次数（CS会话类业务（7.95k））
R027_003
有排队的RAB建立成功次数（CS会话类业务（5.9k））
R027_004
有排队的RAB建立成功次数（CS会话类业务（4.75k））
R027_001
有排队的RAB建立成功次数（CS会话类业务（12.2k））
R002_714
RAB释放请求次数（CS会话类（64k））
R005_012
存在RAB时RNC发给CS域Iu释放请求次数（CS会话类（64k））
R002_082
RAB建立成功次数（CS会话类（64k））
R027_006
有排队的RAB建立成功次数（CS会话类（64k））
2.2.3、指标的详细解释：
RNCHA07
中文名称
按原因分RNC请求释放电路域Iu连接对应的RAB数目
定义
统计RNC请求释放电路域Iu连接对应的RAB数目，应该按请求原因分类统计。
单位：
个；
触发点
RNC向电路域CN发送“IU连接释放请求”（IURELEASEREQUEST）消息，统计对应的RAB数目。
每个原因对应一个子测量项。
（3GPPTS25.413）
采集方式
CC；
数据类型和取值说明
每个子测量项的数据类型为整型；
单位
个
统计的空间粒度
RncFunction；
统计的时间粒度
15分钟
上报周期
备注
终端发起的释放不统计在内
RNCHA09
4.2.2.3.9按业务速率分RNC请求释放电路域Iu连接对应的RAB数目
统计RNC请求释放电路域Iu连接根据业务速率细分的RAB数目。
每个根据业务速率细分的业务类型对应一个子测量项，业务类型定义参见3GPPTS23.107。
根据业务速率细分的业务类型定义参见附录B；
3、UE链路释放信令流程分析
3.1、UE释放流程分析：
3.1.1、UE正常的链路释放流程分析：
上面信令流程为UE发起的CS域呼叫释放的例子，包括Iub口释放，及RRC释放。
当UE和核心网首先主动发起链路释放时，一般不记为掉话或掉线，当RNC主动发起链路释放时，一般记为掉话或掉线。
3.1.2、UE异常释放分析：
当UE在进行业务过程中，由于无线链路失败，以及上下行失步触发小区更新，而小区更新失败，导致RNC主动向核心网发送IuReleaseRequest，导致掉线或掉话。
解决方案：
1）确认该终端所在位置，以及该区域信号覆盖是否良好（包括RSCP和C/I）
2）检查终端所占小区载波及时隙的ISCP值是否符合要求（载波ISCP值可以在LMT-B上检查，时隙ISCP值可以在OMT上检查）
3）分析该终端出现此类掉话及掉线次数，确认该终端型号及其批次。
3.2、切换流程分析：
3.2.1、Intra-NodeB切换：
3.2.1.1、接力切换正常流程：
信令流程说明：
1）RNC判决进行切换后向NB发送无线链路增加请求，为目标小区建立无线链路。
目标小区收到无线链路增加请求后，配置相应链路资源，配置完成后组织无线链路，向RNC发送RL增加响应消息。
2）RNC收到目标小区的响应消息后，为目标小区建立Iub传输承载AAL2。
3）RNC通过源小区的信道向UE发送PHYSICALCHANNELRECONFIGURATION消息，通知UE进行切换。
4）UE收到PHYSICALCHANNELRECONFIGURATION消息后，根据接收到的切换指令做相应配置及处理后，通过目标小区向RNC发送PHYSICALCHANNELRECONFIGURATIONCOMPLETE消息。
5）RNC收到该消息后删除源小区的无线链路和Iub传输承载，切换完成。
3.2.1.2、异常流程1-NODEB失败
异常流程说明：
1）当NodeB不能按照要求为该用户增加RL时，向RNC返回RLAdditionFailure消息，并包含失败原因；
2）切换失败，UE继续在源小区进行通信或掉话；
实体处理方法：
1）检查目标小区告警及资源状态，可以从LMT-B查询；
2）检查对比RNC下发的RLAdditionRequest中携带的参数是否正确。
3.2.1.3、异常流程2-UE响应切换失败
RNC向UE发送PhysicalChannelReconfiguration消息进行切换。
由于一些错误原因导致UE向RNC发送物理信道重配置失败的响应。
导致UE发送失败响应的原因可能为：
1）UE收到的消息协议错；
2）PhysicalChannelReconfiguration消息中包含无效的配置信息；
3）PhysicalChannelReconfiguration消息中包含UE不支持的配置信息；
4）配置信息不匹配；
5）UE物理信道配置失败；
6）重配过程中无线链路失败等。
1）当Iub接口无线链路以及AAL2连接建立完成以后，RNC向UE发送PhysicalChannelReconfiguration进行切换。
当上述某项原因出现时，UE向RNC返回PhysicalChannelReconfigurationFailure消息。
2）RNC与NodeB释放Iub接口的RL。
3）RNC与NodeB释放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）检查源小区定时器参数：
检查后可以适当延长下列几类定时器参数，该类参数的主要作用在于避免由于网络定时器的超时，而主动拆链导致的切换失败，延长该类定时器可以挽回一部分由于网络定时器超时而导致的切换失败。
最小值
最大值
默认值
参数描述
级别
IdleModeT312
空闲模式-T312
（单位：
毫秒）
1000
15000
（1000..15000）。
单位:
毫秒
启动:
：
UE在开始建立专用物理信道时启动此定时器；
停止：
测到N312次来自L1层的“insync”指示后停止；
超时：
如果超时意味着物理信道建立失败。
动态（可创建、可修改）
ConnectedModeT312
连接模式-T312
（1000..15000），单位:
毫秒。
启动：
UE在开始建立专用信道的时候启动此定时器；
检测到N312次来自L1层的“insync”指示后停止；
ConnectedModeT313
连接模式-T313
（0..15000），单位:
当UE检测到来自L1层的连续N313次“outofsync”指示后启动此定时器；
当UE检测到来自L1层的连续N315次“insync”指示后停止此定时器；
如果T313超时意味着无线链路失败。
ConnectedModeT314
连接模式-T314
2000
20000
12000
（2000,4000,6000,8000,12000,16000,20000）。
当无线链路失败后,如果存在与T314相关联的无线承载（用于CS业务）或者只存在RRC连接,则启动该定时器。
由于RL失败导致的小区更新过程结束后停止。
超时:
如果超时,释放UE.一般来说,T314<
T315。
ConnectedModeT315
连接模式-T315
秒）
1800
根据目前实验网测试结果，推荐修改为10。
（以前为180）
（0,10,30,60,180,600,1200,1800），单位:
秒。
当无线链路失败后,如果存在与T314相关联的无线承载（用于PS业务）或者只存在RRC连接,则启动该定时器。
停止:
由于RL失败导致的小区更新过程结束后停止。
如果超时,释放UE。
3.2.1.4、异常流程3-定时器超时失败
定时器超时，指的是RNC在给UE发送了空中接口的配置消息后，在一定的时间内既没有收到用户的成功响应消息，也没有收到失败消息，和UE失去了联系，此释放该用户的所有业务。
1）RNC在给UE发送了空中接口的配置消息后，在一定的时间内没有既没有收到用户的成功响应消息，也没有收到失败消息。
2）若在目标小区已经完成RL同步，则NodeB在目标小区向RNC发送RadioLinkFailure消息，原因为同步失败。
（Note
（1））
3）NodeB在源小区向RNC发送RadioLinkFailure消息，原因为同步失败
4）RNC释放该用户的所有业务，包括：
a）RNC发起Iu连接的释放，释放Iu连接。
b）若为CS域RAB，Iu接口需释放AAL2数据传输承载。
c）RNC收回内部为该用户分配的无线资源。
d）RNC与NodeB释放Iub接口的RL。
e）RNC与NodeB释放Iub接口的AAL2连接。
f）RNC与UE释放Uu接口RRC连接。
5）切换过程失败。
Note
（1）：
若在目标小区没有完成RL同步，则在目标小区没有此消息。
2）确认该小区邻小区的参数是否正确
3）检查目标小区主载波ISCP值（可以从LMT-B上查询）和所占时隙ISCP值（可以从OMT上查询）
4）检查源小区配置的邻区是否合适
5）检查周围是否存在与目标小区同频同码的小区
3.2.2、Inter-NB\Intra-RNC切换
3.2.2.1、接力切换正常流程
IntraNodeB切换与InterNodeB切换之间的主要区别在于，IntraNodeB切换中目标小区与RNC之间为RadioLinkAdditionRequest，而InterNodeB切换中目标小区与RNC之间为RadioLinkSetupRequest。
3.2.2.2、异常流程-NodeB失败
NodeB间切换时NodeB失败的两种情况：
1）目标基站无线链路建立失败；
2）目标基站无线链路建立成功后，目标基站的AAL2建立失败。
1）当目标基站不能成功建立无线链路或不能建立AAL2连接时，切换过程失败，UE仍保持与源基站小区的通信连接。
2）若为AAL2建立失败的情况，需要删除与目标基站的RL。
1）检查目标小区告警及资源使用状态，可以从LMT-B查询；
2）检查对比RNC下发的RLSetupRequest中携带的参数是否正确。
3.2.2.3、异常流程-UE响应切换失败
Inter-NodeB/Intra-RNC切换，UE响应切换失败
2）RNC与目标NodeB释放Iub接口的RL。
3）RNC与目标NodeB释放Iub接口的AAL2连接。
4）切换过程失败，UE继续在源NodeB小区进行通信。
具体内容参见基站内切换分析
3.2.2.4、异常流程-定时器超时失败
1）RNC在给UE发送了空中接口的配置消息后，在一定的时间内既没有收到用户的成功响应消息，也没有收到失败消息。
源NodeB与目标NodeB均向RNC发送RadioLinkFailure消息，原因为同步失败。
2）RNC释放该用户的所有业务，包括：
d）RNC与源NodeB释放Iub接口的RL。
e）RNC与源NodeB释放Iub接口的AAL2连接。
f）RNC与目标NodeB释放Iub接口的RL。
g）RNC与目标NodeB释放Iub接口的AAL2连接。
h）RNC与UE释放Uu接口RRC连接。
3）切换过程失败。
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）TRELOCalloc超时；
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接口发送RelocationCancel消息，取消重定位。
3）目标RNC向CN发送RelocationFailure消息，指示重定位失败。
4）源RNC与源NodeB释放Iub接口RL。
5）源RNC与源NodeB释放Iub接口AAL2承载。
6）CN与目标RNC释放Iu接口AAL2承载。
7）重定位过程失败，UE继续与源RNC进行通信。
当UE回复切换失败原因中携带的原因值为无效配置和物理信道失败时，其解决方案：
5）检查目标小区主载波ISCP值（可以从LMT-
升级会员 