51学通信

深度解析 3GPP TS 38.523-3：5.2.2.1 SDAP (服务数据适配协议测试模型)

20分钟阅读

深度解析 3GPP TS 38.523-3：5.2.2.1 SDAP (服务数据适配协议测试模型)

本文技术原理深度参考了3GPP TS 38.523-3 V18.2.0 (2025-03) Release 18规范中，关于“5.2.2.1 SDAP”的核心章节，旨在为读者深入剖析在5G SA（独立组网）模式下，作为全新协议层的SDAP是如何被精确、隔离地进行协议一致性测试的。

前言：“Pioneer-5G”进入SA数据之心 - QoS流分拣大挑战

在完成了对“Pioneer-5G”手机SA模式下L3信令流程的全面验证后，测试工程师李工将他的目光从网络的“大脑”（RRC）转向了数据传输的“心脏地带”——L2数据链路层。与NSA模式相比，SA模式的L2协议栈迎来了一位全新的成员，也是5G端到端QoS体系的守门员：SDAP（服务数据适配协议）。

在4G时代，QoS的粒度是“承载”（Bearer），一部手机同时承载的业务类型有限，区分度不高。而进入5G SA时代，网络切片和多样化业务场景要求QoS管理必须精细到“流”（Flow）级别。一个PDU会话（比如，一次上网连接）内可以同时存在多个QoS流，例如，一个用于VoNR语音，一个用于VR游戏，一个用于后台文件下载，每个流都有自己独特的QoS要求（时延、速率、可靠性等）。

SDAP层的使命，就是在UE侧，扮演这位至关重要的“QoS流分拣员”。它的核心任务是识别出下行数据包属于哪个QoS流，并将它们准确地递交给对应的无线承载（DRB）进行后续处理；同时，在上行方向，为来自不同应用的数据打上正确的QoS流“标签”（QFI），并交给正确的DRB发送。

李工明白，SDAP层的正确工作是“Pioneer-5G”能否在SA网络下提供真正差异化、高质量服务的关键。任何一个分拣错误，都可能导致VR游戏画面卡顿，语音通话出现延迟，严重影响用户体验。因此，对SDAP的测试，必须精准无误。

本篇文章，我们将跟随李工，深入TS 38.523-3规范的5.2.2.1章节，解构SA模式下SDAP的标准化测试模型，看看测试规范是如何通过巧妙的设计，来验证“Pioneer-5G”这位“分拣员”是否训练有素、明察秋毫。

1. SDAP测试的核心武器：测试环回模式再升级

为了能够独立且精确地评估SDAP层的性能，测试必须将它从复杂的上下文中剥离出来。与之前L2测试的理念一脉相承，规范再次请出了核心武器——测试环回模式（Test Loop Mode），但这次，环回点发生了关键性的变化。

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

这段描述为SDAP测试定下了基调：

  • 环回点上移：与之前PDCP测试环回点在PDCP层之上不同，这次的环回点被设置在了SDAP层之上。这就像在UE协议栈的最顶端，刚刚完成QoS流识别和数据汇聚的地方，安装了一个“U型管”。
  • 测试范围：环回点在SDAP层之上，意味着从网络接收到的数据，必须完整地穿过UE的PHY, MAC, RLC, PDCP, 以及SDAP层，完成所有处理后，再被环回。因此，这个模型测试的是整个L2协议栈的协同工作能力，但其核心判决逻辑聚焦于SDAP的功能是否正确。
  • 简化配置：与之前的测试一样，为了便于观察和分析，加密采用“空算法”，头压缩被关闭。

这个设计的巧妙之处在于，它将SDAP的“分拣”动作，转化为了一个可观测、可判决的端到端数据流向问题。李工的测试系统（SS）从代表某个QoS流的端口发送一个数据包，如果最终能从代表同一个无线承载的端口收到一模一样的数据包，就间接证明了SDAP的分拣工作是正确的。

2. 解构SDAP测试模型：“傀儡”SDAP与“全能”TTCN

要精确验证UE的行为，首先要保证测试系统（SS）的行为是绝对标准和可控的。规范中的“Figure 5.2.2.1-1: Test model for NR/5GC SDAP testing”清晰地描绘了SS侧的特殊配置。

On the SS, Layer 1, MAC, RLC and PDCP are configured in the normal operation. The SDAP is configured in a special mode, where SS does not add any SDAP header in DL and does not remove any SDAP header in UL at the DRB port on the NR PTC.

这段话揭示了SS侧配置的精髓：L1到PDCP层都正常工作，唯独SDAP层被配置成了“特殊模式”。

  • “傀儡”SDAP：在这个特殊模式下，SS的SDAP层变成了一个“傀儡”。在下行方向，它不会自动为来自TTCN的数据包添加SDAP头；在上行方向，它也不会移除UE发来的SDAP头。它失去了作为协议实体的主动性，退化成了一个纯粹的数据透传通道。

