Red Hat Summit 2021:通信事業者様おすすめのセッション

こんにちは。 Red Hatで通信事業者様向けSolution Specialistをしております久保田です。

本日はRed Hat Summit 2021の中から通信事業者様おすすめのセッションをご紹介します。

今年のRed Hatサミットは4月と6月に分かれています。
一回目は日本のゴールデンウィーク直前にオンラインで行われました。
オンデマンドで視聴が可能ですので、登録してぜひセッションをご確認ください。

今日はその中から通信事業者様おすすめのセッションをご紹介します。

vRANセッション

一つ目はvRANに関してRed Hatのエキスパートによるパネルディスカッションです。

Unboxing cloud radio access network (RAN) RAN(携帯無線のネットワーク)を紐解く

概要

  • Disaggregated(分散) RANとCloudインフラの概要
    • Cloud RAN・RANにおけるCNF化の利点
      • いち早く新しいRAN機能を導入
      • 自動化、CI/CDパイプライン
      • エッジアプリとRANアプリでインフラを共有
  • Telco RANとRed Hatの製品について
    • Red Hat Openshiftに備わったRANに必要な機能
      • 低遅延性
      • ネットワーキング
      • デプロイ(フットプリント)
      • ゼロタッチ・プロビジョニング
      • 迅速な障害の発見とリカバリー
      • コンフィグマネージメント
      • トラブルシューティングとログ・インベントリ
    • Red HatはO-RANアライアンスとTIPに貢献
      • アップストリーム(機能やAPIをオープンソースへ還元)ファースト
      • ソースコードなどをダウンストリームとしてRed Hatの製品へ
    • Red Hat Advanced Cluster ManagementとAnsibleでエッジデータセンターのクラスターを管理、自動化

下の黒い三角をクリックして詳細をご覧ください。

セッションの詳細 Senior Solution ArchitectのCristianを司会に、通信事業 Solution ArchitectureのディレクターとRed HatのRANのグルTimoによるパネルセッションです。

まずはRANの背景について、Timoによる説明から始まります。 RANはこれまではソフトウェア・ハードウェアともにプロパライエタリな一つのベンダーだけの技術で作られていました。 そしてソフトウェア・ハードウェアを分解し、アンテナ、RU, DU, CUの機能にわける技術が進んでいます。これは3GPPの標準のものです。
主に二つの配置方法があり
- Centralized RAN:アンテナよりデータセンター側にRAN機能を配置
- Disaggregated RAN:RU,CU, DUをアンテナ側にも置くこともあるります。人口密集地や環境によって決まります。

Red HatではDU/CUをRed Hat OpenShiftなどのクラウドプラットフォームに載せ、Disaggregated RANを実現しています。

なぜいまCloud RANが注目されているのでしょう。
それは主に以下の理由があります。

  • タイトにインテグレートしていないので容易に早く新しい機能を無線ネットワークに導入することができる。
  • いろんな技術をマルチベンダーで実現できる。
  • RAN市場に新規参入を可能にする
  • Cloud PlatformのRAN構築において、自動化を可能にする
    • RANは何千ものエッジデータセンタで構成されているので、自動化がキー
  • またCI/CDパイプラインも有益
  • Cloud Platformを使うことでRAN Intelligent Controller(RIC)などエッジアプリとRANアプリでインフラを共有できる

ではRANに必要とされる機能とは何でしょう。

1.低遅延
5GにおけるRANのTransportネットワークでは時刻同期が必須です。
PTP(Precitsion TIme Protocol) はクロックの同期に使われるものです。タイムスタンプが使えるNICで使用できると、同期の精度が高まります。数マイクロセカンドまで遅延を抑えることができます。

Cloud RANにおける低遅延の特徴はRealtime Determinism、CPUの親和性と孤立性、トポロジー管理です。

CPUに関してはRANのアプリでもCPUクロックがとても重要です。アサインされたアプリ(低遅延を必要とするもの)にはCPUがリザーブされます。他のアプリケーションに使用させることなく、OSのカーネルなどハウスキーピングにリザーブされるのです。DPDKコンテナのRANアプリにはこのようにIsolateかつDedicatedなコアを使用しています。

トポロジー管理にはDualSocketのNUMAでスケジューリングします。
HWアクセラレータが配置される箇所にはリアルタイムポートがスケジューリングされるのです。

ネットワーキング
RANアプリでは性能を発揮するのにDigital Signal Processing(DSP)のハードウェアデバイスでオフロードさせる必要があります。

