(57)【特許請求の範囲】
【請求項１】
少なくとも、所与のユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローおよびそのようなパケットデータユニットの前記ユーザエンティティへの転送（ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ）に関する媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ１０１、１０２、１０４、１０５）を無線ネットワークコントローラ（ＲＮＣ）から受信するように構成された第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）における方法であって、
前記所与のユーザエンティティへの送信は、少なくとも第２の無線基地局（Ｎｏｄｅ  Ｂ＿Ｔ）にハンドオーバするように構成される方法において、
−前記第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）が継続的に、前記ユーザエンティティの優先順位キューの媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ）に関する少なくともデータ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を更新するステップ（１２、３３、３３５、４１）であって、前記パケットデータユニットは、前記無線ネットワークコントローラ（ＲＮＣ  ＲＬＣ）内のプロトコル層（ＲＬＣ）から最後に送信され、それにより、前記パケットデータユニットのうちの少なくともいくつかが、前記ユーザエンティティ（ＵＥ＿Ｑ）内の対応するプロトコル層（ＲＬＣ）によりまだ受信されていない可能性がある、更新するステップ（１２、３３、３３５、４１）、
−前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）が、前記第１の基地局から送信するのに残っている、または前記ユーザエンティティによる肯定確認応答に残っている媒体アクセス制御層パケットデータユニットの数を示すステップ、
−前記第１の基地局が、前記データ構造を要求する予め定められた信号（ＵＮＡＣＫ＿ＭＡＣＤ＿ＲＥＱ（１０８））を前記無線ネットワークコントローラから受信すると、前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の現在の値を前記無線ネットワークコントローラ（ＲＮＣ）に送信するステップ（４１、１１０）
を含み、
前記第１および第２の無線基地局ならびに前記無線ネットワークコントローラは、媒体アクセス制御層パケットデータユニットが、少なくとも所与のユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローに関する、無線ネットワークコントローラ（ＲＮＣ）からのＭＡＣ−ｄパケットデータユニットおよび前記第１または前記第２の基地局から前記ユーザエンティティに送信されたＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓパケットデータユニットを含む規格に従って動作し、
前記方法は、
前記第１の基地局が、フローバッファ内に記憶されているＭＡＣ−ｄ  ＰＤＵの量および最古に送信された否定確認応答ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ  ＰＤＵ（ＢＯＷ）を含め、ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ  ＰＤＵ内でそれまでに送信されたすべてのＭＡＣ−ｄ  ＰＤＵとして前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を計算するステップをさらに含むことを特徴とする、方法。
【請求項２】
前記データ構造の更新は、自動再送要求（ＨＡＲＱ）プロセスの完了後に行われ、自動再送要求プロセスでは、フレームが前記第１の基地局から前記ユーザエンティティへの送信されるようにスケジュールされ、自動再送要求の完了後、優先順位キュー毎のＭＡＣ−ｄ  ＰＤＵ数および完了した自動再送要求（ＨＡＲＱ）プロセスの対応する送信シーケンス番号（ＴＳＮ）が、前記第１の基地局内のスケジューラに報告される（２４）、請求項１に記載の方法。
【請求項３】
前記報告に続き、送信シーケンス番号が窓底に達した後（３２）、前記報告された送信シーケンス番号のＭＡＣ−ｄパケットの数だけ、前記データ構造の値を低減すること（３３５）により、前記データ構造を更新する、請求項２に記載の方法。
【請求項４】
ＭＡＣ−ｄ  ＰＤＵが、ＭＡＣ−ｄの第１の部分が第１のＭＡＣ−ｅｈｓ内で送信され、前記ＭＡＣ−ｄの第２の部分が続くＭＡＣ−ｅｈｓ内で送信されるように分割される場合、後者のみがＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴに寄与し、前記分割されたＭＡＣ−ｄ  ＰＤＵからの他のすべてのＭＡＣ−ｅｈｓは、ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴに寄与しない、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
ＭＡＣ−ｅｈｓ  ＰＤＵが、２つ以上の優先順位キューからのＭＡＣ−ｄを含む場合、前記ＨＡＲＱプロセス（２２）は、ＭＡＣ−ｄ  ＰＤＵの数および前記ＭＡＣ−ｅｈｓ内に存在する各優先順位キューの対応する優先順位キューＩＤを前記送信シーケンス番号と一緒に記憶する、請求項１〜３のいずれか一項に記載の方法。
【請求項６】
前記第１および第２の基地局は、高速パケットデータアクセス規格に従って動作する、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
少なくとも、ユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローに関するパケットデータユニット（ＰＤＵ１０１、１０２、１０４、１０５、図２）を受信して、そのようなパケットデータユニットを第１の基地局にさらに転送するように構成された無線ネットワークコントローラ（ＲＮＣ）の方法であって、
前記送信は、少なくとも第２の無線基地局（Ｎｏｄｅ  Ｂ＿Ｔ）にハンドオーバされるように構成される方法において、
−ユーザエンティティの優先順位キューに関する第１のシーケンス番号ビットマップ（ＳＮＢ＿Ｓ）を保持するステップ、およびユーザエンティティへのさらなる送信のために第１の基地局に最後に送信されたシーケンス番号のリストを含むステップ
をさらに含み、
変更第２のシーケンス番号ビットマップ（ＳＮＢ＿Ｔ）が、前記第１のシーケンス番号ビットマップ（ＳＮＢ＿Ｓ）から導出され、
データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を含む信号（ＵＮＡＣＫ＿ＭＡＣＤ＿ＩＮＤ１１０）の受信時に、前記無線ネットワークコントローラ（ＲＮＣ）は前記第２のシーケンス番号ビットマップ（ＳＮＢ＿Ｔ）を変更し、
前記変更第２のシーケンス番号ビットマップ（ＳＮＢ＿Ｔ）は、前記第２のシーケンス番号ビットマップの有効長、すなわち、最後に送信されたシーケンス番号の量が、前記第１の無線基地局により示される前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の値に制限される手順により、前記無線ネットワークコントローラ（ＲＮＣ）において達成され、
前記第２のシーケンス番号ビットマップは、前記第２の基地局へのハンドオーバ時に再送信を実行するためのベースとして使用され、
前記変更第２のシーケンス番号ビットマップ（ＳＮＢ＿Ｔ）は、前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の値により示される量に対応する数の上位エントリをコピーすることにより作成され、前記変更第２のシーケンス番号ビットマップの残りのエントリはヌル値で構成されることを特徴とする、方法。
【請求項８】
前記第１または第２のシーケンス番号ビットマップのそれぞれは、送信されたおよび再送信されたシーケンス番号を含み、前記送信されたおよび再送信されたシーケンス番号は、前記パケットデータユニットが送信された順番に前記第１または第２のシーケンス番号ビットマップのそれぞれ内に列挙される、請求項７に記載の方法。
【請求項９】
前記第１および第２の基地局ならびに前記無線ネットワークコントローラは、前記高速パケットデータアクセス規格に従って動作する、請求項７又は８に記載の方法。
【請求項１０】
少なくとも、所与のユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローおよびそのようなパケットデータユニットの前記ユーザエンティティへの転送（ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ）に関する媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ１０１、１０２、１０４、１０５）を無線ネットワークコントローラ（ＲＮＣ）から受信するように構成された第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）であって、
前記所与のユーザエンティティへの送信は、少なくとも第２の無線基地局（Ｎｏｄｅ  Ｂ＿Ｔ）にハンドオーバするように構成される第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）において、
−前記第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）が継続的に、前記ユーザエンティティの優先順位キューの媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ）に関する少なくともデータ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を更新する（１２、３３、３３５、４１）ように構成され、前記パケットデータユニットは、前記無線ネットワークコントローラ（ＲＮＣ  ＲＬＣ）内のプロトコル層（ＲＬＣ）から最後に送信され、それにより、前記パケットデータユニットのうちの少なくともいくつかが、前記ユーザエンティティ（ＵＥ＿Ｑ）内の対応するプロトコル層（ＲＬＣ）によりまだ受信されていない可能性があり、
−前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）が、前記第１の基地局から送信するのに残っている、または前記ユーザエンティティによる肯定確認応答に残っている媒体アクセス制御層パケットデータユニットの数を示し、
−前記第１の基地局が、前記データ構造を要求する予め定められた信号（ＵＮＡＣＫ＿ＭＡＣＤ＿ＲＥＱ（１０８））を前記無線ネットワークコントローラから受信すると、前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の現在の値を前記無線ネットワークコントローラ（ＲＮＣ）に送信するように構成され、
前記第１および第２の無線基地局ならびに前記無線ネットワークコントローラは、媒体アクセス制御層パケットデータユニットが、少なくとも所与のユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローに関する、無線ネットワークコントローラ（ＲＮＣ）からのＭＡＣ−ｄパケットデータユニットおよび前記第１または前記第２の基地局から前記ユーザエンティティに送信されたＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓパケットデータユニットを含む規格に従って動作するように構成され、
前記第１の基地局が、フローバッファ内に記憶されているＭＡＣ−ｄ  ＰＤＵの量および最古に送信された否定確認応答ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ  ＰＤＵ（ＢＯＷ）を含め、ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ  ＰＤＵ内でそれまでに送信されたすべてのＭＡＣ−ｄ  ＰＤＵとして前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を計算するように構成されることを特徴とする、第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）。
【請求項１１】
少なくとも、ユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローに関するパケットデータユニット（ＰＤＵ１０１、１０２、１０４、１０５、図２）を受信して、そのようなパケットデータユニットを第１の基地局にさらに転送するように構成された無線ネットワークコントローラ（ＲＮＣ）であって、
前記送信は、少なくとも第２の無線基地局（Ｎｏｄｅ  Ｂ＿Ｔ）にハンドオーバされるように構成される無線ネットワークコントローラ（ＲＮＣ）において、
−ユーザエンティティの優先順位キューに関する第１のシーケンス番号ビットマップ（ＳＮＢ）を保持し、およびユーザエンティティへのさらなる送信のために基地局に最後に送信されたシーケンス番号のリストを含むようにさらに構成され、
変更第２のシーケンス番号ビットマップ（ＳＮＢ＿Ｔ）が、前記第１のシーケンス番号ビットマップ（ＳＮＢ＿Ｓ）から導出され、
データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を含む信号（ＵＮＡＣＫ＿ＭＡＣＤ＿ＩＮＤ１１０）の受信時に、前記無線ネットワークコントローラ（ＲＮＣ）は前記第２のシーケンス番号ビットマップ（ＳＮＢ＿Ｔ）を変更するように構成され、
前記変更第２のシーケンス番号ビットマップ（ＳＮＢ＿Ｔ）は、前記第２のシーケンス番号ビットマップの有効長、すなわち、最後に送信されたシーケンス番号の量が、前記第１の無線基地局により示される前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の値に制限される手順により、前記無線ネットワークコントローラ（ＲＮＣ）において達成され、
前記第２のシーケンス番号ビットマップは、前記第２の基地局へのハンドオーバ時に再送信を実行するためのベースとして使用され、
前記変更第２のシーケンス番号ビットマップ（ＳＮＢ＿Ｔ）は、前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の値により示される量に対応する数の上位エントリをコピーすることにより作成され、前記変更第２のシーケンス番号ビットマップの残りのエントリはヌル値で構成される、無線ネットワークコントローラ（ＲＮＣ）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、様々な基地局からのハンドオーバ中のパケットデータ伝送に関する。特に、本発明は、高速パケットデータプロトコルＨＳＤＰＡに従ったパケットデータに関する。
【背景技術】
【０００２】
３ＧＰＰでのＲＬＣ層は、以下において焦点を当てる３つのモード：トランスペアレントモード、否定確認応答モード、および肯定確認応答モード（ＡＭ）で動作することができる。
【０００３】
ＡＭモードでは、受信側により発見された不正確に受信したＰＤＵ（プロトコルデータユニット）は、ＡＲＱ（自動再送要求）プロトコルにより送信側により再送される。
【０００４】
ＡＭ  ＲＬＣエンティティは送信側および受信側からなり、ＡＭ  ＲＬＣエンティティの送信側はＲＬＣ  ＰＤＵを送信し、ＡＭ  ＲＬＣエンティティの受信側はＲＬＣ  ＰＤＵを受信する。
【０００５】
ＡＭ  ＲＬＣエンティティは、ＵＥ（ユーザ機器）およびＲＮＣ（無線ネットワーク制御装置）のそれぞれに存在する。送信側は、ＲＬＣ  ＳＤＵ（サービスデータユニット）の、固定長のＰＤＵへのセグメント化および／または連結を行う。受信側は、受信したＰＤＵをＲＬＣ  ＳＤＵに再び組み立てて、より上位のデータ層に送信する。同様に、ＳＤＵをＲＬＣ層の上の層からも受信する。ＡＭモードでは、ＲＬＣ層は、ＳＤＵの順序通りの送信を担当する。
【０００６】
文献国際公開第２００５／０３４４１８号の図４には、肯定確認応答モード（ＡＭ）のＵＥ（基地局）／ＵＴＲＡＮ（無線アクセスノード／基地局（ノードＢ））エンティティの実施が示される。
【０００７】
順序通りの送信を容易にするために、各ＲＬＣ  ＰＤＵにはシーケンス番号０〜４０９５が付与され、それにより、送信器は、増大するシーケンス番号モジュロ４０９６を有するＰＤＵを送信する。シーケンス番号を使用して、受信器は欠落しているＰＤＵを検出することができる。受信器は、ＰＤＵの欠落が検出された場合、ステータス（STATUS）メッセージを送信するように構成することができる。ステータスリポートは、ピアＲＬＣエンティティが受信した個々のＲＬＣ  ＰＤＵの肯定または否定の確認応答を含み得る。送信器は、ＰＤＵヘッダ内のポーリングフラグを設定することにより、受信器からのステータスメッセージを要求することもできる。送信器がポーリングフラグを設定する条件は、特に、以下である。
−バッファ内の最後のＰＤＵ：入力バッファ内に存在するＰＤＵが１つのみの場合、ポーリングフラグが設定される。
−ポーリングタイマが切れる：パラメータｔｉｍｅｒ＿ｐｏｌｌが切れた場合、すなわち、応答の受信を再確認するために、送信器が先にステータスを要求し、ｔｉｍｅｒ＿ｐｏｌｌを開始した場合。
−ウィンドウに基づく：送信器は、ステータスにより受信側への受信を確認するまでに送信できる「未解決データ」の量が制限され、「未解決データ」は最古の否定確認応答ＰＤＵに関する。
【０００８】
ＲＬＣ層の機能の上記説明が、実際に提供される機能以外のごくわずかな部分を占めることに留意する。
【０００９】
選択的な再送信が可能であり、例えば、ステータスメッセージにより、シーケンス番号（ＳＮ）３、６、および１３を有するＰＤＵが欠落していることが示される場合、再送信する必要があるのは３、６、および１３のみである。
【００１０】
ＭＡＣ−ｈｓ  ＰＤＵが欠落するという誤った状況から回復するために、３ＧＰＰ  ＴＳ２５．３２１−１１．６．２（再順序付けリリースタイマおよびウィンドウに基づくストール回避）において説明される様々なストール回避メカニズムが使用される。
【００１１】
ハンドオーバ
ＨＳＤＰＡには、データをＵＥに送信する際、１つのみのノードＢが存在する。ノードＢは、ＲＮＣから受信したＭＡＣ−ｄ  ＰＤＵをバッファリングし、内部スケジューラが、ＭＡＣ−ｈｓ  ＰＤＵ内のこれらＭＡＣ−ｄ  ＰＤＵをＵＥにいつ送信するかを決定する。ＵＥは、ＭＡＣ−ｈｓ受信器においてデータを受信し、データを対応する上位層アプリケーションに送る。
【００１２】
ノードＢと別のノードＢとのハンドオーバ時、ＲＮＣ  ＲＬＣ層から送信されたが、ＵＥ  ＲＬＣ層においてまだ受信されていないＭＡＣ−ｄ  ＰＤＵが存在し得る。これは、以下の状況のうちの１つまたは複数によるものであり得る：
−ＲＮＣ  ＲＬＣ層から送信されたＭＡＣ−ｄ  ＰＤＵが、ノードＢ内に保留（またはバッファリング）中であり、ノードＢからまだ続けて送信されていない、
−ＲＮＣ  ＲＬＣ層から送信されたＭＡＣ−ｄ  ＰＤＵが、ノードＢから送信された可能性があるが（ＭＡＣ−ｈｓパケットデータユニットとして）、ＵＥにおいてまだ適宜受信されていない、または
−ＲＮＣ  ＲＬＣ層から送信されたＭＡＣ−ｄ  ＰＤＵが、ＵＥにおいて適宜受信された可能性があるが（ＭＡＣ−ｈｓパケットデータユニットとして）、ＭＡＣ−ｈｓプロトコル再順序付けメカニズムにより、これらＰＤＵがＵＥ  ＲＬＣ層にまだ送られていない。
【００１３】
以下において、ＭＡＣ−ｄ  ＰＤＵがノードＢにおいて破棄されたものとして上記３つの状況を手短に参照する。
【００１４】
ハンドオーバが行われた場合、上述したＭＡＣ−ｄ  ＰＤＵは削除され（または失われ）、ＲＮＣのＲＬＣ層は、例えば、ＴＣＰデータの損失を回避するために、データを再送信する必要がある。
【００１５】
先行技術による文献である米国特許出願公開２００４／０１６５５５４号「System for efficient recovery of Node B buffered data following serving high speed downlink shared channel cell change」には、セル変更を受けているＵＥがどのようにして、ＰＤＵステータスメッセージをＲＮＣに自動的に送信し、それにより、ＲＮＣがより高速に、ＵＥにおいて受信されていないＭＡＣ−ｄ  ＰＤＵを再送信できるかが記載されている。
【００１６】
新しい媒体アクセス制御エンティティであるＭＡＣ−ｅｈｓが、３ＧＰＰリリース７に紹介されている。ＭＡＣ−ｅｈｓはＭＡＣ−ｈｓの代替として使用することができる。ＭＡＣ−ｅｈｓは、柔軟性のあるＲＬＣ  ＭＡＣ−ｄ  ＰＤＵサイズならびにＭＡＣセグメント化／再組み立てをサポートする。さらに、ＨＳＤＰＡのＭＡＣ−ｈｓと異なり、ＭＡＣ−ｅｈｓでは、１つの送信時間間隔である２ｍｓ内でいくつかの優先順位キューからのデータを多重化することが可能である。
【００１７】
本発明では、特記されない限り、ＭＡＣ−ｈｓを参照して説明される。しかし、ＭＡＣ−ｅｈｓも同様に使用し得ることを理解されよう。
【００１８】
ＨＳＤＰＡについてのさらなる情報については、
http://www.ericsson.com/solutions/terms/articles/Q4_2005_High_ Speed_Downlink_Pack_et_Access_part1.pdf
を参照のこと。
【００１９】
ＭＡＣ−ｅｈｓについての情報については、
http://www.ericsson.com/ericsson/corpinfo/publications/review/2008_01/files/5_HSPA_Evolution.pdf
を参照のこと。
【００２０】
ＥＵＬについての情報については、
http://www.ericsson.com/technology/research_papers/wireless_access/doc/wcdma_enhanced_uplink_principles_and_basic.pdf
を参照のこと。
【００２１】
すべての文献は、２００８年１２月３０日現在、Ericsson公式ウェブサイトwww.ericsson.comに公開されている。
【００２２】
以下の図に、セル変更時のＲＮＣとノードＢとのシグナリングを示す。
【００２３】
既存の解決策に伴う問題
先行技術による文献米国特許出願公開２００４／０１６５５５４号（段落［００１１］参照）には、まず、ＨＳ−ＤＳＣＨセル変更に続く既知の先行技術によるメカニズムが説明されている。
１）ＲＮＣは、ステータスＰＤＵをＵＥから明示的に要求することができ、
または
２）ＲＮＣはただ、ソースセル内で停止した場所から送信を開始し、ＵＥにより実現される順不同シーケンスが、ステータスＰＤＵを生成する。
【００２４】
米国特許出願公開２００４／０１６５５５４号に記載のように、復元は相当に遅延する恐れがあり、遅延および遅延ジッタがエンドユーザＴＣＰ性能に対して悪影響を有することが言及されている。先行技術による米国特許出願公開２００４／０１６５５５４号は続けて、遅延および遅延ジッタに起因して復元により生じるエンドユーザのスループットに対する悪影響を軽減するメカニズムをさらに提案し、そのメカニズムでは、ＵＥは、セル変更時、ステータスＰＤＵをサービングＲＮＣに自律的に送信する。ステータスＰＤＵを受信すると、ＲＮＣは、上記１）および２）よりも高速に失われたデータを発見し、再送信を実行する。
【００２５】
これより、自律的ステータスＰＤＵの送信時間に焦点を当て、これと、ＵＥが欠落ＰＤＵを受信するまでにかかる合計時間とを比較する。まず、ステータスＰＤＵをＲＮＣに送信するまでにかかる遅延を推定する。ユーザが、下りリンク伝送にＨＳ−ＤＳＣＨを使用し、上りリンクにＥ−ＤＣＨを使用するものと想定する。
【００２６】
事例１−ＵＥにＥＵＬ認可が存在する（最良の事例）
（ＴＴＩ＝１０ｍｓを使用するＥ−ＤＣＨ構成を想定する）
まず、ＵＥにおいてＲＬＣ層から生成されたステータスＰＤＵがＵＥ  ＥＵＬ層において受信されてから、Ｅ−ＤＰＤＣＨ  ＴＴＩにおいて送信されるまでの待ち時間が５ｍｓ、すなわち、ＴＴＩ間隔の半分であると想定する。
送信時間は、ＴＴＩ期間１０ｍｓに等しい。
伝搬遅延は、その他の時間遅延成分と比較して低いと考えられる。
ラボインタフェースにおいて送信されるまでのノードＢでの復号化時間は５〜１０ｍｓである。
ラボで送信されるまでの合計遅延は２０〜２５ｍｓと推定される。
【００２７】
事例２−ＵＥにＥＵＬ認可が存在しない（最悪の事例）
ＵＥ内のＥＵＬエンティティが、ＵＥのＲＬＣ層から生成されたステータスＰＤＵを受信する場合、ＵＥは、例えば、Ｅ−ＤＰＣＣＨについての不満を送信して、ノードＢにＡＧＣＨを介してのＵＥについての送信を強制的に認可させるために、送信が必要なことをノードＢまで通知する必要がある。
【００２８】
図３は問題を示す。
１）データ（すなわち、ステータスＰＤＵ）をＲＬＣ層から受信する。
２）スケジューリング情報が、ＭＡＣ−ｅヘッダの部分として送信される。
３）ノードＢ内のスケジューラが、スケジューリング情報を受信する。
４）認可がＵＥに送信され、送信可能なことを通知する。
大まかな推定では、ＴＴＩ＝１０ｍｓを使用する構成の場合、ステップ１）〜４）に３０〜１００ｍｓかかる。
【００２９】
ここで、事例１および事例２の遅延を残りの遅延成分：
ａ）ラボのＲＮＣ  ＲＬＣ層までのステータスＰＤＵの送信、
ｂ）ＲＮＣ  ＲＬＣ層がＭＡＣ−ｄ  ＰＤＵを再送信する反応時間、
ｃ）再送信されたＰＤＵをラボのノードＢに送信する時間、
ｄ）第１の送信がＭＡＣ−ｈｓで行われるまでのノードＢ内の待ち時間、
ｅ）ＵＥのＭＡＣ−ｈｓでのデータ受信およびＵＥ  ＭＡＣ−ｈｓ層からＲＬＣ層へのデータ送信
と比較した場合、
ａ）およびｃ）−１ｍｓ未満または１ｍｓよりもはるかに小さい範囲で小さいと想定され、
ｂ）−ＲＮＣ内の負荷に依存するが、推定はおおよそ１ｍｓであり、
ｄ）−３〜５ｍｓの範囲内であると想定され、
ｅ）−再送信されたすべてのＭＡＣ−ｄ  ＰＤＵが１つのＭＡＣ−ｈｓ  ＰＤＵ内に入り、最初の送信に成功したと想定した場合、追加の遅延は０．５〜３ｍｓの範囲内にあると想定され、再送信が必要な場合、遅延は１２．５〜１５ｍｓの範囲内にあり、２回目の再送信が必要な場合、２４．５〜２７ｍｓである。
【００３０】
残りの遅延は全体的に、
ノードＢでの再送信なし：６〜１０ｍｓ、
ノードＢでの再送信が１回：１８〜２２ｍｓ、
ノードＢでの再送信が２回：３０〜３４ｍｓ
であると想定される。
【００３１】
全体的に、上記の初期遅延推定−２０〜２５ｍｓ（事例１）または３０〜１００ｍｓ（事例２）のいずれか−が、上記の残りの遅延よりもかなり長くなり得る、または残りの遅延に少なくとも匹敵すると結論付けることができる。
【発明の概要】
【発明が解決しようとする課題】
【００３２】
本発明の第１の目的は、ユーザエンティティが、基地局間のハンドオーバを介するデータ受信に関わる場合に生じる破棄パケットデータユニットに関連する悪影響を軽減することである。
【課題を解決するための手段】
【００３３】
本発明の第１の態様によれば、少なくとも、所与のユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローおよびそのようなパケットデータユニットの上記ユーザエンティティへの転送（ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ）に関する媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ１０１、１０２、１０４、１０５）を無線ネットワークコントローラ（ＲＮＣ）から受信するように構成された第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）での方法が提供される。
【００３４】
所与のユーザエンティティへの送信は、少なくとも第２の無線基地局（Ｎｏｄｅ  Ｂ＿Ｔ）に潜在的にハンドオーバされるように構成され、この方法は、
−第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）が継続的に、ユーザエンティティの優先順位キューの媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ）に関する少なくともデータ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を更新するステップ（１２、３３、３３５、４１）であって、パケットデータユニットは、無線ネットワークコントローラ（ＲＮＣ  ＲＬＣ）内のプロトコル層（ＲＬＣ）から最近送信され、それにより、上記パケットデータユニットのうちの少なくともいくつかが、ユーザエンティティ（ＵＥ＿Ｑ）内の対応するプロトコル層（ＲＬＣ）によりまだ受信されていない可能性がある、更新するステップ（１２、３３、３３５、４１）、
−第１の基地局が、データ構造を要求する予め定められた信号（ＵＮＡＣＫ＿ＭＡＣＤ＿ＲＥＱ（１０８））を無線ネットワークコントローラから受信すると、上記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の現在の値を無線ネットワークコントローラ（ＲＮＣ）に送信するステップ（４１、１１０）
を特徴とする。
【００３５】
本発明の第２の態様によれば、少なくとも、所与のユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローおよびそのようなパケットデータユニットの上記ユーザエンティティへの転送（ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ）に関する媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ１０１、１０２、１０４、１０５）を無線ネットワークコントローラ（ＲＮＣ）から受信するように構成された第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）が提供される。
【００３６】
所与のユーザエンティティへの送信は、少なくとも第２の無線基地局（Ｎｏｄｅ  Ｂ＿Ｔ）に潜在的にハンドオーバされるように構成され、この方法は、
−第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）が継続的に、ユーザエンティティの優先順位キューの媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ）に関する少なくともデータ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を更新するステップ（１２、３３、３３５、４１）であって、パケットデータユニットは、無線ネットワークコントローラ（ＲＮＣ  ＲＬＣ）内のプロトコル層（ＲＬＣ）から最近送信され、それにより、上記パケットデータユニットのうちの少なくともいくつかが、ユーザエンティティ（ＵＥ＿Ｑ）内の対応するプロトコル層（ＲＬＣ）によりまだ受信されていない可能性がある、更新するステップ（１２、３３、３３５、４１）、
−第１の基地局が、データ構造を要求する予め定められた信号（ＵＮＡＣＫ＿ＭＡＣＤ＿ＲＥＱ（１０８））を無線ネットワークコントローラから受信すると、上記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の現在の値を無線ネットワークコントローラ（ＲＮＣ）に送信するステップ（４１、１１０）
を特徴とする。
【００３７】
この新しいシグナリングをセル変更状況において使用することにより、ＲＮＣは、ノードＢが送信に失敗したのがどのＭＡＣ−ｄ  ＰＤＵであるかを推定することができ、ユーザエンティティのハンドオーバ先である新しいノードＢにこのデータを即座に再送信開始することができる。それにより、セル変更中のダウンロード速度を改良することができる。
【００３８】
本発明のさらなる利点が、以下の本発明の詳細な説明から明らかになろう。
【図面の簡単な説明】
【００３９】
【図１】先行技術によるＨＳＤＰＡネットワークとハンドオーバシグナリングの基本要素を示す。
【図２】既知のＨＳ＿ＤＳＣＨデータフレームフォーマットを示す。
【図３】本発明の好ましい実施形態のハンドシェイク図を示す。
【図４】本発明の好ましい実施形態により無線ネットワークコントローラに保持されるシーケンス番号ビットマップを示す。
【図５】本発明によるノードＢの第１の実施形態に関するフロー図を示す。
【図６】本発明によるノードＢの第１の実施形態に関するフロー図を示す。
【図７】本発明によるノードＢの第１の実施形態に関するフロー図を示す。
【図８】本発明によるノードＢの第１の実施形態に関するフロー図を示す。
【図９】本発明によるノードＢの第１の実施形態に関するフロー図を示す。
【図１０】本発明によるノードＢの第２の実施形態に関するフロー図を開示する。
【図１１】本発明によるノードＢの第２の実施形態に関するフロー図を開示する。
【図１２】本発明による無線ネットワークコントローラに関するフロー図を示す。
【図１３】本発明による無線ネットワークコントローラに関するフロー図を示す。
【図１４】本発明による無線ネットワークコントローラに関するフロー図を示す。
【図１５】本発明を実施し得るＲＮＣを示す。
【図１６】本発明を実施し得るノードＢを示す。
【発明を実施するための形態】
【００４０】
本発明の第１の態様によれば、効率的なビットレートがハンドオーバによる悪影響を実質的に受けないように、ハンドオーバに向けて第２の基地局を準備するために、特別な方法ステップが、ノードＢとしても示される第１の基地局および無線ネットワークコントローラにおいて行われる。以下において、この状況での第１の基地局はソース基地局と呼ばれ、第２の基地局はターゲット基地局と呼ばれる。
【００４１】
基地局であるノードＢに関して、ＭＡＣ−ｄフロー毎に記憶される、否定確認応答ＭＡＣ−ｄ  ＰＤＵの量が計算される。ＲＮＣからの要求があった場合、または自律的に、または他の何からの処理の結果として、ノードＢは、計算された否定確認応答ＭＡＣ−ｄ  ＰＤＵの量を新しいまたは既存の信号でサービングＲＮＣまで送信する。サービング無線ネットワークコントローラＲＮＣに関して、本発明により、複数の最近送信されたＭＡＣ−ｄ  ＰＤＵシーケンス番号を表す更新可能なシーケンス番号ビットマップＳＮＢを作成し保持するステップが行われる。この文脈において、最近送信されたＭＡＣ−ｄ  ＰＤＵは、最初に送信されたＭＡＣ−ｄ  ＰＤＵならびに再送信されたＭＡＣ−ｄ  ＰＤＵの両方を指し得る。ＲＮＣは継続的にシーケンス番号ビットマップを更新する。
【００４２】
本発明の一実施形態によれば、予め定められた信号を受信すると、ＲＮＣは、シーケンス番号ビットマップＳＮＢを調べて、ソースノードＢにおいて破棄されたシーケンス番号がいずれであるかを特定する。ＲＮＣは次に、ＵＥのハンドオーバ先であるターゲットノードＢに対応するＭＡＣ−ｄ  ＰＤＵを再送信する。
【００４３】
シーケンス番号ビットマップを使用する場合、ＲＮＣはシーケンス番号ビットマップを使用して、各破棄ＭＡＣ−ｄ  ＰＤＵを対応するＳＮと一意に照合することが可能であるため、ノードＢは保持する必要があるのは、現在量の破棄ＭＡＣ−ｄ  ＰＤＵについての情報のみである。
【００４４】
それにより、復元時間が、先行技術による挙動による復元時間よりも改良される。
【００４５】
図１に、ハンドオーバが第１の基地局（ソース）から第２の基地局（ターゲット）に実行される、無線ネットワークコントローラ、ノードＢ、およびユーザエンティティ（ＵＥ）の間でのシグナリングを示す例示的なハンドシェイク図を提供する。この図について以下により詳細に対処するが、まず、本発明の好ましい実施形態による基地局および無線ネットワークコントローラの挙動について説明する。
【００４６】
ノードＢの挙動
ノードＢは、ＭＡＣ−ｄフロー毎に一意のＭＡＣ−ｄバッファ内に入力データを記憶する。ＭＡＣ−ｄ  ＰＤＵの内容は、ＲＮＣおよびＵＥ内に存在する層間で搬送される情報を表すため、ＭＡＣ−ｄ  ＰＤＵの復号化は行われず、それに代えて、ノードＢはスケジューラ内に記憶されたＭＡＣ−ｄ  ＰＤＵの量およびサイズを利用する。各バッファからのＭＡＣ−ｄ  ＰＤＵは、昇順で、すなわち、先入れ先出しで送信される。既知のように、ノードＢはＵＥとの通信に最高で８つのプロセスを利用する。
【００４７】
各ＨＡＲＱプロセスは、ＭＡＣ−ｈｓ  ＰＤＵを一意のＭＡＣ−ｈｓ  ＴＳＮと共に送信する。送信シーケンス番号ＴＳＮは６ビット値［０．．．６３］で表される。ＴＳＮは、上述した順序通りのＭＡＣ−ｄ送信が維持されることを保証するため、例えば、ＲＮＣのＲＬＣ層から最初の受信したＭＡＣ−ｄ  ＰＤＵがＵＥのＲＬＣ層に最初に届けられるＭＡＣ−ｄ  ＰＤＵであることを保証するために使用される。
【００４８】
３ＧＰＰでは、ノードＢ送信器の厳密な挙動について指定されていないが、ノードＢは、ＵＥ受信器の３ＧＰＰ仕様の必須（mandatory）部分に対応して動作しなければならない。
【００４９】
本発明によるノードＢは、先行技術による標準のノードＢのように、最初に送信された否定確認応答ＭＡＣ−ｈｓ  ＰＤＵ、例えば、「最も低い」ＴＳＮ（ＴＳＮがモジュロ６４としてカウントされることを考慮する）についての情報を有する。本発明の本実施形態では、「最も低い」ＴＳＮを窓底（ＢＯＷ：bottom of window）とも呼ぶ。
【００５０】
本発明の一態様によれば、本発明によるノードＢは、ＭＡＣ−ｄフローバッファに記憶されているＭＡＣ−ｄ  ＰＤＵの量および問題となっているノードＢ内で最初に送信された否定確認応答ＭＡＣ−ｄ  ＰＤＵを含め、それまでにＭＡＣ−ｈｓ  ＰＤＵ内で送信されたすべてのＭＡＣ−ｄ  ＰＤＵを考慮して、データ構造ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴを計算する。本発明によるノードＢは、所与のユーザエンティティの所与のフローについての下りリンクデータの送信元であるＲＮＣにこのデータ構造を通信するように構成される。フィードバック（ＨＳ−ＤＰＣＣＨ）がＵＥでの受信成功（ＡＣＫ）を開示する場合、または特定のＨＡＲＱプロセスでＭＡＣ−ｈｓ  ＰＤＵ最大再送信数に達したため、過度の時間遅延のため、もしくはこれら両方のためにＢＯＷが転送される例外処理で、ＢＯＷが継続的に更新されることが理解されよう。
【００５１】
ＭＡＣ−ｄの第１の部分が第１のＭＡＣ−ｅｈｓ内で送信され、ＭＡＣ−ｄの第２の（最後の）部分が続くＭＡＣ−ｅｈｓ内で送信されるように、ＭＡＣ−ｄ  ＰＤＵを分割できるＭＡＣ−ｅｈｓの場合、後者のみが、好ましくは、本発明によるＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴに寄与し、例えば、分割されたＭＡＣ−ｄ  ＰＤＵからの他のすべてのＭＡＣ−ｅｈｓは、０をＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴに追加する。
【００５２】
ＭＡＣ−ｅｈｓ  ＰＤＵが２つ以上の優先順位キューからのＭＡＣ−ｄを含む場合、ＨＡＲＱプロセスは、この場合（ステップ２２）、ＭＡＣ−ｄ  ＰＤＵの数およびＭＡＣ−ｅｈｓ内に存在する各優先順位キューの対応する優先順位キューＩＤを送信シーケンス番号と一緒に記憶する。
【００５３】
さらに、ＨＡＲＱプロセスが完了した場合（ステップ２４）、ＭＡＣ−ｄ  ＰＤＵの量および各優先順位キューの対応する優先順位キューＩＤは、送信シーケンス番号と一緒に再びスケジューラに報告される。
【００５４】
さらに、ステップ３３、３３５、および３３４において、各それぞれ含まれる優先順位キューおよびＭＡＣ−ｄの対応する番号が提供される。
【００５５】
ＲＮＣの挙動
本発明によれば、ＲＮＣは、ハンドオーバをより高速にするなどのために、基地局を割り当てる。
【００５６】
このために、無線ネットワークコントローラＲＮＣは、所与の「ソース」基地局ＮＯＤＥ＿Ｂ＿Ｓに対して、シーケンス番号ビットマップ（ＳＮＢ）として示される上述した少なくとも１つのデータ構造を保持し、このデータ構造は、好ましくは、特定のＵＥの特定の優先順キューを宛先として特定の基地局（ＮＯＤＥ＿Ｂ＿Ｓ）に最近送信されたＭＡＣ−ｄ  ＰＤＵのシーケンス番号ＳＮに対応するビットマップとして構成される。
【００５７】
ＲＮＣは、ＵＥの優先順位キューの数、ＵＥの数、および基地局の数に応じて複数のＳＮＢを保持し得る。
【００５８】
シーケンスビットマップの長さは構成可能である。
【００５９】
ターゲット基地局ＮＯＤＥ＿Ｂ＿Ｔにハンドオーバされる特定のＵＥの特定の優先順位キューへの再送信は、ビットマップのインジケーションに従って実行される。
【００６０】
ソース基地局に関するシーケンス番号ビットマップは、ハンドオーバ時に再送信を実行するためのベースとして使用されるか、またはＳＮＢ＿Ｔと示される変更されたシーケンス番号ビットマップが使用される。
【００６１】
後者の場合、図４に示されるように、変更シーケンス番号ビットマップが、ソース基地局シーケンス番号ビットマップＳＮＢ＿Ｓから導出される。
【００６２】
シーケンス番号ビットマップは所与の「最大長」Ｌを有し得るため、それにより、再送信量を適した値に制限し得る。
【００６３】
ノードＢ−ＲＮＣ対話
以下において、本発明の第１の実施形態について図３および図４を参照して説明する。
【００６４】
本発明の第１の実施形態によれば、ＳＮＢ＿Ｔとして示される変更ビットマップが使用される。
【００６５】
変更ビットマップは、ビットマップの有効長、すなわち、最後に送信されたシーケンス番号の量が、最大長Ｌ未満でなければならないＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴとして示されるソース無線基地局により示されるデータ構造の値に制限される手順により、ソース基地局に関連付けられたビットマップから変更される。
【００６６】
変更ビットマップは、ＵＥのハンドオーバ先であるターゲット基地局に対してＲＮＣにおいて確立される。ターゲット基地局のビットマップＳＮＢ＿Ｔは、ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ値により示される量に対応する数の上位ＲＬＣエントリをコピーすることにより作成される。変更ビットマップの残りのエントリは、ヌル値で構成される。
【００６７】
ＵＥのセル変更時、ＲＮＣは、ソースノードＢへのＭＡＣ−ｄデータの送信を停止し、ＵＮＡＣＫ＿ＭＡＣＤ＿ＲＥＱ１０８をソースノードＢであるＮｏｄｅ＿Ｂ＿Ｓに送信する。
【００６８】
内容としてＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴを有する信号ＵＮＡＣＫ＿ＭＡＣＤ＿ＩＮＤ１１０を受信すると、ＲＮＣはシーケンスビットマップを変更し、シーケンス番号ビットマップ内の最後に送信されたＳＮから始まるＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ番号に対応するビットマップ内のいくつかのＭＡＣ−ｄ  ＰＤＵを再送信する。ＲＮＣは、これらＭＡＣ−ｄをターゲットノードＢ：Ｎｏｄｅ＿Ｂ＿Ｔに再送信する。
【００６９】
上述したＵＥの例外処理により、いくつかのＭＡＣ−ｄ  ＰＤＵはＲＬＣ層に送信されている可能性があるが、ノードＢがＵＥ受信器の厳密な状態を決して予測できないことから、払うべき犠牲であるため、ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴの値が、ＵＥでの受信状態の悲観的な図を表すことに留意する。典型的な場合、ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴは、他のＵＥがスケジュールされる際に輻輳状況により保留中の記憶されているＭＡＣ−ｄ  ＰＤＵの量を反映する。
【００７０】
以下において、異なる時点でのＲＬＣシーケンス番号のリストを含む様々なシーケンス番号ビットマップＳＮＢ＿Ｓ、ＳＮＢ＿Ｔを示す図３および図４を参照して、第１の実施形態に関する一例を挙げる。第１のビットマップＳＮＢ＿Ｓはソース基地局に関連し、第２のビットマップは、ＵＥ、より厳密には所与のＵＥの所与の優先順位キューのソース基地局からのハンドオーバ先である潜在的なターゲット基地局に関連する。
【００７１】
例では１つの優先順位キューが示されるが、処理がＵＥのすべての優先順位キューに対して当てはまることを理解されたい。
【００７２】
１．図４のＳＮＢ＿Ｓ（１）を参照して、時間１において、ＲＮＣのＲＬＣ送信バッファ内にデータが存在しないと想定する。バッファリングされている（送信を待っている）ＲＬＣパケットもなければ、無線ネットワーク内の１つの既存ＵＥに対する肯定確認応答を待っている送信済みＲＬＣパケットもない。ＳＮＢ＿Ｓ（１）として示されるビットマップは最初、ヌル値のみを含む。本例では、ビットマップは１０に制限されるが、この値は任意の長さであってよい。例えば、ＲＬＣ付番構造の下での実際の値は、例えば、２０４８である。
【００７３】
２．時間２において、図３では１０１として示され、ＳＮＢ＿Ｓ（２）に示されるようにＲＬＣシーケンス番号０、１、２、３を有する４つのＭＡＣ−ｄを含むＨＳ＿ＤＳＣＨフレームが、ＲＮＣにより送信される。ビットマップＳＮＢ＿Ｓは、最後に送信されたシーケンス番号が一番上に現れ、スタックの中身が下に移動し、スタックの一番下が削除されるように、上から充填されるスタックとして略図に示される。
【００７４】
３．時間３において、ＲＬＣシーケンス番号４を有する第２のＨＳ−ＤＳＣＨ  ＰＤＵフレーム１０２が、ＲＮＣから送信され、このフレーム１０２は、ＳＮＢ＿Ｓ（３）に示されるように、ビットマップの一番上に現れる。
【００７５】
４．時間４において、シーケンス番号２を有するＭＡＣ−ｄがＵＥにおいて欠落していることを示すステータスＰＤＵ１０３メッセージが、ＵＥから受信される。
【００７６】
５．ＲＮＣは、新しいＨＳ＿ＤＳＣＨフレーム１０４内でＲＬＣシーケンス番号２を有するＭＡＣ−ｄを再送信する。ＲＬＣシーケンス番号２がビットマップの一番上に現れ、ビットマップの中身は下に移動する。ＳＮＢ＿Ｓ（４）参照のこと。
【００７７】
６．時間６において、ＲＮＣは、単一のＨＳ−ＤＳＣＨフレームプロトコル１０５内で、ＭＡＣ−ｄシーケンス番号５および６を有する２つのＭＡＣ−ｄ  ＰＤＵをソースノードＢに送信する。
【００７８】
７．時間７において、ＲＮＣは、ＲＮＣとＵＥとの通信を通す既存の基地局（ソースノードＢ）を新しいターゲット基地局（ターゲットノードＢ）に置き換えるハンドオーバ手順内の１ステップとして、ＵＮＡＣＫ＿ＭＡＣＫＤ＿ＲＥＱ１０８をソース基地局に送信する。ＨＳ−ＤＳＣＨハンドオーバを実行する判断が、サービングセルに隣接するセルのＵＥからの測定に基づくことに留意する。
【００７９】
８．これに応答して、ソースノードＢは、２つのＭＡＣ−ｄがソース基地局から送信するために残っている、またはＵＥによる肯定確認応答に残っていることを示すＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ＝２を有するＵＮＡＣＫ＿ＭＡＣＤ＿ＩＮＤ１１０を発行する。
【００８０】
９．ＵＥのハンドオーバ先であるターゲット基地局の変更ビットマップが、ＲＮＣにおいて確立される。ターゲット基地局のビットマップＳＮＢ＿Ｔは、ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ値により示される量に対応する数、本例では２つの上位ＲＬＣエントリをコピーすることにより作成される。ビットマップの残りのエントリはヌル値である。ＳＮＢ＿Ｔ（５）参照のこと。
【００８１】
１０．ＲＬＳシーケンス番号５および６を含むＨＳ＿ＤＳＣＨフレーム１１２が、ターゲット基地局に向けて送信される。
【００８２】
ノードＢ−内部動作
図５〜図９に、本発明の第１の実施形態による例示的な基地局の内部手順をより詳細に示す。図５〜図９に示される手順が並行に実行されることを理解されたい。
【００８３】
図５のステップ１０において、ノードＢは、本明細書ではトラフィックフローとも呼ばれる所与のＵＥの所与の優先順位キューのＨＳ−ＤＳＣＨの受信を待つ。
【００８４】
ステップ１１において、ノードＢは、トラフィックをどの優先順位キューで配信すべきかをチェックする。
【００８５】
ステップ１２において、ノードＢは、所与の優先順位キューのＨＳ−ＤＳＣＨフレームプロトコル内のＭＡＣ−ｄパケットデータユニットの量で、データ構造ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴを更新する。続けて、ルーチンはステップ１０）に進む。
【００８６】
並行して、ステップ４０および４１を含む図６に示されるルーチン、ノードＢは、ＲＮＣからのＵＮＡＣＫ＿ＭＡＣＤ＿ＲＥＱを待つ。そのような信号が受信された場合、ルーチンはステップ４１に進み、ステップ４１に従って、ノードＢは所与の使用エンティティおよび優先順位キューのデータ構造ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴの内容を有するＵＮＡＣＫ＿ＭＡＣＤ＿ＩＮＤ信号を送信する。
【００８７】
図７において、ＨＡＲＱプロセスの挙動を示すさらなるルーチンが実行される。ステップ２０において、ルーチンが開始され、ステップ２１において、送信順位がノードＢのスケジューラにより与えられるか否かがテストされる。与えられない場合、ステップ２０に進み、与えられる場合、ステップ２２に進み、ステップ２２において、ＭＡＣ−ｄ  ＰＤＵの数、優先順位キューＩＤ、およびＭＡＣ−ｈｓ送信シーケンス番号ＴＳＮが記憶される。
【００８８】
対応するＨＡＲＱプロセスが完了した場合、ステップ２３、ステップ２４において、ＭＡＣ−ｄ  ＰＤＵの量、送信シーケンス番号、および優先順位キュー情報が再び、スケジューラに報告される。
【００８９】
ＨＡＲＱプロセスは、ＵＥでの受信成功を表すフィードバック（すなわち、ＡＣＫ）の受信、またはＨＡＲＱ手順が成功せず、ＡＣＫの受信に失敗する例外処理のいずれかで完了し、ＡＣＫの受信の失敗は、構成可能な最大数の再送信が行われたこと、ＭＡＣ−ｈｓデータの最初の送信から構成可能な最長時間が測定されたこと、またはこれらの組み合わせにより発生し得る。
【００９０】
図８のステップ３０に示されるスケジューリングルーチン、所与のＵＥのＨＡＲＱプロセスの完了を待つ待機命令が実行される。そのような報告を受信する場合、送信シーケンス番号が優先順位キューの窓底ＢＯＷに等しいか否かが調べられる。ＹＥＳの場合、ステップ３３に進み、ＮＯの場合ステップ３４に進む。この実施形態では、ＨＡＲＱプロセスが成功するか、それとも成功しないかを考慮しないことに留意する。
【００９１】
ステップ３３において、データ構造ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴが更新される。特に、第１の実施形態を示す図９に示されるように、ＭＡＣ−ｄデータ構造は、ステップ３３５）に従い、報告されたＨＡＲＱプロセスから報告されたＭＡＣ−ｄ  ＰＤＵの数だけ低減される。ステップ３３６において、ＢＯＷは１でインクリメントされ、ステップ３３７において、新しいＢＯＷ送信シーケンス番号が報告され記憶されたか否かがテストされ、ＹＥＳの場合、ステップ３３５に進み、ＮＯの場合、ステップ３０に進む。
【００９２】
ステップ３４において、送信シーケンス番号、優先順位キュー、およびＭＡＣ−ｄ  ＰＤＵの数が記憶される。
【００９３】
ステップ３３の別の実施形態が図１０に付与される。
【００９４】
その場合、ステップ３３０、３３５、３３６、および３３７は、図９に示されるルーチンと等しい。
【００９５】
しかし、何等かの理由により、ＨＡＲＱプロセスが結果として成功しなかった場合、タイムアウト関数が実施される。
【００９６】
ステップ３３１において、ノードＢは、ＨＡＲＱプロセスが成功したか否かを判断する。
【００９７】
３３２において、ノードＢは、ステップ３３１での答えがＮＯであった場合、適切なタイムアウト値Ｔを決定する。有利なことには、ＨＡＲＱプロセスの報告時間が、現在の時間と比較される。例えば、Ｔ＝タイマオフセット値（現在の時間−報告時間）である。
【００９８】
ステップ３３３において、タイマが開始される。
【００９９】
ステップ３３４において、ノードＢは、送信シーケンス番号ＴＳＮ、優先順位キューＩＤ、およびいくつかのＭＡＣ−ｄ  ＰＤＵについての情報を記憶する。
【０１００】
図１１は、第２の実施形態に関連して使用されるさらなるルーチンを示す。
【０１０１】
ステップ４７において、タイマが切れたか否かが調べられる。タイマが切れている場合、データ構造ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴが、記憶されている送信シーケンス番号のＭＡＣ−ｄ  ＰＤＵの数だけ低減される。
【０１０２】
ＲＮＣ−内部動作
図１２〜図１４において、本発明の第１の実施形態による例示的なＲＮＣの内部手順をより詳細に示す。
【０１０３】
図１２では、本発明によるＲＮＣの第１のルーチンを示す。ステップ６０において、ＲＮＣはＨＳ−ＤＳＣＨフレームが送信されるまで待つ。
【０１０４】
ステップ６２において、ＨＳ−ＤＳＣＨ内のすべてのＭＡＣ−ｄがサービングされたか否かをチェックする。ＹＥＳの場合、ステップ６０に進み、ＮＯの場合、ステップ６４に進む。
【０１０５】
ステップ６４において、ＨＳ−ＤＳＣＨ内の最初のＭＡＣ−ｄがサービングされ、それにより、図４に示されるように、ＲＬＣシーケンス番号データを１番目の位置から２番目の位置に、そして以下同様に移動させることにより、ＳＮビットマップが下に移動する。したがって、ビットマップの内容全体が１ステップ下に移動する。現在のＭＡＣ−ｄの対応するＲＬＣシーケンス番号は、１番目の位置に記憶される。
【０１０６】
それにより、シーケンス番号ビットマップ内の１番目の位置は、最古または最後に送信されたデータを表す。２番目の位置は、次に最も古いデータを表し、以下同様である。ビットマップの最後の位置は、新しいデータが記録される際にフラッシュされる。
【０１０７】
ＲＮＣがＵＥの優先順位キュー毎に１つのＳＮ送信ビットマップを保持することに留意する。
【０１０８】
図１３に、ハンドオーバ時のＲＮＣのさらなる手順を付与する。
【０１０９】
ステップ７０において、ハンドオーバが決定されたか否かがチェックされる。これが該当する場合、ステップ７２において、ＲＮＣは、問題となっているＵＥのノードＢ１０８にＵＮＡＣＫ＿ＭＡＣＤ＿ＲＥＱを送信する。
【０１１０】
図１４に、本発明によるさらなるＲＮＣ手順を示す。
【０１１１】
ステップ８０において、ノードＢからのＵＮＡＣＫ＿ＭＡＣＤ＿ＩＮＤ１１０信号を待つ。
【０１１２】
ステップ８２において、ＲＮＣは、すべての優先順位キューについての応答を解析する。
【０１１３】
ステップ８４において、現在の優先順位キューについてＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴが０であるか否かがチェックされる。ＹＥＳの場合、ステップ９４に進み、ステップ８６、８８、９０、および９２がこの優先順位キューに対して実行されている場合、ＭＡＣ−ｄの送信が準備される。新しいノードＢへの準備されたすべてのＭＡＣ−ｄ  ＰＤＵは送信され、図１２によるステップが実行されて、ターゲットノードＢのＳＮＢが更新される。
【０１１４】
続けて、手順はステップ８２に戻る。
【０１１５】
ステップ８６において、ステップ８４に対するＮＯを辿り、ＲＮＣは、ＳＮビットマップ内の１番目の位置に等しいＳＮを有するＭＡＣ−ｄ  ＰＤＵをフェッチし、フェッチしたＭＡＣ−ｄ  ＰＤＵを再送信に向けて準備する。
【０１１６】
ステップ８８において、ＲＮＣは、最後に準備されたＭＡＣ−ｄを最初に送信し、以下同様に送信するように、前に準備されたＭＡＣ−ｄを再アレンジする。
【０１１７】
ステップ９０において、ＳＮビットマップは、２番目の位置を１番目の位置に移動させ、以下同様に移動させることにより更新される。ヌル値が最後の位置に設定される。
【０１１８】
ステップ９２において、ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴが１でデクリメントされ、プロセスはステップ８４に続く。
【０１１９】
したがって、少なくとも、ユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフロー（優先順位キュー）およびそのようなパケットデータユニットの所与のユーザエンティティへの転送に関する媒体アクセス制御層パケットデータユニット（ＰＤＵ１０１、１０２、１０４、１０５）を無線ネットワークコントローラ（ＲＮＣ）から受信するように構成された第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）における方法が提供される。
【０１２０】
所与のユーザエンティティへの送信は、少なくとも第２の無線基地局（Ｎｏｄｅ  Ｂ＿Ｔ）に潜在的にハンドオーバするように構成され、方法は、
−基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）が継続的に、ユーザエンティティの優先順位キューの媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ）に関する少なくともデータ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を更新するステップ（１２、３３、３３５、４１）であって、パケットデータユニットは、無線ネットワークコントローラ（ＲＮＣ  ＲＬＣ）内のプロトコル層（ＲＬＣ）から最近送信され、それにより、前記パケットデータユニットのうちの少なくともいくつかが、ユーザエンティティ（ＵＥ＿Ｑ）内の対応するプロトコル層（ＲＬＣ）によりまだ受信されていない可能性がある、更新するステップ（１２、３３、３３５、４１）、
−第１の基地局が、データ構造を要求する予め定められた信号（ＵＮＡＣＫ＿ＭＡＣＤ＿ＲＥＱ（１０８））を無線ネットワークコントローラから受信すると、上記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の現在の値を無線ネットワークコントローラ（ＲＮＣ）に送信するステップ（４１、１１０）
を特徴とする。
【０１２１】
一実施形態によれば、データ構造の更新は、自動再送要求（ＨＡＲＱ）プロセスの完了後に行うことができ、自動再送要求プロセスでは、フレームが前記基地局から前記ユーザエンティティへ送信されるようにスケジュールされ、自動再送要求の完了後、優先順位キュー毎のＭＡＣ−ｄ  ＰＤＵ数および完了した自動再送要求（ＨＡＲＱ）プロセスの対応する送信シーケンス番号（ＴＳＮ）が、第１の基地局内のスケジューラに報告される（２４）。
【０１２２】
報告に続き、送信シーケンス番号が窓底に達した後（３２）、報告された送信シーケンス番号のＭＡＣ−ｄパケットの数だけ、第１のデータ構造の値を低減すること（３３５）により、第１のデータ構造を更新し得る。
【０１２３】
第１および第２の無線基地局ならびに無線ネットワークコントローラは、有利なことには、媒体アクセス制御層パケットデータユニットが、少なくとも所与のユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローに関する、無線ネットワークコントローラ（ＲＮＣ）からのＭＡＣ−ｄパケットデータユニット、および第１または第２の基地局から前記ユーザエンティティに送信されたＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓパケットデータユニットを含む規格に従って動作することができ、方法は、
−第１の基地局が、フローバッファ内に記憶されているＭＡＣ−ｄ  ＰＤＵの量および最古に送信された否定確認応答ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ  ＰＤＵ（ＢＯＷ）を含め、ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ  ＰＤＵ内でそれまでに送信されたすべてのＭＡＣ−ｄ  ＰＤＵとしてデータ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を計算するステップ
をさらに含み得る。
【０１２４】
ＭＡＣ−ｄ  ＰＤＵが、ＭＡＣ−ｄの第１の部分が第１のＭＡＣ−ｅｈｓ（または複数の第１のＭＡＣ−ｅｈｓ）内で送信され、ＭＡＣ−ｄの第２の部分が続くＭＡＣ−ｅｈｓ内で送信されるように分割される場合、後者のみがＵＮ−ＡＣＫ＿ＭＡＣＤ＿ＣＮＴに寄与し、分割されたＭＡＣ−ｄ  ＰＤＵからの他のすべてのＭＡＣ−ｅｈｓは、ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴに寄与しない。
【０１２５】
ＭＡＣ−ｅｈｓ  ＰＤＵが、２つ以上の優先順位キューからのＭＡＣ−ｄを含む場合、ＨＡＲＱプロセス（２２）は、ＭＡＣ−ｄ  ＰＤＵの数およびＭＡＣ−ｅｈｓ内に存在する各優先順位キューの対応する優先順位キューＩＤを送信シーケンス番号と一緒に記憶する。
【０１２６】
本発明によるＲＮＣに関して、
少なくとも、基地局へのユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローに関するパケットデータユニット（ＰＤＵ１０１、１０２、１０４、１０５、図２）を受信して、そのようなパケットデータユニットを所与のユーザエンティティにさらに転送するように構成された無線ネットワークコントローラ（ＲＮＣ）の方法であって、送信は、少なくとも第２の無線基地局（Ｎｏｄｅ  Ｂ＿Ｔ）に潜在的にハンドオーバされるように構成され、方法は、
−ユーザエンティティの優先順位キューに関するシーケンス番号ビットマップ（ＳＮＢ）を保持するステップおよび無線ネットワークコントローラにより認識された、ユーザエンティティへの基地局に最後に送信されたシーケンス番号のリストを含むステップ
を特徴とする、方法が提供される。
【０１２７】
シーケンスビットマップは、送信されたおよび再送信されたシーケンス番号を含むことができ、送信されたおよび再送信されたシーケンス番号は、好ましくは、パケットデータユニットが送信された順番にビットマップ内に列挙される。
【０１２８】
本発明によれば、シーケンスビットマップは、第２の基地局へのハンドオーバ時に再送信を実行するためのベースとして使用される。
【０１２９】
さらなる実施形態によれば、変更シーケンス番号ビットマップ（ＳＮＢ＿Ｔ）が、第１の基地局シーケンス番号ビットマップ（ＳＮＢ＿Ｓ）から導出される。
【０１３０】
本発明のさらなる実施形態によれば、変更ビットマップ（ＳＮＢ＿Ｔ）は、ビットマップの有効長、すなわち、最後に送信されたシーケンス番号の量が、第１の無線基地局により示されるデータ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の値に制限される手順により、無線ネットワークコントローラ（ＲＮＣ）において達成される。
【０１３１】
変更ビットマップ（ＳＮＢ＿Ｔ）は、本発明の一実施形態によれば、データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の値により示される量に対応する数の上位エントリをコピーすることにより作成され、変更ビットマップの残りのエントリはヌル値で構成される。
【０１３２】
基地局
図１６に、本発明による基地局の方法を実施し得る基地局セット（ノードＢ）の図を示す。
【０１３３】
基地局セットノードＢ５０は、スケジューラＳＣＨＥＤＵＬＥＲ、個々のユーザエンティティＵＥ１〜ＵＥｎに関するデータストリームのセグメントを記憶するいくつかの入力バッファを備える。ＵＥ毎に、いくつかのＵＥへの同時送信を処理するいくつかのＨＡＲＱプロセッサをそれぞれ備えるＨＡＲＱエンティティ、すなわち、ユーザエンティティ毎にも同様に、各ＨＡＲＱプロセスからデータを転送するレイヤ１処理手段。基地局はさらに、ＣＱＩデコーダ、ユーザエンティティ（ＵＥ）フィードバックデコーダ、およびレイヤ１受信器をさらに備える。
【０１３４】
所与のユーザエンティティ内の各ＨＡＲＱプロセスは、ノードＢにおいてミラーリングされ、特定のユーザエンティティにより受信される所与のデータストリームに対応する。上述したように、ユーザは、ユーザエンティティ装置で実行中の１つのアプリケーションまたは恐らく異なるＱｏＳ要件を有する複数の同時アプリケーションに対応するより多数のデータストリームを同時に使用し得る。さらに、連続データを同じユーザエンティティに送信することができ、連続送信は異なるＨＡＲＱプロセスに属し得る。
【０１３５】
さらに、ノードＢは、対応するＨＡＲＱプロセスセットに専用の少なくとも１つの特定の入力バッファキューを備える。
【０１３６】
基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）は、第１の基地局として示すことができ、少なくとも、所与のユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローおよびそのようなパケットデータユニットのユーザエンティティへの転送（ＭＡＣ−ｈｓ／ＭＡＣ−ｅｈｓ）に関する媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ１０１、１０２、１０４、１０５）を無線ネットワークコントローラ（ＲＮＣ）から受信するように構成され、所与のユーザエンティティへの送信は、少なくとも第２の無線基地局（Ｎｏｄｅ  Ｂ＿Ｔ）に潜在的にハンドオーバするように構成され、方法は、
−第１の基地局（Ｎｏｄｅ＿Ｂ＿Ｓ）が継続的に、ユーザエンティティの優先順位キューの媒体アクセス制御層パケットデータユニット（ＭＡＣ−ｄ  ＰＤＵ）に関する少なくともデータ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）を更新するステップ（１２、３３、３３５、４１）であって、パケットデータユニットは、無線ネットワークコントローラ（ＲＮＣ  ＲＬＣ）内のプロトコル層（ＲＬＣ）から最近送信され、それにより、パケットデータユニットのうちの少なくともいくつかが、ユーザエンティティ（ＵＥ＿Ｑ）内の対応するプロトコル層（ＲＬＣ）によりまだ受信されていない可能性がある、更新するステップ（１２、３３、３３５、４１）、
−第１の基地局が、データ構造を要求する予め定められた信号（ＵＮＡＣＫ＿ＭＡＣＤ＿ＲＥＱ（１０８））を無線ネットワークコントローラから受信すると、前記データ構造（ＵＮＡＣＫ＿ＭＡＣＤ＿ＣＮＴ）の現在の値を無線ネットワークコントローラ（ＲＮＣ）に送信するステップ（４１、１１０）
を特徴とする。
【０１３７】
ＲＮＣ
図１５は、本発明による無線ネットワークコントローラの方法を実施し得る無線ネットワークコントローラを示す。
【０１３８】
そのような無線ネットワークコントローラは、国際公開第２００８／０９７１６８号の図４にも示されている。無線ネットワークコントローラ１２４−１は、処理ユニット４１２を備えた処理システム４１０を備える。いくつかのインタフェース４２０、４３０、および４４０が設けられる。
【０１３９】
本発明による無線ネットワークコントローラの方法は、ソフトウェアに実装し、処理ユニット４１２により実行し得る。
【０１４０】
無線ネットワークコントローラ（ＲＮＣ）は、少なくとも、第１の基地局へのユーザエンティティ（ＵＥ＿Ｑ）に関するトラフィックフローに関するパケットデータユニット（ＰＤＵ１０１、１０２、１０４、１０５、図２）を受信して、そのようなパケットデータユニットを所与のユーザエンティティにさらに転送するように構成され、送信は、少なくとも第２の無線基地局（Ｎｏｄｅ  Ｂ＿Ｔ）に潜在的にハンドオーバされるように構成され、無線ネットワークコントローラ内で実施される方法は、少なくとも、
−ユーザエンティティの優先順位キューに関するシーケンス番号ビットマップ（ＳＮＢ）を保持するステップおよび無線ネットワークコントローラにより認識された、ユーザエンティティへの基地局に最後に送信されたシーケンス番号のリストを含むステップ
を備える。
【０１４１】
発明の利点
ノードＢとＲＮＣとの間で本発明によるシグナリングを使用することにより、かつＲＮＣから新しいノードＢへの即時データ再送信を実行することにより、セル変更の影響によるＭＡＣ−ｈｓダウンロード速度の低減を最低限に抑えることができる。
【０１４２】
セル変更の影響は、下りリンクスループットが高いほど深刻である。したがって、セルサイズ（ピコセル）を低減する状況では、本発明の有利な利点が特に魅力的であるとみなされる。
【０１４３】
例えば、セル変更なしで動作中の受信性能に関して性能が劣るＵＥは、先行技術による遅延および遅延ジッタの悪影響が顕著であるため、複数のセル変更に関わる高性能ＵＥよりも性能が優れる可能性が高い。例えば、最高下りリンクビットレート１４．４Ｍｂｐｓを有するＨＳＤＰＡ環境内で動作する３．６Ｍｂｐｓ対応のＵＥ装置であって、本発明により動作し、多くのセル変更を経験するＵＥ装置は、同量のハンドオーバを受けるが、本発明の特徴を使用するネットワーク内で動作しない最大４５Ｍｂｐｓネットワーク内の１１．５Ｍｂｐｓ対応のＵＥよりも性能が良好であり、その理由は、ノードＢにおいて破棄されるデータの影響が顕著であるためである。
【０１４４】
略語
ＨＳＤＰＡ−高速下りリンクパケットアクセス
ＨＳ−ＤＳＣＨ−高速下りリンク共有チャネル
ＨＳ＿ＳＣＣＨ−ＨＳ＿ＤＳＣＨの共有制御チャネル
ＨＳ＿ＰＤＳＣＨ−高速物理下りリンク共有チャネル
ＭＡＣ−ｈｓ−媒体アクセス制御−高速
ＭＡＣ−ｅｈｓ−媒体アクセス制御−エンハンスト高速
ＰＤＵ−プロトコルデータユニット
ＡＣＫ−肯定確認応答
ＮＡＣＫ−否定確認応答
ＤＴＸ−不連続送信
ＥＵＬ−エンハンスト上りリンク
ＨＡＲＱ−ハイブリッド自動再送要求
ＣＱＩ−チャネル品質インジケータ
ＴＳＮ−トランスポートシーケンス番号
ＲＬＣ−無線リンク制御
ＳＮ−シーケンス番号
ＵＥ−ユーザ機器
ＣＲＣ−巡回冗長検査
ＴＣＰ−伝送制御プロトコル
ＤＬ−下りリンク
ＲＧＣＨ−Ｅ−ＤＣＨ相対認可チャネル
ＡＧＣＨ−Ｅ−ＤＣＨ絶対認可チャネル
ＨＩＣＨ−Ｅ−ＤＣＨ  ＨＡＲＱ肯定確認応答インジケータチャネル
ＤＣＨ−専用チャネル
ＣＣＨ−共通チャネル
ＳＩ−スケジューリング情報
ＭＩＭＯ−多入力多出力
ＬＴＥ−長期エボリューション
Ｅ−ＤＣＨ−エンハンスト専用チャネル
ＨＴＴＰ−ハイパーテキスト転送プロトコル
【０１４５】
参照
３ＧＰＰ、２５．２１１、２５．３２１
【図１】
0005342012.tif 000002
【図２】
0005342012.tif 000003
【図３】
0005342012.tif 000004
【図４】
0005342012.tif 000005
【図５】
0005342012.tif 000006
【図６】
0005342012.tif 000007
【図７】
0005342012.tif 000008
【図８】
0005342012.tif 000009
【図９】
0005342012.tif 000010
【図１０】
0005342012.tif 000011
【図１１】
0005342012.tif 000012
【図１２】
0005342012.tif 000013
【図１３】
0005342012.tif 000014
【図１４】
0005342012.tif 000015
【図１５】
0005342012.tif 000016
【図１６】
0005342012.tif 000017