当前位置:首页 >> 计算机硬件及网络 >>

TDD掉话问题处理指导以及案例集 -


文档名称

文档密级

TDD掉话问题处理指导以及经典案例集

拟 审 批

制: 核: 准:

杨金华/00290376 GTAC GCT性能团队

日 期: 日 期: 日 期:

2016-05-11 2016-05-11

华为技术有限公司 2016年05月11日

2017-2-21

华为保密信息,未经授权禁止扩散

第 1 页, 共 119 页

文档名称

文档密级

修订记录
日期 2016-05-11 2016-05-11 修订版本 1.0.0 1.0.1 描述 初稿完成 initial transmittal 内部审核通过 作者 杨金华/00290376 GTAC GCT性能团队

2017-2-21

华为保密信息,未经授权禁止扩散

第 2 页, 共 119 页

文档名称

文档密级

目录 1 掉话定义… ............................................................................................................... 4
1.1 话统 KPI… .............................................................................................................................. 4
1.1.1 掉话率指标话统公式… ......................................................................................................................... 4 1.1.2 异常释放统计… .................................................................................................................................... 8 1.1.3 正常释放统计… .................................................................................................................................. 16 1.1.4 指标包含关系… .................................................................................................................................. 18

1.2 路测 KPI… ............................................................................................................................ 19
1.2.1 华为 probe 路测掉话统计… ................................................................................................................ 19 1.2.2 其他厂家路测掉话统计… .................................................................................................................. 20 1.2.3 路测和后台统计区别… ...................................................................................................................... 20

1.3 标口信令…............................................................................................................................ 21
1.3.1 掉话预检查方式… ............................................................................................................................... 21 1.3.2 获取方式… .......................................................................................................................................... 24

1.4 CHR 数据… ........................................................................................................................... 24
1.4.1 掉话预检查方式… ............................................................................................................................... 24 1.4.2 获取方式… .......................................................................................................................................... 26

2 掉话机制… ............................................................................................................. 27
2.1 L2 掉话机制… ....................................................................................................................... 28 2.2 L3 掉话机制… ....................................................................................................................... 33 2.3 其他掉话机制…..................................................................................................................... 33

3 主要掉话原因分析和优化… ................................................................................. 33
3.1 常见掉话原因….................................................................................................................... 33
3.1.1 邻区漏配… ........................................................................................................................................... 34 3.1.2 弱覆盖… .............................................................................................................................................. 35 3.1.3 切换导致掉话… .................................................................................................................................. 37 3.1.4 干扰引起掉话… .................................................................................................................................. 40 3.1.5 流程交互失败… .................................................................................................................................. 44 3.1.6 其他异常分析… .................................................................................................................................. 45

3.2 常见掉话场景及日志分析…............................................................................................... 46

4 经典案例集… ........................................................................................................ 52

2017-2-21

华为保密信息,未经授权禁止扩散

第 3 页, 共 119 页

文档名称

文档密级

1 掉话定义
1.1 话统 KPI

1.1.1 掉话率指标话统公式

数据业务掉话KPI
华为数据业务掉话率的推荐公式如下: Call Drop Rate = L.E-RAB.AbnormRel / (L.E-RAB.AbnormRel + L.E-RAB.NormRel) 等同于: Call Drop Rate = L.E-RAB.AbnormRel.QCI.N / (L.E-RAB.AbnormRel.QCI.N L.E-RAB.NormRel.QCI.N) 其中: 分子上表征异常释放的Counter为L.E-RAB.AbnormRel.QCI.N= L.E-RAB.AbnormRel.QCI.1+L.E-RAB.AbnormRel.QCI.2+ L.E-RAB.AbnormRel.QCI.3+L.E-RAB.AbnormRel.QCI.4+ L.E-RAB.AbnormRel.QCI.5+ L.E-RAB.AbnormRel.QCI.6+ L.E-RAB.AbnormRel.QCI.7+ L.E-RAB.AbnormRel.QCI.8+ L.E-RAB.AbnormRel.QCI.9; 而分母上是正常释放与异常释放的总和,正常释放的Counter为 L.E-RAB.NormRel.QCI.N= L.E-RAB.NormRel.QCI.1+L.E-RAB.NormRel.QCI.2+ L.E-RAB.NormRel.QCI.3+L.E-RAB.NormRel.QCI.4+ L.E-RAB.NormRel.QCI.5+ L.E-RAB.NormRel.QCI.6+ L.E-RAB.NormRel.QCI.7+ L.E-RAB.NormRel.QCI.8+ L.E-RAB.NormRel.QCI.9; 从该指标中可以知道, 掉话率的指标统计是针对业务承载而非用户的, 如果一个用户建 立了多个DRB业务承载,则在掉话时,会统计多次异常掉话值。 +

由于中国移动集团有自己的KPI定义,中国移动的掉话率定义公式如下,其中无线掉线 率(本地网)为日常考核使用公式。 无线掉线率 (本地网) =∑ (eNB请求释放上下文数-正常的eNB请求释放上下文数) /∑(初
2017-2-21 华为保密信息,未经授权禁止扩散 第 4 页, 共 119 页

文档名称

文档密级

始上下文建立成功次数+遗留上下文个数)*100% , 其中∑代表将本地网范围内的各个小区 的统计结果累加。 无线掉线率(小区级) =(eNB请求释放上下文数-正常的eNB请求释放上下文数)/(初 始上下文建立成功次数+遗留上下文个数+切换入成功次数+RRC连接重建成功次数(非源侧小 区))*100% E-RAB掉线率(本地网)=∑( eNB请求释放的E-RAB数 -正常的eNB请求释放的E-RAB数 + 切出失败的E-RAB数 )/∑(E-RAB建立成功数+遗留E-RAB个数)*100%, 其中∑代表将本地网 范围内的各个小区的统计结果累加 E-RAB掉线率(小区级)= (切出失败的E-RAB数 +eNB请求释放的E-RAB个数 -正常的eNB 请求释放的E-RAB数)/( 遗留E-RAB个数 +E-RAB建立成功数 +切换入E-RAB数 )*100%

映射成华为的指标,对应如下: 无线掉线率(本地网)= ( L.UECNTX.Rel.S1Reset.eNodeB[1526728838]-L.UECNTX.Rel.eNodeB.InitAttEst.MMENoR eply[1526737847] + L.UECNTX.AbnormRel[1526728227])) /(L.UECNTX.SuccEst[1526728851]+L.UECNTX.Left[1526730538])*100% = ( eNodeB发起的 S1 RESET导致的UE Context释放次数[1526728838]-eNodeB等待初始上下文建立请求超时触 发的UE Context释放次数[1526737847] + UE Context异常释放次数[1526728227])/(UE Context建立成功总次数[1526728851]+小区遗留UE Context个数[1526730538]) *100% 无线掉线率(小区级) = (L.UECNTX.Rel.eNodeB[1526728856]+L.UECNTX.Rel.S1Reset.eNodeB[1526728838]-L.UECN TX.Rel.eNodeB.InitAttEst.MMENoReply[1526737847]+L.UECNTX.Rel.eNodeB[1526728856] L.UECNTX.AbnormRel[1526728227])/(L.UECNTX.SuccEst[1526728851]+L.UECNTX.Left[152 6730538]+L.HHO.IntraeNB.ExecSuccIn[1526727255] +L.HHO.IntereNB.ExecSuccIn[1526727258]-L.HHO.IntraeNB.ExecSuccIn.ReEst2Tgt[1526 730548]-L.HHO.IntereNB.ExecSuccIn.ReEst2Tgt[1526730550]+L.RRC.ReEst.NonSrccell. Att[1526730536]) = (eNodeB发起的UE Context释放次数[1526728856]+eNodeB发起的S1 RESET导致的UE Context释放次数[1526728838]-eNodeB等待初始上下文建立请求超时触发
2017-2-21 华为保密信息,未经授权禁止扩散 第 5 页, 共 119 页

文档名称

文档密级

的UE Context释放次数[1526737847]+eNodeBB发起的UE Context释放次数[1526728856] - UE Context异常释放次数[1526728227])/(UE Context建立成功总次数[1526728851]+小区遗留 UE Context个数[1526730538]+小区eNodeB内模式内切换入成功次数[1526727255] +小区 eNodeB间模式内切换入成功次数[1526727258]-通过重建到目标小区的eNodeB内模式内切换 入成功次数[1526730548]-通过重建到目标小区的eNodeB间模式内切换入成功次数 [1526730550]+非源小区RRC重建请求次数[1526730536]) E-RAB掉线率(本地网)= (L.E-RAB.AbnormRel.eNBTot[1526728319]+L.E-RAB.AbnormRel.HOOut[1526728247])/(L.E -RAB.SuccEst[1526727544]+L.E-RAB.Left[1526728817]) )*100% = (eNodeB触发的E-RAB 异常释放总次数[1526728319]+小区切换出E-RAB异常释放总次数[1526728247])/(E-RAB建 立成功总次数[1526727544]+遗留E-RAB总个数[1526728817])*100% E-RAB掉线率(小区级)= (L.E-RAB.AbnormRel.eNBTot[1526728319]+L.E-RAB.AbnormRel.HOOut[1526728247])/(L.E -RAB.SuccEst[1526727544]+L.E-RAB.Left[1526728817]+L.E-RAB.SuccEst.HOIn[15267282 45]) = (eNodeB触发的E-RAB异常释放总次数[1526728319]+小区切换出E-RAB异常释放总 次数[1526728247])/(E-RAB建立成功总次数[1526727544]+遗留E-RAB总个数[1526728817]+ 小区切换入E-RAB成功建立总次数[1526728245])

Volte业务掉话KPI
Volte相关掉话率公式均为E-RAB承载级,语音业务使用QCI1,视频业务使用QCI2,华为 推荐公式如下: QCI1掉话率 = L.E-RAB.AbnormRel.QCI.1 / (L.E-RAB.AbnormRel.QCI.1+L.E-RAB.NormRel.QCI.1) QCI2掉话率 = L.E-RAB.AbnormRel.QCI.2 / (L.E-RAB.AbnormRel.QCI.2+L.E-RAB.NormRel.QCI.2) 通过如下性能指标可以监控VoIP业务的掉话率:
指标名称 指标描述

2017-2-21

华为保密信息,未经授权禁止扩散

第 6 页, 共 119 页

文档名称 指标名称 L.E-RAB.AbnormRel.QCI.1 L.E-RAB.AbnormRel.QCI.2 L.E-RAB.NormRel.QCI.1 L.E-RAB.NormRel.QCI.2 指标描述 小区QCI为1的E-RAB异常释放次数 小区QCI为2的E-RAB异常释放次数 小区QCI为1的E-RAB正常释放次数 小区QCI为2的E-RAB正常释放次数

文档密级

由于中国移动集团有自己的KPI定义,中国移动的Volte掉话率定义如下,其中E-RAB掉 线率(QCI=1)(本地网)为日常考核使用公式。 E-RAB掉线率(QCI=1)(本地网) = ∑( 分QCI的eNB请求释放的E-RAB数 -分QCI的正常 的eNB请求释放的E-RAB数 +分QCI的切出失败的E-RAB数 )/∑分QCI的E-RAB建立成功数, 其 中∑代表将本地网范围内的各个小区的统计结果累加, QCI=1。 E-RAB掉线率(QCI=1)(小区级) =(分QCI的eNB请求释放的E-RAB数 -分QCI的正常的eNB 请求释放的E-RAB数 +分QCI的切出失败的E-RAB数 )/(分QCI的遗留E-RAB个数+分QCI的 E-RAB建立成功数+每QCI切换入E-RAB数)*100% ,其中QCI=1。 E-RAB掉线率(QCI=2)(本地网) = ∑( 分QCI的eNB请求释放的E-RAB数 -分QCI的正常 的eNB请求释放的E-RAB数 +分QCI的切出失败的E-RAB数 )/∑分QCI的E-RAB建立成功数, 其 中∑代表将本地网范围内的各个小区的统计结果累加, QCI=2。 E-RAB掉线率(QCI=2)(小区级) =(分QCI的eNB请求释放的E-RAB数 -分QCI的正常的eNB 请求释放的E-RAB数 +分QCI的切出失败的E-RAB数 )/(分QCI的遗留E-RAB个数+分QCI的 E-RAB建立成功数+每QCI切换入E-RAB数)*100% ,其中QCI=2。 备注: E-RAB掉线率(QCI=x)(本地网):此指标适用于区域汇总,如MME服务区或本地网以上 空间粒度。

中国移动Volte掉话率公式华为映射如下: E-RAB掉线率(QCI=1)(本地网)= (L.E-RAB.AbnormRel.eNBTot.QCI.1[1526730539]+L.E-RAB.AbnormRel.HOOut.QCI.1[15267 27326])/L.E-RAB.SuccEst.QCI.1[1526726669] = (eNodeB触发的QCI为1的业务E-RAB异常 释放次数[1526730539]+切换出QCI为1的E-RAB异常释放次数[1526727326])/QCI为1的业务
2017-2-21 华为保密信息,未经授权禁止扩散 第 7 页, 共 119 页

文档名称

文档密级

E-RAB建立成功次数[1526726669] E-RAB掉线率(QCI=1)(小区级)= (L.E-RAB.AbnormRel.eNBTot.QCI.1[1526730539]+L.E-RAB.AbnormRel.HOOut.QCI.1[15267 27326])/(L.E-RAB.SuccEst.QCI.1[1526726669]+L.E-RAB.Left.QCI.1[1526728808]+L.E-R AB.SuccEst.HOIn.QCI.1[1526728778]) = (eNodeB触发的QCI为1的业务E-RAB异常释放次数 [1526730539]+切换出QCI为1的E-RAB异常释放次数[1526727326])/(QCI为1的业务E-RAB建 立成功次数[1526726669]+QCI为1的遗留E-RAB个数[1526728808]+QCI为1的切换入E-RAB成 功建立次数[1526728778]) E-RAB掉线率(QCI=2)(本地网)= (L.E-RAB.AbnormRel.eNBTot.QCI.2[1526730540]+L.E-RAB.AbnormRel.HOOut.QCI.2[15267 27327])/L.E-RAB.SuccEst.QCI.2[1526726671] = (eNodeB触发的QCI为2的业务E-RAB异常释 放次数[1526730540]+切换出QCI为2的E-RAB异常释放次数[1526727327])/QCI为2的业务 E-RAB建立成功次数[1526726671] E-RAB掉线率(QCI=2)(小区级)= (L.E-RAB.AbnormRel.eNBTot.QCI.2[1526730540]+L.E-RAB.AbnormRel.HOOut.QCI.2[15267 27327])/(L.E-RAB.SuccEst.QCI.2[1526726671]+L.E-RAB.Left.QCI.2[1526728809]+L.E-R AB.SuccEst.HOIn.QCI.2[1526728779]) = (eNodeB触发的QCI为2的业务E-RAB异常释放次数 [1526730540]+切换出QCI为2的E-RAB异常释放次数[1526727327])/(QCI为2的业务E-RAB建 立成功次数[1526726671]+QCI为2的遗留E-RAB个数[1526728809]+QCI为2的切换入E-RAB成 功建立次数[1526728779])

1.1.2 异常释放统计
该章节内容,详细可参考《BTS3900 V100R011C10SPC100 性能指标参考.CHM》

异常释放测量指标
下表1内所示是异常释放话统测量指标
表1 异常释放测量指标

指标 ID

测量指标

指标描述

单 位

2017-2-21

华为保密信息,未经授权禁止扩散

第 8 页, 共 119 页

文档名称

文档密级

1526728319 L.E-RAB.AbnormRel.eNBTot

eNodeB 触发的 E-RAB 异常释放总次 次 数

1526728247 L.E-RAB.AbnormRel.HOOut 1526727546 L.E-RAB.AbnormRel

小区切换出 E-RAB 异常释放总次数 eNodeB 异常释放有数传的 E-RAB 的总

次 次

