JP6560457B2

JP6560457B2 - Ｐｕｃｃｈリソース割当

Info

Publication number: JP6560457B2
Application number: JP2018542216A
Authority: JP
Inventors: エサティーロラ; サミユッカハコラ; カリパユコスキ; エーバラヘトカンガス
Original assignee: ノキアテクノロジーズオーユー
Priority date: 2016-03-01
Filing date: 2017-02-08
Publication date: 2019-08-14
Anticipated expiration: 2037-02-08
Also published as: KR20180121937A; CN109156030B; JP2019505138A; EP3424258A1; WO2017149194A1; EP3424258B1; CN109156030A; US10932237B2; US20190053219A1; PH12018501860A1; EP3424258A4; KR102144207B1

Description

本発明は、概して無線ネットワークにおける制御チャネルに関し、特にＰＵＣＣＨ（Physical Uplink Control Channel：物理アップリンク制御チャネル）リソース割当に関する。

背景

本項は、以下に記載される本発明の背景または文脈を提供することを目的とする。本項における説明は、追求されうる概念を含む可能性があり、必ずしも過去に着想、実施、または記載された概念ではない。したがって、本明細書に別途明示されないかぎり、本項に記載される事項は、本願における説明に対する従来技術ではなく、本項に含まれることによって従来技術であるとされるべきものではない。本明細書および／または図面に用いられる可能性のある略語を、以下の詳細な説明の末尾にて定義する。

移動局やその他同様の無線デバイス（ユーザ端末（User Equipment：ＵＥ）と総称する）に対する無線データ通信規格は、何世代にもわたる進化を遂げている。現在は第４世代、４ＧＬＴＥが普及しており、さらに第５世代、５Ｇの開発実施も進行中である。５Ｇは、４Ｇを上回るデータレートを実現する多数の技術で設計されている。

例えば、高コスト効率のＧｂ／ｓの実現や、より高い周波数帯域（ｃｍＷａｖｅ、ｍｍＷａｖｅ等）での通信の実現を図るカギとなる技術の一つとして、ＲＦビームフォーミングに基づくマッシブＭＩＭＯが挙げられる。これは、例えば送信機および／または受信機側に過度なデジタル処理負担をかけずに、高ビームフォーミングゲインを実現するものである。ＲＦビームフォーミングは、基地局またはその他ＲＦ送信機から、例えば移動局上の受信機への送信が、「集中的に発射」（beamed）されるように実現される技術である。

このような技術革新を支え、データレート上昇を実現するにあたって、アップリンク制御情報（Uplink Control Information：ＵＣＩ）構成が５ＧのＫＰＩの向上に寄与する。ＫＰＩとしては、レイテンシ、スペクトル効率（例えば、システム全体のオーバーヘッド）、所与の条件下で同時に網羅できるＵＥの数が挙げられる。特に、ＨＡＲＱ−ＡＣＫおよび／またはＣＳＩ等のＵＬ制御情報を、ＵＬチャネル（複数可）を介して運ぶＰＵＣＣＨであれば、５Ｇで実現される改良点に対応可能であろうと期待されている。

摘要

本項は例示を目的としており、限定の意図はない。
例示的実施形態において、方法は、第１のサブフレームにおいてネットワークノードによって、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ユーザ端末に送信することを含む。前記タイミング標示は、物理アップリンク制御チャネルにおいて、前記第１のサブフレームの前記ダウンリンク共有チャネルにおいて受信された前記データに対する応答情報を送信するために使用される第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す。前記方法はさらに、前記ネットワークノードによって、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記ユーザ端末から前記応答情報を受信することを含む。

実施形態の別の例としてコンピュータプログラムを含み、前記コンピュータプログラムは、プロセッサ上で実行されると前段落の方法を実施するコードを含む。本段落のコンピュータプログラムは、コンピュータとともに使用するために内部に実装されたコンピュータプログラムコードを有するコンピュータ可読媒体を含むコンピュータプログラムプロダクトである。

一例としての装置は、１つ以上のプロセッサと、コンピュータプログラムコードを含む１つ以上のメモリとを備える。前記１つ以上のメモリおよび前記コンピュータプログラムコードは、前記１つ以上のプロセッサによって、少なくとも、第１のサブフレームにおいてネットワークノードによって、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ユーザ端末に送信することと、前記ネットワークノードによって、第２のサブフレームの物理アップリンク制御チャネルにおいて、前記ユーザ端末から応答情報を受信することとを前記装置に実施させるように構成され、前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームの前記ダウンリンク共有チャネルにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す。

一例としてのコンピュータプログラムプロダクトは、コンピュータとともに使用するために内部に実装されたコンピュータプログラムコードを有するコンピュータ可読記憶媒体を含む。コンピュータプログラムコードは、第１のサブフレームにおいてネットワークノードによって、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ユーザ端末に送信するためのコードと、前記ネットワークノードによって、第２のサブフレームの物理アップリンク制御チャネルにおいて、前記ユーザ端末から応答情報を受信するためのコードとを含み、前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームの前記ダウンリンク共有チャネルにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す。

実施形態の別の例において、装置は、第１のサブフレームにおいてネットワークノードによって、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ユーザ端末に送信する手段と、前記ネットワークノードによって、第２のサブフレームの物理アップリンク制御チャネルにおいて、前記ユーザ端末から応答情報を受信する手段とを含み、前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームの前記ダウンリンク共有チャネルにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す。

別の例示的実施形態において、方法は、第１のサブフレームにおいてユーザ端末で、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ネットワークノードから受信することを含む。前記タイミング標示は、物理アップリンク制御チャネルにおいて、前記第１のサブフレームにおいて受信された前記データに対する応答情報を送信するために使用される第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す。前記方法はさらに、前記ユーザ端末によって、少なくとも前記タイミング標示を使用して前記第２のサブフレームを決定することと、前記ユーザ端末によって、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記応答情報を前記ネットワークノードに対して送信することと、を含む。

一例としての装置は、１つ以上のプロセッサと、コンピュータプログラムコードを含む１つ以上のメモリとを備える。前記１つ以上のメモリおよび前記コンピュータプログラムコードは、前記１つ以上のプロセッサによって、少なくとも、第１のサブフレームにおいてユーザ端末で、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ネットワークノードから受信することと、前記ユーザ端末によって、少なくとも前記タイミング標示を使用して第２のサブフレームを決定することと、前記ユーザ端末によって、前記第２のサブフレームの物理アップリンク制御チャネルにおいて、応答情報を前記ネットワークノードに対して送信することとを前記装置に実施させるように構成され、前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す。

一例としてのコンピュータプログラムプロダクトは、コンピュータとともに使用するために内部に実装されたコンピュータプログラムコードを有するコンピュータ可読記憶媒体を含む。前記コンピュータプログラムコードは、第１のサブフレームにおいてユーザ端末で、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ネットワークノードから受信するためのコードと、前記ユーザ端末によって、少なくとも前記タイミング標示を使用して第２のサブフレームを決定するためのコードと、前記ユーザ端末によって、前記第２のサブフレームの物理アップリンク制御チャネルにおいて、応答情報を前記ネットワークノードに対して送信するためのコードとを含み、前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す。

実施形態の別の例において、装置は、第１のサブフレームにおいてユーザ端末で、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ネットワークノードから受信する手段と、前記ユーザ端末によって、少なくとも前記タイミング標示を使用して第２のサブフレームを決定する手段と、前記ユーザ端末によって、前記第２のサブフレームの物理アップリンク制御チャネルにおいて、応答情報を前記ネットワークノードに対して送信する手段と、を備え、前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す。

図１は、例示的実施形態を採用可能な、実施可能で非限定的な例示的システムの１つを示すブロック図である。図２は、図２ａ、２ｂ、および２ｃを含み、ｘＰＵＣＣＨに対して可能な様々なシナリオを示す。図３は、ＬＴＥＴＤＤに対するダウンリンクアソシエーションセットのインデックスＫ：｛k₀,k₁,・・・k_M-1｝を示す表である。例えば、３ＧＰＰＴＳ３６．２１３Ｖ１２.８.０（２０１５−１２）の表１０.１.３.１−１も参照されたい。図４は、MulteFireシナリオにおけるＰＵＣＣＨと、対応するＨＡＲＱ−ＡＣＫフィードバックを示す図である。図５は、リソース最適化割当を示す（ＵＥ／ｅＮＢ処理時間は約２サブフレームとする）。大きな矢印は、ｘＰＤＣＣＨを使用したｘＰＵＣＣＨスケジューリングを示し、小さな矢印は、ｘＰＤＣＣＨを使用したｘＰＤＳＣＨスケジューリングを示す。図６は、レイテンシ最適化割当を示す（ＵＥ／ｅＮＢ処理時間は約２サブフレームとする）。大きな矢印は、ｘＰＤＣＣＨを使用したｘＰＵＣＣＨスケジューリングを示し、小さな矢印は、ｘＰＤＣＣＨを使用したｘＰＤＳＣＨスケジューリングを示す。図７は、ｘＰＤＣＣＨリソース単位と、ｘＰＵＣＣＨリソース単位との一対一のマッピングを示す。図８は、ネットワークノードによって実行されるＰＵＣＣＨリソース割当の論理フローチャートである。この図により、例示的方法の動作、コンピュータ可読メモリに実装されたコンピュータプログラム命令の実行結果、ハードウェアで実現されるロジックによって実行される機能、および／または例示的実施形態に係る機能を実行するための相互接続手段が示される。図９は、ユーザ端末により実行されるＰＵＣＣＨリソース割当の論理フローチャートである。この図により、例示的方法の動作、コンピュータ可読メモリに実装されたコンピュータプログラム命令の実行結果、ハードウェアで実現されるロジックによって実行される機能、および／または例示的実施形態に係る機能を実行するための相互接続手段が示される。

詳細説明

本明細において使用される用語「例示的」とは、「例、実例、説明例となる」ことを意味する。「例示的」と示された本明細書に記載のいずれの実施形態も、その他の実施形態と比較して必ずしも好適な、または有利なものとして解釈されるものではない。この詳細な説明に記載されたすべての実施形態は、当業者が本発明を製造または使用することができるように提供された例示的実施形態であり、請求項に定義された本発明の範囲を限定するものではない。

参照しやすいように、本開示は複数のセクションに分かれている。最初に、導入説明が設けられ、続いて複数の例を詳細に説明する。

［導入説明：実施可能なシステムの例］

本明細書に記載の例示的実施形態では、ＰＵＣＣＨリソース割当についての技術が記載される。ここで、ハイブリッド・ビームフォーミング・アーキテクチャのためのｘＰＵＣＣＨリソース割当に特に重点を置く。ここで、ＬＴＥ／４ＧＰＵＣＣＨからの区別のために頭字語「ｘＰＵＣＣＨ」が使用されるが、本明細書に提示する技術が特定のＰＵＣＣＨに限定されるものではないことが理解されよう。例示的実施形態を利用可能なシステムを説明した後に、これら技術のさらなる解説と導入説明を行う。

