3GPP TS 23.501 5.32 Support for ATSSS

はじめに

本記事は、「3GPP TS23.501(V17.6.0)を読んでいく Advent Calendar 2022」の「3GPP TS 23.501 5.32 Support for ATSSS」の解説記事になります。
https://qiita.com/advent-calendar/2022/3gpp_ts23501

ATSSS (Access Traffic Steering, Switching, Splitting)は5GSのオプション機能で、3GPPアクセス(NRなど)とnon-3GPPアクセス(Wi-Fiなど)のデュアルアクセスを可能とする機能で、Steering, Switching, Splittingの機能を提供します。

調査資料

TS 23.501に限らず3GPPのTSはTechnical Specificationであり、仕様に関係ない背景情報や参考情報はなるべく削ぎ落とされています。ATSSSなど新しい機能がどうゆうモチベーションで追加されたか読み取ることができません。なので、TS 23.501に加えて、以下のTRも参考にして記事を本記事を記載しています。
Rel-16 TR 23.793 Study on ATSSS support in the 5G System (5GS) architecture
Rel-17 TR 23.700-93 Study on ATSSS support in the 5G System (5GS) architecture; Phase 2
Rel-18 TR 23.700-53 Study on ATSSS support in the 5G system architecture; Phase 3

ATSSS概要

まず、時間のない人向けにATSSSの概要だけ先に書いておきます。
3GPPの5GS(5G System)では5G NRのような3GPPで定義された無線アクセス以外にも様々なアクセス技術を収容することができます。3GPP以外のアクセスはまとめてnon-3GPPアクセスといい、Wi-FiやEthernetなどがそれに該当します。non-3GPPアクセスにはさらにTrustedとUntrustedに分類されます。
現在のスマホのようなUEでは、LTE/NRなどの3GPPアクセスに加えてWi-Fi用のアンテナもモデムも内蔵されていますが、一旦Wi-Fiに接続するとWi-Fiの無線リンクの品質が著しく低下したり切断しない限りWi-Fiを固定的に使い続けるなど、十分にそのポテンシャルを活用できてるとは言いがたい状況です。
そこで、ATSSS（Access Traffic Steering, Switching, Splitting）ではNRとWi-Fiのように複数のアクセスでSteering, Switching, Splittingを行うための機能を提供します。それぞれ以下の機能を指しています。

Steering: アクセスA OR アクセスB（最適なネットワークの選択）
Switching: アクセスA FROM/TO アクセスB（シームレスな切替）
Splitting: アクセスA AND アクセスB（トラフィックの分割、アクセスの同時利用）

名前が似ているので覚えにくいです。個人的にはSwitchingはわかるのですが、SteeringとSplittingがわかりにくかったです。Splittingは分割なのでトラフィックを分割するイメージを持つと覚えれるかと思います。
ここでアクセスAとアクセスBのように抽象化して書いていますが、リリース16と17の仕様の範囲ではアクセスAは3GPPアクセス、アクセスBはnon-3GPPアクセス(例えばWi-FiやEthernet、さらには衛星通信など)と解釈してよいです。
リリース19のSA1では2つの3GPPアクセスのマルチアクセスもFS_DualSteerというSIで検討されています。Stage1のStudyフェーズなので仕様化されるのはまだ先になりますが、NPN(Private 5G)とのマルチアクセスや、地上5Gと衛星5Gのマルチアクセスなどのユースケースが議論されており、夢が広がりますね！

さて、ここまで読んで勘がいい方やネットワークエンジニアの方であれば「これってMPTCPで既にできるんじゃない？なんで改めてATSSSなんて作る必要あるの？」と疑問を抱いているかもしれません。ATSSSではその実現手段としてMPTCP(Multi-Path TCP)を採用しています。3GPPでは要件を満たすことができるのであれば、3GPP以外で作られた仕様や標準を組み入れるというスタンスで、よくIETFの技術を取り入れています。3GPPというと独自プロトコルを作ってるイメージを持たれるかもしれませんが、「車輪の再発明はしない」という考え方はあります。
以下のアーキテクチャ図では、UE側にMPTCP functionality、NW側(UPF)にMPTCP proxy functionalityが配置されているのがわかります。

