首页 › core-network › 5G N3IWF注册与EAP-5G认证全链路拆解

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架构参考点

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个关键步骤：

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: [email protected])
        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：

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地址

关键密钥派生：

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状态机与消息映射

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：

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过滤器

# 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

参考来源

3GPP TS 23.502 V18.x — Section 4.12.2: Registration for untrusted non-3GPP access
3GPP TS 33.501 V18.10.0 — Section 6.3.2: EAP-5G authentication, Section 6.9.2: K_N3IWF derivation
3GPP TS 24.502 V16.11.0 — Section 9.3.2: EAP-5G procedures and AN-Parameters encoding
RomARS: 5G focus on N3IWF, TNGF, TWIF and W-5GAN — 协议栈详解与架构分析
Wipro: 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学通信知识星球海报-扫码加入