很多人对切换的想象是：手机从一个小区"跳"到另一个小区，啪，完了。就像电视剧里的转场，一眨眼人已经到了新地方。
但如果你在现网抓过一次完整切换的信令，会发现它更像一场接力赛的交接棒：裁判先判定该交棒（判决），两位运动员先对好节奏（准备），然后在实际奔跑中完成交接（执行），最后裁判组还要改记分牌，把成绩记到新接力队员名下（路径更新）。任何一幕出问题，棒就掉了——表现在用户的手机上，就是转圈、卡顿，甚至掉话。
先约定一个前提：切换怎么判（测量报告、A3事件、迟滞、触发时间）是另一个话题，本文假定判决已经完成——服务小区已经决定"该把这台手机交给隔壁小区了"。我们要讲的，是判决之后那几十毫秒里，网络内部到底发生了什么。
先看全景：
flowchart TD
A["连接态UE 靠近小区边缘"] --> B["第一幕 测量与报告"]
B --> C["第二幕 切换准备"]
C --> D["第三幕 切换执行"]
D --> E["第四幕 路径切换"]
E --> F["数据彻底改走新路径"]
记住这四幕，后面所有的信令都能装进这个框架里。下面一幕一幕拆。
手机在连接态会持续测量服务小区和邻区的信号质量（RSRP/RSRQ），并按基站下发的条件上报。最经典的判决条件是A3事件，一句话概括：邻区比服务区好出一截，且稳定了一小会儿：
$$M_n > M_s + O_{ff} + H_{ys}$$
其中 $M_n$ 是邻区信号质量，$M_s$ 是服务小区信号质量，$O_{ff}$ 是偏置，$H_{ys}$ 是迟滞。加了迟滞和"持续满足一小段时间"（TTT）之后，信号在边缘上抖来抖去就不会立刻触发切换——这是防"乒乓"的第一道闸门。
手机上报测量报告后，源基站做出切换决策，然后向目标基站发起切换请求。注意一个反直觉的设计：切换是基站自己拍板的，核心网此时并不知情。为什么？因为切换的窗口期只有几十毫秒，如果把核心网拉进来做审批，信令要绕一大圈，时延和失败率都不可接受。所以标准把判决权下放给无线侧，核心网只在最后"补登记"。
紧接着，源基站给手机下发切换指令。这个指令里有几样关键内容：
| 切换指令内容 | 作用 | 为什么必须有 |
|---|---|---|
| 目标小区的物理小区标识（PCI） | 让手机知道去哪个小区 | 防止认错门 |
| 新的调度标识（C-RNTI） | 在新小区的身份凭证 | 新小区不认识旧身份 |
| 专用随机接入前导 | 无竞争接入新小区 | 避免和其他接入请求撞车 |
| 无线参数重配置 | 按新小区的环境重配物理层 | 频点、波束、定时都可能变 |
其中"专用前导"值得一提。随机接入本来是"举手抢话筒"的过程——大家共用一组公共前导，冲突了就退避重试。但切换是网络提前安排好的动作，完全没必要让手机去抢公共资源，所以目标基站专门划一个前导码给这台手机独享，一次就能接入成功。这是把"竞争接入"变成"无竞争接入"，省掉的就是宝贵的切换时延。
切换指令还没发，源基站其实已经先给目标基站打了招呼——切换请求里带着手机的完整上下文：能力、承载、安全信息、当前各层协议状态。目标基站收到后，第一件事是做准入控制：我还有没有足够的无线资源、基带资源接住这个人？接不住就拒绝，源基站另找邻区，或者干脆不切。
准入通过后，目标基站回复切换请求确认，里面还夹带一个"给手机的回执"，由源基站原封不动透传给手机——这就是上文说的切换指令。
接下来是整个流程里最容易被忽略、却最见功力的一步：序号状态转移。
打个比方：快递员（源基站）要把自己手上的一批包裹移交给同事（目标基站），交接时不能只把包裹扔过去，还得附一张交接清单——哪些单号已经签收确认了，哪些还在路上没送到，哪些送过但没等到签收回执。有了这张清单，新快递员才知道：哪些包裹用户已经收了不用管，哪些还得负责送到，甚至哪些要重送。
对应到协议栈，这张清单记录的是PDCP层（负责保序和加密的层）的序号状态：哪些包已经成功送达并确认，哪些还在缓存里等待确认。有了它，目标基站接管后能接着旧进度继续保序和重传，而不是从零开始胡乱编号。没有这一步，切换之后手机收到的数据流序号就会断档或错乱，上层重传风暴，体验瞬间崩塌。
为什么这样设计？ 因为"无缝切换"从来不是靠空口完美的，而是靠协议栈各层把"状态"完整地交出去。切换的本质是状态迁移，空口换小区只是表象。
切换执行期间有个两难：手机已经收到切换指令，正在往新小区跑，可核心网的下行数据还在源源不断地涌向源基站（因为核心网还不知道手机换地方了）。这些"人在途中"的包怎么办？扔掉就是丢包，缓存起来等切换完再发就是时延尖峰。
网络的答案是：转发。切换准备完成后，源基站把自己缓存的数据和陆续到达的新数据，通过基站之间的转发隧道，源源不断地搬给目标基站，由目标基站通过新空口发给手机。这样，从业务的角度看，数据流从来没有中断——这就是5G同频切换"先建后断"（make-before-break）的本质：旧链路活着的时候新链路已经建好，两条腿交替，而不是一条腿先瘸了再跳。
转发路径有两种部署方式：
| 对比项 | 直连转发 | 间接转发 |
|---|---|---|
| 数据路径 | 源gNB → 目标gNB | 源gNB → 核心网中转 → 目标gNB |
| 时延 | 低，一跳直达 | 高，多绕一段 |
| 部署条件 | 两站之间有直连接口 | 不要求直连，借核心网搭桥 |
| 典型场景 | 相邻基站、接口正常时 | 跨大区域、直连不可达时 |
还有一种更精妙的设计，叫终止标记。问题是这样产生的：核心网发出的数据包，切换中有的走了"源基站→转发"的老路，切换完成、路径更新后又直接走"核心网→目标基站"的新路。新旧两条路速度不一样，包就容易乱序——序号10的包坐了慢车，序号15的包坐高铁先到，接收端一看序号乱了，以为丢包，触发重传，白白浪费资源。
终止标记的解法特别朴素：当核心网意识到"这手机要走了"，它向源基站发出的数据流的最后一个包会被打上一个特殊标记。源基站把这个标记原样转发给目标基站。目标基站看到标记的那一刻就明白：旧路上的包到齐了，之后收到的包都是新路上直接来的。以此为界，把两股数据流完美拼接，既不丢也不乱。
flowchart TD
P["UPF 数据锚点"] -->|"下行数据"| S["源gNB"]
S -->|"转发隧道"| T["目标gNB"]
T -->|"新空口收包"| E["UE"]
S -->|"断链前的最后一批"| E
P -.->|"终止标记"| S
S -.->|"标记随转发交割"| T
一句话总结这一幕：丢包不是靠空口零差错避免的，而是靠"缓存+转发+按序交割"这套组合拳兜住的。
前三幕完成，手机已经在新小区收发数据了。但此时核心网的账本还是错的：下行数据的隧道终点仍然写着源基站的地址。每经过一个包，都要走一趟"核心网→源基站→转发→目标基站"的冤枉路。必须尽快改地址。
这就是路径切换：目标基站主动向核心网的AMF报告"这台手机的锚点变了，请把下行隧道改到我这里"。AMF再指挥UPF（负责用户数据的锚点）更新隧道端点，改完之后确认，随后目标基站通知源基站："交接完毕，你可以释放这台手机的上下文了。"源基站释放资源，一场接力正式收官。
看一遍完整的信令时序（以最常见的基站直连切换为例）：
sequenceDiagram
participant U as UE
participant S as 源gNB
participant T as 目标gNB
participant A as AMF
participant P as UPF
U->>S: 测量报告（邻区持续变好）
S->>T: 切换请求（带UE上下文）
T-->>S: 切换请求确认（准入通过）
S->>U: 切换指令（含专用前导）
S->>T: 序号状态转移
S->>T: 数据转发开始
Note over S,T: 两条链路并行，数据不断流
U->>T: 用专用前导随机接入
U->>T: 切换完成确认
T->>A: 路径切换请求
A->>P: 更新下行隧道端点
P-->>A: 更新完成
A-->>T: 路径切换确认
T->>S: 释放UE上下文
这里有个值得嚼一嚼的细节：为什么数据转发期短、路径切换要尽快完成？ 因为转发本质上是一条临时搭建的绕行路，每多待一毫秒，就多一段额外时延和一份转发开销。切换流程设计成"先让用户面通、再让控制面补账"，就是为了把用户感知的中断压到最小——体验优先，行政手续随后办。
顺带说一个现网里极其常见的知识点：上面这套是两座基站之间有直连接口（Xn）时的最优路径。如果两站之间没有直连接口，切换就得绕行核心网，由AMF居中传话，走所谓的NG切换（也叫N2切换）：
| 对比项 | Xn切换（基站直连） | NG切换（绕行核心网） |
|---|---|---|
| 信令路径 | 源gNB ↔ 目标gNB 直接商量 | 源gNB → AMF → 目标gNB |
| 依赖条件 | 两站间配置了直连接口 | 不需要直连，核心网中转 |
| 准备阶段时延 | 低，一跳 | 高，多绕两跳 |
| 数据转发 | 通常直连转发 | 往往走间接转发 |
| 典型场景 | 同厂商相邻站、接口正常 | 跨厂商边界、孤立站点、异频远端 |
工程上要特别注意：Xn切换变成NG切换，用户往往感觉不到，但切换时延会明显变长，切换失败率也会水涨船高。排查切换类投诉时，先确认这段邻区关系走的是哪条路，经常能少走半天弯路。
控制面的信令讲完了，回头看用户真正关心的：切换瞬间，我的数据到底停了多久？这段"中断时间"可以近似拆成三段：
$$T_{中断} \approx T_{指令处理} + T_{随机接入} + T_{调度恢复}$$
整个量级通常在几十毫秒级别。对刷网页、看视频的用户，这就是一个轻微的时延毛刺；对实时业务，几十毫秒已经足够让语音电话"咯噔"一下——好在实时语音宁可丢包也不重传，毛刺过去就过去了。
为了进一步压这个数字，协议还演进出了更激进的做法：让手机在切换期间同时驻留新旧两个小区收发数据（双活动协议栈类机制），新旧链路一起供数，彻底消灭中断窗口。原理还是本文讲的这套——转发加状态转移——只是把"两条腿交替"升级成"两条腿一起跑"。标准在此类特性上允许多种实现选择，具体支持程度以各厂家官方文档为准。
接力赛最怕掉棒。切换也有失败的可能：手机发了测量报告却迟迟等不到切换指令；或者收到了指令，却怎么也接不进目标小区。协议对此的处理逻辑很朴素——限时，超时就撤：
flowchart TD
A["切换执行中"] --> B{"在T304内完成切换？"}
B -->|"是"| C["切换成功"]
B -->|"否"| D["回退并搜索信号最佳小区"]
D --> E["发起RRC重建请求"]
E --> F{"该基站留有UE上下文？"}
F -->|"是"| G["重建成功，业务快速恢复"]
F -->|"否"| H["连接释放，重新入网"]
手机启动切换时会顺手开一个守护定时器（T304）：如果在限期内没能完成在新小区的接入，就宣告切换失败，回到无线链路重建流程——在附近小区里挑信号最好的一个，尝试恢复连接。能否快速恢复，取决于接住它的基站手里有没有这台手机的上下文（常见于切换目标基站本身，或与源站有联络的基站）：有，几百毫秒内业务恢复；没有，只能整体重新入网，用户感受就是"掉了，转圈重连"。
看KPI定位问题。 切换成功率类指标出问题，先按四幕剧拆解：是测量报告发了没收到指令（第一幕断），是指令下了没接入成功（第三幕断），还是路径切换迟迟没完成（第四幕拖）。断在不同幕，根因完全不同——漏配邻区、参数过紧、物理问题（PCI混淆、越区覆盖）、接口故障，各有各的指纹。
PCI混淆是经典陷阱。 源基站在邻区表里搜"该切给谁"，如果两个相邻小区的PCI在某个方位角上出现歧义，源基站可能把切换请求发给一个"根本看不见这台手机"的小区，请求石沉大海。这类问题在信令上表现为切换请求无响应，在地图上表现为某些特定方向切换必失败——画一张PCI邻区图，往往一目了然。
乒乓切换要靠参数治。 两个小区信号犬牙交错，手机来回横跳。治理手段就是第一节那道公式：调大迟滞、拉长TTT、给边界小区设置个性化偏置。本质上都是给判决加"惯性"，让手机别那么敏感。
切换慢≠空口差。 一个常见误解是切换时延大就是无线环境糟糕，实际上接口路径（走了绕行核心网的切换）、准入排队、转发方式（间接转发多绕一跳）都会显著拉长时延。空口只是候选人之一，别上来就吊死在天线上。
还有两个流传甚广的误解顺手澄清：其一，"切换是核心网指挥的"——同制式内的切换决策权在无线侧，核心网只做路径登记；其二，"切换瞬间必丢包"——设计良好的切换在协议栈视角是无损的，缓存转发加按序交割兜底，用户感知到的只是时延毛刺，不是数据丢失。
Q: 切换瞬间到底会不会丢包？ A: 协议栈设计目标是无损：切换期间源基站缓存并转发数据、序号状态随切换移交、终止标记保证新旧数据流按序拼接。理想情况下不丢包，用户感知的是几十毫秒的时延毛刺。但如果切换失败走重建，未经确认的数据就要靠上层重传来补，那才是真正的"丢"。
Q: 切换是谁决定的？核心网参与吗？ A: 同制式内的连接态切换由无线侧自主判决、自主执行，核心网全程不知情，直到切换完成后接收路径切换登记。这样设计是为了把判决链路压到最短。跨制式互操作等特殊场景核心网才会深度介入。
Q: 为什么有些切换特别慢？ A: 先查走了哪条路：两站之间没有直连接口时，信令和数据都要绕行核心网，时延自然翻倍。再查转发方式是直连还是间接、准入是否被拒过、目标小区随机接入是否干净。空口信号差只是慢的可能原因之一。
Q: 乒乓切换怎么治？ A: 给判决加惯性：增大迟滞、拉长触发时间、对边界小区配置个性化偏置，让"邻区略好"不足以触发切换，只有"显著好且稳定"才动。同时排查是否存在越区覆盖把两个小区硬生生揉成了邻居。
Q: 切换失败后手机会做什么？ A: 守护定时器超时后，手机脱离当前配置，按重选规则搜索信号最佳的小区发起连接重建。若对方保有该手机上下文（如切换目标基站），恢复很快；否则释放连接重新入网，用户感受为掉话后重连。
本文由「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 等场景全覆盖。