基于TTCN—3的LTE终端一致性测试集设计概述

【摘 要】TTCN-3测试集是LTE终端一致性测试仪表在开发及使用中重要的软件支撑。通过介绍TTCN-3语言与LTE终端一致性测试框架，重点从TTCN-3测试集的主要构成、基于TTCN-3的LTE终端一致性测试代码的流程与接口设计这两方面对TTCN-3在LTE终端一致性测试中的应用进行了详细阐述。

【关键词】TTCN-3 LTE 终端一致性测试

中图分类号：TN929.5 文献标识码：B 文章编号：1006-1010（2013）-24-0056-07

1 引言

LTE作为新一代移动通信的主流技术，在全球得到了快速发展并展开商用。终端一致性测试的主要目标是能够通过完成一致性相关要求测试内容，进行国际化终端一致性认证，以保证不同厂家的终端在网络内的表现一致，并能够与不同厂家的系统设备、终端互联互通，是运营商、手机厂家等非常关注的一项测试。

LTE终端一致性测试需求由GCF（Global Certification Forum，全球认证论坛）提出，3GPP RAN5制定了一系列文本级测试规范，ETSI（European Telecommunication Standards Institute，欧洲电信标准化协会）与TDIA（Telecommunication Development Industry Alliance，TD产业联盟）合作开发基于TTCN-3语言的LTE协议一致性测试代码集，其中ETSI主要负责LTE FDD的开发，TDIA主要负责TD-LTE的开发。仪表厂家需要依据该统一的测试集进行终端一致性测试平台开发。基于TTCN-3的LTE终端一致性测试集验证通过后提交GCF和3GPP进行，作为标准测试集供第三方认证实验室对入网LTE终端进行测试认证。

2 TTCN-3语言与LTE终端一致性测试框架

TTCN-3语言由ETSI开发和维护，是一种专门为终端一致性测试和认证设计的标准化测试技术，其测试架构提供了控制测试执行的标准接口TRI和TCI，以方便测试平台的开发。TTCN-3是目前测试领域应用最广泛的测试例开发语言。一般来说，一个TTCN-3的测试系统由ATS（Abstract Test Suite，抽象测试套）、TTCN-3集成开发环境、适配层模块等部分组成。

TS 36.523-3给出了LTE一致性测试的框架示意图（见图1）。Host-PC承载TTCN-3代码，通过编译器翻译成C/Java代码，与适配层代码共同编译生成ETS（Executable Test Suite，可执行测试套）。硬件平台SS（System Simulator，系统模拟器）由Host-PC控制，与被测终端通过空中接口相连，负责模拟网络侧的PDCP/RLC/MAC层和射频部分等。由于协议一致性测试的特殊性，网络侧的RRC及以上层由TTCN-3实现。对于PDCP/RLC/MAC层的测试，系统模拟器要开放当前层的协议栈端口进行特殊配置：本层以下协议栈标准配置，本层DL和/或UL方向设置为透传模式，不进行头部的添加和/或头部的移除，由TTCN-3实现本层及其上层PDU编码和/或解码、相关参数的维护。适配层模块起到承上启下的作用，对上适配TTCN-3测试套，对下适配SS接口控制小区参数的配置和数据的收发。

3 TTCN-3在LTE终端一致性测试中的应用

3.1 TTCN-3测试集的主要构成

TTCN-3核心语言基于高级语言表达方式，与C语言有很多相似之处，由于要模拟通信过程进行黑盒测试，TTCN-3语言除了有很多常见的类型（如整型、布尔型、串类型、数组等），还有一些特殊的类型（如record、set、union、verdicttype、port、component、timer等）和操作语句。不同测试套中所使用的TTCN-3的类型和操作需要根据SUT（System Under Test，被测系统）的特点进行设计。TTCN-3测试集是检验LTE终端一致性的唯一标准，该测试集被3GPP在TS 36.523-3协议中。

