<!-- title: 5G N3IWF注册与EAP-5G认证全链路拆解 -->
<!-- domain: core-network -->

# 5G N3IWF非授信接入注册与EAP-5G认证信令全链路拆解

## 一、引言：为什么需要N3IWF？

在5G系统架构中，UE（用户设备）不仅可以通过NR/LTE等3GPP接入网连接5G核心网，还可以通过Wi-Fi等非3GPP接入网接入。3GPP TS 23.501将非3GPP接入分为两类：**授信接入**（Trusted，由运营商管控）和**非授信接入**（Untrusted，如公共Wi-Fi热点、家庭Wi-Fi等不受运营商控制）。

对于非授信接入，3GPP R15定义了一个全新的网络功能——**N3IWF（Non-3GPP InterWorking Function）**，它在架构上等效于4G中的ePDG（evolved Packet Data Gateway），但在协议机制上做了根本性重构：

| 对比维度 | 4G ePDG | 5G N3IWF |
|---------|---------|----------|
| 接入认证 | EAP-AKA via AAA/HSS | EAP-5G + 5G-AKA/EAP-AKA' via AMF/AUSF/UDM |
| NAS传输 | 无NAS概念 | 完整NAS信令（5GMM/5GSM） |
| 控制面接口 | SWm/S2b（GTPC/PMIP） | N2（NGAP）/ N1（NAS） |
| 用户面接口 | S2b（GTPU/GRE） | N3（GTPU） |
| QoS承载 | 基于EPS Bearer | 基于QoS Flow + IPsec Child SA |
| 密钥体系 | CK/IK直接派生 | K_SEAF → K_N3IWF 分层派生 |
| NAS封装 | 无 | EAP-5G封装NAS-PDU |

N3IWF的核心设计思想是：**让非3GPP接入复用5G核心网相同的注册、认证、会话管理信令流程**，而不是像4G ePDG那样走一套独立的AAA/Diameter体系。这使得UE无论通过NR还是Wi-Fi接入，核心网看到的都是统一的NAS信令，AMF的处理逻辑高度一致。

本文将聚焦TS 23.502 Section 4.12.2定义的注册流程、TS 33.501 Section 6.3.2定义的EAP-5G认证机制、以及TS 24.502定义的AN-Parameters编码格式，进行全链路深度拆解。

## 二、总体架构与协议栈

### 2.1 N3IWF架构参考点

```mermaid
graph TB
    subgraph UE ["UE (5G终端)"]
        U1[NAS层]
        U2[EAP-5G]
        U3[IKEv2/IPsec]
        U1 --> U2 --> U3
    end

    subgraph WiFi ["非授信WLAN"]
        W1[WLAN AP]
    end

    subgraph N3IWF ["N3IWF"]
        N1[IKEv2/EAP-5G终结]
        N2[NGAP适配]
        N3[IPsec/GRE处理]
        N1 --> N2
        N1 --> N3
    end

    subgraph 5GC ["5G核心网"]
        AMF[AMF]
        AUSF[AUSF]
        UDM[UDM/ARPF]
        SMF[SMF]
        UPF[UPF]
    end

    U3 -->|"NWu<br/>IPsec隧道"| W1 -->|"Y2<br/>IP"| N1
    N2 -->|"N2<br/>NGAP/SCTP"| AMF
    N3 -->|"N3<br/>GTP-U"| UPF
    AMF --> AUSF --> UDM
    AMF --> SMF --> UPF
    U1 -.->|"N1 NAS"| AMF

    style UE fill:#e1f5fe
    style N3IWF fill:#fff3e0
    style 5GC fill:#e8f5e9
```

### 2.2 控制面协议栈三阶段演变

N3IWF的协议栈在整个注册过程中经历三个阶段的变化，这是理解整个机制的关键：

**阶段一：IKE_SA_INIT（信令IPsec SA建立前）**

```
UE                    N3IWF                  AMF
|  IKEv2 (UDP 500/4500)  |                      |
|  ←→ IKE_SA_INIT        |                      |
|                         |                      |
```

此时UE和N3IWF之间只有IKEv2报文（明文或半加密），尚未建立任何安全隧道。

**阶段二：IKE_AUTH + EAP-5G（注册与认证阶段）**

