51学通信

深度解析 3GPP TS 38.523-3：5.1.2 EN-DC Layer 2 (NSA组网下的层二协议测试模型)

23分钟阅读

深度解析 3GPP TS 38.523-3：5.1.2 EN-DC Layer 2 (NSA组网下的层二协议测试模型)

本文技术原理深度参考了3GPP TS 38.523-3 V18.2.0 (2025-03) Release 18规范中，关于“5.1.2 EN-DC Layer 2”的核心章节，旨在为读者深入剖析在NSA（非独立组网）模式下，如何对UE的数据链路层（PDCP, RLC, MAC）进行精确、隔离和自动化的协议一致性测试。

前言：“Pioneer-5G”深入“执行层” - 层二协议大考

在上一篇文章中，我们的主角，测试工程师李工，已经成功利用TS 38.523-3定义的层三（L3）测试模型，对“Pioneer-5G”手机在EN-DC（NSA）模式下的RRC信令流程进行了全面的“体检”。他验证了手机作为网络中的一个“智慧大脑”，能够正确理解并执行网络下发的各种高级指令，如SCG添加、承载模式切换等。

现在，李工的测试任务将从“指挥中心”（L3/RRC）下沉到“执行引擎”——层二（L2）数据链路层。如果说L3测试关注的是“做什么决策”，那么L2测试则聚焦于“如何高效、可靠地执行数据传输任务”。这一层包括了三个至关重要的协议实体：

  • PDCP (Packet Data Convergence Protocol)：数据的“安全官与整形师”，负责加密、完整性保护、头压缩以及在双连接下的数据复制与重排序。
  • RLC (Radio Link Control)：数据的“打包与重传专家”，负责将大的数据包分片、重组，并通过ARQ机制确保可靠传输。
  • MAC (Medium Access Control)：空口资源的“交通警察”，负责逻辑信道的复用、HARQ处理以及响应调度指令。

李工深知，L2协议的性能直接决定了用户最终的上网体验。任何一个微小的实现偏差，都可能导致数据传输中断、速率下降或时延增加。因此，对L2协议的测试必须更加精细和严苛。与L3测试不同，L2测试的核心不再是复杂的信令流程交互，而是要在一个高度可控的环境下，验证协议实体处理数据的每一个细节。为此，TS 38.523-3引入了一种关键的测试技术——“测试环回模式”（Test Loop Mode）。

本篇文章，我们将跟随李工，深入5.1.2章节，逐一剖析PDCP、RLC、MAC三大协议的EN-DC测试模型，看测试规范是如何通过巧妙的设计，将这些协议实体从复杂的协议栈中“剥离”出来，进行“手术刀”般精准的验证。

1. 数据的守门员：5.1.2.1 PDCP (分组数据汇聚协议) 测试

PDCP层是L2的最高层，直接面向用户数据。在EN-DC场景下，它除了传统的安全和压缩功能，还肩负着数据复制（Duplication）这一关键任务。

1.1 核心理念：测试环回模式 (Test Loop Mode)

为了能够纯粹地测试L2协议，我们需要一种方法来生成可控的数据流，并能方便地验证UE处理后的结果，同时绕开复杂的上层应用和IP协议栈。为此，规范引入了测试环回模式。

The UE is configured in Test Loop Mode, to loop back the user domain data above PDCP layer. On UE side Ciphering is enabled as null algorithm and header compression is not configured.

这段话揭示了PDCP测试的核心设置：

  • UE侧：被配置进入“测试环回模式”。这就像在UE协议栈的PDCP层顶部安装了一个“U型管”，所有从网络侧接收到的、经过PDCP层处理（解密、重排序等）后的数据，不再递交给上层IP协议栈，而是立即被“环回”，重新进入下行PDCP协议栈，准备发送回网络。
  • 安全与压缩：为了便于观察和判决，测试中通常使用“空加密算法”（null algorithm），相当于关闭了实际的加解密，但安全流程本身依然被激活。同时，头压缩功能被关闭。

通过这种方式，李工的测试系统（SS）发送一个已知的数据包给“Pioneer-5G”，手机处理后会原封不动地再发回来。李工只需比对发送和接收的数据包是否完全一致，就能判断UE的PDCP层是否正确地完成了重排序、去重等操作。

1.2 PDCP测试场景：从分离到复制

1.2.1 单NR载波下的测试 (5.1.2.1.1 Single NR carrier)

