LTE終端一致性測試TTCN—3代碼L2模塊設(shè)計(jì)

金毅敦　王晰　陳曉忠

【摘 要】

基于TTCN語言的測試方法已經(jīng)廣泛用于LTE終端一致性測試。主要介紹TD-LTE終端一致性測試中L2（層二）的測試模型設(shè)計(jì)和TTCN-3代碼ASP接口的應(yīng)用實(shí)現(xiàn)。

【關(guān)鍵詞】

TD-LTE 終端一致性測試 TTCN-3 L2模塊 測試接口設(shè)計(jì)

1 引言

LTE（Long Term Evolution，長期演進(jìn)）已在全球范圍內(nèi)得到迅速發(fā)展，據(jù)《TDIA產(chǎn)業(yè)和市場發(fā)展簡訊》數(shù)據(jù)顯示：2014年Q1期間，全球新增4個(gè)商用網(wǎng)絡(luò)，商業(yè)網(wǎng)總數(shù)達(dá)到33個(gè)（包括13張TDD+FDD雙模網(wǎng)絡(luò)，1張eRelay網(wǎng)絡(luò)）；全球在建TD-LTE網(wǎng)絡(luò)新增22個(gè)，總數(shù)達(dá)到83個(gè)；有28個(gè)運(yùn)營商明確將于2014年內(nèi)推出TD-LTE商用服務(wù)。全球已有15家芯片廠商成功開發(fā)超過40款TD-LTE樣片和商用芯片。全球有122家廠商推出了445款TD-LTE終端，比上季度增加了87款；已有38家廠商推出了132款TD-LTE智能手機(jī)。此外，共有113款TD-LTE終端取得中國工業(yè)和信息化部入網(wǎng)許可證書，包括74款手機(jī)終端和39款數(shù)據(jù)終端。

終端一致性測試是終端入網(wǎng)認(rèn)證的重要內(nèi)容，包括射頻一致性測試、RRM一致性測試和協(xié)議一致性測試，其主要目標(biāo)是通過完成一致性相關(guān)要求的測試，以保證不同廠家的終端在網(wǎng)絡(luò)內(nèi)的表現(xiàn)一致并能夠互聯(lián)互通。TD-LTE協(xié)議一致性測試TTCN-3代碼集由ETSI和TDIA合作開發(fā)，作為標(biāo)準(zhǔn)測試集發(fā)布在3GPP 36.523-3協(xié)議中，包括空閑態(tài)小區(qū)選擇與重選、MAC（媒體介入控制層）、RLC（無線鏈路控制層）、PDCP（分組數(shù)據(jù)匯聚層）、RRC（無線資源控制層）及NAS（非接入層）等各層測試內(nèi)容。

2 LTE終端一致性L2測試模型

在協(xié)議一致性測試系統(tǒng)框架中，TTCN-3代碼運(yùn)行于HostPC上，控制系統(tǒng)模擬器SS的行為。對RRC和NAS層的測試?yán)?，TTCN模擬了SS RRC層和網(wǎng)絡(luò)側(cè)行為，SS側(cè)使用物理層和L2（MAC/RLC/PDCP）的正常模式。對于L2協(xié)議的一致性測試來說，UE啟用Loop back數(shù)據(jù)回環(huán)模式將收到的data發(fā)送回網(wǎng)絡(luò)側(cè)，TTCN-3代碼模擬被測試層的部分功能，相應(yīng)地需要將SS配置為特定的功能，才能對終端的L2協(xié)議棧進(jìn)行完整測試。

UE的test loop功能在36.509中描述，分為test loop mode A、B、C共3種模式。

（1）UE test loop mode A為雙向DRB提供PDCP SDU回環(huán)，對于每個(gè)雙向DRB當(dāng)UE收到下行PDCP SDU時(shí)在同一RB上將其返回且不考察PDCP SDU內(nèi)容及EPS相關(guān)的TFT內(nèi)容。

（2）對于E-UTRA、UTRA、GSM/GPRS、CDMA2000的UE test loop mode B，UE為雙向EPS承載提供PDCP SDU（E-UTRA和UTRA）、SNDCP PDU（GSM/GPRS）、RLP PDU（CDMA2000）的回環(huán)。當(dāng)建立了多于一個(gè)PDN連接或激活多于一個(gè)主PDP上下文時(shí)不能使用test loop mode B。對于E-UTRA模式下所有雙向DRB，當(dāng)UE收到下行PDCP SDU時(shí)，將其返回到與該P(yáng)DCP SDU中攜帶的EPS上下文中的TFT TCP/UDP/IP協(xié)議信息相匹配的RB上。

（3）UE test loop mode C提供對已成功接收的MTCH上MBMS包的計(jì)算。

其中UE test loop mode A功能、E-UTRA模式下的UE test loop mode B功能對于所有E-UTRA UE來說都是必須支持的。UE test loop mode C功能對于支持E-MBMS的E-UTRA UE是必須的。

2.1 MAC層測試模型

MAC層測試模型如圖1所示。

UE：配置為Test Loop Mode，loop back PDCP層之上的用戶域數(shù)據(jù)。使用空Ciphering算法，不使用ROHC。

