切换接力：终端如何无缝换基站

你正坐在高铁上视频通话，窗外的基站一个接一个地往后退，可画面始终流畅、声音从未断过。这背后是一场你看不见的"接力赛"——网络在毫秒级时间内，把你的数据流从旧基站交到新基站手里，整个过程不能掉一个包、不能断一帧。这就是移动性管理要解决的核心问题。

前面我们讲过"测量事件A1~A6：切换的触发密码"，回答了"什么时候该切换"。今天这一篇，我们要回答的是切换被触发之后，网络到底做了什么——信令如何接力、数据如何不丢、核心网如何配合。我们会把切换流程、TAU（跟踪区更新）和寻呼这三件移动性管理的头等大事，用信令时序图一次讲透。

一、移动性管理的根本矛盾

先抛出一个看似简单的问题：网络为什么不能一直让终端连着同一个基站？

答案藏在无线信号的物理特性里。电磁波在自由空间的传播损耗满足：

$$P_{rx} = P_{tx} \cdot G_t \cdot G_r \cdot \left(\frac{\lambda}{4\pi d}\right)^2$$

接收功率 $P_{rx}$ 与距离 $d$ 的平方成反比。也就是说，终端每远离基站一倍距离，信号强度就掉到原来的四分之一。一个基站的覆盖半径通常只有几百米到几公里，而人是在不断移动的。信号一旦衰减到无法可靠解码，就必须换一个更近的基站来服务——这就是切换（Handover）存在的物理必然性。

为了调和这个矛盾，移动通信系统设计了一整套精巧的机制。理解这套机制，先要分清楚终端的两种状态。

二、两种状态，两套逻辑：空闲态 vs 连接态

终端在网络中有两个核心状态，对应完全不同的移动性处理方式：

维度	RRC_IDLE（空闲态）	RRC_CONNECTED（连接态）
是否有RRC连接	无	有
是否分配空口资源	无（除接收寻呼外）	有专用无线承载
网络知道终端在哪吗	只知道在某个"跟踪区列表"内	精确知道在哪个基站哪个小区
移动由谁主导	终端自主（小区重选）	网络主导（切换）
信令开销	极小，终端大部分时间在睡觉	实时，毫秒级
位置更新机制	TAU（跟踪区更新）	切换（Handover）
网络找终端的方式	寻呼（Paging）	直接调度（已有连接）

这张表是理解一切的基石。空闲态的终端，网络不知道它在哪个小区，只粗略知道它在哪片"跟踪区"里；连接态的终端，网络实时盯着它，随时准备切换。 这就引出三条主线：连接态靠切换搬家，空闲态靠TAU报位置、靠寻呼被找到。

三、切换的本质：一次无损接力

切换（Handover）的本质，是在终端还在通信的过程中，把它的控制面连接和用户面数据通道从源基站搬到目标基站。整个过程被拆成三个阶段，像接力赛的三个环节：

flowchart LR
    A["准备阶段<br/>Preparation"] --> B["执行阶段<br/>Execution"]
    B --> C["完成阶段<br/>Completion"]
    style A fill:#e3f2fd,stroke:#1565c0
    style B fill:#fff3e0,stroke:#e65100
    style C fill:#e8f5e9,stroke:#2e7d32

注意一个关键点："预订"在先、"搬家"在后。这就是所谓的"先建后断"（Make-before-break）思想——在终端断开旧基站之前，新基站的资源已经准备好了。这样切换中断时间（Interruption Time）才能被压到几十毫秒以内：

$$T_{interruption} \approx T_{RRC\text{-}cmd} + T_{retune} + T_{RA\text{-}resp}$$

其中 $T_{retune}$ 是终端调谐到新频点的时间，$T_{RA\text{-}resp}$ 是随机接入过程的时间。提前准备资源，正是为了把这两个分量之外的不可控因素清零。

那么，源基站和目标基站之间"预订资源"的信令走哪条路？这就要分两种情况了——Xn切换和N2切换。

四、Xn切换：基站之间的"直通车"

如果源基站和目标基站之间存在Xn接口（基站之间的直连逻辑接口），它们就可以绕开核心网，直接对话。这种切换叫基于Xn接口的切换，是现网中最常见的切换方式，延迟最低。

