5G寻呼与位置更新：找手机的信令艺术

一个类比：快递员找你

想象你住在一个大型社区里。快递员要给你送包裹，但他不知道你具体在哪栋楼、哪个房间。有两种策略：

• 策略A：快递员在社区里挨家挨户敲门——效率极低，扰民严重。
• 策略B：你告诉快递公司"我目前在3号楼到7号楼之间活动"，快递员只在这几栋楼的大堂广播你的名字——高效且省事。

5G网络找手机用的就是策略B。位置更新（你告诉快递公司你在哪几栋楼）和寻呼（快递员在指定楼栋大堂广播你的名字）是一对孪生机制，共同构成了移动性管理的核心。

5G移动性管理状态机全景

5G的移动性管理由两层状态机驱动：NAS层的注册管理（RM）和连接管理（CM），加上RRC层的无线状态。三者协同，构成了手机与网络之间的"存在感"管理。

stateDiagram-v2
    [*] --> RM_DEREGISTERED : 开机
    RM_DEREGISTERED --> RM_REGISTERED : 注册成功
    RM_REGISTERED --> RM_DEREGISTERED : 去注册

    state RM_REGISTERED {
        [*] --> CM_IDLE
        CM_IDLE --> CM_CONNECTED : Service Request / 寻呼响应
        CM_CONNECTED --> CM_IDLE : RRC Release（无suspendConfig）
        CM_CONNECTED --> RRC_INACTIVE : RRC Release（带suspendConfig）
        RRC_INACTIVE --> CM_CONNECTED : RRC Resume
        RRC_INACTIVE --> CM_IDLE : RRC Release（去激活态失败/超时）
    }

    note right of CM_IDLE : UE位置：AMF知道到TA级别\n移动方式：小区重选（UE自主）\n寻呼方式：CN Paging
    note right of RRC_INACTIVE : UE位置：gNB知道到RNA级别\n移动方式：小区重选（UE自主）\n寻呼方式：RAN Paging
    note right of CM_CONNECTED : UE位置：gNB知道到小区级别\n移动方式：网络控制切换\n不需要寻呼

这个状态机里有几个关键洞察：

为什么5G要引入RRC INACTIVE态？ 因为4G只有IDLE和CONNECTED两个极端。IDLE→CONNECTED需要完整的RRC建立+NAS Service Request，时延在100ms量级。5G在中间插了一个INACTIVE态：gNB保留UE上下文，恢复时只需RRC Resume（~10ms），核心网完全无感。这是时延与资源占用的折中设计。

位置管理三层架构：TA、RA、RNA

5G的位置管理有三个不同粒度的区域概念，容易混淆，但各自服务于不同目的：

graph TB
    subgraph "核心网位置管理"
        RA["Registration Area (RA)<br/>= TAI List<br/>AMF分配，NAS层使用"]
        TA1["TA-1"]
        TA2["TA-2"]
        TA3["TA-3"]
        RA --> TA1
        RA --> TA2
        RA --> TA3
    end

    subgraph "RAN位置管理"
        RNA["RAN Notification Area (RNA)<br/>gNB分配，RRC层使用"]
        C1["Cell-1"]
        C2["Cell-2"]
        C3["Cell-3"]
        RNA --> C1
        RNA --> C2
        RNA --> C3
    end

    subgraph "TA的组成"
        TA_X["Tracking Area"]
        TAC["TAC (Tracking Area Code)"]
        PLMN["PLMN ID"]
        TA_X --> TAC
        TA_X --> PLMN
    end

TAI List的设计哲学：AMF不是给UE分配一个TA，而是一个TA列表。UE在列表内的TA之间移动不需要发起位置更新。这就像快递公司给你分配了3-7号楼——你在这些楼之间移动时，不用打电话通知快递公司。只有走出这个范围（进入TA-8），才需要发起注册更新。

这样设计的目的是减少信令开销。如果每换一个TA就更新一次，高铁上的手机会在几十秒内发起几十次位置更新，信令风暴。

注册更新（TAU）信令流程详解

5G中，4G的"TAU Request"被统一到了Registration Request中，通过registration type = mobility registration update来区分。

