第3回 3GPP SA2における標準化
- 5Gコアネットワーク・アーキテクチャ -

図2からもわかるように、EPCではSGWとPGWのC/U (Control plane/User plane)分離が当初はできていませんでしたが、5GCでは図3のように初めからC-planeとU-planeが明確に分離されています。

U-planeのUPFはユーザーデータパケットの転送だけを行い、セッションの確立・切断はC-planeのSMFが行います。なお、EPCでもリリース14で追加されたCUPS (Control and User Plane Separation of EPC nodes)という機能によりSGW/PGWがControl plane functionとUser plane functionに分離され、完全なC/U分離が実現されています。

このC/U分離により、トラフィックの特性に応じてControl plane functionとUser plane functionを個別に増強したり、User plane functionを地理的に分散配置して遅延を低減させたりすることが可能になります。

EPCでは、W-CDMAやLTEなどの3GPPが規定したアクセス網 (3GPP access network)と、例えばWi-Fiなどのそれ以外のアクセス網 (non-3GPP access network)は異なる方法でEPCに接続していましたが、5GCでは、NG-RAN（5G NRやLTE）以外のアクセス網も、それらと同じインタフェースを使ってコアネットワークに接続することとなりました。リリース15では、この原則に基づいて公衆Wi-Fi網に該当する“Untrusted non-3GPP access network”をN3IWF (non-3GPP Interworking Function)を使って接続する方法が規定されました。これにより、NG-RANとのインタフェースの違いがN3IWFで吸収され、図5のように、C-planeはN2で、U-planeはN3を使ってそれぞれAMF、UPFに接続することができるようになっています。

リリース16ではこれに加えて、有線アクセス網や“Trusted non-3GPP access network”の収容方法が、第2回でご紹介したリリース16のStudy Itemの1つ、“FS_5WWC”で検討されていました。2018年11月に開催されたSA2会合ではこの検討が終了し、2019年から実際の仕様の策定作業を開始することで合意されています。

先ほど、5GCのアーキテクチャとして “reference point representation”と呼ばれる、「これまで見慣れた図」をご紹介しました。この描き方は「どのノードとどのノードが通信をするのか」がわかり易いのですが、実はTS 23.501には別のアーキテクチャ図も描かれていて、実際のアーキテクチャとしては、こちらの図の方が実態をよくあらわしています。

一番の違いは図6からもわかるとおり、C-planeに導入されたサービスベース・アーキテクチャ（Service-based Architecture、以下SBA）です。SBAでは、各NFは1対1 (point-to-point)で接続されるのではなく、全てのNFが1つの通信経路を共有するような形で、各NFがどのNFとも通信できるようになっています。

EPCでは、各ノード間の通信は個別に定義された「レファレンス・ポイント」ごとに個別のプロトコルが規定されていました。これが、5GCではNF間の通信手順をレファレンス・ポイントごとに個別に規定するのをやめ、各NFの機能を「サービス」として定義し、どのNFからも同一のプロトコル、具体的にはHTTP/2でアクセスできるように規定しました。これにより、新たなNFが定義されても、既存のNFへのアクセスは既に定義されている手順をそのまま使うことができるようになっています。

SBAの導入に伴ってC-planeに新たに導入されたのが、NRF (Network Repository Function)です。SBAでは、「あるサービス（NFの機能、例えば、認証やポリシー制御等）」をどのNFが提供しているのかを見つける必要があります。また、自分がどんなサービスを提供できるのかを他のNFに知らせたり、あるNFはどのサービスを使うことができるのかを管理したりする必要があります。そこで、NRFが「サービスの登録」、「サービスの認可」、「サービスディスカバリー」の機能を提供します。

また、NEF (Network Exposure Function)が提供する機能の1つに、AF (Application Function)などの外部のノードとC-plane内のノードの通信を仲介する役割があります。リリース15では、例えば、AFからNEF経由でPCFに対して、UEからのトラフィックをローカルのサーバ宛にルーティングするよう依頼する手順が規定されています。

