本發(fā)明涉及通信領(lǐng)域，具體涉及一種窄帶物聯(lián)網(wǎng)終端一致性測試方法。

背景技術(shù)：

窄帶物聯(lián)網(wǎng)(Narrow Band Internet of Things，NB-IoT)是低功耗廣域網(wǎng)(Low Power Wide Access，LPWA)的眾多技術(shù)之一，其可以支持低功耗設(shè)備在廣域網(wǎng)的蜂窩數(shù)據(jù)連接。NB-IoT具備四大特點(diǎn)：一是廣覆蓋，將提供改進(jìn)的室內(nèi)覆蓋，在同樣的頻段下，NB-IoT比現(xiàn)有的網(wǎng)絡(luò)增益20dB，覆蓋面積擴(kuò)大100倍；二是具備支撐海量連接的能力，NB-IoT一個(gè)扇區(qū)能夠支持10萬個(gè)連接，支持低延時(shí)敏感度、超低的設(shè)備成本、低功耗和優(yōu)化的網(wǎng)絡(luò)架構(gòu)；三是更低功耗，NB-IoT終端模塊的待機(jī)時(shí)間可長達(dá)10年；四是更低的模塊成本，企業(yè)預(yù)期的單個(gè)接連模塊不超過5美元?？梢詮V泛應(yīng)用于多種垂直行業(yè)，如遠(yuǎn)程抄表、資產(chǎn)跟蹤、智能停車、智慧農(nóng)業(yè)等。

NB-IoT使用180kHz上下行帶寬通過E-UTRA接入網(wǎng)絡(luò)，可直接部署于GSM網(wǎng)絡(luò)或LTE網(wǎng)絡(luò)。NB-IoT有三種部署的模式：Stand-alone operation、Guard-band operation以及In-band operation。下行使用OFDMA多址技術(shù)，上行使用SC-FDMA，分為單音(Single-tone，一個(gè)上行子載波)和多音(Multi-tone，多個(gè)上行子載波)。Rel13的NB-IoT采用的是半雙工的FDD，暫不支持TDD。NB-IoT支持多載波(Multi-carrier，即Multi-PRB)方式，即可以另外使用其他非錨定(non-anchor)NB-IoT載波來傳數(shù)據(jù)，具體結(jié)合部署方式，可支持的組合有inband+inband、inband+guardband、guardband+guardband、Standalone+standalone，不支持standalone mode和guard-band或in-band的組合。目前我國運(yùn)營商計(jì)劃對NB-IoT的部署在GSM頻段上，主要集中在800-900MHz。

NB-IoT技術(shù)的核心規(guī)范雖然寫在LTE(長期演進(jìn))規(guī)范中，但仍然認(rèn)為它是一個(gè)獨(dú)立的RAT(Radio Access Technologies，無線接入技術(shù))，其與LTE技術(shù)主要差別在于其對LTE的媒體接入層(MAC)、無線鏈路控制層(RLC)以及分組數(shù)據(jù)匯聚協(xié)議(PDCP)層協(xié)議功能進(jìn)行了簡化和調(diào)整，對無線資源控制(RRC)層新添加了掛起-恢復(fù)(suspend-resume)流程，NAS協(xié)議中引入了新的專用的消息和過程，以便快速恢復(fù)連接。NB-IoT分為三種解決方案：一種是控制平面解決方案(Control Plane Solution，簡稱CP solution，或稱為Control Plane CIoT EPS optimizations)，一種是用戶平面解決方法(User Plane Solution，簡稱UP solution，或稱為User Plane CIoT EPS optimizations)和同時(shí)使用兩種解決方案。其中CP解決方案是NB-IoT終端必須支持的，UP解決方案是可選支持的。

同時(shí)，TTCN-3(Testing and Test Control Notation)作為TD-LTE及后續(xù)的4G無線移動通信終端一致性測試的通用語言，使用其腳本控制實(shí)現(xiàn)對終端協(xié)議棧信令一致性測試的可靠性和成熟度已被業(yè)界廣泛認(rèn)可。TTCN-3測試?yán)a明確定義了終端一致性測試中所有測試?yán)臏y試條件、測試流程及配置消息內(nèi)容等參數(shù)，通過在終端一致性測試儀表平臺上運(yùn)行該腳本，測試出不同廠商的被測終端(芯片)對核心協(xié)議的解讀與實(shí)現(xiàn)是否一致，最終保障通過認(rèn)證的商用終端在現(xiàn)網(wǎng)中與能夠不同廠商的網(wǎng)絡(luò)設(shè)備之間互連互通。

目前缺乏對于NB-IoT終端的一致性測試方法。

技術(shù)實(shí)現(xiàn)要素：

有鑒于此，本發(fā)明提供一種窄帶物聯(lián)網(wǎng)終端一致性測試方法和系統(tǒng)，對NB-IoT終端的協(xié)議一致性進(jìn)行測試。

第一方面，提供一種窄帶物聯(lián)網(wǎng)(NB-IoT)終端一致性測試方法，包括：

步驟S100、將待測試終端設(shè)置為第一測試回環(huán)模式，在第一測試回環(huán)模式下，所述待測試終端對于接收到的由無線資源控制層(RRC)承載的包裹于非接入層(NAS)消息中的下行用戶數(shù)據(jù)不處理數(shù)據(jù)內(nèi)容直接通過非接入(NAS)層消息返回；同時(shí)，將待測試終端的NAS層設(shè)置為使用空加密算法，不使用健壯性頭壓縮(ROHC)；

