深度解析 3GPP TS 38.509：5.3 Test loop functions (Part 1 - “闭环”与“开环”的控制奥秘)

本文技术原理深度参考了3GPP TS 38.509 V18.0.0 (2025-06) Release 18规范中，关于“5.3.1 General”、“5.3.2 Close UE test loop”以及“5.3.3 Open UE test loop”的核心章节。本文是“Test loop functions”系列的第一部分，旨在为读者彻底厘清数据回环测试的顶层控制逻辑——“闭环”与“开环”命令的深层含义与工作机制。

引言：跑道已就位，如何吹响发令枪？

在上一篇文章中，我们见证了代号为“小五”的5G手机，在系统仿真器（SS）这位严苛考官的指令下，通过“Activate UE test mode”程序，成功搭建起了用于毕业大考的“专用测试跑道”（Test Bearers）。跑道已经灯火通明，万事俱备。

“李工，”工程师小王紧盯着SS的操作界面，提出了新的疑问，“跑道是建好了，但现在上面空空如也，数据这个‘运动员’还没开始跑呢。考官到底是如何下达‘开始跑！’和‘暂停！’的命令的？这和我们之前学的‘搭建跑道’（Activate）和‘拆除跑道’（Deactivate）是一回事吗？”

“问到了点子上！”资深专家李工赞许道，“这是初学者最容易混淆的地方。‘搭建/拆除跑道’是战略层面的准备和收尾，而我们今天要学习的‘闭环/开环’，则是战术层面的‘开始/停止’指令。这正是整个5.3节的核心——回环测试功能的精髓所在。由于内容极其丰富，我们将分几部分来精讲。今天，作为Part 1，我们先来揭示控制这名‘运动员’上场和下场的命令奥秘。”

1. 5.3.1 General - “闭环”与“开环”的哲学

李工首先指向了5.3.1节，这里定义了整个回环测试功能的基本操作理念。

Before a loop functionality can be exercised, the test loop needs to be closed; this is to be understood as the UE being instructed to start looping back received data packets. When looping back received data packets is not any longer required the loop should be re-opened; opening of a loop does not change the type of bearer being established by the UE test mode activation function (subclause 5.2.2).

“这段话，就是我们理解‘闭环’与‘开环’的‘心法’。”李工逐句剖析：

• “闭环” (Close the loop): 它的本质是一个**“开始”**指令。考官SS向“小五”发送“闭环”命令，就如同裁判员吹响了发令枪。“小五”接收到后，就立刻开始执行“回环数据包”这个动作。数据这位“运动员”便开始在“专用跑道”上飞奔起来。
• “开环” (Open the loop): 它的本质是一个**“停止”**指令。考官SS发送“开环”命令，则如同裁判员吹响了暂停的哨声。“小五”会立即停止回环数据的行为。
• 关键区别： 最重要的一点是，“开环”并不会拆除已经建立好的测试承载（专用跑道）。跑道还在，只是运动员暂时下场休息了。这与“Deactivate UE test mode”（拆除跑道）有着本质区别。

“这个设计非常精妙，”李工补充道，“在复杂的测试场景中，我们可能需要多次启动和停止数据传输，来验证不同网络配置下的性能。如果每次停止都必须‘拆跑道’再‘建跑道’，那效率就太低了。‘开环/闭环’机制提供了一种轻量级的、快速的启停控制，极大地提升了测试灵活性。”

1.1 指令的“一箭双雕”：不止于回环

更有趣的是，3GPP的专家们还将“闭环/开环”这对指令的功能进行了扩展。

To limit the number of special test functions, the concept of closing and opening a loop is also used as instruction to the UE to initiate/terminate other actions. An example of this is counting the received packets and reporting the number of received packets back to the SS…

“这是规范设计中的‘优雅’之处。”李工解释道，“为了避免定义过多的TMC消息，规范巧妙地复用了‘闭环/开环’这对指令。当测试科目不是‘数据回环短跑’，而是‘MBS广播接收计数’时，‘闭环’指令就变成了‘开始计数！’，而‘开环’指令则相应地变成了‘停止计数！’。”