The TTCN code shall take care of the SDAP header handling and of the QoS flow to DRB mapping, i.e. the SS shall route DL SDAP PDUs from TTCN to the corresponding DRB.

  • “全能”TTCN：真正的“大脑”是TTCN-3测试脚本。
    1. 模拟UPF：TTCN脚本现在扮演了5GC中UPF（用户面功能）的角色。它负责生成要发送的数据，并且手动为其构造一个完整的、符合规范的SDAP头（如果需要的话）。
    2. 执行QoS映射：TTCN脚本通过ASP接口，不仅将构造好的数据包（SDAP PDU）发送给SS，还会明确地告诉SS这个数据包属于哪个QoS流（QFI）。
    3. 指挥路由：SS的底层逻辑根据TTCN给出的QFI，查找由RRC配置的QoS流到DRB的映射表，然后将这个数据包路由到正确的DRB协议栈实例中去。

这种“上层全权控制，下层忠实执行”的设计，赋予了测试脚本极大的灵活性，使其能够模拟任何合规或异常的数据流，从而对UE的SDAP层进行最严苛的考验。

3. 场景化实战：李工的“QoS流分拣”大挑战

现在，李工将运用这个测试模型，对“Pioneer-5G”发起一次模拟真实业务场景的“三流并发”测试。

3.1 步骤一：构建多业务场景

李工的目标是同时测试三种差异化服务，检验“Pioneer-5G”的SDAP层能否做到忙而不乱、精准分拣。

  • 业务一：模拟VoNR高清语音通话。这是一个GBR（保证比特率）业务，对时延和可靠性要求极高。网络侧为其分配了QFI = 1。
  • 业务二：模拟4K在线视频流。这是一个非GBR业务，但要求较高的吞吐和较低的丢包率。网络侧为其分配了QFI = 8。
  • 业务三：模拟后台邮件同步。这是一个尽力而为（Best Effort）的业务，优先级最低。网络侧为其分配了QFI = 9。

3.2 步骤二：RRC信令配置“分拣规则”

测试开始前，TTCN脚本控制SS向“Pioneer-5G”发送一条RRCConnectionReconfiguration消息，其中包含了drb-ToAddModList，用于建立三个DRB，并通过内嵌的sdap-Config IE明确“分拣规则”：

  • DRB 1：配置sdap-Config，pdu-Session为PDU会话1，sdap-HeaderDL为present，sdap-HeaderUL为present，并且在mappedQoS-FlowsToAdd中，将QFI 1映射过来。
  • DRB 2：类似地，将QFI 8映射过来。
  • DRB 3：将QFI 9映射过来。

这条信令就像是给“Pioneer-5G”的SDAP分拣员下发了一份详细的“作业指导书”。

3.3 步骤三：下行数据分拣测试

  1. TTCN构造数据包：TTCN脚本生成三个带有不同载荷的数据包：VoNR_Packet, Video_Packet, Email_Packet。
  2. 手动添加SDAP头：脚本分别为这三个包手动构造SDAP头。例如，对于VoNR_Packet，它构造一个包含QFI=1的SDAP头，并将其拼接在数据包前，形成一个完整的SDAP PDU。
  3. 发送ASP请求：TTCN向SS发送请求，指示：
    • 将构造好的VoNR_SDAP_PDU发送到与QFI 1关联的端口。
    • 将构造好的Video_SDAP_PDU发送到与QFI 8关联的端口。
    • 将构造好的Email_SDAP_PDU发送到与QFI 9关联的端口。
  4. SS路由与发送：SS接收到这些指令后，根据内部的QFI-DRB映射表，分别将这三个SDAP PDU送入DRB 1、DRB 2和DRB 3的协议栈，最终通过物理层发送出去。
  5. UE侧处理：“Pioneer-5G”的L1/L2底层在三个DRB上分别收到了数据。数据到达SDAP层后，分拣员开始工作：
    • 它从DRB 1收到的数据中解析出SDAP头，看到QFI=1，知道这是VoNR数据。
    • 它从DRB 2收到的数据中解析出SDAP头，看到QFI=8，知道这是视频数据。
    • 它从DRB 3收到的数据中解析出SDAP头，看到QFI=9，知道这是邮件数据。 由于处于测试环回模式，这些被正确识别的数据包（去除了SDAP头之后）立即被送回上行路径。

3.4 步骤四：上行数据验证

  1. UE构造上行数据：“Pioneer-5G”的SDAP层接收到来自环回点的VoNR_Packet, Video_Packet, Email_Packet。
  2. 上行映射与封装：分拣员再次根据“作业指导书”（RRC配置的映射规则），为这些数据包添加正确的上行SDAP头。
    • 为VoNR_Packet添加含QFI=1的SDAP头，并将其交给DRB 1的PDCP实体。
    • 为Video_Packet添加含QFI=8的SDAP头，并交给DRB 2。
    • 为Email_Packet添加含QFI=9的SDAP头，并交给DRB 3。
  3. SS接收与上报：SS在三个不同的逻辑信道上接收到这些上行数据，经过L1/L2处理后，将三个SDAP PDU完整地（因为SS的SDAP是透明的）上报给TTCN。
  4. TTCN最终判决：TTCN脚本收到了三个上报的数据包。它开始执行最终检查：
    • 从与DRB 1关联的端口收到的数据包，移除SDAP头后，内容是否与原始的VoNR_Packet完全一致？
    • 从DRB 2关联端口收到的，是否与Video_Packet一致？
    • 从DRB 3关联端口收到的，是否与Email_Packet一致？ 如果全部一致，测试通过！李工的“Pioneer-5G”证明了其SDAP层在复杂的多流并发场景下，依然能够精准、高效地完成双向数据分拣。

