JP4981904B2 - 媒体アクセス制御破棄通知 - Google Patents

Description

本発明は、ユーザエンティティ（ＵＥ：ｕｓｅｒ ｅｎｔｉｔｙ）と無線基地局（Ｎｏｄｅ‐Ｂ：ノードＢ）と無線ネットワークコントローラ（ＲＮＣ：ｒａｄｉｏ ｎｅｔｗｏｒｋ ｃｏｎｔｒｏｌｌｅｒ）との間のパケットデータトラフィック及び信号送信に関する。本発明は、とりわけＭＡＣ‐ｈｓ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｈｉｇｈ Ｓｐｅｅｄ：媒体アクセス制御高速）及びＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｌａｙｅｒ：無線リンク制御レイヤ）データ送信プロトコルを利用するＨＳＰＤＡ（Ｈｉｇｈ Ｓｐｅｅｄ Ｐａｃｋｅｔ Ｄａｔａ Ａｃｃｅｓｓ：高速パケットデータアクセス）トラフィックに関する。

ＨＳＰＤＡは、ダウンリンク資源のフレキシブルな割当てによって、ＵＭＴＳ基地局（ノードＢ）から複数のユーザエンティティへ高速ダウンリンクアクセスを提供する。

先行技術文献の国際公開第２００５／０３４１８号パンフレットの図３において、ユーザエンティティ（例えば移動局）と、ノードＢ（基地局）と、ＲＮＣ（パーツＣＲＮＣ及びＳＲＮＣによって実施される）との間の通信に関するプロトコルレイヤが示されている。ユーザエンティティは、以下のレイヤに関する。すなわち、ＰＨＹ（物理レイヤ）、ＭＡＣ‐ｈｓ（ＨＳＰＤＡ媒体アクセス制御レイヤ）、ＭＡＣ＿ｄ（媒体アクセス制御装置）ＲＬＣ（無線リンク制御レイヤ）。ノードＢは、それぞれ、ＭＡＣ‐ｈｓレイヤを介してユーザエンティティと通信し、フレームプロトコルＨＳ＿ＤＳＣＨ‐ＦＰを介してＲＮＣと通信する。

ＨＳＰＤＡ仕様書によれば、ＲＬＣは、プロトコルスタックにおけるＭＡＣ‐ｈｓプロトコルの上で作動する。ＲＬＣレイヤは、ＴＣＰ／ＩＰのような上位通信レイヤへの接続をユーザエンティティとＲＮＣとの両方において提供する。ＲＬＣプロトコルとＭＡＣ‐ｈｓプロトコルとの両方は、誤って受信されたプロトコルデータユニットの送信を特徴とするＡＲＱ（Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ：自動再送要求）プロトコルである。

その名のとおり、３ＧＰＰにおいて導入される高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）技術は、実質的データ容量の効果を提供する。技術仕様書３ＧＰＰ ＴＳ ２５．３２１は、機能的観点から、ＭＡＣ（媒体アクセスコントロール）アーキテクチャと様々なエンティティとに関する。３ＧＰＰ ２５．２１１は、基本的に、オンエア送出チャネル上にＭＡＣレイヤからの情報がどのようにマッピングされるのかについて説明する。

ＲＮＣとＵＥとの間のチャネルを排他的に定めるリリース９９（ＧＳＭ／ＥＤＧＥ）と比べて、ＨＳＰＤＡは、ユーザエンティティと、ノードＢとも呼ばれる基地局組（ＮＯＤＥ Ｂ）との間で終了するＨＳ‐ＤＳＣＨ（Ｈｉｇｈ Ｓｐｅｅｄ Ｄｅｄｉｃａｔｅｄ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ：高速専用共有チャネル）チャネルを導入する。ＨＳＰＤＡ媒体アクセス制御（ＭＡＣ‐ｈｓ）は、リンク適応（適応変調符号化、すなわち１６ＱＡＭ又はＱＰＳＫ）による増加したパケットデータスループットと高速の物理レイヤ再送信組合せとを可能にする。ゆえに、ＷＣＤＭＡアクセス技術を組み込むことのほかに、ノードＢは、ユーザエンティティとノードＢとの間でスケジューリング及びハイブリッド自動再送要求（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ：Ｈ‐ＡＲＱ）再送信を実行する。上述のシステムの利点及び特徴は、例えばステファン・パルクヴァルらによる「ＷＣＤＭＡ発展す――高速パケットデータサービス」、エリクソンレヴュー（Ｅｒｉｃｓｓｏｎ ｒｅｖｉｅｗ）２号、２００３年、において説明されている。

ＨＳＰＤＡ送信は、２ｍｓの送信時間（３タイムスロット）を使用する。

ダウンリンク側に提供されるのは、いくつかの共通データチャネル１と、ＨＳＰＤＡ送信を使用するユーザエンティティごとに信号無線ベアラ専用ダウンリンク物理チャネル（ＤＰＣＨ‐Ｒ９９）２とであり、制御信号送信のための共通高速共有制御チャネル（ＨＳ‐ＳＣＣＨ）３と、ＨＳＰＤＡデータをフレキシブルに割り当てられる複数の高速‐物理ダウンリンク共有チャネル（ＨＳ‐ＰＤＳＣＨ）共通ユーザデータチャネル４〜５である。

アップリンク側に提供されるのは、とりわけチャネル品質情報ＣＱＩ、ＨＳＰＤＡ自動要求信号送信を提供する高速‐専用物理コントロールチャネル（ＨＳ‐ＰＤＣＣＨ）６と、制御情報及びデータを含む各ＨＳＰＤＡユーザに関連するアップリンク専用チャネル７とである。

ＨＳＤＰＡ（Ｈｉｇｈ Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ：高速ダウンリンクパケットアクセス）は、ノードＢからユーザエンティティ（ＵＥ）へダウンリンク上の高速送信を容易にする。ＨＳＰＤＡのもとで、ノードＢは、入来ダウンリンクエンドユーザデータをバッファし、内部スケジューリングエンティティを活用して、スケジューリングルーチンにしたがって、バッファしたデータをどの特定のチャネルでいつ送信するかを判定する。スケジューリング決定に向けるために、ノードＢはＵＥエンティティからチャネル品質推定を連続的に受信する。ノードＢもＵＥ受信能力についての認識を有する。

ノードＢは、ＵＥへＭＡＣ‐ｈｓＰＤＵ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｈｉｇｈ Ｓｐｅｅｄ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ：媒体アクセス制御高速プロトコルデータユニット）を最高毎秒５００回のペースで送信可能である。２ｍｓ送信機会（ＴＴＩ送信時間）ごとに、ノードＢは、バッファされたデータ量と、チャネル品質推定と、ＵＥ能力と、許諾された使用可能ダウンリンク符号量とに依存して、ＭＡＣ‐ｈｓＰＤＵサイズを変更可能である。１つのＵＥから最大４つのＵＥに対するＭＡＣ‐ｈｓデータは、スケジュールされたＵＥの間で、符号分割（ＷＣＤＭＡ）を活用して、２ｍｓ送信機会ごとにスケジュール可能である。

