O-RAN virtual Face To Face Meeting Februaryサマリ

2月にO-RANのvirtual Face To Face (vF2F)が開催された。少し遅くなってしまったが、その時の結果をまとめたい。O-RANにはPlenary(全員参加の総会)やvF2Fのレポートのようなものが無いので全体の進捗が非常に把握しにくいが、出来上がった仕様と議論状況の断片からまとめていってみたい。仮想化が検討されている基地局の構造については何故O-RANで基地局のコンテナ化が騒がれているのか？を参照頂きたい。

O-RANの位置付けの変化

元々O-RAN (Open Radio Access Network)とは何かというと、O-RANが盛り上がってきたにも記述しているとおり、3GPPではブラックボックスとなっているDU〜RU間のFront Haulを分離してOpen化するために、AT＆Tやチャイナモバイル、NTTドコモが発起人として立ち上げたアライアンスである。当時の経緯にや狙いについてはケータイWatch『O-RANとは』を参照して頂きたい。O-RANでは主に以下の3つを目的として様々な機能部やIFを定義している。

  • Open化 ＝ RU〜DUのインタフェース制定
  • Intelligence化 ＝ RAN Intelligence Controller(RIC)の導入
  • Virtualization ＝ CU＆DUの仮想化と仮想化基盤(O-Cloud)の導入

元々アライアンスという性質のせいか、O-RANの議論も仕様もCloseな側面が大きかった。それが2021年秋以降にOpenな団体に変化するために、O-RANの中で”Confidential”と”Non-Confidential“が明確に分離され、原則Technical Contribution(実際の仕様の提案)やMeeting Noteなどは”Non-Confidential”に分類されるようになった。本BlogでもO-RANの記述が出来るようになった背景はこのような位置付けの変化が大きい。

また、幾つかのO-RANの仕様はETSIに移管されるようだ。現状はOpen Front HaulのCUSという仕様がETSIの仕様として修正しているように見える。他の仕様が今後どうなるかは不明だが、今後も標準仕様として各Productが守らなくてはいけない仕様はETSIに移管される可能性は高いだろう。

各WGの全体像

