投稿

ラベル(ビジネススキル)が付いた投稿を表示しています

6Gの検討状況 ~USA編~

イメージ
アメリカでは5Gの普及前から6Gに期待されているようで、2020年から6Gの検討が始まっている。現時点での6Gの検討状況(USA)について紹介したい。 USAの主な6G関連のプロジェクト USAでは主に標準化団体や政府主導で6Gの検討がスタートしている。特に6Gに向けては、NGAを中心に6Gの検討が進んでいる。 北米の標準化団体である ATIS (Alliance for Telecommunications Industry Solutions)の NGA (Next Generation Alliance)を中心とした6G検討の推進 アメリカ連邦政府である NSF (National Science Foundation)や NIST (National Institute of Standards and Technology) を中心とした検討団体 その他Private sectorや個別企業 団体名 投資元/金額 6Gに向けた活動状況 主な参加者 PJの期間 主なUsecase 備考 NGA (Next Generation Alliance) 1. ATIS 6Gに向けたロードマップ 80団体 ( テレコムベンダ、オペレータ 、大学、 政府機関 ) 2020 -  5GのUsecaseの拡張(4) ATIS配下の6G戦略検討機関 PAWR (Platforms for Advanced Wireless Research) 2. NSF /1億ドル PoC 民間企業数社 2017 - 2022 無線の基礎研究 RINGS (Resilient and Intelligent Next-Generation Systems) 2. NSF /4350万ドル 標準化に向けたpre study 民間企業9社 大学 NICT、OUSD 2022 -  6Gの通信方式 (37) 6G for DoD (6G for Department of Defense) 2. 国防省 /6億ドル PoC 不明 2020 - 民間・軍事両用での6GのUsecase Open6G 2. 国防省 標準化に向けたpre study 20団体 (ベンダ、オペレータ) 2022 -  6Gの通信方式 OpenRANの6G向け検討 6G@UT 3.A...

6Gの検討状況 ~ヨーロッパ編~

イメージ
5Gが普及し始めると、大学や標準化団体では6Gについて騒がれ始めてきた。まだ6GのUsecaseもキラーコンテンツもアーキテクチャも見えてきていないが、現時点での6Gの検討状況(ヨーロッパ)について紹介したい。 ヨーロッパの主な6G関連のプロジェクト ヨーロッパでは主に4つの方法で6Gの検討がスタートしている。 EUの主要機関である European Commision を中心とした6GのStudyやPoC(Proof of Concept) ITUやETSIを中心した標準化団体を中心とした6Gの仕様化 各国や大学を中心とした6Gの研究 その他Private sectorや個別企業 関連団体の全体像 (『ETSI ISC(23)000006』より) 団体名 投資元/金額 6Gに向けた活動状況 主な参加者 PJの期間 主なUsecase 備考 SNS-JU (the european Smart Networks and Services Joint Undertaking) 1. EU Europe / 900,000,000EURO (35 R&I projects) PoCを中心とした研究 公的機関: EU Commission 私的機関: 6G-IA 2021 - 2031 AI関連(5) European Commision配下の5G-PPPの後継 ICT-52 Hexa-X 1. EU Horizon / 11,000,000 0EURO 標準化に向けたpre study テレコムベンダ(19) 研究所 (3) 大学 (8) 2021 - 2023 5GのUsecaseの拡張(27) European Commision配下の投資ファンドEU HorizonのPJ One6G 4. Freeの団体 標準化に向けたpre study&PoC 26カ国87企業 (テレコムベンダ、オペレータ、大学) 2021 - ... Robot系(7) ...

データベースって何?ストレージとの関係は?①

イメージ
RESTをはじめとした最近のフレームワークや実装では、データベース(DB)やストレージはシステムの中の実装オプションの一例というレベルではなく非常に存在感を増した技術になってきている。一方で、DBやストレージはデータを破損させないように非常に多岐に渡る技術が蓄積されているため、なかなか理解するのにハードルが高い。そこでDBとストレージを勉強する上での入り口になるように概要を説明してみたい。厳密には正しくない部分があるが、分かりやすさ重視のため、その点はご了承頂きたい。 システム開発のフレームワークとデータの関係 突き詰めるとプログラムとは何か?システムとは何か?というと、与えられた 情報 を元に、定められた ロジック によって、問題を解決するもの、である。最初は暗号解読や天気予報など特定の問題を解決するために使われてきたが、段々プログラム言語が開発されプログラムが汎用化されたり、ハードウェアの性能が上がって問題解決のパワーが増したことで、解決できる問題のバリエーションも量も激増してきた。その結果、システム開発の定石(フレームワーク)も変わってきた。 システム開発のフレームワークには様々な評価軸があるが、ここでは問題解決のスケールとして、データ量と処理量に着目してみたい。初期のプログラムはテープにデータとルーティン処理が記録された専用計算機だったものが、プログラムの汎用化とハードウェアの高性能化によって、①扱うデータが増えたことでデータベース化する流れと、②処理量が増えたことに対するマルチプロセス化という2つの流れができる。その結果、一昔前の典型的なフレームワークとしては、データは全てストレージ+データーベスへ格納しデータの管理に特化したプログラムと、そのデータを加工する処理ロジックに特化したプログラムに分離する流れができた。 しかし、このアーキテクチャは、ストレージのサイズやDBの性能にボトルネックが来たり、処理ロジックが変更になった時に他のロジックへの影響も含めて見直しが必要だったりして、問題(=要件)の変化に追従し続けるメンテナンスも大変だった。特にデータ量を拡張したり処理量を拡張する場合は、大型サーバのスケールアップ(CPUやメモリやディスクを増やす)が主な方法となっておりコストも増加した。そこで、データとロジックを一つのオブジェクトとして隠蔽し、オブジェクト...

