NGAP初始上下文建立信令全链拆解

聚焦 3GPP TS 38.413 Section 8.4.1，从 InitialContextSetupRequest 的 IE 编排，到 gNB 派生 KgNB、激活 AS 安全、建立 N3 用户面隧道，再到 Failure 回退路径的完整机制解析。

在 5G SA 网络中，UE 从 RRC_IDLE 进入 RRC_CONNECTED 后，NG-RAN（gNB）侧并不是立刻就能正常调度这个 UE 的——它手里此刻只有一个从空口建立起来的 RRC 连接和一组临时标识，完全没有 UE 的安全上下文、签约限制、切片信息，更没有用户面资源。把这些信息一次性"灌"进 gNB 的那个动作，就是 NGAP 的 Initial Context Setup（初始上下文建立） 流程。它是注册、业务请求、首个 PDU 会话建立背后真正的"地基工程"，几乎所有上行 NAS 信令在 gNB 侧能被正确处理的前提，都是这条流程成功完成。

本文以 TS 38.413 V18.6.0（Release 18）§8.4.1 为主线，逐 IE 拆解请求/响应/失败三条消息，并给出 Mermaid 时序图、IE 结构图、状态机图，最后落到抓包识别与故障排查。

一、为什么需要"初始上下文建立"这一步

很多初学者会疑惑：UE 的上下文不是在 AMF 里就有吗？为什么 gNB 还要单独建一份？

答案在于 5G 的安全架构是分层的。TS 33.501 把密钥层级设计为：

K (USIM) → KSEAF → KAMF (在 AMF) → KgNB (在 gNB) → KRRCint / KRRCenc / KUPint / KUPenc

KAMF 永远不会离开核心网；但要让 gNB 对空口的 RRC 信令和用户面数据做加密与完整性保护，gNB 必须持有一把由 KAMF 派生出来的 KgNB。这把钥匙，连同 UE 的安全能力、签约速率上限、移动性限制、切片权限等，必须由 AMF 主动"推"给 gNB——这个"推送"动作就是 Initial Context Setup。它的核心设计意图有三个：

1. 一锤定音：把安全上下文 + 移动性上下文 + 用户面资源建立合并到一条流程里，减少 UE 进入连接态后的空口往返时延；
2. 密钥不下行：AMF 只下发派生用的 SecurityKey（256 bit，由 KAMF 进一步派生），真正用于空口的 KgNB 在 gNB 内部生成，USIM 主密钥 K 永远不离开卡；
3. 能力缓存：UE 的无线能力（UE Radio Capability）由 AMF 缓存，gNB 建上下文时直接带回，避免每次连接都让 UE 上报一遍这段几 KB 的 blob，省空口资源。

二、触发时机：谁触发、何时触发

Initial Context Setup 永远由 AMF 发起，gNB 没有资格主动要求（这与 4G E-UTRA 的 S1 设计一致）。但 gNB 可以通过 Initial UE Message 里的 UE Context Request 指示位"暗示"AMF："我这边需要建上下文"。具体触发场景有：

值得注意的是第三种"合并流程"——这是 5G 为降低首业务时延的关键优化。AMF 完全可以先发 ICS 建立上下文，等响应回来再单独发一条 PDU Session Resource Setup；但标准允许（且厂商普遍实现）把 PDU 会话资源建立请求塞进 ICS Request 的 PDUSessionResourceSetupListCxtReq，gNB 一次性把 RRC DRB、N3 隧道都建好，少一个 N2 往返。

三、完整信令时序

下面这张时序图刻画了一次"注册 + 合并 PDU 会话建立"的典型组合，也是抓包中最常见的形态：

