JP6185509B2 - ユーザ要素間セッション転送の認可 - Google Patents

Description

本発明は、無線通信技術に関する。

関連出願の相互参照
本願は、その内容が参照によって本明細書に組み込まれている、2010年3月18日に出願した米国特許仮出願第61/315245号明細書の利益を主張するものである。

ＩＭＳ（ＩＰ（インターネットプロトコル）マルチメディアサブシステム）は、ＩＰベースのマルチメディアサービスを配送するアーキテクチャフレームワークである。無線送受信ユニット（ＷＴＲＵ）は、ＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）、ロングタームエボリューション（ＬＴＥ）、ＷｉＭａｘ（Worldwide Interoperability for Microwave Access）、または無線ローカルエリアネットワーク（ＷＬＡＮ）技術などの技術に基づくネットワークを含むがこれらに限定されないさまざまなアクセスネットワークを介してＩＭＳに接続することができる。ＷＴＲＵは、パケット交換（ＰＳ）ドメインを介してＩＭＳにアクセスすることができる。ＩＣＳ（IMS Centralized Services）の使用を介して、ＷＴＲＵは、さらに、回線交換（ＣＳ）ドメインを介してＩＭＳサービスにアクセスすることができる。

ＵＥ間転送（ＩＵＴ）は、あるＷＴＲＵから別のＷＴＲＵへの通信セッション転送を可能にする。転送は、あるユーザが別のユーザとメディアを共有する時、ユーザがセッションもしくはセッションコンポーネントをとり、そのセッションで現在用いられているデバイスから離れて移動する時、ユーザがメディアをよりよく扱うことができるデバイス（すなわち、より大きいスクリーン、より明瞭なオーディオなど）にメディアを転送することを望む時、セッションで現在用いられているデバイスが残量の少ないバッテリもしくは悪い無線カバレージを有する時、またはリモートエンドがメディア特性を変更するか、さらなるメディアを追加し、現在のソースＷＴＲＵによって動作を良好に実行できない時に発生し得る。

オペレータ間転送は、ＷＴＲＵの間の協調（collaborative）セッションを含む場合がある。通常、少なくとも１つのコントローラＷＴＲＵが、協調セッションに用いられる。セッション招待をコントローラＷＴＲＵにルーティングすることができ、通信セッションを、コントローラ能力を有するデバイスに向けることができる。デバイスは、その能力を登録することができ、通信セッションを受信するために他のデバイスより高い優先順位を与えられうる。

セッションを転送するのではなく、あるセッションのメディアコンポーネントの一部またはすべてを複製することが望ましい場合がある。たとえば、あるユーザが、進行中のセッションを別のユーザと共有することを望む場合である。しかし、メディアコンポーネントの転送の要求とメディアコンポーネントの複製の要求との間で区別することは、むずかしい。また、あるデバイスが複製を実行できるかどうか、およびセッションの複製をどれほど頻繁に行えるのかを判定することは、むずかしい。

ＳＣＣ ＡＳ（Service Centralized and Continuity Application Server）内でメディアセッションを複製する方法であって、第２のＷＴＲＵ（無線送受信ユニット）から協調複製セッションｉｎｖｉｔｅ要求を受信するステップと、協調複製セッションｉｎｖｉｔｅ要求の認可を実行するステップと、複製されたメディアフローのメディアリソースを割り当てるステップと、ＭＲＦ（media resource function）内の複製されたメディアフローの応答を第２のＷＴＲＵに送信するステップと、ＭＲＦを用いる複製されたメディアフローの第１のＷＴＲＵ上のアクセスレグを更新するステップと、ＭＲＦ内の複製されたメディアフローのリモートレグを更新するステップとを含むことを特徴とする方法。

より詳細な理解は、添付図面に関連する例として与えられる次の説明から得ることができる。

１つまたは複数の開示される実施形態を実施できる例示の通信システムを示すシステム図である。 図１Ａに示された通信システム内で使用できる例示のＷＴＲＵ（無線送受信ユニット）を示すシステム図である。 図１Ａに示された通信システム内で使用できる例示の無線アクセスネットワークおよび例のコアネットワークを示すシステム図である。 複製シナリオの例を示す図である。 プルモードセッション複製の例を示す図である。 ネットワークによるプッシュモードセッション複製の例を示す図である。 ネットワークによるプルモードセッション複製の例を示す図である。 複製要求を認可する第１の例を示す図である。 複製要求を認可する第２の例を示す図である。 複製の後のＩＵＴの認可の例を示す図である。 プッシュモードを使用するネットワークによる複製の認可の例を示す図である。 プルモードを使用するネットワークによる複製の認可の例を示す図である。 複製インジケータを使用する例を示す図である。 複製インジケータの使用およびプッシュモードを使用するネットワークによる複製の例を示す図である。 複製インジケータの使用およびプルモードを使用するネットワークによる複製の例を示す図である。

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

図１Ａに示されるように、通信システム１００は、ＷＴＲＵ（無線送受信ユニット）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含むことができるが、開示される実施形態が、任意の個数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することを理解されたい。ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれを、無線環境内で動作し、かつ／または通信するように構成された任意のタイプのデバイスとすることができる。たとえば、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄを、無線信号を送信し、かつ／または受信するように構成することができ、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ユーザ機器（ＵＥ）、移動局、固定されたまたは可動の加入者ユニット、ポケットベル、セルラ電話機、携帯情報端末（ＰＤＡ）、スマートホン、ラップトップ機、ネットブック、パーソナルコンピュータ、無線センサ、消費者エレクトロニクスなどを含むことができる。

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

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

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

より具体的には、上で注記したように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１つまたは複数のチャネルアクセス方式を使用することができる。たとえば、ＲＡＮ １０４内の基地局１１４ａおよびＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃは、ＵＴＲＡ（UMTS(Universal Mobile Telecommunications System)Terrestrial Radio Access）などの無線技術を実施することができ、ＵＴＲＡは、ＷＣＤＭＡ（登録商標）（広帯域ＣＤＭＡ）を使用してエアインターフェース１１６を確立することができる。ＷＣＤＭＡは、ＨＳＰＡ（高速パケットアクセス）および／またはＨＳＰＡ＋（Ｅｖｏｌｖｅｄ ＨＳＰＡ）などの通信プロトコルを含むことができる。ＨＳＰＡは、ＨＳＤＰＡ（高速ダウンリンクパケットアクセス）および／またはＨＳＵＰＡ（高速アップリンクパケットアクセス）を含むことができる。

もう１つの実施形態では、基地局１１４ａおよびＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃは、Ｅ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access）などの無線技術を実施することができ、Ｅ−ＵＴＲＡは、ＬＴＥ（ロングタームエボリューション）および／またはＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）を使用してエアインターフェース１１６を確立することができる。

他の実施形態では、基地局１１４ａおよびＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ ８０２．１６（すなわち、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、ＩＳ−２０００（Interim Standard 2000）、ＩＳ−９５（Interim Standard 95）、ＩＳ−８５６（Interim Standard 856）、ＧＳＭ（登録商標）（Global System for Mobile communications）、ＥＤＧＥ（Enhanced Data rates for GSM Evolution）、ＧＥＲＡＮ（GSM EDGE）などの無線技術を実施することができる。

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

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

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

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

図１Ｂは、例示のＷＴＲＵ １０２のシステム図である。図１Ｂに示されているように、ＷＴＲＵ １０２は、プロセッサ１１８、トランシーバ１２０、送受信要素１２２、スピーカ／マイクロホン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、ノンリムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および他の周辺機器１３８を含むことができる。ＷＴＲＵ １０２が、実施形態と一貫性を保ったまま前述の要素の任意のサブ組合せを含むことができることを理解されたい。

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

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

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

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