図１は、例示的実施形態が実現可能な、実施可能かつ非限定的な例示的システムのブロック図である。図１において、ユーザ端末（User Equipment：ＵＥ）１１０は無線ネットワーク１００と無線通信中である。ＵＥは、無線ネットワークにアクセス可能な無線デバイス、典型的にはモバイルデバイスである。ＵＥ１１０は、１つ以上のプロセッサ１２０と、１つ以上のメモリ１２５と、１つ以上の送受信機１３０とを有し、これらは１つ以上のバス１２７を介して相互接続される。１つ以上の送受信機１３０はそれぞれ、受信機（Ｒｘ）１３２と、送信機（Ｔｘ）１３３とを有する。１つ以上のバス１２７は、アドレスバス、データバス、またはコントロールバスであってもよく、任意の相互接続機構を含んでもよい。当該機構としては、マザーボードまたは集積回路上の一連の回線、光ファイバーまたはその他光学通信端末等が挙げられる。１つ以上の送受信機１３０は、１つ以上のアンテナ１２８に接続される。１つ以上のメモリ１２５はコンピュータプログラムコード１２３を含む。ＵＥ１１０は、ＰＵＣＣＨＲＡモジュール１４０を含む。ＰＵＣＣＨＲＡモジュール１４０は、モジュール部１４０−１および／または１４０−２の一方または両方を含み、これらは多様な方法で実現できる。ＰＵＣＣＨＲＡモジュール１４０は、ＰＵＣＣＨＲＡモジュール１４０−１としてハードウェアで実現できる。すなわち、１つ以上のプロセッサ１２０の一部として実現できる。ＰＵＣＣＨＲＡモジュール１４０−１は、集積回路として実現されてもよいし、プログラマブルゲートアレイ等のその他ハードウェアにより実現されてもよい。別の例では、ＰＵＣＣＨＲＡモジュール１４０は、コンピュータプログラムコード１２３として実現され、１つ以上のプロセッサ１２０により実行されるＰＵＣＣＨＲＡモジュール１４０−２として実現されてもよい。例えば、１つ以上のメモリ１２５およびコンピュータプログラムコード１２３は、１つ以上のプロセッサ１２０によって、本明細書に記載の動作の１つ以上をユーザ端末１１０に実施させるように構成されてもよい。ＵＥ１１０は、無線リンク１１１を介してｅＮＢ１７０と通信する。

ｅＮＢ（進化ノードＢ）１７０は、ＵＥ１１０等の無線デバイスから、無線ネットワーク１００にアクセスできるようにする基地局（例えば、ＬＴＥ（ロング・ターム・エボリューション）用）である。ｅＮＢ１７０は、１つ以上のプロセッサ１５２と、１つ以上のメモリ１５５と、１つ以上のネットワークインタフェース（Ｎ／ＷＩ／Ｆ）１６１と、１つ以上の送受信機１６０とを有し、これらは１つ以上のバス１５７を介して相互接続される。１つ以上の送受信機１６０はそれぞれ、受信機（Ｒｘ）１６２と送信機（Ｔｘ）１６３とを有する。１つ以上の送受信機１６０は１つ以上のアンテナ１５８に接続される。１つ以上のメモリ１５５はコンピュータプログラムコード１５３を含む。ｅＮＢ１７０は、ＰＵＣＣＨＲＡモジュール１５０を含む。ＰＵＣＣＨＲＡモジュール１５０は、モジュール部１５０−１および／または１５０−２の一方または両方を含み、これらは多様な方法で実現できる。ＰＵＣＣＨＲＡモジュール１５０は、ＰＵＣＣＨＲＡモジュール１５０−１としてハードウェアで実現できる。すなわち、１つ以上のプロセッサ１５２の一部として実現できる。ＰＵＣＣＨＲＡモジュール１５０−１は、集積回路として実現されてもよいし、プログラマブルゲートアレイ等のその他ハードウェアにより実現されてもよい。別の例では、ＰＵＣＣＨＲＡモジュール１５０は、コンピュータプログラムコード１５３として実現され、１つ以上のプロセッサ１５２により実行されるＰＵＣＣＨＲＡモジュール１５０−２として実現されてもよい。例えば、１つ以上のメモリ１５５およびコンピュータプログラムコード１５３は、１つ以上のプロセッサ１５２によって、本明細書に記載の動作の１つ以上をｅＮＢ１７０に実施させるように構成される。１つ以上のネットワークインタフェース１６１は、リンク１７６および１３１を介する等、ネットワークを介して通信を行う。２つ以上のｅＮＢ１７０は、例えば、リンク１７６を使用して通信を行う。リンク１７６は有線、無線、またはその両方であってもよく、例えば、Ｘ２インタフェースを実現してもよい。

１つ以上のバス１５７は、アドレスバス、データバス、またはコントロールバスであってもよく、任意の相互接続機構を含んでもよい。当該機構としては、マザーボードまたは集積回路上の一連の回線、光ファイバーまたはその他光学通信端末、無線チャネル等が挙げられる。例えば、１つ以上の送受信機１６０はリモートラジオヘッド（ＲＲＨ）１９５として実現されてもよい。この場合、ｅＮＢ１７０のその他要素はＲＲＨから離れた位置に物理的に配置され、１つ以上のバス１５７の一部は、ｅＮＢ１７０の当該その他要素をＲＲＨ１９５に接続する光ファイバーケーブルとして実現されてもよい。ＲＲＨ１９５および／またはｅＮＢ１７０は、ＵＥ（複数可）１１０との無線通信を提供するネットワークノードであってもよい。

無線ネットワーク１００は、ＭＭＥ（モビリティ・マネジメント・エンティティ）／ＳＧＷ（サービング・ゲートウェイ）機能を有し、電話回線および／またはデータ通信ネットワーク（例えば、インターネット）のような別のネットワークへの接続を可能としうるネットワーク制御要素（Network Control Element：ＮＣＥ）１９０を含んでもよい。ｅＮＢ１７０は、リンク１３１を介してＮＣＥ１９０に接続される。リンク１３１は、例えばＳ１インタフェースとして実現されてもよい。ＮＣＥ１９０は、１つ以上のプロセッサ１７５と、１つ以上のメモリ１７１と、１つ以上のネットワークインタフェース（Ｎ／ＷＩ／Ｆ）１８０とを有し、これらは１つ以上のバス１８５を介して相互接続される。１つ以上のメモリ１７１は、コンピュータプログラムコード１７３を含む。１つ以上のメモリ１７１およびコンピュータプログラムコード１７３は、１つ以上のプロセッサ１７５によって、１つ以上の動作をＮＣＥ１９０に実施させるように構成される。

無線ネットワーク１００は、ネットワーク仮想化を実現してもよい。すなわち、ハードウェアおよびソフトウェアネットワークリソースと、ネットワーク機能を組み合わせて、単一のソフトウェア型管理エンティティである仮想ネットワークを実現する処理である。ネットワーク仮想化は、多くの場合リソース仮想化と組み合わされる、プラットフォーム仮想化を伴う。ネットワーク仮想化は、外部（多数のネットワークやその一部を組み合わせて仮想化ユニットを実現）か、内部（ネットワーク的機能を単一システム上のソフトウェアコンテナに与える）かに分類される。なお、ネットワーク仮想化により得られた仮想化エンティティは、プロセッサ１５２または１７５やメモリ１５５および１７１等のハードウェアによりある程度実現されているのが現状であり、技術的効果を創出している。

コンピュータ可読メモリ１２５、１５５、１７１は、ローカルな技術的環境に適した任意の種類であってもよく、半導体型メモリデバイス、フラッシュメモリ、磁気メモリデバイスおよびシステム、光学メモリデバイスおよびシステム、固定式メモリ、着脱式メモリ等、任意の適切なデータ記憶技術により実現されてもよい。コンピュータ可読メモリ１２５、１５５、１７１は、記憶機能を実行する手段であってもよい。プロセッサ１２０、１５２、１７５は、ローカルな技術的環境に適した任意の種類であってもよく、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ（Digital Signal Processor：ＤＳＰ）、マルチコアのプロセッサアーキテクチャに基づくプロセッサを含んでもよいが、これらはあくまで非限定的な例である。プロセッサ１２０、１５２、１７５は、ＵＥ１１０、ｅＮＢ１７０を制御する機能や本明細書に記載のその他機能等の機能を実行する手段であってもよい。

概して、各種実施形態に係るユーザ端末１１０は、スマートフォンのような携帯電話、タブレット、無線通信機能付き携帯情報端末（Personal Digital Assistant：ＰＤＡ）、無線通信機能付きポータブルコンピュータ、デジタルカメラ等の無線通信機能付き撮像装置、無線通信機能付きゲーム機、無線通信機能付き音楽記憶／再生機器、無線インターネットアクセスおよびブラウジングが可能なインターネット機器、無線通信機能付きタブレット、これらの機能の組合せを含むポータブルユニットまたは端末を含んでもよいが、これらに限定されるものではない。

上述のように、本発明の例示的実施形態を実現するにあたって適切かつ非限定的な一技術的文脈を説明した。以下にさらなる導入説明を行う。

［導入説明：ハイブリッド送受信機アーキテクチャおよび対応するＰＵＣＣＨ］

より高い周波数帯域（ｃｍＷａｖｅ、ｍｍＷａｖｅ等）での無線通信は、通常、時分割二重化（Time Division Duplexing：ＴＤＤ）半二重技術に基づく。本技術によると、ノードは一度に特定の周波数帯域で送信または受信を行うことができる。ハイブリッド送受信機アーキテクチャを採用した場合の典型的な動作モードは、ビーム型動作である。ここでＢＳ（ｅＮＢ１７０等）は、一度に、特定の空間的方向に対して送信または受信が可能となる。したがって、セクターまたはセルの空間／角領域の一部のみが、一度に１または複数のビームで取得できる。平行ビームの数は、ベースバンドアンテナポート（受信機により、個別に識別可能な論理エンティティ）の数、ＲＦチェーン（送受信機ユニット）の数で決定される。特定のＢＳ実現に際して利用可能な設計パラメータを以下に述べる。例えば、ＢＳは、８個のアンテナポートと、４個の偏波共用アンテナパネルを含むアンテナアレイ（アンテナ１５８として作用）を含んでもよい。各パネルに２つのアンテナポートが接続される。典型的な動作において、１つのパネルが生成したＲＦビーム（２つの偏波ビーム）は、常に同じ方向に向けられる。したがって、一度に４つの異なる方向への送信を行う手段が提供される。受信についても同様である。この構成は、送信タイバーシティ、受信ダイバーシティがそれぞれ少なくとも２度保証される。

