JP2013521721A - インターネットプロトコルマルチメディアサブシステム協調セッションにおける識別および移転のための方法および装置 - Google Patents

Abstract

ＩＭＳ（ＩＰ（インターネットプロトコル）マルチメディアサブシステム）動作を実行するための方法および装置が説明される。ＷＴＲＵ（無線送受信ユニット）は、ＩＭＳサービスプライオリティをＩＭＳネットワークに登録する。ＩＭＳサービスプライオリティは、ＩＭＳサービスを受ける際の、ＷＴＲＵのプライオリティを示す。ＷＴＲＵは、ＷＴＲＵのＩＭＳサービスプライオリティに基づいて、ＩＭＳネットワークからＩＭＳサービスを受けることができる。ＩＭＳサービスプライオリティは、プライオリティ値を使用して示すことができ、ＷＴＲＵは、ＳＩＰ（セッション開始プロトコル）メッセージングを使用して、ＩＭＳネットワークとシグナリングを行うことができる。ＷＴＲＵは、ＳＩＰ Ｃｏｎｔａｃｔフィールドヘッダ内のｑ値パラメータを使用して、サービスプライオリティ値を登録することができる。ＷＴＲＵは、パブリックユーザアイデンティティもＩＭＳネットワークに登録することができ、パブリックユーザアイデンティティは、他のＩＭＳ対応ＷＴＲＵと共有することができる。

Description

本出願は、通信に関する。

関連出願の相互参照
本出願は、２０１０年３月４日に出願された米国仮出願第６１／３１０，４８６号、および２０１０年３月２６日に出願された米国仮出願第６１／３１７，９８８号の利益を主張し、それらの内容は、参照により本明細書に組み込まれる。

ＩＭＳ（ＩＰ（インターネットプロトコル）マルチメディアサブシステム）は、マルチメディアサービスを様々なアクセスプラットフォームに提供するための、アーキテクチャフレームワークである。ＩＭＳは、インターネットプロトコルに基づいた、マルチメディアサービスの生成および配備を容易にし、ＩＭＳ加入者が、どのデバイス上でも、またどこからでも、カスタマイズされた対話的なマルチメディアサービスにアクセスすることを可能にする。ＩＭＳは、アクセス方法に依存せず（ａｃｃｅｓｓ−ａｇｎｏｓｔｉｃ）、それによって、サービス配信は、基層のアクセスプラットフォームから独立しており、ＩＭＳにおけるインターネットプロトコルの使用は、アクセスプラットフォームの間の相互運用性を可能にする。ＩＭＳは、ネットワークインフラストラクチャ、運営、および管理の面での省力化をももたらす。さらに、ＩＭＳは、別個の制御機能とベアラ機能を使用すること、およびパケット交換ネットワークインフラストラクチャ上のオーバレイサービス配信ネットワークを特徴とすることによって、音声電話などのＣＳ（回路交換）サービスをＰＳ（パケット交換）ドメインに移行させることを可能にする。

ＩＭＳでは、メディアセッションは、ＩＭＳネットワークを介して通信する複数のＩＭＳ対応デバイスのいずれか１つに送ることができる。したがって、ＩＭＳネットワークは、メディアセッションの回送（ルーティング）に関する決定、およびそのような決定をどのように伝えるべきかに直面することがある。加えて、複数のＩＭＳ対応デバイスは、複数のＩＭＳネットワークおよびネットワークの機能エンティティによるサービスを受けることができ、それによって、様々なネットワークは、ＩＭＳセッションの管理に関する決定に直面することがあるが、様々なネットワークは、不必要なシグナリングトラフィックを生じさせずに、それを解決しようとすることがある。

したがって、回送についての選好をＩＭＳネットワークに知らせるための、ＩＭＳ対応デバイスのための方法および装置があれば望ましい。さらに、効率的にそれぞれの役割を識別し、移転するための、ＩＭＳネットワークおよびＩＭＳ対応デバイスのための方法および装置があれば望ましい。

ＩＭＳ（ＩＰ（インターネットプロトコル）マルチメディアサブシステム）動作を実行するための方法および装置が説明される。無線送受信ユニット（ＷＴＲＵ）は、ＩＭＳサービスプライオリティをＩＭＳネットワークに登録する。ＩＭＳサービスプライオリティは、ＩＭＳサービスを受ける際の、ＷＴＲＵのプライオリティを示す。ＷＴＲＵは、ＷＴＲＵのＩＭＳサービスプライオリティに基づいて、ＩＭＳネットワークからＩＭＳサービスを受けることができる。ＩＭＳサービスプライオリティは、プライオリティ値を使用して示すことができ、ＷＴＲＵは、ＳＩＰ（セッション開始プロトコル）メッセージングを使用して、ＩＭＳネットワークとシグナリングを行うことができる。ＷＴＲＵは、ＳＩＰ Ｃｏｎｔａｃｔフィールドヘッダ内のｑ値パラメータを使用して、サービスプライオリティ値を登録することができる。ＷＴＲＵは、パブリックユーザアイデンティティもＩＭＳネットワークに登録することができ、パブリックユーザアイデンティティは、他のＩＭＳ対応ＷＴＲＵと共有することができる。

より詳細な理解は、添付の図面を併用して例によって与えられる、以下の説明から得ることができる。

１つまたは複数の開示される実施形態を実施できる例示的な通信システムのシステム図である。 図１Ａに示された通信システム内で使用できる例示的なＷＴＲＵ（無線送受信ユニット）のシステム図である。 図１Ａに示された通信システム内で使用できる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 リモートパーティとのＩＭＳセッション中のＷＴＲＵを示す図である。 ＩＭＳネットワーク内の機能エンティティを示す図である。 協調ＩＭＳセッション中の、単一のＩＭＳネットワークによってサービスされる複数のＷＴＲＵを示す図である。 説明される実施形態による、ＷＴＲＵ登録およびＩＭＳセッション回送のための情報フローを示す図である。 ＩＭＳ協調セッション中の、複数のＩＭＳネットワークによってサービスされる複数のＷＴＲＵを示す図である。 説明される実施形態による、アンカＳＣＣ ＡＳ（サービス集中および継続アプリケーションサーバ）識別および移転のための情報フローを示す図である。 ＩＭＳ協調セッション制御の移転のための情報フローを示す図である。

図１Ａは、１つまたは複数の開示される実施形態を実施できる例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムとすることができる。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通して、そのようなコンテンツにアクセスできるようにすることができる。例えば、通信システム１００は、ＣＤＭＡ（符号分割多元接続）、ＴＤＭＡ（時分割多元接続）、ＦＤＭＡ（周波数分割多元接続）、ＯＦＤＭＡ（直交ＦＤＭＡ）、およびＳＣ−ＦＤＭＡ（シングルキャリアＦＤＭＡ）など、１つまたは複数のチャネルアクセス方法を利用することができる。

図１Ａに示されるように、通信システム１００は、ＷＴＲＵ（無線送受信ユニット）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、ＲＡＮ（無線アクセスネットワーク）１０４、コアネットワーク１０６、ＰＳＴＮ（公衆交換電話網）１０８、インターネット１１０、および他のネットワーク１１２を含むことができるが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図していることが理解されよう。ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例を挙げると、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成することができ、ＵＥ（ユーザ機器）、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、ＰＤＡ（携帯情報端末）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、および家電製品などを含むことができる。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含むことができる。基地局１１４ａ、１１４ｂの各々は、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを円滑化するために、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線でインタフェースを取るように構成された、任意のタイプのデバイスとすることができる。例を挙げると、基地局１１４ａ、１１４ｂは、ＢＴＳ（トランシーバ基地局）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、ＡＰ（アクセスポイント）、および無線ルータなどとすることができる。基地局１１４ａ、１１４ｂは各々、単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることが理解されよう。

基地局１１４ａは、ＲＡＮ １０４の部分とすることができ、ＲＡＮ １０４は、他の基地局、および／またはＢＳＣ（基地局コントローラ）、ＲＮＣ（無線ネットワークコントローラ）、中継ノードなどのネットワーク要素（図示せず）も含むことができる。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれることがある特定の地理的領域内で、無線信号を送信および／または受信するように構成することができる。セルは、さらにセルセクタに分割することができる。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割することができる。したがって、一実施形態では、基地局１１４ａは、トランシーバを３つ、すなわち、セルのセクタ毎に１つずつ含むことができる。別の実施形態では、基地局１１４ａは、ＭＩＭＯ（多入力多出力）技術を利用することができ、したがって、セルのセクタ毎に複数のトランシーバを利用することができる。

基地局１１４ａ、１１４ｂは、エアインタフェース１１６を介して、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数と通信することができ、エアインタフェース１１６は、任意の適切な無線通信リンク（例えば、ＲＦ（無線周波）、マイクロ波、ＩＲ（赤外線）、ＵＶ（紫外線）、可視光など）とすることができる。エアインタフェース１１６は、任意の適切なＲＡＴ（無線アクセス技術）を使用して確立することができる。

より具体的には、上で言及したように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの、１つまたは複数のチャネルアクセス方式を利用することができる。例えば、ＲＡＮ １０４内の基地局１１４ａ、およびＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃは、ＷＣＤＭＡ（広帯域ＣＤＭＡ）を使用してエアインタフェース１１６を確立できる、ＵＴＲＡ（ＵＭＴＳ（ユニバーサル移動体通信システム）地上無線アクセス）などの無線技術を実施することができる。ＷＣＤＭＡは、ＨＳＰＡ（高速パケットアクセス）および／またはＨＳＰＡ＋（進化型ＨＳＰＡ）などの通信プロトコルを含むことができる。ＨＳＰＡは、ＨＳＤＰＡ（高速ダウンリンクパケットアクセス）および／またはＨＳＵＰＡ（高速アップリンクパケットアクセス）を含むことができる。

別の実施形態では、基地局１１４ａ、およびＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃは、ＬＴＥ（ロングタームエボリューション）および／またはＬＴＥ−Ａ（ＬＴＥアドバンスト）を使用してエアインタフェース１１６を確立できる、Ｅ−ＵＴＲＡ（進化型ＵＭＴＳ地上無線アクセス）などの無線技術を実施することができる。

他の実施形態では、基地局１１４ａ、およびＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ ８０２．１６（すなわちＷｉＭＡＸ（マイクロ波アクセス用の世界的相互運用性））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、ＩＳ−２０００（暫定標準２０００）、ＩＳ−９５（暫定標準９５）、ＩＳ−８５６（暫定標準８５６）、ＧＳＭ（登録商標）（移動体通信用グローバルシステム）、ＥＤＧＥ（ＧＳＭ進化型高速データレート）、およびＧＥＲＡＮ（ＧＳＭ ＥＤＧＥ）などの無線技術を実施することができる。

図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントとすることができ、職場、家庭、乗物、およびキャンパスなどの局所的エリアにおける無線接続性を円滑化するために、任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂ、およびＷＴＲＵ １０２ｃ、１０２ｄは、ＩＥＥＥ ８０２．１１などの無線技術を実施して、ＷＬＡＮ（無線ローカルエリアネットワーク）を確立することができる。別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ １０２ｃ、１０２ｄは、ＩＥＥＥ ８０２．１５などの無線技術を実施して、ＷＰＡＮ（無線パーソナルエリアネットワーク）を確立することができる。また別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ １０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接的な接続を有することがある。したがって、基地局１１４ｂは、コアネットワーク１０６を介して、インターネット１１０にアクセスする必要がないことがある。

ＲＡＮ １０４は、コアネットワーク１０６と通信することができ、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはＶｏＩＰ（ボイスオーバインターネットプロトコル）サービスをＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供することができ、および／またはユーザ認証など、高レベルのセキュリティ機能を実行することができる。図１Ａには示されていないが、ＲＡＮ １０４および／またはコアネットワーク１０６は、ＲＡＮ １０４と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接的または間接的に通信できることが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用できるＲＡＮ １０４に接続するのに加えて、コアネットワーク１０６は、ＧＳＭ無線技術を利用する別のＲＡＮ（図示せず）と通信することもできる。

