JP2014138284A - Ａｐｌ−ｓｃｍ−ｆｅおよびアプリケーション連携方法 - Google Patents

Abstract

【課題】ＳＩＰインタワーク処理が変更になる場合のソフトウェアの修正箇所を局所化し、また、連携するＡＰＬの信頼性、可用性、性能等の要件に応じて、ＡＰＬ−ＳＣＭ−ＦＥのサーバ構成を柔軟に変更可能とする。
【解決手段】複数のアプリケーションの連携サービスを端末に提供するＡＰＬ−ＳＣＭ−ＦＥ３０であって、サービス向け呼処理部３２と、基本呼処理部３１とを分離して備え、サービス向け呼処理部３２は、連携サービスの連携要求を取得し当該連携サービスで用いる呼処理の制御情報を、基本呼処理部３１に送出する複数ＡＰＬ連携部３２１と、複数のアプリケーションでそれぞれ用いられるＳＩＰ信号と標準のＳＩＰ信号との差分を変換するＳＩＰインタワーク部３２２とを備え、基本呼処理部３１は、端末に連携サービスを提供するための呼処理を制御情報を用いて実行する呼制御部３１２、３１５、３１６を備える。
【選択図】図２

Description

本発明は、ＮＧＮ（next generation network：次世代ネットワーク）における、ＡＰＬ−ＳＣＭ−ＦＥ（Application Service Coordination Manager Functional Entity）およびアプリケーション連携方法に関する。

ＮＧＮでのアプリケーションサービスを制御する機能として、ＩＴＵ−Ｔ勧告Ｙ．２０１２で規定されるＡＳＦ＆ＳＳＦ（Application Support Functions and Service Support Functions)がある（非特許文献１参照）。

ＡＳＦ＆ＳＳＦの構成要素であるＡＳ−ＦＥ（Application support functional entity）は、各サービスのサービスロジックを収容・実行するものである（特許文献１参照）。また、ＡＳＦ＆ＳＳＦの構成要素であるＡＰＬ−ＧＷ−ＦＥ（Application gateway functional entity）は、ＮＧＮ外部のアプリケーション（以下、「ＡＰＬ」）向けのゲートウェイであり、外部のＡＰＬ向けのＡＰＩ／プロトコルである、例えば、ＰａｒｌａｙＸ（非特許文献２参照）／ＳＯＡＰと、ＮＧＮ向けの呼制御プロトコルであるＳＩＰとのインタワークを行うものである。ＡＳＦ＆ＳＳＦの構成要素であるＳＳ−ＦＥ（Service switching functional entity）は、ＰＳＴＮ（Public Switched Telephone Network：公衆交換電話網）においてサービスを提供する高度ＩＮ（Intelligent Network）のＳＣＰ（Service Control Point）にアクセスするための機能要素である。

また、ＡＳＦ＆ＳＳＦの構成要素であるＡＰＬ−ＳＣＭ−ＦＥは、ＡＳ−ＦＥやＡＰＬ−ＧＷ−ＦＥ、ＳＳ−ＦＥの複数のＡＰＬ／サービスとのインタラクション（連携）を管理する。

特開2011-40000号公報

ITU-T: Functional requirements and architecture of the NGN, ITU-T Recommendation Y.2012 (Jul. 2006) ETSI: Open Service Access (OSA); Parlay X Web Services, ETSI ES, 202, 504, V1.1.1 (May. 2008)

従来のＮＧＮにおけるＡＰＬ−ＳＣＭ−ＦＥでは、（１）ＮＧＮで呼制御を行うＳ−ＣＳＣ−ＦＥ（Serving Call Session Control Functional Entity）、および、ガイダンス等のメディアリソースを制御するＭＲＣ−ＦＥ（Media Resource Control Functional Entity）と連携したＳＩＰセッション制御を行う「呼処理機能」と、（２）ＡＰＬ−ＧＷ−ＦＥおよびＡＳ−ＦＥと連携したＳＩＰセッション制御を行う「サービス向け呼処理機能」とが一体として構成されている。つまり、基本呼処理機能とサービス向け呼処理機能とを分けることなく、ＡＰＬ−ＳＣＭ−ＦＥの機能として一連のソフトウェアが開発される。

ここで、連携するＡＰＬ／サービスによってＳＩＰのインタフェース仕様が異なる場合、ＡＰＬ−ＳＣＭ−ＦＥでＳＩＰインタワークを行う必要があるが、一体として構成されたＡＰＬ−ＳＣＭ−ＦＥにおいて、連携するＡＰＬ／サービスを追加変更する際には、基本呼処理機能とサービス向け呼処理機能との両方において関連する箇所のソフトウェアの修正が必要となる。

また、ＡＰＬ−ＳＣＭ−ＦＥに要求される信頼性、可用性、性能は、連携するＡＰＬ／サービスによって異なる。例えば、基本的に停止することが許されない高い信頼性、可用性、性能を要求される従来のＰＳＴＮと同程度の高い信頼性等が要求される場合もあれば、低くて構わない場合もある。しかしながら、従来のＡＰＬ−ＳＣＭ−ＦＥでは、基本呼処理機能とサービス向け呼処理機能の両方が一体となった構成のため、連携するＡＰＬ／サービスに適合させて柔軟にサーバ構成を変更することができない。例えば、基本呼処理機能は高い信頼性等を維持しつつ、サービス向け呼処理機能は、連携するＡＰＬ／サービスに応じて、信頼性等を低めに設定し、開発費用や運用費用の削減を実現するような構成にすることはできない。

本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、連携するＡＰＬ／サービスの追加変更によってＳＩＰインタワーク処理が変更になる場合のソフトウェアの修正箇所を局所化し、また、連携するＡＰＬ／サービスの信頼性、可用性、性能等の要件に応じて、ＡＰＬ−ＳＣＭ−ＦＥのサーバ構成を柔軟に変更可能とすることにある。

上記目的を達成するため、本発明は、複数のアプリケーションを連携させた連携サービスを端末に提供するＡＰＬ−ＳＣＭ−ＦＥ（Application Service Coordination Manager Functional Entity）であって、前記ＡＰＬ−ＳＣＭ−ＦＥは、サービス向け呼処理部と、基本呼処理部とを分離して備え、前記サービス向け呼処理部は、前記連携サービスの連携要求を取得し、当該連携サービスで用いる呼処理の制御情報を、前記基本呼処理部に送出する複数ＡＰＬ連携部と、前記複数のアプリケーションでそれぞれ用いられるＳＩＰ信号と、標準のＳＩＰ信号との差分を変換するＳＩＰインタワーク部と、を備え、前記基本呼処理部は、端末に前記連携サービスを提供するための呼処理を、前記制御情報を用いて実行する呼制御部を備える。

