首页 › ran › 5G RRC连接重建信令流全链拆解

5G RRC连接重建(RRC Re-establishment)信令流全链拆解

一、机制定位与设计意图

RRC连接重建是5G NR中最关键的无线链路故障恢复机制之一。当UE处于RRC_CONNECTED状态时遭遇无线链路失败(RLF)、切换失败、RRC重配失败或完整性校验失败后,UE并不会直接回退到RRC_IDLE重新走完整注册流程,而是尝试通过RRC连接重建在目标小区快速恢复SRB1和安全上下文,最大限度减少业务中断时间。

核心设计意图:

该机制定义于: - TS 38.331 Section 5.3.7 — RRC连接重建信令流程与IE定义 - TS 38.401 Section 8.7 — NG-RAN架构视角的重建过程 - TS 33.501 Section 6.11 — 重建过程中的安全处理 - TS 38.473 — F1AP接口在CU-DU分离架构下的重建信令

二、触发条件与前置检测

2.1 四种触发原因

UE在RRC_CONNECTED状态下可能因以下原因发起RRC连接重建:

触发原因 reestablishmentCause值 典型场景 关键检测参数
无线链路失败 otherFailure 覆盖空洞、强干扰、T310超时 T310=1000ms(默认), N310=n310连续失步
切换失败 handoverFailure T304超时(目标小区同步失败) T304=100ms/200ms/500ms等
RRC重配失败 reconfigurationFailure UE无法应用重配参数 T321超时或IE解析异常
完整性校验失败 otherFailure SRB1/DRB的MAC-I校验失败 PDCP层检测到完整性失败

2.2 RLF检测机制(TS 38.331 Section 5.3.10)

RLF检测是触发RRC重建的最常见原因,其核心是同步/失步计数器+定时器机制:

flowchart TD
    A[UE评估PDCCH BLER] -->|BLER >= Qout| B[N310计数器+1]
    A -->|BLER < Qout| C[N311计数器+1]
    B -->|N310达到门限| D[启动T310定时器]
    D -->|T310超时| E[宣告RLF]
    D -->|N311达到门限| F[停止T310, 恢复同步]
    E --> G[启动T311, 开始小区选择]
    G -->|找到合适小区| H[发起RRC连接重建]
    G -->|T311超时| I[进入RRC_IDLE]

关键定时器参数说明:

定时器 默认值 触发条件 停止条件 超时后果
T310 1000ms N310次连续失步 N311次连续同步 宣告RLF
T311 30000ms RLF宣告 选择到合适小区 进入RRC_IDLE
T301 160ms(由gNB配置) 发送RRCReestablishmentRequest 收到RRCReestablishment 进入RRC_IDLE

三、完整信令时序图

以下展示从RLF检测到RRC重建成功的完整信令流程,包含gNB间Xn上下文获取和CU-DU分离架构下的F1AP交互:

sequenceDiagram
    participant UE as UE
    participant DU as gNB-DU(目标)
    participant CU as gNB-CU(目标)
    participant Src as gNB-CU(源)
    participant AMF

    Note over UE: RLF检测 / 切换失败 / 重配失败
    Note over UE: 启动T311, 小区选择

    rect rgb(255, 230, 230)
    Note over UE,DU: Phase 1: 随机接入
    UE->>DU: 1. PRACH Preamble (Msg1)
    DU->>UE: 2. Random Access Response (Msg2, 分配新C-RNTI+TA)
    end

    rect rgb(230, 255, 230)
    Note over UE,CU: Phase 2: RRC重建请求
    UE->>DU: 3. RRCReestablishmentRequest (SRB0/CCCH)
    Note right of UE: ue-Identity={C-RNTI, PCI}<br/>reestablishmentCause<br/>shortMAC-I(16bit)
    DU->>CU: 4. F1AP: INITIAL UL RRC MESSAGE TRANSFER
    end

    rect rgb(230, 230, 255)
    Note over CU,Src: Phase 3: Xn上下文获取
    CU->>Src: 5. XnAP: RETRIEVE UE CONTEXT REQUEST
    Note right of CU: 携带源PCI + C-RNTI + shortMAC-I
    Src->>CU: 6. XnAP: RETRIEVE UE CONTEXT RESPONSE
    Note left of Src: 携带完整UE上下文:<br/>CellGroupConfig, SecurityContext,<br/>DRB列表, PDU Session信息
    end

    rect rgb(255, 255, 230)
    Note over UE,AMF: Phase 4: RRC重建完成
    CU->>DU: 7. F1AP: DL RRC MESSAGE TRANSFER (含RRCReestablishment)
    DU->>UE: 8. RRCReestablishment (SRB1/DCCH)
    Note left of UE: masterCellGroupConfig<br/>radioBearerConfig<br/>nextHopChainingCount
    UE->>DU: 9. RRCReestablishmentComplete (SRB1/DCCH, 加密+完整性保护)
    DU->>CU: 10. F1AP: UL RRC MESSAGE TRANSFER
    end

    rect rgb(240, 230, 255)
    Note over CU,AMF: Phase 5: 后续恢复(可选)
    CU->>AMF: 11. NGAP: PATH SWITCH REQUEST
    Note right of CU: 通知AMF UE已切换到新gNB
    AMF->>CU: 12. NGAP: PATH SWITCH REQUEST ACK
    CU->>Src: 13. XnAP: UE CONTEXT RELEASE
    CU->>UE: 14. RRCReconfiguration (恢复DRB等)
    UE->>CU: 15. RRCReconfigurationComplete
    end

