JP2014090446A - 通信網 - Google Patents

Abstract

【課題】登録サーバと、網の中での資源に対するプログラマブルインターフェースを実現する他の部品を提供する。
【解決手段】アプリケーションプログラミングインターフェース（ＡＰＩ）を実現する通信網における登録サーバは、サービスを認証して、選ばれた網資源にサービスを登録する前に、網資源のディスカバリィを提供する。単一のサービス合意において、サービスの複数のインスタンス及び／又は複数のサービスノードが登録される。
【選択図】図１

Description

この発明は通信網に係り、とくに登録（レジストレーション）サーバと、このような網の中での資源に対するプログラマブルインターフェースを実現するその他の部品とに関する。

従来は、遠隔通信網における高度に進んだ通信サービスは、インテリジェント網（ＩＮ：intelligent network）構造を用いて実施されてきた。このような構造では、最新の進んだサービスを実施するのに必要とされた制御論理と各種の網資源とは密接に通信網と統合されていて、一般には網オペレータの制御の下で実行が進むように意図されている。このようなやり方は堅牢な大規模のアプリケーションが実施できるようにしている。しかしながら、この構造は比較的に融通性がないので、新しいサービスを開発し展開することは時間のかかるものとなっている。さらに、網オペレータ以外にサービスプロバイダにとって網資源を利用可能とし、しかもセキュリティ（安全）と網の完全性（インテグリティ）とを維持することは困難となっている。

最近、開発に関心がもたれている通信アプリケーションは、網の縁（エッジ）に置かれた計算機処理用プラットホームを用いるアプリケーションであり、サービスプロバイダの直接制御の下で一般に動作するプラットホームを用いることである。しかしながら、このような計算機と電話との統合（ＣＴＩ）アプリケーションは間接的なしかも制限されたアクセスだけを網のもつ能力に対して有しているのであるから、このやり方はときとして網資源の不十分な使用を結果している。

通信網としてアプリケーションプログラミングインターフェース（ＡＰＩ）を、網内に組入れられたサービス部品間と網の縁で実行されているアプリケーション間とに含ませた通信網を実施することが提案されている。このようなやり方は規模についての経済性という利益と、通常の網インテリジェンス構造によって提供される信頼性について利益とを、網の縁のフレキシビリティ（融通性）とアクセシビリティ（アクセス可能性）と組合せるやり方となっている。

上述のＡＰＩを含んでいる網は本願出願人とParlay Organisationの他のメンバと共同で開発された。Parlay OrganisationはＡＰＩについての仕様書を実施を支援する資源と一緒に、刊行している。Parlay APIの全体像は“Parlay API Business Benefits White Paper”，Parlay Organisation，11 June 1999，www.parlay.org.刊，Version１．２及び２，Parlay API仕様書という文書の中に含まれていて、ここにあげたサイトで入手可能である。

サービスＡＰＩを備えた通信網を実施する際に、登録サーバが使用されて網の縁（edge-of-network）サービスアプリケーションにより、サービス資源を用意する網内の部品へのアクセスを制御する。登録サーバは認証（オーセンティケーション）プロセスを実行するために使用することができて、このプロセスではサービスアプリケーションの識別子とアクセス網資源へのそのアプリケーションの所有者についての権原とがチェックされ、この際には、例えばディジタルシグネチャ（署名）と、網の権原のある（承認された）使用者をリストしているデータベースとが使用される。登録サーバはまたディスカバリィのプロセスについても使用でき、ここではサービスアプリケーションからの要求に応答して、登録サーバが利用可能な網資源の詳細を用意する。その後に、登録サーバはサービスアプリケーションをいくつかのサービス資源とともに登録する。これは、サービスアプリケーションに向けて論理識別子とサービスマネージャオブジェクトの物理アドレスを特定のサービスノード上で通信すること、及び／又は対応しているサービスアプリケーションを識別するデータをサービスマネージャオブジェクトに向けて通信することによって行なわれる。