步驟S200、主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器中的物理層(PHY)設(shè)置為標(biāo)準(zhǔn)配置，SRB1bis端口的媒體接入層(MAC)設(shè)置為下行不添加MAC層包頭并且上行不去除MAC包頭或者僅下行不添加MAC包頭，將SRB1bis端口的無線鏈路控制層(RLC)設(shè)置為透明模式(TM)；或者，主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器的PHY層和MAC層設(shè)置為標(biāo)準(zhǔn)配置，將RLC層設(shè)置為透明模式；

步驟S300、主計(jì)算機(jī)建立和分解上行和/或下行MAC和/或RLC層頭、控制RLC層序列號(SN，Sequence Number)和狀態(tài)變量，調(diào)用RRC和NAS編解碼器。通過向系統(tǒng)模擬器的SRB1bis下行RLC層端口下發(fā)攜帶了承載用戶數(shù)據(jù)NAS消息的MAC層協(xié)議數(shù)據(jù)單元(PDU)，并在SRB1bis上行端口接收MAC層PDU或RLC層PDU，根據(jù)接收到的所述PDU檢測所述待測試終端的媒體接入層協(xié)議一致性；或者，主計(jì)算機(jī)通過向系統(tǒng)模擬器的SRB1bis下行RLC層端口發(fā)送攜帶了承載用戶數(shù)據(jù)NAS消息的RLC層PDU，并在SRB1bis上行端口接收RLC層PDU，根據(jù)接收到的所述RLC層PDU檢測所述待測試終端的無線鏈路控制層協(xié)議一致性。

優(yōu)選地，所述方法還包括：

步驟400、將待測試終端設(shè)置為第二測試回環(huán)模式，在第二測試回環(huán)模式下，所述待測試終端通過雙向數(shù)據(jù)無線承載(DRB)對于接收到的分組數(shù)據(jù)匯聚協(xié)議(PDCP)層的下行用戶數(shù)據(jù)不處理數(shù)據(jù)內(nèi)容將PDCP層PDU回環(huán)；同時(shí)，將待測試終端設(shè)置為使用加密和ROHC；

步驟500、主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器的PHY層、MAC層和RLC層設(shè)置為標(biāo)準(zhǔn)模式，將PDCP層配置為在上行方向和/或下行方向不進(jìn)行頭處理，只對下行方向配置ROHC，上行接收ROHC的反饋消息；

步驟600、主計(jì)算機(jī)控制PDCP層SN和狀態(tài)變量，通過DRB下行端口向系統(tǒng)模擬器的PDCP層下發(fā)PDCP層PDU，并在DRB上行端口接收PDCP層PDU，根據(jù)接收到的所述PDU檢測所述待測試終端的具有ROHC模式的PDCP層的協(xié)議一致性。

優(yōu)選地，所述方法還包括：

步驟S700、將待測試終端設(shè)置為第二測試回環(huán)模式；同時(shí)，將待測試終端設(shè)置為使用加密但不使用ROHC；

步驟S800、將主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器的協(xié)議棧中的PHY層、MAC層和RLC控制層設(shè)置為標(biāo)準(zhǔn)模式，將PDCP層配置為透明模式使得PDCP層在下行方向不添加PDCP頭且在上行方向不移除PDCP頭；

步驟S900、主計(jì)算機(jī)控制PDCP層SN和狀態(tài)變量，通過DRB下行端口向系統(tǒng)模擬器的PDCP層下發(fā)PDCP層PDU，并在DRB上行端口接收PDCP層PDU，根據(jù)接收到的所述PDU檢測所述待測試終端的非ROHC模式的PDCP層的協(xié)議一致性。

優(yōu)選地，所述主計(jì)算機(jī)通過讀取TTCN測試程序進(jìn)行所述配置。

第二方面，提供一種窄帶物聯(lián)網(wǎng)(NB-IoT)終端一致性測試方法，包括：：

步驟S1000、將待測試終端設(shè)置為正常模式；同時(shí)，將待測試終端設(shè)置為使用NAS加密和完整性保護(hù)，不使用ROHC；或者，將待測試終端設(shè)置為使用PDCP和NAS加密和完整性保護(hù)，不使用ROHC；

步驟S1100、主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器的PHY層、MAC層和RLC層設(shè)置為標(biāo)準(zhǔn)模式，同時(shí)，啟用NAS加密和完整性保護(hù)；或者，主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器的PHY層、MAC層、RLC層和PDCP層設(shè)置為標(biāo)準(zhǔn)模式，同時(shí)，啟用PDCP和NAS加密和完整性保護(hù)；

步驟S1200、主計(jì)算機(jī)在下行方向完成待發(fā)送NAS消息的加密和完整性保護(hù)后通過SRB1bis端口下發(fā)承載/未承載NAS消息的RRC消息或通過SRB0下發(fā)RRC消息到系統(tǒng)模擬器的RRC層，同時(shí)，在上行方向上接收系統(tǒng)模擬器通過SRB1bis端口上報(bào)的包含安全保護(hù)和已編碼NAS消息的RRC消息和/或通過SRB0端口上報(bào)的RRC消息，根據(jù)接收到的所述消息檢測所述待測試終端的RRC層的協(xié)議一致性；或者，主計(jì)算機(jī)在下行方向完成待發(fā)送NAS消息的加密和完整性保護(hù)后通過SRB1端口下發(fā)承載/未承載NAS消息的RRC消息或通過SRB0下發(fā)RRC消息到系統(tǒng)模擬器的RRC層，同時(shí)，在上行方向上通過SRB1和/或通過SRB0端口接收系統(tǒng)模擬器RRC層上報(bào)的消息，根據(jù)接收到的所述消息檢測所述待測試終端的RRC層的協(xié)議一致性。

