目录

1 概述
2 掉话分类定义
2.1. 路测数据
2.1.1. 掉话定义
2.1.2. 表现形式
2.1.3. 获取方式
2.2. 标口信令
2.2.1. 掉话表现形式
2.2.2. 获取方式
2.3. 话统数据
2.3.1. 掉话率指标话统公式
2.3.2. 掉话Counter介绍
2.3.3. 获取方式
2.4. CHR数据
2.4.1. 获取方式

2.4.2. 呈现方式



1 概述

本《LTE掉话优化指导书》重点介绍了LTE系统内掉话率指标的优化思路、分析方法、定位手段及典型案例；

本《指导书》结构如下：

第一部分 主要从路测、标准接口、话统、CHR多角度出发给出了掉话的定义；

第二部分 给出了常见的掉话原因，掉话机制的介绍；

第三部分 介绍了掉话问题的隔离定位分析方法；

第四部分 分享了掉话优化的典型案例；

第五部分 介绍了CHR数据的分析方法，影响掉话的定时器介绍及重建的机制介绍。


2 掉话分类定义

掉话是指在UE在与eNB间成功建立eRAB之后，由于异常原因导致的eRAB释放，本章将分别从路测数据、标准接口信令、话统数据及CHR数据4个方面介绍一下掉话的表现。


2.1. 路测数据


2.1.1. 掉话定义

在华为Probe&Assistant侧对于掉话（eRab Abnormal Release）的定义如下：

一、没有收到“DEACTIVATE EPS BEARER CONTEXT REQUEST”的NAS消息，也没有收到MME的“DETACH REQUEST”的NAS消息，也没有向网络侧主动发出“DETACH REQUEST”的NAS消息，收到了RRCConnectionReconfiguration消息，且其中有信元“drb-ToReleaseList”，则生成一次ERABAbnormalRel，在Info中显示所有“drb-ToReleaseList”下对应的eps-BearerIdentity，并记录ReleaseList下的eps-BearerIdentity个数。ERAB num –释放个数, 如果ERAB减完以后是0了，则状态迁移到RRC_Idle，否则状态不迁移。

二、或者在没有收到“DEACTIVATE EPS BEARER CONTEXT REQUEST”的NAS消息，也没有收到MME的“DETACH REQUEST”的NAS消息，也没有向网络侧主动发出“DETACH REQUEST”的NAS消息，收到了RRCConnection release消息并且前4s如果有RLC层速率传输(上下行都需要考虑进来的，任何一个方向只要有数传即满足条件)，生成一次ERABAbnormalRel，状态迁移到RRC_idle。

三、或者收到RRC Connection Reconfiguration消息中包含了信元“drb-ToAddModList”后，收到RRC释放信令之前，手机的RRCState=Idle，生成一次ERABAbnormalRel，释放次数增加所有“drb-ToAddModListt”下对应的eps-BearerIdentity个数，状态迁移到RRC_idle。

四、在没有收到RRC Connection Reconfiguration，DEACTIVATE EPS BEARER CONTEXT REQUEST，DETACH REQUEST，RRC State, RRCConnection release消息时，收到RRC请求时将判断一个ERAB异常释放事件。

五、遇到RRCReestablishFail事件时同时输出ERAB异常释放事件，打点时间与RRCReestablishFail相同。


2.1.2. 表现形式

通常路测时，使用PROBE软件+华为测试UE/华为数据卡观察（其它商用终端加相应的终端信令跟踪软件），以及路测计算机安装的流量监控软件，能看到如下信息：

1）流量突然掉底或为0

在Ftp下载或上传（或者灌包）没有进行手动干预的情况下，此时吞吐率应该保持持续，若出现突然掉底，则有可能出现掉话。


图1 路测吞吐率掉底

2） UE开始接收系统消息

通常，UE在Detach/不活动定时器释放/切换至新小区/发生重建这些场景时会读取系统消息，但如果在业务正常进行过程中，在未涉及这些场景时突然接收系统消息时，则可以判定为掉话。


图2 开始接收系统消息


2.1.3. 获取方式

通过华为Genex Probe可获取华为测试UE及高通芯片数据卡log；

华为测试UE也可以通过OMT获取；

三星UE通过三星数据卡及XCal/Tems软件获取；

高通芯片TTI及跟踪可通过QXDM软件获取。


2.2. 标口信令

在eNodeB跟踪到的标准接口信令中，如果存在eNodeB发起的释放，既在S1接口上发往CN的S1AP_UE_CONTEXT_REL_REQ消息内携带的原因值不为“User-inactivity”、“cs fallback triggered”、“UE Not Available For PS Service”、“Inter-RAT redirection”时，则判断为掉话。
2.2.1. 掉话表现形式

异常掉话通常都是由ENB发起的释放，通知MME释放上下文，因此只要查看S1口发送的S1AP_UE_CONTEXT_REL_REQ消息即可，如下图所示为正常释放。


图3 S1AP_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服务器，选择 监控->信令跟踪->信令跟踪管理