这种概念上的抽象和复用，体现了协议设计的智慧，用最少的指令集覆盖了尽可能多的测试场景。规范在5.3.1节的末尾，也清晰地罗列了UE测试回环功能旨在覆盖的测试目标，包括：

• NR收发机测试
• NR Layer 2 (MAC, RLC, PDCP, SDAP) 和数据承载测试
• NR Sidelink Layer 2 和数据承载测试
• MBS 广播承载测试
• 5GC 和 NR Layer 3 跨流程数据传输验证
• 5GC NAS 用户面测试 等等。

这些丰富的测试目标，都将由我们后续分节拆解的Loop Mode A, B, C, E 等具体的回环模式来承载和实现。

2. 5.3.2 Close UE test loop - 吹响“开跑”的哨声

现在，我们聚焦于“发令枪”本身——CLOSE UE TEST LOOP这条TMC消息。

2.1 5.3.2.0 General - 沿用与革新

和激活流程一样，“闭环”操作也大量继承了4G的经验。

Same as TS 36.509, subclause 5.4.2 with the following exceptions:

规范再次使用了“继承+例外”的模式。其中的例外条款，如“E-UTRA等同于NR”、“V2X等同于NR sidelink”、“EPS bearers等同于5GS QoS flows”等，与我们在5.2节学到的如出一辙，这里不再赘述。这再次证明了5G测试规范是在成熟的4G体系上平滑演进而来。

2.2 5.3.2.1 Reception of CLOSE UE TEST LOOP message by the UE - “小五”的决策逻辑

这是本章的第一个“硬核”知识点。当“小五”在其逻辑测试接口上收到了CLOSE UE TEST LOOP这条TMC消息后，它内部的TMC实体会如何反应？规范用一段严谨的伪代码给出了答案。我们将其转换为“小五”的内心独白来解读。

场景一：考官要进行“广播听力测试”（Test Loop Mode C）

“小五”收到闭环指令后，首先会检查指令中是否指定了模式C。

1> else if UE test loop mode C has been selected;

“好的，考官要考Mode C。我得先进行一系列‘安全检查’：”

2> if no MBS radio bearer is established or if the UE test mode is not active; or 2> if UE test loop mode A or UE test loop mode B operation is already closed on one or more data radio bearers;

“检查项一：‘广播专用教室’（MBS radio bearer）准备好了吗？如果连教室都没有，测试无法开始。检查项二：我现在处于‘考试状态’（UE test mode active）吗？如果不是，那这个指令就是无效的。检查项三：有没有其他同学正在进行‘短跑’或‘障碍跑’测试（Mode A/B is closed）？场地必须是专用的，不能同时进行两种测试。”

如果以上任何一项检查不通过，那么：

3> the UE behaviour is unspecified.

“‘行为未定义’，意味着考官的指令不合规，我可以选择忽略，或者上报一个错误。总之，测试不能正常进行。”

如果所有安全检查都通过了，“小五”就开始执行正式动作：

2> otherwise: 3> set TEST_LOOP_MODE_C_ACTIVE to TRUE 3> set state variable MBMS_PACKET_COUNTER to zero; 3> perform the UE actions for UE Test Loop Mode C operation as specified in subclause 5.3.4.2A and 3> send CLOSE UE TEST LOOP COMPLETE message…

“太棒了，现在我将：

1. 在脑子里将‘Mode C状态’标记为‘激活’。
2. 将我的‘MBS数据包计数器’清零，准备从头开始数。
3. 调动我的耳朵和大脑（执行5.3.4.2A中定义的具体接收和计数行为），开始认真收听广播并计数。
4. 最重要的一步，立刻向考官回复一条CLOSE UE TEST LOOP COMPLETE消息，告诉他：‘报告考官，我已准备就绪，开始计数！’。这个‘握手’至关重要，它标志着测试的正式开始。”

场景二：考官要进行“车联网通信测试”（Test Loop Mode E）

逻辑与模式C类似，但细节更复杂。

