JP2015057916A - ネットワークベアラーの管理方法及び無線通信網内の複数のネットワークベアラーを管理する移動性管理エンティティー - Google Patents

Abstract

【課題】通信において単一無線映像通話連続性を支援する必要が存在する。【解決手段】無線通信網の複数のネットワークバリアをパケットデータネットワークが管理する方法であって、政策及び課金規則機能エンティティーから、ビデオコールに相応するアプリケーションセッションと関連する第１指示子を受信する過程と、 前記ＰＣＲＦから受信した前記第１指示子に従って第１網から第２網に実行されるハンドオーバー中に使用される第２指示子を含むメッセージをサービングゲートウェイに伝送する過程と、を含み、 前記第１指示子は、ビデオ単一無線音声通信連続性）がビデオコールのビデオコンポーネントに対するフローのために許与されることを指示することを特徴とするネットワークベアラーの管理方法。【選択図】図１

Description

本発明は、一般的に移動通信技術（ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ）分野に関し、より詳細には、第１通信網から第２通信網へのハンドオーバー（ｈａｎｄｏｖｅｒ）の分野に関する。

現在、無線通信システム（ｒａｄｉｏ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｙｓｔｅｍ）の様々な世代は、世界で進化した。無線通信システムの様々な世代は、１世代システム（１Ｇ）、２世代システム（２Ｇ）、３世代システム（４Ｇ）、及び４世代システム（４Ｇ）を含む。それぞれの世代は、異なる伝送特性と異なる通信技術を有する。

４世代通信システム（４Ｇ）は、広帯域移動通信能力（ｂｒｏａｄｂａｎｄ ｍｏｂｉｌｅ ｃａｐａｂｉｌｉｔｉｅｓ）のために現在開発中のＩＴＵ標準（ＩＴＵ ｓｐｅｃｉｆｉｃａｔｉｏｎ）である。４Ｇシステムは、３Ｇに比べてさらに高い速度でインターネットパケット（ＩＰ）基盤の音声データとストリーミングマルチメディアを提供することができる。また、無線通信システム（ｒａｄｉｏ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｙｓｔｅｍ）は、無線接続ネットワーク（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ、ＲＡＮ）と呼ばれる。また、ＲＡＮの数が増加するにつれて、地理的な領域は、１つ以上のＲＡＮによってカバーされる。例えば、与えられた１つの地理的な領域には、例えば２Ｇ、３Ｇシステムのように、同時に動作する２個のＲＡＮが存在する。同様に、例えば、ただ３Ｇだけのように、ただ１つの無線接続ネットワーク（ＲＡＮ）だけが動作する１つの地理的な領域が存在する。

したがって、例えば、ＧＳＭ、ＵＭＴＳ、無線ＬＡＮ（ＷＬＡＮ）及びＥＤＧＥのように、ＲＡＮの数の増加とともに、異なるＲＡＮとエアインターフェース（ａｉｒ ｉｎｔｅｒｆａｃｅ）標準との相互作用（ｉｎｔｅｒｗｏｒｋｉｎｇ）は、優先順位になった。したがって、異なる無線接続ネットワーク（ＲＡＮ）間の相互作用を達成するために、そしてユーザ端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ）に対するさらに広いネットワークカバレッジを提供するために、ＲＡＮと通信網との間のハンドオーバー手続は、ますますさらに重要になった。ハンドオーバー（ＨＯ）手続は、進行中の呼（ｉｎ−ｐｒｏｃｅｓｓ ｃａｌｌ）の連続性が保証しながら１つの基地局の１つのカバー領域（ｃｏｖｅｒａｇｅ ａｒｅａ）（または１つの通信システム）から他の基地局（または他の通信システム）に進行中の呼をスイッチングするための技術的手続である。

１つの通信システムでのハンドオーバー（ＨＯ）は、ユーザ端末（ＵＥ）が通信システムによって支援される１つの無線セル（ｒａｄｉｏ ｃｅｌｌ）から通信システムによって支援される他の無線セルに移動する時に発生する。例えば、２Ｇで、１つのサービス提供者と関連した１つの基地局のカバー領域から同一または異なるサービス提供者によって支援される他の基地局に移動する時である。異なるＲＡＮ間のハンドオーバー（ＨＯ）は、例えば、３Ｇネットワークから４Ｇネットワークへの移動及びその逆の移動のように、技術間のハンドオーバー（ｉｎｔｅｒ−ｔｅｃｈｎｏｌｏｇｙ ｈａｎｄｏｖｅｒ）を意味する。異なるＲＡＮ間のハンドオーバー（ＨＯ）は、無線接続技術間のハンドオーバー（ｉｎｔｅｒ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ ＨＯ）として知られている。

異なるＲＡＮは、異なる特性を有し、ユーザ端末（ＵＥ）のための通信サービスを可能にする異なるネットワーク構造を有する。したがって、１つのＲＡＮから他のＲＡＮへのハンドオーバー（ＨＯ）手続は、効率的に管理しなければならない。例えば、第１ＲＡＮでユーザ端末（ＵＥ）と関連したボイスベアラー（ｖｏｉｃｅ ｂｅａｒｅｒｓ）とノンボイスベアラー（ｎｏｎ ｖｏｉｃｅ ｂｅａｒｅｒｓ）は、パケット交換ネットワーク及び／または回線交換ネットワークを介して支援されることができる。さらに、ユーザ端末（ＵＥ）が第１ＲＡＮから第２ＲＡＮに移動し、ハンドオーバー（ＨＯ）手続が開始されれば、第２ＲＡＮは、第１ＲＡＮと異なる能力（ｄｉｆｆｅｒｅｎｔ ｃａｐａｂｉｌｉｔｉｅｓ）を有する場合が存在することができる。それで、ユーザ端末（ＵＥ）と関連したボイスベアラーとノンボイスベアラーは、第２ＲＡＮの能力に基づいて効率的に管理しなければならない。

現在、技術標準（ＴＳ）２３．２１６［２］で説明したような単一無線音声通話連続性（Ｓｉｎｇｌｅ Ｒａｄｉｏ Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ、ＳＲＶＣＣ）は、ただユーザの音声通話だけを支援するのに使用される。しかし、ユーザがまたＳＲＶＣＣを使用して映像／マルチメディアデータを伝送することを希望するシナリオが存在することができる。１つの通信装置上で駆動されている複数のアプリケーションが存在し、それぞれのアプリケーションは、少なくとも１つのベアラーと関連している。しかし、複数のアプリケーションには、音声及び映像ベアラーの両方を含む映像通話アプリケーションと同様に、特別な媒体ストリームのための１つ以上の専用ベアラーを有する任意のアプリケーションが存在することができる。したがって、どの媒体フローがハンドオーバー決定、ロードバランシング（ｌｏａｄ ｂａｌａｎｃｉｎｇ）中に選択的なベアラー不活性化などのようなシナリオのための特定のアプリケーションに属するかを認識することがネットワークノードによって要求されることができる。
したがって、通信において単一無線映像通話連続性を支援する必要が存在する。

本発明は、少なくとも上記で言及された問題点及び／または短所を扱い、少なくとも以下に説明する長所を提供するために設計された。したがって、本発明の一態様は、無線通信網で複数のネットワークベアラーを管理するための方法及び装置を提供するものである。

本発明の一態様によれば、無線通信網で複数のネットワークベアラーを管理するための方法が提供される。方法は、アプリケーションセッション（ａｐｐｌｉｃａｔｉｏｎ ｓｅｓｓｉｏｎ）のインスタンス（ｉｎｓｔａｎｃｅ）の開始（ｉｎｉｔｉａｔｉｏｎ）または更新（ｕｐｄａｔｅ）のうち少なくとも１つを識別する段階を含む。次に、方法は、アプリケーションセッションのインスタンスと関連した識別子（ｉｄｅｎｔｉｆｉｅｒ）を生成する。さらに、方法は、アプリケーションセッションのインスタンスの識別された開始または識別された更新の結果として設定されたそれぞれの複数のネットワークベアラーに識別子を割り当てる。

本発明の他の態様によれば、第１通信網から第２通信網へのハンドオーバー中に通信を管理する方法が提供される。方法は、ＰＳネットワークからＣＳネットワークへの指示（ＣＳ Ｎｅｔｗｏｒｋ ｉｎｄｉｃａｔｉｏｎ）にハンドオーバーを受信する段階を含む。次に、方法は、サービス識別子の品質に基づいて映像通話アプリケーションインスタンスに相当する複数のネットワークベアラーを識別し、複数のネットワークベアラーは、アプリケーションインスタンスに属するボイスベアラー及びビデオベアラーに相当する。その後、方法は、１つ以上のネットワークエレメント（ＮＥ）にビデオＳＲＶＣＣ能力（ｖｉｄｅｏ ＳＲＶＣＣ ｃａｐａｂｉｌｉｔｙ）を伝送する。

本発明のさらに他の実施例によれば、第１通信網から第２通信網へのハンドオーバー中に通信を管理する方法が提供される。方法は、ハンドオーバーを行うために、ＭＥの能力を識別する段階を含む。その後、方法は、ハンドオーバーを実行するためにＮＥに能力を伝送する段階を含む。

本発明のさらに他の実施例によれば、第１通信網から第２通信網へのハンドオーバー中に通信を管理する方法が提供される。ネットワークエレメント（ＮＥ）での方法は、ＰＳネットワークからＣＳネットワークにモバイルエンティティー（Ｍｏｂｉｌｅ Ｅｎｔｉｔｙ、ＭＥ）ビデオハンドオーバー能力を識別する段階を含む。その後、方法は、１つの映像通話セッション（ｖｉｄｅｏ ｃａｌｌ ｓｅｓｓｉｏｎ）に相当するアプリケーションセッション（ａｐｐｌｉｃａｔｉｏｎ ｓｅｓｓｉｏｎ）の１つのインスタンスを識別する。その後、方法は、ＭＥビデオＳＲＶＣＣ能力及びＰＳ→ＣＳネットワークに映像（ｖｉｄｅｏ）を実行するための識別子のうち少なくとも１つを使用してＰＳ→ＣＳ（ＰＳ ｔｏ ＣＳ）ネットワークにビデオハンドオーバーを実行し、識別子は、ハンドオーバーされやすいアプリケーションセッションと関連したそれぞれの複数のネットワークベアラーに割り当てられる。

本発明のさらに他の実施例によって、無線通信網で複数のネットワークベアラーを管理するシステムが提供される、システムは、アプリケーションセッションのインスタンスの開始または更新の少なくとも１つを識別する手段と；アプリケーションセッションのインスタンスの識別子を発生する手段と；アプリケーションセッションのインスタンスの識別された開始または識別された更新の結果として設定されたそれぞれの複数のネットワークベアラーに識別子を割り当てる手段と；を含む。

本発明のさらに他の実施例によれば、第１通信網から第２通信網へのハンドオーバー中に通信を管理するシステムが提供される。システムは、ＰＳネットワークからＣＳネットワーク指示にハンドオーバーを受信する手段と；サービス識別子の品質に基づいて１つの映像通話アプリケーションに相当する複数のネットワークベアラーを識別する手段であって、複数のネットワークベアラーは、アプリケーションインスタンスに属するボイスベアラー及びビデオベアラーに相当するネットワークベアラーを識別する手段と；１つ以上のネットワークエレメント（ＮＥ）にビデオＳＲＶＣＣ能力を伝送する手段と；を含む。

本発明のさらに他の実施例によれば、モバイルエンティティー（ＭＥ）が提供される。モバイルエンティティー（ＭＥ）は、プロセッサ及びトランシーバ（ｔｒａｎｓｃｅｉｖｅｒ）を含む。プロセッサは、モバイルエンティティー（ＭＥ）のビデオ単一無線音声通話連続性（ｖｉｄｅｏ Ｓｉｎｇｌｅ Ｒａｄｉｏ Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ、ＳＲＶＣＣ）能力を識別するためのものである。

本発明のさらに他の実施例によれば、ネットワークエレメント（ＮＥ）が提供される。ネットワークエレメント（ＮＥ）は、プロセッサ及びトランシーバを含む。プロセッサは、ＰＳネットワークからＣＳネットワークへのモバイルエンティティービデオハンドオーバー能力（Ｍｏｂｉｌｅ Ｅｎｔｉｔｙ ｖｉｄｅｏ ｈａｎｄｏｖｅｒ ｃａｐａｂｉｌｉｔｙ）を識別することができる。また、プロセッサは、１つの映像通話セッションに相当するアプリケーションのインスタンスを識別する。トランシーバは、ＭＥビデオＳＲＶＣＣ能力及びＰＳ→ＣＳネットワークに映像を実行するための識別子のうち少なくとも１つを使用してＰＳ→ＣＳネットワークにビデオハンドオーバーを実行することができ、識別子は、ハンドオーバーされやすいアプリケーションセッションと関連したそれぞれの複数のネットワークベアラーに割り当てられる。
本発明の実施例による上記及び他の態様、特徴、及び利点は、添付の図面とともに与えられた以下の詳細な説明からさらに明らかになる。

