51学通信

深度解析 3GPP TS 38.509：5.3 Test loop functions (Part 4 - Loop Mode C & E, 特殊任务：广播计数与车联通信)

22分钟阅读

深度解析 3GPP TS 38.509：5.3 Test loop functions (Part 4 - Loop Mode C & E, 特殊任务：广播计数与车联通信)

本文技术原理深度参考了3GPP TS 38.509 V18.0.0 (2025-06) Release 18规范中，关于“5.3.4.2A UE test loop mode C operation”和“5.3.4.3 UE test loop mode E operation”的核心章节。本文是“Test loop functions”系列的第四部分，我们将探索两个独特的“竞赛项目”，它们不再是传统的数据折返跑，而是考验UE特殊能力的全新挑战。

引言：从赛跑场到特战演练场

在前两篇关于回环测试功能的文章中，我们的主角“小五”手机已经成功通过了模式A的“百米冲刺”和模式B的“智能障碍赛”两项大考，证明了自己强大的基础数据传输能力和精细化的QoS处理能力。

“李工，模式A和B的测试日志我都整理完了，”工程师小王信心满满地说，“感觉已经掌握了数据回环测试的精髓。但后面的测试用例又出现了Mode C和Mode E，它们也是‘Test Loop Function’，难道也是某种形式的赛跑吗？”

“不，”资深专家李工摇了摇头，脸上露出神秘的微笑，“如果说A和B是田径赛，那么C和E就是‘特种作战演练’。回环（Loop）这个词在这里已经升华了，它不再仅仅指数据的折返，而是泛指一类由SS启动和停止的、在UE数据面进行的特殊任务。今天，我们将把‘小五’从田径场带到两个全新的演练场：

  1. Mode C - 广播听力大赛 (The Broadcast Listening Test): 在这个演练场，“小五”的任务不是回话，而是要证明自己能听清并记住公共广播里的每一条信息。
  2. Mode E - 团队协作演练 (The Team Coordination Exercise): 在这里，“小五”将扮演一名车联网世界里的“智能汽车”，它的任务不再是和基站对话，而是要和周围的“队友”进行高效的直接沟通。”

1. 5.3.4.2A UE test loop mode C operation - 广播听力大赛

第一个特殊任务，就是考验UE对5G MBS（多播广播业务）的接收能力。

1.1 5.3.4.2A.1 General - 核心任务：只听不说，默默计数

“对于广播，用户只能接收，不能发送。那么我们如何验证UE真的收到了广播数据呢？”李工抛出了问题。答案就在模式C的核心机制中。

UE test loop mode C provides counting of successfully received MBS Packets on one MRB (Multicast MRB or Broadcast MRB) while UE is operating in NR/5GC.

“划重点：counting，计数！”李工强调，“模式C的本质，不是回环，而是计数。考官SS向‘小五’发送广播数据包，‘小五’的任务就是成功接收一个，就在心里默默地把计数器加一。等测试结束后，考官再通过其他指令来询问‘小五’：‘你一共收到了多少个包？’通过核对这个计数值，就能精确判断‘小五’的广播接收性能。”

UE test loop mode C is mandatory for NR UEs supporting MBS.

“对于任何一款声称支持5G广播功能的手机，这都是一项强制性的毕业考试科目。”

规范接着列出了一系列复杂的MRB（多播/广播无线承载）配置，模式C必须在这些配置下都能正常工作。这包括了点对点（PTP）和点对多（PTM）传输，以及不同的RLC模式（UM非确认模式，AM确认模式）。这相当于考官设置了多种不同口音、不同频道的广播，来全面考察“小五”的收听能力。

接下来，我们看看这场“听力大赛”的考场是如何布置的。李工指向了规范中的功能框图。

参考规范中的 “Figure 5.3.4.2A.1-1: Model for UE test loop mode C on UE side for Multicast MRB” 和 “Figure 5.3.4.2A.1-2: Model for UE test loop mode C on UE side for Broadcast MRB”。