1> else if UE test loop mode E has been selected;

“好的，是Mode E。同样需要进行安全检查，比如不能有Mode A/B同时在进行，并且我的‘身份证’（USIM）里关于Sidelink的预配置参数必须能读出来。”

检查通过后，“小五”会解析CLOSE UE TEST LOOP消息中专门为Mode E准备的参数。

3> if the E0 bit in Communication Transmit or Receive parameter in UE test loop mode E setup IE is set as zero; 4> set TEST_LOOP_MODE_E_TRIGGER to RECEIVE … 3> if the E0 bit … is set as one; 4> … 5> set TEST_LOOP_MODE_E_TRIGGER to TRANSMIT;

“考官在指令里给了我一个关键的‘E0比特’。如果它是0，就意味着我的任务是**‘接收’，我需要扮演一个‘观察员’的角色，去监听并统计其他‘车辆’发来的Sidelink数据包。如果它是1，那我的任务就是‘发送’**，我需要扮演一个‘信号源’，主动向外发送Sidelink数据包。这个参数决定了我在测试中的角色。”

无论是接收还是发送，最后一步都是相同的：

3> send CLOSE UE TEST LOOP COMPLETE message…

“角色确定后，我将立即启动相应的收/发程序，并向考官回复‘COMPLETE’消息，告知他Sidelink测试已正式启动。”

2.3 5.3.2.2 Reception of AT Command +CCUTLE by the UE - B计划：物理接口的指令

有时候，空口TMC消息这条路走不通。比如，要测试“小五”在没有网络覆盖时的Sidelink通信能力，它根本连接不上SS，也就无法收到TMC消息。这时怎么办？EMMI接口和AT指令就派上了用场。

Upon receiving the AT Command +CCUTLE=<status=0>[,[,,,<monitor_list>,<sl_mimo>]] the UE shall:

“考官现在通过我的USB调试接口（EMMI）给我发送了一条+CCUTLE的AT指令。这就像是考官用一根有线电话直接打给了我。”

这条AT指令的参数，如<direction>，就等同于TMC消息中的“E0比特”，用于指示“小五”是该接收还是该发送。后续的逻辑与处理TMC消息时完全一致。

这个双重控制机制（空口TMC + 物理接口AT指令）确保了几乎所有场景下的测试可达性，体现了测试规范的完备性。

3. 5.3.3 Open UE test loop - “中场休息”的指令

一场紧张的测试过后，可能需要进入“中场休息”时间。

Same as TS 36.509, subclause 5.4.5 with the exceptions:

“开环”指令OPEN UE TEST LOOP同样继承自4G规范。当“小五”收到这条指令时，它会：

• 停止当前的回环或计数行为。
• 保持测试承载（Test Bearers）不释放。

“这声哨响，意味着‘小五’可以暂停跑步或计数，但‘专用跑道’依然保留着。考官可以在这个‘休息时间’里调整SS的配置，比如改变下行信号的功率，或者准备下一轮测试的数据。准备就绪后，只需再次发送一条CLOSE UE TEST LOOP指令，‘小五’就能在原有的跑道上立即恢复测试，无需经历耗时的PDU会话重建和承载建立过程。”

总结：精确到毫秒的启停控制

今天，我们聚焦于回环测试的“控制面”，详细学习了如何通过“闭环”和“开环”指令，像指挥家一样精确地控制数据“运动员”的起跑和暂停。

我们掌握了以下核心知识点：

1. 概念辨析： 彻底分清了**Activate（建跑道）、Deactivate（拆跑道）、Close Loop（开始跑）和Open Loop**（暂停跑）这四个指令的本质区别。
2. 指令复用： 理解了Close/Open指令不仅用于控制数据回环，还被巧妙地复用于启动/停止计数等其他测试行为，体现了规范设计的简洁性。
3. 严谨的执行逻辑： 通过对规范伪代码的解读，我们掌握了UE在收到Close Loop指令后，必须先进行一系列严格的“安全检查”，才能执行真正的测试动作，并最终通过COMPLETE消息与SS进行“握手同步”。
4. 双重控制路径： 了解了除了空口的TMC消息，SS还可以通过物理EMMI接口和AT指令来控制UE，确保了在无网络覆盖等特殊场景下的测试能力。

