ATSSS多接入PDU会话与业务流分发机制全链拆解

聚焦 3GPP TS 23.501 §5.32、TS 23.502 §4.12.2、TS 23.503 §6.1.3 与 TS 24.193 §6.1.3 的 Multi-Access PDU Session 信令与 ATSSS 规则分发机制。

一、为什么需要 ATSSS：从"接入聚合"到"逐流分发"

5G 体系架构里,一个 UE 同时挂着 3GPP 接入(NR)和非 3GPP 接入(N3IWF/TNGF 之后的 Wi-Fi)是常态。早期方案(如"ANDSF + IFOM")只能做粗粒度的策略下发,真正决定哪一条业务流走哪个接入、何时切换、能否同时双发,一直缺乏统一框架。

ATSSS(Access Traffic Steering, Switching and Splitting,接入业务流的引导/切换/分流)在 Rel-16 引入,核心目标是:让 5GC 把"一个 PDU 会话"建在"两条接入腿"上,并由网络侧(SMF+PCF)统一下发规则,UE 和 UPF 各自按规则做逐流(per-flow)、甚至逐包(per-packet)的上下行分发决策。它不是简单的"Wi-Fi 卸载",而是把双接入当成一个逻辑会话的资源池来调度。

ATSSS 的三个动词各有含义:

• Steering(引导):为一个业务流选择一条接入腿传输;
• Switching(切换):把正在一条接入腿上传输的业务流,整体搬到另一条接入腿;
• Splitting(分流):把同一个业务流的数据包,同时在两条接入腿上并发或按比例发送。

理解这三个动作的差别,是理解后文 Steering Mode 设计的关键。

二、MA PDU 会话的架构本质

ATSSS 的载体是 Multi-Access PDU(MA PDU)Session。它的关键特征用一句话概括:一个 PDU Session ID、一个公共 SMF、一个公共 UPF(PSA)、一个公共 IP 地址,但下挂两条 N3 用户面隧道,分别通向 3GPP 接入和非 3GPP 接入。

flowchart TB
    UE["UE\n（ATSSS-LL + MPTCP Client + PMF）"]
    NR[("gNB / NG-RAN")]
    N3IWF[("N3IWF / TNGF\n（Wi-Fi 接入）")]
    AMF["AMF\n（两条 N1/N2）"]
    SMF["SMF（公共）\n下发 ATSSS Rules"]
    UPF["UPF-PSA（公共）\nMPTCP Proxy + ATSSS-LL + PMF"]
    PCF["PCF\nPCC + ATSSS Policy"]
    UDM["UDM\nATSSS 订阅数据"]
    DN["DN / Internet\n（单个 N6）"]

    UE -- N3(3GPP leg) --> NR --> AMF
    UE -- NWu(非3GPP leg) --> N3IWF --> AMF
    AMF <-->|N11/Nsmf| SMF
    SMF <-->|Npcf| PCF
    SMF <-->|Nudm| UDM
    SMF -- N4 --> UPF
    UPF -- N6 --> DN

这里有几个容易踩坑的设计点:

1. 两条腿共享一个 PSA:分流是在 UPF 内部完成的,N6 只有一条。这意味着无论数据从 NR 还是 Wi-Fi 进来,对 DN 里的应用服务器来说,源 IP 始终是 MA PDU 会话的那一个公共 IP——这是 Splitting(双发)能成立的物理基础。如果 PSA 不统一,就只能做 Steering/Switching,做不了 Splitting。
2. 公共 IP 的代价:ATSSS 要求 UE 在两条接入腿上使用相同的 IP 地址(IP 类型)或相同的 MAC 地址(Ethernet 类型)。对于 IP 类型,Rel-16 规定 UE 会被分配一个 MA PDU 会话级 IP,以及两个链路本地 IP(用于 MPTCP 的子流建立)。
3. 接入独立性:MA PDU 会话与具体接入解耦,任意一条腿断开,会话仍可通过另一条腿存活——这是"接入冗余"的来源,也是 ATSSS 在后续 Release 被用来支撑业务连续性和高可靠的原因。

三、两种 Steering Functionality:MPTCP vs ATSSS-LL

