(57)【特許請求の範囲】
【請求項１】
可変レート・ボコーダ（２２）を有するユーザ機器（２０）にメッセージを送るステップ（Ｓ３１０）であって、前記メッセージが、会話区間の間にアップリンク送信のためのパケット・サイズを変えることが前記ユーザ機器に許可される場合に前記ユーザ機器がアップリンク送信を行う際に選択するための２つ以上のトランスポート・ブロック・サイズを定義するステップと、
前記ユーザ機器にスケジューリング許可を送るステップ（Ｓ３２０）であって、前記スケジューリング許可が、会話区間の間に前記定義されたトランスポート・ブロック・サイズの中から１つのトランスポート・ブロック・サイズを自律的に選択して使用すること、および、会話区間の間にアップリンク送信のための前記パケット・サイズを変えることが前記ユーザ機器に許可されることを示すインジケータを含むステップとを含み、
前記インジケータは、前記ユーザ機器が、定義されたトランスポート・ブロック・サイズのうち、ユーザ機器のバッファ中のデータの送達が可能な最小サイズを選択するためのものであることを示す方法。
【請求項２】
前記メッセージが４つの異なるトランスポート・ブロック・サイズを示し、前記４つの異なるトランスポート・ブロック・サイズが２５６ビット、１３６ビット、１０４ビット、および７２ビットである、請求項１に記載の方法。
【請求項３】
前記メッセージが２つの異なるトランスポート・ブロック・サイズを示し、前記２つの異なるトランスポート・ブロック・サイズが２５６ビットおよび１０４ビットである、請求項１に記載の方法。
【請求項４】
前記スケジューリング許可の中の前記インジケータが、使用されない変調・符号化方式レベルである、請求項１に記載の方法。
【請求項５】
前記インジケータが、前記定義されたトランスポート・ブロック・サイズのうち、前記ユーザ機器のバッファ中のデータの送達が可能な最小サイズを選択することが前記ユーザ機器に許可されることを示す、請求項１に記載の方法。
【請求項６】
アップリンク送信の前記パケット・サイズに基づいて送信電力を変更することを前記ユーザ機器に許可するための電力制御規則を設定するステップをさらに含む、請求項１に記載の方法。
【請求項７】
可変レート・ボコーダ（２２）を有するユーザ機器（２０）において、会話区間の間にアップリンク送信のためのパケット・サイズを変えることが前記ユーザ機器に許可される場合に前記ユーザ機器がアップリンク送信を行う際に選択するための２つ以上のトランスポート・ブロック・サイズを定義するメッセージを受信するステップ（Ｓ４１０）と、
前記ユーザ機器においてスケジューリング許可を受信するステップ（Ｓ４２０）であって、前記スケジューリング許可が、会話区間の間に前記定義されたトランスポート・ブロック・サイズの中からトランスポート・ブロック・サイズを選択して使用することによって会話区間の間にアップリンク送信のための前記パケット・サイズを変えることが前記ユーザ機器に許可されることを示すインジケータを含むステップと、
前記定義されたトランスポート・ブロック・サイズの中からトランスポート・ブロック・サイズを自律的に選択することによって会話区間の間にアップリンク送信のための前記パケット・サイズを変えることが前記ユーザ機器に許可されることを前記インジケータが示す場合に、前記定義されたトランスポート・ブロック・サイズの中からトランスポート・ブロック・サイズを選択するステップ（Ｓ４５０）であって、前記ユーザ機器が、定義されたトランスポート・ブロック・サイズのうち、ユーザ機器のバッファ中のデータの送達が可能な最小サイズを選択するステップと、
前記選択したトランスポート・ブロック・サイズに基づいてアップリンク上でパケットを送信するステップ（Ｓ４６０）とを含む方法。
【請求項８】
前記ユーザ機器がアップリンク送信のパケット・サイズに基づいて送信電力を変更することを電力制御規則が許可する場合に、送信のための前記パケットのパケット・サイズに基づいて電力制御を設定するステップをさらに含む、請求項７に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
３ＧＰＰがＵＭＴＳを３ＧＰＰロングターム・エボリューション（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）（ＬＴＥ）における純粋なパケット交換技術へと発展させるのに伴い、音声トラフィックが搬送されることになる方法はボイスオーバＩＰ（ＶｏＩＰ）の形をとる。３ＧＰＰ  ＬＴＥにおけるボイスオーバＩＰ（ＶｏＩＰ）の現行サポートは、ＧＳＭおよびＵＭＴＳで使用されてきたアダプティブ・マルチレート（ａｄａｐｔｉｖｅ  ｍｕｌｔｉｒａｔｅ）（ＡＭＲ）ボコーダに合わせられている。ＬＴＥに移行するＣＤＭＡオペレータのＣＤＭＡネットワーク中でＥＶＲＣ（ｅｎｈａｎｃｅｄ  ｖａｒｉａｂｌｅ  ｒａｔｅ  ｃｏｄｅｃ）が現在使用されており、ＬＴＥへの移行時にＥＶＲＣからＡＭＲにトランスコードしなければならない場合に生じるであろう遅延および品質劣化をオペレータが回避したいならば（すなわち、オペレータのネットワーク上のＬＴＥユーザがＥＶ−ＤＯユーザまたは１ｘユーザに発呼するときは常に、ＬＴＥネットワーク上のＡＭＲコーデックと、１ｘおよびＥＶ−ＤＯネットワーク上のＥＶＲＣコーデックとの間でトランスコーディングが生じなければならないことになる）、オペレータにとっては、ＥＶＲＣが、一般に好まれるボコーダである。
【０００２】
ＡＭＲボコーダとは異なり、ＥＶＲＣボコーダは、会話区間の間に可変サイズのパケットを生成し、改良されたＥＶＲＣ−Ｂボコーダは、実際に、いくらかの通話品質をトレードオフしながらＣＤＭＡネットワーク上の容量を改善するために、より小さいパケットをより頻繁に利用できる種々のモードを可能にする。
【０００３】
残念ながら、ＶｏＩＰに対する現在のＬＴＥアップリンク・サポートによれば、ＵＥは単一のパケット・サイズでしか送信することができず、この単一のパケット・サイズは、最大ＶｏＩＰパケット・サイズに対応するために十分に大きくなければならない。このことは、会話区間中に１つのパケット・サイズしか出力しないＡＭＲボコーダ（例えばＡＭＲ１２．２ｋｂｐｓの場合に２４４ビット）では良いが、会話区間中に様々なパケット・サイズを出力するＥＶＲＣ（例えば１７１ビットもの大きいサイズから４０ビットもの小さいサイズまで）では非常に効率が悪くなる。この結果、現在の３ＧＰＰ  ＬＴＥ標準を使用すると穴埋めのためのオーバヘッドが大きくなり、この結果また、送信電力レベルが必要ＵＥ送信電力レベルよりも高くなり、これは、他のセルに対する余分な干渉を生成して最終的にはシステム容量全体を低減する。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】３ＧＰＰ  ＴＳ３６．２１３
【非特許文献２】３ＧＰＰ  ＴＳ２６．２１３
【非特許文献３】３ＧＰＰ  ＴＳ３６．３３１
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、可変レート・ボコーダを利用するユーザ機器のためのボイスオーバ・インターネット・プロトコル（ＶｏＩＰ）容量の改善に関する。
【課題を解決するための手段】
【０００６】
一実施形態では、ワイヤレス・ネットワークから、可変レート・ボコーダを有するユーザ機器にメッセージが送られる。メッセージは、アップリンク送信のためのパケット・サイズを変えることがユーザ機器に許可される場合にユーザ機器がアップリンク送信を行う際に選択するためのトランスポート・ブロック・サイズを定義する。スケジューリング許可がユーザ機器に送られるが、スケジューリング許可は、定義されたトランスポート・ブロック・サイズの中からトランスポート・ブロック・サイズを選択することによってアップリンク送信のためのパケット・サイズを変えることがユーザ機器に許可されることを示すインジケータを含む。
【０００７】
一実施形態では、メッセージは、無線リソース制御メッセージである。メッセージは、例えば、２５６ビット、１３６ビット、１０４ビット、および７２ビットなど、４つの異なるトランスポート・ブロック・サイズを示してよい。しかし、メッセージは、４つよりも多いかまたは少ないトランスポート・ブロック・サイズを示してもよい。
【０００８】
一実施形態では、インジケータは、定義されたトランスポート・ブロック・サイズのうち、ユーザ機器のバッファ中のデータの送達が可能な最小サイズを選択することがユーザ機器に許可されることを示す。スケジューリング許可の中のインジケータは、使用されない変調・符号化方式レベルとすることができる。
【０００９】
別の実施形態では、方法はさらに、アップリンク送信のパケット・サイズに基づいて送信電力を変更することをユーザ機器に許可するための電力制御規則を設定することを含む。
【００１０】
さらに別の実施形態は、定義されたトランスポート・パケット・サイズに基づいて、ユーザ機器から受信された送信のブラインド復号を実施することを含む。
【００１１】
別の実施形態では、可変レート・ボコーダを有するユーザ機器が、ユーザ機器がアップリンク送信のためのパケット・サイズを変えることが許可される場合にユーザ機器がアップリンク送信を行う際に選択するためのトランスポート・ブロック・サイズを定義するメッセージを受信する。ユーザ機器はさらに、定義されたトランスポート・ブロック・サイズの中からトランスポート・ブロック・サイズを選択することによってアップリンク送信のためのパケット・サイズを変えることがユーザ機器に許可されることを示すインジケータを含むスケジューリング許可を受信することができる。ユーザ機器は、定義されたトランスポート・ブロック・サイズの中からトランスポート・ブロック・サイズを選択することによってアップリンク送信のためのパケット・サイズを変えることがユーザ機器に許可されることをインジケータが示す場合に、定義されたトランスポート・ブロック・サイズの中からトランスポート・ブロック・サイズを選択し、選択したトランスポート・ブロック・サイズに基づいてアップリンク上でパケットを送信する。
【００１２】
一実施形態では、ユーザ機器は、定義されたトランスポート・ブロック・サイズのうち、ユーザ機器のバッファ中のデータの送達が可能な最小サイズを選択する。
【００１３】
本発明の例示的な実施形態は、以下に提供する詳細な記述および添付の図面からより完全に理解されるようになるであろう。この記述および図面では、同じ要素は同じ参照番号で表されるが、この記述および図面は、例示として提供するに過ぎず、したがって本発明を限定するものではない。
【図面の簡単な説明】
【００１４】
【図１】ワイヤレス・ネットワークの一部を示す図である。
【図２】通話に応じた、ＥＶＲＣ−Ｂボコーダによるフルレート、２分の１レート、４分の１レート、および８分の１レートの選択を示す図である。
【図３】例示的な一実施形態による、ネットワークによる可変サイズのアップリンク送信のスケジューリングおよび処理の方法のフローチャートである。
【図４】例示的な一実施形態による、スケジュールされたアップリンク送信をユーザ機器において実施する方法のフローチャートである。
【発明を実施するための形態】
【００１５】
次に、本発明のいくつかの例示的な実施形態が示されている添付の図面を参照しながら、本発明の様々な例示的な実施形態についてより完全に述べる。図面では、明確にするために、レイヤの厚さおよび領域は誇張されている。
【００１６】
本明細書では、本発明の詳細な説明的実施形態を開示する。しかし、本明細書に開示する特定の構造的および機能的な詳細は、本発明の例示的な実施形態を記述するための代表的なものに過ぎない。しかし本発明は、多くの代替形で具体化することができ、本明細書に示す実施形態のみに限定されると解釈すべきではない。
【００１７】
したがって、本発明の例示的な実施形態は様々な修正および代替形が可能だが、本発明の実施形態を図面に例として示し、本明細書に詳細に述べる。しかし、開示する特定の形に本発明の例示的な実施形態を限定する意図はなく、逆に、本発明の例示的な実施形態は、本発明の範囲内に入る全ての修正、均等物、および代替をカバーするものであることを理解されたい。各図の記述を通して、同じ番号は同じ要素を指す。
【００１８】
本明細書では、第１、第２などの用語を使用して様々な要素を記述する場合があるが、これらの要素がこれらの用語によって限定されるべきでないことは理解されるであろう。これらの用語は、ある要素を別の要素と区別するために使用するに過ぎない。例えば、本発明の例示的な実施形態の範囲を逸脱することなく、第１の要素を第２の要素と呼ぶこともでき、同様に第２の要素を第１の要素と呼ぶこともできる。本明細書において、用語「および／または」は、関連する列挙された項目の１つまたは複数の、いずれかまたは全ての組合せを含む。
【００１９】
ある要素が別の要素に「接続される」または「結合される」として言及されるとき、この要素は、他方の要素に直接に接続または結合されてもよく、あるいは介在要素が存在してもよいことは理解されるであろう。対照的に、ある要素が別の要素に「直接に接続される」または「直接に結合される」として言及されるとき、介在要素は存在しない。要素間の関係について述べるのに使用される他の語も、同様にして解釈すべきである（例えば、「〜との間で」と「〜との間で直接に」、「隣接する」と「直接に隣接する」、など）。
【００２０】
本明細書で使用される術語は、特定の実施形態を記述するためのものに過ぎず、本発明の例示的な実施形態を限定するものとはしない。本明細書において、コンテキストによる明確な別段の指示がない限り、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、複数形も含むものとする。さらに、用語「ｃｏｍｐｒｉｓｅ」、「ｃｏｍｐｒｉｓｉｎｇ」、「ｉｎｃｌｕｄｅｓ」、および／または「ｉｎｃｌｕｄｉｎｇ」は、本明細書においては、述べる特徴、整数、ステップ、動作、要素、および／またはコンポーネントの存在を指定するが、１つまたは複数の他の特徴、整数、ステップ、動作、要素、コンポーネント、および／またはこれらのグループの存在または追加を排除しないことも、理解されるであろう。
【００２１】
また、いくつかの代替実施形態では、言及される機能／行為が、図に示される順序以外で行われてもよいことにも留意されたい。例えば、連続して示される２つの図形が、関連する機能／行為に応じて、実際にはほぼ同時に実行されてもよく、あるいは逆の順序で実行されることがあってもよい。
【００２２】
本明細書において、用語「ユーザ機器」は、モバイル、モバイル・ユニット、移動局、モバイル・ユーザ、加入者、ユーザ、リモート局、アクセス端末、受信機などと同義と見なすことができ、以下では時としてこのように言及されることがある。「ユーザ機器」は、ワイヤレス通信ネットワーク中のワイヤレス・リソースのリモート・ユーザを記述することができる。用語「基地局」は、ベース・トランシーバ・ステーション（ＢＴＳ）、ノードＢ、拡張ノードＢ、フェムト・セル、アクセス・ポイントなどと同義と見なすことができ、かつ／またはこのように言及されることがある。「基地局」は、ネットワークと１人または複数のユーザとの間のデータ接続性および／または音声接続性のための無線ベースバンド機能を提供する機器を記述することができる。
【００２３】
図１に、３ＧＰＰロングターム・エボリューション（ＬＴＥ）ワイヤレス・ネットワークの一部を示す。図示のように、基地局１０が、ユーザ機器（ＵＥ）２０のワイヤレス通信ニーズを満たす。図１では、単一のユーザ機器２０のみ、および単一の基地局１０のみが示されている。しかし、基地局１０が複数のユーザ機器のワイヤレス通信ニーズを満たしてよく、ネットワークが複数の基地局を含んでよいことは、理解されるであろう。
【００２４】
基地局１０はスケジューラ１２を備えるが、スケジューラ１２は、ユーザ機器２０のアップリンク送信（ＵＥからワイヤレス・ネットワークへの送信）をスケジュールする。ユーザ機器は、ＥＶＲＣまたはＥＶＲＣ−Ｂボコーダなど、可変レート・ボコーダ２２を備える。
【００２５】
ボイスオーバＩＰトラフィックは、ＬＴＥアップリンクにおいて、スケジューラ１２による動的スケジューリングを介してまたは半永続的スケジューリングを介してサポートすることができる。動的スケジューリングでは、スケジューラ１２は、ＵＥ２０によって送信される各ＶｏＩＰパケットのために、スケジューリング許可を発行する。この方法は、スケジューリング許可利用（これはＬＴＥにおける限られたリソースである）の点で非効率的であり、したがって半永続的スケジューリングが導入された。半永続的スケジューリングは、基地局スケジューラ１２が１つのスケジューリング許可をＵＥ２０に送ることを可能にし、このスケジューリング許可は、どんな追加のスケジューリング許可もなしに、最初のスケジューリング許可中で指定されるフォーマットを使用してＸミリ秒毎に送信することがＵＥ２０に許容されることを意味するものとして、ＵＥ２０がこの許可を理解するという意味で、永続的になる。許可の周期性Ｘは、呼セットアップ時に、より高いレイヤのシグナリング（例えば無線リソース制御（ＲＲＣ）シグナリング）を介して構成される。Ｘの典型的な値は２０ミリ秒であろうが、２０ミリ秒は、多くのボコーダ（ＡＭＲおよびＥＶＲＣ／ＥＶＲＣ−Ｂボコーダなど）から通話フレームが生成される際のレートと整合する。
【００２６】
ＡＭＲの場合、ユーザが話しているとき、ボコーダは、２０ミリ秒毎に固定サイズのパケットを生成することになる。ＡＭＲ１２．２ｋｂｐｓボコーダの場合、パケット・サイズは、生成される通話フレーム毎に２４４ビットである。基地局スケジューラ１２は、動的な許可の中で、または最初の半永続的な許可の中で、ＵＥのＭＡＣレイヤ中で予期されるパケット・サイズに合致する変調・符号化方式（ＭＣＳ）レベルを割り当てることになる。２４４ビットの通話フレームは、ＰＤＣＰレイヤにおけるロバスト・ヘッダ圧縮（ＲＯＨＣ）と共に、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣオーバヘッドにより、３１２ビットのＭＡＣサービス・データ・ユニット（ＳＤＵ）になる。ＴＳ３６．２１３における現在のトランスポート・ブロック・サイズ・テーブルに基づけば、３２８ビットのブロック・サイズが、スケジューリング許可の中で示す妥当な選択肢であろう。
【００２７】
ここで、ＥＶＲＣまたはＥＶＲＣ−ＢボコーダがＵＥ２０などと共に使用されるとき、ユーザが話している間にボコーダ２２によって生成される通話パケットには４つの異なるサイズがある。これら４つの異なるサイズは、フルレート・フレーム、２分の１レート・フレーム、４分の１レート・フレーム、および８分の１レート・フレームと呼ばれる。ＥＶＲＣ−Ｂモード４についての以下の表１に、ボコーダ２２によって生成されるフレーム・サイズ、および、ＭＡＣレイヤにおけるオーバヘッドを含めたサイズ、ならびに、これらのフレーム・サイズが通常の通話中に利用される時間割合を提供する。
【００２８】
どのパケット・サイズがＥＶＲＣボコーダ２２によって生成されることになるかは、図２に示すように話者の実際の通話に依存するので、基地局スケジューラ１２がこれを知る方法はない。したがって、動的スケジューリングであっても、基地局スケジューラ１２は、最大パケットを保持するのに十分な大きいトランスポート・ブロック・サイズ（この場合は２３２ビットのＭＡＣ  ＳＤＵサイズ）をスケジュールすることを選択しなければならない。ＴＳ２６．２１３において利用可能な最も近いトランスポート・ブロック・サイズは２５６ビットであり、したがって基地局スケジューラ１２は、常に２５６ビットのＭＡＣ  ＰＤＵサイズをスケジュールすることになる。より小さいＭＡＣ  ＰＤＵパケットが存在するとき、ＵＥ２０におけるＭＡＣレイヤは、余分なビットを穴埋め（パディング）して２５６ビット許可を埋めなければならず、この結果、パディング・オーバヘッドが生じる。これを表２に例示するが、表２には、フレーム・タイプ毎のパディング・オーバヘッド、ならびに、各フレーム・タイプがアクティブ通話中に使用される時間割合を使用して計算された平均パディング・オーバヘッドが記載されている。平均オーバヘッドは１４８％である。
【００２９】
【表１】
0005956348.tif 000002
【００３０】
【表２】
0005956348.tif 000003
【００３１】
本発明の一実施形態により、アップリンク（例えばＬＴＥアップリンク）のための新しいタイプのスケジューリング許可が開発された。この新しいスケジューリング許可により、基地局スケジューラ１２は、許容されるトランスポート・ブロック・サイズの定義済みリストから最も適切なトランスポート・ブロック・サイズ（例えばＭＡＣ  ＰＤＵサイズ）を自律的に選択することがＵＥのＭＡＣレイヤに許容されることを、ＵＥ２０に知らせることができる。定義済みリストは、呼セットアップ時に、より高いレイヤのシグナリング（例えばＲＲＣシグナリング）によって搬送されてよく、基地局１０によるスケジューリング許可の中の特別なインジケータが、この定義済みセットから最も適切なパケット・サイズを自律的に選択することがＵＥ２０に許容されることを、ＵＥ２０に知らせる。
【００３２】
図３に、例示的な一実施形態による、ネットワークによる可変サイズのアップリンク送信のスケジューリングおよび処理の方法のフローチャートを示す。図示のように、ステップＳ３１０で、基地局１０は、ＵＥ２０にメッセージを送ってトランスポート・ブロック・サイズを定義する。上に論じたように、このメッセージは、呼セットアップ時に搬送されてよい。例えば、より高いレイヤ構成が、この制限されたトランスポート・ブロック・サイズのセットをＵＥ２０に知らせるものとすることができる。より具体的には、この情報は、半永続的スケジューリングに使用される現在のＲＲＣシグナリング・メッセージに含まれてよい。具体的な例として、周知のＴＳ３６．３３１プロトコルにおけるＳＰＳ−ＣｏｎｆｉｇＵＬ情報要素を修正して、以下の変数を含めることができる。
ＢｌｉｎｄＤｅｃｏｄｉｎｇＴｒａｎｓｐｏｒｔＢｌｏｃｋＳｉｚｅＳｅｔ
ＩＮＴＥＧＥＲ｛ＴＢＳ１，ＴＢＳ２，ＴＢＳ３，ＴＢＳ４｝
ここで、ＴＢＳ１、ＴＢＳ２、ＴＢＳ３、およびＴＢＳ４は、ＵＥがアップリンク送信のためにその中から選択できる４つのトランスポート・ブロック・サイズである。例えば、３ＧＰＰ  ＴＳ３６．２１３における許容されるトランスポート・ブロックに関しては、一実施形態による許容されるトランスポート・ブロック・サイズのセットは｛２５６，１３６，１０４，７２｝ビットである。これらが現在、３ＧＰＰ仕様において許容されるトランスポート・ブロック・サイズである。
【００３３】
次にステップＳ３２０で、基地局スケジューラ１２は、アップリンク送信のためのパケット・サイズをＵＥ２０が変えられることを示すスケジューリング許可を送ることができる。本開示では、パケット・サイズ、トランスポート・ブロック・サイズ、およびＭＡＣ  ＰＤＵサイズという用語を、交換可能に使用する。一実施形態では、スケジューリング許可は、ＵＥのバッファ中のデータの送達が可能な最小パケット・サイズを定義済みセットから自律的に選択することがＵＥに許容されることをＵＥに知らせるための、特別なインジケータを含む。例えば、ＵＬスケジューリング許可の中のこの特別な指示は、変調・符号化方式（ＭＣＳ）レベル３０、３１、または３２をシグナリングするものとすることができ、これらのレベルは、３ＧＰＰ仕様において使用されていない、現在予約済みの値である。
【００３４】
定義済みトランスポート・ブロック・サイズからトランスポート・ブロック・サイズを自律的に選択することがＵＥ２０に許可されることをインジケータが示すと仮定すると、ＵＥ２０は、トランスポート・ブロック・サイズを選択し、選択したトランスポート・ブロック・サイズに基づいてアップリンク上で送信する（以下の図４参照）。この場合、ＭＡＣ  ＰＤＵ（すなわちトランスポート・ブロック）パディング・オーバヘッドは、表３に例示するように、平均してほんの８．２％に低減されることになる。
【００３５】
【表３】
0005956348.tif 000004
【００３６】
ステップＳ３３０で、基地局１０は、アップリンク送信を受信する。この後、基地局１０は、ＵＥがどのパケット・サイズを選択したかを決定するために、ブラインド復号を実施する。すなわち、基地局１０は、ＵＥが定義済みリストに基づいてパケット・サイズ（トランスポート・ブロック・サイズ）のうちの１つを選択したと仮定して、この特別なスケジューリング許可に対応するＵＥの送信の復号を試みる。この例では、４回のブラインド復号が必要である。種々のパケット・サイズがどれくらいの頻度で使用されるかがわかっているとすれば、ブラインド復号の順序は、以下の順序に従うことができる。例えば、ＥＶＲＣ−Ｂモード４では、最初に、フルレート・フレーム（この例では２５６ビット）に対応するパケット・サイズの復号を試みる。次いで、これが失敗した場合、４分の１レート・フレームに対応するパケット・サイズの復号を試みる。次いで、これが失敗した場合、２分の１レート・フレームの復号を試みる。次いで、８分の１レート・フレームの復号を試みる。これにより、必要とされるブラインド復号の平均回数が最小限に抑えられることになるが、最大回数は、この例ではなお４回となる（定義済みトランスポート・ブロック・サイズ・セットのサイズ）。当然、ブラインド復号を順次実施する代わりに、並行して、または逐次と並行の組合せで実施してもよい。
【００３７】
別の実施形態では、上記の方法がさらに単純化される。ＥＶＲＣ−Ｂモード４のフレーム利用統計から明白なように、２分の１レートおよび８分の１レート・フレームは、使用頻度が非常に低い。フルレートおよび４分の１レート・フレームが、ほとんどの時に使用される。したがって、定義済みトランスポート・ブロック・サイズ・セットを、２つの要素すなわち｛２５６，１０４｝ビットに制限することができる。以下の表４に、この実施形態についてのＭＡＣ  ＰＤＵパディング・オーバヘッドを例示するが、表４では、平均パディング・オーバヘッドは、ほんの１４．８％である。ここでの利点は、基地局１０において、多くても２回のブラインド復号しか必要とされないことである。また、４つ未満のトランスポート・ブロック・サイズを定義する代わりに、４つよりも多いトランスポート・ブロック・サイズを定義してもよいことも理解されるであろう。
【００３８】
【表４】
0005956348.tif 000005
【００３９】
図４に、図３の実施形態に関連する例示的な一実施形態による、スケジュールされたアップリンク送信をユーザ機器において実施する方法のフローチャートを示す。図示のように、ステップＳ４１０で、ＵＥ２０は、ステップＳ３１０で基地局１０から送られたメッセージを受信する。想起されるように、このメッセージは、許可されるトランスポート・ブロック・サイズを定義する。次にステップＳ４２０で、ＵＥ２０は、基地局１０からスケジューリング許可を受信する。
【００４０】
ステップＳ４３０でＵＥ２０は、スケジューリング許可がアップリンク送信のパケット・サイズを変えることがＵＥ２０に許可されることを示す特別なインジケータを含むかどうか判定する。例えば、ＭＣＳレベル３０が設定されている場合は、ＵＥ２０は、パケット・サイズを変えることがＵＥ２０に許可されると判定する。ＭＣＳレベル３０が設定されていない場合は、ＵＥ２０は、パケット・サイズを変えることがＵＥ２０に許可されないと判定する。すなわち、ステップＳ４４０で、固定の最大パケット・サイズを使用した従来のアップリンク送信が行われることになる。
【００４１】
パケット・サイズを変えることが許可される場合は、ステップＳ４５０で、ＵＥ２０は、いずれかの周知の方式で、ＵＥのバッファ中のデータの送達が可能な最小パケット・サイズ（すなわちトランスポート・ブロック・サイズ）を定義済みセットから自律的に選択する。次いでＵＥ２０は、選択したトランスポート・ブロック・サイズに基づいてアップリンク上で送信する。
【００４２】
周知のように、ＬＴＥ標準では、３ＧＰＰ  ＴＳ３６．２１３に記載の電力制御規則におけるＫｓ＝１．２５（Ｋｓ＝０に反して）を設定することにより、種々のトランスポート・ブロック・サイズ（正確には変調・符号化レベル）で、ＵＥ送信電力スペクトル密度の自律的な調整が可能である。したがって、ＵＥ２０がトランスポート・ブロック・サイズを変えることを基地局１０が許可する場合は、基地局１０は、電力制御規則Ｋｓ＝１．２５を設定することになる。これは、図３のステップＳ３２０で特別なインジケータを含むスケジューリング許可を送る前に実施することができる。ＵＥ２０が定義済みセットからより小さいパケット・サイズを選択したときは、ＵＥ２０はその送信電力スペクトル密度も低減することになり、このことは、ＵＥ電池寿命を向上させる利点、ならびに、より少ない干渉を生むことによってシステム容量を向上させる利点を有する。当然、より大きいパケット・サイズが選択された場合は、ＵＥは、その送信電力スペクトル密度を増大させることができる。
【００４３】
送信電力における達成可能な低減を定量化するために、２５６ビット、１３６ビット、１０４ビット、および７２ビットのトランスポート・ブロック・サイズについてのリンク・レベル・シミュレーションを実施した。シミュレーションは、実際のチャネル推定を使用して、電力制御がイネーブルにされた状態で実行した。ＨＡＲＱ送信の最大数は４に設定し、ＶｏＩＰトラフィックの基準として１％のＨＡＲＱ後ＢＬＥＲを目標とした。また、２つの物理リソースブロック（ＰＲＢ）によるＱＰＳＫ変調も使用した。
【００４４】
表５は、２５６ビットのＭＡＣ  ＰＤＵサイズを常に利用したであろう従来の方法と比較して、４分の１レート・フレーム・サイズの場合に、必要ＳＩＮＲのほぼ３ｄＢの低減が達成されることを示す。必要ＳＩＮＲが３ｄＢ低減されることは、ＵＥが３ｄＢ低い電力を使用してこれらのパケットを送信できる（送信電力を半分に削減できる）ことを意味し、４分の１レート・フレームが、ＥＶＲＣ−Ｂモード４ボコーダを使用したアクティブな通話の間のほぼ４０％の時間に利用される。
【００４５】
【表５】
0005956348.tif 000006
【００４６】
以上、本発明について述べたが、本発明を多くの方式で変形できることは自明であろう。このような変形は本発明を逸脱するものとは見なされず、このような全ての修正は本発明の範囲に含まれるものとする。
【図１】
0005956348.tif 000007
【図２】
0005956348.tif 000008
【図３】
0005956348.tif 000009
【図４】
0005956348.tif 000010