很多工程师把"VoNR注册"等同于"SIP REGISTER",这是一个常见的认知误区。真正要让一台5G终端能发起VoNR呼叫,必须先穿越三条相互独立又彼此咬合的信令链:5GS移动性注册、IMS专用PDU会话建立(含P-CSCF发现)、以及IMS域内的SIP注册与双向鉴权。任何一环失败,UE都会静默退化为EPS Fallback或干脆无法拨号。本文依据3GPP TS 23.501/23.502、TS 23.228、TS 24.229、TS 33.203、TS 29.228等规范,逐消息、逐IE地拆解这条三段链,重点剖析VoNR特有的P-CSCF发现机制与IMS AKA(即"SIP Digest with AKA")的鉴权向量推演。
VoLTE时代,UE通过一次Attach即建立IMS PDN连接,P-CSCF地址随默认承载的PCO下发,紧接着就发SIP REGISTER。5G SA中,控制面与用户面彻底解耦,5G注册(AMF/Registration Management)与会话管理(SMF/Session Management)被拆成两个独立过程;而IMS作为"数据网络(DN)"挂在5G核心网之上,又是一个独立的SIP应用域。因此VoNR的注册必然呈现三段结构:
IMS voice over PS session supported indication告诉UE"本区是否支持VoNR";PDU Session Establishment Accept中通过PCO把P-CSCF地址推给UE;flowchart TB
subgraph S1["第1段:5GS 移动性注册 (TS 23.502 §4.2)"]
A1["UE"] -->|"Registration Request"| A2["AMF"]
A2 -->|"5G-AKA 鉴权 / NAS SMC"| A1
A2 -->|"Registration Accept<br/>IMS voice over PS supported Indication"| A1
end
subgraph S2["第2段:IMS PDU会话 + P-CSCF发现 (TS 23.502 §4.3.2)"]
B1["UE"] -->|"PDU Session Est. Request<br/>DNN=IMS, S-NSSAI=切片X<br/>PCO: P-CSCF addr request"| B2["SMF"]
B2 -->|"N4 Session Est."| B3["UPF"]
B2 -->|"PDU Session Est. Accept<br/>PCO: P-CSCF address(es)"| B1
end
subgraph S3["第3段:SIP REGISTER + IMS AKA (TS 23.228 §5.3.2 / TS 33.203)"]
C1["UE"] -->|"REGISTER"| C2["P-CSCF"]
C2 --> C3["I-CSCF"] --> C4["S-CSCF"]
C4 -->|"Cx: UAR/MAR/SAR"| C5["HSS"]
end
S1 --> S2 --> S3
三段链之间存在严格的前置依赖:第1段的"IMS voice supported indication"若为"not supported",UE不会发起第2段(而是准备EPS Fallback);第2段拿不到P-CSCF地址,第3段的REGISTER就无处可发。下面分段拆解。
5G注册过程本身(TS 23.502 §4.2.2)不携带任何IMS信息,但它通过一个关键的5GMM IE决定了UE后续走向——IMS voice over PS session supported indication。该IE在REGISTRATION ACCEPT消息中下发(TS 24.501),取值含义如下表:
| 取值 | 含义 | UE后续动作 |
|---|---|---|
not supported |
当前注册区不支持IMS语音 over PS | 等待网络触发EPS Fallback |
supported |
支持VoNR(含NR语音) | 可建立IMS PDU会话发起VoNR |
supported over NR only |
仅NR支持,LTE不支持 | NR覆盖下走VoNR |
该指示由AMF根据TAI列表内所有TA的语音能力、NG-RAN上报的Voice over NR支持能力、以及运营商策略综合判定。若AMF判断当前区不支持VoNR但支持IMS语音(通过EPS),就会在未来呼叫时触发EPS Fallback流程(TS 23.502 §4.13.5)。因此,抓包看到Registration Accept中该IE=not supported,通常就是"打不了VoNR、只能回落4G"的根因。
此外,URSP规则(TS 23.501 §5.16.2)也会在注册阶段或UE配置更新阶段下发给UE,规则中包含一条"目的为IMS信令(按DNN=IMS、或SIP端口5060/5061匹配)的流量,路由到特定PDU会话"的描述。这条规则决定了UE后续会把SIP信令送往哪个本地PDU会话。
UE发起的PDU Session Establishment Request(TS 23.502 §4.3.2.2)中,针对IMS会话有几个"硬约束"IE:
P-CSCF是UE接入IMS的唯一入口。3GPP定义了三种发现方式(TS 23.228 §5.1、TS 23.501),VoNR中最常用的是第1种:
| 发现方式 | 触发时机 | 携带IE / 协议 | 地址形式 | 适用场景 |
|---|---|---|---|---|
| PCO方式(主用) | PDU会话建立过程中 | 5GSM Protocol Configuration Options,UE置"P-CSCF address request",SMF在Accept中回填 |
IP地址或FQDN列表 | VoNR/VoLTE标准方式,运营商首选 |
| DHCP方式 | PDU会话建立后 | DHCPv4 Option 120 / DHCPv6 Option 21、56、64 | FQDN,再经DNS解析 | 企业网、固移融合场景 |
| UE预配置 | 出厂/USIM配置 | 本地配置表 | IP或FQDN | 漫游、私有部署兜底 |
PCO方式的具体信令交互:UE在PDU Session Establishment Request的Protocol configuration options IE内携带"P-CSCF IPv4 Address Request"或"P-CSCF IPv6 Address Request"标志位(TS 24.501 §9.11.4.x)。SMF收到后,从UDM签约数据或本地DNN配置中取出候选P-CSCF地址列表(通常为多个,支持负载分担),在PDU Session Establishment Accept的同一PCO IE中回填一个或多个P-CSCF地址。UE若收到多个地址,随机/按规则选其一作为首个REGISTER的目的地址,其余作为备份。
sequenceDiagram
participant UE
participant AMF
participant SMF
participant UDM
participant UPF
UE->>AMF: PDU Session Est. Request (DNN=IMS, SSC1, PCO:P-CSCF req)
AMF->>SMF: Nsm PDUSession_CreateSMContext
SMF->>UDM: Nudm_SDM_Get (DNN签约, 取P-CSCF列表)
UDM-->>SMF: DNN subscription data
SMF->>UPF: N4 Session Establishment (QFI=5)
SMF-->>AMF: Nsm PDUSession_CreateSMContext Response (含P-CSCF列表)
AMF-->>UE: PDU Session Est. Accept (PCO: P-CSCF address(es), QoS QFI=5)
Note over UE: 选定一个P-CSCF,作为后续SIP REGISTER目的
设计意图:把P-CSCF发现嵌入会话建立过程,而非依赖独立的DHCP往返,是为了降低VoNR的"开机到可呼叫"时延(VoNR的会话建立时延指标比VoLTE更严苛)。同时由SMF集中决策P-CSCF分配,便于运营商做地理就近/负载均衡,并避免DHCP带来的额外故障点。
sequenceDiagram
participant UE
participant PCSCF as P-CSCF
participant ICSCF as I-CSCF
participant SCSCF as S-CSCF
participant HSS
UE->>PCSCF: REGISTER (无Authorization, public/private id)
PCSCF->>PCSCF: DNS解析Home Domain -> I-CSCF地址
PCSCF->>ICSCF: REGISTER (转发)
ICSCF->>HSS: Cx: UAR (Public/Private Identity)
HSS-->>ICSCF: Cx: UAA (S-CSCF能力集 / 已选S-CSCF)
ICSCF->>SCSCF: REGISTER (按能力选S-CSCF)
SCSCF->>HSS: Cx: MAR (请求Authentication Vector)
HSS-->>SCSCF: Cx: MAA (RAND, AUTN, XRES, CK, IK)
SCSCF-->>PCSCF: 401 Unauthorized<br/>(WWW-Authenticate: nonce=base64(RAND‖AUTN), algorithm=AKAv1-MD5) + CK/IK
Note over PCSCF: P-CSCF取出CK/IK作为IPsec SA密钥并删除
PCSCF-->>UE: 401 Unauthorized (已剥离CK/IK)
UE->>UE: ISIM用K计算 RES/CK/IK
UE->>PCSCF: REGISTER (Authorization: response=MD5 digest)
PCSCF->>ICSCF->>SCSCF: REGISTER (含response)
SCSCF->>SCSCF: 比对 response 与 XRES
SCSCF->>HSS: Cx: SAR (Server-Assignment, 下载用户profile)
HSS-->>SCSCF: Cx: SAA (iFC, 业务签约)
SCSCF-->>UE: 200 OK (注册成功)
Note over SCSCF: 按iFC触发Third-Party REGISTER -> AS
I-CSCF与S-CSCF和HSS之间的Cx接口基于Diameter协议(TS 29.228/29.229)。注册过程涉及三对请求/应答:
| Cx消息 | 全称 | 方向 | 关键AVP | 作用 |
|---|---|---|---|---|
| UAR/UAA | User-Authorization-Request/Answer | I-CSCF→HSS | Public Identity, Private Identity, Visited Network ID, Server-Name, Server-Capabilities | 授权用户注册,返回S-CSCF能力集或已选S-CSCF名 |
| MAR/MAA | Multimedia-Auth-Request/Answer | S-CSCF→HSS | Public/Private Identity, SIP-Authentication-Scheme("Digest-AKAv1-MD5"), SIP-Number-Auth-Items | 拉取若干个鉴权向量(AV),含RAND/AUTN/XRES/CK/IK |
| SAR/SAA | Server-Assignment-Request/Answer | S-CSCF→HSS | Public/Private Identity, Server-Name, Server-Assignment-Type(REGISTER), User-Data | 通知HSS"用户已注册到此S-CSCF",下载完整用户profile(含iFC) |
设计意图:UAR与MAR分离,是因为"谁能注册(授权)"与"如何鉴权(凭证)"是两个正交的决策——前者由I-CSCF主导(决定路由到哪个S-CSCF),后者由S-CSCF主导(决定挑战什么)。这种解耦让I-CSCF可以无状态化地做负载分担,而把密钥相关操作收敛到S-CSCF与HSS之间。
IMS AKA并非全新协议,而是把3G/5G的AKA挑战"塞进"SIP Digest的WWW-Authenticate/Authorization框架里。这就是为什么IE名里同时出现Digest和AKA。其鉴权向量(TS 33.203 §6.1,称为SD-AV——SIP Digest Authentication Vector)的内部结构如下:
flowchart TD
HSS["HSS / ISIM<br/>长期密钥 K, OPc"] --> AV["鉴权向量 AV (五元组)"]
AV --> R["RAND (128bit 随机挑战)"]
AV --> A["AUTN (128bit 网络认证令牌)"]
AV --> X["XRES (期望响应)"]
AV --> CK["CK (128bit 加密密钥)"]
AV --> IK["IK (128bit 完整性密钥)"]
R --> NONCE["nonce = base64(RAND ‖ AUTN ‖ ...)"]
A --> NONCE
NONCE --> WA["WWW-Authenticate<br/>algorithm=AKAv1-MD5, qop=auth-int"]
X --> S["S-CSCF: 用于校验UE响应"]
CK --> SA["P-CSCF: IPsec ESP 加密"]
IK --> SA
逐字段拆解UE侧响应计算(TS 33.203 §6.1.2, RFC 3310):
nonce中解析出RAND和AUTN;HA1 = MD5(username:realm:RES)(注意:传统Digest这里放密码,AKA放RES)
- response = MD5(HA1:nonce:nonce-count:cnonce:qop:MD5(method:uri))response放入第二次REGISTER的Authorization头发出;response(UE对网络侧的反向证明,因为只有持有K的UE才能算出正确RES)。这构成双向认证:AUTN验证"网络是真的",response验证"UE是真的"。
AKA产生的CK/IK并未浪费——它们被用来在UE与P-CSCF之间建立IPsec ESP安全联盟(TS 33.203 §6.3),保护后续所有SIP信令(Gm接口)的机密性与完整性。这是IMS安全与5G主认证的关键差异点:
flowchart TB
subgraph UE侧["UE / ISIM"]
UECK["CK (本地由K算出)"]
UEIK["IK (本地由K算出)"]
end
subgraph NET侧["S-CSCF → P-CSCF"]
NETCK["CK (来自HSS的AV)"]
NETIK["IK (来自HSS的AV)"]
NOTE["S-CSCF在401中携带CK/IK<br/>P-CSCF取出后删除, 不传给UE"]
end
UECK -.->|"IPsec ESP 加密 SPI=port_uc/port_ps"| NETCK
UEIK -.->|"IPsec ESP 完整性"| NETIK
SIP层通过三个安全头来协商SA参数:Security-Client(UE发送,含算法/端口)、Security-Server(P-CSCF发送,回应算法/端口)、Security-Verify(UE回显确认)。端口port_uc/port_us/port_pc/port_ps分别标识UE→P-CSCF和P-CSCF→UE的信令通道。抓包时,REGISTER成功后所有SIP信令都会"消失"为ESP加密流量——这是Gm安全生效的直接证据。
stateDiagram-v2
[*] --> NotRegistered
NotRegistered --> Registering: 发送REGISTER(第1次, 无response)
Registering --> Challenged: 收到401 Unauthorized
Challenged --> Registering: 发送REGISTER(第2次, 含response)
Registering --> Registered: 收到200 OK
Registered --> Registering: 重注册(T接近超时)
Registered --> NotRegistered: 网络注销 403/超时/去注册
NotRegistered --> [*]
UE维护一个注册定时器(通常为网络下发的expires值,约3600s),到期前会主动重注册。重注册时若使用同一安全联盟,可省略401挑战(网络直接200 OK),称为"重注册优化"。
完整的VoNR注册在抓包中跨越三个协议层,过滤技巧:
| 抓包阶段 | 协议 | 过滤器/识别点 |
|---|---|---|
| 5GS注册 | NGAP / 5G-NAS | nas_5gs.msg_type == 0x41(Registration Request) / 0x42(Accept);查IMS voice over PS supported indication |
| IMS PDU会话 | NGAP / 5GSM / PFCP | nas_5gs.msg_type == 0xc1(PDU Est. Request);展开PCO查"P-CSCF Address" |
| SIP注册 | SIP | sip.Method == "REGISTER";sip.Status-Code == 401(挑战)/ 200(成功);后续INVITE前应有ESP流量 |
IMS voice over PS supported indication = not supported。排查AMF的TA语音能力配置、NG-RAN是否上报Voice over NR supported。Q1: IMS AKA和5G主认证(5G-AKA)是什么关系? A: 二者完全独立。5G-AKA发生在UE与ARPF/UDM之间,保护5GS接入;IMS AKA发生在UE与IMS HSS之间,保护IMS域。两次AKA用的是不同的K(5G用USIM的K,IMS用ISIM的K),产生不同的密钥。这正是为什么SIM卡上要同时存在USIM和ISIM两个应用。
Q2: 为什么不用5G主认证的密钥直接保护IMS,要再来一次AKA? A: 因为IMS是"应用域",历史上先于5G存在(4G/LTE时代就成型),且要支持非3GPP接入(如WiFi通过ePDG/PDIF接入IMS)。IMS AKA让IMS安全自洽,不依赖底层接入技术,保证了跨接入的一致性。
Q3: P-CSCF为什么必须是UE第一个接触的IMS网元,不能让UE直接连S-CSCF? A: P-CSCF承担三重职责:①信任边界与拓扑隐藏;②UE与IMS之间IPsec SA的端点(持有CK/IK);③通过N5/Rx接口向5G PCF下发IMS专用QoS策略(如VoNR专用承载5QI=1)。直接连S-CSCF会暴露核心网拓扑且无法建SA。
Q4: SIP Digest里为什么用AKAv1-MD5而不是更新的算法?
A: algorithm=AKAv1-MD5(RFC 3310)是历史选择,把AKA结果嫁接到MD5 Digest框架。Rel-17起规范也支持AKAv2-MD5,但为兼容现网海量终端,多数运营商仍用v1。完整性由IPsec ESP(AES/理论更强算法)承担,而非依赖MD5本身。
Q5: VoNR注册成功后,PCF如何知道这是IMS会话并下发专用QoS?
A: P-CSCF在UE注册后,通过N5(或Rx)接口的Npcf_PolicyAuthorization服务向PCF上报IMS会话信息(包含媒体描述SDP)。PCF据此触发SM Policy Association Modification,让SMF建立5QI=1的GBR专用QoS Flow。这条"PCF感知"链是VoNR端到端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 等场景全覆盖。
