JP2024520661A - ユーザ機器、スケジューリングノード、ユーザ機器のための方法、およびスケジューリングノードのための方法 - Google Patents

Abstract

本開示は、通信デバイス、基地局、および通信デバイスと基地局のそれぞれの方法に関する。具体的には、通信デバイスは、ＵＣＩ送信用の複数の送信機会を示す通知を取得する。ＵＣＩが送信に利用可能になる場合、通信デバイスは、利用可能なＵＣＩを送信するための複数の送信機会のうちの送信機会を使用するか否かを、利用可能なＵＣＩに関連付けられた優先基準に基づいて判定する。利用可能なＵＣＩの送信に送信機会が使用されると判定される場合、通信デバイスは、利用可能なＵＣＩを送信するために送信機会を使用する。

Description

１．技術分野
本開示は、通信システムにおける信号の送受信に関する。特に、本開示は、そのような送受信のための方法および装置に関する。

２．関連技術の説明
第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標）：３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）は、１００ＧＨｚまでの周波数範囲で動作する、新無線（ＮＲ：Ｎｅｗ Ｒａｄｉｏ）アクセス技術（ＲＡＴ：Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）を含む次世代セルラー技術（第５世代（５Ｇ）ともいう）の技術仕様に取り組んでいる。ＮＲは、ロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）およびＬＴＥアドバンスト（ＬＴＥ－Ａ：ＬＴＥ Ａｄｖａｎｃｅｄ）に代表される技術の後継技術である。

ＬＴＥやＮＲなどのシステムでは、さらなる改良およびオプションによって、通信システムおよび通信システムに関係する特定のデバイスの効率的な動作が容易になる場合がある。

3GPP TS 38.300 v15.6.0 3GPP TS 38.211 v16.2.0 3GPP TS 38.211 v15.7.0 ITU-R M.2083 TR 38.913 TS 23.501 v16.1.0 TS 38.212 v15.6.0 RAN1#104b-e

一つの非限定的かつ例示的な実施の形態は、上りリンク制御情報（ＵＣＩ：Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）の送信用の送信機会の効率的な使用を容易化する。

一実施の形態では、本明細書で開示する技術は、装置（例えば、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）を特徴とする。本装置は、動作時に、ＵＣＩ送信用の複数の送信機会を示す通知を取得する回路を備える。本回路は、ＵＣＩが送信に利用可能であると判定し、利用可能なＵＣＩを送信するための複数の送信機会のうちの送信機会を使用するか否かを、利用可能なＵＣＩに関連付けられた優先基準に基づいて判定する。さらに、本装置は、動作時に、利用可能なＵＣＩの送信に送信機会が使用されると判定された場合に、利用可能なＵＣＩを送信するために送信機会を使用する送受信部を備える。

なお、一般的な実施の形態または具体的な実施の形態は、システム、方法、集積回路、コンピュータプログラム、記憶媒体、またはこれらの任意の選択的な組合せとして、実施できることに留意されたい。

本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施の形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。

以下の例示的な実施の形態は、添付の図面を参照してより詳細に説明される。
３ＧＰＰ ＮＲシステムの例示的なアーキテクチャを示す図 ＮＧ－ＲＡＮと５ＧＣとの間の機能分離を示す概略図 ＲＲＣ接続のセットアップ／再設定の手順のシーケンス図 拡張モバイルブロードバンド（ｅＭＢＢ）、大規模マシンタイプ通信（ｍＭＴＣ）、および超高信頼・低遅延通信（ＵＲＬＬＣ）の使用シナリオを示す概略図 非ローミングのための例示的な５Ｇシステムアーキテクチャを示すブロック図 ユーザ機器および基地局を含む通信システムと、ユーザ機器および基地局の構造とを示すブロック図 ユーザ機器側の処理回路の機能構成を示すブロック図 基地局側の処理回路の機能構成を示すブロック図 ネットワークノードによって実行される例示的なステップおよびユーザ機器によって実行される例示的なステップを示すフローチャート 送信機会がＤＬシンボルと衝突する場合の第１の例示的なＵＥ挙動を示す概略図 送信機会がＤＬシンボルと衝突する場合の第２の例示的なＵＥ挙動を示す概略図 送信機会がＤＬシンボルと衝突する場合にＨＡＲＱ報告のドロップを回避するための優先度に基づくＵＥ挙動の例を示す概略図 送信機会がＤＬシンボルと衝突する場合の、優先度に基づきＱｏＳ要件を考慮に入れたＵＥ挙動の例を示す概略図 ＵＣＩが送信に利用可能になるときにＵＥによって実行される例示的なステップを示すフローチャート ＵＣＩが送信に利用可能になるときにＵＥによって実行される例示的なステップを示すフローチャート ＵＬ制御リソースの使用を低減するための例示的なＵＥ挙動を示す概略図 ＨＡＲＱ ＡＣＫおよびＨＡＲＱ ＮＡＣＫに対して異なる優先基準を使用することによって急を要しないＵＣＩを延期してＵＬトラフィックの低減を実現する優先度に基づくＵＥ挙動の例を示す概略図 ＨＡＲＱ ＮＡＣＫおよびＨＡＲＱ ＡＣＫに対して異なる優先基準を使用することによってＨＡＲＱ ＮＡＣＫのより高い信頼性を実現する優先度に基づくＵＥ挙動の例を示す概略図

＜５Ｇ ＮＲのシステムアーキテクチャおよびプロトコルスタック＞
３ＧＰＰは、１００ＧＨｚまでの周波数範囲で動作する新無線アクセス技術（ＮＲ）の開発を含む第５世代携帯電話技術（単に「５Ｇ」ともいう）の次のリリースに向けて作業を続けている。５Ｇ規格の初版は２０１７年の終わりに完成しており、これにより、５Ｇ ＮＲの規格に準拠したスマートフォンの試作および商用配備に移ることが可能となっている。

特に、システムアーキテクチャは、全体としては、ｇＮＢを備えるＮＧ－ＲＡＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ － Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）を想定する。ｇＮＢは、ＮＧ無線アクセスのユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルのＵＥ側の終端を提供する。ｇＮＢは、Ｘｎインタフェースによって互いに接続される。また、ｇＮＢは、Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ（ＮＧ）インタフェースによってＮＧＣ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｃｏｒｅ）に、より具体的には、ＮＧ－ＣインタフェースによってＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）（例えば、ＡＭＦを行う特定のコアエンティティ）に、また、ＮＧ－ＵインタフェースによってＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）（例えば、ＵＰＦを行う特定のコアエンティティ）に接続される。ＮＧ－ＲＡＮアーキテクチャを図１に示す（例えば、非特許文献１の第４節参照）。

ＮＲのユーザプレーンのプロトコルスタック（例えば、非特許文献１の第４．４．１節参照）は、ｇＮＢにおいてネットワーク側で終端されるＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ（非特許文献１の第６．４節参照））サブレイヤ、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（非特許文献１の第６．３節参照））サブレイヤ、およびＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（非特許文献１の第６．２節参照））サブレイヤを含む。また、新たなアクセス層（ＡＳ：Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）のサブレイヤ（ＳＤＡＰ：Ｓｅｒｖｉｃｅ Ｄａｔａ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）がＰＤＣＰの上に導入されている（例えば、非特許文献１の第６．５節参照）。また、制御プレーンのプロトコルスタックがＮＲのために定義されている（例えば、非特許文献１の第４．４．２節参照）。レイヤ２の機能の概要が非特許文献１の第６節に記載されている。ＰＤＣＰサブレイヤ、ＲＬＣサブレイヤ、およびＭＡＣサブレイヤの機能は、それぞれ、非特許文献１の第６．４節、第６．３節、および第６．２節に列挙されている。ＲＲＣレイヤの機能は、非特許文献１の第７節に列挙されている。

例えば、Ｍｅｄｉｕｍ－Ａｃｃｅｓｓ－Ｃｏｎｔｒｏｌレイヤは、論理チャネルの多重化と、様々なニューメロロジーを扱うことを含むスケジューリングおよびスケジューリング関連の諸機能と、を扱う。

例えば、物理レイヤ（ＰＨＹ）は、符号化、ＰＨＹ ＨＡＲＱ処理、変調、マルチアンテナ処理、および適切な物理的時間－周波数リソースへの信号のマッピングの役割を担う。また、物理レイヤは、物理チャネルへのトランスポートチャネルのマッピングを扱う。物理レイヤは、ＭＡＣレイヤにトランスポートチャネルの形でサービスを提供する。物理チャネルは、特定のトランスポートチャネルの送信に使用される時間周波数リソースのセットに対応し、各トランスポートチャネルは、対応する物理チャネルにマッピングされる。例えば、物理チャネルには、上り物理チャネルとして、ＰＲＡＣＨ（物理ランダムアクセスチャネル：Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）、ＰＵＳＣＨ（物理上りリンク共有チャネル：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）、およびＰＵＣＣＨ（物理上りリンク制御チャネル：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）があり、下り物理チャネルとして、ＰＤＳＣＨ（物理下りリンク共有チャネル：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）、ＰＤＣＣＨ（物理下りリンク制御チャネル：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、およびＰＢＣＨ（物理報知チャネル：Ｐｈｙｓｉｃａｌ Ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ）がある。

ＮＲのユースケース／配備シナリオには、データレート、レイテンシ、およびカバレッジの点で多様な要件を有するｅｎｈａｎｃｅｄ ｍｏｂｉｌｅ ｂｒｏａｄｂａｎｄ（ｅＭＢＢ）、ｕｌｔｒａ－ｒｅｌｉａｂｌｅ ｌｏｗ－ｌａｔｅｎｃｙ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＵＲＬＬＣ）、ｍａｓｓｉｖｅ ｍａｃｈｉｎｅ ｔｙｐｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ（ｍＭＴＣ）が含まれ得る。例えば、ｅＭＢＢは、ＩＭＴ－Ａｄｖａｎｃｅｄが提供するデータレートの３倍程度のピークデータレート（下りリンクにおいて２０Ｇｂｐｓおよび上りリンクにおいて１０Ｇｂｐｓ）および実効（ｕｓｅｒ－ｅｘｐｅｒｉｅｎｃｅｄ）データレートをサポートすることが期待されている。一方、ＵＲＬＬＣの場合、より厳しい要件が超低レイテンシ（ユーザプレーンのレイテンシについてＵＬおよびＤＬのそれぞれで０．５ｍｓ）および高信頼性（１ｍｓ内において１－１０^－５）について課されている。最後に、ｍＭＴＣでは、好ましくは高い接続密度（都市環境において装置１，０００，０００台／ｋｍ^２）、悪環境における広いカバレッジ、および低価格の装置のための極めて寿命の長い電池（１５年）が求められうる。

そのため、１つのユースケースに適したＯＦＤＭのニューメロロジー（例えば、サブキャリア間隔、ＯＦＤＭシンボル長、サイクリックプレフィックス（ＣＰ：Ｃｙｃｌｉｃ Ｐｒｅｆｉｘ）長、スケジューリング区間毎のシンボル数）が他のユースケースには有効でない場合がある。例えば、低レイテンシのサービスでは、好ましくは、ｍＭＴＣのサービスよりもシンボル長が短いこと（したがって、サブキャリア間隔が大きいこと）および／またはスケジューリング区間（ＴＴＩともいう）毎のシンボル数が少ないことが求められうる。さらに、チャネルの遅延スプレッドが大きい展開シナリオでは、好ましくは、遅延スプレッドが短いシナリオよりもＣＰ長が長いことが求められうる。サブキャリア間隔は、同様のＣＰオーバーヘッドが維持されるように状況に応じて最適化されてもよい。ＮＲがサポートするサブキャリア間隔の値は、１つ以上であってよい。したがって、現在、１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ…のサブキャリア間隔が考えられている。シンボル長Ｔ_ｕおよびサブキャリア間隔Δｆは、式Δｆ＝１／Ｔ_ｕによって直接関係づけられている。ＬＴＥシステムと同様に、用語「リソースエレメント」を、１つのＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対する１つのサブキャリアから設定される最小のリソース単位を意味するように使用することができる。

新無線システム５Ｇ－ＮＲでは、各ニューメロロジーおよび各キャリアについて、サブキャリアおよびＯＦＤＭシンボルのリソースグリッドが上りリンクおよび下りリンクのそれぞれに定義される。リソースグリッドの各エレメントは、リソースエレメントと呼ばれ、周波数領域の周波数インデックスおよび時間領域のシンボル位置に基づいて特定される（非特許文献２（例えば、第４節）参照）。例えば、下りリンク送信および上りリンク送信は、１０ｍｓの持続時間を有するフレームに設定される。各フレームは、それぞれ持続時間が１ｍｓの１０個のサブフレームからなる。５Ｇ ＮＲの実装において、サブフレーム当たりの連続ＯＦＤＭシンボルの数は、サブキャリア間隔の設定に依存する。例えば、１５ｋＨｚのサブキャリア間隔の場合、サブフレームは１４個のＯＦＤＭシンボルを有する（通常のサイクリックプレフィックスを想定すると、ＬＴＥ準拠の実装と同様）。一方、３０ｋＨｚのサブキャリア間隔の場合、サブフレームは２つのスロットを有し、各スロットは１４個のＯＦＤＭシンボルを備える。

ＬＴＥニューメロロジー（サブキャリア間隔およびシンボル長）と比較して、ＮＲは、パラメータによってラベル付けされる、複数の異なるタイプのサブキャリア間隔をサポートする（ＬＴＥでは、ＮＲに対応する１５ｋＨｚのサブキャリア間隔のみが存在する）。ＮＲニューメロロジーのタイプは、非特許文献３に要約されている。

＜５Ｇ ＮＲにおけるＮＧ－ＲＡＮと５ＧＣとの間の機能分離＞
図２は、ＮＧ－ＲＡＮと５ＧＣとの間の機能分離を示す。ＮＧ－ＲＡＮの論理ノードは、ｇＮＢまたはｎｇ－ｅＮＢである。５ＧＣは、論理ノードＡＭＦ、ＵＰＦ、およびＳＭＦを有する。

特に、ｇＮＢおよびｎｇ－ｅＮＢは、以下の主な機能をホストする：
－ 無線ベアラ制御（Ｒａｄｉｏ Ｂｅａｒｅｒ Ｃｏｎｔｒｏｌ）、無線アドミッション制御（Ｒａｄｉｏ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ）、接続モビリティ制御（Ｃｏｎｎｅｃｔｉｏｎ Ｍｏｂｉｌｉｔｙ Ｃｏｎｔｒｏｌ）、上りリンクおよび下りリンクの両方におけるリソースのＵＥへの動的割当（スケジューリング）等の無線リソース管理（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ）の機能；
－ データのＩＰヘッダ圧縮、暗号化、および完全性保護；
－ ＵＥが提供する情報からＡＭＦへのルーティングを決定することができない場合のＵＥのアタッチ時のＡＭＦの選択；
－ ＵＰＦに向けたユーザプレーンデータのルーティング；
－ ＡＭＦに向けた制御プレーン情報のルーティング；
－ 接続のセットアップおよびリリース；
－ ページングメッセージのスケジューリングおよび送信；
－ システム報知情報（ＡＭＦまたは運用管理保守機能（ＯＡＭ：Ｏｐｅｒａｔｉｏｎ，Ａｄｍｉｓｓｉｏｎ，Ｍａｉｎｔｅｎａｎｃｅ）が発信源）のスケジューリングおよび送信；
－ モビリティおよびスケジューリングのための測定および測定報告の設定；
－ 上りリンクにおけるトランスポートレベルのパケットマーキング；
－ セッション管理；
－ ネットワークスライシングのサポート；
－ ＱｏＳフロー管理およびデータ無線ベアラに対するマッピング；
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート；
－ 非アクセス層（ＮＡＳ：Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）メッセージの配信機能；
－ 無線アクセスネットワークの共有；
－ デュアルコネクティビティ；
－ ＮＲとＥ－ＵＴＲＡとの緊密な連携。

Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ（ＡＭＦ）は、以下の主な機能をホストする：
－ 非アクセス層（ＮＡＳ：Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）のシグナリングを終端させる機能；
－ ＮＡＳシグナリングのセキュリティ；
－ アクセス層（ＡＳ：Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）のセキュリティ制御；
－ ３ＧＰＰのアクセスネットワーク間でのモビリティのためのコアネットワーク（ＣＮ：Ｃｏｒｅ Ｎｅｔｗｏｒｋ）ノード間シグナリング；
－ アイドルモードのＵＥへの到達可能性（ページングの再送信の制御および実行を含む）；
－ 登録エリアの管理；
－ システム内モビリティおよびシステム間モビリティのサポート；
－ アクセス認証；
－ ローミング権限のチェックを含むアクセス承認；
－ モビリティ管理制御（加入およびポリシー）；
－ ネットワークスライシングのサポート；
－ Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ（ＳＭＦ）の選択。

さらに、Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ（ＵＰＦ）は、以下の主な機能をホストする：
－ ＲＡＴ内モビリティ／ＲＡＴ間モビリティ（適用可能な場合）のためのアンカーポイント；
－ データネットワークとの相互接続のための外部ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）セッションポイント；
－ パケットのルーティングおよび転送；
－ パケット検査およびユーザプレーン部分のポリシールールの強制（Ｐｏｌｉｃｙ ｒｕｌｅ ｅｎｆｏｒｃｅｍｅｎｔ）；
－ トラフィック使用量の報告；
－ データネットワークへのトラフィックフローのルーティングをサポートする上りリンククラス分類（ｕｐｌｉｎｋ ｃｌａｓｓｉｆｉｅｒ）；
－ マルチホームＰＤＵセッション（ｍｕｌｔｉ－ｈｏｍｅｄ ＰＤＵ ｓｅｓｓｉｏｎ）をサポートするための分岐点（Ｂｒａｎｃｈｉｎｇ Ｐｏｉｎｔ）；
－ ユーザプレーンに対するＱｏＳ処理（例えば、パケットフィルタリング、ゲーティング（ｇａｔｉｎｇ）、ＵＬ／ＤＬレート強制（ＵＬ／ＤＬ ｒａｔｅ ｅｎｆｏｒｃｅｍｅｎｔ）；
－ 上りリンクトラフィックの検証（ＳＤＦのＱｏＳフローに対するマッピング）；
－ 下りリンクパケットのバッファリングおよび下りリンクデータ通知のトリガ機能。

最後に、Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ（ＳＭＦ）は、以下の主な機能をホストする：
－ セッション管理；
－ ＵＥに対するＩＰアドレスの割当および管理；
－ ＵＰＦの選択および制御；
－ 適切な宛先にトラフィックをルーティングするためのＵｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ（ＵＰＦ）におけるトラフィックステアリング（ｔｒａｆｆｉｃ ｓｔｅｅｒｉｎｇ）の設定機能；
－ 制御部分のポリシー施行およびＱｏＳ；
－ 下りリンクデータの通知。

＜ＲＲＣ接続のセットアップおよび再設定の手順＞
図３は、ＮＡＳ部分の、ＵＥがＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤに移行する際のＵＥ、ｇＮＢ、およびＡＭＦ（５ＧＣエンティティ）の間のやり取りのいくつかを示す（非特許文献１参照）。

ＲＲＣは、ＵＥおよびｇＮＢの設定に使用される上位レイヤのシグナリング（プロトコル）である。特に、この移行により、ＡＭＦは、ＵＥコンテキストデータ（これは、例えば、ＰＤＵセッションコンテキスト、セキュリティキー、ＵＥ無線能力（ＵＥ Ｒａｄｉｏ Ｃａｐａｂｉｌｉｔｙ）、ＵＥセキュリティ能力（ＵＥ Ｓｅｃｕｒｉｔｙ Ｃａｐａｂｉｌｉｔｉｅｓ）等を含む）を用意し、初期コンテキストセットアップ要求（ＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴ）とともにｇＮＢに送る。そして、ｇＮＢは、ＵＥと一緒に、ＡＳセキュリティをアクティブにする。これは、ｇＮＢがＵＥにＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｍａｎｄメッセージを送信し、ＵＥがＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｐｌｅｔｅメッセージでｇＮＢに応答することによって行われる。その後、ｇＮＢは、ＵＥにＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを送信し、これに対するＵＥからのＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅをｇＮＢが受信することによって、Ｓｉｇｎａｌｉｎｇ Ｒａｄｉｏ Ｂｅａｒｅｒ ２（ＳＲＢ２）およびＤａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ（ＤＲＢ）をセットアップするための再設定を行う。シグナリングのみの接続については、ＳＲＢ２およびＤＲＢがセットアップされないため、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎに関するステップは省かれる。最後に、ｇＮＢは、初期コンテキストセットアップ応答（ＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＳＰＯＮＳＥ）でセットアップ手順が完了したことをＡＭＦに通知する。

したがって、本開示では、ｇＮｏｄｅＢとのＮｅｘｔ Ｇｅｎｅｒａｔｉｏｎ（ＮＧ）接続を動作時に確立する制御回路と、ｇＮｏｄｅＢとユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）との間のシグナリング無線ベアラがセットアップされるように動作時にＮＧ接続を介してｇＮｏｄｅＢに初期コンテキストセットアップメッセージを送信する送信部と、を備える、５ｔｈ Ｇｅｎｅｒａｔｉｏｎ Ｃｏｒｅ（５ＧＣ）のエンティティ（例えば、ＡＭＦ、ＳＭＦ等）が提供される。具体的には、ｇＮｏｄｅＢは、リソース割当設定情報要素（ＩＥ：Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ）を含むＲａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ（ＲＲＣ）シグナリングをシグナリング無線ベアラを介してＵＥに送信する。そして、ＵＥは、リソース割当設定に基づき上りリンクにおける送信または下りリンクにおける受信を行う。

＜２０２０年以降のＩＭＴの利用シナリオ＞
図４は、５Ｇ ＮＲのためのユースケースのいくつかを示す。３ｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ ｎｅｗ ｒａｄｉｏ（３ＧＰＰ ＮＲ）では、多種多様なサービスおよびアプリケーションをサポートすることがＩＭＴ－２０２０によって構想されていた３つのユースケースが検討されている。大容量・高速通信（ｅＭＢＢ：ｅｎｈａｎｃｅｄ ｍｏｂｉｌｅ－ｂｒｏａｄｂａｎｄ）のための第一段階の仕様の策定が終了している。現在および将来の作業には、ｅＭＢＢのサポートを拡充していくことに加えて、高信頼・超低遅延通信（ＵＲＬＬＣ：ｕｌｔｒａ－ｒｅｌｉａｂｌｅ ａｎｄ ｌｏｗ－ｌａｔｅｎｃｙ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）および多数同時接続マシンタイプ通信（ｍＭＴＣ：ｍａｓｓｉｖｅ ｍａｃｈｉｎｅ－ｔｙｐｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）のための規格化が含まれる。図４は、２０２０年以降のＩＭＴの想定される使用シナリオのいくつかの例を示す（例えば、非特許文献４の図２参照）。

ＵＲＬＬＣのユースケースには、スループット、レイテンシ（遅延）、および可用性のような性能についての厳格な要件があり、ＵＲＬＬＣのユースケースは、工業生産プロセスまたは製造プロセスのワイヤレス制御、遠隔医療手術、スマートグリッドにおける送配電の自動化、交通安全等の今後のこれらのアプリケーションを実現するためのものの１つとして構想されている。ＵＲＬＬＣの超高信頼性は、非特許文献５によって設定された要件を満たす技術を特定することによってサポートされる。リリース１５におけるＮＲ ＵＲＬＬＣでは、重要な要件として、目標とするユーザプレーンのレイテンシがＵＬ（上りリンク）で０．５ｍｓ、ＤＬ（下りリンク）で０．５ｍｓであることが含まれている。一度のパケット送信に対する一般的なＵＲＬＬＣの要件は、ユーザプレーンのレイテンシが１ｍｓの場合、３２バイトのパケットサイズに対してブロック誤り率（ＢＬＥＲ：ｂｌｏｃｋ ｅｒｒｏｒ ｒａｔｅ）が１Ｅ－５であることである。

物理レイヤの観点では、信頼性は、多くの採り得る方法で向上可能である。現在の信頼性向上の余地としては、ＵＲＬＬＣ用の別個のＣＱＩテーブル、よりコンパクトなＤＣＩフォーマット、ＰＤＣＣＨの繰返し等を定義することが含まれる。しかしながら、この余地は、ＮＲが（ＮＲ ＵＲＬＬＣの重要要件に関し）より安定しかつより開発されるにつれて、超高信頼性の実現のために広がりうる。リリース１５におけるＮＲ ＵＲＬＬＣの具体的なユースケースには、拡張現実／仮想現実（ＡＲ／ＶＲ）、ｅ－ヘルス、ｅ－セイフティ、およびミッションクリティカルなアプリケーションが含まれる。

また、ＮＲ ＵＲＬＬＣが目標とする技術拡張は、レイテンシの改善および信頼性の向上を目指している。レイテンシの改善のための技術拡張には、設定可能なニューメロロジー、フレキシブルなマッピングによる非スロットベースのスケジューリング、グラントフリーの（設定されたグラントの）上りリンク、データチャネルにおけるスロットレベルでの繰り返し、および下りリンクでのプリエンプション（Ｐｒｅ－ｅｍｐｔｉｏｎ）が含まれる。プリエンプションとは、リソースが既に割り当てられた送信が停止され、当該既に割り当てられたリソースが、後から要求されたより低いレイテンシ／より高い優先度の要件の他の送信に使用されることを意味する。したがって、既に許可されていた送信は、後の送信によって差し替えられる。プリエンプションは、具体的なサービスタイプと無関係に適用可能である。例えば、サービスタイプＡ（ＵＲＬＬＣ）の送信が、サービスタイプＢ（ｅＭＢＢ等）の送信によって差し替えられてもよい。信頼性向上についての技術拡張には、１Ｅ－５の目標ＢＬＥＲのための専用のＣＱＩ／ＭＣＳテーブルが含まれる。

ｍＭＴＣ（ｍａｓｓｉｖｅ ｍａｃｈｉｎｅ ｔｙｐｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）のユースケースの特徴は、典型的には遅延の影響を受けにくい比較的少量のデータを送信する接続装置の数が極めて多いことである。装置には、低価格であること、および電池寿命が非常に長いことが要求される。ＮＲの観点からは、非常に狭い帯域幅部分を利用することが、ＵＥから見て電力が節約されかつ電池の長寿命化を可能にする１つの解決法である。

上述のように、ＮＲにおける信頼性向上のスコープはより広くなることが予測される。あらゆるケースにとっての重要要件の１つであって、特にＵＲＬＬＣおよびｍＭＴＣに必要な重要要件が高信頼性または超高信頼性である。いくつかのメカニズムが信頼性を無線の観点およびネットワークの観点から向上させることができる。概して、信頼性の向上に役立つ可能性がある２つ～３つの重要な領域が存在する。これらの領域には、コンパクトな制御チャネル情報、データチャネル／制御チャネルの繰り返し、および周波数領域、時間領域、および／または空間領域に関するダイバーシチがある。これらの領域は、特定の通信シナリオにかかわらず一般に信頼性向上に適用可能である。

ＮＲ ＵＲＬＬＣに関し、ファクトリーオートメーション、運送業、および電力の分配のような、要件がより厳しいさらなるユースケースが想定されている。厳しい要件とは、高い信頼性（１０^－６レベルまでの信頼性）、高い可用性、２５６バイトまでのパケットサイズ、数μｓ程度までの時間同期（ｔｉｍｅ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）（ユースケースに応じて、値を、周波数範囲および０．５ｍｓ～１ｍｓ程度の短いレイテンシ（特に、目標とするユーザプレーンでの０．５ｍｓのレイテンシ）に応じて１μｓまたは数μｓとすることができる）である。

さらに、ＮＲ ＵＲＬＬＣについては、物理レイヤの観点からいくつかの技術拡張が有り得る。これらの技術拡張には、コンパクトなＤＣＩに関するＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の拡張、ＰＤＣＣＨの繰り返し、ＰＤＣＣＨのモニタリングの増加がある。また、ＵＣＩ（Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）の拡張は、ｅｎｈａｎｃｅｄ ＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）およびＣＳＩフィードバックの拡張に関係する。また、ミニスロットレベルのホッピングに関係するＰＵＳＣＨの拡張、および再送信／繰り返しの拡張が有り得る。用語「ミニスロット」は、スロットより少数のシンボルを含む送信時間間隔（ＴＴＩ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）を指す（スロットは、１４個のシンボルを備える）。

＜ＱｏＳ制御＞
５ＧのＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）モデルは、ＱｏＳフローに基づいており、保証されたフロービットレートが求められるＱｏＳフロー（ＧＢＲ（Ｇｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ）ＱｏＳフロー）、および、保証されたフロービットレートが求められないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）をいずれもサポートする。したがって、ＮＡＳレベルでは、ＱｏＳフローは、ＰＤＵセッションにおける最も微細な粒度のＱｏＳの区分である。ＱｏＳフローは、ＮＧ－Ｕインタフェースを介してカプセル化ヘッダ（ｅｎｃａｐｓｕｌａｔｉｏｎ ｈｅａｄｅｒ）において搬送されるＱｏＳフローＩＤ（ＱＦＩ：ＱｏＳ Ｆｌｏｗ ＩＤ）によってＰＤＵセッション内で特定される。

各ＵＥについて、５ＧＣは、１つ以上のＰＤＵセッションを確立する。各ＵＥについて、ＰＤＵセッションに合わせて、ＮＧ－ＲＡＮは、例えば図３を参照して上に示したように少なくとも一つのＤａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒｓ（ＤＲＢ）を確立する。また、そのＰＤＵセッションのＱｏＳフローに対する追加のＤＲＢが後から設定可能である（いつ設定するかはＮＧ－ＲＡＮ次第である）。ＮＧ－ＲＡＮは、様々なＰＤＵセッションに属するパケットを様々なＤＲＢにマッピングする。ＵＥおよび５ＧＣにおけるＮＡＳレベルパケットフィルタが、ＵＬパケットおよびＤＬパケットとＱｏＳフローとを関連付けるのに対し、ＵＥおよびＮＧ－ＲＡＮにおけるＡＳレベルマッピングルールは、ＵＬ ＱｏＳフローおよびＤＬ ＱｏＳフローとＤＲＢとを関連付ける。

図５は、５Ｇ ＮＲの非ローミング参照アーキテクチャ（ｎｏｎ－ｒｏａｍｉｎｇ ｒｅｆｅｒｅｎｃｅ ａｒｃｈｉｔｅｃｔｕｒｅ）を示す（非特許文献６の第４．２３節参照）。Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ（ＡＦ）（例えば、図４に例示した、５Ｇのサービスをホストする外部アプリケーションサーバ）は、サービスを提供、例えば、トラフィックのルーティングにアプリケーションの影響を与えること、Ｎｅｔｗｏｒｋ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ（ＮＥＦ）にアクセスすること、またはポリシー制御（例えば、ＱｏＳ制御）のためにポリシーフレームワークとやり取りすること（Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ（ＰＣＦ）参照）をサポートするために３ＧＰＰコアネットワークとやり取りする。オペレーターによる配備に基づいて、オペレーターによって信頼されていると考えられるＡｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎは、関連するＮｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎと直接やり取りすることができる。Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎに直接アクセスすることがオペレーターから許可されていないＡｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎは、ＮＥＦを介することにより外部に対する解放フレームワークを使用して関連するＮｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎとやり取りする。

図５は、５Ｇアーキテクチャのさらなる機能単位、すなわち、Ｎｅｔｗｏｒｋ Ｓｌｉｃｅ Ｓｅｌｅｃｔｉｏｎ Ｆｕｎｃｔｉｏｎ（ＮＳＳＦ）、Ｎｅｔｗｏｒｋ Ｒｅｐｏｓｉｔｏｒｙ Ｆｕｎｃｔｉｏｎ（ＮＲＦ）、Ｕｎｉｆｉｅｄ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ（ＵＤＭ）、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ（ＡＵＳＦ）、Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ（ＡＭＦ）、Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ（ＳＭＦ）、およびＤａｔａ Ｎｅｔｗｏｒｋ（ＤＮ、例えば、オペレーターによるサービス、インターネットアクセス、またはサードパーティーによるサービス）をさらに示す。コアネットワークの機能およびアプリケーションサービスの全部または一部がクラウドコンピューティング環境において展開されかつ動作してもよい。

したがって、本開示では、ＱｏＳ要件に応じたｇＮｏｄｅＢとＵＥとの間の無線ベアラを含むＰＤＵセッションを確立するために、動作時、ＵＲＬＬＣサービス、ｅＭＢＢサービス、およびｍＭＴＣサービスの少なくとも一つに対するＱｏＳ要件を含む要求を５ＧＣの機能（例えば、ＮＥＦ、ＡＭＦ、ＳＭＦ、ＰＣＦ、ＵＰＦ等）の少なくとも一つに送信する送信部と、動作時、確立されたＰＤＵセッションを使用してサービスを行う制御回路と、を備える、アプリケーションサーバ（例えば、５ＧアーキテクチャのＡＦ）が提供される。

＜制御信号＞
本開示において、本開示に係る下りリンク制御信号（情報）は、物理レイヤのＰＤＣＣＨを介して送信される信号（情報）であってもよく、上位レイヤまたはＲＲＣのＭＡＣ Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ（ＣＥ）を介して送信される信号（情報）でありうる。下りリンク制御信号は、予め定義された信号（情報）でありうる。

本開示に係る上りリンク制御信号（情報）は、物理レイヤのＰＵＣＣＨを介して送信される信号（情報）であってもよく、上位レイヤまたはＲＲＣのＭＡＣ ＣＥを介して送信される信号（情報）でありうる。また、上りリンク制御信号は、予め定義される信号（情報）でありうる。上りリンク制御信号は、上りリンク制御情報（ＵＣＩ：Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）、第１段階サイドリンク制御情報（ＳＣＩ：ｓｉｌｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）、または第２段階ＳＣＩでありうる。

＜端末＞
端末またはユーザ端末またはユーザデバイスまたは移動局または移動ノードは、ＬＴＥおよびＮＲではユーザ機器（ＵＥ：ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）と呼ばれる。ユーザ機器（ＵＥ）は、無線電話、スマートフォン、タブレットコンピュータ、またはユーザ機器の機能を備えたＵＳＢ（ユニバーサルシリアルバス）スティックなど、モバイルデバイスまたは通信装置であってもよい。ただし、モバイルデバイスという用語はこれに限定されるものではなく、一般に、中継機もこのようなモバイルデバイスの機能を有することがあり、モバイルデバイスが中継機として機能することもある。例えば、端末は、通信ネットワーク内の物理的なエンティティ（物理ノード）である。さらに、通信デバイスは、ＩｏＴデバイス等のような任意のマシンタイプの通信デバイスであってもよい。１つのノードは、いくつかの機能エンティティを有することができる。機能エンティティとは、同一のまたは他のノードまたはネットワークの他の機能エンティティに所定の機能セットを実現および／または提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードが通信することができる通信設備または媒体にノードを接続する１つまたは複数のインタフェースを有することができる。同様に、ネットワークエンティティは、他の機能エンティティまたは通信相手ノードと通信することができる通信設備または媒体に機能エンティティを接続する論理インタフェースを有してもよい。

＜基地局＞
本開示において、基地局は、例えば、送受信点（ＴＲＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｒｅｃｅｐｔｉｏｎ Ｐｏｉｎｔ）、クラスタヘッド、アクセスポイント、遠隔無線ヘッド（ＲＲＨ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ）、ｅＮｏｄｅＢ（ｅＮＢ）、ｇＮｏｄｅＢ（ｇＮＢ）、基地局（ＢＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）、基地局送受信部（ＢＴＳ：Ｂａｓｅ Ｔｒａｎｓｃｅｉｖｅｒ Ｓｔａｔｉｏｎ）、ベースユニット（ｂａｓｅ ｕｎｉｔ）、またはゲートウェイでありうる。また、サイドリンク通信では、基地局の代わりに端末が用いられうる。基地局は、上位ノードと端末との間の通信を中継する中継装置でありうる。基地局は、路側機でありうる。基地局は、例えば、端末にサービスを提供するためのネットワークの一部を形成するスケジューリングノードまたはネットワークノードであってもよい。特に、基地局は端末に無線アクセスを提供することができる。端末と基地局との間の通信は一般的に標準化されており、ＰＨＹ、ＭＡＣ、ＲＲＣなどの異なる層によって定義することができる。ＬＴＥおよびＮＲでは、無線インターフェイスプロトコルスタックには、物理層、媒体アクセス層（ＭＡＣ）、および上位レイヤが含まれる。制御プレーンには、上位レイヤプロトコルである無線リソース制御プロトコルが提供される。ＲＲＣを介して、基地局は端末の設定を制御することができ、端末は基地局と通信して、接続およびベアラの確立、変更などの制御タスク、測定、その他の機能を実行することができる。ＬＴＥで使用される用語はｅＮＢ（またはｅＮｏｄｅＢ）であり、５Ｇ ＮＲで現在使用されている用語はｇＮＢである。ここでの基地局または無線基地局という用語は、通信ネットワーク内の物理的なエンティティを指す。移動局と同様に、基地局はいくつかの機能エンティティを有してもよい。機能エンティティとは、同一のまたは他のノードまたはネットワークの他の機能エンティティに所定の機能セットを実現および／または提供するソフトウェアまたはハードウェアモジュールを指す。物理エンティティは、スケジューリングおよび設定の１つまたは複数を含む、通信デバイスに関するいくつかの制御タスクを実行する。基地局機能および通信デバイス機能はまた、単一のデバイス内に統合されうることに留意されたい。例えば、移動端末は、他の端末のための基地局の機能も実装してよい。ＬＴＥで使用される用語はｅＮＢ（またはｅＮｏｄｅＢ）であり、５Ｇ ＮＲで現在使用されている用語はｇＮＢである。

＜上りリンク／下りリンク／サイドリンク＞
本開示は、上りリンク、下りリンク、およびサイドリンクのいずれに適用されてもよい。

例えば、本開示を上りリンクのＰＵＳＣＨ、ＰＵＣＣＨ、ＰＲＡＣＨ、下りリンクのＰＤＳＣＨ、ＰＤＣＣＨ、ＰＢＣＨ、サイドリンクのＰＳＳＣＨ（物理サイドリンク共有チャネル：Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）、ＰＳＣＣＨ（物理サイドリンク制御チャネル：Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＰＳＢＣＨ（物理サイドリンク報知チャネル：Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ）に適用してもよい。

ＰＤＣＣＨ、ＰＤＳＣＨ、ＰＵＳＣＨ、およびＰＵＣＣＨは、それぞれ、下りリンク制御チャネル、下りリンクデータチャネル、上りリンクデータチャネル、上りリンク制御チャネルの一例である。ＰＳＣＣＨおよびＰＳＳＣＨは、それぞれ、サイドリンク制御チャネルおよびサイドリンクデータチャネルの例である。ＰＢＣＨおよびＰＳＢＣＨはそれぞれ、報知チャネルの例であり、ＰＲＡＣＨは、ランダムアクセスチャネルの例である。

＜データチャネル／制御チャネル＞
本開示は、データチャネルおよび制御チャネルのいずれに適用されてもよい。本開示におけるチャネルは、ＰＤＳＣＨ、ＰＵＳＣＨ、およびＰＳＳＣＨを含むデータチャネル、ならびに／またはＰＤＣＣＨ、ＰＵＣＣＨ、ＰＢＣＨ、ＰＳＣＣＨ、およびＰＳＢＣＨを含む制御チャネルと置き換えられうる。

＜参照信号＞
本開示では、参照信号は、基地局と移動局の両方に既知の信号であり、各参照信号は、参照信号（ＲＳ）またはパイロット信号と呼ばれることがある。参照信号は、ＤＭＲＳ、チャネル状態情報－参照信号（ＣＳＩ－ＲＳ：Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ － Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）、トラッキング参照信号（ＴＲＳ：Ｔｒａｃｋｉｎｇ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）、位相トラッキング参照信号（ＰＴＲＳ：Ｐｈａｓｅ Ｔｒａｃｋｉｎｇ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）、セル固有参照信号（ＣＲＳ：Ｃｅｌｌ－ｓｐｅｃｉｆｉｃ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）、およびサウンディング参照信号（ＳＲＳ：Ｓｏｕｎｄｉｎｇ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）のうちのいずれかでありうる。

＜時間間隔＞
本開示では、時間リソース単位は、スロットおよびシンボルの１つまたは組合せに限定されず、フレーム、スーパーフレーム、サブフレーム、スロット、タイムスロットのサブスロット、ミニスロット、またはシンボル、直交周波数分割多重（ＯＦＤＭ：Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）シンボル、シングルキャリア周波数分割多重アクセス（ＳＣ－ＦＤＭＡ：Ｓｉｎｇｌｅ Ｃａｒｒｉｅｒ－Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ Ａｃｃｅｓｓ）シンボル、または他の時間リソース単位などの時間リソース単位であってよい。１スロットに含まれるシンボルの数は、上述した実施の形態で例示したシンボルの数に限定されるものではなく、他のシンボルの数であってもよい。

＜周波数帯域＞
本開示は、ライセンスバンドおよびアンライセンスバンドのいずれに適用されてもよい。

＜通信＞
本開示は、基地局と端末との通信（Ｕｕリンク通信）、端末と端末との通信（サイドリンク通信）、およびＶ２Ｘ（Ｖｅｈｉｃｌｅ ｔｏ Ｅｖｅｒｙｔｈｉｎｇ）通信のいずれに適用されてもよい。本開示におけるチャネルは、ＰＳＣＣＨ、ＰＳＳＣＨ、物理サイドリンクフィードバックチャネル（ＰＳＦＣＨ）、ＰＳＢＣＨ、ＰＤＣＣＨ、ＰＵＣＣＨ、ＰＤＳＣＨ、ＰＵＳＣＨ、およびＰＢＣＨと言い換えてもよい。

また、本開示は、地上のネットワーク、または、衛星もしくは高度疑似衛星（ＨＡＰＳ：Ｈｉｇｈ Ａｌｔｉｔｕｄｅ Ｐｓｅｕｄｏ Ｓａｔｅｌｌｉｔｅ）を用いた地上ネットワーク以外のネットワーク（ＮＴＮ：Ｎｏｎ－Ｔｅｒｒｅｓｔｒｉａｌ Ｎｅｔｗｏｒｋ）のいずれにも適用することができる。また、本開示は、セルサイズが大きいネットワークや、超広帯域送信ネットワークのようにシンボル長またはスロット長に比べて遅延が大きい地上ネットワークにも適用されうる。

＜アンテナポート＞
アンテナポートは、１つまたは複数の物理アンテナから形成される論理アンテナ（アンテナグループ）を指す。すなわち、アンテナポートとは、必ずしも１つの物理アンテナを指すのではなく、複数のアンテナ等からなるアレーアンテナを指す場合もある。例えば、アンテナポートを構成する物理アンテナの数は定義されておらず、その代わりに、アンテナポートは、端末が参照信号を送信することを許可される最小単位として定義される。アンテナポートはまた、プリコーディングベクトル重み付けの乗算のための最小単位として定義されうる。

＜下りリンク制御チャネルの監視、ＰＤＣＣＨ、ＤＣＩ＞
ＵＥによって実行される機能の多くは、例えばＵＥ宛の特定の制御情報またはデータを受信するために下りリンク制御チャネル（例えばＰＤＣＣＨ、非特許文献１の５．２．３節を参照）を監視することを含む。

以下は、このような機能のリスト（すべてを網羅していない）を示す。
－ ページングメッセージ監視機能、
－ システム情報取得機能、
－ 不連続受信（ＤＲＸ）機能におけるシグナリング監視動作、
－ 不連続受信（ＤＲＸ）機能における非アクティブ性（ｉｎａｃｔｉｖｉｔｙ）監視動作、
－ ランダムアクセス機能におけるランダムアクセス応答の受信、
－ パケットデータコンバージェンスプロトコル（ＰＤＣＰ）レイヤのリオーダリング機能

上述したように、ＰＤＣＣＨの監視は、制御情報およびユーザトラフィック（例えばＰＤＣＣＨ上のＤＣＩ、ＰＤＣＣＨによって示されるＰＤＳＣＨ上のユーザデータ）など、ＵＥを対象とする情報を識別して受信するために、ＵＥによって行われる。

下りリンクにおける制御情報（下りリンク制御情報、ＤＣＩと呼ぶことができる）は、５Ｇ ＮＲではＬＴＥのＤＣＩと同じ目的を有し、すなわち、例えば下りリンクデータチャネル（例：ＰＤＳＣＨ）または上りリンクデータチャネル（例：ＰＵＳＣＨ）をスケジューリングする特別な制御情報のセットである。５Ｇ ＮＲでは、すでに多くの異なるＤＣＩフォーマットが定義されている（非特許文献７の７．３．１節を参照）。

これらのＤＣＩフォーマットは、それぞれの情報が形成されて送信される所定のフォーマットを表している。特に、ＤＣＩフォーマット０＿１および１＿１は、それぞれ、１つのセルにおいてＰＵＳＣＨおよびＰＤＳＣＨをスケジューリングするために使用される。

これらの機能それぞれにおけるＰＤＣＣＨ監視は、特定の目的を果たし、したがってその目的のために開始される。ＰＤＣＣＨ監視は、一般に、ＵＥが動作させるタイマーに少なくとも基づいて制御される。タイマーはＰＤＣＣＨ監視を制御する目的を有し、例えば、ＵＥがＰＤＣＣＨを監視する最大時間長を制限する。例えば、ＵＥはＰＤＣＣＨを無期限に監視する必要はなく、電力を節約できるように、ある時間後に監視を停止することができる。

上述したように、ＰＤＣＣＨにおけるＤＣＩの目的の１つは、下りリンクまたは上りリンク、あるいはサイドリンクにおけるリソースを動的にスケジューリングすることである。特に、ＤＣＩのいくつかのフォーマットは、特定のユーザのためにデータチャネルに割り当てられるリソースの指示（リソース割当て、ＲＡ）を伝えるために提供されている。リソース割当ては、周波数領域および／または時間領域におけるリソースの指定を含むことができる。

＜物理リソースブロック＞
一般に、「物理リソースブロック」（ＰＲＢ：ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）という用語は、（ユーザ）データの送信に使用可能な最小の割当て可能なリソース単位を指す。ＬＴＥおよびＮＲでは、ＰＲＢは、周波数領域における所定の数（例えば１２）の連続するサブキャリアと、時間領域における所定の数のシンボル（例えばＬＴＥでは１４個のＯＦＤＭシンボル）とを有する。

＜専門用語＞
以下では、５Ｇ移動通信システムにおいて想定される新しい無線アクセス技術のためのＵＥ、基地局、および手順について説明する（ただしこれらはＬＴＥ移動通信システムでも使用することができる）。様々な実装形態および変形例も同様に説明される。以下の開示は、上述の議論および発見によって促進され、例えば、その少なくとも一部に基づくことができる。

一般に、本開示の基礎をなす原理を明確かつ理解可能な方法で説明することができるように、本明細書では多くの想定がなされていることに留意されたい。しかしながら、これらの想定は、本開示の範囲を限定すべきではない、例示目的のために本明細書で行われる単なる例として理解されるべきである。

さらに、次の３ＧＰＰ ５Ｇ通信システムのための新しい無線アクセス技術のコンテキストで使用される特定の用語は、まだ完全に決定されていない、または最終的に変更される可能性があるが、以下で使用されている手順、エンティティ、層などの用語のいくつかは、ＬＴＥ／ＬＴＥ－Ａシステムに、または現在の３ＧＰＰ ５Ｇ標準化において使用されている用語に、密接に関連している。したがって、用語は将来的に変更されうるが、実施の形態の機能に影響を与えることはない。したがって、実施形態およびその保護範囲は、より新しいまたは最終的に合意された専門用語が存在しないために本明細書で例示的に使用されている特定の用語に制限されるものではなく、本開示の機能および原理の基礎をなす機能およびコンセプトの観点においてより広義に理解されるべきであることが、当業者には認識されるであろう。

＜実施の形態＞
本開示は、優先基準に基づく効率的な上りリンク制御情報（ＵＣＩ）送信のための技術を提供する。特に、本開示により、同一のＨＡＲＱプロセスＩＤを有するＨＡＲＱプロセスの衝突が回避され得、トラフィックのＱｏＳ要件を考慮に入れたＵＣＩの送信が容易化され得、すべてＵＬ制御リソースの使用および電力消費が低減され得、ＵＣＩの内容に応じた異なる信頼性が容易に実現され得る。

本開示は、ＵＣＩに関連するため、スケジューリングされるデバイス（通常、通信デバイス／送受信デバイス／ＵＥ）およびスケジューリングデバイス（通常、ネットワークノード）の両エンティティが参加する。したがって、本開示は、基地局およびユーザ機器を提供する。図６に示すように、ユーザ機器６１０および基地局６６０は、無線通信システム内の無線チャネル６５０を介して互いに通信してよい。例えば、ユーザ機器はＮＲユーザ機器であり得、基地局は、ＮＲ ｇＮＢ、特に地上ネットワーク（ＴＮ：Ｔｅｒｒｅｓｔｒｉａｌ Ｎｅｔｗｏｒｋ）ＮＲシステムまたは非地上ネットワーク（ＮＴＮ：Ｎｏｎ－Ｔｅｒｒｅｓｔｒｉａｌ Ｎｅｔｗｏｒｋ）ＮＲシステムにおけるｇＮＢなどのネットワークノードまたはスケジューリングノードであり得る。したがって、詳細および実施の形態は、明示的な言及または文脈が他を示さない限り、ＵＥ、スケジューリングデバイス（スケジューリングノード）、ならびにＵＥおよびスケジューリングデバイスのための方法の各々に適用される。特に、本開示では、ＵＥが特定の方法を使用して（例えば、特定の優先基準に基づいて）判定を行う場合、ＵＣＩを受信した基地局は、当該特定の方法に対応する方法を使用して（例えば、同一または同様の特定の優先基準に基づいて）、ＵＣＩのタイプを判定してよい。

本開示はさらに、スケジューリングされるデバイスおよびスケジューリングデバイス、ならびに対応する方法およびプログラムを含むシステムを提供する。このような通信システムの一例を図６に示す。通信システム６００は、５Ｇの技術仕様による無線通信システム、特にＮＲ通信システムでありうる。ただし、本開示は、３ＧＰＰ ＮＲに限定されず、ＮＴＮなどの他の無線システムまたはセルラーシステムにも適用されうる。

図６は、ユーザ機器６１０（通信デバイスとも呼ばれる）と、基地局（ネットワークノード）、例えば、ｅＮＢまたはｇＮＢに位置すると例示的に想定されるスケジューリングデバイス６６０と、を示す一般的な、簡略化された、例示的なブロック図を示す。ただし、一般に、スケジューリングデバイスは、２つの端末間のサイドリンク接続の場合は端末でありうる。さらに、特に、ＵＲＬＬＣ、ｅＭＢＢ、およびｍＭＴＣのユースケースに関して、通信デバイス６１０は、センサデバイス、ウェアラブルデバイス、またはコネクテッド車両、または産業工場における自動化マシンのコントローラであってもよい。さらに、通信デバイス６１０は、基地局６６０と他の通信デバイスとの間の中継機として機能可能であり得る（例えば、本開示は、通信「端末」またはユーザ「端末」に限定されない）。

ＵＥおよびｅＮＢ／ｇＮＢは、それぞれの送受信部６２０（ＵＥ側）および６７０（基地局側）を使用して、（無線）物理チャネル６５０を介して互いに通信している。基地局６６０および端末６１０は、共に通信システム６００を形成する。通信システム６００は、図１に示されるもの以外に他のエンティティをさらに含んでよい。

図６に示すように、いくつかの実施の形態では、ユーザ機器（ＵＥ）６１０は、送受信部６２０および回路６３０を備える。回路６３０は、動作時に、（ｉ）ＵＣＩ送信用の複数の送信機会を示す通知を取得し、（ｉｉ）ＵＣＩが送信に利用可能であると判定し、（ｉｉｉ）利用可能なＵＣＩを送信するための複数の送信機会のうちの送信機会を使用するか否かを、利用可能なＵＣＩに関連付けられた優先基準に基づいて判定する。送受信部６２０は、動作時に、利用可能なＵＣＩの送信に送信機会が使用されると判定される場合、利用可能なＵＣＩを送信するために送信機会を使用する。

通常、利用可能なＵＣＩは、複数のＵＣＩ部分を含んでよい。ＵＣＩ部分は、例えば、ＨＡＲＱ報告、チャネル品質インジケータ（ＣＱＩ：Ｃｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｄｉｃｔｏｒ）、またはスケジューリング要求（ＳＲ：Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ）でありうる。さらに、利用可能なＵＣＩという用語は、たとえば上位レイヤから到着したものであって、送信に利用可能なＵＣＩ／送信の準備ができているＵＣＩを指すことに留意されたい。

図７Ａは、回路６３０の機能構成を示す。具体的には、回路６３０の機能構成は、送受信部制御回路７１０を含む。送受信部制御回路７１０は、動作時に、送受信部を制御する。例えば、この制御は、ＵＣＩを送信するように送受信部６２０を制御すること、優先基準を示す通知を含むシグナリングを受信するように送受信部６２０を制御すること、送信機会を示す通知を含むシグナリングを受信するように送受信部６２０を制御すること、および／またはＤＬトラフィックを受信するように送受信部６２０を制御することを含んでよい。例えば、送受信部制御回路７１０は、そのようなシグナリングを復号するように送受信部６２０を制御する。さらに、回路６３０は、優先基準取得回路７２０、送信機会取得回路７３０、および／または送信機会使用判定回路７４０を含んでよい。優先基準取得回路７２０は、優先基準を示す通知を取得し、かつ／または、例えば、送受信部６２０によって受信されたシグナリングまたは通知から抽出（または解析）することによって優先基準を取得してよい。送信機会取得回路７３０は、送信機会を示す（１つまたは複数の）通知を取得し、かつ／または、例えば、送受信部６２０によって受信された（１つまたは複数の）シグナリングまたは（１つまたは複数の）通知から抽出（または解析）することによって送信機会を取得してよい。送信機会使用判定回路７４０は、ＵＣＩが送信に利用可能であるか否かを判定することができ、ＵＣＩが送信に利用可能である場合、（ｉ）利用可能なＵＣＩの送信用に使用する送信機会を使用するか否か、（ｉｉ）利用可能なＵＣＩの送信用にどの送信機会を使用するか、および／または（ｉｉｉ）送信用に使用される送信機会によって、利用可能なＵＣＩのうちのどのＵＣＩが送信されるか（特に、送信機会のペイロードサイズが、すべての利用可能なＵＣＩを送信するには小さすぎる場合）を判定してよい。

なお、回路６３０は、１つまたは複数のプロセッサを含む一般的な処理回路であってよく、この処理回路は、メモリ（メモリは、回路の一部であってもよい）に記憶されたコード命令を実行してよく、各回路７１０～７４０についての上述の機能に対応するコード命令の一部を含んでもよい。しかしながら、本開示は、任意の特定の回路に限定されず、本開示の実施の形態は、専用のハードウェア、プログラマブルハードウェア、汎用ハードウェア、またはそれらの任意の組合せを含んでよい。特に、回路７１０～７４０は、異なる回路（ハードウェア）であっても、同じ回路であってもよい。

図６にも示されるように、いくつかの実施の形態では、基地局６６０（またはスケジューリングデバイス６６０）は、回路６８０および送受信部６７０を備える。回路６８０は、動作時に、（ｉ）利用可能なＵＣＩを送信するための複数の送信機会のうちの送信機会を使用するか否かを判定する際に基づく優先基準を決定し、（ｉｉ）優先基準を示す通知を含む第１のシグナリング情報を生成し、（ｉｉｉ）ＵＣＩ送信用の複数の送信機会を決定し、（ｉｖ）複数の送信機会を示す通知を含む第２のシグナリング情報を生成する。送受信部６７０は、動作時に、（ｉ）第１のシグナリング情報を送信し、（ｉｉ）第２のシグナリング情報を送信する。

しかしながら、本発明は、いくつかの実施の形態のように（前の段落に記載された基地局の特徴に代えてまたはそれに加えて）、動作時に、送受信部６７０は、ｉ）ＵＣＩ送信用の複数の送信機会を示す通知を含むシグナリング情報を送信し、ｉｉ）送信機会のうちの１つにおいて、１つまたは複数のＵＣＩ部分を受信し、回路６８０は、動作時に、ｉ）シグナリング情報を生成し、ｉｉ）ＵＣＩに関連付けられた優先基準に基づいて、１つまたは複数の受信されたＵＣＩ部分の各々について、受信されたＵＣＩ部分のＵＣＩタイプを判定する。

図７Ｂは、回路６８０の機能構成を示す。具体的には、送受信部制御回路７５０を含む。送受信部制御回路７５０は、動作時に、送受信部を制御する。例えば、この制御は、ＵＣＩを受信するように送受信部６７０を制御すること、優先基準を示す通知を含むシグナリングを送信するように送受信部６７０を制御すること、送信機会を示す通知を含むシグナリングを送信するように送受信部６７０を制御すること、および／またはＤＬトラフィックを送信するように送受信部６７０を制御することを含んでよい。さらに、回路６８０は、優先基準処理回路７６０、送信機会処理回路７７０、および／またはＵＣＩタイプ判定回路７８０を含んでよい。優先基準処理回路７６０は、優先基準を決定し、決定された優先基準を示す通知（またはそのような通知を含むシグナリング）を生成してよい。送信機会処理回路７７０は、送信機会を決定し、決定された送信機会を示す通知（またはそのような通知を含むシグナリング）を生成してよい。ＵＣＩタイプ判定回路７８０は、受信されたＵＣＩのタイプを判定してよい。

通信デバイス６１０は、送受信部６２０および（処理）回路６３０を備えてよく、スケジューリングデバイス６６０は、送受信部６７０および（処理）回路６８０を備えてよい。そして、送受信部６２０は、受信部および／もしくは送信部を備え、かつ／または受信部および／もしくは送信部として機能してよい。言い換えれば、本開示では、「送受信部」という用語は、通信デバイス６１０または基地局６６０が無線チャネル６５０を介して、それぞれ、無線信号を送信および／または受信することを可能にするハードウェア構成要素およびソフトウェア構成要素に対して使用される。したがって、送受信部は、受信部、送信部、または受信部と送信部との組合せに対応する。典型的には、基地局および通信デバイスは、無線信号を送信することも受信することもできると想定される。しかしながら、特に、ｅＭＢＢ、ｍＭＴＣ、およびＵＲＬＬＣ（スマートホーム、スマートシティ、産業自動化など）のいくつかの用途に関して、センサーなどのデバイスが信号を受信するのみのケースが考えられる。さらに、「回路」という用語は、１つまたは複数のプロセッサまたは処理ユニットなどによって形成される処理回路を含む。

回路（または処理回路）は、１つ以上のプロセッサまたは任意のＬＳＩなどの１つ以上のハードウェアであってもよい。送受信部と処理回路との間には、入力／出力点（またはノード）があり、処理回路は、動作時、送受信部を制御する、すなわち、受信部および／または送信部を制御し、受信／送信データを交換することができる。送受信部は、送信部および受信部として、１つまたは複数のアンテナ、増幅器、無線周波数（ＲＦ：Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）変調器／復調器等を含むＲＦフロントを含んでよい。処理回路は、送受信部を制御することにより、処理回路によって提供されるユーザデータおよび制御データを送信すること、および／または処理回路によってさらに処理されるユーザデータおよび制御データを受信する等の制御タスクを実施してよい。処理回路はまた、判定、決定、計算、測定等の他のプロセスの実行を担っていてもよい。送信部は、送信のプロセスおよびそれに関連する他のプロセスの実行を担っていてもよい。受信部は、受信のプロセスおよびそれに関連する他のプロセスの実行を担っていてもよい。

以下で説明するステップ／動作のいずれも、（ＵＥ側の）回路６３０および／または（基地局側の）回路６８０によって実行または制御され得ることにさらに留意されたい。

上述のＵＥに対応して、ＵＥによって／ＵＥのために実行される方法が提供される。図８に示すように、本方法は、（ｉ）ＵＣＩ送信用の複数の送信機会を示す通知を取得するステップＳ８５５と、（ｉｉ）ＵＣＩが送信に利用可能であると（利用可能であるか否かを）判定するステップＳ８６５と、（ｉｉｉ）（ＵＣＩが利用可能であると判定Ｓ８６５される場合）利用可能なＵＣＩに関連付けられた優先基準に基づいて、利用可能なＵＣＩを送信するための複数の送信機会のうちの送信機会を使用するか否かを判定するステップＳ８７５と、（ｉｖ）利用可能なＵＣＩの送信用の送信機会を使用するために、送信機会が使用されると判定される場合、送信機会を使用して利用可能なＵＣＩを送信するステップＳ８８５と、を含む。また、図８に示されるように、本方法は、優先基準を示す通知を含むシグナリング（またはシグナリング情報）を受信するステップＳ８２５、（例えば、シグナリングを受信するステップＳ８２５から）優先基準を取得するステップＳ８３５、および／または複数の送信機会を示す通知を含むシグナリング（またはシグナリング情報）を受信するステップＳ８４５も含んでよい。

さらに、上述の基地局に対応して、スケジューリングデバイスによって／スケジューリングデバイスのために実行される方法が提供される。また、図８に示されるように、本方法は、（ｉ）利用可能なＵＣＩを送信するための複数の送信機会のうちの送信機会を使用するか否かを判定する際に基づく優先基準を決定するステップＳ８００と、（ｉｉ）優先基準を示す通知を含む第１のシグナリング情報を生成するステップＳ８１０と、（ｉｉｉ）第１のシグナリング情報を送信するステップＳ８２０と、（ｉｖ）ＵＣＩ送信用の複数の送信機会を決定するステップＳ８３０と、（ｖ）複数の送信機会を示す通知を含む第２のシグナリング情報を生成するステップＳ８４０と、（ｖｉ）第２のシグナリング情報を送信するステップＳ８５０と、を含む。

しかし、本発明は、上記に限定されず、いくつかの実施の形態のように（前の段落で説明した基地局の方法のステップに代えてまたはそれに加えて）、スケジューリングデバイスによって／スケジューリングデバイスのために実行される方法が提供される。この方法は、（ｉ）ＵＣＩ送信用の複数の送信機会を示す通知を含むシグナリング情報を生成するステップＳ８４０と、（ｉｉ）生成されたシグナリング情報を送信するステップＳ８５０と、（ｉｉｉ）送信機会のうちの１つにおいて、１つまたは複数のＵＣＩ部分を受信するステップＳ８６０と、（ｉｖ）ＵＣＩに関連付けられた優先基準に基づいて、１つまたは複数のＵＣＩ部分の各々について、ＵＣＩ部分のＵＣＩタイプを判定するステップＳ８７０と、を含む。

概して、優先基準および送信機会は、別々にまたは一緒に判定され得、第１のシグナリングおよび第２のシグナリングは、別々にまたは一緒に生成され得、および／または第１のシグナリングおよび第２のシグナリングは、別々にまたは一緒に送信され得ることに留意されたい。例えば、基地局は、図８に示すように、最初に優先度信号を送信し、次いで、（複数の送信のために）ＵＣＩリソースを割り当ててよい。ただし、本発明は、これらのステップのいかなる特定の順序にも限定されないし、これらのステップのすべてが必ず実行されるわけでもない。例えば、優先基準は、規格において予め定義されてもよく、ステップＳ８００、Ｓ８１０、Ｓ８２０、Ｓ８２５、およびＳ８３５は実行されなくてもよい。

＜半永続的スケジューリング（ＳＰＳ：Ｓｅｍｉ－Ｐｅｒｓｉｓｔｅｎｔ Ｓｃｈｅｄｕｌｉｎｇ）＞
一般に、ＵＥには、１つまたは複数のＳＰＳ設定が設定され得る（本開示では、ＳＰＳ設定はＳＰＳとも呼ばれる）。ＳＰＳ設定は、通常、基地局によってＤＬ送信用に設定された周期的なＤＬリソースセットに対応する。すなわち、ＳＰＳ設定のリソースは、通常、時間領域における或る周期性に従う。この周期性において、ＳＰＳの連続する（連続的な）リソース割当の間に或る時間間隔がある。

設定されたＳＰＳは、それぞれのＤＬ ＳＰＳトラフィックに対応し、それぞれの特定のＨＡＲＱプロセスＩＤに関連付けられる。すなわち、一般に、各ＳＰＳは、それぞれのＨＡＲＱプロセスＩＤに関連付けられ得る。ＳＰＳの送信（ＳＰＳ設定のリソースにおいて受信される送信）は、本明細書では、ＤＬトラフィックと呼ばれることもあり、ＳＰＳの単一のリソース割当において送信されるＳＰＳの個々の送信は、ＤＬトラフィックのインスタンスと呼ばれることもある。

３ＧＰＰは、Ｒｅｌ．１７において、製造業における改良されたモノのインターネット（ＩＩｏＴ：Ｉｎｄｕｓｔｒｉａｌ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）および超高信頼・低遅延通信（ＵＲＬＬＣ）のための拡張に取り組んでいる。これは、ＨＡＲＱ－ＡＣＫおよびＣＱＩ送信などのＵＥフィードバックを改良することを含む。半永続的スケジューリング（ＳＰＳ）は、下りリンク（ＤＬ）データ送信用のリソースと、上りリンク（ＵＬ）の関連付けられたＨＡＲＱ－ＡＣＫフィードバックとをリザーブすることによって、ＴＳＮ（Ｔｉｍｅ Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋ：時間に対してセンシティブなネットワーク）などの確定的（ｄｅｔｅｒｍｉｎｉｓｔｉｃ）ＵＲＬＬＣトラフィックのために活用され得る。時分割複信（ＴＤＤ）においてＳＰＳの実現が困難になり得るのは、特に、ＨＡＲＱ－ＡＣＫ報告用のリザーブされたリソースがＤＬ／半静的シンボルと衝突する場合である。そのような場合、ＨＡＲＱ－ＡＣＫ報告は、後の送信のためにドロップされるか、または延期されるべきである。ＨＡＲＱ－ＡＣＫをドロップすることは、通信の信頼性を低下させ得る。一方、ＨＡＲＱ－ＡＣＫを延期すると、レイテンシを増大させたり、ＨＡＲＱプロセスの衝突につながったりすることがある。

＜ＤＬシンボルの衝突＞
非特許文献８では、ＴＤＤにおいてドロップされたＳＰＳ ＨＡＲＱ－ＡＣＫビットを延期するために、対象のＵＬスロット／サブスロットと、準静的ＤＬシンボル、ＳＳＢおよびＣＯＲＥＳＥＴ＃０とが衝突する場合、当該対象のスロット／サブスロット内の（すべての）シンボルが「無効」または「ＵＬ送信のためのシンボルなし」と見なされることが合意されている。

したがって、特に、ＵＥが時分割複信（ＴＤＤ）で動作しているとき、（任意の）利用可能なＵＣＩを送信するために送信機会が使用されるべきではない１つまたは複数のＤＬシンボルと衝突する送信機会が判定され得る。

さらに、ｋ１ｄｅｆまたはｋ１＋ｋ１ｄｅｆを単位としたＳＰＳ ＨＡＲＱの最大遅延の制限がサポートされるべきである。制限は、例えば、最大値ｋ１ｄｅｆまたは最大値ｋ１ｄｅｆｆ＝ｋ１＋ｋ１ｄｅｆによって与えられ、例えば、Ｋ１設定またはＲＲＣに設定された制限によって決定されうる。ＳＰＳ ＨＡＲＱの最大の延期の制限は、ｋ１ｅｆｆ＝ｋ１＋ｋ１ｄｅｆを単位として定義され得、ｋ１ｄｅｆに関して定義される下限値はなくてもよい。

＜ＨＡＲＱプロセスの衝突＞
Ｒｅｌ－１５およびＲｅｌ－１６では、ＳＰＳに対するＨＡＲＱ－ＡＣＫフィードバックは、上りリンク送信に使用できないシンボルと衝突すると、ドロップされる。したがって、ＵＥが或るＨＡＲＱプロセスＩＤのＰＤＳＣＨを受信する場合、このＨＡＲＱプロセスＩＤの延期されたＳＰＳ ＨＡＲＱビットは、ドロップされなければならないことがあり、かつ／または最初のＨＡＲＱ－ＡＣＫ送信機会によって、不規則なＨＡＲＱ状況となりうる。

しかしながら、不対スペクトル（ｕｎｓｐａｉｒｅｄ ｓｐｅｃｔｒｕｍ）では、ＤＬが多い設定（ＤＬ ｈｅａｖｙ ｃｏｎｆｉｇｕｒａｔｉｏｎｓ）および複数のＳＰＳ設定が、ＨＡＲＱ－ＡＣＫの頻繁なドロップを引き起こし得、これにより、リソースが浪費され、システム性能に悪影響を及ぼし得る。ＳＦＩによってＵＬに示されない少なくとも１つのＤＬシンボルまたは少なくとも１つのフレキシブルシンボルとＰＵＣＣＨとの衝突に起因するＴＤＤにおけるＳＰＳ ＨＡＲＱ－ＡＣＫドロップを回避するために、ＨＡＲＱ報告は、先送り／延期され、かつ／または後のスロット／サブスロットにおける他の既存のフィードバック情報／ＵＣＩと多重されうる。

ＵＬ送信に無効なシンボルは、半静的ＤＬシンボル、ＳＳＢ、およびＣＯＲＥＳＥＴ＃０であり得る。利用可能なＰＵＣＣＨリソース／シンボルは、半静的に設定された上りリンクシンボルと、動的ＳＦＩおよび／または動的ＤＣＩによって上りリンクシンボルとして示される半静的フレキシブルシンボルとを含む、上りリンクシンボル中に位置し得る。しかしながら、フレキシブルシンボルは、動的ＳＦＩおよび／または動的スケジューリングＤＣＩによって上りリンクシンボルに変更されない限り、使用されない場合がある。

第１の利用可能なＰＵＣＣＨのＰＵＣＣＨリソースは、延期されたＳＰＳ ＰＵＣＣＨ ＨＡＲＱの瞬間の時間的に後に利用可能な第１のＰＵＣＣＨリソースとして定義することができる。ＳＰＳ ＰＤＳＣＨのみのためのＨＡＲＱ－ＡＣＫ用のＰＵＣＣＨリソース（ＳＰＳ－ＰＵＣＣＨ－ＡＮ－Ｌｉｓｔ－ｒ１６において設定されたＰＵＣＣＨリソース）および動的ＰＤＳＣＨのためのＨＡＲＱ－ＡＣＫ用のＰＵＣＣＨリソース（ＰＵＣＣＨ－ＲｅｓｏｕｒｃｅＳｅｔにおいて設定されたＰＵＣＣＨリソース）の両方を、どちらが最初に利用可能であるかに応じて、第１の利用可能なＰＵＣＣＨとすることができる。

より短いＳＰＳ周期性では、ＳＰＳ ＨＡＲＱ－ＡＣＫリソースと半静的ＵＬ／ＤＬ設定との衝突は、特にＤＬが多いＴＤＤのフレーム構造において頻繁に起こり得る。これにより、多くのＳＰＳ ＰＤＳＣＨを再送する必要があるため、ＤＬ ＳＰＳのパフォーマンスが低下しうる。

＜送信機会＞
本開示において、「送信機会」という用語は、ＵＣＩ送信用のＵＬリソースを指す。一般に、送信機会は、基地局によって決定され得、対応する通知がＵＥに送信され得る。そして、ＵＥは、この通知（例えば、ＰＵＣＣＨまたはＰＵＳＣＨに関してスケジューリングデバイスから受信したＤＣＩシグナリング）から送信機会を取得および／または決定してよい。ただし、本発明はこれに限定されない。一般に、ＰＵＣＣＨリソースは、事前にリザーブされなくてもよく、例えば、ｋ１値に従って使用され得る。一般に、いくつかの送信機会が基地局によって設定され、他の送信機会がｋ１／タイミング値に基づいて動的に決定されることも可能である。

＜優先基準＞
本開示では、「優先基準」という用語は、（ＵＣＩが利用可能であると判定される場合／時に）（例えば、ステップＳ８７５において）（ｉ）利用可能なＵＣＩの送信用に使用する送信機会を使用するか否か、（ｉｉ）利用可能なＵＣＩの送信用にどの送信機会を使用するか、および／または（ｉｉｉ）利用可能なＵＣＩのうちのどのＵＣＩが送信に使用される送信機会を用いて送信されるか、を判定するためにＵＥが使用し得る任意の基準を指す。一般に、ＵＥは、利用可能なＵＣＩに関連付けられた優先基準に基づいて上記判定を行ってもよいが、他のＵＣＩの優先基準を考慮に入れてもよい。例えば、高い優先度をもつＵＣＩが利用可能になると予期される場合、ＵＥは、すでに利用可能なＵＣＩの送信を延期してよい。さらに、送信機会がＵＣＩを送信するために使用されるべきであり、ＵＣＩを送信するために使用されると判定される場合、必ずしもＵＣＩ全体（すなわち、全ＵＣＩ部分）が当該送信機会を使用して送信されることを意味しない。場合によっては、ＵＣＩの一部のみが、送信機会を使用して送信される。さらに、優先基準という用語は、基地局がＵＣＩのＵＣＩタイプを判定するために使用してよい任意の基準も指す。特に、優先基準は、１つのＵＣＩタイプ、２つ以上のＵＣＩタイプ、または各ＵＣＩタイプについて、（ｉ）ＵＣＩタイプの優先度値および／または（ｉｉ）ＵＣＩタイプのタイミング情報を含んでよい。これにより、ＵＣＩの優先度／重要度が、優先度値および／またはタイミング値により特定されうる。

優先基準は、ＨＡＲＱプロセスの衝突を回避し、様々なトラフィックタイプを処理し、上りリンクリソースの使用を制限するように定義することができる。次に、図９Ａおよび図９Ｂを参照して、ＨＡＲＱプロセス衝突に関連する問題をより詳細に説明する。

図９Ａおよび図９Ｂに示す例では、ＵＥには、３種類のＳＰＳリソース、すなわち、４スロットの周期性を有するＳＰＳ＃０と、２スロットの周期性を有するＳＰＳ＃１およびＳＰＳ＃２とが設定されている。言い換えれば、ＵＥには、３種類のＳＰＳ設定ＳＰＳ＃０～＃３が設定され、各ＳＰＳ設定は、それぞれの周期性に従うリソースを指定する。また、ＵＥには、最大２ビットを含むことができるＰＵＣＣＨ０と、２ビットより多くを含むことができるＰＵＣＣＨ１との２つのＰＵＣＣＨリソースが設定されている。

ＵＥがＳＰＳ設定のリソースで送信を受信した後、ＵＥは、次の後続のスロット（例えば、ＵＥが送信を受信したスロットの後続の／後のスロット）で、対応するＨＡＲＱ報告（またはＡＣＫ／ＮＡＣＫ報告）を送信することができる。例えば、あるスロットにおいて受信したトラフィックに関連するＨＡＲＱ報告を送るために、ＵＥは、通常（特に、ＤＬシンボル衝突がない場合）、当該あるスロットの後続のスロットにおけるＰＵＣＣＨ１を利用することができる。例えば、ＵＥは、スロットｎにおいてＳＰＳ＃１およびＳＰＳ＃２トラフィックを受信し、スロットｎ＋１において対応するＨＡＲＱ報告を送信する。さらに示されるように、スロットｎ＋２において、ＳＰＳ＃１～ＳＰＳ＃３のそれぞれのリソースにおけるトラフィックが受信される。しかしながら、スロットｎ＋３では、ＰＵＣＣＨ１は、スロットの前半でＤＬシンボルと衝突する。したがって、スロットｎ＋３中のＰＵＣＣＨ１全体は、ＵＣＩの送信用には無効であると見なされ得る。

図９Ａに示されるように、これらの３つのＨＡＲＱ報告は、スロットｎ＋３のＰＵＣＣＨ０には入らないため、ＵＥは、ＳＰＳ＃０～＃２のＨＡＲＱ－ＡＣＫを、スロットｎ＋５のＰＵＣＣＨ１を介して搬送されるように延期してよい。しかしながら、この場合、ＳＰＳ＃１および＃２における新たなＰＤＳＣＨがスロットｎ＋４にて到着すると、ＳＰＳ＃１および＃２についてのＨＡＲＱプロセス衝突が存在することになる。あるいは、図９Ｂに示されるように、ＨＡＲＱ報告のいくつか／一部（例えばＳＰＳ＃０および＃１（時系列にしたがって選択したＳＰＳ）についてのＨＡＲＱ報告）がスロットｎ＋３のＰＵＣＣＨ０によって搬送され得、ＳＰＳ＃２についてのＨＡＲＱ報告がスロットｎ＋５に延期される。この場合、以前のＨＡＲＱ報告を送る前に、新たなＰＤＳＣＨがスロットｎ＋４に到着するとき、ＳＰＳ＃２のためのＨＡＲＱプロセスの衝突が依然として存在することになる。したがって、一般に、ＵＥは、同一のＨＡＲＱプロセスＩＤを有する新たなＰＤＳＣＨを受信する場合、ＨＡＲＱプロセスの延期したＨＡＲＱ報告ビットをドロップしなければならないことがある。

以下でより詳細に説明するように、優先基準を使用して、ＵＥは、異なるＵＣＩに関連付けられた優先度を判定することができる。これは特に、利用可能なＵＣＩのすべてが同時に搬送され得ない場合にどのＵＣＩがより早く搬送されるべきかを判定するために使用され得る。

多重により、ＵＥは、異なるＵＣＩタイプ（例えばＳＲ＋ＣＱＩ＋ＨＡＲＱ－ＡＣＫ）を一緒に送信することができる。利用可能なＵＣＩすべてのペイロードサイズが送信機会のペイロードサイズを超える場合、ＵＥは、送信に利用可能なＵＣＩの一部を選択しなければならないことがある。つまり、この優先度ベースの解決策は、１）異なるＵＣＩタイプ（例えば、ＳＲ＋ＨＡＲＱ－ＡＣＫが選択される）、および２）各ＵＣＩタイプ内（例えば、全３つのＨＡＲＱ－ＡＣＫの２ビットが選択される）に適用することができる。

例えば、ＵＥは、異なるＨＡＲＱプロセスのＨＡＲＱ報告の優先度を判定することができる。より高い優先度を有するＨＡＲＱ報告は、より早く搬送／送信され得る。より低い優先度を有するＨＡＲＱ報告は延期されて後で搬送／送信されるか、またはドロップされ得る。様々なＵＣＩタイプが送信に利用可能であるとき、ＵＥは、定義された優先基準に従って、上りリンク制御容量が制限されていることによるＵＣＩの一部を送信することを選択してよい。これは、ＵＣＩタイプを優先度付けしてＵＥ内多重（ｉｎｔｒａ－ＵＥ ｍｕｌｔｉｐｌｅｘｉｎｇ）する際に使用され得る。ＵＥはまた、定義された優先基準に従ってＵＣＩ送信を延期／キャンセルすると決定してよい。さらに、ＵＥは、ＵＣＩの内容および定義された優先基準に応じて異なる挙動を行ってよい。これにより、より早く／より確実に重要な情報を搬送することができる一方、重要でない情報を緩和されたレイテンシ／信頼性で送信することができる。例えば、ＮＡＣＫ信号は、可能な限り早く送信可能であり、一方、ＡＣＫ信号は、より緩和されたレイテンシで送信可能である。他の例としては、ＮＡＣＫ信号は、繰返しおよび／または様々なリソースを使用して、ＡＣＫ信号より確実に送信され得る。

したがって、基地局は、様々なＵＣＩタイプを受信してよい。すなわち、基地局は、あるＵＣＩタイプをそれぞれが有する１つまたは複数のＵＣＩ部分を受信してよい。ここで、「ＵＣＩタイプ」という用語は、特に、ＨＡＲＱ報告、ＣＱＩ、および／またはＳＲを含むＵＣＩのタイプを指す。基地局は、どのＵＣＩタイプが送信されるか、および／またはＵＣＩタイプ毎にいくつのビットが送信されるかを判定してよい。より具体的には、基地局は、受信された各ＵＣＩ部分について、受信された当該ＵＣＩ部分のＵＣＩタイプを判定してよい。ＨＡＲＱ報告の場合、基地局は、関連付けられたプロセスＩＤを判定してもよい。

特に、１つまたは複数のＵＣＩ部分を受信した場合、基地局は、当該１つまたは複数のＵＣＩ部分を送信したＵＥによる／ＵＥへの送信にどのＵＣＩ部分が利用可能であったかを判定してよい。ＨＡＲＱ報告の場合、ＨＡＲＱ報告が基地局によってＵＥに送信されたＤＬトラフィックを参照し得るため、基地局は、ＵＥが送信しようとしているＨＡＲＱ報告を知っていてもよい。例えば、ＵＥが、いくつかの周期性を有するＳＲ／ＣＱＩを生成するように設定される場合、基地局もまた、ＵＥが送信用にＳＲ／ＣＱＩをどのインスタンスで有するかを知っていてもよい。したがって、本明細書において、「利用可能なＵＣＩ部分」とは、どのＵＣＩが送信されるべきかを判定する場合、および／または送信機会を使用するか否かを判定する場合、送信時にＵＥに利用可能であったＵＣＩ部分を指す。そして、基地局は、１つまたは複数の受信されたＵＣＩ部分の各々について、（ｉ）優先基準、（ｉｉ）利用可能なＵＣＩ部分、および／または（ｉｉｉ）１つまたは複数のＵＣＩ部分が受信されたリソース（すなわち、当該利用可能なＵＣＩ部分を送信するためにＵＥによって使用／選択された送信機会）に基づいて、ＵＣＩタイプを判定してよい。このとき、ＵＣＩ部分がＨＡＲＱ報告である場合、基地局は、ＨＡＲＱ報告に関連付けられたＤＬトラフィックのＨＡＲＱプロセスＩＤを判定してもよい。

＜優先基準のシグナリング＞
一般に、（ＵＥが、例えば、判定Ｓ８７５を実行する際に基づく）優先基準は、基地局によって決定され、ＵＥにシグナリングされ得る。ＵＥは、（現在）定義されている優先基準に従ってＵＣＩ送信のためのＵＬリソースを選択してよい。定義されている優先基準は、ｇＮＢによって、半静的に、または動的に定義／設定され得る。優先度は、既存のパラメータ／新規導入パラメータを設定することによって調整可能である。

例えば、ＵＥ（例えば、送受信部６２０）は、動作時に、（ｉ）半永続的スケジューリング（ＳＰＳ）設定の一部として、（ｉｉ）無線リソース制御（ＲＲＣ：Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）シグナリングにおいて、（ｉｉｉ）物理下りリンク共有チャネル（ＰＤＳＣＨ）において、（ｉｖ）物理下りリンク制御チャネル（ＰＤＣＣＨ）において、および／または（ｖ）下りリンク制御情報（ＤＣＩ）において優先基準を示す通知を受信してよい。

特に、優先度は、ＲＲＣおよび／またはＳＰＳ設定によって半静的に定義／設定され得、ＵＣＩ内容の送信の信頼性／レイテンシを判定／設定するために使用され得、これにより、オーバーヘッドが低減され得る。ＰＤＳＣＨ、ＰＤＣＣＨ、またはＤＣＩの一部として通知を動的に送信することにより、優先度をよりフレキシブルに調整することができる。基地局は、様々なＵＣＩタイプに対する優先度（優先度値）をＵＥに設定してよく、かつ／または、以下でさらに説明するように、ＨＡＲＱ報告を報告するためのタイミング値の組を提供してもよい。基地局はまた、各ＤＬトラフィックの優先度を別々に通知してもよい。

上で説明されたように、優先基準は、基地局によって判定され、ＵＥにシグナリングされ得る。ただし、本発明はこれに限定されない。また、優先基準のいくつかまたはすべてが、ＵＥによって決定され（および基地局にシグナリングされ）てもよく、かつ／または優先基準のいくつかまたはすべてが（例えば、規格において）事前定義されてもよい。

＜優先基準としての優先度値＞
一般に、優先基準は、ＵＣＩ部分の各々について、それぞれの優先度を含んでよい。ＵＣＩ部分のうちの１つ（または複数またはそれぞれ）の優先度は、（ｉ）当該ＵＣＩ部分のタイプ、（ｉｉ）当該ＵＣＩ部分の内容、および／または（ｉｉｉ）送受信部によって受信された優先度の通知に依存し得る。

ここで、「優先度」という用語は、ＵＣＩの重要度を示す優先度値を指す（例えば、より高い値がより高い重要度に対応してよい）。言い換えれば、ＵＬリソースが制限されている場合、優先度の低いＵＣＩよりも優先度の高いＵＣＩが選択されうる。

一般に、利用可能なＵＣＩの送信に送信機会が使用されるべきであり、利用可能なＵＣＩのペイロードサイズが送信機会のペイロードサイズ以下であると判定される場合、利用可能なＵＣＩ部分のすべてが送信機会を使用して送信されるべきであると判定され得る。一方、利用可能なＵＣＩのペイロードサイズが送信機会のペイロードサイズよりも大きい場合、優先基準に基づいて、送信機会を使用してどの利用可能なＵＣＩ部分が送信されるべきかが判定され得る。

ＵＣＩの優先度付けは、様々な段階で実行することができる。例えば、ｇＮＢは、ＨＡＲＱ－ＡＣＫ、スケジューリング要求（ＳＲ）、およびＣＱＩなど、ＵＣＩタイプに対する追加の優先度を定義することができる。

これは、例えば、ＲＲＣ設定を通じて、ＵＣＩタイプの優先度インデックス／優先度値を定義することによって行うことができる。ＵＣＩ送信のための限られたリソースを用いて、ＵＥは、ＵＣＩタイプに定義された優先度を使用して、かつ各ＵＣＩタイプ内で、どの利用可能なＵＣＩタイプが多重され、送信されるべきかを決定することができる。この目的のために、ＵＥはまず、例えば、ＵＣＩタイプの優先度付けを適用し、次いで、各ＵＣＩタイプ内の優先度付けを適用してよい。

ここで、優先度（値）に基づく判定について、図１３を用いてより詳細に説明する。最初に、ＵＥは、Ｓ１３００において、ＵＣＩ送信用に使用されると判定された送信機会であり得る、利用可能なＵＣＩリソース（Ｎビット）のサイズを判定してよい。さらなるＵＣＩ情報がロード可能であるうちは（Ｓ１３１０において「Ｙｅｓ」）、ＵＥは、まだロードされていない利用可能なＵＣＩの中で最も高い優先度を有する利用可能なＵＣＩのＵＣＩタイプを判定／選択してよい（Ｓ１３２０）。選択されたＵＣＩタイプのすべてのペイロードがロード可能である場合（Ｓ１３３０において「Ｙｅｓ」）、ＵＥは、選択されたＵＣＩタイプのすべてのペイロードを選択し（Ｓ１３４０）、選択されたペイロードをＵＣＩリソースにロードしてよい（Ｓ１３６０）。一方、選択されたＵＣＩタイプのすべてのペイロードがロードできない場合（Ｓ１３３０において「Ｎｏ」）、ＵＥは、選択されたＵＣＩタイプの他の部分よりも高い（または少なくとも低くない）優先度（値）を有するペイロードの部分を選択し（Ｓ１３５０）、選択されたペイロードをＵＣＩリソースにロードしてよい（Ｓ１３６０）。選択されたＵＣＩタイプのすべてのペイロード（部分）が同じ優先度を有する場合、ロードされるＵＣＩの部分は、他の基準に従って（例えば、時系列的に、選択されたＵＣＩタイプのペイロード部分が利用可能になったのと同じ順序で）判定され得る。

言い換えれば、上記を要約すると、ＵＥは、最初に、最も高い優先度を有するＵＣＩタイプを選択し、次いで、ＵＣＩリソースが、選択されたＵＣＩタイプのすべての利用可能なペイロードを収容することができる場合、選択されたＵＣＩタイプのペイロード全体をＵＣＩリソースにロードしてよい。そうでない場合、ＵＥは、選択されたＵＣＩタイプから（例えば、内容ベースの優先度を使用して）ペイロードの一部を選択してよい。

より具体的には、ＰＵＣＣＨ／ＰＵＳＣＨリソースが最大６ビットのペイロードサイズに対応することができ、ＵＥが送信することを意図する異なるＵＣＩタイプを有する様々な利用可能なＵＣＩ部分（以下の表に示されるように、全部で１１ビットの情報）を有すると仮定する。

表中、様々なＵＣＩ部分の優先度値が０～５の範囲のインデックスで示されている。つまり、ＨＰトラフィックのＳＲの優先度値は０、ＨＰトラフィックのＨＡＲＱ－ＡＣＫの優先度値は１などのようになっている。言い換えれば、例えば、ＨＰトラフィックのＳＲは、ＬＰトラフィックのＳＲとは異なるタイプのＵＣＩであると見なされ得る。

この表によって与えられる優先度（値）を使用して、ＵＥは、下記のＵＣＩを絞り込み（down select）、送信機会を使用して多重送信する。
－ ＨＰトラフィックのＳＲ：１ビット
－ ＨＰトラフィックのＨＡＲＱ－ＡＣＫ：２ビット
－ ＬＰトラフィックのＳＲ：１ビット
－ ＬＰトラフィックのＨＡＲＱ－ＡＣＫ：全３ビットから２ビット。この２ビットは、ＨＡＲＱ－ＡＣＫの優先度に応じて選択される。

他のＵＣＩタイプは、ドロップ／延期される。

このアプローチは、様々な設定においてＵＣＩタイプを選択するための単純で統一された解決策を提供する。

＜ＨＡＲＱ報告の優先度＞
一般に、利用可能なＵＣＩは、１つまたは複数のＨＡＲＱ報告を含んでよい。言い換えれば、いくつかの利用可能なＵＣＩ部分がＨＡＲＱ報告であってよい。さらに、一般に、各ＨＡＲＱ報告は、或るＨＡＲＱプロセスＩＤのＤＬトラフィックに関連付けられ、優先基準は、ＨＡＲＱ報告ごとに、ＨＡＲＱ報告の優先度（値）を含んでよい。

本開示では、「ＨＡＲＱ報告の優先度」という用語は、通常、ＨＡＲＱ報告のＨＡＲＱプロセスＩＤに関連付けられた優先度を指し、「ＨＡＲＱ報告の優先度」、「ＨＡＲＱプロセスＩＤの優先度」などの用語が互換的に使用される。言い換えれば、同一のＨＡＲＱプロセスＩＤを有するＨＡＲＱプロセスは、同じ優先度を有し得る（例えば、基地局が、ＨＡＲＱプロセスＩＤに対する新規優先度を示すシグナリングを送信するまで）。すなわち、各ＨＡＲＱプロセスＩＤについて、ＨＡＲＱプロセスＩＤのＨＡＲＱ報告によって使用されるべきそれぞれの優先度が存在し得る。

さらに、本開示では、「ＨＡＲＱ報告」という用語は、単に、再送要求、または特定の送信が受信された（例えば、完全に受信され、正常に復号された）か、もしくはＵＥによって受信されなかったという通知の例として使用されることに留意されたい。言い換えると、本開示は、同様に、ＡＲＱ報告、他の再送要求、および／または受信確認／未受信確認の通知に対しても適用される。

図１２は、ＨＡＲＱ報告の優先度に基づいて、送信されるＨＡＲＱ－ＡＣＫを決定するためのフローチャートを示す。ここで、ＵＥが、送信に利用可能なＵＣＩがあると判定し、特定の送信機会が、当該利用可能なＵＣＩの送信用に使用されると仮定する。また、図１２では、以下の説明において全ての利用可能なＵＣＩ部分がＨＡＲＱ ＡＣＫ／ＮＡＣＫ（例えば、ＨＡＲＱ報告）であると想定される。ただし、利用可能なＵＣＩ部分のいくつかまたは全部が別のＵＣＩタイプ（例えば、ＣＱＩおよび／またはＳＲ）である場合も同じ方法が使用され得る。

ステップＳ１２００において、ＵＥは、利用可能なＵＣＩの送信用に使用される送信機会によって搬送可能な最大ペイロードサイズを判定してよい。具体的には、Ｎビットを搬送可能であると判定する。ステップＳ１２１０では、ＨＡＲＱ－ＡＣＫビットの総数がｎビットであると判定される。ステップＳ１２２０では、判定されたペイロードサイズがＡＲＱ－ＡＣＫビット数以上であるか否か、すなわち、Ｎ≧ｎ（Ｎおよび／またはｎは１より大きい整数）であるか否かを判定する。ペイロードサイズがＡＲＱ－ＡＣＫビット数以上である場合（Ｓ１２２０において「Ｙｅｓ」）、ステップＳ１２５０において、すべてのＵＣＩを送信するために送信機会が使用される。

一方、ペイロードサイズがＡＲＱ－ＡＣＫビット数以下である（言い換えれば、ＡＲＱ－ＡＣＫビット数より小さい）場合（Ｓ１２２０において「Ｎｏ」）、ステップＳ１２３０において、利用可能な各ＨＡＲＱ－ＡＣＫの優先度を判定し、ステップＳ１２４０において、利用可能なＨＡＲＱ－ＡＣＫの優先度のうち最も高い優先度を有するｎビットのＨＡＲＱ－ＡＣＫのうちのＮビットを送信してよい。

ＵＥは、利用可能なＨＡＲＱ報告のどれが送信されるべきかを決定してよく、基地局は、１つまたは複数の受信されたＵＣＩ部分がＨＡＲＱ報告である場合、受信されたＨＡＲＱ報告に関連付けられたＤＬトラフィックのＨＡＲＱプロセスＩＤを判定してよい。基地局は、ＵＣＩタイプ（例えば、ＨＡＲＱ報告／ＣＱＩ／ＳＲ）の判定と一緒にまたは別々に上記判定を実行してよい。基地局のＨＡＲＱプロセスＩＤの判定は、ＵＥと同様または同一の基準と、ＵＥ側において送信に利用可能であると基地局が予期するＵＣＩ部分とに基づいてよい。

ＨＡＲＱ報告（またはＨＡＲＱプロセスＩＤ）の優先度を判定／設定するために以下の方法１）～４）を組み合わせてよい。言い換えれば、例えば、１つまたは複数のＨＡＲＱプロセスＩＤのＨＡＲＱ報告の優先度は、関連付けられたＤＬトラフィックの周期性に基づいていてよく、一方、１つまたは複数の他のＨＡＲＱプロセスＩＤの他のＨＡＲＱ報告の優先度は、関連付けられたトラフィックの優先度に基づいていてよい。１つまたは複数のＨＡＲＱプロセスＩＤのＨＡＲＱ報告の優先度が、方法１）～４）のうちの１つまたは複数の組合せに基づく／依存することも可能である。

１）ＨＡＲＱ報告の周期性ベースの優先度（例えば、ＨＡＲＱの衝突回避を目的とする）
一般に、ＨＡＲＱ報告（例えば、１つのＨＡＲＱ報告、２つ以上のＨＡＲＱ報告、またはすべてのＨＡＲＱ報告／各ＨＡＲＱ報告）の優先度は、当該ＨＡＲＱ報告に関連付けられたＤＬトラフィックの周期性に依存してもよいし、当該ＤＬトラフィックの周期性に基づいてもよい。例えば、ＨＡＲＱ報告の各々について、ＨＡＲＱ報告の優先度（または複数の優先度もしくは各優先度）は、ＨＡＲＱに関連付けられたＤＬトラフィックの周期性が高いほど高くなってよい。

ここで、「周期性」という用語は、例えば、ＤＬトラフィックの受信の（発生）頻度、例えば、ＤＬトラフィックがどれだけ頻繁に／どれだけの頻度で受信されるかを指す。したがって、言い換えれば、ＨＡＲＱ報告の優先度は、ＤＬトラフィックの連続するインスタンスとインスタンスとの間の時間間隔／時間区間の長さに依存し得る。例えば、上記で説明したように、図９Ａおよび図９Ｂでは、ＳＰＳ＃１、＃２および＃３の周期性は、それぞれ４スロット、２スロットおよび２スロットである。

ここで、「ＤＬトラフィックのインスタンス」という用語は、同一のＨＡＲＱプロセスＩＤを有し、かつ／または同じＳＰＳ設定の異なるリソースにおける送信を有する（例えば、異なる時間における）異なるＤＬ送信を指す。言い換えれば、ＤＬトラフィックの周期性とは、特定のＨＡＲＱプロセスＩＤの送信がどれくらい頻繁に受信されるかであってよい。ＨＡＲＱ報告の周期性ベースの優先度を使用することにより、ＨＡＲＱプロセスＩＤを有するＨＡＲＱプロセスの衝突を回避することができる。

２）次のＤＬトラフィックの予期到着時間に基づく優先度（例えばＨＡＲＱの衝突回避を目的とする）
一般に、ＨＡＲＱ報告の優先度（例えば、１つのＨＡＲＱ報告の優先度、２つ以上のＨＡＲＱ報告の優先度、またはすべてのＨＡＲＱ報告／各ＨＡＲＱ報告の優先度）は、或るＨＡＲＱプロセスＩＤと同一のＨＡＲＱプロセスＩＤを有するＤＬトラフィックの次のインスタンスが受信されるまでの予期される時間の長さ（例えば、現在の時刻からの時間の長さ）に依存するか、または当該時間の長さに基づきうる。例えば、ＨＡＲＱ報告の優先度は、当該ＨＡＲＱ報告に関連付けられたＤＬトラフィックの次のインスタンスが受信されるまでの予期される時間の長さが短くなるにつれて高くなってもよい。言い換えれば、時間の長さは、現在の時刻とＤＬの次のインスタンスとの間の時間の長さ（例えば、スロット単位の長さ）であってよい。

次のＤＬトラフィックの予期される到来にＨＡＲＱ報告の優先度が基づくことによって、ＨＡＲＱプロセスＩＤを有するＨＡＲＱプロセスの衝突を回避することができる。

＜ＨＡＲＱ衝突の回避＞
上述のように、例えば方法１）および方法２）またはそれらの組合せに応じた優先度を使用することによって、ＨＡＲＱプロセスの衝突を回避することができる。これについては、図１０を参照してさらに説明する。図１０は、ＵＥに、図９Ａおよび図９ＢのＵＥと同じＳＰＳ設定およびＵＬ送信機会が設定され、また、ＨＡＲＱプロセスの衝突を回避するためにＨＡＲＱ報告に優先度を付けるようにも設定されたシナリオを示す。

具体的には、図９Ａおよび図９Ｂと同様に、スロットｎ＋３におけるＰＵＣＣＨ１の送信機会とＤＬシンボルとの衝突が存在している。ＵＥは、スロットｎ＋２において受信したＳＰＳ＃１および＃２に関連付けられたＰＤＳＣＨ（ＤＬトラフィックとも呼ばれる）に対するＨＡＲＱ報告を送信／搬送するために、スロットｎ＋３においてＰＵＣＣＨ０の送信機会を使用すると決定する。さらに、ＵＥは、ＳＰＳ＃０に対するＨＡＲＱ－ＡＣＫを延期し、他のＨＡＲＱ－ＡＣＫビットと多重してスロットｎ＋５において搬送／送信すると決定する。

この目的のために、ＵＥは、利用可能なＨＡＲＱ報告の優先度を判定し、次いで、搬送されるべきより高い優先度を有するものを選択することができる。

例えば、方法１）によれば、ＨＡＲＱ報告の優先度は、関連付けられたＰＤＳＣＨ（またはＳＰＳトラフィックまたはＤＬトラフィック）の周期性に基づき得る。したがって、ＵＥは、高い周期性を有するＳＰＳトラフィックに関連付けられたＨＡＲＱ報告に、低い周期性（前記高い周期性よりも低い周期性）を有するＳＰＳトラフィックに関連付けられたＨＡＲＱ報告よりも高い優先度を与えてよい。したがって、より高い優先度（より高いトラフィック周期性）を有するＨＡＲＱ報告がより早く搬送／送信され得る。この例では、ＳＰＳ＃１および＃２は２スロットの周期性を有し、ＳＰＳ＃０は４スロットの周期性を有する。したがって、ＳＰＳ＃１およびＳＰＳ＃２に関連付けられたＨＡＲＱ報告は、スロットｎ＋３においてＰＵＣＣＨ０を使用して搬送されるように選択／決定され、ＳＰＳ＃０に関連付けられたＨＡＲＱ報告は、スロットｎ＋５においてＰＵＣＣＨ１を使用して搬送されるように選択／決定される。

あるいは、例えば、方法２）によれば、ＨＡＲＱ報告の優先度は、それぞれのＨＡＲＱプロセスＩＤの次のＰＤＳＣＨの到来時間に基づき得る。より具体的には、所与のＵＣＩ送信／ＨＡＲＱ報告について、ＵＥは、当該ＨＡＲＱ報告と同一のＨＡＲＱプロセスＩＤに関連付けられた次のＰＤＳＣＨトラフィックの到来時間を判定／推定する。次のトラフィックの到来時間が短いＨＡＲＱ報告には、前記短い到来時間より到来時間が長いＨＡＲＱ報告よりも高い優先度が与えられ得る。次いで、ＵＥは、送信されるべき高い優先度を有するＨＡＲＱ報告を選択する。この例では、ＵＥは、スロットｎ＋４においてＳＰＳ＃１および＃２における次のＰＤＳＣＨと、スロットｎ＋６においてＳＰＳ＃０におけるＰＤＳＣＨとを受信すると予期する。スロットｎ＋３におけるＰＵＣＣＨ０を考慮すると、ＳＰＳ＃０～２に関連付けられた新たなＰＤＳＣＨの到来時間は、それぞれ１、１、および３であると判定され得る。ＵＥは、より短い到来時間、すなわち、ＳＰＳ＃１および＃２に関連付けられたＨＡＲＱ報告を選択する。

図９Ａおよび図９ＢのＨＡＲＱプロセスの衝突は、方法１）または２）のいずれかを使用して回避されることが分かる。

３）ＨＡＲＱ報告の内容ベースの優先度
一般に、ＨＡＲＱ報告の優先度（例えば、１つのＨＡＲＱ報告の優先度、２つ以上のＨＡＲＱ報告の優先度、またはすべてのＨＡＲＱ報告／各ＨＡＲＱ報告の優先度）は、ＨＡＲＱ報告が肯定応答（ＡＣＫ）であるか否定応答（ＮＡＣＫ）であるかに依存するか、またはそのことに基づき得る。例えば、ＨＡＲＱ報告がＮＡＣＫであるとき、ＨＡＲＱ報告がＡＣＫであるときよりも、ＨＡＲＱ報告の優先度（または複数の優先度または各優先度）は、高くなり得る。

一般に（特に、利用可能なＵＣＩがＨＡＲＱ報告ではないＵＣＩ部分を含むときも）、ＵＥには、ＵＣＩの様々な内容に対して異なる優先度が設定され得る。言い換えれば、ＵＣＩ部分の優先度は、ＵＣＩの内容および／またはタイプに依存してよい。優先度は、様々なレイテンシ要件を有するＡＣＫ／ＮＡＣＫ送信を満たすように設定され得る。例えば、ＵＥは、データ再送をトリガするために、ＮＡＣＫを即座に、すなわち、次のスロットにおいて報告するように設定され得る。一方、ＵＥは、ＨＡＲＱ－ＡＣＫの多重およびＵＣＩ送信の低減ができるように、緩和されたレイテンシでＡＣＫを送信するように設定され得る。

ＡＣＫ／ＮＡＣＫ送信に対する様々な優先度は、ＮＡＣＫであるＨＡＲＱ報告のタイミング値とは別個にＡＣＫであるＨＡＲＱ報告のタイミング値を定義する（例えば、タイミング値の１つのシーケンスをＰＤＳＣＨ－ｔｏ－ＨＡＲＱ－ＮＡＣＫに対して、タイミング値の他の／異なるシーケンスをＰＤＳＣＨ－ｔｏ－ＨＡＲＱ－ＡＣＫに対して定義する）ことによって設定可能である。例えば、各ＨＡＲＱプロセスＩＤについて、（ｉ）ＡＣＫが送信される場合に対してオフセット値の第１のシーケンス（以下ではＡＣＫシーケンスと呼ばれる）が定義され得、（ｉｉ）ＮＡＣＫが送信される場合に対してオフセット値の第２のシーケンス（以下ではＮＡＣＫシーケンスと呼ばれる）が定義され得る。言い換えれば、優先基準は、各ＨＡＲＱプロセスＩＤについて、（ｉ）ＡＣＫである当該ＩＤのＨＡＲＱ報告に使用されるＡＣＫシーケンスと、（ｉｉ）ＮＡＣＫである当該ＩＤのＨＡＲＱ報告に使用されるＮＡＣＫシーケンスとを含んでよい。ただし、本発明はこれに限定されない。一般に、ＡＣＫである複数またはすべてのＨＡＲＱ報告に使用される１つのＡＣＫシーケンスと、ＮＡＣＫである複数またはすべてのＨＡＲＱ報告に使用されるべき１つのＮＡＣＫシーケンスとがあってもよい。

これについては、ＵＥが周波数分割複信（ＦＤＤ：Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ）モードで動作するシナリオを図１５を参照してさらに説明する。ＦＤＤモードとは、（少なくとも）２つの帯域の周波数リソースがＵＥに設定され、２つの帯域の一方がＵＬ用に使用され、他方がＤＬ送信Ｌに使用されるモードを指す。

本例では、ＰＤＳＣＨ＃０のプロセスＩＤのＮＡＣＫの優先度は、ＰＤＳＣＨ＃０のプロセスＩＤのＡＣＫの優先度よりも高いと想定している。例えば、ＰＤＳＣＨ＃０に対して、ＮＡＣＫでは、オフセット値「１」を使用してよく、ＡＣＫでは、オフセット値「２」を使用してよい。図１５に示すように、スロットｎで受信したＰＤＳＣＨ＃０に関するＨＡＲＱ報告は、ＮＡＣＫであるため、次のスロットｎ＋１におけるＰＵＣＣＨ０を用いて送信される。一方、スロットｍで受信されたＰＤＳＣＨ＃０に関するＨＡＲＱ報告はＡＣＫであるため、次のスロットｍ＋１のＰＵＣＣＨ０では送信されない。

むしろ、スロットｍにおいて受信されたＰＤＳＣＨ＃０に関連するＨＡＲＱ報告は、スロットｍ＋１において受信されたＰＤＳＣＨ＃１に関連するＨＡＲＱ報告と一緒に／多重されて、次のスロットｍ＋２においてＰＵＣＣＨ１において送信され、これは、例えば、内容とは無関係のオフセット値「１」を有し得る。特に、ＵＥは、スロットｎ＋１における送信機会が、その時間において利用可能なＵＣＩの送信用に使用されると判定し、スロットｍ＋１における送信機会が、その時間において利用可能なＵＣＩの送信用に使用されないと判定してよい。

ＵＣＩの内容に依存する優先度を使用することで、急を要しないＵＣＩ内容を延期して多重することにより電力消費およびＵＬトラフィックを低減することができる。さらに、内容ベースの優先度を使用することにより、急を要するＵＣＩを延期することなく、通信システムにおけるＵＥの電力消費および干渉を低減する助けとなり得る。

４）ＨＡＲＱ報告のトラフィックベースの優先度
一般に、ＨＡＲＱ報告の優先度（例えば、１つのＨＡＲＱ報告の優先度、２つ以上のＨＡＲＱ報告の優先度、またはすべてのＨＡＲＱ報告／各ＨＡＲＱ報告の優先度）は、ＨＡＲＱ報告が参照するＤＬトラフィックの優先度に依存するか、またはそれに基づいてもよい。例えば、ＨＡＲＱ報告の優先度は、ＨＡＲＱ報告に関連付けられたＤＬトラフィックの優先度が高いほど高い。言い換えれば、ＨＡＲＱ報告（または複数のＨＡＲＱ報告または各ＨＡＲＱ報告）の優先度は、（ｉ）当該ＨＡＲＱ報告がＡＣＫまたはＮＡＣＫを報告するＤＬ送信の優先度、および／または（ｉｉ）当該ＨＡＲＱ報告がＡＣＫまたはＮＡＣＫを報告するＤＬトラフィック／ＤＬ送信のＨＡＲＱプロセスＩＤの優先度とともに高くなり得る。

言い換えれば、ＵＥには、例えば、高優先度（ＨＰ：Ｈｉｇｈ Ｐｒｉｏｒｉｔｙ）および低優先度（ＬＰ：Ｌｏｗ Ｐｒｉｏｒｉｔｙ）などの様々なトラフィック優先度が設定され得、かつ／または下りリンクトラフィックの優先度に基づいてＨＡＲＱ報告を搬送するように設定され得る。ＨＰトラフィックは、ＬＰトラフィックと比較して、より厳しい信頼性要件／待ち時間要件を有し得る。したがって、ＨＰのためのＨＡＲＱ－ＡＣＫは、ＬＰトラフィックのためのＨＡＲＱ報告と比較して、より早く／より高い信頼性で送信されるべきである。

次に、図１１を参照して、方法４をより詳細に説明する。図１１では、ＵＥには、２スロットの周期性をそれぞれが有する３つのＳＰＳ ＤＬリソースが設定されている。ＵＬ送信機会の２つの設定であるＰＵＣＣＨ０およびＰＵＣＣＨ１は、それぞれ、２ビットおよび３ビット以上のペイロードサイズを有する。さらに、ＳＰＳ＃１には低い優先度（またはＳＰＳ＃０および＃２よりも低い優先度）が設定され、ＳＰＳ＃０およびＳＰＳ＃２が高い優先度（またはＳＰＳ＃１よりも高い優先度）を有すると仮定する。

スロットｎ＋１において、ＵＥは、スロットｎにおいて受信したＳＰＳ＃０～ＳＰＳ＃２のＰＤＳＣＨに対するＨＡＲＱ報告を搬送するためにＰＵＣＣＨ１を選択する。スロットｎ＋３において、ＰＵＣＣＨ１は、ＤＬシンボルと衝突する。したがって、ＵＥは、ＰＵＣＣＨ０を利用して、ＨＰ ＤＬトラフィックのＨＡＲＱ報告の２ビット、すなわち、スロットｎ＋２において受信されたＳＰＳ＃０およびＳＰＳ＃２のトラフィックに関連付けられたＨＡＲＱ報告を搬送する。ＵＥは、同じＩＤを有する新たなＰＤＳＣＨがスロットｎ＋４において受信されるため、スロットｎ＋２において受信されたＳＰＳ＃１のＰＤＳＣＨについてのＨＡＲＱ報告をドロップする必要がある。

したがって、低優先度トラフィックが、例えば、信頼性の観点で緩やかなＱｏＳ要件を有し得るため、ＨＡＲＱ報告のトラフィックベースの優先度を使用することにより、様々なトラフィックタイプの効率的な処理が容易化され得る。

＜優先基準としてのタイミング情報＞
一般に、各ＳＰＳには、ｋ１（値）としても知られるＰＤＳＣＨ－ｔｏ－ＨＡＲＱ－ＡＣＫ／ＮＡＣＫタイミング値の組が設定され得る。言い換えれば、ｋ１値は、ＤＬ送信が受信された時間と、対応するＨＡＲＱ報告が送信される時間との間のオフセット／時間（例えばスロット単位）を示す。ＵＥは、タイミングセット（ＨＡＲＱ報告の送信用の有効なＰＵＣＣＨ／ＰＵＳＣＨリソースを有するタイミング／オフセット値のシーケンス）から第１の値を選択してよい。

一般に、ＨＡＲＱ報告（またはそのプロセスＩＤ）に関連付けられた優先基準は、ＨＡＲＱプロセスＩＤに関連付けられたオフセット値のシーケンスを含んでよい。これは、１つのＨＡＲＱ報告、複数のＨＡＲＱ報告の各々、各ＨＡＲＱ報告に適用され得る。

「オフセット値のシーケンス」または「タイミングシーケンス」という用語は、順序付けたオフセット値のリストまたは順序付けたオフセット値の組を指し、例えば、複数のオフセット値やこれらオフセット値の特定の順序を指すことに留意されたい。一般に、オフセット値のシーケンスは、１つまたは複数のオフセット値を含んでよい。特に、オフセット値は、ｋ１値であってもよく、またはｋ１値に対応してもよい。各オフセット値は、ＨＡＲＱ報告が参照する（ＡＣＫまたはＮＡＣＫが報告される）ＤＬ送信の受信に関連するＵＣＩを送信するための時間を示し得る。したがって、所与のＨＡＲＱ報告および／またはＤＬトラフィックの所与の受信について、オフセット値のシーケンスは、ＨＡＲＱ報告を送信するための送信時間のシーケンスに対応する。この送信時間のシーケンスは、好ましさに応じて、例えば、最も好ましい送信時間から最も好ましくない送信時間まで、順序付けられうる。

したがって、一般に、送信機会が、ＨＡＲＱ報告の送信時間のシーケンスのうちの１つまたは複数における（すなわち、ＨＡＲＱ報告の送信時間の少なくとも１つのシーケンス中の／当該少なくとも１つのシーケンスにおける）第１の有効な送信時間に対応する場合、利用可能なＵＣＩの送信に当該送信機会が使用されると判定され得る。言い換えれば、第１の送信時間は、シーケンスの送信時間のうちの、時間的な意味での最初の送信時間でなくてもよく、むしろ、有効である／衝突していないという基準を満たすシーケンスにおける最初の送信時間であり得る。ここで、「有効」という用語は、上で説明されたように、いかなるＤＬシンボルとも衝突しない送信時間／送信機会を示す。したがって、ＵＥは、送信機会が第１の有効な送信時間に対応するＨＡＲＱ報告を送信するために送信機会を使用してよい。

したがって、優先基準／タイミングシーケンスに基づいて、他のＵＣＩが送信に利用可能になるまで任意のＵＣＩの送信を延期するか否かが判定され得る。したがって、当該任意のＵＣＩの送信に（時間的に）次の送信機会（または、次の送信機会が複数ある場合、次の複数の送信機会のいずれか）が使用されないと決定され得る。通常、他の（現在利用可能なＵＣＩとは異なる）ＵＣＩが（例えば、所定の数のスロット内で）受信されると予期されると判定され得、そのような判定に基づいて、（時間的に）次の送信機会を使用しないと決定してよい。したがって、現在利用可能なＵＣＩと当該他のＵＣＩとを送信するための（時間的に）次の送信機会よりも時間的に後の別の後続の送信機会を使用すると判定してもよい。特に、次の送信機会が発生した後に、（ｉ）他のＵＣＩが送信に利用可能であること、および（ｉｉ）利用可能なＵＣＩおよび他のＵＣＩを送信するために後続の送信機会を使用することを判定してもよい。

＜ＵＬ制御リソースの使用を制限するための優先度に基づくＨＡＲＱ－ＡＣＫ送信＞
ＵＥは、ＵＣＩを搬送するためのＵＬリソースの使用を制限／限定するように設定され得る。この目的のために、ＵＥは、重要なＵＣＩタイプを即座に送信すべきであり、一方、ＵＥは、重要度の低いＵＣＩタイプの送信を延期して他の情報と多重することができる。

＜ＵＬ制御リソース使用量の削減＞
上述のように、タイミング基準／タイミング情報を含む優先基準を使用することによって、ＵＬリソースおよび通信システムにおける干渉が低減されうる。このことを、図１４を参照してさらに説明する。図１４では、ＵＥに、ＳＰＳ＃１、ＳＰＳ＃２、およびＳＰＳ＃３として示される３つのＳＰＳ ＤＬリソースが設定されている。ＳＰＳ＃２は、４スロットの周期性で周期的であり、ＳＰＳ＃０および＃１は、６スロットよりも大きい周期性を有してよい。さらに、ＵＥには、２スロットの周期性で周期的であるＰＵＣＣＨ１によって与えられる送信機会が設定されている。

ＳＰＳ＃０および＃１のＨＡＲＱ報告は、２スロット内で送信される必要があり、ＳＰＳ＃２のＨＡＲＱ報告は、４スロット内で送信される必要がある。ＵＬリソースの削減を容易にするために、ＳＰＳ＃０および＃１にはそれぞれ、オフセット値のシーケンス｛１，２｝（スロット単位）が設定され、ＳＰＳ＃２には、オフセット値のシーケンス｛４，３，２，１｝が設定されている。言い換えれば、優先基準は、ＳＰＳ＃０に関連付けられたＨＡＲＱプロセスＩＤについては、オフセット値のシーケンス｛１，２｝を含み、ＳＰＳ＃１に関連付けられたＨＡＲＱプロセスＩＤについては、オフセット値のシーケンス｛１，２｝を含み、ＳＰＳ＃２に関連付けられたＨＡＲＱプロセスＩＤについては、オフセット値のシーケンス｛４，３，２，１｝を含む。

ＵＥは、スロットｎで受信されたＳＰＳ＃２についてのＨＡＲＱ報告をスロットｎ＋１において送信するが、これは、次の利用可能なスロット（ｎ＋５）へのＨＡＲＱ報告の延期がレイテンシ要件に違反するからである。より具体的には、ＵＥは、オフセット値のシーケンス｛４、３、２、１｝の最後のエントリに対応するスロットｎ＋１において、スロットｎで受信されたＳＰＳ＃２についてのＨＡＲＱ報告を送信する。これは、スロットｎ＋１は、（ｉ）ＳＰＳ＃２のシーケンスにおける第１および第３のエントリに対応するスロットｎ＋４およびｎ＋２に送信機会がないこと、また（ｉｉ）ＳＰＳ＃２のシーケンスにおける第２のエントリに対応するスロットｎ＋３の送信機会が理由である。ｋ１＝４、３、および２は、ＵＣＩ送信が可能でないＤＬスロットを指すため、ｋ１＝１が、スロットｎにおいて受信されたＳＰＳ＃２のシーケンスセット｛４、３、２、１｝からの唯一の有効な値である。したがって、設定されたタイミング情報を使用して、ＵＥは、スロットｎにおいて受信されたＳＰＳ＃２のＰＤＳＣＨのＨＡＲＱ報告のためにｋ１＝１を選択する。

しかし、ＵＥは、スロットｎ＋４において受信されたＳＰＳ＃２についてのＨＡＲＱ報告をスロットｎ＋７に延期し、スロットｎ＋７においてＰＵＣＣＨ１を使用してＳＰＳ＃２についての当該ＨＡＲＱ報告を送信する。言い換えると、スロットｎ＋４において受信されたＳＰＳ＃２についてのＨＡＲＱ報告は、スロットｎ＋６において受信されたＳＰＳ＃０およびＳＰＳ＃１のＨＡＲＱ報告と多重（例えば、一緒に送信）される。より具体的には、ＵＥは、スロットｎ＋８（第１のオフセット値「４」に対応する。すなわち、ｎ＋４＋４＝ｎ＋８）に送信機会がないため、スロットｎ＋４において受信されたＳＰＳ＃２のトラフィックについてのＨＡＲＱ報告を送信するためにスロットｎ＋７が使用されると判定する。さらに、ＵＥは、スロットｎ＋７が、ＳＰＳ＃０および＃１のシーケンスにおける第１のオフセット値「１」に対応する（すなわち、ｎ＋６＋１＝ｎ＋７）ため、スロットｎ＋７が、スロットｎ＋６において受信されたＳＰＳ＃０およびＳＰＳ＃１のトラフィックについてのＨＡＲＱ報告を送信するために使用されると判定する。したがって、ＵＥは、設定されたタイミング情報を用いて、（ｉ）スロットｎ＋４で受信したＳＰＳ＃２のＰＤＳＣＨのＨＡＲＱ報告に対してｋ１＝３、（ｉｉ）スロットｎ＋６で受信したＳＰＳ＃０および＃１のＰＤＳＣＨのＨＡＲＱ報告に対して、ｋ１＝１を選択する。特に、ＵＥは、スロットｎ＋５における送信機会が、利用可能なＵＣＩ（すなわち、スロットｎ＋４において受信されたＳＰＳ＃２についてのＨＡＲＱ報告）の送信に使用されないと判定してよい。

スロットｎ＋７におけるすべてのＰＵＣＣＨ１が３つのＨＡＲＱのすべてを収容することができない場合、ＵＥは、他の優先基準を考慮してよい。１つのアプローチは、ＵＥが、ＳＰＳ＃２についてのＨＡＲＱを搬送するためにスロットｎ＋５のＰＵＣＣＨ１を使用すると決定することであり得る。

したがって、通常、ＵＬ送信機会のペイロードサイズが、すべてのＵＣＩを送信するのに十分なペイロードサイズを有しない場合、この送信機会は、優先される送信時間であり、上記ＵＣＩのうちのどれが当該優先される送信機会を使用して送信されるべきかが、他の優先基準に基づき判定され得る（または、例えば、先入れ先出し方式で、すなわち、利用可能なＵＣＩの中で最初に利用可能になったＵＣＩが、この優先される送信機会に対して選択される）。例えば、図１２および図１３に関して説明したように、送信機会を使用して送信されるべきＵＣＩは、ＵＣＩに定義された優先度値／優先度インデックスに基づいて選択され得る。さらに、他のタイミング値が考慮されてもよい。言い換えれば、有効なタイミング値が他に存在しない（すなわち、対応するシーケンスにおける他のｋ１値が有効な送信機会を示さない）ＵＣＩが選択され得る。具体的には、（特に、第１の送信機会が、当該第１の送信機会が好ましいすべてのＵＣＩのための十分なペイロードサイズを有しない場合）、任意のＵＣＩの第１の（最も好ましい）送信機会ではない有効な送信機会が、ＵＣＩを送信するために使用されると判定され得る。したがって、どのＵＣＩを送信するかは、タイミング値／タイミングシーケンスおよび／または優先度値などの他の優先基準に基づき判定され得る。

スロットｎ＋７においてＰＵＣＣＨ１によって搬送される、ＳＰＳ＃０および＃２に関連付けられたＨＡＲＱ報告の多重によって、ＰＵＣＣＨ１がスロットｎ＋５およびｎ＋７の両方で使用される場合と比較して、通信効率を高めつつ電力消費を減少させる。したがって、優先基準としてタイミング情報を使用することは、システムにおけるＵＥの電力消費および干渉の低減に役立ち得る。

＜特定のＵＣＩの信頼性の向上＞
一般に、優先基準、特に優先度を、ＵＣＩの内容に対する様々な信頼性を実現するために定義することもできる。すなわち、ＵＣＩに対して実現される信頼性は、各ＵＣＩのタイプおよび／または内容に依存し得る。例えば、優先基準に基づいて、送信機会のうちの２つ以上の各々においてＵＣＩ部分を送信するか否かが判定され得る。言い換えれば、ＵＣＩのタイプ／内容に応じて、ＵＣＩを繰り返してもよい（例えば、２回以上、場合によっては異なる冗長バージョンなどを使用して送信してもよい）し、繰り返さなくてもよい。

例えば、図１６に示すように、ＵＥは、高い信頼性を保証するために、様々なリソースまたは多くのリソースを使用してＮＡＣＫ信号を送信するように設定され得る。上記様々なリソースは、より高い信頼性のための送信の繰返し／冗長性を達成するために、時間領域／周波数領域／コード領域における追加のＵＣＩリソースであり得る。一方、ＡＣＫ信号は、少ないリソースを使用して送信することができる。具体的には、図１６において、ＵＥは、周波数分割複信（ＦＤＤ）モードで動作し、次のＰＵＣＣＨ０送信機会と次のＰＵＣＣＨ１送信機会の両方を使用してＮＡＣＫを送信し、一方ＡＣＫは次のＰＵＣＣＨ０送信機会のみを使用して送信するように設定されている。

［ハードウェアおよびソフトウェアによる本開示の実施］
本開示はソフトウェア、ハードウェア、または、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的にまたは全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的にまたは全体的に、一つのＬＳＩまたはＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサまたは専用プロセッサで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理またはアナログ処理として実現されてもよい。さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。

通信装置は無線送受信機（送受信部ー）と処理／制御回路を含んでもよい。無線送受信機は受信部と送信部、またはそれらを機能として、含んでもよい。無線送受信部（送信部、受信部）は、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）モジュールと１または複数のアンテナを含んでもよい。ＲＦモジュールは、増幅器、ＲＦ変調器／復調器、またはそれらに類するものを含んでもよい。

通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物または移動輸送機関（自動車、飛行機、船等）、および上述の各種装置の組み合わせがあげられる。

通信装置は、持ち運び可能または移動可能なものに限定されず、持ち運びできないまたは固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーターまたは計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）ネットワーク上に存在してよいあらゆる「モノ（Ｔｈｉｎｇｓ）」をも含む。

通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。

また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続または連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。

また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。

さらに、さまざまな実施の形態は、ソフトウェアモジュールによっても実施され得る。これらのソフトウェアモジュールは、プロセッサによって実行されるか、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体に格納され得る。特に、他の実装形態によれば、非一時的なコンピュータ読み取り可能な記録媒体が提供される。１つまたは複数のプロセッサによって実行されると、１つまたは複数のプロセッサに、本開示による方法のステップを実行させるプログラムを、上記記録媒体は記憶する。

非限定的な例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶デバイス、フラッシュメモリ、または命令またはデータ構造の形式で所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を備え得る。また、任意の接続は、適宜、コンピュータ可読媒体と呼ばれる。例えば、命令が、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ：ｄｉｇｉｔａｌ ｓｕｂｓｃｒｉｂｅｒ ｌｉｎｅ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まず、代わりに、非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスクは、コンパクトディスク（ＣＤ）、レーザーディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｃ）、フロッピーディスク、およびブルーレイディスクを含み、「ｄｉｓｋ」は通常、データを磁気的に再生し、「ｄｉｓｃ」は、データをレーザーで光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。

さらには、複数の異なる実施の形態の個々の特徴は、個々に、または任意の組合せにおいて、別の実施の形態の主題とすることができることに留意されたい。具体的な実施の形態に示した本開示には、広義に記載されている本発明の概念または範囲から逸脱することなく、さまざまな変更および／または修正を行うことができることが、当業者には理解されるであろう。したがって、本明細書に示した実施の形態は、あらゆる点において例示的であり、本発明を制限するものではないものとみなされる。

＜さらなる態様＞
第１の態様によれば、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）が提供される。ＵＥは、動作時に、（ｉ）上りリンク制御情報（ＵＣＩ）送信用の複数の送信機会を示す通知を取得し、（ｉｉ）ＵＣＩが送信に利用可能であると判定し、（ｉｉｉ）利用可能なＵＣＩを送信するための複数の送信機会のうちの送信機会を使用するか否かを、利用可能なＵＣＩに関連付けられた優先基準に基づいて判定する回路を備える。さらに、ＵＥは、動作時に、利用可能なＵＣＩの送信に送信機会が使用されると判定される場合、利用可能なＵＣＩを送信するために送信機会を使用する送受信部を備える。

第１の態様の例示的な実装形態では、利用可能なＵＣＩは、複数のＵＣＩ部分を含み、優先基準は、ＵＣＩ部分ごとにそれぞれの優先度を含み、複数のＵＣＩ部分のうちの１つの優先度は、（ｉ）当該１つのＵＣＩ部分のタイプおよび／もしくは内容、ならびに／または（ｉｉ）送受信部によって受信された優先度の通知に依存する。

例えば、回路は、動作時に、（ｉ）利用可能なＵＣＩの送信に送信機会が使用されると判定され、かつ、利用可能なＵＣＩのペイロードサイズが送信機会のペイロードサイズよりも大きいと判定される場合、優先基準に基づいて、複数のＵＣＩ部分のうちのどれが送信機会において送信されるかを判定し、かつ／または（ｉｉ）利用可能なＵＣＩの送信に送信機会が使用されると判定され、かつ、利用可能なＵＣＩのペイロードサイズが送信機会のペイロードサイズ以下であると判定される場合、複数のＵＣＩ部分のすべてが送信機会において送信されると判定する。

概して、第１の態様の実装形態では、利用可能なＵＣＩは、１つまたは複数のハイブリッド自動再送要求（ＨＡＲＱ）報告を含んでよく、各ＨＡＲＱ報告は、或るＨＡＲＱプロセスＩＤの下りリンク（ＤＬ）トラフィックに関連付けられている。さらに、通常、優先基準は、ＨＡＲＱ報告の各々について、ＨＡＲＱ報告の優先度を含んでよく、ＨＡＲＱ報告の優先度は、（ｉ）ＨＡＲＱ報告に関連付けられたＤＬトラフィックの周期性、（ｉｉ）或るＨＡＲＱプロセスＩＤと同一のＨＡＲＱプロセスＩＤを有するＤＬトラフィックの次のインスタンスが受信されるまでの予期される時間の長さ、（ｉｉｉ）ＨＡＲＱ報告が肯定応答（ＡＣＫ）であるかＨＡＲＱ否定応答（ＮＡＣＫ）であるか、および／または（ｉｖ）前記ＤＬトラフィックの優先度に依存する。

例えば、ＨＡＲＱ報告の各々について、ＨＡＲＱ報告の優先度は、（ｉ）ＤＬトラフィックの周期性が高いほど高く、（ｉｉ）ＤＬトラフィックの次のインスタンスが受信されるまでの予期される時間の長さが短いほど高く、（ｉｉｉ）ＨＡＲＱ報告がＨＡＲＱ ＡＣＫであるときよりもＨＡＲＱ報告がＨＡＲＱ ＮＡＣＫであるときに高く、かつ／または（ｉｖ）ＨＡＲＱ報告に関連付けられたＤＬトラフィックの優先度が高いほど高い。

通常、第１の態様の実装形態では、ＵＥには、１つまたは複数の半永続的スケジューリング（ＳＰＳ）設定が設定され得、（ｉ）設定されたＳＰＳ設定は、それぞれのＤＬ ＳＰＳトラフィックに対応し、それぞれの特定のＨＡＲＱプロセスＩＤに関連付けられ、（ｉｉ）ＨＡＲＱに関連付けられたＤＬトラフィックは、ＤＬ ＳＰＳトラフィックである。

概して、第１の態様の実装形態では、（ｉ）利用可能なＵＣＩは、１つまたは複数のハイブリッド自動再送要求（ＨＡＲＱ）報告を含んでよく、各ＨＡＲＱ報告は、或るＨＡＲＱプロセスＩＤの下りリンク（ＤＬ）トラフィックに関連付けられ、（ｉｉ）優先基準は、ＨＡＲＱプロセスＩＤの各々について、ＨＡＲＱプロセスＩＤに関連付けられたオフセット値のシーケンスであって、ＤＬトラフィックの受信時間に関連して、ＨＡＲＱ報告を送信するための対応する送信時間のシーケンスを示すオフセット値のシーケンスを含んでよく、（ｉｉｉ）回路は、動作時に、ＨＡＲＱ報告の送信時間のシーケンスのうちの１つまたは複数のシーケンスにおける、いかなるＤＬシンボルとも衝突しない第１の送信時間に送信機会が対応する場合、送信機会は利用可能なＵＣＩの送信用に使用されると判定し得、（ｉｖ）送受信部は、動作時に、送信機会が第１の送信時間に対応するＨＡＲＱ報告を送信するために送信機会を使用してよい。

概して、第１の態様の実装形態では、送受信部は、動作時に、（ｉ）半永続的スケジューリング（ＳＰＳ）設定の一部として、（ｉｉ）無線リソース制御（ＲＲＣ）シグナリングにおいて、（ｉｉｉ）物理下りリンク共有チャネル（ＰＤＳＣＨ）において、（ｉｖ）物理下りリンク制御チャネル（ＰＤＣＣＨ）において、および／または（ｖ）下りリンク制御情報（ＤＣＩ）において、優先基準を示す通知を受信してよい。

概して、第１の態様の実装形態では、（ｉ）送信機会は、複数の送信機会のうちの次の送信機会であってよく、（ｉｉ）回路は、動作時に、優先基準に基づいて、他のＵＣＩが送信に利用可能になるまで任意のＵＣＩの送信を延期するか否かを判定してよく、当該他のＵＣＩは、利用可能なＵＣＩとは異なるＵＣＩである。

例えば、回路は、動作時に、送信機会の後に、（ｉ）他のＵＣＩが送信に利用可能であると判定してよく、（ｉｉ）利用可能なＵＣＩおよび他のＵＣＩを送信するために後続の送信機会を使用すると決定してよく、後続の送信機会は、複数の送信機会のうちの、上記送信機会の後の送信機会であり、送受信部は、動作時に、利用可能なＵＣＩおよび他のＵＣＩを送信するために当該後続の送信機会を使用してよい。

概して、第１の態様の実装形態では、回路は、動作時に、優先基準に基づいて、複数の送信機会のうちの２つ以上の送信機会の各々においてＵＣＩ部分を送信するか否かを判定してよい。

通常、第１の態様の実装形態では、（ｉ）ＵＥは、時分割複信（ＴＤＤ）で動作してよく、（ｉｉ）回路は、動作時に、送信機会が１つまたは複数のＤＬシンボルと衝突する場合、利用可能なＵＣＩの送信に送信機会を使用しないと判定してよい。

第２の態様によれば、スケジューリングデバイスが提供される。スケジューリングデバイスは、動作時に、（ｉ）利用可能な上りリンク制御情報（ＵＣＩ）を送信するための複数の送信機会のうちの送信機会を使用するか否かを判定する際に基づく優先基準を決定し、（ｉｉ）優先基準を示す通知を含む第１のシグナリング情報を生成し、（ｉｉｉ）ＵＣＩ送信用の複数の送信機会を決定し、（ｉｖ）複数の送信機会を示す通知を含む第２のシグナリング情報を生成する回路を備える。さらに、スケジューリングデバイスは、動作時に、（ｉ）第１のシグナリング情報を送信し、（ｉｉ）第２のシグナリング情報を送信する送受信部を備える。

第３の態様によれば、ユーザ機器（ＵＥ）のための方法が提供される。本方法は、（ｉ）上りリンク制御情報（ＵＣＩ）を送信するための複数の送信機会を示す通知を取得するステップと、（ｉｉ）ＵＣＩが送信に利用可能であると判定するステップと、（ｉｉｉ）利用可能なＵＣＩに関連付けられた優先基準に基づいて、利用可能なＵＣＩを送信するための複数の送信機会のうちの送信機会を使用するか否かを判定するステップと、（ｉｖ）利用可能なＵＣＩを送信するために送信機会が使用されると判定される場合、利用可能なＵＣＩの送信に送信機会を使用するステップと、を含む。

第４の態様によれば、スケジューリングデバイスのための方法が提供される。本方法は、（ｉ）利用可能な上りリンク制御情報（ＵＣＩ）を送信するための複数の送信機会のうちの送信機会を使用するか否かを判定する際に基づく優先基準を決定するステップと、（ｉｉ）優先基準を示す通知を含む第１のシグナリング情報を生成するステップと、（ｉｉｉ）第１のシグナリング情報を送信するステップと、（ｉｖ）ＵＣＩ送信用の複数の送信機会を決定するステップと、（ｖ）複数の送信機会を示す通知を含む第２のシグナリング情報を生成するステップと、（ｖｉ）第２のシグナリング情報を送信するステップと、を含む。

第５の態様によれば、スケジューリングデバイスが提供される。スケジューリングデバイスは、動作時に、（ｉ）上りリンク制御情報（ＵＣＩ）を送信するための複数の送信機会を示す通知を含むシグナリング情報を送信し、（ｉｉ）複数の送信機会のうちの１つにおいて、１つまたは複数のＵＣＩ部分を受信する送受信部を備える。さらに、スケジューリングデバイスは、動作時に、（ｉ）シグナリング情報を生成し、（ｉｉ）ＵＣＩに関連付けられた優先基準に基づいて、１つまたは複数の受信されたＵＣＩ部分の各々について、受信されたＵＣＩ部分のＵＣＩタイプを判定する回路を備える。

第５の態様の実装形態では、回路は、動作時に、（ｉ）１つまたは複数のＵＣＩ部分を送信したＵＥによってどのＵＣＩ部分が送信に利用可能であったかを判定し、（ｉｉ）１つまたは複数の受信されたＵＣＩ部分の各々について、優先基準および利用可能なＵＣＩ部分に基づいて、受信されたＵＣＩ部分のＵＣＩタイプを判定してよい。

例えば、第５の態様の実装形態では、回路は、動作時に、ＵＣＩタイプの判定において、受信されたＵＣＩ部分の１つまたは複数がハイブリッド自動再送要求（ＨＡＲＱ）報告である場合、当該１つまたは複数の受信されたＵＣＩ部分の各々について、ＨＡＲＱ報告に関連付けられた下りリンク（ＤＬ）トラフィックのＨＡＲＱプロセスＩＤを判定してよい。

一般に、第５の態様の実装形態では、優先基準は、ＨＡＲＱ報告である利用可能なＵＣＩ部分の各々について、ＨＡＲＱ報告の優先度を含み、ＨＡＲＱ報告の優先度は、（ｉ）ＤＬトラフィックの周期性、（ｉｉ）或るＨＡＲＱプロセスＩＤと同一のＨＡＲＱプロセスＩＤを有するＤＬトラフィックの次のインスタンスが受信されるまでの予期される時間の長さ、（ｉｉｉ）ＨＡＲＱ報告が肯定応答（ＡＣＫ）であるかＨＡＲＱ否定応答（ＮＡＣＫ）であるか、および／または（ｉｖ）前記ＤＬトラフィックの優先度に依存する。

第６の態様によれば、スケジューリングデバイスのための方法が提供される。本方法は、（ｉ）ＵＣＩ送信用の複数の送信機会を示す通知を含むシグナリング情報を生成するステップと、（ｉｉ）生成されたシグナリング情報を送信するステップと、（ｉｉｉ）複数の送信機会のうちの１つにおいて、１つまたは複数のＵＣＩ部分を受信するステップと、（ｉｖ）ＵＣＩに関連付けられた優先基準に基づいて、１つまたは複数のＵＣＩ部分の各々について、ＵＣＩ部分のＵＣＩタイプを判定するステップと、を含む。

第６の態様の実装形態では、本方法は、（ｉ）１つまたは複数のＵＣＩ部分を送信したＵＥによってどのＵＣＩ部分が送信に利用可能であったかを判定するステップと、（ｉｉ）１つまたは複数の受信されたＵＣＩ部分の各々について、優先基準および利用可能なＵＣＩ部分に基づいて、受信されたＵＣＩ部分のＵＣＩタイプを判定するステップと、をさらに含んでよい。

例えば、第６の態様の実装形態では、受信されたＵＣＩ部分のうちの１つまたは複数がハイブリッド自動再送要求（ＨＡＲＱ）報告である場合、ＵＣＩタイプを判定するステップは、前記１つまたは複数の受信されたＵＣＩ部分の各々について、ＨＡＲＱ報告に関連付けられたＤＬトラフィックのＨＡＲＱプロセスＩＤを判定することを含んでよい。

一般に、第６の態様の実装形態では、優先基準は、ＨＡＲＱ報告である利用可能なＵＣＩ部分の各々について、ＨＡＲＱ報告の優先度を含み、ＨＡＲＱ報告の優先度は、（ｉ）ＤＬトラフィックの周期性、（ｉｉ）或るＨＡＲＱプロセスＩＤと同一のＨＡＲＱプロセスＩＤを有するＤＬトラフィックの次のインスタンスが受信されるまでの予期される時間の長さ、（ｉｉｉ）ＨＡＲＱ報告が肯定応答（ＡＣＫ）であるか否定応答（ＮＡＣＫ）であるか、および／または（ｉｖ）前記ＤＬトラフィックの優先度に依存する。

要約すると、通信装置、ネットワークノード、および対応する方法が提供される。通信デバイスは、ＵＣＩ送信用の複数の送信機会を示す通知を取得する。ＵＣＩが送信に利用可能になる場合、通信デバイスは、利用可能なＵＣＩを送信するための複数の送信機会のうちの送信機会を使用するか否かを、利用可能なＵＣＩに関連付けられた優先基準に基づいて判定する。利用可能なＵＣＩの送信に送信機会が使用されると判定される場合、通信デバイスは、利用可能なＵＣＩを送信するために送信機会を使用する。

Claims (17)

1. 動作時に、
   ― 上りリンク制御情報（ＵＣＩ：Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）を送信するための複数の送信機会を示す通知を取得し、
   ― ＵＣＩが送信に利用可能であると判定し、
   ― 前記利用可能なＵＣＩに関連付けられた優先基準に基づいて、前記利用可能なＵＣＩの送信用の前記複数の送信機会のうちの送信機会を使用するか否かを判定する、
   回路と、
   動作時に、前記利用可能なＵＣＩの送信に前記送信機会が使用されると判定される場合、前記利用可能なＵＣＩの送信用の前記送信機会を使用する送受信部と、
   を備えるユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）。
2. 前記利用可能なＵＣＩは、複数のＵＣＩ部分を含み、
   前記優先基準は、前記複数のＵＣＩ部分の各々について、それぞれの優先度を含み、
   前記複数のＵＣＩ部分のうちの１つのＵＣＩ部分の優先度は、
   ― 当該１つのＵＣＩ部分のタイプおよび／もしくは内容、ならびに／または
   ― 前記送受信部によって受信された前記優先度の通知に依存する、
   請求項１に記載のＵＥ。
3. 前記回路は、動作時、
   ― 前記送信機会が前記利用可能なＵＣＩの送信に使用されると判定され、かつ、前記利用可能なＵＣＩのペイロードサイズが前記送信機会のペイロードサイズよりも大きいと判定される場合、前記優先基準に基づいて、前記複数のＵＣＩ部分のうちのどれが前記送信機会において送信されるかを判定し、かつ／または、
   ― 前記利用可能なＵＣＩの送信に前記送信機会が使用されると判定され、かつ、前記利用可能なＵＣＩのペイロードサイズが前記送信機会のペイロードサイズ以下であると判定される場合、前記複数のＵＣＩ部分のすべてが前記送信機会において送信されると判定する、
   請求項２に記載のＵＥ。
4. 前記利用可能なＵＣＩは、１つまたは複数のハイブリッド自動再送要求（ＨＡＲＱ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）報告を含み、
   各ＨＡＲＱ報告は、或るＨＡＲＱプロセスＩＤの下りリンク（ＤＬ）トラフィックに関連付けられ、
   前記優先基準は、前記１つまたは複数のＨＡＲＱ報告の各々について、当該ＨＡＲＱ報告の優先度を含み、前記ＨＡＲＱ報告の優先度は、
   ― 前記ＨＡＲＱ報告に関連付けられた前記ＤＬトラフィックの周期性、
   ― 前記或るＨＡＲＱプロセスＩＤと同一のＨＡＲＱプロセスＩＤを有する前記ＨＡＲＱ報告に関連付けられた前記ＤＬトラフィックの次のインスタンスが受信されるまでの、予期される時間の長さ、
   ― 前記ＨＡＲＱ報告が肯定応答（ＡＣＫ）であるか否定応答（ＮＡＣＫ）であるか、および／または
   ― 前記ＨＡＲＱ報告に関連付けられた前記ＤＬトラフィックの優先度、
   に依存する、
   請求項１に記載のＵＥ。
5. 前記１つまたは複数のＨＡＲＱ報告の各々について、前記ＨＡＲＱ報告の前記優先度は、
   ― 前記ＨＡＲＱ報告に関連付けられた前記ＤＬトラフィックの周期性が高いほど高く、
   ― 前記ＨＡＲＱ報告に関連付けられた前記ＤＬトラフィックの前記次のインスタンスが受信されるまでの予期される時間の長さが短いほど高く、
   ― 前記ＨＡＲＱ報告がＡＣＫである場合よりも前記ＨＡＲＱ報告がＮＡＣＫである場合に高く、かつ／または
   ― 前記ＨＡＲＱ報告に関連付けられた前記ＤＬトラフィックの優先度が高いほど高い、
   請求項４に記載のＵＥ。
6. 前記ＵＥには、１つまたは複数の半永続的スケジューリング（ＳＰＳ：Ｓｅｍｉ－Ｐｅｒｓｉｓｔｅｎｔ Ｓｃｈｅｄｕｌｉｎｇ）設定が設定されており、
   前記設定された１つまたは複数のＳＰＳ設定は、それぞれのＤＬ ＳＰＳトラフィックに対応し、それぞれの或るＨＡＲＱプロセスＩＤに関連付けられており、
   前記ＨＡＲＱに関連付けられた前記ＤＬトラフィックは、前記ＤＬ ＳＰＳトラフィックである、
   請求項４または５に記載のＵＥ。
7. 前記利用可能なＵＣＩは、１つまたは複数のハイブリッド自動再送要求（ＨＡＲＱ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）報告を含み、各ＨＡＲＱ報告は、或るＨＡＲＱプロセスＩＤの下りリンク（ＤＬ）トラフィックに関連付けられており、
   前記優先基準は、前記１つまたは複数のＨＡＲＱ報告の各々について、オフセット値のシーケンスを含み、前記オフセット値のシーケンスは、前記或るＨＡＲＱプロセスＩＤに関連付けられており、前記ＤＬトラフィックの受信時間に関連して、前記ＨＡＲＱ報告を送信するための対応する送信時間のシーケンスを示す、
   前記回路は、動作時に、前記ＨＡＲＱ報告の前記送信時間のシーケンスのうちの１つまたは複数のシーケンスにおける、いかなるＤＬシンボルとも衝突しない第１の送信時間に前記送信機会が対応する場合、前記送信機会が前記利用可能なＵＣＩの送信用に使用されると判定し、
   前記送受信部は、動作時に、前記送信機会が第１の送信時間に対応するＨＡＲＱ報告を送信するために前記送信機会を使用する、
   請求項１に記載のＵＥ。
8. 前記送受信部は、動作時に、
   ― 半永続的スケジューリング（ＳＰＳ）設定の一部として、
   ― 無線リソース制御（ＲＲＣ：Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）シグナリングにおいて、
   ― 物理下りリンク共有チャネル（ＰＤＳＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）において、
   ― 物理下りリンク制御チャネル（ＰＤＣＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）において、かつ／または
   ― 下りリンク制御情報（ＤＣＩ：Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）において、
   前記優先基準を示す通知を受信する、
   請求項１に記載のＵＥ。
9. 前記送信機会は、前記複数の送信機会のうちの次の送信機会であり、
   前記回路は、動作時に、前記優先基準に基づいて、他のＵＣＩが送信に利用可能になるまで任意のＵＣＩの送信を延期するか否かを判定し、
   前記他のＵＣＩは、前記利用可能なＵＣＩとは異なるＵＣＩである、
   請求項１に記載のＵＥ。
10. 前記回路は、動作時に、前記送信機会の後に、
    ― 前記他のＵＣＩが送信に利用可能であると判定し、かつ、
    ― 前記利用可能なＵＣＩおよび前記他のＵＣＩを送信するために後続の送信機会を使用すると決定し、前記後続の送信機会は、前記複数の送信機会のうちの、前記送信機会の後の送信機会であり、
    前記送受信部は、動作時に、前記利用可能なＵＣＩおよび前記他のＵＣＩを送信するために前記後続の送信機会を使用する、
    請求項９に記載のＵＥ。
11. 前記回路は、動作時に、前記優先基準に基づいて、前記複数の送信機会のうちの２つ以上の各々において前記ＵＣＩ部分を送信するか否かを判定する、
    請求項１に記載のＵＥ。
12. 前記ＵＥは、時分割複信（ＴＤＤ：Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ）で動作しており、
    前記回路は、動作時に、前記送信機会が１つまたは複数のＤＬシンボルと衝突する場合、前記送信機会が前記利用可能なＵＣＩの送信用に使用されないと判定する、
    請求項１に記載のＵＥ。
13. 動作時に、
    － 利用可能な上りリンク制御情報（ＵＣＩ：Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）を送信するための複数の送信機会のうちの送信機会を使用するか否かを判定する際に基づく優先基準を決定し、
    － 前記優先基準を示す通知を含む第１のシグナリング情報を生成し、
    － ＵＣＩ送信用の複数の送信機会を決定し、
    － 前記複数の送信機会を示す通知を含む第２のシグナリング情報を生成する、
    回路と、
    動作時に、
    － 前記第１のシグナリング情報を送信し、
    － 前記第２のシグナリング情報を送信する、
    送受信部と、
    と備えるスケジューリングデバイス。
14. 上りリンク制御情報（ＵＣＩ：Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）を送信するための複数の送信機会を示す通知を取得するステップと、
    ＵＣＩが送信に利用可能であると判定するステップと、
    前記利用可能なＵＣＩに関連付けられた優先基準に基づいて、前記利用可能なＵＣＩの送信用の前記複数の送信機会のうちの送信機会を使用するか否かを判定するステップと、
    前記利用可能なＵＣＩの送信に前記送信機会が使用されると判定される場合、前記利用可能なＵＣＩを送信するために前記送信機会を使用するステップと、
    を含む、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）のための方法。
15. 利用可能な上りリンク制御情報（ＵＣＩ：Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）を送信するための複数の送信機会のうちの送信機会を使用するか否かを判定する際に基づく優先基準を決定するステップと、
    前記優先基準を示す通知を含む第１のシグナリング情報を生成するステップと、
    前記第１のシグナリング情報を送信するステップと、
    ＵＣＩ送信用の複数の送信機会を決定するステップと、
    前記複数の送信機会を示す通知を含む第２のシグナリング情報を生成するステップと、
    前記第２のシグナリング情報を送信するステップと、
    を含む、スケジューリングデバイスのための方法。
16. 動作時に、ユーザ機器（ＵＥ）の処理を制御する集積回路であって、前記処理は、
    上りリンク制御情報（ＵＣＩ：Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）を送信するための複数の送信機会を示す通知を取得するステップと、
    ＵＣＩが送信に利用可能であると判定するステップと、
    前記利用可能なＵＣＩに関連付けられた優先基準に基づいて、前記利用可能なＵＣＩの送信用の前記複数の送信機会のうちの送信機会を使用するか否かを判定するステップと、
    前記利用可能なＵＣＩの送信に前記送信機会が使用されると判定される場合、前記利用可能なＵＣＩを送信するために前記送信機会を使用するステップと、
    を含む、集積回路。
17. 動作時に、スケジューリングデバイスの処理を制御する集積回路であって、前記処理は、
    利用可能な上りリンク制御情報（ＵＣＩ：Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）を送信するための複数の送信機会のうちの送信機会を使用するか否かを判定する際に基づく優先基準を決定するステップと、
    前記優先基準を示す通知を含む第１のシグナリング情報を生成するステップと、
    前記第１のシグナリング情報を送信するステップと、
    ＵＣＩ送信用の複数の送信機会を決定するステップと、
    前記複数の送信機会を示す通知を含む第２のシグナリング情報を生成するステップと、
    前記第２のシグナリング情報を送信するステップと、
    を含む、集積回路。
    

Images