<!-- title: 5G IMS第三方注册与业务触发机制拆解 -->
<!-- domain: ims -->

# 5G IMS第三方注册与Filter Criteria业务触发机制深度拆解

## 一、机制定位：从注册到业务的关键桥梁

在VoNR/IMS架构中，UE完成SIP REGISTER并获得200 OK仅意味着**传输层注册成功**——S-CSCF知道了UE的Contact地址和IPSec SA参数。但**IMS业务的真正激活**发生在注册成功之后：S-CSCF从HSS下载用户签约数据中的Filter Criteria（过滤准则），并依据这些规则向应用服务器（AS）发起**Third-Party Registration（第三方注册）**，由AS完成补充业务的初始化配置。

这一机制定义在 **TS 23.228 Section 5.3.5**（Third-Party Registration）、**TS 29.228 Annex A**（Filter Criteria XML Schema）和 **TS 24.229 Section 5.1.1.6**（Third-Party Registration Procedures），是连接"用户可达性"与"业务可用性"的核心纽带。

### 1.1 为什么需要第三方注册？

| 场景 | 无Third-Party Registration | 有Third-Party Registration |
|------|--------------------------|--------------------------|
| 呼叫前转（CFU） | 需用户每次呼叫时自行指定前转号码 | AS自动根据签约数据执行前转 |
| 呼叫等待（CW） | 无法动态激活/去激活 | AS通过SIP SUBSCRIBE/NOTIFY推送状态 |
| 主叫号码显示（CNAP） | 无个性化配置 | AS根据用户偏好定制显示策略 |
| 欠费停机 | 无法实时生效 | ODB触发AS拒绝呼入/呼出 |
| 多终端注册 | 无法关联同一IMPU下的多设备 | TAS维护多设备绑定关系 |

**设计意图**：将"注册管理"（S-CSCF职责）与"业务逻辑"（AS职责）彻底解耦。S-CSCF作为无状态的信令路由器，不维护业务状态；AS作为有状态的业务引擎，通过Third-Party Registration感知用户在线状态并初始化业务上下文。

## 二、Filter Criteria结构深度解析

### 2.1 用户签约数据下载

S-CSCF在IMS-AKA认证成功后，通过Cx SAR/SAA接口从HSS下载完整用户签约数据（TS 29.228 Section 7.6.2）。下载的核心数据结构如下：

```mermaid
graph TB
    subgraph "IMS User Data (TS 29.228 Annex A)"
        UD["User Data<br/>XML Document"]
        UD --> SP["Service Profile"]
        UD --> PI["Public Identity Set"]

        SP --> FC1["Filter Criteria 1"]
        SP --> FC2["Filter Criteria 2"]
        SP --> FC3["Filter Criteria N..."]

        FC1 --> TP1["Trigger Point<br/>(SPT集合)"]
        FC1 --> AS1["Application Server<br/>sip:tas.ims.mnc000.mcc460.3gppnetwork.org"]
        FC1 --> PR1["Profile Part Indicator<br/>(Registered/Unregistered)"]

        TP1 --> SPT1["SPT: Method = REGISTER"]
        TP1 --> SPT2["SPT: Session Case = Originating"]
        TP1 --> SPT3["SPT: Session Description<br/>Line = a=sendrecv"]

        PI --> IMPU1["IMPU: sip:+86138xxx@ims"]
        PI --> IMPU2["IMPU: tel:+86138xxx"]
        PI --> Barring["Barring Indication<br/>(是否允许注册)"]
    end

    style UD fill:#e3f2fd
    style SP fill:#fff3e0
    style FC1 fill:#e8f5e9
    style FC2 fill:#e8f5e9
    style TP1 fill:#fce4ec
    style AS1 fill:#f3e5f5
```

### 2.2 Filter Criteria XML结构（TS 29.228 Annex A.2）

以下是一个典型的Filter Criteria XML片段，对应 **MMTel语音补充业务**的触发规则：