O-RAN virtual Face To Face Meeting Juneサマリでは、O-RANに関連するGroupとして、10WG、6Focus Group/Committee、1Communityがあった。現在は10WG、7Forcus Group/Committee、1Communityがある。MVP-CがO-RAN全体でリリースすべき機能を定義・管理し、各WGがそれぞれの範囲を仕様化していくような構成となっている。

  • MVP-C (Minimum Viable Product Committee): O-RAN全体で提供する機能の管理グループで、実仕様は各WGに提案していくグループ(NFVのFeatureと似ている考え方？)
    • SMO Phase1: SMOの基本機能としてFM (Fault Management) / PM (Performance Management) / xApp & rAppのLCMなどの機能定義
    • RAN analytics information exposure Phase1: 3GPP SA2 TR 23.748 / TS 23.548 / ETSI GR MEC 031をベースとしたMEC向けのQoE維持のためにMEP (MEC Platform)とRICを接続
    • Security Phase1: RIC / Open Front Haul / O-Cloudの脅威分析〜要件〜仕様〜テスト仕様の一式
    • RAN Slicing Phase2: Phase1としてはRANのSlicingとはVLANベースでQoSを分離する概念をWG2/5/6で合意されたため、Phase2としてWG1〜10の全て(End To End)でNW観点ではSLAを分離できるように仕様化
    • Shared O-RU Phase1: 1つのO-RUに複数のvDUを接続 (接続パターンはvDUだけ分離するもの〜SMOも含めて全部分離するものまである)
    • Massive MIMO Optimization Phase1: RICを利用したMassive MIMOの最適化
  • WG1 (Usecase and overall architecture): SMOの全体Usecaseとアーキテクチャを策定
    • O-RANとしての基本UsecaseとArchitectureはRelease 2まで定義済
  • WG2 (Non-Realtime RIC and A1): Non-RT RICの仕様策定しており、A1 IFを中心にStage3まで完了
    • Non-RT RIC: Stage1 (Architecture)
    • A1 IF: Stage1(GAP&Usecase)〜Stage2(A1 interface&Type Definition)〜Stage3(Transport Protocol)
    • rAPP: AI&MLのStage1 (Workflow description)
      • rAPP系はまだまだこれから
  • WG3 (Near-Realtime RIC and E2): E2を中心にStage3まで完了
    • Near-RT RIC: Stage1 (Architecture)
    • E2 IF: Stage1 (GAP)〜Stage2(E2 Service Model)〜Stage3(Application Protocol)
    • xApp: Stage 2 ?(Package)
  • WG4 (Open Front haul): O-RU〜DU間IFとして既に仕様が安定し、Stage4(Test仕様)まで完了
    • C-Plane: Stage3(CUS-plane & CTI TC-plane)〜Stage4(Conformance & IOT)
    • U-Plane: Stage3(CUS-plane)〜Stage4(Conformance & IOT)
    • M-Plane: Stage3(M-plane & Yang Model & CTI TM-plane)〜Stage4(Conformance & IOT)
    • S-Plane: Stage3(CUS-plane)〜Stage4(Conformance & IOT)
  • WG5 (F1/W1/E1/X2/Xn): 3GPPの仕様をベースO-DU/O-CU周辺のIFのO-RAN Profileを作成しており、Stage4(Test仕様)まで完了
    • DU O1: stage3(O1 interface for O-DU)
    • CU O1: stage3(O1 interface for O-CU-UP and O-CU-CP)
    • F1/W1/E1/X2/Xn: stage 3(NR U-Plane profile & NR C-Plane profile)〜stage4 (IOT)
  • WG6 (Cloudification and Orchestration): O-Cloudの仕様を策定中だが、Stage1を少しずつ拡張中
    • O2 IMS: Study(CAD)〜Stage1(GAP & Usecase)〜Stage2&3(O2 IMS spec & O2 notification)〜
    • O2 DMS: Study(CAD)〜Stage1(O2 GAP & Usecase)〜Stage2(TBD)〜Stage3(NFV profile vs native K8s profile)
    • AAL: Stage1(AAL GAP)〜Stage2&3(FEC profile & Hi-Phy profile)
  • WG7 (White-box hardware): Goalが分からないが様々なHWデザイン仕様をリリース中
    • Stage1(Deployment Scenario and Base Station Class)〜Stage2(Hardware Architecture Micro Cell & Macrocell)〜Stage3(Indoor Picocell (FR1) & Outdoor Microcell & Fronthaul Gateway)
  • WG8 (Stack Reference design): Goalが分からないがStage4(Test仕様)まで完了
    • Stage1&2(O-DU and O-CU Architecture and API)〜Stage4(IOT)
  • WG9 (Open X-haul): 既存仕様をベースに安定しており、一部はStage4(Test仕様)まで完了
    • OAM: Stage1(X-Transport Requiremnet)〜Stage2(Management interface)〜Stage3(WDM-based Fronthaul Networks)
    • U-plane: Stage1(X-Transport Requiremnet)〜Stage2(Switch Architecture)〜Stage3(WDM-based Fronthaul Networks & Management interface)〜Stage4(IOT)
    • S-plane: Stage1(X-Transport Requiremnet)〜Stage2(Synchronization Architecture)〜Stage3(WDM-based Fronthaul Networks)〜Stage4(IOT)
  • WG10 (OAM for O-RAN): WG1で検討中だったInformation Model (IM)やData Model(DM)を利用しながらSMOのアーキテクチャを検討中であり、関連仕様を最大限活用して仕様作成中
    • Stage1(O&M Architecture)〜Stage2(IM and DM)〜Stage3(O1 interface)
  • OSFG (Open Source Focus Group): O-RAN SCがメインのためほぼ活動なし。
  • SDFG (Standard Development Focus Group): ほぼ活動なし。
  • TIFG (Test and Integration Focus Group): 各種PlugtestやそのためのTest仕様を作成中
  • SFG (Security Focus Group): 各IFのSecurityチェック
  • TSC (Technical Steering Committee): 全体のWIやEventなどの進捗管理
  • ACOP (Ad-hoc Committee for O-RAN Procedures): O-RANの標準化手続きの整理
  • DTF (Drafting Rules Task Force): ドキュメントの記載ルールの整理
  • O-RAN SC (Software Community): Linux Foundation配下のO-RAN仕様をベースとしたOpen  Sourcce団体