ＷＴＲＵ １０２のプロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（たとえば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合され得、これからユーザ入力データを受け取ることができる。プロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。さらに、プロセッサ１１８は、ノンリムーバブルメモリ１３０および／またはリムーバブルメモリ１３２など、任意のタイプの適切なメモリから情報にアクセスし、これにデータを格納することができる。ノンリムーバブルメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリストレージデバイスを含むことができる。リムーバブルメモリ１３２は、ＳＩＭ（subscriber identity module）カード、メモリスティック、ＳＤ（secure digital）メモリカードなどを含むことができる。他の実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、物理的にＷＴＲＵ １０２上に配置されていないメモリから情報にアクセスし、これにデータを格納することができる。

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

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

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

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

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

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

図１Ｃに示されたコアネットワーク１０６は、ＭＭＥ（無線通信移動管理装置）１４２、サービングゲートウェイ１４４、およびＰＤＮ（パケットデータネットワーク）ゲートウェイ１４６を含むことができる。前述の要素のそれぞれが、コアネットワーク１０６の一部として図示されているが、これらの要素の任意の１つが、コアネットワークオペレータ以外のエンティティによって所有され、かつ／または運営される場合があることを理解されたい。

ＭＭＥ １４２は、Ｓ１インターフェースを介してＲＡＮ １０４内のｅノードＢ １４０ａ、１４０ｂ、１４０ｃのそれぞれに接続され得、制御ノードとして働くことができる。たとえば、ＭＭＥ １４２は、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃの初期アタッチ中の特定のサービングゲートウェイの選択などの責任を負うことができる。ＭＭＥ １４２は、ＲＡＮ １０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を使用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供することもできる。

サービングゲートウェイ１４４を、Ｓ１インターフェースを介してＲＡＮ １０４内のｅノードＢ １４０ａ、１４０ｂ、１４０ｃのそれぞれに接続することができる。サービングゲートウェイ１４４は、一般に、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃへ／からユーザデータパケットをルーティングし、転送する。サービングゲートウェイ１４４は、ｅノードＢ間ハンドオーバ中のユーザプレーンのアンカリング、ダウンリンクデータがＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃについて使用可能である時のページングのトリガ、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および格納、ならびに類似物など、他の機能を実行することもできる。

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

コアネットワーク１０６は、他のネットワークとの通信を容易にすることができる。たとえば、コアネットワーク１０６は、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃと伝統的な陸線通信デバイスとの間の通信を容易にするために、ＰＳＴＮ １０８などの回線交換ネットワークへのアクセスをＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃに与えることができる。たとえば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ １０８との間のインターフェースとして働くＩＰゲートウェイ（たとえば、ＩＭＳ（ＩＰマルチメディアサブシステム）サーバ）を含むことができ、またはこれと通信することができる。さらに、コアネットワーク１０６は、他のサービスプロバイダによって所有され、かつ／または運営される他の有線または無線のネットワークを含むことができるネットワーク１１２へのアクセスをＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃに与えることができる。

協調セッションすなわち、複数のＷＴＲＵにまたがって分割され、ＳＣＣ ＡＣ（Service Centralized and Continuity Application Server）内でアンカリングされるセッションを、ＷＴＲＵ間転送手順に従って確立することができる。協調セッションを確立する際には、ＩＵＴ（ユーザ間転送）を開始するＷＴＲＵが、コントローラ（controller）ＷＴＲＵになる。協調セッションに含まれる他のＷＴＲＵは、コントローリ（controlee）ＷＴＲＵになる。コントローラＷＴＲＵによって開始された後続ＩＵＴを、その協調セッション内で実行することもできる。ＳＣＣ ＡＳは、コントローラＷＴＲＵとコントローリＷＴＲＵとの両方を含むことができる協調セッション手順の調整を提供することができる。マルチメディアセッション全体を、協調セッションのデバイス間転送および／または複製を介して、あるＷＴＲＵから別のＷＴＲＵに転送し、かつ／または複製することができる。

デバイス間転送および／または複製手順を、ターゲットＷＴＲＵからまたはユーザ入力を介して受け取られた情報に基づいてＷＴＲＵによって開始することができる。

図２に、複製シナリオのシステムレベルの例を示す。ＷＴＲＵ−１ ２０１は、ＷＴＲＵ−１ ２０１とリモートパーティ２０３との間のオーディオ−１メディアフローおよびビデオ−１メディアフローを有するマルチメディアセッションを有することができる。ＷＴＲＵ−１ ２０１は、ビデオ−１メディアフローをビデオ−２メディアフローとして複製する要求をＷＴＲＵ−２ ２０２に送信することができる。１つの協調セッションを、複製のために確立することができる。複製の成功の後に、ＷＴＲＵ−１ ２０１は、協調セッション制御の制御を保持することができ、オーディオ−１メディアフローおよびビデオ−１メディアフローは、ＷＴＲＵ−１ ２０１のものになることができ、ＩＭＳ（ＩＰ（インターネットプロトコル）マルチメディアサブシステム）ネットワークは、ＷＴＲＵ−２ ２０２内でビデオ−１およびビデオ−２を複製することができる。ビデオ−１メディアフローおよびビデオ−２メディアフローは、リモートパーティ２０３からの同一のビデオパケットを転送することができる。ＷＴＲＵ−１ ２０１およびＷＴＲＵ−２ ２０２は、同一のＩＭＳサブスクリプション（subscription）または異なるＩＭＳサブスクリプションに属することができる。ＷＴＲＵ−１ ２０１またはＷＴＲＵ−２ ２０２のいずれかが、ＷＴＲＵ−１ ２０１からのビデオ−１をそれ自体に複製するように要求することができる。

図３に、プルモードセッション複製の例のシグナリング図を示す。プルセッション複製では、第２のＷＴＲＵが、第１のＷＴＲＵとリモートパーティとの間で進行中のセッションの複製を要求することができる。複製手順が完了した後に、セッションは、独立しうる。メディアＡを、ＷＴＲＵ−１ ３０１とリモートパーティ３０３との間で確立することができる（３０５）。ＷＴＲＵ−２ ３０２は、既存セッションおよびそのメディアフローに関する情報を入手することができる（３０６）。ＷＴＲＵ−２ ３０２は、ＳＣＣ ＡＳ ３０４に向かってセッション複製要求を送信するのに、入手したセッション情報を使用することができる（３０７）。この要求は、これがセッション複製要求であることを示す情報を含むことができる。

ＳＣＣ ＡＳ ３０４は、複製要求を認可するようにＷＴＲＵ−１ ３０１に要求することができ、または、ＳＣＣ ＡＳ ３０４は、ＷＴＲＵ−１ ３０１の代わりに要求を認可することができる（３０８）。メディア要求が認可される場合には、ＷＴＲＵ−２ ３０２は、リモートパーティ３０３との新しいセッションを作成することができる（３０９）。新しいセッションを確立する時に、オリジナルメディアの状態を複製することができる。たとえば、同一の再生状態および同一の使用されるメディアを、複製することができる。リモートパーティ３０３が、複製されたセッションのセットアップをサポートできない場合には、フローが失敗することがある。メディアがメディア−Ａの複製である新しいセッションを、ＷＴＲＵ−２ ３０２とリモートパーティ３０３との間で確立することができる（３１０）。メディアＡを、ＷＴＲＵ−１ ３０１とリモートパーティ３０３との間で確立することができる（３１１）。

