JP2019515535A - 短レイテンシ高速再送信トリガ - Google Patents

Abstract

本発明は、通信システムにおけるアップリンクデータパケット送信の改良された送信プロトコルに関する。ユーザ機器の受信機は、ＦＲＩと称する高速再送信インジケータを受信する。ＦＲＩは、以前に送信されたデータパケットの再送信を基地局が要求しているか否かを示す。ユーザ機器の送信機は、データパケットの以前の送信にすでに使用されたものと同じ冗長バージョンを用いてデータパケットを再送信する。【選択図】 図６

Description

本開示は、通信システムにおけるアップリンクデータパケット送信の送信プロトコルを動作させる方法に関する。また、本開示は、本明細書に記載の方法に関与するユーザ機器および基地局を提供している。

［ロングタームエボリューション（ＬＴＥ：Long Term Evolution）］
ＷＣＤＭＡ（登録商標）無線アクセス技術に基づく第３世代移動体システム（３Ｇ）が世界中で広範囲に展開されている。この技術の改良または進化の第１段階には、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：High-Speed Downlink Packet Access）および改良アップリンク（高速アップリンクパケットアクセス（ＨＳＵＰＡ：High-Speed Uplink Packet Access）とも称する）の導入による競争優位な無線アクセス技術の付与を必然的に伴う。

ユーザ需要のさらなる増加に備え、新たな無線アクセス技術に対して優位性を確保するため、３ＧＰＰでは、ロングタームエボリューション（ＬＴＥ）と称する新たな移動体通信システムを導入した。ＬＴＥは、高速データ・メディア転送のほか、大容量音声対応について、今後１０年間のキャリア要求を満たすように設計されている。高ビットレートを提供できることは、ＬＴＥの主要な尺度である。

進化型ＵＭＴＳ地上無線アクセス（ＵＴＲＡ：UMTS Terrestrial Radio Access）およびＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ：UMTS Terrestrial Radio Access Network）と称するロングタームエボリューション（ＬＴＥ）に関する作業項目（ＷＩ）仕様は、第８版（ＬＴＥ Ｒｅｌ．８）として完結されている。ＬＴＥシステムは、低レイテンシ（low latency）かつ低コストな完全ＩＰベースの機能を提供する効率的なパケットベース無線アクセスおよび無線アクセスネットワークを表す。ＬＴＥにおいては、所与のスペクトルを用いた柔軟なシステム配置の実現のため、１．４、３．０、５．０、１０．０、１５．０、および２０．０ＭＨｚ等の拡張可能な複数の送信帯域幅が指定されている。ダウンリンクにおいては、低シンボルレートによるマルチパス干渉（ＭＰＩ）に対する固有の耐性、巡回プレフィックス（ＣＰ）の使用、および異なる送信帯域幅構成への親和性により、直交周波数分割多重（ＯＦＤＭ）ベースの無線アクセスが採用されていた。アップリンクにおいては、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）の送信電力の制約を考慮して、ピークデータレートの向上よりも広範囲のサービスエリアの提供が優先されていたため、シングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）ベースの無線アクセスが採用されていた。ＬＴＥ Ｒｅｌ．８／９においては、多入力多出力（ＭＩＭＯ）チャネル送信技術を含む多くの主要なパケット無線アクセス技術が採用されており、高効率の制御シグナリング構造が実現されている。

［ＬＴＥアーキテクチャ］
全体的なＬＴＥアーキテクチャを図１に示す。Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢからなり、Ｅ−ＵＴＲＡユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）プロトコル終端を、ユーザ機器（ＵＥ）に向けて提供する。ｅＮｏｄｅＢ（ｅＮＢ）は、ユーザプレーンヘッダ圧縮および暗号化の機能を含む物理（ＰＨＹ）、メディアアクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）、およびパケットデータ制御プロトコル（ＰＤＣＰ）レイヤをホスティングする。また、制御プレーンに対応した無線リソース制御（ＲＲＣ）機能も提供する。ｅＮｏｄｅＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクサービス品質（ＱｏＳ）の強制、セル情報ブロードキャスト、ユーザおよび制御プレーンデータの暗号化／復号化、ならびにダウンリンク／アップリンクユーザプレーンパケットヘッダの圧縮／解凍といった多くの機能を実行する。ｅＮｏｄｅＢは、Ｘ２インターフェースによって相互に接続されている。

また、ｅＮｏｄｅＢは、Ｓ１インターフェースによってＥＰＣ（進化型パケットコア）にも接続されており、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（モビリティ管理エンティティ）に、Ｓ１−Ｕによってサービングゲートウェイ（ＳＧＷ）に接続されている。Ｓ１インターフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多の関係に対応している。ＳＧＷは、ｅＮｏｄｅＢ間ハンドオーバ時のユーザプレーンのモビリティアンカーとして、また、ＬＴＥと他の３ＧＰＰ技術との間のモビリティのアンカーとしても作用しつつ（Ｓ４インターフェースを終端させるとともに、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間のトラヒックを中継しつつ）、ユーザデータパケットのルーティングおよび転送を行う。アイドル状態のユーザ機器に対して、ＳＧＷは、ダウンリンクデータパスを終端させ、ダウンリンクデータがユーザ機器に到着した場合にページングをトリガする。ＳＧＷは、ユーザ機器のコンテキスト（たとえば、ＩＰベアラサービスのパラメータ）またはネットワーク内部ルーティング情報を管理・記憶する。また、合法的傍受の場合のユーザトラヒックの複製も実行する。

ＭＭＥは、ＬＴＥアクセスネットワークの主要な制御ノードである。再送信を含めて、アイドルモードのユーザ機器の追跡およびページング手順を担う。ＭＭＥは、ベアラ有効化／無効化プロセスに関与するとともに、初期接続時およびコアネットワーク（ＣＮ）ノードの再配置を伴うＬＴＥ内ハンドオーバ時におけるユーザ機器のＳＧＷの選定を担う。また、（ＨＳＳとの相互作用により）ユーザの認証を担う。ＭＭＥでは、非アクセス層（ＮＡＳ）シグナリングが終端するとともに、仮識別情報の生成およびユーザ機器への配分も担う。ユーザ機器の認証を確認して、サービスプロバイダの公衆陸上移動体ネットワーク（ＰＬＭＮ）に留まるとともに、ユーザ機器のローミング制限を強制する。ＭＭＥは、ＮＡＳシグナリングの暗号化／完全性保護のためのネットワーク中の終端点であり、セキュリティの主要管理を取り扱う。ＭＭＥは、シグナリングの合法的傍受にも対応している。また、ＭＭＥは、Ｓ３インターフェースがＳＧＳＮからＭＭＥで終端している状態のＬＴＥと２Ｇ／３Ｇアクセスネットワークとの間のモビリティの制御プレーン機能も提供する。また、ＭＭＥは、ホームＨＳＳに向かってＳ６ａインターフェースを終端させ、ユーザ機器をローミングさせる。

［ＬＴＥにおけるコンポーネントキャリア構造］
３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、時間−周波数領域において、いわゆるサブフレームに細分化される。３ＧＰＰ ＬＴＥにおいては、図２に示すように、各サブフレームが２つのダウンリンクスロットに分割され、第１のダウンリンクスロットが第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を含む。各サブフレームは、時間領域において所与数のＯＦＤＭシンボル（３ＧＰＰ ＬＴＥ（Ｒｅｌ．８）においては１２個または１４個のＯＦＤＭシンボル）からなり、各ＯＦＤＭシンボルがコンポーネントキャリアの帯域幅全体に及ぶ。したがって、ＯＦＤＭシンボルはそれぞれ、各サブキャリア上で送信される多数の変調シンボルからなる。ＬＴＥにおいて、各スロットの送信信号は、Ｎ^ＤＬ _ＲＢＮ^ＲＢ _ＳＣ個のサブキャリアおよびＮ^ＤＬ _ｓｙｍｂ個のＯＦＤＭシンボルのリソースグリッドにより記述される。Ｎ^ＤＬ _ＲＢは、帯域幅内のリソースブロックの数である。数量Ｎ^ＤＬ _ＲＢは、セル中に設定されたダウンリンク送信帯域幅によって決まり、Ｎ^{ｍｉｎ，ＤＬ} _ＲＢ≦Ｎ^ＤＬ _ＲＢ≦Ｎ^{ｍａｘ，ＤＬ} _ＲＢを満たすものとする。ここで、Ｎ^{ｍｉｎ，ＤＬ} _ＲＢ＝６およびＮ^{ｍａｘ，ＤＬ} _ＲＢ＝１１０はそれぞれ、最小および最大のダウンリンク帯域幅であり、現行版の仕様が対応している。Ｎ^ＲＢ _ＳＣは、１つのリソースブロック内のサブキャリアの数である。通常の巡回プレフィックスサブフレーム構造の場合は、Ｎ^ＲＢ _ＳＣ＝１２およびＮ^ＤＬ _ｓｙｍｂ＝７となる。

たとえば３ＧＰＰロングタームエボリューション（ＬＴＥ）において用いられるＯＦＤＭ等を採用したマルチキャリア通信システムを仮定して、スケジューラにより割り当て可能なリソースの最小単位は、１つの「リソースブロック」である。図２に例示の通り、物理リソースブロック（ＰＲＢ）は、時間領域においては連続するＯＦＤＭシンボル（たとえば、７個のＯＦＤＭシンボル）として、周波数領域においては連続するサブキャリア（たとえば、コンポーネントキャリアの場合は１２個のサブキャリア）として規定される。このため、３ＧＰＰ ＬＴＥ（Ｒｅｌ．８）において、物理リソースブロックは、時間領域における１スロットおよび周波数領域における１８０ｋＨｚに対応したリソースエレメントからなる（ダウンリンクリソースグリッドの詳細については、たとえばｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能な３ＧＰＰ ＴＳ ３６．２１１「Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ （Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌｓ ａｎｄ Ｍｏｄｕｌａｔｉｏｎ （Ｒｅｌｅａｓｅ ８）」（現行版１３．０．０、第６．２項）を参照できるが、これを本明細書に援用する）。

１つのサブフレームは２つのスロットからなるため、いわゆる「通常の」ＣＰ（巡回プレフィックス）が用いられる場合はサブフレーム中に１４個のＯＦＤＭシンボルが存在し、いわゆる「拡張」ＣＰが用いられる場合はサブフレーム中に１２個のＯＦＤＭシンボルが存在する。専門用語の便宜上、以下では、サブフレーム全体に及ぶ同じ連続サブキャリアと同等の時間−周波数リソースを「リソースブロック対」または同等の「ＲＢ対」もしくは「ＰＲＢ対」と称する。

用語「コンポーネントキャリア」は、周波数領域における複数のリソースブロックの組み合わせを表す。ＬＴＥの将来版において、用語「コンポーネントキャリア」は使用されなくなる。代替として、専門用語が「セル」に変更となるが、これは、ダウンリンクリソースおよび任意選択でアップリンクリソースの組み合わせを表す。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との連携については、ダウンリンクリソース上で送信されるシステム情報において指定される。

コンポーネントキャリア構造に関する同様の仮定が後継版にも当てはまる。

［より広い帯域幅に対応するためのＬＴＥ−Ａにおけるキャリアアグリゲーション］
世界無線通信会議２００７（ＷＲＣ−０７）において、ＩＭＴアドバンスの周波数スペクトルが決定された。ＩＭＴアドバンスの全周波数スペクトルが決定されたものの、実際に利用可能な周波数帯域幅は、地域または国ごとに異なる。ただし、利用可能な周波数スペクトルの概略の決定に続いて、第３世代パートナーシッププロジェクト（３ＧＰＰ）においては、無線インターフェースの標準化が開始となった。３ＧＰＰ ＴＳＧ ＲＡＮ ＃３９会合においては、「Ｅ−ＵＴＲＡのさらなる進展（ＬＴＥアドバンス）」に関する検討事項記載が承認された。この検討事項は、たとえばＩＭＴアドバンスに関する要件の満足等、Ｅ−ＵＴＲＡの進化について考慮すべき技術要素を網羅している。

ＬＴＥアドバンスシステムが対応可能な帯域幅は１００ＭＨｚである。一方、ＬＴＥシステムは、２０ＭＨｚにしか対応できない。今日、無線スペクトルの不足が無線ネットワークの発展のボトルネックとなっており、結果として、ＬＴＥアドバンスシステムに十分な広さのスペクトル帯を見出すのが困難である。その結果、より広い無線スペクトル帯を獲得する方法を見出すことが喫緊の課題であり、その考え得る答えがキャリアアグリゲーション機能である。

キャリアアグリゲーションにおいては、最大１００ＭＨｚのより広い送信帯域幅に対応するために、２つ以上のコンポーネントキャリアが集約される。ＬＴＥシステムの複数のセルがＬＴＥアドバンスシステムの１つのより広いチャネルに集約され、これは、ＬＴＥのこれらセルが異なる周波数帯であったとしても、１００ＭＨｚに十分な広さである。

少なくともコンポーネントキャリアの帯域幅がＬＴＥ Ｒｅｌ．８／９セルの対応帯域幅を超えない場合は、ＬＴＥ Ｒｅｌ．８／９準拠となるようにすべてのコンポーネントキャリアを設定可能である。ユーザ機器により集約されたすべてのコンポーネントキャリアが必ずしもＲｅｌ．８／９準拠である必要はない。Ｒｅｌ．８／９ユーザ機器がコンポーネントキャリアに留まらないように、既存のメカニズム（たとえば、バーリング（barring））が用いられるようになっていてもよい。

ユーザ機器は、その能力に応じて、（複数のサービングセルに対応する）１つまたは複数のコンポーネントキャリア上で受信または送信を同時に行うようにしてもよい。キャリアアグリゲーションの受信および／または送信能力を備えたＬＴＥ−Ａ Ｒｅｌ．１０ユーザ機器は、複数のサービングセル上で受信および／または送信を同時に行うことができる。一方、ＬＴＥ Ｒｅｌ．８／９ユーザ機器は、コンポーネントキャリアの構造がＲｅｌ．８／９仕様に従うことを前提として、単一のサービングセル上でしか受信および送信を行うことができない。

キャリアアグリゲーションは、（３ＧＰＰ ＬＴＥ（Ｒｅｌ．８／９）ヌメロロジを用いた）それぞれ周波数領域において最大１１０個のリソースブロックに限定される連続および非連続の両コンポーネントキャリアに関して対応がなされている。

アップリンクおよびダウンリンクにおいて、同じｅＮｏｄｅＢ（基地局）に由来する異なる数のコンポーネントキャリアおよび異なる数の潜在的に異なる帯域幅を集約するように、３ＧＰＰ ＬＴＥ−Ａ（Ｒｅｌ．１０）準拠ユーザ機器を設定することができる。設定可能なダウンリンクコンポーネントキャリアの数は、ＵＥのダウンリンクアグリゲーション能力によって決まる。逆に、設定可能なアップリンクコンポーネントキャリアの数は、ＵＥのアップリンクアグリゲーション能力によって決まる。現在は、ダウンリンクコンポーネントキャリアよりも多くのアップリンクコンポーネントキャリアでは、移動端末を設定できない場合がある。通常のＴＤＤ配置においては、アップリンクおよびダウンリンクにおけるコンポーネントキャリア数および各コンポーネントキャリアの帯域幅が同じである。同じｅＮｏｄｅＢに由来するコンポーネントキャリアは、同じサービスエリアを提供する必要がない。

