4G網絡中GTPC路徑斷告警問題分析及定位

饒軻

【摘 要】由于4G網絡規模部署的不斷增加，本文從設備出現大量GTPC告警入手，分析故障現象和信令流程，正對性的開展實驗，最終確定由于某些ENODEB數據配置不全引發了核心網設備側GTPC路徑斷告警以及切換流程的失敗。

【關鍵詞】ENODEB；TAU；GPTC路徑中斷

中圖分類號： TN929.53 文獻標識碼： A 文章編號： 2095-2457（2018）30-0034-002

DOI：10.19694/j.cnki.issn2095-2457.2018.30.013

1 問題現象

近期，SGSN設備出現大量”GTPC路徑斷”告警，告警峰值在24H內會出現接近1000次，而且告警設備的地址幾乎都為本省的SGSN GTPC地址，涉及范圍為每套SGSN。

2 問題影響

本省SGSN間的GTPC路徑斷，具體影響用戶發生RAU、TAU切換時業務會被終端，需要UE重新發起附著方可繼續使用業務（概率性問題，后面有詳細分析），對于沒有發生切換，或者在intra內進行RAU、TAU業務的用戶也不受影響。

3 問題分析

3.1 引起“GTPC路徑斷”的原因有兩種：

1）SGSN間或者SGSN GGSN間互相發送gtp echo 交互消息，達到一定時間、一定次數后，SGSN上報“gtpc 路徑斷”；（T3N3定時器設置為6s，3次）

2）用戶行為（包括PDP激活、RAU、TAU、QOS更新等）涉及到SGSN與GGSN間進行gtpc或者gptu交付的情況，一旦一條GTP消息沒有得到對端網元的正確響應，同樣將會上報“gtpc 路徑斷”；

3.1.1 針對第一種情況：

選取兩套告警頻繁的SGSN進行所有Gn接口鏡像抓包：對CE1和CE2相同時間段的數據包進行echo包統計發現：SGSN1和SGSN2之間的gtp echo消息都可以一對一對應。再看設備間業務地址的ping包，也是沒有丟包的。針對第一種可能產生告警的情況，對于承載網丟包的問題可以排除。

3.1.2 針對第二種情況：

返回CE1和CE2抓的鏡像包結合設備告警進行分析。看到告警定位信息中接口基本都為S10，所以重點分析了GTP V2的報文，可以從抓包中看到有相當一部分relocationg request請求包是沒有得到響應的。relocationg request是終端在MME間發起Handover流程時，源MME向目的MME發送的請求消息，由于源MME遲遲沒有得到響應（10s），而源MME按照自己的T3N3定時器重發Forward Relocation Request消息和上報告警，最后導致流程失敗。至此，初步判斷這個問題并不是丟包引起的GTPC路徑故障告警，而是流程失敗引起的。

SGSN1的兩個告警：

1）告警發生時間/告警恢復時間：2014-09-15 11：54：51+08：00/2014-09-15 11：55：07+08：00.

定位信息：本端IP=11x.xx.xx.12，對端IP=22x.xx.xx.113，路徑接口類型=GTP path EPC，框號=1，槽位號=13，進程類型=PCP，同類進程序號=0，PLMN網元間的接口=S10；

2）告警發生時間/告警恢復時間：2014-09-15 11：55：51+08：00/2014-09-15 11：56：01+08：00.

定位信息：本端IP=11x.xx.xx.5，對端IP=22x.xx.xx.115，路徑接口類型=GTP path EPC，框號=0，槽位號=13，進程類型=PCP，同類進程序號=0，PLMN網元間的接口=S10；

SGSN2的一個告警：

告警發生時間/告警恢復時間：2014-09-15 11：54：56+08：00/2014-09-15 11：55：37+08：00.

定位信息：本端IP=11x.xx.xx.121，對端IP=22x.xx.xx.1，路徑接口類型=GTP path EPC，框號=1，槽位號=11，進程類型=PCP，同類進程序號=0，PLMN網元間的接口=S10；

針對上述三個告警，可以看到設備上響應時間段確認有三個對應的gtpc路徑斷告警。

注：上述的relocationg消息中涉及到的enodeb id都沒有在SGSN1和SGSN2下掛。

3.1.3 根據上面的分析，結合信令分析流程，現場做了兩次實驗：

涉及到的TAC為：

