移动性管理原理：切换、TAU、寻呼的信令时序图详解

你正在地铁上刷视频，手机从基站A的覆盖范围移动到基站B，视频一帧都没卡——这就是移动性管理在背后默默工作的结果。今天我们拆解5G网络中三大移动性管理流程：切换（Handover）、跟踪区更新（TAU/Registration Update）、寻呼（Paging），看它们如何协同保障"无缝移动"。

一、为什么需要移动性管理？

1.1 一个日常类比

想象你住在一个城市里，有三个系统需要知道你在哪：

这三个场景，正好对应移动性管理的三个核心流程：

你搬到新片区 → 告诉快递公司新地址          → TAU（跟踪区更新）
快递公司要给你送包裹 → 不知道你在哪栋楼    → Paging（寻呼）
你在两栋楼之间走动 → 快递员交接包裹        → Handover（切换）

1.2 移动性管理的核心矛盾

移动性管理要解决一对根本矛盾：

$$\text{定位精度} \uparrow \quad \Longleftrightarrow \quad \text{信令开销} \uparrow$$

• 网络越精确地知道你在哪，寻呼范围越小，效率越高
• 但你每移动一小步都要上报，信令风暴就会拖垮网络

5G的解决方案是分层管理：粗粒度用跟踪区（TA），细粒度用切换（HO），中间态用RAN通知区（RNA）。

二、跟踪区更新（TAU）：告诉网络"我搬家了"

2.1 什么是跟踪区？

跟踪区（Tracking Area, TA）是网络划分的地理位置管理单元，每个TA包含若干个基站小区，用TAI（Tracking Area Identity）唯一标识：

$$TAI = MCC + MNC + TAC$$

其中MCC是移动国家码，MNC是移动网络码，TAC是跟踪区编码。

一个UE注册后，AMF会分配一个TAI List（通常包含6-16个TA）。UE在这个列表范围内移动时不需要发起TAU，只有离开这个范围才触发更新。

为什么设计TAI List而不是单个TA？ 想象你住在一个TA边界附近，日常通勤在两个TA之间来回。如果只分配一个TA，你每穿越一次边界就要做一次TAU，这就是经典的乒乓效应。TAI List让你在一片区域内自由移动而不触发更新，大幅减少信令。

2.2 TAU的触发条件

2.3 TAU信令流程（5G Registration Update）

在5G中，TAU被统一到Registration Procedure框架下，称为"Mobility Registration Update"。

sequenceDiagram
    participant UE as UE(手机)
    participant RAN as gNB(基站)
    participant AMF as AMF(移动管理)
    participant UDM as UDM(用户数据)
    participant SMF as SMF(会话管理)
    participant UPF as UPF(用户面)

    UE->>RAN: 1. Registration Request<br/>(类型: Mobility Registration Update)
    RAN->>AMF: 2. N2消息(包含Registration Request + 用户位置信息)

    Note over AMF: AMF检查是否需要鉴权<br/>(通常TAU不重新鉴权)

    AMF->>UDM: 3. Nudm_UECM_Registration<br/>(更新UE位置记录)
    UDM-->>AMF: 4. 确认响应

    AMF->>SMF: 5. Nsmf_PDUSession_UpdateSMContext<br/>(通知PDU会话位置变更)
    SMF->>UPF: 6. N4 Session Modification<br/>(更新下行数据隧道到新基站)

    AMF->>RAN: 7. N2 Registration Accept<br/>(包含新TAI List)
    RAN->>UE: 8. Registration Accept<br/>(UE获得新TAI List)

关键步骤解读：

1. 步骤1-2：UE通过空口和N2接口向AMF发起注册更新请求，携带新旧TAI信息
2. 步骤3-4：AMF向UDM更新UE的当前位置记录，确保后续能找到UE
3. 步骤5-6：通知SMF更新用户面隧道——如果UE有正在进行的PDU会话，下行数据的N3隧道终点需要更新到新的gNB
4. 步骤7-8：AMF下发新的TAI List，UE开始在新区域内"自由活动"

2.4 TAU的优化设计

设计智慧：为什么不在每个小区变化时都上报？

假设一个城市有10000个小区，100万个用户，每人每天穿越50个小区边界：

$$\text{信令量} = 10^6 \times 50 = 5 \times 10^7 \text{ 条/天}$$

如果用TA分组（每个TA约100个小区），每人每天只需穿越约2次TA边界：

$$\text{信令量} = 10^6 \times 2 = 2 \times 10^6 \text{ 条/天}$$

信令量减少了25倍。这就是跟踪区设计的核心价值。

三、寻呼（Paging）：网络主动找你

3.1 为什么需要寻呼？

