JP5367909B2 - Ｉｍｓネットワークとの間のローミング協定の管理 - Google Patents

Description

本発明は、ＩＰマルチメディアサブシステム（ＩＭＳ）ネットワークにおけるローミング協定を管理するための技術に関するものである。より詳しくは、２つのネットワークとの間で自動的に確立されているローミングアグリーメント（協定：agreement）を管理するための技術に関するものであり、ここで、一方のＩＭＳネットワークは他方のＩＭＳネットワークに向かうネットワークエッジにおいて複数のプロキシノードをサポートする。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、移動通信ネットワーク内の特定のドメインである。この移動通信ネットワークには、汎用パケット無線サービス（ＧＰＲＳ）ネットワーク及びユニバーサル移動通信システム（ＵＭＴＳ）ネットワークがある。ＩＭＳは、マルチメディア及び他のサービスのユーザへのプロビジョン（提供）の集中化を実現することができる。ＩＭＳベースのサービスは、本質的には、特定のアクセス技術とは独立して使用することができる。例えば、通常のアクセスをパケットベースのトランスポートメカニズムに基づかせながら、ユーザは、例えば、ＧＳＭ（登録商標）ネットワークのＣＳ（回線交換）ドメインを介してＩＭＳへアクセスすることもできる。選択されている特定のアクセスとは独立して、ユーザは、ＩＭＳサービスのプロビジョンのためにＩＭＳへ登録しなければならない。登録と、特定のユーザへプロビジョンするサービスは、ＩＭＳのサービング（在圏）呼制御機能（Ｓ−ＣＳＣＦ）によって制御される。

音声サービスのプロビジョンに対して知られているローミング状況は、例えば、ＩＭＳサービスのプロビジョンに対しても関連している。ユーザは、訪問先ネットワークのＩＭＳドメインを介して自身のホームＩＭＳネットワークに登録することを試行することができる。この場合、ユーザ端末は、自身の登録リクエストを、訪問先ネットワークのプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）へ送信し、プロキシＣＳＣＦはその登録リクエストをユーザのホームネットワークへ転送する。この目的のために、少なくとも１つのインターロゲイティング（尋問：interrogating）ＣＳＣＦ（Ｉ−ＣＳＣＦ）をホームＩＭＳネットワークで利用可能となるようにしなければならない。ここで、Ｐ−ＣＳＣＦは登録リクエストをその少なくとも１つのインターロゲイティングＣＳＣＦへ送信する。そして、これは、ホームネットワークの適切なＳ−ＣＳＣＦを識別し、登録リクエストをそのＳ−ＣＳＣＦへ送信するための、Ｉ−ＣＳＣＦのタスクとなる。

このようなＩＭＳローミング状況に対する前提条件は、ローミング協定がホームネットワークと訪問先ネットワークとの間で整備されていることである。ここで、ローミング協定は、どのようにして、訪問するユーザが訪問先ネットワークを介して自身のホームネットワークでの所望のサービスにアクセスすることができるかを定義する。ＩＭＳサービスに関しては、今日のローミング協定は、通常は、単に、トンネリング方法を有しているだけである。これは、例えば、訪問先ネットワークはＩＭＳを有していないからである。これは、訪問するユーザのトラフィックが訪問先ネットワーク内のＳＧＳＮ（サービングＧＰＲＳサポートノード）から、ホームネットワークのＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード）へトンネルされることを意味する。このソリューションは、ユーザに対する所望のＱｏＳ（サービスの品質）を保証することができない場合がある。例えば、ベストエフォート型のＱｏＳが訪問先ネットワークに提供される場合を検討する。例えば、ビデオテレフォニーのような、高帯域かつ遅延が少ないマルチメディア配信セッションの場合、ホームネットワークからユーザによって実際にリクエストされるサービスを十分に満足させられない可能性がある。

ＩＭＳドメインの数は、増加していて、また、将来的にもより確実に増加することになる。この増加には、費用効果がある「ボックス内ＩＭＳ（IMS in a box）」ソリューションによって実現される場合のみのローカルの通信範囲及び一時的な通信範囲の少なくとも一方を備えるＩＭＳネットワークも含んでいる。マルチメディアサービスをユーザに柔軟に提供することを可能にするためには、サービスが所望の品質でＩＭＳユーザへ提供され、かつ対応するローミング協定が整備されていなければならないことを前提条件とする。現在のところ、ローミング協定は、通常は、手動でセットアップされる。しかしながら、将来的に要求される数のローミング関係を手動で管理することは、実用的な（ビジネス上の）観点からは実現不可能と考えられる。この要求される数には、通常に増加するＩＭＳドメインの数ばかりか、更には、特に、例えば、展覧会、会議、文化的なイベント等の期間だけのような一時的に存在するＩＭＳドメインに関する数も含まれる。

また、例えば、短期間のトラフィックピークあるいは一時的なサービスの提供に柔軟に応対することを可能にするために、既存のローミング協定を柔軟に更新するための可能性を有することの要望も存在し、これは通常、ローミング協定の手動管理によって達成できるものではない。

これらの理由のために、ＩＭＳネットワーク間で自動的にローミング協定を確立するための（更新するための）手順が要求されている。３ＧＰＰ技術仕様書であるＴＳ２４．２２８とＴＳ２４．２２９は、ＩＭＳシグナリングフローを定義し、これには、ローミングの場合のＩＭＳネットワーク間のシグナリングフローを含んでいる。しかしながら、これらの仕様書では、ローミング協定が整備されているあるいは整備されていない、即ち、そのような手順が、手動で確立されるローミング協定に基づいていることを想定している。３ＧＰＰ技術報告書であるＴＲ２２．９７１は、集中ネットワーク間サービスポイントに基づく「自動」ローミングの形態を記載していて、これは、ローミング関係の確立を実現可能にするために提供されている。

３ＧＰＰ ＴＲ２２．９８０では、いわゆるネットワーク構成に対する実装例が記載されている。この構成は、「アンビエントネットワークプロジェクト（ambient network projects）」内で開発される概念に基づいていて、ここでは、汎用ネットワークアーキテクチャが開発されていて、これには、２つのネットワーク間での汎用化制御機能と標準化リファレンスポイントを含んでいる。この概念は、ネットワーク間で実行される汎用自動ネゴシエーション手順を含んでいて、これについては、例えば、アンビエントネットワークの刊行物である、２００６年１１月のＤ３−Ｇ．１「構成フレームワークの設計」で参照され、http://www.ambient-networks.org/deliverables.htmlで利用可能である。しかしながら、自動ローミング協定ネゴシエーションについての一般的な状況が議論される一方で、ＩＭＳネットワーク間のローミング協定に対して実際に利用可能なソリューションは提供されていない。

事実、ＩＭＳネットワーク間のローミング協定に対する自動確立手順を実現可能にするためには、細部に渡って解決すべき様々な問題が残っている。ここでは、特に、以下の問題について検討する。多くの場合、ＩＭＳネットワークは、別のＩＭＳネットワークからのＰ−ＣＳＣＦに対して取り得る接続点として複数のＩ−ＣＳＣＦを備えることになる。例えば、負荷均衡、信頼性等の理由のために、複数のＩ−ＣＳＣＦが提供される場合がある。Ｉ−ＣＳＣＦに対して問い合わせを行うＰ−ＣＳＣＦは、例えば、ラウンドロビンスキームに従ってこれらの複数のＩ−ＣＳＣＦの１つに割り当てられることになる。

しかしながら、上述で議論される状況の直接的な拡張では、特定のローミング協定は複数のＩ−ＣＳＣＦから１つの特定のＩ−ＣＳＣＦによって処理されることになる。この場合、Ｐ−ＣＳＣＦに提供されるＩ−ＣＳＣＦのアドレスのＩ−ＣＳＣＦは、多くの場合、対応するローミング協定の処理を担当するＩ−ＣＳＣＦとはならない。これは、矛盾した行動を招く結果となる。例えば、連絡するＩ−ＣＳＣＦは、１つのローミング協定が整備されているという事実があるにも関わらず、ローミング協定を確立することを試行する場合があり、同時に存在する複数のローミング協定は互いに一致しない可能性があり、そうすることで、１つのＱｏＳあるいは他のＱｏＳを備えるサービスがローミングユーザに対して無作為な機会で提供されてしまう等ということが生じる。２つのＩＭＳネットワーク間の複数のローミング協定の平行セットアップ及びメンテナンスの少なくとも一方を伴う可能性のある複雑な状況も、ローミング協定の管理時に関与するノード群のすべてにおいて膨大な処理のリソース使用を招き、また、ローミングユーザ群へサービスを提供する場合での時間遅延を生じさせることになる。

１つのＩＭＳネットワークが、Ｉ−ＣＳＣＦ群のような複数のプロキシノードをサポートする場合に２つのＩＭＳネットワーク間のローミング協定を首尾一貫していてかつ効率的に管理するための技術の要望が存在する。

