3GPP Release 18標準化活動（2）
3GPP Release 18におけるネットワーク自動化およびAI/MLの高度化技術

2.1 精度監視

一般に，AI/MLを用いる利点は，ネットワークの性能と効率を向上させることである．しかしながら，AI/MLベースのソリューションの有効性は，MLモデルの性能に依存する．また，MLモデルが不正確な予測を提供する場合，予測に基づく決定によってネットワークの性能が低下する可能性がある．従って，AI/MLの利用が有効であり続けるには，MLモデルの精度を監視し，それを考慮することが重要である．このため，Rel-18では，MLモデルの精度監視と，分析の精度監視の2つの概念が導入された．

前者は，MTLFを含むNWDAFによって提供されるMLモデルの精度指標を表す．これは，すべての予測の中でMLモデルによる正しい予測の数と，全予測に対応するサンプル数で構成される．

同様に，後者は，AnLFを含むNWDAFによって提供される分析ID^*20と呼ばれる特定の分析に対応した性能指標であり，すべての予測の中でその分析IDにおける正しい予測の数と，予測に対応するサンプル数で構成される．なお，分析については後述する．

Rel-18における精度監視アーキテクチャを図2に示す．

この精度監視アーキテクチャでは，デファクト機能であるNFコンシューマ^*21でのAI/MLを活用した意思決定，AnLFでの推論，MTLFでのモデル訓練に加えて，新たにAnLFとMTLFにおける「精度確認」機能が提供される．

AnLFでの精度監視および確認では，例えば，特定の分析IDに関連する予測と予測に対応する正解データをAnLFの精度確認機能が比較することで，NFコンシューマに提供されたAnLFによる分析結果の精度を監視する．この目的のため，NFコンシューマは，AnLFの分析結果に対するフィードバックを，AnLFに提供することができる．また，AnLFが精度の問題を検出した場合，NFコンシューマに提供した分析結果の使用を停止または一時停止するようNFコンシューマに通知し，分析結果の精度情報をMTLFに提供することができる．

MTLFの精度確認機能を使用すると，例えば，AnLFが提供する精度情報を利用する精度確認機能のロジックに基づいて，MTLFはMLモデルの性能を監視できる．精度監視の結果に基づいて，MTLFはMLモデルを再訓練し，更新されたモデルをAnLFに送信することを決定する．

2.2 複数のNWDAF間のFL

5GCでの複数のNWDAFの配備はRel-17でサポートされているが，NWDAF間の相互作用はない．NWDAFの訓練にあたって，このことは，各NWDAFがアクセス可能なデータベースの訓練データのみを使用してMLモデルを最初から訓練する必要があることを意味する．これにより，次の2つの問題が発生する．

• 複数のNWDAFで同じMLモデルを訓練すると，計算資源が浪費される．
• NWDAF間で訓練データの共有ができないことから，各NWDAFの訓練データが限られているため，許容可能な性能を達成するには，十分な訓練データを収集しなければならず，かなりの時間が必要になる可能性がある．

これらの問題に対処するために，Rel-18において，NWDAF間のFLが導入された．FLとは，複数のクライアントが中央サーバの監視下で，訓練データを交換することなく，各クライアントが独自に保持するデータを使用してモデルを共同で訓練する分散型MLモデル訓練手法である．

一般的なFLの訓練手順は，①FLサーバが複数のFLクライアントを選択し，モデルの現在のバージョンを共有する，②各FLクライアントがローカルの訓練データを使用してMLモデルを訓練し，MLモデルの更新情報をFLサーバに送信する，③FLサーバがFLクライアントからの更新情報を集約し，グローバルMLモデルの新しいバージョンを生成する，というステップで構成される．これらの3つのステップは，停止判定がなされるまで続く．

NWDAF間のFLは，図3に示すように，3GPP仕様の3つの主要な手順によってサポートされている．具体的には，①登録と検出手順，②FL訓練手順，③FL保守手順である．

1. まず，FL訓練に参加するFLサーバおよび／またはFLクライアントを含むNWDAFは，その能力をNRF（Network Repository Function）^*22に登録する．
   次に，FLサーバはFL訓練手順を開始する前に，適切なFLクライアントを検出する必要がある．そのため，FLサーバはNRFに照会してFLクライアントを検出し，NRFに登録されているすべてのFLクライアントの中から訓練に用いるFLクライアントを選択する．
2. 主なFL訓練のループがFLサーバによって実行される．まず，FLサーバは，選択されたFLクライアントにMLモデルの現在のバージョンを共有する．次に，FLクライアントのNWDAFは，各々が使用可能なローカル訓練データを使用してこのモデルを訓練し，モデルの更新情報をFLサーバのNWDAFに送信する．最後に，FLサーバのNWDAFは更新を集約し，グローバルMLモデルの新しいバージョンを作成する．
3. さらに，FLクライアントがFL訓練（例えば，十分なリソースと訓練データがある）に適切に参加できるようにするために，FL保守手順もRel-18で導入された．この手順により，FLクライアントは訓練の状態をFLサーバに報告し，FLサーバはFLクライアントの追加／削除を決定する．