SS側(cè)：L1設(shè)為標(biāo)準(zhǔn)配置，MAC配置為下述的特殊模式，其他功能正常。DRB端口DL不添加和/或者UL不移除MAC headers，由TTCN提供最終的包含padding的PDU。DRB端口的RLC設(shè)置為透傳模式（transparent mode），即RLC PDU就是RLC SDU。SS不配置PDCP。對于DRB來說TTCN與SS的接口位于RLC層之上。

其中MAC header添加/刪除配置分為兩種不同模式：

（1）DL/UL header-transparent mode：DL不添加header、UL不移除header。

（2）DL only header-transparent mode：僅DL不添加header，UL方向MAC為正常模式，即負(fù)責(zé)移除header并且按照邏輯信道Id分發(fā)MAC SDU。

如果SS配置為第1種模式，TTCN和SS之間最終交換的DRB PDU是包括MAC、RLC、PDCP header的MAC PDU。TTCN代碼將負(fù)責(zé)組建/處理DL/UL方向的MAC、RLC、PDCP header，維護(hù)RLC、PDCP層的sequence number和狀態(tài)變量。對于UE的多個(gè)DRB測試，SS側(cè)可能僅按照圖1所示配置了1個(gè)DRB，其他DRB不配置以便于路由UL TBS。TTCN負(fù)責(zé)完成不同的DRB PDU的復(fù)用和解復(fù)用。由于MAC層在UL方向不解析MAC header，UL方向的SRB和DRB將無法區(qū)分。因此當(dāng)MAC層配置為本測試模式的時(shí)候?qū)]有SRB傳輸。

如果SS配置為第2種模式，UL方向TTCN和SS之間最終交換的DRB PDU是包括RLC、PDCP header的RLC PDU。SS將根據(jù)邏輯信道Id路由這些PDU。DL方向TTCN最終在DRB端口發(fā)送的是編碼后的MAC PDU，包含MAC、RLC、PDCP header。TTCN負(fù)責(zé)維護(hù)RLC、PDCP層的sequence number和狀態(tài)變量。在本測試模式中SS在UL和DL方向MAC層可以處理SRB數(shù)據(jù)，也就是說可以處理來自SRB的DL RLC PDU和分發(fā)UL RLC PDU到SRB。此外，TTCN將確保在同一個(gè)TTI中正常模式下的DL MAC SDU和測試模式下的DL MAC PDU不同時(shí)出現(xiàn)。endprint

TTCN通過系統(tǒng)控制端口配置UL Scheduling Grant和DL Scheduling assignments。SS可通過系統(tǒng)指示端口上報(bào)PUCCH調(diào)度信息和RACH preamble。

2.2 RLC層測試模型

本測試模型適用于UE DRB的RLC層UM/AM mode的測試，如圖1所示。

UE：配置為Test Loop Mode，loop back PDCP層之上的用戶域數(shù)據(jù)。使用空Ciphering算法，不使用ROHC。

SS側(cè)：L1和MAC設(shè)為標(biāo)準(zhǔn)配置，RLC設(shè)置為透傳模式（transparent mode），即RLC PDU就是RLC SDU。SS不配置PDCP。對于DRB來說TTCN與SS的接口位于RLC層之上。

TTCN和SS之間最終交換的DRB PDU是包括RLC、PDCP header的RLC PDU。TTCN代碼將負(fù)責(zé)組建/處理DL/UL方向的RLC、PDCP header，維護(hù)RLC、PDCP層的sequence number和狀態(tài)變量。如果UE的RLC是AM mode，TTCN將負(fù)責(zé)DL方向的poll生成和對收到的UL Poll響應(yīng)。

TTCN通過系統(tǒng)控制端口配置UL Scheduling Grant和DL Scheduling assignments。

2.3 PDCP層測試模型

PDCP ROHC測試模型如圖2所示。

UE：配置為Test Loop Mode，loop back PDCP層之上的用戶域數(shù)據(jù)。使用加密和ROHC。

SS側(cè)：L1、MAC、RLC設(shè)為標(biāo)準(zhǔn)配置，完成完整協(xié)議棧功能。TTCN與SS的接口位于PDCP層之上。

PDCP配置為特殊模式，不進(jìn)行header處理。DL/UL雙向加密。只對DL方向配置ROHC，由ASP接收UL ROHC反饋信息。可以獨(dú)立地配置UL/DL方向“不進(jìn)行header處理（no header manipulation）”。在本測試模式下，SS在DL方向不添加PDCP header和UL方向不移除PDCP header。SS負(fù)責(zé)維護(hù)PDCP的狀態(tài)變量?？梢允褂每刂圃Z讀取或設(shè)置PDCP內(nèi)部狀態(tài)變量。

TTCN通過系統(tǒng)控制端口配置UL Scheduling Grant和DL Scheduling assignments。SS可通過系統(tǒng)指示端口上報(bào)PUCCH調(diào)度信息。

PDCP（Non ROHC）測試模型如圖3所示：

圖3 PDCP（Non ROHC）測試模型

UE：配置為Test Loop Mode，loop back PDCP層之上的用戶域數(shù)據(jù)。使用加密但不使用ROHC。