連続して集約されたコンポーネントキャリアの中心周波数間の間隔は、３００ｋＨｚの倍数であるものとする。これは、３ＧＰＰ ＬＴＥ（Ｒｅｌ．８／９）の１００ｋＨｚ周波数ラスタに適合すると同時に、１５ｋＨｚ間隔のサブキャリアの直交性を保つためである。アグリゲーションシナリオに応じて、連続するコンポーネントキャリア間に少数の未使用サブキャリアを挿入することにより、ｎ×３００ｋＨｚの間隔を促進することができる。

複数キャリアのアグリゲーションの性質は、ＭＡＣレイヤまでしか現れない。アップリンクおよびダウンリンクの両者について、集約されたコンポーネントキャリアごとに１つのＨＡＲＱエンティティがＭＡＣに求められる。１つのコンポーネントキャリアについては、（アップリンクにＳＵ−ＭＩＭＯがない場合）存在するトランスポートブロックは高々１つである。トランスポートブロックおよびその潜在的なＨＡＲＱ再送信は、同じコンポーネントキャリア上でマッピングされる必要がある。

キャリアアグリゲーションが設定された場合、移動端末とネットワークとのＲＲＣ接続は、１つだけである。ＲＲＣ接続の確立／再確立においては、ＬＴＥ Ｒｅｌ．８／９と同様に、１つのセルがセキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩ、および１つのＡＲＦＣＮ）および非アクセス層モビリティ情報（たとえば、ＴＡＩ）を提供する。ＲＲＣ接続の確立／再確立後、当該セルに対応するコンポーネントキャリアは、ダウンリンクプライマリセル（ＰＣｅｌｌ）と称する。接続状態の１つのユーザ機器については常に、ダウンリンクＰＣｅｌｌ（ＤＬ ＰＣｅｌｌ）およびアップリンクＰＣｅｌｌ（ＵＬ ＰＣｅｌｌ）がそれぞれ１つだけ存在する。設定された一組のコンポーネントキャリアにおいて、他のセルは、セカンダリセル（ＳＣｅｌｌ）と称し、そのＳＣｅｌｌのキャリアは、ダウンリンクセカンダリコンポーネントキャリア（ＤＬ ＳＣＣ）およびアップリンクセカンダリコンポーネントキャリア（ＵＬ ＳＣＣ）である。１つのＵＥについて、ＰＣｅｌｌを含む最大５つのサービングセルを設定可能である。

［ＭＡＣレイヤ／エンティティ、ＲＲＣレイヤ、物理レイヤ］
ＬＴＥレイヤ２ユーザプレーン／制御プレーンプロトコルスタックは、ＲＲＣ、ＰＤＣＰ、ＲＬＣ、およびＭＡＣという４つのサブレイヤを含む。メディアアクセス制御（ＭＡＣ）レイヤは、ＬＴＥ無線プロトコルスタックのレイヤ２アーキテクチャの最下位サブレイヤであり、たとえば３ＧＰＰ技術規格ＴＳ ３６．３２１（現行版１３．０．０）によって規定されている。その下の物理レイヤへの接続はトランスポートチャネルを介し、その上のＲＬＣレイヤへの接続は論理チャネルを介する。したがって、ＭＡＣレイヤは、論理チャネルとトランスポートチャネルとの多重化および逆多重化を実行する。送信側のＭＡＣレイヤは、論理チャネルを通じて受信したＭＡＣ ＳＤＵからトランスポートブロックとして知られるＭＡＣ ＰＤＵを構成し、受信側のＭＡＣレイヤは、トランスポートチャネルを通じて受信したＭＡＣ ＰＤＵからＭＡＣ ＳＤＵを復元する。

ＭＡＣレイヤは、論理チャネルを通じたＲＬＣレイヤのデータ転送サービス（ＴＳ ３６．３２１の第５．４項および５．３項を参照できるが、これを本明細書に援用する）を提供するが、これらの論理チャネルは、制御データ（たとえば、ＲＲＣシグナリング）を搬送する制御論理チャネルまたはユーザプレーンデータを搬送するトラヒック論理チャネルである。一方、ＭＡＣレイヤからのデータは、ダウンリンクまたはアップリンクとして分類されるトランスポートチャネルを通じて物理レイヤと交換される。データは、無線送信の方法に応じてトランスポートチャネルへと多重化される。

物理レイヤは、データおよび制御情報の実際の無線送信を担う。すなわち、物理レイヤは、送信側で、ＭＡＣトランスポートチャネルからのすべての情報を無線搬送する。物理レイヤが実行する重要な機能としては、符号化および変調、リンクアダプテーション（ＡＭＣ）、電力制御、（初期同期およびハンドオーバを目的とした）セルサーチ、ならびに、ＲＲＣレイヤに関する（ＬＴＥシステムの内側およびシステム間の）他の測定が挙げられる。物理レイヤは、変調方式、符号化レート（すなわち、変調・符号化方式（ＭＣＳ））、物理リソースブロック数等の送信パラメータに基づいて、送信を実行する。物理レイヤの機能に関する詳細については、３ＧＰＰ技術規格３６．２１３（現行版１３．０．０）に見られるが、これを本明細書に援用する。

無線リソース制御（ＲＲＣ）レイヤは、無線インターフェースにおけるＵＥとｅＮＢとの間の通信および複数のセルを移動するＵＥのモビリティを制御する。また、ＲＲＣプロトコルは、ＮＡＳ情報の転送にも対応している。ＲＲＣ＿ＩＤＬＥのＵＥの場合、ＲＲＣは、着呼のネットワークからの通知にも対応している。ＲＲＣ接続制御は、ページング、測定の設定および報告、無線リソース設定、初期セキュリティ有効化、ならびに、シグナリング無線ベアラ（ＳＲＢ）およびユーザデータを搬送する無線ベアラ（データ無線ベアラＤＲＢ）の確立等を含む、ＲＲＣ接続の確立、変更、および解放に関連するすべての手順を網羅する。

無線リンク制御（ＲＬＣ）サブレイヤは、主としてＡＲＱ機能を含み、データの分割（segmentation）および連結（concatenation）に対応している。すなわち、ＲＬＣレイヤは、ＭＡＣレイヤが指定するサイズへとＲＬＣ ＳＤＵのフレーミングを実行する。後者２つにより、データレートとは独立してプロトコルオーバヘッドが最小限に抑えられる。ＲＬＣレイヤは、論理チャネルを介してＭＡＣレイヤに接続されている。各論理チャネルは、異なる種類のトラヒックを伝送する。ＲＬＣレイヤの上位レイヤは通常、ＰＤＣＰレイヤであるが、場合によってはＲＲＣレイヤである。すなわち、論理チャネルＢＣＣＨ（ブロードキャスト制御チャネル）、ＰＣＣＨ（ページング制御チャネル）、およびＣＣＣＨ（共通制御チャネル）上で送信されるＲＲＣメッセージには、セキュリティ保護が不要なため、ＰＤＣＰレイヤを迂回して直接ＲＬＣレイヤに向かう。ＲＬＣサブレイヤの主要なサービスおよび機能としては、
ＡＭ、ＵＭ、またはＴＭデータ転送に対応する上位レイヤＰＤＵの転送、
ＡＲＱを通じた誤り訂正、
ＴＢのサイズに応じた分割、
必要に応じた再分割（たとえば、無線品質すなわち対応ＴＢサイズの変更時）、
ＦＦＳにおいて無線ベアラが同じ場合のＳＤＵの連結、
上位レイヤＰＤＵのシーケンス内配送、
複製検出、
プロトコル誤り検出および復元、
ＳＤＵ破棄、
リセット、
が挙げられる。

ＲＬＣレイヤが提供するＡＲＱ機能については、以下により詳しく論じる。

［ＬＴＥのアップリンクアクセス方式］
アップリンク送信の場合、サービスエリアを最大化するには、電力効率の良いユーザ端末送信が必要である。進化型ＵＴＲＡアップリンク送信方式としては、動的な帯域幅配分を伴うＦＤＭＡと組み合わされたシングルキャリア送信が選定されている。シングルキャリア送信が優先される主な理由は、マルチキャリア信号（ＯＦＤＭＡ）と比べて、ピーク対平均電力比（ＰＡＰＲ）が低く、対応して電力増幅器の効率が改善されるとともにサービスエリアが改善されている（所与の端末ピーク電力に対してデータレートが高い）ことである。各時間間隔において、ｅＮｏｄｅＢは、ユーザデータを送信する一意の時間／周波数リソースをユーザに割り当てることにより、セル内直交性を確保する。アップリンクにおける直交アクセスによって、セル内干渉の除外によりスペクトル効率の向上が期待される。マルチパス伝搬に起因する干渉は、送信信号への巡回プレフィックスの挿入によって、基地局（ｅＮｏｄｅＢ）で処理される。

データ送信に用いられる基本的な物理リソースは、符号化情報ビットがマッピングされた１つの時間間隔（たとえば、サブフレーム）におけるサイズＢＷｇｒａｎｔの周波数リソースからなる。送信時間間隔（ＴＴＩ）とも称するサブフレームは、ユーザデータ送信の最小時間間隔であることに留意されたい。ただし、サブフレームの連結によって、１つのＴＴＩよりも長い時間にわたる周波数リソースＢＷｇｒａｎｔをユーザに割り当てることができる。

［レイヤ１／レイヤ２制御シグナリング］
スケジューリングされたユーザにそれぞれの配分ステータス、トランスポートフォーマット、および他のデータに関連する情報（たとえば、ＨＡＲＱ）を知らせるため、ダウンリンク上でデータと併せてＬ１／Ｌ２制御シグナリングが送信される必要がある。制御シグナリングは、（ユーザ配分がサブフレームごとに変化し得ることを仮定して）サブフレームにおいてダウンリンクデータと多重化される必要がある。ここで、ユーザ配分はＴＴＩ（送信時間間隔）ベースで実行されてもよく、ＴＴＩ長がサブフレームの倍数であることに留意されたい。ＴＴＩ長は、すべてのユーザについてサービスエリアで固定されていてもよいし、異なるユーザごとに異なっていてもよいし、ユーザごとに動的であってもよい。一般的に、Ｌ１／Ｌ２制御シグナリングは、ＴＴＩごとに送信されればよい。Ｌ１／Ｌ２制御シグナリングは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）上で送信される。ＰＤＣＣＨ上では、アップリンクデータ送信、ＵＬグラントへの割り当ても送信されることに留意されたい。

以下では、ＤＬ配分の各アップリンク割り当て用に伝達される詳細なＬ１／Ｌ２制御シグナリング情報について説明する。

［ダウンリンクデータ送信］
ダウンリンクパケットデータ送信と併せて、Ｌ１／Ｌ２制御シグナリングが別個の物理チャネル（ＰＤＣＣＨ）上で送信される。このＬ１／Ｌ２制御シグナリングは通常、以下に関する情報を含む。

・データが送信される物理リソース（たとえば、ＯＦＤＭの場合のサブキャリアまたはサブキャリアブロック、ＣＤＭＡの場合のコード）：この情報によれば、ＵＥ（受信機）は、データが送信されるリソースを識別することができる。

・送信に用いられるトランスポートフォーマット：これは、データのトランスポートブロックサイズ（ペイロードサイズ、情報ビットサイズ）、ＭＣＳ（変調・符号化方式）レベル、スペクトル効率、符号化率等が考えられる。この情報によれば（通例、リソース配分と併せて）、ＵＥ（受信機）は、情報ビットサイズ、変調方式、および符号化率を識別して、復調、デレートマッチング、および復号化プロセスを開始することができる。場合によっては、変調方式が明示的に伝達されるようになっていてもよい。

・ハイブリッドＡＲＱ（ＨＡＲＱ）情報：
プロセス番号：データがマッピングされるハイブリッドＡＲＱプロセスをＵＥが識別できるようになる。
シーケンス番号または新規データインジケータ：送信が新たなパケットか再送信パケットかをＵＥが識別できるようになる。
冗長および／または信号点配置バージョン：使用されるハイブリッドＡＲＱ冗長バージョン（デレートマッチングに必要）および／または使用される変調信号点配置バージョン（復調に必要）をＵＥに知らせる。

・ＵＥ識別情報（ＵＥ ＩＤ）：Ｌ１／Ｌ２制御シグナリングが対象とするＵＥを知らせる。通常の実施態様において、この情報は、Ｌ１／Ｌ２制御シグナリングのＣＲＣのマスクによって、他のＵＥがこの情報を読めないようにするために用いられる。

［アップリンクデータ送信］
アップリンクパケットデータ送信を可能にするにため、ダウンリンク（ＰＤＣＣＨ）上でのＬ１／Ｌ２制御シグナリングの送信によって、送信の詳細をＵＥに知らせる。このＬ１／Ｌ２制御シグナリングは通常、以下に関する情報を含む。

・ＵＥがデータを送信すべき物理リソース（たとえば、ＯＦＤＭの場合のサブキャリアまたはサブキャリアブロック、ＣＤＭＡの場合のコード）。

・ＵＥが送信に使用すべきトランスポートフォーマット：これは、データのトランスポートブロックサイズ（ペイロードサイズ、情報ビットサイズ）、ＭＣＳ（変調・符号化方式）レベル、スペクトル効率、符号化率等が考えられる。この情報によれば（通例、リソース配分と併せて）、ＵＥ（送信機）は、情報ビットサイズ、変調方式、および符号化率を得て、変調、レートマッチング、および符号化プロセスを開始することができる。場合によっては、変調方式が明示的に伝達されるようになっていてもよい。

・ハイブリッドＡＲＱ情報：
プロセス番号：データを得るべきハイブリッドＡＲＱプロセスをＵＥに知らせる。
シーケンス番号または新規データインジケータ：新たなパケットの送信またはパケットの再送信をＵＥに知らせる。
冗長および／または信号点配置バージョン：使用するハイブリッドＡＲＱ冗長バージョン（レートマッチングに必要）および／または使用する変調信号点配置バージョン（変調に必要）をＵＥに知らせる。
ＵＥ識別情報（ＵＥ ＩＤ）：データを送信すべきＵＥを知らせる。通常の実施態様において、この情報は、Ｌ１／Ｌ２制御シグナリングのＣＲＣのマスクによって、他のＵＥがこの情報を読めないようにするために用いられる。

前述の情報の正確な送信方法には複数の異なる特色がある。さらに、Ｌ１／Ｌ２制御情報は、別の情報を含んでいてもよいし、情報の一部を省略していてもよい。たとえば、以下の通りである。

・同期ＨＡＲＱプロトコルの場合、ＨＡＲＱプロセス番号は不要となる可能性がある。

・チェイス合成が用いられる場合（常に同じ冗長および／もしくは信号点配置バージョン）または冗長および／もしくは信号点配置バージョンのシーケンスが予め規定されている場合、冗長および／または信号点配置バージョンは不要となる可能性がある。

・電力制御情報が制御シグナリングに別途含まれていてもよい。

・たとえばプリコーディング等のＭＩＭＯ関連制御情報が制御シグナリングに別途含まれていてもよい。

