FDD-LTE掉線問題處理思路及流程研究

1、FDD-LTE掉線問題處理思路及流程研究安徽電信無(wú)線網(wǎng)絡(luò)優(yōu)化中心 【摘 要】本案例對(duì)于LTE掉線問題進(jìn)行了系統(tǒng)分析，并針對(duì)不同的場(chǎng)景，給出了快速定位問題的方法，并總結(jié)歸納出相應(yīng)的處理思路及流程，對(duì)及時(shí)處理掉線問題具有可借鑒意義?！娟P(guān)鍵字】FDD-LTE 掉線 TOP小區(qū)【研究背景】LTE掉線率是判定網(wǎng)絡(luò)性能的一個(gè)重要指標(biāo)。掉線率的高低在一定程度上體現(xiàn)了移動(dòng)網(wǎng)通信質(zhì)量的優(yōu)劣,過高的掉線率會(huì)導(dǎo)致網(wǎng)絡(luò)性能下降,影響用戶感知。本文從LTE無(wú)線網(wǎng)的掉線原因分析,針對(duì)區(qū)域性質(zhì)及TOP小區(qū)性質(zhì)的掉線,總結(jié)歸納出相應(yīng)的處理流程及思路,為L(zhǎng)TE優(yōu)化人員提供參考。【原因分析】一、掉線公式定義定義FDD-LTE網(wǎng)絡(luò)

2、掉線率如下：Call Drop Rate = L.E-RAB.AbnormRel/（ L.E-RAB.NormRel + L.E-RAB.AbnormRel ）*100%其中，L.E-RAB.AbnormRel為小區(qū)異常釋放用戶E-RAB的總次數(shù)；L.E-RAB.NormRel為小區(qū)正常釋放用戶E-RAB的總次數(shù)。二、觸發(fā)掉線的機(jī)制觸發(fā)異常釋放的機(jī)制：空口重同步失敗；空口RLC 達(dá)到最大重傳次數(shù)；資源擁塞；傳輸故障；eNB/MME內(nèi)部異常。（一）空口重同步失敗在eNodeB側(cè)檢測(cè)到的失步為上行失步，在失步時(shí)有下行數(shù)據(jù)到達(dá)后，eNodeB主動(dòng)發(fā)起重同步，基站會(huì)通過通知UE發(fā)起隨機(jī)接入，同時(shí)攜帶一

3、個(gè)專用的Preamble給UE，UE用該專用Preamble發(fā)起接入，重同步詳細(xì)流程如下：圖1：空口重同步流程eNodeB發(fā)起重同步消息后，L2 MAC會(huì)啟動(dòng)定時(shí)器，如果定時(shí)器超時(shí)還沒有收到UE響應(yīng)的專用Preamble，則上報(bào)L3，指示由于下行數(shù)據(jù)觸發(fā)的重同步失敗，L3啟動(dòng)延遲釋放定時(shí)器，在定時(shí)器超時(shí)后釋放UE。（二）空口RLC達(dá)到最大重傳次數(shù)在MAC層發(fā)送RLC數(shù)據(jù)時(shí)，幾次HARQ重傳都失敗的情況下，會(huì)有RLC層的非確認(rèn)，RLC會(huì)發(fā)起重傳；在沒有收到對(duì)端狀態(tài)PDU的情況下，定時(shí)器超時(shí)觸發(fā)RLC重傳，對(duì)于沒有收到對(duì)端狀態(tài)PDU的原因有兩個(gè)，一個(gè)原因?yàn)閁E側(cè)根本就沒有收到任何RLC PDU，也