また、本発明は、ＡＰＬ−ＳＣＭ−ＦＥが、複数のアプリケーションを連携させた連携サービスを端末に提供するアプリケーション連携方法であって、前記ＡＰＬ−ＳＣＭ−ＦＥは、サービス向け呼処理部と、基本呼処理部とを分離して備え、前記サービス向け呼処理部は、要求元のアプリケーションから、少なくとも１つの他のアプリケーションへの連携要求のＳＩＰ信号を取得する取得ステップと、前記連携要求のＳＩＰ信号を、前記他のアプリケーション用のＳＩＰ信号に変換するＳＩＰインタワークステップと、前記他のアプリケーション用のＳＩＰ信号を前記他のアプリケーションに送信し、処理結果を取得する取得ステップと、 前記処理結果が妥当な場合、前記要求元のアプリケーションと前記他のアプリケーションとの連携サービスに対応する制御情報を前記基本呼処理部に送出する送出ステップと、を行い、前記基本呼処理部は、端末に前記連携サービスを提供するための呼処理を、前記制御情報を用いて実行する呼制御ステップを行う。

また、本発明は、ＡＰＬ−ＳＣＭ−ＦＥが、複数のアプリケーションを連携させた連携サービスを端末に提供するアプリケーション連携方法であって、前記ＡＰＬ−ＳＣＭ−ＦＥは、サービス向け呼処理部と、基本呼処理部とを分離して備え、前記サービス向け呼処理部は、前記端末が送信した連携要求のＳＩＰ信号を、前記基本呼処理部から取得する取得ステップと、前記連携要求のＳＩＰ信号を、第１のアプリケーション用のＳＩＰ信号に変換し、前記変換後のＳＩＰ信号を第１のアプリケーションに送信して、第１の処理結果のＳＩＰ信号を取得する取得ステップと、第１の処理結果のＳＩＰ信号を、少なくとも１つの第２のアプリケーション用のＳＩＰ信号に変換し、前記変換後のＳＩＰ信号を第２のアプリケーションに送信して、第２の処理結果を取得する取得ステップと、前記第２の処理結果が妥当な場合、第１のアプリケーションと第２のアプリケーションとの連携サービスに対応する制御情報を前記基本呼処理部に送出する送出ステップと、を行い、前記基本呼処理部は、前記端末に連携サービスを提供するための呼処理を、前記制御情報を用いて実行する呼制御ステップを行う。

本発明によれば、連携するＡＰＬ／サービスを追加変更によってＳＩＰインタワーク処理が変更になる場合のソフトウェアの修正箇所を局所化することができる。また、連携するＡＰＬ／サービスの信頼性、可用性、性能等の要件に応じて、ＡＰＬ−ＳＣＭ−ＦＥのサーバ構成を柔軟に変更可能とすることができる。

本実施形態に係るＡＳＦ＆ＳＳＦの全体構成を示す図である。 本実施形態に係るＡＰＬ−ＳＣＭ−ＦＥの構成例を示す機能ブロック図である。 本実施形態に係る基本呼処理部の部品の一例を示す図である。 本実施形態に係るＩＦ更新部による連携ルールおよびＳＩＰインタワークの追加の例を説明するための図である。 本実施形態に係るＩＦ更新部による連携ルールおよびＳＩＰインタワークの変更の例を説明するための図である。 本実施形態に係るＩＦ更新部による連携ルールおよびＳＩＰインタワークの削除の例を説明するための図である。 本実施形態に係るＡＰＬ−ＳＣＭ−ＦＥにおける第１の処理の流れを説明するための図である。 本実施形態に係るＡＰＬ−ＳＣＭ−ＦＥにおける第２の処理の流れを説明するための図である。

以下、本発明の実施の形態について、図面を参照して説明する。

図１は、本実施形態に係るＡＳＦ＆ＳＳＦ１００の全体構成を示す図である。ＡＳＦ＆ＳＳＦ１００は、ＮＧＮにおいて、アプリケーションサービスを制御する機能を有する。図示するＡＳＦ＆ＳＳＦ１００は、ＡＰＬ−ＧＷ−ＦＥ（Application gateway functional entity）１０と、ＡＳ−ＦＥ（Application Support Functional Entity）２０と、ＡＰＬ−ＳＣＭ−ＦＥ（Application Service Coordination Manager Functional Entity）３０と、ＳＳ−ＦＥ（Service Switching Functional Entity）４０とを備える。

ＡＰＬ−ＧＷ−ＦＥ１０は、ＮＧＮの外部のＡＰＬサーバ２と接続されるとともに、ＡＳ−ＦＥ２０、ＡＰＬ−ＳＣＭ−ＦＥ３０およびＳＳ−ＦＥ４０と接続され、外部のＡＰＬ向けのインタフェースと、ＮＧＮにおけるＳＩＰによる呼処理を実行する。ＡＳ−ＦＥ２０は、ＡＰＬ−ＧＷ−ＦＥ１０、ＡＰＬ−ＳＣＭ−ＦＥ３０およびＳＳ−ＦＥ４０と接続され、各アプリケーションサービスのサービスロジック（サービスを実現するためのアプリケーションプログラム）を収容し、実行する。ＡＰＬ−ＳＣＭ−ＦＥ３０は、ＡＰＬ−ＧＷ−ＦＥ１０、ＡＳ−ＦＥ２０およびＳＳ−ＦＥ４０と接続され、複数のＡＰＬを実行する際の連携を制御する。ＳＳ−ＦＥ４０は、ＡＰＬ−ＧＷ−ＦＥ１０、ＡＳ−ＦＥ２０およびＡＰＬ−ＳＣＭ−ＦＥ３０と接続され、従来のＰＳＴＮ（Public Switched Telephone Networks）との連携を制御する。

図２は、本実施形態に係るＡＰＬ−ＳＣＭ−ＦＥ３０の構成例を示す機能ブロック図である。

