英語が苦手でもグローバル人材を目指して

そもそもプログラムって何？ に対して、"仮想化したときに結局ハイパーバイザー が何をしているか分からない”というコメントを頂いたので、仮想化やコンテナについて追加で執筆したい。なるべく仮想化の全体概要や分かりやすさを重視して説明してみたい。 1. 仮想化されるとプログラム的に何が変わるか？  仮想化とは、エミュレート機能を使って物理ハードウェアを”仮想的に”実現する(Virtual Machine)仕組みである。そのため、OSやプログラムから見ると、普通の物理ハードウェア上に動作しているように見える。 Hypervisorの導入によってできるようになること Hypervisorによってエミュレートすることで、仮想化された環境では3つの機能が追加される。 ハードウェア機能の 抽象化 /互換性 ハードウェアの各種機能をHypervisorがエミュレートすることで、OSやプログラムはハードウェアの変更や機能差分の影響を受けなくなる。 その結果として、ハードウェアが進化したとしても、古いOSやプログラムを継続的に利用できるようになる。 プログラム間の 分離 HypervisorがVM間のアクセスを抑止することで、1つの物理ハードウェア上に複数の環境を用意することができる。 その結果、全く利用用途の異なるプログラムや、セキュリティの観点で同居させづらかったシステムを同一サーバで運用できるようになる。 プログラム及び必要なリソース一式の カプセル化 Hypervisorはエミュレート対象のOS、プログラム、仮想CPU/メモリ/NIC/ファイルシステムの一式を ファイル として扱うことができる。 その結果、仮想化された環境の ファイル の管理だけで保守や運用が可能となる。 Hypervisorのお仕事 Hypervisorの種類や設定によって、Hypervisorが具体的に行う仕事の範囲は異なるが、基本的には ハードウェア機能のエミュレート(qemu) VM内のメモリの論理アドレスと実際に格納されている物理メモリのアドレスの変換(メモリマッピングorメモリエミュレータ) の2つが主な仕事となる。ここでは一例としてKVM + qemuを例に説明する。        エミュレートする範囲によって、qemuタイプ、kqemuタイプ、kvm...

最近の標準化ではREST指向を採用されているケースが多い。ETSI NFVもO-RANもどちらもREST指向で標準仕様を制定している。最近の標準化の世界では、SBAというのも流行している。本日は、REST指向での標準仕様設計の現場を紹介したい。 テレコム系の標準化における設計方法 標準化の一番の目的は、 異なる装置間を接続するため(interoperability) の仕様を制定することであり、多種多様な装置を接続できる仕様が良い標準仕様と言われている。良い標準仕様を円滑に制定するために、テレコム系の標準化ではITUの I.130 に定義されている3 Stage法を採用しているケースが多い。 Stage1: UsecaseやFunctional Requirementを合意する。Goalと前提条件を定義し、そのGoalに向けた手順(Procedure)を定義したり、各機能部の要求条件を記載することが多い。ETSI NFVではIFA010が該当する。 Stage2: Stage1のFunctional Requirementを元に、Information flow(シーケンス)や各機能部間でやり取りするキーパラメータを定義する。ETSI NFVではIFA010を除く多くのGS IFAがStage2に該当する。 Stage3: Stage2のキーパラメータをやり取りするためのプロトコルを定義する。ETSI NFVではSOLがStage3に該当する。 Stage4: 最近ETSI NFV等の団体ではテスト仕様を(非公式に)Stage4と呼んだりするようだ。Stage2やStage3をテストするためのテスト仕様を定義する。ETSI NFVではTSTがStage4に該当する。 Stage1やStage2によって様々な特徴の装置の要件を集めることになるが、一般的に”装置間を接続するための標準仕様”として実際の開発で利用する仕様はStage3が多いだろう。 何故今RESTか？ IT業界では、サービスの継続期間が短く、数日〜数カ月でサービスの入れ替わりが起きる。そのため、なるべく疎な結合(他の機能やコンポーネントに影響を与えない)により、既存の機能やコンポーネント、サービスを再利用しやすいように設計する必要がある。その中で、RESTはWebの世界では相性が良かったようだ。 過去の設...