ATSSS 定义了两种执行分发的"功能",二者并存,由 ATSSS 规则决定对哪条业务流用哪一种。这是理解整套机制最绕的地方,必须分清"Mode(模式,做什么)"和"Functionality(功能,用什么手段做)"。

设计意图:TCP 流天然适合用 MPTCP 做多路径,标准、成熟、不需要 5GC 介入每包决策;而 UDP(尤其是 QUIC、实时媒体)无法套 MPTCP,只能靠 ATSSS-LL 在低层逐包转发。两者互补,ATSSS 规则里会显式指明本条流走哪个功能。

值得注意 Rel-17 的重要增强(Work Item ATSSS_Ph2/Ph3):ATSSS-LL 从只能做"主备 + 最小时延"扩展到支持 Load-Balancing 与 Splitting,这意味着非 TCP 业务(如视频、QUIC)也能按比例双发,大幅提升了 ATSSS 的实用价值。

四、四种 Steering Mode

Steering Mode 描述"按什么策略分发",定义在 TS 23.501 §5.32.2:

四种 Mode 与两种 Functionality 是正交组合:例如"Load-Balancing + ATSSS-LL"=逐包按比例双发;"Load-Balancing + MPTCP"=多 TCP 子流按权重;"Active-Standby + ATSSS-LL"=主用腿故障时逐流切换到备用腿。

五、ATSSS 规则:网络侧的"分流指令书"

ATSSS 规则由 SMF 生成(在 PCF 下发的 PCC 规则基础上),分别通过 N1(5GSM 消息,见 TS 24.193 §6.1.3)发给 UE、通过 N4(见 TS 29.244)发给 UPF。两侧规则保持一致,才能保证上下行分发决策对齐。

flowchart TD
    subgraph RULE["ATSSS Rule"]
        R1["Rule Precedence\n(规则优先级)"]
        R2["Traffic Description\n(SDF filter / App ID)"]
        R3{"Steering Mode\nActive-Standby / Smallest Delay\nLoad-Balancing / Priority-based"}
        R4["Steering Functionality\nMPTCP / ATSSS-LL"]
        R5["Steering Parameters\n(百分比/优先级/主备)"]
        R6["DNS Query Handling\n(可选)"]
    end
    RULE -->|N1 5GSM| UE["UE 执行上行分发"]
    RULE -->|N4 PDR/FAR| UPF["UPF 执行下行分发"]

特别地,Load-Balancing 的百分比不是静态的:SMF/PCF 可下发"autonomous load-balancing"指示,允许 UE 和 UPF 根据实测接入质量在约束区间内自主调整比例,这依赖下文的 PMF。

六、MA PDU 会话建立的完整信令流(TS 23.502 §4.12.2)

MA PDU 会话通过两次"UE 发起的 PDU 会话建立"分别在两条接入腿上完成。第一次是 Request type = "initial request" + MA PDU session request = "MA PDU request",建立会话本体;第二次在另一条腿上是 Request type = "existing PDU session" + MA PDU request,把第二条腿挂到同一会话上。

