5G网络切片(Network Slicing)允许运营商在同一物理基础设施上为不同业务场景构建逻辑隔离的网络实例。标准5G-AKA主认证仅验证UE身份合法性,但无法判定UE是否有权接入某个特定切片。当切片由第三方(如企业、MVNO)运营时,切片拥有者需要独立的认证能力。
NSSAA(Network Slice-Specific Authentication and Authorization) 正是为解决这一问题而引入的机制,定义于3GPP Rel-16,核心规范分布在:
| 规范编号 | 涉及章节 | 内容 |
|---|---|---|
| TS 23.502 | Section 4.2.9 / 4.2.9.2 | NSSAA流程与重认证流程 |
| TS 23.501 | Section 5.15.9 | NSSAI与切片认证策略 |
| TS 33.501 | Section 13.x | NSSAA安全架构 |
| TS 29.526 | 全文 | Nnssaaf SBI接口Stage 3 |
| TS 24.501 | Section 4.4.6 | NAS层EAP消息传输 |
设计意图:主认证(5G-AKA/EAP-AKA')建立基础信任关系,NSSAA在此基础上为每个需要额外验证的S-NSSAI执行独立的EAP认证。这种分层认证架构实现了:
NSSAAF(Network Slice-Specific Authentication and Authorization Function)是Rel-16新增的核心网功能实体,作为PLMN与外部AAA服务器之间的EAP认证代理。
graph TB
UE["UE<br/>持有切片凭证"]
AMF["AMF<br/>EAP Authenticator角色<br/>触发NSSAA"]
NSSAAF["NSSAAF<br/>EAP代理/中继<br/>协议转换"]
AAA_P["AAA-P<br/>PLMN侧AAA代理"]
AAA_S["AAA-S<br/>切片方AAA服务器<br/>(可能第三方)"]
UDM["UDM<br/>签约数据<br/>NSSAA指示"]
NSSF["NSSF<br/>切片选择"]
UE -->|"N1 NAS<br/>(EAP容器)"| AMF
AMF -->|"Nnssaaf_NSSAA<br/>_Authenticate"| NSSAAF
NSSAAF -->|"SWa/STa<br/>(RADIUS/Diameter)"| AAA_P
AAA_P -->|"外部接口"| AAA_S
AMF -->|"Nudm_SDM_Get"| UDM
AMF -->|"Nnssf_NSSelection"| NSSF
style NSSAAF fill:#e1f5fe
style AAA_S fill:#fff3e0
style UE fill:#e8f5e9
| 接口 | 端点 | 协议 | 功能 |
|---|---|---|---|
| N1 | UE ↔ AMF | NAS (5GMM/5GSM) | 承载EAP消息的NAS传输容器 |
| Nnssaaf | AMF ↔ NSSAAF | SBI (HTTP/2) | Nnssaaf_NSSAA_Authenticate / Nnssaaf_NSSAA_Revoke |
| SWa | NSSAAF ↔ AAA-P | RADIUS/Diameter | 非可信非3GPP接入认证 |
| STa | NSSAAF ↔ AAA-P | Diameter | 可信非3GPP接入认证 |
| N33 | NSSAAF ↔ AAA-S | 外部协议 | 第三方AAA交互(通过AAA-P代理) |
| Nudm | AMF ↔ UDM | SBI | 获取切片签约数据中的NSSAA指示 |
AMF根据以下条件判定是否触发NSSAA(依据TS 23.501 Section 5.15.9.2):
条件1: UDM签约数据中该S-NSSAI标记了 "NSSAA Required"
条件2: 该S-NSSAI不在当前Allowed NSSAI中(尚未通过NSSAA)
条件3: 该S-NSSAI不在Pending NSSAI中(未正在进行NSSAA)
当三个条件同时满足时,AMF将该S-NSSAI放入Pending NSSAI列表,并启动NSSAA流程。
以下是TS 23.502 Section 4.2.9定义的完整NSSAA信令流,嵌入在初始注册流程中:
sequenceDiagram
participant UE
participant RAN
participant AMF
participant UDM
participant NSSAAF
participant AAA_P as AAA-P
participant AAA_S as AAA-S
Note over UE,AMF: 阶段1: 初始注册(主认证已完成)
UE->>RAN: Registration Request<br/>Requested NSSAI: [S-NSSAI-A, S-NSSAI-B]
RAN->>AMF: N2 Message + Registration Request
AMF->>UDM: Nudm_SDM_Get (SUPI)
UDM-->>AMF: 订阅数据<br/>S-NSSAI-A: NSSAA Required=True<br/>S-NSSAI-B: NSSAA Required=False
Note right of AMF: S-NSSAI-B → Allowed NSSAI<br/>S-NSSAI-A → Pending NSSAI<br/>触发NSSAA
AMF->>UE: Registration Accept<br/>Allowed NSSAI: [S-NSSAI-B]<br/>Pending NSSAI: [S-NSSAI-A]
Note over UE,AAA_S: 阶段2: NSSAA EAP认证交换
AMF->>UE: DL NAS Transport<br/>EAP-Request/Identity<br/>(针对S-NSSAI-A)
UE->>AMF: UL NAS Transport<br/>EAP-Response/Identity
AMF->>NSSAAF: POST /nnssaaf-nssaa/v1/{supi}/authenticate<br/>{snssai, eapPayload, aaaSelectionData}
NSSAAF->>AAA_P: AAA-Request (EAP-Response/Identity)
AAA_P->>AAA_S: 转发认证请求
AAA_S-->>AAA_P: AAA-Answer (EAP-Request/TLS-Start)
AAA_P-->>NSSAAF: AAA-Response
NSSAAF-->>AMF: 200 OK {eapPayload: EAP-Request/TLS-Start}
AMF->>UE: DL NAS Transport<br/>EAP-Request/TLS-Start
UE->>AMF: UL NAS Transport<br/>EAP-Response/TLS-ClientHello
rect rgb(255, 248, 225)
Note over UE,AAA_S: EAP-TLS握手(可能多轮)
AMF->>NSSAAF: POST .../authenticate {eapPayload}
NSSAAF->>AAA_P: AAA-Request
AAA_P->>AAA_S: 转发
AAA_S-->>AAA_P: AAA-Answer
AAA_P-->>NSSAAF: AAA-Response
NSSAAF-->>AMF: 200 OK {eapPayload}
AMF->>UE: DL NAS Transport (EAP消息)
UE->>AMF: UL NAS Transport (EAP消息)
end
Note over UE,AAA_S: 阶段3: 认证结果
AAA_S-->>AAA_P: AAA-Answer (EAP-Success + 授权数据)
AAA_P-->>NSSAAF: AAA-Response (EAP-Success)
NSSAAF-->>AMF: 200 OK {authResult: SUCCESS,<br/>snssai: S-NSSAI-A}
AMF->>UE: DL NAS Transport<br/>EAP-Success
Note right of AMF: S-NSSAI-A从Pending移至Allowed
AMF->>UE: Configuration Update Command<br/>Allowed NSSAI: [S-NSSAI-A, S-NSSAI-B]
| IE名称 | 长度 | 来源 | 说明 |
|---|---|---|---|
| Requested NSSAI | 可变 | UE | UE请求接入的切片列表,包含S-NSSAI-A等 |
| Network Slicing Indication | 1字节 | UE | 指示是否需要在注册中执行NSSAA |
| 5GS Registration Type | 4bit | UE | 初始注册/移动性更新/周期更新 |
| SUCI/SUPI | 可变 | UE | 用户标识(主认证使用) |
基于TS 29.526定义的SBI接口,AMF向NSSAAF发送的POST请求体结构:
| 字段 | 类型 | 必选 | 说明 |
|---|---|---|---|
| snssai | Snssai | 是 | 需要NSSAA的切片标识(SST+SD) |
| eapPayload | Bytes | 是 | UE发送的EAP-Response原始数据 |
| routingIndicator | String | 否 | SUPI中的路由指示符,用于AAA选择 |
| aaaSelectionData | Object | 否 | AAA服务器选择信息(地址/ID) |
| notificationUri | URI | 否 | 用于接收NSSAA状态变更通知的回调URI |
| notificationCorrelationId | String | 否 | 通知关联标识 |
| afId | String | 否 | 应用功能标识(当AF触发时使用) |
| 字段 | 类型 | 说明 |
|---|---|---|
| eapPayload | Bytes | 返回给UE的EAP-Request消息 |
| authResult | Enum | SUCCESS / FAILURE / ONGOING |
| snssai | Snssai | 认证结果对应的S-NSSAI |
| aaaFailureCause | Enum | AAA服务器失败原因(如可达性、超时等) |
NSSAA的EAP消息通过NAS层的5GMM Transport消息承载,而非使用专门的NAS消息类型:
| NAS消息 | 方向 | 承载的EAP IE |
|---|---|---|
| DL NAS Transport | 网络→UE | EAP-Request(含Slice标识) |
| UL NAS Transport | UE→网络 | EAP-Response |
关键约束:DL NAS Transport中的Payload Container Type必须设置为EAP消息类型,同时携带Payload Container(即EAP数据包)和关联的S-NSSAI信息。
以下展示EAP-TLS方法在NSSAA中的典型交互:
sequenceDiagram
participant UE
participant AMF
participant NSSAAF
participant AAA
AMF->>UE: EAP-Request/Identity
UE->>AMF: EAP-Response/Identity ([email protected])
Note over AMF: 转发至NSSAAF
AMF->>UE: EAP-Request/TLS (Start)
UE->>AMF: EAP-Response/TLS (ClientHello)
AMF->>UE: EAP-Request/TLS (ServerHello + Certificate + ServerKeyExchange + CertificateRequest)
UE->>AMF: EAP-Response/TLS (Certificate + ClientKeyExchange + CertificateVerify + ChangeCipherSpec + Finished)
AMF->>UE: EAP-Request/TLS (ChangeCipherSpec + Finished)
AMF->>UE: EAP-Success
Note over UE,AAA: 关键: UE和AAA双向证书认证<br/>TLS隧道保护后续数据
EAP-TLS交互要点: - UE需预配置切片特定X.509客户端证书 - AAA服务器持服务端证书,实现双向认证 - TLS版本要求≥1.2(推荐1.3) - 大证书可能导致EAP分片(MTU协商)
NSSAA涉及复杂的S-NSSAI状态管理,AMF需维护每个S-NSSAI的认证状态:
stateDiagram-v2
[*] --> Requested: UE在Registration Request<br/>中携带该S-NSSAI
Requested --> Pending: AMF判定需NSSAA<br/>且发起EAP认证
Requested --> Allowed: 签约数据中<br/>NSSAA Required=False
Pending --> Allowed: NSSAA成功<br/>EAP-Success
Pending --> Rejected: NSSAA失败<br/>EAP-Failure
Pending --> Pending: EAP多轮交换<br/>(authResult=ONGOING)
Allowed --> Pending_NSSAA: 重认证触发<br/>(定时器到期/AAA通知)
Pending_NSSAA --> Allowed: 重认证成功
Pending_NSSAA --> Revoked: 重认证失败
Revoked --> [*]: PDU Session释放
Rejected --> [*]: UE可重新请求
Allowed --> Revoked: AAA撤销通知<br/>(Nnssaaf_NSSAA_Revoke)
关键状态转换说明:
| 转换 | 触发条件 | AMF行为 |
|---|---|---|
| Requested→Pending | UDM指示NSSAA Required=True | 将S-NSSAI放入Pending NSSAI,在Reg Accept中通知UE |
| Pending→Allowed | 收到NSSAAF的SUCCESS响应 | 将S-NSSAI从Pending移至Allowed,触发UE Configuration Update |
| Pending→Rejected | 收到NSSAAF的FAILURE响应 | 通知UE该切片不可用,拒绝相关PDU Session请求 |
| Allowed→Revoked | 收到Nnssaaf_NSSAA_Revoke通知 | 释放关联PDU Session,从Allowed中移除 |
TS 23.502 Section 4.2.9.2定义了两个关键子流程。
当以下条件之一满足时触发重认证: - NSSAAF/AAA设置的认证定时器到期 - AAA服务器主动发起重新认证请求 - 切片授权策略变更
sequenceDiagram
participant AAA_S as AAA-S
participant NSSAAF
participant AMF
participant UE
Note over NSSAAF,AMF: 定时器到期或AAA触发
NSSAAF->>AMF: Nnssaaf_NSSAA_Authenticate<br/>通知(重认证触发)
AMF->>UE: DL NAS Transport<br/>EAP-Request/Identity (重认证)
UE->>AMF: UL NAS Transport<br/>EAP-Response/Identity
rect rgb(232, 245, 233)
Note over UE,AAA_S: EAP认证交换(同初始流程)
AMF->>NSSAAF: POST /authenticate
NSSAAF->>AAA_S: AAA-Request
AAA_S-->>NSSAAF: AAA-Answer
NSSAAF-->>AMF: 200 OK {eapPayload}
AMF->>UE: DL NAS Transport (EAP消息)
end
alt 重认证成功
AAA_S-->>NSSAAF: EAP-Success + 新授权数据
NSSAAF-->>AMF: authResult=SUCCESS
AMF->>UE: Configuration Update (维持Allowed NSSAI)
else 重认证失败
AAA_S-->>NSSAAF: EAP-Failure
NSSAAF-->>AMF: authResult=FAILURE
AMF->>UE: Configuration Update (从Allowed移除S-NSSAI)
Note right of AMF: 按TS 23.502 4.3.4<br/>释放关联PDU Session
end
授权撤销可由NSSAAF或AAA-S主动发起,无需UE参与:
| 步骤 | 动作 | 消息/接口 |
|---|---|---|
| 1 | AAA-S决定撤销某UE的切片权限 | AAA-S→AAA-P→NSSAAF |
| 2 | NSSAAF通知AMF | Nnssaaf_NSSAA_Revoke 通知 |
| 3 | AMF将S-NSSAI从Allowed移至Rejected | 内部状态更新 |
| 4 | AMF释放该切片上的所有PDU Session | 按4.3.4发起PDU Session Release |
| 5 | AMF通知UE | UE Configuration Update Command |
| 维度 | 5G-AKA主认证 | NSSAA切片认证 | EAP-AKA'(非3GPP) |
|---|---|---|---|
| 规范 | TS 33.501 Section 6.1 | TS 33.501 Section 13 | TS 33.501 Section 6.2 |
| 触发时机 | 注册流程开始时 | 主认证完成后 | 非可信WiFi接入时 |
| 认证粒度 | 每个SUPI | 每个S-NSSAI | 每个SUPI |
| 凭证类型 | USIM (K, OPc) | 切片特定(证书/预共享密钥) | USIM |
| EAP方法 | 无(原生AKA) | EAP-TLS/EAP-TTLS/EAP-AKA等 | EAP-AKA' |
| 认证方 | AUSF + UDM | NSSAAF + AAA-S | AUSF + UDM |
| 密钥推演 | K→CK/IK→KAUSF→KSEAF | 不影响5G密钥层级 | 独立密钥推演 |
| NAS保护 | 影响NAS安全上下文 | 不影响NAS安全 | 影响NAS安全 |
| UE端存储 | USIM | 切片凭证可存于USIM或ISIM | USIM |
关键区别:NSSAA的认证结果不参与5G密钥层级推演,仅决定UE是否能接入特定切片。这意味着NSSAA成功/失败不影响NAS信令加密和完整性保护,也不会改变AS层安全密钥。
URI: POST {apiRoot}/nnssaaf-nssaa/v1/{supi}/authenticate
请求体JSON结构示例:
{
"supportedFeatures": "ffff",
"snssai": {
"sst": 1,
"sd": "010203"
},
"sliceAuthData": {
"eapPayload": "0x01...(EAP-Response原始字节)",
"routingIndicator": "1234",
"aaaSelectionData": {
"aaaServerAddress": "aaa.enterprise.com",
"aaaProtocol": "DIAMETER"
}
},
"notificationUri": "https://amf.operator.com/nssaa-notify",
"notificationCorrelationId": "corr-id-20260602-001"
}
| authResult值 | 含义 | AMF处理 |
|---|---|---|
SUCCESS |
认证授权通过 | S-NSSAI从Pending移至Allowed |
FAILURE |
认证或授权失败 | S-NSSAI从Pending移至Rejected |
ONGOING |
认证进行中,需继续EAP交换 | 保持Pending状态,继续转发EAP |
当NSSAAF需要主动撤销切片授权时,向AMF发送通知:
URI: POST {notificationUri} (即AMF在初始请求中提供的notificationUri)
{
"report": {
"supi": "imsi-460001234567890",
"snssai": {"sst": 1, "sd": "010203"},
"authResult": "FAILURE",
"aaaFailureCause": "SUBSCRIPTION_EXPIRED"
}
| 过滤器 | 用途 |
|---|---|
nas-5gs.message_type == 110 |
DL NAS Transport(携带EAP-Request) |
nas-5gs.message_type == 111 |
UL NAS Transport(携带EAP-Response) |
nas-5gs.nssai |
查看NSSAI相关IE |
eap.type == 13 |
EAP-TLS类型包 |
eap.code == 1 |
EAP-Request |
eap.code == 2 |
EAP-Response |
json.path == "$.snssai" |
Nnssaaf SBI接口中的S-NSSAI |
http2.headers.path contains "nnssaaf" |
NSSAAF相关HTTP/2请求 |
场景1:Registration Accept中没有包含请求的S-NSSAI
排查路径:
1. 检查UDM签约数据中该S-NSSAI是否标记NSSAA Required
2. 确认AMF是否将S-NSSAI放入Pending NSSAI
3. 检查Registration Accept中是否有Pending NSSAI IE
4. 如无Pending NSSAI → AMF判定逻辑问题或UDM数据缺失
5. 如有Pending NSSAI → 检查后续EAP交换是否正常发起
场景2:EAP交换卡在某轮不继续
排查路径:
1. 抓取Nnssaaf接口HTTP/2消息,确认authResult是否为ONGOING
2. 检查NSSAAF→AAA-P的连通性(RADIUS/Diameter可达性)
3. 检查AAA-S是否可达(第三方服务器状态)
4. 查看AMF日志中EAP超时定时器配置(典型值30-60秒)
5. EAP分片场景下检查MTU设置是否合理
场景3:EAP-TLS证书验证失败
排查路径:
1. 确认UE切片证书的有效期(openssl x509 -checkend)
2. 检查证书链完整性(根CA + 中间CA + 终端证书)
3. 确认AAA-S信任的CA列表包含UE证书的签发CA
4. 检查CRL/OCSP可达性(证书吊销检查)
5. 确认TLS版本兼容性(UE和AAA-S支持的TLS版本交集)
Q1: NSSAA和主认证5G-AKA可以并行执行吗? A: 不可以。NSSAA必须在主认证成功完成之后才能触发。AMF先完成5G-AKA获取SUPI和NAS安全上下文,再从UDM获取签约数据判断哪些S-NSSAI需要NSSAA。只有已通过主认证的UE才能进入NSSAA流程。
Q2: 一个UE同时请求多个需要NSSAA的切片时如何处理? A: AMF对每个需要NSSAA的S-NSSAI独立执行NSSAA流程。多个S-NSSAI的NSSAA可以并行进行,每个切片对应独立的EAP会话和AAA交互。通过S-NSSAI字段区分不同的认证实例。
Q3: NSSAA失败后UE能否继续使用其他切片? A: 可以。NSSAA是按切片粒度执行的。某个S-NSSAI的NSSAA失败仅影响该切片的访问权限,不影响已通过认证的其他切片。UE仍可使用Allowed NSSAI中的其他切片建立PDU Session。
Q4: NSSAA的EAP消息为什么通过NAS Transport而不是专门的NAS消息承载? A: 这是设计上的有意选择。NAS Transport消息是通用的NAS容器,设计用于承载非NAS原生协议(如EAP)。NSSAA在Rel-16引入时,为避免新增NAS消息类型(这需要UE和网络的NAS协议栈同时升级),复用了已有的DL/UL NAS Transport机制,降低了实现复杂度。
Q5: 第三方切片运营商能否直接访问UE的SUPI等永久标识? A: 不能,这是NSSAA架构的安全设计要点。AAA-S仅能获取EAP-Identity(UE在EAP层提供的切片特定身份),无法获取SUPI。AMF和NSSAAF负责协议转换和身份映射,在PLMN信任边界处隔离了用户隐私信息。这种设计符合GDPR等隐私法规的要求。
本文由「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 等场景全覆盖。
