JP2012526450A

JP2012526450A - スケジューリング要求のトリガのハンドリング

Info

Publication number: JP2012526450A
Application number: JP2012509763A
Authority: JP
Inventors: エーステルガード、ジェシカ; スタッティン、マグナス; ペルティエール、ギスライン
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2009-05-05
Filing date: 2010-01-25
Publication date: 2012-10-25
Anticipated expiration: 2030-01-25
Also published as: PL2428091T3; CA2760962A1; IL215207A0; NZ595244A; US20150063278A1; US10375721B2; TW201116122A; EP2428091A4; PL3681234T3; US8913565B2; IL215207A; PL3094148T3; WO2010128927A1; DK2428091T3; PT3094148T; BRPI1014593A2; CN104320857B; ES2891586T3; EP3094148B1; HK1169540A1

Abstract

スケジューリング要求のトリガをハンドリングするユーザ機器における方法が提供される。ユーザ機器はバッファを備える。バッファに到着する、基地局に送信されるデータを受け取った（５０１）後に、ユーザ機器は、スケジューリング要求のトリガを生成する（５０３）。スケジューリング要求のトリガは、取り消されるまで保留され、到着したデータにより直接的にまたは間接的にトリガされる。スケジューリング要求のトリガの生成をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、スケジューリング要求の生成をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、ユーザ機器は、保留されているスケジューリング要求のトリガを取り消す（５０４）。
【選択図】図５

Description

本発明は、ユーザ機器における方法および構成に関する。具体的には、本発明は、スケジューリング要求のトリガをハンドリングすることに関する。

無線通信システムとも呼ばれる典型的なセルラー無線システムでは、モバイル端末および／または無線端末としても知られるユーザ機器（ＵＥ）が、無線アクセスネットワーク（ＲＡＮ）を介して１つ以上のコアネットワークに通信する。ユーザ機器は、「セルラー方式」電話としても知られるモバイル電話、およびモバイル端末等の無線のケイパビリティを伴うラップトップ等の移動局またはユーザ機器ユニットであってもよい。したがって、ユーザ機器は、例えば、携帯用の、小型の、手持ちできる、コンピュータに含まれる、または車載のモバイル装置であって、無線アクセスネットワークで音声および／またはデータを伝達するモバイル装置であってもよい。

無線アクセスネットワークは、無線基地局（ＲＢＳ）等の基地局が各セルエリアにサービスを提供するようにしながら、セル領域に分割される地理的な領域をカバーする。上記基地局は、いくつかのネットワークでは、「ｅＮＢ」、「ＮｏｄｅＢ」または「Ｂｎｏｄｅ」とも呼ばれ、本明細書では基地局と呼ばれる。セルは、基地局サイトにおける無線基地局装置により無線カバレッジが提供される地理的な領域である。基地局は、無線周波数上で動作するエアインターフェースを通して、当該基地局の範囲内のユーザ機器ユニットと通信する。

２００８年末において、３ＧＰＰのＬＴＥ（Long Term Evolution）標準の最初のリリースであるリリース８が最終決定され、リリース９がその時点で進行中である。Ｅ−ＵＴＲＡ（Evolved Universal Terrestrial Radio Access）は、ＬＴＥにおいて使用されるエアインターフェースである。

無線通信システムにおいて、無線アップリンク（ＵＬ）は、ユーザ機器から基地局への伝送路であり、無線ダウンリンクは、基地局からユーザ機器への伝送路である。ＬＴＥのリリース８では、既存のデータよりもより高い優先度の新たなＵＬデータ、または先行するデータがない場合のいずれかの優先度の新たなデータの、ＵＥのバッファへの到着は、いわゆるレギュラーバッファ状態報告（Buffer Status Report：ＢＳＲ）をトリガする（trigger）。これには付帯条件がある。例えば、論理チャネルグループ（ＬＣＧ）に属する論理チャネルについてのデータのみが考慮される。また、「新たなＵＬデータの到着」は、ＵＬデータが無線リンクコントローラ（ＲＬＣ）エンティティまたはパケットデータコンバージェンスプロトコル（ＰＤＣＰ）エンティティで送信可能になる場合として定義される。ＰＤＣＰは、ＲＬＣエンティティの上位層である。

しかしながら、基本的な考え方は、新たなＵＬデータの到着がレギュラーＢＳＲをトリガすることの中でとらえられる。そして、レギュラーＢＳＲが、スケジューリング要求（scheduling request：ＳＲ）をトリガする。ＳＲのトリガ（trigger）は、ＳＲを基地局に伝達させる。そして、基地局は、送信したい新たなデータをユーザ機器が有することを通知される。ＳＲは、ユーザ機器の予め割り当てられた、物理アップリンク制御チャネル（ＰＵＣＣＨ）上のスケジューリング要求のリソース上で送信され、したがってユーザ機器に専用のリソールで送信されるので専用ＳＲ（Ｄ−ＳＲ）として知られ、または、物理ランダムアクセスチャネル（ＰＲＡＣＨ）上で送信され、したがってランダムアクセスＳＲ（ＲＡ−ＳＲ）として知られる。両方のケースで、ＳＲを送信するための機会に関連付けられる一定の周期性がある。これは、当該機会が利用可能になるまでユーザ機器は待機しなければならないことを意味する。

基地局がＤ−ＳＲを受信すると、基地局は典型的にはＵＬ許可（grant）を発行する。ユーザ機器は、上記許可上で送信する場合に、バッファのサイズを表すいわゆるＢＳＲ媒体アクセス制御（ＭＡＣ）制御要素の形でＢＳＲを含むＭＡＣパケットデータユニット（ＰＤＵ）を送信する。ＢＳＲは、ＢＳＲＭＡＣ制御要素を含むＭＡＣパケットデータユニット（ＰＤＵ）が生成された後に、バッファ状態を反映するように強制される。全てのデータがＭＡＣＰＤＵに適合できるが、当該データに加えてバッファ状態報告のための十分な余地がない場合を除き、ＢＳＲのトリガがＭＡＣＰＤＵの作成時にユーザ機器において保留されていれば、ＢＳＲは常に含まれる。

ユーザ機器のバッファのサイズが基地局に報告されると、ユーザ機器がどのくらいのデータを送信しなければならないかは基地局にとって既知であるので、ユーザ機器が追加のＳＲを送信する必要はない。したがって、ユーザ機器が次のＤ−ＳＲの機会にいずれかのＤ−ＳＲを送信しないように、ＳＲのトリガはユーザ機器において取り消されることが可能である。

以下では、以下の用語が使用されることに留意する。

「新たなデータの到着」という用語は、レギュラーＢＳＲをトリガするための全ての付帯条件が満たされた上でのユーザ機器のバッファにおける新たなＵＬデータの到着を示すために使用される。

「許可の受信」という用語は、新たな信号のためのアップリンク共有チャネル（ＵＬ−ＳＣＨ）のリソースについての物理ダウンリンク制御チャネル（ＰＤＣＣＨ）の許可の受信を示すために使用される。

「データの送信」という用語は、新たな信号のために利用可能にされたＵＬ−ＳＣＨリソース上でのＵＬデータの送信を示すために使用される。

「ＳＲ」および「スケジューリング要求」という用語は、ＰＵＣＣＨ上のＤ−ＳＲのシグナリングを示すために使用される。

「ＳＲのトリガ」および「スケジューリング要求のトリガ」という用語は、保留されている（pending）ＳＲを示すために使用される。

「バッファ状態報告が第１のデータを報告する（account for）」等の表現が使用される場合に、それは、バッファ状態報告が含まれる信号が受信された後の第１のデータの残りの何でもバッファ状態報告が反映することを意味する。

これまでのところ、ＳＲは取り消されるまで保留されているとみなされる、すなわちＳＲの送信をトリガするＳＲのトリガは取り消されるまで保留されているとみなされる、ということが決定される。ＳＲのトリガは、第１の送信時間間隔（ＴＴＩ）候補の中で取り消され、当該ＴＴＩで、新たな送信のためのＵＬ−ＳＣＨのリソースが許可される。ＴＴＩは、サブフレームとしても知られる。

さらに、ＵＬ−ＳＣＨのリソースがこのＴＴＩの中で新たな送信に利用可能である場合に、ＰＤＣＣＨの許可の受信時に、またはＵＬ−ＳＣＨのリソースが利用可能であったＴＴＩで、ＵＬ−ＳＣＨリソースがいつ許可されたが不明確であると考えられたため、全ての保留されているＳＲが取り消されるべきである、ということが最近決定された。説明（clarification）では、ＳＲはＵＬ−ＳＣＨリソースが利用可能であるＴＴＩの中で取り消されるということが示されている。

無線通信ネットワークにおける性能を向上させるユーザ機器内のメカニズムを提供することが、本発明の目的である。

本発明の第１の形態によれば、上記目的は、スケジューリング要求のトリガをハンドリングするユーザ機器における方法により達成される。上記ユーザ機器はバッファを備える。上記バッファに到着する、基地局に送信されるデータを受け取った後に、上記ユーザ機器は、スケジューリング要求のトリガを生成する。上記スケジューリング要求のトリガは、取り消されるまで保留され、到着した上記データにより直接的にまたは間接的にトリガされる。上記スケジューリング要求のトリガの生成をトリガした上記データが、上記基地局に送信されるスケジュールされた（scheduled）データ信号の中に含まれるバッファ状態報告の中で報告される場合、または、上記スケジューリング要求の生成をトリガした上記データが、上記基地局に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、上記ユーザ機器は、保留されている上記スケジューリング要求のトリガを取り消す。

本発明の第２の形態によれば、上記目的は、スケジューリング要求のトリガをハンドリングするユーザ機器における方法により達成される。上記ユーザ機器はバッファを備える。上記バッファに到着する、基地局に送信されるデータを受け取った後に、上記ユーザ機器は、スケジューリング要求のトリガを生成する。上記スケジューリング要求のトリガは、取り消されるまで保留され、到着した上記データにより直接的にまたは間接的にトリガされる。上記ユーザ機器は、保留されている上記スケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告され、または上記スケジュールされたデータ信号の中に直接的に含まれたか、および、どのデータが、これらの２つの手段のいずれの中でも報告されていないかを、記録する。次のスケジューリング要求の機会が現れると、上記２つの手段のいずれでもまだ報告されていないデータを上記バッファが含む場合におよび当該場合にのみ、上記ユーザ機器はスケジューリング要求を送信する。