```
UE                     N3IWF                  AMF
|  IPsec ESP (IKE SA)    |                      |
|    EAP-5G              |                      |
|      NAS-PDU           |   NGAP (N2/SCTP)     |
|  ←→ IKE_AUTH           | ←→ InitialUEMessage  |
```

IKE SA建立后，EAP-5G消息在IPsec隧道内传输，NAS-PDU被封装在EAP-5G中。N3IWF解封装EAP-5G，提取NAS-PDU，通过N2 NGAP转发给AMF。

**阶段三：注册完成后的NAS传输**

```
UE                     N3IWF                  AMF
|  IPsec ESP (信令SA)     |                      |
|    TCP                  |                      |
|      NAS-PDU            |   NGAP (N2/SCTP)     |
```

注册完成后，UE与N3IWF之间建立TCP连接（在信令IPsec SA内），后续的NAS消息通过TCP承载，N3IWF通过NGAP Uplink/Downlink NAS Transport消息转发给AMF。

## 三、注册信令全流程时序图

以下是TS 23.502 Section 4.12.2.2定义的完整注册流程，包含14个关键步骤：

```mermaid
sequenceDiagram
    participant UE as UE
    participant N3IWF as N3IWF
    participant AMF as AMF
    participant AUSF as AUSF
    participant UDM as UDM/ARPF

    rect rgb(232, 245, 233)
        Note over UE,N3IWF: Phase 1: IKE_SA_INIT
        UE->>N3IWF: IKE_SA_INIT Request<br/>(SAi1, KEi, Ni)
        N3IWF->>UE: IKE_SA_INIT Response<br/>(SAr1, KEr, Nr, [CERTREQ])
    end

    rect rgb(227, 242, 253)
        Note over UE,AMF: Phase 2: IKE_AUTH + EAP-5G Registration
        UE->>N3IWF: IKE_AUTH Request<br/>(IDi, [IDr], SAi2, [AUTH omitted])
        N3IWF->>UE: EAP-Request/Identity
        UE->>N3IWF: EAP-Response/Identity<br/>(NAI: SUPI@nai.3gpp.org)
        N3IWF->>UE: EAP-Request/5G-Start<br/>(AN-Parameters请求)
        UE->>N3IWF: EAP-Response/5G-NAS<br/>(AN-Params + NAS Registration Request)
        N3IWF->>AMF: N2 Initial UE Message<br/>(NAS Reg Request + N3IWF Info)
    end

    rect rgb(255, 243, 224)
        Note over UE,UDM: Phase 3: Primary Authentication
        AMF->>AUSF: Nausf_UEAuthentication<br/>Auth Request (SUCI/SUPI)
        AUSF->>UDM: Nudm_UEAuthentication<br/>Get Auth Data
        UDM->>AUSF: 5G AV (RAND, AUTN, XRES*, K_AUSF)
        AUSF->>AMF: Auth Response (RAND, AUTN, XRES*)
        AMF->>N3IWF: N2 Downlink NAS Transport<br/>(NAS Auth Request: RAND, AUTN)
        N3IWF->>UE: EAP-Request/5G-NAS<br/>(NAS Authentication Request)
        UE->>N3IWF: EAP-Response/5G-NAS<br/>(NAS Authentication Response: RES*)
        N3IWF->>AMF: N2 Uplink NAS Transport<br/>(NAS Auth Response: RES*)
        AMF->>AUSF: Nausf_UEAuthentication<br/>Auth Confirm (RES*)
        AUSF->>AMF: Auth Confirm Result (K_SEAF)
    end

    rect rgb(243, 229, 245)
        Note over UE,AMF: Phase 4: NAS Security + Registration Accept
        AMF->>N3IWF: N2 DL NAS Transport<br/>(NAS Security Mode Command)
        N3IWF->>UE: EAP-Request/5G-NAS<br/>(NAS SMC)
        UE->>N3IWF: EAP-Response/5G-NAS<br/>(NAS Security Mode Complete)
        N3IWF->>AMF: N2 UL NAS Transport<br/>(NAS SMC Complete)
        AMF->>N3IWF: N2 DL NAS Transport<br/>(NAS Registration Accept)
        N3IWF->>UE: EAP-Request/5G-NAS<br/>(NAS Registration Accept: 5G-GUTI)
        UE->>N3IWF: EAP-Response/5G-NAS<br/>(NAS Registration Complete)
        N3IWF->>AMF: N2 UL NAS Transport<br/>(NAS Registration Complete)
    end

    rect rgb(225, 245, 254)
        Note over UE,N3IWF: Phase 5: IKEv2完成
        N3IWF->>UE: IKE_AUTH Response<br/>(SAr2, AUTH, TSi, TSr, [CP])
        UE->>N3IWF: Informational (ACK)
        Note over UE,N3IWF: 信令IPsec SA建立完成
    end
```