本実施形態のＡＰＬ−ＳＣＭ−ＦＥ３０は、従来は一体型であったものを基本呼処理部３１と、サービス向け呼処理部３２とに分離した構成とする。基本呼処理部３１は、ＮＧＮのネットワークを介して、呼制御を行うＳ−ＣＳＣ−ＦＥ５０、またはガイダンス等のメディアリソースを制御するＭＲＣ−ＦＥ６０と連携したＳＩＰ（Session Initiation Protocol）セッションを制御し、図示しない端末との呼処理を実行する。なお、端末は、例えば、電話回線を介してＮＧＮに接続されるＩＰ（Internet Protocol）電話や、無線回線を介して接続される携帯電話機、若しくは、インターネットを介して接続されるコンピュータ等である。

サービス向け呼処理部３２は、ＡＰＬ−ＧＷ−ＦＥ１０を介したＡＰＬサーバ２のAPL-b２２、またはＡＳ−ＦＥ２０に収容されるAPL-a２１と接続され、複数のＡＰＬと連携したＳＩＰセッションを制御する。

以下に、基本呼処理部３１およびサービス向け呼処理部３２の詳細を説明する。

＜基本呼処理部＞
本実施形態に係るＡＰＬ−ＳＣＭ−ＦＥ３０の基本呼処理部３１は、具体的には、特許文献１（特開2011−40000号公報）に記載された通信サービス提供サーバが備える構成を改良し、新たな機能を追加したものとして実現する。特許文献１に記載された通信サービス提供サーバは、ＡＳ−ＦＥにおいて、各ＡＰＬのサービスに依存しない共通部分を部品（プログラムのモジュール）として予め用意しておくことで、呼接続や、呼切断、ガイダンス再生等の基本的な呼処理を実行させて、通信サービスを提供する。本実施形態におけるＡＰＬ−ＳＣＭ−ＦＥ３０は、基本呼処理部３１とサービス向け呼処理部３２とに分離した構成とし、基本呼処理部３１については、特許文献１に記載の呼処理機能を改良したものとして実現するものである。以下、具体的に説明する。

図２に示すように、ＡＰＬ−ＳＣＭ−ＦＥ３０の基本呼処理部３１は、通信プロトコルスタック３１６と、ＵＡ（User Agent）機能部３１５と、部品機能部３１２と、連携ＡＰＬ部３１１と、通信部３１０とを備える。なお、ＵＡ機能部３１５、部品機能部３１２および通信プロトコルスタック３１６は、請求項の呼制御部に相当する。

通信プロトコルスタック３１６は、ネットワークで用いられるプロトコルのプロトコルスタックとして機能し、例えば、ＳＩＰ等のプロトコルに基づき、メッセージのエンコードおよびデコードを行う。

ＵＡ機能部３１５は、端末との間でセッションを確立するためのメッセージの送受信を行う。具体的には、ＵＡ機能部３１５は、複数のＵＡ（例えば、発ＵＡ、着ＵＡ、発ＭＲＣ−ＦＥ ＵＡ、着ＭＲＣ−ＦＥ ＵＡなど）として機能し、対向装置ごとの通信プロトコルレベルでの状態管理を行う。また、ＵＡ機能部３１５は、部品機能部３１２内ですでに部品が生成されている場合には、その生成されている部品に対してメッセージを送信し、部品が生成されていない場合には、部品機能部３１２内の後述する部品管理制御部３１３に対してメッセージを送信する。

部品機能部３１２は、部品管理制御部３１３および部品の集合を示す呼処理部品３１４を備え、サービスに依存しないＳＩＰ信号レベルでのセッション制御を行う。この部品機能部３１２は、異なる通信サービスに対して、共通して利用可能なソフトウェアのモジュール（部品）を、通信サービスに応じて実行する。

部品管理制御部３１３は、ＵＡ機能部３１５や、連携ＡＰＬ部３１１から取得したメッセージ（制御情報（例えば、後述する「部品の生成に関する情報」等））に応じて、まだ部品のインスタンスが作成されていない場合に、対応する部品を生成し、メッセージの出力を行う。この部品管理制御部３１３による部品のインスタンスの生成は、例えば、セッション毎に行われ、セッションの開始時に、部品管理制御部３１３が、部品のインスタンスを生成し、セッションの終了時に当該部品のインスタンスを削除する。

呼処理部品３１４は、異なる通信サービスにおいて共通する処理を実現する１つ以上の部品を有する。なお、部品機能部３１２は、図２に示す呼処理部品３１４だけでなく、それ以外の部品も備えることとしてもよい。

図３は、部品機能部３１２が備える呼処理部品の例を示す表である。図示するように、発呼部品、接続部品、切断部品、ガイダンス再生部品、メディア張り替え部品、メディア変更部品などの呼処理に関する部品を備える。これらの呼制御部品は、取得したメッセージ（制御情報）に応じて、当該部品の機能を実現するためのメッセージを出力する。

このように、ＵＡ機能部３１５および部品機能部３１２は、複数のＡＰＬを連携した連携サービスを提供するための呼処理を、メッセージ（制御情報）を用いて実行する。

連携ＡＰＬ部３１１は、サービス向け呼処理部３２から、連携サービスの制御情報（例えば、部品の生成に関する情報等）を、通信部３１０を介して取得し、当該制御情報を部品機能部３１２に出力する。また、連携ＡＰＬ部３１１は、端末が送信した連携サービスの連携要求のメッセージを部品機能部３１２から取得すると、当該メッセージを、通信部３１０を介して、サービス向け呼処理部３２の複数ＡＰＬ連携部３２１に送信する。

通信部３１０は、サービス向け呼処理部３２との間で、情報の送受信を行う通信インタフェースにより構成される。

＜サービス向け呼処理部＞
次に、本実施形態のＡＰＬ−ＳＣＭ−ＦＥ３０のサービス向け呼処理部３２について説明する。図２に示すサービス向け呼処理部３２は、通信プロトコルスタック３２５と、ＩＦ更新部３２４と、通信部３２３と、ＳＩＰインタワーク部３２２と、複数ＡＰＬ連携部３２１と、ルール記憶部３２６とを備える。本実施形態のＡＰＬ−ＳＣＭ−ＦＥ３０は、サービス向け呼処理部３２において、複数のＡＰＬを連携して利用する通信サービスについての制御を実行する複数ＡＰＬ連携部３２１を、基本呼処理部３１とは分離した構成として備えることを特徴とする。

