［谷小勇 方一鳴 李培林］

基于TTCN-3的LTE非承載網(wǎng)絡注冊失敗的分析與對策*

［谷小勇 方一鳴 李培林］

為了更好地滿足端到端的QoS機制，以及對TD_LTE系統(tǒng)級測試儀表的開發(fā)，需要對附著注冊過程中的異常機制進行研究和改進，在詳細分析網(wǎng)絡承載原因的基礎之上，給出了一種新的對于非承載網(wǎng)絡注冊失敗原因的研究，首先分許出有關的異常機制并對其中幾種典型的異常機制進行流程設計，然后搭建TTCN-3軟件平臺，通過系統(tǒng)級測試平臺驗證，同時獲取終端LOG圖，對終端和網(wǎng)絡端交互LOG信息進行打印，對流程設計進行驗證。

TD-LTE 默認承載 非承載網(wǎng)絡失敗 TTCN-3

谷小勇

重慶郵電大學，碩士研究生，主要研究方向：TD-LTE系統(tǒng)協(xié)議棧開發(fā)。

方一鳴

重慶郵電大學，碩士研究生，主要研究方向：TD-LTE系統(tǒng)協(xié)議棧開發(fā)。

李培林

重慶郵電大學，碩士研究生，主要研究方向：TD-LTE系統(tǒng)協(xié)議棧開發(fā)。

引言

隨著4G技術的普及和應用，分時長期演進TD-LTE以其技術上的優(yōu)勢正在推動著整個通信業(yè)的發(fā)展，針對其新技術的各種應用，測試環(huán)節(jié)顯得尤為重要。長期演進系統(tǒng)中，UE實現(xiàn)端到端附著到網(wǎng)絡建立PDN連接是必不可少的一個環(huán)節(jié)［1］，因為其關系整個LTE系統(tǒng)是否可以正常地實現(xiàn)各種所需業(yè)務。

在當前附著注冊失敗的測試環(huán)節(jié)中，一般都是針對于承載網(wǎng)絡等異常機制［3］的測試，網(wǎng)絡僅僅反饋給用戶UE承載網(wǎng)絡失敗的原因，如網(wǎng)絡端失敗，UE端失敗等，這使得對于異常機制的研究不夠全面，僅僅是對一個異常方向的研究測試。本文將對非承載網(wǎng)絡失敗的原因，如業(yè)務原因，進行研究處理，設計基于測試和測試控制表示法（Testing and Test Control Notation Version 3，TTCN-3）的平臺［2］，根據(jù)非承載網(wǎng)絡失敗后的處理流程設計編寫測試用例［4］，按照測試流程進行非承載網(wǎng)絡注冊失敗的測試。

1 LTE系統(tǒng)EPS總體架構

圖1 EPS網(wǎng)絡架構

演進分組系統(tǒng)EPS由LTE和SAE兩部分組成。LTE部分包括了用戶UE和eNB，SAE包括了包含了移動管理實體MME，服務網(wǎng)關Serving Gateway，分組數(shù)據(jù)網(wǎng)關PDN Gateway，以及策略與計費規(guī)則功能單元PCRF和歸屬用戶服務器HSS等部分，各模塊分別負責自己的相關功能，最終實現(xiàn)端到端的“永久在線”。

2 開機注冊過程中默認EPS承載的分析

2.1 默認承載成功建立的過程設計

為了UE和要求的PDN之間建立一個默認的EPS承載［5］上下文，使UE獲得對應PDN的IP連接。在UE第一次接入網(wǎng)絡時，PDN連接流程需要聯(lián)合EMM的附著流程。PDN連接請求消息和附著請求消息一起封裝為NAS消息發(fā)送至網(wǎng)絡端。如果網(wǎng)絡端同意UE接入網(wǎng)絡，則發(fā)起默認EPS承載文本激活流程。PDN連接流程具體如下：

① UE向MME發(fā) 送 PDN CONNECTIVITY REQUEST消息。

② MME收到PDN CONNECTIVITY REQUEST消息后，為UE分配該PDN連接的默認承載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交互后確定默認承載的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消息標志著該PDN連接建立完成，意味著UE與P-GW之間已經(jīng)激活了一個默認EPS承載文本。

圖2 默認承載連接建立流程圖

2.2 非承載網(wǎng)絡注冊失敗的議程機制分析

然而上文分析的正常建立情況并不總能夠順利完成，異常機制是時常發(fā)生的。下面主要研究非承載網(wǎng)絡注冊失敗的異常情況：

（1）當UE開始附著注冊時，UE發(fā)送附著請求給eNB，eNB將附著請求消息給MME［6］；該過程對應于流程圖中的①，②。

（2）MME，PGW，SGW，eNB，UE等在附著過程中進行交互，如果MME與PCRF交互后PCRF拒絕，則拒絕消息中攜帶的字段表示的原因為用戶使用權限受限；該過程對應于流程圖中的④，但是此時返回消息IP-CAN Session Establishment中包含的是失敗原因#29：user authentication failed。

（3）如果PGW或者SGW在計費過程中，則拒絕消息中攜帶的字段表示失敗的原因是運營商確定的禁止；該過程對應于流程圖中的④，此時返回消息CREATE SESSION RESPONSE包含的是失敗原因#8：operator determined barring。

（4）如果MME與傳統(tǒng)的電路交換CS域交互后CS域拒絕，則拒絕消息中攜帶的字段表示的原因為用戶業(yè)務使用權限受限。該過程對應于流程圖中的④，此時返回消息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)絡失敗原因注冊失敗是由于用戶的使用權限受到了限制，則使用用戶可以根據(jù)自己的需求決定開通想用的業(yè)務，假如非承載網(wǎng)絡失敗原因注冊失敗是由于運營商確定的禁止，則用戶考慮是否為用戶欠費以決定續(xù)交費。