SS側(cè)：L1、MAC、RLC設(shè)為標(biāo)準(zhǔn)配置，完成完整協(xié)議棧功能。TTCN與SS的接口位于PDCP層之上。

PDCP配置為透傳模式（transparent mode）。SS在DL方向不添加PDCP header和UL方向不移除PDCP header。TTCN負(fù)責(zé)維護(hù)PDCP的sequence number和狀態(tài)變量，使用模擬的加密算法完成雙向AS加密功能。TTCN為加密和解密留出外部函數(shù)接口。PDCP不配置ROHC。

TTCN通過系統(tǒng)控制端口配置UL Scheduling Grant和DL Scheduling assignments。SS可通過系統(tǒng)指示端口上報(bào)PUCCH調(diào)度信息。

3 LTE終端一致性TTCN-3 L2測試接口設(shè)計(jì)

按照3GPP對EUTRAN ASP設(shè)計(jì)，定義了如下測試端口，以下描述的發(fā)送與接收都是以TTCN或者EUTRA_PTC為參照的。

（1）SYS：EUTRAN配置端口，負(fù)責(zé)配置SS EUTEAN的PHY、MAC、RLC、PDCP層參數(shù)，控制系統(tǒng)消息的生成、小區(qū)功率的修改、L2特殊測試模式的設(shè)置、小區(qū)的建立刪除等，并根據(jù)TTCN或者測試需要，返回配置成功的確認(rèn)信息。SYS端口定義了兩個(gè)消息：SYSTEM_CTRL_REQ用于發(fā)送配置信息，SYSTEM_CTRL_CNF用于接收系統(tǒng)確認(rèn)。

（2）SYSIND：EUTRAN指示端口，負(fù)責(zé)上報(bào)SS的PHY、MAC、RLC等協(xié)議層的特定的指示響應(yīng)。SYSIND端口定義了一個(gè)SYSTEM_IND消息用于接收。

（3）SRB：EUTRAN信令無線承載端口，用于無線承載SRB0/1/2上的RRC消息的發(fā)送和接收。SRB端口定義了兩個(gè)消息：SRB_COMMON_REQ用于控制SS發(fā)送DL RRC消息，SRB_COMMON_IND用于接收UL RRC消息。

（4）DRB：EUTRAN數(shù)據(jù)無線承載端口，用于控制DRB端口上數(shù)據(jù)的發(fā)送和接收，數(shù)據(jù)種類包括MAC PDU、RLC PDU、RLC SDU、PDCP PDU、PDCP SDU。DRB端口定義了兩個(gè)消息：DRB_COMMON_REQ用于發(fā)送DRB數(shù)據(jù)，DRB_COMMON_IND用于接收DRB數(shù)據(jù)。

（5）NASCTRL：EUTRAN非接入層控制端口，用于請求NAS安全和NAS COUNT信息，端口定了兩個(gè)消息：NAS_CTRL_REQ用于發(fā)送請求，NAS_CTRL_CNF用于接收反饋確認(rèn)。

與第2部分介紹的L2測試模型的配置直接相關(guān)的端口有SYS、SYSIND、DRB，下面將詳細(xì)介紹。

SYS端口上的配置消息SYSTEM_CTRL_REQ中的配置內(nèi)容如下：

type union SystemRequest_Type {

CellConfigRequest_Type Cell，

CellAttenuationList_Type CellAttenuationList，endprint

RadioBearerList_Type RadioBearerList，

Null_Type EnquireTiming，

AS_Security_Type AS_Security，

SpsConfig_Type Sps，

PagingTrigger_Type Paging，

L1Mac_IndicationControl_Type L1MacIndCtrl，

Rlc_IndicationControl_Type RlcIndCtrl，

PDCP_CountReq_Type PdcpCount，

PDCP_HandoverControlReq_Type PdcpHandoverControl，

L1_TestMode_Type L1_TestMode，

RA_PDCCH_Order_Type PdcchOrder，

ActivateScell_Type ActivateScell，

MBMS_Config_Type MbmsConfig，

PDCCH_MCCH_ChangeNotification_Type

PDCCH_MCCH_ChangeNotification，

MSI_Config_Type MSI_Config

}；

其中RadioBearerList配置和釋放SRB和DRB；L1MacIndCtrl配置SS建立一個(gè)L1/MAC事件的指示信息，控制SS將底層事件RachPreamble/SchedReq/BSR/UL_HARQ/C_RNTI/PHR/HarqError/PeriodicRI/EPHR/PeriodicCQI上報(bào)給TTCN；RlcIndCtrl配置SS建立一個(gè)RLC事件的指示信息；L1_TestMode配置DL CRC和PHICH測試相關(guān)的L1/MAC參數(shù)；PdcchOrder配置SS傳輸一個(gè)PDCCH order給UE來觸發(fā)RA過程。對于L2測試模型的配置，主要集中在RadioBearerList中對各DRB的L2各層的配置接口設(shè)計(jì)上，3.1-3.3各小節(jié)將展開說明。

SYSIND端口上SYSTEM_IND接收SS L1/L2的指示響應(yīng)。