また、ＡＰＬ−ＳＣＭ−ＦＥ３０の構成を、基本呼処理部３１とサービス向け呼処理部３２とに分離したことに伴い、各連携サービスに対応させてルール記憶部３２６の連携ルールまたはＳＩＰインタワークルールを更新するためのＩＦ更新部３２４を、サービス向け呼処理部３２に備えることを特徴とする。以下、具体的に説明する。

通信プロトコルスタック３２５は、各ＡＰＬとの通信で用いられるプロトコルのプロトコルスタックとして機能し、例えば、ＳＩＰ等のプロトコルに基づき、メッセージのエンコードおよびデコードを行う。

ＩＦ更新部３２４は、ルール記憶部３２６に記憶された連携ルールまたはＳＩＰインタワークルールを更新（追加、変更、削除）する。このＩＦ更新部３２４が行うルール記憶部３２６の更新は、サービス向け呼処理部３２の内部の修正に限られたものなるため、基本呼処理部３１について、ソフトウェアの修正を行う必要はない。なお、このＩＦ更新部３２４が行う、ルール記憶部３２６の具体例については、後述する。

通信部３２３は、基本呼処理部３１との間で、情報の送受信を行う通信インタフェースにより構成される。

ＳＩＰインタワーク部３２２は、ルール記憶部３２６のＳＩＰインタワークルールを参照して、各ＡＰＬでそれぞれ用いられるＳＩＰ信号と、標準のＳＩＰ信号との差分を変換する。

複数ＡＰＬ連携部３２１は、複数のＡＰＬを連携した連携サービスについての制御を実行する。この複数ＡＰＬ連携部３２１は、連携サービスの制御を通信部３２３を介して基本呼処理部３１とメッセージを送受信することにより実現すると共に、ルール記憶部３２６に記憶された対応する連携ルールを用いて連携サービスに依存しない通信サービスの制御を、部品機能部３１２にリモートで指示することで実現する。具体的には、複数ＡＰＬ連携部３２１は、部品の生成に関する情報（例えば、部品の種類（発呼、接続、切断、ガイダンス再生等）、連携サービスを提供するＡＰＬ（APL-a２１、APL-b２２）のアドレス情報等の制御情報を作成して、基本呼処理部３１の連携ＡＰＬ部３１１を介して、部品機能部３１２に送出する。すなわち、連携サービスの連携要求を取得し、当該連携サービスで用いる呼処理の制御情報を、基本呼処理部３１に送出する。

ルール記憶部３２６には、連携サービスを提供するための連携ルールおよび各ＡＰＬで用いられるＳＩＰインタワークルールが記憶される。

以上説明したように、本実施形態のＡＰＬ−ＳＣＭ−ＦＥ３０は、基本呼処理部３１とサービス向け呼処理部３２とを分離した構成とし、それぞれの連携サービスに応じた呼制御を行う。

なお、本実施形態のＡＰＬ−ＳＣＭ−ＦＥ３０は、例えば、ＣＰＵと、メモリと、ＨＤＤ等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされたＡＰＬ−ＳＣＭ−ＦＥ３０用のプログラムを実行することにより、ＡＰＬ−ＳＣＭ−ＦＥ３０の各機能が実現される。また、ＡＰＬ−ＳＣＭ−ＦＥ３０用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。

次に、本実施形態の処理について説明する。

図４から図６は、本実施形態のＡＰＬ−ＳＣＭ−ＦＥ３０のサービス向け呼処理部３２のＩＦ更新部３２４による連携ルールおよびSIPインタワークルールの追加、変更、削除の例を説明するための図である。なお、ＩＦ更新部３２４は、連携ルールおよびＳＩＰインタワークルールの追加、変更、削除等の指示を、システム管理者等から、ネットワークを介して受信する、または、ＡＰＬ−ＳＣＭ−ＦＥ３０が備える入力部（不図示）を介して取得することなどにより実行する。

図４は、連携ルールおよびＳＩＰインタワークルールの追加の例を説明するための図である。図４（ａ）では、初期状態のルール記憶部３２６として、少なくとも１つの連携ルールと、少なくとも１つのＳＩＰインタワークルールとが記憶されている。図４（ｂ）は、連携ルールＸの追加の例を示している。ＩＦ更新部３２４は、ＡＰＬの新たな連携サービスを実現するために、連携ルールＸをルール記憶部３２６に追加する。図４（ｃ）は、連携ルールおよびＳＩＰインタワークルールの追加の例を示している。ＩＦ更新部３２４は、ＡＰＬの新たな連携サービスを実現するために、連携ルールＹをルール記憶部３２６に追加するとともに、連携ルールＹで連携するＡＰＬで用いられるＳＩＰインタワークルール（ここでは、ＡＰＬ−ＧＷ−ＦＥω用のＳＩＰインタワークルール）をルール記憶部３２６に追加する。

図５は、連携ルールおよびＳＩＰインタワークルールの変更の例を説明するための図である。図５（ａ）では、初期状態のルール記憶部３２６として、図４（ａ）と同様の連携ルールとＳＩＰインタワークルールとが記憶されている。図５（ｂ）は、連携ルール０１の変更の例を示している。ＩＦ更新部３２４は、ルール記憶部３２６の連携ルール０１を連携ルール０１’に変更する。図５（ｃ）は、ＳＩＰインタワークルールの変更の例を示している。ＩＦ更新部３２４は、ルール記憶部３２６のＡＰＬ−ＧＷ−ＦＥα用のＳＩＰインタワークルールを、ＡＰＬ−ＧＷ−ＦＥα用のＳＩＰインタワークルール’に変更する。

図６は、連携ルールおよびＳＩＰインタワークルールの削除の例を説明するための図である。図６（ａ）では、初期状態のルール記憶部３２６として、図４（ａ）と同様の連携ルールとＳＩＰインタワークルールとが記憶されている。図６（ｂ）は、連携ルールＸの削除の例を示している。ＩＦ更新部３２４は、所定のアプリケーションの連携サービスを廃止するために、連携ルール０２をルール記憶部３２６から削除する。図６（ｃ）は、ＳＩＰインタワークルールの削除の例を示している。ＩＦ更新部３２４は、ＡＰＬ−ＧＷ−ＦＥα用のＳＩＰインタワークルールをルール記憶部３２６から削除する。

