(57)【要約】  本開示は、非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理アップリンク共有チャネルを介してデータを送信することに関する。例示的な装置は、アップリンクデータ送信に応じて開始し、第１の所定の時間が経過した後に停止するように構成されている第１のタイマと、第１のタイマの停止に応じて開始し、第２の所定の時間が経過した後に停止するように構成された第２のタイマと、アップリンク新規データ送信または再送信の肯定応答を含むダウンリンク制御情報を受信するための受信部とを備え、受信部は、第１のタイマが停止しており、第２のタイマが作動しているときのみ受信を行うように構成されており、第２のタイマは、肯定応答の受信を受けて停止するようにさらに構成されている。さらに、データを受信し、制御チャネルを送信する装置ならびに対応する送信および受信方法が提供される。
2019516281.tif 000002
【特許請求の範囲】
【請求項１】
非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理アップリンク共有チャネルを介してデータを送信する装置であって、前記装置は、
アップリンクデータ送信に応じて開始し、第１の所定の時間が経過した後に満了するように構成されている第１のタイマと、
前記第１のタイマの満了に応じて開始し、第２の所定の時間が経過した後に満了するように構成された第２のタイマと、
アップリンク新規データ送信または再送信の肯定応答を含むダウンリンク制御情報を受信する受信部であって、前記受信部は、前記第１のタイマが満了しており、前記第２のタイマが作動しているときのみ前記受信を行うように構成されている、受信部と、
を備え、
前記第２のタイマは、前記肯定応答の受信に応じて停止するようにさらに構成されている、装置。
【請求項２】
前記受信部は、前記アップリンクデータが成功裏に復号されなかったことを示すために、前記アップリンクデータの再送信のためのリソース割当を含むダウンリンク制御情報を受信するようにさらに構成されており、
前記装置は、前記アップリンクリソース割当の受信に応じて、物理アップリンク共有チャネルにおいて前記受信したリソース割当に従って、前記アップリンクデータのＨＡＲＱ再送信を実行する送信部をさらに備える、請求項１に記載の装置。
【請求項３】
前記肯定応答の受信に応じてＨＡＲＱ送信バッファをフラッシュし、前記受信部が前記物理ダウンリンク制御チャネルを受信しないように構成される不連続受信モードに入るＨＡＲＱコントローラをさらに備える、請求項１または２に記載の装置。
【請求項４】
前記ダウンリンク制御情報は、新しい送信と再送信とを区別するフィールドを伴う前記肯定応答または前記リソース割当のいずれかを示す、請求項１〜３のいずれか一項に記載の装置。
【請求項５】
前記ダウンリンク制御情報は、
−別個の１ビットフィールド、および、
−他の様態ではアップリンク送信の無効または不一致の割り当てとして解釈される、フィールド内の値の組み合わせ、
のうちの少なくとも１つにおいて前記肯定応答および／またはバッファフラッシュコマンドを示す、請求項１〜４のいずれか一項に記載の装置。
【請求項６】
前記通信ネットワークへの接続を解放し、前記受信部がブロードキャストチャネルのみを受信するように構成されるアイドルモードに入るように、前記装置を制御するコントローラを含む、請求項１〜５のいずれか一項に記載の装置。
【請求項７】
非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理ダウンリンク共有チャネルを介してデータを受信する装置であって、
ダウンリンク送信のリソース割当を含むダウンリンク制御情報を受信し、それに従って、前記割り当てられたリソースにおいてデータの受信を実行し、前記ダウンリンク送信に関連する確認応答の送信を実行するように構成されている受信部を備え、
前記装置は、ダウンリンクデータ送信に応じて開始し、所定の時間が経過した後に満了するように構成された第４のタイマと、
前記第４のタイマの満了に応じて開始し、第２の所定の時間が経過した後に満了するように構成された第５のタイマと、
をさらに備え、
前記受信部は、前記第４のタイマが満了しており、前記第５のタイマが作動しているときのみダウンリンク制御情報の受信を行うように構成されており、前記第５のタイマは、肯定応答の送信に応じて開始しないようにさらに構成されている、装置。
【請求項８】
前記第５のタイマは、前記受信部が前記ダウンリンクデータ送信のための肯定応答を送信するか否かに関係なく開始するようにさらに構成される、請求項７に記載の装置。
【請求項９】
非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理アップリンク共有チャネルを介してデータを受信する装置であって、前記装置は、
アップリンクデータ受信に応じて開始し、第１の所定の時間が経過した後に満了するように構成されている第１のタイマと、
前記第１のタイマの満了に応じて開始し、第２の所定の時間が経過した後に満了するように構成された第２のタイマと、
アップリンク新規データ送信または再送信の肯定応答を含むダウンリンク制御情報を送信する送信部であって、前記送信部は、前記第１のタイマが満了しており、前記第２のタイマが作動しているときのみ前記送信を行うように構成されている、送信部と、
を備え、
前記第２のタイマは、前記肯定応答の送信に応じて停止するようにさらに構成されている、装置。
【請求項１０】
非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理アップリンク共有チャネルを介してデータを送信する方法であって、
アップリンクデータ送信に応じて第１のタイマを開始し、第１の所定の時間が経過した後に前記第１のタイマを満了させるステップと、
前記第１のタイマの満了に応じて第２のタイマを開始し、第２の所定の時間が経過した後に前記第２のタイマを満了させるステップと、
アップリンク新規データ送信または再送信の肯定応答を含むダウンリンク制御情報を受信するステップと、
を含み、
前記受信するステップは、前記第１のタイマが満了し、前記第２のタイマが作動しているときのみ行われ、
前記第２のタイマは、前記肯定応答の受信に応じて停止する、方法。
【請求項１１】
前記アップリンクデータが成功裏に復号されなかったことを示すために、前記アップリンクデータの再送信のためのリソース割当を含むダウンリンク制御情報を受信するステップと、
前記アップリンクリソース割当の受信に応じて、物理アップリンク共有チャネルにおいて前記受信したリソース割当に従って、前記アップリンクデータのＨＡＲＱ再送信を実行するステップと、
をさらに含み、
前記ダウンリンク制御情報は、新たな送信と再送信とを区別するフィールドを伴う前記肯定応答または前記リソース割当のいずれかを示す、請求項１０に記載の方法。
【請求項１２】
前記肯定応答の受信に応じてＨＡＲＱ送信バッファをフラッシュし、前記受信部が前記物理ダウンリンク制御チャネルを受信しないように構成された不連続受信モードに入るか、または、前記通信ネットワークへの接続を解放し、前記受信部がブロードキャストチャネルのみを受信するように構成されるアイドルモードに入るＨＡＲＱコントローラをさらに備える、請求項１０または１１に記載の方法。
【請求項１３】
前記ダウンリンク制御情報は、
−別個の１ビットフィールド、および、
−他の様態ではアップリンク送信の無効または不一致の割り当てとして解釈される、フィールド内の値の組み合わせ、
のうちの少なくとも１つにおいて前記肯定応答および／またはバッファフラッシュコマンドを示す、請求項１０〜１２のいずれか一項に記載の方法。
【請求項１４】
非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理ダウンリンク共有チャネルを介してデータを受信する方法であって、前記方法は、
ダウンリンク送信のリソース割当を含むダウンリンク制御情報を受信し、それに従って、前記割り当てられたリソースにおいてデータの受信を実行し、前記ダウンリンク送信に関連する確認応答を送信するステップと、
前記ダウンリンクデータ送信に応じて第４のタイマを開始し、所定の時間が経過した後に前記第４のタイマを満了させるステップと、
前記第４のタイマの満了に応じて第５のタイマを開始し、第２の所定の時間が経過した後に前記第５のタイマを満了させるステップであって、前記第５のタイマは、前記受信部が前記ダウンリンクデータ送信の肯定応答を送信するか否かにかかわらず開始する、ステップと、
前記第４のタイマが満了しており、前記第５のタイマが作動しているときのみダウンリンク制御情報を受信するステップであって、前記第５のタイマは、肯定応答の送信に応じて停止する、ステップと
を含む、方法。
【請求項１５】
非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理アップリンク共有チャネルを介してデータを受信するための方法であって、
アップリンクデータ受信に応じて第１のタイマを開始し、第１の所定の時間が経過した後に前記第１のタイマを満了させるステップと、
前記第１のタイマの満了に応じて第２のタイマを開始し、第２の所定の時間が経過した後に前記第２のタイマを満了させるステップと、
アップリンク新規データ送信または再送信の肯定応答を含むダウンリンク制御情報を送信するステップと、
を含み、
前記送信するステップは、前記第１のタイマが満了し、前記第２のタイマが作動しているときのみ行われ、
前記第２のタイマは、前記肯定応答の送信に応じて停止する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、アップリンク物理共有チャネルを介してデータを送信するための非同期ハイブリッド自動再送要求（ＨＡＲＱ）に関する。
【背景技術】
【０００２】
［ロングタームエボリューション（ＬＴＥ：Long Term Evolution）］
広帯域符号分割多元接続（ＷＣＤＭＡ（登録商標）：Wideband Code Division Multiple Access）無線アクセス技術に基づく第３世代（３Ｇ）モバイルシステムが、世界中で広範に展開されている。この技術の向上または進化の最初のステップは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：High-Speed Downlink Packet Access）および高速アップリンクパケットアクセス（ＨＳＵＰＡ：High-Speed Downlink Packet Access）とも呼ばれる強化されたアップリンクを導入しており、競争力のある無線アクセス技術を提供している。ユーザ需要の増大に備え、新しい無線アクセス技術に対する競争力を付けるために、３ＧＰＰはさらに、ロングタームエボリューション（ＬＴＥ）と呼ばれる新しい移動通信システムを導入した。ＬＴＥは、高速データ、メディア転送、および、大容量音声サポートについて、今後１０年間を見越したキャリア需要を満たすように設計されている。高いビットレートを提供する能力は、ＬＴＥの重要な尺度である。進化型ＵＭＴＳ地上無線アクセス（ＵＴＲＡ：UMTS Terrestrial Radio Access）およびＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ：UMTS Terrestrial Radio Access Network）と呼ばれるロングタームエボリューション（ＬＴＥ）に関する作業項目（ＷＩ）仕様が、リリース８においてまとめられている。ＬＴＥシステムは、完全にＩＰベースの機能を提供する、効率的なパケットベースの無線アクセスおよび無線アクセスネットワークを表す。ＬＴＥでは、所与のスペクトルを使用して柔軟なシステム展開を達成するために、スケーラブルな多重送信帯域幅が１．４，３．０，５．０，１０．０，１５．０および２０．０ＭＨｚなどのように指定される。ダウンリンク（ネットワークからユーザへの方向）では、低シンボルレートによってもたらされるマルチパス干渉（ＭＰＩ）に対するその固有の耐性、サイクリックプレフィックス（ＣＰ）の使用、および種々の送信帯域幅構成に対するその親和性のために、直交周波数分割多重（ＯＦＤＭ）ベースの無線アクセスが採用された。ユーザ機器（ＵＥ：User Equipment）の送信電力が制限されていることを考慮してピークデータレートの改善よりも広いエリアカバレッジを提供することが優先されるため、アップリンク（ユーザからネットワークへの方向）においてはシングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）ベースの無線アクセスが採用された識別情報を含む。多入力多出力（ＭＩＭＯ）チャネル送信技術を含む多くの重要なパケット無線アクセス技術が使用され、非常に効率的な制御シグナリング構造がリリース８ＬＴＥにおいて採用されている。
【０００３】
［ＬＴＥアーキテクチャ］
全体的なＬＴＥアーキテクチャが図１に示されており、一方、Ｅ−ＵＴＲＡＮアーキテクチャのより詳細な表現が図２に示されている。Ｅ−ＵＴＲＡＮは、ＵＥに向けてＥ−ＵＴＲＡユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）プロトコル終端を提供するｅＮＢから構成される。ｅＮＢは、ユーザプレーンのヘッダ圧縮および暗号化の機能を含む物理（ＰＨＹ）、媒体アクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）、およびパケットデータ制御プロトコル（ＰＤＣＰ）層をホストする。また、これは制御プレーンに対応する無線リソース制御（ＲＲＣ）機能を提供する。Ｅ−ＵＴＲＡは、無線リソース管理、許可制御、スケジューリング、交渉されたアップリンク（ＵＬ）サービス品質（ＱｏＳ）の実施、セル情報ブロードキャスト、ユーザおよび制御プレーンデータの暗号化／解読、ならびにダウンリンク（ＤＬ）またはＵＬユーザプレーンパケットヘッダの圧縮／解凍を含む多くの機能を実行する。ｅＮＢは、Ｘ２インターフェースを使用して相互に接続される。また、ｅＮＢは、Ｓ１インターフェースによってＥＰＣ（進化型パケットコア（Evolved Packet Core））に、より具体的にはＳ１−ＭＭＥによってＭＭＥ（モビリティ管理エンティティ（Mobility Management Entity））に接続され、Ｓ１−Ｕによってサービングゲートウェイ（Ｓ−ＧＷ）に接続される。Ｓ１インターフェースは、ＭＭＥ／サービングゲートウェイとｅＮＢとの間の多対多の関係をサポートする。ＳＧＷは、ｅＮＢ間のハンドオーバ中にユーザプレーンのモビリティアンカとして、また、ＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカとしても機能しながら、ユーザデータパケットをルーティングおよび転送する（Ｓ４インターフェースを終端し、２Ｇ／３ＧシステムとＰＤＮ  ＧＷとの間のトラフィック中継する）。アイドル状態のＵＥの場合、ＳＧＷは、ＤＬデータパスを終端し、ＤＬデータがＵＥに到来するとページングをトリガする。これは、ＵＥコンテキスト、例えば、ＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報を管理し格納する。これはまた、合法的傍受の場合にユーザトラフィックの複製を実行する。
【０００４】
ＭＭＥは、ＬＴＥアクセスネットワークの重要な制御ノードである。これは、再送信を含むアイドルモードＵＥ追跡およびページング手順の役割を担う。それは、ベアラ起動／停止プロセスに関与し、最初のアタッチ時およびコアネットワーク（ＣＮ）ノード再配置を含むＬＴＥ内ハンドオーバ時にＵＥのＳＧＷを選択する役割も担う。それは、（ＨＳＳとの相互作用により）ユーザの認証の役割を担う。非アクセス層（ＮＡＳ）シグナリングは、ＭＭＥにおいて終端し、一時的アイデンティティを生成し、ＵＥに割り当てる役割も担う。それは、ＵＥがサービスプロバイダの公衆地上移動ネットワーク（ＰＬＭＮ）にキャンプオンするための権限をチェックし、ＵＥローミング制限を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／完全性保護のためのネットワーク内の終端点であり、セキュリティキー管理を処理する。シグナリングの合法的傍受もＭＭＥによってサポートされる。ＭＭＥはまた、ＳＧＳＮからのＭＭＥにおいて終端するＳ３インターフェースを用いてＬＴＥと２Ｇ／３Ｇアクセスネットワークとの間のモビリティのための制御プレーン機能を提供する。ＭＭＥはまた、ＵＥをローミングするためのホームＨＳＳに向かうＳ６ａインターフェースを終端する。
【０００５】
［ＬＴＥにおけるコンポーネントキャリア構造］
３ＧＰＰ  ＬＴＥ（リリース８以降）のダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおいて時間−周波数領域に細分化される。３ＧＰＰ  ＬＴＥ（リリース８以降）において、各サブフレームは２つのダウンリンクスロットに分割され、そのうちの１つが図３に示されている。第１のダウンリンクスロットは、第１のＯＦＤＭシンボル内の制御チャネル領域（ＰＤＣＣＨ領域）を含む。各サブフレームは、時間領域において所与の数のＯＦＤＭシンボル（３ＧＰＰ  ＬＴＥリリース８以降では１２個または１４個のＯＦＤＭシンボル）から構成され、各ＯＦＤＭシンボルは、コンポーネントキャリアの帯域幅全体にわたる。したがって、ＯＦＤＭシンボルは各々、それぞれの
【数１】
2019516281.tif 000003
個のサブキャリア上で送信されるいくつかの変調シンボルから構成される。例えば、例として３ＧＰＰロングタームエボリューション（ＬＴＥ）で使用されるようなＯＦＤＭを利用するマルチキャリア通信システムを想定すると、スケジューラによって割り当てることができるリソースの最小単位は、１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ）は、図３に説明されているように、時間領域における
【数２】
2019516281.tif 000004
個の連続するＯＦＤＭシンボル（例えば、７個のＯＦＤＭシンボル）および周波数領域における
【数３】
2019516281.tif 000005
個の連続するサブキャリア（例えば、コンポーネントキャリアの１２個のサブキャリア）として定義される。したがって、３ＧＰＰ  ＬＴＥ（リリース８）では、物理リソースブロックは、時間領域の１つのスロットおよび周波数領域の１８０ｋＨｚに対応する
【数４】
2019516281.tif 000006
個のリソースエレメントから構成される（ダウンリンクリソースグリッドのさらなる詳細については、例えば、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇにおいて利用可能であり、参照により本明細書に組み込まれる非特許文献１を参照されたい）。
【０００６】
１つのサブフレームは２つのスロットから構成されており、結果、いわゆる「通常」ＣＰ（巡回プレフィックス）が使用されるとき、サブフレーム内に１４個のＯＦＤＭシンボルが存在し、いわゆる「拡張」ＣＰが使用されるとき、サブフレーム内に１２個のＯＦＤＭシンボルが存在する。用語の説明のために、以下では、サブフレーム全体にわたる同じ
【数５】
2019516281.tif 000007
個の連続するサブキャリアと等価な時間−周波数リソースは、「リソースブロック対」または等価な「ＲＢ対」もしくは「ＰＲＢ対」と呼ばれる。
【０００７】
用語「コンポーネントキャリア」は、周波数領域におけるいくつかのリソースブロックの組み合わせを指す。ＬＴＥの後のリリースでは、「コンポーネントキャリア」という用語はもはや使用されなくなり、代わりに、用語は「セル」に変更されている。これは、ダウンリンクリソースおよび任意選択的にアップリンクリソースの組み合わせを指す。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンクは、ダウンリンクリソース上で送信されるシステム情報上で示される。コンポーネントキャリア構造に対する同様の想定が、後のリリースにも当てはまる。
【０００８】
［レイヤ１／レイヤ２（Ｌ１／Ｌ２）制御シグナリング］
スケジューリングされたユーザにそれらの割当状態、トランスポートフォーマットおよび他のデータに関連する情報（例えば、ＨＡＲＱ情報、送信電力制御（ＴＰＣ）コマンド）をシグナリングするために、Ｌ１／Ｌ２制御シグナリングがデータとともにダウンリンク上で送信される。ユーザ割当がサブフレームごとに変化し得ると仮定して、Ｌ１／Ｌ２制御シグナリングがサブフレーム内のダウンリンクデータと多重化される。ユーザ割当は、ＴＴＩ（送信時間間隔）ベースで実行されてもよく、ＴＴＩの長さはサブフレームの倍数であってもよい。ＴＴＩの長さは、すべてのユーザに対してサービスエリア内で固定されてもよく、異なるユーザに対して異なってもよく、またはさらには各ユーザに対して動的であってもよい。一般に、Ｌ１／２制御シグナリングは、ＴＴＩごとに１回だけ送信すればよい。一般性を失うことなく、以下はＴＴＩが１つのサブフレームと等価であると仮定する。
【０００９】
Ｌ１／Ｌ２制御シグナリングは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）上で送信される。ＰＤＣＣＨは、ほとんどの場合、移動端末またはＵＥのグループのためのリソース割当および他の制御情報を含むダウンリンク制御情報（ＤＣＩ）としてメッセージを搬送する。一般に、いくつかのＰＤＣＣＨを１つのサブフレーム内で送信することができる。３ＧＰＰ  ＬＴＥでは、アップリンクスケジューリンググラントまたはアップリンクリソース割当とも呼ばれるアップリンクデータ送信の割り当ても、ＰＤＣＣＨ上で送信される。
【００１０】
以下では、ＤＬ割当またはアップリンク割当のためにシグナリングされる詳細なＬ１／Ｌ２制御シグナリング情報が以下に説明される。
【００１１】
−ダウンリンクデータ送信：
ダウンリンクのパケットデータ送信とともに、Ｌ１／Ｌ２制御シグナリングが別個の物理チャネル（ＰＤＣＣＨ）上で送信される。このＬ１／Ｌ２制御シグナリングは、通常、以下に関する情報を含む。
・データが送信される物理リソース（複数可）（例えば、ＯＦＤＭの場合はサブキャリアまたはサブキャリアブロック、ＣＤＭＡの場合のコード）。この情報は、ＵＥ（受信部）が、データが送信されるリソースを識別することを可能にする。
・送信に使用されるトランスポートフォーマット。これは、データのトランスポートブロックサイズ（ペイロードサイズ、情報ビットサイズ）、ＭＣＳ（変調符号化方式（Modulation and Coding Scheme））レベル、スペクトル効率、符号化率などであってもよい。この情報は（通常はリソース割当とともに）、ＵＥ（受信部）が、復調、デレートマッチングおよび復号プロセスを開始するために情報ビットサイズ、変調方式およびコードレートを識別することを可能にする。場合によっては、変調方式は明示的にシグナリングされてもよい。
・ハイブリッドＡＲＱ（ＨＡＲＱ）情報：
プロセス番号：ＵＥが、データがマッピングされているハイブリッドＡＲＱプロセスを識別することを可能にする
シーケンス番号または新規データインジケータ：ＵＥが、送信が新しいパケットであるか、または、再送信されたパケットであるかを識別することを可能にする
冗長性および／またはコンスタレーションバージョン：いずれのハイブリッドＡＲＱ冗長バージョン（redundancy version）が使用されているか（デレートマッチングに必要）および／またはいずれの変調コンスタレーションバージョンが使用されているか（復調に必要）をＵＥに伝達する
・ＵＥアイデンティティ（ＵＥ  ＩＤ）：Ｌ１／Ｌ２制御シグナリングがいずれのＵＥ向けに意図されているかを伝達する。典型的な実施形態では、この情報は、他のＵＥがこの情報を読み取ることを防止するために、Ｌ１／Ｌ２制御シグナリングのＣＲＣをマスクするために使用される。
【００１２】
−アップリンクデータ送信：
アップリンクパケットデータ送信を可能にするために、ＵＥに送信詳細に関して伝達するために、ダウンリンク（ＰＤＣＣＨ）上でＬ１／Ｌ２制御シグナリングが送信される。このＬ１／Ｌ２制御シグナリングは、通常、以下に関する情報を含む。
・ＵＥがデータを送信すべき物理リソース（複数可）（例えば、ＯＦＤＭの場合はサブキャリアまたはサブキャリアブロック、ＣＤＭＡの場合はコード）。
・ＵＥが送信に使用すべきトランスポートフォーマット。これは、データのトランスポートブロックサイズ（ペイロードサイズ、情報ビットサイズ）、ＭＣＳ（変調符号化方式（Modulation and Coding Scheme））レベル、スペクトル効率、符号化率などであってもよい。この情報は（通常はリソース割当とともに）、ＵＥ（送信部）が、変調、レートマッチングおよび符号化プロセスを開始するために情報ビットサイズ、変調方式およびコードレートを取得することを可能にする。場合によっては、変調方式は明示的にシグナリングされてもよい。
・ハイブリッドＡＲＱ情報：
プロセス番号：いずれのハイブリッドＡＲＱプロセスからデータを取得すべきかをＵＥに伝達する
シーケンス番号または新規データインジケータ：新しいパケットを送信するか、または、パケットを再送信するかをＵＥに伝達する
冗長性および／またはコンスタレーションバージョン：いずれのハイブリッドＡＲＱ冗長バージョンを使用すべきか（レートマッチングに必要）および／またはいずれの変調コンスタレーションバージョンを使用すべきか（変調に必要）をＵＥに伝達する
・ＵＥアイデンティティ（ＵＥ  ＩＤ）：いずれのＵＥがデータを送信すべきかを指示する。典型的な実施形態では、この情報は、他のＵＥがこの情報を読み取ることを防止するために、Ｌ１／Ｌ２制御シグナリングのＣＲＣをマスクするために使用される。
【００１３】
上記の情報を正確に伝達する方法にはいくつかの異なる特色がある。さらに、Ｌ１／Ｌ２制御情報はまた、追加の情報を含んでもよく、または情報の一部を省略してもよい。例えば：
−同期ＨＡＲＱプロトコルの場合、ＨＡＲＱプロセス番号は必要ない場合がある
−チェイスコンバイニング（Chase Combining）が使用される場合（常に同じ冗長性および／またはコンスタレーションバージョン）または冗長性および／またはコンスタレーションバージョンのシーケンスが予め定義されている場合は、冗長性および／またはコンスタレーションバージョンは必要ない場合がある。
−電力制御情報が、制御シグナリングにさらに含まれてもよい
−例えば、プリコーディングのようなＭＩＭＯ関連制御情報が制御シグナリングにさらに含まれてもよい。
−マルチコードワードＭＩＭＯ送信の場合には、複数のコードワードに対するトランスポートフォーマットおよび／またはＨＡＲＱ情報が含まれてもよい
【００１４】
ＬＴＥにおいてＰＤＣＣＨ上でシグナリングされるアップリンクリソース割当（ＰＵＳＣＨ）の場合、ＬＴＥアップリンクに同期ＨＡＲＱプロトコルが使用されるため、Ｌ１／Ｌ２制御情報はＨＡＲＱプロセス番号を含まない。アップリンク送信に使用されるＨＡＲＱプロセスは、タイミングによって与えられる。さらに、冗長バージョン（ＲＶ）情報はトランスポートフォーマット情報とともに符号化される、すなわちＲＶ情報はトランスポートフォーマット（ＴＦ）フィールドに埋め込まれることに留意されたい。ＴＦまたはＭＣＳフィールドは、例えば、３２個のエントリに対応する５ビットのサイズを有する。３つのＴＦ／ＭＣＳテーブルエントリは、ＲＶ  １，２または３を示すために確保されている。残りのＭＣＳテーブルエントリは、ＲＶ０を暗示的に示すＭＣＳレベル（ＴＢＳ）をシグナリングするために使用される。ＰＤＣＣＨのＣＲＣフィールドのサイズは１６ビットである。ＰＵＳＣＨ上のアップリンクリソース割当のための制御情報に関するさらなる詳細な情報は、ＴＳ３６．２１２セクション５．３．３およびＴＳ３６．２１３セクション８．６に見出すことができる。
【００１５】
ＬＴＥにおいてＰＤＣＣＨ上でシグナリングされるダウンリンク割当（ＰＤＳＣＨ）の場合、冗長バージョン（ＲＶ）は２ビットフィールドにおいて別々にシグナリングされる。さらに、変調次数情報が、トランスポートフォーマット情報とともに符号化される。アップリンクの場合と同様に、ＰＤＣＣＨ上でシグナリングされる５ビットのＭＣＳフィールドがある。エントリのうちの３つは、トランスポートフォーマット（トランスポートブロック）情報を提供しない明示的な変調次数をシグナリングするために確保される。残りの２９個のエントリについて、変調次数およびトランスポートブロックサイズ情報がシグナリングされる。ＰＵＳＣＨ上のアップリンクリソース割当のための制御情報に関するさらなる詳細な情報は、ＴＳ３６．２１２セクション５．３．３およびＴＳ３６．２１３セクション７．１．７に見出すことができる。
【００１６】
［物理ダウンリンク制御チャネル（ＰＤＣＣＨ）および物理ダウンリンク共用チャネル（ＰＤＳＣＨ）］
物理ダウンリンク制御チャネル（ＰＤＣＣＨ）は、例えば、ダウンリンクまたはアップリンクデータ送信のためのリソースを割り当てるスケジューリンググラントを搬送する。１つのサブフレームにおいて複数のＰＤＣＣＨを送信することができる。
【００１７】
ユーザ機器のためのＰＤＣＣＨは、システム帯域幅全体にわたって延伸するサブフレーム内の最初の
【数６】
2019516281.tif 000008
個のＯＦＤＭシンボル（通常、ＰＣＦＩＣＨによって示されるように１つ，２つまたは３つのＯＦＤＭシンボル、例外的な事例においてはＰＣＦＩＣＨによって示されるように２つ、３つ、または４つのＯＦＤＭシンボルのいずれか）上で送信される。システム帯域幅は、通常、セルまたはコンポーネントキャリアのスパンと等価である。時間領域において最初の
【数７】
2019516281.tif 000009
ＯＦＤＭシンボルが占有し、周波数領域における
【数８】
2019516281.tif 000010
個のサブキャリアが占有する領域は、ＰＤＣＣＨ領域または制御チャネル領域とも呼ばれる。周波数領域における
【数９】
2019516281.tif 000011
個のサブキャリア上の時間領域における残りの
【数１０】
2019516281.tif 000012
個のＯＦＤＭシンボルは、ＰＤＳＣＨ領域または共有チャネル領域と呼ばれる（下記参照）。
【００１８】
物理ダウンリンク共有チャネル（ＰＤＳＣＨ）上のダウンリンクグラント（すなわち、リソース割当）について、ＰＤＣＣＨは、同じサブフレーム内の（ユーザ）データ用のＰＤＳＣＨリソースを割り当てる。サブフレーム内のＰＤＣＣＨ制御チャネル領域は、ＣＣＥのセットから構成され、サブフレームの制御領域内のＣＣＥの総数が時間および周波数制御リソース全体にわたって分散される。複数のＣＣＥを組み合わせて、制御チャネルの符号化率を効果的に低減することができる。ＣＣＥは、異なる符号化率を達成するためにツリー構造を使用して所定の方法で組み合わされる。
【００１９】
トランスポートチャネルレベルでは、ＰＤＣＣＨを介して送信される情報は、Ｌ１／Ｌ２制御シグナリング（Ｌ１／Ｌ２制御シグナリングの詳細については上記参照）とも呼ばれる。
【００２０】
サブフレームにおいて受信されるアップリンクリソース割当と、ＰＵＳＣＨにおける対応するアップリンク送信との間には、特定の予め定められたタイミング関係がある。詳細は、参照により本明細書に組み込まれる非特許文献２に与えられる。特に、ＴＳ３６．２１３の表８−２は、ＴＤＤ構成０〜６のパラメータｋを定義し、ここで、ｋは、サブフレームにおいて受信されるアップリンクリソース割当のターゲットの正のオフセットを示す。ＴＤＤ構成０の場合、簡単化のためにここでは省略されるが、アップリンクサブフレーム３および８のタイミングの追加の定義がある。例えば、パラメータｋは、ＴＤＤ構成１のサブフレーム１の場合、６であり、これは、ＴＤＤ構成１のサブフレーム１において受信されるアップリンクリソース割当が、実際にはアップリンクサブフレームであるＴＤＤ構成１のサブフレーム１＋６＝７向けに意図されていることなどを示す。
【００２１】
［レガシーＬＴＥの不連続受信］
ＵＥの妥当なバッテリ消費を提供するために、ＬＴＥ  Ｒｅｌ−８／９ならびにＲｅｌ−１０／１１は、不連続受信（discontinuous reception）（ＤＲＸ）の概念を提供する。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態のＵＥのためにＤＲＸ機能性を構成することができ、結果、常にダウンリンクチャネルを監視する必要はない。
【００２２】
ＤＲＸサイクルは、ＵＥがＰＤＣＣＨを監視（モニタ）する「オンデュレーション（"on duration"）」期間と、ＵＥがバッテリ節約の目的でダウンリンクチャネルの受信をスキップすることができる「ＤＲＸ期間」とから構成される。
【００２３】
「オンデュレーション」期間は、ＤＲＸから起動（waking up）した後の持続時間（ダウンリンクサブフレームにおいてカウントされる）であり、その間、ＵＥがスケジューリングメッセージのためにＰＤＣＣＨを受信（すなわち監視）する。ＵＥがＰＤＣＣＨを成功裏に復号する場合、ＵＥは起動したままであり、ＵＥがＰＤＣＣＨを監視する期間（ダウンリンクサブフレームにおいてカウントされる）を定義する「非アクティブタイマ（"inactivity timer"）」を開始する。ＵＥがこの期間中にＰＤＣＣＨを検出し復号しなければ、ＵＥは再びＤＲＸに入る。ＵＥは、最初の送信のみのためのＰＤＣＣＨの１回の復号の成功後（すなわち、これは再送信には適用されない）、非アクティブタイマを再開する。
【００２４】
ＵＥが起動している総持続時間は、「アクティブ時間（"active time"）」と呼ばれ、ＤＲＸサイクルの「オンデュレーション」、非アクティブタイマが満了していない間にＵＥが連続受信を実行している時間、および、ＵＥが１つのＨＡＲＱ  ＲＴＴの後にＤＬ再送信を待つ間に連続受信を実行している時間を含む。同様に、アップリンクに関して、ＵＥは、アップリンク再送信グラントを受信することができるサブフレームにおいて、すなわち、最大再送信回数に達するまで初期アップリンク送信の後８ｍｓごとに起動する。上記に基づいて、最小アクティブ時間はオンデュレーションに等しい長さであり、最大値は不定（無限）である。さらに、ＰＵＣＣＨ上でＳＲ（スケジューリング要求（scheduling request））を送信した後、ＵＥは、起動してＵＬ−ＳＣＨリソースを割り当てるＰＤＣＣＨを監視する。ＤＲＸ期間は、ＵＥがバッテリ節約の目的でダウンリンクチャネルの受信をスキップすることができるダウンリンクサブフレームの持続時間である。
【００２５】
図６は、ＤＲＸサイクルを示している。ＤＲＸサイクル（すなわち、オンデュレーションおよびＤＲＸ期間の長さ）のパラメータ化は、バッテリ節約と待ち時間との間のトレードオフを伴う。一方で、長いＤＲＸ期間は、ＵＥのバッテリ寿命を延ばすために有益である。例えば、ウェブブラウジングサービスの場合、ユーザがダウンロードされたウェブページを読んでいる間、ＵＥがダウンリンクチャネルを連続的に受信することは、通常、リソースの浪費である。他方、ユーザが別のＷｅｂページを要求する場合など、データ転送が再開されるとき、より速い応答のためにＤＲＸ期間は短いほど良い。
【００２６】
これらの矛盾する要件を満たすために、各ＵＥに対して２つのＤＲＸサイクル（短いサイクルおよび長いサイクル）を構成することができる。短いＤＲＸサイクル、長いＤＲＸサイクルおよび連続受信の間の遷移は、タイマまたはｅＮＢからの明示的なコマンドのいずれかによって制御される。ある意味では、短いＤＲＸサイクルは、ＵＥが長いＤＲＸサイクルに入る前に、遅いパケットが到来する場合の確認期間と考えることができる。ＵＥが短いＤＲＸサイクルにある間にデータがｅＮＢに到来すると、データは次のウェイクアップ時に送信のためにスケジューリングされ、その後ＵＥは連続受信を再開する。他方、短いＤＲＸサイクルの間にｅＮＢにデータが到来しない場合、パケット活動が当面終了したと仮定して、ＵＥは長いＤＲＸサイクルに入る。
【００２７】
利用可能なＤＲＸ値はネットワークによって制御され、非ＤＲＸから開始して最大ｘ秒までである。値ｘは、ＲＲＣ  ＩＤＬＥ状態（すなわち、ＵＥがＲＲＣ接続を確立させ、ページング信号を単にチェックする状態）において使用されるページングＤＲＸと同じ長さであってもよい。測定要件および通知基準は、ＤＲＸ間隔の長さに応じて異なることができる、すなわち、長いＤＲＸ間隔はより緩和された要件を経験し得る。ＤＲＸが設定されている場合、周期的なＣＱＩ／ＳＲＳ通知は、アクティブ時間中にのみＵＥによって送信されるべきである。ＲＲＣは、周期的なＣＱＩ通知をさらに制限して、それらがオンデュレーション中にのみ送信されるようにすることができる。
【００２８】
図７では、サブフレームの粒度（granularity）に基づくＤＲＸサイクルの一例が示されている。ＵＥは、現在アクティブなサイクルに応じて、長いＤＲＸサイクルまたは短いＤＲＸサイクルのいずれかのオンデュレーション期間の間に、（上述のようにＰＤＣＣＨ上のＣ−ＲＮＴＩによって示される）スケジューリングメッセージをチェックする。オンデュレーションの間にスケジューリングメッセージが受信されると、ＵＥは、非アクティブタイマを開始し、非アクティブタイマが作動している間、ＰＤＣＣＨを各サブフレームで監視する。この期間の間、ＵＥは連続受信モードであると考えることができる。非アクティブタイマが作動している間にスケジューリングメッセージが受信されると、ＵＥは非アクティブタイマを再起動し、満了すると、ＵＥは短いＤＲＸサイクルに移行し、「短ＤＲＸサイクルタイマ（"Short DRX cycle timer"）」を開始する。短いＤＲＸサイクルは、ＭＡＣ制御要素によって開始することもできる。短ＤＲＸサイクルタイマが満了すると、ＵＥは長いＤＲＸサイクルに移行する。このＤＲＸ挙動に加えて、「ＨＡＲＱ往復時間（ＲＴＴ：Round Trip Time）タイマ」が、ＵＥがＨＡＲＱ  ＲＴＴの間にスリープすることを可能にする目的で定義される。１つのＨＡＲＱプロセスに対するダウンリンクトランスポートブロックの復号が失敗すると、ＵＥは、少なくとも「ＨＡＲＱ  ＲＴＴ」サブフレームの後にトランスポートブロックの次の再送信が発生すると想定することができる。ＨＡＲＱ  ＲＴＴタイマが作動している間、ＵＥはＰＤＣＣＨを監視する必要はない。ＨＡＲＱ  ＲＴＴタイマの満了時に、ＵＥは通常通りにＰＤＣＣＨの受信を再開する。
【００２９】
ＤＲＸ非アクティブタイマ、ＨＡＲＱ  ＲＴＴタイマ、ＤＲＸ再送信タイマ、および短ＤＲＸサイクルタイマなどのＤＲＸ関連タイマは、ＰＤＣＣＨグラントまたはＭＡＣ制御要素（ＤＲＸ  ＭＡＣ  ＣＥ）の受信などのイベントによって起動および停止される。したがって、ＵＥのＤＲＸ状態（アクティブ時間または非アクティブ時間）は、サブフレームごとに変化する可能性があり、したがって必ずしも予測可能ではない。ＵＥごとに１つのみのＤＲＸサイクルが定義される（長いコンポーネントおよび短いコンポーネントを含み得る）。すべての集約されたコンポーネントキャリア（aggregated component carrier）が、このＤＲＸパターンに従う。
【００３０】
［ＨＡＲＱプロトコル］
ＭＡＣ層は、ＨＡＲＱエンティティを含み、ＨＡＲＱエンティティは、ＨＡＲＱ動作の送信および受信の役割を担う。送信ＨＡＲＱ動作は、トランスポートブロックの送信および再送信、ならびに、ＡＣＫ／ＮＡＣＫシグナリングの受信および処理を含む。受信ＨＡＲＱ動作は、トランスポートブロックの受信、受信データの結合およびＡＣＫ／ＮＡＣＫシグナリングの生成を含む。以前のトランスポートブロックが復号されている間に連続送信を可能にするために、並列な最大８つのＨＡＲＱプロセスが、ＰＤＳＣＨ／ＰＵＳＣＨに採用されているマルチプロセス「ストップアンドウェイト（"Stop-And-Wait"）」（ＳＡＷ）ＨＡＲＱ動作をサポートするために使用される。各ＨＡＲＱプロセスは、別々のＳＡＷ動作の役割を担い、別個のバッファを管理する。
【００３１】
ＨＡＲＱプロトコルによって提供されるフィードバックは、（肯定）確認応答（（Positive）  ＡＣＫ（Acknowledgment））または否定確認応答（ＮＡＣＫ（Negative Acknowledgment）のいずれかである。さらに、ＨＡＲＱ動作では、ｅＮＢは、ＵＥが増分冗長度（ＩＲ：incremental redundancy）合成を利用して、合成ゲインを介して追加の符号化ゲインを得ることができるように、再送信時に元のトランスポートブロックから異なる符号化バージョンを送信することができる。
【００３２】
ターボまたは畳み込み符号化のような順方向誤り符号化（ＦＥＣ）によって符号化されたパケットが送信され、受信部がパケットを正しく復号できない場合（誤りは通常ＣＲＣ、巡回冗長検査によってチェックされる）、受信部はパケットの再送信を要求する。一般的に（また、本明細書全体を通して）、付加的な情報の送信は「（パケットの）再送信（retransmission）」と呼ばれ、この再送信は、必ずしも同じ符号化された情報の送信を意味しない。それはまた、例えば、異なる冗長バージョンを使用した、そのパケットに属する任意の情報（例えば追加の冗長情報）の送信を意味することもできる。
【００３３】
一般に、ＨＡＲＱ方式は、同期または非同期のいずれかとして分類することができ、各事例において再送信は適応的（adaptive）または非適応的（non-adaptive）のいずれかである。同期ＨＡＲＱは、各ＨＡＲＱプロセスのためのトランスポートブロックの再送信が、初期の（以前の）送信に対して予め定義された（周期的な）時間に発生することを意味する。したがって、送信タイミングから推測することができるため、受信部に再送信スケジュールまたは例えばＨＡＲＱプロセス番号を示すために明示的なシグナリングは必要とされない。
【００３４】
対照的に、非同期ＨＡＲＱは、初期の（以前の）送信に対していつでも再送信を行うことを可能にし、これは、エアインターフェース（air interface）の条件およびセル負荷またはＱｏＳなどの他の要因に基づいて、再送信をスケジューリングする柔軟性を提供する。しかしながら、この場合、正しい合成およびＨＡＲＱプロトコル動作を可能にするために、例えば、再送信のためのリソース、および、該当する場合にはＨＡＲＱプロセスを受信部に示すために、追加の明示的なシグナリングが必要とされる。
【００３５】
ＬＴＥでは、ダウンリンクには非同期適応的ＨＡＲＱが使用され、アップリンクには同期ＨＡＲＱが使用される。アップリンクでは、再送信は、例えば、アップリンクグラントにおいて送信属性の新しいシグナリングが提供されるか否かに応じて、適応的または非適応的のいずれかであり得る。アップリンクＨＡＲＱプロトコル動作において（すなわち、アップリンクデータ送信を確認応答するために）、再送信をスケジューリングする方法に関する２つの異なる選択肢がある。再送信は、ＮＡＣＫによって「スケジューリング」される（同期非適応的再送信とも呼ばれる）か、または、ＰＤＣＣＨを送信することによってネットワークによって明示的にスケジューリングされる（同期適応的再送信とも呼ばれ、スケジュールされた時刻は、ＨＡＲＱの同期タイミングに対応する）。
【００３６】
同期非適応的再送信の場合、再送信は、以前のアップリンク送信と同じパラメータを使用する。すなわち、同じ物理チャネルリソース上で再送信がシグナリングされ、それぞれ同じ変調方式／トランスポートフォーマットを使用する。ただし、冗長バージョンは変化する、すなわち、０，２，３，１の冗長バージョンの所定のシーケンスを循環する。
【００３７】
同期適応的再送信は、ＰＤＣＣＨを介して明示的にスケジューリングされるため、ｅＮｏｄｅＢは（最初の送信または一般的に以前の送信と比較して）再送信のために特定のパラメータを変更することができる。再送信は、例えば、アップリンクでの断片化を避けるために、異なる周波数リソース上でスケジューリングされてもよく、または、ｅＮｏｄｅＢが、変調方式を変更するか、もしくは、ユーザ機器に再送信にいずれの冗長バージョンを使用するかを指示してもよい。ＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）およびＰＤＣＣＨシグナリングは、ＵＬ  ＨＡＲＱ  ＦＤＤ動作のために同じタイミングで生じることに留意すべきである。したがって、ユーザ機器は、同期非適応的再送信がトリガされる（すなわち、ＮＡＣＫのみが受信される）か否か、または、ｅＮｏｄｅＢが同期適応的再送信を要求するか（すなわち、ＰＤＣＣＨもシグナリングされる）もしくは新しい初期送信を要求するかを一度確認すればよい。
【００３８】
このような同時送信によって、ユーザ端末は、ＰＨＩＣＨの内容にかかわらず、ＰＤＣＣＨが端末に何をするように指示するか、すなわち、新しい送信（トグルされたＮＤＩを伴う新しいＵＬグラント）を指示するか、または、再送信（適応的再送信と呼ばれる）（トグルされたＮＤＩ値を伴わない新しいＵＬグラント）を指示するか、を決定することが可能である。端末に対するＰＤＣＣＨが検出されない場合、ＰＨＩＣＨ内容は、端末のＵＬ  ＨＡＲＱ挙動を指示する。これについては以下に要約する。「ＮＤＩ」という用語は、「新規データインジケータ（"New Data Indicator"）」の略語であり、これは、トグルされると、対応する送信がデータの最初の送信（初期送信）であることを意味する。
【００３９】
ＮＡＣＫの受信に応じて、端末は、非適応的再送信、すなわち、同じＨＡＲＱプロセスによって以前に使用されたのと同じアップリンクリソース上の再送信を実行する。ＡＣＫの受信に応じて、端末はいかなるアップリンク再送信も実行せず、そのＨＡＲＱプロセスのためにデータをＨＡＲＱバッファに保持する。そのＨＡＲＱプロセスのためのさらなる送信は、ＰＤＣＣＨによる後続のグラントによって明示的にスケジューリングされる必要がある。そのようなグラントを受信するまで、端末は「保留状態（"suspension state"）」にある。
【００４０】
ＵＬ  ＨＡＲＱプロトコルの挙動は、以下の表に示されている。
【表１】
2019516281.tif 000013
【００４１】
ＬＴＥにおけるアップリンクＨＡＲＱプロトコルのスケジュールタイミングは、図８に例示的に示されている。ｅＮＢは、ＰＤＣＣＨ上で第１のアップリンクグラント３０１をＵＥに送信し、これに応じて、ＵＥはＰＵＳＣＨ上で第１のデータ３０２をｅＮＢに送信する。ＰＤＣＣＨアップリンクグラントとＰＵＳＣＨ送信との間のタイミングは、現在４ｍｓに固定されている。ＵＥから第１のデータ送信３０２を受信した後、ｅＮＢは、受信された送信に対するフィードバック情報（ＡＣＫ／ＮＡＣＫ）および場合によってはＵＬグラント３０３をＵＥに送信する（代替的に、ＵＬ送信が成功した場合、ｅＮＢは適切な第２のアップリンクグラントを送信することによって新しいアップリンク送信をトリガし得る）。ＰＵＳＣＨ送信と、フィードバック情報を搬送する対応するＰＨＩＣＨとの間のタイミングも、現在、４ｍｓに固定されている。したがって、アップリンクＨＡＲＱプロトコルにおける次の（再）送信機会を示す往復時間（ＲＴＴ）は８ｍｓである。これらの８ｍｓの後、ＵＥは、ｅＮＢによって指示されるように、以前のデータの再送信３０４を送信することができる。さらなる動作のために、以前に送信されたデータパケットの再送信３０４は、再び復号に成功しておらず、結果、ｅＮｏｄｅＢがＵＥに別の再送信を実行するように（例えば、フィードバックとしてＮＡＣＫ３０５を送信するように）指示すると仮定される。したがって、これに応答して、ＵＥは、さらなる再送信３０６を実行する。
【００４２】
図８の上部には、サブフレームナンバリング、および、ＨＡＲＱプロセスとサブフレームとの例示的な関連付けがリストされている。そこから明らかなように、８つの利用可能なＨＡＲＱプロセスの各々は、それぞれのサブフレームと周期的に関連付けられる。図８の例示的なシナリオでは、初期送信３０２、ならびに、それに対応する再送信３０４および３０６が同じＨＡＲＱプロセス番号５によって処理されると仮定される。
【００４３】
ＵＥにおいて測定を実行するための測定ギャップは、ＨＡＲＱ再送信よりも優先度が高い。したがって、ＨＡＲＱ再送信が測定ギャップと衝突するときはいつでも、ＨＡＲＱ再送信は行われない。一方、ＰＨＩＣＨを介したＨＡＲＱフィードバック送信が測定ギャップと衝突するときはいつでも、ＵＥは、ＡＣＫを、期待されるＨＡＲＱフィードバックの内容として仮定する。ＨＡＲＱ動作の関連部分は、例えば、非特許文献４の「ＨＡＲＱ  ｏｐｅｒａｔｉｏｎ」において定義されている。
【００４４】
［ＮＢ−ＩｏＴ／ｅＭＴＣ］
セルラベースのモノのインターネット（ＩｏＴ：Internet of Things）技術は、すべてのインターネット（ＩｏＥ：Internet of Everything）の重要な部門になっている。新興の大規模なＩｏＴセグメントの新しい接続要件を満たすために、３ＧＰＰはネットワーク側とデバイス側の両方で進化のステップを踏み出した。
【００４５】
リリース１３までの３ＧＰＰで取り上げられている主要な改善領域は次のとおりである。
−デバイスコストの低減−ピークレート、メモリ要件、およびデバイスの複雑さを低減することによって、ＬＴＥデバイスのモジュールコストを削減する。ＬＴＥモジュールのコスト削減の展開は、ピークレートを最大１０Ｍｂｐｓまで低減したマシンタイプ通信用ＬＴＥ（LTE for machine-type communication）（ＬＴＥ−Ｍ）Ｃａｔ  １デバイスの導入に始まり、性能を低下させるためにデバイスの複雑さを低減し、より少ない帯域幅または狭帯域のＩｏＴキャリアを使用してコストをさらに削減している、リリース１２および１３において継続している。
−バッテリ寿命の向上−省電力モードおよび／または拡張不連続受信（ｅＤＲＸ：extended discontinuous reception）機能を導入することで、１０年を超えるバッテリ寿命を達成できる。これらの機能により、デバイスは必要に応じてネットワークに接続するか、またはコンタクトされることが可能になる。これは、数分、数時間、またはさらには数日間にわたってスリープモードを維持することができることを意味する。
−カバレッジの改善−ＬＴＥ−Ｍでは１５ｄＢ、ＮＢ−ＩｏＴおよびＧＳＭ（登録商標）では２０ｄＢ改善され、これは、屋内カバレッジエリアが７倍に増加し、屋内信号侵入が大幅に改善されて屋内の奥に届くことを意味する。これは、地下に配置されることが多いスマートメータのような多くのＩｏＴデバイスをサポートする。カバレッジの改善は、時間領域の反復（repetition）によって達成される。
−ＩｏＴ接続の膨大な数に対するサポート−具体的には、１つのＬＴＥセルサイトが、使用事例に応じて、何百万ものＩｏＴデバイスをサポートできる。コアネットワークの強化には、サービス差別化処理、シグナリングの最適化、および大容量プラットフォーム（ノードあたり３，０００万台以上のデバイス）のためのソフトウェアアップグレードが含まれる。
【００４６】
消費電力を低減し、デバイスの複雑さ／コストを削減し、困難な場所（例えば、建物内の奥深く）に達するためにより深いカバレッジを提供するために、３ＧＰＰ規格のリリース１３の一部として、一連の機能を提供するＬＴＥ−Ｍ（拡張マシンタイプ通信、ＭＴＣ）に加えて、ＮＢ−ＩｏＴ技術は３ＧＰＰリリース１３のために標準化されている。
【００４７】
ＮＢ−ＩｏＴ（狭帯域モノのインターネット（Narrow-Band Internet of Things））は、低電力広域（ＬＰＷＡ：Low Power Wide Area）と呼ばれることがある低スループットのＩｏＴアプリケーションに対処する、非常に低い消費電力（例えば、全キャリア帯域幅が１８０ｋＨｚ、サブキャリア間隔が３．７５ｋＨｚまたは１５ｋＨｚであり得る）に最適化された物理層を使用したネットワークサービスへのアクセスを提供する。そのようなアプリケーションには、スマートな水／ガス計量、自治体の照明および廃棄物の管理、家畜の繁殖および灌漑、ならびに環境モニタリングが含まれる。ＮＢ−ＩｏＴは屋内カバレッジの向上、低スループットのモノの大量サポート、低遅延感度、超低デバイスコスト、デバイス消費電力の低減、ネットワークアーキテクチャの最適化を可能にする。この技術は、帯域内で、通常のＬＴＥキャリア内のリソースブロックを利用して、またはＬＴＥキャリアのガードバンド内の未使用のリソースブロック内で、または専用スペクトル内の展開のためにスタンドアロンで展開することができる。この技術は、ＧＳＭチャネルのリファーミングにも特に適している。
【００４８】
ＮＢ−ＩｏＴ技術およびＬＴＥ−Ｍは、より幅広い種類の消費者および企業使用事例を接続するようにセルラ技術を拡大する様々な継続的イニシアチブを用いて、３ＧＰＰセルラＩｏＴポートフォリオを完成させる。グローバルに標準化された信頼性の高い（ライセンスされたスペクトルに基づく）ソリューションを提供するこのセルラ技術のポートフォリオは、豊富で多様なＩｏＴサービスのセットを満足している。さらに、これらのソリューションは、運用者が、配備されたネットワークインフラストラクチャを最大限に再利用でき、ＩｏＴ市場に対応するための新しいネットワークを配備する必要がないように設計されている。
【００４９】
［ＮＢ−ＩｏＴ／ｅＭＴＣのためのカバレッジ強化］
ＬＴＥ  Ｒｅｌ−１３では、１５５．７ｄＢの最大結合損失（ＭＣＬ：Maximum Coupling Loss）を目標とするためのカバレッジ強化が指定されている。これにより、セルのカバレッジエリアが増加するだけでなく、侵入損失の高い場所にあるＭＴＣデバイス（ｅＭＴＣ／ＮＢ−ＩｏＴ）（例えば、地下に設置されたスマートメータ）をサポートできるようになる。しかしながら、Ｒｅｌ−１３低複雑度デバイスは、容量の減少により、カバレッジがより小さい。すなわち、１Ｒｘ（受信）アンテナは、ダウンリンクチャネルの性能において約４ｄＢの劣化をもたらす。これは、受信部結合およびダイバーシティ利得の欠如に起因する。最大送信電力の低減は、アップリンクチャネルのカバレッジの対応する劣化をもたらす。ダウンリンクおよびアップリンクにおける１．４ＭＨｚのＵＥ帯域幅の減少は、ダイバーシティ利得の欠如のために性能の低下をもたらす可能性がある。この結果、性能が約１〜３ｄＢ損失することが予測されている。目標とする１５５．７ｄＢのＭＣＬに到達するために、異なるチャネル（ＵＬ／ＤＬ）は、異なるカバレッジ増強量を必要とし、例えば、Ｒｅｌ−１３低コストデバイスのＰＵＳＣＨには、１８ｄＢのカバレッジ強化が必要である。カバレッジ増強を達成するために、いくつかのカバレッジ増強技法が使用される。
【００５０】
性能要件、複数の復号試行、およびマルチサブフレームチャネル推定を緩和するなどの一部の技法では、適切な性能要件を再定義する以外の仕様変更は必要ない。反復／サブフレームバンドリング、オーバヘッド削減、および基準信号密度の増加などの他の技法では、標準的な変更が必要になる。カバレッジ増強は、各デバイスの受信および送信時間を最小限に抑えることを目的として、スケーラブルで構成可能である。デバイスを適切なカバレッジ増強量向けに構成することができるように、カバレッジ範囲を特定するメカニズムが必要になる。さらなる詳細については、例えば、Ｅｒｉｃｓｓｏｎによって報告され、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇにおいて利用可能であり、参照により本明細書に組み込まれる非特許文献３を参照されたい。
【００５１】
注目すべきことに、公称カバレッジに関する増強カバレッジモードにおけるＵＥの１５／２０ｄＢのカバレッジ増強は、ＵＥが極端に低い信号強度を受信できなければならないことを意味する。これは、初期走査動作、セル探索およびセル選択動作だけでなく、ＵＥによって実行される後続の通信方式にも適用される。上述したように、ネットワークサポートおよびＵＥ能力に応じて、例えば、５／１０／１５ｄＢカバレッジ拡張などの異なるレベルのＣＥが存在する。
【００５２】
増強カバレッジモードを定義する初期の試みは、無線送信の変更に焦点を当てていた。この点に関して、議論は、カバレッジを改善するための主な技法であるとして反復送信に焦点を当ててきた。カバレッジ改善のために、すべてのチャネルに反復を適用することができる。これらの反復送信の例示的な実装では、同じデータが複数のサブフレームにわたって送信されることが規定されている。しかし、これらの反復送信は、通常のカバレッジＵＥに必要とされるものよりも多くのリソース（時間−周波数）を使用することが直ちに明らかになる。ＭＴＣデバイスへの送信に使用されるトランスポートブロックサイズは、１０００ビット未満になる可能性が高い。
【００５３】
［ＮＢ−ＩｏＴ／ｅＭＴＣのためのアップリンクＨＡＲＱプロトコル］
ＮＢ−ＩｏＴおよびｅＭＴＣ（Ｒｅｌ−１３）については、非同期ＵＬ  ＨＡＲＱプロトコルが導入されている。レガシーＬＴＥに使用される同期アップリンクＨＡＲＱプロトコルとは異なり、ＮＢ−ＩｏＴまたはｅＭＴＣ  ＵＥのための再送信は、適応的であり、非同期的である。特に、再送信は、同じプロセスの以前のＨＡＲＱ送信に対して固定されたタイミングで行われる必要はなく、これによって再送信を明示的にスケジューリングする柔軟性が与えられる。さらに、明示的なＨＡＲＱフィードバックチャネル（ＰＨＩＣＨ）は存在しない、すなわち、再送信／初期送信は、ＰＤＣＣＨによって示される（ＮＤＩが初期送信と再送信とを区別する）。本質的に、ＮＢ−ＩｏＴまたはｅＭＴＣ  ＵＥのアップリンクＨＡＲＱプロトコル挙動は、リリース８以降のダウンリンクに使用される非同期ＨＡＲＱプロトコルに非常に類似する。
【００５４】
ＮＢ  ＩｏＴについては、１つのみのＵＬ  ＨＡＲＱプロセスが存在することに留意されたい。ＮＢ−ＩｏＴ／ｅＭＴＣ  ＵＥのために導入された非同期アップリンクＨＡＲＱプロトコルに関するさらなる情報については、参照により本明細書に組み込まれる非特許文献４を参照されたい。
【００５５】
［ライセンスされていないキャリアの送信のためのアップリンクＨＡＲＱプロトコル］
リリース１３まで、アップリンク送信は、ライセンスされたキャリアのみに対してサポートされていた。ＮＢ−ＩｏＴおよびｅＭＴＣ（Ｒｅｌ−１３）以外の機能について、対応するＵＬ  ＨＡＲＱプロトコルは同期的である。しかし、ライセンスされていないキャリアの日和見的なアクセス特性に起因して、再送信タイミング、および、送信時間間隔と同期プロトコルによって確立されるＨＡＲＱプロセスとの間の関連性を固定することは不適切と考えられる。したがって、非同期ＨＡＲＱプロトコルもまた、ライセンスされていないキャリア上のアップリンク送信の強力な候補である。
【００５６】
ＮＢ  ＩｏＴとは対照的に、複数のＵＬ  ＨＡＲＱプロセスが存在することに留意されたい。
【先行技術文献】
【非特許文献】
【００５７】
【非特許文献１】3GPP TS 36.211 "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)" section 6.2
【非特許文献２】TS 36.213 v11.1.0 "3rd Generation Partnership Project; Technical Specification group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures (Release 11)" Chapter 8.0 "UE procedure for transmitting the physical uplink shared channel"
【非特許文献３】3GPP RP-141865 "Revised WI: Further LTE Physical Layer Enhancements for MTC"
【非特許文献４】3GPP TS 36.321 V13.1．0(2016-03) Section 5.4.2
【発明の概要】
【発明が解決しようとする課題】
【００５８】
上述の背景からわかるように、ＬＴＥは、効率的なＩｏＴ実装のためのいくつかの新しい機能を提供する。新しい機能は、通常、以前のリリースの機能に追加される。しかし、レガシーシステムに基づいて新しい機能を導入すると、レガシーシステムと新しい機能との間の相互作用について、いくつかの冗長性および解釈上の問題が生じる可能性がある。
【００５９】
例えば、アップリンクのための非同期ＨＡＲＱプロトコルの導入に起因して、その相互作用をＤＲＸ動作に適合させることは有益であり得る。特に、またアップリンクのダウンリンク動作と同様に、ｅＭＴＣまたはＮＢ  ＩｏＴには、２つの新しいＤＲＸ関連タイマ、すなわち、drx-ULRetransmissionTimer（ｄｒｘ−ＵＬ再送信タイマ）およびＵＬ  ＨＡＲＱ  ＲＴＴタイマが導入されている。drx-ULRetransmissionTimerは、ＵＬ再送信グラントが受信されるまで、最大数の連続するＰＤＣＣＨサブフレームを指定する。ＵＬ  ＨＡＲＱ  ＲＴＴタイマは、ＭＡＣエンティティによってＵＬ  ＨＡＲＱ再送信グラントが予測される前に、最小量のサブフレームを指定する。新規のタイマの動作を効率的に処理し、効率的なＤＲＸ動作を可能にすることが有利であり得る。
【課題を解決するための手段】
【００６０】
これは、独立請求項の特徴によって達成される。
【００６１】
さらなる有利な実施形態は、従属請求項の主題である。
【００６２】
一実施形態によれば、非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理アップリンク共有チャネルを介してデータを送信する装置が提供され、当該装置は、アップリンクデータ送信に応じて開始し、第１の所定の時間が経過した後に停止（満了）するように構成されている第１のタイマと、第１のタイマの満了に応じて開始し、第２の所定の時間が経過した後に停止（満了）するように構成された第２のタイマと、アップリンク新規データ送信または再送信の肯定応答を含むダウンリンク制御情報を受信する受信部とを備え、受信部は、第１のタイマが満了しており、第２のタイマが作動しているときのみ受信を行うように構成されており、第２のタイマは、肯定応答の受信に応じて停止するようにさらに構成されている。
【００６３】
別の実施形態によれば、非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理アップリンク共有チャネルを介してデータを送信する方法が提供され、方法は、アップリンクデータ送信に応じて第１のタイマを開始し、第１の所定の時間が経過した後に第１のタイマを停止するステップと、第１のタイマの満了に応じて第２のタイマを開始し、第２の所定の時間が経過した後に第２のタイマを停止するステップと、アップリンク新規データ送信または再送信の肯定応答を含むダウンリンク制御情報を受信するステップとを含み、受信するステップは、第１のタイマが満了し、第２のタイマが作動しているときのみ行われ、第２のタイマは、肯定応答の受信に応じて停止する。
【００６４】
本発明の上記および他の目的および特徴は、添付の図面と併せて与えられる以下の説明および好ましい実施形態からより明らかになるであろう。
【図面の簡単な説明】
【００６５】
【図１】３ＧＰＰ  ＬＴＥシステムの例示的なアーキテクチャを示すブロック図である。
【図２】３ＧＰＰ  ＬＴＥの全体的なＥ−ＵＴＲＡＮアーキテクチャの例示的な概要を示すブロック図である。
【図３】３ＧＰＰ  ＬＴＥ（リリース８／９現在）について定義されたダウンリンクスロットの例示的なダウンリンクリソースグリッドを示す概略図である。
【図４】キャリアアグリゲーションを設定されているレイヤ２ダウンリンク構造を示す概略図である。
【図５】キャリアアグリゲーションを設定されているレイヤ２ダウンリンク構造を示す概略図である。
【図６】ＤＲＸサイクルを示す概略図である。
【図７】短いＤＲＸサイクルおよび長いＤＲＸサイクルを示す概略図である。
【図８】ＰＨＩＣＨを使用するＨＡＲＱを示す概略図である。
【図９】ＮＢ  ＩｏＴに対するＤＲＸおよびＨＡＲＱモードのタイマを示す概略図である。
【図１０Ａ】アップリンクについての確認応答を有するＮＢ  ＩｏＴに対するＤＲＸおよびＨＡＲＱモードのタイマを示す概略図である。
【図１０Ｂ】ダウンリンクについてのＮＢ  ＩｏＴのためのタイマを示す概略図である。
【図１０Ｃ】ダウンリンクについてのＮＢ  ＩｏＴのためのタイマを示す概略図である。
【図１１】アップリンクデータを送信する方法を示す流れ図である。
【図１２】データを送信および受信する装置を示すブロック図である。
【発明を実施するための形態】
【００６６】
本開示は、アップリンクのＨＡＲＱに関し、特に、アクティブ／非アクティブタイマに関連する非同期再送信の効率的な動作に関する。
【００６７】
以下の説明は、ＨＡＲＱのＮＢ  ＩｏＴ機能への適用に焦点を当てているが、これは、非同期ＨＡＲＱを採用する他の機能への適用性を限定するものと理解されるべきではない。
【００６８】
ＴＳ  ３６．３２１、ｖ１３．１．０（少なくともＮＢ  ＩｏＴについてまだ変更を受ける可能性がある）に従った、現在合意された（再）送信動作が図９に示されている。
【００６９】
図９は、ＵＥの観点からの送信および受信動作を示す。特に、ダウンリンク（ＤＬ）において、ＵＥは、アップリンク送信のためのスケジューリングメッセージを受信する。このメッセージは、ＮＢ−ＩｏＴの物理ダウンリンク制御チャネルであるＮＢ−ＰＤＣＣＨ上で受信される。スケジューリングメッセージは、最初の送信（初期Ｔｘ）、すなわち（再送信とは対照的に）新しいデータの送信のためのアップリンクグラントをＵＥに提供する。現在の規格によれば、ＵＥに向けられたＮＢ−ＰＤＣＣＨの受信に応じて、ＵＥはdrx-InactivityTimer（ｄｒｘ非アクティブタイマ）を開始し、ＰＤＣＣＨを監視する。ＤＲＸ動作に関して上述したように、drx-InactivityTimer中、ＤＲＸは非アクティブであり、これは、ＰＤＣＣＨが監視されることを意味する。
【００７０】
受信されたＮＢ−ＰＤＣＣＨに従って、ＵＥは、その後、ＰＵＳＣＨ（物理アップリンク共有チャネル）のスケジューリングされたリソースにおいてデータを送信する。アップリンク送信は、グラント（ＮＢ−ＰＤＣＣＨ）が受信されたサブフレームに後続するサブフレーム、または、グラント（ＮＢ−ＰＤＣＣＨ）が送信された最後のサブフレームに後続するサブフレーム内で行われる。一般に、グラントを有するサブフレームに後続するサブフレームは、直後のサブフレームであってもよい。しかしながら、実際には、いくつかの事前定義されたまたはシグナリングされたオフセットが利用されてもよい。
【００７１】
ＵＥが、最後の反復が受信される前に、ＮＢ−ＰＤＣＣＨを成功裏に検出することが可能である場合、後者は、ＮＢ−ＰＤＣＣＨが様々なサブフレームにわたって反復される場合に特に適用可能である。そのような場合、ＵＥが、ＮＢ−ＰＤＣＣＨの反復が終了するまで待つことが有益であり、その結果、ｅＮＢについて、対応するＰＵＳＣＨのタイミングは、ＮＢ−ＰＤＣＣＨの可能性の早期の成功裏の復号による影響を受けない。
【００７２】
ＮＢ  ＩｏＴのためのＨＡＲＱによって、２つの追加のタイマが導入されている。ＲＴＴタイマ（ＵＬ  ＨＡＲＱ  ＲＴＴタイマ）は、ＰＵＳＣＨ上のスケジュールされたアップリンクデータの送信に応じて開始される。ＲＴＴタイマは、ＵＬ  ＨＡＲＱ再送信グラントが予測される前のサブフレームの最小量（または一般に最小期間）に対応する。ＲＴＴタイマによって定義された期間中、ＵＥは、ｅＮＢが依然としてＰＵＳＣＨ送信を処理しているため、ＰＤＣＣＨを復号する必要はない。ＲＴＴタイマが満了した後、再送信タイマ（drx-ULRetransmissionTimer）が開始し、これは、ＵＬ再送信グラントが受信されることが予測されるまでの、連続するＰＤＣＣＨ−サブフレームの最大数（または一般的に期間）を指定する。再送信タイマの実行中、ＰＤＣＣＨが監視される。再送信に関するスケジューリングを伴うＰＤＣＣＨが受信されない場合、アップリンクデータ（ＰＵＳＣＨ送信）が受信されており、復号に成功したと仮定することができる。ｅＮＢがＰＵＳＣＨ送信を成功裏に復号しなかった場合、それは、そのグラントがデータ再送信（ＲｅＴｘ）を目的とすることを示す第２のＮＢ−ＰＤＣＣＨを使用して再送信をスケジューリングする。単一のＨＡＲＱプロセスしかないため、あいまい性は存在しない。したがって、ＵＥは、ＰＵＳＣＨの再送信をアップリンクにおいて送信する。上述したように、これは必ずしも同じ内容の反復送信ではなく、別の冗長バージョンであってもよい。ＰＵＳＣＨの再送信の後、ＰＤＣＣＨを監視する必要がないＲＴＴタイマ（ＵＬ  ＨＡＲＱ  ＲＴＴタイマ）が再び開始され、その満了後、可能性のある再送信割当についてＰＤＣＣＨが監視される再送信タイマ（drx-ULRetransmissionTimer）が開始する。再送信後にデータが正しく復号されたとしても、ＵＥは依然として再送信タイマの全持続時間中にＰＤＣＣＨを監視し、したがってＤＲＸに入ることができない。
【００７３】
図９に見られるように、ＰＵＳＣＨで送信される最後のパケット、または（例えばスマートメータのカウンタステータスなどの、アップリンクにおいて送信されるデータバーストの）トランスポートブロックもしくはＭＡＣ  ＰＤＵについて、ＵＥは、パケットがｅＮＢによって正しく復号され得、それ以上の再送信がスケジュールされていなくても、drx-ULRetransmissionTimerが作動している時間、不必要に起動しなければならない。ＭＡＣ  ＰＤＵの送信成功を明示的に確認応答することはできない。より詳細には、ｅＮＢは、ＰＤＣＣＨを用いて初期または再送信をスケジューリングすることしかできない。再送信／新たな送信をさらにスケジューリングすることなく、送信の復号に成功したことをＵＥにシグナリングすることはできない。最後のパケットの場合、さらなる初期送信も再送信も要求されないため、ｅＮＢは、ＰＤＣＣＨを送信せず、結果として、ＵＥは不必要に起動してＤＣＩを監視したままになる。これにより、ＵＥのバッテリが不要に消費される。これがすべてのアップリンクデータ送信に対して、すなわちすべてのカウンタステータス通知と共に起こるとすると、追加のまたは不要な電力消費は無視できない。
【００７４】
示されている問題は、アップリンクの非同期ＨＡＲＱプロトコルに特有である。したがって、これはＲｅｌ−１３  ｅＭＴＣおよびまたＮＢ−ＩｏＴに特に関連するが、そのような非同期手法を使用し得るその他のシステムにも関係する。
【００７５】
さらに、図９からわかるように、DRX-InactivityTimerは、ＰＤＣＣＨが初期ＵＬ／ＤＬデータ送信を示すサブフレームの後の連続するＰＤＣＣＨサブフレームの数を指定する。Drx-InactivityTimerが作動している時間は、ＵＥが新しいＤＣＩを監視する必要があるアクティブ時間の一部である。上記の図９に示すように、Drx-InactivityTimerは、ＮＢ−ＰＤＣＣＨ（ＤＣＩフォーマットＮ０）が送信されている最後のサブフレームの直後に開始される。しかし、ＮＢ−ＩｏＴについてはただ１つのＨＡＲＱプロセスしかないため、ｅＮＢはいくつかのＴＢを並列に送信することはできない。したがって、ＭＡＣ  ＰＤＵ／ＴＢは、次々と送信される必要がある。したがって、ＰＤＣＣＨを受信した直後にＵＥがＤＣＩを監視する必要はない。この挙動により、ＵＥのバッテリが不要に消費される。これは基本的には、ＵＥがＰＵＳＣＨを送信した後に、ＤＣＩ（新しいＴＢまたは同じＴＢの再送信をスケジューリングする）を監視する場合には十分である。
【００７６】
非効率を回避し、効果的なＤＲＸ動作を可能にするために、ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって無線通信システムにおいて物理アップリンク共有チャネルを介してデータを送信するための装置が提供される。この装置は、アップリンクデータ送信に応じて開始し、第１の所定の時間が経過した後に停止（すなわち満了）するように構成されている第１のタイマ（上述のＲＴＴタイマに対応する）と、第１のタイマの満了に応じて開始し、第２の所定の時間が経過した後に停止（満了）するように構成されている第２のタイマ（上述の再送信タイマに対応する）とを備える。さらに、本装置は、アップリンクの新規データ送信または再送信の肯定応答を含むダウンリンク制御情報を受信する受信部を備え、受信部は、第１のタイマが停止（満了）しており、かつ第２のタイマが作動しているときのみ、受信を行うように構成されており、第２のタイマは、肯定応答の受信に応じて停止するようにさらに構成される。
【００７７】
この装置は、例えば、スマートフォンの、測定を行う目標位置に設置されたＮＢ  ＩｏＴデバイス、または他のデバイスに接続することができるモジュールなど、任意の形態で実装された、上述のＵＥであってもよい。対応する動作を図１０Ａに示す。
【００７８】
重要な要件であるＮＢ  ＩｏＴ  ＵＥの電力消費を最適化するために、ｅＮＢは、ＰＵＳＣＨ送信の復号に成功したが、さらなるＰＵＳＣＨ送信（新規または再送信）をスケジューリングしないことを明示的にＵＥに示すことができるべきである。上に概説したように、問題は、ＵＬデータバーストのすべての「最後のＭＡＣ  ＰＤＵ送信」において発生する。ＮＢ  ＩｏＴはＵＬ駆動（UL driven）であるため、アップリンクデータ送信に関してＤＲＸ動作または電力消費が最適化されるべきである。
【００７９】
一実施形態によれば、ダウンリンク制御チャネル、すなわちＮＢ−ＩｏＴについてのＤＣＩフォーマットＮ０（ＮＢ−ＰＤＣＣＨ）は、明示的な確認応答を示すために使用される。対応して、ｅＭＴＣについてのＭ−ＰＤＣＣＨ（ＤＣＩフォーマット６−０Ａ／６−０Ｂ）は新しいコマンドをシグナリングする。シグナリングを実施することができる方法にはいくつかの選択肢がある。
【００８０】
例えば、明示的な確認応答をシグナリングするＤＣＩの新しいフィールドが導入されてもよい。例えば、このフィールドは、「ＡＣＫ／フラッシュ（"ACK/flush"）」フィールドと呼ぶことができる。特にＨＡＲＱプロセスが１つしかない場合、フィールドサイズには１ビットで十分である。換言すれば、一例によれば、ダウンリンク制御情報は、肯定応答および／またはバッファフラッシングコマンド（buffer flushing command）を別個の１ビットフィールド内で示す。
【００８１】
このフィールドは先行するＰＵＳＣＨ送信の復号の成功を示しているに過ぎないため、ＤＣＩ内の他のフィールドは多かれ少なかれ無駄になる（新しいＰＵＳＣＨ送信はスケジューリングされていないため）。したがって、ＤＣＩ内の残りのフィールドは、例えば、すべてゼロに設定されるなど、予め定められた値に設定され得る。これは、ＣＲＣサイズを実質的に増加させるという追加の利点を提供する。すなわち、それらは、予め定められた値に設定される。そして、「ＡＣＫ／フラッシュ」フィールドが明示的な確認応答を示す場合、他のフィールドは、それらが所定の値と一致するか否かを検査され得る。したがって、残りのフィールドを所定の値に設定することにより、明示的な確認応答を誤検出する誤警報率（false alarm rate）を大幅に低減することができる。
【００８２】
そのようなＤＣＩの１つの例示的な実施態様を以下に示す。
−フォーマットＮ０／フォーマットＮ１の区別のためのフラグ−１ビット、ここで値０はフォーマットＮ０を示し、値１はフォーマットＮ１を示す
−サブキャリア指示−ｘビット
−リソース割当−ｘビット
−スケジューリング遅延−ｘビット
−変調符号化方式および冗長バージョン−ｘビット
−反復数−ｘビット
−新規データインジケータ−１ビット
−ＤＣＩサブフレーム反復回数−ｘビット
−ＨＡＲＱ確認応答／フラッシュ  １ビット
−フォーマットＮ０の情報ビットの数がフォーマットＮ１の情報ビット数より少ない場合、ペイロードサイズがフォーマットＮ１のそれに等しくなるまで、フォーマットＮ０にゼロが付加されるものとする。
【００８３】
同様に、新しいフィールドをＤＣＩフォーマット６−０Ａ／ＤＣＩフォーマット６−０Ｂに導入することができる。
【００８４】
ｅＭＴＣでは、ＰＵＳＣＨ送信をスケジューリングするための新しいＤＣＩフォーマットが、ＴＳ  ３６．２１２（フォーマット６−０Ａ、６−０Ｂ、６−１Ａ、６−１Ｂ、６−２を示すバージョン１３．０．０または１３．１．０）において導入されている。これは以下に示す。これらのフォーマットに新しいフィールドを導入することができる。以下、「［２］」は３ＧＰＰ  ＴＳ  ３６．２１１、バージョン１３．１．０を指し、一方で「［３］」は３ＧＰＰ  ＴＳ  ３６．２１３、バージョン１３．１．０を指す。
【００８５】
［フォーマット６−０Ａ］
ＤＣＩフォーマット６−０Ａは、１つのＵＬセル内のＰＵＳＣＨのスケジューリングに使用される。以下の情報が、ＤＣＩフォーマット６−０Ａによって送信される。
−フォーマット６−０Ａ／フォーマット６−１Ａの区別のためのフラグ−１ビット、ここで値０はフォーマット６−０Ａを示し、値１はフォーマット６−１Ａを示す
−周波数ホッピングフラグ−［２］のセクション５．３．４で定義される１ビット
−リソースブロック割当−［３］で定義されているＰＵＳＣＨの＋５ビット：
−ＭＳＢビットが、［２］のセクション５．２．４で定義される狭帯域インデックスを提供する
−５ビットが、指定された狭帯域内でのＵＬリソース割当タイプ０を使用したリソース割当を提供する
−変調符号化方式−［３］のセクション８．６で定義される４ビット
−反復回数−［３］のセクション８．０で定義される２ビット
−ＨＡＲＱプロセス番号−３ビット
−新規データインジケータ−１ビット
−冗長バージョン−２ビット
−スケジュールされたＰＵＳＣＨのためのＴＰＣコマンド−［３］のセクション５．１．１．１で定義されるような２ビット
−ＵＬインデックス−［３］のセクション５．１．１．１、７．２．１、８および８．４で定義されている２ビット（このフィールドは、アップリンク−ダウンリンク構成０のＴＤＤ動作の場合にのみ存在する）
−ダウンリンク割当インデックス（ＤＡＩ：Downlink Assignment Index）−［３］のセクション７．３で定義されているような２ビット（このフィールドは、ＴＤＤプライマリセルおよびアップリンク−ダウンリンク構成１−６を伴うＴＤＤ動作またはＦＤＤ動作の場合にのみ存在する。このフィールドは、ＰＤＳＣＨまたはＭＰＤＣＣＨの設定された最大反復数が１より大きい場合に確保される。）
−ＣＳＩ要求−［３］のセクション７．２．１で定義されるような１ビット
−ＳＲＳ要求−１ビット。このフィールドの解釈は［３］のセクション８．２で提供されている。
−ＤＣＩサブフレーム反復数−［３］のセクション９．１．５で定義されている２ビット。
【００８６】
所与のサーチスペース上にマッピングされるフォーマット６−０Ａ内の情報ビットの数が、同じサービングセルをスケジューリングし、（フォーマット６−１Ａに付加された任意のパディングビットを含む）同じサーチスペース上にマッピングされるフォーマット６−１Ａのペイロードサイズよりも小さい場合、ペイロードサイズがフォーマット６−１Ａのものに等しくなるまで、ゼロがフォーマット６−０Ａに付加される。
【００８７】
［フォーマット６−０Ｂ］
ＤＣＩフォーマット６−０Ｂは、１つのＵＬセル内のＰＵＳＣＨのスケジューリングに使用される。以下の情報が、ＤＣＩフォーマット６−０Ｂによって送信される。
−フォーマット６−０Ｂ／フォーマット６−１Ｂの区別のためのフラグ−１ビット、ここで値０はフォーマット６−０Ｂを示し、値１はフォーマット６−１Ｂを示す
−リソースブロック割当−［３］で定義されているＰＵＳＣＨの＋３ビット：
−ＭＳＢビットが、［２］のセクション５．２．４で定義される狭帯域インデックスを提供する
−３ビットが［３］のセクション８．１．３で指定されているように示された狭帯域内のリソース割当を提供する
−変調符号化方式−［３］のセクション８．６で定義される４ビット
−反復回数−［３］のセクション８．０で定義される３ビット
−ＨＡＲＱプロセス番号−１ビット
−新規データインジケータ−１ビット
−ＤＣＩサブフレーム反復数−［３］のセクション９．１．５で定義されている２ビット。
【００８８】
所与のサーチスペース上にマッピングされるフォーマット６−０Ｂ内の情報ビットの数が、同じサービングセルをスケジューリングし、（フォーマット６−１Ｂに付加された任意のパディングビットを含む）同じサーチスペース上にマッピングされるフォーマット６−１Ｂのペイロードサイズよりも小さい場合、ペイロードサイズがフォーマット６−１Ｂのものに等しくなるまで、ゼロがフォーマット６−０Ｂに付加される。
【００８９】
同様に、例えば、ライセンスされていないキャリア上でＰＵＳＣＨを送信するために想定されるように、ＤＣＩフォーマット０もしくは４、または複数のＨＡＲＱプロセスによって非同期ＨＡＲＱ送信を許可（grant）する他のＤＣＩフォーマットに対して、新しいフィールドを導入することができる。そのような場合、ＤＣＩフォーマットは、適用可能なＨＡＲＱプロセスを決定するフィールドを含む。結果として、新しいフィールド（例えば、「ＡＣＫ／フラッシュ」）も、対応するＤＣＩ内で示されるＨＡＲＱプロセスに特有のものとして扱われ、結果、ＵＥは、その特定のＨＡＲＱプロセスのみの（再）送信バッファおよび送信ステータスに適用するように、それに従ってフィールドを解釈する。代替的な設計では、新しいフィールド（「ＡＣＫ／フラッシュ」）は、明示的な確認応答のためのＨＡＲＱプロセスを搬送する。すなわち、肯定応答が意図されるＨＡＲＱプロセスＩＤを示すか、または、肯定応答を示さない値を担持する。例えば、１０個のＨＡＲＱプロセスがサポートされている場合、新しいフィールドの値１〜１０は対応するプロセスに対する肯定応答を示し、値１１〜１６の少なくとも１つは肯定応答を示さない。この例では、４ビットの新規フィールドサイズで十分である。肯定応答は、バッファフラッシングまたはＤＲＸが意図されていないことを意味するに過ぎないため、特定のＨＡＲＱプロセスを示す必要はない。所望のプロセスのための再送信が、その後、何らかの後の時点において同じＤＣＩまたは別のＤＣＩによって指示されてもよい。
【００９０】
ＤＣＩに新しいフィールドを導入する代わりに、ダウンリンク制御情報は、アップリンク送信の無効または不一致の割り当てとして解釈される、フィールド内の値の組み合わせにおいて肯定応答および／またはバッファフラッシュコマンドを示す。言い換えれば、この組み合わせは、肯定応答／否定応答とは独立した特定の意味を有するフィールドの値に使用され、一方で、組み合わされた値は、フィールドの意味が考慮される場合、無効または一致しない様態で選択される。したがって、以前のリリースのＵＥは、値を受信し、それが無効であるために値を無視／破棄する。しかしながら、上述した追加の確認応答の動作をサポートするＵＥは、この無効な組み合わせを肯定応答として認識（解釈）することができる。
【００９１】
特に、既存のフィールドまたはそれらの組み合わせのいくつかは、明示的な確認応答を示すために所定の値に設定することができる。例えば、誤ったコマンドを示すＤＣＩのフィールド値の組み合わせを使用して、新しい情報（明示的な確認応答）をシグナリングすることができる。一例として、ＤＣＩは、ＭＡＣ  ＰＤＵの再送信（同じＮＤＩ値）を示し得るが、同時に、異なるＴＢサイズを示し得、これは正しいＤＣＩの内容ではない。別の例は、新しい送信（ＮＤＩトグル）を示すことであり得るが、同時にＴＢサイズを示さない（例えば、ＰＵＳＣＨの場合、ＭＣＳインデックスＩＭＣＳは初期送信のために２９，３０または３１のような値に設定される）。
【００９２】
一般に、許可されていないＤＣＩフィールド値のいくつかの組み合わせが存在する可能性がある。
【００９３】
ＵＥが新しい信号「ＨＡＲＱ確認応答／フラッシュ」を受信すると、ＵＥはdrx-ULRetransmissionTimerを停止し、スリープ状態（ＤＲＸ）に入る。さらに、ＵＥは、電力消費に関しても有益なＨＡＲＱ送信バッファをフラッシュすることもできる。
【００９４】
したがって、ＵＥがdrx-ULRetransmissionTimerを早期に停止（満了）することができ、タイマの事前定義された／所定の時間間隔に従って満了するまで待機する必要がないという点で省電力ゲインが生じる。さらに、ＵＥは、早期にＨＡＲＱ  Ｔｘバッファをフラッシュすることができる。対応するＵＥ挙動が図１０Ａに示されている。
【００９５】
図１０Ａは、図９と同様のシナリオを示す。しかしながら、ＰＵＳＣＨの再送信の後、ｅＮＢがＰＵＳＣＨの復号に成功する場合、ｅＮＢはＮＢ−ＰＤＣＣＨ上で肯定応答を送信する。ＵＥは、肯定応答の受信に応じて、再送信タイマを停止する。有利な実施形態によれば、ＵＥは、肯定応答の受信に応じてＤＲＸモードに入り、したがって、ＤＲＸタイマ、すなわちＰＤＣＣＨが監視されない第３のタイマを開始する。
【００９６】
図９および図１０を参照して説明をしたように、受信部は、有利には、アップリンクデータが成功裏に復号されなかったことを示すために、アップリンクデータの再送信のためのリソース割当を含むダウンリンク制御情報を受信するようにさらに構成される。これは、ＮＢ−ＰＤＣＣＨ（ＲｅＴｘ）として図に示されている。
【００９７】
さらに、本装置は、有益には、アップリンクリソース割当の受信に応じて、物理アップリンク共有チャネルにおける受信されたリソース割当に従って、アップリンクデータのＨＡＲＱ再送信を実行する送信部をさらに備える。これは、ＮＢ−ＰＤＣＣＨ上のスケジューリンググラントＲｅＴｘに応答して、第２のＰＵＳＣＨによって図に示されている。
【００９８】
肯定応答はまた、（再）送信バッファフラッシュの効果を有することもできる。したがって、本装置は、肯定応答を受信した場合にＨＡＲＱ送信バッファをフラッシュし、受信部が物理ダウンリンク制御チャネルを受信しないように構成された不連続受信モードに入るＨＡＲＱコントローラをさらに備える。
【００９９】
図からわかるように、ＮＢ−ＰＤＣＣＨは、新しいデータ送信をスケジュールする、再送信をスケジュールする、または肯定応答を提供するなど、異なる目的のために使用されてもよい。有利には、ダウンリンク制御情報は、新たな送信と再送信とを区別するフィールドを伴う肯定応答またはリソース割当のいずれかを示す。したがって、肯定応答は、さらなる送信がスケジュールされない場合にのみ送信される。
【０１００】
本発明は、ＤＲＸモードに入ることに限定されないことにも留意されたい。代替的に、ＤＣＩ上でシグナリングされる新しいコマンド（肯定応答）は、コマンドを受信した後にＵＥがＲＲＣ接続を解放し、ＤＲＸに移行する代わりにＲＲＣ  ＩＤＬＥモードに移行することを示すこともできる。ＲＲＣ  ＩＤＬＥモードでは、ＰＤＣＣＨモニタリングは既に非常に限定された労力のみによって実行されており、結果、バッファ管理およびＰＤＣＣＨ監視に影響を及ぼすような、ＤＲＸは追加の利得をまったくまたは無視できる程度にしか有しないため、ＤＲＸメカニズムは必要ではない。これは、ｅＮＢがＲＲＣ接続を解放するために、ＤＣＩを使用することと比較してかなり長い時間を要するＲＲＣ手順を使用する必要がないため、消費電力に関しても有益である。
【０１０１】
複数のＨＡＲＱプロセスをサポートする機能への実施形態の適用性のために、定義されたＨＡＲＱプロセス当たり１つのdrx-ULRetransmissionTimerがある。結果として、ＵＥがＨＡＲＱプロセスの新しい信号「ＨＡＲＱ確認応答／フラッシュ」を受信すると、ＵＥは対応するＨＡＲＱプロセスのdrx-ULRetransmissionTimerを停止する。さらに、ＵＥは、対応するＨＡＲＱプロセスのためにＨＡＲＱ送信バッファをフラッシュすることもでき、これは電力消費に関しても有益である。すべてのＨＡＲＱプロセスのdrx-ULRetransmissionTimerが停止している場合、ＵＥはスリープに移行する（ＤＲＸ）。
【０１０２】
問題セクションで述べたように、drx-InactivityTimer定義／処理（definition/handling）は、特に１つのＨＡＲＱプロセスのみが使用されるＮＢ−ＩｏＴ機能の場合、電力消費の観点から最適ではない。
【０１０３】
図９からわかるように、また上記で提示されているように、ＤＲＸ動作は、新たに導入されているタイマ（ＲＴＴ、再送信タイマ）とは独立している。したがって、drx-InactivityTimerは、ＮＢ−ＰＤＣＣＨの受信時に開始され、ＲＴＴタイマと並行して作動する。
【０１０４】
いずれの場合でも、ｅＮＢは、対応するＰＵＳＣＨ／ＰＤＳＣＨ送信時にさらなる送信（再送信または新しいＭＡＣ  ＰＤＵ）のみをスケジュールすることができるため、ＮＢ−ＰＤＣＣＨ（ＤＣＩフォーマットＮ０／Ｎ１）の直後にdrx-InactivityTimerを開始する必要はない。したがって、一実施形態によれば、対応するＰＤＳＣＨ／ＰＵＳＣＨ送信の送信後にタイマが開始されるように、drx-InactivityTimerの開始条件が変更される。アップリンクの場合、ｅＮＢは、さらなる再送信または新たな送信をスケジューリングするか否かを決定する前に、受信されたＰＵＳＣＨ送信を最初に処理／復号する必要があるため、drx-InactivityTimerは、ＰＵＳＣＨの送信時にある固定時間後にのみ起動することさえできる。ダウンリンクの場合、ＵＥは、ＰＤＳＣＨ送信を復号し、ｅＮＢがさらなる再送信または新たな送信をスケジュールするかを決定する前に、まずＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）を送信する必要がある。したがって、アップリンクと同様に、drx-InactivityTimerは、ＰＤＳＣＨの送信後のある固定時間（処理時間）にのみ開始することができる。
【０１０５】
別の実施形態によれば、ＮＢ−ＩｏＴのためのＤＲＸ手順は、さらになお最適化／簡略化される。
【０１０６】
この実施形態では、ＤＲＸ動作はdrx-InactivityTimerなしで実行される。より詳細には、上で説明したように、drx-InactivityTimerが（アップリンクの場合）ＰＵＳＣＨの送信のある所定の時間後に開始された場合、drx-InactivityTimerの機能は、drx-ULRetransmissionTimerおよびＵＬ  ＨＡＲＱ  ＲＴＴタイマに類似している。本質的にアップリンクの場合、この実施形態によるＤＲＸ動作は、以下のようなものになる。すなわち、ＰＵＳＣＨ送信の最後のサブフレーム（例えば、ＮＢ−ＰＤＣＣＨによってスケジューリングされた）を送信した後、ＵＥはＵＬ  ＨＡＲＱ  ＲＴＴタイマを開始する。ＵＬ  ＨＡＲＱ  ＲＴＴタイマが満了すると、ＵＥはULRetransmissionTimerを開始し、ＰＤＣＣＨ／ＮＢ−ＰＤＣＣＨ（再送信または新しい送信のスケジューリング）を監視する。これにより、アクティブ時間が短縮され、またdrx-InactivityTimerを取り除くことによって、さらに複雑なテストも取り除かれる。
【０１０７】
図１１は、ＵＥにおいて実行され得る方法としての本発明の実施形態を示すフロー図を示す。
【０１０８】
図１２は、上述したような、本開示による装置１２００のブロック図を示す。
【０１０９】
ダウンリンクの場合、この実施形態による挙動は同様である。
【０１１０】
ダウンリンクデータ送信の一例が図１０Ｂに示されている。特に、図１０Ｂにおいて、ＵＥは、ＰＤＳＣＨの初期（新しいデータ）送信のためのグラントを有するＮＢ−ＰＤＣＣＨを受信し、その後、スケジュールされている（許可された（granted））ＰＤＳＣＨを受信する（ＮＢ−ＰＤＣＣＨの受信とＰＤＳＣＨの受信との間に、いくつかのシステムでは、所定のまたはシグナリングされたオフセットがあり得、同じまたは直後のサブフレームにおいてＰＤＳＣＨを受信することが可能であり得る）。
【０１１１】
（ＮＢ−ＰＤＣＣＨ内のＤＣＩによってスケジューリングされている）ＰＤＳＣＨの受信に応じて、ＵＥはＰＤＳＣＨを復号し、何らかのＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）を送信しようとする。ＵＥは、対応するＰＤＳＣＨ受信の最後の反復（repetition）を含むサブフレーム内で（ＤＬ）ＨＡＲＱ  ＲＴＴタイマを開始する。反復は、ＮＢ−ＩｏＴ／ｅＭＴＣを参照して、上記の背景セクションに記載されている。カバレッジを増加させるために、データは時間領域において数回反復される。しかしながら、本発明は、再送信を実行することに限定されず、一般に、ＤＬ  ＨＡＲＱ  ＲＴＴタイマがＰＤＳＣＨの受信に応じて開始する単一の送信が実行されてもよいことに留意されたい。
【０１１２】
（ＤＬ）ＨＡＲＱ  ＲＴＴタイマの満了に応じて、ＵＥはdrx-RetransmissionTimerを開始し、再送信または新しい送信をスケジューリングするさらなるＤＣＩ（複数可）を監視する。換言すれば、このサブフレームにおいてＤＬ  ＨＡＲＱ  ＲＴＴタイマが満了すると、drx-RetransmissionTimerが開始される。
【０１１３】
図１０Ｂの例では、drx-RetransmissionTimer作動中に、ＵＥは、再送信（Ｒｅ  Ｔｘ）のためのスケジューリングＤＣＩ（ＮＢ−ＰＤＣＣＨ）を受信し、その後、スケジューリングＤＣＩに従って、スケジュールされているリソース上で、再送信されるデータとともにＰＤＳＣＨを受信する。このデータは、ＵＥによって成功裏に復号され、したがって、アップリンクにおいてＡＣＫが送信される。
【０１１４】
drx-RetransmissionTimerの現在の定義と本質的に異なり、本実施形態によるdrx-RetransmissionTimerは、パケット（ＰＤＳＣＨ）がＵＥによって正しく復号され得る場合（すなわち、ＡＣＫの送信後）にも、開始される。これにより、ネットワークは再送信が完了した後に新しい送信をスケジュールすることができる。現在、drx-RetransmissionTimerは、ＵＥがパケットを正しく復号できなかった場合（ＮＡＣＫ）にのみ開始される。
【０１１５】
これは、ＡＣＫ受信の後、ＤＬ  ＨＡＲＱ  ＲＴＴタイマが終了した後もなおdrx-RetransmissionTimerが開始する図１０Ｂに見ることができる。drx-RetransmissionTimerの作動中に、別の初期（新しいデータ）送信のためのＮＢ−ＰＤＣＣＨが受信され、ＰＤＳＣＨ内で対応してスケジュールされたデータが受信される。
【０１１６】
上記の説明は、１つのＨＡＲＱプロセスに焦点を当てていることに留意されたい。ＬＴＥでは、現在、ＮＢ−ＩｏＴに関しては、ダウンリンクにおいても、ただ１つのＨＡＲＱプロセスしか存在しない。しかし、ｅＭＴＣまたはＬＡＡでは、より多くのＨＡＲＱプロセスが存在する可能性がある。一般に、本開示は、１つのプロセスのみに限定されない。以上のようにして、複数のプロセスを処理することができる。
【０１１７】
これに代えて、さらなる実施形態によれば、実際には、ＵＥがパケットを正しく復号することができる場合、すなわちＴＢの最後のＨＡＲＱ送信の後に、drx-InactivityTimerが開始される。この実施形態によれば、drx-RetransmissionTimerの定義は変更されない。本質的には、drx-RetransmissionTimerは、ＴＢに対してスケジュールされているさらなる再送信に注意を払う。すなわち、drx-RetransmissionTimerは、ＴＢが正しく復号できない場合に、ＨＡＲＱ  ＲＴＴタイマの満了に応じて開始される。一方、drx-InactivityTimerは、新しい初期送信についてのＰＤＣＣＨ監視を制御する、すなわち、ＴＢが正しく復号され得る場合に、ＨＡＲＱ  ＲＴＴタイマの満了に応じて、drx-InactivityTimerが開始される。
【０１１８】
この実施形態を図１０Ｃに例示する。図１０Ｂとの違いは、肯定応答（ＡＣＫ）の送信後、drx-RetransmissionTimerが開始されないことである。むしろ、drx-InactivityTimerが開始される。しかしながら、両方の場合において、すなわちdrx-RetransmissionTimerが作動している間およびdrx-InactivityTimerが作動している間に、ＮＢ−ＰＤＣＣＨが監視される。これらの２つのタイマdrx-RetransmissionTimerとdrx-InactivityTimerとはまた、異なる持続時間を有し得ることに留意されたい。
【０１１９】
一実施形態によれば、非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理ダウンリンク共有チャネルを介してデータを受信する装置が提供される。当該装置は、ダウンリンク送信のリソース割当を含むダウンリンク制御情報を受信し、それに従って、割り当てられたリソースにおいてデータの受信を実行し、上記ダウンリンク送信に関連する確認応答の送信を実行するように構成されている受信部を備え、装置は、ダウンリンクデータ送信に応じて開始し、第４の所定の時間が経過した後に停止（満了）するように構成されている第４のタイマと、第４のタイマの満了を受けて開始し、第５の所定の時間が経過した後に停止（満了）するように構成された第５のタイマとをさらに備え、受信部は、第４のタイマが満了しており、第５のタイマが依然として作動しているときのみダウンリンク制御情報の受信を行うように構成されており、第５のタイマは、肯定応答の送信に応じて開始しないようにさらに構成されている。
【０１２０】
この装置は、ダウンリンクデータを受信するＵＥであってもよい。ＵＥは、上述のようにアップリンクおよびダウンリンクの両方で動作することが可能であり得ることに留意されたい。双方向の利点の１つは、肯定応答の受信または送信によって、ＤＲＸに早期に入ることができ、バッテリが節約されることである。
【０１２１】
有利には、第５のタイマは、受信部がダウンリンクデータ送信のための肯定応答を送信するか否かに関係なく開始するようにさらに構成される。
【０１２２】
一実施形態によれば、非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理ダウンリンク共有チャネルを介してデータを送信する装置が提供される。当該装置は、ダウンリンク送信のリソース割当を含むダウンリンク制御情報を送信し、それに従って、割り当てられたリソースにおいてデータの送信を実行し、上記ダウンリンク送信に関連する確認応答の受信を実行するように構成されている送信部を備え、装置は、ダウンリンクデータ送信に応じて開始し、第４の所定の時間が経過した後に停止するように構成されている第４のタイマと、第４のタイマの満了に応じて開始し、第５の所定の時間が経過した後に満了するように構成された第５のタイマとをさらに備え、送信部は、第４のタイマが満了しており、第５のタイマが作動しているときのみダウンリンク制御情報の送信を行うように構成されており、第５のタイマは、肯定応答の受信に応じて開始しないようにさらに構成されている。
【０１２３】
この装置は、ｅＮＢ、すなわち基地局に実装することができる。
【０１２４】
別の実施形態によれば、本発明を実施するように適合されたコンピュータ可読プログラムコードが具現化されたコンピュータ可読媒体を備えるコンピュータプログラム製品が提供される。
【０１２５】
他の例示的な実施形態は、ハードウェアおよびソフトウェアを使用した上述の様々な実施形態の実装に関する。これに関連して、ユーザ端末（移動端末）およびｅＮｏｄｅＢ（基地局）が提供される。ユーザ端末および基地局は、受信部、送信部、プロセッサなどの、方法に適切に関与する対応するエンティティを含む、本明細書で説明される方法を実行するように適合される。
【０１２６】
様々な実施形態は、コンピューティングデバイス（プロセッサ）を使用して実施または実行されてもよいことがさらに認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理デバイスなどであってもよい。様々な実施形態はまた、これらのデバイスの組み合わせによって実施または具現化されてもよい。
【０１２７】
さらに、様々な実施形態はまた、プロセッサによって、または直接ハードウェアによって実行されるソフトウェアモジュールによって実施されてもよい。また、ソフトウェアモジュールとハードウェア実装との組み合わせも可能である。ソフトウェアモジュールは、例えばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ等のような任意の種類のコンピュータ可読記憶媒体に格納することができる。
【０１２８】
複数の異なる実施形態の個々の特徴は、個別にまたは任意に組み合わせて、別の実施形態の主題になり得ることにさらに留意されたい。
【０１２９】
当業者であれば、特定の実施形態に示すように、本開示に対して多くの変形および／または修正を行うことができることが理解されよう。したがって、本実施形態は、すべての点で例示的であり、限定的ではないと考えられるべきである。
【０１３０】
要約すると、本開示は、非同期ハイブリッド自動再送要求（ＨＡＲＱ）を使用することによって、無線通信システムにおいて物理アップリンク共有チャネルを介してデータを送信することに関する。例示的な装置は、アップリンクデータ送信に応じて開始し、第１の所定の時間が経過した後に停止するように構成されている第１のタイマと、第１のタイマの停止に応じて開始し、第２の所定の時間が経過した後に停止するように構成された第２のタイマと、アップリンク新規データ送信または再送信の肯定応答を含むダウンリンク制御情報を受信する受信部とを備え、受信部は、第１のタイマが停止しており、第２のタイマが作動しているときのみ受信を行うように構成されており、第２のタイマは、肯定応答の受信に応じて停止するようにさらに構成されている。さらに、データを受信し、制御チャネルを送信する装置ならびに対応する送信および受信方法が提供される。
【図１】
2019516281.tif 000014
【図２】
2019516281.tif 000015
【図３】
2019516281.tif 000016
【図４】
2019516281.tif 000017
【図５】
2019516281.tif 000018
【図６】
2019516281.tif 000019
【図７】
2019516281.tif 000020
【図８】
2019516281.tif 000021
【図９】
2019516281.tif 000022
【図１０Ａ】
2019516281.tif 000023
【図１０Ｂ】
2019516281.tif 000024
【図１０Ｃ】
2019516281.tif 000025
【図１１】
2019516281.tif 000026
【図１２】
2019516281.tif 000027
【国際調査報告】
2019516281.tif 000028
2019516281.tif 000029
2019516281.tif 000030