本発明の一実施例によって単一ベアラー（ｓｉｎｇｌｅ ｂｅｒａｒｅｒ）が音声及び映像の両方を伝達するために設定される時、ハンドオーバー中に映像通話アプリケーション（ｖｉｄｅｏ ｃａｌｌ ａｐｐｌｉｃａｔｉｏｎ）を支援する方法を説明するフローダイヤグラムを示す。 本発明の一実施例によって無線通信網で複数のネットワークベアラーを管理するためのフローダイヤグラムを示す。 本発明の一実施例によって生成された識別子に基づいて映像通話アプリケーションを支援する方法を説明するフローダイヤグラムを示す。 本発明の一実施例によってハンドオーバー中に映像通話アプリケーションを支援する方法を説明するフローダイヤグラムを示す。 本発明の一実施例によってハンドオーバー中に映像通話アプリケーションを支援する方法を説明するフローダイヤグラムを示す。 本発明の他の実施例によってハンドオーバー中に映像通話アプリケーションを支援する方法を説明するフローダイヤグラムを示す。 本発明の他の実施例によってハンドオーバー中に映像通話アプリケーションを支援する方法を説明するフローダイヤグラムを示す。

本技術分野の熟練された者は、図面の構成要素が単純性と明瞭性のために図示され、縮尺に合わせて図示されないこともあることを理解することができる。例えば、図面において一部の構成要素の寸法は、本発明の様々な実施例の理解を助けるために他の構成要素と関連して誇張されることができる。

全体図面にわたって、類似の参照番号は、同一または類似の構成要素、特徴、及び構造を示すのに使用することに留意しなければならない

以下の説明は、添付の図面を参照して、請求項及びその均等物によって限定されたもののような本発明の任意の実施例の包括的な理解を助けるために提供される。たとえ説明が理解を助けるために多様な特定の詳細事項を含むとしても、これらは、ただ例示として見なされなければならない。したがって、本発明の属する技術分野における通常の知識を有する者は、本発明の文書に記載された実施例を本発明の範囲と思想を逸脱しない範囲内で多様に変形または変更させることができると理解することができる。さらに、よく知られた機能と構造の説明は、明確性と簡潔性のために省略された。
以下の説明及び請求項に使用された用語と単語は、辞書的意味に限定されず、ただ本発明の明瞭で一貫した理解を助けるために発明者によって使用された。

単数の形態である“１つの（ａ、ａｎ及びｔｈｅ）は、 文脈が特に明記しない限り、複数の指示対象（ｐｌｕｒａｌ ｒｅｆｅｒｅｎｔｓ）を含むものと理解しなければならない。したがって、例えば、‘１つの（ａ）構成要素表面’に対する言及は、１つ以上の表面に対する言及を含む。

“実質的に（ｓｕｂｓｔａｎｔｉａｌｌｙ）”という文具によって、引用された特性、パラメータ、または値が正確に達成される必要はないが、例えば、許容誤差、測定誤差、測定正確度限界値及び本技術分野の熟練された者に知られた他の要因を含む偏差または変動は、特性が提供するように意図された効果を排除しない量で発生する。

以下で論議されるように、図１〜図７、及びこの特許文献で本発明の原理を記述するのに使用される多様な実施例は、ただ説明のためのものであり、本発明の範囲を限定するものに理解してはならない。本技術分野の熟練された者は、本発明の原理が任意の適切に配置された通信システムで具現されることができることを理解することができる。多様な実施例を説明するのに使用される用語は、例示的なものである。この用語は、ただ説明の理解を助けるために提供され、これらの使用と定義は、発明の範囲を限定しないことを理解しなければならない。別に明確に明記しない限り、一番目及び二番目などの用語は、同一の技術用語を有する客体を区別するのに使用され、時間的な手順を示すように意図しない。

図１は、本発明の一実施例において単一ベアラーが音声及び映像の両方を伝達するために設定される時、ハンドオーバー中に映像通話アプリケーションを支援する方法を説明するフローダイヤグラムを示す。

方法で、通信網での第１ＮＥ（Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ）は、測定報告が移動通信装備から受信される時、ハンドオーバー要請を第２ＮＥに伝送する。一実施例において、ハンドオーバーは、ビデオＳＲＶＣＣ ハンドオーバー（ｖｉｄｅｏ ＳＲＶＣＣ ｈａｎｄｏｖｅｒ）である。一実施例において、第１ネットワークエレメント（ＮＥ）は、ｅＮｏｄｅＢであり、第２ＮＥは、移動性管理エンティティー（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、ＭＭＥ）またはサービングＧＰＲＳサポートノード（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ、ＳＧＳＮ）である。

第２ＮＥは、ベアラー分離（ｂｅａｒｅｒ ｓｐｌｉｔｔｉｎｇ）を実行し、第３ＮＥにハンドオーバー要請を伝送する。一実施例において、第３ＮＥは、移動通信交換器センター（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ、ＭＳＣ）サーバーである。さらに、第３ＮＥは、ハンドオーバーのためのターゲットシステム（ｔａｒｇｅｔ ｓｙｓｔｅｍ）を用意し、第２ＮＥにハンドオーバー応答を返信する（ｓｅｎｄ ｂａｃｋ）。第２ＮＥは、その後、ターゲットシステムに移動するＭＥにハンドオーバー命令を伝送する。特定のネットワークエレメント（Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔｓ）に関連した詳細な方法が以下で追加に説明される。

方法で、ｅＮｏｄｅＢ及びＭＭＥは、映像通話（ｖｉｄｅｏ ｃａｌｌ）関連ベアラーを識別するためにＱＣＩ及び／またはＡＲＰ値を使用する。ｅＮｏｄｅＢは、映像（ｖｉｄｅｏ）及び音声（ｖｏｉｃｅ）の両方を伝達するベアラーに相当するサービスクラス識別子の品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｅｒ、ＱＣＩ）の存在及びＭＭＥからビデオＳＲＶＣＣ動作可能な（ＳＲＶＣＣ Ｏｐｅｒａｔｉｏｎ Ｐｏｓｓｉｂｌｅ）指示に基づいてビデオＳＲＶＣＣ動作をトリガーする。“ＳＲＶＣＣ Ｏｐｅｒａｔｉｏｎ Ｐｏｓｓｉｂｌｅ”は、暗黙的にｅＮｏｄｅＢに対するユーザ端末（ＵＥ）のビデオＳＲＶＣＣ能力（ＵＥ‘ｓ ｖｉｄｅｏ ＳＲＶＣＣ ｃａｐａｂｉｌｉｔｙ）を示す。ユーザ端末（ＵＥ）は、Ａｔｔａｃｈ／ＴＡＵ手続中に移動性管理エンティティー（ＭＭＥ）に対するそのビデオＳＲＶＣＣ能力を示す。移動性管理エンティティー（ＭＭＥ）は、その後、映像通話（ｖｉｄｅｏ ｃａｌｌ）用ＳＲＶＣＣハンドオーバー指示（ＳＲＶＣＣ ＨＯ ｉｎｄｉｃａｔｉｏｉｎ）、ＱＣＩ及び／またはＡＲＰ値に基づいてベアラーを分離する。移動性管理エンティティー（ＭＭＥ）は、その後、ＰＳ→ＣＳメッセージを映像通話指示用ＳＲＶＣＣにとともに移動通信交換器センター（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ、ＭＳＣ）サーバーに伝送する。ＭＳＣサーバーは、音声及び映像用セッションデータプロトコル（Ｓｅｓｓｉｏｎ Ｄａｔａ Ｐｒｏｔｏｃｏｌ、ＳＤＰ）を提供し、アプリケーションサーバーにｉｎｖｉｔｅメッセージを伝送する。方法でのメッセージの詳細なフローは、以下で説明される。

図１を参照すれば、段階１で、ユーザ端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ）は、測定報告をハンドオーバー（ＨａｎｄＯｖｅｒ、ＨＯ）を開始するためのソースＥ−ＵＴＲＡＮ １０４（またはＥ−ＵＴＲＡＮにあるｅＮｏｄｅＢ）に伝送する。段階２で、ｅＮｏｄｅＢ １０４は、ＳＲＶＣＣ動作がサービス品質クラス識別子（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ（ＱｏＳ）Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｅｒ（ＱＣＩ））及び／またはベアラーと関連した割当及び保有優先順位（Ａｌｌｏｃａｔｉｏｎ ａｎｄ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ、ＡＲＰ）値及び移動性管理エンティティー（ＭＭＥ）でＳＲＶＣＣ動作の可能性に基づいて音声（ｖｏｉｃｅ）用及び／または映像（ｖｉｄｅｏ）用にトリガーされなければならないかを識別する。

段階３で、ｅＮｏｄｅＢ １０４は、（ＱＣＩ値が‘２’である）ビデオベアラーだけでなく、（ＱＣＩ値が‘１’である）ボイスベアラーがＣＳ側に伝送されなければならないことを示す透明コンテナー（ｔｒａｎｓｐａｒｅｎｔ ｃｏｎｔａｉｎｅｒ）を用意する。透明コンテナーを用意するための情報は、それぞれＵＴＲＡＮ及びＥ−ＵＴＲＡＮのための技術標準（ＴＳ）２５．４１３［４］（ＴＳ ２５．４１３［４］）及びＴｓ ３６．４１３［３］に含まれている。また、ハンドオーバー要求（ＨＯ ｒｅｑｕｉｒｅｄ）メッセージは、ＳＲＶＣＣ動作が付録の表１に示されたように、映像通話（ｖｉｄｅｏ ｃａｌｌ）のためにトリガーされなければならないという指示を含む。さらに、高速パケット接続（Ｈｉｇｈ Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ、ＨＳＰＡ）の場合、指示（ｉｎｄｉｃａｔｉｏｎ）は、表２に示されたように、位置再設定要求（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ）メッセージで伝達される。

段階４で、移動性管理エンティティー（ＭＭＥ）１０６は、ｅＮｏｄｅＢ、ＱＣＩ 値及び／またはベアと関連したＡＲＰ値から受信されたビデオ指示（ｖｉｄｅｏ ｉｎｄｉｃａｔｉｏｎ）のためのＳＲＶＣＣの存在に基づいて分離を行う。段階５ａで、ＭＭＥ １０６は、映像だけでなく、音声データを提供するために、ＰＳ→ＣＳ要請（ＰＳ ｔｏＣＳｒｅｑｕｅｓｔ）において指示をＭＳＣサーバー１０８に伝送する。ＰＳ→ＣＳ要請メッセージは、付録の表３に示した。

段階５ｂで、もしＭＳＣサーバー１０８がＭＭＥ １０６及びＭＳＣサーバー１０８からビデオＳＤＰ（ｖｉｄｅｏ ＳＤＰ）を用意するために指示を受信すれば、ＭＳＣサーバー１０８は、拒絶（ｒｅｊｅｃｔ）メッセージを伝送し、映像通話（ｖｉｄｅｏ ｃａｌｌ）を支援することができない。この拒絶メッセージは、独立的に伝送されるか、または段階１２で説明されたＰＳ→ＣＳ応答（ＰＳ ｔｏ ＣＳ ｒｅｓｐｏｎｓｅ）の一部分として伝送されることができる。段階５ｃで、ターゲットＭＳＣ １１０は、位置再設定要請／ハンドオーバー要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ）（追加的なｓｏｕｒｃｅ ｔｏ ｔａｒｇｅｔ ｔｒａｎｓｐａｒｅｎｔ ｃｏｎｔａｉｎｅｒ）メッセージをターゲットＲＮＳ／ＢＳＳ １１４に伝送し、ＣＳ位置再設定（ＣＳ ｒｅｌｏｃａｔｉｏｎ）のための資源割当（ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）を要請する。

段階６ａで、ソースＭＭＥ １０６は、ターゲットＳＧＳＮ（ｔａｒｇｅｔ Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）１１２に位置再設定要請（ｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔ）をフォワーディングする。その後、段階６ｂで、ターゲットＳＧＳＮは、ターゲットＲＮＳ／ＢＳＳ １１４にハンドオーバー要請（ＨＯ ｒｅｑｕｅｓｔ）を伝送する。さらに、ＰＳ→ＣＳ指示子（ＰＳ−ｔｏ−ＣＳ ｉｎｄｉｃａｔｏｒ）は、またビデオベアラーのために設定される。段階７ａで、確認（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）は、またターゲットＲＮＳ／ＢＳＳ １１４から受信される。したがって、ターゲットＲＮＳ／ＢＳＳ １１４がＰＳ位置再設定／ハンドオーバー要請（ＰＳ ｒｅｌｏｃａｔｉｏｎ／ＨＯ ｒｅｑｕｅｓｔ）とともにＣＳ位置再設定／ハンドオーバー要請（ＣＳ ｒｅｌｏｃａｔｉｏｎ／ＨＯ ｒｅｑｕｅｓｔ）を受信した後、これは、適切なＣＳ資源（ＣＳ ｒｅｓｏｕｒｃｅｓ）とＰＳ資源（ＰＳ ｒｅｓｏｕｒｃｅｓ）を割り当てる。段階７ａで、ターゲットＲＮＳ／ＢＳＳ １１４は、位置再設定要請確認／ハンドオーバー要請確認（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ／ＨＯ ｒｅｑｕｅｓｔ ａｃｋｎｏｗｌｅｄｇｅ）（Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをターゲットＳＧＳＮ １１２に伝送することによって、用意したＰＳ位置再設定／ハンドオーバー（ＰＳ ｒｅｌｏｃａｔｉｏｎ／ＨＯ）を確認する。段階７ｂで、ターゲットＳＧＳＮ １１２は、位置再設定応答（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）（Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをソースＭＭＥ １０６に伝送する。

