<!-- title: 5G NGAP初始上下文建立信令全链拆解 -->
<!-- domain: protocols -->

# 5G NGAP初始上下文建立（Initial Context Setup）信令全链拆解

## 一、概述：为什么Initial Context Setup是5G信令的"分水岭"

在5G系统中，UE从"NAS层面已认证"到"可以真正承载业务"之间，存在一个关键的状态跃迁——**NGAP Initial Context Setup**。该过程由AMF发起，经N2接口传递至gNB，完成三件事：

1. **在gNB侧创建完整的UE上下文**（UE Context）
2. **激活AS层安全**（Security Mode Command → Complete）
3. **可选地建立初始PDU会话资源**（PDU Session Resource Setup）

从协议定位看，该过程定义于 **3GPP TS 38.413 Section 8.3.1**（Successful Operation）和 **Section 8.3.2**（Unsuccessful Operation），ASN.1消息结构定义于 **Section 9.2.1.1**（InitialContextSetupRequest）和 **Section 9.2.1.2**（InitialContextSetupResponse）。

**设计意图**：在4G EPC中，类似功能由S1AP的"Initial Context Setup Request"承载。5G NGAP继承了这一设计哲学，但增加了切片感知（Allowed NSSAI）和更灵活的安全上下文传递机制。将上下文建立、安全激活和会话资源建立合并为一次交互，显著减少了空口时延。

## 二、完整信令时序图

下图展示了一次成功的Initial Context Setup完整流程，包含AS安全激活和RRC重配两个子过程：

```mermaid
sequenceDiagram
    participant UE
    participant gNB as gNB/NG-RAN
    participant AMF
    participant SMF

    Note over UE,AMF: 前置条件：NAS Registration + Authentication + NAS SMC已完成

    AMF->>gNB: ① NGAP: Initial Context Setup Request<br/>(AMF UE NGAP ID, RAN UE NGAP ID,<br/>GUAMI, Allowed NSSAI,<br/>UE Security Capabilities, Security Key,<br/>PDU Session Resource Setup List,<br/>NAS-PDU: Registration Accept)

    Note over gNB: gNB解析IE，创建UE Context<br/>选择加密/完整性算法

    gNB->>UE: ② RRC: SecurityModeCommand<br/>(selectedAlgorithms)

    UE->>gNB: ③ RRC: SecurityModeComplete

    Note over gNB,UE: AS层安全激活完成

    gNB->>UE: ④ RRC: RRCReconfiguration<br/>(RadioBearerConfig,<br/>MasterCellGroup,<br/>dedicatedNAS-MessageList)

    Note over gNB: 建立DRB/SRB<br/>配置CellGroup

    UE->>gNB: ⑤ RRC: RRCReconfigurationComplete

    gNB->>AMF: ⑥ NGAP: Initial Context Setup Response<br/>(AMF UE NGAP ID, RAN UE NGAP ID,<br/>PDU Session Resource Setup List CxtRes,<br/>Failed-to-Setup List [可选])

    Note over AMF,SMF: 如包含PDU Session资源<br/>AMF通知SMF建立结果

    AMF->>SMF: ⑦ Nsmf_PDUSession_UpdateSMContext<br/>(N2 SM Info: TEID, Transport Info)
```

### 信令步骤逐一解析

**步骤① Initial Context Setup Request（AMF → gNB）**

AMF在完成NAS层认证和安全模式控制后，通过N2接口向gNB发送此消息。这是整个过程的"控制锚点"，携带了gNB创建UE上下文所需的全部信息。消息中可嵌入NAS-PDU（如Registration Accept），通过gNB透传至UE。

**步骤②③ AS安全激活（gNB ↔ UE）**

gNB收到请求后，根据`UESecurityCapabilities`和`SecurityKey`，选择AS层加密/完整性算法，通过RRC SecurityModeCommand下发给UE。UE验证后返回SecurityModeComplete。**这是AS安全的起点**——在步骤②之前，SRB1上的RRC消息是未加密的。

**步骤④⑤ RRC重配（gNB ↔ UE）**