図４に、ネットワークによるプッシュモードメディアフロー複製の例のシグナリング図を示す。協調セッション制御を、コントローラＷＴＲＵ ４０１とＳＣＣ ＡＳ ４０４との間で確立することができる（４０７）。メディアフロー、メディア−Ａを、コントローラＷＴＲＵ ４０１とリモートパーティ４０３との間で確立することができる（４０８）。コントローラＷＴＲＵ ４０１は、コントローリＷＴＲＵ ４０２内でメディア−Ａを複製する協調セッションＩＵＴ要求をＳ−ＣＳＣＦ（Serving-Call State Control Function）４０５に送信することができる（４０９）。セッションセットアップ要求は、ネットワークが、複製されるメディアがメディア−Ａであることを識別し、複製されるメディアフローのソースがコントローラＷＴＲＵ ４０１であることを識別し、複製されるメディアフローのターゲットがコントローリＷＴＲＵ ４０２であることを識別し、コントローラＷＴＲＵ ４０１内でメディア−Ａの協調セッション制御を保つのに十分な情報を含むことができる。その後、Ｓ−ＣＳＣＦ ４０５は、協調されたセッションＩＵＴ要求をＳＣＣ ＡＳ ４０４に転送することができる。ＳＣＣ ＡＳ ４０４は、コントローラＷＴＲＵ ４０１がＩＵＴサブスクライバ（subscriber）であることと、コントローラＷＴＲＵ ４０１のプロファイルが、コントローラＷＴＲＵ ４０１がメディアをコントローリＷＴＲＵ ４０２に複製することを許可することとを検証することができる（４１０）。その後、ＳＣＣ ＡＳ ４０４は、コントローラＷＴＲＵ ４０１がＩＵＴサブスクライバであることと、コントローラＷＴＲＵ ４０１のプロファイルが、コントローラＷＴＲＵ ４０１がメディアフローをコントローリＷＴＲＵ ４０２に複製することを許可することとを検証することができる（４１１）。

ＳＣＣ ＡＳ ４０４は、複製されたメディア−ＡのためにＭＲＦ（media resource function）４０６内でメディアリソースを割り当てることができる（４１２）。その後、ＳＣＣ ＡＳ ４０４は、メディア−ＡのためにコントローリＷＴＲＵ ４０２でアクセスレグを確立する要求を送信することができる（４１３）。その後、ＳＣＣ ＡＳ ４０４は、ＭＲＦ ４０６を用いる複製されたメディアフロー、メディア−Ａについて、コントローラＷＴＲＵ ４０１上のアクセスレグを更新することができる（４１４）。その後、ＳＣＣ ＡＳ ４０４は、ＭＲＦ ４０６を用いるメディア−Ａと通信するためにリモートレグを更新することができる（４１５）。メディア−Ａを、コントローラＷＴＲＵ ４０１とＭＲＦ ４０６との間（４１６）、コントローリＷＴＲＵ ４０２とＭＲＦ ４０６との間（４１８）、およびリモートパーティ４０３とＭＲＦ ４０６との間（４１７）で確立することができる。

コントローラＷＴＲＵ ４０１およびコントローリＷＴＲＵ ４０２が、異なるサブスクリプションの一部である場合には、コントローリＷＴＲＵ ４０２がＩＵＴ ＷＴＲＵ／サブスクライバでもあると仮定して、ＳＣＣ ＡＳ ４０４およびコントローリＷＴＲＵ ４０２でさらなる認可手順が要求される可能性がある。

図５に、ネットワークによるプルモードメディアフロー複製の例のシグナリング図を示す。協調セッション制御を、コントローラＷＴＲＵ ５０１とＳＣＣ ＡＳ ５０４との間で確立することができる（５０７）。メディアフロー、メディア−Ａを、コントローラＷＴＲＵ ５０１とリモートパーティ５０３との間で確立することができる（５０８）。コントローリＷＴＲＵ ５０２は、コントローリＷＴＲＵ ５０２内でメディア−Ａを複製する協調セッションＩＵＴ要求をＳ−ＣＳＣＦ ５０５に送信することができる（５０９）。セッションセットアップ要求は、ネットワークが、複製されるメディアフローがメディア−Ａであることを識別し、複製されるメディアフローのソースがコントローラＷＴＲＵ ５０１であることを識別し、複製されるメディアフローのターゲットがコントローリＷＴＲＵ ５０２であることを識別し、コントローラＷＴＲＵ ５０１内でメディア−Ａの協調セッション制御を維持するための情報を含むことができる。Ｓ−ＣＳＣＦ ５０５は、協調セッション要求をＳＣＣ ＡＳ ５０４に転送することができる（５１０）。ＳＣＣ ＡＳ ５０４は、その後、コントローリＷＴＲＵ ５０２がＩＵＴサブスクライバであること、および、コントローラＷＴＲＵ ５０１のプロファイルが、コントローリＷＴＲＵ ５０２がコントローラＷＴＲＵ ５０１からのメディアフローを複製することを許可すること、を検証することができる（５１１）。

その後、ＳＣＣ ＡＳ ５０４は、複製されたメディア−Ａのためにメディアリソースを割り当てることができる（５１２）。その後、ＳＣＣ ＡＳ ５０４は、応答をＳ−ＣＳＣＦ ５０５に送信することができる（５１３）。Ｓ−ＣＳＣＦ ５０５は、この応答をコントローリＷＴＲＵ ５０２に転送することができる（５１４）。ＳＣＣ ＡＳ ５０４は、ＭＲＦ ５０６を用いる複製されたメディアフロー、メディア−ＡのためにコントローラＷＴＲＵ ５０１上のアクセスレグを更新することができる（５１５）。その後、ＳＣＣ ＡＳ ５０４は、ＭＲＦ ５０６を用いるメディア−Ａと通信するためにリモートレグを更新することができる（５１６）。メディア−Ａを、コントローラＷＴＲＵ ５０１とＭＲＦ ５０６との間（５１７）、コントローリＷＴＲＵ ５０２とＭＲＦ ５０６との間（５１９）、およびリモートパーティ５０３とＭＲＦ ５０６との間（５１８）で確立することができる。

リモートパーティは、セッション複製を拒否しまたは認可する権限を有することができる。リモートパーティを、別のパーティとセッションを共有しないように構成することができる。たとえば、セッションが機密情報を含む可能性があるため、またはリモートパーティが複製を要求するＷＴＲＵのユーザを識別できないため、リモートパーティがセッションを共有しないものとすることができる。

リモートパーティが接続されるＰ−ＣＳＣＦ（Proxy-Call State Control Function）は、ＰＣＣ（policy and charging control）機能によって行われる判断に基づいて、さらなるセッション複製を拒否することができる。たとえば、ＰＣＣ機能は、リモートパーティが関わることのできる同時セッションの数を超えることを、リモートパーティサブスクリプションに割り当てられた最大帯域幅を超えることを、またはポリシがセッションの複製を制限するかセッションの最大個数に制限を課すことを、識別することができる。

ＷＴＲＵ−２がＩＵＴ複製能力を有する場合には、ＳＣＣ ＡＳがパス内にある可能性がある。ＳＣＣ ＡＳは、サブスクリプション、オペレータポリシ、またはユーザプリファレンスに基づいて、ＷＴＲＵ−２から、またはＷＴＲＵ−２に向かう、いずれかの複製の要求を拒否することができる。

