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

 NFV(クラウド技術)の導入やモバイル内の信号のREST化によって、モバイル装置の開発とWeb系の開発の境界が段々薄くなってきているように感じる。ETSI NFVやO-RANでもCloud-Native ( ETSI GS NFV EVE 019 ) やCICD ( ETSI GR NFV TST 006 )という話が出てきたり、OpenStackやKubernetes、 Free5GC 、 O-RAN SC というOpen Sourceを(部分的でも)利用したり、リファレンス実装として仕様調整として参考にされたりしており、従来のような専用装置を開発する開発スタイルから変わりつつある。 一方で、モバイルサービスの特徴そのものは変わっていないので、開発で求められる要件は変わっていない。今回は、変わりつつあるテレコムの開発スタイルを横目で見つつ、モバイル開発の基本とその特徴について書いてみたい。 モバイル装置を開発する上での基本的要件 モバイルネットワークの保守運用の基礎 にも記載している通り、モバイル装置は各国で法規制がありつつ、目標SLA 99.999％(年間停止許容時間5分程度)を目指した様々な運用条件や保守要件がある。Web系システムの場合は目標SLAを99.9％(年間停止許容時間9時間弱)と設定していることが多いので、この目標SLAの違いがそのままシステム設計の基本原則や運用条件の違いとして染み出してくる。 また、モバイルサービスは、2G、3G、4Gがそれぞれ10年近くサービスを提供し続けている通り、同一サービスを長期間提供し続ける必要がある。モバイルサービスは、多くの場合途中でのサービス追加などを求められることはなく、安定した通信を値上がりすることなく継続利用できることが求められる。 この、目標SLA99.999％を実現することと、10年単位でのサービス継続のために、各モバイルオペレータやベンダは様々な開発ノウハウを保有しており、それらに基づいてこれまで開発してきた。また、日本の場合は総務省が「電気通信事故検証会議」として毎年その年の通信事故の検証結果を報告書としてまとめており、その中に再発防止策や教訓が記載されている。最新の取り組みは電気通信事故検証会議の報告を参照するとして、各モバイルオペレータが取り組むべき品質改善策の全体像については、少し古...

 O-RAN/vRAN (virtual Radio Access Network)と並んで、最近注目を集めている技術にMEC (Multi-access Edge Computing)がある。AWSやGoogleなどのHyperscalerと呼ばれる巨大なパブリッククラウドビジネスがある中で、小規模分散型のMECが騒がれている理由について見てみたい。 MECが想定するビジネス iGillottResearchの『 小売業界におけるMECのビジネスユースケース 』や、NECの『 ユースケースによるMEC導入効果とメリット 』に想定されるビジネスが記載され始めているが、これらのユースケースによれば各企業のシステムを自社(オンプレミス)〜ネットワーク(MEC)〜クラウドのどこに置くかによって“企業のコスト構造の変更によるコスト削減“に見える。 一般的にビジネス性と言えば、「(収入ーコスト)×ビジネス継続期間」となるので、①新規収入(収入UP)、②コスト削減、③SLA/品質/安全性向上(ビジネス継続)のいずれかとなる。MECにおいては各企業のシステムを構築する環境(クラウド)の提供形態となるので、 ITとモバイルの保守の違いとは？ での説明の通り本来物理装置を集約することでコストを極限まで下げることで成り立つビジネスのはずである。しかし、MECは分散することで②のコスト削減や③の品質や安全性の向上を狙っているので、分散クラウドによる維持コスト増加とのバランスにおいてビジネス性のあるユースケースがなかなか出てきていない。総務省の『 ネットワーク設備委員会 』においても、この分散クラウドとパブリッククラウドの効果とコストのトレードオフの関係は議論されているようだ。 交換機に近い場所では、モバイルオペレータ観点では設備の効率化は可能だが必要となるリソースのパブリッククラウドとの差が小さくなるため、大きな費用構造の差は無いだろう。パブリッククラウドの場合ネットワーク帯域の使用料が比較的高額なケースが多いため、そのような高額なリソースの種類によってはMECが競合相手になる可能性がある。 一方で、中継局や基地局のような箇所にMECを置くことが出来れば、ネットワークリソースなどを省略し、費用構造を変えることができるだろう。ただし、MECを基地局サイドに近付けるほどアーキテクチャ...

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に移管される可能性は高い...

モバイルネットワークの難しいところとして、利用者が移動することによる通信先の基地局の変更(ハンドオーバー)や、他の拠点の基地局のアンテナや3Gや4Gなどの既存設備を利用したエリアの冗長化(オーバーレイ)と言った、複雑なエリア設計がある。各接続先の装置特性によって技術特性が全く異なるため、モバイルネットワークの理解も、インフラ設計や監視の検討などが非常に難易度の高いものになっている。今回は、かなり乱暴になり、間違いも多いとは思うが、監視の観点でハンドオーバーやオーバーレイとは何かを解説してみたい。 ハンドオーバーやオーバーレイの必要性 結局モバイルNWのお仕事って何？ のとおり、お客様が移動してもお客様の通信(専用トンネル＝ベアラ)を維持し続けることがモバイルNWのミッションとなる。そのため、モバイルとしては“ 通信先の基地局が動的に変わる “ことを想定しなければいけない。新幹線や自動車で移動していたとしてもモバイル通信が継続できているように、基地局の切り替えはかなり速い速度で頻繁に変わることもありえる。 そのため、モバイル網としては、お客様の端末(UE)から通信先への仮想的な専用トンネルを複数本用意するという手法を用意している。端末UEが通信している基地局の電波が弱くなると、別の専用トンネルを利用することで 専用トンネルの維持 を実現している。このような利用する専用トンネルの変更がハンドオーバーである。 (なお、実際に専用トンネルをどこまで事前に作っておくかは接続先や採用している技術の世代によって異なる) この図では、異なるアンテナや異なる基地局で3本の仮想的な専用トンネルを作っている図となる。基地局の設置と、各基地局から放出アンテナの関係は様々なパターンや制約があるが、仮想的な専用トンネルを作るためには当然同一エリアに異なる設備から放出された電波が必要となる。少し古い資料となるが セル構成技術の進展 のように、これらは電波特性や周波数の衝突、世代による符号化技術、無線パラメータの一貫性等様々な制約があるが、ハンドオーバーできるようにエリアを重ねたり、信頼度を上げるために他の装置によって該当エリアをカバーするような構成(オーバーレイ)にしたりする。 赤とオレンジの切替であれば基地局と端末UE間での切替となるし、赤から青への切り替えであれば交換機と連動した切替が必要と...

 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...