次数 1526726686 L.E-RAB.AbnormRel.QCI.1 1526726688 L.E-RAB.AbnormRel.QCI.2 1526726690 L.E-RAB.AbnormRel.QCI.3 1526726692 L.E-RAB.AbnormRel.QCI.4 1526726694 L.E-RAB.AbnormRel.QCI.5 1526726696 L.E-RAB.AbnormRel.QCI.6 1526726698 L.E-RAB.AbnormRel.QCI.7 1526726700 L.E-RAB.AbnormRel.QCI.8 1526726702 L.E-RAB.AbnormRel.QCI.9 小区 QCI 为 1 的 E-RAB 异常释放次数 小区 QCI 为 2 的 E-RAB 异常释放次数 小区 QCI 为 3 的 E-RAB 异常释放次数 小区 QCI 为 4 的 E-RAB 异常释放次数 小区 QCI 为 5 的 E-RAB 异常释放次数 小区 QCI 为 6 的 E-RAB 异常释放次数 小区 QCI 为 7 的 E-RAB 异常释放次数 小区 QCI 为 8 的 E-RAB 异常释放次数 小区 QCI 为 9 的 E-RAB 异常释放次数 次 次 次 次 次 次 次 次 次

异常释放指标含义
根据不同原因及用户承载数传情况,统计eNodeB小区内E-RAB异常释放的总次数。

异常释放测量点
如图6中A点所示,当eNodeB发出E-RAB RELEASE INDICATION消息,且释放原因不 为“Normal Release”,“Detach”,“User Inactivity”,“Om-Intervention”,“CS Fallback triggered” , “UE Not Available for PS Service” , “Inter-RAT Redirection” , “Successful Handover” , “Redirection towards 1xRTT”时统计L.E-RAB.AbnormRel.eNBTot指标,当判断相应承载有 数传时统计L.E-RAB.AbnormRel指标。如果E-RAB RELEASE INDICATION信令中要求同时 释放多个E-RAB,则相应的指标统计多次;

2017-2-21

华为保密信息,未经授权禁止扩散

第 9 页, 共 119 页

文档名称

文档密级

图1 异常释放测量点1

如图7中A点所示,当eNodeB向MME发送UE CONTEXT RELEASE REQUEST消息,会 释放UE的所有E-RAB。 当释放原因不为 “Normal Release” , “Detach” , “User Inactivity” , “Om-Intervention” “ , CS Fallback triggered” , “UE Not Available for PS Service” , “Inter-RAT Redirection” ,“Time critical handover” ,“Handover Cancelled”,“Redirection towards 1xRTT”时统计L.E-RAB.AbnormRel.eNBTot指标,当判断相应承载有数传时统计 L.E-RAB.AbnormRel指标。如果被释放用户建立了多个E-RAB,则相应的指标统计多次。并 且在MME回复UE CONTEXT RELEASE COMMAND消息时,相应指标不会被重复记录;

图2 异常释放测量点2

异常释放分原因统计
对于异常释放,eRAN8.0版本对异常原因进行了粒度更细的统计,主要针对无线层原
2017-2-21 华为保密信息,未经授权禁止扩散 第 10 页, 共 119 页

文档名称

文档密级

因进行细分, 另外增加了对应的VoIP异常释放的指标, 指标的详细定义可以参考 《BTS3900 V100R010C10SPC150 性能指标参考.CHM》。注:下面的指标是在有数传的情况下才统 计,如果是UE在无数传的情况发起的异常释放不统计。 指标 ID 测量指标 指标描述
无线层问题导致的 1526728282 L.E-RAB.AbnormRel.Radio E-RAB 异常释放次数 传输层问题导致的 1526728283 L.E-RAB.AbnormRel.TNL E-RAB 异常释放次数 无线网络拥塞导致的 1526728284 L.E-RAB.AbnormRel.Cong E-RAB 异常释放次数 切换流程失败导致 1526728291 L.E-RAB.AbnormRel.HOFailure E-RAB 异常释放次数 SRB RLC 达到最大重传 L.E-RAB.AbnormRel.Radio.SRBRese 1526729549 t E-RAB 异常释放次数 DRB RLC 达到最大重传 L.E-RAB.AbnormRel.Radio.DRBRese 1526729550 t E-RAB 异常释放次数 上行重同步失败导致的 L.E-RAB.AbnormRel.Radio.ULSyncF 1526729551 ail 次数 空口过程失败导致的激 L.E-RAB.AbnormRel.Radio.UuNoRep 1526729552 ly 数 核心网触发的释放原因 为 Release due to 1526729911 L.E-RAB.AbnormRel.MME.EUtranGen E-UTRAN Generated Reason 的激活的 E-RAB 活的 E-RAB 异常释放次 激活的 E-RAB 异常释放 次数导致的激活的 次数导致的激活的

备注

见 4.1.1.1 节

见 4.1.1.2 节

见 4.1.2.1 节

见 4.2 节

2017-2-21

华为保密信息,未经授权禁止扩散

第 11 页, 共 119 页

文档名称

文档密级

异常释放次数

无线资源被抢占导致的 1526729912 L.E-RAB.AbnormRel.Cong.PreEmp 激活的 E-RAB 异常释放 次数 无线资源过载导致的激 1526729913 L.E-RAB.AbnormRel.Cong.Load 活的 E-RAB 异常释放次 数 传输资源被抢占导致的 1526729914 L.E-RAB.AbnormRel.TNL.PreEmp 激活的 E-RAB 异常释放 次数 传输资源过载导致的激 1526729915 L.E-RAB.AbnormRel.TNL.Load 活的 E-RAB 异常释放次 数 核心网触发的语音业务 1526729916 L.E-RAB.AbnormRel.MMETot.VoIP E-RAB 异常释放总次数 SRB RLC 达到最大重传 L.E-RAB.AbnormRel.Radio.SRBReset. 1526729917 VoIP 业务 E-RAB 异常释放次 数 UE Reply 超时导致的激 L.E-RAB.AbnormRel.Radio.NoReply.Vo 1526729918 IP 常释放次数 上行重同步失败导致的 L.E-RAB.AbnormRel.Radio.ULSyncFail. 1526729919 VoIP 异常释放次数 L.E-RAB.AbnormRel.MME.EUtranGen. 1526729920 VoIP
2017-2-21

见 4.3 节

见 4.3 节

见 4.3 节

见 4.3 节

次数导致的激活的语音

见 4.1.1.1 节

活的语音业务 E-RAB 异

见 4.2 节

见 4.1.2.1
激活的语音业务 E-RAB


核心网触发的释放原因 为 Release due to
华为保密信息,未经授权禁止扩散 第 12 页, 共 119 页

文档名称

文档密级

E-UTRAN Generated Reason 的激活的语音业 务 E-RAB 异常释放次数 无线层问题导致的激活

见 4.1&4.2
1526729921 L.E-RAB.AbnormRel.Radio.VoIP 的语音业务 E-RAB 异常


释放次数 切换流程失败导致的激 1526729922 L.E-RAB.AbnormRel.HOFailure.VoIP 活的语音业务 E-RAB 异 常释放次数 无线网络拥塞导致的激 1526729923 L.E-RAB.AbnormRel.Cong.VoIP 活的语音业务 E-RAB 异 常释放次数 核心网触发的激活的语 1526729924 L.E-RAB.AbnormRel.MME.VoIP 音业务 E-RAB 异常释放 次数 传输层问题导致的激活 1526729925 L.E-RAB.AbnormRel.TNL.VoIP 的语音业务 E-RAB 异常 释放次数 无线资源被抢占导致的 L.E-RAB.AbnormRel.Cong.PreEmp.VoI 1526729926 P 异常释放次数 无线资源过载导致的激 1526729927 L.E-RAB.AbnormRel.Cong.Load.VoIP 活的语音业务 E-RAB 异 常释放次数 传输资源被抢占导致的 1526729928 L.E-RAB.AbnormRel.TNL.PreEmp.VoIP 激活的语音业务 E-RAB 异常释放次数 1526729929 L.E-RAB.AbnormRel.TNL.Load.VoIP 传输资源过载导致的激 激活的语音业务 E-RAB

见 4.2.2 节

见 4.3 节

见 4.3 节

见 4.3 节

见 4.3 节

见 4.3 节

见 4.3 节

2017-2-21

华为保密信息,未经授权禁止扩散

第 13 页, 共 119 页

文档名称

文档密级

活的语音业务 E-RAB 异 常释放次数

在36.413(36413-930内9.2.1.3章节)内给出了S1接口(S1AP协议)内对于释放原因 的一些定义,从协议定义,包含了4大类原因:无线层、传输层、NAS层及协议错误(前两 大类对应话统的就是L.E-RAB.AbnormRel.Radio/.TNL),每一大类又包含很多小类原因,如 下表所示:
表2 信令流程中释放原因值列表

2017-2-21

华为保密信息,未经授权禁止扩散

第 14 页, 共 119 页

文档名称 IE/Group Name Presence Range IE Type and Reference

文档密级 Semantics Description

CHOICE Cause Group >Radio Network Layer >>Radio Network Layer Cause

M

M

ENUMERATED (Unspecified, TX2RELOCOverall Expiry, Successful Handover, Release due to E-UTRAN Generated Reason, Handover Cancelled, Partial Handover, Handover Failure In Target EPC/eNB Or Target System, Handover Target not allowed, TS1RELOCoverall Expiry, TS1RELOCprep Expiry, Cell not available, Unknown Target ID, No Radio Resources Available in Target Cell, Unknown or already allocated MME UE S1AP ID, Unknown or already allocated eNB UE S1AP ID, Unknown or inconsistent pair of UE S1AP ID, Handover desirable for radio reasons, Time critical handover, Resource optimisation handover, Reduce load in serving cell, User inactivity, Radio Connection With UE Lost, Load Balancing TAU Required, CS Fallback Triggered, UE Not Available For PS Service, Radio resources not available, Failure in the Radio Interface Procedure, Invalid QoS combination, Inter-RAT redirection, Interaction with other procedure, Unknown E-RAB ID, Multiple E-RAB ID instances, Encryption and/or integrity protection algorithms not supported, S1 intra system Handover triggered, S1 inter system Handover triggered, X2 Handover triggered …, Redirection towards 1xRTT, Not supported QCI value, invalid CSG Id)

>Transport Layer 2017-2-21 华为保密信息,未经授权禁止扩散 第 15 页, 共 119 页

文档名称 >>Transport Layer Cause M ENUMERATED (Transport Resource Unavailable, Unspecified, …) >NAS >>NAS Cause M ENUMERATED (Normal Release, Authentication failure, Detach, Unspecified, …, CSG Subscription Expiry) >Protocol >>Protocol Cause M ENUMERATED (Transfer Syntax Error, Abstract Syntax Error (Reject), Abstract Syntax Error (Ignore and Notify),

文档密级

Message not Compatible with Receiver State, Semantic Error, Abstract Syntax Error (Falsely Constructed Message), Unspecified, …) >Misc >>Miscellan eous Cause M ENUMERATED (Control Processing Overload, Not enough User Plane Processing Resources, Hardware Failure, O&M Intervention, Unspecified, Unknown PLMN, …)

1.1.3 正常释放统计
该章节内容,详细可参考《BTS3900 V100R010C10SPC150 性能指标参考.CHM》

正常释放测量指标
下表2内所示是正常释放话统测量指标
表3 正常释放测量指标

指标 ID

测量指标

指标描述 E-RAB 建立成功总次数 遗留 E-RAB 总个数

单位 次 次
第 16 页, 共 119 页

1526727544 L.E-RAB.SuccEst 1526728817 L.E-RAB.Left
2017-2-21

华为保密信息,未经授权禁止扩散

文档名称

文档密级

1526727547 L.E-RAB.NormRel 1526726687 L.E-RAB.NormRel.QCI.1 1526726689 L.E-RAB.NormRel.QCI.2 1526726691 L.E-RAB.NormRel.QCI.3 1526726693 L.E-RAB.NormRel.QCI.4 1526726695 L.E-RAB.NormRel.QCI.5 1526726697 L.E-RAB.NormRel.QCI.6 1526726699 L.E-RAB.NormRel.QCI.7 1526726701 L.E-RAB.NormRel.QCI.8 1526726703 L.E-RAB.NormRel.QCI.9

eNodeB 正常释放 E-RAB 的总次数 小区 QCI 为 1 的 E-RAB 正常释放次数 小区 QCI 为 2 的 E-RAB 正常释放次数 小区 QCI 为 3 的 E-RAB 正常释放次数 小区 QCI 为 4 的 E-RAB 正常释放次数 小区 QCI 为 5 的 E-RAB 正常释放次数 小区 QCI 为 6 的 E-RAB 正常释放次数 小区 QCI 为 7 的 E-RAB 正常释放次数 小区 QCI 为 8 的 E-RAB 正常释放次数 小区 QCI 为 9 的 E-RAB 正常释放次数

次 次 次 次 次 次 次 次 次 次

正常释放指标含义
根据不同的QCI类型,统计小区E-RAB正常释放次数。

正常释放测量点
如图10中A点所示, MME主动发起的释放, 当eNodeB收到来自MME的E-RAB RELEASE COMMAND消息时,根据不同QCI统计相应指标。如果E-RAB RELEASE COMMAND消息 中要求同时释放多个E-RAB,则相应指标按各个业务的QCI分别进行累加。同时,根据消息 中携带的E-RAB个数对eNodeB正常释放E-RAB的总次数进行累加,即指标 L.E-RAB.NormRel累加;

2017-2-21

华为保密信息,未经授权禁止扩散

第 17 页, 共 119 页

文档名称 图3 正常释放测量点1

文档密级

如图11中A点所示,MME主动发起的释放,当eNodeB收到来自MME的UE CONTEXT RELEASE COMMAND消息时, 会释放UE的所有E-RAB, 如果释放原因不是切换类原因值, 包括“Successful Handover”, “Partial Handover”, “S1 intra system Handover triggered”, “S1 inter system Handover triggered”,“X2 Handover triggered”,则根据不同的QCI统计 相应指标。同时,根据具体业务数目对eNodeB正常释放E-RAB的总次数进行累加,即指标 L.E-RAB.NormRel累加。

图4 正常释放测量点2

1.1.4 指标包含关系
eRAN6.1版本开始,针对指标的包含关系进行了系统的梳理,在对版本的《BTS3900 V100RxxCxxSPCxxx 性能指标参考.CHM》 中, 点击对应的测量单元 (如下图左边红框所示) , 在右边会出现该测量单元总体介绍,在文档最下方(如下图后边红框所示),会出现指标的 包含关系,指标共5个层级,根指标—>一级节点指标—>二级节点指标—>三级节点指标—> 四级节点指标,从左至右是包含和被包含关系

2017-2-21

华为保密信息,未经授权禁止扩散

第 18 页, 共 119 页

文档名称

文档密级

1.2 路测KPI 1.2.1 华为Probe路测掉话定义
备注:以下定义从ProbeV3.15获取,其它版本请自行参考Probe的Help文档。 在华为Probe侧对于掉话 (ERAB Abnormal Release) 的定义: UE没有收到Deactivate Eps Bearer Context Request消息,但收到RRC Release或RRC Connection Reconfiguration消息,则 表示ERAB异常释放。以下情况表示ERAB异常释放:
?

?

? ?

?

?

UE 没有收到 DEACTIVATE EPS BEARER CONTEXT REQUEST 消息和 MME 的 DETACH REQUEST 消息,也没有向网络侧主动发出 DETACH REQUEST 消息,但 收到了 RRCConnectionReconfiguration 消息,且其中有信元“drb-ToReleaseList”。 UE 没有收到 DEACTIVATE EPS BEARER CONTEXT REQUEST 消息和 MME 的 DETACH REQUEST 消息,也没有向网络侧主动发出 DETACH REQUEST 消息,但 收到了 RRCConnection release 消息并且前 3s 有 APP 层速率传输。 UE 收到包含了信元“drb-ToAddModList”的 RRC Connection Reconfiguration 消息后, 收到 RRC 释放信令之前,UE 的“RRCState”值为“Idle”。 在 UE 没有收到 RRC Connection Reconfiguration 消息、 DEACTIVATE EPS BEARER CONTEXT REQUEST、 DETACH REQUEST 消息、 RRC State、 RRCConnection release 消息时,收到 RRC 的业务请求。 UE 收到了 RRCConnectionReconfiguration 消息 (其中有信元“drb-ToReleaseList”)之 后 50ms 内,没有收到“DEACTIVATE EPS BEARER CONTEXT REQUEST”的 NAS 消息。 遇到 RRCReestablishFail 事件和 InterRATHOFail 时,产生该事件。

华为Probe侧对于Volte掉话定义为:
2017-2-21 华为保密信息,未经授权禁止扩散 第 19 页, 共 119 页

文档名称

文档密级

