最新完美版TDLTE掉线优化指导书.docx
- 文档编号:7029127
- 上传时间:2023-01-16
- 格式:DOCX
- 页数:25
- 大小:2.09MB
最新完美版TDLTE掉线优化指导书.docx
《最新完美版TDLTE掉线优化指导书.docx》由会员分享,可在线阅读,更多相关《最新完美版TDLTE掉线优化指导书.docx(25页珍藏版)》请在冰豆网上搜索。
最新完美版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概述1
2TD-LTE完整业务流程1
2.1自研UE信令4
2.2CNT信令5
3掉线问题分析5
3.1掉线率公式8
3.2重建原因8
3.2.1定时器不合理8
3.2.2上行干扰9
3.2.3下行干扰13
3.2.4切换准备问题14
3.2.5有MR但无重配17
3.3UE触发重建20
3.3.1UE触发重建未果22
3.3.2UE触发重建被拒22
3.4rrcConnectionRelease掉线24
3.5其他类掉线24
4后台掉线率定义24
4.1掉线原因分类及公式25
4.2KPI分析方法27
5总结27
图目录
图11TD-LTE信令基本流程1
图12自研UE信令4
图13CNT信令5
图21RRC重建无果5
图22RRC重建被拒6
图23异常收到RRC释放消息6
图24TD-LTE掉线问题总结7
图25切换参数查看14
图26切换成功与切换失败表现14
图27UE触发重建被拒21
图31TD-LTE掉线处理流程23
图32影响网优告警列表24
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
原小区
目标小区
切换结果
切换失败说明
重建结
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 最新 完美 TDLTE 优化 指导书
![提示](https://static.bdocx.com/images/bang_tan.gif)