getconnectiontimeoutexception 网络问题排查_「优化技能」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，

(五)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，则相应指标按具体业务数目进行累加。

图4：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等。

【解决方法】

一、问题确认

(一)掉线问题范围分析，按照筛选规则确认是整网问题还是TOP小区问题；

(二)场景分析：是搬迁、升级、扩容等趋势恶化场景还是存量优化场景，例如新建网络；

(三)掉线趋势分析：掉线率长期变化趋势，切换成功率长期变化趋势，掉线率与负载(空口负载，单板CPU负载)变化关系图；

(四)定位“Top小区”问题或整网问题：分别去除TOP10的”掉线率TOP小区”和”掉线次数TOP小区”后，如果整网掉线率明显改善且与原来持平(或者达到了目标值)，则定义为TOP小区问题；如果分别去除TOP10的”掉线率TOP小区”和”掉线次数TOP小区”后整网掉线率没有明显改善，则定义为整网问题。

(二)指标趋势分析

掉线率长期趋势分析，确认是逐渐恶化还是突然恶化。如果是突然恶化，那么在转折点附近寻找异常；如果是逐渐恶化则需要分析负载、容量、当地话务模型。

掉线率趋势线与切换成功率、RB利用率、用户数、CPU负载趋势线密切相关。可以通过这些趋势线推导掉线率恶化原因。如下所示：掉线率逐渐升高，分析关联指标，切换成功率一直恶化，可以判定掉线率升高与切换失败有关。

(三)掉线原因分析

根据话统失败原因值和关联指标对问题进行初步分类，推理可能原因，不同的问题原因后续优先采用的动作以及顺序有差别。

图5：典型掉线原因分析与建议动作

(四)参数核查

1.TOP小区问题：将问题小区参数与正常站点参数进行数据比对，对差异参数进行分析；

2.整网问题：全网参数核查，排查出不符合基线或存在差异的参数配置，分析异常参数对掉线指标的影响。

(五)操作日志排查

查询指标异常时间段有无影响指标的操作。

(六)设备故障排查

排查掉线率异常期间有无影响掉线的故障告警。

(七)弱覆盖问题排查

若后台数据排查掉线原因主要是LE-RAB.AbnormRel.Radio，表示异常释放主要原因为上行弱覆盖和信号陡降，则需要对TOP小区进行覆盖排查。

图6：弱覆盖导致掉线

根据路测数据排查，掉线发生在DL RSRP

(八)切换问题排查

1.邻区漏配可能导致用户无法切换或者切换到次优小区；

2.邻区漏配可能导致用户切换到错误小区而失败；

3.目标小区半径配置过小(小于切换点到目标基站距离)也会导致切换入失败；

4.实际目标小区PCI与源站点邻区关系配置中的邻区PCI冲突。

例如，提取包河大道与环湖路交口西北角2小区与巢湖忠庙碧桂园1小区两两小区切换指标，主要是包河大道与环湖路交口西北角2小区向巢湖忠庙碧桂园1小区切换失败，两站分别位于巢湖两岸，距离19.59km，超远邻区导致切换失败。

(九)容量排查

排查目标小区是否存在单板过载告警，如果存在告警，进一步按照告警帮助查看是否存在CPU过载问题，若单板使用率>90%，则单板负载过高，例如查询某站CPU利用流程如图11所示，单板使用率在均在22%以下，排除单板负载过高引起的掉线可能。

排查目标小区是否存在最大用户数超过规格，如果超过规格及时增加License或对站点进行扩容。例如查询某站小区最大用户数如图12所示，均在10个以下，排除用户过多导致掉线可能。

(十)射频通道问题排查

分析是否存在射频通道相关告警，例如射频单元驻波告警、射频通道接收信道RTWP/RSSI过低告警、射频通道接受通道RTWP/RSSI不平衡告警、射频单元发射通道增益异常告警、射频单元过载告警、射频单元输入功率异常告警、射频单元光接口性能恶化告警、射频单元光模块收发异常告警、射频单元光模块故障告警等。

(十一)核心网问题排查

1.通过标口流程确认是否与已知的核心网问题相同(例如S1切换和X2切换交叉过程中核心网流程冲突)，或者是否问题时间点核心网有改动而基站无任何操作。

2.通过标口分析是否基站发送了S1_PATH_SWITCH_REQ后核心网回复S1_PATH_SWITCH_REQ_FAIL，如图13所示。

图7：S1_PATH_SWITCH_REQ_FAIL

(十二)传输问题排查

对于传输问题引起的掉线需要分类进行排查。非同一传输节点下的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请求响应超时，则需要传输与核心网共同分析；如果是GTPU Err Ind，则需要联合核心网一期分析对方发送Err Ind的原因。

eNodeB收到核心网侧发送的ErrIND，导致GTPU异常释放，需要核心网侧确认下发ErrIND的原因。

【结论与推广】

对于掉线问题，针对不同的场景，按照本文所述规定动作对各个环节进行排查分析，能够对问题进行快速定位，增加问题处理的时效性，及时处理FDD-LTE掉线问题，提升网络指标与用户感知。