さらに、段階８は、以前の段階と並列で実行される。段階８ａで、ターゲットＲＮＳ／ＢＳＳ １１４は、位置再設定要請確認／ハンドオーバー要請確認（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ／Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ）（Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをターゲットＭＳＣに伝送することによって、用意したＣＳ位置再設定／ＨＯを確認する。段階８ｂで、ターゲットＭＳＣ １１０は、ハンドオーバー応答用意（Ｐｒｅｐａｒｅ Ｈａｎｄｏｖｅｒ Ｒｅｓｐｏｎｓｅ）（Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをＭＳＣサーバー１０８に伝送する。段階８ｃで、ターゲットＭＳＣ １１０とＭＳＣサーバー１０８と関連したＭＧＷとの回線連結（ｃｉｒｃｕｉｔ ｃｏｎｎｅｃｔｉｏｎ）が設定される。

位置再設定ハンドオーバー要請確認（ｒｅｌｏｃａｔｉｏｎ ＨＯ ｒｅｑｕｅｓｔ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）は、段階７ａ及び段階８ａで伝送される。段階９で、ＭＳＣサーバー１０８は、ビデオＳＤＰを用意するために移動性管理エンティティー（ＭＭＥ）１０６から指示を受信し、これは、ボイスＳＤＰ（ｖｏｉｃｅ ＳＤＰ）とともにビデオＳＤＰ（ｖｉｄｅｏ ＳＤＰ）を用意し、そうでなければ、これは、ただボイスだけのためのＳＤＰを提供する。

段階１０で、セッション伝達手続（ｓｅｓｓｉｏｎ ｔｒａｎｓｆｅｒ ｐｒｏｃｅｄｕｒｅ）の実行中に、遠隔終端（ｒｅｍｏｔｅ ｅｎｄ）は、ＴＳ ２３．２３７［９］によるＣＳ接続レッグ（ＣＳ ａｃｃｅｓｓ ｌｅｇ）のＳＤＰとともに更新される。ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットのダウンリンクフロー（ｄｏｗｎｌｉｎｋ ｆｌｏｗ）は、この点でＣＳ接続レッグに向かってスイッチングされる。段階１１で、ソースＩＭＳ １１８ 接続レッグは、ＴＳ ２３．２３７［９］によって解除される。段階１２で、ソースＭＳＣサーバー１０８は、またビデオ及びボイスのためのＳＤＰが用意されたか否かを示す指示を含む。したがって、もし段階５ａでのＭＭＥ １０６が音声／映像動作（ｖｏｉｃｅ／ｖｉｄｅｏ ｏｐｅｒａｔｉｏｎ）を要請するが、ＭＳＣサーバー１０８によって支援されなければ、ＭＳＣサーバー１０８は、ＳＲＶＣＣ動作が映像（ｖｉｄｅｏ）のために実行することができないことを示す応答（ｒｅｓｐｏｎｓｅ）を返信し、ただ音声だけのためのＳＲＶＣＣ動作とともに続く。

段階１３で、ソースＭＭＥ １０６は、２個の用意した再位置（ｒｅｌｏｃａｔｉｏｎｓ）を同期化し、ハンドオーバー命令（ＨＯ ｃｏｍｍａｎｄ、Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをソースＥ−ＵＴＲＡＮ １０４に伝送する。段階１４で、Ｅ−ＵＴＲＡＮ １０４は、Ｅ−ＵＴＲＡＮ命令メッセージからのハンドオーバー（ＨＯ）メッセージをユーザ端末（ＵＥ）１０２に伝送する。ユーザ端末（ＵＥ）１０２は、段階１５で、ターゲットＵＴＲＡＮ／ＧＥＡＲＮセルにチューニングされる。段階１６で、ターゲットＲＮＳ／ＢＳＳ １１４でのハンドオーバー検出（ＨＯ ｄｅｔｅｃｔｉｏｎ）が発生する。その後、ユーザ端末（ＵＥ）１０２は、ハンドオーバー完了メッセージ（ＨＯ ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）をターゲットＲＮＳ／ＢＳＳ １１４を介してターゲットＭＳＣ １１０に伝送する。もしターゲットＭＳＣ １１０がＭＳＣサーバー１０８ではない場合、ターゲットＭＳＣ １１０は、ＳＥＳ（ＨＯ Ｃｏｍｐｌｅｔｅ）メッセージをＭＳＣサーバー１０８に伝送する。段階１７ａで、ターゲットＲＮＳ／ＢＳＳ １１４は、位置再設定ハンドオーバー完了メッセージ（ｒｅｌｏｃａｔｉｏｎ ＨＯ ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）をターゲットＭＳＣ １１０に伝送する。段階１７ｂ及び段階１７ｃで、ターゲットＭＳＣ １１０は、ハンドオーバー完了メッセージ（ＨＯ Ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）をＭＳＣサーバーに伝送する。段階１７ｄで、ＭＳＣサーバー１０８は、ソースＭＭＥ １０６と共有されたＰＳ→ＣＳ確認（ＰＳ ｔｏ ＣＳ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を伝送する。段階１７ｅで、ＭＳＣサーバーは、ホーム位置レジスタ（Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ、ＨＬＲ）を更新する。

段階１８ａで、ターゲットＲＮＳ／ＢＳＳ １１４は、位置再設定ハンドオーバー完了メッセージ（ｒｅｌｏｃａｔｉｏｎ ＨＯ ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）をターゲットＳＧＳＮ １１２に伝送し、その後、ターゲットＳＧＳＮ １１２は、確認をソースＭＭＥ １０６に伝送する。段階１８ｃで、ターゲットＳＧＳＮ １１２は、サービングゲートウェイ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ、ＳＧＷ）１１６と通信を行い、ベアラーは、更新される。段階１９で、位置連続性（ｌｏｃａｔｉｏｎ ｃｏｎｔｉｎｕｉｔｙ）は、ＭＳＣサーバー１０８及びソースＭＭＥ １０６が加入者位置報告（ｓｕｂｓｃｒｉｂｅｒ ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔ）をゲートウェイモバイルロケーション センター（Ｇａｔｅｗａｙ Ｍｏｂｉｌｅ Ｌｏｃａｔｉｏｎ Ｃｅｎｔｅｒ、ＧＭＬＣ）に伝送する所で管理される。

図２は、本発明の一実施例によって無線通信網で複数のネットワークベアラーを管理するためのフローダイヤグラムを示す。

方法で、段階１で、第４ＮＥ ２０２は、アプリケーションインスタンスの開始または更新を識別する。一実施例において、第４ＮＥは、ＰＣＲＦエンティティー（ＰＣＲＦ ｅｎｔｉｔｙ）である。第４ＮＥは、１つのアプリケーションインスタンスから識別子を追加に獲得するか、またはアプリケーションインスタンスと関連したそれぞれのベアラーに統計的に生成された識別子を使用する。段階２で、第４ＮＥは、１つ以上のネットワークエレメント（ＮＥ）とともにメッセージを交換する。例えば、第１ＮＥ、第２ＮＥ、第５ＮＥ、第６ＮＥ。一実施例において、前記第１ＮＥは、ｅＮｏｄｅＢである。一実施例において、第２ＮＥは、ＭＭＥ／ＳＧＳＮである。一実施例において、第５ＮＥは、ＰＧＷである。一実施例において、第６ＮＥは、ＳＧＷである。

メッセージ交換で、第４ＮＥは、１つ以上の第１ＮＥとともに生成された識別子を通過させるでしょう。その後、１つ以上のＮＥは、追加的な決定（ｆｕｒｔｈｅｒ ｄｅｃｉｓｉｏｎｓ）のための識別子を格納する。一実施例において、決定は、ハンドオーバー決定（ｈａｎｄｏｖｅｒ ｄｅｃｉｓｉｏｎ）である。段階３で、１つ以上のＮＥは、決定をする目的、例えば、ハンドオーバー決定のために格納された識別子を使用する。

図３は、本発明の一実施例によって生成された識別子に基づいて映像通話アプリケーション（ｖｉｄｅｏ ｃａｌｌ ａｐｐｌｉｃａｔｉｏｎ）を支援する方法を説明するフローダイヤグラムを示す。

方法は、無線通信網で複数のネットワークベアラーを管理する。一実施例において、無線通信網は、Ｅ−ＵＴＲＡＮ通信網またはＵＭＴＳ通信網である。一実施例において、識別子は、固有に前記アプリケーションセッションのインスタンスとともにそれぞれの複数のベアラーを識別する。一実施例において、アプリケーションセッションの開始または更新に相当するそれぞれの複数のベアラーを識別し、複数のベアラーは、音声、映像及びテキストデータのうち少なくとも１つを運送する。一実施例において、アプリケーションセッションの開始または更新の手段は、１つのプロセッシングユニット（ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）である。

方法は、その後、アプリケーションセッションのインスタンスと関連した識別子を生成する。一実施例において、識別子は、アプリケーション識別子または相関関係識別子（ｃｏｒｒｅｌａｔｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）のうち少なくとも１つである。一実施例において、識別子は、第４ＮＥによって生成される。一実施例において、第４ＮＥは、政策及び課金規則機能（ＰＣＲＦ）エンティティーである。一実施例において、アプリケーションセッションのインスタンスと関連した識別子は、プロセッシングユニットによって生成されることができる。方法は、アプリケーションセッションのインスタンスの識別された開始または識別された更新の結果として設定されたそれぞれの複数のネットワークベアラーに識別子を追加に割り当てる。一実施例において、識別子を割り当てる手段は、プロセッシングユニットである。

一実施例において、方法は、識別子を第５ＮＥに伝送する。一実施例において、第５ＮＥは、パケットデータネットワーク（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ、ＰＤＮ）ゲートウェイである。方法は、その後、識別子を第５ＮＥから第６ＮＥに伝送する。一実施例において、第６ＮＥは、サービングゲートウェイ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ、ＳＧＷ）である。その後、方法は、第６ＮＥから（図１で言及された）第２ＮＥに識別子を伝送する。

一実施例において、識別子は、第５ＮＥ（ＰＧＷ）によって生成される。一実施例において、方法は、識別子を第５ＮＥから第６ＮＥ（ＳＧＷ）に伝送し、その後、第２ＮＥ（ＭＭＥ）に伝送される識別子を伝送する。一実施例において、アプリケーションセッションのインスタンスの開始は、モバイルエンティティー（Ｍｏｂｉｌｅ Ｅｎｔｉｔｙ、ＭＥ）と関連する。一実施例において、モバイルエンティティー（ＭＥ）のビデオＳＲＶＣＣ能力が識別される。さらに、生成し、割り当てる段階は、モバイルエンティティー（ＭＥ）がビデオＳＲＶＣＣ能力を有する時にのみ実行される。方法は、その後、少なくともモバイルエンティティー（ＭＥ）がビデオＳＲＶＣＣ可能である（ｖｉｄｅｏ ＳＲＶＣＣ ｃａｐａｂｌｅ）時、第１ＮＥ（ｅＮｏｄｅＢ）に識別子を伝送する。特定のネットワークエレメントと関連した詳細な方法が以下で追加に説明される。

この方法は、異なるベアラーが映像通話アプリケーションに相当するボイス及びビデオストリームのために設定される時に適用される。方法において、ダイナミック政策及び課金制御（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ、ＰＣＣ）が展開される時、政策及び課金規則機能（ＰＣＲＦ）は、政策及び課金執行機能（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｅｎｆｏｒｃｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ、ＰＣＥＦ）、例えば、パケットデータネットワークゲートウェイ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ、ＰＧＷ）に識別子を提供する。この識別子は、アプリケーションインスタンスから識別された実際的な識別子またはＰＣＲＦで統計的に構成された識別子であることができる。さらに、ＰＣＥＦは、ダイナミック ＰＣＣが展開されない時、統計的に割り当てられた識別子を使用する。ＰＣＥＦは、ベアラー要請生成（Ｃｒｅａｔｅ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ）メッセージでサービングゲートウェイ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ、ＳＧＷ）で識別子を伝送する。

