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

これまでNFVをベースとした仮想化の説明をしてきたが、肝心のVNFについて説明していなかったことに気づいた。今日はそもそも”VNFとは何か？“について解説してみる。 Network Functionを仮想化した“VNF“ 『 電気通信のつながるしくみと設備構成 』(NTT東日本)や『 結局モバイルNWのお仕事って何？ 』の通り、テレコムやモバイルのNWは加入者設備・加入者線(・基地局)・伝送路・交換機によって構成されており、これらの設備(のいくつか)をNetwork Functionと呼んでいる。 VNF (Virtual Network Function)とは、このNetwork Functionを仮想化したものであり、主にVM型とコンテナ型がある。ETSI-NFVの仕様としては特定のタイプのNetwork Functionに限定している訳ではないが、NFVは元々 aTCA の有力な後継機として始まったこともあり、暗黙的にモバイルコア(交換機)を最初のターゲットして検討している。 上記図の通り、aTCAとNFVの関係をまとめると、概ね1 Chassisが1VNFインスタンスであり、1 Baldeが1VNFC (VNF component)となっている。もちろん、APLの性質によっては1VNF = 1VNFCとして設計することも可能である。 components aTCA NFV blade APL APL APL MW MW MW OS CGL Guest OS HW aTCA VM NW segment VLAN + L2SW Virtual Link (VL) port port Connection Point (CP) + Top Of Rack (TOR) HW manager HW OAM Charssis manager VIM HW control Charssis manager N/A ...

  今回の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...

