張佳隆,刁 鳴
(哈爾濱工程大學(xué)信息與通信學(xué)院,黑龍江哈爾濱 150001)
為提高無線移動傳輸速率,3GPP組織啟動了LTE項(xiàng)目[1]。從LTE開始,核心網(wǎng)實(shí)現(xiàn)了全PS域設(shè)計,且實(shí)現(xiàn)了控制平面和數(shù)據(jù)平面的分離。而EMM協(xié)議棧中的服務(wù)請求過程作為控制面和數(shù)據(jù)面的唯一紐帶尤為重要[2-3]。鑒于LTE網(wǎng)絡(luò)還未商用的情況下,研究并實(shí)現(xiàn)服務(wù)請求過程等信令流程是關(guān)鍵。基于此,本文重點(diǎn)研究了服務(wù)請求信令流程,并提出了EMM協(xié)議棧服務(wù)請求過程的流程設(shè)計以及具體實(shí)現(xiàn)方法。
MME端的服務(wù)請求模塊分為正常流程和異常流程兩種情況[4],在正常流程中,MME會首先對Service Request消息進(jìn)行解碼,然后通過Initial消息中的stmsi找到UE上下文,之后驗(yàn)證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、短驗(yàn)證碼short MAC與UE上下文不符[6],則進(jìn)入異常流程,即核心網(wǎng)拒絕服務(wù)請求,MME會首先發(fā)送Service Reject消息,然后發(fā)送 Uecxt Release Command 消息[7-8]。
圖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]。
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ù)請求異常流程
從上文的設(shè)計中可看出,服務(wù)請求過程不是單獨(dú)進(jìn)行的,其中伴隨有其他的過程,這是因?yàn)樵贚TE核心網(wǎng)EMM信令流程中分為3個特殊過程和4個普通過程。一般情況下,特殊過程中會啟動普通過程,例如在附著和跟蹤區(qū)域更新過程中均會啟動鑒權(quán)和安全模式控制過程。服務(wù)請求過程也是如此,在該流程中一般會啟動鑒權(quán)過程,所以對于特殊過程的信令實(shí)現(xiàn),本文采用前期處理和后期處理的方式,具體函數(shù)接口與流程圖介紹如下。
函數(shù)接口:int emm_sf_pre_servicereq(ue_context_t*uecxt,void*arg,int argsz,void*outv)。
實(shí)現(xiàn)功能:MME會首先對Service Request消息進(jìn)行解碼,若解碼失敗則需發(fā)送Service Reject消息并釋放UE上下文,原因值EMMCause為Protocol ErrorO-rUnspecified,然后通過Initial消息中的stmsi找到UE上下文,之后驗(yàn)證Service Request消息是否通過完整性保護(hù),若未通過完整性保護(hù)則啟動鑒權(quán)過程,若通過完整性保護(hù),便啟動Service Request的后續(xù)過程。
圖3 服務(wù)請求前期處理模塊流程圖
函數(shù)接口:int emm_sf_servicereq_ok(ue_context_t*uecxt)。
實(shí)現(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ù)請求過程的具體實(shí)現(xiàn)過程,該前期處理模塊與后期處理模塊相結(jié)合的方式能夠關(guān)注到該信令流程的每個細(xì)節(jié),是一種較為合理的信令流程實(shí)現(xià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平臺,可在接口實(shí)時捕捉包,能顯示包的詳細(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,其中實(shí)際網(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)圖
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正常流程的抓包圖
基于Linux開發(fā)環(huán)境,設(shè)計并實(shí)現(xiàn)了LTE核心網(wǎng)EMM協(xié)議棧服務(wù)請求信令流程,經(jīng)測試,可滿足服務(wù)請求過程的正常流程和異常流程。在未來的通信發(fā)展中,隨著LTE的推廣和商用,相信對LTE核心網(wǎng)EMM協(xié)議棧信令流程的研究與實(shí)現(xiàn)將具有更廣泛的現(xiàn)實(shí)意義和應(yīng)用前景。
[1]張慶揚(yáng).4G核心網(wǎng)控制面協(xié)議棧的研究與實(shí)現(xiàn)[D].長春:吉林大學(xué),2011.
[2]王楓.3G移動通信核心網(wǎng)PS域模擬器的軟件設(shè)計與實(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.