LTE掉话问题定位和优化指导书V30.docx
《LTE掉话问题定位和优化指导书V30.docx》由会员分享，可在线阅读，更多相关《LTE掉话问题定位和优化指导书V30.docx（124页珍藏版）》请在冰点文库上搜索。
LTE掉话问题定位和优化指导书V30
产品名称Productname
密级Confidentialitylevel
LTE
内部公开
产品版本Productversion
Total92pages共92页
eRANV100R003C00
LTE掉话问题定位和优化指导书
（仅供内部使用）
Forinternaluseonly
拟制:
Preparedby
解决方案网络KPI组
日期：
Date
2010-09-08
审核:
Reviewedby
日期：
Date
yyyy-mm-dd
审核:
Reviewedby
日期：
Date
yyyy-mm-dd
批准:
Grantedby
日期：
Date
yyyy-mm-dd
华为技术有限公司
HuaweiTechnologiesCo.,Ltd.
版权所有XX
Allrightsreserved
修订记录Revisionrecord
日期
Date
修订版本Revisionversion
修改描述
changeDescription
作者
Author
2010-9-14
1.0
初稿完成initialtransmittal
2010-11-18
1.1
新增案例，补充分析内容
2010-12-1
1.2
补充瑞典分析结果，RLC达到最大重传次数、失步
2010-12-8
1.3
依据评审意见修改
2011-6-3
2.0
补充eRAN2.1版本相关描述
2011-10-8
2.1
按照eRAN2.1SPC400更新描述
400
2012-1-30
2.11
合入CHR分析指导书部分，增加内部机制介绍，按照评审建议修改
目录TableofContents
图目录ListofFigures
表目录ListofTables
1概述
本文重点介绍了LTE系统内掉话率指标的优化思路、分析方法、定位手段及典型案例；
本文结构如下：
第二章主要从路测、标准接口、话统、CHR多角度出发给出了掉话的定义；
第三章给出了常见的掉话原因，掉话机制的介绍；
第四章介绍了掉话问题的隔离定位分析方法；
第五章分享了掉话优化的典型案例；
第六章介绍了CHR数据的分析方法，影响掉话的定时器介绍及重建的机制介绍。
2掉话分类定义
掉话是指在UE在与eNB间成功建立eRAB之后，由于异常原因导致的eRAB释放，本章将分别从路测数据、标准接口信令、话统数据及CHR数据4个方面介绍一下掉话的表现。
2.1.路测数据
2.1.1.掉话定义
在华为Probe&Assistant侧对于掉话（eRabAbnormalRelease）的定义如下：
一、没有收到“DEACTIVATEEPSBEARERCONTEXTREQUEST”的NAS消息，也没有收到MME的“DETACHREQUEST”的NAS消息，也没有向网络侧主动发出“DETACHREQUEST”的NAS消息，收到了RRCConnectionReconfiguration消息，且其中有信元“drb-ToReleaseList”，则生成一次ERABAbnormalRel，在Info中显示所有“drb-ToReleaseList”下对应的eps-BearerIdentity，并记录ReleaseList下的eps-BearerIdentity个数。
ERABnum–释放个数,如果ERAB减完以后是0了，则状态迁移到RRC_Idle，否则状态不迁移。
二、或者在没有收到“DEACTIVATEEPSBEARERCONTEXTREQUEST”的NAS消息，也没有收到MME的“DETACHREQUEST”的NAS消息，也没有向网络侧主动发出“DETACHREQUEST”的NAS消息，收到了RRCConnectionrelease消息并且前4s如果有RLC层速率传输（上下行都需要考虑进来的，任何一个方向只要有数传即满足条件），生成一次ERABAbnormalRel，状态迁移到RRC_idle。
三、或者收到RRCConnectionReconfiguration消息中包含了信元“drb-ToAddModList”后，收到RRC释放信令之前，手机的RRCState=Idle，生成一次ERABAbnormalRel，释放次数增加所有“drb-ToAddModListt”下对应的eps-BearerIdentity个数，状态迁移到RRC_idle。
四、在没有收到RRCConnectionReconfiguration，DEACTIVATEEPSBEARERCONTEXTREQUEST，DETACHREQUEST，RRCState,RRCConnectionrelease消息时，收到RRC请求时将判断一个ERAB异常释放事件。
五、遇到RRCReestablishFail事件时同时输出ERAB异常释放事件，打点时间与RRCReestablishFail相同。
2.1.2.表现形式
通常路测时，使用PROBE软件+华为测试UE/华为数据卡观察（其它商用终端加相应的终端信令跟踪软件），以及路测计算机安装的流量监控软件，能看到如下信息：
●流量突然掉底或为0
在Ftp下载或上传（或者灌包）没有进行手动干预的情况下，此时吞吐率应该保持持续，若出现突然掉底，则有可能出现掉话。
图1路测吞吐率掉底
●UE开始接收系统消息
通常，UE在Detach/不活动定时器释放/切换至新小区/发生重建这些场景时会读取系统消息，但如果在业务正常进行过程中，在未涉及这些场景时突然接收系统消息时，则可以判定为掉话。
图2开始接收系统消息
2.1.3.获取方式
通过华为GenexProbe可获取华为测试UE及高通芯片数据卡log；
华为测试UE也可以通过OMT获取；
三星UE通过三星数据卡及XCal/Tems软件获取；
高通芯片TTI及跟踪可通过QXDM软件获取。
2.2.标口信令
在eNodeB跟踪到的标准接口信令中，如果存在eNodeB发起的释放，既在S1接口上发往CN的S1AP_UE_CONTEXT_REL_REQ消息内携带的原因值不为“User-inactivity”、“csfallbacktriggered”、“UENotAvailableForPSService”、“Inter-RATredirection”时，则判断为掉话。
2.2.1.掉话表现形式
异常掉话通常都是由ENB发起的释放，通知MME释放上下文，因此只要查看S1口发送的S1AP_UE_CONTEXT_REL_REQ消息即可，如下图所示为正常释放。
图3S1AP_UE_CONTEXT_REL_REQ
点击“标准接口消息类型”按消息类型进行排序，这样所有的S1AP_UE_CONTEXT_REL_REQ都会排列在一起，如下图所示。
图4按消息类型排序
依次点击下一条，查看中的原因值，找出信令内携带的原因值为异常释放原因值的进行分析。
如下图所示为一异常释放的话单记录。
图5找到异常掉话消息
根据对应的时间点，打开标准UU口的跟踪，找到对应时间点的RRC_CONN_REL消息，如下图所示。
图6找到对应的UU口消息
再查找对应时间点的IFTS跟踪，看是否跟踪到此次异常释放对应的IFTS跟踪。
图7找到对应的IFTS消息
打开IFTS跟踪，查找对应的时间点的跟踪是否可以和UU口、SI口对应上，如果无法对应，说明该IFTS跟踪的UE和当前掉话的UE不是同一个UE，则该IFTS跟踪就没有分析的必要。
如果可以找到IFTS跟踪的UE和当前掉话的UE是同一个UE，则把该S1/UU/IFTS跟踪发回来分析。
2.2.2.获取方式
在eRAN2.1版本之后，可以通过M2000采集Ifts数据，获取步骤简介如下：
Step1：
登录M2000服务器，选择监控->信令跟踪->信令跟踪管理
图8M2000信令跟踪管理
Step2：
在左侧菜单栏中双击“IFTS跟踪”
图9M2000IFTS跟踪
Step3：
点击“创建”，出现如下对话框，填写跟踪名称，并选定跟踪网元，点击下一步
图10M2000IFTS跟踪网元与时间设置
Step4：
图11M2000IFTS跟踪信息选择设置
1）小区ID：
按实际填写；
2）跟踪层：
L1需要勾选“L1上行链路特征信息”、“L1下行链路”；L2TTI需要勾选“L2性能算法特征信息”；
3）勾选”tracetype”中的“内部消息”（inner）和“文本消息”（text）；
4）MAC内部数据跟踪字段：
需要跟踪不同的模块时填写不同的数字，比如要跟踪“L2下行调度”
模块，在上面的空格中输入33，如果要跟踪多个模块，中间用“/”隔开。
目前支持的数据源和LAE解析类型参考发布的LAE配置文件对应的sheet：
“TLV类型”
常用IFTSL2MAC跟踪布控类型如下表所示：
表1常用的IFTSL2MAC跟踪布控类型
TYPE
TypeName
33
L2_DL_Schedule
40
L2_DL_Schedule_Performance
49
L2_UL_Schedule
55
L2_UL_Schedule_Performance
65
TA
66
RLF
67
MIMO
78
PUCCH_POWERCONTROL
81
PUSCH_POWERCONTROL
82
Semi_Persistent_PUSCH_PowerControl
83
OuterLoop_POWERCONTROL
97
DRX_Measure
98
DRX
102
CQI
130
RLC_Retran
131
RLC_Status_Report
132
TCP_DEBUG
135
PDCP_FLOWCTRL
136
PDCP_DRB
149
PDCP_Ping业务抓包
297
USER_INFO
224/160/43
BF
Step5：
点击“完成”，任务创建成功
图12IFTS跟踪运行中
Step6：
用户接入，可以跟踪到相关日志
Step7：
单击右键，选择“停止”可以停止跟踪
图13停止IFTS跟踪
Step8：
导出数据，点击“Export”，选择本地存放路径
图14IFTS跟踪数据导出
注意事项：
IFTS跟踪是跟踪第一个接入的用户，具体哪个用户是由IFTS跟踪界面打开后L3根据实际接入用户情况跟踪的。
需要先打开IFTS跟踪，再接入用户，才能跟踪到内容。
2.3.话统数据
2.3.1.掉话率指标话统公式
在话统侧异常掉话指标的公式定义如下：
CallDropRate=L.E-RAB.AbnormRel/（L.E-RAB.AbnormRel+L.E-RAB.NormRel）
其中：
L.E-RAB.AbnormRel：
小区异常释放用户E-RAB的总次数
L.E-RAB.NormRel：
小区正常释放用户E-RAB的总次数
而E-RAB是LTE网络中承载用户业务数据的接入层承载，E-RAB释放过程是用户接入层业务承载资源的释放过程，反映了小区为用户释放接入层业务数据承载资源的能力。
此类Counter在统计时以E-RAB的个数为单位，一个E-RAB的释放统计为一次。
故从该指标中可以知道，掉话率的指标统计是针对业务而非用户的，如果一个用户建立了多个DRB业务，则在分别掉话时，有可能会统计多次异常掉话值。
2.3.2.掉话Counter介绍
掉话相关Counter主要有45个，按释放类型可分为正常释放、异常释放、切换出正常释放、切换出异常释放；按照标准QCI等级，又进行从QCI1~QCI9的分类；按照异常释放原因，又可以分为：
无线、传输、拥塞、切换失败、MME共5类。
2.3.2.1.正常释放Counter
下表内所含为正常释放次数对应的Counter。
其中，由于存在扩展QCI，故L.E-RAB.NormRel（1526727547）的统计次数会大于等与QCI1~QCI9的总和。
表1小区E-RAB正常释放Counter
指标ID
测量指标
指标描述
单位
1526726687
L.E-RAB.NormRel.QCI.1
小区QCI为1的E-RAB正常释放次数
次
1526726689
L.E-RAB.NormRel.QCI.2
小区QCI为2的E-RAB正常释放次数
次
1526726691
L.E-RAB.NormRel.QCI.3
小区QCI为3的E-RAB正常释放次数
次
1526726693
L.E-RAB.NormRel.QCI.4
小区QCI为4的E-RAB正常释放次数
次
1526726695
L.E-RAB.NormRel.QCI.5
小区QCI为5的E-RAB正常释放次数
次
1526726697
L.E-RAB.NormRel.QCI.6
小区QCI为6的E-RAB正常释放次数
次
1526726699
L.E-RAB.NormRel.QCI.7
小区QCI为7的E-RAB正常释放次数
次
1526726701
L.E-RAB.NormRel.QCI.8
小区QCI为8的E-RAB正常释放次数
次
1526726703
L.E-RAB.NormRel.QCI.9
小区QCI为9的E-RAB正常释放次数
次
1526727547
L.E-RAB.NormRel
eNodeB正常释放用户E-RAB的总次数
次
如下图中A点所示，当eNodeB收到来自MME的E-RABRELEASECOMMAND消息时统计该指标，如果是MME主动发起的释放，根据不同QCI统计对应指标；如果是eNodeB主动发起的释放，当释放原因为“NormalRelease”，“Detach”，“UserInactivity”，“csfallbacktriggered”，“Inter-RATredirection”，“UENotAvailableForPSService”时，根据不同QCI统计对应指标。
如果E-RABRELEASECOMMAND消息中要求同时释放多个E-RAB，则相应指标按各个业务的QCI分别进行累加。
图15小区E-RAB正常释放打点_1
如下图中A点所示，当eNodeB收到来自MME的UECONTEXTRELEASECOMMAND消息，会释放UE的所有E-RAB。
如果是MME主动发起的释放，根据不同QCI统计对应指标；如果是eNodeB主动发起的释放，当释放原因为“NormalRelease”，“Detach”，“UserInactivity”，“csfallbacktriggered”，“Inter-RATredirection”，“UENotAvailableForPSService”时，相应指标按各个业务的QCI分别进行累加。
图16小区E-RAB正常释放打点_2
2.3.2.2.异常释放Counter
下表内所含为异常释放次数对应的Counter。
其中，由于存在扩展QCI，故L.E-RAB.AbnormRel（1526727546）的统计次数会大于等与QCI1~QCI9的总和。
表1小区E-RAB异常释放Counter
指标ID
测量指标
指标描述
单位
1526726686
L.E-RAB.AbnormRel.QCI.1
小区QCI为1的E-RAB异常释放次数
次
1526726688
L.E-RAB.AbnormRel.QCI.2
小区QCI为2的E-RAB异常释放次数
次
1526726690
L.E-RAB.AbnormRel.QCI.3
小区QCI为3的E-RAB异常释放次数
次
1526726692
L.E-RAB.AbnormRel.QCI.4
小区QCI为4的E-RAB异常释放次数
次
1526726694
L.E-RAB.AbnormRel.QCI.5
小区QCI为5的E-RAB异常释放次数
次
1526726696
L.E-RAB.AbnormRel.QCI.6
小区QCI为6的E-RAB异常释放次数
次
1526726698
L.E-RAB.AbnormRel.QCI.7
小区QCI为7的E-RAB异常释放次数
次
1526726700
L.E-RAB.AbnormRel.QCI.8
小区QCI为8的E-RAB异常释放次数
次
1526726702
L.E-RAB.AbnormRel.QCI.9
小区QCI为9的E-RAB异常释放次数
次
1526727546
L.E-RAB.AbnormRel
eNodeB异常释放用户E-RAB的总次数
次
如下图中A点所示，当eNodeB向MME发送E-RABRELEASEINDICATION消息，且释放原因不为“NormalRelease”，“UserInactivity”，“csfallbacktriggered”，“Inter-RATredirection”，“UENotAvailableForPSService”时统计该指标，并且在MME回复E-RABRELEASECOMMAND消息时，该指标不会被重复记录，如果E-RABRELEASEINDICATION消息中要求同时释放多个E-RAB，则相应指标按各个业务的QCI分别进行累加；
图17小区E-RAB异常释放打点_1
如下图中A点所示，当eNodeB向MME发送UECONTEXTRELEASEREQUEST消息，会释放UE的所有E-RAB。
当释放原因不为“NormalRelease”，“UserInactivity”，“csfallbacktriggered”，“Inter-RATredirection”，“UENotAvailableForPSService”时统计该指标，相应指标按各个业务的QCI分别进行累加。
并且在MME回复UECONTEXTRELEASECOMMAND消息时，该指标不会被重复记录。
图18小区E-RAB异常释放打点_2
2.3.2.3.切换出正常释放Counter
下表内所含为切换出正常释放次数对应的Counter。
其中，由于存在扩展QCI，故L.E-RAB.NormRel.HOOut（1526728246）的统计次数会大于等与QCI1~QCI9的总和。
表1小区切换出E-RAB正常释放Counter
指标ID
测量指标
指标描述
单位
1526727317
L.E-RAB.NormRel.HOOut.QCI.1
切换出QCI为1的E-RAB正常释放次数
次
1526727318
L.E-RAB.NormRel.HOOut.QCI.2
切换出QCI为2的E-RAB正常释放次数
次
1526727319
L.E-RAB.NormRel.HOOut.QCI.3
切换出QCI为3的E-RAB正常释放次数
次
1526727320
L.E-RAB.NormRel.HOOut.QCI.4
切换出QCI为4的E-RAB正常释放次数
次
1526727321
L.E-RAB.NormRel.HOOut.QCI.5
切换出QCI为5的E-RAB正常释放次数
次
1526727322
L.E-RAB.NormRel.HOOut.QCI.6
切换出QCI为6的E-RAB正常释放次数
次
1526727323
L.E-RAB.NormRel.HOOut.QCI.7
切换出QCI为7的E-RAB正常释放次数
次
1526727324
L.E-RAB.NormRel.HOOut.QCI.8
切换出QCI为8的E-RAB正常释放次数
次
1526727325
L.E-RAB.NormRel.HOOut.QCI.9
切换出QCI为9的E-RAB正常释放次数
次
1526728246
L.E-RAB.NormRel.HOOut
切换出E-RAB正常释放总次数
次
如下图所示，从左到右依次为eNodeB内切换、X2接口切换及S1接口切换。
而图中C点所示为切换执行成功，对于目标小区已经成功建立的E-RAB，源小区正常释放对应的E-RAB，此时的释放原因可能为：
“successfulhandover”，则在源小区按各个业务的QCI分别统计该指标。
图19小区切换出E-RAB正常释放打点
2.3.2.4.切换出异常释放Counter
下表内所含为切换出异常释放次数对应的Counter。
其中，由于存在扩展QCI，故L.E-RAB.AbnormRel.HOOut（1526728247）的统计次数会大于等与QCI1~QCI9的总和。
表1小区切换出E-RAB异常释放Counter
指标ID
测量指标
指标描述
单位
1526727326
L.E-RAB.AbnormRel.HOOut.QCI.1
切换出QCI为1的E-RAB异常释放次数
次
1526727327
L.E-RAB.AbnormRel.HOOut.QCI.2
切换出QCI为2的E-RAB异常释放次数
次
1526727328
L.E-RAB.AbnormRel.HOOut.QCI.3
切换出QCI为3的E-RAB异常释放次数
次
1526727329
L.E-RAB.AbnormRel.HOOut.QCI.4
切换出QCI为4的E-RAB异常释放次数
次
1526727330
L.E-RAB.AbnormRel.HOOut.QCI.5
切换出QCI为5的E-RAB异常释放次数
次
1526727331
L.E-RAB.AbnormRel.HOOut.QCI.6
切换出QCI为6的E-RAB异常释放次数
次
1526727332
L.E-RAB.AbnormRel.HOOut.QCI.7
切换出QCI为7的E-RAB异常释放次数
次
1526727333
L.E-RAB.AbnormRel.HOOut.QCI.8
切换出QCI为8的E-RAB异常释放次数
次
1526727334
L.E-RAB.AbnormRel.HOOut.QCI.9
切换出QCI为9的E-RAB异常释放次数
次
1526728247
L.E-RAB.AbnormRel.HOOut
切换出E-RAB异常释放总次数
次
如下图所示，从左到右依次为eNodeB内切换、X2接口切换及S1接口切换。
图中C点所示为切换执行成功，但目标小区有建立失败的E-RAB，源小区异常释放对应的E-RAB，此时的释放原因可能为：
“PartialHandover”等，则在源小区按各个业务的QCI分别统计该指标。
图20小区切换出E-RAB异常释放打点
2.3.2
升级会员 