51学通信

深度解析 3GPP TS 23.501：5.30 Support for non-public networks (Part 2 - SNPN的互联与身份漫游)

22分钟阅读

本文技术原理深度参考了3GPP TS 23.501 V18.9.0 (2025-03) Release 18规范中，关于“5.30 Support for non-public networks”的核心章节，旨在为读者提供一个5G独立非公共网络（SNPN）如何实现与公共网络（PLMN）的互联互通，以及如何通过凭证持有者（Credentials Holder）机制实现灵活的跨组织身份漫游的全景视图。本文为系列解读的第二部分。

深度解析 3GPP TS 23.501：5.30 Support for non-public networks (Part 2 - SNPN的互联与身份漫游)

欢迎来到“解构5G核心网”系列的SNPN专题第二篇。在Part 1中，我们将SNPN描绘成一个与世隔绝的“独立王国”，它拥有自己的国民（UE）、护照（SUPI/USIM）、以及独立的边防和行政系统（5GC）。这套体系保证了极致的安全性与自主性。

然而，在万物互联的时代，绝对的孤立往往意味着效率的瓶颈。如果工厂里的工程师不能用专网手机拨打外部供应商的电话怎么办？如果出差在外的CEO无法远程接入工厂的生产监控系统怎么办？如果合作伙伴的设备需要进入工厂协同作业，难道每次都要换一张本厂的SIM卡吗？

今天，我们将深入探讨规范的5.30.2.7至5.30.2.9等核心章节，揭示SNPN如何打破“孤岛”困境，通过巧妙的架构设计，建立起通往外部世界的“安全桥梁”，并引入“身份联盟”的概念，实现灵活的跨组织身份漫游。

我们将继续**“CyberGear Factory”的场景，但主角变成了工厂的网络总监张工**，以及来自“国家工业互联网联盟（NIIA）”的一台访客AGV。我们将跟随他们的脚步，见证SNPN如何从一个“内循环”的王国，演变为一个“内外双循环”的、开放且安全的工业互联枢纽。

1. “孤岛”架桥：从SNPN访问PLMN服务 (5.30.2.7 Access to PLMN services via stand-alone non-public networks)

第一个核心挑战：如何让身处SNPN网络覆盖下的用户，能够安全、无缝地使用公共网络（PLMN）的服务？规范为此设计了一套精巧的“隧道之上再建隧道”的方案。

To access PLMN services, a UE in SNPN access mode that has successfully registered with an SNPN may perform another registration via the SNPN User Plane with a PLMN (using the credentials of that PLMN) following the same architectural principles as specified in clause 4.2.8… and the SNPN taking the role of “Untrusted non-3GPP access”.

1.1 核心思想：SNPN化身为“非可信接入”

这段原文的精髓在于，它巧妙地将一个已经建立的、安全的SNPN连接，“降维”成了一个供PLMN接入的“管道”。从PLMN的视角来看，整个SNPN网络（包括其RAN和UPF）就如同一个公共Wi-Fi或家庭宽带，被视为一个**“非可信的非3GPP接入网络”**。

这意味着：

  • 物理路径： UE访问PLMN服务的信令和数据，首先会通过SNPN的PDU会话传输。
  • 逻辑连接： 在这条SNPN的数据管道之上，UE会再建立一条端到端的、加密的IPsec隧道，直接连接到PLMN核心网的N3IWF（非3GPP互通功能）。
  • 双重身份： UE因此拥有了双重身份。它在SNPN中是一个正常注册的用户；同时，通过IPsec隧道，它又在PLMN的核心网中完成了第二次、独立的注册。

1.2 架构与流程解析

  1. 前提： UE（如张工的手机）首先必须成功注册在SNPN上，并建立一个能够访问外部互联网的PDU会话。这是后续所有操作的“底层物理链路”。
  2. PLMN N3IWF发现： UE通过DNS等机制，发现其归属PLMN的N3IWF的地址。
  3. IPsec隧道建立： UE通过SNPN的PDU会话，向PLMN的N3IWF发起IKEv2信令，建立一条安全的IPsec隧道。
  4. PLMN注册： 隧道建立后，UE的所有NAS信令（封装在IPsec隧道内）都被透明地传送到PLMN的N3IWF，再由N3IWF转发给PLMN的AMF。UE使用其PLMN的凭证（例如，eSIM中的另一个身份）完成在PLMN的注册。
  5. PLMN业务访问： 注册成功后，UE就可以在PLMN中建立PDU会话，访问公共网络的服务。此时，数据包会经过“两次封装”：先由应用数据封装成PLMN的GTP-U包，再封装进IPsec隧道，最后通过SNPN的GTP-U隧道传输。

