# VoNR IMS注册与P-CSCF发现信令流深度拆解 ## 一、背景与机制定位 在5G SA网络中，VoNR（Voice over New Radio）的语音承载完全依赖IMS（IP Multimedia Subsystem）域。UE在发起任何语音/视频呼叫之前，**必须先完成IMS注册**——这是一套独立于5GS注册的信令流程，涉及SIP REGISTER消息穿越P-CSCF→I-CSCF→S-CSCF完整链路，并通过IMS-AKA完成应用层认证。 本文聚焦 **TS 23.228 Section 5.1.1** 定义的IMS注册流程，结合 **TS 24.229 Section 5.1.1** 的SIP信令规范，以及5G核心网中 **P-CSCF地址发现**（TS 23.501 Section 5.4.2）和 **SIP信令专用QoS Flow建立**（5QI=5）的联动机制，逐级拆解每条消息的关键Information Element。 ### 为什么IMS注册是独立流程？ IMS注册与5GS注册（TS 23.502 Section 4.2.2.2）在协议层面完全解耦： | 维度 | 5GS注册 | IMS注册 | |------|---------|---------| | 协议层 | NAS信令（MM子层） | SIP信令（应用层） | | 触发 | USIM插入/开机/周期性 | IMS APN PDU会话建立后 | | 认证方式 | 5G-AKA / EAP-AKA' | IMS-AKA（基于ISIM/USIM） | | 注册管理 | AMF | S-CSCF | | 参考规范 | TS 23.502 §4.2.2 | TS 23.228 §5.1.1 | 设计意图：**解耦使得IMS可以独立演进**。5GC负责底层连接性管理，IMS负责会话层业务控制，两者通过PDU Session（QoS Flow）作为传输承载松耦合。 ## 二、P-CSCF发现机制 UE必须先获取P-CSCF的IP地址才能发起SIP REGISTER。在5G中，P-CSCF发现有两种主要途径： ### 方式1：PDU Session Establishment中获取（主流方式） UE在建立IMS PDU Session时，通过SMF在 `PDU Session Establishment Accept` 消息中携带P-CSCF地址。 **触发条件**：DNN=IMS，S-NSSAI指向IMS切片 信令路径： ``` UE → (R)AN → AMF → SMF → UDM/PCF → SMF → AMF → (R)AN → UE ↑ SMF查询PCF获取P-CSCF地址 ``` 关键IE位于 `PDU Session Establishment Accept`（TS 24.501 Section 9.11.4.2）： | IE名称 | 参考章节 | 说明 | |--------|---------|------| | PDU address | §9.11.4.2 | 分配给UE的IMS信令IP地址 | | DNN | §9.11.2.1A | "IMS" | | SSC mode | §9.11.4.6 | 通常为SSC Mode 1 | | Session-AMBR | §9.11.4.16 | IMS信令带宽限制 | | **P-CSCF address** | §9.11.4.2A | P-CSCF的IPv4/IPv6地址 | ### 方式2：DHCPv4/DHCPv6查询（备选方式） UE通过已建立的IMS PDU Session，发送DHCP查询获取P-CSCF地址。此方式定义在TS 23.228 Annex B。 **Option编码**： - DHCPv4: Option 120（SIP Servers Domain Name List）或 Option 114（SIP Server IPv4 Address） - DHCPv6: Option OPTION_SIP_SERVER_D (21) 或 OPTION_SIP_SERVER_A (22) ### P-CSCF发现状态转换 ```mermaid stateDiagram-v2 [*] --> NoIMSSession: UE开机/5GS注册完成 NoIMSSession --> EstablishingIMSPDU: 发起IMS PDU Session
(DNN=IMS) EstablishingIMSPDU --> PCSCF_Discovered: SMF返回
P-CSCF地址 EstablishingIMSPDU --> DHCP_Query: SMF未返回P-CSCF地址 DHCP_Query --> PCSCF_Discovered: DHCP响应含
P-CSCF地址 PCSCF_Discovered --> SIP_Registering: 发起SIP REGISTER SIP_Registering --> IMS_Registered: 200 OK SIP_Registering --> SIP_Registering: 401/403挑战
重试 IMS_Registered --> IMS_Registered: 注册刷新
(默认3600s) IMS_Registered --> SIP_Registering: 注册过期/网络发起
de-register后重注册 IMS_Registered --> [*]: IMS PDU Session释放 ``` ## 三、IMS注册完整信令时序图 以下基于 **TS 23.228 Section 5.1.1.1** 的IMS初始注册流程，结合5GC的PDU Session QoS Flow联动。 ```mermaid sequenceDiagram participant UE participant RAN as (R)AN/gNB participant AMF participant SMF participant PCF participant UPF participant PCSCF as P-CSCF participant ICSCF as I-CSCF participant HSS participant SCSCF as S-CSCF Note over UE,UPF: 阶段1：IMS PDU Session建立（若尚未建立） UE->>AMF: NAS PDU Session Establishment Request
(DNN=IMS, SSC mode 1) AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request SMF->>PCF: Npcf_SMPolicyControl_Create
(获取IMS策略+P-CSCF地址) PCF-->>SMF: Policy Decision + P-CSCF Address SMF->>UPF: N4 Session Establishment
(QFI=1, 5QI=5, SIP信令专用) SMF-->>AMF: Nsmf_PDUSession_CreateSMContext Response
(含P-CSCF Address) AMF->>RAN: N2 PDU Session Resource Setup
(QoS参数:5QI=5, Priority) RAN->>UE: RRC Reconfiguration + PDU Session Accept
(含P-CSCF Address + IP地址) Note over UE,SCSCF: 阶段2：SIP REGISTER（未认证） UE->>PCSCF: SIP REGISTER
(Contact, To, From, Call-ID, expires=3600) Note right of UE: 关键Header:
Require: sec-agree
Proxy-Require: sec-agree
Security-Client: alg=ipsec-3gpp PCSCF->>PCSCF: 记录UE IP+Port
关联IMS PDU Session PCSCF->>ICSCF: SIP REGISTER (转发) ICSCF->>HSS: Cx: UAR (User Authorization Request)
(Public Identity, Visited Network) HSS-->>ICSCF: Cx: UAA (User Authorization Answer)
(S-CSCF Name/Capability Set) ICSCF->>SCSCF: SIP REGISTER (转发至选定S-CSCF) SCSCF->>HSS: Cx: MAR (Multimedia Auth Request)
(Public Identity, SIP Number Auth) HSS-->>SCSCF: Cx: MAA (Multimedia Auth Answer)
(RAND, AUTN, XRES, IK, CK) Note over UE,SCSCF: 阶段3：IMS-AKA认证挑战 SCSCF->>ICSCF: SIP 401 Unauthorized Note right of SCSCF: WWW-Authenticate Header:
nonce=RAND:AUTN
algorithm=AKAv1-MD5
ik, ck参数 ICSCF->>PCSCF: SIP 401 Unauthorized (转发) PCSCF->>PCSCF: 提取IK/CK
建立IPSec SA参数 PCSCF->>UE: SIP 401 Unauthorized Note over UE,SCSCF: 阶段4：UE认证响应与注册（已认证） UE->>UE: ISIM验证AUTN
计算RES
派生IK/CK UE->>PCSCF: SIP REGISTER (带认证响应)
Authorization: response=RES
Security-Verify: 服务端安全参数 Note right of UE: 此时IPSec SA已建立
port_us=UE protected port
port_ps=P-CSCF protected port PCSCF->>PCSCF: 验证Security-Verify
后续SIP消息走IPSec隧道 PCSCF->>ICSCF: SIP REGISTER (转发) ICSCF->>SCSCF: SIP REGISTER (转发) SCSCF->>SCSCF: 验证RES == XRES
认证通过 SCSCF->>HSS: Cx: SAR (Server Assignment Request)
(User Data download request) HSS-->>SCSCF: Cx: SAA (Server Assignment Answer)
(IMS用户签约数据/Filter Criteria) Note over UE,SCSCF: 阶段5：注册成功 SCSCF->>ICSCF: SIP 200 OK Note right of SCSCF: Service-Route Header
Path Header确认
关联P-CSCF信息 ICSCF->>PCSCF: SIP 200 OK (转发) PCSCF->>PCSCF: 提取Service-Route
绑定UE Contact→S-CSCF PCSCF->>UE: SIP 200 OK Note over UE,UPF: 阶段6：注册后SIP信令流路径 Note over UE,PCSCF: 所有后续SIP信令经IPSec SA保护
UE(port_us) ↔ P-CSCF(port_ps)
经5QI=5 QoS Flow传输 ``` ## 四、关键信令消息IE解析 ### 4.1 SIP REGISTER（初始注册） 基于 **TS 24.229 Section 5.1.1.2**，UE发出的初始SIP REGISTER包含以下关键IE： ``` REGISTER sip:ims.mnc.mcc.3gppnetwork.org SIP/2.0 Via: SIP/2.0/UDP [UE_IP]:[port];branch=z9hG4bK1234 From: .mcc.3gppnetwork.org>;tag=abc123 To: .mcc.3gppnetwork.org> Call-ID: abcdefgh@[UE_IP] CSeq: 1 REGISTER Contact: ;expires=3600 Expires: 3600 Require: sec-agree Proxy-Require: sec-agree Security-Client: ipsec-3gpp;alg=hmac-sha-1-96;prot=esp;mod=trans; spi-c=;spi-s=; port-c=;port-s= Content-Length: 0 ``` | Header/IE | 作用 | 取值说明 | |-----------|------|---------| | Request-URI | 注册域 | `sip:ims.mnc.mcc.3gppnetwork.org` | | From/To | Public User Identity | 从ISIM读取IMPU，若ISIM缺失则从USIM派生 | | Contact | UE联系地址 | 含UE的IP:Port和注册有效期 | | Require: sec-agree | 强制安全协商 | 要求P-CSCF支持安全机制 | | Security-Client | IPSec参数提议 | UE提议的SPI、端口、算法参数 | | Expires | 注册有效期 | 通常3600秒，运营商可配置 | **Public User Identity派生规则**（TS 23.003 Section 13.4）： - **有ISIM**：直接从ISIM的IMPU字段读取 - **无ISIM有USIM**：按规则派生 `sip:@ims.mnc.mcc.3gppnetwork.org` ### 4.2 SIP 401 Unauthorized（IMS-AKA挑战） S-CSCF通过HSS获取认证向量后，返回401挑战： ``` SIP/2.0 401 Unauthorized ... WWW-Authenticate: Digest realm="ims.mnc.mcc.3gppnetwork.org", nonce="::", algorithm=AKAv1-MD5, ik="", ck="" Security-Server: ipsec-3gpp;alg=hmac-sha-1-96;prot=esp;mod=trans; spi-c=;spi-s=; port-c=;port-s= ``` | 参数 | 来源 | 作用 | |------|------|------| | RAND | HSS/ARPF生成的随机数 | 挑战随机数（128 bit） | | AUTN | HSS计算 | 认证令牌，含MAC+SQN+AMF | | IK (Integrity Key) | HSS从AK派生 | IPSec ESP完整性保护密钥 | | CK (Cipher Key) | HSS从AK派生 | IPSec ESP加密密钥 | | Security-Server | P-CSCF选定 | 服务端接受的IPSec SA参数 | **IMS-AKA密钥推演过程**（TS 33.203 Section 6.1.1）： ```mermaid flowchart TD K["K (ISIM/USIM根密钥, 128bit)"] --> A5G["f1~f5函数族
(Milenage算法)"] RAND["RAND (128bit随机数)"] --> A5G AUTN_SQN["SQN ⊕ AK + AMF"] --> A5G A5G --> RES["RES (64bit)
→经MD5/HMAC响应"] A5G --> IK["IK (128bit)
完整性密钥→IPSec ESP AUTH"] A5G --> CK["CK (128bit)
加密密钥→IPSec ESP ENC"] A5G --> AK["AK (64bit)
用于隐藏SQN"] K -.-> USIM["USIM验证:
AUTN中的MAC == XMAC?
SQN在有效窗口?"] USIM -->|"验证通过"| CALC_RES["计算RES"] USIM -->|"验证失败"| REJ["UE返回认证失败"] IK --> SA["IPSec SA建立
ESP transport mode
alg=hmac-sha-1-96"] CK --> SA ``` ### 4.3 SIP REGISTER（认证响应） UE验证AUTN后，携带RES重新发起REGISTER： ``` REGISTER sip:ims.mnc.mcc.3gppnetwork.org SIP/2.0 ... Authorization: Digest username="private_user@ims.mnc.mcc.3gppnetwork.org", realm="ims.mnc.mcc.3gppnetwork.org", nonce="::", response="", algorithm=AKAv1-MD5 Security-Verify: ipsec-3gpp;alg=hmac-sha-1-96;prot=esp;mod=trans; spi-c=;spi-s=; port-c=;port-s= ``` **关键点**：此时UE已经使用IK/CK建立了IPSec SA，此REGISTER消息通过IPSec ESP隧道（特定port_us ↔ port_ps）发送。 ### 4.4 SIP 200 OK（注册成功） ``` SIP/2.0 200 OK ... Contact: ;expires=3600 Date: Mon, 02 Jun 2026 08:30:00 GMT Service-Route: .mcc.3gppnetwork.org;lr> Path: .mcc.3gppnetwork.org;lr> P-Associated-URI: .mcc.3gppnetwork.org>, ``` | Header | 来源 | 作用 | |--------|------|------| | Service-Route | S-CSCF生成 | UE后续请求的路由路径，确保经S-CSCF | | Path | P-CSCF添加 | 服务端到UE的反向路由 | | P-Associated-URI | S-CSCF从HSS获取 | 关联的其他Public User Identity | | Date | S-CSCF | 服务器时间，UE用于同步 | ## 五、Cx接口信令解析 I-CSCF和S-CSCF与HSS通过Diameter Cx接口交互（TS 29.228），这是IMS注册的核心支撑接口。 ### 5.1 UAR/UAA（用户授权） I-CSCF收到REGISTER后，向HSS查询S-CSCF分配： | AVP | 方向 | 说明 | |-----|------|------| | Public-Identity | UAR→ | Public User Identity（IMPU） | | Visited-Network-Identifier | UAR→ | 拜访网络标识 | | User-Name | UAR→ | Private User Identity（IMPI） | | Server-Name | UAA← | 已分配的S-CSCF URI（若存在） | | Server-Capabilities | UAA← | S-CSCF能力集（mandatory/optional） | **S-CSCF选择逻辑**（TS 23.228 Section 5.1.1.2）： 1. 初始注册：HSS返回Server-Capabilities，I-CSCF按能力集选S-CSCF 2. 重注册：HSS返回Server-Name，I-CSCF直接路由到已分配的S-CSCF ### 5.2 MAR/MAA（多媒体认证） S-CSCF向HSS请求认证向量： | AVP | 方向 | 说明 | |-----|------|------| | SIP-Number-Auth-Items | MAR→ | 请求的认证向量数量（通常1） | | SIP-Auth-Data-Item | MAA← | 认证向量：RAND, AUTN, XRES, IK, CK | | User-Name | MAR→ | IMPI | ### 5.3 SAR/SAA（服务器分配） 认证成功后，S-CSCF向HSS注册自己并下载用户数据： | AVP | 方向 | 说明 | |-----|------|------| | Server-Name | SAR→ | S-CSCF自身URI | | User-Data-Already-Available | SAR→ | 是否需要下载用户数据 | | User-Data | SAA← | IMS用户签约数据（XML格式） | | Charging-Information | SAA← | 计费功能地址 | **IMS用户签约数据**（TS 29.228 Annex A）的核心内容： - **Filter Criteria（过滤准则）**：触发条件+AS地址，决定哪些SIP消息需触发到应用服务器 - **Public Identity集**：IMPU及其关联的tel URI - **Core Network Service Authorization**：允许的媒体类型、编解码器 ## 六、IPSec安全关联建立 IMS注册中最独特的设计是 **IPSec SA的建立时机**——它嵌入在SIP 401/REGISTER交互过程中完成。 ### 6.1 安全参数协商 定义于 **TS 33.203 Section 7.1**： ```mermaid flowchart LR subgraph "UE侧" UE_SPIC["spi-c
(UE→P-CSCF方向SPI)"] UE_SPIS["spi-s
(P-CSCF→UE方向SPI)"] UE_PORTC["port-c
(UE受保护发送端口)"] UE_PORTS["port-s
(UE受保护接收端口)"] end subgraph "P-CSCF侧" PS_SPIC["spi-c'
(与UE spi-c配对)"] PS_SPIS["spi-s'
(与UE spi-s配对)"] PS_PORTC["port-c'
(P-CSCF受保护发送端口)"] PS_PORTS["port-s'
(P-CSCF受保护接收端口)"] end UE_SPIC -.->|"Security-Client提议"| PS_SPIC UE_SPIS -.->|"Security-Client提议"| PS_SPIS PS_PORTC -.->|"Security-Server选定"| UE_PORTS PS_PORTS -.->|"Security-Server选定"| UE_PORTC subgraph "SA_1 (UE→P-CSCF)" SA1["SPI=spi-c
Src=UE_IP:port-c
Dst=P-CSCF_IP:port-s
Key=IK/CK"] end subgraph "SA_2 (P-CSCF→UE)" SA2["SPI=spi-s
Src=P-CSCF_IP:port-s
Dst=UE_IP:port-c
Key=IK/CK"] end ``` ### 6.2 IPSec SA参数表 | 参数 | 值/范围 | 说明 | |------|---------|------| | 协议 | ESP (Encapsulating Security Payload) | 不使用AH，仅ESP | | 模式 | Transport | 端到端保护，不建隧道 | | 加密算法 | NULL / AES-CBC | CK可用于加密，但多数部署仅用完整性保护 | | 完整性算法 | HMAC-SHA-1-96 | mandatory算法 | | SPI范围 | 0xFF000000–0xFFFFFFFF | 动态分配，避免与静态SPI冲突 | | 受保护端口 | 由UE和P-CSCF各自提议/选定 | 后续SIP信令必须使用受保护端口 | | 密钥生命周期 | 与IMS注册周期一致 | 重注册时可能更新SA | **设计意图**：IPSec SA在SIP层协商完成，不依赖IKE（Internet Key Exchange），因为密钥材料直接来自IMS-AKA的IK/CK。这避免了额外的密钥交换往返，降低了信令开销。 ## 七、5G核心网联动：5QI=5 QoS Flow IMS注册的SIP信令通过 **5QI=5** 的专用QoS Flow传输，这是5GC为IMS SIP信令预定义的标准QoS配置。 ### 7.1 5QI=5参数特征（TS 23.501 Table 5.7.4-1） | 参数 | 值 | 说明 | |------|-----|------| | 5QI | 5 | IMS SIP信令专用 | | Resource Type | Non-GBR | 不保证比特率 | | Default Priority Level | 1 | 最高优先级（与5QI=1语音并列） | | Packet Delay Budget | 100ms | 包延迟预算 | | Packet Error Rate | 10^-6 | 误包率 | | Averaging Window | 未定义 | — | **为什么SIP信令需要最高优先级？** SIP REGISTER和呼叫信令消息体积小但时效性极强。如果SIP信令被用户面数据拥塞，将导致注册超时、呼叫建立延迟。Priority Level=1确保SIP信令在任何负载条件下都能优先调度。 ### 7.2 QoS Flow建立时序 IMS PDU Session建立过程中，SMF通过PCF获取IMS策略，建立5QI=5的默认QoS Flow： ``` SMF → PCF: Npcf_SMPolicyControl_Create (DNN=IMS) PCF → SMF: Policy + QoS Data (5QI=5, ARP) SMF → UPF: N4 Session Establishment (QFI=1, 5QI=5) SMF → AMF: N1N2MessageTransfer (QoS Flow描述) AMF → gNB: N2 PDU Session Resource Setup (QoS参数) gNB → UE: RRC Reconfiguration (DRB配置, QFI=1→5QI=5) ``` ## 八、实战抓包识别 ### 8.1 Wireshark过滤表达式 ``` # 过滤SIP注册信令 sip.Method == "REGISTER" || sip.Status-Code == 401 || sip.Status-Code == 200 # 过滤IMS PDU Session gtp.message_type == 168 && nas_5gs.dnn == "ims" # 过滤IPSec ESP esp.spi == 0xFF000001 # 过滤Cx Diameter diameter.Command-Code == 300 || diameter.Command-Code == 303 || diameter.Command-Code == 301 ``` ### 8.2 关键识别特征 | 观察点 | 特征 | |--------|------| | GTP-U层 | IMS PDU Session的TEID，承载SIP信令 | | SIP层 | REGISTER方法、401状态码含WWW-Authenticate nonce | | IPSec层 | 401后出现ESP包，SPI在0xFF000000+范围 | | Diameter层 | Cx接口上的UAR/MAR/SAR命令 | | NAS层 | PDU Session Establishment中DNN=IMS | ### 8.3 典型时间分布 正常IMS注册全程约 **500ms-2s**，各阶段参考时延： | 阶段 | 典型时延 | 说明 | |------|---------|------| | IMS PDU Session建立 | 100-300ms | 含gNB DRB建立 | | SIP REGISTER→401 | 50-200ms | 含Cx UAR+MAR交互 | | UE IMS-AKA计算 | 5-20ms | USIM内计算 | | SIP REGISTER(认证)→200 OK | 50-200ms | 含Cx SAR交互 | | **总耗时** | **200-720ms** | 不含PDU Session建立 | ## 九、常见故障与排错 ### 故障1：P-CSCF地址未返回 **现象**：UE完成5GS注册和IMS PDU Session建立，但无法获取P-CSCF地址。 **排查路径**： 1. 检查 `PDU Session Establishment Accept` 中是否包含P-CSCF Address IE 2. 检查SMF日志中PCF是否通过N7接口下发P-CSCF地址策略 3. 检查PCF中IMS DNN的策略配置是否绑定了P-CSCF地址 4. 备选：UE是否支持DHCP方式查询P-CSCF **根因**：多数情况是 **PCF未配置IMS APN对应的P-CSCF策略**。 ### 故障2：SIP 403 Forbidden **现象**：S-CSCF返回403，注册失败。 **可能原因**： - HSS中无该用户的IMS签约数据（IMPU/IMPI未配置） - S-CSCF能力集与I-CSCF查询结果不匹配（S-CSCF容量满） - 用户被ODB（Operator Determined Barring）限制 **排查命令**（HSS侧）： ``` # 查询用户IMS签约 show subscriber imsi= ims-profile # 检查S-CSCF分配 show scscf-assignment public-id= ``` ### 故障3：IMS-AKA认证失败 **现象**：UE收到401后无法完成认证，或S-CSCF验证RES失败。 **排查路径**： 1. 检查K/OP/OPc一致性：HSS和USIM中的根密钥是否匹配 2. 检查SQN同步：HSS和USIM的SQN是否超出窗口 3. USIM返回AUTS（同步失败），触发重新同步流程 **SQN同步失败处理**（TS 33.203 Section 6.3.2）： - UE在AUTS参数中携带USIM当前SQN - S-CSCF转发AUTS至HSS - HSS重新计算SQN并下发新的认证向量 ### 故障4：IPSec SA建立失败 **现象**：认证后的REGISTER未通过受保护端口发送。 **常见原因**： - UE与P-CSCF之间的NAT设备不支持IPSec ESP穿透 - P-CSCF分配的受保护端口被防火墙拦截 - IKE/ESP协议号（50/51）被中间网络设备过滤 **厂商差异**： - 华为P-CSCF：支持NAT穿透模式，可回退到UDP无保护模式 - 爱立信P-CSCF：严格要求IPSec，NAT场景需配置IKEv2 - 中兴P-CSCF：支持IPSec与TLS双模式安全协商 ### 故障5：注册刷新失败 IMS注册默认有效期3600秒，UE需在过期前（通常在50%-95%时）发起刷新REGISTER。 **现象**：S-CSCF在注册过期后删除绑定，呼入失败。 **排查**： 1. 检查UE是否正常发送刷新REGISTER（抓包确认） 2. 检查Contact header中的expires值是否正确 3. 检查IPSec SA是否在刷新时同步更新 ## 十、与其他机制对比 ### 10.1 IMS注册 vs 5GS注册对比 | 维度 | 5GS注册 | IMS注册 | |------|---------|---------| | 规范 | TS 23.502 §4.2.2 | TS 23.228 §5.1.1 | | 消息类型 | NAS Registration Request | SIP REGISTER | | 认证 | 5G-AKA/EAP-AKA' | IMS-AKA | | 密钥来源 | K (USIM) + SN-id | K (ISIM/USIM) | | 安全保护 | NAS Security (RRC加密+完整性) | IPSec ESP (transport) | | 注册管理 | AMF | S-CSCF | | 有效期 | 运营商配置（T3512等） | Contact expires（默认3600s） | | 用户数据 | UDM (Subscription Profile) | HSS (IMS User Data) | | 路由 | AMF Selection (GUAMI) | I-CSCF→S-CSCF (DNS/Cx) | ### 10.2 VoLTE vs VoNR的IMS注册差异 | 差异点 | VoLTE (EPC) | VoNR (5GC) | |--------|-------------|------------| | 默认承载 | EPS Default Bearer (QCI=5) | QoS Flow (5QI=5) | | P-CSCF发现 | PGW通过PCO下发 | SMF通过PDU Session Accept下发 | | 信令接口 | Gx (PGW-PCRF), Rx (P-CSCF-PCRF) | N7 (SMF-PCF), N5 (P-CSCF-PCF) | | 计费接口 | Rf/Ro over Diameter | Nchf (HTTP/JSON) | | 安全保护 | IPSec (相同) | IPSec (相同) | | S-CSCF选择 | I-CSCF via DRA → HSS | I-CSCF → HSS (无DRA时直连) | ## 常见问题 **Q1: IMS注册中的IMPI和IMPU分别是什么？有什么关系？** A: IMPI（IP Multimedia Private Identity）是用户的私有身份标识，类似于IMSI，用于认证和计费，格式为 `user@realm`。IMPU（IP Multimedia Public Identity）是公开身份，格式为SIP URI `sip:user@domain` 或tel URI `tel:+号码`。一个IMPI可以关联多个IMPU。认证时使用IMPI（Authorization header的username），注册时使用IMPU（From/To header）。 **Q2: 为什么需要两次REGISTER才能完成注册？** A: 第一次REGISTER触发S-CSCF从HSS获取IMS-AKA认证向量并返回401挑战，这是质询-响应机制。UE验证网络（通过AUTN确认网络合法性）后，用RES作为响应凭证发起第二次REGISTER。S-CSCF比较RES和XRES，认证通过才接受注册。两次交互同时完成了双向认证和网络-UE间IPSec SA的密钥协商，效率高于独立的密钥交换。 **Q3: IPSec SA建立的受保护端口有什么特殊意义？** A: 受保护端口（port_us/port_ps）是IPSec SA协商中UE和P-CSCF各自选定的特定UDP端口。SA建立后，**所有后续SIP信令必须通过这些受保护端口收发**。P-CSCF会丢弃非受保护端口发来的SIP消息（除初始REGISTER外）。这防止了SIP信令被伪造或劫持。受保护端口关联IPSec SPI，形成安全绑定。 **Q4: 如果UE没有ISIM，IMS注册还能正常进行吗？** A: 可以。TS 23.228和TS 24.229定义了基于USIM的IMS注册备选方案。IMPI由IMSI派生（`@ims.mnc.mcc.3gppnetwork.org`），IMPU也由IMSI派生。认证仍使用USIM的K密钥进行IMS-AKA。差异在于：无ISIM时无法获取IMS专用密钥（ISIM可能有独立的IMS K），且无法读取ISIM上的IMPU/IMPI预配置值，灵活性降低。 **Q5: IMS注册成功后，S-CSCF下载的Filter Criteria有什么作用？** A: Filter Criteria（过滤准则）定义了哪些SIP消息需要触发到哪些应用服务器（AS）。例如：REGISTER消息触发到Tel-URI AS完成号码关联；INVITE消息触发到MMTel AS完成补充业务处理（如呼叫前转）。这是IMS service control的核心机制——S-CSCF作为信令锚点，根据Filter Criteria对每条SIP请求进行第三方注册或业务触发，实现增值业务的灵活部署。 ## 参考来源 1. [3GPP TS 23.228 V18.x.x](https://www.3gpp.org/DynaReport/23281.htm) — Section 5.1.1 IMS Registration procedures, IP Multimedia Subsystem Stage 2 2. [3GPP TS 24.229 V18.x.x](https://www.3gpp.org/DynaReport/24229.htm) — Section 5.1.1 SIP Registration procedures, SIP-based IP multimedia call control protocol 3. [3GPP TS 33.203 V18.x.x](https://www.3gpp.org/DynaReport/33203.htm) — Section 6.1/7.1 IMS-AKA authentication and IPSec SA establishment 4. [3GPP TS 29.228 V18.x.x](https://www.3gpp.org/DynaReport/29228.htm) — Cx interface signaling (UAR/MAR/SAR), IP Multimedia Subsystem Cx and Dx interfaces 5. [TS 23.502 Section 4.3.5.2 — SSC Mode 3 (itecspec.com)](https://itecspec.com/3gpp/23.502/s/4.3.5.2) — SSC mode 3 PDU Session Anchor relocation reference 6. [VoNR Registration Procedure — 3GLTEInfo](https://www.3glteinfo.com/call-flows/5g/vonr-registration/) — VoNR registration call flow with detailed message analysis 7. [SIP Signaling in VoLTE and VoNR — 5G/6G Academy](https://www.5g6gacademy.com/learn/sip-volte-vonr) — IMS Registration, Call Setup, and QoS correlation analysis --- > 本文由「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 等场景全覆盖。