首页 › deep-tech › 跟踪区与寻呼：网络如何找到你

跟踪区与寻呼：网络如何找到你

一、一个让网络头疼的问题：你的手机到底在哪？

想象一个场景：你的朋友给你打了一个电话。此时你的手机正处于"息屏待机"状态，既没在打电话，也没在刷视频。那么问题来了——核心网要把这个来电请求发给哪个基站？

最直觉的答案是：发给离你最近的那个基站。但核心网根本不知道你"最近"在哪个基站。一个城市可能有上万个基站，你的手机每走过几百米就可能换一个服务小区。如果核心网实时记录你每一秒在哪个小区，那信令开销会瞬间把网络压垮——上千万用户 × 每分钟几次小区变化 = 灾难性的位置更新风暴。

这就引出了移动通信里最经典的一组设计权衡：网络既要"找得到你"，又不能"盯着你"。工程师们给出的解法，就是今天我们要讲的两大支柱机制——跟踪区（Tracking Area） 和 寻呼（Paging）。

打个比方，这就像快递系统：快递员不会知道你此刻坐在哪个工位上，但他知道你登记的收件地址在"某某大厦"。当有包裹到达，他不会一间间办公室去敲门，而是在大厦前台放一个"到件通知"，你路过前台时自己取走。跟踪区就是这个"大厦"，寻呼就是那个"到件通知"。 接下来我们把这套机制一层层拆开。

二、先认清两张"状态脸"：UE 什么时候才需要被找

在讲机制之前，必须先理解终端（UE）的两种根本不同的状态，因为跟踪区和寻呼只在其中一种状态下才起作用。

stateDiagram-v2
    [*] --> CM-IDLE: 注册成功后默认
    CM-IDLE --> CM-CONNECTED: 寻呼响应 / 业务请求(上行数据)
    CM-CONNECTED --> CM-IDLE: 信令连接释放(无活动超时)
    note right of CM-IDLE
        • 无N1 NAS信令连接
        • 网络只知道你在哪个注册区
        • 空口上下文可能已释放
        • 网络找你 = 必须寻呼
    end note
    note right of CM-CONNECTED
        • 有N1 NAS信令连接
        • 网络知道你在哪个小区
        • 空口有RRC连接
        • 网络找你 = 直接调度
    end note

这就是 5G 里连接管理（CM）状态机的核心：CM-IDLE（空闲态）和 CM-CONNECTED（连接态）。

维度 CM-IDLE 空闲态 CM-CONNECTED 连接态
网络知道的精度 注册区（多个跟踪区） 精确到小区（Cell）
是否有空口连接 无 RRC 连接 有 RRC 连接
网络如何找 UE 寻呼（Paging） 直接调度下发
UE 主导行为 小区选择/重选 由网络调度切换
主要耗电来源 周期性醒来看寻呼 持续收发数据

理解了这张表，你就能理解后面所有设计的出发点：寻呼是"找不到你时"的广播式喊话，而跟踪区决定了这个喊话要覆盖多大的范围。

三、跟踪区（TA）：把世界切成可管理的"格子"

既然空闲态下网络不盯着你的小区，那它至少要知道"你在哪一片区域"，否则寻呼就无从发起。这片区域的最小单位，就是跟踪区（Tracking Area，TA）。

跟踪区是一组连续小区的逻辑集合，每个跟踪区有一个全球唯一编号叫 TAI（Tracking Area Identity）。关键设计在这里：当 UE 处于空闲态、在不同小区之间自由游走时，只要它待在同一个跟踪区内部，就不需要向网络报告位置。 只有当它跨出当前注册的跟踪区边界，才触发一次位置更新。

为什么要这么设计？因为"小区粒度太细、全网络粒度太粗"，跟踪区就是工程上最舒服的折中：

这里有一个非常优美的工程权衡公式，描述了跟踪区规划的核心矛盾：

$$ P_{\text{total}} = N_{\text{cell/TA}} \times R_{\text{paging}} + \frac{v \cdot N_{\text{UE}}}{L_{\text{TA}}} \times C_{\text{TAU}} $$

