この記事は 3GPP TS23.501(V17.6.0)を読んでいく Advent Calendar 2022
の最終日の記事として執筆したものです。 その他の記事はQiitaのアドベントカレンダー ページからどうぞ！
Calendar for 3GPP TS23.501(V17.6.0)を読んでいく | Advent Calendar 2022 - Qiita
3GPP 仕様書の日本語解説ナレッジとして、今後も重宝されること間違いなしですので、ぜひ他シリーズも今後検討できればと思っています。
はじめに
今回は、下記の記事の総まとめとして、ネットワークスライシングと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
PDU SessionとQoS Flow
5Gにおいて、ユーザデータ（上図でいう、電話やWebブラウジング 、ゲーム等の通信）はUE~DNの間に作られた、2つのトンネルのようなものの中を通ります。それが、PDU Session とQoS FlowQoS Flowという小さなトンネルがいくつも作られています。この2つは必ず一つずつ存在します。
また、PDU Sessionが無いけれどQoS Flowだけが単独で存在する、もしくはその逆や、PDU Session(QoS Flow)の中にPDU Session(QoS Flow)が存在する、といったことはありません。
PDU SessionとQoS Flowはそれぞれ様々な属性を持ちますが、ここでは今回の記事に関連するもののみを紹介します。
PDU Session
PDU Session id:PDU Session を区別するためのID
S-NSSAI:スライシング識別子 (SST +SDから構成される)
QoS Flow
QFI:QoS flow の識別子
5QI:QoS flowのQoS 特性を表す識別子。但し、QFI=5QIとみなす場合もある。
GBR/non-GBR: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.htm l
モバイルネットワークの大きな特徴として、UE〜DNに至るまでに、下記の異なる区間 を経由していることが挙げられます。
無線区間 （UE〜gNB）
NR-Uu,DRB（DataRadioBearer）と呼ばれたりもします。
N3（gNB〜UPF）のトランスポート区間
N6（UPF〜DN）のトランスポート区間
5GにおけるネットワークスライシングとQoS の大きな目的の一つは、これらの異なる区間 をまたいで、PDUsessionとQoS Flowというユーザデータの流れるトンネルに対して、スライシング識別子やQoS 識別子を用いて、帯域制限や優先制御を実施することで、アプリケーション毎のように細かな粒度でトラフィック を制御すること、と思われます。
その実現のためには、各区間 でQoS 制御を行いつつ、それらすべてを協調させて動作させる必要があります。
"協調させて"、の部分はこれまた今をときめくEnd-to-Endオーケストレーション という概念となり、深いテーマとなっていますので、今回は取り扱いません。
そのため以下では、各区間 におけるQoS 制御の例について見ていきます。
（あくまで例としているのは、標準化されている部分もあれば、実装マターとされている部分もあるためです）
RAN(UE~gNB)区間 でのQoS 制御
ここでいうRAN区間 は、いわゆるUE〜gNBの無線区間 のことを指しています。
はじめに述べておきますが、この区間 のスライシング情報に基づいたリソース管理などは、基本的には実装依存 とされています。
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と記載しています。）
Samsung Network Slicing p.15より引用
https://images.samsung.com/is/content/samsung/p5/global/business/networks/insights/white-paper/network-slicing/200420_Samsung_Network_Slicing_Final.pdf
上記例では、S-NSSAI毎にRBの割当比率の下限・上限を定めることで、無線区間 の帯域保証を実現しようとしています。
この例を参考に、gNBはS-NSSAIをもとにして、PDUsession毎にRBの割当比率を保証しつつ、PDUsession内の各QoS Flow同士は、5QIを比較して優先制御を行うとします。
RAN区間 のQoS 制御例
これにより、従来は、複数のUEや各UE内の各アプリケーションの通信はいずれも無線リソースという観点では、区別されること無く、按分されてしまっていましたが、
S-NSSAIや5QIといった識別子を用いて、割当優先度に差をつけることができるようになります。
つまり、従来はベストフォートでしか提供できなかったモバイル回線が、固定回線のような帯域保証（ギャランティ ）型に近い形として提供可能になると考えられます。
これで一番の恩恵を受けるのは、遅延や帯域保証に拘る、TV中継やeSPORTSあたりでしょうか。
N3(gNB~UPF)区間 でのQoS 制御
N3区間 でのQoS 制御例
つづいて、ユーザデータが無線通信から、IP通信になった後のQoS 制御をみていきます。
まず、標準が存在しているQoSFlowの方から見ていきます。
QoS Flowには、5QIというQoS 識別子が付与されています。これはIP-NWで用いられる優先度である、DSCPとの推奨マッピング が下記のようにIETF でも検討されています。
datatracker.ietf.org
#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と相互変換している、のかもしれません。
GTP ヘッダの中のU-plane情報
N6(UPF~DN)区間 でのQoS 制御
N6区間 での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がその役割を実施するものとしています。
ここまでのおさらいとまとめ
E2Eでみるとこんな感じ DSCP以外は、ほぼ実装依存
いままで、UE~DNまでのE2Eを下記3つの区間 に分けて、スライシング識別子やQoS 識別子を用いたQoS 制御の方法について見てきました。
無線区間 （UE〜gNB）
N3（gNB〜UPF）のトランスポート区間
N6（UPF〜DN）のトランスポート区間
各区間 で、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:どうやって帯域制限する？
3つAMBRがある
トラフィック を制限する方法として、5Gシステム内では下記3つの方法があります。
Session-AMBR：各PDUセッションにUL/DLの帯域制限を行う
UE-AMBR：各UE（PDUセッションの合計）にUL/DLの帯域制限を行う
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をアプリケーション毎に変える？
URSP
各構成要素に予め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セッションを同時に確立できる必要があり、現状の市販の端末はほぼ未対応です