ATSSSではMA PDU(Multi Access PDU)セッションがUEとPSA UPF間で確立されます。MA PDUセッションでは3GPPアクセスとnon-3GPPアクセスの両方を同時に利用します。アーキテクチャ図からわかるように１つのMA PDUセッションは2つの独立したN3(またはN9)トンネルをRAN/ANとPSA UPF間で確立することになるのが特徴です。

スマートフォンでMPTCPの実装はいろいろあるようですが、NW側は5GSの機能としてではなくDNにあるサーバーがMPTCPサーバーとして動作していたのに対し、ATSSSでは、上の図のようにMA PDUセッションはPSA UPFで終端されるためDNのサーバーはMPTCPに対応する必要がないです。

TS 23.501では、steering, switching, splittingの機能群をまとめてSteering Functionalitiesと定義しています。（著者は最初このことを知らず混乱しました。Steering FunctionalitiesがあるならSwitching FunctionalitiesとSplitting Functionalitiesも当然あるだろうと思っていたらなかったです。）
Steering Fucntionalitiesには、上位レイヤと下位レイヤに分類されます。

• High-layer steering functionalities（トランスポートレイヤ（TCPなど）以上）
  • 現在のリリースでは上述したMPTCPのみがサポートされています。そのため、High-layer steering functionalities = MPTCP functionalitiyとなります。MPQUICのサポートはリリース17で検討されてましたがIETF側の成熟がまだということで採用は見送られています。
• Low-layer steering functionalities（ネットワークレイヤ（IP）以下）
  • TCP、UDP、Ethernetなどあらゆる種類のトラフィックのSSSを可能とする機能のようです。しかしながら、TS 23.501を見る限り具体的な方式が何一つ書いてなく私にはどうやって実現するのかわからなかったです。（ご存じの方いらっしゃいましたら教えてください）

下の図ではUEにおけるATSSSのプロトコルスタックを図示しています。

上述したように、1つのMA PDUセッションは2つの独立したN3(またはN9)トンネルをRAN/ANとPSA UPF間で確立することになります。MPTCPでは、5GCは、MA PDUセッション用に1つのIPアドレスを、リンク特有マルチパス(link-specific multipass)に合計2つのIPアドレスが割り当てられる仕組みとなっています。下の図ではIP@3がMA PDUセッション用のIPアドレスで、IP@1,IP@2がリンク特有マルチパスのIPアドレスに対応しています。
なお、MA PDUセッションのIPアドレスは、通常のPDUセッションと同じくSMFが割り当て、リンク特有マルチパスのIPアドレスは、UPFが割り当てるようになっています。

次に、ATSSSが動作する際には3GPPアクセスとnon-3GPPアクセスに対してアップリンクとダウンリンクのトラフィックをどのように振り分ければよいか（Steering Modeという）、ATSSSルールをUEに配布してあげる必要があります。これはMA PDUセッションの確立時にPCFで決定しSMFから配布されます。
Steering Modeには、以下の4つが規定されています。TS 23.793 6.4節にいい感じの図があったのでそれを元に解説します。

Active-Standby
見ての通りアクティブが利用できなくなったときにスタンバイに切り替わります。アクティブが再び利用可能になるとアクティブに切り替わります。

Smallest Delay
RTTが最も小さいとアクセスを利用します。RTTを計測するためにmeasurementを行います。TRでは"Best access"として検討されており、RTTはその指標の一つでしたが、結果的にRTTのみが残ったので"Smallest Delay"というモードの名前になったようです。

Load-Balancing
両方のアクセスを使います。ロードバランシングの割合を指定して使います。
Load-Balancingモードのときは、Steering Mode Indicatorとして、Autonomous load-balance indicatorかUE-assistance indicatorを指定することができます。

• Autonomous load-balance indicator: UEは2つのアクセスのmeasurementに基づきULのロードバランシングの割合を自動調整する。UPFもN4ルールで指示された場合はDLの割合を自動調整する。
• UE-assistance indicator: UEの内部状態（バッテリーレベルなど）に応じてULの割合を決定し、その決定をUPFに通知する（恐らくUPFではそれに基づいてDLを調整する）。