この要望は、第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理する第１の方法によって満足させられる。この第１の方法は、前記第１のＩＭＳネットワークの第１のエッジプロキシで実行され、この第１の方法は、第２のＩＭＳネットワークを介して、ユーザ端末の登録リクエストを受信するステップと、前記登録リクエストに基づいて、前記第２のＩＭＳネットワークを示すローミング情報リクエストを、前記第１のＩＭＳネットワークと関連付けられているユーザデータベースへ送信するステップと、前記ローミング情報リクエストに応じて、前記ユーザデータベースから、前記ローミング協定に関連する情報を示すローミング情報回答を受信するステップと、前記ローミング情報回答に基づいて、前記登録リクエストを、前記第１のＩＭＳネットワークの第２のエッジプロキシへ転送するステップとを備え、前記第２のエッジプロキシは、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間の前記ローミング協定を管理している。

エッジプロキシ群の内の任意のエッジプロキシは、インターロゲイティング呼状態制御機能である「Ｉ−ＣＳＣＦ」、相互接続境界制御機能である「ＩＢＣＦ」、あるいはセッション境界ゲートウェイである「ＳＢＧ」として実現されても良い。

上述の要望は、第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理する第２の方法によって更に満足させられる。この第２の方法は、前記第１のＩＭＳネットワークに関連付けられているユーザデータベースで実行され、この第２の方法は、前記第１のＩＭＳネットワークの第１のエッジプロキシから、第２のＩＭＳネットワークを示すローミング情報リクエストを受信するステップと、前記ローミング情報リクエストに応じて、前記第１のエッジプロキシへ、前記ローミング協定に関連する情報を示すローミング情報回答を送信するステップとを備える。前記ユーザデータベースは、ホーム加入者サーバである「ＨＳＳ」として実現されても良い。

第１の方法及び第２の方法の１つあるいは両方に従えば、前記ローミング情報回答は、前記第２のエッジプロキシを示していても良い。前記ローミング情報回答は、前記動的ローミング協定の状態の指示を含んでいても良い。例えば、前記自動的に確立されているローミング協定は、満了期間を有する動的ローミング協定であっても良く、ここで、前記ローミング協定の状態は、例えば、「準備中」、「確立済」、あるいは「満了済」の１つであっても良い。

第１の方法の実装は、前記登録リクエストの受信後で、かつ前記ローミング情報リクエストの送信前に、前記登録リクエストを前記第１のＩＭＳネットワークのユーザレジスタへルーティングするための許可をリクエストするルーティング許可リクエストを、前記ユーザデータベースへ送信するステップと、前記ルーティング許可リクエストに応じて、前記リクエストされた許可を拒否するルーティング許可応答を前記ユーザデータベースから受信するステップとを備え、前記ローミング情報リクエストは、前記受信するルーティング許可応答に応じて、前記ユーザデータベースへ送信される。

前記ユーザレジスタは、サービング呼状態制御機能である「Ｓ−ＣＳＣＦ」として実現されても良い。この実装の一変形に従えば、前記ルーティング許可リクエストと前記ローミング情報リクエストとを含む１つのメッセージが前記ユーザデータベースへ送信される。前記１つのメッセージは、例えば、Ｄｉａｍｅｔｅｒユーザ認証リクエストコマンドを表していても良い。加えてあるいは選択的には、ルーティング許可応答ではなく、ローミング情報回答だけが、前記ユーザデータベースから受信される。

第２の方法の実装は、前記受信するルーティング許可リクエストに基づいて、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間に永久的なローミング協定が存在するかどうかを判定するステップを備える。ここで、前記ルーティング許可応答は、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間に永久的なローミング協定が存在しないことによって、送信される。

第１の方法及び第２の方法の１つあるいは両方に従えば、前記ローミング情報回答は、オプションとして、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間にローミング協定を確立するためのローミング協定テンプレートを含んでいても良い。加えてあるいは選択的には、前記第１のエッジプロキシと前記ユーザデータベースとの間の通信は、Ｄｉａｍｅｔｅｒメッセージ群に基づいていても良い。

上述の要望は、第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理する第３の方法によって満足させられる。この第３の方法は、前記第１のＩＭＳネットワークの第２のエッジプロキシで実行され、この第３の方法は、前記第１のＩＭＳネットワークの第１のエッジプロキシからユーザ端末の登録リクエストを受信するステップを備え、ここで、前記登録リクエストは、第２のＩＭＳネットワークを介して前記第１のエッジプロキシによって受信され、かつ前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間の前記ローミング協定を管理する前記第２のエッジプロキシへ転送される。

また、上述の要望は、コンピュータプログラムによって満足させられ、これは、１つ以上のコンピュータ装置においてコンピュータプログラムが実行される場合に本明細書で説明される方法の態様及び上述の方法群の１つ以上の方法のステップ群を実行するプログラムコード部分を含んでいて、コンピュータ装置には、例えば、エッジプロキシ、ユーザデータベース及びユーザデータベースがある。コンピュータプログラムは、コンピュータ可読記憶媒体に記憶されても良く、これには、例えば、コンピュータ装置内のあるいはそれに関連付けられている固定のあるいは書換可能なメモリ、あるいはリムーバルＣＤ−ＲＯＭ、ＤＶＤあるいはＵＳＢスティックがある。加えて、あるいは選択的には、コンピュータプログラムは、インターネットのようなデータネットワークを介して、あるいは、電話回線あるいは無線リンクのような通信回線を介して、コンピュータ装置へダウンロードするために提供されても良い。

上述の要望は、更に、第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理するように構成されている第１のエッジプロキシを実現するノードによって更に満足させられる。第２のＩＭＳネットワークを介して、ユーザ端末の登録リクエストを受信するように構成されているコンポーネントと、前記登録リクエストに基づいて、前記第２のＩＭＳネットワークを示すローミング情報リクエストを、前記第１のＩＭＳネットワークと関連付けられているユーザデータベースへ送信するように構成されているコンポーネントと、前記ローミング情報リクエストに応じて、前記ユーザデータベースから、前記ローミング協定に関連する情報を示すローミング情報回答を受信するように構成されているコンポーネントと、前記ローミング情報回答に基づいて、前記登録リクエストを、前記第１のＩＭＳネットワークの第２のエッジプロキシへ転送するように構成されているコンポーネントとを備える。ここで、前記第２のエッジプロキシは、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間の前記ローミング協定を管理している。

前記ノードは、前記登録リクエストを前記第１のＩＭＳネットワークのユーザレジスタへルーティングするための許可をリクエストするルーティング許可リクエストを、前記ユーザデータベースへ送信するように構成されているコンポーネントと、前記ルーティング許可リクエストに応じて、前記リクエストされた許可を拒否するルーティング許可応答を前記ユーザデータベースから受信するように構成されているコンポーネントとを備えていても良い。前記ノードは、前記ルーティング許可リクエストと前記ローミング情報リクエストとを含む１つのメッセージを前記ユーザデータベースへ送信するように構成されていても良い。

更に、また、上述の要望は、第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理するように構成されていて、前記第１のＩＭＳネットワークに関連付けられているユーザデータベースを実現するノードによって満足させられる。前記ノードは、前記第１のＩＭＳネットワークの第１のエッジプロキシから、第２のＩＭＳネットワークを示すローミング情報リクエストを受信するように構成されているコンポーネントと、前記ローミング情報リクエストに応じて、前記第１のエッジプロキシへ、前記ローミング協定に関連する情報を示すローミング情報回答を送信するように構成されているコンポーネントとを備える。

このノードは、更に、前記登録リクエストを前記第１のＩＭＳネットワークのユーザレジスタへルーティングするための許可をリクエストするルーティング許可リクエストを、前記第１のエッジプロキシから受信するように構成されているコンポーネントと、前記ルーティング許可リクエストに応じて、前記リクエストされた許可を拒否するルーティング許可応答を前記第１のエッジプロキシへ送信するように構成されているコンポーネントとを備えていても良い。前記ノードは、前記第１のエッジプロキシから送信される、前記ルーティング許可リクエストと前記ローミング情報リクエストとを含む１つのメッセージを受信するように構成されていても良く、かつルーティング許可応答ではなく、ローミング情報回答だけを前記第１のエッジプロキシへ送信するように構成されていても良い。

前記第１のエッジプロキシと前記ユーザデータベースを実現するノード群は、Ｄｉａｍｅｔｅｒプロトコルを使用して互いに通信するように構成されていても良い。

上述の要望は、更に、第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理するように構成されている、第２のエッジプロキシを実現するノードによって更に満足させられる。前記ノードは、前記第１のＩＭＳネットワークの第１のエッジプロキシからユーザ端末の登録リクエストを受信するように構成されているコンポーネントを備え、ここで、前記登録リクエストは、第２のＩＭＳネットワークを介して前記第１のエッジプロキシによって受信され、かつ前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間の前記ローミング協定を管理する前記第２のエッジプロキシへ転送される。