sequenceDiagram
    participant UE
    participant AMF as AMF
    participant SMF as SMF
    participant UDM as UDM
    participant PCF as PCF
    participant UPF as UPF-PSA
    participant RAN as gNB / N3IWF

    Note over UE,RAN: ① 第一条腿：3GPP，initial request + MA PDU request
    UE->>AMF: NAS PDU Session Establishment Request<br/>（PDU Session ID, DNN, MA PDU request="MA PDU request",<br/>Request type="initial request", UE ATSSS Cap）
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext<br/>（含 MA PDU request, access type=3GPP）
    SMF->>UDM: Nudm_SDM_Get（ATSSS 订阅 / 会话订阅）
    SMF->>UDM: Nudm_SDM_Subscribe（订阅变更通知）
    SMF->>PCF: Npcf_SMPolicyControl_Create
    PCF-->>SMF: PCC Rules + ATSSS Policy（Mode/Func）
    SMF->>UPF: N4 Session Establishment Request<br/>（ATSSS Rules + 3GPP leg PDR/FAR）
    UPF-->>SMF: N4 Response（CN F-TEID）
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>N1: PDU Estab Accept + ATSSS Rules<br/>N2: PDU Session Resource Setup
    AMF->>RAN: N2 PDU Session Resource Setup Request（+ NAS PDU）
    RAN->>UE: RRC Reconfiguration（DRB 建立）
    UE-->>RAN: RRC Reconfiguration Complete
    RAN-->>AMF: N2 PDU Session Resource Setup Response（AN F-TEID）
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext（AN tunnel）
    SMF->>UPF: N4 Modification（绑定 AN tunnel@3GPP）

    Note over UE,RAN: ② 第二条腿：非3GPP，existing PDU session
    UE->>AMF: NAS PDU Session Establishment Request<br/>（同 PDU Session ID, MA PDU request,<br/>Request type="existing PDU session"）
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext（add 非3GPP access）
    SMF->>UPF: N4 Modification（新增 non-3GPP leg PDR/FAR）
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer（N2@N3IWF）
    AMF->>RAN: N2 via N3IWF（IPsec Child SA 建立）
    RAN-->>AMF: N2 Response（AN tunnel@non-3GPP）
    AMF->>SMF: UpdateSMContext（AN tunnel@non-3GPP）
    SMF->>UPF: N4 Modification（绑定 AN tunnel@non-3GPP）
    Note over UE,UPF: 双腿就绪，UE/UPF 按 ATSSS Rules 分发上下行

关键 IE 逐条解析

1. MA PDU session request(NAS):这是 UE 把"普通 PDU 会话"升级为"MA PDU 会话"的开关。SMF 一旦看到它且订阅允许,就会按 MA PDU 模式处理——选一个能同时服务两条腿的 PSA,分配公共 IP。
2. Request type:决定这是"建会话本体"(initial)还是"挂第二条腿"(existing PDU session)。第二次复用同一 PDU Session ID,SMF 据此识别为同一会话的扩展,而非新建。
3. UE ATSSS Capability(NAS):UE 上报自己支持哪些 Steering Functionality(MPTCP / ATSSS-LL)和哪些 Mode。PCF 据此生成与 UE 能力匹配的 ATSSS Policy。
4. ATSSS 订阅(UDM):UDM 里必须有 ATSSS 标志位,否则 SMF 直接拒绝建立 MA PDU 会话。这是运营商商业策略的闸门。
5. N1 的 ATSSS Rules:在 PDU Session Establishment Accept 中下发给 UE;若后续策略变化,SMF 通过 PDU Session Modification Command 更新。
6. N4 的 PDR/FAR:UPF 侧,每条 ATSSS 规则会被翻译成"包检测规则 + 转发动作规则",并关联两条腿的隧道。下行分流就是在 UPF 内部按这些规则把包送进对应隧道。

七、PMF 性能测量:让 Smallest Delay / Load-Balancing 落地

Smallest Delay 和 Load-Balancing 都需要实时知道每条腿的质量,这是 PMF(Performance Measurement Function) 的职责(TS 23.501 §5.32.4)。PMF 在 UE 和 UPF 两侧都有,通过持续探测得到每条接入腿的 RTT。

flowchart LR
    subgraph M["PMF 测量循环"]
        UPF2["UPF PMF"] --|下行探测包| A3["3GPP leg"]
        UPF2 --|下行探测包| AN["non-3GPP leg"]
        A3 --|上行回应| UE2["UE PMF\n→ RTT_3GPP"]
        AN --|上行回应| UE2
        UE2 --|按 Smallest Delay / LB 比例| DEC{"上行分发决策"}
        DEC --> A3
        DEC --> AN
    end

PMF 的设计要点:

• 探测使用轻量数据包(类似 ICMP Echo 的"dummy"包),开销低;
• 分 UL PMF 和 DL PMF 两个方向独立测量,因为上下行时延可能不对称;
• 测量结果只在本地(UE / UPF)使用,不上报给网络,以减少信令——这是一个重要的可扩展性设计:决策分布式执行,规则集中下发。

八、设计意图的深度推演

把上面这些放在一起看,ATSSS 的设计哲学有三层值得玩味:

1. "会话"与"接入"解耦:传统上 PDU 会话绑死在一条接入上,移动性就是接入的移动性。MA PDU 会话把"会话"提升到接入之上,接入只是会话的"传输路径"。这为 Rel-17/18 的多接入冗余、URLLC 增强、卫星+地面融合铺平了道路。
2. 规则集中、执行分布:网络(SMF/PCF)只负责"定策略"(ATSSS Rules),UE 和 UPF 各自"执行策略"。PMF 测量本地化、决策本地化,信令面不被海量逐包决策淹没。这是把控制面/用户面职责切干净的经典手法。
3. Functionality 与 Mode 正交:把"做什么(Mode)"和"用什么做(Functionality)"拆开,使得同一套规则框架能覆盖 TCP 到 QUIC、主备到负载均衡的所有组合,标准扩展时只需在两个轴上各加一项,不破坏既有结构。

九、抓包识别与故障排查

抓包识别要点

• N1(NAS)层面:在 PDU Session Establishment Request 的"Request type"字段和"MA PDU session request"标志位识别。Wireshark 的 5GSM dissector 会显示 Request type: initial request 与 MA PDU session request: MA PDU request (1)。ATSSS Rules 作为 5GSM 信息元素出现在 Accept / Modification Command 中。
• N4(PFCP)层面:MA PDU 会话会有两组 N3 F-TEID(分别对应两条腿),PDR 中带有 ATSSS 相关的 Steering 语义。
• 用户面:同一条 TCP 流的包若同时出现在两条 N3 隧道(Splitting),或某条腿整体消失(Switching),即可判定 ATSSS 在生效。

常见故障点

Q1: MA PDU 会话和两个独立的 PDU 会话(3GPP 一个、Wi-Fi 一个)有什么本质区别? A: 根本区别在于"公共 PSA + 公共 IP"。两个独立会话各有各的 PSA 和 IP,应用层看到两个源 IP,无法做同一流的 Splitting/双发,切换时 TCP 连接会断。MA PDU 会话保证对应用层是一个连续的 IP,从而能逐流/逐包分发并保证连续性。

Q2: 为什么 Rel-16 的 ATSSS-LL 不能做 Load-Balancing/Splitting,只能做主备和最小时延? A: Rel-16 的 ATSSS-LL 定位为低层逐流引导,只决定"这条流走哪条腿",不拆包;真正的按比例双发当时只由 MPTCP 承担(仅限 TCP)。Rel-17 才把逐包 Splitting 能力补进 ATSSS-LL,让 UDP/QUIC 也能双发。

Q3: ATSSS 和 EPS 时代的 IFOM/Mapcon 是什么关系? A: IFOM/Mapcon 是基于 DSMIPv6 的早期多接入方案,粒度粗、依赖 UE 自主决策、缺乏网络统一控制。ATSSS 是 5GC 原生方案,由 SMF/PCF 集中下发规则、UE/UPF 分布执行,粒度到流/包,可视为对前者的全面替代与增强。

Q4: MA PDU 会话必须同时建立在两条腿上吗? A: 不必。可以先用 initial request 建成单腿的 MA PDU 会话(此时等价于普通会话但带 MA 属性),待 UE 注册到另一接入后再用 existing PDU session 挂上第二条腿。会话本身始终只有一个。

Q5: 下行分流在 UPF 怎么决定走哪条腿? A: UPF 按 N4 下发的 PDR/FAR,匹配到对应 ATSSS Rule 后,依 Mode 与 PMF 测得的下行质量/比例,把包送入对应接入腿的 N3 隧道。与 UE 的上行决策规则一致,从而保证双向分流协调。

参考来源

1. 3GPP TS 23.501 System architecture — §5.32 Support for ATSSS — MA PDU 会话架构、Steering Mode/Functionality、PMF 定义
2. 3GPP TS 23.502 Procedures — §4.12.2 MA PDU Session establishment — 双腿建立信令流程
3. 3GPP TS 24.193 ATSSS UE procedures — §6.1.3 ATSSS Rules — ATSSS 规则 IE 编码与下发
4. iTeCSpec — TS 24.193 §5.2 Multi-access PDU connectivity service — MA PDU 会话建立与修改流程解读
5. RomARS — ATSSS in 5G networks — MPTCP/ATSSS-LL 与各 Steering Mode 的工程分析
6. IETF interim-2020-quic — Multipath in 3GPP ATSSS — MA PDU 会话 IP 地址分配与多路径语义

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