(57)【要約】  ＩＰマルチメディアサブシステムを備えるユニバーサル移動通信システムネットワークにおいて使用するための方法が開示される。この方法は、第１のノードに関連付けられているイベントの発生を示すネットワークに属する第１のノードに関するノードのステータス情報を受信するステップと、イベントの発生によって不都合な影響を受けるネットワークに属する第１のノードと第２のノード間に確立されるネットワークアソシエーションの存在を判定するステップと、ネットワークアソシエーションが終了され、第１のノードと第２のノード間に新規のネットワークアソシエーションが確立されることを可能にするステップを備えている。【選択図】  図３
2010525623.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰマルチメディアサブシステムを備えるユニバーサル移動通信システムネットワークにおいて使用するための方法であって、
第１のノードに関連付けられているイベントの発生を示す前記ネットワークに属する前記第１のノードに関するノードのステータス情報を受信するステップと、
前記イベントの前記発生による不都合な影響を受ける前記ネットワークに属する、前記第１のノードと第２のノード間に確立されているネットワークアソシエーションの存在を判定するステップと、
前記ネットワークアソシエーションが終了され、前記第１のノードと前記第２のノード間に新規のネットワークアソシエーションが確立されることを可能にするステップと
を備えることを特徴とする方法。
【請求項２】
前記ネットワークアソシエーションが終了されるべきであることを示すメッセージを、前記第２のノードに送信するステップを更に備える
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記判定は、前記第２のノードによって少なくとも一部分がなされる
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記第１のノードに関する情報を有するメッセージを、前記第２のノードに送信するステップと、
前記イベントの前記発生による影響を受ける前記第１のノードと前記第２のノード間におけるネットワークアソシエーションの前記存在を判定するために、前記第２のノードにおいて前記第１のノードの情報を使用するステップと
を備えることを特徴とする請求項３に記載の方法。
【請求項５】
前記メッセージは、前記第２のノード、および、前記ネットワークの他のノードに送信されるＳＩＰメッセージリクエストであるＳＩＰマルチキャストメッセージである
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記第１のノードの情報は、前記第１のノードの接続情報を有する
ことを特徴とする請求項４または５に記載の方法。
【請求項７】
前記判定を行うために、前記メッセージの接続ヘッダの少なくとも一部分を使用するステップを備える
ことを特徴とする請求項４、５、または６に記載の方法。
【請求項８】
前記第１のノードの情報は、前記第１のノードのＳＩＰユニフォームリソース識別子を有する
ことを特徴とする請求項４乃至７のいずれか１項に記載の方法。
【請求項９】
前記第１のノードと第２のノード間にある前記ネットワークアソシエーションの前記再確立のタイミングを、少なくとも一部分がランダムで判定されることで、前記イベント発生の観点から、前記ネットワークの他のノードに関するいくつかのネットワークアソシエーションが前記第１のノードと再確立される場合のシステム負荷を緩和させるステップと
を備えることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
タイムウィンドウを前記第２のノードに送信し、前記タイムウィンドウ内に前記再確立を少なくとも開始するステップを備える
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記イベントは、前記ネットワークアソシエーションを維持するために必要とされる情報の少なくとも一部分の損失を生じさせるものである
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記イベントは、前記第２のノードの少なくとも一部分の故障に関係している
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記イベントは、前記第２のノードの少なくとも一部分の利用不可な状態に関係している
ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記イベントは、前記第２のノードの再起動に関係している
ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記ネットワークアソシエーションは、前記第１のノードと前記第２のノード間の通信セッションを有する
ことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
請求項２に従属する場合に、前記メッセージは、ＳＩＰ  ＢＹＥメッセージである
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ネットワークアソシエーションは、前記第１のノードと前記第２のノード間のサブスクリプションを有する
ことを特徴とする請求項１乃至１６のいずれか１項に記載の方法。
【請求項１８】
請求項２に従属する場合、前記メッセージは、最終的なＳＩＰ  ＮＯＴＩＦＹメッセージである
ことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記ネットワークアソシエーションは、前記第１のノードと前記第２のノード間のセキュリティアソシエーションを有する
ことを特徴とする請求項１乃至１８のいずれか１項に記載の方法。
【請求項２０】
前記ネットワークアソシエーションは、前記第１のノードと前記第２のノード間のＰＤＰコンテキストを有する
ことを特徴とする請求項１乃至１９のいずれか１項に記載の方法。
【請求項２１】
ルート情報を参照して、前記判定を行う
ことを特徴とする請求項１乃至２０のいずれか１項に記載の方法。
【請求項２２】
当該方法を実行している前記ノードに記憶されている前記情報に基づいて、前記判定を行う
ことを特徴とする請求項１乃至２１のいずれか１項に記載の方法。
【請求項２３】
前記第１のノードは、アプリケーションサーバである
ことを特徴とする請求項１乃至２２のいずれか１項に記載の方法。
【請求項２４】
前記第１のノードは、サービング呼セッション制御機能である
ことを特徴とする請求項１乃至２３のいずれか１項に記載の方法。
【請求項２５】
当該方法は、プロキシ呼セッション制御機能において実行される
ことを特徴とする請求項１乃至２４のいずれか１項に記載の方法。
【請求項２６】
前記第１のノードは、プロキシ呼セッション制御機能である
ことを特徴とする請求項１乃至２４のいずれか１項に記載の方法。
【請求項２７】
当該方法は、ゲートウエイＧＰＲＳサポートノードにおいて実行される
ことを特徴とする請求項２６に記載の方法。
【請求項２８】
当該方法は、前記第２のノードにおいて実行される
ことを特徴とする請求項１乃至２７のいずれか１項に記載の方法。
【請求項２９】
前記ノードのステータス情報は、セッション開始プロトコルリクエストで受信される
ことを特徴とする請求項１乃至２８のいずれか１項に記載の方法。
【請求項３０】
前記セッション開始プロトコルリクエストは、リクエストユニフォームリソース識別子であり、
前記リクエストユニフォームリソース識別子は、前記ノードのステータス情報を内包する前記ＳＩＰリクエスト、および、前記ノードのステータス情報の意図される受信者のうちの少なくとも１つを同定する
ことを特徴とする請求項２９に記載の方法。
【請求項３１】
前記受信したリクエストユニフォームリソース識別子から前記意図される受信者を判定するステップを備える
ことを特徴とする請求項３０に記載の方法。
【請求項３２】
前記判定された受信者に、前記ステータス情報を転送するステップを備える
ことを特徴とする請求項３１に記載の方法。
【請求項３３】
受信ノードが、前記意図される受信者の１つと判定される場合、前記受信ノードにおいて前記ステータス情報を使用するステップを備える
ことを特徴とする請求項３１または３２に記載の方法。
【請求項３４】
前記意図される受信者を判定するために、前記リクエストユニフォームリソース識別子に関連付けられている初期フィルタ基準を参照するステップを備える
ことを特徴とする請求項３１、３２、または３３に記載の方法。
【請求項３５】
前記リクエストユニフォームリソース識別子から前記意図される受信者を判定するために、ダイナミックネームサーバを参照するステップを備える
ことを特徴とする請求項３１、３２、または３３に記載の方法。
【請求項３６】
以前に受信されたＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストに依存して、前記意図される受信者を判定するステップを備える
ことを特徴とする請求項３１、３２、または３３に記載の方法。
【請求項３７】
前記セッション開始プロトコルリクエストは、ＳＩＰ  ＰＵＢＬＩＳＨリクエストである
ことを特徴とする請求項２９乃至３６のいずれか１項に記載の方法。
【請求項３８】
前記ノードのステータスについてのさらなる情報を推定するために、前記ＳＩＰ  ＰＵＢＬＩＳＨリクエストからの有効時間情報を使用するステップを備える
ことを特徴とする請求項３７に記載の方法。
【請求項３９】
前記セッション開始プロトコルリクエストは、ＳＩＰ  ＭＥＳＳＡＧＥリクエストである
ことを特徴とする請求項２９乃至３６のいずれか１項に記載の方法。
【請求項４０】
前記セッション開始プロトコルリクエストユニフォームリソース識別子によって同定されるそれらのノードに関する前記ノードのステータスを記憶するステップを備える
ことを特徴とする請求項２９乃至３９のいずれか１項に記載の方法。
【請求項４１】
ＩＰマルチメディアサブシステムを備えるユニバーサル移動通信システムのネットワークにおいて使用するための装置であって、
第１のノードに関連付けられているイベントの発生を示す、前記ネットワークの前記第１のノードに関するノードのステータス情報を受信する手段と、
前記イベントの発生によって不都合な影響を受ける前記ネットワークの前記第１のノードと第２のノード間で確立されるネットワークアソシエーションの存在を判定する手段と、
前記ネットワークアソシエーションが終了され、前記第１のノードと前記第２のノード間の新規のネットワークアソシエーションがその場で確立されることを可能にする手段と
を備えることを特徴とする装置。
【請求項４２】
請求項１乃至４０のいずれか１項に記載されている方法を実行するための装置を制御するためのプログラム。
【請求項４３】
装置にロードされる場合に、前記装置を請求項４１で記載されている装置として機能させることを特徴とするプログラム。
【請求項４４】
搬送媒体によって搬送されることを特徴とする請求項４２、または４３に記載のプログラム。
【請求項４５】
前記搬送媒体は、記憶媒体であることを特徴とする請求項４４に記載のプログラム。
【請求項４６】
前記搬送媒体は、通信媒体であることを特徴とする請求項４４に記載のプログラム。
【請求項４７】
請求項４２乃至４６のいずれか１項に記載のプログラムによってプログラムされている装置。
【請求項４８】
請求項４２乃至４５のいずれか１項に記載のプログラムを含んでいる記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、ＩＰマルチメディアサブシステムを備えるユニバーサル移動通信システムのような、通信ネットワークにおいて使用する方法、および装置に関するものである。
【背景技術】
【０００２】
ＩＰマルチメディアサービスは、同一のセッションにおいて、音声、映像、メッセージ、データ等を動的に組み合わせたものを提供する。基本的なアプリケーションの数、および、接続可能なメディアの数を増やすことによって、エンドユーザに提供されるサービスの数は増加し、かつ個人間の通信は豊かなものになっている。このことはいわゆる「複合ＩＰマルチメディア」サービスを含む、次世代の、個人向けのマルチメディア通信サービスを豊富にすることになるだろう。
【０００３】
ユニバーサル移動通信システム（ＵＭＴＳ）は、高データレートと拡張サービスを加入者に提供するように設計されている、第三世代無線通信システムである。ＵＭＴＳは、ＧＳＭとＵＭＴＳの間の重要な発展段階である汎用パケット無線サービス（ＧＰＲＳ）を備える、移動通信用グローバルシステムの後継である。ＧＰＲＳは、パケット交換をＧＳＭコアネットワークに導入して、パケットデータネットワーク（ＰＤＮ）群への直接アクセスを可能にしている。このことは、ＧＳＭ呼ネットワークを通して、ＩＳＤＮの限界である６４ｋｂｐｓを超える高データレートのパケット交換通信を可能にしている。このパケット交換通信は、２Ｍｂｐｓ以上のレートのＵＭＴＳデータ通信のために必要である。ＵＭＴＳは、欧州電気通信標準化メカニズム（ＥＴＳＩ）や電波産業会（ＡＲＩＢ）のような、地域の標準化団体の集まりである、第三世代パートナーシッププロジェクト（３ＧＰＰ）によって標準化されている。詳細は、３ＧＰＰ  ＴＳ２３．００２を参照されたい。
【０００４】
ＵＭＴＳアーキテクチャは、新規のＩＰマルチメディアサービス（３ＧＰＰ  ＴＳ２２．２２８、ＴＳ  ２３．２２８、ＴＳ  ２４．２２９、ＴＳ  ２９．２２８、ＴＳ  ２９．２２９、ＴＳ  ２９．３２８、および、ＴＳ  ２９．３２９のリリース５から７を参照）だけでなく、伝統的な電話通信をサポートするための、ＩＰマルチメディアサブシステムとして知られているサブシステムを含んでいる。ＩＭＳは、標準化されたＩＭＳサービスイネーブラの使用を通して、エンドユーザ個人間の通信体験を豊かにするための鍵となる特徴を提供している。ここで、ＩＭＳサービスイネーブラは、ＩＰベースのネットワーク上で、人対コンテンツ（クライアント対サーバ）通信サービスだけでなく、新規の豊かな個人間（クライアント対クライアント）通信サービスを容易にする。ＩＭＳは、インターネットだけでなく、ＰＳＴＮ（公衆交換電話網）／ＩＳＤＮ（総合デジタル通信網）の両方に接続可能である。
【０００５】
ＩＭＳは、ユーザ端末間（または、ユーザ端末とアプリケーションサーバ間）の呼またはセッションの、セットアップおよび制御のために、セッション開始プロトコル（ＳＩＰ）を使用する。ＳＩＰシグナリングによって搬送されるセッション記述プロトコルは（ＳＤＰ）は、セッションのメディアコンポーネントを記述し、かつ交渉するために使用されている。ＳＩＰはユーザ対ユーザプロトコルとして作成されているが、ＩＭＳはオペレータおよびサービスプロバイダに、サービスへのユーザアクセスを制御すること、および、それに応じてユーザに課金することを可能にしている。３ＧＰＰは、ＩＭＳ内の構成要素間と同様に、移動機器（ＵＥ）とＩＭＳ間のシグナリングに対してもＳＩＰを選択している。
【０００６】
ＵＭＴＳ通信ネットワークの運用、および、そのようなネットワークの様々な構成要素の具体的な詳細は、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから利用可能なＵＭＴＳの技術仕様書において参照可能である。ＵＭＴＳにおけるＳＩＰの使用のさらなる詳細は、３ＧＰＰ技術仕様書ＴＳ  ２４．２２８  Ｖ５．８．０（２００４−０３）において参照可能である。
【０００７】
図１は、ＧＰＲＳ／ＰＳアクセスネットワークの場合において、ＩＭＳがどのように移動ネットワークアーキテクチャにおいて適用されているかを示す模式図である（当然、ＩＭＳは、他のアクセスネットワーク上でも動作可能である）。呼／セッション制御機能（ＣＳＣＦ）群は、ＩＭＳにおけるＳＩＰプロキシとして動作する。３ＧＰＰは、３つのタイプのＣＳＣＦを定義している。それは、ＳＩＰ端末用のＩＭＳにおける最初の接続点であるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、加入者であるユーザにサービスを提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、および、ユーザが接続すべきＳ−ＣＳＣＦを同定し、そのＳ−ＣＳＣＦにＰ−ＣＳＣＦを介してＳＩＰ端末から受信されるリクエストを転送する役割を有するインターロゲイティングＣＳＣＦ（Ｉ−ＣＳＣＦ）である。
【０００８】
ユーザは、規定されているＳＩＰ  ＲＥＳＩＳＴＥＲ（ＳＩＰ登録）方法を使用してＩＭＳに登録する。これは、ＩＭＳに接続し、かつ、ＳＩＰユーザアイデンティティに到達できるアドレスをＩＭＳに通知するためのメカニズムである。３ＧＰＰにおいて、ＳＩＰ端末が登録を実行する場合、ＩＭＳはユーザを認証し、利用可能なＳ−ＣＳＣＦ群のセットから１つのＳ−ＣＳＣＦをそのユーザに割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰによって規定されていないが、これには、負荷の共有やサービス要件を含んでいても良い。Ｓ−ＣＳＣＦの割当は、ＩＭＳベースのサービスへのユーザアクセスを制御する（および、ユーザアクセスに対して課金する）ための鍵であることに注意されたい。オペレータは、Ｓ−ＣＳＣＦをバイパスする別の方法で、直接のユーザ間のＳＩＰセッションを防止するためのメカニズムを提供することができる。
【０００９】
登録処理中に、Ｓ−ＣＳＣＦがまだ選択されていない場合には、Ｓ−ＣＳＣＦを選択することはＩ−ＣＳＣＦの責任である。Ｉ−ＣＳＣＦは、ホームネットワークのホーム加入者サーバ（ＨＳＳ）から、要求されるＳ−ＣＳＣＦの機能群を受信し、その受信した機能群に基づいて適切なＳ−ＣＳＣＦを選択する。［ユーザが他のパーティによって発呼され、ユーザが現在Ｓ−ＣＳＣＦに割り当てられていない場合は、Ｓ−ＣＳＣＦの割当はＩ−ＣＳＣＦによって実行されることに注意されたい。］次に、登録されたユーザがセッションリクエストをＩＭＳに送信する場合、Ｐ−ＣＳＣＦは、登録処理中にＳ−ＣＳＣＦから受信される情報に基づいて、選択されたＳ−ＣＳＣＦにそのリクエストを転送することが可能となる。
【００１０】
ＩＭＳサービスネットワークにおいて、アプリケーションサーバ（ＡＳ）群は、ＩＭＳサービスの機能を実現するために提供される。アプリケーションサーバは、ＩＭＳシステムにおけるエンドユーザにサービスを提供し、また、３ＧＰＰにより定義されているＭｒインタフェースを介するエンドポイントとして接続されていてもよく、あるいは３ＧＰＰにより定義されているＩＣＳインタフェースを介するＳ−ＣＳＣＦによって「リンクされて」いてもよい。後者の場合、ＳＩＰセッション確立中に、どのアプリケーションサーバに「リンクされる」べきかを判定するために、初期フィルタ基準（ＩＦＣ）がＳ−ＣＳＣＦによって使用される。異なる呼ごとに、異なるＩＦＣが適用されてもよい。ＩＭＳ登録手順の間に、ＩＦＣは、ＨＳＳからユーザのユーザプロファイルの一部として、Ｓ−ＣＳＣＦによって受信される。アプリケーションサーバのいくつかは、加入者アイデンティティに依存する動作を実行することになる（呼び出されている加入者なのか、または、呼び出しをしている加入者なのか、そうでなければ、アプリケーションサーバを制御するネットワークによって「所有」されている加入者なのか等）。例えば、転送呼の場合において、適切な（終了を行う）アプリケーションサーバは、加入者への呼が転送されることになる、新規の終了を行うパーティを判定することになる。ＩＦＣがＳ−ＣＳＣＦで受信されるＳＩＰメッセージが特定のＳＩＰ  ＡＳに転送されるべきであることを指している場合は、そのＡＳは、メッセージパスに付加される。一旦、ＳＩＰメッセージがＡＳによってＳ−ＣＳＣＦに返信されると、ＩＦＣで指示されている場合、それは最終的な宛先に向けて転送される、または、別のＡＳに転送される。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本出願人は、今までで説明される状況には、以下の問題があることを認識している。
【００１２】
ＩＭＳは広範囲に柔軟に展開できる新規のタイプのサービスを提供するための可能性を十分に備えるソリューションである。しかしながら、特に、複数種類のタイプのアプリケーションを管理するように設定される場合、この柔軟性はシステムの複雑さも増加させることになる。
【００１３】
また、限られた範囲で探索されるあるエリアでは、ノードが故障し、再起動される場合に発生し得る状況に対処するために要求される技術とソリューションが存在している。
【００１４】
基本的な問題は、例えば、サーバが再起動されると、クライアントが再度ログインする必要があること、または、クライアントが継続しているセッションを再作成する必要があることを、ＩＭＳクライアントに通知する一般的なソリューションが現在存在しないことである。
【００１５】
これは、サブスクリプション（加入）が長期間に存在し得り、かつ、システムにおいてそのような故障が、クライアントユニットが再加入を試行するまで感知されることない、プレゼンスのようなサービスに対して、特に、重要である。さらに、ネットワークにおけるパフォーマンスを向上させるために、有効期間を増加させることも要望されている。
【００１６】
上述した問題を対処することが望ましい。
【課題を解決するための手段】
【００１７】
本発明の第１の側面に従えば、ＩＰマルチメディアサブシステムを備えるユニバーサル移動通信システムネットワークにおいて使用するための方法が提供される。この方法は、第１のノードに関連付けられているイベントの発生を示すネットワークに属する第１のノードに関するノードのステータス情報を受信するステップと、イベントの発生によって不都合な影響を受ける、ネットワークに属する第１のノードと第２のノード間に確立されているネットワークアソシエーション（network association）の存在を判定するステップと、ネットワークアソシエーションが終了され、これにより、第１のノードと第２のノード間に新規のネットワークアソシエーションが確立されることを可能にするステップとを備えている。
【００１８】
この方法は、ネットワークアソシエーションが終了されるべきであることを示している第２のノードにメッセージを送信するステップを備えていてもよい。
【００１９】
この判定は、第２のノードによって少なくとも一部分がなされてもよい。
【００２０】
第１のノードに関する情報を有するメッセージを、第２のノードに送信するステップと、イベントの発生による影響を受ける第１のノードと第２のノード間におけるネットワークアソシエーションの存在を判定するために、第２のノードにおいて第１のノードの情報を使用するステップとを備えていてもよい。
【００２１】
このメッセージは、第２のノード、および、ネットワークの他のノードに送信されるＳＩＰメッセージリクエストのようなＳＩＰマルチキャストメッセージであってもよい。
【００２２】
第１のノードの情報は、第１のノードの接続情報を有していてもよい。
【００２３】
この方法は、判定を行うためにメッセージの接続ヘッダの少なくとも一部分を使用するステップを備えていてもよい。
【００２４】
第１のノードの情報は、第１のノードのＳＩＰリソース識別子であるＵＲＩ（ユニフォームリソースアイデンティファイア：Uniform Resource Identifier）を有してもよい。
【００２５】
この方法は、第１のノードと第２のノード間のネットワークアソシエーションの再確立のタイミングが、少なくとも一部分がランダムに判定されるステップを備え、これによって、イベント発生の観点から、ネットワークの他のノードに対するいくつかのネットワークアソシエーションが第１のノードと再確立される場合のシステムの負荷を軽減する。
【００２６】
この方法は、第２のノードにタイムウィンドウ（実行時間間隔）を送信し、そのタイムウィンドウ内に再確立を少なくとも開始するステップを備えていてもよい。
【００２７】
イベントは、ネットワークアソシエーションを維持するために必要とされる情報の少なくとも一部分の損失を生じさせるものであってもよい。
【００２８】
イベントは、第２のノードの少なくとも一部分の故障に関係していてもよい。
【００２９】
イベントは、第２のノードの少なくとも部分的な利用不可な状態に関係していてもよい。
【００３０】
イベントは、第２のノードの再起動に関係していてもよい。
【００３１】
ネットワークアソシエーションは、第１のノードと第２のノード間の通信セッションを有していてもよい。
【００３２】
メッセージは、ＳＩＰＢＹＥメッセージであってもよい。
【００３３】
ネットワークアソシエーションは、第１のノードと第２のノード間のサブスクリプションを有していてもよい。
【００３４】
メッセージは、最終的なＳＩＰ  ＮＯＴＩＦＹメッセージであってもよい。
【００３５】
ネットワークアソシエーションは、第１のノードと第２のノード間のセキュリティアソシエーションを有していてもよい。
【００３６】
ネットワークアソシエーションは、第１のノードと第２のノード間のＰＤＰ通信を有していてもよい。
【００３７】
この方法は、ルート情報を参照して判定を行うステップを備えていてもよい。
【００３８】
この方法は、この方法を実行しているノードにローカルに記憶されている情報に基づいて判定を行うステップを備えていてもよい。
【００３９】
第１のノードとして、アプリケーションサーバを有していてもよい。
【００４０】
第１のノードとして、サービング呼セッション制御機能を有していてもよい。
【００４１】
この方法は、プロキシ呼セッション制御機能において実行されてもよい。
【００４２】
第１のノードとして、プロキシ呼セッション制御機能を有していてもよい。
【００４３】
この方法は、ゲートウエイＧＰＲＳサポートノードにおいて実行されてもよい。
【００４４】
この方法は、第２のノードにおいて実行されてもよい。
【００４５】
ノードのステータス情報は、セッション開始プロトコル（ＳＩＰ）リクエストとして受信されてもよい。
【００４６】
ＳＩＰリクエストは、リクエストユニフォームリソース識別子、あるいはリクエストＵＲＩを有していても良く、これは、ノードのステータス情報を内包するＳＩＰリクエスト、および、ノードのステータス情報の意図される受信者のうちの少なくとも１つを同定する。
【００４７】
この方法は、受信したリクエストＵＲＩから、意図される受信者を判定するステップを備えていてもよい。
【００４８】
この方法は、判定された受信者にステータス情報を転送するステップを備えていてもよい。
【００４９】
この方法は、受信ノードが、意図される受信者の１つと判定される場合に、その受信ノードにおいてステータス情報を使用するステップを備えていてもよい。
【００５０】
この方法は、意図される受信者を判定するために、リクエストＵＲＩに関連付けられている初期フィルタ基準を参照するステップを備えていてもよい。
【００５１】
この方法は、リクエストＵＲＩから意図される受信者を判定するために、ダイナミックネームサーバを参照するステップを備えていてもよい。
【００５２】
この方法は、以前に受信されているＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエスト（ＳＩＰ加入リクエスト）に依存して、意図される受信者を判定するステップを備えていてもよい。
【００５３】
ＳＩＰリクエストは、ＳＩＰ  ＰＵＢＬＩＳＨリクエスト（ＳＩＰ発行リクエスト）であってもよい。
【００５４】
この方法は、ノードのステータスについての更なる情報を推定するために、ＳＩＰ  ＰＵＢＬＩＳＨリクエストからの有効時間情報を使用するステップを備えていてもよい。
【００５５】
ＳＩＰリクエストは、ＳＩＰ  ＭＥＳＳＡＧＥリクエスト（ＳＩＰメッセージリクエスト）であってもよい。
【００５６】
この方法は、ＳＩＰリクエストＵＲＩによって同定される、それらのノードに関するノードのステータスを記憶するステップを備えていてもよい。
【００５７】
本発明の第２の側面に従えば、ＩＰマルチメディアサブシステムを備えるユニバーサル移動通信システムネットワークにおいて使用するための装置が提供される。この装置は、第１のノードに関連付けられているイベントの発生を示すネットワークに属する第１のノードに関するノードのステータス情報を受信する手段と、イベントの発生によって不都合な影響を受けるネットワークに属する第１のノードと第２のノード間で確立されるネットワークアソシエーションの存在を判定する手段と、ネットワークアソシエーションが終了され、第１のノードと第２のノード間に新規のネットワークアソシエーションがその場で確立されることを可能にする手段を備えている。
【００５８】
本発明の第３の側面に従えば、本発明の第１の側面に従う方法を実行するための装置を制御するプログラムが提供される。そして、そのプログラムがその装置にロードされる場合、その装置を、本発明の第２の側面に従う装置として機能させる。このプログラムは、搬送媒体によって搬送される。搬送媒体は、記憶媒体であってもよい。搬送媒体は、通信媒体であってもよい。
【００５９】
本発明の第４の側面に従えば、本発明の第３の側面に従うプログラムによってプログラムされている装置が提供される。
【００６０】
本発明の第５の側面に従えば、本発明の第３の側面に従うプログラムを含む記憶媒体が提供される。
【図面の簡単な説明】
【００６１】
【図１】３Ｇ移動通信システムにおけるＩＰマルチメディアサブシステムを示す統合模式図である。
【図２】本発明の実施形態の概観を示すブロック図である。
【図３】本発明の第１の実施形態を示すブロック図である。
【図４】本発明の第１の実施形態を示すブロック図である。
【発明を実施するための形態】
【００６２】
本発明の実施形態は、ノードのステータス情報を配信するメカニズムと、いくつかのネットワークノード（例えば、Ｐ−ＣＦＣＳ）が、特定のノード（例えば、アプリケーションサーバ）とのセッションを保っているクライアントノード（例えば、ＵＥ）に関する情報を保持しているという事実を組み合わせている。このことにより、例えば、一時的な故障によりノードが利用不可能になっていることを検出する場合に、Ｐ−ＣＳＣＦは、クライアントとノード間のセッションをリセットすることが可能になる。
【００６３】
図２に示される例において、Ｐ−ＣＳＣＦノード、Ｓ−ＣＳＣＦノード、およびＡＳノードは、それぞれのノードからのステータス情報の配信に含まれている。規則的な間隔（または、特定の方法の使用によって判定される他の間隔）で、ノードは、ステータス情報を配信している。このステータス情報には、ノードの再起動などについての情報を含んでいてもよい。このことに関するさらなる情報、および、本発明の実施形態におけるノードのステータス情報を配信する最適なメカニズムは、本出願人が併せて出願しているＰＣＴ特許出願（出願人参照番号Ｐ５４３１９ＷＯ）の明細書に記載されている。
【００６４】
第１の実施形態は、図３と図４を参照して説明する。第１の実施形態は、アプリケーションサーバがいくつかの理由のために再起動の実行を余儀なくされている状況に関するものである。
【００６５】
例えば、再起動の結果として起こるアプリケーションサーバの故障の場合、多くのＵＥが依然としてＡＳに接続しているとことを想定すると、セッション／ダイアログは「ハングアップ」する可能性がある。しかしながら、ＡＳは再起動されているので、自身のセッションデータはすべて損失している。
【００６６】
ＵＥでハングアップしているセッションをリセットするために、ＡＳは、自身のステータス情報メッセージ中（図３のステップ１）に、再起動されていることを示すステータス情報を含んでいる。その情報は、Ｐ−ＣＳＣＦによって受信される。
【００６７】
Ｐ−ＣＳＣＦの通常の機能の一部分は、すべてのアクティブなセッション／ダイアログについての情報を保持することである。そのため、影響を受けているＡＳに対するすべてのセッション／ダイアログを検出するために、この情報を通して探索可能である。Ｐ−ＣＳＣＦは、ルート情報についての知識を有しており、確立されているすべてのセッション／ダイアログについてのルート情報をチェックすることによって、再起動／故障ノードによってどのＵＥが影響を受けているかを検出することが可能である。
【００６８】
Ｐ−ＣＳＣＦが、再起動されたＡＳとのセッションを一旦検出すると、影響を受けているセッションをリセットするために、ＵＥに対してＳＩＰメッセージを送信する（図３のステップ２）。さらに、Ｐ−ＣＳＣＦは、再起動しているＡＳが関与する、自身のダイアログに無効であることをマークし、必要であれば、メモリを開放するためにそれを消去する。
【００６９】
確立されているサブスクリプションを終了させるための最終的なＳＩＰ  ＮＯＴＩＦＹ（ＳＩＰ通知）、または、確立されているセッションを終了させるためのＳＩＰ  ＢＹＥ（ＳＩＰバイ）のような正式なＳＩＰの方法を、Ｐ−ＣＳＣＦに対して使用することは１つのオプションである。これは、図３に示されていることである。
【００７０】
代替としては、ＡＳノードが再起動しているという事実を、すべてのクライアントに通知するためにＳＩＰマルチキャストを使用することである。このことは、図４に示されている。再起動されているノードが、ダイアログ／セッションを確立しているクライアントに影響を与えるのかどうかをクライアントが判定できるようにするために、マルチキャストメッセージ（例えば、ＳＩＰ  ＭＥＳＳＡＧＥ（ＳＩＰメッセージ））は、再起動されているノードについての接続情報を含んでいる。Ｐ−ＣＳＣＦと対象のノード（接触情報に含まれている）間にプロキシノードが存在する場合、ルーティング情報は、端末によって通知されなくてはならないが、このことは通常の場合ではない。しかし、再起動しているノードが、セッション／ダイアログが確立されているアプリケーションサーバである場合、クライアントは、接続ヘッダによって知ることが可能である。
【００７１】
第１の実施形態では、本発明の実施形態に従うメカニズムがどのようにトリガされ得るかということを、アプリケーションサーバの再起動を例として説明している。しかしながら、本発明は、これに限定されるものではない。
【００７２】
第２の実施形態を説明する。第２の実施形態は、Ｓ−ＣＳＣＦがいくつかの理由のために、再起動の実行を余儀なくされている場合である。
【００７３】
例えば、再起動された結果起こるような、Ｓ−ＣＳＣＦの故障の場合において、これ以上は有効でないＵＥの登録がＵＥが数多く存在する可能性がある。
【００７４】
そのような状況において、Ｐ−ＣＳＣＦは、ＵＥに再度登録すべきことを通知する。
【００７５】
Ｐ−ＣＳＣＦは情報を集約している。Ｐ−ＣＳＣＦは、ダイアログの外側に１つまたはいくつかのＳＩＰリクエスト、例えば、ＭＥＳＳＡＧＥを送信する。マルチキャストメカニズムが使用されている場合、１つのリクエストが送信され得る。例えば、ＳＩＰリクエストは、故障しているＳ−ＣＳＣＦのＳＰＩ  ＵＲＩ（ユニフォームリソース識別子）、および、タイムウィンドウ（実行時間間隔）を含んでいる。ＵＥは、登録手順から、サービスルートヘッダからセッションの発信元であるＳ−ＣＳＣＦに関する情報を有している。そのため、ＵＥは、サービスルートからのＳ−ＣＳＣＦと、受信しているＳＩＰリクエストからのＳ−ＣＳＣＦの名前とを比較することができる。それらが一致する場、影響を受けているＵＥは、再度登録すべきである。このリクエストの結果として行われる登録のために生じるシステムに対する負荷を分散するために、ＵＥは、タイムウィンドウまで乱数値を使用すべきである。
【００７６】
また、Ｐ−ＣＳＣＦは、再起動しているＳ−ＣＳＣＦに関与する自身のダイアログに無効をマークし、必要であれば、メモリを開放するためにそれらを消去する。
【００７７】
第３の実施形態を説明する。第３の実施形態は、Ｐ−ＣＳＣＦがいくつかの理由のために再起動の実行を余儀なくされている状況に関するものである。
【００７８】
例えば、再起動の結果として起こるようなＰ−ＣＳＣＦの故障の場合において、これ以上は有効でないＵＥの登録が数多く存在する可能性があり、また、セキュリティアソシエーションが解消されている可能性がある。
【００７９】
ＧＧＳＮ（ゲートウエイＧＰＲＳサポートノード）が仮想インタフェースを有している場合、Ｐ−ＣＳＣＦが再起動していることは認識することは可能である。
【００８０】
ＧＧＳＮは影響を受けているすべてのＰＤＰ（パケットデータプロトコル）コンテキストを中止することができる。代替として、新規のマルチキャストまたはブロードキャストメッセージが、システムの負荷を削減するために定義され得る。この新規のメッセージは、システムに対して再度登録するために、影響を受けているすべてのＵＥに対して命令するべきである。
【００８１】
通常のレベルで、Ｐ−ＣＳＣＦではないＳＩＰダイアログを介する接続を有している他のＳＩＰノードについての情報をＳＩＰノードが受信する場合、ＵＥに通知することは必要ない。これは、Ｐ−ＣＳＣＦ（第１と第２の実施形態）、または、ＧＧＳＮ（第３の実施形態）がそれらを通知することを担当しているからであり、そして、再起動されているノードに関与しているＳＩＰダイアログに無効をマークし、必要ならばそれらを消去して、メモリを開放するために、ノードのステータス情報を使用することができる。ＳＩＰダイアログに関与しているすべてのＳＩＰノードがこのように動作する場合、ネットワークに属するＳＩＰノードのメモリの使用はより効果的になるだろう。
【００８２】
本発明の実施形態は、ネットワーク上で「ハングアップしている」ＳＩＰセッションをリセットするための方法を可能にしている。この方法では、システムの有用性だけでなく、システム全体の動作を改善し、また、ノードにおける一時的な故障の影響が削減されることになる。さらに、ネットワーク内の異なるアプリケーションサーバ上の耐性要件を削減することを可能にする。このことは、全体のコストを削減する。
【００８３】
上述の１つ以上の実施形態は、機器、または、装置を動作させるプログラムによって制御することができる。そのような動作プログラムは、コンピュータ可読媒体に記憶されてもよく、または、例えば、インターネットのウェブサイトから提供されるダウンロード可能なデータ信号のような信号によっても実施可能である。特許請求の範囲は、それ自身による動作プログラム、または、搬送波上のレコードとして、信号として、あるいは任意の他の形態を含むものと解釈されるべきである。
【００８４】
特許請求の範囲によって定義されている本発明の範囲から逸脱することなく、様々な変更が上述の実施形態に対してなされ得ることは、当業者にとって明らかであろう。特に、ＩＰマルチメディアサブシステムを有するユニバーサル移動通信システムに関連して説明してきているが、本発明は、他のタイプのネットワークにも適用可能であることは明らかであろう。
【図１】
2010525623.tif 000003
【図２】
2010525623.tif 000004
【図３】
2010525623.tif 000005
【図４】
2010525623.tif 000006
【手続補正書】
【提出日】平成21年10月16日(2009.10.16)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＩＰマルチメディアサブシステムを備えるユニバーサル移動通信システムのネットワークにおいて使用するための、前記ネットワークの第１のノードと前記ネットワークの第２のノードと通信する装置において実行される方法であって、
前記第１のノードに関連付けられているイベントの発生を示す、前記第１のノードに関するノードのステータス情報を受信するステップと、
前記イベントの前記発生による不都合な影響を受ける、前記第１のノードと前記第２のノード間に確立されているネットワークアソシエーションの存在を判定するステップと、
前記ネットワークアソシエーションが終了され、前記第１のノードと前記第２のノード間に新規のネットワークアソシエーションが確立されることを可能にするステップと
を備えることを特徴とする方法。
【請求項２】
前記ネットワークアソシエーションが終了されるべきであることを示すメッセージを、前記第２のノードに送信するステップを更に備える
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記判定は、前記第２のノードによって少なくとも一部分がなされる
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記第１のノードに関する情報を有するメッセージを、前記第２のノードに送信するステップと、
前記イベントの前記発生による影響を受ける前記第１のノードと前記第２のノード間におけるネットワークアソシエーションの前記存在を判定するために、前記第２のノードにおいて前記第１のノードの情報を使用するステップと
を備えることを特徴とする請求項３に記載の方法。
【請求項５】
前記メッセージは、前記第２のノード、および、前記ネットワークの他のノードに送信されるＳＩＰメッセージリクエストであるＳＩＰマルチキャストメッセージである
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記第１のノードの情報は、前記第１のノードの接続情報を有する
ことを特徴とする請求項４または５に記載の方法。
【請求項７】
前記判定を行うために、前記メッセージの接続ヘッダの少なくとも一部分を使用するステップを備える
ことを特徴とする請求項４、５、または６に記載の方法。
【請求項８】
前記第１のノードの情報は、前記第１のノードのＳＩＰユニフォームリソース識別子を有する
ことを特徴とする請求項４乃至７のいずれか１項に記載の方法。
【請求項９】
前記第１のノードと第２のノード間にある前記ネットワークアソシエーションの前記再確立のタイミングが、少なくとも一部分がランダムで判定されることで、前記イベント発生の観点から、前記ネットワークの他のノードに関するいくつかのネットワークアソシエーションが前記第１のノードと再確立される場合のシステム負荷を緩和させるステップと
を備えることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
タイムウィンドウを前記第２のノードに送信し、前記タイムウィンドウ内に前記再確立を少なくとも開始するステップを備える
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記イベントは、前記ネットワークアソシエーションを維持するために必要とされる情報の少なくとも一部分の損失を生じさせるものである
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記イベントは、前記第２のノードの少なくとも一部分の故障に関係している
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記イベントは、前記第２のノードの少なくとも一部分の利用不可な状態に関係している
ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記イベントは、前記第２のノードの再起動に関係している
ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記ネットワークアソシエーションは、前記第１のノードと前記第２のノード間の通信セッションを有する
ことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
請求項２に従属する場合に、前記メッセージは、ＳＩＰ  ＢＹＥメッセージである
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ネットワークアソシエーションは、前記第１のノードと前記第２のノード間のサブスクリプションを有する
ことを特徴とする請求項１乃至１６のいずれか１項に記載の方法。
【請求項１８】
請求項２に従属する場合、前記メッセージは、最終的なＳＩＰ  ＮＯＴＩＦＹメッセージである
ことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記ネットワークアソシエーションは、前記第１のノードと前記第２のノード間のセキュリティアソシエーションを有する
ことを特徴とする請求項１乃至１８のいずれか１項に記載の方法。
【請求項２０】
前記ネットワークアソシエーションは、前記第１のノードと前記第２のノード間のＰＤＰコンテキストを有する
ことを特徴とする請求項１乃至１９のいずれか１項に記載の方法。
【請求項２１】
ルート情報を参照して、前記判定を行う
ことを特徴とする請求項１乃至２０のいずれか１項に記載の方法。
【請求項２２】
当該方法を実行している前記ノードに記憶されている前記情報に基づいて、前記判定を行う
ことを特徴とする請求項１乃至２１のいずれか１項に記載の方法。
【請求項２３】
前記第１のノードは、アプリケーションサーバである
ことを特徴とする請求項１乃至２２のいずれか１項に記載の方法。
【請求項２４】
前記第１のノードは、サービング呼セッション制御機能である
ことを特徴とする請求項１乃至２３のいずれか１項に記載の方法。
【請求項２５】
当該方法は、プロキシ呼セッション制御機能において実行される
ことを特徴とする請求項１乃至２４のいずれか１項に記載の方法。
【請求項２６】
前記第１のノードは、プロキシ呼セッション制御機能である
ことを特徴とする請求項１乃至２４のいずれか１項に記載の方法。
【請求項２７】
当該方法は、ゲートウエイＧＰＲＳサポートノードにおいて実行される
ことを特徴とする請求項２６に記載の方法。
【請求項２８】
当該方法は、前記第２のノードにおいて実行される
ことを特徴とする請求項１乃至２７のいずれか１項に記載の方法。
【請求項２９】
前記ノードのステータス情報は、セッション開始プロトコルリクエストで受信される
ことを特徴とする請求項１乃至２８のいずれか１項に記載の方法。
【請求項３０】
前記セッション開始プロトコルリクエストは、リクエストユニフォームリソース識別子であり、
前記リクエストユニフォームリソース識別子は、前記ノードのステータス情報を内包する前記ＳＩＰリクエスト、および、前記ノードのステータス情報の意図される受信者のうちの少なくとも１つを同定する
ことを特徴とする請求項２９に記載の方法。
【請求項３１】
前記受信したリクエストユニフォームリソース識別子から前記意図される受信者を判定するステップを備える
ことを特徴とする請求項３０に記載の方法。
【請求項３２】
前記判定された受信者に、前記ステータス情報を転送するステップを備える
ことを特徴とする請求項３１に記載の方法。
【請求項３３】
受信ノードが、前記意図される受信者の１つと判定される場合、前記受信ノードにおいて前記ステータス情報を使用するステップを備える
ことを特徴とする請求項３１または３２に記載の方法。
【請求項３４】
前記意図される受信者を判定するために、前記リクエストユニフォームリソース識別子に関連付けられている初期フィルタ基準を参照するステップを備える
ことを特徴とする請求項３１、３２、または３３に記載の方法。
【請求項３５】
前記リクエストユニフォームリソース識別子から前記意図される受信者を判定するために、ダイナミックネームサーバを参照するステップを備える
ことを特徴とする請求項３１、３２、または３３に記載の方法。
【請求項３６】
以前に受信されたＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストに依存して、前記意図される受信者を判定するステップを備える
ことを特徴とする請求項３１、３２、または３３に記載の方法。
【請求項３７】
前記セッション開始プロトコルリクエストは、ＳＩＰ  ＰＵＢＬＩＳＨリクエストである
ことを特徴とする請求項２９乃至３６のいずれか１項に記載の方法。
【請求項３８】
前記ノードのステータスについてのさらなる情報を推定するために、前記ＳＩＰ  ＰＵＢＬＩＳＨリクエストからの有効時間情報を使用するステップを備える
ことを特徴とする請求項３７に記載の方法。
【請求項３９】
前記セッション開始プロトコルリクエストは、ＳＩＰ  ＭＥＳＳＡＧＥリクエストである
ことを特徴とする請求項２９乃至３６のいずれか１項に記載の方法。
【請求項４０】
前記セッション開始プロトコルリクエストユニフォームリソース識別子によって同定されるそれらのノードに関する前記ノードのステータスを記憶するステップを備える
ことを特徴とする請求項２９乃至３９のいずれか１項に記載の方法。
【請求項４１】
ＩＰマルチメディアサブシステムを備えるユニバーサル移動通信システムのネットワークにおいて使用するための装置であって、
第１のノードに関連付けられているイベントの発生を示す、前記ネットワークの前記第１のノードに関するノードのステータス情報を受信する手段と、
前記イベントの発生によって不都合な影響を受ける前記ネットワークの前記第１のノードと第２のノード間で確立されるネットワークアソシエーションの存在を判定する手段と、
前記ネットワークアソシエーションが終了され、前記第１のノードと前記第２のノード間の新規のネットワークアソシエーションをその場で確立されることを可能にする手段と
を備えることを特徴とする装置。
【請求項４２】
請求項１乃至４０のいずれか１項に記載されている方法を実行するための装置を制御するためのプログラム。
【請求項４３】
装置にロードされる場合に、前記装置を請求項４１で記載されている装置として機能させることを特徴とするプログラム。
【請求項４４】
搬送媒体によって搬送されることを特徴とする請求項４２、または４３に記載のプログラム。
【請求項４５】
前記搬送媒体は、記憶媒体であることを特徴とする請求項４４に記載のプログラム。
【請求項４６】
前記搬送媒体は、通信媒体であることを特徴とする請求項４４に記載のプログラム。
【請求項４７】
請求項４２乃至４６のいずれか１項に記載のプログラムによってプログラムされている装置。
【請求項４８】
請求項４２乃至４５のいずれか１項に記載のプログラムを含んでいる記憶媒体。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】変更
【補正の内容】
【００１７】
本発明の第１の側面に従えば、ＩＰマルチメディアサブシステムを備えるユニバーサル移動通信システムネットワークにおいて使用するための方法が提供される。この方法は、前記ネットワークの第１のノードと前記ネットワークの第２のノードと通信する装置において実行される。この方法は、第１のノードに関連付けられているイベントの発生を示す第１のノードに関するノードのステータス情報を受信するステップと、イベントの発生によって不都合な影響を受ける第１のノードと第２のノード間に確立されているネットワークアソシエーション（network association）の存在を判定するステップと、ネットワークアソシエーションが終了され、これにより、第１のノードと第２のノード間に新規のネットワークアソシエーションが確立されることを可能にするステップとを備えている。
【国際調査報告】
2010525623.tif 000007
2010525623.tif 000008