1.3 场景代入：张工在厂区的“公网通话”

张工身处CyberGear工厂的无尘车间，这里只有SNPN的信号。他需要紧急联系一位设备供应商，而这位供应商只能通过普通手机号联系。

  1. SNPN连接： 张工的手机早已注册在工厂的SNPN上，并有一个访问外部网络的PDU会话。
  2. 触发PLMN接入： 他拨打供应商的电话，手机检测到这是一个需要通过PLMN IMS服务（VoNR）才能完成的呼叫。
  3. 建立“隧道中的隧道”：
    • 手机通过SNPN的数据连接，向其归属PLMN的N3IWF发起了IPsec隧道建立请求。
    • 隧道成功建立后，手机通过这条加密隧道，向PLMN的AMF发起了注册请求。
  4. VoNR呼叫建立： 在PLMN注册成功后，手机为IMS业务建立了一个新的PDU会话（或者使用已有的）。这个会话的所有数据，都被封装在IPsec隧道中，穿过SNPN的用户面，最终到达PLMN的核心网，完成了VoNR呼叫。

对于张工来说，他只是拨打了一个电话。但对于网络来说，这是一次复杂的、跨越私网和公网的“嵌套式”通信。

2. “反向穿梭”：从PLMN访问SNPN服务 (5.30.2.8 Access to stand-alone non-public network services via PLMN)

有了“走出去”的能力，自然也需要“请进来”的通道。当用户身处公共网络覆盖下，如何安全地访问SNPN内部的资源？规范定义了与上一节完全对称的反向流程。

To access SNPN services, a UE that has successfully registered with a PLMN over 3GPP access may perform another registration via the PLMN User Plane with an SNPN (using the credentials of that SNPN) following the same architectural principles as specified in clause 4.2.8… and the PLMN taking the role of “Untrusted non-3GPP access” of the SNPN…

2.1 核心思想：PLMN化身为“非可信接入”

这一次，角色发生了互换。从SNPN的视角来看，UE当前所在的、广阔的公共移动网络（PLMN）变成了一个提供基础IP连接的“管道”，被视为一个**“非可信的非3GPP接入网络”**。

UE同样需要通过PLMN提供的PDU会话，建立一条端到端的IPsec隧道，这次是连接到SNPN的N3IWF，然后在SNPN中完成注册和业务访问。

2.2 场景代入：张工的“远程运维”

张工出差在外，身处酒店，只有公共5G网络信号。他需要紧急登录工厂的生产监控系统，查看“AGV-007”的实时状态。

  1. PLMN连接： 他的手机已经注册在当地的PLMN上，并有一个访问互联网的PDU会话。
  2. 触发SNPN接入： 他打开了工厂的“Cyber-Ops”运维APP。APP被URSP规则配置为需要通过SNPN的特定DNN（internal.cybergear.com）来访问。
  3. 建立通往“家”的隧道：
    • 手机通过PLMN的数据连接，向CyberGear工厂SNPN的N3IWF（其地址可能通过DNS或在APP中预配）发起了IPsec隧道建立请求。
    • 隧道成功建立后，手机通过这条加密隧道，向SNPN的AMF发起了注册请求，使用的是他在工厂内部的员工凭证。
  4. 访问内部服务： 在SNPN注册成功后，手机为运维业务建立了一个PDU会话。现在，他可以安全地访问工厂内网，实时查看AGV-007的位置、电量和任务状态。

通过这种对称的“隧道”机制，5G网络打破了SNPN与PLMN之间的物理壁垒，实现了业务层面的双向互通，同时通过IPsec技术保证了端到端的安全性。

3. “身份联盟”：凭证持有者 (Credentials Holder) 概念 (5.30.2.9)