“这两张图清晰地展示了模式C的内部工作流，”李工解释道，“无论是组播还是广播，数据流从底层的NR PHY一路上传，经过MAC、RLC、PDCP，最终到达了**‘UE Test Loop Function’。但这次，等待它的不是‘折返点’，而是一个全新的模块——MBMS Packet Counter（MBS数据包计数器）**。”

数据流在这里戛然而-止，被计数器记录下来。这条单向的数据流，完美地模拟了广播业务的本质。

1.2 5.3.4.2A.2 Reception of MBS packets - “小五”的计数法则

当比赛开始后（收到CLOSE UE TEST LOOP for Mode C），“小五”是如何执行计数动作的呢？

For Broadcast MRB, upon receiving a MBS packet on the Broadcast MRB … with UE test loop mode C active the UE shall: 1> if UE test loop mode C is active; 2> increment MBMS_PACKET_COUNTER by 1:

“规则简单而明确，”李工说，“只要模式C处于激活状态，每当‘小五’在指定的广播信道（MTCH）上成功接收到一个MBS数据包，它就必须将内部的MBMS_PACKET_COUNTER变量加一。就像手里拿着一个计数器，来一个，按一下。”

这个简单的动作，是SS评估UE广播接收性能的唯一依据，其准确性至关重要。

1.3 5.3.4.2A.3 Release of RRC connection - 考验“后台收听”能力

模式C还有一个非常独特的考验，那就是在RRC连接释放后的行为。

When the RRC connection is released then the UE shall: 1> if UE test loop mode C is active for Broadcast MRB: 2> keep UE test loop mode C active.

“这是一个非常关键的测试点，”李工解释道，“广播业务，比如紧急警报、赛事实况，是一种公共服务。用户即使没有在打电话或上网（处于RRC IDLE或INACTIVE状态），也应该能收到。这条规则就是要验证‘小五’的这种‘后台收听’能力。”

“在测试中，考官SS会先建立一个RRC连接，激活模式C让‘小五’开始计数。然后，SS会故意释放掉这个RRC连接，模拟用户结束通话的场景。此时，‘小五’决不能停止它的计数行为，而是要继续在后台默默地接收和统计广播包。这考验了‘小五’的状态机管理能力，确保了测试功能不会因为RRC状态的改变而意外终止。”

2. 5.3.4.3 UE test loop mode E operation - 团队协作演练

完成了单人的听力大赛，“小五”即将迎来更复杂的团队项目——NR Sidelink通信测试。在这里，它的身份从一个“听众”，转变为一个“车联网终端”。

2.1 5.3.4.3.0 General - 双重身份：信号源与监听站

“Sidelink，或称PC5接口通信，是UE与UE之间的直接通信，不一定需要通过基站中转。因此，测试模式也必须彻底改变。”李工说。

UE test loop mode E provides means for either transmit or receive of SDAP SDUs for PC5 QoS Flows while UE is operating in NR sidelink…

“模式E赋予了‘小五’双重身份。考官可以通过CLOSE UE TEST LOOP消息中的参数，命令‘小五’扮演两个角色之一：”

  1. 信号源 (Transmit): “小五”将变身为一个Sidelink交通流发生器，持续不断地对外发送标准化的数据包，供其他待测设备接收。
  2. 监听站 (Receive): “小五”将变身为一个Sidelink分析仪，负责监听空中的Sidelink信道，并对成功接收到的数据包进行精细化的分类和计数。

UE test loop mode E is mandatory to all 5GS UEs supporting NR sidelink.

“对于所有支持V2X等功能的终端，这项演练也是强制性的。”

规范同样为模式E绘制了复杂的架构图，我们来解读其核心。参考 Figure 5.3.4.3.0-1 到 Figure 5.3.4.3.0-4。

“这四张图覆盖了‘接收/发送’和‘网内/网外’两大维度。但核心模块只有两个：”

  • 当扮演监听站（Receive）时： 核心是 NR Sidelink Data Packet Counter。注意，这里的计数器比模式C的要复杂得多，它能区分不同Sidelink信道（如STCH, PSCCH, PSSCH）的数据包。
  • 当扮演信号源（Transmit）时： 核心是 LB Entity。但这里的LB Entity不再是回环数据，而是作为一个**“虚拟应用”，主动生成并触发**Sidelink数据的发送。