コアネットワーク１０６は、ＰＳＴＮ １０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするための、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイとしてサービスすることもできる。ＰＳＴＮ １０８は、ＰＯＴＳ（基本電話サービス）を提供する回路交換電話網を含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内のＴＣＰ（伝送制御プロトコル）、ＵＤＰ（ユーザデータグラムプロトコル）、およびＩＰ（インターネットプロトコル）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークとデバイスとからなるグローバルシステムを含むことができる。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される有線または無線通信ネットワークを含むことができる。例えば、ネットワーク１１２は、ＲＡＮ １０４と同じＲＡＴまたは異なるＲＡＴを利用できる１つまたは複数のＲＡＮに接続された、別のコアネットワークを含むことができる。

通信システム１００内のＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含むことができる。例えば、図１Ａに示されたＷＴＲＵ １０２ｃは、セルラベースの無線技術を利用できる基地局１１４ａと通信するように、またＩＥＥＥ ８０２無線技術を利用できる基地局１１４ｂと通信するように構成することができる。

図１Ｂは、例示的なＷＴＲＵ １０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ １０２は、プロセッサ１１８と、トランシーバ１２０と、送信／受信要素１２２と、スピーカ／マイクロフォン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、着脱不能メモリ１０６と、着脱可能メモリ１３２と、電源１３４と、ＧＰＳ（全地球測位システム）チップセット１３６と、他の周辺機器１３８とを含むことができる。ＷＴＲＵ １０２は、一実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含むことができる。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ＤＳＰ（デジタル信号プロセッサ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）回路、他の任意のタイプのＩＣ（集積回路）、および状態機械などとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ １０２が無線環境で動作できるようにする他の任意の機能を実行することができる。プロセッサ１１８は、トランシーバ１２０に結合することができ、トランシーバ１２０は、送信／受信要素１２２に結合することができる。図１Ｂは、プロセッサ１１８とトランシーバ１２０を別々のコンポーネントとして示しているが、プロセッサ１１８とトランシーバ１２０は、電子パッケージまたはチップ内に一緒に統合できることが理解されよう。

送信／受信要素１２２は、エアインタフェース１１６を介して、基地局（例えば基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成することができる。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。別の実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放射器／検出器とすることができる。また別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成することができる。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成できることが理解されよう。

加えて、図１Ｂでは、送信／受信要素１２２は単一の要素として示されているが、ＷＴＲＵ １０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ １０２は、ＭＩＭＯ技術を利用することができる。したがって、一実施形態では、ＷＴＲＵ １０２は、エアインタフェース１１６を介して無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば複数のアンテナ）を含むことができる。

トランシーバ１２０は、送信／受信要素１２２によって送信される信号を変調し、送信／受信要素１２２によって受信された信号を復調するように構成することができる。上で言及したように、ＷＴＲＵ １０２は、マルチモード機能を有することができる。したがって、トランシーバ１２０は、ＷＴＲＵ １０２が、例えばＵＴＲＡおよびＩＥＥＥ ８０２．１１などの複数のＲＡＴを介して通信できるようにするための、複数のトランシーバを含むことができる。

ＷＴＲＵ １０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、ＬＣＤ（液晶表示）ディスプレイユニットもしくはＯＬＥＤ（有機発光ダイオード）ディスプレイユニット）に結合することができ、それらからユーザ入力データを受け取ることができる。プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。加えて、プロセッサ１１８は、着脱不能メモリ１０６および／または着脱可能メモリ１３２など、任意のタイプの適切なメモリから情報を入手することができ、それらにデータを記憶することができる。着脱不能メモリ１０６は、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（リードオンリメモリ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含むことができる。着脱可能メモリ１３２は、ＳＩＭ（加入者識別モジュール）カード、メモリスティック、およびＳＤ（セキュアデジタル）メモリカードなどを含むことができる。他の実施形態では、プロセッサ１１８は、ＷＴＲＵ １０２上に物理的に配置されたメモリではなく、サーバまたはホームコンピュータ（図示せず）などの上に配置されたメモリから情報を入手することができ、それらにデータを記憶することができる。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ １０２内の他のコンポーネントへの電力の分配および／または制御を行うように構成することができる。電源１３４は、ＷＴＲＵ １０２に給電するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ＮｉＣｄ（ニッケル−カドミウム）、ＮｉＺｎ（ニッケル−亜鉛）、ＮｉＭＨ（ニッケル水素）、Ｌｉ−ｉｏｎ（リチウムイオン）など）、太陽電池、および燃料電池などを含むことができる。

プロセッサ１１８は、ＧＰＳチップセット１３６に結合することもでき、ＧＰＳチップセット１３６は、ＷＴＲＵ １０２の現在位置に関する位置情報（例えば経度および緯度）を提供するように構成することができる。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ １０２は、基地局（例えば基地局１１４ａ、１１４ｂ）からエアインタフェース１１６を介して位置情報を受け取ることができ、および／または２つ以上の近くの基地局から受信した信号のタイミングに基づいて、自らの位置を決定することができる。ＷＴＲＵ １０２は、一実施形態との整合性を保ちながら、任意の適切な位置決定方法を用いて、位置情報を獲得できることが理解されよう。

プロセッサ１１８は、他の周辺機器１３８にさらに結合することができ、他の周辺機器１３８は、追加的な特徴、機能、および／または有線もしくは無線接続性を提供する、１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。例えば、周辺機器１３８は、加速度計、ｅコンパス、衛星トランシーバ、（写真またはビデオ用の）デジタルカメラ、ＵＳＢ（ユニバーサルシリアルバス）ポート、バイブレーションデバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭ（周波数変調）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含むことができる。

図１Ｃは、一実施形態による、ＲＡＮ １０４およびコアネットワーク１０６のシステム図である。上で言及したように、ＲＡＮ １０４は、エアインタフェース１１６を介してＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃと通信するために、Ｅ−ＵＴＲＡ無線技術を利用することができる。ＲＡＮ １０４は、コアネットワーク１０６と通信することもできる。

ＲＡＮ １０４は、ｅノードＢ １４０ａ、１４０ｂ、１４０ｃを含むことができるが、ＲＡＮ １０４は、一実施形態との整合性を保ちながら、任意の数のｅノードＢを含むことができることが理解されよう。ｅノードＢ １４０ａ、１４０ｂ、１４０ｃは、各々が、エアインタフェース１１６を介してＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含むことができる。一実施形態では、ｅノードＢ １４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実施することができる。したがって、ｅノードＢ １４０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ １０２ａに無線信号を送信し、ＷＴＲＵ １０２ａから無線信号を受信することができる。

ｅノードＢ １４０ａ、１４０ｂ、１４０ｃの各々は、特定のセル（図示せず）に関連付けることができ、無線リソース管理決定、ハンドオーバ決定、ならびにアップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成することができる。図１Ｃに示されるように、ｅノードＢ １４０ａ、１４０ｂ、１４０ｃは、Ｘ２インタフェースを介して互いに通信することができる。

図１Ｃに示されるコアネットワーク１０６は、ＭＭＥ（モビリティ管理ゲートウェイ）１４２、サービングゲートウェイ１４４、およびＰＤＮ（パケットデータネットワーク）ゲートウェイ１４６を含むことができる。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワーク運営体とは異なる主体によって所有および／または運営できることが理解されよう。

ＭＭＥ １４２は、Ｓ１インタフェースを介して、ＲＡＮ １０４内のｅノードＢ １４２ａ、１４２ｂ、１４２ｃの各々に接続することができ、制御ノードとしての役割を果たすことができる。例えば、ＭＭＥ １４２は、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラ・アクティベーション／ディアクティベーション、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃの初期接続中における特定のサービングゲートウェイの選択などを担うことができる。ＭＭＥ １４２は、ＲＡＮ １０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を利用する他のＲＡＮ（図示せず）との間の交換のための制御プレーン機能を提供することもできる。

サービングゲートウェイ１４４は、Ｓ１インタフェースを介して、ＲＡＮ １０４内のｅノードＢ １４０ａ、１４０ｂ、１４０ｃの各々に接続することができる。サービングゲートウェイ１４４は、一般に、ユーザデータパケットをＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃに／からルーティングおよび転送することができる。サービングゲートウェイ１４４は、ｅノードＢ間ハンドオーバ中におけるユーザプレーンのアンカリング（ａｎｃｈｏｒｉｎｇ）、ダウンリンクデータがＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃに利用可能な場合に行う一斉呼出のトリガ、ならびにＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および記憶など、他の機能を実行することもできる。

サービングゲートウェイ１４４は、ＰＤＮゲートウェイ１４６に接続することもでき、ＰＤＮゲートウェイ１４６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスの間の通信を円滑化することができる。

コアネットワーク１０６は、他のネットワークとの通信を円滑化することができる。例えば、コアネットワーク１０６は、ＰＳＴＮ １０８などの回路交換ネットワークへのアクセスをＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスの間の通信を円滑化することができる。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ １０８の間のインタフェースとしての役割を果たすＩＰゲートウェイ（例えばＩＭＳ（ＩＰマルチメディアサブシステム）サーバ）を含むことができ、またはＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０６は、ネットワーク１１２へのアクセスをＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことができる。

図２Ａは、リモートパーティ２０５とのＩＭＳセッション中のＷＴＲＵ ２０１を示している。ＩＭＳセッションは、ＩＭＳネットワーク２１０を介して行われる。ＷＴＲＵ ２０１は、リモートパーティとの進行中のメディアセッションを任意の数だけ有することができる。例えば、図２Ａは、オーディオセッション２０２およびビデオセッション２０３を示している。これらのセッションは例示的なものであり、他のマルチメディアセッションも使用することができる。ＩＭＳネットワーク２１０は、ＩＭＳサービスをホストし、セッション制御およびメディア制御を提供する。ＩＭＳネットワーク２１０は、ＷＴＲＵのサービスインタラクションを管理し、マルチメディアセッションを確立し、監視し、支援し、解放する。

さらに、ＷＴＲＵ ２０１は、ＩＭＳネットワーク２１０とのＩＭＳ制御シグナリング２０４を維持する。ＷＴＲＵは、ＩＭＳ制御シグナリング２０４を使用して、セッション制御機能を実行することができる。ＩＭＳ制御シグナリングは、ＷＴＲＵが、リモートパーティから着信したメディアセッションの確立を求める要求を了承または拒否することを可能にする。ＷＴＲＵ ２０１は、制御パス２０４上でＩＭＳ制御シグナリングを実行する。ＩＭＳネットワーク２１０は、ＷＴＲＵのＩＭＳ制御シグナリング２０４の受信側に位置する。

図２Ｂは、ＩＭＳネットワーク２１０の機能エンティティを示している。ＣＳＣＦ（呼セッション制御機能）エンティティ２１３が、ＷＴＲＵ、リモートパーティ、および他のＩＭＳネットワークエンティティの間のＩＭＳ制御シグナリングのパス上に存在する。ＣＳＣＦエンティティは、ＷＴＲＵ、リモートパーティ、および他のＩＭＳネットワークエンティティのメッセージングを検査することができる。ＣＳＣＦエンティティは、ＩＭＳサービスを提供するために、どのＡＳ（アプリケーションサーバ）に制御メッセージングを転送するかを決定する。ＣＳＣＦエンティティは、回送（ルーティング）サービスを提供し、ネットワーク運営体の方針（ポリシー）を実施する。ＣＳＣＦエンティティは、ＷＴＲＵ登録も扱う。

ＩＭＳネットワークは、１つまたは複数のＡＳを使用することができる。１つまたは複数のＡＳは、ＩＭＳサービスをホストおよび実行し、ＣＳＣＦ ２１３とインタフェースを取るように構成される。ＳＣＣ ＡＳ（サービス集中および継続ＡＳ）２１４は、ＩＭＳセッションのアンカ（ａｎｃｈｏｒ）を務め、メディアセッションの提供およびメディアセッションのＷＴＲＵの間での移転の実行、メディアフローの組み合わせおよび分解、ならびにメディアフローの追加を含む、メディアセッションのためのサービス継続性を可能にする。ＳＣＣ ＡＳ ２１４だけではなく、図２Ｂに示されるＡＳ ２１５などの他のＡＳも、他のＩＭＳ関連サービスを提供するために、ＣＳＣＦ ２１３とインタフェースを取ることができる。

図２Ｂに示されるように、ＷＴＲＵ ２０１は、制御パス２１２によって表される、ＩＭＳネットワーク２１０との制御シグナリングを有する。ＷＴＲＵ ２０１は、一括してメディアパス２１１によって表される、任意の数のＩＭＳメディアセッションも有することができる。図２Ｂは、ＩＭＳセッションのためのアクセスレグ（ａｃｃｅｓｓ ｌｅｇ）およびリモートレグ（ｒｅｍｏｔｅ ｌｅｇ）も示している。アクセスレグは、ＷＴＲＵとＳＣＣ ＡＳの間の制御レグであり、リモートレグは、ＳＣＣ ＡＳとリモートパーティの間の制御レグである。