sequenceDiagram
    participant UE
    participant gNB as NG-RAN (gNB)
    participant AMF
    participant SMF
    participant UPF

    UE->>gNB: RRC SetupRequest / RRCSetupComplete<br/>(NAS: Registration Request)
    gNB->>AMF: NGAP Initial UE Message<br/>(RAN UE NGAP ID, NAS PDU,<br/>UE Context Request = required)
    Note over AMF: 5G AKA 鉴权<br/>向 UDM 取签约、向 PCF 取策略<br/>选择切片、分配 AMF UE NGAP ID
    AMF->>gNB: NGAP Initial Context Setup Request<br/>(SecurityKey, UE Security Capabilities,<br/>UE-AMBR, Allowed NSSAI,<br/>Mobility Restriction List,<br/>Subscriber Profile ID for RFSP,<br/>UE Radio Capability,<br/>PDUSessionResourceSetupListCxtReq)
    Note over gNB: 由 SecurityKey 派生 KgNB<br/>选定 AS 加密/完整性算法<br/>构建 UE context
    gNB->>UE: RRC SecurityModeCommand<br/>(selected algorithms)
    UE->>gNB: RRC SecurityModeComplete
    Note over gNB: 启用 SRB1/2 加密与完整性保护
    gNB->>UE: RRC Reconfiguration<br/>(建立 DRB, 承载 NAS Registration Accept)
    UE->>gNB: RRC ReconfigurationComplete
    gNB->>SMF: (经AMF) N2 SM 信息已就绪
    SMF->>UPF: N4 Session Establishment/Modification<br/>(N3 F-TEID 对端地址)
    gNB->>AMF: NGAP Initial Context Setup Response<br/>(每 PDU Session 的 N3 TNL:<br/>gNB N3 IP + TEID,<br/>PDUSessionResourceSetupListCxtRsp)
    Note over UPF,gNB: N3 GTP-U 隧道打通<br/>上下行用户面就绪
    UE->>AMF: NAS Registration Complete (经 gNB UL NAS Transport)

几个时序上的关键点需要特别说明：

• SecurityKey 必须先于任何受保护 NAS 消息下发。AMF 在 ICS Request 里下发的 SecurityKey 是 256 bit 的中间密钥，gNB 据此派生 KgNB，再派生 KRRCint/KRRCenc/KUPint/KUPenc。只有等 AS Security Mode Command 完成后，Registration Accept 这条 NAS 消息才能安全地通过受保护的 SRB 传递给 UE。
• Registration Accept 的"搭乘"：5G 中 Registration Accept 是一条 NAS 消息，由 AMF 通过 Downlink NAS Transport（NGAP）交给 gNB，gNB 再用 RRC 下发。实践中 AMF 会先把 ICS Request 发出，待 gNB 完成 AS 安全后再投递 Registration Accept，避免明文泄露 SUPI 之外的敏感字段。
• Response 只在 gNB 侧就绪后才回：gNB 要把 N3 的 GTP-U F-TEID（IP + TEID）准备好，才能在 Response 里告诉 AMF/SMF 上行隧道的落点。

四、请求消息 IE 结构深度拆解

InitialContextSetupRequest 的 ASN.1 容器结构（TS 38.413 §9.2）可概括如下。注意 IE 的 Presence（出现性） 分为 Mandatory（M，必含）、Optional（O，可选）、Conditional（C，条件出现）三类，条件出现是理解整条流程灵活性的关键。

graph TD
    A["InitialContextSetupRequest<br/>AMF → NG-RAN"] --> M1["AMF UE NGAP ID (M)"]
    A --> M2["RAN UE NGAP ID (M)"]
    A --> M3["GUAMI (M) <br/>定位 AMF 实例"]
    A --> S1["SecurityKey (M, 256bit)<br/>派生 KgNB 的根"]
    A --> S2["UE Security Capabilities (M)<br/>NR/EUTRA 算法位图"]
    A --> S3["SecurityAlgorithm / Index…"]
    A --> AM["UE Aggregate Maximum Bit Rate (C)<br/>非 GBR 流聚合速率上限"]
    A --> NS["Allowed NSSAI (C)<br/>本 PLMN 允许切片"]
    A --> MOB["Mobility Restriction List (C)<br/>Serving/Equiv PLMN, 禁区"]
    A --> RFSP["Subscriber Profile ID for RFSP (O)<br/>频点/选网优先级索引"]
    A --> RC["UE Radio Capability (O)<br/>AMF 缓存的无线能力 blob"]
    A --> RCP["UE Radio Capability for Paging (O)"]
    A --> PS["PDUSessionResourceSetupListCxtReq (C)<br/>合并建立的用户面资源"]
    A --> LOC["Location Reporting Request (O)<br/>请求上报 UE 位置"]
    A --> CI["Core Network Assistance Info (O)<br/>RRC Inactive 辅助参数"]
    A --> TR["Trace Activation (O)"]
    A --> IMEI["Masked IMEISV (O)"]

下表对最关键的 IE 做参数级说明：

这里要重点解释两个"容易被忽略但极关键"的 IE：

1. SecurityKey 与前向安全。 每次 AMF 发起 Initial Context Setup（包括 UE 重选到新 gNB 后的重建上下文），都会基于当前 KAMF 以及上行/下行 NAS COUNT 重新计算并下发一个新的 SecurityKey。这意味着即便旧 gNB 的密钥被攻破，也无法解密新 gNB 上的流量——这就是 5G 相对 4G 强化的"空口前向安全"。