優(yōu)選地，所述主計(jì)算機(jī)通過讀取TTCN測試程序進(jìn)行所述配置。

第三方面，一種窄帶物聯(lián)網(wǎng)(NB-IoT)終端一致性測試系統(tǒng)，包括：

待測試終端；

系統(tǒng)模擬器；以及

主計(jì)算機(jī)，與所述待測試終端和所述系統(tǒng)模擬器連接，適于執(zhí)行如上所述的方法。

通過本發(fā)明的方法和系統(tǒng)，可以較好地進(jìn)行NB-IoT終端的協(xié)議一致性的測試，有助于優(yōu)化測試流程，促進(jìn)對NB-IoT終端的開發(fā)和完善。

附圖說明

通過以下參照附圖對本發(fā)明實(shí)施例的描述，本發(fā)明的上述以及其它目的、特征和優(yōu)點(diǎn)將更為清楚，在附圖中：

圖1是發(fā)明實(shí)施例的測試系統(tǒng)的示意圖；

圖2A是本發(fā)明實(shí)施例的第一測試回環(huán)模式的協(xié)議模型示意圖；

圖2B是本發(fā)明實(shí)施例的第二測試回環(huán)模式的協(xié)議模型示意圖；

圖3A是本發(fā)明實(shí)施例的MAC層測試流程的模型示意圖；

圖3B是本發(fā)明實(shí)施例的MAC層測試流程的流程圖；

圖4A是本發(fā)明實(shí)施例的RLC層測試流程的模型示意圖；

圖4B是本發(fā)明實(shí)施例的RLC層測試流程的流程圖；

圖5A是本發(fā)明實(shí)施例的ROHC模式的PDCP層測試流程的模型示意圖；

圖5B是本發(fā)明實(shí)施例的ROHC模式的PDCP層測試流程的模型示意圖；

圖6A是本發(fā)明實(shí)施例的非ROHC模式的PDCP層測試流程的模型示意圖；

圖6B是本發(fā)明實(shí)施例的非ROHC模式的PDCP層測試流程的模型示意圖；

圖7A是本發(fā)明實(shí)施例的對CP解決方案的RRC層測試流程的模型示意圖；

圖7B是本發(fā)明實(shí)施例的對CP解決方案的RRC層測試流程的流程圖；

圖8A是本發(fā)明實(shí)施例的對UP解決方案的RRC層測試流程的模型示意圖；

圖8B是本發(fā)明實(shí)施例的對UP解決方案的RRC層測試流程的流程圖。

具體實(shí)施方式

以下基于實(shí)施例對本發(fā)明進(jìn)行描述，但是本發(fā)明并不僅僅限于這些實(shí)施例。在下文對本發(fā)明的細(xì)節(jié)描述中，詳盡描述了一些特定的細(xì)節(jié)部分。對本領(lǐng)域技術(shù)人員來說沒有這些細(xì)節(jié)部分的描述也可以完全理解本發(fā)明。為了避免混淆本發(fā)明的實(shí)質(zhì)，公知的方法、過程、流程、元件和電路并沒有詳細(xì)敘述。

除非上下文明確要求，否則整個(gè)說明書和權(quán)利要求書中的“包括”、“包含”等類似詞語應(yīng)當(dāng)解釋為包含的含義而不是排他或窮舉的含義；也就是說，是“包括但不限于”的含義。

在本發(fā)明的描述中，需要理解的是，術(shù)語“第一”、“第二”等僅用于描述目的，而不能理解為指示或暗示相對重要性。此外，在本發(fā)明的描述中，除非另有說明，“多個(gè)”的含義是兩個(gè)或兩個(gè)以上。

圖1是本發(fā)明實(shí)施例的測試系統(tǒng)的示意圖。如圖1所示，所述測試系統(tǒng)包括主計(jì)算機(jī)Host-PC、系統(tǒng)模擬器SS和被測試用戶設(shè)備UE。

其中，主計(jì)算機(jī)Host-PC承載TTCN3代碼，產(chǎn)生TTCN-3運(yùn)行所需的編譯代碼，用于控制系統(tǒng)模擬器SS執(zhí)行測試流程。

系統(tǒng)模擬器SS承載有NB-IoT協(xié)議棧，可以模擬網(wǎng)絡(luò)側(cè)的RLC(Radio Link Control，無線鏈路控制)層、MAC(Media Access Control，媒體訪問控制)層、物理層和射頻部分，根據(jù)Host-PC控制與被測試用戶終端UE通過控制接口連接。

由此，通過主計(jì)算機(jī)Host-PC控制系統(tǒng)模擬器SS模擬網(wǎng)絡(luò)側(cè)發(fā)送和接收基于NB-IoT的信令，可以實(shí)現(xiàn)對于被測試用戶終端UE的一致性測試。