当UE处于CM-IDLE状态（连接管理空闲态）时，手机和基站之间没有无线连接，核心网不知道UE在哪个具体小区。此时如果有人给你打电话或发微信，网络就需要广播寻呼消息来找到你。

类比：UE在CM-IDLE态就像手机关了WiFi但还开着蜂窝——你还在网络里，但基站不知道你在哪个扇区下面。寻呼就是网络在大喇叭里喊"XX手机你在哪？有人找你"。

3.2 寻呼触发场景

3.3 寻呼信令流程

sequenceDiagram
    participant Peer as 远端服务器/对端UE
    participant UPF as UPF(用户面)
    participant SMF as SMF(会话管理)
    participant AMF as AMF(移动管理)
    participant gNB as gNB(基站们)
    participant UE as UE(手机)

    Peer->>UPF: 1. 下行数据包到达
    Note over UPF: UE处于CM-IDLE<br/>N3隧道已释放

    UPF->>SMF: 2. 下行数据通知<br/>(N4接口)
    SMF->>AMF: 3. Namf_Communication<br/>_N1N2MessageTransfer<br/>(携带PDU Session信息)

    Note over AMF: AMF查询UE的TAI List<br/>确定寻呼范围

    AMF->>gNB: 4. N2 Paging<br/>(发给TAI List内所有gNB)
    gNB->>UE: 5. 空口Paging消息<br/>(在UE的PO时机广播)

    Note over UE: UE在PO时机<br/>检测到Paging

    UE->>gNB: 6. Service Request<br/>(建立RRC连接)
    gNB->>AMF: 7. N2 Service Request
    AMF->>SMF: 8. Nsmf_PDUSession<br/>_UpdateSMContext<br/>(激活用户面)
    SMF->>UPF: 9. N4 Session Modification<br/>(重建N3隧道)

    UPF->>gNB: 10. 下行数据通过新N3隧道发送
    gNB->>UE: 11. 下行数据到达UE

3.4 寻呼的关键参数

寻呼时机（Paging Occasion, PO）

UE不是每时每刻都在监听寻呼消息——那太耗电了。5G引入了DRX（非连续接收）机制，UE只在特定的时间窗口（PO）醒来监听：

$$PO_{index} = (SFN + subframe) \mod (T \times N_{PF})$$

其中 $T$ 是DRX周期（可以是0.32s、0.64s、1.28s、2.56s等）， $N_{PF}$ 是每个DRX周期中的寻呼帧数。

5G新增的寻呼增强：

3.5 寻呼范围优化

问题：TAI List里有多个TA，寻呼消息要发给所有gNB，太浪费了？

5G支持分级寻呼策略：

第1步：在UE最后注册的TA内寻呼
第2步：如果没回应，扩展到TAI List内所有TA寻呼
第3步：如果还没有回应，可能触发可达性判断（UE是否已关机/脱网）

这种策略在UE密集区域可以减少约60-80%的寻呼广播量。

四、切换（Handover）：无缝跨越基站边界

4.1 切换的本质

切换是在UE处于连接态（CM-CONNECTED）时，将正在进行的通信从一个小区（或基站）转移到另一个小区的过程。核心目标是：

$$\text{切换目标} = \min(\text{中断时间}) + \min(\text{丢包率}) + \min(\text{信令开销})$$

4.2 切换的触发：测量报告

切换决策基于UE上报的测量报告。UE持续测量邻区信号质量，当满足特定事件条件时上报：

A3事件是最常见的切换触发条件。举一个通俗的例子：

你正在和房间A的空调吹冷风（服务小区），但你感觉到走廊的空调更凉快了（邻区信号变强），当走廊的冷风比房间A的冷风强出一个阈值（迟滞 hysteresis）并持续一段时间（timeToTrigger），你决定搬去走廊——这就是A3事件触发的切换。

4.3 Xn切换：基站间直接握手

当源gNB和目标gNB之间有Xn接口时，切换可以不经过核心网，速度最快：

sequenceDiagram
    participant UE as UE(手机)
    participant Src as 源gNB
    participant Tgt as 目标gNB
    participant AMF as AMF
    participant SMF as SMF
    participant UPF as UPF

    UE->>Src: 1. Measurement Report<br/>(A3事件触发)
    Note over Src: 切换决策：目标gNB选择、<br/>准入控制判断

    Src->>Tgt: 2. Xn: HANDOVER REQUEST<br/>(UE上下文、PDU Session信息)
    Tgt-->>Src: 3. Xn: HANDOVER REQUEST ACK<br/>(含RRC Reconfiguration内容)

    Src->>UE: 4. RRC Reconfiguration<br/>(含目标小区配置)
    Note over UE: UE断开与源gNB连接<br/>同步到目标gNB

    UE->>Tgt: 5. RRC Reconfiguration Complete
    Note over Tgt: UE已成功接入目标gNB

    Tgt->>AMF: 6. N2: Path Switch Request<br/>(请求切换N3隧道到新gNB)
    AMF->>SMF: 7. Nsmf_PDUSession_UpdateSMContext
    SMF->>UPF: 8. N4 Session Modification<br/>(下行隧道终点切换到目标gNB)
    UPF-->>SMF: 9. 确认
    SMF-->>AMF: 10. 确认（含新的N3隧道信息）

    Note over UPF: 下行数据路径已切换<br/>到目标gNB

    AMF-->>Tgt: 11. N2: Path Switch Request ACK
    Tgt->>Src: 12. Xn: UE Context Release<br/>(通知源gNB释放资源)