ＳＧＷは、ＥＰＳ ベアラーアイデンティティー（ＥＰＳ ｂｅａｒｅｒ ｉｄｅｎｔｉｔｙ）及びリンクされたベアラーアイデンティティーとともにベアラー要請生成（Ｃｒｅａｔｅ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ）メッセージで移動性管理エンティティー（ＭＭＥ）にこの ＩＤを追加に伝送する。移動性管理エンティティー（ＭＭＥ）は、その後、ＵＥビデオＳＲＶＣＣ能力（ＵＥ ｖｉｄｅｏ ＳＲＶＣＣ ｃａｐａｂｉｌｉｔｙ）に基づいてベアラー設定要求（Ｂｅａｒｅｒ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ）メッセージでＥＰＳベアラーアイデンティティーとともにｅＮｏｄｅＢに同一の識別子を伝送するか否かを決定する。ユーザ端末（ＵＥ）は、“Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ”及び“ＴＡＵ Ｒｅｑｕｅｓｔ” メッセージで ‘ＵＥ Ｎｅｔｗｏｒｋ Ｃａｐａｂｉｌｉｔｙ’の一部分としてそのビデオＳＲＶＣＣ能力（ｖｉｄｅｏ ＳＲＶＣＣ ｃａｐａｂｉｌｉｔｙ）を示す。ＧＥＲＡＮ／ＵＴＲＡＮのために、これは、“ＭＳ Ｎｅｔｗｏｒｋ Ｃａｐａｂｉｌｉｔｙ”の一部分として含まれる。もしメカニズムがビデオを支援しない場合、これは、ユーザ端末（ＵＥ）からｅＮｏｄｅＢによってビデオＳＲＶＣＣハンドオーバー（ｖｉｄｅｏＳＲＶＣＣＨＯ）をトリガーすることを避ける。ＰＧＷ、ＳＧＷ、ＭＭＥ及びｅＮｏｄｅＢは、その後、追加的な決定のためにこの情報を局所的に格納する。方法でメッセージの詳細なフローが以下で説明される。

図３を参照すれば、段階１ａで、ＰＣＲＦ ２０２は、ダイナミックＰＣＣの場合、ＰＤＮゲートウェイ（ＰＤＮ ＧＷ）２０４に識別子を伝送する。ＰＣＲＦは、アプリケーションインスタンスから獲得された識別子または統計的に割り当てられた識別子を伝送することができる。ダイナミックＰＣＣが展開されない場合、ＰＤＮ ＧＷ ２０４は、段階２で言及されたように統計的に割り当てられた識別子を使用する。段階２で、ＰＤＮ ＧＷ ２０４は、ＥＰＳベアラーアイデンティティー（ＥＰＳ ｂｅａｒｅｒ ｉｄｅｎｔｉｔｙ）及びリンクされたベアラーアイデンティティーとともにサービングゲートウェイ（ＳＧＷ）１１６に識別子を伝送する。ＰＤＮ ＧＷ ２０４は、付録の表４に示されたように、識別子をベアラーコンテキスト（ｂｅａｒｅｒ ｃｏｎｔｅｘｔ）に格納する。

段階３で、ＳＧＷ １１６は、表５に示されたように、ベアラー要請生成（Ｃｒｅａｔｅ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ）メッセージにあるＥＰＳベアラーアイデンティティー及びリンクされたベアラーアイデンティティーとともにＭＭＥ １０６に識別子を伝送する。段階４で、ＭＭＥ １０６は、識別子をｅＮｏｄｅＢ １０４に伝送するか否かを条件（例えば、ＵＥビデオＳＲＶＣＣ能力）に基づいて決定する。

ＵＥ １０２は、それぞれのＡｔｔａｃｈ及びＴＡＵ手続中に “Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ”及び“ＴＡＵ Ｒｅｑｕｅｓｔ”メッセージで‘ＵＥ Ｎｅｔｗｏｒｋ Ｃａｐａｂｉｌｉｔｙ’の一部分としてそのビデオＳＲＶＣＣ能力（ｖｉｄｅｏ ＳＲＶＣＣ ｃａｐａｂｉｌｉｔｙ）を示す。

ＧＥＲＡＮ／ＵＴＲＡＮのために、もしＵＥ １０２がビデオＳＲＶＣＣを支援し、この段階に追加して、前記移動性管理エンティティー（ＭＭＥ）１０６が付録の表７に示されたように、ｅＮｏｄｅＢに対するベアラー設定要請（Ｂｅａｒｅｒ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ）メッセージ内で段階３で受信された識別子に信号を伝送すれば、これは、“ＭＳ Ｎｅｔｗｏｒｋ Ｃａｐａｂｉｌｉｔｙ”が一部分として含まれる。ＭＭＥ １０６は、付録の表８に示されたように、ベアラーコンテキスト（ｂｅａｒｅｒ ｃｏｎｔｅｘｔ）に識別子を格納する。

段階５で、ｅＮｏｄｅＢ １０４は、段階４で受信された前記識別子を格納する。段階６で、ユーザ端末（ＵＥ）１０２は、ＲＲＣ連結再構成完了（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅ）メッセージとともにｅＮｏｄｅＢ １０４に無線ベアラー活性化（ｒａｄｉｏ ｂｅａｒｅｒ ａｃｔｉｖａｔｉｏｎ）を確認する。段階７で、ｅＮｏｄｅＢ １０４は、ベアラー設定応答（Ｂｅａｒｅｒ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅ）メッセージで移動性管理エンティティー（ＭＭＥ）１０６にベアラー活性化（ｂｅａｒｅｒ ａｃｔｉｖａｔｉｏｎ）を確認し、識別子を含む。段階８で、ＮＡＳ階層（ｌａｙｅｒ）を使用するユーザ端末（ＵＥ）１０２は、ＥＰＳベアラーアイデンティティーを含むセッション管理応答（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｒｅｓｐｏｎｓｅ）を作る。ユーザ端末（ＵＥ）は、その後、直接伝達（セッション管理応答）（Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒ（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｎｔ Ｒｅｓｐｏｎｓｅ））メッセージをｅＮｏｄｅＢ １０４に伝送する。段階９で、ｅＮｏｄｅＢ １０４は、ｕｐｌｉｎｋ ＮＡＳ ｔｒａｎｓｐｏｒｔ（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｒｅｓｐｏｎｓｅ）メッセージを移動性管理エンティティー（ＭＭＥ）１０６に伝送し、識別子は、表９に示されたように、Ｅ−ＲＡＢ Ｅ−ＵＴＲＡＮ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｂｅａｒｅｒ ｓｅｔｕｐ ｒｅｓｐｏｎｓｅに含まれる。

段階１０で、移動性管理エンティティー（ＭＭＥ）１０６は、段階７でベアラー設定応答（Ｂｅａｒｅｒ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅ）メッセージ及び段階９でセッション管理応答（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｒｅｓｐｏｎｓｅ）メッセージを受信すれば、付録の表１０に示されたように、識別子を含む Ｃｒｅａｔｅ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅを伝送することによって、サービングゲートウェア（Ｓｅｒｖｉｎｇ ＧＷ、ＳＧＷ）１１６にベアラー活性化（ｂｅａｒｅｒ ａｃｔｉｖａｔｉｏｎ）を確認する。

段階１１で、ＳＧＷ １１６は、ベアラー応答生成（Ｃｒｅａｔｅ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅ）メッセージを伝送することによって、ＰＤＮ ＧＷ２０４にベアラー活性化を確認する。段階１２で、もし専用ベアラー活性化手続（ｄｅｄｉｃａｔｅｄ ｂｅａｒｅｒ ａｃｔｉｖａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ）がＰＣＲＦ ２０２からＰＣＣ Ｄｅｃｉｓｉｏｎ Ｐｒｏｖｉｓｉｏｎメッセージによってトリガーされれば、ＰＤＮ ＧＷ ２０４は、ＩＰ−ＣＡＮ ｓｅｓｓｉｏｎ ｍｏｄｉｆｉｃａｔｉｏｎメッセージ（識別子）をＰＣＲＦ ２０２に伝送する。

図４は、本発明の一実施例によってハンドオーバー中に映像通話アプリケーション（ｖｉｄｅｏ ｃａｌｌ ａｐｐｌｉｃａｔｉｏｎ）を支援する方法を説明したフローダイヤグラムを示す。

方法は、初期に無線通信網で複数のネットワークベアラーを管理する。方法は、まず１つのアプリケーションセッションのインスタンスの開始または更新のうち少なくとも１つを識別する。その後、方法は、アプリケーションセッションの前記インスタンスと関連した前記識別子を生成する。その後、方法は、アプリケーションセッションのインスタンスの識別された開始または識別された更新の結果として設定されたそれぞれの複数のネットワークベアラーに識別子を割り当てる。

一実施例において、方法は、第１通信網から第２通信網にハンドオーバーを行うためのモバイルエンティティー（ＭＥ）の能力を識別する。一実施例において、第１通信網は、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）ネットワークまたは高速パケットデータネットワーク（Ｈｉｇｈ Ｓｐｅｅｄ Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）であり、前記第２通信網は、ＵＴＲＡＮ（Ｕｎｉｖｅｒｓｉａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）またはＧＰＲＳ ＥＤＧＥ Ｒａｄｉｏ Ａｃｃｅｓｓ 通信網である。

一実施例において、方法は、モバイルエンティティー（ＭＥ）のプロセッサによって実行される。方法は、その後、ハンドオーバーを実行するためにネットワークエレメント（ＮＥ）に能力を伝送する。一実施例において、モバイルエンティティー（ＭＥ）の能力は、モバイルエンティティー（ＭＥ）のトランシーバによってネットワークエレメント（ＮＥ）に伝送される。一実施例において、モバイルエンティティー（ＭＥ）は、通信中にビデオＳＲＶＣＣ能力（ｖｉｄｅｏ ＳＲＶＣ Ｃｃａｐａｂｉｌｉｔｙ）をターンオンまたはターンオフすることができる。

一実施例において、モバイルエンティティー（ＭＥ）は、ＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）プロトコルで情報エレメント（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ、ＩＥ）内で第２ＮＥ（ＭＭＥ／ＳＧＳＮ）にそのビデオＳＲＶＣＣ能力を伝送する。一実施例において、情報エレメント（ＩＥ）は、表１２に示されたように、モバイルスチーション（ＭＳ）ネットワーク能力情報エレメント（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ（ＭＳ）Ｎｅｔｗｏｒｋ ｃａｐａｂｉｌｉｔｉｅｓ ＩＥ）である。他の実施例において、情報エレメント（ＩＥ）は、表１３に示されたように、ユーザ端末（ＵＥ）ネットワーク性能情報エレメント（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ（ＵＥ）Ｎｅｔｗｏｒｋ ｃａｐａｂｉｌｉｔｉｅｓ ＩＥ）である。たとえ情報エレメント（ＩＥ）の２つのタイプだけを上記説明で言及されたが、これは、本発明を２つのタイプに限定するものではない。しかし、本技術分野の熟練された者は、標準で情報エレメントの任意の他のタイプまたは表１４に示されたように標準で知られていない新しいタイプの情報エレメント（ＩＥ）を使用することができる。

一実施例において、モバイルエンティティー（ＭＥ）の能力は、第１ＮＥ及び第２ＮＥによって識別される。一実施例において、方法は、映像通話セッションに相当するアプリケーションセッションのインスタンスを識別する。一実施例において、モバイルエンティティー（ＭＥ）の能力及びアプリケーションセッションのインスタンスは、第１ＮＥまたは第２ＮＥのプロセッサによって識別される。

したがって、方法は、ＭＥビデオＳＲＶＣＣ能力及びＰＳネットワークからＣＳネットワークに映像（ｖｉｄｅｏ）を実行するための識別子のうち少なくとも１つを使用してＰＳネックワークからＣＳネットワークにビデオハンドオーバーを実行し、識別子は、ハンドオーバーされやすいアプリケーションセッションと関連したそれぞれの複数のネットワークベアラーに割り当てられる。一実施例において、ハンドオーバーは、第１ＮＥまたは第２ＮＥのトランシーバによって実行される。

一実施例において、方法は、ハンドオーバー要求された（Ｈａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄ）メッセージまたは位置再設定が要求された（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ）メッセージで第２ＮＥ（ＭＭＥ／ＳＧＳＮ）にビデオＳＲＶＣＣハンドオーバー指示（ｖｉｄｅｏ ＳＲＶＣＣ ｈａｎｄｏｖｅｒ ｉｎｄｉｃａｔｉｏｎ）を伝送する。方法は、その後、受信されたビデオハンドオーバー指示（ｖｉｄｅｏ ｈａｎｄｏｖｅｒ ｉｎｄｉｃａｔｉｏｎ）に基づいてベアラー分離を実行する。一実施例において、ベアラー分離は、第２ＮＥ（ＭＭＥ／ＳＧＳＮ）で実行される。方法は、また、パケット交換→回線交換要請（Ｐａｃｋｅｔ Ｓｗｉｃｈｅｄ（ＰＳ）ｔｏ Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ（ＣＳ）Ｒｅｑｕｅｓｔ）メッセージでビデオＳＲＶＣＣ ハンドオーバー指示（ｖｉｄｅｏ ＳＲＶＣＣ ｈａｎｄｏｖｅｒ ｉｎｄｉｃａｔｉｏｎ）を第３ＮＥ（ＭＳＣサーバー）に伝送する。

