Amazon Elastic Kubernetes Service 上でのオープンソースモバイルコアネットワークの実装

本投稿は Open source mobile core network implementation on Amazon Elastic Kubernetes Service を翻訳したものです。

アマゾンウェブサービス (AWS) のホワイトペーパー『 AWS でのキャリアグレードのモバイルパケットコアネットワーク』および『AWS を使用した 5G ネットワークの進化』で紹介されているように、AWS で 4G Evolved Packet Core(EPC) および 5G Core(5GC) を実装することで、スケーラビリティ、柔軟性、プログラム可能なオーケストレーション、基盤となるインフラストラクチャレイヤーの自動化などの大きな価値とメリットを得ることができます。

このブログ投稿では、オープンソースプロジェクト Open5gs を使用して 4G コアネットワークを構築するための実用的な実装ステップに焦点を当てます。

簡単な手順でインストールできるメリットを紹介するだけでなく、モバイルパケットネットワークがクラウド環境で効率的に動作するのに役立つ以下のAWS サービスも紹介します。 Amazon Elastic Kubernetes Service (Amazon EKS)、 Amazon Route 53 （DNS サービス）、 Amazon DocumentDB、 Amazon Elastic Container Registry (Amazon ECR)、 AWS CloudFormation、 Amazon CloudWatch、 AWS Lambda。

今回紹介するオープンソースベースの 4G コアネットワークの実装例は汎用化されているため、モバイルネットワーク機能の開発者にとって参考になるだけでなく、AWS で実行されるモバイルパケットコアネットワークの一般的な例を必要としている、オーケストレーション、サービスアシュランス、運用サポートシステム (OSS) ソリューションの開発者にとっても適切なツールとなることでしょう。

読了推定時間	約 10~15 分
所要時間	約 45~60 分
完了するためのコスト（見積もり）	489 USD（1 か月あたりのオンデマンドインスタンスのコストを基に算出）
学習レベル	上級 (300)
使用するサービス	AWS CloudFormation、Amazon Elastic Kubernetes Service、Amazon DocumentDB、AWS Lambda、Amazon CloudWatch

ソリューションの概要

今回の実装例では、サンプルとなるモバイルパケットコアアプリケーションとして Open5gs を選択しました。Open5gs は、GNU AGPL 3.0 ライセンスの下、プライベート LTE/5G ネットワークを構築するためのオープンソースプロジェクトであり、4G および 5G モバイルパケットコアネットワーク機能を提供します。現在、 3GPP リリース 16 をサポートしており、5G コア（AMF、SMF+PGW-c、UPF+PGW-u、PCF、UDR、UDM、AUSF、NRF）ネットワーク機能および EPC（MME、SGW-c、SGW-u、HSS、PCRF）ネットワーク機能を提供します。

Open5gs のコンポーネントの中から、以下の表のネットワーク機能アプリケーションを 4G EPC ネットワークのデモ目的に使用します。また、図にあるように 3GPP 論理インターフェイスを持ちます。Network Repository Function (NRF) は 5G のみのネットワーク機能であることに注意してください。NRF は、SMF および UPF を使用するために導入された機能ですが、Open5gs プロジェクトにおいては PGW-c および PGW-u として機能します。

ネットワーク機能	役割
MME	モビリティ管理エンティティ
HSS	加入者管理データベース
PCRF	ポリシーおよび課金ルール機能
SGW-c	SGW コントロールプレーン
SGW-u	SGW ユーザープレーン
SMF+PGW-c	セッション管理機能 + PGW-c
UPF+PGW-u	ユーザープレーン機能 + PGW-u
NRF	ネットワークリポジトリ機能（全 5G 機能(NF)の登録にのみ使用）
Web-UI	HSS/PCRF の加入者とそのプロファイルを設定するための GUI

Kubernetes (K8s) でコンテナベースのネットワーク機能を使用する場合、次の図のように、通常、これらのネットワーク機能のデプロイプロセスを、 VPC 作成→EKS クラスターとワーカーノードの作成→Helm のデプロイ→CNF 設定、のフローで標準化できます。これは、さまざまな自動化ツールやシナリオを使って自動化できます。

今回の例では、CloudFormation を使用して Amazon Virtual Private Cloud (VPC)、Amazon EKS クラスター、および 2 つのワーカーノードグループ（1 つは 3GPP コントロールプレーン用、もう 1 つは 3GPP ユーザープレーン用）を作成します。重要な点として、このようなオープンソースの EPC/5GC を EKS にデプロイする場合、Multus CNI プラグインを利用する必要があります。理由としては、ネットワーク分離をしながら、複数のネットワークインターフェイスを使用して、各インターフェイスで異なるプロトコルに対応するためです。AWS GitHubで説明されているように、AWS Lambda 関数と Amazon CloudWatch イベントルールを使用してこのプロセスを自動化できます。主なポイントとしては、2 つの AWS CloudFormation テンプレートを使って以下のリソースを作成します。