```xml
<FilterCriteria>
  <Priority>0</Priority>
  <TriggerPoint>
    <ConditionTypeCNF>0</ConditionTypeCNF>  <!-- 0=AND, 1=OR -->
    <SPT>
      <ConditionNegated>0</ConditionNegated>  <!-- 0=不取反 -->
      <Group>0</Group>
      <Method>REGISTER</Method>
    </SPT>
    <SPT>
      <ConditionNegated>0</ConditionNegated>
      <Group>0</Group>
      <Header>
        <HeaderName>Content-Type</HeaderName>
        <HeaderContent>application/reginfo+xml</HeaderContent>
      </Header>
    </SPT>
  </TriggerPoint>
  <ApplicationServer>
    <ServerName>sip:tas.ims.mnc000.mcc460.3gppnetwork.org</ServerName>
    <DefaultHandling>0</DefaultHandling>  <!-- 0=继续会话, 1=终止会话 -->
    <ServiceInfo>ims-mmtel-voice</ServiceInfo>
  </ApplicationServer>
  <ProfilePartIndicator>0</ProfilePartIndicator>  <!-- 0=Registered -->
</FilterCriteria>
```

### 2.3 SPT（Service Point Trigger）类型汇总

Filter Criteria的核心匹配逻辑由SPT（Service Point Trigger）定义。每个SPT对应SIP消息中的一个可检测字段：

| SPT类型 | XML标签 | 匹配对象 | 示例 |
|---------|---------|---------|------|
| Method | `<Method>` | SIP方法名 | `REGISTER`, `INVITE`, `SUBSCRIBE` |
| Session Case | `<SessionCase>` | 会话方向 | `0`=Originating, `1`=Terminating, `2`=Originating_Unregistered |
| Session Description | `<SessionDescription>` | SDP行内容 | `s=`, `a=sendrecv` |
| SIP Header | `<Header>` | SIP头部字段 | `Content-Type: application/sdp` |
| Request-URI | `<RequestURI>` | 请求URI中的用户部分 | `+8613800138000` |
| Registration Type | `<RegistrationType>` | 注册事件类型 | `0`=Initial, `1`=Re-registration, `2`=De-registration |

### 2.4 ConditionTypeCNF逻辑组合

多个SPT之间通过 `ConditionTypeCNF` 决定组合逻辑：

| 值 | 含义 | 匹配规则 |
|----|------|---------|
| 0 | CNF（合取范式） | **所有**SPT必须同时满足（AND逻辑） |
| 1 | DNF（析取范式） | **任意**SPT满足即可（OR逻辑） |

Group字段进一步允许将SPT分组：同一Group内的SPT之间是OR关系，不同Group之间是AND关系。这提供了极强的匹配灵活性。

## 三、Third-Party Registration完整信令时序图

以下基于 **TS 23.228 Section 5.3.5.1** 的完整Third-Party Registration流程：