２つのＩＭＳネットワークとの間のローミング協定の自動確立を示すシーケンス図である。 ＩＭＳネットワークにおける訪問ユーザの登録試行の処理を示すフロー図である。 ＩＭＳネットワークの訪問ユーザの登録試行の処理に関連するメッセージシーケンスを示すメッセージシーケンス図である。 ローミング情報リクエストメッセージに含まれるＩＥの実施形態を示す図である。 ローミング情報回答メッセージに含まれるＩＥ群の実施形態を示す図である。 図３の第１のＩ−ＣＳＣＦの機能ブロック図である。 図５のＩ−ＣＳＣＦの動作を示すフロー図である。 図５のＨＳＳの機能ブロック図である。 図７のＨＳＳの動作を示すフロー図である。 図３の第２のＩ−ＣＳＣＦの機能ブロック図である。 図９のＩ−ＣＳＣＦの動作を示すフロー図である。

以下の実施形態では、説明の目的のためであって、限定する目的ではない、特定の詳細について説明する。これには、専用のネットワーク構造、シグナリングプロトコル等があり、これによって、本発明の全体理解を提供する。これらの特定の態様から離れている他の実施形態で本発明を実施することができることは当業者には明らかであろう。

例えば、特定のＩＭＳ環境は、以下の本発明を説明するために導入され、ここでは、エッジプロキシ機能がインターロゲイティング呼状態制御機能である「Ｉ−ＣＳＣＦ」上で実現され、ユーザデータベースは、ホーム加入者サーバである「ＨＳＳ」上で実現され、ユーザレジスタがサービング呼状態機能である「Ｓ−ＣＳＣＦ」で実現され、そして、ユーザプロキシがプロキシ呼状態制御機能である「Ｐ−ＣＳＣＦ」で実現される。しかしながら、本発明は、他の機能エンティティ群あるいはノード群上で実現されても良いことが理解されるべきである。より一般的なＩＭＳ／ＳＩＰ環境を参照すると、例えば、（ＳＩＰ）エッジプロキシ機能は、Ｉ−ＣＳＣＦ上で実現されても良いばかりか、追加的にあるいは選択的に、相互接続境界制御機能である「ＩＢＣＦ」、あるいはセッション境界ゲートウェイである「ＳＢＧ」上で実現れても良い。既存のあるいは将来のＳＩＰ実装に依存して、また、ユーザデータベースの役割に依存して、ユーザレジスタ及びユーザプロキシの少なくとも一方は、１つ以上の適切なノード群でそれぞれ実現されても良い。

以下で説明する機能群が、個別のハードウェア回路を使用して、プログラム化マイクロプロセッサあるいは汎用コンピュータと協働するソフトウェア機能を使用して、特定用途集積回路（ＡＳＩＣ）を使用して、１つ以上のデジタル信号プロセッサ（ＤＳＰ）を使用して、実現されても良いことを、当業者は更に理解するであろう。本発明が方法として記載される場合、その方法も、コンピュータプロセッサ及びプロセッサに接続されているメモリで実施することができることも理解されるであろう。ここで、メモリには、プロセッサによって実行される場合に、本明細書で開示される方法を実行する１つ以上のプログラムがエンコードされている。

図面に関しては、２つ以上の図に示されるエンティティ群は同一の参照番号によって参照することに注意されたい。

図１は、どのようにしてローミング協定（ＲＡ：roaming agreement）が、２つのＩＭＳネットワーク１０２とＩＭＳネットワーク１０４との間で自動的に確立することができるかの例示の状況を詳細に示している。ユーザ機器であるＵＥ＿Ｂ１１６は、ＩＭＳネットワーク１０２の加入者である。ＵＥ＿Ｂ１１６は、ＩＭＳネットワーク１０４を訪問している。ＵＥ１１６の観点からは、ネットワーク１０２はＩＭＳネットワークＢとしても参照され、ネットワーク１０４はＩＭＳネットワークＡとしても参照される。図１に示されるエンティティ群は、ＩＭＳネットワークＢのＩ−ＣＳＣＦ＿Ｂ１０６、Ｓ−ＣＳＣＦ＿Ｂ１０８及びＨＳＳ＿Ｂ１１０と、ＩＭＳネットワーク１０４ＡのＩ−ＣＳＣＦ＿Ａ１１２及びＰ−ＣＳＣＦ＿Ａ１１４である。

ＵＥ＿Ｂ１１６は、自身のホームネットワーク１０２のＩＭＳサービスへのアクセスを要望する。しかしながら、ＩＭＳネットワーク１０２とＩＭＳネットワーク１０４との間には、永久的な（静的な）ローミング協定は整備されていない。図１は、自動的に確立される（動的な）ローミング協定が存在していない場合において、ＵＥ＿Ｂ１１６の登録の試行によって自動的な確立がトリガーされる時点を示している。Ｄｉａｍｅｔｅｒ及びＳＩＰプロトコルは、図１と以下の図に示されるコンポーネント群との間のシグナリングのために使用されると想定する。

ステップ１５０では、加入者ＵＥ＿Ｂは、自身のホームネットワーク１０２への登録を試行し、それゆえ、登録メッセージを、訪問先ネットワーク１０４のＰ−ＣＳＣＦ＿Ａ１１１４へ送信する。Ｐ−ＣＳＣＦ＿Ａ１１４は、登録メッセージを転送するためのホームネットワーク１０２のＩ−ＣＳＣＦとしてＩ−ＣＳＣＦ１０６を判定する。ネットワーク１０４と通信するためのＩ−ＣＳＣＦ＿Ｂ１０６だけではなく、ネットワーク１０２で利用可能なより多くのＩ−ＣＳＣＦが存在していても良い。しかしながら、自動ローミング協定確立の処理を明確に示すために、図１では、Ｉ−ＣＳＣＦ＿Ｂ１０６のみが示されている。ネットワーク１０２に複数のＩ−ＣＳＣＦが存在する場合のローミング協定管理の場合については、以下で詳細に説明する。

ステップＳ１５２では、Ｐ−ＣＳＣＦ＿Ａ１１４が登録メッセージをＩ−ＣＳＣＦ＿Ｂ１０６へ転送する。ステップＳ１５２の転送の詳細は、例えば、Ｉ−ＣＳＣＦ１０６のＩＰアドレスを収集し、ネットワーク１０４とネットワーク１０２との間のネットワークレベルでの保護チャネルが存在することは当業者には知られており、そのため、ここでは省略する。ステップ１５４では、Ｉ−ＣＳＣＦ＿Ｂ１０６は、登録リクエストをＳ−ＣＳＣＦ＿Ｂ１０８へ転送するかどうかを決定するために、ネットワーク１０４にローミング協定が存在するかどうかをチェックする。図１の×印で示されるように、ステップ１５４では、Ｉ−ＣＳＣＦ＿Ｂ１０６は、ネットワーク１０２とネットワーク１０４との間にはまだ実施中のローミング協定がないと判定しているとする。つまり、ＵＥ＿Ｂ１１６は、自身のホームネットワーク１０２に登録することができない。

ＵＥ−Ｂ１１６の登録の試行の失敗をトリガーにして、ステップ１５６では、ネットワーク１０２のエンティティ１０６と、ネットワーク１０４のエンティティ１１２はそれぞれ、少なくとも特定の加入者１１６に対して有効なローミング協定をネゴシエートする。ステップ１５６でのネゴシエーションは、１回以上の周期となり得る提案／回答手順から構成されていても良い。

Ｉ−ＣＳＣＦ１０６とＩ−ＣＳＣＦ１１２は、通常は、ＩＭＳネットワーク１０２とＩＭＳネットワーク１０４との間の第１の接続点となり、それゆえ、ステップ１５６におけるネゴシエーション相手（パートナ）を形成する。別の実施形態では、ローミング協定の自動確立に関連するネゴシエーション機能あるいは同様の機能は、追加的あるいは選択的に、ＩＭＳネットワークの他のノード群に配置されていても良い。例えば、このような機能は、ホームＩＭＳネットワークのＳ−ＣＳＣＦに配置されていても良く、これは、訪問先ネットワーク内のＰ−ＣＳＣＦとのローミング協定をネゴシエートすることができる。他の例では、そのような機能は、アプリケーションサーバ内あるいは専用ノード内に配置されていても良い。そのような実施形態では、Ｉ−ＣＳＣＦは、シグナリング、例えば、登録リクエストを専用ノードへ中継することができる。しかしながら、例えば、ステップ１５６でネゴシエートされるローミング協定がローミングユーザ１１６に対して提供されるばかりかネットワーク１０４内をローミングしている他のユーザ群にも提供される場合を想定すると、自動ローミング協定確立手順に対してネットワーク群のＩ−ＣＳＣＦ群を使用することは、有効である。

