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

モバイル装置の開発は正常ルート1に対して異常ルート9の設計が必要と言われているように、1機能を実現するために必要な設計・製造・試験のコストが大きく、装置の導入や変更にも多大なコストが発生する。そのため、一度新装置を導入すると、なかなか大きな変更や撤去ができなくなる。そのため、『モバイル装置の開発手法の基本① 〜開発工程編〜』の通り、法律や運用条件などの様々な要件から外部設計を行い、SLA99.999%を10年継続できるように機能設計を行なっていく必要がある。また、最近では『ネットワーク仮想化基盤におけるETSI NFV Stage3仕様に準拠したマルチベンダ対応MANOへの移行』の通り、製造請負と呼ばれる自社での開発から、標準化やOpen Sourceを利用した製品を利用した開発に開発方法も変わってきている。今回はそのようなモバイルにおける機能設計の基本について書いてみたい。

モバイル装置における機能設計の基本

『モバイル装置の開発手法の基本①』において長期スパンを見越した課題に対する外部設計が完成すると、そこから機能設計になる。外部設計では、主に対象の業務や必要なサービスなどの“解決する課題“、GUIや他装置や既存装置と接続するための“インタフェース”、法的ルールやSLAなどの”条件”、そして性能や拡張性などの“開発ポリシー”の4つを中心に設計することになる。ここから機能設計をするためには、基本的には“機能の定義“が必要となる。

モバイルにおける“機能の定義“では、全ての装置や通信を新規の装置に全て置き換えることは技術的にもコスト面でも難しいため、既存の装置が既に持っている機能を最大限再活用することが求められることが多い。そのため、まず最初に行う機能定義は既存装置と新規/変更する装置での機能分担が行われる。モバイルの場合は、これらをシーケンス図(Information flow / Procedure)で記載することが多い。

シーケンス図によって、既存装置を含む周辺装置と新規/変更する装置の機能分担と、どの装置にどんな入力データ＆出力データが必要かを設計する。この入出力データはIF仕様書と言われ、具体的に装置間でやりとりするデータやそのデータを届けるための約束事(プロトコル)を規定したりする。特に、装置やネットワークの故障や過負荷などで正常にデータが届かない時の異常系について、リトライをするのか、別装置で処理を再開するのか、諦めて該当処理を終わりにしてエラーを返すのか・・・など様々な規定を行う。

これらのシーケンス図やIF仕様書を基に、その装置の状態遷移図や保持すべきデータのデータ定義を行う。その中で、その装置が保持すべき機能の定義と要件、異常時の振る舞い、各機能の性能指標を規定していくことになる。また、特に異常時を考慮して、その時のリカバリや別装置を利用した迂回路の構築手順などを保守要件として定めていくことになる。

モバイル装置の多くの装置は、3GPPおよび3GPPから参照される各種ドキュメントによって標準仕様として規定されており、その標準仕様を最大限活用することが多いだろう。3GPPのドキュメントの関係性はSpecification Numberingにまとまっている。

• 全体機能分担:  23シリーズ(5Gであれば23.501)、28シリーズ(仮想化であれば28.500、5Gであれば28.530-533)
• シーケンス図:  23シリーズ(5Gであれば23.502など)、28シリーズ(FM/CM/PM/LCMでそれぞれ分離)
• プロトコル: 各23シリーズや28シリーズから参照されるStage3ドキュメント

これらの標準仕様をベースに、各制御信号(Signaling)の数や各オペレータの環境で発生し得る障害(特にネットワークの通信NGのパターン)から、性能や異常時の振る舞いを設計していく。そして、それらの障害や環境毎のチューニングに対応するための監視ポイントや保守機能・コマンドや手順から、保守運用方法とそれに必要な機能を設計していくことになる。特に保守運用という観点では、『モバイルネットワークの保守運用の基礎』に記載されているような、FullfilmentのNF設計やNW設計に必要なKPI(Key Performance Indicator)を決めたり、Assuranceに必要な障害特定ポイントや障害の影響を確認できるような情報収集内容を決めたりするだろう。

また、もう一つモバイル装置の機能設計で大切なことは“装置導入のために必要な機能“となる。既存装置によって構築されたネットワークに新規装置を導入するための手順やそれに伴う必要な機能、またはいくつかの既存装置を新規装置で交換するためのマイグレーション手順や必要な機能を追加検討したりする。

再利用可能な機能設計

『交換機制御ソフトウェアの変遷』(NTT技術史料館)の通り、テレコムやモバイルにおいてもソフトウェアの設計は徐々にソフトウェアコンポーネントを再利用できるような設計に改善され、アナログ交換機用の交換機用アセンブリから、徐々に高級言語が利用されモジュール化やコンポーネント化が促進し、更に分散化が行われている。また最近では、『REST指向での標準仕様設計方法について』の通り、サービス指向やリソース指向での設計になってきている。

いずれにしても、モバイル装置の場合は10年以上利用することを想定し、性能の拡張性、要件変更時に対応可能な拡張性、そのようなソフトウェア変更が必要となってもサービスを止めることなく(無中断)ソフトウェアを変更・更新できるような仕組みが必要となる。

(参考)機能設計の基本

機能設計における根本的な設計は最終的には“入出力“、“ロジック“、“データ“というプログラムにとって極めて基本的な部分の設計となっていく。これらをいかに再利用可能で、様々な変更があったとしても拡張できるような仕組みにしていくかが機能設計において重要となる。

そのために、様々なデザインパターンを駆使しつつ、ロジック＆データの抽象化が重要となる。特にロジックではインタフェースの共通化と抽象化しつつ、方式差分の処理を吸収する実装クラス化、そして物理差分を吸収するドライバ化などの手法が取られる。同様にデータについても外部装置に開示する外部スキーマ、それぞれのデータ間の関係を管理する論理スキーマ、そして物理的にデータをどのように配置するかの物理スキーマと分けて設計する方法がとられる。また最近では、これらのロジックとデータを命令型(Imperative)で抽象化する方式から、宣言型(Declarative)にすることでより複雑な変更に対応しやすい設計方式も採用されつつある。

モバイル装置においても、コンポーネントの再利用性を高めつつ安定的に利用できるソフトウェアに向けた開発手法として日々進化している。特にクラウド技術を取り入れた新しいソフトウェアの開発手法に向けて更に進化するだろう。