根據(jù)需要測試的是CP解決方案的功能還是UP解決方案的功能，待測試終端可以被配置為不同的回環(huán)模式以進(jìn)行對應(yīng)的測試。對于CP解決方案和UP解決方案都支持的功能可以僅在第一測試回環(huán)模式下進(jìn)行測試。對于UP解決方案獨(dú)有的功能需要在UP解決方案對應(yīng)的測試環(huán)境下單獨(dú)進(jìn)行測試。NB-IoT的測試?yán)裳赜肔TE測試?yán)脑O(shè)計(jì)思路，即采用對每個(gè)協(xié)議層單獨(dú)測試的方法，所以本發(fā)明提出對NB-IoT終端協(xié)議棧的媒體接入(MAC)層、無線鏈路控制(RLC)層、分組數(shù)據(jù)匯聚協(xié)議(PDCP)層以及無線資源控制(RRC)層的測試模型作為測試的參考和基礎(chǔ)。

NB-IoT CP和UP解決方案共同與LTE的區(qū)別包括：MAC層傳輸塊(Transmission Block Size，TBS)變小，僅有1個(gè)混合自動重傳請求(Hybrid Automatic Repeat reQuest，HARQ)進(jìn)程，沒有RLC UM模式，沒有SRB2端口(Signaling Radio Bearers—信令無線承載)，新增SRB1bis端口替代未激活安全的SRB1，獨(dú)立ASN.1且可引用LTE已有定義。

同時(shí)，CP解決方案與LTE的主要區(qū)別還包括：無DRB(Data Radio Bearer，數(shù)據(jù)無線承載)，無PDCP，無AS(Access Stratum，接入層)安全保護(hù)，不支持RRC連接重建立(RRC connection re-establishment)和RRC連接重配置(RRC connection reconfiguration)，傳輸?shù)臑镮P/non-IP/SMS類型的用戶數(shù)據(jù)，NAS(Non-Access Stratum，非接入層)層可選的IP數(shù)據(jù)ROHC功能，新增DoNAS(data over NAS)功能。

同時(shí)，UP解決方案與LTE的主要區(qū)別還包括：最多支持2個(gè)DRB(第1個(gè)默認(rèn)，第2個(gè)可選)，新增RRC/NAS掛起和恢復(fù)過程。

在NB-IoT協(xié)議一致性測試系統(tǒng)框架中，TTCN-3代碼運(yùn)行于主計(jì)算機(jī)Host-PC上，控制系統(tǒng)模擬器SS的行為。對于RRC層協(xié)議一致性測試，TTCN模擬了SS RRC層和網(wǎng)絡(luò)側(cè)行為，SS側(cè)使用正常功能的底層。對于MAC/RLC/PDCP層協(xié)議一致性測試，激活啟用UE Loop back數(shù)據(jù)回環(huán)模式將收到的data發(fā)回網(wǎng)絡(luò)，TTCN-3代碼模擬被測試層的部分功能，并將SS配置為特定的模式。

圖2A是本發(fā)明實(shí)施例的第一測試回環(huán)模式的協(xié)議模型示意圖。如圖2A所示，在第一測試回環(huán)模式下，在NAS層為Control Plane CIoT EPS optimizations提供用戶數(shù)據(jù)回環(huán)，對于每個(gè)用戶數(shù)據(jù)，當(dāng)待測試終端UE收到下行用戶數(shù)據(jù)時(shí)通過NAS消息上將其返回，且不考察數(shù)據(jù)內(nèi)容及EPS(Evolved Packet System，演進(jìn)分組系統(tǒng))相關(guān)的TFT(Traffic Flow Template，業(yè)務(wù)流模板)內(nèi)容。如圖2A所示，待測試終端UE包括PHY層(L1)、MAC層(L2)、RLC層(L2)以及RRC層(L3)。PHY層通過空中接口與系統(tǒng)模擬器SS通信，從下行信道接收信息，并通過上行信道發(fā)送。NAS層通過接口與RRC層連接，在測試控制的控制下通過測試信令消息激活回環(huán)操作。也就是說，在第一測試回環(huán)模式下，所述待測試終端在非接入層(NAS)對于接收到的下行用戶數(shù)據(jù)不處理數(shù)據(jù)內(nèi)容直接通過非接入層(NAS)消息返回。

圖2B是本發(fā)明實(shí)施例的第二測試回環(huán)模式的協(xié)議模型示意圖。如圖2B所示，在第二測試回環(huán)模式下，雙向DRB提供PDCP SDU回環(huán)，對于每個(gè)雙向DRB當(dāng)UE收到下行PDCP層SDU(Service Data Unit，服務(wù)數(shù)據(jù)單元)時(shí)在同一無線承載(Radio，RB)上將其返回且不考察PDCP層SDU內(nèi)容及EPS(Evolved Packet System，演進(jìn)分組系統(tǒng))相關(guān)的TFT(Traffic Flow Template，業(yè)務(wù)流模板)內(nèi)容。也就是說，在第二測試回環(huán)模式下，所述待測試終端通過雙向數(shù)據(jù)無線承載(DRB)在分組數(shù)據(jù)匯聚協(xié)議(PDCP)層對于接收到的下行用戶數(shù)據(jù)不處理數(shù)據(jù)內(nèi)容將PDCP層PDU回環(huán)。

由此，可以根據(jù)所要測試的功能屬于CP解決方案還是由UP解決方案獨(dú)有選擇設(shè)置對應(yīng)的測試回環(huán)模式。

