4G網絡中GTPC路徑斷告警問題分析及定位
2018-01-31 08:31:34饒軻
科技視界 2018年30期
饒軻
【摘 要】由于4G網絡規(guī)模部署的不斷增加，本文從設備出現(xiàn)大量GTPC告警入手，分析故障現(xiàn)象和信令流程，正對性的開展實驗，最終確定由于某些ENODEB數(shù)據(jù)配置不全引發(fā)了核心網設備側GTPC路徑斷告警以及切換流程的失敗。
【關鍵詞】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內會出現(xiàn)接近1000次，而且告警設備的地址幾乎都為本省的SGSN GTPC地址，涉及范圍為每套SGSN。
2 問題影響
本省SGSN間的GTPC路徑斷，具體影響用戶發(fā)生RAU、TAU切換時業(yè)務會被終端，需要UE重新發(fā)起附著方可繼續(xù)使用業(yè)務（概率性問題，后面有詳細分析），對于沒有發(fā)生切換，或者在intra內進行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間進行gtpc或者gptu交付的情況，一旦一條GTP消息沒有得到對端網元的正確響應，同樣將會上報“gtpc 路徑斷”；
3.1.1 針對第一種情況：
選取兩套告警頻繁的SGSN進行所有Gn接口鏡像抓包：對CE1和CE2相同時間段的數(shù)據(jù)包進行echo包統(tǒng)計發(fā)現(xiàn)：SGSN1和SGSN2之間的gtp echo消息都可以一對一對應。再看設備間業(yè)務地址的ping包，也是沒有丟包的。針對第一種可能產生告警的情況，對于承載網丟包的問題可以排除。
3.1.2 針對第二種情況：
返回CE1和CE2抓的鏡像包結合設備告警進行分析?？吹礁婢ㄎ恍畔⒅薪涌诨径紴镾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網元間的接口=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網元間的接口=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網元間的接口=S10；
針對上述三個告警，可以看到設備上響應時間段確認有三個對應的gtpc路徑斷告警。
注：上述的relocationg消息中涉及到的enodeb id都沒有在SGSN1和SGSN2下掛。
3.1.3 根據(jù)上面的分析，結合信令分析流程，現(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切換時，關于此Enodeb對應的TAC區(qū)域MME可以在DNS上解析到所有SGSN的GTPC地址，所以如果此時剛好DNS返回的地址不是enodeb原先掛接的SGSN，而是另外一套SGSN（沒有掛接該Enodeb），此時由于目標SGSN沒有到該enodeb的鏈接，向目標Enodeb發(fā)送不了hand over消息，導致源MME接收不到目標MME的relocationg response，導致流程失敗，從而產生”GTPC路徑斷”告警。這里，向讀者完整闡述下這類切換的具體流程：
MME和S-GW均改變的E-UTRAN內部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轉發(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承載關聯(lián)的網絡資源。如果沒有承載上下文，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）經核查無線側有450個左右enodeb只對接了SGSN3，已經協(xié)調無線廠家人員（中興約為200個基站，華為約為150個，貝爾約為100個）配全到所有SGSN的S1鏈路。
2）告警情況：
SGSN1在昨天以后就基本沒有出現(xiàn)GTPC的閃斷告警了；SGSN2和SGSN3閃斷次數(shù)也明顯降低，剩下的告警和某些基站斷鏈有關。
3）業(yè)務情況
聯(lián)系測試人員返回昨日測試地點進行TAU測試，反饋業(yè)務成功，問題解決。
6 經驗教訓及推廣：
對于后續(xù)無線Enodeb對接MME要求：要求所有Enodeb后續(xù)對接MME，必須配置到所有MME的全IP互聯(lián)鏈路。
