3GPP仕様書 TS23.501 Rel18 L4S対応 - 低遅延通信

はじめに・概要: L4Sと5G-Advanced（Rel-18）の接点

3GPP Release 18（5G-Advanced）で導入された「L4S (Low Latency, Low Loss, and Scalable Throughput)」対応について、その技術的背景、5Gシステムアーキテクチャにおける仕様およびその周辺内容について解説することを目的とする。L4Sは、IETFによって標準化された革新的な輻輳制御技術であり、これを5Gシステムに統合することで、XR、クラウドゲーミング、遠隔操作といった、極めて厳格な低遅延と高スループットを両立するようなサービス要件に対応することが期待される。

L4Sが解決する課題：キューイング遅延の克服

L4Sの根本的な目的は、インターネットの通信品質を劣化させる最大の要因の一つである「キューイング遅延」を低減することにある。キューイング遅延とは、ルーターやスイッチのバッファにパケットが滞留することで発生する遅延であり、従来の輻輳制御アルゴリズムでは、この遅延を完全に避けることが困難であった。

従来の輻輳制御（IETF RFC 3168で定義されたClassic ECN（Explicit Congestion Notification）など）は、バッファがほぼ満杯になった際にパケットをドロップするか、ECNマークを付与して輻輳を通知する。このECNマークは「パケットドロップと等価」と見なされるため、送信側は送信レートを大幅に減少させる。この大ざっぱな制御では、バッファが一時的に満杯になるまでキューイング遅延が増加し、その後でしかレート調整が行われないため、低遅延を安定的に維持することができなかった。

これに対し、L4Sはより緻密なアプローチを採用する。IETF RFC 9331に定義されているL4S ECNプロトコルでは、ネットワークはClassic ECNよりも早い段階で、より頻繁にECNマークを付与する。このL4SのECNマークはドロップと等価ではなく、より軽微な輻輳信号として扱われる。これにより、L4S対応の送信側は、ごくわずかなキューイングの兆候を検知しただけで、段階的かつきめ細かなレート調整を行うことが可能となり、結果としてキューの滞留を従来手法にくらべ削減することが期待される。

3GPP Rel-18におけるL4Sサポートの意義

3GPPは、5Gの設計段階からユーザープレーン遅延の削減を目標に掲げており、Release 16ではURLLC (Ultra-Reliable Low Latency Communication) が導入された。しかし、URLLCが産業制御などにおける「超信頼性」を最優先する一方、高レートかつ容量追求型のアプリケーション（例：XR、クラウドゲーミング）においては、データ流入がリンク容量を超えた際に発生する遅延の急増、パケットロス、ジッター増加といった課題が依然として残されていた。

この課題を解決するため、L4Sは3GPP 5G-Advanced Release 18の主要な機能の一つとして採用された。L4Sは、無線区間（RAN）の動的な容量変動やネットワークの輻輳を、ECNマーキングを通じてリアルタイムにアプリケーションに通知することで、アプリケーションレイヤでの効率的なレート適応を促す。L4Sは、URLLCが対象とする領域とは異なる、より広範なアプリケーションの低遅延・高スループット要件を満たすための、5Gシステムの重要な補完技術として位置づけられる。また、L4Sは5Gネットワークスライシングと組み合わせて利用することで、特定の低遅延サービス専用のスライス内でその価値を発揮できることも示唆されている。例えば、XR向けの特定スライスを定義し、そのスライスに属する全てのQoS Flowに対してデフォルトでL4Sを有効化するポリシーを適用する、といった運用が考えられる。これにより、スライス内のgNBやUPFはL4Sトラフィックを効率的に処理するためのリソース（例: Dual-Queue AQM用のバッファ）を予め確保し、サービス品質を保証しやすくなる。

3GPP TS 23.501 Rel-18におけるL4S対応の概要

L4Sのサポートは、5GシステムのQoS（Quality of Service）フレームワークに統合され、特定のトラフィックを識別し、適切なサービス品質を適用するという5Gの基本思想に沿ったものであり、TS 23.501の5.37.3節には、以下のように記載されている。

In 5G System, ECN marking for L4S may be supported. ECN marking for L4S is enabled on a per QoS Flow basis in the uplink and/or downlink direction and may be used for GBR and non-GBR QoS Flows. ECN marking for the L4S in the IP header is supported in either the NG-RAN (see clause 5.37.3.2 and TS 38.300 [27]), or in the PSA UPF (see clause 5.37.3.3).

L4Sを有効化する最小単位: QoS Flow

L4S対応は、QoS Flowを最小単位として有効化される。QoS Flowは、5GシステムにおけるQoS管理の基本単位であり、特定のサービスやアプリケーションのトラフィックをエンド・ツー・エンドで識別・処理するために使用される。L4SをQoS Flow単位で有効化することにより、ネットワークは、L4S対応アプリケーションのトラフィックと、そうでないトラフィックを明確に区別し、異なる処理を適用することができる。

