深度解析 3GPP TS 38.523-3：6 System Interface (系统接口：与虚拟世界的对话语言)

本文技术原理深度参考了3GPP TS 38.523-3 V18.2.0 (2025-03) Release 18规范中，关于“6 System Interface”的核心章节，旨在为读者揭示自动化测试脚本（TTCN-3）与测试系统（SS）之间进行命令与控制交互的标准化接口，即我们与5G虚拟世界对话的“官方语言”。

前言：“Explorer-Sat”的控制面板与API

在之前的征程中，测试工程师李工已经利用第5章定义的各种“测试模型”（Test Models），为他的“Explorer-Sat”勘探终端构建了从NSA到SA、从地面NR-U到太空NTN的多种虚拟测试环境。他就像一位沙盘游戏大师，搭建了各种精妙的“战场”来检验终端的协议能力。

然而，一个问题始终萦绕在李工脑中：他（或者他编写的自动化脚本）究竟是如何对这些复杂的“沙盘”进行精细操作的？当TTCN-3脚本中出现一行简单的指令，如“配置一个NR小区”或“发送一个寻呼”，这行抽象的文本是如何被翻译成测试仪表（SS）能够理解并执行的精确动作，最终变成“Explorer-Sat”可以接收到的真实无线信号的？

答案就隐藏在规范的第六章——“System Interface”（系统接口）之中。这一章是连接“测试逻辑”与“物理实现”的桥梁，它定义了测试系统对外暴露的两种核心“控制面板”：

上层测试接口 (Upper Tester Interface)：一套面向人工干预或外部脚本的“遥控器”，允许测试者在协议之外对测试流程进行高级控制。
抽象系统原语 (Abstract System Primitives, ASPs)：一套标准化的、机器可读的“API（应用程序编程接口）”，是TTCN-3自动化脚本与测试系统之间进行命令交互的“官方语言”。

理解了第六章，就等于掌握了与5G虚拟世界进行精确对话的能力。本篇文章，我们将跟随李工，深入探索这两种接口的定义、结构和使用场景，揭开自动化测试背后那层神秘的“控制论”面纱。

1. 人工干预的“遥控器”：6.1 Upper Tester Interface

上层测试接口（UT Interface）提供了一种在TTCN-3测试流程之外与测试环境进行交互的手段。它并非用于定义核心的协议交互，而是处理一些准备、辅助或模拟用户行为的特殊操作。

规范首先指出，其基本接口与LTE的测试规范TS 36.523-3保持一致，但为5G NR引入了新的MMI（Man-Machine Interface）命令和一系列适用的AT命令。

1.1 MMI命令：测试的“超级工具箱”

MMI命令允许测试者或外部控制脚本向测试系统发送高级指令，以设置特定的测试条件或触发特定的非协议行为。这就像一个功能强大的“遥控器”，提供了TTCN-3标准流程之外的灵活性。

规范中的 Table 6.1-1: MMI commands 详细列出了这些命令。让我们通过李工的视角，看看他会如何使用其中的几个关键命令。

场景一：多卡手机的身份指定 “Explorer-Sat”终端的高配版支持双卡（Multi-USIM）功能。在开始一个针对卡2的测试之前，李工需要明确告知测试系统，接下来所有的交互都是针对第二个USIM的。此时，他就可以调用MMI命令：

"SET_MUSIM_UAI"：这个命令允许他设置要使用的UAI（USIM Application Identifier），从而将测试焦点切换到指定的USIM上。

场景二：广播业务的兴趣激活 在测试5.2.1.8节定义的MBS（5G广播业务）时，一个前提是UE需要对某个广播业务“感兴趣”。李工可以通过MMI命令来模拟这个用户行为：

"MBS_SERVICE_INTEREST"：通过这个命令，他可以指示“Explorer-Sat”向网络表现出对某个特定MBS Service ID的“兴趣”（Interest: “ON”），从而触发后续的广播接收流程。

场景三：特殊配置查询 在一次复杂的Sidelink V2X测试前，李工想确认测试仪表当前配置的关于CSI-RS的参数是否正确。他可以调用：

"SL_CSI_RS_CONFIGURATION"：这个查询命令可以让测试系统返回当前配置的频率分配、起始符号等关键信息，便于快速核对。

下面，我们遵照规范，完整地重绘这张重要的MMI命令表：

Table 6.1-1: MMI commands

Command	Parameters
	Name	Value
”C2MODIFY_SESSION"	"Session Id"
"CAPABILITY_ENQUIRY"	"Freq. Band List"
	"Two-Way"	"TRUE” / “FALSE"