此场景主要验证在单个NR辅小区下，SCG承载和分离承载（Split DRB）的PDCP功能。

  • SCG承载测试 (Figure 5.1.2.1.1-1: Test model for EN-DC PDCP testing (MCG and SCG))

    • 架构解读：规范原文中的“Figure 5.1.2.1.1-1”展示了一个标准的SCG数据承载的PDCP测试模型。在UE侧，环回路径建立在NR PDCP实体之上。在SS侧，NR PTC（模拟gNB）的PDCP被配置为一种“特殊模式”。

    The PDCP is configured in a special mode, where SS does not add any PCDP headers in DL and/or not remove any PDCP headers in UL directions respectively at DRB port on the NR PTC. The TTCN maintains sequence numbers and state variables for the PDCP layer.

    • 深度解析：这意味着SS侧的PDCP实体本身成了一个“傀儡”，它不再自动添加或移除PDCP头。真正的PDCP逻辑（如序列号的维护）被上移到了TTCN-3脚本中。TTCN脚本会生成一个包含了完整PDCP头的“伪PDCP SDU”，交给SS的PDCP层，后者仅作透传。这样做的好处是，测试脚本可以完全控制发送给UE的每一个PDCP PDU的每一个比特，从而能够模拟出各种复杂的异常场景，如乱序、丢包等。

  • 分离承载测试 (Figure 5.1.2.1.1-2: Test model for EN-DC PDCP testing (MCG and split DRB))

    • 架构解读：这张图展示了对分离承载（Split DRB）的测试。UE侧的环回点依然在唯一的PDCP实体之上，但该实体现在同时管理着来自LTE和NR的两条RLC链路。SS侧的EUTRA PTC（模拟eNB）中的PDCP实体被配置为“代理模式”（Proxy mode）。
    • 场景故事：李工正在验证“Pioneer-5G”在分离承载下的重排序能力。TTCN脚本生成了一系列PDCP PDU，SN序列为1, 2, 3, 4, 5。脚本控制SS将SN=1, 3, 5的数据包通过LTE链路发送，将SN=2, 4的数据包通过NR链路发送，并且故意让NR链路的数据包先于LTE的到达手机。此时，“Pioneer-5G”的PDCP层必须能够缓存先到的SN=2, 4，等待SN=1, 3到达后，再按1, 2, 3, 4, 5的正确顺序环回数据。SS接收到环回的数据并上报给TTCN，脚本检查序列号的顺序，从而完成判决。

1.2.2 NR载波聚合与数据复制 (5.1.2.1.2 NR carrier aggregation)

这是EN-DC中提升可靠性的关键技术。PDCP层将同一个数据包复制多份，通过不同的载波（例如，NR的PSCell和SCell）同时发送，接收端只要成功收到一份即可。

  • 架构解读：规范中的“Figure 5.1.2.1.2-1: Test model for EN-DC with NR CA duplication PDCP testing (MCG and SCG)”展示了该模型。在SS侧，一个PDCP实体连接了两个并行的NR RLC/MAC/PHY协议栈，分别对应PSCell和SCell。

The SS configures DRB j and DRB j+1 on the PSCell, every DRB is connected to an RLC entity. The RLC entity configured on DRB j is linked to the MAC entity on the PSCell, the RLC entity configured on DRB j+1 is linked to the MAC entity on the SCell.

  • 场景故事：李工这次要模拟一个对可靠性要求极高的自动驾驶场景，“Pioneer-5G”作为车载通信单元，需要接收关键的协同驾驶信息。SS通过RRC信令为UE配置了PDCP**数据复制（Duplication）**功能。TTCN脚本发送一个SN=1的PDU，SS的PDCP层将其复制，一份通过PSCell发送，另一份通过SCell发送。李工在测试中，可以人为地在一个载波上注入干扰，模拟该路径的丢包。只要“Pioneer-5G”能从另一条路径上正确接收到该PDU，并最终只向上层递交（并环回）一份数据，就证明其PDCP的复制和去重功能是正常的。

2. 数据的裁缝与快递：5.1.2.2 RLC (无线链路控制) 测试