其中 $N_{\text{cell/TA}}$ 是每个跟踪区的小区数（决定寻呼广播范围），$R_{\text{paging}}$ 是寻呼频次，$v$ 是用户移动速度，$L_{\text{TA}}$ 是跟踪区尺寸，$C_{\text{TAU}}$ 是每次更新信令成本。跟踪区越大，$L_{\text{TA}}$ 越大 → 更新次数越少（省更新信令），但 $N_{\text{cell/TA}}$ 越大 → 单次寻呼要广播给更多小区（费寻呼资源）。这是一根永恒的跷跷板，网络规划工程师每天就在它的两端找平衡。

规划策略 优点 代价 适用场景
大跟踪区（多小区） TAU 更新少、信令省 单次寻呼范围大、占用空口 郊区、低话务、用户移动快
小跟踪区（少小区） 单次寻呼精准、省无线资源 跨区频繁触发 TAU、信令多 密集城区、高话务热点
动态/边界优化 按道路走向设计，减少乒乓更新 规划复杂、需持续优化 高铁、高速、城市主干道

💡 实战陷阱：跟踪区边界绝不能划在用户密集流动的路径上（比如把一条主干道两侧划成不同跟踪区）。否则大量用户每天往返穿越边界，会反复触发 TAU，产生"乒乓位置更新"，把 AMF 的信令处理能力吃光。正确做法是让边界垂直于主要人流方向，落在人少的过渡地带。

四、注册区（RA）：聪明的一打"跟踪区套餐"

如果只用单个跟踪区，问题来了：一个用户开车沿着跟踪区边界斜穿而过，会反复在两个区之间横跳，同样造成乒乓更新。解法是 5G 的注册区（Registration Area，RA）设计。

注册区不是单个跟踪区，而是一组跟踪区的列表（TAI List）。AMF 在注册时一次性给 UE 下发这个列表，明确告诉它："以下这十几个跟踪区，你随便走，都不用报告位置。只有当你进入列表之外的新跟踪区时，才需要做一次移动性注册更新。"

flowchart LR
    subgraph TA1["跟踪区 TA1"]
        c1[小区] --- c2[小区] --- c3[小区]
    end
    subgraph TA2["跟踪区 TA2"]
        c4[小区] --- c5[小区]
    end
    subgraph TA3["跟踪区 TA3 ⚠️不在列表"]
        c6[小区] --- c7[小区]
    end
    UE(("📱 UE")) -.区内移动<br/>无需报告.-> c5
    UE -.跨入TA3.->|触发移动性注册更新| c6

    style TA1 fill:#e8f5e9
    style TA2 fill:#e8f5e9
    style TA3 fill:#ffebee
    style UE fill:#fff3e0

这套机制的本质是"延迟更新、批量授权"：与其让你在边界来回横跳时每次都更新，不如一次性给你一片足够大的"自由活动区"。列表通常设计成地理上相邻的一簇跟踪区，让用户在区域内活动时边界穿越概率降到最低。

这里藏着一个很有意思的工程细节：TAI 列表的分配是动态的、按用户画像来的。AMF 会根据这个用户最近的活动轨迹、所在位置，给他分配一个"以当前位置为中心"的列表。这就好比导航 App 给你规划路线时会考虑你常去的地方，而不是死板地套用一个固定模板。一个静止在家的用户，可能拿到一个以家为中心的小列表；一个正在出差的高铁用户，可能拿到一个沿铁路线拉长的长条列表。

当 UE 跨出列表，进入一个全新的跟踪区时，就会触发下面这个关键流程。

五、移动性注册更新（5G 版的 TAU）：换区后的"报到"

在 4G 时代，这个流程叫 TAU（Tracking Area Update）。到了 5G，由于架构统一，它被整合进了更通用的注册流程，全称是 Mobility Registration Update（移动性注册更新）。但工程师们口头上还是习惯叫它"TAU"，所以这两个词在现网文档里经常混用。它的核心使命就一句话："我到了新地方，请重新给我分配注册区。"

sequenceDiagram
    participant UE as 📱 UE
    participant gNB as 📡 gNB(基站)
    participant AMF as 🏛️ AMF(移动性管理)
    participant UDM as 🗃️ UDM(用户数据)

    Note over UE: 检测到新小区的TAI<br/>不在自己的注册区列表中
    UE->>gNB: 1. Registration Request<br/>(类型=移动性更新)
    gNB->>AMF: 2. 透传NAS消息<br/>携带旧GUTI、新TAI
    Note over AMF: 识别用户、校验合法性
    AMF->>UDM: 3. 查询/订阅用户签约数据
    UDM-->>AMF: 4. 返回签约信息、生成新安全上下文
    Note over AMF: 根据新位置<br/>规划新的TAI列表
    AMF-->>gNB: 5. Registration Accept<br/>(下发新TAI列表、新GUTI)
    gNB-->>UE: 6. 透传给UE
    Note over UE: 更新本地注册区<br/>此后在新区内自由移动