インフラストラクチャ作成テンプレート
- EpcVpc: デプロイに使用する VPC。
- PublicSubnet1/2: これらのサブネットでは、 kubectl コマンドの run を実行するための、パブリックインターネットアクセスを持つ踏み台ホストをホスティングします。また、NAT-GW をホスティングし、プライベートサブネットにインターネットアクセスを提供します。
- PrivateSubnetAz1/2: AZ1 および AZ2 における EKS コントロールプレーン用サブネット。
- MultusSubnet1Az1: Multus が EPC コントロールプレーンポッドにセカンダリインターフェイスを作成するために使用する、１番目のサブネット。
- MultusSubnet2Az1: Multus が EPC ユーザープレーンポッドにセカンダリインターフェイスを作成するために使用する、 2 番目のサブネット。
- EksCluster: ネットワーク機能をホスティングする EKS クラスター。
- DocumentDBCluster: 加入者プロファイルストア用。Open5gs は元々 HSS および PCRF 用に MongoDB を使用しますが、Amazon DocumentDB は MongoDB と完全互換なため、今回の実装では Amazon DocumentDB を使用します。
- Route53 Private Hosted Zones: Route53 プライベートホストゾーン: S6a、Gx、S11、S5-c/u IP アドレスなどのサービスインターフェイスを検出するために、Amazon Route 53 を単一の中央 DNS として使用します。
EKS ワーカーノードグループ作成テンプレート
- MME、SGW-c、SMF などのコントロールプレーンネットワーク機能用のワーカーノードグループ。追加のコントロールプレーンサブネットのネットワークを持ちます。
- SGW-u や UPF などのユーザープレーンネットワーク機能用のワーカーノードグループ。追加のコントロールプレーンサブネットとユーザープレーンサブネットのネットワークを持ちます。
- ワーカーノードグループに追加の Multus サブネットネットワークをアタッチするための Lambda 関数。
- CloudWatch イベントルールを使い、インスタンスのスケールアップとスケールダウンをモニタリングして Lambda フックをトリガーし、ワーカーノードグループに追加の Multus ネットワークをアタッチします。

また、自動化をさらに進めるために、追加で 2 つのコントローラーを開発・導入しました。

DNS 更新コントローラー: Multus インターフェイスに付与されたサービス IP の解決には Amazon Route 53 を使用しますが、それに加えてサービス IP を各 Route 53 プライベートホストゾーンに自動的に登録するためのコントローラーも作成しました。各 EPC サービスインターフェイスは、open5gs-infra CFN テンプレートによって作成された個別の DNS プライベートホストゾーンを使用します。
Multus IP 更新コントローラー: こちらのもう 1 つのコントローラーは、ポッドが実行されている EC2 インスタンスに Multus のセカンダリ IP を関連付けるために使用されます。このコントローラーは、指定されたアノテーションを持つポッドをリッスンし、セカンダリ IP を検索し、Amazon EC2 API を呼び出して、ポッドの Multus インターフェイスの IP をホストインスタンスのそれぞれの ENI に関連付けます。また、ポッドが削除されると、ホスト ENI から IP の関連付けが解除されます。

Open5gs のデプロイが成功すると、4G コアネットワークの機能を他のテスターやシミュレータでテストできるようになります。この記事では、 srsLTE Simulator を例として使用していますが、ユーザーの好みに応じて選択できます。

手順の概要

インストール手順の概要 :

インフラストラクチャを作成するため、 CloudFormation (open5gs-infra.yaml) を実行します。
踏み台ホスト設定と K8s ConfigMap の更新。
DocumentDB の初期化。
CoreDNS ConfigMap を更新し、3GPP サービスインターフェイス用に Route 53 を使用します。
Multus ワーカーノードグループ作成用の CloudFormation (open5gs-worker.yaml) を実行します。
自動化用の DNS コントローラーと Multus-IP 更新コントローラーのデプロイ。
クラスターを初期化（名前空間の設定など）するためにシェルスクリプトを実行します。
すべてのネットワーク機能を使うため Helm をインストール。

1から8までの手順全体を通じて GitHub リポジトリを参照してください。

前提条件