"CHANGE_RAC_ID”	(none)
“CLEAR_RSNPN”	(none)
“NO_PRECONDITIONS”	(none)
“PERIODICAL_MEASUREMENT_PSBCH_RSRP"	"Report Interval"
"SET_MUSIM_UAI"	"RRC_STATE"	"idle” / “inactive” / “outOfConnected"
	"STARTING_SFN” NOTE 1
	”STARTING_SUBFRAME” NOTE 1
	”GAP_LENGTH” NOTE 1	“ms3” / “ms4” / “ms6” / “ms10” / “ms20”
	“GAP_REPETITION” NOTE 1	“ms20” / “ms40” / “ms80” / “ms160” / “ms320” / “ms640” / “ms1280” / “ms2560” / “ms5120”
	“GAP_OFFSET” NOTE 1
”SL_CSI_RS_CONFIGURATION"	"Freq. allocation One antenna Port”
	“First symbol"
	"Latency Bound"
"SL_CSI_REPORT”	(none)
“SNPN_AUTOMATIC”	(none)
“SNPN_MANUAL"	"PLMN"
	"N_ID"
"SNPN_SUBSCRIBER_DATA"	"PLMN"
	"N_ID"
	"ACCESS_ID"	"ACCESS_ID"
"UEAI"	"SL-QoS Flow ID"
"UNICAST_SLDRB"	"Action"	"ESTABLISH” / “MODIFY” / “RELEASE"
"MBS_SERVICE_INTEREST"	"Service"
	"Interest"	"ON” / “OFF”
“MBS_SERVICE_ACTIVE”	“Service”
	“Active”	“ON” / “OFF”
NOTE 1: These 5 parameters make up one instance of musim-GapInfo. Up to 4 instances of musim-GapInfo make up the musim-GapPreferenceList, which is itself optional. Each of these parameters is therefore also optional.

1.2 AT命令：与终端模组的传统对话

The following AT commands are also applied in the TTCN.

AT命令是控制调制解调器（Modem）的一套历史悠久且广泛使用的标准指令集。在一致性测试中，TTCN-3环境也可以通过上层测试接口来发送AT命令给UE。这通常用于配置一些非常底层的、非3GPP协议栈本身但又影响测试的行为，或者查询模组的状态。

规范在 Table 6.1-2: AT Commands 中列出了在测试中可能使用到的AT命令。例如，AT+C5GQOS 可能用于查询或设置一个与5G QoS相关的参数。这些命令的具体语法和功能遵循TS 27.007的定义。

Table 6.1-2: AT Commands

Command
AT+C5GNSSAI
AT+C5GNSSAIRDP
AT+C5GQOS
AT+CGBRRREQ
AT+CLCCS
AT+CMICO
AT+CNASCREL
AT+CPAGRES
AT+CPAGTCC
AT+CPSDO
AT+CREJPAG

2. 自动化的“机器语言”：6.2 Abstract System Primitives (ASP)

这部分是第六章的核心，它定义了TTCN-3自动化脚本与测试系统（SS）之间沟通的“语言”——ASP。

6.2.1 Introduction The present clause 6.2 specifies the abstract system primitives (ASPs) used on the system interface to configure and control the SS.

ASP不是简单的文本命令，而是一套定义严谨、结构复杂的数据结构。它们是TTCN-3语言中send和receive操作的对象，构成了测试逻辑与底层实现之间的标准化接口。无论李工使用的是哪个厂商的测试仪表，只要该仪表实现了对这套ASP的正确解析和执行，他的TTCN-3脚本就能无缝运行。

2.1 ASP的“三段论”：请求、确认与指示

ASP的交互模式遵循经典的三种类型：

_REQ (Request)：请求。由TTCN-3测试脚本发送给SS，用以发起一个动作或配置。例如，NR_SYSTEM_CTRL_REQ 就是TTCN-3请求SS去配置一个NR小区。
_CNF (Confirm)：确认。由SS发送给TTCN-3，用以回应一个_REQ，告知该请求已完成（或失败）。例如，在成功配置小区后，SS会回复一个NR_SYSTEM_CTRL_CNF。
_IND (Indication)：指示。由SS主动发送给TTCN-3，用以报告一个从UE侧观察到的异步事件。例如，当SS的物理层检测到一个来自UE的PRACH前导码时，它会发送一个包含该前导码信息的NR_SYSTEM_IND给TTCN-3。

这套“请求-确认/指示”的机制，构成了自动化测试流程中所有控制与反馈的基础。

