金 艦 中國信息通信研究院泰爾終端實驗室工程師

吳 星 中國信息通信研究院泰爾終端實驗室助理工程師

1 引言

隨著物聯(lián)網(wǎng)產(chǎn)業(yè)市場的發(fā)展與成熟，其在未來經(jīng)濟社會發(fā)展中的戰(zhàn)略地位也越發(fā)凸顯，許多國家將其定為戰(zhàn)略性新興產(chǎn)業(yè)的重點發(fā)展領(lǐng)域。LPWAN（Low Power Wide Area Network，低功耗廣域網(wǎng)）是物聯(lián)網(wǎng)系統(tǒng)中的一類適用連接距離較長的廣域網(wǎng)通信技術(shù)方案。

3GPP（The 3rd Generation Partnership Project，第三代合作伙伴計劃）等國際標準組織對工作在授權(quán)頻段的LPWAN技術(shù)進行了標準定義，NB-IoT（Narrow Band-Internet of Things，窄帶物聯(lián)網(wǎng)）就是其中一種重要的窄帶蜂窩通信技術(shù)，作為物聯(lián)網(wǎng)技術(shù)的重要方案之一，隨著市場的發(fā)展和技術(shù)的成熟，目前NB-IoT系統(tǒng)商業(yè)化應用已經(jīng)進入飛速發(fā)展期。在標準方面，3GPP R14版本已于2017年6月凍結(jié)，為了更好地迎合市場需求在R13的基礎(chǔ)上NB-IoT增強技術(shù)又增加了定位和多播功能，提供了更高的數(shù)據(jù)速率，在非錨點載波上進行尋呼和隨機接入，增強了連接態(tài)的移動性，同時支持更低的UE功率等級。

NB-IoT終端一致性測試成為商用終端市場化步驟中不可或缺的內(nèi)容，不僅對不同廠商終端芯片的互聯(lián)互通有十分積極的作用，而且能避免不同芯片終端廠商對核心協(xié)議的理解造成的偏差。本文主要介紹NB-IoT協(xié)議一致性測試框架中的RRC連接管理特性部分，設計基于TTCN-3語言的終端協(xié)議一致性測試方案。

2 TTCN-3語言與NB-IoT一致性測試框架

TTCN-3 是 ETSI（European Telecommunications Standards Institut，歐洲電信標準協(xié)會）發(fā)布的專門針對模型測試和自動化互操作性測試的開發(fā)語言，可獨立于協(xié)議標準、測試方法和測試儀表在不同的硬件平臺上運行，具有良好的靈活性、擴展性和可移植性。TTCN-3就是TTCN的第三個版本。

終端協(xié)議一致性測試依賴大量的信令交互，在TTCN-3實現(xiàn)中，這些來往于協(xié)議棧各層間的信令由消息模板承載，通過在相關(guān)協(xié)議層中控制和比對信令消息模板給出測試的判決結(jié)果。

TTCN-3執(zhí)行測試例流程主要涉及到主控制部分和測試例部分。主控制部分包含運行測試例的一些初始化信息，保證各個功能模塊能正常運作。測試例代碼編寫部分和C代碼思路類似，只是使用TTCN-3的語法。

NB-IoT協(xié)議一致性測試系統(tǒng)仍沿用LTE系統(tǒng)架構(gòu)如圖1所示，TTCN-3代碼運行于Host PC之上，控制硬件平臺SS（系統(tǒng)模擬器）的行為。SS主要用來模擬網(wǎng)絡側(cè)的PDCP/RLC/MAC層和射頻部分。

3 NB-IoT RRC連接管理特性與測試模型

圖1 終端協(xié)議一致性測試系統(tǒng)架構(gòu)圖

NB-IoT的協(xié)議棧仍基于LTE設計，根據(jù)物聯(lián)網(wǎng)的特性，去掉了一些不必要的功能，減少了協(xié)議棧處理流程的開銷。為簡化信令交互，NB-IoT的無線接口協(xié)議棧提出了兩種EPS優(yōu)化方案：一種稱為控制面CIoT EPS優(yōu)化，最大的特點是通過NAS信令傳輸數(shù)據(jù)，減少控制面的消息總數(shù)，此方案具有強制性，在不激活用戶面的情況下，將用戶數(shù)據(jù)或SMS直接封裝在NAS消息中通過SRB傳輸；另一種稱為用戶面CIoT EPS優(yōu)化，基于用戶面?zhèn)鬏斢脩魯?shù)據(jù)，此方案是可選項。

