(57)【要約】中継ノードを介したドナーノードとの通信から目標ノードとの通信への通信システムにおけるユーザ設備のハンドオーバの方法が提供される。ドナーノードは、順次マークを付された一連のドナーパケットにおいてダウンリンクデータを中継ノードへ送信するよう動作し、次いで、中継ノードは、同じく順次マークを付された一連の中継パケットにおいてダウンリンクをユーザ設備へ送信するよう動作する。方法は、ドナーノードでハンドオーバ要求を受信し、受信時にドナーノードで一時バッファにおけるドナーパケットのバッファリングを開始し、ユーザ設備によって受信されたと見なされなかった中継パケットの第１の中継パケットを示すステータスメッセージを中継ノードからドナーノードへ送信し、一時バッファにおいてバッファリングされた第１のドナーパケットを示すアップデートメッセージをドナーノードから中継ノードへ送信する。
2013513988.tif 000002
【特許請求の範囲】
【請求項１】
中継ノードを介したドナーノードとの通信から目標ノードとの通信への通信システムにおけるユーザ設備のハンドオーバの方法であって、前記ドナーノードは、順次マークを付された一連のドナーパケットにおいてダウンリンクデータを前記中継ノードへ送信するよう動作し、次いで、前記中継ノードは、同じく順次マークを付された一連の中継パケットにおいて前記ダウンリンクを前記ユーザ設備へ送信するよう動作する、方法において、
前記ドナーノードでハンドオーバ要求を受信し、受信時に前記ドナーノードで一時バッファにおける前記ドナーパケットのバッファリングを開始し、
前記ユーザ設備によって受信されたと見なされなかった前記中継パケットの第１の中継パケットを示すステータスメッセージを前記中継ノードから前記ドナーノードへ送信し、
前記一時バッファにおいてバッファリングされた第１のドナーパケットを示すアップデートメッセージを前記ドナーノードから前記中継ノードへ送信する
方法。
【請求項２】
前記ユーザ設備によって受信されたと前記中継ノードによって見なされなかった中継パケットであって、前記一時バッファにおいてバッファリングされた前記第１のドナーパケットよりも順番的に早い中継パケットからの全てのダウンリンクデータを、前記中継ノードから前記ドナーノードへ、アップリンク転送する、
請求項１に記載の方法。
【請求項３】
転送されるデータに、該転送されるデータが前記ハンドオーバ要求の前記目標ノードへの転送を対象とするとの前記ドナーノードへのインジケーションを加える、
請求項１又は２に記載の方法。
【請求項４】
前記ドナーノードから前記目標ノードへ前記一時バッファにおける前記ドナーパケットからのデータを転送する、
請求項１乃至３のうちいずれか一項に記載の方法。
【請求項５】
前記ドナーパケットの連続的なマーキングは、前記中継パケットの連続的なマーキングと相違し、各中継パケットは、当該中継パケットが対応するドナーパケットからのダウンリンクデータを含むようにドナーパケットに対応し、
前記ステータスメッセージは、前記ユーザ設備によって受信されたと見なされなかった前記中継パケットの前記第１の中継パケットを特定するよう前記対応するドナーパケットの連続的なマーキングを用いる、
請求項１乃至４のうちいずれか一項に記載の方法。
【請求項６】
前記中継パケットの連続的なマーキングを用いて前記ユーザ設備によって受信されたと見なされなかった前記第１の中継パケットを示す更なるステータスメッセージを前記中継ノードから前記目標ノードへ送信する
請求項１乃至５のうちいずれか一項に記載の方法。
【請求項７】
前記ドナーノードから前記中継ノードへ前記一時バッファにおけるドナーパケットのダウンリンクデータを送信する、
請求項１乃至６のうちいずれか一項に記載の方法。
【請求項８】
前記ドナーノードで、前記一時バッファにおけるドナーパケットからのダウンリンクデータが前記中継ノードによって受信されたとの確認応答を受信すると、前記一時バッファにおいて前記ドナーパケットを保持する、
請求項７に記載の方法。
【請求項９】
所定のシーケンスの中継パケットのうち前記ユーザ設備によって受信されたと見なされなかった中継パケットのインジケーションを前記中継ノードから前記ドナーノードへ送信する、
請求項１乃至８のうちいずれか一項に記載の方法。
【請求項１０】
ＬＴＥ−Ａプロトコルに従って動作する通信システムにおいて使用される、
請求項１乃至９のうちいずれか一項に記載の方法。
【請求項１１】
前記ドナーノードは、ＬＴＥ−Ａプロトコルに従うドナーエンハンスドノード基地局である、
請求項１０に記載の方法。
【請求項１２】
ユーザ設備が中継ノードを介してドナーノードと通信する第１の構成から、前記ユーザ設備が目標ノードと通信する第２の構成へのハンドオーバを実行するよう動作する通信システムであって、
前記第１の構成に従う通信時に、前記ドナーノードは、順次マークを付された一連のドナーパケットにおいてダウンリンクデータを中継ノードへ送信するよう動作し、次いで、前記中継ノードは、順次マークを付された一連の中継パケットにおいて前記ダウンリンクを前記ユーザ設備へ送信するよう動作し、
前記ハンドオーバの実行において、
前記ドナーノードは、ハンドオーバ要求を受信し、受信時に、一時バッファにおける前記ドナーパケットのバッファリングを開始するよう動作し、
前記中継ノードは、前記ユーザ設備によって受信されたと見なされなかった第１の中継パケットを示すステータスメッセージを前記ドナーノードへ送信するよう動作し、
前記ドナーノードは、前記一時バッファにおいてバッファリングされた第１のドナーパケットを示すアップデートメッセージを前記中継ノードへ送信するよう動作する、
通信システム。
【請求項１３】
ユーザ設備が中継ノードを介してドナーノードと通信する第１の構成から、前記ユーザ設備が目標ノードと通信する第２の構成へのハンドオーバを実行するよう動作する通信システムにおける使用のための中継ノードであって、
前記第１の構成に従う通信時に、当該中継ノードは、順次マークを付された一連のドナーパケットにおいて前記ドナーノードからダウンリンクデータを受信し、順次マークを付された一連の中継パケットにおいて前記ダウンリンクを前記ユーザ設備へ送信するよう動作し、
前記ハンドオーバの実行において、
当該中継ノードは、前記ユーザ設備によって受信されたと見なされなかった第１の中継パケットを示すステータスメッセージを前記ドナーノードへ送信するよう動作し、
当該中継ノードは、前記ドナーノードでハンドオーバ要求の受信時にドナーパケットをバッファリングし始めた一時バッファにおいてバッファリングされた第１のドナーパケットを示すアップデートメッセージを前記ドナーノードから受信するよう動作する、
中継ノード。
【請求項１４】
電気通信ノードのコンピュータデバイスで実行される場合に、前記電気通信ノードを請求項１３に記載の中継ノードとするコンピュータプログラム。
【請求項１５】
ユーザ設備が中継ノードを介してドナーノードと通信する第１の構成から、前記ユーザ設備が目標ノードと通信する第２の構成へのハンドオーバを実行するよう動作する通信システムにおける使用のためのドナーノードであって、
前記第１の構成に従う通信時に、当該ドナーノードは、順次マークを付された一連の中継パケットとしての前記ユーザ設備へのその後の送信のために、同じく順次マークを付された一連のドナーパケットにおいてダウンリンクデータを前記中継ノードへ送信するよう動作し、
前記ハンドオーバの実行において、
当該ドナーノードは、ハンドオーバ要求を受信し、受信時に、一時バッファにおける前記ドナーパケットのバッファリングを開始し、且つ、前記ユーザ設備によって受信されたと見なされなかった第１の中継パケットを示すステータスメッセージを前記中継ノードから受信するよう動作し、
当該ドナーノードは、前記一時バッファにおいてバッファリングされた第１のドナーパケットを示すアップデートメッセージを前記中継ノードへ送信するよう動作する、
ドナーノード。
【請求項１６】
電気通信ノードのコンピュータデバイスで実行される場合に、前記電気通信ノードを請求項１５に記載のドナーノードとするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電気通信の分野に関し、特に、１の基地局から他の基地局へのユーザ設備（ＵＥ）のハンドオーバを実行することに関する。本発明は、ＷｉＭＡＸ、ＵＭＴＳ（Universal  Mobile  Telecommunications  System）、ＣＤＭＡ（Code  Division  Multiple  Access）プロトコル、ＧＥＲＡＮ（GSM(登録商標)  EDGE  Radio  Access  Network）、又は他の電気通信プロトコルにおいて使用されるもののような、ＯＦＤＭに従って動作する通信システムにおいて使用されてよい。具体的に、本発明は、中継局が基地局からユーザ設備へダウンリンクデータを中継する電気通信プロトコルにおいて使用されてよい。
【背景技術】
【０００２】
１つの特定の用途は、３Ｇとしても知られるＵＭＴＳにある。ＵＭＴＳ無線通信システムは世界的に開発されている。ＵＭＴＳシステムの将来の進歩は、所謂エボルブドＵＴＲＡＮ又はｅＵＴＲＡＮ（evolved  UMTS  terrestrial  radio  access  network）（より一般的には、プロジェクト名ＬＴＥによって参照される。）に重点を置かれている。
【０００３】
ＬＴＥは、ユーザのためのデータレートの増大を伴った高速データサービスの配信のための技術である。ＵＭＴＳ及び前世代のモバイル通信標準と比較して、ＬＴＥは遅延の減少、セルエッジ・カバレッジの拡大、費用毎ビットの削減、柔軟なスペクトル利用、マルチ無線アクセス技術のモビリティをも提供する。
【０００４】
ＬＴＥは、１００Ｍｂｐｓよりも大きい、ダウンリンク（ＤＬ）方向、すなわち、基地局（ＢＳ）からユーザ設備への通信におけるピークデータレートを与えるよう設計されており、一方、アップリンク方向、すなわち、ユーザ設備からＢＳへの通信においては、５０Ｍｂｐｓよりも大きい。
【０００５】
現在標準化されている発展であるＬＴＥ−Ａ（LTE-Advanced）は、さらに、最大でダウンリンクにおいては１Ｇｂｐｓ及びアップリンクにおいては５００Ｍｂｐｓを可能にするようＬＴＥシステムを改善する。ＬＴＥ−Ａは、特に、より高いデータレートの転送及びセルエッジ・カバレッジに対する改善のために、既存のＬＴＥシステムに対して性能を改善するために新しい技術を用いる。
【０００６】
ＬＴＥ−Ａ及びＬＴＥは、共通の基本アーキテクチャ及びネットワークプロトコル・アーキテクチャを共有する。現在のＵＭＴＳシステムにおいて見られるように、ＬＴＥのために提案される基本アーキテクチャは、ユーザ（又はより正確にはユーザ設備）を基地局として動作するアクセスノードへ接続する無線アクセスネットワーク（ｅＵＴＲＡＮ）から成り、これらのアクセスノードはコアネットワークへ連結されている。ｅＵＴＲＡＮ技術において、アクセスノードはｅＮＢ（enhanced  Node  Basestation）と呼ばれる。従前提案されていたシステムにおいて使用されるような別個の無線ネットワークコントローラ（ＲＮＣ）はもはや必要とされず、その機能の一部はｅＮＢに組み込まれ、一部はＭＭＥ（Mobility  Management  Entity）に組み込まれ、一部はＳＡＥ  ＧＷ（System  Architecture  Evolution  GateWay）に組み込まれる。ｅＮＢは、ＬＴＥにおいてＥＰＣ（evolved  packet  core）と呼ばれるコアネットワークへ接続する。
【０００７】
図１は、ＬＴＥに関しプロトコルレイヤ間の関係を示す。ＰＤＣＰ（Packet  Data  Convergence  Protocol）は、ＲＬＣ（Radio  Link  Control）レイヤの上にあるＬＴＥユーザプレーンレイヤ２プロトコルスタックの最上サブレイヤである。ＰＤＣＰレイヤは、制御プレーンにおけるＲＲＣ（Radio  Resource  Control）メッセージのような制御プレーンメッセージと、ユーザプレーンにおけるＩＰ（Internet  Protocol）パケットのようなユーザプレーンパケットとを処理する。無線ベアラに依存して、ＰＤＣＰレイヤの主な機能は、ヘッダ圧縮、セキュリティ（インテグリティ保護及び暗号化）、並びにハンドオーバ中の並べ替え及び再送信のサポートである。ＰＤＣＰパケットは、上位レイヤへのパケットの順序正しい配信と、欠落パケットの潜在的な再送信を伴うそれら欠落パケットの特定とを可能にするシーケンス番号（Sequence  Number）（ＳＮ）を含む。また、ＳＮは、ユーザプレーン及び制御プレーンの暗号におけるセキュリティのために、さらに、制御プレーンにおけるＲＲＣデータのインテグリティ保護のために使用される。同等のプロトコル構造は３Ｇプロトコルにおいて存在する。
【０００８】
図２は、ユーザ設備１１０、２つのｅＮＢ１２０、１２１、及びサービング・ゲートウェイ（ＳＧＷ又はＳ−ＧＷ）１３０の間のネットワークトポロジを表す。Ｕｕ無線インターフェースがマークされており、図１において‘Ｕｕ’とのマークを付された破線に対応し、同様に、図２においてマークされたＳ１−Ｕインターフェースは、図１において‘Ｓ１−Ｕ’とのマークを付された破線に対応する。ユーザ設備１１０及びｅＮＢ１２０は、Ｕｕ無線インターフェースを介して通信する。２つのｅＮＢ１２０及び１２１は、有線Ｘ２インターフェースを介して互いと通信する。
【０００９】
ＬＴＥ−Ａは、セルエッジでのユーザ設備へのデータスループットを改善するようツールとして中継するためのサポートを提供することによって、ＬＴＥ  Ｒｅｌ−８を拡張する。また、中継は、グループ・モビリティや一時的なネットワーク開発を改善し、且つ／あるいは、新しいエリアにおいてカバレッジを提供することができる。ＬＴＥ−Ａは、説明に役立つ実例として使用されるが、中継は、他の電気通信プロトコルにおいてサポートされ、例えば、同様の中継技術はＩＥＥＥ標準８０２．１６ｊにおいて存在する。
【００１０】
図３は、ユーザ設備１１０が中継ノード１４０を介してドナーｅＮＢ（ＤｅＮＢ）１２０と通信する構成におけるネットワークトポロジを示す。ユーザ設備１１０は、Ｕｕ無線インターフェースを介して中継ノード１４０と通信する。中継ノード１４０は、Ｕｎ無線インターフェースを介してＤｅＮＢ１２０と通信する。ＤｅＮＢ１２０及びｅＮＢ１２１は、Ｘ２インターフェースを介して通信する。ＤｅＮＢ１２０及びｅＮＢ１２１は夫々、Ｓ１−Ｕインターフェースを介してｓＧＷ１３０と通信する。
【００１１】
中継ノード１４０は、ドナーセルにサービスを提供するドナーノード１２０を介して無線アクセスネットワークへ無線により接続する。ＬＴＥ−Ａは、特に、「インバンド」接続により中継ノードにサポートを提供する。この接続において、ネットワーク−中継間リンクは、ドナーノードによってサービスを提供されるドナーセル内の直接ネットワーク−ＵＥ間リンクと同じバンドを共有する。また、他の電気通信プロトコルは、「アウトバンド」接続をサポートしてよい。この接続において、ネットワーク−中継間リンクは、ドナーノードによってサービスを提供されるドナーセル内の直接ネットワーク−ＵＥ間リンクと同じバンドでは動作しない。具体的に、ＬＴＥ−Ａは「タイプ１」中継ノードをサポートする。タイプ１中継ノードは、ＴＲ３６．９１２（“Feasibility  Study  for  Further  Enhancements  for  E-UTRA（LTE-Advanced）”）において提示されるように、以下によって特徴付けられる：
・それは１又はそれ以上のセルを制御し、セルの夫々はドナーセルとは異なった別個のセルとしてユーザ設備に対して現れる；
・１又はそれ以上のセルは各自の物理セルＩＤ（ＬＴＥ  Ｒｅｌ−８において定義される。）を有し、各自の同期チャネル、参照シンボル及び他のパラメータを送信する；
・単一セル動作との関連で、ユーザ設備は中継ノードから直接スケジューリング情報及びＨＡＲＱフィードバックを受信し、その制御チャネル（ＳＲ／ＣＱＩ／ＡＣＫ）を中継ノードへ送信する。
【００１２】
中継が使用される場合に、ハンドオーバ中のデータ損失を回避する問題が通常のハンドオーバ（ｅＮＢからｅＮＢ）においてよりも重要となる。一般的に、「ハンドオーバ」は、ｅＮＢにおける変化を伴うか否かを問わず（１つのｅＮＢはアンテナ構成に依存して複数のセルを提供することが可能である。）、ユーザ設備のサービングセルにおける何らかの変化をいう。なお、本明細書において、「ハンドオーバ」は、通常は、ユーザ設備が中継ノードである第１の「ソース」ノードに接続されなくなり、代わりに第２の「目標」ｅＮＢへ接続されるようになり、よって、（通常は、ユーザ設備が目標ｅＮＢのより近くに移動した結果として）ソースノードから目標ｅＮＢへユーザ設備に対する責任を移す処理をいう。
【００１３】
ハンドオーバがソースノードとして中継ノードを伴う場合の問題の原因は、ハンドオーバにおける２つの無線インターフェース、すなわち、ソース又は目標ノードとユーザ設備との間のＵｕ無線インターフェース、並びにソース及び目標ノードと中継との間のＵｎ無線インターフェースの関与である。
【００１４】
（本願において図４として再現される）図１０．１．２．１．１−１における３ＧＰＰ  ＴＳ３６．３００  ｖ９．１．０（２００９年９月）（3rd  Generation  Partnership  Project;  Technical  Specification  Group  Radio  Access  Network;  Evolved  Universal  Terrestrial  Radio  Access  (E-UTRA)  and  Evolved  Universal  Terrestrial  Radio  Access  Network  (E-UTRAN);  Overall  description;  Stage  2;  Technical  Specification  (Release  9)）は、直接的にｅＮＢ間でのメッセージの交換によって行われるハンドオーバを示す。ハンドオーバ（ＨＯ）完了フェーズの間のソース側でのリソースの解放は、ｅＮＢによってトリガされる。
【００１５】
Ｒ２−０９３７３５（3GPP  TSG  RAN  WG2  Meeting  #66bis、米国ロサンゼルス、２００９年６月２９日〜７月３日、“Joint  PDCP  on  Uu  and  Un  Interfaces  to  improve  type-1  relay  handover”）は、中継局（ソースノードとして動作する。）から目標局へのユーザ設備のハンドオーバのための方法を詳述し、この方法において、（中継局とドナー局との間の）Ｕｎインターフェースにわたって使用されるＰＤＣＰシーケンス番号は、（ユーザ設備と中継局／目標局との間の）Ｕｕインターフェースにわたって使用されるＰＤＣＰシーケンス番号と関連付けられる。パケットは、サービング・ゲートウェイ（ｓＧＷ）から、中継のための制御基地局であり且つハンドオーバの目標でもあるＤｅＮＢへ転送される。通常、これは、ユーザ設備が中継局のカバレッジエリアからＤｅＮＢのカバレッジエリア内に移動している場合に起こる。ハンドオーバの前に、パケットは全てＤｅＮＢでバッファリングされ、Ｕｎ無線インターフェースを介して中継局へ送信される。次いで、中継局は、Ｕｕインターフェースを介してユーザ設備へパケットを送信する。また、中継局は、パケットをバッファに記憶する。
【００１６】
ユーザ設備へのパケットの転送が成功すると、それらのパケットは中継局及びＤｅＮＢの両方においてバッファから削除される。しかし、ハンドオーバが、例えば、ユーザ設備が中継局のカバレッジエリアから目標（この場合、ＤｅＮＢ）のカバレッジエリア内に移動したために、起こる場合に、一部のパケットは中継局からユーザ設備へうまく送信されないことがある。送信に失敗したそのようなパケットは、（再送信がうまくいきそうにないとしても）再送信のために中継局で待ち行列に入れられる。
【００１７】
ハンドオーバにより、ＤｅＮＢは中継局へパケットを送信するのを止める。しかし、幾つかのパケットは、最初のパケット送信の失敗及びＤｅＮＢから中継局へのパケット送信の中止からの期間において中継局へ送信されてしまうことが起こり得る。
【００１８】
中継ノードからＤｅＮＢへのＰＤＣＰステータスレポートは、ユーザ設備において全面的に承認されるパケット及び承認されないパケットの夫々のＰＤＣＰシーケンス番号をＤｅＮＢに知らせる。Ｕｕインターフェースにわたって使用されるＰＤＣＰシーケンス番号とＵｎインターフェースにわたって使用されるＰＤＣＰシーケンス番号との関連付けにより、中継局は、ＵｕＰＤＣＰシーケンス番号をＵｎＰＤＣＰシーケンス番号に変換することができる。最後に、ＤｅＮＢは、ユーザ設備による受信に成功したと特定されるデータパケットをバッファから削除することができる。
【００１９】
Ｒ２−０９３７３５において記載される方法は、幾つかの欠点を有する：
・ユーザ設備にあるとの確認が成功するまでデータは常にＤｅＮＢにおいてバッファリングされているので、ＤｅＮＢにおけるバッファは大きくなければならない；
・ＰＤＣＰ  ＳＮステータスがなくなる場合、ＤｅＮＢバッファはオーバフローしうる；
・Ｕｎ及びＵｕ無線インターフェースからのＰＤＣＰ番号を結合することは、柔軟性を低減する；
・この方法は、どのパケットがユーザ設備によって受信されるのかを特定するために、周期的なＰＤＣＰステータスリポートに依存する。それらのリポートは、貴重なリソースである無線インターフェース上でオーバヘッドに相当する。
【００２０】
Ｘ２シグナリングは、ダウンリンク及びアップリンクの両方のデータのためのステータス転送であり、ハンドオーバ中の制御プレーン・シグナリングの通信及びユーザプレーン・データパケットの転送を可能にする。ＬＴＥネットワークにおいて、Ｘ２インターフェースは、任意にＤｅＮＢと中継局との間でセットアップされて、データのハンドオーバを可能にする。Ｒ２−０９４５５９（3GPP  TSG  RAN  WG2  #67、中華人民共和国深川、２００９年８月２４日〜２８日、“UE  handover  for  Type-1  relay”）は、中継局から目標ノードへのユーザ設備のハンドオーバを管理するための２つのメカニズムを記載している。第１のメカニズムにおいて、ＤｅＮＢは、中継局へ／からのＸ２シグナリングをモニタしない。しかし、ＤｅＮＢは、ユーザ設備ハンドオーバが起ころうとしているとの通知を中継局から受け取った後、ユーザ設備へ向けられているデータをバッファリングし始める。このバッファリングの開始は、ＤｅＮＢが中継局へ／からのＸ２シグナリングをモニタしないので、中継局によって開始されなければならない。例えば、それは、「トンネルセットアップコマンド（tunnel  set-up  command）」を介してよい。ＤｅＮＢは、データをバッファリングし始めると、ユーザ設備へのダウンリンクデータ送信を中止する。バッファリングされたデータは、後に、目標ノードへ直接転送される。
【００２１】
「中継のためのエンドマーカ（End  marker  for  relay）」（ＥＭ＿Ｒ）データパケットは、ＤｅＮＢと中継局との間で送信される。中継局がＥＭ＿Ｒを受信する場合、中継局は、問題になっているユーザ設備に関し、ＤｅＮＢがもはやダウンリンクデータパケットを転送しないと知る。ＤｅＮＢが中継局からＥＭ＿Ｒを受信する場合、ＤｅＮＢは、中継局においてバッファリングされたがユーザ設備によって未だ承認されていないダウンリンクデータがＤｅＮＢへ送り返されたと分かる。次いで、中継局からの受信データはＤｅＮＢから目標ノードへ転送される。
【００２２】
第２のメカニズムにおいて、ＤｅＮＢは、中継局へ／からのＸ２シグナリングをモニタする。従って、「中継のためのスタートマーカ（start  marker  for  relay）」（ＳＭ＿Ｒ）パケットは、ハンドオーバ要求がＤｅＮＢによって受信されると直ぐに、ダウンリンクデータに挿入され、ＤｅＮＢは、ＳＭ＿Ｒに続くユーザ設備を対象とした全てのダウンリンクデータをバッファリングする。ＳＭ＿Ｒはバッファリングより先にあり、従って、どのパケットがバッファリングされたかに関して如何なる情報も含むことができない。中継局及びＤｅＮＢは両方とも、ＳＭ＿Ｒに続くパケットを第１のパケットとして設定し、それにより、ダウンリンクデータパケットは同期する。中継局からＤｅＮＢへの中継ハンドオーバ・ステータスレポートは、ユーザ設備への配信に成功したパケット及び成功しなかったパケットをＤｅＮＢに知らせる。承認されなかったパケットは、ＤｅＮＢから目標ノードへ直接送信される。ＳＭ＿Ｒ以前の如何なる承認されなかったパケットも、ステータスレポートに続いて中継局からＤｅＮＢへ転送される。
【発明の概要】
【課題を解決するための手段】
【００２３】
本発明の第１の態様の実施形態に従って、方法は、中継ノードを介したドナーノードとの通信から目標ノードとの通信への通信システムにおけるユーザ設備のハンドオーバにおいて提供され、前記ドナーノードは、順次マークを付された一連のドナーパケットにおいてダウンリンクデータを前記中継ノードへ送信するよう動作し、次いで、前記中継ノードは、同じく順次マークを付された一連の中継パケットにおいて前記ダウンリンクを前記ユーザ設備へ送信するよう動作する。当該方法は、前記ドナーノードでハンドオーバ要求を受信し、受信時に前記ドナーノードで一時バッファにおける前記ドナーパケットのバッファリングを開始するステップと、前記ユーザ設備によって受信されたと見なされなかった前記中継パケットの第１の中継パケットを示すステータスメッセージを前記中継ノードから前記ドナーノードへ送信するステップと、前記一時バッファにおいてバッファリングされた第１のドナーパケットを示すアップデートメッセージを前記ドナーノードから前記中継ノードへ送信するステップとを有する。
【００２４】
有利に、ハンドオーバ要求を受信した後にのみ一時バッファにおいてダウンリンクデータをバッファリングすることは、通常動作の間にこのようにダウンリンクデータをバッファリングすることよりも有効である。
【００２５】
有利に、中継ノードとドナーノードとの間のメッセージの定義された交換は、ドナーノードが、もしあれば、ユーザ設備へ配信されたと見なされなかったどのデータが一時バッファに記憶されていないのかを特定することを可能にすることができる。それは、通信プロトコル及び目標ノードの識別に依存して、目標ノードへ転送する必要がありうる、ユーザ設備による受信に成功したと見なされなかったデータである。従って、中継ノードは、一時的なデータバッファの開始をマークするデータパケットに気付くべきである。配信できなかったデータパケットの如何なる転送も中継局によって要求される場合に、どのデータパケット、従ってどのデータが前記一時バッファに記憶されるのかの認識は、どのデータを転送すべきかの決定を知らせる。
【００２６】
さらに、通信システムがＬＴＥ及びＬＴＥ−Ａ  ｅＮＢを含む混成ネットワークにおいて動作しており、目標ノードがＬＴＥ  ｅＮＢである場合に、本発明を具現する方法は、ソースノードとして動作する中継局からユーザ設備を受け入れるために、ＬＴＥ  ｅＮＢに対してなされるべき変更を最小限とする。
【００２７】
本発明の実施形態は、ハンドオーバがデータ損失を伴わずに起こることを可能にすることができる。具体的に、中継ノードからユーザ設備へのデータパケットの配信は中止することができ、データパケット配信は、ハンドオーバ処理中にデータパケットを失うことなく、目標ノードからユーザ設備へ再開する。
【００２８】
ユーザ設備は、電話機又はＰＤＡのようなモバイル端末であってよいが、そのようなデバイスに限られない。例えば、デスクトップ型のパーソナルコンピュータが、そのような通信システムの中継ノードへ接続してよい。
【００２９】
通信システムは、有線又は無線通信システムであってよいが、更なる実施形態において、幾つかの特徴は、無線通信システムにおける使用に制限される場合がある。特に、通信システムは、ＬＴＥ−Ａ通信プロトコルに従って動作するのに適する。ＬＴＥ−Ａプロトコルの場合において、ドナーノードはｅＮＢアクセスノードである。更なる代替案として、通信システムはＬＴＥ  ｅＮＢ及びＬＴＥ−Ａ  ｅＮＢを含む混成ネットワークにおいて動作していることがあり得る。そのようなネットワークにおいて、ドナーノードはＬＴＥ−Ａ  ｅＮＢであるべきであるが、目標ノードはＬＴＥ  ｅＮＢ又はＬＴＥ−Ａ  ｅＮＢのいずれであってもよい。
【００３０】
しばしば、目標ノードはドナーノードである場合がある。通常、これは、ユーザ設備が中継ノードのカバレッジエリアからドナーノードのカバレッジエリアに移動している場合に起こる。
【００３１】
順次マークを付されたデータパケットは、シーケンス番号、又はデータの一義的な順序付けを可能にするために範囲内でのパケットの位置を定義するよう加えられ得る何らかの他の情報を含んでよい。ドナーパケットは、ドナーノードから中継ノードへ送信されるデータパケットである。語「ドナーパケット」は、中継ノードからユーザ設備へ送信されるデータパケットである中継パケットと区別するために使用される。ドナーパケット及び中継パケットは両方とも、単に、例えばユーザデータを含むデータパケットとして見なされ得る。望ましくは、夫々のドナーパケットは、同じダウンリンクデータを含む中継パケット又はそのコピーに対応する。この対応は一対一の対応であってよく、夫々の中継パケットは唯一のドナーパケットからのダウンリンクデータを含む。ヘッダデータ、順次マーキング、又は他の情報は、中継パケットを対応するドナーパケットと区別することができる。代替的に、中継パケットはドナーパケット又はドナーパケットの逐語的なコピーであってよく、それにより、それらは実際には同じパケットであると考えられ得る。
【００３２】
ハンドオーバ要求は、ソースノード（ハンドオーバの前のサービングノード）として動作する中継ノードによって送信されるメッセージであってよい。ハンドオーバは、通常、隣接セルに対するサービングセル（サービングノードによってサービスを提供されるエリア）の測定される品質におけるオフセットが設定された閾値よりも大きくなり、且つ、設定されたトリガ時間（time-to-trigger）が経過した場合に、実行される。代替的に、ハンドオーバは、例えば、許容閾値を下回るサービス品質（quality  of  service）（ＱｏＳ）測定の低下によって実行されてよく、あるいは、それは、何らかの他の要因によって、例えば、ソースノード及び目標ノードに対する相対距離に基づいて、促されてよい。
【００３３】
ハンドオーバの後、ユーザ設備は、目標ノードと直接通信することができる。なお、目標ノード自体が中継ノードであってよい。また、目標ノードはｅＮＢ、ホームｅＮＢ（ＨＥＮＢ）、又はドナーノードであってよい。
【００３４】
任意に、中継ノードは、ドナーパケットを逆アセンブルし、それらを、潜在的に異なる順次マーキングを伴うが依然としてダウンリンクデータの一部又は全てを含む中継パケットとして再アセンブルする。順次マーキングが異なるとしても、シーケンスは維持される。これは、ダウンリンクデータの再パッケージングであると考えられ得る。
【００３５】
一時バッファは、受信が中継ノードによって認証されるまで、データパケット（又はそのコピー）を記憶する従来の送信バッファへの付加であり、一時バッファは、配信の確認応答が中継ノードから受信される場合にパケットを削除しない。一時バッファはドナーパケット（又はそのコピー）を記憶する。一時バッファにおけるバッファリングは、ハンドオーバ要求の受信直後に開始してよく、あるいは、それは、アドミッション制御（admission  control）の処理がドナーノードで開始された場合に開始してよい。
【００３６】
ステータスメッセージは、単に、中継ノードによって送信され且つパケットの順次マーキングを用いてユーザ設備によって受信されたと見なされなかった第１の中継パケットを示してよい。また、このステータスメッセージは、例えば、一部のパケットがユーザ設備によって認証されたが一部のパケットは認証されなかった場合に、一連の送信パケットのうち正確にどのパケットが転送される必要があるのかに関するさらに詳細な情報を含むことも可能である。これは、どのビットがユーザによる受信に成功したのかと、どのビットがユーザによる受信に成功しなかったのかとを示すよう、ステータスメッセージに加えて、又はその一部として、ビットマップを用いることによって達成されてよい。
【００３７】
データパケットは、中継ノードによってユーザ設備へ決して送信されなかったために、配信されなかったと見なされることがある。あるいは、それは、配信がユーザ設備によって認証されなかったために、決して配信されなかったと見なされることがある。そのような認証は、例えば、ユーザ設備から中継ノードへ送信される確認応答メッセージの形をとってよい。データパケットが配信されなかったと見なされるための明確な条件は、当該方法が適用される通信プロトコルに依存する。
【００３８】
ＬＴＥ又はＬＴＥ−Ａプロトコルを用いる実施形態におけるステータスメッセージは、ＰＤＣＰ制御情報メッセージとして、又はＲＲＣメッセージとして、送信されてよい。
【００３９】
望ましくは、アップデートメッセージはドナーノードから中継ノードへ送信され、一時バッファに記憶されるよう第１のデータパケットによって搬送される順次マーキングを示す。
【００４０】
ＬＴＥ又はＬＴＥ−Ａプロトコルを用いる実施形態におけるアップデートメッセージは、ＰＤＣＰ制御情報メッセージとして、又はＲＲＣメッセージとして、送信されてよい。
【００４１】
本発明の一態様の実施形態に従って、当該方法は、前記ユーザ設備によって受信されたと前記中継ノードによって見なされなかった中継パケットであって、前記一時バッファにおいてバッファリングされた前記第１のドナーパケットよりも順番的に早い中継パケットからの全てのダウンリンクデータを、前記中継ノードから前記ドナーノードへ、アップリンク転送するステップをさらに有する。中継ノードは、データパケットのどれがユーザ設備へ配信されたと見なされないのかを知り、アップデートメッセージの受信後に、さらに、どのデータパケットが一時バッファに記憶されるよう順番的にもっとも早い（一番である）のかを知る。
【００４２】
一時バッファの開始よりも順番的に早い未配信のデータパケットからのデータをドナーノードへ転送することは、ドナーノードがユーザ設備への配信に失敗した全てのダウンリンクデータのコピーを有することを確かにする。ドナーノードが目標ノードである場合に、再送信が試みられ得る。ドナーノードが目標ノードでない場合には、ユーザ設備への配信に失敗したダウンリンクデータは目標ノードへ転送され得る。
【００４３】
未配信のパケットからのデータを転送することは、データパケットの逆アセンブル及び再アセンブルを含んでよく、それにより、順次マーキングは、データパケットのシーケンスを維持しながら、ドナーノードから中継ノードへの送信において使用されるものから独立している。
【００４４】
中継ノードからドナーノードへ転送されるデータパケットは、アップリンクデータパケットである。中継ノードからドナーノードへ、すなわち、アップリンク方向において転送される未配信データのデータパケットは他のアップリンクデータと区別され得ず、よって、ユーザ設備への再送信のための又は目標ノードへの転送のためのデータとしてドナーノードによって識別されないことが、幾つかの提案されているハンドオーバ方法において問題である。本発明の好ましい実施形態は、転送されるデータパケットにおけるデータがハンドオーバ要求の目標ノードへの転送を対象とするとのドナーノードへのインジケーションを前記転送されるデータパケットに付加することをさらに有する。
【００４５】
それらの転送パケットは、新しい順次マーキングを受け入れてよく、あるいは、専用の無線ベアラ（radio  bearer）（ＲＢ）識別（論理チャネルＩＤ）によって、及び／又はドナーノードから中継ノードへドナーパケットを送信するためにそもそも使用されていた順次マーキング（例えば、Ｕｎ  ＰＤＣＰ  ＳＮ）を埋め込むことによって、ドナーノードに対して識別されてよい。代替的に、ドナーノードから中継ノードへ中継パケットを送信するために使用される順次マーキング（例えば、Ｕｕ  ＰＤＣＰ  ＳＮ）が代わりに埋め込まれてよいが、これは、順次マーキングの各組の間のマーキングがドナーノードで知られている場合にのみ有効である。また、転送されるデータパケットは、データへのヘッダフィールドの付加によって、ドナーノードに対して識別されてよい。一例はＧＴＰ−Ｕプロトコル（General  Packet  Radio  Service  Tunneling  Protocol）の使用であり、そのプロトコルに従って、ヘッダは、データパケットを転送データとして識別するよう、データパケットに加えられる。
【００４６】
本発明を具現する方法が、ドナーノードが目標ノードでもない場合において使用される場合に、当該方法は、望ましくは、前記ドナーノードから前記目標ノードへ前記一時バッファにおける前記ドナーパケットからのデータを転送するステップを有する。それらは、未だユーザ設備への転送に成功していないデータであり、従って、ユーザ設備への送信のためにそれらを目標ノードへ転送することが望ましい。
【００４７】
ドナーパケットが、中継パケットとしてのユーザ設備への送信のために中継ノードで、逆アセンブル及び再アセンブルをされる、あるいは、単に並べ替えられる場合に、ドナーノードは、中継パケットにおいて使用されるマーキングのうちどれが一時バッファに記憶されたどのパケットに対応するのかに気付くことができない。任意に、ドナーパケットの順次マーキングは中継パケットの順次マーキングと相違し、夫々の中継パケットは、中継パケットが対応するドナーパケットからのダウンリンクデータを含む点で、ドナーパケットに対応し、ステータスメッセージは、ユーザ設備によって受信されたと見なされない中継パケットの第１の中継パケットを特定するよう、対応するドナーパケットの順次マーキングを使用する。有利に、このようにドナーパケットの順次マーキングを使用することは、転送データが対応するドナーパケットの順次マーキングを有するデータパケットにおいて中継ノードから受信されると正確なデータが目標ノードへ転送されることを、ドナーノードが確かにすることを可能にする。
【００４８】
望ましくは、ドナーパケットからのデータの順序は、中継パケットへの再アセンブル時に維持される。順次マーキングは、それらが同じ付番方式を用いるが、一方は他方に対してオフセットされるという意味では、互いに相違しうる。それにより、ふた組のマーキングの間にはギャップ又はオーバラップが存在する。代替的に、異なるマーキング方式が、順次マーキングの各組において用いられてよい。
【００４９】
本発明の好ましい実施形態は、前記中継パケットの連続的なマーキングを用いて前記ユーザ設備によって受信されたと見なされなかった前記第１の中継パケットを示す更なるステータスメッセージを前記中継ノードから前記目標ノードへ送信することを含む。
【００５０】
有利に、上記のステータスメッセージ及び更なるステータスメッセージの組み合わせは、目標ノードが、中継パケットをユーザ設備へ送信する際に用いられる順次マーキングを、ドナーノードから転送される（ドナーパケットの順次マーキングを用いて番号付けされた）対応するデータパケットに有効にマッピングすることを、あるいは、ドナーノードが目標ノードである場合には、中継パケットの順次マーキングを一時バッファ内のデータパケットにマッピングすることを、可能にする。目標ノードからユーザ設備へ順次転送又は再送信される如何なるデータパケットも、正確にマークを付され得る。そのようなデータパケットは、次いで、ユーザ設備によって受信され、正確な順序において、シーケンスにおけるギャップによりエラーが生じることなく処理され得る。
【００５１】
本発明の実施形態が適用されるハンドオーバ・シナリオにおいて、中継ノードはソースノードである。ハンドオーバ要求が中継ノードによって発せられると、中継ノードは、間もなく、ダウンリンクデータをユーザ設備へ送信するのを止める。しかし、本発明の実施形態においては、ドナーノードでのハンドオーバ要求の受信と、中継ノードからのユーザ設備の分離との間には、有限な期間の時間が存在する。この有限な時間期間の間、ドナーノードは、受信した全てのダウンリンクデータパケットを一時バッファに記憶する。本発明の実施形態は、前記ドナーノードから前記中継ノードへ前記一時バッファにおけるドナーパケットのダウンリンクデータを送信することを更に含んでよい。有利に、中継ノードは、次いで、ユーザ設備へ送信することができないパケットの数を減らすために、ユーザ設備へのデータパケットの送信を続けることができる。ハンドオーバが失敗するならば、中継局はデータパケットを有しており、即座に送信を再開することができる。すなわち、より速い回復が、ハンドオーバが後退する場合において、可能にされる。任意に、一時バッファからのデータを中継ノードへ転送し続ける機能がアクティブであるか否かを決定するために使用される設定、例えば、ＲＲＣ（Radio  Resource  Control）設定が定められてよい。
【００５２】
望ましくは、本発明の実施形態は、前記ドナーノードで、前記データパケットのコピーが前記中継ノードによって受信されたとの確認応答を受信すると、前記一時バッファにおいて対応するデータパケットを保持することをさらに有する。ハンドオーバの間、ドナーノードから中継ノードへ配信されるパケットがユーザ設備への配信に成功するとは想定されない。従って、中継ノードへ配信されるデータパケットに対応するデータパケットをドナーノードの一時バッファに保持することは、ユーザ設備への直接の再送信のために又は目標ノードへの転送のためにドナーノードへアップリンク方向において配信データパケットを転送する必要性を取り除く。
【００５３】
ユーザ設備による受信に成功したと見なされない一連の中継パケットが、ユーザ設備への配信の成功した時折の中継パケットによって中断される場合に、配信に成功した中継パケットからのデータは、別個の目標ノードを介するか、又は直接に、ユーザ設備への再送信のために中継ノードからドナーノードへ不必要に転送されることがある。任意に、本発明の実施形態は、所定のシーケンスの中継パケットのうち前記ユーザ設備によって受信されたと見なされなかった中継パケットのインジケーションを前記中継ノードから前記ドナーノードへ送信することをさらに含んでよい。このインジケーションは、一連の送信パケットのうち正確にどのパケットが中継ノードからドナーノードへ転送される必要があるのかに関するさらに詳細な情報の形で、ステータスメッセージに含まれてよい。例えば、ビットマップは、どのデータがユーザ設備への配信に成功したのかを示すよう、ステータスメッセージに含まれるか、又はステータスメッセージに加えて送信される。代替的に、別個のステータスレポートが、アップデートメッセージの後に、中継ノードからドナーノードへ送信されてよい。いずれの場合にも、転送されるデータの量は低減され得る。ビットマップは、処理のために受信データを順序づける際に使用されるよう、最終的にユーザ設備へ送信されてよい。
【００５４】
本発明の実施形態の他の態様に従って、方法は、ＬＴＥ−Ａプロトコルに従って動作する通信システムにおいて使用される。望ましくは、かかる方法において、ドナーノードは、ＬＴＥ−Ａプロトコルに従うドナーエンハンスドノード基地局（ＤｅＮＢ）である。
【００５５】
本発明の実施形態の他の態様に従って、ユーザ設備が中継ノードを介してドナーノードと通信する第１の構成から、前記ユーザ設備が目標ノードと通信する第２の構成へのハンドオーバを実行するよう動作する通信システムであって、前記第１の構成に従う通信時に、前記ドナーノードは、順次マークを付された一連のドナーパケットにおいてダウンリンクデータを中継ノードへ送信するよう動作し、次いで、前記中継ノードは、順次マークを付された一連の中継パケットにおいて前記ダウンリンクを前記ユーザ設備へ送信するよう動作する、通信システムが提供される。前記ハンドオーバの実行において、前記ドナーノードは、ハンドオーバ要求を受信し、受信時に、一時バッファにおける前記ドナーパケットのバッファリングを開始するよう動作し、前記中継ノードは、前記ユーザ設備によって受信されたと見なされなかった第１の中継パケットを示すステータスメッセージを前記ドナーノードへ送信するよう動作し、前記ドナーノードは、前記一時バッファにおいてバッファリングされた第１のドナーパケットを示すアップデートメッセージを前記中継ノードへ送信するよう動作する。
【００５６】
本発明の他の態様に従って、ユーザ設備が中継ノードを介してドナーノードと通信する第１の構成から、前記ユーザ設備が目標ノードと通信する第２の構成へのハンドオーバを実行するよう動作する通信システムにおける使用のための中継ノードであって、前記第１の構成に従う通信時に、当該中継ノードは、順次マークを付された一連のドナーパケットにおいて前記ドナーノードからダウンリンクデータを受信し、順次マークを付された一連の中継パケットにおいて前記ダウンリンクを前記ユーザ設備へ送信するよう動作する、中継ノードが提供される。前記ハンドオーバの実行において、当該中継ノードは、前記ユーザ設備によって受信されたと見なされなかった第１の中継パケットを示すステータスメッセージを前記ドナーノードへ送信するよう動作し、当該中継ノードは、前記ドナーノードでハンドオーバ要求の受信時にドナーパケットをバッファリングし始めた一時バッファにおいてバッファリングされた第１のドナーパケットを示すアップデートメッセージを前記ドナーノードから受信するよう動作する。
【００５７】
本発明の実施形態の他の態様に従って、電気通信ノードのコンピュータデバイスで実行される場合に、前記電気通信ノードを上記の中継ノードとするコンピュータプログラムが提供される。
【００５８】
本発明の実施形態の他の態様に従って、ユーザ設備が中継ノードを介してドナーノードと通信する第１の構成から、前記ユーザ設備が目標ノードと通信する第２の構成へのハンドオーバを実行するよう動作する通信システムにおける使用のためのドナーノードであって、前記第１の構成に従う通信時に、当該ドナーノードは、順次マークを付された一連の中継パケットとしての前記ユーザ設備へのその後の送信のために、同じく順次マークを付された一連のドナーパケットにおいてダウンリンクデータを前記中継ノードへ送信するよう動作する、ドナーノードが提供される。前記ハンドオーバの実行において、当該ドナーノードは、ハンドオーバ要求を受信し、受信時に、一時バッファにおける前記ドナーパケットのバッファリングを開始し、且つ、前記ユーザ設備によって受信されたと見なされなかった第１の中継パケットを示すステータスメッセージを前記中継ノードから受信するよう動作し、当該ドナーノードは、前記一時バッファにおいてバッファリングされた第１のドナーパケットを示すアップデートメッセージを前記中継ノードへ送信するよう動作する。
【００５９】
本発明の実施形態の他の態様に従って、電気通信ノードのコンピュータデバイスで実行される場合に、前記電気通信ノードを上記のドナーノードとするコンピュータプログラムが提供される。
【００６０】
当業者には明らかなように、記載又は請求される本発明の実施形態の特徴は、他の実施形態の特徴と容易に組み合わされてよい。特に、記載される通信システム、中継ノード、ドナーノード、又は他の装置は、記載される方法を実行する手段又は機能を有してよい。
【図面の簡単な説明】
【００６１】
【図１】ＬＴＥに関してプロトコルレイヤ間の関係を示す。
【図２】ＬＴＥに関して簡単なネットワークアーキテクチャを示す。
【図３】中継ノードを含むＬＴＥネットワークアーキテクチャを示す。
【図４】先行技術におけるｅＮＢ間の直接のメッセージ交換によって実行されるハンドオーバを示す。
【図５】ソースノードが中継ノードであり且つ目標ノードが関連するドナーノードであるハンドオーバを表す。
【図６】本発明を具現する方法を表すフローチャートである。
【図７】本発明を具現する制御シグナリング及びバッファリング処理の説明図である。
【図８】本発明の実施形態においてデータ転送の制御におけるシーケンス番号シグナリングを示す図である。
【図９】ソースノードが中継ノードであり且つ目標ノードがドナーノード以外のｅＮＢであるハンドオーバを表す。
【図１０】目標ノードがドナーノード以外のｅＮＢである本発明の実施形態においてデータ転送の制御におけるシーケンス番号シグナリングを示す図である。
【発明を実施するための形態】
【００６２】
単に一例として、添付の図面を参照して、以下、本発明の実施例を記載する。
【００６３】
図５は、通信システムにおけるコンポーネント及びそれらのコンポーネントの間のインターフェースを示す。ハンドオーバ前の第１の構成が矢印の左側に示されている。矢印の右側には、ハンドオーバ後の第２の構成がある。
【００６４】
第１の構成は、無線インターフェースＵｕを介して中継ノード２４０と通信するユーザ設備２１０を示す。中継ノード２４０は、Ｕｎ無線インターフェースを介してドナーエンハンスドノード基地局（ＤｅＮＢ）２２０と通信する。ＤｅＮＢ２２０は、中継ノード２４０に対するドナーノードとして動作する。ＤｅＮＢ２２０は、Ｘ２インターフェースによりエンハンスドノード基地局（ｅＮＢ）２２１と通信し、且つ、Ｓ１−Ｕインターフェースによりサービング・ゲートウェイ（ｓＧＷ）２３０と通信する。ｓＧＷ２３０は、Ｓ１−Ｕインターフェースを介してｅＮＢ２２１とも通信する。
【００６５】
第１の構成から第２の構成に達するために、ハンドオーバが実行され、このハンドオーバにおいて、ソースノードは中継ノード２４０であり、目標ノードは、第１の構成において中継ノード２４０に対するドナーノード２２０であったＤｅＮＢである。
【００６６】
第１の構成において、ｓＧＷ２３０からユーザ設備２１０へ伝わるダウンリンクデータは、最初に、ｓＧＷ２３０からＤｅＮＢ２２０へ送信される。データは、連続するデータパケット又は単一のデータユニット（ＳＤＵ）において送信されてよい。連続するデータパケットにおいて送信される場合に、その一連のデータパケットは順次マークを付されてよく、それにより、夫々のデータパケットは番号又はマーキングを含み、それによって、夫々のデータパケットは、例えば処理のために、順番に置かれ得る。ＤｅＮＢ２２０によって受信されたデータパケットは、逆アセンブルされ、そして、中継ノード２４０へ送信される前に、新しいパケットに再アセンブルされてよい。夫々の再アセンブルされたパケットは、対応する逆アセンブルされたパケットからのダウンリンクデータを含んでよく、その対応するパケットに対して同一又は実質的に同一であるが別なふうにマークを付されてよい。代替的に、ＤｅＮＢ２２０によって受信されたデータパケットは、単純に中継ノード２４０へ送信されてよい。ダウンリンクデータを含み且つＤｅＮＢ（すなわち、ドナーノード）２２０から中継ノード２４０へ送信された、又はそのように送信されるよう意図された一連の順次マークを付されたデータパケットは、ドナーパケットと称されるべきである。
【００６７】
中継ノード２４０によって受信されたダウンリンクデータは、次いで、ユーザ設備２１０へ送信される。先と同じく、データは、連続するデータパケットにおいて送信されてよい。連続するデータパケットにおいて送信される場合に、その一連のデータパケットは、順次マークを付されてよく、それにより、夫々のデータパケットは番号又はマーキングを含み、それによって、夫々のデータパケットは、例えば処理のために、順番に置かれ得る。データが一連のデータパケットとして中継ノード２４０によって受信された場合に、それらのパケットは、逆アセンブルされ、そして、ユーザ設備２１０へ送信される前に、新しいパケットに再アセンブルされてよい。夫々の再アセンブルされたパケットは、対応する逆アセンブルされたパケットからのダウンリンクデータを含んでよく、その対応するパケットに対して同一又は実質的に同一であるが別なふうにマークを付されてよい。代替的に、中継ノード２４０によって受信されたデータパケットは、単純にユーザ設備２１０へ送信されてよい。ダウンリンクデータを含み且つ中継ノード２４０（すなわち、ドナーノード）からユーザ設備２１０へ送信された、又はそのように送信されるよう意図された一連の順次マークを付されたデータパケットは、中継パケットと称されるべきである。
【００６８】
第２の構成において、中継ノード２４０は、Ｕｎ無線インターフェースを介してＤｅＮＢ２２０と通信することができる。しかし、ユーザ設備２１０は、Ｕｕ無線インターフェースを介してＤｅＮＢ２２０と直接通信することができる。中継ノードはユーザ設備２１０とＤｅＮＢ２２０との間で必要とされない。
【００６９】
第２の構成において、ｓＧＷ２３０からユーザ設備２１０へ伝わるダウンリンクデータは、最初に、ｓＧＷ２３０からＤｅＮＢ２２０へ送信される。データは、連続するデータパケット又は単一のデータユニット（ＳＤＵ）において送信されてよい。連続するデータパケットにおいて送信される場合に、その一連のデータパケットは順次マークを付されてよく、それにより、夫々のデータパケットは番号又はマーキングを含み、それによって、夫々のデータパケットは、例えば処理のために、順番に置かれ得る。ＤｅＮＢ２２０によって受信されたデータパケットは、逆アセンブルされ、そして、ユーザ設備２１０へ送信される前に、新しいパケットに再アセンブルされてよい。夫々の再アセンブルされたパケットは、対応する逆アセンブルされたパケットからのダウンリンクデータを含んでよく、その対応するパケットに対して同一又は実質的に同一であるが別なふうにマークを付されてよい。代替的に、ＤｅＮＢ２２０によって受信されたデータパケットは、単純にユーザ設備へ送信されてよい。
【００７０】
図６は、本発明を具現する方法を表すフローチャートである。ステップＳ１で、ドナーノード２２０、例えば、基地局又はＤｅＮＢは、ハンドオーバ要求を受信する。ハンドオーバ要求は、ユーザ設備２１０で起こり、ユーザ設備２１０から送信されてよい。通常、ハンドオーバ要求は、隣接セルに対するサービングセル（サービングノードによってサービスを提供されるエリア）の測定される品質におけるオフセットが設定された閾値よりも大きくなり、且つ、設定されたトリガ時間が経過した場合に、行われる。代替的に、ハンドオーバ要求は、ＱｏＳインジケータが所定の閾値を下回ることによって、トリガされてよい。
【００７１】
ステップＳ２で、ドナーノード２２０は、一時バッファにおけるドナーパケットのバッファリングを開始する。一時バッファは、通信コンポーネントにおいて共通する送信バッファとは異なる。
【００７２】
ハンドオーバ要求は、中継パケットをユーザ設備２１０へ配信することにおける何らかの問題に起因して、発せられてよい。ステップＳ３で、ステータスメッセージは、ユーザ設備２１０によって受信されたと見なされなかった第１（本明細書における「第１」は、順番的により早いことを意味する。）の中継パケットのインジケーションを含んで中継ノード２４０からドナーノード２２０へ送信される。インジケーションは、第１の未配信の中継パケットのダウンリンクデータを含むデータパケット、すなわち、対応するデータパケットに属する順次マーキングを参照してなされてよい。
【００７３】
ステップＳ４で、ドナーノード２２０は、一時バッファに記憶されている第１のドナーパケットを示すアップデートメッセージを中継ノード２４０へ送信する。
【００７４】
図７は、本発明を具現する制御シグナリング及びバッファリング処理を表す。アップリンク及びダウンリンクユーザデータ経路は、図の一番上に示されている。図の残りの部分は、ハンドオーバの処理を表す。中継ノード２４０は、それがハンドオーバ処理におけるソースノードであることを示すよう、（Ｓ）を付されている。これに対して、ドナーノード２２０は、それがハンドオーバ処理における目標ノードであることを示すよう、（Ｔ）を付されている。
【００７５】
以下の例においては、ダウンリンクデータはユーザデータであり、それはＰＤＣＰパケットにおいて送信される。ドナー（データ）パケット４、５、６は夫々、中継（データ）パケット１５、１６、１７に対応する。転送されるデータパケットＸ、Ｙ、Ｚは夫々、中継パケット１５、１６、１７に対応する。
【００７６】
図の上方に示されているデータパケット４、５、６は、Ｕｎ無線インターフェースを介して送信され、中継ノード２４０においてドナーノード２２０から受信され、次いで、ユーザ設備２１０への送信のために中継ノード２４０におけるＰＤＣＰエンティティへ転送される。この転送は、中継ノード２４０とユーザ設備２１０との間のＵｕインターフェースにわたる送信のためのＵｎＰＤＣＰパケットの逆アセンブル及びＰＤＣＰパケットの再アセンブルを伴う。この再アセンブルは、潜在的に、Ｕｎインターフェースにわたって順次マーキングとして使用されるＰＤＣＰシーケンス番号（４、５、６）とは異なるＰＤＣＰシーケンス番号を順次マーキングとして使用する。再アセンブルされたＰＤＣＰパケットは、ＵｕＰＤＣＰシーケンス番号１５、１６及び１７を有するパケットとして示されており、これらのパケットは夫々、ＵｎＰＤＣＰシーケンス番号４、５及び６を有するパケットに対応する。
【００７７】
この実施形態において、中継ノード２４０とドナーノード２２０との間の無線リンク制御（ＲＬＣ）レベルプロトコルは、データパケット４、５、６が中継ノード２４０によって受信されたことを認めるために使用される。次いで、パケット４、５及び６は、ドナーノード２２０で送信バッファから削除される。
【００７８】
×印で終わるデータ転送経路は、失敗したデータ送信を表す。
【００７９】
ＵｕＰＤＣＰシーケンス番号１５、１６、１７を有するデータパケットはユーザ設備２１０への配信に成功したと見なされていないので、中継ノード２４０はハンドオーバ又はハンドオフ決定Ｐ３を行う。次いで、ハンドオーバ要求メッセージＭ４が中継ノード２４０からドナーノード２２０へ送信される。
【００８０】
この実施形態において、ドナーノード２２０は、中継ノード２４０からハンドオーバ要求Ｍ４を受信した後にダウンリンクデータパケットを（一時ダウンリンクバッファに）バッファリングし、そして、ハンドオーバが差し迫っていると思われることを認識しているので、成功したアドミッション制御処理Ｐ５を実行し始めることができる。同時に、ドナーノード２２０は、バッファリングされたデータパケットを中継ノード２４０へ転送する。データパケットは、中継ノード２４０への配信が認証された後でさえ、一時ダウンリンクバッファから削除されない。
【００８１】
コールアドミッション制御は、要求されるベアラが無線混雑状態（congestion）の場合に確立されるべきか否かを決定するｅＮＢにおけるプロシージャである。コールアドミッション制御は、セルにおけるリソース状況、新しいエボルブド・パケット・システム（Evolved  Packet  System）（ＥＰＳ）に対するＱｏＳ要求、並びにそのｅＮＢにおけるアクティブなセッションのための現在許可されているＱｏＳレベル及び優先レベルを考慮する。コールアドミッション制御アルゴリズムはｅＮＢベンダー特有であり、（３ＧＰＰによって）標準化されていない。
【００８２】
ハンドオーバ要求確認応答メッセージＭ６は、ドナーノード２２０から中継ノード２４０へ送信される。
【００８３】
例において、ＤｅＮＢは、一時ＤＬバッファにおいて７以降のＵｎＰＤＣＰシーケンス番号を有するデータパケットを記憶する。ドナーノード２２０が一時ダウンリンクバッファにおけるバッファリングを開始する前に、一時ダウンリンクバッファに記憶されているＵｎＰＤＣＰシーケンス番号４、５又は６を有するデータパケットは中継ノード２４０へ予め送信されているので、ＤｅＮＢはそれらのデータパケットを有さない点に留意すべきである。
【００８４】
メッセージＭ７ＲＲＣ接続再設定（Connection  Reconfiguration）は、中継ノード２４０からユーザ設備２１０へ送信される。ＲＲＣ接続再設定は、中継ノード（又は他のｅＮＢ）とユーザ設備との間のシグナリング無線ベアラ（signaling  Radio  Bearer）（ｓＲＢ）を確立し維持する。処理Ｐ６は、ソースノードからユーザ設備２１０を引き離し、ユーザ設備２１０を目標ノードと同期させる。
【００８５】
メッセージＭ８は中継ノード２４０からドナーノード２２０へ送信され、ユーザ設備２１０によって受信されたと見なされなかった第１のデータパケットのＵｕＰＤＣＰシーケンス番号をドナーノード２２０に知らせる。
【００８６】
ステップＳ３で、ＰＤＣＰ制御情報メッセージ「ＳＮステータス」Ｍ８ａが、ステータスメッセージとして中継ノード２４０からドナーノード２２０へ送信される。ＳＮステータスメッセージＭ８ａによって、中継ノード２４０は、ユーザ設備２１０によって受信されたと見なされなかった第１のダウンリンクデータパケットのＵｎＰＤＣＰシーケンス番号をドナーノード２２０に知らせる。これよりも大きいＵｎＰＤＣＰシーケンス番号を有する全てのＰＤＣＰデータパケットは、目標ノードへ転送される必要がある。
【００８７】
また、ＳＮステータスメッセージＭ８ａは、例えば、一部のパケットがユーザ設備２１０によって受信されたと確認され、一部のパケットが確認されなかった場合に、一連の送信パケットのうち正確にどのパケットが転送される必要があるのかに関するさらに詳細な情報を含むことも可能である。これは、どのビットがユーザによる受信に成功したのかを示すようＳＮステータスメッセージに加えて又はその一部としてビットマップを用いることによって、達成され得る。
【００８８】
ステップＳ４で、ＰＤＣＰ制御情報メッセージ「ＳＮステータスアップデート」Ｍ８ｂが、アップデートメッセージとしてドナーノード２２０から中継ノード２４０へ送信される。ドナーノード２２０は、一時ダウンリンクバッファをチェックし、第１の未受信データパケットのＵｎＰＤＣＰシーケンス番号以上のＵｎＰＤＣＰシーケンス番号を有するデータパケットのうち、自身が順次マーキングとしてＵｎＰＤＣＰシーケンス番号４、５、６を有するデータパケットを有していないと特定する。次いで、ドナーノード２２０は、ＳＮステータスアップデートＭ８ｂによって、自身が一時ダウンリンクバッファにおいてバッファリングした第１のダウンリンクデータパケット（パケット７）のそのＵｎＰＤＣＰシーケンス番号を中継ノード２４０に知らせる。ステップＳ５で、中継ノード２４０は、アップリンク方向において、ドナーノード２２０が一時ダウンリンクバッファにおいてバッファリングしていないデータパケットのうち未配信のダウンリンクデータのみを転送する。図７の例において、中継ノード２４０はドナーノード２２０へパケット４、５及び６のみを転送する。
【００８９】
本発明の実施形態において、Ｕｎ及びＵｕＰＤＣＰシーケンス付番は異なる（４、５、６−＞１５、１６、１７）。ドナーパケット及び中継パケットは夫々、ＵｎＰＤＣＰシーケンス付番及びＵｕＰＤＣＰシーケンス付番により番号付けされる。シーケンスの位置が互いに無関係であるとしても、同じシーケンスが維持される。順次マーキングはシーケンス番号に制限されず、データの一義的な又は実質的に一義的な順序づけを可能にするために範囲内でのパケットの位置を定義するよう使用され得るその他の情報にまで及ぶ。
【００９０】
ＳＮステータスＭ８ａは、ＳＮステータス転送Ｍ８において示されるＵｕＰＤＣＰシーケンス番号に対応するＵｎＰＤＣＰシーケンス番号を示す。ＵｎＰＤＣＰシーケンス番号は、目標ノードへ転送される必要がある第１のデータパケットを正確に特定するために使用される（４からマッピングされる１５）。さらに、何らかのユーザ設備識別が、目標ノードからユーザ設備２１０への送信の成功のために必要とされてよい。
【００９１】
ＳＮステータスアップデートＭ８ｂは、ドナーノード２２０が一時ダウンリンクデータバッファにおいてバッファリングした第１のダウンリンクデータパケットを特定するために使用される。アップリンク方向において中継ノード２４０から目標ノードへ転送されるデータは、以下の範囲内でユーザ設備２１０によって未だ受信されていないデータパケットからの全てのデータである：
第１のパケット＝ＵｕＰＤＣＰシーケンス番号（１５）
最後のパケット＝ＵｕＰＤＣＰシーケンス番号（１７）（ドナーノードがＵｎＰＤＣＰシーケンス番号＝７から一時ダウンリンクバッファにおけるバッファリングを開始した場合）
ドナーノードへの転送を要するデータパケットが存在しない場合には、ＳＮステータスアップデートＭ８ｂを省略することが可能であってよい。
【００９２】
それらのパケットは、異なるＰＤＣＰアップリンクシーケンス番号Ｘ、Ｙ、Ｚを受け入れるが、専用の無線ベアラ識別又は論理チャネルＩＤ（ＬＣＩＤ）及び埋め込まれた原のＰＤＣＰＵｕシーケンス番号によってドナーノード２２０に対して識別されてよい。
【００９３】
図８は、中継ノード２４０からアップリンク方向においてドナーノード２２０へ、次いで新しい無線インターフェースリンクＵｕ（ｔ）を介してユーザ設備２１０へ転送される正確なデータパケットを決定するための制御シグナリングの使用の例を示す。この実施形態において、パケット１、２、３は、ｓＧＷ２３０からドナーノード２２０へ配信され、そして、Ｕｕインターフェースを介した配信に成功しユーザ設備２１０に認証される前に、Ｕｎ無線インターフェースを介して中継ノード２４０へ転送される。パケット４、５、６は成功裏に配信されて、Ｕｎインターフェースを介して（ドナーノード２２０から中継ノード２４０へ）配信されたと認証されるが、（中継ノード２４０からユーザ設備２１０へ）Ｕｕインターフェースを介しては未だ認証に成功していない。図は、どのようにこの実施形態においてＰＤＣＰシーケンス番号がＵｎ（ドナーパケット）からＵｕ（中継パケット）インターフェースまで相違するのかを示す。
【００９４】
図８において、ドナー（データ）パケット４、５、６は夫々、中継（データ）パケット１５、１６、１７に対応する。転送されるデータパケットＸ、Ｙ、Ｚは夫々、中継パケット１５、１６、１７に対応する。
【００９５】
一時バッファは「ＤＬデータバッファ」とマークを付されており、順次マーキング‘７’、すなわち、ＵｎＰＤＣＰシーケンス番号‘７’を有するドナーパケットから始める。
【００９６】
図８において、（ＵｕＰＤＣＰシーケンス番号１５、１６、１７を有するデータパケットに対応する）ＵｎＰＤＣＰシーケンス番号４、５、６を有するデータパケットは、ドナーノード２２０から中継ノード２４０へ送信され、認証され、その後、ドナーノードの送信バッファから削除されている。このときハンドオーバが行われていると、如何なるデータも失われることなくハンドオーバが完了されるために、ドナーノード２２０へ送り返されるべきそれらのパケットは次いで目標ノード（この場合にはドナーノード２２０）へ、そして、新しい無線インターフェース（Ｕｕ（ｔ））を介してユーザ設備２１０へ転送されることが望ましい。
【００９７】
ＳＮステータスメッセージＭ８ａは、転送されるデータパケットが始まるべきデータパケットのシーケンス番号（中継ノードからのみ知られ得る情報）を特定する。ＳＮステータスメッセージＭ８ａによって特定されるシーケンス番号は、ユーザ設備２１０によって受信されなかったと見なされたデータパケットの順番的に最も早い番号である。次いで、ＳＮステータスアップデートＭ８ｂは、ドナーノード２２０によって一時ダウンリンクバッファにおいてバッファリングされた第１のパケットについてシーケンス番号を特定する。
【００９８】
メッセージＭ８は、中継ノード２４０から目標ノード（この場合には、ドナーノード２２０）へのＳＮステータス転送である。ＳＮステータス転送メッセージＭ８は、ＰＤＣＰステータス維持が適用するＥＵＴＲＡＮ無線アクセスベアラ（EUTRAN  Radio  Access  Bearers）（Ｅ−ＲＡＢｓ）の（すなわち、無線リンク制御認証モードのための）ダウンリンクＰＤＣＰシーケンス番号トランスミッタステータスを運ぶ。Ｅ−ＲＡＢｓは、ユーザ設備コンテクストがｅＮＢによってサービスを提供されるセルにおいて利用可能である場合に、ユーザデータ・トランスポートのためのリソースを確立し、変更し、及び解放するために使用される。ダウンリンクＰＤＣＰシーケンス番号トランスミッタステータスは、目標ノードが未だＰＤＣＰシーケンス番号を有していない新しいデータパケットへ割り当てるべき次のＵｕＰＤＣＰシーケンス番号を示す。ＳＮステータス転送Ｍ８は、ユーザ設備２１０が目標ノードへ再送信する必要があるシーケンスアップリンクデータパケットの範囲外のレシーバステータスのビットマップを更に含んでよい。このメッセージの送信は、ユーザ設備のＥ−ＲＡＢｓのいずれもＰＤＣＰステータ維持を利用するモードにおいて動作していない場合は、省略されてよい。
【００９９】
メッセージＭ８ａは、ＳＮステータスメッセージである。この実施形態において、中継ノード２４０は、アップリンクＵｎＰＤＣＰＳＮレシーバステータス及びダウンリンクＵｎＰＤＣＰＳＮトランスミッタステータスを運ぶようＵｎＳＮステータス転送メッセージを目標ノードへ送信する。このステータスメッセージＭ８ａは、対応する中継パケットが配信に成功したとしてユーザ設備２１０によって認証されていないＵｎインターフェースにわたって配信された最後のドナーパケットのシーケンス番号を搬送する。目標ノードがドナーノード２２０でもある場合に、このシーケンス番号は、ドナーノード２２０がＵｕシーケンス番号をＵｎシーケンス番号にマッピングすることを可能にすることによって、目標ノードへ転送される必要がある第１のＰＤＣＰＰＤＵに正確なシーケンス番号を付加するよう、前のＳＮステータス転送Ｍ８とともにドナーノード２２０によって使用され得る。また、このメッセージの受信は、正確なＵｕＰＤＣＰシーケンス番号が、ドナーノード２２０からユーザ設備２１０への送信のために一時バッファに記憶されているデータパケット（図においてＵｎＰＤＣＰシーケンス番号７、８を付されているもの）に付加されることを可能にする。
【０１００】
メッセージＭ８ｂは、アップデートメッセージとして中継ノード２４０からドナーノード２２０へ送信されるＳＮステータスアップデートメッセージである。ＳＮステータスアップデートは、ドナーノード２２０が一時バッファにおいてバッファリングした、又は一時バッファにおいてバッファリングを開始された第１のダウンリンクデータパケット（ドナーパケット）を示すために使用される。このステータスアップデートメッセージは、目標ノードへのその後の転送のためにどのパケットがドナーノード２２０へ配信されるべきかを中継ノード２４０が知るように、必要とされる。ハンドオーバ中の一時バッファ及びこの信号を用いないと、全てのドナーパケット（４、５、６、７、８）が中継ノード２４０からドナーノード２２０へ転送される必要があるので、Ｕｎリソースが浪費される。
【０１０１】
ＵｎＰＤＣＰシーケンス番号４、５、６を有するドナーパケットは、アップリンク方向において中継ノード２４０からドナーノード２２０へ転送される。それらのパケットは、逆アセンブル及び再アセンブルをされて、再アセンブルされたデータパケットに埋め込まれたＵｎＰＤＣＰシーケンス番号により順次マーキングＸ、Ｙ、Ｚを与えられる。
【０１０２】
この場合に目標ノードであるドナーノード２２０は、次いで、受け取った転送データパケットＸ、Ｙ、Ｚからのデータを新しいＵｕ無線インターフェースＵｕ（ｔ）を介してユーザ設備２１０へ送信することができる。データは、順次マーキング１５、１６、１７によりマークを付されたデータパケットにおいて、無線インターフェースＵｕ（ｔ）を介して送信される。ここで、１５は、ユーザ設備２１０によって受信されたと見なされなかった中継パケットのＵｕインターフェースＰＤＣＰシーケンス番号（中継パケット順次マーキング）のうち最も早いものである。
【０１０３】
任意に、ＰＤＣＰステータスレポートは、ＳＮステータスアップデートメッセージＭ８ｂの後にトリガされ得る。このＰＤＣＰステータスレポートは、どのパケットがユーザ設備へ成功裏に配信されたと見なされなかったのかを正確に特定するために使用されてよい。このステータスレポートは、転送又は再送信されるデータの一部が既にユーザ設備２１０へ成功裏に配信されている場合に、ドナーノード２２０から目標ノードへ転送される、及び／又は目標ノードからユーザ設備２１０へ再送信されるデータの量を減らすことができる。ＰＤＣＰステータスレポートの代替として、最終的にユーザ設備２１０へ転送される必要がある欠落データパケットのビットマップも使用され得る。
【０１０４】
データパケットがアップリンク方向において中継ノード２４０からドナーノード２２０へ転送される場合に、それらの転送データパケットが新しい目標ノードへのデータ転送を対象としたデータパケットであることをドナーノード２２０が特定するために、何らかのメカニズムが提供されてよい。これは、幾つかの方法において達成され得る。例えば、一意の識別子が、データとともに送信される特定の論理チャネルＩＤ（ＬＣＩＤ）を用いることによって、データパケットのストリームに割り当てられてよい。この特定のＬＣＩＤは、中継ノード２４０からアップリンク方向においてやって来る転送データパケットが、新しい目標ノードへの、最終的にユーザ設備２１０への転送を対象としたデータを含むデータパケットであることを、ドナーノード２２０が特定するのを可能にする。この特定のＬＣＩＤは、中継ノード２４０とドナーノード２２０との間でＵｎインターフェースにわたってセットアップされ得、これは、セミスタティック無線リソース制御（ＲＲＣ）シグナリングによって制御され得る。代替的に、それらのデータパケットは、ＭＡＣレベル制御シグナリングを用いることによって、転送データを含むと特定されてよい。
【０１０５】
複数のユーザ設備２１０が単一の中継ノード２４０へ接続される場合に、ユーザ設備２１０ごとの中継パケットの識別が必要とされる。これを達成する１つの方法は、Ｕｎ（ドナーノードから中継ノードへの）無線インターフェースを介して転送される夫々のＰＤＣＰデータパケットにユーザ設備識別データフィールドを付加することである。代替的に、ユーザ設備ごとの固有の無線ベアラ（ＲＢ）がＵｎインターフェースにわたってセットアップされ得、これはセミスタティック無線リソース制御（ＲＲＣ）シグナリングによって制御され得る。更なる代替案として、ヘッダが、データが対象とするユーザ設備を特定するためにＧＴＰ−Ｕプロトコルに従ってデータパケットに付加されてよい。
【０１０６】
図９は、通信システムにおけるコンポーネント及びそれらのコンポーネントの間のインターフェースを示す。コンポーネント及びコンポーネント間のインターフェースの幾つかの詳細な説明は、図５に関連して先に記載されたので、ここでは省略される。ハンドオーバ前の第１の構成が矢印の左側に示されている。矢印の右側には、ハンドオーバ後の第２の構成がある。図９に示される実施形態において、ドナーノード２２０及び目標ノード２２１は別個のエンティティである。
【０１０７】
第１の構成及び第１の構成におけるダウンリンクデータの経路は、図５に関連して先に記載されたとおりのものである。
【０１０８】
第１の構成から第２の構成に達するために、ハンドオーバが実行され、このとき、ソースノードは中継ノード２４０であり、目標ノードはｅＮＢ２２１である。
【０１０９】
第２の構成において、中継ノード２４０は、Ｕｎ無線インターフェースを介してＤｅＮＢ２２０と通信することができる。しかし、この場合にハンドオーバは実行されず、ユーザ設備２１０は、Ｕｕ無線インターフェースを介して目標ノード２２１と直接通信している。
【０１１０】
第２の構成において、ｓＧＷ２３０からユーザ設備２１０へ伝わるダウンリンクデータは、最初に、ｓＧＷ２３０から目標ノード２２１へ送信される。また、目標ノード２２１は、ハンドオーバ処理中に配信に成功したと見なされなかったドナーノード２２０からの転送データを受信していてよい。第１の転送データは、中継ノード２４０からドナーノード２２０への送信に成功した最後のデータパケットのシーケンス番号に続く次のシーケンス番号によりマークされてよい。代替的に、その次のシーケンス番号は、転送データ内に埋め込まれてよい。
【０１１１】
図９において、目標ノード２２１は、中継ノード２４０に関してＤｅＮＢ２２０に隣接するｅＮＢである。通常、ドナーノード２２０に隣接する目標ノード２２１へのハンドオーバは、ユーザ設備が中継ノード２４０のカバレッジエリアから、ソース中継ノード２４０のＤｅＮＢ２２０でないｅＮＢのカバレッジエリア内に移動する場合に、起こる。このハンドオーバがデータ損失なしで起こるよう、メカニズムは、中継ノードによるパケットの配信を中止し、ハンドオーバ処理中にパケットを失うことなく目標ノードからのパケット配信を再開するよう実施される必要がある。この場合に、未配信のデータパケットは、目標ｅＮＢ２２１へ転送される前に、最初にＵｎインターフェースを介して中継ノード２４０からＤｅＮＢ２２０へアップリンク方向において転送されるべきである。
【０１１２】
図１０は、中継ノード２４０からＤｅＮＢ２２０へ、次いで新しい無線インターフェースリンクＵｕ（ｔ）を介してユーザ設備２１０へ転送される正確なデータパケットを決定するための制御シグナリングの使用の例を示す。この図において、ＵｕＰＤＣＰシーケンス番号１５、１６、１７を有するデータパケットは、ＤｅＮＢ２２０から中継ノード２４０へ送信され、認証され、ＤｅＮＢ２２０の送信バッファから削除されている。しかし、それらのデータパケットは、ユーザ設備２１０への配信に成功したと見なされていない。「ＤＬデータバッファ」とマークを付された、ＤｅＮＢ２２０にある一時データバッファは、ＵｎＰＤＣＰシーケンス番号‘７’を有するデータパケットまで、ダウンリンクデータパケットのバッファリングを開始しない。このときハンドオーバが行われている場合、ＵｕＰＤＣＰシーケンス番号１５、１６、１７を有するデータパケットは、ＤｅＮＢ２２０へ転送され、次いで目標ノード（この場合には、異なるｅＮＢ）へ、そして新しい無線インターフェースＵｕ（ｔ）を介してユーザ設備２１０へ転送されるべきである。また、一時バッファからのデータパケット（ＵｎＰＤＣＰシーケンス番号７及び８を有するデータパケット）は、ＤｅＮＢ２２０から目標ノード２２１へ転送され、次いでＵｕ（ｔ）無線インターフェースを介してユーザ設備２１０へ送信されるべきである。
【０１１３】
図１０において、ドナー（データ）パケット４、５、６は夫々、中継（データ）パケット１５、１６、１７に対応する。転送されるデータパケットＸ、Ｙ、Ｘは夫々、中継パケット１５、１６、１７に対応する。
【０１１４】
この場合に、制御信号、ステータスメッセージＭ８ａ、及びアップデートメッセージＭ８ｂが使用されることが見られる。中継ノード２４０からＤｅＮＢ２２０へのステータスメッセージＭ８ａは、ユーザ設備２１０への配信に成功したと見なされなかった第１のＵｕＰＤＣＰデータパケットに対応するＵｎＰＤＣＰシーケンス番号（中継ノード（ソース）２４０からしか知られ得ない情報）を特定する。ＤｅＮＢ２２０から中継ノード２４０へのアップデートメッセージＭ８ｂは、ＤｅＮＢ２２０で一時バッファにおいてバッファリングされた第１のデータパケットについて開始ＵｎＰＤＣＰシーケンス番号を特定する。
【０１１５】
さらに、この場合に、パケットは目標ノード２２１へ転送される。この転送に使用されるシーケンス番号は、Ｕｎインターフェースにわたって使用されるもの同じであり、木曜ノード２２１おいてのみ、ＳＮステータス転送メッセージＭ８信号は、新しいＵｕ（ｔ）インターフェースにわたる配信のためにＳＮステータス転送メッセージＭ８において特定されるＵｕＰＤＣＰシーケンス番号により番号付けされた目標ノード２２１へ転送されるデータパケットのうち第１のデータパケットを有するＰＤＣＰデータパケットに正確に番号付けを行うために使用される。
【０１１６】
一時バッファに記憶されるデータパケット（図１０においてＵｎＰＤＣＰシーケンス番号７、８を付されているもの）は、また、ドナーノード２２０から目標ノード２２１へ転送される。目標ノード２２１で、ドナーノードの一時バッファからのデータパケットは、正確なＵｕＰＤＣＰシーケンス番号（図１０においては、１８及び１９）をラベル付けされ、ユーザ設備２１０へ送信される。
【０１１７】
語「データパケット」は、一般的に、上記の説明において用いられる。なお、当業者には明らかなように、「単一データユニット」又は「ＳＤＵ」のような等価な語が「データパケット」の直接的な相当語句として使用されてよい。語「データパケット」は、「ドナーパケット」及び「中継パケット」の両方を包含すると見なされるべきである。「ドナーパケット」は、ドナーノード２２０から中継ノード２４０へ送信されるデータパケットである。ドナーパケットの順次マーキングは、ＵｎＰＤＣＰシーケンス番号であってよい。「中継パケット」は、中継ノード２４０からユーザ設備２１０へ送信されるデータパケットである。中継パケットの順次マーキングは、ＵｕＰＤＣＰシーケンス番号であってよい。
【０１１８】
本明細書において論じられるデータパケットからのダウンリンクデータは、ユーザデータであると考えられてよい。
【０１１９】
上記の態様のいずれにおいても、様々な特徴は、ハードウェアにおいて、又は１以上のプロセッサで実行されるソフトウェアモジュールとして、実施されてよい。一態様の特徴は、他の態様のいずれに適用されてもよい。
【０１２０】
また、本発明は、ここに記載されている方法のいずれかを実行するコンピュータプログラム又はコンピュータプログラムプロダクト、及びここに記載されている方法のいずれかを実行するプログラムを記憶したコンピュータ読み取り可能な媒体を提供する。本発明を具現するコンピュータプログラムは、コンピュータ読み取り可能な媒体に記憶されてよく、あるいは、それは、例えば、インターネットウェブサイトから提供されるダウンロード可能なデータ信号のような信号の形をとってよく、あるいは、それはその他の形態をとってよい。
【図１】
2013513988.tif 000003
【図２】
2013513988.tif 000004
【図３】
2013513988.tif 000005
【図４】
2013513988.tif 000006
【図５】
2013513988.tif 000007
【図６】
2013513988.tif 000008
【図７】
2013513988.tif 000009
【図８】
2013513988.tif 000010
【図９】
2013513988.tif 000011
【図１０】
2013513988.tif 000012
【国際調査報告】
2013513988.tif 000013
2013513988.tif 000014