複数のＷＴＲＵが、ＩＭＳネットワークを介して、リモートパーティとの単一の協調ＩＭＳセッションに係わることができる。図２Ｃは、協調ＩＭＳセッション中の、単一のＩＭＳネットワークによってサービスされる複数のＷＴＲＵを示している。図２Ｃでは、ＷＴＲＵ ２０１Ａ〜Ｃ（これ以降、一括して数字だけによってＷＴＲＵ ２０１と呼ばれる）が、リモートパーティ（図示せず）との協調ＩＭＳセッションに係わっている。各ＷＴＲＵ ２０１は、制御パス２１２Ａ〜Ｃと、メディアパス２１１Ａ〜Ｃとを有する。メディアパス２１１は、ＷＴＲＵ ２０１の進行中のメディアセッションを表す。制御パス２１２は、ＷＴＲＵ ２０１のための制御シグナリングを表す。

ＷＴＲＵ ２０１のすべてが、協調ＩＭＳセッションに係わるが、ＷＴＲＵ ２０１の１つが、協調セッションのためのコントローラＷＴＲＵとして機能する。図２Ｃでは、ＷＴＲＵ Ａ ２０１Ａが、協調セッションのためのコントローラＷＴＲＵとして機能する。コントローラとして、ＷＴＲＵ Ａ ２０１Ａは、ＩＤＴ（デバイス間移転）手順を実行することができ、ＩＤＴ手順によって、ＷＴＲＵ Ａ ２０１Ａは、協調セッションに係わる任意のＷＴＲＵ ２０１において、メディアセッションを追加し、移転し、複製し、削除することができる。さらに、ＷＴＲＵ Ａ ２０１Ａなど、協調セッション中のコントローラＷＴＲＵのサービスプロファイルは、協調セッションとリモートパーティの間のパス上で利用可能なサービスを決定することができる。

すべてのＷＴＲＵ ２０１との協調セッションに係わるが、リモートパーティは、そのメディアセッションの１つまたは複数が、ＷＴＲＵ Ｂ ２０１ＢおよびＷＴＲＵ Ｃ ２０１Ｃなどのコントローリ（ｃｏｎｔｒｏｌｌｅｅ）ＷＴＲＵとのものであることを知ることができない。協調セッションでは、リモートパーティは、コントローラＷＴＲＵであるＷＴＲＵ Ａ ２０１Ａしか知ることができない。コントローラＷＴＲＵ Ａ ２０１Ａは、自らのメディアパス２１１に関連する制御シグナリングのためばかりでなく、協調セッション制御メッセージングのためにも、制御パス２１２Ａを使用する。協調セッション内では、コントローリＷＴＲＵ Ｂ ２０１ＢおよびＷＴＲＵ Ｃ ２０１Ｃは、それぞれメディアパス２１１Ｂ〜Ｃを介して、メディアセッションに係わる。コントローリＷＴＲＵ Ｂ ２０１ＢおよびＷＴＲＵ Ｃ ２０１Ｃは、制御シグナリングのために、制御パス２１２Ｂ〜Ｃも使用する。

協調セッション内では、コントローリＷＴＲＵは、ＩＤＴ手順については、コントローラＷＴＲＵに従属する。例えば、コントローラＷＴＲＵは、コントローリＷＴＲＵからメディアセッションを削除することができる。加えて、コントローリＷＴＲＵは、メディアセッションを確立しようとする場合、そのような確立をコントローラＷＴＲＵに要求することができ、コントローラＷＴＲＵは、この要求を了承または拒否することができる。

図２Ｃでは、ＳＣＣ ＡＳ（サービス集中および継続アプリケーションサーバ）２１４は、ＷＴＲＵとリモートパーティの間のセッション制御シグナリングを管理する、アンカＳＣＣ ＡＳとしてサービスする。さらに、ＳＣＣ ＡＳ ２１４は、協調セッションにおけるメディアセッションのサービス継続を可能にし、ＩＤＴ手順を提供および実行する。図２Ｃでは、ただ１つのＳＣＣ ＡＳが協調セッションをサービスするが、他のシナリオでは、協調セッション中の複数のＷＴＲＵは各々、アンカＳＣＣ ＡＳに対するプロキシとしての役割を果たす、自らのＳＣＣ ＡＳを有することができる。図２Ｃは、ＩＭＳネットワークエンティティのＣＳＣＦ ２１３とＡＳ ２１５も示している。

図２Ｂ〜図２Ｃに示されるような、ＩＭＳセッションにおける制御パスを介した制御シグナリングは、ＳＩＰ（セッション開始プロトコル）などのシグナリングプロトコルを利用することができる。ＳＩＰは、当技術分野で知られており、ＩＭＳマルチメディアセッションの確立、変更、終了、追加、および複製を可能にするシグナリングプロトコルである。ＳＩＰは、テキストベースのプロトコルであり、メッセージは、要求と応答という２つの形式のうちの一方を取ることができる。ＳＩＰ要求は、ＲＥＧＩＳＴＥＲ要求を含み、ＲＥＧＩＳＴＥＲ要求は、ＷＴＲＵに関連するＰＵＩ（パブリックユーザアイデンティティ）をＩＭＳネットワークに登録するために、ＷＴＲＵによって使用することができる。ＳＩＰ要求の他の例は、ＷＴＲＵとリモートパーティの間のメディアセッションを確立するために使用できるＩＮＶＩＴＥ要求と、応答が受信されたことを確認するために使用できるＡＣＫ要求とを含む。ＳＩＰ応答コードは、要求が受信され、処理されていることを示すために使用できる暫定応答、すなわち１ｘｘと、アクションが正常に受信され、了承されたことを示すために使用できる成功応答、すなわち２ｘｘとを含む。

ＳＩＰヘッダは、ＷＴＲＵと、ＳＩＰメッセージングを利用しているＩＭＳネットワークとによって使用することができる。いくつかのＳＩＰヘッダは、「Ｔｏ」（意図された受信者のアドレス）、「Ｆｒｏｍ」（送信者のアドレス）、および「Ｃｏｎｔａｃｔ」（要求のためのヘッダか、それとも応答のためのヘッダかに応じて、要求されたリソースまたは要求発信者を識別するアドレス情報）を含む。

ＩＭＳでは、ＷＴＲＵは、ＰＵＩ（パブリックユーザアイデンティティ）を使用して、ＩＭＳネットワークに登録することができる。ＰＵＩは、電子メールアドレスなどのＳＩＰ ＵＲＩ（ユニフォームリソース識別子）、または電話番号などの電話ＵＲＩとすることができる。ＩＭＳネットワークは、ＷＴＲＵのＰＵＩを宛先として指定することによって、ＷＴＲＵとコンタクトを取ることができる。複数のＷＴＲＵが、同じＰＵＩを共有することができる。例えば、ＩＭＳ加入者は、１つのＩＭＳ加入契約のもとで同じＰＵＩを共有する、複数のＷＴＲＵを有することができる。

ＷＴＲＵは、その能力をＩＭＳネットワークに登録することができる。協調セッションを制御することが可能なＷＴＲＵは、協調セッションコントローラＷＴＲＵとして、ＩＭＳネットワークに登録することができる。さらに、メディア制御が可能なＷＴＲＵは、そのようなものとして登録することができる。メディアコントローラＷＴＲＵは、協調セッションのコントローラＷＴＲＵであるか、それともコントローリＷＴＲＵであるかに関係なく、協調セッション内において一定の定義されたメディア制御特権を有することができる。ＷＴＲＵは、ネットワークに登録されたそのプロファイルを、いつでも更新または変更することができる。その能力を登録するため、ＷＴＲＵは、ＳＩＰ Ｃｏｎｔａｃｔヘッダ内においてフィーチャタグを使用することができる。例えば、協調セッション制御能力を登録しようとするＷＴＲＵは、ｇ．３ｇｐｐ．ｉｕｔ＝“ｃｏｎｔｒｏｌｌｅｒ”などのフィーチャタグを使用することができ、メディア制御能力を登録しようとするＷＴＲＵは、ｇ．３ｇｐｐ．ｉｕｔ＝“ｍｅｄｉａ−ｃｏｎｔｒｏｌｌｅｒ”などのフィーチャタグを使用することができる。ＷＴＲＵは、ＳＩＰ ＲＥＧＩＳＴＥＲ要求を利用して、ＩＭＳネットワークとコンタクトを取る場合、そのＩＭＳ能力を示すフィーチャタグを含めることができる。

ＩＭＳネットワークは、ＷＴＲＵの能力についてのプロファイルを維持することができる。このプロファイルは、ＷＴＲＵがネットワークに登録した能力によって、またはネットワークの知識内の他の情報によって、影響を受けることがある。ネットワークは、メディアセッション回送などのＩＭＳサービスを提供する際に、またはＷＴＲＵがＩＭＳアクションを実行することを許可されているかどうかを決定する際に、ＷＴＲＵが登録した能力、またはサービスプロファイル内の情報に依存することができる。例えば、ＩＭＳネットワーク内では、メディアセッション継続性に責任をもつＳＣＣ ＡＳは、メディアセッション回送に影響を与えるために、登録されたＷＴＲＵ能力またはプロファイル情報を使用することができる。着信メディアセッション要求を受信した場合、ＳＣＣ ＡＳは、登録されたコントローラＷＴＲＵへのセッションの回送を選好する旨のプリファレンスを、ＣＳＣＦに示すことができる。その場合、ＣＳＣＦは、このプリファレンスを使用して、登録されたコントローラＷＴＲＵにメディアセッションを回送することができる。

ＳＩＰでは、ＳＣＣ ＡＳは、ＩＥＴＦ ＲＦＣ ３８４１ヘッダおよびパラメータを使用して、回送プリファレンスをＣＳＣＦに示すことができる。例えば、ＳＣＣ ＡＳは、コントローラＷＴＲＵフィーチャタグおよび「ｅｘｐｌｉｃｉｔ」パラメータを有するＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダフィールドを、ＳＩＰ要求内に追加することができ、それによって、コントローラ能力を有するものとして登録されたＷＴＲＵに要求を回送するように要求する。ＳＩＰ要求内のヘッダフィールドおよびコントローラフィーチャタグを受け取ると、ＣＳＣＦは、登録されたコントローラ能力を有するＷＴＲＵに要求を回送する。どのＷＴＲＵも登録されたコントローラ能力を有さない場合、要求は、登録されたコントローラではないＷＴＲＵに回送される。ＳＣＣ ＡＳは、「ｒｅｑｕｉｒｅ」パラメータを有するＳＩＰ Ｃｏｎｔａｃｔヘッダフィールドを追加することによっても、回送プリファレンスを示すことができる。

ＷＴＲＵは、プライオリティ値をＩＭＳネットワークに登録することができる。プライオリティ値は、同じＰＵＩのもとでやはりＩＭＳネットワークに登録できる他のＷＴＲＵと比較したＷＴＲＵのプライオリティを、ＩＭＳネットワークに示すことができる。プライオリティ値は、ＩＭＳセッションの受信についてのＷＴＲＵのプリファレンスレベルも、ＩＭＳネットワークに示すことができる。プライオリティ値は、メディアセッションをどこで確立するか、またはどこに回送するかの決定など、ＩＭＳ管理およびＩＭＳサービスの提供の際に、ＩＭＳネットワークによって使用することができる。ＷＴＲＵに関連するより高いプライオリティ値は、メディアセッションを確立し、そのＷＴＲＵに回送することをより強く選好するプリファレンスを、ネットワークに示すことができる。例えば、同じＰＵＩを有する複数のＷＴＲＵが、ＩＭＳネットワークにコントローラとして登録されている場合、ＩＭＳネットワーク内のＣＳＣＦは、より高いプライオリティ値を有するＷＴＲＵに、着信メディアセッションを回送することができる。一実施形態では、ＷＴＲＵは、ＳＩＰ Ｃｏｎｔａｃｔヘッダフィールド内のｑ値パラメータを使用して、プライオリティ値をＩＭＳネットワークに登録することができる。

