JP2011508490A - 通信ネットワークにおいて使用する方法および装置 - Google Patents

Abstract

ＩＰマルチメディアサブシステム（ＩＭＳ）のホーム加入者サービス（ＨＳＳ）に対する冗長性を可能にする方法を提供する。冗長性を複数のＨＳＳインスタンス（４０）により提供する。ＩＭＳのクライアントノード（１０）がＨＳＳの詳細を要求し、ＨＳＳインスタンス（４０）を代理するプロキシＨＳＳ（２０）の詳細をクライアントノード（１０）に提供する（Ｓ１、Ｓ２）。クライアントノード（１０）は詳細を使用して、プロキシＨＳＳ（２０）に向ける後続要求を送信する（Ｓ３）。プロキシＨＳＳ（２０）はＨＳＳインスタンス（４０）の適切な１つを選択し（Ｓ５）、プロキシＨＳＳ（２０）においてクライアントノード（１０）から受信する（Ｓ４）要求を処理する。プロキシＨＳＳ（２０）は要求を選択するＨＳＳインスタンスンス（４０）に転送し、処理する。

Description

本発明は通信ネットワーク、例えばＩＰマルチメディアサブシステムを有する汎用移動通信システムにおいて使用する方法および装置に関する。

ＩＰマルチメディアサービスは同一セッション内において音声、ビデオ、メッセージング、データ、などの動的結合を提供する。結合することが可能な基本的アプリケーションおよびメディアの数が増えることにより、エンドユーザに提供するサービスの数が増えるであろうし、人と人との間の通信経験が豊かになるであろう。これが導くであろう先は、所謂「結合ＩＰマルチメディア」サービスを含む個人的で、豊かなマルチメディア通信サービスの新しい時代である。

ＵＭＴＳ（汎用移動通信システム、Universal Mobile Telecommunications System）は加入者により速いデータ速度および先進サービスを提供するために考えられた第３世代無線システムである。ＵＭＴＳは移動通信のためのグローバルシステム（ＧＳＭ、Global System for Mobile Communications）の後継であり、ＧＳＭと汎用パケット無線サービス（ＧＰＲＳ、General Packet Radio Service）であるＵＭＴＳ間の重要な発展段階を伴う。ＧＰＲＳはＧＳＭコアネットワークにパケット交換を導入し、パケットデータネットワーク（ＰＤＮ（複数）、packet data networks）への直接アクセスを許容する。これが可能にするのは、ＩＳＤＮの６４ｋｂｐｓの制約を十分に超えるＧＳＭ呼ネットワークによる２ＭｂｐｓまでのＵＭＴＳデータ伝送速度に必須の高データ速度パケット交換伝送である。ＵＭＴＳは第３世代パートナシッププロジェクト（３ＧＰＰ、3rd Generation Partnership Project）により標準化し、第３世代パートナシッププロジェクトは欧州通信標準化協会（ＥＴＳＩ、European Telecommunication Standards Institute）、無線産業事業連盟（ＡＲＩＢ、Association of Radio Industry Business）およびその他のような地域標準化団体の集まりである。より詳細には非特許文献１を参照。

ＵＭＴＳ構成が含むのは従来電話をサポートするＩＰマルチメディアサブシステム（ＩＭＳ、IP Multimedia Subsystem）として既知のサブシステム、並びに新しいＩＰマルチメディアサービス（非特許文献２〜８）である。ＩＭＳが提供するのは標準化ＩＭＳサービスイネーブラの使用によりエンドユーザの人対人の通信経験を豊かにする重要な特徴であり、標準化ＩＭＳサービスイネーブラは新しく豊かな人対人（クライアント対クライアント）の通信サービス、並びにＩＰベースネットワークを経る人対コンテンツ（クライアント対サーバ）サービスを容易にする。ＩＭＳはＰＳＴＮ／ＩＳＤＮ（公衆交換電話ネットワーク／サービス総合ディジタルネットワーク、Public Switched Telephone Network/Integrated Services Digital Network）双方並びにインターネットに接続することができる。

ユーザ端末（またはユーザ端末とアプリケーションサーバ）間の呼またはセッションの設定および制御に、ＩＭＳはセッション開始プロトコル（ＳＩＰ、Session Initiation Protocol）を使用する。ＳＩＰ信号により伝達するセッション記述プロトコル（ＳＤＰ、Session Description Protocol）を使用してセッションのメディア構成要素を記述し、折衝する。ＳＩＰはユーザ対ユーザプロトコルとして作成されたが、ＩＭＳは運用会社およびサービスプロバイダにサービスへのユーザアクセスを制御し、従ってユーザに課金することを許容する。３ＧＰＰはユーザ装置（ＵＥ、Use Equipment）とＩＭＳ並びにＩＭＳ内の構成要素間の信号にＳＩＰを選択した。

ＵＭＴＳ通信ネットワークの運用およびこのようなネットワーク内の種々の構成要素に関する特定の詳細はhttp://www.3gpp.orgから利用できるＵＭＴＳ技術仕様書から見つけることができる。非特許文献９からＵＭＴＳ内におけるＳＩＰの使用に関するさらなる詳細を見つけることができる。

添付する図面の図１はＧＰＲＳ／ＰＳアクセスネットワークの場合（ＩＭＳは勿論その他のアクセスネットワークを経て動作することができる）の移動ネットワーク構成へのＩＭＳの適合を概略的に示す。呼／セッション制御機能（ＣＳＣＦ（複数）、Call/Session Control Functions）はＩＭＳ内でＳＩＰプロキシとして動作する。３ＧＰＰ構成は３つのタイプのＣＳＣＦを定義する：プロキシＣＳＣＦ（Ｐ−ＣＳＣＦ、Proxy CSCF）、これはＳＩＰ端末のＩＭＳ内における最初のコンタクトポイントである；サービス提供ＣＳＣＦ（Ｓ−ＣＳＣＦ、Serving CSCF）、これはユーザが加入するサービスをユーザに提供する；および問い合わせＣＳＣＦ（Ｉ−ＣＳＣＦ、Interrogating CSCF）、この役割は正しいＳ−ＣＳＣＦを特定し、Ｐ−ＣＳＣＦを介してＳＩＰ端末から受信する要求をそのＳ−ＣＳＣＦに転送することである。