```mermaid
sequenceDiagram
    participant UE
    participant PCSCF as P-CSCF
    participant SCSCF as S-CSCF
    participant HSS
    participant TAS as TAS/AS
    participant MMTel as MMTel AS
    participant SCC as SCC AS

    Note over UE,SCSCF: 前置条件: IMS注册200 OK已返回UE
    Note over SCSCF: S-CSCF已通过Cx SAA获取<br/>User Data + Filter Criteria

    Note over SCSCF,TAS: 阶段1: 评估Filter Criteria - REGISTER触发
    SCSCF->>SCSCF: 遍历Filter Criteria列表<br/>按Priority排序
    SCSCF->>SCSCF: 匹配SPT: Method=REGISTER<br/>SessionCase=Originating<br/>ProfilePartIndicator=Registered
    
    Note over SCSCF,TAS: 阶段2: 向TAS发起Third-Party REGISTER
    SCSCF->>TAS: SIP REGISTER<br/>(From: S-CSCF, To: IMPU,<br/>Contact: IMPU@S-CSCF,<br/>expires=3600, Call-ID: scscf-tas-1)
    Note right of SCSCF: S-CSCF充当UA<br/>代表UE向AS注册
    
    TAS->>TAS: 验证S-CSCF身份<br/>检查用户签约数据
    TAS->>TAS: 初始化用户业务上下文<br/>加载CFU/CFC/CW/CLIR配置
    TAS-->>SCSCF: 200 OK (REGISTER)

    Note over SCSCF,MMTel: 阶段3: 向MMTel AS发起Third-Party REGISTER
    SCSCF->>MMTel: SIP REGISTER<br/>(From: S-CSCF, To: IMPU,<br/>expires=3600)
    MMTel->>MMTel: 激活MMTel语音补充业务<br/>OIP/OIR/CDIV/CW
    MMTel-->>SCSCF: 200 OK (REGISTER)

    Note over SCSCF,SCC: 阶段4: 向SCC AS发起Third-Party REGISTER
    SCSCF->>SCC: SIP REGISTER<br/>(From: S-CSCF, To: IMPU,<br/>expires=3600)
    SCC->>SCC: 注册T-ADS功能<br/>建立Multi-Device绑定
    SCC-->>SCSCF: 200 OK (REGISTER)

    Note over SCSCF,TAS: 阶段5: Filter Criteria中的INVITE触发规则生效
    Note over SCSCF: 后续UE发起INVITE时:<br/>匹配Filter Criteria(方法=INVITE,<br/>SessionCase=Originating)<br/>→ SIP INVITE先路由到TAS<br/>→ TAS执行补充业务逻辑<br/>→ TAS转发到目标
```

### 3.1 Third-Party REGISTER消息IE解析

S-CSCF向AS发送的Third-Party REGISTER与UE的初始REGISTER有本质区别：

| IE | UE REGISTER | Third-Party REGISTER |
|----|------------|---------------------|
| From | `<sip:IMPU@ims...>;tag=ue-tag` | `sip:scscf.ims...;tag=scscf-tag` |
| To | `<sip:IMPU@ims...>` | `<sip:IMPU@ims...>` |
| Contact | `<sip:IMPU@[UE_IP]:port>` | `<sip:IMPU@scscf.ims...>` |
| Call-ID | UE生成 | S-CSCF生成（独立命名空间） |
| CSeq | S-CSCF内部分配 | S-CSCF内部分配 |
| Expires | UE请求的值 | 与UE注册有效期同步 |
| Route | 无（P-CSCF已添加） | 可能包含AS的Route信息 |
| P-Charging-Vector | 无 | `icid-value=xxx;orig-ioi=xxx` |
| P-Visited-Network-ID | 无 | 拜访网络标识 |

**关键区别**：Third-Party REGISTER中，S-CSCF扮演UA角色，From头是S-CSCF自身，Contact指向S-CSCF而非UE。AS因此知道用户已注册，且后续SIP请求需经由该S-CSCF路由。

## 四、业务触发机制：INVITE如何经过AS

Third-Party Registration建立了"用户在线"的感知，而真正的业务逻辑在**后续SIP请求触发**时执行。以下以主叫INVITE触发TAS为例：

### 4.1 INVITE触发Filter Criteria匹配流程

```mermaid
flowchart TD
    INVITE["UE → P-CSCF → S-CSCF<br/>SIP INVITE"] --> EVAL["S-CSCF评估<br/>Filter Criteria列表"]

    EVAL --> FC1{"FC Priority=0<br/>Method=INVITE<br/>SessionCase=Originating"}
    FC1 -->|"匹配"| ROUTE1["路由到TAS<br/>执行OCSI逻辑"]
    FC1 -->|"不匹配"| FC2

    ROUTE1 --> TAS_CHECK["TAS检查:<br/>- CLIR是否激活?<br/>- 呼叫限制?<br/>- CDIV触发?"]
    TAS_CHECK -->|"无前转"| FORWARD["TAS → S-CSCF<br/>→ I-CSCF → 被叫"]
    TAS_CHECK -->|"有CFU"| DIVERT["TAS执行呼叫前转<br/>修改Request-URI<br/>重新路由到前转目标"]
    TAS_CHECK -->|"有呼出限制"| REJECT["TAS返回<br/>SIP 603 Decline<br/>或403 Forbidden"]

    FC2{"FC Priority=1<br/>Method=INVITE<br/>SessionCase=Terminating"} -->|"匹配"| ROUTE2["路由到TAS<br/>执行TCSI逻辑"]

    ROUTE2 --> TAS_T["TAS检查:<br/>- CFB/CFNR/CFNL?<br/>- 呼叫等待?<br/>- OIP/OIR?"]

    style INVITE fill:#e1f5fe
    style TAS_CHECK fill:#fff3e0
    style TAS_T fill:#fce4ec
```

