FDD-LTE掉线问题处理思路及流程研究.docxVIP

FDD-LTE掉线问题处理思路及流程研究 安徽电信无线网络优化中心 【摘 要】本案例对于LTE掉线问题进行了系统分析，并针对不同的场景，给出了快速定位问题的方法，并总结归纳出相应的处理思路及流程，对及时处理掉线问题具有可借鉴意义。 【关键字】FDD-LTE 掉线 TOP小区 【研究背景】 LTE掉线率是判定网络性能的一个重要指标。掉线率的高低在一定程度上体现了移动网通信质量的优劣,过高的掉线率会导致网络性能下降,影响用户感知。本文从LTE无线网的掉线原因分析,针对区域性质及TOP小区性质的掉线,总结归纳出相应的处理流程及思路,为LTE优化人员提供参考。 【原因分析】 一、掉线公式定义 定义FDD-LTE网络掉线率如下： Call Drop Rate = L.E-RAB.AbnormRel/（ L.E-RAB.NormRel + L.E-RAB.AbnormRel ）*100% 其中，L.E-RAB.AbnormRel为小区异常释放用户E-RAB的总次数；L.E-RAB.NormRel为小区正常释放用户E-RAB的总次数。 二、触发掉线的机制 触发异常释放的机制：空口重同步失败；空口RLC 达到最大重传次数；资源拥塞；传输故障；eNB/MME内部异常。 （一）空口重同步失败 在eNodeB侧检测到的失步为上行失步，在失步时有下行数据到达后，eNodeB主动发起重同步，基站会通过通知UE发起随机接入，同时携带一个专用的Preamble给UE，UE用该专用Preamble发起接入，重同步详细流程如下： 图1：空口重同步流程 eNodeB发起重同步消息后，L2 MAC会启动定时器，如果定时器超时还没有收到UE响应的专用Preamble，则上报L3，指示由于下行数据触发的重同步失败，L3启动延迟释放定时器，在定时器超时后释放UE。 （二）空口RLC达到最大重传次数 在MAC层发送RLC数据时，几次HARQ重传都失败的情况下，会有RLC层的非确认，RLC会发起重传；在没有收到对端状态PDU的情况下，定时器超时触发RLC重传，对于没有收到对端状态PDU的原因有两个，一个原因为UE侧根本就没有收到任何RLC PDU，也就不会响应状态PDU，另一个原因为UE响应的状态PDU，由于上行误码没有到达eNodeB。 2.3资源拥塞 如图2所示，eNodeB向MME发送E-RAB RELEASE INDICATION消息，如果异常释放在A处打点在L.E-RAB.AbnormRel.Cong Counter下，可以判定为该掉线是由于资源拥塞问题导致的掉线。 图2：拥塞问题导致掉线 拥塞掉线一般为用户数超过license规格限制，高优先级用户抢占低优先级用户资源造成低优先级用户掉线。 （四）传输掉线 GTPU为用户面隧道协议，在两个端点间建立专用隧道，传输用户数据，在S1-u接口实现隧道功能，满足多个用户共享少数传输通道的需求，在X2-u接口实现隧道功能，传递数据和某些信息（如PDCP SN），空口并不涉及GTP-U协议。 图3：GTPU协议层在LTE/SAE网络的示意图 GTPU检测是利用GTPU协议中的GTPU_ECHO_REQ和GTPU_ECHP_RESP报文，检测基站上的PATH链路(IPPATH和EPPATH)通断的一种功能，当eNodeB侧收到对端发送的GTPUErr IND消息，或检测到IPPATH Down，会给RR发送GTPU Reset消息，之后主动释放用户承载，RR给MME发送S1AP_UE_CONTEXT_REQ消息，释放原因为Transport-resource-unavailable，详细信令如下： 图4：传输掉线信令 （五）MME掉线 MME掉线L.E-RAB.AbnormRel.MME统计图5所示的A点。MME主动发起E-RAB或UE CONTEXT释放流程，当eNodeB收到来自MME的E-RAB RELEASE COMMAND或CONTEXT RELEASE COMMAND消息时，且释放原因不为“Normal Release”，“Detach”，“User Inactivity”，“CS Fallback triggered”，“UE Not Available for PS Service”，“Inter-RAT Redirection”，“Successful Handover”统计L.E-RAB.AbnormRel.MMETot指标，当判断相应承载有数传时，统计L.E-RAB.AbnormRel.MME指标。如果E-RAB RELEASE COMMAND消息中要求同时释放多个E-RAB，则相应指标按具体业务数目进行累加。 图5：MME掉线 当S1观察到核心网主动发送E-RAB RELEASE COMMAND