(57)【要約】本開示のさまざまな態様は、一般的にワイヤレス通信に関連する。いくつかの態様では、ユーザ機器（ＵＥ）は、物理アップリンク制御チャネル（ＰＵＣＣＨ）送信が第１のタイプのサービスに関係付けられているかまたは第２のタイプのサービスに関係付けられているかを決定してもよく、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられている。ＵＥは、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、リソースの第１のセットを使用して、または、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、リソースの第２のセットを使用して、ＰＵＣＣＨ送信を送信してもよい。多数の他の態様が提供される。【選択図】図７
2021523617.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ機器（ＵＥ）によって実行されるワイヤレス通信の方法において、
物理アップリンク制御チャネル（ＰＵＣＣＨ）送信が第１のタイプのサービスに関係付けられているかまたは第２のタイプのサービスに関係付けられているかを決定し、前記第２のタイプのサービスは、前記第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることと、
前記ＰＵＣＣＨ送信が前記第１のタイプのサービスに関係付けられているとき、リソースの第１のセットに少なくとも部分的に基づいて、または、前記ＰＵＣＣＨ送信が前記第２のタイプのサービスに関係付けられているとき、リソースの第２のセットに少なくとも部分的に基づいて、前記ＰＵＣＣＨ送信を送信することとを含む方法。
【請求項２】
前記第１のタイプのサービスは、拡張移動体ブロードバンド（ｅＭＢＢ）サービスを含み、前記第２のタイプのサービスは、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）サービスを含む請求項１記載の方法。
【請求項３】
前記リソースの第１のセットは、前記第１のタイプのサービスに対して構成されている複数のリソースセットを含む請求項１記載の方法。
【請求項４】
前記リソースの第２のセットは、前記第２のタイプのサービスに対して構成されている複数のリソースセットを含む請求項１記載の方法。
【請求項５】
前記ＰＵＣＣＨ送信は、
ハイブリッド自動再送要求肯定応答（ＨＡＲＱ−ＡＣＫ）情報、
サービス要求（ＳＲ）、または、
チャネル状態情報（ＣＳＩ）報告のうちの少なくとも１つを含む請求項１記載の方法。
【請求項６】
前記ＡＣＫ／ＮＡＣＫは、動的スケジューリングまたは半永続的スケジューリング（ＳＰＳ）に関係付けられている請求項５記載の方法。
【請求項７】
前記リソースの第１のセットは４つのリソースセットを含み、前記リソースの第２のセットは４つ未満のリソースセットを含む請求項１記載の方法。
【請求項８】
前記リソースの第１のセットは、前記リソースの第２のセットとは異なる請求項１記載の方法。
【請求項９】
前記リソースの第２のセット中のリソースセットの数は、前記リソースの第１のセット中のリソースセットの数よりも少ない請求項１記載の方法。
【請求項１０】
前記リソースの第１のセットのうちの少なくとも１つのリソースセットは、前記リソースの第２のセット中に含まれるリソースセットと同じリソースセットである請求項１記載の方法。
【請求項１１】
前記リソースの第２のセットの各セット内のリソースの数は、前記リソースの第１のセットの各セット内のリソースの数よりも少ない請求項１記載の方法。
【請求項１２】
前記ＵＥは、前記ＰＵＣＣＨ送信に関係して基地局から受信したダウンリンク制御情報（ＤＣＩ）中のＰＵＣＣＨリソースインジケータフィールドのビット幅に少なくとも部分的に基づいて、前記リソースの第１のセットまたは前記リソースの第２のセットの各セット内のリソースの数を決定するように構成されている請求項１記載の方法。
【請求項１３】
前記ＰＵＣＣＨ送信は、前記ＰＵＣＣＨ送信が前記第２のタイプのサービスに関係付けられているという決定に少なくとも部分的に基づいて、前記リソースの第２のセットの２つ以上のリソース上で送信される請求項１記載の方法。
【請求項１４】
前記ＰＵＣＣＨ送信は、前記ＰＵＣＣＨ送信が前記第２のタイプのサービスに関係付けられているという決定に少なくとも部分的に基づいて、前記リソースの第２のセットの２つのリソース上で、少なくとも２つの送信アンテナを介して送信される請求項１記載の方法。
【請求項１５】
前記リソースの第２のセットのうちの１つのセットの少なくとも２つのリソースは、同じ識別子を共有し、前記ＰＵＣＣＨ送信は、前記識別子が前記ＰＵＣＣＨ送信に関係して受信されるとき、前記少なくとも２つのリソースを使用して送信される請求項１記載の方法。
【請求項１６】
前記ＰＵＣＣＨ送信は、基地局から、前記ＰＵＣＣＨ送信に関係して、インデックスと半静的に受信されるコンフィギュレーションとを受信することに少なくとも部分的に基づいて、前記リソースの第２のセットの１つ以上のリソースを使用して送信される請求項１記載の方法。
【請求項１７】
前記リソースの第２のセットのリソースは、前記ＰＵＣＣＨ送信に関連する使用のために、前記リソースの第１のセットのリソースとは異なって識別される請求項１記載の方法。
【請求項１８】
前記リソースの第２のセットのリソースは、異なるＰＵＣＣＨフォーマットを使用することに関連して、前記ＰＵＣＣＨ送信に関連する使用のために、前記リソースの第１のセットのリソースとは異なって識別される請求項１７記載の方法。
【請求項１９】
前記リソースの第１のセットのリソースは、前記リソースの第１のセットのリソースに関係付けられているパラメータの第１の値に少なくとも部分的に基づいて、前記第１のタイプのサービスに関係する使用のために識別され、または、前記リソースの第２のセットのリソースは、前記リソースの第２のセットのリソースに関係付けられている前記パラメータの第２の値に少なくとも部分的に基づいて、前記第２のタイプのサービスに関係する使用のために識別される請求項１記載の方法。
【請求項２０】
前記ＰＵＣＣＨ送信のリソースに対して、パラメータは、前記パラメータの値に少なくとも部分的に基づいて、前記リソースが、前記第１のタイプのサービスに、前記第２のタイプのサービスに、または、前記第１のタイプのサービスと前記第２のタイプのサービスの両方に関係付けられているか否かを示す請求項１記載の方法。
【請求項２１】
前記パラメータは、前記ＰＵＣＣＨ送信に対する前記リソースのコンフィギュレーション内に含まれる請求項２０記載の方法。
【請求項２２】
前記パラメータの値は、前記リソースの第１のセットと前記リソースの第２のセットの同じリソースが、前記第１のタイプのサービスと前記第２のタイプのサービスとに関係付けられていることを示す請求項２０記載の方法。
【請求項２３】
前記リソースの第１のセットは、前記リソースの第２のセットとリソースの同じセットであり、前記リソースの同じセットの各リソースは、前記ＰＵＣＣＨ送信が前記第１のタイプのサービスに関係付けられているとき、前記ＰＵＣＣＨ送信に対する第１の識別子に関係付けられ、前記ＰＵＣＣＨ送信が前記第２のタイプのサービスに関係付けられているとき、前記ＰＵＣＣＨ送信に対する第２の識別子に関係付けられる請求項１記載の方法。
【請求項２４】
前記ＰＵＣＣＨ送信は、前記第１のタイプのサービスまたは前記第２のタイプのサービスに関係付けられているインデックスを示すダウンリンク制御情報を受信することに少なくとも部分的に基づいて、前記リソースの同じセットのうちの１つを使用して送信される請求項２３記載の方法。
【請求項２５】
開始シンボルパラメータは、前記ＰＵＣＣＨ送信が前記第２のタイプのサービスに関係付けられているときとは異なる開始シンボルを、前記ＰＵＣＣＨ送信が前記第１のタイプのサービスに関係付けられるときに識別する請求項１記載の方法。
【請求項２６】
前記ＰＵＣＣＨ送信が前記第１のタイプのサービスに関係付けられているときの、前記開始シンボルパラメータは、前記ＰＵＣＣＨ送信に対するスロットに関する相対インデックスを識別する請求項２５記載の方法。
【請求項２７】
前記ＰＵＣＣＨ送信が前記第２のタイプのサービスに関係付けられているときの、前記開始シンボルパラメータは、ダウンリンク制御情報（ＤＣＩ）中のシグナリングに関係付けられているタイミングを識別する請求項２５記載の方法。
【請求項２８】
前記ＰＵＣＣＨ送信が前記第１のタイプのサービスに関係付けられているとき、前記ＰＵＣＣＨ送信中のハイブリッド自動再送要求肯定応答（ＨＡＲＱ−ＡＣＫ）情報は、第１のダウンリンク割り当てインデックス（ＤＡＩ）動作にしたがって決定され、前記ＰＵＣＣＨ送信が前記第２のタイプのサービスに関係付けられているとき、前記ＰＵＣＣＨ送信中の前記ＨＡＲＱ−ＡＣＫ情報は、第２のＤＡＩ動作にしたがって決定される請求項１記載の方法。
【請求項２９】
前記ＰＵＣＣＨ送信が、前記第１のタイプのサービスに関係付けられている第１のＰＵＣＣＨ送信であり、前記第２のタイプのサービスに関係付けられている第２のＰＵＣＣＨ送信が、前記第１のＰＵＣＣＨ送信のシンボルとオーバーラップするシンボルを使用して送信されることになるとき、前記オーバーラップするシンボルは、前記第１のＰＵＣＣＨ送信からドロップされる請求項１記載の方法。
【請求項３０】
基地局（ＢＳ）によって実行されるワイヤレス通信の方法において、
第１のタイプのサービスに関係付けられている物理アップリンク制御チャネル（ＰＵＣＣＨ）送信のために使用されることになるＰＵＣＣＨリソースの第１のコンフィギュレーションを決定することと、
第２のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定し、前記第２のタイプのサービスは、前記第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることと、
前記第１のコンフィギュレーションと前記第２のコンフィギュレーションとをユーザ機器（ＵＥ）に送信することとを含む方法。
【請求項３１】
前記第１のタイプのサービスは、拡張移動体ブロードバンド（ｅＭＢＢ）サービスを含み、前記第２のタイプのサービスは、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）サービスを含む請求項３０記載の方法。
【請求項３２】
前記第１のコンフィギュレーションは、前記第２のコンフィギュレーションとは異なる請求項３０記載の方法。
【請求項３３】
前記第１のコンフィギュレーション中に含まれるＰＵＣＣＨリソースのセットは、前記第２のコンフィギュレーション中に含まれるＰＵＣＣＨリソースのセットとは異なる請求項３０記載の方法。
【請求項３４】
前記第２のコンフィギュレーションは、前記第１のコンフィギュレーションよりもＰＵＣＣＨリソースのより少ないセットを含む請求項３０記載の方法。
【請求項３５】
前記第２のコンフィギュレーション中に含まれるＰＵＣＣＨリソースの各セット中のＰＵＣＣＨリソースの数は、前記第１のコンフィギュレーション中に含まれるＰＵＣＣＨリソースの各セット中のＰＵＣＣＨリソースの数よりも少ない請求項３０記載の方法。
【請求項３６】
ダウンリンク制御情報（ＤＣＩ）中のＰＵＣＣＨリソースインジケータのビット幅は、前記第２のコンフィギュレーション中に含まれるＰＵＣＣＨリソースの各セット中のＰＵＣＣＨリソースの数にしたがっている前記第２のタイプのサービスに対応する請求項３０記載の方法。
【請求項３７】
前記第１のコンフィギュレーションおよび前記第２のコンフィギュレーションの各ＰＵＣＣＨリソースに対して、パラメータは、前記ＰＵＣＣＨリソースが、前記第１のタイプのサービスに、前記第２のタイプのサービスに、または、前記第１のタイプのサービスと前記第２のタイプのサービスの両方に関係付けられているか否かを示す請求項３０記載の方法。
【請求項３８】
前記第１のコンフィギュレーションのリソースの第１のセットは、前記第２のコンフィギュレーションのリソースの第２のセットとリソースの同じセットであり、前記リソースの同じセットの各リソースは、前記ＰＵＣＣＨ送信が前記第１のタイプのサービスに関係付けられているとき、ＰＵＣＣＨ送信に対する第１の識別子に関係付けられ、前記ＰＵＣＣＨ送信が前記第２のタイプのサービスに関係付けられているとき、前記ＰＵＣＣＨ送信に対する第２の識別子に関係付けられる請求項３０記載の方法。
【請求項３９】
前記第１のコンフィギュレーションは、前記第１のタイプに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１の複数のコンフィギュレーションのうちの１つである請求項３０記載の方法。
【請求項４０】
前記第１のコンフィギュレーションの最大コーディングレートは、前記第２のコンフィギュレーションの最大コーディングレートとは異なる請求項３０記載の方法。
【請求項４１】
ユーザ機器（ＵＥ）によって実行されるワイヤレス通信の方法において、
第１のサービスタイプに関係付けられている送信のためのパラメータの第１のセットと、第２のサービスタイプに関係付けられている送信のためのパラメータの第２のセットとを含む物理アップリンク制御チャネル（ＰＵＣＣＨ）コンフィギュレーションを受信することと、
アップリンク制御情報（ＵＣＩ）を発生させることと、
前記ＰＵＣＣＨコンフィギュレーションとメッセージのサービスタイプとにしたがって、前記ＵＣＩを含む前記メッセージを送信することとを含む方法。
【請求項４２】
前記メッセージのサービスタイプは、基地局から受信したダウンリンク制御情報（ＤＣＩ）に少なくとも部分的に基づいて決定される請求項４１記載の方法。
【請求項４３】
前記パラメータの第１のセットによって示される最大コーディングレートは、前記パラメータの第２のセットによって示される最大コーディングレートとは異なる請求項４１記載の方法。
【請求項４４】
ワイヤレス通信のためのユーザ機器（ＵＥ）において、
メモリと、
前記メモリに結合されている１つ以上のプロセッサとを具備し、
前記メモリおよび前記１つ以上のプロセッサは、
物理アップリンク制御チャネル（ＰＵＣＣＨ）送信が第１のタイプのサービスに関係付けられているかまたは第２のタイプのサービスに関係付けられているかを決定し、前記第２のタイプのサービスは、前記第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられているように、
前記ＰＵＣＣＨ送信が前記第１のタイプのサービスに関係付けられているとき、リソースの第１のセットを使用して、または、前記ＰＵＣＣＨ送信が前記第２のタイプのサービスに関係付けられているとき、リソースの第２のセットを使用して、前記ＰＵＣＣＨ送信を送信するように構成されているＵＥ。
【発明の詳細な説明】
【米国特許法第１１９条に基づく関連出願への相互参照】
【０００１】
［０００１］
本出願は、「超高信頼性低レイテンシ通信（ＵＲＬＬＣ）に対する物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを割り振るための技術および装置」と題される、２０１８年５月１０日に出願された米国仮特許出願番号第６２／６６９，９４１号、および、「超高信頼性低レイテンシ通信（ＵＲＬＬＣ）に対する物理アップリンク制御チャネル（ＰＵＣＣＨ）リソース割り振り」と題される、２０１９年５月８日に出願された米国非仮特許出願第１６／４０６，６６７号に対する優先権を主張し、これらは、参照によりここに明示的に組み込まれている。
【開示の分野】
【０００２】
［０００２］
本開示の態様は、一般的にワイヤレス通信に関連し、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）に対する物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを割り振るための技術および装置に関連する。
【背景】
【０００３】
［０００３］
ワイヤレス通信システムは、電話、ビデオ、データ、メッセージング、および、ブロードキャストのようなさまざまな電気通信サービスを提供するために広く配備されている。典型的なワイヤレス通信システムは、（例えば、帯域幅、送信電力、および／または、これらに類するもののような）利用可能なシステムリソースを共有することによって、複数のユーザとの通信をサポートすることができる多元接続テクノロジーを用いるかもしれない。このような多元接続テクノロジーの例は、コード分割多元接続（ＣＤＭＡ）システム、時分割多元接続（ＴＤＭＡ）システム、周波数分割多元接続（ＦＤＭＡ）システム、直交周波数分割多元接続（ＯＦＤＭＡ）システム、単一搬送波周波数分割多元接続（ＳＣ−ＦＤＭＡ）システム、時分割同期コード分割多元接続（ＴＤ−ＳＣＤＭＡ）システム、および、ロングタームエボリューション（ＬＴＥ（登録商標））を含んでいる。ＬＴＥ／ＬＴＥアドバンストは、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））によって公表されたユニバーサル移動体電気通信システム（ＵＭＴＳ）の移動体標準規格への拡張のセットである。
【０００４】
［０００４］
ワイヤレス通信ネットワークは、多数のユーザ機器（ＵＥ）のための通信をサポートすることができる多数の基地局（ＢＳ）を含んでいてもよい。ユーザ機器（ＵＥ）は、ダウンリンクおよびアップリンクを介して、基地局（ＢＳ）と通信してもよい。ダウンリンク（または、フォワードリンク）は、ＢＳからＵＥへの通信リンクを指し、アップリンク（または、リバースリンク）は、ＵＥからＢＳへの通信リンクを指している。ここでより詳細に説明するように、ＢＳは、ノードＢ、ｇＮＢ、アクセスポイント（ＡＰ）、無線ヘッド、送受信ポイント（ＴＲＰ）、新たな無線（ＮＲ）ＢＳ、５ＧノードＢ、および／または、これらに類するものとして呼ばれることがある。
【０００５】
［０００５］
上記の多元接続テクノロジーは、異なるユーザ機器が市区町村レベル、国レベル、地域レベル、さらにはグローバルレベルで通信できるようにする共通のプロトコルを提供するために、さまざまな電気通信標準規格に採用されている。５Ｇとしても呼ばれることがある新たな無線（ＮＲ）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって公表されたＬＴＥ移動体標準規格に対する拡張のセットである。ＮＲは、スペクトル効率を改善することと、コストを下げることと、サービスを改善することと、新たなスペクトルを使用することと、ダウンリンク（ＤＬ）でサイクリックプリフィックス（ＣＰ）を有する直交周波数分割多重化（ＯＦＤＭＡ）（ＣＰ−ＯＦＤＭ）を使用し、アップリンク（ＵＬ）上で（例えば、離散フーリエ変換拡散ＯＦＤＭ（ＤＦＴ−ｓ−ＯＦＤＭ）としても知られている）ＣＰ−ＯＦＤＭおよび／またはＳＣ−ＦＤＭを使用して、他のオープン標準規格とより良く統合するとともに、ビーム形成、複数入力複数出力（ＭＩＭＯ）アンテナテクノロジー、および、搬送波アグリゲーションをサポートすることにより、移動体ブロードバンドインターネットアクセスをより良くサポートするように設計されている。しかしながら、移動体ブロードバンドアクセスのための需要が増え続けると、ＬＴＥおよびＮＲテクノロジーにおけるさらなる改善に対する必要性が存在する。好ましくは、これらの改善は、これらのテクノロジーを用いる他の多元接続テクノロジーと電気通信標準規格とに適用可能であるべきである。
【概要】
【０００６】
［０００６］
いくつかの態様では、ＵＥによって実行されるワイヤレス通信の方法は、物理アップリンク制御チャネル（ＰＵＣＣＨ）送信が第１のタイプのサービスに関係付けられているかまたは第２のタイプのサービスに関係付けられているかを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることと、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、リソースの第１のセットを使用して、または、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、リソースの第２のセットを使用して、ＰＵＣＣＨ送信を送信することとを含んでいてもよい。
【０００７】
［０００７］
いくつかの態様では、ワイヤレス通信のためのＵＥは、メモリと、メモリに結合されている１つ以上のプロセッサとを含んでいてもよい。メモリおよび１つ以上のプロセッサは、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているかまたは第２のタイプのサービスに関係付けられているかを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられるように、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、リソースの第１のセットを使用して、または、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、リソースの第２のセットを使用して、ＰＵＣＣＨ送信を送信するように構成されていてもよい。
【０００８】
［０００８］
いくつかの態様では、非一時的コンピュータ読取可能媒体は、ワイヤレス通信のための１つ以上の命令を記憶していてもよい。１つ以上の命令は、ＵＥの１つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているかまたは第２のタイプのサービスに関係付けられているかを決定させ、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられ、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、リソースの第１のセットを使用させて、または、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、リソースの第２のセットを使用させて、ＰＵＣＣＨ送信を送信させてもよい。
【０００９】
［０００９］
いくつかの態様では、ワイヤレス通信のための装置は、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているかまたは第２のタイプのサービスに関係付けられているかを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられる手段と、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、リソースの第１のセットを使用して、または、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、リソースの第２のセットを使用して、ＰＵＣＣＨ送信を送信する手段とを含んでいてもよい。
【００１０】
［００１０］
いくつかの態様では、ＵＥによって実行されるワイヤレス通信の方法は、第１のサービスタイプに関係付けられている送信のためのパラメータの第１のセットと、第２のサービスタイプに関係付けられている送信のためのパラメータの第２のセットとを含むＰＵＣＣＨコンフィギュレーションを受信することと、アップリンク制御情報（ＵＣＩ）を発生させることと、ＰＵＣＣＨコンフィギュレーションとメッセージのサービスタイプとにしたがって、ＵＣＩを含むメッセージを送信することとを含んでいてもよい。
【００１１】
［００１１］
いくつかの態様では、ワイヤレス通信のためのＵＥは、メモリと、メモリに結合されている１つ以上のプロセッサとを含んでいてもよい。メモリおよび１つ以上のプロセッサは、第１のサービスタイプに関係付けられている送信のためのパラメータの第１のセットと、第２のサービスタイプに関係付けられている送信のためのパラメータの第２のセットとを含むＰＵＣＣＨコンフィギュレーションを受信するように、ＵＣＩを発生させるように、ＰＵＣＣＨコンフィギュレーションとメッセージのサービスタイプとにしたがって、ＵＣＩを含むメッセージを送信するように構成されていてもよい。
【００１２】
［００１２］
いくつかの態様では、非一時的コンピュータ読取可能媒体は、ワイヤレス通信のための１つ以上の命令を記憶していてもよい。１つ以上の命令は、ＵＥの１つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、第１のサービスタイプに関係付けられている送信のためのパラメータの第１のセットと、第２のサービスタイプに関係付けられている送信のためのパラメータの第２のセットとを含むＰＵＣＣＨコンフィギュレーションを受信させ、ＵＣＩを発生させ、ＰＵＣＣＨコンフィギュレーションとメッセージのサービスタイプとにしたがって、ＵＣＩを含むメッセージを送信させてもよい。
【００１３】
［００１３］
いくつかの態様では、ワイヤレス通信のための装置は、第１のサービスタイプに関係付けられている送信のためのパラメータの第１のセットと、第２のサービスタイプに関係付けられている送信のためのパラメータの第２のセットとを含むＰＵＣＣＨコンフィギュレーションを受信する手段と、ＵＣＩを発生させる手段と、ＰＵＣＣＨコンフィギュレーションとメッセージのサービスタイプとにしたがって、ＵＣＩを含むメッセージを送信する手段とを含んでいてもよい。
【００１４】
［００１４］
いくつかの態様では、基地局によって実行されるワイヤレス通信の方法は、第１のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１のコンフィギュレーションを決定することと、第２のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることと、第１のコンフィギュレーションと第２のコンフィギュレーションとをＵＥに送信することとを含んでいてもよい。
【００１５】
［００１５］
いくつかの態様では、ワイヤレス通信のための基地局は、メモリと、メモリに結合されている１つ以上のプロセッサとを含んでいてもよい。メモリおよび１つ以上のプロセッサは、第１のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１のコンフィギュレーションを決定するように、第２のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられているように、第１のコンフィギュレーションと第２のコンフィギュレーションとをＵＥに送信するように構成されていてもよい。
【００１６】
［００１６］
いくつかの態様では、非一時的コンピュータ読取可能媒体は、ワイヤレス通信のための１つ以上の命令を記憶していてもよい。１つ以上の命令は、基地局の１つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、第１のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１のコンフィギュレーションを決定させ、第２のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定させ、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられ、第１のコンフィギュレーションと第２のコンフィギュレーションとをＵＥに送信させてもよい。
【００１７】
［００１７］
いくつかの態様では、ワイヤレス通信のための装置は、第１のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１のコンフィギュレーションを決定する手段と、第２のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられている手段と、第１のコンフィギュレーションと第２のコンフィギュレーションとをＵＥに送信する手段とを含んでいてもよい。
【００１８】
［００１８］
態様は、一般的に、添付の図面と明細書とを参照してここで実質的に説明し、添付の図面によって図示されているような、方法、装置、システム、コンピュータプログラム製品、非一時的コンピュータ読取可能媒体、ユーザ機器、基地局、ワイヤレス通信デバイス、および／または、処理システムを含んでいる。
【００１９】
［００１９］
前述は、以下の詳細な説明がより良く理解されるように、本開示にしたがう例の特徴および技術的利点をどちらかといえば広く概説している。追加の特徴および利点を以下に説明する。開示される概念および特定の例を、本開示の同じ目的を実行する他の構造を修正または設計するためのベースとして容易に利用できる。このような均等な構造は、添付の特許請求の範囲の範囲から逸脱しない。ここで説明する概念の特性、それらの構成および動作の方法の両方、ならびに、関係する利点は、添付の図に関連して考慮されるとき、以下の説明からより良く理解されるだろう。図のそれぞれは、実例および説明の目的のために提供されており、特許請求の範囲の限定の定義として提供されているものではない。
【図面の簡単な説明】
【００２０】
［００２０］
本開示の先に記載した特徴を詳細に理解できるように、上で簡単に要約されたもののより特定の説明が、態様への参照によって得られてもよく、態様のうちのいくつかは、添付した図面に図示されている。しかしながら、添付図面はこの開示のある典型的な態様を図示しているに過ぎず、したがって、説明は他の等しく有効な態様を許すことから、範囲を限定するものとして添付図面を解釈してはならないことに留意すべきである。異なる図面における同じ参照番号は、同じまたは同様の要素を識別しているかもしれない。
【図１】［００２１］  図１は、本開示のさまざまな態様にしたがう、ワイヤレス通信ネットワークの例を概念的に図示するブロックダイヤグラムである。
【図２】［００２２］  図２は、本開示のさまざまな態様にしたがう、ワイヤレス通信ネットワーク中でユーザ機器（ＵＥ）と通信する基地局の例を概念的に図示するブロックダイヤグラムである。
【図３Ａ】［００２３］  図３Ａは、本開示のさまざまな態様にしたがう、ワイヤレス通信ネットワーク中のフレーム構造の例を概念的に図示するブロックダイヤグラムである。
【図３Ｂ】［００２４］  図３Ｂは、本開示のさまざまな態様にしたがう、ワイヤレス通信ネットワーク中の例示的な同期通信階層を概念的に図示するブロックダイヤグラムである。
【図４】［００２５］  図４は、本開示のさまざまな態様にしたがう、ノーマルサイクリックプリフィックスを有する例示的なスロットフォーマットを概念的に図示するブロックダイヤグラムである。
【図５】［００２６］  図５は、本開示のさまざまな態様にしたがう、ダウンリンク（ＤＬ）中心スロットの例を図示するダイヤグラムである。
【図６】［００２７］  図６は、本開示のさまざまな態様にしたがう、アップリンク（ＵＬ）中心スロットの例を図示するダイヤグラムである。
【図７】［００２８］  図７は、本開示のさまざまな態様にしたがう、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）に対する物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを割り振る例を図示するダイヤグラムである。
【図８】図８は、本開示のさまざまな態様にしたがう、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）に対する物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを割り振る例を図示するダイヤグラムである。
【図９】図９は、本開示のさまざまな態様にしたがう、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）に対する物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを割り振る例を図示するダイヤグラムである。
【図１０】［００２９］  図１０は、本開示のさまざまな態様にしたがう、例えば、ユーザ機器によって実行される例示的なプロセスを図示するダイヤグラムである。
【図１１】［００３０］  図１１は、本開示のさまざまな態様にしたがう、例えば、基地局によって実行される例示的なプロセスを図示するダイヤグラムである。
【図１２】［００３１］  図１２は、本開示のさまざまな態様にしたがう、例えば、ユーザ機器によって実行される例示的なプロセスを図示するダイヤグラムである。
【図１３】［００３２］  図１３は、本開示のさまざまな態様にしたがう、例えば、基地局によって実行される例示的なプロセスを図示するダイヤグラムである。
【詳細な説明】
【００２１】
［００３３］
添付図面を参照して、本開示のさまざまな態様を以下により詳細に説明する。しかしながら、この開示は多くの異なる形式で具現化されてもよく、この開示全体に渡たって提示されるいずれかの特定の構造や機能に限定されるものと解釈すべきでない。むしろ、本開示が、徹底して完全なものになるように、そして、本開示の範囲を当業者に十分に伝えるために、これらの態様を提供する。本発明の他の何らかの態様から独立して実現するかまたは本発明の他の何らかの態様と組み合わせて実現するかにかかわらず、本開示の範囲が、ここで開示する本開示の任意の態様をカバーするように意図されていることを、ここでの教示に少なくも部分的に基づいて、当業者は認識すべきである。例えば、ここで述べる任意の数の態様を使用して、装置を実現してもよく、または、方法を実施してもよい。さらに、ここで述べる本開示のさまざまな態様に加えて、または、ここで述べる開示のさまざまな態様以外の、他の構造を、機能性を、または、構造および機能性を使用して実施されるこのような装置または方法をカバーすることを、本開示の範囲は意図している。ここに開示されている本開示の任意の態様は、請求項の１つ以上の要素によって具現化してもよいことを理解すべきである。
【００２２】
［００３４］
電気通信システムのいくつかの態様が、さまざまな装置および技術を参照して提示されることになる。これら装置および技術は、以下の詳細な説明で説明され、添付の図面中で、さまざまなブロック、モジュール、コンポーネント、回路、ステップ、プロセス、アルゴリズム、および／または、これらに類するもの（集合的に「要素」として呼ばれる）により図示されている。これらの要素は、ハードウェア、ソフトウェア、または、それらの組み合わせを使用して実現してもよい。このような要素をハードウェアまたはソフトウェアとして実現するかは、システム全体に課せられている特定のアプリケーションおよび設計の制約に依存する。
【００２３】
［００３５］
３Ｇおよび／または４Ｇワイヤレステクノロジーに共通して関係付けられている専門用語を使用して、ここでは態様を説明しているが、本開示の態様は、ＮＲテクノロジーを含む、５Ｇおよびその後のもののような、他世代ベースの通信システムに適用することができることに留意すべきである。
【００２４】
［００３６］
図１は、本開示の態様を実施してもよいネットワーク１００を図示しているダイヤグラムである。ネットワーク１００は、ＬＴＥネットワーク、あるいは、５ＧまたはＮＲネットワークのような他の何らかのワイヤレスネットワークであってもよい。ワイヤレスネットワーク１００は、（ＢＳ１１０ａ、ＢＳ１１０ｂ、ＢＳ１１０ｃ、および、ＢＳ１１０ｄとして示されている）多数のＢＳ１１０と、他のネットワークエンティティとを含んでいてもよい。ＢＳは、ユーザ機器（ＵＥ）と通信するエンティティであり、基地局、ＮＲ  ＢＳ、ノードＢ、ｇＮＢ、５ＧノードＢ（ＮＢ）、アクセスポイント、送受信ポイント（ＴＲＰ）、および／または、これらに類するものとして呼ばれることもある。各ＢＳは、特定の地理的エリアのための通信カバレッジを提供していてもよい。３ＧＰＰにおいて、用語「セル」は、用語が使用される文脈に依存して、このカバレッジエリアを担当しているＢＳおよび／またはＢＳサブシステムのカバレッジエリアを指すことがある。
【００２５】
［００３７］
ＢＳは、マクロセル、ピコセル、フェムトセル、および／または、別のタイプのセルに対する通信カバレッジを提供してもよい。マクロセルは、比較的大きい地理的エリア（例えば、半径数キロメートル）をカバーし、サービス加入を有するＵＥによる無制限のアクセスを可能にしていてもよい。ピコセルは、比較的狭い地理的エリアをカバーし、サービス加入を有するＵＥによる無制限のアクセスを可能にしていてもよい。フェムトセルは、比較的小さい地理的エリア（例えば、家）をカバーし、フェムトセルとの関係を有するＵＥ（例えば、閉じられた加入者グループ（ＣＳＧ）中のＵＥ）による制限されたアクセスを可能にしていてもよい。マクロセルに対するＢＳは、マクロＢＳとして呼ばれることがある。ピコセルに対するＢＳは、ピコＢＳとして呼ばれることがある。フェムトセルに対するＢＳは、フェムトＢＳまたはホームＢＳとして呼ばれることがある。図１中で示されている例において、ＢＳ１１０ａは、マクロセル１０２ａのためのマクロＢＳであってもよく、ＢＳ１１０ｂは、ピコセル１０２ｂのためのピコＢＳであってもよく、ＢＳ１１０ｃは、フェムトセル１０２ｃのためのフェムトＢＳであってもよい。ＢＳは、１つ以上（例えば、３つ）のセルをサポートしてもよい。「ｅＮＢ」、「基地局」、「ＮＲ  ＢＳ」、「ｇＮＢ」、「ＴＲＰ」、「ＡＰ」、「ノードＢ」、「５Ｇ  ＮＢ」、および「セル」という用語は、ここでは交換可能に使用されているかもしれない。
【００２６】
［００３８］
いくつかの例において、セルは、必ずしも静的でなくてもよく、セルの地理的エリアは、移動体ＢＳのロケーションにしたがって移動してもよい。いくつかの態様では、直接的な物理接続、仮想ネットワーク、および／または、任意の適切な伝送ネットワークを使用するこれらに類するもののような、さまざまなタイプのバックホールインターフェースを通して、ＢＳは、アクセスネットワーク１００中の、１つの別のＢＳおよび／または１つ以上の他のＢＳあるいは（示していない）ネットワークノードとに相互接続されていてもよい。
【００２７】
［００３９］
ワイヤレスネットワーク１００はまた、中継局を含んでいてもよい。中継局は、アップストリーム局（例えば、ＢＳまたはＵＥ）からのデータの送信を受信でき、ダウンストリーム局（例えば、ＵＥまたはｅＢＳ）へのデータの送信を送ることができるエンティティである。中継局はまた、他のＵＥに対する送信を中継できるＵＥであってもよい。図１中で示されている例において、中継局１１０ｄは、ＢＳ１１０ａとＵＥ１２０ｄとの間の通信を促進するために、マクロＢＳ１１０ａおよびＵＥ１２０ｄと通信してもよい。中継局は、中継ＢＳ、中継基地局、中継器、および／または、これらに類するものとして呼ばれることもある。
【００２８】
［００４０］
ワイヤレスネットワーク１００は、異なるタイプのＢＳ、例えば、マクロＢＳ、ピコＢＳ、フェムトＢＳ、中継ＢＳ、および／または、これらに類するものを含む、ヘテロジニアスネットワークであってもよい。これらの異なるタイプのＢＳは、ワイヤレスネットワーク１００において、異なる送信電力レベル、異なるカバレッジエリア、および、干渉に対する異なる影響を有してもよい。例えば、マクロＢＳは、高い送信電力レベル（例えば、５から４０ワット）を有している一方で、ピコＢＳ、フェムトＢＳ、および、中継ＢＳは、より低い送信電力レベル（例えば、０．１から２ワット）を有していてもよい。
【００２９】
［００４１］
ネットワーク制御装置１３０は、ＢＳのセットに結合され、これらのＢＳに対する調整および制御を提供してもよい。ネットワーク制御装置１３０は、バックホールを介してＢＳと通信してもよい。ＢＳはまた、例えば、直接的に、あるいは、ワイヤレスまたはワイヤラインのバックホールを介して間接的に、互いに通信してもよい。
【００３０】
［００４２］
ＵＥ１２０（例えば、１２０ａ、１２０ｂ、１２０ｃ）は、ワイヤレスネットワーク１００全体を通して分散していてもよく、各ＵＥは、静的または移動性であってもよい。ＵＥは、アクセス端末、端末、移動局、加入者ユニット、局、および／または、これらに類するものとしても呼ばれることがある。ＵＥは、セルラ電話機（スマートフォン）、パーソナルデジタルアシスタント（ＰＤＡ）、ワイヤレスモデム、ワイヤレス通信デバイス、ハンドヘルドデバイス、ラップトップコンピュータ、コードレス電話機、ワイヤレスローカルループ（ＷＬＬ）局、タブレット、カメラ、ゲーミングデバイス、ネットブック、スマートブック、ウルトラブック、医療デバイスまたは医療機器、生体センサ／デバイス、ウェアラブルデバイス（スマートウォッチや、スマートクロージングや、スマートグラスや、スマートリストバンドや、スマートジュエリー（例えば、スマートリング、スマートブレスレット））、エンターテイメントデバイス（例えば、音楽またはビデオデバイス、あるいは、衛星ラジオ）、車両コンポーネントまたはセンサ、スマートメーター／センサ、産業製造機器、グローバルポジショニングシステムデバイス、あるいは、ワイヤレスまたはワイヤード媒体を介して通信するように構成されている他の何らかの適切なデバイスであってもよい。
【００３１】
［００４３］
いくつかのＵＥは、マシンタイプ通信（ＭＴＣ）、あるいは、進化型または拡張マシンタイプ通信（ｅＭＴＣ）ＵＥと見なしてもよい。ＭＴＣおよびｅＭＴＣ  ＵＥは、基地局、別のデバイス（例えば、遠隔デバイス）、または、他の何らかのエンティティと通信してもよい、例えば、ロボット、ドローン、遠隔デバイス、センサ、メーター、モニタ、ロケーションタグ、および／または、これらに類するものを含んでいる。ワイヤレスノードは、例えば、ワイヤードまたはワイヤレス通信リンクを介して、ネットワーク（例えば、インターネットまたはセルラネットワークのようなワイドエリアネットワーク）のための、あるいは、ネットワークへの接続性を提供してもよい。いくつかのＵＥをインターネットオブシングス（ＩｏＴ）デバイスと見なしてもよく、および／または、ＮＢ−ＩｏＴ（狭帯域インターネットオブシングス）デバイスとして実現してもよい。いくつかのＵＥは、顧客構内機器（ＣＰＥ）と見なしてもよい。ＵＥ１２０は、プロセッサコンポーネント、メモリコンポーネント、および／または、これらに類するもののような、ＵＥ１２０のコンポーネントを収容するハウジング内に含まれていてもよい。
【００３２】
［００４４］
一般的には、任意の数のワイヤレスネットワークが所定の地理的エリアに配備されていてもよい。各ワイヤレスネットワークは、特定のＲＡＴをサポートしてもよく、１つ以上の周波数で動作してもよい。ＲＡＴはまた、無線テクノロジー、エアインターフェース、および／または、これらに類するものとして呼ばれることがある。周波数はまた、搬送波、周波数チャネル、および／または、これらに類するものとして呼ばれることがある。各周波数は、異なるＲＡＴのワイヤレスネットワーク間の干渉を避けるために、所定の地理的エリアにおいて、単一のＲＡＴをサポートしてもよい。いくつかのケースでは、ＮＲまたは５Ｇ  ＲＡＴネットワークが配備されていてもよい。
【００３３】
［００４５］
いくつかの態様では、（例えば、ＵＥ１２０ａおよびＵＥ１２０ｅとして示されている）２つ以上のＵＥ１２０は、（例えば、互いに通信するための媒介として基地局１１０を使用せずに）１つ以上のサイドリンクチャネルを使用して、直接通信してもよい。例えば、ＵＥ１２０は、ピアツーピア（Ｐ２Ｐ）通信、デバイスツーデバイス（Ｄ２Ｄ）通信、ビークルツーエブリシング（Ｖ２Ｘ）プロトコル（例えば、これは、ビークルツービークル（Ｖ２Ｖ）プロトコル、ビークルツーインフラストラクチャ（Ｖ２Ｉ）プロトコル、および／または、これらに類するものを含んでいてもよい）、メッシュネットワーク、ならびに／あるいは、これらに類するものを使用して通信してもよい。このケースでは、ＵＥ１２０は、スケジューリング動作、リソース選択動作、および／または、基地局１１０によって実行されるものとしてここでの他の箇所で説明する他の動作を実行してもよい。
【００３４】
［００４６］
上記で示したように、図１は単なる例として提供されている。他の例は、図１に関して説明したものと異なっていてもよい。
【００３５】
［００４７］
図２は、基地局１１０およびＵＥ１２０の設計２００のブロックダイヤグラムを示し、これらは、図１における基地局のうちの１つ、および、ＵＥのうちの１つであってもよい。基地局１１０は、Ｔ本のアンテナ２３４ａないし２３４ｔを装備していてもよく、ＵＥ１２０は、Ｒ本のアンテナ２５２ａないし２５２ｒを装備していてもよく、一般的に、Ｔ≧１であり、Ｒ≧１である。
【００３６】
［００４８］
基地局１１０において、送信プロセッサ２２０は、１つ以上のＵＥのためにデータソース２１２からデータを受け取り、ＵＥから受け取ったチャネル品質インジケータ（ＣＱＩ）に少なくとも部分的に基づいて、各ＵＥに対して１つ以上の変調およびコーディングスキーム（ＭＣＳ）を選択し、ＵＥに対して選択したＭＣＳに少なくとも部分的に基づいて、各ＵＥに対するデータを処理（例えば、エンコードして変調）し、すべてのＵＥに対してデータシンボルを提供してもよい。送信プロセッサ２２０はまた、（例えば、半静的リソース区分情報（ＳＲＰＩ）および／またはこれらに類するもののための）システム情報と、制御情報（例えば、ＣＱＩ要求、許可、上位レイヤシグナリング、および／または、これらに類するもの）とを処理し、オーバーヘッドシンボルおよび制御シンボルを提供してもよい。送信プロセッサ２２０はまた、基準信号（例えば、セル特有基準信号（ＣＲＳ））と同期信号（例えば、１次同期信号（ＰＳＳ）および２次同期信号（ＳＳＳ））とに対する基準シンボルを発生させてもよい。送信（ＴＸ）複数入力複数出力（ＭＩＭＯ）プロセッサ２３０は、適用可能な場合に、データシンボル、制御シンボル、オーバーヘッドシンボル、および／または、基準シンボル上で、空間処理（例えば、プリコーディング）を実行してもよく、Ｔ個の変調器（ＭＯＤ）２３２ａないし２３２ｔにＴ個の出力シンボルストリームを提供してもよい。各変調器２３２は、（例えば、ＯＦＤＭおよび／またはこれらに類するもののために）それぞれの出力シンボルストリームを処理して、出力サンプルストリームを取得してもよい。各変調器２３２はさらに、出力サンプルストリームを処理（例えば、アナログに変換、増幅、フィルタリング、および、アップコンバート）して、ダウンリンク信号を取得する。変調器２３２ａないし２３２ｔからのＴ個のダウンリンク信号はそれぞれ、Ｔ本のアンテナ２３４ａないし２３４ｔを介して送信されてもよい。以下でより詳細に説明するさまざまな態様にしたがうと、追加の情報を伝えるために、ロケーションエンコーディングを用いて同期信号を発生させることができる。
【００３７】
［００４９］
ＵＥ１２０において、アンテナ２５２ａないし２５２ｒは、基地局１１０および／または他の基地局からダウンリンク信号を受信し、復調器（ＤＥＭＯＤ）２５４ａないし２５４ｒに受信した信号をそれぞれ提供してもよい。各復調器２５４は、受信した信号を調整（例えば、フィルタリング、増幅、ダウンコンバート、および、デジタル化）して、入力サンプルを取得してもよい。各復調器２５４はさらに、（例えば、ＯＦＤＭおよび／またはこれに類するものに対する）入力サンプルを処理して、受信シンボルを取得してもよい。ＭＩＭＯ検出器２５６は、Ｒ個のすべての復調器２５４ａないし２５４ｒから受信シンボルを取得し、適用可能な場合に、受信シンボル上でＭＩＭＯ検出を実行し、検出シンボルを提供してもよい。受信プロセッサ２５８は、検出シンボルを処理（例えば、復調およびデコード）し、ＵＥ１２０に対するデコードしたデータをデータシンク２６０に提供し、デコードした制御情報およびシステム情報を制御装置／プロセッサ２８０に提供してもよい。チャネルプロセッサは、基準信号受信電力（ＲＳＲＰ）、受信信号強度インジケータ（ＲＳＳＩ）、基準信号受信品質（ＲＳＲＱ）、チャネル品質インジケータ（ＣＱＩ）、および／または、これらに類するものを決定してもよい。
【００３８】
［００５０］
アップリンクにおいて、ＵＥ１２０では、送信プロセッサ２６４は、データソース２６２からデータを、そして、制御装置／プロセッサ２８０から（例えば、ＲＳＲＰ、ＲＳＳＩ、ＲＳＲＱ、ＣＱＩ、および／または、これらに類するものを含む報告のための）制御情報を受け取り、処理してもよい。送信プロセッサ２６４はまた、１つ以上の基準信号に対する基準シンボルを発生させてもよい。送信プロセッサ２６４からのシンボルは、適用可能な場合に、ＴＸ  ＭＩＭＯプロセッサ２６６によりプリコーディングされ、（例えば、ＤＦＴ−ｓ−ＯＦＤＭ、ＣＰ−ＯＦＤＭ、および／または、これらに類するもののために）変調器２５４ａないし２５４ｒによりさらに処理され、基地局１１０に送信されてもよい。基地局１１０において、ＵＥ１２０および他のＵＥからのアップリンク信号は、アンテナ２３４により受信され、復調器２３２により処理され、適用可能な場合に、ＭＩＭＯ検出器２３６により検出され、受信プロセッサ２３８によりさらに処理されて、ＵＥ１２０により送られ、デコードされた、データおよび制御情報が取得されてもよい。受信プロセッサ２３８は、デコードされたデータをデータシンク２３９に提供し、デコードされた制御情報を制御装置／プロセッサ２４０に提供してもよい。基地局１１０は、通信ユニット２４４を含み、通信ユニット２４４を介してネットワーク制御装置１３０と通信してもよい。ネットワーク制御装置１３０は、通信ユニット２９４と、制御装置／プロセッサ２９０と、メモリ２９２とを含んでいてもよい。
【００３９】
［００５１］
いくつかの態様では、ＵＥ１２０の１つ以上のコンポーネントが、ハウジング中に含まれていてもよい。基地局１１０の制御装置／プロセッサ２４０、ＵＥ１２０の制御装置／プロセッサ２８０、および／または、図２の他の何らかのコンポーネントは、ここでの他の箇所でより詳細に説明するように、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）に対する物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを割り振ることに関係付けられている１つ以上の技術を実行してもよい。例えば、基地局１１０の制御装置／プロセッサ２４０、ＵＥ１２０の制御装置／プロセッサ２８０、および／または、図２の他の何らかのコンポーネントは、例えば、図１０のプロセス１０００、図１１のプロセス１１００、図１２のプロセス１２００、図１３のプロセス１３００、および／または、ここで説明する他のプロセスの動作を実行または指示してもよい。メモリ２４２および２８２はそれぞれ、基地局１１０およびＵＥ１２０に対する、データおよびプログラムコードを記憶していてもよい。スケジューラ２４６は、ダウンリンクおよび／またはアップリンクでのデータ送信のために、ＵＥをスケジューリングしてもよい。
【００４０】
［００５２］
いくつかの態様では、ＵＥ１２０は、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているかまたは第２のタイプのサービスに関係付けられているかを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられている手段と、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、リソースの第１のセットを使用して、または、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、リソースの第２のセットを使用して、ＰＵＣＣＨ送信を送信する手段と、および／または、これらに類するものを含んでいてもよい。追加的にまたは代替的に、ＵＥ１２０は、第１のサービスタイプに関係付けられている送信のためのパラメータの第１のセットと、第２のサービスタイプに関係付けられている送信のためのパラメータの第２のセットとを含むＰＵＣＣＨコンフィギュレーションを受信する手段と、ＵＣＩを発生させる手段と、ＰＵＣＣＨコンフィギュレーションとメッセージのサービスタイプとにしたがって、ＵＣＩを含むメッセージを送信する手段と、および／または、これらに類するものを含んでいてもよい。いくつかの態様では、このような手段は、図２に関して説明したＵＥ１２０の１つ以上のコンポーネントを含んでいてもよい。
【００４１】
［００５３］
いくつかの態様では、基地局１１０は、第１のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１のコンフィギュレーションを決定する手段と、第２のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられている手段と、第１のコンフィギュレーションと第２のコンフィギュレーションとをＵＥに送信する手段と、および／または、これらに類するものとを含んでいてもよい。いくつかの態様では、このような手段は、図２に関して説明した基地局１１０の１つ以上のコンポーネントを含んでいてもよい。
【００４２】
［００５４］
上記で示したように、図２は例として提供されている。他の例は、図２に関して説明するものとは異なっていてもよい。
【００４３】
［００５５］
図３Ａは、電気通信システム（例えば、ＮＲ）におけるＦＤＤのための例示的なフレーム構造３００を示している。ダウンリンクおよびアップリンクのそれぞれに対する送信タイムラインが、無線フレーム（ときにはフレームとして呼ばれる）の単位に区分されている。各無線フレームは、予め定められている持続時間（例えば、１０ミリ秒（ｍｓ））を有していてもよく、（例えば、０〜Ｚ−１のインデックスを持つ）Ｚ（Ｚ≧１）個のサブフレームのセットに区分されていてもよい。各サブフレームは、予め定められた持続時間（例えば、１ｍｓ）を有していてもよく、スロットのセットを含んでいてもよい（例えば、サブフレーム毎に２ｍ個のスロットが図３Ａに示され、ｍは、０、１、２、３、４、および／または、これらに類するもののような送信に対するニューメロジーである）。各スロットは、Ｌ個のシンボル期間のセットを含んでいてもよい。例えば、各スロットは、（例えば、図３Ａ中に示すように）１４個のシンボル期間、７個のシンボル期間、および／または、別の数のシンボル期間を含んでいてもよい。サブフレームが２個のスロットを含むケース（例えば、ｍ＝１であるとき）では、サブフレームは２Ｌ個のシンボル期間を含んでいてもよく、各サブフレーム中の２Ｌ個のシンボル期間は、０〜２Ｌ−１のインデックスが割り当てられていてもよい。いくつかの態様では、ＦＤＤのためのスケジューリング単位は、フレームベース、サブフレームベース、スロットベース、シンボルベース、および／または、これらに類するものであってもよい。
【００４４】
［００５６］
いくつかの技術をフレーム、サブフレーム、スロット、および／または、これらに類するものに関してここで説明するが、これらの技術は、５Ｇ  ＮＲにおいて、「フレーム」、「サブフレーム」、「スロット」、および／または、これらに類するもの以外の用語を使用して呼ばれることがある、他のタイプのワイヤレス通信構造に等しく適用してもよい。いくつかの態様では、ワイヤレス通信構造は、ワイヤレス通信標準規格および／またはプロトコルによって定義される周期的時間限定通信単位を指していてもよい。追加的にまたは代替的に、図３Ａ中に示すもの以外のワイヤレス通信構造の異なるコンフィギュレーションを使用してもよい。
【００４５】
［００５７］
ある電気通信（例えば、ＮＲ）では、基地局は同期信号を送信するかもしれない。例えば、基地局は、基地局によってサポートされる各セルに対して、ダウンリンク上で、１次同期信号（ＰＳＳ）、２次同期信号（ＳＳＳ）、および／または、これらに類するものを送信するかもしれない。ＰＳＳおよびＳＳＳは、セルのサーチおよび捕捉のために、ＵＥにより使用してもよい。例えば、ＰＳＳは、シンボルタイミングを決定するためにＵＥによって使用されてもよく、ＳＳＳは、基地局に関係付けられている物理セル識別子と、フレームタイミングとを決定するためにＵＥによって使用されてもよい。基地局はまた、物理ブロードキャストチャネル（ＰＢＣＨ）を送信してもよい。ＰＢＣＨは、ＵＥによる初期アクセスをサポートするシステム情報のような、いくつかのシステム情報を搬送してもよい。
【００４６】
［００５８］
いくつかの態様では、基地局は、図３Ｂに関して以下で説明するように、複数の同期通信（例えば、ＳＳブロック）を含む同期通信階層（例えば、同期信号（ＳＳ）階層）にしたがって、ＰＳＳ、ＳＳＳ、および／または、ＰＢＣＨを送信してもよい。
【００４７】
［００５９］
図３Ｂは、同期通信階層の例である例示的なＳＳ階層を概念的に図示するブロックダイヤグラムである。図３Ｂ中で示されているように、ＳＳ階層は、複数のＳＳバースト（ＳＳバースト０〜ＳＳバーストＢ−１として識別され、Ｂは、基地局によって送信されるかもしれないＳＳバーストの反復の最大数である）を含んでいてもよい、ＳＳバーストセットを含んでいてもよい。さらに示されているように、各ＳＳバーストは、（ＳＳブロック０からＳＳブロック（ｂ最大＿ＳＳ−１）として識別される）１つ以上のＳＳブロックを含んでいてもよく、ｂ最大＿ＳＳ−１は、ＳＳバーストによって搬送できるＳＳブロックの最大数である。いくつかの態様では、異なるＳＳブロックは、異なってビーム形成してもよい。ＳＳバーストセットは、図３Ｂ中で示されているように、Ｘミリ秒毎のよう、ワイヤレスノードによって周期的に送信されてもよい。いくつかの態様では、ＳＳバーストセットは、図３Ｂ中でＹミリ秒として示されている、固定または動的長を有していてもよい。
【００４８】
［００６０］
図３Ｂ中で示されているＳＳバーストセットは、同期通信セットの例であり、ここで説明する技術に関連して他の同期通信セットを使用してもよい。さらに、図３Ｂ中で示されているＳＳブロックは、同期通信の例であり、ここで説明する技術に関連して、他の同期通信を使用してもよい。
【００４９】
［００６１］
いくつかの態様では、ＳＳブロックは、ＰＳＳ、ＳＳＳ、ＰＢＣＨ、ならびに／あるいは、他の同期信号（例えば、３次同期信号（ＴＳＳ））および／または同期チャネルを搬送するリソースを含んでいる。いくつかの態様では、複数のＳＳブロックがＳＳバースト中に含まれ、ＰＳＳ、ＳＳＳ、および／または、ＰＢＣＨは、ＳＳバーストの各ＳＳブロックに渡って同じであってもよい。いくつかの態様では、単一のＳＳブロックがＳＳバースト中に含まれていてもよい。いくつかの態様では、ＳＳブロックは、長さが少なくとも４つのシンボル期間であってもよく、各シンボルは、（例えば、１つのシンボルを占有している）ＰＳＳ、（例えば、１つのシンボルを占有している）ＳＳＳ、および／または、（例えば、２つのシンボルを占有している）ＰＢＣＨのうちの１つ以上を搬送する。
【００５０】
［００６２］
いくつかの態様では、ＳＳブロックのシンボルは、図３Ｂ中で示されているように連続的である。いくつかの態様では、ＳＳブロックのシンボルは不連続である。同様に、いくつかの態様では、ＳＳバーストの１つ以上のＳＳブロックは、１つ以上のスロットの間に、連続する無線リソース（例えば、連続するシンボル期間）中で送信してもよい。追加的にまたは代替的に、ＳＳバーストの１つ以上のＳＳブロックは、不連続無線リソース中で送信してもよい。
【００５１】
［００６３］
いくつかの態様では、ＳＳバーストはバースト期間を有していてもよく、それによって、ＳＳバーストのＳＳブロックは、バースト期間にしたがって、基地局によって送信される。言い換えれば、ＳＳブロックは、各ＳＳバーストの間に繰り返されてもよい。いくつかの態様では、ＳＳバーストセットは、バーストセット周期を有していてもよく、それによって、ＳＳバーストセットのＳＳバーストは、固定バーストセット周期にしたがって、基地局によって送信される。言い換えれば、ＳＳバーストは、各ＳＳバーストセットの間に繰り返されてもよい。
【００５２】
［００６４］
基地局は、あるスロットにおいて、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）上でシステム情報ブロック（ＳＩＢ）のようなシステム情報を送信してもよい。基地局は、スロットのＣ個のシンボル期間中に、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）上で制御情報／データを送信してもよく、Ｃは各スロットに対して構成可能であってもよい。基地局は、各スロットの残りのシンボル期間中に、ＰＤＳＣＨ上でトラフィックデータおよび／または他のデータを送信してもよい。
【００５３】
［００６５］
上記で示したように、図３Ａおよび図３Ｂは例として提供されている。他の例は、図３Ａおよび３Ｂに関して説明するものとは異なっていてもよい。
【００５４】
［００６６］
図４は、ノーマルサイクリックプリフィックスを有する例示的なスロットフォーマット４１０を示している。利用可能な時間周波数リソースは、リソースブロックに区分してもよい。各リソースブロックは、１つのスロット中で副搬送波のセット（例えば、１２個の副搬送波）をカバーしていてもよく、多数のリソース要素を含んでいてもよい。各リソース要素は、（例えば、時間的に）１つのシンボル期間中に１つの副搬送波をカバーしてもよく、１つの変調シンボルを送るために使用してもよく、変調シンボルは、実数値であっても、または、複素数値であってもよい。
【００５５】
［００６７］
ある電気通信システム（例えば、ＮＲ）中のＦＤＤに対するダウンリンクおよびアップリンクのそれぞれに対して、インターレース構造を使用してもよい。例えば、０ないしＱ−１のインデックスを有するＱ個のインターレースを規定してもよく、Ｑは、４、６、８、１０、または、他の何らかの値と等しくてもよい。各インターレースは、Ｑ個のフレームだけ間隔を空けて離されているスロットを含んでいてもよい。特に、インターレースｑは、スロットｑ、ｑ＋Ｑ、ｑ＋２Ｑ等を含んでいてもよく、ｑ∈｛０，．．．，Ｑ−１｝である。
【００５６】
［００６８］
ＵＥは、複数のＢＳのカバレッジ内に位置付けられていてもよい。ＵＥを担当するように、これらのＢＳのうちの１つを選択してもよい。受信信号強度、受信信号品質、パス損失、および／または、これらに類するもののような、さまざまな基準に少なくとも部分的に基づいて、担当ＢＳを選択してもよい。受信信号品質は、信号対雑音および干渉比（ＳＩＮＲ）、または、基準信号受信品質（ＲＳＲＱ）、または、他の何らかのメトリックによって定量化してもよい。ＵＥは、１つ以上の干渉ＢＳからの高い干渉をＵＥが観測するかもしれない、支配的干渉シナリオにおいて、動作するかもしれない。
【００５７】
［００６９］
ここで説明する例の態様はＮＲまたは５Ｇテクノロジーに関係付けられているかもしれないが、本開示の態様は、他のワイヤレス通信システムに適用可能であってもよい。新たな無線（ＮＲ）は、（例えば、直交周波数分割多元接続（ＯＦＤＭＡ）ベースのエアインターフェース以外の）新たなエアインターフェースに、または、（例えば、インターネットプロトコル（ＩＰ）以外の）固定された伝送レイヤにしたがって動作するように構成されている無線を指していてもよい。態様では、ＮＲは、アップリンク上で、ＣＰを有するＯＦＤＭ（ここではサイクリックプレフィックスＯＦＤＭまたはＣＰ−ＯＦＤＭとして呼ばれる）および／またはＳＣ−ＦＤＭを利用してもよく、ダウンリンク上で、ＣＰ−ＯＦＤＭを利用してもよく、ＴＤＤを使用する半二重動作のためのサポートを含んでいてもよい。態様では、ＮＲは、例えば、アップリンク上で、ＣＰを有するＯＦＤＭ（ここではＣＰ−ＯＦＤＭとして呼ばれる）および／または離散フーリエ変換拡散直交周波数分割多重（ＤＦＴ−ｓ−ＯＦＤＭ）を利用してもよく、ダウンリンク上で、ＣＰ−ＯＦＤＭを利用してもよく、ＴＤＤを使用する半二重動作のためのサポートを含んでいてもよい。ＮＲは、広帯域幅（例えば、８０メガヘルツ（ＭＨｚ）以上）をターゲットとする拡張移動体ブロードバンド（ｅＭＢＢ）サービス、高搬送波周波数（例えば、６０ギガヘルツ（ＧＨｚ））をターゲットとするミリ波（ｍｍＷ）、非下位互換性ＭＴＣ技術をターゲットとする大量のＭＴＣ（ｍＭＴＣ）、および／または、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）サービスをターゲットとするミッションクリティカルを含んでいてもよい。
【００５８】
［００７０］
いくつかの態様では、１００ＭＨｚの単一のコンポーネント搬送波帯域幅をサポートしてもよい。ＮＲリソースブロックは、０．１ミリ秒（ｍｓ）持続時間に渡り、６０または１２０キロヘルツ（ｋＨｚ）の副搬送波帯域幅を有する１２個の副搬送波に及んでいてもよい。各無線フレームは、４０個のスロットを含んでいてもよく、１０ｍｓの長さを有していてもよい。結果として、各スロットは、０．２ｍｓの長さを有していてもよい。各スロットは、データ送信のためのリンク方向（例えば、ＤＬまたはＵＬ）を示してもよく、各スロットに対するリンク方向は、動的に切り替えてもよい。各スロットは、ＤＬ／ＵＬデータとともにＤＬ／ＵＬ制御データを含んでいてもよい。
【００５９】
［００７１］
ビーム形成をサポートしてもよく、ビーム方向を動的に構成してもよい。プリコーディングを有するＭＩＭＯ送信もサポートしてもよい。ＤＬ中のＭＩＭＯコンフィギュレーションは、８本までの送信アンテナをサポートしてもよく、マルチレイヤＤＬ送信は、８ストリームまでであり、ＵＥ毎に２ストリームまでである。ＵＥ毎に２ストリームまでのマルチレイヤ送信をサポートしてもよい。複数のセルのアグリゲーションを、８個までの担当セルによりサポートしてもよい。代替的に、ＮＲは、ＯＦＤＭベースのインターフェース以外の、異なるエアインターフェースをサポートしてもよい。ＮＲネットワークは、中央ユニットまたは分散ユニットのようなエンティティを含んでいてもよい。
【００６０】
［００７２］
上記で示したように、図４は例として提供されている。他の例は、図４に関して説明したものと異なっていてもよい。
【００６１】
［００７３］
図５は、ＤＬ中心スロットまたはワイヤレス通信構造の例を示しているダイヤグラム５００である。ＤＬ中心スロットは、制御部分５０２を含んでいてもよい。制御部分５０２は、ＤＬ中心スロットの最初または開始部分中に存在していてもよい。制御部分５０２は、ＤＬ中心スロットのさまざまな部分に対応する、さまざまなスケジューリング情報および／または制御情報を含んでいてもよい。いくつかのコンフィギュレーションにおいて、制御部分５０２は、図５で示されているように、物理ＤＬ制御チャネル（ＰＤＣＣＨ）であってもよい。いくつかの態様では、制御部分５０２は、レガシーＰＤＣＣＨ情報、短縮ＰＤＣＣＨ（ｓＰＤＣＣＨ）情報、（例えば、物理制御フォーマットインジケータチャネル（ＰＣＦＩＣＨ）上で搬送される）制御フォーマットインジケータ（ＣＦＩ）値、１つ以上の許可（例えば、ダウンリンク許可、アップリンク許可、および／または、これらに類するもの）、ならびに／あるいは、これらに類するものを含んでいてもよい。
【００６２】
［００７４］
ＤＬ中心スロットは、ＤＬデータ部分５０４も含んでいてもよい。ＤＬデータ部分５０４は、ときには、ＤＬ中心スロットのペイロードとして呼ばれることがある。ＤＬデータ部分５０４は、スケジューリングエンティティ（例えば、ＵＥまたはＢＳ）から下位エンティティ（例えば、ＵＥ）にＤＬデータを通信するために利用される通信リソースを含んでいてもよい。いくつかのコンフィギュレーションでは、ＤＬデータ部分５０４は、物理ＤＬ共有チャネル（ＰＤＳＣＨ）であってもよい。
【００６３】
［００７５］
ＤＬ中心スロットは、ＵＬショートバースト部分５０６も含んでいてもよい。ＵＬショートバースト部分５０６は、ＵＬバースト、ＵＬバースト部分、共通ＵＬバースト、ショートバースト、ＵＬショートバースト、共通ＵＬショートバースト、共通ＵＬショートバースト部分、および／または、他のさまざまな適切な用語として呼ばれることがある。いくつかの態様では、ＵＬショートバースト部分５０６は、１つ以上の基準信号を含んでいてもよい。追加的にまたは代替的に、ＵＬショートバースト部分５０６は、ＤＬ中心スロットの他のさまざまな部分に対応するフィードバック情報を含んでいてもよい。例えば、ＵＬショートバースト部分５０６は、制御部分５０２および／またはデータ部分５０４に対応するフィードバック情報を含んでいてもよい。ＵＬショートバースト部分５０６中に含まれているかもしれない情報の非限定的な例は、ＡＣＫ信号（例えば、ＰＵＣＣＨ  ＡＣＫ、ＰＵＳＣＨ  ＡＣＫ、即時ＡＣＫ）、ＮＡＣＫ信号（例えば、ＰＵＣＣＨ  ＮＡＣＫ、ＰＵＳＣＨ  ＮＡＣＫ、即時ＮＡＣＫ）、スケジューリング要求（ＳＲ）、バッファステータス報告（ＢＳＲ）、ＨＡＲＱインジケータ、チャネル状態表示（ＣＳＩ）、チャネル品質インジケータ（ＣＱＩ）、サウンディング基準信号（ＳＲＳ）、復調基準信号（ＤＭＲＳ）、ＰＵＳＣＨデータ、および／または、他のさまざまな適切なタイプの情報を含んでいる。ＵＬショートバースト部分５０６は、ランダムアクセスチャネル（ＲＡＣＨ）手順に適する情報、スケジューリング要求、および、他のさまざまな適切なタイプの情報のような、追加のまたは代替の情報を含んでいてもよい。
【００６４】
［００７６］
図５中に図示されているように、ＤＬデータ部分５０４の終端は、ＵＬショートバースト部分５０６の開始から時間的に分離していてもよい。この時間分離は、ときには、ギャップ、ガード期間、ガードインターバル、および／または、他のさまざまな適切な用語として呼ばれることがある。この分離は、ＤＬ通信（例えば、下位エンティティ（例えば、ＵＥ）による受信動作）からＵＬ通信（例えば、下位エンティティ（例えば、ＵＥ）による送信）への切り替えのための時間を提供する。前述のものは、ＤＬ中心ワイヤレス通信構造の単なる一例に過ぎず、同様の特徴を有する代替構造が、ここで説明した態様から必ずしも逸脱することなく存在していてもよい。
【００６５】
［００７７］
上記で示したように、図５は単なる例として提供されている。他の例は、図５に関して説明したものと異なっていてもよい。
【００６６】
［００７８］
図６は、ＵＬ中心スロットまたはワイヤレス通信構造の例を示しているダイヤグラム６００である。ＵＬ中心スロットは、制御部分６０２を含んでいてもよい。制御部分６０２は、ＵＬ中心スロットの最初または開始部分に存在していてもよい。図６中の制御部分６０２は、図５を参照して上述した制御部分５０２と同様であってもよい。ＵＬ中心スロットは、ＵＬロングバースト部分６０４も含んでいてもよい。ＵＬロングバースト６０４は、ときには、ＵＬ中心スロットのペイロードとして呼ばれることがある。ＵＬ部分は、下位エンティティ（例えば、ＵＥ）からスケジューリングエンティティ（例えば、ＵＥまたはＢＳ）にＵＬデータを通信するために利用される通信リソースを指していてもよい。いくつかのコンフィギュレーションにおいて、制御部分６０２は、物理ＤＬ制御チャネル（ＰＤＣＣＨ）であってもよい。
【００６７】
［００７９］
図６に図示されているように、制御部分６０２の終端は、ＵＬロングバースト６０４の開始から時間的に分離していてもよい。この時間分離は、ときには、ギャップ、ガード期間、ガードインターバル、および／または、他のさまざまな適切な用語として呼ばれることがある。この分離は、ＤＬ通信（例えば、スケジューリングエンティティによる受信動作）からＵＬ通信（例えば、スケジューリングエンティティによる送信）への切り替えのための時間を提供する。
【００６８】
［００８０］
ＵＬ中心スロットは、ＵＬショートバースト部分６０６も含んでいてもよい。図６中のＵＬショートバースト部分６０６は、図５を参照して上述したＵＬショートバースト部分５０６と同様であってもよく、図５に関連して上述した情報のうちのいずれかを含んでいてもよい。前述のものは、ＵＬ中心ワイヤレス通信構造の単なる一例に過ぎず、同様の特徴を有する代替構造が、ここで説明した態様から必ずしも逸脱することなく存在していてもよい。
【００６９】
［００８１］
いくつかの状況では、２つ以上の下位エンティティ（例えば、ＵＥ）が、サイドリンク信号を使用して、互いに通信してもよい。このようなサイドリンク通信の現実世界のアプリケーションは、公衆安全、近接サービス、ＵＥ対ネットワーク中継、ビークルツービークル（Ｖ２Ｖ）通信、インターネットオブエブリシング（ＩｏＥ）通信、ＩｏＴ通信、ミッションクリティカルメッシュ、および／または、他のさまざまな適切なアプリケーションを含んでいてもよい。一般的に、たとえ、スケジューリングエンティティがスケジューリングおよび／または制御目的で利用されるかもしれないとしても、サイドリンク信号は、スケジューリングエンティティ（例えば、ＵＥまたはＢＳ）を通してその通信を中継することなく、１つの下位エンティティ（例えば、ＵＥ１）から別の下位エンティティ（例えば、ＵＥ２）に通信される信号を指していてもよい。いくつかの態様では、サイドリンク信号は、（典型的にライセンスされていないスペクトル使用するワイヤレスローカルエリアネットワークとは異なり）ライセンスされているスペクトルを使用して通信されてもよい。
【００７０】
［００８２］
１つの例では、フレームのようなワイヤレス通信構造は、ＵＬ中心スロットとＤＬ中心スロットの両方を含んでいてもよい。この例では、フレーム中のＤＬ中心スロットに対するＵＬ中心スロットの比は、送信されるＵＬデータの量とＤＬデータの量とに少なくとも部分的に基づいて、動的に調整してもよい。例えば、より多くのＵＬデータがある場合、ＤＬ中心スロットに対するＵＬ中心スロットの比を増加させてもよい。逆に、より多くのＤＬデータがある場合、ＤＬ中心スロットに対するＵＬ中心スロットの比を減少させてもよい。
【００７１】
［００８３］
上記で示したように、図６は単なる例として提供されている。他の例は、図６に関して説明したものと異なっていてもよい。
【００７２】
［００８４］
いくつかの事例では、ＢＳおよびＵＥは、複数のタイプのサービスを介して互いに通信してもよい。例えば、ＢＳとＵＥとの間の第１の通信は、拡張移動体ブロードバンド（ｅＭＢＢ）サービスを使用してもよく、ＢＳとＵＥとの間の第２の通信は、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）サービスを使用してもよい。このようなケースでは、異なるタイプのサービスは、異なるレイテンシおよび／または信頼性要件のような、異なる特性および／または要件を有しているかもしれない（例えば、ＵＲＬＬＣサービスは、ｅＭＢＢよりもより高い信頼性およびより低いレイテンシ要件を有する）。しかしながら、いくつかのケースでは、通信のために使用されているサービスのタイプ（例えば、ｅＭＢＢまたはＵＲＬＬＣ）にかかわらず、ＰＵＣＣＨリソースの同じセットが、ＢＳとＵＥとの間の通信のために割り振られるかもしれない。したがって、長いＰＵＣＣＨリソース（例えば、１４シンボル）は、長いＰＵＣＣＨリソースに関係付けられているかなり高いレイテンシのために、ＵＲＬＬＣに有用でないかもしれない。一方、ｅＭＢＢサービスに必要ではない低いレイテンシ要件を満たすために、より頻繁に（例えば、２シンボル毎に）ＵＲＬＬＣ  ＰＵＣＣＨリソースを構成する必要があるかもしれない。
【００７３】
［００８５］
さらに、いくつかの事例では、ダウンリンク制御情報（ＤＣＩ）は、使用されているサービスのタイプに依存して、異なっていてもよい。例えば、ＤＣＩは、ＵＲＬＬＣに対するＤＣＩ中に含まれるシグナリング方法とは異なる、ｅＭＢＢに対するＰＵＣＣＨリソース割り振りのためのシグナリング方法を含んでいてもよい。したがって、ＰＵＣＣＨ送信のために使用されることになるサービスのタイプにかかわらずＰＵＣＣＨリソースが割り振られるとき、ＵＥは、特定のＰＵＣＣＨ送信のために、リソースのうちのどれが使用されることになるかを不適切に解釈するかもしれない。
【００７４】
［００８６］
さらに、いくつかの事例では、２つのＰＵＣＣＨチャネル（例えば、ｅＭＢＢに対して１つおよびＵＲＬＬＣに対して１つ）が時間的にオーバーラップしているとき、ＵＥは、両方のチャネルのために（例えば、ｅＭＢＢとＵＲＬＬＣの両方のために）アップリンク制御情報（ＵＣＩ）ビットを多重化し、単一のチャネル中でＵＣＩを送信する必要があるかもしれない。しかしながら、多重化されたＵＣＩは、ＵＲＬＬＣパケットまたはｅＭＢＢパケットが適切に受信されたか否かを示さないことから、これは信頼性に悪影響を及ぼすことがある。多重化されたＵＣＩは、パケットに関係付けられているサービスのタイプにかかわらず、単に、受信したパケットの総数を示している。さらに、いくつかの事例では、ＵＥは、異なるタイプのサービスのために異なるタイミングを使用するかもしれない。例えば、ｅＭＢＢ肯定応答または否定応答（ＡＣＫ／ＮＡＣＫ）に対する応答タイミングは、ＵＲＬＬＣ  ＡＣＫ／ＮＡＣＫに対する応答タイミングとは異なっているかもしれない。いくつかのケースでは、ＡＣＫ／ＮＡＣＫは、ハイブリッド自動再送要求肯定応答（ＨＡＲＱ−ＡＣＫ）として呼ばれることがある。同様に、ＡＣＫ／ＮＡＣＫフィードバックは、ＨＡＲＱ−ＡＣＫフィードバックとして呼ばれることがあり、ＡＣＫ／ＮＡＣＫ情報は、ＨＡＲＱ−ＡＣＫ情報、および／または、これらに類するものとして呼ばれることがある。
【００７５】
［００８７］
ここで説明するいくつかの態様は、ＰＵＣＣＨ送信のために使用されることになるサービスのタイプに関連して、ＰＵＣＣＨリソースに対するリソース割り振りを提供する。例えば、ＵＥは、ＰＵＣＣＨ送信が第１のタイプのサービス（例えば、ｅＭＢＢ）に関係付けられているとき、リソースの第１のセットを使用して、または、ＰＵＣＣＨ送信が第２のタイプのサービス（例えば、ＵＲＬＬＣ）に関係付けられているとき、リソースの第２のセットを使用して、ＰＵＣＣＨ送信を送るかもしれない。さらに、ここで説明するいくつかの態様は、適切なリソースが確実に監視および／または使用されるようにするために、ＰＵＣＣＨ送信に関係付けられているサービスのタイプに少なくとも部分的に基づいて、ＤＣＩ中のシグナリングからＰＵＣＣＨ送信に対するリソースを識別してもよい。ここで説明するいくつかの態様は、ＰＵＣＣＨ送信に関係付けられているサービスのタイプに少なくとも部分的に基づいて、別個のＰＵＣＣＨリソースを使用して、ＵＣＩを有するＰＵＣＣＨ送信を送信してもよい。例えば、ｅＭＢＢサービスに関係付けられているＰＵＣＣＨ送信のために実行されるダウンリンク割り当てインデックス（ＤＡＩ）動作は、ＵＲＬＬＣサービスに関係付けられているＰＵＣＣＨ送信のために実行されるＤＡＩ動作とは異なっていてもよい。
【００７６】
［００８８］
したがって、ここで提供されているいくつかの例は、サービスのタイプに少なくとも部分的に基づいて、異なるＰＵＣＣＨリソースがＰＵＣＣＨ送信のために動的に割り振られるかまたは使用されることを可能にするかもしれない。例えば、ＰＵＣＣＨ送信に関係付けられているサービスの要件に依存して、ＰＵＣＣＨ送信のために、ＰＵＣＣＨリソースの比較的少ないセットを、および／または、リソースの各セット中で比較的少ないリソースを使用することによって、ＰＵＣＣＨ送信は、別のタイプよりも、サービスの１つのタイプに対してより高い信頼性および／またはより低いレイテンシを達成するかもしれない。追加的にまたは代替的に、このような高い信頼性または低いレイテンシを必要としないかもしれないサービスの別のタイプは、シグナリング帯域幅を節約し、ＰＵＣＣＨリソースのより多くの数のセットを、ならびに／あるいは、リソースのセット内のより多くの数をまたはより多くのリソースを使用して構成することができる。したがって、ここでのいくつかの例は、ＰＵＣＣＨ送信に関係付けられているサービスに依存して、必要に応じて、信頼性を高め、および／または、レイテンシを低くしながら、ネットワークリソースを節約するかもしれない。
【００７７】
［００８９］
図７は、本開示のさまざまな態様にしたがう、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）に対して物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを割り振る例７００を図示しているダイヤグラムである。例７００において、ＢＳ１１０およびＵＥ１２０は、互いに複数の送信（または、通信）を交換する。いくつかの事例では、送信は、第１のタイプのサービスに関係付けられてもよく、いくつかの事例では、送信は、第２のタイプのサービスに関係付けられてもよい。以下の例で説明するように、第１のタイプのサービスはｅＭＢＢサービスであってもよく、第２のタイプのサービスはＵＲＬＬＣサービスであってもよいが、第１および第２のタイプのサービスは異なるサービスであってもよい。例えば、第２のタイプのサービスは、第１のタイプのサービスよりもより低いレイテンシ要件を有していてもよく、第１のタイプのサービスよりもより高い信頼性要件を有していてもよく、第１のタイプのサービスよりもより高い優先度に関係付けられていてもよく、第１のタイプのサービスよりもより速い処理時間（例えば、より低い処理タイムライン）に関係付けられていてもよく、および／または、これらに類するものであってもよい。
【００７８】
［００９０］
例７００では、ある送信が、異なるパラメータにしたがって動作する、異なるタイプのサービスに関係しているかもしれない（例えば、ＵＲＬＬＣは、ｅＭＢＢよりもより高い信頼性および／またはより低いレイテンシを提供する）ので、ＢＳ１１０およびＵＥ１２０は、送信に関係付けられているサービスのタイプに少なくとも部分的に基づいて、ＰＵＣＣＨリソースを構成および／または使用してもよい。
【００７９】
［００９１］
図７中で参照番号７１０によって示されているように、ＢＳ１１０は、ＵＥ１２０とのＰＵＣＣＨ送信のために使用されるかもしれないサービスのタイプに少なくとも部分的に基づいて、ＰＵＣＣＨ送信に対するリソースコンフィギュレーションを決定する。例えば、ＢＳ１１０は、ＰＵＣＣＨ送信がｅＭＢＢに関係付けられているとき、ＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１のコンフィギュレーションを、ＰＵＣＣＨ送信がＵＲＬＬＣに関係付けられているとき、ＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定してもよい。
【００８０】
［００９２］
ＰＵＣＣＨリソースのコンフィギュレーションは、ＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソース（例えば、リソースブロック）のセットの数、リソースのセット中に含まれることになるリソースの数、および／または、これらに類するものを識別してもよい。ＰＵＣＣＨリソースは、リソースブロックのセットを含んでいてもよい。いくつかのケースでは、ＰＵＣＣＨリソースの各セットは、アップリンク制御情報（ＵＣＩ）ペイロード範囲に関係付けられる。例えば、ＰＵＣＣＨリソースの第１のセットは、１ビットまたは２ビットのサイズを有するＵＣＩを送信するように構成されていてもよく、ＰＵＣＣＨリソースの第２のセットは、３ビットからＸ１ビットのサイズを有するＵＣＩを送信するように構成されていてもよく、ＰＵＣＣＨリソースの第３のセットは、（Ｘ１＋１）ビットからＸ２ビットのサイズを有するＵＣＩを送信するように構成されていてもよく、以下同様である。ＵＲＬＬＣに対して、高信頼性を達成することを支援するために、ＵＣＩのペイロードサイズは、典型的に小さい。したがって、（例えば、４つのセットを使用するかもしれない）ｅＭＢＢと比較して、ＰＵＣＣＨリソースのより少ないセット（例えば、１つまたは２つのセット）が、ＵＲＬＬＣのために必要とされるかもしれない。したがって、ｅＭＢＢサービスを使用するＰＵＣＣＨ送信に対する第１のコンフィギュレーションは、ＵＲＬＬＣサービスを使用するＰＵＣＣＨ送信に対する第２のコンフィギュレーションよりも多くのリソースのセットを含んでいてもよい。
【００８１】
［００９３］
いくつかのケースでは、ＵＲＬＬＣ  ＰＵＣＣＨリソースは、ｅＭＢＢ  ＰＵＣＣＨリソースよりも細かい粒度で構成されていてもよい。例えば、ｅＭＢＢ  ＰＵＣＣＨリソースコンフィギュレーションは、スロットの長さ（例えば、１４シンボル）を有するＰＵＣＣＨリソースを構成してもよいが、ＵＲＬＬＣ  ＰＵＣＣＨリソースコンフィギュレーションは、サブスロット（または、ミニスロット）の長さ（例えば、１４シンボル未満）を有するＰＵＣＣＨリソースを構成してもよい。結果として、ｅＭＢＢ  ＰＵＣＣＨリソースコンフィギュレーションは、短い（例えば、１または２シンボル）および長い（例えば、４〜１４シンボル）ＰＵＣＣＨリソースの両方を構成する必要があるかもしれないが、ＵＲＬＬＣ  ＰＵＣＣＨリソースコンフィギュレーションは、サブスロット（または、ミニスロット）長よりも短いＰＵＣＣＨリソースだけを構成する必要があるかもしれない。したがって、ＵＲＬＬＣに対する各ＰＵＣＣＨリソースセットでは、ｅＭＢＢと比較して、より少ないリソースが必要とされる。したがって、ＵＲＬＬＣサービスに関係付けられているＰＵＣＣＨ送信に対して、リソースの各セットは、ｅＭＢＢサービスに関係付けられているＰＵＣＣＨ送信よりも少ないリソースを含んでいてもよい。このケースでは、ｅＭＢＢサービスは、比較的長いＰＵＣＣＨ（１４シンボル）を利用するかもしれないが、これは、低いレイテンシを達成するためにより頻繁に（例えば、２シンボル毎に）構成されることになる、ＵＲＬＬＣサービスに対して高すぎるレイテンシを引き起こすかもしれない。ｅＭＢＢサービスに対して、そのように頻繁に構成する必要はないかもしれず、そのようにすることは、シグナリング帯域幅および／またはネットワークリソースの浪費になるかもしれない。したがって、ｅＭＢＢサービスは、ｅＭＢＢのために構成されているＰＵＣＣＨ送信に対するリソースのセットおよびサイズを使用してもよく、ＵＲＬＬＣサービスは、ＵＲＬＬＣのために構成されているＰＵＣＣＨ送信に対するリソースのセットまたはサイズを使用してもよい。
【００８２】
［００９４］
いくつかのケースでは、ＰＵＣＣＨリソースを使用して、ダウンリンク半永続的スケジューリング（ＳＰＳ）送信に関係付けられているＨＡＲＱ−ＡＣＫフィードバックを送信してもよい。ダウンリンクＳＰＳに対するＨＡＲＱ−ＡＣＫフィードバックを送信するためのＰＵＣＣＨリソースは、ダウンリンクＳＰＳコンフィギュレーションの一部として、無線リソース制御（ＲＲＣ）メッセージ中で構成されていてもよい。例えば、周期的なＰＵＣＣＨリソースがＲＲＣメッセージ中で構成されていてもよく、そのＰＵＣＣＨリソースを使用して、ダウンリンクＳＰＳ送信のために、ＰＵＣＣＨを周期的に送信してもよい。ダウンリンクＳＰＳに対するＰＵＣＣＨリソースコンフィギュレーションは、ＨＡＲＱ−ＡＣＫフィードバックのために使用されることになるＰＵＣＣＨリソースを識別するＰＵＣＣＨ識別子（ＰＵＣＣＨ  ＩＤ）を示していてもよい。しかしながら、ｅＭＢＢおよびＵＲＬＬＣのためにダウンリンクＳＰＳが別個に構成されているとき、基地局１１０は、ＰＵＣＣＨ  ＩＤだけでなく、ＰＵＣＣＨリソースがＵＲＬＬＣ送信（または、ｅＭＢＢ送信または他のサービスタイプ）に関係付けられているか否かも示す必要があるかもしれない。このケースでは、ＵＥ１２０は、ＵＲＬＬＣ送信のために構成されているＰＵＣＣＨリソースのセットからＰＵＣＣＨリソースを選択してもよい。したがって、ＢＳ１１０は、ＢＳ１１０とＵＥ１２０との間の通信において使用されるサービスのタイプ（例えば、ｅＭＢＢまたはＵＲＬＬＣ）に少なくとも部分的に基づいて、ダウンリンクＳＰＳ送信に関係付けられているＰＵＣＣＨリソースに対する別個のコンフィギュレーションを決定してもよい。例えば、ダウンリンクＳＰＳに関係付けられているＰＵＣＣＨリソースに対して、ＢＳ１１０は、ＰＵＣＣＨおよびダウンリンクＳＰＳ送信がｅＭＢＢに関係付けられているとき、ＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１のコンフィギュレーションを、ＰＵＣＣＨおよびダウンリンクＳＰＳ送信がＵＲＬＬＣに関係付けられているとき、ＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定してもよい。
【００８３】
［００９５］
いくつかの態様では、ＢＳ１１０は、ＰＵＣＣＨリソースの同じセットがＰＵＣＣＨ送信のためにＵＥ１２０にアクセス可能であってもよいことを示すリソースコンフィギュレーションを決定してもよいが、リソースコンフィギュレーションは、第１のタイプのサービス、第２のタイプのサービス、または、両方のタイプのサービスとともに使用するためにＰＵＣＣＨリソースを割り振るパラメータを、ＰＵＣＣＨリソースのそれぞれに割り当ててもよい。例えば、ＢＳ１１０は、ＰＵＣＣＨ送信に対するリソースコンフィギュレーションを介して、各ＰＵＣＣＨリソースが、ｅＭＢＢ、ＵＲＬＬＣ、または、ｅＭＢＢとＵＲＬＬＣの両方とともに使用されることになるか否かを示すパラメータを各ＰＵＣＣＨリソースに割り当ててもよい。結果として、ここで説明するように、ＵＥ１２０は、ｅＭＢＢ送信とＵＲＬＬＣ送信の両方に対して、ＰＵＣＣＨリソースの同じセットにアクセスし、パラメータと、（例えば、ＰＵＣＣＨリソースおよび／またはＰＵＣＣＨリソースの開始シンボルを識別する）ＤＣＩ中で受信した情報とにしたがって、ＰＵＣＣＨ送信に対する適切なリソースを選択してもよい。
【００８４】
［００９６］
図７中で参照番号７２０によってさらに示されているように、ＢＳ１１０は、リソースコンフィギュレーションを有するＰＵＣＣＨコンフィギュレーションをＵＥ１２０に送信する。いくつかの態様では、ＰＵＣＣＨコンフィギュレーションは、第１のタイプのサービス（例えば、ｅＭＢＢ）に関係付けられている送信または通信のためのパラメータの第１のセットと、第２のタイプのサービス（例えば、ＵＲＬＬＣ）に関係付けられている送信のためのパラメータの第２のセットとを含んでいてもよい。追加的にまたは代替的に、ＢＳ１１０は、第１のタイプのサービスおよび第２のタイプのサービスに対して、個々のＰＵＣＣＨコンフィギュレーションを送ってもよい。例えば、ＢＳ１１０は、ｅＭＢＢに対する第１のＰＵＣＣＨコンフィギュレーションと、ＵＲＬＬＣに対する第２のＰＵＣＣＨコンフィギュレーションとを送ってもよい。いくつかの態様では、最大コーディングレートは、ｅＭＢＢとＵＲＬＬＣとで異なっていてもよい。例えば、パラメータの第１のセット（および／または、第１のＰＵＣＣＨコンフィギュレーション）は、パラメータの第２のセット（および／または、第２のＰＵＣＣＨコンフィギュレーション）とは異なる最大コーディングレートを含んでいてもよい。
【００８５】
［００９７］
図７中で参照番号７３０によってさらに示されているように、ＢＳ１１０は、ＤＣＩを有するダウンリンク通信を送信する。ダウンリンク通信は、ＰＵＣＣＨ送信に関係付けられているサービスのタイプを示していてもよい、サービスのタイプに関係付けられている１つ以上のパケットを含んでいてもよい。例えば、ダウンリンク通信がｅＭＢＢ通信である場合、ＰＵＣＣＨ送信はｅＭＢＢサービスに関係付けられていてもよい。追加的にまたは代替的に、ダウンリンク通信がＵＲＬＬＣ通信に関係付けられている場合、ＰＵＣＣＨ送信はＵＲＬＬＣ通信に関係付けられていてもよい。
【００８６】
［００９８］
ＵＥ１２０は、ＤＣＩがｅＭＢＢまたはＵＲＬＬＣに関係付けられているか否かを決定してもよい。いくつかの態様では、ダウンリンク通信中のＤＣＩは、ここではＰＵＣＣＨリソースインジケータとして呼ばれる、ＡＣＫ／ＮＡＣＫリソースインジケータ（ＡＲＩ）フィールドを含んでいてもよい。いくつかの態様では、ＵＥ１２０は、ＰＵＣＣＨ送信のために使用されることになるサービスのタイプ（例えば、ｅＭＢＢまたはＵＲＬＬＣ）に少なくとも部分的に基づいて、ＰＵＣＣＨリソースインジケータのビット幅（すなわち、ビットの数）を決定してもよい。例えば、ＰＵＣＣＨ送信がＵＲＬＬＣ送信に関係付けられているとき、ＵＥ１２０は、（例えば、ＰＵＣＣＨリソースのセットのリソースの数が４つ以下であることを示す）ＰＵＣＣＨリソースインジケータが２ビットであることを決定してもよい。別の例として、ＰＵＣＣＨ送信がｅＭＢＢ送信に関係付けられているとき、ＵＥ１２０は、（例えば、ＰＵＣＣＨリソースのセットのリソースの数が８つ以下であることを示す）ＰＵＣＣＨリソースインジケータが３ビットであることを決定してもよい。
【００８７】
［００９９］
図７中で参照番号７４０によってさらに示されているように、ＵＥ１２０は、ダウンリンク通信に少なくとも部分的に基づいて、ＰＵＣＣＨ送信に関係付けられているサービスのタイプを決定する。いくつかの態様では、ＵＥ１２０は、前のパケットを受信および／または送信するために使用されたサービスのタイプに少なくとも部分的に基づいて、サービスのタイプを決定してもよい。例えば、ダウンリンク通信が第１のサービスを介して受信される場合、ＵＥ１２０は、ＰＵＣＣＨ送信が第１のサービスを使用して送信されることになることを決定してもよく、ダウンリンク通信が第２のサービスを介して受信される場合、ＵＥ１２０は、ＰＵＣＣＨ送信が第２のサービスを使用して送信されることになることを決定してもよい。
【００８８】
［００１００］
図７中で参照番号７５０によってさらに示されているように、ＵＥ１２０は、ＰＵＣＣＨ送信のサービスタイプに関係付けられているリソースコンフィギュレーションにしたがうリソースを使用して、ＰＵＣＣＨ送信を送信する。したがって、ＤＣＩを使用して、ＵＥ１２０は、どのリソースがＰＵＣＣＨ送信のために使用されることになるかを決定し、そのリソースを使用してＰＵＣＣＨ送信を送信してもよい。
【００８９】
［００１０１］
いくつかの態様では、ＵＥ１２０は、異なるサービス（例えば、ｅＭＢＢおよびＵＲＬＬＣ）に対応する異なるＰＵＣＣＨリソースセットを用いて構成されていてもよい。ＵＥ１２０は、サービスタイプに関連する受信したダウンリンク通信内のコンフィギュレーションとＤＣＩとに少なくとも部分的に基づいて、どのリソースがＰＵＣＣＨ送信のために使用されることになるかを決定してもよい。例えば、ＵＥ１２０は、ＰＵＣＣＨ送信がｅＭＢＢサービスに関係付けられていることを決定してもよい。このケースでは、ＵＥ１２０は、受信したダウンリンク通信内のコンフィギュレーションとＤＣＩとに少なくとも部分的に基づいて、ｅＭＢＢサービスのために構成されているリソースのセットからＰＵＣＣＨリソースを選択してもよい。追加的にまたは代替的に、ＵＥ１２０は、ＰＵＣＣＨ送信がＵＲＬＬＣサービスに関係付けられていることを決定してもよい。このケースでは、ＵＥ１２０は、受信したダウンリンク通信内のコンフィギュレーションとＤＣＩとに少なくとも部分的に基づいて、ＵＲＬＬＣサービスのために構成されているリソースのセットからＰＵＣＣＨリソースを選択してもよい。ＤＣＩは、開始シンボル、使用されることになるＯＦＤＭシンボルおよびリソースブロックの数、ＰＵＣＣＨリソースＩＤ、ならびに／あるいは、これらに類するものを示していてもよい。
【００９０】
［００１０２］
いくつかの例では、ＵＥ１２０が複数のタイプのサービスに対して同じＰＵＣＣＨリソースコンフィギュレーションを使用するとき、ＵＥ１２０は、ＰＵＣＣＨリソースがＵＲＬＬＣとともに使用されるべきか、ｅＭＢＢとともに使用されるべきか（または、両方とともに使用されるべきか）を示しているテーブルを参照してもよい。例えば、ＵＥ１２０は、ｅＭＢＢおよびＵＲＬＬＣとともに使用するためのＰＵＣＣＨリソースを識別する以下のテーブルを参照してもよい：
【表１】
2021523617.tif 000003
ＰＵＣＣＨリソースが、ＵＲＬＬＣ  ＰＵＣＣＨ送信、ｅＭＢＢ  ＰＵＣＣＨ送信、または、ＵＲＬＬＣ  ＰＵＣＣＨ送信とｅＭＢＢ  ＰＵＣＣＨ送信の両方とともに使用されることになるかを、ＵＲＬＬＣ／ｅＭＢＢフラグは識別する。いくつかの態様では、各ＰＵＣＣＨリソースは、１つはＵＲＬＬＣに対する、１つはｅＭＢＢに対する、２つの別個の識別子（例えば、ＵＲＬＬＣ／ｅＭＢＢフラグに少なくとも部分的に基づいてＵＥにおいて暗黙的に決定される仮想ＩＤ）を有してもよい。例として、ＵＲＬＬＣに関係付けられているＰＵＣＣＨ送信に対して、ＵＥ１２０は、ＤＣＩ中で（３のＵＲＬＬＣ  ＩＤを示す）ＰＵＣＣＨリソースインジケータ＝３を受信してもよい。したがって、ＵＥ１２０は、ＰＵＣＣＨリソースインジケータ＝３を使用し、リソース＃０から開始して、リソース＃７をＰＵＣＣＨ送信に対するＰＵＣＣＨリソースとして識別し、リソース＃０は、０のＵＲＬＬＣ  ＩＤを有し、リソース＃１は、１のＵＲＬＬＣ  ＩＤを有し、リソース＃６は、２のＵＲＬＬＣ  ＩＤを有し、リソース＃７は、３のＵＲＬＬＣ  ＩＤを有する。したがって、各リソース＃０〜７は、ＰＵＣＣＨ送信に関係付けられているサービスのタイプ（例えば、ｅＭＢＢまたはＵＲＬＬＣ）に少なくとも部分的に基づく追加の識別子を有していてもよい。
【００９１】
［００１０３］
いくつかの態様では、ＵＥ１２０は、開始シンボルパラメータを使用して、どのＰＵＣＣＨリソースがＰＵＣＣＨ送信のために使用されることになるかを決定してもよい。ＤＣＩ中に含まれるかもしれない例示的な開始シンボルパラメータは、ＵＲＬＬＣとｅＭＢＢとに対して異なっていてもよい。例えば、ｅＭＢＢに対して、開始シンボルパラメータは、スロット内の相対インデックスを指していてもよい。追加的にまたは代替的に、ＵＲＬＬＣに対して、開始シンボルパラメータは、シグナリング（例えば、ＡＣＫ／ＮＡＣＫがいつ送信されることになるかを識別する、ＤＣＩ中のＫ１シグナリング）に対するタイミングを示していてもよい。
【００９２】
［００１０４］
いくつかの態様では、（例えば、ＵＲＬＬＣサービスＰＵＣＣＨ送信に対する）送信ダイバーシティを達成するために、ＰＵＣＣＨ送信は、対応するリソースコンフィギュレーション中で識別されるリソースのセットの２つ以上のリソース上で送信されてもよい。例えば、ＵＲＬＬＣサービスに関係付けられているＰＵＣＣＨ送信に対して、ＰＵＣＣＨ送信は、送信ダイバーシティ利得を取得するために、ＵＲＬＬＣサービスのために割り振られるリソースのセットの２つのリソース上で、少なくとも２つの送信アンテナを介して送信されてもよい。これは、ＵＲＬＬＣ内のＰＵＣＣＨ送信の信頼性を改善することができる。このようなケースでは、複数のＰＵＣＣＨリソースは、同じ識別子を用いて構成されていてもよい。したがって、ＰＵＣＣＨ送信がその識別子を有するＰＵＣＣＨリソースを介して送られることになることをＤＣＩが示している場合、複数のリソースを介してＰＵＣＣＨ送信を送ることができる。いくつかのケースでは、ＤＣＩは、インデックスｋを示していてもよく、ＵＥ１２０は、インデックスと、ＰＵＣＣＨを送信するためにＵＥに割り振られるＰＵＣＣＨリソースの数を示す（例えば、ＤＣＩを受信する前にＲＲＣ通信を介して受信されてもよい）無線リソース制御（ＲＲＣ）コンフィギュレーションＭとに少なくとも部分的に基づいて、ＰＵＣＣＨリソースを使用してもよい。したがって、ｋは動的に受信されてもよく、Ｍは半静的に受信されてもよい。ＵＥ１２０は、ｋおよびＭを使用して、使用されることになるリソースの対応するセットのＰＵＣＣＨリソースを識別してもよい。例えば、ＵＥ１２０は、Ｍ（ｋ−１）、Ｍ（ｋ−１）＋１、．．．、Ｍｋ−１に等しい識別子を有するＰＵＣＣＨリソースを識別してもよい。追加的にまたは代替的に、ＵＥ１２０は、ｋ、ｋ＋１、．．．、ｋ＋Ｍ−１に等しい識別子を有するＰＵＣＣＨリソースを識別してもよい。いくつかの態様では、異なるまたは追加のＰＵＣＣＨフォーマットを使用して、送信ダイバーシティを達成することができる。例えば、あるＰＵＣＣＨフォーマットは、ＵＲＬＬＣのために構成されていてもよいが、ｅＭＢＢのためには構成されない。いくつかの態様では、送信ダイバーシティに関して上記で説明したスキームは、ＵＲＬＬＣ  ＰＵＣＣＨ送信に適用されてもよいが、ｅＭＢＢ  ＰＵＣＣＨ送信には適
用されない。
【００９３】
［００１０５］
ダウンリンク割り当てインデックス（ＤＡＩ）を使用して、ＵＥ１２０が現在のＤＣＩまでに受信した物理ダウンリンク共有チャネル（ＰＤＳＣＨ）通信の数を示してもよい。例えば、ＵＥ１２０は、カウンタＤＡＩおよび／またはトータルＤＡＩの表示を受信してもよい。カウンタＤＡＩの値は、現在の担当セルおよび現在のＰＤＣＣＨ監視機会までに、ＰＤＳＣＨ受信またはＳＰＳ  ＰＤＳＣＨ解放が存在する、担当セルＰＤＣＣＨ監視機会の累積数を示していてもよい。トータルＤＡＩの値は、存在する場合、現在のＰＤＣＣＨ監視機会までに、ＰＤＳＣＨ受信およびＳＰＳ  ＰＤＳＣＨ解放が存在する、担当セルＰＤＣＣＨ監視機会ペアの総数を示していてもよい。いくつかの態様では、ＵＥ１２０は、ＵＲＬＬＣおよびｅＭＢＢに対して、ＤＡＩの異なるセットを追跡および／または記憶していてもよく、ＵＲＬＬＣおよびｅＭＢＢに対して、別個のＤＡＩカウントおよび／またはＤＡＩ累積を実行してもよい。例えば、ＵＥ１２０は、ＤＡＩの２つのセットを追跡および／または記憶していてもよく、｛カウンタＤＡＩ、トータルＤＡＩ｝の第１のセットはＵＲＬＬＣ送信のみに適用され、｛カウンタＤＡＩ、トータルＤＡＩ｝の第２のセットはｅＭＢＢ送信のみに適用される。このケースでは、ＵＲＬＬＣ  ＤＡＩはｅＭＢＢ  ＤＡＩに向けてカウントせず、逆もまた同様である。いくつかの態様では、ＵＥ１２０は、ＰＵＣＣＨリソースコンフィギュレーションに少なくとも部分的に基づいて、異なるタイプのサービスに対して別個のＤＡＩ動作を実行するように構成されていてもよい。例えば、ＰＵＣＣＨ送信中のアップリンク制御情報（ＵＣＩ）は、ＰＵＣＣＨ送信がｅＭＢＢに関係付けられているとき、第１のダウンリンク割り当てインデックス（ＤＡＩ）動作にしたがって決定されてもよく、ＰＵＣＣＨ送信中のＵＣＩは、ＰＵＣＣＨ送信がＵＲＬＬＣに関係付けられているとき、第２のＤＡＩ動作にしたがって決定されてもよい。
【００９４】
［００１０６］
ＵＥ１２０は、ＤＣＩがｅＭＢＢに関係付けられているかまたはＵＲＬＬＣに関係付けられているかを決定してもよい。いくつかの態様では、ダウンリンク通信中のＤＣＩは、ＤＡＩフィールドを含んでいてもよい。いくつかの態様では、ＵＥ１２０は、ＰＵＣＣＨ送信のために使用されることになるサービスのタイプ（例えば、ｅＭＢＢまたはＵＲＬＬＣ）に少なくとも部分的に基づいて、ＤＡＩのビット幅（すなわち、ビットの数）を決定してもよい。例えば、ＵＥ１２０は、ＰＵＣＣＨ送信がＵＲＬＬＣ送信に関係付けられているとき、ＤＡＩが１ビットであることを決定してもよい。別の例として、ＵＥ１２０は、ＰＵＣＣＨ送信がｅＭＢＢ送信に関係付けられているとき、ＤＡＩが２ビットであることを決定してもよい。
【００９５】
［００１０７］
例示的なＰＵＣＣＨ送信はＡＣＫ／ＮＡＣＫであってもよい。ＡＣＫ／ＮＡＣＫは、（例えば、ダウンリンク通信を受信したことに応答して）動的に、および／または、半永続的スケジューリング（ＳＰＳ）にしたがって、送られてもよい。いくつかの態様では、ｅＭＢＢと比較して、ＵＲＬＬＣに対するＡＣＫ／ＮＡＣＫバンドリングに関して異なるＤＡＩ動作を実行してもよい。より具体的には、ＵＥ１２０は、ＰＵＣＣＨ送信を送るとき、ＵＲＬＬＣとｅＭＢＢとの間で多重化しないかもしれない。したがって、ＵＲＬＬＣパケットの受信に対するＡＣＫ／ＮＡＣＫは、ｅＭＢＢパケットの受信に対するＡＣＫ／ＮＡＣＫとは別個のＰＵＣＣＨ送信で送られてもよい。いくつかの態様では、ＵＲＬＬＣとｅＭＢＢの両方に対するＡＣＫ／ＮＡＣＫが時間的にオーバーラップするとき、ｅＭＢＢ  ＡＣＫ／ＮＡＣＫは（例えば、ＵＲＬＬＣの低いレイテンシおよび高信頼性要件を満たすために）ドロップされるかもしれない。しかしながら、送信が同じスロット中で行われることになるが、オーバーラップしていない場合、ｅＭＢＢ  ＡＣＫ／ＮＡＣＫはドロップされないかもしれない。例えば、第１のＰＵＣＣＨ送信がシンボル１〜５上でスケジュールされ、第２のＰＵＣＣＨ送信がシンボル６〜１０上でスケジュールされる場合、第１のＰＵＣＣＨ送信も第２のＰＵＣＣＨ送信もドロップされない。追加的にまたは代替的に、２つの送信が部分的にオーバーラップするように構成されているとき、ｅＭＢＢ  ＰＵＣＣＨ送信のオーバーラップする部分はドロップされるかもしれない。例えば、ｅＭＢＢ  ＰＵＣＣＨ送信がシンボル１〜１０上であり、ＵＲＬＬＣ  ＰＵＣＣＨ送信がシンボル７〜１１上であることになる場合、ｅＭＢＢ  ＰＵＣＣＨ送信のためのシンボル７〜１０中のデータはドロップされるかもしれない。
【００９６】
［００１０８］
いくつかの態様では、ＰＵＣＣＨ送信は、（例えば、アップリンクリソースを要求する）サービス要求（ＳＲ）を、および／または、（例えば、ダウンリンク通信を受信するために使用されるチャネルのステータスを示す）チャネル状態情報（ＣＳＩ）報告を含んでいてもよい。
【００９７】
［００１０９］
上記で示したように、図７は例として提供されている。他の例は、図７に関して説明したものとは異なっていてもよい。
【００９８】
［００１１０］
図８は、ＵＲＬＬＣに対するＰＵＣＣＨリソースを割り振る例８１０および８２０を図示しているダイヤグラムである。図８では、サービスのタイプ（例えば、ｅＭＢＢまたはＵＲＬＬＣ）にしたがって割り当てられていてもよいリソースのダイヤグラムが示されている。例８１０によって示されているように、ｅＭＢＢ  ＰＵＣＣＨリソースセットは、ＵＲＬＬＣのために割り振られるＰＵＣＣＨリソースセットとは異なっていてもよい。例えば、ｅＭＢＢ  ＰＵＣＣＨリソースは、セットＡ、Ｂ、Ｃ、Ｄを含んでいてもよく、ＵＲＬＬＣ  ＰＵＣＣＨリソースセットは、セットＸ、Ｙ、Ｚを含んでいてもよい。さらに、例８１０によって示されているように、サービスのタイプに少なくとも部分的に基づいて、異なる量のリソースセットが、割り振られてもよい。例えば、４つのＰＵＣＣＨリソースセットＡ、Ｂ、Ｃ、ＤがｅＭＢＢに対して割り振られ、３つのリソースセットＸ、Ｙ、ＺがＵＲＬＬＣに対して割り振られる。
【００９９】
［００１１１］
例８２０によって示されているように、いくつかの態様では、複数のタイプのサービスに対して、ＰＵＣＣＨリソースの同じセットを共有してもよく、特定のタイプのリソースセットに対して、いくつかのリソースセットを使用してもよい。例えば、ｅＭＢＢおよびＵＲＬＬＣの両方がセットＡＢＣを使用してもよいが、ｅＭＢＢのみがセット０を使用してもよく、ＵＲＬＬＣのみがセット１を使用してもよい。したがって、ＰＵＣＣＨ送信のタイプに少なくとも部分的に基づいて、ＰＵＣＣＨ送信のために、ＰＵＣＣＨリソースセットを割り振ることができる。
【０１００】
［００１１２］
上記で示したように、図８は例として提供されている。他の例は、図８に関して説明したものとは異なっていてもよい。
【０１０１】
［００１１３］
図９は、ＵＲＬＬＣに対するＰＵＣＣＨリソースを割り振る例９００を図示しているダイヤグラムである。例９００によって示されているように、送信ダイバーシティを達成するために、リソースのセット内の複数のリソースに、同じリソースＩＤが割り当てられてもよい。図９では、２つのリソースがＩＤ＝２を有し、４つのリソースがＩＤ＝３を有する。したがって、ＰＵＣＣＨ送信がＩＤ＝２を有するＰＵＣＣＨリソースを介して送信されることになることをＵＥ１２０が決定するとき、ＵＥ１２０は、２つのリソースを介してＰＵＣＣＨ送信を送信してもよい。同様に、ＰＵＣＣＨ送信がＩＤ＝３を有するＰＵＣＣＨリソースを介して送信されることになることをＵＥ１２０が決定するとき、ＵＥ１２０は、４つのリソースを介してＰＵＣＣＨ送信を送信してもよい。いくつかの態様では、２つのＰＵＣＣＨリソースまたは４つのＰＵＣＣＨリソースが、同じ時間ドメインリソースに関係付けられてもよく（例えば、同じＯＦＤＭシンボル上で構成されてもよく）、このケースでは、ＵＥ１２０は、空間ダイバーシティを達成するために、異なる送信アンテナから同時に、これらの示されたＰＵＣＣＨリソース上でＰＵＣＣＨを送信する。
【０１０２】
［００１１４］
上記で示したように、図９は例として提供されている。他の例は、図９に関して説明したものとは異なっていてもよい。
【０１０３】
［００１１５］
図１０は、本開示のさまざまな態様にしたがう、例えば、ＵＥによって実行される例示的なプロセス１０００を図示しているダイヤグラムである。例示的なプロセス１０００は、ＵＥ（例えば、ＵＥ１２０および／またはこれらに類するもの）が、ＰＵＣＣＨリソースを識別することと、ここで説明するいくつかの例にしたがって割り振られるＰＵＣＣＨリソースを使用して、ＰＵＣＣＨ送信を送ることとに関係付けられている動作を実行する例である。
【０１０４】
［００１１６］
図１０中で示されているように、いくつかの態様では、プロセス１０００は、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているかまたは第２のタイプのサービスに関係付けられているかを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることを含んでいてもよい（ブロック１０１０）。例えば、上記で説明したように、ＵＥは（例えば、受信プロセッサ２５８、送信プロセッサ２６４、制御装置／プロセッサ２８０、メモリ２８２、および／または、これらに類するものを使用して）、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているかまたは第２のタイプのサービスに関係付けられているかを決定してもよい。いくつかの態様では、第２のタイプのサービスは、第１のタイプのサービスのよりもより高い信頼性またはより低いレイテンシに関係付けられている。
【０１０５】
［００１１７］
図１０中でさらに示されているように、いくつかの態様では、プロセス１０００は、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、リソースの第１のセットを使用して、または、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、リソースの第２のセットを使用して、ＰＵＣＣＨ送信を送信することを含んでいてもよい（ブロック１０２０）。例えば、ＵＥは（例えば、受信プロセッサ２５８、送信プロセッサ２６４、制御装置／プロセッサ２８０、メモリ２８２、および／または、これらに類するものを使用して）、上記で説明したように、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、リソースの第１のセットを使用して、または、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、リソースの第２のセットを使用して、ＰＵＣＣＨ送信を送信してもよい。
【０１０６】
［００１１８］
プロセス１０００は、以下で説明する、任意の単一の態様または態様の任意の組み合わせ、および／または、ここでの他の箇所で説明する１つ以上の他のプロセスに関連するような、追加の態様を含んでいてもよい。
【０１０７】
［００１１９］
第１の態様では、第１のタイプのサービスは、拡張移動体ブロードバンド（ｅＭＢＢ）サービスを含み、第２のタイプのサービスは、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）サービスを含んでいる。
【０１０８】
［００１２０］
第２の態様では、単独で、または、第１の態様と組み合わせて、リソースの第１のセットは、第１のタイプのサービスに対して構成されている複数のリソースセットを含んでいる。
【０１０９】
［００１２１］
第３の態様では、単独で、または、第１および第２の態様のうちの１つ以上と組み合わせて、リソースの第２のセットは、第２のタイプのサービスに対して構成されている複数のリソースセットを含んでいる。
【０１１０】
［００１２２］
第４の態様では、単独で、または、第１〜第３の態様のうちの１つ以上と組み合わせて、ＰＵＣＣＨ送信は、肯定応答および／または否定応答（ＡＣＫ／ＮＡＣＫ）、サービス要求（ＳＲ）、あるいは、チャネル状態情報（ＣＳＩ）報告のうちの少なくとも１つを含んでいる。
【０１１１】
［００１２３］
第５の態様では、単独で、または、第１〜第４の態様のうちの１つ以上と組み合わせて、ＡＣＫ／ＮＡＣＫは、動的スケジューリングまたは半永続的スケジューリング（ＳＰＳ）に関係付けられている。
【０１１２】
［００１２４］
第６の態様では、単独で、または、第１〜第５の態様のうちの１つ以上と組み合わせて、リソースの第１のセットは４つのリソースセットを含み、リソースの第２のセットは４つ未満のリソースセットを含んでいる。
【０１１３】
［００１２５］
第７の態様では、単独で、または、第１から第６の態様のうちの１つ以上と組み合わせて、リソースの第１のセットは、リソースの第２のセットとは異なる。
【０１１４】
［００１２６］
第８の態様では、単独で、または、第１〜第７の態様のうちの１つ以上と組み合わせて、リソースの第２のセット中のリソースセットの数は、リソースの第１のセット中のリソースセットの数よりも少ない。
【０１１５】
［００１２７］
第９の態様では、単独で、または、第１〜第８の態様のうちの１つ以上と組み合わせて、リソースの第１のセットのうちの少なくとも１つのリソースセットは、リソースの第２のセット中に含まれるリソースセットと同じリソースセットである。
【０１１６】
［００１２８］
第１０の態様では、単独で、または、第１〜第９の態様のうちの１つ以上と組み合わせて、リソースの第２のセットの各セット内のリソースの数は、リソースの第１のセットの各セット内のリソースの数よりも少ない。
【０１１７】
［００１２９］
第１１の態様では、単独で、または、第１〜第１０の態様のうちの１つ以上と組み合わせて、ＵＥは、ＰＵＣＣＨ送信に関係して基地局から受信したダウンリンク制御情報（ＤＣＩ）中のＰＵＣＣＨリソースインジケータフィールドのビット幅に少なくとも部分的に基づいて、リソースの第１のセットまたはリソースの第２のセットの各セット内のリソースの数を決定するように構成されている。
【０１１８】
［００１３０］
第１２の態様では、単独で、または、第１〜第１１の態様のうちの１つ以上と組み合わせて、ＰＵＣＣＨ送信は、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているという決定に少なくとも部分的に基づいて、リソースの第２のセットの２つ以上のリソース上で送信される。
【０１１９】
［００１３１］
第１３の態様では、単独で、または、第１〜第１２の態様のうちの１つ以上と組み合わせて、ＰＵＣＣＨ送信は、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているという決定に少なくとも部分的に基づいて、リソースの第２のセットの２つのリソース上で、少なくとも２つの送信アンテナを介して送信される。
【０１２０】
［００１３２］
第１４の態様では、単独で、または、第１〜第１３の態様のうちの１つ以上と組み合わせて、リソースの第２のセットのうちの１つのセットの少なくとも２つのリソースは、同じ識別子を共有し、識別子がＰＵＣＣＨ送信に関係して受信されるとき、ＰＵＣＣＨ送信は、少なくとも２つのリソースを使用して送信される。
【０１２１】
［００１３３］
第１５の態様では、単独で、または、第１〜第１４の態様のうちの１つ以上と組み合わせて、基地局から、ＰＵＣＣＨ送信に関係して、インデックスと半静的に受信されるコンフィギュレーションとを受信することに少なくとも部分的に基づいて、ＰＵＣＣＨ送信は、リソースの第２のセットの１つ以上のリソースを使用して送信される。
【０１２２】
［００１３４］
第１６の態様では、単独で、または、第１〜第１５の態様のうちの１つ以上と組み合わせて、リソースの第２のセットのリソースは、ＰＵＣＣＨ送信に関連して使用するために、リソースの第１のセットのリソースとは異なって識別される。
【０１２３】
［００１３５］
第１７の態様では、単独で、または、第１〜第１６の態様のうちの１つ以上と組み合わせて、リソースの第２のセットのリソースは、異なるＰＵＣＣＨフォーマットを使用することに関連して、ＰＵＣＣＨ送信に関連する使用のために、リソースの第１のセットのリソースとは異なって識別される。
【０１２４】
［００１３６］
第１８の態様では、単独で、または、第１〜第１７の態様のうちの１つ以上と組み合わせて、リソースの第１のセットのリソースは、リソースの第１のセットのリソースに関係付けられているパラメータの第１の値に少なくとも部分的に基づいて、第１のタイプのサービスに関係する使用のために識別され、または、リソースの第２のセットのリソースは、リソースの第２のセットのリソースに関係付けられているパラメータの第２の値に少なくとも部分的に基づいて、第２のタイプのサービスに関係する使用のために識別される。
【０１２５】
［００１３７］
第１９の態様では、単独で、または、第１〜第１８の態様のうちの１つ以上と組み合わせて、ＰＵＣＣＨ送信のリソースに対して、パラメータは、パラメータの値に少なくとも部分的に基づいて、リソースが、第１のタイプのサービスに、第２のタイプのサービスに、または、第１のタイプのサービスと第２のタイプのサービスの両方に関係付けられているか否かを示している。
【０１２６】
［００１３８］
第２０の態様では、単独で、または、第１〜第１９の態様のうちの１つ以上と組み合わせて、パラメータは、ＰＵＣＣＨ送信に対するリソースのコンフィギュレーション内に含まれている。
【０１２７】
［００１３９］
第２１の態様では、単独で、または、第１〜第２０の態様のうちの１つ以上と組み合わせて、パラメータの値は、リソースの第１のセットとリソースの第２のセットの同じリソースが、第１のタイプのサービスと第２のタイプのサービスとに関係付けられていることを示している。
【０１２８】
［００１４０］
第２２の態様では、単独で、または、第１〜第２１の態様のうちの１つ以上と組み合わせて、リソースの第１のセットは、リソースの第２のセットとリソースの同じセットである。いくつかの態様では、リソースの同じセットの各リソースは、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、ＰＵＣＣＨ送信に対する第１の識別子に関係付けられ、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、ＰＵＣＣＨ送信に対する第２の識別子に関係付けられている。
【０１２９】
［００１４１］
第２３の態様では、単独で、または、第１〜第２２の態様のうちの１つ以上と組み合わせて、ＰＵＣＣＨ送信は、第１のタイプのサービスまたは第２のタイプのサービスに関係付けられているインデックスを示すダウンリンク制御情報を受信することに少なくとも部分的に基づいて、リソースの同じセットのうちの１つを使用して送信される。
【０１３０】
［００１４２］
第２４の態様では、単独で、または、第１〜第２３の態様のうちの１つ以上と組み合わせて、開始シンボルパラメータは、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているときとは異なる開始シンボルを識別する。
【０１３１】
［００１４３］
第２５の態様では、単独で、または、第１〜第２４の態様のうちの１つ以上と組み合わせて、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているときの開始シンボルパラメータは、ＰＵＣＣＨ送信に対するスロットに関する相対インデックスを識別する。
【０１３２】
［００１４４］
第２６の態様では、単独で、または、第１〜第２５の態様のうちの１つ以上と組み合わせて、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているときの開始シンボルパラメータは、ダウンリンク制御情報（ＤＣＩ）中のシグナリングに関係付けられているタイミングを識別する。
【０１３３】
［００１４５］
第２７の態様では、単独で、または、第１〜第２６の態様のうちの１つ以上と組み合わせて、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、ＰＵＣＣＨ送信中のアップリンク制御情報（ＵＣＩ）は、第１のダウンリンク割り当てインデックス（ＤＡＩ）動作にしたがって決定され、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、ＰＵＣＣＨ送信中のＵＣＩは、第２のＤＡＩ動作にしたがって決定される。
【０１３４】
［００１４６］
第２８の態様では、単独で、または、第１〜第２７の態様のうちの１つ以上と組み合わせて、ＰＵＣＣＨ送信が、第１のタイプのサービスに関係付けられている第１のＰＵＣＣＨ送信であり、第２のタイプのサービスに関係付けられている第２のＰＵＣＣＨ送信が、第１のＰＵＣＣＨ送信のシンボルとオーバーラップするシンボルを使用して送信されることになるとき、オーバーラップするシンボルは、第１のＰＵＣＣＨ送信からドロップされる。
【０１３５】
［００１４７］
図１０は、プロセス１０００の例示的なブロックを示しているが、いくつかの態様では、プロセス１０００は、追加のブロック、より少ないブロック、異なるブロック、または、図１０中に描いたものとは異なって構成されているブロックを含んでいてもよい。追加的にまたは代替的に、プロセス１０００のブロックのうちの２つ以上を並列に実行してもよい。
【０１３６】
［００１４８］
図１１は、本開示のさまざまな態様にしたがう、例えば、基地局によって実行される例示的なプロセス１１００を図示しているダイヤグラムである。例示的なプロセス１１００は、基地局（例えば、基地局１１０および／またはこれらに類するもの）が、ＰＵＣＣＨ送信に関係付けられているサービスのタイプに関連するＰＵＣＣＨリソースの割り振りに関係付けられている動作を実行する例である。
【０１３７】
［００１４９］
図１１中で示されているように、いくつかの態様では、プロセス１１００は、第１のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１のコンフィギュレーションを決定することを含んでいてもよい（ブロック１１１０）。例えば、基地局は（例えば、制御装置／プロセッサ２４０、メモリ２４２、および／または、これらに類するものを使用して）、上記で説明したように、第１のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１のコンフィギュレーションを決定してもよい。
【０１３８】
［００１５０］
図１１中でさらに示されているように、いくつかの態様では、プロセス１１００は、第２のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることを含んでいてもよい（ブロック１１２０）。例えば、基地局は（例えば、制御装置／プロセッサ２４０、メモリ２４２、および／または、これらに類するものを使用して）、上記で説明したように、第２のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定してもよい。いくつかの態様では、第２のタイプのサービスは、第１のタイプのサービスのよりもより高い信頼性またはより低いレイテンシに関係付けられている。
【０１３９】
［００１５１］
図１１中でさらに示されているように、いくつかの態様では、プロセス１１００は、第１のコンフィギュレーションと第２のコンフィギュレーションとをユーザ機器（ＵＥ）に送信することを含んでいてもよい（ブロック１１３０）。例えば、基地局は（例えば、送信プロセッサ２２０、制御装置／プロセッサ２４０、メモリ２４２、および／または、これらに類するものを使用して）、上記で説明したように、第１のコンフィギュレーションと第２のコンフィギュレーションとをＵＥに送信してもよい。
【０１４０】
［００１５２］
プロセス１１００は、以下で説明する、任意の単一の態様または態様の任意の組み合わせ、および／または、ここでの他の箇所で説明する１つ以上の他のプロセスに関連するような、追加の態様を含んでいてもよい。
【０１４１】
［００１５３］
第１の態様では、第１のタイプのサービスは、拡張移動体ブロードバンド（ｅＭＢＢ）サービスを含み、第２のタイプのサービスは、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）サービスを含んでいる。
【０１４２】
［００１５４］
第２の態様では、単独で、または、第１の態様と組み合わせて、第１のコンフィギュレーションは第２のコンフィギュレーションとは異なる。
【０１４３】
［００１５５］
第３の態様では、単独で、または、第１および第２の態様のうちの１つ以上と組み合わせて、第１のコンフィギュレーション中に含まれるＰＵＣＣＨリソースのセットは、第２のコンフィギュレーション中に含まれるＰＵＣＣＨリソースのセットとは異なる。
【０１４４】
［００１５６］
第４の態様では、単独で、または、第１〜第３の態様のうちの１つ以上と組み合わせて、第２のコンフィギュレーションは、第１のコンフィギュレーションよりもＰＵＣＣＨリソースのより少ないセットを含んでいる。
【０１４５】
［００１５７］
第５の態様では、単独で、または、第１〜第４の態様のうちの１つ以上と組み合わせて、第２のコンフィギュレーション中に含まれるＰＵＣＣＨリソースの各セット中のＰＵＣＣＨリソースの数は、第１のコンフィギュレーション中に含まれるＰＵＣＣＨリソースの各セット中のＰＵＣＣＨリソースの数よりも少ない。
【０１４６】
［００１５８］
第６の態様では、単独で、または、第１〜第５の態様のうちの１つ以上と組み合わせて、ダウンリンク制御情報（ＤＣＩ）中のＰＵＣＣＨリソースインジケータのビット幅は、第２のコンフィギュレーション中に含まれるＰＵＣＣＨリソースの各セット中のＰＵＣＣＨリソースの数にしたがっている第２のタイプのサービスに対応する。
【０１４７】
［００１５９］
第７の態様では、単独で、または、第１〜第６の態様のうちの１つ以上と組み合わせて、第１のコンフィギュレーションおよび第２のコンフィギュレーションの各ＰＵＣＣＨリソースに対して、パラメータは、ＰＵＣＣＨリソースが、第１のタイプのサービスに、第２のタイプのサービスに、または、第１のタイプのサービスと第２のタイプのサービスの両方に関係付けられているか否かを示している。
【０１４８】
［００１６０］
第８の態様では、単独で、または、第１〜第７の態様のうちの１つ以上と組み合わせて、第１のコンフィギュレーションのリソースの第１のセットは、第２のコンフィギュレーションのリソースの第２のセットとリソースの同じセットであり、リソースの同じセットの各リソースは、ＰＵＣＣＨ送信が第１のタイプのサービスに関係付けられているとき、ＰＵＣＣＨ送信に対する第１の識別子に関係付けられ、ＰＵＣＣＨ送信が第２のタイプのサービスに関係付けられているとき、ＰＵＣＣＨ送信に対する第２の識別子に関係付けられる。
【０１４９】
［００１６１］
第９の態様では、単独で、または、第１〜第８の態様のうちの１つ以上と組み合わせて、第１のコンフィギュレーションは、第１のタイプに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第１の複数のコンフィギュレーションのうちの１つである。
【０１５０】
［００１６２］
第１０の態様では、単独で、または、第１〜第９の態様のうちの１つ以上と組み合わせて、第１のコンフィギュレーションの最大コーディングレートは、第２のコンフィギュレーションの最大コーディングレートとは異なる。
【０１５１】
［００１６３］
図１１は、プロセス１１００の例示的なブロックを示しているが、いくつかの態様では、プロセス１１００は、追加のブロック、より少ないブロック、異なるブロック、または、図１１中に描いたものとは異なって構成されているブロックを含んでいてもよい。追加的にまたは代替的に、プロセス１１００のブロックのうちの２つ以上を並列に実行してもよい。
【０１５２】
［００１６４］
図１２は、本開示のさまざまな態様にしたがう、例えば、ＵＥによって実行される例示的なプロセス１２００を図示しているダイヤグラムである。例示的なプロセス１２００は、ＵＥ（例えば、ＵＥ１２０および／またはこれらに類するもの）が、サービスのタイプにしたがって構成されているＰＵＣＣＨコンフィギュレーションを使用して、そのサービスのタイプに関係付けられているメッセージを送信することに関係付けられている動作を実行する例である。
【０１５３】
［００１６５］
図１２中で示されているように、いくつかの態様では、プロセス１２００は、第１のサービスタイプに関係付けられている送信のためのパラメータの第１のセットと、第２のサービスタイプに関係付けられている送信のためのパラメータの第２のセットとを含むＰＵＣＣＨコンフィギュレーションを受信することを含んでいてもよい（ブロック１２１０）。例えば、ＵＥは（例えば、受信プロセッサ２５８、制御装置／プロセッサ２８０、メモリ２８２、および／または、これらに類するものを使用して）、上記で説明したように、第１のサービスタイプに関係付けられている送信のためのパラメータの第１のセットと、第２のサービスタイプに関係付けられている送信のためのパラメータの第２のセットとを含むＰＵＣＣＨコンフィギュレーションを受信してもよい。
【０１５４】
［００１６６］
図１２中でさらに示されているように、いくつかの態様では、プロセス１２００は、アップリンク制御情報（ＵＣＩ）を発生させることを含んでいてもよい（ブロック１２２０）。例えば、ＵＥは（例えば、送信プロセッサ２６４、制御装置／プロセッサ２８０、メモリ２８２、および／または、これらに類するものを使用して）、上記で説明したように、ＵＣＩを発生させてもよい。
【０１５５】
［００１６７］
図１２中でさらに示されているように、いくつかの態様では、プロセス１２００は、ＰＵＣＣＨコンフィギュレーションとメッセージのサービスタイプとにしたがって、ＵＣＩを含むメッセージを送信することを含んでいてもよい（ブロック１２３０）。例えば、ＵＥは（例えば、送信プロセッサ２６４、制御装置／プロセッサ２８０、メモリ２８２、および／または、これらに類するものを使用して）、上記で説明したように、ＰＵＣＣＨコンフィギュレーションとメッセージのサービスタイプとにしたがって、ＵＣＩを含むメッセージを送信してもよい。
【０１５６】
［００１６８］
プロセス１２００は、以下で説明する、任意の単一の態様または態様の任意の組み合わせ、および／または、ここでの他の箇所で説明する１つ以上の他のプロセスに関連するような、追加の態様を含んでいてもよい。
【０１５７】
［００１６９］
第１の態様では、メッセージのサービスタイプは、基地局から受信したダウンリンク制御情報（ＤＣＩ）に少なくとも部分的に基づいて決定される。
【０１５８】
［００１７０］
第２の態様では、単独で、または、第１の態様と組み合わせて、パラメータの第１のセットによって示される最大コーディングレートは、パラメータの第２のセットによって示される最大コーディングレートとは異なる。
【０１５９】
［００１７１］
図１２は、プロセス１２００の例示的なブロックを示しているが、いくつかの態様では、プロセス１２００は、追加のブロック、より少ないブロック、異なるブロック、または、図１２中に描いたものとは異なって構成されているブロックを含んでいてもよい。追加的にまたは代替的に、プロセス１２００のブロックのうちの２つ以上を並列に実行してもよい。
【０１６０】
［００１７２］
図１３は、本開示のさまざまな態様にしたがう、例えば、基地局によって実行される例示的なプロセス１３００を図示しているダイヤグラムである。例示的なプロセス１３００は、ＢＳ（例えば、ＢＳ１１０および／またはこれらに類するもの）が複数のタイプのサービス（例えば、ｅＭＢＢおよびＵＲＬＬＣ）に対してＰＵＣＣＨコンフィギュレーションを実行する例である。
【０１６１】
［００１７３］
図１３中で示されているように、いくつかの態様では、プロセス１３００は、第１のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨの第１のコンフィギュレーションを決定することを含んでいてもよい（ブロック１３１０）。例えば、ＢＳ１１０は（例えば、送信プロセッサ２２０、ＴＸ  ＭＩＭＯプロセッサ２３０、制御装置／プロセッサ２４０、および／または、これらに類するものを使用して）、上記で説明したように、第１のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨの第１のコンフィギュレーションを決定してもよい。いくつかの態様では、ＵＥ１２０が第１のタイプのサービスを介して通信することが可能であるという表示を受信することに関連して、ＢＳ１１０は第１のコンフィギュレーションを決定してもよい。
【０１６２】
［００１７４］
図１３中で示されているように、いくつかの態様では、プロセス１３００は、第２のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨリソースの第２のコンフィギュレーションを決定し、第２のタイプのサービスは、第１のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることを含んでいてもよい（ブロック１３２０）。例えば、ＢＳ１１０は（例えば、送信プロセッサ２２０、ＴＸ  ＭＩＭＯプロセッサ２３０、制御装置／プロセッサ２４０、および／または、これらに類するものを使用して）、上記で説明したように、第２のタイプのサービスに関係付けられているＰＵＣＣＨ送信のために使用されることになるＰＵＣＣＨの第２のコンフィギュレーションを決定してもよい。いくつかの態様では、第２のタイプのサービスは、第１のタイプのサービスのよりもより高い信頼性またはより低いレイテンシに関係付けられている。いくつかの態様では、ＵＥ１２０が第２のタイプのサービスを介して通信することが可能であるという表示を受信することに関連して、ＢＳ１１０は第２のコンフィギュレーションを決定してもよい。
【０１６３】
［００１７５］
図１３中で示されているように、いくつかの態様では、プロセス１３００は、第１のコンフィギュレーションと第２のコンフィギュレーションとをユーザ機器（ＵＥ）に送信することを含んでいてもよい（ブロック１３３０）。例えば、ＢＳ１１０は（例えば、送信プロセッサ２２０、ＴＸ  ＭＩＭＯプロセッサ２３０、変調器２３２、アンテナ２３４、制御装置／プロセッサ２４０、および／または、これらに類するものを使用して）、上記で説明したように、第１のコンフィギュレーションと第２のコンフィギュレーションとをＵＥ１２０に送信してもよい。いくつかの態様では、ＢＳ１１０は、第１のコンフィギュレーションと第２のコンフィギュレーションとを決定することに関連して、第１のコンフィギュレーションと第２のコンフィギュレーションとを送信してもよい。
【０１６４】
［００１７６］
プロセス１３００は、以下で説明する、任意の単一の態様または態様の任意の組み合わせ、および／または、ここでの他の箇所で説明する１つ以上の他のプロセスに関連するような、追加の態様を含んでいてもよい。
【０１６５】
［００１７７］
第１の態様において、第１のタイプのサービスは、拡張移動体ブロードバンド（ｅＭＢＢ）サービスを含み、第２のタイプのサービスは、超高信頼性低レイテンシ通信（ＵＲＬＬＣ）サービスを含んでいる。
【０１６６】
［００１７８］
第２の態様では、単独で、または、第１の態様と組み合わせて、ＰＵＣＣＨの第１のコンフィギュレーションの最大コーディングレートは、第２のＰＵＣＣＨコンフィギュレーションの最大コーディングレートとは異なる。
【０１６７】
［００１７９］
図１３は、プロセス１３００の例示的なブロックを示しているが、いくつかの態様では、プロセス１３００は、追加のブロック、より少ないブロック、異なるブロック、または、図１３中に描いたものとは異なって構成されているブロックを含んでいてもよい。追加的にまたは代替的に、プロセス１３００のブロックのうちの２つ以上を並列に実行してもよい。
【０１６８】
［００１８０］
上記の開示は、実例および説明を提供するが、網羅的であること、または、態様を開示した厳密な形態に限定することを意図するものではない。修正およびバリエーションは、上記の開示に照らして行われてもよく、または、態様の実施から取得してもよい。
【０１６９】
［００１８１］
ここで使用するように、コンポーネントという用語は、ハードウェア、ファームウェア、または、ハードウェアとソフトウェアとの組み合わせとして広く解釈されるように意図されている。ここで使用するように、プロセッサは、ハードウェア、ファームウェア、または、ハードウェアとソフトウェアとの組み合わせで実現してもよい。
【０１７０】
［００１８２］
ここで使用するように、しきい値を満たすことは、しきい値よりも大きい、しきい値以上、しきい値未満、しきい値以下、しきい値に等しい、しきい値に等しくない、および／または、これらに類するものである値を指していてもよい。
【０１７１】
［００１８３］
ここで説明するシステムおよび／または方法は、ハードウェア、ファームウェア、または、ハードウェアとソフトウェアとの組み合わせの異なる形態で実現してもよいことが明らかになるだろう。これらのシステムおよび／または方法を実現するために使用される実際の専門制御ハードウェアまたはソフトウェアコードは、態様を限定しない。したがって、システムおよび／または方法の動作および挙動は、特定のソフトウェアコードを参照することなくここで説明されており、ソフトウェアおよびハードウェアは、ここでの説明に少なくとも部分的に基づいて、システムおよび／または方法を実現するように設計できることを理解されたい。
【０１７２】
［００１８４］
特徴の特定の組み合わせが特許請求の範囲に記載され、および／または、本明細書に開示されているが、これらの組み合わせは、さまざまな態様の開示を限定するように意図されていない。実際、これらの特徴の多くは、特許請求の範囲に具体的に記載されていない、および／または、本明細書に開示されていない方法で組み合わせてもよい。以下にリストアップされる各従属請求項は、１つの請求項のみに直接従属しているかもしれないが、さまざまな態様の開示は、請求項セット中の他のあらゆる請求項と組み合わせた各従属請求項を含んでいる。アイテムのリストのうちの「少なくとも１つ」に言及するフレーズは、単一の要素を含む、それらのアイテムのうちの任意の組み合わせに言及する。例として、「ａ、ｂ、または、ｃのうちの少なくとも１つ」は、ａ、ｂ、ｃ、ａ−ｂ、ａ−ｃ、ｂ−ｃ、および、ａ−ｂ−ｃとともに、複数の同じ要素の任意の組み合わせ（例えば、ａ−ａ、ａ−ａ−ａ、ａ−ａ−ｂ、ａ−ａ−ｃ、ａ−ｂ−ｂ、ａ−ｃ−ｃ、ｂ−ｂ、ｂ−ｂ−ｂ、ｂ−ｂ−ｃ、ｃ−ｃ、および、ｃ−ｃ−ｃ、または、ａ、ｂ、および、ｃの他の何らかの順序）をカバーするように意図されている。
【０１７３】
［００１８５］
ここで使用される要素、動作、または、命令は、そのように明示的に説明されていない限り、重要または不可欠であるとして解釈すべきではない。また、ここで使用されるように、冠詞「ａ」および「ａｎ」は、１つ以上のアイテムを含むように意図され、「１つ以上」と交換可能に使用されているかもしれない。さらに、ここで使用されるように、「セット」および「グループ」という用語は、１つ以上のアイテム（例えば、関連アイテム、非関連アイテム、関連アイテムと非関連アイテムの組み合わせ、および／または、これらに類するもの）を含むように意図され、「１つ以上」と交換可能に使用されているかもしれない。１つのアイテムのみが意図される場合、用語「１つのみ」または同様の言葉が使用される。また、ここで使用されるように、「有する（ｈａｓ）」、「有する（ｈａｖｅ）」、「有している（ｈａｖｉｎｇ）」、および／または、これらに類するもののような用語は、拡張可能な用語であるように意図されている。さらに、「に基づいて」というフレーズは、別な方法で明示的に述べられていない限り、「に少なくとも部分的に基づいて」を意味するように意図されている。
【図１】
2021523617.tif 000004
【図２】
2021523617.tif 000005
【図３Ａ】
2021523617.tif 000006
【図３Ｂ】
2021523617.tif 000007
【図４】
2021523617.tif 000008
【図５】
2021523617.tif 000009
【図６】
2021523617.tif 000010
【図７】
2021523617.tif 000011
【図８】
2021523617.tif 000012
【図９】
2021523617.tif 000013
【図１０】
2021523617.tif 000014
【図１１】
2021523617.tif 000015
【図１２】
2021523617.tif 000016
【図１３】
2021523617.tif 000017
【国際調査報告】
2021523617.tif 000018
2021523617.tif 000019
2021523617.tif 000020
2021523617.tif 000021