ＵＥは、ＨＳ‐ＳＣＣＨ（Ｈｉｇｈ Ｓｐｅｅｄ Ｓｈａｒｅｄ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ：高速共有制御チャネル）を復号し、成功ＣＲＣチェックサムの上で、ＵＥはＨＳ‐ＰＤＳＣＨ（Ｈｉｇｈ Ｓｐｅｅｄ Ｐｈｙｓｉｃａｌ Ｄａｔａ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ：高速物理データ共有チャネル）の復号を続行する。ＨＳ‐ＳＣＣＨとＨＳ‐ＰＤＳＣＨとの結果に依存して、ＵＥは受信フィードバックをピアノードＢへ返信する。

受信フィードバックは、ノードＢ送信機によって解読され、ノードＢ送信機は、ＵＥに対してあり得る受信失敗を示す否定フィードバック又はフィードバック欠如（ＤＴＸ）の上で、データ送信する。

仕様書３ＧＰＰ２５．３２１チャプタ１１．６．１及び１１．６．２によれば、活用されるのは、ＨＳＰＤＡ Ｎ‐チャネルストップアンドウェイト（ＳＡＷ）ＡＲＱが活用され、１〜８個のＨＡＲＱプロセッサがユーザエンティティごとに同時に存在可能であるということが示される。ダウンリンクＨＳ‐ＤＰＣＣＨチャネルとＨＳ‐ＰＤＳＣＨ上のアップリンクＡＣＫ／ＮＡＣＫ送信との間のタイミング関係は固定であり、つまり、送信とユーザエンティティからの関連期待ＡＣＫ／ＮＡＣＫとの間に常に７．５〜９．５ＴＴＩスロットがあるように、ＡＣＫ、ＮＡＣＫメッセージは送信されるものである。これにより、第１の送信に対する応答がない場合にデータをいつ再送信するかノードＢが簡単に判定可能になる。

＜基地局及びユーザエンティティ＞
図１２及び１３において、基地局組（ノードＢ）及びユーザエンティティ（ＵＥ）の図をそれぞれ示す。

基地局組、ノードＢは、ＭＡＣ‐ｈｓ制御メッセージハンドラと、スケジューラと、個々のユーザエンティティＵＥ１〜ＵＥｎに関するデータストリームのセグメントを格納する複数の入力バッファと、いくつかのＵＥへの同時送信を処理する複数のＨＡＲＱ処理に対応して、つまり各ユーザエンティティに対しても、それぞれのＨＡＲＱ処理からデータを転送するレイヤ１処理手段を備える。基地局は、ＣＱＩデコーダと、ユーザエンティティ（ＵＥ）フィードバックでコーダと、レイヤ１受信機をさらに備える。

任意のユーザエンティティにおける各ＨＡＲＱ処理は、ノードＢにおいて反映され、特定のユーザエンティティが受信する任意のデータストリームに対応する。上述のように、おそらくは異なるＱｏＳ要求について、より多くのデータストリームが、ユーザエンティティ装置上で動作する１つのアプリケーション又は２以上の同時のアプリケーションに対応して、ユーザによって使用可能である。さらに、連続データが同一のユーザエンティティに対して送信可能であり、連続送信異なるＨＡＲＱ処理に属する。

さらに、ノードＢは、対応のＨＡＲＱ処理組専用の少なくとも１つの特別な入力バッファ待ち行列を備える。

図１３において、本発明によるユーザエンティティ（ＭＡＣ）構成を示し、これは、ダウンリンクＨＤ‐ＰＤＳＣＨチャネルを復号するＨＳ‐ＳＣＣＨ復号手段と、Ｊ個のＨＡＲＱ処理からなる構成、Ｎ個の再配列及び分解待ち行列と、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ：無線リンク制御）レイヤ手段とを含むものである。さらに提供されるのは、ＵＥ（ユーザエンティティ）フィードバック処理手段と、ＨＳ‐ＤＰＣＣＨチャネル上でフィードバックを処理するレイヤ１処理とである。

再配列待ち行列配分機能は、待ち行列ＩＤに基づいて、ＭＡＣ‐ｈｓＰＤＵを正しい再配列バッファへルーティングする。再配列エンティティは、受信ＴＳＮ（ｔｒａｎｓｍｉｔ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ：送信シーケンス番号）にしたがって受信ＭＡＣ‐ｈｓＰＤＵを再配列する。上昇するＴＳＮ（ＭＡＣｈｓ送信シーケンス番号）を有するＭＡＣ‐ｈｓＰＤＵが分解機能へ配信される。３ＧＰＰ ＴＳ ２５．３２１‐１１．６．２において説明されるものと同一の回避処理がＭＡＣ‐ｈｓＰＤＵに欠損する場合に誤った条件からリカバリするために、再配列リリースタイマ及びウィンドウベースのストール回避が使用されるであろう。待ち行列ＩＤごとに１つの配列エンティティがＵＥにおいて構成される。分解エンティティは、ＭＡＣ‐ｈｓＰＤＵの分解に対する責任がある。ＭＡＣ‐ｈｄヘッダが削除されると、ＭＡＣ‐ｄＰＤＵは抽出され、いかなるパディングビットも削除される。次にＭＡＣ‐ｄＰＤＵはより高位の（ＲＬＣ）レイヤへ配信される。これらの特徴は３ＧＰＰ ＴＰ ２５．３２１‐１１．６．２．３に記載されている。

＜ＲＬＣレイヤ＞
３ＧＰＰにおけるＲＬＣレイヤは３つのモードで作動可能であり、３つのモードとは、透過（ｔｒａｎｓｐａｒｅｎｔ）モードと、未確認（ｕｎａｃｋｎｏｗｌｅｄｇｅｄ）モードと、確認モード（ＡＭ：ａｃｋｎｏｗｌｅｄｇｅｄ ｍｏｄｅ）とであり、以下で焦点を当てることとする。

ＡＭモードにおいて、受信側が発見する誤受信ＰＤＵ（プロトコルデータユニット）は、ＡＲＱ（自動再送要求）プロトコルによって送信側が再送信するようにもたらされる。

ＡＭ ＲＬＣは送信側と受信側とからなり、ＡＭ ＲＬＣエンティティの送信側はＲ
ＬＣＰＤＵを送信し、ＡＭ ＲＬＣの受信側はＲＬＣ ＰＤＵを受信する。

ＡＭ ＲＬＣエンティティがＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ：ユーザイクイップメント）及びＲＮＣ（ｒａｄｉｏ ｎｅｔｗｏｒｋ ｃｏｎｔｒｏｌ：無線ネットワークコントロール）にそれぞれ存在する。送信側は、ＲＬＣ ＳＤＵ（ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ：サービスデータユニット）を固定長のＰＤＵへセグメント化及び／又は連結させる。受信側は、受信ＰＤＵのＲＬＣ ＳＤＵへの再組立てを行い、これらを高位データレイヤへ送信する。同様に、ＳＤＵは、ＲＬＣレイヤより上のレイヤから受信される。ＡＭモードにおいて、ＲＬＣレイヤは連番でＳＤＵを配信する責任がある。

