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

1、FDD-LTE掉线问题处理思路及流程研究安徽电信无线网络优化中心 【摘 要】本案例对于LTE掉线问题进行了系统分析，并针对不同的场景，给出了快速定位问题的方法，并总结归纳出相应的处理思路及流程，对及时处理掉线问题具有可借鉴意义。【关键字】FDD-LTE 掉线 TOP小区【研究背景】LTE掉线率是判定网络性能的一个重要指标。掉线率的高低在一定程度上体现了移动网通信质量的优劣,过高的掉线率会导致网络性能下降,影响用户感知。本文从LTE无线网的掉线原因分析,针对区域性质及TOP小区性质的掉线,总结归纳出相应的处理流程及思路,为LTE优化人员提供参考。【原因分析】一、掉线公式定义定义FDD-LTE网络

2、掉线率如下：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发起随机接入，同时携带一

3、个专用的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，也

4、就不会响应状态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接口实现隧道功能，满足多个用户共享少数传输通道的需求，在X

5、2-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，详细信令如下

6、：图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”

7、统计L.E-RAB.AbnormRel.MMETot指标，当判断相应承载有数传时，统计L.E-RAB.AbnormRel.MME指标。如果E-RAB RELEASE COMMAND消息中要求同时释放多个E-RAB，则相应指标按具体业务数目进行累加。图5：MME掉线当S1观察到核心网主动发送E-RAB RELEASE COMMAND或CONTEXT RELEASE COMMAND消息，释放原因值包括ho-failure-in-target-EPC-eNB-or-target-system、release-due-to-eutran-generated-reason及unspecified等。图6

8、：核心网主动释放流程【解决方法】一、问题确认（一）掉线问题范围分析，按照筛选规则确认是整网问题还是TOP小区问题；（二）场景分析：是搬迁、升级、扩容等趋势恶化场景还是存量优化场景，例如新建网络；（三）掉线趋势分析：掉线率长期变化趋势，切换成功率长期变化趋势，掉线率与负载(空口负载，单板CPU负载）变化关系图；（四）定位“Top小区”问题或整网问题：分别去除TOP10的”掉线率TOP小区”和”掉线次数TOP小区”后，如果整网掉线率明显改善且与原来持平(或者达到了目标值)，则定义为TOP小区问题；如果分别去除TOP10的”掉线率TOP小区”和”掉线次数TOP小区”后整网掉线率没有明显改善，则定义为

9、整网问题。（二）指标趋势分析掉线率长期趋势分析，确认是逐渐恶化还是突然恶化。如果是突然恶化，那么在转折点附近寻找异常；如果是逐渐恶化则需要分析负载、容量、当地话务模型。掉线率趋势线与切换成功率、RB利用率、用户数、CPU负载趋势线密切相关。可以通过这些趋势线推导掉线率恶化原因。如下所示：掉线率逐渐升高，分析关联指标，切换成功率一直恶化，可以判定掉线率升高与切换失败有关。（三）掉线原因分析根据话统失败原因值和关联指标对问题进行初步分类，推理可能原因，不同的问题原因后续优先采用的动作以及顺序有差别。图7：典型掉线原因分析与建议动作（四）参数核查1.TOP小区问题：将问题小区参数与正常站点参数进行数

10、据比对，对差异参数进行分析；2.整网问题：全网参数核查，排查出不符合基线或存在差异的参数配置，分析异常参数对掉线指标的影响。（五）操作日志排查查询指标异常时间段有无影响指标的操作。（六）设备故障排查排查掉线率异常期间有无影响掉线的故障告警。图8：华为LTE网管告警示意图（七）弱覆盖问题排查若后台数据排查掉线原因主要是LE-RAB.AbnormRel.Radio，表示异常释放主要原因为上行弱覆盖和信号陡降，则需要对TOP小区进行覆盖排查。图9：弱覆盖导致掉线根据路测数据排查，掉线发生在DL RSRP<-119dBm以下，判断为弱覆盖导致掉线，通过对照路测信令与基站信令跟踪，可以判断掉线原因

11、，如果路测信令中发了上行信令，而基站侧信令中没有收到该信令，结合DL RSRP可以判断属于上行弱覆盖还是上行干扰问题。（八）切换问题排查1.邻区漏配可能导致用户无法切换或者切换到次优小区；2.邻区漏配可能导致用户切换到错误小区而失败；3.目标小区半径配置过小（小于切换点到目标基站距离）也会导致切换入失败；4.实际目标小区PCI与源站点邻区关系配置中的邻区PCI冲突。例如，提取包河大道与环湖路交口西北角2小区与巢湖忠庙碧桂园1小区两两小区切换指标，主要是包河大道与环湖路交口西北角2小区向巢湖忠庙碧桂园1小区切换失败，两站分别位于巢湖两岸，距离19.59km，超远邻区导致切换失败。图10：超远邻区

12、导致切换失败（九）容量排查排查目标小区是否存在单板过载告警，如果存在告警，进一步按照告警帮助查看是否存在CPU过载问题，若单板使用率>90%，则单板负载过高，例如查询某站CPU利用流程如图11所示，单板使用率在均在22%以下，排除单板负载过高引起的掉线可能。图11：某站连续5天单板使用率跟踪排查目标小区是否存在最大用户数超过规格，如果超过规格及时增加License或对站点进行扩容。例如查询某站小区最大用户数如图12所示，均在10个以下，排除用户过多导致掉线可能。图12：某站连续5天小区内最大用户数跟踪（十）射频通道问题排查分析是否存在射频通道相关告警，例如射频单元驻波告警、射频通道接收信

13、道RTWP/RSSI过低告警、射频通道接受通道RTWP/RSSI不平衡告警、射频单元发射通道增益异常告警、射频单元过载告警、射频单元输入功率异常告警、射频单元光接口性能恶化告警、射频单元光模块收发异常告警、射频单元光模块故障告警等。（十一）核心网问题排查1.通过标口流程确认是否与已知的核心网问题相同（例如S1切换和X2切换交叉过程中核心网流程冲突），或者是否问题时间点核心网有改动而基站无任何操作。2.通过标口分析是否基站发送了S1_PATH_SWITCH_REQ后核心网回复S1_PATH_SWITCH_REQ_FAIL，如图13所示。图13：S1_PATH_SWITCH_REQ_FAIL（十二

14、）传输问题排查对于传输问题引起的掉线需要分类进行排查。非同一传输节点下的TOP小区问题，需要对TOP小区逐个定位；同一传输节点下的局部小区问题，定位传输节点问题；整网问题则定位为统管全网的传输节点问题或UGW异常。1.排查是否出现SCTP链路故障告警、IP Path故障告警、传输光接口性能恶化、以太网链路故障告警等，判断告警时间是否与掉线时间一致。2.检查VLAN，DSCP，IPRT，IPPATH，SCTP等传输参数配置与规划是否一致。3.通过S1标口信令，检查上下文建立错误用户的INITIAL_CONTEXT_SETUP_REQ中transportLayerAddress是否与基站配置IPPATH对端地址的一致，如地址在基站侧不存在，则添加。分析掉线原因为TNL的内部释放原因，释放原因为UEM_UECNT_REL_RET_IPPATH、UEM_UECNT_RELRECV_GTPU_RESET_BEAR_REQ，此时可能为GTPU问题，需要进行GTPU检测确认GTPU是否正常，如果是GTPU请求响应超时，则需要传输与核