VoLTECallDropRate (Volte掉话率) = VoLTE掉话次数/(VoLTE主叫应答次数 + VoLTE 被叫应答次数)× 100%。其中,分子和分母定义如下 VoLTE掉话次数VoLTECallDrop:没有判断出来VoLTECallEnd的事件场景(不区分主 被叫)下,满足以下任一条件(长呼只看条件1):
? ?

收到层三消息 RRCConnection Release 在判断出 VoLTECallEstablished (MOC)或者 VoLTECallEstablished (MTC)场景下, 2s 以后收到的层三消息 RRCConnection Request。

短呼场景下,通话时长+5s内,主叫仍没判断出VoLTECallEnd事件,且没有 SRVCCHandoverSuc(收到该事件,状态迁移到VoLTECallInitial)事件产生。 VoLTE主叫应答次数VoLTEVideoPhoneEstablished (MOC):高通芯片收到0x156E包 或海思芯片已经判断出VoLTEVideoPhoneSetupSuc(MOC)的前提下,收到海思层间消息 0x4包,同时满足如下条件: 1.获取其Direction字段,Direction = NETWORK_TO_UE 2.获取其Message ID字段,Message ID = IMS_SIP_INVITE 3.获取其Response Code字段,如果: Response Code = OK (200) VoLTE被叫应答次数VoLTEVideoPhoneEstablished (MTC): 高通芯片收到0x156E包或 海思芯片已经判断出来VoLTECallSetupSuc(MTC)的前提下,收到海思层间消息0x4包, 同时满足以下条件时,生成该事件。 1.获取Direction字段,Direction = UE_TO_ NETWORK 2.获取Message ID字段,Message ID = IMS_SIP_INVITE 3.获取Response Code字段,Response Code = OK (200)

1.2.2 其它厂家路测掉话率定义
三星UE通过三星数据卡及XCal软件获取。 高通平台通过高通QXDM工具获取。 鼎力和诺优等ATU厂家分别通过对应厂家的ATU软件获取。

1.2.3 路测掉话率和后台掉话率区别
对于后台掉话场景同数据业务,只涉及两个话统:eNodeB触发的QCI为1的业务E-RAB异常释
2017-2-21 华为保密信息,未经授权禁止扩散 第 20 页, 共 119 页

文档名称

文档密级

放次数[1526730539]、切换出QCI为1的E-RAB异常释放次数[1526727326]。 而对于路测Volte掉话, 非SIP消息“Bye”引发的掉话都是异常。 涉及SIP消息交互异常引发 的掉话,通常后台会统计为正常释放,这主要和eNodeB不解析SIP消息有关。

1.3 标口信令
在eNodeB跟踪到的标准接口信令中,如果存在eNodeB发起的释放,即在S1接口上发往 CN的S1AP_UE_CONTEXT_REL_REQ/S1AP_E-RAB_RLEASE_IND消息内携带的原因值不 为“User-inactivity ”、 “Normal Release”, “Detach”, “User Inactivity”, “CS Fallback triggered” , “UE Not Available for PS Service” , “Inter-RAT Redirection” , “Successful Handover” ,“Redirection towards 1xRTT”时,则判断为掉话。

1.3.1 掉话预检查方式
异常掉话通常都是由eNB发起的释放,通知MME释放上下文,因此只要查看S1口发送 的S1AP_UE_CONTEXT_REL_REQ/S1AP_E-RAB_RLEASE_IND消息,如下图所示。

图5 S1AP_UE_CONTEXT_REL_REQ

点击“标准接口消息类型”按消息类型进行排序,这样所有的
2017-2-21 华为保密信息,未经授权禁止扩散 第 21 页, 共 119 页

文档名称

文档密级

S1AP_UE_CONTEXT_REL_REQ/S1AP_E-RAB_RLEASE_IND都会排列在一起, 如下图所示。

图6 按消息类型排序

依次点击下一条, 查看中的原因值, 找出最后的原因为非 “Normal Release” , “Detach” , “User Inactivity” , “CS Fallback triggered” , “UE Not Available for PS Service” , “Inter-RAT Redirection”,“Successful Handover” ,“Redirection towards 1xRTT”的原因值。

图7 找到异常掉话消息

根据对应的时间点, 打开标准UU口的跟踪, 找到对应时间点的RRC_CONN_REL消息, 如下图所示。

2017-2-21

华为保密信息,未经授权禁止扩散

第 22 页, 共 119 页

文档名称

文档密级

图8 找到对应的UU口消息

再查找对应时间点的IFTS跟踪,看是否跟踪到该异常释放UE的IFTS跟踪。

图9 找到对应的IFTS消息

打开IFTS跟踪,查找对应的时间点的跟踪是否可以和UU口、SI口对应上,如果无法对 应,说明该IFTS跟踪的UE和当前掉话的UE不是同一个UE,则该IFTS跟踪就没有分析的必 要。如果可以找到IFTS跟踪的UE和当前掉话的UE是同一个UE,则把该S1/UU/IFTS跟踪返 回总部分析。 IFTS跟踪如下:

2017-2-21

华为保密信息,未经授权禁止扩散

第 23 页, 共 119 页

文档名称

文档密级

1.3.2 获取方式
eNodeB维护台, 跟踪文件类型为tmf, 需要通过trace viewer进行解析, 具体的采集方法, 请参见配套文档《LTE TDD故障信息采集指导书》:

1.4 CHR数据
S1接口上发往CN的S1AP_UE_CONTEXT_REL_REQ/S1AP_E-RAB_RLEASE_IND消息 内携带的原因值不为 “User-inactivity ” 、“Normal Release” , “Detach” , “User Inactivity” , “CS Fallback triggered”,“UE Not Available for PS Service”,“Inter-RAT Redirection”, “Successful Handover”,“Redirection towards 1xRTT”时,则判断为掉话。CHR会记录一 次内部异常事件。 注:CHR详细分析方法参考《TD-LTE CHR分析使用指导书-掉话篇 V1.0》

1.4.1 掉话预检查方式
用FMA工具,打开工程,点击“Expert”,再双击“Drop”,就可以看到所有掉话的记
2017-2-21 华为保密信息,未经授权禁止扩散 第 24 页, 共 119 页

文档名称

文档密级

录。

在右下方,选中一条呼叫记录,右键选择“All Events by This Callid”就可以把一次呼 叫的所有记录事件过滤出来。

打开呼叫记录后,选择最后一条“L3ChrRecord”,找到“SigInfolst”,双击可查看该 次呼叫最后的信令流程。

2017-2-21

华为保密信息,未经授权禁止扩散

第 25 页, 共 119 页

文档名称

文档密级

本次掉话的信令流程如下图所示,重配置下发后未收到重配置完成消息,向MME发送 UE context释放请求。

1.4.2 获取方式
获取CHR的方式很多,可以通过主控板一键式日志提取,也可以在TS服务FTP提取,具 体参考《LTE TDD故障信息采集指导书》。其中,TS服务器路径为:

/export/home/sysm/ftproot/SauService/CHR, CHR文件是以NE/日期格式排列, 每个eNodeB
2017-2-21 华为保密信息,未经授权禁止扩散 第 26 页, 共 119 页

文档名称

文档密级

可以保存7天的CHR数据,NE和eNodeBID是一一对应的,可以通过M2000的MML界面到 处相应版本所有eNodeB对应关系

2 掉话机制
对于路测掉话率公式涉及的机制, 请参考各路测软件厂家的帮助文档, 本文主要介绍后台掉 话率公式涉及的机制。 对于后台掉话率,无论数据业务(QCI 6/7/8/9)还是Volte业务(QCI 1/2),掉话机制是相 同的。
2017-2-21 华为保密信息,未经授权禁止扩散 第 27 页, 共 119 页

文档名称

文档密级

这里有一点需要注意,对于如果QCI对应的RLC层传输模式为UM模式,则没有“RLC达到最 大重传次数”原因的掉话,对于AM模式,则涉及。 一般,华为推荐QCI1/2/7的RLC模式为UM模式。

2.1 L2掉话机制 2.1.1 RLC达到最大重传次数(协议36.322)
在以下几种情况下,RLC会发起重传 1) 2) 3) 收到对端的状态 PDU 的 NACK 确认(negative acknowledgement); 没有收到对端的状态 PDU,没有新数据发送,同时 POLL 周期定时器超时; 没有收到对端的状态 PDU,发送窗满,同时 POLL 周期定时器超时。

对于1)存在MAC层发送RLC数据时,几次HARQ重传都失败的情况,才会有RLC层的 NACK确认。如下图所示。
ENB RLC ENB HARQ Init Tx(SN=X) SN Init Tx(SN=Y) SN SN SN SN Re Tx(SN=X) UE HARQ = = = = = X Y X X X UE RLC

SN = Y

Status Pdu ACK= Y NACK= X

图10 收到对端的状态PDU的负确认

对于2)和3),都是在没有收到对端状态PDU的情况下,由POLL周期定时器超时触发 的RLC重传,对于没有收到对端状态PDU的原因有两个,一个原因为UE侧根本就没有收到 任何RLC PDU,也就不会响应状态PDU,另一个原因为UE响应的状态PDU,由于上行误码 的原因,没有到达ENODEB。如图2和图3所示:
ENB RLC Init Tx ENB HARQ UE HARQ UE RLC

Re Tx

图11 下行数据发送失败

2017-2-21

华为保密信息,未经授权禁止扩散

第 28 页, 共 119 页

文档名称
ENB RLC Init Tx ENB HARQ UE HARQ UE RLC

文档密级

Status Pdu Re Tx

图12 上行数据发送失败

对于RLC达到最大重传次数的原因分析如下: 1、网络覆盖的原因,弱覆盖/干扰等; 2、UE终端问题,从之前的掉话分析,较大情况是因为UE问题导致PDCCH漏检 3、其他(用户拔卡/突然不发数/终端不回复状态PDU)

SRB达到最大复位次数
在 eNodeB 侧下发 AM 信令如果终端侧没有收到,则会进行 MAC 层的 HARQ 及 RLC 的 ARQ重传,在SRB下行达到最大重传次数后(默认为32次,MML参数无法配置)* Polling (默认50ms,MML参数无法配置)后,L2会上L3上报RLC Unrestore的指示,L3启动启动 延迟释放定时器,在等待延迟释放定时器超时后掉话。 延迟释放时间 eRAN6.1 及以前版本是写死的 20s ,不可设置, eRAN7.0 可以由参数 UeRelDelayTimer控制。

DRB达到最大复位次数
在业务保持过程中,由于弱覆盖、信号陡降、拔卡场景下,若eNodeB侧RLC缓存有数 据待发送, 则易引起DRB达到最大重传次数引起的异常释放; 在DRB达到最大重传次数后, 以 QIC9 为 例 ( 基 线 值 32 次 , 对 应 MML 参 数 配 置 为 ENodeBMaxRetxThreshold=Maxretx_Threshold_t32)* Polling(基线值定时器50ms,对 应MML参数配置为ENodeBPollRetransmitTimer= Tpollretrans_m50),L2会上L3上报RLC Unrestore的指示,L3启动启动延迟释放定时器,在等待延迟释放定时器超时后掉话。 延迟释放时间 eRAN6.1 及以前版本是写死的 20s ,不可设置, eRAN7.0 可以由参数
华为保密信息,未经授权禁止扩散 第 29 页, 共 119 页

2017-2-21

文档名称

文档密级

UeRelDelayTimer控制。

2.1.2 失步流程

上行失步流程介绍
失步分为上行失步和下行失步, 在eNodeB侧检测到的失步称为上行失步; 在UE可以同 时检测到上行失步及下行失步。 UE的上行失步是通过TA定时器维护的, 当TA定时器超时后, 终端还没有收到eNodeB下发的TA调整的MCE,则判断为上行失步;终端检测的下行失步 将在下一小节作详细介绍。此处原因值对应的重同步失败是上行失步之后eNodeB发起的重 同步失败; eNodeB 检测失步的方法有两种: 1 、 eNodeB 连续 N 次下发 TA 但是没有收到 TA_ACK;2、检测到eNodeB L1基带上行连续N次没有上报TA值到L2;两种条件中任意组 合连续达到N次,就判断为上行失步,N表示eNodeB 在TATimer定时期内eNodeB下发TA MCE的次数(N=2)。 eNodeB检测到上行失步,有下行数据要发送
UE 1. send TA 2. TA_ACK 3. report non-synchronization DL data waiting to send 4. Specifically Preamble request 5. send specifically Preamble 6. send specifically Preamble 7. specifically Preamble 9. RAR(include TA and data) 10. RRC_Recofiguration( config TM2) 11. RRC_Reconfiguration_cmp DL GRANT(data) 8. synchronization ENB L2 ENB L3

图13 eNodeB检测到上行失步,且有下行数据要发送 2017-2-21 华为保密信息,未经授权禁止扩散 第 30 页, 共 119 页

文档名称

文档密级

在第6步发送专用Preamble消息给UE后,L2会启动定时器,如果定时器超时还没有收到 UE响应的专用Preamble,则上报L3,指示由于下行数据触发的重同步失败,L3启动延迟释 放定时器, 在定时器超时后释放UE。 目前版本, 当eNodeB检测到上行失步之后, 如果eNodeB 下行有数据要发,则下发PDCCH Order触发重同步,eNodeB会最多下发5次重同步,重同步 次数为min(userinactivetimer/2,5)。

eNodeB检测到上行失步,没有下行数据要发送
UE 1. send TA 2. TA_ACK Non-synchronization, there is no data to send, it need to reset the resynchronization timer. ENB L2 ENB L3

3. report non-synchronization

Re-synchronization timer over, eNodeB does not receive UE re-synchronization message , start the 1s timer.

4. Specifically Preamble request 5. send specifically Preamble

6. send specifically Preamble 7. Specifically Preamble After 1s timer, eNodeB does not receive the specifically preamble. 8. Re-synchronization timer over 9. RAR(包含TA) 10. RRC_Recofiguration( config TM2) 11. RRC_Reconfiguration_cmp 8. synchronization

图14 eNB检测到上行失步,没有下行数据要发送

在第3步检测到失步后,如果没有下行数据要发送,如果不活动定时器先超时,则基站 会主动启动一次专用Preamble请求,下发专用Preamble,如果没有重同步上,则上报L3, 指示重同步定时器超时, L3释放UE, 该释放为异常释放, 原因为UE LOST; 如果同步上了, 则也指示L3释放UE,原因值为User inactivity。

2017-2-21

华为保密信息,未经授权禁止扩散

第 31 页, 共 119 页

文档名称

文档密级

UE检测到上行失步,有上行数据要发送 同 初 始 接 入 流 程 , UE 发 起 竞 争 的 随 机 接 入 , 收 到 RAR 则 同 步 成 功 。
UE 1. 下发TA 2. NO TA_ACK/L1 DSP测量不到TA ENB L2 ENB L3

3. 上报失步指示

7. Preamble 8. 同步指示 9. RAR(包含TA) 10. RRC_Recofiguration(重配MAC资源) 11. RRC_Reconfiguration_cmp

下行失步流程介绍
UE DSP每200ms对时延谱滤波值进行判断,如果满足某门限,则上报L3失步;L3在同 步状态连续收到N310个L1上报的out-of-sync指示,则认为失步,同时,启动T310定时器, 在T310超时前,若收到N311次in-sync指示,则认为UE恢复同步状态,否则,T310超时后, UE会触发重建流程(包括搜索小区、同步、重建),同时启动T311定时器,若超时仍未重 建成功,则进入IDLE态。 附录:移动集团参数规范要求—部分定时器
参数名称 T300 T302 T310 N310 N311 T304 规范值 1000ms 2000ms 1000ms n20 n1 500ms

2017-2-21

华为保密信息,未经授权禁止扩散

第 32 页, 共 119 页

文档名称

文档密级

T311 T301

1000ms 600ms

2.2 L3掉话机制 2.2.1 空口定时器超时
“在eNB侧成功下发RRC重配置消息后信令后,启动等待UE UU口响应定时器(对应 MML参数配置为UuMessageWaitingTimer,一般配置35s),若UuMessageWaitingTimer超时 后未收到UE回复的信令,该流程超时后导致掉话;