圖3A是本發(fā)明實(shí)施例的MAC層測試流程的模型示意圖。

如圖3A所示，該測試流程適用于在CP解決方案下的NB-IoT終端的MAC層測試。

如圖3A所示，為了測試待測試終端UE的MAC層協(xié)議一致性，需要將其設(shè)置為第一測試回環(huán)模式，對NAS層的數(shù)據(jù)進(jìn)行回環(huán)，僅存在SRB傳輸。同時(shí)，需要使用空加密算法，并且不使用ROHC。

在系統(tǒng)模擬器SS側(cè)，PHY層配置為標(biāo)準(zhǔn)配置，MAC層配置除以下特殊模式其他功能正常。也即，MAC層的SRB1bis端口在下行方向不添加和/或者在上行方向不移除MAC層頭字段(headers)，由主計(jì)算機(jī)Host-PC提供最終的包含填充塊(padding)的PDU。SRB1bis端口的RLC層設(shè)置為透明模式(TM，Transparent Mode)，即RLC PDU就是RLC SDU。TTCN與SS的接口位于RLC層。

其中MAC層頭字段添加/刪除配置分為兩種不同模式：

第一種是下行/上行頭字段透明模式(DL/UL header-transparent mode)。在該模式下，在下行方向不添加頭字段，同時(shí)在上行方向不移除header。

第二種是僅下行頭字段透明模式(DL only header-transparent mode)。在該模式下，僅在下行方向不添加頭字段，MAC層在上行方向?yàn)檎ＤＪ剑簇?fù)責(zé)移除頭字段并且按照邏輯信道Id分發(fā)MAC層SDU。

如果系統(tǒng)模擬器SS配置為第一種模式，主計(jì)算機(jī)Host-PC和系統(tǒng)模擬器SS之間最終交換的是MAC層PDU。它包括了MAC、RLC層頭字段以及已編碼的RRC消息。其中RRC消息按照ASN.1(Abstract Syntax Notation Number One，抽象語法描述1)PER(Packed Encoding Rules，壓縮編碼規(guī)則)規(guī)則編解碼，并且攜帶了承載用戶數(shù)據(jù)的NAS消息。主計(jì)算機(jī)Host-PC搭載TTCN代碼來負(fù)責(zé)組建/處理DL/UL方向的MAC層和RLC層頭字段，維護(hù)RLC的SN(Sequence Number，序列號)和狀態(tài)變量，調(diào)用RRC和NAS編解碼器對上層消息進(jìn)行組建和解析。

如果系統(tǒng)模擬器SS配置為第二種模式，則在下行方向上，搭載TTCN代碼的主計(jì)算機(jī)Host-PC最終在SRB1bis端口發(fā)送的是MAC層PDU，它包括了MAC、RLC頭字段以及已編碼的RRC消息。在上行方向，主計(jì)算機(jī)Host-PC和系統(tǒng)模擬器SS之間最終交換的是RLC層PDU。它包括了RLC層頭字段以及已編碼的RRC消息。系統(tǒng)模擬器SS將根據(jù)邏輯信道Id路由這些PDU。其中RRC消息按照ASN.1PER規(guī)則編解碼，并且攜帶了承載用戶數(shù)據(jù)的NAS消息。搭載TTCN代碼的主計(jì)算機(jī)Host-PC負(fù)責(zé)組建下行方向的MAC、RLC層頭字段，維護(hù)RLC層的SN(Sequence Number，序列號)和狀態(tài)變量，調(diào)用RRC和NAS編解碼器對上層消息進(jìn)行組建和解析。

主計(jì)算機(jī)Host-PC通過系統(tǒng)控制端口為待檢測終端和系統(tǒng)模擬器配置上行調(diào)度許可(UL Scheduling Grant)和下行調(diào)度分配(DL Scheduling assignments)。系統(tǒng)模擬器SS可通過系統(tǒng)指示端口上報(bào)RACH(Random Access Channel，隨機(jī)接入信道)前導(dǎo)碼。

圖3B是本發(fā)明實(shí)施例的MAC層測試流程的流程圖。如圖3B所示，該測試流程適用于在CP解決方案下的NB-IoT終端的MAC層測試。

如圖3B所示，對于MAC層的測試流程包括：

步驟S100、將待測試終端設(shè)置為第一測試回環(huán)模式，在第一測試回環(huán)模式下，所述待測試終端對于接收到的由無線資源控制層(RRC)承載的包裹于非接入層(NAS)消息中的下行用戶數(shù)據(jù)不處理數(shù)據(jù)內(nèi)容直接通過非接入(NAS)層消息返回；同時(shí)，將待測試終端NAS層設(shè)置為使用空加密算法，不使用健壯性頭壓縮(ROHC)；

步驟S200、主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器中的物理層設(shè)置為標(biāo)準(zhǔn)配置，SRB1bis端口的媒體接入層(MAC)設(shè)置為下行不添加媒體接入層包頭并且上行不去除媒體接入層包頭或者僅下行不添加媒體接入層包頭，將SRB1bis端口的無線鏈路控制層(RLC)設(shè)置為透明模式(TM)；

