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。
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参数设置错误,终端及用户行为异常等原因。