TDLTE掉线优化指导书.docx
《TDLTE掉线优化指导书.docx》由会员分享，可在线阅读，更多相关《TDLTE掉线优化指导书.docx（24页珍藏版）》请在冰豆网上搜索。
TDLTE掉线优化指导书
TD-LTE掉线分析指导书
R1.3
版本更新说明
产品版本
资料版本
资料编号
资料更新说明
V3.10.10
R1.0
手册第一次发行
V3.10.10
R1.2
更新了部分案例及思路总结
V3.10.10
R1.3
完善版本，整理框架
作者
资料版本
日期
作者
审核者
批准者
R1.0
2012-1-20
李毅
R1.2
2012-08-20
李毅
-
R1.3
2013-03-30
李毅
适用对象：
TDD网优工程师
使用建议：
在阅读本文档之前，建议先了解下面的知识和技能：
序号
知识技能
参考资料
1
TD-LTE产品技能认证二级
TD-LTE基本原理与关键技术
TD-LTE产品技能认证二级
TD-LTE路测工具使用方法
后继资料：
在阅读完本文档之后，你可能需要下面资料：
序号
参考资料
资料说明
1
TD-LTE接入优化指导书
TD-LTE接入知识掌握，了解接入的分析
2
TD-LTE切换优化指导书
TD-LTE切换知识掌握，了解切换的分析
3
SuperCell技术白皮书
SuperCell设计方法
关于这篇文档
摘要
章节
描述
1概述
概述
2TDL信令描述
介绍TD-LTE信令基本流程和真实信令的差异
3总结掉线原因分析
对TD-LTE掉线各种原因分析，说明处理掉线的思路方法，及典型案例说明
3后台掉线率定义
掉线原因及KPI处理方法
3总结
掉线问题处理思路
图目录
1概述
本文主要介绍了TD-LTE系统掉线问题优化方法，通过对各局出现的掉线问题进行讲解说明，总结了TD-LTE掉线的处理思路及优化方案，为后续各个外场处理TD-LTE掉线问题提供了优化经验。
2TD-LTE完整业务流程
TD-LTE完整业务信令流程如下：
图21TD-LTE信令基本流程
完整的业务流程共包含4部分，分别如图中所标识的1（红色）接入过程；2（蓝色）与NAS层完保交互过程；3（绿色）无线承载建立过程；4（黄色）释放过程。
当无线承载建立完成“RRCConnectionReconfigurationComplete”正确到达网络侧，则本次业务建立成功，那么在之后一旦触发RRC重建且被拒或者直接转到IDLE态，那么就代表本次业务掉线，也就是说，如果没有对应的“释放过程”那么就认为掉线。
对上述信令过程步骤描述如下：
步骤1～5会建立RRC连接，步骤6、9会建立S1连接，完成这些过程即标志着NASsignallingconnection建立完成。
消息7的说明：
如果UE是刚开机第一次attach，使用的IMSI，无Identity过程；后续如有有效的GUTI，使用GUTIattach，核心网才会发起Identity过程（为上下行直传消息）。
消息10~12的说明：
如果消息9带了UERadioCapabilityIE，则eNB不会发送UECapabilityEnquiry消息给UE，即没有10~12过程；否则会发送，UE上报无线能力信息后，eNB再发UECapabilityInfoIndication，给核心网上报UE的无线能力信息。
为了减少空口开销，在IDLE下MME会保存UERadioCapability信息，在INITIALCONTEXTSETUPREQUEST消息会带给eNB，除非UE在执行attach或者"firstTAUfollowingGERAN/UTRANAttach"or"UEradiocapabilityupdate"TAU过程（也就是这些过程MME不会带UERadioCapability信息给eNB，并会把本地保存的UERadioCapability信息删除，eNB会问UE要能力信息，并报给MME。
注：
"UEradiocapabilityupdate"TAUisonlysupportedforchangesofGERANandUTRANradiocapabilitiesinECM-IDLE.）。
在CONNECTED下，eNB会一直保存UERadioCapability信息。
UE的E_UTRAN无线能力信息如果发生改变，需要先detach，再attach。
发起UE上下文释放（即21～25）的条件：
●eNodeB-initiatedwithcausee.g.O&MIntervention,UnspecifiedFailure,UserInactivity,RepeatedRRCsignallingIntegrityCheckFailure,ReleaseduetoUEgeneratedsignallingconnectionrelease,etc.;or
●MME-initiatedwithcausee.g.authenticationfailure,detach,etc.
eNB收到msg3以后，DCM给USM配置SRB1，配置完后发送msg4给UE；eNB在发送RRCConnectionReconfiguration前，DCM先给USM配置DRB/SRB2等信息，配置完后发送RRCConnectionReconfiguration给UE，收到RRCConnectionReconfigurationComplete后，控制面再通知用户面资源可用。
消息13~15的说明：
eNB发送完消息13，并不需要等收到消息14，就直接发送消息15。
如果发起IMSIattach时，UE的IMSI与另外一个UE的IMSI重复，并且其他UE已经attach，则核心网会释放先前的UE。
如果IMSI中的MNC与核心网配置的不一致，则核心网会回复attachreject。
消息9的说明：
该消息为MME向eNB发起的初始上下文建立请求，请求eNB建立承载资源，同时带安全上下文，可能带用户无线能力、切换限制列表等参数。
UE的安全能力参数是通过attachrequest消息带给核心网的，核心网再通过该消息送给eNB。
UE的网络能力（安全能力）信息改变的话，需要发起TAU。
2.1自研UE信令
结合自研UE真实信令过程如下：
图22自研UE信令
自研UE释放过程无法记录，后续版本补充。
2.2CNT信令
结合CNT与dongle连接真实信令过程如下：
图23CNT信令
本次释放是UE发起的去附着过程，后续RRCrelease过程CNT无法体现。
3掉线问题分析
3.1分析思路
对于TD-LTE的掉线，是在UE完成“RRCConnectionReconfigurationComplete”处于连接态，之后由于干扰、弱场、其他原因导致的UE上下行失步，触发重建未果或者被拒过程。
只要不是终端主动发起的释放，都应算为掉线。
目前掉线在信令中表现如下3种情况。
●连接态下触发RRC重建无果
图31RRC重建无果
●连接状态下触发RRC重建被拒
图32RRC重建被拒
●连接状态下异常收到RRC释放消息
图33异常收到RRC释放消息
对于非正常释放的掉线问题，TD-LTE引入了重建立机制，对于重建立的掉线的分析要分2部分完成：
●引起重建的原因；
●重建失败的原因；
因此基于上述掉线进行分析总结
图34TD-LTE掉线问题总结
对于掉线问题，首先判断的就是覆盖和干扰，利用CNT查看下行RSRP、SINR值，通常RSRP<-115且SINR<-3掉线比例较高；利用基站侧检测工具查看上行干扰。
下面结合日本网优阶段发现的掉线案例编写掉线问题分析过程。
3.2掉线率公式
目前测试软件CNT（A）对掉线率的定义如下：
L3message：
（rrcConnectionReestablishmentRequest-rrcConnectionReestablishmentComplete+rrcConnectionRelease（不含1~3原因）times*100%/L3message（ActivatedefaultEPSbearercontextaccept）times
●UE发送rrcConnectionReestablishmentRequest但无对应的rrcConnectionReestablishmentComplete消息；
●出现rrcConnectionRelease消息，但不包括：
-1系统间切换网络侧释放;
-2用户未激活，网络侧释放资源情况（UserInactivity）
-3CSFB的网络侧释放（待确定）
说明：
对于TDD-LTE制式，掉线对用户感知的评判有所减弱，此公式只是一般情况，后续可以与局方协商对掉线率公式修改，如RRC重建被拒后2s内业务恢复成功不计做掉话，或者可以用时间掉线比（分母是测试总时长）、公里掉线比（分母是DT测试公里数）
3.3重建原因
3.3.1定时器不合理
定时器相关参数优化建议值如下：
字段名称
优化值
字段中文含义
byT310_Ue
2000ms
UE监测无线链路失败的定时器长度（T310_UE）
byT311_Ue
30000ms
UE监测到无线链路失败后转入idle状态的定时器长度（T311_UE）
byT300
2000ms
UE等待RRC连接响应的定时器长度（T300）
byT301
2000ms
UE等待RRC重建响应的定时器长度（T301）
byT302
1s
UE收到RRC连接拒绝后等待RRC连接请求重试的定时器长度（T302）
byT304
1000ms
UE等待切换成功的定时器长度（T304）
byT304_Cco
4000ms
UECCO到GRAN的定时器长度（T304）
byT320
5min
小区重选优先级定时器长度（T320）
byN310
6
UE接收下行失步指示的最大个数（N310_UE）
byN311
1
UE接收下行同步指示的最大个数（N311）
这类参数都已定标，如发生掉线问题可根据案例查看相关时段是否合理，再结合所有掉线对定时器做全局考虑修改调整。
可参考《TD-LTE网优参数优化指导书》。
3.3.2上行干扰
上行干扰包含用户间的上行干扰，设备自身异常处理的上行干扰，以及频段的干扰导致，通常上行干扰主要表现切换失败、重建失败，发生掉线。
典型案例分析
3.3.2.1现象描述
福冈网络指标摸底阶段中，初期存在接入不成功，切换后异常掉线，这种现象没有一定规律，有时成功有时失败。
测试掉线点分布如图所示：
图中黑色星为掉线点。
通过掉线点分布，掉线点基本在东南边。
3.3.2.2现象分析
1.针对该问题，挑选在掉线集中点区域进行定点测试，各种终端都无法连接网络。
高通终端表现，一直在IDLE、CONNECTED之前乒乓，无法正常接入。
2.查看当时测试数据，在仅能接入的几次其服务小区的RSRP、SINR良好；
下行覆盖良好，无干扰。
查看信令，UE接入小区后就触发RRC重建，发生掉线。
通过高通分析软件QCAT查看掉线过程及重建过程。
看到UE原因为UL_DATA后DCI0未达，SR达到最大次数，触发MSG1，由于MSG1无法到达网络侧，不断重发8次后失败，后触发重建。
为了验证问题是否有规律性，对站点了定点测试，测试区域如图所示：
蓝色区域的站点随机接入和切换成功率较高，而红色区域站点接入困难。
站点分布与BBU关系如图：
红色区域是掉线集中区域。
查看掉线点与BBUID关系，有一定联系，非掉线区域隶属于BBUID=400010（蓝色区域），掉线区域的属于BBUID=400011、400012的BBU下挂小区。
因此怀疑可能BBUID=400010与BBUID=400011、400012某些关联设备问题导致。
3.根据上述分析查看后台设备告警。
BBUID=400011、400012站点的GPS未锁定（对应告警名称：
GPSreceiverfailedtosearchstars（198091072）），400010站点正常。
BBUID=400011、400012站点GPS状态未锁定：
BBUID=400010的GPS状态正常：
400011、400012无GPS锁星，但仍处于激活态，导致其下挂的小区对周边小区造成GPS干扰，影响其他小区上行接入。
对接入切换不成功的小区提取MTS跟踪上行接收功率数据，基站侧接收功率普遍抬高（空载下正常应该在-96~99dbm左右），平均在-80dbm左右，受到上行干扰。
干扰情况如下表显示：
基站侧接收到的RxPow0～3都很高，上行干扰严重。
3.3.2.3解决方法及验证
福冈每个BBU下挂多个RRH（小区），如果GPS锁星失败，此时基站仍然在放电波状态下，就会对周表小区存在干扰。
因此把400011、400012的2个BBU下挂的站点闭塞，后再次测试，问题消失，400010下的所有小区接入切换均成功，问题得以解决。
3.3.2.4总结
根据上述的分析，如果GPS一旦出现异常，那么对周边站点的干扰是比较严重的。
对于没有接通GPS的站点不允许开通释放电波。
对于偶然存在GPS失星的情况要通过参数来控制其对别的站点干扰，目前后台有关于GPS失星后的控制方案，其包含2个参数：
A.Holdovertime-outswitch（GPS同步保持）取值范围：
开/关；
B.Holdovertime-outthreshold（GPS同步保持时间门限）取值范围：
60分钟~4小时
配置在EMS-eNodeB节点配置表，第一个参数必须配置为开，再设置保持时间，默认是60分钟。
参数网管截图如下：
开关状态为enable，时间默认为60分钟：
表示开关打开，基站在60分钟内，GPS没有同步则关闭小区；
开关状态为disable，时间默认为60分钟：
表示开关关闭，小区状态不受GPS是否同步影响，始终保持正常建立状态；
3.3.3下行干扰
系统内的下行干扰是产生掉线原因之一，通常表现无主覆盖小区，服务小区与邻区RSRP较好，数值基本接近，但SINR较差，导致解调信号变弱，易失步，因此会触发重建过程，如果重建不成功则产生掉线。
由于日本全向天线，无法对天面参数调整，对于下行干扰只能采用降功率方式以及超级小区（超级小区详见《
SuperCell小区合并算法》）暂时解决。
但是对于其他局，通常处理方式优先顺序是：
1.先天面调整；
2.覆盖切换类参数调整；
3.最后功率调整。
该案例后续针对定向天线补充。
3.3.4切换准备问题
通常情况下如果UE上报MR时机不佳，则会伴随着服务小区信号衰减抖动过快，导致掉线。
这种情况是由于无法满足切换条件或者切换过早造成。
切换的参数包括：
A3_offset、TTT、Hysteresis，这3个参数设置过于苛刻或过于简单，都会导致时机不佳换造成掉线。
查看三个参数配置情况可看RRCConnectionReconfiguration中的IE字段名称，如图所示：
图35切换参数查看
CNT显示的切换失败信令如下图蓝框内内容所示，红框内信令为正常的切换信令
图36切换成功与切换失败表现
典型案例分析
3.3.4.1现象描述
在测试中路口附近是问题多发点，部分小区由于“波导效应”容易出现过覆盖问题，又由于“拐角效应”在路口两侧信号迅速衰落，从而导致掉线。
3.3.4.2现象分析
测试路线如下图蓝色箭头所示，其中红色区域为掉线点。
在测试路线上主要是PCI=45小区覆盖，在经过红色区域所以的路口时，PCI=4小区信号突然出现并迅速恶化，导致终端切换进该小区产生掉线。
掉线点RSRP分布如上图所示，红色区域显示PCI=4小区突然出现一个尖峰。
CNT掉线点信令如下图所示：
3.3.4.3解决方法及验证
由测试路线图可知PCI=4小区距离测试路线较远，测试路线应该由PCI=45小区覆盖，但由于“波导效应”导致PCI=4小区信号在路口比服务小区高4dB而触发切换流程导致掉线，而解决此掉线只需要避免UE切换到该小区即可。
将PCI=45小区邻区关系中和PCI=4小区邻区“Cellindividualoffset”设置为-3，在UE测量时增加一个迟滞，从而避免触发切换流程。
3.3.4.4总结
在处理路口附近由于突然出现的信号尖峰导致的问题时，由于测试区域均使用全向天线，RS功率/A3事件迟滞/Timetotrigger三个参数影响范围较广不建议调整，应优先使用Cellindividualoffset来解决。
3.3.5有MR但无重配
UE具备全频段所有小区探测能力，只要达到上报条件，就会有MR上报，但如果后台没有对服务小区配置合理正确的邻区关系，就无法从网络侧收到切换命令，无法切换。
在信令主要表现在UE上报多个MR后，但无切换命令，无线链路超时造成掉线。
典型案例分析
3.3.5.1现象描述
在某次路测中发现如下图情况，UE上报多个MR
多次测量报告现象：
3.3.5.2现象分析
查看MR信息，前三次测量报告目标PCI都是28：
第一个测量报告内容：
第四次测量报告（见图3-3）中有PCI28、19两个小区，
第四次测量报告内容：
从测量值上看，28比19高3个dB，接着收到了切换命令，切换命令：
切换命令：
1目标小区的PCI=19
3.3.5.3解决方法及验证
目标小区不是最高的28而是19，所以需要确认源小区的邻区是否添加了PCI=28小区，通过查询源小区的测量控制信息确认源小区漏配邻区：
源小区测量控制信息：
1：
邻区列表中有PCI=19小区
查看信令，没有配置28的小区信息，并且通过站点分布发现，服务小区6与28、19都比较近，应属于漏配邻区情况，站点分布如图：
因此该问题是由于没有添加PCI=28的小区导致，添加PCI=6PCI=28小区后切换正常
3.3.5.4总结
由于目前SON的自动邻区功能不成熟，路测中遇到多次上报MR始终不切换的情况需要根据实际覆盖与邻区关系对比，添加合适的邻区关系，但是也要避免切换参数不合理的突发信号引起的不良MR情况，需要对每个异常问题深刻分析。
3.4UE触发重建
协议中定义了触发重建的流程及信令
图37RRC重建成功
图38RRC重建被拒
协议中对UE触发重建的原因如下：
TheUEshallonlyinitiatetheprocedurewhenASsecurityhasbeenactivated.TheUEinitiatestheprocedurewhenoneofthefollowingconditionsismet:
●upondetectingradiolinkfailure,inaccordancewith“Radiolinkfailurerelatedactionsor”
●通常无线链路失败，牵扯到公共信道、业务信道的覆盖和干扰情况
●uponhandoverfailure,inaccordancewith”T304expiry（handoverfailure）”or
●切换等待定时器超时导致，查看小区邻区及参数是否合理
●uponmobilityfromE-UTRAfailure,inaccordancewith“MobilityfromE-UTRAfailure”or
●检查配置是否合理及参数
●uponintegritycheckfailureindicationfromlowerlayersor
●完整性检查失败,如加密算法，与NAS的直传消息受阻导致
●uponanRRCconnectionreconfigurationfailure,inaccordancewith“Reconfigurationfailure”
3.4.1UE触发重建未果
目前还未发现这种触发重建后没有下文的情况，后续版本补充。
根据通常网优经验，发生这种情况一般都是由于UE发送重建立消息过程中，由于覆盖场强过弱、上行功率异常、干扰等导致。
按照掉线处理思路流程，先确定个性还是局部问题，然后查看发生该问题的服务小区、目标小区有无硬件告警，再查看覆盖、干扰、参数情况进行判断。
3.4.2UE触发重建被拒
该问题通常信令如下图所示：
图39UE触发重建被拒
通常发生RRC被拒一般都是由于版本问题、上下行报文错误、设备原因导致。
典型案例分析
3.4.2.1现象描述
福冈FT拉网测试中，UE最初占用PCI=25号小区，后切换至PCI=18号小区，切换成功。
由于日本全向天线，且在闹市区，存在电平波动，后UE检测到PCI=25号小区满足切换条件，网络下发RRC重配置给UE，携带切换目标小区是原服务小区PCI=25号，可是切换失败，后无线链路失败触发重建立过程：
当时信令表现如下：
蓝色部分是UE从PCI=25PCI=18成功，绿色是从PCI=18PCI=25进行回切失败
后RLF，红色是触发重建过程，从PCI=18PCI=45被拒，造成掉线。
3.4.2.2现象分析
这种现象在测试过程中发生次数较多，根据掉线排查思路，优先查看切换失败到重建立过程中覆盖、干扰情况，发现此过程中的前后几秒内小区覆盖较好，SINR>3，无干扰，后查看后台目标服务小区均无硬件告警。
抓取不同时间段的LOG，对目标和服务小区切换做了统计，有如下规律：
Time
原小区
目标小区
切换结果
切换失败说明
重建结果
17:
41:
18:
066
25
18
成功
同一单板
17:
42:
20:
905
18
25
失败
重建18，成功
17:
42:
21:
537
18
25
失败
重建18，成功
17:
42:
59:
807
18
25
失败
重建45，失败
3.4.2.3解决方法及验证
根据上述分析，搜集大量LOG，对切换失败和重建被拒进行分析，得出如下结论：
●同一单板内，发生回切必然失败；
●失败后的重建如果UE之前没有占用过某小区，无上下报文必然重建被拒。
后与家里研发确定该问题，是由于终端在收到RRC重配消息（切换命令），在PDCP层执行完整性保护校验时FAIL，之后PDCP上报RRC，触发RLF。
完保FAIL的原因是：
终端收到的MAC-I与实际计算的MAC-I不匹配，如下：
其他RBcfgindex=33，对应SRB1，01:
31:
38.030lte_pdcp_dl_protocol.cMAC-Imis-matchRBCfgidx=33seq_num=0,rxedMAC-I=0x783e182b,CalculatedMAC-I=0xbedccd4b。
3.4.2.4总结
该案例重建被拒是由于系统BUG导致，同一单板内回切失败，重建过程中如果重建到未知小区（UE从未占用过的小区）则重建被拒，原因是由于上下行报
升级会员 