JP5349580B2 - サービスノード、その制御方法、ユーザノード、及びその制御方法 - Google Patents

Description

本発明は、サービスノード、その制御方法、ユーザノード、及びその制御方法に関する。特に、本発明は、限定される訳ではないが、所与のアクセスネットワーク経由で所与のネットワークと通信可能なユーザノードに対して、他のアクセスネットワーク経由で前記所与のネットワークからサービスを提供できるようにする技術に関する。

「ＩＰマルチメディア・サブシステム」（ＩＭＳ）と呼ばれるネットワークアーキテクチャが、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって、パケットドメインにおいてマルチメディアサービス及びマルチメディアセッションを扱うためのオープンな標準として開発されてきた（ＩＭＳに関する詳細については、http://www.3gpp.org/ftp/Specs/html-info/22228.htmに見られる３ＧＰＰ ＴＳ２３．２２８を参照されたい）。現在、ＩＭＳ標準に準拠した多様な通信端末及び通信デバイス（以下、ＩＭＳ端末又はＩＭＳユーザ装置（ＵＥ）と呼ぶ）が知られている。ＩＭＳ端末の典型例は、ＩＭＳ機能を備えた移動体電話である。パーソナルコンピュータ（ＰＣ）や携帯情報端末（ＰＤＡ）なども、ＩＭＳ機能を備えれば、ＩＭＳ端末としての役割を果たすことができる。ＩＭＳ端末は、例えば、ＩＭＳネットワークを介してビデオストリーミングサーバからビデオストリーミングを受信することにより、マルチメディアサービスを提供することができる。

一般的に、ＵＥは、ＩＭＳプライベート・ユーザ・アイデンティティ（ＩＭＰＩ）やＩＭＳパブリック・ユーザ・アイデンティティ（ＩＭＰＵ）のようなＩＭＳ加入情報を有する。ＵＥは、汎用パケット無線サービス（ＧＰＲＳ）のような移動体アクセスネットワーク経由で、移動体ＩＭＳオペレータのネットワーク（以下、移動体ＩＭＳネットワークと呼ぶ）にアクセスすることができる。移動体ＩＭＳネットワークは、ＩＭＳ加入情報を使用してＵＥを認証して許可し、ボイス・オーバーＩＰ（ＶｏＩＰ）のようなマルチメディアサービスをＵＥに提供する。

ＵＥが移動体ＩＭＳネットワークに直接アクセスしてＩＭＳサービスの提供を受ける場合、移動体ＩＭＳネットワークは、移動体アクセスネットワーク上でサービス品質（ＱｏＳ）を制御することができる。

ところで、無線ローカルエリアネットワーク（ＷＬＡＮ）アダプタを備えるＵＥも知られている。そのようなＵＥは、デジタル加入者線（ＤＳＬ）のような固定アクセスネットワーク経由で固定ＩＭＳオペレータのネットワーク（以下、固定ＩＭＳネットワークと呼ぶ）に接続する、ＬＡＮに参加することができる。

ＩＭＳはアクセス技術を問わない(access-agnostic)システムであるため、ＵＥが固定ＩＭＳネットワークに登録可能であるという条件下で、ＷＬＡＮアダプタを備えるＵＥは固定ＩＭＳネットワーク経由でＩＭＳサービスの提供を受けることができる。ＵＥの移動体ＩＭＳオペレータが固定ＩＭＳオペレータとのローミング契約を有する場合や、固定ＩＭＳオペレータがＵＥの移動体ＩＭＳオペレータと同じである場合（即ち、ＵＥのＩＭＳ加入情報が固定ＩＭＳネットワークに対しても有効である場合）などに、ＵＥは固定ＩＭＳネットワークに登録することができる。これらの場合、ＵＥが固定ＩＭＳネットワークにアクセスしてＩＭＳサービスの提供を受ける際に、固定ＩＭＳネットワークは、固定アクセスネットワーク上でＱｏＳを制御することができる。

しかしながら、ローミング契約が存在せず、ＵＥのＩＭＳ加入情報が固定ＩＭＳネットワークに対しては有効でない場合に、問題が発生する。この場合、固定ＩＭＳネットワークはＵＥからの最初のＩＭＳ登録要求を拒絶するので、ＵＥは、固定ＩＭＳネットワーク経由でＩＭＳサービスの提供を受けることができない。

状況によっては（例えば、ＵＥのＩＭＳ加入者ＩＤモジュール（ＩＳＩＭ）アプリケーションが移動体ＩＭＳネットワークのＰ−ＣＳＣＦのアドレスを含んでいる場合）、ＵＥは、自分のＩＭＳ加入情報を使用して固定アクセスネットワーク経由で移動体ＩＭＳネットワークに登録してアクセスすることができる。この場合、ＵＥは、固定アクセスネットワーク経由で移動体ＩＭＳネットワークからＩＭＳサービスの提供を受けることができる。しかしながら、移動体ＩＭＳネットワークは固定アクセスネットワーク上でＱｏＳを制御する権限を持たないため、ＱｏＳは保証されない（図１参照）。

本発明は上述の課題を扱うことを意図しており、所与のアクセスネットワーク（例えば、移動体アクセスネットワーク）経由で所与のネットワーク（例えば、移動体ＩＭＳネットワーク）と通信可能なユーザノード（例えば、ＵＥ）に対して、他のアクセスネットワーク（例えば、固定アクセスネットワーク）経由で前記所与のネットワークからサービスを提供できるようにする技術をもたらすことを特徴とする。

本発明の第１の態様によれば、制御ノードを含んだ第１のネットワークの中で第１のユーザノードにサービス提供可能なサービスノードであって、前記第１のネットワークは、第２のユーザノードを含んだ第２のネットワークと通信可能であり、前記サービスノードは、
前記第１のユーザノードから、前記第１のユーザネットワーク内で前記第１のユーザノードを識別する第１のユーザＩＤと前記第２のネットワーク内で前記第２のユーザノードを識別する第２のユーザＩＤとを含んだリダイレクト要求を受信する要求受信ユニットと、
前記第１のユーザＩＤと前記第２のユーザＩＤとの関連付けを格納する格納ユニットと、
前記制御ノードからメッセージを受信するメッセージ受信ユニットと、
前記メッセージが前記第１のユーザＩＤを宛先として含んでいるか、又は、前記メッセージが前記第１のユーザＩＤに対応する補助情報を含んでいるかを判定する判定ユニットと、
修正ユニットであって、
前記メッセージが前記第１のユーザＩＤを宛先として含んでいると前記判定ユニットが判定した場合に、前記関連付けに基づき、前記メッセージの前記宛先を前記第２のユーザＩＤに修正し、
前記メッセージが前記補助情報を含んでいると前記判定ユニットが判定した場合に、前記補助情報に基づき、前記メッセージの発信元を前記第１のユーザＩＤに修正する
前記修正ユニットと、
前記修正されたメッセージを前記制御ノードへ送信する送信ユニットと、
を備える、サービスノードが提供される。

本発明の第２の態様によれば、制御ノードを含んだ第１のネットワークの中で第１のユーザノードにサービス提供可能なサービスノードを制御する方法であって、前記第１のネットワークは、第２のユーザノードを含んだ第２のネットワークと通信可能であり、前記方法は、
前記第１のユーザノードから、前記第１のユーザネットワーク内で前記第１のユーザノードを識別する第１のユーザＩＤと前記第２のネットワーク内で前記第２のユーザノードを識別する第２のユーザＩＤとを含んだリダイレクト要求を受信するステップと、
前記第１のユーザＩＤと前記第２のユーザＩＤとの関連付けを格納するステップと、
前記制御ノードからメッセージを受信するステップと、
前記メッセージが前記第１のユーザＩＤを宛先として含んでいるか、又は、前記メッセージが前記第１のユーザＩＤに対応する補助情報を含んでいるかを判定するステップと、
前記メッセージが前記第１のユーザＩＤを宛先として含んでいると前記判定するステップが判定した場合に、前記関連付けに基づき、前記メッセージの前記宛先を前記第２のユーザＩＤに修正するステップと、
前記メッセージが前記補助情報を含んでいると前記判定するステップが判定した場合に、前記補助情報に基づき、前記メッセージの発信元を前記第１のユーザＩＤに修正するステップと、
前記修正されたメッセージを前記制御ノードへ送信するステップと、
を備える、方法が提供される。