4、就不會(huì)響應(yīng)狀態(tài)PDU，另一個(gè)原因?yàn)閁E響應(yīng)的狀態(tài)PDU，由于上行誤碼沒有到達(dá)eNodeB。2.3資源擁塞如圖2所示，eNodeB向MME發(fā)送E-RAB RELEASE INDICATION消息，如果異常釋放在A處打點(diǎn)在L.E-RAB.AbnormRel.Cong Counter下，可以判定為該掉線是由于資源擁塞問題導(dǎo)致的掉線。圖2：擁塞問題導(dǎo)致掉線擁塞掉線一般為用戶數(shù)超過license規(guī)格限制，高優(yōu)先級(jí)用戶搶占低優(yōu)先級(jí)用戶資源造成低優(yōu)先級(jí)用戶掉線。（四）傳輸?shù)艟€GTPU為用戶面隧道協(xié)議，在兩個(gè)端點(diǎn)間建立專用隧道，傳輸用戶數(shù)據(jù)，在S1-u接口實(shí)現(xiàn)隧道功能，滿足多個(gè)用戶共享少數(shù)傳輸通道的需求，在X

5、2-u接口實(shí)現(xiàn)隧道功能，傳遞數(shù)據(jù)和某些信息（如PDCP SN），空口并不涉及GTP-U協(xié)議。圖3：GTPU協(xié)議層在LTE/SAE網(wǎng)絡(luò)的示意圖GTPU檢測(cè)是利用GTPU協(xié)議中的GTPU_ECHO_REQ和GTPU_ECHP_RESP報(bào)文，檢測(cè)基站上的PATH鏈路(IPPATH和EPPATH)通斷的一種功能，當(dāng)eNodeB側(cè)收到對(duì)端發(fā)送的GTPUErr IND消息，或檢測(cè)到IPPATH Down，會(huì)給RR發(fā)送GTPU Reset消息，之后主動(dòng)釋放用戶承載，RR給MME發(fā)送S1AP_UE_CONTEXT_REQ消息，釋放原因?yàn)門ransport-resource-unavailable，詳細(xì)信令如下

6、：圖4：傳輸?shù)艟€信令（五）MME掉線MME掉線L.E-RAB.AbnormRel.MME統(tǒng)計(jì)圖5所示的A點(diǎn)。MME主動(dòng)發(fā)起E-RAB或UE CONTEXT釋放流程，當(dāng)eNodeB收到來(lái)自MME的E-RAB RELEASE COMMAND或CONTEXT RELEASE COMMAND消息時(shí)，且釋放原因不為“Normal Release”，“Detach”，“User Inactivity”，“CS Fallback triggered”，“UE Not Available for PS Service”，“Inter-RAT Redirection”，“Successful Handover”

7、統(tǒng)計(jì)L.E-RAB.AbnormRel.MMETot指標(biāo)，當(dāng)判斷相應(yīng)承載有數(shù)傳時(shí)，統(tǒng)計(jì)L.E-RAB.AbnormRel.MME指標(biāo)。如果E-RAB RELEASE COMMAND消息中要求同時(shí)釋放多個(gè)E-RAB，則相應(yīng)指標(biāo)按具體業(yè)務(wù)數(shù)目進(jìn)行累加。圖5：MME掉線當(dāng)S1觀察到核心網(wǎng)主動(dòng)發(fā)送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、：核心網(wǎng)主動(dòng)釋放流程【解決方法】一、問題確認(rèn)（一）掉線問題范圍分析，按照篩選規(guī)則確認(rèn)是整網(wǎng)問題還是TOP小區(qū)問題；（二）場(chǎng)景分析：是搬遷、升級(jí)、擴(kuò)容等趨勢(shì)惡化場(chǎng)景還是存量?jī)?yōu)化場(chǎng)景，例如新建網(wǎng)絡(luò)；（三）掉線趨勢(shì)分析：掉線率長(zhǎng)期變化趨勢(shì)，切換成功率長(zhǎng)期變化趨勢(shì)，掉線率與負(fù)載(空口負(fù)載，單板CPU負(fù)載）變化關(guān)系圖；（四）定位“Top小區(qū)”問題或整網(wǎng)問題：分別去除TOP10的”掉線率TOP小區(qū)”和”掉線次數(shù)TOP小區(qū)”后，如果整網(wǎng)掉線率明顯改善且與原來(lái)持平(或者達(dá)到了目標(biāo)值)，則定義為TOP小區(qū)問題；如果分別去除TOP10的”掉線率TOP小區(qū)”和”掉線次數(shù)TOP小區(qū)”后整網(wǎng)掉線率沒有明顯改善，則定義為

9、整網(wǎng)問題。（二）指標(biāo)趨勢(shì)分析掉線率長(zhǎng)期趨勢(shì)分析，確認(rèn)是逐漸惡化還是突然惡化。如果是突然惡化，那么在轉(zhuǎn)折點(diǎn)附近尋找異常；如果是逐漸惡化則需要分析負(fù)載、容量、當(dāng)?shù)卦拕?wù)模型。掉線率趨勢(shì)線與切換成功率、RB利用率、用戶數(shù)、CPU負(fù)載趨勢(shì)線密切相關(guān)?？梢酝ㄟ^這些趨勢(shì)線推導(dǎo)掉線率惡化原因。如下所示：掉線率逐漸升高，分析關(guān)聯(lián)指標(biāo)，切換成功率一直惡化，可以判定掉線率升高與切換失敗有關(guān)。（三）掉線原因分析根據(jù)話統(tǒng)失敗原因值和關(guān)聯(lián)指標(biāo)對(duì)問題進(jìn)行初步分類，推理可能原因，不同的問題原因后續(xù)優(yōu)先采用的動(dòng)作以及順序有差別。圖7：典型掉線原因分析與建議動(dòng)作（四）參數(shù)核查1.TOP小區(qū)問題：將問題小區(qū)參數(shù)與正常站點(diǎn)參數(shù)進(jìn)行數(shù)

