深度解析 3GPP TS 38.523-3：7.3 NR/5GC (Part 2 - RRC连接控制、移动性与重建立)

本文技术原理深度参考了3GPP TS 38.523-3 V18.2.0 (2025-03) Release 18规范中，关于“7.3.5 RRC connection control”、“7.3.6 Bearers”以及“7.3.7 Processing delay testing for RRC procedures”的核心章节。本文作为7.3节的第二部分，旨在为读者详细拆解5G SA（独立组网）模式下，UE RRC连接生命周期中的核心动态流程——连接控制、移动性管理（切换）和连接重建立——的标准化测试方法。

前言：“Explorer-Sat”的动态世界大冒险

在上一篇文章中，我们的主角“Explorer-Sat”勘探终端，在测试工程师李工的指导下，成功掌握了在5G SA世界中的基本生存技能：它学会了阅读“城市公告”（系统信息），并能在“睡梦中”（DRX）被“电话”（寻呼）可靠地唤醒。

现在，“Explorer-Sat”已经不再是一个静止的观察者，它即将开始一场在虚拟5G世界中的动态大冒险。它需要被激活，建立起与网络的稳定连接；它需要在不同的小区之间穿梭，执行无缝的切换；在遭遇意外的“信号风暴”时，它还需要有能力快速恢复通信。

这一切动态行为的核心，都由RRC层的连接控制协议来指挥。TS 38.523-3的7.3.5节，正是这本“导演手册”中最为精彩的“动作戏”拍摄指南。它详细规定了从连接建立的最后确认，到连接释放的优雅告别，再到切换（Handover）这一最复杂、最核心的移动性场景的每一个步骤。

本篇文章，我们将继续跟随李工，深入探索7.3.5、7.3.6和7.3.7节，我们将看到：

• 连接的“礼炮”与“告别”：如何精确测试竞争解决和连接释放流程？
• 无缝的“移形换影”：从常规切换到载波聚合（CA）切换，再到零中断的DAPS切换，测试方法如何层层递进？
• 绝境逢生：如何模拟并验证UE在遭遇无线链路失败后的RRC连接重建立能力？
• 时间的度量：如何精确测量UE处理RRC信令的“反应速度”？

让我们拉开这场动态大戏的帷幕。

1. 连接的确认与释放：7.3.5.1 & 7.3.5.2

1.1 “谁是赢家”：提前竞争解决 (7.3.5.1 Early contention resolution)

在UE通过竞争性随机接入（CBRA）建立RRC连接时，最后一步是竞争解决：网络通过Msg4消息，回显成功接入的UE的身份标识，告知它“你赢得了这次接入”。通常，Msg4中会同时包含RRCSetup消息。但为了测试的灵活性，规范提供了一种“提前竞争解决”的测试方法。

There are cases however where it is necessary to send the DL CCCH or DL DCCH message separately from RA Msg4, this is implemented in TTCN using the test case attribute EarlyContentionResolution:

• RRC connection establishment: when RRCSetup message is part of the test purpose, …

导演的解读：这意味着，李工可以配置测试系统（SS），让它先发送一个“纯粹的”Msg4，只包含竞争解决ID，然后再单独发送RRCSetup消息。这种方法可以将竞争解决的验证与RRC连接建立的验证分离开，使得测试逻辑更清晰，问题定位更精准。

1.2 “优雅的告别”：RRC连接释放序列 (7.3.5.2 RRC connection release sequence)

当一次通信任务结束，网络决定释放RRC连接时，并非简单地发送一条RRCRelease消息就万事大吉。SS必须遵循一个严格的、有时序的资源清理流程，以确保UE能够平滑地过渡到空闲态。

According to TS 38.331, clause 5.3.8.3, after reception of the RRCRelease message the UE may either wait 60 ms or for indication of acknowledgement from lower layer… This requires scheduled release of resources at the SS:

1. At T: Send RRCRelease, stop UL grants.
2. At T + 5ms: Release security.
3. At T + 10ms: Release DRX configuration at the SS. …
4. Delay of 840ms (NOTE) T is set to 300ms in advance of RRCRelease. NOTE: The delay ensures that the UE is camping on the serving cell again to avoid side effects e.g. due to subsequent power level changes.