このように、ＩＦ更新部３２４は、複数のＡＰＬを連携した連携サービスに対応して、連携ルールおよびＳＩＰインタワークルールの追加、変更、削除等を行うことができ、その際に、サービス向け呼処理部３２の内部のみ修正すればよく、基本呼処理部３１を修正する必要はない。よって、本実施形態のＡＰＬ−ＳＣＭ−ＦＥ３０によれば、連携ルールおよびＳＩＰインタワークルールを追加、変更、削除する際にソフトウェアの修正箇所を局所化することができる。

図７および図８は、本実施形態のＡＰＬ−ＳＣＭ−ＦＥ３０の処理を示す説明図である。図７に示す例では、ＡＳ−ＦＥ２０に搭載されたAPL-a２１（例えは、Click to Dial(C2D)などのＡＰＬ）が、ＡＰＬ−ＧＷ−ＦＥ１０に接続されたＡＰＬサーバ２のAPL-b２２（例えば、ＳＮＳなどのＡＰＬ）と連携した上で、ＮＧＮの端末８０に対して発呼する処理を説明する。

具体的なサービスイメージとしては、ユーザが図示しない端末を用いて、APL-a２１に対して自身のアドレスaと、電話したい相手のアドレスbと、連携先のＡＰＬ（APL-b２２）の識別情報などを入力する。これにより、図７の処理が開始され、APL-b２２のＳＮＳアプリは発信者のアドレスaと着信者のアドレスbが互いにブロック（拒否）されていないかチェックし、ブロックされていない場合にAPL-a２１は、APL-b２２と連携して電話したい相手のアドレスbの端末８０に発呼する。

まず、Ｓ１１で、APL-a２１は、ユーザが入力した入力情報（自身のアドレスa、電話したい相手のアドレスb、連携先のＡＰＬ（APL-b２２）、その他の情報など）を受け付けて、連携要求（ＳＩＰ信号）を、ＡＰＬ−ＳＣＭ−ＦＥ３０の通信プロトコルスタック３２５に送信する。連携要求には、入力情報および自身のＡＰＬ（APL-a２１）の識別情報が含まれているものとする。

なお、ユーザが入力した入力情報に、連携先のＡＰＬ（APL-b２２）の識別情報が含まれていない場合があってもよい。この場合、連携要求には、連携先のＡＰＬ（APL-a２１）の識別情報はなく、自身のＡＰＬ（APL-a２１）の識別情報のみが含まれているものとする。

Ｓ１２で、通信プロトコルスタック３２５は、連携要求を受信すると、ＳＩＰ信号受信処理を行った後、ＳＩＰインタワーク部３２２へ連携要求の処理を依頼する。

Ｓ１３で、ＳＩＰインタワーク部３２２は、ルール記憶部３２６のＡＳ−ＦＥ２０用のＳＩＰインタワークルールを参照してＳＩＰ信号変換を行い、ＡＳ−ＦＥ２０のSIPと標準SIPとの差分（方言）を除去し、ＳＩＰ信号変換後の連携要求を複数ＡＰＬ連携部３２１に送出する。

Ｓ１４で、複数ＡＰＬ連携部３２１は、連携要求を受け付けると、ルール記憶部３２６の連携ルールを参照し、APL-a２１からAPL-b２２への連携の許可または不許可を判定する。例えば、複数ＡＰＬ連携部３２１は、ルール記憶部３２６にAPL-a２１からAPL-b２２への連携ルールが記憶（登録）されている場合は、連携を許可すると判別し、APL-a２１からAPL-b２２への連携ルールが記憶されていない場合は、連携を許可しないと判別する。複数ＡＰＬ連携部３２１は、不許可の場合は処理を終了し、許可の場合はＳＩＰインタワーク部３２２に連携要求を送信する。

なお、連携要求に、連携先のＡＰＬ（APL-b２２）の識別情報がなく、連携要求元のＡＰＬ（APL-a２１）の識別情報のみが含まれている場合、複数ＡＰＬ連携部３２１は、ルール記憶部３２６を参照し、連携要求元をAPL-a２１とする連携ルールを特定し、当該連携ルールに設定された連携先のＡＰＬ（APL-b２２）を決定し、連携を許可すると判別する。

Ｓ１５で、ＳＩＰインタワーク部３２２は、複数ＡＰＬ連携部３２１から連携要求を受け付けると、ルール記憶部３２６に記憶された、連携先であるＡＰＬ−ＧＷ−ＦＥ１０用のＳＩＰインタワークルールを参照して、当該連携要求をＡＰＬ−ＧＷ−ＦＥ１０の方言にＳＩＰ信号変換を行い、通信プロトコルスタック３２５にＳＩＰ信号の送信を依頼する。

Ｓ１６で、通信プロトコルスタック３２５は、ＡＰＬ−ＧＷ−ＦＥ１０にＳＩＰ信号（連携要求）を送信する。

Ｓ１７で、ＡＰＬ−ＧＷ−ＦＥ１０に接続されたＡＰＬサーバ２のAPL-b２１は、連携要求で要求された連携処理を実施（ここでは、発信者と着信者が互いにブロック（拒否）されていないかチェック）し、通信プロトコルスタック３２５に処理結果を返送する。

Ｓ１８で、通信プロトコルスタック３２５は、処理結果を受信すると、ＳＩＰ信号受信処理を行った後、ＳＩＰインタワーク部３２２へ処理を依頼する。

Ｓ１９で、ＳＩＰインタワーク部３２２は、Ｓ１３と同様にＳＩＰ信号変換を行い、ＡＰＬ−ＧＷ−ＦＥ１０の差分を除去し、複数ＡＰＬ連携部３２１に処理結果を送出する。

Ｓ２０で、複数ＡＰＬ連携部３２１は、連携処理の処理結果の妥当性を判定し、妥当な場合、ＳＩＰインタワーク部３２２に処理を依頼する。妥当性の判断としては、例えば、処理結果がＯＫの場合（ここでは、発信者と着信者が互いにブロックされていない場合）、妥当であると判断する。また処理結果のデータフォーマットが、対応する連携ルール（APL-a２１→APL-b２２の連携ルール）に合っているかなどをチェックすることが考えられる。複数ＡＰＬ連携部３２１は、妥当でない場合は処理を終了し、妥当な場合はＳＩＰインタワーク部３２２に処理結果を送出する。