上記手順を実行するにあたり、以下の前提条件を満たしている必要があります。

1つの AWS アカウント。
イメージをビルドするために GitHub リポジトリをローカルマシンにダウンロードする。
Open5gs と DNS/Multus-IP コントローラーの Docker イメージをコンパイルし、ご自身の ECR にアップロードする必要があります。
- コンテナイメージ : アプリケーションコンポーネント用の Docker ファイルは、GitHub リポジトリの各プロセッサアーキテクチャ（ARM-Architecture フォルダと x86-Architecture フォルダ）の GitHub リポジトリの Dockerfiles サブフォルダにあります。特に、ARM ベースのファイルは AWS Graviton2 インスタンスで使用できます。これにより、最高のコストパフォーマンスを実現できます。
- Open5gs のバージョン 2.0.22 をコンテナを使用してデプロイしたときに不具合が発生するため、Open5gs コンポーネント用の Dockerfiles は master ブランチから作成しています。使用したコミットは 41fd851 です。または、v2.0.22 よりも新しいバージョンを使用することもできます。
CloudFormation、VPC、EKS などの AWS サービスの基本的な理解。
今回の例で使用される EKS や DocumentDB などの一部のサービスにはサービス利用料金が発生する点にご注意ください。

詳細な実装手順

基本的な手順や詳しい情報については、サービスドキュメントのトピックを参照してください。

インフラストラクチャ作成のために CloudFormation を実行する (open5gs-infra.yaml)

AWS コンソールにログインし、CloudFormation サービスに移動します。
インフラストラクチャテンプレートを実行します。

踏み台ホスト設定と K8s ConfigMap の更新

ユーザーガイドの説明に従い Kubectl をインストールします。
Helm バージョン 3 のインストールも必要です。
ユーザーガイドの説明に従いインスタンスの AWS 認証情報を設定します。
踏み台の kubeconfig を更新して、作成した EKS クラスターと通信できるようにします。
```
aws eks update-kubeconfig --name eks-Open5gsInfra
```

ConfigMap の更新を実行して、Lambda SAR アプリケーションがワーカーノードグループの自動 Join 用に動作できるようにします。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: /**ARN of EKSAdminRoleForLambda (can be found in Output of infra stack)**/
username: ops-user
groups:
- system:masters
EOF

リポジトリの Git クローンを保存しておくと、後でこの踏み台ホストで Helm のインストールを実行するときに役立ちます。

DocumentDB の初期化

AWS コンソールにログインし、DocumentDB サービスに移動します。
DocumentDB クラスターは、Open5gs で使用する前に初期化する必要があります。これを行うには、クラスター内に「open5gs」データベースを作成します。このデータベースの作成は、踏み台ホストを介して実行できます。Mongo クライアントのインストール方法の詳細については、ドキュメントを参照してください。データベースを作成するには、基本ガイドを参照してください。

CoreDNS ConfigMapを更新し3GPP サービスインターフェイス用に Route 53 を使用

CloudFormation テンプレートが作成した Route 53 ゾーンを使うようにクラスターの coreDNS ConfigMap を更新します。以下は、追加する必要があるサンプルエントリです（ゾーン ID はご自身のものに置き換えてください）。Route 53 設定を有効にするには、coreDNS ポッドを再起動する必要があります。

    s6a.hss.open5gs.service {
        route53 s6a.hss.open5gs.service.:Z04391521Q1O3218R9ICQ
    }
    
    s6a.mme.open5gs.service {
        route53 s6a.mme.open5gs.service.:Z021624132KA5KGP80CIJ
    }
    
    gx.pcrf.open5gs.service {
        route53 gx.pcrf.open5gs.service.:Z001178610405PSM3LXE2
    }
    
    s11.sgwc.open5gs.service {
        route53 s11.sgwc.open5gs.service.:Z0012154326705JM1A2HA
    }
    
    sx.sgwu.open5gs.service {
        route53 sx.sgwu.open5gs.service.:Z02156012ZREZXLVAQGCF
    }
    
    s5.smf.open5gs.service {
        route53 s5.smf.open5gs.service.:Z021666966S8THLJAKYF
    }
    
    sx.upf.open5gs.service {
        route53 sx.upf.open5gs.service.:Z04729463PFYEQGVMLX4R
    }

ワーカーノードグループ作成用の CloudFormation (open5gs-worker.yaml) を実行する

