LTE 基础回顾：网络架构、DRX 与寻呼唤醒
各位同学，咱们今天聊聊 LTE 的基础。别急着翻书，我挑几个跟低功耗物联网最相关的点来讲。说白了，你要是不懂 LTE 怎么睡觉、怎么被叫醒，后面 BLE 协同唤醒的策略就根本玩不转。
我个人习惯把 LTE 看作一个「永远在线的管道」。但物联网设备最怕的就是一直在线——那功耗谁受得了？所以 LTE 设计了一套精妙的省电机制，核心就是 DRX（非连续接收）。
LTE 网络架构：谁在管谁？
先画个简图，看看 LTE 网络里都有谁。
核心要点：LTE 网络分三部分——UE（你的设备）、eNB（基站）、EPC（核心网）。物联网设备主要跟 eNB 打交道，但寻呼消息是从 EPC 下来的。
这张图我建议你多看两眼。物联网设备大部分时间都在睡觉，但 eNB 和 EPC 可不敢睡。EPC 一旦发现有人给你的设备发数据，就得想办法叫醒你。
嗯，这里要注意：寻呼不是 eNB 主动发起的，而是 EPC 通知 eNB 去做的。这个流程决定了延迟的上限。
LTE 的 DRX 机制：设备怎么睡觉？
DRX 全称是 Discontinuous Reception，非连续接收。说白了就是让 UE 间歇性地监听物理下行控制信道（PDCCH），其他时间关闭接收机睡觉。
我在项目中遇到过不少工程师，以为 DRX 就是简单「睡一会儿醒一会儿」。其实 LTE 的 DRX 分两层：
- 空闲态 DRX（Idle DRX）——设备已经断开 RRC 连接，只在寻呼时刻醒来。这是物联网设备最常用的模式。
- 连接态 DRX（Connected DRX）——设备还连着网，但没数据收发时周期性休眠。适合需要快速响应的场景。
我的经验：物联网设备绝大多数时间处于空闲态 DRX。连接态 DRX 虽然延迟更低，但功耗比空闲态高一个数量级。选哪个，取决于你的业务容忍多少延迟。
DRX 的关键参数
你想想看，DRX 的省电效果完全取决于几个参数怎么配。我列个表，这些参数在 NB-IoT 和 Cat-M 里都能配置：
| 参数 | 含义 | 典型值（空闲态） | 对功耗的影响 |
|---|---|---|---|
| DRX 周期 | 两次唤醒的间隔时间 | 1.28s / 2.56s / 5.12s | 周期越长，越省电 |
| 寻呼帧（PF） | UE 在哪一帧醒来监听 | 由 IMSI 和 DRX 周期计算 | 决定了唤醒时刻 |
| 寻呼时机（PO） | PF 内的具体子帧位置 | 1 个子帧（1ms） | 监听窗口越短越省电 |
| 寻呼时刻窗口 | UE 监听 PDCCH 的时长 | 通常 1~2 个子帧 | 窗口越短越省电 |
我曾经踩过一个坑：把 DRX 周期设成 10.24 秒，以为省电效果最好。结果设备经常漏掉寻呼，因为 eNB 的时钟漂移加上设备本地时钟误差，导致唤醒时刻对不准。后来我加了 ±1ms 的提前唤醒窗口才解决。
LTE 的寻呼与唤醒流程
好，现在咱们把整个流程串起来。设备怎么被叫醒的？分五步：
- EPC 收到下行数据——有人给你的设备发了一条消息。
- EPC 查位置——看看设备在哪个跟踪区（TA）里，把寻呼请求发给该 TA 下的所有 eNB。
- eNB 计算寻呼帧——根据设备的 IMSI 和 DRX 周期，算出 PF 和 PO。
- eNB 广播寻呼消息——在 PF 的 PO 子帧上发送 P-RNTI 加扰的 DCI。
- UE 醒来监听——设备在预设的 PO 时刻醒来，解码 PDCCH。如果发现是自己的寻呼，就发起 RRC 连接请求。
注意：寻呼消息里不包含具体数据，只告诉设备「有人找你」。设备需要重新建立 RRC 连接，然后去读数据。这个过程通常需要 50~200ms，具体取决于网络负载和信号质量。
寻呼时刻的计算公式
做低功耗物联网，你迟早得跟这个公式打交道。我直接给代码实现：
// 寻呼帧（PF）计算公式
// SFN: 系统帧号（0~1023）
// IMSI: 国际移动用户识别码
// T: DRX 周期（以帧为单位）
// nB: 寻呼密度参数（4T, 2T, T, T/2, T/4, T/8, T/16, T/32）
// 第一步：计算 UE_ID
uint32_t UE_ID = IMSI % 1024;
// 第二步：计算寻呼帧
// PF 满足：SFN % T == (T div N) * (UE_ID % N)
// 其中 N = min(T, nB)
// 第三步：计算寻呼时机（PO）
// i_s = floor(UE_ID / N) % Ns
// Ns = max(1, nB / T)
// 根据 i_s 查表得到 PO 在子帧中的位置说实话，这个公式我第一次看的时候也头疼。但实际开发中，大部分芯片厂商的 SDK 已经帮你算好了。你只需要配好 DRX 周期 T 和寻呼密度 nB 就行。
避坑指南：我曾经在某个 Cat-M 模块上发现，nB 设成 T/32 时，设备几乎收不到寻呼。后来查协议才发现，某些基站的实现不支持 nB 小于 T/8。建议你在实际部署前，先用网络测试仪扫一遍基站的寻呼能力。
DRX 与寻呼的协同设计思路
讲到这里，你应该能理解 LTE 的省电逻辑了。但物联网场景有个特殊需求：设备可能同时需要监听 LTE 寻呼和 BLE 广播。如果两个唤醒时刻错开，设备就得频繁醒来，功耗反而更高。
我个人习惯的做法是：
- 把 LTE 的 DRX 周期和 BLE 的扫描窗口对齐到同一个时间基准上。
- 让 BLE 的扫描时刻落在 LTE 寻呼时机的前后 10ms 内。
- 这样设备只需要一次唤醒，就能同时处理两个协议栈的事件。
嗯，这个思路就是咱们这门课的核心——协同唤醒。后面几章我会详细讲怎么算时间对齐、怎么处理时钟漂移。
今天先到这儿。LTE 的 DRX 和寻呼是基础中的基础，你把它吃透了，后面 BLE 协同的部分才能听懂。