NFV#40(2022年12月)@London & O-RAN F2F@Madrid(2022年10月)会合サマリ

 9月の会合から段々と現地参加型の会合の形式に変わってきた。オンライン参加者もまだまだ多く今回10月のO-RANと12月のNFV#40は現地とオンラインのハイブリッドでの開催ではあるが、概ねどこの企業も最低でも数名は現地で参加しているようだ。HuaweiやZTE等の中国企業も代表者は現地で参加していた。

今回のNFV#40はLayer123との同時開催となり、様々なグローバル動向の議論があった。そのNFV、O-RAN、Layer123の議論を聞く限り、昨今の方向性は"コンテナ化"から"統一プラットフォーム + 自動化"になってきているように感じる。

NFV#40のサマリ

NFVの各Releaseの概要はNFV IFA＆SOL(2021年10月)会合サマリとETSI NFV仕様の各リリース機能、詳細はReleaseDocument、各仕様の最新状況はOpenboxとFeature Wikiを参照して頂きたいが、前回NFV#39からの更新は

  • Release2(v2.8.1)に続き、Release3(v3.7.1)もメンテナンス終了となってきた。WIMのStage 3 IF Or-Wi(SOL019)は完成しなかったため、Release4へ延期となる。
  • 新ETSI NFV ISG議長中島さんのChairman perspectiveが発表された


  • Release4(コンテナ対応): 4.4.1に向けてCIS Cluster管理のためのCCM (CIS Cluster mgmt)を中心にStage2/3の仕様化

    • FEAT17 (Clust-native): CCMのStage3 IFとしてSOL020が提案＆承認された
      • CIS Cluster (Kubernetes Master Node + Worker Node)を構築＆運用する機能部としてCIS Cluster Management Function (CCM)が定義
      • CCMはCIS ClusterのLCMやFCAPS、更にはKubernetesのCRD(Custom Resource Definition)も構築＆管理する
      • IFA036のアーキテクチャや機能分担を満たせるデファクトソリューションはないため、GAP分析からスタート
      • Cluster APIが最有力候補とは見られているが、粒度が合っていない(IFA036はCIS Cluster単位でNFVOと接続 vs CISI(Worker Node)単位で制御するCluster API)のでどうするかは今後要検討
    • FEAT19 (NFV Connectivity): IFA035によってCloud上のNWのバリエーションが揃ってきた
      • NFVにおけるネットワーク関連の仕様としてVM系(IFA035)とコンテナ系(IFA038)を検討中
      • IFA038は既に発行済
    • FEAT20 (Autonomous): IFA047(MDAF: Management Data Analytics Function)のStage2がStable化
      • MANOの中にデータ分析機能が追加され、他の標準仕様等に合わせて解析結果を通知できるようになる
      • 学習データの投入方法がOut of scopeだったり、データ解析用のデータや解析結果のデータモデルが決まっていなかったりするので、もうひと工夫必要
    • FEAT21 (5G NFV): 3GPPとNFVの間のGAPとしてPaaSが抽出されていたが、そのPaaSを管理するPaaS Mgrの機能分担について議論中
      • 3GPPの5G仕様とNFV仕様のGAPを埋める取り組み
      • 5G NFVは既存仕様の拡張も必要なため、IFA-SEC-SOL Joint Sessionでも早急に仕様拡張を進めることを議論
    • FEAT24 (Generic OAM): IFA049においてStage2が少しずつ推進中
      • Cloud native時代(VMとコンテナ両方)の運用(EVE019)をベースにVNFのOAM系の共通機能をPaaS (Common Function + Generic OAM)として定義
      • 今回Generic OAMのリファレンスポイントの位置が確定
      • Time FunctionとVNF Configuration Manger Functionのインタフェース要件が承認
      • Traffic Enforcer、Network Configuration Mangement、VNF Upgrade、VNF Metrics Analysis Exposure、VNF Metrics Aggregator Exposure、Log Analysis Exposure、Log Aggregator ExposureのStage2が進行
    • FEAT26 (Policy content): IFA048がStable
      • SOL012とのGAPについてどうするか議論中
  • Release5: 最初のReportがStableやFinalize中
    • FEAT23(SBA): Rel5に延期
      • MANOの中のアーキテクチャをFunction Block＋Reference Pointベースとするか、Service Based Architecture (SBA) + Service Based Interface (SBI)とするかのStudy
      • ReportであるIFA039は当初Release4として検討を進めていたが、Rel5として発行
    • FEAT29(GreenNFV): EVE021としてReport作成中であり、間もなくStable
      • データセンタの省電力に向けて必要な機能やメトリックスの検討＆仕様化
    • FEAT30(VNF Configuration): EVE022としてReport発行済
      • VNFのConfigurationの投入方法は3GPP-SA5やNFVのVNF Configuration、デファクトのCloud-initやAnsible等、様々な投入方法があるため、そのルートと設定可能な内容の確認
      • VNF向けのConfiguration設定のGuidelineとしてどういうドキュメントをどのように発行していくか検討中
    • FEAT31(Flexible VNF deployment): IFA044として間もなく発行
      • 従来のVNFの構成や容量変更は"VNF Deployment Flavour"という静的に定義された設定を変更(ラックの中のサーバ構成を変えるイメージ)することで容量を変えてきたが、Cloud-native時代ではより動作中(runtime)にDeployableModuleという単位で変更可能とする
    • FEAT24 (Enhansed Generice OAM): EVE019を拡張し、更にAPLサイドの監視制御もUsecaseに追加

