プライベート モバイル ネットワークの設計要件

この記事は、Azure Private 5G Core (AP5GC) に基づいてプライベート 4G または 5G ネットワークを実装するための設計と準備に役立ちます。 これらのネットワークの構築方法と、ネットワークの計画時に行う必要がある決定について理解することを目的としています。

Azure Private MEC と Azure Private 5G Core

Azure プライベート マルチアクセス エッジ コンピューティング (MEC) は、Microsoft のコンピューティング、ネットワーク、アプリケーション サービスを組み合わせて、エンタープライズ プレミス (エッジ) でデプロイするソリューションです。 これらのエッジ デプロイは、クラウドから一元的に管理します。 Azure Private 5G Core は Azure プライベート マルチアクセス エッジ コンピューティング (MEC) 内の Azure サービスであり、エンタープライズ エッジの 4G および 5G コア ネットワーク機能が提供されます。 エンタープライズ エッジ サイトで、デバイスはセルラー無線アクセス ネットワーク (RAN) を介して接続され、Azure Private 5G Core サービスを介してアップストリーム ネットワーク、アプリケーション、リソースに接続されます。 必要に応じて、デバイスで Azure Private MEC から提供されるローカル コンピューティング使用を利用して、すべて企業の管理下で非常に低遅延でデータ ストリームを処理できる場合があります。

プライベート モバイル ネットワークの要件

ユーザー機器 (UE) からプライベート セルラー ネットワークに接続できるようにするには、次の機能が存在する必要があります。

• UE は、無線アクセス ネットワーク (RAN) で使用されるプロトコルとワイヤレス スペクトル帯域と互換性がある必要があります。
• UE がサブスクライバー ID モジュール (SIM) を搭載している必要があります。 SIM は、デバイスの ID を格納する暗号要素です。
• エンタープライズ サイト内でサービスを必要とする UE が含まれるすべての部分に対して、セルラー信号の送受信を行う RAN が必要です。
• RAN およびアップストリーム ネットワークに接続されるパケット コア インスタンスが必要です。 パケット コアは、UE の SIM が RAN 経由で接続し、ネットワークからサービスを要求する際に認証する役割を担います。 たとえば、サービスの品質を設定するために、UE との間で生成されるデータ フローにポリシーを適用します。
• RAN、パケット コア、アップストリーム ネットワーク インフラストラクチャは、IP トラフィックを相互に渡すことができるようにイーサネット経由で接続する必要があります。
• パケット コアをホストするサイトでは、サービス管理、テレメトリ、診断、アップグレードを可能にするために、インターネットへの継続的な高速接続 (最低 100 Mbps) が必要です。

プライベート モバイル ネットワークを設計する

以降のセクションで、考慮が必要なネットワークの要素と、ネットワークのデプロイに備えて行う必要がある設計上の決定について説明します。

トポロジ

ローカル ネットワークの設計と実装は、AP5GC デプロイの基本部分です。 AP5GC パケット コアやその他のエッジ ワークロードをサポートするためのネットワーク設計の決定を行う必要があります。 このセクションでは、ネットワークを設計する際に考慮すべきいくつかの決定事項について説明し、いくつかのサンプル ネットワーク トポロジを提供します。 次の図は、基本的なネットワーク トポロジを示しています。

設計上の考慮事項

パケット コアでネットワーク アドレス変換 (NAT) が有効になっていない限り、ローカル レイヤー 3 ネットワーク デバイスは、対応するアタッチされたデータ ネットワークの適切な N6 IP アドレスを介して UE IP プールへの静的ルートを構成する必要があります。

ネットワーク トポロジの例

サブネットと IP アドレス

エンタープライズ サイトに既存の IP ネットワークがあり、プライベート セルラー ネットワークがそれと統合する必要が生じる場合があります。 これは、たとえば、次のようなことを意味します。