2.2 5.3.4.3.1 Receive or Transmit NR sidelink Communication - “小五”的特战手册

这一节是模式E最核心的逻辑，定义了“小五”在这两种身份下的具体行动指南。CLOSE UE TEST LOOP消息会设置一个内部变量TEST_LOOP_MODE_E_TRIGGER，来决定“小五”的具体任务。

任务一：扮演监听站 (TRIGGER is RECEIVE)

2> if TEST_LOOP_MODE_E_TRIGGER is set to RECEIVE; 3> upon successful reception of a SDAP SDU for NR sidelink communication data packet: … increment STCH_PACKET_COUNTER… 3> upon successful reception of a PSCCH PHY transport block… … increment PSCCH_PACKET_COUNTER… 3> upon successful reception of a PSSCH PHY transport block… … increment PSSCH_PACKET_COUNTER…

“当接到‘监听’指令后，‘小五’会启动它那套精密的Sidelink分析系统。”李工解释道，“它不再是只用一个总计数器，而是为Sidelink的不同逻辑和物理信道都配备了专门的计数器：”

  • STCH (Sidelink Traffic Channel) Counter: 统计成功解出的最终业务数据包（SDAP SDU）的数量。
  • PSCCH (Physical Sidelink Control Channel) Counter: 统计物理层控制信息（SCI）的数量，这关系到能否正确调度资源。
  • PSSCH (Physical Sidelink Shared Channel) Counter: 统计物理层数据块的数量，这反映了底层的传输成功率。

“这种分层计数的机制，让考官可以极其精确地定位问题。比如，如果PSSCH计数正常，但STCH计数为零，那问题很可能出在PDCP或RLC的解包环节，而不是物理层接收。”

任务二：扮演信号源 (TRIGGER is TRANSMIT)

2> else if TEST_LOOP_MODE_E_TRIGGER is set to TRANSMIT; 3> consider that a request from upper layers to transmit the packet for V2X service over PC5 has been received.

“这句‘consider that a request… has been received’是关键！它意味着测试逻辑模拟了一个来自上层应用的发送请求。”李工强调，“‘小五’内部的LB Entity现在开始‘无中生有’。”

它会做什么呢？

  1. 凭空造包： 它会创建一个标准化的SDAP SDU数据包。这个包的内容在规范中有严格定义。

    Table 5.3.4.3.1-1: SDAP SDU payload contents for NR sidelink communication transmit operation in UE test loop mode E

    ParameterValue
    Size (N)300 bytes
    Payload00…00

    李工将表格绘制在白板上：“你看，规则很简单，就是一个大小为300字节、内容全为0的‘哑包’（dummy packet）。使用标准化的哑包，保证了所有‘信号源’UE产生的流量都是一致的，确保了测试的可重复性。”

  2. 持续发送：

    …provide it as the input of PQF handling … for transmission in every PSSCH duration according to subclause 5.22.1.1 of TS 38.321…

    “‘小五’会像机关枪一样，在每一个可用的Sidelink发送机会（PSSCH duration）上，都将这个300字节的哑包发射出去。这将产生持续、饱和的Sidelink流量，对于测试接收端UE的性能极限至关重要。”

总结：超越回环，拥抱多样化测试

“今天，我们见证了‘小五’的两场精彩的特殊任务演练，彻底拓展了我们对‘Test Loop Function’的理解。”李工总结道。

我们掌握了两个全新模式的核心：

  1. Mode C (广播计数): 其核心不是回环，而是通过计数来验证UE对单向MBS业务的接收能力。我们还了解了它在RRC连接释放后仍需保持工作的独特鲁棒性要求。
  2. Mode E (Sidelink收发): 它赋予了UE信号源和监听站的双重身份。作为监听站，它能对Sidelink的不同信道进行分层精细化计数；作为信号源，它能模拟应用请求，持续发送标准化的哑包，产生饱和测试流量。
  3. 统一的控制框架： 尽管功能迥异，Mode C和Mode E依然被统一在Test Loop Function的框架下，通过相同的Close/Open UE Test Loop指令进行启停控制，体现了规范设计的高度一致性和抽象性。