Priority-based
すべてのトラフィックを、優先度の高いアクセスを優先的に使い、アクセスが輻輳していると判断されたら、低優先アクセスの方も使います。輻輳をどのように判断するかは実装依存です。

なお、Steering modeはULとDLと異なるモードを設定することが可能なようです。

ATSSSの機能の概要は以上になります！私はネットワークエンジニアではないので実情がわかっていないのですが、世の中にはSD-WANソリューションとしてSDNルーターに4G/5GとWi-Fiのモデムをつないでロードバランシングするみたいなことは既にやられていますし、ATSSSのような機能は特段珍しいものではない気もします。ただ、そのようなSD-WANソリューションは独自実装で相互運用も難しいのかと思いますし、3GPPで仕様化されることにより、1つのチップでATSSS機能に対応し、(MPTCPなど)IETFの広く使われているプロトコルをベースとし、相互運用性もあって、プロキシーサーバーを設定する面倒なことはオペレータに任せることができるようになるなどメリットがありそうだなと感想をいだきました。

以下は詳解（といっても自分用のメモみたいなものですが）になりますのでもしご興味ありましたら御覧ください。

ATSSS詳解

定義

TS 23.501のDefinitionsにはATSSSのSSSであるSteering, Switching, Splittingの定義の記載がありました。そのまま以下に引用します。

Access Traffic Steering**: The procedure that selects an access network for a new data flow and transfers the traffic of this data flow over the selected access network. Access traffic steering is applicable between one 3GPP access and one non-3GPP access.
Access Traffic Switching: The procedure that moves all traffic of an ongoing data flow from one access network to another access network in a way that maintains the continuity of the data flow. Access traffic switching is applicable between one 3GPP access and one non-3GPP access.
Access Traffic Splitting: The procedure that splits the traffic of a data flow across multiple access networks. When traffic splitting is applied to a data flow, some traffic of the data flow is transferred via one access and some other traffic of the same data flow is transferred via another access. Access traffic splitting is applicable between one 3GPP access and one non-3GPP access.

MA PDUセッション確立手順

この節ではTS 23.502 4.22節を参考にATSSS手順の最も基本的な手順になるMA PDUセッションの確立手順を見ていきたいと思います。
まず、PDUセッション確立の前にUEは5GCに「登録（Registration）」を行いますが、このときAMFからMA PDU Session Support indicator を通知することでUEは5GC側のサポート状況がわかります。5GCがMA PDUセッションをサポートしていなければ、MA PDUセッション確立の要求をしてはいけないことになってます。
MA PDUセッション確立手順ですが基本的には通常のPDUセッションの確立手順をベースにしています。以下は通常のPDUセッションのシーケンスですが、ATSSSで差分となるところだけテキストで解説していきます。

PDUセッション確立手順（前半）

Step1: NASのRequest Typeを"MA PDU Request"として、ATSSS Capabilities (TS 23.501 5.32.2)を含める
Step2: MA PDUセッションをサポートできるSMFを選択する。
Step3: "MA PDU Request"の要求であることをSMFに通知する。どのアクセス上(3GPP AND/OR non-3GPP)で登録されてるかをSMFに通知する。要求されたS-NSSAIが両方のアクセスで許可されていなければAMFでセッション確立は拒否する。LADNを要求されても拒否する。
Step4: 加入者データのみてMA PDUセッションが許可されているか確認する。
Step7: ここのSMFとPCFとのインタラクションがATSSSルールが決定されます。

• Dynamic PCCがMA PDUセッションに使用される場合、SMFは、SM Policy Control Createメッセージで"MA PDU Request" indicationとATSSS CapabilitiesをPCFに送信する。SMFは、現在使用されているAccess Type（複数可）とRAT Type（複数可）もPCFに送信する。PCFは、オペレータポリシーおよび加入者データに基づいて、MA PDUセッションが許可されるか否かを決定する。
• PCFは、MA PDUセッション制御情報を含むPCCルールを提供する。SMFは、受信したPCCルールから、ULとDLそれぞれのルールを導出する。ULルールはUEに送られて、DLルールはN4でUPFに送られることになる。