L4S対応が可能なQoS Flow種別

L4Sは、GBR (Guaranteed Bit Rate) および Non-GBR QoS Flowの両方で使用することが可能である。

• GBR: 厳しい遅延要件を持つリアルタイムアプリケーション（例：XR、ビデオ会議）向けに、保証されたビットレートを提供する。L4Sを適用することで、保証された帯域内での低遅延・低パケットロスをより安定的に実現できる。
• Non-GBR: ベストエフォート型のトラフィックに適用される。L4Sを適用することで、高負荷時でもキューイング遅延を抑え、より快適な通信体験を提供できる。

この両方のQoS FlowでL4Sがサポートされることは、L4Sが特定のニッチなサービスだけでなく、汎用的な機能として利用されうることを示している。

ECNフローがトリガされるパターン: L4S対応QoS Flowの確立

5Gシステムにおいて、L4S対応のQoS Flowを確立するプロセスは、複数のパターンが定義されており、運用上の柔軟性をオペレーターに提供している。これは、L4S対応QoS Flowを確立するための実装形態が複数存在することを示しており、事業者は用途に応じて方式を選択するか、あるいは機器ベンダーの実装に依存することになる。実用的な観点からは、P2のようにトラフィックのECNケーパビリティ（ECT(1)など）をUPFで動的に検出し、専用のQoS Flowへ振り分ける方式が効率的かつ簡潔であると考えられる。

P1: 静的確立 (Statically)

PDUセッション確立時に、L4S QoS Flowが常に確立されるモデルとなる。これは、PCFからの静的なPCCルール、またはSMFのローカル設定に基づいて行われる。

P2: 5GC設定に基づく動的確立 (Dynamically based on 5GC configurations)

このモデルは、ネットワークリソースを効率的に使用するため、トラフィックが実際にL4S対応である場合にのみQoS Flowを確立する。

1. SMFがUPFに検出フィルタをインストール: SMFは、PCFからの要求またはローカル設定に基づいて、L4Sトラフィックを検出するためのフィルタをUPFに設定する。このフィルタは、IPヘッダのECNビット（ECT(1)またはCE）や、XRサーバーのIPアドレスなどの情報を使用できる。
2. UPFがL4Sトラフィックを検出: UPFは、受信したパケットがフィルタに一致すると、L4Sトラフィックであると判断する。
3. UPFがSMFに通知: UPFはL4Sトラフィックの検出をSMFに通知する。
4. SMFがL4S QoS Flowを確立: SMFは、PCFが利用可能であればPCFに通知し、PCCルールを更新して新たなL4S QoS Flowの確立をトリガする。PCFが利用できない場合は、SMF自身のローカル設定に基づいてL4S QoS Flowを確立する。

この動的な確立方法は、ネットワークリソースの無駄な消費を抑えつつ、トラフィックがL4S対応であることを検出した際に、即座に最適なQoSを提供することを可能にする。

P3: AFリクエストに基づく動的確立 (Dynamically based on AF request)

外部のアプリケーション機能（AF）が、NEF (Network Exposure Function) またはPCFを経由して、特定のトラフィックにL4Sサポートを要求するモデルである。この要求により、5Gシステム内でセッション変更手続きがトリガされ、L4S対応のQoS Flowが設定される。これは、5GのService-Based Architecture（サービスベースアーキテクチャ）の思想をL4Sに適用したものであり、アプリケーションの要求にリアルタイムに応じたQoS変更を可能にする。基本的にはSMFが設定される以降はP1と同様のフローになる。

NEF 経由の場合

観測とECNマーキング

3GPP Rel-18のL4S仕様において、輻輳を検知しECNマーキングを行う主体は、無線アクセスネットワーク（NG-RAN）と、PDUセッションアンカーUPF（PSA UPF）のいずれかであり、その選択はオペレーターのネットワーク構成とポリシーに基づいて、(PCF)SMFが決定する。

UPFマーキングの場合

UPFがL4Sマーキングを行う場合、NG-RANは輻輳の検知と情報報告の役割を担う。

原文TS23.501では以下のような記載がある。