逐步解读这个时序：

  1. 触发：UE 在空闲态重选到一个新小区，读取该小区广播的 TAI，发现它不在自己保存的注册区列表里。这就是触发的唯一判据——"我认识的区里没有它"。除位置变化外，还有一个周期性触发器：即便你没移动，每隔一段固定时间（典型几十分钟到几小时），UE 也要主动注册更新一次，好让网络知道"我还活着、还在网上"，否则网络会认为你掉线了。
  2. 报到：UE 通过当前基站发出注册请求。注意，此时 UE 还在空闲态，这个请求本身就会顺带把它从 CM-IDLE 拉回 CM-CONNECTED——因为要发信令就必须先建立空口连接。
  3. 核验：AMF 收到后，用 UE 上报的临时标识（GUTI）认出这个用户，向 UDM 核对签约数据，必要时更新安全上下文（密钥刷新）。
  4. 重新分配：AMF 根据 UE 现在所处的新位置，规划一个以新位置为中心的新 TAI 列表。
  5. 应答：通过 Registration Accept 把新列表和新临时标识下发给 UE。
  6. 生效：UE 更新本地的注册区记忆。从这一刻起，它又能在这片新区里安静地自由移动了。

🔧 工程师视角：TAU/注册更新是 5G 核心网信令风暴（Signaling Storm）的头号元凶之一。如果你在网优后台看到 AMF 信令量异常飙升，第一反应就该查：是不是某个跟踪区边界规划不合理导致乒乓更新？是不是周期性更新定时器配得太短？是不是大批物联网终端同时复活触发海量注册？这些都是教科书级的排障方向。

六、寻呼（Paging）：网络版的"大喇叭广播"

讲完"报到"，回到另一半——网络主动找 UE。当你朋友来电、或有下行数据要送达到一个处于 CM-IDLE 的 UE 时，网络无法直接把数据塞给它（没有空口连接），必须先用寻呼把 UE "唤醒"。

sequenceDiagram
    participant UPF as 📦 UPF(数据面)
    participant SMF as 🧩 SMF(会话管理)
    participant AMF as 🏛️ AMF
    participant gNB1 as 📡 gNB(区A)
    participant gNB2 as 📡 gNB(区B)
    participant UE as 📱 UE(空闲态)

    Note over UPF: 下行数据到达<br/>但UE在空闲态
    UPF->>SMF: 1. 下行数据通知(触发缓存)
    SMF->>AMF: 2. 请求寻呼该UE
    Note over AMF: 查UE当前注册区<br/>(TAI列表)
    par 并行寻呼整个注册区
        AMF->>gNB1: 3a. Paging(TA1内所有小区)
        AMF->>gNB2: 3b. Paging(TA2内所有小区)
    end
    gNB1-->>UE: 4. 空口广播Paging消息
    gNB2-->>UE: 4. 空口广播Paging消息
    Note over UE: 在自己的寻呼时机<br/>醒来收到寻呼
    UE->>gNB1: 5. Service Request(响应寻呼)
    Note over UE: 进入CM-CONNECTED
    gNB1->>AMF: 6. 建立N2连接、恢复隧道
    AMF->>SMF: 7. 激活用户面
    SMF->>UPF: 8. 释放缓存的下行数据
    UPF-->>UE: 9. 数据送达 ✓

这个流程里有三个"为什么这样设计"特别值得玩味：

第一，为什么要"广播"而不是"单播"？ 因为此时网络确实不知道 UE 在注册区的具体哪个小区。注册区内可能有几百上千个小区，UE 可能在其中任意一个。所以最稳妥的做法是让注册区内所有小区的基站都把这条寻呼发一遍。UE 只要听到了，就会响应。这就像在大厦里找人，前台不知道你在哪层，只能用广播喊全楼。

第二，为什么 SMF 不能直接发，必须经 AMF？ 因为在 5G 的职责切分里，AMF 是唯一掌握"UE 位置信息"（注册区）的网元，SMF 只管会话不管位置。所以数据到了，SMF 得"求"AMF 帮忙寻呼。这种职责隔离是 5G 控制面解耦的精髓——位置管理与会话管理彻底分开，互不耦合。