一実施例において、セッションデータプロトコル（Ｓｅｓｓｉｏｎ Ｄａｔａ Ｐｒｏｔｏｃｏｌ、ＳＤＰ）は、ビデオＳＲＶＣＣ ハンドオーバー指示に基づいて第３ＮＥ（ＭＳＣサーバー）によって用意し、ＰＳ→ＣＳ応答メッセージで実行されたＳＲＶＣＣ動作に関して第２ＮＥに通知する。特定のネットワークエレメントに関連した詳細な方法が以下で追加に説明する。

方法で、ｅＮｏｄｅＢ １０４及びＭＭＥ １０６は、専用ベアラー活性化（ｄｅｄｉｃａｔｅｄ ｂｅａｒｅｒ ａｃｔｉｖａｔｉｏｎ）の一部分としてまたはベアラー活性化プロセスが開始されたユーザ端末（ＵＥ ｉｎｉｔｉａｔｅｄ ｂｅａｒｅｒ ａｃｔｉｖａｔｉｏｎ ｐｒｏｃｅｓｓ）として ＰＣＲＦ／ＰＧＷから識別子を受信する。さらに、この方法において、ｅＮｏｄｅＢ １０４は、ＵＥビデオＳＲＶＣＣ能力、ボイスベアラー用ＱＣＩ値及びビデオベアラー用ＱＣＩ値（例えば、値‘１’を有するＱＣＩ及び値‘２’を有するＱＣＩ）及び識別子を暗示的に指示する‘ＳＲＶＣＣ ｏｐｅｒａｔｉｏｎ ｐｏｓｓｉｂｌｅ’に基づいて映像通話動作（ｖｉｄｅｏ ｃａｌｌ ｏｐｅｒａｔｉｏｎ）のためのＳＲＶＣＣをトリガーする。

移動性管理エンティティー（ＭＭＥ）１０６は、ビデオＳＲＶＣＣハンドオーバー指示（ｖｉｄｅｏ ＳＲＶＣＣ ＨＯ ｉｎｄｉｃａｔｉｏｎ）、ＱＣＩ値、及び識別子に基づいてベアラーを分離する。ＭＭＥ １０６は、その後、映像通話指示（ｖｉｄｅｏ ｃａｌｌ ｉｎｄｉｃａｔｉｏｎ）のためのＳＲＶＣＣとともにＰＳ→ＣＳメッセージをＭＳＣサーバー１０８に伝送する。ＭＳＣサーバー１０８は、音声と映像のためのＳＤＰを提供し、アプリケーションサーバーにｉｎｖｉｔｅを伝送する。方法は、フローダイヤグラムの助けで追加に説明される。

図４を参照すれば、ｅＮｏｄｅＢ １０４及びＭＭＥ １０６は、ビデオテレポニーアプリケーション（ｖｉｄｅｏ ｔｅｌｅｐｈｏｎｙ ａｐｐｌｉｃａｔｉｏｎ）のための専用ベアラー活性化手続（ｄｅｄｉｃａｔｅｄ ｂｅａｒｅｒ ａｃｔｉｖａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ）中に識別子を識別する。段階１で、ユーザ端末（ＵＥ）１０２は、Ｅ−ＵＴＲＡＮ／ｅＮｏｄｅＢ １０４に測定報告（ｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔｓ）を伝送する。Ｅ−ＵＴＲＡＮ １０４は、音声と映像のためのＱＣＩ値を別途のアイデンティティー（ｓｅｐａｒａｔｅ ｉｄｅｎｔｉｔｙ）として、例えば、音声用値‘１’を有するＱＣＩ、映像用値‘２’を有するＱＣＩ及びそれぞれの識別子として考慮し、映像用ＳＲＶＣＣハンドオーバー（ＳＲＶＣＣ ｈａｎｄｏｖｅｒ ｆｏｒ ｖｉｄｅｏ）をトリガーする。

段階３で、ｅＮｏｄｅＢ １０４は、ＬＴＥのための表１及びＨＳＰＡのための表２に示されたように、音声の代わりに映像用ＳＲＶＣＣハンドオーバー指示（ＳＲＶＣＣ ＨＯ Ｉｎｄｉｃａｔｉｏｎ）を伝送する。段階４で、ソースＭＭＥ（ｓｏｕｒｃｅ ＭＭＥ）１０６は、すべての他のＰＳベアラーからビデオテレポニーアプリケーションに属する音声及び映像ベアラーを分離し、ＭＳＣサーバー１０８及びＳＧＳＮ １１２に向かってそれらの位置再設定（ｒｅｌｏｃａｔｉｏｎ）を開始する。決定は、ボイス及びビデオベアラーと関連したＱＣＩ、映像用ＳＲＶＣＣハンドオーバー指示（ＳＲＶＣＣ ＨＯ Ｉｎｄｉｃａｔｉｏｎ ｆｏｒ ｖｉｄｅｏ）及び識別子に根拠する。段階５ａで、ＭＭＥ １０６は、ＰＳ→ＣＳ要請が表３に示されたように、ＳＲＶＣＣビデオテレポニーアプリケーション（ＳＲＶＣＣ ｖｉｄｅｏ ｔｅｌｅｐｈｏｎｙ ａｐｐｌｉａｃｔｉｏｎ）に関するものを示す指示（ｉｎｄｉｃａｔｉｏｎ）を含む。

段階５ｂで、ＭＳＣサーバー１０８がＭＭＥ １０６からビデオＳＤＰ（ｖｉｄｅｏ ＳＤＰ）を用意するために指示を受信し、ＭＳＣサーバー１０８が映像（ｖｉｄｅｏ）を支援することができない時、ＭＳＣサーバー１０８は、拒絶メッセージ（ｒｅｊｅｃｔ）を伝送する。この拒絶メッセージ（ｒｅｊｅｃｔ）は、独立的に伝送されるか、または段階１２で言及された ＰＳ→ＣＳ応答メッセージの一部分として伝送されることができる。段階５ｃで、ターゲットＭＳＣ １１０は、ターゲットＲＳＳ／ＢＳＳ １１４に位置再設定要請／ハンドオーバー要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ）（追加的なＳｏｕｒｃｅ ｔｏ Ｔｒａｇｅｔ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージを伝送することによって、ＣＳ位置再設定のための資源割当（ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）を要請する。段階６ａで、位置再設定／ハンドオーバー要請（ｒｅｌｏｃａｔｉｏｎ／ＨＯ ｒｅｑｕｅｓｔ）は、ターゲットＳＧＳＮ １１２にフォワーディングされ、その後、同一の要請がターゲットＲＮＳ／ＢＳＳ １１４に伝送される。その後、確認がターゲットＲＮＳ／ＢＳＳ １１４からターゲットＳＧＳＮ １１２に受信される。

段階７で、ターゲットＲＮＳ／ＢＳＳ １１４がＰＳ位置再設定／ハンドオーバー要請（ＰＳ ｒｅｌｏｃａｔｉｏｎ／ｈａｎｏｖｅｒ ｒｅｑｕｅｓｔ）とともにＣＳ位置再設定／ハンドオーバー要請（ＣＳ ｒｅｌｏｃａｔｉｏｎ／ｈａｎｄｏｖｅｒ ｒｅｑｕｅｓｔ）を受信する時、ＲＮＳ／ＢＳＳ １１４は、適切なＣＳ及びＰＳ資源（ＣＳ ａｎｄ ＰＳ ｒｅｓｏｕｒｃｅｓ）を割り当てる。したがって、段階７ａで、ターゲットＲＮＳ／ＢＳＳ １１４は、位置再設定要請確認／ハンドオーバー要請確認（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ／Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ）（Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをターゲットＳＧＳＮ １１２に伝送することによって、用意したＰＳ位置再設定／ハンドオーバー（ＰＳ ｒｅｌｏｃａｔｉｏｎ／ｈａｎｄｏｖｅｒ）を確認する。段階７ｂで、ターゲットＳＧＳＮ １１２は、位置再設定応答（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）（Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをソースＭＭＥ １０６に伝送する。
また、段階８が以前段階と並列で実行される。段階８ａで、ターゲットＲＮＳ／ＢＳＳ １１４は、位置再設定要請確認／ハンドオーバー要請確認（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ／Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ）（Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをターゲットＭＳＣ １１０に伝送することによって、用意したＣＳ位置再設定／ハンドオーバー（ＣＳ ｒｅｌｏｃａｔｉｏｎ／ｈａｎｄｏｖｅｒ）を確認する。段階８ｂで、ターゲットＭＳＣ １１０は、ＭＳＣサーバー１０８に用意したハンドオーバー応答（Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージを伝送する。段階８ｃで、回線連結（ｃｉｒｃｕｉｔ ｃｏｎｎｅｃｔｉｏｎ）は、ターゲットＭＳＣ １１０とＭＳＣサーバー１０８と関連したモバイルゲートウェイ（Ｍｏｂｉｌｅ Ｇａｔｅｗａｙ、ＭＧＷ）との間に設定される。

段階９で、ＭＳＣサーバー１０８は、ＭＭＥ １０６からの指示に基づいてセッションデータプロトコル（ＳＤＰ）を提供する。したがって、もし指示がただ音声だけのためのＳＲＶＣＣのためのものなら、これは、音声だけのためのＳＤＰを提供する。しかし、もし指示が映像のためのＳＲＶＣＣのためのものなら、ＭＳＣサーバー１０８は、音声と映像のためのＳＤＰを用意する。段階１０で、セッション伝達手続の実行中に、遠隔終端（ｒｅｍｏｔｅ ｅｎｄ）は、ＴＳ ２３．２３７ ［９］によってＣＳ接続レッグ（ＣＳ ａｃｃｅｓｓ ｌｅｇ）のＳＤＰとともに更新される。また、ＶｏＩＰパケットのダウンリンクフローは、ＣＳ接続レッグに向かってスイッチングされる。

段階１１で、ソース ＩＭＳ 接続レッグは、ＴＳ ２３．２３７ ［９］によって解除される（ｒｅｌｅａｓｅｄ）。段階１２で、ＭＳＣサーバー１０８は、応答が表１１に示されたように、応用することができるＳＲＶＣＣ映像または音声動作（ＳＲＶＣＣ ｖｉｄｅｏ ｏｒ ｖｏｉｃｅ ｏｐｅｒａｔｉｏｎ）のためのものであると示す。もし、ＭＭＥ １０６が段階５ａで音声／映像動作（ｖｏｉｃｅ／ｖｉｄｅｏ ｏｐｅｒａｔｉｏｎ）を要請したが、ＭＳＣサーバー１０８によって支援されなければ、ＭＳＣサーバー１０８は、ＳＲＶＣＣ動作が映像（ｖｉｄｅｏ）のために実行されることができず、音声だけのためのＳＲＶＣＣ動作を継続することを示す応答を返信する。

段階１３で、ソースＭＭＥ １０６は、２個の用意した位置再設定（ｒｅｌｏｃａｔｉｏｎ）を同期化し、ハンドオーバー命令メッセージ（ＨＯ ｃｏｍｍａｎｄ ｍｅｓｓａｇｅ）をソースＥ ＵＴＲＡＮ １０４に伝送する。段階１４で、Ｅ ＵＴＲＡＮ １０４は、ハンドオーバー（ＨＯ）をＥ ＵＴＲＡＮ命令メッセージ（Ｅ ＵＴＲＡＮ ｃｏｍｍａｎｄ ｍｅｓｓａｇｅ）からユーザ端末（ＵＥ）１０２に伝送する。段階１５で、ユーザ端末（ＵＥ）１０２は、ターゲットＵＴＲＡＮ／ＧＥＡＲＮセルにチューニングされる。段階１６で、ターゲットＲＮＳ／ＢＳＳ １１４でのハンドオーバー検出（ＨＯ ｄｅｔｅｃｔｉｏｎ）が発生する。ユーザ端末（ＵＥ）１０２は、ターゲットＲＮＳ／ＢＳＳ １１４を介してターゲットＭＳＣ １１０にハンドオーバー完了メッセージ（ＨＯ ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）を伝送する。さらに、もしターゲットＭＳＣ １１０がＭＳＣサーバーではない場合、ターゲットＭＳＣ １１０は、ＳＥＳ（Ｈａｎｄｏｖｅｒ ｃｏｍｐｌｅｔｅ）メッセージをＭＳＣサーバーに伝送する。

段階１７ａで、位置再設定ハンドオーバー完了（ｒｅｌｏｃａｔｉｏｎ ＨＯ ｃｏｍｐｌｅｔｅ）メッセージは、ターゲットＭＳＣ １１０で受信される。段階１７ｂ及び段階１７ｃで、ハンドオーバー完了メッセージ（ＨＯ ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）は、ターゲットＭＳＣ １１０からＭＳＣサーバー１０８に伝送され、また、ハンドオーバー（ＨＯ）に対する応答（ａｎｓｗｅｒ）が伝送される。段階１７ｄで、ＭＳＣサーバー１０８は、ＰＳ→ＣＳ完了通知メッセージ（ＰＳ ｔｏ ＣＳ ｃｏｍｐｌｅｔｅ ｎｏｔｉｆｉｃａｔｉｏｎ ｍｅｓｓａｇｅ）をＳＲＶＣＣが映像通話アプリケーション（ｖｉｄｅｏ ｃａｌｌ ａｐｐｌｉｃａｔｉｏｎ）のために実行されたことを示す指示とともに移動性管理エンティティー（ＭＭＥ）１０６に返信する。段階１７ｅで、位置（ｌｏｃａｔｉｏｎ）は、ホーム位置レジスタ（ＨＬＲ）で更新される。また、段階１８で、ＰＳ→ＣＳ指示子は、ビデオベアラーのために含まれ、ＭＢＲは、ｎ／ＧｐＳＧＳＮのために、そしてビデオベアラーのために０に設定される。段階１９で、位置連続性（ｌｏｃａｔｉｏｎ ｃｏｎｔｉｎｕｉｔｙ）は、緊急通話（ｅｍｅｒｇｅｎｃｙ ｃａｌｌｓ）のために管理される。

