張佳隆，刁 鳴

(哈爾濱工程大學(xué)信息與通信學(xué)院，黑龍江哈爾濱 150001)

為提高無線移動傳輸速率，3GPP組織啟動了LTE項目［1］。從LTE開始，核心網(wǎng)實現(xiàn)了全PS域設(shè)計，且實現(xiàn)了控制平面和數(shù)據(jù)平面的分離。而EMM協(xié)議棧中的服務(wù)請求過程作為控制面和數(shù)據(jù)面的唯一紐帶尤為重要［2－3］。鑒于LTE網(wǎng)絡(luò)還未商用的情況下，研究并實現(xiàn)服務(wù)請求過程等信令流程是關(guān)鍵?；诖?，本文重點研究了服務(wù)請求信令流程，并提出了EMM協(xié)議棧服務(wù)請求過程的流程設(shè)計以及具體實現(xiàn)方法。

1 服務(wù)請求過程的流程設(shè)計

MME端的服務(wù)請求模塊分為正常流程和異常流程兩種情況［4］，在正常流程中，MME會首先對Service Request消息進(jìn)行解碼，然后通過Initial消息中的stmsi找到UE上下文，之后驗證Service Request消息是否通過完整性保護(hù)，若未通過完整性保護(hù)便啟動鑒權(quán)過程，若通過完整性保護(hù)，則啟動Service Request的后續(xù)過程，即發(fā)送Initial Uext Setup Request消息，之后等待enodeB做出回應(yīng)［5］。若在 Service Request過程中，發(fā)現(xiàn)解碼失敗，或密鑰KSI序列碼Sqn、短驗證碼short MAC與UE上下文不符［6］，則進(jìn)入異常流程，即核心網(wǎng)拒絕服務(wù)請求，MME會首先發(fā)送Service Reject消息，然后發(fā)送 Uecxt Release Command 消息［7－8］。

1.1 正常流程

圖1 服務(wù)請求正常流程

Service流程的正常流程與其他的特殊過程較類似，區(qū)別在于安全頭，正常流程介紹如下:1～6 UE和EnodeB之間建立RRC連接，發(fā)送Service Request消息。8 MME接收到 Service Request消息后，會對 Service Request消息的IE逐一進(jìn)行審核比較，若均無問題，則發(fā)送S1AP Initial Context Setup Request消息建立S1AP上下文。16 UE回復(fù)S1AP Initial Context Setup Response消息，表示可開始數(shù)據(jù)承載的傳送，隨后便開始進(jìn)行數(shù)據(jù)傳送。17～20當(dāng)數(shù)據(jù)傳送業(yè)務(wù)結(jié)束后，釋放相應(yīng)的承載［9－10］。

1.2 異常流程

Service流程的異常流程與正常流程基本相似，核心網(wǎng)MME收到Service Request消息后，會比較審核Request消息中的一些IE，在本設(shè)計中只考慮KSI這一IE，若Request消息中的KSI與 UE上下文中存儲的KSI不一致，則向UE發(fā)送Service Reject消息，之后釋放UE上下文，已相應(yīng)的承載和RRC連接［11］。

圖2 服務(wù)請求異常流程

2 服務(wù)請求過程的模塊實現(xiàn)

從上文的設(shè)計中可看出，服務(wù)請求過程不是單獨(dú)進(jìn)行的，其中伴隨有其他的過程，這是因為在LTE核心網(wǎng)EMM信令流程中分為3個特殊過程和4個普通過程。一般情況下，特殊過程中會啟動普通過程，例如在附著和跟蹤區(qū)域更新過程中均會啟動鑒權(quán)和安全模式控制過程。服務(wù)請求過程也是如此，在該流程中一般會啟動鑒權(quán)過程，所以對于特殊過程的信令實現(xiàn)，本文采用前期處理和后期處理的方式，具體函數(shù)接口與流程圖介紹如下。

2.1 服務(wù)請求過程前期處理模塊

函數(shù)接口:int emm_sf_pre_servicereq(ue_context_t*uecxt，void*arg，int argsz，void*outv)。