・マルチコードワードＭＩＭＯ送信の場合は、複数のコードワードのトランスポートフォーマットおよび／またはＨＡＲＱ情報が含まれていてもよい。

ＬＴＥのＰＤＣＣＨ上で伝達されるアップリンクリソース割り当て（ＰＵＳＣＨ）の場合は、ＬＴＥアップリンクに同期ＨＡＲＱプロトコルが採用されるため、Ｌ１／Ｌ２制御情報にＨＡＲＱプロセス番号を含まない。アップリンク送信に用いられるＨＡＲＱプロセスは、タイミングによって与えられる。さらに、冗長バージョン（ＲＶ）情報がトランスポートフォーマット情報と一緒に符号化される。すなわち、ＲＶ情報は、トランスポートフォーマット（ＴＦ）フィールドに埋め込まれることに留意されたい。ＴＦの各ＭＣＳフィールドは、たとえば５ビットのサイズを有し、３２個のエントリに対応する。ＲＶ１、２、または３の指定には、３つのＴＦ／ＭＣＳテーブルエントリが確保される。その他のＭＣＳテーブルエントリは、ＲＶ０を非明示的に指定するＭＣＳレベル（ＴＢＳ）を伝達するのに用いられる。ＰＤＣＣＨのＣＲＣフィールドのサイズは、１６ビットである。ＰＵＳＣＨ上のアップリンクリソース配分の制御情報に関する詳細については、ＴＳ ３６．２１２の第５．３．３項およびＴＳ ３６．２１３の第８．６項に見られる。

ＬＴＥのＰＤＣＣＨ上で伝達されるダウンリンク割り当て（ＰＤＳＣＨ）の場合、冗長バージョン（ＲＶ）は、２ビットフィールドで別個に伝達される。さらに、変調順序情報は、トランスポートフォーマット情報と一緒に符号化される。アップリンクの場合と同様に、ＰＤＣＣＨ上では、５ビットのＭＣＳフィールドが伝達される。明示的な変調順序を伝達するのにエントリのうちの３つが確保され、トランスポートフォーマット（トランスポートブロック）情報が提供されない。その他の２９個のエントリについて、変調順序およびトランスポートブロックサイズ情報が伝達される。ＰＵＳＣＨ上のアップリンクリソース配分の制御情報に関する詳細については、ＴＳ ３６．２１２の第５．３．３項およびＴＳ ３６．２１３の第７．１．７項に見られるが、これらを本明細書に援用する。

［Ｅ−ＵＴＲＡＮ測定 − 測定ギャップ（measurement gaps）］
Ｅ−ＵＴＲＡＮは、測定情報を報告し、たとえばＵＥモビリティの制御をサポートするようにＵＥを設定可能である。各測定設定要素は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージによってシグナリングされる。たとえば、アップリンクまたはダウンリンク送信がスケジューリングされない時間を測定ギャップが規定するため、ＵＥは、測定を実行するようにしてもよい。測定ギャップは、ギャップを利用したすべての測定に共通である。周波数間測定では、ＵＥの能力（たとえば、デュアル受信機を有するか）に応じて、測定ギャップの設定が必要となる場合がある。ＵＥは、サービングセル以外のキャリア周波数上で動作するＥ−ＵＴＲＡセルを識別する。ＵＥが２つ以上の受信機を持たない場合、セル識別を含む周波数間測定は、周期的な測定ギャップにおいて実行される。それぞれ長さが６ｍｓの２つの考え得るギャップパターンをネットワークによって設定可能である。ギャップパターン＃０ではギャップが４０ｍｓごとに発生する一方、ギャップパターン＃１ではギャップが８０ｍｓごとに発生する。

たとえば、基準信号受信電力（ＲＳＲＰ）は、測定期間にわたる測定帯域幅内のセル固有の基準信号に対してＵＥにより測定される。

［ＡＲＱ／ハイブリッドＡＲＱ（ＨＡＲＱ）方式］
ＬＴＥにおいては、信頼性を与える２つの再送信レベル、すなわち、ＭＡＣレイヤにおけるＨＡＲＱおよびＲＬＣレイヤにおける外部ＡＲＱ（outer ARQ）が存在する。ＲＬＣ再送信メカニズムは、上位レイヤへの誤りのないデータ配送の提供を担う。これを実現するため、たとえば応答モードにおいて、受信機および送信機のＲＬＣエンティティ間で（再）送信プロトコルが動作する。ノイズ、予測不可能なチャネル変動等に起因する送信誤りは、ＲＬＣレイヤが処理可能であるものの、ほとんどの場合は、ＭＡＣレイヤのＨＡＲＱ再送信プロトコルによって処理される。したがって、ＲＬＣレイヤの再送信メカニズムの使用は、当初は不要に見える場合がある。ただし、事実は異なり、実際には、フィードバックシグナリングの差が、ＲＬＣベースおよびＭＡＣベースの両再送信メカニズムの十分なきっかけとなる。たとえば、ＲＬＣ−ＡＲＱメカニズムは、ＭＡＣ ＨＡＲＱメカニズムで起こり得る潜在的なＮＡＣＫ対ＡＣＫ誤りに対処する。

信頼性の低いチャネル上でのパケット送信システムの誤り検出および訂正の一般的な技術は、ハイブリッド自動再送要求（ＨＡＲＱ）と称する。ハイブリッドＡＲＱは、順方向誤り訂正（ＦＥＣ）とＡＲＱとの組み合わせである。ＦＥＣ符号化パケットが送信され、受信機がパケットを正しく復号できない場合（誤りは通例、ＣＲＣ（巡回冗長検査）によって検査される）、受信機は、パケットの再送信を要求する。

［ＲＬＣ再送信プロトコル］
ＲＬＣは、失われたＰＤＵの再送信を要求するように設定されている場合、応答モード（ＡＭ：Acknowledged Mode）で動作しているものと考えられる。これは、ＷＣＤＭＡ／ＨＳＰＡで用いられる対応するメカニズムと同様である。

全体として、ＲＬＣには、透過モード（ＴＭ：Transparent Mode）、非応答モード（ＵＭ：Unacknowledged Mode）、および応答モード（ＡＭ：Acknowledged Mode）という３つの動作モードが存在する。各ＲＬＣエンティティは、ＲＲＣによって、これらのモードのうちの１つで動作するように設定されている。

透過モードにおいては、上位レイヤから受信されたＲＬＣ ＳＤＵに対してプロトコルオーバヘッドが追加されない。特別な場合に、分割／再組み立て能力が制限された送信を実現可能である。無線ベアラセットアップ手順においては、分割／再組み立ての使用の有無を取り決める必要がある。透過モードは、たとえば会話のように遅延の影響を大きく受けやすいサービスに用いられる。

非応答モードにおいては、再送信プロトコルが使用されないため、データ配送が保証されない。ＰＤＵ構造には、上位レイヤにおける完全性観測用のシーケンス番号を含む。ＲＬＣシーケンス番号に基づいて、受信ＵＭ ＲＬＣエンティティは、受信ＲＬＣ ＰＤＵの並べ替えを実行可能である。分割および連結は、データに追加されたヘッダフィールドによって与えられる。非応答モードにおけるＲＬＣエンティティは、アップリンクとダウンリンクとの間に関連付けが規定されていないため、単方向である。誤ったデータが受信された場合は、設定に応じて対応するＰＤＵが破棄またはマーキングされる。送信機において、タイマにより指定される一定の時間内に送信されないＲＬＣ ＳＤＵは、破棄されて送信バッファから除外される。上位レイヤから受信したＲＬＣ ＳＤＵは、送信側でＲＬＣ ＰＤＵへと分割／連結される。受信側では、これに対応して再組み立てが実行される。非応答モードは、たとえば特定のＲＲＣシグナリング手順の場合のＭＢＭＳおよびボイスオーバＩＰ（ＶｏＩＰ）等のセルブロードキャストサービス等、配送時間の短さと比較して誤りのない配送の重要度が低いサービスに用いられる。

応答モードにおいて、ＲＬＣレイヤは、自動再送要求（ＡＲＱ）プロトコルによる誤り訂正に対応しており、通常は、誤りのないデータ配送に一番の関心があるファイル転送等のＩＰベースのサービスに用いられる。ＲＬＣ再送信は、たとえばピアＲＬＣ受信エンティティから受信されたＲＬＣステータスレポートすなわちＡＣＫ／ＮＡＣＫに基づく。応答モードは、高いエアインターフェースビット誤り率の存在下での再送信による確実なパケットデータの伝送用に設計されている。ＰＤＵの誤りまたは喪失の場合は、受信機からのＲＬＣステータスレポートの受信に応じて、送信機により再送信が行われる。

ＡＲＱは、誤ったＰＤＵまたは失われたＰＤＵの再送信のための再送信方式として利用される。たとえば、入力シーケンス番号をモニタリングすることにより、受信ＲＬＣエンティティは、失われたＰＤＵを識別することができる。そして、受信ＲＬＣ側でＲＬＣステータスレポートを生成し、送信ＲＬＣエンティティにフィードバックして、失われたＰＤＵまたは上手く復号されなかったＰＤＵの再送信を要求することができる。また、ＲＬＣステータスレポートは、送信機によりポーリング可能である。すなわち、ＲＬＣ送信機がポーリング機能を使用して、ＲＬＣ受信機からステータスレポートを取得することにより、受信バッファステータスをＲＬＣ送信機に知らせる。ステータスレポートは、ＨＡＲＱ並べ替えが完了する最後のＲＬＣデータＰＤＵまで、ＲＬＣデータＰＤＵまたはその一部上で肯定応答（ＡＣＫ）または否定応答情報（ＮＡＣＫ）を提供する。ＲＬＣ受信機は、ポーリングフィールドを備えたＰＤＵが「１」に設定された場合またはＲＬＣデータＰＤＵが失われた旨が検出された場合、ステータスレポートをトリガする。ＴＳ ３６．３２２（現行版１３．０．０）の第５．２．３項には、ＲＬＣ送信機においてＲＬＣステータスレポートのポーリングをトリガする特定のトリガが規定されており、これを本明細書に援用する。送信機においては、送信ウィンドウ内のＰＤＵにのみ送信が許可されており、送信ウィンドウは、ＲＬＣステータスレポートによってのみ更新される。したがって、ＲＬＣステータスレポートが遅延すると、送信ウィンドウを進められず、送信が停滞する可能性がある。

受信機は、トリガされたときＲＬＣステータスレポートを送信機に送信する。

すでに上述した通り、データＰＤＵ配送のほか、ピアエンティティ間で制御ＰＤＵを伝達可能である。

［ＭＡＣ ＨＡＲＱプロトコル］
ＭＡＣレイヤは、送受信ＨＡＲＱ動作を担うＨＡＲＱエンティティを含む。送信ＨＡＲＱ動作には、トランスポートブロックの送信および再送信ならびにＡＣＫ／ＮＡＣＫシグナリングの受信および処理を含む。受信ＨＡＲＱ動作には、トランスポートブロックの受信、受信データの合成、およびＡＣＫ／ＮＡＣＫシグナリングの生成を含む。以前のトランスポートブロックが復号されている間の継続送信を可能にするため、最大８つのＨＡＲＱ並列プロセスの使用により、マルチプロセス「ストップアンドウェイト」（ＳＡＷ）ＨＡＲＱ動作に対応する。各ＨＡＲＱプロセスは、別個のＳＡＷ動作を担うとともに、別個のバッファを管理する。

ＨＡＲＱプロトコルにより提供されるフィードバックは、応答（ＡＣＫ：Acknowledgement）または否定応答（ＮＡＣＫ：Negative Acknowledgement）である。ＡＣＫおよびＮＡＣＫは、送信が正しく受信され得るか否か（たとえば、復号に成功したか）に応じて生成される。さらに、ＨＡＲＱ動作においては、ＵＥがインクリメンタル冗長（ＩＲ：Incremental redundancy）合成を採用して合成利得により別の符号化利得を得られるように、再送信において、元のトランスポートブロックからの異なる符号化バージョンをｅＮＢが送信可能である。

ＦＥＣ符号化パケットが送信され、受信機がパケットを正しく復号できない場合（誤りは通例、ＣＲＣ（巡回冗長検査）によって検査される）、受信機は、パケットの再送信を要求する。一般的に（かつ本明細書全体を通して）、追加の情報の送信は、「（パケットの）再送信」と称し、この再送信は、同じ符号化情報の送信を意味し得るものの、必ずしもそれを意味しない。また、たとえば異なる冗長バージョンの使用により、パケットに属する任意の情報（たとえば、追加の冗長情報）の送信も意味し得る。

一般的に、ＨＡＲＱ方式は、同期または非同期として分類可能であり、各場合の再送信は適応的または非適応的である。同期ＨＡＲＱは、各ＨＡＲＱプロセスのトランスポートブロックの再送信が初期送信に対する所定の（周期的）時間に発生することを意味する。このため、送信タイミングから推論可能であることにより、再送信スケジュールまたはたとえばＨＡＲＱプロセス番号を受信機に示すのに、明示的なシグナリングは必要ない。

これに対して、非同期ＨＡＲＱによれば、初期送信に対する任意の時間に再送信が起こり得る。これは、エアインターフェース条件に基づいて再送信をスケジューリングする柔軟性を与える。ただし、この場合は、正しい合成およびプロトコル動作を可能にするため、たとえばＨＡＲＱプロセスを受信機に示すには、別の明示的なシグナリングが必要となる。３ＧＰＰ ＬＴＥシステムにおいては、８つのプロセスを伴うＨＡＲＱ動作が用いられる。

ＬＴＥにおいては、ダウンリンクに非同期適応ＨＡＲＱが用いられ、アップリンクに同期ＨＡＲＱが用いられる。アップリンクにおいて、再送信は、たとえばアップリンクグラントにおいて送信属性の新たなシグナリングが与えられているかに応じて、適応的であってもよいし、非適応的であってもよい。

アップリンクＨＡＲＱプロトコル動作（すなわち、アップリンクデータ送信の応答）においては、再送信のスケジューリング方法に関して２つの異なる選択肢が存在する。再送信は、ＮＡＣＫによる「スケジューリング」（同期非適応再送信とも称する）またはＰＤＣＣＨの送信によるネットワークによる明示的なスケジューリング（同期適応再送信とも称する）が行われる。

同期非適応再送信の場合、この再送信では、以前のアップリンク送信と同じパラメータを使用することになる。すなわち、この再送信は、それぞれ同じ変調方式／トランスポートフォーマットを使用する同じ物理チャネルリソース上で伝達されることになる。ただし、冗長バージョンは、０、２、３、１という所定の冗長バージョンのシーケンスで変化すなわち循環することになる。

同期適応再送信がＰＤＣＣＨによって明示的にスケジューリングされることから、ｅＮｏｄｅＢは、再送信の特定のパラメータを変更することができる。アップリンクにおける分断を回避するため、たとえば異なる周波数リソース上で再送信をスケジューリングすることも可能であるし、ｅＮｏｄｅＢが変調方式を変更するか、あるいは、再送信に使用する冗長バージョンをユーザ機器に示すことも可能である。ＵＬ ＨＡＲＱ ＦＤＤ動作の場合、ＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）およびＰＤＣＣＨシグナリングは、同じタイミングで発生することに留意されたい。したがって、ユーザ機器は、同期非適応再送信がトリガされているか（すなわち、ＮＡＣＫのみが受信されているか）またはｅＮｏｄｅＢが同期適応再送信を要求しているか（すなわち、ＰＤＣＣＨも伝達されているか）を１回だけ確認すればよい。

