UE上下文掉线率分析定位方法研究

UE上下文掉线率分析定位方法概述UE上下文掉线率是提现用户业务保持性和用户体验的重要KPI，因此，本文主要介绍了FDD-LTE无线掉线率原理与问题优化方法，通过对出现各种counter的掉线问题进行讲解说明，总结了优化方案，为后续处理无线掉线率问题提供了优化经验。分析思路UE上下文掉线率=∑〔eNB请求释放上下文数-正常的eNB请求释放上下文数〕/∑(初始上下文建立成功次数+遗留上下文个数)*100%，其中∑代表将本地网范围内的各个小区的统计结果累加。UE上下文掉线率是网管KPI，首先通过掉线原因Counter初步判断原因，然后根据掉线原因进行分析与优化。理论分析掉线的常见问题从UE角度进行掉线分析，大致有以下几种现象：UE收到非正常的RRCRelease消息后，UE进入idle状态UERRC重建，失败超时后进入idle状态UE直接进入idle状态商用终端UE数据业务中断没有流量等现网的掉线率主要通过网管统计来监测掉线率情况，通过统计掉线率和掉线次数来评估是否存在异常，通常从导出的网管数据看如下信息：全网掉线率，掉线次数以及掉线原因。掉线的TOP小区、掉线失败时间段。掉线问题的分析掉线可以分为UEinitialedDrop，eNBinitialedDrop以及MMEinitialedDrop.UEinitialedDrop过程UEinitialedDrop，涉及RRC连接重建过程。当UE处在RRC连接状态，并且RRC平安激活时，UE可以出发RRC连接重建过程。如果RRC连接状态时，UERRC平安没有激活，UE直接进入空闲模式，执行小区重选或TAU。RRC重建消息中Cause包括以下几种：OtherFailure(UEradiolinkfailure)HandoverFailure(T304HOtimerexpiry)ReconfigurationFailure其中，无线链路失败又可包括以下几种场景：T310超时RLF到达最大上行RLC重传次数RLF非切换随机接入问题RLF如果重建成功，重建SRB1以发送RRC信息，重新激活RRC平安，不需要变更算法，SRB1重建后才能重建DRB。重建失败，UE进入空闲状态，RRC异常释放。T310超时的导致的RLF如下列图所示：UE连续失步n310次那么进入T310计时，假设T310时间内不能恢复那么计入T311RRC重建计时。这里的失步基于无线链路质量估算，详见3GPP标准36.311。最大上行RLC重传次数导致的RLF(RadioLinkFailure)上行RLC链路重传次数到达时，启动RRC重建过程。切换失败导致的RLF(RadioLinkFailure)UE在规定时间内未与目标小区取得同步，即T304超时，发起重建过程，此时UE在目标小区和源小区都有重建成功的可能。其他非切换随机接入失败导致的RLF(RadioLinkFailure)非切换随机失步可以是多种原因，包括PDCCHOrder等。eNBinitialeddrop过程eNBinitialeddrop过程包括如下几种情况：eNB检查到无线链路问题PUSCHRLFCQIRLF〔周期性〕ACK/NACKRLFPDCCHOrderFailureSRSRLFTA定时器超时〔视相关参数配置〕到达最大RLC重传次数传输网络问题(GTP-U失败，PathSwitch等)3GPP标准没有规定eNB无线链路失败，但NSN基站设计了一定的机制，当基站eNB检测到某种无线链路失败即开始计时，如果无线链路恢复，那么取消计时。当无线链路失败超过一定时间〔t310+t311〕，eNB就会发起RRC和S1释放，UE掉线。MMEinitialedDrop过程在做业务的过程中MME也可能发起异常的S1+RRC释放，可能的原因有：基于无线网络层问题由于其它异常原因邻区空载场景UE_A驻留在小区Cell_A，在RB61~68进行数据调度，同频邻区Cell_B处于空载状态，对应的RB61~68上无数据调度，因此Cell_B对Cell_A无影响。邻区负载场景UE_A驻留在小区Cell_A，在RB61~68进行数据调度，同频邻区Cell_B处于负载状态，Cell_B的RB62~70上存在数据调度，由于Cell_A与Cell_B的频率相同，两小区的RB重叠局部RB62~68存在同频干扰。掉线问题的原因业务掉线可以通过UE、eNB或MME发起的RRC+S1释放产生，也有其他一些原因，包括突发故障引起。一般异常业务掉线指因软、硬故障等引起的掉线。将掉线大致分为以下几种原因：无线失败引起的掉线无线信号质量差，覆盖电平低无线信号质量差，干扰大无线信号突变其他原因无线失败切换引起的掉线eNB故障引起的掉线核心网问题引起的掉线传输问题引起的掉线，如传输闪断终端问题引起的掉线掉线问题的定位异常掉线根本问题定位流程：检查基站工作状态及告警基站工作状态有没有变化有没有传输告警有没有其他突发告警对UEinitdrop，通常有RRC重建，如果条件允许，检查RRC重建原因，是otherfailure，还是handoverfailure，还是重配置失败。如果是切换流程失败按照切换类问题进行处理如果是其他失败，检查是否存在高干扰，1〕通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突；2〕检查小区时隙配比是否设置准确〔DE:SA2\SSP7;F:SA2\SSP5〕；3〕通过提取RSSI干扰噪声平均值>-90dBm,确认小区存在上行干扰，同时可通过后台跟踪PRB干扰，确认干扰类型；如果信号质量没有问题，重建异常，检查相关定时器n310，T310，T311等是否正确配置如果定时器配置没有问题，检查是否存在高质差，通过观察小区上下行丢包率是否正常，如丢包率偏高，根本断定小区存在质差；通过后台误码率跟踪，如BLER>10%，确定小区存在高误码；如果高质差检查没有问题，是否存在弱覆盖，1〕检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，根本确定小区存在弱覆盖；2〕比照64QAM和QPSK占比，如后者比例远大于前者,可确定小区覆盖异常；如果都没有找到原因，检查无线信号质量，包括RSRP，下行SINR等1〕安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因；2〕如果确认问题后，需第三方配合解决，转发相关人员处理，做好跟踪工作，直至问题闭环；UE侧观察到UE突然进入空闲或RRCrelease等情况检查eNBinitdrop，如果emil抓log需要能够复现问题，并且检查相关统计项是否异常，按照RLF分类，分别确认检查相关基站参数配置是否存在问题，注意TA定时器的相关设置是否符合无线规划要求检查MMEinitdrop，如果emil等抓log需要能够复现问题，并且检查eNB相关统计项是否异常，如确认核心网及传输可能存在问题，联系EPC协助排查UE问题也可能导致异常掉线，假设网络侧没有其他异常情况，尝试更换UE是否有效解决，如果并且能够复现可能的UE问题，联系终端厂商协助排查掉线问题优化方案切换优化核查邻区，对于漏配邻区，切换参数等问题导致切换失败后掉线。具体参考切换优化指导手册超远邻区核查，通过经纬度换算出邻区之间的距离，对于大于10KM以上的邻区全部删除，在农村或者郊区，除特殊场景外，建议删除大于5KM的邻区；在市区建议超过2KM以上的邻区删除。冗余邻区核查，通过网管数据统计，发现很长一段时间以来都没有掉线关系的邻区建议删除。单向邻区核查，通过网管数据以及X2链路告警信息，对于存在单向邻区的进行补全。漏配邻区核查，在地图上周边2圈以内的邻区都建议加上，定期进行核查，对于漏加的邻区关系进行补全。同频同PCI核查，定期进行同频同PCI核查，防止同频同PCI造成掉线失败。参数优化定时器相关参数优化在上行失步检测过程中，定时器设置的合理性会影响到掉线率，下面是相关定时器参数及参数的优化建议值：参数名称优化值参数中文含义T3102000msUE监测无线链路失败的定时器长度(T310)T31130000msUE监测到无线链路失败后转入idle状态的定时器长度(T311)T3002000msUE等待RRC连接响应的定时器长度(T300)T3012000msUE等待RRC重建响应的定时器长度(T301)T3021sUE收到RRC连接拒绝后等待RRC连接请求重试的定时器长度(T302)T3041000msUE等待切换成功的定时器长度(T304)N3106UE接收下行失步指示的最大个数(N310_UE)N3111UE接收下行同步指示的最大个数(N311)诺基亚设备上行RLF检测机制参数核查参数名称优化值参数含义nCqiDtx0TheparameterdefinesthenumberofconsecutiveCQIDTXdetectionscausingradiolinkfailureindication.Specialvalue0meansthatthefeatureisdisabled.