図6に、5GCのC-planeに新たに導入されたNFとして、もう1つNWDAFというNFがあります。実は、TS 23.501ではアーキテクチャ図には記載されていないのですが、“Network Analytics Architecture”という別の項目として記載されています。一方、TS 23.503のPCCフレームワークのアーキテクチャ図には記載されています。名前が示すとおり、ネットワークの分析情報を提供するNFですが、リリース15ではこの分析情報は個々のスライスの負荷情報に限定されていました。リリース16では、このNWDAFの機能を拡張することで、5Gネットワークの自動化を可能にしようという検討が行われています。これが、第2回でご紹介したリリース16のStudy Item、“FS_eNA (Study of enablers for Network Automation for 5G)”です。この検討では、下記のようなユースケースが検討されています。

このユースケースからもわかるように、リリース16ではネットワークの状況に応じてQoSを変更したり、ユーザートラフィックの経路を変更したりすることが検討されており、NWDAFを活用して動的に5Gネットワークの最適化を行おうとしています。

FS_eNAでは、NWDAFでどのようなデータをどのように収集するか、及び、その分析結果をネットワークに対してどのようにフィードバックするか、が検討されていますが、収集されたデータをどのように分析するかは標準化の対象外となっています。NWDAFにはネットワーク全体からのデータが集められ、そのデータ量は膨大になることが想定されるため、ベンダーによっては、NWDAFでの分析にAIを活用することを考えているところもあるようです。5Gネットワークでは、NWDAFによって「データの収集⇒分析⇒フィードバック」という自動化の流れが可能になりそうです。

EPCでは、U-planeのノードとしてSGW, PGWという2つのノードが定義されていましたが、5GCではUPFのみになりました。これは、U-planeに介在するノードの数を減らすことで、網内での遅延を減らそうとしています。従って、あるDNに向けたセッション上には、UPFは通常は1つだけですが、通信の宛先の所在地に応じて、自由に追加・削除ができるようになっています。これにより、例えばエッジコンピューティング用のローカルサーバが別に存在するような場合には、それまでの通信経路の途中にもう1つのUPFが追加されて、そのサーバ宛のトラフィックだけは追加されたUPFからローカルのサーバに転送することができるようになっています。

上の図では、通常のトラフィック（黄色の矢印）を転送するためのUPFに加え、ローカルのサーバ宛のトラフィック（赤色の矢印）を振り分けるためのUPFが追加されています。なお、このローカルのサーバが存在するDNはLADN (Local Area Data Network)と呼ばれます。

5Gでは、第2回でご紹介したようにeMBB, mMTC, URLLCという要件が全く異なるユースケースをサポートすることが求められていますが、これを実現するのがネットワーク・スライシングです。ネットワーク・スライシングでは、超高速通信、膨大な数の端末からの接続、高信頼性、超低遅延といった様々な要件に応じて論理的に独立したネットワークを生成することで、それぞれのサービスで求められる要件を満たすようなネットワークを提供することができます。これにより、これまでは様々なサービスが1つのネットワークに相乗りしていたのに対し、5Gではそれぞれのサービスがそれぞれの要件に合ったネットワークを使うことができるようになります。

ネットワーク・スライシングでは、1つの端末で複数のスライスを使い分けることも可能です。これをイメージにすると以下のようになります。ちなみに、1つの端末は最大で8つのスライスに接続することができると規定されています。

AMFは、端末レベルの処理、例えば、subscriber認証や端末の位置管理を担うため、端末がいくつのスライスに接続しても同一のAMFが処理を担当します。一方、SMFとUPFはスライスごとに選択され、それぞれのDN向けのセッションが確立されます。こうして、端末上で動作する複数のアプリケーションは、それぞれの要件に合ったスライスに接続することで、他のサービスの影響を受けずに通信を行うことが可能になります。