図５は、本発明の一実施例によってハンドオーバー中に映像通話アプリケーション（ｖｉｄｅｏ ｃａｌｌ ａｐｐｌｉｃａｔｉｏｎ）を支援する方法を説明したフローダイヤグラムを示す。

方法は、ＰＳネットワークからＣＳネットワークにハンドオーバー指示を受信する。方法は、サービス識別子の品質（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ ｉｄｅｎｔｉｆｉｅｒｓ）に基づいて映像通話アプリケーションに相当する複数のネットワークベアラーを追加に識別する。複数のネットワークベアラーは、１つのアプリケーションに属するボイスベアラー及びビデオベアラーに相当する。方法は、また１つ以上のネットワークエレメント（ＮＥ）にビデオＳＲＶＣＣ能力（ｖｉｄｅｏＳＲＶＣＣｃａｐａｂｉｌｉｔｉｅｓ）を伝送することを含む。一実施例において、ハンドオーバーは、ＰＳネットワークからＣＳネットワークに実行され、ビデオＳＲＶＣＣサービスに相当する。一実施例において、サービス識別子の品質は、サービスクラス識別子の品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｅｒｓ、ＱＣＩ）である。

異なるベアラーが映像通話アプリケーションに相当する音声及び映像ストリームのために設定され、値‘２’を有するＱＣＩは、常時値‘１’を有するＱＣＩを伴うという仮定に根拠する時、方法が適用される。さらに、（ＱＣＩ値が‘２’である）対話形ビデオ（ｃｏｎｖｅｒｓａｔｉｏｎａｌ ｖｉｄｅｏ）だけを使用するアプリケーションは存在しない。値‘１’を有するＱＣＩと値‘２’を有するＱＣＩを有するベアラーが存在し、移動性管理エンティティー（ＭＭＥ）が、ベアラーが同一のアプリケーションインスタンスに属し、ＣＳドメイン（ＣＳ ｄｏｍａｉｎ）に伝達されなければならないことを知る時のみに、この方法は、正確に動作する。

この方法で、ｅＮｏｄｅＢは、ＱＣＩ値 ‘２’を有するベアラーが存在するか否かに関係なく、‘１’であるＱＣＩ値を有する任意のベアラーが存在するか否かを検査する。さらに、もし、‘１’であるＱＣＩ値を有するベアラーが存在すれば、ｅＮｏｄｅＢは、ＳＲＶＣＣ動作をトリガーする。移動性管理エンティティー（ＭＭＥ）は、他のＰＳベアラーからボイスまたはボイス及びビデオベアラーを分離し、ＰＳ→ＣＳメッセージをＭＳＣサーバーに伝送する。さらに、もし、‘２’であるＱＣＩ値を有するベアラーも存在すれば、これは、ビデオＳＤＰも提供されなければならないことを示す指示を伝送する。また、これは、ターゲットＳＧＳＮに向かってそれぞれ‘１’及び‘２’のＱＣＩ値を有するベアラーを除いたＰＳベアラーの残りのハンドオーバーを開始する。

しかし、もし、ＭＳＣサーバーがビデオのために向上したら、これは、音声及び映像用ＳＤＰを提供し、そうでなければ、ＭＳＣサーバーは、映像が伝達されることができず、音声だけを続いて伝達することを示す応答をＭＭＥに返信する。移動性管理エンティティー（ＭＭＥ）は、ベアラーが、映像が支援されないという応答を受けた後、相当するビデオベアラーを不活性化させる。映像及び音声の両方が前記ＭＳＣサーバーで支援されることができれば、ＭＳＣサーバーは、音声及び映像用ＳＤＰを含むＳＩＰ ＩＮＶＩＴＥ要請をＳＣＣ ＡＳ（Ｓｅｓｓｉｏｎ Ｃｅｎｔｒａｌｉｚａｔｉｏｎ ａｎｄ Ｃｏｎｔｉｎｕｉｔｙ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）に伝送する。

しかし、もし、ＭＳＣサーバーが音声だけを支援すれば、ＭＳＣサーバーは、音声だけのためのＳＤＰを提供する。ＳＣＣ ＡＳは、ボイス（‘１’であるＱＣＩ値）及びビデオ（‘２’であるＱＣＩ値）ベアラーの存在に依存して次の措置を取ることができる。１番目の措置は、映像通話アプリケーション（ｖｉｄｅｏ ｃａｌｌ ａｐｐｌｉｃａｔｉｏｎ）がボイス及びビデオベアラーとともに活性化状態（ａｃｔｉｖｅ ｓｔａｔｅ）にあり、最初に伝達され、他の音声及び映像通話アプリケーションは、ホールド状態（ｈｅｌｄ ｓｔａｔｅ）で伝達される時である。２番目の措置は、音声通話アプリケーションが活性化状態にあり、最初に伝達され、他の映像及び音声通話アプリケーションが、もしあれば、ホールド状態で伝達される時である。方法は、フローダイヤグラムの助けで追加に説明される。

図５を参照すれば、ユーザ端末（ＵＥ）１０２は、段階１で測定報告を ｅＮｏｄｅＢ １０４に伝送する。段階２で、ｅＮｏｄｅＢ １０４は、ＳＲＶＣＣ 動作がＭＭＥ １０６で可能である時、‘１’であるＱＣＩ値を有するベアラーの存在に基づいてＳＲＶＣＣハンドオーバーをトリガーすることを決定する。段階３で、ｅＮｏｄｅＢ １０４は、ビデオベアラー（‘２’であるＱＣＩ値）だけでなく、ボイスベアラー（‘１’であるＱＣＩ値）がＣＳ側に伝達されなければならないと指示する透明コンテナーを用意しなければならない。透明コンテナーを用意するための情報は、それぞれＵＴＲＡＮ及びＥ−ＵＴＲＡＮのためのＴＳ ２５．４１３［４］及びＴＴ ３６．４１３［３］に含まれる。段階４で、ＭＭＥ １０６は、‘２’及び‘１’であるＱＣＩ値を有するベアラーの存在及びＳＲＶＣＣハンドオーバー指示に基づいて分離を実行する。

段階５ａで、移動性管理エンティティー（ＭＭＥ）１０６は、表３に示されたように、ビデオＳＤＰだけでなく、音声を提供するために、ＰＳ→ＣＳ要請において指示をＭＳＣサーバー１０８に伝送する。段階５ｂで、もしＭＳＣサーバー１０８がビデオを支援することができず、ＭＭＥ １０６からビデオＳＤＰを用意するために指示を受信すれば、ＭＳＣサーバー１０８は、拒絶メッセージを伝送する。拒絶メッセージは、独立的に伝送されるか、または段階１２で説明したように、ＰＳ→ＣＳ応答の一部分として伝送されることができる。段階５ｃで、ターゲットＭＳＣ １１０は、位置再設定要請／ハンドオーバー要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ）（追加的なＳｏｕｒｃｅ ｔｏ Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをターゲットＲＮＳ／ＢＳＳ １１４に伝送することによって、ＣＳ位置再設定（ＣＳ ｒｅｌｏｃａｔｉｏｎ）のための資源割当を要請する。

段階６で、ＰＤＰコンテキスト（ＰＤＰ ｃｏｎｔｅｘｔ）は、ビデオベアラーのためのコンテキストを含み、また、ＰＳ→ＣＳ指示子（ＰＳ ｔｏ ＣＳ ｉｎｄｉｃａｔｏｒ）がビデオベアラーのために設定される。段階７で、ターゲットＲＮＳ／ＢＳＳ １１４がＰＳ位置再設定／ハンドオーバー要請（ＰＳ ｒｅｌｏｃａｔｉｏｎ／ｈａｎｄｏｖｅｒ ｒｅｑｕｅｓｔ）とともにＣＳ位置再設定／ハンドオーバー要請（ＣＳ ｒｅｌｏｃａｔｉｏｎ／ｈａｎｄｏｖｅｒ ｒｅｑｕｅｓｔ）を受信した後、ターゲットＲＮＳ／ＢＳＳ １１４は、適切なＣＳ及びＰＳ資源を割り当てる。段階７ａで、ターゲットＲＮＳ／ＢＳＳ １１４は、位置再設定要請確認／ハンドオーバー要請確認（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ／Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ）（Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをターゲットＳＧＳＮ １１２に伝送することによって、用意したＰＳ位置再設定／ハンドオーバー（ＰＳ ｒｅｌｏｃａｔｉｏｎ／ｈａｎｄｏｖｅｒ）を確認する。段階７ｂで、ターゲットＳＧＳＮ １１２は、位置再設定応答（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）（Ｔｒａｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをソースＭＭＥ（ｓｏｕｒｃｅ ＭＭＥ）１０６に伝送する。

段階８ａで、ターゲットＲＮＳ／ＢＳＳ １１４は、位置再設定要請確認／ハンドオーバー要請確認（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ／Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ）（Ｔａｒｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをターゲットＭＳＣ １１０に伝送することによって、用意したＣＳ位置再設定／ハンドオーバーを確認する。段階８ｂで、ターゲットＭＳＣ １１０は、ハンドオーバー応答用意 （Ｐｒｅｐａｒｅ Ｈａｎｄｏｖｅｒ Ｒｅｓｐｏｎｓｅ）（Ｔｒａｇｅｔ ｔｏ Ｓｏｕｒｃｅ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをＭＳＣサーバー１０８に伝送する。段階８ｃで、回線連結（ｃｉｒｃｕｉｔ ｃｏｎｎｅｃｔｉｏｎ）は、ターゲットＭＳＣ １１０とＭＳＣサーバー１０８と関連したＭＧＷとの間に設定される。

段階９で、ＭＳＣサーバー１０８は、ビデオＳＤＰを用意するために移動性管理エンティティー（ＭＭＥ）１０６から指示を受信し、ＭＳＣサーバー１０８は、その後、ボイスＳＤＰとともにビデオＳＤＰを用意し、そうでなければ、これは、音声専用ＳＤＰを提供する。段階１０で、セッション伝達手続（Ｓｅｓｓｉｏｎ Ｔｒａｎｓｆｅｒ ｐｒｏｃｅｄｕｒｅ）が実行される間に、遠隔終端（ｒｅｍｏｔｅ ｅｎｄ）は、ＴＳ ２３．２３７［９］によってＣＳ接続レッグのＳＤＰとともに更新される。ＶｏＩＰパケットのダウンリンクフローは、この点でＣＳ接続レッグに向かってスイッチングされる。段階１１で、ソースＩＭＳ接続レッグは、ＴＳ ２３．２３７［９］によって解除される。

段階１２で、ＭＳＣサーバー１０８は、表１１に示されたように、映像及び音声のためのＳＤＰが用意したか否かを示す指示を含む。段階１３で、ソースＭＭＥ（ｓｏｕｒｃｅ ＭＭＥ）１０６は、前記２個の用意した再位置を同期化し、ハンドオーバー命令メッセージをソース Ｅ ＵＴＲＡＮ（ｓｏｕｒｃｅ Ｅ ＵＴＲＡＮ）１０４に伝送する。段階１４で、Ｅ ＵＴＲＡＮ １０４は、Ｅ ＵＴＲＡＮ命令メッセージからハンドオーバーメッセージ（ＨＯ ｍｅｓｓａｇｅ）をユーザ端末（ＵＥ）１０２に伝送する。段階１５で、ユーザ端末（ＵＥ）１０２は、ターゲットＵＴＲＡＮ／ＧＥＡＲＮセルにチューニングされる。

段階１６で、ターゲットＲＮＳ／ＢＳＳ １１４でのハンドオーバー検出（ＨＯ ｄｅｔｅｃｔｉｏｎ）が発生する。ユーザ端末（ＵＥ）１０２は、ハンドオーバー完了メッセージをターゲットＲＮＳ／ＢＳＳ １１４を介してターゲットＭＳＣ １１０に伝送する。しかし、もし、ターゲットＭＳＣ １１０がＭＳＣサーバーではない場合、ターゲットＭＳＣ １１０は、ＳＥＳ（ハンドオーバー完了）メッセージをＭＳＣサーバーに伝送する。段階１７ａで、位置再設定ハンドオーバー完了（ｒｅｌｏｃａｔｉｏｎ ＨＯ ｃｏｍｐｌｅｔｅ）メッセージは、ターゲットＭＳＣ １１０で受信される。段階１７ｂ及び段階１７ｃで、ハンドオーバー完了メッセージ（ＨＯ ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）は、ターゲットＭＳＣ １１０からＭＳＣサーバー１０８に伝送され、また、ハンドオーバーに対する返信（ａｎｓｗｅｒ ｔｏ ｔｈｅ ＨＯ）が伝送される。段階１７ｄで、ＭＳＣサーバー１０８は、ＰＳ→ＣＳ完了通知メッセージを、ＳＲＶＣＣが映像通話アプリケーションのために実行されたことを示す指示とともにソースＭＭＥ（ｓｏｕｒｃｅ ＭＭＥ）１０６に返信する。段階１７ｅで、位置は、ホーム位置レジスタ（ＨＬＲ）で更新される。