このハイブリッド送受信機アーキテクチャによると、多重化性能は、主に平行ビームの数と、当該ビームのビーム幅に基づく。アンテナゲインを上げるために、ビームを非常に狭めてもよい。この結果、一度の単一のビームで対象となるＵＥ１１０の数が限られ、場合によっては単一のＵＥ１１０のみが対象となりうる。したがって、セクター時間領域多重化の角領域中（すなわち各ビーム内）に配された多数のＵＥに対して、ｘＰＤＳＣＨＨＡＲＱ−ＡＣＫリソースを提供することが重要となる。

一方、ｘＰＵＣＣＨを介してｘＰＤＳＣＨＨＡＲＱ−ＡＣＫを送信するＵＥの数は、ｅＮＢ１７０のスケジューラの判断に応じて大幅に変動する。これを、図２（図２ａ、２ｂ、および２ｃを含む）を参照に以下に説明する。図２の各図は、４つのサブフレーム２１０−１から２１０−４を含み、ｘＰＤＣＣＨ２２０、ｘＰＵＣＣＨ２３０、ｘＰＤＳＣＨ２４０、ｘＰＵＳＣＨ２５０を示す。符号「ｘ」は、チャネルを対応するＬＴＥ／４Ｇチャネルと区別するために使用される。公知のように、サブフレーム２１０等のサブフレームは、ＯＦＤＭシンボル（時間（横軸）に示す）と、複数のサブキャリア（周波数（縦軸）に示す）を有する二次元リソース空間である。なお、本例では、異なるチャネル間、例えばｘＰＵＣＣＨとｘＰＵＳＣＨの間で時分割多重化が行われるものとするが、さらに異なるチャネル間でその他多重化手段も検討できる。これには例えば周波数分割多重化、符号分割多重化、および／または空間領域多重化が挙げられる。図２から、以下のことが示される。
・図２ａのシナリオは、同時に４台のＵＥに対するＰＤＳＣＨＨＡＲＱ−ＡＣＫを示す。サブフレーム２１０−４におけるｘＰＵＣＣＨ２３０が、サブフレーム２１０−２および２１０−３におけるＰＤＳＣＨ２４０を介して情報を受信する４台のＵＥに対するＨＡＲＱ−ＡＣＫ情報を含む。
・図２ｂのシナリオは、同時に８台のＵＥに対するＰＤＳＣＨＨＡＲＱ−ＡＣＫを示す。サブフレーム２１０−４におけるｘＰＵＣＣＨ２３０が、サブフレーム２１０−２および２１０−３におけるＰＤＳＣＨ２４０を介して情報を受信する８台のＵＥに対するＨＡＲＱ−ＡＣＫ情報を含む。
・図２ｃのシナリオは、同時に０台のＵＥに対するＰＤＳＣＨＨＡＲＱ−ＡＣＫを示す。サブフレーム２１０内にＰＤＳＣＨ２４０はなく、その代わりにサブフレームがＰＵＳＣＨ２５０を含む。

図２に示すとおり、ｘＰＵＣＣＨのオーバヘッドと性能／範囲のバランスをとるために、ｘＰＵＣＣＨ２３０はスケーラブルである必要がある。そのため、サブフレームが含むｘＰＵＣＣＨシンボル（例えば、ＯＦＤＭシンボル）の数が可変である必要がありうる。一方で、リソース要素／サブキャリアの割当数に関して、各ｘＰＵＣＣＨリソースはスケーラブルである必要がある。これにより、ｘＰＵＣＣＨペイロードが可変となり、処理ゲイン量が調整可能となる（インタフェースが限られた場合に有利である）。さらに、特定のＵＬビーム同士が互いに空間的に良好に分離可能となりうる。したがって、単一のｘＰＵＣＣＨシンボルで、複数のＵＥ／ビームに対して同一のｘＰＵＣＣＨリソース要素が利用可能となりうる（これは、ｘＰＵＣＣＨに対するマルチユーザＭＩＭＯとみなせる）。最後に、ｘＰＵＣＣＨ２３０を送信するＵＥ間で、利用可能な受信機Ｒｘビームをどのように共有するかの定義は、ｅＮＢ１７０次第である。例えば、ｅＮＢ１７０は単一のビームのみを基地局近傍のＵＥに、２つ以上のビームをセルの端のＵＥに割り当ててもよい。

上記に基づいて、本発明者らは、ｘＰＵＣＣＨリソースが時間、周波数、そして「空間的」にスケーラブルであるべきであると考える。ここで２つの課題が生じる。ｅＮＢの実施により限定されるハイブリッド・ビームフォーミング・アーキテクチャの性能についてと、ｘＰＵＣＣＨリソースをいかにして割り当てるかということである。

ハイブリッド・ビームフォーミング・アーキテクチャの性能は、ｅＮＢの実施により限定される。これを以下に述べる。狭いＲＦビームは一度に一方向にしか対応できない。したがって、各ＵＥは通常それ専用のビームリソースを要する。例えば、ｘＰＵＣＣＨ多重化性能／シンボルは、受信機ＲＦビーム数により限定される。さらに、ｘＰＵＣＣＨの性能を十分に引き出すには、少なくとも２つ（例えば、Ｘ−ｐｏｌ）の受信機ＲＦビームを、ｘＰＵＣＣＨを送信する単一のＵＥに割り当てることが妥当であろう。実際（少なくとも、ｘＰＵＣＣＨのサイズを考えると）、ＵＥ／シンボルの数は、受信機ＲＦビームの数の半分に等しい。ｅＮＢ１７０で利用可能な受信機ＲＦビームの数は、実施によって決まる。一方、ｘＰＵＣＣＨ２３０を介してｘＰＤＳＣＨＨＡＲＱ−ＡＣＫを送信するＵＥ１７０の数は、ｅＮＢスケジューラの判断次第で変わる。要は、ＵＬ制御プレーンがハイブリッド・ビームフォーミング・アーキテクチャのボトルネックの一つとなりうるのである。

ｘＰＵＣＣＨリソースの割り当て方について、これらリソースは、ｘＰＵＣＣＨオーバヘッドと、ＨＡＲＱ−ＡＣＫフィードバックレイテンシが柔軟にトレードオフでき、ｘＰＵＣＣＨリソース割当を最小限にできるようにしつつ、ＲＥ／チャネルに関するスケーラブルリソースサイズ、異なるＲｘビーム間のスケーラブルマルチユーザＭＩＭＯペアリング、スケーラブルリソースサイズのｘＰＵＣＣＨシンボル／セルの数、スケーラブルペイロード／チャネル、および／または受信機におけるスケーラブルなＲｘビームの数を維持できるように割り当てられるべきである。

これらにどう対処するかを以下に述べる。その前に、いくつかの導入説明を加える。

［導入説明：ＬＴＥＴＤＤにおけるＨＡＲＱ−ＡＣＫタイミング］

現行のシステム（ＵＣＩサブシステムを含む）は、デジタルアーキテクチャ用に定義されており、ｘＰＤＳＣＨ２２０とｘＰＵＣＣＨ２３０との間のＨＡＲＱ−ＡＣＫタイミングは固定されている。当該システムの一例としてのＬＴＥＴＤＤを以下に説明する。

ＬＴＥにおけるＨＡＲＱ−ＡＣＫフィードバック構成を考える際に、図３に示す表の、ダウンリンクアソシエーションセットの概念を理解することが有効であろう。併せて、例えば３ＧＰＰＴＳ３６．２１３Ｖ１２．８．０（２０１５−１２）の表１０.１.３.１−１も参照されたい。図３のＤＬアソシエーションセットは、各ＵＬサブフレームｎに対して、各ＤＬ／特殊サブフレームに対してＨＡＲＱフィードバックが送信されるタイミングと順序を定義する。すなわち、ＵＬ−ＤＬ構成＃０の場合、ＵＬサブフレーム＃ｎ＝２において、ＰＵＣＣＨは６サブフレーム前のＤＬサブフレームに対するＨＡＲＱ−ＡＣＫを運んでもよい。すなわち、この場合ＨＡＲＱ遅延が６サブフレームとなる。同様に、ＵＬ−ＤＬ構成＃１の場合、ＵＬサブフレーム＃２において、ＨＡＲＱ−ＡＣＫは７および／または６サブフレーム前のＤＬサブフレームに対してシグナリングされてもよく、ＰＵＣＣＨリソースはこの特定の順序で埋まる（ＤＬサブフレームｎ−７、その後ＤＬサブフレームｎ−６に対して第１のＨＡＲＱ−ＡＣＫ）。言い換えると、図３の表は、各ＤＬサブフレームに対応付けられたＨＡＲＱ−ＡＣＫフィードバック遅延（ミリ秒単位）を示す。図示のように、遅延の範囲は４ｍｓから１３ｍｓである。

スケーラブルＨＡＲＱ−ＡＣＫタイミングによるいくつかの実施を、MulteFire（無認可帯域におけるＬＴＥ単独動作）の文脈で議論されている。MulteFireアライアンスのシナリオでは、ＨＡＲＱ−ＡＣＫフィードバックがＤＬＴｘバースト直後に配置された短ＰＵＣＣＨに主に基づく（図４を参照）。図４において、１つのＤＬＴｘバーストにサブフレーム２１０−１から２１０−５が含まれ、別のＤＬＴｘバーストに３つのサブフレーム２１０−６から２１０−８が含まれる。サブフレーム２１０−１および２１０−２におけるＰＤＳＣＨ３４０に対するＨＡＲＱ−ＡＣＫ情報は、ダイナミックｓＰＵＣＣＨ３３０−１により報告される。サブフレーム２１０−３および２１０−５におけるＰＤＳＣＨ３４０に対するＨＡＲＱ−ＡＣＫ情報は、ダイナミックｓＰＵＣＣＨ３３０−２により報告される。ＰＤＣＣＨ３２０は、各サブフレーム２１０の一部としても示される。

別のＨＡＲＱ−ＡＣＫフィードバック構成として、ｅＮＢによりトリガされるいわゆるｅＰＵＣＣＨを使用することが挙げられる。ｅＰＵＣＣＨの目的は、例えば、ネガティブＬＢＴにより、特定のＵＥが通常のｓＰＵＣＣＨでＨＡＲＱ−ＡＣＫを送信できなかった等の理由でペンディングしたＨＡＲＱ−ＡＣＫを、ｅＮＢがポーリングする機会を与えることである。

［例示的実施の概要］