四、关键IE深度解析

4.1 RRCReestablishmentRequest消息结构

RRCReestablishmentRequest ::=    SEQUENCE {
    ue-Identity         ReestablishmentUE-Identity,
    reestablishmentCause    ENUMERATED {reconfigurationFailure,
                                        handoverFailure,
                                        otherFailure,
                                        spare},
    spare                    BIT STRING (SIZE (2))
}

ReestablishmentUE-Identity ::=    SEQUENCE {
    c-RNTI                 BIT STRING (SIZE (16)),
    physCellId             PhysCellId (0..1007),
    shortMAC-I             ShortMAC-I
}

ShortMAC-I ::=    BIT STRING (SIZE (16))

各IE字段详解:

IE字段 长度 作用 关键说明
c-RNTI 16 bit UE在源小区的标识 目标gNB用此从源gNB获取上下文
physCellId 10 bit 源小区物理ID (0-1007) 指示上下文来源小区
shortMAC-I 16 bit 截断的MAC-I验证码 由源小区安全密钥推导,用于UE身份验证
reestablishmentCause 2 bit 触发原因 网络据此进行统计和优化

4.2 shortMAC-I的生成过程(TS 33.501 Section 6.11)

shortMAC-I是RRC重建安全机制的核心,其生成过程如下:

flowchart LR
    A["K<sub>RRCint</sub>"] -->|KDF| B["计算完整MAC-I<br/>(128 bit)"]
    C["源PCI + 源频点ARFCN"] --> B
    D["消息内容"] --> B
    B -->|截断低16位| E["shortMAC-I<br/>(16 bit)"]

    style A fill:#ff9999
    style E fill:#99ff99

推导步骤(TS 33.501 Section 6.11.2):

  1. 输入参数:源小区的 K<sub>RRCint</sub> 密钥 + 源PCI + 源频点ARFCN + 消息内容
  2. 计算完整MAC-I:使用SNOW 3G / AES / ZUC算法(取决于安全算法配置),计算128位完整MAC-I
  3. 截断处理:取完整MAC-I的最低16位作为shortMAC-I
  4. 验证流程:目标gNB通过Xn从源gNB获取UE安全上下文后,用相同参数重新计算并与UE发送的shortMAC-I比对

设计巧妙之处:目标gNB在收到shortMAC-I后,无法独立验证(因为它没有源小区的密钥),必须先通过Xn从源gNB获取UE上下文(含安全密钥),然后才能验证。这保证了: - 目标gNB必须与源gNB通信,防止伪基站攻击 - 密钥不会在空口暴露 - 即使shortMAC-I被截获,16位空间也足以防止暴力猜测(65536种可能)

4.3 RRCReestablishment消息结构

RRCReestablishment ::=    SEQUENCE {
    rrc-TransactionIdentifier    RRC-TransactionIdentifier (0..3),
    criticalExtensions           CHOICE {
        rrcReestablishment           RRCReestablishment-IEs
    }
}

RRCReestablishment-IEs ::=    SEQUENCE {
    masterCellGroup          OCTET STRING,      -- 包含CellGroupConfig
    lateForwardingSCG        ENUMERATED {true} OPTIONAL,
    radioBearerConfig        RadioBearerConfig,
    masterKeyUpdate          MasterKeyUpdate OPTIONAL,
    dedicatedNAS-MessageList SEQUENCE OF DedicatedNAS-Message OPTIONAL,
    nonCriticalExtension     RRCReestablishment-v1530-IEs OPTIONAL
}

