好的,在详细探讨了UE在“休眠”状态(IDLE/INACTIVE)下的自主移动行为之后,我们现在将进入移动性管理的“主战场”和“深水区”——RRC_CONNECTED状态下的移动性。这是确保用户在进行实时业务(如通话、视频、游戏)时能够“无感”切换的关键,也是网络优化中最复杂、最具挑战性的领域。

深度解析 3GPP TS 38.300:9.2 Intra-NR Mobility (Part 3 - RRC_CONNECTED态移动性)

本文技术原理深度参考了3GPP TS 38.300 V18.5.0 (2025-03) Release 18规范中,关于“9.2.3 Mobility in RRC_CONNECTED”的核心章节,旨在为读者深入剖析5G网络控制移动性的核心——切换(Handover)的完整流程、关键信令交互、数据转发机制,以及多种高级切换技术(如DAPS, CHO, LTM)的设计理念。

前言:高速行驶中的“空中换轮胎”

我们的主角小明,正坐在校园里飞速行驶的无人驾驶摆渡车上,与朋友进行着一场沉浸式的AR游戏。摆渡车从教学区驶向体育馆,途中连续穿过多个gNB的覆盖范围。然而,小明的AR游戏画面始终如丝般顺滑,丝毫没有因为车辆的高速移动而出现卡顿或掉线。

这场“速度与激情”的背后,是一系列由网络精心策划和执行的、堪比“空中换轮胎”的高难度操作。这个操作,就是切换(Handover, HO)。与IDLE/INACTIVE态下UE的“自主漫游”截然不同,CONNECTED态下的移动性完全由网络主导和控制

导师老王指着实时监控屏幕上跳动的信令轨迹说:“你看,每一次平滑的切换,都是一次源gNB、目标gNB和UE之间,在几十毫秒内完成的精密信令舞蹈。它的每一个舞步,都严格遵循着38.300第9.2.3节定义的‘舞谱’。掌握这套‘舞谱’,是成为高级网优工程师的必经之路。”

今天,我们将深入这场信令舞蹈的后台,从最基础的切换流程开始,逐步揭示5G为应对不同场景而设计的多种高级切换“舞姿”。

1. 切换的宏观视角:Cell Level vs. Beam Level (9.2.3.1)

Network controlled mobility applies to UEs in RRC_CONNECTED and is categorized into two types of mobility: cell level mobility and beam level mobility. Beam level mobility includes intra-cell beam level mobility and inter-cell beam level mobility.

CONNECTED态的移动性被分为两大类:

  • 小区级移动性(Cell Level Mobility):这通常指切换(Handover)。它涉及到UE服务小区的改变,需要显式的RRC信令RRCReconfiguration)来触发。这是“大动作”,通常伴随着UE上下文在基站间的迁移。

  • 波束级移动性(Beam Level Mobility):在5G(尤其是毫米波)中,覆盖是由多个窄波束组成的。当UE在同一个小区内,从一个波束移动到另一个波束时,这个过程称为波束管理(Beam Management)。它通常通过更底层的物理层或MAC层信令(如PDCCH/MAC CE中的TCI-State指示)来快速完成,RRC层甚至可以“不知情”。波束级移动性是“小碎步”,旨在维持最佳的波束连接,不涉及服务小区的改变。

本篇文章,我们主要聚焦于更复杂的小区级移动性——切换。

2. 切换的基础舞步:Inter-gNB Handover (9.2.3.2)

规范中的 Figure 9.2.3.1-1: Inter-gNB handover procedures 已经为我们展示了最经典的gNB间切换的基础流程。我们已在总览篇有过介绍,现在,我们将结合9.2.3.2.1节的详细文本,对每个步骤进行更深入的剖析。

The intra-NR RAN handover performs the preparation and execution phase of the handover procedure performed without involvement of the 5GC…

一个关键原则是:Xn接口切换对核心网(5GC)透明。整个切换过程的“准备”和“执行”阶段,都在源gNB和目标gNB之间通过Xn接口完成。