RLC层位于PDCP之下，负责数据的分段、重组以及通过ARQ机制保证可靠性（仅限AM模式）。RLC测试的核心是验证其分段/重组逻辑和状态机的正确性。

  • 架构解读：“Figure 5.1.2.2-1: Test model for EN-DC RLC AM/UM testing”展示了RLC测试模型。为了隔离RLC，SS侧的协议栈配置发生了关键变化：

    On the SS side, L1 and MAC are configured in the normal way. The RLC of the SCG DRBs is configured in transparent mode. … There is no PDCP configured on SS NR PTC side. The ports are directly above RLC.

    • 深度解析：SS侧的RLC被配置为透明模式（Transparent Mode, TM），它本身不进行任何分段或添加RLC头的操作。并且，SS侧没有PDCP层。TTCN脚本的端口直接对接在RLC层之上。这意味着TTCN脚本必须生成最终的RLC PDU，包括它自己构造的RLC头和“伪”PDCP头。SS的RLC层只负责将这个“成品”PDU原样传递给MAC层。

  • 场景故事：李工要测试“Pioneer-5G”在RLC AM（确认模式）下的轮询（Polling）和状态报告机制。TTCN脚本构造并发送了一系列RLC数据PDU，并在最后一个PDU中将RLC头的“Poll bit”置为1。根据TS 38.322，UE的RLC实体在收到Poll请求后，必须尽快回送一个RLC STATUS PDU，报告其当前的接收窗口状态（哪些PDU收到了，哪些还没收到）。“Pioneer-5G”正确响应了，SS的RLC层（处于TM模式）将收到的STATUS PDU透传给TTCN，脚本解析该PDU的内容，验证其格式和报告的SN号是否符合预期，从而完成测试。

3. 空口交通调度员：5.1.2.3 MAC (媒体接入控制) 测试

MAC层是L2的最底层，直接与物理层打交道，负责执行HARQ流程和复用/解复用来自不同RLC实体的数据。

  • 架构解读：“Figure 5.1.2.3.1-1: Test model for EN-DC MAC testing”展示了MAC测试模型。为了隔离MAC层，SS侧的协议栈配置得更为“极端”：

    On DRBs the NR RLC is configured in transparent mode. … There is no NR PDCP configured on SS side. … NR MAC is configured in a special mode, where it does not add any MAC headers in DL and /or not remove any MAC headers in UL directions… In this case, the TTCN shall provide the final MAC PDU, including padding.

    • 深度解析：不仅PDCP不存在，RLC也处于TM模式，甚至连MAC层都处于一种特殊的“半透明”模式。对于下行，TTCN现在需要生成包含了完整MAC子头、RLC头、伪PDCP头、数据载荷甚至填充字节（Padding）的最终MAC PDU。SS的MAC层只负责执行最基本的HARQ流程，然后将这个PDU交给物理层。

  • MAC测试的两种模式：

    1. DL/UL header-transparent mode: no header addition in DL and no header removal in UL.
    2. DL only header-transparent mode: no header addition in DL; UL NR MAC is configured in normal mode to remove MAC header and de-multiplex the MAC SDUs…

    这两种模式提供了不同的测试深度：

    1. 完全透明模式：SS的MAC层对上下行都不解析MAC头。TTCN发送完整的MAC PDU，也期望收到完整的UL MAC PDU。这种模式主要用于测试HARQ等基本功能。
    2. 下行透明模式：SS的MAC层在下行依然是透明的，但在上行方向，它会工作在正常模式，负责解析UE发来的MAC PDU的头部，根据逻辑信道ID（LCID）将不同的MAC SDU解复用出来，再递交给上层。这种模式能精确验证UE的上行MAC复用功能。

  • 场景故事：李工选择“下行透明模式”来测试“Pioneer-5G”的上行逻辑信道复用。他通过TTCN脚本，模拟SS给UE下发了一个足够大的上行授权（UL Grant）。此时，UE的缓存中有两类数据：一类来自承载VoIP的DRB（高优先级），另一类来自承载网页浏览的DRB（低优先级）。根据TS 38.321的逻辑信道优先级规则，UE的MAC层应该优先封装高优先级的数据。它需要构建一个包含两个MAC SDU的MAC PDU，每个SDU前都有一个带有对应LCID的MAC子头。SS接收到这个UL MAC PDU后，其MAC层将其解复用，并将两个RLC PDU分别上报给TTCN。TTCN脚本检查这两个PDU的来源（通过不同的端口区分）和内容，验证UE是否遵循了正确的复用和优先级规则。

总结：层层递进，精准解剖L2协议栈

