51学通信

深度解析 3GPP TS 38.523-3：5.2.2.3 RLC (无线链路控制协议测试模型)

22分钟阅读

深度解析 3GPP TS 38.523-3：5.2.2.3 RLC (无线链路控制协议测试模型)

本文技术原理深度参考了3GPP TS 38.523-3 V18.2.0 (2025-03) Release 18规范中，关于“5.2.2.3 RLC (Radio Link Control)”的核心章节，旨在为读者深入剖析在5G SA（独立组网）模式下，作为数据传输可靠性与效率关键保障的RLC协议层，是如何被精确测试与验证的。

前言：“Pioneer-5G”的“快递服务”质量大考

在之前的测试中，资深测试工程师李工已经成功验证了“Pioneer-5G”手机的SDAP层和PDCP层。数据包在经过SDAP的“QoS流分拣”和PDCP的“安全加密与打包”之后，现在来到了数据链路层的中间站——RLC（无线链路控制）层。

如果说PDCP层像是打包并加密贵重物品的“仓库管理员”，那么RLC层就是负责将这些包裹送上路的“快递公司”。这家“快递公司”提供三种不同等级的服务，以满足不同业务的需求：

  1. 透明传输模式 (TM)：VIP专送，不拆包、不检查，用于最高优先级的系统信令。
  2. 非确认模式 (UM)：平邮服务，只管把大包裹拆分成小件（分段）发出，不保证送达，速度优先。适用于VoNR语音、在线视频等能容忍少量丢包的实时业务。
  3. 确认模式 (AM)：顺丰快递，不仅拆包发货，还带回执单（ARQ），丢件必补（重传），确保万无一失。适用于网页浏览、文件下载等要求100%可靠传输的业务。

李工的任务，就是要对“Pioneer-5G”这家内置的“快递公司”进行一次全面的“服务质量”大考。他需要验证：在AM模式下，是否真的能做到丢件必补？在UM模式下，是否能高效地处理数据分段？这些服务的每一个环节，从打包（分段）、贴单（加头），到签收（重组）、催单（轮询）和补发（重传），是否都严格遵守3GPP这家“快递行业协会”的规定？

本篇文章，我们将继续跟随李工的脚步，深入TS 38.523-3的5.2.2.3章节，剖析SA模式下RLC协议的标准化测试模型，揭示如何通过巧妙的设计，对这部复杂的“数据传输机器”进行精准的性能与功能验证。

1. RLC三大服务模式：为不同业务量身定制

在进入测试模型之前，我们有必要先详细了解一下RLC提供的这三种核心服务模式，因为它们的差异正是RLC测试的关键所在。

1.1 透明模式 (TM - Transparent Mode)

TM模式是最简单的模式，可以将其理解为一个“直通管道”。RLC层对上层（PDCP层）递交的PDU不做任何修改，不添加任何RLC头部，直接完整地交给下层（MAC层）。它不提供分段、重传等任何服务。这种模式主要用于传输一些特殊的控制信令，如SRB0承载的初始RRC消息和寻呼消息。

1.2 非确认模式 (UM - Unacknowledged Mode)

UM模式以效率为先，提供基础的数据分段和重组服务，但不保证可靠传输。

  • 分段与级联：当上层递交的RLC SDU（即一个PDCP PDU）太大，无法在一个传输机会中发完时，UM RLC会将其分段成多个UMD PDU（非确认模式数据PDU），并为每个PDU添加带有序列号（SN）的RLC头。
  • 无反馈与重传：UM模式是单向的，发送方只管发送，不关心接收方是否收到。接收方如果发现丢了某个SN的PDU，也不会通知发送方，因此没有重传机制。
  • 重排序：接收方的UM RLC实体会维护一个重排序窗口，在一定时间内尝试按SN顺序重组数据。如果等待超时，丢失的PDU就被永久放弃，已收到的数据则递交给上层。 这种模式非常适合像VoNR这样的实时语音业务。偶尔丢失一两个语音包，用户可能只是听到瞬间的微小杂音，影响不大；但如果为了重传一个丢失的包而导致后续所有包都延迟，反而会造成严重的卡顿和时延，得不偿失。

