數(shù)據(jù)包解析在LTE網(wǎng)絡(luò)復(fù)雜故障中的應(yīng)用研究

宋　悅　中國移動通信集團上海有限公司網(wǎng)絡(luò)運行管理中心助理工程師

?

數(shù)據(jù)包解析在LTE網(wǎng)絡(luò)復(fù)雜故障中的應(yīng)用研究

宋悅中國移動通信集團上海有限公司網(wǎng)絡(luò)運行管理中心助理工程師

E-RAB連接作為用戶與EPC之間的連接，直接決定了LTE業(yè)務(wù)的有效性。LTE網(wǎng)絡(luò)中，信令交互與用戶數(shù)據(jù)共同由IP網(wǎng)絡(luò)傳輸，并封裝于不同的協(xié)議中，不同協(xié)議的數(shù)據(jù)包共用物理鏈路。由于網(wǎng)絡(luò)中同時存在大量分布于不同層級的數(shù)據(jù)包，而不同層級的數(shù)據(jù)又會各自分別對業(yè)務(wù)產(chǎn)生影響，提高了網(wǎng)絡(luò)故障定位的困難程度。數(shù)據(jù)包捕捉分析這一手段，可以同時排查多個網(wǎng)絡(luò)層級的業(yè)務(wù)故障。本文通過抓取LTE業(yè)務(wù)數(shù)據(jù)包，分析了E-RAB連接建立的過程，并對一個實際的E-RAB連接故障做出了分析判斷。

LTE；E-RAB；協(xié)議；抓包

1　引言

作為全IP化的新一代通信技術(shù)，LTE網(wǎng)絡(luò)的控制信令與用戶數(shù)據(jù)均完全由IP包進行傳輸。在網(wǎng)絡(luò)層面，控制信令與用戶數(shù)據(jù)均作為OSI模型中應(yīng)用層的數(shù)據(jù)進行傳輸，區(qū)別僅在于底層封裝的傳輸層協(xié)議不同。LTE網(wǎng)絡(luò)的協(xié)議棧與傳統(tǒng)的TCP/IP網(wǎng)絡(luò)協(xié)議棧具有高度的相似性，因此用于分析傳統(tǒng)TCP/IP網(wǎng)絡(luò)故障的手段也可以用于分析LTE網(wǎng)絡(luò)的故障。

延續(xù)3GPP的一貫定義，RAB（Radio Access Bearer）為用戶提供從核心網(wǎng)到UE的數(shù)據(jù)連接能力，但是在LTE中RAB更名為E-RAB。E-RAB連接建立作為信令交互到用戶數(shù)據(jù)正常傳輸之間的最后一個步驟，直接決定了用戶能否正常使用LTE網(wǎng)絡(luò)，同時又會受到之前每一步信令交互的影響。E-RAB連接建立之前的信令交互步驟，均可以由分析傳統(tǒng)IP網(wǎng)絡(luò)故障的手段——抓包，進行捕捉和解析，同時定位故障點。

2　傳輸側(cè)LTE網(wǎng)絡(luò)協(xié)議棧

由于傳統(tǒng)的數(shù)據(jù)包捕捉工具僅適用于有線網(wǎng)絡(luò)，因此本文著重于分析LTE網(wǎng)絡(luò)在傳輸側(cè)的數(shù)據(jù)。在經(jīng)過BBU處理后，在傳輸側(cè)運行的LTE網(wǎng)絡(luò)的協(xié)議棧如圖1所示。

由圖1可知，傳輸側(cè)的網(wǎng)絡(luò)中，LTE業(yè)務(wù)在3層以下是共用IP協(xié)議進行數(shù)據(jù)傳輸?shù)?，?層以下，網(wǎng)絡(luò)并不區(qū)分具體的網(wǎng)絡(luò)信令及用戶數(shù)據(jù)。在網(wǎng)絡(luò)第4層中，LTE利用不同的傳輸協(xié)議封裝網(wǎng)絡(luò)信令與用戶數(shù)據(jù)，對于信令面，使用可靠的數(shù)據(jù)報傳輸協(xié)議SCTP （Stream Control Transmission Protocol）進行傳輸，對于用戶數(shù)據(jù)，則使用高效率的UDP協(xié)議進行傳輸。