SNPN与PLMN的互通解决了“内外网”的问题，但还有一个更复杂的场景：如果多个独立的SNPN之间需要互信互认，该怎么办？这就是“凭证持有者”（CH, Credentials Holder）机制要解决的问题。

SNPNs may support UE access using credentials owned by a Credentials Holder separate from the SNPN. In this case the Session Management procedures (i.e. PDU Sessions) terminate in an SMF in the SNPN.

3.1 CH的核心价值：身份与服务解耦

CH机制的本质，是将**“提供身份凭证”和“提供网络服务”**这两个角色分离开来。

  • SNPN： 扮演服务提供者的角色，它提供无线接入和核心网服务。
  • Credentials Holder (CH): 扮演身份提供者的角色，它拥有用户的签约数据和鉴权密钥，负责对用户进行认证和授权。CH本身可以是一个PLMN运营商，也可以是另一个大型的SNPN，或者一个行业联盟的认证中心。

这就像您拿着A银行的银行卡（凭证），可以在B银行的ATM机（服务）上取款。B银行不负责您的身份验证，它只是将您的卡信息传递给A银行的系统去验证。

3.2 两种实现模型

规范为此定义了两种主要的实现架构：

3.2.1 AAA服务器模型 (Credentials Holder using AAA Server)

The AUSF and the UDM in SNPN may support primary authentication and authorization of UEs using credentials from a AAA Server in a Credentials Holder (CH)… The UDM then instructs the AUSF that primary authentication by a AAA Server in a CH is required, the AUSF shall discover and select the NSSAAF and then forward EAP messages to the NSSAAF.

流程简述：

  1. UE发起注册： 携带由CH颁发的SUCI。
  2. SNPN AMF → UDM: AMF将请求发给UDM。
  3. UDM决策： UDM根据SUCI的领域标识（realm），识别出这是一个需要由外部CH来认证的用户，于是指示AUSF启动外部认证流程。
  4. AUSF → NSSAAF → CH AAA: AUSF通过NSSAAF，将EAP认证消息中继到CH的AAA服务器。
  5. CH AAA完成认证： CH的AAA服务器完成对UE的认证，并将授权结果返回。

3.2.2 AUSF/UDM模型 (Credentials Holder using AUSF and UDM)

An SNPN may support primary authentication and authorization of UEs that use credentials from a Credentials Holder using AUSF and UDM. The Credentials Holder may be an SNPN or a PLMN. The Credentials Holder UDM provides to SNPN the subscription data.

这是更“5G原生”的模式。SNPN的AMF/AUSF可以直接通过标准的5G接口（如Nudm），与CH的UDM进行交互，获取用户的签约数据和鉴权向量，然后在SNPN内部完成认证过程。这种方式避免了对传统AAA协议的依赖，集成度更高。

3.3 场景代入：“联盟AGV”进入CyberGear工厂

“国家工业互联网联盟（NIIA）”作为一个Credentials Holder，为其所有成员单位的设备（如AGV）颁发了统一的USIM卡。

  1. 访客到达： 一台来自NIIA联盟伙伴的AGV，到达CyberGear工厂门口，需要进入厂区协同作业。
  2. 选择并注册： AGV的通信模块设置为SNPN模式，它发现了CyberGear的SNPN信号并发起了注册。其SUCI中包含了@nii-alliance.com这样的领域标识。
  3. SNPN的“委派认证”：
    • CyberGear的AMF收到了这个SUCI，并将其转发给自己的UDM。
    • UDM看到@nii-alliance.com这个不属于自己的realm，立即明白需要“委派”给NIIA进行认证。
    • 它指示AUSF启动外部认证。AUSF通过NSSAAF，将认证请求转发给了NIIA的AAA服务器。
  4. NIIA认证授权： NIIA的AAA服务器验证了这台AGV是其合法成员，并可能在授权信息中附带说明：“该AGV只允许访问CyberGear的‘访客卸货区’网络（特定DNN）”。
  5. 接入成功： 认证成功信息返回后，CyberGear的AMF为该AGV完成了注册。SMF在为其建立PDU会话时，根据NIIA返回的授权策略，只允许其访问“访客卸货区”的DNN。

通过CH机制，CyberGear无需为每一个临时的合作伙伴设备都制作一张新的SIM卡，极大地简化了跨企业协同的身份管理和接入控制流程。