5.37.3.3 Support of ECN marking for L4S in PSA UPF
To enable ECN marking for L4S by a PSA UPF, a QoS Flow level ECN marking for L4S indicator may be sent by SMF to PSA UPF over N4. SMF also indicates to NG-RAN to report the congestion information (i.e. a percentage of packets that UPF uses for ECN marking for L4S) of the QoS Flow on UL and/or DL directions via GTP-U header extension to PSA UPF and accordingly, the PSA UPF may mark the UL and/or DL direction packets of the QoS Flow. If there is no UL packet when report for DL and/or UL needs to be provided, NG-RAN may generate an UL Dummy GTP-U Packet for such a reporting.
The SMF may be instructed, based on either dynamic or predefined PCC rule, to provide an indication for ECN marking for L4S to PSA UPF for a corresponding QoS Flow(s) in UL and/or DL directions.
Upon successful activation of congestion information reporting for UL and/or DL directions, PSA UPF uses information sent by NG-RAN in GTP-U header extension (see TS 38.415 [116] and TS 38.300 [27]) to perform ECN bits marking for L4S for the corresponding direction.

• シーケンス:
  1. NG-RANは、無線区間における輻輳状態を監視する。
  2. NG-RANは、監視結果として得られた輻輳情報（マーキングすべきパケットの割合など）を、GTP-Uヘッダの拡張フィールドを介してPSA UPFに報告する。
  3. PSA UPFは、NG-RANから報告された輻輳情報に基づき、ユーザーIPパケットのECNビットをマークする。

ここで重要な点は、輻輳報告がアップリンクのGTP-Uパケット（UL PDU SESSION INFORMATION）に集約されるという仕様上、ダウンリンクの輻輳情報もアップリンクのパケットに乗せてUPFへ通知される点である。

RANマーキングの場合

NG-RANがマーキングを行う場合、NG-RANは自律的に輻輳を検知し、ECNマーキングを適用する。

原文TS23.501では以下のような記載がある。

5.37.3.2 Support of ECN marking for L4S in NG-RAN
ECN marking for L4S may be supported in NG-RAN as specified in TS 38.300 [27].
To enable ECN marking for L4S in NG-RAN, dedicated QoS Flow(s) are used for carrying L4S enabled IP traffic. The SMF may be instructed, based on either dynamic or predefined PCC rule, to provide an indication for ECN marking for L4S to NG-RAN for a corresponding QoS Flow(s) in UL and/or DL directions. In the absence of such PCC rule, the use of ECN marking for L4S in NG-RAN on a QoS Flow is controlled by a coordinated configuration in NG-RAN and 5GC.

参照先のTS 38.300においては、以下のような記載がある。

SMFからECNのマーキング要求があり、gNBがECNマーキングをサポートしている場合にはSMFに設定が適用できたかを返す。

16.16 ECN marking for L4S and congestion information exposure
In order to support ECN marking for L4S at gNB as specified in TS 23.501[3], SMF provides ECN marking request per QoS flow level to the gNB as part of PDU Session Resource Management procedure. If the gNB supports ECN marking, it provides the status indication back to the SMF which is used by the SMF as specified in TS 23.501[3]. During Xn Handover Preparation procedure, source gNB provides the ECN marking request to target gNB.

• シーケンス:
  1. NG-RANは、自身の無線リソースの負荷状況などから、輻輳状態を自律的に検知する。
  2. 検知結果に基づき、NG-RANは、UEに送信するダウンリンクパケット、またはUPFに送信するアップリンクパケットのインナーIPヘッダにECNマークを直接付与する。

実際にはAMF経由でセッション変更情報がNGAP(TS 38.413)でgNBにリクエストされることになる。RAN側でのマーキングにおいては自律的に輻輳自体を検知してマーキングを実施することになるが、シーケンスとしてはSMF起点のセットアップについてもシーケンスに含めた。

RANにおけるGTPとSDAP SDUのインターワークを以下に示す。仕様上はあくまでSDAP/SDUにおいてIPヘッダにECNを付与すると記載がある。

同じQoS Flow上での最小単位であるSDAPでECNをつけることが、もっともあり得るシナリオであるが、この辺りは輻輳情報の項目と判断基準に何を採用するかにより、実装依存が考えられる。

UE
 └─ PDU Session (PDU Session ID, DNN/APN)
     └─ QoS Flow (QFI)
         └─ SDAP PDU (SDU)
             ↓ (SDAP mapping)
           DRB (Data Radio Bearer)
             ↓ (PDCP/RLC/MAC)
           N3 GTP-U Tunnel (TEID)

以上、このマーキング主体の選択がRANとUPFにて２つあることは、モバイルネットワークのボトルネックが無線区間（NG-RAN）とコアネットワーク（UPF）の両方で発生しうることを反映している。NG-RANが直接マーキングするモデルは、無線区間の輻輳をUEに最も迅速に伝えることができ、効率的である。一方、UPFがマーキングするモデルは、RANとUPF間のトランスポートネットワークの輻輳にも対応できる可能性があり、RAN側の機能が限定的な場合でもL4Sを適用する柔軟性を担保している。その反面、DLへのECNマーキングについてもUPFまで報告をした後にUPFがECNマーキングを実施するため輻輳検知からマーキングの実施までに遅延が発生することで、真の輻輳ポイントに対してマーキングできないデメリットもある。