ローミング協定に当事者同士が同意する場合、ステップ１５８では、ＯＫメッセージが送信され、ステップ１６４では、確認応答（ＡＣＫ）メッセージを返信することで、ネゴシエーションフェーズ１５６を完了する。図１では、ＯＫメッセージが訪問先ネットワークからホームネットワークへ送信されていることが示されているが、ＯＫメッセージはホームネットワークから訪問先ネットワークへ送信することもでき、また、ＡＣＫメッセージは訪問先ネットワークからホームネットワークへ送信することもできることに注意されたい。

ステップＳ１６０及びステップＳ１６６によって示されるように、ネゴシエートされたローミング協定は対応するＩ−ＣＳＣＦ１０６とＩ−ＣＳＣＦ１１２へそれぞれ記憶され、また、対応するユーザデータベース群にも記憶され、ここでは、ＨＳＳ１１０におけるローミング協定を記憶するステップ１６２だけが、図１で示されている。ステップ１６８では、ステップＳ１５２において、（永久的なあるいは動的な）ローミング協定が既に実施されていると想定する場合に実行される方法と同様の方法で、ユーザＵＥ＿Ｂ１１６を登録するための手順が実行される。

ステップ１５６でネゴシエートされるローミング協定は、ユーザ１１６のユーザアイデンティティあるいはユーザグループのユーザアイデンティティを含むことができる。ローミング協定は、更に、ローミングユーザがアクセスすることが許可されるサービス群を示すことができ、これには、可能であれば、所定のＱｏＳ特性、及びＩＭＳドメイン１０２とＩＭＳドメイン１０４との間のセッションをセットアップし、また、解消するために要求される技術パラメータ群を含んでいる。このようなパラメータ群は、例えば、最大帯域幅、データ量等に関連していても良く、また、可能であれば、ローミング協定の満了日時に関連していても良い。また、一般的には、ローミングユーザは自身のホームネットワークからサービスをリクエストすることができるが、ステップ１５６で示されるような自動ネゴシエーションは、ローミングしている加入者が訪問先ネットワークのサービス群を使用しても良いという協定を備えることもできる。

図１のローミング協定が確立した後は、そのローミング協定は、訪問先ネットワーク１０４を介して自身のホームネットワーク１０２への登録を試行する他のユーザに対しても（また、ネットワーク１０２をローミングしているネットワーク１０４のユーザに対しても）有効とすることができる。そのローミング協定がこれらの後続のユーザに対するものとすることができない場合、そのローミング協定は、更なる登録リクエストに応じて構成される、即ち、更新される。ローミング協定の更新手順は、図１のステップ１５６で実行されるネゴシエーションフェーズと同様の更なるネゴシエーションフェーズを含むことができる。更新手順も、他のイベント群、例えば、所定の時点、新規のサービスのプロビジョンあるいはアクティベーション等によってトリガーすることができる。

自動的に確立される（動的な）ローミング協定は、限定された期間あるいは無制限の期間に対して有効にすることができる。ローミング協定に対して満了日時が定義されていない場合でさえも、その終了を導くイベント群が存在していても良い。これには、例えば、ネゴシエートされた最大データ量が送信されている場合、あるいは、訪問先ＩＭＳネットワークが、一定の時点でオフにされる一時的なＩＭＳネットワークである場合がある。

以下の記載は、別のＩＭＳネットワークとの通信のために設計されている複数のＩ−ＣＳＣＦを有するＩＭＳネットワークにおけるローミング協定の管理に着目する。多くても、１つのローミング協定が任意の２つのＩＭＳネットワークとの間で実施されているべきであると想定する。原理的には、他の構成設定（コンフィグレーション）も可能であっても良い一方で、更なる課題が首尾一貫していてかつ効率的にローミングユーザにサービスを提供することに関するそのような構成設定において生じる可能性がある。

図２は、指定された複数のＩ−ＣＳＣＦを有するＩＭＳネットワークにおけるローミング協定を管理する一般的な方法の実施形態を示している。図３に従う手順は、ＩＭＳネットワークのＩ−ＣＳＣＦあるいは同様のエッジプロキシノードで実現されても良い。ステップ２０２では、Ｉ−ＣＳＣＦは、訪問先ネットワークのＰ−ＣＳＣＦによって転送される登録試行をローミングユーザから受信する。登録試行の受信は、ステップ２０４では、Ｉ−ＣＳＣＦがＨＳＳあるいは同様のユーザデータベースからの通常の（永久的な）ローミング協定に関する情報をリクエストすることをトリガーする。ＨＳＳは、通常のローミング協定が存在するかどうかの指示をＩ−ＣＳＣＦへ提供し、これは、登録試行を発信しているユーザが訪問先ネットワークへローミングすることを可能にする。通常のローミング協定は、例えば、図２のＩ−ＣＳＣＦが属するネットワークの任意のユーザ及びどんな時間のいずれか一方に対して有効とすることができる。そのような場合、通常のローミング協定（ＲＡ）が存在し、ステップ２０６では、ユーザ２０２の登録が実行され、例えば、Ｉ−ＣＳＣＦが登録試行を適切なＳ−ＣＳＣＦへ転送することになる。

図３に示される手順に従えば、永久的なあるいは通常のローミング協定が存在しない場合、Ｉ−ＣＳＣＦは登録を拒否しないかわりに、ＨＳＳあるいはユーザデータベースとの更なるメッセージ交換２０８を実行する。具体的には、Ｉ−ＣＳＣＦは、関係するネットワークとの間に動的なローミング協定が存在するかどうかを示す情報をＨＳＳからリクエストする。次に、Ｉ−ＣＳＣＦの更なる動作がＨＳＳからの回答に依存する。動的なローミング協定が存在しない場合、ステップ２１０では、Ｉ−ＣＳＣＦは、訪問先ネットワークとの動的なローミング協定のネゴシエーションを開始する。このネゴシエーションは、図１に示されるＩ−ＣＳＣＦ１０６のネゴシエーションフェーズ１５６に関して説明されるように発生する。但し、動的なローミング協定が既に存在する場合、ステップ２１２では、Ｉ−ＣＳＣＦは、ステップ２０２で受信される登録試行を、現在のローミング協定の処理を担当するＩ−ＣＳＣＦへ転送するように動作する。

図２の手順は自動的に確立されるローミング協定に対して適用されるように記載されているが、原理的には、手動で確立されるローミング協定に対しても適用可能である。

図３は、図２で概略されている手順の特定の実施形態の詳細を示している。これまでのように、この手順は、複数のＩ−ＣＳＣＦを備える自身のホームネットワークにおける訪問ユーザの登録試行の処理に関連する。図３の例示の状況は、図１で導入されている、ホームＩＭＳネットワーク１０２と訪問先ＩＭＳネットワーク１０４とを参照する。上述で既に説明されるこれらのエンティティ群とは別に、ホームネットワーク１０２は更なるＩ−ＣＳＣＦ３０２を備えるように示されている。ＤＮＳサーバ３０４は、訪問先ネットワーク１０４に関連付けられている。ユーザ機器（ＵＥ）３０６のユーザは、ネットワーク１０２に加入していて、かつ訪問先ネットワーク１０４に存在している。

例示の目的のために、以下では、図１の手順は、時間的により早く実行されている、即ち、ローミング協定はホームネットワーク１０２と訪問先ネットワーク１０４との間で確立されていると想定することとし、ここで、Ｉ−ＣＳＣＦ１０６とＩ−ＣＳＣＦ１１２はローミング協定を担当していて、かつ対応する進行中のＳＩＰダイアログ３０８に関与している。このＳＩＰダイアログ３０８は、ローミング協定が存在する限り存在し続ける。

ステップ３１０では、ＵＥ３０６は、ＳＩＰ登録メッセージを訪問先ネットワーク１０４のＰ−ＣＳＣＦ１１４へ送信する。ステップ３１２では、ＵＥ３０６のホームネットワーク１０２と接続するために、Ｉ−ＣＳＣＦの指示に対するクエリをＤＮＳサーバ３０６へ送信する。複数のＩ−ＣＳＣＦがホームネットワーク１０２で利用可能であるため、即ち、エンティティ群１０６と３０２、及び可能であればより多くのＩ−ＣＳＣＦがホームネットワーク１０２で利用可能であるため、ＤＮＳサーバ３０４は、例えば、ラウンドロビンメカニズムに基づいて、Ｉ−ＣＳＣＦのアドレスを返信することで、ネットワーク１０２の複数のＩ−ＣＳＣＦ間の負荷均衡を保障する。図３の構成設定の例では、ステップ３１４では、ＤＮＳサーバ３０４は、Ｉ−ＣＳＣＦのアドレスをＰ−ＣＳＣＦ１１４へ提供することで応答して、これに応じて、ステップ３１６では、Ｐ−ＣＳＣＦ１１４は、ＵＥ３０６の登録メッセージをＩ−ＣＳＣＦ３０２へ転送する。このメッセージの受信は、図２のステップ２０２に対応する。