以下に、フレキシブルなｘＰＵＣＣＨリソース割当方式を提案する。例示的に提案する割当方式では、ｘＰＵＣＣＨに対するサブフレーム割当と、ｘＰＵＣＣＨサブフレーム内のリソース割当が網羅される。ｘＰＵＣＣＨに対するサブフレーム割当およびリソース割当は、例えばＤＬグラントにおける１つ以上の情報要素として表される。

［例示的実施概要：ｘＰＵＣＣＨに対するサブフレーム割当］

サブフレーム割当についてさらなる解説を加える前に、まずは図５、図６について導入説明を行う。サブフレームは、ｘＰＵＳＣＨの送信にも対応しうる（図２に示すとおり）が、この例ではＤＬに重点を置いたシナリオのみ考える（このほうがｘＰＵＣＣＨシグナリング的にはより重要なのである）。図５は、リソース最適化割当（ＵＥ／ｅＮＢ処理時間は約２サブフレームとする）を示す。大きな矢印５５０は、ｘＰＤＣＣＨを使用したｘＰＵＣＣＨスケジューリングを示し、小さな矢印５６０は、ｘＰＤＣＣＨを使用したｘＰＤＳＣＨスケジューリングを示す。１１のサブフレーム２１０−１から２１０−１１が示されている。ほとんどのサブフレーム２１０についてＰＤＳＣＨＨＡＲＱプロセスＩＤ５１０が示されている。各サブフレーム２１０はｘＰＤＣＣＨ２２０とｘＰＤＳＣＨ２４０とを含む。サブフレーム２１０−３（ＰＤＳＣＨＨＡＲＱプロセスＩＤ５１０の１とする）、サブフレーム２１０−７（ＰＤＳＣＨＨＡＲＱプロセスＩＤ５１０の５とする）、サブフレーム２１０−１１（ＰＤＳＣＨＨＡＲＱプロセスＩＤ５１０の１とする）は、ｘＰＵＣＣＨ２３０を含む。ｘＰＵＳＣＨ２５０を含むサブフレーム２１０は図示されていない。ＨＡＲＱ−ＡＣＫのバンドリングウィンドウ（bundling window）長５２０は４である。これは、同じｘＰＵＣＣＨサブフレームにマッピングされるＤＬサブフレームの数に対応する。特定のバンドリングウィンドウにおけるサブフレームは、時間的に不連続であってもよい（例えば、ｘＰＵＳＣＨサブフレームを挟んでもよい）。さらに、図６に示すようにバンドリングウィンドウにおけるｘＰＤＳＣＨＨＡＲＱプロセスは連続していなくてもよいことも付言する。ＨＡＲＱプロセスは、０から（Ｋ−１）の間の任意のＨＡＲＱプロセスであってもよい。Ｋとは、ＵＥが対応する、および／またはＵＥ用に構成されるＨＡＲＱプロセスの数である。ＰＤＳＣＨＲｘおよびｘＰＵＣＣＨ準備用のＵＥ処理時間５３０は、２つのサブフレーム（この例では２１０−６、２１０−７）として示されており、ＨＡＲＱ−ＡＣＫＲｘおよびｘＰＤＣＣＨ／ｘＰＤＳＣＨ準備用のｅＮＢ処理時間５４０は、２つのサブフレーム（この例では２１０−８、２１０−９）として示されている。この図では、ｘＰＵＣＣＨタイミング標示（３）５７０−３、（２）５７０−２、（１）５７０−１、（０）５７０−０も示されている。

図６は、レイテンシ最適化割当（ＵＥ／ｅＮＢ処理時間は約２サブフレームとする）を示す。参照符号の多くは図５にも記載されており、これら図５と異なる点のみを説明する。図６において、８のサブフレーム２１０−１から２１０−８のみが示されている。この例において、ＨＡＲＱ−ＡＣＫバンドリングウィンドウ長５２０は１である。２つの大きな矢印５５０−１および５５０−２は、ｘＰＤＣＣＨを使用したｘＰＵＣＣＨスケジューリングを示し、小さな矢印５６０は、ｘＰＤＣＣＨを使用したｘＰＤＳＣＨスケジューリングを示す。２つのｘＰＵＣＣＨタイミング標示（０）５７０−０がそれぞれサブフレーム２１０−２と２１０−３とに対応する。ＰＤＳＣＨＲｘおよびｘＰＵＣＣＨ準備用のＵＥ処理時間５３０は、２つのサブフレーム（この例では２１０−３、２１０−４）として示されている。ＨＡＲＱ−ＡＣＫＲｘおよびｘＰＤＣＣＨ準備用のｅＮＢ処理時間５４０は、２つのサブフレーム（この例では２１０−５、２１０−６）として示されている。ｘＰＵＳＣＨ２５０を含むサブフレーム２１０は示されていない。

図５および図６について導入説明を行ったところで、例示的実施形態では、ｘＰＵＣＣＨは、ＤＬグラントに含まれる（例えばｘＰＤＣＣＨに含まれる）ｘＰＵＣＣＨタイミング標示ビット５７０によりトリガされる（図５および図６を参照）。ＤＬグラントは、ｘＰＤＳＣＨのスケジューリングに使用され、タイミング標示と同じサブフレームで送信される。さらに、別の例として、ｘＰＤＳＣＨに対するＤＬグラントを含むサブフレームと異なるサブフレームで、タイミング標示が送信されてもよい。例えば、各ＤＬグラント内に、２、３、または４つのｘＰＵＣＣＨタイミング標示ビットが含まれてもよい。必要なビット数は、ＤＬＨＡＲＱプロセスの（例えば最大）数に応じたものであってもよい。

別の例示的実施形態において、ｘＰＵＣＣＨタイミング標示５７０は、割り当てられたｘＰＤＣＣＨとｘＰＵＣＣＨとの間のサブフレームオフセットを示す。さらに、１つの値（例えば最高コードポイント）は、ｘＰＵＣＣＨサブフレームがｅＮＢによって定義されていないことを示してもよい。さらなるオプションを以下に示す。
・オプション＃１：オフセットがＵＥ処理時間を含まない。これは、図５、図６に示す例で想定されている。ｘＰＵＣＣＨのサブフレーム位置は、「ｘＰＤＣＣＨ／ｘＰＤＳＣＨを担うサブフレーム番号＋ｘＰＵＣＣＨタイミング標示５７０ビットによって定義されるオフセット＋ＵＥ処理時間」によって得られる。例えば、図５において、ＳＦＮがサブフレーム２１０−２に対して１つ（１）とする。したがって、サブフレーム２１０−１に対してｘＰＵＣＣＨのサブフレーム位置は、「ｘＰＤＣＣＨ／ｘＰＤＳＣＨを担うサブフレーム番号（１）＋ｘＰＵＣＣＨタイミング標示５７０ビットによって定義されるオフセット（３）＋ＵＥ処理時間（２）＝１＋３＋２＝６」によって得られる。ＳＦＮ＝６のサブフレームは、図５に示すサブフレーム番号２１０−７である。

ＵＥ処理時間はすべてのＵＥに対して共通のパラメータであってもよいし、あるいは処理時間はＵＥ性能／無線ベアラ／サービス関連パラメータであってもよい。後者の場合、初期アクセス（例えば、ＲＲＣ接続確立までの後続のｘＰＵＣＣＨ送信を含む）は、所定の（例えば従来の）値、すなわち３つまたは４つのサブフレームであってもよい。図５および図６は、ＵＥ処理時間が（約）２サブフレームとするものである。オプション＃１の利点として、シグナリング上、異なるＵＥ処理時間が把握できるという利点がある（例えば、ＵＥ性能に関わらず、標示に対するビット数は同じ）。
・オプション＃２：ｘＰＵＣＣＨタイミング標示５７０ビットによって定義されたオフセットはさらにＵＥ処理時間も含む。ｘＰＵＣＣＨのサブフレーム位置は、「ｘＰＤＣＣＨ／ｘＰＤＳＣＨを担うサブフレーム番号＋ｘＰＵＣＣＨタイミング標示ビットによって定義されたオフセット」によって得られる。

これらの提案された例示的技術により、ｅＮＢ１７０は、所望のｘＰＵＣＣＨ動作モードをダイナミックかつＵＥ固有の方法で選択できる（詳細については以下の例示的実施の項を参照）。ｘＰＵＣＣＨに対するサブフレーム割当は、サブフレーム内の非明示的ｘＰＵＣＣＨリソース割当の一部であってもよい（後述）。

［例示的実施概要：サブフレーム内のｘＰＵＣＣＨリソース割当］

ｘＰＵＣＣＨリソースに対して、非明示的リソース割当を提案する。これにより、（明示的リソース割当と比較して）ｘＰＤＣＣＨリソース消費を最小化できる。

これは、ｘＰＤＣＣＨとｘＰＵＣＣＨとが（実質的に）同じ物理リソース単位粒度とインデックス化方式に応じて定義されることを前提とする。「実質的」とは、ｘＰＵＣＣＨ（またはｘＰＤＣＣＨ）リソース単位サイズが、ｘＰＤＣＣＨ（またはｘＰＵＣＣＨ）と比較して２ｘ、３ｘ（または概してＮｘ）である場合も含みうるということである（ここで、「ｘ」はサイズが何倍になるかを示し、２ｘは２倍、３ｘは３倍、ＮｘはＮ倍となる）。

ｘＰＵＣＣＨの開始リソース単位インデックスは、対応するｘＰＤＣＣＨの所定のリソース単位から非明示的に導き出されうる。追加的な例を以下に示す。

一例として、ｘＰＤＣＣＨの最低リソース単位とｘＰＵＣＣＨの最低リソース単位とが一対一でマッピングされていてもよい（図７を参照）。図７において、サブフレーム２１０における各ｘＰＤＣＣＨリソース単位７１０（図では、その内のユニット７１０−０から７１０−２４が示されている）は、対応するｘＰＵＣＣＨリソース単位７２０（図では、その内のユニット７２０−１から７２０−２４が示されている）に対して一対一でマッピングされている。リソース単位７１０、７２０は周波数単位である。後述するように、ｅＮＢ１７０は異なる方策を利用してもよい。ｅＮＢ１７０は、例えば、ＨＡＲＱ−ＡＣＫバンドリングウィンドウにおいて、ｘＰＤＣＣＨ割当を変えなくてもよい。別の方策として、サブフレーム間の、ｘＰＤＣＣＨ／ｘＰＵＣＣＨ負荷状況に応じて、割当を変えてもよい。

別の例として、ｘＰＵＣＣＨが複数のサブフレームに対してＨＡＲＱ−ＡＣＫを網羅する場合、ｘＰＵＣＣＨにおけるリソースが、所定のサブフレーム（例えば、ＨＡＲＱ−ＡＣＫバンドリングウィンドウにおいて最後に受信したサブフレーム、またはｘＰＵＣＣＨタイミング標示値が最小のサブフレーム）と、対応する最低ｘＰＤＣＣＨリソース単位に応じて求められてもよい。