切换流程深度剖析:

  1. 步骤0-2:测量与决策

    • 0. UE上下文: 源gNB中保存着小明的完整“档案”。

    • 1. 测量配置与报告: 源gNB通过RRCReconfiguration消息,为小明配置测量事件,如Event A3(邻区信号强度比服务小区好一个偏移量)。小明的手机持续测量邻区SSB/CSI-RS,并在满足A3条件时,向源gNB发送MeasurementReport

    • 2. 切换决策: 源gNB收到报告,结合负载情况等RRM信息,做出切换决策:“将小明切换到gNB-B”。

  2. 步骤3-5:切换准备 (Handover Preparation)

    • 3. HANDOVER REQUEST (源gNB 目标gNB): 这是切换的“敲门砖”。源gNB通过Xn-C接口,向目标gNB-B发送“切换请求”,其中包含了小明的完整UE上下文(安全信息、承载配置、UE能力等),打包在一个透明容器中。

    • 4. 准入控制 (Admission Control): 目标gNB-B进行“入学审查”。它会检查自己是否有足够的资源(PRB、CCE、C-RNTI等)来接纳小明。如果资源不足,或者不支持小明正在使用的某个切片,它可能会拒绝本次切换。

    • 5. HANDOVER REQUEST ACKNOWLEDGE (目标gNB 源gNB): 准入通过后,目标gNB-B为小明预留好所有资源,并生成一份新的RRC配置。这份新配置被打包在“切换请求确认”消息中,通过Xn接口返回给源gNB-A。

  3. 步骤6:切换执行 (Handover Execution)

    • 6. RRCReconfiguration (源gNB UE): 这是切换的**“执行命令”**。源gNB将从目标gNB-B收到的那份新配置,原封不动地通过RRCReconfiguration消息发给小明的手机。这条消息是切换流程中对UE而言最关键的一条信令,它包含了接入目标小区所需的一切信息(如新的C-RNTI、安全算法、RACH配置等)。
  4. 步骤7-12:切换完成 (Handover Completion)

    • 7. SN STATUS TRANSFER / 7a. EARLY STATUS TRANSFER: 在下发切换命令的同时或之后,源gNB会通过Xn-U接口,启动数据转发(Data Forwarding),将还未发送或未收到确认的下行数据包,转发给目标gNB-B。同时,通过Xn-C接口发送**SN STATUS TRANSFER**消息,告知目标gNB-B上下行PDCP序列号的同步信息,以确保无损和有序传输。

    • 8. UE接入目标小区: 小明的手机收到切换命令后,立即与源gNB-A断开,与目标gNB-B进行同步和随机接入(如果需要),并发送**RRCReconfigurationComplete**消息,宣告“我已成功到达!”

    • 9 & 10. PATH SWITCH: 目标gNB-B收到UE的“报到”后,立即通过NG-C接口向AMF/SMF发起**“路径切换请求(PATH SWITCH REQUEST)”**,要求核心网将小明的下行数据流,从原来的gNB-A切换到自己这里。UPF收到指令后,执行路径切换,并向旧路径发送“End Marker”包。

    • 11 & 12. UE CONTEXT RELEASE: 核心网确认路径切换成功后,目标gNB-B会通过Xn-C接口向源gNB-A发送**“UE上下文释放(UE CONTEXT RELEASE)”**消息,通知它:“交接完毕,你可以释放为小明保留的所有资源了。”

至此,一次平滑、无损的切换舞蹈完美落幕。

3. “无中断”的艺术:DAPS切换 (DAPS Handover)

对于像AR游戏这样对中断时间要求极其苛刻的业务,传统的“先断后连(Break-Before-Make)”切换所带来的几十毫秒中断,仍然是不可接受的。为此,R16引入了DAPS(Dual Active Protocol Stack)切换,一种“先连后断(Make-Before-Break)”的革命性技术。

In case of DAPS handover, the UE continues the downlink user data reception from the source gNB until releasing the source cell and continues the uplink user data transmission to the source gNB until successful random access procedure to the target gNB.