• AP5GC の IP サブネットと IP アドレスは、既存のサブネットと一致し、アドレスが競合しないものを選択する。
• IP ルーターを介すか、サブネットのプライベート RFC 1918 アドレス空間を使用して、新しいネットワークを分離する。
• UE をネットワークに接続するとき、UE によって特に使用できるように IP アドレス プールを割り当てる。
• ネットワーク アドレス ポート変換 (NAPT) を使用して、パケット コア自体、または境界ルーターなどのアップストリーム ネットワーク デバイスで使用する。
• 断片化を最小限に抑える最大転送単位 (MTU) を選択して、ネットワークのパフォーマンスを最適化する。

デプロイに使用される IPv4 サブネットを文書化し、ソリューション内の各要素に使用する IP アドレスと、接続時に UE に割り当てられる IP アドレスについて合意する必要があります。 トラフィックを許可するには、ルーターとファイアウォールをエンタープライズ サイトにデプロイ (または既存のものを構成) する必要があります。 また、ネットワーク内の NAPT または MTU の変更が必要な方法と場所にも同意し、関連するルーターまたはファイアウォールの構成を計画する必要があります。 詳細については、「プライベート モバイル ネットワークをデプロイするために前提となるタスクを完了する」を参照してください。

高可用性 (HA)

必要に応じて、Azure Stack Edge (ASE) デバイスのペアに高可用性 (HA) サービスとして Azure Private 5G Core をデプロイできます。 これには、ASE クラスターと次の間にゲートウェイ ルーター (厳密には、レイヤー 3 対応デバイス - ルーターまたは L3 スイッチ (ルーター/スイッチ ハイブリッド) のいずれか) が必要です。

• アクセス ネットワーク内の RAN 機器。
• データ ネットワーク。

詳細については、「プライベート モバイル ネットワークをデプロイするために前提となるタスクを完了する」を参照してください。

ネットワーク アクセス

プライベート 5G ネットワーク上の RAN と UE から到達可能なネットワークと資産に関する企業の規則を設計に反映する必要があります。 たとえば、ローカル ドメイン ネーム システム (DNS)、動的ホスト構成プロトコル (DHCP)、インターネット、Azure へのアクセスは許可するが、工場運転のローカル エリア ネットワーク (LAN) にはアクセスできないようにできます。 サイトに行かなくても問題をトラブルシューティングできるように、ネットワークへのリモート アクセスの手配が必要になる場合もあります。 また、管理のために、またはエンタープライズ サイト外の他のリソースやアプリケーションにアクセスするために、エンタープライズ サイトを Azure などのアップストリーム ネットワークに接続する方法も検討する必要があります。

どの IP サブネットとアドレスの相互通信を許可するかについて、エンタープライズ チームと合意する必要があります。 次に、この合意をローカル IP インフラストラクチャで実装するルーティング計画またはアクセス制御リスト (ACL) 構成を作成します。 また、仮想ローカル エリア ネットワーク (VLAN) を使用してレイヤー 2 の要素をパーティション分割し、接続されたポートを特定の VLAN に割り当てるようにスイッチ ファブリックを構成することもできます (たとえば、RAN アクセスに使用される Azure Stack Edge ポートをイーサネット スイッチに接続されている RAN ユニットと同じ VLAN に配置します)。 また、サポート担当者がソリューション内の各要素の管理インターフェイスにリモート接続できるようにする、仮想プライベート ネットワーク (VPN) などのアクセス機構を設定することについても企業と合意する必要があります。 管理とテレメトリのために、Azure Private 5G Core と Azure の間の IP リンクも必要です。

RAN コンプライアンス

エンタープライズ サイト全体で信号をブロードキャストするために使用する RAN は地域の規制に準拠している必要があります。 たとえば、これは次のようなことを意味します。

• RAN ユニットは、承認プロセスを完了し、国内または地域内の特定の周波数帯域で使用するための規制機関の承認を受けている。
• 特定の場所のスペクトルを使用して、たとえば、通信事業者や規制機関から、またはスペクトル アクセス システム (SAS) などの技術ソリューションを介して、RAN がブロードキャストするアクセス許可を得ている。
• サイト内の RAN ユニットは、高精度時間プロトコル (PTP) や GPS 位置情報サービスなど、高精度の計時ソースにアクセスできます。