さらなる例として、ｘＰＵＣＣＨ／ｘＰＤＣＣＨはインデックス化方式を利用する。それにより、複数の物理リソース単位が割り当てられる場合に、ローカル割当が実現される。別のオプションとして、分散割当を実現するインデックス化方式を利用してもよい。例えば、ｅＮＢ１７０はｘＰＤＣＣＨ（異なるタイミング標示値による）と、関連するｘＰＤＳＣＨを別々にスケジューリングしてもよい。これによりｘＰＤＣＣＨリソース要素は変化してもしなくてもよい。したがって、ｘＰＤＣＣＨによるｘＰＤＳＣＨスケジューリングに関連した（１または複数の）所定のルールに基づいて、ＵＥ１１０は（１または複数の）ｘＰＵＣＣＨリソース（非明示的リソース割当の場合）を求める（例えば、ルールに応じて、最小のＰＵＣＣＨタイミング標示値のｘＰＤＳＣＨのサブフレームが、少なくともそのサブフレームからの応答情報にどのｘＰＵＣＣＨリソースが使用されるかを示す）。ＵＥが最後のｘＰＤＣＣＨを適切に検出しなかった場合、それに応じて関連するｘＰＵＣＣＨリソースは変化してもよい。ｅＮＢ１７０は、複数のｘＰＵＣＣＨリソースを平行して監視してもよいし、ｘＰＤＣＣＨ検出に関して生じうる（１または複数の）シグナリングエラーを検出できる。

さらなる例として、ｘＰＤＣＣＨ／ｘＰＵＣＣＨのローカル割当により、周波数領域パケットスケジューリング（Frequency Domain Packet Scheduling：ＦＤＰＳ）ゲインがｘＰＤＣＣＨとｘＰＵＣＣＨの両方で向上する。言い換えると、ｅＮＢ１７０がチャネル知識に基づいて「最高の」周波数領域リソースにおけるｘＰＤＣＣＨを割り当てると、それに応じてＦＤＰＳゲインによりｘＰＵＣＣＨが恩恵を受ける。特に、ＵＬとＤＬの両方が同様のリソース単位（周波数）を有するとの考え方である。別の課題は、ＴＤＤシステムに関するものである。すなわち、当該システムにおける無線チャネルは、恩恵が双方向で得られる性質を持つべきということである。これは、少なくとも干渉（ＵＬおよびＤＬの間で同等ではない）を無視した場合、ｅＮＢが特定のＵＥについて良好と判断した特定のリソース単位は、ＤＬ（ｘＰＤＣＣＨ）およびＵＬ（ｘＰＵＣＣＨ）の両方で同等に良好なるべきであるということである。

ｘＰＵＣＣＨリソース単位に関するリソースサイズは、ｘＰＤＣＣＨで明示的にシグナリングされてもよい。これにより、例えば２つまたは３つのビットが網羅される。

１つのオプションとして、ｘＰＵＣＣＨリソース単位に関するリソースサイズは、ｘＰＤＣＣＨで使用されるアグリゲーションレベル（aggregation level、複数可）に依存しうる。これを次の例で説明する。さらに、複数のｘＰＵＣＣＨリソース単位が、１または複数のｘＰＵＣＣＨシンボルにマッピングされてもよい。

例えば、ＰＤＣＣＨのアグリゲーションレベルが２以上であれば、追加的なｘＰＵＣＣＨシンボルが非明示的にｘＰＵＣＣＨに割り当てられる。例えば４のような所定のｘＰＤＣＣＨアグリゲーションレベルの場合、ＰＤＣＣＨリソース要素に基づいて上述のように周波数領域マッピングが求められるｘＰＵＳＣＨリソースで実行される、長いｘＰＵＣＣＨフォーマットが非明示的に割り当てられてもよい。「長い」という表現は、ｘＰＵＣＣＨリソース単位が複数のｘＰＵＣＣＨシンボルにマッピングされるシナリオ（例えば、範囲拡大のため）を含んでもよい。また、ここでの周波数領域マッピングは、ｘＰＤＣＣＨ周波数領域リソースから求められたｘＰＵＣＣＨに対してどのように周波数領域リソースを割り当てるかについての上述の方法を再利用する。ここで、ｘＰＤＣＣＨアグリゲーションレベルが時間に依存して割り当てられることも考えるべきである。さらなるオプションとして、ｘＰＤＣＣＨに使用されるアグリゲーションレベルに基づいて周波数領域においてリソースを割り当てることが挙げられる。これにより、ｘＰＵＣＣＨの符号化レートが下がり、干渉に対する強度が上がる。これらいずれのオプションも利用可能であることから、時間および／または周波数の単位において、ｘＰＤＣＣＨアグリゲーションレベルに基づくｘＰＵＣＣＨリソース割当を実行できる。

別の例として、概して、ｘＰＵＣＣＨに対するリソース割当は、ｘＰＤＣＣＨアグリゲーションレベルに対応付けられてもよい（例えば、この特徴はＢＳにより、ＲＲＣレベル構成等に応じて、ＯＮ／ＯＦＦされるものであってもよい）。ｘＰＤＣＣＨに対する特定の（１または複数の）アグリゲーションレベルにより、ｘＰＵＣＣＨペイロードサイズの上限が非明示的に設けられてもよい。一例では、ＵＥ１１０はＣＳＩレポート（例えばペイロードが大きい場合）を送信する場合、ｘＰＤＣＣＨに使用される高いアグリゲーションレベルにより、ＵＥに例えばｘＰＵＣＣＨからＣＳＩを外すか、アップリンク制御に非明示的にＵＥｘＰＵＳＣＨリソースを割り当てるように強制してもよい。

［例示的実施］

以下の代替例に示すように、ｅＮＢ１７０は、ｘＰＵＣＣＨタイミング標示ビットを利用して動作のｘＰＵＣＣＨモードをダイナミックかつＵＥ固有の方法で選択してもよい。
・代替例＃１：この代替例では、リソース最適化割当が実行される。ｘＰＵＣＣＨオーバヘッド／性能は、セル内で最適化できる（例えば、ＨＡＲＱ−ＡＣＫレイテンシを犠牲にする）。これについては図５を参照のこと。複数のＤＬサブフレームが単一のｘＰＵＣＣＨサブフレームにマッピングされる。多数のＤＬＨＡＲＱプロセスが必要とされる／消費される。
・代替例＃２：この代替案では、レイテンシ最適化割当が実行される。レイテンシ性能は、特定のＵＥ（複数可）に対して最適化できる。これについては図６を参照のこと。少数のＤＬサブフレーム（例えば１つのみ）が単一のｘＰＵＣＣＨサブフレームにマッピングされる。代替例＃１と比較して、必要とされる／消費されるＤＬＨＡＲＱプロセスの数がより少なくて済む。

したがって、ｅＮＢ１７０は２つのモードを、一方の代替例＃１に、他方を代替例＃２に使用できる。この２つのモードの切り替えは、例えば対応するダウンリンクサブフレームにおいて適切なタイミング標示を送信することで行う。

以下に、ｘＰＵＣＣＨリソース割当方式の一例を説明する。

ＤＬグラントにおけるｘＰＵＣＣＨリソース割当ビットは以下とおりであってもよい。
・例えばｘＰＵＣＣＨタイミング標示用に２から３ビット。
・例えばｘＰＵＣＣＨリソースサイズ用に２ビット（ｘＰＤＳＣＨから非明示的には求められない場合）。
・ダイナミックオフセット、例えば、１から２ビット（任意）。
・例えばｘＰＵＣＣＨ開始リソース単位に対して４から６ビット（ｘＰＤＣＣＨ開始リソースから非明示的に求められない場合）。

ＵＥ１１０は、対応するｘＰＤＣＣＨの最低リソース単位からｘＰＵＣＣＨの最低リソース単位を判定する（図７を参照）。ＤＬグラント内に、利用可能なさらなるオフセットがあってもよく、これによって、例えば最後のシンボルではなく、２番目から最後のｘＰＵＣＣＨシンボル間で開始位置が設定されるように開始リソース単位を所定の値だけ変化させる。その他オフセット値も利用できる。ｘＰＵＣＣＨは、ＤＬグラントによって定義される連続リソース単位数を占める。

ｘＰＵＣＣＨは、所定の送信方式を利用する。以下に一形態の例を示す。
・ＱＰＳＫモジュレーション。
・ＨＡＲＱ−ＡＣＫ、ＣＳＩ、ＳＲ（ＢＳＲ）の結合符号化、入力ビットの可変数（ＣＳＩが存在するかによる）。
・定義されたＤＬＨＡＲＱプロセスの数（＝ビットマップ）に基づく固定ＨＡＲＱ−ＡＣＫペイロード。
・未使用のＨＡＲＱプロセスは「ＮＡＣＫ」にマッピングされる。
・ＤＬグラントに含まれるＣＳＩトリガに応じたＣＳＩビット。
・８−ビットＣＲＣは常に含まれる（ロバストネス向上のため）。
・符号化方式によって定義される出力ビット数（例えば、テールバイティング畳み込み符号（１／３）適用）。
・出力ビットが、利用可能なｘＰＵＣＣＨリソース要素（ｘＰＵＣＣＨリソース単位の数によって定義される）の周りでレートマッチングされる。

図８は、ネットワークノードによって実行されるＰＵＣＣＨリソース割当の論理フローチャートである。この図により、例示的方法の動作、コンピュータ可読メモリに実装されたコンピュータプログラム命令の実行結果、ハードウェアで実現されるロジックによって実行される機能、および／または例示的実施形態に係る機能を実行するための相互接続手段が示される。図８のブロックは、ＲＲＨ１９５またはｅＮＢ１７０等のネットワークノードによって実現される。例えば、ＰＵＣＣＨＲＡモジュール１５０は、図８のブロックの内の複数を含んでもよい。含まれる各ブロックは、当該ブロックにおける機能を実行するための相互接続手段である。図８のブロックは、ネットワークノードによって、少なくとも部分的にＰＵＣＣＨＲＡモジュール１５０の制御下で実行されるものとする。

ブロック８１０では、ネットワークノードは、第１のサブフレームにおいて、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ユーザ端末に送信する。前記タイミング標示は、物理アップリンク制御チャネルにおいて、前記第１のサブフレームの前記ダウンリンク共有チャネルにおいて受信された前記データに対する応答情報を送信するために使用される第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す。ブロック８２０では、前記ネットワークノードは、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記ユーザ端末から前記応答情報を受信する。