1.3 确认模式 (AM - Acknowledged Mode)

AM模式以可靠性为最高目标，提供了完整的数据分段、重传和重排序服务，确保数据100%无误地传输。

  • ARQ机制：这是AM模式的核心。发送方为每个AMD PDU（确认模式数据PDU）分配一个序列号（SN）。接收方在收到数据后，需要通过一个**STATUS PDU（状态报告）**来反馈接收情况，明确告知发送方哪些SN收到了（ACK），哪些没收到（NACK）。
  • 轮询 (Polling)：发送方不能无休止地等待状态报告。它会在发送某个PDU时，将RLC头中的P（Poll）比特置为1，强制要求接收方立即回送一个STATUS PDU。
  • 滑动窗口：收发双方都维护着一个“窗口”，定义了当前正在处理的SN范围。随着数据的成功收发，窗口会向前滑动。这套机制确保了即使在高时延链路上，也能实现连续的数据传输，而无需等待每一个包都被确认。
  • 分段、重组与重排序：与UM模式类似，AM模式也支持完整的分段和重组功能，并且由于重传的存在，其重排序机制更为复杂和关键。

李工知道，对AM模式的测试将是本次RLC大考中最复杂、也最全面的部分。

2. RLC测试模型解构：TTCN化身“魔鬼客户”

现在，我们正式进入5.2.2.3章节，看看规范是如何设计测试模型的。

The UE is registered in NR, using SRBs 0-2, and configured for NR/5GC operation. This model is suitable for testing both UM/AM mode of operation of DRBs on UE side. The UE is configured in Test Loop Mode, to loop back the user domain data above PDCP layer.

基础设定与PDCP测试类似：UE处于SA模式，并启用了测试环回模式。但值得注意的是，环回点依然位于PDCP层之上。这似乎有些奇怪，测试RLC为何要让数据流经PDCP？

答案在于测试的简便性和完整性。将环回点设置在高层，可以确保在环回之前，整个RLC SDU（即PDCP PDU）已经被完整地重组。这样，TTCN只需比对最终环回的、完整的PDCP SDU的内容是否正确即可。而RLC协议内部的状态交互（如STATUS PDU的收发）则作为过程量被独立观测和判决。

测试模型的核心设计，依然体现在对SS侧协议栈的“阉割”上。

On the SS side, L1 and MAC are configured in the normal way. The RLC of the DRBs is configured in transparent mode. … There is no PDCP configured on SS side. The ports are directly above RLC. The PDUs, exchanged between TTCN and SS, shall be the final RLC PDUs consisting of RLC and PDCP headers. TTCN code shall take care in DL of building RLC headers and PDCP headers and in UL handle RLC and PDCP headers.

规范的“Figure 5.2.2.3-1: Test model for NR/5GC RLC testing”直观地展示了这一架构。我们可以总结出几个关键点：

  1. SS侧无PDCP：SS的协议栈中完全没有PDCP层实体。
  2. SS侧RLC透明：SS的RLC实体被设为TM（透明模式），它不产生任何RLC头，也不处理任何RLC逻辑，就是一个纯粹的“直通管道”。
  3. TTCN全权负责：测试的“大脑”——TTCN-3脚本，现在直接对接在SS的RLC层之上。这意味着TTCN脚本必须亲自扮演一个对等的RLC实体。它需要：
    • 手动构造RLC PDU：对于下行数据，TTCN需要自己生成包含正确SN、SI（分段信息）、P（轮询）比特等字段的RLC头，并与一个“伪”的PDCP PDU拼接，形成一个最终的、可以在空口传输的RLC PDU。
    • 手动解析RLC PDU：对于上行数据，TTCN接收到的是来自UE的、完整的RLC PDU。它需要自己解析RLC头，处理状态报告（STATUS PDU），并检查其中的SN和ACK/NACK信息。

在这个模型中，TTCN化身成了一个最挑剔、最懂规则的“魔鬼客户”，它不断地给“Pioneer-5G”的“RLC快递公司”下单，并且专门制造各种疑难杂症（如下文的丢包），来考验其服务质量。

