NFV#42(2023年6月)@Sophia-Antipolis & O-RAN F2F@大阪(2023年6月)会合サマリ

 今回のNFV#42はFuture NFVという名目で、ETSI NFVを含むETSIの標準化やOpen Sourceとの関わり方を含めた組織のあり方についてのキックオフがあった。

NFV#42のサマリ

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

  • Release4(コンテナ対応): v4.5.1のStable化
    • v4.5.1: コンテナ関連とセキュリティ関連の仕様改善
      • DaemonSetの定義 
      • TST010のv4.3.1のStable化(Robot code)
    • FEAT17 (Cloud-native): SOL020のGAP分析終了 -> Stage3開始
      • Container based VNFの制御に関する仕様はStage3までほぼ完了
      • CIS Cluster (コンテナ基盤)制御のためのCCM(SOL020)についてGAP分析が完了し、Cluster APIをベースにStage3開始
    • FEAT19 (NFV Connectivity): 
      • NFVにおけるネットワーク関連の仕様としてVM系(IFA035)とコンテナ系(IFA038 発行済)
      • IFA035もStable化済
    • FEAT20 (Autonomous): IFA050(Intent mgmt)の基本IF策定
      • Intent + Data Analyticsによって運用の自動化のためのIFを規定中
      • MANOの中にデータ分析機能であるIFA047(MDAF: Management Data Analytics Function)のStage2が発行済
      • Intentは3GPP TR 28.812 / TS 28.312やTM Forum TMF921A, ETSI ISG ZSM011にて制定済であり、それらと整合化済
      • NFVの当初思想は仮想リソース(Compute/Network/Storage)をNetwork Serviceという形で提供しているが、Intent ⇔ 仮想リソース の変換をIntent Handlerで行う方向で仕様化中
    • FEAT21 (5G NFV): PaaS Mgrの機能分担についてFEAT24と併せて仕様化済
      • 3GPPの5G仕様とNFV仕様のGAPを埋める取り組み
      • IFA049においてPaaS Mgrの導入
    • FEAT24 (Generic OAM): IFA049においてStage2がFinalize済
      • Cloud native時代(VMとコンテナ両方)の運用(EVE019)のためのOAM系の共通PaaS (Common Function + Generic OAM)
      • Descriptor、VNF⇔PaaS間IF、PaaS Mgrは次版(v4.6.1)以降
    • FEAT26 (Policy content): Stage3の議論停滞中
      • ONAP APEX、TOSCA Policyなど、どのソリューションをベースとするかの議論中
    • FEAT31(Flexible VNF deployment): 一部機能をv4.5.1に前倒しし、Stage3仕様化中
      • VDUの組み合わせを自由に変更可能なDeployable Moduleという概念を導入
    • Enh01.01(Certificate Management): Stage2が完了し、Stage3開始
      • 暗号化通信やPackage管理のために利用する証明書を管理するCMF(Certificate Management Function)の導入
      • Direct-mode(証明書を利用する機能部が自ら証明書発行を要求)とDelegation-mode(VNFMなどの管理機能部が代理で証明書発行を要求)
      • IFA026(Stage1), IFA033(Stage2 CMF～NFV-MANO IF)がStable化され、IFA006(VNFM～VIM), IFA007(NFVO～VNFM), IFA008(EM～VNFM), IFA011(VNFD), IFA013(OSS～NFVO), IFA031(MANO Mgmt), IFA040(CISM)にもそれぞれCertificateConfigurationData/CertificateInfoを追加
  • Release5: 最初のReportがFinalizeし、一部前倒しでStage2を開始
    • FEAT23(SBA): Rel5に延期
      • MANOのアーキテクチャのFunction Block＋Reference Point vs Service Based Architecture (SBA) + Service Based Interface (SBI) (IFA039)
    • FEAT29(GreenNFV): EVE021がStable化済
      • データセンタの省電力に向けて必要な機能やメトリックスの検討
    • FEAT30(VNF Configuration): EVE022発行後進展なし
    • FEAT31(Flexible VNF deployment): IFA044として発行済
      • Step1 (DeployableModule)はRelease4へ前倒し中
      • Configurable Attributeの導入はRelease5
    • FEAT24 (Enhansed Generice OAM): EVE019を拡張し、更にAPLサイドの監視制御もUsecaseに追加済
    • PIM: (Physical Infrastructure Manager): IFA053としてStage2仕様化開始
      • IFA036(CCM), IFA046(vRAN for NFV), EVE021(Green NFV)等で物理レイヤを制御する機能部の必要性について議論済
      • IPMI, Ansible, DMTF Redfish, OpenStack Ironic, LFN ODIM, metal3等がGAP分析の対象
  • Release 6: NWIの提案開始
    • 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の仕様をシンプル化＆最適化し、より拡張性高いアーキテクチャにするレポート開始
  • Future NFV: これから10年間のNFVの方向性
    • NFVのMissionとScopeの見直し: VM以外の様々な仮想化技術を対象に様々な標準化団体と連携/マージ
    • 提案手法: TST+SOL / REL+IFAとWGのマージや、WG間の仕様化手順の高速化
    • 参加者増加: 要検討
    • NFV仕様: Mainstream version (≒Long Term Support)の導入やOpen Sourceとより直接的な連携

