# 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："我这边需要建上下文"。具体触发场景有： | 触发场景 | 说明 | |---|---| | **注册流程（带 UE Context Request）** | Initial UE Message 中 UE Context Request = "required"，AMF 鉴权通过后必发 ICS Request | | **注册流程（不带指示）** | 即使 gNB 没置位，只要 AMF 已获得 SUPI 且决定接受注册，AMF 也会主动触发 | | **首个 PDU 会话建立** | UE 发起 PDU Session Establishment，SMF 通过 N1N2MessageTransfer 把资源建立请求交给 AMF，AMF 用 ICS Request 的 PDU Session Resource Setup List 一并下发（合并流程） | | **业务请求（带数据）** | UE 处于 CM-IDLE 时发起 Service Request，若 gNB 侧尚无上下文（如换 gNB 后重连），AMF 触发 ICS | 值得注意的是第三种"合并流程"——这是 5G 为降低首业务时延的关键优化。AMF 完全可以先发 ICS 建立上下文，等响应回来再单独发一条 PDU Session Resource Setup；但标准允许（且厂商普遍实现）把 PDU 会话资源建立请求**塞进 ICS Request 的 `PDUSessionResourceSetupListCxtReq`**，gNB 一次性把 RRC DRB、N3 隧道都建好，少一个 N2 往返。 --- ## 三、完整信令时序 下面这张时序图刻画了一次"注册 + 合并 PDU 会话建立"的典型组合，也是抓包中最常见的形态： ```mermaid sequenceDiagram participant UE participant gNB as NG-RAN (gNB) participant AMF participant SMF participant UPF UE->>gNB: RRC SetupRequest / RRCSetupComplete
(NAS: Registration Request) gNB->>AMF: NGAP Initial UE Message
(RAN UE NGAP ID, NAS PDU,
UE Context Request = required) Note over AMF: 5G AKA 鉴权
向 UDM 取签约、向 PCF 取策略
选择切片、分配 AMF UE NGAP ID AMF->>gNB: NGAP Initial Context Setup Request
(SecurityKey, UE Security Capabilities,
UE-AMBR, Allowed NSSAI,
Mobility Restriction List,
Subscriber Profile ID for RFSP,
UE Radio Capability,
PDUSessionResourceSetupListCxtReq) Note over gNB: 由 SecurityKey 派生 KgNB
选定 AS 加密/完整性算法
构建 UE context gNB->>UE: RRC SecurityModeCommand
(selected algorithms) UE->>gNB: RRC SecurityModeComplete Note over gNB: 启用 SRB1/2 加密与完整性保护 gNB->>UE: RRC Reconfiguration
(建立 DRB, 承载 NAS Registration Accept) UE->>gNB: RRC ReconfigurationComplete gNB->>SMF: (经AMF) N2 SM 信息已就绪 SMF->>UPF: N4 Session Establishment/Modification
(N3 F-TEID 对端地址) gNB->>AMF: NGAP Initial Context Setup Response
(每 PDU Session 的 N3 TNL:
gNB N3 IP + TEID,
PDUSessionResourceSetupListCxtRsp) Note over UPF,gNB: N3 GTP-U 隧道打通
上下行用户面就绪 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，条件出现）三类，条件出现是理解整条流程灵活性的关键。 ```mermaid graph TD A["InitialContextSetupRequest
AMF → NG-RAN"] --> M1["AMF UE NGAP ID (M)"] A --> M2["RAN UE NGAP ID (M)"] A --> M3["GUAMI (M)
定位 AMF 实例"] A --> S1["SecurityKey (M, 256bit)
派生 KgNB 的根"] A --> S2["UE Security Capabilities (M)
NR/EUTRA 算法位图"] A --> S3["SecurityAlgorithm / Index…"] A --> AM["UE Aggregate Maximum Bit Rate (C)
非 GBR 流聚合速率上限"] A --> NS["Allowed NSSAI (C)
本 PLMN 允许切片"] A --> MOB["Mobility Restriction List (C)
Serving/Equiv PLMN, 禁区"] A --> RFSP["Subscriber Profile ID for RFSP (O)
频点/选网优先级索引"] A --> RC["UE Radio Capability (O)
AMF 缓存的无线能力 blob"] A --> RCP["UE Radio Capability for Paging (O)"] A --> PS["PDUSessionResourceSetupListCxtReq (C)
合并建立的用户面资源"] A --> LOC["Location Reporting Request (O)
请求上报 UE 位置"] A --> CI["Core Network Assistance Info (O)
RRC Inactive 辅助参数"] A --> TR["Trace Activation (O)"] A --> IMEI["Masked IMEISV (O)"] ``` 下表对最关键的 IE 做参数级说明： | IE 名称 | Presence | 长度/取值 | 作用与设计意图 | |---|---|---|---| | **SecurityKey** | M | 256 bit 比特串 | gNB 用它派生 KgNB 及全部 AS 密钥；每次新建上下文都会换新值（前向安全） | | **UE Security Capabilities** | M | 算法位图 | UE 支持的 NR/E-UTRA 完整性与加密算法列表，gNB 据此选定 AS 算法 | | **UE Aggregate Maximum Bit Rate** | C | UL/DL 速率 | 跨所有 non-GBR QoS flow 的聚合上限，gNB 调度器据此限速 | | **Allowed NSSAI** | C | S-NSSAI 列表 | 本接入允许的切片，gNB 据此区分用户面与 QoS 处理 | | **Mobility Restriction List** | C | PLMN/TA 列表 | 服务 PLMN、等效 PLMN、禁止 TA/PLMN，用于后续切换判决 | | **Subscriber Profile ID for RFSP** | O | 整数索引 | 指向 OAM 的频点优先级表，影响空闲态小区重选权重 | | **UE Radio Capability** | O | 不透明容器 | UE 的 5G 无线能力，AMF 缓存复用，避免空口重复上报 | | **PDUSessionResourceSetupListCxtReq** | C | 列表 | 合并建立用户面：每个条目含 PDU Session ID + 透明传输容器 | 这里要重点解释两个"容易被忽略但极关键"的 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 在承载内容上的差异： | 维度 | ICS Request 携带的资源建立 | 独立 PDU Session Resource Setup | |---|---|---| | 触发 | UE 进入连接态且 AMF 持有待建会话 | 已连接 UE 新建/修改会话 | | 是否含安全上下文 | 是（SecurityKey 等） | 否 | | 容器 | PDUSessionResourceSetupListCxtReq | PDUSessionResourceSetupListSUReq | | 目的 | 上下文 + 用户面一步到位 | 仅增量建立/调整用户面 | gNB 对容器内每个 QoS flow 的处理：解析 5QI → 映射到 DRB（多个 flow 可复用一个 DRB）→ 在空口用 RRC Reconfiguration 配 DRB → 在 N3 用 GTP-U 隧道串接 UPF。 --- ## 六、响应与失败路径 gNB 完成 UE context 构建和资源准备后，回 **InitialContextSetupResponse**： | IE 名称 | Presence | 说明 | |---|---|---| | AMF UE NGAP ID | M | 关联请求 | | RAN UE NGAP ID | M | 关联请求 | | **PDUSessionResourceSetupListCxtRsp** | C | 每个 PDU Session 的 gNB N3 地址（IP + TEID），供 UPF 发上行包 | | **PDUSessionResourceFailedToSetupListCxtFail** | C | 建立失败的会话及 Cause，逐会话上报 | | CriticalityDiagnostics | O | 协议解码诊断 | **关键设计：部分成功机制。** Initial Context Setup 本身要么成功要么失败，但**它内嵌的 PDU 会话资源建立支持逐会话的成功/失败**。也就是说，UE 上下文可以成功建立，而其中的 1 个 PDU 会话资源建立失败——gNB 在 Response 里用两个列表分别回报成功与失败的会话，AMF/SMF 据此对失败的会话单独走释放或重试，不影响整体上下文。这是工程上避免"一颗老鼠屎坏一锅汤"的精细处理。 失败时 gNB 回 **InitialContextSetupFailure**，核心是 **Cause**（必含）： ```mermaid flowchart LR F["InitialContextSetupFailure"] --> C["Cause (M)"] C --> C1["radioNetwork:
setup-unsuccessful,
radio-connection-with-UE-lost"] C --> C2["transport:
tnl-failed /
up layer缺 N3 资源"] C --> C3["protocol:
IE 缺失/不一致"] C --> C4["misc / nas"] F --> D["CriticalityDiagnostics (O)"] F -. 失败后 .-> R["gNB 清理已建资源
AMF 视 Cause 决定:
重试 / 释放 / 降级"] ``` --- ## 七、状态机视角：gNB 侧 UE context 生命周期 从 NGAP 角度看，UE 关联逻辑 NG 连接（UE-associated logical NG-connection）经历如下状态： ```mermaid stateDiagram-v2 [*] --> NoContext: Initial UE Message
(RAN UE NGAP ID 分配) NoContext --> ContextExists: InitialContextSetupRequest 接收 ContextExists --> Established: InitialContextSetupResponse/Complete Established --> Established: UE Context Modification
(增量更新) Established --> Suspended: UE Context Suspend
(转 RRC_INACTIVE) Suspended --> Established: UE Context Resume Established --> Released: UE Context Release Suspended --> Released: UE Context Release ContextExists --> NoContext: InitialContextSetupFailure
(清理) 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 的初始上下文建立请求与响应"即可联动过滤。 ### 常见故障点与排错思路 | 故障现象 | 可能根因 | 排查方向 | |---|---|---| | 收到 ICS Failure，Cause = `transport` | gNB 到 UPF 的 N3 隧道建不起来（路由/防火墙/F-TEID 配置错） | 检查 gNB N3 IP 可达性、GTP-U 端口 2152、UPF 侧 N4 会话是否已下发 N3 TEID | | Cause = `radio-connection-with-UE-lost` | UE 在 AS 安全激活前掉线（弱覆盖、终端 bug） | 查 RRC SetupComplete 后是否有 SecurityModeCommand，若无则 UE 早已失联 | | AS Security Mode Command 失败 | SecurityKey 与 UE 侧 KAMF 不一致，或算法位图匹配不上 | 对比 ICS Request 的 securityKey 与 UE 鉴权完成的 KAMF；核查 UE 与 gNB 支持的算法交集是否为空 | | PDU 会话建不起来但上下文 OK | ICS Response 里出现 PDUSessionResourceFailedToSetupListCxtFail | 单独排查该会话的 5QI 配置、QoS flow 到 DRB 映射、N3 资源 | | 业务通但速率被卡死 | UE-AMBR 下发值过小或 gNB 未生效 | 查 ICS Request 的 uEAggregateMaximumBitRate，比对 SMF 下发的 Session-AMBR | ## 九、设计哲学小结 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)](https://www.etsi.org/deliver/etsi_ts/138400_138499/138413/18.06.00_60/ts_138413v180600p.pdf) — §8.4.1 Initial Context Setup, §9.2 Information Element definitions 2. [3GPP Specification # 38.413 — Portal 详情页](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3223) — 规范版本与变更追踪 3. [ShareTechnote — 5G/NR Network NGAP/N2 Interface](https://www.sharetechnote.com/html/5G/5G_NGAP.html) — UE Context Request 与 ICS 触发关系图解 4. [3glteinfo — 5G Initial Context Setup Request/Response NGAP Message](https://www.3glteinfo.com/messages/5g/ngap/initial-context-setup-request/) — IE 字段与 call flow 详解 5. [free5GC — NGAP Introduction（2025-10-15）](https://free5gc.org/blog/20251015/20251015/) — 开源核心网实现视角的 ICS 触发与 gNB context 构建 6. [Techplayon — 5G NR SA Registration Call Flow](https://www.techplayon.com/5g-nr-sa-registration-attach-call-flow/) — AMF UE NGAP ID 分配与注册全流程 7. [3GPP TS 33.501](https://www.3gpp.org/dynareport?spec=33501.htm) — §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 等场景全覆盖。