DAPS的核心思想是,在切换过程中的一小段时间内,UE的协议栈是“双激活”的,同时与源小区和目标小区保持连接

DAPS切换的特殊之处:

  • 双下行接收:UE收到切换命令后,不会立即与源gNB断开。它会继续接收来自源gNB的下行数据,同时开始接收来自目标gNB的下行数据。

  • 双上行路径:在上行,UE在成功接入目标小区之前,继续向源gNB发送数据;成功接入目标小区之后,则切换到向目标gNB发送数据。

  • 双PDCP实体功能:为了处理来自两个gNB的数据流,UE的PDCP实体会被“分裂”。它会为源和目标路径分别维护独立的ROHC解压缩和安全解密上下文,但共享同一个重排序缓冲区,以保证最终递交给上层的数据是有序且无重复的。

  • 延迟释放:直到目标gNB确认UE已经稳定连接,并且数据路径已经完全切换后,才会通过一条显式的RRC信令,命令UE最终释放与源小区的连接。

通过DAPS,切换所带来的数据中断时间可以被压缩到接近于零,为实现真正的URLLC移动性提供了终极保障。

4. “预案”的智慧:条件切换 (CHO - Conditional Handover) (9.2.3.4)

在一些移动路径可预测的场景,如车辆沿高速公路行驶,传统的“测量-报告-决策”模式显得有些被动。**CHO(Conditional Handover)**则是一种更具前瞻性的“预案式”切换。

A Conditional Handover (CHO) is defined as a handover that is executed by the UE when one or more handover execution conditions are met.

CHO的工作流程:

  1. 预配置:源gNB可以根据车辆的行驶方向等信息,预测出接下来可能会经过的一个或多个候选小区。它会提前与这些候选gNB完成切换准备,并获取它们为UE准备好的RRC配置。

  2. 下发“预案”:源gNB通过一条RRCReconfiguration消息,将所有这些“候选配置”以及各自的“执行条件”(例如,CHO-events A3/A5)一次性下发给UE。

  3. UE自主决策与执行:UE存储这些预案,并持续监控所有候选小区的信号。一旦某个候选小区的信号质量满足了预设的执行条件,UE无需再向源gNB报告,而是立即、自主地执行到该候选小区的切换。

CHO将切换执行的决策点,从网络侧前移到了UE侧,消除了“报告-决策”这一环节的信令时延,使得切换更加快速、主动,特别适用于高速移动和需要频繁切换的场景。

5. “飞速换挡”:L1/L2触发的移动性 (LTM) (9.2.3.5)

为了将移动性时延推向极致,R17引入了LTM(L1/L2 Triggered Mobility),一种比RRC切换更快的“细胞级切换”机制。

LTM is a procedure in which a gNB receives L1 or L3 measurement report(s) from a UE, and on their basis the gNB may change UE serving cell by a cell switch command signalled via a MAC CE.

LTM的核心特点:

  • RRC预配置:与CHO类似,gNB通过RRC为UE预先配置好一组LTM候选小区。

  • L1/L2触发:LTM的触发不再依赖于RRC层的MeasurementReport,而是基于更快的L1测量报告(如CSI报告)L3测量报告

  • MAC CE执行:切换命令不再通过RRC消息下发,而是通过一个MAC CE来快速触发。

由于整个“触发-执行”的闭环发生在MAC层和物理层,LTM的执行时延远低于RRC切换,可以达到极低的毫秒级,是满足未来更严苛URLLC业务(如远程驾驶、云游戏)移动性需求的关键技术。

总结:为不同场景量身定制的移动性“工具箱”

通过对9.2.3节的深入学习,我们发现5G为CONNECTED态的移动性管理,提供了一个从“稳健”到“极致”的、丰富的“工具箱”:

  1. 基础切换 (HO):以RRC信令为核心的“先断后连”流程,是保障移动连接连续性的基石,适用于绝大多数移动场景。

  2. DAPS切换:通过“先连后断”的双激活协议栈,实现了零中断切换,是URLLC业务的“定心丸”。

  3. 条件切换 (CHO):通过“预案下发,UE自主执行”的模式,实现了主动、快速的切换,适用于高速移动和可预测路径场景。

  4. L1/L2触发移动性 (LTM):通过将触发和执行下沉到MAC/PHY层,实现了超低时延的“细胞级”切换,是面向未来极致URLLC业务的“杀手锏”。