本発明の第３の態様によれば、第１のネットワークの中のサービスノード及び第１の制御ノード、及び、第２の制御ノードを含んだ第２のネットワークの中の他のユーザノードと通信可能なユーザノードであって、
メモリから、前記第１のネットワーク内で前記ユーザノードを識別する第１のユーザＩＤを引き出す引き出しユニットと、
前記他のユーザノードから、前記第２のネットワーク内で前記他のユーザノードを識別する第２のユーザＩＤを受信するユーザＩＤ受信ユニットと、
前記第２のユーザＩＤを前記他のユーザノード経由で前記第２の制御ノードに登録する登録ユニットと、
前記サービスノードへ、前記第１のユーザＩＤ及び前記第２のユーザＩＤを含んだリダイレクト要求を送信する要求送信ユニットと、
前記他のユーザノードへ、前記第１のネットワーク内で前記サービスノードを識別するサービスノードＩＤと前記第１のユーザＩＤに対応する補助情報とを含んだメッセージを送信することにより、前記サービスノードＩＤにより前記第１の制御ノードが前記メッセージを前記サービスノードへルーティングするようにする、メッセージ送信ユニットと、
を備える、ユーザノードが提供される。

本発明の第４の態様によれば、第１のネットワークの中のサービスノード及び第１の制御ノード、及び、第２の制御ノードを含んだ第２のネットワークの中の他のユーザノードと通信可能なユーザノードを制御する方法であって、
メモリから、前記第１のネットワーク内で前記ユーザノードを識別する第１のユーザＩＤを引き出すステップと、
前記他のユーザノードから、前記第２のネットワーク内で前記他のユーザノードを識別する第２のユーザＩＤを受信するステップと、
前記第２のユーザＩＤを前記他のユーザノード経由で前記第２の制御ノードに登録するステップと、
前記サービスノードへ、前記第１のユーザＩＤ及び前記第２のユーザＩＤを含んだリダイレクト要求を送信するステップと、
前記他のユーザノードへ、前記第１のネットワーク内で前記サービスノードを識別するサービスノードＩＤと前記第１のユーザＩＤに対応する補助情報とを含んだメッセージを送信することにより、前記サービスノードＩＤにより前記第１の制御ノードが前記メッセージを前記サービスノードへルーティングするようにする、ステップと、
を備える、方法が提供される。

本発明の主な利点は次の通りである。所与のアクセスネットワーク（例えば、移動体アクセスネットワーク）経由で所与のネットワーク（例えば、移動体ＩＭＳネットワーク）と通信可能なユーザノード（例えば、ＵＥ）に対して、他のアクセスネットワーク（例えば、固定アクセスネットワーク）経由で前記所与のネットワークからサービスを提供できる。その理由は、前記所与のネットワーク内のサービスノードが、ユーザノードに関係するメッセージの宛先又は発信元を修正するからである。

本発明の更なる特徴は、添付の図面を参照する以下の例示的な実施形態に関する記述から明らかになるであろう。添付の図面においては、全図を通して、同様の参照符号は同一の又は類似する部分を示す。

図１は、従来技術において発生する課題を概略的に示す。 図２は、本発明の例示的な実施形態に従うネットワーク構成を示す概略図である。 図３は、本発明の例示的な実施形態に従うユーザ装置（ＵＥ）の機能ブロック図である。 図４は、本発明の例示的な実施形態に従う仮想ローミング・サポート機能（ＶＲＳＦ）の機能ブロック図である。 図５は、本発明の例示的な実施形態に従う、固定ＩＰマルチメディア・システム（ＩＭＳ）ネットワークが移動体ＩＭＳネットワークとのローミング契約を有するか否かをＵＥが判定する処理の流れを示すシーケンス図である。 図６は、本発明の例示的な実施形態に従う、ＵＥが仮想ローミングを開始する処理の流れを示すシーケンス図である。 図７は、本発明の例示的な実施形態に従う、ＵＥ１００に対する着呼が仮想ローミング環境においてどのように処理されるかを示すシーケンス図である。 図８は、本発明の例示的な実施形態に従う、ＵＥからの発呼が仮想ローミング環境においてどのように処理されるかを示すシーケンス図である。 図９は、本発明の例示的な実施形態に従う、ＵＥ１００が仮想ローミングを終了する処理の流れを示すシーケンス図である。

図２は、本発明の例示的な実施形態に従うネットワーク構成を示す概略図である。

図２において、ユーザ装置（ＵＥ）１００は、移動体アクセスネットワーク３０１経由で移動体ＩＭＳネットワーク３００と通信する。ＵＥ１００の詳細な構成は、図３を参照して後述する。ＵＥ１００はまた、無線ＬＡＮ（ＷＬＡＮ）アダプタ（図２には示さず）経由でローカルエリアネットワーク（ＬＡＮ）４００とも通信する。本実施形態では、ＵＥ１００はＬＡＮ４００と無線で通信するものとするが、ＵＥ１００はＬＡＮ４００に対する有線での接続を有してもよい。

ＬＡＮ４００は、固定アクセスネットワーク５０１経由で固定ＩＭＳネットワーク５００と通信する。移動体ＩＭＳネットワーク３００と固定ＩＭＳネットワークとは、トランジットネットワーク６００経由で相互に通信する。

例えば、移動体アクセスネットワーク３０１は汎用パケット無線サービス（ＧＰＲＳ）を使用して実装可能であり、固定アクセスネットワーク５０１はデジタル加入者線（ＤＳＬ）を使用して実装可能である。

移動体ＩＭＳネットワーク３００は、仮想ローミング・サポート機能（ＶＲＳＦ）２００を備える。ＶＲＳＦ２００は、ＵＥ１００に対して固定アクセスネットワーク５０１経由で移動体ＩＭＳネットワーク３００からＩＭＳサービスを提供することを可能にする鍵となるノードのうちの１つである（このスキームを、本願では「仮想ローミング」と呼ぶ）。ＶＲＳＦ２００の詳細な構成は、図４を参照して後述する。

移動体ＩＭＳネットワーク３００はまた、呼セッション制御機能（ＣＳＣＦ）３０２も備える。正確には、ＣＳＣＦは一般的に、プロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、インテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）、及びサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）を含む。しかしながら、単純化を目的として、正確な区別が必要でない限り、本願ではこれらを一般的にＣＳＣＦと呼ぶ。

ＬＡＮ４００は、ＩＭＳゲートウェイ（ＩＧ）４０１を備える。ＩＧ４０１は、ＵＥの一種であり、その基本的な構成は現在の技術において知られている（例えば、ＷＯ２００６／０４５７０６参照）。特に、ＩＧ４０１は、固定アクセスネットワーク５０１経由で固定ＩＭＳネットワーク５００との通信を実行するネットワークアダプタを有する。ＩＧ４０１はまた、１つのＩＭＰＩと１つ以上のＩＭＰＵとを含んだＩＳＩＭアプリケーションも有する。ＩＧ４０１は、ＩＭＰＵの１つを使用して固定ＩＭＳネットワーク５００（厳密には、固定ＩＭＳネットワーク５００のＣＳＣＦ５０２）に登録可能であり、固定ＩＭＳネットワーク５００は、ＩＧ４０１と固定ＩＭＳネットワーク５００との間の通信に関して、固定アクセスネットワーク５０１上でＱｏＳを制御することができる。注意すべきこととして、ＩＧ４０１の基本的な構成は現在の技術において知られているが、いくつかの動作（例えば、後述するステップＳ５０３−５０５及びＳ６０１−６０２において実行される動作）は、新規であり本発明に特有である。

図３は、本発明の例示的な実施形態に従うＵＥ１００の機能ブロック図である。ＵＥ１００は、例えば、移動体電話であってもよい。ＵＥ１００の中の各ブロックの機能は、専用のハードウェアによって、又はプロセッサ（不図示）によって実行されるソフトウェアによって、或いはその組み合わせによって、実装可能である。