AS安全激活后，gNB通过RRCReconfiguration配置无线承载（DRB/SRB2）和CellGroup参数。如果Initial Context Setup Request中携带了`PDU Session Resource Setup List`，gNB会在此步骤中为相应PDU会话建立DRB。同时，NAS-PDU（Registration Accept）通过`dedicatedNAS-MessageList`捎带下发。

**步骤⑥ Initial Context Setup Response（gNB → AMF）**

gNB确认上下文建立结果。**关键特性**：即使整体成功，Response中仍可包含`Failed-to-Setup List`——即部分PDU会话资源建立失败的条目。这是TS 38.413中"partial success"机制的体现。

## 三、核心IE深度解析

### 3.1 Initial Context Setup Request IE结构图

```mermaid
graph TD
    A[Initial Context Setup Request] --> B[AMF UE NGAP ID<br/>Mandatory / Reject]
    A --> C[RAN UE NGAP ID<br/>Mandatory / Reject]
    A --> D[GUAMI<br/>Mandatory / Reject]
    A --> E[Allowed NSSAI<br/>Mandatory / Reject]
    A --> F[UE Security Capabilities<br/>Mandatory / Reject]
    A --> G[Security Key<br/>Mandatory / Reject]
    A --> H[PDU Session Resource<br/>Setup List CxtReq<br/>Optional / Reject]
    A --> I[NAS-PDU<br/>Optional / Reject]
    A --> J[UE Aggregate<br/>Maximum Bit Rate<br/>Optional / Ignore]
    A --> K[Mobility Restriction List<br/>Optional / Ignore]
    A --> L[Masked IMEISVN<br/>Optional / Ignore]
    A --> M[UESecurityCapabilities<br/>Mandatory / Reject]

    style B fill:#ff6b6b,color:#fff
    style C fill:#ff6b6b,color:#fff
    style D fill:#ff6b6b,color:#fff
    style E fill:#ff6b6b,color:#fff
    style F fill:#ff6b6b,color:#fff
    style G fill:#ff6b6b,color:#fff
    style H fill:#4ecdc4,color:#fff
    style I fill:#4ecdc4,color:#fff
    style J fill:#95e1d3,color:#333
    style K fill:#95e1d3,color:#333
```

红色节点为强制IE（Criticality = Reject），青色为可选但高影响IE，浅色为可选且Ignore的IE。

### 3.2 关键IE参数详解

| IE名称 | 存在性 | Criticality | 说明 |
|--------|--------|-------------|------|
| **AMF UE NGAP ID** | Mandatory | Reject | AMF侧UE标识，用于N2接口唯一标识UE。长度40bit，由AMF分配 |
| **RAN UE NGAP ID** | Mandatory | Reject | gNB侧UE标识，长度32bit，在Initial UE Message中已分配 |
| **GUAMI** | Mandatory | Reject | Globally Unique AMF Identifier，含PLMN ID + AMF Region ID + AMF Set ID + AMF Pointer |
| **Allowed NSSAI** | Mandatory | Reject | 允许的网络切片标识列表，含SST+SD。gNB据此进行切片感知的资源分配 |
| **UESecurityCapabilities** | Mandatory | Reject | UE支持的加密/完整性算法列表（NEA0-NEA3, NIA0-NIA3, NEA4-NEA7 for Rel-18） |
| **SecurityKey** | Mandatory | Reject | 256bit安全密钥（K<sub>gNB</sub>），由AMF从K<sub>AMF</sub>推演生成 |
| **PDU Session Resource Setup List CxtReq** | Optional | Reject | 待建立的PDU会话资源列表，含PDU Session ID + S-NSSAI + Transfer IE |
| **NAS-PDU** | Optional | Reject | 捎带的NAS消息（通常为Registration Accept） |
| **UE Aggregate Maximum Bit Rate** | Optional | Ignore | UE聚合最大比特率，用于gNB调度参考 |
| **Mobility Restriction List** | Optional | Ignore | 移动性限制信息（Forbidden Area, Service Area Restriction） |
| **Masked IMEISVN** | Optional | Ignore | 脱敏后的IMEISVN，用于设备标识 |