なお、ここでは同じ（例えば第１の）サブフレーム内のタイミング標示およびデータの両方に最も重点を置く。しかし、ブロック８１５に示すとおり、前記ネットワークノード（例えば、ｅＮＢ１７０）は、１つの第１のサブフレームにおいてデータを送信し、別の第１のサブフレームにおいてタイミング標示を送信してもよい。一例では、ｘＰＤＣＣＨ（ＤＬグラント）からｘＰＤＳＣＨへの遅延は、通常１つ以上のサブフレームであるｘＰＤＣＣＨ（ＵＬグラント）からｘＰＵＳＣＨ（アップリンクデータ）の遅延と同一と定義される。しかし、ｘＰＤＳＣＨは、場合によってはｘＰＤＣＣＨ（ＤＬグラントおよびｘＰＵＣＣＨリソース割当、例えば、タイミング標示）と同じサブフレーム内になくてもよい。

さらに、「ユーザ端末」という用語は、１または複数のＵＥ１１０を指すものであってもよい。例えば、図８の方法は１または複数のＵＥ１１０に適用されてもよい。図５および／または図６の技術は、例えば状況や実施に応じて１または複数のＵＥ１１０に適用されてもよい。

以下に他の例を示す。これらの例では、図８に示す方法を例１と呼ぶ。

例２前記タイミング標示は、前記ユーザ端末に対する処理時間を含まない、例１の方法。

例３前記タイミング標示は、前記ユーザ端末に対する処理時間を含む、例１の方法。

例４前記送信することは複数の第１のサブフレームに対して実施され、前記複数の第１のサブフレームに対して対応するタイミング標示が修正されることで、前記ユーザ端末は前記複数の第１のサブフレームにおいて前記ユーザ端末が受信した前記データに対する応答情報に対して、同じ第２のサブフレームを計算して使用し、
前記受信することはさらに、前記ネットワークノードによって、前記複数の第１のサブフレームにおいて前記ユーザ端末が受信した前記データに対する前記応答情報に対して、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記ユーザ端末から前記応答情報を受信することを含む、例１から３のいずれかの方法。

例５前記受信することはさらに、前記ネットワークノードによって、前記第２のサブフレームの前記物理アップリンク制御チャネルの開始リソース単位インデックスに基づいて、前記ユーザ端末から前記応答情報を受信することを含み、
前記第２のサブフレームの前記物理アップリンク制御チャネルの前記開始リソース単位インデックスは、対応する前記物理ダウンリンク制御チャネルの所定のリソース単位から非明示的に求められる、例１から４のいずれかの方法。

例６前記受信することはさらに、前記ネットワークノードによって、前記第２のサブフレームの前記物理アップリンク制御チャネルのリソースにおいて、前記ユーザ端末から前記応答情報を受信することを含み、
前記第２のサブフレームの前記物理アップリンク制御チャネルの前記リソースの位置は、所定のサブフレームおよび対応する最低物理ダウンリンク制御チャネルリソース単位に応じて求められる、例１から４のいずれかの方法。

例７前記所定のサブフレームは、前記ユーザ端末によってＨＡＲＱ−ＡＣＫバンドリングウィンドウにおいて最後に受信されたサブフレームと、前記タイミング標示の値が最小のサブフレームの内の一方である、例６の方法。

例８前記物理アップリンク制御チャネルのリソース単位に関するシグナリングリソースサイズを前記ネットワークノードから受信することをさらに含み、
前記受信することはさらに、前記ネットワークノードによって、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記物理アップリンク制御チャネルの前記リソース単位に関する前記リソースサイズに基づいて、前記ユーザ端末から前記応答情報を受信することを含む、例１から７のいずれかの方法。

例９前記第１のサブフレームはそれぞれ物理ダウンリンク制御チャネルを含み、
前記第２のサブフレームの前記物理アップリンク制御チャネルにおける前記ユーザ端末からの前記応答情報は、前記物理アップリンク制御チャネルにおけるリソース単位に関するリソースサイズを使用し、
前記リソースサイズは、前記物理ダウンリンク制御チャネルに使用される１つ以上のアグリゲーションレベルに依存する、例１から８のいずれかの方法。

例１０前記物理ダウンリンク制御チャネルに対する前記アグリゲーションレベルが２以上であれば、前記物理アップリンク制御チャネルに対して、追加的な物理アップリンク制御チャネルシンボル、および／または追加的なリソース要素が非明示的に割り当てられる、例９の方法。

例１１前記物理アップリンク制御チャネルに対するリソース割当が、物理ダウンリンク制御チャネルのアグリゲーションレベルに対応付けられる、例９の方法。

例１２前記物理ダウンリンク制御チャネルに対する１つ以上のアグリゲーションレベルの内の所定のものによっても、前記物理アップリンク制御チャネルに対するペイロードサイズの上限が非明示的に設定される、例１１の方法。

例１３前記物理アップリンク制御チャネルの前記応答情報に対して使用されるリソース単位の割当は非明示的であり、
前記物理アップリンク制御チャネルの前記非明示的割当のリソース単位は、実質的に同じリソース単位粒度と、前記物理ダウンリンク制御チャネルおよび前記物理アップリンク制御チャネルの両方に適用されるインデックス化方式に基づく、例１から１２のいずれかの方法。

例１４前記非明示的割当は、前記物理ダウンリンク共有チャネルの、前記物理ダウンリンク制御チャネルに対するスケジューリングに関する１つ以上の所定のルールに基づく、例１３の方法。

例１に関するさらなる例として以下が挙げられる。前記例示的例のいずれか（例えば、例１〜１４）において、前記タイミング標示は、前記第１のサブフレームに対する前記オフセットが、前記ユーザ端末の性能、無線ベアラ、およびサービスの内の少なくとも１つに依存することを示す。本段落の方法において、タイミングに対する上位構成が確立されるまで、前記第１のサブフレームに対するオフセットを示す前記タイミング標示は、３つまたは４つのサブフレームの内の１つを含む共通パラメータに基づく。

前記例示的方法のいずれかにおいて、前記ネットワークノードは、ダウンリンクサブフレーム、アップリンクサブフレーム、および双方向サブフレームの間でサブフレームの種類を動的に変化させる。前記例示的方法のいずれかにおいて、前記物理アップリンク制御チャネルを担う直交周波数分割多重方式シンボルの数は、サブフレームごとに動的に変化する。前記例示的方法のいずれかにおいて、前記物理アップリンク制御チャネルのリソース単位に関するシグナリングリソースサイズを前記ネットワークノードから受信することをさらに有し、前記受信することは、前記ネットワークノードによって、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、この物理アップリンク制御チャネルのリソース単位に関するリソースサイズに基づいて、前記ユーザ端末から前記応答情報を受信することを含む。

図９は、ユーザ端末により実行されるＰＵＣＣＨリソース割当の論理フローチャートである。この図により、例示的方法の動作、コンピュータ可読メモリに実装されたコンピュータプログラム命令の実行結果、ハードウェアで実現されるロジックによって実行される機能、および／または例示的実施形態に係る機能を実行するための相互接続手段が示される。例えば、ＰＵＣＣＨＲＡモジュール１４０は、図９のブロックの内の複数を含んでもよい。含まれる各ブロックは、当該ブロックにおける機能を実行するための相互接続手段である。図９のブロックは、ＵＥ１１０により、少なくとも部分的にＰＵＣＣＨＲＡモジュール１４０の制御下で実行されるものとする。

ブロック９１０では、ＵＥ１１０は、第１のサブフレームにおいて、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ネットワークノードから受信する。前記タイミング標示は、物理アップリンク制御チャネルにおいて、前記第１のサブフレームにおいて受信された前記データに対する応答情報を送信するために使用される第２のサブフレームを決定するために前記ＵＥが使用すべき前記第１のサブフレームに対するオフセットを示す。ブロック９２０では、ＵＥ１１０は、少なくとも前記タイミング標示を使用して、前記第２のサブフレームを決定する。ブロック９３０では、ＵＥ１１０は、前記ネットワークノードに対して、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記応答情報を送信する。

図８と同様に、図９においても、同じ（例えば第１の）サブフレーム内のタイミング標示およびデータの両方に最も重点を置く。しかし、ブロック９１５に示すとおり、ＵＥ１１０は、１つの第１のサブフレームにおいてデータを受信し、別の第１のサブフレームにおいてタイミング標示を受信してもよい。上述のように、ｘＰＤＣＣＨ（ＤＬグラント）からｘＰＤＳＣＨへの遅延は、通常１つ以上のサブフレームであるｘＰＤＣＣＨ（ＵＬグラント）からｘＰＵＳＣＨ（アップリンクデータ）の遅延と同一と定義される。しかし、ｘＰＤＳＣＨは、場合によってはｘＰＤＣＣＨ（ＤＬグラントおよびｘＰＵＣＣＨリソース割当、例えば、タイミング標示）と同じサブフレーム内になくてもよい。

以下にさらなる例を示す。これらの例では、図９を例１５と呼ぶ。

例１６前記タイミング標示は、前記ユーザ端末に対する処理時間を含まず、
前記決定することは、式「前記第１のサブフレームのサブフレーム番号＋前記タイミング標示に対応する値によって定義されたオフセット＋前記ユーザ端末に対する前記処理時間」を用いて前記第２のサブフレームのサブフレーム番号を計算することを含み、
前記送信することは、当該式を使用して決定された前記第２のサブフレームの前記サブフレーム番号を有するサブフレームの前記物理アップリンク制御チャネルにおいて、前記応答情報を送信することを含む、例１５の方法。

例１７前記タイミング標示は、前記ユーザ端末に対する処理時間を含み、
前記決定することは、式「前記第１のサブフレームのサブフレーム番号＋前記タイミング標示に対応する値によって定義されたオフセット」を用いて前記第２のサブフレームのサブフレーム番号を計算することを含み、
前記送信することは、当該式を使用して決定された前記第２のサブフレームの前記サブフレーム番号を有するサブフレームの前記物理アップリンク制御チャネルにおいて、前記応答情報を送信することを含む、例１５の方法。

例１８前記受信することは複数の第１のサブフレームに対して実施され、前記複数の第１のサブフレームに対して対応するタイミング標示が修正され、
前記決定することはさらに、前記対応するタイミング標示に基づいて、前記複数の第１のサブフレームにおいて、前記ユーザ端末が受信する前記データに対する応答情報に対して同じ第２のサブフレームを計算して使用することを含み、前記対応するタイミング標示が修正されていることで、前記計算することで、同じ第２のサブフレームが得られ、
前記送信することはさらに、前記ユーザ端末によって、前記複数の第１のサブフレームにおいて前記ユーザ端末が受信した前記データに対する前記応答情報を、前記同じ第２のサブフレームの前記物理アップリンク制御チャネルにおいて送信することを含む、例１５から１７のいずれかの方法。

