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

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