步驟S300、主計(jì)算機(jī)建立和分解上行和/或下行MAC和/或RLC層頭、控制RLC層序列號(SN，Sequence Number)和狀態(tài)變量，調(diào)用RRC和NAS編解碼器。通過向系統(tǒng)模擬器的SRB1bis下行RLC層端口下發(fā)攜帶了承載用戶數(shù)據(jù)NAS消息的MAC層協(xié)議數(shù)據(jù)單元(PDU)，并在SRB1bis上行端口接收MAC層PDU或RLC層PDU，根據(jù)接收到的所述PDU檢測所述待測試終端的媒體接入層協(xié)議一致性。

圖4A是本發(fā)明實(shí)施例的RLC層測試流程的模型示意圖。

如圖4A所示，該測試流程適用于在CP解決方案下的NB-IoT終端的RLC層AM模式的測試。

在該模型中，待測試終端被配置為第一測試回環(huán)模式。同時(shí)，使用空加密算法，不使用ROHC。

在系統(tǒng)模擬器SS側(cè)，PHY層和MAC層被配置為標(biāo)準(zhǔn)模式。RLC層被設(shè)置為透明模式(TM，Transparent Mode)，即RLC層PDU就是RLC層SDU。主計(jì)算機(jī)Host-PC與系統(tǒng)模擬器SS的接口位于RLC層。

由此，主計(jì)算機(jī)Host-PC和系統(tǒng)模擬器SS之間最終交換的是RLC層PDU，它包括RLC層頭字段以及已編碼的RRC消息。其中RRC消息按照ASN.1PER規(guī)則編解碼，并且攜帶了承載用戶數(shù)據(jù)的NAS消息。主計(jì)算機(jī)Host-PC基于TTCN代碼的指示負(fù)責(zé)組建/處理上行和或下行方向的RLC層頭字段，維護(hù)RLC層的SN和狀態(tài)變量。對于RLC AM模式，主計(jì)算機(jī)Host-PC將負(fù)責(zé)下行方向的輪詢poll生成和對收到的UL Poll的響應(yīng)。

主計(jì)算機(jī)Host-PC通過系統(tǒng)控制端口為待檢測終端和系統(tǒng)模擬器配置上行調(diào)度許可(UL Scheduling Grant)和下行調(diào)度分配(DL Scheduling assignments)。

圖4B是本發(fā)明實(shí)施例的RLC層測試流程的流程圖。

如圖4B所示，對于RLC層的測試流程包括：

步驟S100’、將待測試終端設(shè)置為第一測試回環(huán)模式；同時(shí)，將待測試終端NAS層設(shè)置為使用空加密算法，不使用健壯性頭壓縮(ROHC)；

步驟S200’、主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器的物理層和媒體接入層設(shè)置為標(biāo)準(zhǔn)配置，將無線鏈路控制層設(shè)置為透明模式；

步驟S300’、計(jì)算機(jī)建立和分解上行和下行RLC層頭、控制RLC層SN和狀態(tài)變量，調(diào)用RRC和NAS編解碼器。通過向系統(tǒng)模擬器的SRB1bis下行RLC層端口發(fā)送攜帶了承載用戶數(shù)據(jù)NAS消息的RLC層PDU，并在SRB1bis上行端口接收RLC層PDU，根據(jù)接收到的所述RLC層PDU檢測所述待測試終端的無線鏈路控制層協(xié)議一致性。

圖5A是本發(fā)明實(shí)施例的ROHC模式的PDCP層測試流程的模型示意圖。該模型適于對使用UP解決方案的NB-IoT終端的ROHC模式的PDCP層進(jìn)行測試。其中，在待測試終端UE被配置為第二測試回環(huán)模式，將PDCP層以上的用戶域數(shù)據(jù)進(jìn)行回環(huán)。同時(shí)，使用加密和ROHC。

在系統(tǒng)模擬器SS側(cè)，PHY層、MAC層、RLC層設(shè)為標(biāo)準(zhǔn)模式，完成完整協(xié)議棧功能。同時(shí)，默認(rèn)情況下僅設(shè)置1個(gè)DRB，最多可以配置2個(gè)DRB。主計(jì)算機(jī)Host-PC與系統(tǒng)模擬器SS的接口位于PDCP層。

同時(shí)，系統(tǒng)模擬器SS的PDCP層配置為特殊模式，不進(jìn)行頭處理。同時(shí)，在下行和上行進(jìn)行雙向加密。只對下行方向配置ROHC，由上行接收ROHC反饋信息。同時(shí)，可以獨(dú)立地配置下行或上行方向“不進(jìn)行頭處理(no header manipulation)”。在本測試模式下，系統(tǒng)模擬器SS在下行方向不添加PDCP層頭，在上行方向不移除PDCP層頭。系統(tǒng)模擬器SS負(fù)責(zé)維護(hù)PDCP層的狀態(tài)變量。可以使用控制原語讀取或設(shè)置PDCP內(nèi)部狀態(tài)變量。

主計(jì)算機(jī)Host-PC通過系統(tǒng)控制端口為待檢測終端和系統(tǒng)模擬器配置上行調(diào)度許可(UL Scheduling Grant)和下行調(diào)度分配(DL Scheduling assignments)。

圖5B是本發(fā)明實(shí)施例的ROHC模式的PDCP層測試流程的模型示意圖。

如圖5B所示，ROHC模式的PDCP層測試流程包括：

