トップ :: H 電気 :: H04 電気通信技術




【発明の名称】 ＭＡＣ層リセット後にノードＢバッファデータを効率的に回復するためのシステム
【発明者】 【氏名】スティーブン イー．テリー

【氏名】イ−ジュ チャオ
【要約】 【課題】ノードＢバッファデータを効率的に回復すること。

【構成】伝送待ち時間を削減し、ＭＡＣ層リセット時のＰＤＵの損失を潜在的に防ぐための方法およびシステムに関する。状況ＰＤＵのＵＥ生成は、ＭＡＣ層リセットと結合される。ＲＮＣは、ＭＡＣリセットインジケーションを備えたメッセージを生成する（１６）。ＭＡＣ層リセットに続いて、ＵＥのＭＡＣ層再順序付けバッファに格納されたすべてのＰＤＵがＲＬＣエンティティにフラッシュされ（２２）、その後、ＰＤＵ状況報告の生成（２６）に先立ってＲＬＣエンティティによって処理される（２４）。ＰＤＵ状況報告は、首尾良く受信されたすべてのＰＤＵの状況をＲＮＣに提供する。ＲＮＣでＰＤＵ状況報告が受信されると（２８）、欠落したＰＤＵが認識され、ＵＥに再送される（３０）。
【特許請求の範囲】
【請求項１】
ノードＢバッファデータを効率的に回復するためのシステムであって、少なくとも１つのノードＢに関連付けられた無線ネットワークコントローラ（ＲＮＣ）を含み、さらに少なくとも前記ノードＢは、無線ネットワークコントローラ（ＲＮＣ）から送信されたパケットデータユニット（ＰＤＵ）をバッファリングするための少なくとも１つの再順序付けバッファを有する少なくとも１つのユーザ機器（ＵＥ）に関連付けられており、
ＭＡＣ層リセット通知を生成するための無線ネットワークコントローラ（ＲＮＣ）と、
前記通知を受信するため、および前記少なくとも１つの再順序付けバッファをフラッシュするための、前記ユーザ機器（ＵＥ）内のコントロールユニットと、
前記再順序付けバッファのフラッシュに続いて前記ユーザ機器（ＵＥ）によって受信されたパケットデータユニット（ＰＤＵ）の状況を決定するため、および前記決定に基づいて状況報告を生成するための、前記ユーザ機器（ＵＥ）内の状況手段と、
前記状況報告を前記無線ネットワークコントローラ（ＲＮＣ）に伝送するための伝送手段と
を具えたことを特徴とするシステム。
【請求項２】
前記状況手段は、再順序付けバッファがすべてのパケットデータユニット（ＰＤＵ）をフラッシュしたことを示すコントロール信号に応答して、前記決定を実行することを特徴とする請求項１記載のシステム。
【請求項３】
前記コントロール信号は、バッファ内のすべてのパケットデータユニット（ＰＤＵ）がフラッシュされたときに生成されるパケットデータユニット（ＰＤＵ）の終わりのインジケーションであることを特徴とする請求項２記載のシステム。
【発明の詳細な説明】【技術分野】
【０００１】
本発明は、無線通信の分野に関し、より詳細には、データ伝送の配布元である中間ノードのＭＡＣ層リセット後に、１対のレイヤ２自動反復要求（ＡＲＱ）ピアエンティティ間でのデータ伝送を効率的に回復することに関する。ハンドオーバシナリオの一例として、ハイブリッドＡＲＱ（Ｈ−ＡＲＱ）および適応変調および符号化（ＡＭ＆Ｃ）技法を採用するシステムがある。
【背景技術】
【０００２】
第３世代（３Ｇ）のＵｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（ＵＴＲＡＮ）はいくつかの無線ネットワークコントローラ（ＲＮＣ）を備え、そのそれぞれが１つまたは複数のノードＢに関連付けられ、各ノードＢは１つまたは複数のセルに関連付けられる。
【０００３】
３ＧのＦＤＤおよびＴＤＤシステムは、通常、ＲＮＣを使用してＵＥへのデータ伝送を配布（すなわち、バッファおよびスケジュール）する。しかしながら、３Ｇセルラ式システムの高速チャネルの場合、データはノードＢによって配布される。これら高速チャネルの１つが、たとえば高速ダウンリンク共有チャネル（ＨＳ−ＤＳＣＨ）である。データはノードＢによって配布されるため、伝送のためにデータをノードＢにバッファリングする必要がある。ユーザ機器（ＵＥ）が接続されている配布エンティティ（ノードＢ）が変更された場合、配布エンティティにバッファリングされているデータが損失する恐れがある。データが中間点（ノードＢ）によって配布されるため、ＲＮＣで伝送されるパケットデータユニット（ＰＤＵ）は最新状態ではない。ＵＥにとっては、データ損失を検出し、失われたＰＤＵを状況ＰＤＵなどと共に再送するようＲＮＣに要求することが必要である。状況ＰＤＵの生成が遅れた場合、結果としてデータ再送の待ち時間が長くなり、ＱｏＳ要件を満たせなくなる可能性がある。
【０００４】
この問題は、各ＲＮＣに関連付けられたノードＢがいくつかあり、移動ＵＥは、ＵＥセルのハンドオーバの結果としてＲＮＣの変更よりもノードＢの変更を必要とする可能性の方がはるかに大きいため、ＨＳ−ＤＳＣＨの場合さらに悪化する。
【０００５】
ＨＳ−ＤＳＣＨは、ＡＭＣを利用してデータの高速伝送を可能にし、Ｈ−ＡＲＱを利用してデータ送達が成功する可能性を上げる。サービス（ｓｅｒｖｉｎｇ）ＨＳ−ＤＳＣＨセルを変更するのは、ＵＥがサービスＨＳ−ＤＳＣＨ無線リンクの送信および受信を実行しているＵＴＲＡＮアクセスポイントに関連付けられたセルを変更しなければならない場合である。サービスＨＳ−ＤＳＣＨセル変更が呼び出されるのは、改善された物理チャネル状況および／または改善された物理容量が代替セル内で実現された場合である。
【０００６】
サービスＨＳ−ＤＳＣＨセル変更には２つのタイプがある。ノードＢ内のサービスＨＳ−ＤＳＣＨセル変更は、同じノードＢに関連付けられた２つのセル間でＵＥが換わる場合である。ノードＢ間のサービスＨＳ−ＤＳＣＨセル変更は、異なるノードＢに関連付けられた２つのセル間でＵＥが換わる場合である。ノードＢ間のセル変更では、サービスＨＳ−ＤＳＣＨセル変更前のノードＢをソースノードＢと呼び、サービスＨＳ−ＤＳＣＨセル変更後のノードＢをターゲットノードＢと呼ぶ。
【０００７】
ＲＮＣおよびＵＥのどちらにも、ピア無線リンクコントロール（ＲＬＣ）エンティティがある。送信側ＲＬＣエンティティはＰＤＵヘッダ内のシーケンス番号（ＳＮ）を発信し、受信側ＲＬＣエンティティはこれを使用して伝送中にＰＤＵが欠落しないことを保証する。ＰＤＵの順不同送達によって現実化された、伝送中に欠落したＰＤＵがある場合、受信側ＲＬＣエンティティは状況報告ＰＤＵを送信して、あるＰＤＵが欠落した旨を送信側ＲＬＣエンティティに通知する。状況報告ＰＤＵは、データ伝送の成功および／または失敗を記述するものである。これは、欠落または受信したＰＤＵのＳＮを識別する。ＰＤＵが欠落した場合、送信側ＲＬＣエンティティは欠落したＰＤＵの複製を受信側ＲＬＣに再送することになる。
【０００８】
送信側ＲＬＣエンティティは、受信側ＲＬＣエンティティからの状況報告ＰＤＵをポーリングすることも可能である。このポーリング機能は、送信側ＲＬＣエンティティにＰＤＵ伝送の状況を要求するための機能を提供する。Ｈ−ＡＲＱオペレーションは何らかの失敗した伝送を除去し、データの送達が成功する確率を上げるが、最終的に送達の成功を保証するのはＲＬＣプロトコル層である。
【０００９】
伝播状態が動的に変化するため、ＨＳ−ＤＳＣＨセル変更は、サービスの品質を維持するために迅速に実行しなければならない。サービスＨＳ−ＤＳＣＨセルの変更中、ＵＥは、現在ソースノードＢに格納されているすべてのＰＤＵが首尾良く伝送されるまで、ソースセル内での送信および受信を停止することが可能である。ソースノードＢがデータのスケジューリングおよびバッファリングを実行するため、またデータ速度が非常に速いために（たとえば１０Ｍｂ／秒またはそれ以上）、ＵＥがサービスＨＳ−ＤＳＣＨセル変更を（特にノードＢ間のハンドオーバのために）実行すると、ソースノードＢ内にバッファリングされたかなりの量のデータが失われることになる可能性がある。このデータ損失の理由の１つが、ソースノードＢでバッファリングされたデータをターゲットノードＢに転送するための機構がＵＴＲＡＮアーキテクチャ内に存在しないことである。ＲＮＣにはソースノードＢ内に何のデータがバッファリングされているかを知る手段がないため、サービスＨＳ−ＤＳＣＨセルの変更時に、ＲＮＣはデータがどの程度失われたかに関する情報をもたない。
【００１０】
現在、従来技術のシステムがソースノードＢでバッファリングされたデータの回復を処理するには２つの方法がある。ＨＳ−ＤＳＣＨセルの変更に続いて、１）ＲＮＣが状況ＰＤＵをＵＥから明示的にポーリングすることができるか、または２）ＲＮＣがターゲットセル内での伝送を開始し、ＵＥによって実現される順不同の送達によって状況ＰＤＵを生成することになる。
【００１１】
ＲＮＣが状況ＰＤＵを明示的にポーリングする第１のケースでは、ＲＮＣは第１に、新しいセル内に物理チャネルが確立されるまで待機しなければならない。その後、状況ＰＤＵ要求が送信され、ＵＥによって受信および処理される。ＵＥは状況ＰＤＵを生成してこれをＲＮＣに返送し、ＲＮＣはこの状況ＰＤＵを処理して、どのＰＤＵを再送する必要があるかを決定する。
【００１２】
ＲＮＣがソースセル内で停止された場所からＰＤＵの伝送を開始するだけの第２のケースでは、ＵＥは順不同のデータ送達を認識し、ＲＮＣに返送する状況ＰＤＵを生成する。ＲＮＣは状況ＰＤＵを処理して、どのＰＤＵを再送する必要があるかを習得する。
【００１３】
これら２つのいずれのケースでも、ソースノードＢにバッファリングされたデータを回復する必要がある場合は状況ＰＤＵを処理することになるが、ＵＥによって再送されたデータを正しく受信するのはかなり遅れることになる。これは、ＵＥによる状況ＰＤＵの生成およびＲＮＣでの状況ＰＤＵの受信の遅延が原因である。ＲＬＣ肯定応答モードで伝送が実行されている場合、順序どおりのデータ送達が実行できるまでデータは高位層へは渡されない。したがってＵＥは、欠落したＰＤＵが再送できるまで、順不同データのバッファリングが必要となる。その結果、伝送の遅延が発生するだけではなく、欠落したデータを首尾よく再送できるまでデータを継続して受信するために、ＵＥはデータのバッファリングが可能なメモリを備える必要がある。そうでない場合、有効データ伝送速度が低下し、それによってサービスの品質に影響を与える。メモリは非常に高額であるため、望ましくない設計上の制約である。
【００１４】
ハンドオーバが直面する他の問題は、ＵＥ内にバッファリングされるデータである。ＭＡＣ層には、通常、Ｈ−ＡＲＱ処理を実行するいくつかのＨ−ＡＲＱプロセッサがある。図１に示されるように、Ｈ−ＡＲＱ処理は、送信側（Ｐ１Ｂ〜Ｐ５Ｂ）に複数の並列Ｈ−ＡＲＱプロセッサを備え、受信側（Ｐ１ＵＥ〜Ｐ５ＵＥ）に対応する複数の並列Ｈ−ＡＲＱプロセッサを備えるスキームのことである。それぞれのプロセッサペア（たとえばＰ１ＢとＰ１ＵＥ）は、伝送が成功するまで反復的および逐次的にデータブロックの伝送を試行して、各ブロックのデータがエラーなしで確実に受信されるようにする。各データブロックについて、Ｈ−ＡＲＱ伝送の成功を達成するのに必要な時間は異なる。いくつかのデータブロックが並行して処理されるため、伝送順序が維持されない可能性がある。したがって、受信側Ｈ−ＡＲＱプロセッサによっていったんデータブロックが首尾よく受信されると、ＲＬＣ層への順序どおりの送達を提供するために、そのデータブロックは再順序付け（ｒｅｏｒｄｅｒｉｎｇ）バッファに転送される。再順序付けバッファは、それらの伝送シーケンス番号に基づいてデータブロックを再順序付けした後に、それらをＲＬＣ層に転送することになる。
【００１５】
ノードＢ間またはノードＢ内のハンドオーバ中、ＲＲＣメッセージがＭＡＣ層リセットインジケータをＵＥへ搬送することが多い。ＵＥはＭＡＣ層リセットインジケータを受信すると、構成済みのすべてのＨ−ＡＲＱプロセスについてバッファをフラッシュする（すなわち、再順序付けバッファ内のすべてのＭＡＣ−ｈｓ層ＰＤＵをＭＡＣ−ｄ層ＰＤＵに逆アセンブル（ｄｉｓａｓｓｅｍｂｌｉｎｇ）し、すべてのＭＡＣ−ｄ層ＰＤＵをＭＡＣ−ｄ層に送達した後、関連するＲＬＣエンティティに送達することによって、再順序付けバッファをフラッシュする）ことを含むが、これに限定されることのない、一連の機能を実行する。ノードＢ間のハンドオーバ（および何らかのノードＢ内ハンドオーバ）時には、すべてのＨ−ＡＲＱプロセスおよびすべての再順序付けバッファが、ターゲットノードＢの新しいＭＡＣ−ｈｓエンティティからのデータの受信に対して、ＵＥ内のＭＡＣ−ｈｓ層をリセットする必要がある。
【００１６】
サービスＨＳ−ＤＳＣＨセルの変更後、ＭＡＣ層リセット手順が完了し、データブロックがＲＬＣによって処理されるまで、ＰＤＵ受信の成功または不成功の正しい状況を取得することができない。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
ユーザのサービス品質要件を適切に維持するために、ＵＥ内にバッファリングされたデータについて説明可能なシステムおよび方法を有することが望ましい。
【課題を解決するための手段】
【００１８】
本発明は、伝送待ち時間を削減し、ＭＡＣ層リセット時のＰＤＵの損失を潜在的に防ぐために、ＵＥおよびＲＮＣが一連の動作を実行するための方法およびシステムである。状況ＰＤＵのＵＥ生成はＭＡＣ層リセットと結合される。ＲＮＣは、ＭＡＣリセットインジケーションを備えた信号メッセージを生成する。ＭＡＣ層リセット要求の受信によるＭＡＣ層リセットに続いて、ＵＥのＭＡＣ層再順序付けバッファに格納されたすべてのＰＤＵがＲＬＣエンティティにフラッシュされ、その後、ＰＤＵ状況報告の生成に先立ってＲＬＣエンティティによって処理される。ＰＤＵ状況報告は、首尾良く受信されたすべてのＰＤＵの状況をＲＮＣに提供する。これによって、ＰＤＵ状況報告の迅速な生成が提供される。ＲＮＣでＰＤＵ状況報告が受信されると、欠落したＰＤＵが認識され、ＵＥに再送される。
【００１９】
本発明の好ましい実施形態については、全体を通じて同じ番号が同じ要素を表す図表を参照しながら説明する。
【発明を実施するための最良の形態】
【００２０】
図２の流れ図を参照すると、ＭＡＣ層リセット状態に続く、遅延が最小のＵＥへのＰＤＵ伝送状況を決定する方法１０を備える、本発明の第１の実施形態が示される。この手順は、ＲＮＣがＵＥ ＭＡＣ層をリセットする必要性を認識することで開始される（ステップ１２）。
【００２１】
ＵＥ ＭＡＣ層リセットの起こり得る原因の１つが、サービスＨＳ−ＤＳＣＨセルを変更する場合にある。ＲＮＣは、ノードＢ間のサービスＨＳ−ＤＳＣＨセル変更の場合、および、ソースノードＢがターゲットノードＢと同じであるが、伝送待ち行列はソースセルからターゲットセルへルート変更できない、ノードＢ内のサービスＨＳ−ＤＳＣＨセル変更の場合にも、ＨＳ−ＤＳＣＨセル変更をノードＢに通知する（ステップ１４）。どちらの場合にも、ＭＡＣのリセットが必要である。ＵＥには、ＨＳ−ＤＳＣＨセル変更インジケーションと共に、図に示されるように無線リソースコントロール（ＲＲＣ）メッセージを介して、ＲＮＣによってＭＡＣ層リセット要件が通知される（ステップ１６）。不都合な結果を招くことなしに、ステップ１４に先立ってステップ１６を呼び出すことも可能であることに留意されたい。
【００２２】
当業者であれば、ＭＡＣ層リセットにはＨＳ−ＤＳＣＨセル変更以外に、ＭＡＣリセットに続いてＲＮＣがＰＤＵ伝送状況を決定するための方法１０が適用される、多くの原因があることを理解されよう。たとえば、ノードＢのＨ−ＡＲＱプロセスを再初期化する必要がある場合にはいつでも、ＭＡＣ層リセットを正当化することができる。
【００２３】
ＲＲＣメッセージには、リセットを実行するためのＭＡＣ層に関する識別子がある。この識別子は、サービスＨＳ−ＤＳＣＨセル変更手順の一部とするか、または、結果としてノードＢ間のセル変更またはノードＢ内のセル変更のいずれかでノードＢおよびＵＥでのＭＡＣ層のリセットが生じる、任意の他の手順の一部とすることができる。当業者であれば、ＭＡＣ層にはＭＡＣ−ｈｓ層およびＭＡＣ−ｄ層を含む多くの態様があることを理解されよう。本発明の説明をわかりやすくするために、以下では一般にＭＡＣ層を参照するものとする。
【００２４】
ＨＳ−ＤＳＣＨはデータ移送チャネルである。各データ移送チャネルには複数のＲＬＣインスタンスが存在する可能性がある。ＲＬＣインスタンスは、本来、同じ移送チャネルにマッピングすることが可能な論理チャネルであり、たとえばいくつかのＲＬＣエンティティを単一の移送チャネルＨＳ−ＤＳＣＨにマッピングすることが可能である。ピアＲＬＣインスタンス間での適切な伝送を保証するためにＡＲＱを使用する場合、ＲＬＣインスタンスは肯定応答モード（ＡＭ）と呼ばれる。１対のＡＭ ＲＬＣエンティティは、受信者に関する状況ＰＤＵを使用して、ＰＤＵの伝送成功状況を送信者に示す。ＨＳ−ＤＳＣＨセル変更およびＭＡＣ層リセットの発生に続いて、特定のＨＳ−ＤＳＣＨに関連付けられたそれぞれのＡＭ ＲＬＣインスタンスが状況ＰＤＵを生成する。
【００２５】
ＭＡＣ層リセットインジケータと共にＲＲＣメッセージが受信され、ＵＥ内のＲＲＣによって処理される（ステップ１８）。ＵＥ ＲＲＣはＭＡＣ層リセットインジケータが設定されているかどうかをチェックし、設定されている場合、ＲＲＣはＭＡＣ層リセット要求をＭＡＣ層に通知する（ステップ２０）。ＭＡＣ層リセット要求を受信すると、ＭＡＣ層はリセットし、さらに他のタスクに加えて、再順序付けバッファに格納されたすべてのＰＤＵをＨＳ−ＤＳＣＨにマッピングされたＲＬＣエンティティにフラッシュする（ステップ２２）。その後、フラッシュされたすべてのＰＤＵがＨＳ−ＤＳＣＨにマッピングされたＲＬＣインスタンスによって処理され（ステップ２４）、続いてＰＤＵ状況報告が生成される（ステップ２６）。
【００２６】
正確で完全な伝送状況をＲＮＣに提供するためには、ＰＤＵ状況報告を生成する前に、再順序付けバッファ内でのＲＬＣのＰＤＵ処理を停止する必要がある。ＰＤＵ状況報告が早期に（すなわち、ＭＡＣ再順序付け待ち行列内にバッファリングされたすべてのＰＤＵがＲＬＣインスタンスによって処理される前に）生成された場合、一部のＰＤＵが受信されていないものとして不適切に示される可能性があり、結果として、ＲＮＣによって不必要なＰＤＵ再送が生成される可能性がある。
【００２７】
すべてのＰＤＵがＲＬＣによって処理されたことを保証するにはいくつかの方法があり、結果としてＡＭ ＲＬＣエンティティは、首尾良く受信されたすべてのＰＤＵの正しい状況を取得することができる。第１に、ＭＡＣ層は各再順序付け待ち行列からＰＤＵを順序どおりに転送し、その後、各再順序付け待ち行列に対して「ＰＤＵの終わり」インジケーションを生成する。
【００２８】
第２の代替例では、各再順序付け待ち行列からの最後のＰＤＵが特別なインジケータを有する。これらは、ＵＥで受信されたＲＬＣ ＰＤＵの状況の報告である。
【００２９】
第３の代替例では、ＲＬＣはＰＤＵがいつ処理されたかをＭＡＣ層に確認し、すべてのＰＤＵ処理が終わると、ＭＡＣ層はＲＬＣに対してＰＤＵ状況要求を生成する。ＰＤＵ状況メッセージを生成する前にすべてのＰＤＵがＲＬＣによって処理されることを保証するために、ＭＡＣ層とＲＬＣとの間の処理を調整するには、多数の方法があることを理解されたい。
【００３０】
ＰＤＵの受信および処理の後、ＡＭ ＲＬＣは、すべてのＰＤＵ受信の成功または不成功を示すＰＤＵ状況報告を生成する（ステップ２６）。ＰＤＵ状況報告は、ＨＳ−ＤＳＣＨにマッピングされたそれぞれのＡＭ ＲＬＣインスタンスについて生成される。たとえそのＡＭ ＲＬＣインスタンスについてＭＡＣ層から何のＰＤＵも転送されなかった場合であっても、ＰＤＵ状況報告を生成することができる。その後ＵＥは、ＨＳ−ＤＳＣＨに関連付けられた各ＡＭ ＲＬＣインスタンスに関するＰＤＵ状況報告を、自律的にＲＮＣに送信する。
【００３１】
ＲＮＣではＡＭ ＲＬＣおよびＭＡＣエンティティがＭＡＣ層リセットによるＰＤＵ伝送停止を通知されていないものと想定し、ＲＮＣはＭＡＣ層リセットに関係なくＰＤＵの伝送を続行する。ＨＳ−ＤＳＣＨに関連付けられたそれぞれのＡＭ ＲＬＣインスタンスについてＰＤＵ状況報告を受信すると、ＲＮＣ内のＲＬＣインスタンスは状況報告を処理し（ステップ２８）、失われたＰＤＵを決定して、送達の成功を保証するために必要な場合にはＰＤＵ再送を生成する（ステップ３０）。サービス品質要件を達成するために、この再送は現在の伝送処理よりも優先して行うことができる。
【００３２】
ＭＡＣ層リセットの必要性は、一般にＰＤＵ状況報告生成の必要性を伴うものであることを理解されたい。いずれかの要件のインジケーション、または何らかの共通のインジケーションをＵＥに発信して、ＭＡＣ層のリセットおよびＰＤＵ状況報告の生成の両方を呼び出すことができる。その後ＵＥは、説明した順序で各機能を実行することになる。
【００３３】
図２に示されたような本発明のこの第１の実施形態では、データ経路が１つの無線リンクから他の無線リンクへ切り替えられる間、ＲＮＣはＵＥへの伝送を維持することができる。しかしながら、図３および４に示された本発明の２つの代替実施形態によれば、ＨＳ−ＤＳＣＨセル変更、または、後続のイベントが発生するまでＭＡＣ層リセットにとって必要となる他のイベント時に、データ伝送は中止される。図２に示されたステップと同じ要素番号を有する図３および４に示されたステップは、同一であることに留意されたい。したがって、図３および４を参照する際にこれらのステップの説明は繰り返さないものとする。
【００３４】
本発明の第２の実施形態は、ＭＡＣ層リセット状態に続いて、最小遅延でＰＤＵの状況をＵＥに伝送することを決定するための方法４０を備え、図３に示されている。ＲＮＣがＭＡＣ層リセットの必要性を認識し（ステップ１２）、ノードＢおよびＵＥに通知した（ステップ１４および１６）後、ＲＮＣはすべてのダウンリンクＨＳ−ＤＳＣＨ伝送を中止する（ステップ１７）。ステップ１７は、不都合な結果を招くことなしに、ステップ１４または１６に先立って実行可能であることに留意されたい。その後ＲＮＣはＰＤＵ状況報告を受信する（ステップ３２）。ＰＤＵ状況報告は、ＭＡＣリセットの結果としてのＰＤＵの損失と、ＨＳ−ＤＳＣＨセル変更の場合にソースノードＢで追加のＰＤＵが失われる可能性とを示す。その後、ＰＤＵ状況報告が処理され（ステップ３４）、欠落したＰＤＵがＵＥに再送される（ステップ３６）。ＲＮＣは、最初に再送を必要とする失われたＰＤＵの伝送をスケジューリングすることによって、新しいセル内で伝送を開始する。その後ＲＮＣは、ステップ１７で以前に伝送が停止された時点からＰＤＵの伝送を再開する（ステップ３８）。ステップ３６および３８は同時に実行してもよいことに留意されたい。
【００３５】
図４を参照すると、本発明に従った第３の実施形態の方法５０が示されている。この方法５０は、図３に示された方法４０と同様である。しかしながら、図３に示されたようにステップ３２でＰＤＵ状況報告の受信に応答してＵＥへのダウンリンクＨＳ−ＤＳＣＨ伝送を再開する代わりに、本発明のこの実施形態の方法５０は、「トリガ」の受信または所定のイベント時に伝送を再開する（ステップ１９）。第１の例では、トリガは、当業者であれば理解されるように、新しい「ターゲット」ノードＢが手順を発信してＲＮＣによって達成されるＵＴＲＡＮ内での移送チャネルの確立を含むことができる。ノードＢによって生成された確認をＲＮＣで受信することが、トリガとして使用される。
【００３６】
第２の例では、トリガは「同期（ｉｎ−ｓｙｎｃ）」インジケーションの受信または検出を含むことができる。ターゲットノードＢ内に専用リソースを確立すると、割り当てられた物理チャネルがノードＢ内での伝送に使用可能であると決定された場合に、ノードＢで「同期」インジケーションを決定することができる。このイベントのインジケーションはＲＮＣに中継し、その後トリガとして使用することができる。
【００３７】
第３の例では、トリガはＲＲＣ手順の完了（すなわち、ＲＮＣのＵＥ ＲＲＣメッセージ受信の確認）を含むことができる。ステップ１６でＲＲＣメッセージが発信されると、結果として、ＵＥによって生成されＲＮＣに送信されるＲＲＣ確認メッセージを生じる。このメッセージがＲＮＣで受信された場合、トリガとして使用することができる。
【００３８】
ＵＥとＲＮＣとの間で送信される信号には多くの異なる信号があり、ユーザは本発明に従ったトリガとして動作するために望ましいものとしてこれらのいずれかを選択できることに留意されたい。したがって前述の３つの例は、制限的なものではなく啓発的なものである。トリガの形式に関わらず、ＲＮＣはトリガが受信された後にＨＳ−ＤＳＣＨ伝送を再開する（ステップ２１）。
【図面の簡単な説明】
【００３９】
【図１】従来技術のＨ−ＡＲＱプロセスを示すブロック図である。
【図２】ＨＳ−ＤＳＣＨセルの変更に続いてＵＥのバッファリングデータを効率的に回復するための、本発明に従った効率的な手順を示す流れ図である。
【図３】ターゲットセル内での新しいデータの伝送開始に先立って、ＲＮＣが状況ＰＤＵを待つ場合に使用する、第１の代替方法を示す流れ図である。
【図４】ターゲットセル内での新しいデータの伝送開始に先立って、ＲＮＣがトリガを待つ場合に使用する、第２の代替方法を示す流れ図である。
【出願人】 【識別番号】５９６００８６２２
【氏名又は名称】インターデイジタル テクノロジー コーポレーション
【出願日】 平成１９年１０月４日（２００７．１０．４）
【代理人】 【識別番号】１０００７７４８１
【弁理士】
【氏名又は名称】谷 義一

【識別番号】１０００８８９１５
【弁理士】
【氏名又は名称】阿部 和夫
【公開番号】 特開２００８−３５５５７（Ｐ２００８−３５５５７Ａ）
【公開日】 平成２０年２月１４日（２００８．２．１４）
【出願番号】 特願２００７−２６１２１４（Ｐ２００７−２６１２１４）