図３は、この実施形態による、ＷＴＲＵ登録およびＩＭＳセッション回送のための情報フローを示している。図３では、ＩＭＳ対応のＷＴＲＵ Ａ ３０１は、その能力およびプライオリティ値を、ＩＭＳネットワークに登録しようとする。ＷＴＲＵ Ａ ３０１Ａは、ＳＩＰ ＲＥＧＩＳＴＥＲ要求３１０をＩＭＳ ＣＳＣＦ ３１３に送信する。ＳＩＰ ＲＥＧＩＳＴＥＲ要求３１０は、ＷＴＲＵ Ａ ３０１の能力を示すフィーチャタグと、ＷＴＲＵ Ａ ３０１Ａに関連するプライオリティ値を示すｑ値の両方を含む、Ｃｏｎｔａｃｔヘッダフィールドを有する。図３では、ＷＴＲＵ Ａ ３０１Ａのコントローラ能力を示すフィーチャタグは、ｇ．３ｇｐｐ．ｃｏｎｔｒｏｌｌｅｒ＝“ｃｏｎｔｒｏｌｌｅｒ”であり、ＷＴＲＵ Ａ ３０１Ａに関連するプライオリティ値を示すｑ値は、ｑ＝．５である。

ＣＳＣＦ ３１３は、ＳＩＰ ＲＥＧＩＳＴＥＲ要求３１０をＳＣＣ ＡＳ ３１４に送信し、ＣＳＣＦ ３１３は、ＳＩＰ ２００（ＯＫ）応答３１０をＷＴＲＵ Ａ ３０１Ａに送信する。ＳＣＣ ＡＳ ３１４も、ＳＩＰ ２００（ＯＫ）応答３１０をＣＳＣＦ ３１３に送信する。結果として、ＷＴＲＵ Ａ ３０１Ａは、その能力およびプライオリティ値を、ＩＭＳネットワークに登録する。ＷＴＲＵ Ｂ ３０１ＢおよびＷＴＲＵ Ｃ ３０１Ｃも同様に、その能力および関連プライオリティ値を、ＩＭＳネットワークに登録する（３２０、３３０）。ＷＴＲＵ Ａ〜Ｃ ３０１Ａ〜Ｃは、同じＰＵＩのもとで、ＩＭＳネットワークに登録される。ＷＴＲＵ Ｂ ３０１Ｂは、コントローラ能力を示すフィーチャタグと、ｑ＝．８であるｑ値を登録するが、ＷＴＲＵ Ｃ ３０１Ｃは、コントローラ能力を示すフィーチャタグを登録せず、ｑ＝．５であるｑ値を登録する。

ＣＳＣＦ ３１３は、メディアセッションのために、リモートパーティ（図示せず）から、ＳＩＰ ＩＮＶＩＴＥ要求３４０を受信する。ＳＩＰ ＩＮＶＩＴＥ要求３４０は、ＷＴＲＵ Ａ〜Ｃ ３０１Ａ〜Ｃによって共有されるＰＵＩを宛先として指定する。ＣＳＣＦ ３１３は、ＳＩＰ ＩＮＶＩＴＥ要求３４０をＳＣＣ ＡＳ ３１４に送信する。ＳＣＣ ＡＳ ３１４は、ＳＩＰ ＩＮＶＩＴＥ要求をコントローラＷＴＲＵに回送することを選好する。ＳＣＣ ＡＳ ３１４は、ＲＦＣ ３８４１手順を使用し、このプリファレンスを示すために、コントローラフィーチャタグを有するＡｃｃｅｐｔ−Ｃｏｎｔａｃｔを、ＳＩＰ ＩＮＶＩＴＥ要求内に追加する（３４５）。ＳＣＣ ＡＳ ３１４は、ＳＩＰ ＩＮＶＩＴＥ要求３５０をＣＳＣＦ ３１３に送信する。

ＷＴＲＵ Ａ ３０１ＡとＷＴＲＵ Ｂ ３０１Ｂは、コントローラ能力を有するが、ＷＴＲＵ Ｃ ３０１Ｃは、そのような能力を有さない。したがって、ＣＳＣＦ ３１３は、ＳＩＰ ＩＮＶＩＴＥ要求を、ＷＴＲＵ Ａ ３０１ＡまたはＷＴＲＵ Ｂ ３０１Ｂに送信するが、ＷＴＲＵ Ｃ ３０１Ｃには送信しない。ＷＴＲＵ Ｂ ３０１Ｂは、ＷＴＲＵ Ａ ３０１Ａよりも高い関連ｑ値を有するので、ＣＳＣＦ ３１３は、ＳＩＰ ＩＮＶＩＴＥ要求をより高いｑ値を有するコントローラＷＴＲＵに送ることを決定し（３５５）、その後、ＳＩＰ ＩＮＶＩＴＥ要求３６０をＷＴＲＵ Ｂ ３０１Ｂに送信する。二股をかける、すなわち、ＳＩＰ ＩＮＶＩＴＥ要求をＷＴＲＵ Ａ ３０１ＡとＷＴＲＵ Ｂ ３０１Ｂの両方に送信する代わりに、ＣＳＣＦ ３１３は、ＳＩＰ ＩＮＶＩＴＥ要求をＷＴＲＵ Ｂ ３０１Ｂに送信する。

複数のＳＣＣ ＡＳが、ＩＭＳセッションに係わることができ、各ＳＣＣ ＡＳは、１つのＷＴＲＵまたは複数のＷＴＲＵにサービスする。複数のＷＴＲＵが協調ＩＭＳセッションに係わり、ＷＴＲＵが複数のＳＣＣ ＡＳによってサービスされる場合が、これに相当し得る。例えば、１つのＳＣＣ ＡＳは、協調セッションのためのアンカＳＣＣ ＡＳとすることができ、残りのＳＣＣ ＡＳは、アンカＳＣＣ ＡＳのためにメッセージをプロキシすることができる。

ＩＭＳセッションに係わるＷＴＲＵは、それらが異なるＩＭＳ加入契約のもとにあるために、または異なるＩＭＳネットワークによってサービスされるために、異なるＳＣＣ ＡＳを有することがある。ＩＭＳセッションを開始したＷＴＲＵをサービスするＳＣＣ ＡＳは、アンカポイントが別のＳＣＣ ＡＳに移転されるまで、アンカＳＣＣ ＡＳとして機能することができる。開始ＷＴＲＵは、ＩＭＳセッション内の他のＷＴＲＵに（例えば、これらのＷＴＲＵにＩＭＳメディアセッションを移転すること、複製すること、または確立することによって）係わることができる。したがって、他のＷＴＲＵにサービスするＳＣＣ ＡＳは、開始ＷＴＲＵのＳＣＣ ＡＳに対するプロキシとしての役割を果たすことができる。

図４は、ＩＭＳ協調セッション中の、複数のＩＭＳネットワークによってサービスされる複数のＷＴＲＵを示している。ＷＴＲＵ ４０１Ａ〜Ｃ（これ以降、一括して数字だけによってＷＴＲＵ ４０１と呼ばれる）の各々は、それぞれのＩＭＳネットワーク内において、それぞれＳＣＣ ＡＳ ４０２Ａ〜Ｃによってサービスされる。ＳＣＣ ＡＳ Ａ ４０２Ａは、アンカであり、その方針が、ＩＭＳセッションを統制する。さらに、アンカＳＣＣ ＡＳ Ａ ４０２Ａは、すべてのＷＴＲＵ ４０１の間のメディアセッションのサービス継続性を可能にする。ＳＣＣ ＡＳ Ｂ ４０２ＢおよびＳＣＣ ＡＳ Ｃ ４０２Ｃは、それぞれＷＴＲＵ Ｂ ４０１ＢおよびＷＴＲＵ Ｃ ４０２Ｃにサービスし、ＷＴＲＵ Ｂ ４０２ＢおよびＷＴＲＵ Ｃ ４０２Ｃは、異なるＩＭＳ加入契約に属することができる。ＳＣＣ ＡＳ Ａ ４０２Ａがアンカを務める協調セッションでは、ＳＣＣ ＡＳ Ｂ ４０２ＢおよびＳＣＣ ＡＳ Ｃ ４０２Ｃは、ＷＴＲＵ Ｂ ４０１ＢおよびＷＴＲＵ Ｃ ４０１ＣのそれぞれとＳＣＣ ＡＳ Ａ ４０２Ａの間のメッセージのためのプロキシとしての役割を果たす。

図４では、アクセスレグ４０７が、アンカＳＣＣ ＡＳ Ａ ４０２Ａに提示され、リモートレグ４０８が、リモートパーティ（図示せず）からＳＣＣ ＡＳ Ａ ４０２Ａに提示される。ＷＴＲＵ ４０１は各々、ＳＣＣ ＡＳ ４０２を有する制御パス４０５と、リモートパーティを有するメディアパス４０６とを有する。さらに、ＩＭＳネットワークの各々は、ＣＳＣＦ ４０３Ａ〜Ｃを有する。

ＳＣＣ ＡＳは、制御シグナリングを使用して、自らを他のＳＣＣ ＡＳにアンカとして識別させることができる。加えて、アンカＳＣＣ ＡＳは、制御シグナリングを介して、アンカポイントを自分から別のＳＣＣ ＡＳに移転することができ、または非アンカＳＣＣ ＡＳは、制御シグナリングを介して、アンカポイントをアンカＳＣＣ ＡＳから移転するように要求することができる。

ＳＣＣ ＡＳの間のシグナリングは、アンカ識別および移転の目的に専従させることができ、またはシグナリングは、ＩＭＳシグナリング内に組み込むこと、もしくは含めることができる。例えば、アンカＳＣＣ ＡＳは、非アンカＳＣＣ ＡＳを介して回送され、非アンカＳＣＣ ＡＳによってサービスされるＷＴＲＵを宛先とするＩＭＳ制御メッセージ内に、当該の主旨を有する制御シグナリングを組み込むことによって、自らをそのようなものとして識別させることができる。それによって、自らがサービスしているＷＴＲＵにメッセージを回送する非アンカＳＣＣ ＡＳは、メッセージを介して、アンカＳＣＣ ＡＳの識別情報の通知を受けることができる。非アンカＳＣＣ ＡＳは、メッセージ内に組み込まれたシグナリングを削除し、メッセージを意図されたパーティであるＷＴＲＵに渡す。結果として、このアンカシグナリングは、ある意味で、従来のＩＭＳシグナリングに「便乗」することができる。

セキュリティ上の目的で、ＩＭＳネットワーク内のＳＣＣ ＡＳだけが、アンカＳＣＣ ＡＳを知っているほうが好ましいことがある。したがって、ＩＭＳシグナリング内に組み込まれた、アンカ識別および移転を目的とするシグナリングは、ＩＭＳシグナリングがＷＴＲＵに受け渡される前に、受信ＳＣＣ ＡＳによって削除することができる。

ＳＩＰヘッダは、アンカＳＣＣ ＡＳを識別するために、また１つのＳＣＣ ＡＳから別のＳＣＣ ＡＳにアンカを移転するために、ＳＣＣ ＡＳによって利用することができる。プライベートヘッダ、すなわち、Ｐヘッダは、これらの目的で利用できる、ＳＩＰヘッダフィールドの一例である。Ｐ−Ａｎｃｈｏｒ−Ｐｏｉｎｔ−ＩＤと称されるＰヘッダは、アンカポイントを識別するために使用することができる。例えば、Ｐ−Ａｎｃｈｏｒ−Ｐｏｉｎｔ−ＩＤ： ｓｃｃａｓ１＠ｅｘａｍｐｌｅ．ｃｏｍは、そのアドレスであるｓｃｃａｓ１＠ｅｘａｍｐｌｅ．ｃｏｍによってアンカＳＣＣ ＡＳを識別するために使用することができ、それによって、アンカＳＣＣ ＡＳは、自らを他のＳＣＣ ＡＳにアンカＳＣＣ ＡＳとして識別させるために、このヘッダフィールドをＩＭＳ ＳＩＰシグナリング内に挿入することができる。特に、トラステッドネットワークまたはドメイン内では、アンカではないＳＣＣ ＡＳが自らをそのようなものとして識別させる可能性は低い。

別の実施形態では、ＳＣＣ ＡＳは、現在のアンカＳＣＣ ＡＳのアドレスから、それへのアンカポイント移転が求められているＳＣＣ ＡＳのアドレスに、Ｐ−Ａｎｃｈｏｒ−Ｐｏｉｎｔ−ＩＤアドレスを変更することによって、アンカ移転を要求することができる。