今回のNFV#34は、Telecom TVと合同のNFV-Workshopと、NFV-Tacker Workshopという外部団体の連携が特徴的だった。最新のNFV仕様の全体像は こちら (ETSI-NFVのOpen area)で、NFV会合の説明は過去のBlog NFV33の会合サマリ を確認して頂きたい。 NFV#34のサマリ NFV#33と比較した重要な活動結果としては Release3についてはSOLの第2版(ed351)もTST010の初版(ed331)もリリースされなかったので、大きな進捗はなかったようだ。 3GPPとMANOで連携しながら高度なVNFの制御を可能にするLcmCoordinataionは次回に繰り越しのようだ。 Rel3のSOL API(ed331)に対応するTST010が発行されていないので、Robot Frameworkの自動テスト環境はまだまだ構築ができないだろう。 Release4はIFAの第2版(ed421)が凍結(Finalize)され、最低限のコンテナ制御のAPIとデータモデルはStage2レベルでは揃うだろう。 IFA036(Cluster管理)やIFA038(コンテナネットワーク)が終わっていないので、どのレベルでマルチベンダ可能かは不明。現時点ではVNF/CISM(コンテナ基盤)/VNFMは一体型が現実的かもしれない Stage3は過去のバージョンを見ても半年以上はかかるので、早くてもRelease 4のStage3の初版は年末だろう。 NFV Workshop を見る限り、ETSI-NFVはRelease5を検討しているらしい。プレゼン内容を踏まえると、考えられるRelease5の方向性は以下のあたりだろう。特にVNFのConfigurationやPaaSはRelease5の目玉機能になるかもしれない。 仮想リソースレイヤ→VNFレイヤへ コアネットワーク→MECやRANの領域へ デジュール(標準仕様) vs デファクト(実装先行) → Open Sourceと標準化の融合へ NFV-Workshop 今回NFV-WorksohpはHuaweiがスポンサーとなり、Telecom TV(ヨーロッパの特定分野のテレビ局)と合同で開催された。 NFV開発＆運用のフィードバックのプレゼン DOCOMO: 2G/3G/4GのP...