例１９前記決定することはさらに、前記第２のサブフレームの前記物理アップリンク制御チャネルの開始リソース単位インデックスを、対応する前記物理ダウンリンク制御チャネルの所定のリソース単位から非明示的に求めることを含み、
前記送信することはさらに、前記第２のサブフレームの前記物理アップリンク制御チャネルの前記開始リソース単位インデックスに基づいて、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて１つ以上のリソース単位の前記応答情報を送信することを含む、例１５から１８のいずれかの方法。

例２０前記決定することはさらに、所定のサブフレームおよび対応する最低物理ダウンリンク制御チャネルリソース単位に応じて、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、応答情報を送信するために使用されるリソースの場所を求めることを含み、
前記送信することはさらに、前記第２のサブフレームの前記物理アップリンク制御チャネルの前記リソースの前記求められた場所において、前記ユーザ端末から前記応答情報を送信することを含む、例１５から１８のいずれかの方法。

例２１前記所定のサブフレームは、前記ユーザ端末によってＨＡＲＱ−ＡＣＫバンドリングウィンドウにおいて最後に受信されたサブフレームと、前記タイミング標示の値が最小のサブフレームの内の一方である、例２０の方法。

例２２前記ユーザ端末によって、前記物理アップリンク制御チャネルのリソース単位に関するシグナリングリソースサイズを前記ネットワークノードから受信することをさらに含み、
前記送信することはさらに、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記物理アップリンク制御チャネルの前記リソース単位に関する前記リソースサイズに基づいて、前記ユーザ端末から前記応答情報を送信することを含む、例１５から２１のいずれかの方法。

例２３前記第１のサブフレームはそれぞれ物理ダウンリンク制御チャネルを含み、
前記送信することは、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記ユーザ端末から、前記物理アップリンク制御チャネルにおけるリソース単位に関するリソースサイズを使用して前記応答情報を送信することを含み、
前記リソースサイズは、前記物理ダウンリンク制御チャネルに使用される１つ以上のアグリゲーションレベルに依存する、例１５から２２のいずれかの方法。

例２４前記物理ダウンリンク制御チャネルに対する前記アグリゲーションレベルが２以上であれば、前記物理アップリンク制御チャネルに対して、追加的な物理アップリンク制御チャネルシンボル、および／または追加的なリソース要素が非明示的に割り当てられる、例２３の方法。

例２５前記物理アップリンク制御チャネルに対するリソース割当が、物理ダウンリンク制御チャネルのアグリゲーションレベルに対応付けられる、例２３の方法。

例２６前記物理ダウンリンク制御チャネルに対する１つ以上のアグリゲーションレベルの内の所定のものによっても、前記物理アップリンク制御チャネルに対するペイロードサイズの上限が非明示的に設定される、例２５の方法。

例２７前記物理アップリンク制御チャネルの前記応答情報に対して使用されるリソース単位の割当は非明示的であり、
前記物理アップリンク制御チャネルの前記非明示的割当のリソース単位は、実質的に同じリソース単位粒度と、前記物理ダウンリンク制御チャネルおよび前記物理アップリンク制御チャネルの両方に適用されるインデックス化方式に基づく、例１５から２６のいずれかの方法。

さらなる例として以下が挙げられる。上述の一方法（例えば、例１５〜２７）において、前記タイミング標示は、前記第１のサブフレームに対する前記オフセットが、前記ユーザ端末の性能、無線ベアラ、およびサービスの内の少なくとも１つに依存することを示す。本段落の方法において、タイミングに対する上位構成が確立されるまで、前記第１のサブフレームに対するオフセットを示す前記タイミング標示は、３つまたは４つのサブフレームの内の１つを含む共通パラメータに基づく。

前記例示的方法における一方法では、ダウンリンクサブフレーム、アップリンクサブフレーム、および双方向サブフレームの間でサブフレームの種類が動的に変化する。前記例示的方法における一方法では、前記物理アップリンク制御チャネルを担う直交周波数分割多重方式シンボルの数は、サブフレームごとに動的に変化する。前記例示的方法における一方法は、前記ユーザ端末によって前記ネットワークノードから、前記物理アップリンク制御チャネルのリソース単位に関するリソースサイズを受信することをさらに有し、前記送信することは、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、この物理アップリンク制御チャネルのリソース単位に関するリソースサイズに基づいて、前記ユーザ端末から前記応答情報を送信することをさらに有する。

例２８コンピュータプログラムであって、前記コンピュータプログラムがプロセッサ上で実行されると例１から２７のいずれかの方法を実施するコードを含む、コンピュータプログラム。

例２９前記コンピュータプログラムは、コンピュータとともに使用するために内部に実装されたコンピュータプログラムコードを有するコンピュータ可読媒体を含むコンピュータプログラムプロダクトである、例２８のコンピュータプログラム。

例３０少なくとも１つのプロセッサと、
コンピュータプログラムコードを含む少なくとも１つのメモリと、
を備える装置であって、
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサによって、例１から１４のいずれかの方法を前記装置に実施させるように構成される、装置。

例３１少なくとも１つのプロセッサと、
コンピュータプログラムコードを含む少なくとも１つのメモリと、
を備える装置であって、
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサによって、例１５から２７のいずれかの方法を前記装置に実施させるように構成される、装置。

例３２第１のサブフレームにおいてネットワークノードによって、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ユーザ端末に送信する手段と、
前記ネットワークノードによって、第２のサブフレームの物理アップリンク制御チャネルにおいて、前記ユーザ端末から応答情報を受信する手段と、
を備える装置であって、
前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームの前記ダウンリンク共有チャネルにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す、装置。

例３３例２から１４のいずれかの方法を実施する手段をさらに含む、例３２の装置。

例３４第１のサブフレームにおいてユーザ端末で、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ネットワークノードから受信する手段と、
前記ユーザ端末によって、少なくとも前記タイミング標示を使用して第２のサブフレームを決定する手段と、
前記ユーザ端末によって、前記第２のサブフレームの物理アップリンク制御チャネルにおいて、応答情報を前記ネットワークノードに対して送信する手段と、
を備える装置であって、
前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示す、装置。

例３５例１６から２７のいずれかの方法を実施する手段をさらに含む、例３４の装置。

例３６例３２または３３の装置および例３４または３５の装置のいずれかを含むシステム。

例３７例３２または３３の装置のいずれかを含む基地局。

例３８例３４または３５の装置のいずれかを含むユーザ端末。

後段の請求項の範囲、解釈、用途を一切狭めることなく、本明細書に開示の一例としての実施形態の内の１つ以上の技術的効果や利点は、ビームやハードウェアリソースが不十分なハイブリッドアーキテクチャにおけるＰＤＳＣＨ−ＨＡＲＱＡＣＫフィードバックシグナリングを効果的に支えるものである。本明細書に開示の一例としての実施形態の内の１つ以上のさらなる技術的効果や利点として、ｅＮＢが、レイテンシと、ｘＰＵＣＣＨオーバヘッドとの間のトレードオフを、各種要件（例えば、レイテンシ、ＵＥの種類等）に基づいて実行することが可能となる。本明細書に開示の一例としての実施形態の内の１つ以上のさらなる技術的効果や利点として、提案された技術により、リソース割当を明示的にシグナリングする必要性が最小限に抑えられる。本明細書に開示の一例としての実施形態の内の１つ以上のさらなる技術的効果や利点として、提案された技術により、さらにデジタルアーキテクチャに使用でき、送受信機に依存しないｘＰＵＣＣＨの設計としてみなすことができる。これは、５Ｇシステムが３ＧＨから７０ＧＨｚまでの広大な範囲内の様々なキャリア周波数で動作可能となるための、５Ｇ仕様の重要な部分と見られる。

本明細書に記載の実施形態は、ソフトウェア（１つ以上のプロセッサにより実行される）、ハードウェア（例えば、特定用途向け集積回路）、またはソフトウェアとハードウェアの組合せにおいて実施されてもよい。一例としての実施形態では、このソフトウェア（例えば、アプリケーション・ロジック、命令セット）は、従来型の各種コンピュータ可読媒体のいずれかに保持される。本明細書の文脈において、「コンピュータ可読媒体」は、命令実行システム、装置、またはコンピュータ等のデバイス（一例として、例えば、図１を参照して説明されたコンピュータが挙げられる）とともに、またはこれと関連して用いられる命令を包含し、記憶し、通信し、伝搬し、または送信することができる任意の媒体または手段であってもよい。コンピュータ可読媒体は、命令実行システム、装置、またはコンピュータ等のデバイスとともに、またはこれと関連して用いられる命令を包含し、記憶し、および／または送信することができる任意の媒体または手段でありうるコンピュータ可読記憶媒体（例えば、メモリ１２５、１５５、１７１、またはその他のデバイス）を備えてもよい。コンピュータ可読記憶媒体には、伝搬信号は含まれない。

必要に応じて、本明細書に記載された各機能は、記載されたのとは異なる順序でおよび／または互いに同時に実施することも可能である。さらに必要に応じて、上述の機能の１つ以上は任意選択であり、または組み合わされてもよい。

本発明の各種態様は独立請求項に規定されているが、本発明の別の態様には、記載された実施形態および／または従属請求項の特徴と独立請求項の特徴との異なる組合せも含まれ、これは請求項に明示的に示された組合せのみには限定されない。

本発明の一例としての実施形態を上述したが、これらの記載は限定的に解釈されるべきではない。むしろ、添付の特許請求の範囲に定義された本発明の範囲を逸脱することなく、様々な変更や変形が可能である。