2.2 ASP的定义来源：指向附录D的“路标”

第六章本身并没有详细定义每一个ASP的结构，而是做了一个“路标”的角色。

6.2.3 E-UTRAN ASP definitions Please refer to TS 36.523-3 clause 6.2.

6.2.4 NR ASP definitions See Annex D.

这段引用清晰地指明：

所有与E-UTRA (LTE) 相关的ASP，其定义遵循LTE的测试规范TS 36.523-3。
所有与NR (5G) 相关的ASP，其详细、完整的TTCN-3数据结构定义，全部位于本规范的附录D (Annex D: TTCN-3 definitions)。

附录D是这部规范中代码密度最高的部分，它用纯粹的TTCN-3语言，从最高层的NR_SYSTEM_CTRL_REQ到底层的NR_MAC_PDU_Type，定义了上千个数据类型和结构。对于李工来说，附录D就像是这门“机器语言”的“语法和词典大全”。当他需要构造一个复杂的RRC消息，或者解析一个SS上报的底层指示时，附录D就是他最权威的参考。

2.3 场景故事：一次“寻呼”的ASP之旅

李工想要编写一个简单的测试序列，来验证“Explorer-Sat”的寻呼响应功能。我们来看看这个过程中ASP是如何流转的：

环境配置：
- TTCN → SS: send(NR_SYSTEM_CTRL_REQ with { cellConfig := { ... }, pcchConfig := { ... } })
  - 李工的脚本首先发送一个NR_SYSTEM_CTRL_REQ请求，其中包含了完整的NR小区配置，以及PCCH（寻呼信道）的配置。这个请求的数据结构极其庞大，其定义就来自附录D。
- SS → TTCN: receive(NR_SYSTEM_CTRL_CNF)
  - 测试仪表配置好硬件后，回复一个CNF，告诉脚本：“虚拟小区已建立，随时可以开始。”
触发寻呼：
- TTCN → SS: send(NR_SYSTEM_CTRL_REQ with { pagingTrigger := { ... paging message ... } })
  - 脚本再次发送NR_SYSTEM_CTRL_REQ，但这次的重点是填充pagingTrigger字段，里面包含了要发送的寻呼消息内容和精确的寻呼时机（Paging Occasion）。
- SS → TTCN: receive(NR_SYSTEM_CTRL_CNF)
  - SS确认寻呼任务已成功调度。
监测UE响应：
- SS → TTCN: receive(NR_SYSTEM_IND with { rachPreamble := { ... } })
  - “Explorer-Sat”收到寻呼后，发起随机接入过程。当SS的物理层检测到PRACH前导码时，它会立刻向TTCN发送一个NR_SYSTEM_IND指示，报告前导码的ID和接收时间。
- TTCN → SS: send(NR_DRB_COMMON_REQ with { rarPayload := { ... } })
  - TTCN脚本收到指示后，立即构造RAR（随机接入响应）消息，并通过一个NR_DRB_COMMON_REQ（这里用一个通用请求的例子）发送给SS，指示其在DL-SCH上发送RAR。

通过这一系列ASP的交互，一个完整的“寻呼-响应”测试流程被精确、自动化地执行了。

总结：掌握与虚拟世界对话的两种语言

第六章“System Interface”为我们揭示了5G终端自动化测试的控制核心。它定义了两套截然不同的但又相辅相成的接口：

Upper Tester Interface 提供了面向高层和人工的“遥控器”，通过MMI和AT命令，实现了对测试环境的灵活干预和非协议行为的模拟。
Abstract System Primitives (ASP) 则提供了面向自动化脚本的、标准化的“机器语言”，通过REQ/CNF/IND三元组，实现了TTCN-3测试逻辑与底层物理实现的精确映射和解耦。

对于李工来说，熟练掌握ASP这门“语言”，就如同掌握了与5G虚拟世界进行深度对话的能力。他现在不仅知道要搭建什么样的“沙盘”（测试模型），更知道了如何通过精确的“指令”（ASP）来操控这个沙盘中的每一个元素。

在掌握了控制语言之后，李工的下一个目标将是学习如何运用这门语言来编排各种复杂的“戏剧”——即具体的测试方法和流程。在下一篇文章中，我们将进入规范中内容最丰富、最具体、最具指导性的第七章“Test methods and design considerations”。

FAQ

Q1：Upper Tester接口和ASP接口的主要区别是什么？我应该在什么时候使用它们？

A1：主要区别在于抽象层次和用途。