type union SystemIndication_Type {

charstring Error，

RachPreamble_Type RachPreamble，

Null_Type SchedReq，

BSR_Type BSR，

HARQ_Type UL_HARQ，

C_RNTI C_RNTI，

PHR_Type PHR，

HarqError_Type HarqError，

RlcDiscardInd_Type RlcDiscardInd，

RI_Type PeriodicRI，

MAC_CTRL_ExtPowerHeadRoom_Type EPHR，

Null_Type CqiInd

}；

其中Error上報(bào)SS錯(cuò)誤指示，會(huì)導(dǎo)致測試判決為INCONC；RachPreamble上報(bào)UE使用的RACH preamble信息內(nèi)容；SchedReq上報(bào)UE是否進(jìn)行調(diào)度請求；BSR上報(bào)UE發(fā)送的Short/Truncated/Long BSR內(nèi)容；UL_HARQ上報(bào)某下行傳輸對應(yīng)的UL HARQ確認(rèn)ACK/NACK；C_RNTI上報(bào)UE發(fā)送MAC PDU內(nèi)包含的CRNTI；PHR上報(bào)已收到的PHR；HarqError上報(bào)SS側(cè)發(fā)現(xiàn)的UL傳輸HARQ錯(cuò)誤和UE側(cè)的DL傳輸HARQ NACK；RlcDiscardInd上報(bào)被SS丟棄的RLC層的PDU的SN；PeriodicRI上報(bào)UE periodic RI；EPHR上報(bào)UE Extended PHR；CqiInd上報(bào)UE periodic CQI。一般來說，首先TTCN通過SYS端口的L1MacIndCtrl（包括RachPreamble、SchedReq、BSR、UL_HARQ、C_RNTI、PHR、HarqError、PeriodicRI、EPHR、PeriodicCQI）、RlcIndCtrl配置SS激活上報(bào)功能，SS才會(huì)在層1、層2上將檢測到的相應(yīng)指示信息通過SYSIND端口上報(bào)給TTCN。

由于TTCN對SS的配置模式和測試內(nèi)容的差異，相應(yīng)地DRB端口上通過DRB_COMMON_REQ和DRB_COMMON_IND發(fā)送和接收到的數(shù)據(jù)類型有所不同，如MAC、RLC、PDCP的PDU或SDU數(shù)據(jù)。其中MacPdu、RlcPdu、PdcpPdu的TTCN接口定義包括了各層可能存在的PDU種類。對于MAC PDU，包括MAC header、MAC控制單元和MAC SDU；對于RLC PDU，包括RLC TMD、UMD、AMD PDU和RLC status PDU；對于PDCP PDU，包括PCDP Data PDU、PDCP Control PDU。其中PDU header中的各字段都單獨(dú)定義為一個(gè)元素，以方便TTCN發(fā)送時(shí)單獨(dú)配置和接收時(shí)單獨(dú)進(jìn)行匹配檢測。PdcpSdu、RlcSdu接口定義只有數(shù)據(jù)部分。用戶平面的數(shù)據(jù)類型與各層配置模型結(jié)合使用將在3.1-3.3小節(jié)詳細(xì)說明。

type union U_PlaneDataList_Type {

MAC_PDUList_Type MacPdu，

RLC_PDUList_Type RlcPdu，endprint

PDCP_PDUList_Type PdcpPdu，

PDCP_SDUList_Type PdcpSdu，

RLC_SDUList_Type RlcSdu

}；

3.1 MAC層測試模型的TTCN接口設(shè)計(jì)

當(dāng)MAC層使用標(biāo)準(zhǔn)配置時(shí)TestMode設(shè)置為None，配置成圖1模型時(shí)TTCN接口定義如下：

type record MAC_TestModeInfo_Type {

MAC_Test_DLLogChID_Type DiffLogChId，

MAC_Test_SCH_NoHeaderManipulation_Type

No_HeaderManipulation

}；

type union MAC_Test_DLLogChID_Type {

TestLogicalChannelId_Type LogChId，

Null_Type ConfigLchId

}；

type enumerated MAC_Test_SCH_NoHeader-

Manipulation_Type {

NormalMode，

DL_SCH_Only，

DL_UL_SCH

}；

配置分為兩個(gè)部分：1）DiffLogChId配置了MAC頭中LCID使用特定的LogChId值（范圍0～31）還是ConfigLchId狀態(tài)（使用SS MAC層正常配置）；2）頭處理操作HeaderManipulation使用正常模式、MAC測試模型2（DL_SCH_Only）或MAC測試模型1（DL_UL_SCH）。

MAC按照如上配置的同時(shí)，PDCP層不配置（PDCP_Configuration_None）。對于MAC測試模型1，RLC設(shè)置為透傳模式（TM），DRB端口上傳輸?shù)臄?shù)據(jù)為MacPdu；對于MAC測試模型2，RLC設(shè)置為透傳模式（TM）且指出是AM/UM模式及SN長度，DRB端口上DL數(shù)據(jù)為MacPdu，UL為RlcPdu。

