# 5G RRC连接重建（Re-establishment）信令与shortMAC-I认证机制全链拆解 > 本文聚焦 3GPP TS 38.331 第 5.3.7 节「RRC connection re-establishment」流程，逐条消息解析 IE 结构，并深入剖析承载 UE 身份恢复与安全上下文续接的 shortMAC-I 推导算法与 K~gNB~ 水平/垂直密钥推演链。这是 RAN 域（接入网）在 RRC_CONNECTED 状态下最核心的"空中救护车"机制。 ## 一、为什么需要 RRC 连接重建（设计意图） 在 5G NR 中，UE 处于 RRC_CONNECTED 状态时，无线链路可能因下列原因瞬时中断：无线链路失败（RLF）、切换执行失败（HO Failure）、RRC 重配失败（Reconfiguration Failure）、或 SRB1/SRB2 完整性校验失败。如果每次中断都让 UE 回到 RRC_IDLE 重新发起完整初始接入（RRC Setup）、重新执行 NAS 鉴权与 AS 安全激活，则：① 用户面业务将彻底中断、丢包严重；② 核心网信令风暴（重新注册、PDU 会话重建）；③ 时延从几十毫秒恶化到秒级。 RRC 连接重建的设计哲学是：**只要 UE 本地仍保留有效的 AS 安全上下文（K~gNB~、加密/完整性算法、nextHopChainingCount）以及源 PCell 的标识信息，就允许 UE 在一个合适的相邻小区上"无缝续接"原有连接**——恢复 SRB1、复用已激活的 AS 安全、最终通过一条 RRC Reconfiguration 把 SRB2/DRB 全部接回。整个过程 UE 始终停留在 RRC_CONNECTED 状态，对核心网（AMF/SMF）几乎透明。 这是它与另外两条恢复路径的本质区别： - **RRC Setup**：从 RRC_IDLE 全新建立，无任何历史上下文，必须重新走 NAS 鉴权； - **RRC Resume**：从 RRC_INACTIVE 唤醒，恢复挂起的上下文（suspend 时的快照）； - **RRC Re-establishment**：UE 始终在 RRC_CONNECTED，针对"突然断裂"的抢救性续接。 ## 二、触发条件与前置约束（TS 38.331 §5.3.7） UE 发起重建必须同时满足以下约束，否则一律退化为 RRC Setup： | 约束项 | 说明 | |--------|------| | AS 安全已激活 | 必须已完成 Security Mode Command/Complete。若安全未激活即发生失败，gNB 直接拒绝重建，UE 回 RRC_IDLE | | 目标小区可用性 | 目标小区必须是 UE 配置了测量的小区（在 measObject/cellToAddMod 列表中），UE 持有该小区的 PCI | | 源上下文可定位 | 网络侧必须能通过 (C-RNTI, 源 PCI) 唯一定位 UE 上下文，并用 shortMAC-I 校验 | | SRB1 可用 | 重建只恢复 SRB1（信令承载），SRB2 与 DRB 暂挂起，待后续 Reconfiguration 激活 | RRCReestablishmentRequest 中携带的 `reestablishmentCause` 取值反映触发场景，共三类（Rel-16 定义）： - `reconfigurationFailure`：UE 执行 RRC Reconfiguration 失败（如无法解析 masterCellGroup）； - `handoverFailure`：UE 在 T304 超时内未完成同步到目标 PCell； - `otherFailure`：RLC 达到最大重传次数、RLF、MAC 随机接入问题等归为此类。 ## 三、完整信令时序图（三条消息握手） 整个重建过程是经典的三步握手（Three-way），全程承载在 NR-Uu 接口的 SRB1 上： ```mermaid sequenceDiagram autonumber participant UE participant TgNB as 目标 gNB participant SgNB as 源 gNB(可选) Note over UE: RLF/HO失败/重配失败
本地仍持有 AS 安全上下文 UE->>UE: 小区选择(同频/异频/异系统回退) UE->>TgNB: RACH (Msg1/Msg2 或 2-step MsgA/MsgB) UE->>TgNB: RRCReestablishmentRequest
(C-RNTI, 源PCI, shortMAC-I, cause) alt 目标gNB ≠ 源gNB 且无本地上下文 TgNB->>SgNB: XnAP RETRIEVE UE CONTEXT REQUEST
(C-RNTI, 源PCI) SgNB->>TgNB: XnAP RETRIEVE UE CONTEXT RESPONSE
(UE上下文, Kng-ran*, PDCP SN状态, DRB信息) end TgNB->>TgNB: 校验 shortMAC-I
水平/垂直密钥推演出新 K_gNB TgNB->>UE: RRCReestablishment
(masterCellGroup默认配置, nextHopChainingCount) Note over UE: 用新 NCC 做垂直推演
重新派生 K_RRCenc/K_RRCint UE->>UE: 重配 SRB1, 复用已激活安全 UE->>TgNB: RRCReestablishmentComplete TgNB->>UE: RRCReconfiguration(可选)
恢复 SRB2 + DRB Note over UE: 业务面恢复 ``` 关键点解读： 1. **第 2 步 RACH 不可省**：重建请求是 RRC 消息，必须先有 MAC 层的随机接入获得 C-RNTI 与上行同步，才能在 SRB1 上发送。这也是为什么重建延迟的下限是"小区选择 + 随机接入"耗时。 2. **第 3 步三要素**：C-RNTI + 源 PCI 用于"寻址"，shortMAC-I 用于"鉴真"，cause 用于"告警分类"。 3. **上下文获取是分支决策**：同 gNB 内直接复用内存上下文；跨 gNB 必须走 Xn 接口的 RETRIEVE UE CONTEXT 流程（TS 38.423）。 4. **RRCReestablishment 的两条核心 IE**：`masterCellGroup`（带有一个默认/最小配置）与 `nextHopChainingCount`（触发密钥推演的"齿轮"）。 ## 四、RRCReestablishmentRequest 的 IE 结构与逐位拆解 该消息定义在 TS 38.331 §6.2.2，承载于 UL-DCCH，使用 SRB1。值得注意的是：**这是重建流程中唯一一条在 AS 安全尚未"重新挂载"前发送的消息**，因此它**不加密、不完整性保护**——这也是为什么必须靠 shortMAC-I 单独完成身份证明。 ```mermaid flowchart TD A[RRCReestablishmentRequest] --> B[rrcReestablishmentRequest] B --> C[ue-Identity: ReestUE-Identity] B --> D[reestablishmentCause] B --> E[spare] C --> C1[c-RNTI: BIT STRING size 16
源 PCell 的 C-RNTI] C --> C2[physCellId: INTEGER 0..1007
源 PCell 的物理小区标识] D --> D1[reconfigurationFailure] D --> D2[handoverFailure] D --> D3[otherFailure] style E fill:#eee,stroke:#999 style C fill:#e8f5e9,stroke:#4caf50 ``` 三个 IE 的工程意义： - **c-RNTI（16 bit）**：UE 在源 PCell 上使用的 MAC 层标识。目标 gNB 用它与源 PCI 组成复合键去查找上下文。注意：这是"源小区的"C-RNTI，不是目标小区接入后分配的新 C-RNTI。 - **physCellId（PCI, 0~1007）**：源 PCell 的物理小区标识。NR 共 1008 个 PCI（比 LTE 的 504 翻倍）。PCI 与 C-RNTI 组合定位"哪个小区里的哪个 UE"。 - **reestablishmentCause**：3 bit 编码，便于网络侧统计重建原因分布，是网优分析"重建比率高"问题的关键字段。 为什么不能只靠 C-RNTI？因为不同小区可能复用相同的 C-RNTI（C-RNTI 是小区内标识），加上 PCI 才能在全网/邻区范围内唯一定位。这也是 shortMAC-I 必要性讨论的核心——下节详述。 ## 五、shortMAC-I 推导算法深度拆解（核心难点） shortMAC-I 是整个重建流程中最巧妙的设计。它是一个 **16 bit** 的短认证令牌，定义见 TS 38.331 §6.3.4（ShortMAC-I ::= BIT STRING (SIZE(16))）。其推导过程在 §5.3.7.4 与 §5.3.7 Annex 中给出： **算法本质**：用**源小区的 K~RRCint~ 密钥 + 源小区的完整性算法**，对一段由"源 PCI + 源 C-RNTI"拼接而成的输入串计算一次 MAC-I（消息认证码），再截取其 **16 个最低有效位（LSB）** 作为 shortMAC-I。 ```mermaid flowchart TD subgraph 输入 I1[源 PCI] I2[源 C-RNTI] end subgraph 密钥与算法 K[源小区 K_RRCint] IA[源小区 IntegrityProtAlgorithm] end I1 --> M[按 38.331 规定的
输入串拼接/填充] I2 --> M K --> F[MAC-I 完整性算法计算
例如 NIA2 = 128-SNOW-3G] IA --> F M --> F F --> T[完整 32bit MAC-I] T --> S[取最低 16 bit] S --> R((shortMAC-I
16 bit)) ``` **设计意图三连问**——为什么有了 C-RNTI + PCI 还要 shortMAC-I？ 1. **防伪造**：C-RNTI 与 PCI 都是明文、可被任意监听者获取的标识。若没有 shortMAC-I，一个恶意 UE 只需知道某合法 UE 的 (C-RNTI, PCI) 就能冒充它发起重建，劫持其上下文（攻击者获得该 UE 的 DRB 承载）。shortMAC-I 用只有合法 UE 与源 gNB 才掌握的 K~RRCint~ 计算，构成"知识证明（proof of knowledge）"，攻击者无法伪造。 2. **防冲突**：C-RNTI 16 bit + PCI 10 bit 也只有 26 bit 空间，跨 gNB 取上下文时存在理论上的碰撞窗口。16 bit 的 shortMAC-I 进一步把冲突概率压低 1/65536，配合 gNB 本地的 C-RNTI 表，实际碰撞概率可忽略。 3. **复用已有密钥**：无需引入新协议，直接复用已激活的 AS 安全上下文，零额外协商开销。 UE 端在构造请求时计算一次 shortMAC-I；目标 gNB 拿到（C-RNTI, PCI）后从源 gNB 取回上下文（或本地复用），用同样的 K~RRCint~ 与算法重新计算，与请求中的 shortMAC-I 比对——**匹配才接受，否则拒绝并让 UE 走 RRC Setup**。 ## 六、密钥推演链：水平 vs 垂直（TS 33.501 Annex A） 重建成功后，UE 与 gNB 必须派生出"新的"会话密钥用于后续加密/完整性保护。这里涉及 5G AS 安全最精妙的**水平推演（horizontal derivation）**与**垂直推演（vertical derivation）**机制。 ```mermaid flowchart TD OKgNB[源 gNB 持有的当前 K_gNB] --> H{目标 gNB
是否=源 gNB?} H -- 同 gNB --> V1[复用当前 K_gNB] H -- 跨 gNB --> HD[水平推演:
K_ng-ran* = KDF K_gNB, 0x1F ] HD --> XN[源gNB经 XnAP 将 K_ng-ran*
随上下文发给目标 gNB] XN --> TP[目标 gNB 用目标 PCI 做一次推演:
K_gNB' = KDF K_ng-ran*, target_PCI ] V1 --> VT[用 RRCReestablishment 携带的
nextHopChainingCount 做垂直推演] TP --> VT VT --> K1[K_RRCint = KDF newK_gNB, 0x69] VT --> K2[K_RRCenc = KDF newK_gNB, 0x6B] VT --> K3[K_UPenc = KDF newK_gNB, 0x6E] style HD fill:#fff3e0,stroke:#ff9800 style VT fill:#e3f2fd,stroke:#2196f3 ``` 要点解析： - **水平推演（K~ng-ran~\*）**：当重建目标位于不同 gNB 时，源 gNB 不能直接把当前 K~gNB~ 发过去（那样目标 gNB 会掌握与源相同的密钥，破坏前向/横向隔离）。于是用 KDF 把当前 K~gNB~ 再推演一步得到中间密钥 K~ng-ran~\*，再由目标 gNB 用自己的 PCI 把它"本地化"为属于自己的 K~gNB~'。这样每个 gNB 持有的 K~gNB~ 都绑定了自己的 PCI，互不相同。 - **垂直推演（nextHopChainingCount, NCC）**：RRCReestablishment 消息里的 `nextHopChainingCount` 是一个 0~7 的滚动计数器。UE 收到后，比较本地 NCC：若 NCC 匹配则用当前 NH（Next Hop）参数，否则做"NH 链式推演"追赶到指定 NCC。这个齿轮保证每次重建/切换都用上一代不同的密钥派生材料，实现**前向密钥分离（forward key separation）**——即使某代密钥泄露，也无法回推历史。 - **派生出的四把钥匙**：从新 K~gNB~ 派生 K~RRCint~（0x69）、K~RRCenc~（0x6B）、K~UPenc~（0x6E）、K~UPint~（0x6A，仅 NR 配置了用户面完整性时）。重建完成后，UE 用新密钥对 SRB1 重启加密与完整性保护。 ## 七、UE 上下文获取的决策树（同 gNB vs 跨 gNB） ```mermaid flowchart TD A[目标 gNB 收到
RRCReestablishmentRequest] --> B{本地是否存在
C-RNTI+源PCI 的上下文?} B -- 是(同 gNB 内) --> C[直接复用本地上下文] B -- 否 --> D{与源 gNB 是否有 Xn 连接?} D -- 是 --> E[发起 XnAP RETRIEVE UE CONTEXT REQUEST] E --> F{源 gNB 校验
shortMAC-I 通过?} F -- 是 --> G[返回 UE 上下文 + K_ng-ran* + PDCP SN 状态] F -- 否 --> H[拒绝, UE 走 RRC Setup] D -- 无 Xn --> H C --> I[接受重建] G --> I I --> J[发送 RRCReestablishment] ``` PDCP SN（序列号）状态转移是跨 gNB 重建的关键附加动作：源 gNB 在 RETRIEVE UE CONTEXT RESPONSE 中携带每个 DRB 的上行/下行 PDCP SN（UL/DL COUNT），目标 gNB 据此避免重放与丢包，配合数据前转（data forwarding）实现用户面无缝续接。这与 N2 切换里的 SN Status Transfer 是同一类思想。 ## 八、RRC 状态转换视角 ```mermaid stateDiagram-v2 [*] --> RRC_IDLE RRC_IDLE --> RRC_CONNECTED: RRC Setup + 安全激活 RRC_CONNECTED --> RRC_CONNECTED: 正常业务/切换 RRC_CONNECTED --> 重建中: RLF/HO失败/重配失败 state 重建中 { [*] --> 选小区 选小区 --> 发请求: RACH成功 发请求 --> 收配置: gNB接受 收请求_拒绝: shortMAC-I校验失败/无上下文 发请求 --> 收请求_拒绝: 被拒 收配置 --> 业务恢复: ReestablishmentComplete } 重建中 --> RRC_CONNECTED: 重建成功
(全程未离开CONNECTED) 重建中 --> RRC_IDLE: 重建失败/退化为Setup RRC_CONNECTED --> RRC_INACTIVE: RRC Release(suspend) RRC_INACTIVE --> RRC_CONNECTED: RRC Resume ``` 注意：**重建成功路径上 UE 自始至终没有离开 RRC_CONNECTED**，这是它对核心网透明的根本原因——AMF 甚至感知不到发生过这次空中抢救。 ## 九、IE 参数速查表 | 消息 | 关键 IE | 类型/取值 | 作用 | |------|--------|----------|------| | ReestablishmentRequest | c-RNTI | BIT STRING(16) | 源 PCell 的 MAC 标识，定位 UE | | ReestablishmentRequest | physCellId | 0~1007 | 源 PCell 物理小区标识 | | ReestablishmentRequest | shortMAC-I | BIT STRING(16) | 身份鉴真令牌 | | ReestablishmentRequest | reestablishmentCause | 3 选 1 | 触发原因（网优统计） | | Reestablishment | masterCellGroup | CellGroupConfig | 含 spCell 默认配置，重配 SRB1 | | Reestablishment | nextHopChainingCount | 0~7 | 触发垂直密钥推演的齿轮 | | ReestablishmentComplete | lateRRCReestablishmentComplete-r16 | 可选 | Rel-16 late completion 字段 | | XnAP Retrieve UE Ctx | K~ng-ran~\* | key | 水平推演的中间密钥 | | XnAP Retrieve UE Ctx | PDCP SN Status | per DRB | 防重放/丢包续接 | ## 十、三条恢复路径对比表 | 维度 | RRC Setup | RRC Re-establishment | RRC Resume | |------|-----------|---------------------|------------| | 起始状态 | RRC_IDLE | RRC_CONNECTED（断裂） | RRC_INACTIVE | | 是否有历史上下文 | 无 | 有（仍在 gNB/源 gNB） | 有（suspend 快照） | | AS 安全 | 需全新激活 | 复用已激活，做密钥推演 | 复用 resumeMAC-I + 推演 | | 对核心网 | 全新注册/会话 | 几乎透明 | 透明（Context Resume） | | 典型时延 | 秒级 | 十几~几十 ms | 几十 ms | | 核心认证令牌 | 无 | shortMAC-I（16bit） | resumeMAC-I（16bit） | | 触发 | 开机/寻呼响应 | RLF/HO失败/重配失败 | 上行数据/寻呼 | ## 十一、抓包识别与故障排查 **抓包识别**：在 Wireshark/TShark 中用过滤器 `rrc.rrcReestablishmentRequest` 或 `ngap.*` 配合 Xn 接口过滤 `xnap.RetryUEContextRequest` 可定位重建事件。一条完整的成功重建应呈现：RACH → ReestablishmentRequest →（可选 XnAP Retrieve）→ Reestablishment → ReestablishmentComplete 的连续序列。若 ReestablishmentRequest 之后长时间无响应，则重建失败。 **常见故障点**： 1. **shortMAC-I 校验失败**：源 gNB 已释放上下文（如 UE 失联过久触发隐式去注册，上下文被删），或 K~RRCint~ 因某代密钥推演不一致导致重算结果不符。排查：核对源 gNB 上下文是否存在、NCC 同步是否正常。 2. **目标小区无 Xn 连接**：跨 gNB 重建但两端无 Xn 接口，直接退化为 RRC Setup。排查 Xn 链路状态与邻区关系（ANR）。 3. **重建"乒乓"**：UE 反复在某几个小区间重建，多为覆盖空洞或邻区漏配/错配 PCI（PCI MOD3/MOD6 冲突导致 CRS/CSI-RS 干扰）。 4. **重建比率高**：核心网侧统计重建成功率与重建原因分布，`handoverFailure` 居多指向切换参数（迟滞、TTT、门限）不当；`otherFailure` 居多指向覆盖与干扰。 5. **加密/完整性不匹配**：重建后 RRCReconfiguration 或用户面解密失败，多为 NCC 推演在 UE 与 gNB 间不同步——重点核对 nextHopChainingCount 的链式追赶逻辑。 ## 常见问题 **Q1: shortMAC-I 与 RRC Resume 中的 resumeMAC-I 有什么区别？** A: 两者都是 16 bit 的认证令牌，但作用域与推导输入不同。shortMAC-I 用于 RRC_CONNECTED 内的重建，用源小区的 K~RRCint~ 对 (源 PCI + 源 C-RNTI) 计算；resumeMAC-I 用于从 RRC_INACTIVE 唤醒，用恢复上下文的密钥材料对 (I-RNTI 等) 计算。它们是"同形异源"的两套机制，服务于不同的状态恢复场景。 **Q2: 为什么重建只恢复 SRB1，SRB2 和 DRB 要等 Reconfiguration？** A: SRB1 是承载关键 RRC 信令的基础承载，必须最先恢复以维持信令通路；SRB2 与 DRB 的配置较复杂（涉及 PDCP/RLC/MAC 多层参数），且不同 DRB 的 QoS 与加密策略各异，统一放在重建完成后的 RRC Reconfiguration 里"批量"恢复更高效，也便于失败时回退。 **Q3: 如果 AS 安全尚未激活就发生失败，会怎样？** A: 此时 UE 不能发起重建（无 shortMAC-I 可用），网络侧也无安全上下文可比对。UE 直接进入 RRC_IDLE，重新走 RRC Setup + NAS 鉴权 + AS 安全激活的完整流程。这也是为什么"未激活安全即失败"是重建失败的兜底情形。 **Q4: 跨 gNB 重建时，源 gNB 把 K~ng-ran~\* 直接发给目标 gNB，是否破坏前向安全？** A: 不破坏。K~ng-ran~\* 是当前 K~gNB~ 的一次水平推演中间量，目标 gNB 还要用自己的 PCI 再推演一次得到专属 K~gNB~'。源 gNB 不掌握 K~gNB~'，目标 gNB 也无法回推到源 K~gNB~ 的前代密钥，结合 NCC 垂直推演，实现了横向与纵向的双重密钥隔离。 **Q5: 重建成功后 UE 的新 C-RNTI 从哪来？** A: 来自 RRCReestablishment 中携带的 masterCellGroup 配置——其中 spCell（主小区）的 mac-CellConfig 会重新分配一个属于目标小区的 C-RNTI，供后续 MAC 层调度使用，与请求消息里那个"源 C-RNTI"是两个不同的标识。 ## 参考来源 1. [3GPP TS 38.331 V18.6.0 — NR RRC Protocol Specification](https://www.etsi.org/deliver/etsi_ts/138300_138399/138331/18.06.00_60/ts_138331v180600p.pdf) — §5.3.7 RRC connection re-establishment、§6.2.2/§6.3.4 IE 定义与 ShortMAC-I 推导 2. [5G NR RRC Reestablishment Procedure — 3GLTEInfo Call Flow](https://www.3glteinfo.com/call-flows/5g/rrc-reestablishment/) — 信令流程与故障排查 3. [TS 38.331 Section ShortMAC-I — iTecSpec](https://itecspec.com/3gpp/38.331/s/shortmac-i) — ShortMAC-I 16 LSB 定义与用途 4. [3GPP TS 33.501 — Security architecture and procedures for 5G system](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169) — Annex A K~gNB~/NH 水平与垂直密钥推演 5. [RRC re-establishment 重建流程 — 知乎](https://zhuanlan.zhihu.com/p/259211491) — 触发原因与上下文恢复中文解析 --- > 本文由「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 等场景全覆盖。