LTE测试集---测试系统概述
LTE终端协议符合性是关乎互操作的大事情，3GPP在制定LTE协议的同时也采用TTCN-3定义开发了LTE终端协议符合性测试集。该测试集是唯一被认可的LTE终端符合性测试集，也是被GCF等认证机构采用的认证检测测试集。本文可结合TTCN-3/TTworkbench培训培训内容。如下图所示是LTE测试系统概念性的测试架构。待测（SUT）是LTE移动设备（UE），测试系统有两个重要组件，主机和硬件适配。主机元素包括测试控制部分，测试执行引擎和相应的编解码。硬件适配器提供了到SUT的适配。在这个例子中意味着补齐UE接口的所有测试协议层以下的协议层。
图一、LTE test system architecture
LTE测试集概览
一旦你在TTCN-3工具（TTworkbench)中打开LTE测试集开始浏览代码，你会发现LTE测试集不是一个简单的测试集。确实这个测试集非常复杂，不容易解释清楚所有细节。我们先提供一个概述帮助你理解总体的结构和测试概念。
在考量整个测试集的时候，你可能会发现这个测试集采用了我们在第14章和第15章中学习到的概念和建议。这个测试集采用了一个设计得非常好的Framework.它也采用了命名惯例(请参考TTCN-3官网关于3GPP定义命名规定）。例如，运行在一个组件上的function以f开头，altsteps以a开头，发送模板以CS开头，接收模板以CR开头。除了清晰的命名，也定义了清晰的declarations布局，例如所有的变量都在功能前边定义，declarations的顺序先是本地常量，接着是本地变量，然后是本地计时器。
LTE测试集在最上层被分成了一系列的以TTCN-3为前缀名的文件夹。在每个文件夹里包含一个或多个TTCN-3模块，让我们先从第一个文件夹开始查看，这个文件夹以TTCN-3命名。当双击这个文件夹查看时，可以看到它包含两个TTCN-3模块：LTE_EPS_TS_SelectionExpressions和LTE_EPS_TS_Testcases.如果我们现在双击LTE_EPS_TS_Testcases，源代码在测试工具（TTworkbench)中间窗口打开，这个模块可以看成是这个测试集的中心模块，它定义了所有的测试例。如果我们仔细查看代码内容，我们可以看到这个模块以一系列的导入statements开始，从其它模块导入了定义，然后它定义了所有的测试例，最后是控制部分，测试例是在控制部分被调用的。一个测试例是否被测试控制部分调用取决于function f_ExecutionGuideline,在一些例子中结合了测试例子选择表达（Whether a specific test case is actually called when the control part is executed on the result from the function f_ExecutionGuideline in some cases combined with test selection expression)。
LTE测试集---测试例定义(Test Case Definitions)
现在让我们通过一个测试例看看LTE测试例的构建以及组件的架构是如何组织的，如果我们看测试例 TC_6_1_1_1
Testcase TC_6_1_1_1() runs on MTC system SYSTEM {
// @purpose
// PLMN selection of RPLMN, HPLMN/EHPLMN, UPLMN and OPLMN
var GERAN_PTC v_GERAN := null ;
var EUTRA_PTC v_EUTRA :=EUTRA_PTC.creat alive ;
var UTRAN_PTC v_UTRAN :=null ;
timer t_GuardTimer := int2float(2400) ;
f_MTC_ConnectPTCs(v_EUTRA, v_UTRAN, v_GERAN ) ;
v-EUTRA.start (f_TC_6_1_1_1_EUTRA()) ;
t_GuardTimer.start;
f_MTC_MainLoop(t_GuardTimer);
}
我们可以看到测试例运行在MTC（master test component)上。注释定义的目的之后，我们可以看到三个变量的声明，提供可能的平行组件的参考。通过名字我们可以很容易的看到我们为测试中可能涉及用到的每个Radio access 技术定义了平行组件。GERAN_PTC是GSM的，UTRAN_PTC是UMTS的，EUTRA_PTC是LTE的（虽然这套测试集是测试LTE,但在有些测试中还是需要在测试系统和待测系统间创建通过其它无线技术的连接，如Handover测试）。在我们选择的这个例子中，我们实际上只需LTE连接，因此只有LTE PTC我们使用了create 创建命令语句。在创建完平行组件后，测试例定义了计时器，然后调用功能函数f_MTC_ConnecPTs.这个功能函数创建了MTC和PTCs之间的所有必要的连接。在创建完组件并进行了必要的组件连接后，我们现在实际开始要求的测试行为，在传参函数 function f_TC_6_1_1_1_EUTRA传递的LTE PTC上采用Start操作。采用StarThis is done using the start operation on the LTE PTC passing in the function f_TC_6_1_1_1_EUTRA.就是在这个函数中，实际的测试行为，与SUT发送和接收消息被定义。我们稍后还要回到这个函数。接下来测试例启动guard timer ,然后调用行数function f_MTC_MainLoop ，f_MTC_MainLoop函数的基本上就是只等待平行测试组件完成行为。
从这个例子中我们可以看到LTE测试例的一些特点，实际上如果你查看整个模块，你会发现这些特点在所有例子中是共通的。首先我们可以看到顶层测试例只在MTC执行，其次我们可以看到测试例的实际行为执行在平行组件上。所有测试例运行在MTC上是相同的任务：创建平行组件PTCs，连接平行组件PTCs,开始计时器（guard timer）,然后等待平行组件完成。
LTE测试集---测试行为定义Test Behaviour Definition
现在让我们来看这个测试例的实际的测试行为定义，测试行为定义在function f_TC_6_1_1_1.这个function定义可以在ttcn-3\6_1文件夹的module Idle_PLMNSelection 中找到。这个函数中的行为可以被分为三部分。第一部分是preamble,使待测设置在执行测试例需要的状态。然后是测试主体也就是我们要测试的行为，最后是初始化待测到原来的状态，以便后边的测试例测试使用。找到这些变量哪里开始和哪里结束的最简单方法是调用 function f_EUTRA_TestBody_Set。这个函数在测试最开始和测试结束部分被调用，在开始部分参数是true,在结束部分参数是false。测试体本身被分成一系列的steps，这些测试步骤对应与3GPP标准：终端协议符合测试说明【（3GPP TS 36.523-1 V
LTE测试集---EUTRA 平行测试组件（EUTRA Parallel Test Component）
现在让我们来研究运行函数的平行测试组件（parallel test component）。如我们在4.10章节中学习的，平行组件类型要与Runs on 放在一起用。从 f_TC_6_1_1_1(如下）我们可以看到组件类型是EUTRA_PTC.这个类型在ttcn3/commonEUTRA文件夹的EUTRA_Component模块中定义。一般来讲端口可以分成四组，在图二的上边是对MTC的接口，这个UT接口是控制平行组件上行为的执行。右边的这组端口是与其它平行测试组件之间协调和交流的接口。左边端口是与TTCN-3执行引擎下协议栈和仿真器的接口，最后在图形下边这组端口负责与待测通信。SRB控制平面信息端口，DBR是用户平面数据端口。控制平面是LTE核心网络和移动设备信令流量的通道。用户平面是所有用户数据的信息通道，也就是移动设备用户实际想要发送和接收的信息。
Type component EUTRA_PTC{
Var EUTRA_Global_Type vc_EUTRA_Global;
Port EUTRA_SYSTEM_PORT SYS;
Port EUTRA_SYSIND_PORT SYSIND ;
Port EUTRA_SRB_PORT SRB ;
Port EUTRA_NASCTRL_PORT NASCTRL ;
Port EUTRA_DRB_PORT DRB ;
Port IRAT_CO_ORD_PORT UTRAN ;
Port IRAT_CO_ORD_PORT GERAN ;
Port IP_RAT_CTRL_PORT IP ;
} ;.
图二、EUTRA Component Type
LTE测试集---测试集模块结构
已经研究了测试例TC_6_1_1_1以及相关的函数f_TC_6_1_1_1,现在是时候更好的理解测试集全部模块的结构了。我们可以看到包含平行测试组件测试行为的模块被分成了若干文件夹，体现了3GPP TS 36.523-1 V
Table 16.3 Test group areas for LTE suite
Group Sub-group Test area
6 - Idle mode operations
6.2 Muti-mode environment (E-UTRAN,UTRAN,GERAN,CDMA2000)
6.3 Closed subscriber group cells
7 - Layer 2
7.1 MAC
7.2 RLC
7.3 PDCP
8 - RRC
8.1 RRC connection management procedures
8.2 RRC connection reconfiguration
8.3 Measurement configuration control and reporting
8.4 Inter-RAT handover
8.5 RRC others
9 - EPS mobility procedures
9.1 EMM common procedures
9.2 EMM specific procedures
9.3 EMM connection management procedures(S1 mode only)
9.4 NAS Security
10 - EPS session management
11 - General tests
12 - E-UTRA radio beaer tests
13 - Multi layer procedures
LTE测试集-RRC层协议消息定义
这套测试集测试的最主要协议是RRC(Radio Resource Control)，RRC是LTE的层3协议，RRC被LTE测试集中大多数的TTCN-3消息采用与待测交换信令消息，RRC协议是采用ASN.1定义的，如在第
在文章最后的部分，让我们来看看ASN.1数据类型定义是如何在测试例中被应用的。让我们在回到文件夹ttcn3\6_1 模块Idle_PLMNSelection 的函数f_TC_6_1_1_1。看一下测试主体部分的step 3.
// Step 3: Receive RRCConnectionRequest on Cell 12
SRB.receive(car_SRB0_RrcPdu_IND(eutra_Cell12,
Cr_508_RRCConnectionRequest));
T_IdleMode_GenericTimer.stop;
//* @verdict pass RRCConnectionRequest message receive on Cell 1
F_EUTRA_PreliminaryPass(_FILE_, _LINE_,”Test case
我们可以看到这步是以receive statement开始的.从我们之前对EUTRA_PTU组件类型的了解，我们知道因为receive statement是在SRB端口执行，它正在期待从待测SUT（The LTE mobile device）收到信令消息。期待接收到的消息是用cas_SRB0_Rrcdu_REQ模板定义的，如果我们在ttcn3\commonEUTRA_Template文件夹中的EUTRA_SRB_Templates模块看一下这个模板的定义，我们可以看到我们实际期待接收到的消息类型是SRB_COMMON_REQ。我们也注意到模板和模板使用的参数应用到我们在11.6章节中学习到的Template restrictions原则。The(Value) notation指出模板必须解析到一个特定的值。
Example SRB template
Template (value) SRB_COMMON_REQ cas_SRB0_RrcPdu_REQ(
CellId_Type p_CellID
Template(value) TimingInfo_Type p_TimingInfo,
Template (value) DL_CCCH_Message p_RrcPdu) :=
Common := cs_ReqAspCommonPart_SRB(p_CellID,tsc_SRB0,p_TimingInfo),
Signalling := {
Rrc :={
Ccch :=p_RrcPdu
},
Nas := omit
}
};
SRB_COMMON_REQ类型的定义可以在文件夹ttcn3\CommonEUTRA_Defs中的EUTRA_ASP_Srbdefs模块中找到。如下SRB_COMMON_REQ type definition
Type record SRB_COMMON_REQ{
/* common ASP to send PDUs to SRB0, SRB1 or SRB2 * /
ReqAspCommonPart_Type Common,
C_Plane_Request_Type Signalling
};
从这个类型定义，我们可以看到消息被分成了两部分：Abstract Service Primitive（ASP）信息和信令。在LTE测试集中，所有的消息都被分成了ASP和Protocol Data Unit(PDU)。待测实际要收到的消息是在PDU中被定义的，在这个例子中包含在信令领域里。ASP和与之相关的的任何相关的信息字段是纯粹的为TTCN-3测试执行引擎下的协议栈和适配层。
如果我们想找到ASN.1定义是在哪里被应用的，我们需要仔细看这个类型的PDU部分，在我们的这个例子中应该解析到RRC消息。其中包含的PDU的信令字段的类型是C_Plane_Request_ Type。它的类型定义可以在同一模块SRB_COMMON_REQ.In中找到。如下C_Plane_Request_Type definition
Type record C_Plane_Request_Type {
/* RRC and/or NAS PDU to be send to the UE */
RRC_MSG_Request_Type Rrc optional,
NAS_MSG_Requestlist_Type NAS optional
} ;
这个测试案例，其中涉及的RRC prtotocol这只是个第一个域Rrc，它是相关的。这个域有RRC_MSG_Request_Type类型，可以在ttcn3\CommonEUTRA_Defs文件夹的EUTRA_CommonDefs模块中找到这个类型的定义。如下
RRC_MSG_Request_Type definition
Type Union RRC_MSG_Request_Type{
/* DL RRC PDU on CCCH or DCCH * /
DL_CCCH_Message Ccch,
DL_DCCH_Message Dcch
};
看着这个类型，我们终于有了到ASN.1定义的链接。如果我们看这个类型的第一个域，Ccch是DL_CCCH_Message类型中的一个域，这个类型是在我们之前了解过的模块EUTRA_RRC_ASN.1_Definitions中定义的。
3GPP LTE测试集结构介绍文档下载
| 下载信息 [文件大小：279.49 KB 下载次数： 次] |
 点击下载文件:3GPP LTE测试集结构介绍 |