圖1　LTE傳輸側(cè)協(xié)議棧

在應(yīng)用層以上，eNodeB與MME之間信令交互使用S1-AP協(xié)議，eNodeB之間的信令交互使用X2-AP協(xié)議，用于確認E-RAB連接建立的NAS信令封裝于S1-AP協(xié)議中。對于用戶數(shù)據(jù)，在應(yīng)用層以上由GTP-U協(xié)議封裝，因現(xiàn)有的LTE業(yè)務(wù)為全IP化業(yè)務(wù)，GTP協(xié)議的凈荷通常為一個完整的3層IP包。

3　正常E-RAB連接過程的信令數(shù)據(jù)包分析

用戶于LTE網(wǎng)絡(luò)進行通信時，需要在UE與EPC之間建立一條虛擬的連接，建立連接的基礎(chǔ)包括兩方面，即UE與eNodeB之間穩(wěn)定的連接（Uu接口實現(xiàn)），以及eNodeB與EPC之間穩(wěn)定的連接（S1接口實現(xiàn)），eNodeB與EPC之間的穩(wěn)定連接使用SCTP偶聯(lián)建立。通過在傳輸側(cè)全量抓取數(shù)據(jù)包，并進行過濾后，根據(jù)協(xié)議內(nèi)規(guī)定的流程，本文再現(xiàn)了SCTP偶聯(lián)建立的流程及E-RAB連接建立的流程。

3.1SCTP偶聯(lián)建立流程

SCTP協(xié)議中規(guī)定的偶聯(lián)建立流程見圖2，其中每個流程所包含的內(nèi)容如下：

圖2　SCTP信令流程

圖3　SCTP偶聯(lián)建立中的INIT數(shù)據(jù)包

（1）基站eNodeB（端點A）創(chuàng)建一個INIT數(shù)據(jù)塊來描述即將發(fā)起的這個偶聯(lián)，然后向MME（端點B）發(fā)送。INIT數(shù)據(jù)塊中主要包括的參數(shù)有啟動標(biāo)簽（Initiate Tag）、本站的滑動窗口大小（Rwnd）、輸出流數(shù)量（OS）和輸入流數(shù)量（IS），INIT數(shù)據(jù)塊的抓包實例見圖3。

（2）MME收到INIT數(shù)據(jù)包后，用INIT_ACK數(shù)據(jù)包作為響應(yīng)，INIT_ACK數(shù)據(jù)包中攜帶的參數(shù)有啟動標(biāo)簽（Initiate Tag）、通告窗口（Advertised Window）、輸出流數(shù)量（OS）和輸入流數(shù)量（IS），此外還包含了本站的狀態(tài)COOKIE（STATE COOKIE），具體實例的數(shù)據(jù)包如圖4所示。

（3）eNodeB收到INIT_ACK后，回送COOKIE_ECHO數(shù)據(jù)塊，將收到INIT_ACK數(shù)據(jù)塊中的STATECOOKIE回送至MME進行驗證。

（4）MME收到COOKIE_ECHO數(shù)據(jù)塊后，進行COOKIE驗證，驗證通過后發(fā)出COOKIE_ACK數(shù)據(jù)包，具體如圖5所示。

（5）eNodeB收到COOKIE_ACK包后，偶聯(lián)正式建立，開始向MME發(fā)送DATA數(shù)據(jù)包，DATA數(shù)據(jù)包中所帶參數(shù)有傳輸隊列號（TSN）、流標(biāo)識符（SID）和流順序碼（SSN）。

（6）MME收到DATA數(shù)據(jù)包后，回復(fù)SACK數(shù)據(jù)包。SACK數(shù)據(jù)塊中所帶的參數(shù)有累積證實TSN標(biāo)簽（Cumulative TSN）和間隔塊（Gaps），具體參見圖6。TSN用于驗證數(shù)據(jù)的有效性，SSN用于確保數(shù)據(jù)傳輸?shù)倪B續(xù)性，兩者互相獨立。

圖4　SCTP偶聯(lián)建立中的INIT_ACK數(shù)據(jù)包

（7）MME向eNodeB發(fā)送第一個DATA數(shù)據(jù)包。