导演的解读：这个7步序列是自动化测试中一个至关重要的“Post-action”（后处理）流程。李工的TTCN脚本在完成一个CONNECTED模式的测试后，会严格遵循这个时间线：在T时刻发送释放消息，然后每隔几毫秒，依次拆除为UE建立的安全上下文、DRX配置、测量配置等。最后的840ms延时尤其关键，这是为了给UE足够的时间，在被“踢下线”后，重新扫描并驻留（camp on）到小区上，并读取完必要的系统信息。这避免了下一个测试用例开始时，UE还处于一个不稳定的“找网”状态，保证了测试的稳定性和可重复性。

2. 移动性的核心：切换 (Handover - 7.3.5.3)

切换是移动通信的灵魂，也是RRC协议中最复杂的流程之一。7.3.5.3节用极大的篇幅，详细定义了各种切换场景的测试序列。

2.1 跨小区切换：Intra-NR inter-cell handover (7.3.5.3.1)

这是最经典的切换场景，“Explorer-Sat”从一个gNB（源小区）的覆盖范围移动到另一个gNB（目标小区）。

In general, the intra-NR inter-cell handover is done without activation time, i.e. the timing information for configuration of the SS and sending of the RRCReconfiguration is ‘Now’.

这是一个立即执行的切换，规范为其定义了多达16个步骤的“标准剧本”。

• 场景故事：从营地到勘探点A “Explorer-Sat”正从营地（源小区）出发，前往勘探点A（目标小区）。李工启动了切换测试：

  1. 准备阶段 (Steps 1-6)：TTCN脚本首先命令SS在“幕后”完成准备工作。它在目标小区PTC上配置好DRB，然后模拟Xn接口，将源小区中“Explorer-Sat”的PDCP序列号（SN）状态“拷贝”到目标小区。这是无缝切换（lossless handover）的关键，确保数据包不会在切换中丢失或重复。
  2. “Action!” (Step 9)：源小区PTC向UE发送RRCReconfiguration消息，其中包含了mobilityControlInfo，正式指令UE进行切换。
  3. UE的响应 (Steps 10-11)：UE收到指令后，立即与源小区断开，并在目标小区上发起随机接入（RACH）。成功接入后，它向目标小区发送RRCReconfigurationComplete消息，宣告切换成功。SS检测到此消息后，会上报_IND给TTCN。
  4. “打扫战场” (Steps 15-16)：TTCN确认切换成功后，命令SS释放源小区为UE保留的所有资源。

2.2 极致可靠：DAPS切换 (7.3.5.3.5 Sequence of intra-NR inter-cell DAPS handover…)

对于自动驾驶等URLLC业务，传统“先断后连”（Break-before-make）的切换会带来无法容忍的毫秒级中断。为此，5G引入了DAPS（Dual Active Protocol Stack）切换，即“先连后断”（Make-before-break）。

The intra-NR inter-cell handover involving a DAPS DRB is done with activation time, i.e. the timing information for configuration of the SS and sending of the RRCReconfiguration is explicit. Time ‘T’ is set to 700 ms.

导演的解读：DAPS切换是一个有计划的、定时激活的流程。在切换过程中，UE的协议栈会短暂地“一分为二”，同时维持与源小区和目标小区的数据收发路径。

• 场景故事：无人矿车的数据链保护 李工正在测试一台无人驾驶矿车上的“Explorer-Sat”模组，它需要接收不间断的远程遥控指令。

  1. 激活DAPS：TTCN在T-700ms时刻，命令源小区向UE发送包含daps-Config的RRCReconfiguration消息，指令其进行DAPS切换。
  2. 双路径验证 (Steps 9-14C)：这是DAPS测试的精髓。在切换执行窗口内：
     • TTCN → 源小区 → UE: 脚本先通过源小区发送一个IP包。
     • UE → 源小区 → TTCN: UE的DAPS协议栈收到后，通过源小区的上行链路环回该IP包。TTCN验证收到。
     • TTCN → 目标小区 → UE: 几乎同时，脚本又通过目标小区发送另一个IP包。
     • UE → 目标小区 → TTCN: UE的DAPS协议栈收到后，通过目标小区的上行链路环回。TTCN也成功验证。
  3. 释放源链路 (Step 15)：在确认目标链路稳定后，目标小区会发送一个RRCReconfiguration（包含daps-SourceRelease），指示UE正式断开与源小区的连接，DAPS切换完成。

  通过这个复杂的“左右互搏”测试，李工验证了“Explorer-Sat”具备了在切换过程中数据“零中断”的顶级能力。