Ｓ２１で、ＳＩＰインタワーク部３２２は、複数ＡＰＬ連携部３２１から処理結果を受け付けると、ルール記憶部３２６のＡＳ−ＦＥ２０用のＳＩＰインタワークルールを参照して、当該処理結果をＡＳ−ＦＥ２０の方言にＳＩＰ信号変換を行い、通信プロトコルスタック３２５にＳＩＰ信号の送信を依頼する。

Ｓ２２で、通信プロトコルスタック３２５は、ＡＳ−ＦＥ２０にＳＩＰ信号（処理結果）を送信する。

Ｓ２３で、ＡＳ−ＦＥ２０のAPL-a２１はＳＩＰ信号（処理結果）を受信すると、相手先のアドレスbへの発呼要求を通信プロトコルスタック３２５に送信する。

Ｓ２４で、通信プロトコルスタック３２５は、発呼要求を受信すると、ＳＩＰ信号受信処理を行った後、ＳＩＰインタワーク部３２２へ発呼要求を送出する。

Ｓ２５で、ＳＩＰインタワーク部３２２は、発呼要求を受け付けると、Ｓ１３と同様にＳＩＰ信号変換を行い、ＡＳ−ＦＥ２０のＳＩＰと標準ＳＩＰとの差分を除去し、複数ＡＰＬ連携部３２１に発呼要求を送出する。

Ｓ２６で、複数ＡＰＬ連携部３２１は、発呼要求を受け付けると、ルール記憶部３２６の対応する連携ルール（APL-a２１→APL-b２２の連携ルール）を参照し、使用する部品を特定し、特定した部品の識別情報等を指定した発呼依頼を通信部３２２に送出する。具体的には、複数ＡＰＬ連携部３２１は、対応する連携ルールに基づき、部品の生成に関する情報（例えば、部品の種類（発呼、接続、切断、ガイダンス再生等）、連携サービスを提供するＡＰＬ（APL-a２１、APL-b２２）のアドレス情報等の制御情報を作成して、基本呼処理部３１の連携ＡＰＬ部３１１を介して、部品機能部３１２に送出する。

Ｓ２７で、通信部３２３は、基本呼処理部３１の通信部３１０へ発呼依頼を転送する。

Ｓ２８で、基本呼処理部３１の通信部３１０は、連携ＡＰＬ部３１１に対して発呼依頼を転送する。

Ｓ２９で、連携ＡＰＬ部３１１は、発呼依頼で指定された部品等（ここでは、呼処理部品の発呼、ＵＡ機能部の着ＵＡ）を用いてユーザがＳ１１で入力したアドレスｂの相手端末８０に発呼する。

なお、図７に示す処理において、APL-b２２の連携処理結果をAPL-a２１に返送することなく、発呼処理を行うこととしてもよい。この場合、Ｓ２０で、複数ＡＰＬ連携部３２１は、連携処理の処理結果の妥当性を判定し、妥当な場合、Ｓ２１からＳ２５を行うことなくＳ２６（使用する部品等を特定し、発呼依頼を通信部３２２に送出）に進み、以降の処理を行うこととしてもよい。

図８は、ＮＧＮの端末８０から発信し、ＡＳ−ＦＥ２０に搭載されたAPL-a２１（例えば、番号変換）と、ＡＰＬ−ＧＷ−ＦＥ１０に接続されたＡＰＬサーバ２のAPL-b２２（例えば、ＳＮＳ）が連携する処理を例示する。具体的なサービスイメージとしては、ユーザが特番（例えば、0120-xxx-yyy）に発信し、APL-a２１の番号変換アプリは、番号変換する（例えば、0120-xxx-yyy → 0422-aa-bbbb）。そして、APL-b２２のＳＮＳアプリと連携して発信者と着信者が互いにブロック（拒否）されていないかチェックし、ブロックされていない場合に発信を許可する。

まず、Ｓ３１で、端末８０が所定の番号（例えば、0120-xxx-yyy）に発信する。この発信（連携要求）は、Ｐ−ＣＳＣ−ＦＥ７０およびＳ−ＣＳＣ−ＦＥ６０を介してＡＰＬ−ＳＣＭ−ＦＥ３０に送信される。ＡＰＬ−ＳＣＭ−ＦＥ３０の基本呼処理部３１において、当該発信は、通信プロトコルスタック３１６、ＵＡ機能部３１５の発ＵＡおよび呼処理部品３１４の接続を介して、連携ＡＰＬ部３１１に到達する。

Ｓ３２で、連携ＡＰＬ部３１１は、所定の番号への発信であるため、対応するAPL-a２１への連携要求を通信部３１０に送出する。

Ｓ３３で、通信部３１０は、サービス向け呼処理部３２の通信部３２３にAPL-a２１への連携要求を転送する。

Ｓ３４で、通信部３２３は、複数ＡＰＬ連携部３２１にAPL-a２１への連携要求を転送する。

Ｓ３５で、複数ＡＰＬ連携部３２１は、ルール記憶部３２６のAPL-a２１に対応する連携ルールを参照して、APL-a２１の接続先（ＡＳ−ＦＥ２０）を決定し、ＳＩＰインタワーク部３２２に処理を依頼する。

Ｓ３６で、ＳＩＰインタワーク部３２２は、複数ＡＰＬ連携部３２１から処理の依頼を受け付けると、ルール記憶部３２６のAPL-a２１が搭載されたＡＳ−ＦＥ２０用のＳＩＰインタワークルールを参照して、当該連携要求をＡＳ−ＦＥ２０の方言にＳＩＰ信号変換を行い、通信プロトコルスタック３２５にＳＩＰ信号の送信を依頼する。

Ｓ３７で、通信プロトコルスタック３２５は、ＡＳ−ＦＥ２０にＳＩＰ信号（連携要求）を送信する。

Ｓ３８で、ＡＳ−ＦＥ２０のAPL-a２１は、連携要求で依頼された処理である番号変換（例えば、0120-xxx-yyy → 0422-aa-bbbb）を行い、通信プロトコルスタック３２５にＳＩＰ信号（処理結果）を送信する。

