(57)【特許請求の範囲】
【請求項１】
ネットワークにおいて通信する方法において、
ａ）二次局が、割り当てられたリソースにおけるデータを含むデータフィールドを有するメッセージの一次局に対する送信を準備するステップであって、前記リソースが、複数のリソースブロックを有する、前記準備するステップと、
ｂ）前記割り当てられたリソースのサイズが前記メッセージのサイズに対して必要とされるより大きい場合に、前記二次局が、前記割り当てられたリソースを第１の部分及び第２の部分に分割するステップであって、各部分が少なくとも１つのリソースブロックを有する、前記分割するステップと、
ｃ）前記二次局が、前記リソースの前記第１の部分において前記一次局に前記メッセージを送信するステップと、
ｄ）前記二次局が、前記リソースの前記第２の部分において送信を防止するステップと、
を有する方法。
【請求項２】
前記メッセージが、データフィールドと一緒に送信されるべきレポートを有する、請求項１に記載の方法。
【請求項３】
前記レポートが、前記二次局のバッファ内のデータの量を示す、請求項２に記載の方法。
【請求項４】
前記ステップｂ）が、データが前記データフィールドにおいて送信されるべきでない場合に実行される、請求項２又は請求項３に記載の方法。
【請求項５】
前記第１の部分のサイズが、前記割り当てられたリソースのサイズから得られる、請求項１ないし４のいずれか一項に記載の方法。
【請求項６】
前記第１の部分のサイズが、所定のセットから選択される、請求項５に記載の方法。
【請求項７】
前記第１の部分の前記少なくとも１つのリソースが、前記割り当てられたリソースの最小周波数リソースブロックである、請求項１ないし６のいずれか一項に記載の方法。
【請求項８】
ｅ）前記一次局が、前記メッセージを受信するステップと、
ｆ）前記割り当てられたリソースに対応するメッセージサイズで前記メッセージを復号するステップと、
ｇ）復号が失敗する場合に、メッセージサイズのセットから１つのメッセージサイズを選択し、前記選択されたメッセージサイズで前記メッセージを復号するステップと、
を有する、請求項１ないし７のいずれか一項に記載の方法。
【請求項９】
二次局において、前記二次局が、割り当てられたリソースにおけるデータを含むデータフィールドを含むメッセージの一次局に対する送信を準備するコントローラを有し、前記リソースが、複数のリソースブロックを有し、前記コントローラは、前記割り当てられたリソースのサイズが、前記メッセージのサイズに対して必要とされるより大きい場合に、前記割り当てられたリソースを第１の部分及び第２の部分に分割し、各部分が、少なくとも１つのリソースブロックを有し、前記二次局が、前記リソースの前記第１の部分において前記一次局に前記メッセージを送信する手段を有し、前記コントローラが、前記リソースの前記第２の部分における送信を防止する、二次局。
【請求項１０】
一次局及び少なくとも１つの二次局を有するシステムにおいて、前記二次局が、割り当てられたリソースにおけるデータを含むデータフィールドを含むメッセージの前記一次局に対する送信を準備するコントローラを有し、前記リソースが、複数のリソースブロックを有し、前記コントローラは、前記割り当てられたリソースのサイズが、前記メッセージのサイズに対して必要とされるより大きい場合に、前記割り当てられたリソースを第１の部分及び第２の部分に分割し、各部分が、少なくとも１つのリソースブロックを有し、前記二次局が、前記リソースの前記第１の部分において前記一次局に前記メッセージを送信する手段を有し、前記コントローラが、前記リソースの前記第２の部分における送信を防止する、システム。
【請求項１１】
請求項９に記載の二次局と通信する手段を有する一次局において、前記手段が、前記二次局からメッセージを受信する受信器と、前記割り当てられたリソースに対応するメッセージサイズで前記メッセージを復号するデコーダと、復号が失敗する場合にメッセージサイズのセットから１つのメッセージサイズを選択するコントローラとを有し、前記デコーダが、この選択されたメッセージサイズで前記メッセージを復号する、一次局。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一次局及び少なくとも１つの二次局を有するネットワークにおいて通信する方法、並びにこのような二次局に関する。より具体的には、本発明は、ＧＳＭ（グローバル・システム・フォー・モバイル・コミュニケーションズ）又はＵＭＴＳ（ユニバーサル・モバイル・テレコミュニケーションズ・システム）ネットワークのような移動体通信ネットワークにおいて通信する方法に関する。
【０００２】
本発明は、例えば、ＵＭＴＳ及びＵＭＴＳロング・ターム・エボリューション、並びに複数の端末から基地局にコールをルートするハブにも関連する。
【背景技術】
【０００３】
ＵＭＴＳシステムのような移動体通信ネットワークにおいて、一次局、例えばノードＢ（又は基地局若しくはｅＮＢ）は、複数のチャネルを用いて、少なくとも１つの二次局、例えばユーザ機器（又は移動局）と通信する。前記一次局にデータを送信するために、二次局は、前記一次局にリソースを要求する必要があり、前記リソースが割り当てられる。この割り当て要求は、考慮されるチャネルに依存して複数の方法で行われることができる。
【０００４】
一例において、リソースを要求するために、送信されるべきデータ、すなわち前記二次局のバッファ内のデータの量を示すことが必要とされる。このために、前記二次局は、前記二次局バッファ内のデータの量を示すバッファステータスレポートを前記一次局に送信する。したがって、前記一次局は、前記ネットワークの性能及び前記送信されるべきデータの量の両方に対応するリソースを割り当てる。これは、リソースの割り当てが調整されることを可能にする。
【０００５】
しかしながら、アップリンクリソース許可に関するメッセージが誤って受信される、すなわちデータが送信されるべきでないので、前記二次局がこのリソースを使用しない場合、又はアップリンクリソース許可が送信されなかった場合、これは、幾つかの問題を生じる可能性がある。誤ったアップリンク許可に対して、前記二次局は、許可されたリソース全体を使用してデータパケットを送信する。前記二次局がデータを持たない場合でさえも、前記二次局は、例えばパディングビットで前記リソースを満たすことにより、前記許可において示された前記リソースの全体を使用してバッファステータスレポートを送信する。
【０００６】
更に、幾つかのシステムは、半永続的（semi persistent）スケジューリングを使用し、これにより、幾つかのパラメータは、より高い層により構成されることができ、リソースは、特定のアプリケーションの要求に適合するために定期的に許可される（例えばアップリンク送信リソースの場合、ＶｏＩＰをサポートするように２０ｍｓ毎）。誤った半永続的スケジューリング（ＳＰＳ）アクティベーションの場合、前記二次局は、許可されたリソース全体を使用してデータパケットを定期的に送信する。前記二次局が送信すべきデータを持たない場合、前記二次局は、ＢＳＲを送信するが、依然として送信すべきデータが存在しない場合には設定可能な回数の送信の後に前記リソースを解放する。両方の場合において、前記二次局が送信すべきデータを持たない場合でさえ、著しいアップリンク干渉が生成される。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、この問題が軽減されることを可能にする方法を提案することである。
【０００８】
本発明の他の目的は、リソースの管理を改良する方法を提案することである。
【０００９】
本発明の他の目的は、アップリンクチャネルにおける干渉を低減することを可能にする方法を提案することである。
【課題を解決するための手段】
【００１０】
このために、ネットワークにおいて通信する方法が提案され、前記方法は、
ａ）二次局が、割り当てられたリソースにおけるデータを含むデータフィールドを少なくとも有するメッセージの一次局に対する送信を準備するステップであって、前記リソースが複数のリソースブロックを有する、当該準備するステップと、
ｂ）前記割り当てられたリソースのサイズが前記メッセージのサイズに対して必要とされるより大きい場合に、前記二次局が、前記割り当てられたリソースを第１の部分及び第２の部分に分割するステップであって、各部分が少なくとも１つのリソースブロックを有する、当該分割するステップと、
ｃ）前記二次局が、前記リソースの前記第１の部分において前記メッセージを前記一次局に送信するステップと、
ｄ）前記二次局が、前記リソースの前記第２の部分において送信を防止するステップと、
を有する。
【００１１】
本発明の第２の態様によると、二次局が提案され、前記二次局は、割り当てられたリソースにおけるデータを含むデータフィールドを少なくとも有するメッセージの一次局に対する送信を準備するコントローラを有し、前記リソースが、複数のリソースブロックを有し、前記コントローラは、前記割り当てられたリソースのサイズが、前記メッセージのサイズに対して必要とされるより大きい場合に、前記割り当てられたリソースを第１の部分及び第２の部分に分割するように構成され、各部分が、少なくとも１つのリソースブロックを有し、前記二次局が、前記リソースの前記第１の部分において前記一次局に前記メッセージを送信する手段を有し、前記コントローラが、前記リソースの前記第２の部分において送信することを防止するように構成される。
【００１２】
本発明の第３の態様によると、通信のシステムが提案され、前記システムは、一次局及び少なくとも１つの二次局を有し、前記二次局が、前記割り当てられたリソースにおけるデータを含むデータフィールドを少なくとも有するメッセージの前記一次局に対する送信を準備するコントローラを有し、前記リソースが、複数のリソースブロックを有し、前記コントローラは、前記割り当てられたリソースのサイズが、前記メッセージのサイズに対して必要とされるより大きい場合に、前記割り当てられたリソースを第１の部分及び第２の部分に分割するように構成され、各部分が、少なくとも１つのリソースを有し、前記二次局が、前記リソースの前記第１の部分において前記一次局に前記メッセージを送信する手段を有し、前記コントローラが、前記リソースの前記第２の部分において送信することを防止するように構成される。
【００１３】
本発明の第４の態様によると、一次局が提案され、前記一次局は、二次局と通信する手段を有し、前記手段は、前記二次局からメッセージを受信する受信器と、前記割り当てられたリソースに対応するメッセージサイズで前記メッセージを復号するデコーダと、復号が失敗する場合にメッセージサイズのセットから１つのメッセージサイズを選択するコントローラとを有し、前記デコーダは、この選択されたメッセージサイズで前記メッセージを復号するように構成される。
【００１４】
結果として、前記二次局が、前記割り当てられたリソースの一部の間に送信しないので、特にリソースが誤って許可される又は誤って受信される場合の、干渉が低減される。これは、前記割り当てられたリソースが複数のサブフレーム又はフレームに対して割り当てられることができる半永続的スケジュール（ＳＰＳ）アクティベーションに対して更に効率的である。
【００１５】
本発明のこれら及び他の態様は、以下に記載される実施例を参照して説明され、明らかになる。
【００１６】
本発明は、ここで、添付の図面を参照して、例として、より詳細に記載される。
【図面の簡単な説明】
【００１７】
【図１】本発明において実施されるシステムのブロック図である。
【図２】従来技術によるメッセージの交換を示すタイムチャートである。
【発明を実施するための形態】
【００１８】
本発明は、基地局のような一次局１００と、移動局のような少なくとも１つの二次局２００とを有する、図１に描かれるような通信のシステム３００に関する。
【００１９】
無線システム３００は、複数の一次局１００及び／又は複数の二次局２００を有することができる。一次局１００は、送信器手段１１０及び受信手段１２０を有する。送信器手段１１０の出力部及び受信手段１２０の入力部は、例えばサーキュレータ又は切り替えスイッチであることができる結合手段１４０によりアンテナ１３０に結合される。送信器手段１１０及び受信手段１２０に結合されるのは、例えばプロセッサであることができる制御手段１５０である。二次局２００は、送信器手段２１０及び受信手段２２０を有する。送信器手段２１０の出力部及び受信手段２２０の入力部は、例えばサーキュレータ又は切り替えスイッチであることができる結合手段２４０によりアンテナ２３０に結合される。送信器手段２１０及び受信手段２２０に結合されるのは、例えばプロセッサであることができる制御手段２５０である。一次無線局１００から二次局２００への送信は、ダウンリンクチャネル１６０において行われ、二次無線局２００から一次無線局１００への送信は、アップリンクチャネル２６０において行われる。
【００２０】
前述のように、ＬＴＥにおいて、アップリンク許可に関するメッセージが誤って受信される、又は何も送信されていないときに前記ＵＥが復号する場合、以下の問題が生じる可能性がある。
【００２１】
・誤ったアップリンク許可に対して、前記二次局は、許可されたリソース全体を使用してデータパケットを送信する。前記ＵＥがデータを持たない場合でさえ、前記ＵＥは、前記許可において示された前記リソースの全体を使用してＢＳＲを送信する。
【００２２】
・誤ったＳＰＳアクティベーションに対して、前記ＵＥは、前記許可されたリソース全体を使用して定期的にデータパケットを送信する。前記ＵＥがデータを持たない場合、前記ＵＥは、ＢＳＲを送信するが、依然として送信すべきデータが存在しない場合には設定可能な回数の送信の後に前記リソースを解放する。
【００２３】
主な結果は、両方の場合において、前記ＵＥが送信すべきデータを持たない場合でさえ、著しいアップリンク干渉が生成されることである。
【００２４】
１つの可能な解決法は、前記ＵＥが許可を受信するが、データを持たない場合に、前記ＵＥが何も送信しないことである。しかしながら、これは、同時に送信されるべきデータが存在する場合に送信されるＢＳＲ（バッファステータスレポート）のような他の小さなメッセージをｅＮｏｄｅＢが受信することを可能にしない。
【００２５】
本発明の実施例は、前記ＵＥが、データを持たないが、送信すべき幾つかの他の小さなメッセージが存在する場合に、前記許可されたリソース全体を使用して送信する必要がないという認識に基づく。これが、前記一次局側のより多くの処理の必要性である欠点を持ちうることに注意しなくてはならない。
【００２６】
二次局が、データを持たない場合でさえ、バッファステータスレポートのような、ある小さなメッセージを送信すべきである場合、前記二次局が、制限されたリソース（及び減少された転送ブロックサイズ）で送信することが提案されている。前記一次局が、結果として生じるメッセージサイズ及び使用されるリソースを承知していることを保証するために、これらは、理想的には、前記許可されたリソースから得られるべきである。例えば、前記許可されたリソースがｎのリソースブロックである場合、前記使用されるリソースのサイズは、０．２５ｎのブロックであることができる。
【００２７】
前記二次局が現実にリソースを許可されるが、データを持たない場合、前記二次局は、バッファステータスレポート又は他のメッセージを送信することができる。アップリンク許可の誤検出の場合、結果として生じるアップリンク干渉は、典型的には、前記ＵＥが最大限の許可されたリソースを使用する場合より大幅に小さい。これは、システム全体のサービスの品質を増大させることを可能にする。
【００２８】
本発明の主な不利点は、前記一次局が追加の処理を持ちうることである。例えば、アップリンクパケットの受信が失敗する場合、前記一次局は、ＢＳＲがより小さなリソースにおいてデータを持たずに送信されるという仮定の下で復号を試みることも必要でありうる。これは、追加のソフトバッファが保持されることを必要とする。幸運なことに、ＢＳＲに対する転送ブロックサイズは大きくないので、追加の処理ロードは小さい。結果として、他の処理ロードが、対処されることができる。
【００２９】
ＬＴＥに基づく実施例において、二次局が、アップリンク送信に対する許可を受信するが、送信すべきデータを持たない場合、この規格は、前記二次局がバッファステータスレポートを送信することを必要とする。前記ＢＳＲは、許可メッセージから得られるリソースにおいて送信される。一例として、これは、前記許可されたリソース内のリソースブロックのセット内の単一の最小周波数リソースブロックであると規定されることができる。転送ブロックサイズは、前記ＢＳＲ（及び関連したオーバヘッド）を含むことができる最小サイズであるように固定される。
【００３０】
本発明の応用は、ＬＴＥに限定されない。前記リソースは、周波数領域リソースブロック、タイムスロット又はコードであることができる。
【００３１】
本発明は、無線チャネルステータスに関するレポートのような他のメッセージに応用されることもできる。主な要件は、メッセージサイズが既知であることである。この場合、ｅＮｏｄｅＢは、前記メッセージサイズ（及びリソース割り当て）を仮定して追加の復号を実行することができる。許可されるメッセージサイズの小さなセットのサポートが可能である。
【００３２】
本発明は、前記リソースがデータパケットに対して大きすぎる場合にも応用されることができ、この場合、より小さなリソースが代わりに使用されることができる（例えば許可されたリソースの半分）。一般に、このアプローチは、各ＵＬ許可に応答して許可される少数の追加のリソースサイズ（及び転送ブロックサイズ）を生じる。前記ｅＮｏｄｅＢは、したがって、サイズに関する異なる仮定の下で、各パケットに対して１より多い復号試行を実行することを必要とされうる。
【００３３】
本発明の変形例において、本発明は、以下の実施例の１つと組み合わせて使用されることができる。
【００３４】
時々、二次局２００は、送信されるべきデータを含むバッファのステータスの指示をアップリンクチャネル２６０上で送信する。このバッファステータスレポートは、異なるタイプであることができる。ショートバッファステータスレポート（ＢＳＲ）は、論理チャネルの単一のグループの識別子と、送信を待機している前記二次局のバッファ内に現在ある論理チャネルのグループに対応するデータの量の６ビットインジケータとを有する。ロングＢＳＲは、４つの連結したショートＢＳＲを有し、各ショートＢＳＲは、論理チャネルの異なるグループに対応する。
【００３５】
多くの通信システムは、異なるノードに送信リソースを割り当てるのに関与する集中型スケジューラを使用して動作する。典型例は、ＵＭＴＳ  ＬＴＥのアップリンクであり、ここで、異なるＵＥに対するアップリンク送信は、前記ｅＮＢにより時間及び周波数においてスケジュールされ、前記ｅＮＢは、ＵＥに対して"スケジューリング許可"メッセージを送信し、典型的には前記許可メッセージの送信の約３ｍｓ後の前記ＵＥの送信に対する特定の時間−周波数リソースを示す。前記許可メッセージは、また、典型的には、前記ＵＥの送信に対して使用されるデータレート及び／又はパワーを指定する。
【００３６】
前記ｅＮＢが適切な許可を発行するために、データの量、タイプ及び各ＵＥのバッファにおいて送信を待機しているデータの緊急性に関する十分な情報を持つことが必要である。この情報は、サービスがドロップされる寸前でありうるＵＥ又は個別のＵＥの満足レベルのいずれかを前記ｅＮＢにおける前記スケジューラに通知するのに使用されることができる。
【００３７】
したがって、ＬＴＥにおいて、ある数の異なるタイプのバッファステータスレポート（ＢＳＲ）が規定され、特定のトリガが生じる場合にＵＥから前記ｅＮＢに送信されることができる。これに関する最新技術は、参照により組み込まれる3GPP TS36.321の現在のバージョン（２００８年６月現在）、5.4.5章により規定される。
【００３８】
ショートＢＳＲは、論理チャネルの単一のグループの識別子と、送信を待機している前記ＵＥのバッファ内に現在ある論理チャネルのグループに対応するデータの量の６ビットインジケータとを有する。ロングＢＳＲは、４つの連結したショートＢＳＲを有し、各ショートＢＳＲは、論理チャネルの異なるグループに対応する。
【００３９】
これは、現在、参照により組み込まれる、36.321（２００８年６月現在）6.1.3.1章において規定されている。
【００４０】
この段落において詳述されるように、異なる特性を持つ２つの主なタイプのバッファステータスレポート（ＢＳＲ）、すなわち、
−ＵＬデータが前記ＵＥ送信バッファに到着し、前記データが前記ＵＥ送信バッファ内に既に存在したデータより高い優先度を持つ論理チャネルに属する場合のみにトリガされるレギュラＢＳＲ、
−定期ＢＳＲタイマが満了する場合にトリガされる定期ＢＳＲ、
が存在する。
【００４１】
前記ＵＥが、このＴＴＩに対する新しい送信に対して割り当てられたＵＬリソースを持たない場合、及びレギュラＢＳＲが、ＢＳＲの最後の送信以降にトリガされる場合、スケジューリング要求（ＳＲ）がトリガされるべきである。
【００４２】
このＢＳＲメカニズムは、レギュラＢＳＲの送信に対して利用可能であるＵＬリソースが存在しない場合に、レギュラＢＳＲのみがＳＲの送信をトリガすることができるように設計されている。定期ＢＳＲがトリガされ、割り当てられたＵＬリソースが存在しない場合、前記ＵＥが利用可能なデータを持ち、意図的に前記ＵＥの使用に対してＵＬリソースを割り当てていないことを前記ネットワークが知っていると仮定されるので、前記ＵＥは、ＳＲを送信することができない。
【００４３】
前記定期ＢＳＲが、前記ＢＳＲの送信に対してＵＬリソースが利用可能ではない場合にＳＲを送信することを可能にされた場合、このシステムは、ＳＲを送信するＵＥでオーバロードになりうる。特に前記ＵＥが利用可能なＰＵＣＣＨリソースを持たない場合、ＳＲは、ＲＡＣＨアクセスの送信を必要とする。
【００４４】
また、ＳＲが、保留であると見なされ、ＵＬ−ＳＣＨリソースが許可されるまで繰り返されることが、３６．３２１に記載されている。
【００４５】
上で規定されたＢＳＲ手順に対する問題は、前記ＵＥ内のバッファの状態に関して前記ネットワークが知っている情報が前記ＵＥバッファの実際の状態と異なることができる可能性が存在することである。これは、ＢＳＲが前記ｅＮＢにおいて狂った順番で受信される場合に生じることができる。
【００４６】
ネットワークが、異なる時間においてＵＥからＢＳＲを受信する場合、例えばＨＡＲＱ再送信により前のＢＳＲが後に受信されることもありうるので、いずれが前記ＵＥにより送信された最新のＢＳＲであるかを前記ｅＮＢが決定する方法は存在しない。これは、ゼロを持つＢＳＲが前記ＵＥにより受信されることができ、この場合、たとえ前記ＵＥがバッファ内に送信されるべきデータを持つとしても、前記ネットワークが前記ＵＥからＵＬリソースを除去するという問題を引き起こすことができる。定期ＢＳＲが構成されても、レギュラＢＳＲ（高い優先順位を持つ新しいデータ）に対するトリガが満たされないので、前記ＵＥは、ＳＲを送信することができない。
【００４７】
これの一例は、図２に示される。このタイムチャートにおいて、バッファステータスレポート１００１の前に送信されるバッファステータスレポート１０００が、複数回の再送信のために後にのみ受信されることが見られる。このレポート１０００は、定期レポートであることができ、データが前記バッファステータスレポート内に無いことを示すことができる。前記一次局が、示された順序で前記レポートを受信する場合、現在のステータスが、データが前記二次局のバッファ内に無いことであると誤信する。このため、許可されるべきであるＵＥからのＵＬリソースを除去する。
【００４８】
レポート１０００が、送信されるべきデータが存在することを示す通常のレポートであり、レポート１００１が、送信されるべきデータがこれ以上存在しないことを示す定期レポートである場合、前記一次局は、この混乱のため、必要とされていないにもかかわらず、リソースを割り当てうる。これは、リソースの無駄を生じる。しかしながら、この状況は、あまり起こる可能性は高くない。
【００４９】
ここで、主な問題は、ＳＲが定期ＢＳＲから生成された場合に、前記ＵＥが、どれも利用可能ではない場合に絶えずＵＬリソースを要求するので、ＳＲが、定期ＢＳＲから生成されるべきでないことである。
【００５０】
更に、上述の場合に、前記バッファステータスのネットワークビューは、実際のＵＥ  ＵＬデータバッファステータスと同期がずれている。本発明の一態様は、以下に説明されるように、送信をよりロバストにし、この問題が生じるリスクを低減するために、修正されたチャネル符号化を用いるＢＳＲの送信方法を提供する。
【００５１】
ＬＴＥにおいて、前記二次局が、データの量に対して大きすぎるアップリンク許可を持つ場合（例えばデータがバッファ内に無い場合）、前記二次局は、とにかく送信し、可能であればパディングＢＳＲを含むパディングを追加する。パディングは、許可された転送ブロックサイズに到達するために使用される。これは、送信されるべきデータが存在しない場合でさえ生じる。この状況は、パディングビットを送信することから無駄なアップリンクリソースを生じることができる。
【００５２】
前記ＢＳＲの信頼できる受信は、効率的なスケジューリングを可能にするために、重要である。したがって、ＢＳＲロバスト性を向上させる方法に関心がある。
【００５３】
原理的には、（値が既知であるとして）復号プロセスにおいて前記パディングビットを使用することが可能である。しかしながら、これは、受信器復号アルゴリズムに対する変更を必要とし、これらのビットを使用する最も効率的な方法ではない。
【００５４】
本発明の先行する実施例と組み合わせられることができるこれらの実施例は、二次局が、アップリンクデータ送信及びＢＳＲのような他の信号通知に必要とされるより多くのリソースを許可される場合、前記二次局が、パディングビットではなく追加の冗長性を送信するのに追加のリソースを使用することができるという認識に基づく。これは、ＢＳＲメッセージの正しい復号の可能性を増大させることができる。
【００５５】
前記ＵＥが所定の許可されたリソースに対する１より多いフォーマットを持つメッセージを送信することができる実施例の主な不利点は、前記一次局又はｅＮｏｄｅＢが、追加の処理を実行することを必要としうることである。例えば、アップリンクパケットの受信が失敗する場合、前記ｅＮｏｄｅＢは、パディングＢＳＲ（又は既知のサイズの他のメッセージ）のみが代わりに送信されているという仮定の下で復号を試みることも必要とされうる。これは、追加のソフトバッファが保持されることを必要とする。幸運なことに、ＢＳＲに対する転送ブロックサイズは大きくないので、付加的な処理ロードは、典型的には、小さい。
【００５６】
ＬＴＥに基づく１つの変形例において、二次局が（リソース及び転送ブロックサイズを示す）ＵＬ許可を受信するが、送信すべきデータを持たない場合、前記二次局は、パディングＢＳＲを送信する。本発明によると、前記転送ブロックサイズは、前記ＢＳＲを送信するのにちょうど十分である値に減少される。この場合、チャネル符号化は、通常通り適用され、これは、前記転送ブロックサイズまで冗長性を追加する。前記ｅＮｏｄｅＢは、まず通常の送信の仮定の下で、次いで失敗する場合に、ＢＳＲがより小さな転送ブロックで（しかしながらサイズの限定的セットの１つで）送信されるという仮定の下で、結果として生じるメッセージを復号しようと試みることができる。
【００５７】
ＬＴＥに基づく他の変形例において、二次局が（リソース及び転送ブロックサイズを示す）アップリンク許可を受信するが、前記許可に示されるより少ない送信すべきデータを持つ場合、本発明によると、（限定的なセットから選択されることができる）減少された転送ブロックサイズを決定し、パディングＢＳＲ及びデータを送信する。前記チャネル符号化は、前記選択された転送ブロックサイズに対して通常の形で適用される。結果として、前記チャネル符号化は、典型的には、通常サイズのブロックに対応する符号化より低いレートであることができ、したがって、送信は、エラーに対してよりロバストである。前記ｅＮｏｄｅＢは、まず通常送信の仮定の下で、次いで失敗する場合に、ＢＳＲが、より小さな転送ブロックサイズ（しかしながらサイズの限定的なセットの１つ）及び対応する符号化で送信されたという仮定の下で、結果として生じるメッセージを復号しようと試みることができる。この実施例の変形例において、１つの符号化のみが、転送ブロックの各サイズに関連付けられる。
【００５８】
ＬＴＥに基づくこの実施例の更に他の変形例において、ＵＥが（リソース及び転送ブロックサイズを示す）ＵＬ許可を受信するが、前記許可に示されるより少ない送信すべきデータを持つ場合、前記転送ブロックサイズは、変更されないが、前記メッセージが、前記許可された転送ブロックサイズに等しくなるまでサイズを増大させるために前記転送ブロック内で繰り返される。チャネル符号化は、通常の形で適用される。これは、パディングビットが、有効にデータ反復で置き換えられることを意味する。これは、前記データ反復を効率的に利用するために、受信器復号アーキテクチャに対する変更を必要とする不利点を持つ。
【００５９】
本発明及び様々な実施例は、通信装置がＵＭＴＳ及びＬＴＥのような集中型スケジューリングを使用する移動体通信システムにおいて実施されることができる。
【００６０】
更に、本発明は、複数の端末から基地局への接続をルーティングするハブに対して実施されることもできる。このような装置は、ネットワークの観点から二次局のように見える。
【００６１】
本明細書及び請求項において、要素に先行する単語"１つの"（"a"又は"an"）は、複数のこのような要素の存在を除外しない。更に、単語"有する"は、リストされた要素又はステップ以外の要素又はステップの存在を除外しない。
【００６２】
請求項内の括弧内の参照符号の包含は、理解を助けることを意図され、限定することを意図されない。
【００６３】
本開示を読むことにより、他の修正例が、当業者に明らかである。このような修正例は、無線通信の分野、送信器パワー制御の分野において既知であり、ここに既に記載されたフィーチャの代わりに又は加えて使用されることができる他のフィーチャを含むことができる。
【図１】
0005575767.tif 000002
【図２】
0005575767.tif 000003