對于MAC層的測試?yán)齺碚f，并不是所有的測試?yán)夹枰凑請D1測試模型對SS進(jìn)行配置。TTCN代碼會(huì)根據(jù)測試?yán)木唧w測試內(nèi)容配置SS的底層功能，如隨機(jī)接入過程中對RAResponse和ContentionResolutionCtrl的控制、HARQ過程中對ACK/NACK的控制、對上行數(shù)據(jù)UL GRANT的控制等等。通常測試?yán)枰Y(jié)合使用MAC測試模型、SYS端口上SYSTEM_CTRL_REQ消息中的相關(guān)配置、SYSIND端口上SS接收層1/層2的指示信息，對UE的MAC層的隨機(jī)接入過程、HARQ過程、調(diào)度請求、狀態(tài)緩存報(bào)告、非連續(xù)接收、跳頻、傳輸塊選擇等功能進(jìn)行測試。TTCN DRB端口完整定義了MAC PDU可能出現(xiàn)的所有字段，包括SubHeader、CtrlElementList、SduList和Padding。若一個(gè)MAC PDU中有不存在字段時(shí)該字段設(shè)置為omit。

type record MAC_PDU_Type {

MAC_Header_Type Header，

MAC_CTRL_ElementList_Type CtrlElementList optional，

MAC_SDUList_Type SduList optional，

Octetstring Padding optional

}；

其中MAC Header包含CtrlElement、Sdu、Padding的SubHeader（如果存在）；CtrlElementList（如果存在）包含Short/Long BSR、C_RNTI、ContentionResolutionID、TimingAdvance、PowerHeadRoom等中的一項(xiàng)或幾項(xiàng)；SduList（如果存在）包含一個(gè)或多個(gè)MAC SDU；Padding（如果存在）是隨機(jī)生成的比特串。在測試模型1中，TTCN代替MAC層在下行方向組建MAC PDU，如包含哪些MAC控制單元和SDU、是否存在padding、各MAC SubHeader如何添加；上行方向TTCN檢查UE返回的MAC PDU中的內(nèi)容是否正確。對在測試模型2中，下行方向與模型1相同，上行方向TTCN檢查UE返回的RLC PDU是否正確，RlcPdu的定義見3.2節(jié)。

3.2 RLC層測試模型的TTCN接口設(shè)計(jì)

當(dāng)RLC層使用標(biāo)準(zhǔn)配置時(shí)TestMode設(shè)置為None，配置成圖1模型時(shí)TTCN接口定義如下：

type union RLC_TestModeInfo_Type {

RLC_ACK_Prohibit_Type AckProhibit，

RLC_NotACK_NextRLC_PDU_Type

NotACK_NextRLC_PDU，

RLC_AM_SequenceNumber_Type ModifyVTS，

Null_Type TransparentMode_UMDwith5BitSN，

Null_Type TransparentMode_UMDwith10BitSN，

Null_Type TransparentMode_AMD

}；

配置接口分為6部分內(nèi)容任選其一，其中前3個(gè)是對RLC層測試的輔助配置，如AckProhibit配置SS在AM模式下不發(fā)送/發(fā)送ACK給UE確認(rèn)UL傳輸，NotACK_NextRLC_PDU配置SS在AM模式下對下一個(gè)收到的UL RLC PDU不發(fā)送ACK給UE，ModifyVTS修改SS側(cè)的VT（S）變量值；后3個(gè)是按照圖1設(shè)置SS RLC為SN長度5或10bit的UM透傳模式或AM透傳模式（SN長度10bit）。endprint

RLC按照如上配置的同時(shí)，PDCP層不配置（PDCP_Configuration_None），MAC使用正常配置。此時(shí)，DRB端口上傳輸?shù)臄?shù)據(jù)為RlcPdu。

對于RLC層的測試?yán)齺碚f，SS配置成測試模型，TTCN模擬RLC PDU的各種情況，對UE RLC層在UM或AM傳輸模式下對SDU的分段、重組、重排序以及AM模式下的錯(cuò)誤檢測、重分段功能進(jìn)行檢測。TTCN DRB端口定義了RLC PDU可能出現(xiàn)的所有種類，包括5bit/10bit SN UMD、AMD（AMD PDU和AMD PDU segment）、Status等。

type union RLC_PDU_Type {

RLC_TMD_PDU_Type TMD，

RLC_UMD_PDU_Type UMD，

RLC_AMD_PDU_Type AMD，

RLC_AM_StatusPDU_Type Status

}；

type union RLC_UMD_PDU_Type {

RLC_UMD_PDU_ShortSN_Type ShortSN，

RLC_UMD_PDU_LongSN_Type LongSN

}；

type record RLC_UMD_PDU_ShortSN_Type {

RLC_UMD_HeaderShortSN_Type Header，

RLC_DataFieldList_Type Data

}；

type record RLC_UMD_PDU_LongSN_Type {

RLC_UMD_HeaderLongSN_Type Header，

RLC_DataFieldList_Type Data

}；

type record RLC_AMD_PDU_Type {

RLC_AMD_Header_Type Header，

RLC_DataFieldList_Type Data

}；

type record RLC_AM_StatusPDU_Type {

B1_Type D_C，

B3_Type Type，

RLC_Status_ACK_Type Ack，

RLC_Status_NACK_List_Type NackList optional，

RLC_Status_Padding_Type Padding optional

}；

3.3 PDCP層測試模型的TTCN接口設(shè)計(jì)

