5GCによるMECアプリケーションのサービスポリシー制御を可能とする新たなアーキテクチャーを提案

1. MECとサービスポリシー

MECとは何か？

MEC（Multi-access Edge Computing）は、ユーザー端末（UE：User Equipment）に近いネットワーク内の計算資源を活用して演算を実行する技術の総称です。従来、データ処理はクラウドやデータセンターで行われていましたが、これにより通信の遅延や帯域の制約が発生していました。MECはこれらの問題を解決し、遅延の低減、帯域の効率的な利用、場所に応じたサービス提供などの利点をもたらします。これにより、ゲーム、XR（Cross Reality / Extended Reality）、自動運転、スマートシティ、IoT（Internet of Things）などでの活用が期待されています。

サービスポリシーの重要性

MECを利用したサービス提供では、サービスポリシーが重要です。これはアプリケーションごとに通信品質（QoS）、セキュリティー、リソース配分を規定する概念です。具体的な制御項目には遅延、帯域、セキュリティー、サービス適用範囲などがあります。特定の場所に特化したサービス（例：スポーツスタジアムでの支援アプリケーション、空港・駅でのリアルタイムな情報通知）が提供され、最適なポリシーが適用されることで快適なサービス体験が実現できます。

このように、MECは単なる分散配置だけでなく、場所に応じたアプリケーションの提供を可能にし、ネットワークの利便性を向上させる技術です。しかし、現在のネットワークでは、MECと5GC（5G Core）の両者にわたる一貫したポリシー適用が難しいという課題があります。

2. 現状のモバイルシステムにおけるMECとポリシー管理の課題

モバイルシステムのC-PlaneとUEポリシー管理

モバイルシステムでは、5GCのC-Planeがポリシー管理を担当します。C-Plane（制御プレーン）はUEのセッション管理、認証、QoS制御を行い、動的な制御を可能にします。5GCは図1に示すように複数のネットワーク機能（NF：Network Function）で構成されています。

図1. 5G System Architecture

特に、以下の主要なNFがポリシー管理に関わっています。

• ・SMF（Session Management Function）：セッションの確立・管理、UPFの選択、ポリシー適用

• ・PCF（Policy Control Function）：QoSや課金ポリシーの適用

• ・UPF（User Plane Function）：ユーザーデータへのポリシー適用と転送

これらの機能により、5GCはN3インターフェース（図1のRANとUPFの区間）までの通信に対して、一貫したポリシーを適用することができます。PCFがQoSポリシーを決定し、それをSMFを介してUPFに適用することで、遅延や帯域、優先度などの通信要件が制御されます。
たとえUEが移動してアクセスネットワークの環境が変化しても、5GCはUE上で動作するアプリケーション（UEアプリケーション）に対して一貫したポリシーを維持する仕組みが整備されているといえます。

MECサービスへのポリシー適用の課題

一方、MECサービスへのポリシー適用には大きく2つの課題があります。

A. MECを含めたネットワーク全体にわたる一貫したポリシー制御

UEからMECにわたるネットワーク全体に一貫したポリシー制御を適用することで、MECの効果を最大化することができます。しかし、通常、MECは5GCの外側（N6インターフェース）に配置されます。そのため、5GCによるポリシー制御がそのままMECアプリケーションに適用されることはありません。
5GC側とMEC側の2つのポリシー制御機構が必要となります。さらに、ネットワーク全体にわたる一貫したポリシー制御を実現するには、両者のポリシー制御機構を密に連動させなければならず、複雑なシステムと運用が求められます。

B. MECアプリケーションへのポリシー適用機能の実現

MECアプリケーションへのポリシー適用機能を実現するには、アプリケーションにポリシー適用機能を実装するか、MECアプリケーションが動作する基盤（例：Kubernetes）がアプリケーションにポリシーを適用する機構を持つかの2パターンが考えられます。前者には Camara API のような5GC を間接的に利用するフレームワークがあります。厳格なポリシー制御がされていないアプリケーションはこうしたフレームワークを利用することでMECサービスに対応することができますが、既存のアプリケーション資産に変更を加える必要があり、開発コストがかかります。後者は、5GCを全く意識しないアプリケーション資産をMECサービスに対応させることができますが、MEC基盤と5GCとの間で一貫したポリシー管理をする必要があり、Aで述べた課題に突き当たります。