3. 绝境求生：7.3.5.4 RRC Connection Re-establishment

天有不测风云，信号可能因为遮挡或干扰突然中断，导致无线链路失败（RLF）。此时，UE不能坐以待毙，必须主动发起RRC连接重建立流程，尝试“重返”网络。

In general, the re-establishment is done without activation time, i.e. the timing information for configuration of the SS and sending of the RRCReestablishment is ‘Now’.

1. Target Cell: Reconfigure DCCH/DTCH DCI on CSS and reconfigure RACH procedure…
2. Target Cell: Receive RRCReestablismentRequest. …
3. Target Cell: Send RRCReestablishment.
4. Target Cell: Receive RRCReestablishmentComplete.

导演的解读：重建立测试的核心是模拟一次“意外”。

• 场景故事：突入信号盲区 李工突然大幅降低SS的发射功率，模拟“Explorer-Sat”驶入了一个信号盲区。
  1. UE检测RLF：UE的物理层检测到持续失步，触发RLF。
  2. 小区重选与请求：UE立即进行小区搜索，重新找到了信号（可能是原来的小区）。它通过RACH接入，并在Msg3中发送RRCReestablishmentRequest消息，其中包含了它之前的身份信息。
  3. 网络响应：SS收到请求后，如果能根据UE的身份信息找到其上下文，就会回复RRCReestablishment消息，同意其“归队”。
  4. 恢复连接：UE收到后，重新配置安全和DRB，并回复RRCReestablishmentComplete。连接在中断后被成功恢复，而不是像初次接入那样重新开始。李工验证了整个流程的信令交互和时序都符合规范。

4. 时间的标尺：7.3.7 Processing delay testing for RRC procedures

UE处理网络指令的速度有多快？这不是一个主观感受，而是一个必须精确测量的、有严格规范要求的指标。7.3.7节就提供了这把“时间的标尺”。

Let Nsf be the maximum allowed RRC procedure delay value (in ms) as specified in the test case prose. … The RRC procedure delay requirements are fulfilled when: (T4-K2) - (T2 - K1) ⇐ Nslot + ∆2

导演的解读：这是一个极为精巧的物理层-高层联合测量方法，用于测量从UE在物理层收完一条下行RRC消息（如RRCReconfiguration），到它在物理层准备好发送上行响应消息（如RRCReconfigurationComplete）之间的时间间隔。

• 测试流程 (Figure 7.3.7.2-1)

  1. T1: TTCN记录下行RRC消息发送的精确时间。
  2. T2: SS的物理层收到UE对该消息的HARQ-ACK，TTCN记录下这个精确的接收时间。T2时刻标志着UE在物理层已经成功接收并解码了这条消息。
  3. T3: TTCN立即开始以固定周期给UE下发UL Grant。
  4. T4: SS的物理层最终收到了UE发送的RRC响应消息，TTCN记录下这个时间。T4时刻标志着UE的高层已经处理完指令，并将响应数据交给了物理层。

• 延迟计算：最终的UE处理延迟，就是(T4 - T2)，再减去信号在空中的传输时间（K1和K2）和调度延迟（Δ2）。这个计算出的值必须小于规范（TS 38.331）或测试用例中定义的Nsf。

总结：铸造SA模式下的动态可靠性

通过对7.3.5、7.3.6和7.3.7等章节的深入实践，李工对“Explorer-Sat”在SA模式下的动态行为进行了全面而深刻的检阅。从优雅的连接释放，到复杂的DAPS切换，再到极限情况下的连接重建立，以及对处理速度的“卡尺”般测量，TS 38.523-3为确保UE在真实5G网络中的移动性和鲁棒性，提供了一套无懈可击的标准化测试剧本。