當(dāng)PDCP層使用標(biāo)準(zhǔn)配置時(shí)TestMode設(shè)置為None，配置成圖2或圖3模型時(shí)TTCN接口定義如下：

type union PDCP_TestModeInfo_Type {

PDCP_ROHC_Mode_Type PDCP_ROHC_Mode，

PDCP_NonROHC_Mode_Type PDCP_NonROHC_Mode

}；

type record PDCP_ROHC_Mode_Type {

PDCP_SNLength_Type SN_Size

}；

type record PDCP_NonROHC_Mode_Type {

PDCP_SNLength_Type SN_Size

}；

可以選擇將SS配置成PDCP_ROHC_Mode（圖2）或者PDCP_NonROHC_Mode（圖3），且需要指出PDCP SN長度（PDCP_SNLength5/7/12）。

PDCP按照如上配置的同時(shí)，RLC/MAC都要正常配置。此時(shí)，若SS不處理PDCP header，DRB端口上傳輸?shù)臄?shù)據(jù)為PdcpPdu。

對于PDCP層的測試?yán)齺碚f，AS加密和完整性保護(hù)、UP加密測試可以使用SS本身的PDCP層功能；PDCP SN等其他測試需要SS配置成測試模型，TTCN完成PDCP SDU的加解密功能，模擬PDCP PDU對UE的PDCP層進(jìn)行測試。TTCN DRB端口定義了PDCP PDU可能出現(xiàn)的所有種類，包括LongSN Data PDU、ShortSN Data PDU、RohcFeedback、StatusReport等。

type union PDCP_PDU_Type {

PDCP_DataPdu_LongSN_Type DataLongSN，

PDCP_DataPdu_ShortSN_Type DataShortSN，

PDCP_DataPdu_ExtSN_Type DataExtSN，

PDCP_Ctrl_ROHC_FB_PDU_Type RohcFeedback，

PDCP_Ctrl_StatusReport_Type StatusReport，

PDCP_Ctrl_StatusReportExt_Type StatusReportExt

}；

4 結(jié)束語

TD-LTE終端協(xié)議一致性測試內(nèi)容覆蓋各層協(xié)議過程的理解與實(shí)現(xiàn)，使得TTCN對SS的設(shè)置非常細(xì)致。在L2測試SS的開發(fā)過程或者與UE聯(lián)調(diào)過程中，都要求研發(fā)測試人員對L2測試模型和相關(guān)TTCN的接口定義的含義有明確理解。對于L2測試?yán)齺碚f，TTCN要求SS的可控性非常高，SS不能僅限于支持TD-LTE各層的完整協(xié)議棧，還要按照TTCN的要求，在完整協(xié)議棧實(shí)現(xiàn)的基礎(chǔ)上留出相應(yīng)的測試接口，以便靈活的控制測試流程，才能更好的檢驗(yàn)UE協(xié)議的完整性和一致性。

參考文獻(xiàn)：

[1] 3GPP TS 36.523-1 V12.0.0. Evolved Universal Terrestrial Radio Access （E-UTRA） and Evolved Packet Core （EPC）； User Equipment （UE） conformance specification； Part 1： Protocol conformance specification[S]. 2013.

[2] 3GPP TS 36.523-3 V11.2.0. Evolved Universal Terrestrial Radio Access （E-UTRA） and Evolved Packet Core （EPC）； User Equipment （UE） conformance specification； Part 3： Test Suites[S]. 2013.

[3] 3GPP TS 36.509 V10.1.0. Evolved Universal Terrestrial Radio Access （E-UTRA） and Evolved Packet Core （EPC）； Special conformance testing functions for User Equipment （UE）[S]. 2013.

[4] TD產(chǎn)業(yè)聯(lián)盟. TDIA產(chǎn)業(yè)和市場發(fā)展簡訊[EB/OL]. （2014-03-30）. http：//www.tdia.cn/Downloads/PDF/2014Q1.pdf.endprint

RLC按照如上配置的同時(shí)，PDCP層不配置（PDCP_Configuration_None），MAC使用正常配置。此時(shí)，DRB端口上傳輸?shù)臄?shù)據(jù)為RlcPdu。

對于RLC層的測試?yán)齺碚f，SS配置成測試模型，TTCN模擬RLC PDU的各種情況，對UE RLC層在UM或AM傳輸模式下對SDU的分段、重組、重排序以及AM模式下的錯(cuò)誤檢測、重分段功能進(jìn)行檢測。TTCN DRB端口定義了RLC PDU可能出現(xiàn)的所有種類，包括5bit/10bit SN UMD、AMD（AMD PDU和AMD PDU segment）、Status等。

type union RLC_PDU_Type {

RLC_TMD_PDU_Type TMD，

RLC_UMD_PDU_Type UMD，

RLC_AMD_PDU_Type AMD，

RLC_AM_StatusPDU_Type Status

}；

type union RLC_UMD_PDU_Type {

RLC_UMD_PDU_ShortSN_Type ShortSN，

RLC_UMD_PDU_LongSN_Type LongSN

}；

type record RLC_UMD_PDU_ShortSN_Type {

RLC_UMD_HeaderShortSN_Type Header，

RLC_DataFieldList_Type Data

}；