### 3.3 SecurityKey推演链路

Security Key IE中的K<sub>gNB</sub>并非凭空产生，它遵循 **TS 33.501 Section 6.9.2** 定义的关键推演链：

```mermaid
graph TD
    A["K (永久密钥)<br/>USIM + UDM"] -->|"AKA/5G AKA"| B["K<sub>SEAF</sub>"]
    B -->|"KDF (TS 33.501 6.1.1.1)"| C["K<sub>AMF</sub>"]
    C -->|"KDF (TS 33.501 6.9.2)"| D["K<sub>gNB</sub>"]
    D -->|"KDF (TS 33.501 6.9.3)"| E["K<sub>RRCenc</sub><br/>K<sub>RRCint</sub><br/>K<sub>UPenc</sub><br/>K<sub>UPint</sub>"]

    style A fill:#2d3436,color:#fff
    style D fill:#ff6b6b,color:#fff
    style E fill:#4ecdc4,color:#fff
```

**关键点**：
- K<sub>gNB</sub>通过 **KDF（Key Derivation Function）** 从K<sub>AMF</sub>推演，输入参数包含**UP Counter**和**Access Type**（3GPP接入）
- gNB收到K<sub>gNB</sub>后，进一步推演出RRC加密密钥、RRC完整性密钥、UP加密密钥和UP完整性密钥
- Rel-18引入了**NEA4-NEA7 / NIA4-NIA7**算法（基于国密算法的候选），扩展了UESecurityCapabilities的比特位

## 四、ASN.1消息结构与解码实例

### 4.1 ASN.1定义（TS 38.413 Section 9.2.1.1）

```asn1
InitialContextSetupRequest ::= SEQUENCE {
    protocolIEs   ProtocolIE-Container {
        {InitialContextSetupRequest-IEs}
    },
    ...
}

InitialContextSetupRequest-IEs NGAP-PROTOCOL-IES ::= {
    { ID id-AMF-UE-NGAP-ID          CRITICALITY reject TYPE AMF-UE-NGAP-ID          PRESENCE mandatory } |
    { ID id-RAN-UE-NGAP-ID          CRITICALITY reject TYPE RAN-UE-NGAP-ID          PRESENCE mandatory } |
    { ID id-GUAMI                   CRITICALITY reject TYPE GUAMI                   PRESENCE mandatory } |
    { ID id-AllowedNSSAI            CRITICALITY reject TYPE AllowedNSSAI            PRESENCE mandatory } |
    { ID id-UESecurityCapabilities  CRITICALITY reject TYPE UESecurityCapabilities  PRESENCE mandatory } |
    { ID id-SecurityKey             CRITICALITY reject TYPE SecurityKey             PRESENCE mandatory } |
    { ID id-PDUSessionResourceSetupListCxtReq
                                    CRITICALITY reject TYPE PDUSessionResourceSetupListCxtReq
                                                                               PRESENCE optional  } |
    { ID id-NAS-PDU                 CRITICALITY reject TYPE NAS-PDU                 PRESENCE optional  } |
    { ID id-UEAggregateMaximumBitRate
                                    CRITICALITY ignore  TYPE UEAggregateMaximumBitRate
                                                                               PRESENCE optional  } |
    { ID id-MobilityRestrictionList CRITICALITY ignore  TYPE MobilityRestrictionList PRESENCE optional  } |
    { ID id-MaskedIMEISVN           CRITICALITY ignore  TYPE MaskedIMEISVN          PRESENCE optional  } |
    ...
}
```

**Criticality语义**：
- **Reject**：如果gNB无法识别该IE，必须拒绝整个消息（返回Failure）
- **Ignore**：如果gNB无法识别该IE，直接忽略，不影响上下文建立

### 4.2 抓包解码实例

以下是一次典型Registration场景中的Initial Context Setup Request解码结果：

