LTE接入问题分析
- 格式:docx
- 大小:1.35 MB
- 文档页数:15
一、掉话问题两类
1、异常RRC connection Release,网络设备异常。
2、RRC重建失败。
二、掉话问题具体原因:
1、弱覆盖
2、干扰
3、切换失败,邻区参数配置不正确,目标小区工作不正常(传输误码,负荷高接纳拒绝)
4、邻区漏配,无法切换
5、越区覆盖,导致参考信号污染或邻区漏配引起切换掉话。
6、拥塞,引起多项指标恶化。
7、设备异常,终端或网络设备异常。
三、RRC重建立触发的原因有如下几种情况:
(1)UE检测到无线链路失败,主要包括:上下行RLC达到最大重传次数;上/下行失步,随机接入失败等原因
(2)切换失败(包括同系统、异系统切换)
如果切换失败,UE会发起RRC重建立请求,并将重建立原因封装在RRC重建立请求消息中。
(3)底层指示完整性保护失败
由于信令的完整性保护失败发生RRC重建立,例如UE和基站的加密以及完整性保护算法不一致,这类原因不常见,通常为终端的问题。
(4)RRC重配失败
RRC重配置的目的是修改RRC连接,在如下场景会发生RRC重配置:建立、修改或者释放无线承载时;执行切换时;建立、修改或释放测量配置等。
LTE的随机接⼊及接⼊失败原因分析LTE的随机接⼊随机接⼊是终端在开始和⽹络通信之前的接⼊过程,是保证通信建⽴的决定性环节,随机接⼊过程直接影响到系统的性能。
随机接⼊过程的⽬的是为数据传输分配资源或者取得上⾏同步。
随机接⼊过程分为两种类型:同步随机接⼊过程和⾮同步接⼊过程。
当UE已经和系统取得上⾏同步时,UE的随机接⼊过程称为同步随机接⼈;当UE没有和系统取得上⾏同步时,或者在丢失上⾏同步的情况下称为⾮同步随机接⼊。
LTE中随机接⼊过程的场景在LTE中,有5种情况将会触发随机接⼊过程:1. 从RRC_IDLE状态开始初始接⼊。
2. RRC连接重建⽴过程。
3. 切换。
4. UE处于RRC_CONNECTED状态,UE要接收新的下⾏数据,但是上⾏⾮同步,需要随机接⼊过程建⽴同步。
5. UE处于RRC_CONNECTED状态,UE要发送新的上⾏数据,但是上⾏⾮同步或者是没有PUCCH资源可以传输SR信息,此时需要随机接⼊过程。
LTE随机接⼊过程的模式LTE随机接⼊过程有两种模式:竞争接⼊和⾮竞争接⼊。
1. 基于竞争接⼊对于前⾯提到的随机接⼊应⽤的5种场景,都可以触发基于竞争的随机接⼊过程。
在这个过程中,UE随机的选择⼀个前导序列,这可能导致多个UE同时选择相同的前导序列发送,结果发⽣碰撞,所以需要⼀个竞争解决过程来处理。
2. 基于⾮竞争接⼊对于前⾯提到的随机接⼊应⽤的场景3(切换)和场景4(接收新的下⾏数据),eNodeB可以通过分配⼀个特定的前导序列给UE,来避免竞争。
正常的下⾏链路或者上⾏链路的数据传输出现在随机接⼊过程之后。
LTE接⼊失败原因分析⽬前FDD LTE常见接⼊失败主要包括:RRC连接建⽴失败鉴权失败ERAB建⽴问题FDD LTE接⼊失败分析流程RRC连接建⽴失败原因1. 弱信号起呼导致呼叫信令流程未能完成2. 上⾏RACH问题3. ⼩区重选问题4. 设备异常5. 拥塞问题鉴权加密失败原因1. MAC Failure2. Synch failureE-RAB建⽴失败原因1. 弱信号起呼2. 来⾃UE/MME侧的拒绝3. 参数配置不合理4. 拐⾓效应5. 设备异常。
【关键字】问题LTE的掉话原因分析及处理思路LTE“掉话”是指UE异常退出RRC_CONNECTED状态导致的连接中断。
统计节点为“RrcConnctionReconfigurationComplete”消息正确达到网络侧开始,之后进行的各类业务,未正常释放的均计为“掉话”。
正常释放流程如下:一、外场常见掉话原因分析目前LTE常见掉话原因包括弱覆盖、越区覆盖、切换失败、邻区漏配、系统设备异常、干扰、拥塞等。
掉话原因1:弱覆盖现象:由于弱覆盖导致的掉话,通常有以下表现:1.掉话前服务小区的RSRP持续变差(低于弱覆盖标准,如小于-105dBm),同时服务小区的SINR也一起持续变差(小于0dB,甚至小于-3dB)。
2.掉话后可能会有一段时间(数秒至数分钟不等,取决于实际网络覆盖情况),UE无数据上报(类似于UE脱网)。
解决方案:要解决此类掉话,需要改善覆盖。
具体手段有:1.首先明确当前的弱覆盖区域由哪些扇区的信号覆盖。
2.根据网络拓扑结构和相关无线环境来确定最适合覆盖该区域的扇区,并加强它的覆盖。
如常用的天馈调整、站点建设等。
具体案例:对呼和浩特市大昭寺前街DT过程中占用到大昭寺华隆小区-FL_3小区,覆盖较差存在掉线风险。
通过调整PA:3→0,RS参考功率:13.4dB→15.2dB,覆盖改善,掉线风险大大降低。
掉话原因2:越区覆盖现象:在支持切换的移动通信网络中,由于无法精确控制无线信号的传播,因此或多或少都会存在越区覆盖的情况,导致“孤岛覆盖”无法与周边站点进行正常切换掉话,通常有以下表现:1.越区覆盖导致的“导频污染”。
在覆盖区内,没有稳定的强信号作为主服务小区。
服务小区信号的频繁变化,是导致掉话的一个主要原因。
2.越区覆盖对主服务小区的干扰(包括邻区漏配、越区信号的迅速变化等)。
在某些区域,主服务小区收到越区信号的干扰,最终导致掉话。
解决方案:1.越区覆盖的一般优化原则是:在区域中已有合理的稳定信号覆盖的情况下,尽可能的控制越区覆盖的信号。
CIO设置不合理导致RRC连接重建问题处理【现象描述】进行TD-LTE网络DT测试过程中,车辆行至某两个小区边缘区域时,终端发起原因值为otherfailure的RRC重建,之前无RRC异常释放、RRC重建失败、切换失败等事件。
【原因分析】使用Assistant对测试Log进行分析,信令RRCReestablishAttempt原因值为otherfailure。
上图所示为RRC重建事件点,可看出重建发生在两小区边缘地带,不存在掉线等异常事件。
但此时主服务小区RSRP值为-69,而邻区RSRP值为-53,电平差值较大。
【分析流程】首先需要检查基站、传输等状态是否异常,排查基站、传输等问题后再进行分析。
整个切换过程异常情况我们分为几个阶段:测量报告发送后是否收到切换命令,收到重配命令后是否成功在目标测发送MSG1,成功发送MSG1之后是否正常收到MSG2;在某一环节出现问题我们可查询相应处理流程进行排查。
由于终端未收到切换命令,可能有两种情况:1、基站未收到测量报告(可通过后台信令跟踪检查):检查覆盖点是否合理,主要是检查测量报告点的RSRP,SINR等覆盖情况,确认终端是否在小区边缘,或存在上行功率受限情况(根据下行终端估计的路损判断)。
如果是该情况,按照现场情况调整覆盖,及切换参数,解决异常情况2、基站收到了测量报告:2.1基站未向终端发送切换命令情况:(1)确认目标小区是否为漏配邻区(2)需要检查是否目标小区未向源小区发送切换响应,或者发送HANDOVER PREPARATION FAILUE信令,在这种情况下源小区也不会向终端发送切换命令。
2.1基站向终端发送切换命令情况:主要检查测量报告上报点的覆盖情况,是否为弱场,或强干扰区域,优先建议通过工程参数解决覆盖问题,若覆盖不易调整则通过调整切换参数优化具体分析流程图如下:图1 流程图【分析过程】根据Serving+nighboring Cell图中显示,虽然服务小RSRP值还处于正常水平,但此时邻区电平值已高于服务小区16dBm,服务小区RSRQ已降低到-20。
LTE网络优化分析报告一、引言LTE(Long Term Evolution)是第四代无线通信技术,具有高速率、低时延、分组交换以及平坦的IP体系等优势,已经成为全球主流的移动通信网络技术。
然而,在LTE网络部署和运营过程中,仍然面临一些网络质量问题和优化挑战。
本报告针对LTE网络的优化进行了深入分析和研究,总结出可行的优化方案和建议,以提升网络性能和用户体验。
二、网络问题分析1.LTE网络覆盖问题:在实际应用中,LTE网络的覆盖范围存在一定的限制,尤其是在室内和复杂地理环境下容易出现盲区和弱覆盖区域。
2.LTE网络干扰问题:不同频段之间和相邻基站之间的干扰是LTE网络中一个主要的质量问题。
另外,周围的信号干扰,如电力线干扰和室内杂散干扰也会影响网络性能。
3.LTE网络容量问题:随着用户数量和用户对数据流量需求的增加,LTE网络容量可能成为限制网络性能和用户满意度的一个瓶颈。
高速率用户和热点区域的需求更加迫切。
4.LTE网络切换问题:在LTE网络中,切换是保证用户业务连续性和网络质量的关键。
网络切换过程中可能存在瞬时中断和延迟等问题。
三、优化方案和建议1.LTE覆盖优化方案:-合理规划增加基站覆盖,特别是在人口密集区、室内和边缘区域等盲区和弱覆盖区域。
- 利用Sector Splitting和MIMO等技术,提升基站的覆盖范围和容量。
- 利用Femtocell和Picocell等微型基站技术,增强室内覆盖和边缘区域覆盖效果。
2.干扰优化方案:-通过频率选择、频率规划和功率分配等手段,减小同一频段或相邻基站之间的干扰。
-引入干扰消除和干扰对消等技术,减小外部信号和杂散的影响。
3.容量优化方案:-通过增加基站数量、增加信道带宽和将MIMO技术用于高容量覆盖区域,提升LTE网络的容量。
- 对于高速率用户和热点区域,可以采用Small Cell、Carrier Aggregation等技术,增加网络的处理能力。
TD-LTE接入问题分析课程目标:●掌握LTE随机接入基本过程●理解LTE随机接入主要参数●理解PRACH信道规划思路●掌握一般接入问题的分析思路●掌握常见接入故障的解决方法目录第1章初始接入概述 (1)1.1初始接入信令流程 (1)1.2随机接入信令IE查看 (3)第2章接通率分析思路 (6)2.1随机接入问题分析 (6)2.1.1MSG1发送后是否收到MSG2 (8)2.1.2MSG3是否发送成功 (9)2.1.3MSG4是否正确接收 (9)2.2鉴权、加密问题分析 (10)2.3E-RAB建立问题分析 (10)第3章接入问题案例解析 (11)3.1MSG1多次重发未响应 (11)3.1.1问题现象 (11)3.1.2问题分析和解决 (12)3.1.3总结 (16)3.2MSG4冲突检测定时器超时 (17)3.2.1问题现象 (17)3.2.2问题分析 (19)3.2.3解决方法和验证 (24)第I页图目录图1-1初始接入信令流程图 (1)图1-2SIB2rach_Config (3)图1-3SIB2Prach_Config (4)图1-4CNT中msg1截图 (5)图2-1接通率分析思路 (6)图2-2基于竞争的随机接入 (7)图2-3MSG1分析思路 (8)图2-4MSG4fail分析思路 (10)图3-1MSG1多次发送未响应 (11)图3-2MSG1无响应时的RSRP (12)图3-4msg4fail(QCAT) (19)图3-5msg4fail cause(QCAT) (20)图3-6正常起呼随机接入过程(QCAT) (20)图3-7正常起呼PDCCH decoding Result(QCAT) (21)图3-8正常起呼PDSCH统计(QCAT) (21)图3-9多次PDCCH未收到PDSCH(QCAT) (21)图3-10UE收到第一次PDCCH的解码(QCAT) (22)图3-11UE收到第二次PDCCH的解码(QCAT) (22)图3-12UE未收到PDSCH(QCAT) (23)图3-13UE未收到PDCCH的消息流程(QCAT) (23)图3-14UE未收到PDSCH(QCAT) (24)图3-15第一次msg4fail,随机接入重发后接入成功(QCAT) (24)图3-16随机接入重发后收到PDSCH(QCAT) (25)图3-17第二次msg4fail,随机接入重发后接入成功(QCAT) (25)第II页表目录表3-1修改PRACH检测门限后的接通率 (12)表3-2短呼接通率统计 (17)表3-3未接通呼叫分析 (18)表3-4解码重传PDCCH的MCS为29 (22)第III页第1章初始接入概述在TD-LTE系统中,处于Inactive状态或IDLE状态的UE通过发起attach request或Service Request触发初始随机接入,建立RRC连接,再通过初始直传建立传输NAS消息的信令连接,最后建立E-RAB。
LTE网络优化分析报告分析一、背景随着移动通信技术的不断发展和用户对高速数据业务的需求增加,LTE网络逐渐成为主流无线通信技术。
然而,在实际网络运行中,用户可能会遇到网络质量不佳、信号覆盖区域不广等问题,需要对LTE网络进行优化分析,以提升网络性能和用户体验。
二、问题分析1.网络质量不佳用户在使用LTE网络时,可能会遇到网络延迟高、网速慢等问题,影响了用户的使用体验和满意度。
2.信号覆盖区域不广三、优化方案1.增加基站数量和功率增加基站数量和功率可以提高信号覆盖范围和网络容量,减少用户遇到信号盲区的概率,提升网络质量和用户体验。
2.优化网络参数配置通过调整LTE网络的参数配置,如功率控制、天线倾斜角度等,可以进一步改善信号质量和覆盖范围,减少干扰和盲区。
3.加强网络监控和故障排查建立有效的监控系统,及时发现网络故障和问题,并进行快速解决,可以提高网络的稳定性和可靠性。
4.引入优化工具和算法借助优化工具和算法,对网络进行深入分析和调整,优化网络资源分配和使用效率,提升网络性能和用户体验。
四、优化效果评估通过实施上述优化方案,可以得到以下优化效果:1.网络质量提升通过增加基站和调整参数配置,可以显著提高网络质量,降低延迟和提升网速,提升用户体验和满意度。
2.信号覆盖范围扩大通过增加基站数量和功率,减少信号盲区的出现,提高信号覆盖范围,使更多用户能够正常使用网络业务。
3.故障处理效率提升加强网络监控和故障排查,能够快速发现和解决网络故障,提高网络稳定性和可靠性,并减少用户遇到问题的概率。
4.网络资源利用率提高通过引入优化工具和算法,优化网络资源的使用效率,提高网络性能的同时,减少了资源浪费,实现了资源的最大化利用。
五、结论通过对LTE网络进行优化分析,可以解决网络质量不佳和信号覆盖区域不广的问题,提升用户体验和满意度。
优化方案包括增加基站数量和功率、优化网络参数配置、加强网络监控和故障排查、引入优化工具和算法等。
LTE室分故障分析引言:LTE(Long Term Evolution)是第四代移动通信技术,室分(In-Building Distributed Antenna System)是为了解决室内无线信号覆盖问题而设计的系统。
然而,由于各种原因,室分系统可能出现故障,影响用户的无线通信质量。
本文将针对LTE室分故障进行分析,并提供解决方案。
一、故障类型及原因:1.无信号故障:室分系统无法接收到室外基站的信号,可能的原因包括天线连接问题、射频馈线故障、设备故障等。
2.信号衰减故障:室分系统接收到室外基站的信号,但信号强度衰减较大,影响室内的无线通信质量。
可能的原因包括射频馈线衰减、馈线连接问题、天线方向问题等。
3.随机掉线故障:室分系统在使用过程中,用户会出现随机的掉线现象,可能的原因包括信号干扰、设备故障、天线方向问题等。
二、故障分析与解决方案:1.无信号故障分析与解决方案:(1)天线连接问题:首先检查天线连接是否松动或脱落,及时进行排除。
(2)射频馈线故障:检查射频馈线是否受损或接触不良,可进行馈线更换或重新连接。
(3)设备故障:检查设备是否正常工作,如有故障,及时维修或更换设备。
2.信号衰减故障分析与解决方案:(1)射频馈线衰减:检查射频馈线是否老化或损坏,及时更换损坏的馈线。
(2)馈线连接问题:检查馈线连接是否紧固,确保连接良好。
(3)天线方向问题:检查天线的指向是否正确,确保信号可覆盖到室内各个区域。
3.随机掉线故障分析与解决方案:(1)信号干扰:检查是否有外部无线信号干扰,如有,采取屏蔽措施或调整室分系统频段。
(2)设备故障:检查室分系统设备是否正常工作,如有故障,及时维修或更换设备。
(3)天线方向问题:检查天线的指向是否正确,确保信号可覆盖到用户所在位置。
三、故障预防:1.定期巡检:定期对室分系统进行巡检,检查设备是否正常工作,馈线连接是否紧固。
2.常规维护:定期对馈线进行检查和清洗,保持良好的连接质量。
移动L T E V O L T E案例分析汇总Coca-cola standardization office【ZZ5AB-ZZSYT-ZZ2C-ZZ682T-ZZT18】广东移动4GTD-LTE详细案例分析案例1:580PreconditionFailure导致的未接通。
【问题描述】在集团测试LOG中,存在PreconditionFailure导致的失败事件,表现为呼叫过程中,终端主动上发或收到网络侧下发的580PreconditionFailure消息,随后呼叫中止,出现未接通事件。
Log文件名:MOUE:MTUE:时间:10:16:【问题分析】1、呼叫过程中,被叫发送Ringing180后,收到网络下发的专载去激活命令,QCI1被释放,被叫随后上报580PreconditionFailure,主叫同样收到网络侧转发的580消息,呼叫接续中止,导致未接通。
2、从信令中可以看到,被叫回复Ringing180且主叫也已经收到Ringing180,被叫随后收到网络侧下发的RRC重配,携带有QCI1被释放的信息,被叫去激活专有承载。
由于专载已被释放,业务资源已不存在,所以被叫上发580PreconditionFailure失败消息。
主叫收到网络侧下发的580,接续被中止,导致了会话未接通。
3、从MME下发到NodeB的E-RABRELEASECOMMAND,原因上看是Nas层nomal_release,导致专载QCI1被释放。
4、专载QCI1被释放,去激活后,被叫发送INVITE580,主叫收到网络侧转发的INVITE580,会话流程中断,导致未接通【问题定位】在正常的会话流程中,由于MME下发E-RABRELEASECOMMAND,使得QCI1被释放,导致未接通。
【解决措施】需要核心网查看MME在什么情况下会下发E-RABRELEASECOMMAND。
【测试验证】案例2:ServerInternalError500导致的未接通【问题描述】在集团测试LOG中,存在ServerInternalError导致的失败事件,表现为呼叫过程中,终端主动收到网络侧下发的ServerInternalError500消息,随后呼叫中止,出现未接通事件。
1、无线接通率指标无线接通率=RRC连接建立成功率*E-RAB建立成功率=(RRC连接建立完成次数/RRC连接请求次数(不包括重发))*E-RAB建立成功总次数/E-RAB建立尝试总次数*100%1.1、 RRC连接建立成功率RRCSetupSuccessRate=(L.RRC.ConnReq.Succ)/(L.RRC.ConnReq.Att)*100%话统统计方法:RRC建立统计点【A点】(1)指标L.RRC.ConnReq.Att加1,不统计重发的次数。
Case1:eNB下发RRC_Conn_Setup消息后,在T300定时器超时前,收到相同的UeID发起的RRC_Conn_Req(Setup丢失,UE MAC冲突解决定时器超时后重发RRC_Conn_Req,UeID 不变),记为一次重发RRC_Conn_Req消息。
Case2:T300超时后,UE仍未收到RRC_Conn_Setup,UE重新搜网,发起初始接入,UeID 是取0~239的随机值或上层下发的TMSI。
eNB侧记为新的一次初始接入,L.RRC.ConnReq.Att 加1。
Case3:发起Attach后会启动T3410定时器。
如果UE发出RRC_Conn_Setup_Cmp后,ENB没有收到,UE会在定时器超时后重新发起Attach,ENB侧记为新的一次初始接入;RRC_Conn_Setup_Cmp丢失不会触发重建,发起重建的前提是安全已经激活。
(2)如果RRC Connection Request消息信元Establishment Cause为“emergency”,指标L.RRC.ConnReq.Att.Emc加1。
(3)如果RRC Connection Request消息信元Establishment Cause为“highPriorityAccess”,指标L.RRC.ConnReq.Att.HighPri加1。
(4)如果RRC Connection Request消息信元Establishment Cause为“mt-Access”,指标L.RRC.ConnReq.Att.Mt加1。
(5)如果RRC Connection Request消息信元Establishment Cause为“mo-Singnalling”,指标L.RRC.ConnReq.Att.MoSig加1。
(6)如果RRC Connection Request消息信元Establishment Cause为“mo-Data”,指标L.RRC.ConnReq.Att.MoData加1。
【B点】当eNodeB下小区接收到UE发送的RRC Connection Request消息并下发RRC Connection Setup消息给UE时,指标L.RRC.ConnSetup加1。
【C点】当eNodeB收到UE返回的RRC Connection Setup Complete消息时统计相应指标,L.RRC.ConnReq.Succ加1。
1.2 、ERAB建立成功率ErabSetupSuccessRate=(L.E-RAB.SuccEst)/(L.E-RAB.AttEst)*100%话统统计方法:图4如上图中A点所示,当eNodeB收到来自MME的E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST(初始上下文设置请求)消息时统计该指标。
如果E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息中要求同时建立多个E-RAB,则相应指标按各个业务的QCI分别进行累加。
2、接入性能优化流程接入失败通常有三大类原因:无线侧参数配置问题、信道环境影响以及核心网侧配置问题。
因此无线接通率优化流程可以按以下步骤进行:(1)通过话统分析是否出现接入成功率低的问题,当前RRC\eRAB接通率指标一般为98%,也可根据对接入成功率指标的特殊要求启动问题定位。
(2)确认是否全网指标恶化,如果是全网指标恶化,需要检查操作,告警,是否存在网络变动和升级行为。
检查无线侧以及核心网侧参数配置是否合理,如定时器T300、T302、T3410,以及参数小区接入禁止、小区最小接入电平、IPPATH、Ncs等。
(3)如果是部分站点指标恶化,影响全网指标,需要找出TOP站点。
(4)查询RRC连接建立和ERAB建立成功率最低的TOP10站点和TOP时间段。
(5)查看TOP站点告警,检查单板状态,RRU状态,小区状态,OM操作,配置是否异常。
(6)针对TOP站点进行针对性的标准信令跟踪、干扰检测进行分析。
(7)如果标准信令和干扰检测无异常,将一键式日志,标口跟踪,干扰检测结果返回给厂家技术人员分析。
接入问题优化流程图如下图所示:接入问题优化流程图3、接入问题排查分析3.1、E_NB配置问题排查✧PDCCH符号数配置问题测试局点为了尽可能提高下行吞吐率,PDCCH通常固定1符号,但在20M带宽以下,可能出现无法接入的问题。
5M小区,PDCCH固定1符号,总共能使用的CCE个数为3,由于CCE资源受限接入不了。
10M小区,PDCCH固定1符号,总共能使用的CCE个数为8个,受上下行配比约束,下行最多能用5个,而10M小区公共信令的聚合级别为8,需要8个,因此CCE资源受限所以接入不了。
15M小区,PDCCH固定1符号,总共能使用的CCE个数为12,受上下行配比约束,下行最多能用8个,PDCCH功控开关关闭时可以接入。
PDCCH符号数配置✧IPPATH配置问题基站在完成了安全的配置与UE能力的获取后并向小区申请资源,会向TRM申请GTPU资源,如果申请资源失败则会向核心网返回初始上下文建立失败响应INIT_CONTEXT_SETUP_FAIL;原因值填写transport resource unavailable(0);如下图所示:初始上下文建立失败响应信令截图在这种情况下,对照开站summary首先查看一下MML中的IPPATH是否配置正确,如果已经配置正确,则查看请初始上下文建立请求消息(INIT_CONTEXT_SETUP_REQ消息)中transportlayeraddress的信元值是否为配置的IPPATH值,如果不一样则需要确认一下是我们配置错误还是核心网填写错误。
同时查看路由信息配置是否正确,如果IPPATH正确,但路由错误,同样会出现传输资源不可用的错误信息。
如果以上都不符合则需要把IFTS打开,将跟踪发给厂家技术人员来确认问题的原因。
初始上下文建立请求消息信令3.2、top小区分析处理3.2.1、TOP小区筛选通过U2000导出全网每日话统文件,按照(L.RRC.ConnReq.Att-L.RRC.ConnReq.Succ)次数从高到低排序,结合接入成功率,选出TOP10站点接入成功率低的小区。
按照(L.E-RAB.AttEst-L.E-RAB.SuccEst)次数从高到低排序,结合ERAB建立成功率选出TOP10 ERAB建立成功率低的站点。
目前TOP小区提取暂按以下方式操作:①RRC请求次数大于50次②接通率小于98%。
③在一周之类重复出现2次以上的小区。
若前三种无法提取出TOP小区,可按RRC,ERAB建立失败次数,分开求和后降序排列筛选RRC 和ERAB建立失败的TOP小区。
3.2.2、TOP小区状态检查检查TOP小区的状态是否正常,可以在U2000上,通过MML命令“DSP CELL”能查看到小区的总体信息。
如果小区状态显示不是“正常”,可以按如下方法进行简单排查:➢如果存在S1链路异常告警,请检查S1链路配置是否正确。
➢如果存在RSSI/RSRP通道不平衡,需要检查天馈互调干扰,➢如果存在驻波告警,需要通过DSP TXBRANCH,DSP RXBRANCH查看RRU发射和接收通道状态。
➢如果存在小区不可用告警,需要返回主控和基带板一键式日志。
3.2.3、TOP小区指标分析通过话统可以得出TOP小区原因分布,TOP小区中RRC和ERAB建立失败次数原因值说明:①对小区RRC建立失败次数:➢资源分配失败而导致RRC连接建立失败的次数,指标ID:1526727083;重点关注top 资源是否足够,包括top用户数,传输、PRB等;➢UE无应答而导致RRC连接建立失败的次数,指标ID:1526727084;关注质差、干扰、无线环境等;➢小区发送RRC Connection Reject消息次数,指标ID:1526728269;关注传输问题、是否拥塞、干扰;➢因为SRS资源分配失败而导致RRC连接建立失败的次数,指标ID:1526728485;重点关注SRS带宽、配置指示、配置方式、SRS ACK/NACK设置是否合理等;➢因为PUCCH资源分配失败而导致RRC连接建立失败的次数,指标ID:1526728486;关注PUCCH信道相关参数设置是否合理,CQI RB数配置是否合理等;➢流控导致的RRC Connection Request 消息丢弃次数,指标ID:1526728489;关注拥塞,业务流控相关参数是否设置正确等;➢流控导致的发送RRC Connection Reject消息次数,指标ID:1526728490;关注拥塞,业务流控相关参数是否设置正确等;②对小区E-RAB建立失败次数:➢因未收到UE响应而导致E-RAB建立失败的次数,指标ID:1526726717;处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。
➢核心网问题导致E-RAB建立失败次数,指标ID:1526728276;处理建议:需跟踪信令,排查核心网问题(EPC参数设置,TAC码设置的一致性,对用户开卡限制,硬件故障方面排查);➢传输层问题导致E-RAB建立失败次数,指标ID:1526728277;处理建议:需查询传输是否有故障,高误码,闪断,传输侧参数设置问题。
➢无线层问题导致E-RAB建立失败次数,指标ID:1526728278;处理建议:处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。
➢无线资源不足导致E-RAB建立失败次数,指标ID:1526728279;处理建议:1、排查TOP小区资源是否足够,是否故障引起,若存在资源不足问题,可考虑参数调整,流量均衡(小区选择,重选和切换类参数);2、结合现场调整天馈,流量均衡;3、热点区域,增补基站等;➢安全模式配置失败导致E-RAB建立失败次数,指标ID:1526728280;处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。