2. UE Radio Capability 缓存。 4G 时代 UE 每次建立连接都要把几 KB 的 UE-EUTRA-Capability 通过空口上报，严重浪费无线资源。5G 改由 AMF 缓存（在首次注册时通过 UE Capability Enquiry 取得），后续 gNB 通过 ICS Request 的 UE Radio Capability 直接带回。抓包时你会看到：第一次注册有空口的 UE Capability Information 上行，之后重连就只有 NGAP 的下行 blob，这是判别"是否首次注册"的快速特征。

五、PDU Session Resource 的"嵌套容器"机制

PDUSessionResourceSetupListCxtReq 是 Initial Context Setup 中最复杂的部分。它采用了 5G N2 接口一个普遍的设计——透明容器（Transparent Container / IE Transfer）：

• AMF 并不理解 PDU 会话资源建立请求的内部细节（那是 SMF 的领域）；
• SMF 把 NG-RAN 需要的信息（QoS flow 列表、各 flow 的 5QI/GBR 参数、上行 N3 TEID、会话 AMBR 等）打包成 PDUSessionResourceSetupRequestTransfer；
• AMF 把这个容器原封不动塞进 ICS Request 转发给 gNB，gNB 解开后建 DRB、配 N3。

这种设计的好处是 N2 接口关注点分离：AMF 只管 UE 的接入与移动，SMF 只管会话与 QoS，二者通过 AMF 做"邮差"。下表对比 ICS Request 与独立 PDU Session Resource Setup 在承载内容上的差异：

gNB 对容器内每个 QoS flow 的处理：解析 5QI → 映射到 DRB（多个 flow 可复用一个 DRB）→ 在空口用 RRC Reconfiguration 配 DRB → 在 N3 用 GTP-U 隧道串接 UPF。

六、响应与失败路径

gNB 完成 UE context 构建和资源准备后，回 InitialContextSetupResponse：

关键设计：部分成功机制。 Initial Context Setup 本身要么成功要么失败，但它内嵌的 PDU 会话资源建立支持逐会话的成功/失败。也就是说，UE 上下文可以成功建立，而其中的 1 个 PDU 会话资源建立失败——gNB 在 Response 里用两个列表分别回报成功与失败的会话，AMF/SMF 据此对失败的会话单独走释放或重试，不影响整体上下文。这是工程上避免"一颗老鼠屎坏一锅汤"的精细处理。

失败时 gNB 回 InitialContextSetupFailure，核心是 Cause（必含）：

flowchart LR
    F["InitialContextSetupFailure"] --> C["Cause (M)"]
    C --> C1["radioNetwork:<br/>setup-unsuccessful,<br/>radio-connection-with-UE-lost"]
    C --> C2["transport:<br/>tnl-failed /<br/>up layer缺 N3 资源"]
    C --> C3["protocol:<br/>IE 缺失/不一致"]
    C --> C4["misc / nas"]
    F --> D["CriticalityDiagnostics (O)"]
    F -. 失败后 .-> R["gNB 清理已建资源<br/>AMF 视 Cause 决定:<br/>重试 / 释放 / 降级"]

七、状态机视角：gNB 侧 UE context 生命周期

从 NGAP 角度看，UE 关联逻辑 NG 连接（UE-associated logical NG-connection）经历如下状态：

stateDiagram-v2
    [*] --> NoContext: Initial UE Message<br/>(RAN UE NGAP ID 分配)
    NoContext --> ContextExists: InitialContextSetupRequest 接收
    ContextExists --> Established: InitialContextSetupResponse/Complete
    Established --> Established: UE Context Modification<br/>(增量更新)
    Established --> Suspended: UE Context Suspend<br/>(转 RRC_INACTIVE)
    Suspended --> Established: UE Context Resume
    Established --> Released: UE Context Release
    Suspended --> Released: UE Context Release
    ContextExists --> NoContext: InitialContextSetupFailure<br/>(清理)
    Released --> [*]

Initial Context Setup 完成后，UE 在 gNB 侧进入"已建上下文"状态，此后 AMF 若要修改（如更新 UE-AMBR、切换 PDU 会话、更新切片），用的是 UE Context Modification（§8.4.3）而非重新建；要把 UE 推入 RRC_INACTIVE 省电，用 UE Context Suspend（§8.10），唤醒用 UE Context Resume。可以说 ICS 是这条状态机的"出生证"。

八、抓包识别与实战排错

如何在 Wireshark/TShark 中识别这条流程

