<!-- title: 5G ATSSS五径分流与MA-PDU会话博弈 -->
<!-- domain: core-network -->

# 5G ATSSS五径分流与MA-PDU会话博弈

## 一、ATSSS机制定位与设计意图

ATSSS（Access Traffic Steering, Switching and Splitting）是3GPP自Rel-16引入、Rel-17/18持续增强的核心网关键技术，定义于TS 23.501 Section 5.32和TS 23.502 Section 4.22。其核心目标是让同一PDU会话同时承载在3GPP接入（NR/LTE）和非3GPP接入（Wi-Fi，经N3IWF/TNGF）之上，实现业务流在两条路径间的**导向（Steering）、切换（Switching）、拆分（Splitting）**三种操作。

**设计意图**：传统方案中，UE同时连接5G和Wi-Fi时，每个应用只能选择一条路径。ATSSS打破了这个限制——它允许运营商**在SMF/PCF策略控制下**，将同一用户的流量在两条接入链路上智能分配。对运营商而言，这意味着Wi-Fi offload从"要么全走5G、要么全走Wi-Fi"的粗粒度选择，变成了**逐流、逐包级别的精细调度**。

关键架构实体如下：

```mermaid
graph TB
    subgraph UE侧
        A1[MPTCP Client<br/>TCP流量多路径]
        A2[ATSSS-LL功能<br/>非TCP流量分流]
        A3[PMF客户端<br/>性能测量]
        A1 --> A4[MA-PDU会话<br/>用户面承载]
        A2 --> A4
        A3 -.->|RTT/丢包探测| A1
        A3 -.->|RTT/丢包探测| A2
    end

    subgraph 网络侧
        B1[SMF<br/>ATSSS策略下发]
        B2[UPF/PSA<br/>MPTCP Proxy + ATSSS-LL]
        B3[PCF<br/>ATSSS策略决策]
        B4[AMF<br/>NAS透传]
        B3 -->|PCC Rules| B1
        B1 -->|N4 ATSSS Rules| B2
        B1 -->|NAS ATSSS Rules| B4
        B4 -->|DL NAS Transport| UE侧
    end

    subgraph 双接入
        C1[3GPP接入<br/>gNB/ng-eNB]
        C2[非3GPP接入<br/>N3IWF/TNGF]
    end

    A4 -->|N3| C1
    A4 -->|NWtt/Yaan3| C2
    C1 -->|N3| B2
    C2 -->|N3| B2
    B2 -->|N6| DN[Data Network]
```

## 二、MA-PDU会话建立信令流全链路拆解

### 2.1 建立场景分类

根据TS 23.502 Section 4.22.2，MA-PDU会话的建立有三种场景：

| 场景 | 描述 | TS 23.502章节 |
|------|------|--------------|
| 初始建立（双接入同时） | UE在3GPP和非3GPP接入均已注册，一次性建立MA-PDU会话 | Section 4.22.2.1 |
| 先建后扩 | 先在一条接入建立普通PDU会话，再将其扩展为MA-PDU | Section 4.22.2.2 |
| 单接入+EPC | UE在3GPP接入连接EPC，在非3GPP接入连接5GC | Section 4.22.2.3 |

### 2.2 初始MA-PDU会话建立完整信令流

以下是最复杂的"初始建立"场景的完整信令时序图，基于TS 23.502 Section 4.22.2.1：