図６に、複製要求を認可する第１の例のシグナリング図を示す。メディアフロー、メディア−Ａを、ＷＴＲＵ−１ ６０１とリモートパーティ６０３との間で確立することができる（６０６）。ＷＴＲＵ−２ ６０２は、既存のメディアセッションに関する情報をＳＣＣ ＡＳ ６０４に要求することができる（６０７）。ＷＴＲＵ−２ ６０２は、プルモードセッション複製をＳＣＣ ＡＳ ６０４に要求することができる（６０８）。その後、ＳＣＣ ＡＳ ６０４は、複製要求の認可を実行することができる（６０９）。ＳＣＣ ＡＳは、複製要求を拒否し（６１０（ａ））、または複製の要求を認可するようにＷＴＲＵ−１ ６０１に要求することができる（６１０（ｂ））。

ＷＴＲＵ−１ ６０１は、複製要求を拒否し（６１１（ａ））、または複製要求を許可することができる（６１１（ｂ））。複製要求が拒否される場合には、このプロセスが、最初からやり直され、いくつかの実施形態では、前のステップに戻らないものとすることができる。複製要求が許可されることを条件として、ＷＴＲＵ−２ ６０２は、その後、リモートパーティ６０３との複製セッションを作成することができる（６１２）。リモートパーティ６０３またはリモートパーティ６０３のために働くＰ−ＣＳＣＦ（ＷＴＲＵ−１ ６０１が直接にシグナリングするＩＭＳ内の第１のエンティティ）は、要求を拒否することができ（６１３（ａ））、または、リモートパーティ６０３は、ＷＴＲＵ−２ ６０２とのセッションの確立に進むことができる（６１３（ｂ））。その後、メディア−Ａの複製が、ＷＴＲＵ−２ ６０２とリモートパーティ６０３との間で発生することができる（６１４）。その後、メディア−Ａを、ＷＴＲＵ−１ ６０１とリモートパーティ６０３との間で確立することができる（６１５）。

図７に、複製要求を認可する第２の例のシグナリング図を示す。メディアフロー、メディア−Ａを、ＷＴＲＵ−１ ７０１とリモートパーティ７０３との間で確立することができる（７０６）。複製されたメディアＡが、ＷＴＲＵ−２ ７０２とリモートパーティ７０３との間で確立される（７０７）。ＷＴＲＵ−３ ７０５は、既存のメディアセッションに関する情報をＳＣＣ ＡＳ ７０４に要求することができる（７０８）。ＷＴＲＵ−３ ７０５は、ＷＴＲＵ−２ ７０２からメディアを複製するためにプルモードセッション複製を要求することができる（７０９）。その後、ＳＣＣ ＡＳ ７０４は、複製要求の認可を実行することができる（７１０）。ＳＣＣ ＡＳ ７０４は、複製要求を拒否し（７１１（ａ））または複製の要求を認可するようにＷＴＲＵ−２ ７０２に要求することができる（７１１（ｂ））。

ＷＴＲＵ−２ ７０２は、複製要求を拒否し（７１２（ａ））または複製要求を許可することができる（７１２（ｂ））。複製要求が拒否される場合には、このプロセスが、最初からやり直され、いくつかの実施形態では、前のステップに戻らないものとすることができる。複製要求が許可されることを条件として、ＳＣＣ ＡＳ ７０４は、オリジナルセッションがＷＴＲＵ−１ ７０１上にあったために、複製の要求を認可するようにＷＴＲＵ−１ ７０１に要求することができる（７１３）。ＷＴＲＵ−１ ７０１は、複製要求を拒否し（７１４（ａ））または複製要求を許可することができる（７１４（ｂ））。複製要求が許可されることを条件として、ＷＴＲＵ−３ ７０５は、リモートパーティ７０３との複製されたセッションを作成することができる（７１５）。リモートパーティ７０３またはリモートパーティ７０３のために働くＰ−ＣＳＣＦは、要求を拒否することができ（７１６（ａ））、または、リモートパーティ７０３は、ＷＴＲＵ−３ ７０５とのセッションの確立に進むことができる（７１６（ｂ））。メディア−Ａを、ＷＴＲＵ−３ ７０５とリモートパーティ７０３との間（７１７）、ＷＴＲＵ−２ ７０２とリモートパーティ７０３との間（７１８）、およびリモートパーティ７０３とＷＴＲＵ−１ ７０１との間（７１９）で確立することができる。

複製の後に、ＷＴＲＵ−２とリモートパーティとの間のセッションは、ＷＴＲＵ−１とリモートパーティとの間のセッションと同一であるが、独立とすることができる。したがって、ＷＴＲＵ−２が、異なるＷＴＲＵにセッションを転送するために、セッション全体またはメディアコンポーネントのＩＵＴを実行できる可能性がある。

ＷＴＲＵ−１またはリモートパーティは、セッションの性質またはセッションがどのＷＴＲＵに転送されようとしているのかを知らないことに起因して、そのような転送が行われることを望まない場合がある。したがって、ＳＣＣ ＡＳは、敵対するデバイスまたはユーザへのＩＵＴを防ぐために、転送を規制することができる。ＷＴＲＵ−１およびリモートパーティに、そのようなＩＵＴの試みを拒否する機会を与えることもできる。したがって、ＷＴＲＵ−２が、セッションまたは一部のメディアもしくはすべてのメディアのＷＴＲＵ間転送の要求をＷＴＲＵ−３に送信する場合に、ＷＴＲＵ−１に、この試みについて知らせることができる。ＷＴＲＵ−１は、その代わりにそのような認可を実行することを可能にするプロファイルをＳＣＣ ＡＳに格納させることができる。リモートパーティがＩＵＴの結果としてセッション更新を得る時に、リモートパーティは、セッションに対するそのような更新を拒否し、またはこれを受け入れることができる。

図８に、複製の後のＩＵＴの例示の認可のシグナリング図を示す。メディアフロー、メディア−Ａを、ＷＴＲＵ−１ ８０１とリモートパーティ８０３との間で確立することができる（８０６）。複製されたメディアＡが、ＷＴＲＵ−２ ８０２とリモートパーティ８０３との間で確立される（８０７）。ＷＴＲＵ−２ ８０２は、メディア、つまりメディア−ＡをＷＴＲＵ−３ ８０５に転送するプッシュモードＩＵＴ要求をＳＣＣ ＡＳ ８０４に送信することができる（８０８）。ＳＣＣ ＡＳ ８０４は、複製要求の認可を実行することができる（８０９）。ＳＣＣ ＡＳ ８０４は、複製要求を拒否し（８１０（ａ））または複製の要求を認可するようにＷＴＲＵ−１ ８０１に要求することができる（８１０（ｂ））。

ＷＴＲＵ−１ ８０１は、複製要求を拒否し（８１１（ａ））または複製要求を許可することができる（８１１（ｂ））。複製要求が拒否される場合には、このプロセスが、最初からやり直され、前のステップには戻らない。複製要求が許可されることを条件として、ＷＴＲＵ−２ ８０２は、ＩＵＴ手順を実行することができる（８１２）。リモートパーティ８０３またはリモートパーティ８０３のために働くＰ−ＣＳＣＦは、要求を拒否することができ（８１３（ａ））、または、リモートパーティ８０３は、ＳＣＣ ＡＳ ８０４とのセッションの確立に進むことができる（８１３（ｂ））。協調セッションを、ＷＴＲＵ−２ ８０２とＷＴＲＵ−３ ８０５との間で確立することができる（８１４）。その後、メディア−Ａを、リモートパーティ８０３とＷＴＲＵ−３ ８０５との間で転送することができる（８１５）。メディア−Ａを、ＷＴＲＵ−１ ８０１とリモートパーティ８０３との間で確立することができる（８１６）。