ＳＣＣ ＡＳアンカを移転するために、このヘッダにパラメータを追加することができる。例えば、ｔｒａｎｓｆｅｒ−ａｎｃｈｏｒ−ｐｏｉｎｔ−ｔｏは、パラメータによって識別される別のＳＣＣ ＡＳにアンカポイントを移転するために、アンカＳＣＣ ＡＳによって使用することができる。例えば、ＰヘッダのＰ−Ａｎｃｈｏｒ−Ｐｏｉｎｔ−ＩＤ： ｓｃｃａｓ１＠ｅｘａｍｐｌｅ．ｃｏｍ； ｔｒａｎｓｆｅｒ−ａｎｃｈｏｒ−ｔｏ： ｓｃｃａｓ２＠ｅｘａｍｐｌｅ．ｃｏｍは、自らをアンカポイントとして識別させ、（アドレスｓｃｃａｓ２＠ｅｘａｍｐｌｅ．ｃｏｍによって識別される）別のＳＣＣ ＡＳへのアンカポイントの移転を要求するために、ＳＣＣ ＡＳによってＳＩＰメッセージ内に挿入することができる。

別の実施形態では、アンカ識別または移転の目的で利用されるヘッダフィールドは、複数のパラメータを含むことができる。ｉｎｓｅｒｔｅｄ−ｂｙパラメータは、ヘッダをＳＩＰメッセージ内に挿入したＳＣＣ ＡＳを識別することができる。Ａｃｔｉｏｎパラメータは、ＳＣＣ ＡＳが、ヘッダフィールドの目的を他のＳＣＣ ＡＳに通知することを可能にすることができる。Ａｃｔｉｏｎヘッダフィールドは、アンカポイントを識別すること、別のＳＣＣ ＡＳへのアンカ移転を要求すること、アンカＳＣＣ ＡＳから別のＳＣＣ ＡＳへのアンカ移転を要求すること、または要求されたアンカ移転を拒否することができる。表１は、Ａｃｔｉｏｎパラメータフィールドと、関連する意味の例を示している。

したがって、アドレスｓｃｃａｓ１＠ｅｘａｍｐｌｅ．ｃｏｍを有するアンカＳＣＣ ＡＳが、アドレスｓｃｃａｓ２＠ｅｘａｍｐｌｅ．ｃｏｍを有する別のＳＣＣ ＡＳにアンカポイントを移転しようとする場合、アンカＳＣＣ ＡＳは、ヘッダのＰ−Ａｎｃｈｏｒ−Ｐｏｉｎｔ−ＩＤ： ｉｎｓｅｒｔｅｄ−ｂｙ： ｓｃｃａｓ１＠ｅｘａｍｐｌｅ．ｃｏｍ Ａｃｔｉｏｎ： ｔｒａｎｓｆｅｒ−ａｎｃｈｏｒ ｒｅｑｕｅｓｔ−ｔｏ： ｓｃｃａｓ２＠ｅｘａｍｐｌｅ．ｃｏｍを利用することができる。その後、アドレスｓｃｃａｓ２＠ｅｘａｍｐｌｅ．ｃｏｍを有する非アンカＳＣＣ ＡＳが、アンカポイント移転を了承した場合、非アンカＳＣＣ ＡＳは、ヘッダＰ−Ａｎｃｈｏｒ−Ｐｏｉｎｔ−ＩＤ： Ｉｎｓｅｒｔｅｄ−ｂｙ： ｓｃｃａｓ２＠ｅｘａｍｐｌｅ．ｃｏｍ Ａｃｔｉｏｎ： ａｎｃｈｏｒ−ｐｏｉｎｔを利用することによって応答することができる。あるいは、非アンカＳＣＣ ＡＳが、アンカポイント移転を拒否した場合、非アンカＳＣＣ ＡＳは、ヘッダＰ−Ａｎｃｈｏｒ−Ｐｏｉｎｔ−ＩＤ： Ｉｎｓｅｒｔｅｄ−ｂｙ： ｓｃｃａｓ２＠ｅｘａｍｐｌｅ．ｃｏｍ Ａｃｔｉｏｎ： ｒｅｊｅｃｔ−ａｎｃｈｏｒを利用することによって応答することができる。

図５は、この実施形態による、アンカＳＣＣ ＡＳ識別および移転のための情報フローを示している。図５では、ＳＣＣ ＡＳ Ａ ５０２Ａが、進行中のＩＭＳセッションのためのアンカＳＣＣ ＡＳ ５０５であり、ＳＣＣ ＡＳ Ｂ ５０２ＢおよびＳＳＣ ＡＳ Ｃ ５０２Ｃは、非アンカである。各ＳＣＣ ＡＳ ５０２Ａ〜Ｃは、ＩＭＳ対応ＷＴＲＵ（図示せず）にサービスすることができ、ＳＣＣ ＡＳ Ｂ ５０２ＢおよびＳＳＣ ＡＳ Ｃ ５０２Ｃは、それぞれのＷＴＲＵとアンカＳＣＣ ＡＳ Ａ ５０２Ａの間のＩＭＳシグナリングのためのプロキシとしての役割を果たす。異なるＩＭＳネットワークに属するＷＴＲＵが、協調ＩＭＳセッションに係わることができる。ＳＣＣ ＡＳ Ａ ５０２Ａは、ＳＣＣ ＡＳ Ｂ ５０２ＢへのＳＩＰメッセージ内にＳＩＰヘッダを含めることによって、自らをアンカとして識別させる（５１０）。このＳＩＰヘッダは、このアンカ情報を伝えるためだけに送信されるＳＩＰメッセージの部分とすることができ、あるいは、ヘッダは、ＳＣＣ ＡＳ Ｂ ５０２Ｂ以外のパーティを宛先とするＳＩＰメッセージ内に単に組み込むことができる。例えば、ヘッダは、ＳＣＣ ＡＳ Ｂ ５０２ＢによってサービスされるＷＴＲＵへのＳＩＰメッセージ内に含めることができる。メッセージを受信したとき、ＳＣＣ ＡＳ Ｂ ５０２Ｂは、ヘッダ情報を削除することができ、プロキシとしての役割において、ＳＩＰメッセージの残りを、自らがサービスしているＷＴＲＵに伝達する。

ＳＣＣ ＡＳ Ａ ５０２Ａは、ＳＣＣ ＡＳ Ｂ ５０２ＢへのＳＩＰメッセージ内にＳＩＰヘッダを含めることによって、アンカポイントをＳＣＣ ＡＳ Ｂ ５０２Ｂに移転するように要求する（５２０）。ＳＣＣ ＡＳ Ｂ ５０２Ｂは、ＳＣＣ ＡＳ Ａ ５０２ＡへのＳＩＰメッセージ内にＳＩＰヘッダを含めることによって、アンカポイント移転を了承する（５３０）。それによって、ＳＣＣ ＡＳ Ｂ ５０２Ｂは、アンカＳＣＣ ＡＳ ５３５になる。その後、ＳＣＣ ＡＳ Ｃ ５０２Ｃが、ＳＣＣ ＡＳ Ｂ ５０２ＢへのＳＩＰメッセージ内にＳＩＰヘッダを含めることによって、アンカポイントがＳＣＣ ＡＳ Ｂ ５０２Ｂから自分に移転されるように要求する（５４０）。ＳＣＣ ＡＳ Ｂ ５０２Ｂは、アンカポイントを放棄することを望んでおらず、そのため、ＳＣＣ ＡＳ Ｃ ５０２ＣへのＳＩＰメッセージ内にＳＩＰヘッダを含めることによって、アンカポイント移転要求を拒否し（５５０）、それによって、ＳＣＣ ＡＳ Ｂ ５０２Ｂは、アンカＳＣＣ ＡＳ ５５５であり続ける。

別の実施形態では、アンカ識別および移転のために、ＳＩＰ ＸＭＬボディを利用することができる。アンカＳＣＣ ＡＳは、ＸＭＬボディを利用することによって、自らをそのようなものとして他のＳＣＣ ＡＳに識別させることができる。ＳＣＣ ＡＳは、アンカポイントの維持、またはアンカポイント移転の要求など、ＳＣＣ ＡＳが実施することを求めるアクションのタイプも含めることができる。加えて、ＸＭＬボディは、そこへのアンカポイント移転が求められているＳＣＣ ＡＳの識別情報、またはアンカ移転を求めている非アンカＳＣＣ ＡＳの識別情報を含むことができる。

別の実施形態では、ＳＣＣ ＡＳは、Ｃａｌｌ−Ｉｎｆｏ： ｓｃｃａｓ１＠ｅｘａｍｐｌｅ．ｃｏｍ； ｐｕｒｐｏｓｅ＝ａｎｃｈｏｒのように、ＳＩＰメッセージのＣａｌｌ−Ｉｎｆｏヘッダ内にそのアドレスを含めることによって、自らをアンカＳＣＣ ＡＳとして識別させることができる。別の実施形態では、アンカＳＣＣ ＡＳは、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ内で、自らをそのようなものとして識別させることができる。例えば、アンカＳＣＣ ＡＳは、ＳＩＰメッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ内で、そのアドレスに、例えば「ａｎｃｈｏｒ−ｐｏｉｎｔ」などのパラメータを付加することができる。例えば、Ｒｅｃｏｒｄ−Ｒｏｕｔｅ： ｓｃｃａｓ１＠ｅｘａｍｐｌｅ．ｃｏｍ；ａｎｃｈｏｒ−ｐｏｉｎｔは、アドレスｓｃｃａｓ１＠ｅｘａｍｐｌｅ．ｃｏｍを有するＳＣＣ ＡＳをアンカポイントとして識別する。

ＩＭＳ協調セッションでは、セッション制御は、コントローラＷＴＲＵによって維持され、協調セッションに係わる他のＷＴＲＵは、コントローリＷＴＲＵである。コントローラＷＴＲＵは、自らを、ＩＭＳネットワークまたは協調セッションに係わる他のＷＴＲＵに、協調セッションコントローラとして識別させることができる。さらに、コントローラＷＴＲＵは、協調セッション制御を別のＷＴＲＵに移転することができ、協調セッション制御を受け取ったＷＴＲＵを新しいコントローラＷＴＲＵにする。

ＩＭＳネットワークでは、協調セッションコントローラＷＴＲＵの識別情報を示すために、ＳＩＰシグナリングを使用することができる。さらに、ＳＩＰ制御シグナリングは、協調セッション制御を移転するために使用することもできる。ＳＩＰ ＸＭＬボディは、協調セッションのためのコントローラＷＴＲＵを示す情報要素を含むことができる。加えて、ＸＭＬボディは、協調セッション制御を１つのＷＴＲＵから別のＷＴＲＵに移転する目的で、ＩＭＳ制御シグナリング内で使用することができる。例えば、コントローラＷＴＲＵは、別のＷＴＲＵが協調セッション制御を引き受けるように要求するために、ＳＩＰ ＸＭＬボディを使用することができる。協調セッション制御は、了承されることも、または拒否されることもあり、協調セッション制御の移転を了承または拒否したＷＴＲＵは、ＳＩＰ ＸＭＬボディ内でそのことを示すことができる。さらに、コントローリＷＴＲＵは、協調セッション制御をコントローラＷＴＲＵから自分に移転するように要求するために、ＳＩＰ ＸＭＬボディを使用することができる。

別の実施形態では、協調セッション中のコントローラＷＴＲＵは、それが協調セッション制御を保持しようとするのか、それとも移転しようとするのかを示すパラメータを、ＳＩＰ Ｃｏｎｔａｃｔヘッダフィールド内に含めることができる。例えば、Ｃｏｎｔａｃｔヘッダフィールド内におけるパラメータ「ｃｏｎｔｒｏｌｌｅｒ」の存在は、ＷＴＲＵが協調セッションを維持しようとしていることを、ＳＣＣ ＡＳおよびＩＭＳネットワークに通知する。