ユーザは特定のＳＩＰ登録（REGISTER）法を使用してＩＭＳに登録する。これはＩＭＳに所属し、ＳＩＰユーザ特定情報に到達することができるアドレスをＩＭＳに通知する機構である。３ＧＰＰにおいてＳＩＰ端末が登録を行う場合、ＩＭＳはユーザを認証し、利用可能なＳ−ＣＳＣＦ（複数）のセットからＳ−ＣＳＣＦをそのユーザに割り当てる。Ｓ−ＣＳＣＦ（複数）の割り当て基準は３ＧＰＰにより指定しないが、Ｓ−ＣＳＣＦ（複数）の割り当て基準は負荷分担およびサービス要求を含むことができる。注記するのはＳ−ＣＳＣＦの割り当てがＩＭＳベースサービスへのユーザアクセスの制御（および課金）にとり重要であることである。運用会社はユーザ対ユーザの直接ＳＩＰセッションを防止する機構を提供することができ、ユーザ対ユーザＳＩＰセッションはさもなければＳ−ＣＳＣＦをバイパスすることになろう。

Ｓ−ＣＳＣＦを既に選択していなければ、登録過程でＳ−ＣＳＣＦを選択するのがＩ−ＣＳＣＦの責務である。Ｉ−ＣＳＣＦはホームネットワークのホーム加入者サーバ（ＨＳＳ、Home Subscriber Server）から要求されたＳ−ＣＳＣＦ能力を受信し、受信能力に基づき適切なＳ−ＣＳＣＦを選択する。（注記するのは別の相手がユーザに着信し、ユーザに現在Ｓ−ＣＳＣＦを割り当てていない場合にユーザへのＳ−ＣＳＣＦ割り当てをＩ−ＣＳＣＦによっても実行することである。）登録ユーザがその後ＩＭＳにセッション要求を送信する場合、登録過程でＳ−ＣＳＣＦから受信する情報に基づき、Ｐ−ＣＳＣＦは選択するＳ−ＣＳＣＦに要求を転送することができる。

ＩＭＳサービスネットワーク内に、ＩＭＳサービス機能を実装するアプリケーションサーバ（ＡＳ（複数）、Application Servers）を提供する。アプリケーションサーバはＩＭＳシステムのエンドユーザにサービスを提供し、アプリケーションサーバを３ＧＰＰの定義するＭｒインタフェースを経てエンドポイントとして接続するか、または３ＧＰＰの定義するＩＳＣインタフェースを経てＳ−ＣＳＣＦにより「リンクイン」するかの何れかを行うことができる。後者の場合、初期フィルタ基準（ＩＦＣ、Initial filter Criteria）をＳ−ＣＳＣＦにより使用し、ＳＩＰセッション確立過程で「リンクイン」すべきアプリケーションサーバを判断する。種々のＩＦＣ（複数）を種々の呼の場合に適用することができる。ＩＭＳ登録手順の過程でユーザのユーザプロファイルの一部としてＨＳＳからＳ−ＣＳＣＦにより、ＩＦＣ（複数）を受信する。（アプリケーションサーバ制御ネットワークに所属する被呼者または発呼者の何れかの）加入者特定情報に応じて、あるアプリケーションサーバは動作を実行することになろう。例えば呼転送の場合、適切な（終端）アプリケーションサーバは所与の加入者への呼を転送することにする新しい着信相手を判断することになろう。Ｓ−ＣＳＣＦで受信するＳＩＰメッセージを特定のＳＩＰＡＳに転送すべきことをＩＦＣが指示する場合、そのＡＳをメッセージ経路に追加する。一度ＡＳによりＳ−ＣＳＣＦにＳＩＰメッセージを返送すると、ＳＩＰメッセージをその最終の宛先に向けて、またはＩＦＣ（複数）において別のＡＳを指示すれば、別のＡＳに転送する。

上述の通りＩＭＳネットワークでは、ＨＳＳは主として加入者データの蓄積の責を負う。ＨＳＳはDiameter（ダイアミタ）プロトコル（非特許文献１０）により他のノード（本明細書では一般に「ＨＳＳクライアント」と称す）と協働する。このようなＨＳＳクライアントの例はＩ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、ＡＰ（集団プロキシ）およびＡＳ（アプリケーションサーバ）である。

一般的概念では、ＨＳＳはドメイン（領域）の中央データベースであるということである。とはいえ幾つかのネットワークは単一ＨＳＳにより扱いうる以上のユーザを有し、これらのネットワークはそれ故２つ以上のＨＳＳを備える。２つ以上のＨＳＳを持つネットワークは加入位置機能（ＳＬＦ、Subscription Location Function）も包含する。特定ユーザについてＨＳＳに質問する必要のあるノードはまずＳＬＦに質問し、ＳＬＦはユーザを扱うＨＳＳのアドレスを返送する。ＳＬＦは本質的にDiameter再指令エージェントとして動作する。

しかしながらネットワークにただ１つのＨＳＳを持ち、配備するＳＬＦを持たない孤立するシナリオは現在の配備では非常に一般的であり、考慮もしなければならない。

ＨＳＳを含むDiameterルーティング論理は非特許文献５に見つけることができる。以下の抜粋はＣＳＣＦノードに焦点を当てるが、この抜粋は任意の他のタイプのＨＳＳクライアントに等しく適合する。

