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"的粗粒度选择,变成了逐流、逐包级别的精细调度。
关键架构实体如下:
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]
根据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 |
以下是最复杂的"初始建立"场景的完整信令时序图,基于TS 23.502 Section 4.22.2.1:
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双路径均就绪
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上限、丢包率上限等) |
ATSSS定义了五种steering模式,每种模式的决策逻辑和适用场景截然不同:
机制(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备份)。
机制(TS 23.501 Section 5.32.2.2):UE和UPF各自独立测量两条接入的RTT,将每个新流量导向RTT最小的接入。
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 |
机制:按照SMF下发的百分比权重,将流量在两条接入间分配。权重由PCF策略决定,可基于时段、签约、网络负载动态调整。
关键参数:
| 参数 | 取值范围 | 说明 |
|---|---|---|
| Access Preference | 0-100% | 3GPP接入的流量百分比 |
| Bucket Size | 整数 | 令牌桶大小,控制分割粒度 |
| Split Percentage | 0-100% | 精确的分流比例 |
ATSSS-LL实现Load-Balancing的分割粒度: - Per-flow级别:每个新流随机(按概率)分配到某条接入 - Per-packet级别:令牌桶算法,逐包交替发送(仅ATSSS-LL支持,MPTCP不适用)
机制:定义接入优先级列表。流量优先走最高优先级接入;当高优先级接入的性能低于阈值时,溢出到低优先级接入。
与Active-Standby的关键区别:Active-Standby只在链路完全中断时才切换;Priority-based在性能劣化(如RTT超过阈值)时就开始溢出。
机制(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新增 |
| 实现复杂度 | 低 | 中 | 中 | 中 | 高 |
这三种steering functionality是ATSSS的"执行引擎",决定了流量如何在物理层面被分割。
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
定义:TS 24.193,工作在IP层之下、L2之上。对应用层完全透明,不修改数据包内容。
核心能力: - 逐包级别的分割决策 - 支持所有Steering Mode(Active-Standby、Smallest Delay、Load-Balancing、Priority-based) - 通过PMF进行RTT和丢包率测量 - 无需DN服务器做任何改动
限制:逐包分割可能导致包重排序问题。接收端需要重排序缓冲区,否则上层性能会劣化。
定义:基于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差异大的场景 |
定义:TS 24.193 V17.x,基于IETF draft-ietf-quic-multipath,在QUIC传输层实现多路径。
相比MPTCP的优势: - 无TCP头部的队头阻塞:QUIC流之间独立,一条路径丢包不影响其他流 - 用户态实现:不依赖操作系统内核支持MPTCP - 原生加密:QUIC内置TLS 1.3,每条路径独立密钥 - 更快的路径切换:QUIC Connection ID机制使得路径切换无需重新握手
SMF是ATSSS策略执行的枢纽。它从PCF获取PCC Rules(TS 29.512),将其转换为两组ATSSS规则:
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
| 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是ATSSS的核心感知组件,定义在TS 24.193 Section 7。它的职责是为Steering Mode的决策提供实时性能数据。
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
UE的PMF测量结果有两种上报方式:
SMF收到测量报告后的处理流程(TS 23.502 Section 4.22.6):
| 事件 | SMF动作 |
|---|---|
| 3GPP接入RTT持续增大 | 可能修改ATSSS规则,将更多流量导向Non-3GPP |
| Non-3GPP接入丢包率突增 | 通知PCF请求策略更新,触发PCC Rule变更 |
| 一条接入完全不可达 | 将ATSSS模式临时切换为单接入,更新N4规则 |
| 测量恢复到正常范围 | 恢复原始ATSSS规则 |
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
NAS层识别(Wireshark过滤器):
# 识别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接口识别:
# ATSSS Control Information IE
pfcp.ie_type == 107 # ATSSS Control Information
# MPTCP Proxy Configuration
pfcp.ie_type == 107 && pfcp.mptcp_proxy_information
PMF探测包识别:
# PMF使用GTP-U通道内的特殊包类型
# 目标端口:SMF配置的PMF端口(默认端口待厂商实现)
# 包内容:包含PMF Type + Seq Num + Timestamp
| 故障现象 | 可能原因 | 排错方法 |
|---|---|---|
| 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增强方向 |
TS 23.288中定义的增强方案,将ATSSS概念扩展到:
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间分流。
本文由「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 等场景全覆盖。