図３において、無線ワイドエリアネットワーク（ＷＷＡＮ）アダプタ１０１は、通信標準（例えば、汎欧州デジタル移動通信システム（ＧＳＭ）、広帯域符号分割多元接続（ＷＣＤＭＡ）、ＣＤＭＡ２０００など）に従って移動体ＩＭＳネットワーク３００との通信を実行するネットワークアダプタである。ＷＬＡＮアダプタ１０２は、通信標準（例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ）に従ってＬＡＮ４００との通信を実行するネットワークアダプタである。

引き出しユニット１０３は、メモリが挿入されるメモリスロットを含み、メモリからＩＭＳ加入情報を引き出す。本実施形態では、メモリは、ＩＭＳ加入情報を含んだＩＳＩＭアプリケーションを格納したユニバーサルＩＣカード（ＵＩＣＣ）１５０である。ＩＭＳ加入情報は、１つのＩＭＰＩと１つ以上のＩＭＰＵとを含み、移動体ＩＭＳネットワーク３００においてＵＥ１００を識別する。

ＩＳＩＭアプリケーションはＵＥ１００に物理的に挿入されるＵＩＣＣ１５０の中に実装されるものとするが、ＩＳＩＭアプリケーションは他の形式で実装することもできる。例えば、ＩＳＩＭアプリケーションは、ネットワーク経由でＵＥ１００の信頼済み実行環境へとダウンロード可能なリモート管理されるソフトウェアオブジェクトとして実現することもできるし、ＵＥ１００内の組み込みチップ（インダストリアル・フォーム・ファクタとも呼ばれる）（これはリモートで管理される場合もある）の中に実装することもできる。

本実施形態では、ＵＥ１００は無線通信によりＬＡＮ４００に参加するものとし、移動体ＩＭＳネットワーク３００からサービスの提供を受けるために、ＬＡＮ４００及び固定アクセスネットワーク５０１を経由して固定ＩＭＳネットワーク５００に仮想ローミングするものとする。しかしながら、ネットワーク及びアクセス技術の種類は、これらに限定されない。異なる種類のネットワーク又はアクセス技術が採用される場合、図２のネットワーク構成のコンポーネントの一部がそれに応じて修正される。例えば、固定アクセスネットワーク５０１が所与の無線ネットワークに置き換えられた場合、ＩＧ４０１は、前記所与の無線ネットワーク経由の通信を実行するネットワークインタフェースを有することになろう。

しかしながら、注意すべきこととして、固定アクセスネットワークは通常移動体アクセスネットワークよりも大きな帯域幅を有するので、本実施形態のシナリオは特に利点を有する。従って、ＵＥ１００のユーザは、ビデオストリーミングのような帯域幅を消費するＩＭＳサービスを楽しむことを望む場合、固定ＩＭＳネットワーク５００にローミングすることを好むであろう。

ネットワークＩＤ受信ユニット１０４、登録ユニット１０５、及びユーザＩＤ受信ユニット１０６は、ＷＬＡＮアダプタ１０２経由でＬＡＮ４００内のＩＧ４０１と通信する。要求送信ユニット１０７及び問合せユニット１０８は、ＷＷＡＮアダプタ１０１経由で移動体ＩＭＳネットワーク３００内のＶＲＳＦ２００と通信する。メッセージ送信ユニット１０９は、ＷＬＡＮアダプタ１０２経由でＬＡＮ４００内のＩＧ４０１と通信し、また、ＷＷＡＮアダプタ１０１経由で移動体ＩＭＳネットワーク３００内のＣＳＣＦ３０２と通信することもできる。各ユニットの動作は、図５−９を参照して後述する。

図４は、本発明の例示的な実施形態に従うＶＲＳＦ２００の機能ブロック図である。ＶＲＳＦ２００は、例えば、ＩＭＳアプリケーションサーバ（ＩＭＳ）の一種であってもよい。或いは、ＶＲＳＦ２００は、ＣＳＣＦ３０２に統合されていてもよい。ＶＲＳＦ２００の中の各ブロックの機能は、専用のハードウェアによって、又はプロセッサ（不図示）によって実行されるソフトウェアによって、或いはその組み合わせによって、実装可能である。

図４において、ネットワークアダプタ２０１は、ＵＥ１００及びＣＳＣＦ３０２との通信を実行する。

指示ユニット２０２、要求受信ユニット２０３、通知ユニット２０４、メッセージ受信ユニット２０５、及び送信ユニット２０６は、ネットワークアダプタ２０１経由でＵＥ１００及びＣＳＣＦ３０２の少なくとも一方と通信する。格納ユニット２０７、判定ユニット２０８、及び修正ユニット２０９は、ＶＲＳＦ２００内で所定の動作を実行する。各ユニットの動作は、図５−９を参照して後述する。

図５は、本発明の例示的な実施形態に従う、固定ＩＭＳネットワーク５００が移動体ＩＭＳネットワーク３００とのローミング契約を有するか否かをＵＥ１００が判定する処理の流れを示すシーケンス図である。

ステップＳ５０１で、ＵＥ１００の引き出しユニット１０３（図３参照）は、ＵＩＣＣ１５０からＩＭＳ加入情報を引き出す。その後、ＵＥ１００は、ＩＭＳ加入情報をＷＷＡＮアダプタ１０１経由でＣＳＣＦ３０２に登録することにより、移動体ＩＭＳネットワーク３００にアタッチする。

ステップＳ５０２で、ＵＥ１００は、ＷＬＡＮアダプタ１０２を用いてＬＡＮ４００にアタッチし、例えばＤＨＣＰ(Dynamic Host Configuration Protocol)を使用することにより、ＬＡＮ４００内のローカルＩＰアドレスを取得する。本実施形態では、ＵＥ１００は、固定ＩＭＳネットワーク５００に仮想ローミングしている時であっても、移動体ＩＭＳネットワーク３００にアタッチしたままであるものとする。

ステップＳ５０３で、ＵＥ１００は、ユニバーサル・プラグ・アンド・プレイ（ＵＰｎＰ）のディスカバリー・メカニズムを通じて、ＬＡＮ４００内のＩＧ４０１を発見する。本実施形態では、ＵＥ１００とＩＧ４０１との間の通信はＵＰｎＰメカニズムに基づいて実行されるものとするが、ＵＥ１００及びＩＧ４０１が適切に構成されていれば、他のメカニズムも適用可能である。

ステップＳ５０４で、ネットワークＩＤ受信ユニット１０４は、そこに対して有効なＩＭＳ加入情報をＩＧ４０１が有する固定ＩＭＳネットワーク５００のドメイン名をＩＧ４０１に問い合わせるために、ＵＰｎＰアクション要求を送信する。

ステップＳ５０５で、ステップＳ５０４における要求に応えて、ＩＧ４０１はドメイン名（例えば、"fix.net"）を返す。このステップにおいて、ＩＧ４０１は、ＩＧ４０１の中に格納されているＩＭＳ加入情報からドメイン名を引き出すことができる。例えば、ＩＭＳ加入情報は、ＩＳＩＭアプリケーションの中に格納されている。

ステップＳ５０６で、問合せユニット１０８は、"fix.net"によって特定される固定ＩＭＳネットワーク５００に対してＵＥ１００がローミング可能であるか否かを、ＶＲＳＦ２００に問い合わせる。換言すると、問合せユニット１０８は、固定ＩＭＳネットワーク５００が移動体ＩＭＳネットワーク３００とのローミング契約を有するか否かを、ＶＲＳＦ２００に問い合わせる。なお、ＶＲＳＦ２００のアドレスは、ＵＩＣＣ１５０のＩＳＩＭアプリケーションの中に事前設定しておくことができる。このステップにおいて、ＶＲＳＦ２００は、移動体アクセスネットワーク３０１（これは一般的に認証されたチャネルである）から問合せを受信した場合、この問合せの発信元（即ち、ＵＥ１００）を認証することができる。或いは、ＶＲＳＦ２００は、他の認証されたチャネル（例えば、（ＧＢＡ(Generic Bootstrapping Architecture)ネットワークアプリケーション機能（ＮＡＦ）として機能する）ＶＲＳＦ２００とＵＥ１００との間のＧＢＡによって保護されたＵｔインタフェースなど）経由で問合せが受信された場合、ＵＥ１００を認証することができる。