傳統(tǒng)的RRC（Radio Resource Control，無線資源控制）層支持空閑和連接兩種狀態(tài)。由于NB-IoT不支持不同技術(shù)間的切換，RRC狀態(tài)模式相對簡單。與LTE系統(tǒng)相比，NB-IoT的RRC連接態(tài)也在LTE系統(tǒng)的基礎(chǔ)上減少了以下功能：網(wǎng)絡對切換、測量報告等移動性的控制；尋呼和系統(tǒng)消息的監(jiān)聽；信道質(zhì)量的反饋等。另外，NB-IoT的RRC空閑態(tài)存在以下變化：新增RRC Suspend/Resume過程、不支持終端空閑態(tài)的DRX等。當基站釋放連接時，基站會下達指令讓NB-IoT終端進入Suspend模式，該Suspend指令帶有一組Resume ID，此時終端進入Suspend模式并存儲當前的AS Context。當終端需要再次進行數(shù)據(jù)傳輸時，只需要在RRC Connection Resume Request中攜帶Resume ID，基站即可通過此ID來識別終端，并跳過相關(guān)配置信息交換，直接進入數(shù)據(jù)傳輸。此過程不僅大大減少了信令開銷，還延長了終端的電池壽命。

在最新發(fā)布的R14版本中，NB-IoT新增了支持CP模式下的RRC重建來實現(xiàn)業(yè)務態(tài)切換，即NB-IoT在CP模式、AS層安全性未激活情況下，支持RRC Connection Reestablishment，恢復 SRB1bis和數(shù)據(jù)傳輸。System Information Block Type2-NB通過CPR eestablishment字段指示小區(qū)是否允許重建，當發(fā)生無線鏈路失敗時，UE請求RRC Connection Reestablishment。

當eNB收到CP模式下RRC Connection Reestablishement Request后，在S1接口上把UE相關(guān)信息（S-TMSI UL-NAS-MAC UL-NAS-Count等）發(fā)送給MME。MME校驗UL-MAC信息，如果通過則生成DL-NAS-MAC，下發(fā)給基站。由基站下發(fā)RRC Connection Reestablishment，包括dl-NAS-MAC。如果校驗失敗，則認為恢復失敗，離開RRC連接狀態(tài)，如果校驗成功，UE使用配置的專用無線資源，UE恢復SRB1Bis，具體流程如圖2所示。

由于協(xié)議一致性測試的特殊性，對于RRC層及以上的協(xié)議一致性測試，TTCN-3模擬網(wǎng)絡側(cè)行為，SS使用正常功能的底層配置。NB-IoT RRC測試模型如圖3所示，本模式下將終端設置為正常模式，啟用包括完整性保護與加密保護的NAS安全，但不配置ROHC。對于用戶面，啟用PDCP和AS安全，同樣包括完整性保護與加密保護。網(wǎng)絡側(cè)的物理層、MAC層和RLC層配置為正常模式即可，保證實現(xiàn)各自功能。SRB0的下行端口和上行端口均在RLC層之上；SRB1的端口位于RRC/NAS仿真器之上；SRB1bis的端口位于RRC/NAS仿真器之下。這里的RRC/NAS仿真器作為一個并行測試組件，對NAS消息提供加密和完整性功能。對于用戶面，PDCP層配置為正常模式，DRB端口位于PDCP層之上，啟用AS安全。同時，TTCN代碼中還要通過系統(tǒng)控制端口對上行調(diào)度授權(quán)和下行調(diào)度分配進行配置。

圖2 CP模式下的RRC重建

圖3 NB-IoT RRC層測試模型

4 用例無線鏈路失敗的設計與實現(xiàn)

為保障終端協(xié)議棧實現(xiàn)的完整性，NB-IoT協(xié)議一致性測試用例采用對每個協(xié)議層單獨測試的方法。NB-IoT的RRC層測試用例集中在TS 36.523-1中的第22章，本節(jié)以無線鏈路失敗為例，體現(xiàn)RRC連接重配的TTCN-3設計過程。

終端在進行RRC連接建立過程、RRC連接恢復過程、RRC連接重建立過程和RRC連接重配過程中，可以通過專用無線資源配置（例如，RRC連接建立消息、RRC連接恢復消息、RRC連接重建立消息和RRC連接重配置消息等）獲取無線鏈路失敗檢測以及空口無線鏈路恢復需要的參數(shù)，包括N310、N311、T301、T310及T311，相關(guān)參數(shù)如表1所示。

表1 參數(shù)表

當檢測到定時器T310超時，終端認為發(fā)生了無線鏈路失敗，如果未激活接入層安全，則終端通知NAS層發(fā)生了RRC連接失敗進入空閑態(tài)，如果已經(jīng)激活接入層安全，則終端發(fā)起RRC連接重建立過程。根據(jù)以上特征完成以下測試流程設計如圖4所示。