Theparameterisvendor-specific.nSrsDtx0NumberofconsecutiveSRSDTXdetectionsrequiredforRLFailure

TheparameterdefinesnumberofconsecutiveSRSDTXdetectionscausingradiolinkfailureindication.Specialvalue0meansthatthefeatureisdisabled.rlpDetMaxNUl0DefinesthenumberofuplinkDTXdetectionsonPUSCHbeforeanindicationaboutradiolinkproblemsissenttohigherlayers.Thisparameterisvendor-specific.其他重点参数核查其他对掉线影响较大的参数，如：Inactivitytimer，ilReacTimerUl干扰优化系统内干扰排查，系统内干扰主要有重叠覆盖导致同频干扰、PCImod3干扰、GPS失步导致的干扰等。目前主要通过外场RF优化，合理控制覆盖及PCI优化来尽量减少干扰。系统外干扰排查，通过扫频测试，定位外部干扰源，协调客户区排除干扰源。覆盖优化覆盖问题主要包括弱覆盖，重叠覆盖，越区覆盖，一局部通过功率相关参数如PMAXpa/pb等参数来适当控制覆盖，另外主要是通过外场RF优化，通过调整天线的下倾角和方位角来合理控制小区的覆盖范围。负荷对VoLTE性能影响验证〔一〕测试用例说明测试条件：1、