1. 过滤 N2 信令：sctp.port == 38412（NGAP 承载在 SCTP，端口 38412），再 ngap 展开。
2. 定位请求：ngap.procedureCode == 14（InitialContextSetup 的 Procedure Code 在 TS 38.413 §9.x 定义为 14）。下行方向 AMF→gNB。
3. 核对三要素：展开 InitiatingMessage → value → InitialContextSetupRequest，确认含 securityKey、uESecurityCapabilities、uEAggregateMaximumBitRate。
4. 看响应：同 UE（AMF UE NGAP ID 相同）随后应有 InitialContextSetupResponse，展开 PDUSessionResourceSetupResponse 看 gNB 的 N3 F-TEID。
5. 用 pcap-analyzer 风格的快速查询（若已部署 TShark 后端）：自然语言"显示某 UE 的初始上下文建立请求与响应"即可联动过滤。

常见故障点与排错思路

Initial Context Setup 表面上是一条"AMF 给 gNB 送配置"的消息，但它凝聚了 5G 三大架构决策：

1. 分层安全——密钥逐级派生、KgNB 不出 gNB，实现细粒度前向安全；
2. 关注点分离——AMF/SMF/gNB 各司其职，通过透明容器解耦，N2 接口可独立演进；
3. 时延优化——上下文与用户面合并建立、UE 能力缓存复用，把 UE 从 IDLE 到首业务的路程压到最短。

理解了这条流程，5G 接入侧绝大多数信令异常都能顺藤摸瓜定位到根因。

常见问题

Q1: Initial Context Setup 和 UE Context Modification 有什么区别？ A: ICS 是"从无到有"建立完整 UE 上下文（含安全密钥、首次激活 AS 安全），一个 UE 生命周期里只在每次进入连接态且 gNB 无上下文时发生；UE Context Modification 是在已有上下文基础上"增量更新"（改 UE-AMBR、增删 PDU 会话、更新切片），不涉及密钥重派生。

Q2: 为什么有时抓不到 Initial Context Setup Request，却能正常上网？ A: 若 UE 已在该 gNB 建过上下文（如 CM-CONNECTED 内的连续业务），无需重建；或该 gNB 仍持有 RRC_INACTIVE 挂起的上下文，UE 重连走的是 UE Context Resume 而非 ICS。另外 ICS 是 AMF 单发流程，gNB 无对应请求消息，初次看包容易漏掉 AMF→gNB 这条下行消息。

Q3: SecurityKey 和 KgNB 是一回事吗？ A: 不是。SecurityKey 是 AMF 基于 KAMF 下发给 gNB 的 256 bit 中间密钥；gNB 收到后才在内部派生出 KgNB，再派生空口的 KRRCint/KRRCenc/KUPint/KUPenc。也就是说真正用于加密用户面数据的是 KUPenc，离 SecurityKey 还有两步派生。

Q4: PDU 会话资源建立失败会导致整个注册失败吗？ A: 不会。ICS 支持逐会话的部分成功：UE 上下文与安全可以成功建立，而其中某个 PDU 会话资源失败时，gNB 在 Response 里用 PDUSessionResourceFailedToSetupListCxtFail 单独上报，AMF/SMF 只对该会话做处理，注册流程照常完成。

Q5: NSA（非独立组网）里有这条流程吗？ A: NSA 下 UE 先经 LTE 锚点接入，5G 侧通过 E-UTRA-NR 双连接（EN-DC）的 SgNB Addition 流程增加 5G 腔，走的是 X2/Xn 的 SgNBAddition 而非 NGAP ICS。NGAP 的 Initial Context Setup 是 SA（独立组网）特有的 N2 流程。

参考来源

1. 3GPP TS 38.413 V18.6.0 — NG-RAN; NG Application Protocol (NGAP) — §8.4.1 Initial Context Setup, §9.2 Information Element definitions
2. 3GPP Specification # 38.413 — Portal 详情页 — 规范版本与变更追踪
3. ShareTechnote — 5G/NR Network NGAP/N2 Interface — UE Context Request 与 ICS 触发关系图解
4. 3glteinfo — 5G Initial Context Setup Request/Response NGAP Message — IE 字段与 call flow 详解
5. free5GC — NGAP Introduction（2025-10-15） — 开源核心网实现视角的 ICS 触发与 gNB context 构建
6. Techplayon — 5G NR SA Registration Call Flow — AMF UE NGAP ID 分配与注册全流程
7. 3GPP TS 33.501 — §6 密钥层级（KSEAF/KAMF/KgNB 派生），解释 SecurityKey 的安全语义

本文由「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 等场景全覆盖。