【文献】
"Scheduling request triggering criterions for LTE",3GPP TSG-RAN WG2 #59 Tdoc R2-073209,2007年 8月24日,URL,http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_59/Docs/R2-073209.zip
【文献】
"CHANGE REQUEST",3GPP TSG-RAN2 Meeting #65 R2-091651,2009年 2月13日,URL,http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_65/Docs/R2-091651.zip
(58)【調査した分野】(Int.Cl.,DB名)
基地局へのアップリンクデータ送信のために前記基地局がユーザ機器をスケジュールすること、を要求するための前記ユーザ機器における方法であって、前記ユーザ機器はバッファを備え、前記方法は、
スケジューリングされるアップリンクデータ送信を介して前記基地局へ送信されるべきデータを前記バッファへ受け入れることと、
前記基地局へ前記バッファのサイズを報告するバッファ状態報告の中で報告されていないデータであって、その時点でスケジュールされているアップリンクデータ送信に直接的に含まれることにもならない当該データを前記バッファが含む場合にのみ、次のスケジューリング要求機会が発生した際に、前記基地局へスケジューリング要求を送信することと、
を含む方法。
保留されている前記スケジューリング要求トリガを取り消すことは、前記バッファ状態報告トリガを取り消し、転じて前記スケジューリング要求トリガの取り消しをトリガすること、を含む、請求項3の方法。
前記ユーザ機器は、前記データの前記バッファへの到着に応じて、直接的に又は間接的にスケジューリング要求トリガを生成する、ように構成される生成回路、をさらに備え、前記スケジューリング要求トリガは、前記次のスケジューリング要求機会において当該トリガが保留中である場合に前記基地局へのスケジューリング要求の前記送信をトリガするように、及び、取り消されるまで保留されるように構成され、
前記ユーザ機器は、前記データがバッファ状態報告の中で報告される場合、又は前記データがその時点でスケジュールされているアップリンクデータ送信に含まれることになる場合、のうちのいずれか最初に発生する方で、保留されている前記スケジューリング要求トリガを取り消す、ように構成される取り消し回路、をさらに備え、
前記送信回路は、次のスケジューリング要求機会においてスケジューリング要求トリガが保留中である場合にのみ、当該次のスケジューリング要求機会が発生した際に前記基地局へスケジューリング要求を送信する、ように構成される、
請求項7のユーザ機器。
前記取り消し回路は、前記バッファ状態報告トリガを取り消し、転じて前記スケジューリング要求トリガの取り消しをトリガする、ことにより、保留されている前記スケジューリング要求トリガを取り消す、ように構成される、請求項9のユーザ機器。
バッファ状態報告の中で前記バッファ内のどのデータが報告されたか、及びその時点でスケジュールされているアップリンクデータ送信に前記バッファ内のどのデータが直接的に含まれることになるか、を判定し、並びに、どのデータがバッファ状態報告の中で報告されておらず、その時点でスケジュールされているアップリンクデータ送信に直接的に含まれることにもならないか、を判定する、ように構成される取り消し回路、をさらに備え、
前記送信回路は、前記取り消し回路における前記判定に従って、バッファ状態報告の中で報告されていないデータであって、その時点でスケジュールされているアップリンクデータ送信に直接的に含まれることにもならない当該データを前記バッファが含む場合にのみ、次のスケジューリング要求機会が発生した際に前記基地局へスケジューリング要求を送信する、ように構成される、
請求項7のユーザ機器。
前記送信回路は、バッファ状態報告の中で報告されていないデータであって、その時点でスケジュールされている前記基地局へ送信されるべきパケットデータユニットに直接的に含まれることにもならない当該データを前記バッファが含む場合にのみ、次のスケジューリング要求機会が発生した際に前記基地局へスケジューリング要求を送信する、ように構成される、請求項7のユーザ機器。
【背景技術】
【0002】
無線通信システムとも呼ばれる典型的なセルラー無線システムでは、モバイル端末および/または無線端末としても知られるユーザ機器(UE)が、無線アクセスネットワーク(RAN)を介して1つ以上のコアネットワークに通信する。ユーザ機器は、「セルラー方式」電話としても知られるモバイル電話、およびモバイル端末等の無線のケイパビリティを伴うラップトップ等の移動局またはユーザ機器ユニットであってもよい。したがって、ユーザ機器は、例えば、携帯用の、小型の、手持ちできる、コンピュータに含まれる、または車載のモバイル装置であって、無線アクセスネットワークで音声および/またはデータを伝達するモバイル装置であってもよい。
【0003】
無線アクセスネットワークは、無線基地局(RBS)等の基地局が各セルエリアにサービスを提供するようにしながら、セル領域に分割される地理的な領域をカバーする。上記基地局は、いくつかのネットワークでは、「eNB」、「Node B」または「B node」とも呼ばれ、本明細書では基地局と呼ばれる。セルは、基地局サイトにおける無線基地局装置により無線カバレッジが提供される地理的な領域である。基地局は、無線周波数上で動作するエアインターフェースを通して、当該基地局の範囲内のユーザ機器ユニットと通信する。
【0004】
2008年末において、3GPPのLTE(Long Term Evolution)標準の最初のリリースであるリリース8が最終決定され、リリース9がその時点で進行中である。E−UTRA(Evolved Universal Terrestrial Radio Access)は、LTEにおいて使用されるエアインターフェースである。
【0005】
無線通信システムにおいて、無線アップリンク(UL)は、ユーザ機器から基地局への伝送路であり、無線ダウンリンクは、基地局からユーザ機器への伝送路である。LTEのリリース8では、既存のデータよりもより高い優先度の新たなULデータ、または先行するデータがない場合のいずれかの優先度の新たなデータの、UEのバッファへの到着は、いわゆるレギュラーバッファ状態報告(Buffer Status Report:BSR)をトリガする(trigger)。これには付帯条件がある。例えば、論理チャネルグループ(LCG)に属する論理チャネルについてのデータのみが考慮される。また、「新たなULデータの到着」は、ULデータが無線リンクコントローラ(RLC)エンティティまたはパケットデータコンバージェンスプロトコル(PDCP)エンティティで送信可能になる場合として定義される。PDCPは、RLCエンティティの上位層である。
【0006】
しかしながら、基本的な考え方は、新たなULデータの到着がレギュラーBSRをトリガすることの中でとらえられる。そして、レギュラーBSRが、スケジューリング要求(scheduling request:SR)をトリガする。SRのトリガ(trigger)は、SRを基地局に伝達させる。そして、基地局は、送信したい新たなデータをユーザ機器が有することを通知される。SRは、ユーザ機器の予め割り当てられた、物理アップリンク制御チャネル(PUCCH)上のスケジューリング要求のリソース上で送信され、したがってユーザ機器に専用のリソールで送信されるので専用SR(D−SR)として知られ、または、物理ランダムアクセスチャネル(PRACH)上で送信され、したがってランダムアクセスSR(RA−SR)として知られる。両方のケースで、SRを送信するための機会に関連付けられる一定の周期性がある。これは、当該機会が利用可能になるまでユーザ機器は待機しなければならないことを意味する。
【0007】
基地局がD−SRを受信すると、基地局は典型的にはUL許可(grant)を発行する。ユーザ機器は、上記許可上で送信する場合に、バッファのサイズを表すいわゆるBSR媒体アクセス制御(MAC)制御要素の形でBSRを含むMACパケットデータユニット(PDU)を送信する。BSRは、BSR MAC制御要素を含むMACパケットデータユニット(PDU)が生成された後に、バッファ状態を反映するように強制される。全てのデータがMAC PDUに適合できるが、当該データに加えてバッファ状態報告のための十分な余地がない場合を除き、BSRのトリガがMAC PDUの作成時にユーザ機器において保留されていれば、BSRは常に含まれる。
【0008】
ユーザ機器のバッファのサイズが基地局に報告されると、ユーザ機器がどのくらいのデータを送信しなければならないかは基地局にとって既知であるので、ユーザ機器が追加のSRを送信する必要はない。したがって、ユーザ機器が次のD−SRの機会にいずれかのD−SRを送信しないように、SRのトリガはユーザ機器において取り消されることが可能である。
【0009】
以下では、以下の用語が使用されることに留意する。
【0010】
「新たなデータの到着」という用語は、レギュラーBSRをトリガするための全ての付帯条件が満たされた上でのユーザ機器のバッファにおける新たなULデータの到着を示すために使用される。
【0011】
「許可の受信」という用語は、新たな信号のためのアップリンク共有チャネル(UL−SCH)のリソースについての物理ダウンリンク制御チャネル(PDCCH)の許可の受信を示すために使用される。
【0012】
「データの送信」という用語は、新たな信号のために利用可能にされたUL−SCHリソース上でのULデータの送信を示すために使用される。
【0013】
「SR」および「スケジューリング要求」という用語は、PUCCH上のD−SRのシグナリングを示すために使用される。
【0014】
「SRのトリガ」および「スケジューリング要求のトリガ」という用語は、保留されている(pending)SRを示すために使用される。
【0015】
「バッファ状態報告が第1のデータを報告する(account for)」等の表現が使用される場合に、それは、バッファ状態報告が含まれる信号が受信された後の第1のデータの残りの何でもバッファ状態報告が反映することを意味する。
【0016】
これまでのところ、SRは取り消されるまで保留されているとみなされる、すなわちSRの送信をトリガするSRのトリガは取り消されるまで保留されているとみなされる、ということが決定される。SRのトリガは、第1の送信時間間隔(TTI)候補の中で取り消され、当該TTIで、新たな送信のためのUL−SCHのリソースが許可される。TTIは、サブフレームとしても知られる。
【0017】
さらに、UL−SCHのリソースがこのTTIの中で新たな送信に利用可能である場合に、PDCCHの許可の受信時に、またはUL−SCHのリソースが利用可能であったTTIで、UL−SCHリソースがいつ許可されたが不明確であると考えられたため、全ての保留されているSRが取り消されるべきである、ということが最近決定された。説明(clarification)では、SRはUL−SCHリソースが利用可能であるTTIの中で取り消されるということが示されている。
【発明を実施するための形態】
【0027】
本発明の一部として、まず問題が識別され解説される。上記のように、UL−SCHのリソースがTTIの中で新たな送信に利用可能である場合に、PDCCHの許可の受信時に、またはUL−SCHのリソースが利用可能であったTTIで、UL−SCHリソースがいつ許可されたが不明確であると考えられたため、全ての保留されているSRが取り消されるべきである、ということが最近決定された。ここで、最近の決定に従って、UL−SCHのリソースが利用可能であるTTIで、すなわち新たなデータの送信時に、保留されているSRのトリガを取り消すケースを検討する。
【0028】
図1は、第1のデータについての許可が受信される前に新たな第2のデータがユーザ機器のバッファに到着する場合に、ULデータの送信時にスケジューリング要求を取り消すための代替手段の分析を説明する。以下が実行されたと仮定する。第1のデータがユーザ機器のバッファに到着した。第1のデータが、バッファ状態報告をトリガした。また、この第1のデータは、次のスケジューリング要求の機会にスケジューリング要求を送信するための第1のスケジューリング要求のトリガを直接的にまたは間接的にトリガした。スケジューリング要求の機会が発生し、第1のスケジューリング要求が基地局に送信された。第1のスケジューリング要求のトリガは、まだ保留されている。当該トリガは、ULデータの送信時に取り消されるであろう。時系列を見ると、2つの異なる出現するケース、すなわち
図1において説明されるケースa)およびb)がある。ケースa)では、ユーザ機器は、UL許可の受信とデータの送信との間にスケジューリング要求の機会を有する。ケースb)では、ユーザ機器は、UL許可の受信とデータの送信との間にスケジューリング要求の機会を有しない。次のSRの機会は、データの送信の後に発生する。
【0029】
ケースa)について、以下のステップを仮定する。
【0030】
ステップ100。新たな第2のデータが、ユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告のトリガをトリガする。この第2のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会に第2のデータについてのスケジューリング要求を送信するための第2のスケジューリング要求のトリガをトリガする。
【0031】
ステップ110。基地局に送信された第1のスケジューリング要求への応答として、ユーザ機器は、送信についてのUL許可を基地局から受信する。
【0032】
ステップ115。第1のおよび第2のスケジューリング要求のトリガは、保留されている。これは、ユーザ機器が次のスケジューリング要求の機会にスケジューリング要求を基地局に送信することを意味する。この時点で、スケジューリング要求の機会が発生する。すなわち、このスケジューリング要求の機会は、ケースa)によれば、UL許可の受信とデータの送信との間に発生する。したがって、許可が既に受信されているが、ユーザ機器は、基地局にスケジューリング要求を再度送信する。これは、送信する必要がなく、受信する基地局を混乱させる。これは不利益である。
【0033】
ステップ120。このステップでは、ユーザ機器は、基地局に送信する。許可は単にリソースの許可であるので、ユーザ機器の信号が第1のデータまたは第2のデータからのデータを含むかを確実に知ることはできず、ユーザ機器はどのデータを送信すべきか決定する。第2のデータの一部が送信される場合、第2のデータは第1のデータよりも高い優先度のものであり得る。しかしながら、全てのデータが信号に適合できるがバッファ状態報告が信号に適合しない場合を除き、バッファ状態報告も基地局への信号の中に含まれる。もし含まれると、バッファ状態報告は、スケジュールされた信号が作成された後の第1のデータの残りの何でもおよび第2のデータを報告する。この例でのルールは、ULデータの送信時にSRを取り消すことであるので、ユーザ機器は、両方の保留されているSRトリガをこの時点で取り消す。しかしながら、基地局は、第2のスケジューリング要求115をどのように解釈すべきかを知らない。第2のスケジューリング要求に基づいて、基地局は、信号(120)の中で報告されていないさらなるデータがあると考える新たな許可を送信し得る。信号(120)の中で送信されるバッファ状態報告が空のバッファを反映する場合に、当該新たな許可は、パディングされたビットを送信することにより満たされるのみである。これは、両方の許可およびパディングされた信号が不用であり、他のユーザ機器のために使用できたリソースをとった、ということを意味する。
【0034】
ケースb)について、より小さい問題がある。以下のステップを仮定する。
【0035】
ステップ100。新たな第2のデータがユーザ機器のバッファに到着する。第2のデータは、バッファ状態報告のトリガをトリガする。この第2のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会に第2のデータについてのスケジューリング要求を送信するための第2のスケジューリング要求のトリガをトリガする。
【0036】
ステップ110。基地局に送信された第1のスケジューリング要求に応じて、ユーザ機器は、送信についてのUL許可を基地局から受信する。
【0037】
ステップ120。ユーザ機器は、基地局に送信する。再び、ユーザ機器の信号が第1のデータまたは第2のデータからのデータを含むかを確実に知ることはできない。バッファ状態報告は、基地局への信号の中に含まれる。第2のデータが許可の前に到着したので、当該バッファ状態報告は、第1のデータおよび第2のデータを報告する。この例でのルールは、ULデータの送信時にスケジューリング要求を取り消すことであるので、ユーザ機器は、両方の保留されているスケジューリング要求のトリガをこの時点で取り消す。これは、さらなるスケジューリング要求を送信しなくてもよいため好ましい。
【0038】
ステップ125。スケジューリング要求の機会は、ケースb)によれば、この時点で、すなわちデータの送信後に発生する。ユーザ機器は、ケースa)でのようにUL許可の受信とデータの送信との間にスケジューリング要求の機会を有しなかった。スケジューリング要求のトリガは、取り消され、したがってもはや保留されていない。これは、ユーザ機器がこの次のスケジューリング要求の機会に基地局にスケジューリング要求を再度送信しないということを意味する。スケジューリング要求が送信時に取り消されたことは問題ない。第2のデータが許可の前に到着したので、当該第2のデータは、バッファ状態報告の中で報告され、または信号の中に完全に含まれる、ということが保証される。それは好ましく、かつ安全である。
【0039】
ケースa)では、スケジューリング要求が発生する際に、スケジューリング要求のトリガはまだ取り消されていない。したがって、ユーザ機器は前回のスケジューリング要求に応じて既に許可を受信しているが、新たなスケジューリング要求が送信される。示されたケースでは、第2のスケジューリング要求の必要はないが、ユーザ機器は、仕様により第2のスケジューリング要求を送信するように強制される。スケジューリング要求は、物理アップリンク制御チャネル(PUCCH)上の不用な干渉を生み出すので、これは、ユーザ機器のエネルギーおよび無線リソースの浪費である。したがって、この余分なスケジューリング要求は不用であり、よってこれは不利益である。さらに、上記の不用なスケジューリング要求に応じて基地局が何をすべきかが不明である。ユーザ機器が第1のデータを受信したが第2のデータを受信しなかった場合であっても、余分な不要なスケジューリング要求およびその望ましくない結果を伴う同一の手順がケースa)で発生し、よって、それは珍しいシナリオではない、ということに留意する。
【0040】
しかしながら、
図2および
図3に関連する以下の例では、より悪い問題を伴うさらに複雑なケースがある。当該ケースでは、第1のスケジューリング要求に対応する許可が受信された後に、ユーザ機器がバッファへの新たなデータを取得する。この新たなデータは、スケジューリング要求のトリガをトリガする。時系列を見ると、2つの異なる出現するケース、すなわち
図2において説明されるケースa)および
図3において説明されるケースb)がある。この例では、
図1に関連するケースa)での例のように、ユーザ機器は、UL許可の受信とデータの送信との間にスケジューリング要求の機会を有する。ケースb)では、ユーザ機器は、UL許可の受信とデータの送信との間にスケジューリング要求の機会を有しない。次のスケジューリング要求の機会は、データの送信後に発生する。
【0041】
ケースa)およびケースb)では、2つの個別の代替手段、すなわち代替手段Iおよび代替手段IIがある。
図2は、ケースa)の代替手段Iおよびケースa)の代替手段IIを示し、
図3は、ケースb)の代替手段Iおよびケースb)の代替手段IIを示す。
【0042】
ここから、
図2は、許可の受信とケースa)についての許可に対応するデータの送信との間に新たなデータが到着し、ユーザ機器がUL許可の受信とデータの送信との間にSRの機会を有する場合に、ULデータの送信時にSRを取り消すための、代替手段の分析を説明する。以下が実行されたと仮定する。第1のデータがユーザ機器のバッファに到着した。第1のデータが、バッファ状態報告のトリガをトリガした。また、この第1のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次のスケジューリング要求の機会にスケジューリング要求を送信するための第1のスケジューリング要求のトリガをトリガした。SRの機会が発生し、第1のスケジューリング要求が基地局に送信される。第1のスケジューリング要求のトリガは、まだ保留されている。当該トリガは、ULデータの送信時に取り消されるであろう。
【0043】
ケースa−I)について、以下のステップが仮定される。
【0044】
ステップ200 ケースa−1)。基地局に送信されたSRへの応答として、ユーザ機器は、送信についてのUL許可を基地局から受信する。
【0045】
ステップ210 ケースa−1)。ある期間に、ユーザ機器は、送信される第1のデータの一部または全部について、MAC PDUのようなパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。当該パケットデータユニットは、後の送信時に基地局に送信されるものとする。バッファ状態報告は、第1のデータを報告する。
【0046】
ステップ220 ケースa−1)。新たな第2のデータが、ユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告をトリガする。この第2のデータは、さらに、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第2のスケジューリング要求のトリガをトリガする。第1のデータおよび第2のデータの両方によりトリガされた、第1のスケジューリング要求のトリガおよび第2のスケジューリング要求のトリガは、保留されている。
【0047】
ステップ240 ケースa−1)。この時点で、スケジューリング要求の機会が発生する。すなわち、このスケジューリング要求の機会は、ケースa)によれば、UL許可の受信とデータの受信との間に発生する。したがって、スケジューリング要求はまだ取り消されていないので、ユーザ機器は基地局に第2のスケジューリング要求を送信する。第2のデータがユーザ機器のバッファで入手可能になる前に、送信される第1のデータの一部または全部を含むパケットデータユニットをユーザ機器が既に生成しているので、これは必要である。したがって、第2のデータは、送信時に送信されるバッファ状態報告の中で報告されない。
【0048】
ステップ250 ケースa−1)。ユーザ機器は、バッファ状態報告を含むパケットデータユニットを送信する。当該バッファ状態報告は、(上記)第1のデータによりトリガされる。また、当該バッファ状態報告は、第1のデータを報告するが、第2のデータを報告しない。この例のルールは、ULデータの送信時にスケジューリング要求を取り消すことであるので、ユーザ機器は、両方の保留されているスケジューリング要求のトリガをこの時点で取り消す。この時点で、送信された第2のスケジューリング要求をどのように解釈すればよいかを知ることは基地局にとって困難である。すなわち、第2のスケジューリング要求が、第2のデータに対応するか、または、第2のスケジューリング要求が、スケジューリング要求のトリガがまだ取り消されていない第1のデータに対応するかは、基地局には分からない。基地局は、許可を送信しなければ、バッファの中のデータを伴うユーザ機器が送信できないままにする、というリスクを負う。また、基地局は、新たな許可を送信すれば、この許可が不用であり、対応する信号がパディングのみとなる、というリスクを負う。さらに、PUCCH上の過度の干渉またはPUCCHのカバレッジの問題のため等で、第2のスケジューリング要求が基地局により受けられなければ、スケジューリング要求のトリガはここで取り消され、たとえ新たな許可が第2のデータについて受信されなくても、新たなスケジューリング要求は送信されない。これは、ユーザ機器が第2のデータを送信するための許可を基地局から取得できず、基地局が第2のデータの存在について知らないので、第2のデータがユーザ機器内に残る、ということを意味する。
【0049】
ケースa−II)について、以下のステップを仮定する。
【0050】
ステップ200 ケースa−II)。基地局に送信された第1のスケジューリング要求への応答として、ユーザ機器は、送信についてのUL許可を基地局から受信する。
【0051】
ステップ220 ケースa−II)。新たな第2のデータが、ユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告のトリガをトリガする。この第2のデータは、さらに、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第2のスケジューリング要求のトリガをトリガする。このケースa−II)では、ケースa−Iとは異なり、第2のデータは、パケットデータユニットの生成後の代わりに、パケットデータユニットの生成前に到着する。
【0052】
ステップ230 ケースa−II)。ある期間に、ユーザ機器は、送信されるデータについて、MAC PDUのようなパケットデータユニットを生成する。当該データは、ユーザ機器のバッファの中のデータの優先度に応じて、パケットデータユニットの中で生成される。全てのデータが適合できるがバッファ状態報告が適合できない場合を除き、ユーザ機器は、優先度に従った第1のデータおよび第2のデータ、並びにバッファ状態報告を、パケットデータユニットの中に含める。当該パケットデータユニットは、後の送信時に基地局に送信されるものとする。当該パケットデータユニットは、後の送信時に基地局に送信されるものとする。
【0053】
ステップ240 ケースa−II)。第1のおよび第2のスケジューリング要求のトリガは、保留されている。この時点で、スケジューリング要求の機会が発生する。すなわち、このスケジューリング要求の機会は、ケースa)によれば、UL許可の受信とデータの送信との間に発生する。したがって、ユーザ機器の両方のスケジューリング要求のトリガがまだ取り消されていないので、ユーザ機器は基地局にスケジューリング要求を再度送信する。まさに
図1のaのように、第1のデータおよび第2のデータの両方が、既に割り当てられたリソース上で送信されるバッファ状態報告の中に含まれるので、これはこの場合に不用である。
【0054】
ステップ250 ケースa−II)。ユーザ機器は、生成されたパケットデータユニットの中でデータおよびバッファ状態報告を送信する。当該バッファ状態報告は、第1のデータおよび第2のデータを報告する。この例でのルールは、ULデータの送信時にスケジューリング要求を取り消すことであるので、ユーザ機器は、両方の保留されているスケジューリング要求のトリガをこの時点で取り消す。
【0055】
ケースa)、すなわちケースa−I)およびケースa−II)の両方では、余分なスケジューリング要求が送信される。しかし、基地局は、当該スケジューリング要求を受信する場合に、2つのスケジューリング要求を受信したことを知るのみであり、ケースa−I)とケースa−II)とを区別することができない。すなわち、基地局は、同一のデータが両方のスケジューリング要求の裏にあるか、または、第2のスケジューリング要求について追加のデータが受信されたか、を区別することができない。それに応じて、バッファ状態報告が生成された後に新たなデータが到着した可能性があるので、受信したバッファ状態報告がユーザ機器のバッファのサイズを実際に反映しているかは基地局には分からない。したがって、基地局は、推測しなければならず、その推測に応じて、許可を浪費し、または新たなデータを見失う、というリスクを負う。そして、基地局は、新たなデータが報告されなかったために、ユーザ機器について不正確なバッファのサイズの推定を有する。
【0056】
図3は、許可の受信とケースb)についての許可に対応するデータの送信データの送信との間に新たなデータが到着し、ユーザ機器がUL許可の受信とデータの送信との間にスケジューリング要求の機会を有さず、次のスケジューリング要求の機会がデータの送信後に発生する場合に、ULデータの送信時にスケジューリング要求を取り消すための、代替手段の分析を説明する。以下が実行されたと仮定する。第1のデータがユーザ機器のバッファに到着した。この第1のデータが、バッファ状態報告のバッファをトリガした。また、この第1のデータが、バッファ状態報告のトリガを介して直接的にまたは間接的に、次のスケジューリング要求の機会にスケジューリング要求を送信するための第1のスケジューリング要求のトリガをトリガした。スケジューリング要求の機会が発生し、第1のスケジューリング要求が基地局に送信される。第1のスケジューリング要求のトリガは、まだ保留されている。当該トリガは、ULデータの送信時に取り消されるであろう。
【0057】
ケースb−I)について、以下のステップが仮定される。
【0058】
ステップ300 ケースb−I)。基地局に送信されたスケジューリング要求への応答として、ユーザ機器は、送信についてのUL許可を基地局から受信する。
【0059】
ステップ310 ケースb−I)。ある期間に、ユーザ機器は、送信される第1のデータの一部または全部について、MAC PDUのようなパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。パケットデータユニットは、後の送信時に基地局に送信されるものとする。バッファ状態報告は、第1のデータを報告する。
【0060】
ステップ320 ケースb−I)。新たな第2のデータが、ユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告をトリガする。この第2のデータは、さらに、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第2のスケジューリング要求のトリガをトリガする。
【0061】
ステップ340 ケースb−I)。ユーザ機器は、パケットデータユニットの中で生成された第1のデータを送信し、パケットデータユニットの中にバッファ状態報告を含める。当該バッファ状態報告は、第1のデータによりトリガされた。また、当該バッファ状態報告は、第1のデータを報告するが、第2のデータを報告しない。この例でのルールは、ULデータの送信時にスケジューリング要求を取り消すことであるので、ユーザ機器は、両方の保留されているスケジューリング要求をこの時点で取り消す。これは、いずれのスケジューリング要求もこの時点で現れていないので、第2のデータについてのスケジューリング要求が基地局にまだ送信されていないとしても、ユーザのバッファの中に第2のデータがあることを示すための保留されているスケジューリング要求のトリガがもはやない、ということを意味する。このケースでは、第2のデータのために必要なスケジューリング要求が失われる。
【0062】
ステップ350 ケースb−I)。スケジューリング要求の機会は、ケースb)によれば、この時点で、すなわちデータの送信後に発生する。スケジューリング要求のトリガはステップ340で取り消されたので、いずれのスケジューリング要求のトリガも保留されていない。よって、上記のように、このケースでは、第2のデータについてのSRが失われる。これは好ましくない。
【0063】
ケースb−II)について、以下のステップが仮定される。
【0064】
ステップ300 ケースb−II)。基地局に送信された第1のスケジューリング要求への応答として、ユーザ機器は、送信についてのUL許可を基地局から受信する。
【0065】
ステップ320 ケースb−II)。新たな第2のデータが、ユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告のトリガをトリガする。この第2のデータは、さらに、次の機会にスケジューリング要求を送信するための第2のスケジューリング要求のトリガを直接的にまたは間接的にトリガする。このケースb−II)では、ケースb−I)とは異なり、第2のデータは、パケットデータユニットの生成後の代わりに、パケットデータユニットの生成前に到着する。
【0066】
ステップ330 ケースb−II)。ある期間に、ユーザ機器は、送信されるデータについて、MAC PDUのようなパケットデータユニットを生成する。当該データは、ユーザ機器のバッファの中のデータの優先度に応じて、パケットデータユニットの中で生成される。全てのデータが適合できるがバッファ状態報告が適合できない場合を除き、ユーザ機器は、優先度に従った第1のデータおよび第2のデータ、並びにバッファ状態報告を、パケットデータユニットの中に含める。当該パケットデータユニットは、後の送信時に基地局に送信されるものとする。バッファ状態報告は、第1のデータおよび第2のデータの両方を報告する。
【0067】
ステップ340 ケースb−II)。ユーザ機器は、パケットデータユニットの中でデータおよびバッファ状態報告を送信する。当該バッファ状態報告は、第1のデータおよび第2のデータを報告する。この例でのルールは、ULデータの送信時にSRを取り消すことであるので、ユーザ機器は、保留されているSRのトリガをこの時点で取り消す。
【0068】
ステップ350 ケースb−II)。SRの機会は、ケースb)によれば、この時点で、すなわちデータの送信後に発生する。SRのトリガはステップ340で取り消されたので、いずれのSRのトリガも保留されていない。第1のデータおよび第2のデータは既に送信されているか、またはBSRの中で報告されるので、このケースではこれは望ましい。
【0069】
見られるように、ケースb−II)は良好に機能するが、ケースb−I)は良好に機能しない。両方のケースで、トリガされた第2のスケジューリング要求のトリガは、第1のデータが送信された際に取り消されたので、決して送信されない。しかしながら、ケースb−I)のように、送信されるバッファ状態報告の中に第2のデータが含まれない場合に、基地局はこのデータについて知ることはないであろう。2つの事が当該状況を救い得る。許可上での信号はバッファ状態報告を含むので、ユーザ機器は、送信されていないスケジューリング要求に応じてではなく、他のデータについての許可を受信する。または、新たなSRが、さらに新たなデータの到着によりトリガされる。
【0070】
これらのうちの1つが起こらなければ、ユーザ機器は、「再送バッファ状態報告タイマ(retransmit buffer status report timer)」または「再送BSRタイマ(retx-BSR-Timer)」として知られるフィードバックメカニズムが終了し、スケジューリング要求をトリガするまで、新たなスケジューリング要求を送信する手段がない。しかしながら、このタイマは320msの最小値を有し、当該最小値はかなりの遅延を加える。
【0071】
したがって、無線通信ネットワークにおける性能を向上させるユーザ機器内のメカニズムを提供することが、本発明の目的はである。
【0072】
ここで本ソリューションに関して、
図4は、本ソリューションが実装される無線通信システム100を示す。無線通信システム100は、パケットに基づく通信システムである。当該通信システムは、LTE通信システム、WiMAX(Worldwide Interoperability for Microwave Access)、またはアップリンクスケジューリングについてのスケジューリング要求をハンドリングするいずれかの他の無線通信システムであってもよい。
【0073】
無線通信システム100は、セル115にサービスを提供する基地局110を含む。基地局110は、eNB、無線基地局(RBS)、またはセル内に存在するユーザ機器と無線キャリアを通して通信可能ないずれかの他のネットワークユニット等の無線基地局である。
【0074】
セル115内に存在するユーザ機器120は、基地局110によりサービスを提供され、したがって、無線チャネル125を通して基地局110にMAC PDUのようなデータパケットユニットを送信することができる。ユーザ機器120は、モバイル端末または無線端末等の端末、モバイル電話、例えばラップトップのようなコンピュータ、携帯情報端末(PDA)、またはエアインターフェースを通して基地局と通信可能ないずれかの他の無線ネットワークユニット等の、端末であってもよい。エアインターフェースは、例えば、LTEにおいて使用されるE−UTRAエアインターフェースであってもよい。
【0075】
ユーザ機器120はバッファを備える。基地局110に送信される新たなアップリンクデータが、当該バッファに到着する。当該データは、音声データ、映像データ、写真データ、テキストデータ、またはユーザが送信することを望み得るいずれかの他の種類のデータであってもよい。既存のデータよりもより高い優先度の新たなULデータ、または先行するデータがない場合のいずれかの優先度の新たなデータの、ユーザ機器のバッファへの到着は、バッファ状態報告をトリガする。到着した新たなデータは、さらに、保留されるスケジューリング要求のトリガを直接的にまたは間接的にトリガする。間接的にトリガすることは、到着したデータがバッファ状態報告をトリガし、そして当該バッファ状態報告がスケジューリング要求のトリガをトリガするように、実行され得る。スケジューリング要求のトリガは、次のスケジューリング要求の機会に基地局110に送信されるスケジューリング要求をトリガする。「スケジューリング要求のトリガ」は、「保留されているスケジューリング要求」と呼ばれてもよい。上記のように、基地局110にスケジューリング要求を送信するための機会に関連付けられる一定の周期性がある。よって、ユーザ機器120は、当該機会が利用可能になるまで待機しなければならない。スケジューリング要求を受信する基地局110は、そのようにして、送信したい新たなデータをユーザ機器120が有することを通知される。スケジューリング要求のトリガは、保留さているか、または保留されていない。スケジューリング要求は、典型的には、いずれかの特定の到着したデータと関連付けられない。また、スケジューリング要求のトリガは、当該トリガをトリガしたデータと暗黙的に関連付けられるが、いずれかのデータに関連付けられる必要はない。しかし、スケジューリング要求のトリガが既にトリガされていても、ここでは第2のデータと呼ばれるさらなるデータがユーザ機器のバッファに到着し、スケジューリング要求のトリガをトリガすると、さらなるスケジューリング要求がトリガされる。
【0076】
スケジューリング要求への応答として、基地局110は、典型的には、ユーザ機器120にアップリンク許可を送信する。許可は、ユーザ機器に固有であるが、当該ユーザ機器内のいずれかの特定の到着したデータと関連付けられない。eNBにより設定され、ユーザ機器120にシグナリングされる優先度は、ユーザ機器120に割り当てられたリソース上でどの特定のデータが送信されるべきかを決定する。
【0077】
無線通信ネットワークにおける性能を向上させるより信頼できるスケジューリング手順のハンドリングを行うために、本ソリューションによれば、保留されているスケジューリング要求のトリガは、以下のように取り消される。
【0078】
第1の実施形態では、スケジューリング要求をトリガしたデータが、基地局110に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されているスケジューリング要求が取り消される。この後者のケースでは、スケジュールされたデータは、少し後に送信されるパケットデータユニットの中にまさに含まれて、送信されなくてもよい。
【0079】
代わりに、第2の実施形態では、保留されているスケジューリング要求は、ユーザ機器によりいずれかの時点で取り消される。しかし、ユーザ機器は、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、およびどのデータが報告されていないかを記録する。そして、次のスケジューリング要求の機会が現れると、ユーザ機器120は、バッファ状態報告の中でまだ報告されていないデータをバッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信する。これは、第1の実施形態において、保留されているスケジューリング要求を有することに等しいが、必ずしも「保留されているスケジューリング要求を有する」と呼ばれなくてもよい。しかしながら、結果は同じであり、次のスケジューリング要求の機会に、バッファ状態報告にまだ含まれないデータがあり、また当該データがまだ送信されていなければ、ユーザ機器120はスケジューリング要求を送信する。
【0080】
いくつかの実施形態に従った、スケジューリング要求のトリガをハンドリングする基地局110における方法に関連する本ソリューションが、
図5に示されるフローチャートを参照して説明される。上記のように、ユーザ機器120はバッファを備える。
【0081】
方法は、以下のステップを含む。当該ステップは、また、以下に説明されるものよりも別の適切な順序で実行されてもよい。
【0082】
ステップ501
ユーザ機器120内のバッファは、基地局110に送信されるデータを受け取る。
【0083】
ステップ502
このステップは、オプションである。いくつかの実施形態によると、ユーザ機器120は、バッファ状態報告のトリガを生成する。当該バッファ状態報告のトリガは、到着したデータによりトリガされる。
【0084】
ステップ503
ユーザ機器120は、スケジューリング要求のトリガを生成する。当該スケジューリング要求のトリガは、取り消されるまで保留されている。また、生成は、到着したデータにより直接的にまたは間接的にトリガされる。スケジューリング要求のトリガを生成するこのステップが間接的に実行されるいくつかの実施形態では、当該生成は、到着したデータによりトリガされたバッファ状態報告のトリガの生成によりトリガされる。
【0085】
ステップ504
第1の実施形態によれば、スケジューリング要求をトリガしたデータが、基地局110に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、ユーザ機器120は、保留されているスケジューリング要求を取り消す。したがって、保留されているスケジューリング要求のトリガは、例えば、バッファ状態報告MAC制御要素を含むMAC PDUが生成されるのと同時に取り消されてもよい。
【0086】
MAC PDUのようなパケットデータユニットが生成される場合に、パケットデータユニットは、パケットデータユニットの生成後にユーザ機器のバッファ内に残っているデータを報告するBSR MAC制御要素のようなバッファ状態報告を含む。当該バッファ状態報告は、MAC PDUが生成される時にバッファ状態報告のトリガが保留されており、かつ全てのデータがMAC PDUに適合できない場合に、含まれる。
【0087】
スケジューリング要求をトリガしたデータが、BSR MAC制御要素により表されるバッファ状態報告の中に含まれる場合に、または、スケジューリング要求をトリガした全てのデータが、送信のためのMAC PDUの中に含まれている場合に、ユーザ機器120は、保留されているスケジューリング要求を取り消してもよい。LTE標準に照らすと、スケジューリング要求をトリガしたバッファ状態報告が取り消される場合に、ユーザ機器120が保留されているスケジューリング要求を取り消すこととして、当該動作方法を理解することができる。ここで、「場合に(when)」は、必ずしも時間における一致を暗示せず、保留されているスケジューリング要求をトリガした保留されているバッファ状態報告の取り消しに基づいて、保留されているスケジューリング要求が取り消されること、として理解されることが可能である。換言すると、少なくともある実施形態では、その時点においてスケジュールされたデータ信号が、対応するバッファ状態報告のトリガを生成させた新たなデータの全てを含む場合、または、次のその時点においてスケジュールされたデータ信号の中に含まれるバッファ状態報告(当該バッファ状態報告は、1つ以上の他の保留されているバッファ状態報告のトリガのために生成されたかもしれない)が、新たなデータを報告する場合に、例えば対応するバッファ状態報告のトリガが取り消されることによって、保留されているスケジューリング要求のトリガが取り消される。
【0088】
ステップ505
第2の実施形態によれば、ステップ504の代替手段として、ユーザ機器120は、保留されているスケジューリング要求をいずれかの時点で取り消すが、ユーザ機器120は、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、および、どのデータが報告されていないか、またいくつかの実施形態では、どのデータが、報告されておらず、スケジュールされたデータ信号の中に含まれてもいないか、を記録する。
【0089】
ステップ506
第2の実施形態によれば、次のスケジューリング要求の機会が現れると、ユーザ機器120は、バッファ状態報告の中でまだ報告されていないデータをバッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信する。
【0090】
この代わりの実施形態では、ユーザ機器120は、3GPPがテストすることが可能な振るまいをなお満たしつつ、ステップ504で第1の実施形態に従って取り消される時点の前または後であって望むときはいつでも、保留されているスケジューリング要求のトリガを内部で取り消してもよい。これは、上記のように、バッファ状態報告の中にまだ含まれていないデータ、またいくつかの実施形態によれば、バッファ状態報告の中にまだ含まれておらず、スケジュールされたULデータ信号の中にも含まれていないデータを、ユーザ機器120が記録することにより、実行される。これは、第1の実施形態において保留されているスケジューリング要求を有することに等しいが、必ずしも「保留されているスケジューリング要求を有する」と呼ばれなくてもよい。しかしながら、結果は同じであり、次のスケジューリング要求の機会に、バッファ状態報告にまだ含まれないデータがあり、また当該データがまだ送信されていなければ、ユーザ機器120はスケジューリング要求を送信する。
【0091】
さらに、上記のようないくつかの実施形態では、バッファ状態報告のトリガは、アップリンク送信バッファに入ってくる新たなデータに応じて生成されてもよい。また、スケジューリング要求のトリガは、バッファ状態報告のトリガに対応して生成されてもよい。したがって、アップリンク送信バッファに新たなデータを受け取ることは、新たなバッファ状態報告のトリガを生成させ、当該バッファ状態報告のトリガは、スケジューリング要求のトリガをもたらす。
【0092】
ここで教えられる1つ以上の実施形態では、保留されているバッファ状態報告のトリガおよび対応する保留されているスケジューリング要求のトリガの有利なハンドリングおよび取消しは、アップリンクデータがユーザ機器120で行き詰まることを防ぎ、および/または、不用なスケジューリング要求の送信および結果として起こる不用なアップリンクリソースの許可を防ぎ、若しくは少なくとも減らす。
【0093】
バッファ状態報告のトリガおよび対応するスケジューリング要求のトリガは、フラグまたは他の論理的な指標として実装されてもよく、当該フラグまたは他の論理的な指標は、セットされ、またはそうでなければ保留されている状態を示すように生成され、および、クリアされ、またはそうでなければ取消しのために削除されてもよい、ということも当業者は理解するであろう。
【0094】
図6は、第1のデータについての許可が受信される前に新たな第2のデータがユーザ機器のバッファに到着する場合に、第1の実施形態に従った本ソリューションの分析を説明する。すなわち、第1の実施形態は、スケジューリング要求をトリガしたデータが、基地局110に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合に、スケジューリング要求のトリガを取り消すことを含む。または、ユーザ機器120は、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合に、保留されているスケジューリング要求を取り消す。これらの場合のうちのいずれか最初に発生する方で取り消される。以下が実行されたと再度仮定する。第1のデータがユーザ機器のバッファに到着した。これは、
図5の中のステップ501に対応する。この第1のデータは、バッファ状態報告をトリガした。これは、
図5の中のステップ501に対応する。この第1のデータは、次のスケジューリング要求の機会にスケジューリング要求を送信するための第1のスケジューリング要求のトリガも直接的にまたは間接的にトリガした。これは、
図5の中のステップ503に対応する。スケジューリング要求の機会が発生し、第1のスケジューリング要求が基地局110に送信された。第1のスケジューリング要求のトリガは、まだ保留されている。時系列を見ると、2つの異なる出現するケース、すなわち
図6において説明されるケースa)およびb)がある。ケースa)では、ユーザ機器120は、UL許可の受信とデータの送信との間にスケジューリング要求の機会を有する。ケースb)では、ユーザ機器120は、UL許可の受信とデータの送信との間にスケジューリング要求の機会を有しない。次のスケジューリング要求の機会は、データの送信後に発生する。
【0095】
ケースa)について、以下のステップを仮定する。
【0096】
ステップ600。新たな第2のデータが、ユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告をトリガする。この第2のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第2のスケジューリング要求のトリガをトリガする。
【0097】
ステップ610。基地局110に送信された第1のスケジューリング要求への応答として、ユーザ機器120は、送信についてのUL許可を基地局110から受信する。
【0098】
ステップ612。ある期間に、ユーザ機器120は、送信される第1のデータおよび第2のデータの一部または全部について、MAC PDU等のパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。当該パケットデータユニットは、後の送信時に基地局110に送信されるものとする。本ソリューションによれば、全ての保留されているスケジューリング要求のトリガは、この時点で取り消され、全ての保留されているバッファ状態報告のトリガも、この時点で取り消される。
【0099】
ステップ615。第1のおよび第2のスケジューリング要求のトリガは、保留されていない。これは、ユーザ機器120は次のスケジューリング要求の機会に基地局110にスケジューリング要求を送信しないということを示す。この時点で、スケジューリング要求の機会が発生し、いずれのスケジューリング要求も送信されない。全てのデータがバッファ状態報告またはスケジュールされた信号の中のいずれかで報告されたので、これは望ましい。
【0100】
ステップ620。ユーザ機器120は、生成したパケットデータユニットを基地局110に送信する。
【0101】
ケースb)について、以下のステップを仮定する。
【0102】
ステップ600。新たな第2のデータが、ユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告のトリガをトリガする。この第2のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するためのスケジューリング要求のトリガをトガする。このステップは、ケースa)についてと同じである。
【0103】
ステップ610。基地局110に送信された第1のスケジューリング要求への応答として、ユーザ機器120は、送信についてのUL許可を基地局から受信する。このステップも、ケースa)についてと同じである。
【0104】
ステップ612。ある期間に、ユーザ機器120は、送信される第1のデータおよび第2のデータの一部または全部について、MAC PDU等のパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。当該パケットデータユニットは、後の送信時に基地局110に送信されるものとする。本ソリューションによれば、全ての保留されているスケジューリング要求のトリガは、この時点で取り消され、全ての保留されているバッファ状態報告のトリガも、この時点で取り消される。
【0105】
ステップ620。ユーザ機器120は、生成したパケットデータユニットを基地局110に送信する。再び、ユーザ機器120が第1のデータおよび第2のデータに従って送信したかを確実に知ることはできない。バッファ状態報告は、基地局110への信号の中に含まれる。第2のデータが許可の前に到着したので、当該バッファ状態報告は、第1のデータおよび第2のデータを報告する。この例でのルールは、スケジューリング要求をトリガしたデータが、基地局110に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、スケジューリング要求のトリガを取り消すことである。または、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合に、ユーザ機器120は、保留されているスケジューリング要求を取り消す。これらの場合のうちのいずれか最初に発生する方で取り消される。バッファ状態報告および第1のデータおよび第2のデータを含むデータパケットユニットは、送信の時点の前、すなわちステップ620の前に生成されたので、ユーザ機器120は、保留されているスケジューリング要求のトリガを取り消している。次のスケジューリング要求の機会に追加のスケジューリング要求を送信する動機がないので、これは望ましい。
【0106】
ステップ625。スケジューリング要求の機会は、ケースb)によると、この時点で、すなわちデータの送信後に発生する。ユーザ機器120は、ケースa)では、UL許可の受信とデータの送信との間にスケジューリング要求の機会を有しない。スケジューリング要求のトリガは既に取り消され、したがってもはや保留されていない。これは、ユーザ機器120が次のスケジューリング要求の機会に基地局110にスケジューリング要求を再度送信しないということを意味する。これは望ましい。
【0107】
したがって、ケースa)およびケースb)のいずれでも、いずれの不用なスケジューリング要求も送信されず、スケジューリング要求が意味することについて、基地局110において曖昧さがない。ケースa)およびb)では、スケジューリング要求は、ユーザ機器120において基地局110が予め気づいていなかった新たなデータがあることを意味する。スケジューリング要求の機会615がパケットユニットの生成612前であるエラーケースがまだある。
図1の中のケースa)の分析と同様に、当該ケースでは、送信される追加のスケジューリング要求があり、また、SRが意味することについて基地局110における曖昧さがある。しかし、
図6でのあり得るエラーケースのように第2のデータの到着とパケットユニットの生成との間にSRの機会を有する可能性は、
図1のように第2のデータの到着とデータの送信との間にSRの機会を有する可能性よりも、極めて小さい。
【0108】
図7および
図8は、第1の実施形態に従った本ソリューションの分析を説明する。ここでは、ユーザ機器120は、第1のスケジューリング要求に対応する許可が受信された後にバッファに新たなデータを取得する。この新たなデータは、スケジューリング要求のトリガをトリガする。時系列を見ると、2つの異なる出現するケース、すなわち
図7において説明されるケースa)および
図8において説明されるケースb)がある。ケースa)では、ユーザ機器120は、UL許可の受信とデータの送信との間にスケジューリング要求の機会を有する。ケースb)では、ユーザ機器120は、UL許可の受信とデータの送信との間にスケジューリング要求の機会を有しない。次のスケジューリング要求の機会は、データの送信後に出現する。
【0109】
ケースa)およびケースb)では、2つの個別の代替手段、すなわち代替手段Iおよび代替手段IIがある。
図7は、ケースa)の代替手段Iおよびケースa)の代替手段IIを示し、
図8は、ケースb)の代替手段Iおよびケースb)の代替手段IIを示す。
【0110】
ここから、
図7は、許可の受信とケースa)についての許可に対応するデータの送信との間に新たなデータが到着し、ユーザ機器120がUL許可の受信とデータの送信との間にスケジューリング要求の機会を有するシナリオにおける、本ソリューションに従った分析を説明する。以下が実行されたと仮定する。第1のデータがユーザ機器のバッファに到着した。これは、
図5の中のステップ501に対応する。第1のデータが、バッファ状態報告をトリガした。これは、
図5中のステップ502に対応する。また、この第1のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次のスケジューリング要求の機会にスケジューリング要求を送信するための第1のスケジューリング要求のトリガをトリガした。これは、
図5中のステップ503に対応する。スケジューリング要求の機会が発生し、第1のスケジューリング要求が基地局に送信される。第1のスケジューリング要求のトリガは、まだ保留されている。本ソリューションによれば、スケジューリング要求をトリガしたデータが、基地局110に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合に、スケジューリング要求のトリガが、取り消される。または、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合に、ユーザ機器120は、保留されているスケジューリング要求を取り消す。これらの場合のうちのいずれか最初に発生する方で取り消される。
【0111】
ケースa−I)について、以下のステップを仮定する。
【0112】
ステップ700 ケースa−I)。基地局110に送信されたスケジューリング要求への応答として、ユーザ機器120は、送信についてのUL許可を基地局から受信する。
【0113】
ステップ710 ケースa−I)。ある期間に、ユーザ機器120は、送信される第1のデータの一部または全部について、MAC PDUのようなパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。パケットデータユニットは、後の送信時に基地局110に送信されるものとする。バッファ状態報告は、第1のデータを報告する。本ソリューションの第1の実施形態によれば、保留されている第1のスケジューリング要求は、この時点で取り消される。これは、
図5の中のステップ504に対応する。
【0114】
ステップ720 ケースa−I)。新たな第2のデータがユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告をトリガする。この第2のデータは、さらに、次の機会にスケジューリング要求を送信するための第2のスケジューリング要求のトリガを直接的にまたは間接的にトリガする。第2のスケジューリング要求のトリガは、第2のデータにトリガされて、保留されている。
【0115】
ステップ740 ケースa−I)。この時点で、スケジューリング要求の機会が発生する。すなわち、このスケジューリング要求の機会は、ケースa)によれば、UL許可の受信とデータの送信との間に発生する。したがって、第2のスケジューリング要求が保留されているので、ユーザ機器120は第2のスケジューリング要求を基地局110に再度送信する。第2のデータがユーザ機器のバッファで入手可能になる前に、送信される第2のデータの一部または全部を含むパケットデータユニットをユーザ機器120が既に生成しているので、これは必要である。したがって、第2のデータは、送信時に基地局110に送信されるバッファ状態報告の中で報告されない。
【0116】
ステップ750 ケースa−I)。ユーザ機器120は、バッファ状態報告を含むパケットデータユニットを送信する。当該バッファ状態報告は、(上記)第1のデータによりトリガされた。また、当該バッファ状態報告は、第1のデータを報告するが、第2のデータを報告しない。この時点で、送信された第2のスケジューリング要求をどのように解釈すればよいかを知ることは基地局110にとってもはや困難ではない。第2のスケジューリング要求は、信号の中で受信されるバッファ状態報告について報告されない新たなデータに対応する。さらに、第2のスケジューリング要求が送信されなかった場合に基地局110は第2のデータについて知らないので、ユーザ機器120が第2のスケジューリング要求を送信する必要であった。
【0117】
ケースa−II)について、以下のステップを仮定する。
【0118】
ステップ700 ケースa−II)。基地局に送信される第1のスケジューリング要求への応答として、ユーザ機器120は、送信についてのUL許可を基地局110から受信する。
【0119】
ステップ720 ケースa−II)。新たな第2のデータがユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告をトリガする。この第2のデータは、さらに、バッファ状態報告を介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第2のスケジューリング要求のトリガをトリガする。このケースa−II)では、ケースa−Iとは異なり、第2のデータは、パケットデータユニットの生成後の代わりに、パケットデータユニットの生成前に受信する。
【0120】
ステップ730 ケースa−II)。ある期間に、ユーザ機器120は、送信されるデータについて、MAC PDUのようなパケットデータユニットを生成する。当該データは、ユーザ機器のバッファの中のデータの優先度に応じて、パケットデータユニットの中で生成される。全てのデータが適合できるがバッファ状態報告が適合できない場合を除き、ユーザ機器120は、優先度に従った第1のデータおよび第2のデータ、並びにバッファ状態報告を、パケットデータユニットの中に含める。当該パケットデータユニットは、後の送信時に基地局110に送信されるものとする。バッファ状態報告は、パケットデータユニットの中で生成される第1のデータおよび第2のデータを報告する。本ソリューションの第1の実施形態によれば、保留されている第1のおよび第2のスケジューリング要求は、この時点で取り消される。これは、
図5の中のステップ504に対応する。
【0121】
ステップ740 ケースa−II)。この時点で、スケジューリング要求の機会が発生する。すなわち、このスケジューリング要求の機会は、ケースa)によれば、UL許可の受信とデータの送信との間に発生する。スケジューリング要求のトリガは、もはや保留されていない。したがって、ユーザ機器120は、基地局110にいずれのスケジューリング要求も送信しない。既に割り当てられたリソース上で送信されるバッファ状態報告の中で第1のデータおよび第2のデータは報告されるため、そのようにする必要はないので、これは良好である。
【0122】
ステップ750 ケースa−II)。ユーザ機器120は、生成したパケットデータユニットの中でデータおよびバッファ状態報告を送信する。当該バッファ状態報告は、第1のデータおよび第2のデータを報告する。
【0123】
したがって、ケースa−I)およびケースa−II)のいずれでも、いずれの不用なスケジューリング要求も送信されず、スケジューリング要求が意味することについて、基地局110において曖昧さがない。ケースa−I)およびケースa−II)の両方において、スケジューリング要求は、基地局110が予め気づいていなかった新たなデータがユーザ機器120の中にあることを意味する。
図6について説明されたような同じエラーケースはまだ存在するが、本発明で起こる可能性は極めて小さい。
【0124】
ここから、
図8は、許可の受信とケースb)についての許可に対応するデータの送信との間に新たなデータが到着するシナリオにおける、本ソリューションに従った分析を説明する。ここで、ユーザ機器120はUL許可の受信とデータの送信との間にスケジューリング要求の機会を有さず、次のスケジューリング要求の機会はデータ送信後に発生する。以下が実行されると仮定する。第1のデータがユーザ機器のバッファに到着した。これは、
図5の中のステップ501に対応する。この第1のデータは、バッファ状態報告をトリガした。これは、
図5の中のステップ502に対応する。また、この第1のデータは、バッファ状態報告のトリガを介して直接的にまたは間接的に、次のスケジューリング要求の機会にスケジューリング要求を送信するための第1のスケジューリング要求のトリガをトリガした。これは、
図5の中のステップ503に対応する。スケジューリング要求の機会が発生し、第1のスケジューリング要求が基地局に送信される。第1のスケジューリング要求のトリガは、まだ保留されている。本ソリューションによれば、スケジューリング要求をトリガしたデータが、基地局110に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合に、スケジューリング要求のトリガが、取り消される。または、スケジューリング要求をトリガしたデータが、基地局に送信されるスケジュールされたデータ信号の中に含まれる場合に、ユーザ機器120は、保留されているスケジューリング要求を取り消す。これらの場合のうちのいずれか最初に発生する方で取り消される。
【0125】
ケースb−1)について、以下のステップが仮定される。
【0126】
ステップ800 ケースb−I)。基地局に送信されたスケジューリング要求への応答として、ユーザ機器120は、送信についてのUL許可を基地局から受信する。
【0127】
ステップ810 ケースb−I)。ある期間に、ユーザ機器120は、送信される第1のデータの一部または全部について、MAC PDUのようなパケットデータユニットを生成し、全てのデータが適合できるがバッファ状態報告が適合できない場合を除いて、当該パケットデータユニットの中にバッファ状態報告を含める。パケットデータユニットは、後の送信時に基地局110に送信されるものとする。バッファ状態報告は、第1のデータを報告する。本ソリューションの第1の実施形態によれば、保留されている第1のスケジューリング要求は、この時点で取り消される。これは、
図5の中のステップ504に対応する。
【0128】
ステップ820 ケースb−I)。新たな第2のデータがユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告のトリガをトリガする。この第2のデータは、さらに、次の機会にスケジューリング要求を送信するための第2のスケジューリング要求のトリガを直接的にまたは間接的にトリガする。
【0129】
ステップ840 ケースb−I)。ユーザ機器120は、パケットデータユニットの中で生成された第1のデータを送信し、バッファ状態報告をパケットデータユニットの中に含める。当該バッファ状態報告は、(上記)第1のデータによりトリガされた。また、当該バッファ状態報告は、第1のデータを報告するが、第2のデータを報告しない。
【0130】
ステップ850 ケースb−I)。スケジューリング要求の機会は、ケースb)によれば、この時点で、すなわちデータの送信後に発生する。第2のスケジューリング要求のトリガは、この時点で保留されているので、ユーザ機器120は、この時点で基地局110にスケジューリング要求を送信する。第2のデータについてのスケジューリング要求は基地局110にまだ送信されていないので、これは望ましい。ここで、第2のデータについてのスケジューリングが失われるリスクはない。
【0131】
ケースb−II)について、以下のステップを仮定する。
【0132】
ステップ800 ケースb−II)。基地局に送信されたスケジューリング要求への応答として、ユーザ機器120は、送信についてのUL許可を基地局から受信する。
【0133】
ステップ820 ケースb−II)。新たな第2のデータがユーザ機器のバッファに到着する。この第2のデータは、バッファ状態報告をトリガする。この第2のデータは、さらに、バッファ状態報告を介して直接的にまたは間接的に、次の機会にスケジューリング要求を送信するための第2のスケジューリング要求のトリガをトリガする。このケースb−II)では、ケースb−Iと異なり、第2のデータは、パケットデータユニットの生成後の代わりに、パケットデータユニットの生成前に到着する。
【0134】
ステップ830 ケースb−II)。ある期間に、ユーザ機器120は、送信されるデータについて、MAC PDUのようなパケットデータユニットを生成する。当該データは、ユーザ機器のバッファの中のデータの優先度に応じて、パケットデータユニットの中で生成される。ユーザ機器120は、優先度に従った第1のデータおよび第2のデータ、並びにバッファ状態報告を、パケットデータユニットの中に含める。当該パケットデータユニットは、後の送信時に基地局110に送信されるものとする。バッファ状態報告は、パケットデータユニットの中で生成される第1のデータおよび第2のデータを報告する。本ソリューションの第1の実施形態によれば、保留されている第1のおよび第2のスケジューリング要求は、この時点で取り消される。これは、
図5の中のステップ504に対応する。
【0135】
ステップ840 ケースb−II)。ユーザ機器120は、データおよびバッファ状態報告をパケットデータユニットの中で送信する。当該バッファ状態報告は、第1のデータおよび第2のデータを報告する。
【0136】
ステップ850 ケースb−II)。スケジューリング要求の機会は、ケースb)によれば、この時点で、すなわちデータの送信後に発生する。スケジューリング要求のトリガは、ステップ830で取り消されたので、保留されていない。第1のデータおよび第2のデータは既に送信され、またはBSRの中で報告されるので、この場合にこれは良好である。
【0137】
上記
図5の中で参照された、スケジューリング要求のトリガをハンドリングするための方法のステップを実行するために、ユーザ機器120は、
図9に示される構成を備える。
【0138】
上記のように、ユーザ機器120は、基地局110に送信されるデータを受け取るように構成されるバッファ900を備える。
【0139】
ユーザ機器120は、スケジューリング要求のトリガを生成するように構成される生成部920を備える。当該スケジューリング要求のトリガは、取り消されるまで保留されている。上記生成は、到着したデータにより直接的にまたは間接的にトリガされる。
【0140】
ユーザ機器は、取消し部930をさらに備える。
【0141】
第1の実施形態によれば、取消し部930は、スケジューリング要求のトリガの生成をトリガしたデータが、基地局110に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、または、スケジューリング要求の生成をトリガしたデータが、基地局110に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されているスケジューリング要求のトリガを取り消すように、構成される。
【0142】
第2の実施形態によれば、取消し部930は、保留されているスケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告され、またはスケジュールされたデータ信号の中に直接的に含まれたか、および、どのデータが、これらの2つの手段のいずれの中でも報告されていないかを、記録するように構成される。
【0143】
組み合わせられた第1の実施形態および第2の実施形態によれば、取消し部930は、スケジューリング要求のトリガの生成をトリガしたデータが、基地局110に送信されるスケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告される場合、若しくは、スケジューリング要求の生成をトリガしたデータが、基地局110に送信されるスケジュールされたデータ信号の中に含まれる場合のうち、いずれか最初に発生する方で、保留されているスケジューリング要求のトリガを取り消すように構成され、または、代わりに、保留されているスケジューリング要求のトリガをいずれかの時点で取り消すが、どのデータが、スケジュールされたデータ信号の中に含まれるバッファ状態報告の中で報告されたか、および、どのデータが、報告されていないかを、記録するように構成される。
【0144】
第2の実施形態、並びに、組み合わせられた第1の実施形態および第2の実施形態によれば、ユーザ機器120は、次のスケジューリング要求の機会が現れると、上記2つの手段のいずれでもまだ報告されていないデータをバッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信するように構成される送信部940を備える。
【0145】
第1の実施形態および第2の実施形態によれば、送信部940は、次のスケジューリング要求の機会が現れると、バッファ状態報告の中でまだ報告されていないデータをバッファが含む場合におよび当該場合にのみ、スケジューリング要求を送信するように構成される。
【0146】
スケジューリング要求のトリガをハンドリングするための本メカニズムは、
図9に示されるユーザ機器120の中のプロセッサ950のような1つ以上のプロセッサ、および本ソリューションの機能を実行するためのコンピュータプログラムコードを通して、実装され得る。上記プログラムコードは、また、例えば、ユーザ機器120内に読み込まれる場合に本ソリューションを実行するためのコンピュータプログラムコードを搬送するデータキャリアの形で、コンピュータプログラム製品(computer program product)として提供されてもよい。1つの当該キャリアは、CD ROMディスクの形であってもよい。しかしながら、データキャリアは、メモリスティック等の他のデータキャリアで実現可能である。コンピュータプログラムコードは、さらに、サーバ上で純粋なプログラムコードとして提供され、ユーザ機器120にダウンロードされてもよい。
【0147】
図10は、ユーザ機器120のある実施形態を示す。当該ユーザ機器120は、送受信機回路(無線周波数受信機フロントエンド、送信変調器/増幅器、等)と動作可能なように関連付けられた処理回路と、1つ以上の送信/受信アンテナとを含む。
【0148】
ユーザ機器120は、例えば、モバイル端末、またはLTE標準に基づく無線通信システム内での動作のために構成された他の種類のユーザ機器である。いずれの場合も、ユーザ機器120は、ここで説明された実施形態のいずれかを実装するように構成される。例えば、処理回路は、1つ以上のベースバンドプロセッサを含んでもよい。少なくとも1つの実施形態では、処理回路は、デジタルシグナルプロセッサ(DPS)または他のデジタルプロセッサ等の、1つ以上のマイクロプロセッサに基づく回路を含む。さらに、ユーザ機器120は、プログラム命令、構成およびプロビジョニングのデータ、作業用データ等を記憶するための、例えば不揮発性または揮発性の1つ以上のメモリ回路を含む、ということを当業者は理解するであろう。
【0149】
とりわけ、ユーザ機器120内の処理回路は、アップリンク送信についてのデータをバッファリングするための、バッファ900のようなアップリング送信バッファを含む。当該アップリンク送信バッファは、作業用メモリの予約された部分であってもよい。また、処理回路は、ここで説明され、また
図9に関連する文章の中で言及したように、制御および処理の全てまたは一部を実装するための関連付けられたコントローラを含む。すなわち、取消し部930のようなコントローラの1つ以上の実施形態は、スケジューリング要求をトリガしたデータがバッファ状態報告MAC制御要素の中に含まれる場合、またはスケジューリング要求をトリガしたデータが送信される場合のうち、上記のようにいずれか最初に発生する方で、保留されているスケジューリング要求を取り消すように構成される。LTEに照らすと、ユーザ機器120は、スケジューリング要求をトリガしたバッファ状態報告が取り消される場合に、保留されているスケジューリング要求を取り消すように構成されるものとして、理解されることが可能である。
【0150】
代わりに、ユーザ機器のコントローラは、どのデータが含まれ、そうでなければどのデータがバッファ状態報告の中で報告され、およびどのデータがそうではないかを記録する、ハードウェア、ソフトウェア、またはそれらの組合せによって構成されることが可能である。したがって、スケジューリング要求の機会が出現すると、ユーザ機器120は、バッファ状態報告の中でまだ報告されていないデータを有する場合に、スケジューリング要求を送信する。(バッファ状態報告は送信されなくてもよい。例えば、バッファ状態報告が、送信のために組立てられたMAC PDUの中に含まれれば、十分である。)
【0151】
実施形態1および2の両方は、同一の振るまいをもたらす。当該振るまいの利点は、その目的を果たす場合に保留されているSRを取り消すことが自然であるということである。これは、SRをトリガしたデータがバッファ状態報告の中で報告される場合またはSRをトリガしたデータが送信される場合に取り消されるときにのみ、保証される。いずれかの他のソリューションは、曖昧なまたは不用な送信されるSRおよび/または不用な許可をもたらす。
【0152】
いくつかの実施形態によると、本ソリューションは、以下のように見なされてもよい。スケジューリング要求がトリガされると、スケジューリング要求は、取り消されるまで、保留されているとみなされるものとする。MAC PDUが組立てられて、バッファ状態報告をトリガした最後のイベントまでの(および含む)バッファの状態を含むバッファ状態報告をこのPDUが含む場合、または、送信可能な全ての保留されているデータをアップリンク許可が収容できる場合に、全ての保留されているスケジューリング要求は取り消されるものとする。
【0153】
単語「を含む(comprise)」または「を含む(comprising)」を使用する場合には、当該単号は、限定しないように、すなわち「の少なくとも1つからなる(consist at least of)」を意味するように解釈されるべきである。単語「生成された(built)」は、この文章では単語「組立てられた(assembled)」と等しい。
【0154】
本発明は、上記好適な実施形態に限定されない。様々な代替手段、改良されたもの、および等価なものが、使用されてもよい。したがって、上記実施形態は、本発明の範囲を限定するように受け取られるべきではない。本発明の範囲は、添付の特許請求の範囲により定義される。