ＰＨＩＣＨは、ｅＮｏｄｅＢがＰＵＳＣＨ上の送信を正しく受信したかを示すＨＡＲＱフィードバックを搬送する。ＨＡＲＱインジケータは、肯定応答（ＡＣＫ）の場合に０、否定応答（ＮＡＣＫ）の場合に１が設定される。アップリンクデータ送信用のＡＣＫ／ＮＡＣＫメッセージを搬送するＰＨＩＣＨは、同じユーザ端末に対して、物理ダウンリンク制御チャネルＰＤＣＣＨと同時に送信されるようになっていてもよい。このような同時送信により、ユーザ端末は、ＰＤＣＣＨによる端末への指示すなわちＰＨＩＣＨの内容に関わらず、新たな送信（ＮＤＩを切り替える新たなＵＬグラント）または再送信（適応再送信と称する）（ＮＤＩを切り替えない新たなＵＬグラント）を実行する旨の指示を決定することができる。端末のＰＤＣＣＨが検出されない場合、ＰＨＩＣＨの内容は、端末のＵＬ ＨＡＲＱ挙動を決定するが、これは以下のようにまとめられる。

ＮＡＣＫ：端末は、非適応再送信すなわち同じＨＡＲＱプロセスで以前に使用されたものと同じアップリンクリソース上での再送信を実行する。

ＡＣＫ：端末は、アップリンク再送信を一切実行せず、当該ＨＡＲＱプロセスの間、データをＨＡＲＱバッファに維持する。当該ＨＡＲＱプロセスに関する別途送信は、ＰＤＣＣＨによって、後続のグラントによる明示的なスケジューリングが必要となる。このようなグラントの受信まで、端末は、「中断状態」となる。

これを以下の表１に示す。

ＬＴＥにおけるアップリンクＨＡＲＱプロトコルのスケジュールタイミングを図３に例示する。ｅＮＢがＰＤＣＣＨ上で第１のアップリンクグラント３０１をＵＥに送信し、これに応答して、ＵＥがＰＵＳＣＨ上で第１のデータ３０２をｅＮＢに送信する。ＰＤＣＣＨアップリンクグラントとＰＵＳＣＨ送信との間のタイミングは、現在のところ４ｍｓに固定されている。ＵＥからの第１のデータ送信３０２を受信したのち、ｅＮＢは、受信した送信のフィードバック情報（ＡＣＫ／ＮＡＣＫ）および、例えば、ＵＬグラント３０３をＵＥに送信する（あるいは、ＵＬ送信に成功した場合、ｅＮＢは、適当な第２のアップリンクグランドの送信によって、新たなアップリンク送信をトリガしている可能性もある）。ＰＵＳＣＨ送信とフィードバック情報を搬送する対応するＰＨＩＣＨとの間の時間についても、現在のところ４ｍｓに固定されている。その結果、アップリンクＨＡＲＱプロトコルにおける次の（再）送信機会を示すラウンドトリップタイム（ＲＴＴ：Round Trip Time）は、８ｍｓである。この８ｍｓの後、ＵＥは、ｅＮＢが指示する以前のデータの再送信３０４を送信するようにしてもよい。この別途動作に対して、別の再送信（たとえば、フィードバックとしてのＮＡＣＫ３０５の送信）の実行をｅＮｏｄｅＢがＵＥに指示するように、以前に送信されたデータパケットの再送信３０４が再び成功しなかったものと仮定する。これに応答して、ＵＥは、別途再送信３０６を実行することになる。

図３の上部には、サブフレームのナンバリングのほか、ＨＡＲＱプロセスのサブフレームとの例示的な関連付けを示している。ここから明らかなように、８つの利用可能なＨＡＲＱプロセスがそれぞれ、各サブフレームと循環的に関連付けられている。図３の例示的なシナリオにおいては、初期送信３０２ならびにその対応する再送信３０４および３０６が同じＨＡＲＱプロセス番号５により処理されるものと仮定する。

ＵＥで測定を実行する測定ギャップは、ＨＡＲＱ再送信よりも優先度が高い。このため、ＨＡＲＱ再送信が測定ギャップと衝突した場合はいつでも、ＨＡＲＱ再送信が起こらない。一方、ＰＨＩＣＨ上のＨＡＲＱフィードバック送信が測定ギャップと衝突した場合はいつでも、ＵＥがＡＣＫを予想されるＨＡＲＱフィードバックの内容と仮定する。

ダウンリンク制御情報には、ＨＡＲＱ動作を補助する複数のフィールドが存在する。

・新規データインジケータ（ＮＤＩ：New Data Indicator）：トランスポートブロックの送信がスケジューリングされるたびに切り替えられる（すなわち、初期送信とも称する）（「切り替え」は、このＨＡＲＱプロセスの以前の送信中の値に対して、関連するＨＡＲＱ情報中に与えられたＮＤＩビットの変更／切り替えが行われたことを意味する）。
・冗長バージョン（ＲＶ）：送信または再送信用に選択されたＲＶを示す。
・ＭＣＳ：変調・符号化方式

ＨＡＲＱ動作は複雑であり、本明細書では完全には説明しない／できない上、本発明を完全に理解するのに必要でもない。ＨＡＲＱ動作の関連部分は、たとえば３ＧＰＰ ＴＳ ３６．３２１（現行版１３．０．０）の第５．４．２項「ＨＡＲＱ ｏｐｅｒａｔｉｏｎ」に記載されており、これを本明細書に援用するとともに、その一部を以下に引用する。

「５．４．２ ＨＡＲＱ動作
５．４．２．１ ＨＡＲＱエンティティ
ＭＡＣエンティティでは、アップリンクが設定されたサービングセルごとに１つのＨＡＲＱエンティティが存在し、以前の送信の受信成功または不成功に関するＨＡＲＱフィードバックを待ちながら、送信が継続的に起こり得るようにする多くの並列ＨＡＲＱプロセスを維持する。
ＨＡＲＱエンティティ当たりの並列ＨＡＲＱプロセスの数については、第８項［２］に指定されている。
物理レイヤがアップリンク空間多重用に設定されている場合［２］、所与のＴＴＩとは、２つのＨＡＲＱプロセスが関連付けられている。それ以外の場合は、所与のＴＴＩと１つのＨＡＲＱプロセスが関連付けられている。
所与のＴＴＩにおいて、当該ＴＴＩにアップリンクグラントが示されている場合、ＨＡＲＱエンティティは、送信を行うべきＨＡＲＱプロセスを識別する。また、物理レイヤにより中継された受信ＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ情報）、ＭＣＳ、およびリソースを適当なＨＡＲＱプロセスへとルーティングする。
ＴＴＩバンドルが設定されている場合は、パラメータＴＴＩ＿ＢＵＮＤＬＥ＿ＳＩＺＥがＴＴＩバンドルのＴＴＩの数を与える。ＴＴＩバンドル動作は、同じバンドルの一部である各送信に対して同じＨＡＲＱプロセスを呼び出すＨＡＲＱエンティティに依拠する。バンドル内では、ＨＡＲＱ再送信が非適応的であり、ＴＴＩ＿ＢＵＮＤＬＥ＿ＳＩＺＥに従って、以前の送信からのフィードバックを待たずにトリガされる。バンドルのＨＡＲＱフィードバックは、（たとえば、測定ギャップが生じた場合に）バンドルの最後のＴＴＩ（すなわち、ＴＴＩ＿ＢＵＮＤＬＥ＿ＳＩＺＥに対応するＴＴＩ）における送信が起こるか否かに関わらず、当該ＴＴＩにおいてのみ受信される。ＴＴＩバンドルの再送信もまたＴＴＩバンドルである。ＴＴＩバンドルは、アップリンクが設定された１つまたは複数のＳＣｅｌｌがＭＡＣエンティティに設定されている場合は非対応である。
ＴＴＩバンドルは、Ｅ−ＵＴＲＡＮがＲＮサブフレーム設定と組み合わされたＲＮ通信では非対応である。
ランダムアクセス時のＭｓｇ３の送信（第５．１．５項参照）には、ＴＴＩバンドルは当てはまらない。
各ＴＴＩについて、ＨＡＲＱエンティティは、
このＴＴＩと関連付けられたＨＡＲＱプロセスを識別し、各識別ＨＡＲＱプロセスについて、
このプロセスおよびこのＴＴＩに関してアップリンクグラントが示された場合、
受信グラントがＰＤＣＣＨ上で仮Ｃ−ＲＮＴＩにアドレス指定されておらず、このＨＡＲＱプロセスの以前の送信中の値に対して、関連するＨＡＲＱ情報中に与えられたＮＤＩの切り替えが行われた場合、または
Ｃ−ＲＮＴＩに関してＰＤＣＣＨ上でアップリンクグラントが受信されており、識別プロセスのＨＡＲＱバッファが空である場合、または
ランダムアクセス応答においてアップリンクグラントが受信された場合、
Ｍｓｇ３バッファにＭＡＣ ＰＤＵが存在し、ランダムアクセス応答においてアップリンクグラントが受信された場合、
Ｍｓｇ３バッファから送信するＭＡＣ ＰＤＵを取得する。
上記以外の場合は、
「多重化・組み立て」エンティティから送信するＭＡＣ ＰＤＵを取得する。
ＭＡＣ ＰＤＵ、アップリンクグラント、およびＨＡＲＱ情報を識別ＨＡＲＱプロセスに配送する。
新たな送信のトリガを識別ＨＡＲＱプロセスに指示する。
上記以外の場合は、
アップリンクグラントおよびＨＡＲＱ情報（冗長バージョン）を識別ＨＡＲＱプロセスに配送する。
適応再送信の生成を識別ＨＡＲＱプロセスに指示する。
上記以外の場合で、このＨＡＲＱプロセスのＨＡＲＱバッファが空ではない場合、
非適応再送信の生成を識別ＨＡＲＱプロセスに指示する。
以前の送信の値に対してＮＤＩが切り替えられたかを判定する場合、ＭＡＣエンティティは、その仮Ｃ−ＲＮＴＩに関して、ＰＤＣＣＨ上ですべてのアップリンクグラントにおいて受信されたＮＤＩを無視するものとする。」

［ＮＢ−ＩｏＴ／ｅＭＴＣのアップリンクＨＡＲＱプロトコル］
ＮＢ−ＩｏＴおよびｅＭＴＣ（Ｒｅｌ．１３）については、非同期ＵＬ ＨＡＲＱプロトコルが導入されている（また、アンライセンスキャリア上のアップリンクに関する進行中のＲｅｌ．１４作業項目のために議論されている）。旧来のＬＴＥに用いられる同期アップリンクＨＡＲＱプロトコルと異なり、ＮＢ−ＩｏＴまたはｅＭＴＣ ＵＥに対する再送信は、適応的かつ非同期である。より詳細に、再送信は、同じプロセスの以前のＨＡＲＱ送信に対して固定タイミングで起こる必要がなく、再送信を明示的にスケジューリングする柔軟性を与える。さらに、明示的なＨＡＲＱフィードバックチャネル（ＰＨＩＣＨ）は存在しないことになる。すなわち、再送信／初期送信は、ＰＤＣＣＨによって指示される（初期送信と再送信とでＮＤＩが区別される）。本質的に、ＮＢ−ＩｏＴまたはｅＭＴＣ ＵＥに対するアップリンクＨＡＲＱプロトコル挙動は、Ｒｅｌ−８以降のダウンリンクに用いられる非同期ＨＡＲＱプロトコルと酷似することになる。

ＮＢ−ＩｏＴの場合は、ＵＬ ＨＡＲＱプロセスが１つだけ存在することに留意されたい。

ＮＢ−ＩｏＴ／ｅＭＴＣ ＵＥに導入される非同期アップリンクＨＡＲＱプロトコルの詳細については、３ＧＰＰ ＴＳ ３６．３２１（Ｖ１３．１．０）（２０１６−０３）の第５．４．２項を参照するものとし、これを本明細書に援用する。

［短レイテンシ（Short Latency）検討事項（Study Item）］
パケットデータレイテンシは、ベンダー、事業者ひいてはエンドユーザが（速度テストアプリケーションにより）定期的に測定する性能測定基準の１つである。レイテンシ測定は、新たなソフトウェアリリースまたはシステムコンポーネントを確認する場合、システムを展開する場合、およびシステムを商用運用する場合、無線アクセスネットワークシステムの耐用期間のすべての段階で行われる。

３ＧＰＰ ＲＡＴの以前世代よりも優れたレイテンシは、ＬＴＥの設計を誘導する１つの性能測定基準であった。ＬＴＥは現在、エンドユーザによって、移動無線技術の以前世代よりも高速なインターネットアクセスおよび低いデータレイテンシを提供するシステムとしても認識されている。

３ＧＰＰコミュニティにおいては、ＬＴＥの最初のリリース（Ｒｅｌ．８）から最新のリリース（Ｒｅｌ．１２）まで、データレートの向上に多大な努力が払われてきた。キャリアアグリゲーション（ＣＡ：Carrier Aggregation）、８×８ＭＩＭＯ、２５６ＱＡＭ等の特徴が、Ｌ１データレートの技術的潜在力を３００Ｍｂｐｓから４Ｇｂｐｓまで高めてきた。Ｒｅｌ．１３においては、ＣＡに最大３２個のコンポーネントキャリアを導入することによって、さらに高いビットレートを導入することを３ＧＰＰは目標にしている。

ただし、具体的にシステムの遅延を対象とした別途改善に関しては、ほとんど何もなされていない。パケットデータレイテンシは、システムの認識される応答性に対してのみ重要なわけではなく、スループットに間接的な影響を及ぼすパラメータでもある。ＨＴＴＰ／ＴＣＰは今日、インターネット上で用いられる優位なアプリケーションおよびトランスポートレイヤプロトコルの組である。ＨＴＴＰ Ａｒｃｈｉｖｅ（ｈｔｔｐ：／／ｈｔｔｐａｒｃｈｉｖｅ．ｏｒｇ／ｔｒｅｎｄｓ．ｐｈｐ）によれば、インターネット上のＨＴＴＰベースのトランザクションの典型的なサイズは、数十Ｋｂｙｔｅ〜１Ｍｂｙｔｅの範囲である。このサイズ範囲において、ＴＣＰスロースタート期間は、パケットストリームの全伝送期間の大部分である。ＴＣＰスロースタート時は、性能がレイテンシの制約を受ける。このため、この種のＴＣＰベースのデータトランザクションについては、平均スループットを向上させるためのレイテンシの改善をかなり容易に示すことができる。また、実際に高いビットレート（Ｒｅｌ．１３ ＣＡではＧｂｐｓの範囲）を実現するには、それに応じてＵＥバッファをサイズ規定する必要がある。ＲＴＴが長いほど、大きなバッファが必要となる。ＵＥおよびｅＮＢ側でのバッファリング要件を抑える唯一の方法は、レイテンシの低減である。