RAN が承認されている国または地域と周波数帯域については、RAN パートナーに問い合わせてください。 ソリューションを提供する国および地域を網羅するために、場合により、複数の RAN パートナーを使用する必要があります。 RAN、UE、パケット コアはすべて標準プロトコルを使用して通信しますが、Microsoft では、エンタープライズ顧客でデプロイする前に、Azure Private 5G Core、UE、RAN の間で特定の 4G ロングターム エボリューション (LTE) または 5G スタンドアロン (SA) プロトコルの相互運用性テストを実行することをお勧めします。

RAN から、使用するように構成されている周波数帯域のすべての UE にパブリック ランド モバイル ネットワーク ID (PLMN ID) を転送します。 PLMN ID を定義し、スペクトルへのアクセスを確認する必要があります。 一部の国または地域では、国または地域の規制当局または大手通信事業者からスペクトルを取得する必要があります。 たとえば、バンド 48 Citizens Broadband Radio Service (CBRS) スペクトルを使用している場合は、RAN パートナーと協力してエンタープライズ サイトに Spectrum Access System (SAS) ドメイン プロキシをデプロイし、RAN から、ブロードキャストが承認されていることを継続的に確認できるようにする必要がある可能性があります。

最大転送単位 (MTU)

最大転送単位 (MTU) は IP リンクのプロパティであり、リンクの両端にあるインターフェイスで構成されます。 パケットがインターフェイスの構成済み MTU を超えると、送信前に IPv4 断片化を介して小さなパケットに分割され、宛先で再構成されます。 ただし、インターフェイスの構成済み MTU が、リンクのサポートされている MTU よりも大きい場合は、パケットが正しく転送されません。

IPv4 断片化によって引き起こされる転送の問題を回避するために、4G または 5G パケット コアから UE に対して、どの MTU を使用すべきか指示されます。 ただし、パケット コアによって通知される MTU が UE で常に尊重されるとは限りません。

UE からの IP パケットは RAN からトンネリングされ、カプセル化によるオーバーヘッドが加わります。 このため、UE の MTU 値は、転送の問題を回避するために、RAN とパケット コアの間で使用される MTU 値よりも小さくする必要があります。

通常、RAN は事前に 1500 MTU で構成されています。 パケット コアの既定の UE MTU は、カプセル化のオーバーヘッドを考慮し、1440 バイトです。 これらの値によって RAN 相互運用性が最大化されますが、特定の UE で既定の MTU が監視されず、IPv4 断片化が必要となりネットワークによって破棄される可能性のある大きなパケットが生成されるリスクがあります。 この問題の影響を受ける場合は、1560 以上の MTU を使用するように RAN を構成して、カプセル化のための十分なオーバーヘッドを許容し、標準の 1500 MTU を使用して UE での断片化を回避することを強くお勧めします。

パケット コアによって通知される UE MTU を変更することもできます。 MTU は、UE でサポートされている範囲内の値に設定し、RAN によって通知される MTU より 60 バイト少なく設定することをお勧めします。 以下の点に注意してください。

• データ ネットワーク (N6) は、UE MTU と一致するように自動的に更新されます。
• アクセス ネットワーク (N3) は、UE MTU に 60 を加えた値と一致するように自動的に更新されます。
• 1280 から 1930 バイトまでの値を構成できます。

パケット コアによって通知される UE MTU を変更するには、「パケット コア インスタンスを変更する」を参照してください。

信号受信可能範囲

UE は、サイトの任意の場所から RAN と通信できる必要があります。 つまり、サイト内を移動する UE (たとえば、屋内と屋外の間) をサポートするために、障害や機器を考慮することを含めて、信号が環境内で効果的に伝達する必要があります。