2.2.2 X2/S1口定时器超时
在X2口切换过程中,当源侧向核心网发送完Path Swith Request后,会启动X2口定时器 (X2MessageWaitingTimer,一般配置20s),当X2MessageWaitingTimer定时器超时后,仍 然没有收到目标eNodeB发送的UE Context Release消息,则源侧向MME发送UE Context Release Request发起释放。 在接入过程中,当eNodeB发送完Initial UE Message消息后,会启动S1口定时器 (S1MessageWaitingTimer,一般配置20s),当S1MessageWaitingTimer定时器超时后,任然 没有收到核心网没有下发Intial Context Setup Request,则eNodeB向MME发送UE Context Release Request发起释放,注意,这种情况只会统计Context异常释放,由于这个时候E-RAB 还没有建立起来,所以不会统计E-RAB异常释放。

2.3 其他掉话机制
除了上面介绍的L2和L3相关的掉话机制,当基站资源过载或者触发了负载控制算法, 比如无线资源不足、无线资源抢占、传输资源抢占等eNodeB会主动释放E-RAB或者上下文 发起释放,这部分释放会统计到掉话中去。 另外,如果传输层出现错误,eNodeB也会主动发起释放。

3 主要掉话原因分析及优化
3.1 常见掉话原因
Volte掉话问题的定位和普通数据业务掉话问题的定位步骤类似,关联指标分析时可以
2017-2-21 华为保密信息,未经授权禁止扩散 第 33 页, 共 119 页

文档名称

文档密级

将语音的掉话和普通数据业务的掉话进行关联,分析只是普通数据业务掉话率恶化、Volte 掉话率恶化还是所有业务掉话率恶化。具体分析时还要考虑Volte掉话和普通数据业务掉话 的差异。

3.1.1 邻区错/漏配

常用优化方法
通常,网络建设初期优化过程掉话占大多数是由于邻区错/漏配导致的。对于LTE网络 内同频邻区,通常采用以下的办法来确认是否为同频邻区漏配: 方法一: 如果掉话后UE马上重新接入, 且UE重新接入的PCI与UE掉话时的PCI不一致, 则可以怀疑是邻区错/漏配问题,可以通过测量控制进一步进行确认(从掉话位置的消息开 始往前找,找到最近一条同频测量控制消息,检查该测量控制消息的邻区列表)。 方法二:在网络侧,观察eNodeB在收到UE上报的测量报告后如果没有处理,且同时 X2口没有往目标小区发送HANDOVER_REQUEST,则可以怀疑是邻小区漏配。(该方法 只适用于异站切换,同站切换没有X2口交互)。 邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。 异频邻区漏配的确认方法 和同频几乎相同,主要是掉话发生的时候,UE没有测量或者上报异频邻区,而UE掉话后重 新驻留到异频邻区上。异系统邻区漏配表现为UE在LTE网络掉话,掉话后UE重新选网驻留 到异系统网络,且从信号质量来看,异系统网络的质量很好。 定位邻小区错/漏配的方法可通过UE的Scanner功能进行扫频,观察是否有更强的的且 不在邻小区列表中的小区。 邻小区错/漏配需要结合工参、电子地图等信息进行优化。 优化建议: 1、 结合日常拉网簇优化逐步开展 2、 结合工参、地图等进行参数调整

Volte掉话优化注意
现网CSFB需要配置2G频点, 不要求配置正确的2G邻区准确信息,同时eNodeB携带的 频点组即使没有合适的2G频点信息,终端也会自主搜索其他频点,CSFB呼叫不会失败,只
2017-2-21 华为保密信息,未经授权禁止扩散 第 34 页, 共 119 页

文档名称

文档密级

是会增加CSFB接续时延。 SRVCC实际相当于切换过程,要求4G侧必须配置2G邻区精确的信息(BCC,NCC, LAC都必须正确),并且不能漏配合适2G小区,如果2G邻区配置不合适,就会导致终端测 量不到合适2G小区,触发不了SRVCC导致VoLTE掉话。 为了保证SRVCC正常执行,现网需要核查4G配置2G邻区是否漏配,邻区信息,由于 现网GSM翻频较频繁,要求GSM能够提供准确的工参,并且长期核查4G到2G邻区配置, 这个会增加网优较大的工作量。Smart RNO工具支持4G侧2G邻区规划工作,也可以使用异 系统ANR进行异系统邻区优化。

3.1.2 弱覆盖
这里所说的弱覆盖是超出了链路预算获得的最大路损得到的下行及上行的覆盖, 由于上 下行支持的最大路损不一致,通常在LTE中上行较之于下行先受限,故在这里提到的弱覆盖 将分为上行弱覆盖及下行弱覆盖。 按照当前V100R004C00及以后版本的商用网典型配置来看,下行PDSCH导频配置的 是15.2dBm(2T2R配置),上行UE最大发射功率为23dBm。在链路预算过程中链路预算的 结果和场景、链路预算的边缘吞吐率、接收机灵敏度等的配置强相关。 相关链路预算结果如下表所示:
表4 链路预算结果 Scenario Edge Rate (Kbps) Morphology Channel Model Sectorization System Bandwidth (MHz) Edge MCS Antenna Configuration Environment Resource Block Total RB Number 2017-2-21 PDSCH 1024 Dense Urban ETU3 3 Sector 20 QPSK 0.12 2x2 SFBC Indoor PDSCH 100 华为保密信息,未经授权禁止扩散 PUSCH 64 Dense Urban ETU3 3 Sector 20 QPSK 0.13 1x2 Indoor PUSCH 84 第 35 页, 共 119 页

文档名称 RB Number Required Tx Max Tx Power (dBm) Cable Loss (dB) Body Loss (dB) Antenna Gain (dBi) EIRP (dBm) Rx Antenna Gain (dBi) Cable Loss (dB) Body Loss (dB) Noise Figure (dB) Interference Margin (dB) SINR (dB) Receiver Sensitivity (dBm) Minimum Signal Level (dBm) MAPL Penetration Loss (dB) Std Dev of Slow Fading (dB) Area Coverage Probability Shadow Fading Margin (dB) MAPL (dB) Cell Coverage UE Antenna Height (m) eNB Antenna Height (m) Carrier Frequency (MHz) 39 PDSCH 46.01 0.5 0 18 32.72 PDSCH 0 0 0 7 1.40 -5.10 -130.34 -128.95 PDSCH 20 11.7 95% 10.86 130.80 PDSCH 1.5 30 2655 Cost231-Hata Propagation Model Huawei 2017-2-21 华为保密信息,未经授权禁止扩散 Huawei 3 PUSCH 23.00 0 0 0 7.44 PUSCH 18 0.5 0 2.5 1.40 -4.03 -133.76 -149.86 PUSCH 20 11.7 95% 10.86 126.44 PUSCH 1.5 30 2535 Cost231-Hata

文档密级

第 36 页, 共 119 页

文档名称 Coverage (Km) 0.40 0.31

文档密级

从上表可见,该场景下(下行边缘吞吐率为1024k,最少39个RB)下行支持的最大路 损为130.8dB,则按照导频是 18.2dBm 来计算的话,下行支持的最小 RSRP为18.2-130.8= -112.6,若低于该电平值,则可以认为下行存在弱覆盖。而该场景(上行边缘吞吐率64k, 最少 3 个 RB )上行支持的最大路损为 126.44dB ,则上行支持的最小 RSRP 为 23-126.44= -103.44dBm(上行RSRP可以从内部CHR的L2_CHR_USER_SRB_INFO事件中找到),若上行 低于该值,则就认为上行存在弱覆盖。只要是上行或者下行其中一个存在弱覆盖,则就有导 致掉话发生的可能。 优化建议: 1、 结合实际路测情况及工参进行调整优化 2、 加站 3、 修改互操作参数BlindHoA1A2ThdRsrp使UE在4G覆盖边缘尽快互操作到到异系统 4、 极端情况下修改最小接入电平BlindHoA1A2ThdRsrp进行控制 5、 对于上行弱覆盖,可以调整上行功控 PassLossCoeff、P0NominalPusch参数,这两 个参数可以增加UE发射功率,但是调整太高,会对邻区造成干扰
参数
BlindHoA1A2ThdRsrp QRxLevMin PassLossCoeff P0NominalPusch

建议值
-122 -64~-60 0.7 -67

6、 对于Volte业务,开启SRVCC功能,并调整相关参数。详细请见6.1.3.2节。

3.1.3 切换导致的掉话

常用优化方法
在LTE系统中, 在时间轴上, 可将切换分为如下3类: 过早切换、 过晚切换及乒乓切换。 由于重建的引入,通常过早切换能重建回源区,故不会引发掉话,而过晚切换及乒乓切换易 导致掉话。
2017-2-21 华为保密信息,未经授权禁止扩散 第 37 页, 共 119 页

文档名称

文档密级

从信号变化趋势上来看,过晚切换主要有以下现象: 1) 拐角效应:源小区RSPR/SINR陡降,目标小区RSRP/SINR陡升(即突然出现在邻 小区列表中就是很高的值); 2) 针尖效应:源小区RSPR/SINR快速下降后一段时间后上升,目标小区出现短时间 的陡升后立即陡降。 因为切换过晚时容易发生目标小区没有UE的上下文,由于eRAN2.2SPC230之前的版 本尚未实现无上下文的重建,故易造成重建失败,最终导致掉话。之后的版本在多数场景下 可以无上下文重建成功,如果该现象仍有发生,需要具体问题再具体分析。 从信令流程上看,一般在掉话前UE上报了邻区的A3测量报告,eNodeB也收到了测量 报告,并下发了切换命令,但是UE侧收不到,此时如果目标小区能有UE的上下文且能重建 成功,可以不掉话。 乒乓切换在信号变化趋势上有如下表现: 1)主服务小区变化快:2个或者多个小区交替成为主服务小区,主服务小区具有较好 的RSRP和SINR且每个小区成为主导小区的时间很短; 2)无最优小区:存在多个小区,RSRP正常而且相互之间差别不大,每个小区的SINR 都很差。 从信令流程上看,一般可以看到UE刚刚完成一次切换后就有新的测量报告上报并发起 另一次切换,由于切换后还有较多的重配置消息下发(CQI上报模式、sounding等),在乒 乓区域易导致这些命令超时失败引起掉话。 解决切换过晚导致的掉话问题,可以通过调整天线位置,修改切换参数或者配置CIO使 目标小区能够提前发生切换;解决乒乓切换带来的掉话问题,主要通过调整天线位置改善 RF,使得该区域能有一个稳定的最优小区。 对于异频切换和异系统切换,在切换前需要通过启动 GAP来进行异频或者异系统频点 的测量,故需要对A2参数进行合理配置,保证及时的起GAP测量,从而避免起GAP过晚导 致的终端来不及测量目标侧小区的信号导致掉话,并合理的配置目标小区的门限。 切换相关的问题需要参见 《运维文档_LTE TDD性能问题定位和优化指导书-切换篇》 。 对于切换引起的掉话,第一要进行RF优化,排除RF原因,第二参数要进行合理设置, 下面是对于切换的部分参数设置建议值:

2017-2-21

华为保密信息,未经授权禁止扩散

第 38 页, 共 119 页

文档名称

文档密级

参数
A3InterFreqHoA1ThdRsrp A3InterFreqHoA2ThdRsrp InterFreqHoA1A2Hyst InterFreqHoA4ThdRsrp InterFreqHoA1ThdRsrp InterFreqHoA2ThdRsrp InterFreqHoA3Offset InterFreqHoA4Hyst InterFreqHoA4ThdRsrp IntraFreqHoA3Hyst IntraFreqHoA3Offset IntraFreqHoA3TimeToTrig GapPatternType

建议值
-100 -105 2 -100 -100 -105 4 2 -112 2 2 320ms GAP_PATTERN_TYPE_2

注:由于部分芯片对于GAP处理存在问题,容易引起切换失败和掉话,GapPatternType强烈 建议设置为GAP_PATTERN_TYPE_2, 这样做第一可以将GAP测量的间隔拉长, 减小终端进 入GAP的频率,减少异常;由于终端进入GAP后不进行输出,拉长周期,对吞吐率提升也有 好处干扰引起的掉话。

Volte掉话优化注意
现网数据业务开启的互操作策略是基于测量重定向和盲重定向, 即使测量时间来不及, 盲重 定向也可以生效,并且数据业务即使脱网到异系统影响也不大。但是语音业务使用SRVCC 策略,要求必须测量到合适的小区才能触发。前期测试发现终端测量2G的时间波动非常大 (2s-10s),在快衰落的场景下,由于来不及测量导致SRVCC失败的概率较大。SRVCC异 系统A2起测的门限既不能配置过低也不能配置过高,门限过高会导致终端到2G太早,门限 过低会导致切换失败,SRVCC门限需要针对不同场景(高速,电梯,地下室等)特点精细 优化,网优工作量较大。
2017-2-21 华为保密信息,未经授权禁止扩散 第 39 页, 共 119 页

文档名称

文档密级

日常优化应根据各个场景特点实地摸测,微调SRVCC测量异系统A2,B1/B2门限以及切换 时间迟滞等参数。 调整参数命令如下: MOD INTERRATHOCOMMGROUP: LocalCellId=1, InterRatHoCommGroupId=1, InterRatHoA1ThdRsrp=XX, InterRatHoA2ThdRsrp=XX; 深圳不同场景eSRVCC门限摸索,供参考: 场景 电梯场景(E频段) 电梯场景(F/D频段) 进出地铁站 进出室内外 高速公路 隧道场景 地铁列车场景 高铁场景 高干扰站点(NI>-100站点) 分类 eSRVCC切换 eSRVCC切换 eSRVCC切换 eSRVCC切换 eSRVCC切换 eSRVCC切换 eSRVCC切换 eSRVCC切换 eSRVCC切换 推荐参数 A2=-90/B2-LTE=-105/TTI=128ms A2=-90/B2-LTE=-115/TTI=320ms A2=-105/B2-LTE=-110/TTI=320ms A2=-105/B2-LTE=-115/TTI=320ms A2=-110/B2-LTE=-115/TTI=320ms A2=-105/B2-LTE=-115/TTI=320ms A2=-95/B2-LTE=-115/TTI=320ms A2=-105/B2-LTE=-115/TTI=320ms A2=-105/B2-LTE=-110/TTI=320ms

3.1.4 干扰引起的掉话
通常干扰分为上行干扰及下行干扰, 系统内干扰及外来干扰。 不论哪种类型的干扰都会 导致掉话。 通常,对于下行,当服务小区的RSRP高于-90,但是SINR低于-6,基本上可以认为是 下行干扰的问题(当邻小区错/漏配或切换不及时的时候,也可能出现服务小区 RSRP信号 很好,但SINR很差的情况);下行的干扰通常是指导频污染,指覆盖地区存在3个以上的小 区满足切换条件,由于信号的波动常常出现频繁小区重选或者乒乓切换,可能会导致掉话。 通常在没有干扰的情况下, 上下行是平衡的, 而当下行存在干扰时, 会体现在下行受限, 上行不受限;而存在上行干扰时,则是上行受限但下行不受限。 上行干扰可以从话统指标上进行分析。TDD系统上行干扰包普通时隙和特殊时隙的干 扰两方面,两种干扰呈现的特征也是不一样的,对于上行普通时隙的干扰,我们有下面的指
2017-2-21 华为保密信息,未经授权禁止扩散 第 40 页, 共 119 页

文档名称

文档密级

标,但是这些指标是全带宽的干扰体现,对于只有干扰到部分PRB的情况,可能会淹没掉, 但是整体上还是可以进行评估,PRB级别的干扰理论上最小值为-118dBm,一般认为如果 小区平均干扰L.UL.Interference.Avg持续大于-100dBm, 那么就需要关注了, 对于掉话分析, 可以关联看掉话集中的时段L.UL.Interference.Max是否偏大 系统上行每个PRB上 1526728297 L.UL.Interference.Max 检测到的干扰噪声的 最大值 系统上行每个PRB上 1526728298 L.UL.Interference.Avg 检测到的干扰噪声的 平均值 系统上行每个PRB上 1526728435 L.UL.Interference.Min 检测到的干扰噪声的 最小值

如上所述, 上面的指标统计的是全带宽的干扰, 对于频域干扰不能进行很好的分析, eRAN7.0 增加了针对100个PRB单独统计的干扰最大值和平均值的指标,由于有200个指标,之前的测 量单元“信道质量测量”无法容纳,专门新增了测量单元“信道质量测量1”。可以利用这 些指标进行精细化的分析,由于指标太多,下面不一一列举出来,可以参考《BTS3900 V100R009C00性能指标参考.CHM》