3GPP、ETSI-NFV、O-RANと様々な団体で証明書に関する議論が起き始めている。何故今証明書が重要なのかを、テレコムの進化や運用や観点から考えてみたい。 識別子としての証明書 「 時代を映すインフラ 」(国立情報学研究所)や「 知識の森 第5群4編ノード技術 」(IEICE)の通り、元々テレコムにおいては、端末〜端末間をPoint to Pointの専用線で繋ぐ思想だった。その識別子がチャネル/VCI→IPと変わってきただけで、根本的なNWトポロジー(構成や機能分担)はあまり大きく変わっていない。 テレコムの運用においては、この交換機等のNW設備の“箱“を専用線で繋げる発想であったため、NW設計も保守運用の考え方も、この箱と専用線単位となっている。「 テレコムアプリの実装の特徴と監視方法②〜EM編〜 」にも記載している通り、EMは各設備のFCAPSを装置単位に管理している。通信方式がIPになったとしてもこの考え方は大きくは変わっておらず、IPアドレスで設備を識別・管理し、VLANで専用線を管理している。 5GC以降、「 REST指向での標準仕様設計方法 」の通りSBAやRESTと言ったよりダイナミックでフレキシブルなプロトコルを利用されるようになり、ここで装置の識別子が装置から証明書に変わってきた。 5Gにおいては、Serviceベースでの仕様となりNF(Network Function)の構成やNWの接続先をDynamicに変更しやすくなった。その結果、従来のようなIPアドレスによる装置単位の監視保守は維持できず、リソースを管理するResource Manager (5GCではNRF)が動的に増減・変更されるNFを管理するようになった。これにより、監視方法もトラヒック管理方法も変わってきている。また、IPアドレスで装置を管理することが困難になり新たな識別子の管理方法として 証明書 が利用されるようになった。 証明書の利用方法 3GPP TS 33.501 や ETSI GS NFV-SOL 013 の通り、SBAにおいてはmutual TLS (mTLS)による認証＆セキュア通信と、OAuthによる認可が通信のベースになっている。この時、各NFを識別しているのは”証明書”となる。SEの道標というサイトにおいて、mTLSとOAuthによる認可認証の仕組みは ...

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の冗長...

  今回はIFA＆SOLの中間会合(10/25〜11/4)もコロナの影響でeMeeting (電話会議)となった。今回は標準仕様としてはあまり目立った進展はなかったが、Release4とRelease5のゴールが少しずつ見えてきた。 最新のNFV仕様の全体像は こちら (ETSI-NFVのOpen area)で、前回NFV会合の説明は NFV#35の会合サマリ を確認して頂きたい。 ETSI-NFV仕様の各Release機能 ETSI-NFVはテレコムAPLをクラウド上に載せる技術と仕様であり、各Releaseによって制御範囲や制御内容の拡張が行われている。 非仮想化： ETSI-NFV仕様導入前は、テレコム装置であるNF (Network Function)と、それを制御するEM (Element Manager)、そしてそれら複数のEMを運用する支援するOSS (Operating Support System)によって構成されている 主な仕様は モバイルネットワークの保守運用の基礎 の通りFCAPSとBillingとなる Release2: VNF LCMとは？ の通りVNFやNSの基本ライフサイクルがサポートされている 仮想化されたNF(VNF)と VNFが動作するクラウド環境NFVI (NFV Infrastructure)＋VIM (Virtual Infrastructure Manager ≒ OpenStack/vCenter)が導入された 複数のVIMとVNFを統合管理する NFVO (NFV Orchestrator) と、NFを仮想化するにあたってNFVOやVIMだけで不足する VNFM(VNF Manager) がNFV-MANOとして新規追加された NFV-MANO動作させるNS Package(NSD) (SOL007)とVNF Package(VNFD, VM image, Artifact) (SOL004) 、そしてTOSCA-baseのNSD/VNFD (SOL001)とYang-model baseのNSD/VNFD (SOL006)が定義された 各機能部を接続する RESTベースのAPI (SOL005, SOL002, SOL003)とVIMを制御するVirtual Resource Descriptor (≒H...

 2012年頃にNFVのコンセプト議論が始まった頃から”Orchestrator”というキーワードをチラホラ聞かれるようになったが、2021年になった今でも結局Orchestratorの定義や必要性がよく分からない。 仮想化と監視運用自動化 のECAベースのようなWorkflowと混同されることもあり、「Workflow Orchestrator」で検索すると自動化という文脈の検索の中でWorkflowとOrchestratorが並んだ結果が多数出てくることも分かるとおり、Orchestrator＝Workflow＝自動化で話されることも多いことも原因だろう。 ETSI-NFVにおけるNFVOの役割 VNFMとは？ で記載したとおり、NFVOの役割とは 複数のVIMのキャパシティ管理 既存保守機能部(OSS)との接続 自動化 である。つまり、OSSからの指示に従って各NFV-MANOの部品(VNFMやVIM等)を よしなに 制御し、人手の作業や意思決定を最小限にすることを期待されている。 NFVOの機能 ETSI-GS NFV-IFA 010 を確認すると、NFVOが保持する機能としてはVirtualised Resource (VR) Mgmt, VR PM, VR FM, Reservation Mgmt, NFVI capacity Mgmt, Quota Mgmt, Network Forwarding Path (NFP) Mgmt, Permitted allowance Mgmt, NS LCM, NS PM, NS FM, NS Pacckage Mgmt, PNFD Mgmt, SW image Mgmt, Policy Mgmt, Multi site connectivity mgmtがある。  NS LCM vs VNF LCM NS LCMはNFVO、VNF LCMはVNFMが管理しているため、例えばあるVNFに対してHealingするかScalingするかの判断がNSレベルとVNFレベルで異なる可能性がある。どちらのLCMをマスターにするか(Source of truth)とするかという問題がある。 ETSI-NFVのArchitectureでは、”NFVOの判断を尊重する“ためにVNFMはVNF LCMを実行する前にN...