type record RLC_UMD_PDU_LongSN_Type {

RLC_UMD_HeaderLongSN_Type Header，

RLC_DataFieldList_Type Data

}；

type record RLC_AMD_PDU_Type {

RLC_AMD_Header_Type Header，

RLC_DataFieldList_Type Data

}；

type record RLC_AM_StatusPDU_Type {

B1_Type D_C，

B3_Type Type，

RLC_Status_ACK_Type Ack，

RLC_Status_NACK_List_Type NackList optional，

RLC_Status_Padding_Type Padding optional

}；

3.3 PDCP層測試模型的TTCN接口設(shè)計(jì)

當(dāng)PDCP層使用標(biāo)準(zhǔn)配置時(shí)TestMode設(shè)置為None，配置成圖2或圖3模型時(shí)TTCN接口定義如下：

type union PDCP_TestModeInfo_Type {

PDCP_ROHC_Mode_Type PDCP_ROHC_Mode，

PDCP_NonROHC_Mode_Type PDCP_NonROHC_Mode

}；

type record PDCP_ROHC_Mode_Type {

PDCP_SNLength_Type SN_Size

}；

type record PDCP_NonROHC_Mode_Type {

PDCP_SNLength_Type SN_Size

}；

可以選擇將SS配置成PDCP_ROHC_Mode（圖2）或者PDCP_NonROHC_Mode（圖3），且需要指出PDCP SN長度（PDCP_SNLength5/7/12）。

PDCP按照如上配置的同時(shí)，RLC/MAC都要正常配置。此時(shí)，若SS不處理PDCP header，DRB端口上傳輸?shù)臄?shù)據(jù)為PdcpPdu。

對于PDCP層的測試?yán)齺碚f，AS加密和完整性保護(hù)、UP加密測試可以使用SS本身的PDCP層功能；PDCP SN等其他測試需要SS配置成測試模型，TTCN完成PDCP SDU的加解密功能，模擬PDCP PDU對UE的PDCP層進(jìn)行測試。TTCN DRB端口定義了PDCP PDU可能出現(xiàn)的所有種類，包括LongSN Data PDU、ShortSN Data PDU、RohcFeedback、StatusReport等。

type union PDCP_PDU_Type {

PDCP_DataPdu_LongSN_Type DataLongSN，

PDCP_DataPdu_ShortSN_Type DataShortSN，

PDCP_DataPdu_ExtSN_Type DataExtSN，

PDCP_Ctrl_ROHC_FB_PDU_Type RohcFeedback，

PDCP_Ctrl_StatusReport_Type StatusReport，

PDCP_Ctrl_StatusReportExt_Type StatusReportExt

}；

4 結(jié)束語

TD-LTE終端協(xié)議一致性測試內(nèi)容覆蓋各層協(xié)議過程的理解與實(shí)現(xiàn)，使得TTCN對SS的設(shè)置非常細(xì)致。在L2測試SS的開發(fā)過程或者與UE聯(lián)調(diào)過程中，都要求研發(fā)測試人員對L2測試模型和相關(guān)TTCN的接口定義的含義有明確理解。對于L2測試?yán)齺碚f，TTCN要求SS的可控性非常高，SS不能僅限于支持TD-LTE各層的完整協(xié)議棧，還要按照TTCN的要求，在完整協(xié)議棧實(shí)現(xiàn)的基礎(chǔ)上留出相應(yīng)的測試接口，以便靈活的控制測試流程，才能更好的檢驗(yàn)UE協(xié)議的完整性和一致性。

參考文獻(xiàn)：

[1] 3GPP TS 36.523-1 V12.0.0. Evolved Universal Terrestrial Radio Access （E-UTRA） and Evolved Packet Core （EPC）； User Equipment （UE） conformance specification； Part 1： Protocol conformance specification[S]. 2013.

[2] 3GPP TS 36.523-3 V11.2.0. Evolved Universal Terrestrial Radio Access （E-UTRA） and Evolved Packet Core （EPC）； User Equipment （UE） conformance specification； Part 3： Test Suites[S]. 2013.

[3] 3GPP TS 36.509 V10.1.0. Evolved Universal Terrestrial Radio Access （E-UTRA） and Evolved Packet Core （EPC）； Special conformance testing functions for User Equipment （UE）[S]. 2013.

[4] TD產(chǎn)業(yè)聯(lián)盟. TDIA產(chǎn)業(yè)和市場發(fā)展簡訊[EB/OL]. （2014-03-30）. http：//www.tdia.cn/Downloads/PDF/2014Q1.pdf.endprint

RLC按照如上配置的同時(shí)，PDCP層不配置（PDCP_Configuration_None），MAC使用正常配置。此時(shí)，DRB端口上傳輸?shù)臄?shù)據(jù)為RlcPdu。

對于RLC層的測試?yán)齺碚f，SS配置成測試模型，TTCN模擬RLC PDU的各種情況，對UE RLC層在UM或AM傳輸模式下對SDU的分段、重組、重排序以及AM模式下的錯(cuò)誤檢測、重分段功能進(jìn)行檢測。TTCN DRB端口定義了RLC PDU可能出現(xiàn)的所有種類，包括5bit/10bit SN UMD、AMD（AMD PDU和AMD PDU segment）、Status等。