总结：奠定5G差异化服务体验的基石

通过对5.2.2.1章节的深度解读，我们清晰地看到了针对5G SA核心协议层SDAP的严谨测试方法。该测试模型通过将环回点置于SDAP层之上，并将SS侧的SDAP层配置为由TTCN完全控制的“特殊模式”，成功地构建了一个封闭、可控、可重复的测试环境。

在这个环境中，测试脚本（TTCN）扮演着5GC核心网UPF的角色，能够精细地控制每一个QoS流的数据生成和路由，从而全面地验证UE SDAP层在下行数据解映射和上行数据映射方面的能力。

对于李工和他的“Pioneer-5G”来说，通过SDAP测试，意味着手机已经掌握了5G SA网络下提供差异化服务的核心技能，为将来支持网络切片、承载高清语音、畅玩云游戏等高级应用打下了坚实的协议基础。

在验证了“QoS流分拣员”SDAP之后，李工的测试将继续深入L2协议栈的下一层——PDCP。在SA模式下，PDCP的测试又会有哪些新的变化和挑战？敬请期待下一篇文章，我们将共同探索5.2.2.2章节的奥秘。

FAQ

Q1：为什么SDAP层测试模型的环回点（Loopback）必须在SDAP层之上？

A1：因为SDAP测试的核心目的就是验证SDAP层本身的功能。如果环回点设置在SDAP层之下（例如在PDCP层之上），那么数据流就不会经过SDAP层，SDAP层的QoS流映射/解映射功能就完全没有被测试到。将环回点置于SDAP层之上，确保了下行数据必须经过SDAP层的处理才能被环回，上行数据也必须由SDAP层发起封装，从而构成了一个完整的测试闭环，使得SDAP的功能可以通过端到端的数据一致性来验证。

Q2：在SDAP测试中，为什么UE侧的SDAP头（sdap-HeaderDL和sdap-HeaderUL）通常被配置为present（存在）？

A2：在测试中配置SDAP头存在，主要是为了能够明确地进行验证。下行数据包中包含QFI，UE的SDAP层可以根据这个QFI进行解映射。上行数据包中，UE的SDAP层也需要添加包含QFI的头部，这样测试系统（SS）接收到后，TTCN脚本就能直观地检查UE为上行数据包打上的QFI“标签”是否正确。虽然规范允许在某些特定情况下（如一个DRB只承载一个QoS流）省略SDAP头，但在功能测试中，显式地包含头部信息能让测试逻辑更清晰、判决更直接。

Q3：如果一个DRB承载了多个QoS流，UE的SDAP层如何区分它们？

A3：在这种情况下，SDAP头是必需的。下行方向，来自5GC的每个数据包在进入gNB时，gNB的SDAP层会为其添加一个包含对应QFI的SDAP头。这些带有不同QFI的数据包在gNB被复用到同一个DRB上发送给UE。UE的SDAP层在收到数据后，解析每个数据包的SDAP头，根据其中的QFI来区分它们属于哪个QoS流。上行方向也是类似的，UE的应用层为不同业务生成数据，SDAP层为它们打上各自的QFI标签（添加SDAP头），然后才递交给同一个DRB的PDCP层。

Q4：NR/5GC L2测试与EN-DC L2测试在模型设计上有什么根本不同？

A4：根本不同在于协议栈的构成和测试的起点。

  • EN-DC L2测试：其模型是基于4G/EPC架构的扩展，没有SDAP层。数据流的起点是“承载”（Bearer），测试的核心是验证PDCP、RLC、MAC在双连接环境下的协同工作，如分离承载（Split Bearer）和数据复制（Duplication）。
  • NR/5GC L2测试：是基于纯5G架构，引入了SDAP层。测试的起点是“QoS流”（QoS Flow）。测试的第一个环节就是验证SDAP如何将QoS流正确映射到DRB，这是后续所有L2处理的基础。因此，SA L2测试是从SDAP开始，层层向下验证的。

Q5：UL grants和DL assignments在SDAP测试模型中由谁来配置？

A5：根据规范描述“The UL grants and DL assignments are configured from TTCN over system control port.”，它们依然是由TTCN-3测试脚本来配置的。TTCN通过一个系统控制端口（system control port）向SS下发指令，告诉SS应该在哪个时间、哪个频域资源上为UE分配上行或下行调度。这保证了即使在测试L2高层协议时，底层的物理资源调度也处于测试脚本的完全控制之下，排除了物理层调度不确定性对测试结果的干扰。

关系图谱