NFV#50@Shanghai & NFV#51@Bonn

 今回のNFV#50はチャイナテレコムがホストし、MWC上海と同日開催だった。またNFV#51はドイツ・テレコムのR&Dセンタ近くの会場だった。今回はオペレータのRoundtableが開催された。

NFV#50 & NFV#51のサマリ

NFVの各Releaseの概要はNFV IFA＆SOL(2021年10月)会合サマリとETSI NFV仕様の各リリース機能、詳細はETSI GR NFV 007 Release Description、各仕様の最新状況はOpenboxとFeature Wikiを参照して頂きたい。

この半年はRelease6における新しいMANOのアーキテクチャをどうすべきか？が大きな議論ポイントとなっている。

前回NFV#49からの更新は

ComponentOpen SourceInterface NameStage 2Stage 3 studyStage 3 Normative
Traffic EnforcerIstio, CiliumTraffic management interface機能要件＆
IF要件仕様化済(ed441)		済(ed531)API＆Resource＆Data model
仕様化済(ed531)
Network Configuration Manager調査中Network configuration management interface機能要件＆
IF要件仕様化済(ed441)		未(ed541
/2025年12月末？)
Upgrade VNF Manager調査中
(Argo?)		Upgrade VNF management interface機能要件＆
IF要件仕様化済(ed441)		未(ed541
/2025年12月末？)
Log AggregatorFluentBit, OpenTelemetryLog exposure interface機能要件＆
IF要件仕様化済(ed441)		済(ed531)API＆Resource＆Data model
仕様化済(ed531)
Log AnalyserOpenSearch, GrafanaLog analysis exposure interface機能要件＆
IF要件仕様化済(ed441)		済(ed531)API＆Resource＆Data model
仕様化済(ed531)
VNF Metrics AggregatorOpenTelemetry CollectorMetrics exposure interface機能要件＆
IF要件仕様化済(ed441)		済(ed531)未(ed611
/2025年7月末？)
VNF Metrics AnalyserOpenSearch, VictoriaMetricsMetrics analysis exposure interface機能要件＆
IF要件仕様化済(ed441)		済(ed531)API＆Resource＆Data model
仕様化済(ed531)
Time Manager調査中Time management interface機能要件＆
IF要件仕様化済(ed441)		未(ed541
/2025年12月末？)
VNF Configuration Manager調査中
(Ansible?)		VNF configuration management interface機能要件＆
IF要件仕様化済(ed441)		未(ed541
/2025年12月末？)
PaaS Service Policy AgentOpen Policy Agent, CedarPolicy Management Interface機能要件＆
IF要件仕様化済(ed511)		分析中(ed521)未(ed541
/2025年12月末？)
VNF Testing Manager調査中VNF testing management interface機能要件＆
IF要件仕様化済(ed511)		未(ed611
/2025年7月末？)
PaaS Service Notification ManagerPrometheus Alertmanager, Argo, Kafka, SensuNotifications Management Interface機能要件＆
IF要件仕様化済(ed511)		済(ed531)API＆Resource＆CRD
仕様化済(ed531)
Configuration ServerSchema-driven Configuration
(SDCIO)		Configuration Data Management Interface機能要件＆
IF要件仕様化済(ed511)		済(ed531)未(ed541
/2025年12月末？)
  • Release 6: Usecase検討中
    • latency aspects and new communication technologies for NFV: EVE024としてTSN(Time Sensitive Network)等をNFVで実現するレポート分析中
    • new infrastructure resources for NFV: EVE023として、Hyper-scalerやSmartNICなどの多種多様なインフラを管理するためのレポートレビュー中
    • architectural support for NFV evolution: IFA054として、複雑化したNFVの仕様をシンプル化＆最適化し、より拡張性高いアーキテクチャにするStage1&2仕様化中
      • ドキュメント構成含めて抜本的に改版中
    • Serverless and other application virtualization forms in NFV: EVE025として、serverlessとNFVの役割を分析するレポート開始
    • computing and network convergence: EVE026としてネットワーク内でComputeリソースを利用するレポートを分析中
    • Model-as-a-Service (MaaS) in NFV: EVE027としてMaaSのレポートを分析中有
  • White Paper: NFVの価値を可視化するために2つのWhite Paperを作成済
  • Release6における新アーキテクチャ
    • Rel2～Rel5の10年利用したアーキテクチャを(互換性を維持しながら)刷新することを目指して、アーキテクチャの刷新はもとより、管理対象の装置やドキュメントの形態、再利用するIFや仕様まで議論中


    • 管理対象装置
    • Descriptorの記述内容
    • ネットワークトポロジー
    • アーキテクチャ
    • ドキュメント形式

Round Table