レイテンシの低減は、無線リソースの効率にも好影響を及ぼし得る。パケットデータレイテンシが低いと、一定の遅延範囲内で可能な送信試行数が増えるため、データ送信により高いＢＬＥＲターゲットを使用することも可能となり、無線リソースの制限がなくなる一方、不十分な無線状態のユーザにも同レベルのロバスト性を保ち続ける。一定の遅延範囲内に可能な送信の数が増えると、同じＢＬＥＲターゲットを維持する場合は、実時間データストリーム（たとえば、ＶｏＬＴＥ）のよりロバストな送信も可能となる。これにより、ＶｏＬＴＥボイスシステムの容量が増大することになる。

多くの既存の用途では、認識される経験品質の向上に関して低レイテンシの好影響を受けるその他多くが存在する。一例として、ゲーム、ＶｏＬＴＥ／ＯＴＴ ＶｏＩＰのような実時間アプリケーション、およびテレビ電話／会議が挙げられる。

将来的には、遅延がますます重要となる多くの新たなアプリケーションが存在することになる。一例として、車両の遠隔制御／運転、たとえばスマートグラスにおける拡張現実用途、または低レイテンシおよびクリティカル通信を要する特定の機械通信が挙げられる。

レイテンシをある程度まで低下させるには、さまざまなプレスケジューリング方法を使用可能であるが、Ｒｅｌ．９において導入された低スケジューリング要求（ＳＲ）間隔と同様に、効率に関するすべての側面に必ずしも対応しているわけではない。

また、ユーザプレーンデータのレイテンシが低減されると、制御シグナリングの伝送が速くなるため、コールセットアップ／ベアラセットアップ時間も間接的に短くなる可能性があることにも留意されたい。

したがって、ＬＴＥの進化および競争性を確保するには、パケットデータレイテンシの検討および改善が必要と考えられる。

この検討事項の目的は、Ｅ−ＵＴＲＡＮ無線システムの強化を検討して、
・有効なＵＥのＬＴＥ−Ｕｕエアインターフェース上のパケットデータレイテンシを大幅に低減するとともに、
・（接続状態で）長期間にわたって無効であったＵＥのパケットデータトランスポートラウンドトリップレイテンシを大幅に低減する、
ことである。

検討範囲には、エアインターフェース容量、バッテリ寿命、制御チャネルリソース、仕様影響、および技術的実現可能性といったリソース効率を含む。ＦＤＤおよびＴＤＤの両二重モードが考えられる。

第１の側面として、通常の用途および使用事例におけるレイテンシの改善による応答時間の短縮およびＴＣＰスループットの向上といった潜在的利益が特定され文書化される。結論として、この検討の側面は、レイテンシの低減が望ましい旨を示すことになる。

第２の側面として、以下の領域を検討して文書化するものとする。

・高速アップリンクアクセスソリューション
有効なＵＥおよび長時間にわたって無効であったもののＲＲＣ接続が維持されているＵＥに関し、現行のＴＴＩ長および処理時間を保つ場合および保たない場合の両者について、現規格が可能とするプレスケジューリングソリューションとの比較により、スケジューリングされたＵＬ送信のユーザプレーンレイテンシを低減するとともに、プロトコルおよびシグナリングが強化されたリソース効率の高いソリューションを得ることに焦点を当てるものとする。
・ＴＴＩの短縮および処理時間の短縮
基準信号および物理レイヤ制御シグナリングへの影響を考慮に入れて、０．５ｍｓとＯＦＤＭシンボルとの間のＴＴＩ長の仕様影響、検討実現可能性、および性能を評価する。
下位互換性は保たれるものとする（これにより、同じキャリア上でＲｅｌ．１３以前のＵＥの正常動作が可能となる）。

［アップリンク用の処理チェーン機能］
図４に示す処理チェーンについては、３ＧＰＰ ＴＳ ３６．２１２（Ｖ１３．１．０）（２０１６−０３）の第５．２．２項を参照するものとし、これを本明細書に援用する。

図４は、シングルコードワード／トランスポートブロックの物理レイヤ内の符号化チェーン機能を含むブロック図である。入力は、ＭＡＣレイヤにより継承されたトランスポートブロックからなる。トランスポートブロックの再送信のため、冗長バージョン（ＲＶ）は、「レートマッチングブロック」内の入力パラメータである。その結果、再送信に異なるＲＶを使用する場合は、少なくともブロック「レートマッチング」、「コードブロック連結」、「データ・制御多重化」、および「チャネルインターリーバ」を処理する必要がある。

ブロック「チャネルインターリーバ」の出力は、図５に示す物理チャネル処理ステップへの「コードワード」入力として機能するが、これについては、３ＧＰＰ ＴＳ ３６．２１１（Ｖ１３．１．０）（２０１６−０３）の第５．３項を参照するものとし、これを本明細書に援用する。

図５は、物理レイヤ内の物理チャネル処理機能を含むブロック図である。入力は、［３６．２１２］図５．２．２−１に示される符号化チェーンの結果として得られるコードワードからなる。通常（非ＭＴＣまたはＮＢ−ＩｏＴ）の処理の場合、「スクランブル」ブロックは、その入力パラメータの中に、無線フレーム内の送信サブフレーム指標を有する。したがって、コードワード入力が同一であったとしても、サブフレーム指標が異なれば「スクランブル」ブロックの出力も異なる。トランスポートブロックの再送信のため、冗長バージョン（ＲＶ）は、「レートマッチングブロック」内の入力パラメータである。その結果、再送信に異なるＲＶを使用する場合は、少なくともブロック「レートマッチング」、「コードブロック連結」、「データ・制御多重化」、および「チャネルインターリーバ」を処理する必要がある。

非限定的かつ例示的な実施形態は、ユーザ機器のアップリンクデータパケット送信の改良された送信プロトコル動作を提供する。

独立請求項は、非限定的かつ例示的な実施形態を提供する。有利な実施形態は、従属請求項が対応する。

本明細書に記載の複数の態様によれば、送信プロトコル動作が改良されるものとする。

一般的な一態様によれば、通信システムにおけるアップリンクデータパケット送信の送信プロトコルを動作させるユーザ機器であって、高速再送信インジケータを受信する受信機を備えた、ユーザ機器が記載される。このため、高速再送信インジケータは、以前に送信されたデータパケットの再送信を基地局が要求しているか否かを示す。ユーザ機器は、データパケットの以前の送信にすでに使用されたものと同じ冗長バージョンを用いてデータパケットを再送信する送信機を備える。

一般的な別の態様によれば、通信システムにおけるアップリンクデータパケット送信の送信プロトコルを動作させる基地局であって、高速再送信インジケータを送信する送信機を備えた、基地局が記載される。このため、高速再送信インジケータは、以前に送信されたデータパケットの再送信を基地局が要求しているか否かをユーザ機器に示す。基地局は、ユーザ機器によりデータパケットの以前の送信にすでに使用されたものと同じ冗長バージョンの再送信データパケットをユーザ機器から受信する受信機を備える。

上記に対応して、一般的な別の態様において、本明細書に開示の技術は、通信システムにおけるアップリンクデータパケット送信の送信プロトコルをユーザ機器において動作させる方法を特徴とする。この方法は、ＦＲＩと称する高速再送信インジケータを受信するステップであり、ＦＲＩが、以前に送信されたデータパケットの再送信を基地局が要求しているか否かを示す、高速再送信インジケータを受信するステップを含む。この方法は、データパケットの以前の送信にすでに使用されたものと同じ冗長バージョンを用いてデータパケットを再送信するステップをさらに含む。

上記に対応して、一般的な別の態様において、本明細書に開示の技術は、通信システムにおけるアップリンクデータパケット送信の送信プロトコルを基地局において動作させる方法を特徴とする。この方法は、ＦＲＩと称する高速再送信インジケータを送信するステップであり、ＦＲＩが、以前に送信されたデータパケットの再送信が要求されているか否かをユーザ機器に示す、高速再送信インジケータを送信するステップを含む。この方法は、ユーザ機器によりデータパケットの以前の送信にすでに使用されたものと同じ冗長バージョンの再送信データパケットをユーザ機器から受信するステップをさらに含む。

開示の実施形態の別の利益および利点については、本明細書および図面から明らかとなるであろう。これらの利益および／または利点は、開示の明細書および図面の種々実施形態および特徴により個々にもたらされるようになっていてもよいが、すべてがもたらされる必要はなく、そのうちの１つまたは複数が得られるようになっていてもよい。

これらの一般的かつ具体的な態様は、システム、方法、およびコンピュータプログラム、ならびにシステム、方法、およびコンピュータプログラムの任意の組み合わせを用いて実現されていてもよい。

以下、添付の図面を参照して、例示的な実施形態をより詳しく説明する。

３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示した図である。 ３ＧＰＰ ＬＴＥ（Ｒｅｌ．８／９）用に規定されたサブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドを示した図である。 アップリンク送信およびその再送信の場合のＵＥとｅＮｏｄｅＢとの間の送信プロトコル動作を例示的に示した図である。 シングルコードワード／トランスポートブロックの物理レイヤ内の符号化チェーン機能を含む模式的なブロック図である。 物理レイヤ内の物理チャネル処理機能を含む模式的なブロック図である。 本実施形態に係る、送信要求および対応する送信のタイミングチャートである。 本実施形態に係る、同時に要求された再送信が衝突した場合の送信要求および対応する送信のタイミングチャートである。

図３および「背景」項におけるその説明から分かるように、現在のところ、ＰＤＣＣＨ／ＰＨＩＣＨと対応するＰＵＳＣＨアップリンク送信との間には４ｍｓの遅延が存在する。この遅延は主として、ＰＤＣＣＨ／ＰＨＩＣＨの検出のほか、上に概説した符号化チェーンおよび物理チャネル処理ステップを含むＵＥ側で必要な処理に起因してもたらされる。この４ｍｓのレイテンシは、上述の「短レイテンシ」検討事項の範囲内で論じている通り、ＴＴＩの短縮によっても低減可能であるが、主要な時間の節約は、トランスポートブロックサイズの縮小および高速処理を可能にするハードウェア／ソフトウェア設計の潜在的な改善による。それでもなお、このような節約は依然として、再送信の場合であっても、同じトランスポートブロック（データパケット）の以前の送信と比較して、特に異なるＲＶが再送信に用いられる場合、上に概説した通り、送信チェーンのすべての機能ブロックを処理する必要性の制約を受ける。

現時点で４ｍｓという長さの別の遅延には、ＰＵＳＣＨ送信と同じＨＡＲＱプロセスについてのＰＤＣＣＨ／ＰＨＩＣＨによる次の潜在的トリガとの間のギャップがある。このギャップは、ｅＮＢがＰＵＳＣＨを処理してその復号を試行するとともに、復号の試行に失敗した場合は、適正なスケジューリングおよびリンクアダプテーション手順を再び決定して、他のユーザのアップリンク送信の必要性も考慮に入れる必要がある再送信用の適当な一組の物理レイヤ送信パラメータ（ＭＣＳ、ＲＢの数と位置、ＲＶ、送信電力を含む）を決定するのに必要なため生じる。最終的に、これらのパラメータが決まったら、（適応再送信の場合の）（Ｅ）ＰＤＣＣＨ上のＤＣＩおよび／または（非適応再送信の場合の）ＰＨＩＣＨ上のＨＩによりＵＥまで運ばれる必要がある。

特に異なるＲＶバージョンおよびサブフレームに依存したスクランブルのため、非適応再送信をトリガするコンパクトな方法としてＰＨＩＣＨを見なすことも可能であるが、ＵＥは依然として、送信可能となる前にかなり多くのステップを実行する必要がある。

本発明の目的は、ＵＥからのＰＵＳＣＨ上の送信とｅＮｏｄｅＢによる対応する再送信指示との間の遅延を抑えることである。また、別の目的は、ｅＮｏｄｅＢによる再送信の指示とＵＥからのＰＵＳＣＨ上の対応する再送信との間の遅延を抑えることである。

本発明者らによれば、上記説明の問題のうちの１つまたは複数を緩和するのに、以下の例示的な実施形態が考えられる。

本実施形態の複数の変形例の特定の実施態様は、３ＧＰＰ規格が示す広範な仕様において実現されることになり、「背景」項においても一部を説明しているが、特定の主要な特徴については、記載の実施形態に関する以下の説明において追加する。本実施形態は、たとえば上記「背景技術」項において説明した３ＧＰＰ ＬＴＥ−Ａ（Ｒｅｌ．１０／１１／１２／１３）通信システム等の移動通信システムにおいて使用可能であるのが好都合であるものの、この特定の例示的な通信ネットワークにおける使用には限定されないことに留意されたい。

以下の説明は、本開示の範囲を制限するものではなく、本開示をより深く理解するための実施形態の一例に過ぎないと理解されるべきである。当業者であれば、本明細書において明示的に記載されていない方法で、特許請求の範囲に記載の本開示の一般原理がさまざまなシナリオに適用可能であることを認識するはずである。説明の便宜上、複数の仮定を行っているが、これらは以下の実施形態の範囲を制限しないものとする。

以下、前述の問題を解決する一実施形態について詳しく説明する。本実施形態の異なる実施態様および変形例についても同様に説明する。

本実施形態は、通信システムにおけるアップリンクデータパケット送信の送信プロトコルを動作させるユーザ機器（ＵＥ）を提供する。この送信プロトコルによれば、ｅＮｏｄｅＢにおいてＰＵＳＣＨの復号の試行に失敗した場合、ＵＥで短時間に高速な再送信をトリガするのに高速再送信インジケータ（ＦＲＩ：Fast Retransmission Indicator）が用いられる。このＦＲＩを採用した場合は、ＤＣＩ／ＨＩを使用した場合よりも早く、ｅＮｏｄｅＢによって再送信要求を送信することができる。

ＵＥがＤＣＩへの応答よりも高速にデータパケットを再送信するため、ＵＥは、本実施形態の一変形例によれば、ＨＩによる非適応再送信のトリガのように同じ無線リソースを使用するのみならず、ＤＣＩまたはＨＩによりトリガされた最新の送信データパケットに適用可能であった他の同一のパラメータをデータパケットの再送信に使用するようにしてもよい。

同様に、本実施形態は、アップリンクデータパケット送信の送信プロトコルを動作させる基地局であって、ＦＲＩのＵＥへの送信によって、以前に送信されたデータパケットの再送信が要求されているか否かを示す、基地局を提供する。このような要求に対して、基地局は、データパケットの以前の送信にすでに使用されたものと同じ冗長バージョンの再送信データパケットをＵＥから受信する。

全般的な考察として、たとえば緊急を要するサービス品質（Quality-of-Service）要件のため、ｅＮｏｄｅＢがデータパケットの高速再送信をトリガしようとする場合は、無線チャネル容量の非最適使用を可能な限り犠牲にして、極力高速に再送信を行うことがより重要となる。このようなデータパケットの高速再送信を実現する主要な一態様として、ｅＮｏｄｅＢは、データパケットの以前の送信に対してすべてのパラメータがすでに決定されていることから、リンクアダプテーション評価を完全に行う必要がない。

