51学通信

深度解析 3GPP TS 38.523-3：5.2.2.4 MAC (SA组网下的空口交通警察试炼)

21分钟阅读

深度解析 3GPP TS 38.523-3：5.2.2.4 MAC (SA组网下的空口交通警察试炼)

本文技术原理深度参考了3GPP TS 38.523-3 V18.2.0 (2025-03) Release 18规范中，关于“5.2.2.4 MAC (Medium Access Control)”的核心章节，旨在为读者深入剖析在5G SA（独立组网）模式下，作为空口资源调度执行者的MAC层，是如何被进行严苛且精细的协议一致性测试的。

前言：“Pioneer-5G”迎接空口“交通警察”的检阅

经过一系列严苛的测试，测试工程师李工已经验证了“Pioneer-5G”手机在SA模式下的SDAP、PDCP和RLC层。数据包从被赋予QoS身份，到被加密保护，再到被可靠分段，已经完成了在上层协议栈的“精加工”。现在，这些整装待发的“数据包裹”来到了L2协议栈的最后一站，也是与物理世界直接交互的“发货平台”——MAC（媒体接入控制）层。

MAC层在协议栈中扮演着“空口交通警察”和“总装线工人”的双重角色，其工作直接决定了空口资源的利用效率和数据传输的实时性：

  • 交通警察：它严格执行来自物理层PDCCH的“调度指令”（UL Grant和DL Assignment），在正确的时间和频域资源上接收或发送数据。
  • 总装线工人：它负责将来自不同逻辑信道（不同RLC实体）的数据包，根据优先级规则， multiplexing（复用）到同一个传输块（TB）中，并添加MAC头部，形成最终的MAC PDU。
  • 质量快速检测员：它执行HARQ（混合自动重传请求）流程，为每个传输块提供快速的ACK/NACK反馈和重传管理，是保障空口传输低时延和高可靠性的第一道防线。

李工的任务，就是对“Pioneer-5G”的这位“交通警察”进行一次全面的能力检阅。他需要验证：手机的MAC层能否精准理解调度指令？在上行数据“拥堵”时，能否做到“先急后缓”，正确执行逻辑信道优先级？在HARQ流程中，能否做到快速响应、准确反馈？

本篇文章，我们将继续跟随李工的脚步，深入TS 38.523-3的5.2.2.4章节，详细拆解SA模式下MAC协议的测试模型，看看TTCN-3脚本是如何化身为“最高调度中心”，对这位“交通警察”下达各种极限指令，以检验其是否训练有素、令行禁止。

1. 基础岗前培训：单载波MAC测试模型 (5.2.2.4.1)

这是所有MAC功能测试的起点，在一个简化的单载波SA环境中，对MAC层的核心能力进行隔离验证。

The UE is configured in Test Loop Mode A, to loop back the User Plane data above PDCP layer. On UE side Ciphering is enabled (since Mandatory) but with null ciphering algorithm, which is equivalent to not using ciphering. Header compression is not configured on UE side.

测试的基本设定与RLC测试保持一致：

  • UE侧：处于“测试环回模式 A”，环回点位于PDCP层之上。这意味着数据流必须完整穿过UE的PHY → MAC → RLC → PDCP协议栈，解封装并验证后，再由上行协议栈重新封装并发送回来。
  • 简化配置：同样地，加密采用“空算法”，头压缩关闭，以排除干扰，让测试焦点集中在MAC层的功能上。

1.1 SS侧的“全控”模式：TTCN君临天下

为了能够对MAC层的行为进行“像素级”的控制和验证，测试系统（SS）的协议栈被配置到了一个前所未有的“透明”程度。规范中的“Figure 5.2.2.4.1-1: Test model for NR/5GC MAC testing”展示了这一架构。

On the SS NR, Layer 1 is configured in the normal way. 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 respectively at DRB port. In this case, the TTCN shall provide the final MAC PDU, including padding. … On DRBs the NR RLC is configured in transparent mode. … There is no NR PDCP and SDAP configured on SS side. The ports are directly above NR RLC.

这段描述信息量巨大，为我们揭示了SS侧的“三无”和“一特殊”配置：

  • 三无：SS侧完全没有SDAP、PDCP和功能性的RLC实体（RLC处于透明模式）。
  • 一特殊：SS的MAC层处于“特殊模式”，即它自身不负责生成或解析MAC头。

这意味着，TTCN-3测试脚本现在掌握了至高无上的权力。在下行方向，它必须亲手构造一个完整的、最终的MAC PDU，包括：

  1. MAC子头部：为每个要复用的RLC PDU添加包含LCID（逻辑信道ID）和L（长度）字段的子头。
  2. RLC PDU：这些是来自“透明”RLC层的载荷，实际上也是由TTCN构造的，包含了RLC头和“伪”PDCP PDU。
  3. 填充（Padding）：如果所有数据载荷加起来还不足以填满一个传输块（TB），TTCN还需要负责添加填充字节和对应的MAC填充子头。

TTCN将这个“手工打造”的MAC PDU交给SS的MAC层，后者的唯一工作就是把它送给物理层去发送。这种设计将测试的控制精度提升到了极致。