なお，Rel-18においては特に，水平連合学習（HFL：Horizontal Federated Learning）^*23をサポートしている．HFLでは，NWDAFなどのすべての訓練参加者が訓練データの同じ特徴セットをもつ，すなわち，FLクライアントとして機能するすべてのNWDAFは，データソースから同じ特徴／特性をもつデータを収集する．

2.3 ローミングにおけるデータと分析結果の交換

Rel-17では，分析機能は同一のPLMN内でのみサポートされており，VPLMN（Visited PLMN）^*24にローミングアウトした端末のHPLMN（Home PLMN）^*25観点での分析機能は提供されない．この問題を解決するため，Rel-18では，PLMN間のデータおよび分析機能の交換がサポートされている．全体のアーキテクチャを図4に示す．このアーキテクチャでは，各PLMNにRE-NWDAF（Roaming Exchange NWDAF）と呼ばれる専用のNWDAFを配置し，他のPLMNとデータおよび分析結果を交換する．

ローミングシナリオでの全体的なデータと分析結果の交換の流れを次に述べる．

PLMN（HPLMNなど）のNFコンシューマは分析結果を必要とし，H-RE-NWDAF，またはHPLMNにデプロイ^*26された他のNWDAFに，特定の分析IDと分析対象のスライス選択のための補助情報を含む分析結果の要求を送信する．後者の場合，デプロイされたNWDAFは，分析結果を提供するには他のPLMNからのデータが必要であるか，データを別のPLMNで生成する必要があると判断する．その結果，データまたは分析結果の要求をH-RE-NWDAFに送信する．前者・後者いずれの場合も，H-RE-NWDAFが別のPLMNのNWDAF（V-NWDAF）との連携を介して提供すべきデータまたは分析結果の要求を行う．

このため，H-RE-NWDAFはH-NRFを介して対応するV-RE-NWDAFを検索する．その後，H-RE-NWDAFはデータまたは分析結果の要求を該当のV-RE-NWDAFに送信する．VPLMNでは，V-RE-NWDAFは要求されたデータや分析結果をH-RE-NWDAFに提供する．V-RE-NWDAF自身がこれらのデータや分析結果を提供できない場合，VPLMN内の別のNWDAFへデータまたは分析結果を生成することをリクエストし，その結果をV-RE-NWDAFはH-RE-NWDAFに提供する．

2.4 モデルの格納と検索

Rel-17では，ADRFは分析結果やデータの格納先であったが，Rel-18では，MLモデルの格納先としても使用できる．MTLFを含むNWDAFは，MLモデルをADRFに格納でき，この格納されたモデルをそのNWDAFまたは他のNWDAFが取得できる．このことは，NWDAF間で間接的にMLモデルを共有することを意味する．

Rel-18におけるADRFからのMLモデルの取得手順を図5に示す．この手順では，NFコンシューマからのMLモデル要求（ステップ①）を取得した後，MTLFを含むNWDAFは，要求されたモデルがADRFに格納されていることを確認し，MLモデルをADRFから取得するかどうかを決定する（ステップ②）．NFコンシューマへの応答には2つのオプションがあり，NWDAFが，ADRFからMLモデルを取得して（ステップ③），NFコンシューマに返すか（ステップ④），ADRFからモデルを取得するために必要な情報をNFコンシューマに通知する（例えば，ADRFのID，ストレージ情報など）．その後，NFコンシューマはADRFからモデルを取得する（ステップ⑤）．

2.5 ネットワーク分析の拡充

Rel-18では，さまざまなNFがより知的な意思決定を行うために使用できる，多くの新しい分析が導入されている．分析の概要を以下に示す．

2.6 Rel-19におけるAI/ML

5GC AIの強化はRel-19でも継続されている．FS_AIML_CNはRel-19で検討されている項目であり，4つの重要な課題を解決する．

1. 1つ目は，AI/MLをRAN側に適用するための5GC側のサポートである．3GPP RAN WGでは，SA2と並行して，AI/MLを活用したNG-RAN（Next Generation-RAN）^*44の性能向上の検討を行っている．CSI（Channel State Information）^*45フィードバックの強化，ビームマネジメント，端末位置決定精度の向上など，さまざまなユースケースが特定されており，TR38.843[6]に文書化されている．これらのユースケースにAI/MLを利用するには，RANの強化に加えて5GCの拡張が必要になる可能性があり，Rel-19においてFS_AIML_CNの最初の重要課題で検討されている．
2. 2つ目は，垂直連合学習（VFL：Vertical Federated Learning）^*46のサポートである．前述のように，NWDAF間のHFLはRel-18でサポートされている．HFLの基本的な想定は，NWDAFなどのすべての訓練参加者が訓練データの同じ特徴セットをもつことである．これは，FLクライアントとして機能するすべてのNWDAFが，データソースから同じ特徴／特性をもつデータを収集可能である必要があることを意味する．しかし，FLにおいて常にその想定通りになるとは限らず，シナリオによっては，異なるNWDAFが異なる特徴をもつデータにアクセスする可能性がある．
   この場合に対応するため，VFLでは，NWDAFなどの訓練参加者が同じデータサンプルに対して異なる特徴をもつモデルをもつ場合においても共同で訓練することができる．例えば，とある参加者は特定の端末（データサンプル）の位置／移動に関する情報（特徴／特性）をもち，別の参加者は同じ端末のトラフィックに関する情報をもつ場合などが考えられる．
   このMLモデル訓練の手法は，QoE（Quality of Experience）^*47に関連した分析において，NWDAFがAF側のユーザ体験のすべての詳細にアクセスできない場合，NWDAFとAFの間で使用することもできる．