「背景」項で説明済みではあるが、再送信にＨＩを使用する場合であっても、再送信データブロックに対して冗長バージョンが変化することになる。この場合、冗長バージョンは、たとえば０、２、３、１という所定の冗長バージョンのシーケンスで循環する。図４に示すように、再送信に対して具体的に選択された冗長バージョンは、「レートマッチング」ブロックの入力値である。このため、異なる冗長バージョン（ＲＶ）を使用する再送信データブロックごとに、少なくともブロック「レートマッチング」、「コードブロック連結」、「データ・制御多重化」、および「チャネルインターリーバ」を再び処理する必要がある。また、「チャネルインターリーバ」ブロックの出力は、図５に示す物理チャネル処理全体に入力される。

データパケットの再送信の送信に要する時間の大幅な短縮を実現するため、本実施形態の一実施態様において、ＵＥは、データパケットの以前の送信にすでに使用されたものと同じ冗長バージョンをデータパケットの再送信に使用する。ＵＥがそのデータパケットの再送信に、以前のＤＣＩトリガ送信と同一の送信パラメータのサブセットすなわち以前に送信されたデータパケットと同じ冗長バージョンを使用するため、データパケットの冗長バージョンの変更に伴うすべての処理ステップを省略可能である。

すなわち、データパケットの以前のＤＣＩ（または、ＨＩ）トリガ送信と同じＲＶを使用するだけの場合であっても、スクランブル（図５に示す）の開始まで、新たな「レートマッチング」および後続ブロック（図４に示す）を処理する必要がない。言い換えると、最も新しく送信されたコードワードをＵＥがバッファリングしている場合、高速再送信にはこれで十分であり、図５に示すように、これらバッファリングされたコードワードを物理チャネル処理手順に供給する。

図６には、送信要求および対応する送信のタイミングチャートを示している。この図から分かるように、ｅＮｏｄｅＢによるＤＣＩの送信とＵＥによるデータパケットの対応する送信との間の期間は、期間ｔ０として示されており、この期間ｔ０は、「第３のタイミング」という名称であってもよい。ＬＴＥリリース８から採用されているアップリンクＨＡＲＱプロトコルの場合、期間ｔ０は、図３に示すように４ｍｓの期間に対応しており、ＤＣＩによるアップリンクデータ送信のトリガに関する従来の場合を示している。図６から分かるように、図３との対照として、ＵＥによるデータパケットの送信（ＰＵＳＣＨ）とｅＮｏｄｅＢによるＦＲＩの送信との間の期間ｔ１（図６にも示す）は、ｔ０以下であってもよい。一方、本実施形態の好適な変形例においては、ｔ１が期間ｔ０よりも短い。将来のさらなる発展により、期間ｔ０が４ｍｓ未満となる可能性もあるが、本発明の範囲を制限するものではなく、本実施形態の記述では、特に明記しない限り、期間ｔ０が４ｍｓであるものと仮定する。

したがって、本実施形態の別の変形例として、「第１のタイミング」という名称も可能な期間ｔ１は、固定期間または基地局により準静的に設定可能な期間であって、４ｍｓ未満であるのが好ましい。

ＦＲＩは一般的に、少なくとも２つの状態を示し得ることに留意する。「状態１」によれば、ＦＲＩは、「肯定ＦＲＩ」であり、高速再送信をトリガする一方、この場合は、受信データパケットの否定応答と見なされる可能性もある。「状態２」によれば、ＦＲＩは、「否定ＦＲＩ」であり、高速再送信をトリガしない。この場合は、受信データパケットの肯定応答と見なされる可能性もあるからである。したがって、状態の機能的に等価な解釈としては、「肯定ＦＲＩ」が「否定応答（ＮＡＣＫ）」を搬送するＦＲＩと等価であり、「否定ＦＲＩ」が「応答（ＡＣＫ）」を搬送するＦＲＩと等価である。本実施形態の範囲を限定しない簡素化のため、以降の記述では、専門用語「肯定ＦＲＩ」および「否定ＦＲＩ」のみを使用する。

図６からさらに導き出されることとして、ｅＮｏｄｅＢにより送信された肯定ＦＲＩとＵＥにより送信された対応するＰＵＳＣＨ送信との間の時間として規定される期間ｔ２は、ＤＣＩ（または、ＨＩ）とそれに対応するＰＵＳＣＨ送信との間の期間である期間ｔ０よりも短くなければならない。期間ｔ０と比較して期間ｔ２が短くなるのは、上述した以前のＤＣＩ／ＨＩトリガ送信と同一の送信パラメータのサブセットをデータパケットの再送信に使用することで、ＵＥでの計算時間が節約された結果である。図６には、同一の冗長バージョンの使用を示している。たとえば、冗長バージョンＲＶ＃０を使用することにより、ＤＣＩにより開始されたＰＵＳＣＨ送信およびＦＲＩにより開始されたＰＵＳＣＨ送信の両者が実行される。言い換えると、ＲＶ＃０は、ＤＣＩ開始ＰＵＳＣＨ送信により決定され、ＦＲＩ開始ＰＵＳＣＨ送信により再利用されたものである。

したがって、本実施形態の別の変形例として、「第２のタイミング」という名称も可能な期間ｔ２は、固定期間もしくは基地局により準静的に設定可能な期間、または送信／受信ＦＲＩに含まれる各情報に基づく変数である。好ましくは、期間ｔ２は、４ｍｓ未満であってもよい。

本実施形態の別の実施態様によれば、肯定ＦＲＩは、データパケットの以前の送信に使用されたものと同一の追加の送信パラメータで再送信が実行されることを示すが、これら追加の同一の送信パラメータはその後、ＵＥによるデータパケットの再送信および基地局における再送信データパケットの受信に用いられる。

本実施形態の別の実施態様によれば、データパケットの再送信に用いられる追加の同一の送信パラメータは、少なくとも以前に送信されたデータパケットのスクランブルコードである。同じスクランブルコード等の同一の送信パラメータを別途有する利点として、図４に示したような前述のブロック「レートマッチング」から「チャネルインターリーバ」へのスキップのほか、データパケットの再送信に対して、図５に示す「スクランブル」ブロックを処理する必要がない。

本実施形態の別の変形例においては、以前のＤＣＩ開始ＰＵＳＣＨ送信から、プリコーディング情報が利用可能となる時点、すなわち、図５のブロック「プリコーディング」後まで、追加の同一の送信パラメータが再利用されるようになっていてもよい。たとえば、以前のＤＣＩ開始ＰＵＳＣＨ送信から、別途追加の同一の送信パラメータが変調方式およびレイヤマッピングを再利用することにより、以前の送信と同じ送信方式が再送信に用いられるようになっていてもよい。すなわち、同数の送信レイヤおよび同じアンテナポートが用いられるようになっていてもよい。以前の送信と同じプリコーディングベクトルを使用することは、ＦＲＩが異なるプリコーダの使用を示していない場合に最も合理的である。

ただし、以前のＤＣＩ開始ＰＵＳＣＨ送信から図５に示すブロック「プリコーディング」を越えて別途同一の送信パラメータを再利用する場合は、リソースの一部のみが再送信に利用される。たとえば、「リソースエレメントマッパ」ブロックでは、以前の送信に使用されたリソースの一部（たとえば、リソースブロックの５０％等、リソースブロックの一部）のみにデータがマッピングされることになる。これと同等に、高速再送信の場合は、「リソースエレメントマッパ」ブロックの出力の一部のみが「ＳＣ−ＦＤＭＡ信号生成」ブロックへの入力として使用される。したがって、ＵＥが以前の送信の「リソースエレメントマッパ」ブロックの出力をバッファリングし、部分的な再送信のトリガに際しては、バッファから対応する部分のみを読み出して、ＳＣ−ＦＤＭＡ信号生成への入力としてこれらを適用すれば十分である。高速再送信に使用される部分は、ＴＳ ３６．２１３に規定された「リソースブロック」または「リソースブロック群」のような基準時間または周波数リソース単位の非負整数の倍数からなるのが好ましい。これには、一部のリソースブロックまたはリソースブロック群によるリソースの浪費なく、未使用リソースを他のＵＥに最適に割り当て可能となる利点がある。また、当該部分は、リソースブロックＭ^{ＰＵＳＣＨ} _ＲＢに関してＰＵＳＣＨの帯域幅になるものとするが、ここでは、Ｍ^{ＰＵＳＣＨ} _ＲＢ＝２^α２・３^α３・５^α５であるとともに、α_２，α_３，α_５は、一組の非負整数である。したがって、指定された部分が非整数個のリソースブロックもしくはリソースブロック群となる場合または結果としての帯域幅Ｍ^{ＰＵＳＣＨ} _ＲＢが条件２^α２・３^α３・５^α５を満たさない場合、ＵＥは、好ましくは指定部分を超える最も少ない整数個のリソースブロックもしくはリソースブロック群またはＭ^{ＰＵＳＣＨ} _ＲＢ＝２^α２・３^α３・５^α５をそれぞれ満たす指定部分よりも大きな最小整数値Ｍ^{ＰＵＳＣＨ} _ＲＢへの切り上げを行うものとする。

本実施形態の別の変形例においては、追加の同一の送信パラメータとして、データパケットの再送信用の基準信号の生成と同じ「循環シフトパラメータ」が用いられるようになっていてもよい。この点に関しては、３ＧＰＰ技術規格３６．２１１の第５．５．２項を参照する。生成された基準信号に同一の「循環シフトパラメータ」を使用することにより、再送信の全処理時間がさらに短くなる。別の変形例においては、ｅＮｏｄｅＢにより送信されたＦＲＩが「循環シフトパラメータ」に関する情報をさらに含んでいてもよく、ＵＥによって、データパケットの再送信用の基準信号の生成に用いられることになる。

データブロックの最新の送信がＵＬ−ＳＣＨデータからなるのみならず、ＡＣＫ／ＮＡＣＫ、ＣＳＩ等のアップリンク制御情報（ＵＣＩ）を含む可能性もある。図４から分かるように、このような情報は、ブロック「データ・制御多重化」においてデータに追加される。一般的に、このような情報は、データブロックの最新の送信と同様に、ＦＲＩによりトリガされた再送信にも追加されるのが好ましい。ただし、同一のＡＣＫ／ＮＡＣＫまたはＣＳＩ情報を送信することは、必ずしも合理的ではない。以前の送信とトリガ再送信との間の遅延によって、内容が失効し得るためである。したがって、別の実施形態においては、再送信にＵＣＩを含まないが、情報が存在していたようにこれらのリソースを確保する。結果として、データブロックビットの順序は不変にすることができるため、再送信のためにビットを並び替える手順が別途必要になることはない。

同様に、アップリンクサブフレームのリソースの一部、好ましくはサブフレームの末尾には、サウンディング基準シンボル（ＳＲＳ：Sounding Reference Symbol）を含んでいてもよい。このような場合は、以前の送信と同様に、高速再送信がＳＲＳを含んでいてもよい。すなわち、リソースが確保される（たとえば、ミュート）。結果として、ＰＵＳＣＨのリソースエレメントへのマッピングは不変を維持することができるため、再送信のためにＲＥを並び替える手順が別途必要になることはない。

図６および図７を参照して、データパケットの受信に成功しなかった場合は、ＵＥからのデータパケットの再送信がＦＲＩ、ＤＣＩ、またはＨＩのいずれを用いて要求され、ＦＲＩ、ＤＣＩ、またはＨＩのいずれをＵＥに送信するかをｅＮｏｄｅＢが柔軟に判定してもよいことに留意する。同様に、ＵＥは、ＦＲＩ、ＤＣＩ、またはＨＩのいずれかの受信に応じて、上述の通り、受信したＦＲＩ、ＤＣＩ、またはＨＩに基づいてデータパケットの対応する送信／再送信を柔軟に実行するようにしてもよい。

本実施形態の別の実施態様によれば、ＦＲＩは、以前に送信されたデータパケットの一部の再送信が実行されることを示し、任意選択で、一部が以前に送信されたデータパケットの５０％または２５％である。このような場合、ＵＥは、以前に送信されたデータパケットの示された部分を再送信する。ＵＥは、以前に送信されたデータパケットの上記部分の再送信の合計送信電力が以前に送信されたデータパケットの合計送信電力と等しくなるように、再送信に送信電力を適応させるようにしてもよく、任意選択で、データパケットの５０％を使用すると、以前に送信されたデータパケットの上記部分の送信電力が２倍に増加する。

以前の送信の周波数リソースの一部のみが再送信に利用される場合は、ＵＥが部分的な再送信に送信する合計電力も一部となる。ただし、部分的な再送信データの品質を向上させるため、その電力を相互に、周波数リソースの割合まで増加させることができる。たとえば、部分的な再送信に周波数リソースの５０％のみを利用する場合、部分的な再送信の各ＲＥは、２倍に増加可能であり、部分的な再送信の全送信ＲＥと完全再送信との合計送信電力は等しい。このような部分的な再送信は、完全再送信によってトランスポートブロックの復号を成功に導く必要がない場合またはｅＮｏｄｅＢが周波数リソースの一部のみを再送信に使用して、残りの部分を別のＵＥにスケジューリングできるようにしようとする場合、特に魅力的である。

部分的な再送信に利用される周波数リソースの量は、以下に従って決定することができる。
１．準静的な設定：肯定ＦＲＩが高速再送信をトリガした場合はいつでも、ＵＥが設定値を調べ、それに応じて適用する。
２．ＦＲＩ内での指定：ＦＲＩは、部分的なリソースの量を決定するインジケータを搬送可能である。たとえば、第１のＦＲＩ値が５０％の部分的再送信をトリガし、第２のＦＲＩ値が２５％の部分的再送信をトリガし、第３の値が完全再送信（すなわち、１００％）をトリガする一方、第４のＦＲＩ値は高速再送信をトリガしない。したがって、この例では、３つの肯定ＦＲＩ値および１つの否定ＦＲＩ値が存在する。

これらの組み合わせも可能である。たとえば、ｅＮｏｄｅＢが３つの異なる部分的再送信値（場合により１００％を含む）を設定した後、肯定ＦＲＩ値はそれぞれ、対応する準静的な部分的再送信値をそれぞれ指し示す（１つのＦＲＩ値は高速再送信を指示しない（すなわち否定ＦＲＩ値））。

本実施形態の別の実施態様において、ユーザ機器は、データパケットを送信する複数の送信アンテナを備えていてもよい。この場合は、ＵＥが複数の送信アンテナを用いてデータパケットをｅＮｏｄｅＢに再送信するように、受信ＦＲＩがデータパケットの再送信をトリガする。すなわち、ＳＵ−ＭＩＭＯのように送信が２つのトランスポートブロック（コードワード）を含む場合は、図５に関して当然のことながら、肯定ＦＲＩが両トランスポートブロックの再送信を指示して、過剰なＰＨＹ再処理なく、送信バッファを可能な限り多く再利用するのが好ましい。この場合は、図５を参照して、両トランスポートブロックを再送信する場合に送信バッファを再利用すると、図５に示すブロックを一切処理する必要がなくなる。すなわち、２つのトランスポートブロックの再送信は、各「ＳＣ−ＦＤＭＡ信号生成」ブロックの直後に起こるため、別途処理なく、ｅＮｏｄｅＢに直接送信可能である。

同じく複数のアンテナを使用可能なｅＮｏｄｅＢ側では、トランスポートブロックの再送信をトリガするＦＲＩの送信に際して、再送信されたトランスポートブロックが複数の受信アンテナを用いてｅＮｏｄｅＢで受信される。