海外の会議に参加していて意外に困るのが“ 英語の略語 “だ。日本の会議であったとしても企業毎や組織毎に進め方やルールが異なったり、独特な略称や識別子の使い方があるが、海外の会議でも同じだ。 会議自体の進め方は、その会議のどこかでドキュメントとしてまとまっていることもあるが、略称はどこにもないケースが多い。また、インターネット上で調べてもなかなかまとまっていない。今回はETSIの会議やメールにおいて利用される略称をまとめてみた。今後気づいた用語があれば随時追加していきたい。 ETSIの会議で利用される略語 rh : Raise Hand ("I want to say something") 主に電話会議で利用される“挙手“の意思表示 チャットに” rh ”と記載することで発言の許可を得て発言する lh : Lower Hand ("cancel" the raise hand) 主に電話会議で利用される挙手の取り下げ ”rh“とワンセットで利用し、チャットで挙手を取り下げるときに” lh ”と記載する。 CR : change request. 現在の標準化仕様/ドキュメントの変更提案 会議中やメールなどあらゆるところで利用される w.r.t : with respect to (putting something into context of something else) 議論中の内容に“追加で補足“という意思表示 電話会議中のチャットでの補足やメールで割り込んで発言するときに“ w.r.t [トピックや主張], ”と記載して補足を追加するときに利用 WI : Work Item ETSIにおける標準化ドキュメントを作成するための活動アイテムの名称 会議中やメールなどあらゆるところで利用され、CRや各種提案は全てWI単位で行われる 新しいWIは NWI (New Work Item)と言われることもある AP : Action Point 特定の人/会社に割り当てられた課題/タスク 主に議事録(Meeting Note)などに記載される WG : Working Group 特定の目的に基づいて作業するグループや会議体の総称 会議中やメール、公式ドキュメントなどあらゆるところで利用される メールやチャット等の文章で利...

基地局編 と EM編 の続きである。 交換機 電話交換機とは 、 電話が繋がる仕組 、Voiceの PBXの主要メーカー4社比較 を見て頂くと、交換機の基本的な役割が分かるだろう。 装置構成 交換機はモバイルに求められる要件に応じて、アーキテクチャが大きく変わってきている。論理エンティティとしての機能分担は3GPPの仕様を確認頂くとして、ここでは監視の観点で主な機能部の種類を紹介する。 加入者DB: UE(端末)や契約者の顧客情報に関するネットワーク上のマスターとなるDB サービス加入状況等の契約情報、UEの認証情報やデバイス情報、位置情報 4GまではHSS、5G以降はUDM/UDR マルチメディアサービス: 交換処理の上で契約情報に基づいてテレコムサービスを提供するApplication群 基本呼制御、QoS制御、トーン/アナウンス、音声通話、留守番電話 3GまではMSC内だったが、交換機のIP化の頃からIMS 他網接続: 他網へ接続し各種プロトコルを終端 固定網(PSTN/ISDN)、インターネット(PDN)、他モバイル網(PLMN) 交換処理: 交換機としてUEからの通信の接続先を切り替える中心処理 3GはMSC IP化に伴ってパケット交換処理部はGSN 4GではEPC 5GではU-PlaneをUPF、C-Planeを5GCの他の論理機能部が担当 無線通信の終端: 無線からの信号を受けて無線通信を終端 従来のUE〜UEを擬似的な専用線で接続する“回線交換“から、徐々にインターネットへ通信するためのパケット転送に最適化された機能部に変化している。特に5Gでは、C-PlaneとU-Planeを分離することで、大容量のデータトラヒックに耐えられる思想になっているようだ。 監視方法 『スマートフォン時代の大容量通信を支える新3Gコアネットワークパケット処理ノードの開発』(NTT DOCOMO Technical Journal) や『 NECのUPF 』を見る限り、交換機の実装は、U-Plane系の処理(U-Plane processor)はRouterに近い実装となっており、O&M機能部やC-Plane系(Protocol termination)はIT系の実装に近い実装となっていることが多いようだ。 一般的なIT系技術の実装と異なる点は、DBと処理ロジック...