MasterKeyUpdate ::=    SEQUENCE {
    keySetChangeIndicator    BOOLEAN,
    nextHopChainingCount     NextHopChainingCount (0..7),
    k-RFCfg                  Key-RFCfg OPTIONAL
}
IE字段 类型 含义
masterCellGroup OCTET STRING 编码后的CellGroupConfig(MAC/RLC/PHY全量配置)
radioBearerConfig RadioBearerConfig SRB1的PDCP/SDAP配置,仅恢复SRB1
nextHopChainingCount 0..7 密钥链计数器,用于推导新KgNB
keySetChangeIndicator BOOLEAN 指示是否需要更新密钥集
dedicatedNAS-MessageList 序列 携带NAS消息(如5G-GUTI重分配)

重要注意:RRCReestablishment仅恢复SRB1,DRB的恢复需要在后续的RRCReconfiguration中完成。这是刻意的设计——先恢复信令承载,再逐步恢复数据承载,降低单次消息的处理复杂度。

五、安全密钥推演链

RRC连接重建涉及一次完整的密钥层级更新,确保前向/后向安全:

flowchart TD
    A["K<sub>AMF</sub> (AMF根密钥)"] -->|"KDF"| B["K<sub>gNB</sub> (源gNB密钥)"]
    B -->|"KDF + PCI + ARFCN"| C["K<sub>gNB</sub>* (目标gNB密钥)"]
    C -->|"KDF + NH"| D["K<sub>gNB-new</sub> (新gNB密钥)"]
    D -->|"KDF"| E["K<sub>RRCint</sub>"]
    D -->|"KDF"| F["K<sub>RRCenc</sub>"]
    D -->|"KDF"| G["K<sub>UPint</sub>"]
    D -->|"KDF"| H["K<sub>UPenc</sub>"]

    style A fill:#ffcccc
    style B fill:#ffddaa
    style C fill:#ffffaa
    style D fill:#aaffaa
    style E fill:#aaddff
    style F fill:#aaddff
    style G fill:#aaddff
    style H fill:#aaddff

密钥推演关键参数(TS 33.501 Section 6.9.2):

推演步骤 输入参数 输出密钥 算法
KAMF → KgNB PCI of target, ARFCN-DL of target KgNB* HKDF-SHA-256
KgNB* → KgNB-new NH value, NH chaining count KgNB-new HKDF-SHA-256
KgNB-new → KRRCint algorithmType=RRC-int, algorithmID KRRCint HKDF-SHA-256
KgNB-new → KRRCenc algorithmType=RRC-enc, algorithmID KRRCenc HKDF-SHA-256
KgNB-new → KUPenc algorithmType=UP-enc, algorithmID KUPenc HKDF-SHA-256

关键安全属性: - 前向安全:即使KgNB-new泄露,也无法反推源KgNB(KDF单向性) - 后向安全:通过nextHopChainingCount递增和NH chain,保证新旧密钥隔离 - PCI绑定:KgNB*的推导包含目标小区PCI和ARFCN,确保密钥与小区绑定

六、Xn接口上下文获取流程

当目标gNB收到RRCReestablishmentRequest后,需要从源gNB获取UE上下文。这是整个重建流程中最关键的网元间交互:

6.1 XnAP消息交互

RETRIEVE UE CONTEXT REQUEST:
  - Source PCI
  - Source C-RNTI  
  - shortMAC-I (16 bit)
  - Target Cell ID

RETRIEVE UE CONTEXT RESPONSE (成功):
  - UE Context (完整):
    · CellGroupConfig (MAC/RLC/PHY配置)
    · Security Context (密钥材料)
    · RRC-Container (源小区的RRC配置)
    · PDU Session Resource List
    · DRB Information
    · UE Aggregate Maximum Bit Rate
    · Allowed Nssai List
  - RRC-Container with RRCReestablishment message (可选)

RETRIEVE UE CONTEXT FAILURE (失败):
  - Cause: unknown-pair, short-mac-failure等

6.2 上下文获取失败场景

失败原因 Cause值 网络侧行为 UE侧感知
源gNB找不到对应UE unknown-pair 目标gNB下发RRCReject UE等待后重试或回退
shortMAC-I验证失败 short-mac-failure 目标gNB拒绝重建 安全验证失败
源gNB不可达 Xn接口故障 目标gNB超时 T301超时
源gNB已释放上下文 ue-context-released 无法获取上下文 需回退到RRC Setup

