無線通信システムにおけるエラー制御メッセージを処理するための方法及び装置
【課題】ユーザスケジューリングにおいて、ステータスレポートの送信遅延を回避する。
【解決手段】ＲＬＣ ＡＲＱ制御メッセージなどのエラー制御メッセージの処理のための方法及び装置が開示される。一例としての方法は、データを送信するためにリンクリソースが必要であることをメディアアクセスコントローラ（ＭＡＣ）へシグナリングすることと、当該データを送信するためのリンクリソースが利用可能であることを示す標識をＭＡＣから受信することと、当該標識の受信後に、現在のエラー制御ステータスに基づいてエラー制御メッセージを生成することと、を含む。そして、エラー制御メッセージは、送信のためにＭＡＣへ転送される。エラー制御メッセージの生成はその送信のためのリソースがス利用可能になるまで遅らせられるため、陳腐化した制御メッセージのキューイングが回避される。
【解決手段】ＲＬＣ ＡＲＱ制御メッセージなどのエラー制御メッセージの処理のための方法及び装置が開示される。一例としての方法は、データを送信するためにリンクリソースが必要であることをメディアアクセスコントローラ（ＭＡＣ）へシグナリングすることと、当該データを送信するためのリンクリソースが利用可能であることを示す標識をＭＡＣから受信することと、当該標識の受信後に、現在のエラー制御ステータスに基づいてエラー制御メッセージを生成することと、を含む。そして、エラー制御メッセージは、送信のためにＭＡＣへ転送される。エラー制御メッセージの生成はその送信のためのリソースがス利用可能になるまで遅らせられるため、陳腐化した制御メッセージのキューイングが回避される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、無線通信システムに関し、より具体的には、リンクリソースをスケジューリングする無線通信システムにおけるエラー制御メッセージの処理に関する。
【背景技術】
【０００２】
３ＧＰＰ（The Third-Generation Partnership Project）は、“Long Term Evolution”あるいはＬＴＥとして知られるイニシアティブの下、高度化された無線通信システムの標準を開発するプログラムを立ち上げた。標準化の議論において、ＬＴＥシステムが無線リンク制御（ＲＬＣ）プロトコルにおいて自動再送要求（ＡＲＱ：automatic repeat request）の仕組みを利用することが合意されている。その仕様化されたＡＲＱプロトコルは（“ＲＬＣ確認モード（RLC Acknowledged Mode）”において使用される）選択的再送プロトコル（selective repeat protocol）であり、それにより受信ノードから送信ノードへステータスレポートを送信する手段と共に、送信ノードがステータスについて受信ノードにポーリングする（poll）ための手段が提供される。ステータスレポートの受信に応じて、送信ノードは、失われたいずれかのデータを再送してもよく、又は適切な他のアクションをとってもよい。ポーリングに応じて、一般的に、受信機は、ステータスレポートを送信する。しかしながら、ステータスレポートの送信は、ある状況下では禁止され得る。例えば、前回のステータスレポートの送信時に開始されるステータス−禁止タイマは、ある期間についてステータスレポートを遮断し得る。
【０００３】
また、３ＧＰＰの開発者らは、ポーリング及びステータストリガのセットと共に、ポーリング又はステータスレポートのいずれかに対するノードの応答を規制するタイマを仕様化することに合意した。３ＧＰＰ ＬＴＥ標準に含めるように近日合意されたトリガ及びタイマの例は、以下を含む：
・欠損したプロトコルデータユニット（ＰＤＵ）の検出時の自動ステータスレポート；
・送信バッファ内の最後のＰＤＵの送信に応じた自動的なポーリング、それによりデータのバーストが完全に受信されたことの確証が送信ノードに提供される；
・ノードによる過度に高い頻度でのステータスレポートの送信を防止するためのステータス−禁止タイマ、これは過度に高い頻度でのステータスレポートが不必要な再送を生じさせるからである；
・返答されなかった欠損したであろうポーリングが再送されることを保証するためのポーリング−再送タイマ
【０００４】
当然ながら、追加的なトリガ及びタイマもまた、ＬＴＥにおいて採用される可能性がある。ＬＴＥのためのＲＬＣ ＡＲＱプロトコルは、究極的には、３ＧＰＰ ＴＳ２５．３２２において仕様化された広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）のＲＬＣプロトコルと多くの類似性を有するであろうことを予期することができる。確認モード（Acknowledged Mode）に加えて、ＬＴＥのためのＲＬＣプロトコルは、非確認モードと共に透過モードをも含むであろう。
【０００５】
従来型のＲＬＣ ＡＲＱスキームにおいて、ＲＬＣタイマ及びステータスレポートは、あるトリガに応じて生成される。例えば、受信ノードがポーリングを受信し、ステータス禁止タイマが稼動していない場合には、受信ノードは、現在の受信機のステータスを表すステータスレポートを即座に生成する。典型的なステータスレポートは、最後に受信されたプロトコルデータユニット（ＰＤＵ）についての識別子及び／又は受信が成功しなかった１つ以上のＰＤＵについての否定応答を含み得る。そして、ステータスレポートはメディアアクセス制御（ＭＡＣ）層に送信ノードへの送信のために提供される。（いわゆる当業者は、各無線通信ノードが典型的には送信機と受信機とを含むことを理解するであろう。さらに、ＡＲＱスキームは、双方向に実装されてもよい。本開示の目的のために、“送信ノード”という用語は、確認モードにおいて“受信ノード”に１つ以上のデータＰＤＵを送信するノードを一般的に指す。３ＧＰＰの専門用語において、確認モードデータは、“確認モードのＲＬＣエンティティの送信側”から送信され；当該ＰＤＵは“ピアエンティティ”あるいは確認モードのＲＬＣエンティティの“受信側”へ伝送される。このような用法を前提として、受信ノードは、送信ノードにステータスＰＤＵを送信し得る。同様に、送信ノードはステータスＰＤＵを受信し得る。）
【０００６】
ステータス−禁止タイマを活用するシステムにおいて、受信ノードは、典型的には、ステータスレポートがＲＬＣ層からＭＡＣ層へ転送された時点でステータス−禁止タイマを起動する。すると、タイマが終了するまでは、その間にステータスレポートについての１つ以上の新たなトリガが発生した場合でも、さらなるステータスレポートは許可されない。そうしたトリガは、送信ノードから受信される他のポーリング、又は欠損したＰＤＵの検出などであり得る。よって、ステータス禁止時間は、後に続くステータスレポートが少なくともステータス−禁止タイマにより特定される期間だけ遅らせられることを保証する。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＬＴＥシステムにおいて、（移動体基地局の伝送についての）アップリンクは、スケジューリング対象のリソースであり、スケジューリングはサービング基地局（ＬＴＥにおいて、進化したノードＢあるいはｅＮｏｄｅＢと呼ばれる）により制御される。結果として、所与の瞬間において、移動局は即座には送信リソースへのアクセスを有しないであろう。アップリンクリソースがスケジューリングされていない時点で移動局におけるＭＡＣ層がＲＬＣ層からステータスレポートを受信すると、移動局はｅＮｏｄｅＢにステータスレポートを送信し得る前に、まずそのリソースを要求しなければならない。ｅＮｏｄｅＢによりスケジューリングが制御されているために、アップリンクリソースの許可が大きく遅れる場合もある。例えば、マルチユーザスケジューリングはリソースの割り当てを遅らせる可能性があり、あるいは初期スケジューリング要求は送信に際して欠損する可能性もある。結果として、ステータスレポートの送信は、ステータスレポートにより記述される受信機の状態がその送信前でさえ陳腐となるような程度にまで、遅延され得る。
【課題を解決するための手段】
【０００８】
ここに開示するのは、ＲＬＣ ＡＲＱ制御メッセージなどのエラー制御メッセージを処理するための方法及び装置である。一例としての方法は、データを送信するためにリンクリソースが必要であることをメディアアクセスコントローラ（ＭＡＣ）へシグナリングすることと、データを送信するためのリンクリソースがスケジューリングされていることを示す標識をＭＡＣから受信することと、上記標識の受信後に、現在のエラー制御ステータスに基づいてエラー制御メッセージを生成することと、を含む。そして、エラー制御メッセージは、送信のためにＭＡＣへ転送される。エラー制御メッセージの生成はその送信がスケジューリングされるまで遅らせられるため、キューイング及び陳腐化した（stale）制御メッセージの送信は回避される。
【０００９】
本発明の他の観点において、ＲＬＣ ＡＲＱ制御メッセージの送信が開始され又は確認応答された場合に、ＭＡＣは、無線リンクコントローラ（ＲＬＣ）に通知をしてもよい。その通知に応じて、ＲＬＣコントローラは、エラー制御タイマを起動し又は再開し得る。当該タイマは、例えば、ポーリングタイマ又はステータス禁止タイマを含む。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態に係る通信システムの単純化された図である。
【図２】図１のシステムにおいて活用され得るいくつかの通信プロトコルの階層を示している。
【図３】ＡＲＱステータスレポートの形成についてのスケジューリングの遅延の影響を示している。
【図４】ＡＲＱポーリングタイマについてのスケジューリングの遅延の影響を示している。
【図５】一実施形態に係るＡＲＱステータスレポートの生成のタイミングを示している。
【図６】本発明の一実施形態に係るポーリングタイマ処理を示している。
【図７】エラー制御メッセージを処理する一例としての方法を示す論理フロー図である。
【図８】本発明の１つ以上の実施形態に係る無線装置のブロック図である。
【発明を実施するための形態】
【００１１】
図１は、通信システム１０の単純化された図であり、通信システム１０は、送信ノード１１０及び受信ノード１２０を含む。上で議論したように、送信ノード１１０及び受信ノード１２０の各々は、完全な送受信機を備え；“送信”及び“受信”という用語は、確認応答がなされるデータ伝送における特定のエンドポイントを説明するために使用される。よって、送信ノード１１０はプロトコルデータユニット（ＰＤＵ）を含む１つ以上のデータユニットを受信ノード１２０へ送信し、また、ポーリング要求などの１つ以上のエラー制御メッセージを送信する。（以下で議論するように、ポーリングなどのエラー制御メッセージは、トラフィックデータとしての同じプロトコルデータユニットに含まれてもよい。）そして、受信ノード１２０は、ステータスレポートなどの１つ以上のエラー制御メッセージを送信し、又は受信に失敗したＰＤＵの再送を要求し得る。
【００１２】
本発明のいくつかの実施形態において、送信ノード１１０はＬＴＥｅＮｏｄｅＢにより構成され、受信ノード１２０はＬＴＥに準拠した移動局により構成されてもよい。その場合、図１に描かれたデータユニットはダウンリンク上でｅＮｏｄｅＢにより送信され、１つ以上のエラー制御メッセージはアップリンク上で送信される。しかしながら、いわゆる当業者は、逆方向においても、アップリンク上でのＰＤＵの伝達におけるエラーの検出のためにＡＲＱスキームが実装され得ることを理解するであろう。その場合、送信及び受信ノードの役割は、ｅＮｏｄｅＢと移動局との間で逆になる。
【００１３】
ここで開示される本発明としての技術は、ＬＴＥシステムについて言及しながら説明されるが、本発明はそうしたシステムに限定されるものではない。実際、以下の説明を読み添付図面を見た技術知識を有する実施者は、多様な無線システムに、特にアップリンク若しくはダウンリンク又はその双方において送信リソースを動的にスケジューリングするシステムに、ここで説明される技術が適用され得ることを理解するであろう。
【００１４】
図１の通信ノードの各々は、３ＧＰＰにより仕様化されたＬＴＥプロトコルなどの特定の通信プロトコルに従って動作するように構成される。図２には、いくつかのプロトコル階層が示されており；これらプロトコル階層は、通信ノードの各々において、アナログ及びデジタルハードウェア、適切なソフトウェアと共に構成されるプログラム可能なプロセッサ、又はそれらの組み合わせを用いて実装され得る。特に、ＬＴＥ移動局であり得る送信ノード１１０は、例えばＬＴＥｅＮｏｄｅＢである受信ノード１２０のプロトコルスタック２２０における対応するプロトコル階層と通信するプロトコルスタック２１０内のプロトコル階層を使用し得る。
【００１５】
プロトコルスタック２１０及び２２０の各々は、物理層、データリンク層、及びネットワーク層を含む。データリンク層は、無線リンク制御（ＲＬＣ）層及びメディアアクセス制御（ＭＡＣ）層という２つの副階層に分けられる。一例としての本実施形態において、ネットワーク層は、制御プレーンプロトコル（ＲＲＣ）及びユーザプレーンプロトコル（ＩＰ）に分割される。
【００１６】
ＬＴＥシステムにおいて、物理層は、ダウンリンクについては直交周波数分割多重アクセス（ＯＦＤＭＡ）技術、アップリンクについては密接に関連するシングルキャリア周波数分割多重アクセス（ＳＣ−ＦＤＭＡ）を使用する。一般に、物理層は、エア（無線）インタフェース上でのデータ伝送を提供し、トランスポートチャネルの多重化及び逆多重化、トランスポートチャネルの物理チャネル上へのマッピング、物理チャネルの変調及び復調、順方向誤り訂正符号化及び復号、周波数及び時間同期、送信電力制御、並びにＲＦ処理などの機能を備える。
【００１７】
メディアアクセス制御（ＭＡＣ）層は、一般的に、ピアＭＡＣエンティティ間のサービスデータユニット（ＳＤＵ）の非確認の（unacknowledged）伝送を提供する。ＭＡＣ機能は、各トランスポートチャネルについてのデータレートに依存する適切なトランスポートフォーマットの選択、（複数のユーザをサポートする基地局における）様々なユーザのデータフロー間の優先度の取り扱い、制御メッセージのスケジューリング、並びに上位層のＰＤＵの多重化及び逆多重化などを含み得る。ＬＴＥシステムにおいて、リソースのスケジューリングは、ＭＡＣ層によっても実行される。特に、アップリンクリソースは、移動局についてのＭＡＣ層により要求されることができ、ｅＮｏｄｅＢ内の対応するＭＡＣ層により移動局の間で割り当てられる。
【００１８】
ＲＬＣ層は、ＲＬＣ接続の確立、解放及び維持、可変長の上位層のＰＤＵのより小さいＲＬＣ ＰＤＵとの間のセグメント化及び再結合、連結、再送信（ＡＲＱ）による誤り訂正、上位層のＰＤＵのシーケンス内配信（in-sequence delivery）、重複検出、フロー制御、並びに他の機能を含む様々な機能を実行する。
【００１９】
ＲＲＣプロトコルは、例えば無線アクセスベアラの制御シグナリング、メジャメントレポート、及びハンドオーバシグナリングなどの無線インタフェース上の制御シグナリングを扱う。ネットワーク層のユーザプレーン部分は、周知のインターネットプロトコル（ＩＰ）などのレイヤ３プロトコルにより実行される従来型の機能を含む。
【００２０】
プロトコルスタック２１０及び２２０内の無線リンク制御（ＲＬＣ）プロトコル階層は、自動再送要求（ＡＲＱ）の仕組みを含む。送信ノード１１０内のＲＬＣ層は、ユーザデータを受信し、セグメント化し、ＲＬＣ ＰＤＵに変換する。いくつかの実施形態において、送信されたＲＬＣ ＰＤＵは、送信されたメッセージがデータＰＤＵなのか制御ＰＤＵなのかを示すフィールドを含み得る。他のあるフィールドは、ポーリングフィールドに相当し、送信ノード１１０が受信ノードからのステータスレポートを求めていることを示すビットを含み得る。ＲＬＣ ＰＤＵは、データＰＤＵのシーケンス番号を示す“シーケンス番号”フィールドをさらに含み得る；このシーケンス番号は、新たなデータＰＤＵごとに加算され得る。最後に、データフィールドは、上位レベルのデータ情報のセグメントを含む。“長さ標識（Length Indicator）”及び拡張“Ｅ”フィールドもまたＲＬＣ ＰＤＵ内に含まれてもよい。
【００２１】
ポーリングビットＰが“１”に設定されたＰＤＵに応じて、受信ノードのＲＬＣ層は、ＲＬＣ ＰＤＵが正しく受信されたことを示すステータスレポートを生成し得る。肯定的な若しくは否定的な確認応答、又は双方の組み合わせが用いられ得る。ＬＴＥにおいて、ステータスレポートＰＤＵは、受信ノードにより受信されず欠落も検出されなかったＰＤＵのうちの最小のシーケンスを示す確認応答シーケンス番号（ＡＣＫ＿ＳＮ）フィールドを含む。このステータスレポートＰＤＵは、さらに、受信ノードにより欠落が検出されたＰＤＵを識別する１つ以上の否定応答シーケンス番号（ＮＡＣＫ＿ＳＮ）を含み得る。よって、送信ノード１１０がステータスレポートＰＤＵを受信すると、ＡＣＫ＿ＳＮに対応するＰＤＵまでの（それ自体は含まず）全てのＰＤＵが、１つ以上のＮＡＣＫ＿ＳＮフィールドにより識別されるＰＤＵを除いて、受信されたと判定される。
【００２２】
上で簡単に触れたように、いくつかのシステムにおけるリソースの動的スケジューリングは、ここで議論されるポーリングＰＤＵ又はステータスレポートＰＤＵなどのエラー制御メッセージの生成とそれらメッセージの実際の送信との間の遅延を生じさせ得る。３ＧＰＰ 広帯域ＣＤＭＡシステムなどのように送信リソースが永続的に利用可能であるシステムにおいて、ＲＬＣ制御メッセージ（例えばステータスレポートＰＤＵ又はポーリングＰＤＵ）が生成されると、典型的には、短い処理遅延を除いてそれらは即座に送信される。よって、例えば、ステータスレポートが送信される場合、それは一般的には受信機の状態の正確な“スナップショット”を表す。ＬＴＥにおいては、対照的に、アップリンクは厳密にスケジューリングされ、移動局は典型的にはいかなる永続的なリソースも有しない。移動局がスケジューリングされなければ、移動局のＭＡＣ層は、ステータスレポートＰＤＵが送信可能となるよりも前に、まず、アップリンクリソースを要求しなければならない。それにより生じる遅延は、ステータスレポートＰＤＵが実際にｅＮｏｄｅＢに送信されるよりも前に、それを陳腐（outdated）にし得る。
【００２３】
この問題は図３に示されており、ｅＮｏｄｅＢにおけるイベントが上の水平線に沿って示され、移動局におけるイベントが下の水平線に沿って示されている。図３のイベントフローは、図中左に描かれているように、ｅＮｏｄｅＢから移動局へのポーリング要求の送信によって開始する。上で議論したように、従来型のシステムにおいては、移動局は（処理遅延を除いて）即座にステータスレポートを生成する。ＬＴＥシステムにおいては、上で議論したように、このステータスレポートは、１つ以上の確認モードＰＤＵ（若しくはそれらの一部）が欠落し、又は処理に失敗したことを示し得る。
【００２４】
ＲＬＣ層がステータスレポートを生成すると、ステータスレポートはｅＮｏｄｅＢへの配信のためにＭＡＣ層へ転送される。しかしながら、描かれたイベントフローにおいて、データを送信しようとしてもアップリンク上でリソースは即座に利用可能でない。よって、ＭＡＣ層は、スケジューリング要求を送信することにより、ｅＮｏｄｅＢからアップリンクリソースを要求する。上で議論したように、アップリンクリソースの許可は、相当な遅延を免れない。そうした遅延は、単純に、ｅＮｏｄｅＢが多数の移動局にサービスを提供しているため、あるいはｅＮｏｄｅＢがその時点でより優先度の高い要求にリソースを割り当てているために生じ得る。いくつかのケースにおいて、ｅＮｏｄｅＢによるリソース要求の受信が失敗したことにより遅延が生じ又は遅延が悪化し、その場合には要求は再送されなければならない。
【００２５】
いずれの場合にも、図３に描かれたイベントフローにおけるアップリンクリソースの許可は、最終的に、相当なスケジューリング遅延の後に移動局により受信される。この遅延の期間は、図３において、ＲＬＣの視点から、即ち、エラー制御メッセージ（ステータスレポート）がＲＬＣによりＭＡＣへ転送される瞬間からＭＡＣがアップリンクリソースの許可を受信するまでにわたって示されている。この期間の間、いくつかの追加的なＲＬＣ ＰＤＵ、即ちＰＤＵ１及びＰＤＵ２が移動局により受信される。よって、図中右に示されているように、ステータスレポートがｅＮｏｄｅＢへ送信されるまでに、ステータスレポートは既に陳腐になっている。ステータスレポートは、ＰＵＤ１及びＰＤＵ２の受信を反映していないため、ｅＮｏｄｅＢには、移動局の受信機のその時点のステータスとして不正確な情報が提供される。これにより、ＰＤＵ１及びＰＤＵ２の再送におけるダウンリンクリソースの浪費、及び潜在的にキューイング中のデータのさらなる遅延が引き起こされる。
【００２６】
スケジューリング遅延は、エラー制御プロセスに関連するタイマの動作に伴う問題をも生じさせ得る。例えば、ステータスレポートを搬送するＰＤＵがＭＡＣ層に供給された時にステータス−禁止タイマ（status-prohibit timer）などのステータスレポートの送信を制御するＲＬＣタイマが起動する場合、タイマの終了が早過ぎることが起こり得る。最悪の場合には、ＲＬＣ層がＭＡＣ層にいくつものＲＬＣステータスレポートを供給する可能性があり、その全ては送信のためにキューイングされる。これらステータスレポートが同じＲＬＣ ＰＤＵについての否定応答を含んでいれば、ピアエンティティにより何度も同じＰＤＵが再送される。
【００２７】
同じ問題がポーリングを制御するタイマにも生じ得る。ポーリングを搬送するＰＤＵがＭＡＣ層に供給された時にポーリングタイマが起動する場合、ポーリングを搬送するＰＤＵの送信の遅延を原因として、ポーリングタイマの経過が早過ぎることが起こり得る。これは、不必要なポーリングがキューイングされ受信機に送信される結果を引き起こし得る。図４のイベントフローにおいてこれが示されている。図３と同様、ｅＮｏｄｅＢにおけるイベントが上の水平線に沿って示され、移動局におけるイベントが下の水平線に沿って示されている。図中左において、ポーリング制御メッセージＰＯＬＬ１がｅＮｏｄｅＢのＲＬＣ層により生成される。ポーリング制御メッセージは移動局への送信のために即座にＭＡＣ層に転送され、他のポーリング要求が生成される前に最小の遅延を確立させるポーリングタイマが起動する。しかしながら、ＰＯＬＬ１メッセージは、実際には相当な遅延の後まで移動局に送信されず、それによりバックアップ送信キューからのスケジューリング遅延が引き起こされ得る。
【００２８】
いくつかの場合には、ポーリング要求の送信における遅延は、図４に示されているように、ポーリングタイマが失効する後まで延長され得る。ポーリングタイマが失効すると、前回のポーリングが送信されていないことに気付かないＲＬＣ層は、第２のポーリング要求ＰＯＬＬ２を生成する。この第２のポーリング要求はＭＡＣへ転送され、そしてポーリングタイマが再開される。
【００２９】
最終的に、第１のポーリング要求（ＰＯＬＬ１）が移動局に送信される。図示されたシナリオでは、アップリンク遅延は大幅ではなく、ステータスレポートは迅速に返答される。まもなく、第２のポーリング要求（ＰＯＬＬ２がｅＮｏｄｅＢにより送信され、移動局により受信される。ステータス−禁止タイマは移動局による他のステータスレポートの生成及び送信を禁止しているが、第２のポーリング要求は明らかに不要であり、システムリソースの浪費である。
【００３０】
図３及び４は、スケジューリングされるリソースを伴う無線システムにおけるスケジューリング及びキューイング遅延から生じ得るＲＬＣエラー制御のタイミングの問題のいくつかのみを示している。他の問題は、より優先度の高いデータが既にキューイングされていることによりステータスレポート又はポーリングが遅延し得ることである。優先度の異なる複数のベアラ又は“論理チャネル”を伴う移動端末（ダウンリンクの観点での受信ノード、アップリンクの観点での送信ノード）を考えてみて欲しい。その移動端末が最高の優先度のベアラについての送信バッファにデータを有しており、またｅＮｏｄｅＢからスケジューリングの許可を受信し、低優先度のベアラと関連付けられるＰＤＵの送信のためには帯域が残されていないことを想定する。さらに、低優先度のベアラ上でのステータスレポート又はポーリング要求を送信するためのトリガが発生したと想定する。当該移動端末は、そのＰＤＵを送信するためのリソースを有しないため、ステータスレポート又はポーリングは、大幅に遅延する。上で議論したシナリオのように、このステータスレポートはいくつかの場合にはそれが送信される前に陳腐になる。極端な場合には、低優先度のベアラのリソースが利用可能となるまでにいくつものステータスレポート又はポーリングがキューイングされ、不必要な再送が引き起こされる。
【００３１】
上述した問題のいくつかへの解決策は、上で説明した従来型のＡＲＱプロセスを、エラー制御メッセージ（例えば、ＡＲＱ制御情報を搬送するＲＬＣ ＰＤＵ）の内容をＲＬＣ ＰＤＵの送信のためのリソースが供給され得るときにおいてのみ生成する、というように修正することである。いくつかの実施形態において、これは、ＲＬＣ層とＭＡＣ層との間の追加的な又は修正されたインタフェースを提供することにより達成され得る。この追加的なインタフェースは、ＲＬＣ層が制御情報を搬送するＲＬＣ ＰＤＵを送信することをＭＡＣ層に要求することを可能にする。加えて、この追加的なインタフェースは、制御情報を搬送するＲＬＣ ＰＤＵ層の送信のためにリンクリソースが利用可能であるときに、ＭＡＣ層がＲＬＣ層に通知をすることを可能とする。この手法により、ＲＬＣ層は、リソースまで制御情報の生成を実質的に遅らせることができ、それにより最終的に配信されるエラー制御情報がＲＬＣ層の状態の最新化された情報を含むことになる。
【００３２】
このインタフェース上で、通信ノード（例えば移動局）のＲＬＣ層は、まず、例えばステータスレポートなどのＲＬＣ ＡＲＱ制御メッセージの送信についての必要性をＭＡＣ層に報告し得る。ＭＡＣ層からＲＬＣ層への必要とされたリソースが利用可能である（又はすぐに利用可能となる）ことの通知の後、ＲＬＣ層は、関連する制御情報（例えばステータスレポート情報）を生成し、制御情報をＲＬＣ ＰＤＵにパッケージングし、及びリモートノードへの送信のために当該ＲＬＣ ＰＤＵをＭＡＣ層へ提出する。本発明の実施形態は、ＲＬＣ ＰＤＵがＲＬＣステータスレポート又はポーリングのいずれかを搬送するケースを包含するが、他のエラー制御メッセージにも同様に適用され得る。
【００３３】
図５は、図３及び４と同様のイベントフロー図を表しており、本発明のいくつかの実施形態に係るシステムの動作を示している。図３におけるケースのように、図中左で、ポーリング要求がｅＮｏｄｅＢにより送信され、移動局により受信される。このトリガに応じて、移動局のＲＬＣ層は、この場合はステータスレポートであるエラー制御メッセージの送信のために、アップリンクリソースが必要とされるであろうことを判定する。そこで、図５に示されているように、ＲＬＣ層は、アップリンクリソースが必要とされることをＭＡＣ層にシグナリングする。ＭＡＣ層は、リソースが未だスケジューリングされていなければ、スケジューラからのアップリンクリソースを要求することによりそれに応じる。
【００３４】
いわゆる当業者は、アップリンクリソースが必要とされることのＲＬＣ層からＭＡＣ層へのシグナリングが、エラー制御メッセージの送信のために当該リソースが要求されていることを特に示しても示さなくてもよいことを理解するであろう。よって、いくつかの実施形態では、当該シグナリングは、単純に、ＲＬＣ ＰＤＵが保留されていること、及びアップリンクリソースが未だ利用可能でなければスケジューリングされるべきことを示し得る。他の実施形態において、リソースが制御メッセージのために必要とされていることを特別に示すシグナリングが有益であり得る。
【００３５】
いかなるイベントにおいても、実質的なリソースの許可は、図５に示されているように、大幅な遅延の後にのみ得られる。この遅延の間、複数の確認モードのＲＬＣ ＰＤＵであるＰＤＵ３及びＰＤＵ４が、スケジューリング遅延の間の移動局において受信される。しかしながら、このシナリオでは、ステータスレポートは、生成されておらず、送信待ちとしてＭＡＣ層の中でキューイングもされていない。その代わりに、図５において、ＲＣＬ層は、アップリンクリソース要求が許可されたこと（即ち、アップリンクリソースが利用可能であること）がＭＡＣ層からＲＬＣへ通知された後まで、ステータスレポートデータの生成を遅れさせる。よって、ステータスレポートは、それがＭＡＣ層に転送されｅＮｏｄｅＢへ送信される時には、（ＰＤＵ３及びＰＤＵ４のステータスを含む）その時点のデータを有する。それでも処理及びキューイングの遅延は存在するものの、これら遅延は図３に描かれた状況と比較して極小である。
【００３６】
本発明のいくつかの実施形態は、上で議論したＲＬＣ ＡＲＱポーリング及びステータス−禁止タイマなどのエラー制御処理のためのタイマの起動と再開について同様の技術を利用する。これら実施形態において、エラー制御タイマのアクティブ化は、エラー制御情報を搬送するＲＬＣ ＰＤＵがリモートノードへ送信されたこと、又はまもなく送信されるであろうということのＭＡＣ層による（ＲＬＣ層への）通知によりトリガされ得る。
【００３７】
図６において、そうした一実施形態についての一例としての動作が描かれている。図４において描かれたイベントフローにおけるケースのように、このイベントフローでは、ｅＮｏｄｅＢにおいてポーリング要求がトリガされる。ポーリング要求を搬送するＲＬＣ ＰＤＵは、移動局への送信のためにＭＡＣへ転送される。しかし、この場合、ポーリングタイマは即座には起動しない。その代わり、ポーリングタイマは、ポーリング要求が送信されたことがＭＡＣ層によりＲＬＣ層に通知された後まで起動しない。図６に描かれているように、それは、大幅なスケジューリング／キューイング遅延の後に起こり得る。ポーリング要求が実際に送信された時又はその前後までポーリングタイマの起動は遅らせられたため、タイマは、移動局からのステータスレポートの受信よりも前に失効しない。よって、ポーリング要求の不必要な再送信は回避される。
【００３８】
いくつかの実施形態において、ＭＡＣ層は、ＲＬＣ ＡＲＱ制御情報を搬送するＰＤＵの送信が開始され、又はまもなく開始されることをＲＬＣ層に通知するよう構成されてもよい。他の実施形態において、その代わりに、ＭＡＣ層は、ＲＬＣ ＡＲＱ制御情報を搬送するＰＤＵの送信に対してＭＡＣ ＨＡＲＱ層上で確認応答がなされたことをＲＬＣ層に通知してもよい。いわゆる当業者は、ポーリングタイマの観点での上述した技術が、例えばステータス−禁止タイマなどの他のエラー制御タイマにも適用され得ることを理解するであろう。
【００３９】
図７は、例えば上述した１つ以上のＲＬＣ及びＭＡＣコントローラなどにより実行され得る、エラー制御メッセージの処理のための一例としての方法を示す論理フロー図である。図示された方法において、ここで開示される発明についての技術は、エラー制御メッセージの生成及びエラー制御タイマのアクティブ化の双方に適用される。いわゆる当業者は、当然ながら、本発明の多くの実施形態が双方のエラー制御処理に適用され得るものであり、一方でいくつかは双方ではなくいずれかにのみ適用され得ることを理解するであろう。
【００４０】
いかなるイベントにおいても、図７の一例としての方法は、ブロック７１０において、エラー制御メッセージの送信のためにリンクリソースが必要であることの通信ノードにおけるＭＡＣコントローラへのシグナリングにより始まる。上で議論したように、これは、いくつもの異なるイベントのいずれかによってトリガされ得る。例えば、受信ノードにおけるポーリング要求の受信は、一般的に、ステータスレポート処理をトリガするであろう。すると、この場合、ブロック７１０におけるリンクリソースについてのシグナリングは、ステータスレポートを送信するためのリソースについてのものである。可能性のある他のトリガイベントは、エラー制御タイマの失効である。例えば、ポーリングタイマの失効は、新たなポーリング要求をトリガし得るものであり、その場合、ブロック７１０におけるシグナリングは、新たなポーリング要求をトリガするためのリソースを要求するものとなるであろう。
【００４１】
いかなるイベントにおいても、ブロック７２０において、リンクリソースが利用可能であるという標識がＭＡＣコントローラから受信される。上で詳細に議論したように、これは、リソースについての要求の後に即座に生じ、又は大幅なスケジューリング遅延の後に生じ得る。いずれのケースでも、リンクリソースが利用可能であるという標識に応じて、ブロック７３０においてエラー制御メッセージが生成される。よって、その時点のステータスに基づいてエラー制御メッセージの内容が生成され、その内容はいかなるスケジューリング遅延によっても“陳腐（stale）”にはならない。ブロック７４０において、エラー制御メッセージは送信のためにＭＡＣコントローラへ転送される。ブロック７３０のメッセージ生成及びブロック７４０のメッセージ転送はリソースが利用可能となった後まで遅らせられたため、ＭＡＣコントローラへの転送後の送信遅延は極小化される。
【００４２】
ブロック７５０において、エラー制御メッセージの送信が開始し又は完了したことの通知がＭＡＣコントローラから受信される。この通知に応じて、ブロック７６０に示されているように、例えばポーリングタイマまたはステータス−禁止タイマなどの適切なエラー制御タイマがアクティブ化される。
【００４３】
ここで説明されるＲＬＣ及びＭＡＣ手続は、上述したプロトコルスタック２１０及び２２０のＲＬＣ及びＭＡＣ層をそれぞれ実装するＲＬＣコントローラ及びＭＡＣコントローラによりそれぞれ実装され得る。いわゆる当業者は、これら手続が、従来のＲＬＣコントローラ及びＭＡＣコントローラを修正することにより実装されてもよく、上述したように１つ以上のプログラム可能なプロセッサ、ハードウェア回路又はそれらの組み合わせにより実装されてもよいことを理解するであろう。
【００４４】
さらに、ここで開示される方法は、上述したＬＴＥ移動局又はｅＮｏｄｅＢなどのような無線リンクのいずれか又は双方の端部において実装され得る。よって、図８は、本発明の１つ以上の実施形態に係る無線通信装置の一般的な特徴を示しており；図示された無線装置８００は、様々な実施形態において、移動端末（セルラー電話、無線ＰＤＡ（personal digital assistant）、無線ＰＣ（personal computer）、マシン間（machine-to-machine）デバイスなど）、基地局、リピータ又は無線リンクを終端する他のノードを含み得る。
【００４５】
図８の無線装置８００は、リモート送受信機との間で１つ以上の無線リンク上でアンテナ８１５を介して通信するように動作可能な無線送受信機８１０を有する。いくつかの実施形態において、無線送受信機８１０は、例えば３ＧＰＰにより公表された無線標準のいずれかなどの標準に従ってフォーマットされた信号を送受信するように構成される。例えば、無線送受信機８１０は、ＬＴＥ標準に従って、ＯＦＤＭＡ及びＳＣ−ＦＤＭＡ信号を送信し及び／又は受信するよう構成されてもよい。
【００４６】
無線装置８００は、さらに、メディアアクセス制御機能８２０、無線リンク制御機能８３０、及び他の処理８４０を有する。ＭＡＣ及びＲＬＣ機能の一般的機能は上で議論されており；これら機能は、アナログ及びデジタルハードウェア並びにソフトウェアと共に構成されるプログラム可能なプロセッサの様々な組み合わせのいずれかの上に実装され得る。いわゆる当業者は、無線装置８００の動作のために必要なこれら機能及び他の機能が、１つ又は複数のプログラム可能なプロセッサを用いて実装され得ることを理解するであろう。多くの実施形態において、ＭＡＣ８２０及びＲＬＣ８３０機能は、ここで説明した様々なＲＬＣ及びＭＡＣ機能を実行するソフトウェアと共に構成される単一のマイクロプロセッサ又は特定目的集積回路上に実装される、例えば図２のプロトコルスタック２１０などのプロトコルスタックとして実装される。
【００４７】
例えば、ＲＬＣコントローラ８３０は、ＲＬＣ層を定義するソフトウェアを伴ってプログラムされるマイクロプロセッサと共に実装されることができ、ＲＬＣ層は、データの送信のためにリンクリソースが必要であることをメディアアクセスコントローラにシグナリングし、当該データの送信のためのリンクリソースがスケジューリングされたことの標識をメディアアクセスコントローラから受信し、及び、当該標識に応じて現在のＲＬＣ層についてのエラー制御ステータスに基づいてエラー制御メッセージを生成するように構成される。限定ではないが、エラー制御メッセージは、ポーリング要求又はステータスレポートを含んでよい。いくつかの実施形態において、ＲＬＣ層は、エラー制御メッセージの送信が開始したことの通知を受信し、当該通知に応じてエラー制御タイマを起動するようにさらに構成されてもよい。限定ではないが、エラー制御タイマは、ポーリングタイマ又はステータス−禁止タイマを含み得る。
【００４８】
同様に、ＭＡＣコントローラ８２０の全部又は一部は、ＭＡＣ層を定義するソフトウェアを伴ってプログラムされる同じマイクロプロセッサ上で、又は１つ以上の他のマイクロプロセッサ上で実装されてよい。ＭＡＣ層は、データの送信のためにリンクリソースが必要であることを示す信号をＲＬＣ層から受信し、必要に応じてリンクリソースを要求するように構成される。ＭＡＣ層は、リソースの許可の受信後にＲＬＣ層に通知をするようにさらに構成される。いくつかの構成において、ＭＡＣ層は、（ＲＬＣ層によりＭＡＣ層に提供される）エラー制御メッセージが送信されたときに、又はいくつかの実施形態においてエラー制御の送信が間近に迫ったときに、ＲＬＣ層に通知をするようにさらに構成される。
【００４９】
当然ながら、本開示による内容は、本発明の本質的な特徴から離れることなく、ここで特に例示されたものとは別の手法で実行されてもよい。本実施形態は、あらゆる観点において、限定ではなく説明のためのものとしてみなされ、添付の特許請求の範囲の意味及び均等の範囲内での全ての変更は、ここに含まれることが意図される。
【技術分野】
【０００１】
本発明は、一般に、無線通信システムに関し、より具体的には、リンクリソースをスケジューリングする無線通信システムにおけるエラー制御メッセージの処理に関する。
【背景技術】
【０００２】
３ＧＰＰ（The Third-Generation Partnership Project）は、“Long Term Evolution”あるいはＬＴＥとして知られるイニシアティブの下、高度化された無線通信システムの標準を開発するプログラムを立ち上げた。標準化の議論において、ＬＴＥシステムが無線リンク制御（ＲＬＣ）プロトコルにおいて自動再送要求（ＡＲＱ：automatic repeat request）の仕組みを利用することが合意されている。その仕様化されたＡＲＱプロトコルは（“ＲＬＣ確認モード（RLC Acknowledged Mode）”において使用される）選択的再送プロトコル（selective repeat protocol）であり、それにより受信ノードから送信ノードへステータスレポートを送信する手段と共に、送信ノードがステータスについて受信ノードにポーリングする（poll）ための手段が提供される。ステータスレポートの受信に応じて、送信ノードは、失われたいずれかのデータを再送してもよく、又は適切な他のアクションをとってもよい。ポーリングに応じて、一般的に、受信機は、ステータスレポートを送信する。しかしながら、ステータスレポートの送信は、ある状況下では禁止され得る。例えば、前回のステータスレポートの送信時に開始されるステータス−禁止タイマは、ある期間についてステータスレポートを遮断し得る。
【０００３】
また、３ＧＰＰの開発者らは、ポーリング及びステータストリガのセットと共に、ポーリング又はステータスレポートのいずれかに対するノードの応答を規制するタイマを仕様化することに合意した。３ＧＰＰ ＬＴＥ標準に含めるように近日合意されたトリガ及びタイマの例は、以下を含む：
・欠損したプロトコルデータユニット（ＰＤＵ）の検出時の自動ステータスレポート；
・送信バッファ内の最後のＰＤＵの送信に応じた自動的なポーリング、それによりデータのバーストが完全に受信されたことの確証が送信ノードに提供される；
・ノードによる過度に高い頻度でのステータスレポートの送信を防止するためのステータス−禁止タイマ、これは過度に高い頻度でのステータスレポートが不必要な再送を生じさせるからである；
・返答されなかった欠損したであろうポーリングが再送されることを保証するためのポーリング−再送タイマ
【０００４】
当然ながら、追加的なトリガ及びタイマもまた、ＬＴＥにおいて採用される可能性がある。ＬＴＥのためのＲＬＣ ＡＲＱプロトコルは、究極的には、３ＧＰＰ ＴＳ２５．３２２において仕様化された広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）のＲＬＣプロトコルと多くの類似性を有するであろうことを予期することができる。確認モード（Acknowledged Mode）に加えて、ＬＴＥのためのＲＬＣプロトコルは、非確認モードと共に透過モードをも含むであろう。
【０００５】
従来型のＲＬＣ ＡＲＱスキームにおいて、ＲＬＣタイマ及びステータスレポートは、あるトリガに応じて生成される。例えば、受信ノードがポーリングを受信し、ステータス禁止タイマが稼動していない場合には、受信ノードは、現在の受信機のステータスを表すステータスレポートを即座に生成する。典型的なステータスレポートは、最後に受信されたプロトコルデータユニット（ＰＤＵ）についての識別子及び／又は受信が成功しなかった１つ以上のＰＤＵについての否定応答を含み得る。そして、ステータスレポートはメディアアクセス制御（ＭＡＣ）層に送信ノードへの送信のために提供される。（いわゆる当業者は、各無線通信ノードが典型的には送信機と受信機とを含むことを理解するであろう。さらに、ＡＲＱスキームは、双方向に実装されてもよい。本開示の目的のために、“送信ノード”という用語は、確認モードにおいて“受信ノード”に１つ以上のデータＰＤＵを送信するノードを一般的に指す。３ＧＰＰの専門用語において、確認モードデータは、“確認モードのＲＬＣエンティティの送信側”から送信され；当該ＰＤＵは“ピアエンティティ”あるいは確認モードのＲＬＣエンティティの“受信側”へ伝送される。このような用法を前提として、受信ノードは、送信ノードにステータスＰＤＵを送信し得る。同様に、送信ノードはステータスＰＤＵを受信し得る。）
【０００６】
ステータス−禁止タイマを活用するシステムにおいて、受信ノードは、典型的には、ステータスレポートがＲＬＣ層からＭＡＣ層へ転送された時点でステータス−禁止タイマを起動する。すると、タイマが終了するまでは、その間にステータスレポートについての１つ以上の新たなトリガが発生した場合でも、さらなるステータスレポートは許可されない。そうしたトリガは、送信ノードから受信される他のポーリング、又は欠損したＰＤＵの検出などであり得る。よって、ステータス禁止時間は、後に続くステータスレポートが少なくともステータス−禁止タイマにより特定される期間だけ遅らせられることを保証する。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＬＴＥシステムにおいて、（移動体基地局の伝送についての）アップリンクは、スケジューリング対象のリソースであり、スケジューリングはサービング基地局（ＬＴＥにおいて、進化したノードＢあるいはｅＮｏｄｅＢと呼ばれる）により制御される。結果として、所与の瞬間において、移動局は即座には送信リソースへのアクセスを有しないであろう。アップリンクリソースがスケジューリングされていない時点で移動局におけるＭＡＣ層がＲＬＣ層からステータスレポートを受信すると、移動局はｅＮｏｄｅＢにステータスレポートを送信し得る前に、まずそのリソースを要求しなければならない。ｅＮｏｄｅＢによりスケジューリングが制御されているために、アップリンクリソースの許可が大きく遅れる場合もある。例えば、マルチユーザスケジューリングはリソースの割り当てを遅らせる可能性があり、あるいは初期スケジューリング要求は送信に際して欠損する可能性もある。結果として、ステータスレポートの送信は、ステータスレポートにより記述される受信機の状態がその送信前でさえ陳腐となるような程度にまで、遅延され得る。
【課題を解決するための手段】
【０００８】
ここに開示するのは、ＲＬＣ ＡＲＱ制御メッセージなどのエラー制御メッセージを処理するための方法及び装置である。一例としての方法は、データを送信するためにリンクリソースが必要であることをメディアアクセスコントローラ（ＭＡＣ）へシグナリングすることと、データを送信するためのリンクリソースがスケジューリングされていることを示す標識をＭＡＣから受信することと、上記標識の受信後に、現在のエラー制御ステータスに基づいてエラー制御メッセージを生成することと、を含む。そして、エラー制御メッセージは、送信のためにＭＡＣへ転送される。エラー制御メッセージの生成はその送信がスケジューリングされるまで遅らせられるため、キューイング及び陳腐化した（stale）制御メッセージの送信は回避される。
【０００９】
本発明の他の観点において、ＲＬＣ ＡＲＱ制御メッセージの送信が開始され又は確認応答された場合に、ＭＡＣは、無線リンクコントローラ（ＲＬＣ）に通知をしてもよい。その通知に応じて、ＲＬＣコントローラは、エラー制御タイマを起動し又は再開し得る。当該タイマは、例えば、ポーリングタイマ又はステータス禁止タイマを含む。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態に係る通信システムの単純化された図である。
【図２】図１のシステムにおいて活用され得るいくつかの通信プロトコルの階層を示している。
【図３】ＡＲＱステータスレポートの形成についてのスケジューリングの遅延の影響を示している。
【図４】ＡＲＱポーリングタイマについてのスケジューリングの遅延の影響を示している。
【図５】一実施形態に係るＡＲＱステータスレポートの生成のタイミングを示している。
【図６】本発明の一実施形態に係るポーリングタイマ処理を示している。
【図７】エラー制御メッセージを処理する一例としての方法を示す論理フロー図である。
【図８】本発明の１つ以上の実施形態に係る無線装置のブロック図である。
【発明を実施するための形態】
【００１１】
図１は、通信システム１０の単純化された図であり、通信システム１０は、送信ノード１１０及び受信ノード１２０を含む。上で議論したように、送信ノード１１０及び受信ノード１２０の各々は、完全な送受信機を備え；“送信”及び“受信”という用語は、確認応答がなされるデータ伝送における特定のエンドポイントを説明するために使用される。よって、送信ノード１１０はプロトコルデータユニット（ＰＤＵ）を含む１つ以上のデータユニットを受信ノード１２０へ送信し、また、ポーリング要求などの１つ以上のエラー制御メッセージを送信する。（以下で議論するように、ポーリングなどのエラー制御メッセージは、トラフィックデータとしての同じプロトコルデータユニットに含まれてもよい。）そして、受信ノード１２０は、ステータスレポートなどの１つ以上のエラー制御メッセージを送信し、又は受信に失敗したＰＤＵの再送を要求し得る。
【００１２】
本発明のいくつかの実施形態において、送信ノード１１０はＬＴＥｅＮｏｄｅＢにより構成され、受信ノード１２０はＬＴＥに準拠した移動局により構成されてもよい。その場合、図１に描かれたデータユニットはダウンリンク上でｅＮｏｄｅＢにより送信され、１つ以上のエラー制御メッセージはアップリンク上で送信される。しかしながら、いわゆる当業者は、逆方向においても、アップリンク上でのＰＤＵの伝達におけるエラーの検出のためにＡＲＱスキームが実装され得ることを理解するであろう。その場合、送信及び受信ノードの役割は、ｅＮｏｄｅＢと移動局との間で逆になる。
【００１３】
ここで開示される本発明としての技術は、ＬＴＥシステムについて言及しながら説明されるが、本発明はそうしたシステムに限定されるものではない。実際、以下の説明を読み添付図面を見た技術知識を有する実施者は、多様な無線システムに、特にアップリンク若しくはダウンリンク又はその双方において送信リソースを動的にスケジューリングするシステムに、ここで説明される技術が適用され得ることを理解するであろう。
【００１４】
図１の通信ノードの各々は、３ＧＰＰにより仕様化されたＬＴＥプロトコルなどの特定の通信プロトコルに従って動作するように構成される。図２には、いくつかのプロトコル階層が示されており；これらプロトコル階層は、通信ノードの各々において、アナログ及びデジタルハードウェア、適切なソフトウェアと共に構成されるプログラム可能なプロセッサ、又はそれらの組み合わせを用いて実装され得る。特に、ＬＴＥ移動局であり得る送信ノード１１０は、例えばＬＴＥｅＮｏｄｅＢである受信ノード１２０のプロトコルスタック２２０における対応するプロトコル階層と通信するプロトコルスタック２１０内のプロトコル階層を使用し得る。
【００１５】
プロトコルスタック２１０及び２２０の各々は、物理層、データリンク層、及びネットワーク層を含む。データリンク層は、無線リンク制御（ＲＬＣ）層及びメディアアクセス制御（ＭＡＣ）層という２つの副階層に分けられる。一例としての本実施形態において、ネットワーク層は、制御プレーンプロトコル（ＲＲＣ）及びユーザプレーンプロトコル（ＩＰ）に分割される。
【００１６】
ＬＴＥシステムにおいて、物理層は、ダウンリンクについては直交周波数分割多重アクセス（ＯＦＤＭＡ）技術、アップリンクについては密接に関連するシングルキャリア周波数分割多重アクセス（ＳＣ−ＦＤＭＡ）を使用する。一般に、物理層は、エア（無線）インタフェース上でのデータ伝送を提供し、トランスポートチャネルの多重化及び逆多重化、トランスポートチャネルの物理チャネル上へのマッピング、物理チャネルの変調及び復調、順方向誤り訂正符号化及び復号、周波数及び時間同期、送信電力制御、並びにＲＦ処理などの機能を備える。
【００１７】
メディアアクセス制御（ＭＡＣ）層は、一般的に、ピアＭＡＣエンティティ間のサービスデータユニット（ＳＤＵ）の非確認の（unacknowledged）伝送を提供する。ＭＡＣ機能は、各トランスポートチャネルについてのデータレートに依存する適切なトランスポートフォーマットの選択、（複数のユーザをサポートする基地局における）様々なユーザのデータフロー間の優先度の取り扱い、制御メッセージのスケジューリング、並びに上位層のＰＤＵの多重化及び逆多重化などを含み得る。ＬＴＥシステムにおいて、リソースのスケジューリングは、ＭＡＣ層によっても実行される。特に、アップリンクリソースは、移動局についてのＭＡＣ層により要求されることができ、ｅＮｏｄｅＢ内の対応するＭＡＣ層により移動局の間で割り当てられる。
【００１８】
ＲＬＣ層は、ＲＬＣ接続の確立、解放及び維持、可変長の上位層のＰＤＵのより小さいＲＬＣ ＰＤＵとの間のセグメント化及び再結合、連結、再送信（ＡＲＱ）による誤り訂正、上位層のＰＤＵのシーケンス内配信（in-sequence delivery）、重複検出、フロー制御、並びに他の機能を含む様々な機能を実行する。
【００１９】
ＲＲＣプロトコルは、例えば無線アクセスベアラの制御シグナリング、メジャメントレポート、及びハンドオーバシグナリングなどの無線インタフェース上の制御シグナリングを扱う。ネットワーク層のユーザプレーン部分は、周知のインターネットプロトコル（ＩＰ）などのレイヤ３プロトコルにより実行される従来型の機能を含む。
【００２０】
プロトコルスタック２１０及び２２０内の無線リンク制御（ＲＬＣ）プロトコル階層は、自動再送要求（ＡＲＱ）の仕組みを含む。送信ノード１１０内のＲＬＣ層は、ユーザデータを受信し、セグメント化し、ＲＬＣ ＰＤＵに変換する。いくつかの実施形態において、送信されたＲＬＣ ＰＤＵは、送信されたメッセージがデータＰＤＵなのか制御ＰＤＵなのかを示すフィールドを含み得る。他のあるフィールドは、ポーリングフィールドに相当し、送信ノード１１０が受信ノードからのステータスレポートを求めていることを示すビットを含み得る。ＲＬＣ ＰＤＵは、データＰＤＵのシーケンス番号を示す“シーケンス番号”フィールドをさらに含み得る；このシーケンス番号は、新たなデータＰＤＵごとに加算され得る。最後に、データフィールドは、上位レベルのデータ情報のセグメントを含む。“長さ標識（Length Indicator）”及び拡張“Ｅ”フィールドもまたＲＬＣ ＰＤＵ内に含まれてもよい。
【００２１】
ポーリングビットＰが“１”に設定されたＰＤＵに応じて、受信ノードのＲＬＣ層は、ＲＬＣ ＰＤＵが正しく受信されたことを示すステータスレポートを生成し得る。肯定的な若しくは否定的な確認応答、又は双方の組み合わせが用いられ得る。ＬＴＥにおいて、ステータスレポートＰＤＵは、受信ノードにより受信されず欠落も検出されなかったＰＤＵのうちの最小のシーケンスを示す確認応答シーケンス番号（ＡＣＫ＿ＳＮ）フィールドを含む。このステータスレポートＰＤＵは、さらに、受信ノードにより欠落が検出されたＰＤＵを識別する１つ以上の否定応答シーケンス番号（ＮＡＣＫ＿ＳＮ）を含み得る。よって、送信ノード１１０がステータスレポートＰＤＵを受信すると、ＡＣＫ＿ＳＮに対応するＰＤＵまでの（それ自体は含まず）全てのＰＤＵが、１つ以上のＮＡＣＫ＿ＳＮフィールドにより識別されるＰＤＵを除いて、受信されたと判定される。
【００２２】
上で簡単に触れたように、いくつかのシステムにおけるリソースの動的スケジューリングは、ここで議論されるポーリングＰＤＵ又はステータスレポートＰＤＵなどのエラー制御メッセージの生成とそれらメッセージの実際の送信との間の遅延を生じさせ得る。３ＧＰＰ 広帯域ＣＤＭＡシステムなどのように送信リソースが永続的に利用可能であるシステムにおいて、ＲＬＣ制御メッセージ（例えばステータスレポートＰＤＵ又はポーリングＰＤＵ）が生成されると、典型的には、短い処理遅延を除いてそれらは即座に送信される。よって、例えば、ステータスレポートが送信される場合、それは一般的には受信機の状態の正確な“スナップショット”を表す。ＬＴＥにおいては、対照的に、アップリンクは厳密にスケジューリングされ、移動局は典型的にはいかなる永続的なリソースも有しない。移動局がスケジューリングされなければ、移動局のＭＡＣ層は、ステータスレポートＰＤＵが送信可能となるよりも前に、まず、アップリンクリソースを要求しなければならない。それにより生じる遅延は、ステータスレポートＰＤＵが実際にｅＮｏｄｅＢに送信されるよりも前に、それを陳腐（outdated）にし得る。
【００２３】
この問題は図３に示されており、ｅＮｏｄｅＢにおけるイベントが上の水平線に沿って示され、移動局におけるイベントが下の水平線に沿って示されている。図３のイベントフローは、図中左に描かれているように、ｅＮｏｄｅＢから移動局へのポーリング要求の送信によって開始する。上で議論したように、従来型のシステムにおいては、移動局は（処理遅延を除いて）即座にステータスレポートを生成する。ＬＴＥシステムにおいては、上で議論したように、このステータスレポートは、１つ以上の確認モードＰＤＵ（若しくはそれらの一部）が欠落し、又は処理に失敗したことを示し得る。
【００２４】
ＲＬＣ層がステータスレポートを生成すると、ステータスレポートはｅＮｏｄｅＢへの配信のためにＭＡＣ層へ転送される。しかしながら、描かれたイベントフローにおいて、データを送信しようとしてもアップリンク上でリソースは即座に利用可能でない。よって、ＭＡＣ層は、スケジューリング要求を送信することにより、ｅＮｏｄｅＢからアップリンクリソースを要求する。上で議論したように、アップリンクリソースの許可は、相当な遅延を免れない。そうした遅延は、単純に、ｅＮｏｄｅＢが多数の移動局にサービスを提供しているため、あるいはｅＮｏｄｅＢがその時点でより優先度の高い要求にリソースを割り当てているために生じ得る。いくつかのケースにおいて、ｅＮｏｄｅＢによるリソース要求の受信が失敗したことにより遅延が生じ又は遅延が悪化し、その場合には要求は再送されなければならない。
【００２５】
いずれの場合にも、図３に描かれたイベントフローにおけるアップリンクリソースの許可は、最終的に、相当なスケジューリング遅延の後に移動局により受信される。この遅延の期間は、図３において、ＲＬＣの視点から、即ち、エラー制御メッセージ（ステータスレポート）がＲＬＣによりＭＡＣへ転送される瞬間からＭＡＣがアップリンクリソースの許可を受信するまでにわたって示されている。この期間の間、いくつかの追加的なＲＬＣ ＰＤＵ、即ちＰＤＵ１及びＰＤＵ２が移動局により受信される。よって、図中右に示されているように、ステータスレポートがｅＮｏｄｅＢへ送信されるまでに、ステータスレポートは既に陳腐になっている。ステータスレポートは、ＰＵＤ１及びＰＤＵ２の受信を反映していないため、ｅＮｏｄｅＢには、移動局の受信機のその時点のステータスとして不正確な情報が提供される。これにより、ＰＤＵ１及びＰＤＵ２の再送におけるダウンリンクリソースの浪費、及び潜在的にキューイング中のデータのさらなる遅延が引き起こされる。
【００２６】
スケジューリング遅延は、エラー制御プロセスに関連するタイマの動作に伴う問題をも生じさせ得る。例えば、ステータスレポートを搬送するＰＤＵがＭＡＣ層に供給された時にステータス−禁止タイマ（status-prohibit timer）などのステータスレポートの送信を制御するＲＬＣタイマが起動する場合、タイマの終了が早過ぎることが起こり得る。最悪の場合には、ＲＬＣ層がＭＡＣ層にいくつものＲＬＣステータスレポートを供給する可能性があり、その全ては送信のためにキューイングされる。これらステータスレポートが同じＲＬＣ ＰＤＵについての否定応答を含んでいれば、ピアエンティティにより何度も同じＰＤＵが再送される。
【００２７】
同じ問題がポーリングを制御するタイマにも生じ得る。ポーリングを搬送するＰＤＵがＭＡＣ層に供給された時にポーリングタイマが起動する場合、ポーリングを搬送するＰＤＵの送信の遅延を原因として、ポーリングタイマの経過が早過ぎることが起こり得る。これは、不必要なポーリングがキューイングされ受信機に送信される結果を引き起こし得る。図４のイベントフローにおいてこれが示されている。図３と同様、ｅＮｏｄｅＢにおけるイベントが上の水平線に沿って示され、移動局におけるイベントが下の水平線に沿って示されている。図中左において、ポーリング制御メッセージＰＯＬＬ１がｅＮｏｄｅＢのＲＬＣ層により生成される。ポーリング制御メッセージは移動局への送信のために即座にＭＡＣ層に転送され、他のポーリング要求が生成される前に最小の遅延を確立させるポーリングタイマが起動する。しかしながら、ＰＯＬＬ１メッセージは、実際には相当な遅延の後まで移動局に送信されず、それによりバックアップ送信キューからのスケジューリング遅延が引き起こされ得る。
【００２８】
いくつかの場合には、ポーリング要求の送信における遅延は、図４に示されているように、ポーリングタイマが失効する後まで延長され得る。ポーリングタイマが失効すると、前回のポーリングが送信されていないことに気付かないＲＬＣ層は、第２のポーリング要求ＰＯＬＬ２を生成する。この第２のポーリング要求はＭＡＣへ転送され、そしてポーリングタイマが再開される。
【００２９】
最終的に、第１のポーリング要求（ＰＯＬＬ１）が移動局に送信される。図示されたシナリオでは、アップリンク遅延は大幅ではなく、ステータスレポートは迅速に返答される。まもなく、第２のポーリング要求（ＰＯＬＬ２がｅＮｏｄｅＢにより送信され、移動局により受信される。ステータス−禁止タイマは移動局による他のステータスレポートの生成及び送信を禁止しているが、第２のポーリング要求は明らかに不要であり、システムリソースの浪費である。
【００３０】
図３及び４は、スケジューリングされるリソースを伴う無線システムにおけるスケジューリング及びキューイング遅延から生じ得るＲＬＣエラー制御のタイミングの問題のいくつかのみを示している。他の問題は、より優先度の高いデータが既にキューイングされていることによりステータスレポート又はポーリングが遅延し得ることである。優先度の異なる複数のベアラ又は“論理チャネル”を伴う移動端末（ダウンリンクの観点での受信ノード、アップリンクの観点での送信ノード）を考えてみて欲しい。その移動端末が最高の優先度のベアラについての送信バッファにデータを有しており、またｅＮｏｄｅＢからスケジューリングの許可を受信し、低優先度のベアラと関連付けられるＰＤＵの送信のためには帯域が残されていないことを想定する。さらに、低優先度のベアラ上でのステータスレポート又はポーリング要求を送信するためのトリガが発生したと想定する。当該移動端末は、そのＰＤＵを送信するためのリソースを有しないため、ステータスレポート又はポーリングは、大幅に遅延する。上で議論したシナリオのように、このステータスレポートはいくつかの場合にはそれが送信される前に陳腐になる。極端な場合には、低優先度のベアラのリソースが利用可能となるまでにいくつものステータスレポート又はポーリングがキューイングされ、不必要な再送が引き起こされる。
【００３１】
上述した問題のいくつかへの解決策は、上で説明した従来型のＡＲＱプロセスを、エラー制御メッセージ（例えば、ＡＲＱ制御情報を搬送するＲＬＣ ＰＤＵ）の内容をＲＬＣ ＰＤＵの送信のためのリソースが供給され得るときにおいてのみ生成する、というように修正することである。いくつかの実施形態において、これは、ＲＬＣ層とＭＡＣ層との間の追加的な又は修正されたインタフェースを提供することにより達成され得る。この追加的なインタフェースは、ＲＬＣ層が制御情報を搬送するＲＬＣ ＰＤＵを送信することをＭＡＣ層に要求することを可能にする。加えて、この追加的なインタフェースは、制御情報を搬送するＲＬＣ ＰＤＵ層の送信のためにリンクリソースが利用可能であるときに、ＭＡＣ層がＲＬＣ層に通知をすることを可能とする。この手法により、ＲＬＣ層は、リソースまで制御情報の生成を実質的に遅らせることができ、それにより最終的に配信されるエラー制御情報がＲＬＣ層の状態の最新化された情報を含むことになる。
【００３２】
このインタフェース上で、通信ノード（例えば移動局）のＲＬＣ層は、まず、例えばステータスレポートなどのＲＬＣ ＡＲＱ制御メッセージの送信についての必要性をＭＡＣ層に報告し得る。ＭＡＣ層からＲＬＣ層への必要とされたリソースが利用可能である（又はすぐに利用可能となる）ことの通知の後、ＲＬＣ層は、関連する制御情報（例えばステータスレポート情報）を生成し、制御情報をＲＬＣ ＰＤＵにパッケージングし、及びリモートノードへの送信のために当該ＲＬＣ ＰＤＵをＭＡＣ層へ提出する。本発明の実施形態は、ＲＬＣ ＰＤＵがＲＬＣステータスレポート又はポーリングのいずれかを搬送するケースを包含するが、他のエラー制御メッセージにも同様に適用され得る。
【００３３】
図５は、図３及び４と同様のイベントフロー図を表しており、本発明のいくつかの実施形態に係るシステムの動作を示している。図３におけるケースのように、図中左で、ポーリング要求がｅＮｏｄｅＢにより送信され、移動局により受信される。このトリガに応じて、移動局のＲＬＣ層は、この場合はステータスレポートであるエラー制御メッセージの送信のために、アップリンクリソースが必要とされるであろうことを判定する。そこで、図５に示されているように、ＲＬＣ層は、アップリンクリソースが必要とされることをＭＡＣ層にシグナリングする。ＭＡＣ層は、リソースが未だスケジューリングされていなければ、スケジューラからのアップリンクリソースを要求することによりそれに応じる。
【００３４】
いわゆる当業者は、アップリンクリソースが必要とされることのＲＬＣ層からＭＡＣ層へのシグナリングが、エラー制御メッセージの送信のために当該リソースが要求されていることを特に示しても示さなくてもよいことを理解するであろう。よって、いくつかの実施形態では、当該シグナリングは、単純に、ＲＬＣ ＰＤＵが保留されていること、及びアップリンクリソースが未だ利用可能でなければスケジューリングされるべきことを示し得る。他の実施形態において、リソースが制御メッセージのために必要とされていることを特別に示すシグナリングが有益であり得る。
【００３５】
いかなるイベントにおいても、実質的なリソースの許可は、図５に示されているように、大幅な遅延の後にのみ得られる。この遅延の間、複数の確認モードのＲＬＣ ＰＤＵであるＰＤＵ３及びＰＤＵ４が、スケジューリング遅延の間の移動局において受信される。しかしながら、このシナリオでは、ステータスレポートは、生成されておらず、送信待ちとしてＭＡＣ層の中でキューイングもされていない。その代わりに、図５において、ＲＣＬ層は、アップリンクリソース要求が許可されたこと（即ち、アップリンクリソースが利用可能であること）がＭＡＣ層からＲＬＣへ通知された後まで、ステータスレポートデータの生成を遅れさせる。よって、ステータスレポートは、それがＭＡＣ層に転送されｅＮｏｄｅＢへ送信される時には、（ＰＤＵ３及びＰＤＵ４のステータスを含む）その時点のデータを有する。それでも処理及びキューイングの遅延は存在するものの、これら遅延は図３に描かれた状況と比較して極小である。
【００３６】
本発明のいくつかの実施形態は、上で議論したＲＬＣ ＡＲＱポーリング及びステータス−禁止タイマなどのエラー制御処理のためのタイマの起動と再開について同様の技術を利用する。これら実施形態において、エラー制御タイマのアクティブ化は、エラー制御情報を搬送するＲＬＣ ＰＤＵがリモートノードへ送信されたこと、又はまもなく送信されるであろうということのＭＡＣ層による（ＲＬＣ層への）通知によりトリガされ得る。
【００３７】
図６において、そうした一実施形態についての一例としての動作が描かれている。図４において描かれたイベントフローにおけるケースのように、このイベントフローでは、ｅＮｏｄｅＢにおいてポーリング要求がトリガされる。ポーリング要求を搬送するＲＬＣ ＰＤＵは、移動局への送信のためにＭＡＣへ転送される。しかし、この場合、ポーリングタイマは即座には起動しない。その代わり、ポーリングタイマは、ポーリング要求が送信されたことがＭＡＣ層によりＲＬＣ層に通知された後まで起動しない。図６に描かれているように、それは、大幅なスケジューリング／キューイング遅延の後に起こり得る。ポーリング要求が実際に送信された時又はその前後までポーリングタイマの起動は遅らせられたため、タイマは、移動局からのステータスレポートの受信よりも前に失効しない。よって、ポーリング要求の不必要な再送信は回避される。
【００３８】
いくつかの実施形態において、ＭＡＣ層は、ＲＬＣ ＡＲＱ制御情報を搬送するＰＤＵの送信が開始され、又はまもなく開始されることをＲＬＣ層に通知するよう構成されてもよい。他の実施形態において、その代わりに、ＭＡＣ層は、ＲＬＣ ＡＲＱ制御情報を搬送するＰＤＵの送信に対してＭＡＣ ＨＡＲＱ層上で確認応答がなされたことをＲＬＣ層に通知してもよい。いわゆる当業者は、ポーリングタイマの観点での上述した技術が、例えばステータス−禁止タイマなどの他のエラー制御タイマにも適用され得ることを理解するであろう。
【００３９】
図７は、例えば上述した１つ以上のＲＬＣ及びＭＡＣコントローラなどにより実行され得る、エラー制御メッセージの処理のための一例としての方法を示す論理フロー図である。図示された方法において、ここで開示される発明についての技術は、エラー制御メッセージの生成及びエラー制御タイマのアクティブ化の双方に適用される。いわゆる当業者は、当然ながら、本発明の多くの実施形態が双方のエラー制御処理に適用され得るものであり、一方でいくつかは双方ではなくいずれかにのみ適用され得ることを理解するであろう。
【００４０】
いかなるイベントにおいても、図７の一例としての方法は、ブロック７１０において、エラー制御メッセージの送信のためにリンクリソースが必要であることの通信ノードにおけるＭＡＣコントローラへのシグナリングにより始まる。上で議論したように、これは、いくつもの異なるイベントのいずれかによってトリガされ得る。例えば、受信ノードにおけるポーリング要求の受信は、一般的に、ステータスレポート処理をトリガするであろう。すると、この場合、ブロック７１０におけるリンクリソースについてのシグナリングは、ステータスレポートを送信するためのリソースについてのものである。可能性のある他のトリガイベントは、エラー制御タイマの失効である。例えば、ポーリングタイマの失効は、新たなポーリング要求をトリガし得るものであり、その場合、ブロック７１０におけるシグナリングは、新たなポーリング要求をトリガするためのリソースを要求するものとなるであろう。
【００４１】
いかなるイベントにおいても、ブロック７２０において、リンクリソースが利用可能であるという標識がＭＡＣコントローラから受信される。上で詳細に議論したように、これは、リソースについての要求の後に即座に生じ、又は大幅なスケジューリング遅延の後に生じ得る。いずれのケースでも、リンクリソースが利用可能であるという標識に応じて、ブロック７３０においてエラー制御メッセージが生成される。よって、その時点のステータスに基づいてエラー制御メッセージの内容が生成され、その内容はいかなるスケジューリング遅延によっても“陳腐（stale）”にはならない。ブロック７４０において、エラー制御メッセージは送信のためにＭＡＣコントローラへ転送される。ブロック７３０のメッセージ生成及びブロック７４０のメッセージ転送はリソースが利用可能となった後まで遅らせられたため、ＭＡＣコントローラへの転送後の送信遅延は極小化される。
【００４２】
ブロック７５０において、エラー制御メッセージの送信が開始し又は完了したことの通知がＭＡＣコントローラから受信される。この通知に応じて、ブロック７６０に示されているように、例えばポーリングタイマまたはステータス−禁止タイマなどの適切なエラー制御タイマがアクティブ化される。
【００４３】
ここで説明されるＲＬＣ及びＭＡＣ手続は、上述したプロトコルスタック２１０及び２２０のＲＬＣ及びＭＡＣ層をそれぞれ実装するＲＬＣコントローラ及びＭＡＣコントローラによりそれぞれ実装され得る。いわゆる当業者は、これら手続が、従来のＲＬＣコントローラ及びＭＡＣコントローラを修正することにより実装されてもよく、上述したように１つ以上のプログラム可能なプロセッサ、ハードウェア回路又はそれらの組み合わせにより実装されてもよいことを理解するであろう。
【００４４】
さらに、ここで開示される方法は、上述したＬＴＥ移動局又はｅＮｏｄｅＢなどのような無線リンクのいずれか又は双方の端部において実装され得る。よって、図８は、本発明の１つ以上の実施形態に係る無線通信装置の一般的な特徴を示しており；図示された無線装置８００は、様々な実施形態において、移動端末（セルラー電話、無線ＰＤＡ（personal digital assistant）、無線ＰＣ（personal computer）、マシン間（machine-to-machine）デバイスなど）、基地局、リピータ又は無線リンクを終端する他のノードを含み得る。
【００４５】
図８の無線装置８００は、リモート送受信機との間で１つ以上の無線リンク上でアンテナ８１５を介して通信するように動作可能な無線送受信機８１０を有する。いくつかの実施形態において、無線送受信機８１０は、例えば３ＧＰＰにより公表された無線標準のいずれかなどの標準に従ってフォーマットされた信号を送受信するように構成される。例えば、無線送受信機８１０は、ＬＴＥ標準に従って、ＯＦＤＭＡ及びＳＣ−ＦＤＭＡ信号を送信し及び／又は受信するよう構成されてもよい。
【００４６】
無線装置８００は、さらに、メディアアクセス制御機能８２０、無線リンク制御機能８３０、及び他の処理８４０を有する。ＭＡＣ及びＲＬＣ機能の一般的機能は上で議論されており；これら機能は、アナログ及びデジタルハードウェア並びにソフトウェアと共に構成されるプログラム可能なプロセッサの様々な組み合わせのいずれかの上に実装され得る。いわゆる当業者は、無線装置８００の動作のために必要なこれら機能及び他の機能が、１つ又は複数のプログラム可能なプロセッサを用いて実装され得ることを理解するであろう。多くの実施形態において、ＭＡＣ８２０及びＲＬＣ８３０機能は、ここで説明した様々なＲＬＣ及びＭＡＣ機能を実行するソフトウェアと共に構成される単一のマイクロプロセッサ又は特定目的集積回路上に実装される、例えば図２のプロトコルスタック２１０などのプロトコルスタックとして実装される。
【００４７】
例えば、ＲＬＣコントローラ８３０は、ＲＬＣ層を定義するソフトウェアを伴ってプログラムされるマイクロプロセッサと共に実装されることができ、ＲＬＣ層は、データの送信のためにリンクリソースが必要であることをメディアアクセスコントローラにシグナリングし、当該データの送信のためのリンクリソースがスケジューリングされたことの標識をメディアアクセスコントローラから受信し、及び、当該標識に応じて現在のＲＬＣ層についてのエラー制御ステータスに基づいてエラー制御メッセージを生成するように構成される。限定ではないが、エラー制御メッセージは、ポーリング要求又はステータスレポートを含んでよい。いくつかの実施形態において、ＲＬＣ層は、エラー制御メッセージの送信が開始したことの通知を受信し、当該通知に応じてエラー制御タイマを起動するようにさらに構成されてもよい。限定ではないが、エラー制御タイマは、ポーリングタイマ又はステータス−禁止タイマを含み得る。
【００４８】
同様に、ＭＡＣコントローラ８２０の全部又は一部は、ＭＡＣ層を定義するソフトウェアを伴ってプログラムされる同じマイクロプロセッサ上で、又は１つ以上の他のマイクロプロセッサ上で実装されてよい。ＭＡＣ層は、データの送信のためにリンクリソースが必要であることを示す信号をＲＬＣ層から受信し、必要に応じてリンクリソースを要求するように構成される。ＭＡＣ層は、リソースの許可の受信後にＲＬＣ層に通知をするようにさらに構成される。いくつかの構成において、ＭＡＣ層は、（ＲＬＣ層によりＭＡＣ層に提供される）エラー制御メッセージが送信されたときに、又はいくつかの実施形態においてエラー制御の送信が間近に迫ったときに、ＲＬＣ層に通知をするようにさらに構成される。
【００４９】
当然ながら、本開示による内容は、本発明の本質的な特徴から離れることなく、ここで特に例示されたものとは別の手法で実行されてもよい。本実施形態は、あらゆる観点において、限定ではなく説明のためのものとしてみなされ、添付の特許請求の範囲の意味及び均等の範囲内での全ての変更は、ここに含まれることが意図される。
【特許請求の範囲】
【請求項１】
無線通信システムにおけるエラー制御処理のためにタイマを取り扱うための方法であって：
無線リンクコントローラにより、データを送信するためにリンクリソースが必要であることをメディアアクセスコントローラへシグナリングすることと；
前記データを送信するためのリンクリソースが利用可能であることを示す標識を前記メディアアクセスコントローラから受信することと；
前記標識の受信に応じて、現在のエラー制御ステータスに基づいてエラー制御メッセージを生成し、当該エラー制御メッセージを送信のために前記メディアアクセスコントローラへ転送し、エラー制御タイマを起動することと；
前記エラー制御タイマが失効する前にさらなるエラー制御メッセージが生成されるのを防ぐことと；
を含むことを特徴とする方法。
【請求項２】
前記エラー制御タイマは、ポーリング−再送タイマ及びステータス−禁止タイマの１つであることを特徴とする、請求項１の方法。
【請求項３】
前記エラー制御メッセージは、自動再送要求（ＡＲＱ）ステータスレポートメッセージを含むことを特徴とする、先行する請求項１又は２の方法。
【請求項４】
前記エラー制御メッセージは、再送要求を含むことを特徴とする、先行する請求項１又は２の方法。
【請求項５】
前記エラー制御メッセージは、自動再送要求（ＡＲＱ）ポーリングメッセージを含むことを特徴とする、先行する請求項１又は２の方法。
【請求項６】
前記方法は：
前記エラー制御メッセージの送信が開始したことの通知を受信すること、
をさらに含むこと特徴とする、先行する請求項１又は２の方法。
【請求項７】
前記方法は：
前記エラー制御メッセージに対する確認応答がなされたことの通知を前記メディアアクセスコントローラから受信すること、
をさらに含むこと特徴とする、先行する請求項１又は２の方法。
【請求項８】
無線送受信機、メディアアクセスコントローラ、及び無線リンクコントローラを備える、エラー制御処理のためにタイマを取り扱う無線通信装置であって、
前記無線リンクコントローラは：
データを送信するためにリンクリソースが必要であることを前記メディアアクセスコントローラへシグナリングし；
前記データを送信するためのリンクリソースが利用可能であることを示す標識を前記メディアアクセスコントローラから受信し；
前記標識の受信に応じて、現在のエラー制御ステータスに基づいてエラー制御メッセージを生成し、当該エラー制御メッセージを送信のために前記メディアアクセスコントローラへ転送し、エラー制御タイマを起動し；
前記エラー制御タイマが失効する前にさらなるエラー制御メッセージが生成されるのを防ぐ；
ように構成されることを特徴とする、
無線通信装置。
【請求項９】
前記エラー制御タイマは、ポーリング−再送タイマ及びステータス−禁止タイマの１つであることを特徴とする、請求項８の無線通信装置。
【請求項１０】
前記エラー制御メッセージは、自動再送要求（ＡＲＱ）ステータスレポートメッセージを含むことを特徴とする、請求項８又は９の無線通信装置。
【請求項１１】
前記エラー制御メッセージは、再送要求を含むことを特徴とする、請求項８又は９の無線通信装置。
【請求項１２】
前記エラー制御メッセージは、自動再送要求（ＡＲＱ）ポーリングメッセージを含むことを特徴とする、請求項８又は９の無線通信装置。
【請求項１３】
前記方法は：
前記エラー制御メッセージの送信が開始したことの通知を受信すること
をさらに含むことを特徴とする、請求項８又は９の無線通信装置。
【請求項１４】
前記方法は：
前記エラー制御メッセージに対する確認応答がなされたことの通知を前記メディアアクセスコントローラから受信こと
をさらに含むことを特徴とする、請求項８又は９の無線通信装置。
【請求項１】
無線通信システムにおけるエラー制御処理のためにタイマを取り扱うための方法であって：
無線リンクコントローラにより、データを送信するためにリンクリソースが必要であることをメディアアクセスコントローラへシグナリングすることと；
前記データを送信するためのリンクリソースが利用可能であることを示す標識を前記メディアアクセスコントローラから受信することと；
前記標識の受信に応じて、現在のエラー制御ステータスに基づいてエラー制御メッセージを生成し、当該エラー制御メッセージを送信のために前記メディアアクセスコントローラへ転送し、エラー制御タイマを起動することと；
前記エラー制御タイマが失効する前にさらなるエラー制御メッセージが生成されるのを防ぐことと；
を含むことを特徴とする方法。
【請求項２】
前記エラー制御タイマは、ポーリング−再送タイマ及びステータス−禁止タイマの１つであることを特徴とする、請求項１の方法。
【請求項３】
前記エラー制御メッセージは、自動再送要求（ＡＲＱ）ステータスレポートメッセージを含むことを特徴とする、先行する請求項１又は２の方法。
【請求項４】
前記エラー制御メッセージは、再送要求を含むことを特徴とする、先行する請求項１又は２の方法。
【請求項５】
前記エラー制御メッセージは、自動再送要求（ＡＲＱ）ポーリングメッセージを含むことを特徴とする、先行する請求項１又は２の方法。
【請求項６】
前記方法は：
前記エラー制御メッセージの送信が開始したことの通知を受信すること、
をさらに含むこと特徴とする、先行する請求項１又は２の方法。
【請求項７】
前記方法は：
前記エラー制御メッセージに対する確認応答がなされたことの通知を前記メディアアクセスコントローラから受信すること、
をさらに含むこと特徴とする、先行する請求項１又は２の方法。
【請求項８】
無線送受信機、メディアアクセスコントローラ、及び無線リンクコントローラを備える、エラー制御処理のためにタイマを取り扱う無線通信装置であって、
前記無線リンクコントローラは：
データを送信するためにリンクリソースが必要であることを前記メディアアクセスコントローラへシグナリングし；
前記データを送信するためのリンクリソースが利用可能であることを示す標識を前記メディアアクセスコントローラから受信し；
前記標識の受信に応じて、現在のエラー制御ステータスに基づいてエラー制御メッセージを生成し、当該エラー制御メッセージを送信のために前記メディアアクセスコントローラへ転送し、エラー制御タイマを起動し；
前記エラー制御タイマが失効する前にさらなるエラー制御メッセージが生成されるのを防ぐ；
ように構成されることを特徴とする、
無線通信装置。
【請求項９】
前記エラー制御タイマは、ポーリング−再送タイマ及びステータス−禁止タイマの１つであることを特徴とする、請求項８の無線通信装置。
【請求項１０】
前記エラー制御メッセージは、自動再送要求（ＡＲＱ）ステータスレポートメッセージを含むことを特徴とする、請求項８又は９の無線通信装置。
【請求項１１】
前記エラー制御メッセージは、再送要求を含むことを特徴とする、請求項８又は９の無線通信装置。
【請求項１２】
前記エラー制御メッセージは、自動再送要求（ＡＲＱ）ポーリングメッセージを含むことを特徴とする、請求項８又は９の無線通信装置。
【請求項１３】
前記方法は：
前記エラー制御メッセージの送信が開始したことの通知を受信すること
をさらに含むことを特徴とする、請求項８又は９の無線通信装置。
【請求項１４】
前記方法は：
前記エラー制御メッセージに対する確認応答がなされたことの通知を前記メディアアクセスコントローラから受信こと
をさらに含むことを特徴とする、請求項８又は９の無線通信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１２−１６５４２０（Ｐ２０１２−１６５４２０Ａ）
【公開日】平成２４年８月３０日（２０１２．８．３０）
【国際特許分類】
【出願番号】特願２０１２−７４１５２（Ｐ２０１２−７４１５２）
【出願日】平成２４年３月２８日（２０１２．３．２８）
【分割の表示】特願２０１０−５３１９９０（Ｐ２０１０−５３１９９０）の分割
【原出願日】平成２０年６月１８日（２００８．６．１８）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公開日】平成２４年８月３０日（２０１２．８．３０）
【国際特許分類】
【出願日】平成２４年３月２８日（２０１２．３．２８）
【分割の表示】特願２０１０−５３１９９０（Ｐ２０１０−５３１９９０）の分割
【原出願日】平成２０年６月１８日（２００８．６．１８）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]