Sliceを管理するために必要な管理機能部

 5Gは大容量・低遅延・多デバイスという性能的な特徴の他に、目玉機能としてNetwork Slicingがある。しかし、Network Slicingが何者か、どのように機能分担が変わるのかの全容は今ひとつはっきりしない。総務省の『Network Slicingとは？』や3GPP TS28シリーズ(OAM系)、ETSI ZSM ISG (特にETSI GS ZSM 003) を中心にNetwork Slicingとその管理機能を読み解いてみたい。

Network Slicingとは何か？

本質的には、Software Defined Data Centerのように、インフラを何らかの技術(仮想化やVLAN+QoS等のIsolation technology)によって複数のネットワークに分割することだと思う。そのUsecaseとしてあげられている事は

  • SLAの違いによってネットワークを分離
    • 大容量 or 低遅延 or 高信頼性などの違いが挙げられている
  • 特定用途のためのLocal Area Network (Local 5G)
  • 複数オペレータによるインフラの共有
    • 特に基地局やBackboneのNWが候補のようだ
というのがあるようだ。問題は、これらの実現のためにどんな技術をつかうか？であるが、それが現在のところはっきりしていない。典型的なアイディアとしては、仮想化技術＋VPNの技術によって、モバイルのネットワークの装置(Network Function (NF))とそのネットワークを全て仮想的に独立したインスタンスとして用意するというアイディアがあるようだ。しかし、このアイディアの場合は、スライスの数だけ(仮想的とは言え)モバイルネットワーク装置(NF)を複数用意する必要があるため、リソースの分割損や、保守運用の複雑化、設備購入コストの増加などが想定され、短期的には利用しづらいかもしれない。

Network Slicingの管理機能部

詳細はETSI GS ZSM 003の5章＆6章をご確認頂きたいが、E2E Service Management Domainと各DomainのManagement Domainにより構成される。ZSMのドキュメントやNokiaの事例を踏まえても、典型的なDomainの分割例としては、基地局(NF)などのRadio Area Network (RAN)、BackboneなどのTransport  Network (TN)、交換機(NF)などのCore Network (CN)、Data  CenterなどのNFVとして分割されることが多そうだ。

Network Slicingの実現に向けては、これら各ドメインをNetwork Slice Selection Assistant Information (NSSAI)とそれを構成するSingle NSSAI (S-NSSAI)によって連携することで、一つのNetwork Slicingを作成・管理することになる。Sliceの管理にあたっては、主に4つの運用が定義されている。

  • ProvisioningまたはConfiguration Management (CM): Network Functionやネットワークの
  • Lifecycle Management (LCM): テンプレート＋設計情報を利用して、作成(Instantiate)〜更新(Heal/Scale/Update)〜削除(Terminate)を実施
  • Fault Management (FM): Alarmなどの障害管理
  • Performance Management (PM): リソースの使用率が各モバイルプロトコルの利用量などの性能管理

3GPP-SA5のTS 28.5xxを確認すると、5Gにおいては管理機能部がService Based Architecture (SBA)となっているため、各機能は“Service“として定義され、各Serviceと接続する場合はService Based Interface (SBI)を利用して接続するように規定されている。各ServiceのSetとして、3GPP-SA5では3つの機能ブロックを参考情報(Informative)として記載している。

  • Network Slice Management Function (NSMF): Slice管理機能
    • NSSAIや設計情報(Provisioning)を管理している
    • ZSMのE2E Service Management Domainが相当すると思われる
  • Network Slice Subnet Management Function (NSSMF): Sliceを構成するSlice Subnetの管理機能
    • S-NSSAIを管理しつつ、NFV-MANOを利用して仮想リソースの制御を行う。
    • ZSMのManagement  Domainが相当すると思われる。
    • 4GまでのNM (Network Management)やOSS (Operation Support System)相当の機能と思われる。
  • Network Function Management Function (NFMF): Network Function (NF)管理機能
    • 各NFのFMやPMを直接管理する
    • ZSMではManagement Domain内の一機能
    • 4GまでのEM (Element Manager)相当の機能と思われる。

これらをふまえて、RANの場合の構成と利用が想定されるインタフェース(IF)はこのようになるだろう。

この標準仕様を表に表すとこのようになる。
OAM機能 SBI NSMF -> NSSMF NSSMF -> NFMF NFMF -> NF NSSMF -> NFV-MANO
LCM/CMProvisionig Service
(TS 28.532) ※		 NSI mgmt
(TS 28.531)		NSSI mgmt
(TS 28.531)		 NS mgmt
(TS 28.526/527/528)
FMFault Supervision Service
(TS 28.532) ※		 NSI Alarm
(TS 28.545)		NSSI Alarm
(TS 28.545)		NF Alarm
(TS 28.545)		VNF FM
(TS 28.516/517/518)
PMPerformance assurance mgmt Service
(TS 28.532) ※		 NSI PM
(TS 28.550)		NSSI PM
(TS 28.550)		NF PM
(TS 28.550)		VNF PM
(TS 28.521/522/523)
Slice KPI
(TS 28.554)		 Traffic Item
(TS 28.552)
Test Heartbeat Service
(TS 28.532)		 Trace control
(TS 32.421/422)
Information File data Reporting Service
(TS 28.532)
※全体のデータモデルとしてNRM (TS 28.541)

5Gの管理機能部の特徴とO-RAN SMO

5Gになると、基本的にはCloudでの運用のように、NFのインスタンスを作成・削除(LCM)し、NFMFは基本的にPMやFMなどの監視情報を吸い上げるだけの構成をイメージしているようにも見える。しかし、Integration Reference PointsとしてEM相当の機能であるState管理やConfig管理も使えるOptionは残っている。

また、SBAの厄介なところは、3GPPの仕様としてはどの機能も全てのサービスを利用可能というところだろう。言い換えれば、実装しているサービスの製品の組み合わせとしては無数に存在するし、いくつかのサービスはNFが直接実装しているかもしれない。そのため、実際にSliceを管理する機能部を実現するための製品の組み合わせは無数に存在するかもしれない。

また、O-RAN WG10では、RANのSlicingに向けたSlicing管理機能の議論も始まっているようだ。私の分析では、RAN NSSMF + NFMF + NFVO (FOCOM) + VNFM (NSO) が現在のO-RAN SMOが仕様化したい範囲だと考えられる。しかしながら、NFMFとvRANのIFのはずのO1が、VESだけではなくTS 28シリーズを参照している点は理解に苦しむ。O1のScopeである旧EM〜 NF間IFはこれまで標準仕様化されたことがないが、今後O1は大幅に拡張され、旧EM〜NF間のIFの詳細も決まっていくのだろうか？

コメント

  1. Tanahashi2021年7月6日 18:00

    スライシングについて理解が進みました。ありがとうございます。
    ＞実際にSliceを管理する機能部を実現するための製品の組み合わせは無数に存在するかもしれない。

    のですね。

    返信削除
  2. Yuya Kuno2021年7月6日 23:21

    コメントありがとうございます。
    『REST指向での標準仕様設計方法』でも記載していますが、FlexibilityとInteroperabilityはトレードオフになることがおおいため、3GPP-SA5 28.5xx シリーズのようなSBAの仕様ですとFlexibilityが強する気がします。その結果、実装オプションとその組み合わせは様々なバリエーションが生じてしまうかと感じています。

    返信削除

コメントを投稿

このブログの人気の投稿

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

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

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