O-RAN F2F@大阪会合サマリ

O-RANの公開仕様はこちら、少し古いがO-RAN全体像はO-RAN virtual Face To Face Meeting Februaryサマリ、SMOやO-Cloudの概要はNFV#40(2022年12月)@London & O-RAN F2F@Madrid(2022年10月)会合サマリを確認して頂きたい。

  • WG1:  Usecase and Overall architecture
    • Architecture Task Group (ATG)、Network Slicing Task Group (NSTG)、Use Case Task Group (UCTG)の3Groupで仕様化中
    • ATG: 大きな進展は無し(他WGとのドキュメントの一致化)
    • NSTG: SlicingのUsecaseやO-RANにおけるアーキテクチャについて仕様化
      • SMOがNear-RT RICとO1(SMO～VNF IF)で接続してVNFを監視
      • A1/E2はPolicyを制御するIFに変更
      • 複数のvDU/vCUを制御するためのマルチベンダポイントは3パターン
  • WG2: Non-real time RIC and AI IF
    • A1 (Non-RT RIC ～ Near-RT RIC): Test仕様まで完成 -> Slice系の拡張
      • Slice監視用のパラメータの追加
    • R1 (Non-RT RIC ～ rApp): IF仕様初版作成  -> 拡張中
      • A1 relatedにPlicy serviceの追加
      • AI/ML Workflow serviceの追加
      • Stage3としてKafkaの追加
  • WG3: Near-real time RIC and E2 IF
    • E2 (Near-RT RIC ～ vDU/vCU): Test仕様まで完了 -> メンテナンス中
      • BeamIdなどいくつかのParameterの追加
  • WG4: Open Front haul
    • Test仕様まで完了済 (Revision 7 ～ 11のためかなり安定)
  • WG5: Open F1/W1/E1/ X2/Xn IF
    • 3GPP仕様に対するO-RAN用Profile
    • F1, Xnのテスト仕様の3GPP仕様への追従＆O-RAN Profileの拡張
  • WG6: Cloudification and Orchestration
    • O2 (SMO ～ O-Cloud): O2dms/O2imsのテスト仕様まで完了
      • セキュリティ関連の仕様追加
    • AAL (vDU/vCU ～ Accelerator): Stage2まで完了
      • AALの設定までのStage2完了
  • WG7: White box Hardware
    • HW設計やDeployment ScenarioのStudy
      • セキュリティ関連の追加
  • WG8: Stack Reference
    • ソフトウェア設計とIOTテスト仕様作成
    • 進展なし？
  • WG9: Open X-haul Transport
    • Transport仕様とその管理仕様: テスト仕様まで完了
    • SliceのUsecaseとしてL2VPN/L3VPNを追加
  • WG10: OAM
    • O1 (SMO ～ vDU/vCU/O-RU): IFはほぼ完了
      • 3GPPやWG2/3/4/5の仕様へのReference
    • EMがSMOの内(O1はEM～VNF間) vs 外(O1はEM～OSS間)の議論開始
  • WG11: Security
    • IF: Test仕様まで完了
      • TLS, Certificate, OAuthの仕様
    • Functional Requirement: 各機能部へのTechnical Requirements
      • O-Cloud, Share O-RU, Near-RT RICのセキュリティ仕様の改版が完了
      • Risk Assessmentの初版完成
  • O-RAN - ETSI NFV Joint session
    • O-RANとNFVのGAP分析エリア
    • SMOとO-Cloudのマッピング
    • Accelerator(AAL)のマッピング


今回はNFVとO-RANのJoint sessionが開催され、NFVの仕様紹介やO-RANとのGAP分析を合同で議論した。基本的には策定済みの仕様は再利用していく方向にはなったが、O-RANも既に多数のドキュメントをPublish済のため今後どのようにドキュメントを整理していくのかまだまだ課題は多い。

コメント

コメントを投稿

このブログの人気の投稿

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