上述の文書、国際公開第２００５／０３４４１８号パンフレットの図４において、確認モード（ＡＭ）ＵＥ（基地局）／ＵＴＲＡＮ（無線アクセスノード／基地局（ノードＢ））エンティティの実施形態が示されている。

立て続けの配信を容易にするために、各ＲＬＣ ＰＤＵにはシーケンス番号０〜４０９５が与えられ、それにより、４０９６を法としたシーケンス番号について昇順に、送信機はＰＤＵを送信する。シーケンス番号を用いて、受信機は、欠損ＰＤＵを検出可能である。欠損ＰＤＵを検出した際には、受信機がＳＴＡＴＵＳメッセージを送信するようにしてもよい。ＳＴＡＴＵＳ報告は、ピアＲＬＣエンティティが受信する個々のＲＬＣ ＰＤＵの正又は負の確認応答を含む場合がある。送信機は、ＰＤＵヘッダにおいてポールフラグ（Ｐｏｌｌ Ｆｌａｇ）を設定することにより受信機からＳＴＡＴＵＳメッセージを要求することも可能である。送信機がポールフラグに設定する条件はとりわけ以下である。
‐バッファにおける最終ＰＤＵ
入力バッファにＰＤＵがただ１つだけ存在する場合。
‐ポールタイマ満了
ｔｉｍｅｒ＿ｐｏｌｌが満了する場合、つまり、送信機がＳＴＡＴＵＳを先に要求し、応答が受信されることを再保障するためにｔｉｍｅｒ＿ｐｏｌｌを開始した場合。
‐ウィンドウベースで
ＳＴＡＴＵＳが受信側に受信を確認するまでに送信可能な「未処理データ（ｏｕｔｓｔａｎｄｉｎｇ ｄａｔａ）」の量について、送信機が制限される。「未処理データ」とは、最も先に確認されたＰＤＵに関するものである。

ＲＬＣレイヤの機能について上述した説明は、実際に提供される特徴をわずかな抜粋を構成するだけのものである、ということに留意されたい。

例えばＳＴＡＴＵＳメッセージが、シーケンス番号（ＳＮ）が３、６及び１３であるＰＤＵが欠損していると示す場合には、選択的再送信が可能である。

＜ＭＡＣ‐ｈｓレイヤ＞
ＭＡＣ‐ｈｓレイヤに関する以下の説明においては、
‐ＭＡＣ‐ｈｓ送信機はノードＢである。
‐ＭＡＣ‐ｈｓ受信機は、ダウンリンク３ＧＰＰ ＨＳＤＰＡトラフィックを受信可能な移動局又はＰＣに設置されるｐｃカード又は他のイクイップメントであるＵＥイクイップメントである。

ＭＡＣ‐ｈｓＰＤＵは、フィールド０〜６３にわたり巡回するＴＳＮ（移送シーケンス番号）を法として付番される。

上述のように、ＭＡＣ‐ｈｓプロトコルは複数のハイブリッドＡＲＱ処理（ＨＡＲＱ）を提供し、それにより、ＨＡＲＱ処理ごとに、送信機はＭＡＣ‐ｈｓＰＤＵを送信し、受信機における受信を示すＡＣＫか、又は受信機がＭＡＣ‐ｈｓＰＤＵを受信していないことを示す否定応答（ＮＡＣＫ：Ｎｅｇａｔｉｖｅ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）か、又は応答の欠如（ＤＴＸ）を待機する。ＭＡＣ‐ｈｓＰＤＵ送信からフィードバック（ＡＣＫ／ＮＡＣＫ）の受信までの時間に関する往復時間は固定である。ＮＡＣＫ又はＤＴＸを受信すると、ＭＡＣ‐ｈｓ送信機はＭＡＣ‐ｈｓＰＤＵを再送する。往復時間はＭＡＣ‐ＨＳＰＤＵサイズに関して長いため、また複数のユーザが時間多重化方式でパケットを受信するよう適応可能であるため、複数のＨＡＲＱ処理が提供される。ＨＡＲＱ処理がただ１つ使用可能であった場合、デューティサイクル（すなわち実際の送信時間／あり得る送信時間の総量）低いであろう。複数のＨＡＲＱ処理を用いることで、あるＨＡＲＱ処理が応答を待機可能であり、一方で別のＨＡＲＱ処理又は複数のＨＡＲＱ処理が送信可能である。それにより、デューティサイクルを１００パーセント近くにまですることが可能である。

ＭＡＣ‐ｈｓプロトコルには準信用性（ｓｅｍｉ‐ｒｅｌｉａｂｌｅ）があり、つまり、ＭＡＣ‐ｈｓ送信機は、ＭＡＣ‐ｈｓ受信機へ送信され、またおそらくは再送信されたＭＡＣ‐ｈｓＰＤＵを破棄すること又は削除することを選択可能である。

再送信用のＭＡＣ‐ｈｓを破棄することにより、ＭＡＣ‐ｈｓ受信機が別のセルへ移動した又は電源を切られた場合、又は何か他の理由で受信機がデータ受信不能である場合、無線リンクにわたる不要な送信が防止される。したがって、着目するパケットの第１の送信に対応する所定の時刻（例えばＴ１）に設定されたタイマの満了の際、又は着目するパケットの最大数の再送信が行われたとき、又は入力データバッファにおけるあまりに長い待ち時間に、又は最初に出現するものならば何にでも、あるいはそれらの組合せに基づいて、バッファされたパケットが送信機において破棄される。

ＰＤＵが非昇順シーケンス順序で受信されると（再送信が原因で起こり得るものである）、ＭＡＣ‐ｈｓ受信機は、不要な送信の効果を軽減する目的で、受信機ウィンドウを活用する。次の期待ＴＳＮに等しいＴＳＮ（送信シーケンス番号）でＭＡＣ‐ｈｓＰＤＵの受信が成功するときはいつでも、受信機はＲＬＣレイヤへＰＤＵを配信可能である。後続のＴＳＮ番号（すなわち次の期待ＴＳＮ＋１）の受信が成功したかどうかに依存して、当該ＭＡＣ‐ｈｓＰＤＵもまた配信可能であり、以下同様である。受信機ウィンドウは適宜更新される。ＭＡＣ‐ｈｓプロトコルからＲＬＣレイヤへの配信は、連続する順序で行われ、これをインシーケンス（ｉｎ‐ｓｅｑｕｅｎｃｅ）ともいう。

例えば送信機がＭＡＣ‐ｈｓＰＤＵを破棄したという状況からリカバリするために、受信機は２つの機構Ｉ）＋ＩＩ）を活用して、問題を解決する。

Ｉ）タイマベースのストール回避
ＴＳＮ＞ｎｅｘｔ＿ｅｘｐｅｃｔｅｄ＿（次に期待の）ＴＳＮのＰＤＵを受信すると、受信機は、Ｔ１というタイマを開始する。タイマが満了すると、受信機は適切な行動をとり、後続のＰＤＵの受信を可能にする。正確な詳細は、３ＧＰＰ ２５．３２１チャプタ１１．６．２．３．２において説明されている。挙動を図１に示す。