ただし、（単一の）ＦＲＩによる両トランスポートブロックの再送信のトリガは、無線リソース効率および信号対雑音比を犠牲にすることになる。したがって、本実施形態の別の実施態様では、１つのトランスポートブロックのｅＮｏｄｅＢへの再送信および１つのトランスポートブロックのｅＮｏｄｅＢでの受信が複数の送信アンテナを用いて実行されるように、ＦＲＩ当たり１つのトランスポートブロックの再送信をトリガすることになる。この場合は、ＳＣ−ＦＤＭＡ信号が送信に利用可能となるまで、ＵＥでより多くの処理が必要になることに留意する。すなわち、図５を参照して、ＦＲＩが１つのトランスポートブロックの再送信のみをトリガする場合は、「ＳＣ−ＦＤＭＡ信号生成」ブロックまで、「レイヤマッピング」ブロックの処理を伴う。

上記説明は、再送信の挙動に関し、これによれば、同じトランスポートブロックのデータが送信および再送信に使用されるものと仮定する。すなわち、再送信が同じＨＡＲＱプロセスに当てはまることを暗示している。ただし、同期または非同期プロトコルに従って、同時にスケジューリング可能な複数のＨＡＲＱプロセスが存在していてもよい。

いずれの場合も、図７に示すように、高速再送信は時間「＃ｔ＿ｐｕｓｃｈ」でのＴＴＩに発生することになる。したがって、一般的に異なるＨＡＲＱプロセスに関して、時間「＃ｔ＿ｐｕｓｃｈ」でのＰＵＳＣＨ送信が肯定ＦＲＩにより時間「＃ｔ＿ｐｕｓｃｈ−ｔ２」にトリガされる可能性もあるし、ＤＣＩ（または、ＨＩ）により時間「＃ｔ＿ｐｕｓｃｈ−ｔ０」にトリガされる可能性もある。したがって、図７においては、異なるＨＡＲＱプロセスＰ０およびＰ１を示している。図７に示す例示的な場合においては、ＨＡＲＱプロセスＰ０が時間「＃ｔ＿ｐｕｓｃｈ」におけるＦＲＩ開始再送信に関する一方、ＨＡＲＱプロセスＰ１が時間「＃ｔ＿ｐｕｓｃｈ−ｔ０」におけるＤＣＩ開始再送信に関する。

図７にさらに示すように、両ＨＡＲＱプロセスＰ０およびＰ１の再送信は、結果的に時間「＃ｔ＿ｐｕｓｃｈ」における再送信となる。ただし、送信の衝突を回避するため、ＵＥは、時間「＃ｔ＿ｐｕｓｃｈ」になすべきことを決定する必要がある。第１の選択肢は、ＨＡＲＱプロセスＰ０の再送信を続けることである。すなわち、時間「＃ｔ＿ｐｕｓｃｈ−ｔ２」に受信されたＦＲＩトリガに従う。第２の選択肢は、ＨＡＲＱプロセスＰ１の再送信を続けることである。すなわち、時間「＃ｔ＿ｐｕｓｃｈ−ｔ０」に受信されたＤＣＩ（または、ＨＩ）に従う。

この点、本実施形態の好適な一実施態様は、ＵＥの具体的な挙動に関し、ＦＲＩによるデータパケットの再送信を実行する要求およびＤＣＩまたはＨＩによる別のデータパケットの送信を同時に実行する要求を受信した場合、ＦＲＩによる要求に従う（すなわち、前述の第１の選択肢）とともにＤＣＩまたはＨＩによる要求を無視する。

「背景」項に示した通り、ＨＩとＤＣＩとが衝突する場合、ＵＥは、ＤＣＩに従い、ＨＩを無視する。ただし、これとは対照的に、本実施形態の別の実施態様により提供されるような場合は、高速再送信に従って、ＤＣＩ（または、ＨＩ）を無視するものとする。これは、同じサブフレームに対応するＤＣＩよりも遅い時点に肯定ＦＲＩが送信されたためである。その結果、ｅＮｏｄｅＢは、ＵＥがＤＣＩではなく肯定ＦＲＩに従うようにしようとする場合、肯定ＦＲＩのみを送信すると仮定すべきである。そうでなければ、当該サブフレームについては、肯定ＦＲＩによる再送信をトリガしていないことになる。

図６に関して上述した通り、ＵＥがＦＲＩによる要求に従って送信の衝突を回避する場合も、図７に示すように、同一の冗長バージョンＲＶ＃０の使用により、ＤＣＩにより開始されるＰＵＳＣＨ送信およびＦＲＩにより開始されるＰＵＳＣＨ送信の両者が実行される。言い換えると、ＲＶ＃０は、ＤＣＩ開始ＰＵＳＣＨ送信により決定され、ＦＲＩ開始ＰＵＳＣＨ送信により再利用されたものである。

さらに、本実施形態の別の変形例において、ＦＲＩは、ＨＡＲＱプロセス番号インジケータをさらに含むことにより、送信機によってデータパケットの以前の送信に使用された特定のＨＡＲＱプロセスを示す。

以下の表においては、受信ＦＲＩおよびＤＣＩ／ＨＩの内容に関する複数の場合について、ＵＥ挙動を示す。

以下の表においては、受信ＦＲＩおよびＤＣＩ／ＨＩの内容に関する複数の場合について、別のＵＥ挙動を示す。

以上の説明を参照して、本実施形態の一変形例によれば、ＦＲＩは、以下の要素のうちの少なくとも１つを示していてもよい。
・高速再送信がトリガされたか否か（肯定ＦＲＩまたは否定ＦＲＩあるいはＮＡＣＫまたはＡＣＫ）
・高速再送信がトリガされた場合：トリガされた再送信のＨＡＲＱプロセス番号インジケータ
・高速再送信がトリガされた場合：再送信されるデータブロックの要求部分を示す部分的再送信パラメータ
・高速再送信がトリガされた場合：ＵＥが送信するまでの期間ｔ２に関する指示

本実施形態の別の実施態様によれば、ＵＥは、ＨＩの受信に使用される無線リソースにおいてＦＲＩを受信するか、ＦＲＩをＤＣＩ（たとえば、ＤＣＩフォーマット７）として受信するか、共通サーチスペースの予め設定された無線リソースにおいてＦＲＩを受信するか、または、ユーザ機器固有のサーチスペースの予め設定された無線リソースにおいてＦＲＩを受信する。

一般的に、ＦＲＩは、以下のうちの１つの方法で送信可能である。
・ＵＥがＰＨＩＣＨの発見を予想する同じＲＥ（ただし、ＰＵＳＣＨ送信と対応するＨＩを搬送するサブフレームとの間の時間よりも期間ｔ１が短い場合は異なるサブフレーム）すなわちサブフレーム／ＴＴＩの制御チャネル領域内のＲＥＧに属するＲＥにおける送信、または、
・ＤＣＩの共通サーチスペースに属するＲＥすなわちすべてのＵＥがＦＲＩを検出するＲＥにおける送信：または
・複数のＵＥおよび／またはサブフレームのＦＲＩが好適に多重化されるＤＣＩにおける送信。たとえば、ＤＣＩは、４つのＦＲＩを含む可能性もあり、第１のＦＲＩをＵＥ１に適用可能、第２のＦＲＩをＵＥ２に適用可能といったように、他も同様である。特にＴＤＤシステムの場合は、１つのＵＥについて複数のＦＲＩをＤＣＩへと多重化またはバンドルすることも可能であるため、たとえば最初の４つのＦＲＩをＵＥ１の４つのＰＵＳＣＨ送信に適用可能、次の３つのＦＲＩをＵＥ２の３つのＰＵＳＣＨ送信に適用可能といったように、他も同様である。複数のＵＥについてＦＲＩが多重化される場合は、ＤＣＩが共通サーチスペースにおいて送信されるのが好ましい。１つのＵＥについてのみＦＲＩが送信される場合は、ＤＣＩがＵＥ固有のサーチスペースにおいて送信されるのが好ましい。

本実施形態の一変形例として、上記内容のうちの１つまたは複数をＦＲＩに含む代わりに、上記のうちの１つまたは複数を用いて、ＦＲＩが送信されるＲＥを決定することも可能である。たとえば、ＨＡＲＱプロセスによって、ＦＲＩが送信されるＲＥを決定することも可能である。そして、ＵＥは、複数のＦＲＩリソースをモニタリングし、最大電力で受信されたＦＲＩのみを評価するのが好ましい。

上記実施形態の複数の変形例に関して説明した通り、「背景」項において説明したＨＩによりトリガされる再送信とは対照的に、肯定ＦＲＩは、再送信に対するＲＶの非明示的または明示的な変化を暗示しない。ただし、本実施形態の別の変形例として、ＦＲＩによりトリガされた再送信は、ＰＨＩＣＨによる非適応再送信の潜在的なＲＶ決定ルールに影響を及ぼさないものとする。「背景」項において上記した通り、ＰＨＩＣＨによりトリガされる再送信は、ＲＶ｛０，２，３，１｝間で非明示的かつ循環的に切り替わる。この変形例によれば、後々の非適応再送信のＲＶ決定を目的として肯定ＦＲＩが無視されるものとする。すなわち、ＲＶ切り替え／循環では、以前のＤＣＩ／ＨＩトリガ（再）送信のＲＶのみを考慮に入れるものとする。

本実施形態の別の変形例として、上述の通りＦＲＩを使用するほか、ＰＵＳＣＨが１ｍｓのＴＴＩ全体ではなく（上記「短レイテンシ」検討事項で論じている）短いＴＴＩのみを占有する場合は、トランスポートブロックが１ｍｓのＴＴＩよりも小さいため、ｅＮｏｄｅＢにおける復号結果（ＯＫ／失敗）を即座に利用可能となる。したがって、この場合は、従来システムにおけるＤＣＩ／ＨＩよりも早くＦＲＩを送信することも可能である。

本実施形態の別の実施態様として、データパケットの以前の送信は、「データパケットの初期送信」または「データパケットの再送信」であってもよい。

［本開示のハードウェアおよびソフトウェア実装］
他の例示的な実施形態は、ハードウェア、ソフトウェア、またはハードウェアと連携したソフトウェアの使用による上述の種々実施形態の実装に関する。これに関連して、ユーザ機器（移動端末）が提供される。ユーザ機器は、本明細書に記載の方法を実行するように構成されており、受信機、送信機、プロセッサ等の対応するエンティティがこれらの方法に適宜関与する。

コンピュータ機器（プロセッサ）を用いて種々実施形態が実装または実行され得ることもさらに認識される。コンピュータ機器またはプロセッサは、たとえば汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のプログラム可能な論理デバイス等であってもよい。また、種々実施形態は、これらのデバイスの組み合わせによって実行または具現化されていてもよい。特に、上述の各実施形態の説明に使用した各機能ブロックは、集積回路としてのＬＳＩにより実現可能である。これらは、チップとして個々に形成されていてもよいし、機能ブロックの一部または全部を含むように１つのチップが形成されていてもよい。これらは、データ入出力が結合されていてもよい。ここで、ＬＳＩは、集積度の違いに応じて、ＩＣ、システムＬＳＩ、超ＬＳＩ、または極超ＬＳＩとも称し得る。ただし、集積回路を実装する技術はＬＳＩに限定されず、個別回路または汎用プロセッサを用いることにより実現されるようになっていてもよい。また、ＬＳＩの製造後にプログラム可能なＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＬＳＩの内側に配設された回路セルの接続および設定を再構成可能な再構成可能プロセッサが用いられるようになっていてもよい。

さらに、種々実施形態は、プロセッサによる実行またはハードウェアにおける直接的な実行がなされるソフトウェアモジュールによって実装されていてもよい。また、ソフトウェアモジュールおよびハードウェア実装の組み合わせも可能と考えられる。ソフトウェアモジュールは、たとえばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ等、如何なる種類のコンピュータ可読記憶媒体に記憶されていてもよい。さまざまな実施形態の個々の特徴は、個別または任意の組み合わせにより、別の実施形態の主題であってもよいことにさらに留意されたい。

当業者には当然のことながら、特定の実施形態に示すように、本開示の多くの変形および／または改良が可能である。したがって、本実施形態は、あらゆる点で例示に過ぎず、何ら限定的なものではないと考えるべきである。

Claims (48)

1. 通信システムにおけるアップリンクデータパケット送信の送信プロトコルを動作させるユーザ機器であって、
   ＦＲＩと称する高速再送信インジケータを受信するように動作する受信機であり、前記ＦＲＩは、以前に送信されたデータパケットの再送信を基地局が要求しているか否かを示す、受信機と、
   前記データパケットの前記以前の送信にすでに使用されたものと同じ冗長バージョンを用いて前記データパケットを再送信するように動作する送信機と、
   を備えた、ユーザ機器。
2. 前記ＦＲＩは、前記データパケットの前記以前の送信に使用されたものと同一の追加の送信パラメータで前記再送信が実行されることを示し、
   前記送信機は、前記データパケットの前記以前の送信に使用されたものと同一の追加の送信パラメータを用いて、前記データパケットを再送信するようにさらに動作する、請求項１に記載のユーザ機器。
3. 前記データパケットの再送信に用いられる前記追加の同一の送信パラメータは、少なくとも前記以前に送信されたデータパケットのスクランブルコードである、請求項２に記載のユーザ機器。
4. 前記ＦＲＩは、前記以前に送信されたデータパケットの一部の再送信が実行されることを示し、任意選択で、一部は前記以前に送信されたデータパケットの５０％または２５％であり
   前記送信機は、前記以前に送信されたデータパケットの示された前記一部を再送信するようにさらに動作する、請求項１〜３のいずれか一項に記載のユーザ機器。
5. 前記送信機は、前記以前に送信されたデータパケットの前記一部の前記再送信の合計送信電力が前記以前に送信されたデータパケットの合計送信電力と等しくなるように、前記再送信に送信電力を使用するようにさらに動作し、任意選択で、前記データパケットの５０％を使用すると、前記以前に送信されたデータパケットの前記一部の送信電力が２倍に増加する、請求項４に記載のユーザ機器。
6. 前記受信機は、前記以前のデータパケットの前記送信後の第１のタイミングに前記ＦＲＩを受信するようにさらに動作し、前記第１のタイミングは、固定、または、前記基地局により準静的に設定可能である、請求項１〜５のいずれか一項に記載のユーザ機器。
7. 前記送信機は、前記受信機による前記ＦＲＩの受信後の第２のタイミングに前記データパケットの前記再送信を送信するようにさらに動作し、
   前記第２のタイミングは、固定、または、前記基地局により準静的に設定可能、または、前記受信ＦＲＩに含まれる各情報に基づいて可変である、請求項１〜６のいずれか一項に記載のユーザ機器。
8. データパケットの再送信は、ＤＣＩと称するダウンリンク制御情報、および／または、ＨＩと称するＨＡＲＱインジケータによってもトリガ可能であり、
   前記データパケットの前記以前の送信と前記ＦＲＩの前記受信との間の第１の期間、および／または、前記ＦＲＩの前記受信と前記データパケットの前記再送信との間の第２の期間は、ＤＣＩまたはＨＩの受信とそれに対応する前記データパケットの再送信との間の第３の期間よりも短く、任意選択で、前記第１の期間および前記第２の期間の少なくとも一方が４ｍｓよりも短い、請求項１〜７のいずれか一項に記載のユーザ機器。