图2简单显示了测试集的主要构成。testcase首先初始化MTC（Main Test Component，主测试组件）和System Interface，再由MTC建立EUTRA PTC（Parallel Test Component，并行测试组件），PTC还可以再建立NAS_EMU PTC（NAS模拟器PTC），在端口连接映射之后，测试组件之间即可相互通信。使用function对测试流程进行描述，主要包括三部分：被测系统状态准备Preamble、测试体Test body、被测系统恢复初始状态Postamble。

测试系统的重要功能是模拟通信收发，组件间的通信模拟了测试系统内部的计算和消息交互，组件通过系统接口与SUT完成最终通信。专门用于通信的特殊结构template，表示传送一类赋值参数的集合或者是为接收内容做接收匹配的样板。SUT的反应即测试系统接收情况通常是测试点，使用altstep来对接收过程可能发生的不同情况进行处理。TTCN-3提供ASN.1模块的调用，便于LTE L3消息的配置和收发。定时器（timer）在通信协议中至关重要，TTCN-3提供了定时器的启动、停止和超时等操作。此外，由于PDU在TTCN-3中以类型方式存在，如果测试过程中需要使用特定的PDU码流，就要进行编解码的操作。对于不同的SUT的PDU编解码，TTCN-3不可能一一遍历，因此通过利用函数encvalue/decvalue调用适配层的编解码函数的方法，获得函数的返回值。同时，TTCN-3也提供外部函数external、function来调用适配层中实现对应功能的函数。不同的SUT对于编解码和外部函数的需求不同，其在适配层中的具体实现不在本文的描述范围内，可参考TTCN-3的TCI和TRI标准以及所使用的TTCN-3集成开发环境的参考文档。最后，测试例运行需要给出一个判决结果，图2只给出了最终的判决示意，在测试例编写中，每个测试点都要进行测试结果的判决，并做好异常保护。

下面将围绕上述TTCN-3核心语言的主要构成部分，结合LTE终端一致性测试的设计思想进行TTCN-3代码集（简称测试集或者测试套）的介绍。

3.2 测试代码的流程与接口设计

TTCN-3 LTE测试例的顶层单元是module，所有的TTCN-3代码都要包含在module中，测试套中所有的.ttcn文件仅包含一个同名的module。module由定义部分和控制部分两个可选部分组成。模块的定义部分可以定义component、port、type、const、template、function、altstep、cestcase等，对于动态语言元素（如var或timer）的声明应该仅在控制部分、测试例、函数、可选步或组件中进行。一个模块如果需要使用其他模块中的定义，可在其定义部分使用import语句来引入所需模块。模块的控制部分可以通过control、execute语句控制调用测试例执行。一般来说，带有control/execute控制测试例选择的module是整个测试套的入口，可以由仪表厂家根据测试需要和上层界面设计自己编写。

TTCN-3可以与ASN.1（Abstract Syntax Notation One，抽象语法标记1）结合使用，ASN.1与TTCN-3的类型之间有对应关系，如SEQUENCE-record、SEQUENCE OF-record of、CHOICE-union、SET-set等。当ASN.1转化到TTCN-3时，连字符“-”变为下划线“_”；若ASN.1模块的定义字段使用了TTCN-3的关键字，则TTCN-3使用时在字段后面加上“_”。LTE一致性测试套中所有的EUTRA RRC message和RRC information elements都使用ASN.1描述于文件EUTRA_RRC_ASN1_Definitions.asn中，TTCN-3的模块可以通过关键字import和language引用该ASN.1模块对变量、类型、template进行定义。LTE使用了ASN.1的PER（Packed Encoding Rules，分组编码规则）编码对RRC消息进行编解码。

声明变量vc_EUTRA_Global（包含有EUTRA小区列表配置、security的配置和其他一些测试参数），定义系统配置端口SYS、系统响应端口SYSIND、信令无线承载端口SRB、数据无线承载端口DRB、NAS层控制端口NASCTRL、上层测试端口UT、与其他RAT间的端口UTRAN/GERAN/CDMA2000等。