図９に、プッシュモードを使用するネットワークによる複製の認可の例のシグナリング図を示す。協調セッション制御を、コントローラＷＴＲＵ ９０１とＳＣＣ ＡＳ ９０５との間で確立することができる（９０７）。メディアセッション、メディア−Ａを、コントローラＷＴＲＵ ９０１とリモートパーティ９０３との間で確立することができる（９０８）。コントローラＷＴＲＵ ９０１は、メディア−ＡをコントローリＷＴＲＵ ９０２に複製するＩＵＴ要求をＳ−ＣＳＣＦ ９０５に送信することができる（９０９）。Ｓ−ＣＳＣＦ ９０５は、メディア−ＡをコントローリＷＴＲＵ ９０２に複製するＩＵＴ要求をＳＣＣ ＡＳ ９０４に転送することができる（９１０）。ＳＣＣ ＡＳ ９０４は、オペレータポリシおよびサブスクリプション制限に基づいて、コントローラＷＴＲＵ ９０１が複製を要求できるかどうかを認可することができる（９１１）。ＳＣＣ ＡＳ ９０４は、複製されたメディア−Ａのメディアリソースを割り当てることができる（９１２）。

コントローリＷＴＲＵ ９０２は、複製の要求を受け入れ、または拒否することができる。コントローリＷＴＲＵ ９０２は、さらなるセッションを引き受けるには忙し過ぎるので、または必要な能力に欠けているので、複製の要求を拒否することができる。要求が受け入れられることを条件として、ＳＣＣ ＡＳ ９０４は、メディア−ＡのアクセスレグをコントローリＷＴＲＵ ９０２で確立する要求を送信することができる（９１３）。その後、ＳＣＣ ＡＳ ９０４は、ＭＲＦ ９０６を用いる複製されたメディアフロー、つまりメディア−ＡのコントローラＷＴＲＵ ９０１上のアクセスレグを更新することができる（９１４）。その後、ＳＣＣ ＡＳ ９０４は、ＭＲＦ ９０６を用いるメディア−Ａと通信するためにリモートレグを更新することができる（９１５）。リモートパーティ９０３は、セッションの機密の性質またはコントローリＷＴＲＵ ９０２のユーザを知らないことに起因して、メディアセッションを複製することを望まない場合がある。メディアを、コントローラＷＴＲＵ ９０１とＭＲＦ ９０６との間（９１６）、コントローリＷＴＲＵ ９０２とＭＲＦ ９０６との間（９１８）、およびリモートパーティ９０３とＭＲＦ ９０６との間（９１７）で確立することができる。

メディアが複製された後に、オペレータポリシおよび／またはサブスクリプション制限が、可能な場合には、同一のメディアの複製を何回行うことができるのか、およびそれをどのＷＴＲＵに転送できるのか、について制限を課すことができる。オリジナルセッション参加者、コントローラＷＴＲＵ ９０１、およびリモートパーティ９０３に、複製されたメディアセッションに対して実行されるさらなるアクションについて通知することができる。

図１０に、プルモードを使用するネットワークによる複製の認可の例のシグナリング図を示す。協調セッション制御を、コントローラＷＴＲＵ １００１とＳＣＣ ＡＳ １００４との間で確立することができる（１００７）。メディアセッション、メディア−Ａを、コントローラＷＴＲＵ １００１とリモートパーティ１００３との間で確立することができる（１００８）。コントローリＷＴＲＵ １００２内でメディア−Ａを複製する協調セッション要求を、Ｓ−ＣＳＣＦ １００５に送信することができる（１００９）。Ｓ−ＣＳＣＦ １００５は、メディア−ＡをコントローリＷＴＲＵ １００２に複製するＩＵＴ要求を、ＳＣＣ ＡＳ １００４に転送することができる（１０１０）。ＳＣＣ ＡＳ １００４は、オペレータポリシおよびサブスクリプション制限に基づいて、コントローラＷＴＲＵ １００１が複製を要求できるかどうかを認可することができる（１０１１）。その後、ＳＣＣ ＡＳ １００４は、複製されたメディア−Ａのメディアリソースを割り当てることができる（１０１２）。その後、ＳＣＣ ＡＳ １００４は、ＭＲＦ １００６内のメディア−Ａに関する応答をＳ−ＣＳＣＦ １００５に送信することができる（１０１３）。その後、Ｓ−ＣＳＣＦ １００６は、ＭＲＦ １００６内のメディア−Ａに関する応答をコントローリＷＴＲＵ １００２に転送することができる（１０１４）。

コントローラＷＴＲＵ １００１は、複製の要求を受け入れ、または拒否することができる。コントローラＷＴＲＵ １００１は、コントローリＷＴＲＵ １００２のユーザを知らないので、または機密情報を共有することを望まない可能性があるので、複製の要求を拒否することができる。要求が許可されることを条件として、ＳＣＣ ＡＳ １００４は、ＭＲＦ １００６を用いる複製されたメディアフロー、メディア−ＡのコントローラＷＴＲＵ １００１上のアクセスレグを更新することができる（１０１５）。その後、ＳＣＣ ＡＳ １００４は、ＭＲＦ １００６を用いるメディア−Ａと通信するためにリモートレグを行使することができる（１０１６）。リモートパーティ１００３は、セッションの機密の性質またはコントローリＷＴＲＵ １００２のユーザを知らないことに起因して、メディアセッションを複製することを望まない場合がある。メディアを、コントローラＷＴＲＵ １００１とＭＲＦ １００６との間（１０１７）、コントローリＷＴＲＵ １００２とＭＲＦ １００６との間（１０１９）、およびリモートパーティ１００３とＭＲＦ １００６との間（１０１８）で確立することができる。

メディアが複製された後に、オペレータポリシおよび／またはサブスクリプション制限が、可能な場合には、同一のメディアの複製を何回行うことができるのか、およびそれをどのＷＴＲＵに転送できるのか、について制限を課すことができる。オリジナルセッション参加者、コントローラＷＴＲＵ １００１、およびリモートパーティ１００３に、複製されたメディアセッションに対して実行されるさらなるアクションについて通知することができる。

ＳＣＣ ＡＳが、ＷＴＲＵからＩＵＴの要求を受信する時に、ＳＩＰ（Session Initiated Protocol）メッセージを、メディアまたはセッションの複製であるか、メディアまたはセッションの転送であるか、を識別するために、異なるものとすることができる。転送について、メディアは、コントローラＷＴＲＵ、リモートパーティ、またはその両方のいずれかから生じうる。転送の後に、メディアは、コントローリＷＴＲＵ、リモートパーティ、またはその両方のいずれかから生じる。対して、複製に関して、メディアは、ネットワークによる複製についてＭＲＦがコントローラＷＴＲＵからコントローリＷＴＲＵにメディアフローを複製する場合を除いて、リモートパーティから生じうる。

転送と複製との間で区別する明示的な方法は、どのセッションが複製されるのかを示すために特定のヘッダフィールドを含めることである。したがって、「Ｒｅｐｌｉｃａｔｅヘッダフィールド」などのヘッダを標準化して、複製されるセッションのダイアログ識別子（ＩＤ）を含めてもよい。