### 4.2 OCSI与TCSI触发点

S-CSCF对Filter Criteria的评估分两个独立维度：

| 触发类型 | 全称 | 触发时机 | 典型业务 |
|---------|------|---------|---------|
| OCSI | Originating CAMEL Subscription Information | UE发起INVITE（主叫侧） | CLIR、呼出限制、预付费计费 |
| TCSI | Terminating CAMEL Subscription Information | INVITE到达被叫S-CSCF | CFB/CFNR/CFNL、呼入限制、CNAP |

> 注：OCSI/TCSI术语源自CAMEL智能网架构（TS 23.008），IMS中通过Filter Criteria的SessionCase字段实现等价功能。

### 4.3 INVITE触发AS路由——完整信令流

```mermaid
sequenceDiagram
    participant UE_O as UE (Calling)
    participant PCSCF_O as P-CSCF (O)
    participant SCSCF_O as S-CSCF (O)
    participant TAS_O as TAS (Originating)
    participant ICSCF_T as I-CSCF (T)
    participant SCSCF_T as S-CSCF (T)
    participant TAS_T as TAS (Terminating)
    participant PCSCF_T as P-CSCF (T)
    participant UE_T as UE (Called)

    UE_O->>PCSCF_O: SIP INVITE
    PCSCF_O->>SCSCF_O: SIP INVITE
    
    Note over SCSCF_O: 匹配Filter Criteria<br/>SessionCase=Originating<br/>Method=INVITE → Route to TAS
    
    SCSCF_O->>TAS_O: SIP INVITE (OCSI触发)
    Note over TAS_O: 执行主叫侧业务逻辑:<br/>1. 检查CLIR<br/>2. 检查呼出限制(ODB)<br/>3. 预付费扣费授权
    TAS_O->>SCSCF_O: SIP INVITE (业务处理完成,继续路由)
    
    SCSCF_O->>ICSCF_T: SIP INVITE (跨域路由)
    ICSCF_T->>SCSCF_T: SIP INVITE
    
    Note over SCSCF_T: 匹配Filter Criteria<br/>SessionCase=Terminating<br/>Method=INVITE → Route to TAS
    
    SCSCF_T->>TAS_T: SIP INVITE (TCSI触发)
    Note over TAS_T: 执行被叫侧业务逻辑:<br/>1. 检查CFB/CFNR<br/>2. 检查呼入限制<br/>3. 呼叫等待判断
    TAS_T->>SCSCF_T: SIP INVITE (无前转,继续路由)
    
    SCSCF_T->>PCSCF_T: SIP INVITE
    PCSCF_T->>UE_T: SIP INVITE
```

## 五、状态转换与生命周期管理

### 5.1 Filter Criteria注册状态转换