本発明の第一の態様によると、通信網を動作する方法であって、前記通信網は、少くとも一つのサービスノードと、前記少くとも一つのサービスノードへのサービスアプリケーションによるアクセスを制御するように構成された登録サーバと、一つ以上の通信サービスを実行している、前記登録プラットホームから離れているプラットホームと、を含み、
前記方法は、
ａ）前記通信網に接続された前記又は各サービスノード上で利用可能なサービス資源を識別するデータを配信する段階と、
ｂ）前記段階ａ）で識別された前記サービス資源の少くとも一部に対する、前記プラットホームによるアクセスの要求を、登録サーバに通信する段階と、
ｃ）前記登録サーバにおいて、前記段階ｂ）の前記要求に応答して、前記要求されたサービス資源を提供している少くとも一つのサービスノードへの前記サービスアプリケーションによるアクセスを許すサービス合意を実行する段階と、
ｄ）その後で、前記サービスアプリケーションを前記少くとも一つのサービスノードにバインドさせる段階と、
を含み、
前記段階ｃ）において、
前記サービス合意が、前記サービスアプリケーションの複数のインスタンス、及び／又は複数のサービスノードを特定し、
前記段階ｄ）において、
（ｉ）前記サービスアプリケーションの複数のインスタンスを前記少くとも一つのサービスノードにバインドさせる段階と、
（ｉｉ）前記サービスアプリケーションの少くとも一つのインスタンスを複数のサービスノードにバインドさせる段階と、
のうちの少くとも一方を含むことを特徴とする、方法を提供する。

この出願の記述とクレームとでは、用語“サービスノード”は広義に使用されていて、通信サービスを実行するための資源を用意している網のノードを言うものとしている。それには、いずれの意味でも限定をかける積りはなく、計算機処理用プラットホームであって網の縁に置かれ、かつメッセージング（メッセージ送付）のような特殊サービスに使用されるものを含んでいる。以下に記述する例では、サービスノードはＩＮ（インテリジェント網）構造を用いる網内のサービス制御ポイントである。

この発明は通信網内でＡＰＩを実現する方法を用意していて、これによると高度な回復力（レジレンス）を求められているアプリケーションを支持することがよくできる。これが達成されるのはＡＰＩの実施を修復することによるもので、それによって登録プロセスがもはや一対一のバインデングをサービスアプリケーションとサービスノードとの間で作ることに対して制限を加えない。がこれに代って、サービスアプリケーションのいくつかのインスタンスがノードで登録されるようにするか、あるいはいくつかの異なるノードが一つのサービスアプリケーションに登録されるか、またはその両方ができるようにしている。

この発明を実施する網を示す図。 図１の網で使用するためのサービスプラットホームをさらに詳細に示す図。 図１の網におけるＡＰＩの使用を模式的に示す図。 この発明を実施する網の異なる部品間のインターフェースを示す図。 始動と登録とをゲートウェイについて示すメッセージシーケンスチャート。 サービス始動についてのメッセージシーケンスチャート。 ゲートウェイの故障と回復（復帰）を示すメッセージシーケンスチャート。 クライアントアプリケーションの故障と回復（復帰）を示すメッセージシーケンスチャート。

この発明を実施するシステムについて添付の図面を参照して詳細に記述して行く。

通信網はアクセス網１とコア網２とを備えている。顧客端末３ａ，３ｂがアクセス網１に接続されている。サービスプロバイダプラットホーム４ａ，４ｂもまたアクセス網１に接続されている。登録サーバ５は網に接続され、以下に記述するようにＡＰＩ（アプリケーション プログラマーズ インターフェース）を網資源に対して実現するのに使用される。これらの網資源は多数のサービスノード６ａ，６ｂ，６ｃを含み、その各々はそれぞれのゲートウェイＧＷ１，ＧＷ２，ＧＷ３を含んでいる。サービスノードはハードウェアとソフトウェアとを含んでいて、それが例えば番号（ナンバ）変換アプリケーション、対話形音声認識及びメッセージングサービスを実行する。上述のように、用語“サービスノード”はここでは広義に使用されていて、サービスアプリケーションを実行するのに使用されるノードを指していて、網の縁の位置にあるノードに限定されていない。