10、據(jù)比對(duì)，對(duì)差異參數(shù)進(jìn)行分析；2.整網(wǎng)問題：全網(wǎng)參數(shù)核查，排查出不符合基線或存在差異的參數(shù)配置，分析異常參數(shù)對(duì)掉線指標(biāo)的影響。（五）操作日志排查查詢指標(biāo)異常時(shí)間段有無(wú)影響指標(biāo)的操作。（六）設(shè)備故障排查排查掉線率異常期間有無(wú)影響掉線的故障告警。圖8：華為L(zhǎng)TE網(wǎng)管告警示意圖（七）弱覆蓋問題排查若后臺(tái)數(shù)據(jù)排查掉線原因主要是LE-RAB.AbnormRel.Radio，表示異常釋放主要原因?yàn)樯闲腥醺采w和信號(hào)陡降，則需要對(duì)TOP小區(qū)進(jìn)行覆蓋排查。圖9：弱覆蓋導(dǎo)致掉線根據(jù)路測(cè)數(shù)據(jù)排查，掉線發(fā)生在DL RSRP<-119dBm以下，判斷為弱覆蓋導(dǎo)致掉線，通過對(duì)照路測(cè)信令與基站信令跟蹤，可以判斷掉線原因

11、，如果路測(cè)信令中發(fā)了上行信令，而基站側(cè)信令中沒有收到該信令，結(jié)合DL RSRP可以判斷屬于上行弱覆蓋還是上行干擾問題。（八）切換問題排查1.鄰區(qū)漏配可能導(dǎo)致用戶無(wú)法切換或者切換到次優(yōu)小區(qū)；2.鄰區(qū)漏配可能導(dǎo)致用戶切換到錯(cuò)誤小區(qū)而失??；3.目標(biāo)小區(qū)半徑配置過?。ㄐ∮谇袚Q點(diǎn)到目標(biāo)基站距離）也會(huì)導(dǎo)致切換入失敗；4.實(shí)際目標(biāo)小區(qū)PCI與源站點(diǎn)鄰區(qū)關(guān)系配置中的鄰區(qū)PCI沖突。例如，提取包河大道與環(huán)湖路交口西北角2小區(qū)與巢湖忠廟碧桂園1小區(qū)兩兩小區(qū)切換指標(biāo)，主要是包河大道與環(huán)湖路交口西北角2小區(qū)向巢湖忠廟碧桂園1小區(qū)切換失敗，兩站分別位于巢湖兩岸，距離19.59km，超遠(yuǎn)鄰區(qū)導(dǎo)致切換失敗。圖10：超遠(yuǎn)鄰區(qū)