图8 M2000信令跟踪管理

Step2：在左侧菜单栏中双击“IFTS跟踪”


图9 M2000IFTS跟踪

Step3：点击“创建”，出现如下对话框，填写跟踪名称，并选定跟踪网元，点击下一步


图10 M2000 IFTS跟踪网元与时间设置

Step4：


图11 M2000 IFTS跟踪信息选择设置

1）小区ID：按实际填写；

2）跟踪层：L1需要勾选“L1上行链路特征信息”、“L1下行链路”；L2 TTI需要勾选“L2性能算法特征信息”；

3）勾选”trace type”中的“内部消息”(inner)和“文本消息”(text)；

4）MAC内部数据跟踪字段：需要跟踪不同的模块时填写不同的数字，比如要跟踪“L2下行调度”

模块，在上面的空格中输入33，如果要跟踪多个模块，中间用“/”隔开。

目前支持的数据源和LAE解析类型参考发布的LAE配置文件对应的sheet：“TLV类型”

常用IFTS L2 MAC跟踪布控类型如下表所示：


Step5：点击“完成”，任务创建成功


图12 IFTS跟踪运行中

Step6：用户接入，可以跟踪到相关日志

Step7：单击右键，选择“停止”可以停止跟踪


图13 停止IFTS跟踪

Step8：导出数据，点击“Export”，选择本地存放路径


图14 IFTS跟踪数据导出

注意事项：IFTS跟踪是跟踪第一个接入的用户，具体哪个用户是由IFTS跟踪界面打开后L3根据实际接入用户情况跟踪的。

需要先打开IFTS跟踪，再接入用户，才能跟踪到内容。

2.3. 话统数据
2.3.1. 掉话率指标话统公式

在话统侧异常掉话指标的公式定义如下：

Call Drop Rate = 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的总和。


如下图中A点所示，当eNodeB收到来自MME的E-RAB RELEASE COMMAND消息时统计该指标，如果是MME主动发起的释放，根据不同QCI统计对应指标；如果是eNodeB主动发起的释放，当释放原因为“Normal Release”，“Detach”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection”，“UE Not Available For PS Service”时，根据不同QCI统计对应指标。如果E-RAB RELEASE COMMAND消息中要求同时释放多个E-RAB，则相应指标按各个业务的QCI分别进行累加。


图15 小区E-RAB正常释放打点_1

如下图中A点所示，当eNodeB收到来自MME的UE CONTEXT RELEASE COMMAND消息，会释放UE的所有E-RAB。如果是MME主动发起的释放，根据不同QCI统计对应指标；如果是eNodeB主动发起的释放，当释放原因为“Normal Release”，“Detach”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection” ，“UE Not Available For PS Service”时，相应指标按各个业务的QCI分别进行累加。


图16 小区E-RAB正常释放打点_2


2.3.2.2. 异常释放Counter

下表内所含为异常释放次数对应的Counter。其中，由于存在扩展QCI，故L.E-RAB.AbnormRel（1526727546）的统计次数会大于等与QCI1~QCI9的总和。


如下图中A点所示，当eNodeB向MME发送E-RAB RELEASE INDICATION消息，且释放原因不为“Normal Release”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection” ，“UE Not Available For PS Service”时统计该指标，并且在MME回复E-RAB RELEASE COMMAND消息时，该指标不会被重复记录，如果E-RAB RELEASE INDICATION消息中要求同时释放多个E-RAB，则相应指标按各个业务的QCI分别进行累加；


图17 小区E-RAB异常释放打点_1

如下图中A点所示，当eNodeB向MME发送UE CONTEXT RELEASE REQUEST消息，会释放UE的所有E-RAB。当释放原因不为“Normal Release”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection” ，“UE Not Available For PS Service”时统计该指标，相应指标按各个业务的QCI分别进行累加。并且在MME回复UE CONTEXT RELEASE COMMAND消息时，该指标不会被重复记录。


图18 小区E-RAB异常释放打点_2


2.3.2.3. 切换出正常释放Counter

下表内所含为切换出正常释放次数对应的Counter。其中，由于存在扩展QCI，故L.E-RAB.NormRel.HOOut（1526728246）的统计次数会大于等与QCI1~QCI9的总和。


如下图所示，从左到右依次为eNodeB内切换、X2接口切换及S1接口切换。而图中C点所示为切换执行成功，对于目标小区已经成功建立的E-RAB，源小区正常释放对应的E-RAB，此时的释放原因可能为：“successful handover”，则在源小区按各个业务的QCI分别统计该指标。

图19 小区切换出E-RAB正常释放打点


2.3.2.4. 切换出异常释放Counter

下表内所含为切换出异常释放次数对应的Counter。其中，由于存在扩展QCI，故L.E-RAB.AbnormRel.HOOut（1526728247）的统计次数会大于等与QCI1~QCI9的总和。