步驟S400、將待測試終端設(shè)置為第二測試回環(huán)模式，在第二測試回環(huán)模式下，所述待測試終端通過雙向數(shù)據(jù)無線承載(DRB)對于接收到的分組數(shù)據(jù)匯聚協(xié)議(PDCP)層下行用戶數(shù)據(jù)不處理數(shù)據(jù)內(nèi)容將PDCP層PDU回環(huán)；同時(shí)，將待測試終端設(shè)置為使用加密和ROHC；

步驟S500、主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器的物理層、媒體接入層和無線鏈路控制層設(shè)置為標(biāo)準(zhǔn)模式，將PDCP層配置為在上行方向和/或下行方向不進(jìn)行頭處理，只對下行方向配置ROHC，由上行接收ROHC的反饋消息；

步驟S600、主計(jì)算機(jī)控制PDCP層SN和狀態(tài)變量，通過DRB下行端口向系統(tǒng)模擬器的PDCP層下發(fā)PDCP層PDU，并在DRB上行端口接收PDCP層PDU，根據(jù)接收到的所述PDU檢測所述待測試終端的具有ROHC模式的PDCP層的協(xié)議一致性。

圖6A是本發(fā)明實(shí)施例的非ROHC模式的PDCP層測試流程的模型示意圖。該模型用于NB-IoT終端在UP解決方案下的非ROCH模式的額PDCP層測試。待測試終端UE采用UP解決方案，并被設(shè)置為第二測試回環(huán)模式，將PDCP層以上的用戶域數(shù)據(jù)進(jìn)行回環(huán)。同時(shí)，使用加密但不使用ROHC。

在系統(tǒng)模擬器SS側(cè)，PHY層、MAC層和RLC層被設(shè)為標(biāo)準(zhǔn)模式，完成完整協(xié)議棧功能。同時(shí)，默認(rèn)情況下僅設(shè)置1個(gè)DRB，最多可以配置2個(gè)DRB。主計(jì)算機(jī)Host-PC與系統(tǒng)模擬器SS的接口位于PDCP層。

同時(shí)，PDCP層被配置為透傳模式(TM，Transparent Mode)。系統(tǒng)模擬器SS在下行方向不添加PDCP層頭，并在上行方向不移除PDCP層頭。主計(jì)算機(jī)Host-PC負(fù)責(zé)維護(hù)PDCP層的SN和狀態(tài)變量，使用模擬的加密算法完成雙向AS加密功能。主計(jì)算機(jī)Host-PC為加密和解密留出外部函數(shù)接口。PDCP層不配置ROHC。

主計(jì)算機(jī)Host-PC通過系統(tǒng)控制端口為待檢測終端和系統(tǒng)模擬器配置上行調(diào)度許可(UL Scheduling Grant)和下行調(diào)度分配(DL Scheduling assignments)。

圖6B是本發(fā)明實(shí)施例的非ROHC模式的PDCP層測試流程的模型示意圖。

如圖6B所示，非ROHC模式的PDCP層測試流程包括：

步驟S700、將待測試終端設(shè)置為第二測試回環(huán)模式；同時(shí)，將待測試終端設(shè)置為使用加密但不使用健壯性頭壓縮(ROHC)；

步驟S800、將主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器的協(xié)議棧中的PHY層、MAC層和RLC控制層設(shè)置為標(biāo)準(zhǔn)模式，將PDCP層配置為透明模式使得PDCP層在下行方向不添加PDCP頭且在上行方向不移除PDCP頭；

步驟S900、主計(jì)算機(jī)控制PDCP層SN和狀態(tài)變量，通過DRB下行端口向系統(tǒng)模擬器的PDCP層下發(fā)PDCP層PDU，并在DRB上行端口接收PDCP層PDU，根據(jù)接收到的所述PDU檢測所述待測試終端的非ROHC模式的PDCP層的協(xié)議一致性。

圖7A是本發(fā)明實(shí)施例的對CP解決方案的RRC層測試流程的模型示意圖。在RRC層的測試流程中，采用CP解決方案的待測試終端UE被設(shè)置為正常模式。同時(shí)，待測試終端UE使用NAS加密和完整性保護(hù)，不使用ROHC。

在系統(tǒng)模擬器SS側(cè)，PHY層、MAC層和RLC層設(shè)為標(biāo)準(zhǔn)配置，完成完整協(xié)議棧功能。SRB0上下行端口位于RLC層。SRB1bis端口位于并行測試RRC層和NAS層的兩側(cè)。啟用NAS加密和完整性保護(hù)。

主計(jì)算機(jī)Host-PC搭載的TTCN代碼中的RRC/NAS模擬器為SRB1bis提供了NAS消息的加密和完整性保護(hù)的功能。UL方向SS將包含了安全保護(hù)和已編碼NAS層的RRC層消息上報(bào)到SRB1bis的RRC端口，下行方向在完成NAS消息的加密和完整性保護(hù)之后將承載了NAS消息的RRC消息通過SRB1bis的RRC端口發(fā)送給系統(tǒng)模擬器SS。

主計(jì)算機(jī)Host-PC通過系統(tǒng)控制端口為待檢測終端和系統(tǒng)模擬器配置上行調(diào)度許可(UL Scheduling Grant)和下行調(diào)度分配(DL Scheduling assignments)。

圖7B是本發(fā)明實(shí)施例的對CP解決方案的RRC層測試流程的流程圖。

如圖7B所示，RRC層測試流程包括：

步驟S1000、將待測試終端設(shè)置為正常模式；同時(shí)，將待測試終端設(shè)置為使用NAS加密和完整性保護(hù)，不使用ROHC；