System Interface是TTCN-3与SUT数据收发的最终通信端口。由于要与EUTRA、UTRAN、NAS-Emulation等PTC端口进行连接或者映射，测试系统接口的定义形式和component相同，可以使用关键字system引用测试系统接口定义进行测试例关联。对于关联测试例的系统接口，当测试例启动时，测试系统接口与MTC一起由系统初始化。

testcase是一种特殊的函数，使用execute语句来启动运行测试例，隐式的创建MTC并实例化MTC端口和测试系统接口，测试结果为verdicttype类型值。测试例头部须明确该测试运行的MTC，可以用system标出该测试例需要引用的系统端口。如图3所示，以测试例8.1.1.1的定义为例，测试例运行在主测试组件MTC_LTE上，测试系统接口为SYSTEM_LTE，由于是LTE单模测试例，仅create了并行测试组件EUTRA_PTC的实例，函数f_MTC_ConnectPTCs_LTE中建立NASEMU_PTC/IP_PTC等并行测试组件且开启各自的数据处理循环功能，并对端口进行了connect或map，开始EUTRA_PTC实例上的测试行为f_TC_8_1_1_1_EUTRA（），启动总定时器t_GuardTimer，开启MTC主循环。

组件中最重要的定义就是port端口，它用于component之间和component与测试系统接口之间的通信，通过关键字message定义端口上的ASP（Abstract Service Primitive，抽象服务原语），out用于发送，in用于接收，inout表示双向混合。对于E-UTRAN component上定义端口的ASP在TS36.523-3中规定，例如SYS端口定义SYSTEM_CTRL_REQ和SYSTEM_CTRL_CNF分别是该端口发送、接收的消息类型。port可以使用操作connect和map进行连接或映射，为MTC-PTC、MTC-System Interface、PTC-PTC、PTC-System Interface相关端口间的收发消息做准备，测试集中使用函数f_MTC_ConnectPTCs_LTE来完成端口的连接操作，连接映射如图4所示。

其中，最大边框表示系统接口SYSTEM_LTE，其他可能存在的component也在图4中画出，虚线的操作是否存在依赖于测试例、是否为多模测试或者LTE小区是否配置相关功能。如果两个端口被连接起来，例如SRB和TC_SRB，SRB.send的数据由TC_SRB.receive、SRB.receive的数据是TC_SRB.send过来的；如果两个端口进行了映射，例如SYS_SRB和E_SRB，SYS_SRB口上的收发就相当于E_SRB上数据的收发。

template模板为通信端口上发送send和接收receive操作传递的唯一结构，是一种特殊的数据结构，可用作参数传递。它为发送内容提供特定值的集合，为判定接收数据是否匹配提供模板依据。例如配置SS对UE的随机接入响应时，SYS端口send一个类型为SYSTEM_CTRL_REQ、对所有元素都已赋值的模板，其中对msg2、msg4等RACH参数赋特定值，其他配置不变的可选参数赋值为omit；如果需要确认SS反馈配置是否完成，那么接收端等待接收类型为SYSTEM_CTRL_CNF、cell配置完成的confirm模板。若receive收到的与接收模板匹配，则测试例继续；否则进入异常处理。

function用来描述测试流程，函数的定义或外部调用函数的声明（external）都要放在module中，可以return一个返回值。测试的步骤可以按序写在一个函数里，并且可以规定该函数运行在某个component上从而引用该component的定义。对于一些计算规则明确但计算过程繁琐、测试例中仅仅需要一个简单的返回值的函数，TTCN-3采用外部调用函数来处理。TTCN-3仅为外部函数提供函数接口，不允许包含端口、定时器和默认处理操作，不允许返回template。对于LTE中加密和完整性保护算法的计算，测试套采用了外部函数的处理方法，例如外部函数fx_NasIntegrityAlgorithm计算完整性保护消息MAC（Message Authentication Code，消息鉴权码），输入参数包括需要安全保护的消息p_EncodedNasPdu、完保算法p_IntegrityAlgorithm、K值p_KNASint、p_NasCount、p_BearerId、p_Direction，当该函数被调用时，将使用测试系统适配层中相应函数，进行完整性保护算法计算后再把MAC值作为输出参数返回给TTCN-3。