Layer123のサマリ

今回はNFV#40と同一時期＆場所でLayer123 World Congress 2022も開催された。Layer123はオペレータサイドの技術部門の幹部や、製品ベンダのプロダクトオーナー等が参加するイベントであり、オペレータのビジョンとベンダ製品のコンセプトをプレゼンしたり、パネル討論等を行っていた。今回は特にNFVDaysというものが設けられ、NFVのメンバーも多数プレゼンをしていた。

EricssonやNokiaはあまりプレゼンが無かったが、オペレータや中国勢はコア～無線の統一プラットフォームを目指したアーキテクチャ提案が多数あり、どのオペレータやベンダも次のターゲットは無線であることを感じるプレゼンだった。

Huawei

ZTE

Amdocs

Vodafone

Rakuten

Tera Flow

DOOCMO


O-RAN F2F@Madrid会合サマリ

O-RANはよりOpenな団体に仕組みが変更され始めており、多くの提案や仕様がNon-Confidentialとなってきた。仕様も公開されこちらからダウンロードできるようになった。少し古いがO-RAN全体像はO-RAN virtual Face To Face Meeting Februaryサマリを確認して頂きたい。 

O-RAN全体概要

O-RANは現在11のWGによって、SMO (Service Management and Orchestration - Confluence)、O-Cloud、RIC (RAN Intelligent Controller)、RU(RADIO Unit)～vDU(Distributed Unit)～vCU(Central Unit)の仕様化が推進されている。特に今回WG11 Securityが独立したWGとして活動を始め、他のWGの仕様とセキュリティ観点で議論が始まったことが特徴的であった。

SMOの概要

SMOの中の機能部は2022年12月時点ではまだまだ仕様化が進んでおらず不透明な部分が多い。現時点で定義され始めている機能部としては
  • NFO (Network Function Orechestration): O-Cloud DMSとO2dmsと接続し、vDU/vCUのLCMを制御する機能部
  • FOCOM (Federated O-Cloud Orchestration and Management): O-Cloud IMSとO2imsと接続し、O-CloudのLCM＋FCAPS(Fault / Configuration / Accounting / Performance / Security)を管理する機能部
  • RAN NF OAM (RAN Network Function Operation And Management): RU/vDU/vCUのFCAPSを管理する機能部
  • Non-RT RIC (Non-Real Time RAN Intelligent Controller): SMOの各種サービスと接続し、rAppからの指示に従って自動化するための制御機構
  • rApp (Non-RT RIC Application): Non-RT RIC上で、業務を自動化するアプリケーション群