3. 5GCによるMECアプリケーションのポリシー制御機構の提案

これまでに述べたように、MECアプリケーションは通常5GCの管理外にあり、UEアプリとは異なるポリシー適用の仕組みが必要でした。これが原因で、MEC基盤ごとに個別のQoS制御や認証が必要になり、ネットワーク全体の管理が煩雑になっているのが現状です。

そこで、MECアプリケーションを仮想的なUE（vUE）上で動作するアプリケーションとして扱い、5GCのC-Planeを活用するアーキテクチャーを提案します。図2にアーキテクチャーの概要を示します。
このアーキテクチャーではUEアプリケーションもMECアプリケーションも同じ仕組みでサービスポリシーを適用できるようになり、ネットワーク全体で一貫したポリシー管理が可能になります。

図2. 提案する新たなアーキテクチャーの概要

MECアプリケーションを5GCで管理する仕組み

MECアプリケーションを5GCの管理下にするには、いくつかのステップが必要です。

1）MECアプリにIMSIを割り当てる

まず、サービス事業者が提供するMECアプリケーションを5GCの下で管理できるようにするために、MECアプリケーションごとにIMSI（国際移動体加入者識別番号）を発行します。IMSIは本来UEを識別するためのものですが、MECアプリケーション（≒vUE）にもこれを持たせることで、5GCのポリシーを適用することができます。これは、みなさんが通信事業者との間で通信サービスの内容（ポリシー）を確認して契約し、SIMカードを発行してもらう（≒IMSIを発行してもらう）行為と類似しています。IMSIは、UDR（統合データリポジトリ）に登録され、QoSやセキュリティーポリシーが自動的に適用される仕組みになっています。これにより、MECアプリケーションは従来のUEアプリケーションと同じ形でポリシー管理ができるようになります。

2）MEC基盤内に仮想gNB（vgNB）を展開

MECアプリケーションが5GCとやりとりするために、MEC基盤内に仮想gNB（vgNB）を設置します。vgNBは、MECアプリケーション（≒vUE）からの通信を5GCに転送し、通常のUEと同じように5GCのC-Planeに登録される仕組みになっています。現状、vgNBは現在の5GCとの互換性を保つためにのみ存在します。

3）MECアプリケーションの登録と回線確立

MECアプリが起動すると、5GCに対してRegistration（登録）を実施し、ネットワークに参加します。その後、PDU Session Establishment（PDUセッション確立）を行い、通信が可能な状態になります。これにより、MECアプリケーションは契約したポリシーの内容に従って通信の可否が制御されます。

4）5GCによるポリシー適用

MECアプリケーションが5GCに登録されると、QoSや帯域、セキュリティーポリシーが適用されます。これは、5GCのC-Planeを通じてPCF（ポリシー制御機能）がポリシーを決定し、SMF（セッション管理機能）を介して適用される仕組みです。
MECアプリケーションの通信もUEアプリケーションと同じ仕組みの下で管理され、MECサービスを構成する通信に対してネットワーク全体で一貫したポリシー適用が可能になります。

4. MECアプリケーションを5GCの制御下にするメリット

従来は5GCとMECのそれぞれでポリシー管理をし、それらを密に連動させる必要がありました。MECアプリケーションが5GCのC-Planeの管理下に入ることで、MECごとに異なるポリシー制御機構を運用する必要がなくなり、通信事業者の運用負担が軽減されます。
また、アプリケーション開発者やサービス事業者にとっても大きなメリットがあります。従来のMECアプリケーション開発では、5GCのポリシーを適用するために個別の設定やAPIの実装が必要で、モバイルネットワークのコアの仕組みを理解することが求められていました。一方、提案する仕組みでは、例えばKubernetesのマニフェストファイルに、図3に示すような形式でIMSIをラベルに指定するだけで、契約時に設定したポリシーが自動的に適用されます。