時刻１）において、ＴＳＮ＝４のＰＤＵが受信され、次に期待される送信シーケンス番号は３であり、それによってタイマＴ１が開始する。

時刻２）において、ＴＳＮ６及び７のＰＤＵが受信される。

時刻３）において、タイマは満了し、それによってＴＳＮ＝４がＲＬＣレイヤへ配信される。ｎｅｘｔ ｅｘｐｅｃｔｅｄ＿ＴＳＮ＝５。ｎｅｘｔ＿ｅｘｐｅｃｔｅｄ＿ＴＳＮ＝５が受信されず、少なくとも１つのＰＤＵが受信機ウィンドウに存在するため、新たなタイマＴ１が開始する。

ＴＳＮ６及び７はバッファに残る。

ＩＩ）ウィンドウベースのストール回避
受信機ウィンドウの外側のＴＳＮのＰＤＵを受信すると、受信機は、その「右の（ｒｉｇｈｔ）」（又は「上の（ｕｐｐｅｒ）」）ウィンドウエッジ及びｈｉｇｈｅｓｔ＿ｒｅｃｅｉｖｅｄ＿（最高の受信）ＴＳＮを受信ＴＳＮへシフトするであろう。ｎｅｘｔ＿ｅｘｐｅｃｔｅｄ＿ＴＳＮが、ｈｉｇｈｅｓｔ＿ｒｅｃｅｉｖｅｄ＿ＴＳＮへ更新されるであろう‐受信機ウィンドウサイズ＋１｜以前はウィンドウに格納され、今度はウィンドウの範囲内にあるＰＤＵがＲＬＣレイヤへ配信されるであろう。これを図２に示した。

受信機ウィンドウサイズは長さ８であると仮定する。

時刻１）において、ＰＤＵ ＴＳＮ４が受信され、受信機ウィンドウ内であり、ＴＳＮ＝３がｎｅｘｔ＿ｅｘｐｅｃｔｅｄ＿ＴＳＮであり、タイマＴ１は動いている。

時刻２）において、ＴＳＮ＝１２が受信され、受信機ウィンドウ内であり、したがってウィンドウを進めさせ、ｎｅｘｔ＿ｅｘｐｅｃｔｅｄ＿ＴＳＮは更新され、ＰＤＵ ＴＳＵ＝４がＲＬＣへ配信される。ｎｅｘｔ＿ｅｘｐｅｃｔｅｄ＿ＴＳＮが受信されず、ＰＤＵが受信機ウィンドウに存在するため、新たなタイマＴ１が開始する。

ＭＡＣ‐ｈｓリセット
ＭＡＣ‐ｈｓは、ＭＡＣ‐ｈｓプロトコルを再開するために使用され、ＭＡＣ‐ｈｓ受信機は、受信機ウィンドウに格納されるデータをＲＬＣレイヤへ配信し、そのｎｅｘｔ＿ｅｘｐｅｃｔｅｄ＿ＴＳＮ＝０に、ｈｉｇｈｅｓｔ＿ｒｅｃｅｉｖｅｄ＿ＴＳＮ＝６３に設定する。それはセル間のハンドオーバのような条件で使用される。

＜既存の解決手段における問題＞
固定ネットワークから、例えばラップトップに挿入されたｐｃカードを有する３ＧＰＰ ＨＳＤＰＡネットワークに存在するピアユーザへ、ＴＣＰセッションが開始する場合を仮定する。固定ネットワークにおけるＴＣＰ送信機は、非常に低量のデータを送信することによって開始する。ＲＬＣレイヤは無線ネットワークコントローラ（ＲＮＣ）に存在するということと、それは２つのＲＬＣ ＰＤＵ内でノードＢへデータを送信するということとをさらに仮定する。２つのＰＤＵは、ノードＢ入来データバッファにまず格納される。図３がその状況を示す。

さらに、ノードＢが両方のＲＬＣ ＰＤＵをＴＳＮ＝０の１つのＭＡＣ‐ｈｓＰＤＵで送信すると仮定する。ここで、送信が失敗し、ノードＢが、ＰＤＵの送信を、そのＰＤＵがノードＢにおいて最終的に破棄されるまで繰り返すと仮定する。次にノードＢは、そのウィンドウをそのＢｏＷ（Ｂｏｔｔｏｍ ｏｆ Ｗｉｎｄｏｗ：ウィンドウ最下部）としてのシーケンス番号１へ進める。図４がその状況を示す。

続いてＲＬＣポールタイマが満了すると、ＲＬＣは最後のＲＬＣ ＰＤＵ（ＴＳＮ＝４６）を再送信する。ノードＢは、ＲＬＣ ＰＤＵデータを受信し、そのデータを１つのＭＡＣ‐ｈｓでＵＥへ送信するであろう。受信が成功すると仮定する。受信ＴＳＮ＜＞ｎｅｘｔ＿ｅｘｐｅｃｔｅｄ＿ＴＳＮであるため、ＵＥはそのＴ１タイマを開始するであろう。

複製ＲＬＣ ＰＤＵがノードＢにバッファされるのを回避するため、ノードＢにおける第１の送信からノードＢがＭＡＣ‐ｈｓＰＤＵを破棄するまでの時間はＰｏｌｌ＿ｔｉｍｅｒよりも短いと仮定する。図５がその状況を示す。

ここで、ＭＡＣ‐ｈｓ受信機におけるＴ１タイマ＜ＲＬＣにおけるポールタイマ、と仮定すると、続いてＵＥにおけるＴ１タイマが満了し、ＰＤＵは、ＲＬＣ受信機（ＲＬＣ ＴＳＮ＝４６）によって受信されるであろう。ＵＥにおけるＲＬＣ受信機が、欠如するＴＳＮ＝４５のＲＬＣ ＰＤＵを示すＳＴＡＴＵＳメッセージを送信するであろう。するとＲＬＣ送信機は、ＴＳＮ＝４５のＲＬＣ ＰＤＵを再送信し、ＵＥ ＭＡＣ‐ｈｓ受信機において受信に成功すると、ＲＬＣレイヤは上位レイヤへＲＬＣ ＰＤＵ４５及び４６を配信可能である。

ＭＡＣ‐ｈｓ受信機におけるＴ１タイマ＞ＲＬＣにおけるポールタイマであると、それでも別のＲＬＣ ＰＤＵ４６が送信されるであろうが、しかしＴ１タイマが依然として動いているため、ＲＬＣ受信機へはＴ１が満了するまで何も送信されないであろう、という別のシナリオが発生する場合もある。ＵＥにおけるＴ１が満了すると、ＴＳＮ４６の複数のコピーがＲＬＣ受信機によって受信されるであろう。

上述のように、ここでＵＥは、ＴＳＮ＝４５の欠如を示すＳＴＡＴＵＳを送信し、ＲＬＣにおいてＳＴＡＴＵＳメッセージを受信すると、ＲＬＣはＴＳＮ＝４５を再送信するであろう。ＭＡＣ‐ｈｓレイヤを介したＴＳＮ＝４５のＲＬＣ ＰＤＵの配信成功を仮定すると、ここでＵＥ ＲＬＣレイヤは、その上位レイヤへ完全データシーケンスＴＳＮ＝４５及び４６を配信可能である。