sequenceDiagram
    participant UE as UE (手机)
    participant gNB as gNB (基站)
    participant AMF as AMF
    participant Old_AMF as Old AMF
    participant UDM as UDM
    participant SMF as SMF

    Note over UE: 检测到进入新TA<br/>(不在TAI List中)

    UE->>gNB: RRC Setup Complete<br/>（携带 Registration Request）
    Note right of UE: registration type =<br/>mobility registration update<br/>5G-GUTI / TAI

    gNB->>AMF: NGAP: Initial UE Message<br/>（ Registration Request ）

    alt AMF变更
        AMF->>Old_AMF: Namf_Communication:<br/>UEContextTransfer
        Old_AMF-->>AMF: UE Context (SUPI, 安全上下文)
    end

    AMF->>UDM: Nudm_UECM: Registration
    Note right of UDM: 更新UE当前服务的<br/>AMF地址
    UDM-->>AMF: 确认

    AMF->>AMF: 计算新的 TAI List<br/>（基于UE当前位置和策略）

    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext<br/>（通知位置变更）
    SMF-->>AMF: 确认

    AMF-->>gNB: NGAP: Downlink NAS Transport<br/>（ Registration Accept ）
    gNB-->>UE: RRC DL Information Transfer<br/>（ Registration Accept ）

    Note right of UE: 携带新参数：<br/>• 新的 TAI List<br/>• 新的 5G-GUTI（可选）<br/>• T3512 定时器值<br/>• Allowed NSSAI

TAU触发的三大场景

周期性位置更新的意义：如果UE突然掉电或进入信号盲区，网络无法知道它已离线。T3512定时器（通常54分钟）超时后，AMF会标记UE为"不可达"，不再对其发起寻呼，避免浪费无线资源。

TAI List分配策略

AMF分配TAI List时会考虑以下因素：

$$N_{TA} = f(\text{移动速度}, \text{负载均衡}, \text{TA大小})$$

• 高速UE（如高铁）：分配更多TA，减少更新频率
• 低速UE（如行人）：分配较少TA，缩小寻呼范围
• 负载均衡：当某个TA的寻呼负载过高时，调整TAI List将UE分散到不同AMF

寻呼流程：网络"喊人"的完整信令链

场景一：CN Paging（核心网寻呼，UE在CM-IDLE态）

这是最经典的寻呼场景——有人给你打电话或发微信，但你的手机处于空闲态。

sequenceDiagram
    participant Caller as 主叫/应用服务器
    participant UPF as UPF
    participant SMF as SMF
    participant AMF as AMF
    participant gNB1 as gNB-1 (TA-1)
    participant gNB2 as gNB-2 (TA-2)
    participant gNB3 as gNB-3 (TA-3)
    participant UE as UE (手机)

    Caller->>UPF: 下行数据包
    UPF->>SMF: 下行数据通知<br/>（UE处于CM-IDLE）
    SMF->>AMF: Namf_Communication:<br/>N1N2MessageTransfer<br/>（指示UE有下行数据）

    Note over AMF: 查找UE的TAI List<br/>= {TA-1, TA-2, TA-3}

    par 并行寻呼所有TA内的gNB
        AMF->>gNB1: NGAP: Paging<br/>（5G-S-TMSI, TAI-1）
        AMF->>gNB2: NGAP: Paging<br/>（5G-S-TMSI, TAI-2）
        AMF->>gNB3: NGAP: Paging<br/>（5G-S-TMSI, TAI-3）
    end

    par 各gNB在空口广播寻呼
        gNB1->>UE: 空口 Paging<br/>（在PO时刻广播）
        gNB2->>UE: 空口 Paging<br/>（在PO时刻广播）
        gNB3->>UE: 空口 Paging<br/>（在PO时刻广播）
    end

    Note over UE: 在自己的Paging Occasion<br/>检测到5G-S-TMSI

    UE->>gNB1: RRC Setup Request
    UE->>gNB1: RRC Setup Complete<br/>（携带 Service Request）

    gNB1->>AMF: NGAP: Initial UE Message<br/>（ Service Request ）

    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext<br/>（激活用户面）
    SMF->>UPF: N4 Session Modification<br/>（建立下行隧道）
    UPF-->>SMF: 确认
    SMF-->>AMF: 确认

    AMF->>gNB1: NGAP: Initial Context Setup
    gNB1->>UE: RRC Reconfiguration<br/>（建立DRB）
    UE-->>gNB1: 确认

    Note over UE: CM-IDLE → CM-CONNECTED<br/>下行数据可以投递

场景二：RAN Paging（RAN寻呼，UE在RRC INACTIVE态）

5G独有的场景。UE在RRC INACTIVE态时，核心网认为它仍然在CM-CONNECTED态——AMF根本不知道gNB把UE挂起了。寻呼由gNB发起，范围仅限RNA内的小区。

寻呼时机计算：UE何时"竖起耳朵"

UE不可能24小时监听寻呼——那太耗电了。5G采用DRX（不连续接收）机制，UE只在特定的时刻（Paging Occasion, PO）醒来监听，其余时间休眠。

关键参数

PF和PO的计算公式

UE使用5G-S-TMSI的最低10位作为UE_ID来计算自己专属的寻呼时机：

$$UE_ID = 5G\text{-}S\text{-}TMSI \mod 1024$$

$$SFN \mod T = (T \div N) \times (UE_ID \mod N)$$