```mermaid
sequenceDiagram
    participant UE
    participant AMF_3G as AMF(3GPP接入)
    participant AMF_N3 as AMF(非3GPP接入)
    participant SMF
    participant PCF
    participant UDM
    participant UPF as UPF/PSA
    participant N3IWF

    Note over UE,N3IWF: 前提：UE已通过3GPP和非3GPP接入完成注册

    rect rgb(230,240,255)
    Note over UE,AMF_3G: Step 1-2: UE发起MA-PDU会话建立请求
    UE->>AMF_3G: UL NAS Transport<br/>PDU Session Establishment Request<br/>MA-PDU Request=1<br/>ATSSS Capability Indication
    AMF_3G->>SMF: Nsmf_PDUSession_CreateSMContext Request<br/>{MA-PDU Indicator, ATSSS Capability,<br/>S-NSSAI, DNN, 3GPP Access Type}
    end

    rect rgb(255,240,230)
    Note over SMF,UDM: Step 3-4: 订阅数据获取与策略决策
    SMF->>UDM: Nudm_SDM_Get<br/>{SUPI, DNN, S-NSSAI}
    UDM-->>SMF: Subscription Data<br/>{ATSSS Allowed, Steering Mode,<br/>MA-PDU Permitted}
    SMF->>PCF: Npcf_SMPolicyControl_Create<br/>{SUPI, DNN, MA-PDU Indicator,<br/>ATSSS Capability}
    PCF-->>SMF: PCC Rules + ATSSS Policy<br/>{Steering Mode, Traffic Filters,<br/>Thresholds, Measurement Req}
    end

    rect rgb(230,255,230)
    Note over SMF,UPF: Step 5-6: UPF选择与N4会话建立
    SMF->>UPF: N4 Session Establishment Request<br/>{ATSSS Rules for UPF,<br/>PDR/FAR/QER per access,<br/>MPTCP Proxy Config,<br/>PMF Configuration}
    UPF-->>SMF: N4 Session Establishment Response<br/>{F-TEID (3GPP), F-TEID (Non-3GPP),<br/>MPTCP Proxy Address}
    end

    rect rgb(255,230,255)
    Note over SMF,UE: Step 7-9: 向UE返回ATSSS规则
    SMF-->>AMF_3G: Nsmf_PDUSession_CreateSMContext Response<br/>{N2 SM Info, PDU Session Accept,<br/>ATSSS Rules for UE}
    AMF_3G->>UE: DL NAS Transport + N2 RAN msg<br/>PDU Session Establishment Accept<br/>{MA-PDU Accepted, Steering Mode,<br/>ATSSS Rules, MPTCP Proxy Info,<br/>3GPP Tunnel Info}
    end

    rect rgb(240,240,230)
    Note over UE,N3IWF: Step 10-12: 非3GPP接入路径建立
    UE->>AMF_N3: UL NAS Transport (Non-3GPP)<br/>PDU Session Establishment Request<br/>Existing MA-PDU Session<br/>{PSI, MA-PDU Session ID}
    AMF_N3->>SMF: Nsmf_PDUSession_UpdateSMContext<br/>{Add Non-3GPP Access,<br/>MA-PDU Session ID}
    SMF->>UPF: N4 Session Modification<br/>{Add Non-3GPP PDR/FAR,<br/>F-TEID for Non-3GPP}
    UPF-->>SMF: N4 Response

    SMF-->>AMF_N3: Nsmf_PDUSession_UpdateSMContext Response
    AMF_N3->>N3IWF: NWu Session Setup
    N3IWF-->>UE: IKEv2/IPsec Tunnel Established
    AMF_N3-->>UE: DL NAS Transport<br/>PDU Session Establishment Accept<br/>{Non-3GPP Tunnel Info}
    end

    Note over UE,UPF: MA-PDU会话建立完成<br/>3GPP和Non-3GPP双路径均就绪
```

### 2.3 关键Information Element逐字段解析

**Step 1中的UL NAS Transport（TS 24.501 Section 8.2.6）核心IE：**

| IE名称 | 长度 | 取值/含义 | 必选/可选 |
|--------|------|----------|----------|
| Payload container type | 1字节 | N1 SM container (=1) | M |
| Payload container | 变长 | 包含PDU Session Establishment Request | M |
| PDU session ID | 1字节 | 会话标识（0-255） | M |
| Request type | 1字节 | Initial request (=1) | M |
| MA-PDU session request | 1字节 | Requested MA-PDU (=1) | O |
| ATSSS capability | 变长 | UE支持的steering functionality列表 | O |
| DNN | 变长 | Data Network Name | O |
| S-NSSAI | 变长 | Network Slice Selection | O |

**ATSSS Capability IE结构（TS 24.501 Section 9.11.4.26）：**

```
ATSSS Capability
├── ATSSS-LL Indicator (1 bit) — UE支持ATSSS-LL功能
├── MPTCP Indicator (1 bit) — UE支持MPTCP功能
├── MPTCP with MP-QUIC Indicator (1 bit) — UE支持MP-QUIC (Rel-17+)
└── Spare bits (5 bits) — 保留
```

**SMF下发给UE的ATSSS Rules结构（TS 24.193 Section 6.2）：**

| 字段 | 说明 |
|------|------|
| Rule ID | 规则标识 |
| Traffic Description | SDF过滤器（五元组或App ID） |
| Steering Functionality | MPTCP / ATSSS-LL |
| Steering Mode | Active-Standby / Smallest-Delay / Load-Balancing / Priority-based |
| Priority | 规则优先级 |
| Measurement Assistance | PMF测量配置（RTT探测间隔等） |
| Thresholds | 性能阈值（RTT上限、丢包率上限等） |