Ｓ３９で、通信プロトコルスタック３２５は、ＳＩＰ信号受信処理を行った後、ＳＩＰインタワーク部３２２へＳＩＰ信号（処理結果）のＳＩＰ信号変換処理を依頼する。

Ｓ４０で、ＳＩＰインタワーク部３２２は、ルール記憶部３２６のＡＳ−ＦＥ２０用のＳＩＰインタワークルールを参照してＳＩＰ信号変換を行い、ＡＳ−ＦＥ２０のＳＩＰと標準ＳＩＰとの差分（方言）を除去し、ＳＩＰ信号変換後の処理結果を複数ＡＰＬ連携部３２１に送出する。

Ｓ４１で、複数ＡＰＬ連携部３２１は、ルール記憶部３２６に記憶されたＡＳ−ＦＥ２０に対応する連携ルールを参照して、連携先のAPL-b２２の接続先（ＡＰＬ−ＧＷ−ＦＥ１０）を決定し、ＳＩＰインタワーク部３２２にＳＩＰ信号（処理結果）のＳＩＰ信号変換処理を依頼する。

Ｓ４２で、ＳＩＰインタワーク部３２２は、複数ＡＰＬ連携部３２１から依頼を受け付けると、ルール記憶部３２６に記憶されたＡＰＬ−ＧＷ−ＦＥ１０用のＳＩＰインタワークルールを参照して、処理結果をＡＰＬ−ＧＷ−ＦＥ１０の方言にＳＩＰ信号変換を行い、通信プロトコルスタック３２５にＳＩＰ信号の送信を依頼する。

Ｓ４３で、通信プロトコルスタック３２５は、ＡＰＬ−ＧＷ−ＦＥ１０にＳＩＰ信号を送信する。

Ｓ４４で、ＡＰＬ−ＧＷ−ＦＥ１０に接続されたＡＰＬサーバ２のAPL-b２２は、処理結果を受け付けて、所定の連携処理（ここでは、端末８０の発信者と、変換後の番号の端末８１の着信者とが互いにブロックされていないかのチェック処理）を実施し、処理結果のＳＩＰ信号を通信プロトコルスタック３２５に返送する。

Ｓ４５で、通信プロトコルスタック３２５は、ＳＩＰ信号受信処理を行った後、ＳＩＰ信号変換処理をＳＩＰインタワーク部３２２へ依頼する。

Ｓ４６で、ＳＩＰインタワーク部３２２は、ルール記憶部３２６のＡＰＬ−ＧＷ−ＦＥ１０用のＳＩＰインタワークルールを参照してＳＩＰ信号変換を行い、ＡＰＬ−ＧＷ−ＦＥ１０のＳＩＰと標準ＳＩＰとの差分（方言）を除去し、ＳＩＰ信号（処理結果）を複数ＡＰＬ連携部３２１に送出する。

Ｓ４７で、複数ＡＰＬ連携部３２１は、連携処理の処理結果の妥当性を判定する。妥当性の判断としては、例えば、処理結果がＯＫの場合（ここでは、発信者と着信者が互いにブロックされていない場合）、妥当であると判断する。また処理結果のデータフォーマットが、対応する連携ルール（APL-a２１→APL-b２２の連携ルール）に合っているかなどをチェックすることが考えられる。複数ＡＰＬ連携部３２１は、妥当でない場合は処理を終了し、妥当な場合はルール記憶部３２６の対応する連携ルールを参照して、使用する部品を特定し、特定した部品の識別情報等を指定した発信依頼を通信部３２２に送出する。具体的には、複数ＡＰＬ連携部３２１は、対応する連携ルールに基づき、部品の生成に関する情報（例えば、部品の種類（発呼、接続、切断、ガイダンス再生等）、連携サービスを提供するＡＰＬ（APL-a２１、APL-b２２）のアドレス情報等の制御情報を作成して、基本呼処理部３１の連携ＡＰＬ部３１１を介して、部品機能部３１２に送出する。

Ｓ４８で、通信部３２３は、基本呼処理部３１の通信部３１０へ発信依頼を転送する。

Ｓ４９で、基本呼処理部３１の通信部３１０は、連携ＡＰＬ部３１１に対して発信依頼を転送する。

Ｓ５０で、連携ＡＰＬ部３１１は、処理要求で指定された部品等（ここでは、呼処理部品の接続、ＵＡ機能部の発ＵＡ）を用いてＳ３８で変換された番号の相手端末８１にＳＩＰ信号を送信する。

なお、図７および図８で説明した処理では、２つのＡＰＬ（APL-a２１、APL-b２２）の連携を例として説明したが、ＡＰＬの連携は２つに限定されるものではなく、３つ以上のＡＰＬの連携であってもよい。

以上説明したように、本実施形態のＡＰＬ−ＳＣＭ−ＦＥ３０では、基本呼処理部３１とサービス向け呼処理部３２とを分離した構成とし、基本呼処理部３１の部品（呼処理部品）をサービス向け呼処理部３２からリモートで制御できるようにした。これにより、連携するＡＰＬ／サービスの追加変更によってＳＩＰインタワーク処理が変更になる場合のソフトウェアの修正箇所をサービス向け呼処理部３２に局所化することができ、基本呼処理部３１への改造が不要となる。

また、連携するＡＰＬ／サービスの信頼性、可用性、性能等の要件に応じて、ＡＰＬ−ＳＣＭ−ＦＥのサーバ構成を柔軟に変更することが可能となる。例えば、低遅延が要求される場合は基本呼処理部３１とサービス向け呼処理部３２を同一のサーバに搭載する構成を選択し、また、サービス向け呼処理部３２の処理量が基本呼処理部３１よりも大幅に多い場合は基本呼処理部３１とサービス向け呼処理部３２を別サーバに搭載する構成を選択し、さらに、サービス向け呼処理部３２に高性能のハードウェアを使用したり複数台で構成したりすることなどが可能である。また、ＡＳ−ＦＥ２０、ＡＰＬ−ＧＷ−ＦＥ１０およびＡＰＬ−ＳＣＭ−ＦＥ３０に要求される性能の総和がサーバ一台で賄える場合、ＡＳ−ＦＥ２０、ＡＰＬ−ＧＷ−ＦＥ１０およびＡＰＬ−ＳＣＭ−ＦＥ３０の基本呼処理機能を同一のマシンに集約して搭載することで、設備効率を高めることなども可能となる。