Upper Tester接口 (MMI/AT命令) 位于更高的抽象层，更接近用户或外部系统。它用于测试流程之外的控制和配置，例如：在测试开始前手动查询UE能力、模拟用户发起一个特定的业务（如对MBS感兴趣）、在多USIM设备中选择要测试的USIM等。
ASP接口 则是TTCN-3测试脚本内部使用的、与协议交互紧密耦合的程序化接口。它用于执行协议规范中定义的每一个具体步骤，例如：配置一个RRC消息的所有字段、在某个精确的时隙发送一个DCI、报告一个接收到的MAC PDU等。简单来说，当你需要做的操作是3GPP协议流程的一部分时，你会使用ASP；当操作是测试的准备、辅助或模拟非协议行为时，你会使用Upper Tester接口。

Q2：ASP中的REQ, CNF, IND分别代表什么？请举例说明。

A2：它们代表了TTCN与SS之间的三种基本交互模式：

_REQ (Request)：请求，TTCN → SS，是命令。例：TTCN发送NR_SYSTEM_CTRL_REQ，命令SS配置一个NR小区。
_CNF (Confirm)：确认，SS → TTCN，是对命令的同步响应。例：SS在成功配置小区后，回复一个NR_SYSTEM_CTRL_CNF，告知TTCN“命令已完成”。
_IND (Indication)：指示，SS → TTCN，是SS对外部异步事件的主动上报。例：UE发送了一个上行信号，SS检测到后，主动发送一个NR_SYSTEM_IND，告知TTCN“我收到了来自UE的东西”。

Q3：规范第6.2.4节说NR ASP的定义在附录D，附录D是什么？它为什么那么重要？

A3：附录D（Annex D: TTCN-3 definitions）是本规范的形式化定义附录。它用纯粹的TTCN-3语言，定义了所有NR相关的ASP（如NR_SYSTEM_CTRL_REQ）以及这些ASP中所使用的所有数据结构（从高层的RRC消息结构到底层的MAC PDU结构）。它之所以重要，是因为它是实现标准化和互操作性的基石。不同厂商的测试仪表都必须根据附录D的定义来实现其系统适配层，这样才能保证任何遵循此规范编写的TTCN-3测试脚本都能在不同品牌的仪表上正确运行。它相当于测试语言的“官方头文件库”或“API文档”。

Q4：为什么需要MMI命令来改变一个GAP的配置，这不能在TTCN-3脚本里完成吗？

A4：这是一个很好的关于接口划分的问题。GAP（测量/监听间隙）的配置本身确实是通过RRC信令（即通过ASP触发）来完成的。然而，MMI命令"SET_MUSIM_UAI"中包含的GAP参数，其场景是Multi-USIM。在这种特殊场景下，一个USIM为了让另一个USIM有时间去监听网络，可能需要配置一些特殊的GAP。这种GAP的决策逻辑可能超出了单个协议一致性测试用例的范畴，更像是一种上层的、模拟特定终端行为的配置。因此，通过MMI接口提供这种高级配置，给予了测试更大的灵活性，使其可以模拟一些复杂的、与多卡调度策略相关的终端行为。

Q5：这些系统接口的定义是3GPP独有的吗？

A5：接口的概念和方法论是业界通用的，但具体实现是3GPP特有的。

ASP的概念，即用一种抽象原语来解耦测试逻辑和实现，源于ISO/IEC 9646等国际测试方法论标准。
TTCN-3语言本身是由ETSI（欧洲电信标准化协会）定义的，广泛应用于各种通信协议测试。
但是，NR_SYSTEM_CTRL_REQ这个ASP的具体名称、结构和字段，以及附录D中的所有TTCN-3类型定义，则是3GPP为5G NR测试专门设计和标准化的，是3GPP独有的。

51学通信

探索

深度解析 3GPP TS 38.523-3：6 System Interface (系统接口：与虚拟世界的对话语言)

深度解析 3GPP TS 38.523-3：6 System Interface (系统接口：与虚拟世界的对话语言)

前言：“Explorer-Sat”的控制面板与API

1. 人工干预的“遥控器”：6.1 Upper Tester Interface

1.1 MMI命令：测试的“超级工具箱”

1.2 AT命令：与终端模组的传统对话

2. 自动化的“机器语言”：6.2 Abstract System Primitives (ASP)

2.1 ASP的“三段论”：请求、确认与指示

2.2 ASP的定义来源：指向附录D的“路标”

2.3 场景故事：一次“寻呼”的ASP之旅

总结：掌握与虚拟世界对话的两种语言

FAQ

关系图谱

目录