ステップＳ５０７で、ＶＲＳＦ２００の通知ユニット２０４（図４参照）は、ステップＳ５０６において受信されたドメイン名が格納ユニット２０７に格納されているか否かを判定する。ドメイン名が格納されている場合、通知ユニット２０４は、"fix.net"によって特定されるネットワークに対してＵＥ１００がローミング可能であるということを示す回答を返す。そうでない場合、通知ユニット２０４は、"fix.net"によって特定されるネットワークに対してＵＥ１００がローミング可能でないということを示す回答を返す。

ＵＥ１００が固定ＩＭＳネットワーク５００にローミング可能である場合は仮想ローミングを避けることができるので、ＵＥ１００にとって、固定ＩＭＳネットワーク５００にローミング可能であるか否かを知ることは、利点となる。

いくつかの実施形態では、ＵＥ１００は、代替メカニズムによって、固定ＩＭＳネットワーク５００が移動体ＩＭＳネットワーク３００とのローミング契約を有するか否かを判定することができる。例えば、ＵＥ１００は、セッション開始プロトコル（ＳＩＰ）サーバに対するＤＨＣＰオプションを伴うＤＨＣＰ要求をブロードキャストすることにより、固定ＩＭＳネットワーク５００のＰ−ＣＳＣＦのアドレスを取得することができる（詳細な情報については、RFC 3361 "DHCP Option for SIP Servers"を参照のこと）。この場合、ＩＧ４０１と一緒に用いられるレジデンシャルゲートウェイは、家庭内のＤＨＣＰ（中継）サーバとして機能し、ＬＡＮ４００内の他のＩＭＳ ＵＥに対してＰ−ＣＳＣＦアドレスを広告する。しかしながら、ＤＨＣＰサーバは得てして、Ｐ−ＣＳＣＦアドレスのみならず、普通のＳＩＰクライアントデバイスをサポートするために自分自身のＳＩＰプロキシサーバアドレス（即ち、ＩＧのＢ２ＢＵＡ ＳＩＰサーバアドレス）も広告するので、この点で、このメカニズムは問題を引き起こす可能性がある。ＵＥ１００は、２つのＳＩＰサーバアドレス（或いはホストドメイン名）を受信した場合、どちらがＰ−ＣＳＣＦアドレスであるかを知るための標準や確立した手法が存在しないので、概してこれを知ることができない。それゆえ、ＤＨＣＰサーバがＤＨＣＰオプションを通じてＰ−ＣＳＣＦアドレスだけを広告するという限られた環境において、このメカニズムは有効に機能する。この場合、ＵＥ１００は、そのＰ−ＣＳＣＦアドレスに対するＩＭＳ登録要求が成功すれば、固定ＩＭＳネットワークにローミング可能であるということを知ることができる。ＩＭＳ登録要求が失敗した場合、ＵＥ１００は、ローミングが不可能であるということを知ることになる。

或いは、ＵＥ１００は、移動体ＩＭＳネットワーク３００のドメイン名を提示することにより、ＵＥが固定ＩＭＳネットワーク５００にローミング可能か否かをＩＧ４０１に尋ねてもよい。この場合、ＩＧ４０１は、指定された移動体ＩＭＳネットワーク３００からのローミングを固定ＩＭＳネットワーク５００が受け入れるか否かに関する質問を、固定ＩＭＳネットワーク５００の、ＶＲＳＦ２００に類似する機能エンティティに対して送信する（或いは、ＩＧ４０１には事前に、ＩＧ４０１の固定ＩＭＳネットワーク５００がローミング契約を有する移動体ＩＭＳネットワークのリストが与えられていてもよい）。ＩＧ４０１はその後、ローミングの利用可能性を示す回答をＵＥ１００に返す。

図６は、本発明の例示的な実施形態に従う、ＵＥ１００が仮想ローミングを開始する処理の流れを示すシーケンス図である。

ステップＳ６０１で、ＵＥ１００のユーザＩＤ受信ユニット１０６は、ＵＥ１００がＩＧ４０１に対してＳＩＰ登録を実行するために必要な情報を求めるＵＰｎＰアクション要求を送信する。

ステップＳ６０２で、ＩＧ４０１はユーザＩＤ受信ユニット１０６に対して、ＩＧ４０１のＳＩＰサーバアドレスとＩＧ４０１によってＵＥ１００に割り当てられたＩＭＰＵ（例えば、"sip:user-x@fix.net"）とを含んだ情報を返す。ＵＥ１００は、その後のＩＧ４０１を通じたＩＭＳ通信のために、このＩＭＰＵを使用する。

応答はまた、ＩＧ４０１がサポート可能なＩＭＳサービスのリスト（例えば、ＩＣＳＩ(IMS Communication Service Identifiers)）も含む（ＩＣＳＩに関する詳細については、http://www.3gpp.org/ftp/Specs/html-info/22228.htmに見られる３ＧＰＰ ＴＳ２３．２２８を参照されたい）。注意すべきこととして、ＩＧ４０１が、ＩＧ４０１のＩＭＳ加入情報を使用して限られた種類のＩＭＳサービスだけを利用することを許可されている場合もある。この場合、ＵＥ１００は、固定アクセスネットワーク５０１を通じて、許可されたＩＭＳサービスだけを利用することができる。他のサービスは、移動体アクセスネットワーク３０１経由でアクセスされる。

ステップＳ６０３で、登録ユニット１０５は、ＩＧ４０１へＳＩＰ Ｒｅｇｉｓｔｅｒメッセージを送信する。ＳＩＰ Ｒｅｇｉｓｔｅｒメッセージは、ステップＳ６０２で受信されたＩＭＰＵを含む。

ステップＳ６０４で、ＩＧ４０１は、ＳＩＰ ＲｅｇｉｓｔｅｒメッセージをＩＭＳ ＳＩＰ Ｒｅｇｉｓｔｅｒメッセージに変換し、これをＣＳＣＦ５０２へ送信する。

ステップＳ６０５−Ｓ６０６で、対応する２００ＯＫメッセージが、ＩＧ４０１経由でＣＳＣＦ５０２からＵＥ１００へ返される。

ステップＳ６０７で、要求送信ユニット１０７は、ＶＲＳＦ２００に対してリダイレクト要求を行う。リダイレクト要求は、ＵＥ１００のＩＭＰＵ（例えば、"bob@mobile.net"）と、ステップＳ６０２で受信されたＩＭＰＵ（例えば、"user-x@fix.net"）とを含む。リダイレクト要求は、ＶＲＳＦ２００に対して、"bob@mobile.net"に宛てられたセッション確立を"user-x@fix.net"へリダイレクトするように指示する。ＶＲＳＦ２００の要求受信ユニット２０３（図４参照）がリダイレクト要求を受信し、格納ユニット２０７がこの関連付けを格納する。

リダイレクト要求は、いかなる追加の設定（例えばステップＳ６０２において受信されたＩＣＳＩの全て又は一部を指定することによる、どの特定のＩＭＳサービスをリダイレクトすべきか、など）を含んでもよい。他の可能な設定には、ＵＥ１００が、ＩＰＴＶのような帯域幅を消費するＩＭＳサービスだけを固定アクセスネットワーク５０１を介して受信することを望み、メッセージングサービスのようなＱｏＳがデリケートではない他のＩＭＳサービスは移動体アクセスネットワーク３０１を介して受信することを望むということがある。これらの設定も、格納ユニット２０７の中に格納される。

このリダイレクト要求を実装するプロトコルは、ＧＢＡによって保護されるＵｔインタフェース上のＸＣＡＰであってもよい。或いは、このリダイレクト要求を搬送するために、移動体アクセスネットワーク３０１を介するＩＭＳ ＳＩＰ Ｒｅｇｉｓｔｅｒ要求が使用されてもよい（例えば、ＳＩＰ Ｒｅｇｉｓｔｅｒ要求のＣｏｎｔａｃｔヘッダが、"user-x@fix.net"を搬送する）。