本発明の第３の形態によれば、上記目的は、スケジューリング要求のトリガをハンドリングするユーザ機器における方法により達成される。上記ユーザ機器はバッファを備える。上記バッファに到着する、基地局に送信されるデータを受け取った後に、上記ユーザ機器は、スケジューリング要求のトリガを生成する。上記スケジューリング要求のトリガは、取り消されるまで保留され、到着した上記データにより直接的にまたは間接的にトリガされる。上記スケジューリング要求のトリガの生成をトリガした上記データが、上記基地局に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、上記スケジューリング要求の生成をトリガした上記データが、上記基地局に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、上記ユーザ機器は、保留されている上記スケジューリング要求のトリガを取り消す。代わりに、上記ユーザ機器は、保留されている上記スケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、および、どのデータが、報告されていないかを、記録する。次のスケジューリング要求の機会が現れると、上記バッファ状態報告の中でまだ報告されていないデータを上記バッファが含む場合におよび当該場合にのみ、上記ユーザ機器はスケジューリング要求を送信する。

本発明の第４の形態によれば、上記目的は、スケジューリング要求のトリガをハンドリングするユーザ機器により達成される。上記ユーザ機器は、基地局に送信されるデータを受信するように構成されるバッファを備える。上記データは、上記バッファに到着する。上記ユーザ機器は、スケジューリング要求のトリガを生成するように構成される生成部をさらに備える。上記スケジューリング要求のトリガは、取り消されるまで保留され、到着した上記データにより直接的にまたは間接的にトリガされる。上記ユーザ機器は、上記スケジューリング要求のトリガの生成をトリガした上記データが、上記基地局に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、上記スケジューリング要求の生成をトリガした上記データが、上記基地局１１０に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されている上記スケジューリング要求のトリガを取り消すように構成される取消し部、をさらに備える。

本発明の第５の形態によれば、上記目的は、スケジューリング要求のトリガをハンドリングするユーザ機器により達成される。上記ユーザ機器は、基地局に送信されるデータを受信するように構成されるバッファを備える。上記データは、上記バッファに到着する。上記ユーザ機器は、スケジューリング要求のトリガを生成するように構成される生成部をさらに備える。上記スケジューリング要求のトリガは、取り消されるまで保留され、到着した上記データにより直接的にまたは間接的にトリガされる。上記ユーザ機器は、保留されている上記スケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告され、または上記スケジュールされたデータ信号の中に直接的に含まれたか、および、どのデータが、これらの２つの手段のいずれの中でも報告されていないかを、記録するように構成される取消し部、をさらに備える。上記ユーザ機器は、次のスケジューリング要求の機会が現れると、上記２つの手段のいずれでもまだ報告されていないデータを上記バッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信するように構成される送信部をさらに備える。

本発明の第６の形態によれば、上記目的は、スケジューリング要求のトリガをハンドリングするユーザ機器により達成される。上記ユーザ機器は、基地局に送信されるデータを受信するように構成されるバッファを備える。上記データは、上記バッファに到着する。上記ユーザ機器は、スケジューリング要求のトリガを生成するように構成される生成部をさらに備える。上記スケジューリング要求のトリガは、取り消されるまで保留され、到着した上記データにより直接的にまたは間接的にトリガされる。上記ユーザ機器は、上記スケジューリング要求のトリガの生成をトリガした上記データが、上記基地局に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、上記スケジューリング要求の生成をトリガした上記データが、上記基地局に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されている上記スケジューリング要求のトリガを取り消すように構成される取消し部、をさらに備える。代わりに、取消し部９３０は、保留されている上記スケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、および、どのデータが、報告されていないか、並びに、次のスケジューリング要求の機会がいつ現れるかを、記録する。この代替手段では、ユーザ機器は、上記バッファ状態報告の中でまだ報告されていないデータを上記バッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信するように構成される送信部、をさらに備える。

上記スケジューリング要求のトリガの生成をトリガした上記データが、上記基地局に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、上記スケジューリング要求の生成をトリガした上記データが、上記基地局に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、上記ユーザ機器は、保留されている上記スケジューリング要求のトリガを取り消す。または、代わりに、上記ユーザ機器は、保留されている上記スケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、および、どのデータが、報告されていないかを、記録する。この取消しは、同一の振るまい、その目的を果たす場合に保留されているスケジューリング要求を取り消すという利点をもたらす。これは、スケジューリング要求をトリガしたデータがバッファ状態の中で報告され、またはスケジューリング要求をトリガしたデータがスケジュールされた信号の中に含まれる場合に、スケジューリング要求が取り消されるときにのみ、保証される。したがって、いずれのスケジュール要求も不必要に送信されず、またいずれのスケジューリング要求も誤って取り消されないことを確実にすることにより、無線通信ネットワークにおける性能が向上する。不必要に送信されるスケジューリング要求は、干渉の増加をもたらし、また、基地局により送信されるアップリンク共有チャネルのリソースについての不必要な許可をもたらす可能性がある。また、誤って取り消されるスケジューリング要求は、ユーザ機器がバッファ内のデータを送信できないようにする可能性がある。

本発明は、本発明の例示的な実施形態を説明する添付の図面を参照してより詳細に説明される。
問題分析を説明する概略図である。問題分析を説明する概略図である。問題分析を説明する概略図である。無線通信ネットワークの実施形態を説明する概略的なブロック図である。方法の実施形態を示すフローチャートである。実施形態の分析を説明する概略図である。実施形態の分析を説明する概略図である。実施形態の分析を説明する概略図である。ユーザ機器の実施形態を説明する概略的なブロック図である。ユーザ機器の実施形態を説明する概略的なブロック図である。

本発明の一部として、まず問題が識別され解説される。上記のように、ＵＬ−ＳＣＨのリソースがＴＴＩの中で新たな送信に利用可能である場合に、ＰＤＣＣＨの許可の受信時に、またはＵＬ−ＳＣＨのリソースが利用可能であったＴＴＩで、ＵＬ−ＳＣＨリソースがいつ許可されたが不明確であると考えられたため、全ての保留されているＳＲが取り消されるべきである、ということが最近決定された。ここで、最近の決定に従って、ＵＬ−ＳＣＨのリソースが利用可能であるＴＴＩで、すなわち新たなデータの送信時に、保留されているＳＲのトリガを取り消すケースを検討する。

図１は、第１のデータについての許可が受信される前に新たな第２のデータがユーザ機器のバッファに到着する場合に、ＵＬデータの送信時にスケジューリング要求を取り消すための代替手段の分析を説明する。以下が実行されたと仮定する。第１のデータがユーザ機器のバッファに到着した。第１のデータが、バッファ状態報告をトリガした。また、この第１のデータは、次のスケジューリング要求の機会にスケジューリング要求を送信するための第１のスケジューリング要求のトリガを直接的にまたは間接的にトリガした。スケジューリング要求の機会が発生し、第１のスケジューリング要求が基地局に送信された。第１のスケジューリング要求のトリガは、まだ保留されている。当該トリガは、ＵＬデータの送信時に取り消されるであろう。時系列を見ると、２つの異なる出現するケース、すなわち図１において説明されるケースａ）およびｂ）がある。ケースａ）では、ユーザ機器は、ＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有する。ケースｂ）では、ユーザ機器は、ＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有しない。次のＳＲの機会は、データの送信の後に発生する。

ケースａ）について、以下のステップを仮定する。

ステップ１００。新たな第２のデータが、ユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告のトリガをトリガする。この第２のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会に第２のデータについてのスケジューリング要求を送信するための第２のスケジューリング要求のトリガをトリガする。

ステップ１１０。基地局に送信された第１のスケジューリング要求への応答として、ユーザ機器は、送信についてのＵＬ許可を基地局から受信する。

ステップ１１５。第１のおよび第２のスケジューリング要求のトリガは、保留されている。これは、ユーザ機器が次のスケジューリング要求の機会にスケジューリング要求を基地局に送信することを意味する。この時点で、スケジューリング要求の機会が発生する。すなわち、このスケジューリング要求の機会は、ケースａ）によれば、ＵＬ許可の受信とデータの送信との間に発生する。したがって、許可が既に受信されているが、ユーザ機器は、基地局にスケジューリング要求を再度送信する。これは、送信する必要がなく、受信する基地局を混乱させる。これは不利益である。

ステップ１２０。このステップでは、ユーザ機器は、基地局に送信する。許可は単にリソースの許可であるので、ユーザ機器の信号が第１のデータまたは第２のデータからのデータを含むかを確実に知ることはできず、ユーザ機器はどのデータを送信すべきか決定する。第２のデータの一部が送信される場合、第２のデータは第１のデータよりも高い優先度のものであり得る。しかしながら、全てのデータが信号に適合できるがバッファ状態報告が信号に適合しない場合を除き、バッファ状態報告も基地局への信号の中に含まれる。もし含まれると、バッファ状態報告は、スケジュールされた信号が作成された後の第１のデータの残りの何でもおよび第２のデータを報告する。この例でのルールは、ＵＬデータの送信時にＳＲを取り消すことであるので、ユーザ機器は、両方の保留されているＳＲトリガをこの時点で取り消す。しかしながら、基地局は、第２のスケジューリング要求１１５をどのように解釈すべきかを知らない。第２のスケジューリング要求に基づいて、基地局は、信号（１２０）の中で報告されていないさらなるデータがあると考える新たな許可を送信し得る。信号（１２０）の中で送信されるバッファ状態報告が空のバッファを反映する場合に、当該新たな許可は、パディングされたビットを送信することにより満たされるのみである。これは、両方の許可およびパディングされた信号が不用であり、他のユーザ機器のために使用できたリソースをとった、ということを意味する。

ケースｂ）について、より小さい問題がある。以下のステップを仮定する。

ステップ１００。新たな第２のデータがユーザ機器のバッファに到着する。第２のデータは、バッファ状態報告のトリガをトリガする。この第２のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会に第２のデータについてのスケジューリング要求を送信するための第２のスケジューリング要求のトリガをトリガする。

ステップ１１０。基地局に送信された第１のスケジューリング要求に応じて、ユーザ機器は、送信についてのＵＬ許可を基地局から受信する。

ステップ１２０。ユーザ機器は、基地局に送信する。再び、ユーザ機器の信号が第１のデータまたは第２のデータからのデータを含むかを確実に知ることはできない。バッファ状態報告は、基地局への信号の中に含まれる。第２のデータが許可の前に到着したので、当該バッファ状態報告は、第１のデータおよび第２のデータを報告する。この例でのルールは、ＵＬデータの送信時にスケジューリング要求を取り消すことであるので、ユーザ機器は、両方の保留されているスケジューリング要求のトリガをこの時点で取り消す。これは、さらなるスケジューリング要求を送信しなくてもよいため好ましい。