AWS コンソールにログインし、CloudFormation サービスに移動します。
ワーカーノードグループテンプレートを実行します。この時点において、インフラストラクチャの作成に使用したスタック名を指定し、適切に参照できるようにする必要があります。
オプション : ワーカーノードグループが EKS クラスターに自動的に Join しない場合は、EKS クラスターコントロールプレーンがワーカーノードを登録できるように、aws-auth ConfigMap を手動で更新してください。（踏み台ホスト設定 – 4 のステップが適切に行われた場合、このステップは通常必要ありません。）

ステージング環境の整備

前提条件のステップで完了したコントローラーイメージの ECR リポジトリを指し示すように controllers/deployments/aws-secondary-int-controller-deployment.yaml、controllers/deployments/svc-watcher-route53-deployment.yaml ファイルを編集します。
./cluster_initializer.sh を実行（リポジトリのルートフォルダで実行する必要があります）し、Open5gs 名前空間、Multus-daemonset、Multus ネットワーク接続定義、サービス検出、セカンダリインターフェイスコントローラーなど、事前に必要な Kubernetes リソースをインストールします。サービス検出とセカンダリインターフェイスコントローラーは、kube-system 名前空間にインストールされます。Helm チャートから Open5gs をインストールする前に、このスクリプトを実行する必要があります。
CloudWatch Container Insight をインストールして、コンテナのモニタリングとログ収集を行います。インストールの詳細については、セットアップガイドを参照してください。

Helm のデプロイ

values.yaml を開き、イメージリポジトリが ECR イメージを指し示すよう編集します（open5gs.image.repository、open5gs.image.tag、webui.image.repository、webui.image.tag）。
次のコマンドを使用して Helm チャートをインストールします。
```
helm -n open5gs install -f values.yaml epc-core ./
```

すべてのポッドが実行状態になるまで待ちます。これには約 5~10 分かかります。この間、一部のポッドはRoute 53 および IP の更新中に複数回再起動されますが、これは想定通りの動作となります。

>> kubectl get -n open5gs pods
NAME                                       READY   STATUS    RESTARTS   AGE
open5gs-hss-deployment-54f7b8b47f-rpvvv    1/1     Running   3          5m23s
open5gs-mme-deployment-657bdc78fc-hstkb    1/1     Running   3          5m24s
open5gs-nrf-deployment-b5d6b7755-cc275     1/1     Running   0          5m23s
open5gs-pcrf-deployment-f9bc9b648-jhktg    1/1     Running   3          5m24s
open5gs-sgwc-deployment-7f4d4b7f86-xcvw5   1/1     Running   0          5m23s
open5gs-sgwu-deployment-59656b6b8-z2ht9    1/1     Running   0          5m23s
open5gs-smf-deployment-74659f5849-jnr7z    1/1     Running   3          5m25s
open5gs-upf-deployment-5f9f944b49-zcq5l    1/1     Running   0          5m24s
open5gs-webui-6679c7c99f-vhkw6             1/1     Running   0          5m25s

>> kubectl logs -n open5gs open5gs-mme-deployment-657bdc78fc-hstkb
Open5GS daemon v2.1.1-5-gefd1780

01/07 08:04:52.849: [app] INFO: Configuration: '/open5gs/config-map/mme.yaml' (../lib/app/ogs-init.c:129)

セットアップ全体の検証

オープンソースまたは AWS パートナーの用意する任意の LTE UE/eNB エミュレータを使うことで環境をテストできます。
srsLTE を使用する場合は、EKS 上に作成された EPC コアネットワークで以下の結果を確認できます。（シミュレーターの設定は、EKS のコアネットワークに設定された加入者プロファイル（IMSI、OPc、Kval）、MCC、MNC、APN の設定と一致している必要があります。）

クリーンアップ

継続して課金されることを防ぐため、CloudFormation サービスを使用して作成されたすべてのリソースを削除してください。AWS コンソールから CloudFormation サービスに戻り、スタックを1 つずつ削除してください（順番としては、ワーカーノードスタック削除後にインフラストラクチャスタックを削除してください）。

まとめ

このブログ投稿では、ハードウェアや追加のデータベース、基盤となるインフラストラクチャを用意することなく簡単に環境を設定する方法を説明することで、モバイルパケットコアネットワークを実装するためにAWSを使用するメリットとその機能を示しました。この標準化されたプロセスは、 AWS Cloud Development Kit (AWS CDK) と AWS CodePipeline を使用するか、あるいはサードパーティ製のツールやオーケストレーターを使用して API 統合を実装することで、さらに自動化を進めることも可能です。

翻訳はソリューションアーキテクトの荒木靖宏とプログラムマネージャーの安田茂樹が担当しました。原文はこちらです。

Amazon Web Services ブログ