<!-- title: 5G寻呼与位置更新：找手机的信令艺术 -->

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

## 一个类比：快递员找你

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

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

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

---

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

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

```mermaid
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的位置管理有三个不同粒度的区域概念，容易混淆，但各自服务于不同目的：

```mermaid
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
```

| 区域类型 | 全称 | 分配者 | 粒度 | 服务于 |
|---------|------|--------|------|--------|
| **TA** (Tracking Area) | 跟踪区 | 网络规划 | 多个小区的集合 | 基本寻呼单位 |
| **RA** (Registration Area) | 注册区 | AMF | 多个TA的列表（TAI List） | CN寻呼范围 |
| **RNA** (RAN Notification Area) | RAN通知区 | gNB | 多个小区或小区列表 | RAN寻呼范围 |

**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`来区分。

```mermaid
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触发的三大场景

| 触发条件 | 场景 | 紧急程度 |
|---------|------|---------|
| **进入新TA（不在TAI List中）** | UE移动出当前注册区 | 高——否则网络找不到UE |
| **周期性定时器T3512超时** | UE长期静止不动 | 中——确保UE仍在网 |
| **从非3GPP接入切换** | WiFi→5G切换 | 中——更新接入类型 |

**周期性位置更新的意义**：如果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态）

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

```mermaid
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**内的小区。

| 对比项 | CN Paging | RAN Paging |
|--------|-----------|------------|
| 发起者 | AMF | 最后服务gNB |
| 寻呼范围 | TAI List内所有gNB | RNA内所有小区 |
| UE状态 | CM-IDLE | RRC INACTIVE |
| UE响应 | Service Request（全流程） | RRC Resume（轻量级） |
| 核心网感知 | AMF全程参与 | AMF无感知 |
| 时延 | ~100ms | ~10-20ms |
| 信令开销 | 大（涉及AMF/SMF/UPF） | 小（仅RRC层） |

---

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

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

### 关键参数

| 参数 | 含义 | 典型值 |
|------|------|--------|
| **T** (DRX cycle) | 寻呼周期 | 32/64/128/256个无线帧 |
| **N** | 一个DRX周期内的PO数量 | 取决于配置 |
| **Ns** | 一个PF内的PO数量 | 1, 2, 或 4 |
| **PF** (Paging Frame) | 包含PO的系统帧 | 由公式计算 |
| **PO** (Paging Occasion) | PF内具体的时隙位置 | 由公式计算 |

### 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移动性管理关键差异

| 维度 | 4G LTE | 5G NR |
|------|--------|-------|
| 位置更新消息 | TAU Request | Registration Request |
| 核心网节点 | MME | AMF |
| NAS状态 | ECM-IDLE/CONNECTED | CM-IDLE/CONNECTED |
| 中间态 | 无 | **RRC INACTIVE**（CM-CONNECTED but RRC suspended） |
| RAN侧寻呼 | 无 | **RAN Paging**（gNB发起） |
| RAN侧位置区 | 无 | **RNA**（gNB管理） |
| 位置区粒度 | TAI List | TAI List（同4G，但分配策略更灵活） |
| 寻呼标识 | S-TMSI / IMSI | **5G-S-TMSI** |
| 接入类型 | 仅3GPP | 3GPP + **非3GPP**（WiFi等） |

---

## 常见问题

**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](https://techlteworld.com/5g-paging-procedure/) — 5G寻呼完整信令流程图解
2. [5G信令流程：5GC的移动性管理 - 华为云社区](https://bbs.huaweicloud.com/blogs/291683) — 华为对5G移动性管理流程的详解
3. [Paging in 5G Network - free5GC](https://free5gc.org/blog/20241204/20241204/) — 开源5G核心网项目free5GC的寻呼实现分析
4. [从TAU流程看5G网络演进 - CSDN博客](https://blog.csdn.net/weixin_42648844/article/details/161213763) — 4G TAU到5G Registration Update的演进对比
5. [5G Paging Procedure Call Flow - 3GLTEInfo](https://www.3glteinfo.com/call-flows/5g-paging-procedure/) — 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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)