可选步altstep或alt语句针对可能发生的几个事件提供了一种处理的方法，常与数据接收、测试点判决、定时器等操作结合使用。其中，altstep和函数类似，也可以运行在一个component上来引用该component的定义，并且能够用activate和deactivate来激活或者取消激活可选步。altstep/alt语句利用在符号[]中不填或填入布尔表达式来控制当前可选对象被列入考察的条件，并且结合repeat语句进行循环接收以实现对较复杂情况的描述。例如用于层2测试的alt语句，如果收到满足模板要求的SRB或DRB数据之一就继续接收，直到SRB和DRB的数据都收到就成功跳出alt语句，或者发生t_Wait超时进入异常处理。

定时器在通信协议中必不可少，用来考察一个事件的到达，它的状态直接影响到接下来发生的行为。已声明的定时器可以赋一个持续时间值（非负浮点数），以秒为单位。TTCN-3 timer提供了start、stop、timeout等操作，以配合一定时间内对事件发生后进行正常或者异常处理。

测试例根据执行情况给出判决结果，其类型verdicttype取值包括：通过（pass）、失败（fail）、不确定的（inconc）、空（none）和错误（error）。测试结果判定的设计要充分考虑到测试过程中出现的各种可能性，做到完善的错误保护。一般来说，pass为测试流程正确结束；fail为测试例主体中接收过程有误；inconc为非测试主体的接收过程有误；error不是测试例编写过程中设置的，而是测试例运行时由测试系统设置，用来指出TTCN-3编译器或者是适配层等发生了一个错误。在测试例的调试过程中，需要调测人员对3GPP各层协议和测试协议比较了解，对TTCN-3语言和LTE测试集非常熟悉，掌握系统模拟器以及终端的配置和使用，并且对适配层有一定的认知，才能很快地定位出错的原因。

4 结束语

本文结合TTCN-3核心语言和终端一致性测试框架，简要介绍了LTE终端一致性测试集代码的流程和接口设计。本测试集作为GCF规定的终端进行一致性测试认证时必须使用的标准测试例代码，是测试仪表唯一的运行脚本和调试参考，是对核心协议的理解与实现，代码要求具有很高的正确性和完备性。目前TD-LTE和FDD LTE测试代码达到同步开发，2013年度STF160小组开发重点主要是：统一Rel-10版本之后所有测试例的测试模型，包含多个并行的测试模块、可处理不同的3GPP数据结构（ASN.1/CSN.1/XSD）；新开发测试例包括语音呼叫（VoLTE、紧急呼叫）及呼叫连续性测试、LTE-A（载波聚合测试）、E-UTRA/UTRA更新和完善（MDT、ANR、UE positioning、NIMTC、3C/4C HSDPA）。

参考文献：

[1] ETSI ES 201 873-1 V4.4.1. Methods for Testing and Specification（MTS）； The Testing and Test Control Notation version 3； Part 1： TTCN-3 Core Language[S]. 2012.

[2] ETSI ES 201 873-1 V2.2.1. 测试描述方法（MTS）；测试和测试控制表示法第三版；第一部分：TTCN-3核心语言[S]. 2003.

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

[4] 3GPP TS 36.523-1 V11.3.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.

[5] MCC TF160. R5-134010： TF160 TTCN Current Status Report[EB/OL]. （2013-11-05）. http：///ftp/tsg_ran/WG5_Test_ex-T1/TSGR5_61_SanFrancisco/Docs/.