<!-- title: VoNR IMS注册双轮鉴权与IPSec协商拆解 -->
<!-- domain: ims -->

# VoNR IMS注册双轮鉴权与IPSec协商拆解

## 一、从5G注册到IMS注册：VoNR语音的"入场券"

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字段、设计意图和实战要点。

## 二、VoNR IMS注册前置：PDU Session与P-CSCF发现

在UE发起SIP REGISTER之前，必须先完成以下准备：

### 2.1 IMS信令专用PDU Session

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 | 优先级较高 | 确保信令承载优先 |

### 2.2 P-CSCF发现机制

5G网络中P-CSCF地址通过以下三种方式获取：

1. **PCO（Protocol Configuration Options）**：SMF在PDU Session Establishment Accept消息中，通过PCO IE直接下发P-CSCF地址列表（TS 24.501 Section 9.11.4.1）
2. **DHCPv6**：UE通过DHCPv6 Option查询P-CSCF FQDN，再通过DNS解析获得地址
3. **PCF/N5接口**：运营商通过PCF策略控制向P-CSCF提供IMS会话策略

```mermaid
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，实现负载均衡和边缘计算优化。

## 三、SIP REGISTER双轮鉴权完整信令流

IMS注册的核心是**两轮SIP REGISTER**：第一轮不携带认证凭据，S-CSCF通过401 Unauthorized下发鉴权挑战；第二轮UE携带计算后的响应值完成鉴权。这种设计基于HTTP Digest框架（RFC 2617），但将IMS-AKA（RFC 3310）映射到Digest参数中。

### 3.1 完整信令时序图

```text
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:user@ims.mnc.mcc.3gppnetwork.org<br/>From: sip:user@ims.mnc.mcc.3gppnetwork.org<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
```

### 3.2 第一轮REGISTER：IE字段解析

**SIP REGISTER消息关键IE**（TS 24.229 Section 5.1.1.2）：

| IE字段 | 格式/值 | 说明 |
|---------|---------|------|
| Request-URI | `sip:ims.mnc.mcc.3gppnetwork.org` | 指向归属域（Home Domain） |
| To | `sip:user_public_id@ims.mnc.mcc.3gppnetwork.org` | 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）机制**的核心。

### 3.3 401 Unauthorized：IMS-AKA挑战解析

S-CSCF收到第一轮REGISTER后，向UDM/HSS发起**Cx MAR**请求获取鉴权向量。401消息中的关键字段：

```text
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认证。

### 3.4 第二轮REGISTER：认证响应计算

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层认证与传输层安全关联绑定，防止中间人攻击。

### 3.5 200 OK：注册完成

鉴权通过后S-CSCF执行**Cx SAR/SSA**向HSS注册用户绑定，返回的200 OK携带关键信息：

| IE字段 | 说明 |
|---------|------|
| Contact | 包含注册的IMPU和过期时间 |
| Service-Route | `sip:orig@scscf.ims.mnc.mcc.3gppnetwork.org;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。

## 四、Cx接口四消息交互与S-CSCF选择

IMS注册过程中I-CSCF和S-CSCF通过Cx接口（TS 29.228/29.229）与HSS通信，共涉及四个关键Diameter消息：

```mermaid
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。不同厂商可能采用轮询、权重或拓扑优先策略。

## 五、IPSec安全关联：端口对与SPI协商

TS 33.203 Section 6定义了UE与P-CSCF之间的IPSec ESP隧道建立机制。这是IMS接入安全的第二层防护（第一层是SIP Digest认证）。

### 5.1 端口对称机制

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消息将被丢弃

### 5.2 IPSec SA密钥推衍

```
输入: CK（128bit）, IK（128bit）来自ISIM AKA计算

密钥材料 = CK || IK = 256bit

IPSec ESP加密密钥: 从密钥材料前128/256bit派生（取决于算法）
IPSec ESP完整性密钥: 从密钥材料后bit派生
SPI: 由发起方分配（UE分配SPI-c，P-CSCF分配SPI-s）
```

### 5.3 状态转换图

```mermaid
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: 注销确认
```

## 六、VoNR vs VoLTE：IMS注册关键差异

| 对比项 | 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协议本身。

## 七、实战抓包与故障排查

### 7.1 抓包识别要点

| 抓包位置 | 识别方法 | 关键过滤条件 |
|----------|---------|-------------|
| 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切换 |

### 7.2 常见故障点

**故障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架构的优势之一。

## 参考来源

1. [3GPP TS 24.229 V18.8.0](https://www.3gpp.org/DynaReport/24229.htm) — Section 5.1.1.2/5.1.1.3 SIP REGISTER流程定义
2. [3GPP TS 33.203 V15.1.0](https://www.etsi.org/deliver/etsi_ts/133200_133299/133203/15.01.00_60/ts_133203v150100p.pdf) — IMS接入安全架构与IPSec SA机制
3. [RFC 3310 - HTTP Digest AKA](https://rfc.blacklabs.team/rfc3310.html) — IMS-AKA到HTTP Digest的映射规范
4. [3GPP TS 29.228/29.229](https://www.3gpp.org/DynaReport/29228.htm) — Cx接口Diameter信令定义（UAR/UAA/MAR/MAA/SAR/SAA）
5. [VoNR Registration Procedure Call Flow - 3glteinfo](https://www.3glteinfo.com/call-flows/5g/vonr-registration/) — VoNR注册完整流程参考

---

> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)