Step10: SMFが導出したMA PDU セッションのN4 ルールがUPFに送信される。UPFによって2つのN3 UL CNトンネル情報が割り当てられる。ATSSS LLがサポートされている場合、MA PDU セッションのパフォーマンス測定を開始するように指示できる。また、MPTCPがサポートされている場合、MPTCP機能を起動するようUPFに指示できる。
Step10a:

• ATSSS-LL: UPF内のPMF(Performance Measurement Function)のためのアドレス情報を割り当てる。UPFがSMFからアクセス性能測定を行うQoSフローのリストを受け取った場合、UPFはアクセス毎QoSフロー毎に、異なるUDPポートまたは異なるMACアドレスを割り当てる。
• MPTCP: SMFからのメッセージがUPFにMPTCP機能を起動するよう指示した場合、UPFはUEのlink-specific multipath アドレス／プレフィックスを割り当てる。

Step10b:

• ATSSS LL: UPF内のPMFのアドレス情報をSMFに送信する。アクセス毎QoSフロー毎に、UDPポート又はMACアドレスを割り当てる場合
  • IP PDUセッションの場合: 関連するQFIを有するPMFのIPアドレス情報及びUDPポートをSMFに送信する。
  • Ethernet PDUセッションの場合: 関連するQFIを有するMACアドレスをSMFに送信する。
• MPTCP: UPFがSMFに対してlink-specific multipathアドレス／プレフィックスおよび MPTCPプロキシ情報を送信します。

Step11: Namf_Communication_N1N2MessageTransferメッセージに"MA PDU session Accepted"指示を含める。このメッセージに含まれるN2 SM情報を3GPPアクセスで送信すべきことをAMFに指示する。AMFは受信した"MA PDU session Accepted"指示に基づいて、このPDUセッションをMA PDUセッションとしてマークしておく。
Step13: UEはPDUセッション確立Acceptメッセージを受信し、要求されたMA PDUセッションが正常に確立されたことを認識する。このメッセージにはSMFによって導出されたATSSSルールを含む。

• ATSSS-LL: SMFは、UPF内のPMF のアドレス情報を含めることができる(MAY)。
• MPTCP: SMFは、link-specifik multipathアドレス／プレフィックスおよび MPTCPプロキシ情報を含める(SHALL)。

PDUセッション確立手順（後半）

Step18以降:もしStep2でSMFが両方のアクセス上(3GPP and non-3GPP)でUE が登録されていることを通知していた場合、SMFは、3GPPアクセスでのPDUセションが確立された後に、non-3GPPアクセス上でもユーザープレーンのリソースの確立を開始する。SMFは、N2 SM情報を含むNamf_Communication_N1N2MessageTransferをAMFに送信し、N2 SM情報がnon-3GPPアクセス上で送信されるべきことをAMFに指示します。Namf_Communication_N1N2MessageTransferは、Step 13でUEに送信されているため、UE用のN1 SMコンテナを含んでいない。この後、PSAとRAN／ANとの間の2つのN3トンネルが確立される。
UEが1つのアクセスのみで登録されている場合、上記の最後のステップは実行されない。この場合、MA PDUセッションは、1つのアクセスのみのユーザ・プレーン・リソースで確立される。
MA PDUセッションのアクセス上でユーザープレーンのリソースを追加することもできる。その場合には、もう一つのアクセスでMA PDUセッション確立リクエストを送ることになる。TS 23.502 4.22.7 節に規定されている。

ATSSSルール

ATSSSルールはSMFからUEに提供されます。

