(57)【要約】      （修正有）【課題】マシンタイプ通信デバイスのための高データレート送信に関連する方法を提供する。【解決手段】方法は、基地局のセル帯域幅を（重複しない）狭帯域及び各狭帯域のサブフレームに分割することにより基地局がマシンタイプ通信（ＭＴＣ）デバイスと通信する通信システムが開示される。基地局は、ＭＴＣデバイスのために複数のサブフレームにおいて物理リソースブロック（ＰＲＢ）のセットを割り当てるための制御情報（ＤＣＩ）を生成し、送信する。基地局がデータを送信した後に、ＭＴＣデバイスは、ｉ）データが複数のサブフレームの各々において正常に受信されたこと（例えば、単一の「ＡＣＫ」）又はｉｉ）データが複数のサブフレームの少なくとも１つにおいて受信されなかったこと（例えば、単一の「ＮＡＣＫ」）を示すＨＡＲＱフィードバックを生成し、送信する。【選択図】図４
2020120412.tif 000002
【特許請求の範囲】
【請求項１】
基地局により実行される方法であって、前記方法は、
通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を生成することと、
前記生成された制御情報を前記通信デバイスに送信することと、
前記割り当てられた通信リソースを用いて、前記通信デバイスにデータを送信することと、
前記通信デバイスに送信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを前記通信デバイスから受信することと、を含み、
前記ＡＣＫ／ＮＡＣＫフィードバックは、複数のサブフレームにおいて送信されたデータを受け取ったことを通知するための１つのＡＣＫ／ＮＡＣＫ指示を含む、方法。
【請求項２】
通信デバイスにおいて実行される方法であって、前記方法は、
前記通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を受信することと、
前記割り当てられた通信リソースを用いて、基地局により送信されるデータを受信することと、
前記通信デバイスにより受信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックであって、複数のサブフレームにおいて前記基地局により送信されたデータを受け取ったことを通知するための１つのＡＣＫ／ＮＡＣＫ指示を含む前記ＡＣＫ／ＮＡＣＫフィードバックを生成することと、
前記生成されたＡＣＫ／ＮＡＣＫフィードバックを前記基地局に送信することと、を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信デバイス及びネットワークに関連し、特に、第３世代パートナーシッププロジェクト（３ＧＰＰ：3rd Generation Partnership Project）規格又はその均等物又は派生物に応じて動作するそれらに関連するが、これらに限定されない。本発明は、特に排他的ではないが、マシンタイプ通信デバイスのための高データレート送信に関連する。
【背景技術】
【０００２】
移動（セルラ）通信ネットワークにおいて、（ユーザ）通信デバイス（ユーザ装置（ＵＥ）、例えば携帯電話としても知られている）は、基地局を介して遠隔サーバ又は他の通信デバイスと通信する。お互いが通信する際に、通信デバイス及び基地局は、ライセンスされた無線周波数を使用し、それらは典型的に周波数帯域及び／又は時間ブロックに分割される。
【０００３】
３ＧＰＰ規格の最新の開発は、ＬＴＥ（Long Term Evolution）−Ａｄｖａｎｃｅｄを含む、ＥＰＣ（Evolved Packet Core）ネットワークのＬＴＥ及びＥ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network）として称される。３ＧＰＰ規格下では、ＮｏｄｅＢ（又はＬＴＥのｅＮＢ）は、基地局であり、通信デバイスは、基地局を介してコアネットワークと接続し、他の通信デバイス又は遠隔サーバと通信する。簡略化のため、本出願は、そのような任意の基地局を指すために基地局という用語を使用する。通信デバイスは、例えば、携帯電話、スマートフォン、ユーザ装置、パーソナルデジタルアシスタント、ラップトップ／タブレットコンピュータ、ウェブブラウザ、電子書籍リーダ、及び／又は同様のもの等の移動通信デバイスであってもよい。そのような移動（又は一般的には静止している）デバイスも、通常、ユーザにより操作される。
【０００４】
３ＧＰＰ規格はまた、いわゆる「モノのインターネット」（ＩｏＴ：Internet of Things）デバイス（例えば、狭帯域ＩｏＴ（ＮＢ−ＩｏＴ）デバイス）をネットワークに接続することを可能にする。ＩｏＴデバイスは、典型的には、様々な測定装置、テレメトリー機器、監視システム、追跡装置（tracking and tracing devices）、車載安全システム、車両メンテナンスシステム、ロードセンサ、デジタル看板、販売時点情報管理（ＰＯＳ：point of sale）端末、遠隔制御システム等の自動装置を含む。一部のＩｏＴデバイスは、監視／追跡されるために、非静止装置（例えば、車両）に埋め込まれるかもしくは動物又は人に取り付けることができるが、ＩｏＴデバイスは、自動販売機、路側センサ、ＰＯＳ端末等の（一般的に）固定装置の一部として実装することができる。効果的に、モノのインターネットは、適切な電子機器、ソフトウェア、センサ、ネットワークコネクティビティ及び／又はそのようなものを備えたデバイス（又は「モノ」）のネットワークであり、これらのデバイスが、相互に、及び他の通信デバイスとデータを収集し交換することを可能にする。ＩｏＴデバイスは、時々、マシンタイプ通信（ＭＴＣ：Machine-Type Communication）通信デバイス又はマシンツーマシン（Ｍ２Ｍ：Machine-to-Machine）通信デバイスとも呼ばれることは理解されるであろう。
【０００５】
簡略化のために、本出願は、説明において、ＭＴＣデバイスに言及するが、説明される技術は、そのような通信デバイスが、人の入力又はメモリに格納されたソフトウェア命令により制御されるかに関わらず、データの送信／受信するために通信ネットワークに接続することができる、任意の通信デバイス（モバイル及び／又は一般的に静止）に実装することができることは理解されるであろう。
【０００６】
ＭＴＣデバイスは、遠隔の「機械」（例えば、サーバ）又はユーザにデータを送信し、遠隔の「機械」（例えば、サーバ）又はユーザからデータを受信するために、ネットワークに接続する。ＭＴＣデバイスは、携帯電話又は同様のユーザ装置のために最適化された通信プロトコル及び規格を使用する。しかし、一旦配置されると、ＭＴＣデバイスは、典型的に、人の監督又は対話を必要とせずに動作し、内部メモリに格納されたソフトウェア命令に従う。ＭＴＣデバイスはまた、長期間静止及び／又は非アクティブのままであり得る。ＭＴＣ（ＩｏＴ）デバイスをサポートするための特定のネットワーク要件は、３ＧＰＰテクニカルレポート（ＴＲ）３６．８８８  Ｖ１２．０．０及び３ＧＰＰ  ＴＲ  ２３．７２０  Ｖ１３．０．０において取り扱われてきた。ＭＴＣデバイスに関連するさらなるネットワーク要件は、３ＧＰＰ技術仕様（ＴＳ：technical specification）２２．３６８  Ｖ１３．１．０において開示されている。これらの３ＧＰＰ文書の内容は、本明細書に参照により取り込む。
【０００７】
セルラネットワークを介したＩｏＴ及び他のマシンタイプ通信デバイスの提供は、モバイル事業者にとって重要な機会であることが証明されている。３ＧＰＰ規格のリリース１３（Ｒｅｌ−１３）バージョンでは、拡張されたカバレッジ及び長いバッテリ寿命を備えた２つのクラスの低コストＩｏＴデバイスが指定されている：それぞれ６ＰＲＢ及び１ＰＲＢのＵＥ帯域幅をサポートする拡張ＭＴＣ（ｅＭＴＣ：enhanced MTC）デバイス及び狭帯域ＩｏＴ（ＮＢ−ＩｏＴ：narrowband IoT）デバイスである（１ＰＲＢ＝１８０ｋＨｚ物理リソースブロック）である。このように、（「低減された帯域幅ＭＴＣデバイス（reduced bandwidth MTC devices）」と呼ばれてもよい）いくつかのＭＴＣデバイスは、総ＬＴＥ帯域幅と比較して、限られた帯域幅（ダウンリンク及びアップリンクにおいて、通常、１．４ＭＨｚ又は１８０ｋＨｚ）のみをサポートするであろう。これは、より大きな帯域幅をサポートする、及び／又は、より複雑な構成要素を有するＭＴＣデバイス及び他の通信デバイスと比較して、（より少ない／単純化した構成要素を有する）そのような低減された帯域幅ＭＴＣデバイスが、より経済的に作られることを可能にする。
【０００８】
ＬＴＥシステム帯域幅は、典型的に１．４ＭＨｚよりも大きく（つまり、最大２０ＭＨｚ）、システム帯域幅は、複数の「狭帯域」（又は「サブバンド」）に分割され、各狭帯域は、最大６つの物理リソースブロック（ＰＲＢ：physical resource block）を含み、これは、１．４ＭＨｚ帯域幅に制限されたＭＴＣデバイスがＬＴＥにおいて使用することができるＰＲＢの最大数である。
【０００９】
（ＭＴＣデバイスの機能が制限されていることが多いことと組み合わされて、（例えば、屋内に配置されている場合で）例えば、ネットワークカバレッジが不足していることにより）ＭＴＣデバイスが一部の送信を受信しないというリスクを軽減するために、ＭＴＣデバイスのために特定のＬＴＥ送信（チャネル）のカバレッジを拡大することも提案されている。ＭＴＣデバイスのためにカバレッジを向上させるための１つのアプローチは、複数（例えば、２、３、４又はそれ以上）のサブフレームにわたって同じ情報を繰り返すことである。換言すると、カバレッジ拡張ＭＴＣデバイス（coverage enhanced MTC devices）の場合、基地局は、時間領域において送信された情報を複製する（基地局は、その情報が最初に送信されたサブフレームに続く１つ又は複数のサブフレームにおいて同じ情報を再送信する）。カバレッジ拡張ＭＴＣデバイスは、複数のサブフレームにおいて受信された（同じ）情報の複数のコピーを組み合わせるように構成することができ、受信された情報を組み合わせた後、カバレッジ拡張ＭＴＣデバイスは、当該情報の単一コピーに基づくよりも送信されたデータを正常に複合することができる可能性が高い。３ＧＰＰは、ＭＴＣデバイスのために２つのカバレッジ拡張（ＣＥ：coverage enhancement）モードを指定した：比較的少ない数の繰り返し（又は繰り返しが全くない）を採用するＣＥモードＡ；及び、多数の繰り返しを採用する（かつ、より高い送信電力を採用してもよい）ＣＥモードＢである。
【００１０】
狭帯域の導入を含むＲｅｌ−１３規格は、主に、センサ、メータ、スマートリーダ及び同様のもの等のＭＴＣデバイスに対して複雑さの軽減、拡張されたバッテリ寿命及びカバレッジ拡張に取り組む。ＮＢ−ＩｏＴタイプＵＥカテゴリの導入は、低いデータレートのユースケース（例えば、２００ｋｂｐｓ未満を必要とする）に対処し、一方、ｅＭＴＣタイプＵＥカテゴリの導入は、半二重周波数分割複信（ＨＤ−ＦＤＤ：Half Duplex Frequency Division Duplex）が採用された場合に３００ｋｂｐｓ程度のデータレート、又は全二重周波数分割複信（ＦＤ−ＦＤＤ：Full Duplex Frequency Division Duplex）送信が採用される場合に８００ｋｂｐｓ程度のデータレートに対処することができる。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
主な焦点となっている、これらのＭＴＣデバイス／ユースケースとは別に、Ｒｅｌ−１３規格はまた、音声対応ウェアラブルデバイス及びヘルスモニタリングデバイス等、他のタイプのＭＴＣデバイス／ユースケースの要件も満たす。しかし、Ｒｅｌ−１３の改善により完全にカバーされていない、及び／又はサポートされていないＭＴＣデバイス／ユースケースのサブセットが未だある。例えば、（例えば、１Ｍｂｐｓを超える）より高いデータレート、モビリティを要求するＭＴＣデバイス／ユースケース、及び遅延に敏感なサービスをサポート／使用するＭＴＣデバイスである。したがって、（既存のＲｅｌ−１３  ｅＭＴＣソリューションにより達成された消費電力及び複雑性の低減並びにリンクバジェット拡張機能を犠牲にすることなく）（現在可能なＭＴＣデータレートと比較して）より高いデータレート、及びＲｅｌ−１３  ＭＴＣ／ｅＭＴＣ仕様において考慮されているＭＴＣデバイスと比較してモビリティに対する向上されたサポートを提供することにより、さらなるユースケースに対処し、さらなるタイプのＭＴＣデバイスをサポートすることは重要である。
【００１２】
したがって、本発明は、これらの問題のうちの１又は複数に少なくとも部分的に対処するためのシステム、装置、及び方法を提供しようとするものである。
【課題を解決するための手段】
【００１３】
一態様において、本発明は、通信システムのための基地局を提供し、前記基地局は、マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を生成するように動作可能なコントローラと、前記マシンタイプ通信デバイスに前記生成された制御情報を送信し、前記割り当てられた通信リソースを用いて、前記マシンタイプ通信デバイスにデータを送信し、前記マシンタイプ通信デバイスに送信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを前記マシンタイプ通信デバイスから受信するように動作可能なトランシーバと、を含み、前記データは、多数のデータバンドルにおいて順に送信され（例えば、物理ダウンリンク共有チャネル「ＰＤＳＣＨ」バンドル）、各データバンドルは、一連のダウンリンクサブフレームにおいて送信され、前記ＡＣＫ／ＮＡＣＫフィードバックは、各データバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックを含み、前記コントローラは、最後のデータバンドルが送信される最後のサブフレームに基づいて、最初のＰＤＳＣＨバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックが予想される開始サブフレーム、データバンドルの数、及び前記データバンドルの送信が繰り返されるか否かを決定するように動作可能である。
【００１４】
他の態様において、本発明は、通信システムのためのマシンタイプ通信デバイスを提供し、前記マシンタイプ通信デバイスは、前記マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を受信し、前記割り当てられた通信リソースを用いてデータを受信するように動作可能なトランシーバを含み、前記データは、多数のデータバンドルにおいて順に送信され（例えば、物理ダウンリンク共有チャネル「ＰＤＳＣＨ：physical downlink shared channel」バンドル）、各データバンドルは、一連のダウンリンクサブフレームにおいて送信され、前記マシンタイプ通信デバイスは、前記マシンタイプ通信デバイスにより受信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを生成するように動作可能なコントローラを含み、前記ＡＣＫ／ＮＡＣＫフィードバックは、各バンドルに対するそれぞれのＡＣＫ／ＮＡＣｋフィードバックを含み、前記コントローラは、最後のデータバンドルが送信される最後のサブフレームに基づいて、最初のＰＤＳＣＨバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックが予想される開始サブフレーム、データバンドルの数、前記データバンドルの送信が繰り返されるか否かを決定するように動作可能であって、前記トランシーバは、前記決定された開始サブフレームに基づいて、前記生成されたフィードバックを前記基地局に送信するように動作可能である。
【００１５】
他の態様において、本発明は、通信システムのための基地局を提供し、前記基地局は、マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を生成するように動作可能なコントローラと、前記割り当てられた通信リソースを用いて、前記マシンタイプ通信デバイスに前記生成された制御情報を送信し、前記マシンタイプ通信デバイスにデータを送信し、前記マシンタイプ通信デバイスに送信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを前記マシンタイプ通信デバイスから受信するように動作可能なトランシーバと、を含み、前記ＡＣＫ／ＮＡＣＫフィードバックは、複数のサブフレームにおいて奏しされたデータを受け取ったことを通知するための１つのＡＣＫ／ＮＡＣＫ指示を含む。
【００１６】
他の態様において、本発明は、通信システムのための基地局を提供し、前記基地局は、マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を生成するように動作可能なコントローラを含み、前記制御情報は、（ｉ）複数のサブフレームの各々における通信リソース、及び（ｉｉ）同一サブフレームの複数の狭帯域の各々における通信リソースの少なくとも１つを割り当てるための１つのダウンリンク制御指示を含み、前記基地局は、前記割り当てられた通信リソースを用いて、前記マシンタイプ通信デバイスにデータを送信するために、前記マシンタイプ通信デバイスに前記生成された制御情報を送信するように動作可能なトランシーバを含む。
【００１７】
他の態様において、本発明は、通信システムのためのマシンタイプ通信デバイスを提供し、前記マシンタイプ通信デバイスは、マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を受信し、前記割り当てられた通信リソースを用いて、データを受信するように動作可能なトランシーバと、前記マシンタイプ通信デバイスにより受信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを生成するように動作可能なコントローラと、を含み、前記ＡＣＫ／ＮＡＣＫフィードバックは、複数のサブフレームにおいて送信されたデータを受け取ったことを通知するための１つのＡＣＫ／ＮＡＣＫ指示を含み、前記トランシーバは、前記生成されたフィードバックを前記基地局に送信するように動作可能である。
【００１８】
他の態様において、本発明は、通信システムのためのマシンタイプ通信デバイスを提供し、前記マシンタイプ通信デバイスは、基地局から、前記マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を受信するように動作可能なトランシーバを含み、前記制御情報は、（ｉ）複数のサブフレームの各々における通信リソース、及び（ｉｉ）同一サブフレームの複数の狭帯域の各々における通信リソースの少なくとも１つを割り当てるための１つのダウンリンク制御指示を含み、前記トランシーバは、前記割り当てられた通信リソースを用いてデータを受信するように動作可能である。
【００１９】
本発明の態様は、対応するシステム、方法、及び、上記の態様及び可能性において説明された、又は任意の請求項に記載された方法を実行するためにプログラム可能なプロセッサをプログラムするように動作可能な、及び／又は任意の請求項に記載された装置を提供するように適切に適合されたコンピュータをプログラムするように動作可能な、コンピュータ可読記憶媒体に格納された命令を有するコンピュータ可読記憶媒体等のコンピュータプログラム製品にまで及ぶ。
【００２０】
（特許請求の範囲を含む用語である）本明細書に開示された、及び／又は、図面に示された各特徴は、任意の他の開示された、及び／又は、図示された特徴と独立して（もしくは任意の他の開示された、及び／又は、図示された特徴と組み合わされて）本発明に組み込まれてもよい。特に、限定するものではないが、特定の独立請求項に従属する任意の請求項の特徴は、当該独立請求項に任意の組み合わせで、又は個別に導入されてもよい。
【００２１】
方法及び／又は装置に関して本明細書で使用される「レガシー」という用語は、本出願の優先日において関連する規格に精通している者に知られている方法及び／又は装置、特に、限定されるものではないが、優先日において標準化されている方法／及び装置を指す（例えば、限定されるものではないが、３ＧＰＰ規格のリリース１３又はそれよりも前に標準化されたもの等）。
【００２２】
本発明の例示的な実施形態は、添付の図面を参照して、一例として説明される。
【図面の簡単な説明】
【００２３】
【図１】図１は、本発明の例示的な実施形態が適用され得る通信システムを概略的に示す図である。
【図２】図２は、図１に示す通信デバイスの主要な構成要素を示すブロック図である。
【図３】図３は、図１に示す基地局の主要な構成要素を示すブロック図である。
【図４】図４は、図１に示すシステムにおけるＭＴＣデバイスに対して高いデータレートを実現することができる例示的な方法を示す図である。
【図５】図５は、図１に示すシステムにおけるＭＴＣデバイスに対して高いデータレートを実現することができる例示的な方法を示す図である。
【図６】図６は、図１に示すシステムにおけるＭＴＣデバイスに対して高いデータレートを実現することができる例示的な方法を示す図である。
【図７】図７は、図１に示すシステムにおけるＭＴＣデバイスに対して高いデータレートを実現することができる例示的な方法を示す図である。
【図８】図８は、図１に示すシステムにおけるＭＴＣデバイスに対して高いデータレートを実現することができる例示的な方法を示す図である。
【図９】図９は、図１に示すシステムにおいてＭＴＣデバイス対応狭帯域を提供し得る例示的な方法を示す図である。
【発明を実施するための形態】
【００２４】
概要
図１は、通信デバイス３（携帯電話３−１及びＭＴＣデバイス３−２等）が、互いに、及び／又はＥ−ＵＴＲＡＮ基地局５（「ｅＮＢ」として示される）並びにコアネットワーク７を介して他の通信ノードと通信することができるモバイル（セルラ）電気通信システム１を概略的に示す。当業者には理解されるように、１つの携帯電話３−１、１つのＭＴＣデバイス３−２及び１つの基地局５が例示目的で図１に示されているが、実装される場合、システムは、通常、他の基地局及び通信デバイスを含むことになる。
【００２５】
基地局５は、Ｓ１インタフェースを介してコアネットワーク７に接続されている。簡略化のために、図１には省略されているが、コアネットワーク７は、とりわけ、インターネット等の他のネットワークに、及び／又はコアネットワーク７の外部にホストされているサーバに接続するためのゲートウェイ、通信ネットワーク１内の通信デバイス３（例えば、携帯電話及びＭＴＣデバイス）の位置を追跡するためのモビリティ管理エンティティ（ＭＭＥ：mobility management entity）、及び、加入関連情報（例えば、どの通信デバイス３がマシンタイプ通信デバイスとして構成されているかを特定する情報）を記憶するための、及び各通信デバイス３に固有の制御パラメータを記憶するためのホーム加入者サーバ（ＨＳＳ：home subscriber server）を含む。
【００２６】
基地局５は、例えば、物理ダウンリンク制御チャネル（ＰＤＣＣＨ：physical downlink control channel）及び物理アップリンク制御チャネル（ＰＵＣＣＨ：physical uplink control channel）を含む、多数の制御チャネル、並びに、例えば、物理ダウンリンク共有チャネル（ＰＤＳＣＨ：Physical Downlink Shared Channel）及び物理アップリンク共有チャネル（ＰＵＳＣＨ：Physical Uplink Shared Channel）を含む、多数のデータチャネルを提供するように構成される。ＰＤＣＣＨ（又はＭＴＣ固有のＰＤＣＣＨ、「ＭＰＤＣＣＨ：MTC specific PDCCH」）は、（通常、現在のスケジューリングラウンドにおいてスケジューリングされた各通信デバイス３に、それぞれのＵＥ固有のダウンリンク制御情報（ＤＣＩ：downlink control information）を送信することにより）通信デバイス３にリソースを割り当てるために、基地局５により使用される。ＰＵＣＣＨは、ＵＥ固有のアップリンク制御情報（ＵＣＩ：uplink control information）を基地局５に送信するために、通信デバイス３により使用される（例えば、アップリンクデータを送信するためのスケジューリング要求、及びＤＣＩにより割り当てられたリソースを用いて受信されたダウンリンクデータに対応するハイブリッドオートマチックリピートリクエスト（ＨＡＲＱ：Hybrid Automatic Repeat Request）フィードバック）。ＰＤＳＣＨは、関連するＤＣＩシグナリングを介してスケジューリングされた特定の通信デバイス３のためのダウンリンクデータ等のダウンリンクユーザデータを運ぶ主データ搬送チャネルである。ＰＤＳＣＨはまた、基地局５のセルに関連するシステム情報も運ぶ。ＰＵＳＣＨは、（ＰＵＣＣＨを介して受信された適切なスケジューリング要求ＵＣＩに基づいて）基地局５により割り当てられたリソースを使用して、通信デバイス３からのアップリンクユーザデータを運ぶ。
【００２７】
セル内の低減された帯域幅ＭＴＣデバイスをサポートするために、図１の基地局５のシステム帯域幅は、複数の重ならない狭帯域（例えば、狭帯域当たり最大６ＰＲＢ）に分割される。システム帯域幅内の狭帯域は、Ｒｅｌ−１３低複雑度ＭＴＣ  ＵＥに対して狭帯域のためのリソース割り当てシグナリングを維持することが可能であるように割り当てられる。
【００２８】
各通信デバイス３は、ＵＥの１又は複数のカテゴリに分類され得る。ＵＥの第１のカテゴリは、基地局５のセル内で利用可能な全帯域幅にわたって通信することができる、携帯電話等の従来の（つまり、非ＭＴＣ）通信デバイスを含む。ＵＥの第２のカテゴリは、１８０ｋＨｚ帯域幅のみ（１ＰＲＢ）を使用することが可能なＮＢ−ＩｏＴデバイス（及び／又は同様のもの）を含む。ＵＥの第３のカテゴリは、最大１．４ＭＨｚ帯域幅を使用することが可能なＲｅｌ−１３ＭＴＣ／ｅＭＴＣデバイスを含む。ＵＥの第４のカテゴリは、従来のＭＴＣ／ｅＭＴＣデバイスよりも洗練された回路（高度な回路）を有する可能性があり、１．４ＭＨｚ帯域幅を超えた帯域幅を使用することが可能である、「さらなる拡張」ＭＴＣ（「ＦｅＭＴＣ」）デバイスを含む。したがって、この例では、ＵＥの第２から第４のカテゴリは、（各カテゴリのデバイスは、異なるそれぞれの帯域幅をサポートしてもよいが、）基地局５のセル内で利用可能な全帯域幅にわたって通信することが可能ではない、又は通信するように構成されていない可能性がある、様々な低減された帯域幅ＵＥ（ＭＴＣデバイス及びＭＴＣ機能が設定された場合のオプション的な携帯電話等）を含む。
【００２９】
この例では、携帯電話３−１は、ＵＥの第１のカテゴリに分類され、それはまた、（例えば、ＭＴＣアプリケーションを実行する場合）１又は複数の他のカテゴリに分類されてもよい。そのため、携帯電話３−１は、全システム帯域幅を使用することができる。一方、ＭＴＣデバイス３−２は、ＵＥの第４のカテゴリに分類され、（全システム帯域幅ではないが）１．４ＭＨｚ帯域幅を超える帯域幅を使用することができる。ＭＴＣデバイス３−２は、ＮＢ−ＩｏＴデバイス又はｅＭＴＣデバイスとしてそれぞれ動作する場合、第２のＵＥカテゴリ又は第３のＵＥカテゴリに分類され得ることは理解されるであろう。
【００３０】
有利なことに、このシステムは、互換性のある通信デバイス（例えば、少なくとも第１及び第４のカテゴリのＵＥ）に対して、（１．４ＭＨｚ帯域幅／６ＰＲＢを使用する）現在の（ｅ）ＭＴＣ規格を使用して達成することができるデータレートよりも高い／柔軟なデータレートをサポートするように構成される。
【００３１】
具体的には、より高いデータレートに対するそのようなサポートは、互換性のある通信デバイス３に対して、そのダウンリンク送信を、スケジューリングされた通信デバイス３がアップリンクにおいて（肯定応答を含む）データを送信することをスケジューリング／要求されない間の複数の（連続する）ダウンリンクサブフレームにスケジューリングする、基地局５により実現されてもよい。このようなサブフレームのシーケンスを使用することは、通信デバイス３が実質的に連続的に（そして、適切な場合には、ｅＭＴＣデバイスに対して現在可能なものよりも潜在的に高いデータレートで）データを受信することを有利なことに可能とする。このようにスケジューリングされる通信デバイス３はまた、ダウンリンクサブフレームのシーケンス中にアップリンクデータ及び／又はフィードバックを送信するためにアップリンクチャネルに戻ることを回避することができる。具体的には、この場合、サブフレームのシーケンスにわたるダウンリンク送信を受信するようにスケジューリングされる各通信デバイス３は、サブフレームのシーケンスに関する（複数の）ＨＡＲＱ確認応答を束ね（バンドルする）ように構成され、通信デバイス３のためにスケジューリングされる複数のダウンリンクサブフレームの各シーケンスの最後のサブフレームに続いて、（例えば、周期的に、ＨＡＲＱ送信機会において）束ねられた（バンドリングされた）ＨＡＲＱフィードバックを送信するように構成される。
【００３２】
効果的には、ＨＡＲＱバンドリングの場合、通信デバイス３は、（各サブフレームにおけるデータ送信が成功したか否かに基づいて、そのサブフレームに対して単一の「ＡＣＫ」又は「ＮＡＣＫ」になる場合）複数のダウンリンクサブフレームに対して、複数のそれぞれのＡＣＫ／ＮＡＣＫについて論理「及び」演算を実行することにより単一の確認応答フィードバックを導くように構成される。通信デバイス３は、全ての関連するダウンリンク送信が成功した場合に基地局５に「ＡＣＫ」を送信するように構成され、もしくは１又は複数の関連するダウンリンク送信が失敗した場合に「ＮＡＣＫ」を送信するように構成される。ＨＡＲＱバンドリングのさらなる詳細は、図４を参照して以下で提供される。
【００３３】
ＨＡＲＱ確認応答バンドリングが使用される場合、基地局５は、互換性のある通信デバイス３に対して、ダウンリンクデータをスケジューリングするための２つのオプションを有する。第１のオプションでは、基地局５は、単一のサブフレームにおいて送信をスケジューリングするために１つのＤＣＩフォーマット（サブフレーム当たり１つのＤＣＩ）を使用してもよい。この場合、一連の適切に構成されたＤＣＩフォーマットが、ダウンリンクデータに割り当てられる一連のサブフレームをスケジューリングされる通信デバイス３に指示するために使用されてもよい。そのＤＣＩフォーマットから、通信デバイス３は、対応する（バンドリングされた）ＨＡＲＱフィードバックを送信するためにどのサブフレームを使用する必要があるかを決定することができる。
【００３４】
第２のオプションでは、基地局５は、複数のサブフレームにおいて送信をスケジューリングするために１つのＤＣＩフォーマット（複数のサブフレーム当たり１つのＤＣＩ）を使用する。この場合、通信デバイス３は、ＤＣＩを介してスケジューリングされた複数のサブフレームのうちの最後のサブフレームに続いて、（適切な送信機会において）対応する（バンドリングされた）ＨＡＲＱフィードバックを送信するように構成される。
【００３５】
有利なことに、適切なＤＣＩフォーマット及びバンドリングされたＨＡＲＱフィードバックを使用して、基地局５は、効率的かつ柔軟な方法で特定の通信デバイス３に対して比較的大きい量のリソースをスケジューリングすることができ、依然として、いずれかのデータを再送信する必要があるかどうかを決定することが可能である。
【００３６】
有利なことに、このシステムでは、いずれのマイナーカバレッジ拡張無しで、又はマイナーカバレッジ拡張のみで動作する（「ＣＥモードＡ」動作として参照される）、少なくともＭＴＣデバイス（及び他の互換性のあるユーザ装置）のＨＤ−ＦＤＤ送信について、より高いデータレートに対するサポートはまた、増加した帯域幅（つまり、１．４ＭＨｚよりも高い帯域幅）でＰＤＳＣＨ／ＰＵＳＣＨを動作するように基地局５を構成することにより、実現されてもよい。適切であれば、増加したＰＤＳＣＨ／ＰＵＳＣＨ帯域幅を使用するオプションは、バンドリングされたＨＡＲＱフィードバック手法と組み合わされてもよいことは理解されるであろう。
【００３７】
基地局５が１．４ＭＨｚを超えるＰＤＳＣＨ／ＰＵＳＣＨ帯域幅を提供することができる２つの方法がある。例えば、基地局は、その狭帯域についても１．４ＭＨｚ、３ＭＨｚ、及び５ＭＨｚのレガシー（つまり、リリース１３以前）のシステム帯域幅を再利用するように構成されてもよい。しかしながら、この場合、いくつかのＭＴＣデバイス（例えば、第２及び第３のＵＥカテゴリ）は、この基地局５のいくつかの狭帯域構成（つまり、６ＰＲＢ／１．４ＭＨｚを超える、そのような「拡張された」狭帯域）と互換性がない可能性がある。したがって、基地局５は、１．４ＭＨｚを超えない狭帯域においてのみ第２及び第３のＵＥカテゴリのＭＴＣデバイスをスケジューリングし、任意の狭帯域（より高いデータレートが要求される場合は、３ＭＨｚ及び／又は５ＭＨｚ狭帯域が好ましい）では、（例えば、第４のＵＥカテゴリの）より拡張されたＭＴＣデバイス及び（第１のカテゴリの）従来のＵＥをスケジューリングするように構成されてもよい。
【００３８】
他の例では、基地局５は、（例えば、第４のＵＥカテゴリの）より拡張されたＭＴＣデバイス及び（第１のＵＥカテゴリの）関連するＵＥのそれぞれに対して、６ＰＲＢ（１．４ＭＨｚ）の複数の狭帯域を集約するように構成されてもよい。この場合、（例えば、第２及び第３のＵＥカテゴリの）他のＭＴＣデバイスのための送信は、依然として単一の狭帯域に対して（つまり、狭帯域のいずれの集約も無しに）スケジューリングすることができる。有利なことに、各互換性のあるＵＥ／ＭＴＣデバイスは、高いデータレートが必要とされるときはいつでもより大きい送信又は受信帯域幅を使用するように構成されてもよい（例えば、特定の通信デバイスのデータレート要求を満たすために、２又は複数の連続する狭帯域を集約してもよい）。
【００３９】
要約すると、ｉ）（時間領域において）複数のサブフレームのシーケンスを使用して、及び／又はｉｉ）拡張／集約された狭帯域を使用して、通信するように、互換性のあるＭＴＣデバイス及び他のユーザ装置をスケジューリングすることにより、現在（Ｒｅｌ−１３）のｅＭＴＣ規格を使用して現在可能なものに加えて、様々なＭＴＣデバイス及びユースケースをサポートすることができ、そして、柔軟な方法で様々なＭＴＣデバイス及びユースケースをサポートすることができる。有利なことに、上述した技術はまた、Ｒｅｌ−１３ｅＭＴＣに対して指定された既存の電力消費及び複雑性の低減機能に準拠し、さらに、既存の電力消費及び複雑性の低減機能を改善することさえあり得る。
【００４０】
通信デバイス
図２は、図１に示す通信デバイス３の主要な構成要素を示すブロック図である。通信デバイス３は、マシンタイプ通信デバイスとして構成されるＭＴＣデバイス又は携帯電話（又は「セルラ」電話）であり得る。通信デバイス３は、少なくとも１つのアンテナ３３を介して、基地局５に信号を送信し、基地局５から信号を受信するように動作するトランシーバ回路３１を含む。典型的に、通信デバイス３はまた、ユーザが通信デバイス３と対話することを可能とするユーザインタフェース３５を含む。しかし、ユーザインタフェース３５は、いくつかのＭＴＣデバイスについては省略されてもよい。
【００４１】
トランシーバ回路３１の動作は、メモリ３９に格納されたソフトウェアに従ってコントローラ３７により制御される。ソフトウェアは、とりわけ、オペレーティングシステム４１、通信制御モジュール４２及びＭＴＣモジュール４５を含む。
【００４２】
通信制御モジュール４２は、通信デバイス３と、基地局５及び／又は（基地局５を介して）他の通信ノードとの間の通信を制御する。図２に示すように、通信制御モジュール４２は、とりわけ、狭帯域モジュール４３及びＨＡＲＱモジュール４４を含む。狭帯域モジュール４３は、システム帯域幅内の狭帯域を識別し、使用することを担当する。ＨＡＲＱモジュール４４は、サービング基地局５からのダウンリンク送信に対して、適切な確認応答（ＡＣＫ／ＮＡＣＫ）を生成し、サービング基地局５に送信することを担当する。適切な場合には、ＨＡＲＱモジュール４４は、確認応答をバンドルし（束ね）、複数のダウンリンク送信に対して（単一の）「バンドリングされた」ＡＣＫ／ＮＡＣＫを送信するように構成されてもよい。
【００４３】
ＭＴＣモジュール４５は、マシンタイプ通信タスクを実行するように動作する。例えば、ＭＴＣモジュール４５は、基地局５によりＭＴＣデバイス３に割り当てられたリソースにより（トランシーバ回路３１を介して）遠隔サーバから（例えば、周期的に）データを受信してもよい。ＭＴＣモジュール４５はまた、（トランシーバ回路３１を介して）遠隔サーバに（例えば、周期的に、及び／又はトリガを検出したときに）送信するためにデータを収集してもよい。ＭＴＣモジュール４５は、（少なくともいくつかのＭＴＣアプリケーションにおいて）高いデータレート送信をサポートするように構成されてもよい。
【００４４】
基地局
図３は、図１に示す基地局５の主要な構成要素を示すブロック図である。基地局５は、１又は複数のアンテナ５３を介して通信デバイスに信号を送信し、通信デバイス３から信号を受信するように動作可能なトランシーバ回路５１を備えるＥ−ＵＴＲＡＮ基地局（ｅＮＢ）を含む。基地局５はまた、適切なコアネットワークインタフェース５５（例えば、Ｓ１インタフェース）を介して、コアネットワーク７に信号を送信し、コアネットワーク７から信号を受信するように動作可能である。
【００４５】
トランシーバ回路５１の動作は、メモリ５９に格納されたソフトウェアに従って、コントローラ５７により制御される。ソフトウェアは、とりわけ、オペレーティングシステム６１及び通信制御モジュール６２を含む。
【００４６】
通信制御モジュール６２は、（任意のＭＴＣデバイスを含む）通信デバイス３との通信を制御する。通信制御モジュール６２はまた、基地局５によりサービスされる通信デバイス３により使用されるリソースをスケジューリングすることを担当する。図３に示すように、通信制御モジュール６２は、とりわけ、狭帯域モジュール６３及びスケジューリングモジュール６４を含む。
【００４７】
狭帯域モジュール６３は、（ＭＴＣ）通信デバイス３と通信するためにシステム帯域幅を狭帯域に分割することを担当する。スケジューリングモジュール６４は、適切にフォーマットされた制御データ（例えば、ＤＣＩ）を生成し、送信することより、及び（適切な場合に、複数のダウンリンク送信に対する「バンドリングされた」ＡＣＫ／ＮＡＣＫを含む）関連する確認応答を受信し、処理することにより、基地局のセル内の通信デバイス３に対する送信をスケジューリングすることを担当する。
【００４８】
上記の説明では、通信デバイス３及び基地局５は、理解を容易にするために、多数の個別モジュールを有するとして説明されている。例えば、既存システムが本発明を実施するために変更された場合等、これらのモジュールは特定の用途のために、このように提供されてもよいが、例えば、はじめから本発明の特徴を念頭において設計されたシステムの他の用途において、これらのモジュールがオペレーティングシステム全体又はコードに組み込まれてもよく、これらのモジュールが別個のエンティティとして認識できなくてもよい。
【００４９】
以下は、ＭＴＣデバイスがＬＴＥシステムにおいて高いデータレート送信を実行し得る様々な方法の説明である。具体的には、上述したように、（ＣＥモードＡのＨＤ−ＦＤＤのための）ＨＡＲＱ−ＡＣＫバンドリングにより、及び／又は、（少なくともＣＥモードＡにおいて）接続されたモードのより大きなＰＤＳＣＨ／ＰＵＳＣＨチャネル帯域幅を採用することにより、より高い／柔軟なデータレートが達成されてもよい。
【００５０】
動作−ＨＡＲＱ−ＡＣＫバンドリング
ＬＴＥでは送信及び受信は、ＨＤ−ＦＤＤ  ＵＥに対して、つまり、半二重ＦＤＤ（ＨＤ−ＦＤＤ：Half Duplex FDD）モードで動作する、通信デバイス３に対して、周波数及び時間の両方で分離される。しかしながら、基地局５は、動作の全二重ＦＤＤ（ＦＤ−ＦＤＤ：Full Duplex FDD）モードをサポートする。したがって、基地局５が同時送信及び受信が可能であったとしても、各ＨＤ−ＦＤＤ  ＵＥは、アップリンク／ダウンリンク方向の後続のサブフレームにおいて送信／受信するようにスケジューリングするかどうかを決定するために、１つのサブフレーム内で制御チャネル（つまり、ＭＰＤＣＣＨ）を待ち受ける（listen）必要がある（つまり、受信機のみとして動作する）。特定のＨＤ−ＦＤＤ  ＵＥが（ＭＰＤＣＣＨ上の適切にフォーマットされた制御情報を介して）送信のためにスケジューリングされている場合、受信された制御情報により識別されるサブフレームにおいてアップリンクデータを送信することができる前に、そのＨＤ−ＦＤＤ動作を送信モードに変更する必要がある。スケジューリングされたデータが送信されると、通信デバイス３は、さらなるスケジューリング割り当てを監視するために、受信機モードに戻る。
【００５１】
このようなＨＤ−ＦＤＤタイプの動作（及びＨＤ−ＦＤＤトランシーバ回路）を使用する主な利点は、通信デバイス３の複雑さの低減（二重フィルタが必要ではない）及び、関連する低コストである。これは、少なくともいくつかのＭＴＣデバイスの場合、重要な要素であり得る。
【００５２】
既存のＬＴＥ  ＦＤＤシステムでは、ダウンリンク（ユニキャスト）データの送信は、受信側の通信デバイス３が、アップリンクにおいて適切なＨＡＲＱフィードバック（Ａｃｋ／Ｎａｃｋ）を生成し、送信することを必要とする。したがって、各ＨＤ−ＦＤＤ  ＵＥ（例えば、ＭＴＣデバイス）は、ダウンリンクデータを受信するときでさえ、ダウンリンクからアップリンクへ、及びその逆に、頻繁に切り換える必要がある（つまり、受信機動作モードと送信機動作モードとの間で行ったり来たりする）。ＨＤ−ＦＤＤ  ＵＥが必要なダウンリンク−アップリンク切り替え動作（つまり、受信機モードから送信機モードへの切り替え）を実行するのに十分な時間を許容するために、ＨＤ−ＦＤＤ  ＵＥは、（ＨＡＲＱフィードバックが送信される）アップリンクサブフレームの直前の割り当てられたダウンリンクサブフレームの最後の直交周波数分割多重（ＯＦＤＭ：Orthogonal Frequency Division Multiplexing）シンボルにおいて、ダウンリンクデータを受信することを期待されていない。これは、ＨＤ−ＦＤＤ  ＵＥは、（次のアップリンクサブフレームの開始前の時間において）トランシーバを送信機モードに切り替えるために、スケジューリングされたダウンリンク送信の最後のＯＦＤＭを使用するからである。これは、欠落したＯＦＤＭシンボル（及びそこに含まれる任意のデータ）のために誤った受信をもたらすが、ＨＡＲＱ手順は、（送信をわずかに延長するが）後の再送信において、任意のそのような欠落したデータを有益に回復することができる。
【００５３】
ＬＴＥシステムでは、多数のＰＲＢを通信デバイス３（例えば、ＨＤ−ＦＤＤ  ＵＥ）に割り当てることにより、単位のサブフレーム（つまり、１つのスケジューリングインスタンス）内にできるだけ多くのデータをスケジューリングすることが可能である。これは、後続のアップリンクサブフレームにおいて関連するデータ送信（例えば、ＨＡＲＱフィードバック）の必要性を減らし、それにより、ダウンリンクサブフレーム及びアップリンクサブフレームの間の（受信機動作モード及び送信機動作モードの間の）頻繁な切り替えの必要性も減らす。しかし、（１．４ＭＨｚ狭帯域帯域幅である場合）狭帯域当たりのＰＲＢ数が６ＲＢに制限されるので、この手法は、ＭＴＣデバイスの場合に限られた可能性がある。
【００５４】
しかし、ダウンリンクからアップリンクへの頻繁な切り替え（及びＨＤ−ＦＤＤ動作における関連する切り替え）の必要性は、帯域幅が制限されたＨＤ−ＦＤＤ  ＵＥの全体的なデータレートも改善する、バンドリングされたＨＡＲＱフィードバックを使用することを回避し得る。
【００５５】
図４は、例示的なＨＡＲＱバンドリング技術の詳細を示す。効果的には、ＨＡＲＱバンドリングの場合、通信デバイス３は、（各サブフレームにおけるデータ送信が成功したか否かに基づいて、そのサブフレーム対して単一の「ＡＣＫ」又は「ＮＡＣＫ」になる場合）複数のダウンリンクサブフレームに対して、複数のそれぞれのＡＣＫ／ＮＡＣＫについて論理「及び」演算を実行することにより単一の確認応答フィードバックを導くように構成される。通信デバイス３は、全ての関連するダウンリンク送信が成功した場合、基地局５に「ＡＣＫ」を送信するように構成され、そうではなく、１又は複数の関連するダウンリンク送信が失敗した場合、「ＮＡＣＫ」を送信するように構成される。
【００５６】
この例では、通信リソースは、ＭＰＤＣＣＨ７０において適切にフォーマットされたＤＣＩフォーマットを送信することにより、通信デバイス３に割り当てられる。例えば、ＤＣＩは、ＤＣＩフォーマットが送信されるサブフレームに続く第２のサブフレームにおいてＰＤＳＣＨ７１のためにダウンリンクデータを「クロススケジューリングする」ために使用され得る。しかし、この例では、通信デバイス３は、ＰＤＳＣＨ７１に続くサブフレームにおいて、ＭＰＤＣＣＨ７０を介して（さらなるＤＣＩを介して）さらなるダウンリンクデータのためにスケジューリングされる（さらなるダウンリンクデータは、さらなるＤＣＩフォーマットが送信されるサブフレームに続く第２のサブフレームにおいて送信される）。ＨＡＲＱバンドリングを実行することにより、通信デバイス３は、ダウンリンク送信が完了するまでの間、ＨＤ−ＦＤＤ送信機モードに切り替える必要性を有益に回避することができ、（２つのサブフレームのバンドリングの場合）両方のダウンリンク送信に対する十分なフィードバックを提供することができる。図４に見ることができるように、バンドリングされたＨＡＲＱフィードバック（Ａｃｋ／Ｎａｃｋ）は、（最後のスケジューリングされたダウンリンクＰＤＳＣＨ７１に続くアップリンクサブフレームにおいて）ＰＵＣＣＨ７２を介して送信される。図４において、バンドリングされたＨＡＲＱフィードバックは、後のサブフレームで送信されるが、バンドリングされたＨＡＲＱフィードバックは、最後のスケジューリングされたダウンリンクＰＤＳＣＨ７１に続く最初の「ＵＬ」サブフレーム（当該サブフレームがＰＵＣＣＨ７２を運ぶ場合）において送信されてもよいことは理解されるであろう。
【００５７】
以下は、図１に示すシステム１における通信デバイス３が、複数のダウンリンクサブフレームをスケジューリングすることができるいくつかの可能な方法の詳細な説明である。以下の例では、通信デバイス３は、ＵＥの第４のカテゴリ（ＦｅＭＴＣデバイス）に分類され、ＨＤ−ＦＤＤ動作が可能なトランシーバ３１を備える。しかし、通信デバイス３はまた、ＵＥの第１のカテゴリ（例えば、携帯電話３−１）に分類されてもよく、いくつかの例では、ＵＥの第２のカテゴリ又は第３のカテゴリ（例えば、ＮＢ−ＩｏＴデバイス／（ｅ）ＭＴＣデバイス）に分類されてもよい。通信デバイス３は、カバレッジ拡張をせずに、又はわずかなカバレッジ拡張のみにより（「ＣＥモードＡ」動作と呼ばれる）動作してもよいことは理解されるであろう。
【００５８】
＜サブフレーム当たり１つのＤＣＩ＞
第１のオプションでは、（スケジューリングモジュール６４を使用して）基地局５は、特定の通信デバイス３のために、１つのＤＣＩフォーマット（つまり、各スケジューリングされるサブフレーム当たり１つのＤＣＩ）を使用して特定の（単一の）ダウンリンクサブフレームにおいてダウンリンク送信をスケジューリングするように構成される。このように、当該通信デバイス３にダウンリンクデータを運ぶためにサブフレームのシーケンスをスケジューリングするとき、基地局５（スケジューリングモジュール６４）は、ＭＰＤＣＣＨ７０（非ＭＴＣ  ＵＥの場合ＰＤＣＣＨ）において、複数の適切に設定されたＤＣＩフォーマットを生成し、送信し、各ＤＣＩフォーマットは、サブフレームのスケジューリングされたシーケンスの１つのそれぞれのサブフレームを示す（また、そのサブフレーム内の割り当てられたダウンリンクリソース、つまり、ＰＲＢも示す）。通信デバイス３は、（ＨＤ−ＦＤＤ受信モードにある受信機３１を使用して）ＭＰＤＣＣＨ７０を待ち受ける（listening）ことによりＤＣＩフォーマットを受信し、（通信制御モジュール４２を使用して）受信されたＤＣＩフォーマットを処理することによりダウンリンク割り当て（どのサブフレーム／ＰＲＢ）を決定する。依然としてＨＤ−ＦＤＤ受信モードにある間に、通信デバイス３は、ＰＤＳＣＨ７１を介して、関連するＤＣＩフォーマットにより示される各ダウンリンクサブフレーム内のダウンリンクデータを受信する。
【００５９】
この場合、ＨＡＲＱバンドリングが使用されるため、（ＨＡＲＱモジュール４４を使用して）通信デバイス３は、全てのスケジューリングされたダウンリンク送信が正常に受信された場合、「ＡＣＫ」を生成し、（ＰＵＣＣＨ７２を介して）送信され、１又は複数のスケジューリングされたダウンリンク送信が正しく受信されなかった場合、「ＮＡＣＫ」を生成し、送信する。具体的には、例として図５に示すように、通信デバイス３が、「ｎ」でインデックスされたアップリンクサブフレームにおいて、ＰＵＣＣＨ７２を介して、バンドリングされたＨＡＲＱフィードバックを送信する必要がある場合、この特定の通信デバイス３への最後のスケジューリングされたダウンリンク送信は、「ｎ−４」でインデックスされたダウンリンクサブフレームのためにスケジューリングされる。したがって、通信デバイス３がダウリンクサブフレーム「ｎ−４」の後に、いずれのＤＣＩも受信しない場合、通信デバイス３は、サブフレーム「ｎ」の前に、送信モードを切り替えるために十分な時間がある。
【００６０】
ＨＡＲＱフィードバックを提供する必要がある前に、通信デバイスにスケジューリングされるサブフレームの（合計又は残りの）数を示すために、いわゆるダウンリンク割り当てインデックス（ＤＡＩ：downlink assignment index）は、各ＤＣＩフォーマットに含まれてもよいことは理解されるであろう。有利なことに、通信デバイス３は依然としてＨＡＲＱフィードバックを送信するために（最後にスケジューリングされたダウンリンクサブフレームを基準にして）正しいサブフレームを決定することができるので、ＤＣＩフォーマットの１つが誤検出された場合でされても、通信デバイス３は、適切なＨＡＲＱフィードバック（例えば、ＮＡＣＫ）を適切なアップリンクサブフレーム「ｎ」で提供することを可能にする。
【００６１】
ＤＡＩが使用される場合、以下の可能性のいずれかを用いて実装されてもよい：
−特定のセットにおけるＰＤＳＣＨの最後の割り当てがサブフレーム「ｎ−４」として使用され、ＨＡＲＱフィードバックがアップリンクサブフレーム「ｎ」において送信された場合、固定の事前に定義されたサブフレームのセットに対する割り当てがバンドリングされる（例えば、サブフレームのセット［２，５，８］、［３，６，９］及び［１，４，７］）。
−以下のような式を使用する
【数１】
2020120412.tif 000003
ここで、ｎｆは、システムフレーム番号（ＳＦＮ：system frame number）であり、フロア（ｎｓ／２）は、サブフレーム番号である。この場合、４つの連続するサブフレーム毎に生じるＨＡＲＱフィードバックがバンドリングされる。
−ＤＣＩフォーマットは、（例えば、開始割り当てから）いくつの連続するスケジューリング割り当てがバンドリングされるかをシグナリングするように構成され得る。例えば、２ビットを使用して、値「００」が１つの割り当てを示してもよく、値「０１」が２つの割り当てを示してもよく、値「１０」が３つの割り当てを示してもよく、値「１１」が４つの割り当てを示してもよい。さらに、追加のビット（extra bit）が開始割り当てを識別するために使用されてもよい（例えば、値「１」＝ＯＮ；値「０」＝ＯＦＦ）。
−ＤＣＩフォーマットは、割り当て毎にデクリメントされるカウンタをシグナリングするように構成されてもよい。例えば、４つの割り当ての場合、２ビットが使用されてもよく、１１-->１０-->０１-->００（「００」は、最後の割り当てを示す）のようにデクリメントすることができる。この場合も同様に、追加のビットが開始割り当てを識別するために使用されてもよい（例えば、「１」＝ＯＮ、「０」＝ＯＦＦ）。
−ＤＣＩフォーマットは、割り当ての総数と、シーケンス内の現在の割り当ての位置と、の両方（の組み合わせ）を示すカウンタをシグナリングするように構成され得る。例えば、４つの割り当ての場合、３ビットが使用されてもよく、その値は以下のように解釈することができる。００１-->２つの割り当てのシーケンスにおける１番目；０１０-->２つの割り当てのシーケンスにおける２番目；０１１-->４つの割り当てのシーケンスの１番目；１００-->４つの割り当てのシーケンスの２番目；１０１-->４つの割り当てのシーケンスの３番目；１１０-->４つの割り当てのシーケンスの４番目。この可能性は表１にまとめられている。
【表１】
2020120412.tif 000004
−ＤＣＩフォーマットは、開始割り当て、中間割り当て及び終了割り当てを表すビットパターンをシグナリングするように構成されてもよい。例えば、開始割り当てが１ビット（ＭＳＢビット）を用いて示され、終了割り当てもまた１ビットを用いて示される場合（ＬＳＢビット）、値「１０」が開始割り当てを示し、値「００」が任意の中間割り当てを示し、値「０１」（又は「１１」）が（一連の割り当てにおいて）終了割り当てを示す。したがって、この場合、「１１」は、単一のスケジューリング割り当てを示す（１つの割り当ての「シーケンス」の開始及び終了の両方を示す）。
【００６２】
＜複数のサブフレーム当たり１つのＤＣＩ＞
第２のオプションでは、（スケジューリングモジュール６４を使用して）基地局５は、特定の通信デバイス３に対して、１つのＤＣＩフォーマットを使用して複数のダウンリンクサブフレームにおけるダウンリンク送信をスケジューリングするように構成される（つまり、スケジューリングされるサブフレームのシーケンス当たり１つのＤＣＩ）。このように、ダウンリンクデータを当該通信デバイス３に運ぶサブフレームのシーケンスをスケジューリングする場合、基地局５（スケジューリングモジュール６４）は、ＭＰＤＣＣＨ７０（又は非ＭＴＣ  ＵＥの場合ＰＤＣＣＨ）において、サブフレームのスケジューリングされたシーケンスを識別する適切に設定されたＤＣＩフォーマットを生成し、送信する（また、シーケンスの各サブフレーム内で割り当てられたダウリンクリソース、つまり、ＰＲＢも示す）。通信デバイス３は、（ＨＤ−ＦＤＤ受信モードにあるその受信機３１を使用して）、ＭＰＤＣＣＨ７０を待ち受ける（listening）ことにより、ＤＣＩフォーマットを受信し、（その通信制御モジュール４２を使用して）受信されたＤＣＩフォーマットを処理することによりダウンリンク割り当て（どのサブフレーム／ＰＲＢ）を決定する。依然としてＨＤ−ＦＤＤ受信モードにある間、通信デバイス３は、ＰＤＳＣＨ７１を介して、受信されたＤＣＩフォーマットにより示される各ダウンリンクサブフレーム内のダウンリンクデータを受信する。
【００６３】
例示的な実装が例示の目的で図６に示されている。この例では、通信デバイス３は、ダウンリンクサブフレームにおいて、ＭＰＤＣＣＨ７０を介してＤＣＩフォーマットを受信し、このＤＣＩフォーマットは、通信デバイス３に、４つの連続するダウンリンクサブフレームにおいてリソースを割り当てる。したがって、この例では、（ＨＤ−ＦＤＤ受信モードにあるそのトランシーバ３１を備える）通信デバイス３は、ＤＣＩフォーマットにより識別される４つのサブフレームの割り当てられたＰＤＳＣＨ７１リソースにおいてダウンリンクデータを受信するように試行する。
【００６４】
そして、ＨＡＲＱバンドリングを用いて、（そのＨＡＲＱモジュール４４を使用して）通信デバイス３は、全てのスケジューリングされたダウンリンク送信が正常に受信された場合、「ＡＣＫ」を生成し、（ＰＵＣＣＨ７２を介して）送信し、１又は複数のスケジューリングされたダウンリンク送信が正しく受信されなかった場合、「ＮＡＣＫ」を生成し、送信する。具体的には、図６に示す例では、通信デバイス３がインデックス「ｎ」のアップリンクサブフレームにおいて、ＰＵＣＣＨ７２を介してバンドリングされたＨＡＲＱフィードバックを送信する必要がある場合、この特定の通信デバイス３への最後にスケジューリングされたダウンリンク送信は、インデックス「ｎ−４」のダウンリンクサブフレームのためにスケジューリングされる。したがって、通信デバイス３がサブフレーム「ｎ−４」の後にいずれのＤＣＩフォーマットも受信しない場合、通信デバイス３は、サブフレーム「ｎ」の前に送信モードを変更するための十分な時間を有する。
【００６５】
単一のＤＣＩフォーマットを介した複数のサブフレームをスケジューリングすることは、別個のＤＣＩフォーマットを介してサブフレーム毎にスケジューリングすることと比較して、ダウンリンクサブフレームからアップリンクサブフレームへの頻繁な切り替えを回避することを可能とし、またダウンリンクデータレートを（実質的に２倍に）改善することは理解出来るであろう。
【００６６】
この場合、ＤＣＩフォーマットは、その特定の通信デバイス３にスケジューリングされるサブフレームの数を示すように構成されてもよい。特定の通信デバイス３のためにスケジューリングされるサブフレームの数（例えば、最大４サブフレームまでを示すための２ビットのシグナリング）を示すために、適切なシグナリング情報がＤＣＩフォーマットに含まれてもよいことは理解されるであろう。この場合、例として２ビットを使用するとき、シグナリングされる値は、表２に従って割り当てられたサブフレームの数を示してもよい。
【表２】
2020120412.tif 000005
【００６７】
特定の通信デバイス３のためにスケジューリングされるサブフレームの数は、例えば、その通信デバイス３のチャネル状態、全体的なシステム負荷、要求されるサービス品質、通信デバイスの能力、及び／又は同様のものに依存してもよいことは理解されるであろう。
【００６８】
単一のＤＣＩフォーマットを介して複数のサブフレームをスケジューリングする場合、基地局５は、（異なるＵＥに対して異なり得る）以下の可能性のうちの１つを実装するように構成されてもよい：
−サブフレーム毎に比較的小さいトランスポートブロック（ＴＢ：transport block）を送信する（例えば、所定の狭帯域における単一のサブフレームの容量よりも大きくないＴＢ）。この場合、ＭＰＤＣＣＨ及びＰＤＳＣＨは、各ＴＢに対して別々であるので、通信デバイスは、ＴＢに含まれるデータの早期復号の利益を得ることが出来る可能性がある。
−複数のサブフレームにおいて比較的大きなＴＢを送信する（例えば、所定の狭帯域における単一のサブフレームの容量よりも大きいＴＢ）。この場合、有利には、より大きいＴＢサイズのためにチャネル符号化利得がある。
【００６９】
有利なことに、バンドリングされたＨＡＲＱフィードバックと共に、上記のＤＣＩフォーマットのうちの１つを使用して、基地局５は、効率的にかつ柔軟な方法で、特定の通信デバイス３のための比較的大量のリソースをスケジューリングすることができ、任意のデータがその通信デバイス３に再送信される必要があるかどうかを決定することができる。
【００７０】
動作−ＰＤＳＣＨ／ＰＵＳＣＨチャネル帯域幅
より高いデータレートのサポートはまた、いずれのカバレッジ拡張をせずに又はわずかなカバレッジ拡張のみで動作する（「ＣＥモードＡ」動作として称される）ＭＴＣデバイス（及び他の互換性のあるユーザ装置）のための少なくともＨＤ−ＦＤＤに対して、増加された帯域幅（つまり、１．４ＭＨｚよりも高い帯域幅）でＰＤＳＣＨ／ＰＵＳＣＨを動作するように基地局５を構成することにより実現されてもよい。適切であれば、増加されたＰＤＳＣＨ／ＰＵＳＣＨ帯域幅を使用するというオプションは、バンドリングされたＨＡＲＱフィードバック手法と組み合わされてもよいことは理解されるであろう。
【００７１】
３ＧＰＰ会合における最近の議論に基づいて、ユニキャストトラフィックに対するターゲットデータレートは、（ＦＤ−ＦＤＤの）ＵＬ／ＤＬそれぞれについて、３Ｍｂｐｓ／２Ｍｂｐｓよりも小さくすべきではないことは理解されるであろう。しかし、そのようなピークデータレートは、１．４ＭＨｚの現在のｅＭＴＣ指定ＵＥ帯域幅を使用して提供することができる少なくとも２倍のデータレートが必要となる。
【００７２】
そのようなより広い帯域幅／高いデータレート動作は、以下の方法によりサービング基地局５により可能にされ得ることは理解されるであろう：
−半静的（Semi-statically）（例えば、ＲＲＣを介して）：通信デバイス３（ＭＴＣデバイス又は他のＵＥ）がこの機能を使用することができると（例えば、ＭＴＣデバイスからのシグナリングに基づいて）サービング基地局５が決定する場合、基地局５は、その受信及び／又は送信に対して（１．４ＭＨｚよりも広い）より広い帯域幅を使用するように（例えば、適切なＲＲＣシグナリングを介して）通信デバイス３を設定してもよい。例えば、帯域幅は、１．４ＭＨｚの倍数に設定されてもよい。しかし、この場合、特定の帯域幅を使用するように設定されると、（例えば、６ＰＲＢよりも少ないか又は等しい）少数のＲＢのみが、所定のスケジューリングラウンドにおいて（又は所定の時間期間内において）、当該通信デバイス３のためにスケジューリングされている場合でさえ、通信デバイス３は、（１．４ＭＨｚ／６ＰＲＢよりも広い可能性がある）その帯域幅を受信のために維持する。少なくとも、基地局５から（異なる帯域幅に設定する）さらなるＲＲＣメッセージを受信するまで、又は（ＭＴＣデバイスがデフォルト１．４ＭＨｚ構成に切り戻る可能性がある）ＭＴＣデバイスが異なるセルに移動するまで、通信デバイス３は、その設定された帯域幅を維持してもよいことは理解されるであろう。これは、通信デバイスの電力小異の観点から理想的ではないかもしれないが、この手法は、サービング基地局５に保持された設定と通信デバイス３に保持された設定との間の矛盾を回避する。
−動的（Dynamically）（例えば、ＤＣＩフォーマットを介して）：通信デバイス３（ＭＴＣデバイス又は他のＵＥ）がこの機能を使用することができるとサービング基地局が決定する場合、基地局５は、１．４ＭＨｚ（最大６ＰＲＢ）の通常の狭帯域又は（６ＰＲＢよりも大きい）より広い狭帯域のいずれかを動的に割り当てるように構成されてもよい。基地局は、例えば、（スケジューリングラウンドにおいてその通信デバイス３の「狭帯域」に含まれるＰＲＢの数を識別する）適切に設定されたＤＣＩフォーマットシグナリングを使用して、通信デバイス３へのリソース割り当てを生成し、シグナリングすることによりそのようにしてもよい。有利なことに、そのような動的（ＤＣＩベースの）シグナリングは、通常の（１．４ＭＨｚ）狭帯域に要求されるブラインドデコーディングの量と比較して、通信端末３がＭＰＤＣＣＨのブラインドデコーディングの数を増やすことを必要としない。この場合、帯域幅は動的に変更されるため、通信デバイス３は、（６ＰＲＢよりも大きくない）少数のＰＲＢがその通信デバイス３に割り当てられている場合、通常の狭帯域動作にフォールバックすることができるので、パワーセービング／電力最適化からも利益を得る可能性がある。
【００７３】
以下は、（半静的に又は動的に）最大ＰＤＳＣＨ／ＰＵＳＣＨチャネル帯域幅を増加することにより、互換性のあるＭＴＣデバイス（及び他のユーザ装置）に対してより高いデータレートを実現し得るいくつかの可能な方法の説明である。これらのオプションは、時分割複信（ＴＤＤ：Time Division Duplex）、ＨＤ−ＦＤＤ、及びＦＤ−ＦＤＤ送信にも適用可能であることは理解されるであろう。
【００７４】
＜狭帯域を定義するためのレガシーシステム帯域幅の使用＞
１つのオプションでは、基地局５は、その狭帯域に対しても１．４ＭＨｚ、３ＭＨｚ及び５ＭＨｚのレガシー（つまり、Ｒｅｌ−１３以前の）システム帯域幅を再利用するように構成されてもよい。しかし、この場合、（例えば、第２及び第３のＵＥカテゴリの）いくつかのＭＴＣデバイスは、この基地局５のいくつかの狭帯域構成（つまり、そのような６ＰＲＢ／１．４ＭＨｚを超える「拡張」狭帯域）と互換性がない可能性がある。したがって、基地局５は、１．４ＭＨｚを超えないこれらの狭帯域のみにおいて、第２及び第３のＵＥカテゴリのＭＴＣデバイスをスケジューリングし、任意の狭帯域において（より高いデータレートが要求される場合、３ＭＨｚ及び／又は５ＭＨｚが好ましい）、（例えば、第４のＵＥカテゴリの）より拡張されたＭＴＣデバイス、及び（第１のＵＥカテゴリの）従来のＵＥをスケジューリングするように構成されてもよい。
【００７５】
＜狭帯域の統合（Aggregating）＞
他のオプションでは、基地局５は、（例えば、第４のＵＥカテゴリの）より拡張されたＭＴＣデバイス及び（第１のＵＥカテゴリの）従来のＵＥに対して（それぞれ６ＲＢ／１．４ＭＨｚの）複数の狭帯域を統合する（aggregate）ように構成されてもよい。この場合、（例えば、第２及び第３のＵＥカテゴリの）他のＭＴＣデバイスのための送信は、依然として単一の狭帯域に対して（つまり、狭帯域のいずれの統合もなしに）スケジューリングされることができる。有利なことに、各互換性のあるＵＥ／ＭＴＣデバイスは、（例えば、特定の通信デバイス３のデータレート要求を満たすために、２又は複数の連続する狭帯域が統合される可能性がある等）高いデータレートを必要とするときはいつでも、より大きな送信又は受信帯域幅を使用するように構成されてもよい。この場合、そのデータレートの必要性に応じて、特定の無線周波数及び特定のベースバンド帯域（例えば、１．４ＭＨｚよりも高いが、そのデバイスによりサポートされる最大帯域幅を超えない）を使用するために、各通信デバイスは、半静的に又は動的にスケジューリングされてもよい。
【００７６】
このオプションに従う場合、（狭帯域モジュール６３を使用して）基地局５は、無線リソース制御（ＲＲＣ：radio resource control）シグナリングを使用して、半静的に、特定の通信デバイス３に対して、複数の狭帯域を統合してもよい。適切である場合、基地局５はまた、統合された狭帯域の数を変更することにより、通信デバイス３に対してＵＥ帯域幅を変更することができる。この場合、（スケジューリングモジュール６４により）リソース割り当ては、ＲＲＣシグナリングにより設定された狭帯域の数に基づいてもよい。リソース割り当て指示は、例えば、式log 2(N RB(N RB+1)/2)等により与えられてもよい。この手法に関連する利点は、通信デバイス３による電力消費を低減することができることである。
【００７７】
このオプションの変形として、１．４ＭＨｚ狭帯域の代わりに、基地局５は、互換性のあるデバイス（例えば、第４のＵＥカテゴリの拡張されたＭＴＣデバイス及び第１のＵＥカテゴリの従来のＵＥ）に対してそれぞれ５ＭＨｚの複数のサブバンドを統合するように構成されてもよい。この場合、システム帯域幅は、複数の５ＭＨｚサブバンドに分割されてもよく、各サブバンドはそれ自体が別々のリソース割り当てを有する。この場合、基地局５は、割り当てられたサブバンドのインデックス及びそのサブバンド内のＲＢをスケジューリングされる通信デバイスに指示する（indicate）ように構成されてもよい。
【００７８】
あるいは、図７に一般的に示すように、スケジューリングインスタンスにおいて、（図７の「ＵＥ１」と示される）特定の通信デバイス３に割り当てられた帯域幅（つまり、狭帯域アグリゲーションのレベル）を指示するために、（スケジューリングモジュール６４を使用して）基地局５は、（ＤＣＩフォーマットの変形に基づいて）ＭＰＤＣＣＨ７０を介して動的シグナリングを使用してもよい。図７において、列は連続したサブフレームを表し、行はシステム帯域幅における狭帯域を表す（各狭帯域は、それぞれ「０」及び「７」の間の関連インデックスを有する）。この例では、各狭帯域の帯域幅（したがってＭＰＤＣＣＨ７０の帯域幅）は、６ＲＢ（１．４ＭＨｚ）であり、つまり、Ｒｅｌ−１３  ｅＭＴＣに対して定義された狭帯域の帯域幅と同じである。
【００７９】
この場合、ＤＣＩフォーマットは、当該ＤＣＩフォーマットに割り当てられた狭帯域の数を示す情報を含む。例えば、表３に示すように、２ビットの情報が、割り当てられた狭帯域の数を示してもよい（最大４つの狭帯域、つまり４ｘ６＝２４ＲＢ）。
【表３】
2020120412.tif 000006
【００８０】
そのため、（例えば、式log 2(N RB(N RB+1)/2))により与えられる）リソース割り当て指示は、ＤＣＩフォーマットにおいてシグナリングされる狭帯域の数に基づいてもよい。
【００８１】
この動的シグナリングの変形を図８に示す。この場合、ＤＣＩフォーマットは、特定の通信デバイス３にそのスケジューリングインスタンスにおいて割り当てられた開始狭帯域及び連続するＰＲＢの数を示す情報を含む。有益なことに、（部分的な）狭帯域アグリゲーションは、（上記のように６ＰＲＢと対比して）１ＰＲＢステップとすることができるため、この手法は、より段階的なリソース割り当てを可能にする。この場合、（例えば、式log 2(N RB(N RB+1)/2))により与えられる）リソース割り当て指示は、開始ＰＲＢ及び割り当てられた連続ＰＲＢの数を示す。開始ＰＲＢは、（開始狭帯域の最初のＰＲＢから計算される）最大サポートＵＥ帯域幅内のどこにでも割り当てられることができることは理解されるであろう。必要であれば、基地局５は、例えば、周波数選択スケジューリングを可能にするために、動的に開始狭帯域をシグナリングするように構成されてもよい。したがって、開始狭帯域は、所定のリソース割り当ての開始ＰＲＢを含む狭帯域であり得る。
【００８２】
より詳細には、ＰＤＳＣＨ／ＰＵＳＣＨのリソース割り当ては、所定の通信デバイス３に対して割り当てられた、開始狭帯域のインデックス及び連続ＲＢの数を含んでもよい。リソース割り当ては、例えば、３ＧＰＰ  ＴＳ  ３６．２１２  Ｖ１３．２．０のセクション５．３．３．１．１０に定義されている「ＤＣＩフォーマット６−０Ａ」等のレガシーｅＭＴＣリソース割り当て方法を再利用することにより実施されてもよい。この再利用されるリソース割り当ては、以下の式に基づく。
【数２】
2020120412.tif 000007
【００８３】
（開始狭帯域のインデックスにより自動的に与えられる）開始ＲＢを考慮しないと、５ビットは、２５ＲＢ（５ＭＨｚ）よりも多くを表すことができることは理解されるであろう。しかし、この場合、５ＭＨｚ（２５ＲＢ）の最大帯域幅を割り当てるために、リソース割り当て式の＋５ビットは、以下により与えられる。
【数３】
2020120412.tif 000008
そのため、有益なことに、この修正されたリソース割り当て方法は、（ＤＣＩフォーマット６−０Ａ等の）レガシーＲｅｌ−１３  ｅＭＴＣリソース割り当てのサイズに影響を及ぼさない。
【００８４】
したがって、上記のリソース割り当て方法を適用する場合、Ｒｅｌ−１３  ｅＭＴＣ及びＦｅＭＴＣリソース割り当てのためのＤＣＩサイズは、同じになるであろう。有利なことに、通信デバイス３が２つのＤＣＩフォーマットの間を区別することができるように、どのＤＣＩフォーマットがサービング基地局５により使用されるかを決定するために以下の技術が使用されてもよい。
【００８５】
第１のオプションでは、基地局５（及び通信デバイス３）は、２つのタイプのＤＣＩフォーマットを区別するために、（レガシー）フィールド「周波数ホッピングフラグ−１ビット」を使用するように構成されてもよい。１．４ＭＨｚよりも大きいＰＤＳＣＨ／ＰＵＳＣＨの帯域幅をサポートする通信デバイス３が周波数ホッピングを要求しないか、又は周波数ホッピングが要求される場合、周波数ホッピングがＤＣＩフォーマットを動的に使用する代わりに高いレイヤ（ＲＲＣシグナリング）のみを使用して有効もしくは無効にすることが出来ることができるので、これは可能である。したがって、通信デバイス３（ＭＴＣデバイス／ＵＥ）が基地局５に１．４ＭＨｚよりも大きいＰＤＳＣＨ／ＰＵＳＣＨの帯域幅をサポートすることを報告する場合、基地局５（及び通信デバイス３）は、（周波数ホッピングが採用されているか否かを示すのではなく）２つのタイプのＤＣＩフォーマットを区別するために、「周波数ホッピングフラグ−１ビット」フィールドを使用するように構成されてもよい。例えば、「周波数ホッピングフラグ−１ビット」が特定の値（例えば、「１」）に設定されている場合、上述した修正されたＤＣＩフォーマットが使用されていることを示すと解釈することができ、当該フラグが異なる値（例えば、「０」）に設定されている場合、レガシーＤＣＩフォーマットが使用されていることを示すと解釈することができる（もしくはその逆）。
【００８６】
第２のオプションでは、２つのタイプのＤＣＩフォーマット（レガシーＤＣＩフォーマット及び修正されたＤＣＩフォーマット）を区別するために、基地局５（及び通信デバイス３）は、「周波数ホッピングフラグ−１ビット」及び「繰り返し数−２ビット」フィールドを使用するように構成されてもよい。（「繰り返し数−２ビット」フィールドを介して設定された）繰り返しが、周波数ホッピングと共により大きいダイバーシチゲインを達成することができるので、これは可能である。したがって、このオプションでは、「周波数ホッピングフラグ−１ビット」フィールドは、繰り返しが特定の通信デバイス３に対しても設定する場合にのみ周波数ホッピングを示す。しかし、ＰＤＳＣＨ／ＰＵＳＣＨが時間領域において繰り返さない限り（適切にフォーマットされた「繰り返し数−２ビット」フィールドが繰り返さないことを示す場合）、「周波数ホッピングフラグ−１ビット」フィールドは、（例えば、第１のオプションについて上記で説明した方法で）２つのＤＣＩフォーマットを区別するために使用されてもよい。第２のオプションの結果は、ＰＤＳＣＨ／ＰＵＳＣＨのより大きい帯域幅は、時間領域において繰り返しがない場合にのみ使用されることである。繰り返し数が「１」、つまり、値「００」に設定されている場合、例えば、ホッピングフラグ（hopping flag）（１ビット）＝「１」がレガシーＲｅｌ−１３  ＤＣＩフォーマットを意味すると解釈でき、フラグ（flag）＝「０」がより大きい帯域幅の新しいＲｅｌ−１４（修正された）ＤＣＩフォーマットを意味すると解釈することができる。「繰り返し数」フィールドに関するより詳細は、３ＧＰＰ  ＴＳ  ３６．２１３  Ｖ１３．２．０のセクション８に見出すことができる。
【００８７】
他の例では、基地局５は、狭帯域通信デバイス３に対してレガシーリソース割り当てを使用するように構成されてもよいが、特定の通信デバイス３に対する合計割り当て（total assignment）を最大２５ＲＢ（５ＭＨｚ）に制限するように構成されてもよい。有益なことに、この場合、ＰＤＳＣＨ／ＰＵＳＣＨリソース割り当ては、（狭帯域の帯域幅ではなく）基地局のシステム帯域幅に基づくことができる。したがって、これは、（ＵＥ毎の合計割り当てが２５ＲＢを超えない）ダウンリンクリソース割り当て「タイプ２」及びアップリンクリソース割り当て「タイプ０」のようなレガシーリソース割り当て方式を再利用することを可能にする。
【００８８】
ＰＵＣＣＨ送信の開始の決定
特に有利な例では、（例えば、ＨＤ−ＦＤＤの場合のＣＥモードＡにおいて）ＨＡＲＱ−ＡＣＫバンドリングのためにＰＵＣＣＨ送信が開始する適切なサブフレームを決定するために、以下の手法が採用されてもよい。この例は、（繰り返しあり及び繰り返しなしの）ＰＵＣＣＨ送信の全ての場合に適用されてもよい。
【００８９】
この例では、基地局５は、一連のダウンリンクサブフレームにおいて、通信デバイス３に多数のデータバンドル（例えば、ＰＤＳＣＨバンドル）を送信する。通信デバイス３は、各データバンドルに対して、それぞれのバンドリングされたＡＣＫ／ＮＡＣＫを提供するように構成される。有益なことに、通信デバイス３及び基地局５は、その特定の通信デバイス３に適用可能なバンドリング設定に基づいて（例えば、最後のデータバンドルが送信された最後のサブフレーム、データバンドルの数、及びデータバンドルの送信が繰り返されているか否かに基づいて）、最初のＰＤＳＣＨバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックが予想される、適切な開始サブフレームを決定することができる。そのため、最初のバンドリングされたＡＣＫ／ＮＡＣＫ送信の適切な開始サブフレームを決定することにより、通信デバイス３及び基地局５は、どのサブフレームにおいてどのＡＣＫ／ＮＡＣＫが送信されるかの共通の理解を有する。したがって、（適切な場合、繰り返しがある）最初のＰＤＳＣＨバンドルに対するＡＣＫ／ＮＡＣＫを送信した後に、通信デバイス３は、正しいサブフレームにおいて、任意のさらなるＰＤＳＣＨバンドルに対するＡＣＫ／ＮＡＣＫフィードバックを送信することに進むことができる。
【００９０】
より詳細には、通信デバイス３（例えば、ＭＴＣ  ＵＥ３−２）は、最初に受信されたＰＤＳＣＨバンドルに対するＨＡＲＱ−ＡＣＫから開始し、各ＰＤＳＣＨバンドルに対してＰＵＣＣＨにおいて適切なＨＡＲＱ−ＡＣＫ応答を順に送信するように構成される。この場合、
【数４】
2020120412.tif 000009
ＰＵＣＣＨ送信は、通信デバイス３がＰＵＣＣＨ送信を延期する任意の非ＢＬ／ＣＥ  ＵＬサブフレームを含む、
【数５】
2020120412.tif 000010
連続したサブフレームに及ぶ（span）ことは理解されるであろう。例えば、インデックスがｎ−４のサブフレームが、最後のバンドルのＰＤＳＣＨが通信デバイス３により受信される最後のサブフレームである場合、最初のＰＵＣＣＨ送信は、以下の式によって与えられるインデックスを有するサブフレームから始まる：
【数６】
2020120412.tif 000011
Ｎbundleは、通信デバイス３が受信したバンドルの数（つまり、ＨＡＲＱフィードバックが提供される必要があるバンドルの数）であり；
【数７】
2020120412.tif 000012
は、（各バンドルが適用可能な）単一のバンドルのＰＵＣＣＨ繰り返しの数であり；
【数８】
2020120412.tif 000013
は、全てのＰＵＣＣＨ送信が及ぶ（span）（任意の非ＢＬ／ＣＥ  ＵＬサブフレームを含む）絶対連続サブフレームの総数である。
【００９１】
狭帯域
図９は、図１に示すシステムにおいてＭＴＣデバイス互換狭帯域が提供される例示的な方法を示す。
【００９２】
「拡張」ＭＴＣ（ｅＭＴＣ）のフレームワークの一部として、３ＧＰＰは、ＭＴＣ固有の狭帯域を以下のように定義した：
−各狭帯域のサイズは６ＰＲＢである；
−システム帯域幅においてダウンリンク（ＤＬ）狭帯域の総数（ＮＢｗｈｏｌｅ）は、
【数９】
2020120412.tif 000014
として定義される；
−システム帯域幅においてアップリンク（ＵＬ）狭帯域の総数（ＮＢｗｈｏｌｅ）は、
【数１０】
2020120412.tif 000015
として定義される；
−（任意の狭帯域の一部を形成していない）残りのリソースブロックは、システム帯域幅の両端において均等に分割され（つまり、システム帯域幅の最も低い周波数付近と、最も高い周波数付近で同数のＲＢとして分割され）、システム帯域幅（例えば、３、５及び１５ＭＨｚシステム帯域幅）の追加の奇数ＰＲＢはシステム帯域幅の中心に位置する。
−狭帯域は、ＰＲＢ番号が大きい順に番号が付けられる。
注：
【数１１】
2020120412.tif 000016
は、システム帯域幅のＰＲＢの数を表す（それぞれ、ダウンリンク及びアップリンクを表す）。
【００９３】
図９に示すように、各狭帯域は、６個のリソースブロックを含み、周波数帯域幅の端部（edges）に均等に分配される、いくつかの残りのリソースブロック（６個のリソースブロックよりも少ない）がある。システム帯域幅は、合計
【数１２】
2020120412.tif 000017
を含み、
各ＰＲＢは、
【数１３】
2020120412.tif 000018
の範囲のそれぞれの関連するリソースブロックを有する。この例では、合計８個の狭帯域があり、各々が、０と７との間のそれぞれの関連するインデックスを有し、ＰＲＢ番号が増加する順に番号が付けられている。
【００９４】
具体的には、システム帯域幅内の狭帯域の総数は、以下の式を用いて定義される：
【数１４】
2020120412.tif 000019
ここで、ＮＢｗｈｏｌｅは、システム帯域幅内の１．４ＭＨｚ狭帯域の総数（各狭帯域は６ＰＲＢで構成される）であり；
【数１５】
2020120412.tif 000020
は、システム帯域幅内のダウンリンク（ＤＬ）リソースブロックの総数であり；
【数１６】
2020120412.tif 000021
は、フローリング関数である（つまり、「ｘ」よりも大きくない最大の整数である。
【００９５】
この例では、基地局５のセル内の（ダウンリンク）システム帯域幅は、約１０ＭＨｚの周波数帯域幅に対応する、
【数１７】
2020120412.tif 000022
である。各狭帯域は、６ＰＲＢ（つまり、帯域幅が制限されたＭＴＣデバイスが使用することができるＰＲＢの最大数）を含む。したがって、システム帯域幅のうち合計４８ＰＲＢを占める最大８つの全狭帯域を提供することができる（つまり、ＮＢｗｈｏｌｅ＝８）。さらに、残りのリソースブロックは、（システム帯域幅の端部において）それぞれ１つのＰＲＢを含む、２つの「部分的な狭帯域」に分割される。適切であれば、これらの残りのリソースブロックもまた、互換性のあるＭＴＣデバイス（又は他のユーザ装置）に割り当てられてもよいことは理解されるであろう。あるいは、残りのリソースブロックは、他のＵＥによる使用（例えば、非ＭＴＣ使用）及び／又は制御データの送信のために割り当てられてもよい。
【００９６】
有利なことに、狭帯域インデックス番号は、ＭＴＣデバイスへの狭帯域の効率的な割り当てを容易にする。この例では、インデックスは、ＰＲＢ番号が増加する順に配列されている。図９には示さないが、部分的な狭帯域もまた、（例えば、ＮＢ−ＩｏＴデバイスへの割り当てのために）それら自身のそれぞれのインデックス番号が与えられてもよいことは理解されるであろう。
【００９７】
変形及び代替
上記において詳細な例示的な実施形態を説明した。当業者であれば理解できるように、具体化された本発明から以前として利益を受けるが、上述した実施形態に対して多くの変形及び代替を行うことができる。
【００９８】
通信システムは、Ｅ−ＵＴＲＡＮ基地局（ｅＮＢ）として動作する基地局に関して説明されているが、同じ原理がマクロ又はピコ基地局、フェムト基地局、基地局機能の要素を提供する中継ノード、ホーム基地局（ＨｅＮＢ）もしくは他のそのような通信ノードとして動作する基地局に適用されてもよいことは理解されるであろう。
【００９９】
上記の例示的な実施形態では、ＬＴＥ電気通信システムが説明された。当業者には理解されるように、本出願において説明された技術は、以前の３ＧＰＰタイプのシステムを含む、他の通信システムに提供することができる。他の通信ノード又はデバイスは、例えば、パーソナルデジタルアシスタント、ラップトップコンピュータ、ウェブブラウザ等のユーザデバイスを含んでもよい。
【０１００】
上述した例示的な実施形態では、基地局及び通信デバイスはそれぞれトランシーバ回路を含む。典型的に、この回路は、専用のハードウェアにより形成される。しかし、いくつかの例示的な実施形態では、トランシーバ回路の一部は、対応するコントローラにより実行されるソフトウェアとして実装されてもよい。
【０１０１】
上記の例示的な実施形態では、いくつかのソフトウェアモジュールが説明された。当業者には理解されるように、ソフトウェアモジュールは、コンパイルされた又はコンパイルされていない形式で提供されてもよく、コンピュータネットワーク上の信号として、又は記録媒体において、基地局又は通信デバイスに供給されてもよい。さらに、このソフトウェアの一部又は全部により実行される機能は、１又は複数の専用のハードウェア回路を使用して実行されてもよい。
【０１０２】
例えば、本明細書に記載された機能及び／又はモジュールは、必要な機能を提供するための適切なソフトウェア命令を使用してプログラムされた１又は複数のハードウェアコンピュータプロセッサを有する１又は複数のコンピュータ処理装置を使用して実装されてもよい（例えば、図２又は図３を参照して説明したコントローラの一部を形成する１又は複数のコンピュータプロセッサ等）。さらに、これらの機能の全部又は一部は、例えば、特定用途向け集積回路（ＡＳＩＣ）等の１又は複数の専用集積回路を使用して、専用回路としてハードウェアに実装されてもよいことは理解されるであろう。
【０１０３】
ＵＥ及び基地局の説明において（つまり、図２及び３を参照した）参照されたコントローラは、例えば、アナログ又はデジタルコントローラ等の任意の適切なコントローラを含んでもよい。各コントローラは、例えば、（これらに限定されないが）次のものを含む任意の適切な形態の処理回路を含んでもよい：１又は複数のハードウェア実装コンピュータプロセッサ；中央処理装置（ＣＰＵ）；算術論理回路（ＡＬＵ）；入出力（ＩＯ）回路；内部メモリ／キャッシュ（プログラム及び／又はデータ）；処理レジスタ；通信バス（例えば、制御、データ及び／又はアドレスバス）；ダイレクトメモリアクセス（ＤＭＡ）機能；ハードウェア又はソフトウェア実装カウンタ、ポインタ及び／又は同様のもの。
【０１０４】
上記の例示的な実施形態では、マシンタイプ通信デバイス及び携帯電話について説明した。しかし、携帯電話（及び同様のユーザ装置）もマシンタイプ通信デバイスとして動作するように構成されてもよい。例えば、携帯電話３−１は、ＭＴＣモジュール４５を含んでもよい（及び／又はＭＴＣモジュール４５の機能を提供してもよい）。
【０１０５】
＜ＭＴＣアプリケーションの例＞
各通信デバイスは、１又は複数のＭＴＣアプリケーションをサポートしてもよいことは理解されるであろう。ＭＴＣアプリケーションのいくつかの例が以下の表にリスト化される（ソース：３ＧＰＰ  ＴＳ  ２２．３６８  Ｖ１３．１．０、ＡｎｎｅｘＢ）。このリストは、網羅的なものではなく、マシンタイプ通信アプリケーションのスコープを示すためのものである。
【表４】
2020120412.tif 000023
【０１０６】
複数のサブフレームの全てのサブフレームにおいてマシンタイプ通信デバイスに送信されたデータが正常に受信された場合、ＡＣＫ／ＮＡＣＫ指示は、肯定応答（ＡＣＫ）を含んでもよく、複数のサブフレームの１つのサブフレームにおいてマシンタイプ通信デバイスに送信されたデータが正常に受信されなかった場合、ＡＣＫ／ＮＡＣＫ指示は、否定応答（ＮＡＣＫ）を含んでもよい。
【０１０７】
制御情報は、複数のサブフレームの各々において通信リソースを割り当てるための単一のダウンリンク制御指示を含んでもよい。この場合、複数のサブフレームは、単一の狭帯域内の複数の連続するサブフレームを含んでもよい。
【０１０８】
制御情報は、複数のサブフレームの各サブフレームについて、当該サブフレーム内にＰＲＢのセットを割り当てるためのそれぞれのダウンリンク制御情報（ＤＣＩ）フォーマットを含んでもよい。この場合、制御情報は、各サブフレームについて、通信デバイスがフィードバックを提供することが要求される前に、通信リソースが通信デバイスのために割り当てられるサブフレームの総数又は残りの数を示す情報（例えば、ダウンリンク割り当てインデックス、ＤＡＩ：downlink assignment index）を含んでもよい。
【０１０９】
制御情報は、複数のサブフレームの開始サブフレーム；複数のサブフレームの終了サブフレーム；複数のサブフレームにおけるサブフレームの数、の少なくとも１つを識別する情報を含んでもよい。
【０１１０】
フィードバックが送信されるサブフレームは複数のサブフレームの最後に続くサブフレームの予め決定された数（例えば、４）であってもよい。フィードバックは、バンドリングされたハイブリッドオートマチックリピートリクエスト、ＨＡＲＱ、フィードバックを含んでもよい。
【０１１１】
基地局のトランシーバは、マシンタイプ通信（ＭＴＣ：machine-type communication）固有の物理ダウンリンク制御情報（ＭＰＤＣＣＨ：Physical Downlink Control Channel）を使用して生成された制御情報を送信するように（及び、マシンタイプ通信デバイスのトランシーバが受信するように）動作可能であってもよい。
【０１１２】
基地局は、ロングタームエボリューション（ＬＴＥ：long term evolution）無線アクセスネットワークの基地局を含んでよい。マシンタイプ通信デバイスのトランシーバは、セル帯域幅と比較して低減された帯域幅を使用して通信するように動作可能であってもよい。
【０１１３】
１つの可能性において、制御情報は、複数のサブフレームの各々において通信リソースを割り当てるための１つのダウンリンク制御指示（downlink control indication）を含んでもよい；トランシーバは、マシンタイプ通信デバイスから、当該マシンタイプ通信デバイスに送信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを受信するように動作可能であり得る；そして、ＡＣＫ／ＮＡＣＫフィードバックは、複数のサブフレームにおいて送信されたデータを受け取ったことを通知するための単一のＡＣＫ／ＮＡＣＫフィードバックを含んでもよい。
【０１１４】
制御情報は、同一のサブフレームの複数の狭帯域の各々において通信リソースを割り当てるための１つのダウンリンク制御指示を含んでもよい；そして、複数の狭帯域は、複数の連続する狭帯域を含んでもよい。
【０１１５】
通信リソースは、物理リソースブロック（ＰＲＢ：physical resource block）を含んでもよく、制御情報は、開始ＰＲＢ及び開始ＰＲＢから通信デバイスに割り当てられた連続するＰＲＢの総数を識別してもよい。
【０１１６】
ダウンリンク制御指示は、同一のサブフレームの複数の狭帯域の各々における通信リソースを割り当てるためにレガシーＤＣＩフォーマット（例えば、修正されたＤＣＩフォーマット６−０Ａ）を再利用してもよい。再利用されるレガシーＤＣＩフォーマットは、最大「ｎ」個の連続するＰＲＢを割り当てるために、式
【数１８】
2020120412.tif 000024
を使用する。コントローラは、（レガシー）周波数ホッピングパラメータ及び（レガシー）繰り返し数パラメータの少なくとも１つの異なるそれぞれの設定を使用することにより、同一のサブフレームの複数の狭帯域の各々における通信リソースを割り当てるためのレガシーＤＣＩフォーマットの使用と、レガシー目的のためのレガシーＤＣＩフォーマットの使用とを区別するように動作可能であってもよい。
【０１１７】
各狭帯域は、所定数の（好ましくは６又は２５）の物理リソースブロック（ＰＲＢ）を含む異なるそれぞれの周波数範囲をカバーしてもよい。
【０１１８】
データは、多数のデータバンドル（例えば、ＰＤＳＣＨバンドル）で順に送信されてもよく、各データバンドルは、一連のダウンリンクサブフレームにおいて送信される。この場合、マシンタイプ通信デバイスは、各バンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックを含む、ＡＣＫ／ＮＡＣＫフィードバックを基地局に送信するように動作可能であってもよい。マシンタイプ通信デバイス及び基地局は、最後のデータバンドルが送信される最後のサブフレームに基づいて、最初のＰＤＳＣＨバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックが予想される開始サブフレーム、及びデータバンドルの送信が繰り返されるか否かを決定するように動作可能であってもよい。
【０１１９】
開始サブフレームは、以下の式に基づいて決定されてもよい：
【数１９】
2020120412.tif 000025
ここで、「ｎ」は、最後のデータバンドルが送信される最後のサブフレームに続く４番目のサブフレームであり；Ｎｂｕｎｄｌｅは、データバンドルの数であり；
【数２０】
2020120412.tif 000026
は、データバンドルが送信される回数である。
【０１２０】
様々な他の修正は、当業者には明らかであり、ここではさらに詳細は説明されない。
【０１２１】
上記の例示的な実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【０１２２】
（付記１）通信システムのための基地局であって、前記基地局は、
マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を生成するように動作可能なコントローラと、
前記マシンタイプ通信デバイスへの前記生成された制御情報を送信し、前記割り当てられた通信リソースを用いて前記マシンタイプ通信デバイスにデータを送信し、前記マシンタイプ通信デバイスに送信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを前記マシンタイプ通信デバイスから受信するように動作可能なトランシーバと、を含み、
前記データは、多数のデータバンドルで順に送信され（例えば、物理ダウンリンク共有チャネル「ＰＤＳＣＨ」バンドル）、各データバンドルは、一連のダウンリンクサブフレームにおいて送信され、
前記ＡＣＫ／ＮＡＣＫフィードバックは、各バンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックを含み、
前記コントローラは、最後のデータバンドルが送信された最後のサブフレームに基づいて、最初のＰＤＳＣＨバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックが予想される開始サブフレーム、データバンドル数、及び前記データバンドルの送信が繰り返されるか否かを決定するように動作可能である、基地局。
【０１２３】
（付記２）前記コントローラは、以下の式に基づいて、前記開始サブフレームを決定するように動作可能である、付記１に記載の基地局。
【数２１】
2020120412.tif 000027
ここで、「ｎ」は、前記最後のデータバンドルが送信された最後のサブフレームに続く４番目のサブフレームであり、Ｎｂｕｎｄｌｅは、データバンドル数であり；
【数２２】
2020120412.tif 000028
は、データバンドルが送信される回数である。
【０１２４】
（付記３）通信システムのための基地局であって、前記基地局は、
マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を生成するように動作可能であるコントローラと、
前記生成された制御情報を前記マシンタイプ通信デバイスに送信し、前記割り当てられた通信リソースを用いてデータを前記マシンタイプ通信デバイスにデータを送信し、前記マシンタイプ通信デバイスに送信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを前記マシンタイプ通信デバイスから受信するように動作可能であるトランシーバと、を含み、
前記ＡＣＫ／ＮＡＣＫフィードバックは、複数のサブフレームにおいて送信されたデータを受け取ったことを通知するための１つのＡＣＫ／ＮＡＣＫ指示を含む、基地局。
【０１２５】
（付記４）前記複数のサブフレームの全てのサブフレームにおいて前記マシンタイプ通信デバイスに送信されたデータが正常に受信された場合、前記ＡＣＫ／ＮＡＣＫ指示は、肯定応答（ＡＣＫ）を含み、前記複数のサブフレームの１つのサブフレームにおいて前記マシンタイプ通信デバイスに送信されたデータが正常に受信出来なかった場合、前記ＡＣＫ／ＮＡＣＫ指示は、否定応答（ＮＡＣＫ）を含む、付記３に記載の基地局。
【０１２６】
（付記５）前記制御情報は、前記複数のサブフレームの各々において通信リソースを割り当てるための単一のダウンリンク制御指示を含む、付記３又は４に記載の基地局。
【０１２７】
（付記６）前記複数のサブフレームは、単一の狭帯域内の複数の連続するサブフレームを含む、付記５に記載の基地局。
【０１２８】
（付記７）前記制御情報は、前記複数のサブフレームの各サブフレームについて、当該サブフレームにおいて物理リソースブロック（ＰＲＢ）のセットを割り当てるための、それぞれのダウンリンク制御情報（ＤＣＩ）を含む、付記３又は４に記載の基地局。
【０１２９】
（付記８）前記制御情報は、各サブフレームについて、前記通信デバイスがフィードバックを提供することを要求される前に、通信リソースが前記通信デバイスに割り当てられているサブフレームの総数又は残りの数を示す情報（例えば、ダウンリンク割り当てインデックス（ＤＡＩ：downlink assignment index））を含む、付記７に記載の基地局。
【０１３０】
（付記９）前記制御情報は、前記複数のサブフレームの開始サブフレーム、前記複数のサブフレームの終了サブフレーム、及び前記複数のサブフレームのサブフレーム数、の少なくとも１つを識別する情報を含む、付記３〜８のいずれか１項に記載の基地局。
【０１３１】
（付記１０）前記トランシーバは、マシンタイプ通信（ＭＴＣ）固有の物理ダウンリンク制御チャネル（ＭＰＤＣＣＨ）を用いて、前記生成された制御情報を送信するように動作可能である、付記１〜９のいずれか１項に記載の基地局。
【０１３２】
（付記１１）フィードバックが送信される前記サブフレームは、前記複数のサブフレームの最後のサブフレームに続く所定数のサブフレーム（例えば、４）である、付記１〜１０のいずれか１項に記載の基地局。
【０１３３】
（付記１２）前記フィードバックは、バンドリングされたハイブリッドオートマチックリピートリクエスト（ＨＡＲＱ：Hybrid Automatic Repeat Request）フィードバックを含む、付記１〜１１のいずれか１項に記載の基地局。
【０１３４】
（付記１３）ロングタームエボリューション（ＬＴＥ：long term evolution）無線アクセスネットワークの基地局を含む、付記１〜１２のいずれか１項に記載の基地局。
【０１３５】
（付記１４）通信システムのための基地局であって、前記基地局は、
マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を生成するように動作可能なコントローラと、を含み、前記制御情報は、（ｉ）複数のサブフレームの各々における通信リソース、及び（ｉｉ）同一のサブフレームの複数の狭帯域の各々における通信リソース、のうちの少なくとも１つを割り当てるための１つのダウンリンク制御指示を含み、
前記基地局は、前記割り当てられた通信リソースを用いて前記マシンタイプ通信デバイスにデータを送信するために、前記マシンタイプ通信デバイスに前記生成された制御情報を送信するように動作可能なトランシーバを含む、基地局。
【０１３６】
（付記１５）前記制御情報は、複数のサブフレームの各々において通信リソースを割り当てるための１つのダウンリンク制御指示を含み、前記トランシーバは、前記マシンタイプ通信デバイスに送信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを前記マシンタイプ通信デバイスから受信するように動作可能であり、前記ＡＣＫ／ＮＡＣＫフィードバックは、複数のサブフレームにおいて送信されたデータを受け取ったことを通知するための単一のＡＣＫ／ＮＡＣＫ指示を含む、付記１４に記載の基地局。
【０１３７】
（付記１６）前記制御情報は、同一のサブフレームの複数の狭帯域の各々において通信リソースを割り当てるための１つのダウンリンク制御指示を含み、前記複数の狭帯域は、複数の連続する狭帯域を含む、付記１４又は１５に記載の基地局。
【０１３８】
（付記１７）前記通信リソースは、物理リソースブロック（ＰＲＢ：physical resource block）を含み、前記制御情報は、開始ＰＲＢ、及び前記開始ＰＲＢから前記通信デバイスに割り当てられた連続するＰＲＢの総数を識別する、付記１６に記載の基地局。
【０１３９】
（付記１８）前記ダウンリンク制御指示は、同一のサブフレームの複数の狭帯域の各々における通信リソースの割り当てのためレガシーＤＣＩフォーマット（例えば、修正されたＤＣＩフォーマット６−０Ａ）を再利用する、付記１５に記載の基地局。
【０１４０】
（付記１９）前記再利用されるレガシーＤＣＩフォーマットは、最大「ｎ」個の連続するＰＲＢを割り当てるために以下の式を使用する、付記１８に記載の基地局。
【数２３】
2020120412.tif 000029
【０１４１】
（付記２０）前記コントローラは、（レガシー）周波数ホッピングパラメータ及び（レガシー）繰り返し数パラメータの少なくとも１つの異なるそれぞれの設定を用いて、同一のサブフレームの複数の狭帯域の各々における通信リソースの割り当てのための前記レガシーＤＣＩフォーマットの使用と、レガシー目的のための前記レガシーＤＣＩフォーマットの使用とを区別するように動作可能である、付記１８又は１９に記載の基地局。
【０１４２】
（付記２１）各狭帯域は、所定数（好ましくは６又は２５）の物理リソースブロック（ＰＲＢ：physical resource block）を含む異なるそれぞれの周波数範囲をカバーする、付記１６又は１７に記載の基地局。
【０１４３】
（付記２２）前記コントローラは、セル帯域幅を有するセルを運用するように構成され、前記セル帯域幅は、以下の式により与えられる狭帯域の総数を含む、付記１６〜２１のいずれか１項に記載の基地局。
【数２４】
2020120412.tif 000030
ここで、ＮＢｗｈｏｌｅは、前記セル帯域幅内の狭帯域の数であり、ＮＲＢは、前記セル帯域幅内のリソースブロックの数であり、ｎは、各狭帯域のリソースブロックの数であり；
【数２５】
2020120412.tif 000031
は、フロア関数（つまり、「ｘ」よりも大きくない最大の整数）である。
【０１４４】
（付記２３）前記データは、多数のデータバンドルで順に送信され（例えば、物理ダウンリンク共有チャネル「ＰＤＳＣＨ」バンドル）、各データバンドルは、一連のダウンリンクサブフレームで送信され、前記トランシーバは、各バンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックを含む、ＡＣＫ／ＮＡＣＫフィードバックを受信するように動作可能であり、前記コントローラは、最後のデータバンドルが送信される最後のサブフレームに基づいて、最初のＰＤＳＣＨバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックが予想される開始サブフレーム、データバンドルの数、及び前記データバンドルの送信が繰り返されるか否かを決定するように動作可能である、付記３又は１４に記載の基地局。
【０１４５】
（付記２４）前記トランシーバは、マシンタイプ通信（ＭＴＣ：machine-type communication）固有の物理ダウンリンク制御チャネル（ＭＰＤＣＣＨ：MTC specific Physical Downlink Control Channel）を用いて前記生成された制御情報を送信するように動作可能である、付記１４〜２３のいずれか１項に記載の基地局。
【０１４６】
（付記２５）通信システムのためのマシンタイプ通信デバイスであって、前記マシンタイプ通信デバイスは、
前記マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を受信し、
前記割り当てられた通信リソースを用いて、多数のデータバンドルで順に送信される（例えば、物理ダウンリンク共有チャネル「ＰＤＳＣＨ」バンドル）、データであって、各データバンドルが一連のダウンリンクサブフレームで送信される前記データを受信するように動作可能なトランシーバと、
前記マシンタイプ通信デバイスにより受信されるデータに対するＡＣＫ／ＮＡＣＫフィードバックであって、各バンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックを含む、前記ＡＣＫ／ＮＡＣＫフィードバックを生成するように動作可能なコントローラと、を含み、
前記コントローラは、最後に送信された最後のサブフレームに基づいて、最初のＰＤＳＣＨバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックが予想される開始サブフレーム、データバンドルの数、及び前記データバンドルが繰り返されるか否かを決定するように動作可能であって、
前記トランシーバは、前記決定された開始サブフレームに基づいて、前記基地局に前記生成されたフィードバックを送信するように動作可能である、マシンタイプ通信デバイス。
【０１４７】
（付記２６）前記コントローラは、以下の式に基づいて前記開始サブフレームを決定するように動作可能である、付記２５に記載のマシンタイプ通信デバイス。
【数２６】
2020120412.tif 000032
ここで、「ｎ」は、前記最後のデータバンドルが送信される最後のサブフレームに続く、第４のサブフレームであり；Ｎｂｕｎｄｌｅは、データバンドルの数であり；
【数２７】
2020120412.tif 000033
は、データバンドルが送信される回数である。
【０１４８】
（付記２７）通信システムのためのマシンタイプ通信デバイスであって、前記マシンタイプ通信デバイスは、
前記マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を受信し、
前記割り当てられた通信リソースを用いてデータを受信するように動作可能なトランシーバと、
前記マシンタイプ通信デバイスにより受信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを生成するように動作可能なコントローラと、を含み、
前記ＡＣＫ／ＮＡＣＫフィードバックは、複数のサブフレームにおいて送信されたデータを受け取ったことを通知するための１つのＡＣＫ／ＮＡＣＫ指示を含み、
前記トランシーバは、前記生成されたフィードバックを前記基地局に送信するように動作可能である、マシンタイプ通信デバイス。
【０１４９】
（付記２８）前記複数のサブフレームの全てのサブフレームにおいて前記マシンタイプ通信デバイスに送信されたデータが正常に受信された場合、前記ＡＣＫ／ＮＡＣＫ指示は、肯定応答（ＡＣＫ：acknowledgement）を含み、前記複数のサブフレームの１つのサブフレームにおいて前記マシンタイプ通信デバイスに送信されたデータが正常に受信されなかった場合、前記ＡＣＫ／ＮＡＣＫ指示は、否定応答（ＮＡＣＫ：non-acknowledgement）を含む、付記２７に記載のマシンタイプ通信デバイス。
【０１５０】
（付記２９）前記制御情報は、前記複数のサブフレームの各々における通信リソースを割り当てるための単一のダウンリンク制御指示を含む、付記２７又は２８に記載のマシンタイプ通信デバイス。
【０１５１】
（付記３０）前記複数のサブフレームは、単一の狭帯域内に複数の連続するサブフレームを含む、付記２９に記載のマシンタイプ通信デバイス。
【０１５２】
（付記３１）前記制御情報は、前記複数のサブフレームの各サブフレームについて、当該サブフレームにおいて物理リソースブロック（ＰＲＢ：physical resource block）のセットを割り当てるためのそれぞれのダウンリンク制御情報（ＤＣＩ：downlink control information）フォーマットを含む、付記２７又は２８に記載のマシンタイプ通信デバイス。
【０１５３】
（付記３２）前記制御情報は、各サブフレームについて、前記通信デバイスがフィードバックを提供することを要求される前に通信リソースが前記通信デバイスに割り当てられるサブフレームの総数又は残りの数を示す情報（例えば、ダウンリンク割り当てインデックス（ＤＡＩ：downlink assignment index））を含む、付記３１に記載のマシンタイプ通信デバイス。
【０１５４】
（付記３３）前記制御情報は、前記複数のサブフレームの開始サブフレーム、前記複数のサブフレームの終了サブフレーム、及び前記複数のサブフレームのサブフレーム数の少なくとも１つを識別する情報を含む、付記２７〜３２のいずれか１項に記載のマシンタイプ通信デバイス。
【０１５５】
（付記３４）前記トランシーバは、マシンタイプ通信（ＭＴＣ：machine-type communication）固有の物理ダウンリンク共有チャネル（ＭＰＤＣＣＨ：MTC specific Physical Downlink Control Channel）を用いて、前記制御情報を受信するように動作可能である、付記２７〜３３のいずれか１項に記載のマシンタイプ通信デバイス。
【０１５６】
（付記３５）フィードバックが送信されるサブフレームは、前記複数のサブフレームの最後のサブフレームに続く所定数の（例えば４個の）サブフレームである、付記２７〜３４のいずれか１項に記載のマシンタイプ通信デバイス。
【０１５７】
（付記３６）前記ＡＣＫ／ＮＡＣＫフィードバックは、バンドリングされたハイブリッドオートマチックリピートリクエスト（ＨＡＲＱ：Hybrid Automatic Repeat Request）フィードバックを含む、付記２７〜３５のいずれか１項に記載のマシンタイプ通信デバイス。
【０１５８】
（付記３７）前記トランシーバは、前記セル帯域幅と比較して低減された帯域幅を用いて通信するように動作可能である、付記２７〜３６のいずれか１項に記載のマシンタイプ通信デバイス。
【０１５９】
（付記３８）通信システムのためのマシンタイプ通信デバイスであって、前記マシンタイプ通信デバイスは、
前記マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報であって、（ｉ）複数のサブフレームの各々における通信リソース、及び（ｉｉ）同一のサブフレームの複数の狭帯域の各々における通信リソースの少なくとも１つを割り当てるための１つのダウンリンク制御指示を含む前記制御情報を基地局から受信し、
前記割り当てられた通信リソースを用いてデータを前記基地局から受信するように動作可能なトランシーバを含む、マシンタイプ通信デバイス。
【０１６０】
（付記３９）前記制御情報は、複数のサブフレームの各々における通信リソースを割り当てるための１つのダウンリンク制御指示を含み、前記トランシーバは、前記基地局により前記マシンタイプ通信デバイスに送信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを前記基地局に送信するように動作可能であり、前記ＡＣＫ／ＮＡＣＫフィードバックは、複数のサブフレームにおいて送信されたデータを受け取ったことを通知するための単一のＡＣＫ／ＮＡＣＫ指示を含む、付記３８に記載のマシンタイプ通信デバイス。
【０１６１】
（付記４０）前記制御情報は、同一のサブフレームの複数の狭帯域の各々において通信リソースを割り当てるための１つのダウンリンク制御指示を含み、前記複数の狭帯域は、複数の連続する狭帯域を含む、付記３８又は３９に記載のマシンタイプ通信デバイス。
【０１６２】
（付記４１）前記通信リソースは、物理リソースブロック（ＰＲＢ：physical resource block）を含み、前記制御情報は、開始ＰＲＢ、及び前記開始ＰＲＢから前記通信デバイスに割り当てられた連続するＰＲＢの総数を識別する、付記４０に記載のマシンタイプ通信デバイス。
【０１６３】
（付記４２）各狭帯域は、所定数（好ましくは６又は２５）の物理リソースブロック（ＰＲＢ：physical resource block）を含む異なるそれぞれの周波数範囲をカバーする、付記３８、４０又は４１に記載のマシンタイプ通信デバイス。
【０１６４】
（付記４３）前記データは、前記基地局により多数のデータバンドルにおいて順に送信され（例えば、物理ダウンリンク共有チャネル「ＰＤＳＣＨ」バンドル）、各データバンドルは、一連のダウンリンクサブフレームにおいて送信され、前記トランシーバは、各バンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックを送信するように動作可能であり、前記コントローラは、最後のデータバンドルが送信される最後のサブフレームに基づいて、最初のＰＤＳＣＨバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックが予想される開始サブフレーム、及び前記データバンドルの送信が繰り返されるか否かを決定するように動作可能である、付記２７又は３８に記載のマシンタイプ通信デバイス。
【０１６５】
（付記４４）前記トランシーバは、マシンタイプ通信（ＭＴＣ：machine-type communication）固有の物理ダウンリンク共有チャネル（ＭＰＤＣＣＨ：MTC specific Physical Downlink Control Channel）を用いて、前記制御情報を受信するように動作可能である、付記３８〜４３のいずれか１項に記載のマシンタイプ通信デバイス。
【０１６６】
（付記４５）付記１〜２４のいずれか１項に記載の基地局と、付記２５〜４４のいずれか１項に記載のマシンタイプ通信デバイスとを含むシステム。
【０１６７】
（付記４６）通信システムの基地局により実行される方法であって、前記方法は、
マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を生成することと、
前記マシンタイプ通信デバイスに前記生成された制御情報を送信することと、
前記割り当てられた通信リソースを用いて、前記マシンタイプ通信デバイスにデータを送信することと、
前記マシンタイプ通信デバイスに送信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを前記マシンタイプ通信デバイスから受信することと、を含み、
前記データは、多数のデータバンドルにおいて順に送信され（例えば、物理ダウンリンク共有チャネル「ＰＤＳＣＨ」バンドル）、各データバンドルは、一連のダウンリンクサブフレームにおいて送信され、
前記ＡＣＫ／ＮＡＣＫフィードバックは、各バンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックを含み、
前記方法は、最後のデータバンドルが送信される最後のサブフレームに基づいて、最初のＰＤＳＣＨバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックが予想される開始サブフレーム、データバンドルの数、及び前記データバンドルの送信が繰り返されるか否かを決定することを含む、方法。
【０１６８】
（付記４７）通信システムの通信デバイスにより実行される方法であって、前記方法は、
前記マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を受信し、
前記割り当てられた通信リソースを用いて、多数のデータバンドルにおいて順に送信され（例えば、物理ダウンリンク共有チャネル「ＰＤＳＣＨ」バンドル）、各データバンドルは、一連のダウンリンクサブフレームにおいて送信される、データを受信することと、
前記マシンタイプ通信デバイスにより受信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックであって、各バンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックを含む前記ＡＣＫ／ＮＡＣＫフィードバックを生成することと、
最後のデータバンドルが送信される最後のサブフレームに基づいて、最初のＰＤＳＣＨバンドルに対するそれぞれのＡＣＫ／ＮＡＣＫフィードバックが予想される開始サブフレーム、データバンドルの数、及び前記データバンドルの送信が繰り返されるか否かを決定することと、
前記決定された開始サブフレームに基づいて、前記生成されたフィードバックを前記基地局に送信することと、を含む方法。
【０１６９】
（付記４８）通信システムの基地局により実行される方法であって、前記方法は、
マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を生成することと、
前記マシンタイプ通信デバイスに前記生成された制御情報を送信することと、
前記割り当てられた通信リソースを用いて、前記マシンタイプ通信デバイスにデータを送信することと、
前記マシンタイプ通信タイプに送信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックを前記マシンタイプ通信デバイスから受信することと、を含み、
前記ＡＣＫ／ＮＡＣＫフィードバックは、複数のサブフレームにおいて送信されたデータを受け取ったことを通知するための１つのＡＣＫ／ＮＡＣＫ指示を含む、方法。
【０１７０】
（付記４９）通信システムの基地局により実行される方法であって、前記方法は、
マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報であって、（ｉ）複数のサブフレームの各々における通信リソース、及び（ｉｉ）同一サブフレームの複数の狭帯域の各々における通信リソースの少なくとも１つを割り当てるための１つのダウンリンク制御指示を含む前記制御情報を生成することと、
前記割り当てられた通信リソースを用いて、前記マシンタイプ通信デバイスにデータを送信するために、前記マシンタイプ通信デバイスに前記生成された制御情報を送信することと、を含む方法。
【０１７１】
（付記５０）通信システムの通信デバイスであって、前記方法は、
マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報を受信し、
前記割り当てられた通信リソースを用いて、データを受信することと、
前記マシンタイプ通信デバイスにより受信されたデータに対するＡＣＫ／ＮＡＣＫフィードバックであって、複数のサブフレームにおいて送信されたデータを受け取ったことを通知するための１つのＡＣＫ／ＮＡＣＫ指示を含む前記ＡＣＫ／ＮＡＣＫフィードバックを生成することと、
前記生成されたフィードバックを前記基地局に送信することと、を含む方法。
【０１７２】
（付記５１）通信システムの通信デバイスにより実行される方法であって、前記方法は、
基地局から、
前記マシンタイプ通信デバイスにデータを送信するための通信リソースを割り当てるための制御情報であって、（ｉ）複数のサブフレームの各々における通信リソース、及び（ｉｉ）同一サブフレームの複数の狭帯域の各々における通信リソースの少なくとも１つを割り当てるための１つのダウンリンク制御指示を含む前記制御情報を受信し、
前記割り当てられた通信リソースを用いて、データを受信することと、を含む方法。
【０１７３】
（付記５２）プログラム可能な通信デバイスに付記４６〜５１のいずれか１項に記載の方法を実行させるためのコンピュータ実行命令を含むコンピュータ実行可能命令製品。
【０１７４】
本出願は、２０１６年８月９日に出願された英国特許出願第１６１３７１０．１号、２０１６年９月２８に出願された英国特許出願第１６１６４９２．３号、及び２０１７年２月３日に出願された英国特許出願第１７０１８４５．８号に基づく優先権の利益を主張するものであり、その開示は参照によりその全体が本明細書に組み込まれる。
【図１】
2020120412.tif 000034
【図２】
2020120412.tif 000035
【図３】
2020120412.tif 000036
【図４】
2020120412.tif 000037
【図５】
2020120412.tif 000038
【図６】
2020120412.tif 000039
【図７】
2020120412.tif 000040
【図８】
2020120412.tif 000041
【図９】
2020120412.tif 000042