首页 › core-network › NGAP初始上下文建立三阶段信令与资源注入博弈

NGAP Initial Context Setup三阶段信令与安全上下文注入深度解析

一、机制概述:为什么Initial Context Setup是5G最关键的NGAP过程

NGAP Initial Context Setup(初始上下文建立)是AMF通过N2接口向gNB注入UE完整上下文的唯一原子操作。它在一个过程中同时完成三件关键事项:安全上下文下推、PDU会话无线资源建立、UE能力信息确认。这个过程承载了5G网络从"知道UE存在"到"UE可以通信"的核心状态跃迁。

与4G S1AP的Initial Context Setup相比,5G NGAP版本在以下方面发生了根本变化:

  1. 安全算法集扩展:新增5G-IA5/5G-EA5(基于SNOW 3G)、5G-IA4/5G-EA4(基于AES-CTR),支持更灵活的安全算法协商
  2. PDU Session级资源管理:取代EPS的EPS Bearer概念,每个PDU Session包含多个QoS Flow,资源颗粒度更细
  3. Network Slicing感知:通过NSSAI IE携带切片信息,gNB需要按切片隔离资源

1.1 触发场景分析

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 --> [*]: 上下文建立失败

二、信令时序图:完整Initial Context Setup流程

以下时序图展示了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

三、关键IE结构深度解析

3.1 Security Context IE(安全上下文信息元素)

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能力

3.2 UE Aggregate Maximum Bit Rate IE

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属性

3.3 PDU Session Resource Setup IE

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、gNB与UE的资源分配三角关系

4.1 Phase 1:安全上下文下推——AMF的"一次写入"策略

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秒

4.2 Phase 2:AS安全激活——gNB的算法选择权

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的重大区别)

4.3 Phase 3:PDU会话资源建立——gNB的QoS Flow到DRB映射决策

这是整个过程中最复杂的博弈环节。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实体需要独立的加密/完整性保护上下文

4.4 Initial Context Setup Response中的AN Tunnel Info

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,实现传输层隔离

五、失败场景与定时器博弈

5.1 Initial Context Setup Failure

当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 需结合具体日志分析

5.2 定时器链式博弈

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

六、抓包识别与实战排错

6.1 抓包特征

在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

6.2 关键排错场景

场景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 Initial Context Setup对比

维度 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的密钥安全。

参考来源

  1. 3GPP TS 38.413 V19.x.x — NG-RAN: NG Application Protocol (NGAP) — Section 8.3.1 Initial Context Setup, Section 9.3 IE定义
  2. 3GPP TS 33.501 V19.x.x — Security Architecture and Procedures for 5G System — Section 6.9.2 Key Derivation, Section 6.7.1 Security Context Management
  3. 3GPP TS 23.502 V19.x.x — Procedures for the 5G System — Section 4.2.2 Registration, Section 4.2.3 Service Request
  4. ShareTechnote — NGAP Initial Context Setup — NGAP信令流程详解及IE解析
  5. 3GPP TS 38.300 V19.x.x — NR Overall Description — Section 7.3.2 QoS Flow to DRB Mapping

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