## 四、逐步信令解析

### 4.1 Phase 1: IKE_SA_INIT——建立第一层安全隧道

**IKE_SA_INIT**是RFC 7296定义的IKEv2标准流程，UE和N3IWF协商出第一个IKE SA（Security Association），为后续的EAP-5G交换提供加密通道。

**Step 1: UE → N3IWF: IKE_SA_INIT Request**

| IE | 说明 | 典型值 |
|----|------|--------|
| SAi1 | 安全关联提案（加密/完整性/PRF/DH组） | AES-CBC-256 + HMAC-SHA2-256 + DH Group 19/20 |
| KEi | Diffie-Hellman公开值 | 基于协商的DH Group计算 |
| Ni | UE随机数（Nonce） | 16~32字节随机值 |

**Step 2: N3IWF → UE: IKE_SA_INIT Response**

| IE | 说明 |
|----|------|
| SAr1 | N3IWF选择的安全关联参数 |
| KEr | N3IWF的DH公开值 |
| Nr | N3IWF随机数 |
| CERTREQ | 可选，请求UE证书（EAP模式下通常不发） |

此阶段完成后，UE和N3IWF基于DH交换各自计算出**SK_ei/SK_er**（加密密钥）和**SK_ai/SK_ar**（完整性密钥），后续所有IKE_AUTH消息都在这些密钥保护下传输。

**设计意图**：IKE_SA_INIT阶段只协商隧道级别的安全参数，不涉及3GPP认证。这种分层设计使得3GPP的认证机制（5G-AKA/EAP-AKA'）可以完全在IKEv2的EAP框架内运行，实现了安全协议的解耦。

### 4.2 Phase 2: IKE_AUTH + EAP-5G——注册请求发起

**Step 3: UE → N3IWF: IKE_AUTH Request**

UE发送IKE_AUTH请求，其中**不包含AUTH载荷**（因为认证将通过EAP完成），但包含：
- **IDi**：UE身份标识（NAI格式，如`<SUCI>@nai.3gpp.org`）
- **SAi2**：提议的IPsec SA参数（ESP加密/完整性算法）

**Step 4-5: EAP-Identity交换**

N3IWF作为EAP认证器，先通过标准EAP-Identity流程获取UE身份：

```
N3IWF → UE: EAP-Request/Identity
UE → N3IWF: EAP-Response/Identity (NAI: <SUCI>@nai.3gpp.org)
```

**Step 6: EAP-Request/5G-Start**

N3IWF发送**EAP-Request/5G-Start**消息，触发EAP-5G流程。EAP-5G的标识特征：
- **EAP Code**: 1 (Request)
- **EAP Type**: 0xFE (Expanded Type)
- **Vendor-ID**: 3GPP (0x5581)
- **Vendor-Type**: EAP-5G (0x01)
- **Sub-Type**: 5G-Start (0x01)

**Step 7: UE → N3IWF: EAP-Response/5G-NAS（核心消息）**

这是整个流程中最关键的EAP-5G消息，UE同时携带**AN-Parameters**和**NAS Registration Request**：

```mermaid
graph LR
    subgraph EAP-Response/5G-NAS
        A[EAP Header<br/>Code=2 Type=0xFE]
        B[Vendor-ID: 3GPP 0x5581]
        C[Vendor-Type: EAP-5G 0x01]
        D[Sub-Type: 5G-NAS 0x02]
        E[AN-Parameters<br/>TLV编码]
        F[NAS-PDU<br/>Registration Request]
    end
    A --> B --> C --> D --> E --> F
```

**AN-Parameters编码格式**（TS 24.502 Section 9.3.2.2.2）：

