NFV#36 (2021年12月)会合サマリとO-RAN WG6 November trainのサマリ

 今回のNFV#36(12/1〜10)もコロナの影響でeMeeting (電話会議)となった。今回はNFV-Workshopのようなイベントは無かったようだが、いくつかの仕様検討は大きく進んだ。最新のNFV仕様の全体像はこちら(ETSI-NFVのOpen area)で、前回NFV会合の説明や現在のNFVのリリース機能の状況はNFV中間会合(10月)サマリを確認して頂きたい。

NFV#36のサマリ

NFV#35やNFV中間会合(10月)と比較した重要な活動結果としては、
  • Release3のed361がFinalize Review (12月Finalize/1月Publish)となりFEAT03(NFVI Upgrade)がサポートされるようになる。
  • Release4のNormative WIとしてPaaS (特にOAM系)、MDA(Machine Learning)、Intent mgmtが提案された。
  • Release5のNew Work ItemのVNF Configuration、NFV for vRAN、Fault ModelのUsecaseが概ねで揃ってきた。
会合参加者の目線からすると、開発で注目されている技術や各標準化団体の境界案件のような重要な案件の進捗はeMeetingが続いたことでどんどん遅くなってきている。ロビー活動ができないことで、様々な他社案件に対して疑心暗鬼になったり警戒してしまったりして、協力し合うという空気感が薄くなってきているように感じる。また、もう一つ大きな問題として、ETSI-NFVの認知度向上やベンダを含めた製品化を牽引してきたような重要メンバーが高齢化し引退を始めている。これまでにNSDやVLのInformation Modelの設計を牽引したHPEのMarc氏、ETSI-NFVのアピールに貢献したCable LabのDon氏が引退し、そして今回ETSI-NFV NOCの重要メンバーでありZSMのChairも務めたKlaus氏が引退を表明した。今後年齢的にETSI-ISG ChiarのBruno氏、NOC ChairのDiego氏も引退話が出始めるかもしれない。

Release3：LCMの高度化

IFA&SOLの第3版(ed361)のCRが全て承認されFinal Reviewになった。
  • FEAT03 NFVI Upgradeが完成した。
    • IFAによるとNFVI Upgradeの方式は大きく以下のような順序で行う。VIMがNFVI Upgradeのマスターとなり、EMがそのメンテナス情報を受け取って対処するという考え方である。
      1. 事前に各VRのメンテナンス時の通知条件をPolicyで登録しておく (Rel3のScope外)
      2.  VIMの独自ソリューションでNFVIをUpgradeする (現NFVのScope外であり実装依存)
      3. NFVIをダウンさせる前に、1で登録したPolicy条件に基づいてVNFMにVR Change Notification(IFA006)でメンテナンス情報を通知する (Rel3にてサービス停止予定時間等のメンテナンス関連の付加情報が追加)。VNFMはVIMから受け取ったVR Change Notificationをベースに、EMにAlarmでメンテナンス情報を通知 (Rel3にて3と連動した付加情報が追加)
      4. EMはメンテナンス情報をベースにAPLレベルの制御や、VNF LCM制御、Policyの変更などを実施 (現FEAT03ではPolicyの変更は未定義)
    • SOL014においてVirtual Resource (VR) Change Notificaiton (NFVIをMaintenanceするときにVIMからVR単位でMaintenanceの信号)とAlarm Notification (仮想リソースの障害情報)をサポートするように仕様を拡大した。参照実装としてはAodhを利用し、VR Change NotificationとAlarm NotificationのSubscriptionをそれぞれ行うことで、Notificationを識別することを想定しているようだ。
    • SOL002において、Alarmが拡張され、Fault typeにNFVI_OAM_VIRTUALIZED_RESOURCE_STATE_CHANGEが追加され、メンテナンス関連の情報が追加された。Faultの中身はRel5 IFA045で仕様化予定。
    • VIMに設定するPolicy Contentや、EMからのPolicy変更などはRel3の対象外。Rel4でPolicy Content (IFA042をベースとしたNormative仕様)で仕様化予定。
  • Rel3 の最後の大きな仕様WIMのNorth Bound Interface (NBI)はIETF ACTNベースでSOL019としてWIが開始
    • SOL017(WIMのNBIのプロトコル評価のレポート)はNECがRapporteurだったが、SOL019(WIM NBIのstage 3)はHuaweiとなった
  • ExtCpを利用したIPアドレスの付与方法について、課題提起あり
    • ExternallyManagedVirtualLinkの識別ができなかった仕様について、VNFDに識別子externally_managedを追加。
    • IPアドレスの付与を誰が行うかについて不明瞭だったため、どこから付与されるかのip_address_assignment_subtypeをVNFDに追加。
    • MacAddressも同じような付与元の明確化を拡張する予定だったが、IPアドレスとは特徴が異なるため3.7.1へ延期。
  • SOL016はSOL014の取り込みとSnapshotのシーケンス拡張をしたが、完成に至らず3.7.1 (2022年春)に延期となった。