図２はサービス資源ノードの一つの構造をさらに詳細に示している。この例では、サービスノードは網インテリジェンスプラットホーム（ＮＩＰ）として知られているプラットホームである。そこには多数の通信サーバ（ＣＳ）を含んでいて、ＣＳは網シグナリングを終端し、この例ではシグナリングシステムナンバ７（ＳＳ７）共通チャンネルシグナリングとなっている。グローバルデータサーバ（ＧＤＳ）はシグナリングレートを監視して、呼の統計を集めている。トランザクションサーバ（ＴＳ）は基本的なサービス制御機能
であってサービスノードにより求められているものを実施する。オーバーロード制御サーバ（ＯＣＳ）は過負荷制御保護をサービスノードについてと、サービスノードから下流の部品についてとの両方に対して実施する。例えば、ＯＳＣは過負荷状態が検出されるときにはコールギャッピング（呼の間隔をとる）を始動させる。オーバーロード制御サーバとトランザクションサーバとは共通高速バスに接続されている。ゲートウェイ（ＧＷ）はサービスマネージャオブジェクトの多数のインスタンスを支持していて、このオブジェクトは特定のサービスアプリケーションに対して、サービスノード内部の異なる部品の資源を割当てる。サービスノードを作り上げている異なるサーバはそれぞれが各ＵＮＩＸ（登録商標）ワークステーション上で実施される。異なるサーバは高速光ファイバ（ＦＤＤＩ）ローカルエリア網（ＬＡＮＳ）２１，２２を介して通信する。

図３に模式的に示したように、通信網は、アプリケーションプログラマーズインターフェース（ＡＰＩ）を、網の縁でいわゆる“エンタープライズ（事業）ドメイン”で実行しているアプリケーションと網オペレータドメインでサービスを実施するのに使用される網部品との間で実現する。この例では、インターフェースはParlay API仕様書に規定されている。

図４はParlay（パーレイ）インターフェースを実施している網の部品間のインターフェースをもっと詳細に示している。このインターフェースはオブジェクト指向のもので、インターフェースの二つのカテゴリィを用いて実施される。第一はサービスインターフェースであり、第二はフレームワークインターフェースである。アプリケーションのサービスインターフェースは網のもつ能力機能にアクセスする。フレームワークインターフェースはサービスインターフェースについて環境を用意する。フレームワークインターフェースは認証、ディスカバリィ及び登録というプロセスを実現する。フレームワークオブジェクトで網ドメインにあるものは、クライアントＦＷ（フレームワーク）オブジェクトでユーザドメインにあるものと通信をする。加えて、クライアントアプリケーションとParlayサービスとの間に直接インターフェース４．２が存在する。しかし、こういった直接インターフェース４．２は通常はあるアプリケーションがフレームワークインターフェース４．１を介してサイン・オン（計算機へのアクセス、すなわちログオンと同義）した後に限ってアクセスされる。

この例では、フレームワークＦＷを実現するオブジェクトが登録サーバ５の上に置かれている。クライアントアプリケーションとクライアントＦＷとはサービスプロバイダプラットホーム４ａ，４ｂ上で実行する。Parlayサービスでゲートウェイを含むものがサービスノード６ａ，６ｂ，６ｃで実施される。

クライアントアプリケーションの一つが初期化されるときには、まず登録サーバを経由してParlay APIにサイン・オンされる。Parlay認証オブジェクトは登録サーバ上でインスタンス化されて、認証インターフェースを用意し、これが登録サーバとクライアントアプリケーションとの相互認証を可能とする。認証プロセスでは、アプリケーションは識別用コードを登録サーバに戻す。登録サーバは認識されたアプリケーションについてのデータベースを含んでいる。登録サーバはアプリケーションＩＤ上でルックアップ（一覧）を実行しまたアプリケーションに特有の暗号キーを検索することもできる。

ディスカバリィ相（フェーズ）では、アプリケーションは登録サーバから、プロパティ名とプロパティ値とによって識別されたサービス特徴のディスカバリィを要求する。Parlay API仕様書はプロパティ名の組を定義する。Parlayサービスは適当な名前を用いて登録サーバに登録する。ディスカバリィ要求に応答して、登録サーバはサービスＩＤを戻すが、このＩＤは要求された網サービスを識別する。後に、アプリケーションはサービスを選ぶ。これをするためにアプリケーションはサーバに対して、ディスカバリィ問合せに応答して受取ったサービスＩＤを戻す。登録サーバはそこでサービストークンを戻すが、このトークンはサービスのインスタンスをユニークに識別する。その結果、アプリケーションがサービスを使用できる前に、アプリケーションは登録サーバとの合意をディジタル的にサインする。ディジタルシグネチャ（署名）はアプリケーションＩＤとサービストークンとを含んでいるデータとともに記憶される。ディジタル合意（アグリーメント）は、例えば、後に網オペレータによる課金を網サービスの使用について行うときの基礎として使用される。合意がサインされてしまうと、登録サーバはアプリケーションに対して要求された網サービスマネージャインターフェースを実施するオブジェクトについての参照基準（レファレンス）を戻す。