ハンドオーバーとL4Sの継続性

L4S対応のQoS Flowは、UEが移動してNG-RANやPSA UPFが変更されるハンドオーバー時にも、そのL4Sマーキングが継続されることが推奨されている。もし、新しいNG-RANまたはUPFがL4Sをサポートしていない場合、アプリケーション機能（AF）にはL4Sが利用できなくなったことが通知される仕組みとなっている。（省略）

RAN/UPFにおける輻輳とは何か

RAN（Radio Access Network） で「輻輳」と言う場合は、無線アクセス側のいずれかのレイヤーで供給可能なリソースより需要が多く、QoS低下やスループット制限が発生している状態を指す。具体的には、以下のようにレイヤー別に輻輳の意味が分かれる。

レイヤー	説明	備考
L3（RRC）	ネットワーク側の無線リソースが不足し、新たなRRC接続や無線ベアラの確立が拒否される状態	接続数の上限到達、基地局リソース不足
L2（MAC/RLC）	キューイング遅延の増加やパケットドロップが発生。L4Sの測定項目候補。	MACスケジューラでの割当不足、RLCバッファ溢れ
L1（物理層）	無線干渉やカバレッジ不足によりリンク品質が低下し、有効スループットが低下	SINR低下、フェージング、遮蔽物

UPF（User Plane Function） で「輻輳」と言う場合は、以下の意味合いが考えられる。

状態	説明	備考
N3/N9インターフェースの帯域飽和	RANとUPF間（N3）やUPF間（N9）のトランスポートネットワークにおいて、実際のトラフィックが物理リンクや予約帯域の容量を上回る状態。	N3（gNB⇔UPF）、N9（UPF⇔UPF）、トランスポートネットワーク層
UPF内部の処理リソース不足	UPFが管理するPDUセッション数やQoS Flow数の増加により、CPU・メモリなどの処理リソースが限界に達している状態。パケット処理や転送性能が低下する。	UPF（ユーザプレーン処理、L2/L3/L4レベルの処理）
パケットバッファのキューイング遅延	UPF内部のバッファが満杯になり、パケットのキューイング遅延が増大、あるいはパケットドロップが発生する状態。L4Sの測定項目候補。	UPF内部バッファ、L2/L3バッファ制御

L4Sにおける「輻輳」の検知は、主にキューイング遅延の増加とバッファ占有率が中心となる。これは、IETFがL4Sで目指している「低遅延」の目標と直接関連している。コアネットワーク側のリソースは基本的に多く確保されているため、イベントや障害による当初設計からの偏りが生じない限りは輻輳は無視できると考えられる。L4Sのためのインジケータ元情報としては無線リソースを管理する方が適していると考えられる。

マーキング戦略

原文TS23.501では以下のように記載があり、NG-RAN側のECNマーキング条件、UPFでの輻輳情報からECNへの変換方法、NG-RANが輻輳情報を提供する条件についても実装依存となる。

5.37.3.2 Support of ECN marking for L4S in NG-RAN
The criteria based on which NG-RAN decides to mark ECN bits for L4S is NG-RAN implementation specific.

5.37.3.3 Support of ECN marking for L4S in PSA UPF
NOTE: How the congestion information is converted to ECN markings is UPF implementation specific.
The criteria based on which NG-RAN decides to provide the congestion information is up to NG-RAN implementation.

マーキング単位

RANでマーキングする場合、3GPP TS 23.501/23.502/23.203などではQoS Flow単位が基本で、QFI（QoS Flow Identifier）単位でのパケット処理が想定されている。同一QoSフロー内でECNマーキングの閾値や確率を検討する必要がある。

マーキングの観測方法

L4Sの仕様では、輻輳を検知するための特定の観測方法（アルゴリズム）は規定されていない。L4Sの基本思想はキューイング遅延を最小化することにあるため、以下の指標が観測点として使用することが候補となる。ただし、リポート可能な値（後記）は１次元のため、キュー長・遅延・再送率などを重み付けして輻輳スコア化することになる。

項目	説明
キューの長さ	gNBのRLC/MACキュー長（バイト数・パケット数）が閾値を超過した割合
キューイング遅延時間	パケットのMAC待機時間やRLC遅延が一定閾値を超えた割合
パケットドロップ率	バッファオーバーフローなどによるパケットの破棄率。
スケジューラ優先度ベース	高優先度QoS Flowが継続して遅延・欠落している割合

確率的マーキングの指定有無

RFC 3168やRFC 7567（AQM Recommendations）では、ECNマーキングは**確率的（probabilistic）**に行うべきとしているが、特定のアルゴリズムに固定する指示はない。RFCでは推奨方式の例として以下が挙げられている。

