VoNR(Voice over New Radio)是5G SA网络中语音业务的终极形态。但一个UE要打出第一通VoNR电话,必须跨越两道门槛:5G网络注册和IMS域注册。前者解决"能否接入5G网络",后者解决"能否使用IMS语音服务"。两者之间还存在一个关键桥梁——IMS信令专用的PDU Session建立与P-CSCF发现。
整个VoNR注册前置链路如下:
5G Registration → IMS PDU Session (5QI=5) → P-CSCF Discovery → SIP REGISTER (Round 1) → 401 Challenge → SIP REGISTER (Round 2) → 200 OK + IPSec SA
本文聚焦TS 24.229 Section 5.1.1定义的SIP REGISTER双轮鉴权流程,以及TS 33.203定义的IPSec安全关联(Security Association)协商机制,深入拆解每一步信令的IE字段、设计意图和实战要点。
在UE发起SIP REGISTER之前,必须先完成以下准备:
UE通过URSP(UE Route Selection Policy)规则或本地配置,识别出IMS信令流量需要建立专用的PDU Session。该PDU Session的关键参数:
| 参数 | 值 | 说明 |
|---|---|---|
| DNN | ims | 专用DNN标识IMS域 |
| S-NSSAI | 运营商配置 | IMS切片标识 |
| SSC Mode | 1 | 保持IP地址不变的会话连续性 |
| 5QI | 5 | IMS信令默认QoS(Non-GBR) |
| ARP | 优先级较高 | 确保信令承载优先 |
5G网络中P-CSCF地址通过以下三种方式获取:
sequenceDiagram
participant UE
participant gNB
participant AMF
participant SMF
participant UPF
participant PCF
UE->>gNB: UL NAS Transport<br/>(PDU Session Establishment Request)
gNB->>AMF: N2 UL NAS Transport
AMF->>SMF: Nsmf_PDUSession_CreateSMContext
SMF->>PCF: Npcf_SMPolicyControl_Create
PCF-->>SMF: Policy + P-CSCF Address
SMF->>UPF: N4 Session Establishment
SMF-->>AMF: N1N2Transfer<br/>(PDU Session Accept + P-CSCF via PCO)
AMF->>gNB: N2 PDUSessionReq + NAS PDU
gNB-->>UE: PDU Session Establishment Accept<br/>PCO: P-CSCF IPv6 Address
Note over UE: UE now has P-CSCF address<br/>and IMS signaling bearer (5QI=5)
设计意图:将P-CSCF地址与PDU Session绑定,而非依赖额外的DNS查询,可以减少IMS注册的端到端时延。运营商可根据SMF拓扑灵活选择最近的P-CSCF,实现负载均衡和边缘计算优化。
IMS注册的核心是两轮SIP REGISTER:第一轮不携带认证凭据,S-CSCF通过401 Unauthorized下发鉴权挑战;第二轮UE携带计算后的响应值完成鉴权。这种设计基于HTTP Digest框架(RFC 2617),但将IMS-AKA(RFC 3310)映射到Digest参数中。
sequenceDiagram
participant UE
participant P-CSCF as P-CSCF
participant I-CSCF as I-CSCF
participant HSS as UDM/HSS
participant S-CSCF as S-CSCF
rect rgb(230, 245, 255)
Note over UE,S-CSCF: Round 1 — 初始REGISTER(无凭据)
UE->>P-CSCF: SIP REGISTER<br/>To: sip:[email protected]<br/>From: sip:[email protected]<br/>Contact: sip:user@[UE_IP]:port<br/>Security-Client: ipsec-3gpp;alg=AES-CBC<br/>Require: sec-agree
P-CSCF->>I-CSCF: REGISTER + Path + Via<br/>Path: sip:pcscf@addr;lr
I-CSCF->>HSS: Cx: UAR (User-Authorization-Request)<br/>Public Identity + Private Identity
HSS-->>I-CSCF: Cx: UAA<br/>S-CSCF Name / Capability Set
I-CSCF->>S-CSCF: REGISTER (forwarded)
end
rect rgb(255, 230, 230)
Note over UE,S-CSCF: 401 Unauthorized Challenge
S-CSCF->>HSS: Cx: MAR (Multimedia-Auth-Request)<br/>获取鉴权向量 AV(RAND,AUTN,XRES,CK,IK)
HSS-->>S-CSCF: Cx: MAA<br/>AV + SIP-Auth-Data-Item
S-CSCF-->>I-CSCF: 401 Unauthorized<br/>WWW-Authenticate: Digest<br/>nonce=Base64(RAND||AUTN)<br/>algorithm=AKAv2-MD5<br/>qop="auth,auth-int"<br/>opaque=SIP-Auth-Data-Item
I-CSCF-->>P-CSCF: 401 Unauthorized
P-CSCF->>P-CSCF: 分配Server SPI/Port<br/>添加Security-Server头
P-CSCF-->>UE: 401 Unauthorized<br/>Security-Server: ipsec-3gpp;alg=AES-CBC<br/>port-s=port-c' (对称端口对)
end
rect rgb(230, 255, 230)
Note over UE,S-CSCF: Round 2 — 带凭据REGISTER
UE->>UE: ISIM计算 RES = f2(RAND,K)<br/>检测AUTN有效性<br/>计算CK,IK → IPSec密钥
UE->>P-CSCF: SIP REGISTER (via IPSec SA)<br/>Authorization: Digest<br/>response=MD5(H(A1):nonce:H(A2))<br/>A1 = H(IMPI:realm:RES)<br/>Security-Verify: ipsec-3gpp
P-CSCF->>P-CSCF: 验证IPSec SA完整性
P-CSCF->>I-CSCF: REGISTER (via IPSec tunnel)
I-CSCF->>HSS: Cx: UAR
HSS-->>I-CSCF: Cx: UAA → S-CSCF
I-CSCF->>S-CSCF: REGISTER
end
rect rgb(255, 255, 230)
Note over UE,S-CSCF: 鉴权成功 + 注册确认
S-CSCF->>S-CSCF: 比对 response vs XRES<br/>验证通过
S-CSCF->>HSS: Cx: SAR (Server-Assignment-Request)<br/>注册IMPU → S-CSCF绑定
HSS-->>S-CSCF: Cx: SAA (用户配置/IFCs)
S-CSCF-->>I-CSCF: 200 OK<br/>Service-Route, P-Associated-URI
I-CSCF-->>P-CSCF: 200 OK
P-CSCF-->>UE: 200 OK<br/>Service-Route, Path, Security-Server<br/>绑定IPSec SA有效期
end
SIP REGISTER消息关键IE(TS 24.229 Section 5.1.1.2):
| IE字段 | 格式/值 | 说明 |
|---|---|---|
| Request-URI | sip:ims.mnc.mcc.3gppnetwork.org |
指向归属域(Home Domain) |
| To | sip:[email protected] |
IMPU(IMS Public Identity) |
| From | 同To | 注册场景下From=To |
| Contact | sip:user@[UE_IP]:[port-c];+sip.instance="<urn:gsma:imei:...>" |
UE的联系地址+实例ID |
| Call-ID | 全局唯一标识 | 标识一次注册事务 |
| CSeq | 1 REGISTER |
命令序列号 |
| Expires | 600000 |
注册有效期(毫秒,典型值10分钟) |
| Security-Client | ipsec-3gpp;alg=AES-CBC;ealg=AES-CBC;mod=trans |
UE支持的IPSec安全参数 |
| Require | sec-agree |
要求安全协商(TS 33.203) |
| Proxy-Require | sec-agree |
代理侧安全协商 |
| Via | SIP/2.0/UDP [UE_IP]:[port-c];branch=z9hG4bK... |
包含UE端口和branch ID |
| Allow | REGISTER, INVITE, ACK, BYE, CANCEL, OPTIONS... |
UE支持的SIP方法 |
Security-Client头的设计意图(TS 33.203 Section 7.1):UE在初始REGISTER中声明自己支持的安全机制。P-CSCF收到后,在401响应中通过Security-Server头回应所选安全参数,形成安全能力协商。这是前端安全(Sec-Agree)机制的核心。
S-CSCF收到第一轮REGISTER后,向UDM/HSS发起Cx MAR请求获取鉴权向量。401消息中的关键字段:
graph TB
subgraph "WWW-Authenticate Digest 头"
A["algorithm=AKAv2-MD5<br/>IMS AKA版本号"]
B["nonce=Base64(RAND ∥ AUTN)<br/>Base64编码的挑战参数"]
C["realm=ims.mnc.mcc.3gppnetwork.org<br/>认证域"]
D["qop=auth,auth-int<br/>保护质量"]
E["opaque=Base64(SIP-Auth-Data-Item)<br/>S-CSCF认证上下文"]
F["ik=[" + CK="]<br/>可选: 密钥推衍参数"]
end
subgraph "Security-Server 头"
G["ipsec-3gpp<br/>选定安全协议"]
H["alg=AES-CBC<br/>加密算法"]
I["ealg=AES-CBC<br/>加密封装算法"]
J["port-s=5061<br/>P-CSCF服务器端口"]
K["port-c=5060<br/>期望UE使用的客户端端口"]
end
B --> |"UE解析"| L["RAND: 128bit随机数<br/>AUTN: 认证令牌"]
L --> |"ISIM计算"| M["RES = f2(RAND, K)<br/>CK = f3(RAND, K)<br/>IK = f4(RAND, K)"]
M --> |"密钥推衍"| N["IPSec SA密钥材料:<br/>CK' = CK XOR IK<br/>用于ESP加密"]
nonce字段编码规则(RFC 3310 Section 3):nonce = Base64(RAND || AUTN || server-specific-data)。其中RAND为128位随机数,AUTN为128位认证令牌(含SQN||AMF||MAC)。这种将IMS-AKA参数嵌入HTTP Digest nonce的设计,使SIP协议栈无需修改即可承载AKA认证。
UE收到401后执行以下步骤:
步骤1:ISIM/USIM计算AKA响应
输入: RAND(从nonce解码), K(ISIM存储的共享密钥)
计算:
RES = f2(RAND, K) // 期望响应,64bit→128bit
CK = f3(RAND, K) // 加密密钥,128bit
IK = f4(RAND, K) // 完整性密钥,128bit
AUTS(如果SQN不同步) // 同步失败时计算
步骤2:构造Digest响应值
H(A1) = MD5(IMPI : realm : RES)
H(A2) = MD5("REGISTER" : Request-URI)
response = MD5(H(A1) : nonce : nc : cnonce : qop : H(A2))
步骤3:建立IPSec安全关联
UE使用CK和IK推衍IPSec SA的密钥材料:
CK' = CK || IK(256位,用于AES-CBC加密)
IK' = 从IK推衍(用于HMAC-SHA-1完整性保护)
SPI: 从Security-Server头获取
Port: 使用对称端口对(port-c/port-s)
第二轮REGISTER消息关键IE:
| IE字段 | 说明 |
|---|---|
| Authorization | Digest username="IMPI@realm", realm="...", nonce="...", response="计算值", algorithm=AKAv2-MD5, cnonce="UE随机数", nc=00000001, qop=auth |
| Security-Verify | ipsec-3gpp;alg=AES-CBC;ealg=AES-CBC;mod=trans — 回显协商确认的安全参数 |
| Via port | 使用IPSec SA分配的新端口(port-c') |
| Contact port | 同步更新为IPSec SA端口 |
设计意图:第二轮REGISTER必须通过已建立的IPSec SA发送。P-CSCF会验证该REGISTER是否来自合法的IPSec隧道,这实现了信道绑定(Channel Binding)——将SIP层认证与传输层安全关联绑定,防止中间人攻击。
鉴权通过后S-CSCF执行Cx SAR/SSA向HSS注册用户绑定,返回的200 OK携带关键信息:
| IE字段 | 说明 |
|---|---|
| Contact | 包含注册的IMPU和过期时间 |
| Service-Route | sip:[email protected];lr — 后续呼叫信令的路由路径 |
| Path | sip:pcscf@addr;lr — 确保MT信令经由同一P-CSCF路由 |
| P-Associated-URI | 关联的其他IMPU(如tel URI) |
| Security-Server | 确认IPSec SA参数和有效期 |
UE保存Service-Route和Path后,后续的SIP INVITE将自动路由到正确的S-CSCF。
IMS注册过程中I-CSCF和S-CSCF通过Cx接口(TS 29.228/29.229)与HSS通信,共涉及四个关键Diameter消息:
graph LR
subgraph "Cx接口消息流"
A["UAR<br/>User-Authorization-Request<br/>I-CSCF → HSS<br/>查询: IMPU是否已注册?"]
B["UAA<br/>User-Authorization-Answer<br/>HSS → I-CSCF<br/>返回: S-CSCF名称/能力集"]
C["MAR<br/>Multimedia-Auth-Request<br/>S-CSCF → HSS<br/>请求: 鉴权向量AV"]
D["MAA<br/>Multimedia-Auth-Answer<br/>HSS → S-CSCF<br/>返回: AV(RAND,AUTN,XRES,CK,IK)"]
E["SAR<br/>Server-Assignment-Request<br/>S-CSCF → HSS<br/>通知: IMPU注册到本S-CSCF"]
F["SAA<br/>Server-Assignment-Answer<br/>HSS → S-CSCF<br/>返回: 用户Profile/IFCs"]
end
A --> B
C --> D
E --> F
style A fill:#E6F3FF
style C fill:#FFE6E6
style E fill:#E6FFE6
| Cx消息 | 关键AVP | 说明 |
|---|---|---|
| UAR | Public-Identity, UserName(IMPI), Visited-Network-Identifier | I-CSCF查询IMPU注册状态 |
| UAA | Server-Name, Server-Capabilities | 若已注册返回S-CSCF名称;若未注册返回能力集供选择 |
| MAR | Public-Identity, SIP-Auth-Data-Item(Auth-Session-State), Server-Name | S-CSCF请求鉴权向量 |
| MAA | SIP-Auth-Data-Item(RAND, AUTN, XRES, CK, IK) | 返回一个完整AV |
| SAR | Public-Identity, Server-Name, Server-Assignment-Type | 通知注册成功/注销 |
| SAA | User-Data(IMS User Profile), ChargingInformation | 返回用户签约数据和IFC(初始过滤规则) |
S-CSCF选择策略:UAA返回Server-Capabilities时,I-CSCF根据能力集(如支持的算法、协议版本)选择合适的S-CSCF。不同厂商可能采用轮询、权重或拓扑优先策略。
TS 33.203 Section 6定义了UE与P-CSCF之间的IPSec ESP隧道建立机制。这是IMS接入安全的第二层防护(第一层是SIP Digest认证)。
IPSec SA使用对称端口对,这是IMS安全的一个独特设计:
| 方向 | UE侧端口 | P-CSCF侧端口 | SPI |
|---|---|---|---|
| UE → P-CSCF(客户端SA) | port-c(如5060) | port-s'(如5061) | SPI-c |
| P-CSCF → UE(服务器SA) | port-c'(如5062) | port-s(如5063) | SPI-s |
关键约束: - 初始REGISTER使用明文端口(port-uc/port-us) - 401响应后建立的IPSec SA使用受保护端口(port-c/port-s) - 第二轮及后续所有SIP消息必须通过受保护端口发送 - P-CSCF严格检查:未通过IPSec SA的SIP消息将被丢弃
输入: CK(128bit), IK(128bit)来自ISIM AKA计算
密钥材料 = CK || IK = 256bit
IPSec ESP加密密钥: 从密钥材料前128/256bit派生(取决于算法)
IPSec ESP完整性密钥: 从密钥材料后bit派生
SPI: 由发起方分配(UE分配SPI-c,P-CSCF分配SPI-s)
stateDiagram-v2
[*] --> NotRegistered: UE开机/PDU Session建立
NotRegistered --> RegPending: 发送REGISTER(R1)<br/>无凭据
RegPending --> Challenged: 收到401<br/>解析nonce→RAND/AUTN<br/>建立IPSec SA
RegPending --> RegFailed: 超时/网络错误
Challenged --> AuthProcessing: 发送REGISTER(R2)<br/>经IPSec SA<br/>携带Digest响应
AuthProcessing --> Registered: 收到200 OK<br/>保存Service-Route/Path
AuthProcessing --> RegFailed: 鉴权失败<br/>SIP 403/401(重试)
Registered --> ReRegistration: Expires到期前重注册
Registered --> DeRegistered: UE发送REGISTER(Expires=0)
Registered --> RegFailed: 网络侧注销(423 Interval Too Brief)
ReRegistration --> Registered: 200 OK
ReRegistration --> Challenged: 收到401(网络要求重鉴权)
RegFailed --> NotRegistered: 等待重试
DeRegistered --> NotRegistered: 注销确认
| 对比项 | VoLTE (4G EPC) | VoNR (5G 5GC) | 差异说明 |
|---|---|---|---|
| 默认承载 | EPS Default Bearer (QCI=5) | PDU Session (5QI=5) | 承载架构不同 |
| P-CSCF发现 | PCO in Default Bearer Setup | PCO in PDU Session + URSP | 5G引入URSP策略路由 |
| 策略接口 | P-CSCF ↔ PCF via Rx | P-CSCF ↔ PCF via N5 | N5基于HTTP/2 |
| 5G主鉴权 | EPS-AKA | 5G-AKA / EAP-AKA' | SUCI隐私保护增强 |
| IMS-AKA | 相同(ISIM) | 相同(ISIM) | IMS层鉴权机制不变 |
| QoS保障 | Dedicated Bearer (QCI=1) | QoS Flow (5QI=1, dynamic) | 5G使用动态QoS Flow |
| EPS Fallback | 不适用 | 支持 | VoNR特有回退机制 |
| 连续性 | SRVCC to UTRAN/GERAN | EPS Fallback to LTE | 演进方向不同 |
核心观点:IMS域的SIP REGISTER流程在VoNR和VoLTE中基本一致(TS 24.229是独立于接入的规范)。差异集中在5GC承载管理和策略控制接口层面,而非IMS协议本身。
| 抓包位置 | 识别方法 | 关键过滤条件 |
|---|---|---|
| N3接口(UE↔UPF) | SIP over UDP/TCP, 端口5060/5061 | udp.port == 5060 \|\| tcp.port == 5060 |
| N6/N9接口 | 可能加密(IPSec ESP) | esp 协议过滤 |
| IMS内部(Cx/Dx) | Diameter over TCP/SCTP, 端口3868 | diameter.Code == 300 \|\| 303 |
| P-CSCF入口 | 观察IPSec SA建立前后端口变化 | 对比port-uc→port-c切换 |
故障1:SIP REGISTER无响应(超时)
| 可能原因 | 排查方法 |
|---|---|
| P-CSCF地址未正确下发 | 检查PDU Session Accept中的PCO IE |
| IMS PDU Session建立失败 | 检查DNN="ims"配置、SMF选择是否正确 |
| URSP规则未匹配IMS流量 | 验证UE URSP规则中traffic descriptor是否包含IMS DNN |
| 防火墙阻断SIP端口 | 检查UPF/N6接口ACL规则 |
故障2:持续收到401 Unauthorized
| 可能原因 | 排查方法 |
|---|---|
| ISIM/USIM中IMS密钥K不匹配 | 对比HSS与ISIM的K值配置 |
| nonce解析错误(Base64解码) | 抓包对比RAND/AUTN编码 |
| 时钟不同步导致SQN校验失败 | 检查UE与网络时钟同步 |
| AKAv1与AKAv2版本不匹配 | 检查algorithm参数是否一致 |
故障3:收到403 Forbidden
| 可能原因 | 排查方法 |
|---|---|
| IMPU未在HSS签约 | 检查HSS用户Profile中IMS Public Identity |
| S-CSCF选择失败(无可用S-CSCF) | 检查I-CSCF→HSS的UAA返回值 |
| Initial Filter Criteria(IFC)无匹配 | 检查用户签约的服务模板 |
| 用户处于restricted状态 | 检查HSS中Registration-State |
故障4:IPSec SA建立失败
| 可能原因 | 排查方法 |
|---|---|
| Security-Client/Server算法不匹配 | 对比UE与P-CSCF支持的加密算法列表 |
| SPI冲突 | 检查P-CSCF日志中的SPI分配 |
| 端口对协商失败 | 验证对称端口分配是否满足TS 33.203要求 |
| NAT穿越问题(UE在NAT后) | 检查Contact头中的IP是否可路由 |
| ## 八、IMS-AKA vs 5G主鉴权:两层鉴权的关系 |
很多工程师对IMS-AKA和5G-AKA的关系存在困惑。这里做清晰梳理:
| 对比维度 | 5G主鉴权(5G-AKA/EAP-AKA') | IMS域鉴权(IMS-AKA) |
|---|---|---|
| 规范 | TS 33.501 | TS 33.203 |
| 认证向量来源 | UDM/AUSF | UDM/HSS(Cx MAR) |
| 共享密钥 | USIM中的K | ISIM中的K(可共享) |
| 认证结果 | 5G NAS安全上下文 | IMS IPSec SA |
| 保护范围 | UE ↔ 5GC(NAS/AS层) | UE ↔ P-CSCF(SIP层) |
| 目的 | 接入网络认证 | IMS服务认证 |
| 时序 | 先于IMS注册 | 在5G注册和PDU Session之后 |
密钥关系:在大多数商用网络中,ISIM和USIM共享同一组密钥K。但标准允许它们使用不同的密钥。5G主鉴权成功后,UE已建立了NAS和AS层安全,但IMS SIP信令仍需要独立的IMS-AKA认证来建立IPSec保护通道。这种双层鉴权设计实现了安全域分离。
Q1: VoNR IMS注册是否必须使用ISIM?能否用USIM替代?
A: 根据TS 24.229和TS 33.203,IMS注册需要ISIM中存储的IMPI/IMPU和密钥K。但实际网络中,大量UE不具备ISIM应用,此时可通过BSF(Bootstrapping Server Function)机制(TS 33.220 GBA)从USIM导出IMS认证参数。主流做法是在HSS中配置USIM IMSI到IMPI/IMPU的映射规则,使USIM也能完成IMS-AKA。
Q2: 为什么需要两轮REGISTER而不是一轮直接携带凭据?
A: 两轮设计有三个目的:①S-CSCF在第一轮时可能还不存在(需要I-CSCF通过Cx UAR/UAA选择),因此无法预先获取挑战参数;②401响应携带的Security-Server头需要在鉴权前完成安全能力协商;③P-CSCF需要利用401消息建立IPSec SA,使第二轮REGISTER能通过安全隧道传输敏感凭据。
Q3: IPSec SA是强制的还是可选的?
A: 在3GPP规范中,IPSec ESP完整性保护是强制的(TS 33.203 Section 6.1),加密是条件强制的。但在实际部署中,某些运营商可能出于简化配置的考虑,在固网接入场景(如IMS over WiFi via N3IWF)中降级使用TLS保护,而在5G NR直接接入时仍然强制IPSec。
Q4: 重注册流程和初始注册有何不同?
A: 重注册时UE已有IPSec SA和有效的Security-Context,可以直接通过受保护端口发送REGISTER(携带Authorization头中的重注册参数)。但如果S-CSCF要求重新鉴权(如Auth-Session-State=STATE_MAINTAINED),仍可能触发401/REGISTER的双轮交互。此外,重注册时I-CSCF通过Cx UAR会发现已有S-CSCF绑定,直接路由到原S-CSCF,无需重新选择。
Q5: VoNR IMS注册失败会不会影响数据业务?
A: 不会。IMS注册是在独立的PDU Session上进行的(DNN=ims),与互联网数据业务的PDU Session(DNN=internet)完全隔离。IMS注册失败只影响语音和视频通话服务,不影响数据业务。这也是5G多PDU Session架构的优势之一。
本文由「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 等场景全覆盖。
