# 5G非3GPP接入注册信令拆解：IKEv2/IPsec + EAP-5G + NAS 三层封装全链解析
当一部手机经公共 Wi-Fi（咖啡店、家庭路由、机场热点）接入 5G 核心网时，由于这段 IP 网络对运营商而言"完全不可信"，5GC 必须用一套与蜂窝空口截然不同的封装机制把 UE 安全地"接入"进来。这套机制的核心是 **N3IWF（Non-3GPP InterWorking Function）**，对应规范为 **3GPP TS 23.502 第 4.12.2.2 节**。本文聚焦"非信任非 3GPP 接入的注册信令全链"，逐层拆解 IKEv2/IPsec 隧道、EAP-5G 承载、5G NAS 注册三者如何在一个看似 VPN 的流程里完成身份认证与注册。
---
## 一、为什么需要一个"长得像 gNB 的网元"
在 5G 系统架构里，N3IWF 对 5GC 内部暴露的接口与 gNB 完全一致：**N2（NGAP）连 AMF、N3（GTP-U）连 UPF**。从 AMF 的视角看，它根本不关心对面是 NR 基站还是 N3IWF——只要走 NGAP、能传 NAS、能做 PDU Session 资源建立即可。这种"接入无关性（access agnostic）"是 5GC 相比 4G EPC 的关键设计红利：把异质接入的差异完全收敛到一个边缘网元，核心网内部协议保持不变。
但 N3IWF 与 gNB 有一个本质差异：**UE 到 N3IWF 之间没有空口安全（AS 层）**。5G NR 有 RRC 安全和 UP/CP 数据无线承载加密；而 UE 到 N3IWF 之间是一段任意的、可能被嗅探和篡改的公共 IP 网络。于是 5G 把这段"不可信 IP 网络"上的安全责任全部用 **IKEv2/IPsec** 来兜底，形成了著名的**两层保护模型**：
- **外层 IKEv2/IPsec**：UE 与 N3IWF 之间建立加密隧道，保证即使 Wi-Fi/中间 IP 网被攻击者控制，也无法窃听或篡改 5G 信令与用户面。
- **内层 5G-AKA / EAP-AKA′**：在隧道内部，UE 仍必须向 AUSF/UDM 证明"我是谁、是否有权接入"。
```mermaid
flowchart TD
UE["UE
(5G NAS + IPsec Client)"] -->|"WiFi / 有线 IP
DHCP 获取 IP"| AN["非3GPP接入网 AN
(Untrusted)"]
AN -->|"NWu: IKEv2/IPsec (UDP 500/4500)"| N3IWF["N3IWF
= 虚拟 gNB"]
N3IWF -->|"N2: NGAP"| AMF["AMF"]
N3IWF -->|"N3: GTP-U"| UPF["UPF"]
AMF -->|"SBI"| AUSF["AUSF"]
AUSF -->|"SBI"| UDM["UDM/ARPF"]
UPF -->|"N6"| DN["DN / Internet"]
```
理解这张图，就理解了整篇文章的拓扑基础。值得强调的是 **NWu** 这条参考点——它承载了全部三层封装：IPsec（外）、EAP-5G（中）、5G NAS（内）。
### 表 1：非 3GPP 接入相关网元与参考点速查
| 网元/参考点 | 全称 | 作用 | 规范出处 |
|---|---|---|---|
| N3IWF | Non-3GPP InterWorking Function | 非信任接入网关，终结 IPsec，对外呈现 N2/N3 | TS 23.501 §4.4.7 |
| TNGF | Trusted Non-3GPP Gateway Function | 受信任接入网关（运营商自管 Wi-Fi） | TS 23.501 §4.4.6 |
| TWIF | Trusted WLAN Interworking Function | 受信任 WLAN 互操作（多用于非信任接入到 5GC 的 5GC-only 场景） | TS 23.501 §4.4.8 |
| NWu | UE ↔ N3IWF | IKEv2/IPsec 隧道，承载 NAS 与用户面 | TS 23.501 §4.4.10 |
| Y2 | UE ↔ TNGF | TNGF 侧的接入参考点 | TS 23.501 |
| N2 (N3IWF 侧) | N3IWF ↔ AMF | NGAP，等同 gNB 的 N2 | TS 38.413 |
| N3 (N3IWF 侧) | N3IWF ↔ UPF | GTP-U，等同 gNB 的 N3 | TS 29.281 |
---
## 二、注册全流程总览：四个阶段
把非信任非 3GPP 注册拆成四个连续阶段，整个流程的脉络就清晰了：
1. **阶段 0 — IP 连通获取**：UE 先经 Wi-Fi/有线 DHCP 拿到一个普通 IP，此时它与 N3IWF 之间只是"互联网上的两台主机"。UE 通过预置的 N3IWF FQDN 或 IP（USIM/ME provisioning，或 DNS 解析）定位到 N3IWF。
2. **阶段 1 — IKEv2/IPsec 隧道建立（IKE_SA_INIT + IKE_AUTH）**：UE 与 N3IWF 协商出 IKE SA。
3. **阶段 2 — EAP-5G 承载 5G NAS 注册**：在 IKE_AUTH 里嵌入 EAP-5G，把 `Registration Request` 当作 EAP 载荷送到 AMF。
4. **阶段 3 — 主认证 + 密钥派生 + 注册接受 + CHILD SA 建立**：5G-AKA 在 EAP-5G 内完成，派生出 IPsec 密钥，注册成功后建立"信令 CHILD SA"，并为后续 PDU 会话建立"用户面 CHILD SA"。
下面这张总信令时序图把四阶段串起来（精简了部分二次握手细节）：
```mermaid
sequenceDiagram
autonumber
participant UE
participant N3IWF
participant AMF
participant AUSF
participant UDM
Note over UE: 阶段0: DHCP 获取 IP, 解析 N3IWF FQDN
UE->>N3IWF: IKE_SA_INIT (SAi, KEi, Ni)
N3IWF-->>UE: IKE_SA_INIT (SAr, KEr, Nr)
Note over UE,N3IWF: 阶段1: 进入 IKE_AUTH, 启动 EAP-5G
UE->>N3IWF: IKE_AUTH (IDi, SAi, 无 AUTH → 触发 EAP)
N3IWF-->>UE: EAP-Request / Identity
UE->>N3IWF: EAP-Response / Identity
N3IWF-->>UE: EAP-Request / EAP-5G (EAP-5G Start)
UE->>N3IWF: EAP-Response / EAP-5G (AN-Params + NAS Reg Request)
Note over N3IWF: 解析 AN-Params 做 AMF 选择
N3IWF->>AMF: NGAP Initial UE Message (含 NAS Reg Request)
AMF->>AUSF: Nausf_UEAuthentication (SUCI)
AUSF->>UDM: Nudm_UEAuthentication Get
UDM-->>AUSF: 认证向量 (RAND/AUTN/.../KAUSF)
AUSF-->>AMF: 认证向量
AMF->>N3IWF: NGAP DL NAS Transport (Authentication Request)
N3IWF-->>UE: EAP-Request / EAP-5G (NAS: Authentication Request)
UE->>N3IWF: EAP-Response / EAP-5G (NAS: Authentication Response/RES*)
N3IWF->>AMF: NGAP UL NAS Transport (Authentication Response)
Note over AMF,AUSF: 5G-AKA 第二确认 (MAC 校验 + RES* 比对)
AMF->>N3IWF: NGAP DL NAS (Security Mode Command)
N3IWF-->>UE: EAP-5G (NAS: SMC)
UE->>N3IWF: EAP-5G (NAS: SMC Complete)
AMF->>N3IWF: NGAP DL NAS (Registration Accept)
N3IWF-->>UE: EAP-5G (NAS: Registration Accept)
AMF->>N3IWF: NGAP: 下发 N3IWF 密钥材料(派生自 MSK)
N3IWF-->>UE: IKE_AUTH (AUTH, SAr2, TSi/TSr) + EAP-Success
Note over UE,N3IWF: 阶段4: IKE SA + 信令 CHILD SA 完成 → UE 已注册
```
---
## 三、阶段 1：IKEv2/IPsec 隧道的建立（NWu 的"地基"）
### 3.1 IKE_SA_INIT：先协商一条"裸的"安全通道
UE 首先发起 `IKE_SA_INIT`，与 N3IWF 交换：
- **SAi/SAr**：协商 IKE SA 的加密/完整性算法（如 AES-GCM、SHA-256）；
- **KEi/KEr**：Diffie-Hellman 公钥，用于后续派生共享密钥；
- **Ni/Nr**：随机数 Nonce。
注意：此时 `IKE_SA_INIT` **只生成一个匿名通道**，双方还没有验证彼此身份——这很像普通 VPN 的第一阶段。差异在于：身份认证不靠 N3IWF 证书，而是**借力 5G 主认证生成的 MSK**（见第六节）。N3IWF 证书主要用于 IKEv2 的服务器认证（Server Auth），让 UE 确认自己连的是"运营商认可的 N3IWF"，防止伪基站式的中间人。
### 3.2 IKE_AUTH 与 EAP 的衔接
进入 `IKE_AUTH` 时，UE 发送 `IDi`、`SAi`（CHILD SA 提议）但**不带 AUTH**（或带占位），明确表示"我要走 EAP 认证"。N3IWF 随即以 **EAP authenticator** 身份启动 EAP 流程，EAP-5G 就是在此刻登场。
一个实战要点：**IKEv2 通常走 UDP 500，一旦检测到 NAT（家庭/公共 Wi-Fi 几乎必有 NAT）会回退到 UDP 4500（NAT-T）**，后续 ESP 也封装在 UDP 4500 里。抓包时若只过滤 UDP 500，会漏掉 NAT-T 之后的全部流量——这是排错常踩的坑。
---
## 四、阶段 2：EAP-5G——把"空口 NAS"塞进 EAP 的精巧设计
这是整个流程最值得品味的部分。在 3GPP 接入里，UE 的 `Registration Request` 是经 RRC、NGAP（Initial UE Message）一路送到 AMF 的；RRC 还顺带捎带"接入网参数"（如 Selected PLMN）。而到了非 3GPP，UE 与 N3IWF 之间没有 RRC，只有 IKEv2——于是 3GPP 在 **TS 24.502** 中专门定义了 **EAP-5G**，用它同时承载两类信息：
- **AN-Parameters（接入网参数）**：相当于 RRC 在 Initial UE Message 里携带的那部分（GUAMI、Requested NSSAI、5G-GUTI、Selected PLMN 等），供 N3IWF 做 **AMF 选择**；
- **NAS-5G Message**：完整的 5G NAS 消息（如 Registration Request）。
### 4.1 EAP-5G 消息结构
EAP-5G 是一个自定义的 EAP Method（EAP Type = EAP-5G），其载荷结构如下：
```mermaid
flowchart TB
subgraph EAP["EAP-5G PDU（封装在 IKE_AUTH 的 EAP 载荷里）"]
direction TB
H["EAP Header
Code/Identifier/Length/Type"]
T["EAP-5G Message Type
① Start ② NAS/AN-Params ③ Result"]
L["EAP-5G Message Length"]
B["EAP-5G Message Body（可被分段为多条 EAP-5G）"]
end
B --> A1["AN-Parameters（TLV 列表）
GUAMI / Requested NSSAI / 5G-GUTI / Selected PLMN"]
B --> A2["NAS-5G Message
Registration Request / Auth Request ..."]
```
### 表 2：EAP-5G 关键 AN-Parameters（TS 24.502 §A.x）
| AN-Parameter | 作用 | 用途 |
|---|---|---|
| GUAMI | 网关 AMF 标识 | N3IWF 据此路由到原 AMF（注册更新场景） |
| 5G-GUTI | 临时用户标识 | 隐式标识 UE，避免每次都解析 SUCI |
| Requested NSSAI | UE 请求的切片 | AMF/NSSF 切片选择输入 |
| Selected PLMN | UE 选定的 PLMN | N3IWF/AMF 选择与归属判断 |
### 4.2 AMF 选择：N3IWF 的"路由判断"
收到 `EAP-Response / EAP-5G` 后，N3IWF 提取 AN-Parameters，按 **TS 23.502** 的 AMF 选择规则（GUAMI 命中 → 否则按 PLMN/切片 → 否则默认 AMF Set）选一个 AMF，随后构造 **NGAP `Initial UE Message`**——这一步和 gNB 收到 RRC `SetupRequest` 后给 AMF 发 `Initial UE Message` **完全同构**。N3IWF 在 NGAP 里还会带上自己的"无线能力"等价信息（如 UE 的 N3IWF 接入能力），让 AMF 觉得对面就是个普通的接入节点。
### 4.3 EAP-5G 的 NAS 分段机制（实战易错点）
5G NAS 消息（尤其带 SUCI 公钥加密、切片信息的 Registration Request）可能很大，而单条 EAP-5G 载荷有长度上限。**TS 24.502 规定 EAP-5G 可对 NAS 消息做分段**，用 Message Type/Length 配合多条 EAP-5G 拼装。配合 IKEv2 自身的 **IKE Fragmentation（RFC 7383）**，大 NAS 报文才能在 UDP 之上可靠传输。排错时如果看到 EAP-5G 交互突然"卡住"，往往要查 IKE 分段协商是否被禁用——这是企业 Wi-Fi 禁掉 IKE Fragmentation 导致注册失败的经典故障。
---
## 五、阶段 3：隧道内的 5G-AKA 主认证与密钥派生
身份认证本身走标准 5G-AKA（与 3GPP 接入完全一致，详见 **TS 33.501**），差别只在"传输管道"：3GPP 接入里 Authentication Request/Response 走 NAS over RRC/NGAP；非 3GPP 接入里它们被 EAP-5G 包裹后再被 IPsec 包裹。
### 5.1 双确认机制（与 3GPP 接入一致）
- AMF 经 AUSF 向 UDM/ARPF 取认证向量；
- UDM 用 K（USIM 根密钥）算出 RAND/AUTN/KAUSF，经 AUSF 透传给 AMF；
- UE 用 K 验证 AUTN（网络对 UE 的认证），回 RES*；
- AMF/AUSF 比对 RES* 与 XRES*（UE 对网络的认证）。
### 5.2 密钥如何"绑定"到 IPsec 隧道
这是非 3GPP 接入最精妙的设计：**IPsec 隧道的密钥不是 N3IWF 独立生成的，而是从主认证结果 MSK 派生出来的**。密钥层级如下：
```mermaid
flowchart TD
K["K（UE USIM ↔ UDM/ARPF 根密钥）"] --> CKIK["CK / IK（认证中间结果）"]
CKIK --> KAUSF["KAUSF"]
KAUSF --> MSK["MSK 主会话密钥（256-bit）"]
MSK -. "AMF 经 N2 下发" .-> N3IWF["N3IWF 持有 MSK"]
MSK --> SKEYSEED["SKEYSEED（IKEv2 AUTH 计算）"]
SKEYSEED --> SK["SK_d / SK_ai / SK_ar / SK_ei / SK_er"]
SK --> CHILD["IPsec CHILD SA 密钥"]
CHILD --> ESP["ESP 加密/完整性密钥
（信令 CHILD SA + 每个PDU会话用户面 CHILD SA）"]
```
**设计意图极其关键**：因为 MSK 只有在 5G-AKA 成功后才存在，所以 IKE_AUTH 的 AUTH 值、CHILD SA 的密钥全部"挂靠"在用户真实身份认证之上。这意味着——**没有合法 USIM、没有通过主认证，IPsec 隧道根本建不起来**。N3IWF 不需要持有用户的长期密钥 K，它只从 AMF 拿到派生好的 MSK，既保证了隧道与身份的强绑定，又避免了根密钥扩散到边缘网元（最小化密钥暴露面）。
---
## 六、阶段 4：注册完成与用户面 CHILD SA（PDU 会话）
注册接受后，AMF 通过 N2 把 MSK 派生材料发给 N3IWF，N3IWF 回送 `IKE_AUTH` 的 `AUTH`、`SAr2`、`TSi/TSr` 并以 **EAP-Success** 收尾——此时 **IKE SA 与一条"信令 CHILD SA"** 建立，UE 正式注册成功。
随后 UE 建立 PDU 会话时，用户面走的是 **N3IWF 上的 N3（GTP-U）↔ NWu（IPsec+GRE）** 翻译：
- **N3IWF ↔ UPF**：标准 GTP-U，QFI 在 GTP-U 扩展头；
- **UE ↔ N3IWF**：IPsec ESP 内承载 **GRE**，QFI 放在 **GRE 扩展头**里（TS 24.502 / TS 29.281）。N3IWF 负责两边 QFI 的对应与转发。
每个 PDU 会话的用户面会建立**独立的 IPsec CHILD SA**（部分实现按 QoS Flow 拆分），这就是为什么非 3GPP 接入的 IPsec CHILD SA 数量会随 PDU 会话/QoS 流线性增长——这也是 N3IWF 性能瓶颈的常见来源。
```mermaid
stateDiagram-v2
[*] --> WiFiIP: DHCP 获取 IP 连通
WiFiIP --> IKEInit: IKE_SA_INIT
IKEInit --> IKEAuth: IKE_AUTH + EAP-5G 启动
IKEAuth --> PrimaryAuth: 5G-AKA / EAP-AKA' 主认证
PrimaryAuth --> RegAccept: Registration Accept + EAP-Success
RegAccept --> TunnelUp: 信令 CHILD SA 建立
TunnelUp --> Registered: UE 注册完成（RM-REGISTERED）
Registered --> PDUSession: 用户面 CHILD SA + GRE/QFI
```
---
## 七、设计意图复盘：为什么不直接 TLS/NAS？
| 设计选择 | 为什么这样设计 |
|---|---|
| 用 IKEv2/IPsec 而非 TLS | IPsec 工作在 L3，可同时保护控制面（NAS）与用户面（PDU），且对 NAT 友好（NAT-T）；TLS 只能保护单条 TCP 流，无法承载全部业务面 |
| 用 EAP-5G 自定义 Method | UE↔N3IWF 没有 RRC，需一个"通用管道"既带 AN 参数又带 NAS；EAP 框架天然适合做 IKEv2 的认证扩展，复用成熟协议栈 |
| N3IWF 暴露 N2/N3（模拟 gNB） | 复用 5GC 全部接入无关逻辑，AMF/SMF 无需为非 3GPP 写特殊分支 |
| 密钥派生自 MSK | 把隧道与用户身份强绑定，根密钥 K 不出核心网，N3IWF 无需持有长期密钥 |
| 用户面用 GRE 带 QFI | 在 IPsec 内复用 5G QoS 标识，N3IWF 与 UPF 两侧 QFI 透明映射，QoS Flow 在非 3GPP 接入上等价可用 |
---
## 八、抓包识别与排错实战
### 8.1 抓包如何识别该流程
1. **过滤 UDP 500/4500**：先看 `ISAKMP`（IKEv2）报文，`IKE_SA_INIT` → `IKE_AUTH`；
2. **定位 EAP-5G**：在 `IKE_AUTH` 的 `SK` 载荷内展开 EAP，EAP Method Type 即 EAP-5G，其中能看到 AN-Parameters（GUAMI/NSSAI）与 NAS 消息；
3. **看 NGAP**：N3IWF↔AMF 的 `Initial UE Message` 内含 `NAS-PDU`，与 EAP-5G 里的 NAS 内容一一对应；
4. **看 GTP-U**：注册后 N3IWF↔UPF 出现 N3 GTP-U，UE↔N3IWF 出现 ESP（UDP 4500 封装）+ GRE。
### 表 3：3GPP 接入 vs 非信任非 3GPP 接入注册对比
| 维度 | 3GPP 接入（NR） | 非信任非 3GPP 接入（N3IWF） |
|---|---|---|
| 接入安全 | RRC/UP/CP AS 安全 | IKEv2/IPsec（NWu） |
| NAS 承载 | RRC + NGAP | EAP-5G + IKEv2 |
| 接入网参数传递 | RRC Setup/Initial UE Message | EAP-5G AN-Parameters |
| AMF 选择发起者 | gNB | N3IWF |
| 主认证 | 5G-AKA / EAP-AKA′（同） | 5G-AKA / EAP-AKA′（同） |
| 用户面封装 | SDAP/PDCP/RLC/MAC | IPsec ESP + GRE（带 QFI） |
| 端口 | N/A（空口） | UDP 500/4500 |
### 表 4：常见故障点与排查思路
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| IKEv2 协商失败 | N3IWF 证书不受信/算法不匹配 | 检查 UE 信任的 N3IWF 证书、SA 算法提议 |
| 卡在 EAP-5G，NAS 未送达 AMF | IKE Fragmentation 被网络禁用、分段丢包 | 抓包看 IKE Notify `FRAGMENTATION_SUPPORTED`，开启 IKE 分段 |
| AMF 选择失败、寻呼不到 | AN-Parameters 缺失/GUAMI 路由错 | 核对 N3IWF 解析出的 GUAMI、PLMN 是否正确 |
| 注册成功但 PDU 不通 | GRE/QFI 映射错、CHILD SA 未建立 | 检查用户面 CHILD SA 协商、GTP-U TEID 对应 |
| MTU 黑洞、大包丢弃 | ESP+GRE+UDP 开销导致超 MTU | 启用 IKEv2/路径 MTU 发现，调整 MSS |
---
## 常见问题
**Q1: EAP-5G 和 EAP-AKA′ 有什么区别？**
A: 二者层次不同。**EAP-AKA′ 是一种主认证方法**（与 5G-AKA 二选一，由 UE 能力和网络决定），直接对用户身份做认证并产出密钥；**EAP-5G 是一个"传输管道"**（EAP Method），把任意 5G NAS 消息（含 5G-AKA 或 EAP-AKA′ 的报文）封装进 IKEv2。换句话说：非 3GPP 接入里，**EAP-5G 是信封，5G-AKA/EAP-AKA′ 才是信里的认证逻辑**。
**Q2: 为什么不用 TLS 直接跑 NAS，而要套 IKEv2/IPsec？**
A: TLS 只保护单条 TCP 流，无法承载用户面（UDP/RTP 数据）。IPsec 工作在 L3，可一条隧道同时保护控制面与用户面，且对 NAT 友好（NAT-T）。5G 需要在一条 NWu 隧道里同时跑 NAS 与 PDU 数据，IPsec 是更自然的选择。
**Q3: N3IWF 是不是就是一个 VPN 网关？**
A: 从网络位置看是的——它就是"5G 专用 VPN 网关"。但关键差异：VPN 网关的认证与隧道密钥通常是独立的（如预共享密钥/证书），而 **N3IWF 的隧道密钥派生自 5G 主认证的 MSK**，隧道与用户身份强绑定；且它对外暴露 N2/N3，向 5GC 伪装成 gNB，这是普通 VPN 网关不具备的。
**Q4: 非信任接入下，N3IWF 持有用户的根密钥 K 吗？**
A: 不持有。这是最小化密钥暴露面的设计。K 始终只在 USIM 与 UDM/ARPF；N3IWF 只从 AMF 拿到主认证派生的 MSK 及其衍生密钥，足以验证 IKEv2 AUTH 与建立 CHILD SA，但无法反推 K。
**Q5: 同一 UE 能否同时经 3GPP 和非 3GPP 注册？**
A: 可以，这就是 ATSSS 场景。UE 经 5G NR 走一条 N1，经 Wi-Fi/N3IWF 走另一条 N1，最终在 UPF 汇聚，由 SMF/UPF/PCF 按 Steering/Switching/Splitting 策略分流，提升带宽与可靠性。
---
## 参考来源
1. [3GPP TS 23.502 V19.x — Procedures for the 5G System, §4.12.2.2 Registration for untrusted non-3GPP access](https://www.3gpp.org/dynareport/23502.htm) — 注册主流程规范出处
2. [3GPP TS 33.501 — Security architecture of the 5G system](https://www.3gpp.org/dynareport/33501.htm) — EAP-5G、IKEv2、MSK 密钥派生安全机制
3. [3GPP TS 24.502 — Access to the 3GPP 5G Core via non-3GPP access networks](https://www.3gpp.org/dynareport/24502.htm) — EAP-5G 消息结构、AN-Parameters、GRE/QFI 用户面封装
4. [free-ran-ue 5G Core Book, Chapter 7: Non-3GPP Access](https://free-ran-ue.github.io/doc-5g-core-book/en/part2-free5gc/chapter7/) — TNGF/N3IWF 两层保护模型与实战说明
5. [DeepWiki: N3IWF (Non-3GPP Interworking Function) / GRE Tunnel Setup](https://deepwiki.com/free5gc/free5gc/6.1-n3iwf-(non-3gpp-interworking-function)) — N3IWF 与 UE 侧 IPsec/GRE 实现细节
6. [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/) — IKEv2 SA→EAP-5G→用户面 CHILD SA 流程解读
7. [YD/T 行业标准：5G 非 3GPP 接入网络技术要求（非受信接入）](https://hbba.sacinfo.org.cn/) — 国内对 IKEv2/IPSec+EAP-5G+5G-AKA 密钥派生的工程要求
---
> 本文由「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 等场景全覆盖。