```
NGAP-PDU
  initiatingMessage
    procedureCode: id-InitialContextSetup (15)
    criticality: reject
    value: InitialContextSetupRequest
      protocolIEs:
        id-AMF-UE-NGAP-ID: 0x000010A1 (4257)
        id-RAN-UE-NGAP-ID: 0x00000041 (65)
        id-GUAMI:
          pLMNIdentity: 00 F1 10 (MCC: 001, MNC: 01)
          aMFRegionID: 0x02
          aMFSetID: 0x155
          aMFPointer: 0x01
        id-AllowedNSSAI:
          AllowedNSSAI-Item:
            s-NSSAI:
              sST: 01 (eMBB)
              sD: 01 02 03
        id-UESecurityCapabilities:
          nRencryptionAlgorithms: 0xE000 (NEA1, NEA2, NEA3)
          nRintegrityProtectionAlgorithms: 0xE000 (NIA1, NIA2, NIA3)
          eUTROencryptionAlgorithms: 0xE000
          eUTROintegrityProtectionAlgorithms: 0xE000
        id-SecurityKey: 8F 7C A2 3D ... (256 bits / 32 bytes)
        id-PDUSessionResourceSetupListCxtReq:
          PDUSessionResourceSetupItemCxtReq:
            pDUSessionID: 10
            s-NSSAI: SST=01, SD=010203
            pDUSessionResourceSetupRequestTransfer: [Opaque]
        id-NAS-PDU:
          ProtocolDiscriminator: 5GMM (0x7E)
          SecurityHeaderType: 0x02 (Integrity Protected)
          MessageType: Registration Accept (0x42)
```

**解码要点**：
- GUAMI中`aMFSetID: 0x155`表示AMF Set ID=341，AMF Pointer=1
- `nRencryptionAlgorithms: 0xE000`表示bit15-13置1，对应NEA1、NEA2、NEA3
- `SecurityKey`长度固定256bit，是K<sub>gNB</sub>的原始值
- PDU Session Resource的Transfer部分是Opaque（透传），内容遵循**TS 38.413 Section 9.3.2.2**的ASN.1定义

## 五、状态转换图

Initial Context Setup过程涉及UE在gNB侧的状态变迁：

```mermaid
stateDiagram-v2
    [*] --> NG_Not_Exists: UE首次接入<br/>(无NG连接)
    NG_Not_Exists --> NG_Connected: Initial UE Message<br/>(RAN UE NGAP ID分配)

    NG_Connected --> Context_Validating: 收到Initial Context Setup Request
    Context_Validating --> Security_Activating: IE校验通过<br/>算法选择完成
    Context_Activating --> Context_Active: RRCReconfigurationComplete

    Context_Active --> Context_Active: PDU Session Resource<br/>后续建立/修改

    Context_Active --> Context_Releasing: UE Context Release Command
    Context_Releasing --> NG_Not_Exists: 资源释放完成

    Context_Validating --> Context_Failed: IE校验失败/算法不匹配
    Context_Activating --> Context_Failed: AS安全激活失败/RRC重配失败
    Context_Failed --> NG_Not_Exists: Initial Context Setup Failure<br/>或UE Context Release Request
```

**状态说明**：

| 状态 | 含义 | 触发条件 |
|------|------|---------|
| NG_Not_Exists | UE在gNB侧无任何上下文 | UE首次接入或上下文已释放 |
| NG_Connected | N2连接已建立，UE NGAP ID已分配 | Initial UE Message处理完成 |
| Context_Validating | gNB正在验证请求IE | 收到Initial Context Setup Request |
| Security_Activating | AS安全正在激活 | SecurityModeCommand已下发 |
| Context_Active | UE上下文完全激活 | RRCReconfigurationComplete收到 |
| Context_Failed | 上下文建立失败 | 任意步骤失败 |

## 六、Initial Context Setup Response与Failure对比

### 6.1 Response消息IE结构