通信事業(Telco)で使われているのは、例えばフィールドプログラマブル・ゲートウェイであるFPGA、様々な機能が決まったライフサイクル上で使用されるASIC、ハイパフォーマンス・データプレーンを実現するDPDKなどがあります。

Multusでは複数のNIC・IPをサポートし、マルチネットワーキング・インターフェースやSCTPのマルチホーム・サポートを実現します。

通信事業では大容量トラフィックと低遅延が必須なのはご存知の通りです。大容量の例としてはフロントホール・インターフェース(RU-DU間)で25−30Gbpsのスループット、低遅延はいくつかの要素はありますが、10−20マイクロセカンドほどと言われています。

デプロイ(フットプリント)と拡張性
vRAN(仮想RAN)のユースケースでは、このようなエッジクラウドがなるべくセルサイトに近くある必要があります。しかし、セルサイトはだいたいスペースや電源容量が制限されているものです。ですから、RANクラウドはフットプリントが小さくなくてはいけません。

そこで、Single Node OpenShift(SNO)やリモートワーカーノードなどの機能が有益となります。
SNOはマスターとワーカーノードを単一サーバーで動かすことができる機能です。リモートワーカーノード機能ではマスターノードを中央のデータセンタに置き、ワーカーを分散してエッジに配置できます。
もちろん、実際のデプロイにはCSPやNEPにより色々な好みや違いがあります。

ゼロタッチ・プロビジョニング(ZTP)
最後はZTPです。
大規模RANをデプロイするには、オペレーションの自動化が必須です。中央からデプロイ、アップグレード、コンフィグ、ハードウェア・プロビジョニングなどをリモートクラウドにする必要があります。

OpenShiftは上記の機能を実装しており、すでにパートナーと実証しています。
どのようにデリバー、スケール、自動化するかがキーとなります。これにはCloud RANをアプライアンスのように扱う、つまりLABで十分テストされていて、LAB同様にデプロイできる必要があります。
Cloud RANのデリバリーはDay1とDay2に分けられます。以下のような機能も必要となるでしょう。

通信事業基準のHigh Availability、迅速な障害の発見とリカバリー モバイルブロードバンドにはFive 9s(0.99999)の要件あり、つまり一年に5分と30秒のダウンタイムしか一年に許されないことが多くあります。 低遅延を考慮するとSix 9s (1年で30秒のダウンタイム)しか許容されません。 つまりHigh Availabilityは一番重要なCloud RANでの機能なのです。

コンフィグマネージメント 全てのクラウドの設定をPersistant DBに格納し、このデータをCLIとRESTで運用します。これはどのようにCloudを操作するか、ローリング・アップデートを行うか、ということです。また、一晩で4時間しかないメンテナンス時間内で何らかの操作の失敗の場合には、ロールバックを行う必要があります。

トラブルシューティングとログ・インベントリ
アラームを収集、KPIやログをニアリアルタイムで収集しモニタリングツールのあるNORTHBANDインターフェースに提供します。 

DUに関してはCPUマネージャー、Huge Pages、PTP、DPDK、SCTPなどの実装が必要になります。OpenShiftではこのようなケイパビリティが実証されています。 アプリのデプロイ、ストレージやファイアウォール、ネットワーク、ハードウェア、スイッチのプロビジョニングはAnsibleで自動化することが可能です。

ここで、リアルタイムな質問がチャットで投稿されます。

質問:HWアクセラレーションはOpenshiftでサポートされていますか?
答え:DUでも実証されています。 設定はAnsibleで自動化でき、Day1で自動化し、Day2でクラウドサイトにデプロイできます。

質問:通信事業産業について、どのスタンダードの組織にRed Hatは参加していますか
答え:通信事業はスタンダード(標準化)に依存しているのはご存知の通りです。これはデバイスやネットワークの相互接続性の観点、マルチベンダーを可能とするためです。3GPPとITUが主にありますが、Red Hatはその会員ではありません。

RANでは二つの主な団体があり、O-RANアライアンスにはRed HatもWG6・Cloudification and orchestrationにてインターフェースやアーキテクチャで貢献しています。また、Disagrigting RANで必要となるセキュリティでも貢献しています。 もうひとつはTIM (Telcom Infra Project)で、こちらはPoCや検証など実用的なことを行なっている団体です。Red HatはTIMのopen-RANグループに参加しており、13のOpenLabのうちいくつかに参加し、OCPをプラットフォームとして推進しています。