今回のNFV#35(9/13〜22)もコロナの影響でeMeeting (電話会議による会議)となった。今回はNFV-Workshopのようなイベントは無かったようだが、いくつかの仕様検討は大きく進んだ。 最新のNFV仕様の全体像は こちら (ETSI-NFVのOpen area)で、前回NFV会合の説明は NFV34の会合サマリ を確認して頂きたい。 NFV#35のサマリ NFV#34と比較した重要な活動結果としては、 Release3のed351がPublishになった。 Release4のStudyが多数完了フェーズになり、今後Normativeに移行する。 Release5のNew Work Itemが承認され、活動が開始された。 コンテナ関連はあまり進んでいないが、新Usecaseや新機能に関するStudyが多数完了して、これから新しい機能に関するアーキテクチャの検討や機能分担が開始されそうだ。 Release3：LCMの高度化 IFA&SOLの第2版(ed351)がPublishされ、サポートするVNF関連の機能について大きな進展があった CoordinateLcmOperationが仕様化され、FEAT02 VNF Upgradeが完了した。ed361に向けた残機能はFEAT03 NFVI UpgradeとWIMのNorth Bound Interface (NBI)のみとなる。 SOL017 MSCS (Multi-Site Connectivity Service) stage 3 reportが完了し、IETF ACTNベースでWIM NBIが開始予定。 VipCpの導入によりVirtual IP address (VIP)がNFV-MANOでも管理可能となり、NFV-MANOがサポートできるVNFのNWの幅が広がった。 Rel2までは主にMAC Address＋VLAN (L2)のLinkのみがNFV-MANOの管理対象であり、IPアドレスはConfiguration(設定情報でありNFV-MANOの管理対象外)だった。そのため、例えばVNFC間で冗長構成になっていた場合も、その数だけExtCpが必要となるような管理方法だった。 Rel3からはVipCpを利用することで、複数のVNFCでVIPを共有するVRRPのようなNWも記述可能になっ...

引き続きテレコムアプリ(Network Function)の特徴と監視方法についてまとめてみた。今回はNFの監視機能部であるEM(Element Manager)についてまとめてみた。 EMの役割 テレコムアプリ(NF)はユーザに安定した通信を提供するため、長期間NFを動作させ続けるという要件があり、「 モバイルネットワークの保守運用の基礎 」のようなテレコムアプリの運用やメンテナンスのための様々な機能が実装されている。基本的な考え方はFCAPS (Fault management / Caonfiguration management / Accounting management / Performance management / Security management)となるが、近年はここにProvisioning + LCM (LifeCycle Management)やProve監視といった運用方法が追加されている。 EMのFCAPSの実装例 Open Sourceも含めて一般的にFCAPSは3つの機能とAPI GW(Gateway)で実装されていることが多い。 Data Collection: 監視対象からLogや信号を集める 通常のLinuxであればSyslogやSNMP、HW関連であればIPMIやRedfishなどを利用してDataを集めることが多い 昔であればvmstat + tail -f /var/log/messageなどを利用することが多かったと思うが、最近はZabbix Agent / Prometheus Exporter / SNMP agentなどのツール、更にはiLoやiDracなどの管理用の専用HWなどを利用することが多い 3GPP-SA5やNFVだとLog (FM/SM)やReport (PM/AM)と呼ばれ、実際にFM/PMなどで管理される情報の元ネタ相当となる Data Analysis: 集めた信号からコンポーネント単位の状態変化を判定し異常状態の有無を管理し、Alarm発生/回復を判断する 各管理コンポーネント(Managed Object)とマッピングされ、各MOの状態を生成する。障害時は1のCollectionが情報欠損することが多いため、SynchronizationやAuditの機能を保持していることが多い。...