| IE名称 | 存在性 | Criticality | 说明 |
|--------|--------|-------------|------|
| AMF UE NGAP ID | Mandatory | Ignore | 与Request中的值一致 |
| RAN UE NGAP ID | Mandatory | Ignore | 与Request中的值一致 |
| PDU Session Resource Setup List CxtRes | Optional | Ignore | **成功建立的**PDU会话资源列表 |
| PDU Session Resource Failed List CxtRes | Optional | Ignore | **建立失败的**PDU会话资源列表 |
| CriticalityDiagnostics | Optional | Ignore | 诊断信息 |

### 6.2 Failure消息IE结构

| IE名称 | 存在性 | Criticality | 说明 |
|--------|--------|-------------|------|
| AMF UE NGAP ID | Mandatory | Ignore | 标识失败UE |
| RAN UE NGAP ID | Mandatory | Ignore | 标识失败UE |
| Cause | Mandatory | Ignore | 失败原因码 |
| PDU Session Resource Failed List CxtRes | Optional | Ignore | 失败的PDU会话资源 |
| CriticalityDiagnostics | Optional | Ignore | 诊断信息 |
| RAN UE NGAP ID Extension | Optional | Ignore | RAN UE NGAP ID扩展 |

### 6.3 常见Cause值

| Cause值 | 典型场景 | 排查方向 |
|---------|---------|---------|
| **radio-network: unspecified** | 无线资源不足 | 检查gNB负载、PRB利用率 |
| **radio-network: encryption-and-or-integrity-protection-algorithms-not-supported** | 安全算法不匹配 | 对比UE能力与gNB配置 |
| **radio-network: interference-with-higher-priority-NR-layer** | 与更高优先级NR层冲突 | 检查载波配置 |
| **transport: transport-resource-unavailable** | 传输资源不可用 | 检查N3隧道、F1-U资源 |
| **protocol: transfer-syntax-error** | ASN.1编解码错误 | 抓包检查消息结构 |
| **protocol: abstract-syntax-error-reject** | IE无法识别 | 检查AMF/gNB版本兼容性 |
| **misc: control-processing-overload** | gNB处理过载 | 检查gNB CPU/内存负载 |
| **misc: not-enough-user-plane-processing-resources** | UP资源不足 | 检查gNB用户面处理能力 |

## 七、与4G S1AP Initial Context Setup的对比

| 对比维度 | 5G NGAP | 4G S1AP |
|---------|---------|---------|
| 协议规范 | TS 38.413 Section 8.3.1 | TS 36.413 Section 8.4.1 |
| 接口 | N2/NG-C | S1/S1-MME |
| UE标识 | AMF UE NGAP ID + RAN UE NGAP ID | MME UE S1AP ID + eNB UE S1AP ID |
| 切片信息 | Allowed NSSAI（**新增**） | 无（EPC不支持切片） |
| 安全密钥 | Security Key（256bit K<sub>gNB</sub>） | Security Key（256bit K<sub>eNB</sub>） |
| 安全算法标识 | NEA0-NEA7, NIA0-NIA7 | EEA0-EEA3, EIA0-EIA3 |
| 会话/承载建立 | PDU Session Resource Setup（透传结构） | E-RAB Setup（显式IE） |
| NAS捎带 | NAS-PDU（含Security Header） | NAS-PDU |
| Mobility Restriction | Mobility Restriction List（**增强**：含Service Area Restriction） | Handover Restriction List |
| UE聚合速率 | UE Aggregate Maximum Bit Rate | UE Aggregate Maximum Bit Rate |
| 设备标识 | Masked IMEISVN（**新增**） | 无（可选的IMEI通过NAS传递） |
| Partial Success | Response可含Failed List | 类似机制 |

**关键差异解读**：

1. **Allowed NSSAI是5G独有的切片感知机制**——gNB收到此IE后，在为PDU会话分配无线资源时会考虑切片的QoS Profile
2. **PDU Session Resource采用透传（Opaque Transfer）设计**——AMF不需要理解无线侧参数，全部封装在`PDUSessionResourceSetupRequestTransfer`中由gNB解析
3. **Masked IMEISVN体现了5G隐私增强**——IMEI在NAS层通过SUCI加密传递，在NGAP层以脱敏形式传递给gNB