図３のネットワーク１０２の例に基づいて、複数のＩ−ＣＳＣＦを備えるネットワークで発生し得る課題が示される。動的ローミング協定は、ネットワーク１０２とネットワーク１０４との間でネゴシエートされている。特に、Ｉ−ＣＳＣＦ１０６は、ＳＩＰダイアログ３０８による動的ローミング協定を維持することを担当する。但し、訪問先ネットワーク１０４からの登録試行を受信するＩ−ＣＳＣＦは、２つのネットワーク１０２とネットワーク１０４との間の既存のローミング協定に関係するＩ−ＣＳＣＦ１０６とは異なる別のものであっても良い。このような設定構成は、例えば、１つの境界ゲートウェイの概念を実現することによって回避することができる。図３を参照すると、例えば、Ｐ−ＣＳＣＦ１１４は、任意の登録試行をＩ−ＣＳＣＦ１０６へ送信するように構成設定されていても良い。このような構成設定では、負荷均衡がホームネットワーク１０２で内部的に実現されていなければならないであろう。但し、本明細書で説明される技術に従えば、より柔軟でかつ効率的な別の方法が提案される。

ステップ３２０での登録試行の受信時に、Ｉ−ＣＳＣＦ３０２は、ローミング協定について利用可能な情報と、ネットワーク１０２とネットワーク１０４との間のローミング協定のステータスを有していない、これは、ローミング協定がＩ−ＣＳＣＦ１０６でのみ処理されるからである。ステップ３２０では、Ｉ−ＣＳＣＦは、ＨＳＳ１１０から、ユーザ３０６にネットワーク１０４内をローミングすることを許容する、ネットワーク１０４との通常のローミング協定が存在するかについての情報をリクエストし、そして、その目的のために、Ｄｉａｍｅｔｅｒユーザ認証リクエスト（ＵＡＲ）コマンドを使用する。ユーザ認証回答（ＵＡＡ）を用いることで、ステップ３２２では、ＨＳＳは、その指示をＩ−ＣＳＣＦ２０４へ提供する。ＵＡＡは、ネットワーク１０４との通常のローミング協定が存在しないことをＩ−ＣＳＣＦ３０２へ指示する。ステップ３２０とステップ３２２では、ＵＡＲ／ＵＡＡメッセージのペアは、図２のステップ２０４を実現する。

図２のステップ２０８に応じて、ステップ３２４では、Ｉ−ＣＳＣＦ２０４は、ＨＳＳ１１０から、ネットワーク１０２とネットワーク１０４との間の動的ローミング協定についての情報をリクエストする。このリクエストは、Ｄｉａｍｅｔｅｒ「ローミング情報リクエスト」（ＲＩＲ）として実現される。ステップ３２６では、ＨＳＳ１１０は、対応するＤｉａｍｅｔｅｒ「ローミング情報回答」（ＲＩＡ）を返信する。ＲＩＲ／ＲＩＡメッセージのペアは、以下で更に詳細に説明する。動的ローミング協定が整備されていると想定されるので、図２のステップ２１２に対応するステップ３２８では、Ｉ−ＣＳＣＦ２０４は、ステップ３１６で受信される登録メッセージを、現在のローミング協定を処理することを担当するＩ−ＣＳＣＦ、即ち、Ｉ−ＣＳＣＦ１０６へ転送するように動作する。

ステップ３３０とステップ３３２では、Ｉ−ＣＳＣＦ１０６とＩ−ＣＳＣＦ１１２は、ユーザ３０６もローミング協定によって網羅されるように、既存のローミング協定の適切な再ネゴシエーションを実行する。ステップ３３４では、Ｉ−ＣＳＣＦ１０６は、ローミング更新リクエスト（ＲＵＲ）メッセージに基づいて、ユーザ２０２に訪問先ネットワーク１０４へローミングすることを可能にする、再ネゴシエーションされたローミング協定をＨＳＳ１１０へ通知する。ステップ３３６では、ＨＳＳ１１０は、ローミング更新回答（ＲＵＡ）に基づいて、ローミング協定に関連するデータの更新の成功を指示する。ステップ３３８では、Ｉ−ＣＳＣＦ１０６は、ステップ３２０のＩ−ＣＳＣＦ３０２によって試行される不成功に終わったＵＡＲを繰り返す。それまでの間、ローミング協定は責任のあるＩ−ＣＳＣＦ１０６によって更新されているので、ステップ３４０では、ＨＳＳ１１０は、ローミングユーザ３０６の登録が許可されていることを示すＵＡＡで応答する。その結果、ステップ３４２では、Ｉ−ＣＳＣＦ１０６は、ステップ３２８で受信される登録メッセージをＳーＣＳＣＦ１０８へ転送する。この登録処理は、更に、通常の方法で継続することになる。

図４ａは、訪問ユーザの登録試行の受信に応じてＩ−ＣＳＣＦからＨＳＳへ、図３のステップ３２４のＲＩＲで送信することができる、情報要素（ＩＥ）を示している。ＩＥ「訪問先ネットワーク識別子」は、ホームネットワーク１０２における訪問先ネットワーク１０４の指示を含むことができる。この情報要素は、必須（「Ｍ」）であっても良い。

図４ｂは、ＨＳＳ１１０からＩ−ＣＳＣＦ３０２へ、図３のステップ３２６のＲＩＡで返信される情報要素群を示している。ＲＩＡは、図２のステップ２０８に関して例示されるような、Ｉ−ＣＳＣＦ３０２の更なる動作を制御することができる、ローミング協定の状態を示す情報要素「ローミング状態」を含むことができる。この状態の指示は、ＲＩＲで指示される訪問先ネットワークに対して既存のローミング協定が存在するかどうかの単なる指示に及ぼさせることができる。取り得る状態の指示は、例えば、「確立済」、「終了済」、「早期」を含むことができる。前者は読んで字の通りである一方で、状態「早期」はローミング協定が現在、同様の予備的なフェーズのネゴシエーションフェーズにあることをを示すことができる。即ち、Ｉ−ＣＳＣＦは既にローミング協定を担当していても良いが、そのローミング協定自身は現在実施されてはいない。

また、ＲＩＡは「ローミングテンプレート」ＩＥを含むことができ、これは、ローミング協定のテンプレートを含むことができるフィールドであり、そして、これは、訪問先ネットワークにおけるインターロゲイティングを行う相手方とのローミング協定のネゴシエーションを開始するために、受信側のＩ−ＣＳＣＦによって使用されることになる（図２のステップ２１０）。更にまた、ＲＩＡは、「ローミングハンドラ」ＩＥを備えることができ、これは、責任のあるＩ−ＣＳＣＦへ登録試行を転送することを可能にするために、その責任のあるＩ−ＣＳＣＦへ指示する。図２の状況の例に対しては、ローミングハンドラＩＥは、ＩＰアドレス、ＳＩＰ ＵＲＩ、あるいは、訪問先ネットワーク１０４とのＳＩＰダイアログ３０８を処理するＩ−ＣＳＣＦ１０６の同様のアドレスを指示する。

図４ｂでは、ローミング状態の情報要素だけが必須のＩＥ（「Ｍ」」）として示されているが、ローミング協定の状態に依存して、他の情報要素群をオプション（「Ｏ」）として含めることができる。他の実装も考慮することができる。例えば、一実装では、ローミング状態のＩＥを利用可能ではないが、ＲＩＡを受信するＩ−ＣＳＣＦは、受信するＩＥ「ローミングテンプレート」あるいは「ローミングハンドラ」からの状態を間接的に決定しなければならない。例えば、ＲＩＡはローミングテンプレートＩＥを含んでいる場合、Ｉ−ＣＳＣＦは、現在ローミング協定が実施されていないことを決定することができるので、ネゴシエーションを開始することになる。ＲＩＡがローミングハンドラＩＥを含んでいる場合、ＩーＣＳＣＦはローミング協定が実施されていて、かつ指示されているＩ−ＣＳＣＦがそのローミング協定を担当していると決定することができる。このようにして、ローミング状態ＩＥは旧来のものとして見られる場合がある。

しかしながら、一実装においては、必須フィールドとしてローミング状態ＩＥを提供することは有効であるということが分かる。例えば、進行中のローミング協定のネゴシエーションの状況について検討する。この状況では、ローミング状態の直接的な知識を、ＲＩＡを受信するＩ−ＣＳＣＦの更なる動作に影響を与える制御入力として使用することができる。例えば、状態「早期」（あるいは「現在ネゴシエーション中」あるいは同様の指示）を受信先のＩ−ＣＳＣＦへ信号送信する場合、一方では、更なるローミング協定を自身で確立することを試行すべきでないが、一方では、登録試行メッセージをネゴシエーションするＩ−ＣＳＣＦへすぐに転送すべきでない。ローミング状態「早期」に対して取り得る応対は、所定時間期間経過した後にＲＩＲのＨＳＳへの送信を繰り返すようにすることができる。その結果、ローミング状態ＩＥの「必須」の包含は、受信される登録試行の適切な処理を保障することである。