Xn切换的关键步骤解读：

数据转发机制：

在步骤4-6之间（切换执行期间），下行数据可能还会发往源gNB。5G支持数据转发（Data Forwarding）：源gNB通过Xn接口把收到的数据包转给目标gNB，确保不丢包。

4.4 N2切换：核心网参与的切换

当源gNB和目标gNB之间没有Xn接口，或者涉及不同AMF时，切换需要经过核心网的N2接口：

sequenceDiagram
    participant UE as UE(手机)
    participant Src as 源gNB
    participant AMF as AMF
    participant Tgt as 目标gNB
    participant SMF as SMF
    participant UPF as UPF

    UE->>Src: 1. Measurement Report
    Src->>AMF: 2. N2: HANDOVER REQUIRED<br/>(含目标gNB ID、PDU Session列表)

    AMF->>SMF: 3. Nsmf_PDUSession_CreateSMContext<br/>(为切换准备新侧资源)
    SMF->>UPF: 4. N4 Session Modification<br/>(建立数据转发隧道)
    SMF-->>AMF: 5. 确认（含转发隧道信息）

    AMF->>Tgt: 6. N2: HANDOVER REQUEST<br/>(含UE上下文、转发隧道信息)
    Tgt-->>AMF: 7. N2: HANDOVER REQUEST ACK<br/>(含新RRC配置)

    AMF->>Src: 8. N2: HANDOVER COMMAND<br/>(含目标小区RRC配置)

    Src->>UE: 9. RRC Reconfiguration
    UE->>Tgt: 10. RRC Reconfiguration Complete

    Tgt->>AMF: 11. N2: HANDOVER NOTIFY<br/>(切换完成通知)
    AMF->>SMF: 12. Nsmf_PDUSession_UpdateSMContext<br/>(切换N3隧道到目标gNB)
    SMF->>UPF: 13. N4 Session Modification

4.5 Xn切换 vs N2切换对比

4.6 切换失败的常见原因

五、5G新增：RRC Inactive态与RAN寻呼

5G引入了一个4G没有的全新状态——RRC Inactive。这个状态是理解5G移动性管理的关键创新。

5.1 为什么要设计RRC Inactive？

类比：RRC Connected是"坐在办公室里"（全连接），RRC Idle是"下班回家关机"（完全断开），RRC Inactive是"去茶水间休息但没关电脑"（空口释放但核心网保持连接）。

RRC Inactive的核心价值是快速恢复：智能手机上大量应用（即时通讯、IoT传感器）频繁收发小数据包，如果每次都要从RRC Idle完整建立连接（需要经过TAU→Service Request→鉴权等步骤），时延太大。RRC Inactive让UE可以在10-20ms内恢复传输。

5.2 RNA（RAN-based Notification Area）

在RRC Inactive态下，UE的移动性管理由RAN侧负责，使用RAN通知区（RNA）代替核心网的TA：

• RNA是一组小区的集合，由最后服务的gNB（称为anchor gNB）定义
• UE在RNA内移动时只需要做RNA Update，不涉及核心网
• 当有下行数据到达时，anchor gNB在RNA范围内发起RAN Paging

$$\text{寻呼范围: } RNA \subseteq TA, \quad \text{通常RNA包含数十个小区}$$

5.3 三种寻呼方式对比

六、三大流程的协作关系

切换、TAU、寻呼不是孤立工作的，它们在UE的不同状态下协同运作：

flowchart TD
    A[UE开机] --> B[初始注册 Registration]
    B --> C[CM-CONNECTED<br/>RRC Connected]
    C --> D{UE有数据传输?}
    D -->|是| E[正常数据传输<br/>可能触发Handover]
    D -->|否, 超时| F[CM-CONNECTED<br/>RRC Inactive]
    F --> G{UE离开RNA?}
    G -->|是| H[RNA Update<br/>通知anchor gNB]
    G -->|否, 下行数据到达| I[RAN Paging<br/>在RNA范围内寻呼]
    I --> C
    F -->|超时或基站指令| J[CM-IDLE<br/>RRC Idle]
    J --> K{UE离开TAI List?}
    K -->|是| L[TAU / Mobility<br/>Registration Update]
    K -->|否, 下行数据到达| M[CN Paging<br/>在TAI List范围内寻呼]
    M --> C
    L --> J
    H --> F
    E -->|切换到新gNB| C

    style C fill:#4CAF50,color:#fff
    style F fill:#FF9800,color:#fff
    style J fill:#f44336,color:#fff