（8）MME向eNodeB發(fā)送第二個DATA數(shù)據(jù)報。

（9）eNodeB收到兩個DATA數(shù)據(jù)包后，回復(fù)SACK數(shù)據(jù)包。

3.2E-RAB連接建立流程

eNodeB與MME之間的SCTP偶聯(lián)建立后，其間的S1信令交互就作為SCTP協(xié)議的凈荷在設(shè)備間傳輸。S1信令交互的建立由eNodeB發(fā)起，eNodeB發(fā)出S1 Setup Request請求，MME回應(yīng)S1 SetupResponse，信令連接建立后，id-Paging由MME發(fā)起（見圖7）。

在S1信令交互正常后，若有用戶接入，則在S1信令中產(chǎn)生E-RAB連接建立請求。E-RAB連接通過NAS信令實現(xiàn)，NAS信令交互流程如表1所示，其傳輸側(cè)實際抓包展示如圖8所示。信令交互至第9步時，E-RAB連接建立完成。

4　E-RAB連接受阻對無線業(yè)務(wù)的影響及數(shù)據(jù)包分析

當(dāng)E-RAB連接受阻時，通常表現(xiàn)為用戶無法正常使用LTE網(wǎng)絡(luò)。E-RAB連接位于網(wǎng)絡(luò)內(nèi)的高層，其下任意一層網(wǎng)絡(luò)故障時，均可能導(dǎo)致E-RAB連接失效。若故障發(fā)生于網(wǎng)絡(luò)層級的高層（傳輸層或應(yīng)用層之上），此時承載LTE業(yè)務(wù)的無線及傳輸設(shè)備可能并不會上報任何告警信息，從而使傳統(tǒng)的運營商維護方法，即告警→監(jiān)控→派單→處理這一流程失效。

在這種情況下，需要分析連接中斷的故障點，可以利用在傳輸側(cè)抓取數(shù)據(jù)包并分析的手段，將故障點定位精確至信令層面。在抓包分析的過程中，可將故障定位根據(jù)網(wǎng)絡(luò)內(nèi)的協(xié)議層級由低到高分為4個層面。其中前兩個層面的網(wǎng)絡(luò)發(fā)生故障時，通常會伴隨設(shè)備告警，抓包分析可以作為輔助說明手段。

圖5　SCTP偶聯(lián)建立中的COOKIE_ECHO及COOKIE_ACK包

圖6　SCTP信令中的DATA及SACK包

（1）于傳輸側(cè)抓取數(shù)據(jù)包，若能正常抓取到eNodeB與二層核心交換機（亦或網(wǎng)關(guān)網(wǎng)元）之間來往的數(shù)據(jù)包，則可以說明eNodeB與核心網(wǎng)之間的物理路由正常，同時所經(jīng)的二層傳輸網(wǎng)絡(luò)正常。

（2）若能抓取到eNodeB與MME之間來往的數(shù)據(jù)包，則可以說明eNodeB與核心網(wǎng)之間的三層路由正常。反之若二層網(wǎng)絡(luò)正常，但抓不到至MME的數(shù)據(jù)包，則故障應(yīng)發(fā)生于二三層轉(zhuǎn)接處。

（3）當(dāng)eNodeB與MME之間通信正常，則需關(guān)注四層信令部分，SCTP協(xié)議提供了豐富的驗證手段，確保數(shù)據(jù)的有效傳輸，從中可以分析的故障點有：通道誤碼導(dǎo)致COOKIE驗證失敗、傳輸延時過大導(dǎo)致COOKIE失效、設(shè)備緩存溢出導(dǎo)致滑動窗口Rwnd為0、軟件進程故障導(dǎo)致發(fā)送與接收的TSN號不一致，以及SACK包不能正常發(fā)送等。排查以上部分可將故障定位至網(wǎng)絡(luò)第四層。

（4）若前四層網(wǎng)絡(luò)正常，則繼續(xù)分析應(yīng)用層協(xié)議（見圖9），通過查詢NAS信令所攜帶的信息，如ENB-UE-S1AP-ID、MME-UE-S1AP-ID、CGI、TAI等，可以將故障定位至單條ERAB連接上，從而分析是否因為用戶設(shè)備故障以及鑒權(quán)失敗等原因?qū)е翬-RAB連接失效。