今回も中国の標準化団体CCSAや、中国・欧州のオペレータの現状など、盛り沢山のラウンドテーブルだった。
  • CCSA(China Commiunication Standards Association)
    • 『中国における標準化活動動向』によれば、2002年に設立された中国の標準化団体であり、無線や優先の通信のネットワークやプロトコルやセキュリティから、運用、ユビキタスやMachine To Machineなど様々なユースケースまで、幅広い範囲の標準化を推進
    • ETSI NFVの仕様を利用し中国内の通信仮想化の仕様を策定済
    • コンテナの利用についてはネガティブでありContainer on VMを推奨
    • AIの利用を推進しており、6G時代のインフラ構築ではAIとNFVの融合がキーテクノロジーになると想定
  • China Mobile
    • 239のDCと1000以上のEdge Siteの巨大な仮想化ネットワークであり、5GC＆VoNRは100％NFVで対応済
    • 6Gに向けては更なる大容量でIntelligenceな通信が必要
    • GPUのリソースプールやLLMの管理を基にNFVを拡張したAIと融合した新しいアーキテクチャを検討中
    • ハイパフォーマンスなサーバ(GPU/DPU)、ストレージ(NVMe)、ネットワークのリソースプール化とAI Accelerator Pooling
    • 新しいタイプのAPLとAIに向けてセキュリティを担保しながらアーキテクチャの進化が必要
  • China Telecom
    • コアネットワークとサービスプラットフォームの2種類のNFV化を実施し、13のCenter DCと多数のEPCやUPFのRegional DCやEdge DCを構築し、5GCとIMSは100％NFV化
    • ベンダー専用のNFVO/VNFM/EMSから、GenericなNFVOやVNFMへ移行中
    • OpenStackベースのPrivate CloudからAWSなどのPublic CloudとのHybrid Cloud、そしてOpenAIなどと連携したAI NativeなCloudへ進化中
    • サイロから脱却し、コンピュート、ネットワーク、ストレージ、PaaSを自由に選び組み合わせられるアーキテクチャを志向
    • ネットワーク、データベース、通信、AI、保守のそれぞれのPaaSがある
    • NFVの仕様をベースAI機能を拡充した自動化


  • China Unicom
    • HW/仮想レイヤー/モバイル装置の3レイヤーの分離、Autonomousに向けたArtificial Drivenな運用、マルチベンダでのO&MがNFVの重要な方向性
    • Cloud NativeとFlexible Networkを融合させた進化
    • Telco Cloud AI Nativeなネットワーク
  • Huawei
    • NFVとAIの融合
    • 早期発見・早期回復に向けたAIを利用したDay2オペレーション
    • CPUとxPUを中心とした新しいリソース
    • Release6の新しいアーキテクチャをベースにCloud for AIに向けた進化


  • ZTE
    • ContainerとAIが次のトレンド
    • AI Infrastructure、AI最適化オーケストレーション、AI Operatorによる3レイヤーのAI対応のアーキテクチャ
    • 垂直統合型の装置がCloud技術によってリソースを共有できる世界が期待値だが、そこまでの技術が未成熟
    • マルチベンダでのデプロイはコストが上昇
    • 標準化とOpen Sourceのフラグメント
    • ITとTelcoのプロダクトライフサイクルのタイミングの違い
  • DTAG
    • GitOpsを利用したCICDのPipelineを利用したモバイル装置のデプロイ
    • 複雑化したモバイルネットワークをKubernetesのOperator Frameworkから制御可能なHost Based Routingによってシンプル化
    • 内製のPipeline、Container基盤によるノウハウの蓄積
  • Swisscom
    • ベンダ基盤を利用しつつ、各種設定のテンプレート化によるGitOpsでの高速デプロイ
  • Telefonica Germany(O2)
    • ベンダーロックインを脱却するためにマルチベンダー化とOutposts化
    • AWSのAI機能を利用した自動化推進
VMからContainerに徐々に標準かも実際のオペレータのデプロイもシフトしつつ、NFVもAIのニーズが高まっている。運用やリソース利用効率を最適化するAI for NWと、GPUをはじめAIを動作させるために必要なリソースを管理するCloud for AIの2軸によってNFVとAIの融合が進むのだろう。

コメント

コメントを投稿

このブログの人気の投稿

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を導入し...
続きを読む

VNF Lifecycle Management (LCM)とは？

イメージ
NFVの登場によりLifecycle Management (LCM)というキーワードが頻繁に登場するようになったが、NFVの用語定義( NFV003 )を見ても”set of functions required to manage the instantiation, maintenance and termination of a VNF or NS“としか書かれておらず、なかなか意味が分からない。NFVの仕様の基本であるLCMについて解説していきたい。 LCMとは？   標準化仕様について①「基本仕様の見分け方」 でも記載した通り、NFVの仕様の基本であり、仮想化されたNetwork Function(VNF)に対してInstantiation/Healing/Scaling/Termination等の制御を行うことである。元々は IT系のLCM  Service という考え方であり、それをNFVでテレコムやモバイル系装置にも同じ概念を適用したようだ。 NFVにおいては、これらの計画・設計 〜 導入・工事 〜 運用・更新 〜 廃止・撤去をそれぞれAPI化し、 モバイルの運用 でも利用可能なように機能を拡充している。 IT系と異なる点 としては 仮想リソース(VMやVirtual Storage)の設定や設計をインフラではなく、Network FunctionのApplication  Provider (VNF Provider)が決めている IT系では、Compute FlavourやGuest OSはインフラ提供者が決め、Cloudの運用効率最大化を指向することが多い NFVでは、性能向上のためにGuest OSの使い方がVNF毎に特殊だったり、そもそも独自OSを利用していたりするため、Guest OSや仮想リソースの設定・設計(Descriptor)はVNF Providerが用意する Cloudのネットワーク機能を利用せず、VNF自身がネットワークを制御する IT系では、CloudのDNSやOverlay Networkingの機能を利用しApplicationはNetworkを意識しない方向で設計や運用をすることが多い NFVでは、VNF自体がRouterのようなものなのでAddressingやTunnelingもVNF...
続きを読む