ステップ１２５。スケジューリング要求の機会は、ケースｂ）によれば、この時点で、すなわちデータの送信後に発生する。ユーザ機器は、ケースａ）でのようにＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有しなかった。スケジューリング要求のトリガは、取り消され、したがってもはや保留されていない。これは、ユーザ機器がこの次のスケジューリング要求の機会に基地局にスケジューリング要求を再度送信しないということを意味する。スケジューリング要求が送信時に取り消されたことは問題ない。第２のデータが許可の前に到着したので、当該第２のデータは、バッファ状態報告の中で報告され、または信号の中に完全に含まれる、ということが保証される。それは好ましく、かつ安全である。

ケースａ）では、スケジューリング要求が発生する際に、スケジューリング要求のトリガはまだ取り消されていない。したがって、ユーザ機器は前回のスケジューリング要求に応じて既に許可を受信しているが、新たなスケジューリング要求が送信される。示されたケースでは、第２のスケジューリング要求の必要はないが、ユーザ機器は、仕様により第２のスケジューリング要求を送信するように強制される。スケジューリング要求は、物理アップリンク制御チャネル（ＰＵＣＣＨ）上の不用な干渉を生み出すので、これは、ユーザ機器のエネルギーおよび無線リソースの浪費である。したがって、この余分なスケジューリング要求は不用であり、よってこれは不利益である。さらに、上記の不用なスケジューリング要求に応じて基地局が何をすべきかが不明である。ユーザ機器が第１のデータを受信したが第２のデータを受信しなかった場合であっても、余分な不要なスケジューリング要求およびその望ましくない結果を伴う同一の手順がケースａ）で発生し、よって、それは珍しいシナリオではない、ということに留意する。

しかしながら、図２および図３に関連する以下の例では、より悪い問題を伴うさらに複雑なケースがある。当該ケースでは、第１のスケジューリング要求に対応する許可が受信された後に、ユーザ機器がバッファへの新たなデータを取得する。この新たなデータは、スケジューリング要求のトリガをトリガする。時系列を見ると、２つの異なる出現するケース、すなわち図２において説明されるケースａ）および図３において説明されるケースｂ）がある。この例では、図１に関連するケースａ）での例のように、ユーザ機器は、ＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有する。ケースｂ）では、ユーザ機器は、ＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有しない。次のスケジューリング要求の機会は、データの送信後に発生する。

ケースａ）およびケースｂ）では、２つの個別の代替手段、すなわち代替手段Ｉおよび代替手段IIがある。図２は、ケースａ）の代替手段Iおよびケースａ）の代替手段IIを示し、図３は、ケースｂ）の代替手段Iおよびケースｂ）の代替手段IIを示す。

ここから、図２は、許可の受信とケースａ）についての許可に対応するデータの送信との間に新たなデータが到着し、ユーザ機器がＵＬ許可の受信とデータの送信との間にＳＲの機会を有する場合に、ＵＬデータの送信時にＳＲを取り消すための、代替手段の分析を説明する。以下が実行されたと仮定する。第１のデータがユーザ機器のバッファに到着した。第１のデータが、バッファ状態報告のトリガをトリガした。また、この第１のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次のスケジューリング要求の機会にスケジューリング要求を送信するための第１のスケジューリング要求のトリガをトリガした。ＳＲの機会が発生し、第１のスケジューリング要求が基地局に送信される。第１のスケジューリング要求のトリガは、まだ保留されている。当該トリガは、ＵＬデータの送信時に取り消されるであろう。

ケースａ−I）について、以下のステップが仮定される。

ステップ２００ケースａ−１）。基地局に送信されたＳＲへの応答として、ユーザ機器は、送信についてのＵＬ許可を基地局から受信する。

ステップ２１０ケースａ−１）。ある期間に、ユーザ機器は、送信される第１のデータの一部または全部について、ＭＡＣＰＤＵのようなパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。当該パケットデータユニットは、後の送信時に基地局に送信されるものとする。バッファ状態報告は、第１のデータを報告する。

ステップ２２０ケースａ−１）。新たな第２のデータが、ユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告をトリガする。この第２のデータは、さらに、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第２のスケジューリング要求のトリガをトリガする。第１のデータおよび第２のデータの両方によりトリガされた、第１のスケジューリング要求のトリガおよび第２のスケジューリング要求のトリガは、保留されている。

ステップ２４０ケースａ−１）。この時点で、スケジューリング要求の機会が発生する。すなわち、このスケジューリング要求の機会は、ケースａ）によれば、ＵＬ許可の受信とデータの受信との間に発生する。したがって、スケジューリング要求はまだ取り消されていないので、ユーザ機器は基地局に第２のスケジューリング要求を送信する。第２のデータがユーザ機器のバッファで入手可能になる前に、送信される第１のデータの一部または全部を含むパケットデータユニットをユーザ機器が既に生成しているので、これは必要である。したがって、第２のデータは、送信時に送信されるバッファ状態報告の中で報告されない。

ステップ２５０ケースａ−１）。ユーザ機器は、バッファ状態報告を含むパケットデータユニットを送信する。当該バッファ状態報告は、（上記）第１のデータによりトリガされる。また、当該バッファ状態報告は、第１のデータを報告するが、第２のデータを報告しない。この例のルールは、ＵＬデータの送信時にスケジューリング要求を取り消すことであるので、ユーザ機器は、両方の保留されているスケジューリング要求のトリガをこの時点で取り消す。この時点で、送信された第２のスケジューリング要求をどのように解釈すればよいかを知ることは基地局にとって困難である。すなわち、第２のスケジューリング要求が、第２のデータに対応するか、または、第２のスケジューリング要求が、スケジューリング要求のトリガがまだ取り消されていない第１のデータに対応するかは、基地局には分からない。基地局は、許可を送信しなければ、バッファの中のデータを伴うユーザ機器が送信できないままにする、というリスクを負う。また、基地局は、新たな許可を送信すれば、この許可が不用であり、対応する信号がパディングのみとなる、というリスクを負う。さらに、ＰＵＣＣＨ上の過度の干渉またはＰＵＣＣＨのカバレッジの問題のため等で、第２のスケジューリング要求が基地局により受けられなければ、スケジューリング要求のトリガはここで取り消され、たとえ新たな許可が第２のデータについて受信されなくても、新たなスケジューリング要求は送信されない。これは、ユーザ機器が第２のデータを送信するための許可を基地局から取得できず、基地局が第２のデータの存在について知らないので、第２のデータがユーザ機器内に残る、ということを意味する。

ケースａ−II）について、以下のステップを仮定する。

ステップ２００ケースａ−II）。基地局に送信された第１のスケジューリング要求への応答として、ユーザ機器は、送信についてのＵＬ許可を基地局から受信する。

ステップ２２０ケースａ−II）。新たな第２のデータが、ユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告のトリガをトリガする。この第２のデータは、さらに、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第２のスケジューリング要求のトリガをトリガする。このケースａ−II）では、ケースａ−Iとは異なり、第２のデータは、パケットデータユニットの生成後の代わりに、パケットデータユニットの生成前に到着する。

ステップ２３０ケースａ−II）。ある期間に、ユーザ機器は、送信されるデータについて、ＭＡＣＰＤＵのようなパケットデータユニットを生成する。当該データは、ユーザ機器のバッファの中のデータの優先度に応じて、パケットデータユニットの中で生成される。全てのデータが適合できるがバッファ状態報告が適合できない場合を除き、ユーザ機器は、優先度に従った第１のデータおよび第２のデータ、並びにバッファ状態報告を、パケットデータユニットの中に含める。当該パケットデータユニットは、後の送信時に基地局に送信されるものとする。当該パケットデータユニットは、後の送信時に基地局に送信されるものとする。

ステップ２４０ケースａ−II）。第１のおよび第２のスケジューリング要求のトリガは、保留されている。この時点で、スケジューリング要求の機会が発生する。すなわち、このスケジューリング要求の機会は、ケースａ）によれば、ＵＬ許可の受信とデータの送信との間に発生する。したがって、ユーザ機器の両方のスケジューリング要求のトリガがまだ取り消されていないので、ユーザ機器は基地局にスケジューリング要求を再度送信する。まさに図１のａのように、第１のデータおよび第２のデータの両方が、既に割り当てられたリソース上で送信されるバッファ状態報告の中に含まれるので、これはこの場合に不用である。

ステップ２５０ケースａ−II）。ユーザ機器は、生成されたパケットデータユニットの中でデータおよびバッファ状態報告を送信する。当該バッファ状態報告は、第１のデータおよび第２のデータを報告する。この例でのルールは、ＵＬデータの送信時にスケジューリング要求を取り消すことであるので、ユーザ機器は、両方の保留されているスケジューリング要求のトリガをこの時点で取り消す。

ケースａ）、すなわちケースａ−I）およびケースａ−II）の両方では、余分なスケジューリング要求が送信される。しかし、基地局は、当該スケジューリング要求を受信する場合に、２つのスケジューリング要求を受信したことを知るのみであり、ケースａ−I）とケースａ−II）とを区別することができない。すなわち、基地局は、同一のデータが両方のスケジューリング要求の裏にあるか、または、第２のスケジューリング要求について追加のデータが受信されたか、を区別することができない。それに応じて、バッファ状態報告が生成された後に新たなデータが到着した可能性があるので、受信したバッファ状態報告がユーザ機器のバッファのサイズを実際に反映しているかは基地局には分からない。したがって、基地局は、推測しなければならず、その推測に応じて、許可を浪費し、または新たなデータを見失う、というリスクを負う。そして、基地局は、新たなデータが報告されなかったために、ユーザ機器について不正確なバッファのサイズの推定を有する。

図３は、許可の受信とケースｂ）についての許可に対応するデータの送信データの送信との間に新たなデータが到着し、ユーザ機器がＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有さず、次のスケジューリング要求の機会がデータの送信後に発生する場合に、ＵＬデータの送信時にスケジューリング要求を取り消すための、代替手段の分析を説明する。以下が実行されたと仮定する。第１のデータがユーザ機器のバッファに到着した。この第１のデータが、バッファ状態報告のバッファをトリガした。また、この第１のデータが、バッファ状態報告のトリガを介して直接的にまたは間接的に、次のスケジューリング要求の機会にスケジューリング要求を送信するための第１のスケジューリング要求のトリガをトリガした。スケジューリング要求の機会が発生し、第１のスケジューリング要求が基地局に送信される。第１のスケジューリング要求のトリガは、まだ保留されている。当該トリガは、ＵＬデータの送信時に取り消されるであろう。