ステップＳ６０８で、指示ユニット２０２は、ＵＥ１００に現在サービス提供しているＣＳＣＦ３０２（正確には、Ｓ−ＣＳＣＦ）に対して、"bob@mobile.net"のためのあらゆるサービスプロファイルの初期フィルタ基準（ＩＦＣ）のトリガーポイントを追加するように指示する。追加されるトリガーポイントは、"bob@mobile.net"に宛てて着信するＳＩＰ要求がＣＳＣＦ３０２によってＶＲＳＦ２００へ転送されるようにするものであり、そうすることで、ＶＲＳＦは仮想ローミングを実現するために必要な処理を実行する。或いは、"bob@mobile.net"のためのＩＦＣは、ＶＲＳＦ２００のためのこのトリガーポイントを含むように静的に事前設定されていてもよい。即ち、"bob@mobile.net"に着信するＳＩＰ要求は、ＵＥ１００が固定ＩＭＳネットワーク５００に仮想ローミングしているか否かに関わらず、常にＶＲＳＦ２００へ転送される。このようにして、ＶＲＳＦ２００は、サービスプロファイルに対する修正（より具体的には、ＵＥ１００のためのＩＦＣに対する修正）を要求する機能を持つ。この修正には、何らかの新たなＩＦＣの追加と何らかの既存のＩＦＣの削除とが含まれる。

ステップＳ６０９で、要求受信ユニット２０３は、ユーザ固有の識別子（例えば、"1234"）を生成し、このユーザ固有の識別子を含んだＶＲＳＦ２００のＳＩＰアドレスを返す。例えば、"sip:vrsf@service.mobile.net;usr=1234"がＵＥ１００へ返される。ユーザ固有の識別子とＵＥ１００のＩＭＰＵとの間の関連付けも格納ユニット２０７に格納され、そうすることで、ＶＲＳＦは後でユーザ固有の識別子に基づいてＵＥ１００を識別することができる。

結果として、ＵＥ１００は仮想ローミングを実行する準備ができる。

図７は、本発明の例示的な実施形態に従う、ＵＥ１００に対する着呼が仮想ローミング環境においてどのように処理されるかを示すシーケンス図である。

ステップＳ７０１で、ＩＭＳピア７０１（これは例えば他のＵＥである）は、bob@mobile.netに宛てられたＳＩＰ ＩＮＶＩＴＥメッセージをＣＳＣＦ３０２へ送信する。

ステップＳ７０２で、ＣＳＣＦ３０２は、（ステップＳ６０８で設定されたＩＦＣに従って）ＳＩＰ ＩＮＶＩＴＥメッセージをＶＲＳＦ２００へ転送する。ＶＲＳＦ２００のメッセージ受信ユニット２０５（図４参照）が、このＳＩＰ ＩＮＶＩＴＥメッセージを受信する。

ステップＳ７０３で、判定ユニット２０８は格納ユニット２０７を参照して、ＳＩＰ ＩＮＶＩＴＥメッセージがＵＥ１００のＩＭＰＵを宛先として含んでいるか否かを判定する。この例では、ＵＥ１００は固定ＩＭＳネットワーク５００に仮想ローミングしており、bob@mobile.netとuser-x@fix.netとの間の関連付けが格納ユニット２０７に格納されている。従って、修正ユニット２０９は、ＳＩＰ ＩＮＶＩＴＥメッセージのＲｅｑｕｅｓｔ−ＵＲＩ（即ち、宛先）をuser-x@fix.netに修正する。その後、送信ユニット２０６は、修正されたＳＩＰ ＩＮＶＩＴＥメッセージをＣＳＣＦ３０２へ送信する。

なお、ＶＲＳＦ２００は、着信するＳＩＰ ＩＮＶＩＴＥメッセージが図６のＳ６０７の間に行われた設定に合致する場合にのみ、このリダイレクト（即ち、修正）を実行する。即ち、修正ユニット２０９は、ＳＩＰ ＩＮＶＩＴＥメッセージによって特定されるサービスタイプをチェックし、このサービスタイプがステップＳ６０７において格納ユニット２０７に格納されているという条件下で、ＳＩＰ ＩＮＶＩＴＥメッセージを修正する。例えば、着信するＳＩＰ ＩＮＶＩＴＥメッセージが要求するＩＭＳサービスが"user-x@fix.net"ではサポートされていないものである場合、ＶＲＳＦ２００は、修正無しでＳＩＰ ＩＮＶＩＴＥメッセージをＣＳＣＦ３０２に返す。その後、ＳＩＰ ＩＮＶＩＴＥメッセージは移動体アクセスネットワーク３０１経由でＵＥ１００へ送信される。

ステップＳ７０４−Ｓ７０６で、修正されたＳＩＰ ＩＮＶＩＴＥメッセージは、ＣＳＣＦ５０２及びＩＧ４０１を経由してＵＥ１００へ転送される。従って、ＵＥ１００は、固定アクセスネットワーク５０１経由で着呼を受信することができる。

ステップＳ７０７−Ｓ７０８で、ＵＥ１００は、ＳＩＰ ＩＮＶＩＴＥメッセージに対して２００ＯＫメッセージにより応答する。２００ＯＫメッセージは最終的に、ＩＧ４０１経由でＣＳＣＦ５０２によって受信される。

ステップＳ７０９で、ＣＳＣＦ５０２は、ＲＡＣＦ(Resource Admission Control Function)７０２に対して、上述のＩＮＶＩＴＥトランザクションによって確立されたセッションに対して必要なＱｏＳを割り当てるように指示する。従って、固定アクセスネットワーク５０１上でのＱｏＳが、仮想ローミング環境において制御される。

ステップＳ７１０−Ｓ７１３で、２００ＯＫメッセージは最終的に、ＩＭＳピア７０１によって受信される。

ステップＳ７１４で、ＵＥ１００及びＩＭＳピア７０１は、固定アクセスネットワーク５０１を介してＱｏＳ制御下でメディアデータを交換する。

図８は、本発明の例示的な実施形態に従う、ＵＥ１００からの発呼が仮想ローミング環境においてどのように処理されるかを示すシーケンス図である。

ステップＳ８０１で、ＵＥ１００のメッセージ送信ユニット１０９（図３参照）は、ＩＭＳピア７０１に宛てられたＳＩＰ ＩＮＶＩＴＥメッセージを生成する。メッセージ送信ユニット１０９は、Ｆｒｏｍヘッダを、ＩＧ４０１によって割り当てられたＩＭＰＵ（即ち、user-x@fix.net）に設定する。加えて、メッセージ送信ユニット１０９は、ＳＩＰ ＩＮＶＩＴＥメッセージに、図６のステップＳ６０９において受信されたＶＲＳＦ２００のＳＩＰアドレスをＲｏｕｔｅヘッダフィールドの中に持たせる。これにより、ＳＩＰ ＩＮＶＩＴＥメッセージは、宛先に到達する前にＶＲＳＦ２００へルーティングされるようにされる。その後、メッセージ送信ユニット１０９は、生成されたＳＩＰ ＩＮＶＩＴＥメッセージをＩＧ４０１へ送信する。

注意すべきこととして、メッセージ送信ユニット１０９は、ステップＳ６０９において要求受信ユニット２０３によって生成されたユーザ固有の識別子（即ち、"1234"）の代わりに、ＵＥ１００のＩＭＰＵ（即ち、"bob@mobile.net"）を補助情報として使用してもよい。ここで重要なことは、補助情報がＵＥ１００を識別可能であることである。

加えて、注意すべきこととして、ＳＩＰ ＩＮＶＩＴＥメッセージは、user-x@fix.netの代わりにbob@mobile.netをＦｒｏｍヘッダフィールドの中に持ってもよい。というのも、Ｆｒｏｍヘッダフィールドは純粋に、論理的な発呼者の識別子を搬送するために使用され、ＳＩＰルーティングのために使用されはしないからである。しかしながら、そのようなトポロジ上不正確なＦｒｏｍヘッダは時々問題を引き起こすので、ＵＥ１００が固定ＩＭＳネットワーク５００に仮想ローミングしているときは、ＳＩＰ ＩＮＶＩＴＥメッセージはＦｒｏｍヘッダフィールドの中にuser-x@fix.netを持つことが好ましい。

