<!-- title: 谁决定手机往哪走 -->

# 谁决定手机往哪走：5G移动性管理的控制权全景

> 面向有 1–3 年经验的无线/核心网工程师。本文不谈"切换失败了怎么补参数"，而是回答一个更上游的问题：**当一部手机在网格里移动时，测量、判决、执行这三件事，究竟分别归谁？为什么标准要这样分？**

---

## 一、先看一场接力赛

想象一场元宇宙里的马拉松。

裁判（终端）戴着心率表，一直在测量自己的状态；教练（基站）盯着大屏，判断"要不要让运动员换个赛道"；而赛事组织方（核心网）手里握着全国参赛者的名单和联络方式。

这就是移动性管理的全部骨架：

- **测量**——谁在采集现场数据？
- **判决**——谁根据数据拍板？
- **执行**——谁最终下达"换跑道"的指令？

移动通信标准用了三十年，把这个"谁说了算"的问题拆得比接力赛还细。而在不同的网络状态下、同一条移动链路的三个环节，归属甚至会来回变化。理解这套归属关系，你才算真正看懂了移动性，而不是记住了几条触发时序。

---

## 二、一个绕不开的矛盾：位置要准，信号要省

先算一笔账。

一部手机如果一直"在线报位置"，网络当然知道它在哪儿，呼入业务想找到它非常快。但全国有海量终端，如果每部手机每分钟报一次位置，核心网的信令面会瞬间被位置更新流量淹掉。

反过来，如果网络完全不管位置，只在有呼入时漫无目的地广播寻呼——"XX，你在吗？"在几十上百个小区上空喊一遍——信令省了，但呼出成功率会塌方。

这两件事互相拉扯，构成移动性管理的第一性矛盾：

$$
\underbrace{N_{\text{ue}}\cdot f_{\text{upd}}}_{\text{位置上报开销}} \;\times\; \underbrace{C_{\text{paging}}}_{\text{单次寻呼代价}} \;=\; \text{系统总成本}
$$

位置上报越频繁，寻呼范围就越可以缩小；上报越稀疏，就必须靠更大的寻呼范围来兜底。**跟踪区（Tracking Area）、注册区（Registration Area）、TAI List、RNA 这些概念，全都是为了在这条曲线上找一个"性价比最优的工作点"而造出来的。**

理解到这一层，你就明白为什么"手机多久报一次位置"永远没有标准答案：它是**信令开销**与**状态时效性**之间的一次性权衡，取值取决于用户类型（手机、IoT 模组、专网终端诉求完全不同）和网络策略。

---

## 三、控制权三段式：三种经典模式

蜂窝移动性管理在教科书里被抽象成三种控制模式，区别只在于"测量、判决、执行"三个环节分别归谁。

```mermaid
flowchart TD
    subgraph M1["模式一：网络控制"]
        A1["网络测量"] --> A2["网络判决"]
        A2 --> A3["网络执行"]
    end
    subgraph M2["模式二：终端辅助"]
        B1["终端测量"] --> B2["网络判决"]
        B2 --> B3["网络执行"]
    end
    subgraph M3["模式三：终端控制"]
        C1["终端测量"] --> C2["终端判决"]
        C2 --> C3["网络执行"]
    end
```

| 模式 | 谁测量 | 谁判决 | 谁执行 | 特点与代价 |
|---|---|---|---|---|
| 网络控制 | 网络 | 网络 | 网络 | 网络全知全能，但空口测量负担全压给基站，终端毫无主动性 |
| 终端辅助 | 终端 | 网络 | 网络 | 终端报测量报告，网络拍板。现代蜂窝网连接态的标准做法 |
| 终端控制 | 终端 | 终端 | 网络执行 | 终端自己决定何时移动，网络照办。空闲态的小区重选就是典型 |

**为什么现代网络在连接态选择"终端辅助"？** 因为空口质量只有终端最清楚——它知道自己收到几个子帧、有没有丢包、被谁干扰。把这块最原始的观测交给最懂现场的人，是最省事的设计。代价是判决权仍在网络，所以网络的策略意图（负载均衡、异频引导、切换带设计）依然能贯彻下去。

**为什么空闲态反而让终端自己说了算？** 因为空闲态根本没有"连接"可言——上下文已经释放，网络不掌握任何实时测量。此时强制每部手机持续上报，等于为了发一条短信先搭一整条专线。而终端完全可以在广播的系统信息里读到邻区信号强度，自己算出"哪个小区更好"，然后通过一次极轻量的移动性更新把新位置报上去。这就是空闲态**小区重选**和**移动性更新**的哲学基础：网络只在必要时收一个"结果"，不参与过程的实时控制。