“至此，‘小五’已经完成了所有与数据包内容处理相关的核心测试项目。从‘裸跑’到‘智能调度’，再到‘广播收听’和‘团队通信’，它证明了自己全面的数据面能力。”李工眼中闪烁着光芒，“但毕业大考还未结束。接下来，我们将进入一个全新的领域，不再关注数据包本身，而是开始直接操控UE的‘眼睛’和‘手臂’——我们将学习波束锁定（UBF）和功率上报等更接近物理层的特殊功能。那将是另一场精彩的考验。”

FAQ环节

Q1：SS如何获取UE在模式C和模式E下统计的计数值？ A1：这是一个非常好的问题，体现了测试流程的完整性。本章只定义了UE如何进行“计数”，但并没有定义如何“汇报”。计数的汇报是由后续章节定义的其他独立功能完成的。例如，对于模式E（Sidelink），规范在5.9节定义了“NR Sidelink Packet Counter reporting procedure”。在Close Loop让UE开始计数一段时间后，SS会再发送一条UE TEST LOOP NR SIDELink COUNTER REQUEST消息，UE收到后，就会将内部存储的STCH、PSCCH、PSSCH计数值打包在RESPONSE消息中回复给SS。模式C的汇报机制与此类似。

Q2：在模式E的Transmit模式下，为什么需要由测试逻辑来“模拟”应用请求，而不是直接在UE上运行一个真实的V2X App？ A2：主要原因是为了测试的纯粹性、稳定性和可重复性。

  • 纯粹性： 运行真实App会引入操作系统调度、进程优先级、CPU负载等大量不可控因素，我们无法确定测试出的性能瓶颈是来自协议栈还是App本身。模式E将测试与上层应用完全隔离，只关注协议栈的行为。
  • 稳定性与可重复性： 真实App产生的流量是动态变化的，无法保证每次测试的流量模型都完全一致。而模式E发送的是固定大小、固定内容的哑包，并且是在每个可用机会上饱和发送，创造了一个最严苛且完全可重复的测试条件。

Q3：模式C中为什么要区分Multicast MRB和Broadcast MRB？它们在测试上有什么不同？ A3：两者在业务模型和资源分配上有所不同，因此需要分开测试。

  • Broadcast MRB (广播) 通常是小区级别的，面向该小区所有用户，UE即使在RRC IDLE/INACTIVE状态也能接收。测试重点是验证这种公共信道的接收能力，以及在RRC状态切换时的行为稳定性（如5.3.4.2A.3节所述）。
  • Multicast MRB (组播) 通常是面向特定用户组的，需要UE先“加入”该组播组，并且通常要求UE处于RRC CONNECTED状态。测试重点是验证UE能否正确地根据组播配置，在专用或共享信道上接收属于自己组的数据。

Q4：模式E的架构图中提到了“PC5-only operation”，这是什么场景？ A4：“PC5-only operation”指的是**网络外（out-of-coverage）**的Sidelink通信场景，也就是我们常说的“直通模式”。在这种模式下，UE之间直接通信，完全不依赖任何基站的覆盖和调度。这是V2X（车联网）安全应用（如碰撞预警）的关键场景。模式E必须支持这种场景的测试，通常通过AT指令（如+CCUTLE）从物理接口启动，因为此时UE无法通过空口收到SS的TMC消息。

Q5：这些特殊的“计数”和“触发发送”功能，在手机出厂后会移除吗？ A5：不会。这些功能是UE协议栈固件的一部分。它们被设计为只能通过经过安全验证的、来自SS的特定TMC消息或受保护的AT指令来激活。在正常的用户使用场景中，这些逻辑永远不会被触发，对手机的功耗、性能和安全没有任何影响。它们就像是隐藏在系统深处的“诊断端口”，只有在专业的“实验室”环境下，用特定的“钥匙”才能打开。

关系图谱