中継ノードとのハンドオーバを実施するための方法および装置
ネットワーク内で中継ノード（ＲＮ）とハンドオーバを実施するための技法が開示されている。ＲＮは、高度化ノードＢ（ｅＮＢ）と無線送信／受信ユニット（ＷＴＲＵ）の間に配備されるノードである。ＲＮは、ｅＮＢおよびＷＴＲＵのうちの一方からデータを受信し、それを他方に転送する。ＲＮは、サービングドナー高度化ノードＢ（ＤｅＮＢ）からパケットデータ収束プロトコル（ＰＤＣＰ）プロトコルデータユニット（ＰＤＵ）を受信し、それをＷＴＲＵに送信する。ＲＮは、ＷＴＲＵから受信された測定レポートに基づいてハンドオーバの決定を行う。ハンドオーバの決定を行った後で、ＲＮは、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含めて、ハンドオーバ要求または制御メッセージをサービングＤｅＮＢに送る。次いで、サービングＤｅＮＢは、最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄する。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、無線通信に関する。
【背景技術】
【０００２】
関連出願の相互参照
本願は、２００９年６月１７日に出願された米国特許仮出願第６１／１８７，８０９号および２００９年６月１７日に出願された米国特許仮出願第第６１／１８７，８７９号の利益を主張するものであり、これらの特許出願を、完全に記載されているかのように参照により組み込む。
【０００３】
拡張ロングタームエボリューション（ＬＴＥ−Ａ）では、中継ノード（ＲＮ）の概念が導入されている。ＲＮは、高度化ノードＢ（ｅＮＢ）（すなわち、基地局）と無線送信／受信ユニット（ＷＴＲＵ）の間に配備されるノードである。ＲＮは、ｅＮＢおよびＷＴＲＵのうちの一方からデータを受信し、それを他方に転送する。ＲＮへの、またＲＮからのＷＴＲＵのリンク（回線）品質は、ＲＮの方がＷＴＲＵに近いためｅＮＢとの間の直接リンクよりも良いものとなるであろう、したがってｅＮＢとＷＴＲＵの間のリンクの性能は、ＲＮを導入することによって高まるであろう。
【０００４】
ＲＮは、カバレージ（受信可能範囲サービスエリア）の改善が必要とされるときに、ｅＮＢを設置することに対しての低コストな選択肢であることを狙いとしているが、無線ネットワークの容量を改善するために使用することもできる。コスト削減は、ネットワークに対する有線リンクに付随する資本経費および事業費を削減することによって達成される。有線リンクに代わって、ＲＮは、ネットワークに対してのリンク（回線）を提供する「ドナーｅＮＢ（ＤｅＮＢ）」に無線を用いて通信する。レガシーＷＴＲＵ（すなわち、第３世代移動体通信システムの標準化プロジェクト（３ＧＰＰ）リリース９またはそれ以前のＷＴＲＵ）にとって、ＲＮは、ちょうどｅＮＢのように見える。図１は、ＤｅＮＢと共にＲＮの例示的な配備を示し、ＲＮとＤｅＮＢとに関連するインターフェースをも示す。
【０００５】
ＬＴＥ−Ａ（拡張ロングタームエボリューション）でＲＮを配備する場合には、ＲＮとｅＮＢの間にハンドオーバが発生する可能性がある。以下のハンドオーバシナリオが予期され、すなわち、ＷＴＲＵが、ＲＮからそれ自体のサービングドナー高度化ノードＢ（ｅＮＢ）に移動すること、ＷＴＲＵが、ＲＮから隣接するドナー高度化ノードＢに移動すること、ＷＴＲＵが、あるＲＮから、同じドナー高度化ノードＢによってサービスの提供を受ける別のＲＮに移動すること、ＷＴＲＵが、あるＲＮから、隣接するドナー高度化ノードＢによってサービスの提供を受ける別のＲＮに移動すること、ＷＴＲＵが、ドナー高度化ノードＢから、同じドナー高度化ノードＢによってサービスの提供を受けるＲＮに移動すること、ＷＴＲＵが、隣接するドナー高度化ノードＢから、異なるドナー高度化ノードＢによってサービスの提供を受けるＲＮに移動すること、などが予期される。
【０００６】
ＷＴＲＵをＲＮから（別のＲＮ、またはＤｅＮＢのいずれかへ）ハンドオーバする必要があるとき、無線リンク制御（ＲＬＣ）非応答モード（ＵＭ）の場合には、まだダウンリンクでのＲＮの送信がＲＬＣによって完了されていない、ＲＮ内のパケットデータ収束プロトコル（ＰＤＣＰ）サービスデータユニット（ＳＤＵ）を、無線バックホール（ｂａｃｋｈａｕｌ：帰路）リンクを介してＤｅＮＢに転送する必要がある。ＲＬＣ応答（アクノリッジ）モード（ＡＭ）の場合は、ダウンリンク送信の場合で、送信することができなかったＰＤＣＰ ＳＤＵに加えて、ＲＮが、ＷＴＲＵによってＲＬＣレイヤにて成功裏に確認（アクノリッジ）されていないＰＤＣＰ ＳＤＵをも転送しなければならない。これらのデータパケットの再転送の事例が必須となるが、それは、バックホールリンク（Ｕｎ）とアクセスリンク（Ｕｕ）の両方が、自立して動作し、図２〜図９に示されているように別々のピアツゥピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）データリンクレベル伝送プロトコルスタックを実装することを考えると、ＤｅＮＢが、ＲＮに前に送信されたＰＤＣＰ ＳＤＵを削除している可能性があるからである。データの再転送は、バックホールリソースを２回消耗する（すなわち、ＤｅＮＢからＲＮにデータを送信するのに使用されるリソースと、ＲＮからＤｅＮＢにデータを再送信するのに使用されるリソース）。
【０００７】
ＬＴＥ−Ａにおいて考えられているユーザプレーン（Ｕプレーン）および制御プレーン（Ｃプレーン）のプロトコルアーキテクチャの例示が図２〜図９に示されている。図２および図３は、ＤｅＮＢにとってトランスペアレント（透過的）であるフルＬ３リレーのためのＣプレーンアーキテクチャおよびＵプレーンアーキテクチャを示す。図４および図５は、プロキシＳ１／Ｘ２のためのＣプレーンアーキテクチャおよびＵプレーンアーキテクチャを示す（すなわち、ＲＮは、無線通信移動管理装置（ＭＭＥ）にとってＤｅＮＢ下のセルのように見える）。図６および図７は、ＲＮベアラがＲＮで終了する場合のＣプレーンアーキテクチャおよびＵプレーンアーキテクチャを示す。図８および図９は、Ｓ１インターフェースがＤｅＮＢで終了するＣプレーンアーキテクチャおよびＵプレーンアーキテクチャを示す。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ハンドオーバ中におけるＲＮからＤｅＮＢへのデータ再転送を削減または回避すること、ハンドオーバ中にもとのサービングＤｅＮＢに再転送する必要があるＤｅＮＢからＲＮに転送されたデータ量を最小限に抑えること、およびＲＮとサービングＤｅＮＢ間での不必要なデータ交換に起因するハンドオーバ完了時間を縮小することが望ましいであろう。
【課題を解決するための手段】
【０００９】
ネットワーク内でＲＮとハンドオーバを実施するための実施形態を開示する。ＲＮは、ｅＮＢとＷＴＲＵの間に配備されるノードである。ＲＮは、ｅＮＢおよびＷＴＲＵのうちの一方からデータを受信し、それを他方に転送する。ＲＮは、ＷＴＲＵから受信された測定レポートに基づいてハンドオーバの決定をすることができる。ハンドオーバを決定した後で、ＲＮは、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含めて、ハンドオーバ要求または制御メッセージをサービングＤｅＮＢに送る。次いで、サービングＤｅＮＢは、最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵ（パッケトデータユニット）を破棄する。
【００１０】
ＲＮおよびサービングＤｅＮＢは、ＲＮとＷＴＲＵの間の無線インターフェースを介してＷＴＲＵに送信されたデータのＰＤＣＰ ＳＮと、ＲＮとサービングＤｅＮＢの間の無線インターフェースを介してＲＮによって受信されたデータのＰＤＣＰ ＳＮ間のマッピングのテーブルを維持することができる。ＲＮは、呼セットアップ中に、ＷＴＲＵコンテキストアイデンティティ（ＩＤ）、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報をサービングＤｅＮＢに提供することができる。
【００１１】
サービングＤｅＮＢは、ハンドオーバ要求メッセージをターゲットｅＮＢに転送する。ターゲットｅＮＢは、アドミッション制御を実施する。ターゲットｅＮＢは、ハンドオーバ要求ＡＣＫメッセージをサービングＤｅＮＢに送る。サービングＤｅＮＢは、データをターゲットｅＮＢに転送する。ＷＴＲＵは、ターゲットｅＮＢとの同期を実施し、ＲＡＣＨを介してターゲットセルにアクセスし、ターゲットｅＮＢは、ＵＬ割当ておよびタイミングアドバンスで応答し、ＷＴＲＵがターゲットセルへのアクセスに成功したとき、ＷＴＲＵは、ＲＲＣハンドオーバ完了メッセージを送る。ターゲットｅＮＢは、経路切替要求メッセージをＭＭＥ／ＧＷに送り、ＷＴＲＵがセルを変更したことを通知する。サービングＧＷは、ダウンリンクデータ経路をターゲットｅＮＢに切り替え、元の経路上の１つまたは複数のＳ１−ＵＰエンドマーカパケットをソースＲＮおよび／またはソースＤｅＮＢに送り、次いでＵプレーン／トランスポートネットワークレイヤ（ＴＮＬ）リソースをソースＲＮに対して解放する。
【００１２】
より詳細な理解を、添付の図面と共に、例として与えられている以下の説明から得ることができる。
【図面の簡単な説明】
【００１３】
【図１】例示的なリレー配備アーキテクチャを示す。
【図２】ＬＴＥ−Ａにおいて考えられているＣプレーンプロトコルアーキテクチャの例を示す図である。
【図３】ＬＴＥ−Ａにおいて考えられているＵプレーンプロトコルアーキテクチャの例を示す図である。
【図４】ＬＴＥ−Ａにおいて考えられているＣプレーンプロトコルアーキテクチャの例を示す図である。
【図５】ＬＴＥ−Ａにおいて考えられているＵプレーンプロトコルアーキテクチャの例を示す図である。
【図６】ＬＴＥ−Ａにおいて考えられているＣプレーンプロトコルアーキテクチャの例を示す図である。
【図７】ＬＴＥ−Ａにおいて考えられているＵプレーンプロトコルアーキテクチャの例を示す図である。
【図８】ＬＴＥ−Ａにおいて考えられているＣプレーンプロトコルアーキテクチャの例を示す図である。
【図９】ＬＴＥ−Ａにおいて考えられているＵプレーンプロトコルアーキテクチャの例を示す図である。
【図１０】拡張地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）を含むＬＴＥ無線通信システム／アクセスネットワークの図である。
【図１１】ＷＴＲＵ、ｅＮＢ、およびＲＮを含むＬＴＥ無線通信システムの例示的なブロック図である。
【図１２】一実施形態に従ってＲＮが展開されるネットワーク内でのハンドオーバの例示的なプロセスを示す図である。
【図１３】他の実施形態に従ってＲＮが展開されるネットワーク内でのハンドオーバのための例示的なプロセスの流れ図である。
【発明を実施するための形態】
【００１４】
「ＷＴＲＵ」という用語は、以下で参照されたとき、それだけには限らないが、ユーザ機器（ＵＥ）、移動局、固定型もしくは移動型加入者ユニット、ページャ（ポケットベル）、セルラ電話、携帯情報端末（ＰＤＡ）、コンピュータ、センサ、マシーン−ツ−マシーン（Ｍ２Ｍ）のデバイス、または無線環境内で動作することが可能な任意の他のタイプのデバイスを含む。「高度化ノードＢ（ｅＮＢ）」「ＤｅＮＢ」または「ＲＮ」という用語は、以下で参照されたとき、それだけには限らないが、基地局、サイトコントローラ、アクセスポイント（ＡＰ）、または無線環境内で動作することが可能な任意の他のタイプのインターフェース用デバイスを含む。
【００１５】
３ＧＰＰ ＬＥＴおよびＬＴＥ−Ａに関連して実施形態が開示されているが、これらの実施形態はＬＥＴまたはＬＴＥ−Ａに限定されず、それだけには限らないが、３ＧＰＰ広帯域符号分割多元接続（ＷＣＤＭＡ）、ＣＤＭＡ２０００、ＩＥＥＥ８０２．ＸＸなどを含めて、現在存在する、または将来配備されることができる任意の無線通信技術に適用可能であることに留意されたい。本明細書に記載されている諸実施形態は、任意の順序または組合せで適用可能とすることができ、実施形態の任意の特定の部分は、その実施形態の残りの部分なしに独立して実施することができることに留意されたい。本明細書で開示されている実施形態は、現在論じられている、または将来開発されることになるＲＮを含めて、任意のプロトコルアーキテクチャで実施することができることに留意されたい。
【００１６】
図１０は、拡張地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）２０５を含むＬＴＥ無線通信システム／アクセスネットワーク２００を示す。Ｅ−ＵＴＲＡＮ２０５は、いくつかのｅＮＢ２２０と、少なくとも１つのＲＮ２４０とを含む。ＷＴＲＵ２１０は、ｅＮＢ２２０またはＲＮ２４０のいずれかと通信することができる。ｅＮＢ２２０は、Ｘ２インターフェースを使用して互いにインターフェースする。ｅＮＢ２２０のそれぞれは、Ｓ１インターフェースを介して無線通信移動管理装置（ＭＭＥ）／サービングゲートウェイ（Ｓ−ＧＷ）２３０とインターフェースする。ｅＮＢ２２０は、Ｕｎインターフェースを使用してＲＮとインターフェースする。ＲＮ２４０またはｅＮＢ２２０は、Ｕｕインターフェースを使用してＷＴＲＵ２１０とインターフェースする。単一のＷＴＲＵ２１０、３つのｅＮＢ２２０、および単一のＲＮ２４０が図１０に示されているが、任意の数のデバイスが存在してもよく、無線デバイスと有線デバイスの任意の組合せが無線通信システムアクセスネットワーク２００に含まれてもよいということは明らかなはずである。
【００１７】
図１１は、ＷＴＲＵ２１０、ｅＮＢ２２０、およびＲＮ２４０を含むＬＴＥ無線通信システム４００の例示的なブロック図である。ＷＴＲＵ２１０、ｅＮＢ２２０、およびＲＮ２４０は、本明細書で開示されている実施形態に従って、無線通信、フロー制御、およびハンドオーバを実施するように構成されている。
【００１８】
ＷＴＲＵ２１０は、典型的なＷＴＲＵに見出すことができる構成要素に加えて、少なくとも１つのトランシーバ２１１と、任意選択で接続されるメモリ２１３を有するプロセッサ２１２と、アンテナ２１４とを含む。プロセッサ２１２は、単独またはソフトウェアとの組合せで、本明細書で開示されている実施形態に従って、無線通信、フロー制御、およびハンドオーバを実施するように構成される。トランシーバ２１１は、プロセッサ２１２およびアンテナ２１４と通信して、無線通信の送信および受信を容易にする。ＷＴＲＵ２１０は、ｅＮＢ２２０またはＲＮ２４０のいずれか一方と通信することができる。
【００１９】
ｅＮＢ２２０は、典型的なｅＮＢに見出すことができる構成要素に加えて、少なくとも１つのトランシーバ２２１と、任意選択で接続されるメモリ２２３を有するプロセッサ２２２と、アンテナ２２４とを含む。プロセッサ２２２は、単独またはソフトウェアとの組合せで、本明細書で開示されている実施形態に従って、無線通信、フロー制御、およびハンドオーバを実施するように構成される。トランシーバ２２１は、プロセッサ２２２およびアンテナ２２４と通信して、無線通信の送信および受信を容易にする。
【００２０】
ＲＮ２４０は、少なくとも１つのトランシーバ２４１と、任意選択で接続されるメモリ２４３を有するプロセッサ２４２と、アンテナ２４４とを含む。プロセッサ２４２は、単独またはソフトウェアとの組合せで、本明細書で開示されている実施形態に従って、無線通信、フロー制御、およびハンドオーバを実施するように構成される。トランシーバ２４１は、プロセッサ２４２およびアンテナ２４４と通信して、無線通信の送信および受信を容易にする。
【００２１】
図１２は、一実施形態に従ってＲＮが展開されるネットワーク内でのハンドオーバの例示的なプロセス（一連の処理過程）５００を示す。この例では、ＷＴＲＵが現在はＲＮ（ソースＲＮ）に接続されているが、別のｅＮＢ（ターゲットｅＮＢ）にハンドオーバされつつあるのを想定している。呼セットアップ（呼設定）中に、ＷＴＲＵ高度化パケットシステム（ＥＰＳ）ベアラおよびＵｕ無線ベアラ（ＲＢ）、ならびにＲＮ ＥＰＳベアラおよびＵｎインターフェースＲＢが確立され、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＲＢ間のマッピングまたは関連付けが確立される（５０２）。ＷＴＲＵ ＥＰＳベアラは、ＷＴＲＵとパケットデータネットワークゲートウェイ（Ｐ−ＧＷ）の間に確立されるベアラであり、ＲＮ ＥＰＳベアラは、ＲＮとＰ−ＧＷの間に確立されるベアラである。Ｕｕ ＲＢは、Ｕｕインターフェースを介してＷＴＲＵとＲＮの間に確立されるベアラであり、Ｕｎ ＲＢは、Ｕｎインターフェースを介してＲＮとソースＤｅＮＢの間に確立されるベアラである。
【００２２】
ＲＮは、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＲＢ間のマッピングまたは関連付けを維持することができる。マッピングは、一意のＷＴＲＵコンテキストＩＤ、（１つまたは複数の）ＲＮベアラ（たとえば、インターネットプロトコル（ＩＰ）ソースアドレス、ＩＰ宛先アドレス、ユーザデータグラムプロトコル（ＵＤＰ）ソースポート、ＵＤＰ宛先ポート、トンネルエンドポイントＩＤ）、（１つまたは複数の）ＷＴＲＵベアラ（たとえば、ＩＰソースアドレス、ＩＰ宛先アドレス、ＵＤＰソースポート、ＵＤＰ宛先ポート、トンネルエンドポイントＩＤ）、（１つまたは複数の）ＲＮベアラＩＤ、（１つまたは複数の）ＷＴＲＵベアラＩＤに基づいて維持することができる。これは、図２〜図９におけるプロトコルアーキテクチャのいずれかに適用可能である。
【００２３】
この実施形態によれば、ＲＮは、サービングＤｅＮＢと制御メッセージを交換する。制御メッセージは、ハンドオーバ中に、ＲＮからサービングＤｅＮＢに再転送で返される必要があるデータ量を回避または削減するために、またＵｕインターフェースを介して送信にまだ成功していないデータパケットに関して、サービングＤｅＮＢおよびＲＮのバッファを同期させ続けるために、交換される。制御メッセージは、定期的に、またはトリガに基づいて、送信することができる。制御メッセージは、たとえばＰＤＣＰ制御ＰＤＵを使用してユーザプレーンに送信されてもよい。あるいは、制御メッセージは、無線リソース制御（ＲＲＣ）もしくはＸ２ＡＰ、またはＲＮとサービングＤｅＮＢの間の通信用の任意の他の同様に規定されたインターフェースを使用して、制御プレーンに送信されてもよい。
【００２４】
制御メッセージは、最初の（すなわち最も古い）送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵシーケンス番号（ＳＮ）（すなわち、ＲＮからＷＴＲＵへの送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵの最初のＳＮ）を含むことができる。ＲＬＣ ＡＭデータの場合において、「送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ」は、Ｕｕインターフェースを介してＷＴＲＵによって成功裏に受信されたと確認されていない、Ｕｕ ＰＤＣＰ ＳＤＵに対応するＵｎ ＰＤＣＰ ＳＤＵを意味している。ＲＬＣ ＵＭデータの場合において、「送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ」は、ＲＮにてまだＵｕインターフェースを介して送信するためにＰＤＣＰレイヤから下位のレイヤに提出されていない、またはＭＡＣレイヤでハイブリッド自動再送要求（ＨＡＲＱ）機構によって肯定的に確認されていないＵｕ ＰＤＣＰ ＰＤＵに対応するＵｎ ＰＤＣＰ ＳＤＵを意味している。ＲＬＣ透過モード（ＴＭ）データの場合では、「送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ」は、ＲＮにてまだＵｕインターフェースを介して送信するためにＰＤＣＰレイヤから下位のレイヤに提出されていないＵｕ ＰＤＣＰ ＰＤＵに対応するＵｎ ＰＤＣＰ ＳＤＵを意味している。代替として、または追加的に、制御メッセージは、Ｕｎインターフェースを介してＲＮへの送信を開始／増大または停止／減少させるための指示を含むことができる。
【００２５】
ＲＮは、図２〜図９に示されているように、ＰＤＣＰエンティティの１つのセットをＵｕインターフェース上で、またＰＤＣＰエンティティのもう１つのセットをＵｎインターフェース上で維持することができ、これらのセットは、互いに独立して動作することができる。ＲＮとサービングＤｅＮＢの間でフロー制御するために、ＲＮ（および任意選択でサービングＤｅＮＢ）は、Ｕｕインターフェースを介してＷＴＲＵに送信されるＵｕ ＰＤＣＰ ＰＤＵのＳＮと、Ｕｎインターフェースを介してサービングＤｅＮＢから受信されるＵｎ ＰＤＣＰ ＰＤＵとの間のＳＮ間のマッピングを維持することができる。
【００２６】
マッピングは、各ＵｕインターフェースＰＤＣＰ ＳＮを、対応するＵｎインターフェースＰＤＣＰ ＳＮに関連した、またはその逆に関連付けした、ルックアップテーブルを使用して、実行することができる。２つのシーケンス番号の関連付けられた値は、同じでない可能性があり、その理由は、シーケンス番号付けが、ＵｎインターフェースまたはＵｕインターフェース上でいつでも、上限（たとえば、４０９５）に達する前に、他方が引き続き動作している間に再スタートすることができるからである。あるいは、シーケンス番号間の関連付けは、ＵｎインターフェースＰＤＣＰ ＳＮとＵｕインターフェースＰＤＣＰ ＳＮの間の１組のオフセットを維持する変換テーブルを介して行われてもよい。変換テーブルは、単一のオフセットまたは複数のオフセットを含むことができる。
【００２７】
ＰＤＣＰエンティティが複数のＰＤＣＰ ＳＤＵ（たとえば、ＩＰパケット）を１つのＰＤＣＰ ＰＤＵに連結すること、または単一のＰＤＣＰ ＳＤＵを複数のＰＤＣＰ ＰＤＵにセグメンとする（分ける）ことが許される場合、ＵｎインターフェースＰＤＣＰ ＳＮをＵｕインターフェースＰＤＣＰ ＳＮと関連付けるために、またはその逆で関連付けるために、ルックアップテーブルを使用することができる。
【００２８】
ＲＮ（および任意選択でサービングＤｅＮＢ）は、ターゲットハンドオーバへ転送させる必要がある正しいパケットがサービングＤｅＮＢで識別できるように、Ｕｕインターフェースを介してＲＮによって送信されるデータおよびＵｎインターフェースを介して受信されたデータのＳＮの適正な変換、及びその逆の変換を、このマッピングを使用して確実にすることができる。代替として、またはそれに加えて、制御メッセージは、最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮがあってもなくても、データフローの開始／増大または停止／減少を示すことができる。
【００２９】
さらに、ＤｅＮＢは、ＰＤＣＰ ＳＤＵとＰＤＣＰ ＰＤＵ間のマッピングを維持することができる。ダウンリンク送信の場合、ＤｅＮＢは、ＰＤＣＰ ＳＤＵ（たとえば、ＩＰパケット）を１つのＰＤＣＰ ＰＤＵ内に含めることができる。この場合、マッピングは、１対１のマッピングとすることができる。あるいは、ＤｅＮＢは、（単一のＷＴＲＵまたは複数のＷＴＲＵに対して指定された）複数のＰＤＣＰ ＳＤＵを１つのＰＤＣＰ ＰＤＵに連結する、または１つのＰＤＣＰ ＳＤＵが複数のＰＤＣＰ ＰＤＵに含まれるように１つのＰＤＣＰ ＳＤＵを複数のセグメントに分けることができる。この場合、マッピングは、多対１のマッピングとすることができる。このマッピングのために、各ＰＤＣＰ ＳＤＵ（またはそのセグメント）と各ＰＤＣＰ ＰＤＵには、異なるシーケンス番号（ＳＮ）を割り当てることができ、ＤｅＮＢは、関連付けられたマッピングでＰＤＣＰ ＳＤＵを追跡することができる。同様に、ＲＮは、ＰＤＣＰ ＳＤＵと、Ｕｕインターフェースを介して送信されるＰＤＣＰ ＰＤＵ間のマッピングを維持することができる。
【００３０】
マッピング（または上述のマッピングの任意の組合せ）により、ＤｅＮＢは、ＲＮバッファの輻輳（混雑）または枯渇（スターベイション）が発生したかどうかを判断することができ、このマッピング情報を使用し、ハンドオーバ中のデータ再転送を最小限に抑えることができる。
【００３１】
この実施形態によれば、サービングＤｅＮＢは、ＲＮからの制御メッセージによって、まだＵｕインターフェースを介して送信に成功したと確認されていないＵｎ ＰＤＣＰ ＳＤＵすべて（すなわち、ＲＬＣ ＵＭデータの場合、ＲＮにて、送信するために下位のレイヤに提出されていない、またはＨＡＲＱエンティティによって肯定的に確認されていないＰＤＣＰ ＰＤＵ、およびＲＬＣ ＡＭデータの場合、ＲＬＣレイヤによって受信に成功したと肯定的に確認されていないＰＤＣＰ ＳＤＵ）を持ち続けることができる。ソースＤｅＮＢが制御メッセージを受信した後で、最初の送信に成功しなかったＰＤＣＰ ＳＤＵよりも古い（１つまたは複数の）Ｕｎ ＰＤＣＰ ＳＤＵをソースＤｅＮＢバッファから破棄することができる。
【００３２】
フロー制御は、ＷＴＲＵごと、ＷＴＲＵ ＥＰＳベアラごと、ＲＮ ＥＰＳベアラごと、または他の任意のものごとに実施することができる。ＷＴＲＵごとの制御の場合、ＲＮは、特定のＷＴＲＵについて最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵを、ソースＤｅＮＢに示す。ＷＴＲＵ ＥＰＳベアラごとの場合、ＲＮは、特定のＷＴＲＵ ＥＰＳベアラ内で最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵを、ソースＤｅＮＢに示す。
【００３３】
個々のＷＴＲＵ ＥＰＳベアラごと、またはＷＴＲＵごとのフロー制御は、サービングＤｅＮＢにおいて、ＷＴＲＵ ＥＰＳベアラ／Ｕｕデータ無線ベアラ（ＤＲＢ）とＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間のマッピングまたは関連付けの知識、およびその関連付けからＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢを導出できることを必要とする。この関連付けは、プロトコルアーキテクチャ次第で、サービングＤｅＮＢに既知であることも、既知でないこともある。たとえば、ＤｅＮＢにとってトランスペアレントなＲＮでＳ１インターフェースが終了する場合、この関連付けはサービングＤｅＮＢに知られていないことがある。一実施形態によれば、ＷＴＲＵに対するＥＰＳベアラ／Ｕｕ ＤＲＢ確立の一部として、ＲＮ（あるいは、ＭＭＥ、ＧＷ、もしくはこれらのノードの任意の組合せ、または（１つまたは複数の）他のノード）は、ソースＤｅＮＢに、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間の関連付けまたはマッピングを含むコンテキスト情報を伝えることができる。ＷＴＲＵコンテキスト情報は、コンテキストＩＤとすることができる。あるいは、ＷＴＲＵコンテキスト情報は、ＷＴＲＵコンテキストＩＤを、（１つまたは複数の）ＷＴＲＵベアラおよび（１つまたは複数の）ＲＮベアラに関する情報ならびにそれらのマッピング／関連付けと共に含むことができる。
【００３４】
マッピング情報は、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢ確立後に、サービングＤｅＮＢに送られる専用のメッセージを使用してやり取りすることができる。ＲＮは、ＷＴＲＵ ＥＰＳベアラ／ＤＲＢとＵｎインターフェースＥＰＳベアラ／ＤＲＢ間の関連付けまたはマッピング情報を、ＥＰＳベアラ／Ｕｕ ＤＲＢ確立中またはその確立後に、ＭＭＥ／ＧＷを介してサービングＤｅＮＢに伝えることができる。
【００３５】
サービングＤｅＮＢは、ＷＴＲＵのためのコンテキストを作成し、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間のマッピングを維持することができる。ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間のマッピングが確立した後で、ソースＤｅＮＢは、受信した制御メッセージを特定のＰＤＣＰプロセスに関連付けることができる。サービングＤｅＮＢは、ＲＮに行く予定の各パケットを調べることができ、ハンドオーバ要求メッセージにコンテキストが含まれているＷＴＲＵ宛のパケットを停止することができる。これは、サービングＤｅＮＢからＲＮへの冗長なデータ転送を回避する助けとなる。
【００３６】
ＰＤＣＰ制御ＰＤＵ交換を介したフロー制御の場合では、ソースＤｅＮＢは、受信したＰＤＣＰ制御ＰＤＵを、ＭＡＣヘッダ内容に基づいて所与のＤＲＢに関連付けられた特定のＰＤＣＰプロセスに対して関連付けることができる。非ＷＴＲＵ多重化（ｎｏｎ−ＷＴＲＵ ｍｕｌｔｉｐｌｅｘｉｎｇ）の場合でのＭＡＣヘッダは、ＬＴＥリリース８ＭＡＣヘッダと同じであるとしてよい。
【００３７】
制御プレーンＲＲＣまたはＸ２ＡＰシグナリングを使用するフロー制御の場合、シグナリングメッセージは、最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮに加えて、Ｕｕ ＲＢ ＩＤ、ＷＴＲＵコンテキストＩＤ、およびＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢ ＩＤとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ ＩＤ間のマッピング情報などの情報を任意選択で含むことができる。
【００３８】
（１つまたは複数の）関連のベアラ用の、（１つまたは複数の）ＲＮバッファ（すなわち、メモリ２４３内に割り当てられたＲＮバッファ）は、Ｕｎインターフェースを制御メッセージでオーバフローさせる危険性を最小限に抑えながら比較的小さく設計することができる。たとえば、バッファサイズは、フロー制御される特定のベアラについて予想される伝送時間間隔（ＴＴＩ）あたりの平均データ量の関数として設定することができる。ＴＴＩ＿ＢｕｆｆｅｒはＴＴＩあたり予想されるデータの平均量であり、「α」は乗率（倍率）であるため、ＲＮでバッファされるデータの量は、ＴＴＩ＿Ｂｕｆｆｅｒにαを乗じたものに等しくなり得る。この乗率は、データ相当の数ＴＴＩがＲＮによってバッファされるように設定することができる。特定のベアラについてＴＴＩあたり予想されるデータの平均量は、保証ビットレートベアラの場合、保証ビットレート（ＧＢＲ）または上限ビットレート（ＭＢＲ）などＱｏＳパラメータに関して導出することができる。非保証ビットレートベアラの場合、総合最大ビットレート（ＡＭＢＲ）を使用することができる。たとえば、ＡＭＢＲを非保証ビットレートベアラの数で除し、各非保証ビットレートベアラに対して予想される最大データ転送速度を得ることができ、一方、ＧＢＲは、ある保証ビットレートベアラに対して予想される平均データ転送速度のプロキシ（ｐｒｏｘｙ：代理）として使用することができる。
【００３９】
図１２を再び参照すると、ＷＴＲＵは、定期的に、またはトリガのいずれかに基づいて、設定されたソースＲＮに測定レポートを送ることができる（５０６）。ソースＲＮは、測定レポートに基づいて、ハンドオーバする決定を行い（５０８）、ハンドオーバ要求メッセージ（Ｘ２ＡＰまたはＲＲＣメッセージ）をサービングＤｅＮＢに送る（５１０）。ハンドオーバ要求メッセージは、最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ ＳＮを含むことができる。あるいは、ハンドオーバ要求メッセージの前後に、別個のメッセージを介して、最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ ＳＮを送ることができる。ソースＲＮは、このメッセージを使用し、ターゲットハンドオーバノードに転送すべきＰＤＣＰ ＳＤＵ ＳＮをサービングＤｅＮＢに通知する。サービングＤｅＮＢは、示されたＳＮから開始してそれから先のＳＮを有するパケットを破棄することができない。
【００４０】
ＲＮは、ハンドオーバ要求メッセージと共に、ＷＴＲＵコンテキスト情報をサービングＤｅＮＢに送ることができる。コンテキスト情報は、単にコンテキストＩＤとすることも、あるいはＷＴＲＵベアラ、ＲＮベアラ、およびそれらのマッピングを伴うＷＴＲＵコンテキストＩＤとすることもできる。サービングＤｅＮＢは、ＷＴＲＵコンテキスト情報に基づいて、ハンドオーバをトリガしているＷＴＲＵに属する（１つまたは複数の）データフローを識別する。サービングＤｅＮＢは、ＲＮに行く各パケットを調べ、ハンドオーバ要求メッセージにコンテキストが含まれるＷＴＲＵ宛のパケットを停止することができる。これは、冗長なデータ転送を回避する助けとなる。
【００４１】
任意選択で、ソースＲＮは、ソースＲＮからサービングＤｅＮＢに戻る冗長なデータ転送を回避するために、ハンドオーバの開始をサービングＤｅＮＢに通知することができる。というのは、（ハンドオーバ要求メッセージは、プロトコルアーキテクチャに応じてサービングＤｅＮＢにとってトランスペアレントであり得るので）ＷＴＲＵに対するハンドオーバが開始されたことをサービングＤｅＮＢが知らない可能性があり、サービングＤｅＮＢがデータをソースＲＮに転送し続ける可能性があるからである。また、この方法は、ハンドオーバの開始前にＤｅＮＢによってＲＮに送られたデータをＤｅＮＢに再転送することを回避するように設計されている。
【００４２】
サービングＤｅＮＢは、ハンドオーバ要求メッセージをターゲットｅＮＢに転送する（５１２）。ターゲットｅＮＢは、アドミッション制御を実施する（５１４）。リソースをターゲットｅＮＢによって与えることができる場合、ターゲットｅＮＢによって、ＥＰＳベアラのサービス品質（ＱｏＳ）情報に基づいてアドミッション制御を実施し、ハンドオーバ成功の可能性を高めることができる。ターゲットｅＮＢは、受信されたＥＰＳベアラＱｏＳ情報に従って、必要とされるリソースを設定し、セル無線ネットワークの一時的な識別子（Ｃ−ＲＮＴＩ）などのような、リソースをリザーブ（確保）する。
【００４３】
ターゲットｅＮＢは、ハンドオーバ要求ＡＣＫメッセージをサービングＤｅＮＢに送る（５１６）。ハンドオーバ要求ＡＣＫメッセージは、ハンドオーバを実施するためにＲＲＣメッセージとしてＷＴＲＵに送られることになるトランスペアレントなコンテナを含む。このコンテナは、新しいＣ−ＲＮＴＩ、選択されたセキュリティアルゴリズム用のターゲットｅＮＢセキュリティアルゴリズム識別子、専用ランダムアクセスチャネル（ＲＡＣＨ）プリアンブルなど、パラメータを含むことができる。
【００４４】
サービングＤｅＮＢは、ハンドオーバ要求ＡＣＫメッセージ、あるいはハンドオーバコマンドメッセージ（Ｘ２ＡＰまたはＲＲＣメッセージ）をＲＮに送ることができる（５１８）。ハンドオーバ要求ＡＣＫメッセージ（あるいは、ハンドオーバコマンドメッセージ）は、サービングＤｅＮＢによって破棄されなかったＵｎ ＰＤＣＰ ＳＤＵの最初の（すなわち、最も古い）ＳＮ（すなわち、サービングＤｅＮＢでのデータバッファリングの開始点）を含むことができる。
【００４５】
この情報は、ハンドオーバの場合にどのＰＤＣＰ ＳＤＵ（１つまたは複数）が転送される必要があるかを判断するために、ＲＮによって使用されることができる。ＲＮは、この情報を使用し、ＲＮからサービングＤｅＮＢに転送して返される必要があるパケットが依然としてあるかどうか判断することができる。ＲＮは、ターゲットハンドオーバノード（たとえば、ターゲットｅＮＢ）に、ハンドオーバ要求ＡＣＫメッセージ（またはハンドオーバコマンド）内に示されたＳＮの直前のＳＮを有するパケットまで、以前に受信された、ＷＴＲＵへの送信に成功しなかったパケットすべてを転送することができる。ハンドオーバ要求ＡＣＫメッセージ（またはハンドオーバコマンド）内に示されたＳＮは、ＲＮによってハンドオーバ要求メッセージ（または制御メッセージ）内に示された、最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮと同じであり得る。この情報は、ハンドオーバ要求ＡＣＫメッセージまたはハンドオーバコマンドの前後に別個のメッセージを介して送信されてもよい。ＲＮは、この情報がハンドオーバ要求ＡＣＫメッセージまたはハンドオーバコマンド内に含まれていない場合、このＳＮを暗黙のうちに導出することができる。
【００４６】
ＲＮは、ハンドオーバコマンドメッセージをＷＴＲＵに送る（５２０）。ＲＮがその送信機および受信機をフリーズ（凍結）して、ＷＴＲＵにデータを送信することを停止した、またはＷＴＲＵからのデータを受信することを停止した後で、ＲＮは、サービングＤｅＮＢを介して（あるいは直接に）ターゲットｅＮＢにＳＮステータス転送メッセージを送ることができる（５２２、５２４）。従来の３ＧＰＰ Ｒ８ Ｘ２ＡＰ ＳＮステータス転送メッセージを再使用することも、Ｘ２ＡＰ ＳＮステータス転送メッセージと同様の内容を有する新しいＲＲＣ ＳＮステータス転送メッセージを使用することもできる。
【００４７】
ＳＮステータス転送メッセージは、ＰＤＣＰステータス保存（プリザベイション）が適用されるＥ−ＲＡＢのアップリンクＰＤＣＰ ＳＮ受信機ステータスおよびダウンリンクＰＤＣＰ ＳＮ送信機ステータスを伝える（すなわち、ＲＬＣ ＡＭの場合）。アップリンクＰＤＣＰ ＳＮ受信機ステータスは、少なくとも最初の失ったＵＬ ＳＤＵのＰＤＣＰ ＳＮを含む。ダウンリンクＰＤＣＰ ＳＮ送信機ステータスは、ターゲットｅＮＢが新しいＳＤＵに割り当てることを必要とする次のＰＤＣＰ ＳＮを示す。一実施形態によれば、ＳＮステータス転送メッセージは、最初の送信に成功しなかったダウンリンクＵｎ ＰＤＣＰ ＳＤＵ ＳＮを含むことができる。あるいは、この情報は、サービングＤｅＮＢを最新の情報で更新するためにＳＮステータス転送メッセージの前後に発行される別個の制御メッセージを介して送ることができ、その結果、ＲＮは、転送される必要があるまさにそのダウンリンクデータを転送することができる。ハンドオーバを支援するフロー制御（またはＲＮ対ＤｅＮＢのバッファ同期）により、サービングＤｅＮＢは、ハンドオーバ時に、ＲＮバッファ内のすべてのＵｎインターフェースＰＤＣＰ ＳＤＵを有し、おそらくはＵｕインターフェースを介してすでに成功裏に送信された追加のＰＤＣＰ ＳＤＵを有することができる。ＳＮステータス転送メッセージを拡張する目的は、サービングＤｅＮＢによる冗長なデータ転送を最小限に抑えることである。
【００４８】
サービングＤｅＮＢは、データをターゲットｅＮＢに転送する（５２６）。ダウンリンクデータの場合、サービングＤｅＮＢは、ＲＮによってレポートされた、最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵから開始してそのバッファ内のＰＤＣＰ ＳＤＵすべてを転送することができる。最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ ＳＮは、ＲＮからのＳＮステータス転送メッセージから導出することも、ＳＮステータス転送メッセージの一部として、または別個のメッセージで、サービングＤｅＮＢに明示的にシグナリングすることもできる。フロー制御における停止／減少および開始／増大指示を使用する場合には、ソースＤｅＮＢは、Ｕｎインターフェースを介してまだ送達されていないＰＤＣＰ ＳＤＵすべてを転送することができ、ＲＮは、Ｕｎインターフェースを介して受信されたがＵｕインターフェースを介した送信にまだ成功していないＰＤＣＰ ＰＤＵ（またはＳＤＵ）すべてを転送することができる。
【００４９】
ＷＴＲＵは、ターゲットｅＮＢとの同期を実施し、ＲＡＣＨを介してターゲットセルにアクセスし、ターゲットｅＮＢは、ＵＬ割当ておよびタイミングアドバンスで応答し、ＷＴＲＵがターゲットセルへのアクセスに成功したとき、ＷＴＲＵは、ＲＲＣハンドオーバ完了メッセージを送る（５２８）。
【００５０】
ターゲットｅＮＢは、経路切替要求メッセージをＭＭＥ／ＧＷに送り、ＷＴＲＵがセルを変更したことを通知する（５３０）。サービングＧＷは、ダウンリンクデータ経路をターゲットｅＮＢに切り替え、１つまたは複数のＳ１−ＵＰエンドマーカパケットを元の経路上でソースＲＮおよび／またはソースＤｅＮＢに送り、次いでＵプレーン／トランスポートネットワークレイヤ（ＴＮＬ）リソースをソースＲＮに向かって解放する（５３２、５３４）。
【００５１】
ＭＭＥは、経路切替ＡＣＫメッセージで経路切替要求メッセージを確認する（５３６）。ＭＭＥから経路切替ＡＣＫメッセージを受信した後で、ターゲットｅＮＢは、ハンドオーバの成功を通知しソースＤｅＮＢによるリソースの解放をトリガするために、コンテキスト解放メッセージをソースＤｅＮＢに送る（５３８）。ソースＤｅＮＢは、コンテキスト解放メッセージを受信すると、ＲＲＣ接続再構成メッセージをソースＲＮに送り、ソースＲＮは、ＲＲＣ接続再構成応答メッセージで応答する（５４０、５４２）。
【００５２】
図１３は、他の実施形態に従ってＲＮが展開されるネットワーク内でのハンドオーバのための例示的なプロセス６００の流れ図である。この実施形態では、ソースＲＮからサービングＤｅＮＢに戻る最小または最も少ない量のダウンリンクデータ転送でハンドオーバが実施され、サービングＤｅＮＢからソースＲＮへ、冗長なデータ転送が削減または回避される。この例では、ＷＴＲＵが現在ＲＮ（ソースＲＮ）に接続されており、別のｅＮＢ（ターゲットｅＮＢ）にハンドオーバされつつあることが想定されている。この実施形態は、他のシナリオにも適用可能であることに留意されたい。
【００５３】
呼セットアップ中に、ＷＴＲＵ ＥＰＳベアラおよびＵｕ ＲＢ、ならびにＲＮ ＥＰＳベアラおよびＵｎインターフェースＲＢが確立され、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＲＢ間のマッピングまたは関連付けが確立される（６０２）。ＲＮは、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＲＢ間のマッピングまたは関連付けを維持する。マッピングは、一意のＷＴＲＵコンテキストＩＤ、（１つまたは複数の）ＲＮベアラ（たとえば、ＩＰソースアドレス、ＩＰ宛先アドレス、ＵＤＰソースポート、ＵＤＰ宛先ポート、トンネルエンドポイントＩＤ）、（１つまたは複数の）ＷＴＲＵベアラ（たとえば、ＩＰソースアドレス、ＩＰ宛先アドレス、ＵＤＰソースポート、ＵＤＰ宛先ポート、トンネルエンドポイントＩＤ）、（１つまたは複数の）ＲＮベアラＩＤ、（１つまたは複数の）ＷＴＲＵベアラＩＤに基づいて維持することができる。これは、任意のプロトコルアーキテクチャのいずれかに適用可能である。
【００５４】
ＤｅＮＢにとってトランスペアレントなＲＮでＳ１インターフェースが終了する場合、この関連付けはサービングＤｅＮＢに知られていないことがある。一実施形態によれば、ＷＴＲＵに対するＥＰＳベアラ／Ｕｕ ＤＲＢ確立の一部として、ＲＮ、ＭＭＥ、ＧＷ、またはこれら３つのノードの任意の組合せは、ソースＤｅＮＢに、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間の関連付けまたはマッピングを含むコンテキスト情報を伝えることができる。ＷＴＲＵコンテキスト情報は、コンテキストＩＤとすることができる。代替として、ＷＴＲＵコンテキスト情報は、ＷＴＲＵコンテキストＩＤを、（１つまたは複数の）ＷＴＲＵベアラ、（１つまたは複数の）ＲＮベアラ、およびそれらのマッピングと共に、含むことができる。
【００５５】
マッピング情報は、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢ確立の後に、サービングＤｅＮＢに送られる専用のメッセージを使用してやり取りすることができる。ＲＮは、ＷＴＲＵ ＥＰＳベアラ／ＤＲＢとＵｎインターフェースＥＰＳベアラ／ＤＲＢ間の関連付けまたはマッピング情報を、ＥＰＳベアラ／Ｕｕ ＤＲＢ確立中にＭＭＥ／ＧＷを介してサービングＤｅＮＢを使って伝えることができる。
【００５６】
サービングＤｅＮＢは、ＷＴＲＵのためのコンテキストを作成し、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間のマッピングを維持することができる。ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間のマッピングが確立した後で、ソースＤｅＮＢは、受信された制御メッセージを特定のＰＤＣＰプロセスに関連付けることができる。サービングＤｅＮＢは、ＲＮに行く各パケットを調べることができ、ハンドオーバ要求メッセージにコンテキストが含まれるＷＴＲＵ宛のパケットを停止することができる。これは、サービングＤｅＮＢからＲＮへの冗長なデータ転送を回避する助けとなる。
【００５７】
マッピング情報は、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢ確立後に、サービングＤｅＮＢに送られる専用のメッセージを使用して、ＲＮ（またはＭＭＥまたはＧＷ）とサービングＤｅＮＢの間で交換することができる。ＲＮはまた、ＷＴＲＵ ＥＰＳベアラ／ＤＲＢとＵｎインターフェースＥＰＳベアラ／ＤＲＢ間の関連付けまたはマッピング情報を、ＥＰＳベアラ／Ｕｕ ＤＲＢ確立中にＭＭＥ／ＧＷを介してサービングＤｅＮＢを使って伝えることができる。
【００５８】
ＲＮは、ＰＤＣＰエンティティの一方のセットをＵｕインターフェース上で、またＰＤＣＰエンティティの他方のセットをＵｎインターフェース上で維持することができ、これらのセットは、互いに独立して動作することができる。ＲＮおよびサービングＤｅＮＢは、Ｕｕインターフェースを介してＷＴＲＵに送信されるＵｕ ＰＤＣＰ ＰＤＵのＳＮと、Ｕｎインターフェースを介してサービングＤｅＮＢからＲＮによって受信されたＵｎ ＰＤＣＰ ＰＤＵのＳＮ間のマッピングを維持する。
【００５９】
マッピングは、各ＵｕインターフェースＰＤＣＰ ＳＮをＵｎインターフェースＰＤＣＰ ＳＮと関連付ける、またはその逆に関連付けるルックアップテーブルを使用して実施することができる。２つのシーケンス番号の関連付けられた値は、同じでない可能性がある。というのは、シーケンス番号付けは、ＵｎインターフェースまたはＵｕインターフェース上でいつでも、上限（たとえば、４０９５）に達する前に、他方が引き続き動作している間に再スタートすることができるからである。あるいは、シーケンス番号間の関連付けは、ＵｎインターフェースＰＤＣＰ ＳＮとＵｕインターフェースＰＤＣＰ ＳＮの間の１組のオフセットを維持する変換テーブルを介して行われてもよい。変換テーブルは、単一のオフセットまたは複数のオフセットを含むことができる。
【００６０】
あるいは、ＰＤＣＰエンティティが複数のＩＰパケットを１つのＰＤＣＰ ＰＤＵに連結すること、または単一のＰＤＣＰ ＳＤＵを複数のＰＤＣＰ ＰＤＵに分けることが許される場合、ＵｎインターフェースＰＤＣＰ ＳＮをＵｕインターフェースＰＤＣＰ ＳＮと関連付けるために、またはその逆に関連付けるために、ルックアップテーブルを使用することができる。
【００６１】
ＲＮ（および任意選択でサービングＤｅＮＢ）は、このマッピングを使用し、ターゲットハンドオーバノードに転送されることを必要とする正しいパケットをサービングＤｅＮＢにて識別することができるように、Ｕｕインターフェースを介してＲＮによって送信されるデータのＳＮとＵｎインターフェースを介して受信されたデータの適正な変換、およびその逆の変換を確実にすることができる。
【００６２】
さらに、ＤｅＮＢは、ＰＤＣＰ ＳＤＵとＰＤＣＰ ＰＤＵ間のマッピングを維持することができる。ダウンリンク送信の場合、ＤｅＮＢは、ＰＤＣＰ ＳＤＵ（すなわち、ＩＰパケット）を１つのＰＤＣＰ ＰＤＵ内に含めることができる。この場合、マッピングは、１対１のマッピングとすることができる。あるいは、ＤｅＮＢは、（単一のＷＴＲＵまたは複数のＷＴＲＵに対して指定された）複数のＰＤＣＰ ＳＤＵを１つのＰＤＣＰ ＰＤＵに連結する、または１つのＰＤＣＰ ＳＤＵが複数のＰＤＣＰ ＰＤＵに含まれるように１つのＰＤＣＰ ＳＤＵを複数のセグメントに分けることができる。この場合、マッピングは、多対１のマッピングとすることができる。このマッピングのために、各ＰＤＣＰ ＳＤＵ（またはそのセグメント）と各ＰＤＣＰ ＰＤＵには、異なるシーケンス番号（ＳＮ）を割り当てることができ、ＤｅＮＢは、関連付けられたマッピングでＰＤＣＰ ＳＤＵを追跡することができる。同様に、ＲＮは、ＰＤＣＰ ＳＤＵと、Ｕｕインターフェースを介して送信されるＰＤＣＰ ＰＤＵ間のマッピングを維持することができる。
【００６３】
マッピング（または上述のマッピングの任意の組合せ）により、ＤｅＮＢは、ＲＮバッファ輻輳または枯渇が発生したかどうか判断することができ、このマッピング情報を使用し、ハンドオーバ中にデータ再転送を最小限に抑えることができる。
【００６４】
ＷＴＲＵは、定期的に、またはトリガに基づいて、設定されているようにソースＲＮに測定レポートを送ることができる（６０４）。ソースＲＮは、測定レポートに基づいて、ハンドオーバの決定を行い（６０６）、ハンドオーバ要求メッセージ（Ｘ２ＡＰまたはＲＲＣ）をサービングＤｅＮＢに送る（６０８）。
【００６５】
ハンドオーバ要求メッセージは、データのバッファリングを開始するようにサービングＤｅＮＢに指示するように拡張されてもよい（すなわち、ＲＮに送られたダウンリンクデータを破棄しない）。ハンドオーバ要求メッセージは、最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ ＳＮを含むことができる。あるいは、ハンドオーバ要求メッセージの前後に、別個のメッセージを介して、データバッファリング要求指示または最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮを送ることができる。ソースＲＮは、このメッセージを使用し、ターゲットハンドオーバノードに転送すべきＳＮおよび対応するＰＤＣＰ ＳＤＵをサービングＤｅＮＢに通知することができる。データバッファリング要求指示または最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮを受け取ると、サービングＤｅＮＢは、パケットを破棄することができず、示されたＳＮから始まるＳＮを有するデータをバッファするのを開始することができる。これは、ハンドオーバが開始された後で、ＲＮによる冗長なデータ再転送（すなわち、サービングＤｅＮＢによって送られたＤＬデータをサービングＤｅＮＢに再転送して返すこと）を回避するために実施される。
【００６６】
ＲＮは、ハンドオーバ要求メッセージと共に、ＷＴＲＵコンテキスト情報をサービングＤｅＮＢに送ることができる。ＷＴＲＵコンテキスト情報は、単にコンテキストＩＤとすることも、あるいは（１つまたは複数の）ＷＴＲＵベアラおよび（１つまたは複数の）ＲＮベアラ、ならびにそれらのマッピング／関連付けの情報を伴うＷＴＲＵコンテキストＩＤとすることもできる。サービングＤｅＮＢは、ＷＴＲＵコンテキスト情報に基づいて、ハンドオーバがトリガされつつあるＷＴＲＵに属する（１つまたは複数の）データフローを識別することができる。サービングＤｅＮＢは、ＲＮに行く各パケットを調べ、ハンドオーバ要求メッセージにコンテキストが含まれるＷＴＲＵ宛のパケットを停止することができる。これは、冗長なデータ転送を回避する助けとなる。
【００６７】
サービングＤｅＮＢは、ハンドオーバ要求メッセージをターゲットｅＮＢに転送する（６１０）。ターゲットｅＮＢは、アドミッション制御を実施する（６１２）。リソースをターゲットｅＮＢによって与えることができる場合、ターゲットｅＮＢによって、ＥＰＳベアラのサービス品質（ＱｏＳ）情報に基づいてアドミッション制御を実施し、ハンドオーバ成功の可能性を高めることができる。ターゲットｅＮＢは、受信されたＥＰＳベアラＱｏＳ情報に従って、必要とされるリソースを設定し、セル無線ネットワークの一時的な識別子（Ｃ−ＲＮＴＩ）などのような、リソースをリザーブ（確保）する。
【００６８】
ターゲットｅＮＢは、ハンドオーバ要求ＡＣＫメッセージをサービングＤｅＮＢに送る。ハンドオーバ要求ＡＣＫメッセージは、ハンドオーバを実施するためにＲＲＣメッセージとしてＷＴＲＵに送られることになるトランスペアレントなコンテナを含む。このコンテナは、新しいＣ−ＲＮＴＩ、選択されたセキュリティアルゴリズム用のターゲットｅＮＢセキュリティアルゴリズム識別子、専用ＲＡＣＨプリアンブルなどの、パラメータを含むことができる。
【００６９】
サービングＤｅＮＢは、ハンドオーバ要求ＡＣＫメッセージ、あるいはハンドオーバコマンドメッセージ（Ｘ２ＡＰまたはＲＲＣ）をＲＮに送ることができる（６１６）。ハンドオーバ要求ＡＣＫメッセージ（あるいは、ハンドオーバコマンドメッセージ）は、ソースＤｅＮＢがデータのバッファリングを開始したところのＳＮを含むことができる。このＳＮは、ＲＮによって提供された最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮよりも古くてもよい。この情報は、ハンドオーバの場合にどのＰＤＣＰ ＳＤＵが転送される必要があるかを判断するために、ＲＮが使用することができる。ハンドオーバ要求ＡＣＫメッセージ内に示されたＳＮは、ソースＲＮによってハンドオーバ要求メッセージ内に示されたＳＮと同じであってもよい。この情報は、ハンドオーバ要求ＡＣＫメッセージの後または前に個別に送ることができる。
【００７０】
ＲＮは、ハンドオーバコマンドメッセージをＷＴＲＵに送る（６１８）。ＲＮがその送信機および受信機をフリーズ（凍結）して、データをＷＴＲＵへ送信すること、またはＷＴＲＵからデータを受信することを停止した後で、ＲＮは、サービングＤｅＮＢを介してターゲットｅＮＢにＳＮステータス転送メッセージを送ることができる（６２０、６２２）。従来型の３ＧＰＰ Ｒ８ Ｘ２ＡＰ ＳＮステータス転送メッセージを再使用することも、あるいはＸ２ＡＰ ＳＮステータス転送メッセージと同様の内容を有する新しいＲＲＣ ＳＮステータス転送メッセージを定義することもできる。
【００７１】
ＳＮステータス転送メッセージは、ＰＤＣＰステータス保存が適用されるＥ−ＲＡＢのアップリンクＰＤＣＰ ＳＮ受信機ステータスおよびダウンリンクＰＤＣＰ ＳＮ送信機ステータスを搬送する（すなわち、ＲＬＣ ＡＭの場合）。アップリンクＰＤＣＰ ＳＮ受信機ステータスは、少なくとも次の予想される順番内の（ｉｎ−ｓｅｑｕｅｎｃｅ）アップリンクサービスデータユニットのＰＤＣＰ ＳＮを含む。ダウンリンクＰＤＣＰ ＳＮ送信機ステータスは、ターゲットｅＮＢが新しいＳＤＵに割り当てることを必要とする次のＰＤＣＰ ＳＮを示す。一実施形態によれば、ＳＮステータス転送メッセージは、最初の送信に成功しなかったダウンリンクＵｎインターフェースＰＤＣＰ ＳＤＵ ＳＮを含むことができる。あるいは、この情報は、サービングＤｅＮＢを最新の情報で更新するためにＳＮステータス転送メッセージの前後に発行される別個のメッセージを介して送ることができ、その結果、ＲＮは、転送される必要があるまさにそのダウンリンクデータを転送することができる。
【００７２】
ソースＲＮは、データをサービングＤｅＮＢに、またはターゲットｅＮＢに直接転送する（６２４、６２６）。ダウンリンクデータ転送が、必要とされ、かつＤｅＮＢがそのバッファ内に持っているＵｎインターフェースを介してすでに送信されたデータの情報（ｋｎｏｗｌｅｄｇｅ）に基づく場合には、ソースＲＮは、サービングＤｅＮＢバッファ内に存在しないＰＤＣＰ ＳＤＵを転送することができる。Ｕｎインターフェースを介してすでに送信されたデータをソースＤｅＮＢが持っていないことをソースＲＮが知っている場合には、ソースＲＮは、Ｕｕインターフェースを介してＷＴＲＵへの送信にまだ成功していない、Ｕｎインターフェースを介して受信されたＳＤＵすべてを転送することができる。
【００７３】
ダウンリンクデータの場合、サービングＤｅＮＢは、ＲＮにより報告された最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵから開始したそのバッファ内に、すべてのＰＤＣＰ ＳＤＵを転送する（６２８）。最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮは、ＲＮからのＳＮステータス転送メッセージから導出することも、ＳＮステータス転送メッセージの一部として、または別個のメッセージで、サービングＤｅＮＢに明示的にシグナリングすることもできる。
【００７４】
ＷＴＲＵは、ターゲットｅＮＢとの同期を実施し、ＲＡＣＨを介してターゲットセルにアクセスし、ターゲットｅＮＢは、ＵＬ割当ておよびタイミングアドバンスで応答し、ＷＴＲＵがターゲットセルへのアクセスに成功したとき、ＷＴＲＵは、ＲＲＣハンドオーバ完了メッセージを送る（６３０）。
【００７５】
ターゲットｅＮＢは、経路切替要求メッセージをＭＭＥ／ＧＷに送り、ＷＴＲＵがセルを変更したことを通知する（６３２）。サービングＧＷは、ダウンリンクデータ経路をターゲットｅＮＢに切り替え、１つまたは複数のＳ１−ＵＰエンドマーカパケットを元の経路上でソースＲＮおよび／またはソースＤｅＮＢに送り、次いでＵプレーン／ＴＮＬリソースをソースＲＮに向かって解放する（６３４、６３６）。
【００７６】
ＭＭＥは、経路切替応答メッセージで経路切替要求メッセージを確認する（６３８）。ＭＭＥから経路切替ＡＣＫメッセージを受信した後で、ターゲットｅＮＢは、ハンドオーバの成功を通知して、ソースＤｅＮＢによるリソースの解放をトリガするために、コンテキスト解放メッセージをソースＤｅＮＢに送る（６４０）。ソースＤｅＮＢは、コンテキスト解放メッセージを受信すると、ＲＲＣ接続再構成メッセージをソースＲＮに送り、ソースＲＮは、ＲＲＣ接続再構成応答メッセージで応答する（６４２、６４４）。
【００７７】
これらの実施形態は、ＷＴＲＵが任意のノードから任意のノードへ、たとえばソースＲＮから、そのソースＲＮを制御するサービングＤｅＮＢ、またはサービングＤｅＮＢもしくは隣接するｅＮＢのいずれかによって制御される別のＲＮへ、ハンドオーバされるハンドオーバシナリオ（状況、筋書き）にも同様に適用可能であることに留意されたい。これらの実施形態は、ダウンリンクとアップリンクの両方に適用可能であることにも留意されたい。
【００７８】
実施形態
１．ＲＮとのハンドオーバを実施することを特徴とする方法。
【００７９】
２．ＲＮがＤｅＮＢからＰＤＣＰ ＰＤＵを受信するステップを含むことを特徴とする実施形態１に記載の方法。
【００８０】
３．前記ＲＮがＷＴＲＵに前記ＰＤＣＰ ＰＤＵを送信するステップを含むことを特徴とする実施形態２に記載の方法。
【００８１】
４．前記ＲＮが前記ＷＴＲＵから測定レポートを受信するステップを含むことを特徴とする実施形態３に記載の方法。
【００８２】
５．前記ＲＮが前記測定レポートに基づいてハンドオーバの決定を行うステップを含むことを特徴とする実施形態４に記載の方法。
【００８３】
６．前記ＲＮが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含む情報と共にハンドオーバ要求メッセージを前記ＤｅＮＢに転送するステップを含むことを特徴とする実施形態５に記載の方法。
【００８４】
７．前記ＲＮが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて制御メッセージを前記ＤｅＮＢに送るステップをさらに含むことを特徴とする実施形態２〜６のいずれか１つに記載の方法。
【００８５】
８．前記ＲＮが、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＤｅＮＢからハンドオーバ要求応答メッセージを受信するステップをさらに含むことを特徴とする実施形態６〜７のいずれか１つに記載の方法。
【００８６】
９．前記ＲＮが、前記ＤｅＮＢから受信された情報に基づいて前記ＤｅＮＢにＰＤＣＰ ＰＤＵを転送するステップをさらに含むことを特徴とする実施形態８に記載の方法。
【００８７】
１０．前記ＲＮは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供することを特徴とする実施形態６〜９のいずれか１つに記載の方法。
【００８８】
１１．前記ＲＮは、前記ＲＮと前記ＷＴＲＵの間の無線インターフェースを介して前記ＷＴＲＵに送信されたデータのＰＤＣＰ ＳＮと、前記ＲＮと前記ＤｅＮＢの間の無線インターフェースを介して前記ＲＮによって受信されたデータのＰＤＣＰ ＳＮとの間のマッピングのテーブルを維持することを特徴とする実施形態３〜１０のいずれか１つに記載の方法。
【００８９】
１２．前記ＲＮが、呼セットアップ中に、ＷＴＲＵコンテキストＩＤ、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するステップをさらに含むことを特徴とする実施形態２〜１１のいずれか１つに記載の方法。
【００９０】
１３．無線通信用であることを特徴とするＲＮ。
【００９１】
１４．アンテナを備えることを特徴とする実施形態１３に記載のＲＮ。
【００９２】
１５．ＤｅＮＢから受信し、ＷＴＲＵに送信するように構成されたトランシーバを備えることを特徴とする実施形態１３〜１４のいずれか１つに記載のＲＮ。
【００９３】
１６．前記ＤｅＮＢからＰＤＣＰ ＰＤＵを受信し、前記ＰＤＣＰ ＰＤＵを前記ＷＴＲＵに送信し、前記ＷＴＲＵから受信された測定レポートに基づいてハンドオーバの決定を行い、最初の送信に成功しなかったＰＤＣＰ ＳＮを含む情報と共にハンドオーバ要求メッセージを前記ＤｅＮＢに送るように構成されたプロセッサを備えることを特徴とする実施形態１５に記載のＲＮ。
【００９４】
１７．前記プロセッサは、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて制御メッセージを前記ＤｅＮＢに送るように構成されていることを特徴とする実施形態１６に記載のＲＮ。
【００９５】
１８．前記プロセッサは、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＤｅＮＢからハンドオーバ要求応答メッセージを受信し、前記ＤｅＮＢから受信された情報に基づいて前記ＤｅＮＢにＰＤＣＰ ＰＤＵを転送するように構成されていることを特徴とする実施形態１６〜１７のいずれか１つに記載のＲＮ。
【００９６】
１９．前記プロセッサは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するように構成されていることを特徴とする実施形態１６〜１８のいずれか１つに記載のＲＮ。
【００９７】
２０．前記プロセッサは、前記ＲＮと前記ＷＴＲＵの間の無線インターフェースを介して前記ＷＴＲＵに送信されたデータのＰＤＣＰ ＳＮと、前記ＲＮと前記ＤｅＮＢの間の無線インターフェースを介して前記ＲＮによって受信されたデータのＰＤＣＰ ＳＮとの間のマッピングのテーブルを維持するように構成されていることを特徴とする実施形態１６〜１９のいずれか１つに記載のＲＮ。
【００９８】
２１．前記プロセッサは、呼セットアップ中に、ＷＴＲＵコンテキストＩＤ、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するように構成されていることを特徴とする実施形態１６〜２０のいずれか１つに記載のＲＮ。
【００９９】
２２．ＲＮとのハンドオーバを実施することを特徴とする方法。
【０１００】
２３．ノードＢがＰＤＣＰ ＰＤＵをＲＮに送るステップを含むことを特徴とする実施形態２２に記載の方法。
【０１０１】
２４．前記ノードＢが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含む情報と共に前記ＲＮからハンドオーバ要求メッセージを受信するステップを含み、前記ノードＢは、前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄することを特徴とする実施形態２３に記載の方法。
【０１０２】
２５．前記ノードＢが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて前記ＲＮから制御メッセージを受信するステップを含み、前記ノードＢは、前記制御メッセージを介して示された前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄することを特徴とする実施形態２３〜２４のいずれか１つに記載の方法。
【０１０３】
２６．前記ノードＢが、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＲＮにハンドオーバ要求応答メッセージを送るステップをさらに含むことを特徴とする実施形態２４〜２５のいずれか１つに記載の方法。
【０１０４】
２７．前記ノードＢは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を受信することを特徴とする実施形態２４〜２６のいずれか１つに記載の方法。
【０１０５】
２８．前記ノードＢが、呼セットアップ中に、ＷＴＲＵコンテキストＩＤ、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を受信するステップをさらに含むことを特徴とする実施形態２４〜２７のいずれか１つに記載の方法。
【０１０６】
２９．前記ノードＢが、ＷＴＲＵベアラとＲＮベアラ間のマッピングを確立するステップを含むことを特徴とする実施形態２８に記載の方法。
【０１０７】
３０．前記ノードＢがＳ１−ＵＰエンドマーカパケットを受信するステップをさらに含むことを特徴とする実施形態２４〜２９のいずれか１つに記載の方法。
【０１０８】
３１．ＲＮとのハンドオーバを実施することを特徴とするノードＢ。
【０１０９】
３２．アンテナを備えることを特徴とする実施形態３１に記載のノードＢ。
【０１１０】
３３．ＲＮと無線で通信するように構成されたトランシーバを備えることを特徴とする実施形態３１〜３２のいずれか１つに記載のノードＢ。
【０１１１】
３４．前記ＲＮにＰＤＣＰ ＰＤＵを送り、最初の送信に成功しなかったＰＤＣＰ ＳＮを含む情報と共に前記ＲＮからハンドオーバ要求メッセージを受信するように構成されたプロセッサを備え、前記プロセッサは、前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄することを特徴とする実施形態３３に記載のノードＢ。
【０１１２】
３５．前記プロセッサは、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて前記ＲＮから制御メッセージを受信し、前記制御メッセージを介して示された前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄するように構成されていることを特徴とする実施形態３４に記載のノードＢ。
【０１１３】
３６．前記プロセッサは、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＲＮにハンドオーバ要求応答メッセージを送るように構成されていることを特徴とする実施形態３４〜３５のいずれか１つに記載のノードＢ。
【０１１４】
３７．前記プロセッサは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を受信することを特徴とする実施形態３４〜３６のいずれか１つに記載のノードＢ。
【０１１５】
３８．前記プロセッサは、呼セットアップ中に、ＷＴＲＵコンテキストＩＤ、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を受信し、ＷＴＲＵベアラとＲＮベアラ間のマッピングを確立するように構成されていることを特徴とする実施形態３４〜３７のいずれか１つに記載のノードＢ。
【０１１６】
３９．前記プロセッサは、Ｓ１−ＵＰエンドマーカパケットを受信するように構成されていることを特徴とする実施形態３４〜３８のいずれか１つに記載のノードＢ。
【０１１７】
上記では特徴および要素が特定の組合せで述べられているが、各特徴および要素は、他の特徴および要素なしの単独で、または他の特徴および要素のある、もしくは他の特徴および要素のない様々な組合せで使用することができる。本明細書において提供されている方法または流れ図は、汎用コンピュータまたはプロセッサによって実行するためのコンピュータ可読記憶媒体内に組み込まれるコンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読記憶媒体の例は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクや取外し式ディスクなど磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多目的ディスク（ＤＶＤ）など光媒体を含む。
【０１１８】
好適なプロセッサは、例として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、特定用途用標準品（ＡＳＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、ならびに任意の他のタイプの集積回路（ＩＣ）、および／または状態機械を含む。
【０１１９】
ソフトウェアに関連付けられたプロセッサを使用し、無線送信／受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、端末、基地局、無線通信移動管理装置（ＭＭＥ）もしくは拡張パケットコア（ＥＰＣ）、または任意のホストコンピュータ内で使用するための無線周波数トランシーバを実装することができる。ＷＴＲＵは、ソフトウェア無線（ＳＤＲ）を含めてハードウェアおよび／またはソフトウェアで実装されるモジュールと共に、またカメラ、ビデオカメラモジュール、テレビ電話、スピーカフォン、振動デバイス、スピーカ、マイクロフォン、テレビトランシーバ、ハンドフリー用ハンドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、近距離無線通信（ＮＦＣ）モジュール、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット、有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および／または任意の無線構内通信網（ＷＬＡＮ）もしくは超広帯域（ＵＷＢ）モジュールなど他の構成要素と共に使用することができる。
【技術分野】
【０００１】
本願は、無線通信に関する。
【背景技術】
【０００２】
関連出願の相互参照
本願は、２００９年６月１７日に出願された米国特許仮出願第６１／１８７，８０９号および２００９年６月１７日に出願された米国特許仮出願第第６１／１８７，８７９号の利益を主張するものであり、これらの特許出願を、完全に記載されているかのように参照により組み込む。
【０００３】
拡張ロングタームエボリューション（ＬＴＥ−Ａ）では、中継ノード（ＲＮ）の概念が導入されている。ＲＮは、高度化ノードＢ（ｅＮＢ）（すなわち、基地局）と無線送信／受信ユニット（ＷＴＲＵ）の間に配備されるノードである。ＲＮは、ｅＮＢおよびＷＴＲＵのうちの一方からデータを受信し、それを他方に転送する。ＲＮへの、またＲＮからのＷＴＲＵのリンク（回線）品質は、ＲＮの方がＷＴＲＵに近いためｅＮＢとの間の直接リンクよりも良いものとなるであろう、したがってｅＮＢとＷＴＲＵの間のリンクの性能は、ＲＮを導入することによって高まるであろう。
【０００４】
ＲＮは、カバレージ（受信可能範囲サービスエリア）の改善が必要とされるときに、ｅＮＢを設置することに対しての低コストな選択肢であることを狙いとしているが、無線ネットワークの容量を改善するために使用することもできる。コスト削減は、ネットワークに対する有線リンクに付随する資本経費および事業費を削減することによって達成される。有線リンクに代わって、ＲＮは、ネットワークに対してのリンク（回線）を提供する「ドナーｅＮＢ（ＤｅＮＢ）」に無線を用いて通信する。レガシーＷＴＲＵ（すなわち、第３世代移動体通信システムの標準化プロジェクト（３ＧＰＰ）リリース９またはそれ以前のＷＴＲＵ）にとって、ＲＮは、ちょうどｅＮＢのように見える。図１は、ＤｅＮＢと共にＲＮの例示的な配備を示し、ＲＮとＤｅＮＢとに関連するインターフェースをも示す。
【０００５】
ＬＴＥ−Ａ（拡張ロングタームエボリューション）でＲＮを配備する場合には、ＲＮとｅＮＢの間にハンドオーバが発生する可能性がある。以下のハンドオーバシナリオが予期され、すなわち、ＷＴＲＵが、ＲＮからそれ自体のサービングドナー高度化ノードＢ（ｅＮＢ）に移動すること、ＷＴＲＵが、ＲＮから隣接するドナー高度化ノードＢに移動すること、ＷＴＲＵが、あるＲＮから、同じドナー高度化ノードＢによってサービスの提供を受ける別のＲＮに移動すること、ＷＴＲＵが、あるＲＮから、隣接するドナー高度化ノードＢによってサービスの提供を受ける別のＲＮに移動すること、ＷＴＲＵが、ドナー高度化ノードＢから、同じドナー高度化ノードＢによってサービスの提供を受けるＲＮに移動すること、ＷＴＲＵが、隣接するドナー高度化ノードＢから、異なるドナー高度化ノードＢによってサービスの提供を受けるＲＮに移動すること、などが予期される。
【０００６】
ＷＴＲＵをＲＮから（別のＲＮ、またはＤｅＮＢのいずれかへ）ハンドオーバする必要があるとき、無線リンク制御（ＲＬＣ）非応答モード（ＵＭ）の場合には、まだダウンリンクでのＲＮの送信がＲＬＣによって完了されていない、ＲＮ内のパケットデータ収束プロトコル（ＰＤＣＰ）サービスデータユニット（ＳＤＵ）を、無線バックホール（ｂａｃｋｈａｕｌ：帰路）リンクを介してＤｅＮＢに転送する必要がある。ＲＬＣ応答（アクノリッジ）モード（ＡＭ）の場合は、ダウンリンク送信の場合で、送信することができなかったＰＤＣＰ ＳＤＵに加えて、ＲＮが、ＷＴＲＵによってＲＬＣレイヤにて成功裏に確認（アクノリッジ）されていないＰＤＣＰ ＳＤＵをも転送しなければならない。これらのデータパケットの再転送の事例が必須となるが、それは、バックホールリンク（Ｕｎ）とアクセスリンク（Ｕｕ）の両方が、自立して動作し、図２〜図９に示されているように別々のピアツゥピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）データリンクレベル伝送プロトコルスタックを実装することを考えると、ＤｅＮＢが、ＲＮに前に送信されたＰＤＣＰ ＳＤＵを削除している可能性があるからである。データの再転送は、バックホールリソースを２回消耗する（すなわち、ＤｅＮＢからＲＮにデータを送信するのに使用されるリソースと、ＲＮからＤｅＮＢにデータを再送信するのに使用されるリソース）。
【０００７】
ＬＴＥ−Ａにおいて考えられているユーザプレーン（Ｕプレーン）および制御プレーン（Ｃプレーン）のプロトコルアーキテクチャの例示が図２〜図９に示されている。図２および図３は、ＤｅＮＢにとってトランスペアレント（透過的）であるフルＬ３リレーのためのＣプレーンアーキテクチャおよびＵプレーンアーキテクチャを示す。図４および図５は、プロキシＳ１／Ｘ２のためのＣプレーンアーキテクチャおよびＵプレーンアーキテクチャを示す（すなわち、ＲＮは、無線通信移動管理装置（ＭＭＥ）にとってＤｅＮＢ下のセルのように見える）。図６および図７は、ＲＮベアラがＲＮで終了する場合のＣプレーンアーキテクチャおよびＵプレーンアーキテクチャを示す。図８および図９は、Ｓ１インターフェースがＤｅＮＢで終了するＣプレーンアーキテクチャおよびＵプレーンアーキテクチャを示す。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ハンドオーバ中におけるＲＮからＤｅＮＢへのデータ再転送を削減または回避すること、ハンドオーバ中にもとのサービングＤｅＮＢに再転送する必要があるＤｅＮＢからＲＮに転送されたデータ量を最小限に抑えること、およびＲＮとサービングＤｅＮＢ間での不必要なデータ交換に起因するハンドオーバ完了時間を縮小することが望ましいであろう。
【課題を解決するための手段】
【０００９】
ネットワーク内でＲＮとハンドオーバを実施するための実施形態を開示する。ＲＮは、ｅＮＢとＷＴＲＵの間に配備されるノードである。ＲＮは、ｅＮＢおよびＷＴＲＵのうちの一方からデータを受信し、それを他方に転送する。ＲＮは、ＷＴＲＵから受信された測定レポートに基づいてハンドオーバの決定をすることができる。ハンドオーバを決定した後で、ＲＮは、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含めて、ハンドオーバ要求または制御メッセージをサービングＤｅＮＢに送る。次いで、サービングＤｅＮＢは、最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵ（パッケトデータユニット）を破棄する。
【００１０】
ＲＮおよびサービングＤｅＮＢは、ＲＮとＷＴＲＵの間の無線インターフェースを介してＷＴＲＵに送信されたデータのＰＤＣＰ ＳＮと、ＲＮとサービングＤｅＮＢの間の無線インターフェースを介してＲＮによって受信されたデータのＰＤＣＰ ＳＮ間のマッピングのテーブルを維持することができる。ＲＮは、呼セットアップ中に、ＷＴＲＵコンテキストアイデンティティ（ＩＤ）、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報をサービングＤｅＮＢに提供することができる。
【００１１】
サービングＤｅＮＢは、ハンドオーバ要求メッセージをターゲットｅＮＢに転送する。ターゲットｅＮＢは、アドミッション制御を実施する。ターゲットｅＮＢは、ハンドオーバ要求ＡＣＫメッセージをサービングＤｅＮＢに送る。サービングＤｅＮＢは、データをターゲットｅＮＢに転送する。ＷＴＲＵは、ターゲットｅＮＢとの同期を実施し、ＲＡＣＨを介してターゲットセルにアクセスし、ターゲットｅＮＢは、ＵＬ割当ておよびタイミングアドバンスで応答し、ＷＴＲＵがターゲットセルへのアクセスに成功したとき、ＷＴＲＵは、ＲＲＣハンドオーバ完了メッセージを送る。ターゲットｅＮＢは、経路切替要求メッセージをＭＭＥ／ＧＷに送り、ＷＴＲＵがセルを変更したことを通知する。サービングＧＷは、ダウンリンクデータ経路をターゲットｅＮＢに切り替え、元の経路上の１つまたは複数のＳ１−ＵＰエンドマーカパケットをソースＲＮおよび／またはソースＤｅＮＢに送り、次いでＵプレーン／トランスポートネットワークレイヤ（ＴＮＬ）リソースをソースＲＮに対して解放する。
【００１２】
より詳細な理解を、添付の図面と共に、例として与えられている以下の説明から得ることができる。
【図面の簡単な説明】
【００１３】
【図１】例示的なリレー配備アーキテクチャを示す。
【図２】ＬＴＥ−Ａにおいて考えられているＣプレーンプロトコルアーキテクチャの例を示す図である。
【図３】ＬＴＥ−Ａにおいて考えられているＵプレーンプロトコルアーキテクチャの例を示す図である。
【図４】ＬＴＥ−Ａにおいて考えられているＣプレーンプロトコルアーキテクチャの例を示す図である。
【図５】ＬＴＥ−Ａにおいて考えられているＵプレーンプロトコルアーキテクチャの例を示す図である。
【図６】ＬＴＥ−Ａにおいて考えられているＣプレーンプロトコルアーキテクチャの例を示す図である。
【図７】ＬＴＥ−Ａにおいて考えられているＵプレーンプロトコルアーキテクチャの例を示す図である。
【図８】ＬＴＥ−Ａにおいて考えられているＣプレーンプロトコルアーキテクチャの例を示す図である。
【図９】ＬＴＥ−Ａにおいて考えられているＵプレーンプロトコルアーキテクチャの例を示す図である。
【図１０】拡張地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）を含むＬＴＥ無線通信システム／アクセスネットワークの図である。
【図１１】ＷＴＲＵ、ｅＮＢ、およびＲＮを含むＬＴＥ無線通信システムの例示的なブロック図である。
【図１２】一実施形態に従ってＲＮが展開されるネットワーク内でのハンドオーバの例示的なプロセスを示す図である。
【図１３】他の実施形態に従ってＲＮが展開されるネットワーク内でのハンドオーバのための例示的なプロセスの流れ図である。
【発明を実施するための形態】
【００１４】
「ＷＴＲＵ」という用語は、以下で参照されたとき、それだけには限らないが、ユーザ機器（ＵＥ）、移動局、固定型もしくは移動型加入者ユニット、ページャ（ポケットベル）、セルラ電話、携帯情報端末（ＰＤＡ）、コンピュータ、センサ、マシーン−ツ−マシーン（Ｍ２Ｍ）のデバイス、または無線環境内で動作することが可能な任意の他のタイプのデバイスを含む。「高度化ノードＢ（ｅＮＢ）」「ＤｅＮＢ」または「ＲＮ」という用語は、以下で参照されたとき、それだけには限らないが、基地局、サイトコントローラ、アクセスポイント（ＡＰ）、または無線環境内で動作することが可能な任意の他のタイプのインターフェース用デバイスを含む。
【００１５】
３ＧＰＰ ＬＥＴおよびＬＴＥ−Ａに関連して実施形態が開示されているが、これらの実施形態はＬＥＴまたはＬＴＥ−Ａに限定されず、それだけには限らないが、３ＧＰＰ広帯域符号分割多元接続（ＷＣＤＭＡ）、ＣＤＭＡ２０００、ＩＥＥＥ８０２．ＸＸなどを含めて、現在存在する、または将来配備されることができる任意の無線通信技術に適用可能であることに留意されたい。本明細書に記載されている諸実施形態は、任意の順序または組合せで適用可能とすることができ、実施形態の任意の特定の部分は、その実施形態の残りの部分なしに独立して実施することができることに留意されたい。本明細書で開示されている実施形態は、現在論じられている、または将来開発されることになるＲＮを含めて、任意のプロトコルアーキテクチャで実施することができることに留意されたい。
【００１６】
図１０は、拡張地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）２０５を含むＬＴＥ無線通信システム／アクセスネットワーク２００を示す。Ｅ−ＵＴＲＡＮ２０５は、いくつかのｅＮＢ２２０と、少なくとも１つのＲＮ２４０とを含む。ＷＴＲＵ２１０は、ｅＮＢ２２０またはＲＮ２４０のいずれかと通信することができる。ｅＮＢ２２０は、Ｘ２インターフェースを使用して互いにインターフェースする。ｅＮＢ２２０のそれぞれは、Ｓ１インターフェースを介して無線通信移動管理装置（ＭＭＥ）／サービングゲートウェイ（Ｓ−ＧＷ）２３０とインターフェースする。ｅＮＢ２２０は、Ｕｎインターフェースを使用してＲＮとインターフェースする。ＲＮ２４０またはｅＮＢ２２０は、Ｕｕインターフェースを使用してＷＴＲＵ２１０とインターフェースする。単一のＷＴＲＵ２１０、３つのｅＮＢ２２０、および単一のＲＮ２４０が図１０に示されているが、任意の数のデバイスが存在してもよく、無線デバイスと有線デバイスの任意の組合せが無線通信システムアクセスネットワーク２００に含まれてもよいということは明らかなはずである。
【００１７】
図１１は、ＷＴＲＵ２１０、ｅＮＢ２２０、およびＲＮ２４０を含むＬＴＥ無線通信システム４００の例示的なブロック図である。ＷＴＲＵ２１０、ｅＮＢ２２０、およびＲＮ２４０は、本明細書で開示されている実施形態に従って、無線通信、フロー制御、およびハンドオーバを実施するように構成されている。
【００１８】
ＷＴＲＵ２１０は、典型的なＷＴＲＵに見出すことができる構成要素に加えて、少なくとも１つのトランシーバ２１１と、任意選択で接続されるメモリ２１３を有するプロセッサ２１２と、アンテナ２１４とを含む。プロセッサ２１２は、単独またはソフトウェアとの組合せで、本明細書で開示されている実施形態に従って、無線通信、フロー制御、およびハンドオーバを実施するように構成される。トランシーバ２１１は、プロセッサ２１２およびアンテナ２１４と通信して、無線通信の送信および受信を容易にする。ＷＴＲＵ２１０は、ｅＮＢ２２０またはＲＮ２４０のいずれか一方と通信することができる。
【００１９】
ｅＮＢ２２０は、典型的なｅＮＢに見出すことができる構成要素に加えて、少なくとも１つのトランシーバ２２１と、任意選択で接続されるメモリ２２３を有するプロセッサ２２２と、アンテナ２２４とを含む。プロセッサ２２２は、単独またはソフトウェアとの組合せで、本明細書で開示されている実施形態に従って、無線通信、フロー制御、およびハンドオーバを実施するように構成される。トランシーバ２２１は、プロセッサ２２２およびアンテナ２２４と通信して、無線通信の送信および受信を容易にする。
【００２０】
ＲＮ２４０は、少なくとも１つのトランシーバ２４１と、任意選択で接続されるメモリ２４３を有するプロセッサ２４２と、アンテナ２４４とを含む。プロセッサ２４２は、単独またはソフトウェアとの組合せで、本明細書で開示されている実施形態に従って、無線通信、フロー制御、およびハンドオーバを実施するように構成される。トランシーバ２４１は、プロセッサ２４２およびアンテナ２４４と通信して、無線通信の送信および受信を容易にする。
【００２１】
図１２は、一実施形態に従ってＲＮが展開されるネットワーク内でのハンドオーバの例示的なプロセス（一連の処理過程）５００を示す。この例では、ＷＴＲＵが現在はＲＮ（ソースＲＮ）に接続されているが、別のｅＮＢ（ターゲットｅＮＢ）にハンドオーバされつつあるのを想定している。呼セットアップ（呼設定）中に、ＷＴＲＵ高度化パケットシステム（ＥＰＳ）ベアラおよびＵｕ無線ベアラ（ＲＢ）、ならびにＲＮ ＥＰＳベアラおよびＵｎインターフェースＲＢが確立され、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＲＢ間のマッピングまたは関連付けが確立される（５０２）。ＷＴＲＵ ＥＰＳベアラは、ＷＴＲＵとパケットデータネットワークゲートウェイ（Ｐ−ＧＷ）の間に確立されるベアラであり、ＲＮ ＥＰＳベアラは、ＲＮとＰ−ＧＷの間に確立されるベアラである。Ｕｕ ＲＢは、Ｕｕインターフェースを介してＷＴＲＵとＲＮの間に確立されるベアラであり、Ｕｎ ＲＢは、Ｕｎインターフェースを介してＲＮとソースＤｅＮＢの間に確立されるベアラである。
【００２２】
ＲＮは、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＲＢ間のマッピングまたは関連付けを維持することができる。マッピングは、一意のＷＴＲＵコンテキストＩＤ、（１つまたは複数の）ＲＮベアラ（たとえば、インターネットプロトコル（ＩＰ）ソースアドレス、ＩＰ宛先アドレス、ユーザデータグラムプロトコル（ＵＤＰ）ソースポート、ＵＤＰ宛先ポート、トンネルエンドポイントＩＤ）、（１つまたは複数の）ＷＴＲＵベアラ（たとえば、ＩＰソースアドレス、ＩＰ宛先アドレス、ＵＤＰソースポート、ＵＤＰ宛先ポート、トンネルエンドポイントＩＤ）、（１つまたは複数の）ＲＮベアラＩＤ、（１つまたは複数の）ＷＴＲＵベアラＩＤに基づいて維持することができる。これは、図２〜図９におけるプロトコルアーキテクチャのいずれかに適用可能である。
【００２３】
この実施形態によれば、ＲＮは、サービングＤｅＮＢと制御メッセージを交換する。制御メッセージは、ハンドオーバ中に、ＲＮからサービングＤｅＮＢに再転送で返される必要があるデータ量を回避または削減するために、またＵｕインターフェースを介して送信にまだ成功していないデータパケットに関して、サービングＤｅＮＢおよびＲＮのバッファを同期させ続けるために、交換される。制御メッセージは、定期的に、またはトリガに基づいて、送信することができる。制御メッセージは、たとえばＰＤＣＰ制御ＰＤＵを使用してユーザプレーンに送信されてもよい。あるいは、制御メッセージは、無線リソース制御（ＲＲＣ）もしくはＸ２ＡＰ、またはＲＮとサービングＤｅＮＢの間の通信用の任意の他の同様に規定されたインターフェースを使用して、制御プレーンに送信されてもよい。
【００２４】
制御メッセージは、最初の（すなわち最も古い）送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵシーケンス番号（ＳＮ）（すなわち、ＲＮからＷＴＲＵへの送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵの最初のＳＮ）を含むことができる。ＲＬＣ ＡＭデータの場合において、「送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ」は、Ｕｕインターフェースを介してＷＴＲＵによって成功裏に受信されたと確認されていない、Ｕｕ ＰＤＣＰ ＳＤＵに対応するＵｎ ＰＤＣＰ ＳＤＵを意味している。ＲＬＣ ＵＭデータの場合において、「送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ」は、ＲＮにてまだＵｕインターフェースを介して送信するためにＰＤＣＰレイヤから下位のレイヤに提出されていない、またはＭＡＣレイヤでハイブリッド自動再送要求（ＨＡＲＱ）機構によって肯定的に確認されていないＵｕ ＰＤＣＰ ＰＤＵに対応するＵｎ ＰＤＣＰ ＳＤＵを意味している。ＲＬＣ透過モード（ＴＭ）データの場合では、「送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ」は、ＲＮにてまだＵｕインターフェースを介して送信するためにＰＤＣＰレイヤから下位のレイヤに提出されていないＵｕ ＰＤＣＰ ＰＤＵに対応するＵｎ ＰＤＣＰ ＳＤＵを意味している。代替として、または追加的に、制御メッセージは、Ｕｎインターフェースを介してＲＮへの送信を開始／増大または停止／減少させるための指示を含むことができる。
【００２５】
ＲＮは、図２〜図９に示されているように、ＰＤＣＰエンティティの１つのセットをＵｕインターフェース上で、またＰＤＣＰエンティティのもう１つのセットをＵｎインターフェース上で維持することができ、これらのセットは、互いに独立して動作することができる。ＲＮとサービングＤｅＮＢの間でフロー制御するために、ＲＮ（および任意選択でサービングＤｅＮＢ）は、Ｕｕインターフェースを介してＷＴＲＵに送信されるＵｕ ＰＤＣＰ ＰＤＵのＳＮと、Ｕｎインターフェースを介してサービングＤｅＮＢから受信されるＵｎ ＰＤＣＰ ＰＤＵとの間のＳＮ間のマッピングを維持することができる。
【００２６】
マッピングは、各ＵｕインターフェースＰＤＣＰ ＳＮを、対応するＵｎインターフェースＰＤＣＰ ＳＮに関連した、またはその逆に関連付けした、ルックアップテーブルを使用して、実行することができる。２つのシーケンス番号の関連付けられた値は、同じでない可能性があり、その理由は、シーケンス番号付けが、ＵｎインターフェースまたはＵｕインターフェース上でいつでも、上限（たとえば、４０９５）に達する前に、他方が引き続き動作している間に再スタートすることができるからである。あるいは、シーケンス番号間の関連付けは、ＵｎインターフェースＰＤＣＰ ＳＮとＵｕインターフェースＰＤＣＰ ＳＮの間の１組のオフセットを維持する変換テーブルを介して行われてもよい。変換テーブルは、単一のオフセットまたは複数のオフセットを含むことができる。
【００２７】
ＰＤＣＰエンティティが複数のＰＤＣＰ ＳＤＵ（たとえば、ＩＰパケット）を１つのＰＤＣＰ ＰＤＵに連結すること、または単一のＰＤＣＰ ＳＤＵを複数のＰＤＣＰ ＰＤＵにセグメンとする（分ける）ことが許される場合、ＵｎインターフェースＰＤＣＰ ＳＮをＵｕインターフェースＰＤＣＰ ＳＮと関連付けるために、またはその逆で関連付けるために、ルックアップテーブルを使用することができる。
【００２８】
ＲＮ（および任意選択でサービングＤｅＮＢ）は、ターゲットハンドオーバへ転送させる必要がある正しいパケットがサービングＤｅＮＢで識別できるように、Ｕｕインターフェースを介してＲＮによって送信されるデータおよびＵｎインターフェースを介して受信されたデータのＳＮの適正な変換、及びその逆の変換を、このマッピングを使用して確実にすることができる。代替として、またはそれに加えて、制御メッセージは、最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮがあってもなくても、データフローの開始／増大または停止／減少を示すことができる。
【００２９】
さらに、ＤｅＮＢは、ＰＤＣＰ ＳＤＵとＰＤＣＰ ＰＤＵ間のマッピングを維持することができる。ダウンリンク送信の場合、ＤｅＮＢは、ＰＤＣＰ ＳＤＵ（たとえば、ＩＰパケット）を１つのＰＤＣＰ ＰＤＵ内に含めることができる。この場合、マッピングは、１対１のマッピングとすることができる。あるいは、ＤｅＮＢは、（単一のＷＴＲＵまたは複数のＷＴＲＵに対して指定された）複数のＰＤＣＰ ＳＤＵを１つのＰＤＣＰ ＰＤＵに連結する、または１つのＰＤＣＰ ＳＤＵが複数のＰＤＣＰ ＰＤＵに含まれるように１つのＰＤＣＰ ＳＤＵを複数のセグメントに分けることができる。この場合、マッピングは、多対１のマッピングとすることができる。このマッピングのために、各ＰＤＣＰ ＳＤＵ（またはそのセグメント）と各ＰＤＣＰ ＰＤＵには、異なるシーケンス番号（ＳＮ）を割り当てることができ、ＤｅＮＢは、関連付けられたマッピングでＰＤＣＰ ＳＤＵを追跡することができる。同様に、ＲＮは、ＰＤＣＰ ＳＤＵと、Ｕｕインターフェースを介して送信されるＰＤＣＰ ＰＤＵ間のマッピングを維持することができる。
【００３０】
マッピング（または上述のマッピングの任意の組合せ）により、ＤｅＮＢは、ＲＮバッファの輻輳（混雑）または枯渇（スターベイション）が発生したかどうかを判断することができ、このマッピング情報を使用し、ハンドオーバ中のデータ再転送を最小限に抑えることができる。
【００３１】
この実施形態によれば、サービングＤｅＮＢは、ＲＮからの制御メッセージによって、まだＵｕインターフェースを介して送信に成功したと確認されていないＵｎ ＰＤＣＰ ＳＤＵすべて（すなわち、ＲＬＣ ＵＭデータの場合、ＲＮにて、送信するために下位のレイヤに提出されていない、またはＨＡＲＱエンティティによって肯定的に確認されていないＰＤＣＰ ＰＤＵ、およびＲＬＣ ＡＭデータの場合、ＲＬＣレイヤによって受信に成功したと肯定的に確認されていないＰＤＣＰ ＳＤＵ）を持ち続けることができる。ソースＤｅＮＢが制御メッセージを受信した後で、最初の送信に成功しなかったＰＤＣＰ ＳＤＵよりも古い（１つまたは複数の）Ｕｎ ＰＤＣＰ ＳＤＵをソースＤｅＮＢバッファから破棄することができる。
【００３２】
フロー制御は、ＷＴＲＵごと、ＷＴＲＵ ＥＰＳベアラごと、ＲＮ ＥＰＳベアラごと、または他の任意のものごとに実施することができる。ＷＴＲＵごとの制御の場合、ＲＮは、特定のＷＴＲＵについて最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵを、ソースＤｅＮＢに示す。ＷＴＲＵ ＥＰＳベアラごとの場合、ＲＮは、特定のＷＴＲＵ ＥＰＳベアラ内で最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵを、ソースＤｅＮＢに示す。
【００３３】
個々のＷＴＲＵ ＥＰＳベアラごと、またはＷＴＲＵごとのフロー制御は、サービングＤｅＮＢにおいて、ＷＴＲＵ ＥＰＳベアラ／Ｕｕデータ無線ベアラ（ＤＲＢ）とＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間のマッピングまたは関連付けの知識、およびその関連付けからＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢを導出できることを必要とする。この関連付けは、プロトコルアーキテクチャ次第で、サービングＤｅＮＢに既知であることも、既知でないこともある。たとえば、ＤｅＮＢにとってトランスペアレントなＲＮでＳ１インターフェースが終了する場合、この関連付けはサービングＤｅＮＢに知られていないことがある。一実施形態によれば、ＷＴＲＵに対するＥＰＳベアラ／Ｕｕ ＤＲＢ確立の一部として、ＲＮ（あるいは、ＭＭＥ、ＧＷ、もしくはこれらのノードの任意の組合せ、または（１つまたは複数の）他のノード）は、ソースＤｅＮＢに、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間の関連付けまたはマッピングを含むコンテキスト情報を伝えることができる。ＷＴＲＵコンテキスト情報は、コンテキストＩＤとすることができる。あるいは、ＷＴＲＵコンテキスト情報は、ＷＴＲＵコンテキストＩＤを、（１つまたは複数の）ＷＴＲＵベアラおよび（１つまたは複数の）ＲＮベアラに関する情報ならびにそれらのマッピング／関連付けと共に含むことができる。
【００３４】
マッピング情報は、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢ確立後に、サービングＤｅＮＢに送られる専用のメッセージを使用してやり取りすることができる。ＲＮは、ＷＴＲＵ ＥＰＳベアラ／ＤＲＢとＵｎインターフェースＥＰＳベアラ／ＤＲＢ間の関連付けまたはマッピング情報を、ＥＰＳベアラ／Ｕｕ ＤＲＢ確立中またはその確立後に、ＭＭＥ／ＧＷを介してサービングＤｅＮＢに伝えることができる。
【００３５】
サービングＤｅＮＢは、ＷＴＲＵのためのコンテキストを作成し、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間のマッピングを維持することができる。ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間のマッピングが確立した後で、ソースＤｅＮＢは、受信した制御メッセージを特定のＰＤＣＰプロセスに関連付けることができる。サービングＤｅＮＢは、ＲＮに行く予定の各パケットを調べることができ、ハンドオーバ要求メッセージにコンテキストが含まれているＷＴＲＵ宛のパケットを停止することができる。これは、サービングＤｅＮＢからＲＮへの冗長なデータ転送を回避する助けとなる。
【００３６】
ＰＤＣＰ制御ＰＤＵ交換を介したフロー制御の場合では、ソースＤｅＮＢは、受信したＰＤＣＰ制御ＰＤＵを、ＭＡＣヘッダ内容に基づいて所与のＤＲＢに関連付けられた特定のＰＤＣＰプロセスに対して関連付けることができる。非ＷＴＲＵ多重化（ｎｏｎ−ＷＴＲＵ ｍｕｌｔｉｐｌｅｘｉｎｇ）の場合でのＭＡＣヘッダは、ＬＴＥリリース８ＭＡＣヘッダと同じであるとしてよい。
【００３７】
制御プレーンＲＲＣまたはＸ２ＡＰシグナリングを使用するフロー制御の場合、シグナリングメッセージは、最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮに加えて、Ｕｕ ＲＢ ＩＤ、ＷＴＲＵコンテキストＩＤ、およびＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢ ＩＤとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ ＩＤ間のマッピング情報などの情報を任意選択で含むことができる。
【００３８】
（１つまたは複数の）関連のベアラ用の、（１つまたは複数の）ＲＮバッファ（すなわち、メモリ２４３内に割り当てられたＲＮバッファ）は、Ｕｎインターフェースを制御メッセージでオーバフローさせる危険性を最小限に抑えながら比較的小さく設計することができる。たとえば、バッファサイズは、フロー制御される特定のベアラについて予想される伝送時間間隔（ＴＴＩ）あたりの平均データ量の関数として設定することができる。ＴＴＩ＿ＢｕｆｆｅｒはＴＴＩあたり予想されるデータの平均量であり、「α」は乗率（倍率）であるため、ＲＮでバッファされるデータの量は、ＴＴＩ＿Ｂｕｆｆｅｒにαを乗じたものに等しくなり得る。この乗率は、データ相当の数ＴＴＩがＲＮによってバッファされるように設定することができる。特定のベアラについてＴＴＩあたり予想されるデータの平均量は、保証ビットレートベアラの場合、保証ビットレート（ＧＢＲ）または上限ビットレート（ＭＢＲ）などＱｏＳパラメータに関して導出することができる。非保証ビットレートベアラの場合、総合最大ビットレート（ＡＭＢＲ）を使用することができる。たとえば、ＡＭＢＲを非保証ビットレートベアラの数で除し、各非保証ビットレートベアラに対して予想される最大データ転送速度を得ることができ、一方、ＧＢＲは、ある保証ビットレートベアラに対して予想される平均データ転送速度のプロキシ（ｐｒｏｘｙ：代理）として使用することができる。
【００３９】
図１２を再び参照すると、ＷＴＲＵは、定期的に、またはトリガのいずれかに基づいて、設定されたソースＲＮに測定レポートを送ることができる（５０６）。ソースＲＮは、測定レポートに基づいて、ハンドオーバする決定を行い（５０８）、ハンドオーバ要求メッセージ（Ｘ２ＡＰまたはＲＲＣメッセージ）をサービングＤｅＮＢに送る（５１０）。ハンドオーバ要求メッセージは、最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ ＳＮを含むことができる。あるいは、ハンドオーバ要求メッセージの前後に、別個のメッセージを介して、最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ ＳＮを送ることができる。ソースＲＮは、このメッセージを使用し、ターゲットハンドオーバノードに転送すべきＰＤＣＰ ＳＤＵ ＳＮをサービングＤｅＮＢに通知する。サービングＤｅＮＢは、示されたＳＮから開始してそれから先のＳＮを有するパケットを破棄することができない。
【００４０】
ＲＮは、ハンドオーバ要求メッセージと共に、ＷＴＲＵコンテキスト情報をサービングＤｅＮＢに送ることができる。コンテキスト情報は、単にコンテキストＩＤとすることも、あるいはＷＴＲＵベアラ、ＲＮベアラ、およびそれらのマッピングを伴うＷＴＲＵコンテキストＩＤとすることもできる。サービングＤｅＮＢは、ＷＴＲＵコンテキスト情報に基づいて、ハンドオーバをトリガしているＷＴＲＵに属する（１つまたは複数の）データフローを識別する。サービングＤｅＮＢは、ＲＮに行く各パケットを調べ、ハンドオーバ要求メッセージにコンテキストが含まれるＷＴＲＵ宛のパケットを停止することができる。これは、冗長なデータ転送を回避する助けとなる。
【００４１】
任意選択で、ソースＲＮは、ソースＲＮからサービングＤｅＮＢに戻る冗長なデータ転送を回避するために、ハンドオーバの開始をサービングＤｅＮＢに通知することができる。というのは、（ハンドオーバ要求メッセージは、プロトコルアーキテクチャに応じてサービングＤｅＮＢにとってトランスペアレントであり得るので）ＷＴＲＵに対するハンドオーバが開始されたことをサービングＤｅＮＢが知らない可能性があり、サービングＤｅＮＢがデータをソースＲＮに転送し続ける可能性があるからである。また、この方法は、ハンドオーバの開始前にＤｅＮＢによってＲＮに送られたデータをＤｅＮＢに再転送することを回避するように設計されている。
【００４２】
サービングＤｅＮＢは、ハンドオーバ要求メッセージをターゲットｅＮＢに転送する（５１２）。ターゲットｅＮＢは、アドミッション制御を実施する（５１４）。リソースをターゲットｅＮＢによって与えることができる場合、ターゲットｅＮＢによって、ＥＰＳベアラのサービス品質（ＱｏＳ）情報に基づいてアドミッション制御を実施し、ハンドオーバ成功の可能性を高めることができる。ターゲットｅＮＢは、受信されたＥＰＳベアラＱｏＳ情報に従って、必要とされるリソースを設定し、セル無線ネットワークの一時的な識別子（Ｃ−ＲＮＴＩ）などのような、リソースをリザーブ（確保）する。
【００４３】
ターゲットｅＮＢは、ハンドオーバ要求ＡＣＫメッセージをサービングＤｅＮＢに送る（５１６）。ハンドオーバ要求ＡＣＫメッセージは、ハンドオーバを実施するためにＲＲＣメッセージとしてＷＴＲＵに送られることになるトランスペアレントなコンテナを含む。このコンテナは、新しいＣ−ＲＮＴＩ、選択されたセキュリティアルゴリズム用のターゲットｅＮＢセキュリティアルゴリズム識別子、専用ランダムアクセスチャネル（ＲＡＣＨ）プリアンブルなど、パラメータを含むことができる。
【００４４】
サービングＤｅＮＢは、ハンドオーバ要求ＡＣＫメッセージ、あるいはハンドオーバコマンドメッセージ（Ｘ２ＡＰまたはＲＲＣメッセージ）をＲＮに送ることができる（５１８）。ハンドオーバ要求ＡＣＫメッセージ（あるいは、ハンドオーバコマンドメッセージ）は、サービングＤｅＮＢによって破棄されなかったＵｎ ＰＤＣＰ ＳＤＵの最初の（すなわち、最も古い）ＳＮ（すなわち、サービングＤｅＮＢでのデータバッファリングの開始点）を含むことができる。
【００４５】
この情報は、ハンドオーバの場合にどのＰＤＣＰ ＳＤＵ（１つまたは複数）が転送される必要があるかを判断するために、ＲＮによって使用されることができる。ＲＮは、この情報を使用し、ＲＮからサービングＤｅＮＢに転送して返される必要があるパケットが依然としてあるかどうか判断することができる。ＲＮは、ターゲットハンドオーバノード（たとえば、ターゲットｅＮＢ）に、ハンドオーバ要求ＡＣＫメッセージ（またはハンドオーバコマンド）内に示されたＳＮの直前のＳＮを有するパケットまで、以前に受信された、ＷＴＲＵへの送信に成功しなかったパケットすべてを転送することができる。ハンドオーバ要求ＡＣＫメッセージ（またはハンドオーバコマンド）内に示されたＳＮは、ＲＮによってハンドオーバ要求メッセージ（または制御メッセージ）内に示された、最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮと同じであり得る。この情報は、ハンドオーバ要求ＡＣＫメッセージまたはハンドオーバコマンドの前後に別個のメッセージを介して送信されてもよい。ＲＮは、この情報がハンドオーバ要求ＡＣＫメッセージまたはハンドオーバコマンド内に含まれていない場合、このＳＮを暗黙のうちに導出することができる。
【００４６】
ＲＮは、ハンドオーバコマンドメッセージをＷＴＲＵに送る（５２０）。ＲＮがその送信機および受信機をフリーズ（凍結）して、ＷＴＲＵにデータを送信することを停止した、またはＷＴＲＵからのデータを受信することを停止した後で、ＲＮは、サービングＤｅＮＢを介して（あるいは直接に）ターゲットｅＮＢにＳＮステータス転送メッセージを送ることができる（５２２、５２４）。従来の３ＧＰＰ Ｒ８ Ｘ２ＡＰ ＳＮステータス転送メッセージを再使用することも、Ｘ２ＡＰ ＳＮステータス転送メッセージと同様の内容を有する新しいＲＲＣ ＳＮステータス転送メッセージを使用することもできる。
【００４７】
ＳＮステータス転送メッセージは、ＰＤＣＰステータス保存（プリザベイション）が適用されるＥ−ＲＡＢのアップリンクＰＤＣＰ ＳＮ受信機ステータスおよびダウンリンクＰＤＣＰ ＳＮ送信機ステータスを伝える（すなわち、ＲＬＣ ＡＭの場合）。アップリンクＰＤＣＰ ＳＮ受信機ステータスは、少なくとも最初の失ったＵＬ ＳＤＵのＰＤＣＰ ＳＮを含む。ダウンリンクＰＤＣＰ ＳＮ送信機ステータスは、ターゲットｅＮＢが新しいＳＤＵに割り当てることを必要とする次のＰＤＣＰ ＳＮを示す。一実施形態によれば、ＳＮステータス転送メッセージは、最初の送信に成功しなかったダウンリンクＵｎ ＰＤＣＰ ＳＤＵ ＳＮを含むことができる。あるいは、この情報は、サービングＤｅＮＢを最新の情報で更新するためにＳＮステータス転送メッセージの前後に発行される別個の制御メッセージを介して送ることができ、その結果、ＲＮは、転送される必要があるまさにそのダウンリンクデータを転送することができる。ハンドオーバを支援するフロー制御（またはＲＮ対ＤｅＮＢのバッファ同期）により、サービングＤｅＮＢは、ハンドオーバ時に、ＲＮバッファ内のすべてのＵｎインターフェースＰＤＣＰ ＳＤＵを有し、おそらくはＵｕインターフェースを介してすでに成功裏に送信された追加のＰＤＣＰ ＳＤＵを有することができる。ＳＮステータス転送メッセージを拡張する目的は、サービングＤｅＮＢによる冗長なデータ転送を最小限に抑えることである。
【００４８】
サービングＤｅＮＢは、データをターゲットｅＮＢに転送する（５２６）。ダウンリンクデータの場合、サービングＤｅＮＢは、ＲＮによってレポートされた、最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵから開始してそのバッファ内のＰＤＣＰ ＳＤＵすべてを転送することができる。最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ ＳＮは、ＲＮからのＳＮステータス転送メッセージから導出することも、ＳＮステータス転送メッセージの一部として、または別個のメッセージで、サービングＤｅＮＢに明示的にシグナリングすることもできる。フロー制御における停止／減少および開始／増大指示を使用する場合には、ソースＤｅＮＢは、Ｕｎインターフェースを介してまだ送達されていないＰＤＣＰ ＳＤＵすべてを転送することができ、ＲＮは、Ｕｎインターフェースを介して受信されたがＵｕインターフェースを介した送信にまだ成功していないＰＤＣＰ ＰＤＵ（またはＳＤＵ）すべてを転送することができる。
【００４９】
ＷＴＲＵは、ターゲットｅＮＢとの同期を実施し、ＲＡＣＨを介してターゲットセルにアクセスし、ターゲットｅＮＢは、ＵＬ割当ておよびタイミングアドバンスで応答し、ＷＴＲＵがターゲットセルへのアクセスに成功したとき、ＷＴＲＵは、ＲＲＣハンドオーバ完了メッセージを送る（５２８）。
【００５０】
ターゲットｅＮＢは、経路切替要求メッセージをＭＭＥ／ＧＷに送り、ＷＴＲＵがセルを変更したことを通知する（５３０）。サービングＧＷは、ダウンリンクデータ経路をターゲットｅＮＢに切り替え、１つまたは複数のＳ１−ＵＰエンドマーカパケットを元の経路上でソースＲＮおよび／またはソースＤｅＮＢに送り、次いでＵプレーン／トランスポートネットワークレイヤ（ＴＮＬ）リソースをソースＲＮに向かって解放する（５３２、５３４）。
【００５１】
ＭＭＥは、経路切替ＡＣＫメッセージで経路切替要求メッセージを確認する（５３６）。ＭＭＥから経路切替ＡＣＫメッセージを受信した後で、ターゲットｅＮＢは、ハンドオーバの成功を通知しソースＤｅＮＢによるリソースの解放をトリガするために、コンテキスト解放メッセージをソースＤｅＮＢに送る（５３８）。ソースＤｅＮＢは、コンテキスト解放メッセージを受信すると、ＲＲＣ接続再構成メッセージをソースＲＮに送り、ソースＲＮは、ＲＲＣ接続再構成応答メッセージで応答する（５４０、５４２）。
【００５２】
図１３は、他の実施形態に従ってＲＮが展開されるネットワーク内でのハンドオーバのための例示的なプロセス６００の流れ図である。この実施形態では、ソースＲＮからサービングＤｅＮＢに戻る最小または最も少ない量のダウンリンクデータ転送でハンドオーバが実施され、サービングＤｅＮＢからソースＲＮへ、冗長なデータ転送が削減または回避される。この例では、ＷＴＲＵが現在ＲＮ（ソースＲＮ）に接続されており、別のｅＮＢ（ターゲットｅＮＢ）にハンドオーバされつつあることが想定されている。この実施形態は、他のシナリオにも適用可能であることに留意されたい。
【００５３】
呼セットアップ中に、ＷＴＲＵ ＥＰＳベアラおよびＵｕ ＲＢ、ならびにＲＮ ＥＰＳベアラおよびＵｎインターフェースＲＢが確立され、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＲＢ間のマッピングまたは関連付けが確立される（６０２）。ＲＮは、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＲＢ間のマッピングまたは関連付けを維持する。マッピングは、一意のＷＴＲＵコンテキストＩＤ、（１つまたは複数の）ＲＮベアラ（たとえば、ＩＰソースアドレス、ＩＰ宛先アドレス、ＵＤＰソースポート、ＵＤＰ宛先ポート、トンネルエンドポイントＩＤ）、（１つまたは複数の）ＷＴＲＵベアラ（たとえば、ＩＰソースアドレス、ＩＰ宛先アドレス、ＵＤＰソースポート、ＵＤＰ宛先ポート、トンネルエンドポイントＩＤ）、（１つまたは複数の）ＲＮベアラＩＤ、（１つまたは複数の）ＷＴＲＵベアラＩＤに基づいて維持することができる。これは、任意のプロトコルアーキテクチャのいずれかに適用可能である。
【００５４】
ＤｅＮＢにとってトランスペアレントなＲＮでＳ１インターフェースが終了する場合、この関連付けはサービングＤｅＮＢに知られていないことがある。一実施形態によれば、ＷＴＲＵに対するＥＰＳベアラ／Ｕｕ ＤＲＢ確立の一部として、ＲＮ、ＭＭＥ、ＧＷ、またはこれら３つのノードの任意の組合せは、ソースＤｅＮＢに、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間の関連付けまたはマッピングを含むコンテキスト情報を伝えることができる。ＷＴＲＵコンテキスト情報は、コンテキストＩＤとすることができる。代替として、ＷＴＲＵコンテキスト情報は、ＷＴＲＵコンテキストＩＤを、（１つまたは複数の）ＷＴＲＵベアラ、（１つまたは複数の）ＲＮベアラ、およびそれらのマッピングと共に、含むことができる。
【００５５】
マッピング情報は、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢ確立の後に、サービングＤｅＮＢに送られる専用のメッセージを使用してやり取りすることができる。ＲＮは、ＷＴＲＵ ＥＰＳベアラ／ＤＲＢとＵｎインターフェースＥＰＳベアラ／ＤＲＢ間の関連付けまたはマッピング情報を、ＥＰＳベアラ／Ｕｕ ＤＲＢ確立中にＭＭＥ／ＧＷを介してサービングＤｅＮＢを使って伝えることができる。
【００５６】
サービングＤｅＮＢは、ＷＴＲＵのためのコンテキストを作成し、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間のマッピングを維持することができる。ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢとＲＮ ＥＰＳベアラ／Ｕｎ ＤＲＢ間のマッピングが確立した後で、ソースＤｅＮＢは、受信された制御メッセージを特定のＰＤＣＰプロセスに関連付けることができる。サービングＤｅＮＢは、ＲＮに行く各パケットを調べることができ、ハンドオーバ要求メッセージにコンテキストが含まれるＷＴＲＵ宛のパケットを停止することができる。これは、サービングＤｅＮＢからＲＮへの冗長なデータ転送を回避する助けとなる。
【００５７】
マッピング情報は、ＷＴＲＵ ＥＰＳベアラ／Ｕｕ ＤＲＢ確立後に、サービングＤｅＮＢに送られる専用のメッセージを使用して、ＲＮ（またはＭＭＥまたはＧＷ）とサービングＤｅＮＢの間で交換することができる。ＲＮはまた、ＷＴＲＵ ＥＰＳベアラ／ＤＲＢとＵｎインターフェースＥＰＳベアラ／ＤＲＢ間の関連付けまたはマッピング情報を、ＥＰＳベアラ／Ｕｕ ＤＲＢ確立中にＭＭＥ／ＧＷを介してサービングＤｅＮＢを使って伝えることができる。
【００５８】
ＲＮは、ＰＤＣＰエンティティの一方のセットをＵｕインターフェース上で、またＰＤＣＰエンティティの他方のセットをＵｎインターフェース上で維持することができ、これらのセットは、互いに独立して動作することができる。ＲＮおよびサービングＤｅＮＢは、Ｕｕインターフェースを介してＷＴＲＵに送信されるＵｕ ＰＤＣＰ ＰＤＵのＳＮと、Ｕｎインターフェースを介してサービングＤｅＮＢからＲＮによって受信されたＵｎ ＰＤＣＰ ＰＤＵのＳＮ間のマッピングを維持する。
【００５９】
マッピングは、各ＵｕインターフェースＰＤＣＰ ＳＮをＵｎインターフェースＰＤＣＰ ＳＮと関連付ける、またはその逆に関連付けるルックアップテーブルを使用して実施することができる。２つのシーケンス番号の関連付けられた値は、同じでない可能性がある。というのは、シーケンス番号付けは、ＵｎインターフェースまたはＵｕインターフェース上でいつでも、上限（たとえば、４０９５）に達する前に、他方が引き続き動作している間に再スタートすることができるからである。あるいは、シーケンス番号間の関連付けは、ＵｎインターフェースＰＤＣＰ ＳＮとＵｕインターフェースＰＤＣＰ ＳＮの間の１組のオフセットを維持する変換テーブルを介して行われてもよい。変換テーブルは、単一のオフセットまたは複数のオフセットを含むことができる。
【００６０】
あるいは、ＰＤＣＰエンティティが複数のＩＰパケットを１つのＰＤＣＰ ＰＤＵに連結すること、または単一のＰＤＣＰ ＳＤＵを複数のＰＤＣＰ ＰＤＵに分けることが許される場合、ＵｎインターフェースＰＤＣＰ ＳＮをＵｕインターフェースＰＤＣＰ ＳＮと関連付けるために、またはその逆に関連付けるために、ルックアップテーブルを使用することができる。
【００６１】
ＲＮ（および任意選択でサービングＤｅＮＢ）は、このマッピングを使用し、ターゲットハンドオーバノードに転送されることを必要とする正しいパケットをサービングＤｅＮＢにて識別することができるように、Ｕｕインターフェースを介してＲＮによって送信されるデータのＳＮとＵｎインターフェースを介して受信されたデータの適正な変換、およびその逆の変換を確実にすることができる。
【００６２】
さらに、ＤｅＮＢは、ＰＤＣＰ ＳＤＵとＰＤＣＰ ＰＤＵ間のマッピングを維持することができる。ダウンリンク送信の場合、ＤｅＮＢは、ＰＤＣＰ ＳＤＵ（すなわち、ＩＰパケット）を１つのＰＤＣＰ ＰＤＵ内に含めることができる。この場合、マッピングは、１対１のマッピングとすることができる。あるいは、ＤｅＮＢは、（単一のＷＴＲＵまたは複数のＷＴＲＵに対して指定された）複数のＰＤＣＰ ＳＤＵを１つのＰＤＣＰ ＰＤＵに連結する、または１つのＰＤＣＰ ＳＤＵが複数のＰＤＣＰ ＰＤＵに含まれるように１つのＰＤＣＰ ＳＤＵを複数のセグメントに分けることができる。この場合、マッピングは、多対１のマッピングとすることができる。このマッピングのために、各ＰＤＣＰ ＳＤＵ（またはそのセグメント）と各ＰＤＣＰ ＰＤＵには、異なるシーケンス番号（ＳＮ）を割り当てることができ、ＤｅＮＢは、関連付けられたマッピングでＰＤＣＰ ＳＤＵを追跡することができる。同様に、ＲＮは、ＰＤＣＰ ＳＤＵと、Ｕｕインターフェースを介して送信されるＰＤＣＰ ＰＤＵ間のマッピングを維持することができる。
【００６３】
マッピング（または上述のマッピングの任意の組合せ）により、ＤｅＮＢは、ＲＮバッファ輻輳または枯渇が発生したかどうか判断することができ、このマッピング情報を使用し、ハンドオーバ中にデータ再転送を最小限に抑えることができる。
【００６４】
ＷＴＲＵは、定期的に、またはトリガに基づいて、設定されているようにソースＲＮに測定レポートを送ることができる（６０４）。ソースＲＮは、測定レポートに基づいて、ハンドオーバの決定を行い（６０６）、ハンドオーバ要求メッセージ（Ｘ２ＡＰまたはＲＲＣ）をサービングＤｅＮＢに送る（６０８）。
【００６５】
ハンドオーバ要求メッセージは、データのバッファリングを開始するようにサービングＤｅＮＢに指示するように拡張されてもよい（すなわち、ＲＮに送られたダウンリンクデータを破棄しない）。ハンドオーバ要求メッセージは、最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵ ＳＮを含むことができる。あるいは、ハンドオーバ要求メッセージの前後に、別個のメッセージを介して、データバッファリング要求指示または最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮを送ることができる。ソースＲＮは、このメッセージを使用し、ターゲットハンドオーバノードに転送すべきＳＮおよび対応するＰＤＣＰ ＳＤＵをサービングＤｅＮＢに通知することができる。データバッファリング要求指示または最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮを受け取ると、サービングＤｅＮＢは、パケットを破棄することができず、示されたＳＮから始まるＳＮを有するデータをバッファするのを開始することができる。これは、ハンドオーバが開始された後で、ＲＮによる冗長なデータ再転送（すなわち、サービングＤｅＮＢによって送られたＤＬデータをサービングＤｅＮＢに再転送して返すこと）を回避するために実施される。
【００６６】
ＲＮは、ハンドオーバ要求メッセージと共に、ＷＴＲＵコンテキスト情報をサービングＤｅＮＢに送ることができる。ＷＴＲＵコンテキスト情報は、単にコンテキストＩＤとすることも、あるいは（１つまたは複数の）ＷＴＲＵベアラおよび（１つまたは複数の）ＲＮベアラ、ならびにそれらのマッピング／関連付けの情報を伴うＷＴＲＵコンテキストＩＤとすることもできる。サービングＤｅＮＢは、ＷＴＲＵコンテキスト情報に基づいて、ハンドオーバがトリガされつつあるＷＴＲＵに属する（１つまたは複数の）データフローを識別することができる。サービングＤｅＮＢは、ＲＮに行く各パケットを調べ、ハンドオーバ要求メッセージにコンテキストが含まれるＷＴＲＵ宛のパケットを停止することができる。これは、冗長なデータ転送を回避する助けとなる。
【００６７】
サービングＤｅＮＢは、ハンドオーバ要求メッセージをターゲットｅＮＢに転送する（６１０）。ターゲットｅＮＢは、アドミッション制御を実施する（６１２）。リソースをターゲットｅＮＢによって与えることができる場合、ターゲットｅＮＢによって、ＥＰＳベアラのサービス品質（ＱｏＳ）情報に基づいてアドミッション制御を実施し、ハンドオーバ成功の可能性を高めることができる。ターゲットｅＮＢは、受信されたＥＰＳベアラＱｏＳ情報に従って、必要とされるリソースを設定し、セル無線ネットワークの一時的な識別子（Ｃ−ＲＮＴＩ）などのような、リソースをリザーブ（確保）する。
【００６８】
ターゲットｅＮＢは、ハンドオーバ要求ＡＣＫメッセージをサービングＤｅＮＢに送る。ハンドオーバ要求ＡＣＫメッセージは、ハンドオーバを実施するためにＲＲＣメッセージとしてＷＴＲＵに送られることになるトランスペアレントなコンテナを含む。このコンテナは、新しいＣ−ＲＮＴＩ、選択されたセキュリティアルゴリズム用のターゲットｅＮＢセキュリティアルゴリズム識別子、専用ＲＡＣＨプリアンブルなどの、パラメータを含むことができる。
【００６９】
サービングＤｅＮＢは、ハンドオーバ要求ＡＣＫメッセージ、あるいはハンドオーバコマンドメッセージ（Ｘ２ＡＰまたはＲＲＣ）をＲＮに送ることができる（６１６）。ハンドオーバ要求ＡＣＫメッセージ（あるいは、ハンドオーバコマンドメッセージ）は、ソースＤｅＮＢがデータのバッファリングを開始したところのＳＮを含むことができる。このＳＮは、ＲＮによって提供された最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮよりも古くてもよい。この情報は、ハンドオーバの場合にどのＰＤＣＰ ＳＤＵが転送される必要があるかを判断するために、ＲＮが使用することができる。ハンドオーバ要求ＡＣＫメッセージ内に示されたＳＮは、ソースＲＮによってハンドオーバ要求メッセージ内に示されたＳＮと同じであってもよい。この情報は、ハンドオーバ要求ＡＣＫメッセージの後または前に個別に送ることができる。
【００７０】
ＲＮは、ハンドオーバコマンドメッセージをＷＴＲＵに送る（６１８）。ＲＮがその送信機および受信機をフリーズ（凍結）して、データをＷＴＲＵへ送信すること、またはＷＴＲＵからデータを受信することを停止した後で、ＲＮは、サービングＤｅＮＢを介してターゲットｅＮＢにＳＮステータス転送メッセージを送ることができる（６２０、６２２）。従来型の３ＧＰＰ Ｒ８ Ｘ２ＡＰ ＳＮステータス転送メッセージを再使用することも、あるいはＸ２ＡＰ ＳＮステータス転送メッセージと同様の内容を有する新しいＲＲＣ ＳＮステータス転送メッセージを定義することもできる。
【００７１】
ＳＮステータス転送メッセージは、ＰＤＣＰステータス保存が適用されるＥ−ＲＡＢのアップリンクＰＤＣＰ ＳＮ受信機ステータスおよびダウンリンクＰＤＣＰ ＳＮ送信機ステータスを搬送する（すなわち、ＲＬＣ ＡＭの場合）。アップリンクＰＤＣＰ ＳＮ受信機ステータスは、少なくとも次の予想される順番内の（ｉｎ−ｓｅｑｕｅｎｃｅ）アップリンクサービスデータユニットのＰＤＣＰ ＳＮを含む。ダウンリンクＰＤＣＰ ＳＮ送信機ステータスは、ターゲットｅＮＢが新しいＳＤＵに割り当てることを必要とする次のＰＤＣＰ ＳＮを示す。一実施形態によれば、ＳＮステータス転送メッセージは、最初の送信に成功しなかったダウンリンクＵｎインターフェースＰＤＣＰ ＳＤＵ ＳＮを含むことができる。あるいは、この情報は、サービングＤｅＮＢを最新の情報で更新するためにＳＮステータス転送メッセージの前後に発行される別個のメッセージを介して送ることができ、その結果、ＲＮは、転送される必要があるまさにそのダウンリンクデータを転送することができる。
【００７２】
ソースＲＮは、データをサービングＤｅＮＢに、またはターゲットｅＮＢに直接転送する（６２４、６２６）。ダウンリンクデータ転送が、必要とされ、かつＤｅＮＢがそのバッファ内に持っているＵｎインターフェースを介してすでに送信されたデータの情報（ｋｎｏｗｌｅｄｇｅ）に基づく場合には、ソースＲＮは、サービングＤｅＮＢバッファ内に存在しないＰＤＣＰ ＳＤＵを転送することができる。Ｕｎインターフェースを介してすでに送信されたデータをソースＤｅＮＢが持っていないことをソースＲＮが知っている場合には、ソースＲＮは、Ｕｕインターフェースを介してＷＴＲＵへの送信にまだ成功していない、Ｕｎインターフェースを介して受信されたＳＤＵすべてを転送することができる。
【００７３】
ダウンリンクデータの場合、サービングＤｅＮＢは、ＲＮにより報告された最初の送信に成功しなかったＵｎ ＰＤＣＰ ＳＤＵから開始したそのバッファ内に、すべてのＰＤＣＰ ＳＤＵを転送する（６２８）。最初の送信に成功しなかったＰＤＣＰ ＳＤＵ ＳＮは、ＲＮからのＳＮステータス転送メッセージから導出することも、ＳＮステータス転送メッセージの一部として、または別個のメッセージで、サービングＤｅＮＢに明示的にシグナリングすることもできる。
【００７４】
ＷＴＲＵは、ターゲットｅＮＢとの同期を実施し、ＲＡＣＨを介してターゲットセルにアクセスし、ターゲットｅＮＢは、ＵＬ割当ておよびタイミングアドバンスで応答し、ＷＴＲＵがターゲットセルへのアクセスに成功したとき、ＷＴＲＵは、ＲＲＣハンドオーバ完了メッセージを送る（６３０）。
【００７５】
ターゲットｅＮＢは、経路切替要求メッセージをＭＭＥ／ＧＷに送り、ＷＴＲＵがセルを変更したことを通知する（６３２）。サービングＧＷは、ダウンリンクデータ経路をターゲットｅＮＢに切り替え、１つまたは複数のＳ１−ＵＰエンドマーカパケットを元の経路上でソースＲＮおよび／またはソースＤｅＮＢに送り、次いでＵプレーン／ＴＮＬリソースをソースＲＮに向かって解放する（６３４、６３６）。
【００７６】
ＭＭＥは、経路切替応答メッセージで経路切替要求メッセージを確認する（６３８）。ＭＭＥから経路切替ＡＣＫメッセージを受信した後で、ターゲットｅＮＢは、ハンドオーバの成功を通知して、ソースＤｅＮＢによるリソースの解放をトリガするために、コンテキスト解放メッセージをソースＤｅＮＢに送る（６４０）。ソースＤｅＮＢは、コンテキスト解放メッセージを受信すると、ＲＲＣ接続再構成メッセージをソースＲＮに送り、ソースＲＮは、ＲＲＣ接続再構成応答メッセージで応答する（６４２、６４４）。
【００７７】
これらの実施形態は、ＷＴＲＵが任意のノードから任意のノードへ、たとえばソースＲＮから、そのソースＲＮを制御するサービングＤｅＮＢ、またはサービングＤｅＮＢもしくは隣接するｅＮＢのいずれかによって制御される別のＲＮへ、ハンドオーバされるハンドオーバシナリオ（状況、筋書き）にも同様に適用可能であることに留意されたい。これらの実施形態は、ダウンリンクとアップリンクの両方に適用可能であることにも留意されたい。
【００７８】
実施形態
１．ＲＮとのハンドオーバを実施することを特徴とする方法。
【００７９】
２．ＲＮがＤｅＮＢからＰＤＣＰ ＰＤＵを受信するステップを含むことを特徴とする実施形態１に記載の方法。
【００８０】
３．前記ＲＮがＷＴＲＵに前記ＰＤＣＰ ＰＤＵを送信するステップを含むことを特徴とする実施形態２に記載の方法。
【００８１】
４．前記ＲＮが前記ＷＴＲＵから測定レポートを受信するステップを含むことを特徴とする実施形態３に記載の方法。
【００８２】
５．前記ＲＮが前記測定レポートに基づいてハンドオーバの決定を行うステップを含むことを特徴とする実施形態４に記載の方法。
【００８３】
６．前記ＲＮが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含む情報と共にハンドオーバ要求メッセージを前記ＤｅＮＢに転送するステップを含むことを特徴とする実施形態５に記載の方法。
【００８４】
７．前記ＲＮが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて制御メッセージを前記ＤｅＮＢに送るステップをさらに含むことを特徴とする実施形態２〜６のいずれか１つに記載の方法。
【００８５】
８．前記ＲＮが、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＤｅＮＢからハンドオーバ要求応答メッセージを受信するステップをさらに含むことを特徴とする実施形態６〜７のいずれか１つに記載の方法。
【００８６】
９．前記ＲＮが、前記ＤｅＮＢから受信された情報に基づいて前記ＤｅＮＢにＰＤＣＰ ＰＤＵを転送するステップをさらに含むことを特徴とする実施形態８に記載の方法。
【００８７】
１０．前記ＲＮは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供することを特徴とする実施形態６〜９のいずれか１つに記載の方法。
【００８８】
１１．前記ＲＮは、前記ＲＮと前記ＷＴＲＵの間の無線インターフェースを介して前記ＷＴＲＵに送信されたデータのＰＤＣＰ ＳＮと、前記ＲＮと前記ＤｅＮＢの間の無線インターフェースを介して前記ＲＮによって受信されたデータのＰＤＣＰ ＳＮとの間のマッピングのテーブルを維持することを特徴とする実施形態３〜１０のいずれか１つに記載の方法。
【００８９】
１２．前記ＲＮが、呼セットアップ中に、ＷＴＲＵコンテキストＩＤ、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するステップをさらに含むことを特徴とする実施形態２〜１１のいずれか１つに記載の方法。
【００９０】
１３．無線通信用であることを特徴とするＲＮ。
【００９１】
１４．アンテナを備えることを特徴とする実施形態１３に記載のＲＮ。
【００９２】
１５．ＤｅＮＢから受信し、ＷＴＲＵに送信するように構成されたトランシーバを備えることを特徴とする実施形態１３〜１４のいずれか１つに記載のＲＮ。
【００９３】
１６．前記ＤｅＮＢからＰＤＣＰ ＰＤＵを受信し、前記ＰＤＣＰ ＰＤＵを前記ＷＴＲＵに送信し、前記ＷＴＲＵから受信された測定レポートに基づいてハンドオーバの決定を行い、最初の送信に成功しなかったＰＤＣＰ ＳＮを含む情報と共にハンドオーバ要求メッセージを前記ＤｅＮＢに送るように構成されたプロセッサを備えることを特徴とする実施形態１５に記載のＲＮ。
【００９４】
１７．前記プロセッサは、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて制御メッセージを前記ＤｅＮＢに送るように構成されていることを特徴とする実施形態１６に記載のＲＮ。
【００９５】
１８．前記プロセッサは、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＤｅＮＢからハンドオーバ要求応答メッセージを受信し、前記ＤｅＮＢから受信された情報に基づいて前記ＤｅＮＢにＰＤＣＰ ＰＤＵを転送するように構成されていることを特徴とする実施形態１６〜１７のいずれか１つに記載のＲＮ。
【００９６】
１９．前記プロセッサは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するように構成されていることを特徴とする実施形態１６〜１８のいずれか１つに記載のＲＮ。
【００９７】
２０．前記プロセッサは、前記ＲＮと前記ＷＴＲＵの間の無線インターフェースを介して前記ＷＴＲＵに送信されたデータのＰＤＣＰ ＳＮと、前記ＲＮと前記ＤｅＮＢの間の無線インターフェースを介して前記ＲＮによって受信されたデータのＰＤＣＰ ＳＮとの間のマッピングのテーブルを維持するように構成されていることを特徴とする実施形態１６〜１９のいずれか１つに記載のＲＮ。
【００９８】
２１．前記プロセッサは、呼セットアップ中に、ＷＴＲＵコンテキストＩＤ、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するように構成されていることを特徴とする実施形態１６〜２０のいずれか１つに記載のＲＮ。
【００９９】
２２．ＲＮとのハンドオーバを実施することを特徴とする方法。
【０１００】
２３．ノードＢがＰＤＣＰ ＰＤＵをＲＮに送るステップを含むことを特徴とする実施形態２２に記載の方法。
【０１０１】
２４．前記ノードＢが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含む情報と共に前記ＲＮからハンドオーバ要求メッセージを受信するステップを含み、前記ノードＢは、前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄することを特徴とする実施形態２３に記載の方法。
【０１０２】
２５．前記ノードＢが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて前記ＲＮから制御メッセージを受信するステップを含み、前記ノードＢは、前記制御メッセージを介して示された前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄することを特徴とする実施形態２３〜２４のいずれか１つに記載の方法。
【０１０３】
２６．前記ノードＢが、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＲＮにハンドオーバ要求応答メッセージを送るステップをさらに含むことを特徴とする実施形態２４〜２５のいずれか１つに記載の方法。
【０１０４】
２７．前記ノードＢは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を受信することを特徴とする実施形態２４〜２６のいずれか１つに記載の方法。
【０１０５】
２８．前記ノードＢが、呼セットアップ中に、ＷＴＲＵコンテキストＩＤ、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を受信するステップをさらに含むことを特徴とする実施形態２４〜２７のいずれか１つに記載の方法。
【０１０６】
２９．前記ノードＢが、ＷＴＲＵベアラとＲＮベアラ間のマッピングを確立するステップを含むことを特徴とする実施形態２８に記載の方法。
【０１０７】
３０．前記ノードＢがＳ１−ＵＰエンドマーカパケットを受信するステップをさらに含むことを特徴とする実施形態２４〜２９のいずれか１つに記載の方法。
【０１０８】
３１．ＲＮとのハンドオーバを実施することを特徴とするノードＢ。
【０１０９】
３２．アンテナを備えることを特徴とする実施形態３１に記載のノードＢ。
【０１１０】
３３．ＲＮと無線で通信するように構成されたトランシーバを備えることを特徴とする実施形態３１〜３２のいずれか１つに記載のノードＢ。
【０１１１】
３４．前記ＲＮにＰＤＣＰ ＰＤＵを送り、最初の送信に成功しなかったＰＤＣＰ ＳＮを含む情報と共に前記ＲＮからハンドオーバ要求メッセージを受信するように構成されたプロセッサを備え、前記プロセッサは、前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄することを特徴とする実施形態３３に記載のノードＢ。
【０１１２】
３５．前記プロセッサは、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて前記ＲＮから制御メッセージを受信し、前記制御メッセージを介して示された前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄するように構成されていることを特徴とする実施形態３４に記載のノードＢ。
【０１１３】
３６．前記プロセッサは、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＲＮにハンドオーバ要求応答メッセージを送るように構成されていることを特徴とする実施形態３４〜３５のいずれか１つに記載のノードＢ。
【０１１４】
３７．前記プロセッサは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を受信することを特徴とする実施形態３４〜３６のいずれか１つに記載のノードＢ。
【０１１５】
３８．前記プロセッサは、呼セットアップ中に、ＷＴＲＵコンテキストＩＤ、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を受信し、ＷＴＲＵベアラとＲＮベアラ間のマッピングを確立するように構成されていることを特徴とする実施形態３４〜３７のいずれか１つに記載のノードＢ。
【０１１６】
３９．前記プロセッサは、Ｓ１−ＵＰエンドマーカパケットを受信するように構成されていることを特徴とする実施形態３４〜３８のいずれか１つに記載のノードＢ。
【０１１７】
上記では特徴および要素が特定の組合せで述べられているが、各特徴および要素は、他の特徴および要素なしの単独で、または他の特徴および要素のある、もしくは他の特徴および要素のない様々な組合せで使用することができる。本明細書において提供されている方法または流れ図は、汎用コンピュータまたはプロセッサによって実行するためのコンピュータ可読記憶媒体内に組み込まれるコンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読記憶媒体の例は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクや取外し式ディスクなど磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多目的ディスク（ＤＶＤ）など光媒体を含む。
【０１１８】
好適なプロセッサは、例として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、特定用途用標準品（ＡＳＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、ならびに任意の他のタイプの集積回路（ＩＣ）、および／または状態機械を含む。
【０１１９】
ソフトウェアに関連付けられたプロセッサを使用し、無線送信／受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、端末、基地局、無線通信移動管理装置（ＭＭＥ）もしくは拡張パケットコア（ＥＰＣ）、または任意のホストコンピュータ内で使用するための無線周波数トランシーバを実装することができる。ＷＴＲＵは、ソフトウェア無線（ＳＤＲ）を含めてハードウェアおよび／またはソフトウェアで実装されるモジュールと共に、またカメラ、ビデオカメラモジュール、テレビ電話、スピーカフォン、振動デバイス、スピーカ、マイクロフォン、テレビトランシーバ、ハンドフリー用ハンドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、近距離無線通信（ＮＦＣ）モジュール、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット、有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および／または任意の無線構内通信網（ＷＬＡＮ）もしくは超広帯域（ＵＷＢ）モジュールなど他の構成要素と共に使用することができる。
【特許請求の範囲】
【請求項１】
中継ノード（ＲＮ）とのハンドオーバを実施するための方法であって、
ＲＮがドナー高度化ノードＢ（ＤｅＮＢ）からパケットデータ収束プロトコル（ＰＤＣＰ）プロトコルデータユニット（ＰＤＵ）を受信するステップと、
前記ＲＮが無線送信／受信ユニット（ＷＴＲＵ）に前記ＰＤＣＰ ＰＤＵを送信するステップと、
前記ＲＮが前記ＷＴＲＵから測定レポートを受信するステップと、
前記ＲＮが前記測定レポートに基づいてハンドオーバの決定を行うステップと、
前記ＲＮが、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含む情報と共にハンドオーバ要求メッセージを前記ＤｅＮＢに転送するステップと
を含むことを特徴とする方法。
【請求項２】
前記ＲＮが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて制御メッセージを前記ＤｅＮＢに送るステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＲＮが、前記ＤｅＮＢにて破棄されていない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＤｅＮＢからハンドオーバ要求応答メッセージを受信するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記ＲＮが、前記ＤｅＮＢから受信された情報に基づいて前記ＤｅＮＢにＰＤＣＰ ＰＤＵを転送するステップをさらに含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記ＲＮは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供することを特徴とする請求項１に記載の方法。
【請求項６】
前記ＲＮは、前記ＲＮと前記ＷＴＲＵの間の無線インターフェースを介して前記ＷＴＲＵに送信されたデータのＰＤＣＰ ＳＮと、前記ＲＮと前記ＤｅＮＢの間の無線インターフェースを介して前記ＲＮによって受信されたデータのＰＤＣＰ ＳＮ間のマッピングのテーブルを維持することを特徴とする請求項１に記載の方法。
【請求項７】
前記ＲＮが、呼セットアップ中に、ＷＴＲＵコンテキストアイデンティティ（ＩＤ）、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
無線通信用の中継ノード（ＲＮ）であって、
アンテナと、
ドナー高度化ノードＢ（ＤｅＮＢ）から受信し、無線送信／受信ユニット（ＷＴＲＵ）に送信するように構成されたトランシーバと、
前記ＤｅＮＢからパケットデータ収束プロトコル（ＰＤＣＰ）プロトコルデータユニット（ＰＤＵ）を受信し、前記ＰＤＣＰ ＰＤＵを前記ＷＴＲＵに送信し、前記ＷＴＲＵから受信された測定レポートに基づいてハンドオーバの決定を行い、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含む情報と共にハンドオーバ要求メッセージを前記ＤｅＮＢに送るように構成されたプロセッサと
を備えることを特徴とするＲＮ。
【請求項９】
前記プロセッサは、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて制御メッセージを前記ＤｅＮＢに送るように構成されていることを特徴とする請求項８に記載のＲＮ。
【請求項１０】
前記プロセッサは、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＤｅＮＢからハンドオーバ要求応答メッセージを受信し、前記ＤｅＮＢから受信された情報に基づいて前記ＤｅＮＢにＰＤＣＰ ＰＤＵを転送するように構成されていることを特徴とする請求項８に記載のＲＮ。
【請求項１１】
前記プロセッサは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するように構成されていることを特徴とする請求項８に記載のＲＮ。
【請求項１２】
前記プロセッサは、前記ＲＮと前記ＷＴＲＵの間の無線インターフェースを介して前記ＷＴＲＵに送信されたデータのＰＤＣＰ ＳＮと、前記ＲＮと前記ＤｅＮＢの間の無線インターフェースを介して前記ＲＮによって受信されたデータのＰＤＣＰ ＳＮ間のマッピングのテーブルを維持するように構成されていることを特徴とする請求項８に記載のＲＮ。
【請求項１３】
前記プロセッサは、呼セットアップ中に、ＷＴＲＵコンテキストアイデンティティ（ＩＤ）、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するように構成されていることを特徴とする請求項８に記載のＲＮ。
【請求項１４】
中継ノード（ＲＮ）とのハンドオーバを実施するための方法であって、
ノードＢがパケットデータ収束プロトコル（ＰＤＣＰ）プロトコルデータユニット（ＰＤＵ）をＲＮに送るステップと、
前記ノードＢが、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含む情報と共に前記ＲＮからハンドオーバ要求メッセージを受信するステップとを含み、前記ノードＢは、最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄することを特徴とする方法。
【請求項１５】
前記ノードＢが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて前記ＲＮから制御メッセージを受信するステップをさらに含み、前記ノードＢは、前記制御メッセージを介して示された前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄することを特徴とする請求項１４に記載の方法。
【請求項１６】
前記ノードＢが、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＲＮにハンドオーバ要求応答メッセージを送るステップをさらに含むことを特徴とする請求項１４に記載の方法。
【請求項１７】
前記ノードＢは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を受信することを特徴とする請求項１４に記載の方法。
【請求項１８】
前記ノードＢが、呼セットアップ中に、ＷＴＲＵコンテキストアイデンティティ（ＩＤ）、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を受信するステップと、
前記ノードＢが、ＷＴＲＵベアラとＲＮベアラ間のマッピングを確立するステップと
をさらに含むことを特徴とする請求項１４に記載の方法。
【請求項１９】
前記ノードＢがＳ１−ＵＰエンドマーカパケットを受信するステップをさらに含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
中継ノード（ＲＮ）とのハンドオーバを実施するためのノードＢであって、
アンテナと、
ＲＮと無線で通信するように構成されたトランシーバと、
前記ＲＮにパケットデータ収束プロトコル（ＰＤＣＰ）プロトコルデータユニット（ＰＤＵ）を送り、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含む情報と共に前記ＲＮからハンドオーバ要求メッセージを受信するように構成されたプロセッサであって、前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄するプロセッサと
を備えることを特徴とするノードＢ。
【請求項２１】
前記プロセッサは、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて前記ＲＮから制御メッセージを受信し、前記制御メッセージを介して示された前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄するように構成されていることを特徴とする請求項２０に記載のノードＢ。
【請求項２２】
前記プロセッサは、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＲＮにハンドオーバ要求応答メッセージを送るように構成されていることを特徴とする請求項２０に記載のノードＢ。
【請求項２３】
前記プロセッサは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を受信することを特徴とする請求項２０に記載のノードＢ。
【請求項２４】
前記プロセッサは、呼セットアップ中に、ＷＴＲＵコンテキストアイデンティティ（ＩＤ）、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を受信し、ＷＴＲＵベアラとＲＮベアラ間のマッピングを確立するように構成されていることを特徴とする請求項２０に記載のノードＢ。
【請求項２５】
前記プロセッサは、Ｓ１−ＵＰエンドマーカパケットを受信するように構成されていることを特徴とする請求項２４に記載のノードＢ。
【請求項１】
中継ノード（ＲＮ）とのハンドオーバを実施するための方法であって、
ＲＮがドナー高度化ノードＢ（ＤｅＮＢ）からパケットデータ収束プロトコル（ＰＤＣＰ）プロトコルデータユニット（ＰＤＵ）を受信するステップと、
前記ＲＮが無線送信／受信ユニット（ＷＴＲＵ）に前記ＰＤＣＰ ＰＤＵを送信するステップと、
前記ＲＮが前記ＷＴＲＵから測定レポートを受信するステップと、
前記ＲＮが前記測定レポートに基づいてハンドオーバの決定を行うステップと、
前記ＲＮが、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含む情報と共にハンドオーバ要求メッセージを前記ＤｅＮＢに転送するステップと
を含むことを特徴とする方法。
【請求項２】
前記ＲＮが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて制御メッセージを前記ＤｅＮＢに送るステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＲＮが、前記ＤｅＮＢにて破棄されていない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＤｅＮＢからハンドオーバ要求応答メッセージを受信するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記ＲＮが、前記ＤｅＮＢから受信された情報に基づいて前記ＤｅＮＢにＰＤＣＰ ＰＤＵを転送するステップをさらに含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記ＲＮは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供することを特徴とする請求項１に記載の方法。
【請求項６】
前記ＲＮは、前記ＲＮと前記ＷＴＲＵの間の無線インターフェースを介して前記ＷＴＲＵに送信されたデータのＰＤＣＰ ＳＮと、前記ＲＮと前記ＤｅＮＢの間の無線インターフェースを介して前記ＲＮによって受信されたデータのＰＤＣＰ ＳＮ間のマッピングのテーブルを維持することを特徴とする請求項１に記載の方法。
【請求項７】
前記ＲＮが、呼セットアップ中に、ＷＴＲＵコンテキストアイデンティティ（ＩＤ）、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
無線通信用の中継ノード（ＲＮ）であって、
アンテナと、
ドナー高度化ノードＢ（ＤｅＮＢ）から受信し、無線送信／受信ユニット（ＷＴＲＵ）に送信するように構成されたトランシーバと、
前記ＤｅＮＢからパケットデータ収束プロトコル（ＰＤＣＰ）プロトコルデータユニット（ＰＤＵ）を受信し、前記ＰＤＣＰ ＰＤＵを前記ＷＴＲＵに送信し、前記ＷＴＲＵから受信された測定レポートに基づいてハンドオーバの決定を行い、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含む情報と共にハンドオーバ要求メッセージを前記ＤｅＮＢに送るように構成されたプロセッサと
を備えることを特徴とするＲＮ。
【請求項９】
前記プロセッサは、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて制御メッセージを前記ＤｅＮＢに送るように構成されていることを特徴とする請求項８に記載のＲＮ。
【請求項１０】
前記プロセッサは、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＤｅＮＢからハンドオーバ要求応答メッセージを受信し、前記ＤｅＮＢから受信された情報に基づいて前記ＤｅＮＢにＰＤＣＰ ＰＤＵを転送するように構成されていることを特徴とする請求項８に記載のＲＮ。
【請求項１１】
前記プロセッサは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するように構成されていることを特徴とする請求項８に記載のＲＮ。
【請求項１２】
前記プロセッサは、前記ＲＮと前記ＷＴＲＵの間の無線インターフェースを介して前記ＷＴＲＵに送信されたデータのＰＤＣＰ ＳＮと、前記ＲＮと前記ＤｅＮＢの間の無線インターフェースを介して前記ＲＮによって受信されたデータのＰＤＣＰ ＳＮ間のマッピングのテーブルを維持するように構成されていることを特徴とする請求項８に記載のＲＮ。
【請求項１３】
前記プロセッサは、呼セットアップ中に、ＷＴＲＵコンテキストアイデンティティ（ＩＤ）、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を前記ＤｅＮＢに提供するように構成されていることを特徴とする請求項８に記載のＲＮ。
【請求項１４】
中継ノード（ＲＮ）とのハンドオーバを実施するための方法であって、
ノードＢがパケットデータ収束プロトコル（ＰＤＣＰ）プロトコルデータユニット（ＰＤＵ）をＲＮに送るステップと、
前記ノードＢが、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含む情報と共に前記ＲＮからハンドオーバ要求メッセージを受信するステップとを含み、前記ノードＢは、最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄することを特徴とする方法。
【請求項１５】
前記ノードＢが、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて前記ＲＮから制御メッセージを受信するステップをさらに含み、前記ノードＢは、前記制御メッセージを介して示された前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄することを特徴とする請求項１４に記載の方法。
【請求項１６】
前記ノードＢが、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＲＮにハンドオーバ要求応答メッセージを送るステップをさらに含むことを特徴とする請求項１４に記載の方法。
【請求項１７】
前記ノードＢは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を受信することを特徴とする請求項１４に記載の方法。
【請求項１８】
前記ノードＢが、呼セットアップ中に、ＷＴＲＵコンテキストアイデンティティ（ＩＤ）、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を受信するステップと、
前記ノードＢが、ＷＴＲＵベアラとＲＮベアラ間のマッピングを確立するステップと
をさらに含むことを特徴とする請求項１４に記載の方法。
【請求項１９】
前記ノードＢがＳ１−ＵＰエンドマーカパケットを受信するステップをさらに含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
中継ノード（ＲＮ）とのハンドオーバを実施するためのノードＢであって、
アンテナと、
ＲＮと無線で通信するように構成されたトランシーバと、
前記ＲＮにパケットデータ収束プロトコル（ＰＤＣＰ）プロトコルデータユニット（ＰＤＵ）を送り、最初の送信に成功しなかったＰＤＣＰシーケンス番号（ＳＮ）を含む情報と共に前記ＲＮからハンドオーバ要求メッセージを受信するように構成されたプロセッサであって、前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄するプロセッサと
を備えることを特徴とするノードＢ。
【請求項２１】
前記プロセッサは、最初の送信に成功しなかったＰＤＣＰ ＳＮを含めて前記ＲＮから制御メッセージを受信し、前記制御メッセージを介して示された前記最初の送信に成功しなかったＰＤＣＰ ＳＮよりも古いＳＮを有するＰＤＣＰ ＰＤＵを破棄するように構成されていることを特徴とする請求項２０に記載のノードＢ。
【請求項２２】
前記プロセッサは、前記ＤｅＮＢにて破棄されない最初のＰＤＣＰ ＳＮを含む情報と共に前記ＲＮにハンドオーバ要求応答メッセージを送るように構成されていることを特徴とする請求項２０に記載のノードＢ。
【請求項２３】
前記プロセッサは、前記ハンドオーバ要求メッセージと共にＷＴＲＵコンテキスト情報を受信することを特徴とする請求項２０に記載のノードＢ。
【請求項２４】
前記プロセッサは、呼セットアップ中に、ＷＴＲＵコンテキストアイデンティティ（ＩＤ）、ＲＮベアラ情報、ＷＴＲＵベアラ情報、ＲＮベアラＩＤ、およびＷＴＲＵベアラＩＤのうちの少なくとも１つを含めて、ＷＴＲＵコンテキスト情報を受信し、ＷＴＲＵベアラとＲＮベアラ間のマッピングを確立するように構成されていることを特徴とする請求項２０に記載のノードＢ。
【請求項２５】
前記プロセッサは、Ｓ１−ＵＰエンドマーカパケットを受信するように構成されていることを特徴とする請求項２４に記載のノードＢ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公表番号】特表２０１２−５３１１０３（Ｐ２０１２−５３１１０３Ａ）
【公表日】平成２４年１２月６日（２０１２．１２．６）
【国際特許分類】
【出願番号】特願２０１２−５１６１９６（Ｐ２０１２−５１６１９６）
【出願日】平成２２年６月１５日（２０１０．６．１５）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３８６５６
【国際公開番号】ＷＯ２０１０／１４７９７４
【国際公開日】平成２２年１２月２３日（２０１０．１２．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＣＤＭＡ
【出願人】（５１００３０９９５）インターデイジタル パテント ホールディングス インコーポレイテッド (229)
【Ｆターム（参考）】
【公表日】平成２４年１２月６日（２０１２．１２．６）
【国際特許分類】
【出願日】平成２２年６月１５日（２０１０．６．１５）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３８６５６
【国際公開番号】ＷＯ２０１０／１４７９７４
【国際公開日】平成２２年１２月２３日（２０１０．１２．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＣＤＭＡ
【出願人】（５１００３０９９５）インターデイジタル パテント ホールディングス インコーポレイテッド (229)
【Ｆターム（参考）】
[ Back to top ]