段階１８ａで、Ｒｅｌｏｃ／ＨＯ 完了メッセージは、ターゲットＳＧＳＮ １１２にターゲットＲＮＳ／ＢＳＳ １１４によって伝送される。段階１８ｂで、ＲＥｌｏｃ／ＨＯ ｃｏｍｐｌｅｔｅ／Ａｃｋ メッセージは、ターゲットＳＧＳＮ １１２によってソースＭＭＥ １０６に伝送される。段階１８ｂで、ベアラーは、ターゲットＳＧＳＮ １１２及びＳＧＷ １１６で更新される。ＰＳ→ＣＳ指示子は、ビデオベアラーのために含まれ、ＭＢＲは、Ｇｎ／Ｇｐ ＳＧＳＮのために、そしてビデオベアラーのために、０に設定される。段階１９で、緊急通話の位置連続性は維持される。

図６は、本発明の他の実施例によってハンドオーバー中に映像通話アプリケーションを支援する方法を説明したフローダイヤグラムを示す。

方法は、ＰＳネットワークからＣＳネットワークにハンドオーバー指示を受信する。方法は、サービス識別子の品質に基づいて映像通話アプリケーションに相当する複数のネットワークベアラーを追加に識別する。複数のネットワークベアラーは、１つのアプリケーションに属するボイスベアラー及びビデオベアラーに相当する。また、方法は、１つ以上のネットワークエレメント（ＮＥ）に対するビデオＳＲＶＣＣ能力を伝送することを含む。一実施例において、ハンドオーバーは、ＰＳネットワークからＣＳネットワークに実行され、ビデオＳＲＶＣＣ サービスに相当する。一実施例において、サービス識別子の品質は、サービスクラス識別子の品質（ＱＣＩ）である。

一実施例において、ビデオＳＲＶＣＣ動作が実行される時、方法は、ターゲットドメインに基づいて複数の透明コンテナーを用意する。一実施例において、複数の透明コンテナーは、第１ＮＥ（ｅＮｏｄｅＢ）によって実行される。

一実施例において、複数の透明コンテナーのうち少なくとも１つは、第１ＮＥから第２ＮＥ（ＭＭＥ／ＳＧＳＮ）に伝送される。例えば、４個のコンテナー、すなわち第１コンテナー、第２コンテナー、第３コンテナー、第４コンテナーは、第２ＮＥに伝送される。その後、少なくとも１つのコンテナーは、第３ＮＥ（ＭＳＣサーバー）に伝送され、第２ＮＥ（ＭＭＥ）は、サービングＧＰＲＳサポートノード（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ、ＳＧＳＮ）にコンテナーを伝送する前に応答を待つ。その後、応答メッセージは、確認メッセージまたは拒絶メッセージとともに第３ＮＥ及び第２ＮＥから伝送される。一実施例において、ターゲットベアラーに基づいて識別された透明コンテナーは、ＭＳＣサーバーから受信された前記応答メッセージに基づいてＭＳＣサーバー及び前記ＳＧＳＮに伝送される。特定のネットワークエレメントに関連した詳細な方法が以下で追加に説明される。

方法で、ＳＲＶＣＣ動作のために、ｅＮｏｄｅＢは、ターゲットドメインのための透明コンテナーを用意する。もしターゲットセルがＵＴＲＡＮなら、ｅＮｏｄｅＢは、すべてのベアラーに対する情報を含むＣＳ及びＰＳドメインのための単一コンテナーを用意するが、これは、ＴＳ ２５．４１３［７］のようにターゲットＲＮＣ透明コンテナー（ｔａｒｇｅｔ ＲＮＣ ｔｒａｎｓｐａｒｅｎｔ ｃｏｎｔａｉｎｅｒ）に対してソース無線ネットワーク制御機（ｓｏｕｒｃｅ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）（ＲＮＣ）で‘ＰＳ ＲＡＢ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｂｅａｒｅｒ）ｔｏ Ｂｅ Ｒｅｐｌａｃｅｄ’ フィールドを含む。交替されるこのようなＰＳ ＲＡＢは、ＣＳ側に伝達されるＲＡＢのＲＡＢ ＩＤを含み、このフィールドは、ＳＲＶＣＣハンドオーバー用にのみ適用されることができ、ここで、ボイスまたはビデオハンドオーバーに相当するＰＳベアラー（ＰＳ ｂｅａｒｅｒ）がＣＳドメインに伝達される。

さらに、もしターゲットがＧＥＡＲＮなら、別途のコンテナーがＣＳ及びＰＳドメインのために用意する。ＰＳドメインは、ＰＳドメインに伝達されるベアラーに関する情報を含み、ターゲットＣＳドメインのための透明コンテナーは、ＣＳ側に伝達されるベアラーに関する情報を含む。ＭＳＣサーバーが、ビデオがＣＳ側に伝達されることができるように音声と映像通話を支援する時、これは可能である。他の場合に、もしＭＳＣサーバーが映像通話を支援せず、ただ音声通話だけがＣＳ側に伝達される必要があれば、映像通話に関連したベアラーは、移動性管理エンティティー（ＭＭＥ）によって不活性化するか、またはＰＳドメインに伝達される必要がある。

ターゲット側に余剰の資源を格納することを避けるために、ｅＮｏｄｅＢは、４個の透明コンテナーを用意する。第１透明コンテナーは、ボイスベアラーだけに関する情報を有するＣＳドメイン透明コンテナーである。第２透明コンテナーは、音声及び映像の両方のための情報を有するＣＳドメイン透明コンテナーである。第３透明コンテナーは、すべての音声と映像に関連したベアラーを除いたＰＳベアラー（ＰＳ ｂｅａｒｅｒｓ）に関する情報を含むＰＳドメイン透明コンテナーである。第４透明コンテナーは、音声を除いた映像を含むＰＳベアラーに対する情報を含むＰＳドメイン透明コンテナーである。ｅＮｏｄｅＢは、４個のコンテナーをＭＭＥにフォワーディングする。

ＭＭＥは、ＭＳＣサーバーが音声及び映像通話動の両方を支援するものと仮定し、第２透明コンテナーをＭＳＣサーバーに伝送し、ＳＧＳＮに位置再設定要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）を伝送する前に、ＭＳＣサーバーから応答を待つ。ＭＳＣサーバーは、ビデオ動作が支援されるか、または実行中であることを示す確認（ＡＣＫ）メッセージまたはビデオ動作がＭＳＣサーバーで支援されないことを示す拒絶（ＲＥＪＥＣＴ）メッセージとともにＭＭＥに返信する。ＭＭＥは、前記ＭＳＣサーバーから受信されたメッセージに基づいて措置を取る。もしＭＳＣサーバーがＡＣＫに応答した場合、フォワーディングされた位置再設定要請（Ｆｏｒｗａｒｄｅｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージは、第３透明コンテナーとともにＳＧＳＮに伝送される。さらに、ＭＭＥは、第１透明コンテナーを含むＭＳＣサーバーに他のＰＳ→ＣＳ要請メッセージを返信し、もしＭＳＣサーバーがＲＥＪＥＣＴメッセージに応答した場合、第４透明コンテナーを有するＳＧＳＮに位置再設定要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージを伝送する。ＭＳＣサーバーは、ＣＳドメイン用ＰＳ→ＣＳ要請メッセージで伝送された透明コンテナーを使用する。

図６を参照すれば、段階１で、ユーザ端末（ＵＥ）１０２は、測定報告をｅＮｏｄｅＢ １０４に伝送する。段階２で、ｅＮｏｄｅＢ １０４は、ＳＲＶＣＣハンドオーバーをトリガーすることを決定する。段階３で、ｅＮｏｄｅＢ １０４は、４個の透明コンテナーを用意し、ハンドオーバー要求された（Ｈａｎｄｏｖｅｒ ｒｅｑｕｉｒｅｄ）メッセージで４個の透明コンテナーをすべて移動性管理エンティティー（ＭＭＥ）１０６に伝送する。ＵＴＲＡＮネットワークのための透明コンテナーを用意のための情報は、技術的標準ＴＳ ２５．４１３［４］に含まれ、Ｅ−ＵＴＲＡＮネットワークのための透明コンテナーを用意するための情報は、ＴＳ ３６．４１３［３］に含まれる。段階４で、ＭＭＥ １０６は、値‘１’及び値‘２’（ＱＣＩ＝‘２’及びＱＣＩ＝‘１’）及びＳＲＶＣＣハンドオーバー指示を有するベアラーの存在に基づいて分離を実行する。

段階５ａで、ＭＭＥ １０６は、ビデオＳＤＰだけでなく、音声を提供するために、ＰＳ→ＣＳ要請で指示をＭＳＣサーバー１０８に伝送する。また、ＭＭＥ １０６は、ＭＳＣサーバー１０８が音声及び映像通話動作の両方を支援するものと仮定し、ＭＳＣサーバー１０８に第２透明コンテナーを伝送し、ＳＧＳＮ １１２に位置再設定要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）を伝送する前にＭＳＣサーバー１０８から応答を待つ。段階５ａ１で、ＭＳＣサーバー１０８は、ビデオ動作が支援されるか、または実行中であることを示すＡＣＫメッセージ、またはビデオ動作がＭＳＣサーバー１０８で支援されないことを示す拒絶メッセージとともにＭＭＥ １０６に返信する。段階５ａ２で、もしＭＳＣサーバー１０８が拒絶メッセージで応答すれば、ＭＭＥ １０６は、フォワーディングされた位置再設定要請（Ｆｏｒｗａｒｄｅｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージは、第１透明コンテナーを含む他のＰＳ→ＣＳ要請メッセージをＭＳＣサーバー１０８に返信する。

段階５ｂで、ＭＳＣサーバー１０８は、移動性管理エンティティー（ＭＭＥ）１０６から獲得されたコンテナーのためメッセージを拒絶しない。段階５ｃで、ターゲットＭＳＣ １１０は、位置再設定要請／ハンドオーバー要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ）（追加的な Ｓｏｕｒｃｅ ｔｏ Ｔａｒｇｅｔ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをターゲットＲＮＳ／ＢＳＳ １１４に伝送することによって、ＣＳ位置再設定のための資源割当を要請する。段階６で、ＰＤＰコンテキスト（ＰＤＰ ｃｏｎｔｅｘｔ）は、ビデオベアラー用コンテキストを含む。ＰＳ→ＣＳ指示子がビデオベアラーのために設定される。もし ＭＳＣサーバー１０８がＡＣＫで応答した場合、ＭＭＥ １０６は、第３透明コンテナーとともにＳＧＳＮ １１２にフォワーディングされた再位置決定要請（Ｆｏｒｗａｒｄｅｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージを伝送する。もしＭＳＣサーバー１０８が拒絶メッセージで応答した場合、ＭＭＥ １０６は、ＳＧＳＮ １１２に第４透明コンテナーを伝送する。段階７ないし段階９は、図１、図２、図３、及び図４とともに説明されたように実行される。

図７は、本発明の他の実施例によってハンドオーバー中に映像通話アプリケーションを支援する方法を説明したフローダイヤグラムを示す。

方法は、ＰＳネットワークからＣＳネットワークにハンドオーバー指示を受信する。方法は、サービス識別子の品質に基づいて映像通話アプリケーションに相当する複数のネットワークベアラーを追加に識別する。複数のネットワークベアラーは、１つのアプリケーションに属するボイスベアラー及びビデオベアラーに相当する。また、方法は、１つ以上のネットワークエレメント（ＮＥ）にビデオＳＲＶＣＣ能力を伝送することを含む。一実施例において、ハンドオーバーは、ＰＳネットワークからＣＳネットワークに行われ、ビデオＳＲＶＣＣサービスに相当する。一実施例において、サービス識別子の品質は、サービスクラス識別子の品質（ＱＣＩ）である。

一実施例において、方法は、ビデオＳＲＶＣＣ動作が実行される時、ターゲットドメインに基づいて複数の透明コンテナーを用意する。一実施例において、複数の透明コンテナーは、第１ＮＥ（ｅＮｏｄｅＢ）によって実行される。一実施例において、複数の透明コンテナーのうち少なくとも１つは、第１ＮＥから第２ＮＥ（ＭＭＥ／ＳＧＳＮ）に伝送される。例えば、すべての４個のコンテナー、すなわち第１コンテナー、第２コンテナー、第３コンテナー、第４コンテナーは、第２ＮＥに伝送される。その後、複数のコンテナーは、第３ＭＥ（ＭＳＣサーバー）に伝送され、第２ＮＥ（ＭＭＥ）は、サービングＧＰＲＳサポートノード（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）（ＳＧＳＮ）にコンテナーを伝送する前に応答を待つ。