第三，UE 收到寻呼后做什么？ 它发一个 Service Request（业务请求），这会把状态从 CM-IDLE 翻转到 CM-CONNECTED，重新建立空口和 N2 连接、恢复用户面隧道，然后缓存的下行数据才真正送达。寻呼本质上是"敲门的动作"，真正的数据是在门打开之后才进来的。

💡 寻呼不只服务于电话：寻呼的触发源很丰富——下行数据到达（最常见）、地震海啸告警（ETWS）、商用移动告警（CMAS）、系统信息变更通知、甚至 5G 特有的语音回退（EPS Fallback）场景。所有这些"网络需要主动联系空闲态 UE"的时刻，统一走寻呼这一条路。

七、寻呼的省电魔法：DRX、寻呼帧与寻呼时机

到这里有一个尖锐问题：UE 在空闲态要随时待命接寻呼，那它是不是得一直醒着监听？那电池半天就没了。5G 的答案是非连续接收（DRX）——这也是上一篇我们讲过的省电机制，但它在寻呼场景下有一套专门的精妙设计。

UE 不会一直醒着，而是周期性地"醒来一小会儿"看看有没有自己的寻呼，然后再睡去。这个周期叫 DRX 周期（DRX Cycle），典型取 32、64、128、256 个无线帧（每帧 10ms）。那么问题来了：注册区里成千上万个 UE，如果大家都同一时刻醒来，基站的寻呼信道瞬间被挤爆；如果随机分布，又要保证每个 UE 都在自己的窗口被找到。怎么安排？5G 用一套基于 UE 标识的确定性公式，给每个 UE 算出它专属的"寻呼帧（PF）"和"寻呼时机（PO）"：

$$ (SFN + \text{PF_offset}) \bmod T = (UE_ID \bmod N) $$

$$ i_s = \left\lfloor \frac{UE_ID}{N} \right\rfloor \bmod N_s $$

逐项解释这套公式：

这套设计的绝妙之处在于：它是"伪随机但确定性"的。 每个 UE 由自己的 ID 决定唯一的唤醒时刻，不同 ID 的 UE 被自然地分散到不同的 PF/PO 上，避免了所有人同时醒来挤爆信道；而基站要寻呼某个 UE 时，用同一套公式算出它该在哪个 PF/PO 出现，精准在那个时刻把寻呼发出去，UE 就能恰好接住。UE 一生中真正醒着监听的时间，只占总时间的极小一部分——这就是手机能待机好几天的物理基础。

寻呼参数 含义 调大的影响
DRX 周期 $T$ UE 唤醒周期 更省电，但寻呼响应延迟增大
$nB$ 寻呼帧密度参数 寻呼更快、延迟更低，但 UE 唤醒更频繁、更费电
$N_s$ 每帧寻呼时机数 单帧可容纳更多寻呼，但每个时机更短
TAI 列表大小 注册区范围 更新更少，但单次寻呼广播范围更大

⚠️ 经典网优坑："用户投诉 5G 信号满格却接不到电话"，很多时候根本不是覆盖问题，而是 DRX 周期配得太长或 PO 计算与基站配置不一致导致寻呼错过。还有一种典型故障：核心网 AMF 里 UE 的注册区记录与 UE 实际位置不同步（比如注册更新丢了），网络去一个"错误的老地方"寻呼，UE 自然接不到。遇到接不到电话，先别查信号，先查寻呼流程的信令。

八、把两条线串起来：完整的位置管理闭环

理解了 TAU 和寻呼，我们把它们和状态机拼成一张全景图。整个移动性管理本质上是一个"网络对 UE 位置的认知精度"随状态切换而动态伸缩的过程：

flowchart TB
    A[UE 空闲态 CM-IDLE<br/>网络认知=注册区级别] --> B{UE 是否跨出注册区?}
    B -- 是 --> C[移动性注册更新/TAU<br/>网络重新分配注册区]
    B -- 否 --> D[沉默不报告<br/>自由移动]
    C --> A

    A --> E{是否有下行数据/来电?}
    E -- 是 --> F[网络在注册区内寻呼]
    F --> G[UE 响应 Service Request]
    G --> H[进入连接态 CM-CONNECTED<br/>网络认知=小区级别]
    H --> I{是否长时间无活动?}
    I -- 是 --> J[信令连接释放]
    J --> A
    I -- 否 --> H

    style A fill:#fff3e0
    style H fill:#e8f5e9
    style C fill:#e3f2fd
    style F fill:#fce4ec