ケースｂ−I）について、以下のステップが仮定される。

ステップ３００ケースｂ−I）。基地局に送信されたスケジューリング要求への応答として、ユーザ機器は、送信についてのＵＬ許可を基地局から受信する。

ステップ３１０ケースｂ−I）。ある期間に、ユーザ機器は、送信される第１のデータの一部または全部について、ＭＡＣＰＤＵのようなパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。パケットデータユニットは、後の送信時に基地局に送信されるものとする。バッファ状態報告は、第１のデータを報告する。

ステップ３２０ケースｂ−I）。新たな第２のデータが、ユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告をトリガする。この第２のデータは、さらに、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第２のスケジューリング要求のトリガをトリガする。

ステップ３４０ケースｂ−I）。ユーザ機器は、パケットデータユニットの中で生成された第１のデータを送信し、パケットデータユニットの中にバッファ状態報告を含める。当該バッファ状態報告は、第１のデータによりトリガされた。また、当該バッファ状態報告は、第１のデータを報告するが、第２のデータを報告しない。この例でのルールは、ＵＬデータの送信時にスケジューリング要求を取り消すことであるので、ユーザ機器は、両方の保留されているスケジューリング要求をこの時点で取り消す。これは、いずれのスケジューリング要求もこの時点で現れていないので、第２のデータについてのスケジューリング要求が基地局にまだ送信されていないとしても、ユーザのバッファの中に第２のデータがあることを示すための保留されているスケジューリング要求のトリガがもはやない、ということを意味する。このケースでは、第２のデータのために必要なスケジューリング要求が失われる。

ステップ３５０ケースｂ−I）。スケジューリング要求の機会は、ケースｂ）によれば、この時点で、すなわちデータの送信後に発生する。スケジューリング要求のトリガはステップ３４０で取り消されたので、いずれのスケジューリング要求のトリガも保留されていない。よって、上記のように、このケースでは、第２のデータについてのＳＲが失われる。これは好ましくない。

ケースｂ−II）について、以下のステップが仮定される。

ステップ３００ケースｂ−II）。基地局に送信された第１のスケジューリング要求への応答として、ユーザ機器は、送信についてのＵＬ許可を基地局から受信する。

ステップ３２０ケースｂ−II）。新たな第２のデータが、ユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告のトリガをトリガする。この第２のデータは、さらに、次の機会にスケジューリング要求を送信するための第２のスケジューリング要求のトリガを直接的にまたは間接的にトリガする。このケースｂ−II）では、ケースｂ−I）とは異なり、第２のデータは、パケットデータユニットの生成後の代わりに、パケットデータユニットの生成前に到着する。

ステップ３３０ケースｂ−II）。ある期間に、ユーザ機器は、送信されるデータについて、ＭＡＣＰＤＵのようなパケットデータユニットを生成する。当該データは、ユーザ機器のバッファの中のデータの優先度に応じて、パケットデータユニットの中で生成される。全てのデータが適合できるがバッファ状態報告が適合できない場合を除き、ユーザ機器は、優先度に従った第１のデータおよび第２のデータ、並びにバッファ状態報告を、パケットデータユニットの中に含める。当該パケットデータユニットは、後の送信時に基地局に送信されるものとする。バッファ状態報告は、第１のデータおよび第２のデータの両方を報告する。

ステップ３４０ケースｂ−II）。ユーザ機器は、パケットデータユニットの中でデータおよびバッファ状態報告を送信する。当該バッファ状態報告は、第１のデータおよび第２のデータを報告する。この例でのルールは、ＵＬデータの送信時にＳＲを取り消すことであるので、ユーザ機器は、保留されているＳＲのトリガをこの時点で取り消す。

ステップ３５０ケースｂ−II）。ＳＲの機会は、ケースｂ）によれば、この時点で、すなわちデータの送信後に発生する。ＳＲのトリガはステップ３４０で取り消されたので、いずれのＳＲのトリガも保留されていない。第１のデータおよび第２のデータは既に送信されているか、またはＢＳＲの中で報告されるので、このケースではこれは望ましい。

見られるように、ケースｂ−II）は良好に機能するが、ケースｂ−I）は良好に機能しない。両方のケースで、トリガされた第２のスケジューリング要求のトリガは、第１のデータが送信された際に取り消されたので、決して送信されない。しかしながら、ケースｂ−I）のように、送信されるバッファ状態報告の中に第２のデータが含まれない場合に、基地局はこのデータについて知ることはないであろう。２つの事が当該状況を救い得る。許可上での信号はバッファ状態報告を含むので、ユーザ機器は、送信されていないスケジューリング要求に応じてではなく、他のデータについての許可を受信する。または、新たなＳＲが、さらに新たなデータの到着によりトリガされる。

これらのうちの１つが起こらなければ、ユーザ機器は、「再送バッファ状態報告タイマ（retransmit buffer status report timer）」または「再送ＢＳＲタイマ（retx-BSR-Timer）」として知られるフィードバックメカニズムが終了し、スケジューリング要求をトリガするまで、新たなスケジューリング要求を送信する手段がない。しかしながら、このタイマは３２０ｍｓの最小値を有し、当該最小値はかなりの遅延を加える。

したがって、無線通信ネットワークにおける性能を向上させるユーザ機器内のメカニズムを提供することが、本発明の目的はである。

ここで本ソリューションに関して、図４は、本ソリューションが実装される無線通信システム１００を示す。無線通信システム１００は、パケットに基づく通信システムである。当該通信システムは、ＬＴＥ通信システム、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、またはアップリンクスケジューリングについてのスケジューリング要求をハンドリングするいずれかの他の無線通信システムであってもよい。

無線通信システム１００は、セル１１５にサービスを提供する基地局１１０を含む。基地局１１０は、ｅＮＢ、無線基地局（ＲＢＳ）、またはセル内に存在するユーザ機器と無線キャリアを通して通信可能ないずれかの他のネットワークユニット等の無線基地局である。

セル１１５内に存在するユーザ機器１２０は、基地局１１０によりサービスを提供され、したがって、無線チャネル１２５を通して基地局１１０にＭＡＣＰＤＵのようなデータパケットユニットを送信することができる。ユーザ機器１２０は、モバイル端末または無線端末等の端末、モバイル電話、例えばラップトップのようなコンピュータ、携帯情報端末（ＰＤＡ）、またはエアインターフェースを通して基地局と通信可能ないずれかの他の無線ネットワークユニット等の、端末であってもよい。エアインターフェースは、例えば、ＬＴＥにおいて使用されるＥ−ＵＴＲＡエアインターフェースであってもよい。

ユーザ機器１２０はバッファを備える。基地局１１０に送信される新たなアップリンクデータが、当該バッファに到着する。当該データは、音声データ、映像データ、写真データ、テキストデータ、またはユーザが送信することを望み得るいずれかの他の種類のデータであってもよい。既存のデータよりもより高い優先度の新たなＵＬデータ、または先行するデータがない場合のいずれかの優先度の新たなデータの、ユーザ機器のバッファへの到着は、バッファ状態報告をトリガする。到着した新たなデータは、さらに、保留されるスケジューリング要求のトリガを直接的にまたは間接的にトリガする。間接的にトリガすることは、到着したデータがバッファ状態報告をトリガし、そして当該バッファ状態報告がスケジューリング要求のトリガをトリガするように、実行され得る。スケジューリング要求のトリガは、次のスケジューリング要求の機会に基地局１１０に送信されるスケジューリング要求をトリガする。「スケジューリング要求のトリガ」は、「保留されているスケジューリング要求」と呼ばれてもよい。上記のように、基地局１１０にスケジューリング要求を送信するための機会に関連付けられる一定の周期性がある。よって、ユーザ機器１２０は、当該機会が利用可能になるまで待機しなければならない。スケジューリング要求を受信する基地局１１０は、そのようにして、送信したい新たなデータをユーザ機器１２０が有することを通知される。スケジューリング要求のトリガは、保留さているか、または保留されていない。スケジューリング要求は、典型的には、いずれかの特定の到着したデータと関連付けられない。また、スケジューリング要求のトリガは、当該トリガをトリガしたデータと暗黙的に関連付けられるが、いずれかのデータに関連付けられる必要はない。しかし、スケジューリング要求のトリガが既にトリガされていても、ここでは第２のデータと呼ばれるさらなるデータがユーザ機器のバッファに到着し、スケジューリング要求のトリガをトリガすると、さらなるスケジューリング要求がトリガされる。

スケジューリング要求への応答として、基地局１１０は、典型的には、ユーザ機器１２０にアップリンク許可を送信する。許可は、ユーザ機器に固有であるが、当該ユーザ機器内のいずれかの特定の到着したデータと関連付けられない。ｅＮＢにより設定され、ユーザ機器１２０にシグナリングされる優先度は、ユーザ機器１２０に割り当てられたリソース上でどの特定のデータが送信されるべきかを決定する。

無線通信ネットワークにおける性能を向上させるより信頼できるスケジューリング手順のハンドリングを行うために、本ソリューションによれば、保留されているスケジューリング要求のトリガは、以下のように取り消される。

第１の実施形態では、スケジューリング要求をトリガしたデータが、基地局１１０に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されているスケジューリング要求が取り消される。この後者のケースでは、スケジュールされたデータは、少し後に送信されるパケットデータユニットの中にまさに含まれて、送信されなくてもよい。

代わりに、第２の実施形態では、保留されているスケジューリング要求は、ユーザ機器によりいずれかの時点で取り消される。しかし、ユーザ機器は、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、およびどのデータが報告されていないかを記録する。そして、次のスケジューリング要求の機会が現れると、ユーザ機器１２０は、バッファ状態報告の中でまだ報告されていないデータをバッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信する。これは、第１の実施形態において、保留されているスケジューリング要求を有することに等しいが、必ずしも「保留されているスケジューリング要求を有する」と呼ばれなくてもよい。しかしながら、結果は同じであり、次のスケジューリング要求の機会に、バッファ状態報告にまだ含まれないデータがあり、また当該データがまだ送信されていなければ、ユーザ機器１２０はスケジューリング要求を送信する。