更に、ＵＥ１００が仮想ローミング環境の中でサービスを開始することを望まない場合（例えば、ＳＩＰ ＩＮＶＩＴＥメッセージによって要求されるサービスのサービスタイプが図６のＳ６０２において受信されたＩＣＳＩに含まれない場合）、メッセージ送信ユニット１０９は、従来のやり方でＳＩＰ ＩＮＶＩＴＥメッセージを生成して移動体アクセスネットワーク３０１経由で送信する。

ステップＳ８０２で、ＩＧ４０１は、ＳＩＰ ＩＮＶＩＴＥメッセージを受信し、Ｒｏｕｔｅヘッダフィールドの中に、ＶＲＳＦ２００のアドレスの前に固定ＩＭＳネットワーク５００の必要なＣＳＣＦアドレスを挿入する。これにより、ＳＩＰ ＩＮＶＩＴＥメッセージは、最初に固定ＩＭＳネットワーク５００へとルーティングされるようにされる。その後、ＩＧ４０１は、ＳＩＰ ＩＮＶＩＴＥメッセージをＣＳＣＦ５０２へ送信する。

ステップＳ８０３で、ＣＳＣＦ５０２は、関連するＲｏｕｔｅヘッダ（即ち、図８の例ではcscfs@fix.net）を消費する。残りのＲｏｕｔｅヘッダ（即ち、図８の例ではsip:vrsf@service.mobile.net;user=1234）に従い、ＣＳＣＦ５０２は、ＳＩＰ ＩＮＶＩＴＥメッセージをＣＳＣＦ３０２へ転送する。

ステップＳ８０４で、ＣＳＣＦ３０２は、Ｒｏｕｔｅヘッダに従い、ＳＩＰ ＩＮＶＩＴＥメッセージをＶＲＳＦ２００へ転送する。ＶＲＳＦ２００のメッセージ受信ユニット２０５（図４参照）が、このＳＩＰ ＩＮＶＩＴＥメッセージを受信する。

ステップＳ８０５で、判定ユニット２０８は格納ユニット２０７を参照して、ＳＩＰ ＩＮＶＩＴＥメッセージが補助情報を含むか否かを判定する。この例では、ＵＥ１００は固定ＩＭＳネットワーク５００に仮想ローミングしているので、ＳＩＰ ＩＮＶＩＴＥメッセージに含まれる補助情報は格納ユニット２０７に格納されている。更に、補助情報（即ち、"1234"）とbob@mobile.netとの間の関連付けも、格納ユニット２０７に格納されている。従って、判定ユニット２０８は、発呼エンティティがＵＥ１００であるということを認識する。その後、修正ユニット２０９は、ＳＩＰ ＩＮＶＩＴＥメッセージのＦｒｏｍヘッダフィールド（即ち、発信元）を、bob@mobile.netに修正する。修正ユニット２０９はまた、ＣＳＣＦ５０２によって追加されるかもしれない、ＳＩＰ ＩＮＶＩＴＥメッセージのＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダも検査することで、ＳＩＰ ＩＮＶＩＴＥメッセージが本当にuser-x@fix.netから送信されたということを検証する。その後、修正ユニット２０９は、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダの内容をbob@mobile.netに修正する（或いは、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダが存在しない場合、修正ユニと２０９は、bob@mobile.netを伴うＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダを追加する）。その後、送信ユニット２０６は、修正されたＳＩＰ ＩＮＶＩＴＥメッセージをＣＳＣＦ３０２へ送信する。

ステップＳ８０６で、ＣＳＣＦ３０２は、ＳＩＰ ＩＮＶＩＴＥメッセージを宛先のＩＭＳピア７０１へ転送する。

ステップＳ８０７−Ｓ８１０で、ＩＭＳピア７０１は、ＳＩＰ ＩＮＶＩＴＥに対して２００ＯＫメッセージにより応答し、この２００ＯＫメッセージは、着呼の場合と同様のやり方で（図７参照）最終的にＣＳＣＦ５０２によって受信される。

ステップＳ８１１で、ＣＳＣＦ５０２はＲＡＣＦ７０２に対して、上述のＩＮＶＩＴＥトランザクションによって確立されたセッションに対して必要なＱｏＳを割り当てるように指示する。従って、固定アクセスネットワーク５０１上でのＱｏＳが、仮想ローミング環境において制御される。

ステップＳ８１２−Ｓ８１３で、２００ＯＫメッセージは最終的に、ＵＥ１００によって受信される。

ステップＳ８１４で、ＵＥ１００及びＩＭＳピア７０１は、固定アクセスネットワーク５０１を介してＱｏＳ制御下でメディアデータを交換する。

図９は、本発明の例示的な実施形態に従う、ＵＥ１００が仮想ローミングを終了する処理の流れを示すシーケンス図である。

ステップＳ９０１で、ＵＥ１００の要求送信ユニット１０７（図３参照）は、リダイレクト無効化要求をＶＲＳＦ２００へ送信する。リダイレクト無効化要求は、ＶＲＳＦ２００に対して、bob@mobile.netのための仮想ローミングを無効化するように指示する。ＶＲＳＦは、関連するＩＦＣを削除することにより、ＣＳＣＦ３０２に対してbob@mobile.netに宛てられたメッセージの転送を停止するように指示することができる。この要求は、例えば、ＧＢＡによって保護される。ＶＲＳＦ２００の要求受信ユニット２０３（図４参照）が、リダイレクト無効化要求を受信する。

ステップＳ９０２で、要求受信ユニット２０３は、リダイレクト無効化要求に対して肯定応答を返す。

ステップＳ９０３で、ＵＥ１００は、ＷＬＡＮアダプタ１０２を用いて、ＳＩＰ ｄｅ−ＲｅｇｉｓｔｅｒメッセージをＩＧ４０１へ送信する。

ステップＳ９０４で、ＩＧ４０１は、図６のステップＳ６０２においてＵＥ１００に割り当てられたuser-x@fix.netに関して、ＩＭＳ ｄｅ−ＲｅｇｉｓｔｅｒメッセージをＣＳＣＦ５０２へ送信する。

ステップＳ９０５−Ｓ９０６で、２００ＯＫメッセージが、ＩＧ４０１経由でＣＳＣＦ５０２からＵＥ１００へ最終的に返送される。

（本発明の利点）
本発明は、例え移動体ＩＭＳネットワーク３００が固定ＩＭＳネットワーク５００とのローミング契約を有さない場合であっても、移動体アクセスネットワーク３０１経由で移動体ＩＭＳネットワーク３００と通信可能なＵＥ１００が、他のネットワーク（即ち、固定ＩＭＳネットワーク５００）へ「仮想的に」ローミング可能であり、他のアクセスネットワーク（即ち、固定アクセスネットワーク５０１）経由で移動体ＩＭＳネットワーク３００からサービスの提供を受けることができるという点で、利点を有する。

他の非限定的な利点は以下の通りである。

− ＵＥ１００と移動体ＩＭＳネットワーク３００との間のサービスのために、固定アクセスネットワーク５０１上でのＱｏＳがサポートされる。

− 本発明の構成及び手順は、他のネットワークに対するいかなる変更も無しに、任意のネットワークにおいて実装可能である。即ち、固定ＩＭＳネットワーク５００及び固定アクセスネットワーク５０１を修正する必要はない。

例示的な実施形態を参照して本発明を説明してきたが、理解すべきこととして、本発明は開示された例示的な実施形態には限定されない。添付の請求項の範囲には、全ての修正物、及び均等な構造及び機能を包含するように、最も広い解釈が与えられる。

Claims (26)