9. 前記受信機が、前記ＦＲＩによる前記データパケットの前記再送信を実行する要求および前記ＤＣＩまたはＨＩによる別のデータパケットの送信を同時に実行する要求を受信した場合、前記送信機は、前記ＦＲＩによる前記要求に従い、前記ＤＣＩまたはＨＩによる前記要求を無視するようにさらに動作する、請求項８に記載のユーザ機器。
10. 前記ＦＲＩは、前記送信機により前記データパケットの前記以前の送信に使用されたＨＡＲＱプロセスを示すＨＡＲＱプロセス番号インジケータをさらに含む、請求項１〜９のいずれか一項に記載のユーザ機器。
11. 前記データパケットの前記以前の送信は、前記データパケットの初期送信または再送信である、請求項１〜１０のいずれか一項に記載のユーザ機器。
12. 前記受信機は、前記ＨＩの受信に使用される無線リソースにおいて前記ＦＲＩを受信するか、前記ＦＲＩをＤＣＩとして受信するか、共通サーチスペースの予め設定された無線リソースにおいて前記ＦＲＩを受信するか、または、ユーザ機器固有のサーチスペースの予め設定された無線リソースにおいて前記ＦＲＩを受信するようにさらに動作する、請求項１〜１１のいずれか一項に記載のユーザ機器。
13. 前記ユーザ機器がデータパケットの送信に複数の送信アンテナを使用する場合、
    前記受信機は、前記データパケットの再送信をトリガする前記ＦＲＩを受信するようにさらに動作し、
    前記送信機は、前記複数の送信アンテナを用いて前記データパケットを前記基地局に再送信するようにさらに動作する、
    または、
    前記受信機は、前記データパケットのうちの１つの再送信をトリガする前記ＦＲＩを受信するようにさらに動作し、
    前記送信機は、前記複数の送信アンテナを用いて前記データパケットのうちの前記１つを前記基地局に再送信するようにさらに動作する、請求項１〜１２のいずれか一項に記載のユーザ機器。
14. 通信システムにおけるアップリンクデータパケット送信の送信プロトコルを動作させる基地局であって、
    ＦＲＩと称する高速再送信インジケータを送信するように動作する送信機であり、前記ＦＲＩは、以前に送信されたデータパケットの再送信が要求されるか否かをユーザ機器に示す、送信機と、
    前記ユーザ機器により前記データパケットの前記以前の送信にすでに使用されたものと同じ冗長バージョンの前記再送信データパケットを、前記ユーザ機器から受信するように動作する受信機と、
    を備えた、基地局。
15. データパケットの受信が成功しなかった場合、前記データパケットの再送信が、前記ＦＲＩ、または、ＤＣＩと称するダウンリンク制御情報、または、ＨＩと称するＨＡＲＱインジケータを用いて、前記ユーザ機器から要求されたかを判定するように動作するプロセッサをさらに備え、
    前記送信機は、前記ＦＲＩ、前記ＤＣＩ、または前記ＨＩのいずれかを送信するようにさらに動作する、請求項１４に記載の基地局。
16. 前記ＦＲＩは、前記データパケットの前記以前の送信に使用されたものと同一の追加の送信パラメータで前記再送信が実行されることを前記ユーザ機器に示し、
    前記受信機は、前記データパケットの前記以前の送信に使用されたものと同一の追加の送信パラメータを用いて再送信された前記データパケットを受信するようにさらに動作する、請求項１４または１５に記載の基地局。
17. 前記再送信データパケットに用いられる前記追加の同一の送信パラメータは、少なくとも前記以前に送信されたデータパケットのスクランブルコードである、請求項１４〜１６のいずれか一項に記載の基地局。
18. 前記ＦＲＩは、前記以前に送信されたデータパケットの一部の再送信が実行されることを前記ユーザ機器に示し、任意選択で、一部が、前記以前に送信されたデータパケットの５０％または２５％であり
    前記受信機が、前記以前に送信されたデータパケットの前記再送信される一部を受信するようにさらに動作する、請求項１４〜１７のいずれか一項に記載の基地局。
19. 前記送信機は、前記以前のデータパケットの前記受信後の第１のタイミングに前記ＦＲＩを送信するようにさらに動作し、前記第１のタイミングは、固定または前記基地局により準静的に設定可能である、請求項１４〜１８のいずれか一項に記載の基地局。
20. 前記受信機は、前記送信機による前記ＦＲＩの送信後の第２のタイミングに前記データパケットの前記再送信を受信するようにさらに動作し、
    前記第２のタイミングは、固定、または、前記基地局により準静的に設定可能、または、前記送信ＦＲＩに含まれる各情報に基づいて可変である、請求項１４〜１９のいずれか一項に記載の基地局。
21. データパケットの再送信は、前記基地局により前記ＤＣＩおよび／または前記ＨＩによってもトリガ可能であり、
    前記以前に送信されたデータパケットの前記受信と前記ＦＲＩの前記送信との間の第１の期間、および／または、前記ＦＲＩの前記送信と前記データパケットの前記再送信の前記受信との間の第２の期間は、ＤＣＩまたはＨＩの送信とそれに対応する前記再送信データパケットの受信との間の第３の期間よりも短く、任意選択で、前記第１の期間および前記第２の期間の少なくとも一方が４ｍｓよりも短い、請求項１４〜２０のいずれか一項に記載の基地局。
22. 前記ＦＲＩは、前記ユーザ機器により前記データパケットの前記以前の送信に使用されたＨＡＲＱプロセスを示すＨＡＲＱプロセス番号インジケータをさらに含む、請求項１４〜２１のいずれか一項に記載の基地局。
23. 前記ユーザ機器による前記データパケットの前記以前の送信は、前記データパケットの初期送信または再送信である、請求項１４〜２２のいずれか一項に記載の基地局。
24. 前記基地局が複数の受信アンテナを使用する場合、
    前記送信機は、前記データパケットの再送信をトリガする前記ＦＲＩを送信するようにさらに動作し、
    前記受信機は、前記複数の送信アンテナを用いて前記再送信データパケットを受信するようにさらに動作する、
    または、
    前記送信機は、前記データパケットのうちの１つの再送信をトリガする前記ＦＲＩを送信するようにさらに動作し、
    前記受信機は、前記複数の受信アンテナを用いて前記データパケットのうちの前記１つの再送信データパケットを受信するようにさらに動作する、請求項１４〜２３のいずれか一項に記載の基地局。
25. 通信システムにおけるアップリンクデータパケット送信の送信プロトコルをユーザ機器において動作させる方法であって、
    ＦＲＩと称する高速再送信インジケータを受信するステップであり、前記ＦＲＩは、以前に送信されたデータパケットの再送信を基地局が要求しているか否かを示し、
    前記データパケットの前記以前の送信にすでに使用されたものと同じ冗長バージョンを用いて前記データパケットを再送信するステップと、
    を含む、方法。
26. 前記ＦＲＩは、前記データパケットの前記以前の送信に使用されたものと同一の追加の送信パラメータで前記再送信が実行されることを示し、
    前記データパケットの前記以前の送信に使用されたものと同一の追加の送信パラメータを用いて前記データパケットを再送信するステップをさらに含む、請求項２５に記載の方法。
27. 前記データパケットの再送信に用いられる前記追加の同一の送信パラメータは、少なくとも前記以前に送信されたデータパケットのスクランブルコードである、請求項２６に記載の方法。
28. 前記ＦＲＩは、前記以前に送信されたデータパケットの一部の再送信が実行されることを示し、任意選択で、一部は前記以前に送信されたデータパケットの５０％または２５％であり
    前記以前に送信されたデータパケットの示された前記一部を再送信するステップをさらに含む、請求項２５〜２７のいずれか一項に記載の方法。
29. 前記以前に送信されたデータパケットの前記一部の前記再送信の合計送信電力が前記以前に送信されたデータパケットの合計送信電力と等しくなるように、前記再送信に送信電力を使用するステップをさらに含み、任意選択で、前記データパケットの５０％を使用すると、前記以前に送信されたデータパケットの前記一部の送信電力が２倍に増加する、請求項２８に記載の方法。
30. 前記以前のデータパケットの前記送信後の第１のタイミングに前記ＦＲＩを受信するステップをさらに含み、前記第１のタイミングは、固定、または、前記基地局により準静的に設定可能である、請求項２５〜２９のいずれか一項に記載の方法。
31. 前記受信機による前記ＦＲＩの受信後の第２のタイミングに前記データパケットの前記再送信を送信するステップをさらに含み、
    前記第２のタイミングは、固定、または、前記基地局により準静的に設定可能、または、前記受信ＦＲＩに含まれる各情報に基づいて可変である、請求項２５〜３０のいずれか一項に記載の方法。
32. データパケットの再送信は、ＤＣＩと称するダウンリンク制御情報、および／または、ＨＩと称するＨＡＲＱインジケータによってもトリガ可能であり、
    前記データパケットの前記以前の送信と前記ＦＲＩの前記受信との間の第１の期間、および／または、前記ＦＲＩの前記受信と前記データパケットの前記再送信との間の第２の期間は、ＤＣＩまたはＨＩの受信とそれに対応する前記データパケットの再送信との間の第３の期間よりも短く、任意選択で、前記第１の期間および前記第２の期間の少なくとも一方が４ｍｓよりも短い、請求項２５〜３１のいずれか一項に記載の方法。
33. 前記ユーザ機器によって、前記ＦＲＩによる前記データパケットの前記再送信を実行する要求および前記ＤＣＩまたはＨＩによる別のデータパケットの送信を同時に実行する要求を受信した場合、前記ＦＲＩによる前記要求に従い、前記ＤＣＩまたはＨＩによる前記要求を無視するステップをさらに含む、請求項３２に記載の方法。
34. 前記ＦＲＩは、前記ユーザ機器により前記データパケットの前記以前の送信に使用されたＨＡＲＱプロセスを示すＨＡＲＱプロセス番号インジケータをさらに含む、請求項２５〜３３のいずれか一項に記載の方法。
35. 前記データパケットの前記以前の送信は、前記データパケットの初期送信または再送信である、請求項２５〜３４のいずれか一項に記載の方法。
36. 前記ＨＩの受信に使用される無線リソースにおいて前記ＦＲＩを受信するステップ、前記ＦＲＩをＤＣＩとして受信するステップ、共通サーチスペースの予め設定された無線リソースにおいて前記ＦＲＩを受信するステップ、または、ユーザ機器固有のサーチスペースの予め設定された無線リソースにおいて前記ＦＲＩを受信するステップ、をさらに含む、請求項２５〜３５のいずれか一項に記載の方法。
37. 前記ユーザ機器がデータパケットの送信に複数の送信アンテナを使用する場合、
    前記データパケットの再送信をトリガする前記ＦＲＩを受信するステップと、
    前記複数の送信アンテナを用いて前記データパケットを前記基地局に再送信するステップ、
    または、
    前記データパケットのうちの１つの再送信をトリガする前記ＦＲＩを受信するステップと、
    前記複数の送信アンテナを用いて前記データパケットのうちの前記１つを前記基地局に再送信するステップと、をさらに含む、請求項２５〜３６のいずれか一項に記載の方法。
38. 通信システムにおけるアップリンクデータパケット送信の送信プロトコルを基地局において動作させる方法であって、
    ＦＲＩと称する高速再送信インジケータを送信するステップであり、前記ＦＲＩは、以前に送信されたデータパケットの再送信が要求されるか否かをユーザ機器に示し、
    前記ユーザ機器により前記データパケットの前記以前の送信にすでに使用されたものと同じ冗長バージョンの前記再送信データパケットを前記ユーザ機器から受信するステップと、
    を含む、方法。
39. データパケットの受信が成功しなかった場合、前記データパケットの再送信が、前記ＦＲＩ、または、ＤＣＩと称するダウンリンク制御情報、または、ＨＩと称するＨＡＲＱインジケータを用いて、前記ユーザ機器から要求されたかを判定するステップと、
    前記ＦＲＩ、前記ＤＣＩ、または、前記ＨＩのいずれかを送信するステップと、
    をさらに含む、請求項３８に記載の方法。
40. 前記ＦＲＩは、前記データパケットの前記以前の送信に使用されたものと同一の追加の送信パラメータで前記再送信が実行されることを前記ユーザ機器に示し、
    前記データパケットの前記以前の送信に使用されたものと同一の追加の送信パラメータを用いて再送信された前記データパケットを受信するステップをさらに含む、請求項３８または３９に記載の方法。
41. 前記再送信データパケットに用いられる前記追加の同一の送信パラメータは、少なくとも前記以前に送信されたデータパケットのスクランブルコードである、請求項３８〜４０のいずれか一項に記載の方法。
42. 前記ＦＲＩは、前記以前に送信されたデータパケットの一部の再送信が実行されることを前記ユーザ機器に示し、任意選択で、一部が前記以前に送信されたデータパケットの５０％または２５％であり
    前記以前に送信されたデータパケットの前記再送信される一部を受信するステップをさらに含む、請求項３８〜４１のいずれか一項に記載の方法。
43. 前記以前のデータパケットの前記受信後の第１のタイミングに前記ＦＲＩを送信するステップをさらに含み、前記第１のタイミングは、固定または前記基地局により準静的に設定可能である、請求項３８〜４２のいずれか一項に記載の方法。
44. 前記送信機による前記ＦＲＩの送信後の第２のタイミングに前記データパケットの前記再送信を受信するステップをさらに含み、
    前記第２のタイミングは、固定、または、前記基地局により準静的に設定可能、または、前記送信ＦＲＩに含まれる各情報に基づいて可変である、請求項３８〜４３のいずれか一項に記載の方法。
45. データパケットの再送信は、前記基地局により前記ＤＣＩおよび／または前記ＨＩによってもトリガ可能であり、
    前記以前に送信されたデータパケットの前記受信と前記ＦＲＩの前記送信との間の第１の期間、および／または、前記ＦＲＩの前記送信と前記データパケットの前記再送信の前記受信との間の第２の期間は、ＤＣＩまたはＨＩの送信とそれに対応する前記再送信データパケットの受信との間の第３の期間よりも短く、任意選択で、前記第１の期間および前記第２の期間の少なくとも一方が４ｍｓよりも短い、請求項３８〜４４のいずれか一項に記載の方法。
46. 前記ＦＲＩは、前記ユーザ機器により前記データパケットの前記以前の送信に使用されたＨＡＲＱプロセスを示すＨＡＲＱプロセス番号インジケータをさらに含む、請求項３８〜４５のいずれか一項に記載の方法。
47. 前記ユーザ機器による前記データパケットの前記以前の送信は、前記データパケットの初期送信または再送信である、請求項３８〜４６のいずれか一項に記載の方法。
48. 前記基地局が複数の送信アンテナを使用する場合、
    前記データパケットの再送信をトリガする前記ＦＲＩを送信するステップと、
    前記複数の受信アンテナを用いて前記再送信データパケットを受信するステップ、
    または、
    前記データパケットのうちの１つの再送信をトリガする前記ＦＲＩを送信するステップと、
    前記複数の受信アンテナを用いて前記データパケットのうちの前記１つの再送信データパケットを受信するステップと、をさらに含む、請求項３８〜４７のいずれか一項に記載の方法。

Images