「Ｉ−ＣＳＣＦまたはＳ−ＣＳＣＦがあるユーザのＨＳＳアドレス／ネームを知れば、宛先領域および宛先ホストＡＶＰ（複数）（Attribute Value Pairs、属性値対）の双方は要求に存在するであろう。そうでなければ、宛先領域ＡＶＰのみが存在し、クライントのDiameterルーティングテーブルに基づき、命令を次のDiameterノード、例えばＳＬＦにルーティングするであろう。

一度再指令機能（ＳＬＦ）がアドレスまたは宛先ＨＳＳを（再指令ホストＡＶＰを使用して）返送すると、ＨＳＳへの再指令要求は宛先領域および宛先ホストＡＶＰ（複数）双方を含むであろう。

最初の要求を再指令機能に送信後、Ｓ−ＣＳＣＦは各ユーザのＨＳＳアドレスを蓄積する。

Ｓ−ＣＳＣＦに対しＨＳＳにより開始する要求は宛先ホストおよび宛先領域双方を含むであろう。Ｓ−ＣＳＣＦから以前の要求において受信した元のホストＡＶＰから、ＨＳＳはＳ−ＣＳＣＦへの要求に使用する宛先ホストＡＶＰを取得する。従ってＨＳＳにより開始する全ての要求のＡＢＮＦでは、宛先ホストＡＶＰを必須と言明する。

全ての要求のＡＢＮＦでは、宛先領域ＡＶＰを必須と言明する」。

出願者が認識するように、３ＧＰＰ標準において特に言及しない１つの問題はＨＳＳに対する冗長性解決策の問題である：実際の配備では、ユーザデータ（例えばＴＳＰで現在利用可能なものであるホット／予備構成では、負荷分担、など）は２つ以上のＨＳＳに蓄積することができよう。ＨＳＳクライアントに正しいＨＳＳのアドレスを学習することを許容するであろう機構は３ＧＰＰ標準では明記していない。ＩＥＴＦ Diameter文書（非特許文献１０）は「Diameterエージェント」に対する冗長性解決策を提供するが、宛先ホストに関しては冗長性解決策を提供しない。例えば３ＧＰＰＩＭＳでは、加入位置機能（ＳＬＦ）は「Diameter再指令エージェント」であり、ホーム加入者サーバＨＳＳは宛先ホストである。

この問題に対処するのが望ましい。

３ＧＰＰＴＳ２３．００２ ３ＧＰＰＴＳ２２．２２８ ３ＧＰＰＴＳ２３．２２８ ３ＧＰＰＴＳ２４．２２９ ３ＧＰＰＴＳ２９．２２８ ３ＧＰＰＴＳ２９．２２９ ３ＧＰＰＴＳ２９．３２８ ３ＧＰＰＴＳ２９．３２９リリース５乃至７ ３ＧＰＰＴＳ２４．２２８Ｖ５．８．０（２００４年３月） ＩＥＴＦ ＲＦＣ３５８８（章５．５．４）

本発明の第１の態様によれば、ＩＰマルチメディアサブシステムＩＭＳのホーム加入者サービスＨＳＳに対する冗長性を可能にする方法であって、冗長性は複数のＨＳＳインスタンスにより提供され、方法は、ＩＭＳのクライアントノードがＨＳＳの詳細を要求した場合、ＨＳＳインスタンスを代理するプロキシＨＳＳの詳細をクライアントノードに提供するように設定するステップと、複数のＨＳＳインスタンスのうちの、プロキシＨＳＳにおいてクライアントノードから受信した要求を処理するのに適切な１つを選択することをプロキシＨＳＳが行うように設定するステップと、要求を選択されたＨＳＳインスタンスンスに処理させるために当該選択されたＨＳＳインスタンスへ転送することをプロキシＨＳＳが行うようにように設定するステップとを有することを特徴とする方法が提供される。

上記方法は、加入位置機能ＳＬＦがＩＭＳに設けられ、ＳＬＦがクライアントノードにプロキシＨＳＳの詳細を提供するように設定するステップを有してもよい。

上記方法は、加入位置機能ＳＬＦがＩＭＳに設けられず、プロキシＨＳＳ自体がクライアントノードにプロキシＨＳＳの詳細を提供するように設定するステップを有してもよい。

クライアントノードとプロキシＨＳＳとの間の通信にDiameterプロトコルが使用されてもよい。

上記方法は、選択に基づき受信要求の宛先ホスト属性値対を変更するステップを有してもよい。

複数のプロキシＨＳＳインスタンスンスを有することによりプロキシＨＳＳの冗長性もが提供され、プロキシＨＳＳインスタンスンスに対する冗長性は標準Diameterプロトコル機構により処理されてもよい。

少なくとも少数のＨＳＳインスタンスンスがデータベースへの異なる個別のフロントエンドであってもよい。

上記方法は、選択の実行に使用する情報をプロキシＨＳＳに保持するステップを有してもよい。

上記情報には、ＨＳＳインスタンスンスに与えられる個別の負荷に関する情報と、ＨＳＳインスタンスンスの個別の可用性に関する情報と、ＨＳＳインスタンスンスの個別の状態に関する情報と、の少なくとも１つが含まれてもよい。

上記データベースが複数のサイトに亘って分散し、情報にはサイトに関する地理的情報が含まれてもよい。

上記方法は、選択の実行に使用する各ＨＳＳインスタンスンスの状態を監視するステップを有してもよい。

上記方法は、Diameterメッセージの使用により状態を監視するステップを有してもよい。

上記方法は、ＤＷＲ／ＤＷＡメッセージの使用により状態を監視するステップを有してもよい。

上記方法は、地理的位置、可用性、負荷および応答時間の少なくとも１つに基づき選択を実行するステップを有してもよい。

プロキシＨＳＳはＩＭＳのノードであってもよい。

プロキシＨＳＳはDiameterプロキシエージェントであってもよい。

クライアントノードはDiameterクライアントであってもよい。

クライアントノードは、ＩＭＳのインテロゲーティング呼セッション制御機能と、ＩＭＳのサービング呼セッション制御機能と、ＩＭＳの集団プロキシと、ＩＭＳのアプリケーションサーバと、の少なくとも１つを含んでもよい。