完整測試例的代碼設計，主要完成以下4個部分：

（1）測試數(shù)據(jù)類型定義，包括：消息結(jié)構(gòu)、IE(信息元素)結(jié)構(gòu)、內(nèi)部數(shù)據(jù)結(jié)構(gòu)。

（2）實際測試數(shù)據(jù)的構(gòu)建，包括：常量和模板、消息及參數(shù)值、消息及參數(shù)的匹配表達。

（3）測試配置的定義和管理建立：定義測試組件（Component）、定義測試端口（Port）、測試組件動態(tài)管理：測試組件到抽象測試系統(tǒng)接口的映射、測試組件接口間的連接、測試組件的創(chuàng)建與終止。

（4）測試流程的實現(xiàn)，包括：消息收發(fā)、過程函數(shù)的計算、測試結(jié)果驗證判決。

其中，一個測試流程對應一個TTCN-3函數(shù)。根據(jù)以上思路設計無線鏈路失敗的大致檢驗步驟如下：

●設置初始小區(qū)功率。

●等待10s（需設計時長＞T310+T311+不同步情況的時間）。

●改變小區(qū)功率滿足注冊條件。

●檢查終端是否在合適小區(qū)上發(fā)送RRCConnection Request-NB。

●UE進行TAU過程，釋放RRC連接。

●通過配置的SRB發(fā)送RRC連接重配置消息。

●等待UE發(fā)送RRCConnection Reconfiguration Complete-NB消息。

●測試例判決。

●釋放小區(qū)，關(guān)機結(jié)束。

在測試例初始化配置階段，首先需初始化NB-IoT系統(tǒng)配置。通過函數(shù)f_NBIOT_Init(c1,USER_PLANE)對所有小區(qū)、安全性、移動性參數(shù)進行初始化。

測試前言部分，創(chuàng)建NB-IoT小區(qū)，通過函數(shù)f_NBIOT_CellConfig_Def完成Ncell1和Ncell2創(chuàng)建和配置。f_NBIOT_CellInfo_GetSIB2()和f_NBIOT_CellInfo_SetSIB2()獲取Ncell1和Ncell2小區(qū)參數(shù)并修改t311_r13的值為ms30000后重新設置Ncell1和Ncell2的SIB2-NB消息如表2所示。

圖4 RRC代碼設計流程

在測試開始前，f_UT_Switch OnUE(UT,false)打開UE，f_NBIOT_CellInfo_GetGuti()獲取小區(qū)的GUTI（全球唯一臨時UE標識）并且在小區(qū)上完成注冊前兩步流程。該測試例檢測支持用戶面優(yōu)化的終端，所以還要激活接入層（AS）安全。然后，使用函數(shù)f_NBIOT_NAS_Attach Complete_UP()完成預置條件部分。

表2 SIB2-NB消息

測試主體部分流程不再贅述，主要實現(xiàn)函數(shù)如下：通過函數(shù)f_NBIOT_SetCell PowerList()配置調(diào)整小區(qū)功率，f_NBIOT_Tracking Area Update()發(fā)起跟蹤區(qū)域更新至新小區(qū)；通過函數(shù)f_NBIOT_Generic RbEst()建立無線承載；通過函數(shù)f_NBIOT_SS_RRC_Release Security()，f_NBIOT_SS_SRBs_DRBs_Reset()釋 放RRC安全、SRB、DRB，重新配置SRB、DRB；系統(tǒng)通過f_NBIOT_ActivateDRBs_RRCConnection Reconfig()發(fā)送RRC重配消息。

最后，通過函數(shù)f_NBIOT_TestBody_Set(false)表示測試主體結(jié)束，函數(shù)f_NBIOT_Postamble()完成測試條件復位，命令終端關(guān)機。

5 結(jié)束語

基于以上設計，通過儀表供應商提供的代碼調(diào)試工具實現(xiàn)用例編譯和運行，得到儀表輸出的測試結(jié)果。經(jīng)過分析測試日志對比特殊消息，得出驗證正確的測試判決結(jié)果與預期相符。

本文結(jié)合TTCN-3核心語言，重點關(guān)注NB-IoT協(xié)議一致性測試中的RRC連接管理內(nèi)容和流程設計。測試集作為GCF規(guī)定的終端進行一致性測試誰時必須使用的標準測試使其代碼，是儀表唯一的運行腳本和調(diào)試參考，深入理解協(xié)議重點流程的設計和實現(xiàn)，對推動NB-IoT終端一致性測試的發(fā)展以及NB-IoT設備的成熟商用能起到良好的推動作用。