七、CU-DU分离架构下的重建流程

在CU-DU分离的gNB架构下(TS 38.401, TS 38.473),RRC重建涉及额外的F1AP信令:

sequenceDiagram
    participant UE
    participant DU as gNB-DU(目标)
    participant CU as gNB-CU(目标)

    Note over UE: RLF后选择到目标DU小区

    UE->>DU: PRACH + RRCReestablishmentRequest
    DU->>DU: 查找old gNB-DU F1AP UE ID
    Note over DU: 若old UE在本DU:<br/>直接获取上下文

    alt Old UE在同一个DU
        DU->>DU: 复用原有上下文
        DU->>CU: INITIAL UL RRC MESSAGE TRANSFER
    else Old UE在不同DU或同一CU下
        DU->>CU: INITIAL UL RRC MESSAGE TRANSFER
        Note right of DU: 含源PCI + C-RNTI
        CU->>CU: 通过PCI确定源gNB
        CU->>CU: Xn获取源UE上下文
        CU->>DU: F1AP: UE CONTEXT SETUP REQUEST
        Note left of CU: 携带CellGroupConfig等
        DU->>CU: F1AP: UE CONTEXT SETUP RESPONSE
    end

    CU->>DU: F1AP: DL RRC MESSAGE TRANSFER (RRCReestablishment)
    DU->>UE: RRCReestablishment
    UE->>DU: RRCReestablishmentComplete
    DU->>CU: F1AP: UL RRC MESSAGE TRANSFER

F1AP关键IE(UE CONTEXT SETUP REQUEST中):

IE 说明
gNB-CU UE F1AP ID CU侧UE标识
gNB-DU UE F1AP ID DU侧UE标识
SpCell Config 特殊小区配置
DRB-To-Setup-List 待建立DRB列表
SRB-To-Setup-List SRB配置(至少SRB1)
UE Context Setup Cause 原因值标识(如re-establishment)

八、重建失败与回退机制

8.1 状态转换全景图

stateDiagram-v2
    [*] --> RRC_CONNECTED: RRC Setup完成
    RRC_CONNECTED --> RLF_Detected: T310超时 / 切换失败 / 重配失败
    RLF_Detected --> Cell_Selection: 启动T311
    Cell_Selection --> RRC_Reestab_Proceed: 找到合适小区(T311未超时)
    Cell_Selection --> RRC_IDLE: T311超时

    RRC_Reestab_Proceed --> Wait_Reestab: 发送Request, 启动T301
    Wait_Reestab --> RRC_CONNECTED: 收到RRCReestablishment
    Wait_Reestab --> RRC_IDLE: T301超时
    Wait_Reestab --> RRC_IDLE: 收到RRCReject + T302超时

    RRC_CONNECTED --> RRC_Reconfig: 恢复DRB
    RRC_Reconfig --> RRC_CONNECTED: 重配成功

8.2 回退到RRC Setup的场景

当以下情况发生时,UE必须回退到RRC Setup(相当于全新建连接):

  1. T301超时:目标gNB未在规定时间内响应
  2. T311超时:找不到合适小区
  3. RRCReject:网络主动拒绝(如拥塞控制)
  4. Xn上下文获取失败:源gNB无法提供上下文
  5. 安全验证失败:shortMAC-I不匹配

回退到RRC Setup意味着: - UE进入RRC_IDLE → 发起RRC Setup → 发起Registration → 重新建立PDU Session - 整个恢复时间从<100ms增加到数秒级别 - 业务中断明显,用户体验下降

九、抓包识别与故障排查

9.1 Wireshark/TShark抓包过滤

# 过滤RRC Reestablishment Request (RRC层)
tshark -i eth0 -f "port 38472" -Y "rrc.rrcConnectionReestablishmentRequest"

# 过滤XnAP Retrieve UE Context
tshark -i eth0 -f "port 38473" -Y "xnap.RetriveUEContext"

# 过滤F1AP UE Context Setup (CU-DU架构)
tshark -i eth0 -f "port 38472" -Y "f1ap.procedureCode == 40"

# 统计RRC重建成功率
tshark -r capture.pcap -Y "rrc.rrcConnectionReestablishmentRequest || rrc.rrcConnectionReestablishment || rrc.rrcConnectionReestablishmentComplete" -T fields -e rrc.messageType | sort | uniq -c