步驟S1100、主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器的物理層、媒體接入層和無線鏈路控制層設(shè)置為標(biāo)準(zhǔn)模式，同時(shí)，啟用NAS加密和完整性保護(hù)；

步驟S1200、主計(jì)算機(jī)在下行方向完成待發(fā)送NAS消息的加密和完整性保護(hù)后通過SRB1bis端口下發(fā)承載/未承載NAS消息的RRC消息或通過SRB0下發(fā)RRC消息到系統(tǒng)模擬器的RRC層，同時(shí)，在上行方向上接收系統(tǒng)模擬器通過SRB1bis端口上報(bào)的包含安全保護(hù)和已編碼NAS消息的RRC消息和或通過SRB0端口上報(bào)的RRC消息，根據(jù)接收到的所述消息檢測所述待測試終端的RRC層的協(xié)議一致性。

圖8A是本發(fā)明實(shí)施例的對UP解決方案的RRC層測試流程的模型示意圖。在該模型中，采用UP解決方案的待測試終端UE被設(shè)置為正常模式。同時(shí)，待測試終端UE使用PDCP和NAS加密和完整性保護(hù)，不使用ROHC。

在系統(tǒng)模擬器SS側(cè)：PHY層、MAC層、RLC層和PDCP層設(shè)為標(biāo)準(zhǔn)模式，完成完整協(xié)議棧功能。SRB0上下行端口位于RLC層。SRB1端口位于并行測試成分RRC和NAS模塊的兩側(cè)。DRB接口位于PDCP層。啟用PDCP和NAS加密和完整性保護(hù)。

主計(jì)算機(jī)Host-PC搭載的TTCN代碼中的RRC/NAS模擬器為SRB1提供了NAS消息的加密和完整性保護(hù)的功能。在上行方向，系統(tǒng)模擬器SS將包含了安全保護(hù)和已編碼NAS的RRC消息上報(bào)到SRB1的RRC端口，下行方向在完成NAS消息的加密和完整性保護(hù)之后將承載了NAS消息的RRC消息通過SRB1的RRC端口發(fā)送給SS。

主計(jì)算機(jī)Host-PC通過系統(tǒng)控制端口為待檢測終端和系統(tǒng)模擬器配置上行調(diào)度許可(UL Scheduling Grant)和下行調(diào)度分配(DL Scheduling assignments)。

圖8B是本發(fā)明實(shí)施例的對UP解決方案的RRC層測試流程的流程圖。

如圖8B所示，RRC層測試流程包括：

步驟S1000’、將待測試終端設(shè)置為正常模式；同時(shí)，將待測試終端設(shè)置為使用PDCP和NAS加密和完整性保護(hù)，不使用ROHC；

步驟S1100’、主計(jì)算機(jī)下發(fā)指令將系統(tǒng)模擬器的PHY層、MAC層、RLC層和PDCP層設(shè)置為標(biāo)準(zhǔn)模式，同時(shí)，啟用PDCP和NAS加密和完整性保護(hù)；

步驟S1200’、主計(jì)算機(jī)在下行方向完成待發(fā)送NAS消息的加密和完整性保護(hù)后通過SRB1端口下發(fā)承載/未承載NAS消息的RRC消息或通過SRB0下發(fā)RRC消息到系統(tǒng)模擬器的RRC層，同時(shí)，在上行方向上通過SRB1和/或通過SRB0端口接收系統(tǒng)模擬器RRC層上報(bào)的消息，根據(jù)接收到的所述消息檢測所述待測試終端的RRC層的協(xié)議一致性。

由此，本發(fā)明提供了一種NB-IoT終端一致性測試模型設(shè)計(jì)，其可以作為NB-IoT終端一致性測試?yán)O(shè)計(jì)的基礎(chǔ)。

顯然，本領(lǐng)域技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計(jì)算裝置來實(shí)現(xiàn)，它們可以集中在單個(gè)計(jì)算裝置上，或者分布在多個(gè)計(jì)算裝置所組成的網(wǎng)絡(luò)上，可選地，他們可以用計(jì)算機(jī)裝置可執(zhí)行的程序代碼來實(shí)現(xiàn)，從而可以將它們存儲在存儲裝置中由計(jì)算裝置來執(zhí)行，或者將它們分別制作成各個(gè)集成電路模塊，或者將它們中的多個(gè)模塊或步驟制作成單個(gè)集成電路模塊來實(shí)現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件的結(jié)合。本領(lǐng)域普通技術(shù)人員可以理解實(shí)現(xiàn)上述實(shí)施例方法中的全部或部分流程，是可以通過計(jì)算機(jī)程序來指令相關(guān)的硬件完成，所述的程序可存儲于一計(jì)算機(jī)可讀取介質(zhì)中，該程序在執(zhí)行時(shí)，可包括如上所述各方法的實(shí)施例的流程。其中，所述的存儲介質(zhì)可為磁碟、光盤、只讀存儲記憶體(Read-Only Memory，ROM)或隨機(jī)存儲記憶體(Random Access Memory，RAM)等。

以上所述僅為本發(fā)明的優(yōu)選實(shí)施例，并不用于限制本發(fā)明，對于本領(lǐng)域技術(shù)人員而言，本發(fā)明可以有各種改動和變化。凡在本發(fā)明的精神和原理之內(nèi)所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。