选取负荷较低的区域，上/下行PRB利用率不超过20%〔15分钟粒度〕。2、

挑选的VoLTE测试小区要存在较多的同频邻区〔至少3个〕，RSRP差值均在10dB以内〔差值越小越好〕。本次测试选定培华学院宿舍楼区域的“西安_长安_151988培华学院学生公寓_CMIDCX”-1作为效劳小区，同频邻区数量控制在3个左右。3、

VoLTE测试点RSRP在-100~105左右，不发生切换，不锁频。4、后台实时监控各小区的PRB利用率情况。测试要求：第1轮VoLTE用户在测试点做MOS测试，短/长呼各测试30分钟；第2轮(1)VoLTE用户在测试点做MOS测试，短/长呼各测试30分钟；(2)同时在VoLTE用户小区做FTP上传/下载业务，上/下行PRB利用率到达90%以上；第3轮(1)VoLTE用户在测试点做MOS测试，短/长呼各测试30分钟；(2)周边所有同频邻区做FTP上传/下载业务，上/下行PRB利用率到达90%以上；第4轮(1)VoLTE用户在测试点做MOS测试，短/长呼各测试30分钟；(2)周边所有同频邻区以及效劳小区做FTP上传/下载业务，上/下行PRB利用率到达90%以上；

测试结果及分析说明由于测试业务较多，本次测试分为2个时间段进行：6月28日0:00-6:00；6月29日0:00-6:00。下表为本次测试结果：轮次主叫呼叫次数主叫接通次数主叫掉话次数被叫掉话次数呼叫成功率接通率掉话率呼叫建立时延〔s〕T0-短呼202000100.00%100.00%0.00%2.81T1-短呼202000100.00%100.00%0.00%2.96T2-短呼191900100.00%100.00%0.00%3.23T3-短呼191900100.00%100.00%0.00%3.32轮次MOS质量平均SINR平均RSRPLTE覆盖采样点(RSRP>-110andSINR>-3)LTE覆盖率(RSRP>-110andSINR>-3)LTE覆盖总采样点PUSCHTxPowerMOS>=3.5占比T0-长呼4.1612.64-98.417579100.00%757913.4596.43%T1-长呼4.1511.09-98.267656100.00%765613.97100.00%T2-长呼4.081.5-98.87759298.56%77039.21100.00%T3-长呼4.03-1.89-98.36729195.59%762716.6199.11%通过第1轮与第2轮的测试比照说明，本小区负荷抬升〔周边同频小区都是空载〕后，呼叫建立时延由2.81秒升至2.96秒；SINR由12.64降至11.09，MOS质量由4.15降至4.14。通过第1轮与第3、4轮的测试比照说明，周边同频邻区负荷抬升后，呼叫建立时延由2.81秒升至3.23秒/3.32秒；SINR由12.64降至1.5/-1.89，MOS质量由4.16降至4.08/4.03。小结：①通过T0与T1测试比照说明，效劳小区负荷抬升〔周边同频小区轻载〕后，VoLTE的感知无明显变化；②通过T0与第T2、T3的测试比照说明，周边同频邻区负荷抬升后，效劳小区干扰上升，呼叫建立时延增大，SINR变差，MOS质量有下降，VoLTE用户感知下降。负荷对VoLTE性能影响验证〔二〕测试条件及要求测试条件：1、

选取负荷较低的片区，上行/下行PRB利用率均不超过20%〔15分钟粒度〕。2、

挑选的VoLTE测试小区要存在较多的同频邻区，RSRP差值均在10dB以内〔越小越好〕。通过现场测试，本次测试选定“西安_土门_151707外事学院03男生公寓_BMIDCX”-1作为效劳小区，同频邻区数量控制在5个。3、