gNB的RRC“总导演”,可以根据UE的能力、业务的类型以及移动的场景,从这个工具箱中,为每一次移动性事件,挑选出最合适的“舞姿”,从而为用户呈现出一场场流畅、无缝的连接盛宴。

FAQ

Q1:为什么切换过程要对核心网(5GC)透明?这样做有什么好处?

A1:Xn接口切换对5GC透明,最大的好处是。如果每次切换都需要核心网(AMF)的介入和协调,信令流程将变为“UE 源gNB AMF 目标gNB”,路径长,时延大,难以满足5G低时延切换的要求。通过Xn接口,源gNB和目标gNB可以直接“对话”,完成切换的准备和UE上下文的迁移。只有当UE成功接入目标小区后,才需要通过一次PATH SWITCH流程通知核心网更新用户路径。这种“先切换,后通知”的模式,极大地降低了切换信令时延,是实现无缝移动性的关键设计。

Q2:数据转发(Data Forwarding)在切换中扮演了什么角色?它是必须的吗?

A2:数据转发是为了实现无损切换。在切换过程中,从核心网发往UE的下行数据,在路径切换完成前,仍然会继续到达源gNB。如果没有数据转发,这些数据包就会丢失。通过Xn-U接口的数据转发隧道,源gNB可以将这些“迟到”的数据包,以及那些已发送但未收到UE确认(ACK)的数据包,都转发给目标gNB,再由目标gNB发送给UE。这样就避免了数据的丢失。对于RLC AM承载,数据转发是实现无损切换的必要环节。对于UM承载,它不是强制的,但可以减少丢包。

Q3:DAPS切换听起来很完美,为什么不把所有切换都做成DAPS模式?

A3:DAPS虽好,但“成本”高昂。1)对UE能力要求高:UE需要具备在短时间内同时处理来自两个小区的PDSCH/PDCCH的能力,其基带处理能力和射频前端设计都更复杂,会增加终端的成本和功耗。2)对网络资源消耗大:在切换期间,同一个数据包可能需要同时在源小区和目标小区占用无线资源,造成了短暂的资源双倍消耗。因此,DAPS是一种“奢侈”的切换模式,网络通常只会为那些对中断时间零容忍的、最高等级的URLLC业务(如工业控制)配置DAPS切换,而对于普通业务,使用标准切换已经足够。

Q4:条件切换(CHO)和双连接(DC)有什么关系?

A4:CHO和DC是两种独立的技术,但可以结合使用,并且设计思想有相似之处。CHO的核心是预先配置切换候选,实现服务小区的快速变更。而DC下的CPC(Conditional PSCell Change),也可以看作是一种“条件化”的移动性,但它只针对辅小区(PSCell)的变更,主小区(PCell)保持不变。两者的共同点是都将部分移动性决策的“扳机”下放给了UE,实现了更主动、更快速的链路管理。一个支持CHO的UE,也可能同时处于DC状态。

Q5:LTM(L1/L2触发移动性)和波束管理(Beam Management)有什么区别?

A5:它们都由低层信令触发,速度很快,但目的和影响范围不同。波束管理通常发生在同一个小区内部(Intra-cell),UE只是在同一个服务小区的不同波束之间切换,其服务小区ID(PCI)不发生改变,RRC层可以完全不感知。而LTM是一种小区间(Inter-cell)的移动性,它会导致UE的服务小区发生改变。虽然触发命令来自MAC CE,但它执行的是一个简化的、预先配置好的RRC切换流程。可以把波束管理看作是“在同一个房间里换个座位”,而LTM则是“快速地从一个房间跑到隔壁房间”。