ＰＤＵがＲＬＣ受信機において正しく受信されるまでの遅延は、Ｐｏｌｌ＿ｔｉｍｅｒ＋ＲＮＣにおけるＲＬＣからＵＥにおけるＭＡＣ‐ｈｓへのＲＬＣ ＰＤＵ送信時間＋ＵＥにおけるＴ１タイマ＋ＵＥからＲＬＣへのＳＴＡＴＵＳ制御メッセージＵＬ送信時間＋ＲＮＣにおけるＲＬＣからＵＥにおけるＲＬＣへのＲＬＣ ＰＤＵ送信時間である、と結論可能である。

より高いトラフィックロードの場合、例えばＴＣＰが高速で動いている場合、より多くの送信がノードＢとＵＥとの間に発生するから、ＵＥがそのＴ１タイマをより開始しやすくなるので、問題はより気付きにくいものとなる。高ロードトラフィックの場合、第１（タイマベース）又は第２（ウィンドウベース）のリカバリ機構が、Ｕｅに、データをＲＬＣへ配信させる。ＰＤＵが欠損するにあたりＳＴＡＴＵＳを送信するよう構成されると、ＵＥはＳＴＡＴＵＳを送信するであろう。すると送信ＲＬＣエンティティは、ｐｏｌｌ＿ｔｉｍｅｒが満了するより先にＳＴＡＴＵＳメッセージを受信するであろう。

まとめると、２つのＡＲＱ（自動再送要求）インシーケンス配信プロトコルレイヤが同一のプロトコルスタックにおいて動作するところ、基盤のＡＲＱプロトコルがデータを破棄すると、上述のデータ遅延問題が、２つのＡＲＱプロトコルを上で操作するアプリケーションによってわかるように、発生する場合がある。低トラフィックロード状況の間に問題が発生すると、自動解消が発生するまで相対的に長い遅延を引き起こしかねない。

本発明の第１の課題は、２つのプロトコルレイヤを有し、各レイヤは確認肯定応答／否定応答信号送信にしたがって動作するシステムに起こり得るタイムラグを取り除くことである。

確認モード（ＡＭ）におけるＲＬＣ及びＭＡＣ‐ｈｓ信号送信のために適応される基地局組（ノードＢ）のための方法であって、基地局組は少なくとも無線ネットワークコントローラ（ＲＮＣ）からユーザエンティティ（ＵＥ）へプロトコルデータユニット（ＭＡＣ‐ｄＰＤＵ）を送信し、基地局組の送信エンティティのＭＡＣレイヤを監視する（１）ステップと、ＭＡＣレイヤにおいてＭＡＣ破棄が発生した場合、プロトコルデータユニットの破棄を示す破棄通知メッセージを、基地局組におけるＭＡＣ送信エンティティから無線ネットワークコントローラ（ＲＮＣ）のＲＬＣレイヤへ送信するステップとを含む方法によって、この課題は完遂された。

また、ＲＬＣ及びＭＡＣ‐ｈｓ信号送信のために適応される基地局組（ノードＢ）のための方法であって、基地局組は確認モードにおけるユーザエンティティ及び無線ネットワークコントローラと通信し、基地局組の送信エンティティのＭＡＣレイヤを監視するステップと、ＭＡＣレイヤにおいてＭＡＣ破棄が発生した場合、ユーザエンティティのＭＡＣ受信機へＭＡＣ‐ｈｓ＿ｂリセットメッセージを送信するステップとを含む方法によっても、上課題は完遂された。

さらに、ＲＬＣ及びＭＡＣ‐ｈｓ信号送信のために適応されるユーザエンティティ（ＵＥ）のための方法であって、無線ネットワークコントローラ（ＲＮＣ）が、少なくとも、プロトコルデータ（ＭＡＣ‐ｄＰＤＵ）を、前記ユーザエンティティ（ＵＥ）へさらに送信する基地局組（ノードＢ）へ送信し、
ＭＡＣ‐ｈｓ＿ｂリセットメッセージを受信する（４０４）と、次に期待される送信シーケンス番号（ＴＳＯ）を０にリセットするステップと、最高受信送信シーケンス番号を６３にリセットするステップと、ユーザエンティティのＲＬＣレイヤへ全部の受信ＲＬＣプロトコルデータユニット（ＰＤＵ）を配信するステップと、基地局へ確認肯定応答メッセージを送信するステップとを含む方法によっても、代替的に完遂された。

追加の効果は、以下の、発明を実施するための形態から明らかとなろう。

先行技術Ｔ１タイマベースのストール回避を示す。 先行技術ウィンドウベースのストール回避を示す。 先行技術においてあり得る周知のシナリオに関連する問題を示す。 先行技術においてあり得る周知のシナリオに関連する問題を示す。 先行技術においてあり得る周知のシナリオに関連する問題を示す。 本発明による例示的シナリオを示す。 本発明による例示的シナリオを示す。 第１の比較先行技術シナリオを示す。 第２の比較先行技術シナリオを示す。 本発明の第１、第２及び第３の実施形態に関する流れ図を示す。 本発明の第２の実施形態に関する流れ図を示す。 第４の発明に関する流れ図を示す。 本発明による基地局を示す。 本発明によるユーザエンティティを示す。

本発明によれば、先行技術に関する上の問題場合の発生を発見し、誤った状況からよりはやくリカバリするための明示的な信号送信を提供する様々な解決手段が示される。

＜実施形態１＞
上で議論したデータ破棄の効果を軽減するための本発明の第１の実施形態によれば、ノードＢは、ＰＤＵ破棄が出現したということをノードＢ破棄通知メッセージでＲＬＣレイヤまで示す。この通知は、ノードＢがＭＡＣ‐ｈｓＰＤＵの破棄を行うと起こる。本発明によれば、信号送信は、新たなＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ：情報エレメント）として、又は新たな制御メッセージとして起こる場合がある。破棄通知の受信に続いて、ＲＬＣ送信エンティティが何の行動をとるか決める。

図９に、ノードＢにおいて実行される手続に関する流れ図を示す。

ステップ１において、ノードＢは、送信エンティティの確認モードにおけるＭＡＣレイヤを監視する。

ＡＭ送信エンティティにおけるＭＡＣレイヤにおいてＭＡＣ破棄が発生すると、ステップ３、ノードＢは、直接ステップ７へ進み、ノードＢのＭＡＣレイヤは、ＲＮＣのＲＬＣレイヤへ、ＭＡＣレイヤにおいてＭＡＣ破棄が発生したと示す破棄通知メッセージを送信する。

適宜、ステップ７において、破棄通知メッセージは、破棄されたデータ量の信号送信を含み、また適宜、着目する破棄されたＰＤＵのＲＬＣシーケンス番号を含む。

続いて、ＲＮＣにおけるＲＬＣ送信レイヤエンティティは、破棄通知にしたがって行動し、ステップ８、それによってＲＮＣ送信エンティティは以下のステップのうちの少なくとも１つを行う。