ＳＤＰ（session description protocol）では、メディアレベルｉ行を使用して、メディアが複製されることを示すことができる。「ｉ＝」フィールドは、セッションまたはメディアストリームの目的の自由形式で人間可読な記述を提供することが意図されている。これは、解析するオートマトンには適切でない可能性がある。一実施形態では、たとえば、「ｉ＝ｒｅｐｌｉｃａｔｅ」を標準化することができる。値「ｉ＝ｔｒａｎｓｆｅｒ」を使用して、メディアコンポーネントの転送を明示的に示すことができる。あるいは、新しい「ａ」属性を定義して、メディアコンポーネントごとに「ｔｒａｎｓｆｅｒ（転送）」または「ｒｅｐｌｉｃａｔｅ（複製）」を示すことができる。たとえば、新しい「ａ」属性を、「ａ＝ｒｅｐｌｉｃａｔｅ」とすることができる。この属性をメディアレベルで含めて、複製される特定のメディアコンポーネントを識別することができ、または、セッションレベルで、すべてのメディアコンポーネントを含むセッション全体が複製されることを示すことができる。

さらに、複製は、ＸＭＬ（eXtensible Markup Language）本体を複製の要求に含めることを通して、示されうる。この要求は、あるメディアコンポーネントまたはセッション全体が複製されることの情報を含みうる。ＸＭＬ本体は、さらに、どのメディアコンポーネントが複製されるのかの情報を含むことができる。たとえば、ＸＭＬ本体に含めることもできる情報は、メディアおよび／またはセッションが複製され、メディアおよび／またはセッションのオリジネータを含むことができる場合に、複製の要求元のアイデンティティ、複製がネットワークまたはリモートパーティのどちらによって実行されることが望まれるのか、特定のメディアフローが複製されるのかどうか、またはセッション全体が複製されるのかどうか、とすることができる。複製されるセッションまたはそのセッション内のメディアフローのセッションＩＤを、ＸＭＬ本体に含めることもできる。

図１１に、複製インジケータの使用のシグナリング図を示す。メディアフロー、メディア−Ａを、ＷＴＲＵ−１ １１０１とリモートパーティ１１０３との間で確立することができる（１１０５）。ＷＴＲＵ−２ １１０２は、既存のセッションに関する情報を要求することができる（１１０６）。ＷＴＲＵ−２ １１０２は、プルモードセッション複製要求をＳＣＣ ＡＳ １１０４に送信することができる（１１０７）。たとえば、この要求を、ＷＴＲＵ−１ １１０１とリモートパーティ１１０３との間の既存のセッションのダイアログ−ＩＤを有するｒｅｐｌｉｃａｔｅヘッダフィールド、ｒｅｐｌｉｃａｔｅ値を有するメディアレベルの「ｉ＝」フィールドもしくは「ａ＝」フィールド、またはメディアコンポーネントもしくはセッション全体のどちらが複製されるのかを示すＸＭＬ本体のうちのいずれかを含むことができるｉｎｖｉｔｅとすることができる。これらのインジケータのうちの１つまたは両方の組合せを、複製に関するＳＩＰ要求に含めることができる。

ＳＣＣ ＡＳ １１０４は、複製要求の認可を実行することができる（１１０８）。ＳＣＣ ＡＳ １１０４は、複製の要求の認可の要求をＷＴＲＵ−１ １１０１に送信することができる（１１０９）。たとえば、この要求をＵＰＤＡＴＥ要求とすることができる。ＷＴＲＵ−１は、複製要求を許可することができる（１１１０）。ＳＣＣ ＡＳ １１０４は、複製されたセッションを作成することができる（１１１１）。複製要求に含まれる複製インジケータを、ＳＩＰメッセージに含めることもできる（１１１０および１１１１）。リモートパーティ１１０３は、セッションの確立に進むことができる（１１１２）。複製されたメディア−Ａを、ＷＴＲＵ−２ １１０２とリモートパーティ１１０３との間で確立することができる（１１１３）。メディア−Ａを、ＷＴＲＵ−１ １１０１とリモートパーティ１１０３との間で確立することができる（１１１４）。

図１２に、複製インジケータの使用およびプッシュモードを使用するネットワークによる複製のシグナリング図を示す。協調セッション制御を、コントローラＷＴＲＵ １２０１とＳＣＣ ＡＳ １２０４との間で確立することができる（１２０７）。メディアフロー、つまりメディア−Ａを、コントローラＷＴＲＵ １２０１とリモートパーティ１２０３との間で確立することができる（１２０８）。コントローラＷＴＲＵ １２０１は、メディア−ＡをコントローリＷＴＲＵ １２０２に複製するＩＵＴ要求を、Ｓ−ＣＳＣＦ １２０５に送信することができる（１２０９）。

この複製要求は、ＲＥＦＥＲ要求である可能性が高い。Ｒｅｆｅｒ−Ｔｏヘッダ内に、複製されるセッションのダイアログ−ＩＤを含むＲｅｐｌｉｃａｔｅヘッダフィールドを含めることができる。特定のメディアコンポーネントが複製される場合には、それらを、通常のＩＵＴ転送要求と同一の形で示すことができる。さもなければ、複製に関する次のインジケータのうちのいずれか１つ、すなわち、Ｒｅｆｅｒ−Ｔｏヘッダフィールドに含まれる各メディア記述に付加された「ｉ＝」フィールドもしくは「ａ＝」フィールド、またはどのセッション（ダイアログ−ＩＤ）もしくはどのメディアコンポーネントが複製されるのかを示すＸＭＬ本体、を使用することができる。

Ｓ−ＣＳＣＦ １２０５は、メディア−ＡをコントローリＷＴＲＵ １２０２に複製するＩＵＴ要求をＳＣＣ ＡＳ １２０４に転送することができる（１２１０）。ＳＣＣ ＡＳ １２０４は、複製要求の認可を実行することができる（１２１１）。その後、ＳＣＣ ＡＳ １２０４は、複製されたメディア−Ａのメディアリソースを割り当てることができる（１２１２）。その後、ＳＣＣ ＡＳ １２０４は、メディア−ＡのコントローリＷＴＲＵ １２０２上のアクセスレグを確立する要求を送信することができる（１２１３）。その後、ＳＣＣ ＡＳ １２０４は、ＭＲＦ １２０６を用いる複製されたメディアフロー、メディア−ＡのコントローラＷＴＲＵ １２０１上のアクセスレグを更新することができる（１２１４）。その後、ＳＣＣ ＡＳ １２０４は、ＭＲＦ １２０６を用いるメディア−Ａと通信するためにリモートレグを更新することができる（１２１５）。

複製表示を、アクセスレグを確立する要求、アクセスレグの更新、およびリモートレグの更新に含めることもできる。Ｒｅｐｌｉｃａｔｅヘッダフィールドが使用される場合には、ｒｅ−ＩＮＶＩＴＥメッセージまたはＵＰＤＡＴＥメッセージ内で、ヘッダは、通常のヘッダフィールドとして現れ、複製されるセッションのダイアログ−ＩＤを含む。ＳＤＰインジケータを、オファーおよび／またはアンサーに含めることができる。ＸＭＬ本体を、通常のＳＩＰメッセージ本体とすることができる。その後、メディアを、コントローラＷＴＲＵ １２０１とＭＲＦ １２０６との間（１２１６）、コントローリＷＴＲＵ １２０２とＭＲＦ １２０６との間（１２１８）、およびリモートパーティ１２０３とＭＲＦ １２０６との間（１２１７）で確立することができる。

図１３に、複製インジケータの使用およびプルモードを使用するネットワークによる複製のシグナリング図を示す。協調セッション制御を、コントローラＷＴＲＵ １３０１とＳＣＣ ＡＳ １３０４との間で確立することができる（１３０７）。メディアフロー、メディア−Ａを、コントローラＷＴＲＵ １３０１とリモートパーティ１３０３との間で確立することができる（１３０８）。コントローリＷＴＲＵ １３０２は、メディア−ＡをコントローリＷＴＲＵ １３０２内で複製する協調セッション要求をＳ−ＣＳＣＦ １３０５に送信することができる（１３０９）。