9.2 常见故障点与排错思路

故障现象 可能根因 排查思路
T301超时率极高 gNB处理延迟或Xn链路异常 检查Xn接口时延和gNB CPU利用率
重建成功率<70% 覆盖空洞或邻区配置错误 分析PCI和reestablishmentCause统计
shortMAC-I验证失败 源gNB安全上下文异常 核查源gNB的密钥更新日志
重建后DRB不恢复 RRCReconfiguration丢失 检查gNB是否下发DRB重配消息
重建导致大量S1/NG Reset AMF侧UE上下文不一致 核查Path Switch流程是否完成
## 十、与LTE RRC重建的对比
维度 5G NR 4G LTE
规范 TS 38.331 Section 5.3.7 TS 36.331 Section 5.3.7
消息名称 RRCReestablishmentRequest RRCConnectionReestablishmentRequest
随机接入 必须先完成4-step RA 必须先完成4-step RA
身份验证 shortMAC-I (16 bit) shortMAC-I (16 bit)
密钥推演 KgNB → KgNB* (含PCI+ARFCN) KeNB → KeNB* (含PCI+EARFCN)
CU-DU分离 支持,通过F1AP交互 不适用(无CU-DU分离)
PDCP恢复 PDCP status report可选 PDCP status report可选
RRC Inactive 可回退到RRC Resume N/A(LTE无此状态)
异系统重建 不支持(NR与LTE间) 不支持(LTE与NR间)

常见问题

Q1: RRC连接重建和RRC连接恢复(RRC Resume)有什么区别?

A: 两者是完全不同的机制。RRC重建(Re-establishment)发生在RRC_CONNECTED状态下发生故障时,目标是恢复已有的SRB1连接;而RRC恢复(Resume)发生在RRC_INACTIVE状态下,UE有完整的暂停上下文,通过resumeFromRRC-Inactive恢复到RRC_CONNECTED。重建需要Xn上下文获取,恢复则不需要(UE本地保存上下文)。

Q2: UE如何知道应该向哪个小区发起重建?

A: UE在RLF检测后启动T311定时器,同时执行小区选择过程。UE会根据S准则(Srxlev > 0 且 Squal > 0)在同频/异频邻区中选择合适的小区。UE优先选择信号质量最好的小区,但必须是PLMN匹配的合适小区。如果T311超时仍未找到合适小区,UE进入RRC_IDLE。

Q3: 为什么RRCReestablishment只恢复SRB1而不直接恢复DRB?

A: 这是刻意的设计决策。原因有二:第一,SRB1是信令承载,恢复后网络可以通过RRCReconfiguration精确控制DRB的恢复顺序和参数;第二,DRB可能涉及UPF路径切换(Path Switch),需要在NGAP侧协调。分离处理降低了单步操作的复杂度,也便于灵活处理部分DRB不需要恢复的场景。

Q4: shortMAC-I只有16位,是否存在碰撞风险?

A: 理论上存在,但实际风险极低。65536种可能值在短时间内被随机碰撞的概率很低,且目标gNB会先通过Xn从源gNB获取上下文进行验证,攻击者无法伪造合法的源小区密钥。此外,shortMAC-I的验证是一次性的(仅在重建请求时使用),后续消息使用完整的安全保护。

Q5: gNB收到重建请求后,如果源gNB不可达怎么办?

A: 目标gNB会等待Xn RETRIEVE UE CONTEXT RESPONSE直到内部定时器超时(典型值2-5秒)。如果超时未收到响应,目标gNB将拒绝重建请求(可能发送RRCReject或直接不响应),UE的T301超时后进入RRC_IDLE,随后发起完整的初始接入流程(RRC Setup → Registration → PDU Session Establishment)。

参考来源

  1. 3GPP TS 38.331 V18.6.0 — Section 5.3.7 RRC connection re-establishment, Section 5.3.10 RLF detection
  2. 3GPP TS 38.401 V19.x — Section 8.7 RRC connection reestablishment (NG-RAN architecture perspective)
  3. 3GPP TS 33.501 V18.10.0 — Section 6.11 Security handling for RRC connection re-establishment procedure
  4. WirelessBrew — RRC Reestablishment request in 5G NR — 触发条件、IE分析和回退机制详解
  5. 3GLTEInfo — 5G NR RRC Reestablishment Procedure — 完整信令流程图和故障恢复上下文

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