今日は実際にETSI NFVやヨーロッパ系の企業の人とどのようなビジネスコミュニケーションツールを利用しているか紹介したい。国や企業、時期によっても変わると思うので、これは一例と考えて欲しい。 ビジネスコミュニケーション上の基本ツール やはり基本的なビジネスコミュニケーションツールは Microsoft Teams だと思う。国や企業にもよるのだろうが、今お付き合いしている企業や団体は比較的少人数(10人以下)のPJチームで作業することが多いようで、Outlookのスケジューラーでスケジュールを管理し、OneNoteで課題管理や作業録を管理しているようだ。 電話会議はWebEX、GoToMeeting、Business Skypeを利用しているように感じる。日本国内ではZoomを利用することが多いが、ヨーロッパ系の企業でZoomを求められることは少ない気がする。 生産物作成 逆に生産物作成は、複数のPJチームが合同で同一の文書やドキュメントを操作するため、大人数でも合同編集できるツールを利用していることが多い。 ETSI ETSIは基本的にMicrsoft Wordで作業をしている。仕様提案者(Contributor)はWordの編集履歴付で提案し、編集者(Rapporteur)が人手でマージしている。会議のAgendaやReportも全て議長がWordで作成している。連絡方法はメールであり、Web会議はGoToMeetingを利用している。 最近では、一部のドキュメントはWikiやGitHubも利用し始めているが、メインはまだまだWordだ。 O-RAN O-RANではConfluenceを利用しており、会議のAgendaやReportはConfluenceのWikiを利用している。ドキュメントはMicrosoft Wordで作成している。 OpenStack Open Source系であるOpenStackではGitHubを利用している。情報共有方法はIRCとLaunchPadを利用しているようだ。 個人での連絡方法 メインのSNSはLinkedInが多いだろう。名刺交換(Businesses Card)はあまり行われず、LinkedInで検索することが多い気がする。LinkedInのアカウント作成は必須だろう。 ヨーロッパの方ではチャットツールとしては、Sig...

 4/19からNFV Release5の NFV Workshop が開催されるようだ。今回はオンラインでの開催となり、4/19〜21において こちら から閲覧可能になるようだ。メールアドレス、名前、会社名を入力すると、メールアドレスに1タイムの視聴用URLが送られてくる。本日は、英語が話せない人にとって英語でのプレゼンをどのように準備するかと、NFVのReleaseとは何かについてお話ししたい。 英語ができないのに英語のプレゼン？ 英語ができない人にとっても、実は英語のプレゼンは可能だ。英語が苦手な人にとって英語での発表の場は、恐らく以下のような順番の難易度になるだろう。 Presenter：プレゼンはまさに自分の経験を多くのリスナーに向けて説明する発表形態である。大切なことは「何をメッセージとして伝えるか？」と、「どのようなストーリーでそれを表現するか？」であり、実は英語の力はそれほど関係ない。 Paneler：Panelは数名の人が司会者の議事進行に従って自分の意見を伝える発表形態である。Panelには、事前にテーマを与えられていて当日それを資料無しで説明するタイプと、事前テーマがほぼなく当日アドリブで話す必要があるタイプの2種類がある。事前にテーマが与えられている場合はプレゼンに近いが、事前テーマがない場合は当日質問内容を理解することと、自分のメッセージを英語化することの2つの力が必要になる。 Moderator：Panelなどで司会をすることである。Moderatorは、深い知識、機転の効いたお題の提示やPanelerの話のサマリ化、そしてそれらを支える高度な英語スキルが必要になる。英語が苦手な人はModeratorは不可能だろう。 英語に限らず、何かを発表する場合は、この「メッセージ」と「ストーリー」が必要である。Presenterの場合は、このメッセージとストーリーを沢山の人に聞いて貰って、より具体的で、余計な説明の無い、流れるようなお話に改善すれば良い。つまり、プレゼンする場合の必要なスキルは英語ではないのだ。 私の場合、まずはこの資料と口頭で話す説明(カンペ)を日本語で準備し、色々な人に聞いてもらって、メッセージとストーリーを固めた。その後、翻訳ツールを使って資料とカンペを英語化する。今度はそれを英語の得意な人に聞いて貰って、英語として自然...