ＲＩＲを送信し、ＲＩＡを受信するＩ−ＣＳＣＦがローミング協定の処理を自身で担当する場合、最適化されたシグナリングスキームを採用することができる。これは、このＩ−ＣＳＣＦは既にすべての要求された情報を利用可能となっているからである。例えば、ローミング状態ＩＥだけが必須のＩＥである場合の一実装では、このフィールドは、受信先のＩーＣＳＣＦが、ＲＩＲに含まれる訪問先ネットワークとのローミング協定を自身で担当することを示す特定の値を搬送することができる。

図２及び図３では、Ｉ−ＣＳＣＦとＨＳＳとの間には、２つのメッセージ交換が存在することが示されている。つまり、（図２を参照すると）、ステップ３２０とステップ３２２におけるＵＡＲ／ＵＡＡメッセージのペアと、また、ステップ３２４とステップ３２６におけるＲＩＲ／ＲＩＡメッセージのペアである。２つの別々のメッセージ交換の形式で、Ｉ−ＣＳＣＦとＨＳＳとの間で通信を提供することは、更なる実装の取り組みを最小化し、また、複数のＩ−ＣＳＣＦを採用するＩＭＳネットワークに対して要求される更なる適合を最小化する。これは、この手順が、従来知られているＵＡＲ／ＵＡＡのメッセージ交換を完全にあるいは部分的に変更しないからである。しかながら、ネットワークトラフィック／シグナリングの最小化が更に要望される場合、２つのメッセージ交換に代えて、１つのメッセージ交換だけを実行することができる。例えば、図４ａの情報要素「訪問先ネットワーク識別子」をＵＡＲにも含めることができ、また／あるいはＨＳＳ１１０を、ＵＡＲ内の訪問先ネットワークＩＤの受信に応じて、指示されている訪問先ネットワークとの通常の（永久的な）のローミング協定と動的な（一時的な）ローミング協定の両方を検索するように構成することができる。この場合、ＵＡＡは、図４ｂに示される１つ以上の情報要素を既に含んでいても良い。この方法では、１つのメッセージ交換に節約することができる。

図５は、図３のＩ−ＣＳＣＦ３０２の例示の実装の機能構成図を示している。Ｉ−ＣＳＣＦ３０２は、受信コンポーネント５０２、クエリコンポーネント５０４、応答コンポーネント５０６、及び転送コンポーネント５０８を備えている。Ｉ−ＣＳＣＦ３０４のコンポーネント群は、Ｄｉａｍｅｔｅｒプロトコル及びＳＩＰプロトコルの少なくとも一方に基づいて通信するために構成することができる。一般的には、Ｉ−ＣＳＣＦ３０２は、ＩＭＳネットワーク１０２内で自動的に確立されるローミング協定を管理するように動作する。Ｉ−ＣＳＣＦ３０２の例示の動作を、図６を参照して説明する。ここでは、Ｉ−ＣＳＣＦ３０２の観点から図３の状況を参照する。

ステップ６０２では、受信コンポーネント５０２は、訪問先ネットワーク１０４を介してＵＥ３０２からの登録リクエストを受信する（図３のステップ３１６）。受信コンポーネント５０２は、登録試行に含まれる訪問先ネットワーク識別子をクエリコンポーネント５０４へ提供し、これによって、ステップ６０４では、ルーティング許可リクエスト、より具体的には、ＵＡＲをＨＳＳ１１０へ送信することがトリガーされる（ステップ３２０）。ＵＡＲは、登録リクエストをネットワーク１０２のユーザレジスタへ、より具体的には、Ｓ−ＣＳＣへルーティングするための許可をリクエストする。ステップ６０６では、応答コンポーネント５０６は、ＵＡＲに応じて、ＨＳＳ１１０からのローミング状態回答、より具体的には、ＵＡＡを受信する（ステップ３２２）。ＵＡＡはリクエストされた許可を拒否する。これは、ネットワーク１０２とネットワーク１０４との間で確立される通常のローミング協定が存在しないからである。

ステップ６０８では、クエリコンポーネント５０４は、拒否するＵＡＡに応じて、ＲＩＲをＨＳＳ１１０へ送信するように動作する（図３のステップ３２４）。ＲＩＲは、例えば、図４ａで示されるＩＥに基づいて、訪問先ネットワーク１０４をＨＳＳ１１０へ指示する。ステップ６１０では、応答コンポーネント５０６は、ＲＩＲに応じて、ＲＩＡをＨＳＳ１１０から受信する（ステップ３２６）。ここでは、ＲＩＡは、図４ｂに示される１つ以上のＩＥを含んでいる。ＲＩＡで受信される情報に基づいて、ステップ６１２では、転送コンポーネント５０８は、ステップ６０２で受信される登録リクエストを、更なるＩ−ＣＳＣＦへ、即ち、ＲＩＡで指示されている、ネットワーク１０２のＩ−ＣＳＣＦ１０６へ転送するように動作する。

図７は、図３のＨＳＳ１１０の実装例の機能構成図である。ＨＳＳ１１０は、受信コンポーネント７０２、データベースアクセスコンポーネント７０４、関係データベース７０６、及び応答コンポーネント７０８を備えている。コンポーネント７０２及び７０８は、Ｄｉａｍｅｔｅｒプロトコル及びＳＩＰプロトコルの少なくとも一方に基づく通信のために構成されている。一般的には、ＨＳＳ１１０は、ＩＭＳネットワーク１０２において自動的に確立されるローミング協定の管理に貢献するように動作する。ＨＳＳ１１０の例示の動作を、図８のフロー図を参照して説明する。ここでは、ＨＳＳ１１０の観点から図３の状況を参照する。

ステップ８０２では、Ｉ−ＣＳＣＦ３０２からのＵＡＲが受信コンポーネント７０２によって受信される（図３のステップ３２０）。ＵＡＲの受信に応じて、データベースアクセスコンポーネント７０４は、ネットワーク１０２とネットワーク１０４との間の通常のローミング協定が存在するかを判定するためにアクセスデータベース７０６へアクセスする。本明細書で説明される例では、そのような通常のローミング協定が存在しないので、ステップ８０４では、応答コンポーネント７０８は、訪問ユーザ３０６の登録試行のためのルーティング許可を拒否するＵＡＡメッセージを構築し、そのＵＡＡをＩ−ＣＳＣＦへ返信する（ステップ３２２）。

ステップ８０６では、受信コンポーネント７０２は、Ｉ−ＣＳＣＦ３０２からＲＩＲを受信する（図３のステップ３２４）。ＲＩＲの受信に応じて、データベースアクセスコンポーネント７０４はデータベース７０６にアクセスして、ネットワーク１０２とネットワーク１０４との間の動的ローミング協定が存在するかどうかを判定する。具体的には、アクセスコンポーネント７０４はルックアップテーブル７１０へアクセスする。これについては以下で詳細に説明する。その結果、ステップ８０８では、応答コンポーネント７０８は、ＲＩＡをＩ−ＣＳＣＦ３０２へ提供する。ここで、ＲＩＡは、ローミングハンドラ、即ち、ネットワーク１０２とネットワーク１０４との間の既存の動的ローミング協定を担当するＩ−ＣＳＣＦ１０６を示している。ＲＩＡは、例えば、図４ｂで示されるＩＥ群である「ローミング状態」と「ローミングハンドラ」を含んでいても良い。

図７のルックアップテーブル７１０は、例示のデータレコード群の構造を示していて、これは、動的ローミング協定についての情報に対するリクエストに効率的に応対することをＨＳＳ１１０に実現可能にするためにデータベース７０６に記憶されても良い。ルックアップテーブル７１０におけるデータレコードは、訪問先ネットワーク識別子の指示を表すためのフィールド７１２（「訪問先ネットワークＩＤ」）、動的ローミング協定の指示を表すためのフィールド７１４（「ＲＡ ＩＤ」）、ローミングハンドラを指示するために提供されても良いフィールド７１６（「ローミングハンドラ」）、及び動的ローミング協定の状態を表すために提供されても良いフィールド７１８（「ＲＡ状態」）を含むことができる。更なるフィールド群が実装に依存して提供されても良い。

フィールド７１２の訪問先ネットワークＩＤは、ローミングユーザの登録試行によって配信される訪問先ネットワークの指示に関連していて、即ち、例えば、図４ａに示されるＩＥ「訪問先ネットワーク識別子」の内容に関連していて、これは、ＲＩＲでＨＳＳ１１０に提供される。フィールド７１６におけるローミングハンドラの指示は、例えば、ＩＰアドレス、ＳＩＰ ＵＲＩ、あるいは動的ローミング協定を担当するＩ−ＣＳＣＦを指し示す表示のようなアドレスであっても良い。フィールド７１８は、上述のようなローミング協定の現在の状態に依存する、「早期」あるいは「ネゴシエーション中」、「確立済」、あるいは「存在しない」、「満了済」のような状態を示すことができる。