1. 制御ノード（３０２）を含んだ第１のネットワーク（３００）の中で第１のユーザノード（１００）にサービス提供可能なサービスノード（２００）であって、前記第１のネットワークは、第２のユーザノード（４０１）を含んだ第２のネットワーク（５００）と通信可能であり、前記サービスノードは、
   前記第１のユーザノードから、前記第１のユーザネットワーク内で前記第１のユーザノードを識別する第１のユーザＩＤと前記第２のネットワーク内で前記第２のユーザノードを識別する第２のユーザＩＤとを含んだリダイレクト要求を受信する要求受信ユニット（２０３）と、
   前記第１のユーザＩＤと前記第２のユーザＩＤとの関連付けを格納する格納ユニット（２０７）と、
   前記制御ノードからメッセージを受信するメッセージ受信ユニット（２０５）と、
   前記メッセージが前記第１のユーザＩＤを宛先として含んでいるか、又は、前記メッセージが前記第１のユーザＩＤに対応する補助情報を含んでいるかを判定する判定ユニット（２０８）と、
   修正ユニット（２０９）であって、
   前記メッセージが前記第１のユーザＩＤを宛先として含んでいると前記判定ユニットが判定した場合に、前記関連付けに基づき、前記メッセージの前記宛先を前記第２のユーザＩＤに修正し、
   前記メッセージが前記補助情報を含んでいると前記判定ユニットが判定した場合に、前記補助情報に基づき、前記メッセージの発信元を前記第１のユーザＩＤに修正する
   前記修正ユニットと、
   前記修正されたメッセージを前記制御ノードへ送信する送信ユニット（２０６）と、
   を備える、サービスノード。
2. 前記要求受信ユニットは、前記補助情報を生成し、当該補助情報を前記第１のユーザノードへ送信し、
   前記格納ユニットは、前記第１のユーザＩＤに関連付けて前記補助情報を格納する、
   請求項１に記載のサービスノード。
3. 前記要求受信ユニットが前記リダイレクト要求を受信すると、前記制御ノードに対して、前記第１のユーザＩＤを宛先として含んだメッセージを前記サービスノードへ転送するように指示する指示ユニット（２０２）
   を更に備える、請求項１又は２に記載のサービスノード。
4. 前記要求受信ユニットは、前記第１のユーザノードから、前記第１のユーザＩＤを含んだリダイレクト無効化要求を受信し、
   前記指示ユニットは、前記要求受信ユニットが前記リダイレクト無効化要求を受信すると、前記制御ノードに対して、前記第１のユーザＩＤを宛先として含んだメッセージを前記サービスノードへ転送することを停止するように指示する、
   請求項３に記載のサービスノード。
5. 前記メッセージは、当該メッセージによって要求されるサービスのサービスタイプを特定し、
   前記リダイレクト要求は、各々がサービスタイプを特定する１以上のサービス識別子を含み、
   前記修正ユニットは、前記第１のユーザＩＤを宛先として含んだ前記メッセージによって特定されるサービスタイプをチェックし、
   前記修正ユニットは、前記メッセージによって特定されるサービスタイプが前記１以上のサービス識別子によって特定される１以上のサービスタイプの中に含まれているという条件下で、前記関連付けに基づき、前記メッセージの宛先を前記第２のユーザＩＤに修正する、
   請求項１乃至４のいずれか１項に記載のサービスノード。
6. 前記格納ユニットは、各々が前記第１のユーザノードがローミング可能なネットワークを特定する１以上のネットワーク識別子を格納し、
   前記サービスノードは、ネットワーク識別子を含んだ問合せに応えて、前記１以上のネットワーク識別子に基づき、前記第１のユーザノードが前記問合せに含まれる前記ネットワーク識別子によって特定されるネットワークにローミング可能であるか否かを前記第１のユーザノードに通知する通知ユニットを更に備える、
   請求項１乃至５のいずれか１項に記載のサービスノード。
7. 前記第１のネットワークは、第１のＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークであり、
   前記第２のネットワークは、第２のＩＭＳネットワークであり、
   前記第１のユーザＩＤは、前記第１のユーザノードのＩＭＳパブリック・ユーザ・アイデンティティ（ＩＭＰＵ）であり、
   前記第２のユーザＩＤは、前記第２のユーザノードのＩＭＰＵであり、
   前記メッセージは、セッション開始プロトコル（ＳＩＰ）要求メッセージであり、
   前記制御ノードは、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）を含み、
   前記修正ユニットは、前記補助情報を含んだ前記メッセージを、当該メッセージのＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダの中に前記第１のユーザＩＤが含まれるように修正する、
   請求項１乃至６のいずれか１項に記載のサービスノード。
8. 制御ノード（３０２）を含んだ第１のネットワーク（３００）の中で第１のユーザノード（１００）にサービス提供可能なサービスノード（２００）を制御する方法であって、前記第１のネットワークは、第２のユーザノード（４０１）を含んだ第２のネットワーク（５００）と通信可能であり、前記方法は、
   前記第１のユーザノードから、前記第１のユーザネットワーク内で前記第１のユーザノードを識別する第１のユーザＩＤと前記第２のネットワーク内で前記第２のユーザノードを識別する第２のユーザＩＤとを含んだリダイレクト要求を受信するステップ（Ｓ６０７）と、
   前記第１のユーザＩＤと前記第２のユーザＩＤとの関連付けを格納するステップ（Ｓ６０７）と、
   前記制御ノードからメッセージを受信するステップ（Ｓ７０２，Ｓ８０４）と、
   前記メッセージが前記第１のユーザＩＤを宛先として含んでいるか、又は、前記メッセージが前記第１のユーザＩＤに対応する補助情報を含んでいるかを判定するステップ（Ｓ７０３，Ｓ８０５）と、
   前記メッセージが前記第１のユーザＩＤを宛先として含んでいると前記判定するステップが判定した場合に、前記関連付けに基づき、前記メッセージの前記宛先を前記第２のユーザＩＤに修正するステップ（Ｓ７０３）と、
   前記メッセージが前記補助情報を含んでいると前記判定するステップが判定した場合に、前記補助情報に基づき、前記メッセージの発信元を前記第１のユーザＩＤに修正するステップ（Ｓ８０５）と、
   前記修正されたメッセージを前記制御ノードへ送信するステップ（Ｓ７０３，Ｓ８０５）と、
   を備える、方法。
9. 前記リダイレクト要求を受信する前記ステップは、前記補助情報を生成し、当該補助情報を前記第１のユーザノードへ送信し、
   前記格納するステップは、前記第１のユーザＩＤに関連付けて前記補助情報を格納する、
   請求項８に記載の方法。
10. 前記リダイレクト要求を受信する前記ステップにおいて前記リダイレクト要求が受信されると、前記制御ノードに対して、前記第１のユーザＩＤを宛先として含んだメッセージを前記サービスノードへ転送するように指示するステップ（Ｓ６０８）
    を更に備える、請求項８又は９に記載の方法。
11. 前記リダイレクト要求を受信する前記ステップは、前記第１のユーザノードから、前記第１のユーザＩＤを含んだリダイレクト無効化要求を受信し、
    前記指示するステップは、前記リダイレクト要求を受信する前記ステップにおいて前記リダイレクト無効化要求が受信されると、前記制御ノードに対して、前記第１のユーザＩＤを宛先として含んだメッセージを前記サービスノードへ転送することを停止するように指示する、
    請求項１０に記載の方法。
12. 前記メッセージは、当該メッセージによって要求されるサービスのサービスタイプを特定し、
    前記リダイレクト要求は、各々がサービスタイプを特定する１以上のサービス識別子を含み、
    前記宛先を修正する前記ステップは、前記第１のユーザＩＤを宛先として含んだ前記メッセージによって特定されるサービスタイプをチェックし、
    前記宛先を修正する前記ステップは、前記メッセージによって特定されるサービスタイプが前記１以上のサービス識別子によって特定される１以上のサービスタイプの中に含まれているという条件下で、前記関連付けに基づき、前記メッセージの宛先を前記第２のユーザＩＤに修正する、
    請求項８乃至１１のいずれか１項に記載の方法。
13. 前記格納するステップは、各々が前記第１のユーザノードがローミング可能なネットワークを特定する１以上のネットワーク識別子を格納し、
    前記方法は、ネットワーク識別子を含んだ問合せに応えて、前記１以上のネットワーク識別子に基づき、前記第１のユーザノードが前記問合せに含まれる前記ネットワーク識別子によって特定されるネットワークにローミング可能であるか否かを前記第１のユーザノードに通知するステップ（Ｓ５０７）を更に備える、
    請求項８乃至１２のいずれか１項に記載の方法。