2017-2-21

华为保密信息,未经授权禁止扩散

第 41 页, 共 119 页

文档名称

文档密级

2017-2-21

华为保密信息,未经授权禁止扩散

第 42 页, 共 119 页

文档名称

文档密级

对于特殊时隙的干扰,目前有如下指标: 统计上行UpPTS每个 1526728769 L.UpPTS.Interference.Avg PRB上检测到的干扰 噪声。 统计第1个上行子帧 1526728770 L.UL.FirstUL0.Pwr 的第0个符号接收总 功率。 统计第1个上行子帧 1526728771 L.UL.FirstUL6(4).Pwr 的第6(或4)个符号接 收总功率。 统计倒数第1个上行 1526728772 L.UL.LastUL0.Pwr 子帧的第0个符号接
2017-2-21 华为保密信息,未经授权禁止扩散 第 43 页, 共 119 页

文档名称

文档密级

收总功率。

统计倒数第1个上行 1526728773 L.UL.LastUL11(9).Pwr 子帧的第11(或9)个 符号接收总功率。

1、 网外干扰 分析方法:上行频谱扫描、上行干扰实时监测(100PRB)、话统 需要进行扫频、频谱分析,找出干扰的频段,如果可能的话找出干扰点,进行干扰 排除 2、 下行干扰 分析方法:路测数据 分析小区是否存在摸3情况,对于导频污染 3、 上行网内干扰 分析方法:上行频谱扫描、上行干扰实时监测(100PRB)、话统

分析参数是否设置合理,和上行干扰效相关的参数主要有 PassLossCoeff (路径损耗因子)和 PUSCH 标称 P0 值,这两个参数是控制 UE 发射功率的,这两 个值设置越大,UE 的发射功率越大,对其他小区的干扰也就越严重,需要参看 参数是否设置合理
参数 PassLossCoeff P0NominalPusch 建议值
0.7 -67

3.1.5 流程交互失败
一些需要信令交互的流程,如CQI上报周期、MIMO模式、SRS、ANR流程等,这些流 程往往常常会由于无线环境的原因, eNodeB与终端侧兼容方面的原因或者UE本身的问题导
2017-2-21 华为保密信息,未经授权禁止扩散 第 44 页, 共 119 页

文档名称

文档密级

致流程失败,最后导致掉话。 VoLTE相比普通业务需要建立/修改/删除QCI1的专有承载,当切换和QCI1专有承载修 改/建立/删除冲突时,可能导致QCI1对应的NAS流程失败,导致掉话。 这类问题需要针对特定的流程进行分析,特殊情况特殊处理,没有一般性的处理方法。 从参数方面,需要关注下面几个参数的设置:
参数 建议值

UuMessageWaitingTimer X2MessageWaitingTimer S1MessageWaitingTimer

35s 20s 20s

3.1.6 其他异常分析
传输问题(S1、X2口复位、闪断等) eNB故障(单板复位、射频通道故障等) UE故障等(UE死机、发热、版本缺点等) 在排除了以上的原因之后, 其他的掉话一般需要怀疑是否是设备存在问题, 需要通过查 看设备的日志文件,告警信息等进一步来分析掉话原因。 比如:eNodeB基带板内存泄露导致在发起小区资源核查时释放用户导致掉话; 比如:友商核心网重启导致的eRAB异常释放。 还有在路测过程中易引起路测终端过热/死机,或者连线脱落/掉电导致的掉话。 通常eNodeB侧的告警可通过在M2000侧进行观察,对于每个告警,都有相关的处理建 议,可通过M2000的在线帮助进行阅读。如下图所示:

2017-2-21

华为保密信息,未经授权禁止扩散

第 45 页, 共 119 页

文档名称

文档密级

图15 M2000告警浏览界面

3.2 常见掉话场景日志分析 3.2.1 场景1:SRB RLC重传达到最大次数掉话
掉话原因: SRB RLC重传达到最大次数掉话 日志分析: 1)上行大量误码,RSRP小于-140,分析是由于下行覆盖差,终端没有解调到控制信道,导 致终端没有发数。 2)入网后,CQI波动较大,14:55:22的CQI突降,终端无法正确解调下行控制信道,导致掉 话。

2017-2-21

华为保密信息,未经授权禁止扩散

第 46 页, 共 119 页

文档名称

文档密级

结论: 弱覆盖,导致UE未解调UL Grant,从而掉话

3.2.2 场景2:DRB RLC重传达到最大掉话
掉话原因: DRB RLC重传达到最大掉话。 日志分析: 1) 初传下发了ulGrant,但是没有检测到终上行数据 2)继续调度UE,连续检测不到数据 3)从上行RSRP看,都很低,掉话前CQI很差,波动很大,基本确认是由于下行UE没有解调 ulGrant

2017-2-21

华为保密信息,未经授权禁止扩散

第 47 页, 共 119 页

文档名称

文档密级

结论: 弱覆盖,导致UE未解调UL Grant,从而掉话

3.2.3 场景3:CCE受限
掉话原因:
2017-2-21 华为保密信息,未经授权禁止扩散 第 48 页, 共 119 页

文档名称

文档密级

CCE受限 日志分析: 用户入网后,80%以上的上行调度由于CCE个数不足的失败(错误码41484),终端因此掉 话。掉话时CQI好。

结论:
2017-2-21 华为保密信息,未经授权禁止扩散 第 49 页, 共 119 页

文档名称

文档密级

CCE不足导致掉话

3.2.4 场景4:重同步失败掉话
掉话原因: 失步掉话 日志分析: 1)UE在失步(20:44:54),尝试重同步,但到20:45:05掉话时,一直没有重同步成功。 2)终端入网后,CQI差且波动大持续到掉话前

2017-2-21

华为保密信息,未经授权禁止扩散

第 50 页, 共 119 页

文档名称

文档密级

结论: 弱覆盖导致掉话

3.2.5 场景5:空口定时器超时掉话
掉话原因: 最后一条重配之后35秒掉话,为空口等待重配完成超时导致掉话(空口等待定时器35秒) 日志分析: 1)最后一次重配(57443)的下行调度,终端已反馈ACK 2) eNodeB下发ulGrant,分配上行调度资源,开始检查UE响应RRC重配置完成,但是基站 检测到终端上行RSRP很低,说明没有发送上行数据 3)掉话前CQI很差,波动较大,所以基本确定终端没有收到ul grant

2017-2-21

华为保密信息,未经授权禁止扩散

第 51 页, 共 119 页

文档名称

文档密级

结论: 弱覆盖,导致UE未解调UL Grant,从而掉话

4 经典案例集
4.1 【案例 1】由于上行弱覆盖导致掉话指标恶化

【问题描述】 G局点无线掉话率当前为0.16%-0.17%,同城友商约为0.10%,两家站点数相当。华为共652 站1760小区,主要覆盖主城区及2个乡镇,友商主要覆盖两个县城。全省共14个地市,华为 有8个,其中G局点排名倒数,急需提升指标。 【问题结论】 G局点无线掉话率差主要由于农村区域指标差导致,并且有部分站点由于切换失败导致掉话。 通过对农村区域的3个Top小区以及覃塘区域的1个Top小区的分析,发现掉话的主要原因为 上行弱覆盖或者上行信号陡降。这些小区都有用户位于或者超出小区边缘,需要控制覆盖。 未发现异常终端、异常用户、MME等问题,没有明显Top小区,为整网性问题。 【解决方案】 1、 RF优化,控制覆盖; 2、 切换失败Top小区排查(邻区漏配、单向邻区、超远覆盖等); 3、 客户同意后,提升最低接收电平(小区选择和小区重选); 4、 客户同意后,降低异系统重选门限,在覆盖较差区域及时重选到异系统; 5、 全网修改S1等待定时器到200s;
2017-2-21 华为保密信息,未经授权禁止扩散 第 52 页, 共 119 页

文档名称

文档密级

6、 每天密切关注告警、干扰、Top小区等异常情况; 7、 其他的可能提升覆盖的参数或措施。 【分析过程】 话统分析 全网话统分析 近几天全网话统指标统计如下:

上表解读: 1)E-RAB异常释放次数小于上下文异常释放次数,4.8日为例,E-RAB异常释放14335次, 而上下文异常释放47063次,约为E-RAB的3.28倍。正常情况下,这两个次数应该相接近。 对于这种上下文发生掉话而E-RAB没有发生掉话,可能的情况及应对措施见3.1节。 2)上下文异常掉话中,约10%为切换失败导致,90%为空口原因导致。E-RAB异常掉话中, 约24%为切换失败导致,76%为空口原因导致。需要进一步排查存在Top小区。 分区域话统分析 由于空口原因导致占比较大,针对G局点全市按照覆盖类型进行统计,小区数如下:

行标签 港北区 港南区 高速公路 高速路 高铁 共址站 农村 市区 覃塘区 乡镇
2017-2-21

计数项:小区覆盖类型 579 125 6 9 2 1 631 3 68 288
华为保密信息,未经授权禁止扩散 第 53 页, 共 119 页

文档名称

文档密级

一般城区 一般市区 总计

3 15 1730

各个场景对应的指标如下:

求和 求和 项:eNode 求和 项:UE Context 异常释放 次数 项:eNode B发起的 B发起的 原因为切 原因为UE 换失败的 LOST的UE UE Context Context 释放次数 释放次数 港北区 港南区 高速公路 高速路 高铁 共址站 农村 市区 覃塘区 乡镇 一般城区 一般市区 (空白) 总计 329449 260895 32039 203263384 1777242 109000 21566 714 1105 1538 37 110275 783 18678 63337 365 2051 94538 18680 618 621 883 36 83305 664 9701 49880 312 1657 7744 1447 73 415 558 0 12180 80 1168 8192 40 142 95545042 16686531 99699 441113 296236 189403 47674987 882319 8621703 30473635 442417 1910299 792993 145937 854 3436 1947 1929 471552 7075 71779 258277 4545 16918 0.11% 0.13% 0.71% 0.25% 0.52% 0.02% 0.23% 0.09% 0.21% 0.21% 0.08% 0.11% #DIV/0! 0.16% 次数 个数 立成功总 Context Context建 留UE 率 求和项:UE 小区遗 无线掉话 求和项:

2017-2-21

华为保密信息,未经授权禁止扩散

第 54 页, 共 119 页

文档名称

文档密级

上表解读: 1)高速站点较少,可以忽略; 2)市区(港北区、港南区)掉话基本达标; 3)农村、乡镇区域掉话次数和掉话率均最高,影响整网指标。 因此, 掉话应重点针对农村区域进行分析, 可能的原因为农村区域站间距大, 导致覆盖不足, 有可能引起弱覆盖掉话、切换失败掉话。 小区级话统分析 分别按照切换失败导致的掉话和Ue lost的掉话进行小区级话统统计。 切换失败导致掉话 针对切换失败导致的掉话,汇总全网一共32039次,但Top30小区就有10110次,占比1/3,具 有明显Top小区现象。并且,Top小区主要为农村及乡镇站点,这和覆盖关系较大。

针对切换失败导致的掉话,需要核查邻区配置是否出现单向邻区、冗余邻区、PCI冲突或混 淆、邻区漏配、超远邻区等异常情况,以及是否存在Top两两小区切换对。这个需要一线工
2017-2-21 华为保密信息,未经授权禁止扩散 第 55 页, 共 119 页

文档名称

文档密级

程师逐一排查。如果排除上述原因,要重点关注是否弱覆盖导致的切换失败。 相关优化建议有: 1) 最小接收电平由-124调为-120(全网乡镇及郊区) 2) 盲重定向门限由-124至-122(全网) 3) 关闭测量重定向:GeranA2ThdRsrpOffset从0改为-100 4)超远邻区核减(大于7KM以上的按照两两切换次数删除) 5)邻区漏配核查(城区按照1.5KM, 郊区及乡镇按照小于2.5KM添加) 6)单向邻区、冗余邻区、PCI冲突核查。 空口原因(Ue lost)导致的掉话 全网汇总共计260895次,前30小区共计51311次,占比1/5,Top小区不明显。

Top小区分析 内部释放原因统计
2017-2-21 华为保密信息,未经授权禁止扩散 第 56 页, 共 119 页

文档名称

文档密级

对5个站点C.H.R日志进行汇总统计, 内部释放原因主要为RLC复位, 还有少量等待上下文超 时:

对于等待上下文超时,一次典型信令如下,为UE向MME发送S1AP_INITIAL_UE_MSG后, 始终没有收到MME发送的“上下文建立请求消息”,导致eNodeB的S1定时器超时上下文释放 掉话,但是注意,此时并没有发起E-RAB建立,因此并不统计E-RAB掉话,这就会导致2.1 节看到的上下文掉话次数比E-RAB掉话次数多。 优化建议:全网拉长S1定时器时长S1MessageWaitingTimer到60s。 异常信令如下:

正常的信令是下面这样,给MME发消息后,MME回复上下文建立请求,然后才能建立成下 文及E-RAB。如果MME不下发,就会记为上下文掉话(上面那种情况)。
2017-2-21 华为保密信息,未经授权禁止扩散 第 57 页, 共 119 页

文档名称

文档密级

针对RLC掉话要结合小区具体统计,下面主要分析农村及乡镇站点情况。 G局点大玗镇 掉话原因主要为RLC复位及X2切换失败:

该站点覆盖分析,上行弱覆盖导致掉话占比52.73%,上行信号陡降导致掉话占比17.01%, 这两个都和覆盖密切相关。

该站点所有小区半径配置为4000米,但是掉话用户中有15.03%处于小区边缘,8.4%用户超 过小区半径。

2017-2-21

华为保密信息,未经授权禁止扩散

第 58 页, 共 119 页

文档名称

文档密级

总结: 掉话主要为上行弱覆盖,且边缘用户较多,需要控制覆盖。 参考优化建议:优化弱覆盖,可参考3.1.3节方法,或者压低天线方向角。 G局点港北庆丰镇-HLH 掉话原因主要为RLC及X2切换失败:

掉话中,超过76%为上行弱覆盖及上行信号陡降导致:

2017-2-21

华为保密信息,未经授权禁止扩散

第 59 页, 共 119 页

文档名称

文档密级

该站点所有小区半径配置为4000米,但是掉话用户中有15.65%处于小区边缘,7.7%用户超 过小区半径。

总结: 掉话主要为上行弱覆盖,且边缘用户较多,需要控制覆盖。 参考优化建议:优化弱覆盖,可参考3.1.3节方法,或者压低天线方向角。 G局点黄练龙山茶厂-HLH 掉话原因主要为RLC复位:

掉话中,81%为上行弱覆盖及上行信号陡降导致:

该站点所有小区半径配置为4000米,但是掉话用户中有11.73%接近小区边缘,1.64%用户位
2017-2-21 华为保密信息,未经授权禁止扩散 第 60 页, 共 119 页

文档名称

文档密级

于小区边缘。

总结: 掉话主要为上行弱覆盖,且边缘用户较多,需要控制覆盖。 参考优化建议:优化弱覆盖,可参考3.1.3节方法,或者压低天线方向角。 G局点覃塘大碑头-HLH 掉话原因主要为RLC复位及X2切换失败:

掉话中,超过74%为上行弱覆盖及上行信号陡降导致:

该站点所有小区半径配置为4000米,但是掉话用户中有5.32%位于小区边缘,6.08%用户超 过小区边缘。

2017-2-21

华为保密信息,未经授权禁止扩散

第 61 页, 共 119 页

文档名称

文档密级

总结: 掉话主要为上行弱覆盖,且边缘用户较多,需要控制覆盖。 参考优化建议:优化弱覆盖,可参考3.1.3节方法,或者压低天线方向角。

4.2

【案例 2】由于部分终端对 BF 不支持导致掉话恶化

【问题描述】 某局点从12日开始很多站点掉话率恶化严重,需要分析根因。 【问题结论】 1、 部分终端(尤其是酷派)对 BF 特性支持不好,eNodeB 下发了 BF 的测量配置后, 终端不响应,最终导致掉话; 2、 核心网没有及时下发初始上下文请求导致 eNodeB 侧等待 S1 响应定时器超时, 导致 掉话。 【解决方案】 1) 关闭 BF 算法,规避终端影响,提升掉话率; 20日晚上对两个站点关闭BF算法,掉话率大幅度改善,已经优于之前水平。

2017-2-21