| 参数类型 | Type值 | 长度 | 说明 |
|---------|--------|------|------|
| GUAMI | 0x01 | 6字节 | PLMN ID (3B) + AMF ID (3B) |
| Selected PLMN ID | 0x02 | 3字节 | UE选择的PLMN |
| Requested NSSAI | 0x03 | 可变 | S-NSSAI列表（SST 1B + SD 3B） |
| Establishment Cause | 0x04 | 1字节 | MO-Signaling/MO-Data/MT-Access等 |

AN-Parameters的TLV编码示例（基于free5GC n3iwue实现分析）：

```
GUAMI TLV:
  Type: 0x01 (1 byte)
  Length: 0x06 (1 byte)
  Value: MCC+MNC编码 (3 bytes) + AMF Region/Set/Pointer (3 bytes)

Requested NSSAI TLV:
  Type: 0x03 (1 byte)
  Length: N (1 byte)
  Value: 
    S-NSSAI-1 Length: 0x04 (1 byte)
    SST: 0x01 (1 byte) 
    SD: 0x01 0x02 0x03 (3 bytes)
    S-NSSAI-2 Length: 0x04 (1 byte)
    SST: 0x02 (1 byte)
    SD: 0x00 0x00 0x00 (3 bytes)
```

**设计意图**：AN-Parameters是N3IWF执行AMF选择所需的关键信息。在3GPP接入中，gNB通过NGAP直接传递这些参数给AMF；而在非3GPP接入中，N3IWF需要从UE获取这些参数，然后组装到NGAP Initial UE Message中。这就是为什么AN-Parameters要在EAP-5G消息中单独编码——N3IWF需要提取它们并映射到N2接口。

**Step 8: N3IWF → AMF: N2 Initial UE Message**

N3IWF将收到的EAP-5G中提取的NAS-PDU和AN-Parameters组装为NGAP消息：

| NGAP IE | 来源 | 说明 |
|---------|------|------|
| NAS-PDU | EAP-5G中的NAS Registration Request | UE的注册请求 |
| UserLocationInformation | N3IWF构造 | 包含N3IWF的TAC和Cell ID |
| RAN UE NGAP ID | N3IWF分配 | N3IWF侧的UE标识 |
| SelectedPLMNID | AN-Parameters中的Selected PLMN ID | 用于AMF确认PLMN |
| Allowed NSSAI | N3IWF本地配置或NRF查询 | 允许的切片列表 |

### 4.3 Phase 3: 主认证——5G-AKA/EAP-AKA'

**Step 9-10: AMF → AUSF → UDM/ARPF 认证向量获取**

AMF根据Registration Request中的SUCI（或5G-GUTI），执行标准的5G认证向量获取流程：
- AMF调用`Nausf_UEAuthentication_Authenticate` Request给AUSF
- AUSF调用`Nudm_UEAuthentication_Get`给UDM/ARPF
- UDM/ARPF生成5G Authentication Vector (5G AV)，包含**RAND、AUTN、XRES\*、K_AUSF**

**Step 11-12: NAS认证挑战下发**

AMF通过N2 Downlink NAS Transport将`NAS Authentication Request`（包含RAND和AUTN）发给N3IWF。N3IWF封装为**EAP-Request/5G-NAS**：

| EAP-5G字段 | 内容 |
|------------|------|
| Sub-Type | 5G-NAS (0x02) |
| AN-Parameters | 空（下行方向不携带） |
| NAS-PDU | NAS Authentication Request (RAND, AUTN) |

**Step 13-14: UE响应认证**

UE收到RAND和AUTN后，执行以下操作：
1. **验证网络**：检查AUTN中的MAC和SQN，确认是合法网络
2. **计算RES\***：基于USIM中的K和RAND，通过Milenage算法计算RES，再通过KDF推演RES\*
3. **派生K_SEAF**：基于CK'||IK'，通过KDF推演出K_SEAF（锚点密钥）

UE将RES\*通过`NAS Authentication Response`返回。

**Step 15-16: AUSF验证**

AMF将RES\*转发给AUSF，AUSF比对RES\*和XRES\*（哈希后比对XRES\*的哈希）。认证成功后，AUSF返回**K_SEAF**给AMF。