## 八、实战连接：抓包识别与故障排查

### 8.1 Wireshark抓包过滤

```
# 过滤所有Initial Context Setup消息
ngap.procedureCode == 15

# 仅过滤Request
ngap.procedureCode == 15 && ngap.initiatingMessage

# 仅过滤Response
ngap.procedureCode == 15 && ngap.successfulOutcome

# 仅过滤Failure
ngap.procedureCode == 15 && ngap.unsuccessfulOutcome

# 检查特定AMF UE NGAP ID
ngap.procedureCode == 15 && ngap.amf_ue_ngap_id == 4257
```

### 8.2 TShark解码命令

```bash
# 提取Initial Context Setup Request中的关键IE
tshark -r trace.pcap -Y "ngap.procedureCode==15 && ngap.initiatingMessage" \
  -T fields \
  -e ngap.amf_ue_ngap_id \
  -e ngap.ran_ue_ngap_id \
  -e ngap.GUAMI \
  -e ngap.AllowedNSSAI \
  -e ngap.SecurityKey

# 统计Initial Context Setup成功/失败比例
tshark -r trace.pcap -Y "ngap.procedureCode==15" \
  -T fields -e ngap.message_type | sort | uniq -c
```

### 8.3 常见故障场景与排查思路

**场景1：Security Capability Mismatch**

```
现象：Initial Context Setup Failure
Cause: encryption-and-or-integrity-protection-algorithms-not-supported
```

**排查步骤**：
1. 检查Initial Context Setup Request中的`UESecurityCapabilities`——UE支持哪些NEA/NIA算法
2. 检查gNB配置中启用的算法列表
3. 确认是否存在交集。**NEA0（空加密）和NIA0（空完整性）在Rel-15中是强制支持的**，但如果gNB策略禁用了NEA0，可能出现不匹配
4. 注意Rel-18引入的NEA4-NEA7——如果AMF在UESecurityCapabilities中标记了这些位但gNB不支持，也会导致失败

**场景2：PDU Session Resource Partial Failure**

```
现象：Initial Context Setup Response中包含Failed-to-Setup List
（UE Context本身成功，但部分PDU会话资源建立失败）
```

**排查步骤**：
1. 不要误判为"Initial Context Setup失败"——UE Context是正常的
2. 检查Failed List中的Cause值，常见为`transport-resource-unavailable`或`not-enough-user-plane-processing-resources`
3. 检查N3接口的TEID分配是否成功
4. 检查gNB的F1-U接口资源（CU-DU分离架构下）

**场景3：AS安全激活失败（RRC SecurityModeFailure）**

```
现象：gNB发出SecurityModeCommand后收到SecurityModeFailure
→ 随后gNB发送UE Context Release Request
```

**排查步骤**：
1. 确认gNB选择的算法在UE安全能力范围内
2. 检查SecurityKey（K<sub>gNB</sub>）是否正确推演——可对比AMF日志中的KDF输入参数
3. 检查是否存在**安全上下文不同步**——UE和AMF的安全计数器不一致
4. 特别注意**重注册场景**——如果UE从旧AMF重定向到新AMF，K<sub>AMF</sub>可能需要从旧AMF通过N14接口传递
## 九、Rel-18/19增强特性

### 9.1 NEA4-NEA7 / NIA4-NIA7算法支持（Rel-18）

TS 33.501 V18.x引入了4组新的加密/完整性算法（NEA4/NIA4 ~ NEA7/NIA7），对应`UESecurityCapabilities`中的新增比特位。这意味着：

- AMF在Initial Context Setup Request中可能携带这些新算法的支持指示
- gNB需要根据自身配置选择是否使用新算法
- **向后兼容**：如果gNB仅支持NEA0-NEA3，应忽略高位bit

### 9.2 MBS多播/广播会话的上下文建立（Rel-17/18）

