(57)【要約】  本発明は、複数のセカンダリ局と通信するプライマリ局を含むネットワークを動作させるための方法に関し、当該方法は、プライマリ局が間欠モードにおいてセカンダリ局と通信して、セカンダリ局がセカンダリ局の現在のステータスに基づく制御メッセージをプライマリ局に送信し、プライマリ局が、制御メッセージに応じて、間欠モードのパラメータを変更する。
2012532480.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのセカンダリ局と通信するプライマリ局を含む通信システムを動作させる方法であって、セカンダリ局バッファにおいて少なくとも１つのデータ・ユニットを待ち行列に入れ、予め定められた成功確率で前記少なくとも１つのデータ・ユニットを送るために必要な時間を推定し、推定された時間が所与の閾値を超える場合、リソース信号を生成する方法。
【請求項２】
前記時間を推定するステップが前記セカンダリ局において実行され、前記リソース信号が、送信リソースに対する要求又は前記バッファの内容を示すバッファ・ステータス・リポートである、請求項１に記載の方法。
【請求項３】
前記時間を推定するステップが前記プライマリ局において実行され、前記信号がリソース付与である、請求項１に記載の方法。
【請求項４】
前記少なくとも１つのデータ・ユニットを送るために必要な時間が、前記セカンダリ局におけるARQ処理特性に基づいて推定される、請求項１から請求項３のいずれか一項に記載の方法。
【請求項５】
前記ARQ処理特性が、最近の送信に対するARQ再送信の数、最近の送信に対するARQ再送信の平均数、ARQ再送信の数の確率密度関数の特性のうちの少なくとも１つを含む、請求項４に記載の方法。
【請求項６】
前記少なくとも１つのデータ・ユニットを送るために必要な時間が、送信レートの確率密度関数に基づいて推定される、請求項１から請求項３のいずれか一項に記載の方法。
【請求項７】
前記少なくとも１つのデータ・ユニットを送るために必要な時間が、前記セカンダリ局バッファにおいて既に費やされた時間を考慮して推定される、請求項１から請求項３のいずれか一項に記載の方法。
【請求項８】
前記少なくとも１つのデータ・ユニットを送るために必要な時間が、前記データ・ユニットの送信が開始する前に予想される時間インターバルの推定を考慮して推定される、請求項１から請求項３のいずれか一項に記載の方法。
【請求項９】
前記データ・ユニットの送信が開始する前に予想されるインターバルの推定が、前記セカンダリ局において待ち行列に入れられたより高い優先度を持つ更なるデータ・ユニットの量に基づいて行われる、請求項８に記載の方法。
【請求項１０】
前記少なくとも１つのデータ・ユニットを送るために必要な時間が、前記リソース信号に対する予想される応答時間を考慮して推定される、請求項１から請求項３のいずれか一項に記載の方法。
【請求項１１】
前記リソース信号に対する応答が、送信リソースの割り当て、又は、割り当てられた送信リソースの変更である、請求項１０に記載の方法。
【請求項１２】
前記所与の閾値が、待ち行列中のパケットの数、予想される再送信の推定される数、中継が用いられる場合のホップの数、許可される送信データ・レート、ARQラウンドトリップ時間のうちの少なくとも１つの関数に基づく、請求項１から請求項１１のいずれか一項に記載の方法。
【請求項１３】
前記プライマリ局が前記所与の閾値を通知する、請求項１から請求項１２のいずれか一項に記載の方法。
【請求項１４】
プライマリ局を含むネットワークにおいて通信するための手段を有するセカンダリ局であって、少なくとも１つのデータ・ユニットを待ち行列に入れるための少なくとも１つのバッファ、予め定められた成功確率で前記少なくとも１つのデータ・ユニットを送るために必要な時間を推定するための制御手段、及び、推定された時間が所与の閾値を超える場合に、リソース信号を生成するための送信手段を有するセカンダリ局。
【請求項１５】
前記閾値が前記プライマリ局から受信される、請求項１４に記載のセカンダリ局。
【請求項１６】
少なくとも１つのセカンダリ局と通信するための手段を有するプライマリ局であって、予め定められた成功確率で前記セカンダリ局が当該セカンダリ局のバッファ中に記憶された少なくとも１つのデータ・ユニットを送るために必要な時間を推定するための制御手段を有し、前記制御手段は、推定された時間が所与の閾値を超過する場合に、リソース信号を生成するように用意される、プライマリ局。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおいて通信するための方法に関する。より具体的には、本発明は、セルラ通信ネットワーク(例えばUMTS、UMTS LTE、GSM)のような通信ネットワークにおけるプライマリ局とセカンダリ局との間の通信に関する。
【背景技術】
【０００２】
集中型制御による無線パケットデータ・ネットワークにおいて、それぞれの移動端末(ユーザ端末、又はUMTS LTEではUE)間でアップリンク送信リソースの割り当ての優先順位を基地局(又はUMTS LTE用語ではeNB)が効果的に決定することを可能にするためのメカニズムが必要とされる。図1に開示されるように、例えばUMTSにおける基地局又はLTEにおけるノードB(eNB)であるプライマリ局100は、複数のチャネル120によって、例えばUMTSにおける移動局又はLTEにおける使用者機器(UE)である複数のセカンダリ局101と通信する。各々のチャネル120は、制御データ又はユーザ・データのような異なる種類のデータを伝達するために専用でありえる。各々のセカンダリ局は一般に、プライマリ局によってリソースが与えられたときに送信することができるまでバッファ中の待ち行列に入れられたデータを持つ。図2に示されるように各々が異なるサービス品質(QoS)要求を有する複数の異なるストリームのためのバッファが存在する場合がある。図2から分かるように、３つのバッファ又はキュー21、22及び23が示される。各々のキューに対して、対応するサービス品質要求が設定され、あるレベルのサービス品質を必要とし、例えば、送信の遅延を制限し、又は、最小限の所与のインターバルでの定期的な送信を要求する。eNBは、どのUEがどのレートでの送信を許可されるべきかを決定することを可能にするための情報を必要とする。このプロセスを補助するために、そのバッファ中のデータの指標(すなわちバッファ・ステータス・レポート：BSR)と同様に、許可に対する要求(いわゆるスケジューリング要求すなわちSR)、をUEが送信することが知られている。
【０００３】
最高水準の技術において、アップリンク上でのこれらのイベントを引き起こす閾値は、通常予め定められているか、又は、瞬間的なチャネル及び/又はバッファ占有状況に基づく。既存の改良は、最近許可されたデータ速度又は最近許可されたデータ速度の平均を考慮する方法を含む。UEは、実際には、その過去の送信履歴の更なる詳細を記憶して分析することができ、それによって、QoSターゲットが達成されそうかどうかのさらに正確な予測を抽出する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記の問題を軽減する方法を提案することが本発明の目的である。
【０００５】
セカンダリ局の信号に更なる柔軟性を提供する方法を提案することが本発明の他の目的である。
【課題を解決するための手段】
【０００６】
本発明の第１の態様によれば、少なくとも１つのセカンダリ局と通信するプライマリ局を含む通信システムを動作させる方法が提案され、当該方法は、セカンダリ局バッファにおいて少なくとも１つのデータ・ユニットを待ち行列に入れ、予め定められた成功確率で少なくとも１つのデータ・ユニットを送るために必要な時間を推定し、推定された時間が所与の閾値を超過する場合、リソース信号を発生させる。
【０００７】
本発明の第２の態様によれば、プライマリ局を含むネットワークにおいて通信するための手段を有するセカンダリ局が提案され、当該セカンダリ局は、少なくとも１つのデータ・ユニットを待ち行列に入れるための少なくとも１つのバッファ、予め定められた成功確率で少なくとも１つのデータ・ユニットを送るために必要な時間を推定するための制御手段、及び、推定された時間が所与の閾値を超過する場合、リソース信号を発生させるための送信手段を有する。
【０００８】
本発明の第３の態様によれば、少なくとも１つのセカンダリ局と通信するための手段を有するプライマリ局が提案され、当該プライマリ局は、セカンダリ局が予め定められた成功確率でセカンダリ局のバッファ中に記憶された少なくとも１つのデータ・ユニットを送るために必要な時間を推定するための制御手段を有し、制御手段は、推定された時間が所与の閾値を超過する場合、リソース信号を発生させるように用意される。
【０００９】
本発明のこれらの及び他の態様は、以下に述べられる実施の形態から明らかであり、それらを参照して説明される。
【００１０】
本発明は、添付の図面を参照して、さらに詳細に一例として説明される。
【図面の簡単な説明】
【００１１】
【図１】本発明が実施されることができるネットワーク。
【図２】送信前にセカンダリ局中にデータパケットを記憶するためのキュー。
【発明を実施するための形態】
【００１２】
本発明は、無線通信システムのアップリンク上での信号伝達イベントをトリガするための１セットのルールを定める。問題となるイベントは、そのようなネットワーク中の中心的なエンティティが正確なスケジューリング決定を行うために移動端末から必要とする情報に関連し、
・スケジューリング要求自体
・バッファ・ステータス・レポート
・特定のレートにおける、又は特定の論理チャネル、優先度、アプリケーションの送信要求、
を含む。
【００１３】
本発明において定められるルールは、そのようなイベントをトリガするために使用される閾値が、要因の組み合わせに基づいて決定されることを可能にする。これらの要因は、過去の送信履歴の統計を考慮する。そして閾値は、移動端末において計算されるか、又は、中央のスケジューリング・エンティティにおいて計算されてその後で移動端末に通知される。
【００１４】
上の問題に対して提案されるソリューションは、考えられるトリガの範囲を改良することである。上記のトリガリング閾値のより詳細な統計分析及び/又は更なる閾値の導入は、リソースのさらに効率的な利用をもたらす。SR又はBSRの通知は、潜在的に、複数の新たなイベントによってトリガされることができる（例えば、予め定められた成功確率でパケットを送るために必要な時間及び/又はトリガされたイベントに対して期待される応答時間）。
【００１５】
特に、本発明は、送信が成功する前に経過すると予測される平均又は瞬間的な時間の代わりに、パケットが特定の時間(例えば、データパケットが生じたアプリケーションのQoS要求によって設定された待ち時間閾値)内に送信されることができる確率を考慮する。
【００１６】
本発明の実施態様は、以前の(H)ARQ送信及び再送信の統計の考察から、特定の時間内での送信成功確率を導き出すことができる。
【００１７】
計算は、過去のスケジューリング時点のスライディング・ウィンドウにわたって実行されることができ、計算の更新レートは、スケジューリング・インターバルと同じか、又はスケジューリング・インターバルより小さい。
【００１８】
本発明は、SR又はBSRイベントをトリガするべきかどうかを決定するときに、全伝送遅延に対する重要な要因(すなわち(H)ARQ再送信遅延)が考慮されることを可能にする。これは、バッファにおいて既に費やされた遅延及び最初の送信を待つ予測された遅延のみを考慮するがHARQ再送信に対して予測される遅延又はターゲット時間内の送信成功確率は考慮しない従来技術(例えばPHGB050012)をこえる改善を表す。
【００１９】
本発明の第１の実施の形態によれば、通信システムを動作させる方法が提案され、当該方法は、UEバッファにおいてデータ・ユニットを待ち行列に入れ、UE自体又はeNBにおいて、予め定められた成功確率(例えば98%)でパケットを送るために必要な時間を推定し、推定された時間が所与の閾値を超過する場合、eNBへの適切な通知(SR及び/又はBSR)を発生させる。
【００２０】
したがって、送信失敗率が高い場合、データパケットの１つあるいは複数の再送信をおそらく必要として、パケットを送るために必要な時間は長くなる。
【００２１】
長所として、パケットを送るために必要な時間は、UEにおける(H)ARQプロセスの特定の特性に基づいて推定される。考えられる候補は、
a. 最近の送信のためのHARQ再送信の数、
b. 最近の送信のためのHARQ再送信の平均数(又は、例えば忘却因子を用いて計算される重み付き平均)、
を含む。忘却因子の場合、古い送信の平均の計算における寄与が、より最近の送信の寄与未満であることを意味する。これは例えば、古い送信の送信時間に重み付けする１未満の係数によって、実行されることができる。これらの係数はさらに時間に依存することができ、時間とともにさらに減少することができる。
c. HARQ再送信の数の確率密度関数(pdf)の特定のパラメータ。
【００２２】
この実施の形態によれば、時間を推定するステップは、プライマリ局又はNode Bにおいて実行され、通知は、リソースがセカンダリ局に割り当てられたことをセカンダリ局に示すリソース付与である。変形例において、リソース付与は、１セットのリソースからどのリソースが割り当てられたかを特定することができる。
【００２３】
この実施の形態の変形例において、予め定められた確率でデータパケットを送信するために必要な時間の推定は、ARQ再送信の数の確率密度関数の特性に基づく。
【００２４】
ここで、少なくとも１つのデータ・ユニットを送るために必要な時間は、送信レートの確率密度関数に基づいて推定される。
【００２５】
少なくとも１つのデータ・ユニットを送るために必要な時間は、セカンダリ局バッファにおいて既に費やされた時間の考察によって、すなわちデータ・ユニットの送信が始まる前の予想される時間インターバルの推定によって、及び/又は、リソース信号に対する予想される応答時間の考察によって、推定されることができることに留意する必要がある。
【００２６】
各々のデータ・ユニットが異なる優先度又はQoS要求を持つ場合があるならば、データ・ユニットの送信が始まる前に予想されるインターバルの推定は、セカンダリ局において待ち行列に入れられたより高い優先度を持つ更なるデータ・ユニットの量に基づいて行われる。
【００２７】
バッファ・レポート又はリソース要求に応じて、プライマリ局は、送信リソースを割り当てるためのリソース付与を送信することができるか、又は、例えば半永続的なスケジューリングが用いられる場合には、半永続的にスケジューリングされるリソースがどれだけ頻繁かを変更するために、割り当てられた送信リソースの変更を通知することができる。
【００２８】
上で議論された変形例の全てにおいて、プライマリ局は、閾値を通知することができる。そのうえ、閾値は、あまりに頻繁なリソース要求を回避するために、セカンダリ局のそれぞれの優先度又は各々のセカンダリ局が現在経験している送信状況に依存して、セカンダリ局ごとに異なってもよい。
【００２９】
本発明の変形例において、パケットを送るために必要な時間は、付与されたレートのpdfに基づいて推定される。
【００３０】
本発明の他の変形例において、パケットを送るために必要な時間は、合計遅延を決定するために、バッファにおいて既に費やされた全時間の考察によって推定されることが提案される。
【００３１】
本発明の更に別の態様において、パケットを送るために必要な時間は、合計遅延を決定するために、データの送信が開始する前の予測される時間の長さの考察によって推定される。この推定は、例えば既にバッファリングされたより高い優先度の他のデータの量に基づいて行われることができる。
【００３２】
時には、パケットを送るために必要な時間は、トリガされているイベントに対する予想される応答時間の考察によって推定されることに留意する必要がある。
【００３３】
そのような場合、トリガされたイベントに対する応答は、送信リソースの割り当て又は割り当てられた送信リソースの変更である。
【００３４】
他の実施の形態
【００３５】
一例として、本発明によるトリガ基準は、以下として計算されることができる:
(例えば特定の論理的なチャネルのためのキュー中のパケットの数) x (再送信の予測される数) x (中継が用いられる場合のホップの数) / [(許可された送信レート) x((H)ARQ RTT)]
【００３６】
基準が集中型スケジューラ(例えばeNB)で計算される場合、その基準は、例えば、論理チャネルごとに、優先度クラスごとに、アプリケーションごとに、又はUEごとに通知されることができるか、あるいは、セル中で放送されることができる。
【００３７】
本発明は、セルラ・パケット通信システム、UMTS LTE及びUMTS LTE-Advancedのような移動遠距離通信システム又は間欠受信若しくは送信を実施する他のネットワークに適用可能である。
【００３８】
本明細書及び請求の範囲において、単数で表現された要素は、そのような要素が複数存在することを除外しない。さらに、「有する」「含む」などの用語は、挙げられたもの以外の要素が存在することを除外しない。
【００３９】
請求の範囲の括弧中に参照符号が含まれていることは、理解を助けることを目的とするものであって、制限することは意図されない。
【００４０】
本開示を読むことから、他の変形例が当業者にとって明らかとなる。そのような変形例は、無線通信の技術において既に知られている他の特徴を含むことができる。
【図１】
2012532480.tif 000003
【図２】
2012532480.tif 000004
【国際調査報告】
2012532480.tif 000005
2012532480.tif 000006