```mermaid
stateDiagram-v2
    [*] --> User_Data_Download: Cx SAA<br/>(IMS注册认证成功)
    User_Data_Download --> FC_Evaluation: 解析Filter Criteria<br/>按Priority排序
    
    FC_Evaluation --> TP_Reg: FC匹配REGISTER<br/>ProfilePartIndicator=Registered
    FC_Evaluation --> TP_UnReg: FC匹配REGISTER<br/>ProfilePartIndicator=Unregistered
    
    TP_Reg --> 3rd_Reg_TAS: Third-Party REGISTER → TAS
    TP_Reg --> 3rd_Reg_MMTel: Third-Party REGISTER → MMTel AS
    TP_Reg --> 3rd_Reg_SCC: Third-Party REGISTER → SCC AS
    
    3rd_Reg_TAS --> AS_Context_Active: TAS业务上下文激活<br/>(CFU/CW/CLIR配置加载)
    3rd_Reg_MMTel --> AS_Context_Active
    3rd_Reg_SCC --> AS_Context_Active
    
    AS_Context_Active --> INVITE_Trigger: 后续INVITE匹配FC<br/>触发到AS
    AS_Context_Active --> ReReg_Trigger: UE重注册<br/>触发Third-Party REGISTER刷新
    AS_Context_Active --> DeReg_Trigger: UE去注册/注册过期<br/>触发Third-Party De-Register
    
    DeReg_Trigger --> AS_Context_Cleanup: AS清除业务上下文
    AS_Context_Cleanup --> [*]
    
    TP_UnReg --> UnReg_Service: 未注册业务处理<br/>(如未注册呼入前转至语音信箱)
    UnReg_Service --> [*]
```

### 5.2 注册过期与Third-Party De-Register

当IMS注册过期或UE主动去注册时，S-CSCF必须向所有已发起Third-Party Registration的AS发送**REGISTER with expires=0**：

```
REGISTER sip:tas.ims.mnc000.mcc460.3gppnetwork.org SIP/2.0
From: <sip:scscf.ims.mnc000.mcc460.3gppnetwork.org>;tag=de-reg-001
To: <sip:+8613800138000@ims.mnc000.mcc460.3gppnetwork.org>
Contact: <sip:+8613800138000@scscf.ims.mnc000.mcc460.3gppnetwork.org>
Expires: 0
Call-ID: scscf-tas-1@scscf.ims.mnc000.mcc460.3gppnetwork.org
CSeq: 2 REGISTER
```

TAS收到expires=0后，执行以下清理：
1. 释放用户业务上下文
2. 停止所有激活的补充业务计时器
3. 若用户签约了"未注册"状态的Filter Criteria（`ProfilePartIndicator=Unregistered`），则激活未注册业务处理（如将呼入前转至语音信箱）

## 六、SIP SUBSCRIBE/NOTIFY与补充业务配置

### 6.1 UE订阅注册事件包

IMS注册完成后，UE可通过SIP SUBSCRIBE订阅**reg事件包（registration event package）**（RFC 3680），获取自身注册状态变化通知：

```
SUBSCRIBE sip:+8613800138000@ims.mnc000.mcc460.3gppnetwork.org SIP/2.0
Event: reg
Accept: application/reginfo+xml
Expires: 3600
Contact: <sip:+8613800138000@[UE_IP]:port_us>
```

S-CSCF通过NOTIFY返回当前注册状态：

```xml
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo" state="full" version="0">
  <registration aor="sip:+8613800138000@ims.mnc000.mcc460.3gppnetwork.org"
                id="reg1" state="active">
    <contact id="c1" state="active" event="registered" expires="3600">
      <uri>sip:+8613800138000@[UE_IP]:port_us</uri>
    </contact>
  </registration>
</reginfo>
```

### 6.2 AS订阅UE注册状态

AS（如TAS）在收到Third-Party Registration后，也可向S-CSCF订阅reg事件包，以感知UE的去注册事件：

```mermaid
sequenceDiagram
    participant TAS
    participant SCSCF as S-CSCF
    participant UE

    TAS->>SCSCF: SIP SUBSCRIBE (Event: reg)<br/>订阅IMPU注册状态
    SCSCF-->>TAS: 200 OK (SUBSCRIBE)
    
    Note over UE: UE网络异常断开<br/>注册超时
    SCSCF->>TAS: SIP NOTIFY<br/>(reginfo: state=terminated)
    Note over TAS: TAS感知UE离线<br/>激活未注册前转逻辑
    
    Note over UE: UE重新上线<br/>完成IMS注册
    SCSCF->>SCSCF: 触发Third-Party REGISTER刷新
    SCSCF->>TAS: Third-Party REGISTER (expires=3600)
    SCSCF->>TAS: SIP NOTIFY<br/>(reginfo: state=active)
```

