この記事は 3GPP TS23.501(V17.6.0)を読んでいく Advent Calendar 2022
の最終日の記事として執筆したものです。
その他の記事はQiitaのアドベントカレンダーページからどうぞ！
Calendar for 3GPP TS23.501(V17.6.0)を読んでいく | Advent Calendar 2022 - Qiita
賛同して記事を執筆して頂いた皆様、ありがとうございました！
3GPP仕様書の日本語解説ナレッジとして、今後も重宝されること間違いなしですので、ぜひ他シリーズも今後検討できればと思っています。
- はじめに
- 基本構成図
- PDU Session とQoS Flow
- RAN(UE~gNB)区間でのQoS制御
- N3(gNB~UPF)区間でのQoS制御
- N6(UPF~DN)区間でのQoS制御
- ここまでのおさらいとまとめ
- 参考1:どうやって帯域制限する？
- 参考2:どうやってS-NSSAIをアプリケーション毎に変える？
はじめに
今回は、下記の記事の総まとめとして、ネットワークスライシングとQoSについて個人的な理解を図解してみました。
3GPP TS23.501 5.7 Qos model を読んでいく - omusubi techblog
3GPP TS23.501 5.15 Network Slicing を読んでいく - omusubi techblog
簡略のため省略している部分もありますが、そもそも全然違うよ！といった指摘がございましたら、ぜひぜひお待ちしております。
基本構成図
ネットワークスライシングとQoSを理解するには、まず基本的な5Gアーキテクチャを理解しておく必要があります。本記事では、必要な構成要素のみを抜粋した上図を今後用いていきます。用語の意味はざっくり下記です。
- UE:スマートフォン等、端末のこと
- gNB:CU,DU,RUをまとめて総称したもの。基地局と言ったほうがわかりやすい。
- 5GC:コア機能のこと。AMF,SMF,UDM,PCF,UPFはすべてコア機能の一部
- N1/N2:UE,gNB~AMF間のインタフェース
- N3:gNB~UPF間のインタフェース ,N4:UPF~SMF間のインタフェース
- N6:UPF~DN間のインタフェース
- Transport NW:各インタフェース間をつなぐNW(≒IPv4/IPv6 NW)
- DN:DataNetworkの略。インターネットとかアプリケーションサーバのこと。
- C-plane:制御信号 ,U-plane:ユーザデータ
PDU Session とQoS Flow
5Gにおいて、ユーザデータ（上図でいう、電話やWebブラウジング、ゲーム等の通信）はUE~DNの間に作られた、2つのトンネルのようなものの中を通ります。それが、PDU SessionとQoS Flowです。イメージとしては、PDU Sesionという大きなトンネルの中に、QoS Flowという小さなトンネルがいくつも作られています。この2つは必ず一つずつ存在します。
また、PDU Sessionが無いけれどQoS Flowだけが単独で存在する、もしくはその逆や、PDU Session(QoS Flow)の中にPDU Session(QoS Flow)が存在する、といったことはありません。
PDU SessionとQoS Flowはそれぞれ様々な属性を持ちますが、ここでは今回の記事に関連するもののみを紹介します。
- PDU Session
- QoS Flow
QoS Flowを5QI,GBR/non-GBR,QoS特性毎にマッピングして標準化された一覧表は、
TS 23.501Table 5.7.4-1: Standardized 5QI to QoS characteristics mapping
に記載されています。
https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-501_zb.html
モバイルネットワークの大きな特徴として、UE〜DNに至るまでに、下記の異なる区間を経由していることが挙げられます。
5GにおけるネットワークスライシングとQoSの大きな目的の一つは、これらの異なる区間をまたいで、PDUsessionとQoS Flowというユーザデータの流れるトンネルに対して、スライシング識別子やQoS識別子を用いて、帯域制限や優先制御を実施することで、アプリケーション毎のように細かな粒度でトラフィックを制御すること、と思われます。
その実現のためには、各区間でQoS制御を行いつつ、それらすべてを協調させて動作させる必要があります。
"協調させて"、の部分はこれまた今をときめくEnd-to-Endオーケストレーションという概念となり、深いテーマとなっていますので、今回は取り扱いません。
そのため以下では、各区間におけるQoS制御の例について見ていきます。
（あくまで例としているのは、標準化されている部分もあれば、実装マターとされている部分もあるためです）
RAN(UE~gNB)区間でのQoS制御
ここでいうRAN区間は、いわゆるUE〜gNBの無線区間のことを指しています。
はじめに述べておきますが、この区間のスライシング情報に基づいたリソース管理などは、基本的には実装依存とされています。
TS38.300 NG-RAN overall description (V17.2.0)の16.3.1 General Principles and Requirements の記載を下記に引用します。
RAN awareness of slices
- NG-RAN supports a differentiated handling of traffic for different network slices which have been pre-configured. How NG-RAN supports the slice enabling in terms of NG-RAN functions (i.e. the set of network functions that comprise each slice) is implementation dependent.
Resource isolation between slices
- The NG-RAN supports resource isolation between slices. NG-RAN resource isolation may be achieved by means of RRM policies and protection mechanisms that should avoid that shortage of shared resources in one slice breaks the service level agreement for another slice. It should be possible to fully dedicate NG-RAN resources to a certain slice. Some RACH resources can be associated to specific NSAG(s). Other aspects how NG-RAN supports resource isolation is implementation dependent.
RAN Slicingというキーワードで、Rel-17で標準化された部分もありますが、これはユーザデータのQoS制御というよりも、RACH手順やセル選択といったUEがgNBと無線通信を開始する手順において、S-NSSAIを意識した制御を可能とする、といったものでした。詳細は過去の下記記事を参照ください。
TR38.832 Study on enhancement of RAN slicing を読む [前編] - omusubi techblog
したがって、ここではSamsungのホワイトペーパーで記載されている、S-NSSAIによるRBパーティションという事例をもとに見ていきます。
（RB=リソースブロック。無線リソースをブロック単位で表したもの。正式にはPRB
ですが、以下ではRBと記載しています。）
上記例では、S-NSSAI毎にRBの割当比率の下限・上限を定めることで、無線区間の帯域保証を実現しようとしています。
この例を参考に、gNBはS-NSSAIをもとにして、PDUsession毎にRBの割当比率を保証しつつ、PDUsession内の各QoS Flow同士は、5QIを比較して優先制御を行うとします。
これにより、従来は、複数のUEや各UE内の各アプリケーションの通信はいずれも無線リソースという観点では、区別されること無く、按分されてしまっていましたが、
S-NSSAIや5QIといった識別子を用いて、割当優先度に差をつけることができるようになります。
つまり、従来はベストフォートでしか提供できなかったモバイル回線が、固定回線のような帯域保証（ギャランティ）型に近い形として提供可能になると考えられます。
これで一番の恩恵を受けるのは、遅延や帯域保証に拘る、TV中継やeSPORTSあたりでしょうか。
N3(gNB~UPF)区間でのQoS制御
つづいて、ユーザデータが無線通信から、IP通信になった後のQoS制御をみていきます。
まず、標準が存在しているQoSFlowの方から見ていきます。
QoS Flowには、5QIというQoS識別子が付与されています。これはIP-NWで用いられる優先度である、DSCPとの推奨マッピングが下記のようにIETFでも検討されています。
#QCIはLTEでいうところの5QIに該当するものですが、ほぼ同じ概念です
したがって、QoS Flowについては、トランスポートネットワークがIP-NWであれば、
5QI⇔DSCPと読み替えることで、優先制御することができます。
（もちろん、推奨マッピングであって、必ずこのように読み替える必要はありません）
このようなマッピングを行うことは、TS29.244 5.4.13 Transport Level Marking でも下記のように言及されています。
For 5GC, transport level marking is performed on a per QoS flow basis. Transport level marking refers to the process of marking traffic at the UPF with a DSCP value based on the mapping from the 5QI, the Priority Level (if explicitly signalled) and optionally the ARP priority level configured at the SMF.
※UPFはマーキングを実施するけど、gNBも実施するの？みたいな部分はReflective QoSという新しいルールも含めて、別途解説したいとおもいます。ここでは、gNBも同じくマーキングするものとします。
つぎに、PDU SessionのQoS制御について考えます。
こちらについては、標準は存在しないのですが、実装として考えられる方法の1つとして、S-NSSAI毎にVLANを分けるという案が考えられます。
つまり、gNB⇔UPF間はS-NSSAIの数だけVLANトランクが存在し、VLAN単位でQoS制御を行います。
これらをまとめると、下記になります。
- PDU SessionはS-NSSAI毎にVLANに変換して分割
- QoS FlowはQFI(5QI)⇔DSCPの変換を実施
いずれも、Transpor NWでは、5Gでしか登場しない識別子は理解できないので、
gNBやUPFがこれらの変換処理を実施する必要があります。
また、N3区間については、ユーザデータはGTP-Uというプロトコルによりカプセル化されてTransport NWを運ばれます。
GTPのヘッダには、拡張ヘッダが定義されており、その中にPDU session informationが存在しています。この中にはQoS Flow Identifier(QFI)は存在しますが、5QIは存在しません。
今までQFI=5QIとして扱う場合がある、としてきましたが、そもそもユーザデータのヘッダの中に5QIが含まれておらず、QFIしか無いので、仕方なくQFI=5QIとみなして、
これをDSCPと相互変換している、のかもしれません。
N6(UPF~DN)区間でのQoS制御
5Gシステムを抜けて、インターネット等のIP-NWに抜けるのがこの区間になります。基本的には、N3区間と実施することは変わらず、UPF（もしくは5Gシステムを終端する機能部）がPDU SessionをS-NSSAI毎にVLANで分割、QoS FlowをQFI(5QI)をもとにDSCPに変換します。
N3区間と違って、GTP-Uによるカプセル化はされていないのですが、先につながるインターネットやアプリケーションサーバが、Transport NWのときと同じように、S-NSSAIや5QIを理解できないため、何らかの変換を行う必要があります。ここでは、UPFがその役割を実施するものとしています。
ここまでのおさらいとまとめ
いままで、UE~DNまでのE2Eを下記3つの区間に分けて、スライシング識別子やQoS識別子を用いたQoS制御の方法について見てきました。
各区間で、S-NSSAIをRB保証比率やVLAN、5QI(QFI)をRB優先比率やDSCPにマッピングしてきましたが、各区間でそれぞれの制御方法や優先度の重み付けが同一ではなくバラバラになってしまうことが想定されます。
すべての構成要素が単一であれば、そこまで各区間同士でバランスが取れていなくても、ある程度は望む制御が行えるかもしれませんが、gNBが何万という単位で存在し、その間のTransport NWも大規模なNWとなるキャリア網で望むようなE2EでのQoS制御を実現するには、かなりのチューニングが必須と考えられます。
この難解なチューニングを、AI/ML等を用いたオーケストレーターによって最適化したい！、というのが昨今のE2Eオーケストレーションブームのモチベーションのように思います。
※ N3,N6区間は従来の固定回線のQoS制御ノウハウにより、比較的に容易な気もしますが、RANについては、無線リソースのスライシング識別子による分割の実現だけでなく、モビリティという要素も含めると、まだまだ課題山積のように感じられます（Rel-17でのRAN Slicingは、ハンドオーバーのようなサービス継続観点についてはスコープ外となっている）
個人的には、ぜひRANも含めたE2Eでのスライシング及びQoS制御ができるようになって、様々な業界でのイノベーションやブレークスルーに寄与できればと思っています。
参考1:どうやって帯域制限する？
トラフィックを制限する方法として、5Gシステム内では下記3つの方法があります。
- Session-AMBR：各PDUセッションにUL/DLの帯域制限を行う
- UPFで実施
- non-GBR Flowのみに適用
- UE-AMBR：各UE（PDUセッションの合計）にUL/DLの帯域制限を行う
- gNBで実施
- non-GBR Flowのみに適用
- UE-Slice-AMBR：同一S-NSSAIの全てのPDUセッションにUL/DLの帯域制限を行う
- gNBで実施
- non-GBR/GBR Flowの両方に適用
新たにRel-17で追加されたUE-Slice-MBRにより、S-NSSAIをもとに、従来は適用範囲外だったGBR Flowも含めて、帯域制限を行うことができるようになりました。
参考2:どうやってS-NSSAIをアプリケーション毎に変える？
各構成要素に予めS-NSSAIを設定しておけば、今まで見た来たようなアプリケーションごとにS-NSSAIを変えてPDUセッションを確立することは可能です。
但し、実際の運用においてはUEはそのような設定を意識せずとも利用することが求められ、そのためにURSP (User equipment Route Selection Policy)という機能があります。
最近、下記のようなプレスリリース内でも出てきたワードになります。
ソニーとKDDI、5G SA構成で複数ネットワークスライスの同時通信に成功 | 2022年 | KDDI株式会社
これは、簡潔に言うと、UEが通信を開始する際(Registaration)に、5GC側から各アプリケーションで利用するS-NSSAIをUEへ通知する仕組みです。
URSPで受け取った情報を元に、Registrationを完了したUEは、各アプリケーション毎にPDUセッションを確立します。これにより、UE側への事前設定等は不要かつ、あらたなアプリケーションが増えても、UE側での設定が不要となります。
※ただし、これらはUEが複数のPDUセッションを同時に確立できる必要があり、現状の市販の端末はほぼ未対応です