本方法はプロキシＨＳＳにおいて実行することができる。

ＨＳＳ以外のＩＭＳの宛先ホストにより、ＨＳＳが置換されていてもよい。

本発明の第２の態様によれば、ＩＰマルチメディアサブシステムＩＭＳのホーム加入者サービスＨＳＳに対する冗長性を可能にする装置であって、冗長性が複数のＨＳＳインスタンスにより提供され、装置は、ＩＭＳのクライアントノードがＨＳＳの詳細を要求し、ＨＳＳインスタンスを代理するプロキシＨＳＳの詳細をクライアントノードに提供するように設定する手段と、複数のＨＳＳインスタンスのうちの、プロキシＨＳＳにおいてクライアントノードから受信した要求を処理するのに適切な１つを選択することをプロキシＨＳＳが行うように設定する手段と、要求を選択されたＨＳＳインスタンスンスに処理させるために当該選択されたＨＳＳインスタンスへ転送することをプロキシＨＳＳが行うようにように設定する手段とを備えることを特徴とする装置が提供される。

上記装置はプロキシＨＳＳを備えてもよい。

本発明の別の態様によれば、ＩＰマルチメディアサブシステムＩＭＳの宛先ホストに対する冗長性を可能にする方法を提供し、冗長性を複数の宛先ホストインスタンスにより提供し、本方法が含むのは：ＩＭＳのクライアントノードが宛先ホストの詳細を要求する場合、宛先ホストインスタンスを代理するプロキシ宛先ホストの詳細をクライアントノードに提供するように設定するステップ；プロキシ宛先ホストが宛先ホストインスタンスの適切な１つを選択し、プロキシ宛先ホストにおいてクライアントノードから受信する要求を処理するように設定するステップ；およびプロキシ宛先ホストが要求を選択する宛先ホストインスタンスンスに転送し、処理するように設定するステップである。プロキシ宛先ホストはDiameterプロキシエージェントでありうる。これらの方法のステップを実行する手段を含む装置も提供する。

本発明の別の態様によれば、通信ネットワークのプロトコルサーバに対する冗長性を可能にする方法を提供し、冗長性を複数のプロトコルサーバインスタンスにより提供し、本方法が含むのは：プロトコルクライアントがプロトコルサーバの詳細を要求する場合、プロトコルサーバインスタンスを代理するプロキシプロトコルサーバの詳細をプロトコルクライアントに提供するように設定するステップ；プロキシプロトコルサーバがプロトコルサーバインスタンスの適切な１つを選択し、プロキシプロトコルサーバにおいてプロキシクライアントから受信する要求を処理するように設定するステップ；およびプロキシプロトコルサーバが要求を選択するプロトコルサーバインスタンスンスに転送し、処理するように設定するステップである。プロトコルはDiameterプロトコルでありうる。プロキシプロトコルサーバはDiameterプロキシエージェントでありうる。これらの方法のステップを実行する手段を含む装置も提供する。

本発明の第３の態様によれば、本発明の第１の態様による方法を実行する装置を制御するか、または装置にロードする場合本装置が本発明の第２の態様による装置になるようにするプログラムを提供する。プログラムを担体媒体において搬送することができる。担体媒体は蓄積媒体でありうる。担体媒体は伝送媒体でありうる。

本発明の第４の態様によれば、本発明の第３の態様によるプログラムによりプログラムする装置を提供する。

本発明の第５の態様によれば、本発明の第３の態様によるプログラム含む蓄積媒体を提供する。

本発明の実施形態は少なくとも１つの以下の利点を有する：
ネットワークに配備する１つの論理ＨＳＳが存在するので、任意の第３のパーティのベンダプロダクトが（標準化していない）ＨＳＳの冗長性解決策の利点を利用することが可能である。ＨＳＳクライアントとDiameterプロキシアプリケーション間インタフェースは純粋なDiameter標準機構に基づく。

ＩＰルーティングテーブルの変更は必要でなく、有利にはクライアントノードは本発明の実施形態におけるプロキシ装置の宛先アドレスを構成する必要があるだけであり、プロキシ装置は、プロキシ装置をアドレス指定するクライアントノードから受信する宛先アドレスをプロキシ装置で選択するサーバの宛先アドレスに置換するように設定する。

宛先ピアへの配信論理は負荷分担、ユーザ位置に基づきうる：シナリオに応じて構成することができる。

本発明を実施する方法および装置は現在の「単体」ＨＳＳおよび階梯化（レイヤ化）ＨＳＳ構成双方に有効である。最終宛先が単体ＨＳＳか、またはフロントエンドであるかは問題ではない。

本明細書で以前に考察したＩＰマルチメディアサブシステムの３Ｇ移動通信システムへの統合を概略的に示す図である。 本発明の実施形態において実行するステップを示す概要フローチャートである。 図２の方法を実行するために本発明を実施する装置の一部を示す概要ブロック図である。 本発明を実施するシステムにおける複数のプロキシＨＳＳ（Diameterプロキシ）の使用を示す概要ブロック図である。 ＨＳＳインスタンス（ＨＳＳフロントエンド）の選択に使用するために監視する情報を持つプロキシＨＳＳ例の一部を示す概要ブロック図である。

ＨＳＳのための冗長性解決策の問題を３ＧＰＰ標準で明確に言及していないことを以上で記述した。本発明の実施形態に関する詳細な説明の前に、この冗長性の問題に言及することになろう以下の３つの可能性な解決策を次に順次説明することにする。各解決策は以下に詳述するように幾つかの制約を有する：（ａ）全てのトラフィックはＳＬＦを通じてルーティングする；（ｂ）Diameterプロトコル標準手順への依頼；および（ｃ）ＩＰレイヤベース解決策。これに以下の説明が続くことになる：（ｄ）冗長ノードを取得する他の機構；および次いで（ｅ）本発明の実施形態による解決策。