實現(xiàn)功能:MME會首先對Service Request消息進(jìn)行解碼，若解碼失敗則需發(fā)送Service Reject消息并釋放UE上下文，原因值EMMCause為Protocol ErrorO-rUnspecified，然后通過Initial消息中的stmsi找到UE上下文，之后驗證Service Request消息是否通過完整性保護(hù)，若未通過完整性保護(hù)則啟動鑒權(quán)過程，若通過完整性保護(hù)，便啟動Service Request的后續(xù)過程。

圖3 服務(wù)請求前期處理模塊流程圖

2.2 服務(wù)請求過程后續(xù)處理模塊

函數(shù)接口:int emm_sf_servicereq_ok(ue_context_t*uecxt)。

實現(xiàn)功能:在Service Request的后續(xù)過程中，首先對保存在UE上下文中的Initial Message進(jìn)行解碼，若發(fā)現(xiàn)Service Request消息中攜帶的KSI與UE上下文存儲的KSI不符，則發(fā)送Service Reject消息并釋放UE上下文。若相符便發(fā)送Initial Uext Setup Request消息，之后等待enodeB做出回應(yīng)。

相關(guān)參數(shù)定義如下:uecxt:狀態(tài)機(jī)傳遞的UE上下文指針，可能為空。Arg:狀態(tài)機(jī)傳遞的參數(shù)指針，此處為消息緩沖區(qū)指針。Argsz:arg指向緩沖區(qū)的長度。Outv:傳遞需推遲處理的Initial UE Message參數(shù)。

圖4 服務(wù)請求后續(xù)處理模塊流程圖

以上是服務(wù)請求過程的具體實現(xiàn)過程，該前期處理模塊與后期處理模塊相結(jié)合的方式能夠關(guān)注到該信令流程的每個細(xì)節(jié)，是一種較為合理的信令流程實現(xiàn)方式。

3 服務(wù)請求過程測試方案及結(jié)果分析

3.1 測試環(huán)境及測試工具介紹

服務(wù)請求過程作為LTE系統(tǒng)特殊信令流程，其測試必須要放到LTE環(huán)境中，然而由于LTE并未上市的客觀條件，LTE模式的終端和基站并未作為產(chǎn)品大量上市，因此在本設(shè)計中采用服務(wù)器運(yùn)行python腳本模擬UE以及enodeB。而網(wǎng)關(guān)本身就是運(yùn)行在服務(wù)器上的，測試環(huán)境采用CentOS6.0，因該系統(tǒng)憑借其穩(wěn)定性及容錯性，被譽(yù)為最穩(wěn)定的服務(wù)器系統(tǒng)。測試環(huán)境的配置如表1所示。

表1 測試環(huán)境配置表

網(wǎng)絡(luò)分析儀選用Wireshark，Wireshark其是一款網(wǎng)絡(luò)封包分析軟件。WireShark軟件支持Unix和Windows平臺，可在接口實時捕捉包，能顯示包的詳細(xì)協(xié)議信息，可打開或保存捕捉包，可導(dǎo)入導(dǎo)出其他捕捉程序支持的包數(shù)據(jù)格式，可通過多種方式過濾包，多種方式查找包，創(chuàng)建多種統(tǒng)計分析。如今這款軟件已成為最為成熟且使用率最高的網(wǎng)絡(luò)分析軟件，設(shè)計中使用WireShark工具用來對LTE系統(tǒng)EMM信令流程進(jìn)行工程測試。

設(shè)計中網(wǎng)絡(luò)拓?fù)鋱D的搭建遵照LTE網(wǎng)絡(luò)架構(gòu)，即核心網(wǎng)－eNodeB－UE這一架構(gòu)，圖5給出了本文測試的網(wǎng)絡(luò)架構(gòu)拓?fù)鋱D，其中實際網(wǎng)絡(luò)設(shè)備為核心網(wǎng)網(wǎng)關(guān)、交換機(jī)、集線器。模擬網(wǎng)絡(luò)設(shè)備為EnodeB、UE。

圖5 測試方案網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖

3.2 測試方案的設(shè)計結(jié)果分析