1.2 MAC测试的两种“审讯模式”

为了满足不同的测试目的，规范为SS MAC的“特殊模式”定义了两种不同的工作方式，这直接影响了上行数据的处理流程。

There are two different test modes in which NR MAC header addition/removal can be configured:

  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 according to the logical channel Ids.

1.2.1 模式一：DL/UL全透明模式 - 考验TTCN的“全能”

  • 机制：在此模式下，SS的MAC层对上下行都是“睁眼瞎”。下行时，它透传TTCN构造的MAC PDU。上行时，它将从物理层收到的整个MAC PDU（包含所有头部和填充）原封不动地、作为一个整体的数据块上报给TTCN。
  • 测试目的：这种模式给予TTCN最大的控制权和可见性，适用于需要精确分析UE上行MAC PDU完整结构的场景，例如验证填充规则、子头格式等底层细节。但缺点是TTCN脚本需要自己编写复杂的MAC PDU解析逻辑。

1.2.2 模式二：下行透明/上行正常模式 - 聚焦逻辑信道复用

  • 机制：下行方向与模式一相同。但在上行方向，SS的MAC层切换回正常工作模式。它会主动解析UE发来的MAC PDU头部，根据LCID对不同的MAC SDU（即RLC PDU）进行解复用，然后将这些干净的RLC PDU通过不同的逻辑端口分别上报给TTCN。
  • 测试目的：这是测试UE上行逻辑信道优先级（LCP）和复用功能的“利器”。在这种模式下，TTCN无需关心复杂的MAC PDU解析，只需检查在正确的端口上是否收到了预期的RLC PDU即可，大大简化了测试脚本的判决逻辑。

1.3 场景故事：一次“先救护车，后私家车”的交通疏导测试

李工决定使用“下行透明/上行正常模式”来验证“Pioneer-5G”最关键的上行LCP（逻辑信道优先级）功能。

  1. 场景设置：TTCN通过RRC信令为UE配置了两个DRB，一个DRB（LCID=5）承载高优先级的模拟“紧急医疗数据”，另一个DRB（LCID=6）承载低优先级的“网页浏览数据”。TTCN脚本确保两个DRB的RLC层都有待发数据。
  2. 下发调度指令：TTCN通过ASP控制SS，向UE发送一个UL Grant（上行授权），其授权的传输块大小（TBS）恰好只够传输一部分“紧急医疗数据”和一小部分“网页浏览数据”。
  3. UE的MAC层决策：根据TS 38.321定义的LCP规则，“Pioneer-5G”的MAC层开始“装车”。它必须优先服务高优先级的逻辑信道。于是，它首先从LCID=5的RLC实体取走所有可传输的“紧急医疗数据”，然后用剩余的授权空间，从LCID=6的RLC实体取走一部分“网页浏览数据”。最后，它为这两部分数据分别添加MAC子头，组装成一个MAC PDU发送出去。
  4. SS解复用与上报：SS的MAC层（处于正常上行模式）收到了这个PDU。它解析头部，发现里面包含了来自LCID=5和LCID=6的两个MAC SDU。于是，它将这两个SDU（即RLC PDU）分离开，分别通过与LCID 5和LCID 6关联的两个不同端口上报给TTCN。
  5. TTCN判决：TTCN脚本收到了两份数据。它进行检查：
    • 在LCID 5端口上收到的数据，是否是完整的“紧急医疗数据”？
    • 在LCID 6端口上收到的数据，是否是预期的那部分“网页浏览数据”？
    • 数据到达的顺序和数量是否符合优先级规则？ 确认无误后，测试Pass。这证明了“Pioneer-5G”的“交通警察”在上行拥堵时，能够正确地疏导交通，让“救护车”先行。

2. 协同作战：NR载波聚合MAC测试模型 (5.2.2.4.2)

当网络配置了载波聚合（CA）时，MAC层需要管理和调度多个载波上的资源，其复杂性进一步增加。

The NR/5GC MAC CA test model builds on top of the NR/5GC MAC test model, with the differences specified hereafter. On the SS NR side, there is one PCell and one SCell configured…

  • 架构解读：规范的“Figure 5.2.2.4.2-1: Test model for NR/5GC MAC CA testing”展示了CA模型。SS侧的RLC实体依然是统一的（位于PCell上），但下面连接了两个并行的MAC实体，分别对应PCell和SCell。
  • 核心机制 - MacBearerRouting：

The NR data routing between the RLC layer of PCell and the lower layers of either PCell or SCell shall be provided to/by SS in the common part of the data ASP using the MacBearerRouting field.