华为保密信息,未经授权禁止扩散

第 62 页, 共 119 页

文档名称

文档密级

【分析过程】 话统分析 UE Context异常释放次数在参数修改增长非常明显,其中主要是eNodeB发起的原因为UE Lost的UE Context市场次数增长很明显。

2017-2-21

华为保密信息,未经授权禁止扩散

第 63 页, 共 119 页

文档名称

文档密级

信令分析 从信令里统计S1AP_UE_CONTEXT_REL_REQ的原因值,可以看出掉话的原因值有两种,
radio-connection-with-ue-lost和nas unspecified.其中UE Lost的掉话最多,占总掉话的70% 左右。 中天大厦统计结果: S1AP_UE_CONTEXT_REL_REQ原因 cause=user-inactivity; cause=ue-not-available-for-ps-service; cause=interrat-redirection; cause=radio-connection-with-ue-lost; cause=nas unspecified; 总数 39160 1454 939 107 47 释放类型 正常释放 正常释放 正常释放 异常释放 异常释放 69.4% 30.5% 比例

世纪泰华统计结果
S1AP_UE_CONTEXT_REL_REQ原因 cause=interrat-redirection; cause=ue-not-available-for-ps-service; cause=user-inactivity; cause=nas unspecified; cause=radio-connection-with-ue-lost; 总数 191 324 9634 8 24 释放类型 正常释放 正常释放 正常释放 异常释放 异常释放 25% 75% 比例

南湖住(未升级站点)
S1AP_UE_CONTEXT_REL_REQ原因 cause=interrat-redirection; cause=nas unspecified; cause=radio-connection-with-ue-lost;
2017-2-21

总数 254 24 28

释放类型 正常释放 异常释放 异常释放

异常释放比例

46% 54%
第 64 页, 共 119 页

华为保密信息,未经授权禁止扩散

文档名称

文档密级

cause=ue-not-available-for-ps-service; cause=user-inactivity;

558 15583

正常释放 正常释放

Nas Unspecified掉话分析 从信令上看,MME下发下行NAS消息(鉴权和NAS加密后)后,手机没有响应,没有回UL Information Transfer,因此eNodeB没有回UL NAS Transfer消息,20s后eNodeB收不到MME 的Initial Context Request消息。之后,手机发起UE Context释放请求,造成掉话,原因为nas unspecified。 目前问题的不正常点: MME收到eNodeB的Initial UE Msg后超过9s才下发NAS消息(DL NAS TRANS),这个很不 正常。正常的就几十毫秒,核心网就会下发NAS消息。核心网下发时间长,容易导致无线侧 的等待S1响应定时器超时, 造成UE Context异常释放; 从目前的信令看, 核心网9s后下发NAS 鉴权,无线侧必然掉话。 核心网没有下发初始上下文消息。 以上两点都不受eNodeB控制,需要核心网解释并分析。

2017-2-21

华为保密信息,未经授权禁止扩散

第 65 页, 共 119 页

文档名称

文档密级

16日下午修改 【等待S1响应定时器】 , 从20s修改为40s后, 掉话率明显改善。 修改这个参数, 主要改善的是这种nas掉话。

UE Lost掉话分析 掉话的主要原因是基站下发重配置消息(RRC_CONN_Reconfig)后,手机没有上报重配置 完成,最终基站侧定时器超时,导致掉话。 大部分掉话前的重配置消息都含有BF算法的现象,但手机并没有响应。。

2017-2-21

华为保密信息,未经授权禁止扩散

第 66 页, 共 119 页

文档名称

文档密级

从CHR看,主要是RLC重传超时及核心网释放导致的掉话很多。

eNode下发RRC重配置后,没有收到完成消息,RLC重传超时后释放链路。
2017-2-21 华为保密信息,未经授权禁止扩散 第 67 页, 共 119 页

文档名称

文档密级

从层2消息来看,eNodeB收到的反馈信息为HARQ_ACK,这表明基站下发的测量重配置消 息MS已经正确接收,但是终端并没有响应。

UE特征分析 通过对掉话的终端类型来看, 掉话主要终端FGI=FE0DD89C导致, 这款终端的型号是Coolpad 8720L;另外这款终端(FGI=FE0DD89E)也是酷派的一款。因此,酷派导致掉话的比例超 过了50%。在其它局点也发现Marvel芯片(酷派终端采用Marvel芯片)对BF特性不好导致掉
2017-2-21 华为保密信息,未经授权禁止扩散 第 68 页, 共 119 页

文档名称

文档密级

话恶化的现象。
UeFeature 14; FE0DD89C; 00E000000040; 00000000; 0000 14; FE0DD89C; 00E000000000; 00000000; 0000 24; 7F4FFE9A; 00E000000000; 00000000; 0564 14; FF0FFCB8; 00E000000000; 00000000; 0004 13; 7E0DF882; 00E000000000; 00000000; 0564 14; 7F4FFE9E; 00E000000000; 00000000; 0564 14; 7F4F1E84; 00E000000000; 00000000; 0004 14; FF0FFC98; 00E000000000; 00000000; 0004 24; 7F4FFE9E; 01E000000004; 00000000; 0564 24; 7FCFFE9A; 01E000000000; 00000000; 0564 24; 7F4FFE9A; 00E000000000; 00000000; 0164 14; 7F4FFE9A; 01E000000000; 00000000; 0564 14; FE0DD89A; 00E000000000; 00000000; 0000 14; FE0DD898; 00E000000000; 00000000; 0000 24; 7FCFFE9A; 00E000000000; 00000000; 0164 14; FE0DD89E; 00E000000040; 00000000; 0000 14; FF0FFC98; 01E000000000; 00000000; 0004 14; 7FCFFE9A; 01E000000000; 00000000; 0564 14; 7F4FDE84; 00E000000000; 00000000; 0004 24; 7F4FFE9A; 01E000000000; 00000000; 0564 14; 7F4FFE9E; 01E000000000; 00000000; 0564 14; FF4FFE98; 00E000000000; 00000000; 0564 13; CF4FDE84; 00E000000040; 00000000; 0144 14; 7F4FDE84; 01E000000000; 00000000; 0764 14; FF4FFE98; 01E000000000; 00000000; 0564 24; 7F4FFE9E; 00E000000044; 00000000; 0164
2017-2-21 华为保密信息,未经授权禁止扩散

计数 317 92 42 38 31 29 26 26 25 23 22 22 17 16 13 13 13 9 6 6 5 5 3 3 3 2

比例 38.1% 11.1% 5.1% 4.6% 3.7% 3.5% 3.1% 3.1% 3.0% 2.8% 2.6% 2.6% 2.0% 1.9% 1.6% 1.6% 1.6% 1.1% 0.7% 0.7% 0.6% 0.6% 0.4% 0.4% 0.4% 0.2%
第 69 页, 共 119 页

文档名称

文档密级

14; 7F4F1E84; 00E000000000; 00000000; 0364 14; FF4FFE9E; 00E000000040; 00000000; 0764 24; 7F4FDE84; 00E000000000; 00000000; 0004 24; 7F4FFE86; 00E000000000; 00000000; 0164 24; 7E4FFA9A; 00E000000000; 00000000; 0560 24; 67CFFE9E; 00E000000000; 00000000; 0164 14; FF4FFE9E; 010000000005; 00000083; 0560 24; 7ECFFA9A; 00E000000000; 00000000; 0160 24; 7FCFFE9E; 012000000005; 00000013; 0560 14; FF4FDE84; 010000000004; 00000001; 0360 24; 7F4FFE9E; 00E000000000; 00000000; 0164 13; 7F0FFC86; 01E000000000; 00000000; 0004

2 2 2 2 1 1 1 1 1 1 1 1

0.2% 0.2% 0.2% 0.2% 0.1% 0.1% 0.1% 0.1% 0.1% 0.1% 0.1% 0.1%

操作日志分析 12日凌晨除了基站升级135外,还修改了大量的ATU参数。但基本可以排除这些操作对掉话 的影响,因为未升级站点的指标也恶化很明显。

2017-2-21

华为保密信息,未经授权禁止扩散

第 70 页, 共 119 页

文档名称

文档密级

4.3

【案例 3】由于 TAU 拒绝引起掉话恶化问题

【问题描述】 W 局点反馈全网无线掉线率从 25 日凌晨 1:00 开始出现恶化,客户需要分析具体的恶化原因

【问题结论】
由于核心网 TAU 拒绝携带#15 原因值,会导致 TA 禁止列表中加入该 TAC,后续终端在不 重启/拔卡/12~24 小时不删除该列表的情况下,则终端无法正 常接入到该 TAC 下的小区;
2017-2-21 华为保密信息,未经授权禁止扩散 第 71 页, 共 119 页

文档名称

文档密级

如果该终端从可用的 TAC 小区切换到禁止的 TAC 小区下, 则会出现切换完成后终端在目标 掉线的问题

【解决方案】
无,只能终端侧重启/拔卡/12~24 小时后解除禁止列表后恢复 【分析过程】

1.1 操作分析 凌晨时间段存在传输的操作,但无线侧网络无任何操作;

图 1 操作日志

1.2 掉线话统分析 掉线从 25 日凌晨 1 时出现的抬升的趋势,掉线的原因为无线层原因;

2017-2-21

华为保密信息,未经授权禁止扩散

第 72 页, 共 119 页

文档名称

文档密级

图 2 掉线率恶化趋势 1.3 详细分析 1.3.1 eNodeB 信令分析 1) 通过信令分析发现,掉线都是发生在切换成功后,目标 eNodeB 下发重配置消息 后,UE 没有响应导致的掉线

图 3 掉线信令 2)从 Initial UE MSG 中可以发现 TAU 前 UE 驻留的 TAC 为 7021,从数据配置中 发现当前该小区的 TAC 为 7023,说明此终端在 TAC 的边界活动;

图 4 TAC 分析 1.3.2 核心网侧 TAU 失败分析
2017-2-21 华为保密信息,未经授权禁止扩散 第 73 页, 共 119 页

文档名称

文档密级

通过分析核心网侧 TAU 失败的话统,发现在问题时间段出现了大量的 TAU Reject, 拒绝原因为#15 原因值;当携带#15 原因值的 TAU reject/Attach reject/Service reject,此时 UE 会将当前 TAI 记入 forbidden TA 列表,UE 可以在其他 TA 区域 内搜索合适的小区进行接入:

图 5 TAU 失败分析 1.3.3 协议规定的流程: 1) 下图为协议规定的 TAU 的信令流程, 从该流程图可以看出无线在整个 TAU 的过程中只是对 NAS 消息进行透传,eNodeB 不做任何处理;

2017-2-21

华为保密信息,未经授权禁止扩散

第 74 页, 共 119 页

文档名称

文档密级

图 6 协议 TAU 流程 2) 终端在发起 Initial NAS 流程(TAU/Attach/Service request)时,MME 可能因为网络侧异常,而发送携带#15 原因值的 TAU reject/Attach reject/Service reject,此时 UE 会将当前 TAI 记入 forbidden TA 列表,UE 可 以在其他 TA 区域内搜索合适的小区进行接入:

2017-2-21

华为保密信息,未经授权禁止扩散

第 75 页, 共 119 页

文档名称

文档密级

3) TA forbidden 列表会在 UE 关机/USIM 卡移除/UE 内部维护的周期定时器 (12~24 小时间)超时后,才会清除掉

4) 而后处于该 forbidden TA 边界区的 UE 可能接入到相邻的 TAC 小区中进 行业务,但 forbidden TAC 的邻区信号在满足条件后,UE 会在连接态切换到 forbidden TAC 的邻区,切换到目标邻区(UE 在目标小区发送切换完成消息 RRCConnectionReconfigurationComplete)后,搜索目 标小区的 SIB(含 TAI 信息)后,才发现该小区属于 forbidden TA 小区,所以,UE 自行掉网离开了目 标小区,导致目标小区掉话。协议规定 UE 是在切换完成后,才发起 SIB 消息捕 获:

5.3.5.4 Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE (handover)
2017-2-21 华为保密信息,未经授权禁止扩散 第 76 页, 共 119 页

文档名称

文档密级

TAI 信息是在 SIB1 消息中发送的: 5) 流程示意图如下:

4.4

【案例 4】由于终端不支持 FDD 到 TDD 切换导致掉话恶化

【问题描述】 某局点为FDD和TDD共主控站点, 在激活一个月左右后发现掉话率ErabDrop逐渐升高问 题,如下所示:

2017-2-21

华为保密信息,未经授权禁止扩散

第 77 页, 共 119 页

文档名称

文档密级

【问题结论】 信令流程分析发现在TOP终端(支持TDD到FDD的测量,但不支持TDD到FDD的切换)在收到 eNodeB下发的到FDD的测量控制消息后 (由RRC Reconfiguration消息携带) , 会导致多次RRC 重建,之后发生MME异常释放,进而贡献掉话 【解决方案】 现网所用版本为V100R010C10SPC120,经确定V100R010C10SPC190版本已修复此问题,即 eNodeB识别出UE能力支持到FDD的测量,不支持TDD向FDD切换时,eNodeB不会向这个UE下发 TDD频点的测量控制,进而不会导致掉话,故可升级版本解决。 但在SPC190版本中相关开关默认是关闭的,需要人为打开此开关,命令如下: 方案生效: MOD ENBRSVDPARA: RsvdSwPara3=RsvdSwPara3_bit6-1; 【分析过程】 此局点要求的掉话话统定义如下,包含了L.E-RAB.AbnormRel.MME的次数: 100%*(L.E-RAB.AbnormRel+L.E-RAB.AbnormRel.Mme)/(L.E-RAB.normRel+ L.E-RAB.AbnormRel) 分析话统发现,掉话的主要贡献来自MME异常释放:

CHR分析 从高峰时间点的CHR分析,存在top终端,如下所示:
2017-2-21 华为保密信息,未经授权禁止扩散 第 78 页, 共 119 页

文档名称

文档密级

从TOP终端的FGI分析此终端的能力,发现Top终端支持TDD到FDD测量,但不支持到 FDD的切换,如下解释:

4.5

【案例 5】由于异常终端导致掉话恶化

【问题描述】 XX局点有部分站点掉话率非常高,需要分析问题根 【问题结论】 这些站点98%以上的掉话都是由于天迈L818 (T-smart L818) 和三星S5 (SM-G9008W) 导致, 这两款终端对eNodeB下发的重配置消息无响应导致掉话。 【解决方案】 最终解决方案需要客户推动终端厂家解决。临时规避措施如下: 关闭SRS功控:MOD CELLALGOSWITCH: SrsPcSwitch-0; 固定传输模式为TM2:MOD BFMIMOADAPTIVEPARACFG: BfMimoAdaptiveSwitch=NO_ADAPTIVE, FixedBfMimoMode=TM2; 【分析过程】
2017-2-21 华为保密信息,未经授权禁止扩散 第 79 页, 共 119 页

文档名称

文档密级

话统分析 分析了海阳综合楼和恒丰银行的数据, 这个站有两个小区的掉话率非常高, 忙时掉话率达到 20%~70%。。

从掉话原因分布来看,主要是无线层的UE LOST掉话。

CHR分析 掉话原因主要为RLC重传达到最大次数而导致的掉话。

从掉话的终端分布来看,大部分掉话(超过98%)都是由于FGI= FF4FFE9C的终端导致的, 而其它终端的掉话正常。有明显的异常终端导致掉话的特征。掉话排名第二的是FGI= FF4FFE18的终端。

2017-2-21

华为保密信息,未经授权禁止扩散

第 80 页, 共 119 页

文档名称

文档密级

从信令里可以看到FGI= FF4FFE9C终端的IMEI为: 86391302XXXXX.从工信部的网站可以查 到,这款终端为天迈手机,具体型号为:T-smart L818。

2017-2-21

华为保密信息,未经授权禁止扩散

第 81 页, 共 119 页

文档名称

文档密级

恒丰银行分析: 恒丰银行主要是由于两款终端导致, 这两款终端和海阳综合楼的前两款终端一样, 这两狂终 端的比例超过97%。只不过这个站FGI= FF4FFE18排第一位。

通过信令分析,FGI= FF4FFE18终端的IMEI为352XXXXXX5100,在工信部网站上可以查到
2017-2-21 华为保密信息,未经授权禁止扩散 第 82 页, 共 119 页

文档名称

文档密级

这款终端为三星S5:SM-G9008W。