sequenceDiagram
    participant UE as 终端 UE
    participant Src as 源 gNB
    participant Tgt as 目标 gNB
    participant AMF as 核心网 AMF
    participant UPF as 用户面 UPF

    UE->>Src: ① 测量上报 (Measurement Report)
    Note over Src: ② 切换判决
    Src->>Tgt: ③ Xn: 切换请求 (HO Request)
    Note over Tgt: ④ 接纳控制 + 资源预留
    Tgt->>Src: ⑤ Xn: 切换请求确认 (含RRC重配)
    Src->>Src: ⑥ 建立数据转发隧道
    Src->>UE: ⑦ RRC Reconfiguration (切换命令)
    Src->>Tgt: ⑧ SN状态转移 (SN Status Transfer)
    par 终端搬家
        UE-->>Src: 断开
        UE->>Tgt: ⑨ 随机接入 + 同步
    and 数据转发
        UPF->>Src: 下行数据
        Src->>Tgt: ⑩ 转发未发送的包
    end
    Tgt->>AMF: ⑪ N2: 路径切换请求 (Path Switch)
    AMF->>UPF: ⑫ 切换N3下行隧道到目标
    UPF-->>Tgt: 下行数据直送新基站
    Tgt->>Src: ⑬ Xn: UE上下文释放
    Note over UE,Tgt: 切换完成，业务无感

第③步——Xn切换请求。源基站直接通过Xn接口把"终端的画像"发给目标基站：包含终端的能力、当前建立的PDU会话、各QoS流的参数、安全上下文等。目标基站据此判断"我接得住吗"。

第④步——接纳控制。目标基站评估自己的无线资源和算力，决定是否接收。这一步直接决定了切换成功还是失败。如果目标基站过载，它会拒绝，源基站只能另选目标或暂缓切换。

第⑧步——SN状态转移（Sequence Number Status Transfer）。这一步是无损切换的灵魂，后面专门讲。

第⑩步——数据转发。在核心网下行隧道还没改道到目标基站的这段"窗口期"里，源基站把还没发给终端的下行包，以及刚收到的上行包，通过Xn接口的转发隧道送给目标基站。这样终端在新基站那边不会"丢包"。

第⑪步——路径切换请求（Path Switch）。目标基站接上终端后，主动通过N2接口通知AMF："数据隧道改到我这里来吧。" 这是Xn切换最巧妙的地方——整个切换过程核心网几乎没参与，直到最后才被"告知"换路。所以Xn切换又叫"事后通知"型切换。

第⑬步——上下文释放。目标基站告诉源基站"接力完成，你可以把终端的上下文删掉了"，源基站释放占用的资源，整个流程收尾。

五、N2切换：核心网当裁判

如果源基站和目标基站之间没有Xn接口（比如分属不同厂商但未配置Xn、或者跨AMF服务区），基站之间说不上话，那就得请核心网的AMF来当中间人传话。这种切换叫基于N2接口（NG接口）的切换。

sequenceDiagram
    participant UE as 终端 UE
    participant Src as 源 gNB
    participant AMF as 核心网 AMF
    participant SMF as 会话管理 SMF
    participant Tgt as 目标 gNB

    UE->>Src: ① 测量上报
    Note over Src: ② 切换判决（无Xn可用）
    Src->>AMF: ③ N2: 切换要求 (Handover Required)
    AMF->>SMF: ④ 要求建立间接转发隧道
    SMF-->>AMF: 转发隧道信息
    AMF->>Tgt: ⑤ N2: 切换请求 (Handover Request)
    Note over Tgt: ⑥ 接纳控制 + 资源预留
    Tgt->>AMF: ⑦ N2: 切换请求确认
    AMF->>Src: ⑧ N2: 切换命令 (含RRC重配)
    Src->>UE: ⑨ RRC Reconfiguration
    par 终端搬家
        UE->>Tgt: ⑩ 随机接入 + 同步
    and 间接数据转发
        Src->>UPF: 转发数据
        UPF->>Tgt: 转发数据
    end
    Tgt->>AMF: ⑪ N2: 切换通知 (Handover Notify)
    Note over AMF,SMF: ⑫ 核心网切换N3隧道到目标
    AMF->>Src: ⑬ N2: UE上下文释放

第一，信令路径不同。 Xn切换是"基站—基站"的直线，N2切换是"基站—AMF—基站"的折线。多一跳，时延就高一截。

第二，核心网介入时机不同。 Xn切换是事后通知，N2切换是事前请示——必须AMF同意、目标基站准备好，终端才能动身。

