5.21 Architectural support for virtualized deployments
はじめに
本記事は 3GPP TS23.501(V17.6.0)を読んでいく Advent Calendar 2022の5.21 Architecture support for virtualized deploymentsに関する紹介記事となります。また、本記事では全文章の日本語訳を掲載するわけでなく、ポイントのみをまとめていきます。
5.21章、Architecture support for virtualized deploymentsでは、5Gの特徴の一つである仮想化をサポートするために、5GCにおいて導入されたアーキテクチャに関して紹介しています。章の構成としては、以下のようになっております。
| サブセクション | 内容 |
|---|---|
| 5.21.0 General | 章全体の概要を記述 |
| 5.21.1 Architectural support for N2 | N2(RAN~AMF間)インターフェースにおける仮想化のための拡張 |
| 5.21.2 AMF Management | AMFの管理に関して記述 |
| 5.21.3 Network Reliability support with Sets | NF Setによる信頼性の向上 |
| 5.21.4 Network Function/NF Service Context Transfer | NF間のコンテキスト情報の送信 |
謝罪
Advent Calendarの担当日の22時から執筆を開始したところ、時間が猛烈に足りずにまだまだ途中です。
少しずつコンテンツを追加していく予定です。
5.21.1 Architectural support for N2
そもそもN2はどこか？
本セクションが対象とするN2インターフェースは、上図(3GPP TS23.501 V17.6.0 Fig.4.2.3-1より引用)のように、RANとAMFの間のインターフェースを指します。
N2の端点であるRAN(基地局、gNB）とAMFの中で、本セクションではAMFを仮想化する場合の検討点を整理しています。特に、全国に分散されたRANがどのように仮想化により分散されたAMFを選択するのか記述されています。
TNL association
本セクションでは、Transport Network Layer(TNL)、Transport Network Layer Association(TNLA)という用語が頻出します。ここでいう「Transport Network Layer」が何を指すかというと、私が調べた限りでは明確な定義を記述した3GPPの文書を発見することができなかったのですが、RANとAMF間のL4(Transport) Protocolのことを指しているようです。
図(3GPP TS23.501 V17.6.0 Sec8.2.1.2より引用)のように、N2インターフェースにおいてはL4プロトコルとしては、SCTP(RFC4960)を利用します。本セクションにおいては、あるAMF(AMF Set?)が、仮想化等により、複数のAMFインスタンスにより構築されている場合に、ある基地局が複数のAMFとSCTPセッションを接続し、UEからの接続要求に対してその複数AMF間でロードバランスするための手法が記述されています。
複数AMF間のロードバランスに関しては上図のようなイメージでしょうか（AMF_1、AMF_2、AMF_3があるAMF Setを構成している前提です）。RAN～AMF間のSCTPセッションは常に接続されており、UEからの接続要求(例：Registration)があった際に、AMFより通知された重み（Weight）によって重みづけをしながら、そのUEが接続する実際のAMFインスタンスを決定します。
疑問？
原文(Sec5.21.1.1)では「5G-AN node shall have the capability to support multiple TNL associations per AMF, i.e. AMF name.」と記述されています。直訳すると、一つのAMF毎に複数のTNL association＝SCTPセッションを接続できるとのことですが、上図のようにAMFインスタンスが分かれていない場合は複数セッションを接続するメリットは何も無いと思うので、上の解釈をしておりますが、あってますかね・・・？
具体的な実装例としては、AWSが発行している5G Network Evolution with AWSにおいて、TNL Associationにより、ある基地局が、異なるAvailability Zone(AZ)のAMFと複数のSCTPセッションを接続することが記されています(P.21)。
ちなみに、NG-AP Protocolの中では、このWeight値はTNL Address Weight Factorとして定義されているようで、0～255のIntegerであり、0の場合はそのAMFへNGAPメッセージを送信しないようになるとのことです(NG-RAN; NG Application Protocol (NGAP) Sec9.3.2.10より)。
TNL Associationの決定に関しては、以下のように記述されています
- UEからの初期メッセージ(例：N2 INITIAL UE MESSAGE)に関しては、(1)各TNL Associationの利用状況と(2)各TNL Associationにおいて通知されたWeight値を用いてあるTNL Association(≒AMF)を決定する
- CM-Connected状態なUEからのメッセージは初期に割り当てられたTNL Associationに送信すべき (shall)
- AMFは既存のCM-Connected状態なUEのTNL Associationを変更することができる
5.21.2 AMF Management
（工事中、後日公開予定）
5.21.3 Network Reliability support with Sets
（工事中、後日公開予定）
5.21.4 Network Function/NF Service Context Transfer
（工事中、後日公開予定）