別の実施形態では、協調セッション制御を移転するために、Ｐヘッダを使用することができる。Ｐヘッダは、協調セッションコントローラを識別する、Ｃｏｎｔｒｏｌｌｅｒパラメータを有することができる。Ｐヘッダは、協調セッション制御を別のＷＴＲＵに移転することを求めるコントローラＷＴＲＵによる要求、または協調セッション制御をコントローラＷＴＲＵから獲得することを求めるコントローリＷＴＲＵによる要求を示す、Ａｃｔｉｏｎパラメータも有することができる。Ｐヘッダは、Ａｃｔｉｏｎパラメータが関係するＷＴＲＵを示すパラメータも有することができる。例えば、ＳＩＰヘッダのＰ−Ｓｅｓｓｉｏｎ−Ｃｏｎｔｒｏｌ： Ｃｏｎｔｒｏｌｌｅｒ＝ｗｔｒｕＡ＠ｅｘａｍｐｌｅ．ｃｏｍ； Ａｃｔｉｏｎ＝ｔｒａｎｓｆｅｒ； Ｒｅｑｕｅｓｔ−ｔｏ＝ｗｔｒｕＢ＠ｅｘａｍｐｌｅ．ｃｏｍは、ＷＴＲＵ Ｂへの協調セッション制御の移転を要求するために、ＷＴＲＵ Ａによって、ＲＥＦＥＲまたはＲｅ−ＩＮＶＩＴＥなどのＳＩＰメッセージ内に含めることができる。ＷＴＲＵ Ｂは、ＷＴＲＵ ＡへのＳＩＰメッセージ内にＳＩＰヘッダを含めることによって、この要求を了承または拒否することができる。

別の実施形態では、協調セッション制御は、ＩＭＳネットワークがコントローラＷＴＲＵと連携するコンタクトアドレスを変更することによって、移転することができる。この実施形態では、ＩＭＳネットワークが、１つのコントローラＷＴＲＵのためのコンタクトアドレスを有するＩＭＳシグナリングを先に受信している場合、協調セッション制御移転は、別のコントローラＷＴＲＵのためのコンタクトアドレスを有するＩＭＳシグナリングを受信したＩＭＳネットワークによって示すことができ、この場合、両方のＷＴＲＵはともに協調セッションにある。コンタクトアドレスの変更は、デバイスがコントローラ能力を有することを示す「ｃｏｎｔｒｏｌｌｅｒ」フィーチャタグと一緒に示すことができる。要求内におけるフィーチャタグの存在は、ＷＴＲＵがコントローラであることを意味し、一方、フィーチャタグの不存在は、コントローラ能力を有する別のＷＴＲＵが協調セッションを制御できることを意味する。したがって、ｃｏｎｔｒｏｌｌｅｒフィーチャタグの存在または不存在は、ＩＭＳネットワークがコントローラＷＴＲＵのためのコンタクトアドレスとして識別するコンタクトアドレスを変更するように、ＳＣＣ ＡＳを促すことができる。

図６は、ＩＭＳ協調セッション制御の移転のための情報フローを示している。図６では、ＷＴＲＵ Ａ ６０１ＡおよびＷＴＲＵ Ｂ ６０１Ｂが、リモートパーティ６０５との協調セッションに係わる。ＳＣＣ ＡＳ Ａ ６０２Ａは、ＷＴＲＵ Ａ ６０１Ａにサービスし、ＳＣＣ ＡＳ Ｂ ６０２Ｂは、ＷＴＲＵ Ｂ ６０１Ｂにサービスする。この協調セッションのために、ＷＴＲＵ Ａ ６０１Ａが、協調セッション制御を維持する。ＷＴＲＵ Ａ ６０１Ａは、コントローラＷＴＲＵであり、ＷＴＲＵ Ｂ ６０１Ｂは、コントローリＷＴＲＵであり、ＳＣＣ ＡＳ Ａ ６０２Ａは、協調セッション６１０のためのアンカＳＣＣ ＡＳである。各ＷＴＲＵ ６０１Ａ〜Ｂは、リモートパーティ６０５とのメディアフローを有する（５２０）。

コントローラＷＴＲＵとして、ＷＴＲＵ Ａ ６０１Ａは、ＳＣＣ ＡＳ Ａ ６０２Ａおよびリモートパーティ６０５との協調セッション制御シグナリングを維持する（６３０）。ＷＴＲＵ Ａ ６０１Ａは、協調セッション制御をＷＴＲＵ Ｂ ６０１Ｂに移転しようとする。ＷＴＲＵ Ａ ６０１Ａは、本明細書で説明される実施形態に従って、協調セッション制御を移転するために、ＳＩＰ要求をＷＴＲＵ Ｂ ６０１Ｂに送信する（６４０）。ＷＴＲＵ Ｂ ６０１Ｂは、協調セッション制御の移転を了承し、本明細書で説明される実施形態に従って、協調セッション制御の了承を示すＳＩＰメッセージを、ＷＴＲＵ Ａ ６０１Ａに送信する（６５０）。それによって、協調セッション６６０については、ＷＴＲＵ Ｂ ６０１Ｂが、コントローラＷＴＲＵになり、ＷＴＲＵ Ａ ６０１Ａが、コントローリＷＴＲＵになる。コントローラＷＴＲＵとして、ＷＴＲＵ Ｂ ６０１Ｂは、ＳＣＣ ＡＳ Ａ ６０２Ａおよびリモートパーティ６０５との協調セッション制御シグナリングを維持し（６７０）、ＳＣＣ ＡＳ Ａ ６０２Ａは、アンカＳＣＣ ＡＳとしての役割を果たし、ＳＣＣ ＡＳ Ｂ ６０２Ｂは、ＷＴＲＵ Ｂ ６０１ＢとＳＣＣ ＡＳ Ａ ６０２Ａの間のメッセージングをプロキシする。

上では特徴および要素を特定の組み合わせで説明したが、各特徴または要素は、単独で使用でき、または他の特徴および要素との任意の組み合わせで使用できることを当業者であれば理解されよう。加えて、本明細書で説明した方法は、コンピュータまたはプロセッサによって実行する、コンピュータ可読媒体内に包含された、コンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読媒体の例は、（有線接続または無線接続を介して送信される）電子信号と、コンピュータ可読記憶媒体とを含む。コンピュータ可読記憶媒体の例は、ＲＯＭ（リードオンリメモリ）、ＲＡＭ（ランダムアクセスメモリ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびＤＶＤ（デジタル多用途ディスク）などの光媒体を含むが、これらに限定されない。ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用する無線周波数トランシーバを実施するために、ソフトウェアと連携するプロセッサを使用することができる。

実施形態

１．ＩＭＳサービスプライオリティをＩＭＳネットワークに登録するステップを含む、ＩＭＳ（ＩＰ（インターネットプロトコル）マルチメディアサブシステム）動作のための方法。

２．ＩＭＳサービスプライオリティは、ＩＭＳサービスを受ける際の、ＷＴＲＵ（無線送受信ユニット）プライオリティをＩＭＳネットワークに示す、実施形態１に記載の方法。

３．少なくとも部分的にＷＴＲＵのＩＭＳサービスプライオリティに基づいて、ＩＭＳネットワークからＩＭＳサービスを受ける、前記実施形態のいずれか１つに記載の方法。

４．ＷＴＲＵは、ＩＭＳネットワークとシグナリングを行う際に、ＳＩＰ（セッション開始プロトコル）を使用する、前記実施形態のいずれか１つに記載の方法。

５．ＷＴＲＵは、そのプライオリティ値をＩＭＳネットワークに登録するために、ＳＩＰ Ｃｏｎｔａｃｔフィールドヘッダ内でｑ値パラメータを使用する、前記実施形態のいずれか１つに記載の方法。

６．パブリックユーザアイデンティティが、ＩＭＳネットワークに登録される、前記実施形態のいずれか１つに記載の方法。

７．ＷＴＲＵは、そのパブリックユーザアイデンティティを他のＩＭＳ対応ＷＴＲＵと共有する、前記実施形態のいずれか１つに記載の方法。

８．ＩＭＳサービス能力が、ＩＭＳネットワークに登録される、前記実施形態のいずれか１つに記載の方法。

９．ＩＭＳサービス能力は、特定のＩＭＳ機能を実行するためのＷＴＲＵの能力をＩＭＳネットワークに示す、前記実施形態のいずれか１つに記載の方法。

１０．少なくとも部分的にＷＴＲＵのＩＭＳサービス能力に基づいて、ＩＭＳネットワークからＩＭＳサービスを受ける、前記実施形態のいずれか１つに記載の方法。

１１．ＷＴＲＵは、ＳＩＰ Ｃｏｎｔａｃｔフィールドヘッダフィーチャタグを使用して、ＩＭＳサービス能力をＩＭＳネットワークに登録する、前記実施形態のいずれか１つに記載の方法。

１２．ＷＴＲＵは、コントローラ能力をＩＭＳネットワークに登録する、前記実施形態のいずれか１つに記載の方法。

１３．ＷＴＲＵは、メディアコントローラ能力をＩＭＳネットワークに登録する、前記実施形態のいずれか１つに記載の方法。

１４．協調セッションを制御することが可能なＷＴＲＵは、協調セッションコントローラＷＴＲＵとしてＩＭＳネットワークに登録する、前記実施形態のいずれか１つに記載の方法。

１５．メディアコントローラＷＴＲＵは、協調セッションのコントローラＷＴＲＵであるか、それともコントローリＷＴＲＵであるかに関係なく、協調セッション内において一定の定義されたメディア制御特権を有する、前記実施形態のいずれか１つに記載の方法。

１６．ＷＴＲＵは、ネットワークに登録されたそのプロファイルを、いつでも更新または変更できる、前記実施形態のいずれか１つに記載の方法。

１７．ＷＴＲＵは、協調セッション制御能力を登録するために、ＳＩＰ Ｃｏｎｔａｃｔヘッダ内においてフィーチャタグを使用することができる、前記実施形態のいずれか１つに記載の方法。

１８．ＷＴＲＵは、ＩＭＳネットワークとコンタクトを取るために、ＳＩＰ ＲＥＧＩＳＴＥＲ要求を使用する、前記実施形態のいずれか１つに記載の方法。

１９．ＩＭＳネットワークは、ＷＴＲＵの能力についてのプロファイルを維持することができる、前記実施形態のいずれか１つに記載の方法。

２０．プロファイルは、ＷＴＲＵがネットワークに登録した能力によって、またはネットワークの知識内の他の情報によって影響を受ける、前記実施形態のいずれか１つに記載の方法。

２１．ネットワークは、ＩＭＳサービスを提供する際に、ＷＴＲＵが登録した能力、またはサービスプロファイル内の情報に依存する、前記実施形態のいずれか１つに記載の方法。

２２．登録されたＷＴＲＵ能力またはプロファイル情報は、メディアセッション回送に影響を与える、前記実施形態のいずれか１つに記載の方法。

２３．着信メディアセッション要求を受信した場合、ＳＣＣ ＡＳは、登録されたコントローラＷＴＲＵへのセッションの回送を選好する旨のプリファレンスを、ＣＳＣＦに示す、前記実施形態のいずれか１つに記載の方法。

２４．ＣＳＣＦは、プリファレンスを使用して、登録されたコントローラＷＴＲＵにメディアセッションを回送する、前記実施形態のいずれか１つに記載の方法。

２５．ＳＣＣ ＡＳは、ＩＥＴＦ ＲＦＣ ３８４１ヘッダおよびパラメータを使用して、回送プリファレンスをＣＳＣＦに示す、前記実施形態のいずれか１つに記載の方法。

２６．ＷＴＲＵは、コントローラＷＴＲＵフィーチャタグおよび「ｅｘｐｌｉｃｉｔ」パラメータを有するＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダフィールドを、ＳＩＰ要求内に追加する、前記実施形態のいずれか１つに記載の方法。

２７．ＳＩＰ要求内のヘッダフィールドおよびコントローラフィーチャタグを受け取ると、ＣＳＣＦは、登録されたコントローラ能力を有するＷＴＲＵに要求を回送する、前記実施形態のいずれか１つに記載の方法。

２８．どのＷＴＲＵも登録されたコントローラ能力を有さない場合、要求は、登録されたコントローラではないＷＴＲＵに回送される、前記実施形態のいずれか１つに記載の方法。

２９．ＳＣＣ ＡＳは、「ｒｅｑｕｉｒｅ」パラメータを有するＳＩＰ Ｃｏｎｔａｃｔヘッダフィールドを追加することによって、回送プリファレンスを示す、前記実施形態のいずれか１つに記載の方法。

３０．ＷＴＲＵは、プライオリティ値をＩＭＳネットワークに登録する、前記実施形態のいずれか１つに記載の方法。