### 6.3 MMTel补充业务配置交互

TS 24.173定义了MMTel补充业务通过SIP SUBSCRIBE/NOTIFY和SIP PUBLISH进行配置。以**呼叫前转无条件（CFU）**为例：

**UE激活CFU**：
```
PUBLISH sip:+8613800138000@ims.mnc000.mcc460.3gppnetwork.org SIP/2.0
Content-Type: application/xml

<?xml version="1.0"?>
<ims-3gpp-completedata xmlns="urn:xml:ns:ims-3gpp-completedata">
  <communication-diversion-condition>
    <diversion-not-reason></diversion-not-reason>
    <forward-to>
      <target>sip:+8613900139000@ims.mnc000.mcc460.3gppnetwork.org</target>
    </forward-to>
  </communication-diversion-condition>
</ims-3gpp-completedata>
```

**业务流程链**：UE PUBLISH → S-CSCF（匹配Filter Criteria: Method=PUBLISH）→ TAS → TAS存储CFU配置 → 200 OK。后续呼入INVITE到达TAS时，TAS执行前转逻辑。

## 七、Filter Criteria优先级冲突与处理策略

### 7.1 优先级规则（TS 23.228 Section 5.3.5.2）

当多条Filter Criteria同时匹配时，S-CSCF按以下规则处理：

| 规则 | 说明 |
|------|------|
| Priority值越小越优先 | Priority=0最高，依次递增 |
| 同Priority按AS地址排序 | 字典序排列，确保确定性 |
| 高优先FC处理完成后继续 | 除非AS返回终止指示 |
| DefaultHandling决定失败策略 | 0=继续后续FC评估，1=终止会话 |

### 7.2 典型Filter Criteria配置示例

| Priority | Method | SessionCase | 目标AS | 业务 |
|----------|--------|-------------|--------|------|
| 0 | REGISTER | Originating | TAS | Third-Party Registration |
| 1 | REGISTER | Originating | MMTel AS | MMTel业务初始化 |
| 2 | INVITE | Originating | TAS | 主叫补充业务（CLIR/呼出限制） |
| 3 | INVITE | Terminating | TAS | 被叫补充业务（CFB/CFNR/呼入限制） |
| 4 | INVITE | Terminating | SCC AS | T-ADS多设备路由决策 |
| 5 | SUBSCRIBE | Originating | TAS | 补充业务订阅管理 |
| 6 | PUBLISH | Originating | TAS | 补充业务配置更新 |
| 7 | *（任意） | Unregistered | Voicemail AS | 未注册呼入前转语音信箱 |

## 八、实战抓包识别与排错

### 8.1 Wireshark过滤表达式

```
# 过滤Third-Party REGISTER（S-CSCF → AS）
sip.Method == "REGISTER" && sip.From contains "scscf"

# 过滤特定IMPU的所有Filter Criteria触发
sip.To contains "+8613800138000"

# 过滤Cx Diameter交互（Filter Criteria下载）
diameter.Command-Code == 301   # SAR/SAA

# 过滤SIP NOTIFY（reg事件包）
sip.Method == "NOTIFY" && sip.Event == "reg"

# 过滤SIP PUBLISH（补充业务配置）
sip.Method == "PUBLISH"
```

### 8.2 关键识别特征

| 观察点 | Third-Party REGISTER特征 | UE REGISTER特征 |
|--------|------------------------|----------------|
| From头 | S-CSCF URI | UE IMPU |
| Contact头 | S-CSCF地址 | UE IP:Port |
| IPSec保护 | 无（网络内部） | 有（受保护端口） |
| 路径 | S-CSCF → AS（直连） | UE → P-CSCF → I-CSCF → S-CSCF |
| P-Charging-Vector | 有 | 可选 |

### 8.3 常见故障与排错