テレコムAPLが具体的にどのように実装されているか、それに伴う監視ポイントがどこかがまとまっている資料がないので、公開情報からまとめてみた。今回は基地局である。 基地局 @DIMEの「 携帯電話基地局の仕組み、設置料、メーカーなど知られざる秘密、こっそり教えます 」や「 携帯電話のしくみ 」、「 結局モバイルNWのお仕事って何？ 」を参考にして頂きたいが、一言で基地局と言っても複数の構成からできている。 装置構成 無線 装置と言って良いか分からないが、モバイルにおいては端末 UE (User Equipment)とネットワークは電磁波を利用した無線で通信される。そのため、電磁波の物理的性質に基づいて「 電波の特性 」のような性質がある。 無線は電磁波を利用して信号を運ぶため、 周波数×時間×電力(振幅)を組み合わせる ことで限られた無線リソースを複数のユーザで共有する。 電磁波に情報を載せるため、電磁波の振幅を加工する変調技術と、誤り訂正( FEC )や信号の再送( ARQ )を行うための 符号化 が行われる。こちらの論文「 無線通信方式の基礎 」がよくまとまっている。 これらの無線は特定の周波数( キャリア )毎に セル という単位で制御し、電磁波の放射エリアに指向性を持たせ セクタ を構成することで、他のセルの干渉を最小化したり、1セルのエリアを小さくして1セルあたりの収容ユーザ数を限定させたりして、限られた無線リソースを効率的に利用している。 第2世代、第3世代、第4世代、第5世代・・・とは、これら無線リソースの 共有方式や符号化技術を改良 することで、限られた無線リソースで大容量の信号を運べるように改良している。 異なる周波数(キャリア)のセルを重ね合わせる( オーバーレイ )によって、基地局やアンテナの故障への 耐障害性 を高めたり、キャリアアグリゲーションによって複数のキャリアと同時に通信することで通信速度を高めたりしている。 アンテナ 無線の送受信を行う基地局の装置 RRE (Remote Radio Equipment)であり、端末(UE)と基地局が通信するモバイルの要の装置である。 一様に広がりがちな無線の放射に対して特定のエリアのみに無線を放射できるようにビーム性を持たせ、アンテナではこの ビームの角度( チルト 角) を制御している。 MIMO...

グローバル企業と議論する場合、前提となる基礎情報が異なるケースが多い。例えば、国内では企業名を言えば大凡の売上等は分かるが、海外企業と話す時はしっかり財務情報ベースで話をしないと通じないことが多い。そのため、 マーケットニーズの規模 と様々な施策のコスト感は金額ベースの定量的(数値的)な情報を把握しておいた方が良い。 共通的な基礎情報 共通的な指標として、主要国の国土情報とマクロ的経済指標、そして主要企業の決算報告書は目を通す習慣をつけた方が良いと思う。 国土情報 国土情報は今の時代はWikipediaで調べれば十分な情報を獲得できる。人口、年齢分布、地理的特徴、政策的特徴、主要産業あたりは抑えておきたい。 マクロ的経済指標 外務省のHP にリンクがまとまっているため、そちらを利用すると簡単に確認できる。特に外務省の『 主要経済指標 』( 2021年 分)やOECDの『 OECDの主要指標 』、JETROの『 世界貿易投資報告 』、総務省の『 世界の統計 』は一度見ておくと規模感が分かると思う。 景気情報 GDP: 各国の経済の規模感を知る上ではGDPは一番話がしやすい情報の一つだと思う。関連する国の大凡の規模とトレンド(上昇/下降/横ばい)は抑えておきたい。 企業情報 設備投資(Gross Fixed Capital Formation): 法人向けのビジネスをする上では、その国の設備投資トレンドとその設備投資額の規模感は抑えておいた方が良いだろう。OECDの『 設備投資(総固定資本形成) 』から部門(Sector)別で過去10年以上の傾向を辿ることもできる。 労働 失業率: 一般消費者の懐事情を見る上では、失業率は一度見ておきたい。OECDの『 失業率 』であれば若手とそれ以外の失業を確認でき、ヨーロッパでは若手の失業率が非常に高いことも分かる。 物価 消費者物価指数: こちらも一般消費者の消費傾向を見る上では大切な指標であろう。内需を伴う経済成長中か、デフレが起きているのかなどもある程度確認できる。 貿易 輸出入量: こちらもその国の経済規模を見る上では参考になる指標値である。JETROのサイトでは貿易の内容を細かく調べることもできるので、どのような産業に力を入れているのか、どのような物が自国でまかなえないのかなども分かる。 国際収支: こちらはその国が外貨を...