アルゴリズム	説明
RED (Random Early Detection)/WRED	バッファ占有率に応じて線形または非線形でマーキング確率を増加させる。
PIE (Proportional Integral controller Enhanced)	キュー遅延時間を目標値に保つように確率を動的制御。
CoDel (Controlled Delay)	一定時間以上キューに滞留したパケットを優先的にマーキングまたはドロップ。
PI2	PIEの改良版で二次制御項を追加、Googleなどの大規模データセンターで採用例あり。

3GPP側の仕様では、RANノードがどのAQM方式を使うかは実装依存である。RED系、PIE/PI2系、あるいはベンダー独自のハイブリッド方式が検討の候補となる。

GTP拡張ヘッダ

UPFマーキングモデルにおいて、NG-RANはGTP-Uヘッダー拡張を用いて輻輳情報をPSA UPFに報告する。この仕組みは、UPFがL4Sのマーキング主体となるための基盤であり、RANとUPF間の連携を可能にする。

この拡張ヘッダーは、TS 38.415（NG-RANと5GC間のインターフェース仕様）およびTS 38.300（NRおよびE-UTRAの全体説明）で定義されており、NG-RANが自律的に検知した無線区間の輻輳レベルを、IPヘッダーの変更なしにUPFに伝える役割を担う。

拡張ヘッダの構成は3GPP TS 38.415 / TS 38.300 に記載の “QoS Monitoring Report” / “Congestion Information” に相当し、主に以下が含まれる。

GTP-U拡張ヘッダの基本構造：

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |  Message Type (0xFF)  |     Length                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      TEID (Tunnel Endpoint Identifier)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Sequence Number (optional)   |  N-PDU Number (optional)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Extension Header Type (if any)                          | <---拡張ヘッダ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Extension Header Type が 0x85であればCongestion Informationを含む拡張ヘッダなどが後続に来ることになる。この拡張ヘッダタイプは3GPP TS 29.281には明示的に言及されていないが、TS 38.415の中に0x85 = PDU Session Containerの拡張ヘッダとして定義されているUL PDU SESSION INFORMATION (PDU Type 1)の構造体にCongestion Informationが含まれて定義されている。

[GTP-U Header] (TS 29.281)
   |
   +-- Next Extension Header Type = 0x85 (PDU Session Container)
        |
        +-- [PDU Session Container Header] (TS 29.281)
        |
        +-- [PDU Session User Plane Protocol Frame] (TS 38.415)
              |
              +-- PDU Type 1 (UL情報)
                     ...
                     +-- New IE Flags
                     +-- UL Congestion Information (2 octets)
                     +-- DL Congestion Information (2 octets)

[PCAP image]
GTPv1-U
  Flags: .... (E=1 )
  Message Type: G-PDU (0xFF)
  Length: ...
  TEID: ...
  Sequence/NPDU: ...
  Next Extension Header Type: PDU Session Container (0x85)
  Extension Header: PDU Session Container (Type=0x85, Len=3)
    PDU Session User Plane Protocol
      PDU Type: 1 (UL PDU SESSION INFORMATION)
      QFI: 9
      New IE Flags: 0x06
        .... ..1.  UL Congestion Information present
        .... .1..  DL Congestion Information present
      UL Congestion Information: 0x2576  (9574)  → 95.74 %
      DL Congestion Information: 0x0F9C  (3996)  → 39.96 %
      Next Extension Header Type: No more extensions (0x00)

Congestion Information は PDU Type 1（UL）にのみ定義されている。末尾側の New IE Flags の bit1/bit2が立っているとき、直後にそれぞれ 2B で現れる。

TS38.415のCongestion Information該当部分は以下のとおりである。

5.5.3.25 DL Congestion Information
Description: For the cases of ECN marking at UPF request, this field indicates the percentage of DL IP packets up to two decimal points that should be ECN marked for a QoS flow.
For the case of congestion information request, this field should be interpreted as a percentage of congestion level in DL up to two decimal points for a QoS flow.
As an example, value 9574 corresponds to a percentage of 95.74%.
Value range: {0..10000}.
Field length: 2 octets.
5.5.3.26 UL Congestion Information
Description: For the cases of ECN marking at UPF request, this field indicates the percentage of UL IP packets up to two decimal points that should be ECN marked for a QoS flow.
For the case of congestion information request, this field should be interpreted as a percentage of congestion level in UL up to two decimal points for a QoS Flow.
As an example, value 9574 corresponds to a percentage of 95.74%
Value range: {0..10000}.
Field length: 2 octets.

値の単位は 0.01%（固定小数）であり、2Bで表現されている。（例：9574 → 95.74%。値域は 0..10000（= 0.00%..100.00%））UL/DL どちらの Congestion Information も、UL 側のフレーム（PDU Type 1）に搭載され、RAN→UPF に報告される（RANが測定／集約）。UPFはこれを基に ECNマーキング割合や情報のExposureを実施する。