Rel-17引入了MBS（Multicast/Broadcast Service），Initial Context Setup过程也相应扩展：
- 如果UE加入了MBS多播会话，AMF可在Initial Context Setup Request中携带MBS Session信息
- gNB需为MBS会话建立相应的MRB（MBS Radio Bearer）

### 9.3 RRC Inactive态的上下文迁移（Rel-16+）

当UE从RRC Inactive态恢复时，gNB可能通过**Retrieve UE Context**过程（而非Initial Context Setup）恢复上下文。但在某些场景（如gNB间Resume），新gNB可能需要触发新的Initial Context Setup。

## 十、常见问题

**Q1: Initial Context Setup和PDU Session Establishment可以合并吗？**

A: 可以。这是5G相比4G的一个重要优化。AMF可以在Initial Context Setup Request中携带`PDU Session Resource Setup List CxtReq`，将上下文建立和初始PDU会话资源建立合并为一次N2交互。这减少了空口时延，特别有利于URLLC场景。但也存在风险——如果上下文建立失败，所有PDU会话资源也会一起失败。

**Q2: SecurityKey和UESecurityCapabilities中的算法有什么关系？**

A: SecurityKey提供的是**密钥材料**（K<sub>gNB</sub>），而UESecurityCapabilities提供的是UE**支持的算法列表**。gNB的工作是：从UESecurityCapabilities中选择自己也支持的算法，然后用SecurityKey推演出该算法对应的密钥。两者缺一不可——没有密钥无法加密，没有匹配的算法也无法工作。

**Q3: 为什么Criticality有的IE是Reject，有的是Ignore？**

A: 这反映了IE的重要性分级。**Reject**表示该IE如果无法识别，整个消息必须被拒绝——因为这些IE（如GUAMI、SecurityKey、Allowed NSSAI）是建立合法上下文的必要条件。**Ignore**表示该IE即使无法识别，也不影响上下文建立——如UE Aggregate Maximum Bit Rate仅用于调度优化，不影响上下文的合法性。

**Q4: Initial Context Setup Failure后AMF会怎么做？**

A: 根据TS 38.413 Section 8.3.2，AMF收到Failure后应：
1. 释放为该UE分配的N2资源
2. 如果NAS层有未完成的注册流程，向UE发送Registration Reject
3. 记录失败原因，用于后续的策略决策（如是否重定向到其他gNB）
4. 在特定场景下（如transport资源不可用），AMF可能触发N2 Handover尝试

**Q5: 在gNB CU-DU分离架构下，Initial Context Setup的信令路径有什么变化？**

A: 在CU-DU分离架构下，AMF仍然通过N2接口与CU通信。CU收到Initial Context Setup Request后，通过F1AP的**UE Context Setup Request**将部分参数（DRB配置、CellGroup配置等）传递给DU。DU完成L1/L2资源配置后回复CU。CU汇总所有信息后通过N2回复AMF。从AMF的角度看，CU-DU分离是透明的——AMF只与CU交互。

## 参考来源

1. [3GPP TS 38.413 V19.0.0](https://www.etsi.org/deliver/etsi_ts/138400_138499/138413/19.00.00_60/ts_138413v190000p.pdf) — NGAP Initial Context Setup Section 8.3.1/8.3.2, ASN.1 Section 9.2.1.1/9.2.1.2
2. [3GPP TS 33.501 V18.x](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169) — 安全密钥推演 KDF 定义，Section 6.9.2/6.9.3
3. [5G Initial Context Setup Request | 3glteinfo](https://www.3glteinfo.com/messages/5g/ngap/initial-context-setup-request/) — IE详解与Call Flow分析
4. [5G Initial Context Setup Failure Analysis | 3glteinfo](https://www.3glteinfo.com/troubleshooting/5g/signaling-and-procedure-failures/initial-context-setup-failure-analysis/) — 故障排查指南
5. [5G Initial Context Setup and Security Mode Command | TelecomTrainer](https://www.telecomtrainer.com/5g-initial-context-setup-and-security-mode-command-explained-step-by-step-5g-core-signaling/) — Step-by-Step信令解析

---

> 本文由「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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)