状态转换的关键逻辑：

1. 有数据传输时 → CM-CONNECTED/RRC Connected → 移动时触发Handover
2. 暂无数据但可能很快恢复 → CM-CONNECTED/RRC Inactive → 移动时触发RNA Update，有下行数据时触发RAN Paging
3. 长时间无数据 → CM-IDLE/RRC Idle → 离开TAI List时触发TAU，有下行数据时触发CN Paging

七、现网实战：工程师调试指南

7.1 切换问题排查

场景：用户投诉在特定区域频繁掉话

排查步骤： 1. 提取测量报告：确认UE是否正常上报A3事件，邻区信号质量如何 2. 检查切换参数：迟滞（hysteresis）是否过大导致切换过晚，触发时间（timeToTrigger）是否过长 3. 检查Xn接口：是否有Xn断链导致本该走Xn的切换变成了N2切换 4. 检查目标gNB：是否准入控制拒绝了切换请求

常见参数调优：

7.2 TAU风暴防范

在高铁、地铁等高移动性场景下，大量UE同时穿越TA边界，可能产生TAU风暴：

• 现象：AMF CPU利用率飙升，Registration Request处理时延增大
• 措施：优化TA边界规划（沿交通干线对齐TA边界）、增大TAI List范围、启用TAU节流（Throttling）

7.3 寻呼优化

• PEI（寻呼提前指示）：5G新特性，在PO之前发送一个简短的指示信号，UE如果发现自己的UE ID不匹配就直接跳过，大幅省电
• 寻呼分组：将UE分成不同组，每组在不同的PO监听，减少UE的监听频率
• eDRX：扩展DRX周期到数百秒甚至数千秒，适用于IoT设备

常见问题

Q: TAU和RNA Update的区别是什么？

A: TAU（或5G中的Mobility Registration Update）是核心网级别的位置更新，AMF参与，更新TAI List。RNA Update是RAN级别的位置更新，只有anchor gNB参与，不涉及核心网。TAU适用于RRC Idle态，RNA Update适用于RRC Inactive态。RNA Update时延更低、信令开销更小。

Q: Xn切换和N2切换在实际网络中如何选择？

A: 网络自动选择，不需要手动配置。源gNB在做出切换决策时，会先检查与目标gNB之间是否有可用的Xn接口。如果有，优先走Xn切换（更快、更省信令）；如果没有（比如跨厂家设备间未开通Xn、或跨AMF区域），则自动退回到N2切换。

Q: 为什么切换时不直接断开旧连接再连新的，而要先准备再执行？

A: 这是移动通信中"先搭桥再过河"的设计哲学。如果先断旧再连新，UE在断开期间完全无法通信，用户会感受到明显的通话中断或视频卡顿。先在目标gNB准备好资源和配置，UE只需切换一个无线信道（通常<10ms），用户几乎无感知。这种设计叫做make-before-break。

Q: 寻呼会不会导致UE很费电？

A: 不会。UE通过DRX机制，只在特定的时间窗口（PO）醒来监听，其余时间可以休眠。典型配置下UE每1.28秒醒来一次，每次监听约1ms，实际"清醒"时间占比不到0.1%。5G新增的PEI机制进一步优化：在正式PO之前发一个超短指示，如果发现不是找自己的，连PO都不用监听了。

Q: 切换失败后会怎样？

A: 切换失败后，UE会尝试RRC重建（RRC Re-establishment）流程——重新连接到原来的或另一个gNB。如果RRC重建也失败，UE进入RRC Idle态，需要通过Service Request重新建立连接。对于用户来说，切换失败可能表现为短暂的通话中断或数据速率下降，但通常会在数百毫秒内恢复。

参考来源

1. free5GC Blog: Introduction of Xn and NG (N2) based handover — Xn和N2切换的详细对比与流程说明
2. 3glteinfo: 5G NR Xn Handover Procedure — Xn切换信令流程图解教程
3. 3glteinfo: 5G NR N2 Handover Procedure — N2切换信令流程图解教程
4. ResearchGate: Tracking Area Update and Paging in 5G Networks: a Survey — 5G TAU和寻呼的学术综述，含问题建模与优化方案
5. 5G/6G Academy: 5G Handover Types Explained — Xn/N2/Inter-RAT切换类型详解

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。