お客様の設定により、お客様情報が「非表示」となっております。お客様情報を表示するにはdアカウントでログインしてください。
お客様情報表示について

メディア系付加価値サービスを提供するメディア処理ノードの開発〜3.システム概要

3.2 サービス制御装置の特徴

サービスの柔軟な構築を行うために、サービス共通機能の共有・再利用およびサービスアプリケーションの選択起動を実装した。

(1)サービス共通機能の共有・再利用

MPNは複数のメディア系サービスを取り扱うことを想定しており、導入当初から表1のように留守番電話やメロディコールなど、音声メディアを取り扱う複数のサービスを提供している。この際、例えばユーザのプロファイル情報を取得する「プロファイル情報取得」のような機能はパラメータが異なるだけで、機能の呼出しや応答は複数のサービスで同様に実行できる。このように、複数のサービスアプリケーションから共通的に利用できるようにするため、機能ごとにAPI(Application Programming Interface)注意1を定義し、類似する機能群によってグループ化している(図5)。

図5 サービス共通機能の利用形態およびAPIの一例

例えばメロディコールサービスは、ユーザプロファイルを参照する機能が必要であるが、それは留守番電話サービスでも同様に必要である。このとき、プロファイル情報取得機能をAPI(図の例ではAPI_B_4)として規定しておけば、利用するサービスアプリケーションごとにパラメータを変えるだけで機能を共通的に利用できる。また、新たなサービスアプリケーションで本APIを利用すれば、同様の機能を容易に実現できる。

(2)サービスアプリケーションの選択起動

従来のシステムでは、類似サービスであっても各サービスごとに装置が開発され、機能提供を行っていた。このため、サービス開始前の設備構築時は、ユーザのサービス需要を正確に推測することが困難であるため、需要が想定を上回り、装置台数が不足してユーザに不便をかけることがないよう、ドコモ専用の高価な装置を余剰に導入するといった対応が必要であった。

MPNではこのリスクを低減した運用を可能とするため、従来個別の装置で提供していた複数のサービスを統合し、提供することとした。これらを実現するために、サービス制御装置のブレードサーバ実装上、オペレーションシステム(OS)とミドルウェアだけでなく、サービスアプリケーションも含め、MPNで提供する全サービスを個々のサーバで動作可能とする方式とした。

ブレードサーバ上で提供するサービスに共通的な処理や、各サービスに特化した処理のすべてを、ブレードサーバ上のメモリ領域にロードし動作させておくことになるため、どのサービスでも処理可能となる(図6)。実際に各ブレードでどのサービスを提供するのかは、MPNの固有情報を定義する局データ注意2に設定する情報(本例では、ブレードサーバで収容するメロディコールユーザの加入者番号帯)で決定する(図6(a))。

図6 メロディコールサービスの選択実行例

1つのMPNシステム内に複数のブレードサーバの搭載が可能であるが、これによりそれぞれのブレードサーバで異なるサービスもしくはすべて同一のサービスなどを選択して提供を行うことが可能である。

この仕組みを実装することにより、少ない設備数で需要を賄うことができるサービスは、容量に余裕のある他のサーバ(すでに他のサービスを提供済みでも)があれば、そこに集約することが可能である。さらに、契約数が伸びているサービスに必要な設備を、契約数が減少傾向にある設備から転用して賄うことで、設備の有効活用を行うことができる。

  • 注意1 OS やミドルウェアなどが提供する機能を、上位のソフトウェアが利用するためのインタフェース。
  • 注意2 局データ:ノードの動作条件、他のノードとの接続情報、加入者の収容条件などを規定したデータ。

本記事は、テクニカル・ジャーナルVol.17 No.1に、掲載されています。