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分离架构下的重建信令
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层检测到完整性失败 |
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
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 | 触发原因 | 网络据此进行统计和优化 |
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):
K<sub>RRCint</sub> 密钥 + 源PCI + 源频点ARFCN + 消息内容设计巧妙之处:目标gNB在收到shortMAC-I后,无法独立验证(因为它没有源小区的密钥),必须先通过Xn从源gNB获取UE上下文(含安全密钥),然后才能验证。这保证了: - 目标gNB必须与源gNB通信,防止伪基站攻击 - 密钥不会在空口暴露 - 即使shortMAC-I被截获,16位空间也足以防止暴力猜测(65536种可能)
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,确保密钥与小区绑定
当目标gNB收到RRCReestablishmentRequest后,需要从源gNB获取UE上下文。这是整个重建流程中最关键的网元间交互:
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等
| 失败原因 | 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分离的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) |
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: 重配成功
当以下情况发生时,UE必须回退到RRC Setup(相当于全新建连接):
回退到RRC Setup意味着: - UE进入RRC_IDLE → 发起RRC Setup → 发起Registration → 重新建立PDU Session - 整个恢复时间从<100ms增加到数秒级别 - 业务中断明显,用户体验下降
# 过滤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
| 故障现象 | 可能根因 | 排查思路 |
|---|---|---|
| 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)。
本文由「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 等场景全覆盖。