VoLTE测试点RSRP在-100~105左右，不发生切换，不锁频。4、后台实时监控各小区的PRB利用率情况。测试要求：第1轮VoLTE用户在测试点做MOS测试，短/长呼各测试30分钟；第2轮(1)VoLTE用户在测试点做MOS测试，短/长呼各测试30分钟；(2)同时在周边所有同频邻区做FTP上传/下载业务，上/下行PRB利用率稳定在50%左右；第3轮(1)VoLTE用户在测试点做MOS测试，短/长呼各测试30分钟；(2)同时在周边所有同频邻区做FTP上传/下载业务，上/下行PRB利用率稳定在90%左右；第4轮(1)VoLTE用户在测试点做MOS测试，短/长呼各测试30分钟；(2)同时在周边同频邻区做FTP上传/下载业务〔做业务的邻区数量比用第3轮减少2~3个〕，上/下行PRB利用率稳定在90%左右；测试结果及分析由于测试业务较多，本次测试共分为2个时间段：6月30日0:00-6:00；7月1日0:00-6:00。以下是本次测试的结果：轮次主叫呼叫次数主叫接通次数主叫掉话次数被叫掉话次数呼叫成功率接通率掉话率呼叫建立时延〔s〕T0-短呼191900100.00%100.00%0.00%2.88T1-短呼191900100.00%100.00%0.00%3.13T2-短呼191900100.00%100.00%0.00%3.25T3-短呼191900100.00%100.00%0.00%2.96轮次MOS质量平均SINR平均RSRPLTE覆盖采样点(RSRP>-110andSINR>-3)LTE覆盖率(RSRP>-110andSINR>-3)LTE覆盖总采样点PUSCHTxPowerMOS>=3.5占比T0-长呼4.1213.84-97.767736100.00%773617.69100.00%T1-长呼4.1013.71-97.898692100.00%869217.71100.00%T2-长呼4.06-3.33-99.49459454.85%837517.4498.96%T3-长呼4.081.50-98.87759298.56%77039.21100.00%第1、2、3的测试比照说明，在同频邻区数量保持不变的情况下，负荷抬升〔轻载->中载->重载〕对效劳小区的影响，呼叫建立时延由2.88秒升至3.13秒/3.25秒；SINR由13.84降至13.71/-3.33，MOS质量由4.12降至4.10/4.06。第3、4轮的测试比照说明，在高负荷的情况下，同频邻区数量由5个减少至3个对效劳小区的影响，呼叫建立时延由3.25秒降至2.96秒；SINR由-3.33升至1.5，MOS质量由4.06升至4.08。小结：通过T0、T1、T2的测试比照说明，在同频邻区数量保持不变的情况下，随着负荷的抬升〔轻载->中载->重载〕，空口干扰越大，VoLTE用户感知呈下降趋势。通过T2与T3的测试比照说明，在高负荷情况下，周边同频邻区数量的减少，空口干扰越小，VoLTE用户感知有所提升。掉线问题典型案例案例一PDCCH拥塞导致掉线率偏高【问题描述】宁波诺基亚网络TD-LTE网络NBCX大红鹰FHTL-3基站9月15日掉线率剧增，忙时一个时段掉线4300屡次，接通率正常。小区、基站均无告警，常规参数配置也正常。【原因分析】分析掉线统计时发现掉线率升高的时段均为忙时，疑心掉线率升高跟业务量有关，接通率指标正常，说明接入相关的容量没有问题，忙时掉线率高的时候PDCCH阻塞次数也很高〔AGG1~8_BLOCKED_PDCCH〕，而在半夜指标正常的时候那么无此问题。因此初步定为为PDCCH下行控制信道资源缺乏，调度受限导致掉线高。PDCCH拥塞优化的常规思路如下：1、增加PDCCH的符号数量，可调整参数MaximumnumberofOFDMsymbolsforPDCCH，最大调整到3，该参数需要配合PRACHFreqOFF一起调整；PRACHFreqOFF定义了PRACH的位置，可按照网管提示来配置，一般情况下PDCCH数量调到3的时候，PRACHFreqOFF可调到7；2、减少每TTI调度的用户数，涉及参数MaximumamountofusersperTTIinUL/DL。【处理过程】调整MaximumnumberofOFDMsymbolsforPDCCH从1到3，PRACHFreqOFF从3到7，MaximumamountofusersperTTIinDL从10到6。【优化效果】调整后，掉线率和PDCCH的拥塞情况都有明显改善。案例二模三干扰导致掉线率高【问题描述】TOP小区分析时发现鑫隆平价超市-3小区2月14日掉线率较高，到达9%。基站无任何告警，状态正常。【原因分析】查看接入指标都正常，用户数在30左右，不是业务高引起。查看切换指标，发现与圣昌玻璃公司东-2小区切换次数较多，并且失败次数也较多。疑心是切换失败引起。ENB_CELL1ENB_CELL2HOSUCCRATIOHOFAILSUCCEHOATT469425_3469366_217.68%10292211250检查两小区为模三对打，现场测试发现有掉线问题。【处理过程】对调鑫隆平价超市-2/3小区PCI。【优化效果】调整后，两站间测试切换正常，鑫隆平价超市-3小区掉线率恢复正常案例三无线环境和切换关系优化解决掉话问