(57)【要約】本発明の側面は、移動端末と基地局を含む電気通信システムにおける資源のスケジューリングに関する。一つの実施形態では、移動端末は基地局に最初のスケジューリング要求を送る。その後、スケジューリング要求トリガ・イベントを検出しないなら、および検出するまで、移動端末は基地局にスケジューリング要求を送信しない。
2010530707.tif 000002
【特許請求の範囲】
【請求項１】
移動端末（３０２）から基地局（３０４）にスケジューリング要求（３０６）を送信する方法であって、
（ａ）移動端末（３０２）から基地局（３０４）への送信に利用可能となる第一のデータに応じて、移動端末（３０２）から基地局（３０４）に第一のスケジューリング要求（ＳＲ）（３０６）を送信するステップと、
（ｂ）第一のＳＲ（３０６）を送信後、基地局（３０４）から送信したスケジューリング許可信号（ＳＧ）（３１０）を移動端末（３０２）で受信するステップと、
（ｃ）ＳＧ（３１０）の受信に応じて、移動端末（３０２）から基地局（３０４）に送信バッファ状態情報（３１４）を送信するステップと、
（ｄ）少なくとも幾つかの第一のデータが基地局（３０４）に送信されるのを待っている間において、バッファ状態情報（３１４）を送信後、かつ基地局（３０４）に任意の後続のＳＲ（３０６）を送信するに先立って、
（ｄ１）スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップと、
（ｄ２）トリガ・イベントが起こったなら、トリガ・イベントが起こったとの判定に応じて、次の機会に、基地局（３０４）に第二のＳＲ（３０６）を送信するステップと、
（ｄ３）トリガ・イベントが起こらなかったなら、トリガ・イベントが起こらなかったとの判定に応じて、その次の機会に、トリガ・イベントが起こらなかったことを示すメッセージを基地局（３０４）に送信するステップと、
をさらに実行するステップと、
を有することを特徴とする方法。
【請求項２】
スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップには、基地局（３０４）に送信した送信バッファ状態情報（３１４）と送信バッファの状態に関する新しい情報とを比較するステップを有することを特徴とする請求項１に記載の方法。
【請求項３】
スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップには、基地局（３０４）に移動端末（３０２）からの送信に利用可能な第二のデータが、第一のデータより高い優先度を持つかどうかを判定するステップを有し、
第一のＳＲ（３０６）を送信した後、第二のデータが基地局（３０４）への送信に利用可能となったこと
を特徴とする請求項１または２に記載の方法。
【請求項４】
スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップには、第一のＳＲ（３０６）を送信して以降経過した時間がある閾値を超えたかどうかを判定するステップを有すること
を特徴とする請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップには、送信バッファの現在のデータ量と、送信バッファにあった、以前の非ゼロのデータ量との差がある閾値を超えたかどうかを判定するステップを有することを特徴とする請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
スケジューリング要求トリガ・イベントが起こったかどうかを判定する前記ステップが、
（ａ）第一のＳＲ（３０６）を送信した後に基地局（３０４）への送信に利用可能となった第二のデータが、第一のデータより高い優先度を持つかどうかを判定するステップと、
（ｂ）第一のＳＲ（３０６）を送信して以降経過した時間がある閾値を超えたかどうかを判定するステップと、
（ｃ）送信バッファの現在のデータ量と、送信バッファにあった、以前の非ゼロのデータ量との差がある閾値を超えたかどうかを判定するステップと
を有することを特徴とする請求項１に記載の方法。
【請求項７】
スケジューリング要求トリガ・イベントが起こったかどうかを判定する前記ステップが、
（ａ）第一のＳＲ（３０６）を送信した後に基地局（３０４）への送信に利用可能となった第二のデータが、第一のデータより高い優先度を持つかどうかを判定するステップと、
（ｂ）第一のＳＲ（３０６）を送信して以降経過した時間がある閾値を超えたかどうかを判定するステップと
を有する特徴とする請求項１に記載の方法。
【請求項８】
トリガ・イベントが起こらなかったことを示すメッセージが１ビットのメッセージであることを特徴とする請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
ＳＲ（３０６）が１ビットのメッセージであることを特徴とする請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
無線資源制御（ＲＲＣ）シグナリングを通して基地局（３０４）が移動端末（３０２）で閾値を構成することを特徴とする請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
データが移動端末（３０２）の空の送信バッファに到達するごとに、次の利用可能な機会にＳＲ（３０６）を送信するステップをさらに有することを特徴とする請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
移動端末（３０２）から送信バッファ状態情報（３１４）を基地局（３０４）へ送信し、移動端末（３０２）に確認応答を格納した後、基地局（３０４）から送信したＨＡＲＱ  ＡＣＫを移動端末（３０２）で受信するステップをさらに有することを特徴とする請求項１乃至１１のいずれか一項に記載の方法。
【請求項１３】
送信バッファ（７０２）と、
データ・プロセッサ（７０６）とを備え、
前記データ・プロセッサ（７０６）を、
（ａ）移動端末（３０２）の空の送信バッファに到達することに応じて、移動端末（３０２）に、第一のスケジューリング要求（ＳＲ）（３０６）を基地局（３０４）に送信さ、
（ｂ）基地局（３０４）からスケジューリング許可信号（ＳＧ）（３１０）を受信することに応じて、移動端末（３０２）に、送信バッファ状態情報（３１４）を基地局（３０４）に送信させ、
（ｃ）少なくとも幾つかの第一のデータが基地局（３０４）に送信されるのを待っている間において、バッファ状態情報（３１４）を送信後、かつ基地局（３０４）に任意の後続のＳＲを送信するのに先立って、（ｃ１）スケジューリング要求トリガ・イベントが起こったかどうかを判定し、（ｃ２）トリガ・イベントが起こったとの判定に応じて、次の機会に移動端末（３０２）に第二のＳＲ（３０６）を基地局（３０４）に送信させ、（ｃ３）トリガ・イベントが一つも起こらなかったとの判定に応じて、移動端末（３０２）に、トリガ・イベントが次の機会に起こらなかったことを示すメッセージを基地局（３０４）に送信させるというステップ（ｃ１）−（ｃ３）を実行するように構成した
ことを特徴とする移動端末（３０２）。
【請求項１４】
基地局（３０４）に送信した送信バッファ状態情報（３１４）を送信バッファの状態に関する新しい情報と比較することにより、スケジューリング要求トリガ・イベントが起こったかどうかを判定するようデータ・プロセッサ（７０６）を構成することを特徴とする請求項１３に記載の移動端末（３０２）。
【請求項１５】
第一のＳＲ（３０６）を送信した後、基地局（３０４）への送信に利用可能となった第二のデータが第一のデータより高い優先度を持つかどうかを判定することにより、スケジューリング要求トリガ・イベントが起こったかどうかを判定するようデータ・プロセッサ（７０６）を構成することを特徴とする請求項１３または１４に記載の移動端末（３０２）。
【請求項１６】
第一のＳＲ（３０６）を送信して以降経過した時間がある閾値を超えたかどうかを判定することにより、スケジューリング要求トリガ・イベントが起こったかどうかを判定するようデータ・プロセッサを構成することを特徴とする請求項１３、１４または１５に記載の移動端末（３０２）。
【請求項１７】
送信バッファ（７０２）の現在のデータ量と、送信バッファ（７０２）にあった、以前の非ゼロのデータ量との差がある閾値を超えたかどうかを判定することにより、スケジューリング要求トリガ・イベントが起こったかどうかを判定するようデータ・プロセッサ（７０６）を構成することを特徴とする請求項１３、１４、１５または１６に記載の移動端末（３０２）。
【請求項１８】
トリガ・イベントが起こらなかったことを示すメッセージが１ビットのメッセージであることを特徴とする請求項１３、１４、１５、１６または１７に記載の移動端末（３０２）。
【請求項１９】
ＳＲ（３０６）が１ビットのメッセージであることを特徴とする請求項１３、１４、１５、１６、１７または１８に記載の移動端末（３０２）。
【請求項２０】
（ａ）データを受信する移動端末（３０２）の空の送信バッファに応じて、基地局（３０４）に第一のスケジューリング要求（ＳＲ）（３０６）を送信する手段と、
（ｂ）基地局（３０４）から受信したスケジューリング許可信号（ＳＧ）（３１０）を受信する手段と、
（ｃ）ＳＧ（３１０）を受信することに応じて、送信バッファ状態情報（３１４）を基地局（３０４）に送信する手段と、
（ｄ）スケジューリング要求トリガ・イベントが起こったかどうかを判定するためのトリガ・イベント検出手段（７０６）とを備え、
前記トリガ・イベント検出手段（７０６）は、少なくとも幾つかのデータが基地局（３０４）に送信されるのを待っている間、判定を実行するよう構成され、 
（ｅ）前記スケジューリング要求トリガ・イベントが起こったとの判定に応じて、次の機会に第二のＳＲ（３０６）を基地局（３０４）に送信する手段を備えること、
を特徴とする移動端末（３０２）。
【請求項２１】
（ｆ）前記スケジューリング要求トリガ・イベントが起こらなかったとの判定に応じて、前記スケジューリング要求トリガ・イベントが起こらなかったことを示すメッセージを、次の機会に、基地局（３０４）に送信する手段をさらに備えること、
を特徴とする請求項２１に記載の移動端末（３０２）．
【請求項２２】
前記トリガ・イベント検出手段（７０６）には、基地局（３０４）に送信された送信バッファ状態情報（３１４）と送信バッファの状態に関する新しい情報とを比較する手段（７０８）を備えること、
を特徴とする請求項２１または２２に記載の移動端末（３０２）。
【請求項２３】
前記トリガ・イベント検出手段（７０６）には、移動端末（３０２）から基地局（３０４）への送信に利用可能な第二のデータが、第一のデータより高い優先度を持つかどうかを判定する手段（７０８）を備え、
第一のＳＲ（３０６）を送信した後、第二のデータが基地局（３０４）への送信に利用可能となったこと、
を特徴とする請求項２０乃至２２のいずれか一項に記載の移動端末（３０２）。
【請求項２４】
トリガ・イベント検出手段（７０７）には、第一のＳＲ（３０６）を送信して以降経過した時間が、ある閾値を超えたかどうかを判定する手段（７０８）を備えること、
を特徴とする請求項２０乃至２３のいずれか一項に記載の移動端末（３０２）。
【請求項２５】
トリガ・イベント検出手段（７０７）には、送信バッファの現在のデータ量と送信バッファにあった、以前の非ゼロのデータ量との差がある閾値を超えたかどうかを判定する手段（７０８）を備えること、
を特徴とする請求項２０乃至２４のいずれか一項に記載の移動端末（３０２）。
【請求項２６】
トリガ・イベントが起こらなかったことを示すメッセージが１ビットのメッセージであることを特徴とする請求項２０乃至２５のいずれか一項に記載の移動端末（３０２）。
【請求項２７】
ＳＲ（３０６）が１ビットのメッセージであることを特徴とする請求項２０乃至２６のいずれか一項に記載の移動端末（３０２）。
【請求項２８】
移動端末（３０２）に上りリンク資源を許可するために基地局（３０４）が実行する方法であって、
第一の移動端末（３０２）に上りリンク資源を割り当て、それによって第一の移動端末（３０２）が基地局（３０４）にデータを送信可能となるステップと、
第一の移動端末（３０２）が上りリンク資源を利用している間、第二の移動端末（３０２）からＳＲ（３０６）を受信するステップと、
ＳＲ（３０６）を受信することに応じて、第二の移動端末（３０２）に上りリンク資源を再割り当てするステップと、
基地局（３０４）に送信されるのを待っている、第二の移動端末のデータの優先度に関係する情報を、第二の移動端末（３０２）から受信するステップと、
それぞれの優先度情報を使用して、第一の移動端末のデータの優先度と第二の移動端末のデータの優先度とを比較するステップと、
第一の移動端末（３０２）が第二の移動端末（３０２）より高い優先度を持つことを判定するステップに応じて、第一の移動端末（３０２）に上りリンク資源を再配分するステップと、
第二の移動端末（３０２）から後続のＳＲ（３０６）を受信するステップとを有し、
前記第二の移動端末（３０２）から優先度情報を受信した後で、前記第二の移動端末（３０２）からその他の任意のデータの優先度情報を受信する前に、後続のＳＲ（３０６）を受信するステップと、 
前記後続のＳＲ（３０６）の受信に応じて、前記第二の移動端末（３０２）に上りリンク資源を再割り当てするステップと
を有すること
を特徴とする方法。
【請求項２９】
各ＳＲ（３０６）が１ビットのメッセージであることを特徴とする請求項２８に記載の方法。
【請求項３０】
前記第一の移動端末（３０２）が前記第二の移動端末（３０２）より高い優先度のデータを持つことの判定に応じて前記第一の移動端末（３０２）に上りリンク資源を再割り当てした後、前記第二の移動端末（３０２）から後続のＳＲ（３０６）を受信するのに先立って、第二の移動端末（３０２）から複数のメッセージを受信するステップを有し、
前記複数のメッセージは各々、前記第二の移動端末（３０２）がスケジューリング要求トリガ・イベントを検出しなかったことを示すこと
を特徴とする請求項２８または２９に記載の方法。
【請求項３１】
前記複数のメッセージの各々が１ビットのメッセージであることを特徴とする請求項３０に記載の方法。
【請求項３２】
複数の移動端末（３０２）と通信する手段と、
端末からの各バッファ状態データ送信に基づき、前記移動端末（３０２）の一つに上りリンク資源を配分する手段（９０６）と、
他の端末のバッファ状態データの変化を示す単一ビットのメッセージの受信に基づき、複数の端末のもう一つに上りリンク資源を再割り当てする手段（９０６）とをさらに備えることを特徴とする基地局（３０４）。
【請求項３３】
請求項１３乃至２７のいずれか一項に記載の移動端末（３０２）を備えることを特徴とする通信システム。
【請求項３４】
請求項３２に記載の基地局（３０４）をさらに備えることを特徴とする請求項３３に記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的には電気通信システムに関する。本発明の実施形態は、電気通信システムにおける資源のスケジューリングに関する。
【背景技術】
【０００２】
セルラ移動ネットワーク用無線アクセス技術は、高速データ速度、改善したサービス圏および改善した容量のための将来の要求を満たすよう、常に発達している。広帯域符号分割多元接続（ＷＣＤＭＡ）の最近の発展の例は、高速パケットアクセス（ＨＳＰＡ）プロトコルである。現在は、第３世代（３Ｇ）システム、３Ｇロング・ターム・エボリューション（ＬＴＥ）が、新しいアクセス技術および新しいアーキテクチャを含めて、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）標準化機関内で開発されている。
【０００３】
ＬＴＥの主な目的は、現在の周波数配分および新しい周波数配分で使用できる柔軟なアクセス技術を提供することである。また、ＬＴＥシステムは、各種の２重通信解決策の使用を可能とすべきである。例えば、上りリンクと下りリンクが周波数および時間でそれぞれ分離している周波数分割複信（ＦＤＤ）および時分割複信（ＴＤＤ）は両方とも、対および非対の両方のスペクトルでの利用を提供するよう、サポートされるべきである。
【０００４】
例えば、下りリンクに対しては直交周波数分割多重（ＯＦＤＭ）、および上りリンクに対してはシングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）に基づくアクセス技術は、そのような柔軟なスペクトル解決策を可能にする。
【０００５】
ＬＴＥの概念は、上りリンクおよび下りリンクの両方に対して周波数と時間で高速なスケジューリングをサポートするよう設計されているので、時間と周波数における資源割当ては、ユーザの瞬間的トラヒック要求およびチャネル変化に対してできれば調整可能とすべきである。ＬＴＥ上りリンクでは、異なるユーザに異なる周波数部分を割当てることにより、一つの送信時間間隔（ＴＴＩ）で数個のユーザをスケジューリングすることができる。シングルキャリア構成を維持するため、各ユーザは、図１に示すように、周波数において隣接する割当のみを受信すべきである。
【０００６】
ここで図２を参照して、進化したノードＢ（基地局）２０４のスケジューラ２０２は資源割当を実行してもよい。上りリンクの二つ以上のユーザ間で資源をスケジューリングすることは、スケジューラ２０２が各ユーザの上りリンク・データおよび資源要求を自動的には知っていないという事実により、複雑である。即ち、例えば、スケジューラ２０２は、各ユーザの移動端末２０６（例えば、移動電話、携帯情報端末、またはその他の任意の携帯端末）の送信バッファにどれだけ多くのデータがあるか、知っていない可能性がある。移動端末２０６は、ユーザ機器（ＵＥ）と呼んでもよい。高速スケジューリングをサポートするため、スケジューラ２０２には、ＵＥの瞬間的トラヒック要求（例えば、送信バッファ状態）を知らされなければならないだろう。
【０００７】
基本的な上りリンク・スケジューリングの概念を図２に示す。通常は、上りリンク（ＵＬ）スケジューラ２０２にＵＥの瞬間的トラヒック要求を知らせるため、システム２００は、（i）専用のスケジューリング要求（ＳＲ）チャネルと（ii）バッファ状態報告とをサポートする。あるいは、同じ目的のため、同期したランダム・アクセス・チャネル（ＲＡＣＨ）を使用できる。
【０００８】
スケジューラ２０２は、各ＵＥのトラヒック要求をモニタし、それに従って資源を割り当てる。スケジューラ２０２は、資源割り当て２０８をＵＥに送信することによりスケジューリング決定をＵＥ（例えば、ＵＥ２０６）に知らせる。加えて、高速リンク適応およびチャネル依存スケジューリングのために、進化したノードＢ（ｅＮｏｄｅＢ）が広帯域チャネル評価を行うことができるように、チャネル・サウンディング基本信号を送信するようＵＥを構成する可能性がある。  また、同期したＵＥは、フォールバック解決策としてランダム・アクセス・チャネル（ＲＡＣＨ）を使用し、ＵＬ資源を要求する機会を有する。しかしながら、一般的には、非同期のＵＥのために殆んど、本ＲＡＣＨを意図している。専用ＳＲチャネル手法では、ＵＥがＵＬ資源を要求しているということをｅＮｏｄｅＢに示すメッセージを送信するため、各アクティブＵＥに専用チャネルを割り当てる。そのようなメッセージをスケジューリング要求（ＳＲ）２１０と呼ぶ。この方法が有する利点は、いかなるＵＥ識別子（ＩＤ）も送信する必要がないということであり、これは、ＵＥが使用する“チャネル”によりＵＥを識別するからである。さらに、競合をベースとした手法と対比して、セル内の衝突が全く起こらないだろう。
【０００９】
ＳＲ２１０を受信することに応じて、スケジューラ２０２は、スケジューリング許可信号（ＳＧ）２０８をＵＥに出してもよい。即ち、当然ＵＥがこの情報を使用し、ＵＥに通信するだろう資源（例えば、時間スロットおよび周波数またはそのいずれか一方）を、スケジューラは選択してもよい。また、スケジューラ２０２は、リンク・アダプテーション機能からのサポートで、転送ブロック・サイズ、変調方式、符号方式およびアンテナ方式を選択してもよい（即ち、ｅＮｏｄｅＢでリンク適合を実行し、ユーザＩＤの情報と一緒に選択した転送フォーマットをＵＥに信号伝達する）。スケジューリング許可信号はＵＥを指定するが、特定の無線ベアラを指定しない。その最も簡単な形式では、スケジューリング許可信号は次のＵＬ  ＴＴＩ（アップリンクの送信時間間隔）に対してのみ有効である。しかしながら、必要とする制御シグナリング量を削減するため、他の継続時間を有する幾つかの提案が可能である。
【００１０】
最初のＳＲ（スケジューリング要求）を送信した後、ＵＥはスケジューラ２０２により詳細なバッファ状態報告を送信してもよい。バッファ状態報告をインバンドで送信してもよい（例えば、媒体アクセス制御（ＭＡＣ）ヘッダの一部として、バッファ状態報告を含めてもよい）。例えば３ＧＰＰでは、バッファ状態報告には、最初のＳＲに含む以上の情報を含むべきである、というのが共通した意見である。
【００１１】
上記の手順について、さらに図３に示す。図３に示すように、ｅＮｏｄｅＢ３０４に送信すべきデータを持つＵＥ３０２は、まず、ｅＮｏｄｅＢ３０４にＳＲ３０６を送信し、次にｅＮｏｄｅＢ３０４の上りリンク・スケジューラ３０８によって、それを処理する。ＳＲ３０６に応じて、上りリンク・スケジューラ３０８はＳＧ（例えば、資源割当）３１０をＵＥ  ３０２に送信する。その後に、ＵＥ３０２は、バッファ状態報告３１４と一緒にデータ３１２をｅＮｏｄｅＢ３０４に送信し、その報告を上りリンク・スケジューラ３０８が処理する。上記で議論したように、データ３１２を有するインバンドでバッファ状態報告３１４を送信してもよい。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
電気通信システムにおける上りリンク・スケジューリング要求をトリガするため、改善したシステムと方法を提供することが目的である。
【課題を解決するための手段】
【００１３】
一つの側面では、本発明は、移動端末（または“ＵＥ”）から基地局にスケジューリング要求を送信する方法を提供する。幾つかの実施形態では、本方法は、基地局に送信するため利用可能となったデータに応じて、ＵＥが基地局に第一のスケジューリング要求（ＳＲ）を送信することから始まる。第一のＳＲを送信した後、ＵＥは、基地局から送信されたスケジューリング許可信号（ＳＧ）を受信する。ＳＧを受信することに応じて、ＵＥは基地局に送信バッファ状態情報を送信する。基地局へバッファ状態情報を送信した後、しかし基地局への後続のＳＲのいずれの送信に先立って、そして少なくとも幾つかのデータが基地局へ送信されるのを待っている間、ＵＥは、（１）スケジューリング要求のトリガ・イベントが起きたかどうかを判定し、もしトリガ・イベントが起きたなら、トリガ・イベントが起きたと判定することに応じて、ＵＥは、次の機会に基地局に第二のＳＲを送信するが、（２）さもなければ、トリガ・イベントが起きなかったなら、トリガ・イベントが起きなかったということを判定したことに応じて、ＵＥは、次の機会に基地局にトリガ・イベントが起きなかったということを示すメッセージを送信する。
【００１４】
幾つかの実施形態では、スケジューリング要求のトリガ・イベントが起こったかどうかを判定するステップには、（ａ）第一のＳＲを送信した後、基地局に送信するため利用可能となった追加のデータが、最初のデータより高い優先度を持つかどうかを判定すること、（ｂ）第一のＳＲを送信して以降経過した時間量が、ある閾値を超えているかどうかを判定すること、および（ｃ）送信バッファの現在のデータ量と、送信バッファにあった前の、非ゼロのデータ量との差が、ある閾値を超えているかどうかを判定すること、または（ａ）〜（ｃ）の少なくとのいずれかを含む。この実施形態、またはその他の実施形態では、スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップには、基地局に送信した送信バッファ状態情報と、送信バッファの状態に関する新しい情報とを比較することを含む。
【００１５】
幾つかの実施形態では、トリガ・イベントが起こらなかったということを示すメッセージは１ビットのメッセージであり、ＳＲもまた１ビットのメッセージである。さらに、幾つかの実施形態では、無線資源制御（ＲＲＣ）信号を通して基地局がＵＥ内に閾値を構成してもよい。さらに、幾つかの実施形態では、データがＵＥにある空の送信バッファに到達するごとに、次の利用可能な機会にＳＲを送信するよう、ＵＥを構成する。
【００１６】
もう一つの側面では、本発明は改善した移動端末に関する。幾つかの実施形態で、改善した移動端末には送信バッファとデータ・プロセッサを含む。移動端末の空の送信バッファに到達するデータに応じて、移動端末に第一のスケジューリング要求（ＳＲ）を基地局に送信させ、そして基地局からスケジューリング許可信号（ＳＧ）を受信するのに応じて、移動端末に送信バッファに関する状態情報を基地局に送信させるよう、データ・プロセッサを構成してもよい。幾つかの実施形態では、スケジューリング要求トリガ・イベントが起こったかどうかを判定し、トリガ・イベントが起こったと判定することに応じて、移動端末に第二のＳＲを次の機会に基地局に送信させ、トリガ・イベントが一つも起こらなかったと判定するのに応じて、移動端末にトリガ・イベントが起こらなかったことを示すメッセージを次の機会に基地局に送信させるように、データ・プロセッサをさらに構成してもよい。好ましくは、少なくとも幾つかの第一のデータが基地局に送信されるのを待っている間、そしてＵＥがバッファ状態情報を送信した後、しかし、基地局に任意の後続のＳＲをＵＥが送信するのに先立って、これらの三つのステップを実行する。
【００１７】
幾つかの実施形態では、改善した移動端末には、移動端末受信データの空の送信バッファに応じて、第一のＳＲを基地局に送信する手段と、基地局が送信したＳＧを受信する手段と、ＳＧを受信することに応じて、送信バッファ状態に関する状態情報を基地局に送信する手段と、スケジューリング要求トリガ・イベントが起こったかどうかを判定するトリガ・イベント検出手段と、スケジューリング要求のトリガ・イベントが起こったことを判定するのに応じて、次の機会に、第二のＳＲを基地局に送信する手段とを含む。幾つかの実施形態では、少なくとも幾つかのデータが基地局に送信されるのを待っている間、判定を実行するようトリガ・イベント検出手段を構成する。
【００１８】
もう一つの側面では、本発明は、移動端末に上りリンク資源を許可するために基地局が実行する方法に関する。幾つかの実施形態では、基地局は、第一の移動端末に上りリンク資源を配分し、それによって第一の移動端末が基地局にデータを送信できるようにし、第一の移動端末が上りリンク資源を利用している間、第二の移動端末からＳＲを受信し、ＳＲを受信することに応じて第二の移動端末に上りリンク資源を再配分し、基地局に送信するよう待っている第二の移動端末のデータの優先度に関係する情報を、第二の移動端末から受信し、それぞれの優先度情報を使用して第一の移動端末のデータの優先度と第二の移動端末のデータの優先度とを比較し、第一の移動端末が第二の移動端末より高い優先度データを持つことを判定するのに応じて上りリンク資源を第一の移動端末に再配分し、第二の移動端末から後続のＳＲを受信するが、第二の移動端末から優先度情報を受信した後かつ第二の移動端末から他の全ての優先度情報を受信する前にその後続のＳＲを受信し、後続のＳＲを受信することに応じて第二の移動端末に上りリンク資源を再配分する。
【００１９】
もう一つの側面では、本発明は改善した基地局に関する。幾つかの実施形態では、改善した基地局には、複数の移動端末と通信する手段と、端末からのバッファ状態データ送信の各々に基づいて、移動端末のうちの一つに上りリンク資源を配分てる手段と、他の端末のバッファ状態データの変化を示す単一ビットのメッセージの受信に基づいて、複数の端末のうちの他のもう一つに上りリンク資源を再配分する手段とを含む。
【００２０】
さらにもう一つの側面では、本発明は、改善した移動端末と改善した基地局とを備える電気通信システムに関する。
【００２１】
本発明の上記およびその他の側面と実施形態について、添付の図面を参照して以下に述べる。
【００２２】
本明細書に組み込み、明細書の一部を形成する添付図面は、本発明の各種の実施形態を示すものである。
【図面の簡単な説明】
【００２３】
【図１】ＳＣ−ＦＤＭＡシステムの各種のユーザに対する資源配分を概略的に示す。
【図２】ＬＴＥシステムにおける上りリンク・スケジューリングを示す。
【図３】ＵＥにデータ送信のための資源を提供する方式を示す。
【図４】ｅＮｏｄｅＢと２個のＵＥ間の改善したスケジューリング・メッセージ・フローを示す。
【図５】ｅＮｏｄｅＢと二つのＵＥ間の更なる改善したスケジューリング・メッセージ・フローを示す。
【図６ａ】、
【図６ｂ】本発明の実施形態による処理を示す。
【図７】移動端末の幾つかの構成要素を示す機能ブロック図である。
【図８】上りリンク・スケジューラの幾つかの構成要素を示す機能ブロック図である。
【図９】本発明の実施形態による処理を示すフローチャートである。
【発明を実施するための形態】
【００２４】
一つの可能なスケジューリング要求方式は、単一ビット（即ち、“信号要求ビット”）を特定の所定の値に設定（例えば、“１”に設定）した単一ビット・メッセージであるとＳＲを定義し、以下の場合にはいつでもＵＥがＳＲをスケジューラに送信するよう、ＵＥを構成することである。（１）ＵＥが送信すべきデータを持っており（例えば、ＵＥは送信バッファにデータを持っている）、かつ、（２）ＵＥが、そのデータをｅＮｏｄｅＢに送信するための上りリンク資源配分を持っていない。しかしながら、図４に示すスケジューリング・メッセージ・フローの例は、この手法の潜在的な欠点を示している。
【００２５】
図４に示す例では、２個の同期したＵＥ（即ち、ＵＥ１とＵＥ２）があり、そのいずれも最初は、データ送信のための上りリンク資源配分を持っていない、と仮定する。さらに、ＵＥは専用のＳＲチャネルを持つ、と仮定する。
【００２６】
図４に示すように、データがＵＥ１の送信バッファに到達すると、ＵＥ１は、その次のＳＲ機会を使用してスケジューラにＳＲ（例えば、“１”）を送信することにより、このイベントの通知をスケジューラに提供する。これに応じて、スケジューラはデータ送信のために幾つかの資源をＵＥ１に許可し、ＵＥ１にＳＧを送信する。これに応じて、ＵＥ１はｅＮｏｄｅＢにバッファ状態報告を送信する。ＵＥ１はまた、割り当てられたＵＬ資源に依存して、ｅＮｏｄｅＢにデータを送信することができる。
【００２７】
図４にさらに示すように、ＵＥ２が送信用データをもつ場合、ＵＥ２は、その次のＳＲ機会にＳＲ（例えば、“１”）を送信する。この例のため、ＵＥ２のデータはＵＥ１のデータより低い優先度を持つと仮定しよう。ＵＥ２が送信するＳＲを受信するのに応じて、スケジューラは、時間内のこの時点では、ＵＥ２のデータがＵＥ１のデータより低い優先度を持つことを知らないが、ＵＥ２にやみくもに幾つかの資源を許可する。ＵＥ２は割り当てを受けた資源を使用し、ＱｏＳ情報を含むバッファ状態報告と割り当てサイズに依存する幾つかのデータとを送信する。ＵＥ１及びＵＥ２それぞれが送信するバッファ状態報告を使用して、スケジューラはＵＥ１のバッファ状態とＵＥ２のバッファ状態とを比較し、その比較結果に基づいて、ＵＥ２のデータが低い優先度特質であることを比較結果が示しているため、ＵＥ１からのデータを優先する。ＵＥ１からのデータを優先するので、スケジューラはＵＥ２をそれ以上スケジュールせず、それ故、ＵＥ２がそのデータを送信すること防ぐ。このため、ＵＥ２は送信すべきデータを持つので、ＳＲ機会を持つＴＴＩのそれぞれにおいて、ＵＥ２はＳＲを送信し続けるだろう。
【００２８】
ＵＥ２が最後に送信したデータ・バッファ報告、それは、ＵＥ２が送信を待っている低い優先度のデータのみを持つという表示を報告するのであるが、その報告を信頼して、スケジューラはＵＥ２が送信するＳＲを無視する。ＵＥ２が続いて送るべき高い優先度のデータを持った後でさえ、スケジューラはこれらのＳＲを無視するが、これは、バッファ状態報告を送信することを通じて以外に、ＵＥ２にとって、高い優先度のデータを持つということをスケジューラに通知する方法がないからである。従って、幾つかの場合では、スケジューラが、ＵＥ２の送信バッファに到達している高い優先度のデータに直ちに気付かない可能性がある。
【００２９】
もし時々ＵＥ２に幾つかの上りリンク資源を許可するようスケジューラを構成するなら、この問題を回避することでき、これにより新規の高い優先度のデータを示すバッファ状態報告をスケジューラに送信する機会をＵＥ２に提供するであろう。しかしながら、もし多くのユーザがあるなら、この解決策は資源の観点から極めて高価である。もう一つの解決策は、ＳＲがデータ優先度に関する情報を含むことができるよう、１ビットから１ビット以上にＳＲを拡張することである。しかしながらこの解決策は、多くの優先度レベルがある場合は特に、ＳＲチャネルに対して重大なオーバヘッドを与える。本発明の実施形態は、これらの二つの解決策が被る不利益なしに、上記の問題を克服する。
【００３０】
本発明の実施形態は、送信バッファ状態における変化に基づく代替的なＳＲトリガ機構を定義する。そのような代替的トリガ機構で、ＳＲを１ビットから数ビットに増加させることなしに、そしてバッファ状態報告を送信するためにＵＥを周期的にスケジューリングすることなしに、上記の問題を解決することができる。
【００３１】
本発明の実施形態によれば、例えば、前に報告したこと、または前に送信したことと比較した、ＵＥの送信バッファ内容における変化のような、ある所定の条件を満足する場合のみ、ＳＲを送信するようＵＥを構成する。例えば、データがＵＥの送信バッファに到達し、そのデータが、前に報告したデータ（または送信したデータ）の優先度より高い優先度を持つ場合はいつでも、所定の条件に合致するものとできる。典型的には無線資源制御（ＲＲＣ）シグナリングを通して、ＳＲをトリガするバッファ状態の変化を構成される。
【００３２】
幾つかの実施形態では、以下の全てが正しい場合のみ、ＳＲを送信するようＵＥを構成する。（１）ＵＥは上りリンク許可を全く持たない。（２）ＵＥはｅＮｏｄｅＢに送信すべきデータを持つ。（３）確認応答があった最後のバッファ報告がＵＥにより送信されたか、または確認応答があった最後の送信がＵＥにより送信された後、バッファ状態が“変化”した。これらの実施形態では、上記のように構成したＵＥからのＳＲを無視しないよう、スケジューラを構成する。
【００３３】
幾つかの実施形態では、以下の条件の一個以上を満足する場合のみ、バッファ状態が“変化”したと考える。（１）より高い優先度のデータがバッファに到達した。（２）バッファ・サイズ増加が所定の閾値（閾値Ａ）を超える。または（３）最後のＳＲの送信以降の経過時間が所定の閾値（閾値Ｂ）を超える。通常は、ＲＲＣシグナリングを通して閾値Ａと閾値Ｂとを構成することができる。上記の規則に対する一つの例外は、データがＵＥの空のバッファに到達した場合、ＵＥは常に次のＳＲ機会にＳＲを送信すべきである、ということである。
【００３４】
上記の例では、ＵＥがスケジューラからＵＬスケジューリング許可信号を受信する場合、ＵＥが送信する通常のバッファ状態報告を通して、続いてＵＥのバッファ内容をスケジューラに気付かせる。これは、各スケジュール送信に対して連続的なバッファ報告である可能性がある。しかしながら、幾つかの実施形態では、ＵＥにバッファ状態報告を送信させるために、判定基準を使用する。このことは、もしさらなるＵＬ資源をＵＥに許可しないなら、最後に認知したバッファ報告を更新するであろう、ということを意味する。また、ＵＥが正規のバッファ報告を送信しない場合、上記のＳＲトリガ規則の変形を使用することも可能である。
【００３５】
例えば、ＵＥが無線ベアラ間で厳格な優先度（即ち、より低い優先度の無線ベアラからのデータの前に、常により高い優先度の無線ベアラからのデータを送信する）を採用すると仮定すると、送信したものより高い優先度のデータは送信バッファには何もないということを、スケジューラは理解するであろう。そのような状況では、以下の条件の１個以上を満足する場合のみ、バッファ状態が“変化”したと考える。（１）より高い優先度のデータがバッファに到達した。または（２）最後のＳＲを送信して以降の経過時間閾値（閾値Ｂ）を超える。前と同じように、本規則に対する一つの例外は、データがＵＥの空のバッファに到達した場合、ＵＥは常にその次のＳＲ機会にＳＲを送信すべきである、ということである。通常は、ＲＲＣシグナリングを通して閾値Ｂを構成する。
【００３６】
上記の例の幾つかの代替案と組合せが構成可能である。ＵＥが送信すべきデータをもつ場合はいつでもＳＲを送信するようＵＥを構成する代わりに、送信すべきデータを持ち、かつ幾つかのその他のイベントが生じた場合のみ、ＳＲを送信するようＵＥを構成する、ということにおける改善を本発明は提供するものである（例えば、最後のＳＲを送信した後ある時間が経過した、または、データまたは状態報告の最近の送信の後バッファのデータ量が少なくともある量だけ増加した、または、データを受信する直前に送信バッファが空であった）。
【００３７】
幾つかの実施形態では、ＳＲ送信機会の前に、ＵＥがｅＮｏｄｅＢからスケジューリング許可信号を得た時はいつでも、トリガを受けたが未送信のＳＲを取り消すべきである。これらの場合には、ＵＥはまず高い優先度のデータを送り、詳細なバッファ状態報告を選択的に含めるであろう。いずれの場合でも、ｅＮｏｄｅＢは、スケジューリング許可信号を得ることなしにでも変化に気付く。
【００３８】
ここで図５を参照し、図５は、本発明の実施形態によるシステムのメッセージ・フローを示すが、そのシステムには２個のＵＥ（ＵＥ１とＵＥ２）を含む。ＵＥ１がその送信バッファに高い優先度のデータを受信した場合から、図示のメッセージ・フローを開始する。図５に示すように、このイベントに応じて、ＵＥ１はその次のＳＲ機会に、ｅＮｏｄｅＢにＳＲを送信する。
【００３９】
これに応じて、ｅＮｏｄｅＢはＵＥ１にＳＧを送信する。本ＳＧに応答して、ＵＥ１は、ＵＥ１の送信バッファ内のデータの高い優先度を示すバッファ報告を送信してもよい。ＵＥ１がバッファ報告を送信した後のいつか、ＵＥ２はその送信バッファのデータを受信してもよく、そのイベントにより、ＵＥ２はその次のＳＲ機会にＳＲを送信させる。
【００４０】
この例のために、ＵＥ２のデータはＵＥ１のデータより低い優先度を持つと仮定しよう。ＵＥ２が送信するＳＲの受信に応じて、時間内のこの時点で、ＵＥ２のデータはＵＥ１のデータより低い優先度を持つということを知らないｅＮｏｄｅＢは、ＵＥ２に何らかの資源をやみくもに許可する。ＥＵ２は割り当てられた資源を使用して、ＱｏＳ情報を含むバッファ状態報告と割り当てサイズに依存する幾つかのデータとを送信する。ＵＥ２のデータの優先度の低さを示すバッファ状態報告の基づき、ｅＮｏｄｅＢはＵＥ１からのデータを優先させ、それ故、ＵＥ２をこれ以上スケジュールせず、これによって、ＵＥ２がそのデータを送信するのを防ぐ（例えば、バッファ報告を含む送信に対するハイブリッド型自動反復要求（ＨＡＲＱ）ＡＣＫをＵＥ２に送信し、ＵＥ２は最後にＡＣＫした報告をストアする）。  しかしながら、各後続のＳＲ機会にＳＲを送信し続けるよりはむしろ、図４に示すように、一個以上のある所定のイベントが起こるまでＳＲを送信しないよう、ＵＥ２を構成する（例えば、図５に示すように、ＵＥ２はｅＮｏｄｅＢに、 “１”の代わりに“０”の値に設定したビットを有する信号要求ビットを、イベントの一つが起こるまで送信してもよい）。従って、後続の各ＳＲ機会に先立って、（高い優先度のデータの受信のような）一個以上のあるイベントが起こったかどうかをチェックするようＵＥ２を構成し、その結果、もしそのような一つのイベントが起こった場合、ＵＥ２はその次のＳＲ機会にＳＲを送信することができる。
【００４１】
この例では、ＵＥ２がバッファ状態報告を送信した後のいつか、高い優先度のデータがＵＥ２の送信バッファに到達する。ＵＥ２はこのイベントを検出し、それに応じて、ｅＮｏｄｅＢにＳＲ（例えば、“１”）を送信する。送信バッファの状態を時間内の幾つかの前の時点で示す最後に確認応答されたバッファ状態報告と、送信バッファの現在の状態を示す新しく生成したバッファ状態情報とを比較することにより、このイベントを検出するようＵＥ２を構成してもよい。ＵＥ２が今やより高い優先度のデータを持つことを示す新しいバッファ状態報告を、ｅＮｏｄｅＢがＵＥ２から受信していないとしても、ＳＲを無視するのとは対照的に、ＵＥ２に上りリンク資源を許可することによりＳＲに応答するよう、ｅＮｏｄｅＢを構成する。その結果、この方法で、本発明の実施形態は図４に関連して議論した問題を解決する。
【００４２】
ここで図６ａを参照して、図６ａは、本発明の幾つかの実施形態により、ＵＥが実行する手順６００を示すフローチャートである。手順６００は、ステップ６０２で開始してもよい。手順６００では、ＵＥは最初、ｅＮｏｄｅＢに送信すべきデータを全く持っていない（例えば、ＵＥの送信バッファは最初、空である）と仮定し、従って、ステップ６０２では、送信バッファにデータを収納するまでＵＥは待っている。ＵＥがｅＮｏｄｅＢに送るべきデータを持つことに応じて、ＵＥはｅＮｏｄｅＢにＳＲを送信する（ステップ６０４）。ステップ６０６で、ＵＥはｅＮｏｄｅＢからＳＲを受信する。ステップ６０８で、ＵＥはｅＮｏｄｅＢが割り当てた資源を使用し、割り当てた資源に依存してバッファ状態報告および幾つかのデータまたはそのいずれかをｅＮｏｄｅＢに送信する。ステップ６０９で、ＵＥは、現在その送信バッファにあるデータ量を示す値を記録してもよい。
【００４３】
ステップ６１０では、ＵＥは、バッファ状態報告を含む送信のためのＨＡＲＱ  ＡＣＫを、ｅＮｏｄｅＢから受信する。ステップ６１２で、ＵＥは、最後の確認応答（ＡＣＫ）したバッファ状態報告（即ち、ステップ６０８で送信した報告）を格納する。ステップ６１４で、ＵＥは、ｅＮｏｄｅＢに送るべきデータを持っているかどうか判定する（例えば、ＵＥはその送信バッファが空かどうかを判定する）。もし送信すべきデータを持っていない（例えば、バッファが空である）なら、手順６００はステップ６０２に戻って進んでもよく、そうでなければ、それはステップ６１６に進んでもよい。
【００４４】
ステップ６１６で、ＵＥは、ＳＲトリガ・イベントが起こったかどうかを判定する。もし起こったなら、手順６００はステップ６０４に戻って進み、そうでなければ、手順６００はステップ６１８に進んでもよい。ステップ６１８で、まさしく次の送信機会に、ＵＥはｅＮｏｄｅＢに、トリガ・イベントが起こらなかったことを示すメッセージを送信する（例えば、ＵＥはｅＮｏｄｅＢに、ビットの値を“０”に設定した１ビットのメッセージを送信する）。ステップ６１８の後、手順６００はステップ６１６に戻って進んでもよい。
【００４５】
ここで図６ｂを参照して、図６ｂは本発明の幾つかの実施形態による、トリガ・イベントが起こったかどうかを判定する手順を示す。即ち、図６ｂは、手順６００のステップ６１６を実行する場合に実行してもよいステップを示す。
【００４６】
ここで図６ｂに示すように、手順はステップ６５６で開始してもよく、ＵＥは、時間内の特定の時点以降、送信バッファに新しいデータが到達したかどうかを判定する。例えば、ＵＥは、最後のバッファ状態報告を発生して以降、または、ＵＥがステップ６１６を実行した最後の時間以降、新しいデータが送信バッファに到達したかどうかを判定してもよい。もしＵＥが、新しいデータが到達したと判定すると、手順はステップ６５８に進んでもよく、そうでない場合は、それはステップ６６２に進んでもよい。
【００４７】
ステップ６５８で、ＵＥは、新しいデータが到達した時、新しいデータが送信バッファにあったデータより高い優先度を持つかどうかを判定する。ＵＥは、ステップ６１２でストアしたバッファ状態報告の情報と、送信バッファの現在の状況の状態を反映する、新しく生成した情報とを比較することにより、これを判定する。もし新しいデータがより高い優先度を持つなら、手順はステップ６０４に進んでもよく、そうでなければ、手順はステップ６６０に進んでもよい（即ち、ＵＥはえＮｏｄｅＢにＳＲを送信する）。
【００４８】
ステップ６６０で、ＵＥは、送信バッファに現在あるデータ量と時間内の前の時点で送信バッファにあったデータ量との差が、ある閾値を超えるかどうかを判定する。例えば、ステップ６６０で、ＵＥは、送信バッファに現在あるデータ量を表わす値とステップ６０９で記録した値との差を見付け出し、その差をその閾値値と比較してもよい。もしその差が閾値と等しいか、それを超えているなら、手順はステップ６０４に進んでもよく、そうでなければ手順はステップ６６２に進んでもよい。
【００４９】
ステップ６６２で、ＵＥは、最後のＳＲを送信して以降経過した時間量がある閾値を越えるかどうかを判定する。もしそうなら、手順はステップ６０４に進んでもよく、そうでなければ、手順はステップ６１８に進んでもよい。
【００５０】
ここで、起こる可能性のあるエラー・ケースについて検討する。
【００５１】
エラー・ケース１：この第一のエラーの場合では、（ａ）ｅＮｏｄｅＢがＳＲを間違えて解釈し（例えば、信号要求ビットが“１”の変わりに“０”に設定されることを、ｅＮｏｄｅＢが検出する）、資源を許可しないか、または、（ｂ）ＵＥが資源割当メッセージをデコードできないか、のどちらかである。この状況に対処するため、ＵＬ許可を得るまで（即ち、データおよびバッファ状態報告またはそのいずれかを送信する機会をＵＥに与えるまで）、全てのＳＲの機会にＳＲを送信するようＵＥを構成する。
【００５２】
エラー・ケース２：第二のエラーの場合では、ｅＮｏｄｅＢは、バッファ状態報告または最初のデータ送信を含むメッセージをデコードし損なう。ＨＡＲＱ再送信を待つことは、過度の遅延の原因となるであろう。スケジューラはＵＬ許可を、（１）もし各ＵＬ送信でバッファ報告を送信するなら信頼できる報告を得るまで、あるいは、（２）もしＳＲに対するものと類似の判断基準でバッファ報告がトリガされているなら（ＵＥは、最近確認応答された報告と比較したバッファ変化を持ち、信頼できる報告を得るまで報告を送信し続けるであろう）、または、（３）もし何のバッファ報告もトリガされないなら、ｅＮｏｄｅＢがデコードできるまで新しいデータを送信する。
【００５３】
エラー・ケース３：第三のエラーの場合では、ｅＮｏｄｅＢは、バッファ報告または最初のデータ送信を含むメッセージを検出するが、ＵＥは否定応答（ＮＡＣＫ）としてＨＡＲＱ  ＡＣＨを間違えて解釈する。この状況では、ＵＥは通常のＨＡＲＱ再送信を実行するが、ｅＮｏｄｅＢは更なる送信試行を全く期待しないので、再送信は失敗する。送信試行の最大回数の後、ＵＥは停止する。もし幾つかの後続の送信が成功したなら、ＵＥはもう一つのスケジューリング要求を実行する必要はない。ケース２のエラー処理で、もし送信が失敗したなら、ｅＮｏｄｅＢはもう一つの許可を出したであろう。
【００５４】
ここで図７を参照して、図７は、本発明の実施形態によるＵＥ７００の幾つかの構成要素の機能ブロック図である。図７に示すように、ＵＥには、ｅＮｏｄｅＢに送信すべきデータをバッファする送信バッファ７０２と、最後に送信されたバッファ状態報告をストアするストレージ・ユニット７０４と、ＳＲを送信すべきかまたは送信すべききでないかどうかを判定するため（即ち、幾つかあるステップの中で、手順６００のステップ６１６−６２２を実行するよう、ソフトウエア７０８を構成してもよい）、およびＳＲを送信すべきと判定した場合はＳＲを送信させるためソフトウエア７０８を実行するデータ・プロセッサ７０６と、ｅＮｏｄｅＢにデータを無線で送信する送信器と、その他の要素とを含む。
【００５５】
ここで図８を参照すると、図８は、本発明の実施形態による上りリンク資源スケジューラ２０２の機能ブロック図である。図８に示すように、スケジューラ２０２には、バッファ状態報告８１０をストアするストレージ・ユニット８０４と、ソフトウエア８０８を実行するデータ・プロセッサ８０６とを含む。データ・プロセッサ８０６が実行する場合、ソフトウエア８０８がスケジューラ２０２を上記のように機能させるようソフトウエア８０８を構成する。即ち、例えば、ソフトウエア８０８はスケジューラ２０２に、ｅＮｏｄｅＢ２４０と通信するため、ＵＥが試行するバッファ状態の比較に基づき、上りリンク資源をスケジュールさせてもよく、そして各ＳＲに応答させてもよい。図示していないが、データ・プロセッサ８０６は、スケジューラがＵＥと通信できる送信手段（例えば、送信バッファおよび送信器またはそのいずれか、または類似のもの）に連結している。
【００５６】
ここで図９を参照して、図９は本発明の実施形態により構成した、基地局が実行する手順９００を示すフローチャートである。図９に示しように、ステップ９０２で基地局は上りリンク資源を第一のＵＥ（ＵＥ１）に配分し、これにより、ＵＥ１が基地局にデータを送信することを可能にする。ステップ９０４で、ＵＥ１が上りリンク資源を利用している間、基地局は第二のＵＥ（ＵＥ２）からＳＲを受信する。ステップ９０６で、ＳＲを受信することに応じて、基地局は上りリンク資源をＵＥ２に再割り当てする。ステップ９０８で、基地局は、基地局への送信を待っているＵＥ２のデータの優先度に関係する情報を、ＵＥ２から受信する。ステップ９１０で、各々の優先度情報を使用して、基地局は、ＵＥ１のデータの優先度とＵＥ２のデータの優先度とを比較する。ステップ９１２で、ＵＥ１がＵＥ１より高い優先度のデータを持つと判定することに応じて、基地局はＵＥ１に上りリンク資源を再割り当てする。ステップ９１４で、基地局はＵＥ２から後続のＳＲを受信するが、ＵＥ２から優先度情報を受信した後、およびＵＥ２から任意の他のデータの優先度情報を受信する前、後続のＳＲを受信する。ステップ９１６で、後続のＳＲを受信することに応じて、基地局は上りリンク資源をＵＥ２に再割り当てする。
【００５７】
本発明の実施形態の一つの利点は、スケジューリング要求チャネルのＵＥ電力消費量を減少させながら（ＯＮ／ＯＦＦキーイングを使用する場合）、端末のバッファ状態を選択的に更新することと、単一ビットのＳＲでも適当なサービス品質（ＱｏＳ）を認知することとを、基地局（ｅＮｏｄｅＢ）のスケジューラに提供する、ということである。
【００５８】
本発明の各種の実施形態／変形を上記で述べたが、例としてのみであり、限定するものでないということでそれらを提供した、と理解すべきである。それ故、本発明の幅と範囲は、上記の典型的な実施形態のいずれによっても限定されるべきではない。さらに、述べてはいないが、上記の実施形態は全て相互に排他的ではない。それ故、本発明は、各種の実施形態の特徴の任意の組合せおよび統合またはそのいずれかを含めてもよい。
【００５９】
加えて、図面で示し、上記で説明した手順は、ステップのシーケンスとして示しているが、これは図示のためにのみ行ったことである。従って、幾つかのステップを追加してもよく、幾つかのステップを削除してもよく、ステップの順序を再構成してもよい、ということを考慮している。
【図１】
2010530707.tif 000003
【図２】
2010530707.tif 000004
【図３】
2010530707.tif 000005
【図４】
2010530707.tif 000006
【図５】
2010530707.tif 000007
【図６ａ】
2010530707.tif 000008
【図６ｂ】
2010530707.tif 000009
【図７】
2010530707.tif 000010
【図８】
2010530707.tif 000011
【図９】
2010530707.tif 000012
【手続補正書】
【提出日】平成22年2月18日(2010.2.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
移動端末（３０２）から基地局（３０４）にスケジューリング要求（３０６）を送信する方法であって、
（ａ）移動端末（３０２）から基地局（３０４）への送信に利用可能となる第一のデータに応じて、前記移動端末（３０２）から前記基地局（３０４）に第一のスケジューリング要求（ＳＲ）（３０６）を送信するステップと、
（ｂ）前記第一のＳＲ（３０６）を送信後、前記基地局（３０４）から送信したスケジューリング許可信号（ＳＧ）（３１０）を前記移動端末（３０２）で受信するステップと、
（ｃ）前記ＳＧ（３１０）の受信に応じて、前記移動端末（３０２）から前記基地局（３０４）に送信バッファ状態情報（３１４）を送信するステップと、
（ｄ）少なくとも幾つかの第一のデータが前記基地局（３０４）に送信されるのを待っている間において、バッファ状態情報（３１４）を送信後、かつ前記基地局（３０４）に任意の後続のＳＲ（３０６）を送信するに先立って、
（ｄ１）スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップと、
（ｄ２）トリガ・イベントが起こったなら、トリガ・イベントが起こったとの判定に応じて、次の機会に、前記基地局（３０４）に第二のＳＲ（３０６）を送信するステップと
をさらに実行するステップと
を有することを特徴とする方法。
【請求項２】
前記スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップには、前記基地局（３０４）に送信した送信バッファ状態情報（３１４）と送信バッファの状態に関する新しい情報とを比較するステップを有することを特徴とする請求項１に記載の方法。
【請求項３】
前記スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップには、前記基地局（３０４）に移動端末（３０２）からの送信に利用可能な第二のデータが、前記第一のデータより高い優先度を持つかどうかを判定するステップを有し、
前記第一のＳＲ（３０６）を送信した後、前記第二のデータが基地局（３０４）への送信に利用可能となったことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップには、前記第一のＳＲ（３０６）を送信して以降経過した時間が或る閾値を超えたかどうかを判定するステップを有することを特徴とする請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
前記スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップには、送信バッファの現在のデータ量と、前記送信バッファにあった、以前の非ゼロのデータ量との差が或る閾値を超えたかどうかを判定するステップを有することを特徴とする請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記スケジューリング要求トリガ・イベントが起こったかどうかを判定するステップが、
（ａ）前記第一のＳＲ（３０６）を送信した後に前記基地局（３０４）への送信に利用可能となった第二のデータが、前記第一のデータより高い優先度を持つかどうかを判定するステップと、
（ｂ）前記第一のＳＲ（３０６）を送信して以降経過した時間が或る閾値を超えたかどうかを判定するステップと、
（ｃ）送信バッファの現在のデータ量と、前記送信バッファにあった、以前の非ゼロのデータ量との差がある閾値を超えたかどうかを判定するステップと
を有することを特徴とする請求項１に記載の方法。
【請求項７】
前記スケジューリング要求トリガ・イベントが起こったかどうかを判定する前記ステップが、
（ａ）前記第一のＳＲ（３０６）を送信した後に前記基地局（３０４）への送信に利用可能となった第二のデータが、前記第一のデータより高い優先度を持つかどうかを判定するステップと、
（ｂ）前記第一のＳＲ（３０６）を送信して以降経過した時間が或る閾値を超えたかどうかを判定するステップと
を有する特徴とする請求項１に記載の方法。
【請求項８】
前記ＳＲ（３０６）が１ビットのメッセージであることを特徴とする請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
前記閾値は、前記基地局において、無線資源制御（ＲＲＣ）シグナリングを通して前記基地局（３０４）により構成されることを特徴とする請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
データが前記移動端末（３０２）の空の送信バッファに到達するごとに、次の利用可能な機会にＳＲ（３０６）を送信するステップをさらに有することを特徴とする請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
前記移動端末（３０２）から送信バッファ状態情報（３１４）を前記基地局（３０４）へ送信し、移動端末（３０２）に確認応答を格納した後、前記基地局（３０４）から送信したＨＡＲＱ  ＡＣＫを前記移動端末（３０２）で受信するステップをさらに有することを特徴とする請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
送信バッファ（７０２）と、
データ・プロセッサ（７０６）とを備え、
前記データ・プロセッサ（７０６）を、
（ａ）移動端末（３０２）の空の送信バッファに到達することに応じて、移動端末（３０２）に、第一のスケジューリング要求（ＳＲ）（３０６）を基地局（３０４）に送信させ、
（ｂ）前記基地局（３０４）からスケジューリング許可信号（ＳＧ）（３１０）を受信することに応じて、前記移動端末（３０２）に、送信バッファ状態情報（３１４）を前記基地局（３０４）に送信させ、
（ｃ）少なくとも幾つかの第一のデータが前記基地局（３０４）に送信されるのを待っている間において、バッファ状態情報（３１４）を送信後、かつ前記基地局（３０４）に任意の後続のＳＲを送信するのに先立って、（ｃ１）スケジューリング要求トリガ・イベントが起こったかどうかを判定し、（ｃ２）トリガ・イベントが起こったとの判定に応じて、次の機会に前記移動端末（３０２）に第二のＳＲ（３０６）を基地局（３０４）に送信させるというステップ（ｃ１）−（ｃ２）を実行する
ように構成したことを特徴とする移動端末（３０２）。
【請求項１３】
前記基地局（３０４）に送信した送信バッファ状態情報（３１４）を送信バッファの状態に関する新しい情報と比較することにより、前記スケジューリング要求トリガ・イベントが起こったかどうかを判定するようデータ・プロセッサ（７０６）を構成することを特徴とする請求項１２に記載の移動端末（３０２）。
【請求項１４】
前記第一のＳＲ（３０６）を送信した後、前記基地局（３０４）への送信に利用可能となった第二のデータが前記第一のデータより高い優先度を持つかどうかを判定することにより、前記スケジューリング要求トリガ・イベントが起こったかどうかを判定するようデータ・プロセッサ（７０６）を構成することを特徴とする請求項１２または１３に記載の移動端末（３０２）。
【請求項１５】
前記第一のＳＲ（３０６）を送信して以降経過した時間が或る閾値を超えたかどうかを判定することにより、前記スケジューリング要求トリガ・イベントが起こったかどうかを判定するようデータ・プロセッサを構成することを特徴とする請求項１２乃至１４のいずれか一項に記載の移動端末（３０２）。
【請求項１６】
送信バッファ（７０２）の現在のデータ量と、送信バッファ（７０２）にあった、以前の非ゼロのデータ量との差が或る閾値を超えたかどうかを判定することにより、前記スケジューリング要求トリガ・イベントが起こったかどうかを判定するようデータ・プロセッサ（７０６）を構成することを特徴とする請求項１２乃至１５のいずれか一項に記載の移動端末（３０２）。
【請求項１７】
トリガ・イベントが起こらなかったことを示すメッセージが１ビットのメッセージであることを特徴とする請求項１２乃至１５のいずれか一項に記載の移動端末（３０２）。
【請求項１８】
前記ＳＲ（３０６）が１ビットのメッセージであることを特徴とする請求項１２乃至１７のいずれか一項に記載の移動端末（３０２）。
【請求項１９】
（ａ）データを受信する移動端末（３０２）の空の送信バッファに応じて、基地局（３０４）に第一のスケジューリング要求（ＳＲ）（３０６）を送信する手段と、
（ｂ）前記基地局（３０４）から受信したスケジューリング許可信号（ＳＧ）（３１０）を受信する手段と、
（ｃ）前記ＳＧ（３１０）を受信することに応じて、送信バッファ状態情報（３１４）を前記基地局（３０４）に送信する手段と、
（ｄ）スケジューリング要求トリガ・イベントが起こったかどうかを判定するためのトリガ・イベント検出手段（７０６）であって、前記トリガ・イベント検出手段（７０６）は、少なくとも幾つかのデータが前記基地局（３０４）に送信されるのを待っている間、判定を実行するよう構成されたトリガ・イベント検出手段（７０６）と、
（ｅ）前記スケジューリング要求トリガ・イベントが起こったとの判定に応じて、次の機会に第二のＳＲ（３０６）を前記基地局（３０４）に送信する手段と
を備えることを特徴とする移動端末（３０２）。
【請求項２０】
前記トリガ・イベント検出手段（７０６）には、前記基地局（３０４）に送信された送信バッファ状態情報（３１４）と送信バッファの状態に関する新しい情報とを比較する手段（７０８）を備えることを特徴とする請求項１９に記載の移動端末（３０２）。
【請求項２１】
前記トリガ・イベント検出手段（７０６）には、前記移動端末（３０２）から前記基地局（３０４）への送信に利用可能な第二のデータが、第一のデータより高い優先度を持つかどうかを判定する手段（７０８）を備え、
前記第一のＳＲ（３０６）を送信した後、前記第二のデータが基地局（３０４）への送信に利用可能となったことを特徴とする請求項１９または２０に記載の移動端末（３０２）。
【請求項２２】
トリガ・イベント検出手段（７０７）には、前記第一のＳＲ（３０６）を送信して以降経過した時間が、或る閾値を超えたかどうかを判定する手段（７０８）を備えることを特徴とする請求項１９乃至２１のいずれか一項に記載の移動端末（３０２）。
【請求項２３】
前記トリガ・イベント検出手段（７０７）には、送信バッファの現在のデータ量と送信バッファにあった、以前の非ゼロのデータ量との差が或る閾値を超えたかどうかを判定する手段（７０８）を備えることを特徴とする請求項１９乃至２２のいずれか一項に記載の移動端末（３０２）。
【請求項２４】
移動端末（３０２）に上りリンク資源を許可するために基地局（３０４）が実行する方法であって、
第一の移動端末（３０２）に上りリンク資源を割り当て、それによって前記第一の移動端末（３０２）が前記基地局（３０４）にデータを送信可能となるステップと、
前記第一の移動端末（３０２）が上りリンク資源を利用している間、第二の移動端末（３０２）からＳＲ（３０６）を受信するステップと、
前記ＳＲ（３０６）を受信することに応じて、前記第二の移動端末（３０２）に上りリンク資源を再割り当てするステップと、
前記基地局（３０４）に送信されるのを待っている、前記第二の移動端末のデータの優先度に関係する情報を、前記第二の移動端末（３０２）から受信するステップと、
それぞれの優先度情報を使用して、前記第一の移動端末のデータの優先度と前記第二の移動端末のデータの優先度とを比較するステップと、
前記第一の移動端末（３０２）が前記第二の移動端末（３０２）より高い優先度を持つことを判定するステップに応じて、前記第一の移動端末（３０２）に上りリンク資源を再配分するステップと、
前記第二の移動端末（３０２）から後続のＳＲ（３０６）を受信するステップと、
前記第二の移動端末（３０２）から優先度情報を受信した後で、前記第二の移動端末（３０２）からその他の任意のデータの優先度情報を受信する前に、後続のＳＲ（３０６）を受信するステップと、 
前記後続のＳＲ（３０６）の受信に応じて、前記第二の移動端末（３０２）に上りリンク資源を再割り当てするステップと
を有することを特徴とする方法。
【請求項２５】
前記第一の移動端末（３０２）が前記第二の移動端末（３０２）より高い優先度のデータを持つことの判定に応じて前記第一の移動端末（３０２）に上りリンク資源を再割り当てした後、前記第二の移動端末（３０２）から後続のＳＲ（３０６）を受信するのに先立って、前記第二の移動端末（３０２）から複数のメッセージを受信するステップをさらに有し、
前記複数のメッセージは各々、前記第二の移動端末（３０２）がスケジューリング要求トリガ・イベントを検出しなかったことを示すことを特徴とする請求項２４に記載の方法。
【請求項２６】
複数の移動端末（３０２）と通信する手段と、
端末からの各バッファ状態データ送信に基づき、前記移動端末（３０２）の一つに上りリンク資源を配分する手段（９０６）と、
他の端末のバッファ状態データの変化を示す単一ビットのメッセージの受信に基づき、複数の端末のもう一つに上りリンク資源を再割り当てする手段（９０６）と
を備えることを特徴とする基地局（３０４）。
【請求項２７】
請求項１２乃至２３のいずれか一項に記載の移動端末（３０２）を備えることを特徴とする通信システム。
【請求項２８】
請求項２６に記載の基地局（３０４）をさらに備えることを特徴とする請求項２７に記載の通信システム。
【国際調査報告】
2010530707.tif 000013
2010530707.tif 000014
2010530707.tif 000015
2010530707.tif 000016