### 4.4 Phase 4: NAS安全模式与注册接受

**Step 17-18: NAS Security Mode Command**

AMF通过N2下发`NAS Security Mode Command`，携带：
- 选定的NAS安全算法（如NEA2/NEA3加密 + NIA2/NIA3完整性）
- K_AMF的KDF输入参数
- UE安全能力确认

UE收到后，基于K_SEAF推演**K_AMF**，再推演**NAS加密密钥**和**NAS完整性密钥**，后续NAS消息将受到加密和完整性保护。

**Step 19-20: NAS Registration Accept**

AMF下发`NAS Registration Accept`，关键IE：

| IE | 说明 |
|----|------|
| 5G-GUTI | AMF分配的临时标识 |
| TAI List | 注册区域列表 |
| Allowed NSSAI | 允许的切片 |
| Registration Area | 注册区域 |
| 5GS Registration Result | 注册结果 |
| MICO Indication | 可选，MICO模式指示 |
| LADN Information | 可选，本地接入数据网络信息 |

**Step 21-22: Registration Complete**

UE发送`NAS Registration Complete`确认收到5G-GUTI。

### 4.5 Phase 5: IKEv2完成与信令IPsec SA建立

**Step 23: N3IWF → UE: IKE_AUTH Response**

N3IWF发送最终的IKE_AUTH响应，完成IKEv2协商：

| IE | 说明 |
|----|------|
| SAr2 | 选定的IPsec SA（ESP算法） |
| AUTH | N3IWF的认证数据（基于K_N3IWF派生） |
| TSi, TSr | Traffic Selector（信令流量范围） |
| CP (Configuration Payload) | 可选，分配UE内部IP地址 |

**关键密钥派生**：

```mermaid
graph TD
    K["K (USIM/UDM永久密钥)"]
    K -->|"AKA"| CKIK["CK ∥ IK"]
    CKIK -->|"KDF (RFC 5448)"| CKpIKp["CK' ∥ IK'"]
    CKpIKp -->|"KDF (TS 33.501 6.1.1)"| KSEAF["K_SEAF<br/>(锚点密钥)"]
    KSEAF -->|"KDF (TS 33.501 6.1.2)"| KAMF["K_AMF"]
    KAMF -->|"KDF"| NAS_K["NAS加密/完整性密钥"]
    KAMF -->|"KDF"| KN3IWF["K_N3IWF<br/>(TS 33.501 6.9.2)"]
    KN3IWF -->|"KDF"| IKE_SK["IKE SA密钥<br/>(SK_ei/SK_ai等)"]
    KN3IWF -->|"KDF"| IPsec_SK["IPsec Child SA密钥<br/>(ESP加密/完整性)"]

    style K fill:#ffcdd2
    style KSEAF fill:#fff9c4
    style KN3IWF fill:#c8e6c9
```

K_N3IWF的派生过程（TS 33.501 Section 6.9.2）：

```
K_N3IWF = KDF(K_AMF, 
    "N3IWF NAS traffic key", 
    P0 = Access Type (non-3GPP), 
    L0 = length of P0)
```

K_N3IWF再通过IKEv2的KDF进一步派生为：
- **SK_d**：用于后续Child SA的密钥材料
- **SK_ai/SK_ar**：IKE SA完整性密钥
- **SK_ei/SK_er**：IKE SA加密密钥

**设计意图**：密钥层级的设计体现了5G安全架构的核心原则——**密钥隔离**。K_N3IWF与NAS密钥、3GPP接入密钥完全独立，即使N3IWF被攻破，攻击者也无法获取NAS层的密钥材料或其他接入类型的密钥。这比4G ePDG直接使用CK/IK的安全性强得多。

## 五、EAP-5G协议封装深度解析

### 5.1 EAP-5G消息格式

EAP-5G定义于TS 24.502，是一种扩展EAP方法（Expanded Type），用于在IKEv2隧道内传输5G NAS消息和接入网参数。