この複製要求は、ＩＮＶＩＴＥ要求である可能性が高い。複製されるセッションのダイアログ−ＩＤを含むＲｅｐｌｉｃａｔｅヘッダフィールドを含めることができる。特定のメディアコンポーネントが複製される場合には、それらを、オファーに含めることができる。そうではなく、複製に関する次のインジケータのうちのいずれか１つ、すなわち、ＳＤＰに含まれる各メディア記述に付加された「ｉ＝」フィールドもしくは「ａ＝」フィールド、またはどのセッション（ダイアログ−ＩＤ）もしくはどのメディアコンポーネントが複製されるのかを示すＸＭＬ本体、を使用することができる。

Ｓ−ＣＳＣＦ １３０５は、メディア−ＡをコントローリＷＴＲＵ １３０２内で複製する協調セッション要求をＳＣＣ ＡＳ １３０４に転送することができる（１３１０）。ＳＣＣ ＡＳ １３０４は、複製要求の認可を実行することができる（１３１１）。ＳＣＣ ＡＳ １３０４は、その後、複製されるメディア−Ａのメディアリソースを割り当てることができる（１３１２）。ＳＣＣ ＡＳ １３０４は、ＭＲＦ １３０６内のメディア−Ａに関する応答をＳ−ＣＳＣＦ １３０５に送信することができる（１３１３）。Ｓ−ＣＳＣＦ １３０５は、ＭＲＦ １３０６内のメディア−Ａに関する応答をコントローリＷＴＲＵ １３０２に転送することができる（１３１４）。ＳＣＣ ＡＳ １３０４は、ＭＲＦ １３０６を用いる複製されたメディアフロー、つまりメディア−ＡのコントローラＷＴＲＵ １３０１上のアクセスレグを更新することができる（１３１５）。その後、ＳＣＣ ＡＳ １３０４は、ＭＲＦ １３０６を用いるメディア−Ａと通信するためにリモートレグを更新することができる（１３１６）。その後、メディアを、コントローラＷＴＲＵ １３０１とＭＲＦ １３０６との間（１３１７）、コントローリＷＴＲＵ １３０２とＭＲＦ １３０６との間（１３１９）、およびリモートパーティ１３０３とＭＲＦ １３０６との間（１３１８）で確立することができる。

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

実施形態
１．ＳＣＣ ＡＳ（Service Centralized and Continuity Application Server）内でメディアセッションを複製する方法であって、
第２のＷＴＲＵ（無線送受信ユニット）から協調複製セッションｉｎｖｉｔｅ要求を受信するステップ
を含むことを特徴とする方法。

２．協調複製セッションｉｎｖｉｔｅ要求の認可を実行するステップ
をさらに含むことを特徴とする実施形態１に記載の方法。

３．複製されたメディアフローのメディアリソースを割り当てるステップ
をさらに含むことを特徴とする実施形態１〜２に記載の方法。

４．ＭＲＦ（media resource function）内の複製されたメディアフローの応答を第２のＷＴＲＵに送信するステップ
をさらに含むことを特徴とする実施形態１〜３に記載の方法。

５．ＭＲＦを用いる複製されたメディアフローの第１のＷＴＲＵ上のアクセスレグを更新するステップ
をさらに含むことを特徴とする実施形態１〜４に記載の方法。

６．ＭＲＦ内の複製されたメディアフローのリモートレグを更新するステップ
をさらに含むことを特徴とする実施形態１〜５に記載の方法。

７．複製セッションｉｎｖｉｔｅ要求は、ｒｅｐｌｉｃａｔｅヘッダフィールドを含むことを特徴とする実施形態１〜６に記載の方法。

８．ｒｅｐｌｉｃａｔｅヘッダフィールドは、メディアレベル「ｉ＝ｒｅｐｌｉｃａｔｅ」フィールドであることを特徴とする実施形態７に記載の方法。

９．ｒｅｐｌｉｃａｔｅヘッダフィールドは、メディアレベル「ａ＝ｒｅｐｌｉｃａｔｅ」フィールドであることを特徴とする実施形態７に記載の方法。

１０．ｒｅｐｌｉｃａｔｅヘッダフィールドは、ＸＭＬ本体であることを特徴とする実施形態７に記載の方法。

１１．ＸＭＬ本体は、どのメディアコンポーネントまたはセッション全体が複製されるのかを示すことを特徴とする実施形態１０に記載の方法。

１２．ＳＣＣ ＡＳ（Service Centralized and Continuity Application Server）内でメディアセッションを複製する方法であって、
第２のＷＴＲＵ（無線送受信ユニット）から既存のメディアフローに関する情報の要求を受信するステップ
を含むことを特徴とする方法。

１３．第２のＷＴＲＵから複製セッションｉｎｖｉｔｅ要求を受信するステップ
をさらに含むことを特徴とする実施形態１２に記載の方法。

１４．セッションｉｎｖｉｔｅ複製要求の認可を実行するステップ
をさらに含むことを特徴とする実施形態１２〜１３に記載の方法。

１５．セッションｉｎｖｉｔｅ複製要求を認可する要求を第１のＷＴＲＵに送信するステップ
をさらに含むことを特徴とする実施形態１２〜１４に記載の方法。

１６．許可複製要求を第１のＷＴＲＵから受信するステップ
をさらに含むことを特徴とする実施形態１２〜１５に記載の方法。

１７．複製されたメディアフローを作成するステップ
をさらに含むことを特徴とする実施形態１２〜１６に記載の方法。

１８．複製セッションｉｎｖｉｔｅ要求は、ｒｅｐｌｉｃａｔｅヘッダフィールドを含むことを特徴とする実施形態１２〜１７に記載の方法。

１９．ｒｅｐｌｉｃａｔｅヘッダフィールドは、メディアレベル「ｉ＝ｒｅｐｌｉｃａｔｅ」フィールドであることを特徴とする実施形態１８に記載の方法。

２０．ｒｅｐｌｉｃａｔｅヘッダフィールドは、メディアレベル「ａ＝ｒｅｐｌｉｃａｔｅ」フィールドであることを特徴とする実施形態１８に記載の方法。

２１．ｒｅｐｌｉｃａｔｅヘッダフィールドは、ＸＭＬ本体であることを特徴とする実施形態１８に記載の方法。

２２．ＸＭＬ本体は、どのメディアコンポーネントまたはセッション全体が複製されるのかを示すことを特徴とする実施形態２１に記載の方法。

２３．ＷＴＲＵ（無線送受信ユニット）内でメディアセッションを複製する方法であって、
既存のメディアフローに関する情報の要求をＳＣＣ ＡＳ（Service Centralized and Continuity Access Server）に送信するステップ
を含むことを特徴とする方法。

２４．ＳＣＣ ＡＳから既存のメディアフローに関する情報を受信するステップ
をさらに含むことを特徴とする実施形態２３に記載の方法。

２５．複製セッションｉｎｖｉｔｅ要求をＳＣＣ ＡＳに送信するステップ
をさらに含むことを特徴とする実施形態２３〜２４に記載の方法。

２６．ＳＣＣ ＡＳから許可複製要求を受信するステップ
をさらに含むことを特徴とする実施形態２３〜２５に記載の方法。

２７．リモートパーティとの複製されたメディアフローを作成するステップ
をさらに含むことを特徴とする実施形態２３〜２６に記載の方法。