RAN側でのECNマーキングが有効化され、かつTS 23.501の手順においてSMFからのN2/NGAP:PDU Session Resource Setup/Modify Requestにて、UPF側のMarkingが実施されているかが判明すると想定するため、QoS MonitoringやAF要求で輻輳レベル報告が有効化されている場合は「現在のDL輻輳度％」を送ることになる。他方では、UPFでのECNマーキングが有効な場合においては、「UPFがこの割合でDLパケットにECNを付けるべき」という目安がこの項目で送られることになる。同じように、UPFは、当該QoS Flowの制御プレーン情報（N4経由でSMFから受信）を参照し、このフィールドをどちらの意味として扱うかを決定する。

ECNのRFC側観点での動作

L4Sの真価は、ネットワークとエンドポイント（UE/AS）のプロトコルスタックがIETFのL4S仕様に準拠して協調動作することによって発揮される。UEのOS（Linux、Android、iOSなど）のカーネルがL4S対応の輻輳制御アルゴリズム（TCP Pragueなど）をサポートし、アプリケーションがAPI経由でそれを有効にできなければ、5Gネットワーク側がL4Sをサポートしてもエンド・ツー・エンドでの低遅延は実現されない。

Classic ECNとL4S ECNの相違点

L4Sは、従来のECN（Classic ECN）の課題を克服するために設計された。この2つのアプローチの違いを以下に示す。

特徴	Classic ECN (RFC 3168)	L4S ECN (RFC 9331)
輻輳信号の振る舞い	深刻な輻輳時にマーク。パケットドロップと等価と見なされる。	軽い輻輳の兆候で高頻度にマーク。ドロップと等価ではない。
キューの管理	一般的にRED/WREDのようなSingle-Queue AQM。	Dual-Queue AQMフレームワーク（ClassicとL4Sでキューを分離）。
トランスポートの応答	深刻なレート減少（ウィンドウサイズを乗法的に減少）。	きめ細かく、段階的なレート調整。
結果	キューイング遅延が増加しやすい。	平均でミリ秒未満のキューイング遅延を維持。

この表が示すように、従来のECNが「キューイング遅延の増加を許容してスループットを最大化する」というアプローチだったのに対し、L4Sは「キューイング遅延を最小限に抑えつつスループットを維持する」という新しい目標を追求している。

ECN対応の判別

L4S対応のトランスポート（TCP, QUIC, SCReAMなど）を使用するUEやアプリケーションサーバーは、L4S対応をネットワークに表明するため、IPヘッダのECNフィールドをECT(1)に設定してパケットを送信する。5Gシステムは、この ECT(1)コードポイントを持つパケットをL4S対応トラフィックとして識別し、適切なL4S対応QoS Flowにマッピングする。

RFC 3168/7567に基づくと IPヘッダのTraffic Class（IPv6）またはTOSフィールド（IPv4）の下位2ビットがECNフィールドとして使われる。値は以下の通りである。

ビット値	名前	意味	備考
00	Not-ECT	ECN非対応（従来のドロップベース輻輳制御）
01	ECT(1)	ECN対応、コードポイント1	RFC 3168, RFC 9330など(L4S)
10	ECT(0)	ECN対応、コードポイント0	RFC 3168
11	CE (Congestion Experienced)	Congestion Experienced（輻輳通知）

輻輳検知時のアプリケーションとの動作連携

L4S対応のネットワークノード（NG-RANやUPF）が輻輳を検知し、ECNマーク（CE）を付与したパケットを送信する。このパケットをUEが受信し、さらにその受信をアプリケーションサーバーに通知することで、トランスポートレイヤ（QUIC, SCReAMなど）が輻輳フィードバックを受け取る。UEおよびアプリケーションサーバーは、このフィードバックに基づき、アプリケーションレイヤ（例：ビデオエンコーダ）のレートをリアルタイムに適応させる。このレート調整の具体的な振る舞いは、IETF RFC 9331に定義される「Scalable congestion control」アルゴリズムに準拠して、UE/AS側で実装される。つまり、フォワードのECNに対して、上位のトランスポートにおける連携動作からのフィードバック通知にて実際の送信元のレートが調整されることになる。

以下に、L4S対応のトランスポート例を挙げる。

	主な役割	プロトコルスタック位置	主な上位プロトコル	実装例・実績