## 三、五种Steering模式深度解析

ATSSS定义了五种steering模式，每种模式的决策逻辑和适用场景截然不同：

### 3.1 Active-Standby模式

**机制（TS 23.501 Section 5.32.2.1）**：所有流量走Active接入，Standby接入仅用于热备。当Active接入链路中断（通过PMF探测或NAS信令检测），流量**整体切换**到Standby接入。

**决策逻辑**：
- UE侧：根据SMF下发的规则，将所有匹配流量发往Active接入的N3隧道
- UPF侧：同理，下行流量仅从Active接入的N3隧道发送
- 切换触发：PMF探测连续N次超时，或收到Access层面的链路失败指示

**运营商博弈**：Active-Standby是成本最低的模式——不需要实时测量，不需要复杂调度算法。但它的带宽利用率仅用了单链路，适合对可靠性要求高但对吞吐量不敏感的场景（如VoWiFi备份）。

### 3.2 Smallest Delay模式

**机制（TS 23.501 Section 5.32.2.2）**：UE和UPF各自独立测量两条接入的RTT，将**每个新流量**导向RTT最小的接入。

```mermaid
flowchart LR
    subgraph PMF测量框架
        A[UE PMF客户端] -->|RTT Probe<br/>间隔=T_ms| B[3GPP PMF端点]
        A -->|RTT Probe<br/>间隔=T_ms| C[Non-3GPP PMF端点]
        B -->|RTT Response| A
        C -->|RTT Response| A
        A -->|RTT_3GPP, RTT_Non3GPP| D[Steering决策<br/>选RTT最小的接入]
    end
    subgraph UPF侧
        E[UPF PMF功能] -->|RTT Probe| F[UE 3GPP PMF]
        E -->|RTT Probe| G[UE Non-3GPP PMF]
        E -->|下行RTT比较| H[下行Steering决策]
    end
```

**PMF（Performance Measurement Function）探测包格式（TS 24.193 Section 7.1）**：

| 字段 | 长度 | 说明 |
|------|------|------|
| PMF Type | 1字节 | 0=RTT测量请求，1=RTT测量响应 |
| Sequence Number | 2字节 | 探测包序号 |
| Timestamp T1 | 8字节 | 发送时间戳（NTP格式） |
| Timestamp T4 | 8字节 | 仅响应包携带：收到请求的时间 |
| RTT = T4 - T1 | - | 单向/双向RTT |

### 3.3 Load-Balancing模式

**机制**：按照SMF下发的**百分比权重**，将流量在两条接入间分配。权重由PCF策略决定，可基于时段、签约、网络负载动态调整。

关键参数：

| 参数 | 取值范围 | 说明 |
|------|---------|------|
| Access Preference | 0-100% | 3GPP接入的流量百分比 |
| Bucket Size | 整数 | 令牌桶大小，控制分割粒度 |
| Split Percentage | 0-100% | 精确的分流比例 |

**ATSSS-LL实现Load-Balancing的分割粒度**：
- **Per-flow级别**：每个新流随机（按概率）分配到某条接入
- **Per-packet级别**：令牌桶算法，逐包交替发送（仅ATSSS-LL支持，MPTCP不适用）

### 3.4 Priority-based模式

**机制**：定义接入优先级列表。流量优先走最高优先级接入；当高优先级接入的**性能低于阈值**时，溢出到低优先级接入。

与Active-Standby的关键区别：Active-Standby只在链路**完全中断**时才切换；Priority-based在**性能劣化**（如RTT超过阈值）时就开始溢出。

### 3.5 MPTCP/MP-QUIC模式

**机制（TS 23.501 Section 5.32.3）**：在传输层实现多路径——UE作为MPTCP Client或MP-QUIC端点，UPF作为MPTCP Proxy或MP-QUIC Proxy，将多路径连接转换为普通连接发送给DN。

### 五种模式对比总表