Red Hatはオープンソースのアップストリーム開発モデルとしてこの2つのRAN団体に貢献し、この結果をアップストリームにあげ、機能やAPIをオープンソースに還元しています。これはとても難しいことですが技術の発展には非常に重要なことです。 そして、そのソースコードなどをダウンストリームとしてRed Hatの製品にとしていれこみます。 これがRed Hatのアップストリームファーストの文化です。

質問:何千ものサイトがあるがどのように管理しているのでしょうか

答え:大規模なモバイルネットワークでは何千ものアンテナサイトがあり、DU/CUをホストしているエッジデータセンターも同じくらいあるでしょう。インストールとデプロイは未だ手動で行われています。

Red Hatではそれを自動化できるようにツールを促進しています。 Red Hat Advanced Cluster Management (RHACM)を適用し、何万ものエッジデータセンターのクラスターを管理したり、ポリシーベースのk8sモデルやアプリケーションのライフサイクルや監視を行うなど大規模なデプロイメントのクラスター管理に活用できます。

また自動化ツールであるAnsibleもこの何千ものエッジサイトのデプロイメントに活用することができます。

質問:Telco Edge Mobile ComputingとRANの関連とは?

答え:5Gにはビジネスと居住地での需要があり、アクセスにはいくつかの種類(FixWireless, CMTS などのケーブル、4/5G、Wifi、NB-IoTなど)があり、その技術は全てベアメタルでした。現在、それらは仮想・コンテナ・クラウド化され、全て同じクラウドで動くように融合されています。通信エッジクラウド全体で共有できるのです。それらのサービスはパフォーマンスだけでなくプライバシー、E2Eコントロールなどの必須要件定義があります。

また全てのサービスがエッジに配置されるわけではなく、大体がデータセンターに配置されます。例えば、自宅設備の自動化のツールは低遅延が必要ではないですよね。Private5Gなど、工場やスタジアムはエッジからデータセンターにデータを送るような必要もありません。つまりサービスをエッジに持ってきて、低遅延とエッジのプライバシーを確保する必要があるのです。

通信エッジクラウドはユーザーに近いクラウド、遅延の要求に耐え、かつ距離を許容できるものでなくてはいけません。 このタイプのクラウドは、まずはDUクラウドがあります。これはD-RANユースケースで、マルチテナントではなくシングルサーバーで動くことが多くあります。つまりアプライアンスのようなものと考えられます。

ただその次にくるクラウドはRICやMEC機能があるCUで、エッジで動くサービスへのブレークアウトが必要となります。 UPFのようなゲートウェイ機能をおく必要があり、UPFではMEC、マルチアクセス・エッジコンピューティングへのトラフィックのブレークアウトができます。

MECではVR・AR、スマート・マニュファクチャリングなどのアプリケーションが使えるようになるのです。 このように、通信事業用エッジは様々なアクセスネットワーク・テクニカルなアプリだけでなく、エッジにおかなければならないアプリやサービスの低遅延の要件に合わせることができます。

質問:CU/DUにおいて、VNFよりCNFが良い点とはなんですか
答え:コアアプリはベアメタルから仮想マシンに移行しましたが、全てのアプリが移行したわけではありません。仮想マシンのステップを経由しないで直接コンテナ化されたものもあります。
コンテナ化したアプリは通信クラウドに移行した利点があります。 そのひとつがCI/CDパイプラインで、これによって新しいRAN機能をいち早く使うことができます。 またエッジにおいてはDevSecOpsによってセキュリティを強化することが可能です。

以上が30分のvRANに関するセッションでした。

Verizonのソリューション

次はVerizonが採用した、AWS WavelengthとOpenShiftのエッジソリューションに関してのパネルディスカッションです。

Verizon 5G Edge with Red Hat OpenShift unleashes the next generation of applications

概要

  • ネットワーク

    • コンピュートとストレージの全ての機能をリージョンに配置し、世界最大級のハイパースケーラー(AWS Wavelength)で提供
    • モバイル・エッジ・コンピューティングのポートフォリオであり、顧客に価値を与える5Gエッジ
    • 遅延を減らすためコンピュートとストレージをユーザー側に配置したモバイル・エッジ・コンピューティング
    • アクセスの形態(5G・ベライゾンのネットワーク)を意識することなく、顧客・開発者たちはシームレスにアプリケーションの開発・デプロイ
    • マスターを通常のAWSのリージョナルゾーンに、ワーカーをWavellengthにデプロイし、アプリケーションがエッジで動く
  • Red Hat OpenShift

    • 5Gエコシステムに溶け込んだソリューションをRed Hatチームとともに実現
    • IPIインストールを使用
    • Single Node Openshiftによるエッジでの小さいフットプリント