（ａ）全てのトラフィックはＳＬＦを通じてルーティングする：
ＳＬＦはＨＳＳの状態を監視することができ（これはＡＳＤＮＳ機能に代わり現在エリクソン（Ericsson）のＩＰワークプロダクトにおいて行われ、ＳＮＭＰおよびＩＣＭＰをこの目的に使用する）、「アクティブで」／[好ましい]もののみを応答に含むことにする。ＨＳＳへ向かう全てのトラフィックはＳＬＦを通じてルーティングすべきである。

しかしながら標準によればＨＳＳにメッセージを送信しなければならない場合に何時でも、ＨＳＳクライアントがＳＬＦをポーリングすることは必須ではない。現在の実装に見つけることができる幾つかの例は：
・ Ｓ−ＣＳＣＦが初めてコンタクトを受け、ＳＬＦからＨＳＳ「宛先ホスト」を受信するとそれを蓄積する。その瞬間から同じユーザに対しそのアドレスを保持することができる。特別なポーリングを必要としない。
・ （ＳＩＰＲＥＧＩＳＴＥＲメッセージに埋め込む）専用機構によりＩ−ＣＳＣＦからＳ−ＣＳＣＦにＨＳＳ宛先ホストを送信することもできる。この方法ではＳ−ＣＳＣＦがＳＬＦから何ら情報を取り出す必要がないのは、Ｉ−ＣＳＣＦがＳＬＦから情報を受信し、Ｓ−ＣＳＣＦに伝達しているからである。この実装をエリクソンのＣＳＣＦで使用する。

その上加入者数が比較的小さい場合、現在の配備はＳＬＦを含まない；これが意味するのは「単一ＨＳＳシナリオ」も考慮しなければならないことである。

（ｂ）Diameterプロトコル標準手順への依頼：
純粋な標準Diameter機構に頼ることができないのは（非特許文献１０参照）、対応するDiameter・アプリケーション・ベース・メッセージのルーティングの責を負うDiameterエージェントを伴うシナリオにのみルーティングおよびフェイルオーバ機構を適用することができるからである。この意味で代替Diameterエージェントの使用により、フェイルオーバ機構は所与の宛先ホストに到達する代替法を提供する。宛先ホストがこのように障害になれば、ＲＦＣに明記する機構は存在しない。それは別の場合であろう。

Diameterエージェントは中継、プロキシ、再指令、または変換サービス（Diameterと別のＡＡＡプロトコル間のプロトコル変換を実行する）を提供するDiameterノードである。換言すれば、これらのサービスはDiameterメッセージを（宛先ホストにより指定する）最終宛先にルーティングするのに使用する。

（ｃ）ＩＰレイヤベース解決策：
別の手法はＩＰレイヤに頼ることであろう：冗長ノードが仮に同じＩＰアドレスを共有すれば（これはホット／予備冗長解決策に役立つであろう；「アクティブ」ノードのみが共有ＩＰアドレスを持つであろう）、アプリケーションに影響を与えることなくフェイルオーバを実行することが可能であろう。この代替方式は現在ＴＳＰにより提供し、その他の商用プラットフォームにも見つけることができるが（例えばモートローラ(Motorola)の先進ＴＣＡ通信サーバなど；サン（Sun）のクラスタも多くの製品にこの特徴を含む）、幾つかの欠点がある：
・ あるサイトから別のサイトに移動するＩＰを有することが意味するのは、ノード障害の場合にルーティングテーブルのホストＩＰ部は幾つかの更新を必要とするであろうことである（ＯＳＰＦはこの目的に使用できよう）。バックボーンを多くのルータにより構成すれば、バックボーンの完全な収束を達成するまで、正しい宛先へのトラフィックのルーティングは保証されないであろう。あるバックボーンの調整が各架設に必要であろう。
・ バックボーンは通常種々の解決策間で共有するので、その変更は他の解決策に影響を与えよう。従って幾つかの運用会社はこのような調整を行うことに同意しないであろう。その他に配備経費が指数的に増大するであろう。
・ これは安全でないと認められる。

（ｄ）冗長ノードを取得する他の機構：
冗長ノードは静的にテーブルにおいて構成することができよう。ネットワークのそれぞれのありうるＨＳＳ宛先ホストに対し、ＨＳＳ宛先ホストはその対応する２次（冗長）ＨＳＳ宛先ホストを決める。ＨＳＳクライアントはその場合ＨＳＳの状態を監視することができ、１次ＨＳＳが障害になるとその場合ＨＳＳクライアントはDiameter問い合わせを構成する２次ＨＳＳに送信するであろう。この代替方式の欠点は、ネットワークの全てのＨＳＳクライアント（ＣＳＣＦ、アプリケーションサーバ、ＡＡＡサーバ、ＢＳＦ、など）がこの機構を実装する場合のシナリオにおいてのみＨＳＳ冗長性が役立つであろうことである。

あるいは、冗長ノードに関する情報を伝達する新しいＡＶＰをＳＬＦ応答に加えることができよう。これは現在ＩＥＴＦＤＩＮＭＥ作業グループで研究中である。この解決策の欠点は、これらのＡＶＰが（後方両立性を提供するのに）オプションであり、それ故クライアントがＡＶＰを使用するであろうことを保証できないことである。その上この情報を提供するのにＳＬＦが必要であり、その他の考慮（ユーザ位置、負荷平衡、など）に基づきメッセージをルーティングすることができない。