你看，整个系统的设计哲学其实非常优雅：

这两座桥配合 5G 特有的 RRC_INACTIVE 态（一种"半睡半醒、保留上下文、寻呼范围更小"的中间态），构成了现代移动网络位置管理的完整骨架。

九、一句话总结

跟踪区是网络给世界画的格子，注册区是给你发的"自由活动通行证"，TAU 是换区后的报到，寻呼是找不到你时的广播喊话，而 DRX/PO/PF 让这套喊话既精准又省电。 这五个概念环环相扣，共同回答了移动通信里最朴素也最核心的问题——面对一个随时在移动、又大部分时间在睡觉的用户，网络该如何随时找到他？

常见问题

Q1：TAU（跟踪区更新）和切换（Handover）有什么区别？ A：这是初学者最常混淆的一对。切换发生在连接态——你正在打电话/刷视频，网络为了保证业务不断，主动把你从一个基站无缝搬到另一个基站，全程由网络控制，目标是"业务连续"。TAU 发生在空闲态——你没在用业务，只是物理上挪了个地方越过了跟踪区边界，UE 主动向网络"报到"更新位置，目标是"让网络知道我在哪"。一个保业务连续，一个保位置新鲜，完全是两套机制、两种触发、两个状态。

Q2：为什么不让 UE 在空闲态也实时报告每个小区？那样寻呼不就精准了吗？ A：因为信令开销无法承受。空闲态用户远多于连接态用户（大多数人大部分时间在待机），如果每个人都按小区报告位置，核心网信令量会是现在的几十上百倍，AMF 会瞬间瘫痪。跟踪区就是用"牺牲一点寻呼精度，换取巨大信令节省"的工程妥协。网络永远在"找得准"和"盯得起"之间权衡。

Q3：注册区（TAI 列表）给得越大越好吗？ A：不是。列表越大，UE 跨出边界触发更新的次数越少（省更新信令），但网络每次寻呼要广播给更多跟踪区的更多小区（费空口寻呼资源）。极端情况下，一个超大注册区里来个电话，可能惊动成百上千个基站同时寻呼。所以列表大小必须结合话务密度、用户移动性、寻呼容量综合优化——没有最优值，只有当前网络下的最合适值。

Q4：DRX 周期设得越长越省电，那直接设成最大值不就好了？ A：省电的另一面是寻呼延迟增大。DRX 周期越长，UE 两次唤醒之间的间隔越大，网络发的寻呼要等 UE 下次醒来才能被收到，最坏情况下电话要响好几秒才接通。对于语音这种对延迟敏感的业务，这是不可接受的。所以实际网络会在"省电"和"接通速度"之间取折中，不同运营商、不同业务场景（普通用户 vs 物联网终端）会配不同的周期。

Q5：寻呼消息会泄漏用户隐私吗（比如别人知道我被寻呼了）？ A：空口广播的寻呼消息里携带的是 UE 的临时标识（5G-S-TMSI），而非永久身份（SUPI）。临时标识会周期性变化，且核心网到空口全程加密。所以理论上监听空口的人只能知道"某个临时标识被寻呼了"，难以直接关联到真实用户身份。5G 相比 4G 在这一点上做了进一步加固（永久身份的初始注册加密、SUCI 机制等），隐私保护是移动性管理设计时就被严肃考虑的一环。

参考来源

  1. 5G NR Paging 寻呼（CSDN） — 系统讲解寻呼中的 DRX、寻呼帧 PF、寻呼时机 PO 计算方法
  2. 5G 寻呼 Paging 总结（知乎） — PO/PF 公式中各参数含义与 UE_ID 取值的工程解读
  3. 5G Paging Procedure and How It Differs from LTE Paging — 5G 与 LTE 寻呼流程的对比讲解
  4. 跟踪区 TA（达希物联通信知识库） — 跟踪区规划原则：寻呼量与 TAU 更新量的权衡
  5. 5G NR 基站的扇区、小区、跟踪区、注册区、服务区（CSDN） — 厘清小区、跟踪区、注册区、服务区的层级关系

本文由「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学通信知识星球海报-扫码加入

📎 本分类最新文章