icon OpenShiftブログより

下の黒い三角をクリックして詳細をご覧ください。

セッションの詳細 こちらはVerizonの Strategy AnalystであるRobert BelsonとRed HatのPrincipal Specialist Solutions ArchitectであるAshish Aggarwalのパネルディスカッションです。Red HatのSachin Ratheeが司会を務めます。

まずVerizonのRobbie(Robert)がRed HatとVerizonの初期の活動について話しました。 2つのチームが一緒に動くために、まず初めに行ったのは基本的な5Gエッジの定義でした。「5Gエッジとは何か」、「そのポートフォリオがどのように顧客に価値を与えることができるか」を議論したそうです。

皆さんも日々のインターネット通信で体感されるように、ネットワークは通常は「ベストエフォート」であり、どうしても遅延に悩まされることが多いものです。
しかし、そこを差別化要因とし、アプリケーションのモダナイゼーションやコンテンツ・デリバリーネットワークを促進させ、ウェブページなどのアセットをユーザーにより近いところに配置しました。 このコンセプトをモバイル通信の世界にも持ってこれないかというところで、コンピュートとストレージをよりユーザーの近く持ってきたものが、モバイル・エッジ・コンピューティングのネットワークです。

それをもう一歩先に進めて、コンピュートとストレージの全ての機能をリージョンに配置し、世界最大級のハイパースケーラーに乗せネットワークエッジだけではなくモバイル・ネットワークエッジでサービスを提供しよう、というのが今回のVerizonのソリューションでした。

これによりアプリケーションチームがアプリケーションを最適化するように、モバイルの世界でも「どこにデプロイするかだけではなく、どのようにデプロイするか」さらにたくさんの選択肢を提供できるようになりました。k8sクラスターの載ったVM(仮想マシン)を使い、Red Hat OpenShiftのプラットフォームが使えるようになったのです。

ここで、本日のセッションのトピックでもあるVerizonによる、AWS Wavelengthの5Gエッジコンピューティングのソリューションについて話は深掘りされます。

Verizonの5Gエッジはモバイルエッジ・コンピューティング・ポートフォリオです。いいかえると、このAWSサービスはパブリック・モバイルコンピューティング的なものです。Verizonはプライベートエッジも提供しているそうですが、今回はパブリックにフォーカスを当てることにしたそうです。というのもARやVR、イーコマースや小売、V2Xなどのコンバージェンスをドライブするという価値がパブリックサービスにはあるからです。

AWSではコアサービスをエッジに、とくに4Gや5Gのモバイルエッジに持ってくることができます。

なぜコアサービスをエッジ側に配置すると良いのでしょう?

エンドユーザーは4Gや5Gの基地局に接続するのですが、ここではモバイルパケットがアンカーされ、コンピュートが起こるからです。この通信はハイパースケーラー越しにデータセンターに接続されるとは言っても、トポロジカル的にはモバイル・エッジコンピューティング側に接続するのが近いのです。

さて、ここでVerizonのユーザーにとって大切なのは5Gのネットワークについて知ることではありません。ネットワークの詳細を知らなくてもハイパースケーラーとRed Hat OpenShiftを含むインテグレートされたプラットフォームを信頼することで、アプリケーションの開発に集中することです。

さて、ここで話はAshishに移ります。
AshishはRed Hat OpenShiftの利点を、デプロイの環境を気にすることなく 開発者が常に同じ環境で開発することだと述べています。例えば、アプリケーションの開発において、デプロイされるインフラストラクチャがエッジのどこにあるのか気にする必要がないのです。

ここでAshishはOpenShiftをWavelengthにデプロイするときの方法と変更点を聞かれます。
今回OpenShiftはカスタマイズすることなく、通常のIPIでデプロイされました。また、OpenShiftはシングル・ノードで運用も可能でフットプリントも小さいことも利点でした。

ただ、唯一の変更点はMTUの値です。 ちなみに詳細はこちらのブログに載っておりますので、OpenShiftをAWSのWavelengthで試してみたい方は是非ご覧ください。

マスターノード(コントローラー)をAWSのペアレントリージョナルゾーンに、ワーカーノードをWavelengthにデプロイし、アプリケーションをエッジ側で動かすことに成功しました。これにより低遅延が実現されたのです。