通过对5.1.2章节的深入剖析，我们看到了一套设计精妙、层层递进的测试体系。通过灵活运用“测试环回模式”和配置SS侧协议栈的“特殊/透明模式”，TS 38.523-3成功地将紧密耦合的L2协议栈（PDCP, RLC, MAC）逐层解耦，实现了对每个协议实体功能的独立、精准验证。

李工通过这些测试，系统性地检验了“Pioneer-5G”手机在数据处理“执行层”的每一个细节，从PDCP的数据复制和重排序，到RLC的分片和状态报告，再到MAC的复用和HARQ，为手机在复杂的NSA网络环境下的稳定数据传输性能打下了坚实的基础。

完成了EN-DC部分的测试，李工的下一个目标将是更具挑战性的NR/5GC（SA）模式。在接下来的文章中，我们将继续跟随他的脚步，探索在纯正的5G（SA）架构下，TS 38.523-3又会带来哪些全新的测试模型和技术挑战，例如新增的SDAP层测试。

FAQ

Q1：什么是“测试环回模式”（Test Loop Mode），它在L2测试中为什么如此重要？

A1：“测试环回模式”是UE的一种特殊工作状态，在此模式下，UE协议栈在指定的一层（如PDCP层之上或RLC层之上）将接收到的数据直接“环回”到发送路径，而不是递交给上层应用。它对于L2测试至关重要，因为它创建了一个封闭、可控的数据回路。测试系统发送已知的数据，UE处理后将其发回，测试系统通过比对收发数据的一致性，就能精确判断UE在环回点以下的协议层（如PDCP、RLC、MAC）是否正确工作，从而隔离了上层应用和IP协议栈的复杂性，使L2功能测试变得纯粹和可重复。

Q2：在RLC和MAC的测试模型中，为什么测试系统（SS）侧的协议栈要配置为“透明模式”？

A2：配置为“透明模式”是为了将协议头的生成和解析逻辑完全交给TTCN-3测试脚本，从而实现对测试的完全控制。例如，在RLC测试中，如果SS的RLC层工作在正常模式，它会自动处理分片和添加RLC头，TTCN就无法精确控制发送给UE的每一个RLC PDU的细节（如模拟一个错误的SN或一个特定的Poll请求）。通过将SS RLC设为透明，TTCN可以直接构造最终的RLC PDU，实现“所想即所发”，从而能够模拟各种边界和异常条件，对UE进行更严苛的测试。

Q3：PDCP测试中的“数据复制”（Duplication）和分离承载（Split Bearer）有什么区别？

A3：两者都是利用多条链路传输数据的技术，但目的和机制不同：

  • 分离承载（Split Bearer）：主要目的是提升吞吐率。它将一个数据流分流到两条链路上，两条路传输的是不同的数据包。例如，SN为奇数的数据包走路径A，SN为偶数的走路径B。
  • 数据复制（Duplication）：主要目的是提升可靠性。它将同一个数据流复制成多份，在多条链路上发送相同的数据包。例如，SN=1, 2, 3…的数据包，在路径A和路径B上都会被完整地发送一次。接收端只要从任一路径收到即可，并负责丢弃重复的包。

Q4：MAC测试中的“DL/UL header-transparent mode”和“DL only header-transparent mode”在测试目的上有什么不同？

A4：这两种模式提供了不同深度的上行测试能力：

  • DL/UL header-transparent mode：SS的MAC层对上下行MAC头都不解析。它主要用于测试基础的HARQ流程、时序关系等，无法精细验证UE的上行复用行为。
  • DL only header-transparent mode：SS的MAC层在上行会工作在正常模式，解析MAC头并进行解复用。这种模式能够精确验证UE的MAC层是否正确地根据逻辑信道优先级、令牌桶算法（LCP）等规则来复用来自不同DRB/SRB的数据，是测试UE上行QoS保障能力的关键。

Q5：在EN-DC L2测试模型中，ASP字段 MacBearerRouting 起什么作用？

A5：MacBearerRouting字段在涉及载波聚合（CA）的场景下（如5.1.2.3.2节）至关重要。在一个CA场景中，UE的一个高层承载（如一个RLC实体）的数据可能被调度到不同的载波（Component Carrier，如PSCell或SCell）上进行传输。MacBearerRouting就是TTCN-3脚本用来指示SS底层将某个特定的MAC PDU路由到哪个载波的物理层去发送的“路由标签”。通过这个字段，测试脚本可以精确模拟跨载波调度的行为，验证UE是否能在正确的时间、正确的载波上接收或发送数据。

关系图谱