受信可能範囲が適切であることを確認するには、RAN パートナーおよび企業と共にサイト調査を実行する必要があります。 異なる環境での RAN ユニットの機能と制限 (1 つのユニットでサポートできる接続 UE の数など) を理解していることを確認してください。 UE がサイトを動き回る場合は、RAN が X2 (4G) または Xn (5G) ハンドオーバーをサポートしていることも確認する必要があります。これにより、UE が 2 つの RAN ユニットによって提供される受信可能範囲の間でシームレスに移行できるからです。 RAN で X2 (4G) または Xn (5G) がサポートされない場合、RAN では UE モビリティ用に S1 (4G) と N2 (5G) がサポートされる必要があります。 UE でこれらのハンドオーバー手法を使用して、プライベート エンタープライズ ネットワークと通信事業者から提供されるパブリック セルラー ネットワークとの間をローミングできないことに注意してください。

SIM

すべての UE で、サブスクライバー ID モジュール (SIM) 内にエンコードされている ID がネットワークに提示される必要があります。 SIM は、さまざまな物理フォーム ファクターと、ソフトウェアのみの形式 (eSIM) で使用できます。 SIM でエンコードされるデータは、RAN の構成と、Azure Private 5G Core 内のプロビジョニングされた ID データの構成と一致する必要があります。

UE と互換性があり、デプロイに使用する PLMN ID とキーを使ってプログラムされたファクターの SIM を取得します。 物理 SIM は、オープン マーケットで比較的低コストで広く入手できます。 eSIM を使用する場合は、セルラー ネットワークに接続する前に UE で自身を構成できるように、必要な eSIM 構成とプロビジョニング インフラストラクチャをデプロイする必要があります。 SIM パートナーから受け取るプロビジョニング データを使用して、Azure Private 5G Core で一致するエントリをプロビジョニングできます。 SIM データをセキュリティで保護する必要があるため、SIM のプロビジョニングに使用される暗号化キーは、一度設定すると読み取ることができません。そのため、Azure Private 5G Core でデータを再プロビジョニングする必要がある場合に備えて、それらを格納する方法を検討する必要があります。

オートメーションと統合

オートメーションやその他のプログラム手法を使用してエンタープライズ ネットワークを構築すると、時間を節約し、エラーを減らし、成果を向上させることができます。 これらの手法では、ネットワークの再構築が必要なサイト障害が発生した場合の復旧パスも提供されます。

"コードとしてのインフラストラクチャ" というプログラム手法をデプロイに採用することをお勧めします。 テンプレートまたは Azure REST API を使用して、プロジェクトの設計フェーズ中に収集した値を入力としてパラメーターを使用してデプロイを構築できます。 SIM データ、スイッチまたはルーターの構成、ネットワーク ポリシーなどのプロビジョニング情報をマシンが読み取り可能な形式で保存することで、障害が発生した場合は、最初に行ったのと同じ方法で構成を再適用できるようにする必要があります。 障害から復旧するもう 1 つのベスト プラクティスは、最初のユニットで障害が発生した場合に復旧時間を最小限に抑えるために、予備の Azure Stack Edge サーバーをデプロイすることです。その後、保存したテンプレートと入力を使用して、デプロイをすばやく再作成できます。 テンプレートを使用したネットワークのデプロイの詳細については、「クイックスタート: プライベート モバイル ネットワークとサイトをデプロイする - ARM テンプレート」を参照してください。

また、他の Azure 製品やサービスをプライベート エンタープライズ ネットワークと統合する方法も検討する必要があります。 これらの製品には、Microsoft Entra ID とロールベースのアクセス制御 (RBAC) が含まれます。テナント、サブスクリプション、リソースのアクセス許可が、お客様と企業の間に存在するビジネスモデル、および顧客システム管理に対する独自のアプローチとどのように一致するかについて検討する必要があります。 たとえば、Azure Blueprints を使用して、組織に最適なサブスクリプションとリソース グループ モデルを設定できます。

次のステップ

• プライベート モバイル ネットワークの主要なコンポーネントについて詳しく見る
• プライベート モバイル ネットワークをデプロイするための前提条件について学習する