いくつかの実施形態に従った、スケジューリング要求のトリガをハンドリングする基地局１１０における方法に関連する本ソリューションが、図５に示されるフローチャートを参照して説明される。上記のように、ユーザ機器１２０はバッファを備える。

方法は、以下のステップを含む。当該ステップは、また、以下に説明されるものよりも別の適切な順序で実行されてもよい。

ステップ５０１
ユーザ機器１２０内のバッファは、基地局１１０に送信されるデータを受け取る。

ステップ５０２
このステップは、オプションである。いくつかの実施形態によると、ユーザ機器１２０は、バッファ状態報告のトリガを生成する。当該バッファ状態報告のトリガは、到着したデータによりトリガされる。

ステップ５０３
ユーザ機器１２０は、スケジューリング要求のトリガを生成する。当該スケジューリング要求のトリガは、取り消されるまで保留されている。また、生成は、到着したデータにより直接的にまたは間接的にトリガされる。スケジューリング要求のトリガを生成するこのステップが間接的に実行されるいくつかの実施形態では、当該生成は、到着したデータによりトリガされたバッファ状態報告のトリガの生成によりトリガされる。

ステップ５０４
第１の実施形態によれば、スケジューリング要求をトリガしたデータが、基地局１１０に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、ユーザ機器１２０は、保留されているスケジューリング要求を取り消す。したがって、保留されているスケジューリング要求のトリガは、例えば、バッファ状態報告ＭＡＣ制御要素を含むＭＡＣＰＤＵが生成されるのと同時に取り消されてもよい。

ＭＡＣＰＤＵのようなパケットデータユニットが生成される場合に、パケットデータユニットは、パケットデータユニットの生成後にユーザ機器のバッファ内に残っているデータを報告するＢＳＲＭＡＣ制御要素のようなバッファ状態報告を含む。当該バッファ状態報告は、ＭＡＣＰＤＵが生成される時にバッファ状態報告のトリガが保留されており、かつ全てのデータがＭＡＣＰＤＵに適合できない場合に、含まれる。

スケジューリング要求をトリガしたデータが、ＢＳＲＭＡＣ制御要素により表されるバッファ状態報告の中に含まれる場合に、または、スケジューリング要求をトリガした全てのデータが、送信のためのＭＡＣＰＤＵの中に含まれている場合に、ユーザ機器１２０は、保留されているスケジューリング要求を取り消してもよい。ＬＴＥ標準に照らすと、スケジューリング要求をトリガしたバッファ状態報告が取り消される場合に、ユーザ機器１２０が保留されているスケジューリング要求を取り消すこととして、当該動作方法を理解することができる。ここで、「場合に（when）」は、必ずしも時間における一致を暗示せず、保留されているスケジューリング要求をトリガした保留されているバッファ状態報告の取り消しに基づいて、保留されているスケジューリング要求が取り消されること、として理解されることが可能である。換言すると、少なくともある実施形態では、その時点においてスケジュールされたデータ信号が、対応するバッファ状態報告のトリガを生成させた新たなデータの全てを含む場合、または、次のその時点においてスケジュールされたデータ信号の中に含まれるバッファ状態報告（当該バッファ状態報告は、１つ以上の他の保留されているバッファ状態報告のトリガのために生成されたかもしれない）が、新たなデータを報告する場合に、例えば対応するバッファ状態報告のトリガが取り消されることによって、保留されているスケジューリング要求のトリガが取り消される。

ステップ５０５
第２の実施形態によれば、ステップ５０４の代替手段として、ユーザ機器１２０は、保留されているスケジューリング要求をいずれかの時点で取り消すが、ユーザ機器１２０は、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、および、どのデータが報告されていないか、またいくつかの実施形態では、どのデータが、報告されておらず、スケジュールされたデータ信号の中に含まれてもいないか、を記録する。

ステップ５０６
第２の実施形態によれば、次のスケジューリング要求の機会が現れると、ユーザ機器１２０は、バッファ状態報告の中でまだ報告されていないデータをバッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信する。

この代わりの実施形態では、ユーザ機器１２０は、３ＧＰＰがテストすることが可能な振るまいをなお満たしつつ、ステップ５０４で第１の実施形態に従って取り消される時点の前または後であって望むときはいつでも、保留されているスケジューリング要求のトリガを内部で取り消してもよい。これは、上記のように、バッファ状態報告の中にまだ含まれていないデータ、またいくつかの実施形態によれば、バッファ状態報告の中にまだ含まれておらず、スケジュールされたＵＬデータ信号の中にも含まれていないデータを、ユーザ機器１２０が記録することにより、実行される。これは、第１の実施形態において保留されているスケジューリング要求を有することに等しいが、必ずしも「保留されているスケジューリング要求を有する」と呼ばれなくてもよい。しかしながら、結果は同じであり、次のスケジューリング要求の機会に、バッファ状態報告にまだ含まれないデータがあり、また当該データがまだ送信されていなければ、ユーザ機器１２０はスケジューリング要求を送信する。

さらに、上記のようないくつかの実施形態では、バッファ状態報告のトリガは、アップリンク送信バッファに入ってくる新たなデータに応じて生成されてもよい。また、スケジューリング要求のトリガは、バッファ状態報告のトリガに対応して生成されてもよい。したがって、アップリンク送信バッファに新たなデータを受け取ることは、新たなバッファ状態報告のトリガを生成させ、当該バッファ状態報告のトリガは、スケジューリング要求のトリガをもたらす。

ここで教えられる１つ以上の実施形態では、保留されているバッファ状態報告のトリガおよび対応する保留されているスケジューリング要求のトリガの有利なハンドリングおよび取消しは、アップリンクデータがユーザ機器１２０で行き詰まることを防ぎ、および／または、不用なスケジューリング要求の送信および結果として起こる不用なアップリンクリソースの許可を防ぎ、若しくは少なくとも減らす。

バッファ状態報告のトリガおよび対応するスケジューリング要求のトリガは、フラグまたは他の論理的な指標として実装されてもよく、当該フラグまたは他の論理的な指標は、セットされ、またはそうでなければ保留されている状態を示すように生成され、および、クリアされ、またはそうでなければ取消しのために削除されてもよい、ということも当業者は理解するであろう。

図６は、第１のデータについての許可が受信される前に新たな第２のデータがユーザ機器のバッファに到着する場合に、第１の実施形態に従った本ソリューションの分析を説明する。すなわち、第１の実施形態は、スケジューリング要求をトリガしたデータが、基地局１１０に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合に、スケジューリング要求のトリガを取り消すことを含む。または、ユーザ機器１２０は、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合に、保留されているスケジューリング要求を取り消す。これらの場合のうちのいずれか最初に発生する方で取り消される。以下が実行されたと再度仮定する。第１のデータがユーザ機器のバッファに到着した。これは、図５の中のステップ５０１に対応する。この第１のデータは、バッファ状態報告をトリガした。これは、図５の中のステップ５０１に対応する。この第１のデータは、次のスケジューリング要求の機会にスケジューリング要求を送信するための第１のスケジューリング要求のトリガも直接的にまたは間接的にトリガした。これは、図５の中のステップ５０３に対応する。スケジューリング要求の機会が発生し、第１のスケジューリング要求が基地局１１０に送信された。第１のスケジューリング要求のトリガは、まだ保留されている。時系列を見ると、２つの異なる出現するケース、すなわち図６において説明されるケースａ）およびｂ）がある。ケースａ）では、ユーザ機器１２０は、ＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有する。ケースｂ）では、ユーザ機器１２０は、ＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有しない。次のスケジューリング要求の機会は、データの送信後に発生する。

ケースａ）について、以下のステップを仮定する。

ステップ６００。新たな第２のデータが、ユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告をトリガする。この第２のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第２のスケジューリング要求のトリガをトリガする。

ステップ６１０。基地局１１０に送信された第１のスケジューリング要求への応答として、ユーザ機器１２０は、送信についてのＵＬ許可を基地局１１０から受信する。

ステップ６１２。ある期間に、ユーザ機器１２０は、送信される第１のデータおよび第２のデータの一部または全部について、ＭＡＣＰＤＵ等のパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。当該パケットデータユニットは、後の送信時に基地局１１０に送信されるものとする。本ソリューションによれば、全ての保留されているスケジューリング要求のトリガは、この時点で取り消され、全ての保留されているバッファ状態報告のトリガも、この時点で取り消される。

ステップ６１５。第１のおよび第２のスケジューリング要求のトリガは、保留されていない。これは、ユーザ機器１２０は次のスケジューリング要求の機会に基地局１１０にスケジューリング要求を送信しないということを示す。この時点で、スケジューリング要求の機会が発生し、いずれのスケジューリング要求も送信されない。全てのデータがバッファ状態報告またはスケジュールされた信号の中のいずれかで報告されたので、これは望ましい。

ステップ６２０。ユーザ機器１２０は、生成したパケットデータユニットを基地局１１０に送信する。

ケースｂ）について、以下のステップを仮定する。

ステップ６００。新たな第２のデータが、ユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告のトリガをトリガする。この第２のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するためのスケジューリング要求のトリガをトガする。このステップは、ケースａ）についてと同じである。

ステップ６１０。基地局１１０に送信された第１のスケジューリング要求への応答として、ユーザ機器１２０は、送信についてのＵＬ許可を基地局から受信する。このステップも、ケースａ）についてと同じである。

ステップ６２０。ユーザ機器１２０は、生成したパケットデータユニットを基地局１１０に送信する。再び、ユーザ機器１２０が第１のデータおよび第２のデータに従って送信したかを確実に知ることはできない。バッファ状態報告は、基地局１１０への信号の中に含まれる。第２のデータが許可の前に到着したので、当該バッファ状態報告は、第１のデータおよび第２のデータを報告する。この例でのルールは、スケジューリング要求をトリガしたデータが、基地局１１０に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、スケジューリング要求のトリガを取り消すことである。または、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合に、ユーザ機器１２０は、保留されているスケジューリング要求を取り消す。これらの場合のうちのいずれか最初に発生する方で取り消される。バッファ状態報告および第１のデータおよび第２のデータを含むデータパケットユニットは、送信の時点の前、すなわちステップ６２０の前に生成されたので、ユーザ機器１２０は、保留されているスケジューリング要求のトリガを取り消している。次のスケジューリング要求の機会に追加のスケジューリング要求を送信する動機がないので、これは望ましい。

