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

 O-RANの次回会合が2022年2月となり、前回 O-RAN virtual Face to Face June会合 から期間が大分時間が経ってしまった。 TelecomTVの報道 によると、O-RANに参加している数企業がアメリカの Entity  List (アメリカの安全保障の観点で取引禁止としている企業リスト)に追加されたことで主要参加企業(Nokia等)がアメリカ政府からのペナルティを恐れてO-RANの活動を停止し、その結果O-RANとしても2021年9月の会合をキャンセルとしていたようだ。virtual Face to Faceはキャンセルになったものの、この半年以上で様々な検討が進んだ。その中の一つに、基地局のコンテナ化がある。 基地局をコンテナ化するとは？ テレコムアプリの実装の特徴と監視方法① の通り、基地局は大きく分けると、アンテナ、リモート装置、Base Band処理装置、呼処理制御装置と、それらを繋ぐネットワーク機器の5つに大別されるだろう。特に5GはO-RANによって、O-RU 〜 O-DU 〜 O-CUの3つの機能部に分離され、O-RU=アンテナ+リモート装置、O-DU=Base Band処理、O-CU=呼処理制御装置になってきている。O-RANでの議論や仕様、 O-RAN SC の参照実装を見る限り、現時点で仮想化のターゲットとなっているのはO-CUとO-DUとなる。特にO-CUは既に Samsung や Mavenir などが Verizon やが仮想化を商用展開始めており、 Telecom Italia (TIM) もLTEの仮想化などを行なっている。 無線装置を仮想化するにあたっては、そのまま4Gの処理をVM等で実現する方式と、仮想化の集約効果を向上するために機能分担を見直して再実装する方式がある。前者の場合は、基本的には基地局装置は各アンテナ配下に数台レベルの超小規模データセンタを作ることになり、D-RAN (Distributed Radio Access Network)と呼ばれることもある。後者の場合は、C-RANと呼ばれるように集約可能な機能部を集めることで比較的中規模なデータセンタを作ることになり、C-RAN (Centralized Radio Access Network)とよばれる方法と親和性...

このBlogをはじめてからコンピュータ・サイエンスに興味を持ち勉強の必要性を感じつつも、なかなか第一歩が踏み出せない人が多いことが分かってきた。これまでの経験では、基本的には「日常的に自分で使ってみる」ことが一番の勉強の近道だと思う。今日はその第一歩として、Linux(Ubuntu)を日常的に使うことで、コンピュータ・サイエンスの学習環境を用意することを案内したい。休みの日にでもチャレンジしてみてほしい。  Linuxを日常的に使うことは現実的か？  最近はTabやスマホでほとんどの日常作業が可能になったので、正直PCを利用する場面は大幅に減っていると思う。現在どうしてもPCを利用するケースとしては 年賀状 そもそも最近では年賀状を送らない人も増えているので、今後は利用しないかもしれない 最近では はがきデザインキット (郵便局)や 年賀状印刷 (カメラのキタムラ)があるので、自宅でプリンタを維持するよりこのようなサービスを頼んだ方がコストパフォーマンスは良いかもしれない。 一方で、Linuxで年賀状を作ることはなかなか敷居が高い。スマホなどのアプリで年賀状を作成し、Linuxはただのプリンタサーバとしての利用となっている。CanonやEpsonなどの大手プリンタであれば特に問題なく利用可能だ。 動画編集 最近ではスマホの動画編集アプリも増え、スマホ自体のマシンパワーも上がってきたので、PCで編集が必要な動画は減ってきている。 PCで作業が必要な動画は、映画のような長時間＆巨大な動画ファイルのエンコードや、運動会の編集のような長時間ファイルから必要な部分のみ切り出したり拡大や逆光加工を頻繁に行う動画だろう。 Linuxでも動画編集アプリはAvidemux、Lightworks、OpenShotなど品質の良いアプリが増えてきている。 Excel/Power Point/Wordでの資料作成 資料作成はまだまだPCを使った方が簡単に作ることができる気がする。 今後はTabで資料作成が可能になっていくかもしれない。 LinuxではLibreOfficeがMicrosoft  Officeと大体互換性があるため、普通に資料作成可能だ。微妙に各ボタンが異なるので、UIに慣れるまでは時間がかかるが。 ファイルサーバ  Google Driv...

これまで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と処理ロジック...