通信業界でも、最近はVMからコンテナに話題が移っているようだ。昨年あたりから 楽天 、 Verizon 、 VMware 、 Samsung と様々な企業が5Gとコンテナについて発表を始めている。何故今通信業界でコンテナが騒がれているのだろうか？5Gとどんな関係があるのだろうか？ 5Gの3GPP仕様にコンテナを想起させる仕様が多々ある 5Gのコアネットワークの基本標準仕様である TS23.501 において、REST、Service Communication Proxy(SCP)、Statelessなどコンテナを利用することを明らかに想定した仕様が多々ある。これらが“5Gはコンテナベース“と通信業界で騒がれている理由の一つかもしれない。 SCPとコンテナの関係 TS23.501のAnnex GにSCPの実装例の記載がある。こちらにはService MeshやService Agent、Ingress/Egress Proxyと、明らかにIstioを想定していると思われる仕様がある。TS23.501では、SCPはIndirect Communicationとしてオプション扱い(必ずしも必須の仕様ではない)が、ここまで詳細に記載があると、実際の開発においてベンダはIstioを使いたくなるだろう。 また、Istioを使う場合、Sidecarとして同一PodにIstioのAgentをデプロイする必要があるが、Sidecarをどのように提供するかが不明瞭な現在では、ベンダ戦略の一つ(コンテナとコンテナ基盤を同一ベンダで提供する)としてIstioを使うのかもしれない。5Gをどのようにデプロイすることがデファクトになっていくかは引き続き注視が必要だろう。 Statelessとコンテナの関係 通信系装置は、端末の位置や契約条件に基づくサービス利用条件、接続先トポロジーを覚えておく必要があるためどうしてもStatefulな作りになってしまうため、コンテナでの実装が難しかった。しかし、TS23.501の5.21章を見ると、仮想化に伴ってStalessを志向しており、UDRとUDSFにストレージ機能を置くことで、他の機能部はStatelessとなっている。こちらもコンテナを想定しているようであり、コンテナの実装が容易となるような仕様になっている。 とはいえ、実際の商用の運用を考えると、U...

 筆者が一番苦労した時間が、ディナーとその時の世間話だ。 日本の飲み会とディナーの違い 日本の場合、夜一緒に夕食を食べに行く＝飲み会となることが多いと思うが、私が海外で出会った方々はディナーに行く＝食事がメインだった。勿論、皆ビールやワインも飲むが、ビジネスのお付き合いのディナーで酔っ払う人はあまり見たことがないように感じる。もしかしたら、仲間内だけのディナーであれば酔っ払うほど飲む人もいるのかもしれないが、私はそのような光景を見たことがなかった。 私が主に海外出張で訪問した地域はヨーロッパが多いが、ヨーロッパやアメリカのレストランでは、基本的に食事にドリンクをつけることがマナーという風潮もある。しかも、ジュース系や水とアルコールの値段があまり変わらないので、アルコールを頼む人が多いだろう。 また、一昔前は交渉はディナーで行われると聞くが、私の参加したETSI NFV ISGや3GPP-SA5ではディナーで交渉することは少なく、ディナーは食事を楽しみつつ、どんなことを考えているかということを探る場に感じた。 ディナーは誰と行くべきか？ 理想は取引先や関連企業と行き、交渉の裏側や本音、将来どんなことを考えているかなどを探ったり、逆に将来の方向性を普及するために会議の場で説明した内容の補足をしたりということに使うと良いだろう。 一方で、海外の方の多くは家族＞＞＞仕事なので、毎日のようにディナーに誘ってしまうとあまり喜ばれない。ビジネスとしてお誘いするケースと、仲間内で楽しむケースと、観光代わりに個人で楽しむケースと分けて計画した方が良いかもしれない。 ディナーでの会話 ヨーロッパ系のディナーはコース料理が多いので、普通に食事をしても1時間以上はかかる。基本的には注文〜前菜〜メインディッシュが届くまでが主な会話時間で、メインディッシュが始まると何となく会話が減る気がする。特に注文した直後は共通の話題を探るところから始まるが、日本のようにスポーツや気候の話をしても共通の話題にならないことが多いので、共通の話題探しはなかなか難しい。私が今までの経験でよく話題に上がった最初の話題探しは、大きく分類すると以下のような内容だった。 少し変わった料理やその調理法 保温鍋での料理、自分の家族の得意料理など 相手の国に関連して、自分が見たことあるニュース 回転寿司の寿司を機械が作...