第三，数据转发方式不同。 这是实战中最容易被忽略、却最影响性能的差异。

六、数据转发：直接转发 vs 间接转发

切换时终端在"搬家"，但下行数据还在源源不断地往旧基站送。这部分"在途数据"怎么办？系统设计了数据转发（Data Forwarding）机制，把源基站的包转给目标基站。转发分两种：

转发方式	直接转发（Direct）	间接转发（Indirect）
典型场景	Xn切换	N2切换（无Xn）
转发路径	源gNB → 目标gNB（走Xn）	源gNB → UPF → 目标gNB
中间节点	无，直达	UPF中转
时延	低	较高
隧道建立方	源/目标gNB直接协商	SMF参与建立
隧道数量	每QoS流一条Xn隧道	经UPF中转

为什么N2切换要走UPF绕一圈？ 因为源基站和目标基站之间根本没有直达的Xn隧道，数据送不过去，只能"借道"核心网的UPF。UPF本来就在数据路径上，让它临时当个中转站是顺理成章的事。这段转发隧道是临时的，等核心网下行隧道改道完成（路径切换）后就会被拆除。

理解了转发的差异，你就能解释一个现网现象：跨厂商边界、跨AMF区域的切换，往往比同区域的切换更慢、丢包略多——根子就在间接转发的绕行路径上。

七、SN状态转移：无损切换的"记账法"

切换要做到"不丢一个包、不重一个包"，光有数据转发还不够，还必须解决一个核心问题：源基站和目标基站对"已经发到第几号包"的记账必须对齐。

5G用PDCP层维护一个序列号（SN, Sequence Number）。每个数据包都被编上号，发送方按号发，接收方按号收、按号排序去重。切换时如果序号对不齐，轻则重复包、重则丢包。

SN状态转移（SN Status Transfer）就是干这件事的——源基站把自己"发到哪个下行SN了""收到哪个上行SN了"这些账本数据，原原本本交给目标基站：

flowchart LR
    subgraph 源基站账本
        A1["下行已发SN = 100"]
        A2["上行期望SN = 200"]
        A3["未确认的下行包<br/>转发给目标"]
    end
    subgraph 目标基站账本
        B1["下行从SN=101接着发"]
        B2["上行从SN=200接着收"]
        B3["接收转发的包并排序去重"]
    end
    A1 --> B1
    A2 --> B2
    A3 --> B3
    style A1 fill:#fff3e0
    style A2 fill:#fff3e0
    style B1 fill:#e8f5e9
    style B2 fill:#e8f5e9

有了这套记账法，终端在新基站那边收到的包序列是连续的、无重复的。这就是"无损切换"的真正含义——不是不丢包，而是通过转发+序号对齐，把"切换那一瞬间的缝隙"用预转发的包和严格的序号管理填满了。

八、TAU：空闲态终端的"打卡报到"

讲完连接态的切换，我们回到空闲态。空闲态的终端不跟任何基站保持连接，大部分时间在睡觉（还记得我们讲过的DRX省电呼吸术吗）。但核心网总得知道它大致在哪，不然来电话时怎么找？

这就靠跟踪区更新（TAU，Tracking Area Update；在5G SA里叫注册更新 Registration Update for Mobility）。

跟踪区（Tracking Area, TA） 是核心网管理位置的最小粒度。一个TA包含若干个小区，每个小区在系统广播（SIB1）里会告诉终端自己属于哪个TA。终端一旦发现自己进入了当前TA列表以外的新TA，就会触发一次TAU，向核心网"打卡报到"。

flowchart TD
    Start["终端在空闲态移动"] --> Check{"进入新TA?<br/>(当前TA List之外)"}
    Check -->|否| Sleep["继续睡觉 / 小区重选"]
    Check -->|是| Trigger["触发TAU"]
    Trigger --> RRC["建立RRC连接<br/>(承载NAS信令)"]
    RRC --> NAS["发送注册请求<br/>(Registration Request)"]
    NAS --> Auth["核心网鉴权 / 安全模式"]
    Auth --> Update["AMF更新终端位置<br/>分配新TA List"]
    Update --> Resp["下发注册接受<br/>(Registration Accept)<br/>含新TA List"]
    Resp --> Done["终端记录新TA List<br/>回到空闲态"]
    style Check fill:#fff9c4
    style Update fill:#e8f5e9