Ａ）さらにデータが入力バッファに存在する場合には、破棄通知を無視して、入力バッファからのデータ送信を続行する。入力バッファにデータが存在しない場合にも、ＲＮＣは破棄通知を無視可能である。これは、ＲＮＣが欠損ＰＤＵの再送信のために既存のより高位のプロトコルに依存する、又は破棄メッセージのための処理手段の欠如の原因となり得ることを意味する。

Ｂ）全部の未処理のＲＬＣ ＰＤＵを送信する、つまり、送信済みだが未確認のＰＤＵ全部を再送信し、最後のＰＤＵ上にポールビットを設定する。

Ｃ）ポールビットを最後のＰＤＵに設定して、破棄通知に適宜含まれるシーケンス番号を有するＰＤＵを再送信する。

Ｄ）ペンディングＲＬＣ ＰＤＵが送信を待機する場合に、ポールビットを設定した、又は設定していない単一のＲＬＣ ＰＤＵ（最高送信シーケンス番号（ＳＮ））を再送信する。

Ｅ）ＭＡＣ‐ＨＳリセットを呼び出す。これにより、ＭＡＣ‐ｈｓ受信機が、ＲＬＣ受信機へデータを配信させられる。

＜実施形態２＞
図１０に、本発明の第２の実施形態を示す。

本発明の第２の実施形態によれば、第１の実施形態と共通の同一の参照番号のステップを有し、以下の手続が実行される。

ステップ１において、ノードＢは、送信エンティティの確認モードにおけるＭＡＣレイヤを監視する。

ノードＢにおける入力バッファにＭＡＣ‐ｄＰＤＵのＭＡＣ破棄が発生する場合、すなわちＵＥへの当該ＭＡＣ‐ｄＰＤＵの送信がまだ発生していない場合、ステップ２、手続はステップ７へ行き、さもなければステップ３へ行く。

ステップ３において、確認モードエンティティにおけるＭＡＣレイヤにＭＡＣ破棄が発生したかどうかテストされ、ｎｏの場合には手続はステップ１へ行き、ｙｅｓの場合には手続はステップ４へ進む。

ステップ４において、破棄ＭＡＣ‐ｈｓＰＤＵの送信シーケンス番号より大きいが、送信機送信ウィンドウ内である送信シーケンス番号（ＴＳＮ）のＭＡＣ‐ＨＳに対して確認肯定応答（ＡＣＫ）が受信されたかどうかが調査される。ｎｏの場合にはステップ５へ進み、ｙｅｓの場合にはステップ６へ進む。ステップ４からステップ６へ移動する場合の効果となるように、破棄通知を送信しない理由は、ＵＥがそのＴ１タイマを開始しており、Ｔ１タイマが満了すると、ＵＥは欠損ＰＤＵをＲＬＣに通知するであろうという事実による、ということに留意されたい。

ステップ５において、入力バッファにペンディングＭＡＣ‐ＨＳ送信又はデータがあるかどうか調査される。ｙｅｓの場合にはステップ６へ進み、ｎｏの場合にはステップ７へ進む。ステップ５からステップ６へ進む理由は、ノードＢがＭＡＣ‐ｈｓを一般に昇順ＴＳＮ番号順序で送信するという事実による。ＵＥに対するＭＡＣ‐ｈｓの送信試行より先に、ノードＢは、ノードＢ送信ウィンドウにおいてあり得る最低ＴＳＮを選択することを試すであろう。これは、例えばＴＳＮ＝ｎについて破棄が発生すると、ノードＢがＴＳＮ＜ｎについてペンディングＭＡＣ‐ｈｓ送信を有するということはあり得ない、ということを意味する。同様に、受信されたが、まだ送信はされていないＭＡＣ‐ｄＰＤＵが発生する場合、このようなＰＤＵはＴＳＮ＞ｎで送信されるであろう。当業者には了解されるように、ＴＳＮは６４を法として数えられるものであり、そのことを上で与えた例でも考慮しなければならない。

ステップ６において、破棄通知は１つも送信されない。

ステップ７において、ＲＬＣレイヤへのＭＡＣレイヤ送信破棄通知が送信され、破棄が発生したことを通知し、破棄されたデータ量を適宜含む。図９におけるステップ８のもとで図示し説明したステップ８において手続は続行し、本発明の第２の実施形態によって、ノードＢは、上述と同様に同一の後続ステップでノードＢ破棄通知メッセージを送信する。

第１の実施形態と比べると、この実施形態、本発明の第２の実施形態は、ノードＢとＲＮＣとの間の信号送信を削減する。

＜実施形態３＞
送信ＲＬＣエンティティを、その決定について援助するために、ノードＢ破棄通知メッセージは、ノードＢが破棄したデータ量を含む。あるいは、ＭＡＣ‐ｄＰＤＵを調べることによって、ノードＢは、ＲＬＣシーケンス番号を復号し、破棄されたシーケンス番号を特定することが可能である。
このオプションを図９においてステップ７に示した。この情報を使用することによって、ＲＮＣは、どのＲＬＣ ＰＤＵが再送信を要求するかを推定可能であり、又は、ＲＬＣシーケンス番号が提供されると、破棄されたそれらのＰＤＵのみを再送信可能である。

＜実施形態４＞
代替的ＭＡＣ‐ｈｓリセットが、ノードＢから送信可能な制御メッセージとして定められ、ＭＡＣ‐ｈｓｂ＿ｒｅｓｅｔと表す。この手続を図１１に示す。ユーザエンティティＵＥは受信機であり、ノードＢは送信機である。

ステップ４０１において、ＡＭ送信エンティティにおけるＭＡＣレイヤは監視される。

ＭＡＣ破棄が発生すると、ステップ４０２、ＭＡＣレイヤにおいて、ＭＡＣ送信機エンティティは、本発明によって、ＭＡＣ‐ｈｓユーザエンティティ受信機へＭＡＣ‐ｈｓｂ＿ｒｅｓｅｔメッセージを送信する、ステップ４０３。メッセージは、ノードＢからユーザエンティティＵＥへ送信される。さもなければ、手続はステップ４０１へ行く。

ＭＡＣ‐ｈｓｂ＿ｒｅｓｅｔを受信すると、４０４、ＭＡＣ‐ｈｓ受信機は、そのｎｅｘｔ＿ｅｘｐｅｃｔｅｄ＿ＴＳＮを０へ、ｈｉｇｈｅｓｔ＿ｒｅｃｅｉｖｅｄ ＴＳＮを６３へリセットし、全部の受信ＲＬＣ ＰＤＵをＲＬＣレイヤまで配信するであろう、４０５。ＭＡＣ‐ｈｓｂ＿ｒｅｓｅｔメッセージは、続いて、ユーザエンティティＵＥによって確認されるであろう、４０６。

確認肯定応答を受信すると４０７、ＭＡＣ‐ｈｓ送信機は、その送信機ＢｏＷを０に設定するであろう、ステップ４０８。

送信機は、否定応答の上で、ステップ４０４を参照、メッセージを繰り返して、受信機がメッセージの受信に成功することを再保証するであろう。ＭＡＣ‐ｈｓｂ＿ｒｅｓｅｔ送信中、及び確認肯定応答が受信されるまでの時間、他の送信は１つも発生しないであおる。これは、ＴＳＮ解釈のあいまいさを回避するためである。