“小五”的毕业大考，现在已经完成了入场、建跑道和发令枪的所有准备工作。从下一篇文章开始，我们将正式进入“比赛环节”，详细拆解不同的“竞赛项目”——UE Test Loop Mode A、B、C、E，看看数据这位运动员在不同的跑道上，究竟是如何飞奔的。

FAQ环节

Q1：Activate UE Test Mode和Close UE Test Loop这两个命令，到底有什么本质区别？ A1：这是最关键也最容易混淆的概念。可以类比建房子：

• Activate UE Test Mode 相当于**“打地基、建框架”。它通过NAS信令建立起一个专用的、从网络端到UE协议栈内部（如PDCP层）的基础数据通道（测试承载）**。这个过程完成后，只是有了一条“路”，但路上还没有“车”在跑。
• Close UE Test Loop 相当于**“剪彩、通车”。它通过TMC消息命令UE开始使用**这条已经建好的路。具体的使用方式可以是让数据在这条路上“来回跑”（回环），或者在这条路上“统计车流量”（计数）。

Q2：为什么会有TMC消息和AT指令两种方式来闭环测试（Close Loop）？ A2：这是为了覆盖不同的测试场景，保证测试的完备性。

• TMC消息是标准方式，通过空口传输，适用于所有**网络内（in-coverage）**的测试场景，即UE能正常与SS通信。
• AT指令是通过物理接口（EMMI，如USB）传输，是TMC消息的补充。它专门用于**网络外（out-of-coverage）**的测试场景，例如测试NR Sidelink在没有基站覆盖下的直通通信能力。此时UE无法收到空口消息，只能通过有线方式接收测试指令。

Q3：规范中提到的“UE behaviour is unspecified”（UE行为未定义）是什么意思？这对UE实现有什么影响？ A3：“行为未定义”意味着3GPP规范没有对UE在这种异常情况下的行为做出强制规定。这通常发生在UE收到了一个逻辑上不合理或与当前状态冲突的指令时（例如，在没有建立MBS承载时收到了闭环Mode C的指令）。对于UE开发者来说，这给予了一定的自由度，但通常最佳实践是：1. 忽略该非法指令；2. 保持当前状态不变；3. （可选）通过某种机制向测试系统上报一个错误或失败指示。最重要的是，UE不能因为这个未定义的行为而崩溃或进入不稳定的状态。

Q4：既然有了Deactivate UE Test Mode可以终止测试，为什么还需要Open UE Test Loop？ A4：Open UE Test Loop提供了一种更高效的**“暂停”机制。Deactivate是彻底的“终止”，它会拆除整个测试承载，释放所有相关网络资源，相当于推倒了房子。如果想再次测试，就需要重新走一遍PDU会话建立和承载建立的完整流程，非常耗时。而Open Loop只是“暂停”**了数据活动，承载和PDU会话等“房子框架”都还保留着，SS可以在此期间快速修改测试参数，然后用一个Close Loop指令就能瞬间恢复测试。在需要连续执行多个但配置略有不同的测试项时，这种“暂停-调整-继续”的模式能节省大量时间。

Q5：为什么Close Mode C/E的操作是“计数”而不是“回环数据”？ A5：这是因为Test Loop Functions这个术语是一个广义的概念。虽然字面意思是“回环”，但在TS 38.509中，它被抽象为一类**“需要SS启动和停止的、在UE数据面或其附近进行操作”**的测试功能集合。对于Mode A/B，这个操作是“回环”。但对于MBS（Mode C），其核心功能是接收和呈现，测试的重点是验证UE能否成功接收，所以操作就变成了“计数”。对于Sidelink（Mode E），操作可以是“触发发送”或“接收计数”。规范将这些功能统一归入“Test Loop”框架下，并复用Close/Open这对控制信令，是一种高效、简洁的协议设计选择。