| 维度 | Active-Standby | Smallest Delay | Load-Balancing | Priority-based | MPTCP/MP-QUIC |
|------|---------------|----------------|----------------|----------------|---------------|
| 分割粒度 | 整体切换 | 逐流 | 逐流/逐包 | 逐流 | 逐包（传输层） |
| 需要PMF测量 | 否（仅检测通断） | 是（RTT） | 否 | 是（RTT/丢包） | 否（拥塞控制自带） |
| 适用流量类型 | 所有 | 所有 | 所有 | 所有 | MPTCP仅TCP；MP-QUIC仅QUIC |
| 非TCP流量处理 | 直接 | 直接 | 直接 | 直接 | 需ATSSS-LL辅助 |
| 额外UPF能力 | 无 | PMF | 令牌桶 | PMF | MPTCP Proxy |
| Rel-16支持 | 是 | 是 | 是 | 是 | MPTCP:是 |
| Rel-17增强 | 否 | 否 | 否 | 否 | MP-QUIC新增 |
| 实现复杂度 | 低 | 中 | 中 | 中 | 高 |

## 四、ATSSS-LL vs MPTCP vs MP-QUIC：三种Steering Functionality的架构博弈

这三种steering functionality是ATSSS的"执行引擎"，决定了流量如何在物理层面被分割。

```mermaid
graph TB
    subgraph "UE协议栈"
        APP[Application<br/>TCP/UDP/QUIC]
        APP -->|TCP流| MPTCP_C[MPTCP Client<br/>Subflow Manager]
        APP -->|QUIC流| MPQUIC_C[MP-QUIC Endpoint]
        APP -->|所有流量| ATSSS_LL[ATSSS-LL<br/>L2/L3分割]
        MPTCP_C --> SF1[Subflow 1<br/>3GPP N3]
        MPTCP_C --> SF2[Subflow 2<br/>Non-3GPP N3]
        MPQUIC_C --> QP1[QUIC Path 1<br/>3GPP N3]
        MPQUIC_C --> QP2[QUIC Path 2<br/>Non-3GPP N3]
        ATSSS_LL --> LL1[Path 1<br/>3GPP N3]
        ATSSS_LL --> LL2[Path 2<br/>Non-3GPP N3]
    end

    subgraph "UPF协议栈"
        SF1 --> MP[MPTCP Proxy<br/>MPTCP→TCP转换]
        SF2 --> MP
        QP1 --> QP[MP-QUIC Proxy<br/>MP-QUIC→QUIC转换]
        QP2 --> QP
        LL1 --> ULL[ATSSS-LL<br/>上行→单路转发]
        LL2 --> ULL
        MP --> DN_TCP[DN Server<br/>Regular TCP]
        QP --> DN_QUIC[DN Server<br/>Regular QUIC]
        ULL --> DN_ALL[DN Server]
    end
```

### 4.1 ATSSS-LL（低层分流）

**定义**：TS 24.193，工作在IP层之下、L2之上。对应用层完全透明，不修改数据包内容。

**核心能力**：
- 逐包级别的分割决策
- 支持所有Steering Mode（Active-Standby、Smallest Delay、Load-Balancing、Priority-based）
- 通过PMF进行RTT和丢包率测量
- 无需DN服务器做任何改动

**限制**：逐包分割可能导致**包重排序**问题。接收端需要重排序缓冲区，否则上层性能会劣化。

### 4.2 MPTCP Proxy

**定义**：基于RFC 8684，UPF内嵌MPTCP代理功能。

**工作流程**：
1. UE发起TCP连接时，MPTCP Client将连接升级为Multipath TCP
2. UE在3GPP接入上建立第一条MPTCP subflow（MP_CAPABLE握手）
3. UE在非3GPP接入上通过MP_JOIN添加第二条subflow
4. UPF MPTCP Proxy终止MPTCP连接，向DN发起普通TCP连接
5. 数据在两条subflow间根据MPTCP拥塞控制算法自动分配

**拥塞控制算法选择（运营商策略）**：
| 算法 | RFC | 特点 |
|------|-----|------|
| LIA (Linked Increases Algorithm) | RFC 6356 | 基础算法，兼顾公平性和吞吐量 |
| OLIA (Optimized LIA) | RFC 6356补充 | 更优的吞吐量均衡 |
| BALIA (Balanced LIA) | 学术论文 | LIA和OLIA的平衡 |
| wVegas | 学术论文 | 基于延迟的拥塞控制，适合RTT差异大的场景 |

### 4.3 MP-QUIC（Rel-17新增）

**定义**：TS 24.193 V17.x，基于IETF draft-ietf-quic-multipath，在QUIC传输层实现多路径。