図3. MECアプリケーションのマニフェストの例（提案手法）

この仕組みを使えば、アプリケーションをKubernetesにデプロイするときと同じ作法で、5GCのポリシーをアプリケーションに適用できます。通信やネットワークに関する専門知識がなくても、適切なQoS制御やセキュリティー管理を容易に適用できるようになり、アプリケーションの設計や運用の手間が大きく軽減されると考えられます。

キャリアの伝送網（TN：Transport Network）には、あらかじめ顧客やサービス特性などの単位で分離されたネットワークが展開されていることがしばしばあります。これを5GCが扱うネットワークスライスに対応させるようにコンフィグレーションすることで、UEアプリケーションとMECアプリケーションが同じネットワークスライスにN6インターフェイスで接続することができます。端末とMECサービスが同じポリシーに属する契約を交わすことで、5GC による一貫したポリシーを自動的に MEC サービスに適用することができるようになります。

PoCによる検証

今回は、5GCとしてfree5GCを、gNBおよびvgNBとしてUERANSIMを、UEおよびvUEとしてUERAMSIM UEを、それぞれ仮想マシン（VM: Virtual Machine）上に展開してPoC（Proof-of-Concept）の検証環境を構築しました（図4）。MEC基盤には k8s (Kubernetes)を採用しました。

図4. PoCの検証環境

UE1とUE2は、それぞれポリシーAとポリシーBに加入しています。2台のUEは、VM3上のgNBを経由してVM1上の 5GC C-plane との間で登録と回線確立を済ませます。これにより、2台のUEはVM4上のUPFを経由してDNと通信できるようになります。

MEC アプリケーションは、ポリシーBに加入しています。図3に示すようなマニフェストを受け取ったk8sは、CNI（Container Network Interface）プラグインとして実装した vUE を起動します。vUEはvgNBを経由してVM1上の5GC C-plane との間で先述の手順を実施し、登録と回線確立を済ませます。これにより、MECアプリケーションのPod が vgNBとVM6上のUPFを経由してDNと通信できるようになります。

このとき、UE2とvUE（≒MECアプリケーション）は同じポリシーBに加入しているためDNを介して通信可能であり、UE2はMECサービスが利用可能な状態を実現しました。一方、UE1とvUEは同じポリシーに加入していないため通信不可能であり、UE1はMECサービスが利用できない状態を実現しました。これは、MECアプリケーションを5GCの制御下に置くことで、MECサービスにおいて重要なサービスポリシーの制御が可能であることを簡易的に示したことになります。

5. MECサービスの展望

UEアプリケーションと同様にMECアプリケーションも5GCの制御下でポリシーを適用することで、ポリシー制御機構が簡素化され、サービス事業者とキャリアオペレーターの両者に恩恵があることを示しました。今回、PoC環境での実装と動作確認をし、基本的な要件を満たしていることを確認しました。本内容は、電子情報通信学会ネットワークシステム研究会にて発表されました^[1]。
今後は、加入者情報（IMSI）だけでなく、ユーザーのエリア情報（TA：Tracking Area）に応じてアプリ利用を制御するといった、具体的なポリシーの実現に取り組みます。これにより、特定エリアでのアプリ提供や利用制限に柔軟に対応できます。また、5GCからのポリシー制御がアプリケーションに与える影響や、ネットワークの運用効率性を確認する予定です。
これらを通じて、通信事業者ならではのMECサービスをより簡単に構築可能になる世界を目指します。今後の多様なサービス要求に対応するため、MECとモバイルシステムが親和したアーキテクチャーの実現に向けて、今後も検証と改善を続けます。

参考文献

• [1]. “5GCによるアプリケーションサービスポリシー管理に対応したMECアーキテクチャ”, 石原 匠, 渡邊 大記, 堀場 勝広, 植原 啓介, 信学技報, vol. 124, no. 310, NS2024-158, pp. 86-91, 2024年12月.

執筆者

渡邊 大記、石原 匠