Release 4：コンテナ対応

NFV#36はRelease3のFinalizeを優先したため、Release4の進捗は限定的だった。
  • IFA036 CCM IFについてはEditor‘s Note(仕様が不完全な残課題)を解消したが、SOL018はあまり進捗しなかった。
  • SOL001はコンテナを収容するための拡張が概ね完了し、現在は既存IF (SOL002/003/005)の拡張中である。最新のSOL003の提案を見る限り、
    • PodはResourceHandleにマッピングされ、CISMの管理情報がマスターになる方向。
    • DeploymentはMcioInfoにマッピングされ、VNFMが管理情報のマスターになる方向。
  • IFA041 Autonomous mgmtに従ったMDA(Management Data Analytics)の新規IFをHuaweiが提案。
  • IFA041 Intent mgmtに従った新規IFをCMCCが提案。詳細は「仮想化と監視運用自動化」を参照。
  • IFA042 Policy Modelに従った新規Policy contentをCMCCが提案。ONAP APEXとPolicy FrameworkをECA(Event Condition Action)ベースでテレコム向けに再定義。
    • かなり細かいレベルでErro-handlingも記述することを要求しているので、ETSI-NFVで拡張仕様を決めることになるのだろう。
  • EVE019 (Generic OAM) + IFA029 (Common Function) = PaaSとして、NFV-MANOでPaaS基盤を提供するWIをドコモが提案。
  • Enh01.01としてCertificate  Mgmtが追加されることになり、Operator Certificate Enrollment Function (OCEF ≒ CA局から証明書を配信するPKI相当)のStage2に向けたDiscussionあり。
    • ( mTLSやOAuthのClient認証で使う)各APIのEnd Pointに利用するCertificateの配布は、各機能部(VNF/NFV-MANO)が既存プロトコルを最大限に利用して自ら証明書を入手する
    • 一方で、OCMFが提供したCertificateが、各機能部にとって信用できる証明書であることを識別するためにCertificate Chain(該当Certificateを発行した上位認証局のCertificate)を配る必要がある。現状はCertificate Chainを的確に配布するロジックや標準仕様はないため、実質同一ベンダのOCMF(CAやPKI)内でしかCertificate Chinを配ることは難しかった。


Release5: NFV適応ドメイン拡張

