[谷小勇 方一鳴 李培林]
基于TTCN-3的LTE非承載網(wǎng)絡(luò)注冊失敗的分析與對策*
[谷小勇 方一鳴 李培林]
為了更好地滿足端到端的QoS機制,以及對TD_LTE系統(tǒng)級測試儀表的開發(fā),需要對附著注冊過程中的異常機制進(jìn)行研究和改進(jìn),在詳細(xì)分析網(wǎng)絡(luò)承載原因的基礎(chǔ)之上,給出了一種新的對于非承載網(wǎng)絡(luò)注冊失敗原因的研究,首先分許出有關(guān)的異常機制并對其中幾種典型的異常機制進(jìn)行流程設(shè)計,然后搭建TTCN-3軟件平臺,通過系統(tǒng)級測試平臺驗證,同時獲取終端LOG圖,對終端和網(wǎng)絡(luò)端交互LOG信息進(jìn)行打印,對流程設(shè)計進(jìn)行驗證。
TD-LTE 默認(rèn)承載 非承載網(wǎng)絡(luò)失敗 TTCN-3
谷小勇
重慶郵電大學(xué),碩士研究生,主要研究方向:TD-LTE系統(tǒng)協(xié)議棧開發(fā)。
方一鳴
重慶郵電大學(xué),碩士研究生,主要研究方向:TD-LTE系統(tǒng)協(xié)議棧開發(fā)。
李培林
重慶郵電大學(xué),碩士研究生,主要研究方向:TD-LTE系統(tǒng)協(xié)議棧開發(fā)。
隨著4G技術(shù)的普及和應(yīng)用,分時長期演進(jìn)TD-LTE以其技術(shù)上的優(yōu)勢正在推動著整個通信業(yè)的發(fā)展,針對其新技術(shù)的各種應(yīng)用,測試環(huán)節(jié)顯得尤為重要。長期演進(jìn)系統(tǒng)中,UE實現(xiàn)端到端附著到網(wǎng)絡(luò)建立PDN連接是必不可少的一個環(huán)節(jié)[1],因為其關(guān)系整個LTE系統(tǒng)是否可以正常地實現(xiàn)各種所需業(yè)務(wù)。
在當(dāng)前附著注冊失敗的測試環(huán)節(jié)中,一般都是針對于承載網(wǎng)絡(luò)等異常機制[3]的測試,網(wǎng)絡(luò)僅僅反饋給用戶UE承載網(wǎng)絡(luò)失敗的原因,如網(wǎng)絡(luò)端失敗,UE端失敗等,這使得對于異常機制的研究不夠全面,僅僅是對一個異常方向的研究測試。本文將對非承載網(wǎng)絡(luò)失敗的原因,如業(yè)務(wù)原因,進(jìn)行研究處理,設(shè)計基于測試和測試控制表示法(Testing and Test Control Notation Version 3,TTCN-3)的平臺[2],根據(jù)非承載網(wǎng)絡(luò)失敗后的處理流程設(shè)計編寫測試用例[4],按照測試流程進(jìn)行非承載網(wǎng)絡(luò)注冊失敗的測試。
圖1 EPS網(wǎng)絡(luò)架構(gòu)
演進(jìn)分組系統(tǒng)EPS由LTE和SAE兩部分組成。LTE部分包括了用戶UE和eNB,SAE包括了包含了移動管理實體MME,服務(wù)網(wǎng)關(guān)Serving Gateway,分組數(shù)據(jù)網(wǎng)關(guān)PDN Gateway,以及策略與計費規(guī)則功能單元PCRF和歸屬用戶服務(wù)器HSS等部分,各模塊分別負(fù)責(zé)自己的相關(guān)功能,最終實現(xiàn)端到端的“永久在線”。
2.1 默認(rèn)承載成功建立的過程設(shè)計
為了UE和要求的PDN之間建立一個默認(rèn)的EPS承載[5]上下文,使UE獲得對應(yīng)PDN的IP連接。在UE第一次接入網(wǎng)絡(luò)時,PDN連接流程需要聯(lián)合EMM的附著流程。PDN連接請求消息和附著請求消息一起封裝為NAS消息發(fā)送至網(wǎng)絡(luò)端。如果網(wǎng)絡(luò)端同意UE接入網(wǎng)絡(luò),則發(fā)起默認(rèn)EPS承載文本激活流程。PDN連接流程具體如下:
① UE向MME發(fā) 送 PDN CONNECTIVITY REQUEST消息。
② MME收到PDN CONNECTIVITY REQUEST消息后,為UE分配該PDN連接的默認(rèn)承載EBI,選擇S-GW并向該S-GW發(fā)送CREATE SESSION REQUEST消息。
③ S-GW收到CREATE SESSION REQUEST消息后,在自己的EPS承載表中創(chuàng)建新實例,并向P-GW發(fā)送CREATE SESSION REQUEST消息。
④ P-GW收到CREATE SESSION REQUEST消息后,發(fā)起IP-CAN Session Establishment過程,與PCRF交互后確定默認(rèn)承載的QoS參數(shù)并為該UE分配IP地址,然后在自己的EPS承載表中創(chuàng)建新實例并向S-GW發(fā)送CREATE SESSION RESPONSE消息。
⑤ S-GW收到CREATE SESSION RESPONSE消息后,向MME發(fā)送CREATE SESSION RESPONSE消息。
⑥ MME收到CREATE SESSION RESPONSE消息后,如果該PDN連接被P-GW接受,則向UE發(fā)送ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST消息,由eNodeB轉(zhuǎn)發(fā)。
⑦ UE收到ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST消息后,保存EPS QoS和PDN address等信息,并向MME發(fā)送ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT消息,由eNodeB轉(zhuǎn)發(fā)。
⑧ MME收到ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT消息標(biāo)志著該PDN連接建立完成,意味著UE與P-GW之間已經(jīng)激活了一個默認(rèn)EPS承載文本。
圖2 默認(rèn)承載連接建立流程圖
2.2 非承載網(wǎng)絡(luò)注冊失敗的議程機制分析
然而上文分析的正常建立情況并不總能夠順利完成,異常機制是時常發(fā)生的。下面主要研究非承載網(wǎng)絡(luò)注冊失敗的異常情況:
(1)當(dāng)UE開始附著注冊時,UE發(fā)送附著請求給eNB,eNB將附著請求消息給MME[6];該過程對應(yīng)于流程圖中的①,②。
(2)MME,PGW,SGW,eNB,UE等在附著過程中進(jìn)行交互,如果MME與PCRF交互后PCRF拒絕,則拒絕消息中攜帶的字段表示的原因為用戶使用權(quán)限受限;該過程對應(yīng)于流程圖中的④,但是此時返回消息IP-CAN Session Establishment中包含的是失敗原因#29:user authentication failed。
(3)如果PGW或者SGW在計費過程中,則拒絕消息中攜帶的字段表示失敗的原因是運營商確定的禁止;該過程對應(yīng)于流程圖中的④,此時返回消息CREATE SESSION RESPONSE包含的是失敗原因#8:operator determined barring。
(4)如果MME與傳統(tǒng)的電路交換CS域交互后CS域拒絕,則拒絕消息中攜帶的字段表示的原因為用戶業(yè)務(wù)使用權(quán)限受限。該過程對應(yīng)于流程圖中的④,此時返回消息CREATE SESSION RESPONSE包含失敗原因#32:service option not supported;。
(5)在其他的實例中,如果MME與PCRF交互后PCRF拒絕,則拒絕消息中攜帶的字段表示失敗的原因是PCRF返回的具體原因;如果MME與傳統(tǒng)的電路交換CS域交互后CS域拒絕,則拒絕消息中攜帶的字段表示的原因為CS域返回的具體失敗原因。
(6)表示失敗原因的具體字段可以是現(xiàn)有字段,如協(xié)議配置選項PCO,也可以采用新增字段。
(7)MME通過eNB向UE發(fā)送攜帶了表示失敗原因的字段的拒絕消息,然后UE端會把返回的失敗原因告知給用戶,這樣手機用戶就會根據(jù)返回的具體原因做出正確的決策,例如,假如非承載網(wǎng)絡(luò)失敗原因注冊失敗是由于用戶的使用權(quán)限受到了限制,則使用用戶可以根據(jù)自己的需求決定開通想用的業(yè)務(wù),假如非承載網(wǎng)絡(luò)失敗原因注冊失敗是由于運營商確定的禁止,則用戶考慮是否為用戶欠費以決定續(xù)交費。
測試流程步驟如下:
步驟1:當(dāng)網(wǎng)絡(luò)端MME收到PDN CONNECTIVITY REQUEST消息后。判定用戶業(yè)務(wù)是否受限,當(dāng)用戶業(yè)務(wù)受限的情況下,直接返回攜帶非承載網(wǎng)絡(luò)失敗原因的拒絕消息給UE端的ESM層,由EMS進(jìn)行原因值分析后,通過原語將失敗原因傳到SPV應(yīng)用層,是的用戶獲知具體失敗的原因,然后做相應(yīng)的處理。
步驟2: 當(dāng)網(wǎng)絡(luò)端P-GW收到CREATE SESSION RESPONSE消息后。判定是否為運營商確定的禁止,當(dāng)當(dāng)前禁止的情況下,返回拒絕消息的操作通步驟1。
步驟3:當(dāng)網(wǎng)絡(luò)端MME與PCRF交互后PCRF拒絕后。判定是否為用戶使用權(quán)限受限,當(dāng)用戶使用權(quán)限受限的情況下,返回拒絕消息的操作通步驟1,如圖3所示。
4.1UE開機附著過程EPS成功建立的仿真結(jié)果圖:
圖4為TTCN-3系統(tǒng)級測試平臺的默認(rèn)的EPS承載成功建立完成,此情況下網(wǎng)絡(luò)端各個模塊成功進(jìn)行交互,沒有發(fā)生任何非承載網(wǎng)絡(luò)注冊失敗的異常,圖5為終端由于在與網(wǎng)絡(luò)端進(jìn)行交互的過程中各個狀態(tài)的變化情況,從圖中可以看出終端UE成功接收到網(wǎng)絡(luò)端EPS承載建立接受的消息,最終終端UE實現(xiàn)附著完成。
圖6為網(wǎng)絡(luò)端回復(fù)給UE的原語中攜帶的協(xié)議配置選項的內(nèi)容,該內(nèi)容包含在圖中的ACT_DEF_EPS_ BEARER_CTX_REQ當(dāng)中,由EMM層發(fā)送給ESM層,在注冊過成功的測試中,不進(jìn)行非承載網(wǎng)絡(luò)注冊失敗原因的協(xié)議選項配置,僅僅包含網(wǎng)絡(luò)端需要的發(fā)送給終端UE的一些所需信息。
4.2UE開機附著過程由于非承載網(wǎng)絡(luò)原因失敗的仿真結(jié)果圖
圖7為TTCN-3系統(tǒng)級測試平臺中由于非承載網(wǎng)絡(luò)原因默認(rèn)的EPS承載建立失敗的情況,此情況下由于網(wǎng)絡(luò)端人為設(shè)置了非承載網(wǎng)絡(luò)異常的設(shè)置,最終終端UE沒有成功注冊,沒有建立EPS承載,圖8為網(wǎng)絡(luò)端人為設(shè)置了非承載網(wǎng)絡(luò)異常的情況下,終端與網(wǎng)絡(luò)端交互中各個狀態(tài)的變化的情況,從圖8可以看出終端UE收到了非承載網(wǎng)絡(luò)失敗的原因值,并且在SPV應(yīng)用層成功顯示了具體的原因,成功告知了用戶非承載網(wǎng)絡(luò)失敗的具體原因。
圖9為網(wǎng)絡(luò)端回復(fù)給UE的原語中攜帶的協(xié)議配置選項的內(nèi)容,在注冊過失敗的測試中,網(wǎng)絡(luò)端進(jìn)行了非承載網(wǎng)絡(luò)注冊失敗原因的的協(xié)議選項配置,圖中具體為EMM CASE <#8 failure>,即非承載網(wǎng)絡(luò)失敗的原因為前文提到的運營商確定的禁止,測試中,終端UE成功接收到該配置選項并成功由會ESM層解析后發(fā)送給了SPV應(yīng)用層,終端用戶成功獲得具體的非承載網(wǎng)絡(luò)失敗原因。
圖3 測試流程設(shè)計圖
圖4 注冊成功TTCN-3測試圖
圖5 注冊成功UE終端消息收發(fā)logo圖
圖6 UE終端協(xié)議配置選項圖
圖7 注冊失敗TTCN-3測試圖
圖8 注冊失敗UE終端消息收發(fā)logo圖
圖9 UE終端協(xié)議配置選項圖
本文提出了一種TD-LTE系統(tǒng)中非承載網(wǎng)絡(luò)注冊失敗的改進(jìn)處理方法,通過攜帶表示非承載網(wǎng)絡(luò)失敗的原因給應(yīng)用層用戶,解決了在附著注冊過程中,用戶無法及時準(zhǔn)確分辨出是承載網(wǎng)絡(luò)原因還是非承載網(wǎng)絡(luò)失敗的原因,用TTC-3為測試平臺對該過程進(jìn)行測試和驗證,測試結(jié)果表明,非承載網(wǎng)絡(luò)原因注冊失敗的改進(jìn)處理完全符合預(yù)期結(jié)果。
1 3GPP.3GPP TS 24.301,Non-Access-Stratum (NAS)protocol for Evolved Packet System (EPS)[S].2012
2 陳發(fā)堂,牛勇清,韓娜娜.協(xié)議一致性測試平臺的搭建及仿真實現(xiàn)[J].電子技術(shù)應(yīng)用,2014,40(4):137-140
3 李小文,李媚媚.TD-LTE系統(tǒng)EMM的介紹及其異常機制的研究[J].通信熱點,2013,04
4 3GPP.TS 36.508 Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access(E-UTRA)and Evolved Packet Core(EPC);Common test environments for Use Equipment(UE)conformance testing[S].France: 3GPP Organizational Partners,2012
5 劉向玉,張紅帥.TD-LTE系統(tǒng)ESM層默認(rèn)承載建立過程的研究與實現(xiàn)[J].現(xiàn)代電信科技,2012,(03)
6 李小文,肖壘,宋海貝.TD-LTE系統(tǒng)移動性管理實體測試研究[J].光通信研究.2011(04)
7 董宏成,張寧,李小文,TTCN-3在RRC協(xié)議一致性測試中的應(yīng)用 [J],電子技術(shù)應(yīng)用,2013第39卷第7期117-120
10.3969/j.issn.1006-6403.2016.08.015
2016-07-31)
國家科技重大專項資助項目“TD-LTE TTCN 擴展測試集儀表開發(fā)(無線資源管理部分)”(No.2012ZX03001024)