8901（0x550F）：這個TAC對應的是一個連接了所有SGSN的Enodeb

8902（0x550F）：這個TAC對應的是只連接了SGSN3的enodeb（也就是SGSN1和SGSN2沒有該enodeb的S1連接）

第一次測試：用戶在8901下面進行激活，同時激活在SGSN3上，由8901->8902進行TAU測試，用戶測試正常；

第二次測試：用戶在8901下面進行激活，同時激活在SGSN1上，由8901->8902進行TAU測試，用戶業務中斷，看到的現象為：在源MME向目標MME發送relocation req后，等待10s，沒有收到response消息，之后又重新發起hand over流程，與此同時SGSN上有對應SGSN1和SGN5之間的gtpc斷鏈告警。

4 問題根因：

SGSN間大量的“S10”類型的“gtpc路徑斷”告警，是由于某些Enodeb只直接入了某臺SGSN，當某用戶從該Enodeb接入使用4G業務并且發生TAU切換時，關于此Enodeb對應的TAC區域MME可以在DNS上解析到所有SGSN的GTPC地址，所以如果此時剛好DNS返回的地址不是enodeb原先掛接的SGSN，而是另外一套SGSN（沒有掛接該Enodeb），此時由于目標SGSN沒有到該enodeb的鏈接，向目標Enodeb發送不了hand over消息，導致源MME接收不到目標MME的relocationg response，導致流程失敗，從而產生”GTPC路徑斷”告警。這里，向讀者完整闡述下這類切換的具體流程：

MME和S-GW均改變的E-UTRAN內部TAU詳細流程如下：

1、條件滿足，觸發TAU流程。

2、UE通過向eNodeB發送Tracking Area Update Request消息以及指示了Selected Network和old GUMMEI的RRC參數來發起一個TAU流程。

3、eNodeB通過GUMMEI（Globally Unique MME Identifier）和Selected Network找到MME，并向MME轉發Tracking Area Update Request消息。

4、new MME通過GUTI獲得old MME地址，并向old MME發送Context Request消息重新獲取用戶信息， old MME會啟動一個定時器。

5、old MME向new MME返回Context Response消息。

6、new MME決定是否重新選擇S-GW。new MME向old MME發送Context Acknowledge消息，消息包含：Serving GW change indication，指示已選擇的new S-GW。

7、new MME繼續維護從old MME收到的UE的EPS承載上下文。MME會驗證來自UE的EPS承載狀態，并釋放非活動態EPS承載關聯的網絡資源。如果沒有承載上下文，MME將拒絕TAU請求。

8、new S-GW向所在PDN連接的P-GW發送Modify Bearer Request消息告知其承載信息變更。

9、P-GW更新承載上下文，并向new S-GW返回Modify Bearer Response消息。

10、new S-GW更新承載上下文，并向MME返回Create Session Response消息。

11、new MME首先查看本地是否保存了UE的簽約數據，使用GUTI、additional GUTI或IMSI進行標識。

12、HSS向old MME發送Cancel Location消息，消息包含：IMSI、Cancellation type，Cancellation type設置為Update Procedure。

13、如果4中的定時器已超時，old MME刪除移動性管理上下文；否則，待定時器超時后再刪除上下文。

14、HSS向new MME響應Update Location Ack消息。

15、當4中的定時器超時，old MME釋放本地承載資源，并向old S-GW發送Delete Session Request消息告知其釋放EPS承載資源。

16、old S-GW向old MME返回Delete Session Response消息并丟棄所有為UE緩存的數據包，消息包含：Cause。

17、MME向UE響應Tracking Area Update Accept消息，如果MME重新分配了GUTI，也隨此消息下發給UE。

5 問題處理進展：

1）經核查無線側有450個左右enodeb只對接了SGSN3，已經協調無線廠家人員（中興約為200個基站，華為約為150個，貝爾約為100個）配全到所有SGSN的S1鏈路。

2）告警情況：

SGSN1在昨天以后就基本沒有出現GTPC的閃斷告警了；SGSN2和SGSN3閃斷次數也明顯降低，剩下的告警和某些基站斷鏈有關。

3）業務情況

聯系測試人員返回昨日測試地點進行TAU測試，反饋業務成功，問題解決。

6 經驗教訓及推廣：

對于后續無線Enodeb對接MME要求：要求所有Enodeb后續對接MME，必須配置到所有MME的全IP互聯鏈路。