図７のルックアップテーブル７１０はＨＳＳにＲＩＲに応答することを可能にするデータ構造の一例だけを表している一方で、一般的には、ＨＳＳは、訪問先ネットワーク識別子とローミングハンドラの関係に効率的にアクセスするべきである。ローミングハンドラのＩＰアドレス、ホストＩＤ等は、少なくともローミング協定が実施されている限り存在していても良い。いくつかの実装では、ローミングハンドラのアドレスは、ローミング協定が満了している場合に依然としてアクセスすることができるようにしても良い。例えば、いくつかの構成設定では、他のネットワークとの動的ローミング協定は、常にネゴシエーションされ、かつ１つの同一のＩ−ＣＳＣＦによって維持されていても良い。

別の実装では、動的ローミング情報リクエストに応答するためにアクセスされるテーブルは、ローミング協定のリストを含んでいても良い。これは、各リクエストに対してＨＳＳが各訪問先ネットワークを識別するためにリスト全体をスキャンしなければならないことを要求するものである。しかしながら、このテーブルは、例えば、訪問先ネットワーク識別子に従ってそのテーブルにインデックスを付与することによって効率的に構成設定することができる。このような構造は、図７に示されるような構造７１０に対応するようなものとなる。

図９は、図３のＩ−ＣＳＣＦ１０６の例示の実装の機能構成図を示していて、これは、訪問先ネットワーク１０４のＩ−ＣＳＣＦ１１２との動的なローミング協定をネゴシエートし、かつ維持することを担当する。図９のＩ−ＣＳＣＦ１０６の実装は、受信コンポーネント９０２、ＲＡ更新コンポーネント９０４、ＨＳＳリクエストコンポーネント９０６、及び転送コンポーネント９０８を備えている。Ｉ−ＣＳＣＦ１０６の例示の動作を、図１０を参照して説明する。ここでは、Ｉ−ＣＳＣＦ１０６の観点から図３の状況を参照する。

ステップ１００２では、受信コンポーネント９０２は、ネットワーク１０２のＩ−ＣＳＣＦ３０２から登録試行を受信する（図３のステップ３２８）。登録試行の受信に応じて、更新コンポーネント９０４は、ネットワーク１０２とネットワーク１０４との間で実施する動的ローミング協定の再ネゴシエーションを実行する（ステップ３３０、３３２）。再ネゴシエーションの成功後、ステップ１００６では、コンポーネント９０６は、再ネゴシエーションされたローミング協定をＨＳＳ１１０へ指示する（ステップ３３４、３３６）。また、コンポーネント９０６は、図３のステップ３３８及び３４０に示される手順に従って動的ローミング協定に関する情報を、ＨＳＳ１１０からリクエストするように動作する。ステップ１００８では、コンポーネント９０８は、ステップ１００２で受信される登録試行をＳ−ＣＳＣＦ１０８へ転送する（図２参照）。

従来のＩＭＳネットワーク実装では、通常は、Ｓ−ＣＳＣＦだけがステートフルである一方で、本明細書で提案される技術に従えば、Ｉ−ＣＳＣＦも、動的ローミング協定に関してステートフルとなる。一般的には、動的ローミング協定をネゴシエートしかつ維持することを担当するＩ−ＣＳＣＦがステートフルに構成設定されること、即ち、他のネットワークとネゴシエートされるローミング協定の詳細を覚えておき、そして、ローミング協定の現在の状態に関する情報へのアクセスを有することが提案される。例えば、ネットワーク１０２とネットワーク１０４との間の動的ローミング協定を担当する、図３のＩ−ＣＳＣＦ１０６はステートフルであり、これは、動的ローミング協定の追跡を行い、そして、ネットワーク１０４の対応するＩ−ＣＳＣＦ１１２との対応のＳＩＰダイアログを維持する。

任意の２つのＩＭＳネットワークとの間に多くても１つの動的ローミング協定が存在し、かつ、１つの特定のＩ−ＣＳＣＦがネットワークの動的ローミング協定を担当することが本明細書で提案されるので、そのネットワーク内の別のＩ−ＣＳＣＦはローミングユーザからの登録試行の受信に対して首尾一貫して応対することができない。その理由は、このＩ−ＣＳＣＦがローミング協定の状態についての情報を有していない、即ち、そのようなＲＡが存在しているかあるいは確立されるべきであるかがわからないからである。例えば、図３のＩ−ＣＳＣＦ３０２は、登録試行がステップ３２０で受信される時に利用可能な任意の状態情報を有していない。それゆえ、Ｉ−ＣＳＣＦ３０２は、通常のローミング協定が実施されていないことをＨＳＳ１１０がステップ３２２で公表した後に、正しく登録試行を処理することができない。

このような理由のために、登録試行を受信するＩ−ＣＳＣＦは、動的ローミング協定に関する情報を受信することを実現可能にしなければならない。これに関しては、上述の例示の実施形態では、ＲＩＲ／ＲＩＡメッセージのペアが導入される。ＲＩＡに含まれる情報は、Ｉ−ＣＳＣＦに、（実装に依存して）動的ローミング協定をネゴシエートすることを開始すること、あるいは動的ローミング協定を担当するＩ−ＣＳＣＦに登録試行を転送することを実現可能にする。この後者のＩ−ＣＳＣＦは、それに従ってローミング協定を再ネゴシエートすることができる。つまり、所与の動的ローミング関係に関与するすべての登録試行は、特定のＩ−ＣＳＣＦへ到達することができ、これは、ローミング協定の効率的な処理を実現可能にする一方で、他方では、ローミング協定に関連するユーザ登録の効率的な処理を実現可能にする。

本明細書で記載される例示の実施形態では、Ｉ−ＣＳＣＦはローミング協定の管理を担当する一方で、一般的には、提案される機能は、任意の適切なノードで実現することができ、これには、即ち、任意のＳＩＰプロキシ、エッジプロキシ、ＳＩＰプロキシサーバ、境界プロキシサーバ等を選択することができる。

本明細書で提案される技術は、ＩＭＳネットワーク間のローミング協定の自動確立を実現するための包括的なネットワークに貢献する。提案される技術は、ローミング協定の首尾一貫した管理を実現することができる。通常のあるいは永久的なローミング協定に対して知られているあるいは議論されている技術は、広範囲に再使用することができる。

提案される技術を採用する場合、他のＩＭＳネットワーク群と通信するために、最初に、１つだけのＩ−ＣＳＣＦあるいはエッジプロキシを有するＩＭＳネットワークは、容易に複数のＩ−ＣＳＣＦに拡張することができる。また、提案される技術は、ノード間の処理リソースの使用及びネットワークトラフィックを最小化することに貢献する。既存の手順に対する最適化は本明細書でも示されており、これらは、ネットワークトラフィック及び処理リソース使用の少なくとも一方の最小化に更に貢献することができる。並行して行うローミング協定及びローミング協定の責任を他のノード群へ移行することの少なくとも一方を伴う複雑な状況を回避することができる。提案される技術を実現するために、確立すべき新規のノードは必要とされない。

本発明はそれ自身の実施形態に関連して説明されているが、この説明は例示の目的だけのものであることが理解されるべきである。従って、本発明は、添付の請求項の範囲によってのみ制限されることが意図される。

Claims (23)

1. 第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理する方法として、前記第１のＩＭＳネットワーク（１０２）の第１のエッジプロキシ（３０２）で実行される方法であって、
   第２のＩＭＳネットワーク（１０４）を介して、ユーザ端末（３０６）の登録リクエストを受信するステップ（２０３、３１６、６０２）と、
   前記登録リクエストに基づいて、前記第２のＩＭＳネットワークを示すローミング情報リクエストを、前記第１のＩＭＳネットワーク（１０２）と関連付けられているユーザデータベース（１１０）へ送信するステップ（２０８、３２４、６０８）と、
   前記ローミング情報リクエストに応じて、前記ユーザデータベース（１１０）から、前記ローミング協定に関連する情報を示すローミング情報回答を受信するステップ（２０８、３２６、６１０）と、
   前記ローミング情報回答に基づいて、前記登録リクエストを、前記第１のＩＭＳネットワーク（１０２）の第２のエッジプロキシ（１０６）へ転送するステップ（２１２、３２８、６１２）とを備え、
   前記第２のエッジプロキシ（１０６）は、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間の前記ローミング協定を管理している
   ことを特徴とする方法。
2. 第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理する方法として、前記第１のＩＭＳネットワーク（１０２）に関連付けられているユーザデータベース（１１０）で実行される方法であって、
   前記第１のＩＭＳネットワークの第１のエッジプロキシ（３０２）から、第２のＩＭＳネットワーク（１０４）を示すローミング情報リクエストを受信するステップ（３２４、８０６）と、
   前記ローミング情報リクエストに応じて、前記第１のエッジプロキシ（３０２）へ、前記ローミング協定に関連する情報を示すローミング情報回答を送信するステップ（３２４、８０６）とを備え、
   ユーザ端末の登録リクエストが第２のＩＭＳネットワークを介して前記第１のエッジプロキシ（３０２）によって受信され、かつ前記ユーザ端末の登録リクエストは、前記ローミング情報回答に基づいて、前記第１のＩＭＳネットワーク（１０２）の第２のエッジプロキシ（１０６）へ転送され、
   前記第２のエッジプロキシ（１０６）は、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間の前記ローミング協定を管理している
   ことを特徴とする方法。