信令分析 从信令里统计S1AP_UE_CONTEXT_REL_REQ的原因值,可以看到都是UE LOST掉话。
从信令流程看,掉话特征类似,都是eNodeB下发重配置消息后(RRC_CONN_DECFG),没有收到手 机的重配置完成消息(RRC_CONN_RECFG_CMP).

2017-2-21

华为保密信息,未经授权禁止扩散

第 83 页, 共 119 页

文档名称

文档密级

另外,所有掉话前的最后一个重配置消息都包含SRS功控消息,因此建议一线先关闭SRS功 控观察: MOD CELLALGOSWITCH: SrsPcSwitch-0

2017-2-21

华为保密信息,未经授权禁止扩散

第 84 页, 共 119 页

文档名称

文档密级

关闭SRS功控后,指标改善有限。分析关闭SRS功控后的信令,发现掉话前的重配置都包含 传输模式。因此,建议一线固定传输模式为TM2,减少重配传输模式: MOD BFMIMOADAPTIVEPARACFG: BfMimoAdaptiveSwitch=NO_ADAPTIVE, FixedBfMimoMode=TM2;

2017-2-21

华为保密信息,未经授权禁止扩散

第 85 页, 共 119 页

文档名称

文档密级

传输模式修改为TM2后,掉话率大幅度改善。

4.6

【案例 6】由于小区边缘用户增加导致掉话恶化

【问题描述】 C国Z局点一线工程师监控指标发现, 4月3号开始, 华为区域无线掉线率比平时恶化0.01%; 进一步监控4月4号9点到17点小时级指标, 发现掉线率最高高达0.16%。 统计无线掉线原因, 发现从4月3号开始,ENODEB发起的原因为无线层问题的UE CONTEXT释放次数比原来增 加3万次左右,其中UE-LOST原因导致的UE CONTEXT释放次数增加2万次左右。详细指标 见下表:

2017-2-21

华为保密信息,未经授权禁止扩散

第 86 页, 共 119 页

文档名称

文档密级

【问题结论】 假期某著名景点地区用户数大幅增加,同时小区边缘用户增加明显,话务模型变化,掉话 恶化。 【解决方案】 假期结束后,随着游客离开,指标自行恢复。 【分析过程】 1. 话统分析 考虑到指标恶化时间点正处于清明节假期第一天,再考虑到该局点旅游资源丰富。依据X板 斧“外部事件排查”原则,对该局点分地区进行指标统计,结果如下图,可以看到指标恶化主 要集中在景点较多的某个地市,而市区和大部分县城并没有恶化或者恶化很小。 因此,初步判定掉话恶化主要和假期用户数猛增有关。

2. Top 小区分析 在Top地区中选取一个掉话恶化的Top小区进行分析。 2.1 Top小区话统分析 该站点掉话在4号增加:

2017-2-21

华为保密信息,未经授权禁止扩散

第 87 页, 共 119 页

文档名称

文档密级

同时用户数也有增长:

远点用户数4号增长明显:

结果是在4号,上下文建立次数和掉话次数都有增加:

干扰比较平稳:

2017-2-21

华为保密信息,未经授权禁止扩散

第 88 页, 共 119 页

文档名称

文档密级

上下行误码率在4号都有增加:

平均下行CQI在4号出现下降,这和远点用户增加有关:

关联指标方面,RRC和E-RAB也都有恶化:

2017-2-21

华为保密信息,未经授权禁止扩散

第 89 页, 共 119 页

文档名称

文档密级

分析结论: 用户数增加,尤其远点用户增加,导致RRC、E-RAB、掉话均恶化。 2.2 C.H.R分析 对4号当天的C.H.R进行统计,掉话主要原因为RLC复位,这和空口有关:

进一步统计,发现90%掉话是上行弱覆盖及信号陡降导致,这说明掉话确实都是空口条件 不好导致:

在结合掉话用户分布,87%掉话用户分布在4500米以外:

2017-2-21

华为保密信息,未经授权禁止扩散

第 90 页, 共 119 页

文档名称

文档密级

而该小区半径配置为5000m,因此4500m就已经是相当远的距离了,并且大部分掉话集中 在小区边缘。

结论: 4号掉话恶化,是由于远点用户增多,尤其小区边缘用户增加明显。这可能和节日有关, 预计节日结束后,指标可以恢复。 3. 指标恢复 截止4.7日(节后第一天),掉话指标已经恢复,符合上面分析的预期。

从分地区来看,截止节后第一天(7号),所有地区掉话指标均已恢复。

2017-2-21

华为保密信息,未经授权禁止扩散

第 91 页, 共 119 页

文档名称

文档密级

4.7

【案例 7】由于终端在非 DRX 状态下 SRI 周期和异频 GAP 冲突导致掉话

【问题描述】 X局点生活基地开通3个D频段小区后,掉线率一直居高不下(最高时超过2%,每天掉 线次数达到7000次,对全网指标影响较大),话统中掉线原因主要为SRB RLC复位导致的 激活的E-RAB异常释放(RLC达到最大重传次数导致的掉话),另外共站的4个F小区掉线没 有问题,该站点其他指标均正常:

2017-2-21

华为保密信息,未经授权禁止扩散

第 92 页, 共 119 页

文档名称

文档密级

【问题结论】 该站点在高话务量情况下,终端SRI和GAP测量冲突导致eNodeB侧RLC重传超出最大次 数引发掉线。 高话务场景下,掉线率高的同时小区最大用户数也较高。由于SR资源承载在PUCCH上 发给eNodeB,而PUCCH资源有限,当用户数上升时,因此为了保证用户接入用户,SR资源 配置周期相应拉长,由10/20ms变为40/80ms。但配置为40/80ms时会概率性与GAP测量配置 资源重叠,导致终端无法发送SR,因此eNodeB侧在RLC重传超出最大次数后触发掉线。 【解决方案】 扩容增加小区 【分析过程】 该站点D频段小区的RRC建立、E-RAB建立、切换成功率指标都正常:

2017-2-21

华为保密信息,未经授权禁止扩散

第 93 页, 共 119 页

文档名称

文档密级

CHR、信令及其他分析 掉线CHR分析结果显示,98.9%的掉线原因为 UEM_UECNT_REL_UE_RLC_UNRESTORE_IND,也即RLC达到最大重传次数的掉线,该 原因一般以无线口因素居多:
Error No. Code 1 2 3 4 5 6 7 8 9 10 11 58 39 60 34 116 128 16 129 13 74 53 UEM_UECNT_REL_UE_RLC_UNRESTORE_IND UEM_UECNT_REL_MME_CMD UEM_UECNT_REL_UE_RESYNC_DATA_IND_REL_CAUSE UEM_UECNT_REL_RRC_REEST_SRB1_FAIL UEM_UECNT_REL_LAST_DRBS_RLC_UNRESTORE_IND UEM_UECNT_REL_HO_OUT_INTRA_FREQ_X2_REL_BACK_FAIL UEM_UECNT_REL_RB_CFG_FAIL_UE_NO_REPLY UEM_UECNT_REL_HO_OUT_INTER_FREQ_X2_REL_BACK_FAIL UEM_UECNT_REL_USER_ABNORMAL UEM_UECNT_REL_PDCP_INTEG_CHECK_FAIL_IND UEM_UECNT_REL_WAIT_RRC_CONN_RECFG_RSP_TIMEOUT 华为保密信息,未经授权禁止扩散 16109 73 41 18 16 14 6 4 3 2 2 Inner Release Cause Times Drop) 98.90% 0.45% 0.25% 0.11% 0.10% 0.09% 0.04% 0.02% 0.02% 0.01% 0.01% 第 94 页, 共 119 页 Percentage(Call

2017-2-21

文档名称

文档密级

Time 2015-04-06

ulCallId

Type

InnerRelCause

10302517 12:30:38(701) 2015-04-06 537260106 13:24:57(956) 2015-04-06 27074097 15:53:09(659) 2015-04-06 27079111 16:30:01(747) 2015-04-06 27086489 17:20:49(038) 2015-04-06 10349612 17:51:23(660) 2015-04-06 805705953 18:26:06(166) 2015-04-06 805708234 19:17:30(507) 2015-04-06 10366357 19:23:25(608) 2015-04-06 42204844 19:38:41(238)

L2_CHR_USER_RLC_RETX_INFO

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

L2_CHR_USER_RLC_RETX_INFO

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

L2_CHR_USER_RLC_RETX_INFO

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

L2_CHR_USER_RLC_RETX_INFO

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

L2_CHR_USER_RLC_RETX_INFO

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

L2_CHR_USER_RLC_RETX_INFO

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

L2_CHR_USER_RLC_RETX_INFO

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

L2_CHR_USER_RLC_RETX_INFO

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

L2_CHR_USER_RLC_RETX_INFO

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

L2_CHR_USER_RLC_RETX_INFO

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

空口上行掉线原因中, 上行弱覆盖及上行电平陡降的比例分别为14.54%及11.84%, 其他 原因占比73.51%,说明上行覆盖不是掉线高的主要原因:
UL Radio Condition UL Weak Coverage UL Interference UL Signal Instant Deterioration CallDropTimes 269 2 219 Percent 14.54% 0.11% 11.84%

2017-2-21

华为保密信息,未经授权禁止扩散

第 95 页, 共 119 页

文档名称 Others 1360

文档密级 73.51%

进一步分析,掉线全部发生在UE非DRX状态:

掉线用户距离大部分在1km范围内,分布较集中:
Distance(m) 0~468 468~936 936~1404 1404~1872 1872~2808 2808~3744 3744~4680 4680~6084 6084~7488 7488~8892 8892~10764 10764~12636 12636~14508 14508~14586 Counts 889 284 103 28 7 2 0 0 0 0 0 0 0 0 Percent 67.71% 21.63% 7.84% 2.13% 0.53% 0.15% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%

从掉线涉及较多的终端类型来看,基本上可排除由于个别异常终端导致的掉线:
2017-2-21 华为保密信息,未经授权禁止扩散 第 96 页, 共 119 页

文档名称

文档密级

FGI

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND

占比

终端类型 OPPO Find7 X9077

7F4FFE9A

616

26.10% Samsung S5

7F4FFE9E 7FCFFE9A 7E0DF882 FF4FFE98

538 446 249 143

22.80% 18.90% 10.55% 6.06%

iPhone6 A1586 未知 iPhone 5S 未知

分析问题小区的最大用户数和掉线次数的关系, 发现二者趋势很吻合, 怀疑与用户数过 多有关:

怀疑是切换时电平相对偏低,无线原因导致掉线。进一步查看D频段小区配置:3个D 频段小区的A2门限设置很低(-94),A4门限设置相对较高(-88/-85):

2017-2-21

华为保密信息,未经授权禁止扩散

第 97 页, 共 119 页

文档名称

文档密级

一方面,从CHR具体掉线时的RSRP分布来看,也存在部分低电平的掉线:

S1口的释放原因全部为UE LOST:

CHR查看具体的掉线原因,下行应该是正常的,因此怀疑主要是上行太弱导致的:

2017-2-21

华为保密信息,未经授权禁止扩散

第 98 页, 共 119 页

文档名称

文档密级

另一方面:从CHR记录的每次掉线来分析,掉线都具有同样的规律,在eNodeB异常释 放前给UE下发rrc conn reconfig消息后未收到终端的rrc conn reconfig cmp消息,导致掉线。 从rrc conn reconfig消息的内容来看都给UE下发了GAP测量配置,因此怀疑可能与SR(数据 发送请求)资源冲突导致基站侧未收到rrc conn reconfig cmp消息。 以callid为27432683的掉线为例:

掉线前最后一次rrc conn reconfig消息中给UE下发的GAP测量配置为gp0,对应现网配置
2017-2-21 华为保密信息,未经授权禁止扩散 第 99 页, 共 119 页

文档名称

文档密级

GAP_PATTERN_TYPE_1(也即GAP周期40ms,测量时间6ms),gapoffset为28,也即GAP 测量时间窗为[40*n+28,40*n+28+6]:

查看SRB2/DRB1建立时的rrc conn reconfig消息中的SR资源配置,sr-configindex为147:

根据协议36.213(见下表)可查询SR资源配置周期为80ms,SR调度偏置为147-75=72, 因此UE发送SR的时间点为80*n+72:

2017-2-21

华为保密信息,未经授权禁止扩散

第 100 页, 共 119 页

文档名称

文档密级

如下图所示: GAP测量周期覆盖SR调度周期, SR调度时间点72落在GAP测量时间窗内, 因此UE无法在配置的SR调度周期时间点发送rrc conn reconfig cmp消息,导致掉线:

举例2(callid为10702094的掉线): sr-configindex为97,对应SR调度时间点80*n+97-75=80*n+22:

GAP测量配置中,gapoffset为19,也即GAP测量时间窗为[40*n+19,40*n+19+6],SR调 度时刻正好落在GAP测量时间窗内:

2017-2-21

华为保密信息,未经授权禁止扩散

第 101 页, 共 119 页

文档名称

文档密级

综上所有分析,证实掉线为GAP测量及SR调度冲突导致。现网针对该问题依次做了如 下几个方面的优化: (1) 修改生活基地 3 个 D 频段小区的 A2(-94->80)及 A4 门限(-85->-92),修改后掉 线次数下降一半,但是个别时段仍然很高(8-11 点),说明不是切换参数设置以及 覆盖问题导致; (2) 开启 SRI 与 GAP 冲突优化开关,同时关闭 DRX,指标恢复正常; (3) 开启非 DRX 下 SRI 与 GAP 冲突优化开关并重新开启 DRX,指标仍正常。

4.8

【案例 8】由于修改 PagingSentNum 导致掉话恶化

【问题描述】 XX局点出现PagingSentNum设置次数与掉话率强相关的现象,当PagingSentNum设置大于1时
掉话率异常上升,改回为1后掉话率恢复正常;
2017-2-21 华为保密信息,未经授权禁止扩散 第 102 页, 共 119 页

文档名称

文档密级

前期分析发现掉话主要集中在同一款终端,UE Feature: 0x19C5A000C295327040B82E0BFF06EC4C 0x19C5A000C295327040B82E0BFF06EC4E 这款终端使用的是Marvell芯片, 终端型号包括Coolpad 8705、 Coolpad 8720L、 康佳 L823等。

下图为XX局点在PagingSentNum设置为2和1时的掉话率对比情况
8月21日完成 PagingSentNum从2改 为1

【问题结论】 使用Marvell芯片,UE Feature为0x19C5A000C295327040B82E0BFF06EC4C、 0x19C5A000C295327040B82E0BFF06EC4E的这类终端,在连接态下会响应二次寻呼,并发 起service-request,核心网无法响应连接态终端的service-request,T3417定时器超时后终端异 常释放进入IDLE,导致之前建立的连接掉话。 【解决方案】 将PagingSentNum更改为1 【分析过程】 下面以UE Feature:0x19C5A000C295327040B82E0BFF06EC4C、Call ID:1168275、TMSI: CB 09 10 B2的流程为例做简要分析:

终端在第一次寻呼时RRC已经建立: 第一次paging时间14:24:39(763),RRC_CONN_REQ时间14:24:39(806),服务小区为Cell 1;

2017-2-21

华为保密信息,未经授权禁止扩散

第 103 页, 共 119 页

文档名称

文档密级

2017-2-21

华为保密信息,未经授权禁止扩散

第 104 页, 共 119 页

文档名称

文档密级

连接态终端响应二次寻呼 在第一次寻呼消息发送1280ms后,无线测重发第二次寻呼消息(时间14:24:41(043)), 此时UE已经处于连接态。根据协议规定,对于寻呼域为PS的寻呼消息,只有在IDLE态的UE 才能发起service request;连接态的UE只有在收到CS fallback类的寻呼域为CS的寻呼消息才 能发起service request; 第二次寻呼消息的寻呼域为PS:

协议相关规定:

2017-2-21

华为保密信息,未经授权禁止扩散

第 105 页, 共 119 页

文档名称

文档密级

由于此时UE已经处于连接态,核心网对第二次上发的service-request-message未做响应;

2017-2-21

华为保密信息,未经授权禁止扩散

第 106 页, 共 119 页

文档名称

文档密级

UE在响应二次寻呼后的动作 UE在发送service-request-message后,会启动T3417定时器,由于此时UE已经处于连接态,核 心网对第二次上发的service-request-message未做响应;

协议规定T3417定时器为5s ;

T3417定时器超时后,协议规定将释放所有与service request相关的资源,之前建立的RRC连 接也被释放,UE进入IDLE; 协议相关内容:

2017-2-21

华为保密信息,未经授权禁止扩散

第 107 页, 共 119 页

文档名称

文档密级

网络侧对IDLE态的UE下发RRC_CONN_RECFG消息,终端无响应 UE在UL_NAS_TRANS消息5s后进入IDLE态, 无法对网络侧发起的RRC_CONN_RECFG进行响应, 导 致导致RLC重传达最大次数掉话; 下图可见在UE在UL_NAS_TRANS发送5s后,对RRC_CONN_RECFG无响应;

2017-2-21

华为保密信息,未经授权禁止扩散

第 108 页, 共 119 页

文档名称

文档密级

4.9

【案例 9】由于 X2 切换失败增加导致掉话恶化

【问题描述】 哈尔滨近段时间无线掉线率持续恶化,从话统指标趋势图看,一直呈上升趋势,现场初 步分析,未见明显TOP小区,客户已经关注,并要求华为给出恶化原因并尽快提升。

图16 无线掉话率趋势

一线已经执行的掉话率优化措施如下: 1.打开智能预调度 MOD CELLALGOSWITCH: LocalCellId=x, UlSchSwitch=

SmartPreAllocationSwitch-1; MOD CELLULSCHALGO: LocalCellId=x, SmartPreAllocationDuration=50;

2.打开SRI和GAP冲突优化开关: 1)针对关闭DRX的小区:MOD ENODEBALGOSWITCH:HoCommOptSwitch= BasedSriGapOptSwitch=1; 2)针对打开DRX的小区:MOD ENODEBALGOSWITCH:HoCommOptSwitch=DrxBasedSriGapOptSwitch;(eRAN8.1版本) 3.SRS功控开关MOD CELLALGOSWITCH: LocalCellId=1, UlPcAlgoSwitch=SrsPcSwitch-0; 4.修改GAP测量模式:GapPatternType=GAP_PATTERN_TYPE_2;
2017-2-21 华为保密信息,未经授权禁止扩散 第 109 页, 共 119 页