ＭＡＣ‐ｈｓｂ＿ｒｅｓｅｔは、特定のＵＥについてデータが１つも送信されない時間、周期的に使用可能である。これを用いて、送信機と受信機とが同一のＢｏＷ解釈を有することを確証可能である。

＜例示的シナリオのもとでの本発明と先行技術との比較＞
［図６ａ＋６ｂ］
図６ａ及び６ｂにおいて、本発明の第１の実施形態による例示的ハンドシェイク図を示し、以下のステップが発生する／実行される例示的シナリオに関する。

１０１）少量のデータが、特定のユーザに対するＲＮＣにおいて受信される。
（例えば、ユーザが、ＵＥへ向かうダウンリンクＴＣＰセッションを開始し、ＴＣＰスピードはランプアップするところであると仮定する。）

１０２）ＲＮＣが、受信データを２つのＭＡＣｄＰＤＵでノードＢへシーケンス番号４５及び４６で送信する。ＲＮＣが、最後に送信されたＰＤＵ（ＳＮ４６）上にＰＯＬＬ ＦＬＡＧを設定し、ａ）データがＵＥにおいて正しく受信されたことか、又はｂ）配信が失敗したら、ＲＮＣはＰＯＬＬ ＦＬＡＧタイマが満了すると再送信を開始することかのどちらかを再保証する。

１０３）ノードＢが、ＴＳＮ＝０の単一のＭＡＣｈｓＰＤＵでデータを送信する。

１０４）ノードＢが、ＵＥからのＮＡＣＫ（又は応答なし（ＤＴＸ））のため、データを再送信する。ノードＢは、ステップ１０５が起きるまでこのステップを続ける。

１０５）図９ステップ２に対応して、Ｔ１タイマが満了するため、ノードＢがＴＳＮ＝０のＭＡＣｈｓＰＤＵを破棄する。

１１２）図９ステップ５に対応して、ノードＢが、ＤＩＳＣＡＲＤ（破棄）通知をＲＮＣへ送信する。

１２０）図９ステップ６オプションＤに対応して、ＤＩＳＣＡＲＤ通知は、ＲＮＣのＲＬＣレイヤによって受信され、ＲＬＣレイヤは続いてＳＮ＝４６のＰＤＵを送信し、ＰＯＬＬ ＦＬＡＧタイマを再開する。

代替として、ＲＮＣは、ＳＮ＝４５とＳＮ＝４６との両方を再送信可能であるということに留意されたい。この手法を用いて、ステップ１４０）から、及びステップ１４０）以上を含むステップは回避可能である（以下を参照）。

１２５）ノードＢが、ＲＮＣからＭＡＣ‐ｄＰＤＵを受信し、ＴＳＮ＝１の１つのＭＡＣ‐ｈｓＰＤＵで送信する。ＵＥがデータを受信し、ＡＣＫを送信するが、ＵＥはＴＳＮ＝０を期待するため、そのＴ１タイマを開始し、ノードＢがＴＳＮ＝０を再送信することを可能とするであろう（この例では起こることはないのであるが）。

１３０）Ｔ１タイマはＵＥ ＭＡＣ‐ｈｓにおいて満了する。ｎｅｘｔ＿ｅｘｐｅｃｔｅｄ＿ＴＳＮは２に設定され、ｈｉｇｈｅｓｔ＿ｒｅｃｅｉｖｅｄ＿ＴＳＮは１に設定される。ＴＳＮ＝１の再組立て後、データはＲＬＣへ配信される。

１３５）ＵＥにおけるＲＬＣは、ＳＮ＝４５を欠損していると、またＳＮ＝４６を受信されていると識別するＳＴＡＴＵＳメッセージを送信する。

１４０）ＲＮＣにおけるＲＬＣはＳＴＡＴＵＳを受信し、ＳＮ＝４５を再送信し、ＰＯＬＬ ＦＬＡＧタイマを再開する。

１４５）ノードＢがＲＮＣからＭＡＣ‐ｄＰＤＵを受信し、ＴＳＮ＝２のＭＡＣ‐ｈｓＰＤＵを送信する。ＵＥはデータを受信し、ＡＣＫを送信する。データはＲＬＣへ配信される。

１５０）ＵＥにおけるＲＬＣレイヤは、ＳＮ＝４６を最高受信シーケンス番号と識別するＳＴＡＴＵＳメッセージを送信する。ＳＴＡＴＵＳメッセージは、様々な方法で構成される。例えば、ＳＴＡＴＵＳは、任意のシーケンス番号まで全部正しく受信されると示す場合がある。またＳＴＵＴＵＳメッセージは、受信及び非受信シーケンス番号を示すビットマップとして形成される場合もある。

ＳＴＡＴＵＳメッセージの受信の際、ＲＮＣにおけるＲＬＣはＰＯＬＬ ＦＬＡＧタイマを停止する。

１５５）再組立て後、ＵＥにおけるＲＬＣは上位レイヤへＲＬＣ ＳＤＵを配信する。

［図７シナリオ］
図７において、先行技術による例示的ハンドシェイク図を示し、以下のステップを含む例示的シナリオに関する。

２０１）少量のデータが、特定のユーザに対するＲＮＣにおいてが受信される。
（例えば、ユーザがＵＥに向かうダウンリンクＴＣＰセッションを開始し、ＴＣＰスピードはランプアップするところであることを仮定する。）

２０２）ＲＮＣが受信データを２つのＭＡＣｄＰＤＵでノードＢへシーケンス番号４５及び４６で送信する。ＲＮＣが、最後に送信されたＰＤＵ（ＳＮ４６）上にＰＯＬＬ ＦＬＡＧを設定して、ａ）データがＵＥにおいて正しく受信されることか、又はｂ）配信が失敗する場合、ＲＮＣは、ＰＯＬＬ ＦＬＡＧタイマが満了すると再送信を開始することかのどちらかを再保証する。

２０３）ノードＢが、ＴＳＮ＝０の単一のＭＡＣｈｓＰＤＵでデータを送信する。

２０４）続いて、送信と再送信とが試行される、が、依然としてエアーインターフェースに不具合。

２０５）ノードＢが、ＳＮ＝０のＭＡＣｈｓＰＤを破棄する。

２０６）時間が経過する。

２０７）ＰＯＬＬ ＦＬＡＧタイマがＲＮＣにおいて満了する。ＲＮＣは、ここでａ）４５及び４６を再送信し、最後に送信されたＰＤＵ（ＳＮ＝４６）上にＰＦ（Ｐｏｌｌ Ｆｌａｇ：ポールフラグ）を設定するか、又はｂ）ＰＦを設定した最終ＰＤＵ（ＳＮ＝４６）を送信するかする。
ｂ）を図に示す。

２０８）ノードＢによる送信が成功するが、ＵＥはＴＳＮ＝０を期待するため、そのＴ１タイマ開始して、ノードＢがＴＳＮ＝０を再送信可能とする。