また、本実施形態では、サービス向け呼処理部３２はＩＦ更新部３２４を備え、ルール記憶部３２６の連携ルールおよびＳＩＰインタワークルールを更新する。これにより、連携サービスに対応して連携ルールおよびＳＩＰインタワークルールの追加、変更、削除等を行うことができ、その際にサービス向け呼処理部３２のルール記憶部３２６のみを修正すればよい。したがって、ソフトウェアの修正箇所を局所化することができる。

なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

２ ＡＰＬサーバ
１０ ＡＰＬ−ＧＷ−ＦＥ
２０ ＡＳ−ＦＥ
３０ ＡＰＬ−ＳＣＭ−ＦＥ
３１ 基本呼処理部
３１０ 通信部
３１１ 連携ＡＰＬ部
３１２ 部品機能部（呼制御部）
３１３ 部品管理制御部
３１４ 呼処理部品
３１５ ＵＡ機能部（呼制御部）
３１６ 通信プロトコルスタック（呼制御部）
３２ サービス向け呼処理部
３２１ 複数ＡＰＬ連携部
３２２ ＳＩＰインタワーク部
３２３ 通信部
３２４ ＩＦ更新部
３２５ 通信プロトコルスタック
４０ ＳＳ−ＦＥ
５０ Ｓ−ＣＳＣ−ＦＥ
６０ ＭＲＣ−ＦＥ
７０ Ｐ−ＣＳＣ−ＦＥ
８０、８１ 端末
１００ ＡＳＦ＆ＳＳＦ

Claims (6)

1. 複数のアプリケーションを連携させた連携サービスを端末に提供するＡＰＬ−ＳＣＭ−ＦＥ（Application Service Coordination Manager Functional Entity）であって、
   前記ＡＰＬ−ＳＣＭ−ＦＥは、サービス向け呼処理部と、基本呼処理部とを分離して備え、
   前記サービス向け呼処理部は、
   前記連携サービスの連携要求を取得し、当該連携サービスで用いる呼処理の制御情報を、前記基本呼処理部に送出する複数ＡＰＬ連携部と、
   前記複数のアプリケーションでそれぞれ用いられるＳＩＰ信号と、標準のＳＩＰ信号との差分を変換するＳＩＰインタワーク部と、を備え、
   前記基本呼処理部は、
   端末に前記連携サービスを提供するための呼処理を、前記制御情報を用いて実行する呼制御部を備えること
   を特徴とするＡＰＬ−ＳＣＭ−ＦＥ。
2. 請求項１に記載のＡＰＬ−ＳＣＭ−ＦＥであって、
   前記複数ＡＰＬ連携部は、前記連携サービスの連携要求をアプリケーションから取得すること
   を特徴とするＡＰＬ−ＳＣＭ−ＦＥ。
3. 請求項１または請求項２に記載のＡＰＬ−ＳＣＭ−ＦＥであって、
   前記基本呼処理部は、端末から受信した連携要求を、前記複数ＡＰＬ連携部に送出する連携ＡＰＬ部を、さらに備えること
   を特徴とするＡＰＬ−ＳＣＭ−ＦＥ。
4. 請求項１から請求項３のいずれか１項に記載のＡＰＬ−ＳＣＭ−ＦＥであって、
   前記サービス向け呼処理部は、
   前記連携サービスを提供するための連携ルールおよび各アプリケーションで用いられるＳＩＰインタワークルールを記憶するルール記憶部と、
   各連携サービスに対応させて前記ルール記憶部の連携ルールまたはＳＩＰインタワークルールを更新するＩＦ更新部と、をさらに備えること
   を特徴とするＡＰＬ−ＳＣＭ−ＦＥ。
5. ＡＰＬ−ＳＣＭ−ＦＥ（Application Service Coordination Manager Functional Entity）が、複数のアプリケーションを連携させた連携サービスを端末に提供するアプリケーション連携方法であって、
   前記ＡＰＬ−ＳＣＭ−ＦＥは、サービス向け呼処理部と、基本呼処理部とを分離して備え、
   前記サービス向け呼処理部は、
   要求元のアプリケーションから、少なくとも１つの他のアプリケーションへの連携要求のＳＩＰ信号を取得する取得ステップと、
   前記連携要求のＳＩＰ信号を、前記他のアプリケーション用のＳＩＰ信号に変換するＳＩＰインタワークステップと、
   前記他のアプリケーション用のＳＩＰ信号を前記他のアプリケーションに送信し、処理結果を取得する取得ステップと、
   前記処理結果が妥当な場合、前記要求元のアプリケーションと前記他のアプリケーションとの連携サービスに対応する制御情報を前記基本呼処理部に送出する送出ステップと、を行い、
   前記基本呼処理部は、
   端末に前記連携サービスを提供するための呼処理を、前記制御情報を用いて実行する呼制御ステップを行うこと
   を特徴とするアプリケーション連携方法。
6. ＡＰＬ−ＳＣＭ−ＦＥ（Application Service Coordination Manager Functional Entity）が、複数のアプリケーションを連携させた連携サービスを端末に提供するアプリケーション連携方法であって、
   前記ＡＰＬ−ＳＣＭ−ＦＥは、サービス向け呼処理部と、基本呼処理部とを分離して備え、
   前記サービス向け呼処理部は、
   前記端末が送信した連携要求のＳＩＰ信号を、前記基本呼処理部から取得する取得ステップと、
   前記連携要求のＳＩＰ信号を、第１のアプリケーション用のＳＩＰ信号に変換し、前記変換後のＳＩＰ信号を第１のアプリケーションに送信して、第１の処理結果のＳＩＰ信号を取得する取得ステップと、
   第１の処理結果のＳＩＰ信号を、少なくとも１つの第２のアプリケーション用のＳＩＰ信号に変換し、前記変換後のＳＩＰ信号を第２のアプリケーションに送信して、第２の処理結果を取得する取得ステップと、
   前記第２の処理結果が妥当な場合、第１のアプリケーションと第２のアプリケーションとの連携サービスに対応する制御情報を前記基本呼処理部に送出する送出ステップと、を行い、
   前記基本呼処理部は、
   前記端末に連携サービスを提供するための呼処理を、前記制御情報を用いて実行する呼制御ステップを行うこと
   を特徴とするアプリケーション連携方法。

Images