３１．プライオリティ値は、他のＷＴＲＵと比較したＷＴＲＵのプライオリティをＩＭＳネットワークに示す、前記実施形態のいずれか１つに記載の方法。

３２．プライオリティ値は、ＩＭＳセッションの受信についてのＷＴＲＵのプリファレンスレベルをＩＭＳネットワークに示す、前記実施形態のいずれか１つに記載の方法。

３３．プライオリティ値は、ＩＭＳ管理およびＩＭＳサービスの提供の際に、ＩＭＳネットワークによって使用される、前記実施形態のいずれか１つに記載の方法。

３４．プライオリティ値は、メディアセッションをどこで確立するか、またはどこに回送するかを決定する際に、ＩＭＳネットワークによって使用される、前記実施形態のいずれか１つに記載の方法。

３５．ＷＴＲＵに関連するより高いプライオリティ値は、メディアセッションを確立し、そのＷＴＲＵに回送することをより強く選好するプリファレンスを、ネットワークに示す、前記実施形態のいずれか１つに記載の方法。

３６．同じＰＵＩのもとにある複数のＷＴＲＵが、コントローラとしてＩＭＳネットワークに登録されている場合、ＩＭＳネットワーク内のＣＳＣＦは、より高いプライオリティ値を有するＷＴＲＵに、着信メディアセッションを回送する、前記実施形態のいずれか１つに記載の方法。

３７．ＷＴＲＵは、ＳＩＰ Ｃｏｎｔａｃｔヘッダフィールド内のｑ値パラメータを使用して、そのプライオリティ値をＩＭＳネットワークに登録する、前記実施形態のいずれか１つに記載の方法。

３８．ＩＵＴ（デバイス間移転）が、実行される、前記実施形態のいずれか１つに記載の方法。

３９．コントローラＷＴＲＵは、複数のＷＴＲＵから決定される、前記実施形態のいずれか１つに記載の方法。

４０．ＩＤＴは、ソースネットワークにおいて発生する、前記実施形態のいずれか１つに記載の方法。

４１．ＩＤＴは、ターゲットネットワークにおいて発生する、前記実施形態のいずれか１つに記載の方法。

４２．ＩＤＴは、第２のＷＴＲＵ（無線送受信ユニット）との協調セッション中の第１のＷＴＲＵにおいて通信セッションを実行するステップを含む、前記実施形態のいずれか１つに記載の方法。

４３．ＩＤＴは、協調セッションにおいて発生する、前記実施形態のいずれか１つに記載の方法。

４４．複数のＷＴＲＵは、それらの能力を登録する、前記実施形態のいずれか１つに記載の方法。

４５．コントローラＷＴＲＵは、ＷＴＲＵの能力に基づいて決定される、前記実施形態のいずれか１つに記載の方法。

４６．コントローラＷＴＲＵは、ＷＴＲＵのプライオリティに基づいて決定される、前記実施形態のいずれか１つに記載の方法。

４７．コントローラＷＴＲＵは、登録に基づいて決定される、前記実施形態のいずれか１つに記載の方法。

４８．複数のＷＴＲＵが、同様の能力を登録する、前記実施形態のいずれか１つに記載の方法。

４９．ＷＴＲＵは、コントローラ能力を示すフィーチャタグを含める、前記実施形態のいずれか１つに記載の方法。

５０．ＷＴＲＵは、ＳＩＰ（セッション開始プロトコル）要求をＳ−ＣＳＣＦ（サービング呼セッション管理機能）に送信する、前記実施形態のいずれか１つに記載の方法。

５１．登録要求は、ＩＰアドレス、登録ＩＤ、能力情報、またはコントローラ情報のうちの少なくとも１つを含む、前記実施形態のいずれか１つに記載の方法。

５２．Ｓ−ＣＳＣＦ（サービング呼セッション管理機能）は、ＳＩＰ ＲＥＧＩＳＴＥＲ要求をＳＣＣ ＡＳ（サービス集中および継続アプリケーションサーバ）に送信する、前記実施形態のいずれか１つに記載の方法。

５３．ＳＣＣ ＡＳ（サービス集中および継続アプリケーションサーバ）は、ＡＣＫ（肯定応答）をＳ−ＣＳＣＦ（サービング呼セッション管理機能）に送信する、前記実施形態のいずれか１つに記載の方法。

５４．Ｓ−ＣＳＣＦ（サービング呼セッション管理機能）は、ＳＩＰ ＩＮＶＩＴＥをリモートソースから受信する、前記実施形態のいずれか１つに記載の方法。

５５．Ｓ−ＣＳＣＦ（サービング呼セッション管理機能）は、Ａｃｃｅｐｔ−ＣｏｎｔａｃｔヘッダをＳＩＰ ＩＮＶＩＴＥに挿入する、前記実施形態のいずれか１つに記載の方法。

５６．Ｓ−ＣＳＣＦ（サービング呼セッション管理機能）は、呼をコントローラＷＴＲＵに回送する、前記実施形態のいずれか１つに記載の方法。

５７．コントローラＷＴＲＵは、ｑ値に基づいて決定される、前記実施形態のいずれか１つに記載の方法。

５８．複数のＳＣＣ ＡＳが、ＩＭＳセッションに係わる、前記実施形態のいずれか１つに記載の方法。

５９．各ＳＣＣ ＡＳは、１つのＷＴＲＵまたは複数のＷＴＲＵにサービスする、前記実施形態のいずれか１つに記載の方法。

６０．複数のＷＴＲＵが、協調ＩＭＳセッションに係わり、これらのＷＴＲＵは、複数のＳＣＣ ＡＳによってサービスされる、前記実施形態のいずれか１つに記載の方法。

６１．１つのＳＣＣ ＡＳは、協調セッションのためのアンカＳＣＣ ＡＳであり、残りのＳＣＣ ＡＳは、アンカＳＣＣ ＡＳのためのプロキシとしての役割を果たす、前記実施形態のいずれか１つに記載の方法。

６２．ＩＭＳセッションに係わるＷＴＲＵは、それらが異なるＩＭＳ加入契約のもとにあるために、または異なるＩＭＳネットワークによってサービスされるために、異なるＳＣＣ ＡＳを有する、前記実施形態のいずれか１つに記載の方法。

６３．ＩＭＳセッションを開始したＷＴＲＵにサービスするＳＣＣ ＡＳは、アンカポイントが別のＳＣＣ ＡＳに移転されない限り、アンカＳＣＣ ＡＳとして機能する、前記実施形態のいずれか１つに記載の方法。

６４．開始ＷＴＲＵは、ＩＭＳセッション内の他のＷＴＲＵと係わる、前記実施形態のいずれか１つに記載の方法。

６５．開始ＷＴＲＵは、他のＷＴＲＵにＩＭＳメディアセッションを移転し、複製し、または確立する、前記実施形態のいずれか１つに記載の方法。

６６．ＳＣＣ ＡＳは、開始ＷＴＲＵのＳＣＣ ＡＳに対するプロキシとしての役割を果たす、前記実施形態のいずれか１つに記載の方法。

６７．ＳＣＣ ＡＳは、制御シグナリングを使用して、自らを他のＳＣＣ ＡＳにアンカとして識別させる、前記実施形態のいずれか１つに記載の方法。

６８．アンカＳＣＣ ＡＳは、制御シグナリングを介して、アンカポイントを自分から別のＳＣＣ ＡＳに移転する、前記実施形態のいずれか１つに記載の方法。

６９．プロキシＳＣＣ ＡＳは、制御シグナリングを介して、アンカポイントをアンカＳＣＣ ＡＳから移転するように要求する、前記実施形態のいずれか１つに記載の方法。

７０．ＳＣＣ ＡＳの間のシグナリングは、アンカ識別および移転の目的に専従する、前記実施形態のいずれか１つに記載の方法。

７１．シグナリングは、ＩＭＳシグナリング内に組み込まれ、または含まれる、前記実施形態のいずれか１つに記載の方法。

７２．アンカＳＣＣ ＡＳは、プロキシＳＣＣ ＡＳを介して回送され、そのＳＣＣ ＡＳによってサービスされるＷＴＲＵを宛先とするＩＭＳ制御メッセージ内に、当該の主旨を有する制御シグナリングを組み込むことによって、自らをそのようなものとして識別させる、前記実施形態のいずれか１つに記載の方法。

７３．自らがサービスしているＷＴＲＵにメッセージを回送するプロキシＳＣＣ ＡＳは、メッセージングを介して、アンカＳＣＣ ＡＳの識別情報を通知される、前記実施形態のいずれか１つに記載の方法。

７４．プロキシは、組み込まれたアンカシグナリングを削除し、元のメッセージを意図されたパーティに渡す、前記実施形態のいずれか１つに記載の方法。

７５．ＩＭＳネットワーク内のＳＣＣ ＡＳだけが、アンカＳＣＣ ＡＳを知っている、
前記実施形態のいずれか１つに記載の方法。

７６．ＩＭＳシグナリング内に組み込まれた、アンカ識別および移転を目的とするシグナリングは、ＩＭＳシグナリングが受け渡される前に、受信ＳＣＣ ＡＳによって削除される、前記実施形態のいずれか１つに記載の方法。

７７．ＳＣＣ ＡＳは、ＳＩＰヘッダ内で自らをアンカＳＣＣ ＡＳとして識別させる、前記実施形態のいずれか１つに記載の方法。

７８．ＳＣＣ ＡＳは、ＳＩＰヘッダを使用して、１つのＳＣＣ ＡＳから別のＳＣＣ ＡＳにアンカを移転する、前記実施形態のいずれか１つに記載の方法。

７９．プライベートヘッダが、アンカＳＣＣ ＡＳを識別する、前記実施形態のいずれか１つに記載の方法。

８０．プライベートヘッダは、アンカＳＣＣ ＡＳを移転することを求める要求を示す、前記実施形態のいずれか１つに記載の方法。

８１．アンカ移転は、現在のアンカＳＣＣ ＡＳのアドレスから、それへのアンカポイント移転が求められているＳＣＣ ＡＳのアドレスに、Ｐ−Ａｎｃｈｏｒ−Ｐｏｉｎｔ−ＩＤアドレスを変更することによって要求される、前記実施形態のいずれか１つに記載の方法。

８２．ＳＣＣ ＡＳアンカを移転するために、ＳＩＰヘッダにパラメータが追加される、前記実施形態のいずれか１つに記載の方法。

８３．１つのパラメータは、そのパラメータによって識別される別のＳＣＣ ＡＳにアンカポイントを移転することを要求する、前記実施形態のいずれか１つに記載の方法。

８４．アンカ識別または移転のために使用されるヘッダフィールドは、複数のパラメータを含む、前記実施形態のいずれか１つに記載の方法。

８５．１つのパラメータは、ＳＩＰメッセージにヘッダを挿入したＳＣＣ ＡＳを識別する、前記実施形態のいずれか１つに記載の方法。

８６．１つのパラメータは、ＳＣＣ ＡＳが、ヘッダフィールドの目的を他のＳＣＣ ＡＳに通知することを可能にすることができる、前記実施形態のいずれか１つに記載の方法。

８７．パラメータは、アンカポイントを識別し、別のＳＣＣ ＡＳへのアンカ移転を要求し、アンカＳＣＣ ＡＳから別のＳＣＣ ＡＳへのアンカ移転を要求し、または要求されたアンカ移転を拒否する、前記実施形態のいずれか１つに記載の方法。

８８．ＳＩＰ ＸＭＬボディが、アンカＳＣＣ ＡＳを識別する、前記実施形態のいずれか１つに記載の方法。

８９．ＳＩＰ ＸＭＬボディは、アンカＳＣＣ ＡＳの移転を要求する、前記実施形態のいずれか１つに記載の方法。

９０．ＳＩＰ ＸＭＬボディは、ＳＣＣ ＡＳが実施することを求めるアクションのタイプを含む、前記実施形態のいずれか１つに記載の方法。

９１．ＳＩＰ ＸＭＬボディは、そこへのアンカポイント移転が求められているＳＣＣ ＡＳの識別情報を含む、前記実施形態のいずれか１つに記載の方法。

９２．ＳＩＰ ＸＭＬボディは、アンカ移転を求めている非アンカＳＣＣ ＡＳの識別情報を含む、前記実施形態のいずれか１つに記載の方法。

９３．ＳＣＣ ＡＳは、ＳＩＰメッセージのＣａｌｌ−Ｉｎｆｏヘッダ内にそのアドレスを含めることによって、自らをアンカＳＣＣ ＡＳとして識別させる、前記実施形態のいずれか１つに記載の方法。

