《LTE_TDD问题定位指导书-掉话篇-华为》由会员分享，可在线阅读，更多相关《LTE_TDD问题定位指导书-掉话篇-华为（88页珍藏版）》请在金锄头文库上搜索。
1、LTE TDD问题定位指导书-掉话篇内部公开confidentiality level产品名称Product name密级Confidentiality levelLTE TDD内部公开产品版本Product versionTotal 91pages 共91页eRAN2.2/ eRAN3.0/ eRAN 3.1LTE TDD问题定位指导书-掉话篇(仅供内部使用）For internal use only拟制:Prepared by谢石生、许钢煌日期：Date2013-03-15审核:Reviewed by日期：Dateyyyy-mm-dd审核:Reviewed by日期：Dateyyyy-mm
2、-dd批准:Granted by日期：Dateyyyy-mm-ddKoukou:277764781 华为技术有限公司Huawei Technologies Co., Ltd.版权所有 侵权必究All rights reserved修订记录Revision record日期Date修订版本Revision version修改描述 Change Description作者Author2010-9-140.5初稿完成 initial transmittal 何勇镇，杨东利2010-11-180.6新增案例，补充分析内容何勇镇2010-12-10.7补充瑞典分析结果，RLC达到最大重传次数、失步何勇镇
3、，杨东利2010-12-80.8依据评审意见修改何勇镇2011-6-80.9补充日本软银掉话案例等王光华2012-1-201.0根据eRAN3.0修改文中涉及的相关参数和MML命令谢石生2012-10-251.1资料整改,中文资料必须中文截图，添加“本文中的所提到的M2000在中国区等同于DOMC920”字样吴丽婷2013-3-153.0刷新部分信息，补充License受限掉话案例，与其它指导书匹配版本号许钢煌目录1免责说明72概述73掉话分类定义73.1.路测数据73.1.1.路测数据掉话定义73.1.2.获取方式83.2.标口信令83.2.1.掉话预检查方式83.2.2.获取方式103.3
4、.话统数据113.3.1.掉话率指标话统公式113.3.2.异常释放统计113.3.3.正常释放统计143.3.4.获取方式153.4.CHR163.4.1.CHR数据源采集方法163.4.2.呈现方式314掉话原因分析314.1.常见掉话原因314.1.1.邻区错/漏配314.1.2.弱覆盖324.1.3.切换导致的掉话334.1.4.干扰引起的掉话344.1.5.流程交互失败354.1.6.异常分析354.2.话统中掉话率相关Counter364.3.CHR内掉话原因分类364.3.1.CHR内常见异常释放原因介绍374.4.信令流程中释放原因分类454.4.1.协议中释放原因定义455优
5、化方法475.1.掉话率指标分析流程475.1.1.全网话统指标分析流程475.1.2.Top小区分析流程506优化案例596.1.挪威掉话率指标优化596.1.1.【问题描述】596.1.2.【问题分析】606.1.3.【解决措施】656.2.瑞典掉话率指标优化666.2.1.【问题描述】666.2.2.【问题分析】666.2.3.【解决措施】756.3.日本软银PDCCH解调受限导致掉话756.3.1.【问题描述】756.3.2.【问题分析】756.3.3.【解决措施】826.4.基站License受限导致忙时小区掉话率升高826.4.1.【问题描述】836.4.2.【问题分析】836.4
6、.3.【解决措施】867附录867.1.UE不活动定时器的工作机制867.2.UE重建工作机制877.2.1.上行RLC重传达到最大次数887.2.2.MAC层SRI重传达到最大次数887.2.3.时延谱首径搜索失败88图目录List of Figures图1 S1AP_UE_CONTEXT_REL_REQ9图2 按消息类型排序9图3 找到异常掉话消息10图4 找到对应的UU口消息11图5 找到对应的IFTS消息11图6 异常释放测量点113图7 异常释放测量点213图8 异常释放测量点314图9 异常释放测量点414图10 正常释放测量点115图11 正常释放测量点216图12 话统文件格式
7、16图13 InsightSharp界面32图14 M2000告警浏览界面37图15 收到对端的状态PDU的负确认40图16 下行数据发送失败40图17 上行数据发送失败40图18 DETACH简化流程图42图19 LCEM_UEM_UNRESTORED_IND消息内容43图20 L3_PDCP_DATA_Req消息内容44图21 eNB检测到上行失步，且有下行数据要发送45图22 eNB检测到上行失步，没有下行数据要发送46图23 DMAC_L3_SYNC_STATUS_IND消息内容47图24 UU口完整重建流程信令48图25 话统指标分析流程图51图26 eNodeB软件版本查询结果51
8、图27 Top小区分析流程图53图28 CHR数据导出的TMSI信息55图29 INITIAL_UE_MSG消息内容56图30 CHR显示字段57图31 DSP MMCTX操作界面58图32 LST SIMEI操作界面59图33 RF优化流程图60图34 掉话log隔离定位思维导图62图35 挪威掉话率趋势63图36 挪威掉话Top站点分布64图37 挪威掉话Top切换分析_164图38 挪威掉话Top切换分析_265图39 挪威掉话Top切换分析_365图40 标口信令分析_166图41 标口信令分析_266图42 OSL119 CHR数据68图43 OSL119 话统数据68图44 Top
9、站点掉话比例分布70图45 某站点话统数据70图46 Top用户分析71图47 话统数据分析72图48 Top用户分析73图49 调度结果分析74图50 UU口信令分析75图51 eNodeB达到最大重传次数75图52 eNodeB检测到上行失步76图53 L3释放消息76图54 L1 TTI跟踪解析77图55 Harq重传超过门限上报测量报告79图56 eNB检测到失步上报失步指示80图57 PROBE跟踪下行误码率统计80图58 服务小区及相邻小区RSRP81图59 服务小区SINR82图60 下行信道时延谱83图61 eNB上行TA分析83图62 加大搜索窗后eNB上行TA分析85图63
10、 不活动定时器超时释放消息94表目录 List of Tables表1 异常释放测量指标12表2 正常释放测量指标14表3 链路预算结果34表4 V100R002C00 CHR主要释放原因列表38表5 信令流程中释放原因值列表48表6 部分掉话率相关参数51表7 CHR释放原因与实际掉话原因关系54表8 Top小区CHR释放原因65表9 Top小区CHR释放原因69表10 T314008 CHR释放原因统计70表11 T314025 CHR释放原因统计72表12 T314025 CHR释放原因统计742013-04-1024华为机密，未经许可不得扩散第88页,共88页Page 88 , Tot
11、al881 免责说明该指导书在提供服务或维护过程中，可能涉及个人数据的使用，如设备的IP地址等信息，因此您需遵循所适用国家的法律或公司用户隐私政策采取足够的措施，以确保用户的个人数据受到充分的保护。建议您遵从国家的相关法律执行该任务，并采取足够的措施以确保用户的个人数据受到充分保护，处理完毕后将保存跟踪记录文件进行删除。2 概述本文中的所提到的M2000在中国区等同于DOMC920本文重点介绍了LTE系统内掉话率指标的优化思路、分析方法、定位手段及典型案例；本文结构如下：第3章主要从路测、标准接口、话统、CHR多角度出发给出了掉话的定义；第4章给出了常见的掉话原因，掉话机制的介绍；第5章介绍了
12、掉话问题的优化方法；第6章展示了掉话优化的典型案例；第7章附录介绍了UE不活动定时器及重建机制。3 掉话分类定义3.1. 路测数据3.1.1. 路测数据掉话定义在华为Probe侧对于掉话（ERAB Abnormal Release）的定义：UE没有收到Deactivate Eps Bearer Context Request消息，但收到RRC Release或RRC Connection Reconfiguration消息，则表示ERAB异常释放。三星UE定义方式待补充。高通平台华为数据卡定义方式待补充。3.1.2. 获取方式通过华为Genex Probe及华为UE获取。三星UE通过三星数据卡
13、及XCal软件获取。高通平台华为数据卡获通过高通QXDM工具获取。3.2. 标口信令在eNodeB跟踪到的标准接口信令中，如果存在eNodeB发起的释放，即在S1接口上发往CN的S1AP_UE_CONTEXT_REL_REQ消息内携带的原因值不为“User-inactivity (20)”时，则判断为掉话。3.2.1. 掉话预检查方式异常掉话通常都是由eNB发起的释放，通知MME释放上下文，因此只要查看S1口发送的S1AP_UE_CONTEXT_REL_REQ消息即可，如下图所示。图1 S1AP_UE_CONTEXT_REL_REQ点击“标准接口消息类型”按消息类型进行排序，这样所有的S1AP
14、_UE_CONTEXT_REL_REQ都会排列在一起，如下图所示。图2 按消息类型排序依次点击下一条，查看中的原因值，找出最后的原因为非 02 80 的原因值。图3 找到异常掉话消息根据对应的时间点，打开标准UU口的跟踪，找到对应时间点的RRC_CONN_REL消息，如下图所示。图4 找到对应的UU口消息再查找对应时间点的IFTS跟踪，看是否跟踪到该异常释放UE的IFTS跟踪。图5 找到对应的IFTS消息打开IFTS跟踪，查找对应的时间点的跟踪是否可以和UU口、SI口对应上，如果无法对应，说明该IFTS跟踪的UE和当前掉话的UE不是同一个UE，则该IFTS跟踪就没有分析的必要。如果可以找到IFTS跟