文档名称

文档密级

【问题结论】 在X2切换执行过程中,目标侧eNodeB捕获终端后,向MME发送通道转换请求消息, MME回复了通道转换失败,导致切换失败,在源侧eNodeB统计为切换失败导致的掉话,造 成掉话率恶化,MME回复通道转换失败原因需要MME侧进行分析。 【解决方案】 MME侧问题,需要MME侧分析通道转换失败次数增加的原因。 【分析过程】 无线掉话率恶化分析 经查询移动集团的无线掉话率计算公式如下: (eNodeB发起的S1 RESET导致的UE Context释放次数+ UE Context异常释放次数)/ (UE Context建立成功总次数+小区遗留UE上下文个数)100% 分析UE Context释放的相关话统,“eNodeB发起的S1 RESET导致的UE Context释放次数” 为0,而“UEContext异常释放次数”增加的原因主要由“eNodeB发起的原因为切换失败导 致的UE Context释放次数”贡献。

UE Context异常释放原因统计 分析无线掉线率与 “eNodeB发起的原因为切换失败导致的UE Context释放次数” 指标的关系, 如下图3所示,可见无线掉线率恶化主要是由于切换失败导致的Context释放导致。

2017-2-21

华为保密信息,未经授权禁止扩散

第 110 页, 共 119 页

文档名称

文档密级

无线掉话率与切换失败导致的Context释放次数 操作日志分析 从操作日志来看,站点进行的操作较多,9号左右掉话率的上升怀疑与如下参数修改相关, 修改了同频和异频MR上报的最大小区数,默认值应该分别为6和3,经与现场确认该参数是 优化MR指标的参数,该参数是修改周期性MR上报的小区数,虽然用于切换判决的MR从事 件MR会转为周期MR,但是这个参数对切换成功率的影响有限,并且不会出现持续恶化的 情况。

修改MR上报最大小区数操作日志 而后面时间段上现场执行ATU保障参数,期间多次执行和回退,经与一线确认之前现场也 多次执行过ATU保障措施,但是没有出现掉话率恶化的情况,确认与ATU保障参数执行关 系不大。

2017-2-21

华为保密信息,未经授权禁止扩散

第 111 页, 共 119 页

文档名称

文档密级

ATU保障措施操作日志 切换成功率恶化分析 分析现网的切换话统指标发现, 切换失败主要集中在切换执行阶段。 从反馈的切换入失败的 话统指标来看,“切换失败导致的UE上下文释放”与“eNodeB间模式内切换入path switch 失败次数”的增长趋势一致,说明切换失败主要是由于path switch失败导致。

MME发送通道转换失败的次数 其中:
eNodeB发起的原因为切换失败的UE Context释放次数 (无)= 小区eNodeB间模式内切换入通道转换请求次 2017-2-21 华为保密信息,未经授权禁止扩散 第 112 页, 共 119 页

文档名称 数 (无)- 小区eNodeB间模式内切换入通道转换成功次数 (无)

文档密级

而从TOP站的信令跟踪中 也发现了大量的MME发送S1AP_PATH_SWITCH_REQ_FAIL消 息的情况,如下图7所示,

TOP站切换失败信令跟踪 其典型信令流程图如图8所示,切换执行阶段,在目标侧 eNodeB收到终端上报的RRC Reconfiguration Complete消息后,向MME发送S1AP_PATH_SWITCH_REQ消息,但是4秒钟 后收到了MME下发的S1AP_PATH_SWITCH_REQ_FAIL消息,通道转换失败,引起切换失 败,源侧eNodeB统计为切换失败导致的掉话。

典型切换入失败流程图 由于全网MME回复通道转换失败的次数逐渐增多, 原因需要MME侧分析具体原因, 待MME 侧能正常响应通道转换请求消息后,切换成功率和掉话率均能恢复正常。

4.10 【案例 10】无线掉话优化问题
【问题描述】 哈尔滨精品网项目,项目开始初期无线掉话率在0.13%左右,当前由于核心网问题导致
2017-2-21 华为保密信息,未经授权禁止扩散 第 113 页, 共 119 页

文档名称

文档密级

的通道转换失败导致掉话率恶化,但是当前剔除通道转换失败的掉话率在0.15%左右,一线 诉求在此基础上优化到0.13%。
0.3000% 0.2500% 0.2000% 0.1500% 0.1000% 0.0500% 0.0000%

掉话率 去除通道转换失败的掉话率

【问题结论】 1.大部分掉话是由于弱覆盖、信号突衰导致。 2.切换失败导致掉话。 【解决方案】

【分析过程】
2017-2-21 华为保密信息,未经授权禁止扩散 第 114 页, 共 119 页

文档名称

文档密级

无线掉话率指标分析 当前现网存在MME异常导致通道转换失败,造成切换失败而掉话。在MME问题恢复后,掉 话指标能够有所好转,剔除掉核心网导致通道转换失败的原因,掉话原因占比如下:

9%

eNodeB发起的原因为 UE LOST的UE Context释 放次数 切换失败导致UE Context释放次数

91%

剔除通道转换失败的UE Context异常释放原因统计 掉话主要由UE LOST、切换失败2类原因构成。 根据TOP掉话站点日志,分析CHR中的掉话原因,CHR原因分为RLC最大重传次数释放(对 应UE LOST)、S1切换失败、X2切换失败三类:

6% 9%

UEM_UECNT_REL_LAST _DRBS_RLC_UNRESTOR E_IND UEM_UECNT_REL_HO_ OUT_INTRA_FREQ_X2_R EL_BACK_FAIL UEM_UECNT_REL_HO_ OUT_INTER_FREQ_X2_R EL_BACK_FAIL

85%

TOP掉话站点的CHR掉话原因分布 UE LOST导致掉话优化 根据TOP站点掉话用户的覆盖分析,掉话原因34.11%为弱覆盖,44.62%为信号突衰。

2017-2-21

华为保密信息,未经授权禁止扩散

第 115 页, 共 119 页

文档名称

文档密级

TOP掉话站点的CHR掉话原因 针对以上2种主要原因优化思路如下: 弱覆盖: 1)基础优化,参考【地区部移动TMO重要技术通知201515号】弱覆盖、重叠覆盖、室分泄 露优化指导书。 2)参数调整,限制弱覆盖用户接入(参考KPI优化checklist)。 3)参数调整,通过修改互操作门限,让4G弱覆盖用户切换到2G/3G(参数可能省公司或者 集团限制,一线可以在可调范围内调整)。 信号突衰: 主要包括进入电梯、小房间、遮挡等信号突然衰减场景,8.1版本无优化手段。 切换失败导致掉话优化 根据切换的相关话统,可以发现切换失败主因是切换执行失败。

2017-2-21

华为保密信息,未经授权禁止扩散

第 116 页, 共 119 页

文档名称

文档密级

TOP站点切换失败原因 排查切换参数,发现异频切换的A2/A4门限参数配置异常:全网90%的站点,A2和A4都配置 -90,其中部分小区A4比A2小-15左右,会导致终端异频切换到质差的异频小区,同时也会 导致乒乓切换。 切换参数需全网调整,消除此类不合理配置。建议A2配置在-92到-96之间,A4比A2高3到6 个db。 分析以下话统,切换过程中发送Msg2数量比收到msg3数量占比超出很多,这部分主要就是 目标侧未收到切换完成消息,这里并不全部引起切换失败,例如重建到了目标侧等。

TOP站切换阶段的随机接入话统 进一步分析用户行为: 从目标侧基站CHR中找出切换入失败的UE。
2017-2-21 华为保密信息,未经授权禁止扩散 第 117 页, 共 119 页

文档名称

文档密级

TOP站切换入失败用户信令跟踪

TOP站收到重建请求消息时上行覆盖情况

TOP站下发重建消息时上行覆盖情况
2017-2-21 华为保密信息,未经授权禁止扩散 第 118 页, 共 119 页

文档名称

文档密级

RRC_CONN_REESTAB消息下发时,发生HARQ_DTX,没有收到UE发ACK或NACK,测量 的上行SINR和RSRP较好。 由于切换失败时间点附近,空口上行质量较好,且CQI较差,所以基本可以确定终端没有收 到RAR是切换失败的主因,针对该问题可以尝试提升RAR功率进行优化。 优化建议下发 经核查,全网已下发《TD-LTE 话统KPI优化提升checklist V2.0》中的所有掉话优化参数, 针对TOP站点的分析,补充3个优化手段,可扩大验证范围,尝试推广。 手段1:针对切换指标差的站点,提升RAR功率,提升切换成功率,减少由于切换失败导致 的掉话,哈尔滨5个站点验证结果如下:

TOP站提升RAR功率后效果 手段2:针对弱覆盖较严重的站点,降低RAR功率,减少弱覆盖用户的接入(未验证)。 手段3:降低DeltaPreambleMsg3功率,减少弱覆盖用户的接入。

降低MSG3功率后的效果

2017-2-21

华为保密信息,未经授权禁止扩散

第 119 页, 共 119 页


相关文章:
TDD掉话问题处理指导以及案例集 -_图文.doc
TDD掉话问题处理指导以及案例集 - - 文档名称 文档密级 TDD掉话问题处理
TDD MR问题处理指导及典型案例集 20160504_图文.doc
TDD MR问题处理指导及典型案例集 20160504 - 文档名称 文档密级 TDD LTE MR类问题处理指导及典型案例集 拟审批 制: 核: 准: 员沛东/00334819 ...
顺序错掉话处理案例.doc
顺序错掉话处理案例 - “顺序错误”类型掉话处理案例 1、问题描述 在日常质差小区的持续性优化过程中,发现有绍兴孙端碧波庄园_1 小区出 现 TCH 掉话次数较多,...
GSM掉话案例集锦_图文.doc
GSM掉话案例集锦_信息与通信_工程科技_专业资料。...利用 TRX 基本测量处理 AFRIPA 站点高掉话问题 .....掉话的载频是否集 中在同一根馈线上面,如果是,就要...
掉话问题分析处理指导书-20020307-B-1.0.doc
掉话问题分析处理指导书-20020307-B-1.0_信息与...(3) 由设备故障等原因造成的掉话,例如案例八的详细...定向小区有主集分集两副天线时,该小区的 BCCH ...
移动LTE常见故障处理集.doc
常见案例处理集 华为技术有限公司 版权所有 侵权必究...故障处理指导书 文档密级 目录 1 配置类问题处理 ....FddTddInd=CELL_TDD, SubframeAssignment=SA2, Special...
LTE的掉话原因分析及处理思路(加精,值得收藏)_图文.doc
LTE 的掉话原因分析处理思路 LTE“掉话”是指 UE 异常退出 RRC_CONNECTED ...三、小结 本文结合呼市现网 LTE 掉话问题处理案例, 对外场 RF 优化、 网管 ...
掉话常见原因及案例介绍.doc
1.1.1 掉话常见原因及案例介绍 1.1.1.1 覆盖因素差导致的掉话在覆盖边缘...问题的症结在于导频复用距离小了,如果将 C 的导频更换,问题就可以得到解决。 ...
TD终端并发业务掉话问题案例分析_图文.doc
TD终端并发业务掉话问题案例分析 - 终端用户投诉TD网络掉话问题,经过信令跟踪以及CDT分析发现,掉话由单一终端在进行并发业务时掉话,掉话的原因为:RNLC_Ue_Operate_...
TD-SCDMA网络优化中掉话问题的分析.pdf
的关键技术对无线网络优化中具体问题的解决思路和方法...对于本文提到的掉话问题,业务在发生过程中,基于 TDD...TD-SCDMA优化案例介绍 22页 5下载券 ...
VOLTE案例分析(PDCP SN SIZE 配置不一致导致异常掉话问题。).doc
VOLTE案例分析(PDCP SN SIZE 配置不一致导致异常掉话问题。)_计算机硬件及网络_...问题处理:通过研发分析,是由于 PDCP-config 没有下发导致;根据研发提供的 patch...
LTETDD干扰检测指导书.doc
LTETDD干扰检测指导书_信息与通信_工程科技_专业资料...指导书描述了在LTE系统中干扰问题的分类、定位和解决...的关键因素之一,对通话质量、掉话、切换、吞吐量均...
科技大楼话务过高导致掉话问题解决案例.doc
科技大楼话务过高导致掉话问题解决案例_IT/计算机_专业资料。7月中旬前自贡C网
案例申报_城三分公司_TAU失败导致VoLTE掉话问题处理方....doc
案例申报_城三分公司_TAU失败导致VoLTE掉话问题处理方案_信息与通信_工程科技_...TDD-LTE NetNumen U31 V12.14.31 18652333213 故障现象衙门口桥北侧为两个 ...
青岛PS掉话(安全模式超时)问题处理经验案例.doc
青岛PS掉话(安全模式超时)问题处理经验案例_信息通信_工程科技_专业资料。本案例是通过对青岛PS业务安全模式超时导致位置区更新从而IURELEASE,产生掉话的原因分析,...
TDD_LTE RF基础优化指导_图文.ppt
TDD LTE基础优化指导 www.huawei.com 目标学习完此...与规划 一致,解决孤岛效 应导致的切换掉话 问题; ...案例-分析找出无主导小区区域 ? 现象: 一段测试...
TDD-LTE初中级考试(试卷1)-含答案.doc
TDD-LTE初中级考试(试卷1)-含答案_从业资格考试_...关于切换失败导致的掉话问题常用排查手段,下述说法不...(优化会碰到的 问题类型,不同类型处理思路) ;(12...
无线网络优化常见问题处理思路_图文.ppt
无线网络优化常见问 题处理思路 www.huawei.com HUAWEI...Huawei Confidential 掉话问题分析 5、由于干扰和小区...造成掉话 案例: PN复用问题 HUAWEI TECHNOLOGIES CO....
通过TA分布快速定位高掉话小区问题故障分析案例.doc
通过TA分布快速定位高掉话小区问题故障分析案例_信息通信_工程科技_专业资料。选填,简要介绍文档的主要内容,方便文档被更多人浏览下载。 ...
无线网络优化常见问题处理思路2010125_图文.ppt
无线网络优化常见问题处理思路2010125_互联网_IT/...造成掉话 案例: PN复用问题 HUAWEI TECHNOLOGIES CO....(分)集长时间RSSI高于-95dBm 或在一定时间内高于-...
更多相关标签: