JP2022519123A

JP2022519123A - 通信システム

Info

Publication number: JP2022519123A
Application number: JP2021544871A
Authority: JP
Inventors: キャロラインケンイリャン，; ロバートアーノット，
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2019-02-15
Filing date: 2020-01-29
Publication date: 2022-03-18
Also published as: GB201902166D0; WO2020166334A1; US20220123875A1; GB2581391A; JP2023171855A; EP3925122A1

Abstract

通信システムが開示されており、ＵＥ（ｕｓｅｒｅｑｕｉｐｍｅｎｔ：ユーザ装置）は、シンボル又はサブスロットレベルでダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックを送信するために用いられる少なくとも１つの通信リソースを示すＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を、前記ダウンリンクデータが送信されるタイミングウィンドウがスロット長よりも短いか長いかを示すために用いられる第１のＤＣＩフォーマット及び第２のＤＣＩフォーマットのうちの少なくとも１つに従って、受信する。ＵＥは、前記タイミングウィンドウの間にダウンリンクデータを受信し、示された少なくとも１つの通信リソースを用いて、対応するＨＡＲＱ－ＡＣＫを送信する。【選択図】図１

Description

本発明は、３ＧＰＰ（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ：第３世代パートナーシッププロジェクト）規格又は等価物若しくはその派生物に従って動作する無線通信システム及びその装置に関する。本開示は、いわゆる「５Ｇ」（あるいは「ＮｅｘｔＧｅｎｅｒａｔｉｏｎ」）システムにおける、超信頼性低遅延通信に関する改良に特に関連するが、これに限定するものではない。

３ＧＰＰ規格の最新の発展は、ＭＴＣ（ＭａｃｈｉｎｅＴｙｐｅＣｏｍｍｕｎｉｃａｔｉｏｎｓ：マシンタイプコミュニケーション）、ＩｏＴ（ＩｎｔｅｒｎｅｔｏｆＴｈｉｎｇｓ：モノのインターネット）通信、車両通信及び自律走行車、高解像度ビデオストリーミング、スマートシティサービスなどの様々なアプリケーション及びサービスをサポートすることが期待される、進化する通信技術を指し示す、いわゆる「５Ｇ」又は「ＮＲ」（ＮｅｗＲａｄｉｏ）規格である。３ＧＰＰは、いわゆる３ＧＰＰのＮｅｘｔＧｅｎ（ＮｅｘｔＧｅｎｅｒａｔｉｏｎ：次世代）ＲＡＮ（ｒａｄｉｏａｃｃｅｓｓｎｅｔｗｏｒｋ：無線アクセスネットワーク）及び３ＧＰＰのＮＧＣ（ＮｅｘｔＧｅｎｃｏｒｅ：次世代コア）ネットワークを通じて、５Ｇをサポートすることを意図している。５Ｇネットワークの様々な詳細は、例えば、ＮＧＭＮ（ＮｅｘｔＧｅｎｅｒａｔｉｏｎＭｏｂｉｌｅＮｅｔｗｏｒｋｓ）アライアンスによる「ＮＧＭＮ５ＧＷｈｉｔｅＰａｐｅｒ：ＮＧＭＮ５Ｇ白書」Ｖ１．０に記載されており、その文献はhttps://www.ngmn.org/5g-white-paper.htmlから入手可能である。

エンドユーザ通信装置は、一般にＵＥ（ｕｓｅｒｅｑｕｉｐｍｅｎｔ：ユーザ装置）と呼ばれ、人間によって操作されてもよいし、自動化された（ＭＴＣ／ＩｏＴ）装置を備えていてもよい。５Ｇ／ＮＲ通信システムの基地局は、一般に、「ＮＲ－ＢＳ」（ＮｅｗＲａｄｉｏＢａｓｅＳｔａｔｉｏｎ：ＮＲ基地局）又は「ｇＮＢ」と呼ばれるが、それらは、より典型的には、ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ：ロングタームエボリューション）基地局（一般に「４Ｇ」基地局とも呼ばれる）に関連付けられた用語「ｅＮＢ」（又は５Ｇ／ＮＲｅＮＢ）を用いて呼ばれることもあるということが理解される。３ＧＰＰＴＳ（ＴｅｃｈｎｉｃａｌＳｐｅｃｉｆｉｃａｔｉｏｎ：技術仕様書）３８．３００Ｖ１５．４．０及びＴＳ３７．３４０Ｖ１５．４．０は、とりわけ、以下のノードを定義する。
ｇＮＢ：ＵＥにＮＲユーザプレーン及び制御プレーンプロトコルの終端を提供し、ＮＧインタフェースを介して５ＧＣ（５Ｇｃｏｒｅｎｅｔｗｏｒｋ：５Ｇコアネットワーク）に接続されるノード。
ｎｇ－ｅＮＢ：ＵＥにＥ－ＵＴＲＡ（ＥｖｏｌｖｅｄＵｎｉｖｅｒｓａｌＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓ）ユーザプレーン及び制御プレーンプロトコルの終端を提供し、ＮＧインタフェースを介して５ＧＣに接続されるノード。
Ｅｎ－ｇＮＢ：ＵＥにＮＲユーザプレーン及び制御プレーンプロトコルの終端を提供し、ＥＮ－ＤＣ（Ｅ－ＵＴＲＡ－ＮＲＤｕａｌＣｏｎｎｅｃｔｉｖｉｔｙ：デュアルコネクティビティ）におけるセカンダリノードとして動作するノード。
ＮＧ－ＲＡＮノード：ｇＮＢ又はｎｇ－ｅＮＢの何れか。

３ＧＰＰは、また、隣接するＮＧ－ＲＡＮノード間のネットワークインタフェースとして、いわゆる「Ｘｎ」インタフェースも定義している。

次世代のモバイルネットワークは、ＩＴＵ（ＩｎｔｅｒｎａｔｉｏｎａｌＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎＵｎｉｏｎ：国際電気通信連合）によって、ｅＭＢＢ（ＥｎｈａｎｃｅｄＭｏｂｉｌｅＢｒｏａｄｂａｎｄ：エンハンストモバイルブロードバンド）、ＵＲＬＬＣ（Ｕｌｔｒａ－ＲｅｌｉａｂｌｅａｎｄＬｏｗ－ＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性低遅延通信）、及びｍＭＴＣ（ＭａｓｓｉｖｅＭａｃｈｉｎｅＴｙｐｅＣｏｍｍｕｎｉｃａｔｉｏｎｓ：大規模マシンタイプ通信）の３つのカテゴリーに分類されている、多様化するサービス要件をサポートする。ｅＭＢＢは、ＨＤ（ＨｉｇｈＤｅｆｉｎｉｔｉｏｎ：高解像度）ビデオ、ＶＲ（ＶｉｒｔｕａｌＲｅａｌｉｔｙ：仮想現実）、及びＡＲ（ＡｕｇｍｅｎｔｅｄＲｅａｌｉｔｙ：拡張現実）など、広域で且つ保証された帯域幅を必要とするサービスに重点を置いて、従来のモバイルブロードバンドのサポートを強化することを目的としている。ＵＲＬＬＣは、自動運転やファクトリオートメーションなど、まさに短時間でのアクセスを保証することを必要とする重要なアプリケーションのための要件である。ＭＭＴＣは、スマートメータリングや環境モニタリングなどの莫大な数の接続装置をサポートする必要があるが、通常、ある程度のアクセス遅延を許容することができる。これらのアプリケーションのいくつかは、比較的緩やかなＱｏＳ／ＱｏＥ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ／ＱｕａｌｉｔｙｏｆＥｘｐｅｒｉｅｎｃｅ：サービス品質／体感品質）要件を有することもあれば、その一方でいくつかのアプリケーションは、比較的厳格なＱｏＳ／ＱｏＥ要件（例えば、高帯域及び／又は低遅延）を有することもある、ということが理解される。

ＰＵＣＣＨ（ＰｈｙｓｉｃａｌＵｐｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ：物理アップリンク制御チャネル）は、ＵＣＩ（ＵｐｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：アップリンク制御情報）と呼ばれる１組の情報を伝送する。ＰＵＣＣＨのフォーマットは、ＵＣＩがどのような種類の情報を伝送するのかに依存する。用いられるＰＵＣＣＨフォーマットは、どれだけのビットの情報を伝送しなければならないか、及びどれだけのシンボルが割り当てられるかによって決定される。ＮＲ（５Ｇ）において用いられるＵＣＩは、ＣＳＩ（ＣｈａｎｎｅｌＳｔａｔｅＩｎｆｏｒｍａｔｉｏｎ：チャネル状態情報）、ＡＣＫ／ＮＡＫ、及びＳＲ（ＳｃｈｅｄｕｌｉｎｇＲｅｑｕｅｓｔ：スケジューリング要求）の情報のうちの１つ以上を含む。これは、ＬＴＥ（４Ｇ）と概ね同じである。

（時間領域及び周波数領域における）ＰＵＣＣＨの位置は、ＰＵＣＣＨを伝送するリソースセットの位置によって決定される。具体的には、ＰＵＣＣＨリソースセットの位置は、その開始ＰＲＢ（ＰｈｙｓｉｃａｌＲｅｓｏｕｒｃｅＢｌｏｃｋ：物理リソースブロック）、その開始シンボル、ＰＲＢの数、及び用いられるシンボルの数に基づいて決定される。

更に、ＵＥが専用のＰＵＣＣＨリソース構成を有する場合、ＵＥは、１つ以上のＰＵＣＣＨリソースを持つ上位層によって提供される。各ＰＵＣＣＨリソースは、以下のパラメータを含む。
・上位層パラメータｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＩｄによって提供されるＰＵＣＣＨリソースインデックス、
・上位層パラメータｓｔａｒｔｉｎｇＰＲＢによる周波数ホッピング前の又は周波数ホッピングなし場合の第１のＰＲＢのインデックス、
・上位層パラメータｓｅｃｏｎｄＨｏｐＰＲＢによる周波数ホッピング後の第１のＰＲＢのインデックス、
・上位層パラメータｉｎｔｒａＳｌｏｔＦｒｅｑｕｅｎｃｙＨｏｐｐｉｎｇによるスロット内周波数ホッピングの指示、及び
・上位層パラメータフォーマットによって提供されるＰＵＣＣＨフォーマット０からＰＵＣＣＨフォーマット４までのＰＵＣＣＨフォーマットの構成。

３ＧＰＰＴＳ３８．２１３のセクション９．２．３は、ＤＣＩフォーマット１＿０について、ＮＲＲｅｌｅａｓｅ－１５において、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱ－ｔｉｍｉｎｇ－ｉｎｄｉｃａｔｏｒフィールド値が｛１、２、３、４、５、６、７、８｝にマッピングされる、ということを規定している。ＤＣＩフォーマット１＿１について、もし存在すれば、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱ－ｔｉｍｉｎｇ－ｉｎｄｉｃａｔｏｒフィールド値は、（３ＧＰＰＴＳ３８．２１３の表９．２．３－１において定義されているように）上位層パラメータｄｌ－ＤａｔａＴｏＵＬ－ＡＣＫによって提供されるスロット数のセットの値にマッピングされる。

３ＧＰＰＴＳ３８．３３１Ｖ１５．４．０は、ｆｏｒｍａｔ０及びｆｏｒｍａｔ１のＰＵＣＣＨリソースが第１のＰＵＣＣＨリソースセットにおいて、すなわちｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＳｅｔＩｄ＝０であるＰＵＣＣＨ－ＲｅｓｏｕｒｃｅＳｅｔにおいてのみ許容される、ということを規定している。このセットは、１～３２個のリソースを含んでいてもよい。ｆｏｒｍａｔ２、ｆｏｒｍａｔ３、及びｆｏｒｍａｔ４のＰＵＣＣＨリソースは、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＳｅｔＩｄ＞０であるＰＵＣＣＨ－ＲｅｓｏｕｒｃｅＳｅｔにおいてのみ可能にされる。もし存在すれば、これらのセットは、それぞれ１～８個のリソースを含む。

開始シンボルは、上記の定義から「任意の」ＯＦＤＭ（ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ：直交周波数分割多重）シンボルに配置することができるが、ネットワークは、ＰＵＣＣＨリソース構成の数が限られているため、それらのサブセットのみを設定することができる。スロット内に複数のＰＵＣＣＨ送信がある場合、「ｓｔａｒｔＳｙｍｂｏｌ」の位置は、タイムライン要件を満たすことに加えて、同一のスロット内で衝突がないということも保証する必要がある。

３ＧＰＰは、また、Ｒｅｌｅａｓｅ－１６において、スロット内のＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）のための複数のＰＵＣＣＨをサポートする意図がある。この機能を実装するためには、以下の課題のうちの１つ以上を解決する必要がある。
・異なるＰＵＣＣＨに対してＨＡＲＱ－ＡＣＫ多重化ウィンドウをどのように分離するか、
・異なるＰＵＣＣＨの開始シンボルをどのように示すか、
・スロットタイミング値「Ｋ_１」を、例えば、スロットの単位、ハーフスロットの単位、シンボル数の単位、又はシンボルの単位など、どのように示すか、
・動的ＨＡＲＱコードブックをどのように決定するか、
・準静的ＨＡＲＱ－ＡＣＫコードブックをどのように決定するか、
・ＰＵＣＣＨリソースセットをどのように構成するのか、例えば、Ｒ１５ＰＵＣＣＨリソースセット構成を再使用するか否か、
・各ＰＵＣＣＨのＰＵＣＣＨリソースをどのように決定するか、
・ＨＡＲＱ－ＡＣＫ多重化のためにＰＵＣＣＨリソースのオーバーライドをどのように行うか、
・スロットにおいて許容されるＨＡＲＱ－ＡＣＫのためのＰＵＣＣＨ送信数の最大値をいくつにするか。

３ＧＰＰにおいては、Ｒｅｌｅａｓｅ－１６のＵＥについては、ＵＥに対する異なるサービスタイプをサポートするために、少なくとも２つのＨＡＲＱ－ＡＣＫコードブックを同時に構成することができる、ということが合意されている。但し、関連する手順の詳細、適用可能なＨＡＲＱ－ＡＣＫコードブックを識別する方法の詳細、並びに準静的ＨＡＲＱ－ＡＣＫコードブック及び／又は動的ＨＡＲＱ－ＡＣＫコードブックの適用可能性は、依然として知られていない。

従って、本発明は、（少なくともいくつかの）上記の課題を解決するか又は少なくとも軽減する方法及び関連する装置を提供しようとするものである。

当業者の理解を効率的にするために、本発明は、３ＧＰＰシステム（５Ｇネットワーク）との関連で詳細に説明されるが、本発明の原理は、他のシステムに対しても同様に適用することができる。

本発明は、ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）により行われる方法であって、シンボル又はサブスロットレベルでダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックを送信するために用いられる少なくとも１つの通信リソースを示すＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を、前記ダウンリンクデータが送信されるタイミングウィンドウがスロット長よりも短いか長いかを示すために用いられる第１のＤＣＩフォーマット及び第２のＤＣＩフォーマットのうちの少なくとも１つに従って、受信することと、前記タイミングウィンドウの期間中にダウンリンクデータを受信することと、前記示された少なくとも１つの通信リソースを用いて、前記受信したダウンリンクデータについてのＨＡＲＱ－ＡＣＫを送信することと、を備える方法を提供する。

本発明は、ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）により行われる方法であって、ＰＵＣＣＨ（ＰｈｙｓｉｃａｌＵｐｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ：物理アップリンク制御チャネル）リソースインジケータフィールド（ΔＰＲＩ）を備えるＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を受信することと、ＰＵＣＣＨについて、通信リソースのセットを備えるスロット中の開始通信リソースを前記リソースインジケータフィールド（ΔＰＲＩ）の値に等しくすること、を決定することと、前記決定された開始通信リソースから開始して、前記受信したダウンリンクデータについてのＨＡＲＱ－ＡＣＫを送信することと、を備える方法を提供する。

本発明は、ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）により行われる方法であって、一連のＰＤＣＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ：物理ダウンリンク制御チャネル）の監視機会を監視することと、ＰＤＣＣＨの監視機会で、ＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を受信することと、ＰＤＳＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ：物理ダウンリンク共有チャネル）上で、前記ＤＣＩに対応するダウンリンクデータを受信することと、前記ダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックの送信に用いるために、コードブックを維持することであって、前記ＤＣＩに関連付けられたＰＤＳＣＨ受信（複数可）用の｛サービングセル、ＰＤＣＣＨ監視機会｝ペア（複数可）の累積数に基づき、最初にサービングセルインデックスの昇順で次にＰＤＣＣＨ監視機会インデックスの昇順で、現在のサービングセル及び現在のＰＤＣＣＨ監視機会まで、第１のカウンタ（例えば「Ｃ－ＤＡＩ」）を更新することと、前記ＤＣＩに関連付けられたＰＤＳＣＨ送信（複数可）が発生したスロット／サブスロット（複数可）／マルチスロットの総数に基づき、スロット／サブスロット／マルチスロットのインデックスの昇順で、現在のスロット／サブスロット／マルチスロットまで、第２のカウンタ（例えば「Ｔ－ＤＡＩ」）を更新することと、を備える方法を提供する。

本発明の例示的な態様は、対応するシステム、装置、及びコンピュータプログラム製品、例えば、命令が格納されたコンピュータ読み取り可能な記憶媒体であって、当該命令は、プログラム可能なプロセッサを、例示的な態様に記載された方法、及び、上記の又は特許請求の範囲に列挙された実現手段を実行するようにプログラムするように、及び／又は、適切に構成されたコンピュータを、特許請求の範囲の何れかに列挙された装置を提供するようにプログラムするように動作可能な命令が格納された上記記憶媒体に及ぶ。

本明細書（この用語には特許請求の範囲が含まれる）に開示されている及び／又は図面に示されている各特徴は、他の開示及び／又は図示されている特徴から独立して（又はそれらと組み合わせて）本発明に組み込むことができる。特に限定されることなく、特定の独立請求項に従属する何れかの請求項の特徴は、任意の組み合わせで、又は個別に、その独立請求項に導入されることもできる。

次に、本発明の例示的な実施形態を、以下の添付の図面を参照して、例示的に説明する。
図１は、本発明の例示的な実施形態が適用しうるモバイル（セルラ又は無線）通信システムを概略的に示す。図２は、図１に示すシステムの一部を形成するモバイル装置の概略ブロック図である。図３は、図１に示すシステムの一部を形成するアクセスネットワークノード（例えば基地局）の概略ブロック図である。図４は、図１に示すシステムの一部を形成するコアネットワークノードの概略ブロック図である。図５は、本発明の例示的な実施形態による、複数のＰＤＳＣＨ受信に準静的コードブック及び動的コードブックが適用されうるいくつかの例示的な方法を概略的に示す。図６は、本発明の例示的な実施形態による、複数のＰＤＳＣＨ受信に準静的コードブック及び動的コードブックが適用されうるいくつかの例示的な方法を概略的に示す。図７は、本発明の例示的な実施形態による、複数のＰＤＳＣＨ受信に準静的コードブック及び動的コードブックが適用されうるいくつかの例示的な方法を概略的に示す。

概要
３ＧＰＰ規格の下では、ＮｏｄｅＢ（又はＬＴＥにおいては「ｅＮＢ」、５Ｇにおいては「ｇＮＢ」）は、通信装置（ユーザ装置又は「ＵＥ」）がコアネットワークに接続し、他の通信装置又は遠隔サーバと通信するための基地局である。通信装置は、例えば、携帯電話、スマートフォン、スマートウォッチ、携帯情報端末、ラップトップ／タブレットコンピュータ、ウェブブラウザ、ｅブックリーダなどの移動通信装置であってもよい。このようなモバイル装置（一般的な固定式の装置でもよい）は、典型的には、ユーザによって操作される（従って、それらは多くの場合ユーザ装置、「ＵＥ」と総称される）が、ＩｏＴ装置及び同様のＭＴＣ装置をネットワークに接続することも可能である。簡単にするために、本願では、基地局という用語を用いて、このような基地局に言及し、モバイル装置又はＵＥという用語を用いて、このような通信装置に言及する。

図１は、本発明の例示的な実施形態が適用されてもよいモバイル（セルラ又は無線）通信システム１を概略的に示す。

このシステム１では、モバイル装置３（ＵＥ）のユーザが適切な３ＧＰＰＲＡＴ（ｒａｄｉｏａｃｃｅｓｓｔｅｃｈｎｏｌｏｇｙ：無線アクセス技術）、例えば、Ｅ‐ＵＴＲＡ及び／又は５ＧＲＡＴを使用して、各基地局５及びコアネットワーク７を介して、互いに及び他のユーザと通信することができる。多数の基地局５が（無線）アクセスネットワーク又は（Ｒ）ＡＮを形成する、ということが理解される。当業者が理解するように、２つのモバイル装置３Ａ及び３Ｂと、１つの基地局５とが例示の目的のために図１に示されるが、システムは、実装される際に、典型的には他の基地局及びモバイル装置（ＵＥ）を含む。

各基地局５は、１つ又は複数の関連付けられたセルを（直接に、又は、ホーム基地局、中継器、リモート無線ヘッド、分散ユニットなどの他のノードを介して）制御する。Ｅ‐ＵＴＲＡ／４Ｇプロトコルをサポートする基地局５は「ｅＮＢ」（ｅｖｏｌｖｅｄＮｏｄｅＢ）と呼ばれてもよく、ＮｅｘｔＧｅｎｅｒａｔｉｏｎ／５Ｇプロトコルをサポートする基地局５は「ｇＮＢ」と呼ばれてもよい。いくつかの基地局５は、４Ｇ及び５Ｇの双方、及び／又は他の任意の３ＧＰＰ又は非３ＧＰＰの通信プロトコルをサポートするように構成されてもよい、ということが理解される。

モバイル装置３とそのサービング基地局５とは、適切なエアインタフェース（例えば、いわゆる「Ｕｕ」インタフェースなど）を介して接続される。隣接する基地局５は基地局インタフェース（いわゆる「Ｘ２」インタフェース、及び／又は「Ｘｎ」インタフェースなど）に対する適切な基地局を介して互いに接続される。基地局５は、また、適切なインタフェース（いわゆる「Ｓ１」、「Ｎ１」、「Ｎ２」、及び／又は「Ｎ３」インタフェースなど）を介して、コアネットワークノードに接続される。

コアネットワーク７（例えば、ＬＴＥの場合のＥＰＣ、又はＮＲ／５Ｇの場合のＮＧＣ）は、典型的には、通信システム１における通信をサポートするための、及び、（とりわけ）加入者管理、モビリティ管理、課金、セキュリティ、通話／セッション管理のための論理ノード（又は「機能」）を含む。例えば、「ＮｅｘｔＧｅｎｅｒａｔｉｏｎ」／５Ｇシステムのコアネットワーク７は、ユーザプレーンエンティティ及び制御プレーンエンティティを含むことになる。この例において、コアネットワークは、少なくとも１つのＣＰＦ（ｃｏｎｔｒｏｌｐｌａｎｅｆｕｎｃｔｉｏｎ：制御プレーン機能）１０及び少なくとも１つのＵＰＦ（ｕｓｅｒｐｌａｎｅｆｕｎｃｔｉｏｎ：ユーザプレーン機能）１１を含む。また、コアネットワーク７は、とりわけ、ＡＭＦ（ＡｃｃｅｓｓａｎｄＭｏｂｉｌｉｔｙＦｕｎｃｔｉｏｎ：アクセス及びモビリティ機能）、ＳＭＦ（ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔＦｕｎｃｔｉｏｎ：セッション管理機能）、ＰＣＦ（ＰｏｌｉｃｙＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ：ポリシー制御機能）、ＡＦ（ＡｐｐｌｉｃａｔｉｏｎＦｕｎｃｔｉｏｎ：アプリケーション機能）、ＡＵＳＦ（ＡｕｔｈｅｎｔｉｃａｔｉｏｎＳｅｒｖｅｒＦｕｎｃｔｉｏｎ：認証サーバ機能）、ＵＤＭ（ＵｎｉｆｉｅｄＤａｔａＭａｎａｇｅｍｅｎｔ：統合データ管理）エンティティのうちの１つ以上を含んでもよいことが理解される。コアネットワーク７は、また、インターネット又は同様のＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ：インターネットプロトコル）ベースのネットワークなどのＤＮ（ＤａｔａＮｅｔｗｏｒｋ：データネットワーク）２０（図１に示す「外部ネットワーク」）に（ＵＰＦ１１を介して）接続される。

各モバイル装置３は、上記で定義されたカテゴリー（ＵＲＬＬＣ／ｅＭＢＢ／ｍＭＴＣ）のうちの１つに分類されうる１つ以上のサービスをサポートしてもよい、ということが理解される。各サービスは、典型的には、関連付けられた要件（例えば、遅延／データレート／パケット損失要件など）を有することになり、該要件は異なるサービスごとに異なってもよい。

特定のＵＥ３のデータパケットは、動的スケジューリングを用いて、及び／又は、事前に割り当てられた通信リソースを用いて（例えば半永続的なスケジューリング又は設定グラントによって）送信されてもよい。

ＰＵＣＣＨリソースセットの開始シンボルを「任意の」ＯＦＤＭシンボルにも配置することができるが、ネットワークは、可能なＰＵＣＣＨリソース構成の数が限られているため、これらのシンボルのサブセットのみ設定することができる。複数のＰＵＣＣＨ送信がスロットにある場合、タイムライン要件を満たす一方で、同一のスロット内で衝突がないように「ｓｔａｒｔＳｙｍｂｏｌ」の位置を選択する必要がある。

従って、１つのオプションは、ＨＡＲＱ－ＡＣＫを有する２ＵＣＩビットを超えるものも含めて、ＰＵＣＣＨリソースセットのサイズを増加させることである。具体的には、スロット未満のスロットタイミング値Ｋ_１について、示されたシンボル又はサブスロットは、スロットレベルにおける追加的な指示を必要とせずに、異なるＰＤＳＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ：物理ダウンリンク共有チャネル）のＨＡＲＱ－ＡＣＫ多重化ウィンドウを決定するのに十分であり得る。

但し、また同一のＰＵＣＣＨリソースＩＤによって「シンボル数」や「ＰＲＢ数」などもまた正しく選択する必要があるということを考慮すると、必ずしも所望の「開始シンボル」を示すことが可能であるとは限らないかもしれない。更に、上記のオプションは、ＣＣＥブロッキングの課題を解決しないかもしれない。

従って、１つ以上のスロットにまたがるスロットタイミング値Ｋ_１については、示されたシンボル又はサブスロットの開始点は、スロットレベル指示の終端からであり、すなわち次のスロットの開始を基準とする。

有利なことに、上記のシステムで、以下のコードブックが用いられてもよい。
準静的コードブック
ＡＣＫ／ＮＡＣＫビット＝１１００００１０
サブスロット０（Ｃ－ＤＡＩ＝０；Ｃ－ＤＡＩ＝１）
サブスロット１（Ｃ－ＤＡＩ＝２，Ｃ－ＤＡＩ＝３）
サブスロット２（Ｃ－ＤＡＩ＝０，Ｃ－ＤＡＩ＝１）
サブスロット３（Ｃ－ＤＡＩ＝２）
動的コードブック
ＡＣＫ／ＮＡＣＫビット＝１１００００１０
サブスロット０（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝０；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝０）
サブスロット１（Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝３，Ｔ－ＤＡＩ＝１）
サブスロット２（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝２；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝２）
サブスロット３（Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝３）
（注記：これらの例において、サブスロットごとに最大で２つのＰＤＳＣＨが設定される）
有利なことに、上記のシステムは、スロット内で複数のＰＵＣＣＨを許容するために、現在用いられているＵＣＩを改善し、ＵＲＬＬＣ及びｅＭＢＢ送信の、より信頼性の高いＨＡＲＱ－ＡＣＫフィードバック及び優先順位付けを提供する。

ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）
図２は、図１に示すモバイル装置（ＵＥ）３の主要な構成要素を示すブロック図である。図示したように、ＵＥ３は、１つ以上のアンテナ３３を介して、接続されたノード（複数可）に信号を送信し、当該ノードから信号を受信するように動作可能な送受信回路３１を含む。図２には必ずしも示されていないが、ＵＥ３は、当然ながら、（ユーザインターフェース３５などの）従来のモバイル装置の通常の機能のすべてを有することになり、これは、必要に応じて、ハードウェア、ソフトウェア、及びファームウェアのうちの任意の１つ又は任意の組み合わせによって提供されてもよい。コントローラ３７は、メモリ３９内に格納されたソフトウェアに従ってＵＥ３の動作を制御する。ソフトウェアは、例えば、メモリ３９に予めインストールされていてもよく、及び／又は電気通信ネットワーク１を介して、若しくはＲＭＤ（ｒｅｍｏｖａｂｌｅｄａｔａｓｔｏｒａｇｅｄｅｖｉｃｅ：取り外し可能なデータ記憶装置）からダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステム４１と通信制御モジュール４３とを含む。

通信制御モジュール４３は、ＵＥ３と、（Ｒ）ＡＮノード５及びコアネットワークノードを含む他のノードとの間の、アップリンク／ダウンリンクデータパケットを含むシグナリングメッセージに対応する（生成する／送信する／受信する）ことを担う。シグナリングは、（とりわけ）ＰＵＣＣＨ及び／又はＰＤＣＣＨに関連する制御シグナリング（ＵＣＩ及びＤＣＩを含む）を有してもよい。また、通信制御モジュール４３は、特定チャネルのために用いられるリソースセット及びコードブックを決定する役割を担う。

アクセスネットワークノード（基地局）
図３は、図１に示す基地局５（又は同様のアクセスネットワークノード）の主要な構成要素を示すブロック図である。図示したように、基地局５は、１つ以上のアンテナ５３を介して、接続されたＵＥ３（複数可）から信号を受信し、当該ＵＥ３に信号を送信し、ネットワークインタフェース５５を介して（直接的あるいは間接的に）他のネットワークノードに信号を送信し、当該ノードから信号を受信するように動作可能な送受信回路５１を含む。ネットワークインタフェース５５は、典型的には、適切な基地局－基地局インタフェース（例えばＸ２／Ｘｎ）と、適切な基地局－コアネットワークインタフェース（例えばＳ１／Ｎ１／Ｎ２／Ｎ３）とを含む。コントローラ５７は、メモリ５９内に格納されたソフトウェアに従って基地局５の動作を制御する。ソフトウェアは、例えば、メモリ５９に予めインストールされていてもよく、及び／又は電気通信ネットワーク１を介して、若しくはＲＭＤ（ｒｅｍｏｖａｂｌｅｄａｔａｓｔｏｒａｇｅｄｅｖｉｃｅ：取り外し可能なデータ記憶装置）からダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステム６１と通信制御モジュール６３とを含む。

通信制御モジュール６３は、基地局５と、ＵＥ３やコアネットワークノードなどの他のノードとの間のシグナリングに対応（生成／送信／受信）する役割を担う。シグナリングは、（とりわけ）ＰＵＣＣＨ及び／又はＰＤＣＣＨに関連する制御シグナリング（ＵＣＩ及びＤＣＩを含む）を有してもよい。また、通信制御モジュール６３は、特定チャネルためのリソースセット及びコードブックを決定する役割を担う。

コアネットワーク機能
図４は、図１に示すＵＰＦ１１又はＡＭＦ１２など、一般的なコアネットワーク機能の主要な構成要素を示すブロック図である。図示したように、コアネットワーク機能は、ネットワークインタフェース７５を介して（ＵＥ３、基地局５、及び他のコアネットワークノードを含む）他のノードに信号を送信し、当該他のノードから信号を受信するように動作可能な送受信回路７１を含む。コントローラ７７は、メモリ７９に記憶されたソフトウェアに従って、コアネットワーク機能の動作を制御する。ソフトウェアは、例えば、メモリ７９に予めインストールされていてもよく、及び／又は電気通信ネットワーク１を介して、若しくはＲＭＤ（ｒｅｍｏｖａｂｌｅｄａｔａｓｔｏｒａｇｅｄｅｖｉｃｅ：取り外し可能データ記憶装置）からダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステム８１と通信制御モジュール８３とを含む。

通信制御モジュール８３は、コアネットワークノードと、ＵＥ３、基地局５、及び他のコアネットワークノードなどの他のノードとの間のシグナリングに対応（生成／送信／受信）する役割を担う。

詳細な説明
いくつかの例示的な実施形態及び特徴のより詳細な説明を、図５～図７を参照して、以下に示す。

異なるＰＵＣＣＨのための個別のＨＡＲＱ－ＡＣＫ多重化ウィンドウ
上記のように、ＨＡＲＱ－ＡＣＫ送信のための複数のＰＵＣＣＨは、単一スロット内に提供されてもよい。例えば、１つのＰＵＣＣＨは、１つのＵＲＬＬＣサービスに関連付けられたＨＡＲＱ－ＡＣＫに対して提供されてもよく、別のＰＵＣＣＨは、異なるＵＲＬＬＣサービスに関連付けられたＨＡＲＱ－ＡＣＫに対して提供されてもよい。代替的に、１つのＰＵＣＣＨは、ＵＲＬＬＣに対して提供されてもよく、別のＰＵＣＣＨが、異なるタイプのサービス（非ＵＲＬＬＣ）に対して提供されてもよい。

（他のタイプのトラフィックと比較して）ＵＲＬＬＣトラフィックのより高い信頼性及びより低い遅延の要件をサポートするために、個別のＨＡＲＱ－ＡＣＫ多重化ウィンドウが、ｅＭＢＢ及びＵＲＬＬＣに対してサポートされてもよい。第１に、異なるサービスタイプは、ＵＥ３によって識別可能である必要がある。単純な方法は、「ＭＣＳ－Ｃ－ＲＮＴＩ」無線ネットワーク一時識別子を、ＤＣＩを介してスケジューリングするＵＲＬＬＣの識別のために再使用することである。第２に、個別のＨＡＲＱ－ＡＣＫ多重化ウィンドウは、Ｋ_１に基づいて、同一のサービスタイプの異なるＰＵＣＣＨに対して決定されてもよい。ＵＲＬＬＣのスロット内でＨＡＲＱ－ＡＣＫの複数のＰＵＣＣＨをサポートするために、スロットレベルのＨＡＲＱフィードバックタイミングに加えて、より細かい単位でＫ_１が示されることが有用である。そして、スロット内の異なるＰＵＣＣＨのＨＡＲＱ－ＡＣＫ多重化ウィンドウを決定するために、示されたＫ_１を直接用いることができる。

スロット内の複数のＰＵＣＣＨは、ＵＥ内のＵＲＬＬＣ及びｅＭＢＢはサービス（すなわち、同一のＵＥ３に対するＵＲＬＬＣ及びｅＭＢＢサービス）のための個別のＨＡＲＱフィードバックを可能にすることができる。部分的に重なる又は完全に重なるＨＡＲＱ－ＡＣＫ多重化ウィンドウを有するＰＵＣＣＨは、ＴＤＭ（ＴｉｍｅＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ：時分割多重）又はＦＤＭ（ＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ：周波数分割多重）によって分離されることができる。使用可能な周波数領域リソースがある場合、ｅＭＢＢ及びＵＲＬＬＣのＰＵＣＣＨは、ＵＬ（ｕｐｌｉｎｋ：アップリンク）において同時に送信されてもよい。

ＵＲＬＬＣについては、Ｋ_１が、スロットレベルのＨＡＲＱフィードバックタイミングに加えて、シンボル（複数可）単位又はサブスロット単位で示されることが有用である。

この説明では、少なくとも以下の２つのケースを考慮する。
（ｉ）シンボルのみによって指示されたＫ_１について（例えば、多重化ウィンドウがスロット未満である）、指示されたシンボル又はサブスロットは、スロットレベルでの追加的な指示を必要とせずに、異なるＰＤＳＣＨに対するＨＡＲＱ－ＡＣＫ多重化ウィンドウを決定するのに十分であるとすることができる。
（ｉｉ）スロット及びオプションとしてシンボルによって示されたＫ_１について（例えば、多重化ウィンドウがスロットを超えてまたがる）、示されたシンボル又はサブスロットの開始点は、スロットレベルの指示の終端からであり、すなわち次のスロットの開始を基準とする。

ダウンリンク（ＤＬ）アソシエーションセットは、設定されたＨＡＲＱ－ＡＣＫタイミングのセットに基づいて決定される（例えば、シンボルのリスト｛２，４，６，８，１０，１２，１４，１６｝若しくはこれらのシンボル値の倍数、又はサブスロット｛０，１，２，３，４，５，６，７｝若しくはこれらのサブスロット値の倍数によって提供される制限されたタイミング値のセットでＤＣＩフォーマット１＿０によってＵＥ３をスケジューリングする場合）。非スロットベースのＵＲＬＬＣサービスについては、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱ－ｔｉｍｉｎｇ－ｉｎｄｉｃａｔｏｒフィールドは、必要に応じて、ＰＤＳＣＨの最後のシンボル、又は単にＰＤＳＣＨが終了後の絶対的なシンボル番号を基準とすることができる。

ＤＣＩフォーマット１＿１によるスケジューリングについて、スロットタイミング値は、上位層パラメータＤＬ－ｄａｔａ－ＤＬ－ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ（及び／又は同種のもの）によって提供されてもよい。ｄｌ－ＤａｔａＴｏＵＬ－ＡＣＫ値は、上位層パラメータＳｌｏｔ－ｓｙｍｂｏｌ－ｔｉｍｉｎｇ－ｖａｌｕｅ－Ｋ１によって提供されるスロット数、シンボル／サブスロット数、又はその双方の組み合わせを示すように更新されることができる。タイミング値は、スロット値｛０，１｝と、シンボル値、例えば｛０，４，８，１２｝又はサブスロット値｛０，１，２，３｝のセットとの和集合によって決定することができる。

ＵＲＬＬＣサービスについては、示されたスロット値及びシンボル／サブスロット値は、異なるＰＵＣＣＨに対する個別のＨＡＲＱ－ＡＣＫ多重化ウィンドウ、及びＰＵＣＣＨの開始シンボルを決定するために直接用いられてもよい。

サブスロットの単位でＫ_１を示すことに関連する利点は、Ｒｅｌｅａｓｅ－１５の仕組みを再使用することができるということである。シンボルの単位でＫ_１を示すことに関連する利点は、局所的な実装の影響のみで望ましいＰＵＣＣＨリソース割り当てを適切にサポートすることを含み、ＰＵＣＣＨの開始シンボルは、直接決定されることができる。

多重化ウィンドウの終端に向かうＮ_１タイムラインを満たすことができれば、ＰＤＳＣＨが多重化ウィンドウに含まれることになることが理解される（ここで、Ｎ_１は、ＰＤＳＣＨ受信終了から、ＵＥ視点からのＰＵＳＣＨ又はＰＵＣＣＨの対応するＡＣＫ／ＮＡＣＫ送信の可能な限り早い開始まで、ＵＥの処理のために必要なＯＦＤＭシンボル数である）。

ＵＲＬＬＣの低遅延の要件を考慮すると、ＰＤＳＣＨ多重化ウィンドウＫ_１の終端とＰＵＣＣＨとの間のデフォルトのタイミング間隔は、可能な限り早くなるべきである。例えば、ＰＵＣＣＨ開始シンボルは、（Ｎ_１ＵＥの処理時間を満たす）Ｋ_１の直後であってもよい。

有利なことに、上記の方法を使用すれば、ＤＣＩにおける更なる指示を必要とせずに、Ｋ_１指示に暗黙的に基づいたＰＵＣＣＨ開始シンボルを設定することが可能である。

準静的コードブック及び動的ＨＡＲＱコードブックの決定
図５は、本例示的な実施形態による準静的コードブックを用いる例示的な方法を概略的に示す。

準静的コードブックの場合、Ｒｅｌｅａｓｅ－１５の仕組みは次のものを規定する。
ＡＣＫ／ＮＡＣＫビット＝１０００１００００００００００００００００１００００

対照的に、本システムは、以下の準静的コードブックを使用する。
ＡＣＫ／ＮＡＣＫビット＝１１００００１０
サブスロット０（Ｃ－ＤＡＩ＝０；Ｃ－ＤＡＩ＝１）
サブスロット１（Ｃ－ＤＡＩ＝２，Ｃ－ＤＡＩ＝３）
サブスロット２（Ｃ－ＤＡＩ＝０，Ｃ－ＤＡＩ＝１）
サブスロット３（Ｃ－ＤＡＩ＝２）

キャリアごとのスロット／サブスロットごとにＰＤＳＣＨ受信候補の最大数（又はスロット内で設定されたＨＡＲＱ－ＡＣＫの最大数）をｘとする。（各キャリアの）ｘビットのフィードバックは、各スロット／サブスロットの準静的コードブックに常に存在する。更に、Ｃ－ＤＡＩカウンタも存在することになる（ＤＣＩ＿ｆｏｒｍａｔ１＿０及び１＿１では既に存在する）。これもまた図５に示される（注記：この図に示す例ではサブスロットごとにｘ＝２）。

スロット／サブスロットごとのＰＤＣＣＨ監視機会がシンボルレベルまで増加すると、準静的コードブックのサイズが著しく増加する可能性がある、ということが理解される。（比較的）バースト的なＵＲＬＬＣトラフィックについては、準静的コードブックにおける多くのビットは、対応するＰＤＳＣＨ送信を有しない場合がある。これが、ひいては、ＰＵＣＣＨチャネルの送信期間を増加させ、及び／又は、準静的コードブックの伝送効率を減少させる場合がある。（２つのＰＵＣＣＨの場合に）同時に構築される２つのＨＡＲＱ－ＡＣＫコードブックがあったとしも、（例えば、第２のコードブックが異なるサービスタイプのものである場合）ＨＡＲＱ－ＡＣＫビット数は、必ずしも減少しないであろう。準静的コードブックの伝送効率を向上させるためにいくつかの仕組みが考えられ得るが（例えば、より短いＰＵＣＣＨ多重化ウィンドウが用いられてもよい）、ＰＵＣＣＨリソース又はＵＬスロットフォーマットが限られている可能性があることを鑑みると、特にＴＤＤについては、必ずしも実現可能だとは限らない。

動的コードブックの使用は、ＨＡＲＱ－ＡＣＫフィードバックの伝送効率を有利に向上させ、カウンタＤＡＩ値及びトータルＤＡＩ値は、各ＨＡＲＱ－ＡＣＫコードブックをＰＵＣＣＨごとに個別に適用することができる。現在、各カウンタには２ビットのみであるため、ＨＡＲＱ－ＡＣＫ多重化ウィンドウが４つ以上の開始タイミング／サブスロットにまたがる場合、動的コードブックの信頼性が損なわれうる。以下に、ＵＲＬＬＣの動的コードブックの信頼性を向上させる可能性のある方法を説明する。

Ｒｅｌｅａｓｅ－１５については、関連するダウンリンク割り当て指標「Ｃ－ＤＡＩ」及び「Ｔ－ＤＡＩ」は、以下の通りに定義される。
Ｃ－ＤＡＩ：ＤＣＩフォーマット１＿０又はＤＣＩフォーマット１＿１におけるカウンタＤＡＩ（ｄｏｗｎｌｉｎｋａｓｓｉｇｎｍｅｎｔｉｎｄｉｃａｔｏｒ：ダウンリンク割り当て指示子）フィールドの値は、ＤＣＩフォーマット１＿０又はＤＣＩフォーマット１＿１に関連付けられたＰＤＳＣＨ受信（複数可）のための｛サービングセル、ＰＤＣＣＨ監視機会｝ペア（複数可）の累積数を、現在のサービングセル及び現在のＰＤＣＣＨ監視機会まで、先ずサービングセルインデックスの昇順で、そして次にＰＤＣＣＨ監視機会インデックスの昇順で示す。
Ｔ－ＤＡＩ：現［ＴＳ３８．２１２］の場合、ＤＣＩフォーマット１＿１におけるトータルＤＡＩの値は、ＤＣＩフォーマット１＿０又はＤＣＩフォーマット１＿１に関連付けられたＰＤＳＣＨ受信（複数可）が存在する｛サービングセル、ＰＤＣＣＨ監視機会｝ペア（複数可）の、現在のＰＤＣＣＨ監視機会までの、総数を示し、ＰＤＣＣＨ監視機会からＰＤＣＣＨ監視機会に更新されるものとする。

但し、この文献では、Ｔ－ＤＡＩは、以下の通りに定義される。
Ｔ－ＤＡＩ：ＤＣＩフォーマット１＿１に存在する場合のトータルＤＡＩの値は、ＤＣＩフォーマット１＿１に関連付けられたＰＤＳＣＨ送信（複数可）が行われるスロット／サブスロット（複数可）／マルチスロットの総数を、現在のスロット／サブスロット／マルチスロットまで、スロット／サブスロット／マルチスロットインデックスの昇順で示す。ここで、１２０ｋＨｚ以上など、サブキャリア間隔が大きい場合に、「マルチスロット」が考慮される、ということに留意されたい。

図６及び図７は、新たに定義されたＣ－ＤＡＩ及びＴ－ＤＡＩを使用することから生じる、いくつか改善点を概略的に示す。事実上、カウンタが連続しているため、ＵＥ３は、（例えば、Ｃ－ＤＡＩ＝１とＣ－ＤＡＩ＝２との間のサブスロット／シンボルにおける）検出ミスを認識しない。

有利なことに、この例において、スロット／サブスロットごとの（設定された）ＰＤＳＣＨ送信の最大数は、動的コードブックにおける対応する「Ｃ－ＤＡＩ」及び「Ｔ－ＤＡＩ」値のペアごとのＨＡＲＱ－ＡＣＫビット数を決定するために用いられる。スロットごとのＰＤＳＣＨ送信の数は、ＰＤＳＣＨ期間が２、４、７シンボルであることを考慮すると、典型的には、ＰＤＣＣＨ監視機会の数よりも少ない。

動的コードブックの場合、Ｒｅｌｅａｓｅ－１５の仕組みは、以下のものを規定する。
ＡＣＫ／ＮＡＣＫビット＝１１１
サブスロット０（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝０；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝１）
サブスロット１（Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝２；Ｃ－ＤＡＩ＝３，Ｔ－ＤＡＩ＝３）
サブスロット２（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝０；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝１）
サブスロット３（Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝２）

対照的に、現在のシステムは、以下の動的コードブックを用いる。
ＡＣＫ／ＮＡＣＫビット＝１１００００１０
サブスロット０（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝０；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝０）
サブスロット１（Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝３，Ｔ－ＤＡＩ＝１）
サブスロット２（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝２；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝２）
サブスロット３（Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝３）

キャリアごとスロット／サブスロットごとのＰＤＳＣＨ受信候補の最大数（又は設定されたＨＡＲＱ－ＡＣＫの最大数）をｘとする。（各キャリアの）ｘビットのフィードバックは、Ｃ－ＤＡＩ／（Ｔ－ＤＡＩ）の各値（ペア）の動的コードブックに常に存在する。これもまた図６に示す（注記：この図に示す例ではサブスロットごとにｘ＝２）。

上記の仕組みに関連する利点は、（Ｒｅｌｅａｓｅ－１５と比較して）動的コードブックの信頼性が向上され得るということである。

スロットにおけるＨＡＲＱ－ＡＣＫのＰＵＣＣＨ送信の最大数
スロットごとのＰＤＣＣＨ監視機会は、シンボルレベルまで増加させることができるが、スロットにおけるＨＡＲＱ－ＡＣＫを含むＰＵＣＣＨ送信の最大数を、そのＵＥ処理時間の制約を満たすようにｅＭＢＢ及びＵＲＬＬＣのそれぞれに規定してもよい。

２．５、５、又は１０シンボルのＮ_１の典型的な値を考慮すると（ここで、Ｎ_１は、ＰＤＳＣＨ受信終了から、ＰＵＳＣＨ又はＰＵＣＣＨの対応するＡＣＫ／ＮＡＣＫ送信の可能な限り早い開始まで、ＵＥの処理のために必要なＯＦＤＭシンボル数である）、各スロットの各キャリアの関連付けられたＨＡＲＱ－ＡＣＫビットを含むＰＵＣＣＨ送信数を、ＵＲＬＬＣサービスに対して制限することができる。但し、ＴＤＤの場合には、スロットにおけるＰＵＣＣＨ送信が、マルチスロットのＰＤＳＣＨに関連付けられていてもよい。更に、キャリアアグリゲーションの場合には、複数のセルからの複数のＨＡＲＱ－ＡＣＫは、ＰＵＣＣＨ上に多重化されてもよい。したがって、スロットごとのＨＡＲＱ－ＡＣＫビットを含むＰＵＣＣＨ送信数は、設定可能とする必要があり得る。

キャリアアグリゲーションが利用されるとき、動的コードブックのＲｅｌｅａｓｅ－１５の仕組みは、以下のように規定される。
ＡＣＫ／ＮＡＣＫビット＝１１１１１１
サブスロット０（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝３，Ｔ－ＤＡＩ＝１）
サブスロット１（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝３，Ｔ－ＤＡＩ＝１）
サブスロット２（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝３，Ｔ－ＤＡＩ＝１）
サブスロット３（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝１）

対照的に、現在のシステムは、以下の動的コードブックを用いる。
ＡＣＫ／ＮＡＣＫビット＝１１１１００００００００１１００
サブスロット０（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝０；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝０；Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝０；Ｃ－ＤＡＩ＝３，Ｔ－ＤＡＩ＝０）
サブスロット１（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝１；Ｃ－ＤＡＩ＝３，Ｔ－ＤＡＩ＝１）
サブスロット２（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝２；Ｃ－ＤＡＩ＝１，Ｔ－ＤＡＩ＝２；Ｃ－ＤＡＩ＝２，Ｔ－ＤＡＩ＝２；Ｃ－ＤＡＩ＝３，Ｔ－ＤＡＩ＝２）
サブスロット３（Ｃ－ＤＡＩ＝０，Ｔ－ＤＡＩ＝３）

キャリアごとスロット／サブスロットごとのＰＤＳＣＨ受信候補の最大数（又は設定されたＨＡＲＱ－ＡＣＫの最大数）をｘとする。ｘビットのフィードバックは、Ｃ－ＤＡＩ／（Ｔ－ＤＡＩ）の各値（ペア）の動的コードブックに（キャリアごとに）常に存在する。ＵＲＬＬＣトラフィックは、典型的には小さなパケットを有するので、その多数のキャリアをＵＲＬＬＣコードブック内に集約させることは期待されていない。これもまた図７に示す（注記：この図に示す例ではサブスロットごとにｘ＝２）。

有利なことに、このアプローチを用いれば、ＵＲＬＬＣのスロットにおいて可能にされるＨＡＲＱ－ＡＣＫビットを含むＰＵＣＣＨ送信の最大数を設定することが可能である。

複数のＵＬチャネルの衝突処理
「ＡＣＫ／ＮＡＣＫ」を伝送する２つ以上のＰＵＣＣＨ／ＰＵＳＣＨ（ＰＵｘＣＨｓ）が互いに重なるとき、優先順位ルールを定義される必要があるかもしれない。概して、ＵＲＬＬＣに割り当てられるＴＢＳ（ＴｒａｎｓｐｏｒｔＢｌｏｃｋＳｉｚｅ：トランスポートブロックサイズ）及び物理リソースは限られている。他方、ｅＭＢＢＵＣＩのオーバヘッドは、大きくなる可能性があり、ｅＭＢＢＵＣＩの信頼性は、ＵＲＬＬＣＰＵＳＣＨの信頼性よりも低い。ＵＥ３がＰＵＣＣＨとＰＵＳＣＨとの同時通信をサポートする場合、複数のＰＵＣＣＨチャネルは、ＦＤＭ方式で並列に送信されてもよいが、そうでない場合は、以下の時間領域ソリューションが用いられてもよい。
・ＵＥ３が、ＵＲＬＬＣＰＵｘＣＨの送信と同じ第１のシンボルによるｅＭＢＢＰＵｘＣＨを送信することが予想される場合、ＵＥ３は、ＵＲＬＬＣＰＵｘＣＨの送信が完了するまで、ｅＭＢＢＰＵｘＣＨを延期してもよい。
・ＵＥ３が、ＵＲＬＬＣＰＵｘＣＨの送信の間にｅＭＢＢＰＵｘＣＨを送信することが予想される場合、ＵＥ３は、ＵＲＬＬＣＰＵｘＣＨの送信が完了するまでｅＭＢＢＰＵｘＣＨを送信しない。
・ＵＥ３が、ｅＭＢＢＰＵｘＣＨの送信中にＵＲＬＬＣＰＵｘＣＨを送信することが予想される場合、ＵＥ３は、ＵＲＬＬＣＰＵｘＣＨの送信をサポートするために、ｅＭＢＢ送信をパンクチャ又はレートマッチしてもよい。

有利なことに、ｅＭＢＢＰＵＣＣＨ／ＰＵＳＣＨの送信を延期又はレートマッチングすることによって、ＵＲＬＬＣの送信との衝突を回避することが可能である。

変形例及び代替例
以上、詳細な例示的な実施形態について説明してきた。当業者が理解しうるように、上記の例示的な実施形態に対して、多数の変形及び代替を行うことができ、そこで実施される本発明の利点を得ることができる。ここでは、例示のために、これらの代替例及び変形例のうちのいくつかのみを説明する。

５ＧＮＲとＬＴＥシステム（Ｅ－ＵＴＲＡＮ）の両方に対して、上記の例示的な実施形態が適用されてもよいことが理解される。

上記の説明では、ＵＥ、アクセスネットワークノード（基地局）、コアネットワークノードは、理解しやすくするために、（通信制御モジュールなどの）いくつかの個別モジュールを有するものとして説明されている。これらのモジュールは、例えば、既存のシステムが本発明を実装するように変形された特定の用途のために、又は、例えば、最初から本発明の特徴を念頭に置いて設計されたシステムにおける他の用途のために、このような方法で提供されてもよい。その一方で、これらのモジュールは、オペレーティングシステム又はコードの全体に組み込まれてもよく、従って、これらのモジュールは、別個のエンティティとして識別できなくてもよい。これらのモジュールは、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせで実装されてもよい。

各コントローラは、例えば、１つ以上のハードウェアで実装されたコンピュータプロセッサと、マイクロプロセッサと、ＣＰＵ（ｃｅｎｔｒａｌｐｒｏｃｅｓｓｉｎｇｕｎｉｔ：中央処理装置）と、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃｌｏｇｉｃｕｎｉｔ：算術論理ユニット）と、ＩＯ（ｉｎｐｕｔ／ｏｕｔｐｕｔ：入出力）回路と、内部メモリ／キャッシュ（プログラム及び／若しくはデータ）と、プロセッシングレジスタと、通信バス（例えば、コントロール、データ、及び／若しくはアドレスバス）と、ＤＭＡ（ｄｉｒｅｃｔｍｅｍｏｒｙａｃｃｅｓｓ：ダイレクトメモリアクセス）機能と、ハードウェア若しくはソフトウェアで実装されたカウンタ、ポインタ、及び／若しくはタイマなどを含む（但しそれらに限定はされない）任意の適当な形式の処理回路を備えてもよい。

上記の例示的な実施形態で、多くのソフトウェアモジュールを説明した。当業者が理解しうるように、ソフトウェアモジュールは、コンパイルされた形態又はコンパイルされていない形態で提供されてもよく、コンピュータネットワーク上の信号として、又は記録媒体上で、ＵＥ、アクセスネットワークノード（基地局）、及びコアネットワークノードに供給されてもよい。更に、このソフトウェアの一部又は全部によって実行される機能は、１つ又は複数の専用ハードウェア回路を使用して実行してもよい。但し、ソフトウェアモジュールの使用は、ＵＥ、アクセスネットワークノード、及びコアネットワークノードの機能を更新するために、それらの更新を容易にするので好ましい。

ＣＰ－ＵＰ（ｃｏｎｔｒｏｌｐｌａｎｅ－ｕｓｅｒｐｌａｎｅ：制御プレーン－ユーザプレーン）の分割が利用される場合、基地局は、個別の制御プレーン及びユーザプレーンのエンティティに分割されてもよく、それぞれが関連付けられた送受信回路、アンテナ、ネットワークインタフェース、コントローラ、メモリ、オペレーティングシステム、及び通信制御モジュールを含んでもよい、ということが理解されることになる。基地局が分散基地局を備えるとき、ネットワークインタフェース（図３における参照符号５５）は、また、分散基地局のそれぞれの機能の間で信号を通信するためにＥ１インタフェース及びＦ１インタフェース（制御プレーンのためにＦ１－Ｃ及びユーザプレーンのためにＦ１－Ｕ）を含む。この場合、通信制御モジュールは、また、基地局の制御プレーン部分とユーザプレーン部分との間の通信（シグナリングメッセージの生成、送信、及び受信）の役割を担う。分散基地局を用いる場合、上記の例示的な実施形態で説明したように、通信リソースの先取りのために、制御プレーン部分とユーザプレーン部分の両方を含む必要がない、ということが理解される。制御プレーン部分を含まずに、基地局のユーザプレーン部分で先取りを対応してもよい（逆もまた同様）、ということが理解される。

上記の例示的な実施形態は、また、「非モバイル」若しくは概して固定式のユーザ装置に対しても適用可能である。上記のモバイル装置は、ＭＴＣ／ＩｏＴ装置などを備えてもよい。

第１のＤＣＩフォーマット（例えば「ＤＣＩフォーマット１＿０」）は、タイミングウィンドウがスロット長よりも短いことを示してもよい。第２のＤＣＩフォーマット（例えば「ＤＣＩフォーマット１＿１」）は、タイミングウィンドウがスロット長よりも長いことを示してもよい。

少なくとも１つの通信リソースの指示は、タイミングウィンドウが終了するスロットと同じスロット内の少なくとも１つのシンボル又はサブスロットの位置を示してもよい。この場合、少なくとも１つの通信リソースの指示は、タイミングウィンドウが終了するスロット内の少なくとも１つのシンボル又はサブスロットの絶対位置を示してもよい。代替的に、少なくとも１つの通信リソースの指示は、タイミングウィンドウが終了するスロット内でダウンリンクデータが受信される最後のシンボル又はサブスロットに対する少なくとも１つのシンボル又はサブスロットの位置を示してもよい。

ＤＣＩは、ＵＲＬＬＣ（Ｕｌｔｒａ－ＲｅｌｉａｂｌｅａｎｄＬｏｗ－ＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性低遅延通信）のスケジューリングのための固有無線ネットワーク一時識別子（例えば「ＭＣＳ－Ｃ－ＲＮＴＩ」）を備えてもよい。

少なくとも１つの通信リソースは、（オプションとして、ＵＥでの処理を可能とする「Ｎ１」のＯＦＤＭ（ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ：直行周波数分割多重）シンボルの遅延を有する）タイミングウィンドウの直後に続いてもよい。

タイミングウィンドウが１つ以上のスロットにまたがるとき、少なくとも１つの通信リソースは、少なくとも１つのシンボル及び／又は少なくとも１つのサブスロットを識別する情報を備える上位層パラメータ（例えばＤＬ－ｄａｔａ－ＤＬ－ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）によって与えられてもよい。本方法は、ダウンリンクデータを受信してから対応するＨＡＲＱ－ＡＣＫを送信するまでの間のスロット数及びシンボル／サブスロット数のうちの少なくとも１つを示す情報（例えば、上位層パラメータＳｌｏｔ－ｓｙｍｂｏｌ－ｔｉｍｉｎｇ－ｖａｌｕｅ－Ｋ１における「ｄｌ－ＤａｔａＴｏＵＬ－ＡＣＫ」情報要素）を受信することを含んでもよい。

タイミングウィンドウは、スロットインデックス値（例えば｛０，１｝）と、シンボルインデックス値（例えば｛０，４，８，１２｝）又はサブスロットインデックス値（例えば｛０，１，２，３｝）のセットの和集合に基づいて決定されてもよい。

ＤＣＩはＰＵＣＣＨリソースインジケータフィールド（ΔＰＲＩ）を備えてもよく、その場合には、本方法は、ＰＵＣＣＨについて、通信リソースのセットを備えるスロット中の開始通信リソースを前記リソースインジケータフィールド（ΔＰＲＩ）の値に等しくすること、を決定することと、前記決定された開始通信リソースから開始して、前記受信したダウンリンクデータについてのＨＡＲＱ－ＡＣＫを送信することと、を備えてもよい。ＰＵＣＣＨ（Ｐｈｙｓｉｃａl ＵｐｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ：物理アップリンク制御チャネル）は、ＵＲＬＬＣ（Ｕｌｔｒａ－ＲｅｌｉａｂｌｅａｎｄＬｏｗ－ＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性低遅延通信）用であってもよい。

様々な他の変形が当業者には明らかであり、ここでは、それ以上詳細には説明しない。

上記の例示的な実施形態の一部又は全部は、以下の付記項に示すように説明することができるが、以下のものに限定するものではない。

（付記１）
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）により行われる方法であって、
シンボル又はサブスロットレベルでダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックを送信するために用いられる少なくとも１つの通信リソースを示すＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を、前記ダウンリンクデータが送信されるタイミングウィンドウがスロット長よりも短いか長いかを示すために用いられる第１のＤＣＩフォーマット及び第２のＤＣＩフォーマットのうちの少なくとも１つに従って、受信することと、
前記タイミングウィンドウの期間中にダウンリンクデータを受信することと、
前記示された少なくとも１つの通信リソースを用いて、前記受信したダウンリンクデータについてのＨＡＲＱ－ＡＣＫを送信することと、を備える方法。

（付記２）
前記第１のＤＣＩフォーマット（例えば、「ＤＣＩフォーマット１＿０」）は、前記タイミングウィンドウがスロット長よりも短いことを示す、付記１記載の方法。

（付記３）
前記第２のＤＣＩフォーマット（例えば、「ＤＣＩフォーマット１＿１」）は、前記タイミングウィンドウがスロット長よりも長いことを示す、付記１又は２記載の方法。

（付記４）
前記少なくとも１つの通信リソースの指示は、前記タイミングウィンドウが終了するスロットと同じスロット内の少なくとも１つのシンボル又はサブスロットの位置を示す、付記１乃至３のうち何れか１項記載の方法。

（付記５）
前記少なくとも１つの通信リソースの指示は、前記タイミングウィンドウが終了する前記スロット内の前記少なくとも１つのシンボル又はサブスロットの絶対位置を示す、付記４記載の方法。

（付記６）
前記少なくとも１つの通信リソースの指示は、前記タイミングウィンドウが終了する前記スロット内で前記ダウンリンクデータが受信される最後のシンボル又はサブスロットに対する前記少なくとも１つのシンボル又はサブスロットの位置を示す、付記４記載の方法。

（付記７）
前記ＤＣＩは、ＵＲＬＬＣ（Ｕｌｔｒａ－ＲｅｌｉａｂｌｅａｎｄＬｏｗ－ＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性低遅延通信）をスケジュールするための固有無線ネットワーク一時識別子（例えば、「ＭＣＳ－Ｃ－ＲＮＴＩ」）を備える、付記１乃至６のうち何れか１項記載の方法。

（付記８）
前記少なくとも１つの通信リソースは、（オプションとして、前記ＵＥでの処理を可能とする「Ｎ_１」のＯＦＤＭ（ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ：直交周波数分割多重）シンボルの遅延を有する）前記タイミングウィンドウの直後に続く、付記１乃至７のうち何れか１項記載の方法。

（付記９）
前記タイミングウィンドウが複数のスロットにまたがる場合、前記少なくとも１つの通信リソースは、少なくとも１つのシンボル及び／又はサブスロットを識別する情報を備える上位層パラメータ（例えば、ＤＬ－ｄａｔａ－ＤＬ－ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）により与えられる、付記１乃至８のうち何れか１項記載の方法。

（付記１０）
前記ダウンリンクデータの受信と対応するＨＡＲＱ－ＡＣＫの送信との間のスロット数及びシンボル／サブスロット数のうちの少なくとも１つを示す情報（例えば、上位層パラメータＳｌｏｔ－ｓｙｍｂｏｌ－ｔｉｍｉｎｇ－ｖａｌｕｅ－Ｋ１における「ｄｌ－ＤａｔａＴｏＵＬ－ＡＣＫ」情報要素）を受信すること、を備える付記１乃至９のうち何れか１項記載の方法。

（付記１１）
前記タイミングウィンドウは、スロットインデックス値（例えば｛０，１｝）と、シンボルインデックス値（例えば｛０，４，８，１２｝）又はサブスロットインデックス値（例えば｛０，１，２，３｝）のセットとの和集合に基づいて決定される、付記１乃至１０のうちの何れか１項記載の方法。

（付記１２）

（付記１３）
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）により行われる方法であって、

（付記１４）
前記ＰＵＣＣＨは、ＵＲＬＬＣ（Ｕｌｔｒａ－ＲｅｌｉａｂｌｅａｎｄＬｏｗ－ＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性低遅延通信）用である、付記１３記載の方法。

（付記１５）
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）により行われる方法であって、
一連のＰＤＣＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ：物理ダウンリンク制御チャネル）の監視機会を監視することと、
ＰＤＣＣＨの監視機会で、ＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を受信することと、
ＰＤＳＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ：物理ダウンリンク共有チャネル）上で、前記ＤＣＩに対応するダウンリンクデータを受信することと、
前記ダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックの送信に用いるために、コードブックを維持することであって、
前記ＤＣＩに関連付けられたＰＤＳＣＨ受信用の｛サービングセル、ＰＤＣＣＨ監視機会｝ペアの累積数に基づき、最初にサービングセルインデックスの昇順で次にＰＤＣＣＨ監視機会インデックスの昇順で、現在のサービングセル及び現在のＰＤＣＣＨ監視機会まで、第１のカウンタ（例えば「Ｃ－ＤＡＩ」））を更新することと、
前記ＤＣＩに関連付けられたＰＤＳＣＨ送信が発生したスロット／サブスロット／マルチスロットの総数に基づき、スロット／サブスロット／マルチスロットのインデックスの昇順で、現在のスロット／サブスロット／マルチスロットまで、第２のカウンタ（例えば「Ｔ－ＤＡＩ」）を更新することと、を含むことと、を備える方法。

（付記１６）
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）であって、
シンボル又はサブスロットレベルでダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックを送信するために用いられる少なくとも１つの通信リソースを示すＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を、前記ダウンリンクデータが送信されるタイミングウィンドウがスロット長よりも短いか長いかを示すために用いられる第１のＤＣＩフォーマット及び第２のＤＣＩフォーマットのうちの少なくとも１つに従って、受信する手段と、
前記タイミングウィンドウの期間中にダウンリンクデータを受信する手段と、
前記示された少なくとも１つの通信リソースを用いて、前記受信したダウンリンクデータについてのＨＡＲＱ－ＡＣＫを送信する手段と、を備えるＵＥ。

（付記１７）
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）であって、

（付記１８）
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）であって、
一連のＰＤＣＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ：物理ダウンリンク制御チャネル）の監視機会を監視する手段と、
ＰＤＣＣＨの監視機会で、ＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を受信する手段と、
ＰＤＳＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ：物理ダウンリンク共有チャネル）上で、前記ＤＣＩに対応するダウンリンクデータを受信する手段と、
前記ダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックの送信に用いるために、コードブックを維持することであって、
前記ＤＣＩに関連付けられたＰＤＳＣＨ受信用の｛サービングセル、ＰＤＣＣＨ監視機会｝ペアの累積数に基づき、最初にサービングセルインデックスの昇順で次にＰＤＣＣＨ監視機会インデックスの昇順で、現在のサービングセル及び現在のＰＤＣＣＨ監視機会まで、第１のカウンタ（例えば「Ｃ－ＤＡＩ」）を更新することと、
前記ＤＣＩに関連付けられたＰＤＳＣＨ送信が発生したスロット／サブスロット／マルチスロットの総数に基づき、スロット／サブスロット／マルチスロットのインデックスの昇順で、現在のスロット／サブスロット／マルチスロットまで、第２のカウンタ（例えば「Ｔ－ＤＡＩ」）を更新することと、を含む手段と、を備えるＵＥ。

（付記１９）
プログラマブル通信装置に、付記１乃至１５のうちの何れか１項記載の方法を行わせるためのコンピュータ実行可能な命令を備えるコンピュータ実行可能なプログラム。

本出願は、２０１９年２月１５日に出願された英国特許出願第１９０２１６６．６号に基づくものであり、その優先権の利益を主張し、その開示は、参照によりその全体が本明細書に組み込まれる。

Claims

ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）により行われる方法であって、
シンボル又はサブスロットレベルでダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックを送信するために用いられる少なくとも１つの通信リソースを示すＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を、前記ダウンリンクデータが送信されるタイミングウィンドウがスロット長よりも短いか長いかを示すために用いられる第１のＤＣＩフォーマット及び第２のＤＣＩフォーマットのうちの少なくとも１つに従って、受信することと、
前記タイミングウィンドウの期間中にダウンリンクデータを受信することと、
前記示された少なくとも１つの通信リソースを用いて、前記受信したダウンリンクデータについてのＨＡＲＱ－ＡＣＫを送信することと、を備える方法。
前記第１のＤＣＩフォーマットは、前記タイミングウィンドウがスロット長よりも短いことを示す、請求項１記載の方法。
前記第２のＤＣＩフォーマットは、前記タイミングウィンドウがスロット長よりも長いことを示す、請求項１又は２記載の方法。
前記少なくとも１つの通信リソースの指示は、前記タイミングウィンドウが終了するスロットと同じスロット内の少なくとも１つのシンボル又はサブスロットの位置を示す、請求項１乃至３のうち何れか１項記載の方法。
前記少なくとも１つの通信リソースの指示は、前記タイミングウィンドウが終了する前記スロット内の前記少なくとも１つのシンボル又はサブスロットの絶対位置を示す、請求項４記載の方法。
前記少なくとも１つの通信リソースの指示は、前記タイミングウィンドウが終了する前記スロット内で前記ダウンリンクデータが受信される最後のシンボル又はサブスロットに対する前記少なくとも１つのシンボル又はサブスロットの位置を示す、請求項４記載の方法。
前記ＤＣＩは、ＵＲＬＬＣ（Ｕｌｔｒａ－ＲｅｌｉａｂｌｅａｎｄＬｏｗ－ＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性低遅延通信）をスケジュールするための固有無線ネットワーク一時識別子を備える、請求項１乃至６のうち何れか１項記載の方法。
前記少なくとも１つの通信リソースは、（オプションとして、前記ＵＥでの処理を可能とする「Ｎ_１」のＯＦＤＭ（ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ：直交周波数分割多重）シンボルの遅延を有する）前記タイミングウィンドウの直後に続く、請求項１乃至７のうち何れか１項記載の方法。
前記タイミングウィンドウが複数のスロットにまたがる場合、前記少なくとも１つの通信リソースは、少なくとも１つのシンボル及び／又はサブスロットを識別する情報を備える上位層パラメータにより与えられる、請求項１乃至８のうち何れか１項記載の方法。
前記ダウンリンクデータの受信と対応するＨＡＲＱ－ＡＣＫの送信との間のスロット数及びシンボル／サブスロット数のうちの少なくとも１つを示す情報を受信すること、を備える請求項１乃至９のうち何れか１項記載の方法。
前記タイミングウィンドウは、スロットインデックス値と、シンボルインデックス値又はサブスロットインデックス値のセットとの和集合に基づいて決定される、請求項１乃至１０のうちの何れか１項記載の方法。
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）により行われる方法であって、
前記ＰＵＣＣＨは、ＵＲＬＬＣ（Ｕｌｔｒａ－ＲｅｌｉａｂｌｅａｎｄＬｏｗ－ＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性低遅延通信）用である、請求項１３記載の方法。
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）により行われる方法であって、
一連のＰＤＣＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ：物理ダウンリンク制御チャネル）の監視機会を監視することと、
ＰＤＣＣＨの監視機会で、ＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を受信することと、
ＰＤＳＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ：物理ダウンリンク共有チャネル）上で、前記ＤＣＩに対応するダウンリンクデータを受信することと、
前記ダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックの送信に用いるために、コードブックを維持することであって、
前記ＤＣＩに関連付けられたＰＤＳＣＨ受信用の｛サービングセル、ＰＤＣＣＨ監視機会｝ペアの累積数に基づき、最初にサービングセルインデックスの昇順で次にＰＤＣＣＨ監視機会インデックスの昇順で、現在のサービングセル及び現在のＰＤＣＣＨ監視機会まで、第１のカウンタを更新することと、
前記ＤＣＩに関連付けられたＰＤＳＣＨ送信が発生したスロット／サブスロット／マルチスロットの総数に基づき、スロット／サブスロット／マルチスロットのインデックスの昇順で、現在のスロット／サブスロット／マルチスロットまで、第２のカウンタを更新することと、を含むことと、を備える方法。
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）であって、
シンボル又はサブスロットレベルでダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックを送信するために用いられる少なくとも１つの通信リソースを示すＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を、前記ダウンリンクデータが送信されるタイミングウィンドウがスロット長よりも短いか長いかを示すために用いられる第１のＤＣＩフォーマット及び第２のＤＣＩフォーマットのうちの少なくとも１つに従って、受信する手段と、
前記タイミングウィンドウの期間中にダウンリンクデータを受信する手段と、
前記示された少なくとも１つの通信リソースを用いて、前記受信したダウンリンクデータについてのＨＡＲＱ－ＡＣＫを送信する手段と、を備えるＵＥ。
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）であって、
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）であって、
一連のＰＤＣＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ：物理ダウンリンク制御チャネル）の監視機会を監視する手段と、
ＰＤＣＣＨの監視機会で、ＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ：ダウンリンク制御情報）を受信する手段と、
ＰＤＳＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ：物理ダウンリンク共有チャネル）上で、前記ＤＣＩに対応するダウンリンクデータを受信する手段と、
前記ダウンリンクデータのＨＡＲＱ－ＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ハイブリッド自動再送要求受信確認）フィードバックの送信に用いるために、コードブックを維持することであって、
前記ＤＣＩに関連付けられたＰＤＳＣＨ受信用の｛サービングセル、ＰＤＣＣＨ監視機会｝ペアの累積数に基づき、最初にサービングセルインデックスの昇順で次にＰＤＣＣＨ監視機会インデックスの昇順で、現在のサービングセル及び現在のＰＤＣＣＨ監視機会まで、第１のカウンタを更新することと、
前記ＤＣＩに関連付けられたＰＤＳＣＨ送信が発生したスロット／サブスロット／マルチスロットの総数に基づき、スロット／サブスロット／マルチスロットのインデックスの昇順で、現在のスロット／サブスロット／マルチスロットまで、第２のカウンタを更新することと、を含む手段と、を備えるＵＥ。
プログラマブル通信装置に、請求項１乃至１５のうちの何れか１項記載の方法を行わせるためのコンピュータ実行可能な命令を備えるコンピュータ実行可能なプログラム。