Parlayインターフェースの上述した実施はさらにParlay API仕様書１．２に詳述されている。しかし、この発明の実施には各インターフェースに対して若干の修正が求められている。従来実施されているように、各単一のサービス合意でParlayインターフェースを用いて作られるものは、単一のゲートウェイを単一のクライアントアプリケーションにリンクするようにしている。この発明を実施する現在の網では、インターフェースは修正されて、複数のゲートウェイを複数のクライアントアプリケーションに、単一のサービス合意の下で、リンクするようにしている。このやり方でParlayサポートのエンドユーザサービスにとってゲートウェイかクライアントアプリケーションかの故障に対して弾力的で回復力のあるものとすることが可能である。各サービスマネージャでゲートウェイ内に置かれているものは初期事象の通知を送ることが可能とされていて、例えば、到来呼の通知を、配信アルゴリズムを用いて利用可能なクライアントアプリケーションに向けて送ることができて、このアルゴリズムは例えばラウンドロビンアルゴリズムである。同じように、クライアント側では、クライアントアプリケーションサポートレイヤは初期セッション要求をインボーク（呼出す）ことができる。例えば、呼を発する要求は配信アルゴリズムを用いて多数の利用可能なゲートウェイの一つに向けてすることができる。こういった特徴に加えて、フレームワークＦＷは今ではポーリング機構を含んでいて、登録したサービスをサポートするゲートウェイの現在の状態を検出するのにあてる。故障したゲートウェイの検出は警報をトリガするために使用できる。クライアントアプリケーションに仕えているゲートウェイの各々についての利用可能性はクライアントフレームワークに向けて送られる。機能停止の後で回復されたゲートウェイが検出されるときには、フレームワークは新しいサービスマネージャのインスタンシエーションを求め、新しいサービスマネージャについてのレファレンス（参照基準）をクライアントＦＷに向けて送る。クライアントＦＷはポーリング機構を実現し、これがクライアントアプリケーションの現在の状態を検出する。故障したクライアントアプリケーションの検出は警報をトリガするのに使用されてよい。クライアントアプリケーションの各々についての利用可能性はフレームワークＦＷに向けて報告される。回復されたクライアントアプリケーションが機能停止の後で検出されるときには、クライアントＦＷは新しいクライアントアプリケーションに向けてサービスマネージャに対するレファレンスの全リストを通信する。

Parlay APIについての修正は図４に示した特殊インターフェースの各々との関係でここで記述することとする。これらのインターフェースの一つは、クライアントフレームワークとクライアントアプリケーションとの間でParlay API仕様書の一部を形成していないが、ここでは全体としてシステムの記述に対する支援として定義されている。

ＦＷ−サービスインターフェース
Parlayサービス登録
１．ParlayサービスはＦＷで登録される。Parlayサービスが複数のゲートウェイをまたいで支持されることができるためには、Parlayサービスの登録は、そのサービスを支持している個々のゲートウェイの登録からは異なっている。図５のメッセージシーケンスチャートに示すように、サービスノードは先ずＦＷでの登録を要求し、後にサービスを支持しているゲートウェイ全部の登録をインボークする（実施する）。別個の実施呼び出し（インボケーション）が各ゲートウェイに送られる。

開始（スタートアップ）
１．図６に示すように、ＦＷは、Parlayサービスを支持しているすべてのゲートウェイ内でParlayサービスゲートウェイマネージャを作ることを要求する。新しいサービスゲートウェイマネージャについてのレファレンスはゲートウェイによって戻される。

２．一度、バインドが完了すると、ＦＷはグローバル事象通知情報をサービスゲートウェイマネージャに向けて送る。例えば、情報はアプリケーションが所有している番号範囲を含んでいてもよい。この情報はデータベース内に記憶される。

ゲートウェイの故障と回復
１．図７に示すように、ＦＷはゲートウェイの故障を検出して、適当な警報を生じさせる。