| 故障现象 | 可能原因 | 排错方法 |
|----------|---------|---------|
| IMS注册成功但补充业务不生效 | Third-Party REGISTER未发出或AS未响应 | 检查S-CSCF日志中的FC评估记录；检查S-CSCF→AS的SIP REGISTER；检查AS是否返回200 OK |
| 呼叫前转不执行 | TAS未正确存储CFU配置 | 检查UE PUBLISH是否到达TAS；检查TAS日志中的CFU规则；验证Filter Criteria中INVITE→TAS规则存在 |
| 主叫INVITE被错误路由 | Filter Criteria Priority配置冲突 | 检查HSS用户签约数据中的FC Priority顺序；确认S-CSCF按Priority评估 |
| 用户已去注册但呼入仍振铃 | S-CSCF未发送Third-Party De-Register | 检查S-CSCF在注册过期后是否向AS发送REGISTER expires=0 |
| AS收到INVITE但无用户上下文 | Third-Party REGISTER被AS拒绝 | 检查AS日志中REGISTER处理结果码；检查AS与HSS之间的Sh接口用户数据同步 |
| 未注册前转不工作 | ProfilePartIndicator=Unregistered的FC缺失 | 检查HSS签约数据中是否配置了Unregistered类型的Filter Criteria |
## 九、Sh接口与Cx接口协同

### 9.1 AS获取用户数据的两种途径

AS需要用户业务配置数据来执行补充业务逻辑，有两种获取途径：

| 途径 | 接口 | 协议 | 数据来源 | 适用场景 |
|------|------|------|---------|---------|
| Cx接口 | I-CSCF/S-CSCF ↔ HSS | Diameter | HSS直出 | 注册/认证相关 |
| Sh接口 | AS ↔ HSS | Diameter | HSS直出 | 业务数据查询/更新 |

Sh接口（TS 29.328）允许AS主动查询和更新用户数据，关键命令：

| 命令 | 用途 |
|------|------|
| UDR/UDA | 用户数据查询（User-Data-Request/Answer） |
| PUR/PUA | 用户数据更新（Profile-Update-Request/Answer） |
| SNR/SNA | 订阅通知（Subscribe-Notifications-Request/Answer） |

### 9.2 Sh接口数据操作示例

```
AS → HSS: Sh-UDR (User-Data-Request)
  - User-Identity: sip:+8613800138000@ims...
  - Data-Reference: RepositoryData (0)
  - Service-Indication: "MMTel-CDIV"

HSS → AS: Sh-UDA (User-Data-Answer)
  - User-Data:
    <RepositoryData>
      <ServiceIndication>MMTel-CDIV</ServiceIndication>
      <ServiceData>
        <CDIV active="true">
          <ForwardTo>sip:+8613900139000@ims...</ForwardTo>
          <NoReplyTimer>20</NoReplyTimer>
        </CDIV>
      </ServiceData>
    </RepositoryData>
```

AS通过Sh接口获取CDIV（Communication Diversion）配置后，在呼入INVITE到达时执行前转判断。

## 十、5GC与EPC场景下的差异

| 维度 | VoNR (5GC) | VoLTE (EPC) |
|------|-----------|-------------|
| Filter Criteria来源 | HSS (via Cx) | HSS (via Cx)，相同机制 |
| Third-Party Reg传输承载 | 5QI=5 QoS Flow | QCI=5 EPS Bearer |
| AS间通信 | ISC接口（SIP） | ISC接口（SIP），相同 |
| Sh接口 | Diameter（与4G相同） | Diameter |
| 策略控制联动 | PCF (N7) → SMF | PCRF (Gx) → PGW |
| 计费接口 | Nchf (HTTP/JSON) | Rf/Ro (Diameter) |
| AS发现方式 | DNS/NAPTR + S-CSCF路由 | 相同 |
| Multi-Device支持 | SCC AS + T-ADS | 相同机制 |

