NGAP Initial Context Setup(初始上下文建立)是AMF通过N2接口向gNB注入UE完整上下文的唯一原子操作。它在一个过程中同时完成三件关键事项:安全上下文下推、PDU会话无线资源建立、UE能力信息确认。这个过程承载了5G网络从"知道UE存在"到"UE可以通信"的核心状态跃迁。
与4G S1AP的Initial Context Setup相比,5G NGAP版本在以下方面发生了根本变化:
Initial Context Setup在以下四个场景中被触发:
| 触发场景 | 触发条件 | 关键差异 |
|---|---|---|
| 初始Registration | gNB发送Initial UE Message(RRC Setup Complete + Registration Request NAS) | 必须携带完整Security Context |
| Service Request | UE从CM-IDLE恢复,发起Service Request | 可能携带已有PDU Session资源 |
| N2 Handover | 切换目标gNB需要建立UE上下文 | 携带Source gNB的UE History |
| RAN Paging后响应 | gNB寻呼UE成功,UE响应 | 可能不建立新PDU Session |
stateDiagram-v2
[*] --> InitialUEMessage: gNB收到RRC Setup Complete
InitialUEMessage --> InitialContextSetupRequest: AMF完成NAS认证/安全
InitialContextSetupRequest --> SecurityModeCommand: gNB推送安全上下文到UE
SecurityModeCommand --> SecurityModeComplete: UE确认安全激活
SecurityModeComplete --> RRCReconfiguration: gNB配置PDU Session无线资源
RRCReconfiguration --> RRCReconfigurationComplete: UE确认资源配置
RRCReconfigurationComplete --> InitialContextSetupResponse: gNB向AMF确认
InitialContextSetupResponse --> [*]: UE上下文建立完成
InitialContextSetupRequest --> InitialContextSetupFailure: 资源不足/安全失败
InitialContextSetupFailure --> [*]: 上下文建立失败
以下时序图展示了Registration触发的完整Initial Context Setup过程,包含所有关键IE和定时器:
sequenceDiagram
participant UE
participant gNB
participant AMF
Note over UE,gNB: Phase 0: RRC连接建立(已提前完成)
UE->>gNB: RRC Setup Complete + NAS Registration Request
gNB->>AMF: NGAP Initial UE Message<br/>RAN-UE-NGAP-ID, UserLocationInformation,<br/>RRC Establishment Cause, 5G-S-TMSI
Note over AMF: AMF执行NAS认证(5G AKA/EAP-AKA')<br/>NAS Security Mode Command/Complete
rect rgb(230, 240, 255)
Note over AMF,gNB: Phase 1: 安全上下文注入
AMF->>gNB: NGAP Initial Context Setup Request<br/>[Security Context]<br/>[UESecurityCapabilities]<br/>[SecurityKey]
end
rect rgb(255, 240, 230)
Note over gNB,UE: Phase 2: 安全激活
gNB->>UE: AS Security Mode Command<br/>选定的5G-IA/5G-EA算法<br/>+ SecurityKey衍生
UE->>gNB: AS Security Mode Complete
end
rect rgb(230, 255, 230)
Note over AMF,gNB: Phase 3: PDU会话资源建立
AMF->>gNB: Initial Context Setup Request中携带<br/>PDU Session Resource Setup Request List<br/>[PDU Session ID, S-NSSAI, QoS Flow List,<br/>UL/DL TEID, Transport Layer Address]
gNB->>UE: RRC Reconfiguration<br/>DRB配置、QoS Flow映射
UE->>gNB: RRC Reconfiguration Complete
gNB->>AMF: NGAP Initial Context Setup Response<br/>PDU Session Resource Setup Response List<br/>[AN Tunnel Info, QoS Flow Per TNL Info]
end
Security Context是Initial Context Setup Request中最敏感的IE,包含gNB推衍所有AS层安全密钥的种子信息。
TS 38.413 Section 9.3.37 - Security Key IE结构:
SecurityKey ::= SEQUENCE {
k-gNB BIT STRING (SIZE(256)), -- 5G核心网推衍的gNB密钥
k-n3iwf BIT STRING (SIZE(256)) OPTIONAL, -- N3IWF密钥(非可信接入)
k-ng-ran BIT STRING (SIZE(256)) OPTIONAL -- NG-RAN密钥(可信接入)
}
密钥推衍链路(TS 33.501 Section 6.9.2):
graph TD
KAMF["KAMF (AMF根密钥)"] -->|"KDF: FC=0x6E, P0=accessType"| KgNB["KgNB"]
KAMF -->|"KDF: FC=0x6E, P0=N3IWF"| KN3IWF["KN3IWF"]
KgNB -->|"KDF: FC=0x70, P0=algorithmType"| KRRCEnc["K_RRC_enc"]
KgNB -->|"KDF: FC=0x70"| KRRCEnt["K_RRC_int"]
KgNB -->|"KDF: FC=0x70"| KUPEnc["K_UP_enc"]
KgNB -->|"横向推衍 FC=0x69"| KgNB_next["Next-hop KgNB"]
KgNB_next -->|"继续推衍"| KRRCEnc2["K_RRC_enc(next)"]
style KAMF fill:#ff9999
style KgNB fill:#ffcc99
style KRRCEnc fill:#99ff99
style KRRCEnt fill:#99ff99
style KUPEnc fill:#99ff99
| 字段 | 长度 | 来源 | 说明 |
|---|---|---|---|
| k-gNB | 256 bits | AMF通过KDF从KAMF推衍 | gNB根密钥,用于推衍RRC/UP加密和完整性保护密钥 |
| SecurityAlgorithm | 变长 | AMF从UE Security Capabilities中选择 | 5G-IAx/5G-EAx算法对 |
| NextHopChainingCount | 8 bits | AMF维护计数器 | KgNB横向推衍的链式计数器,初始值为0 |
| UESecurityCapabilities | 变长 | UE在Registration Request中上报 | UE支持的安全算法列表,含NR/EIRP/NG-RAN能力 |
AMF在Initial Context Setup Request中为gNB提供UE级别的速率上限,这是5G新引入的聚合速率控制机制。
TS 38.413 Section 9.3.1.55:
| 参数 | 含义 | 对4G的改进 |
|---|---|---|
| UE-AMBR-for-UL | UE所有Non-GBR QoS Flow上行聚合最大速率 | 替代S1AP的UE-AMBR,粒度为QoS Flow级 |
| UE-AMBR-for-DL | UE所有Non-GBR QoS Flow下行聚合最大速率 | 支持按S-NSSAI独立配置 |
| UE-AMBR-for-UL-with-NSA | Non-GBR且Non-Standardized Attribute的上行AMBR | 5G新增,支持定制化QoS属性 |
PDU Session Resource Setup是嵌入在Initial Context Setup Request中的关键传输容器,AMF将SMF通过N1/N2 Container传递的N2 SM Information封装在此IE中。
IE层级结构(TS 38.413 Section 9.3.1.57):
PDUSessionResourceSetupRequestList ::= SEQUENCE {
pduSessionID INTEGER (0..255), -- PDU Session标识
pDUSessionNAS-PDU NAS-PDU OPTIONAL, -- NAS PDU(发给UE的PDU Session Establishment Accept)
pDUSessionResourceSetupRequestTransfer OCTET STRING -- N2 SM Information
}
N2 SM Information内部结构(TS 38.413 Section 9.3.2.1):
graph LR
subgraph "N2 SM Information (来自SMF)"
A["PDU Session ID"]
B["S-NSSAI"]
C["QoS Flow List"]
D["UL UP Transport Info<br/>(TEID + UPF IP)"]
E["Session-AMBR"]
F["PDU Session Type<br/>(IPv4/IPv6/Ethernet)"]
end
subgraph "QoS Flow Item"
C1["QoS Flow Identifier (QFI)"]
C2["QoS Profile<br/>(5QI, ARP, GBR参数)"]
C3["UL/DL QoS Flow Map"]
end
C --> C1
C --> C2
C --> C3
style A fill:#e8f4f8
style B fill:#fff3cd
style C fill:#d4edda
style D fill:#f8d7da
| N2 SM IE | 来源 | 用途 | 博弈点 |
|---|---|---|---|
| UL UP Transport Info | SMF → UPF分配 | gNB用此TEID/IP向UPF发送上行数据 | UPF锚点位置决定UL时延 |
| S-NSSAI | SMF通过NSSF选择 | gNB按切片隔离资源 | 切片间资源抢占 |
| QoS Flow QFI List | PCF策略决策→SMF映射 | gNB将QFI映射到DRB | QFI-to-DRB映射策略影响UE复杂度 |
| Session-AMBR | UDM签约数据→SMF | gNB的Non-GBR速率控制 | 与UE-AMBR取最小值 |
| PDU Session NAS-PDU | SMF生成 | 透传给UE的PDU Session Establishment Accept | NAS容器需AS安全保护 |
AMF在Initial Context Setup Request中必须一次性携带完整的Security Context。这是因为:
设计意图(TS 33.501 Section 6.7.1): - gNB收到KgNB后,必须先完成AS Security Mode Command/Complete,才能处理后续的RRC Reconfiguration(含DRB配置) - 原因:PDU Session Establishment Accept NAS消息通过NAS Container透传,必须先激活AS安全,否则NAS消息无法加密 - 博弈点:AMF在发送Initial Context Setup Request之前,必须先完成NAS层Security Mode Command/Complete(即NAS安全已激活),然后才能将KgNB下推给gNB
定时器约束: - AMF设置定时器T3524(Initial Context Setup Response等待定时器),默认值5-10秒 - gNB设置定时器TNGAP_initialContextSetup(等待RRC Reconfiguration Complete),默认值10秒
gNB收到Security Context后,需要从UE Security Capabilities和gNB自身支持的算法集合中选择优先级最高的算法。
算法选择博弈矩阵:
| gNB支持的算法 | UE支持的算法 | 选择结果 | 安全等级 |
|---|---|---|---|
| 5G-IA2 (128-SNOW 3G) 优先 | 5G-IA1 (128-AES) 优先 | 取两者交集中的gNB最高优先级 → 5G-IA2 | 中等 |
| 仅5G-IA0 (NULL) | 5G-IA1/IA2/IA3 | 5G-IA0 | 无完整性保护,运营商合规风险 |
| 5G-IA3 (128-ZUC) 优先 | 5G-IA3支持 | 5G-IA3 | 国密标准 |
关键约束(TS 33.501 Section 5.4.1): - 5G网络强制要求信令完整性保护(包括RRC信令和NAS信令) - 如果gNB和UE没有共同的完整性保护算法,Initial Context Setup必须失败 - 加密(Encryption)可以选NULL算法,但完整性保护不可为NULL(这是与4G的重大区别)
这是整个过程中最复杂的博弈环节。gNB需要将AMF转发的QoS Flow List映射到DRB(Data Radio Bearer)上。
gNB的QoS Flow → DRB映射策略(TS 38.300 Section 7.3.2):
graph TD
subgraph "QoS Flows (来自SMF)"
QF1["QFI=1: VoNR<br/>5QI=1, GBR, ARP=1"]
QF2["QFI=2: Video<br/>5QI=2, GBR, ARP=3"]
QF3["QFI=5: IMS Sig<br/>5QI=5, Non-GBR, ARP=1"]
QF4["QFI=9: Internet<br/>5QI=9, Non-GBR, ARP=9"]
end
subgraph "gNB映射决策"
M1["策略1: 1:1映射<br/>每个QFI一个DRB"]
M2["策略2: 相似QoS合并<br/>相同5QI优先级的QFI共享DRB"]
M3["策略3: GBR/Non-GBR分离<br/>GBR QFI独占DRB"]
end
subgraph "DRB结果"
DRB1["DRB1: QFI=1<br/>专享,低时延调度"]
DRB2["DRB2: QFI=2<br/>GBR保障"]
DRB3["DRB3: QFI=5+9<br/>Non-GBR共享"]
end
QF1 --> M3
QF2 --> M3
QF3 --> M3
QF4 --> M3
M3 --> DRB1
M3 --> DRB2
M3 --> DRB3
style QF1 fill:#ffcccc
style QF2 fill:#ffddcc
style QF3 fill:#ccffcc
style QF4 fill:#ccccff
运营商博弈点: - 1:1映射:控制最精确,但DRB数量增加,UE功耗上升。华为设备倾向此策略 - 合并映射:节省空口资源,但GBR和Non-GBR混用DRB可能导致相互影响。中兴设备倾向此策略 - 影响:DRB数量直接影响PDCP实体数量,每个PDCP实体需要独立的加密/完整性保护上下文
gNB在Response中为每个PDU Session创建AN Tunnel Info(接入侧隧道信息),这是UPF下行数据通道的端点。
AN Tunnel Info结构(TS 38.413 Section 9.3.2.4):
PDUSessionResourceSetupResponseTransfer ::= SEQUENCE {
dLQosFlowPerTNLInformation QosFlowPerTNLInformation,
dLNGUPTNLInformation UPTransportLayerInformation, -- gNB的DL TEID + IP
...
}
| 字段 | 说明 | 博弈影响 |
|---|---|---|
| gNB TEID (DL) | gNB为下行数据分配的GTP-U隧道端点 | gNB可能将同一PDU Session的不同QoS Flow映射到不同传输层隧道 |
| gNB IP Address | gNB的N3接口IP | 多IP场景下,gNB可选择最佳UPF路由路径 |
| QosFlowPerTNLInformation | 每个TNL上的QoS Flow映射 | gNB可将GBR QoS Flow分配到专用TNL,实现传输层隔离 |
当gNB无法完成上下文建立时,返回Initial Context Setup Failure,包含Cause IE。
常见失败原因分析:
| Cause值 | 含义 | 典型触发条件 | 排错思路 |
|---|---|---|---|
| Radio Network: Unknown (26) | 无线原因 | UE已失联或RRC连接断开 | 检查UE RRC状态、无线覆盖 |
| Radio Network: Failure in Radio Interface Procedure (14) | 空口过程失败 | AS SMC失败或RRC Reconfig超时 | 抓包检查AS SMC消息是否正常交互 |
| Transport: Transport Resource Unavailable (1) | 传输资源不足 | N3接口GTP-U隧道无法建立 | 检查gNB到UPF的传输网连通性 |
| Protocol: Transfer Syntax Error (44) | 协议语法错误 | NGAP消息编解码异常 | 检查AMF和gNB的NGAP版本兼容性 |
| Misc: Not specified (44) | 未分类 | 各种边缘case | 需结合具体日志分析 |
Initial Context Setup涉及多条定时器的级联等待:
graph LR
T1["AMF: T3524<br/>等待Initial Context<br/>Setup Response<br/>5-10s"] -->|"超时"| F1["AMF认为gNB失败<br/>触发UE Release"]
T2["gNB: T_RRC<br/>等待RRC Reconfig<br/>Complete<br/>10s"] -->|"超时"| F2["gNB向AMF返回<br/>Failure Cause"]
T3["UE: T300<br/>等待RRC Setup<br/>Response<br/>400ms-2s"] -->|"超时"| F3["UE触发RRC<br/>连接重建"]
T4["gNB: T_Algorithm<br/>安全算法协商<br/>隐含在T_RRC内"] -->|"算法不匹配"| F4["直接返回<br/>Security Failure"]
T1 -->|"包含"| T2
T2 -->|"包含"| T4
style F1 fill:#ffaaaa
style F2 fill:#ffaaaa
style F3 fill:#ffaaaa
style F4 fill:#ffaaaa
定时器博弈分析: - AMF的T3524必须大于gNB的T_RRC + UE处理时间,否则会误判gNB超时 - 实际部署中,T3524默认10秒,而整个RRC Reconfig过程通常在1-3秒内完成 - 关键风险:当UE处于小区边缘,RRC Reconfig需要多次HARQ重传时,可能接近T3524上限
在N2接口(SCTP端口38412)上识别Initial Context Setup:
# Wireshark过滤NGAP Initial Context Setup
ngap.procedureCode == 15
# 过滤Initial Context Setup Request (Initiating Message)
ngap.procedureCode == 15 && ngap.messageType == 1
# 过滤Initial Context Setup Response (Successful Outcome)
ngap.procedureCode == 15 && ngap.messageType == 2
# 过配Initial Context Setup Failure (Unsuccessful Outcome)
ngap.procedureCode == 15 && ngap.messageType == 3
场景1:Initial Context Setup失败 — AS SMC失败
症状:gNB返回Initial Context Setup Failure,Cause = "Failure in Radio Interface Procedure"
分析路径:
1. 检查AMF发送的SecurityKey是否正确(256 bits,非全零)
2. 检查gNB选择的5G-IA算法是否在UE Security Capabilities范围内
3. 检查UE是否正确计算了AS层密钥(K_RRC_int)
4. 检查AS Security Mode Complete中的MAC-I是否验证通过
场景2:PDU Session Resource建立失败
症状:Initial Context Setup Response中,部分PDU Session在Failed List
分析路径:
1. 检查N2 SM Information中的UL UP Transport Info(TEID是否有效)
2. 检查gNB到UPF的N3传输路由是否可达
3. 检查QoS Flow的5QI参数是否在gNB支持的范围内
4. 检查Session-AMBR是否与UE签约数据一致
| 维度 | 4G S1AP | 5G NGAP | 演进原因 |
|---|---|---|---|
| 安全密钥 | KeNB (256 bits) | KgNB (256 bits) + NH Chain | 5G支持前向安全增强 |
| 承载模型 | EPS Bearer (1:1映射) | QoS Flow → DRB (N:1映射) | 5G QoS框架更灵活 |
| 切片信息 | 无 | S-NSSAI per PDU Session | 5G原生支持网络切片 |
| 完整性保护 | 可选 | RRC信令强制 | 5G安全等级提升 |
| Non-GBR控制 | UE-AMBR (全UE聚合) | UE-AMBR + Session-AMBR | 5G支持Session级速率控制 |
| NAS容器 | Attach Accept透传 | PDU Session Establishment Accept透传 | NAS消息类型变化 |
Q1: Initial Context Setup和PDU Session Resource Setup可以分开吗? A: 可以。AMF可以选择在Initial Context Setup Request中不携带PDU Session Resource,先完成安全上下文注入,然后通过独立的PDU Session Resource Setup过程建立无线资源。这在Service Request场景中常见——先恢复UE上下文,再逐一建立PDU Session资源。但如果是初始Registration,通常合并在一个Initial Context Setup中完成。
Q2: gNB收到多个PDU Session的Resource Setup时,是串行还是并行处理? A: 规范未强制要求顺序。gNB可以并行处理多个PDU Session的资源配置。实践中,同一S-NSSAI的PDU Session通常并行处理,不同S-NSSAI的可能需要串行(因为涉及不同的切片资源池配置)。爱立信实现为完全并行,华为实现为同切片并行、跨切片串行。
Q3: AS Security Mode失败会导致Initial Context Setup失败吗? A: 一定会。AS Security Mode是Initial Context Setup的必经阶段(Phase 2)。如果UE无法验证AS Security Mode Command(比如算法不匹配、密钥错误),UE会发送Security Mode Failure,gNB随后向AMF返回Initial Context Setup Failure,Cause为"Failure in Radio Interface Procedure"。这也是5G与4G的关键区别——5G不允许跳过AS安全激活。
Q4: 为什么5G强制要求AS完整性保护而4G不强制? A: 因为4G时代出现了IMSI Catcher(伪基站)攻击。伪基站通过强制使用NULL完整性保护算法,可以窃听和篡改RRC信令。5G引入了强制完整性保护机制(TS 33.501 Section 5.4.1),即使选择不加密(5G-EA0),RRC信令和NAS信令也必须有完整性保护(5G-IAx, x≠0)。这显著提高了伪基站攻击的门槛。
Q5: NextHopChainingCount为0和为其他值有什么区别? A: NHCC=0表示AMF首次为该UE推衍KgNB,此时使用KAMF直接推衍。NHCC>0表示发生了gNB间切换或KgNB横向推衍,此时使用前一个KgNB通过KDF推衍下一个KgNB(TS 33.501 Section 6.9.2.2)。这个机制确保了即使KAMF不变,gNB间的密钥也是不同的,提供了前向安全保证——一个gNB被攻破不会影响其他gNB的密钥安全。
本文由「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 等场景全覆盖。