3. 场景化实战：一次惊心动魄的“丢件补发”测试 (AM模式)

李工决定模拟一次最常见的网络问题——丢包，来测试“Pioneer-5G”在RLC AM模式下的可靠传输能力。

步骤一：场景建立

TTCN脚本首先控制SS通过RRCConnectionReconfiguration消息，为“Pioneer-5G”配置了一个使用AM模式的DRB，并激活了测试环回模式。

步骤二：TTCN“发货”并故意“藏起一件”

李工要模拟发送一个被分割成5个小件的大包裹。

  1. 构造RLC PDUs：TTCN脚本手动构造了5个AMD PDUs，它们的SN分别为0, 1, 2, 3, 4。
  2. 设置“催单”请求：为了能及时知道UE的接收情况，TTCN在SN=4的PDU的RLC头部，将Poll比特置为1。这相当于在最后一个包裹上贴了张纸条：“收到后请立即电话告知我收货情况！”
  3. 模拟丢包：TTCN控制SS依次发送SN=0, 1, 3, 4的PDU，但故意不发送SN=2的PDU。

步骤三：“Pioneer-5G”的“收货”与“反馈”

“Pioneer-5G”的RLC实体开始接收数据。

  1. 检测到丢包：它收到了SN=0和SN=1，然后直接收到了SN=3。它立刻意识到SN=2丢失了，于是在其接收窗口中标记了SN=2为空缺状态。
  2. 响应轮询：接着，它收到了SN=4，并检测到Poll比特为1。这个“催单”请求触发了它的状态报告机制。
  3. 生成STATUS PDU：UE的RLC实体立即生成一个STATUS PDU。这个PDU是RLC层的控制消息，其内容大致如下：
    • ACK_SN：设置为3。这表示“SN=3之前（不包括3）的所有PDU，我都确认收到了”（即SN=0, 1）。
    • NACK_SN：包含一个条目，明确指出SN=2没有收到。

步骤四：TTCN的“补发”与最终验证

  1. 解析状态报告：SS的底层将UE回送的STATUS PDU上报给TTCN。TTCN脚本解析这个PDU，立刻就明白了：“客户”确认收到了0和1，但明确表示2没收到。
  2. 执行重传：TTCN立即将之前“藏起来”的SN=2的PDU，再次通过SS发送出去。
  3. UE完成重组：“Pioneer-5G”的RLC实体收到了补发的SN=2，填补了接收窗口的空缺。现在，SN=0, 1, 2, 3, 4都已集齐。RLC实体将它们按序重组，还原成一个完整的RLC SDU（即PDCP PDU），并递交给PDCP层。
  4. 环回验证：这个完整的PDCP SDU经过PDCP层（在本次测试中仅为透传）后，被环回至上行路径，最终被SS接收并上报给TTCN。
  5. 最终判决：TTCN脚本比对环回的数据内容与最初构造的5000字节数据是否完全一致。确认无误后，测试Pass。

通过这个精巧的闭环测试，李工不仅验证了“Pioneer-5G”的丢包检测能力、状态报告能力、重传接收能力，还间接验证了其最终的重组和重排序能力，一箭多雕。

4. “只管发，不管收”的UM模式测试

对于UM模式，测试流程相对简单，因为它没有反馈和重传机制。

  • 场景故事：模拟VoIP通话 李工切换到UM DRB测试。TTCN脚本同样构造了SN=0, 1, 2, 3, 4的UMD PDU，并故意不发送SN=2。
  • UE的行为：“Pioneer-5G”的RLC实体收到0, 1, 3, 4后，会启动一个t-Reassembly定时器等待SN=2。
  • 超时与递交：当定时器超时后，SN=2仍未到达。UM RLC实体不再等待，它将已经收到的、连续的PDU（SN=0, 1）进行重组并递交给PDCP层，然后丢弃它们。接着，它将SN=3, 4也进行处理并递交。
  • 判决：最终，TTCN收到的环回数据中，会明确地缺少SN=2对应的数据载荷。这恰恰证明了UE正确地执行了UM模式“不等待、不重传”的协议行为，测试同样Pass。