（ｅ）本発明の実施形態：
本発明の実施形態で、先進Diameterプロキシを導入し、ネットワークにおいて単一論理ＨＳＳを提供する。さらなる詳細を以下に、簡単ではあるが提供することにする：
・ 各ＨＳＳクライアントは単一ＨＳＳ宛先ホストを構成することができ、その場合ＳＬＦを必要としないであろう（ＳＬＦが動作する場合本発明の実施形態を使用することもできるが）。
・ 単一論理ＨＳＳへのアクセスポイントは１つまたは幾つかの先進Diameterプロキシを含むことができ、ＨＳＳクライアントから送信する各Diameterメッセージはこれらのプロキシの１つにおいて受信する。ＨＳＳクライアント側から、Diameterプロキシを標準Diameterインタフェースにおけるように構成することができる。
・ 冗長性を提供し、トラフィック処理容量を見積もるために、幾つかのプロキシが存在しえよう。プロキシに対する冗長性はDiameter標準手順により達成することができる（非特許文献１０参照）。
・ 先進DiameterプロキシはDiameterメッセージを処理するのに最も適切なDiameterピアであるものを見出す機構を提供するであろう。これらのピアはＨＳＳフロントエンド（ＦＥ（複数）、Front Ends）でありえ、ＨＳＳフロントエンドがアクセスするのはユーザデータを包含するデータベースか、またはＨＳＳアプリケーション論理およびユーザデータ双方を保持する単体ＨＳＳ（複数）である。これらの機構はＦＥの可用性に関するＨＳＳ単体、並びにユーザデータの地理的位置を考慮し、Diameterピアへの負荷配分を管理する。

本発明の実施形態を次に図２および図３を参照してより詳細に説明することにする。図２は本発明の実施形態において実行するステップを示す概要フローチャートであり、一方図３は本発明を実施する装置の一部を示す概要ブロック図である。

図２は以前に説明したＨＳＳクライアント１０およびＳＬＦ３０を示す。この例のＨＳＳは第１のおよび第２のＨＳＳインスタンス４０の包含によりある程度の冗長性を備える。最後に、プロキシＨＳＳ２０も備え、その機能は以下の説明から明らかになろう。

特定ユーザに関するＨＳＳが持つ詳細（例えば、「宛先ホストＡＶＰ」）のＨＳＳクライアント１０による要求に応じて、ステップＳ１でプロキシＨＳＳ２０の詳細をＳＬＦ３０（１つ存在すれば）からＨＳＳクライアント１０に提供するか、または（例えばＳＬＦが存在しなければ）ＨＳＳクライアント１０において予め構成するか、またはプロキシＨＳＳ２０自体から提供するかの何れかである。有利には、各ＨＳＳクライアント１０はプロキシＨＳＳ２０を宛先指定する単一ＨＳＳ宛先ホストを構成し、これによりクライアントの単純化構成を提供し、同時にＳＬＦの必要性を無くすことを許容する。プロキシＨＳＳ２０が持つ詳細をステップＳ２でＨＳＳクライアント１０により受信する。

ステップＳ２で受信する詳細を使用してステップＳ３で、ＨＳＳクライアント１０はプロキシＨＳＳ２０に要求を送信し、この要求をステップＳ４でプロキシＨＳＳ２０により受信する。

ステップＳ５で、プロキシＨＳＳ２０は選択処理を実行し、要求を処理するのに選択すべき第１のおよび第２のＨＳＳインスタンス４０の内の何れかを判断する；選択処理で使用する可能な基準の例をさらに以下で詳述する。

ステップＳ５で適切なＨＳＳインスタンス４０の選択を行うと、ステップＳ５ａでＨＳＳクライアント１０から受信する宛先ホストＡＶＰを選択するＨＳＳインスタンス４０の宛先ホストＡＶＰにより置換する。次いでステップＳ６で要求をプロキシＨＳＳ２０により選択するＨＳＳインスタンス４０に転送し、ステップＳ７で選択するＨＳＳインスタンス４０により要求を受信し、処理する。

要求を処理すると、選択するＨＳＳインスタンス４０からプロキシＨＳＳ２０に応答を送信し、ステップＳ９でプロキシＨＳＳ２０により受信する。ステップＳ１０で、プロキシＨＳＳ２０によりＨＳＳクライアント１０に応答を転送し、ステップＳ１１でＨＳＳクライアント１０により受信する。

図２のステップを実行するプロキシＨＳＳ２０、ＳＬＦ３０およびＨＳＳインスタンス４０の一部を図３に概略的に示し、図３の部分Ｐ１およびＰ４乃至Ｐ１０を応用して図２のステップＳ１およびＳ４乃至Ｓ１０をそれぞれ実行する。

全てのノードを相互接続するDiameterプロキシエージェント（例えば、プロキシＨＳＳ）をDiameterレベルで使用することは可能である。このオプションにより、現在のクライアントノードに変更が不要であるのは、全ての論理をプロキシに集中することができ、これによりプロキシ２０を宛先指定するクライアント（例えば、１０）から受信する「宛先ホストＡＶＰ」をプロキシ２０で選択するＨＳＳインスタンスの「宛先ホストＡＶＰ」により置換し、クライアントから受信するメッセージをＨＳＳインスタンスに宛先指定するのにそれを使用することができるからである。

プロキシにより余分の処理および遅延を導入するが、他方ＨＳＳクライアントからＳＬＦへの問い合わせを除去することができ、それが意味する処理能力および遅延を除去することができる。さらにプロキシＨＳＳ２０のであり、個別のＨＳＳインスタンスのでないアドレスをＨＳＳクライアントは構成さえすればよい。ＨＳＳインスタンスにより処理する必要があるメッセージおよび要求を送信するのに、クライアントは次いで上記アドレスを（例えば、Diameterプロトコルを使用すれば「宛先ホストＡＶＰ」として）使用し、これによりこれらのメッセージおよび要求をプロキシＨＳＳに自動的にルーティングするように設定することになろう。

プロキシを２重化することは可能である。フェイルオーバおよびリンク監視の標準手順（非特許文献１０参照）をこれに使用することができる。図４は複数のDiameterプロキシ２０による構成を示す。

あたかもネットワークに配備する（ＳＬＦがなく）単一のＨＳＳがあるかのように、ＨＳＳクライアントにおいて発生するDiameterメッセージはプロキシＨＳＳ２０のアドレスである同じ宛先ホストを有する。

