ＩＰマルチメディア・サブシステム・ネットワークにおける障害復旧
ＩＰマルチメディア・サブシステム・ネットワーク内のＰ−ＣＳＣＦ（１３）の障害からの復旧を促進する方法が提供される。ＧＧＳＮのようなゲートウェイ（１１）が、Ｐ−ＣＳＣＦからゲートウェイに到着する信号を監視し、例えば信号の中断が原因で監視対象の信号が受信不可能になった場合に指示情報を提供する。ゲートウェイ（１１）は、ＩＭＳネットワークに対する以前の登録の間にＰ−ＣＳＣＦに関連付けられたユーザ装置（１０）に対してＰ−ＣＳＣＦ（１３）が利用不可能であるということをシグナリングすることにより、応答する。これに応えて、例えば、障害の影響を受けるユーザは、別の利用可能なＰ−ＣＳＣＦを使用してＩＭＳネットワークに再登録することを要求することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰマルチメディア・サブシステム・ネットワークにおける障害復旧に関し、特に、プロキシ呼セッション制御機能の障害からの復旧を可能にする方法及び装置に関する。
【背景技術】
【０００２】
ＩＰマルチメディア・サービスは、音声、ビデオ、メッセージング、データなどの動的な組み合わせを同一のセッション中で提供する。組み合わせ可能な基本アプリケーション及びメディアの数が増加することにより、エンドユーザに提供されるサービスの数が増加し、個人間の通信エクスペリエンスが豊かになるであろう。このことは、所謂「組み合わせＩＰマルチメディア」サービスを含んだ、パーソナライズされた豊かなマルチメディア通信サービスの新しい世代を導くものとなろう。
【０００３】
ＵＭＴＳ（ユニバーサル・モバイル・テレコミュニケーションズ・システム）は、第３世代の無線システムであり、加入者に対してより高いデータレート及び高度なサービスを提供するように設計されている。ＵＭＴＳは、グローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ）の後継であり、ＧＳＭとＵＭＴＳとの間の重要な進化段階には、汎用パケット無線サービス（ＧＰＲＳ）が存在する。ＧＰＲＳは、ＧＳＭコアネットワークにパケット交換を導入し、パケットデータネットワーク（ＰＤＮ）に対する直接アクセスを可能にする。このことは、ＧＳＭ呼ネットワークを介したＩＳＤＮの６４ｋｂｐｓの限界をはるかに超える高いデータレートでのパケット交換伝送を可能にし、これは、２Ｍｂｐｓにも及ぶＵＭＴＳデータ伝送レートのために不可欠なことである。ＵＭＴＳは、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって標準化された。３ＧＰＰは、欧州電気通信標準化協会（ＥＴＳＩ）や電波産業界（ＡＲＩＢ）などの地域標準化機構の集合体である。更なる詳細については、３ＧＰＰ ＴＳ ２３．００２を参照のこと。
【０００４】
ＵＭＴＳのアーキテクチャは、ＩＰマルチメディア・サブシステム（ＩＭＳ）として知られる、従来の電話技術に加えて新しいＩＰマルチメディア・サービスをサポートするためのサブシステムを含む（３ＧＰＰ ＴＳ ２２．２２８， ＴＳ ２３．２２８， ＴＳ ２４．２２９， ＴＳ ２９．２２８， ＴＳ ２９．２２９， ＴＳ ２９．３２８ 及び ＴＳ ２９．３２９ リリース５乃至７）。ＩＭＳは、標準化されたＩＭＳサービスイネーブラの使用を通じて、エンドユーザの個人対個人の通信エクスペリエンスを豊かにする重要な特徴を提供する。ＩＭＳサービスイネーブラは、ＩＰベースのネットワークを介した個人対コンテンツ（クライアント対サーバ）のサービスに加えて、新しい豊かな個人対個人（クライアント対クライアント）の通信サービスを促進するものである。ＩＭＳは、ＰＳＴＮ／ＩＳＤＮ（公衆交換電話網／サービス総合デジタル網）に対しても、インターネットに対しても、共に接続可能である。
【０００５】
ＩＭＳは、ユーザ端末間（又はユーザ端末とアプリケーション端末との間）で呼又はセッションをセットアップして制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）は、セッションのメディアコンポーネントを記述して交渉するために使用される。ＳＩＰはユーザ対ユーザのプロトコルとして創造されたが、ＩＭＳによれば、オペレータ及びサービスプロバイダが、サービスに対するユーザアクセスを制御してそれに応じてユーザに課金することが可能である。３ＧＰＰは、ＩＭＳ内のコンポーネント間に加えて、ユーザ装置（ＵＥ）とＩＭＳとの間のシグナリングのためにもＳＩＰを選択した。
【０００６】
ＵＭＴＳ通信ネットワークの動作、及びそのようなネットワーク内の多様なコンポーネントに関する具体的な詳細については、http://www.3gpp.orgから入手可能なＵＭＴＳの技術仕様から発見可能である。ＵＭＴＳ内でのＳＩＰの使用に関する更なる詳細については、３ＧＰＰ技術仕様ＴＳ ２４．２２９から発見可能である。
【０００７】
添付図面の図１は、ＧＰＲＳ／ＰＳアクセスネットワークの場合にＩＭＳが移動体ネットワークアーキテクチャにどのように適合するかを概略的に示す（ＩＭＳはもちろん、他のアクセスネットワークを介して動作することもできる）。呼セッション制御機能（ＣＳＣＦ）は、ＩＭＳ内でＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、３種類のＣＳＣＦを規定する。即ち、ＳＩＰ端末にとってＩＭＳ内での最初のコンタクトポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、ユーザが加入しているサービスをユーザに対して提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、及び、正しいＳ−ＣＳＣＦを特定し、Ｐ−ＣＳＣＦを介してＳＩＰ端末から受信したＳＩＰリクエストをそのＳ−ＣＳＣＦへ転送するインテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）である。
【０００８】
ユーザは、規定されたＳＩＰ ＲＥＧＩＳＴＥＲメソッドを使用してＩＭＳに登録する。これは、ＩＭＳにアタッチし、ＳＩＰユーザＩＤに到達可能なＩＭＳアドレスをアナウンスするための、メカニズムである。３ＧＰＰでは、ＳＩＰ端末が登録を行う際に、ＩＭＳはユーザを認証し、利用可能なＳ−ＣＳＣＦのセットからＳ−ＣＳＣＦをそのユーザに割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰによって規定されていないが、これらの基準には、負荷分散及びサービス要件が含まれ得る。なお、Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースのサービスに対するユーザアクセスを制御する（そして課金する）ことの要である。オペレータは、さもなければＳ−ＣＳＣＦをバイパスしてしまうような、ユーザ対ユーザの直接のＳＩＰセッションを阻止するためのメカニズムを提供することができる。
【０００９】
登録プロセスの間、Ｓ−ＣＳＣＦがまだ選択されていない場合にＳ−ＣＳＣＦを選択することが、Ｉ−ＣＳＣＦの責務である。Ｉ−ＣＳＣＦは、必要とされるＳ−ＣＳＣＦの能力をホームネットワークのホーム加入者サーバ（ＨＳＳ）から受信し、受信した能力に基づいて適切なＳ−ＣＳＣＦを選択する。ＳＩＰ ＲＥＧＩＳＴＥＲメッセージは、選択されたＳ−ＣＳＣＦへ転送され、Ｓ−ＣＳＣＦは自分のＩＤをＳＩＰ Ｓｅｒｖｉｃｅ Ｒｏｕｔｅヘッダに追加する。Ｐ−ＣＳＣＦがＳ−ＣＳＣＦから２００ ＯＫを受信すると、Ｐ−ＣＳＣＦはＳｅｒｖｉｃｅ ＲｏｕｔｅヘッダからＳＩＰ ＩＤを知る。なお、ユーザのためのＳ−ＣＳＣＦの割り当ては、そのユーザが他の当事者から呼び出されそのユーザにＳ−ＣＳＣＦが正しく割り当てられていない場合にも、Ｉ−ＣＳＣＦによって行われる。これを、「着信」呼の事例と呼ぶ。
【００１０】
ＩＭＳサービスネットワークの中で、ＩＭＳサービス機能を実装するためにアプリケーションサーバ（ＡＳ）が提供される。アプリケーションサーバは、ＩＭＳシステム内のエンドユーザにサービスを提供する。アプリケーションサーバには、３ＧＰＰによって規定されるＭｒインタフェースを介してエンドポイントとしても接続可能であるし、３ＧＰＰによって規定されるＩＳＣインタフェースを介してＳ−ＣＳＣＦによって「リンクする」ことも可能である。後者の場合、ＳＩＰセッション確立の間にどのアプリケーションサーバに「リンクする」べきであるかを判断するために、Ｓ−ＣＳＣＦによって初期フィルタ基準（ＩＦＣ）が使用される。様々な呼の事例に対して様々なＩＦＣを適用可能である。ＩＦＣは、Ｓ−ＣＳＣＦによって、ＩＭＳ登録手順の間にユーザのユーザプロファイルの一部としてＨＳＳから受信される。アプリケーションサーバによっては、加入者ＩＤ（アプリケーションサーバを制御するネットワークによって「所有」されている限りは発呼側加入者であっても着呼側加入者であってもよい）に応じた動作を実行するものもある。例えば、呼の転送の場合、適切な（着信）アプリケーションサーバは、所与の加入者に対する呼の転送先となる新たな着信側当事者を判断する。Ｓ−ＣＳＣＦによって受信されたＳＩＰメッセージが特定のＳＩＰ ＡＳへ転送されるべきであるとＩＦＣが示す場合、そのＡＳがメッセージパスに追加される。ＳＩＰメッセージがＡＳによってＳ−ＣＳＣＦへ返されると、ＳＩＰメッセージは、最終的な宛先へ向かって転送されるか、又は、ＩＦＣの中で指定されている場合は別のＡＳへと転送される。
【００１１】
現行のＩＭＳコアの仕様は、ネットワークエレメントにおける障害の後で整合状態に復旧するための手順を含んでいない。
【００１２】
ＩＭＳ登録時にユーザ装置がコンタクトするＰ−ＣＳＣＦは、ＩＭＳに登録している期間内にＳＩＰシグナリングパスに留まるために、自分自身のＳＩＰ ＵＲＩをＳＩＰパスヘッダに挿入する。
【００１３】
ユーザが着信側としてコンタクトされる場合（例えば、音声呼のＢパーティーとして）、ＩＭＳは、登録時に挿入されたＰ−ＣＳＣＦのＳＩＰ ＵＲＩを使用して端末にコンタクト可能であることを要求する。通信に障害が存在する場合、ＩＭＳが更なる試みを断念するまでの遅延は、数分かそこらの問題かもしれない。その期間の後、ＳＩＰタイムアウトエラーがＡパーティーに返される。到達不可能なＰ−ＣＳＣＦによって管理される全てのユーザへ宛てられた全ての着信ＳＩＰリクエストは、それらのユーザが新しい登録を開始するまで失敗するであろう。このシナリオは、３ＧＰＰ ＴＲ ２３．８２０ ５．３．３節に記述されている。
【００１４】
既存のソリューションでは、Ｐ−ＣＳＣＦの障害は、ユーザがＩＭＳコアネットワークに接続されているという認識を持っていながら到達不可能である期間を意味する。この期間は、ユーザ端末からＳＩＰリクエストが開始されるまで継続することになり、再登録期間と同じ長さになる場合もある。現行では、ＩＭＳにおける再登録タイマーは３０分から数時間の範囲に亘る。これは、Ｐ−ＣＳＣＦの障害がいかに稀であるかを考慮に入れたとしても、ユーザによってはこの状態であり続けるには長すぎる時間であろう。
【００１５】
「心臓の鼓動」シグナリング、又は、ユーザ装置によって実行され、且つ、ＩＭＳコアとの接続（そしてそれ故に登録）が失われているということをユーザ装置に対して示すように規定されるその他の監視は、この問題を解決するかもしれない。特に、このことは、Ｐ−ＣＳＣＦに障害が発生している時や再起動した時という場合に当てはまる。しかしながら、そのようなシグナリングは、移動体ユーザ装置のバッテリーをすぐに使い果たしてしまうであろうし、許容不可能な量の無線リソースを消費するであろう。
【発明の概要】
【課題を解決するための手段】
【００１６】
本発明の第１の態様によれば、ＩＰマルチメディア・サブシステム・ネットワーク内のプロキシ呼セッション制御機能の障害からの復旧を促進する方法であって、
ゲートウェイにおいて、前記プロキシ呼セッション制御機能から前記ゲートウェイに到着する信号を監視するステップと、
前記ゲートウェイにおいて、前記監視対象の信号が受信不可能になった場合に指示情報を提供するステップと、
前記ゲートウェイにおいて、前記指示情報に応えて、前記プロキシ呼セッション制御機能に関連付けられている１つの又は各々のユーザ装置に対して前記プロキシ呼セッション制御機能が利用不可能であるということを信号通知する動作を実行するステップと、
を備えることを特徴とする方法が提供される。
【００１７】
前記提供するステップは、到達不可能であるという明示的な指示情報を伝送ネットワークから受信した後に前記指示情報を提供してもよい。前記提供するステップは、前記監視対象の信号における、送信ノードの利用不可能性又は到着不可能性の特徴である変化の後に、前記指示情報を提供してもよい。
【００１８】
前記提供するステップは、前記監視対象の信号の中断に応えて、前記指示情報を提供してもよい。前記提供するステップは、前記監視対象の信号の受信から所定の遅延の後に、前記指示情報を提供してもよい。前記所定の遅延は、前記１つの又は各々のユーザ装置から前記ゲートウェイを介して前記プロキシ呼セッション制御機能に向けられた信号トラヒックレベルの関数であってもよい。
【００１９】
前記所定の遅延は、前記プロキシ呼セッション制御機能に関連付けられたユーザ装置インスタンスの数の関数であってもよい。前記所定の遅延は、リアルタイムで実行されるシグナリングトラヒック測定値、及び／又は、事前のシグナリングトラヒック測定値の関数であってもよい。前記所定の遅延は、これらの関数のいかなる組み合わせであってもよい。
【００２０】
前記監視するステップは、前記プロキシ呼セッション制御機能が前記ゲートウェイに対して応答を送信することを要求する信号を、前記プロキシ呼セッション制御機能へ送信するステップを含んでもよく、前記提供するステップは、前記ゲートウェイにおいて所定数の応答を受信できなかったことに応えて、前記指示情報を提供してもよい。前記ゲートウェイと前記プロキシ呼セッション制御機能との間の信号トラヒックが所定レベルより低い場合に前記応答を要求する信号が送信されてもよい。
【００２１】
前記ゲートウェイは、汎用パケット無線サービスのためのゲートウェイ・サポート・ノードであってもよい。前記動作を実行するステップは、セッション管理シグナリングを用いて前記動作を実行するステップを含んでもよい。前記動作は、
前記１つの又は各々のユーザ装置に対するシグナリングＩＰフローに対応するトラヒックフローテンプレートを除去することと、
前記１つの又は各々のユーザ装置に対するシグナリングＩＰフローを搬送するＰＤＰコンテキストを削除することと、
ＧＰＲＳセッション管理において通知を送信することと、
宛先ＩＰアドレスに到達不可能であることを示すＩＣＭＰメッセージを送信することと、
前記１つの又は各々のユーザ装置に対してどのプロキシ呼セッション制御機能が利用可能であるかを通知することと、
のうちのいずれか１つを含んでもよい。
【００２２】
前記１つの又は各々のユーザ装置は、前記ユーザ装置を別のプロキシ呼セッション制御機能に関連付けることを含む前記ＩＰマルチメディア・サブシステムへの再登録を実行することにより、前記動作に対して応答してもよい。
【００２３】
前記監視するステップは、前記ゲートウェイにおいて、アドレスが前記ゲートウェイに格納されている各々のプロキシ呼セッション制御機能から前記ゲートウェイに到着する信号を監視するステップを含んでもよい。
【００２４】
本発明の第２の態様によれば、ＩＰマルチメディア・サブシステム・ネットワーク内でゲートウェイとして動作するように構成される装置であって、
プロキシ呼セッション制御機能から到着する信号を受信する入力部と、
前記プロキシ呼セッション制御機能から受信した前記信号を監視する手段と、
前記監視対象の信号が受信不可能になった場合に指示情報を提供する手段と、
前記指示情報に応えて、前記ＩＰマルチメディア・サブシステム・ネットワークに対する以前の登録の間に前記プロキシ呼セッション制御機能に関連付けられた１つの又は各々のユーザ装置に対して前記プロキシ呼セッション制御機能が利用不可能であるということを信号通知する動作を実行する手段と、
を備えることを特徴とする装置が提供される。
【図面の簡単な説明】
【００２５】
【図１】上で説明したものであり、ＩＰマルチメディア・サブシステムの３Ｇ移動体通信システムへの統合を概略的に示す。
【図２】本発明の実施形態を構成し本発明の実施形態を構成する方法を実行するＧＧＳＮに関連する構造及びシグナリングを示す。
【図３】図２に類似するものであり、Ｐ−ＣＳＣＦの利用可能性を監視する第１の技術を示す。
【図４】図２に類似するものであり、Ｐ−ＣＳＣＦの利用可能性を監視する別の技術を示す。
【図５】Ｐ−ＣＳＣＦの障害からの復旧に関係するＩＭＳシグナリングを示す。
【発明を実施するための形態】
【００２６】
図２は、図１に示すシステムの一部を示し、ユーザ装置１０に接続されている。ネットワークは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１１を含む。ＧＧＳＮ１１は、各々がパケットデータプロトコル（ＰＤＰ）コンテキスト１２を用いて複数のユーザ装置１０に関連付けられている複数のゲートウェイのうちの１つである。
【００２７】
図２は、ユーザ装置１０がプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）１３に登録している状態を示す。ユーザ装置１０は、セッション開始プロトコル（ＳＩＰ）シグナリングのインターネットプロトコル（ＩＰ）フロー１４を含んだ手段を用いて、ＧＧＳＮ１１を介してＰ−ＣＳＣＦ１３と通信する。
【００２８】
ＧＧＳＮ１１は、Ｐ−ＣＳＣＦ１３の利用可能性を監視する新機能１５を含む。新機能１５は、フロー１４のようなＰ−ＣＳＣＦ１３からＧＧＳＮ１１への信号が受信不可能になった場合に、指示情報を提供する。機能１５は、図３を参照して後述するような、Ｐ−ＣＳＣＦ１３からのトラヒックの統計的監視を実行可能である。或いは、又はこれに加えて、機能１５は、「心臓の鼓動メカニズム」１６を使用して、機能１５によって生成されＰ−ＣＳＣＦ１３へ送信されＰ−ＣＳＣＦからの応答を要求する信号に対するＰ−ＣＳＣＦ１３の応答を監視することができる。そのような心臓の鼓動メカニズムは、図４を参照して後述する。
【００２９】
大まかに言えば、機能１５は、Ｐ−ＣＳＣＦ１３からの信号フローを監視し、信号フローにおける送信者の利用不可能性の特徴である変化（例えば、監視対象信号の中断など）に応えて、受信不可能に関する指示情報を提供する。次に機能１５は、Ｐ−ＣＳＣＦ１３の利用不可能性を信号通知するために、適切な動作を行う（例えば、１つ又は各々のユーザ装置１０に、現在のところ利用可能であると知られている又は信じられている別のＰ−ＣＳＣＦに対する再登録を開始させる）。
【００３０】
ＧＧＳＮ１１と各Ｐ−ＣＳＣＦとの間には固定的な接続が存在しないので、機能１５は、どのＰ−ＣＳＣＦ（例えば、１３）を監視すべきかを知る必要がある。ＧＧＳＮ１１に接続されているユーザ装置に現時点で関連付けられている各Ｐ−ＣＳＣＦのアドレスがＧＧＳＮ１１に格納されるシステムのような例では、機能１５は、ＧＧＳＮ１１に現時点で格納されている各Ｐ−ＣＳＣＦのアドレスを監視すればよい。或いは、又はこれに加えて、機能１５は、シグナリングのために使用されるものとしてマークされたＩＰアドレスの宛先アドレスを検査してもよい。そのようなマーク付けは、３ＧＰＰ ＴＳ ２４．００８に示されているように、ＧＰＲＳセッション管理シグナリングにおいてユーザ装置によって実行可能である。そのようなマーク付けは、Ｇｘを介してＰＣＲＦによっても実行可能であるが、これは新しいメカニズムである。
【００３１】
前述の通り、図３は、Ｐ−ＣＳＣＦ１３の利用可能性を判断する統計的監視技術を示す。この技術は、次の事実に基づいている。その事実とは、ＧＧＳＮ１１は一般的に、多数のユーザ装置１０ａ、１０ｂ、１０ｃのＰ−ＣＳＣＦに対するシグナリングを扱うということである。従って、統計的には、ＧＧＳＮを介したＣＳＣＦへの、そしてＣＳＣＦからの、ほとんど連続的なＩＰパケットのフローが存在するであろう。機能１５はそれゆえ、Ｐ−ＣＳＣＦ１３のアドレスに到達不可能であることを示すＩＣＭＰを受信した場合、又は、Ｐ−ＣＳＣＦに関連付けられた全てのユーザ装置に対するＰ−ＣＳＣＦからのパケットのフローが許容不可能な期間中断した場合に、Ｐ−ＣＳＣＦ１３に障害が発生したと判断することができる。この期間は、いかなる適切な方法によっても決定可能なものであり、例えば、Ｐ−ＣＳＣＦ１３とのシグナリングを行っているユーザ装置１０ａ、１０ｂ、１０ｃの数に対応する、ＧＧＳＮ１１がＰ−ＣＳＣＦ１３のために扱っているシグナリングＩＰフローの数に従って動的に調整されてもよい。この期間は、Ｐ−ＣＳＣＦからの、及び／又は、Ｐ−ＣＳＣＦへの、シグナリングＩＰパケットフローの測定値に従って動的に調整されてもよい。この期間は、ＧＧＳＮにとってのシグナリングトラヒックの予測を反映するように事前設定されてもよい。この期間は、これらの方法のうち任意のものの組み合わせを用いて決定されてもよい。この期間は、Ｐ−ＣＳＣＦの利用不可能性を発見するための要求される最大遅延にも基づく。
【００３２】
機能１５は一般的に、ＧＧＳＮ１１に接続されたユーザ装置のいずれかに影響を与える障害に関する早期の信頼できるシグナリングを提供するように、複数のＰ−ＣＳＣＦの利用可能性を同時に監視することができる。この機能は、上述した統計的監視、及び／又は後述する心臓の鼓動メカニズムを実行するために、各Ｐ−ＣＳＣＦに関係するシグナリングフローを個別に監視する。
【００３３】
心臓の鼓動メカニズムを図４に示す。機能１５は、ＩＰパケット又は「ｐｉｎｇ」を１つの（又は各）Ｐ−ＣＳＣＦ１３に対して定期的に送信する。ＩＰパケットは、Ｐ−ＣＳＣＦ１３からＧＧＳＮ１１へ戻る応答を要求するように構成される。それゆえ、Ｐ−ＣＳＣＦ１３が利用可能で正しく機能している場合は、Ｐ−ＣＳＣＦ１３は、ＧＧＳＮ１１へと返送する応答ＩＰパケット又は「ｐｏｎｇ」により、ｐｉｎｇに対して応答する。機能１５は、各ｐｉｎｇの結果として帰ってくるｐｏｎｇを待ち受ける。Ｐ−ＣＳＣＦからのｐｏｎｇの形式である１以上の応答が欠落しているということは、Ｐ−ＣＳＣＦの障害として判断される。
【００３４】
心臓の鼓動メカニズムは、ＩＰフローをシグナリングするユーザ装置の数とは無関係に使用可能であるので、Ｐ−ＣＳＣＦの利用可能性を監視するより汎用的な技術を提供する。心臓の鼓動メカニズムは、ＧＧＳＮ１１及びＰ−ＣＳＣＦ１３に対して追加の信号負荷をもたらすが、一方で統計的監視は、既存の信号フローを利用するので、負荷を変化させない。しかしながら、統計的監視は、信頼に足るように実行するためには、最低限のまとまったシグナリングトラヒックを必要とする。
【００３５】
いずれの技術も単独で実行可能であるが、両方の技術を同時に実行することもできるし、或いは、シグナリングトラヒックが十分な場合は統計的監視が使用される一方でシグナリングトラヒックが不十分な場合は心臓の鼓動メカニズムが使用されるようなやり方で両方の技術を組み合わせることもできる。機能１５は、例えばシグナリングトラヒックに従って、いつでもこれらの技術の間で切り替わることができる。
【００３６】
Ｐ−ＣＳＣＦ１３の障害（又は他の利用不可能性）からの復旧を促進するために、ＧＧＳＮ１１は、多様な対策のうちの任意のもの又は任意の組み合わせを実行可能である。一般的には、これらの対策は、障害が発生したか又は利用不可能なＰ−ＣＳＣＦに以前に登録されていた１つの又は各ユーザ装置に対して通知を行うために使用される。するとユーザ装置は、現時点で利用可能な別のＰ−ＣＳＣＦに登録することができる。
【００３７】
ＧＧＳＮ１１は、例えば３ＧＰＰ ＴＳ ２４．００８に規定される既存の手順に従って、ユーザ装置に対するＰＤＰコンテキスト変更手順を使用してシグナリングＩＰフローを除去することにより、ユーザ装置１０に対する通知を行うことができる。ＧＧＳＮ１１は、やはり３ＧＰＰ ＴＳ ２４．００８に規定されているＰＤＰコンテキスト非アクティブ化手順を使用して、シグナリングフローを搬送するＰＤＰコンテキスト１２を削除することができる。ＧＧＳＮ１１は、現在のところ３ＧＰＰ ＴＳ ２４．００８に規定されていないＧＰＲＳセッション管理シグナリングの中で、シグナリングＩＰフローの宛先（Ｐ−ＣＳＣＦ１３）に障害が発生しているという新しい明示的な通知を送信することができる。ＧＧＳＮは、ＩＥＴＦ ＲＦＣ７２２に従い、（Ｐ−ＣＳＣＦの）宛先ＩＰアドレスに到達不可能であるという指示情報を伴うＩＣＭＰ（インターネット制御管理プロトコル）メッセージを送信することができる。
【００３８】
図５は、Ｐ−ＣＳＣＦ１３の利用可能性を監視してそれに反応するための、変更された技術を示す。ＧＧＳＮ１１は、ＧＧＳＮ１１に接続されているユーザ装置１０に対してどのＰ−ＣＳＣＦのアドレスが割り当てられているかに関する情報を、保持又は格納する。ＧＧＳＮは、例えば統計的監視又は心臓の鼓動メカニズムを使用することにより、これらの格納されたアドレスの各々におけるＰ−ＣＳＣＦとのトラヒックを監視する。監視により、Ｐ−ＣＳＣＦのうちのいずれかで障害が発生した又は利用不可能になったと判断された場合、ＧＧＳＮ１１は、もはや利用可能ではない１つの又は各アドレスを引っ込めることにより、そのＰ−ＣＳＣＦのアドレスが有効であるかに関する変更されたアナウンスをユーザ装置に対して提供する。これに影響されるユーザ装置は、次に、変更されたアナウンスの中で提供されるＰ−ＣＳＣＦのアドレスを使用してＩＭＳ再登録を開始する。心臓の鼓動による監視メカニズムを使用する場合、Ｐ−ＣＳＣＦの障害から再登録までの遅延は、心臓の鼓動トラヒックの頻度と、影響されるユーザ装置に対して変更されたアナウンスが行われるペースとに主に依存する。
【００３９】
図５を参照すると、ＧＧＳＮ１１は、３ＧＰＰ ＴＳ ２９．０６１に従い、ユーザ装置（例えば、１０）に対してＰ−ＣＳＣＦのアドレスを提供するように構成される。ＧＧＳＮ１１は、ＩＭＳフレームワークにおける新しいＳＩＰ／ＳＤＰ手順であってもよいし（例えばＩＣＭＰプロトコルを使用する）ＩＰプロトコルベースの手順であってもよい、心臓の鼓動技術を実行する。例えば、これは、ＧＧＳＮが開始する定期的なエコートラヒックであってもよいし、（対応する通知（ＳＩＰ ＮＯＴＩＦＹ）を定期的に発行する）Ｐ−ＣＳＣＦからの「心臓の鼓動」イベントをＧＧＳＮが購読すること（ＳＩＰ ＳＵＢＳＣＲＩＢＥ）であってもよい。Ｐ−ＣＳＣＦの障害が検出された場合、ＧＧＳＮ１１は、どのＩＰ−ＣＡＮ（接続アクセスネットワーク）セッションが影響を受けるかを判断する。
【００４０】
第１の後続の手順によれば、ＧＧＳＮ１１は、影響を受けるＩＰ−ＣＡＮセッションのための新しい１以上のＰ−ＣＳＣＦのアドレスを決定し、その各々について、中で元の１以上のアドレスが発行(publish)されていたＰＤＰコンテキストのための「変更されたＰＤＰコンテキスト」を発行(issue)する。ＰＤＰコンテキストがもはや存在しない場合、専用のシグナリングＰＤＰコンテキスト、又は他の何らかのコンテキストを、使用可能である。ＰＤＰコンテキストに対する唯一の変更は、１以上のＰ−ＣＳＣＦのアドレスの中のＰＣＯ（ｐｒｏｔｏｃｏｌ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｏｐｔｉｏｎ）フィールドであり、ベアラ制御モードが許可する場合であって必要な場合は、専用のシグナリングコンテキストのためのＴＦＴ（トラヒックフローテンプレート）フィルタが新しい状況に対して調整される。ユーザ装置は、新しいＰ−ＣＳＣＦに対してＩＭＳ登録リクエストを発行することにより、ＰＤＰコンテキストの変更に対して応答する。
【００４１】
Ｐ−ＣＳＣＦに障害が発生してからユーザ装置が再登録するまでの遅延には、１つの心臓の鼓動の周期、ＧＧＳＮが「ＰＤＰコンテキストの変更」を送信する際の遅延（同時進行する変更の数は制限され得るので）、及び、ユーザ装置の応答時間までが含まれる。
【００４２】
ユーザ装置がＩＭＳ登録を再確立するように構成される第２の後続の手順によれば、ＩＰ−ＣＡＮセッションが終了した場合、例えば全てのＰＤＰコンテキストを非アクティブ化することにより影響を受けるＩＰ−ＣＡＮセッションを終了させ、ユーザ端末に新しいＩＰ−ＣＡＮセッションを確立させてＩＭＳに再登録させる。この手順の下で、ユーザ装置は別のＩＰアドレスを正常に受信し、全てのＩＭＳサービスが着信する。この場合、Ｐ−ＣＳＣＦに障害が発生してから再登録までの典型的な遅延には、心臓の鼓動メカニズムの１つの周期、ＧＧＳＮが「ＰＤＰコンテキストの削除」を送信する際の遅延（同時進行する変更の数は制限され得るので）、及び、ユーザ装置の応答時間までが含まれる。
【００４３】
有効なＰ−ＣＳＣＦのアドレスの新しいセットの送信に対して単純に応答する能力をユーザ装置が持っていない場合、この技術の使用は、ユーザ装置が最初にＰ−ＣＳＣＦアドレスを要求することに関連してサポート（ＰＣＯフィールド）を宣言するように、条件付にされ得る。
【００４４】
ＧＧＳＮ１１は、３ＧＰＰ ＴＳ ２９．０６１に従ってＧｉインタフェースを介してＰ−ＣＳＣＦ１３の健康状態を監視することができる。このための信号フローを図５に示す。監視には、Ｐ−ＣＳＣＦの再起動の指示情報を伴ういくつかの追加の明示的なシグナリングが含まれ得る。Ｐ−ＣＳＣＦが利用不可能である場合、ＧＧＳＮは、ユーザ装置へ送信されるアドレスリストから対応するＰ−ＣＳＣＦのアドレスを除去することができる。Ｐ−ＣＳＣＦの再起動の場合、ＧＧＳＮは、新しい登録を開始するために、利用可能なＰ−ＣＳＣＦのアドレスのリストを伴う指示情報をユーザ装置に対して送信することができる。
【００４５】
ＧＧＳＮ内でＰ−ＣＳＣＦの健康状態を監視するための代替は、３ＧＰＰ ＴＳ ２９／０６０（７．２節）に示されるように、ＧＧＳＮとＳＧＳＮ（サービングＧＰＲＳサポートノード）との間のＧＴＰにおいて利用可能なＥｃｈｏ Ｒｅｑｕｅｓｔに類似した心臓の鼓動を実装することである。これにより、Ｅｃｈｏ Ｒｅｑｕｅｓｔに対する応答が欠落していることを検出することにより利用不可能性を検出することが可能であり、インクリメントされたＲｅｓｔａｒｔ Ｃｏｕｎｔｅｒを伴うＥｃｈｏ Ｒｅｓｐｏｎｓｅを含む再起動を検出することが可能である。
【技術分野】
【０００１】
本発明は、ＩＰマルチメディア・サブシステム・ネットワークにおける障害復旧に関し、特に、プロキシ呼セッション制御機能の障害からの復旧を可能にする方法及び装置に関する。
【背景技術】
【０００２】
ＩＰマルチメディア・サービスは、音声、ビデオ、メッセージング、データなどの動的な組み合わせを同一のセッション中で提供する。組み合わせ可能な基本アプリケーション及びメディアの数が増加することにより、エンドユーザに提供されるサービスの数が増加し、個人間の通信エクスペリエンスが豊かになるであろう。このことは、所謂「組み合わせＩＰマルチメディア」サービスを含んだ、パーソナライズされた豊かなマルチメディア通信サービスの新しい世代を導くものとなろう。
【０００３】
ＵＭＴＳ（ユニバーサル・モバイル・テレコミュニケーションズ・システム）は、第３世代の無線システムであり、加入者に対してより高いデータレート及び高度なサービスを提供するように設計されている。ＵＭＴＳは、グローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ）の後継であり、ＧＳＭとＵＭＴＳとの間の重要な進化段階には、汎用パケット無線サービス（ＧＰＲＳ）が存在する。ＧＰＲＳは、ＧＳＭコアネットワークにパケット交換を導入し、パケットデータネットワーク（ＰＤＮ）に対する直接アクセスを可能にする。このことは、ＧＳＭ呼ネットワークを介したＩＳＤＮの６４ｋｂｐｓの限界をはるかに超える高いデータレートでのパケット交換伝送を可能にし、これは、２Ｍｂｐｓにも及ぶＵＭＴＳデータ伝送レートのために不可欠なことである。ＵＭＴＳは、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって標準化された。３ＧＰＰは、欧州電気通信標準化協会（ＥＴＳＩ）や電波産業界（ＡＲＩＢ）などの地域標準化機構の集合体である。更なる詳細については、３ＧＰＰ ＴＳ ２３．００２を参照のこと。
【０００４】
ＵＭＴＳのアーキテクチャは、ＩＰマルチメディア・サブシステム（ＩＭＳ）として知られる、従来の電話技術に加えて新しいＩＰマルチメディア・サービスをサポートするためのサブシステムを含む（３ＧＰＰ ＴＳ ２２．２２８， ＴＳ ２３．２２８， ＴＳ ２４．２２９， ＴＳ ２９．２２８， ＴＳ ２９．２２９， ＴＳ ２９．３２８ 及び ＴＳ ２９．３２９ リリース５乃至７）。ＩＭＳは、標準化されたＩＭＳサービスイネーブラの使用を通じて、エンドユーザの個人対個人の通信エクスペリエンスを豊かにする重要な特徴を提供する。ＩＭＳサービスイネーブラは、ＩＰベースのネットワークを介した個人対コンテンツ（クライアント対サーバ）のサービスに加えて、新しい豊かな個人対個人（クライアント対クライアント）の通信サービスを促進するものである。ＩＭＳは、ＰＳＴＮ／ＩＳＤＮ（公衆交換電話網／サービス総合デジタル網）に対しても、インターネットに対しても、共に接続可能である。
【０００５】
ＩＭＳは、ユーザ端末間（又はユーザ端末とアプリケーション端末との間）で呼又はセッションをセットアップして制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）は、セッションのメディアコンポーネントを記述して交渉するために使用される。ＳＩＰはユーザ対ユーザのプロトコルとして創造されたが、ＩＭＳによれば、オペレータ及びサービスプロバイダが、サービスに対するユーザアクセスを制御してそれに応じてユーザに課金することが可能である。３ＧＰＰは、ＩＭＳ内のコンポーネント間に加えて、ユーザ装置（ＵＥ）とＩＭＳとの間のシグナリングのためにもＳＩＰを選択した。
【０００６】
ＵＭＴＳ通信ネットワークの動作、及びそのようなネットワーク内の多様なコンポーネントに関する具体的な詳細については、http://www.3gpp.orgから入手可能なＵＭＴＳの技術仕様から発見可能である。ＵＭＴＳ内でのＳＩＰの使用に関する更なる詳細については、３ＧＰＰ技術仕様ＴＳ ２４．２２９から発見可能である。
【０００７】
添付図面の図１は、ＧＰＲＳ／ＰＳアクセスネットワークの場合にＩＭＳが移動体ネットワークアーキテクチャにどのように適合するかを概略的に示す（ＩＭＳはもちろん、他のアクセスネットワークを介して動作することもできる）。呼セッション制御機能（ＣＳＣＦ）は、ＩＭＳ内でＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、３種類のＣＳＣＦを規定する。即ち、ＳＩＰ端末にとってＩＭＳ内での最初のコンタクトポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、ユーザが加入しているサービスをユーザに対して提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、及び、正しいＳ−ＣＳＣＦを特定し、Ｐ−ＣＳＣＦを介してＳＩＰ端末から受信したＳＩＰリクエストをそのＳ−ＣＳＣＦへ転送するインテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）である。
【０００８】
ユーザは、規定されたＳＩＰ ＲＥＧＩＳＴＥＲメソッドを使用してＩＭＳに登録する。これは、ＩＭＳにアタッチし、ＳＩＰユーザＩＤに到達可能なＩＭＳアドレスをアナウンスするための、メカニズムである。３ＧＰＰでは、ＳＩＰ端末が登録を行う際に、ＩＭＳはユーザを認証し、利用可能なＳ−ＣＳＣＦのセットからＳ−ＣＳＣＦをそのユーザに割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰによって規定されていないが、これらの基準には、負荷分散及びサービス要件が含まれ得る。なお、Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースのサービスに対するユーザアクセスを制御する（そして課金する）ことの要である。オペレータは、さもなければＳ−ＣＳＣＦをバイパスしてしまうような、ユーザ対ユーザの直接のＳＩＰセッションを阻止するためのメカニズムを提供することができる。
【０００９】
登録プロセスの間、Ｓ−ＣＳＣＦがまだ選択されていない場合にＳ−ＣＳＣＦを選択することが、Ｉ−ＣＳＣＦの責務である。Ｉ−ＣＳＣＦは、必要とされるＳ−ＣＳＣＦの能力をホームネットワークのホーム加入者サーバ（ＨＳＳ）から受信し、受信した能力に基づいて適切なＳ−ＣＳＣＦを選択する。ＳＩＰ ＲＥＧＩＳＴＥＲメッセージは、選択されたＳ−ＣＳＣＦへ転送され、Ｓ−ＣＳＣＦは自分のＩＤをＳＩＰ Ｓｅｒｖｉｃｅ Ｒｏｕｔｅヘッダに追加する。Ｐ−ＣＳＣＦがＳ−ＣＳＣＦから２００ ＯＫを受信すると、Ｐ−ＣＳＣＦはＳｅｒｖｉｃｅ ＲｏｕｔｅヘッダからＳＩＰ ＩＤを知る。なお、ユーザのためのＳ−ＣＳＣＦの割り当ては、そのユーザが他の当事者から呼び出されそのユーザにＳ−ＣＳＣＦが正しく割り当てられていない場合にも、Ｉ−ＣＳＣＦによって行われる。これを、「着信」呼の事例と呼ぶ。
【００１０】
ＩＭＳサービスネットワークの中で、ＩＭＳサービス機能を実装するためにアプリケーションサーバ（ＡＳ）が提供される。アプリケーションサーバは、ＩＭＳシステム内のエンドユーザにサービスを提供する。アプリケーションサーバには、３ＧＰＰによって規定されるＭｒインタフェースを介してエンドポイントとしても接続可能であるし、３ＧＰＰによって規定されるＩＳＣインタフェースを介してＳ−ＣＳＣＦによって「リンクする」ことも可能である。後者の場合、ＳＩＰセッション確立の間にどのアプリケーションサーバに「リンクする」べきであるかを判断するために、Ｓ−ＣＳＣＦによって初期フィルタ基準（ＩＦＣ）が使用される。様々な呼の事例に対して様々なＩＦＣを適用可能である。ＩＦＣは、Ｓ−ＣＳＣＦによって、ＩＭＳ登録手順の間にユーザのユーザプロファイルの一部としてＨＳＳから受信される。アプリケーションサーバによっては、加入者ＩＤ（アプリケーションサーバを制御するネットワークによって「所有」されている限りは発呼側加入者であっても着呼側加入者であってもよい）に応じた動作を実行するものもある。例えば、呼の転送の場合、適切な（着信）アプリケーションサーバは、所与の加入者に対する呼の転送先となる新たな着信側当事者を判断する。Ｓ−ＣＳＣＦによって受信されたＳＩＰメッセージが特定のＳＩＰ ＡＳへ転送されるべきであるとＩＦＣが示す場合、そのＡＳがメッセージパスに追加される。ＳＩＰメッセージがＡＳによってＳ−ＣＳＣＦへ返されると、ＳＩＰメッセージは、最終的な宛先へ向かって転送されるか、又は、ＩＦＣの中で指定されている場合は別のＡＳへと転送される。
【００１１】
現行のＩＭＳコアの仕様は、ネットワークエレメントにおける障害の後で整合状態に復旧するための手順を含んでいない。
【００１２】
ＩＭＳ登録時にユーザ装置がコンタクトするＰ−ＣＳＣＦは、ＩＭＳに登録している期間内にＳＩＰシグナリングパスに留まるために、自分自身のＳＩＰ ＵＲＩをＳＩＰパスヘッダに挿入する。
【００１３】
ユーザが着信側としてコンタクトされる場合（例えば、音声呼のＢパーティーとして）、ＩＭＳは、登録時に挿入されたＰ−ＣＳＣＦのＳＩＰ ＵＲＩを使用して端末にコンタクト可能であることを要求する。通信に障害が存在する場合、ＩＭＳが更なる試みを断念するまでの遅延は、数分かそこらの問題かもしれない。その期間の後、ＳＩＰタイムアウトエラーがＡパーティーに返される。到達不可能なＰ−ＣＳＣＦによって管理される全てのユーザへ宛てられた全ての着信ＳＩＰリクエストは、それらのユーザが新しい登録を開始するまで失敗するであろう。このシナリオは、３ＧＰＰ ＴＲ ２３．８２０ ５．３．３節に記述されている。
【００１４】
既存のソリューションでは、Ｐ−ＣＳＣＦの障害は、ユーザがＩＭＳコアネットワークに接続されているという認識を持っていながら到達不可能である期間を意味する。この期間は、ユーザ端末からＳＩＰリクエストが開始されるまで継続することになり、再登録期間と同じ長さになる場合もある。現行では、ＩＭＳにおける再登録タイマーは３０分から数時間の範囲に亘る。これは、Ｐ−ＣＳＣＦの障害がいかに稀であるかを考慮に入れたとしても、ユーザによってはこの状態であり続けるには長すぎる時間であろう。
【００１５】
「心臓の鼓動」シグナリング、又は、ユーザ装置によって実行され、且つ、ＩＭＳコアとの接続（そしてそれ故に登録）が失われているということをユーザ装置に対して示すように規定されるその他の監視は、この問題を解決するかもしれない。特に、このことは、Ｐ−ＣＳＣＦに障害が発生している時や再起動した時という場合に当てはまる。しかしながら、そのようなシグナリングは、移動体ユーザ装置のバッテリーをすぐに使い果たしてしまうであろうし、許容不可能な量の無線リソースを消費するであろう。
【発明の概要】
【課題を解決するための手段】
【００１６】
本発明の第１の態様によれば、ＩＰマルチメディア・サブシステム・ネットワーク内のプロキシ呼セッション制御機能の障害からの復旧を促進する方法であって、
ゲートウェイにおいて、前記プロキシ呼セッション制御機能から前記ゲートウェイに到着する信号を監視するステップと、
前記ゲートウェイにおいて、前記監視対象の信号が受信不可能になった場合に指示情報を提供するステップと、
前記ゲートウェイにおいて、前記指示情報に応えて、前記プロキシ呼セッション制御機能に関連付けられている１つの又は各々のユーザ装置に対して前記プロキシ呼セッション制御機能が利用不可能であるということを信号通知する動作を実行するステップと、
を備えることを特徴とする方法が提供される。
【００１７】
前記提供するステップは、到達不可能であるという明示的な指示情報を伝送ネットワークから受信した後に前記指示情報を提供してもよい。前記提供するステップは、前記監視対象の信号における、送信ノードの利用不可能性又は到着不可能性の特徴である変化の後に、前記指示情報を提供してもよい。
【００１８】
前記提供するステップは、前記監視対象の信号の中断に応えて、前記指示情報を提供してもよい。前記提供するステップは、前記監視対象の信号の受信から所定の遅延の後に、前記指示情報を提供してもよい。前記所定の遅延は、前記１つの又は各々のユーザ装置から前記ゲートウェイを介して前記プロキシ呼セッション制御機能に向けられた信号トラヒックレベルの関数であってもよい。
【００１９】
前記所定の遅延は、前記プロキシ呼セッション制御機能に関連付けられたユーザ装置インスタンスの数の関数であってもよい。前記所定の遅延は、リアルタイムで実行されるシグナリングトラヒック測定値、及び／又は、事前のシグナリングトラヒック測定値の関数であってもよい。前記所定の遅延は、これらの関数のいかなる組み合わせであってもよい。
【００２０】
前記監視するステップは、前記プロキシ呼セッション制御機能が前記ゲートウェイに対して応答を送信することを要求する信号を、前記プロキシ呼セッション制御機能へ送信するステップを含んでもよく、前記提供するステップは、前記ゲートウェイにおいて所定数の応答を受信できなかったことに応えて、前記指示情報を提供してもよい。前記ゲートウェイと前記プロキシ呼セッション制御機能との間の信号トラヒックが所定レベルより低い場合に前記応答を要求する信号が送信されてもよい。
【００２１】
前記ゲートウェイは、汎用パケット無線サービスのためのゲートウェイ・サポート・ノードであってもよい。前記動作を実行するステップは、セッション管理シグナリングを用いて前記動作を実行するステップを含んでもよい。前記動作は、
前記１つの又は各々のユーザ装置に対するシグナリングＩＰフローに対応するトラヒックフローテンプレートを除去することと、
前記１つの又は各々のユーザ装置に対するシグナリングＩＰフローを搬送するＰＤＰコンテキストを削除することと、
ＧＰＲＳセッション管理において通知を送信することと、
宛先ＩＰアドレスに到達不可能であることを示すＩＣＭＰメッセージを送信することと、
前記１つの又は各々のユーザ装置に対してどのプロキシ呼セッション制御機能が利用可能であるかを通知することと、
のうちのいずれか１つを含んでもよい。
【００２２】
前記１つの又は各々のユーザ装置は、前記ユーザ装置を別のプロキシ呼セッション制御機能に関連付けることを含む前記ＩＰマルチメディア・サブシステムへの再登録を実行することにより、前記動作に対して応答してもよい。
【００２３】
前記監視するステップは、前記ゲートウェイにおいて、アドレスが前記ゲートウェイに格納されている各々のプロキシ呼セッション制御機能から前記ゲートウェイに到着する信号を監視するステップを含んでもよい。
【００２４】
本発明の第２の態様によれば、ＩＰマルチメディア・サブシステム・ネットワーク内でゲートウェイとして動作するように構成される装置であって、
プロキシ呼セッション制御機能から到着する信号を受信する入力部と、
前記プロキシ呼セッション制御機能から受信した前記信号を監視する手段と、
前記監視対象の信号が受信不可能になった場合に指示情報を提供する手段と、
前記指示情報に応えて、前記ＩＰマルチメディア・サブシステム・ネットワークに対する以前の登録の間に前記プロキシ呼セッション制御機能に関連付けられた１つの又は各々のユーザ装置に対して前記プロキシ呼セッション制御機能が利用不可能であるということを信号通知する動作を実行する手段と、
を備えることを特徴とする装置が提供される。
【図面の簡単な説明】
【００２５】
【図１】上で説明したものであり、ＩＰマルチメディア・サブシステムの３Ｇ移動体通信システムへの統合を概略的に示す。
【図２】本発明の実施形態を構成し本発明の実施形態を構成する方法を実行するＧＧＳＮに関連する構造及びシグナリングを示す。
【図３】図２に類似するものであり、Ｐ−ＣＳＣＦの利用可能性を監視する第１の技術を示す。
【図４】図２に類似するものであり、Ｐ−ＣＳＣＦの利用可能性を監視する別の技術を示す。
【図５】Ｐ−ＣＳＣＦの障害からの復旧に関係するＩＭＳシグナリングを示す。
【発明を実施するための形態】
【００２６】
図２は、図１に示すシステムの一部を示し、ユーザ装置１０に接続されている。ネットワークは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１１を含む。ＧＧＳＮ１１は、各々がパケットデータプロトコル（ＰＤＰ）コンテキスト１２を用いて複数のユーザ装置１０に関連付けられている複数のゲートウェイのうちの１つである。
【００２７】
図２は、ユーザ装置１０がプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）１３に登録している状態を示す。ユーザ装置１０は、セッション開始プロトコル（ＳＩＰ）シグナリングのインターネットプロトコル（ＩＰ）フロー１４を含んだ手段を用いて、ＧＧＳＮ１１を介してＰ−ＣＳＣＦ１３と通信する。
【００２８】
ＧＧＳＮ１１は、Ｐ−ＣＳＣＦ１３の利用可能性を監視する新機能１５を含む。新機能１５は、フロー１４のようなＰ−ＣＳＣＦ１３からＧＧＳＮ１１への信号が受信不可能になった場合に、指示情報を提供する。機能１５は、図３を参照して後述するような、Ｐ−ＣＳＣＦ１３からのトラヒックの統計的監視を実行可能である。或いは、又はこれに加えて、機能１５は、「心臓の鼓動メカニズム」１６を使用して、機能１５によって生成されＰ−ＣＳＣＦ１３へ送信されＰ−ＣＳＣＦからの応答を要求する信号に対するＰ−ＣＳＣＦ１３の応答を監視することができる。そのような心臓の鼓動メカニズムは、図４を参照して後述する。
【００２９】
大まかに言えば、機能１５は、Ｐ−ＣＳＣＦ１３からの信号フローを監視し、信号フローにおける送信者の利用不可能性の特徴である変化（例えば、監視対象信号の中断など）に応えて、受信不可能に関する指示情報を提供する。次に機能１５は、Ｐ−ＣＳＣＦ１３の利用不可能性を信号通知するために、適切な動作を行う（例えば、１つ又は各々のユーザ装置１０に、現在のところ利用可能であると知られている又は信じられている別のＰ−ＣＳＣＦに対する再登録を開始させる）。
【００３０】
ＧＧＳＮ１１と各Ｐ−ＣＳＣＦとの間には固定的な接続が存在しないので、機能１５は、どのＰ−ＣＳＣＦ（例えば、１３）を監視すべきかを知る必要がある。ＧＧＳＮ１１に接続されているユーザ装置に現時点で関連付けられている各Ｐ−ＣＳＣＦのアドレスがＧＧＳＮ１１に格納されるシステムのような例では、機能１５は、ＧＧＳＮ１１に現時点で格納されている各Ｐ−ＣＳＣＦのアドレスを監視すればよい。或いは、又はこれに加えて、機能１５は、シグナリングのために使用されるものとしてマークされたＩＰアドレスの宛先アドレスを検査してもよい。そのようなマーク付けは、３ＧＰＰ ＴＳ ２４．００８に示されているように、ＧＰＲＳセッション管理シグナリングにおいてユーザ装置によって実行可能である。そのようなマーク付けは、Ｇｘを介してＰＣＲＦによっても実行可能であるが、これは新しいメカニズムである。
【００３１】
前述の通り、図３は、Ｐ−ＣＳＣＦ１３の利用可能性を判断する統計的監視技術を示す。この技術は、次の事実に基づいている。その事実とは、ＧＧＳＮ１１は一般的に、多数のユーザ装置１０ａ、１０ｂ、１０ｃのＰ−ＣＳＣＦに対するシグナリングを扱うということである。従って、統計的には、ＧＧＳＮを介したＣＳＣＦへの、そしてＣＳＣＦからの、ほとんど連続的なＩＰパケットのフローが存在するであろう。機能１５はそれゆえ、Ｐ−ＣＳＣＦ１３のアドレスに到達不可能であることを示すＩＣＭＰを受信した場合、又は、Ｐ−ＣＳＣＦに関連付けられた全てのユーザ装置に対するＰ−ＣＳＣＦからのパケットのフローが許容不可能な期間中断した場合に、Ｐ−ＣＳＣＦ１３に障害が発生したと判断することができる。この期間は、いかなる適切な方法によっても決定可能なものであり、例えば、Ｐ−ＣＳＣＦ１３とのシグナリングを行っているユーザ装置１０ａ、１０ｂ、１０ｃの数に対応する、ＧＧＳＮ１１がＰ−ＣＳＣＦ１３のために扱っているシグナリングＩＰフローの数に従って動的に調整されてもよい。この期間は、Ｐ−ＣＳＣＦからの、及び／又は、Ｐ−ＣＳＣＦへの、シグナリングＩＰパケットフローの測定値に従って動的に調整されてもよい。この期間は、ＧＧＳＮにとってのシグナリングトラヒックの予測を反映するように事前設定されてもよい。この期間は、これらの方法のうち任意のものの組み合わせを用いて決定されてもよい。この期間は、Ｐ−ＣＳＣＦの利用不可能性を発見するための要求される最大遅延にも基づく。
【００３２】
機能１５は一般的に、ＧＧＳＮ１１に接続されたユーザ装置のいずれかに影響を与える障害に関する早期の信頼できるシグナリングを提供するように、複数のＰ−ＣＳＣＦの利用可能性を同時に監視することができる。この機能は、上述した統計的監視、及び／又は後述する心臓の鼓動メカニズムを実行するために、各Ｐ−ＣＳＣＦに関係するシグナリングフローを個別に監視する。
【００３３】
心臓の鼓動メカニズムを図４に示す。機能１５は、ＩＰパケット又は「ｐｉｎｇ」を１つの（又は各）Ｐ−ＣＳＣＦ１３に対して定期的に送信する。ＩＰパケットは、Ｐ−ＣＳＣＦ１３からＧＧＳＮ１１へ戻る応答を要求するように構成される。それゆえ、Ｐ−ＣＳＣＦ１３が利用可能で正しく機能している場合は、Ｐ−ＣＳＣＦ１３は、ＧＧＳＮ１１へと返送する応答ＩＰパケット又は「ｐｏｎｇ」により、ｐｉｎｇに対して応答する。機能１５は、各ｐｉｎｇの結果として帰ってくるｐｏｎｇを待ち受ける。Ｐ−ＣＳＣＦからのｐｏｎｇの形式である１以上の応答が欠落しているということは、Ｐ−ＣＳＣＦの障害として判断される。
【００３４】
心臓の鼓動メカニズムは、ＩＰフローをシグナリングするユーザ装置の数とは無関係に使用可能であるので、Ｐ−ＣＳＣＦの利用可能性を監視するより汎用的な技術を提供する。心臓の鼓動メカニズムは、ＧＧＳＮ１１及びＰ−ＣＳＣＦ１３に対して追加の信号負荷をもたらすが、一方で統計的監視は、既存の信号フローを利用するので、負荷を変化させない。しかしながら、統計的監視は、信頼に足るように実行するためには、最低限のまとまったシグナリングトラヒックを必要とする。
【００３５】
いずれの技術も単独で実行可能であるが、両方の技術を同時に実行することもできるし、或いは、シグナリングトラヒックが十分な場合は統計的監視が使用される一方でシグナリングトラヒックが不十分な場合は心臓の鼓動メカニズムが使用されるようなやり方で両方の技術を組み合わせることもできる。機能１５は、例えばシグナリングトラヒックに従って、いつでもこれらの技術の間で切り替わることができる。
【００３６】
Ｐ−ＣＳＣＦ１３の障害（又は他の利用不可能性）からの復旧を促進するために、ＧＧＳＮ１１は、多様な対策のうちの任意のもの又は任意の組み合わせを実行可能である。一般的には、これらの対策は、障害が発生したか又は利用不可能なＰ−ＣＳＣＦに以前に登録されていた１つの又は各ユーザ装置に対して通知を行うために使用される。するとユーザ装置は、現時点で利用可能な別のＰ−ＣＳＣＦに登録することができる。
【００３７】
ＧＧＳＮ１１は、例えば３ＧＰＰ ＴＳ ２４．００８に規定される既存の手順に従って、ユーザ装置に対するＰＤＰコンテキスト変更手順を使用してシグナリングＩＰフローを除去することにより、ユーザ装置１０に対する通知を行うことができる。ＧＧＳＮ１１は、やはり３ＧＰＰ ＴＳ ２４．００８に規定されているＰＤＰコンテキスト非アクティブ化手順を使用して、シグナリングフローを搬送するＰＤＰコンテキスト１２を削除することができる。ＧＧＳＮ１１は、現在のところ３ＧＰＰ ＴＳ ２４．００８に規定されていないＧＰＲＳセッション管理シグナリングの中で、シグナリングＩＰフローの宛先（Ｐ−ＣＳＣＦ１３）に障害が発生しているという新しい明示的な通知を送信することができる。ＧＧＳＮは、ＩＥＴＦ ＲＦＣ７２２に従い、（Ｐ−ＣＳＣＦの）宛先ＩＰアドレスに到達不可能であるという指示情報を伴うＩＣＭＰ（インターネット制御管理プロトコル）メッセージを送信することができる。
【００３８】
図５は、Ｐ−ＣＳＣＦ１３の利用可能性を監視してそれに反応するための、変更された技術を示す。ＧＧＳＮ１１は、ＧＧＳＮ１１に接続されているユーザ装置１０に対してどのＰ−ＣＳＣＦのアドレスが割り当てられているかに関する情報を、保持又は格納する。ＧＧＳＮは、例えば統計的監視又は心臓の鼓動メカニズムを使用することにより、これらの格納されたアドレスの各々におけるＰ−ＣＳＣＦとのトラヒックを監視する。監視により、Ｐ−ＣＳＣＦのうちのいずれかで障害が発生した又は利用不可能になったと判断された場合、ＧＧＳＮ１１は、もはや利用可能ではない１つの又は各アドレスを引っ込めることにより、そのＰ−ＣＳＣＦのアドレスが有効であるかに関する変更されたアナウンスをユーザ装置に対して提供する。これに影響されるユーザ装置は、次に、変更されたアナウンスの中で提供されるＰ−ＣＳＣＦのアドレスを使用してＩＭＳ再登録を開始する。心臓の鼓動による監視メカニズムを使用する場合、Ｐ−ＣＳＣＦの障害から再登録までの遅延は、心臓の鼓動トラヒックの頻度と、影響されるユーザ装置に対して変更されたアナウンスが行われるペースとに主に依存する。
【００３９】
図５を参照すると、ＧＧＳＮ１１は、３ＧＰＰ ＴＳ ２９．０６１に従い、ユーザ装置（例えば、１０）に対してＰ−ＣＳＣＦのアドレスを提供するように構成される。ＧＧＳＮ１１は、ＩＭＳフレームワークにおける新しいＳＩＰ／ＳＤＰ手順であってもよいし（例えばＩＣＭＰプロトコルを使用する）ＩＰプロトコルベースの手順であってもよい、心臓の鼓動技術を実行する。例えば、これは、ＧＧＳＮが開始する定期的なエコートラヒックであってもよいし、（対応する通知（ＳＩＰ ＮＯＴＩＦＹ）を定期的に発行する）Ｐ−ＣＳＣＦからの「心臓の鼓動」イベントをＧＧＳＮが購読すること（ＳＩＰ ＳＵＢＳＣＲＩＢＥ）であってもよい。Ｐ−ＣＳＣＦの障害が検出された場合、ＧＧＳＮ１１は、どのＩＰ−ＣＡＮ（接続アクセスネットワーク）セッションが影響を受けるかを判断する。
【００４０】
第１の後続の手順によれば、ＧＧＳＮ１１は、影響を受けるＩＰ−ＣＡＮセッションのための新しい１以上のＰ−ＣＳＣＦのアドレスを決定し、その各々について、中で元の１以上のアドレスが発行(publish)されていたＰＤＰコンテキストのための「変更されたＰＤＰコンテキスト」を発行(issue)する。ＰＤＰコンテキストがもはや存在しない場合、専用のシグナリングＰＤＰコンテキスト、又は他の何らかのコンテキストを、使用可能である。ＰＤＰコンテキストに対する唯一の変更は、１以上のＰ−ＣＳＣＦのアドレスの中のＰＣＯ（ｐｒｏｔｏｃｏｌ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｏｐｔｉｏｎ）フィールドであり、ベアラ制御モードが許可する場合であって必要な場合は、専用のシグナリングコンテキストのためのＴＦＴ（トラヒックフローテンプレート）フィルタが新しい状況に対して調整される。ユーザ装置は、新しいＰ−ＣＳＣＦに対してＩＭＳ登録リクエストを発行することにより、ＰＤＰコンテキストの変更に対して応答する。
【００４１】
Ｐ−ＣＳＣＦに障害が発生してからユーザ装置が再登録するまでの遅延には、１つの心臓の鼓動の周期、ＧＧＳＮが「ＰＤＰコンテキストの変更」を送信する際の遅延（同時進行する変更の数は制限され得るので）、及び、ユーザ装置の応答時間までが含まれる。
【００４２】
ユーザ装置がＩＭＳ登録を再確立するように構成される第２の後続の手順によれば、ＩＰ−ＣＡＮセッションが終了した場合、例えば全てのＰＤＰコンテキストを非アクティブ化することにより影響を受けるＩＰ−ＣＡＮセッションを終了させ、ユーザ端末に新しいＩＰ−ＣＡＮセッションを確立させてＩＭＳに再登録させる。この手順の下で、ユーザ装置は別のＩＰアドレスを正常に受信し、全てのＩＭＳサービスが着信する。この場合、Ｐ−ＣＳＣＦに障害が発生してから再登録までの典型的な遅延には、心臓の鼓動メカニズムの１つの周期、ＧＧＳＮが「ＰＤＰコンテキストの削除」を送信する際の遅延（同時進行する変更の数は制限され得るので）、及び、ユーザ装置の応答時間までが含まれる。
【００４３】
有効なＰ−ＣＳＣＦのアドレスの新しいセットの送信に対して単純に応答する能力をユーザ装置が持っていない場合、この技術の使用は、ユーザ装置が最初にＰ−ＣＳＣＦアドレスを要求することに関連してサポート（ＰＣＯフィールド）を宣言するように、条件付にされ得る。
【００４４】
ＧＧＳＮ１１は、３ＧＰＰ ＴＳ ２９．０６１に従ってＧｉインタフェースを介してＰ−ＣＳＣＦ１３の健康状態を監視することができる。このための信号フローを図５に示す。監視には、Ｐ−ＣＳＣＦの再起動の指示情報を伴ういくつかの追加の明示的なシグナリングが含まれ得る。Ｐ−ＣＳＣＦが利用不可能である場合、ＧＧＳＮは、ユーザ装置へ送信されるアドレスリストから対応するＰ−ＣＳＣＦのアドレスを除去することができる。Ｐ−ＣＳＣＦの再起動の場合、ＧＧＳＮは、新しい登録を開始するために、利用可能なＰ−ＣＳＣＦのアドレスのリストを伴う指示情報をユーザ装置に対して送信することができる。
【００４５】
ＧＧＳＮ内でＰ−ＣＳＣＦの健康状態を監視するための代替は、３ＧＰＰ ＴＳ ２９／０６０（７．２節）に示されるように、ＧＧＳＮとＳＧＳＮ（サービングＧＰＲＳサポートノード）との間のＧＴＰにおいて利用可能なＥｃｈｏ Ｒｅｑｕｅｓｔに類似した心臓の鼓動を実装することである。これにより、Ｅｃｈｏ Ｒｅｑｕｅｓｔに対する応答が欠落していることを検出することにより利用不可能性を検出することが可能であり、インクリメントされたＲｅｓｔａｒｔ Ｃｏｕｎｔｅｒを伴うＥｃｈｏ Ｒｅｓｐｏｎｓｅを含む再起動を検出することが可能である。
【特許請求の範囲】
【請求項１】
ＩＰマルチメディア・サブシステム・ネットワーク内のプロキシ呼セッション制御機能の障害からの復旧を促進する方法であって、
ゲートウェイにおいて、前記プロキシ呼セッション制御機能から前記ゲートウェイに到着する信号を監視するステップと、
前記ゲートウェイにおいて、前記監視対象の信号が受信不可能になった場合に指示情報を提供するステップと、
前記ゲートウェイにおいて、前記指示情報に応えて、前記プロキシ呼セッション制御機能に関連付けられている１つの又は各々のユーザ装置に対して前記プロキシ呼セッション制御機能が利用不可能であるということを信号通知する動作を実行するステップと、
を備えることを特徴とする方法。
【請求項２】
前記提供するステップは、前記監視対象の信号の中断に応えて、前記指示情報を提供することを特徴とする請求項１に記載の方法。
【請求項３】
前記提供するステップは、前記監視対象の信号の受信から所定の遅延の後に、前記指示情報を提供することを特徴とする請求項２に記載の方法。
【請求項４】
前記所定の遅延は、前記１つの又は各々のユーザ装置から前記ゲートウェイを介して前記プロキシ呼セッション制御機能に向けられた信号トラヒックレベルの関数であることを特徴とする請求項３に記載の方法。
【請求項５】
前記監視するステップは、前記プロキシ呼セッション制御機能が前記ゲートウェイに対して応答を送信することを要求する信号を、前記プロキシ呼セッション制御機能へ送信するステップを含み、
前記提供するステップは、前記ゲートウェイにおいて所定数の応答を受信できなかったことに応えて、前記指示情報を提供する
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記ゲートウェイと前記プロキシ呼セッション制御機能との間の信号トラヒックが所定レベルより低い場合に前記応答を要求する信号が送信されることを特徴とする、請求項２乃至４のいずれか１項に従属する請求項５に記載の方法。
【請求項７】
前記ゲートウェイは、汎用パケット無線サービスのためのゲートウェイ・サポート・ノードであることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記動作を実行するステップは、セッション管理シグナリングを用いて前記動作を実行するステップを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記動作は、前記１つの又は各々のユーザ装置に対するシグナリングＩＰフローに対応するトラヒックフローテンプレートを除去することを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記動作は、前記１つの又は各々のユーザ装置に対するシグナリングＩＰフローを搬送するＰＤＰコンテキストを削除することを含むことを特徴とする請求項８に記載の方法。
【請求項１１】
前記動作は、ＧＰＲＳセッション管理において通知を送信することを含むことを特徴とする請求項８に記載の方法。
【請求項１２】
前記動作は、宛先ＩＰアドレスに到達不可能であることを示すＩＣＭＰメッセージを送信することを含むことを特徴とする請求項８に記載の方法。
【請求項１３】
前記動作は、前記１つの又は各々のユーザ装置に対してどのプロキシ呼セッション制御機能が利用可能であるかを通知することを含むことを特徴とする請求項８に記載の方法。
【請求項１４】
前記１つの又は各々のユーザ装置は、前記ユーザ装置を別のプロキシ呼セッション制御機能に関連付けることを含む前記ＩＰマルチメディア・サブシステムへの再登録を実行することにより、前記動作に対して応答することを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記監視するステップは、前記ゲートウェイにおいて、アドレスが前記ゲートウェイに格納されている各々のプロキシ呼セッション制御機能から前記ゲートウェイに到着する信号を監視するステップを含むことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
ＩＰマルチメディア・サブシステム・ネットワーク内でゲートウェイとして動作するように構成される装置であって、
プロキシ呼セッション制御機能から到着する信号を受信する入力部と、
前記プロキシ呼セッション制御機能から受信した前記信号を監視する手段と、
前記監視対象の信号が受信不可能になった場合に指示情報を提供する手段と、
前記指示情報に応えて、前記プロキシ呼セッション制御機能に関連付けられている１つの又は各々のユーザ装置に対して前記プロキシ呼セッション制御機能が利用不可能であるということを信号通知する動作を実行する手段と、
を備えることを特徴とする装置。
【請求項１】
ＩＰマルチメディア・サブシステム・ネットワーク内のプロキシ呼セッション制御機能の障害からの復旧を促進する方法であって、
ゲートウェイにおいて、前記プロキシ呼セッション制御機能から前記ゲートウェイに到着する信号を監視するステップと、
前記ゲートウェイにおいて、前記監視対象の信号が受信不可能になった場合に指示情報を提供するステップと、
前記ゲートウェイにおいて、前記指示情報に応えて、前記プロキシ呼セッション制御機能に関連付けられている１つの又は各々のユーザ装置に対して前記プロキシ呼セッション制御機能が利用不可能であるということを信号通知する動作を実行するステップと、
を備えることを特徴とする方法。
【請求項２】
前記提供するステップは、前記監視対象の信号の中断に応えて、前記指示情報を提供することを特徴とする請求項１に記載の方法。
【請求項３】
前記提供するステップは、前記監視対象の信号の受信から所定の遅延の後に、前記指示情報を提供することを特徴とする請求項２に記載の方法。
【請求項４】
前記所定の遅延は、前記１つの又は各々のユーザ装置から前記ゲートウェイを介して前記プロキシ呼セッション制御機能に向けられた信号トラヒックレベルの関数であることを特徴とする請求項３に記載の方法。
【請求項５】
前記監視するステップは、前記プロキシ呼セッション制御機能が前記ゲートウェイに対して応答を送信することを要求する信号を、前記プロキシ呼セッション制御機能へ送信するステップを含み、
前記提供するステップは、前記ゲートウェイにおいて所定数の応答を受信できなかったことに応えて、前記指示情報を提供する
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記ゲートウェイと前記プロキシ呼セッション制御機能との間の信号トラヒックが所定レベルより低い場合に前記応答を要求する信号が送信されることを特徴とする、請求項２乃至４のいずれか１項に従属する請求項５に記載の方法。
【請求項７】
前記ゲートウェイは、汎用パケット無線サービスのためのゲートウェイ・サポート・ノードであることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記動作を実行するステップは、セッション管理シグナリングを用いて前記動作を実行するステップを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記動作は、前記１つの又は各々のユーザ装置に対するシグナリングＩＰフローに対応するトラヒックフローテンプレートを除去することを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記動作は、前記１つの又は各々のユーザ装置に対するシグナリングＩＰフローを搬送するＰＤＰコンテキストを削除することを含むことを特徴とする請求項８に記載の方法。
【請求項１１】
前記動作は、ＧＰＲＳセッション管理において通知を送信することを含むことを特徴とする請求項８に記載の方法。
【請求項１２】
前記動作は、宛先ＩＰアドレスに到達不可能であることを示すＩＣＭＰメッセージを送信することを含むことを特徴とする請求項８に記載の方法。
【請求項１３】
前記動作は、前記１つの又は各々のユーザ装置に対してどのプロキシ呼セッション制御機能が利用可能であるかを通知することを含むことを特徴とする請求項８に記載の方法。
【請求項１４】
前記１つの又は各々のユーザ装置は、前記ユーザ装置を別のプロキシ呼セッション制御機能に関連付けることを含む前記ＩＰマルチメディア・サブシステムへの再登録を実行することにより、前記動作に対して応答することを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記監視するステップは、前記ゲートウェイにおいて、アドレスが前記ゲートウェイに格納されている各々のプロキシ呼セッション制御機能から前記ゲートウェイに到着する信号を監視するステップを含むことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
ＩＰマルチメディア・サブシステム・ネットワーク内でゲートウェイとして動作するように構成される装置であって、
プロキシ呼セッション制御機能から到着する信号を受信する入力部と、
前記プロキシ呼セッション制御機能から受信した前記信号を監視する手段と、
前記監視対象の信号が受信不可能になった場合に指示情報を提供する手段と、
前記指示情報に応えて、前記プロキシ呼セッション制御機能に関連付けられている１つの又は各々のユーザ装置に対して前記プロキシ呼セッション制御機能が利用不可能であるということを信号通知する動作を実行する手段と、
を備えることを特徴とする装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１０−５４１３４９（Ｐ２０１０−５４１３４９Ａ）
【公表日】平成２２年１２月２４日（２０１０．１２．２４）
【国際特許分類】
【出願番号】特願２０１０−５２６１７０（Ｐ２０１０−５２６１７０）
【出願日】平成１９年９月２８日（２００７．９．２８）
【国際出願番号】ＰＣＴ／ＥＰ２００７／０６０３４６
【国際公開番号】ＷＯ２００９／０３９８９４
【国際公開日】平成２１年４月２日（２００９．４．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２２年１２月２４日（２０１０．１２．２４）
【国際特許分類】
【出願日】平成１９年９月２８日（２００７．９．２８）
【国際出願番号】ＰＣＴ／ＥＰ２００７／０６０３４６
【国際公開番号】ＷＯ２００９／０３９８９４
【国際公開日】平成２１年４月２日（２００９．４．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]