`MacBearerRouting`字段再次扮演了关键的“路由标签”角色。当TTCN要发送一个下行数据包时，它可以通过这个字段，明确指示SS应该将这个包交由PCell的MAC实体处理，还是SCell的MAC实体处理。这使得测试脚本能够精确模拟**跨载波调度**的行为。
  • 场景故事：双车道并行调度 李工要测试跨载波调度功能。
    1. SS通过RRC信令为“Pioneer-5G”配置了一个SCell。
    2. TTCN脚本构造一个PDCCH DCI，该DCI在PCell上发送，但其中的“Carrier Indicator Field (CIF)”字段指向SCell，且调度了一个位于SCell上的PDSCH资源。
    3. 同时，TTCN向SS发送包含用户数据的ASP，并通过MacBearerRouting字段指明该数据应路由到SCell。
    4. SS收到指令后，在PCell上发送了调度DCI，并在SCell上发送了对应的数据PDSCH。
    5. “Pioneer-5G”的MAC层必须能够正确解析PCell上的DCI，并根据CIF的指示，转到SCell上去接收数据。
    6. 数据通过环回路径返回，TTCN验证数据一致性，测试通过。这证明了手机MAC层具备了处理跨载波调度指令，实现多车道协同工作的能力。

总结：保障空口最后一公里的秩序与效率

通过对5.2.2.4章节的深度解读，我们完成了对SA模式L2协议栈测试的“三部曲”。MAC层的测试模型，通过将控制权最大限度地交予TTCN，并设计两种不同的上行处理模式，实现了对MAC层核心功能的全面、精准覆盖。无论是逻辑信道优先级这种“微观”的复用规则，还是载波聚合下“宏观”的跨载波调度，都在这套模型下得到了严谨的验证。

李工对“Pioneer-5G”的L2“执行引擎”进行了彻底的性能摸底，确保了它不仅能正确决策（L3），还能高效、可靠、有序地执行（L2）。至此，“Pioneer-5G”在SA模式下的核心数据传输能力已经得到了充分的证明。

我们的深度解读系列也随之完成了对TS 38.523-3核心章节（5.1和5.2）的剖析。在后续的文章中，我们将继续探索规范中定义的其他高级特性测试模型，如Sidelink、共享频谱等，敬请期待。

FAQ

Q1：为什么MAC层测试模型要将SS侧的RLC也设置为透明模式？

A1：这是为了最大限度地隔离被测对象（DUT）的MAC层。如果SS侧RLC工作在正常模式，它会对TTCN发来的数据进行分段，这会改变递交给MAC层的数据单元（RLC PDU）的大小和数量，从而引入了RLC行为的变量。通过将SS RLC设为透明，TTCN可以精确控制交给SS MAC层的RLC PDU，确保发送给UE的MAC PDU中的载荷与TTCN的预期完全一致，从而将测试的焦点严格限定在MAC层的复用、填充和HARQ功能上。

Q2：逻辑信道优先级（LCP）是什么？为什么它是MAC层的一个重要测试点？

A2：LCP是MAC层在上行方向进行数据复用时必须遵循的一套规则。当UE有多个逻辑信道（对应不同的业务，如语音、视频、网页）都有数据待发，而当前获得的UL Grant资源又不足以发送所有数据时，LCP规定了MAC层必须按照“优先级 > PBR（优先比特率） > BSR（缓存状态报告）”的顺序来决定先发送哪个逻辑信道的数据，以及发送多少。正确实现LCP是保证UE端QoS差异化服务的关键，因此是MAC层的一个核心测试点。

Q3：什么是HARQ？MAC测试模型如何验证UE的HARQ功能？

A3：HARQ（混合自动重传请求）是MAC层提供的一种快速重传机制。发送方发送一个传输块后，接收方会通过物理层快速反馈ACK（确认）或NACK（未确认）。如果收到NACK，发送方会立即重传。MAC测试模型通过TTCN脚本来验证此功能：

  • 下行HARQ：TTCN控制SS发送一个数据，然后监听UE在上行PUCCH上反馈的是ACK还是NACK。
  • 上行HARQ：TTCN控制SS给UE一个UL Grant，UE发送数据后，TTCN可以控制SS故意回送NACK，并验证UE是否会在指定的 HARQ RTT 时间后，在同一个HARQ进程上进行重传。

Q4：在载波聚合（CA）测试中，TTCN如何控制数据在PCell还是SCell上发送？

A4：通过在发送数据的ASP（抽象系统原语）请求中设置MacBearerRouting字段。这个字段就像一个“地址标签”，TTCN用它来告诉SS的底层协议栈，这个MAC PDU应该被路由到PCell的物理层去发送，还是应该被路由到SCell的物理层去发送。这使得TTCN能够精确模拟各种跨载波调度场景。

Q5：Test Loop Mode A和之前在RLC/PDCP测试中提到的Test Loop Mode有什么区别？

A5：Test Loop Mode A是3GPP为MAC层测试专门定义的一个环回模式（在TS 38.509中定义）。它的环回点位于PDCP层之上。这与我们之前讨论的PDCP测试和RLC测试所使用的环回点是相同的。规范在这里明确使用Test Loop Mode A这个术语，是为了与其他可能存在的、环回点在不同层次的测试模式（如Test Loop Mode B环回点在RLC之上，Test Loop Mode C用于MBS计数）进行区分，确保测试配置的精确性。所以，在5.2.2章节的L2测试中，SDAP、PDCP、RLC的测试模型虽然没有明确写Mode A，但其描述的“loop back … above PDCP layer”实际上就是Test Loop Mode A的行为。

关系图谱