$$i_s = \lfloor UE_ID \div N \rfloor \mod N_s$$

其中 $SFN$ 是系统帧号，$i_s$ 决定了PF内哪个PO属于该UE。

直觉理解：这就像电影院选座——你的UE_ID就是你的"票号"，它决定了你该在哪个"场次"（PF）的哪个"座位"（PO）出现。不同的UE被分散到不同的PO，避免所有UE同时醒来导致信道拥塞。

寻呼容量计算

一个PO内能携带的寻呼记录数是有限的：

$$N_{paging_records} = \lfloor \frac{PDSCH_TB_size - Header}{UE_ID_size} \rfloor$$

当某个PO的寻呼记录满了，额外的UE会被安排到下一个PO。在高密度城区，这是寻呼容量规划的关键指标。

实战调试：工程师什么时候会碰到这些

场景1：用户投诉"有人打我电话说无法接通"

排查路径： 1. 检查AMF上UE的注册状态——是否在CM-IDLE？ 2. 检查TAI List是否正确分配——是否包含UE当前所在的TA？ 3. 检查寻呼记录——AMF是否发出了Paging？gNB是否收到了NGAP Paging？ 4. 检查UE的PO配置——DRX cycle是否过长导致寻呼时延？ 5. 检查gNB空口Paging发送日志——是否在正确的PO发送？

常见陷阱：UE在TA边界频繁乒乓，导致TAI List频繁更新。如果AMF分配策略不当，UE可能刚更新完又到了新TA，造成短暂的"不可达"窗口。

场景2：物联网设备掉线

排查路径： 1. 检查T3512周期性注册定时器——是否太短导致频繁信令？ 2. 检查eDRX配置——是否DRX cycle过长（如超过1小时），导致AMF认为UE不可达？ 3. 检查UE是否正确响应了Paging——空口日志中PO时刻的UE行为。

场景3：RRC INACTIVE态异常释放

排查路径： 1. 检查RNA配置是否合理——太小导致频繁RNA Update，太大导致RAN Paging范围过广。 2. 检查gNB间的Xn链路——RNA Update需要新gNB从旧gNB获取UE上下文。 3. 检查RAN Paging是否超时——如果RNA内小区过多，寻呼时延可能超过定时器。

4G与5G移动性管理关键差异

常见问题

Q: TAI List越大越好吗？越大就越省信令？

A: 不一定。TAI List大确实减少了位置更新次数，但增大了每次寻呼的范围。一个极端的例子：如果TAI List覆盖整个城市，那么每次有人给你打电话，城市里所有gNB都要广播你的寻呼消息——这对无线资源是巨大的浪费。AMF需要根据UE移动特征动态平衡这个trade-off。

Q: RRC INACTIVE和CM-IDLE的区别是什么？核心网感知差异在哪？

A: RRC INACTIVE是RRC层状态，核心网（AMF）认为UE仍然在CM-CONNECTED。AMF不会对这个UE发起CN Paging。只有gNB知道UE被挂起了，由gNB负责在RNA范围内进行RAN Paging。核心网完全无感，这是5G降低信令时延的关键设计。

Q: 寻呼失败了怎么办？网络会重试几次？

A: AMF会按照预设的寻呼策略进行重试。典型配置是：首次寻呼失败后，间隔几秒发起第二次，可尝试3-5次。如果所有尝试都失败，AMF标记UE为"不可达"，主叫方会收到"用户暂时无法接通"的提示。下次UE发起TAU或Service Request时，AMF会清除"不可达"标记。

Q: 高铁场景下移动性管理有什么特殊处理？

A: 高铁场景的核心挑战是快速穿过多个TA。优化手段包括：(1) AMF为高铁UE分配更大的TAI List；(2) 沿线TA规划时将高铁沿线小区划入专用TA，避免与普通用户混用；(3) 利用RRC INACTIVE态，减少核心网信令。部分运营商还会部署专用的"高铁AMF Pool"来集中管理。

Q: RNA Update失败会导致什么？

A: RNA Update失败时，gNB可能释放UE上下文，UE回退到CM-IDLE态（需要AMF介入），或者UE尝试重新发起Registration。最坏情况下，UE需要从RM-DEREGISTERED重新开始注册，恢复时间较长。

参考来源

1. 5G Paging Procedure - TechLTE World — 5G寻呼完整信令流程图解
2. 5G信令流程：5GC的移动性管理 - 华为云社区 — 华为对5G移动性管理流程的详解
3. Paging in 5G Network - free5GC — 开源5G核心网项目free5GC的寻呼实现分析
4. 从TAU流程看5G网络演进 - CSDN博客 — 4G TAU到5G Registration Update的演进对比
5. 5G Paging Procedure Call Flow - 3GLTEInfo — 5G寻呼流程各分支场景详解

本文由「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 等场景全覆盖。