饒軻

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

【關(guān)鍵詞】ENODEB；TAU；GPTC路徑中斷

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

DOI：10.19694/j.cnki.issn2095-2457.2018.30.013

1 問題現(xiàn)象

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

2 問題影響

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

3 問題分析

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

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

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

3.1.1 針對第一種情況：

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

3.1.2 針對第二種情況：

返回CE1和CE2抓的鏡像包結(jié)合設備告警進行分析?？吹礁婢ㄎ恍畔⒅薪涌诨径紴镾10，所以重點分析了GTP V2的報文，可以從抓包中看到有相當一部分relocationg request請求包是沒有得到響應的。relocationg request是終端在MME間發(fā)起Handover流程時，源MME向目的MME發(fā)送的請求消息，由于源MME遲遲沒有得到響應（10s），而源MME按照自己的T3N3定時器重發(fā)Forward Relocation Request消息和上報告警，最后導致流程失敗。至此，初步判斷這個問題并不是丟包引起的GTPC路徑故障告警，而是流程失敗引起的。

SGSN1的兩個告警：

1）告警發(fā)生時間/告警恢復時間：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網(wǎng)元間的接口=S10；

2）告警發(fā)生時間/告警恢復時間：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網(wǎng)元間的接口=S10；

SGSN2的一個告警：

告警發(fā)生時間/告警恢復時間：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網(wǎng)元間的接口=S10；

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

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

3.1.3 根據(jù)上面的分析，結(jié)合信令分析流程，現(xiàn)場做了兩次實驗：

涉及到的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測試，用戶業(yè)務中斷，看到的現(xiàn)象為：在源MME向目標MME發(fā)送relocation req后，等待10s，沒有收到response消息，之后又重新發(fā)起hand over流程，與此同時SGSN上有對應SGSN1和SGN5之間的gtpc斷鏈告警。

4 問題根因：

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

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

1、條件滿足，觸發(fā)TAU流程。

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

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

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

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

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

7、new MME繼續(xù)維護從old MME收到的UE的EPS承載上下文。MME會驗證來自UE的EPS承載狀態(tài)，并釋放非活動態(tài)EPS承載關(guān)聯(lián)的網(wǎng)絡資源。如果沒有承載上下文，MME將拒絕TAU請求。

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

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

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

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

12、HSS向old MME發(fā)送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發(fā)送Delete Session Request消息告知其釋放EPS承載資源。

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

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

5 問題處理進展：

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

2）告警情況：

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

3）業(yè)務情況

聯(lián)系測試人員返回昨日測試地點進行TAU測試，反饋業(yè)務成功，問題解決。

6 經(jīng)驗教訓及推廣：

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