Service Request流程是UE有服務(wù)請求時啟動的信令流程，一般由UE發(fā)起，該信令流程通常會伴有承載以及相應(yīng)上下文的建立過程。在這里分以下幾個方面進(jìn)行測試:(1)若MME并未通過Initial Message找到UE上下文，MME是否發(fā)送Uecxt Release Command消息。(2)若MME在收到Service Request消息后，進(jìn)行鑒權(quán)和加密過程，之后發(fā)送Initial Uecxt Request消息，是否能夠完成Service Request整個過程。(3)若MME在收到Service Request消息后，進(jìn)行鑒權(quán)和加密過程，之后由于Service Request消息中的安全上下文與UE上下文中的安全上下文不一致，MME是否發(fā)送Service Reject消息。(4)若 MME在收到 Service Request消息后，該消息是初始消息，要進(jìn)行鑒權(quán)過程，而鑒權(quán)失敗，是否轉(zhuǎn)入主狀態(tài)機(jī)，根據(jù)相應(yīng)的特殊過程，發(fā)送Service Reject消息，之后釋放UE上下文。

經(jīng)測試，設(shè)計中的Service模塊滿足前面所有測試用例的預(yù)期輸出，并滿足功能測試。故在此只需分析服務(wù)請求過程的正常流程，圖6為正常Service流程的抓包圖。通過該抓包圖可看到UE首先向核心網(wǎng)發(fā)送了服務(wù)請求消息，該過程觸發(fā)了一般性過程，如鑒權(quán)過程和安全模式控制過程。在這兩個一般性過程通過后，核心網(wǎng)回復(fù)了上下文建立成功回應(yīng)消息，說明完成了服務(wù)請求過程。這與服務(wù)請求過程的正常流程相吻合，即說明該模塊滿足了設(shè)計要求。

圖6 service正常流程的抓包圖

4 結(jié)束語

基于Linux開發(fā)環(huán)境，設(shè)計并實現(xiàn)了LTE核心網(wǎng)EMM協(xié)議棧服務(wù)請求信令流程，經(jīng)測試，可滿足服務(wù)請求過程的正常流程和異常流程。在未來的通信發(fā)展中，隨著LTE的推廣和商用，相信對LTE核心網(wǎng)EMM協(xié)議棧信令流程的研究與實現(xiàn)將具有更廣泛的現(xiàn)實意義和應(yīng)用前景。

［1］張慶揚(yáng).4G核心網(wǎng)控制面協(xié)議棧的研究與實現(xiàn)［D］.長春:吉林大學(xué)，2011.

［2］王楓.3G移動通信核心網(wǎng)PS域模擬器的軟件設(shè)計與實現(xiàn)［D］.長春:吉林大學(xué)，2010.

［3］楊放春.下一代網(wǎng)絡(luò)中的關(guān)鍵技術(shù)［J］.北京郵電大學(xué)學(xué)報，2003(26):1－8.

［4］鄧永紅.4G通信技術(shù)綜述［J］.數(shù)字通信世界，2005(2):59－63.

［5］龐韶敏，李亞波.3G UMTS與4G LTE核心網(wǎng)［M］.北京:電子工業(yè)出版社，2011.

［6］霍龍社，王健全，周光濤.演進(jìn)的移動分組核心網(wǎng)架構(gòu)和關(guān)鍵技術(shù)［M］.北京:機(jī)械工業(yè)出版社，2013.

［7］龐韶敏，李亞波，沈宇超.3G核心網(wǎng)技術(shù)揭秘——CS，PS，IMS［M］.北京:電子工業(yè)出版社，2008.

［8］田輝.3GPP核心網(wǎng)技術(shù)［M］.北京:人民郵電出版社，2007.

［9］姜怡華.3GPP系統(tǒng)架構(gòu)演進(jìn)(SAE)原理與設(shè)計［M］.2版.北京:人民郵電出版社，2013.

［10］3GPP.Non－Access－Stratum(NAS)protocol for Evolved Packet System(EPS)［S］.NA USA:3GPPGroup，2010.

［11］3GPP.General Packet Radio Service enhancements for E-volved Universal Terrestrial Radio Access Network(E－UTRAN)access［S］.NA USA:3GPPGroup，2012.