９４．アンカＳＣＣ ＡＳは、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ内で、自らをそのようなものとして識別させる、前記実施形態のいずれか１つに記載の方法。

９５．協調セッション制御は、コントローラＷＴＲＵによって維持される、前記実施形態のいずれか１つに記載の方法。

９６．協調セッションに係わる他のＷＴＲＵは、コントローリＷＴＲＵである、前記実施形態のいずれか１つに記載の方法。

９７．コントローラＷＴＲＵは、自らを、ＩＭＳネットワークまたは協調セッションに係わる他のＷＴＲＵに、協調セッションコントローラとして識別させる、前記実施形態のいずれか１つに記載の方法。

９８．コントローラＷＴＲＵは、協調セッション制御を別のＷＴＲＵに移転し、協調セッション制御を受け取ったＷＴＲＵを新しいコントローラＷＴＲＵにする、前記実施形態のいずれか１つに記載の方法。

９９．協調セッションコントローラＷＴＲＵの識別情報を示すために、ＳＩＰシグナリングが使用される、前記実施形態のいずれか１つに記載の方法。

１００．協調セッション制御を移転するために、ＳＩＰ制御シグナリングが使用される、前記実施形態のいずれか１つに記載の方法。

１０１．ＳＩＰ ＸＭＬボディは、協調セッションのためのコントローラＷＴＲＵを示す情報要素を含む、前記実施形態のいずれか１つに記載の方法。

１０２．ＸＭＬボディは、協調セッション制御を１つのＷＴＲＵから別のＷＴＲＵに移転する目的で、ＩＭＳ制御シグナリング内で使用される、前記実施形態のいずれか１つに記載の方法。

１０３．コントローラＷＴＲＵは、別のＷＴＲＵが協調セッション制御を引き受けるように要求するために、ＳＩＰ ＸＭＬボディを使用する、前記実施形態のいずれか１つに記載の方法。

１０４．協調セッション制御は、了承されることも、または拒否されることもある、前記実施形態のいずれか１つに記載の方法。

１０５．協調セッション制御の移転を了承または拒否したＷＴＲＵは、ＳＩＰ ＸＭＬボディ内でそのことを示す、前記実施形態のいずれか１つに記載の方法。

１０６．コントローリＷＴＲＵは、協調セッション制御をコントローラＷＴＲＵから自分に移転するように要求するために、ＳＩＰ ＸＭＬボディを利用する、前記実施形態のいずれか１つに記載の方法。

１０７．協調セッション中のコントローラＷＴＲＵは、それが協調セッション制御を保持しようとするのか、それとも移転しようとするのかを示すパラメータを、ＳＩＰ Ｃｏｎｔａｃｔヘッダフィールド内に含める、前記実施形態のいずれか１つに記載の方法。

１０８．Ｃｏｎｔａｃｔヘッダフィールド内におけるパラメータ「ｃｏｎｔｒｏｌｌｅｒ」の存在は、ＷＴＲＵが協調セッション制御を維持しようとしていることを、ＳＣＣ ＡＳおよびＩＭＳネットワークに通知する、前記実施形態のいずれか１つに記載の方法。

１０９．協調セッション制御を移転するために、Ｐヘッダを使用することができる、前記実施形態のいずれか１つに記載の方法。

１１０．Ｐヘッダは、協調セッションコントローラを識別する、Ｃｏｎｔｒｏｌｌｅｒパラメータを有する、前記実施形態のいずれか１つに記載の方法。

１１１．Ｐヘッダは、協調セッション制御を別のＷＴＲＵに移転することを求めるコントローラＷＴＲＵによる要求を示す、Ａｃｔｉｏｎパラメータを有する、前記実施形態のいずれか１つに記載の方法。

１１２．Ｐヘッダは、協調セッション制御をコントローラＷＴＲＵから獲得することを求めるコントローリＷＴＲＵによる要求を示す、Ａｃｔｉｏｎパラメータを有する、前記実施形態のいずれか１つに記載の方法。

１１３．Ｐヘッダは、Ａｃｔｉｏｎパラメータが関係するＷＴＲＵを示すパラメータを有する、前記実施形態のいずれか１つに記載の方法。

１１４．Ｐヘッダは、ＷＴＲＵによって、ＳＩＰメッセージ内に含められる、前記実施形態のいずれか１つに記載の方法。

１１５．Ｐヘッダは、別のＷＴＲＵへの協調セッション制御の移転を要求するために、ＷＴＲＵによって、ＳＩＰメッセージのＲＥＦＥＲまたはＲｅ−ＩＮＶＩＴＥ内に含められる、前記実施形態のいずれか１つに記載の方法。

１１６．ＷＴＲＵは、ＳＩＰメッセージ内にＳＩＰヘッダを含めることによって、要求を了承または拒否する、前記実施形態のいずれか１つに記載の方法。

１１７．協調セッション制御は、ＩＭＳネットワークがコントローラＷＴＲＵと連携するコンタクトアドレスを変更することによって移転される、前記実施形態のいずれか１つに記載の方法。

１１８．ＩＭＳネットワークが、１つのコントローラＷＴＲＵのためのコンタクトアドレスを有するＩＭＳシグナリングを先に受信している場合、協調セッション制御移転は、別のコントローラＷＴＲＵのためのコンタクトアドレスを有するＩＭＳシグナリングを受信したＩＭＳネットワークによって示され、この場合、両方のＷＴＲＵはともに協調セッションにある、前記実施形態のいずれか１つに記載の方法。

１１９．コンタクトアドレスの変更は、「ｃｏｎｔｒｏｌｌｅｒ」フィーチャタグと一緒に示される、前記実施形態のいずれか１つに記載の方法。

１２０．要求内におけるフィーチャタグの存在は、デバイスがコントローラであることを意味する、前記実施形態のいずれか１つに記載の方法。

１２１．フィーチャタグの不存在は、コントローラ能力を有する別のデバイスが協調セッションを制御できることを意味する、前記実施形態のいずれか１つに記載の方法。

１２２．ｃｏｎｔｒｏｌｌｅｒフィーチャタグの存在または不存在は、ＩＭＳネットワークがコントローラＷＴＲＵのためのコンタクトアドレスとして識別するコンタクトアドレスを変更するように、ＳＣＣ ＡＳを促す、前記実施形態のいずれか１つに記載の方法。

１２３．実施形態１〜１２２のいずれか１つの方法を実行するように構成された、無線通信で使用するためのＷＴＲＵ（無線送受信ユニット）。

１２４．実施形態１〜１２３のいずれか１つの方法を実行するように構成された、無線通信で使用するための基地局。

１２５．実施形態１〜１２２のいずれか１つの方法を実行するように構成された集積回路。

Claims (20)

1. インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）対応無線送受信ユニット（ＷＴＲＵ）で使用するために実施される方法であって、
   ＩＭＳサービスプライオリティをＩＭＳネットワークに登録するステップであって、前記ＩＭＳサービスプライオリティは、ＩＭＳサービスを受ける際の、前記ＷＴＲＵのプライオリティを示す、ステップと、
   前記ＷＴＲＵのＩＭＳサービスプライオリティに基づいて、前記ＩＭＳネットワークからＩＭＳサービスを受けるステップと
   を含むことを特徴とする方法。
2. ＩＭＳサービスプライオリティは、プライオリティ値を使用して示されることを特徴とする請求項１に記載の方法。
3. 前記ＷＴＲＵは、セッション開始プロトコル（ＳＩＰ）メッセージングを使用して、前記ＩＭＳネットワークとシグナリングを行うことを特徴とする請求項１に記載の方法。
4. 前記ＷＴＲＵは、ＳＩＰ Ｃｏｎｔａｃｔフィールドヘッダ内でｑ値パラメータを使用して、前記サービスプライオリティ値を登録することを特徴とする請求項２に記載の方法。
5. パブリックユーザアイデンティティを前記ＩＭＳネットワークに登録するステップであって、前記パブリックユーザアイデンティティは、他のＩＭＳ対応ＷＴＲＵと共有される、ステップ
   をさらに含むことを特徴とする請求項１に記載の方法。
6. ＩＭＳサービス能力を前記ＩＭＳネットワークに登録するステップであって、前記ＩＭＳサービス能力は、特定のＩＭＳ機能を実行するためのＷＴＲＵの能力を示す、ステップと、
   前記ＷＴＲＵのＩＭＳサービス能力に基づいて、前記ＩＭＳネットワークからＩＭＳサービスを受けるステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
7. 前記ＷＴＲＵは、ＳＩＰ Ｃｏｎｔａｃｔフィールドヘッダフィーチャタグを使用して、ＩＭＳサービス能力を登録することを特徴とする請求項６に記載の方法。
8. 前記ＷＴＲＵは、コントローラ能力を前記ＩＭＳネットワークに登録することを特徴とする請求項６に記載の方法。
9. インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）協調セッション制御の移転を要求するための無線送受信ユニット（ＷＴＲＵ）であって、
   インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）協調セッションの制御の前記移転を要求するための協調セッション制御移転要求を生成するように構成されたプロセッサであって、前記要求は、セッション開始プロトコル（ＳＩＰ）メッセージの拡張可能マークアップ言語（ＸＭＬ）ボディ内に収めて伝えられる、プロセッサと、
   協調セッション制御移転を要求する前記ＳＩＰメッセージをＩＭＳネットワークに送信するように構成された、前記プロセッサと通信する送信機と
   を備えることを特徴とするＷＴＲＵ。
10. 協調セッション制御が移転されたことを示す協調セッション制御移転応答を受信するように構成された、前記プロセッサと通信する受信機であって、前記応答は、ＳＩＰメッセージ内に収めて伝えられる、受信機
    をさらに備えることを特徴とする請求項９に記載のＷＴＲＵ。
11. 前記ＷＴＲＵは、リモートパーティとのＩＭＳ協調セッションに参加していることを特徴とする請求項９に記載のＷＴＲＵ。
12. 協調セッション制御移転を求める前記ＳＩＰ要求の前記ＸＭＬボディは、協調セッションコントローラＷＴＲＵの識別情報、協調セッション制御移転を要求する前記ＷＴＲＵの識別情報、または協調セッション制御がそれに移転されるように要求されるＷＴＲＵの識別情報のうちの１つまたは複数を含むことを特徴とする請求項９に記載のＷＴＲＵ。
13. 前記協調セッション制御移転応答は、ＳＩＰメッセージのＸＭＬボディ内に収めて伝えられることを特徴とする請求項１０に記載のＷＴＲＵ。
14. インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワークにおけるサービス継続性を可能にするために、アンカアプリケーションサーバ（ＡＳ）によって実施される方法であって、
    ＩＭＳセッションのためのアンカの役割を引き受けるように第２のＡＳに要求するステップであって、前記要求は、ＳＩＰメッセージ内で示される、ステップと、
    前記ＩＭＳセッションのためのアンカの役割を放棄して、前記第２のＡＳに渡すステップと
    を含むことを特徴とする方法。
15. 前記ＡＳは、ＳＩＰメッセージのプライベートヘッダ内で、自らをアンカＡＳとして前記第２のＡＳに識別させることを特徴とする請求項１４に記載の方法。
16. 前記ＡＳは、ＳＩＰプライベートヘッダのパラメータで、前記第２のＡＳへの前記アンカの役割の移転を要求することを特徴とする請求項１４に記載の方法。
17. 前記第２のＡＳから回答を受信するステップであって、前記回答は、前記第２のＡＳが前記アンカの役割を了承したこと、または前記第２のＡＳが前記アンカの役割を拒否したことを示す、ステップ
    をさらに含むことを特徴とする請求項１４に記載の方法。
18. 前記ＡＳは、ＳＩＰメッセージの拡張可能マークアップ言語（ＸＭＬ）ボディ内で、前記第２のＡＳへの前記アンカの役割の移転を要求することを特徴とする請求項１４に記載の方法。
19. 前記第２のＡＳは、ＩＭＳ対応デバイスにサービスし、前記ＩＭＳ対応デバイスからアンカＡＳへのメッセージをプロキシすることを特徴とする請求項１４に記載の方法。
20. 前記ＩＭＳ対応デバイスは、前記ＡＳがアンカを務めるＩＭＳ協調セッションに係わることを特徴とする請求項１９に記載の方法。

Images