前兩層面的故障通常導(dǎo)致批量的基站業(yè)務(wù)故障，第三個層面即SCTP協(xié)議故障通常導(dǎo)致單獨的基站業(yè)務(wù)故障，第四個層面即單獨E-RAB連接失效通常導(dǎo)致單個用戶業(yè)務(wù)故障。圖10為一個實際故障中抓取的數(shù)據(jù)包，在該故障發(fā)生時，故障基站內(nèi)所有用戶均無法使用LTE上網(wǎng)，但4G信號強度正常，所有網(wǎng)元均無告警，通過抓包分析，發(fā)現(xiàn)eNodeB與MME進行S1信令交互時，基站發(fā)送的SACK包內(nèi)a_rwnd值為0，意為基站緩存滿，無法接受新的數(shù)據(jù)，導(dǎo)致MME不會響應(yīng)基站發(fā)出的NAS Initial UE Message，此后基站持續(xù)重傳該數(shù)據(jù)，無法建立E-RAB連接。

定位故障在SCTP協(xié)議層后，分析故障為eNodeB緩存非正常溢出導(dǎo)致，人工將基站進行緩存清空并復(fù)位重啟后，故障恢復(fù)。

圖7　S1信令建立過程

表1　E-RAB連接建立過程中的信令過程

圖8　E-RAB連接建立過程中的信令交互

圖9　NAS信令包內(nèi)攜帶的信息

5　結(jié)束語

在以往的2G及3G時代，設(shè)備層面的網(wǎng)絡(luò)結(jié)構(gòu)復(fù)雜多樣，但電路業(yè)務(wù)涉及的網(wǎng)絡(luò)層級較簡單，無線、傳輸、核心網(wǎng)等部門往往各自為政，將自身網(wǎng)絡(luò)內(nèi)的問題排除即可。而在LTE正式商用后，因設(shè)備層面的網(wǎng)絡(luò)結(jié)構(gòu)扁平化及網(wǎng)絡(luò)的全面IP化，業(yè)務(wù)所包含的網(wǎng)絡(luò)層級越發(fā)復(fù)雜，各個部門所負責(zé)的區(qū)域邊界趨于模糊，故障發(fā)生時跨部門協(xié)查的情況將會越來越普遍。E-RAB連接受阻這一表面現(xiàn)象，背后可能發(fā)生的故障可能涉及網(wǎng)絡(luò)的各個層面，排查時要深入分析每一層協(xié)議的有效性，才能將故障清晰定位，針對處理。

圖10　SCTP協(xié)議故障的數(shù)據(jù)包實例

［1］3GPP.Non-Access-Stratum（NAS）protocol for Evolved Packet System（EPS），Stage3［EB/OL］.www.3gpp.org.

［2］3GPP.Evolved Universal Terrestrial Radio Access（E-UTRA）and Evolved Universal Terrestrial Radio Access Network （E-UTRAN）；Overall description Stage 2［EB/OL］.www.3gpp. org.

［3］Sesia S.Toufik M.Baker I.LTE-The UMTS Long Term Evolution:From Theory to Practice（The Second Edition）［M］.北京：人民郵電出版社，2012，11.

［4］Sanders C.Wireshark數(shù)據(jù)包分析實戰(zhàn)（第2版）［M］.北京：人民郵電出版社，2013，3.

［5］王令侃，林曉軒，陳煒，等.TD-LTE技術(shù)發(fā)展及其應(yīng)用［J］.移動通信，2011，6：56-58.

［4］謝希仁.計算機網(wǎng)絡(luò)（第6版）［M］.北京：電子工業(yè)出版社，2013，6.

Analysis of the LTE failure by packet capture

SONG Yue

The LTE transmission effect is determined by E-RAB communication. The signal and user data are simultaneously transferred on the same physical network， and they are separately packaged in individual protocols. The cost of LTE network failure location is increased because of the complex data on the network. By packet capture， network failure in multiple layers will be analyzed simultaneously. In this paper， the packets of a practical LTE network failure are captured and analyzed.

LTE；E-RAB；protocol；packet capture

2016-07-10）