3. 前記ローミング情報回答は、前記第２のエッジプロキシ（１０６）を示している
   ことを特徴とする請求項１または２に記載の方法。
4. 前記自動的に確立されているローミング協定は、満了期間を有する動的ローミング協定であり、
   前記ローミング情報回答は、前記動的ローミング協定の状態の指示を含んでいる
   ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記登録リクエストを受信するステップの後で、かつ前記送信するステップの前に、
   前記登録リクエストを前記第１のＩＭＳネットワーク（１０２）のユーザレジスタ（１０８）へルーティングするための許可をリクエストするルーティング許可リクエストを、前記ユーザデータベース（１１０）へ送信するステップ（２０４、３２０、６０４）と、
   前記ルーティング許可リクエストに応じて、前記リクエストされた許可を拒否するルーティング許可応答を前記ユーザデータベース（１１０）から受信するステップ（２０４、３２２、６０６）とを備え、
   前記ローミング情報リクエストは、前記受信するルーティング許可応答に応じて、前記ユーザデータベース（１１０）へ送信される
   ことを特徴とする請求項１に記載の方法。
6. 前記ルーティング許可リクエストと前記ローミング情報リクエストとを含む１つのメッセージが前記ユーザデータベースへ送信される
   ことを特徴とする請求項５に記載の方法。
7. 前記１つのメッセージは、Ｄｉａｍｅｔｅｒユーザ認証リクエストコマンドを表している
   ことを特徴とする請求項６に記載の方法。
8. ルーティング許可応答ではなく、ローミング情報回答だけが、前記ユーザデータベースから受信される
   ことを特徴とする請求項５乃至７のいずれか１項に記載の方法。
9. 受信するルーティング許可リクエストに基づいて、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間に永久的なローミング協定が存在するかどうかを判定するステップを更に備え、
   ルーティング許可応答が、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間に永久的なローミング協定が存在しないことによって、送信される
   ことを特徴とする請求項２に記載の方法。
10. 前記ローミング情報回答は、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間にローミング協定を確立するためのローミング協定テンプレートを含んでいる
    ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. 前記第１のエッジプロキシ（３０２）と前記ユーザデータベース（１１０）との間の通信は、Ｄｉａｍｅｔｅｒメッセージ群に基づいている
    ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
12. 第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理する方法として、前記第１のＩＭＳネットワーク（１０２）の第２のエッジプロキシ（１０６）で実行される方法であって、
    前記第１のＩＭＳネットワーク（１０２）の第１のエッジプロキシ（３０２）からユーザ端末の登録リクエストを受信するステップ（３２８、１００２）を備え、
    前記登録リクエストは、第２のＩＭＳネットワーク（１０４）を介して前記第１のエッジプロキシによって受信され、かつ前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間の前記ローミング協定を管理する前記第２のエッジプロキシ（１０６）へ転送される
    ことを特徴とする方法。
13. １つ以上のコンピュータ装置上で実行される場合に、請求項１乃至１２のいずれか１項に記載の方法を実行するプログラムコード部分を含むコンピュータプログラム。
14. コンピュータ可読記憶媒体に記憶されていることを特徴とする請求項１３に記載のコンピュータプログラム。
15. 第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理するように構成されている第１のエッジプロキシ（３０２）を実現するノードであって、
    第２のＩＭＳネットワーク（１０４）を介して、ユーザ端末（３０６）の登録リクエストを受信するように構成されているコンポーネント（５０２）と、
    前記登録リクエストに基づいて、前記第２のＩＭＳネットワークを示すローミング情報リクエストを、前記第１のＩＭＳネットワーク（１０２）と関連付けられているユーザデータベース（１１０）へ送信するように構成されているコンポーネント（５０４）と、
    前記ローミング情報リクエストに応じて、前記ユーザデータベース（１１０）から、前記ローミング協定に関連する情報を示すローミング情報回答を受信するように構成されているコンポーネント（５０６）と、
    前記ローミング情報回答に基づいて、前記登録リクエストを、前記第１のＩＭＳネットワーク（１０２）の第２のエッジプロキシ（１０６）へ転送するように構成されているコンポーネント（５０６）とを備え、
    前記第２のエッジプロキシ（１０６）は、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間の前記ローミング協定を管理している
    ことを特徴とするノード。
16. 前記登録リクエストを前記第１のＩＭＳネットワークのユーザレジスタへルーティングするための許可をリクエストするルーティング許可リクエストを、前記ユーザデータベースへ送信するように構成されているコンポーネント（５０４）と、
    前記ルーティング許可リクエストに応じて、前記リクエストされた許可を拒否するルーティング許可応答を前記ユーザデータベースから受信するように構成されているコンポーネント（５０６）と
    を更に備えることを特徴とする請求項１５に記載のノード。
17. 前記ノードは、前記ルーティング許可リクエストと前記ローミング情報リクエストとを含む１つのメッセージを前記ユーザデータベースへ送信するように構成されている
    ことを特徴とする請求項１５に記載のノード。
18. 第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワークにおいて自動的に確立されているローミング協定を管理するように構成されていて、前記第１のＩＭＳネットワーク（１０２）に関連付けられているユーザデータベース（１１０）を実現するノードであって、
    前記第１のＩＭＳネットワークの第１のエッジプロキシから、第２のＩＭＳネットワークを示すローミング情報リクエストを受信するように構成されているコンポーネント（７０２）と、
    前記ローミング情報リクエストに応じて、前記第１のエッジプロキシへ、前記ローミング協定に関連する情報を示すローミング情報回答を送信するように構成されているコンポーネント（７０８）とを備え、
    ユーザ端末の登録リクエストが第２のＩＭＳネットワークを介して前記第１のエッジプロキシ（３０２）によって受信され、かつ前記ユーザ端末の登録リクエストは、前記ローミング情報回答に基づいて、前記第１のＩＭＳネットワーク（１０２）の第２のエッジプロキシ（１０６）へ転送され、
    前記第２のエッジプロキシ（１０６）は、前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間の前記ローミング協定を管理している
    を備えることを特徴とするノード。
19. 前記登録リクエストを前記第１のＩＭＳネットワークのユーザレジスタへルーティングするための許可をリクエストするルーティング許可リクエストを、前記第１のエッジプロキシから受信するように構成されているコンポーネント（７０２）と、
    前記ルーティング許可リクエストに応じて、前記リクエストされた許可を拒否するルーティング許可応答を前記第１のエッジプロキシへ送信するように構成されているコンポーネント（７０８）と
    を備えることを特徴とする請求項１８に記載のノード。
20. 前記ノードは、前記第１のエッジプロキシから送信される、前記ルーティング許可リクエストと前記ローミング情報リクエストとを含む１つのメッセージを受信するように構成されていて、かつルーティング許可応答ではなく、ローミング情報回答だけを前記第１のエッジプロキシへ送信するように構成されている
    ことを特徴とする請求項１８に記載のノード。
21. 前記第１のエッジプロキシ及び前記ユーザデータベースを実現する前記ノード群は、Ｄｉａｍｅｔｅｒプロトコルを使用して互いに通信するように構成されている
    ことを特徴とする請求項１５乃至２０のいずれか１項に記載のノード。
22. 第１のＩＰマルチメディアサブシステムである「ＩＭＳ」ネットワーク（１０２）において自動的に確立されているローミング協定を管理するように構成されている、第２のエッジプロキシ（１０６）を実現するノードであって、
    前記第１のＩＭＳネットワーク（１０２）の第１のエッジプロキシ（３０２）からユーザ端末の登録リクエストを受信するように構成されているコンポーネント（９０４）を備え、
    前記登録リクエストは、第２のＩＭＳネットワーク（１０４）を介して前記第１のエッジプロキシ（３０２）によって受信され、かつ前記第１のＩＭＳネットワークと前記第２のＩＭＳネットワークとの間の前記ローミング協定を管理する前記第２のエッジプロキシ（１０６）へ転送される
    ことを特徴とするノード。
23. 前記第１のエッジプロキシと前記第２のエッジプロキシの少なくとも１つは、インターロゲイティング呼状態制御機能である「Ｉ−ＣＳＣＦ」（３０２、１０６）、相互接続境界制御機能である「ＩＢＣＦ」、あるいはセッション境界ゲートウェイである「ＳＢＧ」として実現され、
    前記ユーザデータベースは、ホーム加入者サーバである「ＨＳＳ」（１１０）として実現され、
    前記ユーザレジスタは、サービング呼状態制御機能である「Ｓ−ＣＳＣＦ」（１０８）として実現される
    ことを特徴とする請求項１６または１９に記載のノード。

Images