14. 前記第１のネットワークは、第１のＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークであり、
    前記第２のネットワークは、第２のＩＭＳネットワークであり、
    前記第１のユーザＩＤは、前記第１のユーザノードのＩＭＳパブリック・ユーザ・アイデンティティ（ＩＭＰＵ）であり、
    前記第２のユーザＩＤは、前記第２のユーザノードのＩＭＰＵであり、
    前記メッセージは、セッション開始プロトコル（ＳＩＰ）要求メッセージであり、
    前記制御ノードは、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）を含み、
    前記発信元を修正する前記ステップは、前記補助情報を含んだ前記メッセージを、当該メッセージのＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダの中に前記第１のユーザＩＤが含まれるように修正する、
    請求項８乃至１３のいずれか１項に記載の方法。
15. 第１のネットワーク（３００）の中のサービスノード（２００）及び第１の制御ノード（３０２）、及び、第２の制御ノード（５０２）を含んだ第２のネットワーク（５００）の中の他のユーザノード（４０１）と通信可能なユーザノード（１００）であって、
    メモリ（１５０）から、前記第１のネットワーク内で前記ユーザノードを識別する第１のユーザＩＤを引き出す引き出しユニット（１０３）と、
    前記他のユーザノードから、前記第２のネットワーク内で前記他のユーザノードを識別する第２のユーザＩＤを受信するユーザＩＤ受信ユニット（１０６）と、
    前記第２のユーザＩＤを前記他のユーザノード経由で前記第２の制御ノードに登録する登録ユニット（１０５）と、
    前記サービスノードへ、前記第１のユーザＩＤ及び前記第２のユーザＩＤを含んだリダイレクト要求を送信する要求送信ユニット（１０７）と、
    前記他のユーザノードへ、前記第１のネットワーク内で前記サービスノードを識別するサービスノードＩＤと前記第１のユーザＩＤに対応する補助情報とを含んだメッセージを送信することにより、前記サービスノードＩＤにより前記第１の制御ノードが前記メッセージを前記サービスノードへルーティングするようにする、メッセージ送信ユニット（１０９）と、
    を備える、ユーザノード。
16. 前記要求送信ユニットは、前記サービスノードから前記補助情報を受信する、
    請求項１５に記載のユーザノード。
17. 前記ユーザＩＤ受信ユニットは、前記他のユーザノードから、各々がサービスタイプを特定する１以上のサービス識別子を受信し、
    前記要求送信ユニットは、前記サービスノードへ、前記１以上のサービス識別子の全て又は一部を送信する、
    請求項１５又は１６に記載のユーザノード。
18. 前記メッセージは、当該メッセージによって要求されるサービスのサービスタイプを特定し、
    前記メッセージ送信ユニットは、前記メッセージによって特定されるサービスタイプが前記１以上のサービス識別子によって特定される１以上のサービスタイプの中に含まれない場合、前記他のユーザノードの代わりに前記第１の制御ノードへ前記メッセージを送信する、
    請求項１７に記載のユーザノード。
19. 前記第２のネットワークを識別するネットワークＩＤを受信するネットワークＩＤ受信ユニット（１０４）と、
    前記ユーザノードが前記ネットワークＩＤによって識別される前記第２のネットワークにローミング可能であるか否かを前記サービスノードに問い合わせる問合せユニット（１０８）と、
    を更に備える、請求項１５乃至１８のいずれか１項に記載のユーザノード。
20. 前記第１のネットワークは、第１のＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークであり、
    前記第２のネットワークは、第２のＩＭＳネットワークであり、
    前記第１のユーザＩＤは、前記ユーザノードのＩＭＳパブリック・ユーザ・アイデンティティ（ＩＭＰＵ）であり、
    前記第２のユーザＩＤは、前記他のユーザノードのＩＭＰＵであり、
    前記サービスノードＩＤは、前記サービスノードのユニフォーム・リソース・アイデンティファイア（ＵＲＩ）であり、
    前記メモリは、前記第１のユーザＩＤを維持管理するＩＭＳ加入者ＩＤモジュール（ＩＳＩＭ）を格納するユニバーサルＩＣカード（ＵＩＣＣ）であり、
    前記メッセージは、セッション開始プロトコル（ＳＩＰ）要求メッセージであり、
    前記第１の制御ノードは、第１のサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）を含み、
    前記第２の制御ノードは、第２のＳ−ＣＳＣＦを含み、
    前記メッセージは、当該メッセージのＲｏｕｔｅヘッダの中に前記サービスノードＩＤを含む、
    請求項１５乃至１９のいずれか１項に記載のユーザノード。
21. 第１のネットワーク（３００）の中のサービスノード（２００）及び第１の制御ノード（３０２）、及び、第２の制御ノード（５０２）を含んだ第２のネットワーク（５００）の中の他のユーザノード（４０１）と通信可能なユーザノード（１００）を制御する方法であって、
    メモリ（１５０）から、前記第１のネットワーク内で前記ユーザノードを識別する第１のユーザＩＤを引き出すステップ（Ｓ５０１）と、
    前記他のユーザノードから、前記第２のネットワーク内で前記他のユーザノードを識別する第２のユーザＩＤを受信するステップ（Ｓ６０２）と、
    前記第２のユーザＩＤを前記他のユーザノード経由で前記第２の制御ノードに登録するステップ（Ｓ６０３）と、
    前記サービスノードへ、前記第１のユーザＩＤ及び前記第２のユーザＩＤを含んだリダイレクト要求を送信するステップ（Ｓ６０７）と、
    前記他のユーザノードへ、前記第１のネットワーク内で前記サービスノードを識別するサービスノードＩＤと前記第１のユーザＩＤに対応する補助情報とを含んだメッセージを送信することにより、前記サービスノードＩＤにより前記第１の制御ノードが前記メッセージを前記サービスノードへルーティングするようにする、ステップ（Ｓ８０１）と、
    を備える、方法。
22. 前記リダイレクト要求を送信する前記ステップは、前記サービスノードから前記補助情報を受信する、
    請求項２１に記載の方法。
23. 前記第２のユーザＩＤを受信する前記ステップは、前記他のユーザノードから、各々がサービスタイプを特定する１以上のサービス識別子を受信し、
    前記リダイレクト要求を送信する前記ステップは、前記サービスノードへ、前記１以上のサービス識別子の全て又は一部を送信する、
    請求項２１又は２２に記載の方法。
24. 前記メッセージは、当該メッセージによって要求されるサービスのサービスタイプを特定し、
    前記メッセージを送信する前記ステップは、前記メッセージによって特定されるサービスタイプが前記１以上のサービス識別子によって特定される１以上のサービスタイプの中に含まれない場合、前記他のユーザノードの代わりに前記第１の制御ノードへ前記メッセージを送信する、
    請求項２３に記載の方法。
25. 前記第２のネットワークを識別するネットワークＩＤを受信するステップ（Ｓ５０５）と、
    前記ユーザノードが前記ネットワークＩＤによって識別される前記第２のネットワークにローミング可能であるか否かを前記サービスノードに問い合わせるステップ（Ｓ５０６）と、
    を更に備える、請求項２１乃至２４のいずれか１項に記載の方法。
26. 前記第１のネットワークは、第１のＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークであり、
    前記第２のネットワークは、第２のＩＭＳネットワークであり、
    前記第１のユーザＩＤは、前記ユーザノードのＩＭＳパブリック・ユーザ・アイデンティティ（ＩＭＰＵ）であり、
    前記第２のユーザＩＤは、前記他のユーザノードのＩＭＰＵであり、
    前記サービスノードＩＤは、前記サービスノードのユニフォーム・リソース・アイデンティファイア（ＵＲＩ）であり、
    前記メモリは、前記第１のユーザＩＤを維持管理するＩＭＳ加入者ＩＤモジュール（ＩＳＩＭ）を格納するユニバーサルＩＣカード（ＵＩＣＣ）であり、
    前記メッセージは、セッション開始プロトコル（ＳＩＰ）要求メッセージであり、
    前記第１の制御ノードは、第１のサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）を含み、
    前記第２の制御ノードは、第２のＳ−ＣＳＣＦを含み、
    前記メッセージは、当該メッセージのＲｏｕｔｅヘッダの中に前記サービスノードＩＤを含む、
    請求項２１乃至２５のいずれか１項に記載の方法。

Images