(57)【要約】  本発明の例示的な実施形態によれば、ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストを含む情報を受け取り、この情報に基づいて、ソースネットワークにおいて、少なくとも１つのベアラを少なくとも１つのパケットデータプロトコルコンテキストにマッピングするための方法、実行可能コンピュータプログラム、及び装置が存在する。また、本発明の別の例示的な実施形態によれば、少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた少なくとも１つのベアラの指示を含む情報を受け取り、受け取った情報をハンドオーバで使用するために記憶するための方法、実行可能コンピュータプログラム、及び装置が存在する。【選択図】図８Ａ
2011504035.tif 000002
【特許請求の範囲】
【請求項１】
ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストを含む情報を受け取るステップと、
前記情報に基づいて、ソースネットワークにおいて、少なくとも１つのベアラを前記少なくとも１つのパケットデータプロトコルコンテキストにマッピングするステップと、
を含むことを特徴とする方法。
【請求項２】
前記少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた前記少なくとも１つのベアラの指示と、対応する保証ビットレート及びトラフィックフローテンプレートの少なくとも一方とを含む情報をユーザ装置へ送信するステップをさらに含む、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記マッピングされた少なくとも１つのベアラのための対応するパケットデータプロトコルコンテキストのサービス品質を含む情報をユーザ装置へ送信するステップをさらに含む、
ことを特徴とする請求項１又は２のいずれか１項に記載の方法。
【請求項４】
前記少なくとも１つのベアラが、システムアーキテクチャエボリューションのデフォルトベアラ又はシステムアーキテクチャエボリューションの専用ベアラの一方であり、前記少なくとも１つのパケットデータプロトコルコンテキストが、第１のパケットデータプロトコルコンテキスト又は第２のパケットデータプロトコルコンテキストの一方である、
ことを特徴とする請求項１又は請求項２のいずれか１項に記載の方法。
【請求項５】
前記ユーザ装置のための少なくとも１つのサポートされるパケットデータプロトコルコンテキストの指示を含む情報をターゲットネットワーク装置へ送信するステップをさらに含む、
ことを特徴とする請求項２に記載の方法。
【請求項６】
前記マッピングが前記ソースネットワークのモビリティ管理エンティティ上で行われ、前記ソースネットワークがロングタームエボリューションネットワークであり、前記ターゲットネットワークが汎用パケット無線サービスネットワークである、
ことを特徴とする請求項１又は請求項２のいずれか１項に記載の方法。
【請求項７】
ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストを含む情報を受け取るステップと、
前記情報に基づいて、ソースネットワークにおいて、少なくとも１つのベアラを前記少なくとも１つのパケットデータプロトコルコンテキストにマッピングするステップと、
を含む動作を実行すべくプロセッサにより実行可能なコンピュータプログラムで符号化されたコンピュータ可読媒体。
【請求項８】
前記少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた前記少なくとも１つのベアラの指示と、対応する保証ビットレート及びトラフィックフローテンプレートの少なくとも一方とを含む情報をユーザ装置へ送信するステップをさらに含む、
ことを特徴とする請求項７に記載のコンピュータプログラムで符号化されたコンピュータ可読媒体。
【請求項９】
前記マッピングされた少なくとも１つのベアラのための対応するパケットデータプロトコルコンテキストのサービス品質を含む情報をユーザ装置へ送信するステップをさらに含む、
ことを特徴とする請求項７又は請求項８のいずれか１項に記載のコンピュータプログラムで符号化されたコンピュータ可読媒体。
【請求項１０】
ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストを含む情報を受け取るように構成された受信機と、
前記情報に基づいて、ソースネットワークにおいて、少なくとも１つのベアラを前記少なくとも１つのパケットデータプロトコルコンテキストにマッピングするように構成されたプロセッサと、
を備えることを特徴とする装置。
【請求項１１】
前記少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた前記少なくとも１つのベアラの指示と、対応する保証ビットレート及びトラフィックフローテンプレートの少なくとも一方を含む情報をユーザ装置へ送信するように構成された送信機をさらに備える、
ことを特徴とする請求項１０に記載の装置。
【請求項１２】
前記マッピングされた少なくとも１つのベアラのための対応するパケットデータプロトコルコンテキストのサービス品質を含む情報をユーザ装置へ送信するように構成された送信機をさらに備える、
ことを特徴とする請求項１０又は請求１１のいずれか１項に記載の装置。
【請求項１３】
前記少なくとも１つのベアラが、システムアーキテクチャエボリューションのデフォルトベアラ又はシステムアーキテクチャエボリューションの専用ベアラの一方であり、前記少なくとも１つのパケットデータプロトコルコンテキストが、第１のパケットデータプロトコルコンテキスト又は第２のパケットデータプロトコルコンテキストの一方である、
ことを特徴とする請求項１０又は請求項１１のいずれか１項に記載の装置。
【請求項１４】
前記送信機が、前記ユーザ装置のための少なくとも１つのサポートされるパケットデータプロトコルコンテキストの指示を含む情報をターゲットネットワーク装置へ送信するようにさらに構成された、
ことを特徴とする請求項１１に記載の装置。
【請求項１５】
前記装置が前記ソースネットワークのモビリティ管理エンティティにおいて具体化され、前記ソースネットワークがロングタームエボリューションネットワークであり、前記ターゲットネットワークが汎用パケット無線サービスネットワークである、
ことを特徴とする請求項１０又は請求項１１のいずれか１項に記載の装置。
【請求項１６】
ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストを含む情報を受け取るための手段と、
前記情報に基づいて、ソースネットワークにおいて、少なくとも１つのベアラを前記少なくとも１つのパケットデータプロトコルコンテキストにマッピングするための手段と、
を備えることを特徴とする装置。
【請求項１７】
前記少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた前記少なくとも１つのベアラの指示と、対応する保証ビットレート及びトラフィックフローテンプレートの少なくとも一方とを含む情報をユーザ装置へ送信するための手段をさらに備える、
ことを特徴とする請求項１６に記載の装置。
【請求項１８】
前記マッピングされた少なくとも１つのベアラのための対応するパケットデータプロトコルコンテキストのサービス品質を含む情報をユーザ装置へ送信するための手段をさらに備える、
ことを特徴とする請求項１６又は請求項１７のいずれか１項に記載の装置。
【請求項１９】
ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた少なくとも１つのベアラの指示を含む情報をソースネットワーク装置から受け取るステップと、
前記受け取った情報をハンドオーバで使用するために記憶するステップと、
を含むことを特徴とする方法。
【請求項２０】
前記受け取った情報が、対応する保証ビットレート及びトラフィックフローテンプレートの少なくとも一方をさらに含む、
ことを特徴とする請求項１９に記載の方法。
【請求項２１】
ネットワーク装置からハンドオーバ手順の指示を受け取るステップと、
前記ハンドオーバ指示の受け取りに応答して、前記サポートされるマッピングを含む情報を前記ネットワーク装置へ送信するステップと、
を含むことを特徴とする請求項１９又は請求項２０のいずれか１項に記載の方法。
【請求項２２】
前記少なくとも１つのベアラが、システムアーキテクチャエボリューションのデフォルトベアラ又はシステムアーキテクチャエボリューションの専用ベアラの一方であり、前記少なくとも１つのパケットデータプロトコルコンテキストが、第１のパケットデータプロトコルコンテキスト又は第２のパケットデータプロトコルコンテキストの一方である、
ことを特徴とする請求項１９又は請求項２０のいずれか１項に記載の方法。
【請求項２３】
ユーザ装置により実行される方法であって、前記ハンドオーバが、ロングタームエボリューションネットワークから汎用パケット無線サービスネットワークへ行われる、
ことを特徴とする請求項１９又は請求項２０のいずれか１項に記載の方法。
【請求項２４】
ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた少なくとも１つのベアラの指示を含む情報をソースネットワーク装置から受け取るように構成された受信機と、
前記受け取った情報をハンドオーバで使用するために記憶するように構成されたプロセッサ及びメモリと、
を備えることを特徴とする装置。
【請求項２５】
前記受け取った情報が、対応する保証ビットレート及びトラフィックフローテンプレートの少なくとも一方をさらに含む、
ことを特徴とする請求項２４に記載の装置。
【請求項２６】
ネットワーク装置からハンドオーバ手順の指示を受け取るように構成された受信機と、
前記ハンドオーバ指示の受け取りに応答して、前記サポートされるマッピングを含む情報を前記ネットワーク装置へ送信するように構成された送信機と、
を備えることを特徴とする請求項２４又は請求項２５のいずれか１項に記載の装置。
【請求項２７】
前記少なくとも１つのベアラが、システムアーキテクチャエボリューションのデフォルトベアラ又はシステムアーキテクチャエボリューションの専用ベアラの一方であり、前記少なくとも１つのパケットデータプロトコルコンテキストが、第１のパケットデータプロトコルコンテキスト又は第２のパケットデータプロトコルコンテキストの一方である、
ことを特徴とする請求項２４又は請求項２５のいずれか１項に記載の装置。
【請求項２８】
ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた少なくとも１つのベアラの指示を含む情報をソースネットワーク装置から受け取るための手段と、
前記受け取った情報をハンドオーバで使用するために記憶するための手段と、
を備えることを特徴とする装置。
【請求項２９】
前記少なくとも１つのベアラが、進化型パケットシステムベアラ又はシステムアーキテクチャエボリューションベアラの一方であり、前記少なくとも１つのパケットデータプロトコルコンテキストが、第１のパケットデータプロトコルコンテキスト又は第２のパケットデータプロトコルコンテキストの一方である、
ことを特徴とする請求項２８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書の教示は、一般に、ＬＴＥと３Ｇ／２Ｇネットワークとの間などの異なる無線アクセスネットワーク間におけるユーザ装置のハンドオーバに関し、特に、ハンドオーバ全体を通じてサービス品質要件を完全にサポートすることを対象とする。
【背景技術】
【０００２】
本節は、特許請求の範囲に記載する本発明に至るまでの背景又は状況を示すことを目的とする。本明細書における説明は、追求できる概念を含むことができるが、この概念が必ずしも以前に考案又は追求されたものであるとは限らない。したがって、本節で説明する内容は、本明細書において特に示さない限り、本出願における説明及び特許請求の範囲にとっての先行技術ではなく、本節に含まれることにより先行技術であると認められるものではない。
【０００３】
本明細書では以下の略語及び用語を定義する。
３ＧＰＰ  第３世代パートナーシッププロジェクト
ＤＬ  ダウンリンク
ＥＰＳ  進化型パケットシステム
Ｅ−ＵＴＲＡＮ  次世代ＵＴＲＡＮ
ＧＢＲ  保証ビットレート
ＧＰＲＳ  汎用パケット無線サービス
ＨＯ  ハンドオーバ
ＩＥ  情報要素
ＩＲＡＴ  無線間アクセス技術
ＩＳＨＯ  システム間ハンドオーバ
ＬＴＥ  ３ＧＰＰのロングタームエボリューション（Ｅ−ＵＴＲＡＮ、３．９Ｇ、又はＳＡＥとも呼ばれる）
ＭＭＥ  モビリティ管理エンティティ
Ｎｏｄｅ  Ｂ  基地局又は同様のネットワークアクセスノード
ＰＣＲＦ  ポリシ及び課金ルール機能
ＰＤＰ  パケットデータプロトコル
ＱＣＩ  ＱｏＳクラス識別子
ＱｏＳ  サービス品質
ＲＡＮ  無線アクセスノード
ＲＴＳＰ  リアルタイムストリーミングプロトコル
ＳＡＥ  システムアーキテクチャエボリューション
ＳＤＰ  セッション記述プロトコル
ＳＧＳＮ  サービングＧＰＲＳサポートノード
ＳＩＰ  セッション開始プロトコル
ＴＥＩＤ  トンネルエンドポイント識別子
ＴＦＴ  トラフィックフローテンプレート
ＵＥ  ユーザ装置（例えば、移動装置／局）
ＵＬ  アップリンク
ＵＭＴＳ  ユニバーサル移動体電気通信システム
ＵＰＥ  ユーザプレーンエンティティ（例えば、ＬＴＥアンカーと３ＧＰＰアンカーとの組み合わせ）
ＵＴＲＡＮ  ＵＭＴＳ地上無線アクセスネットワーク
【０００４】
３ＧＰＰは、無線アクセス技術のロングタームエボリューション（ＬＴＥ）を規格化しており、これは、レイテンシの短縮、より高いユーザデータ転送率、システム容量及び受信範囲の改善、及び通信事業者のコスト削減の達成を目的とする。３ＧＰＰ  ＴＳ２３．４０１：Ｅ−ＵＴＲＡＮアクセスのためのＧＰＲＳ強化（リリース８）バージョン１．３．０（２００７年１０月）の図４．２．１−１を同様に再現した図１Ａ、及び引用により本明細書に組み入れられる３ＧＰＰ  ＴＲ２３．８８２から抜粋した図１Ｂにシステムアーキテクチャの概観を示しており、これらの開示に関する態様は、図示のＬＴＥネットワークなどの第１の種類のネットワークと、図１Ａ及び図１ＢにＵＴＲＡＮ又はＧＥＲＡＮとして示す例えば２Ｇ又は３Ｇネットワークなどの異なる種類のネットワークとの間における（モバイル端末／移動局／ハンドセットなどの）ユーザ装置のハンドオーバに関する。これは、異なる無線アクセス技術ＲＡＴ又はシステム間のハンドオーバであるので、一般にＲＡＴ間又はシステム間ハンドオーバと呼ばれる。通常、異なるシステムは異なるトレードオフを含んで開発されてきたため、これらは異なるシステム内の基地局のような類似するノードが一連の異なる情報要件で動作するように動作することが多く、ネットワークノード及びユーザ機器のうちの異なるものには異なる情報が存在するので、ＲＡＴ間ハンドオーバは興味深いものである。
【０００５】
少なくともＬＴＥネットワークと２Ｇ／３Ｇネットワークとの間におけるようなこれらの不一致の１つにサービス品質（ＱｏＳ）サポートがある。ＳＡＥ／ＬＴＥでは、ＱｏＳは、ネットワーク制御及びネットワーク開始専用ベアラを使用して実施される。２Ｇ／３Ｇシステムでは、ＱｏＳは、モバイル端末によって制御されるパケットデータプロトコルＰＤＰコンテキストにより実施される。ＬＴＥは新しい３ＧＰＰシステムであり、今なお最終段階にあるため、ＬＴＥシステムと２Ｇ／３Ｇシステムとの間のハンドオーバに伴うＱｏＳ問題は今まで存在しておらず、発明者は、適切なＱｏＳサポートを伴うこのようなハンドオーバを実現できる先行技術におけるメカニズムを知らない。
【０００６】
３ＧＰＰ  ＴＳ２３．４０１：Ｅ−ＵＴＲＡＮアクセスのためのＧＰＲＳ強化（リリース８）バージョン１．３．０（２００７−１０）のセクション５．４〜５．５が本開示に関連する。本明細書で使用する場合、ベアラとは、３ＧＰＰ  ＴＲ２１．９０５  ｖ．８．２．０において（又はそれ以降のバージョンにおいて）定義されるように、定義済みの容量、遅延、又はビットエラーレートなどの情報伝達経路のことである。本明細書で使用するマルチ無線端末（略して端末又はＵＥ）とは、２Ｇ及び／又は３Ｇだけでなく、ＬＴＥアクセスネットワークにおいても使用できる端末のことである。このような端末は、例えば、ラップトップコンピュータ又は昨今の携帯電話のような特定のモバイルハンドセットのためのモデムとして使用されるネットワークカードであってもよい。
【０００７】
適切なハンドオーバのためには、端末が前のアクセスシステムへの接続を解除した場合、ターゲットアクセスシステムが、この端末のための完全なＱｏＳサポートを直ちに行うことが必要とされる。ＳＡＥ／ＬＴＥから３Ｇ／２Ｇへのシステム間ハンドオーバ中は、ＬＴＥネットワーク制御の専用ベアラが、３Ｇ／２Ｇ端末制御のＰＤＰコンテキストに変更又はマッピングされるものとする。これには、端末がソースＬＴＥアクセスネットワークから解放される前に、ターゲット３Ｇ／２Ｇアクセスネットワークにおいて第１のコンテキストだけでなく要求される第２のコンテキストも事前準備しておく必要がある。現行の３Ｇ／２Ｇシステムでは、端末が要求した場合にのみ第２のＰＤＰコンテキストが生成される。したがって、端末は常に第２のＰＤＰコンテキストを認識している。端末のハンドオーバにおいて、ターゲットアクセスシステムがＬＴＥシステムであり、前のアクセスシステムが３Ｇ／２Ｇアクセスシステムである場合、ハンドオーバされる端末が自身の第２のＰＤＰコンテキストを認識しているので、生成されるあらゆる専用ベアラが端末のＬＴＥネットワークに対する要求に応えることになる。しかしながら、このことは、ハンドオーバにおいてＱｏＳを適切にサポートするためにいくつかの問題を提起する。適切な専用ベアラを全ての必要な第２のコンテキストにマッピングできるように第２のコンテキストが生成されることをいかにして確実にするか。言換すれば、ＵＥがサポートしていないＰＤＰコンテキストを事前準備しないようにし、なおかつどのコンテキストがサポートされていないかを他の何らかの方法で端末に示すハンドオーバの準備段階で、ＵＥがサポートするＰＤＰコンテキストを全て事前準備することが重要である。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
当業では、上記の問題を解決するためにシステム間ハンドオーバのＱｏＳに対処する方法が必要とされている。
【課題を解決するための手段】
【０００９】
本発明の例示的な態様では、方法が、ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストを含む情報を受け取るステップと、この情報に基づいて、ソースネットワークにおいて、少なくとも１つのベアラを少なくとも１つのパケットデータプロトコルコンテキストにマッピングするステップとを含む。
【００１０】
本発明の別の例示的な態様では、プロセッサにより実行可能なコンピュータプログラムで符号化されたコンピュータ可読媒体が、ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストを含む情報を受け取るステップと、この情報に基づいて、ソースネットワークにおいて、少なくとも１つのベアラを少なくとも１つのパケットデータプロトコルコンテキストにマッピングするステップとを含む動作を実行する。
【００１１】
本発明の例示的な態様では、装置が、ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストを含む情報を受け取るように構成された受信機と、この情報に基づいて、ソースネットワークにおいて、少なくとも１つのベアラを少なくとも１つのパケットデータプロトコルコンテキストにマッピングするように構成されたプロセッサとを備える。
【００１２】
本発明の別の例示的な態様では、装置が、ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストを含む情報を受け取るための手段と、この情報に基づいて、ソースネットワークにおいて、少なくとも１つのベアラを少なくとも１つのパケットデータプロトコルコンテキストにマッピングするための手段とを備える。
【００１３】
本発明の上記の例示的な態様によれば、受け取り手段が受信機を含み、マッピング手段がプロセッサを含む。
【００１４】
本発明の例示的な態様では、方法が、ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた少なくとも１つのベアラの指示を含む情報をソースネットワーク装置から受け取るステップと、受け取った情報をハンドオーバで使用するために記憶するステップとを含む。
【００１５】
本発明のさらに別の例示的な態様では、装置が、ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた少なくとも１つのベアラの指示を含む情報をソースネットワーク装置から受け取るように構成された受信機と、受け取った情報をハンドオーバで使用するために記憶するように構成されたプロセッサ及びメモリとを備える。
【００１６】
本発明のさらに別の例示的な態様では、装置が、ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた少なくとも１つのベアラの指示を含む情報をソースネットワーク装置から受け取るための手段と、受け取った情報をハンドオーバで使用するために記憶するための手段とを備える。
【００１７】
本発明の上記の例示的な態様によれば、受け取り手段が受信機を含み、記憶手段がプロセッサ及びメモリを含む。
【００１８】
添付の図面と併せて以下の詳細な説明を読めば、本発明の実施形態の上述の及びその他の態様がより明らかになる。
【図面の簡単な説明】
【００１９】
【図１Ａ】３ＧＰＰ  ＴＳ２３．４０１の図４．２．１−１に類似する３ＧＰＰアクセスのための先行技術のアーキテクチャを示す図である。
【図１Ｂ】異なるアクセス技術を示すＬＴＥシステムアーキテクチャエボリューションの先行技術の概略図である（ＴＲ２３．８８２より抜粋）。
【図２】本発明の実施形態による特定のシグナリングを含む３ＧＰＰ  ＴＳ２３．４０１（ｖ１．３．０）の図５．４．１−１に類似するシグナリング図である。
【図３】本発明の実施形態による特定のシグナリングを含む３ＧＰＰ  ＴＳ２３．４０１（ｖ１．３．０）の図５．４．２−１に類似するシグナリング図である。
【図４】本発明の実施形態による特定のシグナリングを含む３ＧＰＰ  ＴＳ２３．４０１（ｖ１．３．０）の図５．５．２．１−１に類似するシグナリング図である。
【図５Ａ】本発明の実施形態による特定のシグナリングを含む３ＧＰＰ  ＴＳ２３．４０１（ｖ１．３．０）の図５．５．２．１−２に類似するシグナリング図である。
【図５Ｂ】本発明の実施形態による特定のシグナリングを含む３ＧＰＰ  ＴＳ２３．４０１（ｖ１．３．０）の図５．５．２．１−２に類似するシグナリング図である。
【図６】本発明の実施形態による特定のシグナリングを含む３ＧＰＰ  ＴＳ２３．４０１（ｖ１．３．０）の図５．５．２．２−１に類似するシグナリング図である。
【図７Ａ】本発明の実施形態による特定のシグナリングを含む３ＧＰＰ  ＴＳ２３．４０１（ｖ１．３．０）の図５．５．２．２−２に類似するシグナリング図である。
【図７Ｂ】本発明の実施形態による特定のシグナリングを含む３ＧＰＰ  ＴＳ２３．４０１（ｖ１．３．０）の図５．５．２．２−２に類似するシグナリング図である。
【図８Ａ】２Ｇ／３Ｇプロトコルによる端末の論理層の概略図である。
【図８Ｂ】ＬＴＥプロトコルによる端末の論理層の概略図である。
【図９】本発明の例示的な実施形態の実施における使用に適した様々な電子装置の簡略ブロック図である。
【発明を実施するための形態】
【００２０】
問題を正確に表現することにより、上述した問題点の解決へと近づく。ＬＴＥ内のＭＭＥがＭＭＥ内のマッピングルールに従って第２のＰＤＰコンテキストを事前準備する場合、モバイル端末がこれらの全てをサポートするわけではないとすると、いかにしてこの状況に対処するか。１つの可能性として、端末が要求される第２のコンテキストをサポートできるか否かが分からない状態で、ハンドオーバの準備段階においてＳＡＥベアラに基づいてＰＤＰコンテキストを生成することが挙げられる。ハンドオーバ後に、ネットワークが未使用のＰＤＰコンテキストを検出してこれらを非アクティブにすることができる。これらの開示は、サポートされないＰＤＰコンテキストのために事前予約されるこれらのネットワークリソースを無駄なものとして、さらに、サポートされないＰＤＰコンテキストを使用するあらゆるダウンリンクデータ［例えば、端末宛てではあるが、システム間ハンドオーバ中に（ＧＧＳＮなどの）ＵＰＥにおいて受け取られるＤＬパケット］の潜在的な損失に対処できないという理由でこのアプローチを却下している。別の考えられる解決策は、ソースＬＴＥネットワークが、サポートされているＰＤＰコンテキストを事前に認識し、システム間ハンドオーバ中にターゲットネットワークが、サポートされているＰＤＰコンテキストのためのリソースのみを設定するように要求できるようにすることである。これは、無線リソースを無駄にせずに問題に対処する、より理解できるアプローチと考えられる。これらの開示は、ＬＴＥアクセスの際に、端末がサポートするＰＤＰコンテキストに関する情報をＭＭＥへ送信する方法について詳述している。使用するようなシステムアーキテクチャエボリューション（ＳＡＥ）という用語は、進化型パケットシステム（ＥＰＳ）とみなすこともできる。したがって、これらの一方又は他方に対するあらゆる言及は、その言及に限定しているわけではない。
【００２１】
本発明の例示的な実施形態は、システム間（ＬＴＥ＜−＞２Ｇ／３Ｇ）ハンドオーバ中に、ＳＡＥ／ＥＰＳ  ＬＴＥベアラをＰＤＰコンテキストとの間でマッピングするための解決策を含む。これらの例示的な実施形態は、このようなハンドオーバのためのネットワーク並びに端末の両方に関する。重要なこととして、これらの例示的な実施形態は、ＵＥがサポートできない特定の第２のＰＤＰコンテキストをターゲット２Ｇ／３Ｇネットワーク内で確立しないようにする方法について詳述する。
【００２２】
ＬＴＥから２Ｇ／３Ｇへのシステム間ＨＯをサポートするためには、ＳＡＥベアラがＰＤＰコンテキストにマッピングを行う必要がある。また、２Ｇ／３ＧからＬＴＥへのシステム間ＨＯをサポートするためには、ＰＤＰコンテキストがＳＡＥベアラにマッピングを行う必要がある。１つのアプローチは、（単複の）ＳＡＥデフォルトベアラが第１のＰＤＰコンテキストにマッピングを行い、ＳＡＥ専用ベアラが第２のＰＤＰコンテキストにマッピングを行うことである。一般に、これらのシグナリング図のメッセージは、示すように順次的であり、以前に受け取ったメッセージ又は図示の機能ブロックに応じて自動的に送信される。
【００２３】
２Ｇ／３ＧアクセスシステムからＬＴＥアクセスシステムへのシステム間ハンドオーバの場合、１つの具体的な解決策は以下のとおりである。ＨＯ準備中にＳＧＳＮがＭＭＥへコンテキストを転送した後、ＭＭＥが、ＭＭＥ内のマッピングルールに従ってベアラを起動することができる。ＬＴＥから２Ｇ／３Ｇへのシステム間ＨＯの場合にはさらなる考慮が必要となる。本発明の実施形態によれば、ＭＭＥが、ＳＡＥベアラとＰＤＰコンテキストとの間のマッピングの生成に関与する。ＵＥの非アクセス層であるＮＡＳ層は、ＱｏＳ要求が存在することを知っており、対応するＵＬ  ＴＦＴからＳＡＥベアラへのマッピングを有する。しかしながら、リリース９９（Ｒ９９  ＱｏＳプロファイル要求メッセージ）によれば、ＵＥのＮＡＳ層は、このＱｏＳ要求の詳細は有していない。本発明の実施形態によれば、ＳＡＥベアラが設定されるときに、このＴＦＴのためにリソースが予約されている旨の通知、並びに対応する保証ビットレート情報がＳＡＥ／ＬＴＥネットワークからＵＥへ送信される。ＳＡＥ／ＬＴＥネットワークはまた、このベアラのための対応するＰＤＰコンテキストのＱｏＳに関する情報もＵＥに提供する。この情報は、ＵＥ内にローカルに記憶されるが、端末がＬＴＥにアクセスしている間は使用されない。この情報はベアラ固有のものであり、アプリケーション固有のものではないので、ＵＥのアプリケーション層がこれを直接使用することはできない。ＵＥがこの情報をＭＭＥと共有するには、１）ＳＡＥ専用ベアラ設定シグナリング中に、２）システム間ハンドオーバ前に、という２つの方法が考えられる。解決策１）では、ハンドオーバ前／中には、ＭＭＥが追加のシグナリングを伴わずにＵＥ内のＰＤＰコンテキストを認識しているので、異なる３ＧＰＰアクセス間のアイドルモードモビリティの場合に有利である。
【００２４】
次に上記のパート２）について検討する。ソースｅＮＢが、ＵＥに２Ｇ／３Ｇ下のセルを測定するように求めた場合、ＵＥは、サポートされる第２のＰＤＰコンテキストの情報を収集し、これをＮＡＳメッセージとして測定報告に含める。ＵＥ自体はコンテキストのマッピングを行なわない。代わりに、ＳＡＥベアラ設定シグナリング中に、ＭＭＥが、ＵＥのために交渉された対応するＲ９９  ＱｏＳプロファイルを提供する（ＬＴＥと２Ｇ／３Ｇとの間のＩＳＨＯに関しては、３ＧＰＰ  ＴＳ２３．４０１のセクション５．５．２を参照）。ＵＥは、自身が第２のＰＤＰコンテキストをサポートすることになる対象のＳＡＥベアラを選択し、これらのベアラに関してＭＭＥに通知する。或いは、ＵＥが、サポートされる第２のＰＤＰコンテキスト情報を測定報告に含めずに、これをＳＡＥベアラ設定中に異なるＮＡＳメッセージとしてＭＭＥへ直接送信する。端末間ＱｏＳ要求を行ったアプリケーションに対して専用ベアラが設定される場合、ベアラ設定中に端末／ＵＥが、端末／ＵＥがこのベアラに対して第２のＰＤＰコンテキストをサポートすることになる旨をＭＭＥに示す。端末／ＵＥが、割り当てられた専用ベアラをいずれの端末間ＱｏＳ要求にも結び付けることができない場合、端末／ＵＥは、２Ｇ／３Ｇセルへのシステム間ハンドオーバに関し、このＳＡＥベアラに対していずれの第２のＰＤＰコンテキストもサポートされていない旨をＭＭＥに通知する。ソースｅＮＢが２Ｇ／３Ｇセルへのシステム間ハンドオーバの実行を決定する場合、このサポートされるＰＤＰコンテキスト情報がＭＭＥへ転送される。サポートされるＰＤＰコンテキスト情報がＮＡＳメッセージを介して既に入手可能な場合、ＨＯ準備を開始するためのメッセージをｅＮＢがＭＭＥへ送信するときに、ＭＭＥは既にこの情報を有していることになる。
【００２５】
両解決策において、ＭＭＥは、これらの事前準備されたＰＤＰコンテキストをシステム間ハンドオーバの準備段階中にＳＧＳＮへ転送することができ、ＳＧＳＮはこれらを直ちに使用することになる。或いは、通信事業者のポリシに基づき、ＭＭＥがＰＤＰコンテキスト情報をさらに修正してこれをＳＧＳＮへ送信することができる。より詳細には、ＭＭＥが、ＰＤＰコンテキスト情報を通常の２Ｇから３Ｇへの又は３Ｇから２ＧへのＳＧＳＮ間ＨＯとしてＳＧＳＮへ送信する。ターゲットネットワークでは、ＳＧＳＮがＲＮＣに、要求されたＰＤＰコンテキストのために無線アクセスベアラを設定するように求める。ターゲットネットワーク内のリソース及び通信事業者ポリシによっては、確立されるＰＤＰコンテキストが、要求されたＰＤＰコンテキストと異なることがある。したがって、本発明の実施形態は、ターゲット２Ｇ／３Ｇ側でＨＯ準備が正常に行われた後に、ＭＭＥに事前準備されたＰＤＰコンテキストをｅＮＢ経由でＵＥへ付加的に送信させる。このＰＤＰコンテキスト情報は、ＮＡＳ  ＰＤＵとして、又はＭＭＥとｅＮＢとの間の、及びｅＮＢとＵＥとの間の制御インタフェースにおける情報要素として符号化されることになる。
【００２６】
この解決策は、システム間（ＬＴＥ＜−＞２Ｇ／３Ｇ）ハンドオーバを実行するための効率的な方法を提供するとともに、ＬＴＥ  ＱｏＳと２Ｇ／３Ｇ  ＱｏＳとの間のマッピングのための単純なルールを提供する。この解決策はまた、ＬＴＥから２Ｇ／３Ｇへのハンドオーバの際に、ＵＥが全ての事前準備された第２のＰＤＰコンテキストをサポートするわけではない場合のパケットの損失を防ぐ。この解決策をＬＴＥなどの無線標準規格に導入できることが期待されている。例えば、（ＬＴＥ）ハンドオーバ完了メッセージは、いずれのＰＤＰコンテキストが使用可能であるかを示す必要があり、この情報は（３ＧＰＰアンカーに類似する）ＧＧＳＮまで配信される必要がある。
【００２７】
図２〜図７は、３ＧＰＰ  ＴＳ２３．４０１  ｖ１．３．０（２００７年１０月）に基づいて適用される様々なシナリオに関するシグナリング図を示している。上記の図面の簡単な説明においてＴＳ２３．４０１への具体的な相互参照を見出すことができる。特に、太字テキストは、本出願時点におけるＴＳ２３．４０１のバージョンに記載されたシグナリングとは異なる本発明の実施形態によるシグナリングを示している。参照番号は、番号について詳述する図に対してのみ固有のものである。
【００２８】
図２：専用ベアラの起動手順、アクティブモードのＵＥ
本発明の態様によれば、ＴＳ２３．４０１セクション５．４．１のセッション管理、ＱｏＳ、及びＰＣＣ機能との相互作用を下記の太字テキストにより修正した結果、図２を参照しながら以下のように読める。
注意：ステップ３〜８は、ＧＴＰベースのＳ５／Ｓ８及びＰＭＩＰベースのＳ５／Ｓ８によるアーキテクチャの変形例に共通する。ＰＭＩＰベースのＳ５／Ｓ８の場合、３ＧＰＰ  ＴＳ２３．４０２［２］において手順ステップ（Ａ）及び（Ｂ）が定義される。ステップ１、２、９、及び１０はＧＴＰベースのＳ５／Ｓ８に関連する。
１．動的ＰＣＣが導入される場合、ＰＣＲＦがＰＣＣ決定提供（ＱｏＳポリシ）メッセージをＰＤＮ  ＧＷへ送信する。動的ＰＣＣが導入されない場合、ＰＤＮ  ＧＷがローカルＱｏＳポリシを適用することができる。
２．ＰＤＮ  ＧＷは、このＱｏＳポリシを使用してベアラＱｏＳを割り当て、すなわち、ベアラレベルＱｏＳパラメータ（ＡＭＢＲを除く）に値を割り当てる（条項４．７．２を参照）。ＰＤＮ  ＧＷは、専用ベアラ生成要求メッセージ（ＰＴＩ、ベアラＱｏＳ、ＵＬ  ＴＦＴ、Ｓ５／Ｓ８ＴＥＩＤ、ＬＢＩ）をサービングＧＷへ送信し、この場合リンク済みＥＰＳベアラ識別情報（ＬＢＩ）とは、デフォルトベアラのＥＰＳベアラ識別情報のことである。プロシージャトランザクションＩｄ（ＰＴＩ）パラメータは、手順がＵＥ要求によるベアラリソース割り当て手順によって開始されたときにのみ使用される（条項５．４．５を参照）。
３．サービングＧＷは、専用ベアラ生成要求（ＰＴＩ、ベアラＱｏＳ、ＵＬ  ＴＦＴ、Ｓ１−ＴＥＩＤ、ＬＢＩ）メッセージをＭＭＥへ送信する。
４．ＭＭＥは、未だＵＥに割り当てられていないＥＰＳベアラ識別情報を選択する。次に、ＭＭＥが、ＰＴＩ、ＵＬ  ＴＦＴ、ＥＰＳベアラ識別子、及びリンク済みＥＰＳベアラ識別情報（ＬＢＩ）を含むセッション管理構成ＩＥを構築する。ＵＥがＵＴＲＡＮ又はＧＥＲＡＮ機能を有する場合、ＭＭＥは、ＥＰＳベアラＱｏＳ情報を使用して、対応するＰＤＰコンテキストパラメータであるＱｏＳ交渉済み（Ｒ９９のＱｏＳプロファイル）、無線プライオリティ、及びパケットフローＩｄを取り出して、これらをセッション管理構成に含める。ＵＥが、ＵＥネットワーク機能において、ＢＳＳパケットフロー手順をサポートしないことを示した場合、ＭＭＥはパケットフローＩｄを含めるべきではない。次に、ＭＭＥは、ベアラ設定要求（ベアラＱｏＳ、セッション管理構成、Ｓ１−ＴＥＩＤ）メッセージをｅＮｏｄｅＢへシグナリングする。
５．ｅＮｏｄｅＢは、ベアラＱｏＳを無線ベアラＱｏＳにマッピングする。次に、ｅＮｏｄｅＢが、無線ベアラ設定要求（無線ベアラＱｏＳ、セッション管理構成、ＥＰＳ  ＲＢ識別情報）メッセージをＵＥへシグナリングする。ＵＥは、セッション管理構成内で受け取ったＱｏＳ交渉済み、無線プライオリティ、及びパケットフローＩｄを、ＧＥＲＡＮ又はＵＴＲＡＮを介したアクセス時に使用するために記憶する。ＵＥ  ＮＡＳは、ＥＰＳベアラ識別情報を記憶し、リンク済みＥＰＳベアラ識別子（ＬＢＩ）によって示されるデフォルトベアラに専用ベアラをリンクする。ＵＥは、アップリンクパケットフィルタ（ＵＬ  ＴＦＴ）を使用して、サービスデータフローの無線ベアラへのマッピングを決定する。
注意：無線ベアラＱｏＳの詳細はＲＡＮ２により規定される。
６．ＵＥ  ＮＡＳ層は、ＥＰＳベアラ識別情報を含むセッション管理応答ＩＥを構築する。ＵＥが２Ｇ／３Ｇ対応の場合、ＵＥはまた、自身がその専用ＥＰＳベアラに対応する第２のＰＤＰコンテキストをサポートできるかどうかもチェックする。第２のＰＤＰコンテキストサポートの指示は、セッション管理応答ＩＥ内に含まれる。次に、ＵＥは、無線ベアラの起動を無線ベアラ設定応答（セッション管理応答）メッセージでｅＮｏｄｅＢに確認応答する。
７．ｅＮｏｄｅＢは、ベアラの起動をベアラ設定応答（ＥＰＳベアラ識別情報、Ｓ１−ＴＥＩＤ、セッション管理応答）メッセージでＭＭＥに確認応答する。ｅＮｏｄｅＢは、要求されたベアラＱｏＳを割り当てることができるか否かを示す。
８．ＭＭＥは、専用ベアラ生成応答（ＥＰＳベアラ識別子、Ｓ１−ＴＥＩＤ）メッセージを送信することにより、ベアラの起動をサービングＧＷに確認応答する。ＭＭＥは、この専用ＥＰＳベアラのために第２のＰＤＰコンテキストがサポートされているかどうかについての情報を記憶する。この情報は、２Ｇ／３Ｇネットワークへのシステム間ハンドオーバの場合にのみ使用される。
９．サービングＧＷは、専用ベアラ生成応答（ＥＰＳベアラ識別子、Ｓ５／Ｓ８−ＴＥＩＤ）メッセージを送信することにより、ベアラの起動をＰＤＮ  ＧＷに確認応答する。
１０．専用ベアラの起動手順がＰＣＲＦからのＰＣＣ決定提供メッセージによってトリガされていた場合、ＰＤＮ  ＧＷが、提供ＡＣＫメッセージを送信することにより、要求されたＰＣＣ決定（ＱｏＳポリシ）を実行できるか否かをＰＣＲＦに示す。
注意：（ローカルブレークアウトの場合などの）ステップ１及び１０の正確なシグナリングは本明細書の範囲外である。このシグナリング及び専用ベアラの起動手順との相互作用については、３ＧＰＰ  ＴＳ２３．２０３［６］で規定されるものとする。ステップ１及び１０は、完全性を期す目的でのみ含めたものである。
【００２９】
図３：ベアラＱｏＳ更新による専用ベアラ修正手順、アクティブモードのＵＥ
本発明の態様によれば、ＴＳ２３．４０１セクション５．４．２のベアラＱｏＳ更新による専用ベアラの修正を下記の太字テキストにより修正した結果、図３を参照しながら以下のように読める。
注意：ステップ３〜８は、ＧＴＰベースのＳ５／Ｓ８及びＰＭＩＰベースのＳ５／Ｓ８によるアーキテクチャの変形例に共通する。ＰＭＩＰベースのＳ５／Ｓ８の場合、３ＧＰＰ  ＴＳ２３．４０２［２］において手順ステップ（Ａ）及び（Ｂ）が定義される。ステップ１、２、９、及び１０は、ＧＴＰベースのＳ５／Ｓ８に関連する。
１．動的ＰＣＣが導入されない場合、ＰＣＲＦがＰＣＣ決定提供（ＱｏＳポリシ）メッセージをＰＤＮ  ＧＷへ送信する。動的ＰＣＣが導入されない場合、ＰＤＮ  ＧＷがローカルＱｏＳポリシを適用することができる。
２．ＰＤＮ  ＧＷは、このＱｏＳポリシを使用して、サービスデータフローをアクティブな専用ベアラに集約すべきか、或いはここから削除すべきかを判定する。ＰＤＮ  ＧＷは、ＵＬ  ＴＦＴを生成して、集約したサービスデータフローセットにマッチするようにベアラＱｏＳを更新する。次に、ＰＤＮ  ＧＷは、専用ベアラ更新要求（ＰＴＩ、ＥＰＳベアラ識別子、ベアラＱｏＳ、ＵＬ  ＴＦＴ）メッセージをサービングＧＷへ送信する。プロシージャトランザクションＩｄ（ＰＴＩ）パラメータは、手順がＵＥ要求によるベアラリソース割り当て手順によって開始されたときにのみ使用される（条項５．４．５を参照）。
３．サービングＧＷは、専用ベアラ更新要求（ＥＰＳベアラ識別子、ベアラＱｏＳ、ＵＬ  ＴＦＴ）メッセージをＭＭＥへ送信する。
４．ＭＭＥは、ＵＬ  ＴＦＴ及びＥＰＳベアラ識別子を含むセッション管理構成ＩＥを構築する。ＵＥがＵＴＲＡＮ又はＧＥＲＡＮ機能を有する場合、ＭＭＥは、ＥＰＳベアラＱｏＳ情報を使用して、対応するＰＤＰコンテキストパラメータであるＱｏＳ交渉済み（Ｒ９９のＱｏＳプロファイル）、無線プライオリティ、及びパケットフローＩｄを取り出して、これらをセッション管理構成に含める。ＵＥが、ＵＥネットワーク機能において、ＢＳＳパケットフロー手順をサポートしないことを示した場合、ＭＭＥはパケットフローＩｄを含めるべきではない。次に、ＭＭＥは、ベアラ修正要求（ＥＰＳベアラ識別子、ベアラＱｏＳ、セッション管理構成）メッセージをｅＮｏｄｅＢへ送信する。
５．ｅＮｏｄｅＢは、修正したベアラＱｏＳを無線ベアラＱｏＳにマッピングする。次に、ｅＮｏｄｅＢが、無線ベアラ修正要求（無線ベアラＱｏＳ、セッション管理構成、ＥＰＳ  ＲＢ識別情報）メッセージをＵＥへシグナリングする。ＵＥは、セッション管理構成内で受け取ったＱｏＳ交渉済み、無線プライオリティ、及びパケットフローＩｄを、ＧＥＲＡＮ又はＵＴＲＡＮを介したアクセス時に使用するために記憶するものとする。ＵＥは、アップリンクパケットフィルタ（ＵＬ  ＴＦＴ）を使用して、サービスデータフローの無線ベアラへのマッピングを決定する。
注意：無線ベアラＱｏＳの詳細はＲＡＮ２により規定される。
６．ＵＥ  ＮＡＳ層は、ＥＰＳベアラ識別情報を含むセッション管理応答ＩＥを構築する。ＵＥが２Ｇ／３Ｇ対応の場合、ＵＥはまた、自身がその専用ＥＰＳベアラに対応する第２のＰＤＰコンテキストをサポートできるかどうかもチェックする。第２のＰＤＰコンテキストサポートの指示は、セッション管理応答ＩＥに含まれる。次に、ＵＥは、無線ベアラの修正を無線ベアラ修正応答（セッション管理応答）メッセージでｅＮｏｄｅＢに確認応答する。
７．ｅＮｏｄｅＢは、ベアラの修正をベアラ修正応答（ＥＰＳベアラ識別情報、セッション管理応答）メッセージでＭＭＥに確認応答する。このメッセージで、ｅＮｏｄｅＢは、要求されたベアラＱｏＳを割り当てることができるか否かを示す。
８．ＭＭＥは、専用ベアラ更新応答（ＥＰＳベアラ識別子）メッセージを送信することにより、ベアラの修正をサービングＧＷに確認応答する。ＭＭＥは、この専用ＥＰＳベアラのために第２のＰＤＰコンテキストがサポートされているかどうかについての情報を記憶する。この情報は、２Ｇ／３Ｇネットワークへのシステム間ハンドオーバの場合にのみ使用される。
９．サービングＧＷは、専用ベアラ更新応答（ＥＰＳベアラ識別子）メッセージを送信することにより、ベアラの修正をＰＤＮ  ＧＷに確認応答する。
１０．専用ベアラの修正手順がＰＣＲＦからのＰＣＣ決定提供メッセージによってトリガされていた場合、ＰＤＮ  ＧＷが、提供ＡＣＫメッセージを送信することにより、要求されたＰＣＣ決定（ＱｏＳポリシ）を実行できるか否かをＰＣＲＦに示す。
注意：（ローカルブレークアウトの場合などの）ステップ１及び１０の正確なシグナリングは本明細書の範囲外である。このシグナリング及び専用ベアラの起動手順との相互作用については、３ＧＰＰ  ＴＳ２３．２０３［６］で規定されるものとする。ステップ１及び１０は、完全性を期す目的でのみ含めたものである。
【００３０】
図４：Ｅ−ＵＴＲＡＮからＵＴＲＡＮ  ＩｕモードへのＲＡＴ間ＨＯ、準備段階
本発明の態様によれば、ＴＳ２３．４０１セクション５．５．２．１．２の準備段階を下記の太字テキストにより修正した結果、図４を参照しながら以下のように読める。
１．ソースｅＮｏｄｅＢが、ターゲットアクセスネットワークであるＵＴＲＡＮ  ＩｕモードへのＲＡＴ間ハンドオーバの開始を決定する。この時点で、アップリンク及びダウンリンクの両方のユーザデータが、ＵＥとソースｅＮｏｄｅＢとの間は（単複の）ベアラを介して、ソースｅＮｏｄｅＢ、サービングＧＷ、及びＰＤＮ  ＧＷの間は（単複の）ＧＴＰトンネルを介して送信される。（解決策２を使用する場合、ソースｅＮｏｄｅＢがＵＥに２Ｇ／３Ｇ下のセルを測定するように求めると、ＵＥは、サポートされている第２のＰＤＰコンテキストの情報を収集し、これをＮＡＳメッセージとして測定報告内に含める。その後、ＵＥは、ＮＡＳメッセージをＭＭＥへ送信する（ＮＡＳメッセージは、図５．５．２．１−１には図示していない）。
注意：ハンドオーバ決定に至る処理については、本明細書の範囲外である。
２．ソースｅＮｏｄｅＢは、要ハンドオーバ（原因、ターゲットＲＮＣ識別子、ソースｅＮｏｄｅＢ識別子、ソースからターゲットへの透明コンテナ、ベアラ要求データ転送リスト）メッセージをソースＭＭＥへ送信して、ＣＮにターゲットＲＮＣ、ターゲットＳＧＳＮ、及びサービングＧＷ内でリソースを確立するように要求する。
「ベアラ要求データ転送リスト」ＩＥは、ソースｅＮｏｄｅＢが、（直接的又は間接的）データ転送が必要であると判断した対象のベアラのリストを含む。
３．ソースＭＭＥは、「ターゲットＲＮＣ識別子」ＩＥから、ハンドオーバの種類がＵＴＲＡＮ  ＩｕモードへのＩＲＡＴハンドオーバであると判断する。ソースＭＭＥは、再配置転送要求（ＩＭＳＩ、ターゲット識別、ＭＭコンテキスト、ＰＤＰコンテキスト、ＰＤＰコンテキスト優先順位付け、コントロールプレーンのＭＭＥトンネルエンドポイント識別子、コントロールプレーンのＭＭＥアドレス、ソースからターゲットへの透明コンテナ、Ｓ１−ＡＰ原因直接転送フラグ）メッセージをターゲットＳＧＳＮへ送信することにより、ハンドオーバリソース割り当て手順を開始する。このメッセージは、ソースシステム内で確立されたベアラに対応する全てのＰＤＰコンテキスト、及びサービングＧＷのアップリンクのトンネルエンドポイントパラメータを含む。ＭＭＥは、端末がサポートするＰＤＰコンテキストのリストをＳＧＳＮへ送信する。サポートされていないＰＤＰコンテキストからのサービスデータフローが、関連するサポートされているＰＤＰコンテキストへ転送されるかどうかはＦＦＳである。
「直接転送フラグ」ＩＥは、ターゲット側へのデータ直接転送を使用すべきか否かを示す。このフラグはソースＭＭＥにより設定される。
ＭＭコンテキストは、３ＧＰＰ  ＴＳ２９．０６０［１４］に記載されるようなサポートされる暗号アルゴリズムなどのセキュリティ関連情報を含む。ＵＴＲＡＮセキュリティパラメータとＥＰＳセキュリティパラメータとの関係はＦＦＳである。
編集者注：これはリリース８のセキュリティ要件と整合させる必要がある。
４．ターゲットＳＧＳＮは、ＰＬＭＮの変更などによりサービングＧＷが再配置されるかどうかを判断する。サービングＧＷが再配置される場合、「ＧＷ選択機能」の条項で説明するように、ターゲットＳＧＳＮがターゲットサービングＧＷを選択する。ターゲットＳＧＳＮは、ＰＤＰコンテキスト生成要求メッセージ（ＩＭＳＩ、コントロールプレーンのＳＧＳＮトンネルエンドポイント識別子、コントロールプレーンのＳＧＳＮアドレス、ユーザプレーンの（単複の）ＰＤＮ  ＧＷアドレス、ユーザプレーンの（単複の）コントロールプレーンの（単複の）ＰＤＮ  ＧＷアドレス、及びコントロールプレーンの（単複の）ＰＤＮ  ＧＷ  ＴＥＩＤ）をターゲットサービングＧＷへ送信する。
４ａ．ターゲットサービングＧＷは、ＰＤＰコンテキスト生成応答（ユーザプレーンの（単複の）サービングＧＷのアドレス、ユーザプレーンのサービングＧＷの（単複の）ＵＬ  ＴＥＩＤ、間接転送の場合は、サービングＧＷの（単複の）ＤＬ  ＴＥＩＤ、サービングＧＷのコンテキストＩＤ）メッセージをターゲットＳＧＳＮへ戻す。
５．ターゲットＳＧＳＮは、再配置要求メッセージ（ＵＥ識別子、原因、ＣＮドメインインジケータ、完全性保護情報（すなわち、ＩＫ及び許容された完全性保護アルゴリズム）、暗号化情報（すなわち、ＣＫ及び許可された暗号アルゴリズム)、設定されるＲＡＢのリスト、ソースからターゲットへの透明コンテナ）を送信することにより、ターゲットＲＮＣに無線ネットワークリソース（ＲＡＢ）を確立するように要求する。
設定されるＲＡＢは、確立を要求される個々のＲＡＢごとに、ＲＡＢ  ＩＤ、ＲＡＢパラメータ、トランスポート層アドレス、及びＩｕトランスポートアソシエーションなどの情報を含むものとする。ターゲットＳＧＳＮは、ＰＤＰコンテキスト内の活動状況インジケータが、このＰＤＰコンテキストに関してソース側にアクティブな無線ベアラが存在しないことを示す場合にはリソースを要求すべきではない。ＲＡＢ  ＩＤ情報要素はＮＳＡＰＩ値を含み、ＲＡＢパラメータ情報要素はＱｏＳプロファイルを与える。トランスポート層アドレスはユーザデータのためのサービングＧＷのアドレスであり、Ｉｕトランスポートアソシエーションはアップリンクのトンネルエンドポイント識別子データに相当する。
暗号キー及び完全性保護キーをターゲットＲＮＣへ送信して、新規ＡＫＡ（認証及び鍵承諾）手順を必要とせずに、新しいＲＡＴ／モードのターゲットセルにおいてデータ転送を継続できるようにする。ターゲットＲＮＣ内のＲＲＣからＵＥへ（再配置コマンドメッセージの形で、又はハンドオーバ完了メッセージの後に）送信する必要がある情報は、ターゲットＲＮＣからＵＥへ透明コンテナを介して送信されるＲＲＣメッセージに含まれるものとする。
ターゲットＲＮＣにおいて、承諾済みＲＡＢのために無線及びＩｕユーザプレーンリソースが予約される。
５ａ．ターゲットＲＮＣは、リソースを割り当てるとともに、適用可能なパラメータを再配置要求確認応答メッセージ（ターゲットからソースへの透明コンテナ、ＲＡＢ設定リスト、ＲＡＢ設定失敗リスト）に含めてターゲットＳＧＳＮへ戻す。
再配置要求確認応答メッセージを送信すると、承諾済みＲＡＢのために、ターゲットＲＮＣにサービングＧＷからのダウンリンクＧＴＰ  ＰＤＵを受け取る準備が成されるものとする。
設定される個々のＲＡＢは、ユーザデータのためのターゲットＲＮＣのアドレスであるトランスポート層アドレス、及びユーザデータのダウンリンクトンネルエンドポイント識別子に相当するＩｕトランスポートアソシエーションにより定められる。
６．ターゲットＳＧＳＮは、ＰＤＰコンテキスト更新要求メッセージ（ＩＭＳＩ、交渉済みＱｏＳ、コントロールプレーンのＳＧＳＮトンネルエンドポイント識別子、コントロールプレーンのＳＧＳＮアドレス、ＤＬユーザプレーンのターゲットＲＮＣアドレス及び（単複の）ＴＥＩＤ）をターゲットサービングＧＷへ送信することができる。このメッセージは、ＳＧＷが変更された場合にターゲットＳＧＷへ送信される。
６ａ．（ターゲット）サービングＧＷは、ＰＤＰコンテキスト更新応答（原因）メッセージをターゲットＳＧＳＮへ戻す。
７．ターゲットＳＧＳＮは、再配置転送応答メッセージ（原因、コントロールプレーンのＳＧＳＮトンネルエンドポイント識別子、コントロールプレーンのＳＧＳＮアドレス、ターゲットからソースへの透明コンテナ、ＲＡＮＡＰ原因、ＲＡＢ設定情報、付加的ＲＡＢ設定情報、ユーザトラフィックデータ転送のための（単複の）アドレス及び（単複の）ＴＥＩＤ）をソースＭＭＥへ送信する。
「直接転送」が適用可能な場合、ＩＥ「ユーザトラフィックデータ転送のための（単複の）アドレス及び（単複の）ＴＥＩＤ」は、ターゲットＲＮＣへのＧＴＰ−Ｕトンネルエンドポイントパラメータを含む。それ以外の場合、ＩＥ「ユーザトラフィックデータ転送のための（単複の）アドレス及び（単複の）ＴＥＩＤ」は、サービングＧＷ（或いは、再配置の場合はターゲットサービングＧＷ）へのＧＴＰ−Ｕトンネルエンドポイントパラメータを含む。
８．「直接転送」が適用可能でない場合、ソースＭＭＥは、ベアラ生成要求メッセージ（原因、データ転送のための（単複の）アドレス及び（単複の）ＴＥＩＤ（ステップ７を参照）、（単複の）ＮＳＡＰＩ）を、間接的パケット転送に使用するサービングＧＷへ送信するものとする。原因は、ベアラがデータ転送の対象であることを示すものとする。
ＵＥのためのアンカーポイントとして使用されるサービングＧＷとは異なるサービングＧＷを介して間接転送を行うことができる。
８ａ．サービングＧＷは、ベアラ生成応答メッセージ（原因、データ転送のためのサービングＧＷの（単複の）アドレス及び（単複の）ＴＥＩＤ）を送信することにより転送パラメータを戻す。サービングＧＷがデータ転送をサポートしていない場合、適当な原因値が戻されて、サービングＧＷの（単複の）アドレス及び（単複の）ＴＥＩＤはメッセージに含まれなくなる。
【００３１】
図５：Ｅ−ＵＴＲＡＮからＵＴＲＡＮ  ＩｕモードへのＲＡＴ間ＨＯ、実行段階
本発明の態様によれば、ＴＳ２３．４０１セクション５．５．２．１．３の実行段階を下記の太字テキストにより修正した結果、図５を参照しながら以下のように読める。
注意：ＰＭＩＰベースのＳ５／Ｓ８の場合、手順ステップ（Ａ）は３ＧＰＰ  ＴＳ  ２３．４０２［２］において定められる。ステップ８及び８ａは、ＧＴＰベースのＳ５／Ｓ８に関連する。
ソースｅＮｏｄｅＢは、ダウンリンク及びアップリンクのユーザプレーンＰＤＵを受信し続ける。
１．ソースＭＭＥは、ハンドオーバコマンドメッセージ（ターゲットからソースへの透明コンテナ、データ転送対象ベアラのリスト）を送信することにより、ソースｅＮｏｄｅＢへ向けての準備段階を完了する。「データ転送対象ベアラのリスト」ＩＥをメッセージに含めることができ、これは、準備段階でターゲット側から受け取った「ユーザトラフィックデータ転送のための（単複の）アドレス及び（単複の）ＴＥＩＤ」のリスト（再配置転送応答メッセージ）であるものとする。
ソースｅＮｏｄｅＢは、「データ転送対象ベアラのリスト」内で特定されるベアラのためにデータ転送を開始する。データ転送は、ターゲットＲＮＣへ直接行うことができ、或いは、準備段階でソースＭＭＥ及び／又はターゲットＳＧＳＮにより決定された場合にはサービングＧＷを介して行うことができる。
２．ソースｅＮｏｄｅＢはＵＥに、Ｅ−ＵＴＲＡＮからのＨＯコマンドメッセージを介してターゲットアクセスネットワークにハンドオーバするように命令する。このメッセージに含まれる透明コンテナは、ターゲットＲＮＣが準備段階で設定した無線状態パラメータを含む。このＥ−ＵＴＲＡＮ固有のシグナリングの詳細は、３ＧＰＰ  ＴＳ３６．３００［５］に記載されている。
ハンドオーバコマンドメッセージを含むＥ−ＵＴＲＡＮからのＨＯコマンドメッセージを受け取ると、ＵＥは、ＮＳＡＰＩとの関係に基づいて、自身のベアラＩＤをそれぞれのＲＡＢに関連付け、ユーザプレーンデータのアップリンク送信を一時停止するものとする。
３．ソースｅＮｏｄｅＢは、ＳＲＮＳコンテキスト転送メッセージにおいて「配信順」パラメータに関してソースＭＭＥに通知を行い、その後ソースＭＭＥがこれをターゲットＳＧＳＮに通知する。ターゲットＳＧＳＮは、ＳＲＮＳコンテキストをターゲットＲＮＣへ転送する。
４．ＵＥは、ターゲットＵＴＲＡＮ  Ｉｕ（３Ｇ）システムへ移動し、ステップ２で送られたメッセージに含まれて提供されたパラメータに基づいてハンドオーバを実行する。手順は、３ＧＰＰ  ＴＳ４３．１２９［８］の従属条項５．２．２．２のステップ６及び８と同じものであるが、追加機能として、受け取ったＲＡＢと、特定のＮＳＡＰＩに関連する既存のベアラＩＤとの関連付けを含む。
ＵＥは、ターゲットＲＮＣ内に割り当てられた無線リソースが存在するこれらのＮＳＡＰＩのみに対してユーザデータ転送を再開することができる。
５．新規ソースＲＮＣ−ＩＤ＋Ｓ−ＲＮＴＩがＵＥと正常に交換されると、ターゲットＲＮＣは、ターゲットＳＧＳＮへ再配置完了メッセージを送信するものとする。再配置完了手順の目的は、ターゲットＲＮＣによりソースＥ−ＵＴＲＡＮの再配置の完了をＥＰＣに示すことである。再配置完了メッセージを受け取った後、ターゲットＳＧＳＮは、ターゲットＲＮＣからデータを受け取る準備をするものとする。ターゲットＳＧＳＮによって受け取られた個々のアップリンクＮ−ＰＤＵは、サービングＧＷへ直接転送される。
６．これでターゲットＳＧＳＮは、ＵＥがターゲット側に到着したことを認識し、ターゲットＳＧＳＮは、再配置転送完了メッセージを送信することによりソースＭＭＥに通知を行う。ソースＭＭＥもまた、この情報に確認応答を行う。（サービングＧＷの再配置の場合）ソースｅＮｏｄｅＢ及びソースサービングＧＷ内のリソースをいつ解放すべきかを管理するためにタイマを開始することができる（通常、これはソースＭＭＥがＨＳＳから配置キャンセルメッセージを受け取ったときに行われる）。ソースＭＭＥにおけるさらなる動作は、ステップ１３において継続する。
７．ここでターゲットＳＧＳＮは、今やＵＥが確立した全てのＰＤＰコンテキストにターゲットＳＧＳＮが関与することをサービングＧＷ（サービングＧＷ再配置の場合はターゲットサービングＧＷ）に通知することにより、ハンドオーバ手順を完了する。これは、ＰＤＰコンテキスト更新要求メッセージ（コントロールプレーンの（単複の）ＳＧＳＮトンネルエンドポイント識別子、（単複の）ＮＳＡＰＩ、コントロールプレーンの（単複の）ＳＧＳＮアドレス、ユーザトラフィックのための（単複の）ＳＧＳＮアドレス及び（単複の）ＴＥＩＤ又は（単複の）ＲＮＣアドレス及び（単複の）ＴＥＩＤ、及びＲＡＴタイプ）の形で行われる。
８．サービングＧＷ（サービングＧＷの再配置の場合はターゲットサービングＧＷ）は、ベアラ更新要求メッセージを送信することにより、例えばサービングＧＷの再配置、又は課金などに使用することができるＲＡＴタイプの変更を（単複の）ＰＤＮ  ＧＷに通知することができる。このメッセージは、ターゲットネットワーク及び端末により承諾されたＰＤＰコンテキストのＴＥＩＤ及びＮＳＡＰＩを含む。ＰＤＮ  ＧＷは、この要求にベアラ更新応答メッセージで確認応答しなければならない。ＰＤＮ  ＧＷは、アクティブなサービスデータフローを、ベアラ更新要求（ＮＳＡＰＩ、ＴＦＴ）内の現在のＰＤＰコンテキストセットにいかにしてマッピングするかを示すことができる。
９．サービングＧＷ（サービングＧＷ再配置の場合はターゲットサービングＧＷ）は、ＰＤＰコンテキスト更新応答メッセージ（原因、コントロールプレーンのサービングＧＷトンネルエンドポイント識別子、コントロールプレーンのサービングＧＷのアドレス、プロトコル構成オプション、及び各アクティブなＰＤＰコンテキストのＴＦＴ）を介して、ターゲットＳＧＳＮに対してユーザプレーンの切替を確認応答する。この段階で、ＵＥ、ターゲットＲＮＣ、サービングＧＷ（サービングＧＷ再配置の場合ターゲットサービングＧＷ）、及びＰＤＰ  ＧＷ間の全てのＰＤＰコンテキストに関してユーザプレーンパスが確立される。
ＵＬトラフィックを正しいＰＤＰコンテキストにマッピングするために、端末は内部的にマッピングを決定することができ、或いは端末にＰＤＮ  ＧＷのマッピングが与えられる。ＳＧＳＮがＴＦＴマッピングを端末にシグナリングすべき場合、新規メッセージ、又は既存メッセージに対する新規情報要素が必要となる。
１０．ＵＥは、自身が新規ルーティングエリア内に配置されたことを示すルーティングエリア更新要求メッセージをターゲットＳＧＳＮへ送信する。ＵＥは、このメッセージをステップ４ａの直後に送信するものとする。
ターゲットＳＧＳＮは、このＵＥに関してＩＲＡＴハンドオーバが実行されたことを認識しているので、通常ＲＡ更新手順において使用されるソースＭＭＥとターゲットＳＧＳＮとの間のコンテキスト手順を除外することができる。
１１．この時点で、ターゲットＳＧＳＮは、任意にセキュリティ機能を呼び出すことができる。セキュリティ機能を遅らせて、同様にそれ以降のいずれの時間に実行することもできる。手順については「セキュリティ機能」の条項で定める。
１２．ターゲットＳＧＳＮは、配置更新メッセージ（ＳＧＳＮ番号、ＳＧＳＮアドレス、ＩＭＳＩ）をＨＳＳへ送信することによりＣＮノードの変更をＨＳＳに通知する。
１３．ＨＳＳは、更新手順にキャンセルタイプを設定して、配置キャンセル（ＩＭＳＩ、キャンセルタイプ）メッセージをソースＭＭＥへ送信する。ソースＭＭＥは、配置キャンセル確認応答（ＩＭＳＩ）メッセージで確認応答する。このメッセージによって、ソースＭＭＥがベアラ削除要求メッセージを送信することにより、サービングＧＷ内の（単複の）ベアラを解放できるようになる。サービングＧＷが再配置されない場合には、サービングＧＷとソースＭＭＥとの間でシグナリング関係のみが解放され、ＵＥコンテキストはサービングＧＷ内に存在し続ける。間接的転送のためのリソースが割り当てられていた場合、この時点でこれらも解放されるものとする。
１４．ソースＭＭＥが配置キャンセルメッセージを受け取り、或いはステップ６ａ）で開始したタイマが時間切れになった後、ソースＭＭＥは、リソース解放メッセージをソースｅＮｏｄｅＢへ送信する。リソース解放メッセージを受け取っていて、ｅＮｏｄｅＢがデータをこれ以上転送する必要がない場合、ソースｅＮｏｄｅＢは自身のリソースを解放する。
１５．このステップは、サービングＧＷの再配置の場合にのみ実行される。ソースＭＭＥがＭＭコンテキストを削除する場合、ソースＭＭＥは、ベアラ削除要求（原因、ＴＥＩＤ）メッセージをソースサービングＧＷへ送信することによりＥＰＳベアラリソースを削除する。原因は、ソースサービングＧＷに、ソースサービングＧＷがＰＤＮ  ＧＷに対して削除手順を開始すべきでない旨を示す。ソースサービングＧＷは、ベアラ削除応答（ＴＥＩＤ）メッセージで確認応答を行う。
１６．ＨＬＲは、加入者データ挿入（ＩＭＳＩ、加入者データ）メッセージをターゲットＳＧＳＮへ送信する。ターゲットＳＧＳＮは、新規ＲＡ内にＵＥが存在することを確認する。ＵＥに関して全てのチェックが成功すると、ターゲットＳＧＳＮは、加入者データ挿入確認応答（ＩＭＳＩ）メッセージをＨＬＲへ戻す。
１７．ＨＳＳは、配置更新確認応答（ＩＭＳＩ）メッセージをターゲットＳＧＳＮへ戻すことにより、配置更新を確認応答する。
１８．ターゲットＳＧＳＮは、新規ＲＡ内にＵＥが存在することを確認する。ＵＥがこのＲＡ内に帰属することを許可されると、ターゲットＳＧＳＮはＭＭコンテキストを更新し、ルーティングエリア更新承諾（Ｐ−ＴＭＳＩ、ＴＭＳＩ、Ｐ−ＴＭＳＩ署名、その他）メッセージをＵＥへ送信する。
１９．ＵＥは、ルーティングエリア更新完了メッセージでターゲットＳＧＳＮに応答することにより、新規Ｐ−ＴＭＳＩの再配置を確認する。５．５．２．２ＵＴＲＡＮ  ＩｕモードからＥ−ＵＴＲＡＮへのＲＡＴ間ハンドオーバ。
【００３２】
図６：ＵＴＲＡＮ  ＩｕモードからＥ−ＵＴＲＡＮへのＲＡＴ間ＨＯ、準備段階
本発明の態様によれば、ＴＳ２３．４０１セクション５．５．２．２．２の準備段階を、図６を参照しながら以下の状態のままとする。
１．ソースＲＮＣが、Ｅ−ＵＴＲＡＮへのＲＡＴ間ハンドオーバの開始を決定する。この時点で、アップリンク及びダウンリンクの両方のユーザデータが、ＵＥとソースＲＮＣとの間はベアラを介して、ソースＲＮＣ、サービングＧＷ、及びＰＤＮ  ＧＷの間は（単複の）ＧＴＰトンネルを介して送信される。
注意：ハンドオーバ決定に至る処理については、本明細書の範囲外である。
２．ソースＲＮＣは、要再配置（原因、ターゲットｅＮｏｄｅＢ識別子、ソースＲＮＣ識別子、ソースからターゲットへの透明コンテナ、ベアラ要求データ転送リスト）メッセージをソースＳＧＳＮへ送信して、ＣＮにターゲットｅＮｏｄｅＢ、ターゲットＭＭＥ、及びサービングＧＷ内でリソースを確立するように要求する。
「ベアラ要求データ転送リスト」ＩＥは、ソースＲＮＣが、（直接的又は間接的）データ転送が必要であると判断した対象のＲＡＢのリストを含む。
３．ソースＳＧＳＮは、「ターゲットｅＮｏｄｅＢ識別子」ＩＥから、ハンドオーバの種類がＥ−ＵＴＲＡＮへのＩＲＡＴハンドオーバであると判断する。ソースＳＧＳＮは、再配置転送要求（ＩＭＳＩ、ターゲット識別、ＭＭコンテキスト、ＰＤＰコンテキスト、ＰＤＰコンテキスト優先順位付け、コントロールプレーンのＳＧＳＮトンネルエンドポイント識別子、コントロールプレーンのＳＧＳＮアドレス、ソースからターゲットへの透明コンテナ、直接転送フラグ）メッセージをターゲットＭＭＥへ送信することにより、ハンドオーバリソース割り当て手順を開始する。このメッセージは、ソースシステム内で確立された全てのベアラに対応する全てのＰＤＰコンテキスト、及びサービングＧＷのアップリンクのトンネルエンドポイントパラメータを含む。
「直接転送フラグ」ＩＥは、ターゲット側へのデータ直接転送を使用すべきか否かを示す。このフラグはソースＳＧＳＮにより設定される。
ＭＭコンテキストは、３ＧＰＰ  ＴＳ２９．０６０［１４］に記載されるようなサポートされる暗号アルゴリズムなどのセキュリティ関連情報を含む。
ターゲットＭＭＥが、使用する暗号アルゴリズムを選択する。このアルゴリズムは、ターゲットからソースへの透明コンテナ（ＥＰＣ部）に含められてターゲットｅＮｏｄｅＢからＵＥへ透過的に送信される。
４．ターゲットＭＭＥは、ＰＬＭＮの変更などによりサービングＧＷが再配置されるかどうかを判断する。サービングＧＷが再配置される場合、「ＧＷ選択機能」の条項で説明するように、ターゲットＭＭＥがターゲットサービングＧＷを選択する。ターゲットＭＭＥは、ベアラ生成要求メッセージ（ＩＭＳＩ、ＭＭＥコンテキストＩＤ、コントロールプレーンのＭＭＥトンネルエンドポイント識別子、コントロールプレーンのＭＭＥアドレス、ユーザプレーンの（単複の）ＰＤＮ  ＧＷアドレス、ユーザプレーンの（単複の）コントロールプレーンの（単複の）ＰＤＮ  ＧＷアドレス、及びコントロールプレーンの（単複の）ＰＤＮ  ＧＷ  ＴＥＩＤ）をターゲットサービングＧＷへ送信する。
４ａ．ターゲットサービングＧＷは、ベアラ生成応答（ユーザプレーンの（単複の）サービングＧＷのアドレス、ユーザプレーンのサービングＧＷの（単複の）ＵＬ  ＴＥＩＤ、間接転送の場合は、サービングＧＷの（単複の）ＤＬ  ＴＥＩＤ、サービングＧＷのコンテキストＩＤ）メッセージをターゲットＭＭＥへ戻す。
５．ターゲットＭＭＥは、ハンドオーバ要求メッセージ（ＵＥ識別子、原因、ＣＮドメインインジケータ、完全性保護情報（すなわち、ＩＫ及び許容された完全性保護アルゴリズム）、暗号化情報（すなわち、ＣＫ及び許可された暗号アルゴリズム)、設定されるＥＰＳベアラのリスト、ソースからターゲットへの透明コンテナ）を送信することにより、ターゲットｅＮｏｄｅＢに（単複の）ベアラを確立するように要求する。
「設定されるＥＰＳベアラ」ＩＥは、確立を要求される個々のＥＰＳベアラごとに、ＩＤ、ベアラパラメータ、トランスポート層アドレス、及びＳＩトランスポートアソシエーションなどの情報を含むものとする。トランスポート層アドレスはユーザデータのためのサービングＧＷのアドレスであり、ＳＩトランスポートアソシエーションはアップリンクのトンネルエンドポイント識別子データに相当する。
暗号キー及び完全性保護キーがターゲットからソースへの透明コンテナに含められてターゲットｅＮｏｄｅＢからＵＥへ、及びＵＴＲＡＮからのＨＯコマンドメッセージに含められてソースＲＮＣからＵＥへ透過的に送信される。この結果、新規ＡＫＡ（認証及び鍵共有）手順を必要とせずに、新しいＲＡＴ／モードのターゲットセルにおいてデータ転送を継続できるようになる。
５ａ．ターゲットｅＮｏｄｅＢは、要求されたリソースを割り当てるとともに、適用可能なパラメータをハンドオーバ要求確認応答メッセージ（ターゲットからソースへの透明コンテナ、ＥＰＳベアラ設定リスト、ＥＰＳベアラ設定失敗リスト）に含めてターゲットＭＭＥへ戻す。
ハンドオーバ要求確認応答メッセージを送信すると、承諾済みＥＳＰベアラのために、ターゲットｅＮｏｄｅＢにサービングＧＷからのダウンリンクＧＴＰ  ＰＤＵを受け取る準備が成されるものとする。
６．ターゲットＭＭＥは、ベアラ更新要求メッセージ（ＩＭＳＩ、ＭＭＥコンテキストＩＤ、ＤＬユーザプレーンのターゲットｅＮｏｄｅＢアドレス及び（単複の）ＴＥＩＤ）をターゲットサービングＧＷへ送信することができる。
６ａ．ターゲットサービングＧＷは、ベアラ更新応答（原因）メッセージをターゲットＭＭＥへ戻す。
７．ターゲットＭＭＥは、メッセージ再配置転送応答（原因、設定ＲＡＢのリスト、コントロールプレーンのＭＭＥトンネルエンドポイント識別子、Ｓ１−ＡＰ原因、コントロールプレーンのＭＭＥアドレス、データ転送のための（単複の）アドレス及び（単複の）ＴＥＩＤ）をソースＳＧＳＮへ送信する。
「直接転送」が適用可能な場合、ＩＥ「データ転送のための（単複の）アドレス及び（単複の）ＴＥＩＤ」は、ｅＮｏｄｅＢへのＧＴＰ−Ｕトンネルエンドポイントパラメータを含む。それ以外の場合、ＩＥ「データ転送のための（単複の）アドレス及び（単複の）ＴＥＩＤ」は、サービングＧＷ（或いは、再配置の場合はターゲットサービングＧＷ）へのＧＴＰ−Ｕトンネルエンドポイントパラメータを含む。
８．「直接転送」が適用可能でない場合、ソースＳＧＳＮは、ベアラ生成要求メッセージ（原因、データ転送のための（単複の）アドレス及び（単複の）ＴＥＩＤ（ステップ７を参照）、（単複の）ＮＳＡＰＩ）を、間接的パケット転送に使用するサービングＧＷへ送信するものとする。原因は、ベアラがデータ転送の対象であることを示すものとする。
ＵＥのためのアンカーポイントとして使用されるサービングＧＷとは異なるサービングＧＷを介して間接転送を行うことができる。
８ａ．サービングＧＷは、メッセージベアラ生成応答（原因、データ転送のためのサービングＧＷの（単複の）アドレス及び（単複の）ＴＥＩＤ）を送信することにより転送ユーザプレーンパラメータを返す。サービングＧＷがデータ転送をサポートしていない場合、適当な原因値が戻されて、サービングＧＷの（単複の）アドレス及び（単複の）ＴＥＩＤはメッセージに含まれなくなる。
【００３３】
図７：ＵＴＲＡＮ  ＩｕモードからＥ−ＵＴＲＡＮへのＲＡＴ間ＨＯ、準備段階
本発明の態様によれば、ＴＳ２３．４０１セクション５．５．２．２．３の実行段階を下記の太字テキストにより修正した結果、図７を参照しながら以下のように読める。
注意：ＰＭＩＰベースのＳ５／Ｓ８の場合、手順ステップ（Ａ）は３ＧＰＰ  ＴＳ  ２３．４０２［２］において定められる。ステップ９及び９ａは、ＧＴＰベースのＳ５／Ｓ８に関連する。
ソースＲＮＣは、ダウンリンク及びアップリンクのユーザプレーンＰＤＵを受信し続ける。
１．ソースＳＧＳＮは、再配置コマンドメッセージ（ターゲットからソースへの透明コンテナ、解放されるＲＡＢのリスト、データ転送対象ＲＡＢのリスト）を送信することにより、ソースＲＮＣへ向けての準備段階を完了する。「解放されるＲＡＢのリスト」ＩＥとは、ターゲットｅＮｏｄｅＢ内でベアラが確立されなかった全てのＮＳＡＰＩ（ＲＡＢ  ＩＤ）のリストのことである。「データ転送対象ＲＡＢのリスト」ＩＥをメッセージ内に含めることができ、これは、準備段階でターゲット側から受け取った「ユーザトラフィックデータ転送のための（単複の）アドレス及び（単複の）ＴＥＩＤ」のリスト（再配置転送応答メッセージ）であるものとする。
２．ソースＲＮＣはＵＥに、ＵＴＲＡＮコマンドからのＨＯメッセージを介してターゲットｅＮｏｄｅＢにハンドオーバするように命令する。このＵＥへのアクセスネットワーク固有のメッセージに含まれる透明コンテナは、ターゲットｅＮｏｄｅＢが準備段階で設定した無線状態パラメータを含む。
ソースＲＮＣは、「データ転送対象のＲＡＢのリスト」内で指定されたＲＡＢ／ＰＤＰコンテキストのためにデータ転送を開始することができる。データ転送は、ターゲットｅＮｏｄｅＢへ直接行うことができ、或いは、準備段階でソースＳＧＳＮ及び／又はターゲットＭＭＥにより決定された場合にはサービングＧＷなどを介して行うことができる。
再配置コマンドメッセージを含むＵＴＲＡＮからのＨＯコマンドメッセージを受け取ると、ＵＥは、ＮＳＡＰＩとの関係に基づいて、自身のＲＡＢ  ＩＤをそれぞれのベアラＩＤに関連付け、ユーザプレーンデータのアップリンク送信を一時停止するものとする。
３．ソースＲＮＣは、ＳＲＮＳコンテキスト転送メッセージにおいて、「配信順」パラメータに関してソースＳＧＳＮに通知を行い、その後ソースＳＧＳＮがこれをターゲットＭＭＥに通知する。
ターゲットＮＭＥは、ＳＲＮＳコンテキストをｅＮｏｄｅＢへ転送する。
４．ＵＥは、Ｅ−ＵＴＲＡＮへ移動し、ターゲットｅＮｏｄｅＢに対してアクセス手順を実行する。
５．ＵＥがターゲットｅＮｏｄｅＢにアクセスすると、Ｅ−ＵＴＲＡＮへのＨＯ完了メッセージをＥ−ＵＴＲＡＮへ送信するものとする。このメッセージに含まれるＮＡＳコンテナ／情報要素は、ＵＬ  ＴＦＴ及び対応するベアラへのマッピングを含む。
６．ＵＥがターゲットｅＮｏｄｅＢに正常にアクセスすると、ターゲットｅＮｏｄｅＢは、ハンドオーバ通知メッセージを送信することによりターゲットＭＭＥに通知を行う。このメッセージは、ＵＬ  ＴＦＴに関する情報要素を含む。
７．これでターゲットＭＭＥは、ＵＥがターゲット側に到着したことを認識し、ターゲットＭＭＥは、再配置転送完了メッセージを送信することによりソースＳＧＳＮに通知を行う。ソースＳＧＳＮもまた、この情報に確認応答を行う。（サービングＧＷの再配置の場合）ソースＲＮＣ及びソースサービングＧＷ内のリソースをいつ解放すべきかを管理するためにタイマを開始することができる（通常、これはソースＳＧＳＮがＨＳＳから配置キャンセルメッセージを受け取ったときに行われる）。ソースＳＧＳＮにおけるさらなる動作は、ステップ１４において継続する。
８．ここでターゲットＭＭＥは、今やＵＥが確立した全てのベアラにターゲットＭＭＥが関与することをサービングＧＷ（サービングＧＷの再配置の場合はターゲットサービングＧＷ）に通知することにより、ＲＡＴ間ハンドオーバ手順を完了する。これは、ベアラ更新要求メッセージ（原因、コントロールプレーンのＭＭＥトンネルエンドポイント識別子、コントロールプレーンのＭＭＥアドレス、ユーザトラフィックのための（単複の）ｅＮｏｄｅＢアドレス及び（単複の）ＴＥＩＤ、及びＲＡＴタイプ）の形で行われる。
９．サービングＧＷ（サービングＧＷの再配置の場合はターゲットサービングＧＷ）は、ベアラ更新要求メッセージを送信することにより、例えばサービングＧＷの再配置、又は課金などに使用することができるＲＡＴタイプの変更をＰＤＮ  ＧＷに通知することができる。このメッセージは、ＵＬ  ＴＦＴに関するＩＥを含む。ＰＤＮ  ＧＷは、この要求にベアラ更新応答メッセージで確認応答しなければならない。
１０．サービングＧＷ（サービングＧＷ再配置の場合はターゲットサービングＧＷ）は、ベアラ更新応答メッセージ（原因、コントロールプレーンのサービングＧＷトンネルエンドポイント識別子、コントロールプレーンのサービングＧＷのアドレス、プロトコル構成オプション）を介して、ターゲットＭＭＥに対してユーザプレーンの切替を確認応答する。この段階で、ＵＥ、ターゲットｅＮｏｄｅＢ、サービングＧＷ（サービングＧＷ再配置の場合ターゲットサービングＧＷ）、及びＰＤＰ  ＧＷ間の全てのベアラに関してユーザプレーンパスが確立される。
１１．ＵＥは、自身が新規トラッキングエリア内に配置されたことを示すトラッキングエリア更新要求メッセージをターゲットＭＭＥへ送信する。ＵＥは、このメッセージをメッセージ５の直後に送信するものとする。
ターゲットＭＭＥは、このＵＥに関してＩＲＡＴハンドオーバが実行されたことを認識しているので、通常ＴＡ更新手順において使用されるソースＳＧＳＮとターゲットＭＭＥとの間のコンテキスト手順を除外することができる。
１２．この時点で、ターゲットＭＭＥは、任意にセキュリティ機能を呼び出すことができる。セキュリティ機能を遅らせて、同様にそれ以降のいずれの時間に実行することもできる。手順については「セキュリティ機能」の条項で定める。
１３．ターゲットＭＭＥは、配置更新（ＭＭＥアドレス、ＩＭＳＩ）メッセージをＨＳＳへ送信することによりＣＮノードの変更をＨＳＳに通知する。
１４．ＨＳＳは、更新手順にキャンセルタイプを設定して、配置キャンセル（ＩＭＳＩ、キャンセルタイプ）メッセージをソースＳＧＳＮへ送信する。ソースＳＧＳＮは、配置キャンセル確認応答（ＩＭＳＩ）メッセージで確認応答する。このメッセージによって、ソースＳＧＳＮがベアラ削除要求メッセージを送信することにより、サービングＧＷ内の（単複の）ベアラを解放できるようになる。サービングＧＷが再配置されない場合には、サービングＧＷとソースＳＧＳＮとの間でシグナリング関係のみが解放され、ＵＥコンテキストはサービングＧＷ内に存在し続ける。間接的転送のためのリソースが割り当てられていた場合、この時点でこれらも解放されるものとする。
１５．ステップ７の後、ソースＳＧＳＮは、Ｉｕ解放手順を実行することにより、ソースＲＮＣへの全ての自身のリソースを一掃する。ＲＮＣがこれ以上データを転送する必要がない場合、ソースＲＮＣがＩｕ解放完了メッセージで応答する。
１６．このステップは、サービングＧＷの再配置の場合にのみ実行される。ソースＳＧＳＮがＭＭコンテキストを削除する場合、ソースＳＧＳＮは、ベアラ削除要求（原因、ＴＥＩＤ）メッセージをソースサービングＧＷへ送信することによりＥＰＳベアラリソースを削除する。原因は、ソースサービングＧＷに、ソースサービングＧＷがＰＤＮ  ＧＷに対して削除手順を開始すべきでない旨を示す。ソースサービングＧＷは、ベアラ削除応答（ＴＥＩＤ）メッセージで確認応答を行う。
１７．ＨＬＲは、加入者データ挿入（ＩＭＳＩ、加入者データ）メッセージをターゲットＭＭＥへ送信する。ターゲットＭＭＥは、新規ＴＡ内にＵＥが存在することを確認する。ＵＥに関して全てのチェックが成功すると、ターゲットＭＭＥは、加入者データ挿入確認応答（ＩＭＳＩ）メッセージをＨＬＲへ戻す。
１８．ＨＳＳは、配置更新確認応答（ＩＭＳＩ）メッセージをターゲットＭＭＥへ戻すことにより、配置更新を確認応答する。
１９．ターゲットＭＭＥは、新規ＴＡ内にＵＥが存在することを確認する。ＵＥがこのＴＡ内に帰属することを許可されると、ターゲットＭＭＥはＭＭコンテキストを更新し、トラッキングエリア更新承諾（Ｓ−ＴＭＳＩ、ＴＭＳＩ、ＴＡ−Ｌｉｓｔ、その他）メッセージをＵＥへ送信する。
２０．ＵＥは、トラッキングエリア更新完了メッセージでターゲットＭＭＥに応答することにより、新規Ｓ−ＴＭＳＩの再配置を確認する。
【００３４】
上記の特定の実施構成から分かるように、専用ベアラを起動（図２）するためにＩＳＨＯが２Ｇ／３ＧネットワークからＬＴＥネットワークへ行われる場合、専用ベアラは現在理解されるように設定され、ｅＮｏｄｅＢは、無線ベアラＱｏＳ及びＲＢ識別子を保持する無線ベアラ設定要求メッセージをＵＥへ送信する。ＵＥはこれを記憶し、ベアラ識別子を有するセッション管理応答ＩＥを構築し、自身が第２のＰＤＰコンテキストをサポートできるかどうかをチェックして、セッション管理応答ＩＥを保持するとともにサポートされる第２のＰＤＰコンテキストも示す無線ベアラ設定応答メッセージをｅＮｏｄｅＢへ送信する。ＱｏＳ更新を伴う専用ベアラ変更手順にも実質的に同じことが行われるが、メッセージはｅＮｏｄｅＢからＵＥへの無線ベアラ変更要求であり、応答はＵＥからｅＮｏｄｅＢへの無線ベアラ変更応答である。いずれにせよ、ＩＳＨＯが２Ｇ／３ＧネットワークからＬＴＥネットワークへ行われる場合、ＭＥからサービングゲートウェイＧＷへのメッセージ（図２の専用ベアラ生成応答、又は図３の専用ベアラ更新応答）によって、ＵＥによりサポートされる第２のＰＤＰコンテキストが通知される。
【００３５】
ＩＳＨＯ準備段階中の図４で分かるように、上記の解決策２を使用する場合、ソースｅＮｏｄｅＢが２Ｇ／３Ｇ下のセルを測定する要求をＵＥへ送信し、ＵＥは、サポートされる第２のＰＤＰコンテキストの情報を収集し、これをＮＡＳメッセージとして測定報告に含める（これは、図４のハンドオーバ開始前に行われる）。ソースＭＭＥは、端末がサポートするＰＤＰコンテキストのリストを再配置転送要求に含めてターゲットＳＧＳＮへ送信し、さらにターゲットＳＧＳＮが、（ハンドオーバ中にサービングゲートウェイが変更される場合）ＱｏＳ交渉された情報をＰＤＰコンテキスト更新要求メッセージに含めてターゲットサービングＧＷへ送信する。図５に見られるようなハンドオーバ実行段階中には、サービングＧＷは、ターゲットネットワーク及び端末／ＵＥにより承諾されたＰＤＰＤコンテキストのＴＥＩＤ及びＮＳＡＰＩをベアラ更新要求メッセージに含めてＰＤＮ  ＧＷへ送信し、ＰＤＢ  ＧＷは、アクティブなデータサービスフローを現在のＰＤＰコンテキストセットにいかにしてマッピングするかをベアラ更新要求応答の形で確認応答することができる。サービングＧＷは、個々のアクティブなＰＤＰコンテキストのＴＦＴを含むＰＤＰコンテキスト更新応答メッセージを送信する。端末／ＵＥによりマッピングを決定することができ、或いはＰＤＰ  ＧＷのマッピングを端末／ＵＥに与えることができる。
【００３６】
図６で分かるように、２Ｇ／３ＧからＬＴＥへのＩＳＨＯの準備段階のシグナリングに関しては本発明の実施形態による格別な変更点はないが、図７に示した実行段階では、ＵＥからターゲットｅＮｏｄｅＢへのＥ−ＵＴＲＡＮへのＨＯ完了メッセージがＵＬ  ＴＦＴ及び対応するベアラへのマッピングを含む点と、ターゲットｅＮｏｄｅＢからターゲットＭＭＥへのハンドオーバ通知メッセージがＵＬ  ＴＦＴを含む点と、ターゲットＭＭＥからサービングＧＷへのベアラ更新要求メッセージがＵＬ  ＴＦＴを含む点と、サービングＧＷからＰＤＮ  ＧＷへのベアラ更新要求メッセージがＵＬ  ＴＦＴを含む点という最高４つの変更点がある。
【００３７】
図８Ａ〜図８Ｂに詳細を示すような（ＬＴＥの観点ではベアラ開始スキームに類似すると考えられる）異なるコンテキスト開始スキームにより、以下、システム間ＨＯを適切に実行するための解決策を示す。図８Ａ〜図８ＢのＰＤＣＰとアプリケーション層との間の論理層を「接続層」とみなす。図８ＡのＱｏＳ認識端末（ＬＴＥ以前）においては、アプリケーションがより良いＱｏＳを必要として要求を行う。要求は、端末のセルラー層で第２のＰＤＰコンテキスト要求へと処理され、このＰＤＰコンテキスト要求がＳＧＳＮへ送信される。端末（セルラー層）及びアプリケーションは、要求されるＱｏＳを認識している。第２のＰＤＰコンテキスト設定の準備が整うと、ＳＧＳＮは、ＰＤＰコンテキスト応答メッセージを端末へ送信する。セルラー層は、アプリケーションと第２のＰＤＰコンテキストとの間のマッピングを行うことができ、（予約ビットレートなどの）ＱｏＳの状態についてアプリケーションに通知する。
【００３８】
図８Ｂは、本発明の実施形態によるＬＴＥ端末内のアプリケーションの挙動を示している。アプリケーションは、３ＧアクセスとＬＴＥアクセスとの間の相違を認識しないものとする。アプリケーションは、より良いＱｏＳが要求されたことを認識すると、３Ｇの場合のように要求を送信する。接続層は、現在のアクセス技術を認識している。ＬＴＥ端末はＱｏＳを要求することを許可されていないので、接続層は、要求されたＱｏＳの情報を記憶するが、この情報をネットワークへシグナリングすることはない。アプリケーションレベルのシグナリングにより、ネットワークがリソース予約を開始するようになり、リソース予約の準備が整うと、無線ベアラ設定シグナリングにおいて、端末にアプリケーション固有のＱｏＳ情報が非アクセス層ＮＡＳメッセージの形で与えられる。リソース予約に失敗すると、ＭＭＥからＵＥへの直接転送を使用して失敗情報を転送する。接続層は常にこの情報を受け取り、この情報が使用されるか否かはアプリケーション及びミドルウェア次第で決まる。ＰＤＣＰ層は、ＮＡＳメッセージをセルラー層に渡し、ここで割り当て済みのＱｏＳが、マッチするアプリケーション層要求に結び付けられる。割り当て済みのＱｏＳは、要求側アプリケーションに応答として与えられる。（アプリケーション側から見れば、第２のＰＤＰコンテキスト応答が到着したのと同じである）。セルラー層ではＳＡＥ／ＥＰＳベアラが見えず、アプリケーション固有のＱｏＳ情報のみが見える。
【００３９】
ここで、本発明の例示的な実施形態の実施における使用に適した様々な電子装置の簡略ブロック図を示す図９を参照する。図９では、ＵＥ９１０とＮｏｄｅ  Ｂ９１２（ｅ−ＮｏｄｅＢ）との間の通信に第１の無線ネットワークが適用される。ネットワークは、ゲートウェイＧＷ／サービングモビリティエンティティＭＭＥ／無線ネットワークコントローラＲＮＣ９１６、又は異なる無線通信システムにおいて様々な用語で知られるその他の無線コントローラ機能を含むことができる。ＵＥ９１０は、データプロセッサ（ＤＰ）９１０Ａと、プログラム（ＰＲＯＧ）９１０Ｃを記憶するメモリ（ＭＥＭ）９１０Ｂと、適当な無線周波数（ＲＦ）トランシーバ９１０Ｄを含み、この無線周波数（ＲＦ）トランシーバ９１０Ｄは、Ｎｏｄｅ  Ｂ  ９１２との１又はそれ以上の無線リンク９２０を介した双方向無線通信のために１又はそれ以上のアンテナ９１０Ｅ（１つを図示）に結合される。
【００４０】
「接続された」、「結合された」という用語、又はこれらのあらゆる変形は、直接的、間接的を問わず、２又はそれ以上の要素間のあらゆる接続又は結合を意味するとともに、ともに「接続された」又は「結合された」２つの要素間における１又はそれ以上の中間要素の存在を含むことができる。要素間の結合又は接続は、物理的なもの、論理的なもの、又はこれらの組み合わせであってもよい。本明細書で使用する場合、２つの要素が、１又はそれ以上のワイヤ、ケーブル、及びプリント電気接続部を使用して、並びに非限定的な例として、高周波領域、マイクロ波領域及び光学（可視、不可視の両方）領域内に波長を有する電磁エネルギーなどの電磁エネルギーを使用して、ともに「接続」又は「結合」されると考えることができる。
【００４１】
Ｎｏｄｅ  Ｂ９１２もまた、ＤＰ９１２Ａと、ＰＲＯＧ９１２Ｃを記憶するＭＥＭ９１２Ｂと、１又はそれ以上のアンテナ９１２Ｅに結合された適当なＲＦトランシーバ９１２Ｄとを含む。Ｎｏｄｅ  Ｂ９１２は、（Ｉｕｂ又はＳ１インタフェースなどの）データパス９４０を介してサービング又はその他のＧＷ／ＭＭＥ／ＲＮＣ９１６に結合することができる。ＧＷ／ＭＭＥ／ＲＮＣ９１６は、ＤＰ９１６Ａと、ＰＲＯＧ９１６Ｃを記憶するＭＥＭ９１６Ｂと、Ｉｕｂリンク９４０を介してＮｏｄｅ  Ｂ９１２と通信するための適当なモデム及び／又はトランシーバ（図示せず）を含む。
【００４２】
また、ｎｏｄｅ  Ｂ９１２内には、様々なＵＬ及びＤＬサブフレームに関して様々なＵＥをｎｏｄｅ  Ｂの制御下でスケジューリングする（ＤＰ９１２Ａ内の機能のような）スケジューラが存在する。一般に、ＬＴＥシステムのＮｏｄｅ  Ｂ９１２は、自身のスケジューリングにおいてかなり自立しており、自身のＵＥの１つが他のＮｏｄｅ  Ｂにハンドオーバしている間以外は、ＧＷ／ＭＭＥ９１６と協調する必要はない。
【００４３】
第２のネットワークは、図９の第１のネットワークと類似しており、ＤＰ９１４Ａと、ＰＲＯＧ９１４Ｃを記憶するＭＥＭ９１４Ｂと、ＵＥ９１０とのリンク９３０を介して双方向通信を行うべくアンテナに結合されたトランシーバ９１４Ｄとを含む第２のノードＢ９１４を有する。第２のネットワークのよりも上位のネットワークノードはＲＮＣ９１８と呼ばれ、これもまたＰＲＯＧ９１８Ｃを記憶するＭＥＭ９１８Ｂに結合されたＤＰ９１８Ａを有し、データパス９５０を介して自身のノードＢと通信を行い、第１のネットワークのＭＭＥ９１６とのデータパス９７０を有することができる。２つのシステム間ノードＢを、データパス９６０により結合することもできる。
【００４４】
ＰＲＯＧ９１０Ｃ、９１２Ｃ、及び９１４Ｃのうちの少なくとも１つは、関連するＤＰにより実行された場合、電子装置を上述のような本発明の例示的な実施形態に従って動作できるようにするプログラム命令を含むと推定される。ＤＰ９１０Ａ、９１２Ａ、及び９１４Ａには、要求される適切な時間間隔及びタイムスロット内で送受信を行うために、様々な装置間における同期を可能にするためのクロックが備わっているが、これはスケジューリングの実行及び付与されたリソース／サブフレームが時間に依存するためである。
【００４５】
必要に応じて、ＰＲＯＧ９１０Ｃ、９１２Ｃ、９１４Ｃをソフトウェア、ファームウェア、及び／又はハードウェアにおいて具体化することができる。一般に、図示の装置の一部又は全てにおいて、本発明の例示的な実施形態を、ＭＥＭ９１０Ｂ内に記憶されたコンピュータソフトウェアによって実施し、ＵＥ９１０のＤＰ９１０Ａにより、またＮｏｄｅ  Ｂ９１２及び９１４並びにより上位のネットワークノード９１６及び９１８の他のＭＥＭ９１２Ｂ、９１４Ｂ、９１６Ｂ、９１８Ｂ、及びＤＰ９１２Ａ、９１４Ａ、９１６Ａ、９１８Ａに関しても同様であるが、ハードウェアにより、又はソフトウェア及び／又はファームウェアとハードウェアとの組み合わせにより実行することができる。
【００４６】
一般に、ＵＥ９１０の様々な実施形態として、以下に限定されるわけではないが、移動局、携帯電話、無線通信能力を有する携帯情報端末（ＰＤＡ）、無線通信能力を有するポータブルコンピュータ、無線通信能力を有するデジタルカメラなどの画像取込装置、無線通信能力を有するゲーム装置、無線通信能力を有する音楽ストレージ及び再生機器、無線インターネット接続及びブラウジングを可能にするインターネット機器、並びにこのような機能の組み合わせを組み込んだポータブルユニット又は端末を挙げることができる。
【００４７】
ＭＥＭは、ローカルな技術環境に適したいずれの種類のものであってもよく、半導体ベースのメモリ装置、磁気記憶装置及びシステム、光学記憶装置及びシステム、固定記憶装置及び着脱可能記憶装置などのあらゆる適当なデータストレージ技術を使用して実装することができる。ＤＰは、ローカルな技術環境に適したいずれの種類のものであってもよく、また非限定的な例として、１又はそれ以上の汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、及びマルチコアプロセッサアーキテクチャに基づくプロセッサを含むことができる。
【００４８】
ＬＴＥから２Ｇ／３ＧへのマッピングのためのＭＭＥに関する本発明の態様では、図示のプロセッサ９１２Ａ、９１４Ａ、９１６Ａ、９１８ＡなどのＮｏｄｅ  Ｂ９１２、９１４又はより上位のネットワークノード９１６、９１８のデータプロセッサによって実行可能なコンピュータソフトウェアにより、又はハードウェアにより、或いはソフトウェアとハードウェアとの組み合わせにより本発明の実施形態を実施することができる。この態様の実施形態によれば、装置と、動作を実行するための命令のプログラムを記憶するコンピュータ可読メモリと、第２のＰＤＰコンテキストを要求した少なくとも１つのアプリケーションを示す第１の情報と対応するＵＬ  ＴＦＴのＳＡＥベアリングへのマッピングを示す第２の情報とを受け取るステップと、少なくとも１つのＳＡＥベアラの少なくとも１つのＰＤＰコンテキストへのマッピングを含むマップを生成するステップと、生成されたマップを示す第３の情報を送信するステップとを含む方法が存在する。
【００４９】
２Ｇ／３ＧからＬＴＥへのマッピングのためのＭＭＥに関する本発明の態様では、図示のプロセッサ９１２Ａ、９１４Ａ、９１６Ａ、９１８ＡなどのＮｏｄｅ  Ｂ９１２、９１４又はより上位のネットワークノード９１６、９１８のデータプロセッサによって実行可能なコンピュータソフトウェアにより、又はハードウェアにより、或いはソフトウェアとハードウェアとの組み合わせにより本発明の実施形態を実施することができる。この態様の実施形態によれば、装置と、動作を実行するための命令のプログラムを記憶するコンピュータ可読メモリと、少なくとも１つのＳＡＥ／ＥＰＳベアラへの少なくとも１つのＰＤＰコンテキストを示す第１の情報を受け取るステップと、使用中の少なくとも１つのＰＤＰコンテキストの少なくとも１つのＳＡＥ又はＥＰＳベアラへのマッピングを含むマップを生成するステップと、少なくとも１つのＳＡＥ又はＥＰＳベアラを開始するステップと、生成されたマップを示す第２の情報を送信するステップとを含む方法が存在する。
【００５０】
ＬＴＥから２Ｇ／３ＧへのマッピングのためのＵＥに関する本発明の態様では、図示のプロセッサ９１０ＡなどのＵＥ９１０のデータプロセッサによって実行可能なコンピュータソフトウェアにより、ハードウェアにより、又はソフトウェアとハードウェアとの組み合わせにより本発明の実施形態を実施することができる。この態様の実施形態によれば、装置と、動作を実行するための命令のプログラムを記憶するコンピュータ可読メモリと、第２のＰＤＰコンテキストを要求した少なくとも１つのアプリケーションを示す第１の情報と対応するＵＬ  ＴＦＴのＳＡＥベアリングへのマッピングを示す第２の情報とを送信するステップと、少なくとも１つのＳＡＥベアラの少なくとも１つのＰＤＰコンテキストへのマッピングを含むマップを示す第３の情報を受け取るステップとを含む方法が存在する。
【００５１】
本発明の例示的な態様によれば、ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストを含む情報を受け取るステップと、この情報に基づいて、ソースネットワークにおいて、少なくとも１つのベアラを少なくとも１つのパケットデータプロトコルコンテキストにマッピングするステップとを含む動作又は機能を実行するための少なくとも方法、装置、及び実行可能コンピュータプログラムが存在する。
【００５２】
さらに、上記によれば、少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた少なくとも１つのベアラの指示と、マッピングのための対応する保証ビットレート及びトラフィックフローテンプレートの少なくとも一方とを含む情報をユーザ装置に送信する動作又は機能を実行するための方法、装置、及び実行可能コンピュータプログラムが存在する。さらに、上記のいずれかによれば、ユーザ装置のためにサポートされる少なくとも１つのパケットデータプロトコルコンテキストの指示を含む情報をターゲットネットワーク装置へ送信する。さらに、上記によれば、ソースネットワークのモビリティ管理エンティティ内でマッピングが行われ、装置をモビリティ管理エンティティにおいて具体化することができる。
【００５３】
また、前述のいずれかと同様に、マッピングされた少なくとも１つのベアラのための対応するパケットデータプロトコルコンテキストのサービス品質を含む情報をユーザ装置へ送信するための動作又は機能がサポートされ、同様に、少なくとも１つのベアラが、システムアーキテクチャエボリューションのデフォルトベアラ又はシステムアーキテクチャエボリューションの専用ベアラの一方であり、少なくとも１つのパケットデータプロトコルコンテキストが、第１のパケットデータプロトコルコンテキスト又は第２のパケットデータプロトコルコンテキストの一方である。
【００５４】
また、上記の動作によれば、ソースネットワークのモビリティ管理エンティティ上でマッピングを行うことができ、ソースネットワークをロングタームエボリューションネットワークとすることができ、ターゲットネットワークを汎用パケット無線サービスネットワークとすることができる。
【００５５】
本発明の例示的な実施形態によれば、ターゲットネットワークの少なくとも１つのパケットデータプロトコルコンテキストにマッピングされた少なくとも１つのベアラの指示を含む情報をソースネットワーク装置から受け取り、受け取った情報をハンドオーバで使用するために記憶するための少なくとも方法と、実行可能コンピュータプログラムと、装置とが存在する。上記によれば、受け取った情報が、対応する保証ビットレート及びトラフィックフローテンプレートの少なくとも一方をさらに含むことができる。また、ネットワーク装置からハンドオーバ手順の指示を受け取ることができ、このハンドオーバ指示の受け取りに応答して、サポートされるマッピングを含む情報をネットワーク装置へ送信する。上記に加え、少なくとも１つのベアラが、システムアーキテクチャエボリューションのデフォルトベアラ又はシステムアーキテクチャエボリューションの専用ベアラの一方であり、少なくとも１つのパケットデータプロトコルコンテキストが、第１のパケットデータプロトコルコンテキスト又は第２のパケットデータプロトコルコンテキストの一方であることがわかる。さらに、上記の要素をユーザ装置内で実行することができ、ハンドオーバをロングタームエボリューションネットワークから汎用パケット無線サービスネットワークに対して行うことができる。
【００５６】
一般に、様々な実施形態を、ハードウェア又は専用回路、ソフトウェア（コンピュータ可読媒体上で具体化されるコンピュータ可読命令）、論理回路、又はこれらのあらゆる組み合わせの形で実現することができる。例えば、ハードウェアの形で実現できる態様もあれば、コントローラ、マイクロプロセッサ、又はその他のコンピュータ装置により実行できるファームウェア又はソフトウェアの形で実現できる態様もあるが、本発明はこれらに限定されるものではない。本発明の様々な態様をブロック図、フロー図、又は他の何らかの図的記述を使用して示し説明することができるが、本明細書で説明したこれらのブロック、装置、システム、技術、又は方法を、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路又は論理回路、汎用ハードウェア又はコントローラ又はその他のコンピュータ装置、又はこれらのいくつかの組み合わせの形で実行できることが十分に理解される。さらに、この点に関して、上述した様々な論理ステップ／順次的シグナリングは、プログラムステップ、又は相互接続された論理回路、ブロック及び機能、或いはプログラムステップと論理回路とブロック及び機能との組み合わせを表すことができる。
【００５７】
本発明の実施形態を、一体型回路モジュールなどの様々な構成要素において実施することができる。一体型回路の設計は、概して高度に自動化されたプロセスである。論理レベルの設計を、半導体基板上でエッチングされ形成される準備ができている半導体回路設計に変換するために、複雑かつ強力なソフトウェアツールが利用可能である。
【００５８】
カリフォルニア州マウンテンビューのＳｙｎｏｐｓｙｓ社、及び、カリフォルニア州サンホセのＣａｄｅｎｃｅ  Ｄｅｓｉｇｎ社により提供されるようなプログラムは、十分に確立した設計ルール並びに事前に記憶した設計モジュールのライブラリを使用して、自動的に導体を導き半導体チップ上に構成部品を位置決めする。半導体回路の設計が完了すると、結果として得られる（Ｏｐｕｓ、ＧＤＳＩＩなどの）標準化された電子品フォーマットの形の設計を半導体加工施設へ、又は製造のために製造工場へ送信することができる。
【００５９】
添付図面と併せて読めば、当業者には上述の説明に照らして様々な修正及び適応が明らかとなるであろう。しかしながら、本発明の例示的な実施形態のあらゆる修正も本発明の非限定的な実施形態の範囲に含まれる。
【００６０】
特定の実施形態との関連において説明したが、当業者には、これらの教示に対する数多くの修正及び様々な変更を行えることが明らかであろう。したがって、本発明の本発明の１又はそれ以上の実施形態に関連して本発明を具体的に示し説明したが、当業者であれば、上述したような本発明の範囲から逸脱することなく本発明に一定の修正又は変更を行えることを理解するであろう。
【図１Ａ】
2011504035.tif 000003
【図１Ｂ】
2011504035.tif 000004
【図２】
2011504035.tif 000005
【図３】
2011504035.tif 000006
【図４】
2011504035.tif 000007
【図５Ａ】
2011504035.tif 000008
【図５Ｂ】
2011504035.tif 000009
【図６】
2011504035.tif 000010
【図７Ａ】
2011504035.tif 000011
【図７Ｂ】
2011504035.tif 000012
【図８Ａ】
2011504035.tif 000013
【図８Ｂ】
2011504035.tif 000014
【図９】
2011504035.tif 000015
【国際調査報告】
2011504035.tif 000016
2011504035.tif 000017
2011504035.tif 000018