---

## 四、完整迁移地图：一部手机的三种处境

现在把控制权放回时间轴上。终端在网络里的处境不是两态，而是三态；每一次跨态，都是一次移动性事件的终点。

```mermaid
flowchart TD
    IDLE["空闲态<br/>上下文已释放"] -->|业务请求或寻呼响应| CONN["连接态<br/>上下文完整"]
    CONN -->|静默超时 网络下发挂起| INACT["非激活态<br/>上下文保留"]
    INACT -->|恢复请求或网络寻呼| CONN
    CONN -->|主动释放或掉电| IDLE
    INACT -->|挂起超时或主动释放| IDLE
```

三条跨态路径的工程含义完全不同：

**① 空闲态 → 连接态：唤醒**

触发源有两种，方向截然相反：

- **上行触发**：终端自己有话要说（发数据、发起呼叫），走随机接入 + 服务请求。
- **下行触发**：网络有事找它（来话、下行数据到达）。此时网络并不知道终端在哪个具体小区，只能先发寻呼；终端在自己的寻呼时机醒来、认出自己，再发起随机接入。

```mermaid
sequenceDiagram
    participant AMF as 核心网
    participant GNB as 基站
    participant UE as 终端
    AMF->>GNB: 下发寻呼消息
    GNB->>UE: 空口广播寻呼
    UE->>GNB: 随机接入 表明身份
    GNB->>AMF: 转交接入请求
    AMF->>GNB: 下发待传数据
    GNB->>UE: 调度下行数据
```

这条链路解释了现网里最经典的一类投诉：**主叫能打、被叫不通**。主叫是上行触发，不需要网络先找到你；被叫是下行触发，卡在"网络找到你"这一环——寻呼时机没对上、TAI List 覆盖不全、TAI List 太大导致寻呼广播拥塞、或终端位置记录已经过期，都会让这条链路断在中间。

**② 连接态 → 非激活态：挂起**

网络发现某部终端一段时间内没有业务流量，不想一直占着连接资源，于是下发一条"带挂起配置"的释放消息：连接放掉，但**上下文（安全上下文、承载、能力信息）留在基站和核心网里**。终端转入非激活态，像一个在酒店大堂登记过、暂时回房休息的人——行李还寄存在前台。

这一步的核心价值是**省电 + 快速唤醒**：终端进入类似空闲态的低功耗睡眠周期，但万一业务再来，不需要从零建链，只需要发一个恢复请求。

**③ 非激活态 → 连接态：复活**

两种触发：终端自己发起恢复请求，或者网络通过 RAN 侧寻呼把终端叫醒。真正麻烦的是**上下文迁移**——恢复请求可能落在一个和原来不同的基站点上，新基站必须能把上下文捞回来。这是"非激活态"在实现上比空闲态贵得多的根本原因，也是它只适合"短时间静默"而不是"长期待机"的原因。

---

## 五、位置记录的三层刻度

移动性不是单一动作，而是一串尺度不同的动作。把它们按时间尺度排开，整个体系会立刻清晰起来。

```mermaid
flowchart TD
    L1["波束级<br/>十毫秒量级"] --> L2["小区级<br/>百毫秒量级"]
    L2 --> L3["位置更新<br/>分钟量级"]
    L3 --> L4["注册与寻呼<br/>事件驱动"]
```

| 刻度 | 典型时延 | 谁测量 | 谁判决 | 主要代价 | 失败后果 |
|---|---|---|---|---|---|
| 波束级调整 | 十几毫秒 | 终端 | 终端（状态机） | 几乎为零 | 单波束失步，重试即可 |
| 小区间切换（连接态） | 几十至几百毫秒 | 终端 | 基站 | 空口中断、上下文转移 | 掉话、速率跌落 |
| 位置/注册更新（空闲态） | 分钟至小时 | 终端 | 终端自决 + 网络确认 | 空口信令开销 | 呼入找不到人 |
| 注册与寻呼 | 事件驱动 | — | 核心网发起 | 寻呼广播开销 | 呼入成功率低 |

四个刻度之间是**逐级兜底**的关系：上一级太慢就靠下一级补，下一级太贵就靠上一级省。