```
EAP-5G消息通用格式:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Code (1B)    |  Identifier   |            Length (2B)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type = 0xFE (Expanded)                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-ID = 0x005581 (3GPP)                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-Type = 0x00000001 (EAP-5G)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sub-Type (1B) |  Reserved    |  AN-Params Len (2B)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  AN-Parameters (TLV) ...                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NAS-PDU Length (2B)  |  NAS-PDU ...                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

| Sub-Type值 | 名称 | 方向 | 用途 |
|------------|------|------|------|
| 0x01 | 5G-Start | N3IWF→UE | 触发UE发送NAS注册请求 |
| 0x02 | 5G-NAS | 双向 | 携带AN-Parameters和NAS-PDU |
| 0x03 | 5G-Stop | N3IWF→UE | 终止EAP-5G会话（异常情况） |
| 0x04 | 5G-Auto-Re-Auth | 双向 | 自动重认证（R16新增） |

### 5.2 AN-Parameters完整编码

| 参数 | Type | 编码规则 | 示例值 |
|------|------|---------|--------|
| GUAMI | 0x01 | PLMN ID（BCD编码3字节）+ AMF ID（3字节） | 02F860 + 800001 |
| PLMN ID (Selected) | 0x02 | BCD编码，MCC+MNC | 02F860 (MCC=208, MNC=60) |
| Requested NSSAI | 0x03 | Length+SST+SD列表 | 04 01 010203 |
| Establishment Cause | 0x04 | 枚举值 | 0x00 (MO-Signaling) |
| Requested Target Cell | 0x05 | 可选，目标小区ID | - |
| UE's Usage | 0x06 | 可选 | - |

PLMN ID的BCD编码特殊规则（以MCC=460, MNC=00为例）：
```
Byte 1: MCC Digit 2 | MCC Digit 1  → 0x64
Byte 2: MNC Digit 3 | MCC Digit 3  → 0x04 (MNC 3位时) 或 0xF4 (MNC 2位时)
Byte 3: MNC Digit 2 | MNC Digit 1  → 0x00
```

## 六、N3IWF状态机与消息映射

```mermaid
stateDiagram-v2
    [*] --> Idle: UE未连接
    
    Idle --> IKE_SA_INIT: 收到IKE_SA_INIT Request
    IKE_SA_INIT --> IKE_SA_ESTABLISHED: SA协商成功
    IKE_SA_ESTABLISHED --> EAP_IDENTITY: 发送EAP-Request/Identity
    
    EAP_IDENTITY --> EAP_5G_START: 收到EAP-Response/Identity
    EAP_5G_START --> NAS_REG_PENDING: 收到EAP-Response/5G-NAS<br/>(Registration Request)
    
    NAS_REG_PENDING --> AUTH_CHALLENGE: N2 DL NAS Transport<br/>(Auth Request)
    AUTH_CHALLENGE --> AUTH_VERIFY: 收到EAP-Response/5G-NAS<br/>(Auth Response RES*)
    AUTH_VERIFY --> NAS_SMC: AUSF认证成功
    AUTH_VERIFY --> AUTH_FAILURE: AUSF认证失败
    
    NAS_SMC --> REG_ACCEPT: 收到EAP-Response/5G-NAS<br/>(SMC Complete)
    REG_ACCEPT --> IKE_AUTH_DONE: 收到Registration Complete
    
    IKE_AUTH_DONE --> REGISTERED: IKE_AUTH Response发送成功
    REGISTERED --> [*]: 正常去注册
    
    AUTH_FAILURE --> [*]: EAP-Failure
    IKE_SA_INIT --> [*]: SA协商失败
```

### N3IWF对NAS消息的映射规则

| 方向 | N3IWF行为 |
|------|----------|
| UL: EAP-Response/5G-NAS → N2 | 提取NAS-PDU，封装为NGAP Uplink NAS Transport |
| DL: N2 → EAP-Request/5G-NAS | 从NGAP Downlink NAS Transport提取NAS-PDU，封装为EAP-Request/5G-NAS |
| UL: TCP NAS → N2 | 解析TCP流中的NAS消息，封装为NGAP Uplink NAS Transport |
| DL: N2 → TCP NAS | 从NGAP提取NAS-PDU，写入TCP连接 |

## 七、用户面IPsec Child SA建立

注册完成后，UE通过信令IPsec SA内的TCP连接发送PDU Session Establishment请求。PDU会话建立成功后，N3IWF为每个QoS Flow创建一个**IPsec Child SA**：

```mermaid
sequenceDiagram
    participant UE
    participant N3IWF
    participant SMF
    participant UPF

    UE->>N3IWF: NAS PDU Session Establishment Request<br/>(via 信令IPsec SA + TCP)
    N3IWF->>SMF: N2 SM Info (via AMF)
    SMF->>N3IWF: N2 SM Info: PDU Session Resource Setup<br/>(QoS Flow参数, GTP Tunnel Info)
    N3IWF->>UE: CREATE_CHILD_SA Request<br/>(SA提案, TSi, TSr, SPI)
    UE->>N3IWF: CREATE_CHILD_SA Response<br/>(确认SA, SPI)
    Note over UE,N3IWF: 用户面IPsec Child SA建立
    N3IWF->>UPF: GTP-U Tunnel (N3) 建立
    Note over UE,UPF: UE ←IPsec→ N3IWF ←GTP-U→ UPF ←N6→ DN