本会合での進捗

  • MVP-C (Minimum Viable Product Committee): 初版のターゲット検討中のフェーズ
    • Releaseという概念の導入 (継続議論中)
      • Release1: 2021 March Train (2021/3月)までのバラバラな仕様一式
      • Release2: 2021 Nov Train (2021/11月)までのRICを中心としたQoS/QoEやSlicingの仕様一式
      • Release3: 2022 July Train (2022/7月)までのFeature Packageを含んだ仕様一式
    • Operator Survey: 主要Operator向けアンケートの結果発表
      • Deployment Scenario: 屋内のSmall Cellと屋外のMassive MIMOから始まり、最終的にはMacro Cellまで拡張 → 一方でIOT向けのPrivate Networkは直近2年程度では予定な史
      • O-RANで利用予定の仕様は直近はOpen Front Haulであり、その後1年以上経ってからRICやO-Cloudの導入を考えている模様
      • Feature Packageは数年以内に導入を希望しており、更に省電力のニーズが高い → SON/V2X向けHO/屋内の高精度位置情報/UAV(ドローン)のようなものはあまり導入予定なし
  • WG1 (Usecase and overall architecture): SMOのアーキテクチャ再定義議論
    • MVPのFeature Package実現に向けたアーキテクチャ＆Usecaseの更新
      • Slicing系のアーキテクチャ更新
      • Shared O-RUのUsecase追加
      • RAN analytics information exposureのUsecase追加
      • Massive MIMO最適化のUsecase更新
    • SMOの分離の提案＆議論中
      • Non-RT RIC
      • RAN O&M
      • Cloud Orchestration
      • Others
    • Topology viewの追加
      • 現時点ではO-RANと既存装置との混在(ブラウンフィールド)におけるネットワークトポロジー(物理/論理/サービス/model)のように見えるが、詳細不明
  • WG2 (Non-Realtime RIC and A1): Non-RT RICのアーキテクチャを変更する議論が中心。A1等のインタフェース議論はあまりなかった模様。
    • rAPPはどのようにその他IFの情報(O1やO2等)を取得するか？について議論
      • SBAとしてどのIFも利用可 vs rAPP向けの新規IF作成 
    • Slicing実現に向けたrAPPの要件検討
    • Configの管理方法議論
  • WG3 (Near-Realtime RIC and E2): Massive MIMOのWI検討。
    • Massive MIMO最適化に向けたWork Item提案
    • E2 IFの拡張＆改版
  • WG4 (Open Front haul):Shared O-RUの対応議論開始。
    • M-Plane: Beam Formingの管理 / Software管理 / Historical Alarmの管理
    • S-Plane: ETSI向けの仕様化 
    • Conformance Test: 3GPPのTest仕様の取込み
    • Interoperability Test (IOT): IPv6やTLSのTest仕様
    • Shared O-RU: Teantや周波数の管理方法議論
  • WG5 (F1/W1/E1/X2/Xn): WG4仕様と3GPP仕様のGAP穴埋めに苦労中。
    • IOT: 3GPP Test仕様の取込み(特にWG4のO-RUは3GPP仕様にないためどうテストするか？)とTest Caseの拡張
    • O1: Trace管理の追加
    • Shared O-RUやSlicingについて議論開始
  • WG6 (Cloudification and Orchestration): Stage1を少しずつ拡張中
    • WG10と連携したFM/PMのStage2化
    • O2dmsのNFV Profileとnative K8s profileの進め方推進
      • NFV ProfileはSOL003を参照する方向
    • AALはAccleration Managerを利用したO1とO2によるAcceleratorの設定や管理方法のProcedure議論
    • O-CloudのNW(WG6)とTN(WG10)のNWの責任分解点の議論
  • WG7 (White-box hardware): その他のタイプのHWデザイン仕様を検討中
    • Outdoor Macrocellの追加議論中
  • WG8 (Stack Reference design): ほぼ活動なし。
    • AAL/Massive MIMOの影響確認
  • WG9 (Open X-haul):Slicing実現に向けて拡張中
    • PTPの対応やITU-Tとの一致化
    • Slicingの実現方法
  • WG10 (OAM for O-RAN): APP Packageを中心にSMOにとってどんな管理情報が必要か議論中
    • APP PackageとしてAPLのConfig/Alarm Dictionary/Performance Dictionary/VNFD/AI用学習データをどうPackage化するかの議論
    • WG3/WG4/WG5/WG6と連携したDictionaryの管理方法
  • TIFG (Test and Integration Focus Group): 2021年のPlugtestのまとめと2022年のPlugtestの計画。
  • SFG (Security Focus Group): 各IFのコメント＋ETSI GS NFV IFA026のSecurity Managerを導入する案を検討。
  • TSC (Technical Steering Committee): Event系のUpdate
  • ACOP (Ad-hoc Committee for O-RAN Procedures): Wikiの書き方議論
  • DTF (Drafting Rules Task Force): 不明
  • O-RAN SC (Software Community): F Realseに向けて、OpenStack Tackerの取込みとRICの改造をアナウンス。

コメント

コメントを投稿

このブログの人気の投稿

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