**相比MPTCP的优势**：
- **无TCP头部的队头阻塞**：QUIC流之间独立，一条路径丢包不影响其他流
- **用户态实现**：不依赖操作系统内核支持MPTCP
- **原生加密**：QUIC内置TLS 1.3，每条路径独立密钥
- **更快的路径切换**：QUIC Connection ID机制使得路径切换无需重新握手

## 五、SMF的N4规则配置——ATSSS策略的"神经中枢"

SMF是ATSSS策略执行的枢纽。它从PCF获取PCC Rules（TS 29.512），将其转换为两组ATSSS规则：

- **UE侧ATSSS Rules**：通过NAS容器下发，控制上行流量分流
- **UPF侧ATSSS Rules**：通过N4接口下发，控制下行流量分流

### 5.1 N4 ATSSS相关规则结构

```mermaid
graph LR
    subgraph "PCF PCC Rules"
        P1[PCC Rule 1<br/>SDF: App=Video<br/>Steering: Load-Balancing<br/>Percentage: 70/30]
        P2[PCC Rule 2<br/>SDF: App=VoIP<br/>Steering: Smallest-Delay<br/>Threshold: RTT<50ms]
        P3[PCC Rule 3<br/>SDF: App=FTP<br/>Steering: MPTCP]
    end

    subgraph "SMF规则转换"
        P1 --> S1[ATSSS Rule for UE<br/>UL: 按概率70%走3GPP<br/>30%走Non-3GPP]
        P1 --> S1U[ATSSS Rule for UPF<br/>DL: 同理]
        P2 --> S2[ATSSS Rule for UE<br/>UL: PMF测量→选RTT小的]
        P2 --> S2U[ATSSS Rule for UPF<br/>DL: 同理]
        P3 --> S3[MPTCP Config for UE<br/>Proxy Address + Port]
        P3 --> S3U[N4 MPTCP Proxy Config<br/>Enable MPTCP termination]
    end

    subgraph "N4接口规则集"
        S1U --> N4_1[Create PDR<br/>Source: 3GPP/Non-3GPP<br/>FAR: Apply ATSSS Rule]
        S2U --> N4_2[Create PDR<br/>+ PMF Measurement Req]
        S3U --> N4_3[Create PDR<br/>+ MPTCP Proxy Enable]
    end
```

### 5.2 N4会话中的ATSSS参数（TS 29.564 Section 7.2.5）

| IE | 类型 | 说明 |
|----|------|------|
| ATSSS Control Information | Group | 包含所有ATSSS相关配置 |
| Steering Functionality | Enum | ATSSS-LL(0) / MPTCP(1) / MP-QUIC(2) |
| Steering Mode | Enum | Active-Standby(0) / Smallest-Delay(1) / Load-Balancing(2) / Priority-based(3) |
| Split Percentage | Uint8 | 0-100%，仅Load-Balancing模式 |
| Access Priority | Uint8 | 接入优先级，仅Priority-based模式 |
| PMF Address | FQDN/IP | UPF PMF端点地址 |
| PMF Port | Uint16 | PMF端口号 |
| MPTCP Proxy Address | FQDN/IP | UPF MPTCP代理地址 |
| MPTCP Proxy Port | Uint16 | MPTCP代理端口号 |
| Measurement Period | Uint16 | PMF探测间隔（毫秒） |
| RTT Threshold | Uint32 | RTT阈值（微秒），用于Smallest-Delay/Priority-based |
| Packet Loss Threshold | Uint16 | 丢包率阈值（千分比） |

## 六、性能测量框架（PMF）详解

PMF是ATSSS的核心感知组件，定义在TS 24.193 Section 7。它的职责是为Steering Mode的决策提供实时性能数据。

### 6.1 PMF测量过程

```mermaid
sequenceDiagram
    participant UE
    participant UPF_3G as UPF(3GPP侧)
    participant UPF_N3 as UPF(Non-3GPP侧)

    loop 每个测量周期 T_ms
        UE->>UPF_3G: PMF Probe Request<br/>Seq=N, T1=timestamp
        UPF_3G-->>UE: PMF Probe Response<br/>Seq=N, T2=recv, T3=send

        UE->>UPF_N3: PMF Probe Request<br/>Seq=M, T1=timestamp
        UPF_N3-->>UE: PMF Probe Response<br/>Seq=M, T2=recv, T3=send
    end

    Note over UE: 计算 RTT_3GPP = (T4-T1) - (T3-T2)<br/>计算 RTT_Non3GPP = (T4'-T1') - (T3'-T2')

    alt Smallest Delay模式
        Note over UE: 选择 RTT 值更小的接入发送新流量
    else Priority-based模式
        Note over UE: 如果高优先级接入RTT > 阈值<br/>则溢出到低优先级接入
    end
```