上の表のATSSSルールは複数提供されて、優先順位はRule Precedenceをみて決定される。トラフィックはTraffic Descriptorで特定される。5-tupleに加えてアプリIDなどでも特定できる（しかし、このアプリIDなどは標準化されておらず実装依存になると思われる）。特定されたトラフィックはAccess Selection Descriptorに基づいてステアリングされる。ここには概要で紹介したATSSS Functionalityの種類（LLかMPTCPか）、Steering Mode、Steering Mode Indicatorを記載する。
Threshold Valuesは概要に出てこなかったので簡単に紹介する。
Threshold ValuesはステアリングモードがPriority baseの場合か、固定分割パーセンテージのLoad Balancingの場合（Steering Mode Indicatorはなし）、Thresholdが提供してもよい。Thresholdには、RTTの値またはPLR(パケット損失率)の値のいずれか。Thresholdには両方のアクセスに適用される。

• Load Balancing: 1つのアクセスにおける少なくとも1つの測定パラメータ（RTT またはパケット損失率など）が提供された閾値を超えた場合、UEおよびUPFはこのアクセス上でのトラフィック送信を停止してもよいし、継続するときはこのアクセス上のトラフィックを固有の量だけもう片方のアクセスにオフロードする。両アクセスのすべての測定パラメータ（RTT およびパケット損失率など）が提供された閾値を超えない場合、UE および UPF は固定分割パーセンテージを適用する。
• Priority-based: UEとUPFは閾値を考慮して、アクセスが輻輳するタイミングを判断する。例えば、あるアクセスで測定されたパラメータ（RTT または Packet Loss Rateなど）が提供された閾値を超えた場合、UE および UPFはこのアクセスを混雑していると見なし、トラフィックを優先度の低いアクセスにも送ることができる。

測定

MA PDUセッションを確立する際に、NWはUEにMeasurement Assistance Informationを提供します。この情報は、UEが両方のアクセスでどの測定を行うか、また、測定レポートをNWに送信する必要があるかどうかを判断するのに利用されます。
Measurement Assistance Informationには、PMFのアドレス情報が必須で含まれます。なお、PMFをDDoS攻撃から守るために、PMFにはUEのIPアドレスからのみアクセスできるようにしてます。

• PDUセッションがIPタイプ：PMFのIPアドレスが含まれる。
• PDUセッションがEthernetタイプ：PMFのMACアドレスが含まれる

QoSフロー単位でaccess performance measurementが行う場合にはMeasurement Assistance InformationにはQoFフローのリストを必ず入れる必要がある。

UEおよびUPFは、access performance measurementにより、あるアクセスタイプでSDFが送信された場合に予想されるRTT and/or PLR(Packet Loss Rate) を推定する。UEおよびUPFは、これらの測定値およびUE内のATSSSルールとUPF内のMARルールに基づき、SDFのトラフィックを2つのアクセスに分散させる方法を決定する。

RTTとPLRの測定は以下のsteering modeで使われる。

• RTT: "Priority-based", "Load-Balancing", "Smallest Delay"
• PLR: "Priority-based", "Load-Balancing"

RTTの測定

PMF protocolはTS 24.193で規定されているようですが、動作の概略だけはTS 23.501にあったのでそこだけ書いておきます。

• UEのPMFは、ユーザープレーン上のPMF-Echo RequestメッセージをUPFのPMFに送信し、PMF-Echo Responseメッセージで応答します。逆に、UPFのPMFはUEのPMFに対してPMF-Echo Requestメッセージを送信します。
• あるアクセスにおいて MA PDU セッションのUP接続が解除された場合、このアクセスでは PMF-Echo Requestメッセージは送信されない。UPFのPMFは、UP接続が利用できない場合、または(H-)SMFからこのアクセスでのPMF-Echo Requestの送信を停止する通知を受けた後、このアクセスでPMF-Echo Requestを送信してはならない。
• UEおよびUPFは、アクセス・タイプおよびQoSフローで得られたRTT測定値を平均することで、アクセス・タイプおよびQoSフローでの平均RTTの推定を導出します。

単純な手順ですがシーケンスにするとこんな感じかと思われます。

ただのPingと変わりないですがEthernetでも同じプロトコルで実行できることがポイントかと思います。

PLRの測定

UEとUPFは、PMF-PLR Reportメッセージを交換することによって、SDFのPLRを計算する。PMF-PLR Reportメッセージは、3GPPアクセスまたはnon-3GPP アクセスで送信され、5.32.5.1 節に規定されたデフォルトQoSルールに関連するQoSフローまたはtarget QoS フローのいずれかを使用します。
UE および UPF による PLR の算出は以下のように行う。

