在5G网络中,UE接入网络首先要完成主认证(Primary Authentication)——即5G-AKA或EAP-AKA',建立SUPI与PLMN之间的信任关系。但这只是"你能入网",并不代表"你能用任何切片"。
某些垂直行业切片(如电力、车联网、工业控制)由第三方企业运营,这些企业拥有自己的用户数据库和认证系统。运营商无法判断某个UE是否有权接入该行业切片。3GPP从Rel-16开始引入NSSAA(Network Slice-Specific Authentication and Authorization)机制,允许第三方AAA服务器对UE进行独立的二次认证和授权。
核心设计原则(TS 33.501 Section 16.3):
┌───────────────────────────────────────────────────────┐
│ NSSAA在5G认证体系中的位置 │
│ │
│ Stage 1: 主认证 (5G-AKA / EAP-AKA') │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ UE │───▶│ SEAF│───▶│ AUSF│───▶│ UDM │ │
│ └─────┘ └─────┘ └─────┘ └─────┘ │
│ 验证: SUPI/USIM凭证 → 获得Allowed NSSAI │
│ │
│ Stage 2: NSSAA (EAP-based) │
│ ┌─────┐ ┌─────┐ ┌───────┐ ┌──────┐ │
│ │ UE │───▶│ AMF │───▶│NSSAAF │───▶│ AAA-S│ │
│ └─────┘ └─────┘ └───────┘ └──────┘ │
│ 验证: 企业级EAP凭证 → 获得切片接入授权 │
└───────────────────────────────────────────────────────┘
根据TS 23.502 Section 4.2.9.1,NSSAA在以下三种场景触发:
| 触发场景 | 描述 | 发起方 |
|---|---|---|
| 注册流程中 | UE注册时,Requested NSSAI中包含需要NSSAA的S-NSSAI | AMF触发 |
| 订阅变更 | UDM通知AMF订阅数据变更,新的S-NSSAI需要NSSAA | AMF触发 |
| AAA-S发起重认证 | 第三方AAA服务器主动要求对已授权UE重新认证 | AAA-S触发 |
AMF在注册流程中(TS 23.502 Section 4.2.2.2.1, Step 21/25)进行以下判断:
检查UE能力:UE是否在UE 5GMM Core Network Capability中声明支持NSSAA
- 不支持 → 将该S-NSSAI放入Rejected NSSAI
- 支持 → 继续
检查订阅数据:从UDM获取的订阅信息中,S-NSSAI是否标记为"subject to NSSAA"
检查已有结果:UE Context中是否已有该S-NSSAI的成功NSSAA记录 - 已成功且有效 → 可跳过(基于网络策略) - 无记录或已过期 → 需要执行NSSAA
确定Pending NSSAI:将需要NSSAA的S-NSSAI放入Pending NSSAI,不放入Allowed NSSAI
关键博弈点:如果UE请求的所有S-NSSAI都需要NSSAA,AMF将返回空Allowed NSSAI + Pending NSSAI。此时UE已注册但"什么都做不了",必须等待NSSAA完成(TS 23.502 Section 4.2.2.2.1)。
┌──────────┐ Registration Request ┌─────┐
│ UE │─────────────────────────────▶│ AMF │
│ │ (Requested NSSAI: │ │
│ │ S-NSSAI-A, S-NSSAI-B) │ │
└──────────┘ └──┬──┘
│
┌──────────────────┤
▼ ▼
订阅数据查询 主认证(如需)
│ │
▼ ▼
┌─────────────────────────────┐
│ AMF 判断逻辑: │
│ S-NSSAI-A: 需要NSSAA │
│ S-NSSAI-B: 不需要NSSAA │
└──────────┬──────────────────┘
│
▼
Registration Accept
Allowed NSSAI: [S-NSSAI-B]
Pending NSSAI: [S-NSSAI-A]
NSSAA必须使用GPSI(Generic Public Subscription Identifier)而非SUPI。这是因为AAA-S通常由第三方运营,不应获得3GPP内部标识符SUPI。GPSI是面向外部的通用标识符(如External Identifier或MSISDN),适合跨域认证场景。
TS 23.502 Section 4.2.9.1明确规定:包含需要NSSAA的S-NSSAI的订阅,必须至少包含一个GPSI。
以下基于TS 23.502 Section 4.2.9.2和TS 33.501 Section 16.3,绘制完整的NSSAA EAP认证流程:
sequenceDiagram
participant UE
participant AMF
participant NSSAAF
participant AAA_P as AAA-P<br/>(可选)
participant AAA_S as AAA-S<br/>(第三方)
Note over UE,AAA_S: 阶段0: 注册流程已完成主认证, AMF已确定S-NSSAI需要NSSAA
rect rgb(230, 245, 255)
Note over UE,AMF: Step 1-3: EAP Identity交换
AMF->>UE: NAS MM Transport<br/>(EAP Identity Request, S-NSSAI)
UE->>AMF: NAS MM Transport<br/>(EAP Identity Response, S-NSSAI)
end
rect rgb(255, 245, 230)
Note over AMF,AAA_S: Step 4-6: 向AAA-S发起认证请求
AMF->>NSSAAF: Nnssaaf_NSSAA_Authenticate Request<br/>(EAP ID Response, GPSI, S-NSSAI)
NSSAAF->>AAA_P: AAA Protocol Message<br/>(EAP ID Response, GPSI, S-NSSAI/ENSI)
AAA_P->>AAA_S: AAA Protocol Message<br/>(EAP ID Response, GPSI, S-NSSAI/ENSI)
Note over AAA_S: AAA-S存储GPSI与EAP ID关联<br/>用于后续重认证/撤销
end
rect rgb(230, 255, 230)
Note over UE,AAA_S: Step 7-14: EAP消息多轮交互
loop EAP方法可能需要多轮交互
AAA_S->>AAA_P: EAP-Request/Challenge
AAA_P->>NSSAAF: EAP-Request/Challenge
NSSAAF->>AMF: Nnssaaf_NSSAA_Authenticate Response<br/>(EAP-Request/Challenge)
AMF->>UE: NAS MM Transport<br/>(EAP-Request/Challenge)
UE->>AMF: NAS MM Transport<br/>(EAP-Response)
AMF->>NSSAAF: Nnssaaf_NSSAA_Authenticate Request<br/>(EAP-Response, GPSI, S-NSSAI)
NSSAAF->>AAA_P: AAA Protocol (EAP-Response)
AAA_P->>AAA_S: AAA Protocol (EAP-Response)
end
end
rect rgb(255, 230, 230)
Note over UE,AAA_S: Step 15-18: 认证结果
AAA_S->>AAA_P: EAP-Success/Failure<br/>(GPSI, S-NSSAI)
AAA_P->>NSSAAF: AAA Protocol<br/>(EAP-Success/Failure, S-NSSAI, GPSI)
NSSAAF->>AMF: Nnssaaf_NSSAA_Authenticate Response<br/>(EAP-Success/Failure, S-NSSAI, GPSI)
AMF->>UE: NAS MM Transport<br/>(EAP-Success/Failure)
Note over AMF: AMF存储NSSAA结果到UE Context
end
rect rgb(240, 240, 255)
Note over UE,AMF: Step 19a: 更新Allowed NSSAI
AMF->>UE: UE Configuration Update<br/>(新Allowed NSSAI包含该S-NSSAI)
Note over UE,AMF: Step 19b: 若全部失败则执行Deregistration
end
NSSAA的EAP消息通过NAS MM Transport消息在UE和AMF之间传递。该消息类型专为NAS层透传上层协议数据设计。
| IE名称 | 方向 | 说明 |
|---|---|---|
| Payload Container Type | 双向 | 值为"N1 SM information"或"SMS"等,NSSAA中使用特定值标识EAP容器 |
| Payload Container | 双向 | 携带EAP消息体(EAP-Request/Response/Success/Failure) |
| S-NSSAI | AMF→UE | 标识本次NSSAA针对的切片(使用HPLMN S-NSSAI,非本地映射值) |
| EAP Message | 双向 | RFC 3748定义的EAP消息结构 |
根据TS 29.526 Section 5.2.2.2,NSSAAF暴露的SBI服务操作如下:
| 服务操作 | HTTP方法 | URI模式 | 请求参数 | 响应参数 |
|---|---|---|---|---|
| Authenticate | POST | /nnssaaf-nssaa/v1/slice-authentications |
SliceAuthInfo | SliceAuthContext |
| Authenticate(后续) | PUT | /nnssaaf-nssaa/v1/slice-authentications/{sliceAuthId}/confirm |
SliceAuthConfirmationData | SliceAuthConfirmationResponse |
| Re-AuthenticationNotification | POST | AMF回调URI | SliceAuthReauthNotification | - |
| RevocationNotification | POST | AMF回调URI | SliceAuthRevocNotification | - |
根据TS 29.526 Section 6.1.6.2.2:
| 字段名 | 类型 | 必选/可选 | 说明 |
|---|---|---|---|
| EapId | String (Binary) | 首次必选 | UE的EAP Identity(如NAI格式) |
| Gpsi | String | 必选 | UE的外部标识符 |
| SNssai | Snssai | 必选 | 需要NSSAA的切片标识 |
| EapMessage | String (Binary) | 后续必选 | 后续EAP消息 |
graph LR
subgraph "SliceAuthInfo (Request)"
A[EapId<br/>EAP Identity] --> B[Gpsi<br/>GPSI]
B --> C[SNssai<br/>S-NSSAI]
end
subgraph "SliceAuthContext (Response)"
D[SliceAuthId<br/>会话标识]
D --> E[EapMessage<br/>EAP消息]
end
subgraph "SliceAuthConfirmationData"
F[EapMessage<br/>UE的EAP响应]
F --> G[SliceAuthId<br/>会话标识]
end
NSSAAF负责将EAP消息路由到正确的AAA-S。路由规则(TS 33.501 Section 16.3):
stateDiagram-v2
[*] --> Requested: UE注册请求<br/>包含S-NSSAI
Requested --> Pending_NSSAI: AMF判定需要NSSAA<br/>放入Pending NSSAI
Pending_NSSAI --> NSSAA_InProgress: AMF发送EAP Identity Request
NSSAA_InProgress --> Allowed_NSSAI: NSSAA成功<br/>EAP-Success
NSSAA_InProgress --> Rejected_NSSAI: NSSAA失败<br/>EAP-Failure
Allowed_NSSAI --> NSSAA_InProgress: AAA-S触发重认证
Allowed_NSSAI --> Rejected_NSSAI: AAA-S触发授权撤销
Rejected_NSSAI --> NSSAA_InProgress: UE重新请求<br/>或订阅变更
Pending_NSSAI --> Deregistered: 所有S-NSSAI的NSSAA<br/>全部失败
当UE收到的Registration Accept中包含空Allowed NSSAI + Pending NSSAI时(TS 23.502 Section 4.2.2.2.1):
AMF为每个S-NSSAI维护NSSAA状态(TS 29.526):
| 状态值 | 含义 |
|---|---|
| SUCCESS | NSSAA成功,S-NSSAI可加入Allowed NSSAI |
| FAILURE | NSSAA失败,S-NSSAI加入Rejected NSSAI |
| ONGOING | NSSAA进行中 |
| NOT_PERFORMED | 尚未执行NSSAA |
注意(TS 23.502 Section 4.2.9.1 Note 2):如果S-NSSAI因NSAC(网络切片准入控制)被拒绝,不影响已存储的NSSAA结果状态。NSSAA成功≠切片一定可用,还需要通过容量准入。
AAA-S可在任何时候主动要求UE重新认证(TS 33.501 Section 16.4),这是NSSAA区别于主认证的重要特性——第三方企业可以在自己的策略下强制重认证。
sequenceDiagram
participant AAA_S as AAA-S
participant NSSAAF
participant UDM
participant AMF
participant UE
AAA_S->>NSSAAF: Re-Auth Request (GPSI, S-NSSAI)
NSSAAF->>UDM: Nudm_UECM_Get (GPSI, AMF Registration)
UDM->>NSSAAF: AMF ID
NSSAAF-->>AAA_S: ACK
NSSAAF->>AMF: Nnssaaf_NSSAA_Re-AuthenticationNotification<br/>(GPSI, S-NSSAI)
Note over AMF: 检查S-NSSAI是否在Allowed NSSAI中
AMF->>UE: 触发完整NSSAA流程<br/>(回到Section 16.3步骤)
关键步骤:
1. AAA-S发送Re-Auth Request,包含GPSI和S-NSSAI
2. NSSAAF通过UDM的Nudm_UECM_Get查询当前服务该UE的AMF
3. 如果UE在3GPP和非3GPP两个Access Type都注册了,NSSAAF可能收到两个AMF地址,需要决策通知哪一个
4. AMF收到通知后检查S-NSSAI是否在Allowed NSSAI中,是则触发完整NSSAA流程
授权撤销(TS 33.501 Section 16.5)比重认证更剧烈——直接从Allowed NSSAI中移除S-NSSAI:
| 撤销后的处理 | 条件 |
|---|---|
| 更新Allowed NSSAI(移除该S-NSSAI) | 至少还有一个S-NSSAI在Allowed NSSAI中 |
| 加入Default NSSAI | Allowed NSSAI变空但有Default NSSAI可用 |
| 执行Deregistration | Allowed NSSAI变空且无Default NSSAI可用 |
如果被撤销的S-NSSAI上还有PDU Session,AMF会主动发起PDU Session Release。
| 对比维度 | 主认证 (5G-AKA/EAP-AKA') | NSSAA |
|---|---|---|
| 规范定义 | TS 33.501 Section 6.1 | TS 33.501 Section 16.3 |
| 信令流程 | TS 23.502 Section 4.2.2.2 | TS 23.502 Section 4.2.9.2 |
| 凭证来源 | USIM (SUPI/K) | 企业自有 (EAP ID/企业密钥) |
| 认证服务器 | AUSF/UDM (PLMN内) | AAA-S (可第三方) |
| EAP角色 | SEAF=Authenticator, AUSF=EAP Server | AMF=Authenticator, AAA-S=EAP Server |
| 协议中继 | 无需 (AUSF直连) | NSSAAF+可选AAA-P |
| UE标识 | SUCI/SUPI | GPSI |
| 触发时机 | 注册流程中(首要) | 主认证成功后(次要) |
| 密钥产出 | KSEAF→NAS/AS密钥 | 无密钥产出(纯授权) |
| 重认证 | 网络发起(AMF/AUSF) | AAA-S发起 |
| 失败后果 | 注册被拒绝 | S-NSSAI被拒绝,不影响其他切片 |
关键差异:NSSAA不产生密钥材料。它只是授权决策,不参与5G安全密钥层级。NSSAA的保护依赖已建立的NAS安全上下文——所有EAP消息都在NAS安全通道内传输。
| 接口 | 协议 | 关键过滤条件 |
|---|---|---|
| UE↔AMF (N1) | NAS | nas.mm.msg_type == 0x77(DL NAS Transport) 或 0x78(UL NAS Transport),Payload Container中含EAP |
| AMF↔NSSAAF | HTTP/2 (SBI) | POST /nnssaaf-nssaa/v1/slice-authentications |
| NSSAAF↔AAA-S | RADIUS/Diameter | 含S-NSSAI和GPSI的认证请求 |
故障1:UE不支持NSSAA但请求了需要NSSAA的切片
现象:Registration Accept中该S-NSSAI出现在Rejected NSSAI中,而非Pending NSSAI。
根因:UE在UE 5GMM Core Network Capability中未声明NSSAA支持能力(TS 23.502 Section 4.2.2.2.1)。
故障2:NSSAA超时未完成
现象:UE收到空Allowed NSSAI和Pending NSSAI后一直等待,无法发起任何业务。
根因:AAA-S不可达或EAP交互超时。AMF会设置该S-NSSAI的NSSAA状态为NOT_PERFORMED(TS 33.501 Section 16.3 Step 15),下次注册时重新触发。
故障3:GPSI缺失
现象:AMF无法发起Nnssaaf_NSSAA_Authenticate Request。
根因:UDM订阅数据中未配置GPSI。NSSAA要求订阅至少包含一个GPSI(TS 23.502 Section 4.2.9.1)。
故障4:多Access Type场景下NSSAA重复执行
现象:UE在3GPP和非3GPP都注册时,同一S-NSSAI被执行了两次NSSAA。
根因:AMF未正确复用已有Access Type上的NSSAA结果。根据规范,AMF应基于网络策略跳过已成功的S-NSSAI的NSSAA。
NSSAA不是孤立运行的。在注册流程中,它与NSSF(Network Slice Selection Function)协作完成切片选择与授权的完整闭环:
注册请求(Requested NSSAI)
│
▼
┌─────────┐ N22 ┌──────┐
│ AMF │─────────▶│ NSSF │ ← 切片选择
└────┬────┘ └──────┘
│
▼
检查订阅数据(UDM)
哪些S-NSSAI需要NSSAA?
│
├── 不需要NSSAA → 直接入Allowed NSSAI
│
└── 需要NSSAA → 放入Pending NSSAI
│
▼
触发NSSAA流程
(AMF↔NSSAAF↔AAA-S)
│
┌─────────┼─────────┐
▼ ▼
NSSAA成功 NSSAA失败
加入Allowed 加入Rejected
NSSAI NSSAI
NSSF负责的是切片选择(Allowed NSSAI中哪些S-NSSAI适合当前TA),而NSSAA负责的是切片级认证授权(UE是否有权接入该切片)。两者是互补关系,NSSF的选择结果可能因为NSSAA失败而被修正。
在Release 18中,NSSAA相关机制有以下增强:
Partially Allowed NSSAI:支持在部分TAI区域内允许的切片,即使NSSAA已成功,切片也可能只在部分区域可用(TS 23.502 Section 4.2.2.2.1)
NSAG(Network Slice AS Group):引入NSAG信息,优化NSSAA结果在RAN侧的应用
Slice Usage Policy:AMF可下发切片使用策略,包括"按需切片"和"切片去注册不活动定时器"
Alternative S-NSSAI:当NSSAA失败的S-NSSAI有替代切片时,AMF可自动替换
Q1: NSSAA和主认证的EAP-AKA'有什么区别? A: 主认证的EAP-AKA'使用USIM上的3GPP凭证(SUPI/K),由PLMN内的AUSF/UDM执行,产生安全密钥。NSSAA使用企业自有凭证(如证书、用户名密码),由第三方AAA-S执行,不产生密钥材料。两者是完全独立的认证过程。
Q2: NSSAA失败后UE还能用其他切片吗? A: 可以。NSSAA是按S-NSSAI粒度执行的。某个S-NSSAI的NSSAA失败只影响该切片的接入,不影响其他已授权切片的使用。只有当所有S-NSSAI都因NSSAA失败(且无Default NSSAI)时,AMF才会执行Deregistration。
Q3: NSSAA使用什么EAP方法? A: 规范未强制特定EAP方法。实际部署中常见EAP-TLS(证书认证,适合物联网场景)和EAP-AKA(复用SIM卡凭证)。选择取决于AAA-S的能力和企业的安全策略。TS 33.501建议使用支持隐私保护的EAP方法。
Q4: UE在3GPP和非3GPP两个Access上都注册了,NSSAA需要执行两次吗? A: 不需要。AMF可基于UE Context判断某个S-NSSAI在另一个Access Type上已有成功的NSSAA记录,根据网络策略跳过重复执行(TS 23.502 Section 4.2.9.2 Step 1)。这是优化设计,避免不必要的认证交互。
Q5: AAA-S如何知道要重认证哪个UE?
A: AAA-S在首次NSSAA成功时存储了GPSI与EAP Identity的关联。当需要重认证时,AAA-S使用GPSI标识UE,NSSAAF通过Nudm_UECM_Get(GPSI)查询UDM获取当前服务该UE的AMF地址,然后通知AMF触发重认证。
本文由「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 等场景全覆盖。