3 測試流程設計

測試流程步驟如下：

步驟1：當網(wǎng)絡端MME收到PDN CONNECTIVITY REQUEST消息后。判定用戶業(yè)務是否受限，當用戶業(yè)務受限的情況下，直接返回攜帶非承載網(wǎng)絡失敗原因的拒絕消息給UE端的ESM層，由EMS進行原因值分析后，通過原語將失敗原因傳到SPV應用層，是的用戶獲知具體失敗的原因，然后做相應的處理。

步驟2： 當網(wǎng)絡端P-GW收到CREATE SESSION RESPONSE消息后。判定是否為運營商確定的禁止，當當前禁止的情況下，返回拒絕消息的操作通步驟1。

步驟3：當網(wǎng)絡端MME與PCRF交互后PCRF拒絕后。判定是否為用戶使用權限受限，當用戶使用權限受限的情況下，返回拒絕消息的操作通步驟1，如圖3所示。

4 TTCN-3仿真測試對比結果與對比分析

4.1UE開機附著過程EPS成功建立的仿真結果圖：

圖4為TTCN-3系統(tǒng)級測試平臺的默認的EPS承載成功建立完成，此情況下網(wǎng)絡端各個模塊成功進行交互，沒有發(fā)生任何非承載網(wǎng)絡注冊失敗的異常，圖5為終端由于在與網(wǎng)絡端進行交互的過程中各個狀態(tài)的變化情況，從圖中可以看出終端UE成功接收到網(wǎng)絡端EPS承載建立接受的消息，最終終端UE實現(xiàn)附著完成。

圖6為網(wǎng)絡端回復給UE的原語中攜帶的協(xié)議配置選項的內(nèi)容，該內(nèi)容包含在圖中的ACT_DEF_EPS_ BEARER_CTX_REQ當中，由EMM層發(fā)送給ESM層，在注冊過成功的測試中，不進行非承載網(wǎng)絡注冊失敗原因的協(xié)議選項配置，僅僅包含網(wǎng)絡端需要的發(fā)送給終端UE的一些所需信息。

4.2UE開機附著過程由于非承載網(wǎng)絡原因失敗的仿真結果圖

圖7為TTCN-3系統(tǒng)級測試平臺中由于非承載網(wǎng)絡原因默認的EPS承載建立失敗的情況，此情況下由于網(wǎng)絡端人為設置了非承載網(wǎng)絡異常的設置，最終終端UE沒有成功注冊，沒有建立EPS承載，圖8為網(wǎng)絡端人為設置了非承載網(wǎng)絡異常的情況下，終端與網(wǎng)絡端交互中各個狀態(tài)的變化的情況，從圖8可以看出終端UE收到了非承載網(wǎng)絡失敗的原因值，并且在SPV應用層成功顯示了具體的原因，成功告知了用戶非承載網(wǎng)絡失敗的具體原因。

圖9為網(wǎng)絡端回復給UE的原語中攜帶的協(xié)議配置選項的內(nèi)容，在注冊過失敗的測試中，網(wǎng)絡端進行了非承載網(wǎng)絡注冊失敗原因的的協(xié)議選項配置，圖中具體為EMM CASE ＜#8 failure＞，即非承載網(wǎng)絡失敗的原因為前文提到的運營商確定的禁止，測試中，終端UE成功接收到該配置選項并成功由會ESM層解析后發(fā)送給了SPV應用層，終端用戶成功獲得具體的非承載網(wǎng)絡失敗原因。

圖3 測試流程設計圖

圖4 注冊成功TTCN-3測試圖

圖5 注冊成功UE終端消息收發(fā)logo圖

圖6 UE終端協(xié)議配置選項圖

圖7 注冊失敗TTCN-3測試圖

圖8 注冊失敗UE終端消息收發(fā)logo圖

圖9 UE終端協(xié)議配置選項圖

5 結論

本文提出了一種TD-LTE系統(tǒng)中非承載網(wǎng)絡注冊失敗的改進處理方法，通過攜帶表示非承載網(wǎng)絡失敗的原因給應用層用戶，解決了在附著注冊過程中，用戶無法及時準確分辨出是承載網(wǎng)絡原因還是非承載網(wǎng)絡失敗的原因，用TTC-3為測試平臺對該過程進行測試和驗證，測試結果表明，非承載網(wǎng)絡原因注冊失敗的改進處理完全符合預期結果。

1 3GPP.3GPP TS 24.301，Non-Access-Stratum （NAS）protocol for Evolved Packet System （EPS）［S］.2012

2 陳發(fā)堂，牛勇清，韓娜娜.協(xié)議一致性測試平臺的搭建及仿真實現(xiàn)［J］.電子技術應用，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層默認承載建立過程的研究與實現(xiàn)［J］.現(xiàn)代電信科技，2012，（03）

6 李小文，肖壘，宋海貝.TD-LTE系統(tǒng)移動性管理實體測試研究［J］.光通信研究.2011（04）

7 董宏成，張寧，李小文，TTCN-3在RRC協(xié)議一致性測試中的應用 ［J］，電子技術應用，2013第39卷第7期117-120

10.3969/j.issn.1006-6403.2016.08.015

2016-07-31）

國家科技重大專項資助項目“TD-LTE TTCN 擴展測試集儀表開發(fā)（無線資源管理部分）”（No.2012ZX03001024）