SCReAM(Self-Clocked Rate Adaptation for Multimedia)	映像/音声などリアルタイムメディア向けの低遅延混雑制御。ECNを用いた輻輳回避とレート適応を行う。	アプリケーション層（RTP/UDP）上で動作する送信レート制御アルゴリズム	RTP、WebRTC	IETF実験仕様（draft-ietf-rmcat-scream）、Ericsson等の試作実装、研究用途
TCP Prague	L4S（Low Latency, Low Loss, Scalable Throughput）対応の低遅延TCP混雑制御。ECN(Ect(1))を用いて混雑を検知。	トランスポート層（TCP）	HTTP/2、HTTP/3（TCP版）、FTP等	IETF実験仕様（draft-ietf-tsvwg-ecn-l4s-id）、Linuxカーネル実装あり。商用大規模展開は限定的、5G実験やEU RITEプロジェクト等
QUIC（L4S対応版を含む）	TCPの代替となる低遅延かつ暗号化デフォルトのトランスポートプロトコル。L4S対応版ではECN(Ect(1))利用可能。	トランスポート層（UDP上）	HTTP/3、カスタムアプリプロトコル	Google Chrome、Cloudflare、Akamaiなど大規模商用運用（L4S対応は実験段階）
BBRv2（Bottleneck Bandwidth and Round-trip propagation time, v2）	TCP用の遅延・帯域推定型混雑制御アルゴリズム。ECN対応でL4S利用も可能。	トランスポート層（TCP）	HTTP/2、HTTP/3（TCP版）、FTP等	Google、YouTube配信などで大規模利用（v1）、v2はLinuxカーネルで利用可能（5.19以降）
DCTCP（Data Center TCP）	データセンター内での低遅延・高スループット混雑制御。ECN(Ect(0))を利用。	トランスポート層（TCP）	RPC、分散ストレージ、分散計算	Microsoft Azure、データセンター間トラフィック制御などで商用利用実績あり

利用可能なトランスポートはいくつか存在するが、現在までに広く商用のネットワークで使われているのは限定的であり、既存の方式との混在に課題を抱えている状態である。

BBRv2でのECNの利用例

BBRv2は、Googleが開発した輻輳制御アルゴリズムで、ECNを輻輳シグナルとして活用する。ECNの動作モードは2つあり、Classic Flowにも対応した動作をする。

• 輻輳シグナル: BBRv2は、パケットロスだけでなく、ECNマークも輻輳の兆候として捉える。これにより、キューが一杯になる前に積極的にレートを調整し、レイテンシーの悪化を防ぐ。

• 状態遷移: BBRv2には、ネットワークの帯域幅を探索するPROBE_BWという主要なフェーズがある。

  PROBE_BWフェーズでは、BBRv2は送信レートを上げて帯域幅をプローブする。この際、ECNマーク率を監視し、ECNマークが一定の割合を超えると、送信レートの増加を抑えたり、逆に減速したりする。これは、ECNによって帯域幅の限界が示されたと判断するためである。

このように、ECNはBBRv2がネットワークの動的な状態を正確に把握し、最適な送信レートを維持するための重要な情報源となる。

ClassicFlowとの分離、影響

ECNは非常に有用な輻輳回避の技術であるが、商用環境での普及は限定的である。その最大の理由は、既存のトラフィックとの公平性の問題にある。

ECNトラフィック vs. Classicトラフィック: 従来のTCP（Cubicなど）はパケットロスに反応してレートを減らすが、ECNトラフィックはCEマークに即座に反応してレートを下げる。

キューの競合: ネットワーク中間にあるルーターのキューがECN対応トラフィックと非ECN対応（Classic）トラフィックで共有されている場合、ECNトラフィックはCEマークを受け取るとすぐに送信レートを下げるが、Classicトラフィックはパケットがドロップされるまでレートを維持する。これにより、Classicトラフィックがキューを占有し、ECNトラフィックが不公平に帯域を失うことになる。

中継機器の対応不足: ECNを正しく機能させるためには、エンドホストだけでなく、経路上のすべてのルーターがECNに対応している必要がある。ECNを正しく処理しない機器があると、ECN対応ホストが不利になるか、ECNそのものが機能しない。中継部分やバックボーン、モバイル部分などEncapの存在する環境である場合はRFC 6040(Tunnelling of Explicit Congestion Notification)のようなアプローチも必要と考えられる。また、商用展開における隠れた課題として、経路上に存在するファイアウォール等のMiddleboxがECNビットを正しく透過しない可能性も考慮する必要がある。

このように2種類のフローが単一の共有キューで競合すると、問題が発生する。スケーラブルなフローは、その非常にきめ細かな調整によって、キューが膨らむ前に素早く送信レートを調整する。一方、Classicフローはより大きなバッファを必要とし、その「のこぎり波」の振る舞いによってキューを頻繁に満たそうとする、いわゆるグローバル同期（global synchronization）を引き起こす。これにより、両者が混在すると、スケーラブルなフローが、より攻撃的かつ素早い反応によって、Classicフローが獲得できるはずの帯域幅を奪ってしまうという「不公平性」が生じる。この問題は、特にRTTが長いパスや、高帯域幅のリンクで顕著になる。このジレンマは、サーバとクライアントのようなエンドポイントのソフトウェア修正だけでは解決できず、ネットワークアーキテクチャ全体のアーキテクチャ変更が不可欠であることを示している。