type union RLC_PDU_Type {

RLC_TMD_PDU_Type TMD，

RLC_UMD_PDU_Type UMD，

RLC_AMD_PDU_Type AMD，

RLC_AM_StatusPDU_Type Status

}；

type union RLC_UMD_PDU_Type {

RLC_UMD_PDU_ShortSN_Type ShortSN，

RLC_UMD_PDU_LongSN_Type LongSN

}；

type record RLC_UMD_PDU_ShortSN_Type {

RLC_UMD_HeaderShortSN_Type Header，

RLC_DataFieldList_Type Data

}；

type record RLC_UMD_PDU_LongSN_Type {

RLC_UMD_HeaderLongSN_Type Header，

RLC_DataFieldList_Type Data

}；

type record RLC_AMD_PDU_Type {

RLC_AMD_Header_Type Header，

RLC_DataFieldList_Type Data

}；

type record RLC_AM_StatusPDU_Type {

B1_Type D_C，

B3_Type Type，

RLC_Status_ACK_Type Ack，

RLC_Status_NACK_List_Type NackList optional，

RLC_Status_Padding_Type Padding optional

}；

3.3 PDCP層測試模型的TTCN接口設(shè)計(jì)

當(dāng)PDCP層使用標(biāo)準(zhǔn)配置時(shí)TestMode設(shè)置為None，配置成圖2或圖3模型時(shí)TTCN接口定義如下：

type union PDCP_TestModeInfo_Type {

PDCP_ROHC_Mode_Type PDCP_ROHC_Mode，

PDCP_NonROHC_Mode_Type PDCP_NonROHC_Mode

}；

type record PDCP_ROHC_Mode_Type {

PDCP_SNLength_Type SN_Size

}；

type record PDCP_NonROHC_Mode_Type {

PDCP_SNLength_Type SN_Size

}；

可以選擇將SS配置成PDCP_ROHC_Mode（圖2）或者PDCP_NonROHC_Mode（圖3），且需要指出PDCP SN長度（PDCP_SNLength5/7/12）。

PDCP按照如上配置的同時(shí)，RLC/MAC都要正常配置。此時(shí)，若SS不處理PDCP header，DRB端口上傳輸?shù)臄?shù)據(jù)為PdcpPdu。

對于PDCP層的測試?yán)齺碚f，AS加密和完整性保護(hù)、UP加密測試可以使用SS本身的PDCP層功能；PDCP SN等其他測試需要SS配置成測試模型，TTCN完成PDCP SDU的加解密功能，模擬PDCP PDU對UE的PDCP層進(jìn)行測試。TTCN DRB端口定義了PDCP PDU可能出現(xiàn)的所有種類，包括LongSN Data PDU、ShortSN Data PDU、RohcFeedback、StatusReport等。

type union PDCP_PDU_Type {

PDCP_DataPdu_LongSN_Type DataLongSN，

PDCP_DataPdu_ShortSN_Type DataShortSN，

PDCP_DataPdu_ExtSN_Type DataExtSN，

PDCP_Ctrl_ROHC_FB_PDU_Type RohcFeedback，

PDCP_Ctrl_StatusReport_Type StatusReport，

PDCP_Ctrl_StatusReportExt_Type StatusReportExt

}；

4 結(jié)束語

TD-LTE終端協(xié)議一致性測試內(nèi)容覆蓋各層協(xié)議過程的理解與實(shí)現(xiàn)，使得TTCN對SS的設(shè)置非常細(xì)致。在L2測試SS的開發(fā)過程或者與UE聯(lián)調(diào)過程中，都要求研發(fā)測試人員對L2測試模型和相關(guān)TTCN的接口定義的含義有明確理解。對于L2測試?yán)齺碚f，TTCN要求SS的可控性非常高，SS不能僅限于支持TD-LTE各層的完整協(xié)議棧，還要按照TTCN的要求，在完整協(xié)議棧實(shí)現(xiàn)的基礎(chǔ)上留出相應(yīng)的測試接口，以便靈活的控制測試流程，才能更好的檢驗(yàn)UE協(xié)議的完整性和一致性。

參考文獻(xiàn)：

[1] 3GPP TS 36.523-1 V12.0.0. Evolved Universal Terrestrial Radio Access （E-UTRA） and Evolved Packet Core （EPC）； User Equipment （UE） conformance specification； Part 1： Protocol conformance specification[S]. 2013.

[2] 3GPP TS 36.523-3 V11.2.0. Evolved Universal Terrestrial Radio Access （E-UTRA） and Evolved Packet Core （EPC）； User Equipment （UE） conformance specification； Part 3： Test Suites[S]. 2013.

[3] 3GPP TS 36.509 V10.1.0. Evolved Universal Terrestrial Radio Access （E-UTRA） and Evolved Packet Core （EPC）； Special conformance testing functions for User Equipment （UE）[S]. 2013.

[4] TD產(chǎn)業(yè)聯(lián)盟. TDIA產(chǎn)業(yè)和市場發(fā)展簡訊[EB/OL]. （2014-03-30）. http：//www.tdia.cn/Downloads/PDF/2014Q1.pdf.endprint