总结：确保数据之路平稳畅通

通过对5.2.2.3章节的深度剖析，我们揭示了RLC协议测试的核心方法论。通过将环回点巧妙地设置在PDCP层之上，并利用SS侧的“透明RLC”和“全能TTCN”架构，测试规范为验证RLC这个“快递公司”的服务质量，提供了一个无与伦比的、高度可控的测试平台。

李工通过AM和UM模式下的丢包、重传、轮询等一系列场景测试，确保了“Pioneer-5G”的数据链路层既能在需要时提供“使命必达”的可靠服务，也能在追求效率时做到“轻装上阵”。

至此，L2协议栈的“大脑”（PDCP）和“中枢神经”（RLC）都已通过了严苛的考验。在下一篇文章中，我们将进入L2的最后一站，也是与物理世界直接交互的层面——5.2.2.4 MAC层，去看看这位“空口交通警察”是如何接受检阅的。

FAQ

Q1：为什么在RLC测试模型中，测试环回点位于PDCP层之上，而不是RLC层之上？

A1：这主要是为了简化验证逻辑和保证测试的端到端完整性。RLC层处理的是分段后的PDU，如果环回点在RLC层之上，TTCN需要验证的是一个个独立的RLC PDU，而难以直接判断它们组合起来是否能还原成一个正确的上层数据包。将环回点置于PDCP层之上，意味着UE的RLC层必须成功完成所有重排序和重组工作，将一个完整的SDU（即PDCP PDU）递交给PDCP层，然后才能被环回。这样，TTCN只需在最终验证环回的整个PDCP SDU的内容是否正确即可，判决逻辑更简单、更可靠。

Q2：RLC的确认模式（AM）和非确认模式（UM）最核心的区别是什么？它们各自适用于什么业务？

A2：最核心的区别在于是否提供可靠性保障。

  • AM（确认模式）：通过ARQ（自动重传请求）机制，利用STATUS PDU进行反馈和重传，保证数据100%可靠送达。适用于对数据完整性要求极高的业务，如文件下载、网页浏览、信令等。
  • UM（非确认模式）：不提供反馈和重传，以牺牲一定的可靠性为代价换取更低的传输时延。适用于能容忍少量丢包的实时业务，如VoIP语音、在线视频流、实时游戏等。

Q3：在RLC AM测试中，TTCN脚本是如何知道UE丢了哪个数据包的？

A3：通过解析UE回送的STATUS PDU。当TTCN在发送的数据包中设置了Poll比特（轮询位）后，会强制UE上报一个STATUS PDU。这个PDU中包含了详细的接收状态信息，最关键的是NACK_SN（未确认的序列号）列表。TTCN读取这个列表，就能精确地知道UE没有收到哪些SN的数据包，从而触发相应的重传。

Q4：测试系统（SS）侧的RLC配置为“透明模式”意味着什么？

A4：意味着SS侧的RLC实体变成了一个“直通管道”，它自身不执行任何RLC协议功能，如添加/移除RLC头、分段、重组等。它收到的来自上层（TTCN）的数据会原封不动地交给下层（MAC），从下层收到的数据也会原封不动地交给上层。这种模式将所有RLC协议逻辑的处理任务都交给了TTCN脚本，使得测试脚本能够完全控制发送给UE的每一个RLC PDU的细节，从而实现对UE RLC实体各种边界和异常行为的精确测试。

Q5：RLC的序列号（SN）长度可以是6比特或12比特（UM），12比特或18比特（AM），这在测试中是如何体现的？

A5：SN的长度是由RRC信令在建立DRB时配置的。在测试中，TTCN脚本会首先通过RRC信令明确告诉UE当前DRB使用的SN长度。随后，在构造和解析RLC PDU时，TTCN都会严格按照这个配置的长度来处理SN字段。例如，如果配置了18位SN，TTCN就会生成包含18位SN的RLC头，并期望UE在STATUS PDU中也使用18位SN来报告状态。测试系统会验证UE的行为是否与RRC信令配置的SN长度完全一致。

关系图谱