Release5はStudyのUsecaseが進んできた。元々「NFV＃34の会合サマリ」でも記載した通り、Release5はAPLレイヤの制御支援による自動化と、NFVで利用可能なドメインの拡張が主な方向性であり、少しずつ課題が見えてきたようだ。
  • IFA043 Enhanced container network: IFA038の後継でテレコムのNW条件を考慮したContainer  NWの拡張。本会合では進展なし。
  • IFA044 Flexible deployment: ”Deployment Flavour”によるStaticなScaleの仕様からコンテナの特徴を活かしたよりDynamicなScaleを行う方法。目次(ToC)がかなり固まってきた。
  • IFA045 Fault Model: Alarmの中身の規定。Computeをベースに、どんな障害を誰がどのように変換するかの基本Usecaseが少しまとまってきた。
  • IFA046 NFV for RAN: O-RAN仕様のGAP分析として、O-RAN WG1やWG6のドキュメントのうち、UsecaseレベルでNFV仕様とのGAP分析の全体像が記述。
  • EVE021 Green NFV: 省電力に向けた高度なPolicy制御やSmall Setの機能定義。本会合ではあまり進展なし。
  • EVE022 VNF Configuration: VNFに関するConfigurationの設定ルート。こちらも既存のConfigurationルートは概ねUsecaseが揃ってきた。

O-RAN WG6 November train

9月のO-RAN会合がEntity Listの影響でキャンセルになってから少し動きが見えにくくなっていたが、現在はO-RANの規定がCloseな規約からOpenな規約に変えたことでEntity Listの影響を受けない規定になり、主要企業含めて無事活動を再開している。今回はWG6関連のNovember Trainの状況について簡単にまとめたい

  • ドキュメント体系の見直し: ドキュメント間の関係が不透明だったO-RAN WG6のドキュメントについて、3 Stage法によって各ドキュメントの仕様を継承するように改善中
    • General Aspect and Principle (GA & P): Stage 1相当として基本概念や機能の説明を行う。
    • Orchestration Usecase: Stage1〜2として、実現したいことからインフォメーションフローを記載し、各機能やIFの要件を抽出する。
    • Interface: Stage3として、Information ModelやData Model、Protocolを定義する。
  • O2 GA&P: 特に新しい定義は無いが、各機能部の定義がそれぞれUsecaseやInterfaceに合わせて改良された。
    • O-Cloud: O-Cloud Node(Compute/Network/Storage相当) 、Workload(VMとPod相当)、Resource Pool(NFVI-Pop/Zone Group/Zone相当)などの定義が見直され、DMS(Workloadの管理)とIMS(O-Cloud NodeとResource Poolの管理)の役割がもう少し明確になった。
    • Provisioning: NFVのVNF LCM (O2dms)、CIS ClusterのLCM(O2ims)
    • Fault Mgmt: Alarm (SMOに通知しActionが必要な障害)とFault(全ての障害全般)の定義。
    • Performance Mgmt: Metrics(測定項目)やMeasurement(測定値)の定義。
  • Orchestration Usecase: PMのUsecaseが追加された。
    • O-Cloud LCM: O-Cloudの構築〜Upgrade〜撤去
    • NF Deployment: VNF LCM相当(ただしHealingは現状なし)
    • xApp LCM: RIC platform上のAPLのLCM
    • Recovery: O-Cloud NodeやNF DeploymentのReset
    • Fault Mgmt (IMS): O-Cloud NodeのAlarmに対するSubscription〜Notify〜Query〜Syncrhonization
    • Performance Mgmt (IMS): O-Cloud NodeのPerfurmance取得〜通知/Queryなど
  • O2 IMS interface:: FMを‘入れようとしたがMarchに延期
    • O-Cloudベンダが用意するAlarm DictionaryをベースにAlarmを定義しようとし、Alarmの意味をSMOが分からなくて意味があるの化？という点から371に延期。
  • AAL GA&P: HW  Accelerator (FPGAやGPU等のデバイス)、HW  Accelerator Manager (Operator frameworkなど)、AAL  Profile (HW Accelerator上で動作するプログラムであり、GPUならCUDA)、AAL (AAL ProfileとNF Deployment間のIF)などの定義と、無線で必要なアクセラレータの種類を定義
  • AAL FEC: FECのAAL ProfileとHW Accelerator デバイスの検出のAPI定義
  • AAL High-Phy: High-PhyのAAL Profile

次回はO-RAN仕様全体を通して、IFA046での分析ポイントをまとめてみたい。

コメント

コメントを投稿

このブログの人気の投稿

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