“Explorer-Sat”成功地完成了这场大冒险，证明了它不仅能在SA世界中“生存”，更能灵活地“移动”和“适应”。至此，我们对TS 38.523-3核心章节的拆解已接近尾声。在最后一篇文章中，我们将对整部规范进行一次全面的回顾与总结，并展望协议一致性测试的未来发展。

---

FAQ

Q1：RRC切换（Handover）和RRC重建立（Re-establishment）最根本的区别是什么？

A1：最根本的区别在于可预见性和触发原因。

• 切换（Handover） 是一种可预见的、网络控制的移动性流程。它由网络根据UE的测量报告主动发起，目的是让UE在移动过程中平滑地从一个小区过渡到另一个小区，以维持业务连续性。
• 重建立（Re-establishment） 是一种不可预见的、UE发起的连接恢复流程。它通常由突发的无线链路失败（RLF）、切换失败或RRC流程异常触发。UE在与网络失联后，主动尝试在某个小区上恢复其RRC连接，而不是重新开始一个全新的连接。

Q2：什么是DAPS切换？它相比普通切换有什么优势？

A2：DAPS（Dual Active Protocol Stack）切换是一种“先连接、后断开”（Make-before-break）的切换机制。在DAPS切换期间，UE会短暂地同时维持与源小区和目标小区的协议栈连接和数据收发路径。其最大的优势是能够实现零中断的数据传输，对于时延和可靠性要求极高的URLLC业务（如远程手术、自动驾驶协同）至关重要。而普通切换是“先断开、后连接”（Break-before-make），存在毫秒级的业务中断。

Q3：为什么在测试EN-DC和NR-DC的切换流程时，PDCP COUNT的转移是一个关键步骤？

A3：PDCP COUNT（包含了HFN和SN）是PDCP层用于保证数据包唯一序列号和进行安全加密的关键状态变量。在无缝切换（lossless handover）中，为了避免数据在切换过程中发生丢失或重复，UE和网络必须确保目标小区的PDCP实体能够“接续”源小区的工作。PDCP COUNT的转移，就是网络侧（通过Xn/X2接口）将UE在源小区的收发序列号状态同步给目标小区。这样，切换后，目标小区就能知道应该从哪个SN开始给UE发送新数据，以及UE发来的第一个上行数据的SN应该是多少，从而实现数据的无缝衔接。

Q4：7.3.7节定义的RRC流程时延测试，为什么需要精确记录T2（HARQ-ACK接收时间）和T4（RRC响应接收时间）？

A4：因为这个测试的目的是精确测量UE内部协议栈的处理时延，即从“物理层成功收到指令”到“高层准备好响应数据并交给物理层”之间的时间。

• T2（HARQ-ACK接收时间）是能从外部观测到的、最接近“物理层成功收到指令”的时间点。
• T4（RRC响应接收时间）是能从外部观测到的、最接近“物理层开始发送响应”的时间点。 通过测量(T4 - T2)并扣除已知的空口传输和调度延迟，就可以相对精确地剥离出UE内部从物理层上报数据，到RRC/NAS层处理，再到数据下达到物理层准备发送的纯协议栈处理时间，从而验证其是否满足规范定义的性能要求。

Q5：7.2.6.2节的Intra-cell PSCell change和7.3.5.3.2节的Intra-cell handover有什么联系和区别？

A5：两者本质上都是在同一个物理小区内进行的RRC重配，通常用于波束切换或BWP切换等场景，都采用定时激活的方式来实现平滑过渡。

• 联系：它们的设计哲学和测试方法（使用dedicated timing information）是相同的，都属于计划性的网络资源优化。
• 区别：它们应用的场景不同。Intra-cell PSCell change (7.2.6.2) 专门用于EN-DC（NSA）模式，指的是在NR辅小区组（SCG）内部进行的主小区（PSCell）属性的变更。而Intra-cell handover (7.3.5.3.2) 则用于NR/5GC（SA）模式，指的是在独立组网下，UE在当前服务的主小区（PCell）内部进行配置变更，流程上被定义为一次“切换”。虽然都叫“intra-cell”，但它们分属于EN-DC和SA两个不同的测试方法大类。