L4Sは、ClassicトラフィックとL4Sトラフィックが共存する環境で機能するよう設計されている。この共存を実現するために、L4SはDual-Queue Coupled AQMと呼ばれるフレームワークに依存する。これは、L4Sトラフィックを専用の低遅延キューで処理し、Classicトラフィックを従来のキューで処理することで、Classicトラフィックの挙動（大きなキューの構築）がL4Sトラフィックの低遅延性を損なうのを防ぐ。L4Sは、Classicトラフィックの性能に悪影響を与えることなく、自身の低遅延・高スループット性能を達成することを目指している。

Dual-Queue Coupled AQMについては主にRFC9330に記載があり、単一のキューではなく、L4Sトラフィック用とClassicトラフィック用の2つの独立したキューを設ける。

• レイテンシ分離: L4Sキューは、Classicキューから切り離され、優先的に処理される。これにより、L4Sトラフィックは、Classicフローがもたらす大きなキューイング遅延の影響を受けることなく、常に低いレイテンシを享受できる。通常は重み付けされたスケジューラであるWRRやSPなどによりL4S側に優先権を与える。
• 帯域幅プーリング: 2つのキューは、輻輳シグナリングによって「結合」(coupled) されている。ClassicキューのAQMは、自身の輻輳状況を両方のキューのマーキング確率に影響させる。この仕組みにより、L4Sフローは、Classicフローの存在を認識し、そのために帯域幅を譲るよう調整される。結果として、スケジューラがL4Sキューに優先権を与えても、長期的に見れば両者は公正な帯域幅を共有することが可能となる。

まとめ

3GPP Release 18におけるL4Sサポートは、5Gシステムが次世代の低遅延・高スループットサービスを本格的に支えるための重要な進化である。この対応は、IETFによって定義されたL4Sプロトコルを5GのQoSフレームワークに統合するもので、従来の輻輳制御では克服が困難であったキューイング遅延という本質的な課題に、ひとつの解決策を提供する。 L4Sは、5Gネットワーク以外にも、DOCSIS（ケーブルブロードバンド）、Wi-Fi、光ファイバーなど、様々なネットワーク技術で採用されている。これは、L4Sが特定の技術に限定されない、インターネット全体における低遅延化という普遍的な課題を解決する技術であることを示している。

しかし、L4Sが真に普及し、エンドユーザーがその恩恵を享受するためには、ネットワークインフラ（5G RAN/UPF）がL4Sマーキング機能をサポートするだけでなく、エンドユーザーデバイス（UE）のOSや、クラウドゲーミング・XRなどのアプリケーションのクライアントソフトウェアがIETFのRFC 9330/9331に準拠したL4Sプロトコルスタックを実装する必要がある。このエンド・ツー・エンドのエコシステム全体での連携が、L4Sの商用展開における最大の課題であり、このエコシステムの成熟度を測る上でポイントになると考えられる。

参考文献

• What is L4S? - Deutsche Telekom https://www.telekom.com/en/company/details/easy-and-simple-what-is-l4s-1094112
• L4S | Nokia.com https://www.nokia.com/bell-labs/research/l4s/
• 5G architecture support for XR and media services https://www.3gpp.org/technologies/xr-sa2
• L4S: A Breakthrough in Internet Congestion Control — Insights For Success https://www.kiledjian.com/main/2025/1/31/l4s-a-breakthrough-in-internet-congestion-control
• RFC 9330: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture - » RFC Editor https://www.rfc-editor.org/rfc/rfc9330.html
• RFC 9331: The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S) - » RFC Editor https://www.rfc-editor.org/rfc/rfc9331.html
• Explicit Congestion Notification (ECN) RFC 3168 - ECE/CIS https://www.eecis.udel.edu/~amer/856/ecn.05f.ppt
• Optimizing 5G-Advanced Networks for Time-critical Applications: The Role of L4S - arXiv https://arxiv.org/html/2407.20852v1
• Information on RFC 9330 » RFC Edito https://www.rfc-editor.org/info/rfc9330
• Information on RFC 9331 https://www.rfc-editor.org/info/rfc9331
• L4S in 5G networks - DiVA http://kth.diva-portal.org/smash/get/diva2:1484466/FULLTEXT01.pdf
• L4S – low latency, low loss, and scalable throughput - Nokia https://www.nokia.com/asset/213410
• 3GPP Portal > ChangeRequests https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=990110