これらの構成についてO-RAN SCでは以下のような構成を検討中である。今後、SMOのNBI(North-Band Interface)なども検討が進むと、新たなサービスが増えていくだろう。 
OpenStack Tackerの資料とはなるが、O-RAN SMOの仕様進捗状況とNFVの関係が分かる資料としては、こちらだろう。O-RAN SCのG-ReleaseはO-RAN November Trainの仕様をベースに2022年12月にReleaseされたばかりである。やっとSMOとO-Cloudが接続できる仕様ができてきたが、まだまだNon-RT RICからvDU/vCUやO-Cloudを自動制御するというところまでは遠い。NFVO相当の機能やEM相当の機能の早期の仕様化が求められる。

セキュリティ議論

ETSI NFVにおいて既にセキュリティ関連の仕様ができているので、そちらを参照していく方向で議論が進んだ。



5Gになってきて、建設vs保守、RANvsコアがそれぞれ近づいてきており、”統一プラットフォーム上でいかに自動化するか？"が議論の中心になってきている。背景としては、モバイルネットワークを、一般ユーザー向けからvertical industry(他の産業)へ拡張し、それらのネットワーク毎に管理運営(Slicing)していくことを考えているのかもしれない。

コメント

コメントを投稿

このブログの人気の投稿

CISMとは？CCMとは？NFVでコンテナ管理はどうやるの？

イメージ
ETSI-NFV仕様の各Release機能 の通り、ETSI-NFVのRelease4ではコンテナの制御が追加される。Release4は IFA039のSBA の影響でService Baseの仕様が入っており、ETSI-NFVにおけるコンテナ管理は様々なバリエーションがある。そのため、どのように各仕様を使うかを理解するのは非常に難易度が高いだろう。なお、コンテナとは何か？については こちら を参照して頂きたい。 Kubernetesによるクラウド管理 Kubernetesは、コンテナという技術と各種管理機能を使ってプログラム(APL)を抽象化し、クラウド上でAPLを制御するフレームワークとそれを支える管理機能群である。ここでのクラウドとは、APLを抽象化することでインフラの制御を含む様々な資源を共通機能化し、それらをAPIでソフトウェア的に制御できるようにしていることだが、それを仮想化とクラウドの違いから図でまとめてみた。 仮想化だけした場合(単純仮想化)は、基本的にはAPLは物理装置自体と同じ構造であり、それをインストールしたり故障時の修理をしたりする作業も物理装置と同じ手順が必要だった。しかし、せっかくAPLを仮想化によりソフトウェア化し、HWとの依存関係を無くしている(抽象化している)ので、例えば初期構築やHW故障時の対応をAPI化したい。これがIaaS(Infrastructure As A Service)と呼ばれ、サーバやNW機能の一部を管理機能(ETSI-NFVの場合はVIM)で制御できるようにしている。これにより、物理装置の変更に伴う各種作業は削減され、VMだけ考慮すればよくなった。さらに一歩進んで、LBやDBなどの共通機能をインフラの一部として提供する(PaaS)ことで、HWに依存しない新しいタイプのAPLとプラットフォームへ進化することができ、この“何か分らない雲のようなところにリクエストを出すとサービスを得られる“というものがクラウドである。 Kubernetesは、このクラウドの効果を最大化するために、APLの範囲を最小限化している。 Kubernetesの世界では、APLはDataを持たず、Logicのみをコンテナとしてカプセル化しPodという単位で管理することで、外部から容易かつ高速に起動/停止が可能となっている。そのため、APLの冗長...
続きを読む

モバイルネットワークの保守運用の基礎