### 6.2 测量报告与策略更新

UE的PMF测量结果有两种上报方式：

1. **事件触发上报**：当RTT超过阈值或丢包率超过阈值时，通过UL NAS Transport中的ATSSS Performance Measurement Report IE上报（TS 24.501 Section 9.11.4.28）
2. **周期性上报**：SMF在下发ATSSS规则时配置上报周期

SMF收到测量报告后的处理流程（TS 23.502 Section 4.22.6）：

| 事件 | SMF动作 |
|------|---------|
| 3GPP接入RTT持续增大 | 可能修改ATSSS规则，将更多流量导向Non-3GPP |
| Non-3GPP接入丢包率突增 | 通知PCF请求策略更新，触发PCC Rule变更 |
| 一条接入完全不可达 | 将ATSSS模式临时切换为单接入，更新N4规则 |
| 测量恢复到正常范围 | 恢复原始ATSSS规则 |

## 七、MA-PDU会话状态转换

```mermaid
stateDiagram-v2
    [*] --> Idle: UE未建立PDU Session

    Idle --> SingleAccess: PDU Session<br/>Establishment Request<br/>(普通PDU Session)

    Idle --> MA_Pending: MA-PDU Request<br/>ATSSS Capability<br/>(双注册场景)

    MA_Pending --> MA_Active: SMF接受<br/>双接入隧道建立成功

    MA_Pending --> SingleAccess: SMF拒绝MA-PDU<br/>或非3GPP不可用

    SingleAccess --> MA_Active: PDU Session<br/>Modification<br/>添加非3GPP接入

    MA_Active --> MA_Active: Steering Mode变更<br/>ATSSS规则更新<br/>PMF阈值调整

    MA_Active --> MA_Degraded: 一条接入<br/>链路中断

    MA_Degraded --> MA_Active: 中断接入<br/>恢复

    MA_Degraded --> SingleAccess: 中断接入<br/>长期不可达<br/>SMF移除该路径

    MA_Active --> MA_Handover: N2切换<br/>3GPP侧gNB变更

    MA_Handover --> MA_Active: 切换完成<br/>N4更新

    MA_Active --> Idle: PDU Session Release<br/>双接入路径均释放

    MA_Degraded --> Idle: PDU Session Release

    SingleAccess --> Idle: PDU Session Release
```

## 八、抓包识别与故障排查

### 8.1 抓包识别关键点

**NAS层识别（Wireshark过滤器）**：

```bash
# 识别MA-PDU请求
nas-5gs.nas_msg_emm.ma_pdu_session_request == 1

# 识别ATSSS Capability
nas-5gs.nas_msg_emm.atsss_capability

# 识别ATSSS Rules（在PDU Session Establishment Accept中）
nas-5gs.nas_msg_sm.atsss_steering_mode
```

**N4接口识别**：

```bash
# ATSSS Control Information IE
pfcp.ie_type == 107  # ATSSS Control Information

# MPTCP Proxy Configuration
pfcp.ie_type == 107 && pfcp.mptcp_proxy_information
```

**PMF探测包识别**：

```bash
# PMF使用GTP-U通道内的特殊包类型
# 目标端口：SMF配置的PMF端口（默认端口待厂商实现）
# 包内容：包含PMF Type + Seq Num + Timestamp
```

### 8.2 常见故障点与排错思路

| 故障现象 | 可能原因 | 排错方法 |
|---------|---------|---------|
| MA-PDU请求被拒绝 | UE订阅数据中ATSSS Not Allowed | 查UDM中ATSSS-Allowed标识（TS 29.503） |
| 仅3GPP路径建立成功 | N3IWF不支持MA-PDU；N4规则下发失败 | 抓N4接口确认Non-3GPP PDR/FAR是否创建 |
| 流量未按策略分流 | UE未正确解析ATSSS Rules；UPF N4规则未生效 | 对比NAS下发和N4下发规则是否一致 |
| MPTCP subflow建立失败 | UPF不支持MPTCP Proxy；DN侧干扰 | 抓3GPP/Non-3GPP的TCP SYN，检查MP_CAPABLE选项 |
| Smallest Delay模式误判 | PMF探测包被丢失或延迟；测量间隔过长 | 检查PMF包是否正常收发，调整测量间隔 |
| 包重排序严重 | ATSSS-LL逐包分割 + 两条路径RTT差异大 | 改用per-flow分割或增大重排序缓冲区 |
## 九、Rel-18/19增强方向

