(57)【特許請求の範囲】
【請求項１】
LTE（long  term  evolution）無線ネットワークにおける無線リソースブロック割り当ての方法であって、
ユーザ装置のための下りリンク制御情報メッセージを生成するステップであり、前記下りリンク制御情報メッセージは、1から最大数の割り当てられた物理リソースブロックの複数の全ての可能な物理リソースブロック割り当てへのインデックスを指定することにより、前記ユーザ装置にスケジューリングされた最大数までの割り当てられた物理リソースブロックを示すリソースブロック割り当てフィールドを有し、前記リソースブロック割り当てフィールドは、複数の物理リソースブロックグループの中の物理リソースブロックグループの1から前記最大数の割り当てられた物理リソースブロックの割り当てのための全ての可能な物理リソースブロック割り当てを指定するために必要なビット数をせいぜい有し、前記最大数の割り当てられた物理リソースブロックは、0より大きく物理リソースブロックの総数より小さい整数であるステップと、
直交周波数分割多重を使用して物理下りリンク制御チャネルで前記下りリンク制御情報を送信するステップと
を有する方法。
【請求項２】
前記ユーザ装置に割り当てられた物理リソースブロックで前記ユーザ装置にVoIP（voice-over-internet-protocol）パケットを送信するステップを有する、請求項１に記載の方法。
【請求項３】
前記リソースブロック割り当てフィールドは、前記物理下りリンク制御チャネルのアドレスを参照して前記ユーザ装置に割り当てられた前記最大数までの割り当てられた物理リソースブロックを指定する、請求項１に記載の方法。
【請求項４】
前記リソースブロック割り当てフィールドは、ePDCCH（enhanced  physical  downlink  control  channel）のアドレスを参照して前記ユーザ装置に割り当てられた前記最大数までの割り当てられた物理リソースブロックを指定し、前記ePDCCHは、共通のリソースブロックグループにおいて第１の物理リソースブロックから送信される、請求項１に記載の方法。
【請求項５】
前記最大数の割り当てられた物理リソースブロックは、前記ユーザ装置に送信されるRRCメッセージの一部としてシグナリングされる、請求項１に記載の方法。
【請求項６】
前記下りリンク制御情報メッセージは、スクランブルインジケーション、アンテナポート及びレイヤ数のうち１つの情報を含まない、請求項１に記載の方法。
【請求項７】
前記下りリンク制御情報メッセージは、変調及び符号化方式インジケーション、新規データインジケーション及び冗長バージョンインジケーションのうち１つの情報を含まない、請求項１に記載の方法。
【請求項８】
ユーザ装置のための下りリンク制御情報メッセージを生成するように構成されたスケジューラモジュールであり、前記下りリンク制御情報メッセージは、全て同じリソースブロックグループに割り当てられる1から最大数のスケジューリングされた物理リソースブロックの複数の全ての可能な物理リソースブロック割り当てへのインデックスを指定することにより、最大数までのスケジューリングされた物理リソースブロックを前記ユーザ装置に割り当て、前記最大数のスケジューリングされた物理リソースブロックは、0より大きくリソースブロックの総数より小さい整数であり、前記インデックスは、複数の物理リソースブロックグループの中の物理リソースブロックグループの1から前記最大数のスケジューリングされた物理リソースブロックの複数の全ての可能な物理リソースブロック割り当てを指定するために必要なビット数をせいぜい有するスケジューラモジュールと、
決定された制御チャネルエレメントでスケジューリングメッセージを送信するように構成されたトランシーバと
を有するeNodeB。
【請求項９】
前記eNodeBと前記ユーザ装置との間の通信モードは、送信モード9である、請求項８に記載のeNodeB。
【請求項１０】
前記最大数のスケジューリングされた物理リソースブロックは、前記最大数までのスケジューリングされた物理リソースブロックで送信されるパケットを復号化するために必要な最小の信号対干渉及び雑音比に基づいて決定される、請求項８に記載のeNodeB。
【請求項１１】
スケジューラは、同じリソースブロックグループ内で２つの不連続な物理リソースブロックをスケジューリングするように構成される、請求項８に記載のeNodeB。
【請求項１２】
前記下りリンク制御情報は、物理下りリンク制御チャネルのアドレスを参照して前記ユーザ装置に割り当てられた前記最大数までのスケジューリングされた物理リソースブロックを指定する、請求項８に記載のeNodeB。
【請求項１３】
前記下りリンク制御情報は、ePDCCH（enhanced  Physical  Downlink  Control  Channel）のアドレスを参照して前記ユーザ装置に割り当てられた前記最大数までのスケジューリングされた物理リソースブロックを指定する、請求項８に記載のeNodeB。
【請求項１４】
物理下りリンク制御チャネルでeNodeBからリソースブロック割り当てメッセージを受信し、前記リソースブロック割り当てメッセージが小さいリソースブロック割り当てメッセージであることを判断するように構成された受信モジュールであり、前記小さいリソースブロック割り当てメッセージは、リソースブロック割り当てフィールドを含み、前記リソースブロック割り当てフィールドは、UEに割り当てられた物理下りリンク共有チャネルの最大数までの割り当てられた物理リソースブロックを指定し、前記リソースブロック割り当てフィールドは、複数の物理リソースブロックグループの中の物理リソースブロックグループの1から最大数の割り当てられた物理リソースブロックの複数の全ての可能な物理リソースブロック割り当てへのインデックスであり、前記最大数の割り当てられた物理リソースブロックは、0より大きく物理リソースブロックの総数より小さい整数である受信モジュールを有し、
前記受信モジュールは、前記リソースブロック割り当てフィールドに基づいてユーザ装置に割り当てられた前記物理下りリンク制御チャネルの１つ以上の物理リソースブロックを決定し、前記１つ以上の物理リソースブロックで前記eNodeBにより送信されたデータを復号化するように構成されるユーザ装置。
【請求項１５】
前記ユーザ装置に割り当てられた物理リソースブロックで送信されるデータは、VoIP（voice-over-internet-protocol）パケットを有する、請求項１４に記載のユーザ装置。
【請求項１６】
前記受信モジュールは、ユーザ装置特有の参照信号及びチャネル状態情報参照信号を受信するように構成される、請求項１４に記載のユーザ装置。
【請求項１７】
前記リソースブロック割り当てフィールドは、前記物理下りリンク制御チャネルのアドレスを参照して前記ユーザ装置に割り当てられた前記最大数までの割り当てられた物理リソースブロックを指定する、請求項１４に記載のユーザ装置。
【請求項１８】
前記リソースブロック割り当てフィールドは、ePDCCH（enhanced  physical  downlink  control  channel）のアドレスを参照して前記ユーザ装置に割り当てられた前記最大数までの割り当てられた物理リソースブロックを指定する、請求項１７に記載のユーザ装置。
【請求項１９】
下りリンク制御情報メッセージは、せいぜい1ビットのHARQ（hybrid  automatic  repeat  request）プロセスインジケーションフィールドを有する、請求項１４に記載のユーザ装置。
【請求項２０】
下りリンク制御情報メッセージは、スクランブルインジケーション、アンテナポート及びレイヤ数のうち１つの情報を含まない、請求項１４に記載のユーザ装置。
【請求項２１】
下りリンク制御情報メッセージは、変調及び符号化方式、新規データインジケータ及び冗長バージョンのうち１つの情報を含まない、請求項１４に記載のユーザ装置。
【請求項２２】
機械により実行された場合、前記機械に対して、
ユーザ装置のための下りリンク制御情報メッセージを生成する動作であり、前記下りリンク制御情報メッセージは、1から最大数の割り当てられた物理リソースブロックの複数の全ての可能な物理リソースブロック割り当てへのインデックスを指定することにより、前記ユーザ装置にスケジューリングされた最大数までの割り当てられた物理リソースブロックを示すリソースブロック割り当てフィールドを有し、前記リソースブロック割り当てフィールドは、複数の物理リソースブロックグループの中の物理リソースブロックグループの1から前記最大数の割り当てられた物理リソースブロックの割り当てのための全ての可能な物理リソースブロック割り当てを指定するために必要なビット数をせいぜい有し、前記最大数の割り当てられた物理リソースブロックは、0より大きく物理リソースブロックの総数より小さい整数である動作と、
直交周波数分割多重を使用して物理下りリンク制御チャネルで前記下りリンク制御情報を送信する動作と
を実行させる命令を格納した機械読み取り可能媒体。
【請求項２３】
前記命令は、前記機械により実行された場合、前記機械に対して、前記ユーザ装置に割り当てられた物理リソースブロックで前記ユーザ装置にVoIP（voice-over-internet-protocol）パケットを送信することを有する動作を実行させる、請求項２２に記載の機械読み取り可能媒体。
【請求項２４】
前記リソースブロック割り当てフィールドは、前記物理下りリンク制御チャネルのアドレスを参照して前記ユーザ装置に割り当てられた前記最大数までの割り当てられた物理リソースブロックを指定する、請求項２２に記載の機械読み取り可能媒体。
【請求項２５】
前記リソースブロック割り当てフィールドは、ePDCCH（enhanced  physical  downlink  control  channel）のアドレスを参照して前記ユーザ装置に割り当てられた前記最大数までの割り当てられた物理リソースブロックを指定し、前記ePDCCHは、共通のリソースブロックグループにおいて第１の物理リソースブロックから送信される、請求項２２に記載の機械読み取り可能媒体。
【請求項２６】
前記最大数の割り当てられた物理リソースブロックは、前記ユーザ装置に送信されるRRCメッセージの一部としてシグナリングされる、請求項２２に記載の機械読み取り可能媒体。
【請求項２７】
前記下りリンク制御情報メッセージは、スクランブルインジケーション、アンテナポート又はレイヤ数のうち１つの情報を含まない、請求項２２に記載の機械読み取り可能媒体。
【請求項２８】
前記下りリンク制御情報メッセージは、変調及び符号化方式インジケーション、新規データインジケーション及び冗長バージョンインジケーションのうち１つの情報を含まない、請求項２２に記載の機械読み取り可能媒体。
【請求項２９】
ユーザ装置のための下りリンク制御情報メッセージを生成するように構成されたスケジューラモジュールであり、前記下りリンク制御情報メッセージは、全て同じリソースブロックグループに割り当てられる1から最大数のスケジューリングされた物理リソースブロックの複数の全ての可能な物理リソースブロック割り当てへのインデックスを指定することにより、最大数までのスケジューリングされた物理リソースブロックを前記ユーザ装置に割り当て、前記最大数のスケジューリングされた物理リソースブロックは、リソースブロックの総数より小さいスケジューラモジュールと、
決定された制御チャネルエレメントでスケジューリングメッセージを送信するように構成されたトランシーバと
を有し、
eNodeBと前記ユーザ装置との間の通信モードは、送信モード9であるeNodeB。
【請求項３０】
ユーザ装置のための下りリンク制御情報メッセージを生成するように構成されたスケジューラモジュールであり、前記下りリンク制御情報メッセージは、全て同じリソースブロックグループに割り当てられる1から最大数のスケジューリングされた物理リソースブロックの複数の全ての可能な物理リソースブロック割り当てへのインデックスを指定することにより、最大数までのスケジューリングされた物理リソースブロックを前記ユーザ装置に割り当て、前記最大数のスケジューリングされた物理リソースブロックは、リソースブロックの総数より小さいスケジューラモジュールと、
決定された制御チャネルエレメントでスケジューリングメッセージを送信するように構成されたトランシーバと
を有し、
前記最大数のスケジューリングされた物理リソースブロックは、前記最大数までのスケジューリングされた物理リソースブロックで送信されるパケットを復号化するために必要な最小の信号対干渉及び雑音比に基づいて決定されるeNodeB。
【発明の詳細な説明】
【背景技術】
【０００１】
この出願は、2012年6月21日出願された米国特許出願第13/529,895号の優先権を主張する。米国特許出願第13/529,895号は、2012年4月27日に出願された米国仮特許出願61/639,795号及び2012年1月23日に出願された米国仮特許出願第61/589,774号の優先権を主張する。これらの全ての内容を援用する。
【０００２】
この特許文献の開示の一部は、著作権保護の対象となる資料を含む。著作権所有者は、米国特許商標長における特許のファイル又は記録に表れる特許文献又は特許の開示のだれかによるファクシミリ複製に対して異議はないが、全ての如何なる著作権をも確保する。注釈：Copyright  Intel,  Inc.,  All  Rights  Reservedは、以下に説明するソフトウェア及びデータと、この文献の一部を形成する図面とに適用する。
【０００３】
3GPP（Third  Generation  Partnership  Project）により公表されたLTE（Long  Term  Evolution）ファミリーの無線標準に基づく第４世代無線技術は、主としてデータサービスのために設計されている。データサービスは無線技術のユーザにとって重要度が増えている一方で、音声サービスも依然として重要である。しかし、LTE及び他の第４世代無線技術は、主に高速データ送信に適応されているため、音声の送信は多くの課題を提示する。
【図面の簡単な説明】
【０００４】
【図１】この開示の或る例によるタイプ1のリソース割り当ての概略図
【０００５】
【図２】この開示の或る例に従ってコンパクトなスケジューリングメッセージを構築する方法のフローチャート
【０００６】
【図３】この開示の或る例に従ってコンパクトなスケジューリングメッセージを処理するユーザ装置（UE：user  equipment）のフローチャート
【０００７】
【図４】この開示の或る例による例示的なLTE（long  term  evolution）システム
【０００８】
【図５】この開示の或る例によるeNodeB及びUEのブロック図
【０００９】
【図６】この開示の或る例による機械の図
【００１０】
【図７】この開示の或る例に従ってe-PDCCH（enhanced  physical  downlink  control  channel）及びPDSCH（physical  downlink  shared  channel）を多重する例
【発明を実施するための形態】
【００１１】
必ずしも縮尺通りに描かれていない図面において、同様の番号は、異なる図面において同様の構成要素を示すことがある。異なる添え字を有する同様の番号は、同様の構成要素の異なるインスタンスを表すことがある。図面は、概して、限定ではなく一例としてこの文献で説明される様々な実施例を示す。
【００１２】
データにとってLTEシステムを最適化するために、3GPPは、音声データを送信する専用の音声チャネルなしにLTEを設計した。むしろ、無線インタフェース（air  interface）は、１つの大きい共有リソースである。下りリンクデータチャネルは、物理下りリンク共有チャネル（PDSCH：Physical  Downlink  Shared  Channel）であり、上りリンクデータチャネルは、物理上りリンク共有チャネル（PUSCH：Physical  Uplink  Shared  Channel）である。これらのリソースは全てのモバイルデバイス（例えば、ユーザ装置又は“UE”）の間で共有されるため、UEは、下りリンク（UEの方向）又は上りリンク（基地局又は“eNodeB”の方向）に送信するデータが存在する毎に、チャネルの特定のリソースでスケジューリングされなければならない。PDSCHの場合、eNodeBからの送信をスケジューリングする役目のeNodeBのエンティティ（一般的に“スケジューラ”と呼ばれる）は、どの物理リソース（例えば、特定のリソースブロックグループ“RBG”の中のどの物理リソースブロック“PRB”）がその特定のUEのためのものであるかを示すスケジューリングメッセージをUEに送信しなければならない。上りリンクでは、UEは、スケジューリングリクエスト又はバッファステータスレポートをeNodeBに送信しなければならず、次に、eNodeBは、PUSCHのリソースを許可するスケジューリング許可メッセージをUEに送信してもよい。典型的には、スケジューリングメッセージは、典型的にはリソースブロックの全体周波数を通じてリソースブロックの最初の数個の直交周波数分割変調（OFDM：Orthogonal  Frequency  Division  Modulation）シンボルに位置する物理下りリンク制御チャネル（PDCCH：Physical  Downlink  Control  Channel）でブロードキャストされる。
【００１３】
比較的規則的に送信されるVoIP（voice  over  IP）のような固定の小さいサイズのパケットを利用するサービスの場合、この機構は、送信及び／又は受信される各パケットをサポートするために制御シグナリングが存在する必要がるため、非効率なスペクトル利用をもたらす。従って、制御オーバヘッドは、これらのパケットのサイズに比べて相当なものになる。これは、無線スペクトルの非効率な利用をもたらす。これは、多くの無線キャリアがLTEネットワークで音声サービスを提供することを試みるときに問題になる。
【００１４】
最近、LTE無線インタフェースは、VoIP及び他のサービスのために或る程度システムを最適化する複数の主な機能が追加されている。例えば、半永続的（semi-persistent）なスケジューリングは、UEが特定の期間にPDSCH又はPUSCHの特定のリソースを予め割り当てられ得るため、必要なメッセージングを削減する。更に、LTE-A（LTE-Advanced）のリリース10及び11は、e-PDCCH（enhanced  PDCCH）と共に8個までの下りリンク空間ストリームで閉ループのシングルユーザMIMOをサポートするために、送信モード9（UE特有の参照信号及びチャネル状態情報参照信号（CSI-RS：Channel  State  Information  Reference  Signal）に依存する）を導入した。これらの機能は、データスループットを改善する。e-PDCCHは、LTE-Aのリリース11で導入された。従来のPDCCHとの１つの主な違いは、従来のPDCCHはPRBにおいてPDSCHと時間多重されるが、e-PDCCHは、柔軟且つ効率的なスケジューリングを可能にするため、PDSCHと周波数多重されてもよい点にある。
【００１５】
これらの基本の変更は、LTEの共有チャネルを使用してVoIPのようなサービスをより良く可能にする。これにも拘わらず、無線インタフェースは、PDCCHの無駄なシグナリング帯域幅を回避するために、VoIPパケットの特性を利用することにより、依然として更に改善される可能性がある。すなわち、VoIPのようなサービスにより送信されるパケットの特性は、制御シグナリングを改善するために活用されてもよい。
【００１６】
いくつかの例で開示されるものは、比較的固定のサイズの小さいパケットのために規定された改善された割り当てのシグナリングである。或る例では、これは、PDSCHでUEをスケジューリングするためにPDCCHで送信される小さいスケジューリング割り当てメッセージでもよい。或る例では、これは、UEが割り当てられた物理リソース及び他のパラメータを示すために使用されるスケジューリング割り当ての情報（例えば、下りリンク制御情報フィールド“DCI”）をコンパクトにすることにより行われてもよい。例えば、或る例では、DCIのリソース割り当て“RA”フィールドのリソースブロック割り当てフィールド（例えば、UEに割り当てられたPRB及び／又はRBGを指定するために使用されるフィールド）は、17ビットから2〜3ビットにかなり短縮されてもよい（実装及びネットワーク構成に依存する）。他の例では、RAフィールドを短縮する例に加えて又はその例とは別に、小さいスケジューリング割り当てメッセージにおいて他のフィールドがかなり短縮又は除去されてもよい。
【００１７】
ここに説明する例では、UERS及びCSI-RSに基づく送信モード9を使用した10Mhzのシステムを仮定するが、この出願の開示の利益を有する当業者は、この対策が他の送信モード及び他の帯域幅を利用したシステムで使用されてもよいことを認識する。
＜リソースブロック割り当て＞
【００１８】
LTEでは、特定のUE宛の下りリンクリソースは、DCIフィールドを含むスケジューリング割り当てメッセージでUEにシグナリングされる。DCIフィールドは、PDSCHにおいてモバイルに割り当てられる下りリンクリソースの下りリンクチャネル情報の特定の特性を指定する。例えば、DCIフィールドは、UEがPDSCHで割り当てられた正確なPRB又はRBGを指定するリソースブロック割り当てフィールド及びヘッダを含むリソース割り当てフィールドを含む。DCIメッセージのフォーマットは、使用される送信モードに応じて変化してもよい。送信モード9では、DCIフォーマットはDCI  2Cである。
【００１９】
10MHZの帯域幅を有してDCI  2Cを使用するシステムでは、リソース割り当ては、17ビットのリソースブロック割り当てビットマップと1ビットのリソース割り当てヘッダとを有する18ビットのフィールドを必要とする。リソース割り当てヘッダは、異なるリソース割り当てタイプの間を切り替え、DCI  2Cの場合には２つのRAタイプ（RAタイプ0及びRAタイプ1）が規定されている。17ビットのビットマップの解釈は、どのRAタイプが選択されたかに応じて異なる。
【００２０】
RAタイプ0では、リソースブロック割り当ての17ビットは、２つ以上の連続するPRBを有するリソースブロックグループにPRBをグループ化することに基づいて、物理リソースブロック（PRB：physical  resource  block）をUEに割り当てるために使用されるビットマップを有する。ビットマップは、RBGのうちどれがモバイルに割り当てられるかを指定する。従って、各RBGが３つの連続するPRBで構成される（２つの連続するPRBで構成される最後のRBGを除く）50個のリソースブロックが存在する例では、ビットマップの17ビットのそれぞれは、特定のRBGの割り当てを示す。この手法の細かさは、RBGのサイズ（すなわち、３つの連続するリソースブロック）に制限される点に留意すべきである。VoIPのような固定の小さいパケットサイズを有するサービスでは、スペクトル効率は、単にVoIPパケットに割り当てられたPRBの数により決定される。各VoIPパケットは、328個のペイロードビットと24個のCRCビットを有し、合計で352ビットを有する。１つのPRBがユーザにささげられた12個のリソースエレメントのみを有することを仮定すると、VoIPパケットを送信するために使用することができる合計で156個のリソースエレメントを有する（この理由は1つのPRBの対が2つのスロットを有し、各スロットが7/6のOFDMシンボルを有するため、7*2*12-12=156であるからである）。従って、RAタイプ0を使用したVoIPパケットのスペクトル効率は、352/(156*3)=0.75b/s/Hzである。理想的なシャノンの効率に比べて2dBの実装ロスを仮定し、受信ダイバーシチにおいて2dBを得るために1×2のSIMO（Single  Input  Multiple  Output）送信を仮定すると、これは、-2.7dBのジオメトリの信号対雑音及び干渉比（geometry  SINR：geometry   Signal  to  Noise  and  Interference  Ratio）を必要とする。これは、１つの全体のVoIPパケットを送信するために１つのRBGを使用することで、ほとんどの場合に十分であることを意味する。しかし、高ジオメトリのUE（すなわち、低いチャネル干渉を検出するUE）のためにVoIPパケットのスペクトル効率を改善するために、リソース割り当ては、少なくとも10MHzのシステムではRAタイプ0より細かい必要がある。
【００２１】
RAタイプ1は、RGBより小さい帯域幅（例えば、１つのPRB）を割り当てることができる。図１は、RAタイプ2の割り当ての例を示している。図１において、50個のPRBは3個のPRBのRBGに分割され、合計で17個のRBGに分割される（最後のRBG（RGB16）は2個のPRBを有する）。17個のRBGのそれぞれは、3個のRBGサブセットにグループ化される（図１の陰影付けに基づいて示されている）。各RGBサブセットは２つおきのRBGで構成される。リソースブロック割り当ての2ビットのRBGサブセットのフィールドは、割り当てがどのサブセットに対応するかを選択する。ビットマップは14ビットになり、RBG内のPRBのどれがモバイルに割り当てられるかを表す。例えば、RBG1内の２番目のPRBとRBG7の最初のPRB（図１でハイライトされている）を割り当てるために、ビットマップは、２番目のRBGサブセット（クロスハッチで陰影付けされている）を選択するためにRBGサブセットで“01”になり、適切なPRBを選択するために
“010  000  100  000  000  00”になる。リソースブロック割り当てフィールドの他のビットは、ビットマップを解釈するときにオフセット（シフト）を適用するか否かを示す。RAタイプ0で行われた同じ計算を使用して、1×2のSIMO送信で１つのPRB又は２つのPRBを使用してVoIPパケットを送信するための対応するジオメトリは、それぞれほぼ5dB及び0dBになる。
【００２２】
従って、10MHzのLTEは、１つのVoIPパケットのリソースを割り当てるために、18ビットのリソース割り当てオーバヘッドを利用することが分かる。
【００２３】
小さい固定サイズのパケットを有するサービス（例えば、VoIP）では、RAフィールドのサイズを低減し、従って、スペクトル効率を増加させることができる。この理由は、現在のRAタイプ0及び1は、異なる種類のアプリケーションのために柔軟になるように設計されているからである。従って、RAタイプ0及び1は、複数のRBGに渡って拡散された多くの（潜在的に）不連続なPRBの割り当てを許容するように調整されている。メッセージ毎に割り当てられるPRBの数を１つのPRBとN個のPRBとの間に制限した場合（Nは、依然としてパケットを復号化するために必要な最小のSINRを実現しつつ、１つのパケットが適合し得るPRBの最大数として定義されてもよい）、リソースブロック割り当てフィールドはこれらの制限されたPRBの組み合わせへのインデックスになり得るため、シグナリングオーバヘッドの量をかなり低減することができる。VoIPサービスの場合、Nは3又は4でもよい（Nは他のサービスで異なってもよい）。例えば、割り当てフィールドは、割り当てられた特定のリソースブロックを示し得るテーブルへのインデックスでもよい。これは、他のRAタイプと区別できる。この理由は、eNodeBは、実際の位置を送信する必要はなく、位置にマッピングするコードを送信してもよいため、リソースを節約できるからである。
【００２４】
一例では、メッセージ毎に割り当てられるPRBの数を１つのPRBと３つのPRBとの間に制限することができ、２つ又は３つのPRBの割り当てを同じRBG内になるように更に制限する場合（小さいパケットにより生じるリソース分割を回避するため）、リソースブロック割り当てフィールドにおけるビット数をかなり低減することができる。実際に、7ビットのサイズのフィールドが必要な全てのものになる。この理由は、単一のPRBが割り当てられ得る場合に合計で50個の可能性が存在し、２つのPRBが割り当てられ得る場合に合計で49個の可能な組み合わせが存在し、３つのPRBが割り当てられる場合に合計で16個の可能な組み合わせが存在し（全てが同じRBGに存在しなければならないことを前提とする）、合計で115個の可能性が存在するからである（115個の異なる組み合わせを表すために7ビットを必要とする）。
【００２５】
従って、例えば、eNodeBがPRB43を割り当てる場合、リソース割り当ては、0101011（43のバイナリ形式）になってもよい。この例では、１つのPRBを割り当てるための最後のビットパターンは、0110001でもよい。同様に、１つのRBG内での２つのPRBの割り当てでは、合計で49個の可能な割り当ての組み合わせのみが存在し（２つのPRBのみを有する最後のRBGについての１つの組み合わせを除くRBG毎に３つの組み合わせ）、これらの49個の可能な割り当ては、0110010〜1100010のビット列に符号化されてもよい。例えば、eNodeBがRGB0内のPRB0及び2を割り当てる場合、リソース割り当てパターンは、0110100（10進数で52）でもよい。従って、リソース割り当てパターンが49と98との間にある場合、UEは、２つのPRBを割り当てられたと判断してもよい。リソース割り当てパターンに基づいて、UEは、49を引き、その数をRBG内の２つのPRBの可能な配置の数（この場合には、合計で３つの可能な配置：(0,2)、(0,1)、(1,2)が存在するため、3である）で割り、１を引く（ゼロからインデックス付けしているため）ことにより、２つのPRBを割り当てられたと検出した場合に、RBGを決定してもよい。従って、例えば、10進数で55である0110111の割り当ての場合、49を引くと6になり、RBG毎に３つの可能性で割り、１を引くことで、1のRGBを得る。RBG内のPRBは、49を引いて可能な組み合わせの数（この例では3）で割った後の残りの数から決定可能である。UEは、可能な組み合わせ及び対応する数を示すテーブルを調べてもよい。３つのPRB（全てが１つのRBG内にある）の割り当ての場合、合計で16個のみの可能な組み合わせが存在し、16個の可能な組み合わせは、1100011〜1110010のビット列に符号化されてもよい。従って、リソース割り当てパターンが99と114との間にある場合、UEは、３つのPRBを割り当てられたと判断してもよい。割り当てられたRBGは、リソース割り当てパターンから99を引くことにより決定される。RBG内の全てのPRBはモバイルに割り当てられるため、モバイルに割り当てられたPRB内でRBGを計算する必要はない。
【００２６】
或る例では、NをRBG内のPRBの数より小さくなるように制限するが、NはRBG内のPRBの数より大きくてもよい（例えば、RBG内に３つのPRBが存在する10mhzのシステムで4になってもよい）。
【００２７】
リソースブロック割り当てフィールドの値からPRBの位置を計算するための式がUEにより使用されてもよいが、他の例では、UE及び／又はeNodeBは、単に参照テーブルを使用してもよい。この開示の利益を有する当業者は、リソースブロックの割り当てで送信されたインデックスと割り当てられたPRBとの間で異なるマッピングが使用されてもよいことを認識する。
【００２８】
従って、合計では１つのRBG内の1PRB/2PRB/3PRBの割り当てについて115個の可能性を有し、これは7ビットのシグナリングを必要とする。他のシステム帯域幅について一般化すると、必要なビット数は、最も近い整数ビットに切り上げられたln(x)/ln(2)であると言うことができ、xは1からN個のPRBでの割り当てサイズ毎に可能な割り当ての数の合計である。従って、N=3では、x=（割り当てサイズ1の場合の50+割り当てサイズ2の場合の49+割り当てサイズ3の場合の16）=115であるため、必要なビット数は7である。
【００２９】
Nは、予め決められてもよく（例えば、仕様で規定される、又はUE若しくはeNodeBにシグナリングされる）、サービス（例えば、VoIP）及び／又はネットワーク特性（例えば、RBGサイズ）に基づいて選択されてもよい。例えば、Nは、サービス（例えば、VoIP）の１つのパケットが適合し、パケットが適切に復号化されることを可能にする最小のSINRを許容するPRBの最大数により決定されてもよい。或る例では、Nは全体システム帯域幅より小さくてもよい（例えば、Nは、システムのPRBの数より小さい）。
【００３０】
この割り当て方式は同じPRBの外のPRBの割り当てをサポートすることはできないが、リソースをスケジューリングするために使用されるビット数を依然として低減しつつ、不連続な割り当てを実現するための複数の選択肢が存在する。例えば、RBGの外の１つ又は２つの更なるPRBの割り当てのシグナリングを可能にするために、更なるビット（元の18より依然として小さい）が導入されてもよい。他の例では、特に設計された分散型のPRBが複数のPRBにマッピングされてもよい。これは、周波数ダイバーシチ（特定の周波数範囲に制限され得る干渉の影響又は他の理想未満のチャネル状況を制限するための、広い範囲の利用可能な周波数を通じた特定のPRBのマッピング）を可能にするために望ましいことがある。
【００３１】
RAシグナリングのオーバヘッドは、他の例では、2又は3ビットに更に低減され得る。これらの例では、リソース割り当て情報の一部を伝えるために、PDCCHのアドレスが使用されてもよい。例えば、リソース割り当て情報の一部を伝えるために、PDCCHのアドレスとPDSCHリソースが割り当てられたRBGのインデックスとの間に１対１のマッピングが使用されてもよい。従って、例えば、割り当てのRBGは、PDCCHアドレスにオフセットを加えることにより決定されてもよい。使用するオフセットは予め決められてもよく（例えば、3GPP仕様で規定される）、UE又はeNodeBによりシグナリングされてもよい（例えば、eNodeBによりブロードキャストされるシステム情報メッセージの一部として、又は無線リソース制御“RRC”接続手順の一部等としてシグナリングされてもよい）。PDCCHアドレスは、以下に説明するいずれかの数の様々な方法に基づいて決定されてもよい。
【００３２】
１対１のマッピングが決定された場合、リソースブロック割り当てフィールドは、RBG（RBGはPDCCHからのオフセットに基づいて決定される）内のどのPRBを割り当てられたかをUEに伝えさえすればよい。表１は、１つのRBGが３つのPRBを含む場合の様々なPRB割り当てを示すために3ビットを使用する例を示している。他のシステム帯域幅に一般化すると、RAフィールド内のビット数は、RBG内のPRBの数でもよい。
【表１】
0006045606.tif 000002
【００３３】
更に他の例では、１つのUEのePDCCHがRBG  g内の特定のPRB  nから送信され、そのRBG  gの残りのPRBは常に同じUEのPDSCHに割り当てられることをUEが仮定することができる場合、UEに割り当てられたPRBをシグナリングするために2ビットのみが必要になる。表２は、ePDCCHをも含むRBGの残りのPRBのPRB割り当てを示すために2ビットを使用する例を与える。ePDCCHは全体のPRBを占有しないため、ePDCCHがスケジューリングされたPRBは、以下に説明するようにPDSCH及びePDCCHを送信するために使用されてもよい点に留意すべきである。他のシステム帯域幅に一般化すると、PRBを割り当てるために必要なビット数は、RBG内のPRBの数から１を引いたものでもよい。
【表２】
0006045606.tif 000003
【００３４】
ePDCCHを使用した表２の手法は、表１の3ビットの手法を使用するよりもいくつかの利点を有する。特に、UEはそのePDCCH及びPDSCHを同じPRBに有するため、UEは、ePDCCHを復号化するときに、常に１つのPRB内の全てのユーザ装置参照信号“UERS（User  Equipment  Reference  Signal）”を使用することができる。
＜PDCCHアドレスの決定＞
【００３５】
前述のように、リソース割り当てを決定するためのオフセットとしてPDCCHアドレスを使用するために、PDCCHアドレスを決定する複数の異なる選択肢が存在する。第１の例では、いずれか所与のサブフレームにおいて、集約レベル（aggregation  level）１のPDCCH候補インデックスは、0〜5まで普遍的にインデックス付けされてもよく、集約レベル2は、6〜11までインデックス付けされてもよく、同様に、集約レベル4の候補は、12及び13としてインデックス付けされてもよく、集約レベル8は14及び15としてインデックス付けされてもよい。
【００３６】
他の例の選択肢では、開始制御チャネルエレメント（CCE：control  channel  element）インデックスは、PDCCHアドレスとして使用されてもよい。このインデックスは、PDSCHのACK/NACKビットを送信するためのPUCCH（Physical  Uplink  Control  Channel）リソースインデックスを符号化するために既に使用されている。
【００３７】
更に他の例の選択肢では、前述のように、ePDCCH及びその示されたPDSCHが同じRBGを共有してもよい。従って、RBGインデックスはDCIに必要なくてもよい。従って、ローカライズのePDCCH（localized  ePDCCH）では、UEの制御及びデータチャネル（すなわち、ePDCCH及びPDSCH）が同じRBGにあることが規定されている場合、制御チャネル（ePDCCH）においてRBGインデックスを指定する必要はない。この理由は、UEは、データチャネル（PDSCH）を見つけるために、単にePDCCHが位置するRBGを使用するからである。分散型のePDCCH（distributed  ePDCCH）では、ePDCCHの一部がPDSCHのRBGインデックスとして送信される場合のRBGインデックスを使用することができる。しかし、１つの分散型のePDCCHが複数のRBGで送信され得るため、リソース割り当てフィールドは、依然として2〜3ビットまで低減され得る。しかし、分散型のePDCCHとPDSCH割り当てのRBGとの間のマッピングを指定するために、何らかのシグナリングが必要になってもよい。
【００３８】
例えば、5MHzのシステムを使用する場合、分散型のePDCCHを送信するために、4個のPRBを構成することができる。合計で、16個の分散型のeCCE（Enhanced  Control  Channel  Element）を有することができる。25個のPRBを7個のVoIPのRBGとしてグループ化してもよく、各VoIPは4個のPRBを含んでもよく、2個のPRBに等しくてもよい。小さいDCIを送信するために常に１つのeCCEを使用する場合、eCCEとVoIPのRBGとの間に１対１のマッピングを設定することができる。この場合、eCCE0〜6は、VoIPのRBG0〜6をスケジューリングするために使用される。従って、UEは、eCCE0〜6において小さいDCIを復号化しさえすればよい。eCCE7〜15は、DCI  2Cのような大きい送信モードに依存するDCIが使用されるときに、SPSアクティブ又はリリースを送信するために使用されてもよい。例えば、eCCE7〜15は、集約2Cを使用してDCI  2Cを送信するために使用されてもよい。従って、UEの検索空間は、これらの残りのeCCEから構成された大きい集約レベルの候補を含む必要がある。他の例では、eCCE7〜15はまた、（eCCE0〜6について設定されたものと同様の１対１のマッピングを用いて）小さいDCIを送信するために使用されてもよい。小さいDCIについても同様にeCCE7〜15を利用することは、複数の再送信が１つのVoIPのRBGでスケジューリングされることを可能にし得る。
＜HARQプロセスIDの低減＞
【００３９】
他の制御シグナリングのオーバヘッドの節約は、DCIフィールドで指定されたHARQ（Hybrid  Automatic  Repeat  Request）プロセスIDを3ビットから1ビットに低減することにより実現され得る。この理由は、無線インタフェースの遅延予算が50msであるが、VoIPパケットの周期が20msであるためである。20ms後にVoIPパケットは破棄される。従って、せいぜい２つの未解決のVoIPパケットが許容され、従って、せいぜい２つのHARQプロセスが必要となる。せいぜい２つのHARQプロセスが必要となるため、特定のHARQプロセスを識別するために１ビットのみが必要になる。
＜アンテナポート、SCID、レイヤ数インジケーション＞
【００４０】
アンテナポート、スクランブルインジケーション“SCID（scrambling  identification）”及びレイヤ数インジケーションのフィールドをスケジューリングメッセージのDCIフィールドから除去することにより、更なるシグナリングの節約が実現され得る。SPS初期送信と小さいDCIのスケジューリングされた再送信との間の複合ランク（composite  rank）2のMU-MIMO（Multi-User  MIMO）を可能にするために、eNodeBは常にUERSポート7で初期の送信を行い、常にUERSポート8でPDSCHの再送信をスケジューリングしてもよいため、これらのフィールドは除去されてもよい。
＜トランスポートブロック1のMCS、NDI及びRVの低減＞
【００４１】
低減したサイズのDCIのために、変調及び符号化方式フィールド（MCS）は、割り当てられたPRBの数により暗示的に指定されてもよい。例えば、トランスポートブロックサイズは小さいパケットでは固定されているため（例えば、VoIPパケットでは40バイトであると仮定することができる）、また、割り当てられたリソースブロックの数は知られているため、MCSは、更なるシグナリングなしにUEにより計算されてもよい。従って、MCSフィールドは必要ない。更に、初期送信は常にSPSの割り当てを使用しているため、新規データインジケータ（NDI：new  data  indicator）は必要ない。更に、これらの送信にChase合成のみが使用される場合、冗長バージョン（RV：redundancy  version）ビットは利用されなくてもよい。合計で、冗長なフィールドを除去することにより、8ビットを節約することができる。
【００４２】
例えば、ランク1の送信では、送信フォーマットは以下のようになる。
【００４３】
1.  1PRB/64QAM
【００４４】
2.  2PRB/16QAM
【００４５】
3.  3PRB/QPSK
【００４６】
ランク2の送信が利用される場合、以下の送信フォーマットが使用される。
【００４７】
1.  1PRB/16QAM
【００４８】
2.  2PRB/QPSK
【００４９】
トランスポートブロックサイズは、328ビットになるように固定されてもよい。
＜トランスポートブロック2のMCS、NDI及びRVの低減＞
【００５０】
低減したDCIのために、第２のトランスポートブロックが存在しないことを仮定してもよい。ランク2の送信がVoIP送信について許容される場合であっても、唯一のトランスポートブロックが使用される。
＜小さいDCIの要約＞
【００５１】
合計で、下りリンク割り当てメッセージにおける標準のDCIフィールドと小さいDCIフィールドとの比較が表３に示される。
【表３】
0006045606.tif 000004
【００５２】
要約すると、１つのePDCCHが１つのPRBで集約レベル1を使用して送信され、１つのPRBが4個のeCCEを含む場合、１つのeCCEは、約36個のリソースエレメント“RE（resource  element）”を含む。この小さいDCIの動作SINRは約-4dBになる。従って、１つのe-CCEであっても、ePDCCHは依然として十分に信頼性がある。ほとんどの場合、ePDCCHにVoIPパケットを加えたものは、小さいDCIを使用してPRBにうまく適合し得る。従って、VoIPのキャパシティ（capacity）がかなり増加し得る。
【００５３】
他の例では、CRCビットの数を減少させ、更に制御シグナリングを短縮することが可能になり得る。例えば、短縮したC-RNTIを用いたマスキングを使用すること、又は小さいDCIにシーケンス変調（sequence  modulation）を適用することによるものである。これらの例では、各UEは、単に数個の候補のシーケンスからシーケンスを復調する。
【００５４】
更に、小さいDCIは限られた数のPRBをスケジューリングすることしかできないため、eNodeBは、同じサブフレームにおいて同じUEの複数の小さいDCIを送信してもよい。例えば、eNodeBは、同じUEについて同じサブフレームにおいてRBG0でHARQID=0を送信し、RBG3でHARQID=1を送信してもよい。他の例では、VoIPのキャパシティを増加させ、欠落したVoIPフレームの迅速な再送信を支援するため、同じHARQIDは、同じサブフレームにおいて複数回送信されてもよい。
【００５５】
図２は、小さいスケジューリングメッセージを構築するためのこの開示の或る例による方法を記載している。動作2010において、eNodeBは、特定のUEに割り当てられる下りリンク共有チャネルリソースを決定する。前述のように、或る例では、これらのリソースは、同じUEに割り当てられたePDCCHと同じRBGに存在してもよい。動作2020において、eNodeBは、前述のように、小さいスケジューリング割り当てメッセージの小さいDCIフィールドを構築する。動作2030において、eNodeBは、どのCCE又はeCCEで小さいスケジューリングメッセージを送信するかを決定してもよい。動作2040において、eNodeBは、必要に応じて、決定されたCCE又はeCCEでスケジューリングメッセージを送信する。
【００５６】
図３は、小さいスケジューリングメッセージを受信し、その内容を利用するためのこの開示の或る例による方法を記載している。動作3010において、UEは、適切な検索空間及び集約レベル（或る例では現在のフレーム番号及び／又はモバイルアイデンティティに基づいて決定されてもよい）において、PDCCH又はePDCCHでスケジューリングメッセージを受信（リスン）する。動作3020において、スケジューリングメッセージを復号化すると、UEは、小さいスケジューリングメッセージであることを判断する。動作3030において、モバイルは、どの下りリンクリソースがUEに割り当てられたかを決定する（いずれかの小さいRAフィールドに基づく）。動作3040において、UEは、eNodeBによりスケジューリングされて小さい割り当てメッセージの一部としてシグナリングされた下りリンクリソースの１つ以上のパケットを受信してもよい。
＜PDSCHとePDCCHとの多重＞
【００５７】
ePDCCH（enhanced  PDCCH）は、LTE  Rel.11システムで導入された。LTE  Rel.8システムで規定されたPDCCHと比べて、ePDCCHの主な違いは以下の通りである。
【００５８】
1)PDCCHは、OFDMシンボルの細かさでPDSCHと時分割多重（TDM）する。例えば、PDCCHは、常に１つのサブフレームの最初のN個のOFDMシンボルを占有する。ただし、Nは、1、2、3又は4でもよい。これに対して、ePDCCHは、PRBの細かさでPDSCHと周波数分割多重（FDM）する。例えば、ePDCCHは、１つのサブフレームのM個のPRBを占有してもよい。ただし、Mは、0より大きく、全体システム帯域幅より小さい。
【００５９】
2)PDCCHは、コヒーレント復調のために共通参照信号（CRS：common  reference  signal）に依存するが、ePDCCHは、コヒーレント復調のためにUE特有の参照信号（UERS：UE-specific  reference  signal）に依存する。
【００６０】
3)PDCCHは、分散方式で全体の制御領域にマッピングされるが、ePDCCHは、連続するPRBへのローカライズのマッピング又は分散したPRBへの分散型のマッピングをサポートする。
【００６１】
4)PDCCHのセル間直交性は、ランダムなマッピングのため保証できないが、ePDCCHのセル間直交性は保証できる。
【００６２】
ePDCCHが同じPRBにおいて同じUEのPDSCHに多重され得るか否かは、3GPPによりまだ決定されておらず、許可されたとしても、同じPRBにおいてPDSCとePDCCHとを多重する正確な方法はまだ決定されていない。
【００６３】
同じPRBにePDCCH/PDSCHが共存するための複数の用途シナリオが存在する。
【００６４】
第１に、小さいシステム帯域幅のシステムでは、これは帯域幅を節約し、無駄を除去することができる。例えば、システムが6個のPRBのみを有し、2個のPRBがePDCCHを送信するために確保されている場合、eNBは、１つのサブフレームで１つのUEをスケジューリングするためにしばしばTDMスケジューリングを使用する。ePDCCH/PDSCHの多重が１つのPRBにおいて許可されていない場合、ePDCCHを含むPRBの未使用のREは常に無駄になる。システム帯域幅は小さいため、リソースの無駄は大きくなり、例えば、10%より大きくなる可能性がある。
【００６５】
第２に、高い選択性のチャネルでは、多重方式は、データ領域についてロバストなチャネル推定性能を確保するため、これらのチャネルの性能を改善するように設計され得る。これを実現するために、ePDCCH/PDSCHが同じPRBに共存することを許可し、多重パターンを適切に設計すると、同じPRBにおいてこれらのPDSCHのREのための更なるチャネルトレーニング信号として復号化されたePDCCHを使用することができる。その結果、これらの高速フェージング及び周波数選択性チャネル（例えば、高速チャネル）において、これらのPDSCHのREの復号化性能がかなり改善する。
【００６６】
TDM、FDM（Frequency  Division  Multiplexing）及びTDFDM（Time  Division  and  Frequency  Division  Multiplexing）のような複数の選択肢が１つのPRBにおいてPDSCH/ePDCCHを一緒に多重するために使用されてもよい。図７は、更なるチャネルトレーニング信号としてePDCCHを使用することを可能にするために、どのように複数のCCEが１つのPRBにおいてインターリーブされ得るかの一例を示している。図７のインターリーブは、TDFDMの特定の例として考えられてもよい。１つのPRBが１つのCCEを使用して唯一のDCIを送信する場合、PRBの残りのREは、PDSCHがデータトラヒックを送信するために使用される。PDSCHのREがDCIと同じUEについてのものである場合、復号化されたDCIは、これらのPDSCHのREを復調するためのトレーニングパイロットとして使用されてもよい。復号化手順は、UEの実装に関するが、高速のシナリオでは更なる復号化要件を規定することにより、3GPPにおいて標準化されてもよい。
＜無線ネットワークの例＞
【００６７】
図４は、或る例に従ってLTE（Long  Term  Evolution）ファミリーの標準に従って実装された無線ネットワークの概略を示している。１つ以上のモバイルデバイス又はユーザ装置（UE：user  equipment）（例えば、UE4010等）は、１つ以上の無線周波数インタフェースで１つ以上のeNodeB（例えば、eNodeB4020等）と通信する。eNodeBは、UEとeNodeBと他のネットワークとの間でデータ送信を提供するために使用されるレイヤ1（OFDM（Orthogonal  Frequency  Division   Multiplexing）物理レイヤ）、レイヤ2（媒体アクセス制御、無線リンク制御、パケットデータコンバージェンスプロトコル）及びレイヤ3（無線リソース制御（RRC：Radio  Resource  Control））プロトコルをサポートする。これらのプロトコルは、変調／復調、チャネル符号化／復号化、無線リソース制御、無線モビリティ管理及び他の機能を含む機能を提供する。eNodeB4020は、１つ以上のMME（Mobility  Management  Entity）4034、サービングゲートウェイ（SGW：serving  gateway）4036及びパケットデータネットワークゲートウェイ4032で構成されるEPC（Evolved  Packet  Core）4030にS1インタフェースで更に接続されてもよい。EPCはまた、ポリシー設定及び課金のための構成要素と、音声呼を可能にするために利用される構成要素とを含む他の構成要素（図示せず）を有してもよい。MME4034は、加入者及びセッション管理に関する制御プレーン機能を制御する。サービングゲートウェイ4036は、ネットワーク4000内でのモビリティのため、モバイルからのパケットをルーティングするモビリティアンカー（mobility  anchor）として機能する。PDNゲートウェイ4032は、パケットデータネットワークへのパケットデータインタフェースの送信ポイントである。PDNゲートウェイ4032は、インターネットのような１つ以上の公衆ネットワーク4050にアクセスを提供し得るIMS（Internet  Protocol  Multimedia  Subsystem）4040に接続されてもよい。PCRF（Policy  and  Charging  Rules   Function）構成要素4038は、QoS情報及び他のシステムポリシーを管理する。HSS（Home  Subscriber  Server）4060は、ユーザ識別情報及びアドレス、ユーザプロファイル情報、ユーザの認証、暗号化及び整合性の保護並びに他の機能を維持及び管理する。HSS4060は、EPC4030と別のものとして示されているが、他の例ではEPC4030の一部でもよい。ネットワーク4000の様々な構成要素は、機械6000（図６参照）の様々な構成要素又はRFトランシーバ／受信機、増幅器等のような更なる構成要素でもよく、これらの構成要素を含んでもよい。
【００６８】
図５は、eNodeB5010及びユーザ装置5050の例示的な概略図を示している。eNodeBは、（他のモジュールの中でも）PDCCH、PDSCH並びに他の制御及びデータチャネルでの送信をスケジューリングするために使用されるスケジューラモジュール5005を含んでもよい。eNodeBはまた、L2及びL3機能を扱ってもよい制御モジュール5010を含んでもよい。或る例では、スケジューラは、制御モジュール5010に統合されてもよい。eNodeBはまた、EPCからのデータを送信／受信するS1インタフェースモジュール5020を含んでもよい。eNodeBはまた、変調、符号化、送信、受信、復調及び復号化を含むLTE物理レイヤ機能を実装し得るTX/RXモジュールを含んでもよい。データは、UE5050とのRFインタフェース5040で送信されてもよい。UE5050は、変調、符号化、送信、受信、復調及び復号化を含むLTE物理レイヤ機能を実装し得るTX/RXモジュール5070を含んでもよい。UEもまた、LTEプロトコルスタックの他のレイヤ（例えば、レイヤ2及びレイヤ3）を実装し得る制御モジュール5060を有してもよい。例えば、制御モジュール5060は、PDSCH及びPUCCHでのUEをスケジューリングするPDCCHで送信されたスケジューリングメッセージを受信、復号化及び解釈してもよい。この情報に応じて、制御モジュールは、TX/RXモジュールに対してこのUEにスケジューリングされたPRBを受信及び復号化するように命令してもよい。制御モジュール5060はまた、どのDCI（例えば、小さいもの又は通常のもの）が使用されるかを判断してもよい。或る例では、制御モジュール5060は、TX/RXモジュール5070に全体的に又は部分的に統合されてもよい。
【００６９】
図６は、ここで説明した技術（例えば、手法）のいずれか１つ以上が実行され得る例示的な機械6000のブロック図を示している。別の実施例では、機械6000は、スタンドアローンデバイスとして動作してもよく、他の機械に接続（例えば、ネットワーク接続）されてもよい。ネットワーク接続された配置では、機械6000は、サーバマシン、クライアントマシンの能力で又はサーバ・クライアントネットワーク環境で動作してもよい。一例では、機械6000は、ピア・ツー・ピア（P2P：peer-to-peer）（又は他の分散型）ネットワーク環境のピア機械として動作してもよい。機械6000は、パーソナルコンピュータ（PC）、タブレットPC、セットトップボックス（STB）、パーソナルデジタルアシスタント（PDA）、移動電話、ウェブ機器、ネットワークルータ、スイッチ若しくはブリッジ、又はその機械により行われる動作を指定した命令を（順次的に又は他の方法で）実行可能ないずれかの機械でもよい。例えば、eNodeB、UE又はLTEシステムの他の構成要素は、機械6000の構成要素でもよく、機械6000の構成要素を含んでもよい。更に、単一の機械が示されているが、“機械”という用語は、クラウドコンピューティング、SaaS（software  as  a  service）、他のコンピュータクラスタ構成のように、ここで説明した手法のいずれか１つ以上を実行する一式の命令（又は複数のセット）を個々に又は併せて実行する機械のいずれかの集合を含むものと考えられるものとする。例えば、機械6000の機能は、ネットワークの複数の他の機械に分散されてもよい。
【００７０】
ここで説明する例は、ロジック又は複数の構成要素、モジュール若しくは機構を含んでもよく、これらで動作してもよい。モジュールは、指定の動作を実行可能な有形のエンティティであり、特定の方法で構成又は配置されてもよい。一例では、回路は、モジュールとして指定の方法で構成されてもよい（例えば、内部的に又は他の回路のような外部エンティティに関して）。一例では、１つ以上のコンピュータシステム（例えば、スタンドアローン、クライアント又はサーバコンピュータシステム）若しくは１つ以上のハードウェアプロセッサの全体又は一部は、指定の動作を実行するように動作するモジュールとして、ファームウェア又はソフトウェア（例えば、命令、アプリケーション部又はアプリケーション）により構成されてもよい。一例では、ソフトウェアは、(1)過渡的でない機械読み取り可能な媒体又は(2)送信信号に存在してもよい。一例では、ソフトウェアは、モジュールの基礎となるハードウェアにより実行された場合、ハードウェアに対して指定の動作を実行させる。
【００７１】
従って、“モジュール”という用語は、指定の方法で実行するように、又はここに記載のいずれかの動作の一部又は全部を実行するように物理的に構築されたエンティティ、特別に構成（例えば、配線結合）されたエンティティ又は時間的に（例えば、過渡的に）構成（例えば、プログラム）されたエンティティを含むことが分かる。モジュールが時間的に構成される例を考えると、各モジュールは、いずれかの時点においてインスタンス化される必要はない。例えば、モジュールがソフトウェアを使用して構成された汎用ハードウェアプロセッサを有する場合、汎用ハードウェアプロセッサは、時間と共に変化し得る１つ以上のモジュールとして構成されてもよい。従って、ソフトウェアは、例えば、１つの時点で特定のモジュールを構成し、異なる時点で異なるモジュールを構成するように、ハードウェアプロセッサを構成してもよい。
【００７２】
機械（例えば、コンピュータシステム）6000は、ハードウェアプロセッサ6002（例えば、中央処理装置（CPU）、グラフィック処理ユニット（GPU）、ハードウェアプロセッサコア又はこれらのいずれかの組み合わせ）と、メインメモリ6004と、スタティックメモリ6006とを含んでもよく、これらの一部又は全部はバス6008を介して相互に通信してもよい。機械6000は、ディスプレイユニット6010、英数字入力デバイス6012（例えば、キーボード）、ユーザインタフェース（UI）制御デバイス6014及び／又は他の入力デバイスを更に含んでもよい。一例では、ディスプレイユニット6010及びUI制御デバイス6014は、タッチスクリーンディスプレイでもよい。機械6000は、記憶デバイス（例えば、ドライブユニット）6016、信号生成デバイス6018（例えば、スピーカ）及びネットワークインタフェースデバイス6020を更に含んでもよい。
【００７３】
記憶デバイス6016は、ここに記載の技術又は機能のうちいずれか１つ以上により利用される又は具現するデータ構造又は命令6024（例えば、ソフトウェア）の１つ以上のセットを格納した機械読み取り可能媒体6022を含んでもよい。命令6024はまた、機械6000による実行中に、メインメモリ6004、スタティックメモリ6006又はハードウェアプロセッサ6002内に完全に又は少なくとも部分的に存在してもよい。一例では、ハードウェアプロセッサ6002、メインメモリ6004、スタティックメモリ6006又は記憶デバイス6016のうち１つ又はいずれかの組み合わせは、機械読み取り可能媒体を構成してもよい。
【００７４】
機械読み取り可能媒体6022は、単一の媒体として示されているが、“機械読み取り可能媒体”という用語は、１つ以上の命令6024を格納するように構成された単一の媒体又は複数の媒体（例えば、集中型又は分散型データベース及び／又は関連するキャッシュ及びサーバ）を含んでもよい。
【００７５】
“機械読み取り可能媒体”という用語は、機械6000により実行される命令を格納、符号化又は伝達することができ、機械6000に対してこの開示の技術のいずれか１つ以上を実行させるいずれか有形の媒体を含んでもよく、このような命令により使用されるデータ構造又はこのような命令に関連するデータ構造を格納、符号化又は伝達することができるいずれかの有形の媒体を含んでもよい。非限定的な機械読み取り可能媒体の例は、ソリッドステートメモリと、光学及び磁気媒体を含んでもよい。機械読み取り可能媒体の特定の例は、半導体メモリデバイス（例えば、EPROM（Electrically  Programmable  Read-Only  Memory）、EEPROM（Electrically  Erasable  Programmable  Read-Only  Memory））及びフラッシュメモリデバイスのような不揮発性メモリと、内部ハードディスク及び取り外し可能ディスクのような磁気ディスクと、光磁気ディスクと、CD-ROM及びDVD-ROMディスクとを含んでもよい。
【００７６】
命令6024は、ネットワークインタフェースデバイス6020を介して伝送媒体を使用して通信ネットワーク6026で更に送信又は受信されてもよい。ネットワークインタフェースデバイス6020は、複数の転送プロトコル（例えば、フレームリレー、インターネットプロトコル（IP）、伝送制御プロトコル（TCP）、ユーザデータグラムプロトコル（UDP）、ハイパーテキスト転送プロトコル（HTTP）等）のうちいずれか１つを利用することによりネットワークにおいて他の機械と通信するために、機械6000を他の機械のネットワークに接続してもよい。例示的な通信ネットワークは、特に、ローカルエリアネットワーク（LAN）と、広域ネットワーク（WAN）と、パケットデータネットワーク（例えば、インターネット）と、移動電話ネットワーク（例えば、セルラネットワーク）と、一般電話（POTS：Plain  Old  Telephone）ネットワークと、無線データネットワーク（例えば、Wi-Fiとして知られるIEEE（Institute  of  Electrical  and  Electronics  Engineers）802.11ファミリーの標準、WiMaxとして知られるIEEE802.16ファミリーの標準）と、ピア・ツー・ピア（P2）ネットワークとを含んでもよい。一例では、ネットワークインタフェースデバイス6020は、通信ネットワーク6026に接続するために１つ以上の物理ジャック（例えば、Ethernet（登録商標）、同軸又は電話ジャック）又は１つ以上のアンテナを含んでもよい。一例では、図６に示すように、ネットワークインタフェースデバイス6020は、SIMO（single-input  multiple-output）、MIMO（multiple-input  multiple-output）又はMISO（multiple-input  single-output）技術のうち少なくとも１つを使用して無線で通信するために、複数のアンテナを含んでもよい。“伝送媒体”という用語は、機械6000により実行される命令を格納、符号化又は伝達することができるいずれかの無形の媒体を含むものとして考えられ、デジタル若しくはアナログ信号又はこのようなソフトウェアの通信を容易にする他の無形の媒体を含む。
【００７７】
前述の詳細な説明は、詳細な説明の一部を形成する添付図面への参照を含む。図面は、一例として本発明が実施され得る特定の実施例を示している。これらの実施例はまた、ここでは“例”とも呼ばれる。このような例は、図示のもの又は記載のものに加えた要素を含んでもよい。しかし、本発明の発明者はまた、図示又は記載の要素のみが提供される例も考慮する。更に、本発明の発明者はまた、特定の例（又はその１つ以上の態様）に関して、或いはここに図示又は記載の他の例（又はその１つ以上の態様）に関して、図示又は記載の要素（又はその１つ以上の態様）のいずれかの組み合わせ又は置換を使用した例も考慮する。
【００７８】
この文献で参照される全ての刊行物、特許及び特許文献は、個別に援用することにより、その全内容を援用する。この文献とこのように援用した文献との間の不一致の用途の場合には、援用した文献の用途は、この文献の用途の捕捉として考えられるべきである。矛盾する不一致については、この文献の用途が支配する。
【００７９】
この文献において、特許文献において一般的なように、単数が使用される場合、“少なくとも１つ”又は“１つ以上”の他の場合又は用途とは独立して、１つ又は１つより多くを含むものとする。この文献において、“又は”という用語は、特に言及しない限り“A又はB”が “BではなくA”、“AではなくB”及び“A及びB”を含むように、非排他的な論理和を示すために使用される。特許請求の範囲において、“including（含む）”及び“in  which”は、“comprising（有する）”及び“wherein”というそれぞれの用語のプレインイングリッシュの等価物として使用される。また、特許請求の範囲において“含む”及び“有する”は制限のないことであり、すなわち、請求項においてこのような用語の後に記載のものに加えた要素を含むシステム、デバイス、製造物又は処理も、依然としてその請求項の範囲内に入るものと考えられる。更に、特許請求の範囲において、“第１”、“第２”及び“第３”等の用語は、単なるラベルとして使用され、これらの対象の数値的要件を課すことを意図するものではない。
【００８０】
前述の説明は、例示的であり、限定的でないことを意図する。例えば、前述の例（又はその１つ以上の態様）は、互いに組み合わせて使用されてもよい。前述の説明を読むことで当業者により行われるような他の実施例が使用されてもよい。要約は、読者が技術的開示の特徴を迅速に確認することを可能にするため、37  C.F.R.§1.72(b)に従うように提供されている。これは特許請求の範囲又は意味を解釈又は限定するために使用されないという理解で提示されている。また、前述の詳細な説明において、この開示を簡素化するために、様々な特徴がグループ化されることがある。これは、特許請求の範囲に記載されていない開示の特徴がいずれかの請求項に必須であるという意図として解釈されるべきではない。むしろ、本発明の対象は、特定の開示の実施例の全ての特徴より少ないものに存在することがある。従って、特許請求の範囲は、各請求項が別々の実施例として自立して、詳細な説明に組み込まれる。本発明の範囲は、特許請求の範囲により権利がある全範囲の均等物と共に、特許請求の範囲を参照して決定されるべきである。
【００８１】
＜他の例＞
【００８２】
例１．LTE（long  term  evolution）無線ネットワークにおける無線リソースブロック割り当ての方法であって、
ユーザ装置のための下りリンク制御情報メッセージを生成するステップであり、下りリンク制御情報メッセージは、1からN個のリソースブロックの複数の全ての可能な物理リソースブロック割り当てへのインデックスを指定することにより、ユーザ装置にスケジューリングされたN個までの物理リソースブロックを示すリソースブロック割り当てフィールドを有し、リソースブロック割り当てフィールドは、1からN個の物理リソースブロックの割り当てのための全ての可能な物理リソースブロック割り当てを指定するために必要なビット数をせいぜい有し、Nは、物理リソースブロックの総数より小さいステップと、
直交周波数分割多重を使用して物理下りリンク制御チャネルで下りリンク制御情報を送信するステップと
を有する方法。
【００８３】
例２．ユーザ装置に割り当てられたN個までの物理リソースブロックでユーザ装置にVoIP（voice-over-internet-protocol）パケットを送信するステップを有する、例１に記載の方法。
【００８４】
例３．リソースブロック割り当てフィールドのサイズは、せいぜい物理リソースブロックグループのサイズに等しいビット数であり、リソースブロック割り当てフィールドは、物理下りリンク制御チャネルのアドレスを参照してユーザ装置に割り当てられたN個までの物理リソースブロックを指定する、例１又は２に記載の方法。
【００８５】
例４．リソースブロック割り当てフィールドのサイズは、せいぜい物理リソースブロックグループのサイズ-1に等しいビット数であり、リソースブロック割り当てフィールドは、ePDCCH（enhanced  physical  downlink  control  channel）のアドレスを参照してユーザ装置に割り当てられたN個までの物理リソースブロックを指定し、ePDCCHは、共通のリソースブロックグループにおいて第１の物理リソースブロックから送信される、例１又は２に記載の方法。
【００８６】
例５．Nは、ユーザ装置に送信されるRRCメッセージの一部としてシグナリングされる、例１ないし４のうちいずれか１項に記載の方法。
【００８７】
例６．下りリンク制御情報メッセージは、スクランブルインジケーション、アンテナポート及びレイヤ数のうち１つの情報を含まない、例１ないし５のうちいずれか１項に記載の方法。
【００８８】
例７．下りリンク制御情報メッセージは、変調及び符号化方式インジケーション、新規データインジケーション及び冗長バージョンインジケーションのうち１つの情報を含まない、例１ないし６のうちいずれか１項に記載の方法。
【００８９】
例８．ユーザ装置のための下りリンク制御情報メッセージを生成するように構成されたスケジューラモジュールであり、下りリンク制御情報メッセージは、全て同じリソースブロックグループに割り当てられる1からN個のリソースブロックの複数の全ての可能な物理リソースブロック割り当てへのインデックスを指定することにより、N個までのスケジューリングされた物理リソースブロックをユーザ装置に割り当て、Nは、リソースブロックの総数より小さいスケジューラモジュールと、
決定された制御チャネルエレメントでスケジューリングメッセージを送信するように構成されたトランシーバと
を有するeNodeB。
【００９０】
例９．eNodeBとユーザ装置との間の通信モードは、送信モード9である、例８に記載のeNodeB。
【００９１】
例１０．Nは、N個までの物理リソースブロックで送信されるパケットを復号化するために必要な最小の信号対干渉及び雑音比に基づいて決定される、例８又は９に記載のeNodeB。
【００９２】
例１１．スケジューラは、同じリソースブロックグループ内で２つの不連続な物理リソースブロックをスケジューリングするように構成される、例８ないし１０のうちいずれか１項に記載のeNodeB。
【００９３】
例１２．下りリンク制御情報は、物理下りリンク制御チャネルのアドレスを参照してユーザ装置に割り当てられたN個までの物理リソースブロックを指定する、例８ないし１１のうちいずれか１項に記載のeNodeB。
【００９４】
例１３．下りリンク制御情報は、ePDCCH（enhanced  Physical  Downlink  Control  Channel）のアドレスを参照してユーザ装置に割り当てられたN個までの物理リソースブロックを指定する、例８ないし１１のうちいずれか１項に記載のeNodeB。
【００９５】
例１４．物理下りリンク制御チャネルでeNodeBからリソースブロック割り当てメッセージを受信し、リソースブロック割り当てメッセージが小さいリソースブロック割り当てメッセージであることを判断するように構成された受信モジュールであり、小さいリソースブロック割り当てメッセージは、リソースブロック割り当てフィールドを含み、リソースブロック割り当てフィールドは、UEに割り当てられた物理下りリンク共有チャネルのN個までの物理リソースブロックを指定し、リソースブロック割り当てフィールドは、1からN個のリソースブロックの複数の全ての可能な物理リソースブロック割り当てへのインデックスであり、Nは、物理リソースブロックの総数より小さい受信モジュールを有し、
受信モジュールは、リソースブロック割り当てフィールドに基づいてユーザ装置に割り当てられた物理下りリンク制御チャネルの１つ以上の物理リソースブロックを決定し、１つ以上の物理リソースブロックでeNodeBにより送信されたデータを復号化するように構成されるユーザ装置。
【００９６】
例１５．ユーザ装置に割り当てられたN個までの物理リソースブロックで送信されるデータは、VoIP（voice-over-internet-protocol）パケットを有する、例１４に記載のユーザ装置。
【００９７】
例１６．受信モジュールは、ユーザ装置特有の参照信号及びチャネル状態情報参照信号を受信するように構成される、例１４又は１５に記載のユーザ装置。
【００９８】
例１７．リソースブロック割り当てフィールドのサイズは、せいぜいリソースブロックグループの物理リソースブロック数に等しいビット数であり、リソースブロック割り当てフィールドは、物理下りリンク制御チャネルのアドレスを参照してユーザ装置に割り当てられたN個までの物理リソースブロックを指定する、例１４ないし１６のうちいずれか１項に記載のユーザ装置。
【００９９】
例１８．リソースブロック割り当てフィールドのサイズは、せいぜい物理リソースブロックグループの物理リソースブロック数-1に等しいビット数であり、リソースブロック割り当てフィールドは、ePDCCH（enhanced  physical  downlink  control  channel）のアドレスを参照してユーザ装置に割り当てられたN個までの物理リソースブロックを指定する、例１４ないし１６のうちいずれか１項に記載のユーザ装置。
【０１００】
例１９．下りリンク制御情報メッセージは、せいぜい1ビットのHARQ（hybrid  automatic  repeat  request）プロセスインジケーションフィールドを有する、例１４ないし１８のうちいずれか１項に記載のユーザ装置。
【０１０１】
例２０．下りリンク制御情報メッセージは、スクランブルインジケーション、アンテナポート及びレイヤ数のうち１つの情報を含まない、例１４ないし１９のうちいずれか１項に記載のユーザ装置。
【０１０２】
例２１．下りリンク制御情報メッセージは、変調及び符号化方式、新規データインジケータ及び冗長バージョンのうち１つの情報を含まない、例１４ないし２０のうちいずれか１項に記載のユーザ装置。
【０１０３】
例２２．機械により実行された場合、機械に対して、
ユーザ装置のための下りリンク制御情報メッセージを生成する動作であり、下りリンク制御情報メッセージは、1からN個のリソースブロックの複数の全ての可能な物理リソースブロック割り当てへのインデックスを指定することにより、ユーザ装置にスケジューリングされたN個までの物理リソースブロックを示すリソースブロック割り当てフィールドを有し、リソースブロック割り当てフィールドは、1からN個の物理リソースブロックの割り当てのための全ての可能な物理リソースブロック割り当てを指定するために必要なビット数をせいぜい有し、Nは、物理リソースブロックの総数より小さい動作と、
直交周波数分割多重を使用して物理下りリンク制御チャネルで下りリンク制御情報を送信する動作と
を実行させる命令を格納した機械読み取り可能媒体。
【０１０４】
例２３．命令は、機械により実行された場合、機械に対して、ユーザ装置に割り当てられたN個までの物理リソースブロックでユーザ装置にVoIP（voice-over-internet-protocol）パケットを送信することを有する動作を実行させる、例２２に記載の機械読み取り可能媒体。
【０１０５】
例２４．リソースブロック割り当てフィールドのサイズは、せいぜい物理リソースブロックグループのサイズに等しいビット数であり、リソースブロック割り当てフィールドは、物理下りリンク制御チャネルのアドレスを参照してユーザ装置に割り当てられたN個までの物理リソースブロックを指定する、例２２又は２３に記載の機械読み取り可能媒体。
【０１０６】
例２５．リソースブロック割り当てフィールドのサイズは、せいぜい物理リソースブロックグループのサイズ-1に等しいビット数であり、リソースブロック割り当てフィールドは、ePDCCH（enhanced  physical  downlink  control  channel）のアドレスを参照してユーザ装置に割り当てられたN個までの物理リソースブロックを指定し、ePDCCHは、共通のリソースブロックグループにおいて第１の物理リソースブロックから送信される、例２２又は２３に記載の機械読み取り可能媒体。
【０１０７】
例２６．Nは、ユーザ装置に送信されるRRCメッセージの一部としてシグナリングされる、例２２ないし２５のうちいずれか１項に記載の機械読み取り可能媒体。
【０１０８】
例２７．下りリンク制御情報メッセージは、スクランブルインジケーション、アンテナポート又はレイヤ数のうち１つの情報を含まない、例２２ないし２６のうちいずれか１項に記載の機械読み取り可能媒体。
【０１０９】
例２８．下りリンク制御情報メッセージは、変調及び符号化方式インジケーション、新規データインジケーション及び冗長バージョンインジケーションのうち１つの情報を含まない、例２２ないし２６のうちいずれか１項に記載の機械読み取り可能媒体。
【図１】
0006045606.tif 000005
【図２】
0006045606.tif 000006
【図３】
0006045606.tif 000007
【図４】
0006045606.tif 000008
【図５】
0006045606.tif 000009
【図６】
0006045606.tif 000010
【図７】
0006045606.tif 000011