图1 可执行测试套生成原理
由图1可见，为了生成可执行测试例，只由TTCN编辑器产生的C代码是不够的，因为仍然没有关于内部协议结构和测试平台的具体描述。事实上，在MP文件中动态部分给出的事件被转换成了函数调用，而不是函数本身。这些函数，比如收发消息等通过调用适配层库中相应的函数来完成编码和解码等消息的传递。在图1中还可以看到C编辑器首先编译由TTCN编辑器创建的C代码，然后和适配层库一起链接目标文件，最后生成可执行测试套。尽管利用TTCN编辑器编辑的MP文件到C文件的转换是独立于内部协议结构的，但需要说明的是，适配层用的消息格式与对应的TTCN申明部分的消息格式是一致的。如果不一致，转换到C代码后，测试套结构类型的定义就不再与适配层相符合。在这种情况下，可执行的测试套仍然会产生（即链接过程仍然起作用），但由于编译码警告，当收发消息时会发生错误。测试套的静态部分，特别是声明部分永远都不应该被改变，而动态行为的改变不重要。通常情况下，正是利用这一点不断地完善测试例，而不需要一次设计完成RRM所需要的31个测试例。也保证可采用TTCN-2方式设计的测试例不会因为协议本身小的修改或版本升级而对软件结构进行大结构性的修改。
通常的适配层对协议独立任务是有响应的，因此它可以使ETS能够读取配置文件并为各层以及测试套的执行创建所需的log文件。其他的协议独立任务，比如编译码和消息传递、计时器处理也由适配层设计和实现。同时适配层的另一个功能是，通过定义相应的PCO（控制观察点）和SAP（业务接入点）来定义协议栈具体的响应，并将协议栈接收到的ASP的格式转换为TTCN消息。
3.2RRM一致性测试架构设计
RRM一致性测试系统的软件包含主控软件、高层协议栈软件、低层协议栈软件和物理层软件等，如图2所示。
图2 RRM一致性测试系统软件架构
在图2给出的软件结构中，协议栈软件通过低层协议栈中的MAC以及驱动软件，完成与物理层软件的交互；通过高层协议栈中的APP部分和低层协议栈中的API调度器完成用户平面内容的交互；通过高层协议栈中由TTCNMP文件生成的适配和低层协议栈中的API调度器完成用户平面内容的交互。
高层协议栈完成TD-SCDMARNC中RRC、NAS（非接入）部分的功能，其中RRC和NAS采用TTCNMP文件实现，由于RRC、NAS部分采用TTCN的实现方式，致使高层协议栈部分除了这两部分内容之外还需要其他相关辅助模块以完成与主控软件、低层协议栈之间的正常、完全的交互。低层协议栈完成TD-SCDMARNC中RABM、PDCP、RLC、MAC等4个部分的功能。这4部分内容均是依照协议实装实现，其中的MAC实体满足RRM一致性测试系统中同时支持6个小区的需求。
基于TTCN-2一致性测试原理来分析RRM测试系统的结构，其主要由两部分组成：一部分是网络侧（UTRANside），另一部分是终端侧（UEside）。如图3所示。在网络侧，该设计包括了不同的PCO，这些PCO主要是对网络侧的不同层进行配置和管理。
图3 TD-SCDMA终端RRM一致性测试平台结构
