第 3 章 5G コアのクラウドネイティブアーキテクチャ
5G 時代には、通信事業者はサービスの迅速化、高度化、多様化が求められる一方、加入者に投資コストを転嫁することは厳しく制限されます。そのため、無線ネットワークだけではなく、サービス提供の柔軟性にかかわる 5G パケット コアにも斬新なアーキテクチャが求められます。
2018 年以降実装された 5G トライアルと商用ネットワークのパケットコアは、基本的には 4G EPC をベースとした 5G NSA（ノンスタンドアロン）の実装です。
本章では、5G SA（スタンドアロン）パケットコアの 3GPP の標準化における定義を解説します。また、それを実現するためにクラウドネイティブアーキテクチャを追求したシスコ 5G SA パケットコア製品のアプローチと、そのアーキテクチャの応用および汎用化について考察します。
3.1. 5G パケットコアの 3GPP の標準化定義
2G/3G/4G と進化してきたパケットコア ネットワークには、次のような課題があります。
- Control Plane（CP）と User Plane（UP）の完全分離がされていない。3GPP の Release14 で Control/User Plane Separation （CUPS: CU分離）の取り組みがありましたが、幅広く実装されていません。このようなモノリシック的なパケットコアのアーキテクチャでは、5G に期待されている高速大容量、超低遅延、多数同時接続などのユース ケースで必要とされる UP の柔軟な配置や、新サービスの迅速な立ち上げに求められる高度な自動化、CP/UP のそれぞれ独立したスケールアウトなどを実現することは不可能です。
- 障害時の復旧、新サービスの導入が困難。パケット コア内のネットワーク機能（NF) 間では、 1 対 1 のインターフェイス（Diameter、GTP-C）とコールフローが定義され、それぞれの NF が個別に複雑なステートを持っているため、新機能や NF の追加/変更の際に慎重な設計とテストが必要です。このため、スケールアウトや障害時の復旧、新サービスの導入に非常に時間を要します。
- アクセス ネットワークへの依存性。現在のパケット コア ネットワークは、アクセス ネットワークに依存する部分が多く、非 3GPP アクセス（WiFi 等）への対応に大きな変更が必要になります。将来、衛星回線や固定ブロードバンドなど多様なアクセスの取り組みも視野に入れている 5G においては、アクセス非依存のアーキテクチャにする必要があります。
- ネットワーク スライシングへの対応。5G が多様なサービスを共通の基盤で実現するためには、パケット コアにもネットワーク スライシングの実現が必要です。しかし、4G EPC がモノリシックかつ密結合の構造であるため、自動化や、効率的で柔軟なスライシングの実現が非常に困難です。
以上の課題から、5G で要求される高速大容量、超高信頼・低遅延、多数同時接続などの多様なユース ケースを効率的なネットワーク スライスにより自動化プロセスで実現するためには、より柔軟なパケットコア ネットワークを持つアーキテクチャが求められています。
2018 年 6 月に完成し、「5G Phase 1」と位置づけられた 3GPP Release 15 から、 5GC（5G コアネットワーク）の主な特徴を次に規定しています[1][2][3]：
― CU の完全分離
― クラウド化と Service Based Architecture （SBA：サービス ベース アーキテクチャ）の導入
― ネットワーク スライスに対応するためのコア ネットワーク内の NF 機能分担を再定義
― アクセス非依存
図 3-1 3GPP における 4G と 5G コア ネットワークの違い
図 3-1 は 4G から 5G へのアーキテクチャの変化を示しています。SBA はコアの NF 機能をサービスとして捉え、インターフェイス（Service based Interface; SBI）を軽量な Web アプリケーション ベースに統一することで効率化を実現します。
従来のポイントツーポイントの Diameter や GTP-C 採用せず、 Web 世界で容易な自動化を実現できる HTTP2/JSON の RESTful API を採用しました。また、BUS 型のアーキテクチャを採用し、NF 間を互いに「サービス」としてリクエスト/レスポンス等の形で制御します。
3.2. クラウド ネイティブ アーキテクチャで実現するシスコの 5GC ソリューション
5G における迅速な新サービスの投入をコントロール可能なコストで実現するために、シスコは、5G コア ネットワークの実装に次の要素が必須と考えています：
― CUPS（CU分離）
― クラウド ネイティブ（CN）化: クラウド化と高度な自動化が可能な仮想化基盤
― CP（Control Plane）の SBA
― 仮想化環境の UP（User Plane）性能改善
― ネットワーク スライスの効率的な実現
― エッジ コンピューティングの実現
― 4G EPC から 5GC へのシームレスな移行と共存
上記の要素を順に見ていきましょう。
3.2.1. CUPS （CU分離）
シスコは 、CUPS を 4G EPC から実装しており、5GC の CU 分離の基礎になりました（図 3-2）。
図 3-2 CUPS（Control/User Plane Separation）
CUPS の実装には次のメリットがあります。
― ユーザ機器において数～数十 Gbps のスループットを実現
― 処理能力拡張や保守運用作業を CP と UP で独立に行える
― CP を DC に集約したオペレーションが可能
― UP を VoLTE や IoT などのユース ケースごとに分離可能
― UP の物理的な配置が柔軟にでき、Remote CUPS による低遅延の MEC ユース ケースに対応可能
― 障害時の切り離しが容易（UP 障害時も CP はサービス継続可能）
3.2.2. クラウド ネイティブ : クラウド化と高度な自動化が可能な仮想化基盤
数年前に、European Telecommunications Standards Institute（ETSI; 欧州電気通信標準化機構）の Management and Orchestration（MANO）Network Function Virtualization （NFV; ネットワーク仮想化）フレームワークが制定されて以来、パケット コアの NFV 化が進んでいます。しかし、多くの仮想化実装は、交換機時代の設計を踏襲し、元の機能を Virtual Network Function （VNF; 仮想化ネットワーク機能）で再ポーティングする仮想化アプライアンス化にとどまっているのが実情です。
本来 NFV で実現したいインフラとの分離、機能間の疎結合化、運用の完全自動化は、必ずしも実現できていません。逆に、仮想化基盤の導入と頻繁な変更への対応に多くの時間とコストがかかってしまうケースも見られます。
こうした経験を踏まえ、業界と多くのお客様が次に必要と考えているのが、クラウド ネイティブのアーキテクチャです。
シスコは、クラウド ネイティブのアーキテクチャを実現するために、4 つの重要な要素があると考えています（図 3-3）[4]。
図 3-3 シスコが考えるクラウド ネイティブの 4 要素
- Microservices（マイクロサービス）
― モジュラー、疎結合のソフトウェア サービス
― 個々にデプロイ可能で、それぞれライフサイクルの管理が可能
― ステートフルとステートレス アプリケーションの分離
- Containers（コンテナ）
― マイクロサービスの仮想化と管理
― マルチ環境への非常に高いポータビリティ
- Continuous Delivery（継続デリバリ）
― 自動的に CI/CD（Continuous Integration/Continuous Deployment）
― Canary In-Service アップグレードを可能
- DevOps
― 迅速なデプロイの自動化管理
― 検証環境と商用環境のギャップをできるだけ縮小し、商用への導入をスムーズにする
シスコのクラウド ネイティブ対応アーキテクチャは、今まで取り込んだ仮想化基盤（CVIM: Cisco Virtual Infrastructure Managaement）の経験を踏まえて進化してきました（図 3-4）。CVIM が 5GC のみのためではなく、より汎用的な仮想基盤を目指しています。
図 3-4 CVIM 仮想化基盤のクラウド ネイティブへの進化
シスコは 5GC を実装するにあたり、クラウド ネイティブ時代の初期段階でお客様が導入しやすいよう、より統合され、かつオープンなアーキテクチャを取ることが重要と考え、SMI（Subscriber Microservice Infrastructure）を 5GC の共通クラウド ネイティブサービスインフラとして開発しています。このアーキテクチャの実現には、業界のオープンソースを含めたさまざまなエコシステムと Web スケールの技術の取り入れが重要です。
シスコは、業界に幅広く採用されている Docker コンテナと自動化ツールの Kubernetes を採用し、CN プラットフォームの柱として、アプリケーションの自動化ライフサイクル管理を実現しています。図 3-5 にそのアーキテクチャを示しています。
- Infrastructure as a Service: VM、プライベート クラウド、パブリック クラウド、またはエッジ クラウドにも対応可能、将来ベアメタルへ移行
- Docker、Kubernetes、Istio 等が Service Mesh でアプリケーションのライフサイクル自動化を管理
- VPP（FD.io）、Contiv、また将来NSM（Network Service Mesh）で高度化コンテナ ネットワークを実現
- アプリケーションのマイクロサービス化
- 共通サービスインフラ（SMI: Subscriber Microservice Infrastructure）: アプリケーション間で共通な初期化、デプロイ、監視と可視化、パッケージ管理、memif、ステート データベースなどを効率的に管理
- 上位レイヤへの API 提供
図 3-5 シスコのクラウド ネイティブ 5GC アーキテクチャ
次回は、このクラウド ネイティブ のアーキテクチャの他の要素と、その上に実装されるシスコ 5GC を解説します。その他のサービスへの応用についても触れる予定です。
参考文献
[1] 3GPP TS 23.501 – System Architecture for the 5G System; Stage 2
[2] 3GPP TS 23.502 – Procedures for the 5G System; Stage 2
[3] NTT Docomo Technical Journal – Vol25_3_003jp
[4] Cisco: Evolving the Mobile Core to Being Cloud Native White Paper
用語集
SBA : Service based Architecture
CUPS: Control-User Plane Seperation
CP: Control Plance
UP: User Plane
EPC: Evolved Packet Core
5GC: 5G Core Network
CN: Cloud Native
SMI: Cisco Subscriber Microservice Infrastructure
CVIM: Cisco Virtual Infrastructure Management
CCP-SP: Cisco Container Platform for SP
Authors