ステップ６２５。スケジューリング要求の機会は、ケースｂ）によると、この時点で、すなわちデータの送信後に発生する。ユーザ機器１２０は、ケースａ）では、ＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有しない。スケジューリング要求のトリガは既に取り消され、したがってもはや保留されていない。これは、ユーザ機器１２０が次のスケジューリング要求の機会に基地局１１０にスケジューリング要求を再度送信しないということを意味する。これは望ましい。

したがって、ケースａ）およびケースｂ）のいずれでも、いずれの不用なスケジューリング要求も送信されず、スケジューリング要求が意味することについて、ユーザ機器１１０において曖昧さがない。ケースａ）およびｂ）では、スケジューリング要求は、ユーザ機器１２０においてユーザ機器１１０が予め気づいていなかった新たなデータがあることを意味する。スケジューリング要求の機会６１５がパケットユニットの生成６１２前であるエラーケースがまだある。図１の中のケースａ）の分析と同様に、当該ケースでは、送信される追加のスケジューリング要求があり、また、ＳＲが意味することについてユーザ機器１１０における曖昧さがある。しかし、図６でのあり得るエラーケースのように第２のデータの到着とパケットユニットの生成との間にＳＲの機会を有する可能性は、図１のように第２のデータの到着とデータの送信との間にＳＲの機会を有する可能性よりも、極めて小さい。

図７および図８は、第１の実施形態に従った本ソリューションの分析を説明する。ここでは、ユーザ機器１２０は、第１のスケジューリング要求に対応する許可が受信された後にバッファに新たなデータを取得する。この新たなデータは、スケジューリング要求のトリガをトリガする。時系列を見ると、２つの異なる出現するケース、すなわち図７において説明されるケースａ）および図８において説明されるケースｂ）がある。ケースａ）では、ユーザ機器１２０は、ＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有する。ケースｂ）では、ユーザ機器１２０は、ＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有しない。次のスケジューリング要求の機会は、データの送信後に出現する。

ケースａ）およびケースｂ）では、２つの個別の代替手段、すなわち代替手段Ｉおよび代替手段IIがある。図７は、ケースａ）の代替手段Iおよびケースａ）の代替手段IIを示し、図８は、ケースｂ）の代替手段Iおよびケースｂ）の代替手段IIを示す。

ここから、図７は、許可の受信とケースａ）についての許可に対応するデータの送信との間に新たなデータが到着し、ユーザ機器１２０がＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有するシナリオにおける、本ソリューションに従った分析を説明する。以下が実行されたと仮定する。第１のデータがユーザ機器のバッファに到着した。これは、図５の中のステップ５０１に対応する。第１のデータが、バッファ状態報告をトリガした。これは、図５中のステップ５０２に対応する。また、この第１のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次のスケジューリング要求の機会にスケジューリング要求を送信するための第１のスケジューリング要求のトリガをトリガした。これは、図５中のステップ５０３に対応する。スケジューリング要求の機会が発生し、第１のスケジューリング要求が基地局に送信される。第１のスケジューリング要求のトリガは、まだ保留されている。本ソリューションによれば、スケジューリング要求をトリガしたデータが、基地局１１０に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合に、スケジューリング要求のトリガが、取り消される。または、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合に、ユーザ機器１２０は、保留されているスケジューリング要求を取り消す。これらの場合のうちのいずれか最初に発生する方で取り消される。

ケースａ−I）について、以下のステップを仮定する。

ステップ７００ケースａ−I）。基地局１１０に送信されたスケジューリング要求への応答として、ユーザ機器１２０は、送信についてのＵＬ許可を基地局から受信する。

ステップ７１０ケースａ−I）。ある期間に、ユーザ機器１２０は、送信される第１のデータの一部または全部について、ＭＡＣＰＤＵのようなパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。パケットデータユニットは、後の送信時にユーザ機器１１０に送信されるものとする。バッファ状態報告は、第１のデータを報告する。本ソリューションの第１の実施形態によれば、保留されている第１のスケジューリング要求は、この時点で取り消される。これは、図５の中のステップ５０４に対応する。

ステップ７２０ケースａ−I）。新たな第２のデータがユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告をトリガする。この第２のデータは、さらに、次の機会にスケジューリング要求を送信するための第２のスケジューリング要求のトリガを直接的にまたは間接的にトリガする。第２のスケジューリング要求のトリガは、第２のデータにトリガされて、保留されている。

ステップ７４０ケースａ−I）。この時点で、スケジューリング要求の機会が発生する。すなわち、このスケジューリング要求の機会は、ケースａ）によれば、ＵＬ許可の受信とデータの送信との間に発生する。したがって、第２のスケジューリング要求が保留されているので、ユーザ機器１２０は第２のスケジューリング要求を基地局１１０に再度送信する。第２のデータがユーザ機器のバッファで入手可能になる前に、送信される第２のデータの一部または全部を含むパケットデータユニットをユーザ機器１２０が既に生成しているので、これは必要である。したがって、第２のデータは、送信時に基地局１１０に送信されるバッファ状態報告の中で報告されない。

ステップ７５０ケースａ−I）。ユーザ機器１２０は、バッファ状態報告を含むパケットデータユニットを送信する。当該バッファ状態報告は、（上記）第１のデータによりトリガされた。また、当該バッファ状態報告は、第１のデータを報告するが、第２のデータを報告しない。この時点で、送信された第２のスケジューリング要求をどのように解釈すればよいかを知ることは基地局１１０にとってもはや困難ではない。第２のスケジューリング要求は、信号の中で受信されるバッファ状態報告について報告されない新たなデータに対応する。さらに、第２のスケジューリング要求が送信されなかった場合に基地局１１０は第２のデータについて知らないので、ユーザ機器１２０が第２のスケジューリング要求を送信する必要であった。

ケースａ−II）について、以下のステップを仮定する。

ステップ７００ケースａ−II）。基地局に送信される第１のスケジューリング要求への応答として、ユーザ機器１２０は、送信についてのＵＬ許可を基地局１１０から受信する。

ステップ７２０ケースａ−II）。新たな第２のデータがユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告をトリガする。この第２のデータは、さらに、バッファ状態報告を介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第２のスケジューリング要求のトリガをトリガする。このケースａ−II）では、ケースａ−Iとは異なり、第２のデータは、パケットデータユニットの生成後の代わりに、パケットデータユニットの生成前に受信する。

ステップ７３０ケースａ−II）。ある期間に、ユーザ機器１２０は、送信されるデータについて、ＭＡＣＰＤＵのようなパケットデータユニットを生成する。当該データは、ユーザ機器のバッファの中のデータの優先度に応じて、パケットデータユニットの中で生成される。全てのデータが適合できるがバッファ状態報告が適合できない場合を除き、ユーザ機器１２０は、優先度に従った第１のデータおよび第２のデータ、並びにバッファ状態報告を、パケットデータユニットの中に含める。当該パケットデータユニットは、後の送信時に基地局１１０に送信されるものとする。バッファ状態報告は、パケットデータユニットの中で生成される第１のデータおよび第２のデータを報告する。本ソリューションの第１の実施形態によれば、保留されている第１のおよび第２のスケジューリング要求は、この時点で取り消される。これは、図５の中のステップ５０４に対応する。

ステップ７４０ケースａ−II）。この時点で、スケジューリング要求の機会が発生する。すなわち、このスケジューリング要求の機会は、ケースａ）によれば、ＵＬ許可の受信とデータの送信との間に発生する。スケジューリング要求のトリガは、もはや保留されていない。したがって、ユーザ機器１２０は、基地局１１０にいずれのスケジューリング要求も送信しない。既に割り当てられたリソース上で送信されるバッファ状態報告の中で第１のデータおよび第２のデータは報告されるため、そのようにする必要はないので、これは良好である。

ステップ７５０ケースａ−II）。ユーザ機器１２０は、生成したパケットデータユニットの中でデータおよびバッファ状態報告を送信する。当該バッファ状態報告は、第１のデータおよび第２のデータを報告する。

したがって、ケースａ−I）およびケースａ−II）のいずれでも、いずれの不用なスケジューリング要求も送信されず、スケジューリング要求が意味することについて、基地局１１０において曖昧さがない。ケースａ−I）およびケースａ−II）の両方において、スケジューリング要求は、基地局１１０が予め気づいていなかった新たなデータがユーザ機器１２０の中にあることを意味する。図６について説明されたような同じエラーケースはまだ存在するが、本発明で起こる可能性は極めて小さい。

ここから、図８は、許可の受信とケースｂ）についての許可に対応するデータの送信との間に新たなデータが到着するシナリオにおける、本ソリューションに従った分析を説明する。ここで、ユーザ機器１２０はＵＬ許可の受信とデータの送信との間にスケジューリング要求の機会を有さず、次のスケジューリング要求の機会はデータ送信後に発生する。以下が実行されると仮定する。第１のデータがユーザ機器のバッファに到着した。これは、図５の中のステップ５０１に対応する。この第１のデータは、バッファ状態報告をトリガした。これは、図５の中のステップ５０２に対応する。また、この第１のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次のスケジューリング要求の機会にスケジューリング要求を送信するための第１のスケジューリング要求のトリガをトリガした。これは、図５の中のステップ５０３に対応する。スケジューリング要求の機会が発生し、第１のスケジューリング要求が基地局に送信される。第１のスケジューリング要求のトリガは、まだ保留されている。本ソリューションによれば、スケジューリング要求をトリガしたデータが、基地局１１０に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合に、スケジューリング要求のトリガが、取り消される。または、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合に、ユーザ機器１２０は、保留されているスケジューリング要求を取り消す。これらの場合のうちのいずれか最初に発生する方で取り消される。

ケースｂ−１）について、以下のステップが仮定される。

ステップ８００ケースｂ−I）。基地局に送信されたスケジューリング要求への応答として、ユーザ機器１２０は、送信についてのＵＬ許可を基地局から受信する。

ステップ８１０ケースｂ−I）。ある期間に、ユーザ機器１２０は、送信される第１のデータの一部または全部について、ＭＡＣＰＤＵのようなパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。パケットデータユニットは、後の送信時にユーザ機器１１０に送信されるものとする。バッファ状態報告は、第１のデータを報告する。本ソリューションの第１の実施形態によれば、保留されている第１のスケジューリング要求は、この時点で取り消される。これは、図５の中のステップ５０４に対応する。

ステップ８２０ケースｂ−I）。新たな第２のデータがユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告のトリガをトリガする。この第２のデータは、さらに、次の機会にスケジューリング要求を送信するための第２のスケジューリング要求のトリガを直接的にまたは間接的にトリガする。