12、導(dǎo)致切換失?。ň牛┤萘颗挪榕挪槟繕?biāo)小區(qū)是否存在單板過載告警，如果存在告警，進(jìn)一步按照告警幫助查看是否存在CPU過載問題，若單板使用率>90%，則單板負(fù)載過高，例如查詢某站CPU利用流程如圖11所示，單板使用率在均在22%以下，排除單板負(fù)載過高引起的掉線可能。圖11：某站連續(xù)5天單板使用率跟蹤排查目標(biāo)小區(qū)是否存在最大用戶數(shù)超過規(guī)格，如果超過規(guī)格及時(shí)增加License或?qū)φ军c(diǎn)進(jìn)行擴(kuò)容。例如查詢某站小區(qū)最大用戶數(shù)如圖12所示，均在10個(gè)以下，排除用戶過多導(dǎo)致掉線可能。圖12：某站連續(xù)5天小區(qū)內(nèi)最大用戶數(shù)跟蹤（十）射頻通道問題排查分析是否存在射頻通道相關(guān)告警，例如射頻單元駐波告警、射頻通道接收信

13、道RTWP/RSSI過低告警、射頻通道接受通道RTWP/RSSI不平衡告警、射頻單元發(fā)射通道增益異常告警、射頻單元過載告警、射頻單元輸入功率異常告警、射頻單元光接口性能惡化告警、射頻單元光模塊收發(fā)異常告警、射頻單元光模塊故障告警等。（十一）核心網(wǎng)問題排查1.通過標(biāo)口流程確認(rèn)是否與已知的核心網(wǎng)問題相同（例如S1切換和X2切換交叉過程中核心網(wǎng)流程沖突），或者是否問題時(shí)間點(diǎn)核心網(wǎng)有改動(dòng)而基站無(wú)任何操作。2.通過標(biāo)口分析是否基站發(fā)送了S1_PATH_SWITCH_REQ后核心網(wǎng)回復(fù)S1_PATH_SWITCH_REQ_FAIL，如圖13所示。圖13：S1_PATH_SWITCH_REQ_FAIL（十二

14、）傳輸問題排查對(duì)于傳輸問題引起的掉線需要分類進(jìn)行排查。非同一傳輸節(jié)點(diǎn)下的TOP小區(qū)問題，需要對(duì)TOP小區(qū)逐個(gè)定位；同一傳輸節(jié)點(diǎn)下的局部小區(qū)問題，定位傳輸節(jié)點(diǎn)問題；整網(wǎng)問題則定位為統(tǒng)管全網(wǎng)的傳輸節(jié)點(diǎn)問題或UGW異常。1.排查是否出現(xiàn)SCTP鏈路故障告警、IP Path故障告警、傳輸光接口性能惡化、以太網(wǎng)鏈路故障告警等，判斷告警時(shí)間是否與掉線時(shí)間一致。2.檢查VLAN，DSCP，IPRT，IPPATH，SCTP等傳輸參數(shù)配置與規(guī)劃是否一致。3.通過S1標(biāo)口信令，檢查上下文建立錯(cuò)誤用戶的INITIAL_CONTEXT_SETUP_REQ中transportLayerAddress是否與基站配置IPPATH對(duì)端地址的一致，如地址在基站側(cè)不存在，則添加。分析掉線原因?yàn)門NL的內(nèi)部釋放原因，釋放原因?yàn)閁EM_UECNT_REL_RET_IPPATH、UEM_UECNT_RELRECV_GTPU_RESET_BEAR_REQ，此時(shí)可能為GTPU問題，需要進(jìn)行GTPU檢測(cè)確認(rèn)GTPU是否正常，如果是GTPU請(qǐng)求響應(yīng)超時(shí)，則需要傳輸與核