グローバルでチームを牽引するためには

イメージ
グローバル人材に向けて必要なスキルとは や 基礎情報収集 においてグローバルで必要となる知識やスキルについて紹介したが、今回はグローバルでチームを牽引するケースについて考えたい。 グローバルでチームを牽引する場合も、国内同様にステークホルダーを意識し、チームのアウトプット(作業スコープ)の明確化と作業全体の可視化は非常に重要であるが、それに追加して現作業のアウトプットが次の作業やプロジェクトに連続的に続くビジョンを描き続けることがチーム内のメンバーから信頼を得るためには重要だと感じる。 グローバルでチームを牽引するときのスキルセット グローバルであろうと、チームを牽引するためにはステークホルダー (お客様や依頼元、チーム内、幹部などの意思決定組織、自チームの作業の周辺作業のチーム等)からの“信頼“が必須となる。信頼を得るためには、スキルと実績が必要である。立場によるのかもしれないが、国内では実績に重きを置かれがちだが、海外ではスキルと与えられた権限に重きが置かれているように感じる。 ビジネススキルについては グローバル人材に向けて必要なスキルとは を参照して欲しいが、ビジネススキルのThink/Collaboration/Actionが揺らぐとなかなかチームを牽引することは難しい。これらのスキルスタックを基にステークホルダーから信用や信頼を得ることが、チームを牽引するスキルセットの第一歩となる。そして、リーダーとしてチームを牽引し続けるためには、お客様をはじめとした業務の依頼元との調整、チーム内の管理、そして自分自身のマインドセットの維持・向上を継続することが必要となってくる。 実はこれらのスキルセットや必要な能力は、実質国内の管理者やリーダー的存在のスキルセットと変わらない。しかし、各スキルや能力の濃淡には少し違いがある。例えば、グローバルではステークホルダーのバックグラウンドやモチベーションが異なるため、資本管理やメンバー管理といったマネジメントスキルより、ビジョンを掲げそのGAPを主張し続けられる人の方がリーダーとして信頼を得やすいように感じる。同様の背景から、反対意見を含む様々な意見や考えがある中でも最後までやり遂げられるタフさや、チームの活動内容を明確化するための作業スコープのIN/OUTを即時できる決断力を持った人が好まれる傾向にある気がする。 チームを...

モバイル装置の開発手法の基本② 〜機能設計編〜

イメージ
モバイル装置の開発は正常ルート1に対して異常ルート9の設計が必要と言われているように、1機能を実現するために必要な設計・製造・試験のコストが大きく、装置の導入や変更にも多大なコストが発生する。そのため、一度新装置を導入すると、なかなか大きな変更や撤去ができなくなる。そのため、『 モバイル装置の開発手法の基本① 〜開発工程編〜 』の通り、法律や運用条件などの様々な要件から外部設計を行い、SLA99.999%を10年継続できるように機能設計を行なっていく必要がある。また、最近では『 ネットワーク仮想化基盤におけるETSI NFV Stage3仕様に準拠したマルチベンダ対応MANOへの移行 』の通り、製造請負と呼ばれる自社での開発から、標準化やOpen Sourceを利用した製品を利用した開発に開発方法も変わってきている。今回はそのようなモバイルにおける機能設計の基本について書いてみたい。 モバイル装置における機能設計の基本 『モバイル装置の開発手法の基本①』において長期スパンを見越した課題に対する外部設計が完成すると、そこから機能設計になる。外部設計では、主に対象の業務や必要なサービスなどの“解決する課題“、GUIや他装置や既存装置と接続するための“インタフェース”、法的ルールやSLAなどの”条件”、そして性能や拡張性などの“開発ポリシー”の4つを中心に設計することになる。ここから機能設計をするためには、基本的には“機能の定義“が必要となる。 モバイルにおける“機能の定義“では、全ての装置や通信を新規の装置に全て置き換えることは技術的にもコスト面でも難しいため、既存の装置が既に持っている機能を最大限再活用することが求められることが多い。そのため、まず最初に行う機能定義は 既存装置と新規/変更する装置での機能分担 が行われる。モバイルの場合は、これらをシーケンス図(Information flow / Procedure)で記載することが多い。 シーケンス図によって、既存装置を含む周辺装置と新規/変更する装置の機能分担と、どの装置にどんな入力データ&出力データが必要かを設計する。この入出力データはIF仕様書と言われ、具体的に装置間でやりとりするデータやそのデータを届けるための約束事(プロトコル)を規定したりする。特に、装置やネットワークの故障や過負荷などで正常にデータが届...

モバイル装置の開発手法の基本① 〜開発工程編〜

イメージ
 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年単位でのサービス継続のために、各モバイルオペレータやベンダは様々な開発ノウハウを保有しており、それらに基づいてこれまで開発してきた。また、日本の場合は総務省が「電気通信事故検証会議」として毎年その年の通信事故の検証結果を報告書としてまとめており、その中に再発防止策や教訓が記載されている。最新の取り組みは電気通信事故検証会議の報告を参照するとして、各モバイルオペレータが取り組むべき品質改善策の全体像については、少し古...

MECとは?vRANやNFVとの関係は?

イメージ
 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を基地局サイドに近付けるほどアーキテクチャ...

モバイルにおけるハンドオーバーとは?オーバーレイとは?

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

(試してみよう)仮想化環境の作り方

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