• UEはUPF に対し、ターゲットQoS フロー上でPMF-PLR Count Requestメッセージを送信して、受信したULパケットの数のカウントを開始するよう要求する。UPFは、ターゲットQoSフロー上とPMF-PLR Count Requestメッセージを受信したアクセスネットワーク上で受信したULパケットのカウントを開始する。UEは、UPFに PMF-PLR Count Request メッセージを送信すると、ターゲット QoS フローおよびアクセスネットワーク上の送信ULパケットのカウントを開始します。
• UEはカウントを停止し、UPFに対してターゲットQoSフロー上でPMF-PLR Report Requestメッセージを送信して、カウントされたULパケット数の報告を要求します。UPF はカウントを停止し、最後にPMF-PLR Count Requestメッセージを受信してからカウントされたULパケット数を含むPMF-PLR Report ResponseメッセージをQoS Flow上で送信します。
• UEはUPF内の送信ULパケット数と受信ULパケット数のローカル・カウント結果に基づいてULパケ ット損失率を計算します。
• UPF は、DL PLR を計算するために同じ手順を適用します。すなわち、ターゲットQoSフロー上で PMF-PLR Count Request メッセージをUEに送信し、このターゲットQoSフロー上で受信した DLパケット数のカウントを開始するようにUEに要求します。5.32.5.1節に定義されているように、UEは、DLパケットのヘッダー（例えば、SDAPヘッダー）に含まれるQFIを確認することによって、ターゲットQoSフロー上でどのDLパケットを受信しているかを判断します。DLパケットのヘッダにQFIが含まれていない場合、UEは、SMFから受信したQoSルールのダウンリンク用パケットフィルタを適用して、このDLパケットのQFIを決定する。
• UE および UPF は、あるアクセスタイプにおける QoS フローごとの平均 PLR の推定値を、そのアクセ スで得られた PLR 測定値の平均値によって導出する。

単純な手順ですがシーケンスにするとこんな感じかと思われます。

PMFプロトコルスタック

PMFプロトコル・スタック



なお、Ethernet typeの場合は、UDP/IPの場合にEthernetの上でPMF protocolが動作することになる。

ATSSS最新動向

リリース17

TR 23.700-93 Study on access traffic steering, switch and splitting support in the 5G System (5GS) architecture; Phase 2

Key issue #1: Additional Steering Modes

• 追加のステアリングモードの検討
  • UEとNW間、NF間(SMFとUPF間)のネゴシエーション
  • PCCルールの拡張
  • PMFサポート

Solutions for Key issue#1

#2 New steering mode – Autonomous steering mode
UEとUPFがリンクパフォーマンスをみてweightなどを自動調整。

This steering mode, called Autonomous steering mode, provides to both the UE and the UPF flexibility on the traffic splitting control in order to maximize the bandwidth/throughput when two accesses are applicable for this traffic. Then the autonomous steering mode can be applied on these traffic for UE and UPF to flexibly adjust the weight factor on both accesses in order to maximize the bandwidth/throughput.

#3 New steering mode – Autonomous steering mode with advanced PMF

To support these new steering modes, the link performance measurement function (PMF) defined in Rel-16 needs to be enhanced. The Rel-16 PMF can support the RTT measurement and access availability report per PDU session. Regarding the RTT measurement, a default QoS flow is used to transport the measurement traffic, and the RTT value detected on this QoS flow is treated as the RTT for this PDU session via this access. Obviously, it cannot reflect the accurate RTT for every traffic in this PDU session via this access. For some latency sensitive service traffic, the RTT measurement per QoS flow is needed. Furthermore, except the RTT, the loss ratio and jitter are also valuable to be measured for decision of the link performance, and consequently enable better traffic steering/switching/splitting.

#4 New steering mode – Redundant steering mode