**为什么必须有波束级这一层？** 因为毫米波与大规模天线的窄波束，指向稍有偏差就会掉出主瓣。当"小区"本身是一个几十米宽的波束集合时，只做小区级切换，粒度太粗——用户站在波束边缘就会掉。而波束级的调整在终端侧本地完成，几乎不消耗信令，几毫秒内就能换到相邻波束。**粒度设计的本质是：把能本地解决的事情留在本地解决，只把解决不了的推给网络。**

**为什么位置更新这一层必须"分钟起步"？** 因为它是空闲态唯一的位置来源。如果终端每 30 秒报一次位置，全国网络每天要处理数亿次更新——这不是设备能力问题，而是空口资源根本承载不起。工程上常见的做法是给终端下发一张"区域通行证"（TAI List），允许它在这一片区域内自由走动而不必报位置，只有跨出边界才需要更新。这把"逐小区跟踪"退化成"逐片区跟踪"，是移动性管理里最经典的一次降本设计。

---

## 六、空闲态的"自主搬家"：重选与更新的分工

空闲态有两件事看起来相似，实则分工明确。

**小区重选**回答的是"我该待在哪个小区"，**位置更新**回答的是"我在哪个片区"。前者是终端的本地自治，后者是与网络的位置同步。

重选的核心是一条带迟滞的判决式。设服务小区和邻区的信号质量分别为 $M_s$、$M_n$，则重选通常要求：

$$
M_n > M_s + Q_{\text{offset}} + Q_{\text{hys}}
$$

注意那个迟滞项 $Q_{\text{hys}}$：没有它，处在两个小区信号交叉区域的手机会以极高频率来回换，每次重选都要触发一次位置更新，信令开销瞬间爆炸，用户的业务也会被打断。**迟滞是移动性管理里最便宜也最有效的"防抖器"**，其思路和空调温控器完全一致：不设缓冲区，压缩机就会一秒钟启停三次。

而位置更新（5G 里它是注册流程的一种）则要回答"我是否离开了已知区域"。它的触发原因通常包括：

- 移动出了当前 TAI List 覆盖的范围；
- TAI List 本身发生变化；
- 周期性更新定时器到期——即使终端一动不动，也必须定期"打卡自证存活"。

最后这一条常被低估。它的意义在网络侧：只有终端持续打卡，网络才能确信它还活着；一旦打卡断掉，网络要靠一串级联的定时器（"可达宽限期""隐式去注册"）去判定"这个人已经不在了"，从而停止向它寻呼、释放它的上下文。**没有这套机制，网络会被大量"幽灵用户"占满资源，而且每次呼入都要往这些黑洞里做无用功。**

---

## 七、实战：这套知识在现网怎么用

**场景一：被叫不通的排查顺序**

按上面的迁移地图走一遍，顺序就是固定的：

1. 终端在空闲态还是连接态？空闲态就要看寻呼链路，连接态要看寻呼是否被抑制。
2. 寻呼时机是否对齐？终端的寻呼时机由自身标识与广播参数算出，双方算法必须一致；参数不匹配会导致"网络喊了，终端没醒"。
3. TAI List 是否覆盖了终端实际所在位置？漏配会出现"该区能打进来、旁边区打不进"的诡异现象。
4. 寻呼广播是否拥塞？TAI List 划得太大，广播量激增，可能出现"网络发了，基站丢了"。
5. 终端是否被误判失联而清掉了上下文？查周期更新定时器是否配得过短，IoT 模组尤其容易踩这个坑。

**场景二：切换迟了还是乒乓了**

两者是同一个旋钮的两端。切换判决的触发条件形如邻区优于服务小区一个固定偏置再叠加迟滞，还要叠加一段持续时间条件。偏置和持续时间调大，切换变晚但乒乓减少；调小则相反。工程上的常规顺序是：先调迟滞，再调持续时间，最后才动判决偏置——因为偏置影响面最大，会牵动所有测量事件的响应节奏。

**场景三：信令风暴**

位置更新量突然放大，优先怀疑三个方向：小区重选频繁（迟滞配得太小或干扰导致信号抖动）、跟踪区边界划在了人流密集的通道上（每过一次边界就是一次更新）、以及周期性更新定时器配置不合理。**信令风暴的本质，往往是"边界划在了用户必须频繁穿越的地方"。**

**场景四：非激活态相关的异常**