如下图所示，从左到右依次为eNodeB内切换、X2接口切换及S1接口切换。图中C点所示为切换执行成功，但目标小区有建立失败的E-RAB，源小区异常释放对应的E-RAB，此时的释放原因可能为：“Partial Handover”等，则在源小区按各个业务的QCI分别统计该指标。
图20 小区切换出E-RAB异常释放打点


2.3.2.5. 异常释放原因Counter

下表内所含为异常释放原因分类对应的Counter。

如下图中A点所示，MME主动发起E-RAB释放流程，当eNodeB收到来自MME的E-RAB RELEASE COMMAND消息时，且释放原因不为“Normal Release”，“Detach”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection” ，“UE Not Available For PS Service”则统计L.E-RAB.AbnormRel.MME指标。如果E-RAB RELEASE COMMAND消息中要求同时释放多个E-RAB，则指标L.E-RAB.AbnormRel.MME按具体业务数目进行累加；


图21 小区E-RAB异常释放原因打点_1

如下图中A点所示，MME主动发起UE CONTEXT释放流程，当eNodeB收到来自MME的UE CONTEXT RELEASE COMMAND消息时，会释放UE的所有E-RAB。当释放原因不为“Normal Release”，“Detach”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection” ，“UE Not Available For PS Service”时，统计L.E-RAB.AbnormRel.MME指标，指标L.E-RAB.AbnormRel.MME按具体业务数目进行累加；


图22 小区E-RAB异常释放原因打点_2

如下图中A点所示，当eNodeB向MME发送E-RAB RELEASE INDICATION消息，当释放原因为无线层错误时，统计L.E-RAB.AbnormRel.Radio指标，无线层错误描述请参考3GPP TS36.413协议定义；当释放原因为传输层错误时，统计L.E-RAB.AbnormRel.TNL指标，传输层错误描述请参考3GPP TS36.413协议定义；当释放原因为网络拥塞时，统计L.E-RAB.AbnormRel.Cong指标。如果E-RAB RELEASE INDICATION消息中要求同时释放多个E-RAB，则相应指标根据具体业务数目按上述原因分别进行累加；


图23 小区E-RAB异常释放原因打点_3

如下图中A点所示，当eNodeB向MME发送UE CONTEXT RELEASE REQUEST消息，会释放UE的所有E-RAB。当释放原因为无线层错误时，统计L.E-RAB.AbnormRel.Radio指标，无线层错误描述请参考3GPP TS36.413协议定义；当释放原因为传输层错误时，统计L.E-RAB.AbnormRel.TNL指标，传输层错误描述请参考3GPP TS36.413协议定义；当释放原因为网络拥塞时，统计L.E-RAB.AbnormRel.Cong指标，本指标统计包括因抢占和资源拥塞导致的异常释放；当释放原因为切换失败时，统计L.E-RAB.AbnormRel.HOFailure指标。相应指标根据具体业务数目按上述原因分别进行累加。并且在MME回复UE CONTEXT RELEASE COMMAND消息时，该指标不会被重复记录。


图24 小区E-RAB异常释放原因打点_4
2.3.3. 获取方式

通常为方便数据发送及后处理，话统数据可通过M2000进行获取导出，格式一般为Excel，相关格式如下图所示


图25 话统文件格式

也可以通过PRS/OMStar软件直接处理M2000服务器上的原始话统数据。


2.4. CHR数据

CHR侧掉话定义与话统侧相一致，只是CHR侧会依据相对应异常释放话单内部流程的错误原因将掉话原因进行细分，并依据L3内部的实现输出内部失败原因值，便于工程师将掉话原因进行分类。
2.4.1. 获取方式
2.4.1.1. 直接获取CHR日志

通过web LMT或M2000直接获取

Step1：在web LMT或M2000上输入LST LOGFILE: LT=CHRLOG; 查询当前CHR日志文件列表；


图 LST LOGFILE执行结果

Step2：在web LMT或M2000上输入ULD NEFILE（V100R003C00及以后版本），然后选择日志类型为CHR，输入需要保存的目标文件的名称（通常命名规则为NE Name+获取日期），并输入FTP服务器IP、用户名、密码 FTP服务器信息请向机房管理人员或者维护工程师索取），可以上传对应的CHR日志至FTP服务器。


图 Log 上传到服务器

这种采集日志的方法只能挨个导出单个站点的日志。
2.4.1.2. 通过一键式日志获取

从主控板所在槽位上导出的一键式日志，其中既包含了Debug日志、Sig日志及CHR日志等。导出一键式日志可通过在WebLMT或者M2000上执行MML命令“ULD NEFILE”完成，其中单板所在的框号、槽号需要与主控板所在位置对应。


图26 一键式日志获取


2.4.1.3. 使用LogUnpack.exe解包日志

将上传后的CHR数据（2.1版本）或一键式日志使用Log Unpack工具解压，就能提取出CHR日志可供分析。如下图所示：


图27 日志解包


2.4.2. 呈现方式

CHR数据可通过华为开发的InsightSharp软件进行解析，相关操作界面如下图所示


图28 InsightSharp界面