TS 38.300 16.3 Network Slicingを読む - Transport Network Slicingとの考察

こんにちは、Assieです！
前回はTransport Network Slicingについて書きましたが、今回はようやく目的のTS 38.300のRANのNetwork Slicingについて学んでいきたいと思います。
一通り読んだ後にRANとTransportのNetwork Slicingと結合させたらどういう世界観になるか考えたいと思います。

さて、Network SlicingはRANとCore Network(以降CN)両方のパートが関わるものですが、スライスの識別子はS-NSSAI(Single NSSAI)と呼ばれ、一つ以上のS-NSSAIを含んだリストをNSSAI(Network Slice Selection Assistance Information)と呼びます。NSSAIには最大8つのS-NSSAIが含められます（つまり1つのNSSAIには最大8スライス情報まで）。このNSSAI値はUEによってRRCSetupCompleteの時に付与されます。

S-NSSAIには、以下2つのフィールドがあります。
・必須フィールド：SST (Slice-Service Type)(8ビット)
・オプショナルフィールド：SD (Slice Defferentiator) (24ビット)

各スライスはSLAベースか、Subscriptionタイプベースで切ることが想定されているみたいです。

NG-RANにおけるNetwork Sliceの基本的なポリシーは以下。
・スライスがRAN Awareであること。
　事前に設定済みのスライスに対して、トラフィックを適切にステアリングすること。
　どのNFをスライスに入れるかは実装依存。
・スライス内のRANの部分のセレクション
　UEか5GCから送られてくるNSSAIによってスライスの中のRANの部分を適切に選択する。
・スライス間のリソースマネジメント
　NG-RANはSLAにあわせたRRMを適用する。
・QOSのサポート
　Rate Limit。
・RANノードによるCNの選択
・スライス間のリソース分離
・アクセス制御
・スライスのアベイラビリティの確認
・複数スライスへのUEの紐づけのサポート
・スライスアウェアネスの粒度
　PDUセッションレベル。
・UEのスライスへのアクセス件の確認

基本的な考え方はスライスはダイナミックに切るのではなく"Preconfigured"で、この仕様ではトラフィックが流れてきたときに適切にスライスを選択する方法、と複数スライスに対しての考慮等を中心に考えてあるのかなと思いました。

コアNW側に関しては、スライスのセレクションに関係があるのは、AMFです。
NG-RANでは接続するAMFをTemp ID, NSSAIを見て選択します。

次にResourceのIsolation(分離)に関してです。Resource Isolationはスライス間でインパクトがないように工夫するやり方です。
どう分離するか(ソフトベースか、ハードベースか)は実装次第で、各スライスはTS28.541にあるように専用リソース・シェアドリソース・優先度つけされたリソースに紐づけることが可能です。
また、Multi-Carrier Resouce SharingかResource Partitioningも可能だそう。

ここからはシーケンスです。
まずはAMFとスライスの選択プロセス。

先にgNBとAMF間でNG-SETUP REQUESTが送られるタイミングで、NSSAIの情報も交換していくみたいです。
そのあとUEからのRRC(Connection) Setup CompleteにTempID, NSSAIが乗ってきて、そのNSSAIに基づいてスライス選択・関連AMFにまわしていくという感じです。

そのあとはAMFからInitial Context SetupがAMF-gNB間でやりとりされます。

その後、別のAMFと新しくPDUセッション確立する必要がある時はそのAMFからPDU Sessuon Resource SEtup RequestがgNBに送られてきます。

ハンドオーバーに関しては、以下みたいなやりとりです。

以上がTS 38.300のNetwork Sharing部です。
ふむふむふむ。
どうやってTransportと連携するんや。。。
落ち着こう。。。

ポイントはNSSAIに基づいた①スライスの設定、②スライスの選択だと思うのですが、
①スライスの設定に関してはRANに関してもこのTSには書いてないですね。
ここはOrchastratorからRAN, Transport, CoreのNSSAIの設定をするものとして、
TransportもTransport Network ControllerでNSSAIとVPNのマッピングをとってそれベースでQoS設定をいれたらひとまず既存のトランスポートのスライス技術には対応させてPreconfiguredなスライスは切れるのかしら。
SRのTE・Flex-Algoでのスライシング入れれたらいいけど、SRはもっとダイナミックに動いてくれるのに対して、NSSAIでのスライスってだいぶ静的な設定の入れ方だしなぁ、、SRの良さを生かしきれない。。
けどE2EのVPNのプロビも大変だし、SRのほうがいいのかなあ。。
上記はIPレイヤの話で、Optical Layerのスライスに関してはNSSAIとの連携の話とか全く出てきてないので道のりは遠い。。

②スライスの選択に関しては、正直全く思いついてない。。
RRCSetupCompleteに乗ってくるNSSAI情報をどうやってTransportが読むのか。。
ここが難しすぎる。。IPヘッダにNSSAI乗ってくるって見た気がするけど、誰が設定するのか。。。Opticalは。。
ぜんっぜんわからない。。
NSSAI値は実際のルーティングの時には読まずにVPNで分けて転送するとかしかないと思うのだけど、、

ものっすごくもやもやしか残らないのだけど、結論としてはやっぱりRANとCoreの世界間の中でしかスライスを考えてないから真のE2E Slicingまでは遠い。。

以上です