5. FAQ

Q1: 在SNPN中访问PLMN服务，我的数据安全吗？

A: 是的，非常安全。这个过程的核心是端到端的IPsec隧道。虽然您的数据流物理上经过了SNPN的用户面（UPF），但它被完整地封装在一条从您的UE设备直接到PLMN的N3IWF之间的加密隧道中。SNPN网络本身无法解密或窥探其中的内容，它只扮演了一个“管道”的角色。这种架构确保了您在访问公共网络服务时，依然享有与直接连接PLMN同等级别的安全保障。

Q2: “非可信非3GPP接入”这个术语听起来不安全，为什么SNPN/PLMN互通要用这个模型？

A: 这是一个常见的误解。这里的“非可信”（Untrusted）是一个3GPP的技术术语，而不是对网络安全性的评价。它指的是，从发起连接的核心网（Overlay网络）的角度来看，它不信任底层为其提供IP连接的网络（Underlay网络）能够提供3GPP级别的安全保障。 正因为“不信任”，所以才必须在UE和核心网的入口（N3IWF）之间建立一条强大的、端到端的IPsec加密隧道，来构建一个独立的安全通道。所以，这个模型恰恰是为了在不依赖底层网络安全承诺的情况下，保证自身通信的绝对安全而设计的。

Q3: 凭证持有者（CH）和漫游（Roaming）有什么本质区别？

A: 虽然两者都实现了跨网接入，但它们的模型和目的不同。

  • 漫游（Roaming）： 是**对等网络（Peer Networks）**之间的协议，通常发生在公共运营商（PLMNs）之间。它基于标准的、复杂的漫游接口（如N27, N32）和协议，涉及信令和计费的清算。在漫游中，VPLMN会为用户提供全面的服务，并代表HPLMN进行大部分管理。
  • 凭证持有者（CH）： 是服务提供者与身份提供者分离的模型，主要用于SNPN场景。SNPN作为服务提供方，并不需要与CH建立复杂的漫游接口。它只是将认证请求“委派”给CH。CH的角色更像一个纯粹的“身份认证中心”，而不是一个提供全面网络服务的“对等运营商”。

简单来说，漫游是“两个国家的外交关系”，而CH是“拿着A公司的工卡去B公司上班，B公司门口的保安需要打电话给A公司确认你的身份”。

Q4: 在CH场景下，CyberGear工厂（SNPN）如何控制来访AGV的访问权限？

A: 认证和授权是分离的。虽然认证（确认“你是谁”）是由CH完成的，但授权（决定“你能做什么”）可以由SNPN和CH共同完成。

  1. CH下发授权策略： CH的AAA服务器在认证成功后，可以返回一系列授权属性给SNPN。例如，它可以明确指示：“该AGV只允许访问DNN为‘guest-area’的业务”。
  2. SNPN本地策略执行： CyberGear的SMF和PCF在收到这些授权属性后，会在本地执行这些策略。即使AGV尝试请求访问生产区的DNN，SMF也会根据策略予以拒绝。
  3. SNPN的补充策略： 即使CH没有下发精细的策略，SNPN也可以根据自己的本地策略，对所有来自外部CH的用户统一应用一套“访客权限”，例如，限制其带宽、禁止访问核心服务器等。

Q5: 如果我同时拥有PLMN和SNPN的签约，我的手机如何决定连接哪个网络？

A: 这取决于您手机的接入模式设置和网络选择优先级配置。

  • SNPN接入模式： 如果您将手机设置为“SNPN接入模式”，那么手机会优先扫描和连接您签约的SNPN。只有在找不到任何可用SNPN时，它才会去尝试连接PLMN。
  • PLMN模式： 如果您设置为普通的“PLMN模式”，那么手机会优先选择PLMN。
  • 手动选择： 您也可以随时进入手机的网络设置菜单，手动选择您希望连接的SNPN或PLMN。
  • 双连接能力（高级场景）： 规范在Annex D中也探讨了UE同时连接SNPN和PLMN的能力。在这种模式下，UE可以同时在两个网络注册，并根据URSP规则将不同的应用流量路由到不同的网络，但这需要更高级的终端和网络支持。

关系图谱