本日は仮想化を理解するために、プログラムとは何かを考えてみたい。最低限のプログラムの概念を理解することで、何故仮想化やクラウドが流行したかを改めて考え、グローバルでも自信を持って議論や交渉できる一つの基準として欲しい。なお、概念の説明上、詳細は多少間違っていることがあるが、その点は目を瞑って頂きたい。 1. プログラムの動作とは？ 現状多くの汎用コンピュータはノイマン型コンピュータと呼ばれており、多くのプログラムもノイマン型コンピュータで動作することを前提に設計されている。 コンピュータの基本構成 ノイマン型コンピュータは主に演算部・制御部(CPU)、記憶装置(メモリ)、入出力補助装置で構成される。記憶装置(メモリ＋HDD)にあるプログラムとデータを制御部・演算部(CPU)によって実行し、結果を入出力装置(ディスプレイ or 印刷 or 保存媒体)に出力する構成となっている。 プログラムの実行 ノイマン型コンピュータでは、プログラムは、実行コード領域の命令を順番に演算部で計算されることで実行される。プログラムで記載された計算結果は、スタック領域とヒープ領域に保持される。CPUは現在実行コード領域上のどこを演算しているかをプログラムカウンタで記憶している。  2. 性能向上の工夫 昔のコンピュータは各部品(CPU, メモリ, バス等)の性能が低かったため、 限られたコンピュートリソースを有効利用するために様々な工夫がされていた。 メモリの大規模化 メモリは容量及び速度共に性能に限界があったため、キャッシュとSWAPを利用しページング方式によって効率的なデータ転送を実現していた。ページング頻度が多くなる(4回/秒程度)と性能劣化に繋がるため、ページング頻度を抑止するような処理の見直しが求められた。 マルチタスク 実行主体であるCPUは少数(数十程度)であったため、マルチタスクという仕組みを利用してプログラムを同時に複数実行することを実現していた。マルチプロセスは、1つのプログラム毎にUSER領域及びプログラムカウンタを管理(プロセス)し、これらのプロセスを高速で切り替えていく(コンテキストスイッチ)方式である。  マルチスレッド プロセスを切り替えるためにはコンテキストスイッチが必要であり、コンテキストスイッチの度にコスト(レジスタやプログラムカウンタ...

NFVはテレコム系装置の基盤のような性質があるため、その仕様管理団体であるETSI NFV ISGと 関連のある団体 は多数ある。そのため、真にNFVと連携が進んでいる団体が見えにくい。 NFV仕様と密接な関係の団体 NFV仕様が参照している密な標準化団体としてOASIS、Swagger、Robot、IETFがある。 OASIS： NFVの肝の仕様であるSOL001(TOSCA base NFV  Descriptor)とSOL004(VNF Package)/007(NS Package)/010(Snapshot Package)はTOSCAを参照しているため、そのTOSCAの仕様管理団体であるOASISとは密接な関係がある。 Huawei、NetCracker がリードしている印象がある。 Swagger： 現時点ではまだメジャーになっているようには感じないが、 SOL008(Open API) はSwaggerを参照しており、SOL002(Ve-Vnfm)/SOL003(Or-Vnfm)/SOL005(Os-Ma-Nfvo)/SOL009(MANO OAM)/SOL011(Or-Or)/SOL012(Policy mgmt)/SOL013(common SOL API)もOpen APIの影響を受けているので、それなりに密接な関係があると言って良いだろう。 Robot： こちらもまだ現時点ではメジャーになっているようには感じないが、 TST010(API Conformance Test) ではRobot Frameworkを利用して試験自動化を行なっている。 IETF：IFA032(Multi-Site Multi-Connectivity)を実現するためのプロトコル評価としてSOL017(IFA032)のGAP分析対象がIETF ACTNとなる。今後NFVにおけるNetworkの制御のために、IETF ACTNの仕様を利用する可能性は高い。 逆にNFV仕様をベースに実装している代表的なOpen  SourceとしてOSM、ONAP、OpenStackがある。興味のある人は 2020年のETSI Plugtest の結果も参照して頂きたい。 OSM ：SOL006(Yang Model base NFV Descriptor)をベースにN...

 NFVの動向を観察していると、最近はNFVと一緒にO-RANというキーワードをよく聞くようになってきた。諸説あるが2015年がVMベースのNFV元年と言われているので、5年経ってNFVの業界動向が落ち着き、多くのNFV関係者はNFVの領域拡大を狙っているのかもしれない。NFVの領域拡大の第一候補が無線であり、O-RANはその時代の流れに合致しているのだろう。その考え方としては 総務省HPのNEC説明資料 が分かりやすい。 O-RANとは O-RAN Alliance によると、O-RANの目的は無線装置の業界変革として3つのキーワードを挙げている。 Open化 ＝ RU〜DUのインタフェース制定？ Intelligence化 ＝ RAN Intelligence Controller(RIC)の導入 Virtualization ＝ CU＆DUの仮想化と仮想化基盤(O-Cloud)の導入 モバイルの標準化仕様の代表例として3GPPがあり、 TS 38.401 においてCU〜DUのアーキテクチャが定義されている。 こちら でLTEと比較しながら3GPP仕様の無線装置の主な機能と機能分担の考え方が説明されているが、RU〜DUのインタフェースが定義されていないことが分かる。3GPPは論理機能部を接続するためのプロトコルを規定することが主なScopeであるため、O-RANは3GPP仕様をベースに、RICやO-Cloudのような論理機能部の中の構成要素や保守機能部の標準化を補完( O-RAN White paper より)しているようだ。 O-RANとNFVの関係 O-RANのSpecを閲覧するためには登録が必要なため、メンバー以外が簡単に確認できるのは Blog かと思う。これらとWhite Paperを読む限り、DUやCUを仮想化してクラウドに載せるため、O-Cloudと呼ばれる仮想化基盤上にAPLがデプロイされるようだ。そのため、“O-Cloud ＝ VIM＋NFVI ＆ CISM＋CISI“であり、O2 Interface ≒ Vi-Vnfm/Or-Vi ＋ CismのIF だろう。 Verizon や Samsung の記事を読むと、いくつかのオペレータは既にNFVと同じような構成でRANをデプロイしているようなので、O-CloudがNFVと全く別の機能分...

グローバルで交渉するためにはGive and Takeが大切であり、そのためには知恵orお金or労働力が必要であることを こちら で記載した。英語が聞き取れない＆単語しか話せない私がどのように様々な国や企業の人と交渉しているかを記載したい。本質的な交渉のポイントは英語の得意＆苦手に関わらず同じであり、英語ができない人はこれらをどれだけ 事前に丁寧に準備できるか だと思う。 交渉ポイントと作戦 英語の得意＆苦手に関わらず、やはり一番大切なことはこの“作戦“だろう。では、どのように作戦を考えれば良いだろうか？ここでは“どれだけ知恵を提供しながら、こちらのリクエストに関わる点を議論ポイントに持っていけるか？“を考えることになる。こちらのリクエストに対して知恵が不十分な場合は、お金と労働力をオプションで追加する必要がある。 最近流行りの5Gを例に説明したい。5Gで 一般的に求められている要件 は“大容量・低遅延・多接続“であるが、これを知恵として提供しても誰も聞いてくれない。では、何を考えるべきか？大切なことは、“現在の4Gで抱えている課題“をしっかり丁寧に説明することだ。現在の自分の所属によってどれだけ深く課題を調査できるか変わってくるだろうが、例えば、現在の4Gの運用上の課題は何か？新規サービスを導入するときの課題は何か？開発上の課題は何か？日本独自の課題は何か？と言った点を、どれだけ深く追究できるがポイントである。この課題を5Gの要件と絡めてどのように解決したいか？を説明できる必要がある。私は英語が苦手なので、これを日本語＆絵で説明する資料を事前にしっかり作っておくようにしている(その後翻訳ツールで英語化)。つまり知恵とは これから3〜5年後の世界観＝イノベーションによって実現される世界＋ それによって解決したい具体的な課題 この時の課題について、なるべく具体的な数値を用いて相手がビジネスの規模感を想像できるようにする必要がある。数字だけならば英語が苦手な人でも話せるだろう。私はこのようにして交渉の作戦を立てている。 議論ポイントの考え方 3〜5年後の世界観を資料or英語で説明できれば、次は交渉ポイントを考えることになる。この交渉ポイントこそ“ Coffee Breakでの議論ポイント “となる。世界観に入れた 具体的な課題 ＋自社の要件 vs 交渉相手の世界観/要件...

日本で仕事をしていると「いつもお世話になっています」、「今後ともよろしくお願いします」という挨拶を言いたくなる。しかし、英語で該当するような表現がない。安易に“Thank you”とお礼を言うと「何について？」と聞かれる。今回は、なかなか人に教えてもらえないグローバルでのビジネスマナーの体験について記載したい。 直接会見した時のビジネスマナー 日本で言うところの「お世話になっています」という挨拶は、“How are you?”と聞かれ握手することが多いように感じる。国によっては抱擁することもあるようだが、日本人が抱擁を求められることは少ない。 逆に仲良くなると、“Hi, [名前]“と言われるようになり、具体的に“飛行機はどうだったか？“とか、“昨日はホテルについてゆっくり眠ることができたか？“と聞かれる。ポイントは“具体的“ということであり、日本のような「いつもお世話になっています」のようなどんな場面でも使えるような表現はない、ということだろう。 また、会議が終わって帰国する時などの、「お世話になりました」や「今後ともよろしくお願いします」という挨拶は、握手をして“Have a safe trip”とか“See you again”ということが多いように聞こえる。また、ホテルで自室に戻る時は、普通に“Good night”とか”See you tomorrow“で良いようだ。 日本のビジネスの感覚だと総論として“ありがとう“と言いたくなるが、具体的な感謝の対象なしの“Thank you”は喜ばれない。もし取引相手などの関係がある場合は、具体的に自社に対してどんなメリットのあることをして貰ったかをメモしておいて、しっかり“Thank you for your [具体的な行為]”と挨拶する必要がある。 メールのビジネスマナー 日本のメールでは「いつもお世話になっています」から「どうぞよろしくお願い致します」という形で終わるように、手紙のように記載することが多い。しかし、英語のビジネスメールは、まるでチャットのように要件だけを短文で記載することが多く、長文はむしろ嫌われるように感じる。そして、依頼“I would like you to ask [要件]...”なのか、情報共有”For your information,”なのかをはっきりと記載した方が良いようだ。 H...

NFV標準仕様は今も日々進化している。このブログでは標準仕様のトレンドや進捗状況についても定期的に共有したい。最新のNFV仕様の全体像は こちら で確認できる。 NFV会合とは ETSI NFV ISGは複数のWorking  Group(WG)と呼ばれる 会議体 によって標準仕様を検討・制定している。NFVの主要な仕様を制定しているWGはInterface And  Architecture(IFA)とSolution(SOL)であり、基本的にはIFAとSOLのGS(ETSI NFV ISGの標準仕様として発行しているドキュメント)の更新状況を確認していくことになる。 NFV会合とは、プレナリと呼ばれるETSI  NFV  ISGの最高意思決定会議が開催される期間であり、コロナ以前は1週間特定の場所で集中的に会合を行なっていた。実は NFV#6沖縄 と NFV#28福岡 の2回ほど日本でも開催されている。基本的にはプレナリによって新しいドキュメント作成の活動(WI)が提案されたり、完成したドキュメントの発行を承認されたりする。 NFV#33のサマリ Technical Steering Comittee(TSC)が最新のETSI NFVの活動状況をまとめており、NFV#33の時点ではNFVTSC(21)000004r1_Summary_of_NFV_Releases_by_Jan_2021.pdfに記載されている。重要な活動結果としては Release 2のStage3レベルの仕様がVersion 2.8.1として全て揃いCloseされる。これでETSI NFVとしては実質Release2のメンテナンスが終了。 今更感があるがNFVのアーキテクチャ(全体像)を表す NFV006 “Architectural Framework“ Release2 が発行された。 Release3はFEAT02 NFVI UpgradeのStage2がVersion 3.4.1で完了し、Stage2は全て完了。 Release3のStage3も初版は3.4.1として完了し、主なStage3の残仕様は、 NFVI Upgradeの取り込み CoordinateLCMoperationの完成 SOL017 “Multi-site connectiv...