# 切换、寻呼与位置更新：手机搬家为什么不断网 ## 一、从一个类比说起：一部永远接得通的电话 想象你一边打电话一边从公司走到家里。你的手机会先后经过十几个基站的服务范围，但电话始终没断——这就是**切换**（Handover）在背后默默完成的工作。 再想象你开着手机待机躺在床上。为了省电，手机其实处于“深度睡眠”，一天里绝大部分时间根本不听网络说话。这时朋友打来电话，网络却能精准地“喊醒”你——这就是**寻呼**（Paging）的功劳。 最后想象你出差去了另一个城市。你的“户籍地址”变了，但快递依然能找到你——因为网络里有一套**位置登记**机制（4G叫TAU，5G叫移动性注册更新），在悄悄替你更新着档案。 这三个机制合起来，就是移动通信的立身之本——**移动性管理**（Mobility Management）。蜂窝网络和Wi-Fi最本质的区别不在网速，而在于：**Wi-Fi假设你坐着不动，蜂窝网络假设你永远在路上**。 ## 二、根本矛盾：省电和被找到，只能二选一吗 移动性管理要解决的核心矛盾是一个经典的两难： - **手机必须让网络知道自己在哪**，否则来电话、来微信都找不到你； - 但**时刻向网络汇报位置太费电**——无线发射是手机最耗电的操作之一，如果每隔几秒就“广播”一次位置，智能手机的电池撑不过半天。 蜂窝网络的解法非常聪明：**把“精确定位”降级成“范围定位”**。网络不需要知道你在哪个小区，只需要知道你在**哪一片**，打电话时再临时喊话精确定位。这就像快递系统：快递员不需要实时追踪你的坐标，只知道你的收件地址在哪个片区，包裹到了去那个片区喊你的名字就行。 这个思路催生了移动性管理的三件套，它们分别对应三个问题： | 机制 | 回答的问题 | 工作状态 | 类比 | |---|---|---|---| | 位置更新 | 你在哪一片？ | 空闲态，低频 | 搬家后去派出所改户籍 | | 寻呼 | 精确到这个小区！ | 被叫时刻，一次性 | 快递员到小区喊人 | | 切换 | 移动中保持业务 | 连接态，高频 | 边打电话边搬家 | 理解了这三件套的分工，我们再深入每一个的内部原理。 ## 三、状态机：三个状态，三套玩法 5G把手机的连接状态分成了三档（4G只有前两档），不同的状态用不同的移动性策略： ```mermaid flowchart TD A[空闲态 Idle] -->|手机主动发业务| B[连接态 Connected] B -->|连接释放| A B -->|释放但保留锚点| C[非激活态 Inactive] C -->|手机主动发业务| B C -->|网络寻呼唤醒| B A -->|网络寻呼唤醒| B C -->|锚点超时失效| A ``` 为什么要发明中间的“非激活态”？因为很多业务是“脉冲式”的——聊几句停几分钟。频繁在空闲态和连接态之间进出，每次都要走完整流程（随机接入、安全激活、上下文建立），信令开销大、时延高。非激活态相当于“人已下班但工牌还在公司”：手机睡了，但基站的上下文、安全密钥都还留着，回来干活时几步就能恢复。 **这个状态机决定了移动性管理的基本格局**：连接态靠切换无缝搬家，空闲态靠重选+位置更新低调挪窝，非激活态介于两者之间（用的是一套更轻量的“RAN寻呼”，后文详述）。 ## 四、位置登记：TA、TA列表与“户籍片区” ### 4.1 跟踪区：给基站画格子 网络把若干相邻的小区打包成一个**跟踪区**（Tracking Area，TA），每个TA有一个编号（TAC），加上运营商网络标识后构成全球唯一的**TAI**。你可以把TA理解成邮政编码：一个编码覆盖一片区域，区域内所有小区共享这个编码。 空闲态手机在小区之间移动时（通过**小区重选**，这是另一个已讲过的话题），会留意新驻留小区的TAC。这里就出现了一个关键设计问题：**手机什么时候该向网络汇报“我挪窝了”？** - 每换一个小区就汇报一次？太费电，也浪费信令资源——空闲态换小区太频繁了。 - 永远不汇报？那网络就找不到你了。 标准答案是**TA列表**（TA List）：注册时，核心网（5G是AMF）会分配给手机**一组**TA，而不是一个。只要手机重选后驻留的小区还在这组TA的范围内，就保持安静；一旦走进列表之外的TA，才发起一次**移动性注册更新**，网络顺便重新分配一个新的TA列表。 ```mermaid flowchart TD A[空闲态驻留中] --> B[小区重选到新小区] B --> C{新小区TAC在列表内?} C -->|在| D[保持安静继续睡觉] C -->|不在| E[发起移动性注册更新] E --> F[AMF刷新登记与TA列表] F --> G[更新完成回到睡眠] ``` ### 4.2 为什么是“一组”TA？为了对付边界上的犹豫者 想象你住在两个TA的分界线上，窗口正对着边界另一侧的信号塔。无线信号不会画地为牢，你手机看到的邻区信号忽强忽弱，驻留小区可能来回摆动。如果登记单位是单个TA，你每过一次界就要发一次注册更新——站在窗口边晃悠五分钟，能产生几十条信令。这就是**信令风暴**的微观成因之一，而“TA列表”设计让更新频率直接降了一个数量级：只有彻底走出“这一整组片区”才需要重新登记。 这个设计哲学值得记住：**用“模糊的范围”换取“极低的更新频率”，是所有位置管理系统的第一原则**。寻呼范围的划定也遵循同样的逻辑——网络喊你的范围，正是这个TA列表。 ### 4.3 术语对照：4G和5G叫法不同 | 概念 | 4G叫法 | 5G叫法 | 说明 | |---|---|---|---| | 片区编号 | TAI（TAC） | TAI（TAC） | 逻辑不变 | | 登记范围 | TA列表 | TA列表（注册区域内） | 5G还有基于RAN的编号区 | | 更新流程 | TAU（跟踪区更新） | 移动性注册更新 | 5G统一并入注册流程 | | 核心网管家 | MME | AMF | 职责类似 | | 中间状态 | 无 | RRC INACTIVE | 5G新增 | 工程上有个常见误区：5G语境下说“TAU”通常指4G流程，5G里对应的动作是**移动性注册更新**（Mobility Registration Update），它是5GC统一注册管理流程的一种类型——逻辑上与TAU一脉相承，但消息和流程已完全重新设计。看现网信令时注意别把两代术语混为一谈。 ## 五、寻呼：如何在手机睡觉时找到它 ### 5.1 核心设计：约定时刻的“查岗” 寻呼的难题在于：手机在空闲态是**深度睡眠**的，接收电路大部分时间关闭，这是续航的命根子。但网络随时可能来电话。 解法是**不连续接收**（DRX）：网络和手机提前约定好一个**寻呼周期**——比如每1.28秒（或其他配置值）为一个轮回。每个轮回中，手机只在一个由它自己的“代号”算出来的特定帧、特定时刻（PF/PO，寻呼帧/寻呼时机）短暂睁开眼，听一耳朵有没有喊自己的名字，然后继续睡。 关键在于：**醒来的时刻由手机自己的代号决定，且手机和网络双方用同一个公式独立计算**——手机不需要向网络申请“我几点醒”，网络也不用逐一通知。两边看同一张时刻表，这就是非同步系统里最优雅的协作方式。 教科书式的计算思路是这样的：把临时身份标识（5G里是网络分配的短代号）对周期内的寻呼岗总数取余，余数决定站哪班岗： $$SFN_{PF} = T \times (\,UE\_ID \bmod N\,) + offset$$ 其中 $T$ 是寻呼周期（以无线帧计），$N$ 是周期内划分的寻呼岗数量，$UE\_ID$ 是网络分配的临时身份号。直观理解：把每个周期想象成“每 $T$ 帧一个班次”，班次里设了 $N$ 个岗哨，你的编号除以岗哨数取余，余几就站第几岗。这样所有手机被**天然均匀打散**到不同的醒来时刻，避免同一瞬间全部睁眼挤爆寻呼信道。 ### 5.2 寻呼的完整旅程 一切就绪后，一次完整的被叫寻呼是这样的： ```mermaid sequenceDiagram participant N as 主叫网络 participant A as AMF participant G as gNB participant U as 手机 N->>A: 有人呼你查位置 A->>A: 查TA列表登记范围 A->>G: 向列表内所有基站发寻呼 G->>U: 在各手机约定的时刻广播 U->>G: 醒来听到自己代号应答 U->>G: 随机接入转连接态 G->>A: 该用户位置已确认 A->>N: 建立承载接通 ``` 注意一个重要细节：**寻呼不是全网广播**。AMF只向手机TA列表覆盖的基站发寻呼——这正是位置登记的回报时刻。如果你刚出差到外地还没来得及注册更新，寻呼发不到你所在的片区，电话就会漏接。这也是“寻呼无响应”类故障最常见的根因之一：**登记范围与实际位置脱节**。 ### 5.3 两本地址簿：CN寻呼与RAN寻呼 5G的非激活态引入了一套双层寻呼：**CN寻呼**管“跨大区找你”，范围是TA列表；**RAN寻呼**管“锚点基站的小地盘”，范围是基站自己掌握的编号区。手机若在自己“老东家”的地盘附近活动，只需要响应轻量的RAN寻呼，不用惊动核心网——这是5G为高频小包业务（如即时消息心跳）专门优化的设计：把大部分寻呼消化在无线侧，核心网信令面压力大幅下降。 ## 六、切换：连接态的无缝搬家 现在进入本文的重头戏。位置更新和寻呼都发生在空闲态，丢了也无大碍——大不了重连一次。但**切换发生在业务进行中**：你的视频会议、你的游戏对局正在跑，切换失败的直接后果是掉话或卡顿。它对**时延**和**可靠性**的要求苛刻得多。 ### 6.1 与小区重选的本质区别 | 维度 | 小区重选（空闲态） | 切换（连接态） | |---|---|---| | 谁主导 | 手机自主决定 | 基站决策指挥 | | 时序 | 先断后连（离网再选） | 先连后断（接上新再放旧） | | 业务影响 | 无业务，用户无感 | 业务连续，必须无损 | | 判断依据 | 重选优先级与门限 | 测量报告+偏置+迟滞 | | 失败后果 | 重选别的即可 | 可能掉话，需重建 | 一句话总结：**重选是“裸辞再找工作”，切换是“骑驴找马”**。后者难度高得多——你要在保住现有工作的同时，无缝衔接下一家。 ### 6.2 切换三部曲：测量、决策、执行 **第一步：测量与A3事件。** 手机持续测量服务小区和邻区的信号质量（如RSRP/RSRQ）。但不是“邻居稍微好一点就上报”——那样太抖了。网络设置了多重防抖闸门，最经典的是**A3事件**，其进入条件的直觉表达： $$M_n > M_s + O_{a3} + H_{ys}$$ 即：**邻区质量 $M_n$ 要比服务小区 $M_s$ 高出偏置 $O_{a3}$ 加迟滞 $H_{ys}$**，并且**持续满足一段时间**（触发时间TTT）才上报。三个参数各司其职： - **偏置（a3-Offset）**：邻居要“好出多少”才算数，控制切换的激进程度； - **迟滞（Hys）**：防止信号在门限附近抖动导致的来回翻转； - **触发时间（TTT）**：毛刺过滤器，信号短暂变好不算，持续好一段时间才触发。 此外还有**小区个体偏移（CIO）**，可以针对“某一对小区”单独加减偏置——比如高铁场景下，想让手机早点切向下一个覆盖小区，就给那一对小区配正的CIO，提前触发切换。 **第二步：决策与准备。** 源基站收到测量报告后自行判断是否切换、切向谁。注意：**切换决策权在基站，不在核心网**——这是很多新工程师的误解。基站间若存在直连接口（Xn链路），切换准备工作直接在两站之间完成，核心网只在最后“改个门牌”。 **第三步：执行。** 这是精妙所在，我们用信令时序图完整走一遍： ```mermaid sequenceDiagram participant U as 手机 participant S as 源基站 participant T as 目标基站 participant A as AMF U->>S: 测量报告邻区持续变好 S->>T: Xn直连发切换请求 T->>S: 资源准入同意回确认 S->>U: 重配置交付新小区钥匙 S->>T: 转交序号状态与在途数据 U->>T: 向新小区随机接入 T->>A: 请求改下行数据隧道 A->>T: 隧道已改指向新站 A->>S: 旧站可以释放了 ``` 这张图里有三个值得咀嚼的设计细节： **细节一：“钥匙”提前交付。** 源基站下发的切换命令里，已经包含了目标小区的专用配置——新的小区标识、随机接入资源、安全密钥的衍生参数。手机到了新小区不需要“从零开始问路”，直接用钥匙开门（无竞争随机接入），把切换中断时间压到几十毫秒量级。 **细节二：序号交接——数据不丢不重的秘密。** 切换瞬间，天上和链路上还有“在途数据”：有些包已经发给你、手机还没确认；有些包堵在传输路上没落地。切换时，源基站把**序号状态**（发到哪了、收到哪了）通过Xn转交给目标基站，配合**数据转发**（源站把缓存和后续收到的下行包转发给目标站）。接收端按序号重排序去重，就实现了**无线侧先断后连、数据侧却无缝衔接**的效果——这就是确认模式业务“切换零丢包”的原理基础。 **细节三：核心网只做“改门牌”。** 注意AMF出现在流程的尾部而不是开头——它的工作只是把下行数据的隧道终点从源基站改成目标基站（路径转换）。数据通道在这之后改道，之前堵在路上的数据靠源站转发兜底。整个切换的“大脑”始终在无线侧。 ### 6.3 备胎方案：NG切换 如果源基站和目标基站之间**没有Xn直连链路**（比如跨厂商边界、传输规划未打通），切换信令就得绕道核心网走全程——这叫NG切换： ```mermaid sequenceDiagram participant U as 手机 participant S as 源基站 participant A as AMF participant T as 目标基站 U->>S: 测量报告邻区变好 S->>A: 无直连改走核心网 A->>T: 转发切换请求 T->>A: 准入同意回传 A->>S: 下达切换命令 S->>U: 重配置换小区 U->>T: 随机接入新小区 T->>A: 切换完成通知 ``` 两者对比一目了然： | 维度 | Xn切换 | NG切换 | |---|---|---| | 信令路径 | 两站直连 | 绕道AMF中转 | | 切换时延 | 低 | 明显更高 | | 核心网角色 | 事后改隧道 | 全程参与调度 | | 前置条件 | 站间有直连链路 | 只要核心网可达 | | 典型场景 | 同厂商密集城区 | 异厂商边界、Xn未配置 | NG切换不是“更差的切换”，而是**传输条件不具备时的兜底**。但现网中若发现大量本可走Xn的流量落在NG切换上，往往意味着邻区/Xn配置有疏漏——这是网络优化的经典抓手。 ### 6.4 切换失败了怎么办 切换不是总能成功。手机收到切换命令后向新小区随机接入，若迟迟得不到响应（比如新小区资源已被抢占、空口质量骤降），手机不会傻等——它会判定**无线链路失败**，转而搜索周围可用小区发起**RRC重建立**。重建成功则业务恢复（可能回退到旧小区或接入第三方小区，会有短暂卡顿但不断线）；重建也失败，才真正掉话。 理解这条失败恢复链路对调试至关重要：**切换失败≠掉话，两者之间还隔着一次重建的机会**。看话统指标时，切换成功率、重建成功率、掉话率是三个要分开看的层级，混在一起会误判问题位置。 ## 七、实战连接：现网中这三个原理藏在哪里 **场景一：乒乓切换整治。** 某路段话统显示两个小区之间每小时切换上百次，信令开销大、用户感知卡顿。用本文的原理分析：这就是迟滞（Hys）和触发时间（TTT）设置不足以过滤边界信号抖动，配合CIO微调让切换点偏离信号交叠中心，三参数组合下药。 **场景二：被叫不通排查。** 用户投诉电话打不进来。排查路径天然沿着寻呼链路走：登记的TA列表是否覆盖用户实际位置（登记问题）？寻呼消息是否下发了（核心网问题）？手机是否在约定的时刻醒来并应答（终端/空口问题）？本文的时序图就是排查的“地图”——每一环节对应一类故障。 **场景三：高铁专网规划。** 高铁时速350公里，每秒约100米，正常切换参数来不及完成“测量—决策—执行”。运营商的高铁专网会拉大重叠覆盖带、调快切换参数、用CIO让切换“提前起跑”——全部都是本文原理的工程化应用。 **调试陷阱提醒**：切换参数不是万能药。空口质量差导致的测量报告失真、传输链路抖动导致的信令时延，症状都像“切换问题”，根因却在别处。先看测量报告的原始质量，再动切换参数——这是老师傅和新手的分水岭。另外，标准在多种实现方式上允许厂家有不同的具体行为，实际参数含义与默认值以所用设备厂商的官方文档为准。 ## 八、常见误解澄清 **误解一：切换是核心网指挥的。** 恰恰相反，测量、决策、执行的主导权全在无线侧，Xn切换里核心网只在最后改个数据隧道方向。核心网介入越深（NG切换），切换越慢。 **误解二：切换瞬间会丢包，所以视频会议切换时会卡。** 设计良好的切换里，序号交接+数据转发保证了确认模式业务无损（用户感知的“切换卡顿”更多来自无线侧几十毫秒的传输中断和速率恢复过程，而非丢包）。 **误解三：寻呼是全网大喊。** 寻呼只发生在登记的TA列表范围内，且每个手机只在自己专属的时刻醒来听——全网广播既浪费空口资源，也唤醒不了在睡觉的手机。 **误解四：5G的TAU和4G是一回事。** 逻辑同源，但5G已将位置更新并入统一的注册管理流程（移动性注册更新），并新增了非激活态的RAN寻呼层，两代机制的消息流程完全不同。 ## 常见问题 **Q: 切换和小区重选到底差在哪？** A: 差在状态和时序。重选发生在空闲态，手机自己做主，先断开再找新家，没有业务所以无所谓“无缝”；切换发生在连接态，基站指挥，先接上新小区再放掉旧的，全程保业务。可以记成：重选是自由行，切换是有导游的团队转移。 **Q: Xn切换和NG切换，现网哪个更常见？** A: 连续同厂商覆盖区域内，Xn切换占绝对多数，因为它快。NG切换主要出现在异厂商边界、Xn链路未开通或故障的场景。如果你在路测中发现本应Xn直连的两站频繁走NG切换，先查站间传输和Xn配置，而不是去调切换参数。 **Q: 为什么寻呼范围用TA列表，不精确到小区？** A: 精确到小区意味着手机必须随时汇报位置，空闲态就废了——省电和被找到不可兼得。TA列表是折中：登记时精确一次，寻呼时在小范围内广播式喊话。范围越小寻呼开销越小，但位置更新越频繁；范围越大则相反。TA列表的粒度就是运营商在这个天平上的落点。 **Q: 手机在切换命令里拿到的“钥匙”是什么？** A: 一整套开箱即用的目标小区接入配置：目标小区标识、专用的随机接入资源、切换后使用的新安全密钥参数（由算法从原密钥衍化而来，目标基站不掌握完整旧密钥，保证前向安全）。有了它，手机到新小区直接无竞争接入，省去了普通随机接入的冲突解决过程。 **Q: 没接到寻呼电话，一定是网络问题吗？** A: 不一定。可能是登记位置与实际不符（长时间飞行模式后位置信息过期）、寻呼时刻手机确实在睡觉但没听到（深覆盖弱场）、也可能手机应答了但随机接入失败。排查时要按寻呼时序图的链路逐段定位，别上来就怀疑寻呼参数。 ## 参考来源 1. [Handover - Wikipedia](https://en.wikipedia.org/wiki/Handover) — 蜂窝切换机制的总览词条，覆盖硬切换/软切换概念与移动性管理脉络 2. [Tracking area update - Wikipedia](https://en.wikipedia.org/wiki/Tracking_area_update) — 位置更新的触发条件与流程概述 3. [ShareTechnote](https://www.sharetechnote.com/) — 通信工程师社区知识库，站内 Handover、Paging 专题有大量信令流程图解与实测示例 4. 《5G无线网络规划与优化》（人民邮电出版社）— A3事件参数工程经验、切换类指标优化案例 5. 《通信原理》（樊昌信等，高等教育出版社）— 同步与定时、DRX类间歇接收设计的数学基础 --- > 本文由「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 等场景全覆盖。