本発明の方法およびプロキシは共に：単体および階梯化構成において使用できる。要するに、単体構成によるＨＳＳインスタンスはＨＳＳクライアントと交換する信号を処理するように設定する処理手段およびアプリケーション論理、並びに上記処理を達成するのに必要なデータ（例えば、加入者の動的および静的情報）を含む蓄積手段を含む。次いで、ＨＳＳ「階梯化」構成は複数のＨＳＳフロントエンド（ＦＥ）を含み、ＨＳＳフロントエンドは処理手段およびアプリケーション論理、並びに任意のＨＳＳＦＥがその処理の達成に必要とすることがありうる全ての必要なデータを蓄積する（物理的または論理的）中央データベースＤＢ（database）を含む。

２つまたはそれ以上のサイトにこのＤＢが分散する場合、加入者データベース（ＤＢ）にアクセスするＨＳＳフロントエンドの場合、地理的データ分散に基づき各ユーザにサービスを提供するのに最も適切なフロントエンド（ＦＥ）またはフロントエンドグループプロキシは何かに関する情報を、プロキシは保持することができる。

先進Diameterプロキシアプリケーションは所与のユーザ宛てのメッセージを処理することができるDiameterピア（これらのピアはユーザデータを包含するデータベースにアクセスする単体ＨＳＳか、またはフロントエンドの何れかでありえよう）の状態を監視することができる。冗長性の場合、少なくとも２つのDiameterピア（例えば、ＨＳＳインスタンス）は各ユーザを管理することができるべきである。終端ピアを監視するのにDiameterプロキシで使用する機構はDiameter標準（ＤＷＲ／ＤＷＡメッセージ）に含む同じものか、または異なるものの何れかでありえよう。

例えば地理的位置および可用性に基づき動作を処理することができる種々のDiameterピア間に、プロキシはトラフィックを分配することができよう。この分配はサーバの負荷、応答時間、ラウンドロビン、などのような既存平衡化機構に基づくことができる。

これらの概念を図５に示す。

一度適切な終端ノードを選択すると、ＨＳＳクライアントから受信する宛先ホストＡＶＰ（即ち、単一論理ＨＳＳを特定するＨＳＳDiameterＵＲＩ）を選択するDiameterピアに従い置換し、Diameterメッセージを終端ノードに送信する。

応答を終端ノードから受信すると、一貫するDiameterホストＩＤを保持することが望ましい（即ち、応答は要求に使用する宛先ホストから来るべきである）。この単一論理ＨＳＳの内部構成はＨＳＳクライアントに透明である、即ちプロキシはＨＳＳクライアントに選択する宛先ホストの実際のDiameterＵＲＩを提供する必要はない。

ＨＳＳからの要求もプロキシ（代理）することができる。ＨＳＳDiameterプロキシインタフェースは両方向における冗長性を許容する（３ＧＰＰ標準手順に従いＨＳＳ／ＦＥにＨＳＳクライアントDiameterＵＲＩを蓄積することができる）。

本発明をこのようにこれまで主としてＨＳＳクライアントおよびＨＳＳに関して説明したが、本発明の実施形態はより広く適用することができる。一般的な意味で、本発明の実施形態は任意の「Diameterクライアント」（例えば、呼セッション制御機能ＣＳＣＦまたはアプリケーションサーバＡＳ）と任意の「宛先ホスト」（例えば、ＨＳＳ）間に「Diameterプロキシエージェント」（ＤＰＡ、Diameter proxy agent）（ＩＭＳ構成において、しかしＩＭＳ構成に限定せず使用できる）を導入する。

ＤＰＡはクライアント側の標準プロキシエージェントとして動作し、宛先ホスト側に関して先進的である。ＤＰＡはクライアントから「宛先ホスト」ＡＶＰを包含する要求を受信することができる。ＤＰＡはクライアントから受信する（架空の）「宛先ホスト」ＡＶＰを「可用性情報」に従いＤＰＡにより選択する最終ＨＳＳに要求をルーティングするのに使用できる特定情報に変換する。ＤＰＡが従って蓄積するのは、クライアントから受信することができ、ＤＰＡにルーティングする（架空の）「宛先ホスト」ＡＶＰ、および選択することができる実際のＨＳＳ（複数）が持つ実際の「宛先ホスト」ＡＶＰ（複数）特定情報の対応するリストを含むテーブルである。動的に更新することができる実際のＨＳＳ毎の可用性情報、並びにＨＳＳ（複数）の地理的位置対クライアントの位置についての情報もＤＰＡにより保持し、以上の変換に使用することができる。

ＳＬＦを含むシナリオおよびＳＬＦを含まないシナリオ双方において、本発明の実施形態はＨＳＳおよび／またはＨＬＲの冗長性を許容し、単体または階梯化ＨＳＳ構成に使用することができる。

本発明のＤＰＡはクライアントに対し標準化Diameter冗長性手順を提供することができ、それにより複数のＤＰＡの配備を許容し、クライアントと宛先ホスト間の通信に関する高い可用性を提供する。さらに、Diameterクライアント（例えば、ＣＳＣＦ（複数））またはDiameterサーバ（例えばＨＳＳ（複数））に修正が必要でないのは、ＤＰＡにより実行する新しい処理が「Diameter」レベルにおいてのみ動作し、アプリケーションレベル（例えば、ＣＸ−ｉｎｔｆ関係処理）では動作しないからである。

認識されるであろうことは、デバイスまたは装置において動作するプログラムにより以上で説明する構成要素の１つまたは複数の動作を制御することができることである。このような動作プログラムはコンピュータの読むことができる媒体上に蓄積することができるか、または例えばインターネットウェブサイトから提供するダウンロード可能なデータ信号のような信号に埋め込むことができよう。添付する特許請求の範囲は動作プログラムをそれ自体により、または担体上の記録として、または信号として、または任意の他の形式において包含すると解釈するものとする。