```

用户面协议栈（TS 23.501 Figure 4.4.2.1-2）：

```
UE                     N3IWF                    UPF
|  App PDU (IP)        |                         |
|  GRE (+QFI)          |                         |
|  IP (Inner)          |                         |
|  ESP (IPsec Tunnel)  |---IP/WiFi---|           |
|  IP (Outer)          |             |           |
|  WiFi (802.11)       |             |           |
                       |  App PDU (IP)          |
                       |  GTP-U                 |
                       |  UDP                   |
                       |  IP                    |
                       |  N3                    |
```

GRE头部中的**QFI（QoS Flow Identifier）**字段用于标识数据包所属的QoS Flow，N3IWF根据QFI将上行数据映射到对应的GTP-U隧道，下行方向则将GTP-U中的QFI映射到对应的IPsec Child SA。

## 八、抓包识别与故障排查

### 8.1 Wireshark过滤器

```bash
# IKEv2协商阶段
ikev2 || (udp.port == 500 || udp.port == 4500)

# EAP-5G消息（EAP Type = 0xFE = Expanded）
eap.type == 254

# IPsec ESP隧道
esp

# NAS-5GS消息（注册完成后通过TCP传输）
nas-5gs

# 综合过滤器
ikev2 || esp || (eap.type == 254) || nas-5gs
```

### 8.2 常见故障点与排错

| 故障现象 | 根因分析 | 排错方法 |
|---------|---------|---------|
| IKE_SA_INIT无响应 | 防火墙拦截UDP 500/4500 | `tcpdump -i any udp port 500 or port 4500` |
| NO_PROPOSAL_CHOSEN | 加密算法不匹配 | 检查UE和N3IWF的IKE Proposal配置 |
| EAP-Identity后断开 | N3IWF无法连接AMF（N2/SCTP） | 检查N3IWF到AMF的SCTP连接状态 |
| 5GMM Cause #7 | 用户未签约非3GPP接入 | 检查UDM中Access andMobilitySubscriptionData |
| 5GMM Cause #22 | AMF拥塞 | 检查AMF负载和过载控制策略 |
| EAP-5G AN-Parameters解析失败 | PLMN ID编码错误 | 对比TS 24.502 Section 9.3.2.2.2的BCD编码 |
| 注册完成后无数据 | Child SA未建立或GRE隧道异常 | 检查IPsec SA状态 `ip xfrm state` |
| 单向通（上行有下行无） | NAT-T未启用或SPD不匹配 | 确认UDP 4500 NAT-T，检查Security Policy Database |

### 8.3 典型抓包特征

一个成功的N3IWF注册过程在Wireshark中应呈现如下消息序列：

```
1. IKE_SA_INIT Request/Response (2包)
2. IKE_AUTH Request (含IDi，无AUTH) (1包)
3. EAP-Request/Identity (1包)
4. EAP-Response/Identity (1包)
5. EAP-Request/5G-Start (1包)
6. EAP-Response/5G-NAS (含AN-Params + NAS Reg Request) (1包)
7. EAP-Request/5G-NAS (NAS Auth Request: RAND, AUTN) (1包)
8. EAP-Response/5G-NAS (NAS Auth Response: RES*) (1包)
9. EAP-Request/5G-NAS (NAS SMC) (1包)
10. EAP-Response/5G-NAS (NAS SMC Complete) (1包)
11. EAP-Request/5G-NAS (NAS Registration Accept) (1包)
12. EAP-Response/5G-NAS (NAS Registration Complete) (1包)
13. IKE_AUTH Response (含AUTH, SAr2, TSi, TSr) (1包)
```

总计约13-15个IKEv2/EAP包，整个注册过程在正常情况下耗时200-500ms。
## 九、常见问题

**Q1: N3IWF和TNGF的区别是什么？**

A: N3IWF用于**非授信**非3GPP接入（如公共Wi-Fi），UE与N3IWF之间需要建立IPsec隧道保证安全；TNGF（Trusted Non-3GPP Gateway Function，R16引入）用于**授信**非3GPP接入（如运营商自建Wi-Fi），因为接入网可信，安全要求可适当降低。TNGF使用TLS而非IKEv2/IPsec建立安全通道，协议开销更小。此外，TWIF（Trusted WLAN Interworking Function）则专门用于WLAN的授信接入场景。

**Q2: EAP-5G为什么不直接用EAP-AKA'传输NAS消息？**

A: EAP-AKA'是一种认证方法，它的载荷格式是固定的（用于传递AT_RAND、AT_AUTN等AKA参数）。而EAP-5G是一种**传输协议**（wrapper），它的Sub-Type=5G-NAS可以封装任意的NAS消息，实现了认证（5G-AKA/EAP-AKA'）和NAS传输的解耦。这种设计使得5G核心网不需要关心底层是3GPP接入还是非3GPP接入，AMF处理的NAS消息格式完全一致。

**Q3: 注册完成后为什么还需要TCP连接传输NAS消息？**

A: IKEv2的EAP交换是"请求-响应"模式，一次只能有一个未完成的EAP消息，不适合双向异步的NAS消息传输。注册完成后，UE在信令IPsec SA内建立一个TCP连接到N3IWF的特定端口（TS 24.502规定），TCP连接支持双向独立收发NAS消息，满足SMF/AMF主动下发NAS通知的需求（如Configuration Update Command、Network Slicing Change等）。

**Q4: 一个UE能否同时通过3GPP和非3GPP接入注册到同一个AMF？**

A: 可以。3GPP R16引入了**ATSSS（Access Traffic Steering, Switching and Splitting）**功能，支持UE通过3GPP和非3GPP接入同时注册到5G核心网（称为Multi-Access PDU Session）。AMF通过不同的Access Type标识区分两个注册。但需要注意：两个注册使用不同的GUAMI和不同的安全上下文，N3IWF和gNB各自独立维护与AMF的N2连接。

**Q5: N3IWF部署时如何选择AMF？**

A: N3IWF执行AMF选择的依据来自EAP-5G中UE提供的AN-Parameters（GUAMI、Selected PLMN ID、Requested NSSAI）。选择逻辑遵循TS 23.501 Section 6.3.5：
1. 如果AN-Parameters中有GUAMI且对应的AMF可用，直接选择该AMF
2. 否则根据PLMN ID + NSSAI查询NRF，选择支持对应切片的AMF
3. 如果没有NSSAI信息，N3IWF使用本地配置的默认AMF

## 参考来源

1. [3GPP TS 23.502 V18.x](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.12.2: Registration for untrusted non-3GPP access
2. [3GPP TS 33.501 V18.10.0](https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/18.10.00_60/ts_133501v181000p.pdf) — Section 6.3.2: EAP-5G authentication, Section 6.9.2: K_N3IWF derivation
3. [3GPP TS 24.502 V16.11.0](https://cdn.standards.iteh.ai/samples/72451/fbd47aee31504546a9a43c9fcccadfab/ETSI-TS-124-502-V16-11-0-2024-07-.pdf) — Section 9.3.2: EAP-5G procedures and AN-Parameters encoding
4. [RomARS: 5G focus on N3IWF, TNGF, TWIF and W-5GAN](https://romars.tech/en/pubblications/n3iwf/) — 协议栈详解与架构分析
5. [Wipro: Untrusted Non-3GPP Access Network Interworking with 5G Core](https://www.wipro.com/network-edge-providers/untrusted-non-3gpp-access-network-interworking-with-5g-core/) — 注册流程与QoS机制分析

---
> 本文由「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)