２８．複製セッションｉｎｖｉｔｅ要求は、ｒｅｐｌｉｃａｔｅヘッダフィールドを含むことを特徴とする実施形態２３〜２７に記載の方法。

２９．ｒｅｐｌｉｃａｔｅヘッダフィールドは、メディアレベル「ｉ＝ｒｅｐｌｉｃａｔｅ」フィールドであることを特徴とする実施形態２８に記載の方法。

３０．ｒｅｐｌｉｃａｔｅヘッダフィールドは、メディアレベル「ａ＝ｒｅｐｌｉｃａｔｅ」フィールドであることを特徴とする実施形態２８に記載の方法。

３１．ｒｅｐｌｉｃａｔｅヘッダフィールドは、ＸＭＬ本体であることを特徴とする実施形態２８に記載の方法。

３２．ＸＭＬ本体は、どのメディアコンポーネントまたはセッション全体が複製されるのかを示すことを特徴とする実施形態３１に記載の方法。

Claims (16)

1. ＳＣＣ ＡＳ（Service Centralized and Continuity Application Server）が、第１の無線送受信ユニット（ＷＴＲＵ）との協調セッション制御を確立するステップであって、前記第１のＷＴＲＵは、第１のサブスクリプションに関連付けられ、前記第１のＷＴＲＵは、メディアフローをリモートパーティから受信している、ステップと、
   前記ＳＣＣ ＡＳが、前記メディアフローを第２のＷＴＲＵへ複製する協調セッション要求を前記第２のＷＴＲＵから受信するステップと、
   前記ＳＣＣ ＡＳが、前記受信された協調セッション要求を認可するステップと、
   前記ＳＣＣ ＡＳが、前記メディアフローのためにＭＲＦ（media resource function）においてメディアリソースを割り当てるステップと、
   前記ＳＣＣ ＡＳが、前記第２のＷＴＲＵが前記要求された複製されたメディアフローを前記ＭＲＦから受信するための応答を前記第２のＷＴＲＵに送信するステップと、
   前記ＳＣＣ ＡＳが、前記第１のＷＴＲＵがその後前記メディアフローを前記ＭＲＦから受信するために前記第１のＷＴＲＵ上のアクセスレグを更新するステップと、
   前記ＳＣＣ ＡＳが、前記複製されたメディアフローを前記ＭＲＦに通信するためにリモートレグを更新するステップであって、前記メディアフローは、その後前記リモートパーティから前記ＭＲＦに、前記ＭＲＦから前記第１のＷＴＲＵに、および前記ＭＲＦから前記第２のＷＴＲＵに流れる、ステップと
   を備える方法。
2. 前記第２のＷＴＲＵは、また前記第１のサブスクリプションにも関連付けられている、請求項１の方法。
3. 前記ＳＣＣ ＡＳは、前記協調セッション要求をＳ−ＣＳＣＦ（Serving-Call State Control Function）を介して前記第２のＷＴＲＵから受信する、請求項１の方法。
4. 前記ＳＣＣ ＡＳは、前記応答を前記Ｓ−ＣＳＣＦを介して前記第２のＷＴＲＵに送信する、請求項３の方法。
5. 前記受信された協調セッション要求を認可する前記ステップは、前記第１のサブスクリプションが、前記第２のＷＴＲＵへの、前記メディアフローの前記要求された複製を許可することをチェックすることを含む、請求項１の方法。
6. 前記ＳＣＣ ＡＳは、前記応答をＳ−ＣＳＣＦ（Serving-Call State Control Function）を介して前記第２のＷＴＲＵに送信する、請求項１の方法。
7. 前記ＳＣＣ ＡＳが、前記第２のＷＴＲＵから、前記第１のＷＴＲＵによって前記リモートパーティから受信されている前記メディアフローに関する情報についての情報要求を受信するステップと、
   前記ＳＣＣ ＡＳが、前記第２のＷＴＲＵに、前記第１のＷＴＲＵによって前記リモートパーティから受信されている前記メディアフローに関する情報を備える情報応答を送信するステップと
   をさらに備える、請求項１の方法。
8. 前記第１のＷＴＲＵは、前記メディアフローに関してコントローラＷＴＲＵであり、前記第２のＷＴＲＵは、前記メディアフローに関してコントローリＷＴＲＵである、請求項１の方法。
9. ＳＣＣ ＡＳ（Service Centralized and Continuity Application Server）において、
   プロセッサと、
   前記ＳＣＣ ＡＳに一連の機能を実行させるための、前記プロセッサによって実行可能な命令を含むデータストレージと
   を備え、前記一連の機能は、
   第１の無線送受信ユニット（ＷＴＲＵ）との協調セッション制御を確立することであって、前記第１のＷＴＲＵは、第１のサブスクリプションに関連付けられ、前記第１のＷＴＲＵは、メディアフローをリモートパーティから受信している、ことと、
   前記メディアフローを第２のＷＴＲＵへ複製する協調セッション要求を前記第２のＷＴＲＵから受信することと、
   前記受信された協調セッション要求を認可することと、
   前記メディアフローのためにＭＲＦ（media resource function）においてメディアリソースを割り当てることと、
   前記要求された複製されたメディアフローを前記第２のＷＴＲＵが前記ＭＲＦから受信するための応答を、前記第２のＷＴＲＵに送信することと、
   前記第１のＷＴＲＵがその後前記メディアフローを前記ＭＲＦから受信するために、前記第１のＷＴＲＵ上のアクセスレグを更新することと、
   前記複製されたメディアフローを前記ＭＲＦに通信するためにリモートレグを更新することであって、前記メディアフローは、その後前記リモートパーティから前記ＭＲＦに、前記ＭＲＦから前記第１のＷＴＲＵに、および前記ＭＲＦから前記第２のＷＴＲＵに流れ
   る、ことと
   を備えたＳＣＣ ＡＳ。
10. 前記第２のＷＴＲＵは、また前記第１のサブスクリプションにも関連付けられている、請求項９のＳＣＣ ＡＳ。
11. 前記ＳＣＣ ＡＳは、前記協調セッション要求をＳ−ＣＳＣＦ（Serving-Call State Control Function）を介して前記第２のＷＴＲＵから受信する、請求項９のＳＣＣ ＡＳ。
12. 前記ＳＣＣ ＡＳは、前記応答をＳ−ＣＳＣＦを介して前記第２のＷＴＲＵに送信する、請求項９のＳＣＣ ＡＳ。
13. 前記受信された協調セッション要求を認可することは、前記第１のサブスクリプションが、前記第２のＷＴＲＵへの、前記メディアフローの前記要求された複製を許可するのをチェックすることを含む、請求項９のＳＣＣ ＡＳ。
14. 前記ＳＣＣ ＡＳは、前記応答をＳ−ＣＳＣＦ（Serving-Call State Control Function）を介して前記第２のＷＴＲＵに送信する、請求項９のＳＣＣ ＡＳ。
15. 前記一連の機能は、
    前記第２のＷＴＲＵから、前記第１のＷＴＲＵによって前記リモートパーティから受信されている前記メディアフローに関する情報についての情報要求を受信することと、
    前記第２のＷＴＲＵに、前記第１のＷＴＲＵによって前記リモートパーティから受信されている前記メディアフローに関する情報を備える情報応答を送信することと
    をさらに備えた、請求項９のＳＣＣ ＡＳ。
16. 前記第１のＷＴＲＵは、前記メディアフローに関してコントローラＷＴＲＵであり、前記第２のＷＴＲＵは、前記メディアフローに関してコントローリＷＴＲＵである、請求項９のＳＣＣ ＡＳ。

Images