Claims (23)

1. ＩＰマルチメディアサブシステムＩＭＳのホーム加入者サービスＨＳＳに対する冗長性を可能にする方法であって、
   冗長性は複数のＨＳＳインスタンスにより提供され、
   前記方法は、
   前記ＩＭＳのクライアントノードがＨＳＳの詳細を要求し、
   前記ＨＳＳインスタンスを代理するプロキシＨＳＳの詳細を前記クライアントノードに提供するように設定するステップと、
   前記複数のＨＳＳインスタンスのうちの、前記プロキシＨＳＳにおいて前記クライアントノードから受信した要求を処理するのに適切な１つを選択することを前記プロキシＨＳＳが行うように設定するステップと、
   前記要求を前記選択されたＨＳＳインスタンスンスに処理させるために当該選択されたＨＳＳインスタンスへ転送することを前記プロキシＨＳＳが行うようにように設定するステップと
   を有することを特徴とする方法。
2. 加入位置機能ＳＬＦが前記ＩＭＳに設けられ、
   前記ＳＬＦが前記クライアントノードに前記プロキシＨＳＳの詳細を提供するように設定するステップを有する
   ことを特徴とする請求項１に記載の方法。
3. 加入位置機能ＳＬＦが前記ＩＭＳに設けられず、
   前記プロキシＨＳＳ自体が前記クライアントノードに前記プロキシＨＳＳの詳細を提供するように設定するステップを有する
   ことを特徴とする請求項１または２に記載の方法。
4. 前記クライアントノードと前記プロキシＨＳＳとの間の通信にDiameterプロトコルが使用されることを特徴とする請求項１から３のいずれか１項に記載の方法。
5. 前記選択に基づき前記受信要求の宛先ホスト属性値対を変更するステップを有することを特徴とする請求項１から４のいずれか１項に記載の方法。
6. 複数のプロキシＨＳＳインスタンスンスを有することにより前記プロキシＨＳＳの冗長性もが提供され、
   前記プロキシＨＳＳインスタンスンスに対する冗長性は標準Diameterプロトコル機構により処理される
   ことを特徴とする請求項１から５のいずれか１項に記載の方法。
7. 少なくとも少数の前記ＨＳＳインスタンスンスがデータベースへの異なる個別のフロントエンドである
   ことを特徴とする請求項１から６のいずれか１項に記載の方法。
8. 前記選択の実行に使用する情報を前記プロキシＨＳＳに保持するステップを有することを特徴とする請求項１から７のいずれか１項に記載の方法。
9. 前記情報には、前記ＨＳＳインスタンスンスに与えられる個別の負荷に関する情報と、前記ＨＳＳインスタンスンスの個別の可用性に関する情報と、前記ＨＳＳインスタンスンスの個別の状態に関する情報と、の少なくとも１つが含まれることを特徴とする請求項８に記載の方法。
10. 前記データベースが複数のサイトに亘って分散し、前記情報には前記サイトに関する地理的情報が含まれることを特徴とする、請求項７に従属する、請求項８または９に記載の方法。
11. 前記選択の実行に使用する各ＨＳＳインスタンスンスの状態を監視するステップを有することを特徴とする請求項１から１０のいずれか１項に記載の方法。
12. Diameterメッセージの使用により前記状態を監視するステップを有することを特徴とする請求項１１に記載の方法。
13. ＤＷＲ／ＤＷＡメッセージの使用により前記状態を監視するステップを有することを特徴とする請求項１２に記載の方法。
14. 地理的位置、可用性、負荷および応答時間の少なくとも１つに基づき前記選択を実行するステップを有することを特徴とする請求項１から１３のいずれか１項に記載の方法。
15. 前記プロキシＨＳＳは前記ＩＭＳのノードであることを特徴とする請求項１から１４のいずれか１項に記載の方法。
16. 前記プロキシＨＳＳはDiameterプロキシエージェントであることを特徴とする請求項１から１５のいずれか１項に記載の方法。
17. 前記クライアントノードはDiameterクライアントであることを特徴とする請求項１から１６のいずれか１項に記載の方法。
18. 前記クライアントノードは、前記ＩＭＳのインテロゲーティング呼セッション制御機能と、前記ＩＭＳのサービング呼セッション制御機能と、前記ＩＭＳの集団プロキシと、前記ＩＭＳのアプリケーションサーバと、の少なくとも１つを含むことを特徴とする請求項１から１７のいずれか１項に記載の方法。
19. ＨＳＳ以外の前記ＩＭＳの宛先ホストにより、前記ＨＳＳが置換されていることを特徴とする請求項１から１８のいずれか１項に記載の方法。
20. ＩＰマルチメディアサブシステムＩＭＳのホーム加入者サービスＨＳＳに対する冗長性を可能にする装置であって、
    冗長性が複数のＨＳＳインスタンスにより提供され、
    前記装置は、
    前記ＩＭＳのクライアントノードがＨＳＳの詳細を要求し、
    前記ＨＳＳインスタンスを代理するプロキシＨＳＳの詳細を前記クライアントノードに提供するように設定する手段と、
    前記複数のＨＳＳインスタンスのうちの、前記プロキシＨＳＳにおいて前記クライアントノードから受信した要求を処理するのに適切な１つを選択することを前記プロキシＨＳＳが行うように設定する手段と、
    前記要求を前記選択されたＨＳＳインスタンスンスに処理させるために当該選択されたＨＳＳインスタンスへ転送することを前記プロキシＨＳＳが行うようにように設定する手段と
    を備えることを特徴とする装置。
21. 前記装置は前記プロキシＨＳＳを備えることを特徴とする請求項２０に記載の装置。
22. 請求項１から１９のいずれか１項に記載の方法を実行するように装置を制御することを特徴とするプログラム。
23. 請求項２２に記載のプログラムを格納した記録媒体。

Images