２．ＦＷはゲートウェイの回復を検出して、サインされた各サービス合意について新しいParlayサービスゲートウェイマネージャのインスタンシエーションを求める。これはサービスの開始からの振舞いを再使用する。

クライアントアプリケーションの故障
１．図８に示すように、クライアントアプリケーションの故障についての通知があると、ＦＷはこれを各ゲートウェイに報告する。

２．各ゲートウェイは、有効なクライアントアプリケーションについてのゲートウェイのリストから古く、失効した、レファレンスを除去する。

ＦＷ−クライアントＦＷインターフェース
開始（図６）
１．クライアントＦＷは認証ハンドシェークをＦＷと実行する。

２．クライアントＦＷはディスカバリィインターフェースを用いて、エンドユーザサービスを実行するのに必要な、Parlayサービスを見付ける。

３．クライアントＦＷはParlayサービスを選び、回復目的で必要とされているゲートウェイの数（ｎ）を特定する。またParlayサービスゲートウェイにバインドすることになるクライアントアプリケーションの最大数（ｍ）を特定する。これはサービスレベル合意の一部として特定される。

４．クライアントＦＷがサービス合意にサインをするときには、ＦＷはサービスゲートウェイマネージャのリストに対するレファレンスをクライアントＦＷに向けて戻す。

５．クライアントＦＷはＦＷを介してグローバル事象通知情報を送る。例えば、これはアプリケーション“自体の”番号範囲であり、この情報はデータベース内に記憶される。

ゲートウェイの故障と回復（図７）
１．ゲートウェイの故障を検出すると、ＦＷはこれをクライアントＦＷに報告する。

２．ゲートウェイの回復を検出し、新しいサービスゲートウェイマネージャのインスタンシエーションを要求すると、ＦＷはクライアントＦＷに対して報告を送り、サービスゲートウェイマネージャのレファレンスをパラメータとして送る。

クライアントアプリケーションの故障と回復（図８）
１．クライアントアプリケーションの故障を検出すると、クライアントＦＷはこれをＦＷに報告する。

クライアントアプリケーション−サービスインターフェース
バインド（図６と７）
開始後、あるいはクライアントアプリケーションの回復後に、サービスゲートウェイマネージャのレファレンスをクライアントアプリケーションに向けて送ること
１．クライアントアプリケーションはサービスゲートウェイマネージャの各々に対して順々にバインドする。各サービスゲートウェイマネージャはｍのクライアントアプリケーションを越えてそこへのバインドを許さない。

２．サービスゲートウェイマネージャは適当な配信アルゴリズムを用いて事象をクライアントアプリケーションに分散させる。

ゲートウェイの故障と回復（図７）
１．ゲートウェイの故障は次によりクライアントアプリケーションに向けて通知される。

ａ）クライアントＦＷが故障を報告するか、
ｂ）クライアントアプリケーションが故障を直接検出するか（実施の際か、プロトコル固有の故障のとき）、既存のアプリケーションセッションを時間切れ（タイムアウト）とするか（例えばアプリケーション呼出しセッションのとき）による。

２．ＡＰＩインボケーション（実施のための呼出し）であって既存のサービスセッションに関するものは他のゲートウェイには転送されない。

３．新しいサービスセッションについてのＡＰＩインボケーションが代りのゲートウェイに向けて転送される。これは適当な配信アルゴリズムを用いて行なわれて、残っているゲートウェイの間でインボケーションが分散される。

４．ゲートウェイ回復では、クライアントＦＷは新しいサービスマネージャに対するレファレンスをクライアントアプリケーションに送り、このアプリケーションが新しいサービスマネージャにバインドする。

クライアントアプリケーションの故障と回復（図８を見よ）
１．クライアントアプリケーションの故障は次によりゲートウェイに通知される。

ａ）ＦＷが故障を報告する
ｂ）ゲートウェイが故障を直接に検出する（実施の場合か、プロトコル固有の故障のとき）か、既存のサービスセッション（例えば、呼出しセッション）をタイムアウトとする。

２．既存のアプリケーションセッションについてのＡＰＩインボケーションは他のクライアントアプリケーションに向けて転送されない。

３．新しいアプリケーションセッションについてのインボケーション（初期事象通知）が代りのクライアントアプリケーションに向けて転送される。これは適当な配信アルゴリズムを用いて行なわれて、残っているクライアントアプリケーション間でインボケーションが分散される。