ステップ８４０ケースｂ−I）。ユーザ機器１２０は、パケットデータユニットの中で生成された第１のデータを送信し、バッファ状態報告をパケットデータユニットの中に含める。当該バッファ状態報告は、（上記）第１のデータによりトリガされた。また、当該バッファ状態報告は、第１のデータを報告するが、第２のデータを報告しない。

ステップ８５０ケースｂ−I）。スケジューリング要求の機会は、ケースｂ）によれば、この時点で、すなわちデータの送信後に発生する。第２のスケジューリング要求のトリガは、この時点で保留されているので、ユーザ機器１２０は、この時点で基地局１１０にスケジューリング要求を送信する。第２のデータについてのスケジューリング要求はユーザ機器１１０にまだ送信されていないので、これは望ましい。ここで、第２のデータについてのスケジューリングが失われるリスクはない。

ケースｂ−II）について、以下のステップを仮定する。

ステップ８００ケースｂ−II）。基地局に送信されたスケジューリング要求への応答として、ユーザ機器１２０は、送信についてのＵＬ許可を基地局から受信する。

ステップ８２０ケースｂ−II）。新たな第２のデータがユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告をトリガする。この第２のデータは、さらに、バッファ状態報告を介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第２のスケジューリング要求のトリガをトリガする。このケースａ−II）では、ケースａ−Iと異なり、第２のデータは、パケットデータユニットの生成後の代わりに、パケットデータユニットの生成前に到着する。

ステップ８３０ケースｂ−II）。ある期間に、ユーザ機器１２０は、送信されるデータについて、ＭＡＣＰＤＵのようなパケットデータユニットを生成する。当該データは、ユーザ機器のバッファの中のデータの優先度に応じて、パケットデータユニットの中で生成される。ユーザ機器１２０は、優先度に従った第１のデータおよび第２のデータ、並びにバッファ状態報告を、パケットデータユニットの中に含める。当該パケットデータユニットは、後の送信時にユーザ機器１１０に送信されるものとする。バッファ状態報告は、パケットデータユニットの中で生成される第１のデータおよび第２のデータを報告する。本ソリューションの第１の実施形態によれば、保留されている第１のおよび第２のスケジューリング要求は、この時点で取り消される。これは、図５の中のステップ５０４に対応する。

ステップ８４０ケースｂ−II）。ユーザ機器１２０は、データおよびバッファ状態報告をパケットデータユニットの中で送信する。当該バッファ状態報告は、第１のデータおよび第２のデータを報告する。

ステップ８５０ケースｂ−II）。スケジューリング要求の機会は、ケースｂ）によれば、この時点で、すなわちデータの送信後に発生する。スケジューリング要求のトリガは、ステップ８３０で取り消されたので、保留されていない。第１のデータおよび第２のデータは既に送信され、またはＢＳＲの中で報告されるので、この場合にこれは良好である。

上記図５の中で参照された、スケジューリング要求のトリガをハンドリングするための方法のステップを実行するために、ユーザ機器１２０は、図９に示される構成を備える。

上記のように、ユーザ機器１２０は、基地局１１０に送信されるデータを受け取るように構成されるバッファ９００を備える。

ユーザ機器１２０は、スケジューリング要求のトリガを生成するように構成される生成部９２０を備える。当該スケジューリング要求のトリガは、取り消されるまで保留されている。上記生成は、到着したデータにより直接的にまたは間接的にトリガされる。

ユーザ機器は、取消し部９３０をさらに備える。

第１の実施形態によれば、取消し部９３０は、スケジューリング要求のトリガの生成をトリガしたデータが、基地局１１０に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、スケジューリング要求の生成をトリガしたデータが、基地局１１０に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されているスケジューリング要求のトリガを取り消すように、構成される。

第２の実施形態によれば、取消し部９３０は、保留されているスケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告され、またはスケジュールされたデータ信号の中に直接的に含まれたか、および、どのデータが、これらの２つの手段のいずれの中でも報告されていないかを、記録するように構成される。

組み合わせられた第１の実施形態および第２の実施形態によれば、取消し部９３０は、スケジューリング要求のトリガの生成をトリガしたデータが、基地局１１０に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、若しくは、スケジューリング要求の生成をトリガしたデータが、基地局１１０に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されているスケジューリング要求のトリガを取り消すように構成され、または、代わりに、保留されているスケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、および、どのデータが、報告されていないかを、記録するように構成される。

第２の実施形態、並びに、組み合わせられた第１の実施形態および第２の実施形態によれば、ユーザ機器１２０は、次のスケジューリング要求の機会が現れると、上記２つの手段のいずれでもまだ報告されていないデータをバッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信するように構成される送信部９４０を備える。

第１の実施形態および第２の実施形態によれば、送信部９４０は、次のスケジューリング要求の機会が現れると、バッファ状態報告の中でまだ報告されていないデータをバッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信するように構成される。

スケジューリング要求のトリガをハンドリングするための本メカニズムは、図９に示されるユーザ機器１２０の中のプロセッサ９５０のような１つ以上のプロセッサ、および本ソリューションの機能を実行するためのコンピュータプログラムコードを通して、実装され得る。上記プログラムコードは、また、例えば、ユーザ機器１２０内に読み込まれる場合に本ソリューションを実行するためのコンピュータプログラムコードを搬送するデータキャリアの形で、コンピュータプログラム製品（computer program product）として提供されてもよい。１つの当該キャリアは、ＣＤＲＯＭディスクの形であってもよい。しかしながら、データキャリアは、メモリスティック等の他のデータキャリアで実現可能である。コンピュータプログラムコードは、さらに、サーバ上で純粋なプログラムコードとして提供され、ユーザ機器１２０にダウンロードされてもよい。

図１０は、ユーザ機器１２０のある実施形態を示す。当該ユーザ機器１２０は、送受信機回路（無線周波数受信機フロントエンド、送信変調器／増幅器、等）と動作可能なように関連付けられた処理回路と、１つ以上の送信／受信アンテナとを含む。

ユーザ機器１２０は、例えば、モバイル端末、またはＬＴＥ標準に基づく無線通信システム内での動作のために構成された他の種類のユーザ機器である。いずれの場合も、ユーザ機器１２０は、ここで説明された実施形態のいずれかを実装するように構成される。例えば、処理回路は、１つ以上のベースバンドプロセッサを含んでもよい。少なくとも１つの実施形態では、処理回路は、デジタルシグナルプロセッサ（ＤＰＳ）または他のデジタルプロセッサ等の、１つ以上のマイクロプロセッサに基づく回路を含む。さらに、ユーザ機器１２０は、プログラム命令、構成およびプロビジョニングのデータ、作業用データ等を記憶するための、例えば不揮発性または揮発性の１つ以上のメモリ回路を含む、ということを当業者は理解するであろう。

とりわけ、ユーザ機器１２０内の処理回路は、アップリンク送信についてのデータをバッファリングするための、バッファ９００のようなアップリング送信バッファを含む。当該アップリンク送信バッファは、作業用メモリの予約された部分であってもよい。また、処理回路は、ここで説明され、また図９に関連する文章の中で言及したように、制御および処理の全てまたは一部を実装するための関連付けられたコントローラを含む。すなわち、取消し部９３０のようなコントローラの１つ以上の実施形態は、スケジューリング要求をトリガしたデータがバッファ状態報告ＭＡＣ制御要素の中に含まれる場合、またはスケジューリング要求をトリガしたデータが送信される場合のうち、上記のようにいずれか最初に発生する方で、保留されているスケジューリング要求を取り消すように構成される。ＬＴＥに照らすと、ユーザ機器１２０は、スケジューリング要求をトリガしたバッファ状態報告が取り消される場合に、保留されているスケジューリング要求を取り消すように構成されるものとして、理解されることが可能である。

代わりに、ユーザ機器のコントローラは、どのデータが含まれ、そうでなければどのデータがバッファ状態報告の中で報告され、およびどのデータがそうではないかを記録する、ハードウェア、ソフトウェア、またはそれらの組合せによって構成されることが可能である。したがって、スケジューリング要求の機会が出現すると、ユーザ機器１２０は、バッファ状態報告の中でまだ報告されていないデータを有する場合に、スケジューリング要求を送信する。（バッファ状態報告は送信されなくてもよい。例えば、バッファ状態報告が、送信のために組立てられたＭＡＣＰＤＵの中に含まれれば、十分である。）

実施形態１および２の両方は、同一の振るまいをもたらす。当該振るまいの利点は、その目的を果たす場合に保留されているＳＲを取り消すことが自然であるということである。これは、ＳＲをトリガしたデータがバッファ状態報告の中で報告される場合またはＳＲをトリガしたデータが送信される場合に取り消されるときにのみ、保証される。いずれかの他のソリューションは、曖昧なまたは不用な送信されるＳＲおよび／または不用な許可をもたらす。

いくつかの実施形態によると、本ソリューションは、以下のように見なされてもよい。スケジューリング要求がトリガされると、スケジューリング要求は、取り消されるまで、保留されているとみなされるものとする。ＭＡＣＰＤＵが組立てられて、バッファ状態報告をトリガした最後のイベントまでの（および含む）バッファの状態を含むバッファ状態報告をこのＰＤＵが含む場合、または、送信可能な全ての保留されているデータをアップリンク許可が収容できる場合に、全ての保留されているスケジューリング要求は取り消されるものとする。

単語「を含む（comprise）」または「を含む（comprising）」を使用する場合には、当該単号は、限定しないように、すなわち「の少なくとも１つからなる（consist at least of）」を意味するように解釈されるべきである。単語「生成された（built）」は、この文章では単語「組立てられた（assembled）」と等しい。

本発明は、上記好適な実施形態に限定されない。様々な代替手段、改良されたもの、および等価なものが、使用されてもよい。したがって、上記実施形態は、本発明の範囲を限定するように受け取られるべきではない。本発明の範囲は、添付の特許請求の範囲により定義される。

したがって、ケースａ）およびケースｂ）のいずれでも、いずれの不用なスケジューリング要求も送信されず、スケジューリング要求が意味することについて、基地局１１０において曖昧さがない。ケースａ）およびｂ）では、スケジューリング要求は、ユーザ機器１２０において基地局１１０が予め気づいていなかった新たなデータがあることを意味する。スケジューリング要求の機会６１５がパケットユニットの生成６１２前であるエラーケースがまだある。図１の中のケースａ）の分析と同様に、当該ケースでは、送信される追加のスケジューリング要求があり、また、ＳＲが意味することについて基地局１１０における曖昧さがある。しかし、図６でのあり得るエラーケースのように第２のデータの到着とパケットユニットの生成との間にＳＲの機会を有する可能性は、図１のように第２のデータの到着とデータの送信との間にＳＲの機会を有する可能性よりも、極めて小さい。