During Rel-16 ATSSS study, the redundancy steering mode is documented (see clause 6.3.1.1, 6.4.1 in the TR 23.793 [13]) for the loss rate sensitive traffic, such as IMS singling, video, and some TCP-based traffic. It allows the traffic transmitted via 3GPP and non-3GPP accesses in a redundant way to achieve the lowest latency and lower the loss rate. It is proposed to further enhance the redundancy steering mode as described in the TR 23.793 [13], with which the traffic will always be transmitted over both accesses once applied, to make it possible that the traffic transmission goes via both accesses if necessary or via only one access to save the transport resource.

#11 New steering mode – RTT difference based steering mode

With these enhancements, the UE and UPF may receive a new parameter indicating whether the application is sensitive to disordering or not. In case the application is sensitive or disordering, both UE and UPF may measure the RTT of both accesses and calculate the RTT difference between the two accesses. For RTT measurement, both UE and UPF can apply the existing RTT measurement mechanism defined in TS 23.501 [3] clause 5.32.5 or can use measurement available at the MPTCP/MPQUIC/QUIC layer. In addition, a new parameter called "out-of-order sensitivity" can be sent to UE and UPF by the network that may assist UE/UPF to determine which access(es) will be selected to transmit SDFs. It may be used as described below:

#12 New steering mode – UE assisted traffic steering mode

When this steering mode operation is applied, the UE decides how traffic is steered, switched and split between 3GPP and non-3GPP access based on UE state and UE knowledge of access conditions.

#15 Enhancements to steering mode operation

Extending the steering mode configuration with link performance conditions as an option enables PCF to authorize when needed extra flexibility for both the UE and the UPF to perform the traffic steering accounting the mode intention but also the dynamic link characteristics.

Key issue #2: Additional Steering Functionalities

• UDPとEthernetトラフィックのSplittingの検討。

Solutions for Key issue#2

#1 QUIC-LL Steering Functionality
#6 MPQUIC-LL Steering Functionality
#7 Proposed solution based on MP-QUIC
#8 Proposed solution based on QUIC
#13 Proxy based solution using QUIC
#14 Proxy based solution using MP-QUIC

結局、QUICはのATSSSでの導入は見送られた。

Key Issue #3: Supporting MA PDU with 3GPP access leg over EPC and Non-3GPP access leg over 5GC

• EPC 3GPPアクセス、5GC Non 3GPPアクセスでのMA PDUセッション

Solutions for Key issue#3

#9 Supporting a PDN connection in EPC as a 3GPP access leg of MA-PDU Session
#10 Extension of 5G RG solution to support Ethernet PDU Session types

リリース18

Rel-18 TR 23.700-53 Study on ATSSS support in the 5G system architecture; Phase 3

Key Issue #2: New steering functionalities for non-TCP traffic

Solutions
#2.1 MP-DCCP based Steering Functionality
#2.2 MPQUIC steering functionality using UDP proxying over HTTP
#2.3 MPQUIC steering functionality using IP proxying over HTTP
#2.4 Limiting MA-PDU Per-Packet Overhead

Key Issue #3: Support of redundant traffic steering

Solutions
#3.1 New steering mode - Redundancy steering mode with packet loss rate
#3.2 Redundant traffic steering triggered by AF
#3.3 New traffic duplication operation
#3.4 Redundant steering mode with duplication information
#3.5 Redundant Traffic Steering Mode Activation/Deactivation
#3.6 Redundant steering mode
#3.7 Suspending the Redundancy Steering Mode

duplication criteriaにはPLR Packet Loss Rateを採用

Key Issue #5: Switching traffic of an MA PDU Session between two non-3GPP access paths

Solutions
#5.1 Support traffic switching between two non-3GPP paths
#5.2 Delaying UDM Registration until non-3GPP access switching completes
#5.3 Path switching between non-3GPP accesses
#5.4 Non-3GPP access path switching in MA PDU Session
#5.5 Non-3GPP path switch during Registration in new non-3GPP access
#5.6 Consolidated solution for traffic switching between two non-3GPP access paths

Key Issue #6: Supporting MA PDU Session with one 3GPP access path via 5GC and one non-3GPP access path via ePDG/EPC

#6.1 Support non-3GPP access leg of MA-PDU Session with PDN connection in EPC

リリース19

to be described...