本明細書および／または図面に用いられる可能性のある略語を、以下のとおり定義する。
４Ｇ：第４世代
５Ｇ：第５世代
ＡＣＫ：応答
ＢＳ：基地局
ＢＳＲ：バッファ・ステータス・レポート
ｃｍＷａｖｅ：センチメートル波
ＣＳＩ：（Channel State Information）チャネル状態情報
ＤＬ：ダウンリンク（ネットワークからユーザ端末へ）
ｅＮＢ（またはｅノードＢ）：進化ノードＢ（例えば、ＬＴＥ基地局）
ＦＤＰＳ：（Frequency Domain Packet Scheduling）周波数領域パケットスケジューリング
Ｇｂ／ｓ：ギガバイト／秒
ＨＡＲＱ：（Hybrid Automatic Repeat Request）ハイブリッド自動再送要求
ＩＤ：識別情報
Ｉ／Ｆ：インタフェース
ＫＰＩ：（Key Performance Indicator）重要評価指標
ＬＢＴ： Listen Before Talk（電波干渉回避技術）
ＬＴＥ：ロング・ターム・エボリューション
ＭＩＭＯ：（Multiple Input, Multiple Output）複数の入力、複数の出力
ＭＭＥ：モビリティ・マネジメント・エンティティ
ｍｍＷａｖｅ：ミリ波
ｍｓ：ミリ秒
ＮＣＥ：（Network Control Element）ネットワーク制御要素
Ｎ／Ｗ：ネットワーク
ＯＦＤＭ：（Orthogonal Frequency Division Multiplexing）直交周波数分割多重方式
ＰＤＣＣＨ：物理ダウンリンク制御チャネル
ＰＤＳＣＨ：物理ダウンリンク共有チャネル
ＰＵＣＣＨ：物理アップリンク制御チャネル
ＰＵＳＣＨ：物理アップリンク共有チャネル
ＲＡ：（Resource Allocation）リソース割当
ＲＥ：（Resource Element）リソース要素
ＲＦ：無線周波数
ＲＲＣ：（Radio Resource Control）無線リソース制御
ＲＲＨ：リモートラジオヘッド
ＲｘまたはＲＸ：受信機または受信
ＳＦＮ：サブフレーム番号
ＳＧＷ：サービング・ゲートウェイ
ｓＰＵＣＣＨ：短ＰＵＣＣＨ
ＳＲ：（Scheduling Request）スケジューリング要求
ＴＤＤ：（Time Division Duplexing）時分割二重化
ＴＳ：（Technical Standard）技術標準
ＴｘまたはＴＸ：送信機または送信
ＵＣＩ：（Uplink Control Information）アップリンク制御情報
ＵＥ：ユーザ端末（例えば無線デバイス、典型的にはモバイルデバイス）
ＵＬ：アップリンク（ユーザ端末からネットワークへ）
ｘＰＤＣＣＨ：５Ｇ以降の物理ダウンリンク制御チャネル
ｘＰＤＳＣＨ：５Ｇ以降の物理ダウンリンク共有チャネル
ｘＰＵＣＣＨ：５Ｇ以降の物理アップリンク制御チャネル
ｘＰＵＳＣＨ：５Ｇ以降の物理アップリンク共有チャネル
Ｘ−ｐｏｌ：（cross-polarized）交差偏波

Claims

第１のサブフレームにおいてネットワークノードによって、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ユーザ端末に送信することと、
前記ネットワークノードによって、第２のサブフレームの物理アップリンク制御チャネルにおいて、前記ユーザ端末から応答情報を受信することと、
を含む方法であって、
前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームの前記ダウンリンク共有チャネルにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示し、
前記送信することは複数の第１のサブフレームに対して実施され、前記複数の第１のサブフレームに対して対応するタイミング標示が修正されることで、前記ユーザ端末は前記複数の第１のサブフレームにおいて前記ユーザ端末が受信した前記データに対する応答情報に対して、同じ第２のサブフレームを計算して使用し、
前記受信することはさらに、前記ネットワークノードによって、前記複数の第１のサブフレームにおいて前記ユーザ端末が受信した前記データに対する前記応答情報に対して、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記ユーザ端末から前記応答情報を受信することを含む、
方法。
前記タイミング標示は、前記ユーザ端末に対する処理時間を含まない、請求項１に記載の方法。
前記タイミング標示は、前記ユーザ端末に対する処理時間を含む、請求項１に記載の方法。
前記タイミング標示は、前記第１のサブフレームに対する前記オフセットが、前記ユーザ端末の性能、無線ベアラ、およびサービスの内の少なくとも１つに依存することを示す、請求項１から３のいずれかに記載の方法。
タイミングに対する上位構成が確立されるまで、前記第１のサブフレームに対するオフセットを示す前記タイミング標示は、３つまたは４つのサブフレームの内の１つを含む共通パラメータに基づく、請求項４に記載の方法。
前記ネットワークノードは、ダウンリンクサブフレーム、アップリンクサブフレーム、および双方向サブフレームの間でサブフレームの種類を動的に変化させる、請求項１から５のいずれかに記載の方法。
前記物理アップリンク制御チャネルを担う直交周波数分割多重方式シンボルの数は、サブフレームごとに動的に変化する、請求項１から６のいずれかに記載の方法。
前記物理アップリンク制御チャネルのリソース単位に関するシグナリングリソースサイズを前記ネットワークノードから受信することをさらに有し、
前記受信することは、前記ネットワークノードによって、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、この物理アップリンク制御チャネルのリソース単位に関するリソースサイズに基づいて、前記ユーザ端末から前記応答情報を受信することを含む、請求項１から７のいずれかに記載の方法。
第１のサブフレームにおいてユーザ端末で、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ネットワークノードから受信することと、
前記ユーザ端末によって、少なくとも前記タイミング標示を使用して第２のサブフレームを決定することと、
前記ユーザ端末によって、前記第２のサブフレームの物理アップリンク制御チャネルにおいて、応答情報を前記ネットワークノードに対して送信することと、
を含む方法であって、
前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示し、
前記受信することは複数の第１のサブフレームに対して実施され、前記複数の第１のサブフレームに対して対応するタイミング標示が修正され、
前記決定することはさらに、前記対応するタイミング標示に基づいて、前記複数の第１のサブフレームにおいて、前記ユーザ端末が受信する前記データに対する応答情報に対して同じ第２のサブフレームを計算して使用することを含み、前記対応するタイミング標示が修正されていることで、前記計算することで、同じ第２のサブフレームが得られ、
前記送信することはさらに、前記ユーザ端末によって、前記複数の第１のサブフレームにおいて前記ユーザ端末が受信した前記データに対する前記応答情報を、前記同じ第２のサブフレームの前記物理アップリンク制御チャネルにおいて送信することを含む、
方法。
前記タイミング標示は、前記ユーザ端末に対する処理時間を含まず、
前記決定することは、式「前記第１のサブフレームのサブフレーム番号＋前記タイミング標示に対応する値によって定義されたオフセット＋前記ユーザ端末に対する前記処理時間」を用いて前記第２のサブフレームのサブフレーム番号を計算することを含み、
前記送信することは、当該式を使用して決定された前記第２のサブフレームの前記サブフレーム番号を有するサブフレームの前記物理アップリンク制御チャネルにおいて、前記応答情報を送信することを含む、請求項９に記載の方法。
前記タイミング標示は、前記ユーザ端末に対する処理時間を含み、
前記決定することは、式「前記第１のサブフレームのサブフレーム番号＋前記タイミング標示に対応する値によって定義されたオフセット」を用いて前記第２のサブフレームのサブフレーム番号を計算することを含み、
前記送信することは、当該式を使用して決定された前記第２のサブフレームの前記サブフレーム番号を有するサブフレームの前記物理アップリンク制御チャネルにおいて、前記応答情報を送信することを含む、請求項９に記載の方法。
前記タイミング標示は、前記第１のサブフレームに対する前記オフセットが、前記ユーザ端末の性能、無線ベアラ、およびサービスの内の少なくとも１つに依存することを示す、請求項９から１１のいずれかに記載の方法。
タイミングに対する上位構成が確立されるまで、前記第１のサブフレームに対するオフセットを示す前記タイミング標示は、３つまたは４つのサブフレームの内の１つを含む共通パラメータに基づく、請求項１２に記載の方法。
ダウンリンクサブフレーム、アップリンクサブフレーム、および双方向サブフレームの間でサブフレームの種類が動的に変化する、請求項９から１３のいずれかに記載の方法。
前記物理アップリンク制御チャネルを担う直交周波数分割多重方式シンボルの数は、サブフレームごとに動的に変化する、請求項９から１４のいずれかに記載の方法。
前記ユーザ端末によって前記ネットワークノードから、前記物理アップリンク制御チャネルのリソース単位に関するリソースサイズを受信することをさらに有し、
前記送信することは、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、この物理アップリンク制御チャネルのリソース単位に関するリソースサイズに基づいて、前記ユーザ端末から前記応答情報を送信することをさらに有する、請求項９から１５のいずれかに記載の方法。
装置の処理手段で実行されると、前記装置に、請求項１から１６のいずれかに記載の方法を実施するコードを含む、コンピュータプログラム。
第１のサブフレームにおいてネットワークノードによって、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ユーザ端末に送信する手段と、
前記ネットワークノードによって、第２のサブフレームの物理アップリンク制御チャネルにおいて、前記ユーザ端末から応答情報を受信する手段と、
を備える装置であって、
前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームの前記ダウンリンク共有チャネルにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示し、
前記送信することは複数の第１のサブフレームに対して実施され、前記複数の第１のサブフレームに対して対応するタイミング標示が修正されることで、前記ユーザ端末は前記複数の第１のサブフレームにおいて前記ユーザ端末が受信した前記データに対する応答情報に対して、同じ第２のサブフレームを計算して使用し、
前記受信することはさらに、前記ネットワークノードによって、前記複数の第１のサブフレームにおいて前記ユーザ端末が受信した前記データに対する前記応答情報に対して、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記ユーザ端末から前記応答情報を受信することを含む、
装置。
請求項２から８のいずれかに記載の方法を実施する手段をさらに含む、請求項１８に記載の装置。
第１のサブフレームにおいてユーザ端末で、ダウンリンク共有チャネルにおいてデータを、物理ダウンリンク制御チャネルにおいてタイミング標示を、ネットワークノードから受信する手段と、
前記ユーザ端末によって、少なくとも前記タイミング標示を使用して第２のサブフレームを決定する手段と、
前記ユーザ端末によって、前記第２のサブフレームの物理アップリンク制御チャネルにおいて、応答情報を前記ネットワークノードに対して送信する手段と、
を備える装置であって、
前記タイミング標示は、前記物理アップリンク制御チャネルにおいて、前記第１のサブフレームにおいて受信された前記データに対する前記応答情報を送信するために使用される前記第２のサブフレームを決定するために前記ユーザ端末が使用すべき前記第１のサブフレームに対するオフセットを示し、
前記送信することは複数の第１のサブフレームに対して実施され、前記複数の第１のサブフレームに対して対応するタイミング標示が修正されることで、前記ユーザ端末は前記複数の第１のサブフレームにおいて前記ユーザ端末が受信した前記データに対する応答情報に対して、同じ第２のサブフレームを計算して使用し、
前記受信することはさらに、前記ネットワークノードによって、前記複数の第１のサブフレームにおいて前記ユーザ端末が受信した前記データに対する前記応答情報に対して、前記第２のサブフレームの前記物理アップリンク制御チャネルにおいて、前記ユーザ端末から前記応答情報を受信することを含む、
装置。
請求項１０から１６のいずれかに記載の方法を実施する手段をさらに含む、請求項２０に記載の装置。
少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備える装置であって、前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサに実行されると、前記装置に、請求項１から８のいずれかに記載の方法を遂行させるように構成される、装置。
少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備える装置であって、前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサに実行されると、前記装置に、請求項９から１６のいずれかに記載の方法を遂行させるように構成される、装置。