４．回復されたクライアントアプリケーションは、サービスゲートウェイマネージャの各々とバインドする。

クライアントＦＷ−クライアントアプリケーションインターフェース
開始（図６）
１．クライアントＦＷはサービスゲートウェイマネージャレファレンスのリストをクライアントアプリケーションのすべてに向けて送る。

ゲートウェイの故障と回復（図７）
１．ゲートウェイの故障についてＦＷから報告を受取ると、クライアントＦＷはこの情報をクライアントアプリケーションに向けて送る。

２．各クライアントアプリケーションは有効なゲートウェイのリストから古い、失効した基準（レファレンス）を除去する。

３．ゲートウェイの回復があると、クライアントＦＷは新しいサービスゲートウェイマネージャのレファレンスをクライアントアプリケーションのすべてに向けて送ってバインドさせる。

クライアントアプリケーションの故障と回復（図８）
１．クライアントＦＷは故障を検出し、適当な警報を生じさせて、故障をＦＷに向けて報告する。

２．クライアントＦＷはクライアントアプリケーションの回復を検出する。

３．クライアントＦＷはサービスゲートウェイマネージャレファレンスのリストを回復したクライアントアプリケーションに向けて送って、バインドさせる。

Claims (7)

1. 通信網を動作する方法であって、
   前記通信網は
   少くとも一つのサービスノードと、
   前記少くとも一つのサービスノードへのサービスアプリケーションによるアクセスを制御するように構成された登録サーバと、
   一つ以上の通信サービスを実行している、前記登録プラットホームから離れているプラットホームと、
   を含み、
   前記方法は、
   ａ）前記通信網に接続された前記又は各サービスノード上で利用可能なサービス資源を識別するデータを配信する段階と、
   ｂ）前記段階ａ）で識別された前記サービス資源の少くとも一部に対する、前記プラットホームによるアクセスの要求を、登録サーバに通信する段階と、
   ｃ）前記登録サーバにおいて、前記段階ｂ）の前記要求に応答して、前記要求されたサービス資源を提供している少くとも一つのサービスノードへの前記サービスアプリケーションによるアクセスを許すサービス合意を実行する段階と、
   ｄ）その後で、前記サービスアプリケーションを前記少くとも一つのサービスノードにバインドさせる段階と、
   を含み、
   前記段階ｃ）において、
   前記サービス合意が、前記サービスアプリケーションの複数のインスタンス、及び／又は複数のサービスノードを特定し、
   前記段階ｄ）において、
   （ｉ）前記サービスアプリケーションの複数のインスタンスを前記少くとも一つのサービスノードにバインドさせる段階と、
   （ｉｉ）前記サービスアプリケーションの少くとも一つのインスタンスを複数のサービスノードにバインドさせる段階と、
   のうちの少くとも一方を含むことを特徴とする、方法。
2. 前記段階ｄ）は、サービスアプリケーションの複数のインスタンスを前記少くとも一つのサービスノードにバインドさせる段階を含み、
   前記方法は、一連の初期事象の通知を前記サービスアプリケーションの前記複数のインスタンスに配信する段階を含む、請求項１に記載の方法。
3. 複数のサービスノードをサービスアプリケーションの前記少くとも一つのインスタンスに登録する段階を含み、
   前記方法は、一連の初期セッション要求を前記複数のサービスノードに配信する段階を含む、請求項１又は２に記載の方法。
4. 前記登録サーバによって、
   前記登録サーバに登録された複数のサービスノードを繰返しポーリングして、
   前記サービスノードの利用可能性における何らかの変化を示しているデータを前記又は各サービスアプリケーションに通信する段階を、更に含む、請求項１乃至３の何れか１項に記載の方法。
5. 前記登録サーバに登録された複数のサービスアプリケーションのインスタンスの各々を繰返しポーリングする段階と、
   前記サービスアプリケーションのインスタンスの利用可能性における何らかの変化を示しているデータを、前記又は各サービスノードに通信する段階と、
   を更に含む、請求項１乃至４の何れか１項に記載の方法。
6. 請求項１乃至５の何れか１項に記載の方法に従って動作するように構成されている、通信網。
7. 請求項６に記載の通信網で使用するように構成された、登録サーバ。

Images