TAU的关键产物是核心网给终端重新分配一个TA List（跟踪区列表）——注意是"列表"不是单个TA。这引出移动性管理里一个极为重要的优化设计。

九、TA List机制：用"懒"对抗信令风暴

想象终端在TA边界附近来回晃动（比如在两个TA交界的一条路上反复走），如果每次过线都要TAU，核心网会被这种"乒乓"信令淹没。更极端的例子是高铁——以300km/h穿越城区，几十秒一个TA，TAU信令会像雪片一样飞向AMF，这就是著名的信令风暴。

TA List的设计思路是"批量授权"：核心网一次性授权终端在一组TA（通常几个到十几个）内自由活动，只要不出这个圈子，就不用报到。只有跨出整个List边界，才触发一次TAU。这把乒乓信令直接砍掉了一大半。

设计要点	说明
TA List作用范围	终端在List内任意TA移动，不触发TAU
TA List由谁分配	核心网AMF在注册/TAU时下发
List内寻呼	终端来业务时，核心网对整个List所有小区同时寻呼
规划原则	TA List应按用户移动轨迹沿"带状/面状"合理划分，避免边界在高移动区域
与省电关系	TAU越少，终端唤醒越少，越省电

这里有一个精妙的工程权衡：TA List越大，TAU越少（省信令、省电），但寻呼时要广播的小区越多（费空口资源）。TA List越小，寻呼精准（省空口），但TAU频繁（费信令）。网络规划工程师的本质工作之一，就是在这根跷跷板上找平衡点——这就是为什么TA/TA List规划是网优的核心课题。

顺带一个实战知识：5G引入了注册区（Registration Area, RA） 的概念，本质上等价于TA List，是5G对这套机制的命名升级。

十、寻呼：网络喊人的广播术

当有下行数据或信令要发给一个空闲态终端时，网络不知道它在哪个小区，只知它在某个TA List里。怎么办？用寻呼（Paging）把它喊出来。

核心网AMF向TA List内所有相关的基站下发寻呼消息，每个基站再在自己覆盖的小区空口上广播"终端X，你在吗？"。终端在自己监听的寻呼时机（PO, Paging Occasion）醒来，听到自己的ID，就发起业务请求（Service Request），建立RRC连接，从空闲态进入连接态。

sequenceDiagram
    participant UPF as 用户面 UPF
    participant AMF as 核心网 AMF
    participant gNB as TA List内的基站们
    participant UE as 终端 (空闲/睡觉中)

    UPF->>AMF: ① 下行数据到达，终端是空闲态
    Note over AMF: ② 确定终端的TA List
    AMF->>gNB: ③ N2: 寻呼消息 (Paging)
    gNB-->>UE: ④ 空口广播寻呼 (在终端的PO时机)
    Note over UE: ⑤ DRX周期醒来,听到自己的ID
    UE->>gNB: ⑥ 发起Service Request (随机接入)
    gNB->>AMF: ⑦ N2: 业务请求
    Note over AMF,UPF: ⑧ 建立连接,下行数据送达
    UE->>UE: 进入连接态

寻呼和我们之前讲的DRX紧密耦合：终端为了省电，只在特定的寻呼帧、寻呼时机（PO）醒来听寻呼，其余时间沉睡。核心网下发的寻呼，必须卡在终端的PO窗口里被广播，否则终端听不到。这就是为什么寻呼不是"立刻就发"，而是要算准时机——这套时序，是网优工程师排查"被叫不通"问题的核心线索。

寻呼还有一个容易踩的坑：寻呼信道容量是有限的。一个小区单位时间内能广播的寻呼次数有上限。如果TA List划得太大、或者高价值业务集中在某些时段，寻呼信道可能被挤爆，导致寻呼丢弃——表现为"对方手机明明有信号，就是打不通"。这背后的根因，又回到了TA List规划。

十一、实战连接：工程师会踩的坑

1. 切换失败排查。终端掉话，先看是"切换没触发"还是"切换失败"。如果是切换失败，重点查目标基站的接纳控制——是不是过载拒绝了？用信令跟踪看Xn/N2的"切换请求确认"是否正常返回，还是回了拒绝。如果切换频繁失败，多半是邻区关系、Xn链路或目标小区资源的问题。