イメージ
O-RANや Sliceの管理 によって、最近モバイルネットワークの保守運用が脚光を浴びるようになってきた。しかし、運用方法や保守系装置は“オペレータやベンダ毎に異なる領域“というイメージであり、なかなかまとまったドキュメントや資料が見つからない。 保守運用の基本 これまでネットワークの保守運用のデファクトや標準仕様と言えばTM Forumの eTOM 程度しか無かったと思う。eTOMや各種標準化機能やOpen Sourceを踏まえると、大きく以下のような考え方がありそうだ。 保守運用のプロセス strategy： 新サービス導入やユーザの利用状況を踏まえた設備計画 保守運用の観点から見るとfulfillmentのInput情報 fulfilment(fulfillment)：設備計画に基づいたネットワーク装置(NF)や、それらを接続するネットワーク(NW)の設計・工事 assurance：運用しているNFやサービスの監視や復旧、更新作業 4Gまでの保守運用というと、assuranceを指すことが billing：利用状況に基づいた課金 保守運用の観点から見ると運用結果のOutput 保守運用レイヤ Business Management System (BMS)： 顧客の契約情報を管理 一般的にBusiness Support System (BSS)を利用 Service Management System (SMS)： 提供サービスの管理運用 Network Management System (NMS)： (サービスを実現する)NFの接続性の管理運用 4GまでのOperation Support System (OSS)と言うとNMSのことを指すことが多かったようだ Element Management System (EMS)： NF自体の管理運用 NFのFCAPSと言えば、EMSのことを指すことが多い 一般的にネットワークの保守運用というと、EMSまたはNMSのレイヤのfulfilment＋assuranceを指すことが多いように感じる。しかしながら、システムによる実装と人手での運用という観点では、4GまではEMSのassuranceまでを実装し、残りは手作業ということも多かったようだ。規模が大きな企業では、NMSやSMSの一部を取り入れてOSSを導入し...
続きを読む

VNFMとは？

仮想化された交換機等のテレコム設備(VNF: Virtualised Network Function)の管理機能部としてETSI-NFVではVNFM(VNF Manager)が定義されている。VNFMの主な役目として VNF LCM を行うというものがあるが、VNFMが入ることでNFVOやVIMとの機能的な違いが分かりにくくなっている。VNFMの役割とは何だろう？ ETSI-NFVにおけるVNFMの役割 ETSI GS NFV-MAN 001 の過去の提案資料(寄書)や議論状況を見ていると、どうやら以下のような考え方で機能部を検討してきたようだ。 テレコム設備(Network Function)の仮想化(VNF) Compute/Storage/Networkの仮想リソースプール化(NFVI: NFV Infrastructure) 複数のNFVIの管理/クラウド化(VIM: Virtual Infrastructure Manager) 複数のVIMのキャパシティ管理と既存保守機能部(OSS: Operation Support System)の接続と自動化(NFVO: NFV Orchestrator) 既存のNFのOAM部(EM: Element Manager)やVNFの仮想化に伴う不足機能の補完(VNFM) MAN001の議論状況だけ見ると、上記の通りNFVOとVIMしかなかったようだ。MAN001の発行直前に、既存のVNF/EM/OSSと新機能部であるNFVO/VIMの不足機能を補完するためにVNFMが定義されている。 問題はこの“不足機能“とは何かが不明瞭なため、VNFMは様々な機能部との境界ラインが曖昧になってしまっている。 VNFMの機能 ETSI GS NFV-IFA 010 を確認すると、VNFMが保持する機能としてはVirtualised Resource (VR) Mgmt、VNF  LCM、VNF Config Mgmt、VNF Info、VNF FM、VNF PM、VNF Indicator、Policy Mgmt、Snapshot Mgmt、VNF workload Mgmtがある。VNF LCMやVNF workload Mgmtは NFV-Tacker workshopのレポート「NFV＃34会合サマリとNFV-Work...
続きを読む