ステップ７１０ケースａ−I）。ある期間に、ユーザ機器１２０は、送信される第１のデータの一部または全部について、ＭＡＣＰＤＵのようなパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。パケットデータユニットは、後の送信時に基地局１１０に送信されるものとする。バッファ状態報告は、第１のデータを報告する。本ソリューションの第１の実施形態によれば、保留されている第１のスケジューリング要求は、この時点で取り消される。これは、図５の中のステップ５０４に対応する。

ステップ８１０ケースｂ−I）。ある期間に、ユーザ機器１２０は、送信される第１のデータの一部または全部について、ＭＡＣＰＤＵのようなパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。パケットデータユニットは、後の送信時に基地局１１０に送信されるものとする。バッファ状態報告は、第１のデータを報告する。本ソリューションの第１の実施形態によれば、保留されている第１のスケジューリング要求は、この時点で取り消される。これは、図５の中のステップ５０４に対応する。

ステップ８５０ケースｂ−I）。スケジューリング要求の機会は、ケースｂ）によれば、この時点で、すなわちデータの送信後に発生する。第２のスケジューリング要求のトリガは、この時点で保留されているので、ユーザ機器１２０は、この時点で基地局１１０にスケジューリング要求を送信する。第２のデータについてのスケジューリング要求は基地局１１０にまだ送信されていないので、これは望ましい。ここで、第２のデータについてのスケジューリングが失われるリスクはない。

ステップ８２０ケースｂ−II）。新たな第２のデータがユーザ機器のバッファに到着する。この第２のデータは、バッファ状態報告をトリガする。この第２のデータは、さらに、バッファ状態報告を介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第２のスケジューリング要求のトリガをトリガする。このケースｂ−II）では、ケースｂ−Iと異なり、第２のデータは、パケットデータユニットの生成後の代わりに、パケットデータユニットの生成前に到着する。

ステップ８３０ケースｂ−II）。ある期間に、ユーザ機器１２０は、送信されるデータについて、ＭＡＣＰＤＵのようなパケットデータユニットを生成する。当該データは、ユーザ機器のバッファの中のデータの優先度に応じて、パケットデータユニットの中で生成される。ユーザ機器１２０は、優先度に従った第１のデータおよび第２のデータ、並びにバッファ状態報告を、パケットデータユニットの中に含める。当該パケットデータユニットは、後の送信時に基地局１１０に送信されるものとする。バッファ状態報告は、パケットデータユニットの中で生成される第１のデータおよび第２のデータを報告する。本ソリューションの第１の実施形態によれば、保留されている第１のおよび第２のスケジューリング要求は、この時点で取り消される。これは、図５の中のステップ５０４に対応する。

Claims

スケジューリング要求のトリガをハンドリングするユーザ機器（１２０）における方法であって、前記ユーザ機器（１２０）はバッファ（９００）を備え、前記方法は：
基地局（１１０）に送信されるデータを受け取るステップ（５０１）と、
前記データは前記バッファ（９００）に到着することと、
スケジューリング要求のトリガを生成するステップ（５０３）と、
前記スケジューリング要求のトリガは、取り消されるまで保留されていることと、
前記生成するステップは、到着した前記データにより直接的にまたは間接的にトリガされることと、
前記スケジューリング要求のトリガの生成をトリガした前記データが、前記基地局（１１０）に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、前記スケジューリング要求の生成をトリガした前記データが、前記基地局（１１０）に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されている前記スケジューリング要求のトリガを取り消すステップ（５０４）と、
を含む、方法。
バッファ状態報告のトリガを生成するステップ（５０２）と、
バッファ状態報告のトリガの生成は、到着した前記データによりトリガされることと、
をさらに含み、
スケジューリング要求のトリガを生成する前記ステップ（５０３）は、到着した前記データによりトリガされた前記バッファ状態報告のトリガの前記生成によりトリガされることによって、到着した前記データにより間接的に実行される、
請求項１に記載の方法。
前記取り消すステップ（５０４）は、前記バッファ状態報告のトリガを取り消すこと、そして当該取り消すことが前記スケジューリング要求のトリガの取り消しをトリガすることにより、実行される、請求項２に記載の方法。
スケジューリング要求のトリガをハンドリングするユーザ機器（１２０）における方法であって、前記ユーザ機器（１２０）はバッファ（９００）を備え、前記方法は：
基地局（１１０）に送信されるデータを受け取るステップ（５０１）と、
前記データは前記バッファ（９００）に到着することと、
スケジューリング要求のトリガを生成するステップ（５０３）と、
前記スケジューリング要求のトリガは、取り消されるまで保留されていることと、
前記生成するステップは、到着した前記データにより直接的にまたは間接的にトリガされることと、
保留されている前記スケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告され、または前記スケジュールされたデータ信号の中に直接的に含まれたか、および、どのデータが、これらの２つの手段のいずれの中でも報告されていないかを、記録するステップ（５０５）と、
次のスケジューリング要求の機会が現れると、前記２つの手段のいずれでもまだ報告されていないデータを前記バッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信するステップ（５０６）と、
を含む、方法。
バッファ状態報告のトリガを生成するステップ（５０２）と、
バッファ状態報告のトリガの生成は、到着した前記データによりトリガされることと、
をさらに含み、
スケジューリング要求のトリガを生成する前記ステップ（５０３）は、到着した前記データによりトリガされた前記バッファ状態報告のトリガの前記生成によりトリガされることによって、到着した前記データにより間接的に実行される、
請求項４に記載の方法。
前記取り消すステップ（５０５）は、前記バッファ状態報告のトリガを取り消すこと、そして当該取り消すことが前記スケジューリング要求のトリガの取り消しをトリガすることにより、実行される、請求項５に記載の方法。
スケジューリング要求のトリガをハンドリングするユーザ機器（１２０）における方法であって、前記ユーザ機器（１２０）はバッファ（９００）を備え、前記方法は：
基地局（１１０）に送信されるデータを受け取るステップ（５０１）と、
前記データは前記バッファ（９００）に到着することと、
スケジューリング要求のトリガを生成するステップ（５０３）と、
前記スケジューリング要求のトリガは、取り消されるまで保留されていることと、
前記生成するステップは、到着した前記データにより直接的にまたは間接的にトリガされることと、
前記スケジューリング要求のトリガの生成をトリガした前記データが、前記基地局（１１０）に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、若しくは、前記スケジューリング要求の生成をトリガした前記データが、前記基地局（１１０）に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されている前記スケジューリング要求のトリガを取り消すステップ（５０４）と、
または、代わりに、保留されている前記スケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、および、どのデータが、報告されていないかを、記録するステップ（５０５）、並びに、次のスケジューリング要求の機会が現れると、前記バッファ状態報告の中でまだ報告されていないデータを前記バッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信するステップ（５０６）と、
を含む、方法。
バッファ状態報告のトリガを生成するステップ（５０２）と、
バッファ状態報告のトリガの生成は、到着した前記データによりトリガされることと、
をさらに含み、
スケジューリング要求のトリガを生成する前記ステップ（５０３）は、到着した前記データによりトリガされた前記バッファ状態報告のトリガの前記生成によりトリガされることによって、到着した前記データにより間接的に実行される、
請求項７に記載の方法。
前記取り消すステップ（５０４、５０５）は、前記バッファ状態報告のトリガを取り消すこと、そして当該取り消すことが前記スケジューリング要求のトリガの取り消しをトリガすることにより、実行される、請求項８に記載の方法。
スケジューリング要求のトリガをハンドリングするユーザ機器（１２０）であって：
基地局（１１０）に送信されるデータを受け取るように構成されるバッファ（９００）と、
スケジューリング要求のトリガを生成するように構成される生成部（９２０）であって、当該スケジューリング要求のトリガは取り消されるまで保留され、当該生成は到着した前記データにより直接的にまたは間接的にトリガされる、前記生成部（９２０）と、
前記スケジューリング要求のトリガの生成をトリガした前記データが、前記基地局（１１０）に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、前記スケジューリング要求の生成をトリガした前記データが、前記基地局（１１０）に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されている前記スケジューリング要求のトリガを取り消すように構成される取消し部（９３０）と、
を備えるユーザ機器（１２０）。
スケジューリング要求のトリガをハンドリングするユーザ機器（１２０）であって：
基地局（１１０）に送信されるデータを受け取るように構成されるバッファ（９００）と、
スケジューリング要求のトリガを生成するように構成される生成部（９２０）であって、当該スケジューリング要求のトリガは取り消されるまで保留され、当該生成は到着した前記データにより直接的にまたは間接的にトリガされる、前記生成部（９２０）と、
保留されている前記スケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告され、または前記スケジュールされたデータ信号の中に直接的に含まれたか、および、どのデータが、これらの２つの手段のいずれの中でも報告されていないかを、記録するように構成される取消し部（９３０）と、
を備え、
前記ユーザ機器（１２０）は、
次のスケジューリング要求の機会が現れると、前記２つの手段のいずれでもまだ報告されていないデータを前記バッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信するように構成される送信部（９４０）
をさらに備える、ユーザ機器。
スケジューリング要求のトリガをハンドリングするユーザ機器（１２０）であって：
基地局（１１０）に送信されるデータを受け取るように構成されるバッファ（９００）であって、前記データは前記バッファ（９００）に到着する、前記バッファと、
スケジューリング要求のトリガを生成するように構成される生成部（９２０）であって、当該スケジューリング要求のトリガは取り消されるまで保留され、当該生成は到着した前記データにより直接的にまたは間接的にトリガされる、前記生成部（９２０）と、
前記スケジューリング要求のトリガの生成をトリガした前記データが、前記基地局（１１０）に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、若しくは、前記スケジューリング要求の生成をトリガした前記データが、前記基地局（１１０）に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されている前記スケジューリング要求のトリガを取り消すように構成される取消し部（９３０）と、
または、代わりに、保留されている前記スケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、および、どのデータが、報告されていないか、並びに、次のスケジューリング要求の機会がいつ現れるかを、記録するように構成される取消し部（９３０）と、
を備え、
前記ユーザ機器は、
前記バッファ状態報告の中でまだ報告されていないデータを前記バッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信するように構成される送信部（９４０）
をさらに備える、ユーザ機器。