**核心结论**：Third-Party Registration和Filter Criteria机制在5GC和EPC中**完全一致**——它们是IMS层面的机制，与底层承载技术（QoS Flow vs EPS Bearer）无关。这是IMS架构"接入无关性"的典型体现。

## 常见问题

**Q1: Third-Party Registration和UE的SIP REGISTER有什么关系？是否独立？**

A: 完全独立但有时序依赖。UE的REGISTER建立UE与S-CSCF之间的注册绑定；Third-Party REGISTER发生在UE注册成功后，由S-CSCF**自动发起**到AS，UE完全不感知。Third-Party REGISTER的From头是S-CSCF而非UE，它们使用不同的Call-ID命名空间。但Third-Party REGISTER的expires值必须与UE注册的expires同步——UE重注册时，S-CSCF同步刷新所有Third-Party Registration。

**Q2: 如果AS不可达，S-CSCF如何处理INVITE？**

A: 取决于Filter Criteria中的`DefaultHandling`字段（TS 29.228 Annex A）：
- `DefaultHandling=0`（继续会话）：S-CSCF跳过该AS，继续评估后续Filter Criteria并正常路由INVITE。业务降级但呼叫不中断。
- `DefaultHandling=1`（终止会话）：S-CSCF直接返回SIP 503 Service Unavailable，呼叫失败。适用于关键AS（如预付费计费），不可跳过。

**Q3: 用户为什么感觉不到Third-Party Registration的存在？**

A: 因为Third-Party Registration是**网络内部行为**，完全在S-CSCF和AS之间完成，不涉及UE。UE的IMS注册延迟中已包含了Third-Party Registration的耗时（通常增加50-200ms），但对用户透明。UE只知道注册成功或失败，不知道后台有多少个AS被通知。

**Q4: Filter Criteria中的SessionCase=Unregistered有什么特殊用途？**

A: 当用户**未注册**但有呼入时，S-CSCF仍会评估`ProfilePartIndicator=Unregistered`的Filter Criteria。典型场景是：用户关机/离线后，呼入INVITE到达S-CSCF，匹配Unregistered FC，路由到语音信箱AS或执行CFU（无条件前转）。这确保了即使用户不在线，呼入业务也能正常处理。

**Q5: 一个用户最多能配置多少条Filter Criteria？实际网络中典型配置是多少？**

A: 3GPP规范未定义硬性上限，但各厂商有实现限制（通常32-64条/用户）。实际网络中，普通VoNR用户的典型配置为3-5条：Third-Party Reg→TAS、Third-Party Reg→MMTel、INVITE(O)→TAS、INVITE(T)→TAS、INVITE(T)→SCC AS。企业用户或VIP用户可能增加预付费计费AS、录音AS等触发规则，达到8-10条。

## 参考来源

1. [3GPP TS 23.228 V18.x.x](https://www.3gpp.org/DynaReport/23228.htm) — Section 5.3.5: Third-Party Registration procedures, Section 5.3.5.1: Third-Party Registration for registered users
2. [3GPP TS 29.228 V18.x.x](https://www.3gpp.org/DynaReport/29228.htm) — Annex A: XML Schema for Filter Criteria, Section 7.6: Cx SAR/SAA user data download
3. [3GPP TS 24.229 V18.x.x](https://www.3gpp.org/DynaReport/24229.htm) — Section 5.1.1.6: S-CSCF Third-Party Registration procedures
4. [3GPP TS 24.173 V18.x.x](https://www.3gpp.org/DynaReport/24173.htm) — MMTel supplementary services: OIP, OIR, CDIV, CW, ACR, MCID
5. [3GPP TS 29.328 V18.x.x](https://www.3gpp.org/DynaReport/29328.htm) — Sh interface: AS-HSS data manipulation for supplementary service data
6. [RFC 3680](https://www.rfc-editor.org/rfc/rfc3680) — A Session Initiation Protocol (SIP) Event Package for Registrations
7. [3glteinfo - IMS Third Party Registration](https://www.3glteinfo.com/ims-third-party-registration/) — Third-Party Registration flow analysis and AS interaction

---

> 本文由「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)