2. 乒乓切换。终端在两个基站之间反复横跳。根因往往是迟滞（Hysteresis）和触发时延（Time-to-Trigger）参数配得不合理，或者两个基站的信号在该位置几乎相等。这属于测量事件调参范畴（前面A1~A6那篇讲过），但表现是切换信令风暴，最终看的是切换次数统计。

3. 切换时丢包/卡顿。查数据转发是否建立、SN状态转移是否完成。跨厂商、跨AMF区域的N2切换最容易出现，因为间接转发绕行UPF，时序窗口大。优化方向是尽量打通Xn接口，把N2切换降级为Xn切换。

4. 寻呼不通。被叫打不通但主叫正常。查寻呼是否下发、是否在终端的PO窗口内广播、寻呼信道是否拥塞丢弃。常见原因：终端的TAU异常导致位置记录过期、TA List规划不合理导致寻呼范围错误或信道拥塞。

5. 信令风暴。大量终端同时TAU/寻呼。原因常是网络侧触发了批量配置更新、或TA边界划在了高铁/地铁等高移动区域。应急手段是调整TA List边界，长期手段是合理规划。

记住一条主线：连接态的问题查切换（Xn/N2信令+转发+SN），空闲态的问题查TAU和寻呼（TA List+PO时机+信道容量）。 这条主线能帮你快速定位八成的移动性故障。

十二、全景：三件套如何协同

最后用一张全景图把切换、TAU、寻呼三者串起来，看清它们如何共同支撑"无缝移动"：

flowchart TB
    Idle["RRC_IDLE 空闲态"] -->|"有业务/被叫"| Conn["RRC_CONNECTED 连接态"]
    Conn -->|"无业务一段时间"| Idle
    Idle -->|"进入新TA List外"| TAU["TAU 注册更新<br/>(向核心网报位置)"]
    Conn -->|"测量触发,信号变差"| HO["切换 Handover<br/>(Xn / N2)"]
    Idle -->|"被叫:下行数据到达"| Page["寻呼 Paging<br/>(TA List内广播喊人)"]
    TAU -.->|"维持核心网位置记录<br/>供寻呼使用"| Page
    HO -->|"切换后如跨TA<br/>可能触发TAU"| TAU
    style Idle fill:#e3f2fd
    style Conn fill:#e8f5e9
    style TAU fill:#fff9c4
    style HO fill:#fff3e0
    style Page fill:#f3e5f5

常见问题

Q1：Xn切换和N2切换，现网到底用哪个？ A：优先用Xn切换。只要源、目标基站之间有Xn接口且同属一个AMF服务区，就走Xn，时延低、占用核心网信令少。只有在没有Xn（如跨厂商未配置、跨AMF区域）时才退而用N2。现网工程上，打通Xn接口、减少N2切换比例，是网优提质的重要目标。

Q2：切换真的是"不丢包"吗？为什么我有时打电话还是会有断顿？ A：严格说，切换设计目标是"无损"，但实现上有一个极短的"切换中断时间"（终端断开旧基站、接入新基站的间隙），期间数据靠预转发填补。如果转发隧道没建好、或目标基站接纳慢、或无线条件突变，这个间隙里仍可能出现几十毫秒的卡顿甚至少量丢包。所谓"无缝"是工程意义上的近似无缝，不是物理意义上的零中断。

Q3：TAU和切换有什么关系？切换后会触发TAU吗？ A：两者针对不同状态——TAU是空闲态的位置更新，切换是连接态的基站交接。但如果切换让终端进入了一个新的TA（且核心网位置记录需要刷新），连接释放后终端回到空闲态时，可能会触发一次TAU来对齐位置记录。两者共享"跟踪区/注册区"这套位置管理底座。

Q4：为什么有时候被叫打不通，主叫却正常？ A：主叫是终端主动发起连接，不依赖网络知道你在哪；被叫是网络要主动找你，依赖寻呼。如果终端的TAU异常（位置记录过期或错误）、寻呼时机PO对不上、或寻呼信道拥塞丢弃，就会出现"主叫能打、被叫不通"。这是排查被叫问题最经典的三条线索。

Q5：TA List越大越好吗？ A：不是。TA List大，TAU少、省电省信令，但寻呼时要对整个List的所有小区广播，空口寻呼资源消耗大，容易拥塞。TA List小，寻呼精准省空口，但TAU频繁。网络规划的本质就是在TAU信令开销和寻呼空口开销之间找平衡，没有"越大越好"一说。