终端频繁掉回空闲态而不是稳定在非激活态，通常指向挂起定时器配置、承载保持条件、或上下文恢复失败。这类问题在日志里表现为"恢复请求反复重传"，而在用户侧只表现为"打开 App 要多等一两秒"——**用户投诉的严重程度和底层原因的严重程度完全不成比例**，这正是原理知识能帮工程师快速定位的地方。

---

## 八、常见误解

- **"终端一直在上报位置。"** 错。绝大多数时间终端处于空闲/非激活态，只在寻呼时机短暂醒来；位置上报只在跨区域或周期到期时发生。
- **"跟踪区就是小区。"** 错。跟踪区是若干小区的集合，终端拿到的是一片区域而非一个点。
- **"寻呼是网络直接找到手机。"** 错。网络只能在一个区域内广播，真正的"应答"由终端在寻呼时机完成。
- **"切换失败是空口差。"** 错。相当比例的失败来自邻区漏配、PCI 冲突、传输配置缺失——这些是配置问题，不是电平问题。

---

## 常见问题

**Q: 空闲态为什么不也用"切换"，而要另设一套重选机制？**
A: 因为空闲态没有连接、没有上下文，切换这套流程（测量上报、判决、上下文转移、路径切换）在资源上根本不划算。空闲态只需要回答"我该听谁的"，用极轻的广播信息 + 本地判决就能完成，并且顺带完成位置更新。切换是为"正在通话中"准备的，是保业务的手段；重选是为"待着"准备的，是省资源的手段。

**Q: 5G 里还有独立的 TAU 过程吗？**
A: 没有。5G 把附着、位置更新、周期性更新、去附着这些场景统一收敛进了**注册流程**，靠注册类型字段区分。这是一次重要的收敛：4G 时代"附着"和"TAU"是两套流程、两种失败模式，5G 合并后，核心网的状态机更简单，终端的实现路径也更短。

**Q: 非激活态和空闲态，功耗差多少？**
A: 非激活态仍然要按寻呼时机醒来、维持基本同步，所以功耗接近但高于空闲态。它换来的是"上下文还在"——业务再来的话恢复路径短得多。**非激活态是拿一点点电费买响应速度**，适合"刚停下来一会儿还会继续用"的场景，不适合长期静默。

**Q: 迟滞、持续时间、偏置，调哪个最划算？**
A: 先调迟滞。它对其他测量事件的影响最小，却能直接压住乒乓这类由边界抖动引发的误切换。持续时间条件次之，它能过滤掉短时的信号毛刺。判决偏置影响面最广，它决定切换带的位置，改动会牵动全网切换时机，应当留到最后。

**Q: 手机掉电关机，网络怎么知道它不在了？**
A: 靠定时器级联。终端正常关机时会主动去注册告别；非正常掉电时，靠周期更新定时器、可达宽限期、隐式去注册判定逐级确认失联，最终释放上下文并停止寻呼。理解这套机制很重要：它决定了"网络为一个已经不在的用户保留资源多久"——保留太久是资源浪费，太短则会出现用户明明在线却收不到呼入的误判。

---

## 参考来源

1. [LTE Tracking Area (TA) and Tracking Area Update (TAU) — Netmanias](https://netmanias.com/en/post/blog/5930/lte-tau/lte-tracking-area-ta-and-tracking-area-update-tau) — TA、TA List 与位置更新的经典图解，位置上报与寻呼范围的权衡关系
2. [Why is there no Tracking Area Update procedure in 5G? — Apis Training](https://apistraining.com/tracking-area-5g/) — 5G 用注册流程取代独立 TAU 的设计动因与演进脉络
3. [5G NR Handover Procedure — Xn and N2 Handover — ranbits](https://ranbits.com/module12/12-1-handover.html) — 从测量事件触发到路径切换、数据转发的完整信令时序
4. [NR RRC Inactive — Amarisoft Tech Academy](https://tech-academy.amarisoft.com/NR_RrcInactive.html) — 非激活态的上下文保留、寻呼与恢复流程的工程化解析
5. [5G/NR Paging — ShareTechnote](https://www.sharetechnote.com/html/5G/5G_Paging.html) — 寻呼帧与寻呼时机的计算方法，终端与网络侧的算术对齐机制
6. [RRC States Explained: Idle, Connected and Inactive in LTE and 5G NR — Hicelltek](https://hicelltek.com/en/blog/rrc-states-explained-idle-connected-inactive-lte-5g-nr/) — 三态设计的动机与相互差异

---

> 本文由「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)
