(57)【特許請求の範囲】
【請求項１】
ロングタームエボリューション(LTE)ネットワークを通じて通信するように構成されたマシンタイプコミュニケーション(MTC)デバイスであって、当該MTCデバイスは、
前記LTEネットワークを介して信号を受信する無線トランシーバと、
最大ハイブリッド自動再送信要求(HARQ)プロセス数にまでの複数のソフトチャネルビットを記憶するように構成されたソフトバッファと、
前記最大HARQプロセス数と、サブブロックインタリーブサイズと、コードブロック数とを掛けて、符号化率で割ったものに基づく総ソフトチャネルビット数を決定し、
制限バッファレートマッチング(LBRM)を用いて、前記ソフトバッファ内に、前記総ソフトチャネルビット数より小さい数のソフトチャネルビットを記憶する、信号処理部と、を含むMTCデバイス。
【請求項２】
前記小さい数は、前記総ソフトチャネルビット数の半分を含む、請求項1に記載のMTCデバイス。
【請求項３】
前記ソフトバッファは、前記総ソフトチャネルビット数より小さい数だけ記憶するサイズとされた、請求項1に記載のMTCデバイス。
【請求項４】
当該MTCデバイスは、前記LTEネットワーク内で、進化型ユニバーサル地上無線アクセスネットワーク(E-UTRAN)を用いたダウンリンク通信用の総ソフトチャネルビット数25344に対応するユーザエクイップメント(UE)カテゴリに定義される、請求項1から3のいずれか一項に記載のMTCデバイス。
【請求項５】
前記最大HARQプロセス数は8である、請求項4に記載のMTCデバイス。
【請求項６】
前記信号処理部は、半二重周波数分割複信(HD-FDD)用に、前記最大HARQプロセス数より小さい数に基づいた前記総ソフトチャネルビット数を決定する、請求項1から3のいずれか一項に記載のMTCデバイス。
【請求項７】
前記最大HARQプロセス数より小さい数は4つのHARQプロセスを含み、前記総ソフトチャネルビット数より小さい数は6336ビットを含む、請求項6に記載のMTCデバイス。
【請求項８】
前記最大HARQプロセス数より小さい数は3つのHARQプロセスを含み、前記総ソフトチャネルビット数より小さい数は4752ビットを含む、請求項6に記載のMTCデバイス。
【請求項９】
前記信号処理部は、前記最大HARQプロセス数より小さい数に基づいた前記総ソフトチャネルビット数を決定し、前記最大HARQプロセス数より小さい数は、HARQ  RTTタイマに基づく、請求項1から3のいずれか一項に記載のMTCデバイス。
【請求項１０】
アンテナ、タッチ感応ディスプレイ画面、スピーカー、マイクロフォン、グラフィックプロセッサ、アプリケーションプロセッサ、内部メモリ、不揮発性メモリポート及びこれらの組み合わせのうち少なくとも一つをさらに含む、請求項1から3にいずれか一項に記載のMTCデバイス。
【請求項１１】
ロングタームエボリューション(LTE)ネットワークを通じて通信する方法であって、当該方法は、
前記LTEネットワークを通じて信号を受信することと、
最大ハイブリッド自動再送信要求(HARQ)プロセス数にまでの複数のソフトチャネルビットを記憶することと、
前記最大HARQプロセス数と、サブブロックインタリーブサイズと、コードブロック数とを掛けて、符号化率で割ったものに基づく総ソフトチャネルビット数を決定することと、
制限バッファレートマッチング(LBRM)を用いて、前記総ソフトチャネルビット数より小さい数のソフトチャネルビットを記憶することと、を含む方法。
【請求項１２】
請求項11に記載の方法を実行する手段を含む、装置。
【請求項１３】
実行により、請求項11に記載の方法を実装する、機械読み取り可能なプログラム。
【請求項１４】
請求項13に記載のプログラムを含む、機械読み取り可能ストレージ。
【請求項１５】
請求項11に記載の方法を行うように構成された処理論理を含む、装置。
【請求項１６】
一以上のプロセッサに、方法を行わせるプログラムであって、当該方法は、
ロングタームエボリューション(LTE)ネットワーク内で進化型NodeB(eNB)との接続を確立することと、
前記eNBとの全二重周波数分割複信について、最大ハイブリッド自動再送信要求(HARQ)プロセス数を決定することと、
前記eNBとの半二重周波数分割複信について、前記最大HARQプロセス数より小さい数を決定することであって、当該小さい数は、前記最大HARQプロセス数よりも小さい、決定することと、
前記小さいHARQプロセス数と、サブブックインタリーブサイズと、コードブロック数とを掛けて、符号化率で割ったものに基づいた総ソフトチャネルビット数を決定することと、
ソフトバッファに、前記総ソフトチャネルビット数より小さい数のソフトチャネルビットを記憶すること、とを含む、プログラム。
【請求項１７】
前記総ソフトチャネルビット数より小さい数のソフトチャネルビットを記憶することは、制限バッファレートマッチングを行うことを含む、請求項16に記載のプログラム。
【請求項１８】
前記総ソフトチャネルビット数より小さい数は、前記総ソフトチャネルビット数の半分を含む、請求項16に記載のプログラム。
【請求項１９】
前記ソフトバッファは、前記総ソフトチャネルビット数より小さい数だけ記憶するサイズとされた、請求項16に記載のプログラム。
【請求項２０】
当該方法が、前記eNBとの半二重周波数分割複信用のマシンタイプコミュニケーションデバイスとしてユーザエクイップメント(UE)を構成することをさらに含む、請求項16に記載のプログラム。
【請求項２１】
請求項16から20のいずれか一項に記載のプログラムを記憶したコンピュータ読み取り可能記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、35  U.S.C.  §119(e)に基づき、2014年3月20日に出願された、米国仮特許出願番号61/968,282号(代理人整理番号P64659Z)、2014年4月28日に出願された、米国仮特許出願番号61/985,391号(代理人整理番号P67009Z)及び2014年5月8日に出願された、米国仮特許出願番号61/990,619号(代理人整理番号P67689Z)の利益を主張し、各々は、すべて参照により本明細書に援用される。
【０００２】
本開示は、一般的に、無線通信ネットワークに関する。詳細には、本開示は、低コストのマシンタイプコミュニケーション(MTC)デバイスに関する。
【背景技術】
【０００３】
マシンタイプコミュニケーション(MTC)(マシンツーマシン(M2M)コミュニケーションとも呼ばれる)は、移動体通信事業者、設備業者、MTC専門会社、研究機関の関心となっている。M2Mコミュニケーションにより、M2Mコンポーネントを、低コストの拡張性と信頼性のある技術を用いて、相互接続し、ネットワークに繋ぎ、遠隔制御することができる。そのようなM2Mコミュニケーションはモバイルネットワーク上で搬送され、その場合、モバイルネットワークの役割は、その大部分において転送ネットワークとしての働きに限られる。
【０００４】
MTCアプリケーション(単に、MTC)内でのMTCコミュニケーションのためのMTCデバイスとして用いられるユーザエクイップメントデバイス(単に、UE)は、色々なところで(再)展開され、低いモバイル性で展開され、弱い信号強度を有する場所(例えば、不十分なカバー範囲)に展開され、通信の優先度が低く、まれに少量のモバイル志向(MO)又はモバイル端末(MT)データを送信する等の特性を有する。例えば、需給計器アプリケーションのためのスマートメーターは、MTCデバイス(以下、通常、MTCと称する)として用いられる、ある種のUEである。そのような計測デバイスは、市の公共サービスの利用をモニタリングして、定期的にエネルギー使用についての情報をサービスプロバイダに報告する。計測デバイスは自発的に利用情報をネットワークの中央ノードに転送してもよいし、中央ノードはレポート情報が必要とされるときに計測デバイスをポーリングしてもよい。
【０００５】
ロードセキュリティはモニタリングアプリケーションの他の例である。例えば、自動車事故の際には、車載緊急コールサービスが自発的に自動車事故の位置情報を緊急第一応答者に報告することで、即座の支援を促進する。モニタリング用の他のロードセキュリティアプリケーションには、知的交通管理、自動発券、フリート管理及び他の用途が含まれる。
【０００６】
家庭用電化製品には、eBookリーダ、デジタルカメラ、パーソナルコンピュータ、ナビゲーションシステム等のデバイスが含まれ、モニタリングによる恩恵を受ける。例えば、そのようなデバイスはモニタリングを用いて、ファームウェアをアップグレードしたり、オンラインコンテンツをアップロード及びダウンロードしたりできる。
【図面の簡単な説明】
【０００７】
【図１】図1は、所定の実施形態による、通信ネットワークのブロック図である。
【０００８】
【図２】図2は、一の実施形態による、MTCデバイス例のブロック図である。
【０００９】
【図３】図3は、一の実施形態による、図2に示した信号処理部のブロック図である。
【００１０】
【図４】図4は、制限バッファレートマッチング(LBRM)の実施形態例を示す。
【００１１】
【図５Ａ】図5Aは、所定の実施形態による、フルバッファレートマッチング(FBRM)とLBRMとのパフォーマンス比較を示すグラフである。
【図５Ｂ】図5Bは、所定の実施形態による、フルバッファレートマッチング(FBRM)とLBRMとのパフォーマンス比較を示すグラフである。
【図６Ａ】図6Aは、所定の実施形態による、フルバッファレートマッチング(FBRM)とLBRMとのパフォーマンス比較を示すグラフである。
【図６Ｂ】図6Bは、所定の実施形態による、フルバッファレートマッチング(FBRM)とLBRMとのパフォーマンス比較を示すグラフである。
【図７Ａ】図7Aは、所定の実施形態による、フルバッファレートマッチング(FBRM)とLBRMとのパフォーマンス比較を示すグラフである。
【図７Ｂ】図7Bは、所定の実施形態による、フルバッファレートマッチング(FBRM)とLBRMとのパフォーマンス比較を示すグラフである。
【００１２】
【図８Ａ】図8Aは、所定の実施形態による、低コストのMTCデバイスについてのハイブリッド自動再送信要求(HARQ)プロセス例を示す。
【図８Ｂ】図8Bは、所定の実施形態による、低コストのMTCデバイスについてのハイブリッド自動再送信要求(HARQ)プロセス例を示す。
【図９Ａ】図9Aは、所定の実施形態による、低コストのMTCデバイスについてのハイブリッド自動再送信要求(HARQ)プロセス例を示す。
【図９Ｂ】図9Bは、所定の実施形態による、低コストのMTCデバイスについてのハイブリッド自動再送信要求(HARQ)プロセス例を示す。
【００１３】
【図１０】図10は、一の実施形態による、モバイルデバイスの図示例である。
【発明を実施するための形態】
【００１４】
本開示の実施形態に沿ったシステム及び方法の詳細な説明を以下に提供する。複数の実施形態を記載するが、開示内容は任意の一の実施形態に限定されないし、多数の代替物、修正物及び均等物を包含すると理解されるべきである。また、多数の具体的な詳細を、本明細書で開示する実施形態への十分な理解を提供するため、次の記載に提供するが、いくつかの実施形態は、これらの詳細の一部又は全部がなくても実施し得る。さらに、明確性のため、関連技術分野において既知の所定の技術事項は、本開示を不必要に不明確にすることを避けるため、詳細には記載していない。
【００１５】
MTCデバイスは、一般的には、低コストのデバイスである。しかし、低コストのMTCデバイスのコスト及びサイズをさらに小さくする試みが行われている。以下に説明するように、ユーザエクイップメント(UE)(MTCデバイスなど)でのレートマッチング(rate  matching)がメモリの大部分を使用して、ハイブリッド自動再送信要求(HARQ)プロセスのためのソフトチャネルビット(soft  channel  bits)を記憶する。ソフトチャネルビットは、ソフトバッファサイズの実装に関連する。本明細書で開示する所定の実施形態は、ソフトチャネルビットを減らして、MTCデバイス用のメモリの観点からコスト及びサイズを小さくするものである。そのような実施形態においては、ソフトバッファサイズは、サポートされる最大転送ブロック(TB)サイズ、HARQプロセス数、ターボ符号化及び復号化並びに制限バッファレートマッチング(LBRM)のアプリケーションの関数である。所定の実施形態は、同じ数のHARQプロセスを用いる他のアプローチと比較して、ソフトチャネルビット数を約50%削減し得る。さらに、又は他の実施形態においては、低コストのMTCデバイスについてのHARQプロセス数を小さくすることでコスト節約性が向上し得る。
【００１６】
第三世代パートナーシッププロジェクト(3GPP)無線アクセスネットワーク(RAN)ロングタームエボリューション(LTE)システムでは、ノードは、進化型ユニバーサル地上無線アクセスネットワーク(E-UTRAN)Node  B(通常、進化型(evolved)Node  B、改良型(enhanced)Node  B、eNodeB又はeNBとも示される)と無線ネットワークコントローラ(RNC)との組み合わせであり、ユーザエクイップメント(UE)として知られる、無線デバイスと通信し得る。DL送信は、ノード(例えば、eNB)から無線デバイス(例えば、UE)への通信であり得る。UL送信は、ノード無線デバイスからノードへの通信であり得る。本明細書において、用語「ノード」及び「セル」は同義語であることを意図しており、複数のユーザエクイップメントと動作可能に通信する無線送信ポイント(eNB、低出力ノード(low  power  node)、その他の基地局等)を示す。
【００１７】
図1は、所定の実施形態による、通信ネットワーク100のブロック図である。通信ネットワーク100は、UE(低コストのMTCデバイス114)とアップリンク(UL)及びダウンリンク(DL)のユーザデータ112を通信するように構成されたノード(eNB  110)を含む。MTCデバイス114は、eNB110のカバーエリア内に示されている。MTCデバイス114は、他のUE120との直接通信118用に構成されている。例では、eNB110のカバーエリア116内にあるUE120を示しているが、直接通信118は、UE120がカバーエリア116の外にあるときでも起き得る。MTCデバイス114は、所定の実施形態においては、LBRMを用いて、HARQプロセス用のソフトチャネルビット数を小さくするように構成されている。
【００１８】
図2は、一の実施形態による、MTCデバイス114の例のブロック図である。本明細書で記載する実施形態は、無線通信システム(図1に示した通信ネットワーク100等)内で動作可能なMTCデバイス114に関するものである。MTCデバイス114は、LBRMを用いて、HARQプロセス用のソフトチャネルビット数を小さくするように構成される。
【００１９】
MTCデバイス114は、点線で囲んで図示される、アレンジメント208を含む。MTCデバイス114は、低コストのMTCデバイスであり得る。MTCデバイス114及びアレンジメント208は、さらに、通信部210を介した他のエンティティと通信するように図示されている。通信部210はアレンジメント208の一部とみなし得る。通信部210は通信手段(受信機(Rx)222及び送信機(Tx)220又はトランシーバ等)を含む。あるいは、通信部210は、「インタフェース」と示され得る。アレンジメントは、さらに他の複数の機能部217(通常のUE機能を提供する機能部等)を含んでよいし、一以上のメモリ部216を含み得る。
【００２０】
アレンジメント208は、例えば、プロセッサ若しくはマイクロプロセッサ及び適正なソフトウェア及びそれを記憶するメモリ、プログラマブル論理デバイス(PLD)、他の電子コンポーネント又は本明細書に記載される活動を行うように構成された処理回路の一つ以上により実装され得る。
【００２１】
アレンジメント208は、キャリア(例えば、ULキャリア、DLキャリア、M2Mキャリア又はデバイスツーデバイス(D2D)キャリア)を介して信号を受信するように適合した受信部212を含む。受信部212は、信号を信号処理部214に渡す。
【００２２】
図3は、一の実施形態による、図2に示した信号処理部214のブロック図である。信号処理部214はハードウェア、ソフトウェア、又はこれら二つの組み合わせで実装され得る。信号処理部214は図3に示す複数の機能ブロックに構造化されている。信号は図2のトランシーバによって受信され、トランシーバは信号を復調し、所与のTBについての受信対数尤度比(LLR)を生成する。HARQ組み合わせ要素310は、受信LLRと前回の送信によるTBについての記憶LLRとを組み合わせる。組み合わせLLRはプロセッサ304によってブロック312(例えば、ターボデコーダ)で復号され、他のプロセスに渡される(例えば、さらなる処理用に高位層に送られる)。TBが正常に復号されない(例えば、信号処理部214の巡回冗長検査(CRC)機能によって判定される)場合、そのTBについての組み合わせLLRが、ソフトバッファ314のパーティション316に記憶される。TBがブロック312で正常に復号されない場合、MTCデバイス114は、アップリンク上にHARQフィードバックを送信し得る。ソフトバッファ314は、MTCデバイス114がTBを復号する他の試行を行うまで、TBについての組み合わせLLRを保持する。
【００２３】
送信エンティティ(例えば、図1に示したeNB110又はUE120)は、MTCデバイスが正常にTBを受信しなかったことを示すHARQフィードバックを受信すると、TBを再送信することを試行する。再送信TBは前と同一の機能ブロックに通されるが、MTCデバイス114がブロック312で再送信TBを復号することを試行するときは、MTCデバイス114はTBについてのLLRをメモリ部216から取得し、HARQ組み合わせ要素310を用いて、「ソフトコンバイニング(soft  combining)」として知られるプロセス内でTBについての受信LLRと記憶LLRとを組み合わせる。組み合わせLLRはブロック312にあるデコーダに提供され、デコーダはTBを復号し、正常に復号されたTBをさらなる処理用に高位層に提供する。
【００２４】
ソフトバッファ314は、HARQメモリ又はHARQバッファとも呼ばれ得る。複数のHARQプロセスがあるので、HARQプロセスインデックス又はHARQアイデンティティ(典型的には、(例えば、ダウンリンクについての)TBに関連づけられたダウンリンク制御情報(DCI)内の明示フィールドを用いて送出される、又は(例えば、アップリンクについての)サブフレーム番号(SN)、システムフレーム番号(SFN)等を介して黙示的に決定される)がHARQ組み合わせ要素310に利用されて、正しく組み合わせ動作を行う。アップリンク送信については、黙示のHARQプロセスインデックスがMTCデバイス114により用いられて、アップリンク送信について符号化ビットを正しく決定する。MTCデバイスが、HARQプロセスあたりの一つのTB(又は送信タイミング間隔(TTI)あたりの一つのTB)が最大である送信モードで構成されている場合、MTCデバイス114のソフトバッファ314は、図3に示されるように、八つのパーティション316に分割される。
【００２５】
所与のコンポーネントキャリアについての周波数分割複信(FDD)については、MTCデバイス114は、DL内に8つのHARQプロセスを有し得る。いくつかの状況において、MTCデバイス114が所与のトランスポートブロックについての十分な量のストレージを有しておらず、デコード失敗が起きる場合、MTCデバイス114は、いくつかのLLRを記憶し、他のいくつかのLLRを破棄することを選択し得る。他の状況において、トランスポートブロックについての利用可能なストレージがない、又はトランスポートブロックに必要なストレージがないとみなされ、デコード失敗が生じる場合、MTCデバイス114は、そのトランスポートブロックに対応する全てのLLRを破棄し得る。そのような状況は、典型的には、ネットワークエンティティがUEのストレージ能力を超える符号化ビット量を送信する場合に起きる。所与のコンポーネントキャリアについてのFDDについては、アップリンクに対しては、MTCデバイス114は、MTCデバイス114がUL-MIMO送信モードに構成されていないときに、8つのHARQプロセスを有し得る。TDDについては、アップリンクに対するHARQプロセスの数は、TDD  UL/DL構成に基づいて決定される。
【００２６】
表1を参照して、フルバッファレートマッチング(FBRM)を用いるときの、低コストのMTCデバイス(例えば、3GPP  LTE規格のUEカテゴリー0)についてのソフトバッファの寸法が総ソフトチャネルビット数によって決定される。ソフトバッファサイズの導出は、最大TBサイズ、ターボ符号化/復号化及びHARQプロセス数に基づく。
【表１】
0006328802.tif 000002
【００２７】
FRBMを用いる低コストのMTCデバイスについて、ソフトバッファサイズは、総ソフトチャネルビット数(25344ビット)に対応し、次のように導出される。
TTI当たりの最大TB  ：  1000ビット
コードワード当たりのTBサイズ(B)  ：  1000
コードブロック数(C)  ：  Ceil{B=24/(6144-24)｝=1
巡回冗長検査(CRC)を合わせたTBサイズ(B’)  ：  (B+24)=1024
ターボ符号インタリーブサイズ(K)  ：  B’/C=1024
ターボ符号トレリス終端(term)(T)  ：  K+4=1028
サブブロックインタリーブサイズ(V)  ：  Ceil(T/32)*32=1056
パディングビット数  ：  V-T=28
総バッファサイズ  ：  V*(1/マザー符号化率)*C*(最大HARQプロセス数)=1056*3*1*8=25344ビット(ここで、マザー符号化率=1/3、最大HARQプロセス数=8とする)
【００２８】
所定の実施形態はさらに、LBRMを適用することによって、総ソフトチャネルビット数を小さくして、低コストのMTCデバイスのコストをさらに小さくする。LTEについては、高位のUEカテゴリ(例えば、3、4及び5)についてはLBRMによって最大50%ソフトバッファを小さくするが、下位のUEカテゴリ(例えば、1及び2)には適さない。パフォーマンスの違いが、特に、HARQプロセス数が4までのときには、ほとんどないか、顕著なものではない可能性がある。4つより多くのHARQプロセスを用いても、LBRMをもちいたパフォーマンスの低下は非常にわずかなものであり得る。
【００２９】
図4は、LBRMの実施形態例である。ターボ符号化の後、符号化ビットサイズは、情報ビットサイズの三倍になる(3×)。ゆえに、図4に示す例においては、情報ビットに対応する32のサブブロックインタリーブ列は、FBRM用に3回繰り返されることになる(32×3=96列)。しかし、LBRMについて、ソフトバッファサイズは、N列後に、強制的に早期に終了(early  wrap-around)することによって、小さくされる。LBRMは、冗長バージョン(RV)位置(RV0、RV1、RV2及びRV3として示される)も、各RVが終了ポイントより前に位置するように圧縮する。RVは、LBRM(N/4)後にサブブロックインタリーブ列の数の4等分によって定義される。RV0は2列だけオフセットされ、RV定義コラムは2列で量子化される。
【００３０】
表2に示されるように、所定の実施形態においては、低コストのMTCデバイスにLBRMを用いると、ソフトバッファサイズは、12672ビット(=25344/2)まで小さくなる。一般的に、総ソフトチャネルビット数はLBRMを用いて次のように計算される。
総ソフトチャネルビット数=V*(マザー符号化率)*C*(最大HARQプロセス数)/2
V(サブブロックインタリーブサイズ)を導出するいずれかのパラメータが変更される場合には、それが(以下の例で示すように)上記の式に反映され得ることに留意されたい。
【表２】
0006328802.tif 000003
【００３１】
低コストのMTCデバイスについて、TBサイズ(TBS)が(TBS_max/2)以下であるとき、若しくはMTCデバイスが信号対雑音比(SNR)ポイント付近で動作するとき、若しくは有効符号化レートがチェイス合成を用いた(2*TBS)/(3*TBS_max)以下であるとき、又はインクリメンタルリダンダンシーのみを用いた初期送信については、LBRMとFBRMとではパフォーマンスの損失がほとんどないか、まったくない。
【００３２】
例えば、図5A、図5B、図6A、図6B、図7A及び図7Bは、所定の実施形態によるFBRMとLBRMとのパフォーマンス比較を示すグラフである。図示のFBRMとLBRMとのパフォーマンス比較は、図5A、図6A及び図7Aにおける初期送信ブロック誤りレート(BLER)の観点によるものと、図5B、図6B及び図7Bにおける正規化スループットの観点によるものがある。図5A及び図5Bは、四位相偏移変調(QPSK)及び6つの物理リソースブロック(PRB)を用いた例を図示する。図6A及び図6Bは、16直交振幅変調(QAM)及び3つのPRBを用いた例を図示する。図7A及び図7Bは、64QAM及び2つのPRBを用いた例を図示する。各グラフ例のシミュレーションモデル及びパラメータには、バンド幅が10MHz、キャリア周波数が2GHz、FDDフレームタイプ、TM2送信モード、低相関の2×1多入力多出力(MIMO)構成、拡張歩行者A(EPA)チャネルモデル、1Hzのドップラーシフト及び10%の目標ブロック誤りレートが含まれる。シミュレーションでは、二つのTBSサイズが考慮される。500ビット及び1000ビットであり、1/3及び2/3の有効符号化レートにそれぞれ対応する。
【００３３】
プロットからは、FBRMとLRBMとでは初期送信についてBLERパフォーマンスの差異は無視できるほどであることが分かり得る。さらに、動作するSNRポイント(図5A、図6A及び図7Aにおいて、10%のBLERを想定する)を考慮するとき、スループットパフォーマンスの低下がLBRMについては観察されない。したがって、所定の実施形態においては、低コストのMTCデバイスはLBRMを用いて、12672ビットを超えないソフトバッファサイズを含む。
【００３４】
さらに、又は他の実施形態において、半二重FDD(HD-FDD)を用いてHARQプロセス数を減らすときは、ソフトバッファサイズがさらに小さくなる。HD-FDDについて、半二重の制約(例えば、同時の送信及び受信が許されない)により、所定の実施形態においては、全てのサブフレーム(SF)が送信及び受信のために用いられない可能性がある。ゆえに、HARQプロセス数が減らされて、さらにソフトバッファサイズを小さくする。
【００３５】
例えば、図8A、図8B、図9A及び図9Bは、所定の実施形態による、低コストのMTC  UEいついてのHARQプロセス例を図示する。これらの例において、ULとDLとの移行時間は、例えば、単一発振器が低コストのMTC  UEに用いられる場合には、最大約1ms(1サブフレーム)までであり得る。
【００３６】
図8Aは、1msの移行時間を有する低コストのMTC  UEでの半二重用のHARQプロセスを示す。SF0及びSF1での物理的ダウンリンク共有チャネル(PDSCH)に対応するHARQ-ACKは、それぞれSF4及びSF5でノードからUEに送信される。PDSCHが正常にMTC  UEで復号化される場合(つまり、MTC  UEはACKをeNBに送信する)は、新たなPDSCHが次の利用可能なフレーム-SF7及びSF8で送信され得る。SF2及びSF6は、それぞれDLからUL及びULからDL用の移行時間用に用いられる。
【００３７】
第一HARQプロセスは、SF0及びSF8(SF0及びSF8の上にある0で示される)。第二HARQプロセスは、SF1(SF1の上にある1で示される)に対応する。第三HARQプロセスは、SF7(SF7の上にある2で示される)に対応する。この例においては、SF2、SF3、SF4、SF5及びSF6は、切替時間及びUL送信により、MTC  UEは、HD-FDDの受信(DL)に用いることができない。さらに、MTC  UEは、SF0、SF1、SF2、SF3、SF6、SF7及びSF8は、切替時間及びDL受信により、HD-FDDの送信(UL)に用いることができない。図示の動作からは、半二重の低コストのMTC  UEについての最大HARQ処理数は3である。表3に示すように、FDD用のHARQプロセス数が3のときは、LBRMを用いた総ソフトチャネルビット数は、1056*3*1*3/2=4752ビットであり得る。
【００３８】
図8Aに示した例は、第三HARQプロセスにSF7を用いることを示すが、図8Bは、SF7がHARQプロセスに用いられない例を示す。従って、最大HARQプロセス数は、図8Bでの移行時間1msを有する低コストMTC  UEでの半二重については、2である。表3に示すように、FD-HDD用のHARQプロセス数が2のときは、LBRMを用いた総ソフトチャネルビット数は、1056*3*1*2/2=3168ビットであり得る。
【００３９】
１つのシステム情報ブロック(SIB)-1のHARQバッファを考慮すると、低コストのTC  UEでの半二重用の最大HARQプロセス数は、4であり、表3に示すように、HD-FDD用の総ソフトチャネルビット数4752であることに対応する。半二重の低コストMTC  UEの最大HARQプロセス数は、最もコストが小さいものでもあり得る。表3に示すように、HDD-FDD用のHARQプロセス数が1であるときは、LBRMを用いた総ソフトチャネルビット数は、1056*3*1*1/2=1584ビットであり得る。
【表３】
0006328802.tif 000004
【００４０】
図3に示した値のいくつかは、全二重FDD(FD-HDD)にも適用し得る。さらに、表3に示した値は、例として提供したのであり、当業者であれば、本明細書の開示から、システム構成への変更により、総ソフトチャネルビット数についての異なる結果を生成し得ることが理解するだろう。例えば、表4は、最大TBS=968ビットのときと最大TBS=1032ビットのときの所定のシステムパラメータのバリエーションを示す。表5及び表6は、総ソフトチャネルビット数の変更結果を示す。
【表４】
0006328802.tif 000005
【表５】
0006328802.tif 000006
【表６】
0006328802.tif 000007
【００４１】
他のパラメータを、HARQプロセス数を減らすのに変更し得る。例えば、図9A及び図9Bは異なるHARQ巡回タイマ(RRT)を有する低コストのMTC  UEについてのHARQプロセス例を図示する。HARQ  RRTタイマは、DL  HARQ再送信がUEによって期待される前の最小サブフレーム量を特定するパラメータである。図9Aは、HARQ  RTTタイマ=14について送信ギャップ1msを有するHARQ動作を示す。HARQタイマを8から14に変更することによって、最大HARQプロセス数は4になる。同様に、図9は、HARQ  RTTタイマ=7について送信ギャップ1msを有するHARQ動作を示す。HARQ  RTTタイマを8から7に変更することによって、最大HARQプロセス数は2つになる。
【００４２】
HARQプロセス数とHARQ  RTTタイマとはトレードオフの関係にあり得る。HARQ  RTTタイマを大きくすると、最大HARQプロセス数は大きくなり得る。例えば、HARQ  RTT=21の場合は、最大HARQプロセス数は6になる。
【００４３】
表7は、さらに、さまざまHARQ  RTTタイマ及び対応する最大HARQプロセス数の例を示す。所定の実施形態によれば、HARQ  RTTタイマと最大HARQプロセス数との関係は、2*(HARQ  RTTタイマ)/7で与えられる。
【表７】
0006328802.tif 000008
【００４４】
図10は、モバイルデバイス(UE、モバイルステーション(MS)、モバイル無線デバイス、モバイル通信デバイス、タブレット、ハンドセット、その他の種類の無線通信デバイス等)の図示例である。モバイルデバイスは、送信局(基地局(BS)、eNB、ベースバンドユニット(BBU)、遠隔無線ヘッド(RRH)、遠隔無線エクイップメント(RRE)、リレー局(RS)、無線エクイップメント(RE)、その他の種類の無線ワイドエリアネットワーク(WWAN)アクセスポイント等)と通信するように構成された一つ以上のアンテナを含み得る。モバイルデバイスは、少なくとも一以上の無線通信規格(3GPP  LTE、WiMAX、高速パケットアクセス(HSPA)、Bluetooth(登録商標)及びWiFiが含まれる)を用いて通信するように構成され得る。モバイルデバイスは、無線通信規格ごとに別々のアンテナを用いて、又は複数の無線通信規格についての共有アンテナを用いて通信し得る。モバイルデバイスは、無線ローカルエリアネットワーク(WLAN)、無線パーソナルエリアネットワーク(WPAN)及び/又はWWAN内で通信し得る。
【００４５】
図10は、また、モバイルデバイスの音響入出力に用いられ得る、マイク及び一以上のスピーカーの図を提供している。ディスプレイ画面は、液晶(LCD)画面又は、他の種類のディスプレイ画面(有機発光ダイオード(OELD)ディスプレイ等)であり得る。ディスプレイ画面はタッチスクリーンとして構成され得る。タッチスクリーンは、容量方式、抵抗方式、その他の種類のタッチスクリーン技術を用い得る。アプリケーションプロセッサ及びグラフィックプロセッサは内部メモリに結合されて、処理及び表示能力を提供する。不揮発性メモリポートも用いられてユーザーにデータ入出力オプションを提供する。不揮発性メモリポートは、モバイルデバイスのメモリ能力を拡張するのに用いられ得る。キーボードがモバイルデバイスに統合されて、又はモバイルデバイスに無線で接続されて、追加のユーザ入力を提供し得る。タッチスクリーンを用いて、仮想キーボードも提供され得る。
【００４６】
追加の実施形態例
さらなる実施形態例は次のようである。
【００４７】
実施例1は、LTEネットワークを通じて通信するように構成されたMTCデバイスであって、無線トランシーバと、ソフトバッファと、信号処理部と、を含む。
前記無線トランシーバは、前記LTEネットワークを介して信号を受信する。
前記ソフトバッファは、最大HARQプロセス数にまでの複数のソフトチャネルビットを記憶するように構成される。
前記信号処理部は、前記最大HARQプロセス数、サブブロックインタリーブサイズ、符号化率及びコードブロック数に基づく総ソフトチャネルビット数を決定し、
LBRMを用いて、前記ソフトバッファ内に、前記総ソフトチャネルビット数より小さい数のソフトチャネルビットを記憶する。
【００４８】
実施例2では、実施例1の前記小さい数は、前記総ソフトチャネルビット数の半分を含む。
【００４９】
実施例3では、実施例1又は2の前記ソフトバッファは、前記総ソフトチャネルビット数より小さい数だけ記憶するサイズとされる。
【００５０】
実施例4では、実施例1から3のいずれか一つの当該MTCデバイスは、LTEネットワーク内で、eNBとのダウンリンク通信用の総ソフトチャネルビット数25344に対応するUEカテゴリに定義される、前記総ソフトチャネルビット数より小さい数は、12672ビットを含む。
【００５１】
実施例5では、実施例1から4のいずれか一つの前記最大HARQプロセス数は8である。
【００５２】
実施例6では、実施例1から5のいずれか一つの前記信号プロセッサは、HD-FDD用に、前記最大HARQプロセス数より小さい数に基づいた前記総ソフトチャネルビット数を決定する。
【００５３】
実施例7では、実施例6の前記最大HARQプロセス数より小さい数は4つのHARQプロセスを含み、前記総ソフトチャネルビット数より小さい数は6336ビットを含む。
【００５４】
実施例8では、実施例6又は7の前記最大HARQプロセス数を小さい数は3つのHARQプロセスを含み、前記総ソフトチャネルビット数より小さい数は4752ビットを含む。
【００５５】
実施例9では、実施例1から8のいずれか一つの前記信号プロセッサは、前記最大HARQプロセス数より小さい数に基づいた前記総ソフトチャネルビット数を決定し、前記最大HARQプロセス数より小さい数は、HARQ  RTTタイマに基づく。
【００５６】
実施例10は、MTCデバイスに対応する無線信号を受信する工程を含む方法である。
当該方法は、前記無線信号を復調して、転送ブロックに対応する複数の受信LLRを生成する工程を含む。
当該方法は、受信した前記LLRに、制限した回数で前回の無線信号による前記転送ブロックについての記憶されたLLRを組み合わせる工程を含む。
当該方法は、組み合わせた前記LLRの復号をする工程と、
巡回冗長検査を行って、前記復号が失敗したことを判定する工程と、を含む。
当該方法は、前記復号が失敗したと判定したことに応じて、制限バッファレートマッチングを行って、ソフトバッファ内に制限した数の、組み合わせた前記LLRを記憶して、前記転送ブロックに対応する少なくとも一つ以上の追加の無線信号の送信を要求する工程と、を含む。
【００５７】
実施例11では、実施例10の前記制限バッファレートマッチングを行う工程は、前記ソフトバッファ内に、組み合わせた前記LLRの半分を記憶する工程を含む。
【００５８】
実施例12では、実施例10又は11の前記MTCデバイスは、LTEネットワークを通じて通信するように構成された低コストのMTCデバイスである。
【００５９】
実施例13では、実施例12の前記低コストのMTCデバイスは、カテゴリー0のUEを含む。
【００６０】
実施例14では、実施例10から13のいずれか一つの前記転送ブロックに対応する少なくとも一つ以上の追加の無線信号の送信を要求する工程は、ハイブリッド自動再送信要求(HARQ)プロセスの一部であり、当該方法は、ネットワークノードを有する半二重周波数分割複信を用いることに基づき、転送ブロックについての最大HARQプロセス数を小さくする工程を含む。
【００６１】
実施例15では、実施例10から14のいずれか一つの前記転送ブロックに対応する少なくとも一つ以上の追加の無線信号の送信を要求する工程は、ハイブリッド自動再送信要求(HARQ)プロセスの一部であり、当該方法は、HARQ  RTTタイマ値に基づき、前記転送ブロックについての最大HARQプロセス数を小さくする工程を含む。
【００６２】
実施例16は、実施例10から15のいずれか一つの方法を実行する手段を含む、装置。
【００６３】
実施例17は、実行により、実施例10から15のいずれか一つの方法を実装する、機械読み取り可能な命令を含む、機械読み取り可能ストレージ。
【００６４】
実施例18は、実施例10から15のいずれか一つの方法を行うように構成された処理論理を含む、装置。
【００６５】
実施例19は、LTEネットワークを通じて通信する方法である。当該方法は、前記LTEネットワークを通じて信号を受信する工程と、最大HARQプロセス数までの複数のソフトチャネルビットを記憶する工程を含む。当該方法は、前記最大HARQプロセス数、サブブロックインタリーブサイズ、符号化率及びコードブロック数に基づく総ソフトチャネルビット数を決定する工程を含む。当該方法は、LBRMを用いて、前記ソフトバッファ内に、前記総ソフトチャネルビット数より小さい数のソフトチャネルビットを記憶する。
【００６６】
実施例20は、実施例19の方法を行う手段を含む装置である。
【００６７】
実施例21は、実施例19又は20の装置を実現する方法を実装する、機械読み取り可能な命令を含む、機械読み取り可能ストレージである。
【００６８】
実施例22は、実施例19の方法を行うように構成された処理論理を含む、装置。
【００６９】
実施例23は、一以上のプロセッサに、方法を行わせる、プログラムコードを記憶するコンピュータ読み取り可能記憶媒体を含むコンピュータプログラムプロダクトである。当該方法は、
ロングタームエボリューション(LTE)ネットワーク内で進化型NodeB(eNB)との接続を確立する工程と、
前記eNBとの全二重周波数分割複信について、最大自動再送信要求(HARQ)プロセス数を決定する工程と、
前記eNBとの半二重周波数分割複信について、前記最大HARQプロセス数より小さい数を決定する工程であって、当該小さい数は、前記最大HARQプロセス数よりも小さい、工程と、
前記小さいHARQプロセス数に基づいた総ソフトチャネルビット数を決定する工程と、
ソフトバッファに、前記総ソフトチャネルビット数より小さい数のソフトチャネルビットを記憶する工程とを含む。
【００７０】
実施例24は、実施例23の主題を含み、前記総ソフトチャネルビット数より小さい数のソフトチャネルビットを記憶する工程は、制限バッファレートマッチングを行う工程を含む。
【００７１】
実施例25は、実施例23又は24の主題を含み、前記総ソフトチャネルビット数より小さい数は、前記総ソフトチャネルビット数の半分を含む。
【００７２】
実施例26は、実施例23から25のいずれか一つの主題を含み、前記ソフトバッファは、前記総ソフトチャネルビット数より小さい数だけ記憶するサイズとされた。
【００７３】
実施例27は、当該方法が、前記eNBとの半二重周波数分割複信用のマシンタイプコミュニケーションデバイスとしてユーザエクイップメント(UE)を構成することをさらに含む。
【００７４】
本明細書で開示された種々の技術及び、それらの所定の観点又は部分は、有形媒体(フロッピーディスク(登録商標)、CD-ROM、ハードドライブ、不揮発性コンピュータ読み取り可能記憶媒体又は、その他の機械読み取り可能記憶媒体(プログラムコードが機械(例えば、コンピュータ)にロードされ、実行されるときに、その機械が種々の技術を実施する装置となるもの)等)に組み込まれたプログラムコード(つまり、命令)の形式をとり得る。プログラマブルコンピュータ上でプログラムコード実行する場合、コンピューティングデバイスは、プロセッサ、プロセッサにより読み取り可能な記憶媒体(揮発性・不揮発性メモリ及び/又は記憶要素を含む)、少なくとも一の入力デバイスおよび少なくとも一の出力デバイスを含み得る。揮発性・不揮発性メモリは、RAM、EPROM、フラッシュドライブ、光学ドライブ、磁気ハードディスク、その他の電子データを記憶する媒体を含み得る。eNB(又は、他の基地局)及びUE(又は他の移動局)は、トランシーバコンポーネント、計数コンポーネント、処理コンポーネント及び又はクロックコンポーネント若しくはタイマコンポーネントをも含み得る。本明細書で記載された種々の技術を実装又は利用し得る一以上のプログラムはアプリケーションプログラミングインタフェース(API)、再利用制御等を用い得る。そのようなプログラムは、高レベル処理又はオブジェクト指向の言語で実装されて、コンピュータシステムと通信し得る。しかし、プログラムは、所望により、アセンブリ又は機械言語で実装され得る。いずれの場合でも、言語はコンパイラ型又はインタプリタ型言語であり、ハードウェア実装と組み合わされ得る。
【００７５】
本明細書に記載された多くの機能部は一以上のモジュール又はコンポーネントとして実装されることが理解されるべきである。モジュール又はコンポーネントは、それらの実装独立性をより特に強調するのに用いられる文言である。例えば、モジュール又はコンポーネントは、ハードウェア回路として実装され得る。ハードウェア回路は、カスタム大規模集積(VLSI)回路又はゲートアレイ、論理チップなどの既製半導体、トランジスタ、その他のディスクリートコンポーネントを含む。モジュール又はコンポーネントは、プログラマブルハードウェアデバイス(フィールドプログラマブルゲートアレイ、プログラマブルアレイ論理、プログラマブル論理デバイス等)にも実装し得る。
【００７６】
モジュール又はコンポーネントは、種々のタイプのプロセッサによる実行用にソフトウェアにも実装され得る。実行可能な識別コンポーネントは、例えば、コンピュータ命令の一以上の物理的又は論理的ブロックを含み得る。コンピュータ命令は、例えば、オブジェクト、プロシージャ又は関数として構造化され得る。しかし、識別モジュール又はコンポーネントの実行ファイルは物理的に一緒の場所にある必要はなく、異なる場所に記憶された異種の命令を含み、論理的に一緒に結合したときは、そのモジュール又はコンポーネントを含み、そのモジュール又はコンポーネントの明示の目的を達成する。
【００７７】
実際には、実行コードのモジュール又はコンポーネントは、単一命令又は複数命令であり得るし、複数の異なるコードセグメント、異なるプログラム、複数のメモリデバイスにまたがって分散されてよい。同様に、動作データがモジュール又はコンポーネント内に、本明細書において、識別され、図示され、任意の好適な形式で実施され、任意の好適なタイプのデータ構造体内で構造化され得る。動作データは、単一データセットとして集められてよく、異なる記憶デバイスであることを含む異なる場所に分散されてよく、少なくとも部分的には、システム又はネットワーク上での単なる電子信号として存在してもよい。モジュール又はコンポーネントは、パッシブ又はアクティブでよく、所望能機能を行うのに動作可能なエージェントを含む。
【００７８】
この明細書を通じて「実施例(example)」についての参照は、実施例に関連した特定の特徴、構造又は特性が本発明の少なくとも一の実施形態に含まれることを意味する。ゆえに、この明細書を通じて、種々の所で「実施例において」との表現が現れるが、必ずしも、同じ実施形態について参照していない。
【００７９】
本明細書で用いたように、複数の項目、構造的要素、組成要素及び/又は材料は便宜上常用リストに提示され得る。しかし、これらのリストは、リストの各要素が分離した独自の部材として個々に識別されるかのように解釈するべきである。ゆえに、そのようなリストの個々の部材は、逆の示唆がなければ、共通グループ内の提示に基づいてのみ、事実上、同じリストの他の部材と等価であると解釈されるべきではない。また、本発明の種々の実施形態及び実施例が、それらの種々のコンポーネントに対する代替物とともに、本明細書にて言及され得る。そのような実施形態、実施例及び代替物は、事実上、互いに等価なものとして解釈されるべきではなく、本発明の分離した自立性の表現物と見なされる。
【００８０】
前述のものは、明確性を目的として、いくぶん詳細に記載されているが、本質を逸脱することなく、所定の変更及び修正がなされ得ることは明らかであろう。本明細書で記載された処理及び装置を実装する多くの代替方法があることには留意すべきである。従って、本実施形態は例示的かつ非限定的なものとみなされ、本発明は本明細書に与えた詳細に限定されず、添付の請求項の範囲及び均等物において修正し得るものである。
【００８１】
本発明の基本的な原理を逸脱することなく、当業者によって多くの変更が上記記載の実施形態の詳細に対してなされ得ると理解されるだろう。それゆえ、本発明の範囲は、次の請求項によってのみ決定されるべきである。
【図１】
0006328802.tif 000009
【図２】
0006328802.tif 000010
【図３】
0006328802.tif 000011
【図４】
0006328802.tif 000012
【図５Ａ】
0006328802.tif 000013
【図５Ｂ】
0006328802.tif 000014
【図６Ａ】
0006328802.tif 000015
【図６Ｂ】
0006328802.tif 000016
【図７Ａ】
0006328802.tif 000017
【図７Ｂ】
0006328802.tif 000018
【図８Ａ】
0006328802.tif 000019
【図８Ｂ】
0006328802.tif 000020
【図９Ａ】
0006328802.tif 000021
【図９Ｂ】
0006328802.tif 000022
【図１０】
0006328802.tif 000023