3. 3つ目は，PCF（Policy Control Function）^*48に対するNWDAF支援によるQoSとポリシー制御の強化である．Rel-18では，PCFはQoSフローのQoSパラメータを決定するために，端末通信などの分析結果をNWDAFから購読することがあるが，PCFは過去の行動を考慮しない問題がある．すなわち，PCFは，QoSフローに適用されたQoSパラメータが実際に端末に期待された性能をもたらしたかどうかを考慮しない．そこで，過去に適用されたQoSパラメータもNWDAFが評価することで，PCFを支援するNWDAFによるQoSとポリシー制御の機能を向上させられる．
4. 4つ目は，AI/MLを活用した，信号量過多の検出と信号量の緩和である．この目的のために，NWDAFの機能を拡充して，5GC内の他のNFが信号量過多を検出／予測するのを支援する情報を提供し，NFが適切な対策を講じることができるようにする．

3.1 ユースケースと要件

TR22.874[7]では，SA1は5GC上のAI/ML操作（ML訓練・デプロイなど）の主なユースケースとして，次の3つを特定した．

3.2 ネットワーク開示の拡充

5GCでは，NEFはAFに5GC情報を開示する機能を担っている．AI/MLアプリケーションの場合，Rel-17ですでにサポートされた情報開示に加え，Rel-18では，例えば，適切なAI/ML操作の分割を決定する際に，アプリケーション層をサポートするためのいくつかの追加情報が，AFに開示される場合がある．この追加情報には，例えば，FLに参加する端末群のQoS，SMFから収集したPDUセッションの不活性時間，トラフィック量，UPFから取得したUL/DLデータレートが含まれる．

3.3 AI/MLトラフィック転送サポート

前述のように，AI/MLアプリケーションでは，AFから端末群へのMLモデルの配布と，MLモデルの計画的な更新という2つのトラフィックパターンが一般的である．これらのトラフィックパターンに対して，Rel-18の5GCでは，マルチメンバAFセッションと，QoS要件付計画的データ転送（PDTQ：Planned Data Transfer with QoS Requirement）ポリシー交渉を使用した計画的なデータ転送のサポートという2つの拡張機能が導入されている．

3.4 アプリケーション層におけるFLの支援

Rel-18の5GCでは，AFがFLサーバとして機能し，端末がFLクライアントとして機能する場合において，アプリケーション層のFLを容易にするための拡張が導入されている．

AFは，端末をFLクライアントのメンバとして選択するために，端末の位置，端末の移動性，端末の5Gシステムへの接続性能など，多くの要因を考慮する必要がある．このような多くのパラメータを収集することは，AFにとって複雑な作業であり，5GCとAFの間の付帯的信号も増加させる．

これらの問題に対処するために，Rel-18では，NEFは「メンバ端末選択支援機能」と呼ばれる新しいサービスを提供している．この機能は，AFが提供する対象メンバ端末のリストの中から，1つまたは複数の候補端末のリストと，定義したフィルタリング基準に基づいて5Gシステムが生成した支援情報を基にした追加情報を，外部事業者が取得できるようにするものである．

全体の手順を図8に示す．図8は5つのステップから構成されている．最初に，NEFはAFから，初期端末リスト，および必要に応じて時間枠，および1つ以上のフィルタリング基準（例えば，端末の現在位置，端末の移動方向，QoS要件，DNN，優先アクセス／RAT（Radio Access Technology）種別^*54など）を含む要求を受信する（図8①）．

次に，AFによって提供されたフィルタリング基準に基づいて（図8②），NEFは関連する5GC NF（例：PCF，NWDAF，AMF，SMF）から，対象メンバ端末のリスト内のすべての端末の対応するデータを収集する（図8③）．そして，NEFは，フィルタリング基準を満たす候補端末のリスト（すなわち，AFによって提供された初期端末のリストの中の端末）を導出する（図8④）．

最後に，NEFは，候補端末の1つまたは複数のリスト，および必要に応じて他の追加情報（例えば，アプリケーション操作を実行するための1つ以上の推奨時間枠，各対象端末のQoS，アクセス／RAT種別など）を含む，メンバ端末選択支援情報をAFに提供する（図8⑤）．加えて，対応するフィルタリング基準を満たさない，フィルタリング基準ごとの端末数を提供することもできる．