２０９）時間が経過するが、おそらくは以前のタイマ（２０６）ほど長くはない。

２１０）Ｔ１タイマが満了し、Ｎｅｘｔ＿Ｅｘｐ＿ＴＳＮ＝２、最高受信ＴＳＮ＝１、受信データはＲＬＣに送信される。

２１１）ＵＥ ＲＬＣは、ＳＮ４５を欠損と、ＳＮ＝４６を受信されていると示すＳＴＡＴＵＳを送信する。

２１３）ＳＮ４５がＲＮＣによって再送信される。

本発明によれば、タイムラグ２０６）と、２１１及び２１３を実行する時間とは回避され、さもなければそれぞれステップ２０５）〜２０７）の間に現れるであろう、ということが認識される。

［図８シナリオ］
図８のシナリオは、図７と同様であるが、ＲＮＣがより多くのデータを受信してしまうが、３０７）を参照、ＳＮ４５、４６の確認肯定応答を待機するという点で異なる。

このシナリオは、ＰＯＬＬ ＦＬＡＧタイマ待機時間が回避されるため、図７に示すシナリオよりはやくリカバリするであろう。図６ａ＋６ｂと比較すると、ステップ３０７）が１２０）｜図６ａ＋６ｂと同時に起こると仮定すれば、遅延は同一となろう。
ステップ１２０）におけるＲＮＣが代わりにＳＮ＝４５とＳＮ＝４６との両方を再送信した場合、図８の期間３１２）本発明によって回避可能である。

時間Ｘ、ステップ３０５）において、本発明は、４５、４６が破棄されたと示す破棄通知を送信する。ステップ３０１＝３１３は上のステップ２０１〜２１３に大きく対応する。

Claims (6)

1. 確認モード（ＡＭ）におけるＲＬＣ及びＭＡＣ‐ｈｓ信号送信のために適応される基地局組（ノードＢ）のための方法であって、前記基地局組は少なくとも無線ネットワークコントローラ（ＲＮＣ）からユーザエンティティ（ＵＥ）へプロトコルデータユニット（ＭＡＣ‐ｄＰＤＵ）を送信し、
   前記基地局組の送信エンティティのＭＡＣレイヤを監視する（１）ステップと、
   前記ＭＡＣレイヤにおいてＭＡＣ破棄が発生した（３）場合、
   プロトコルデータユニットの破棄を示す破棄通知メッセージを、前記基地局組における前記ＭＡＣ送信エンティティから前記無線ネットワークコントローラ（ＲＮＣ）のＲＬＣレイヤへ送信する（７）ステップであって、前記破棄通知メッセージは、破棄されたデータのＲＬＣシーケンス番号（ＳＮ）を含む、送信する（７）ステップとを含み、さらに、
   前記無線ネットワークコントローラのRLCレイヤから、前記破棄通知メッセージに含まれたRLCシーケンス番号のプロトコルデータユニット（PDU)を再送信するステップを含む、方法。
2. 前記破棄通知（７）メッセージは破棄されたデータの量の情報を含む、請求項１に記載の方法。
3. 入力バッファにおけるデータのＭＡＣ破棄が発生していないが（２）、前記確認モードエンティティにおける前記ＭＡＣレイヤにＭＡＣ破棄が発生し（３）、破棄された送信シーケンス番号より大きい送信シーケンス番号（ＴＳＮ）のＭＡＣ‐ｈｓに対して肯定確認応答が受信された（４）場合、又は前記入力バッファにペンディングＭＡＣ‐ｈｓ送信又はデータがある（５）場合、破棄通知メッセージを送信することを控える（６）、請求項１又は２に記載の方法。
4. 確認モード（ＡＭ）におけるＲＬＣ及びＭＡＣ‐ｈｓ信号送信のために適応される無線ネットワークコントローラ（ＲＮＣ）のための方法であって、前記無線ネットワークコントローラ（ＲＮＣ）は、少なくとも、プロトコルデータユニット（ＭＡＣ‐ｄＰＤＵ）を、ユーザエンティティ（ＵＥ）へさらに送信する基地局組（ノードＢ）へ送信し、
   前記基地局組におけるＭＡＣ送信エンティティから破棄通知メッセージを受信するとき、
   Ａ）データを送信することを続行することと、
   Ｂ）全部の未処理ＲＬＣプロトコルデータユニットを再送信することと、
   Ｃ）シーケンス番号が前記破棄通知メッセージにおいて提供されたプロトコルデータユニットを再送信することと、
   Ｄ）ポールビット設定あり又はなしの単一のＲＬＣプロトコルデータユニットを再送信することと、
   Ｅ）ＲＬＣレイヤがＭＡＣ‐ｈｓ‐リセットオペレーションを呼び出すことと
   のうちの少なくとも１つを行う（８）ステップを含む方法。
5. 確認モード（ＡＭ）におけるＲＬＣ及びＭＡＣ‐ｈｓ信号送信のために適応される基地局組（ノードＢ）であって、前記基地局組は少なくとも無線ネットワークコントローラ（ＲＮＣ）からユーザエンティティへプロトコルデータユニット（ＭＡＣ‐ｄＰＤＵ）を送信し、前記基地局は、
   前記基地局組（１）の送信エンティティのＭＡＣレイヤを監視（１）し、
   前記ＭＡＣレイヤにおいてＭＡＣ破棄が発生する場合（３）、
   プロトコルデータユニットの破棄を示す破棄通知メッセージを、前記基地局組のＭＡＣ送信エンティティから前記無線ネットワークコントローラ（ＲＮＣ）のＲＬＣレイヤへ送信し、
   前記破棄通知メッセージは、破棄されたデータのＲＬＣシーケンス番号（ＳＮ）を含み、
   前記無線ネットワークコントローラのRLCレイヤから、前記破棄通知メッセージに含まれたRLCシーケンス番号のプロトコルデータユニット（PDU)を受信する、基地局組（ノードＢ）。
6. 確認モード（ＡＭ）におけるＲＬＣ及びＭＡＣ‐ｈｓ信号送信のために適応される無線ネットワークコントローラ（ＲＮＣ）であって、前記無線ネットワークコントローラ（ＲＮＣ）は、少なくとも、プロトコルデータユニット（ＭＡＣ‐ｄＰＤＵ）を、ユーザエンティティ（ＵＥ）へさらに送信する基地局組（ノードＢ）へ送信し、
   前記基地局組におけるＭＡＣ送信エンティティから破棄通知メッセージを受信するとき、
   Ａ）データを送信することを続行することと、
   Ｂ）全部の未処理ＲＬＣプロトコルデータユニットを再送信することと、
   Ｃ）シーケンス番号が前記破棄通知メッセージにおいて提供されたプロトコルデータユニットを再送信することと、
   Ｄ）ポールビット設定あり又はなしの単一のＲＬＣプロトコルデータユニットを再送信することと、
   Ｅ）ＲＬＣレイヤがＭＡＣ‐ｈｓ‐リセットオペレーションを呼び出すことと
   のうちの少なくとも１つを行う（８）無線ネットワークコントローラ（ＲＮＣ）。

Images