### 9.1 Rel-18 MASSS（Multi-Access Steering, Switching and Splitting）

TS 23.288中定义的增强方案，将ATSSS概念扩展到：

- **多接入扩展**：不仅限于3GPP + Non-3GPP，可支持卫星接入、Wired接入等
- **QUIC-IP（Rel-19）**：基于MP-QUIC但工作在IP层，支持所有类型的IP流量（不仅限于QUIC应用流量）
- **Per-Application QoS**：不同应用使用不同的Steering策略，SMF基于App ID精细化控制

### 9.2 ATSSS与NWDAF的联动

Rel-18引入了NWDAF为ATSSS提供网络分析能力的机制：
- NWDAF分析两条接入的历史性能数据
- 预测接入质量变化趋势
- 通知PCF提前调整Steering策略（从Smallest Delay预切换到Load-Balancing）

## 常见问题

**Q1: MA-PDU Session和普通PDU Session的本质区别是什么？**

A: 普通PDU Session只有一组N3隧道（对应一个接入），而MA-PDU Session有**两组N3隧道**（分别对应3GPP和非3GPP接入），但共享同一个IP地址。在SMF/UPF视角下，MA-PDU Session的N4会话包含两套PDR/FAR规则，分别绑定到两个接入的F-TEID。

**Q2: ATSSS-LL的逐包分割如何解决包重排序问题？**

A: ATSSS-LL在UE侧和UPF侧各维护一个**重排序缓冲区**（Reordering Buffer），基于IP包的序列号（或时间戳）对乱序到达的包进行重新排序。但这对内存和延迟有开销——实际部署中，大部分运营商倾向于使用per-flow分割（同一流的所有包走同一路径）而非per-packet分割。

**Q3: MPTCP Proxy对DN服务器透明吗？**

A: 完全透明。DN服务器看到的是一条普通TCP连接，它不知道UE侧使用了多路径。MPTCP Proxy在UPF内将多条MPTCP subflow合并为一条TCP连接，对应用层完全屏蔽了多路径细节。这也是MPTCP方案的核心优势——不需要DN侧做任何改动。

**Q4: 如果UE只注册了3GPP接入，能否使用ATSSS？**

A: 不能。ATSSS的前提是UE在3GPP和非3GPP接入上**同时注册**到同一个PLMN的5GC（TS 23.501 Section 5.32.1）。如果只有单接入注册，SMF会建立普通PDU Session而非MA-PDU Session。但UE后续注册到非3GPP接入后，可以通过PDU Session Modification将现有PDU Session升级为MA-PDU Session。

**Q5: ATSSS和传统的Wi-Fi Calling/VoWiFi是什么关系？**

A: 它们是不同层面的机制。VoWiFi基于IMS over Wi-Fi，在应用层实现语音通过Wi-Fi传输，但它和5G数据是**完全独立**的两条路径。ATSSS是在**PDU Session层面**实现多路径融合——同一个PDU Session的流量可以在两条接入间分配。VoWiFi可以和ATSSS共存：语音走IMS over Wi-Fi，数据通过ATSSS在5G和Wi-Fi间分流。

## 参考来源

1. [3GPP TS 23.502 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.22 ATSSS Procedures
2. [3GPP TS 23.501 V18.x](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144) — Section 5.32 Support for ATSSS
3. [3GPP TS 24.193 V18.8.0](https://www.etsi.org/deliver/etsi_ts/124100_124199/124193/18.08.00_60/ts_124193v180800p.pdf) — ATSSS Lower Layer Functionality
4. [RomARS: ATSSS in 5G Networks](https://romars.tech/en/pubblications/atsss/) — 技术架构分析与流程图
5. [Rohde & Schwarz: 5G Interworking and ATSSS White Paper](https://www.rohde-schwarz.com/us/solutions/wireless-communications-testing/landingpages/white-paper-5g-interworking-and-atsss_258297.html) — 多路径传输方法深度分析
6. [Enhanced ATSSS (arXiv:2302.05439)](https://arxiv.org/abs/2302.05439) — 增强型接入流量调度学术分析

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