首页 › ran › 5G RRC连接重建shortMAC-I全链拆解

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 上：

sequenceDiagram
    autonumber
    participant UE
    participant TgNB as 目标 gNB
    participant SgNB as 源 gNB(可选)

    Note over UE: RLF/HO失败/重配失败<br/>本地仍持有 AS 安全上下文
    UE->>UE: 小区选择(同频/异频/异系统回退)
    UE->>TgNB: RACH (Msg1/Msg2 或 2-step MsgA/MsgB)
    UE->>TgNB: RRCReestablishmentRequest<br/>(C-RNTI, 源PCI, shortMAC-I, cause)

    alt 目标gNB ≠ 源gNB 且无本地上下文
        TgNB->>SgNB: XnAP RETRIEVE UE CONTEXT REQUEST<br/>(C-RNTI, 源PCI)
        SgNB->>TgNB: XnAP RETRIEVE UE CONTEXT RESPONSE<br/>(UE上下文, Kng-ran*, PDCP SN状态, DRB信息)
    end

    TgNB->>TgNB: 校验 shortMAC-I<br/>水平/垂直密钥推演出新 K_gNB
    TgNB->>UE: RRCReestablishment<br/>(masterCellGroup默认配置, nextHopChainingCount)

    Note over UE: 用新 NCC 做垂直推演<br/>重新派生 K_RRCenc/K_RRCint
    UE->>UE: 重配 SRB1, 复用已激活安全
    UE->>TgNB: RRCReestablishmentComplete

    TgNB->>UE: RRCReconfiguration(可选)<br/>恢复 SRB2 + DRB
    Note over UE: 业务面恢复

关键点解读：

第 2 步 RACH 不可省：重建请求是 RRC 消息，必须先有 MAC 层的随机接入获得 C-RNTI 与上行同步，才能在 SRB1 上发送。这也是为什么重建延迟的下限是"小区选择 + 随机接入"耗时。
第 3 步三要素：C-RNTI + 源 PCI 用于"寻址"，shortMAC-I 用于"鉴真"，cause 用于"告警分类"。
上下文获取是分支决策：同 gNB 内直接复用内存上下文；跨 gNB 必须走 Xn 接口的 RETRIEVE UE CONTEXT 流程（TS 38.423）。
RRCReestablishment 的两条核心 IE：masterCellGroup（带有一个默认/最小配置）与 nextHopChainingCount（触发密钥推演的"齿轮"）。

四、RRCReestablishmentRequest 的 IE 结构与逐位拆解

该消息定义在 TS 38.331 §6.2.2，承载于 UL-DCCH，使用 SRB1。值得注意的是：这是重建流程中唯一一条在 AS 安全尚未"重新挂载"前发送的消息，因此它不加密、不完整性保护——这也是为什么必须靠 shortMAC-I 单独完成身份证明。

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<br/>源 PCell 的 C-RNTI]
    C --> C2[physCellId: INTEGER 0..1007<br/>源 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。

flowchart TD
    subgraph 输入
        I1[源 PCI]
        I2[源 C-RNTI]
    end
    subgraph 密钥与算法
        K[源小区 K_RRCint]
        IA[源小区 IntegrityProtAlgorithm]
    end
    I1 --> M[按 38.331 规定的<br/>输入串拼接/填充]
    I2 --> M
    K --> F[MAC-I 完整性算法计算<br/>例如 NIA2 = 128-SNOW-3G]
    IA --> F
    M --> F
    F --> T[完整 32bit MAC-I]
    T --> S[取最低 16 bit]
    S --> R((shortMAC-I<br/>16 bit))

设计意图三连问——为什么有了 C-RNTI + PCI 还要 shortMAC-I？

防伪造：C-RNTI 与 PCI 都是明文、可被任意监听者获取的标识。若没有 shortMAC-I，一个恶意 UE 只需知道某合法 UE 的 (C-RNTI, PCI) 就能冒充它发起重建，劫持其上下文（攻击者获得该 UE 的 DRB 承载）。shortMAC-I 用只有合法 UE 与源 gNB 才掌握的 K~RRCint~ 计算，构成"知识证明（proof of knowledge）"，攻击者无法伪造。
防冲突：C-RNTI 16 bit + PCI 10 bit 也只有 26 bit 空间，跨 gNB 取上下文时存在理论上的碰撞窗口。16 bit 的 shortMAC-I 进一步把冲突概率压低 1/65536，配合 gNB 本地的 C-RNTI 表，实际碰撞概率可忽略。
复用已有密钥：无需引入新协议，直接复用已激活的 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）机制。

flowchart TD
    OKgNB[源 gNB 持有的当前 K_gNB] --> H{目标 gNB<br/>是否=源 gNB?}

    H -- 同 gNB --> V1[复用当前 K_gNB]
    H -- 跨 gNB --> HD[水平推演:<br/>K_ng-ran* = KDF K_gNB, 0x1F ]

    HD --> XN[源gNB经 XnAP 将 K_ng-ran*<br/>随上下文发给目标 gNB]
    XN --> TP[目标 gNB 用目标 PCI 做一次推演:<br/>K_gNB' = KDF K_ng-ran*, target_PCI ]

    V1 --> VT[用 RRCReestablishment 携带的<br/>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）

flowchart TD
    A[目标 gNB 收到<br/>RRCReestablishmentRequest] --> B{本地是否存在<br/>C-RNTI+源PCI 的上下文?}
    B -- 是(同 gNB 内) --> C[直接复用本地上下文]
    B -- 否 --> D{与源 gNB 是否有 Xn 连接?}
    D -- 是 --> E[发起 XnAP RETRIEVE UE CONTEXT REQUEST]
    E --> F{源 gNB 校验<br/>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 状态转换视角

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: 重建成功<br/>(全程未离开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 之后长时间无响应，则重建失败。

常见故障点：

shortMAC-I 校验失败：源 gNB 已释放上下文（如 UE 失联过久触发隐式去注册，上下文被删），或 K~RRCint~ 因某代密钥推演不一致导致重算结果不符。排查：核对源 gNB 上下文是否存在、NCC 同步是否正常。
目标小区无 Xn 连接：跨 gNB 重建但两端无 Xn 接口，直接退化为 RRC Setup。排查 Xn 链路状态与邻区关系（ANR）。
重建"乒乓"：UE 反复在某几个小区间重建，多为覆盖空洞或邻区漏配/错配 PCI（PCI MOD3/MOD6 冲突导致 CRS/CSI-RS 干扰）。
重建比率高：核心网侧统计重建成功率与重建原因分布，handoverFailure 居多指向切换参数（迟滞、TTT、门限）不当；otherFailure 居多指向覆盖与干扰。
加密/完整性不匹配：重建后 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"是两个不同的标识。

参考来源

3GPP TS 38.331 V18.6.0 — NR RRC Protocol Specification — §5.3.7 RRC connection re-establishment、§6.2.2/§6.3.4 IE 定义与 ShortMAC-I 推导
5G NR RRC Reestablishment Procedure — 3GLTEInfo Call Flow — 信令流程与故障排查
TS 38.331 Section ShortMAC-I — iTecSpec — ShortMAC-I 16 LSB 定义与用途
3GPP TS 33.501 — Security architecture and procedures for 5G system — Annex A K~gNB~/NH 水平与垂直密钥推演
RRC re-establishment 重建流程 — 知乎 — 触发原因与上下文恢复中文解析

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