その後、応答メッセージは、確認メッセージまたは拒絶メッセージとともに第３ＮＥ及び第２ＮＥから伝送される。一実施例において、第２ＮＥは、第３ＮＥから応答メッセージに基づいてターゲットＰＳドメインに複数の透明コンテナーから少なくとも１つのコンテナーを伝送する。特定のネットワークエレメントに関連した詳細な方法は、以下で追加に説明される。

方法で、ｅＮｏｄｅＢは、４個の透明コンテナーを用意する。第１透明コンテナーは、ボイスベアラーだけに関する情報を有するＣＳドメイン透明コンテナーである。第２透明コンテナーは、音声及び映像の両方を提供するための情報を有するＣＳドメイン透明コンテナーである。第３透明コンテナーは、すべての音声と映像に関連したベアラーを除いたＰＳベアラーに対する情報を含むＰＳドメイン透明コンテナーである。第４透明コンテナーは、音声を除いて映像を含むＰＳベアラーに関する情報を含むＰＳドメイン透明コンテナーである。ｅＮｏｄｅＢは、すべての４個のコンテナーをＭＭＥにフォワーディングする。

ＭＭＥは、第１及び第２透明コンテナーをＭＳＣサーバーに伝送し、ＳＧＳＮで位置再設定要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）を伝送する前に、ＭＳＣサーバーから応答を待つ。ＭＳＣサーバーは、その後、適切で透明なコンテナーを使用し、例えば、映像を支援するＭＳＣサーバーの能力に依存して第１透明コンテナーまたは第２透明コンテナーを使用する。ＭＳＣサーバーは、ビデオ動作が支援され、実行中であることを示すＡＣＫメッセージまたはビデオ動作がＭＳＣサーバーで支援されないことを示すＲＥＪＥＣＴ メッセージでＭＭＥに返信する。

ＭＭＥは、ＭＳＣサーバーから受信されたメッセージに基づいて次の措置を取る。もしＭＳＣサーバーがＡＣＫを持って応答した場合、ＭＭＥは、フォワーディングされた位置再設定（Ｆｏｒｗａｒｄｅｄ Ｒｅｌｏｃａｔｉｏｎ）メッセージを第３透明コンテナーとともにＳＧＳＮに伝送する。さらに、もしＭＳＣサーバーがＲＥＪＥＣＴメッセージを持って応答した場合、ＭＭＥは、第４透明コンテナーとともに位置再設定要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージをＳＧＳＮに伝送する。

図７を参照すれば、段階１で、ユーザ端末（ＵＥ）１０２は、測定報告をｅＮｏｄｅＢ １０４に伝送する。ｅＮｏｄｅＢ １０４は、ＳＲＶＣＣハンドオーバーをトリガーすることを決定する。ｅＮｏｄｅＢ １０４は、４個の透明コンテナーを用意し、ハンドオーバー要求されたメッセージ（Ｈａｎｄｏｖｅｒ ｒｅｑｕｉｒｅｄ ｍｅｓｓａｇｅ）で４個のコンテナーをすべてＭＭＥ １０６に伝送する。透明コンテナーを用意するための情報は、ＵＴＲＡＮに対してＴＳ ２５．４１３［４］及びＥ−ＵＴＲＡＮに対してＴＳ ３６．４１３［３］に含まれる。

段階４で、ＭＭＥ １０６は、値‘１’及び値‘２’であるＱＣＩ値（ＱＣＩ＝２及びＱＣＩ＝１）、そしてＳＲＶＣＣハンドオーバー指示を有するベアラーの存在に基づいて分離を実行する。５ａで、ＭＭＥ １０６は、映像及び音声ＳＤＰを提供するために、ＰＳ→ＣＳ要請でＭＳＣサーバー１０８に指示を伝送する。また、ＭＭＥ １０６は、ＭＳＣサーバー１０８に第１及び第２透明コンテナーを伝送し、ＳＧＳＮ １１２に位置再設定要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）を伝送する前に、ＭＳＣサーバー１０８から応答を待つ。段階５ａ１で、ＭＳＣサーバー１０８は、ビデオ動作が支援され、実行中であることを示すＡＣＫメッセージ、またはビデオ動作がＭＳＣサーバー１０８で支援されないことを示すＲＥＪＥＣＴ メッセージでＭＭＥ １０６に返信する。

段階５ｂで、ＭＳＣサーバー１０８は、ビデオ支援有無に依存して第１及び第２透明コンテナーを含む。段階５ｃで、ターゲットＭＳＣ １１０は、位置再設定要請／ハンドオーバー要請（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ）（追加的なＳｏｕｒｃｅ ｔｏ Ｔａｒｇｅｔ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）メッセージをターゲットＲＮＳ／ＢＳＳ １１４に伝送することによって、ＣＳ位置再設定のための資源割当を要請する。段階６で、ＰＤＰコンテキスト（ＰＤＰ ｃｏｎｔｅｘｔ）は、また、ビデオベアラー用コンテキストを含む。ＰＳ→ＣＳ指示子は、また、ビデオベアラーのために設定される。

さらに、もし、ＭＳＣサーバー１０８がＡＣＫを持って応答した場合、ＭＭＥ １０６は、第３透明コンテナーとともにＳＧＳＮにフォワーディングされた位置再設定要請（Ｆｏｒｗａｒｄｅｄ Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージを伝送する。もしＭＳＣサーバー１０８がＲＥＪＥＣＴメッセージを持って応答した場合、ＭＭＥ １０６は、ＳＧＳＮ １１２に第４透明コンテナーを伝送する。段階７ないし段階９は、図１、図２、図３、及び図４とともに説明されたように実行される。

以上で説明したように、本発明の多様な実施例は、次のような長所を提供する。本発明は、複数の無線接続ネットワークにハンドオーバー中に映像通話を管理する方法を提供する。本発明は、インターラプトなしに進行中の映像通話中にユーザが１つの無線接続ネットワークから他の無線接続ネットワークに移動することを可能にする。さらに、方法は、既存の無線接続ネットワークに影響を及ぼすことなく、したがって、既存の無線接続ネットワークシステムの変更なしに具現されることができる。

また、方法は、ハンドオーバー用意段階を最小化する。しかも、さらに高い世代からのハンドオーバー（ＨＯ）、例えば、４世代無線接続ネットワークからさらに低い世代無線接続ネットワーク、例えば、３世代無線接続ネットワークへのハンドオーバーは、サービス品質に対する影響なしに容易に実行される。

さらに、方法は、パケット交換（ＰＳ）ネットワークだけを支援する無線接続ネットワークから回線交換（ＣＳ）及び／またはＰＳを支援する他の無線接続ネットワークへのハンドオーバー（ＨＯ）中に効率的な互換性を提供する。さらに、ハンドオーバープロセス（ＨＯ ｐｒｏｃｅｓｓ）中に、方法は、ボイス及びビデオベアラーを効果的に管理する。方法は、ターゲットセルによって管理されることができるベアラーのリストをあらかじめ識別する。したがって、ハンドオーバープロセスの全体オーバーヘッドは、効果的に減少し、これは、無線接続ネットワークの効率を増加させる。

方法は、コアネットワークエレメント（ｃｏｒｅ ｎｅｔｗｏｒｋ ｅｌｅｍｅｎｔ）（例えば、ＭＭＥまたはＳＧＳＮ）がターゲットセル能力に対する十分な情報を持って更新されるので、不要なシグナリングを避ける。したがって、コアネットワークエレメントは、映像通話の処理と関連した正確な決定をすることができる。

上記明細書で、本発明及びその長所は、例示的実施例を参照して説明された。しかし、以下の請求項に開示されたような本発明の範囲を逸脱することなく多様に変更または変形を行うことができることが本技術分野の通常の技術を有する者に明らかになる。したがって、明細書及び図面は、限定的な意味よりは、本発明の説明のための例として見なされなければならない。このようなすべての可能な変形は、本発明の範囲内に含まれるように意図された。

本発明の例示的実施例は、ここで説明された技術を具現するためのコンピュータシステムの使用に関するものである。一実施例において、この技術は、メモリ内に含まれた情報を使用してプロセッサによって実行される。このような情報は、格納装置とともに機械読み取り可能な媒体（ｍａｃｈｉｎｅ−ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）からメインメモリ内に読み込まれることができる。メモリに含まれた情報は、プロセッサが本発明で説明された方法を実効するように作動させる。

ここで使用される“機械読み取り可能な媒体”という用語は、機械を特定方式で作動させるデータを提供するのに参加する任意の媒体を示す。コンピュータシステムを使用して具現される例示的実施例において、多様な機械読み取り可能な媒体が、例えば、実行のためにプロセッサに情報を提供するのに含まれる。機械読み取り可能な媒体は、格納媒体であることができる。格納媒体は、非揮発性媒体と揮発性媒体を含む。非揮発性媒体は、例えば、サーバー格納ユニットのように、光学または磁気ディスクを含む。揮発性媒体は、動的なメモリを含む。すべてのこのような媒体は、媒体によって伝達される情報が機械内に情報を読み込む物理的メカニズムによって検出され得るように有形（ｔａｎｇｉｂｌｅ）でなければならない。

機械読み取り可能な媒体の一般的な形態は、例えば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、または任意の他の磁気媒体、ＣＤ−ＲＯＭ、任意の他の光学媒体、パンチカード、ペーパーテープ、孔のパターンを有する任意の他の物理的媒体、ＲＡＭ、ＰＲＯＭ、及びＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、任意の他のメモリチップ、またはカードリッジを含む。

１つの例示的実施例において、機械読み取り可能な媒体は、バスを含む線を含む同軸ケーブル、銅線、及び光ファイバを含む伝送媒体であることができる。また、伝送媒体は、電波及び赤外線通信時に発生するもののような音波または光波形態であることができる。機械読み取り可能な媒体の例は、搬送波（ｃａｒｒｉｅｒ ｗａｖｅ）、またはコンピュータで読み取り可能な、例えば、オンラインソフトウェア、ダウンロードリンク、設置リンク及びオンラインリンクなどの任意の他の媒体を含むことができるが、これらに限定されない。

付録（ＡＰＰＥＮＤＩＸ）
表１は、ＴＳ ３６．４１３［６］のようにハンドオーバー要求された（Ｈａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄ）メッセージからビデオＳＲＶＣＣハンドオーバー指示に関する表である。

表２は、ＴＳ ２５．４１３［８］のように位置再設定要求された（Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ）メッセージからビデオＳＲＶＣＣハンドオーバー指示に関する表である。

ＰＳ→ＣＳ要請メッセージは、表３に表示される。

表４は、ＴＳ ２３．４０１［１］のようなＰＧＷコンテキストに関する表である。

表５は、３ＧＰＰ ＴＳ ２９．２７４［５］のようなベアラー要請形成（Ｃｒｅａｔｅ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ）メッセージ内のベアラーコンテキストに関する表である。

表６は、ＴＳ ２３．４０１［］のようなＳＧＷコンテキストに関する表である。

表７は、ＴＳ ３６．４１３［６］のようなＥ−ＲＡＢ設定要請メッセージに関する表である。

表８は、ＴＳ ２３．４０１［１］のようなＭＭＥ ＭＭ及びＥＰＳベアラーコンテキストに関する表である。

表９は、ＴＳ ３６．４１３［６］のようなＥ−ＲＡＢ設定応答メッセージに関する表である。

表１０は、３ＧＰＰ ＴＳ ２９．２７４［５］のようなベアラー要請生成（Ｃｒｅａｔｅ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅ）メッセージ内でベアラーコンテキストに関する表である。

表１１は、ＴＳ ２９．２８０［７］のようなＳＲＶＣＣＰＳ→ＣＳ応答メッセージに関する表である。

表１２は、３ＧＰＰ ＴＳ ２４．００８のようなＭＳネットワーク能力情報エレメントに関する表である。

表１３は、３ＧＰＰ ＴＳ ２４．３０１のようなＵＥネットワーク能力情報エレメントに関する表である。

表１４は、ビデオＳＲＶＣＣ能力を伝達するための新しい情報エレメント（ＩＥ）に関する表である。

本発明は、特定の例示的実施例を参照して図示され説明されたが、本技術分野の通常の技術を有する者は、添付の請求項及びそれらの均等物によって限定されるような本発明の思想と範囲を逸脱することなく、多様に変更または変形されることができることを理解することができる。

Claims (28)

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. 前記第１網は、Ｅ−ＵＴＲＡＮ通信網であり、前記第２網は、ＵＭＴＳ通信網であることを特徴とする請求項１５記載の端末。
27. 前記含まれた指示子は、ｖＳＲＶＣＣ指示子であることを特徴とする請求項１記載のネットワークベアラーの管理方法。
28. 前記含まれた指示子は、ｖＳＲＶＣＣ指示子であることを特徴とする請求項１５記載のＰＤＮゲートウェイ。

Images