OpenShiftのエコシステムによってk8sオペレーター機能、サーバーレス、サービスメッシュなどの機能を使用しアプリケーションをデプロイしました。 つまり、アベイラビリティ・ゾーンでシームレスにRed Hat OpenShiftを使えます。WavelengthはAZの一つとして扱われ、ユーザーはVerizonのネットワークなのか、5Gアクセスなのかを意識する必要がありません。

新しい技術や5Gの特性を学ぶ必要なく、ユーザーは5Gの恩恵を受けることができるのです。この点はVerizonのRobbyが付け足しながら絶賛した点です。

さて、ここでユースケースに話は移ります。 顧客がエッジで何をするか。 V2Xなどの自動車関連や安全性、インフォメーションに関するビジネス。コンタクトレスなパブリックなサービスとして、メディアやエンタテイメント。スタジアムに接続されたたくさんのカメラやセンサー。

これらはオーケストレーションやクラウド管理が必要なワークロードで、インテリジェントなトラフィック・ルーティングやクラウドの分析が必要です。

しかし、全てのカメラなどのデバイスをケーブルで繋げるのは拡張性が高いとは言えません。 また、少し前のテレビ中継でも皆さんご存知の通り、衛星を経由したテレビ放送は遅延が発生します。現地のレポーターとスタジオのキャスターのすれ違った会話がよく以前は見られましたよね?

現在では5Gネットワークに接続されたカメラとSDN(ソフトウェア・デファインド・ネットワーク)があれば、柔軟性と拡張性をもった放送が可能です。 低遅延、エッジでのフラッド検知、キャッシュによる遅延の緩和によって、時間と帯域を節約することができます。

なぜ、Verizonは5Gに取り組むのか、5Gの利点とは何か、というリアルタイムの質問に対して、Robbyは5Gはやはり高速であることをあげています。 LTEでは4秒かかっていた1メガのデータも5Gでは32ミリ秒で送信することができる。これによってユーザー・エクスペリエンスは飛躍的に向上します。

最後に5GエッジのエコシステムについてRobbyがVerizonの視点で答えます。

このエコシステムによって、開発者コミュニティを魅きつけ育成することができます。5Gエッジはすでに大企業にとってはインフラを拡張し、ROIや顧客体験を向上させるのために、すでに活発に発展・活用されている技術です。 コンテンツ面では、このウェビナーのようにコミュニティの認知度を高め、特にインフラに関して開発者にどこに、どのようにアプリケーションをデプロイするかの様々な選択肢を与えることができます。

それだけでなくまたAshishRobbieのブログのようにリファレンスアーキテクチャによって簡単にデプロイメントする方法やクラウド構成のテンプレやモジュールなどを伝えることも可能です。 またVerizonの5Gラボでは仮想および物理のテストラボがあり、開発者たちはハンズオン体験をしたりアプリケーションを試験稼働したりできます。

アドボカシー面では顧客と働いたり開発者が既にいるチャネルにてコミュニティを作り上げることがエコシステムで大切なことです。 Sachinの#5GBuildRightと書かれたTシャツのように、とても深くエコシステムにインテグレートされて5Gを作り上げるのです。

だからRed Hatと一緒にこの場で講演できること、パートナーとして働けることを光栄に思っていると述べて、セッションは終わります。

その他にもSecurityやEdge関連の興味深いセッションがあります。 ぜひご登録の上、オンデマンド配信をご覧ください。

Red Hat Summit 6月のおすすめ

Red Hat Summit 2021は6月にも続きます。

その中から個人的注目セッションをご紹介いたします。

Cloud-native 5G with Verizon Wireless and Red Hat
Verizon Wirelessの5Gコアのビジョン、Red Hatと協働する中でのアーキテクチャ要求や体験を5GデプロイやCNFとそのインフラプラットフォームのベストプラクティスを交えてお話しします。
Tuesday, Jun 15 2:00 PM - 2:30 PM JST(他)

Lessons from a truly multivendor 5G standalone trial
真のマルチベンダーかつクラウドネイティブ 構成の5GSAをどのように実現・運用しているか。Telenorのソリューション・アーキテクトとリサーチサイエンティストが実体験を共有します。
Wednesday, Jun 16 1:00 PM - 1:30 PM JST(他)

Delivering a unified 5G-edge solution for telco cloud and distributed datacenters
5Gネットワークを低コスト、高パフォーマンスでエッジ・ネイティブなアプリケーションで実現するために、Red HatとKaloomでどのようなコラボレーション・ソリューションを作り上げたかお話しします。
Wednesday, Jun 16 12:00 PM - 12:30 PM JST(他)

ご登録はこちらから!

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。