JP7206296B2 - 超高信頼性低レイテンシ通信(urllc)に対する物理アップリンク制御チャネル(pucch)リソース割り振り - Google Patents

超高信頼性低レイテンシ通信(urllc)に対する物理アップリンク制御チャネル(pucch)リソース割り振り Download PDF

Info

Publication number
JP7206296B2
JP7206296B2 JP2020562689A JP2020562689A JP7206296B2 JP 7206296 B2 JP7206296 B2 JP 7206296B2 JP 2020562689 A JP2020562689 A JP 2020562689A JP 2020562689 A JP2020562689 A JP 2020562689A JP 7206296 B2 JP7206296 B2 JP 7206296B2
Authority
JP
Japan
Prior art keywords
service
type
resources
pucch
pucch transmission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020562689A
Other languages
English (en)
Other versions
JP2021523617A (ja
JPWO2019217696A5 (ja
Inventor
ヤン、ウェイ
ジャン、ジン
ファン、イー
ワン、レンチウ
チェン、ワンシ
ガール、ピーター
リ、チ-ピン
ジ、ティンファン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2021523617A publication Critical patent/JP2021523617A/ja
Publication of JPWO2019217696A5 publication Critical patent/JPWO2019217696A5/ja
Application granted granted Critical
Publication of JP7206296B2 publication Critical patent/JP7206296B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/003Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053Allocation of signaling, i.e. of overhead other than pilot signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/003Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055Physical resource allocation for ACK/NACK
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0017Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy where the mode-switching is based on Quality of Service requirement
    • H04L1/0018Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy where the mode-switching is based on Quality of Service requirement based on latency requirement
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/0091Signaling for the administration of the divided path
    • H04L5/0092Indication of how the channel is divided
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • H04W72/21Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • H04W72/23Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • H04W72/23Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H04W72/232Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal the control data signalling from the physical layer, e.g. DCI signalling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/50Allocation or scheduling criteria for wireless resources
    • H04W72/535Allocation or scheduling criteria for wireless resources based on resource usage policies

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

米国特許法第119条に基づく関連出願への相互参照
[0001]
本出願は、「超高信頼性低レイテンシ通信(URLLC)に対する物理アップリンク制御チャネル(PUCCH)リソースを割り振るための技術および装置」と題される、2018年5月10日に出願された米国仮特許出願番号第62/669,941号、および、「超高信頼性低レイテンシ通信(URLLC)に対する物理アップリンク制御チャネル(PUCCH)リソース割り振り」と題される、2019年5月8日に出願された米国非仮特許出願第16/406,667号に対する優先権を主張し、これらは、参照によりここに明示的に組み込まれている。
開示の分野
[0002]
本開示の態様は、一般的にワイヤレス通信に関連し、超高信頼性低レイテンシ通信(URLLC)に対する物理アップリンク制御チャネル(PUCCH)リソースを割り振るための技術および装置に関連する。
背景
[0003]
ワイヤレス通信システムは、電話、ビデオ、データ、メッセージング、および、ブロードキャストのようなさまざまな電気通信サービスを提供するために広く配備されている。典型的なワイヤレス通信システムは、(例えば、帯域幅、送信電力、および/または、これらに類するもののような)利用可能なシステムリソースを共有することによって、複数のユーザとの通信をサポートすることができる多元接続テクノロジーを用いるかもしれない。このような多元接続テクノロジーの例は、コード分割多元接続(CDMA)システム、時分割多元接続(TDMA)システム、周波数分割多元接続(FDMA)システム、直交周波数分割多元接続(OFDMA)システム、単一搬送波周波数分割多元接続(SC-FDMA)システム、時分割同期コード分割多元接続(TD-SCDMA)システム、および、ロングタームエボリューション(LTE(登録商標))を含んでいる。LTE/LTEアドバンストは、第3世代パートナーシッププロジェクト(3GPP(登録商標))によって公表されたユニバーサル移動体電気通信システム(UMTS)の移動体標準規格への拡張のセットである。
[0004]
ワイヤレス通信ネットワークは、多数のユーザ機器(UE)のための通信をサポートすることができる多数の基地局(BS)を含んでいてもよい。ユーザ機器(UE)は、ダウンリンクおよびアップリンクを介して、基地局(BS)と通信してもよい。ダウンリンク(または、フォワードリンク)は、BSからUEへの通信リンクを指し、アップリンク(または、リバースリンク)は、UEからBSへの通信リンクを指している。ここでより詳細に説明するように、BSは、ノードB、gNB、アクセスポイント(AP)、無線ヘッド、送受信ポイント(TRP)、新たな無線(NR)BS、5GノードB、および/または、これらに類するものとして呼ばれることがある。
[0005]
上記の多元接続テクノロジーは、異なるユーザ機器が市区町村レベル、国レベル、地域レベル、さらにはグローバルレベルで通信できるようにする共通のプロトコルを提供するために、さまざまな電気通信標準規格に採用されている。5Gとしても呼ばれることがある新たな無線(NR)は、第3世代パートナーシッププロジェクト(3GPP)によって公表されたLTE移動体標準規格に対する拡張のセットである。NRは、スペクトル効率を改善することと、コストを下げることと、サービスを改善することと、新たなスペクトルを使用することと、ダウンリンク(DL)でサイクリックプリフィックス(CP)を有する直交周波数分割多重化(OFDMA)(CP-OFDM)を使用し、アップリンク(UL)上で(例えば、離散フーリエ変換拡散OFDM(DFT-s-OFDM)としても知られている)CP-OFDMおよび/またはSC-FDMを使用して、他のオープン標準規格とより良く統合するとともに、ビーム形成、複数入力複数出力(MIMO)アンテナテクノロジー、および、搬送波アグリゲーションをサポートすることにより、移動体ブロードバンドインターネットアクセスをより良くサポートするように設計されている。しかしながら、移動体ブロードバンドアクセスのための需要が増え続けると、LTEおよびNRテクノロジーにおけるさらなる改善に対する必要性が存在する。好ましくは、これらの改善は、これらのテクノロジーを用いる他の多元接続テクノロジーと電気通信標準規格とに適用可能であるべきである。
概要
[0006]
いくつかの態様では、UEによって実行されるワイヤレス通信の方法は、物理アップリンク制御チャネル(PUCCH)送信が第1のタイプのサービスに関係付けられているかまたは第2のタイプのサービスに関係付けられているかを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることと、PUCCH送信が第1のタイプのサービスに関係付けられているとき、リソースの第1のセットを使用して、または、PUCCH送信が第2のタイプのサービスに関係付けられているとき、リソースの第2のセットを使用して、PUCCH送信を送信することとを含んでいてもよい。
[0007]
いくつかの態様では、ワイヤレス通信のためのUEは、メモリと、メモリに結合されている1つ以上のプロセッサとを含んでいてもよい。メモリおよび1つ以上のプロセッサは、PUCCH送信が第1のタイプのサービスに関係付けられているかまたは第2のタイプのサービスに関係付けられているかを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられるように、PUCCH送信が第1のタイプのサービスに関係付けられているとき、リソースの第1のセットを使用して、または、PUCCH送信が第2のタイプのサービスに関係付けられているとき、リソースの第2のセットを使用して、PUCCH送信を送信するように構成されていてもよい。
[0008]
いくつかの態様では、非一時的コンピュータ読取可能媒体は、ワイヤレス通信のための1つ以上の命令を記憶していてもよい。1つ以上の命令は、UEの1つ以上のプロセッサによって実行されるとき、1つ以上のプロセッサに、PUCCH送信が第1のタイプのサービスに関係付けられているかまたは第2のタイプのサービスに関係付けられているかを決定させ、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられ、PUCCH送信が第1のタイプのサービスに関係付けられているとき、リソースの第1のセットを使用させて、または、PUCCH送信が第2のタイプのサービスに関係付けられているとき、リソースの第2のセットを使用させて、PUCCH送信を送信させてもよい。
[0009]
いくつかの態様では、ワイヤレス通信のための装置は、PUCCH送信が第1のタイプのサービスに関係付けられているかまたは第2のタイプのサービスに関係付けられているかを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられる手段と、PUCCH送信が第1のタイプのサービスに関係付けられているとき、リソースの第1のセットを使用して、または、PUCCH送信が第2のタイプのサービスに関係付けられているとき、リソースの第2のセットを使用して、PUCCH送信を送信する手段とを含んでいてもよい。
[0010]
いくつかの態様では、UEによって実行されるワイヤレス通信の方法は、第1のサービスタイプに関係付けられている送信のためのパラメータの第1のセットと、第2のサービスタイプに関係付けられている送信のためのパラメータの第2のセットとを含むPUCCHコンフィギュレーションを受信することと、アップリンク制御情報(UCI)を発生させることと、PUCCHコンフィギュレーションとメッセージのサービスタイプとにしたがって、UCIを含むメッセージを送信することとを含んでいてもよい。
[0011]
いくつかの態様では、ワイヤレス通信のためのUEは、メモリと、メモリに結合されている1つ以上のプロセッサとを含んでいてもよい。メモリおよび1つ以上のプロセッサは、第1のサービスタイプに関係付けられている送信のためのパラメータの第1のセットと、第2のサービスタイプに関係付けられている送信のためのパラメータの第2のセットとを含むPUCCHコンフィギュレーションを受信するように、UCIを発生させるように、PUCCHコンフィギュレーションとメッセージのサービスタイプとにしたがって、UCIを含むメッセージを送信するように構成されていてもよい。
[0012]
いくつかの態様では、非一時的コンピュータ読取可能媒体は、ワイヤレス通信のための1つ以上の命令を記憶していてもよい。1つ以上の命令は、UEの1つ以上のプロセッサによって実行されるとき、1つ以上のプロセッサに、第1のサービスタイプに関係付けられている送信のためのパラメータの第1のセットと、第2のサービスタイプに関係付けられている送信のためのパラメータの第2のセットとを含むPUCCHコンフィギュレーションを受信させ、UCIを発生させ、PUCCHコンフィギュレーションとメッセージのサービスタイプとにしたがって、UCIを含むメッセージを送信させてもよい。
[0013]
いくつかの態様では、ワイヤレス通信のための装置は、第1のサービスタイプに関係付けられている送信のためのパラメータの第1のセットと、第2のサービスタイプに関係付けられている送信のためのパラメータの第2のセットとを含むPUCCHコンフィギュレーションを受信する手段と、UCIを発生させる手段と、PUCCHコンフィギュレーションとメッセージのサービスタイプとにしたがって、UCIを含むメッセージを送信する手段とを含んでいてもよい。
[0014]
いくつかの態様では、基地局によって実行されるワイヤレス通信の方法は、第1のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを決定することと、第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることと、第1のコンフィギュレーションと第2のコンフィギュレーションとをUEに送信することとを含んでいてもよい。
[0015]
いくつかの態様では、ワイヤレス通信のための基地局は、メモリと、メモリに結合されている1つ以上のプロセッサとを含んでいてもよい。メモリおよび1つ以上のプロセッサは、第1のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを決定するように、第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられているように、第1のコンフィギュレーションと第2のコンフィギュレーションとをUEに送信するように構成されていてもよい。
[0016]
いくつかの態様では、非一時的コンピュータ読取可能媒体は、ワイヤレス通信のための1つ以上の命令を記憶していてもよい。1つ以上の命令は、基地局の1つ以上のプロセッサによって実行されるとき、1つ以上のプロセッサに、第1のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを決定させ、第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定させ、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられ、第1のコンフィギュレーションと第2のコンフィギュレーションとをUEに送信させてもよい。
[0017]
いくつかの態様では、ワイヤレス通信のための装置は、第1のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを決定する手段と、第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられている手段と、第1のコンフィギュレーションと第2のコンフィギュレーションとをUEに送信する手段とを含んでいてもよい。
[0018]
態様は、一般的に、添付の図面と明細書とを参照してここで実質的に説明し、添付の図面によって図示されているような、方法、装置、システム、コンピュータプログラム製品、非一時的コンピュータ読取可能媒体、ユーザ機器、基地局、ワイヤレス通信デバイス、および/または、処理システムを含んでいる。
[0019]
前述は、以下の詳細な説明がより良く理解されるように、本開示にしたがう例の特徴および技術的利点をどちらかといえば広く概説している。追加の特徴および利点を以下に説明する。開示される概念および特定の例を、本開示の同じ目的を実行する他の構造を修正または設計するためのベースとして容易に利用できる。このような均等な構造は、添付の特許請求の範囲の範囲から逸脱しない。ここで説明する概念の特性、それらの構成および動作の方法の両方、ならびに、関係する利点は、添付の図に関連して考慮されるとき、以下の説明からより良く理解されるだろう。図のそれぞれは、実例および説明の目的のために提供されており、特許請求の範囲の限定の定義として提供されているものではない。
[0020]
本開示の先に記載した特徴を詳細に理解できるように、上で簡単に要約されたもののより特定の説明が、態様への参照によって得られてもよく、態様のうちのいくつかは、添付した図面に図示されている。しかしながら、添付図面はこの開示のある典型的な態様を図示しているに過ぎず、したがって、説明は他の等しく有効な態様を許すことから、範囲を限定するものとして添付図面を解釈してはならないことに留意すべきである。異なる図面における同じ参照番号は、同じまたは同様の要素を識別しているかもしれない。
[0021] 図1は、本開示のさまざまな態様にしたがう、ワイヤレス通信ネットワークの例を概念的に図示するブロックダイヤグラムである。 [0022] 図2は、本開示のさまざまな態様にしたがう、ワイヤレス通信ネットワーク中でユーザ機器(UE)と通信する基地局の例を概念的に図示するブロックダイヤグラムである。 [0023] 図3Aは、本開示のさまざまな態様にしたがう、ワイヤレス通信ネットワーク中のフレーム構造の例を概念的に図示するブロックダイヤグラムである。 [0024] 図3Bは、本開示のさまざまな態様にしたがう、ワイヤレス通信ネットワーク中の例示的な同期通信階層を概念的に図示するブロックダイヤグラムである。 [0025] 図4は、本開示のさまざまな態様にしたがう、ノーマルサイクリックプリフィックスを有する例示的なスロットフォーマットを概念的に図示するブロックダイヤグラムである。 [0026] 図5は、本開示のさまざまな態様にしたがう、ダウンリンク(DL)中心スロットの例を図示するダイヤグラムである。 [0027] 図6は、本開示のさまざまな態様にしたがう、アップリンク(UL)中心スロットの例を図示するダイヤグラムである。 [0028] 図7は、本開示のさまざまな態様にしたがう、超高信頼性低レイテンシ通信(URLLC)に対する物理アップリンク制御チャネル(PUCCH)リソースを割り振る例を図示するダイヤグラムである。 図8は、本開示のさまざまな態様にしたがう、超高信頼性低レイテンシ通信(URLLC)に対する物理アップリンク制御チャネル(PUCCH)リソースを割り振る例を図示するダイヤグラムである。 図9は、本開示のさまざまな態様にしたがう、超高信頼性低レイテンシ通信(URLLC)に対する物理アップリンク制御チャネル(PUCCH)リソースを割り振る例を図示するダイヤグラムである。 [0029] 図10は、本開示のさまざまな態様にしたがう、例えば、ユーザ機器によって実行される例示的なプロセスを図示するダイヤグラムである。 [0030] 図11は、本開示のさまざまな態様にしたがう、例えば、基地局によって実行される例示的なプロセスを図示するダイヤグラムである。 [0031] 図12は、本開示のさまざまな態様にしたがう、例えば、ユーザ機器によって実行される例示的なプロセスを図示するダイヤグラムである。 [0032] 図13は、本開示のさまざまな態様にしたがう、例えば、基地局によって実行される例示的なプロセスを図示するダイヤグラムである。
詳細な説明
[0033]
添付図面を参照して、本開示のさまざまな態様を以下により詳細に説明する。しかしながら、この開示は多くの異なる形式で具現化されてもよく、この開示全体に渡たって提示されるいずれかの特定の構造や機能に限定されるものと解釈すべきでない。むしろ、本開示が、徹底して完全なものになるように、そして、本開示の範囲を当業者に十分に伝えるために、これらの態様を提供する。本発明の他の何らかの態様から独立して実現するかまたは本発明の他の何らかの態様と組み合わせて実現するかにかかわらず、本開示の範囲が、ここで開示する本開示の任意の態様をカバーするように意図されていることを、ここでの教示に少なくも部分的に基づいて、当業者は認識すべきである。例えば、ここで述べる任意の数の態様を使用して、装置を実現してもよく、または、方法を実施してもよい。さらに、ここで述べる本開示のさまざまな態様に加えて、または、ここで述べる開示のさまざまな態様以外の、他の構造を、機能性を、または、構造および機能性を使用して実施されるこのような装置または方法をカバーすることを、本開示の範囲は意図している。ここに開示されている本開示の任意の態様は、請求項の1つ以上の要素によって具現化してもよいことを理解すべきである。
[0034]
電気通信システムのいくつかの態様が、さまざまな装置および技術を参照して提示されることになる。これら装置および技術は、以下の詳細な説明で説明され、添付の図面中で、さまざまなブロック、モジュール、コンポーネント、回路、ステップ、プロセス、アルゴリズム、および/または、これらに類するもの(集合的に「要素」として呼ばれる)により図示されている。これらの要素は、ハードウェア、ソフトウェア、または、それらの組み合わせを使用して実現してもよい。このような要素をハードウェアまたはソフトウェアとして実現するかは、システム全体に課せられている特定のアプリケーションおよび設計の制約に依存する。
[0035]
3Gおよび/または4Gワイヤレステクノロジーに共通して関係付けられている専門用語を使用して、ここでは態様を説明しているが、本開示の態様は、NRテクノロジーを含む、5Gおよびその後のもののような、他世代ベースの通信システムに適用することができることに留意すべきである。
[0036]
図1は、本開示の態様を実施してもよいネットワーク100を図示しているダイヤグラムである。ネットワーク100は、LTEネットワーク、あるいは、5GまたはNRネットワークのような他の何らかのワイヤレスネットワークであってもよい。ワイヤレスネットワーク100は、(BS110a、BS110b、BS110c、および、BS110dとして示されている)多数のBS110と、他のネットワークエンティティとを含んでいてもよい。BSは、ユーザ機器(UE)と通信するエンティティであり、基地局、NR BS、ノードB、gNB、5GノードB(NB)、アクセスポイント、送受信ポイント(TRP)、および/または、これらに類するものとして呼ばれることもある。各BSは、特定の地理的エリアのための通信カバレッジを提供していてもよい。3GPPにおいて、用語「セル」は、用語が使用される文脈に依存して、このカバレッジエリアを担当しているBSおよび/またはBSサブシステムのカバレッジエリアを指すことがある。
[0037]
BSは、マクロセル、ピコセル、フェムトセル、および/または、別のタイプのセルに対する通信カバレッジを提供してもよい。マクロセルは、比較的大きい地理的エリア(例えば、半径数キロメートル)をカバーし、サービス加入を有するUEによる無制限のアクセスを可能にしていてもよい。ピコセルは、比較的狭い地理的エリアをカバーし、サービス加入を有するUEによる無制限のアクセスを可能にしていてもよい。フェムトセルは、比較的小さい地理的エリア(例えば、家)をカバーし、フェムトセルとの関係を有するUE(例えば、閉じられた加入者グループ(CSG)中のUE)による制限されたアクセスを可能にしていてもよい。マクロセルに対するBSは、マクロBSとして呼ばれることがある。ピコセルに対するBSは、ピコBSとして呼ばれることがある。フェムトセルに対するBSは、フェムトBSまたはホームBSとして呼ばれることがある。図1中で示されている例において、BS110aは、マクロセル102aのためのマクロBSであってもよく、BS110bは、ピコセル102bのためのピコBSであってもよく、BS110cは、フェムトセル102cのためのフェムトBSであってもよい。BSは、1つ以上(例えば、3つ)のセルをサポートしてもよい。「eNB」、「基地局」、「NR BS」、「gNB」、「TRP」、「AP」、「ノードB」、「5G NB」、および「セル」という用語は、ここでは交換可能に使用されているかもしれない。
[0038]
いくつかの例において、セルは、必ずしも静的でなくてもよく、セルの地理的エリアは、移動体BSのロケーションにしたがって移動してもよい。いくつかの態様では、直接的な物理接続、仮想ネットワーク、および/または、任意の適切な伝送ネットワークを使用するこれらに類するもののような、さまざまなタイプのバックホールインターフェースを通して、BSは、アクセスネットワーク100中の、1つの別のBSおよび/または1つ以上の他のBSあるいは(示していない)ネットワークノードとに相互接続されていてもよい。
[0039]
ワイヤレスネットワーク100はまた、中継局を含んでいてもよい。中継局は、アップストリーム局(例えば、BSまたはUE)からのデータの送信を受信でき、ダウンストリーム局(例えば、UEまたはeBS)へのデータの送信を送ることができるエンティティである。中継局はまた、他のUEに対する送信を中継できるUEであってもよい。図1中で示されている例において、中継局110dは、BS110aとUE120dとの間の通信を促進するために、マクロBS110aおよびUE120dと通信してもよい。中継局は、中継BS、中継基地局、中継器、および/または、これらに類するものとして呼ばれることもある。
[0040]
ワイヤレスネットワーク100は、異なるタイプのBS、例えば、マクロBS、ピコBS、フェムトBS、中継BS、および/または、これらに類するものを含む、ヘテロジニアスネットワークであってもよい。これらの異なるタイプのBSは、ワイヤレスネットワーク100において、異なる送信電力レベル、異なるカバレッジエリア、および、干渉に対する異なる影響を有してもよい。例えば、マクロBSは、高い送信電力レベル(例えば、5から40ワット)を有している一方で、ピコBS、フェムトBS、および、中継BSは、より低い送信電力レベル(例えば、0.1から2ワット)を有していてもよい。
[0041]
ネットワーク制御装置130は、BSのセットに結合され、これらのBSに対する調整および制御を提供してもよい。ネットワーク制御装置130は、バックホールを介してBSと通信してもよい。BSはまた、例えば、直接的に、あるいは、ワイヤレスまたはワイヤラインのバックホールを介して間接的に、互いに通信してもよい。
[0042]
UE120(例えば、120a、120b、120c)は、ワイヤレスネットワーク100全体を通して分散していてもよく、各UEは、静的または移動性であってもよい。UEは、アクセス端末、端末、移動局、加入者ユニット、局、および/または、これらに類するものとしても呼ばれることがある。UEは、セルラ電話機(スマートフォン)、パーソナルデジタルアシスタント(PDA)、ワイヤレスモデム、ワイヤレス通信デバイス、ハンドヘルドデバイス、ラップトップコンピュータ、コードレス電話機、ワイヤレスローカルループ(WLL)局、タブレット、カメラ、ゲーミングデバイス、ネットブック、スマートブック、ウルトラブック、医療デバイスまたは医療機器、生体センサ/デバイス、ウェアラブルデバイス(スマートウォッチや、スマートクロージングや、スマートグラスや、スマートリストバンドや、スマートジュエリー(例えば、スマートリング、スマートブレスレット))、エンターテイメントデバイス(例えば、音楽またはビデオデバイス、あるいは、衛星ラジオ)、車両コンポーネントまたはセンサ、スマートメーター/センサ、産業製造機器、グローバルポジショニングシステムデバイス、あるいは、ワイヤレスまたはワイヤード媒体を介して通信するように構成されている他の何らかの適切なデバイスであってもよい。
[0043]
いくつかのUEは、マシンタイプ通信(MTC)、あるいは、進化型または拡張マシンタイプ通信(eMTC)UEと見なしてもよい。MTCおよびeMTC UEは、基地局、別のデバイス(例えば、遠隔デバイス)、または、他の何らかのエンティティと通信してもよい、例えば、ロボット、ドローン、遠隔デバイス、センサ、メーター、モニタ、ロケーションタグ、および/または、これらに類するものを含んでいる。ワイヤレスノードは、例えば、ワイヤードまたはワイヤレス通信リンクを介して、ネットワーク(例えば、インターネットまたはセルラネットワークのようなワイドエリアネットワーク)のための、あるいは、ネットワークへの接続性を提供してもよい。いくつかのUEをインターネットオブシングス(IoT)デバイスと見なしてもよく、および/または、NB-IoT(狭帯域インターネットオブシングス)デバイスとして実現してもよい。いくつかのUEは、顧客構内機器(CPE)と見なしてもよい。UE120は、プロセッサコンポーネント、メモリコンポーネント、および/または、これらに類するもののような、UE120のコンポーネントを収容するハウジング内に含まれていてもよい。
[0044]
一般的には、任意の数のワイヤレスネットワークが所定の地理的エリアに配備されていてもよい。各ワイヤレスネットワークは、特定のRATをサポートしてもよく、1つ以上の周波数で動作してもよい。RATはまた、無線テクノロジー、エアインターフェース、および/または、これらに類するものとして呼ばれることがある。周波数はまた、搬送波、周波数チャネル、および/または、これらに類するものとして呼ばれることがある。各周波数は、異なるRATのワイヤレスネットワーク間の干渉を避けるために、所定の地理的エリアにおいて、単一のRATをサポートしてもよい。いくつかのケースでは、NRまたは5G RATネットワークが配備されていてもよい。
[0045]
いくつかの態様では、(例えば、UE120aおよびUE120eとして示されている)2つ以上のUE120は、(例えば、互いに通信するための媒介として基地局110を使用せずに)1つ以上のサイドリンクチャネルを使用して、直接通信してもよい。例えば、UE120は、ピアツーピア(P2P)通信、デバイスツーデバイス(D2D)通信、ビークルツーエブリシング(V2X)プロトコル(例えば、これは、ビークルツービークル(V2V)プロトコル、ビークルツーインフラストラクチャ(V2I)プロトコル、および/または、これらに類するものを含んでいてもよい)、メッシュネットワーク、ならびに/あるいは、これらに類するものを使用して通信してもよい。このケースでは、UE120は、スケジューリング動作、リソース選択動作、および/または、基地局110によって実行されるものとしてここでの他の箇所で説明する他の動作を実行してもよい。
[0046]
上記で示したように、図1は単なる例として提供されている。他の例は、図1に関して説明したものと異なっていてもよい。
[0047]
図2は、基地局110およびUE120の設計200のブロックダイヤグラムを示し、これらは、図1における基地局のうちの1つ、および、UEのうちの1つであってもよい。基地局110は、T本のアンテナ234aないし234tを装備していてもよく、UE120は、R本のアンテナ252aないし252rを装備していてもよく、一般的に、T≧1であり、R≧1である。
[0048]
基地局110において、送信プロセッサ220は、1つ以上のUEのためにデータソース212からデータを受け取り、UEから受け取ったチャネル品質インジケータ(CQI)に少なくとも部分的に基づいて、各UEに対して1つ以上の変調およびコーディングスキーム(MCS)を選択し、UEに対して選択したMCSに少なくとも部分的に基づいて、各UEに対するデータを処理(例えば、エンコードして変調)し、すべてのUEに対してデータシンボルを提供してもよい。送信プロセッサ220はまた、(例えば、半静的リソース区分情報(SRPI)および/またはこれらに類するもののための)システム情報と、制御情報(例えば、CQI要求、許可、上位レイヤシグナリング、および/または、これらに類するもの)とを処理し、オーバーヘッドシンボルおよび制御シンボルを提供してもよい。送信プロセッサ220はまた、基準信号(例えば、セル特有基準信号(CRS))と同期信号(例えば、1次同期信号(PSS)および2次同期信号(SSS))とに対する基準シンボルを発生させてもよい。送信(TX)複数入力複数出力(MIMO)プロセッサ230は、適用可能な場合に、データシンボル、制御シンボル、オーバーヘッドシンボル、および/または、基準シンボル上で、空間処理(例えば、プリコーディング)を実行してもよく、T個の変調器(MOD)232aないし232tにT個の出力シンボルストリームを提供してもよい。各変調器232は、(例えば、OFDMおよび/またはこれらに類するもののために)それぞれの出力シンボルストリームを処理して、出力サンプルストリームを取得してもよい。各変調器232はさらに、出力サンプルストリームを処理(例えば、アナログに変換、増幅、フィルタリング、および、アップコンバート)して、ダウンリンク信号を取得する。変調器232aないし232tからのT個のダウンリンク信号はそれぞれ、T本のアンテナ234aないし234tを介して送信されてもよい。以下でより詳細に説明するさまざまな態様にしたがうと、追加の情報を伝えるために、ロケーションエンコーディングを用いて同期信号を発生させることができる。
[0049]
UE120において、アンテナ252aないし252rは、基地局110および/または他の基地局からダウンリンク信号を受信し、復調器(DEMOD)254aないし254rに受信した信号をそれぞれ提供してもよい。各復調器254は、受信した信号を調整(例えば、フィルタリング、増幅、ダウンコンバート、および、デジタル化)して、入力サンプルを取得してもよい。各復調器254はさらに、(例えば、OFDMおよび/またはこれに類するものに対する)入力サンプルを処理して、受信シンボルを取得してもよい。MIMO検出器256は、R個のすべての復調器254aないし254rから受信シンボルを取得し、適用可能な場合に、受信シンボル上でMIMO検出を実行し、検出シンボルを提供してもよい。受信プロセッサ258は、検出シンボルを処理(例えば、復調およびデコード)し、UE120に対するデコードしたデータをデータシンク260に提供し、デコードした制御情報およびシステム情報を制御装置/プロセッサ280に提供してもよい。チャネルプロセッサは、基準信号受信電力(RSRP)、受信信号強度インジケータ(RSSI)、基準信号受信品質(RSRQ)、チャネル品質インジケータ(CQI)、および/または、これらに類するものを決定してもよい。
[0050]
アップリンクにおいて、UE120では、送信プロセッサ264は、データソース262からデータを、そして、制御装置/プロセッサ280から(例えば、RSRP、RSSI、RSRQ、CQI、および/または、これらに類するものを含む報告のための)制御情報を受け取り、処理してもよい。送信プロセッサ264はまた、1つ以上の基準信号に対する基準シンボルを発生させてもよい。送信プロセッサ264からのシンボルは、適用可能な場合に、TX MIMOプロセッサ266によりプリコーディングされ、(例えば、DFT-s-OFDM、CP-OFDM、および/または、これらに類するもののために)変調器254aないし254rによりさらに処理され、基地局110に送信されてもよい。基地局110において、UE120および他のUEからのアップリンク信号は、アンテナ234により受信され、復調器232により処理され、適用可能な場合に、MIMO検出器236により検出され、受信プロセッサ238によりさらに処理されて、UE120により送られ、デコードされた、データおよび制御情報が取得されてもよい。受信プロセッサ238は、デコードされたデータをデータシンク239に提供し、デコードされた制御情報を制御装置/プロセッサ240に提供してもよい。基地局110は、通信ユニット244を含み、通信ユニット244を介してネットワーク制御装置130と通信してもよい。ネットワーク制御装置130は、通信ユニット294と、制御装置/プロセッサ290と、メモリ292とを含んでいてもよい。
[0051]
いくつかの態様では、UE120の1つ以上のコンポーネントが、ハウジング中に含まれていてもよい。基地局110の制御装置/プロセッサ240、UE120の制御装置/プロセッサ280、および/または、図2の他の何らかのコンポーネントは、ここでの他の箇所でより詳細に説明するように、超高信頼性低レイテンシ通信(URLLC)に対する物理アップリンク制御チャネル(PUCCH)リソースを割り振ることに関係付けられている1つ以上の技術を実行してもよい。例えば、基地局110の制御装置/プロセッサ240、UE120の制御装置/プロセッサ280、および/または、図2の他の何らかのコンポーネントは、例えば、図10のプロセス1000、図11のプロセス1100、図12のプロセス1200、図13のプロセス1300、および/または、ここで説明する他のプロセスの動作を実行または指示してもよい。メモリ242および282はそれぞれ、基地局110およびUE120に対する、データおよびプログラムコードを記憶していてもよい。スケジューラ246は、ダウンリンクおよび/またはアップリンクでのデータ送信のために、UEをスケジューリングしてもよい。
[0052]
いくつかの態様では、UE120は、PUCCH送信が第1のタイプのサービスに関係付けられているかまたは第2のタイプのサービスに関係付けられているかを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられている手段と、PUCCH送信が第1のタイプのサービスに関係付けられているとき、リソースの第1のセットを使用して、または、PUCCH送信が第2のタイプのサービスに関係付けられているとき、リソースの第2のセットを使用して、PUCCH送信を送信する手段と、および/または、これらに類するものを含んでいてもよい。追加的にまたは代替的に、UE120は、第1のサービスタイプに関係付けられている送信のためのパラメータの第1のセットと、第2のサービスタイプに関係付けられている送信のためのパラメータの第2のセットとを含むPUCCHコンフィギュレーションを受信する手段と、UCIを発生させる手段と、PUCCHコンフィギュレーションとメッセージのサービスタイプとにしたがって、UCIを含むメッセージを送信する手段と、および/または、これらに類するものを含んでいてもよい。いくつかの態様では、このような手段は、図2に関して説明したUE120の1つ以上のコンポーネントを含んでいてもよい。
[0053]
いくつかの態様では、基地局110は、第1のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを決定する手段と、第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられている手段と、第1のコンフィギュレーションと第2のコンフィギュレーションとをUEに送信する手段と、および/または、これらに類するものとを含んでいてもよい。いくつかの態様では、このような手段は、図2に関して説明した基地局110の1つ以上のコンポーネントを含んでいてもよい。
[0054]
上記で示したように、図2は例として提供されている。他の例は、図2に関して説明するものとは異なっていてもよい。
[0055]
図3Aは、電気通信システム(例えば、NR)におけるFDDのための例示的なフレーム構造300を示している。ダウンリンクおよびアップリンクのそれぞれに対する送信タイムラインが、無線フレーム(ときにはフレームとして呼ばれる)の単位に区分されている。各無線フレームは、予め定められている持続時間(例えば、10ミリ秒(ms))を有していてもよく、(例えば、0~Z-1のインデックスを持つ)Z(Z≧1)個のサブフレームのセットに区分されていてもよい。各サブフレームは、予め定められた持続時間(例えば、1ms)を有していてもよく、スロットのセットを含んでいてもよい(例えば、サブフレーム毎に2個のスロットが図3Aに示され、mは、0、1、2、3、4、および/または、これらに類するもののような送信に対するニューメロジーである)。各スロットは、L個のシンボル期間のセットを含んでいてもよい。例えば、各スロットは、(例えば、図3A中に示すように)14個のシンボル期間、7個のシンボル期間、および/または、別の数のシンボル期間を含んでいてもよい。サブフレームが2個のスロットを含むケース(例えば、m=1であるとき)では、サブフレームは2L個のシンボル期間を含んでいてもよく、各サブフレーム中の2L個のシンボル期間は、0~2L-1のインデックスが割り当てられていてもよい。いくつかの態様では、FDDのためのスケジューリング単位は、フレームベース、サブフレームベース、スロットベース、シンボルベース、および/または、これらに類するものであってもよい。
[0056]
いくつかの技術をフレーム、サブフレーム、スロット、および/または、これらに類するものに関してここで説明するが、これらの技術は、5G NRにおいて、「フレーム」、「サブフレーム」、「スロット」、および/または、これらに類するもの以外の用語を使用して呼ばれることがある、他のタイプのワイヤレス通信構造に等しく適用してもよい。いくつかの態様では、ワイヤレス通信構造は、ワイヤレス通信標準規格および/またはプロトコルによって定義される周期的時間限定通信単位を指していてもよい。追加的にまたは代替的に、図3A中に示すもの以外のワイヤレス通信構造の異なるコンフィギュレーションを使用してもよい。
[0057]
ある電気通信(例えば、NR)では、基地局は同期信号を送信するかもしれない。例えば、基地局は、基地局によってサポートされる各セルに対して、ダウンリンク上で、1次同期信号(PSS)、2次同期信号(SSS)、および/または、これらに類するものを送信するかもしれない。PSSおよびSSSは、セルのサーチおよび捕捉のために、UEにより使用してもよい。例えば、PSSは、シンボルタイミングを決定するためにUEによって使用されてもよく、SSSは、基地局に関係付けられている物理セル識別子と、フレームタイミングとを決定するためにUEによって使用されてもよい。基地局はまた、物理ブロードキャストチャネル(PBCH)を送信してもよい。PBCHは、UEによる初期アクセスをサポートするシステム情報のような、いくつかのシステム情報を搬送してもよい。
[0058]
いくつかの態様では、基地局は、図3Bに関して以下で説明するように、複数の同期通信(例えば、SSブロック)を含む同期通信階層(例えば、同期信号(SS)階層)にしたがって、PSS、SSS、および/または、PBCHを送信してもよい。
[0059]
図3Bは、同期通信階層の例である例示的なSS階層を概念的に図示するブロックダイヤグラムである。図3B中で示されているように、SS階層は、複数のSSバースト(SSバースト0~SSバーストB-1として識別され、Bは、基地局によって送信されるかもしれないSSバーストの反復の最大数である)を含んでいてもよい、SSバーストセットを含んでいてもよい。さらに示されているように、各SSバーストは、(SSブロック0からSSブロック(b最大_SS-1)として識別される)1つ以上のSSブロックを含んでいてもよく、b最大_SS-1は、SSバーストによって搬送できるSSブロックの最大数である。いくつかの態様では、異なるSSブロックは、異なってビーム形成してもよい。SSバーストセットは、図3B中で示されているように、Xミリ秒毎のよう、ワイヤレスノードによって周期的に送信されてもよい。いくつかの態様では、SSバーストセットは、図3B中でYミリ秒として示されている、固定または動的長を有していてもよい。
[0060]
図3B中で示されているSSバーストセットは、同期通信セットの例であり、ここで説明する技術に関連して他の同期通信セットを使用してもよい。さらに、図3B中で示されているSSブロックは、同期通信の例であり、ここで説明する技術に関連して、他の同期通信を使用してもよい。
[0061]
いくつかの態様では、SSブロックは、PSS、SSS、PBCH、ならびに/あるいは、他の同期信号(例えば、3次同期信号(TSS))および/または同期チャネルを搬送するリソースを含んでいる。いくつかの態様では、複数のSSブロックがSSバースト中に含まれ、PSS、SSS、および/または、PBCHは、SSバーストの各SSブロックに渡って同じであってもよい。いくつかの態様では、単一のSSブロックがSSバースト中に含まれていてもよい。いくつかの態様では、SSブロックは、長さが少なくとも4つのシンボル期間であってもよく、各シンボルは、(例えば、1つのシンボルを占有している)PSS、(例えば、1つのシンボルを占有している)SSS、および/または、(例えば、2つのシンボルを占有している)PBCHのうちの1つ以上を搬送する。
[0062]
いくつかの態様では、SSブロックのシンボルは、図3B中で示されているように連続的である。いくつかの態様では、SSブロックのシンボルは不連続である。同様に、いくつかの態様では、SSバーストの1つ以上のSSブロックは、1つ以上のスロットの間に、連続する無線リソース(例えば、連続するシンボル期間)中で送信してもよい。追加的にまたは代替的に、SSバーストの1つ以上のSSブロックは、不連続無線リソース中で送信してもよい。
[0063]
いくつかの態様では、SSバーストはバースト期間を有していてもよく、それによって、SSバーストのSSブロックは、バースト期間にしたがって、基地局によって送信される。言い換えれば、SSブロックは、各SSバーストの間に繰り返されてもよい。いくつかの態様では、SSバーストセットは、バーストセット周期を有していてもよく、それによって、SSバーストセットのSSバーストは、固定バーストセット周期にしたがって、基地局によって送信される。言い換えれば、SSバーストは、各SSバーストセットの間に繰り返されてもよい。
[0064]
基地局は、あるスロットにおいて、物理ダウンリンク共有チャネル(PDSCH)上でシステム情報ブロック(SIB)のようなシステム情報を送信してもよい。基地局は、スロットのC個のシンボル期間中に、物理ダウンリンク制御チャネル(PDCCH)上で制御情報/データを送信してもよく、Cは各スロットに対して構成可能であってもよい。基地局は、各スロットの残りのシンボル期間中に、PDSCH上でトラフィックデータおよび/または他のデータを送信してもよい。
[0065]
上記で示したように、図3Aおよび図3Bは例として提供されている。他の例は、図3Aおよび3Bに関して説明するものとは異なっていてもよい。
[0066]
図4は、ノーマルサイクリックプリフィックスを有する例示的なスロットフォーマット410を示している。利用可能な時間周波数リソースは、リソースブロックに区分してもよい。各リソースブロックは、1つのスロット中で副搬送波のセット(例えば、12個の副搬送波)をカバーしていてもよく、多数のリソース要素を含んでいてもよい。各リソース要素は、(例えば、時間的に)1つのシンボル期間中に1つの副搬送波をカバーしてもよく、1つの変調シンボルを送るために使用してもよく、変調シンボルは、実数値であっても、または、複素数値であってもよい。
[0067]
ある電気通信システム(例えば、NR)中のFDDに対するダウンリンクおよびアップリンクのそれぞれに対して、インターレース構造を使用してもよい。例えば、0ないしQ-1のインデックスを有するQ個のインターレースを規定してもよく、Qは、4、6、8、10、または、他の何らかの値と等しくてもよい。各インターレースは、Q個のフレームだけ間隔を空けて離されているスロットを含んでいてもよい。特に、インターレースqは、スロットq、q+Q、q+2Q等を含んでいてもよく、q∈{0,...,Q-1}である。
[0068]
UEは、複数のBSのカバレッジ内に位置付けられていてもよい。UEを担当するように、これらのBSのうちの1つを選択してもよい。受信信号強度、受信信号品質、パス損失、および/または、これらに類するもののような、さまざまな基準に少なくとも部分的に基づいて、担当BSを選択してもよい。受信信号品質は、信号対雑音および干渉比(SINR)、または、基準信号受信品質(RSRQ)、または、他の何らかのメトリックによって定量化してもよい。UEは、1つ以上の干渉BSからの高い干渉をUEが観測するかもしれない、支配的干渉シナリオにおいて、動作するかもしれない。
[0069]
ここで説明する例の態様はNRまたは5Gテクノロジーに関係付けられているかもしれないが、本開示の態様は、他のワイヤレス通信システムに適用可能であってもよい。新たな無線(NR)は、(例えば、直交周波数分割多元接続(OFDMA)ベースのエアインターフェース以外の)新たなエアインターフェースに、または、(例えば、インターネットプロトコル(IP)以外の)固定された伝送レイヤにしたがって動作するように構成されている無線を指していてもよい。態様では、NRは、アップリンク上で、CPを有するOFDM(ここではサイクリックプレフィックスOFDMまたはCP-OFDMとして呼ばれる)および/またはSC-FDMを利用してもよく、ダウンリンク上で、CP-OFDMを利用してもよく、TDDを使用する半二重動作のためのサポートを含んでいてもよい。態様では、NRは、例えば、アップリンク上で、CPを有するOFDM(ここではCP-OFDMとして呼ばれる)および/または離散フーリエ変換拡散直交周波数分割多重(DFT-s-OFDM)を利用してもよく、ダウンリンク上で、CP-OFDMを利用してもよく、TDDを使用する半二重動作のためのサポートを含んでいてもよい。NRは、広帯域幅(例えば、80メガヘルツ(MHz)以上)をターゲットとする拡張移動体ブロードバンド(eMBB)サービス、高搬送波周波数(例えば、60ギガヘルツ(GHz))をターゲットとするミリ波(mmW)、非下位互換性MTC技術をターゲットとする大量のMTC(mMTC)、および/または、超高信頼性低レイテンシ通信(URLLC)サービスをターゲットとするミッションクリティカルを含んでいてもよい。
[0070]
いくつかの態様では、100MHzの単一のコンポーネント搬送波帯域幅をサポートしてもよい。NRリソースブロックは、0.1ミリ秒(ms)持続時間に渡り、60または120キロヘルツ(kHz)の副搬送波帯域幅を有する12個の副搬送波に及んでいてもよい。各無線フレームは、40個のスロットを含んでいてもよく、10msの長さを有していてもよい。結果として、各スロットは、0.2msの長さを有していてもよい。各スロットは、データ送信のためのリンク方向(例えば、DLまたはUL)を示してもよく、各スロットに対するリンク方向は、動的に切り替えてもよい。各スロットは、DL/ULデータとともにDL/UL制御データを含んでいてもよい。
[0071]
ビーム形成をサポートしてもよく、ビーム方向を動的に構成してもよい。プリコーディングを有するMIMO送信もサポートしてもよい。DL中のMIMOコンフィギュレーションは、8本までの送信アンテナをサポートしてもよく、マルチレイヤDL送信は、8ストリームまでであり、UE毎に2ストリームまでである。UE毎に2ストリームまでのマルチレイヤ送信をサポートしてもよい。複数のセルのアグリゲーションを、8個までの担当セルによりサポートしてもよい。代替的に、NRは、OFDMベースのインターフェース以外の、異なるエアインターフェースをサポートしてもよい。NRネットワークは、中央ユニットまたは分散ユニットのようなエンティティを含んでいてもよい。
[0072]
上記で示したように、図4は例として提供されている。他の例は、図4に関して説明したものと異なっていてもよい。
[0073]
図5は、DL中心スロットまたはワイヤレス通信構造の例を示しているダイヤグラム500である。DL中心スロットは、制御部分502を含んでいてもよい。制御部分502は、DL中心スロットの最初または開始部分中に存在していてもよい。制御部分502は、DL中心スロットのさまざまな部分に対応する、さまざまなスケジューリング情報および/または制御情報を含んでいてもよい。いくつかのコンフィギュレーションにおいて、制御部分502は、図5で示されているように、物理DL制御チャネル(PDCCH)であってもよい。いくつかの態様では、制御部分502は、レガシーPDCCH情報、短縮PDCCH(sPDCCH)情報、(例えば、物理制御フォーマットインジケータチャネル(PCFICH)上で搬送される)制御フォーマットインジケータ(CFI)値、1つ以上の許可(例えば、ダウンリンク許可、アップリンク許可、および/または、これらに類するもの)、ならびに/あるいは、これらに類するものを含んでいてもよい。
[0074]
DL中心スロットは、DLデータ部分504も含んでいてもよい。DLデータ部分504は、ときには、DL中心スロットのペイロードとして呼ばれることがある。DLデータ部分504は、スケジューリングエンティティ(例えば、UEまたはBS)から下位エンティティ(例えば、UE)にDLデータを通信するために利用される通信リソースを含んでいてもよい。いくつかのコンフィギュレーションでは、DLデータ部分504は、物理DL共有チャネル(PDSCH)であってもよい。
[0075]
DL中心スロットは、ULショートバースト部分506も含んでいてもよい。ULショートバースト部分506は、ULバースト、ULバースト部分、共通ULバースト、ショートバースト、ULショートバースト、共通ULショートバースト、共通ULショートバースト部分、および/または、他のさまざまな適切な用語として呼ばれることがある。いくつかの態様では、ULショートバースト部分506は、1つ以上の基準信号を含んでいてもよい。追加的にまたは代替的に、ULショートバースト部分506は、DL中心スロットの他のさまざまな部分に対応するフィードバック情報を含んでいてもよい。例えば、ULショートバースト部分506は、制御部分502および/またはデータ部分504に対応するフィードバック情報を含んでいてもよい。ULショートバースト部分506中に含まれているかもしれない情報の非限定的な例は、ACK信号(例えば、PUCCH ACK、PUSCH ACK、即時ACK)、NACK信号(例えば、PUCCH NACK、PUSCH NACK、即時NACK)、スケジューリング要求(SR)、バッファステータス報告(BSR)、HARQインジケータ、チャネル状態表示(CSI)、チャネル品質インジケータ(CQI)、サウンディング基準信号(SRS)、復調基準信号(DMRS)、PUSCHデータ、および/または、他のさまざまな適切なタイプの情報を含んでいる。ULショートバースト部分506は、ランダムアクセスチャネル(RACH)手順に適する情報、スケジューリング要求、および、他のさまざまな適切なタイプの情報のような、追加のまたは代替の情報を含んでいてもよい。
[0076]
図5中に図示されているように、DLデータ部分504の終端は、ULショートバースト部分506の開始から時間的に分離していてもよい。この時間分離は、ときには、ギャップ、ガード期間、ガードインターバル、および/または、他のさまざまな適切な用語として呼ばれることがある。この分離は、DL通信(例えば、下位エンティティ(例えば、UE)による受信動作)からUL通信(例えば、下位エンティティ(例えば、UE)による送信)への切り替えのための時間を提供する。前述のものは、DL中心ワイヤレス通信構造の単なる一例に過ぎず、同様の特徴を有する代替構造が、ここで説明した態様から必ずしも逸脱することなく存在していてもよい。
[0077]
上記で示したように、図5は単なる例として提供されている。他の例は、図5に関して説明したものと異なっていてもよい。
[0078]
図6は、UL中心スロットまたはワイヤレス通信構造の例を示しているダイヤグラム600である。UL中心スロットは、制御部分602を含んでいてもよい。制御部分602は、UL中心スロットの最初または開始部分に存在していてもよい。図6中の制御部分602は、図5を参照して上述した制御部分502と同様であってもよい。UL中心スロットは、ULロングバースト部分604も含んでいてもよい。ULロングバースト604は、ときには、UL中心スロットのペイロードとして呼ばれることがある。UL部分は、下位エンティティ(例えば、UE)からスケジューリングエンティティ(例えば、UEまたはBS)にULデータを通信するために利用される通信リソースを指していてもよい。いくつかのコンフィギュレーションにおいて、制御部分602は、物理DL制御チャネル(PDCCH)であってもよい。
[0079]
図6に図示されているように、制御部分602の終端は、ULロングバースト604の開始から時間的に分離していてもよい。この時間分離は、ときには、ギャップ、ガード期間、ガードインターバル、および/または、他のさまざまな適切な用語として呼ばれることがある。この分離は、DL通信(例えば、スケジューリングエンティティによる受信動作)からUL通信(例えば、スケジューリングエンティティによる送信)への切り替えのための時間を提供する。
[0080]
UL中心スロットは、ULショートバースト部分606も含んでいてもよい。図6中のULショートバースト部分606は、図5を参照して上述したULショートバースト部分506と同様であってもよく、図5に関連して上述した情報のうちのいずれかを含んでいてもよい。前述のものは、UL中心ワイヤレス通信構造の単なる一例に過ぎず、同様の特徴を有する代替構造が、ここで説明した態様から必ずしも逸脱することなく存在していてもよい。
[0081]
いくつかの状況では、2つ以上の下位エンティティ(例えば、UE)が、サイドリンク信号を使用して、互いに通信してもよい。このようなサイドリンク通信の現実世界のアプリケーションは、公衆安全、近接サービス、UE対ネットワーク中継、ビークルツービークル(V2V)通信、インターネットオブエブリシング(IoE)通信、IoT通信、ミッションクリティカルメッシュ、および/または、他のさまざまな適切なアプリケーションを含んでいてもよい。一般的に、たとえ、スケジューリングエンティティがスケジューリングおよび/または制御目的で利用されるかもしれないとしても、サイドリンク信号は、スケジューリングエンティティ(例えば、UEまたはBS)を通してその通信を中継することなく、1つの下位エンティティ(例えば、UE1)から別の下位エンティティ(例えば、UE2)に通信される信号を指していてもよい。いくつかの態様では、サイドリンク信号は、(典型的にライセンスされていないスペクトル使用するワイヤレスローカルエリアネットワークとは異なり)ライセンスされているスペクトルを使用して通信されてもよい。
[0082]
1つの例では、フレームのようなワイヤレス通信構造は、UL中心スロットとDL中心スロットの両方を含んでいてもよい。この例では、フレーム中のDL中心スロットに対するUL中心スロットの比は、送信されるULデータの量とDLデータの量とに少なくとも部分的に基づいて、動的に調整してもよい。例えば、より多くのULデータがある場合、DL中心スロットに対するUL中心スロットの比を増加させてもよい。逆に、より多くのDLデータがある場合、DL中心スロットに対するUL中心スロットの比を減少させてもよい。
[0083]
上記で示したように、図6は単なる例として提供されている。他の例は、図6に関して説明したものと異なっていてもよい。
[0084]
いくつかの事例では、BSおよびUEは、複数のタイプのサービスを介して互いに通信してもよい。例えば、BSとUEとの間の第1の通信は、拡張移動体ブロードバンド(eMBB)サービスを使用してもよく、BSとUEとの間の第2の通信は、超高信頼性低レイテンシ通信(URLLC)サービスを使用してもよい。このようなケースでは、異なるタイプのサービスは、異なるレイテンシおよび/または信頼性要件のような、異なる特性および/または要件を有しているかもしれない(例えば、URLLCサービスは、eMBBよりもより高い信頼性およびより低いレイテンシ要件を有する)。しかしながら、いくつかのケースでは、通信のために使用されているサービスのタイプ(例えば、eMBBまたはURLLC)にかかわらず、PUCCHリソースの同じセットが、BSとUEとの間の通信のために割り振られるかもしれない。したがって、長いPUCCHリソース(例えば、14シンボル)は、長いPUCCHリソースに関係付けられているかなり高いレイテンシのために、URLLCに有用でないかもしれない。一方、eMBBサービスに必要ではない低いレイテンシ要件を満たすために、より頻繁に(例えば、2シンボル毎に)URLLC PUCCHリソースを構成する必要があるかもしれない。
[0085]
さらに、いくつかの事例では、ダウンリンク制御情報(DCI)は、使用されているサービスのタイプに依存して、異なっていてもよい。例えば、DCIは、URLLCに対するDCI中に含まれるシグナリング方法とは異なる、eMBBに対するPUCCHリソース割り振りのためのシグナリング方法を含んでいてもよい。したがって、PUCCH送信のために使用されることになるサービスのタイプにかかわらずPUCCHリソースが割り振られるとき、UEは、特定のPUCCH送信のために、リソースのうちのどれが使用されることになるかを不適切に解釈するかもしれない。
[0086]
さらに、いくつかの事例では、2つのPUCCHチャネル(例えば、eMBBに対して1つおよびURLLCに対して1つ)が時間的にオーバーラップしているとき、UEは、両方のチャネルのために(例えば、eMBBとURLLCの両方のために)アップリンク制御情報(UCI)ビットを多重化し、単一のチャネル中でUCIを送信する必要があるかもしれない。しかしながら、多重化されたUCIは、URLLCパケットまたはeMBBパケットが適切に受信されたか否かを示さないことから、これは信頼性に悪影響を及ぼすことがある。多重化されたUCIは、パケットに関係付けられているサービスのタイプにかかわらず、単に、受信したパケットの総数を示している。さらに、いくつかの事例では、UEは、異なるタイプのサービスのために異なるタイミングを使用するかもしれない。例えば、eMBB肯定応答または否定応答(ACK/NACK)に対する応答タイミングは、URLLC ACK/NACKに対する応答タイミングとは異なっているかもしれない。いくつかのケースでは、ACK/NACKは、ハイブリッド自動再送要求肯定応答(HARQ-ACK)として呼ばれることがある。同様に、ACK/NACKフィードバックは、HARQ-ACKフィードバックとして呼ばれることがあり、ACK/NACK情報は、HARQ-ACK情報、および/または、これらに類するものとして呼ばれることがある。
[0087]
ここで説明するいくつかの態様は、PUCCH送信のために使用されることになるサービスのタイプに関連して、PUCCHリソースに対するリソース割り振りを提供する。例えば、UEは、PUCCH送信が第1のタイプのサービス(例えば、eMBB)に関係付けられているとき、リソースの第1のセットを使用して、または、PUCCH送信が第2のタイプのサービス(例えば、URLLC)に関係付けられているとき、リソースの第2のセットを使用して、PUCCH送信を送るかもしれない。さらに、ここで説明するいくつかの態様は、適切なリソースが確実に監視および/または使用されるようにするために、PUCCH送信に関係付けられているサービスのタイプに少なくとも部分的に基づいて、DCI中のシグナリングからPUCCH送信に対するリソースを識別してもよい。ここで説明するいくつかの態様は、PUCCH送信に関係付けられているサービスのタイプに少なくとも部分的に基づいて、別個のPUCCHリソースを使用して、UCIを有するPUCCH送信を送信してもよい。例えば、eMBBサービスに関係付けられているPUCCH送信のために実行されるダウンリンク割り当てインデックス(DAI)動作は、URLLCサービスに関係付けられているPUCCH送信のために実行されるDAI動作とは異なっていてもよい。
[0088]
したがって、ここで提供されているいくつかの例は、サービスのタイプに少なくとも部分的に基づいて、異なるPUCCHリソースがPUCCH送信のために動的に割り振られるかまたは使用されることを可能にするかもしれない。例えば、PUCCH送信に関係付けられているサービスの要件に依存して、PUCCH送信のために、PUCCHリソースの比較的少ないセットを、および/または、リソースの各セット中で比較的少ないリソースを使用することによって、PUCCH送信は、別のタイプよりも、サービスの1つのタイプに対してより高い信頼性および/またはより低いレイテンシを達成するかもしれない。追加的にまたは代替的に、このような高い信頼性または低いレイテンシを必要としないかもしれないサービスの別のタイプは、シグナリング帯域幅を節約し、PUCCHリソースのより多くの数のセットを、ならびに/あるいは、リソースのセット内のより多くの数をまたはより多くのリソースを使用して構成することができる。したがって、ここでのいくつかの例は、PUCCH送信に関係付けられているサービスに依存して、必要に応じて、信頼性を高め、および/または、レイテンシを低くしながら、ネットワークリソースを節約するかもしれない。
[0089]
図7は、本開示のさまざまな態様にしたがう、超高信頼性低レイテンシ通信(URLLC)に対して物理アップリンク制御チャネル(PUCCH)リソースを割り振る例700を図示しているダイヤグラムである。例700において、BS110およびUE120は、互いに複数の送信(または、通信)を交換する。いくつかの事例では、送信は、第1のタイプのサービスに関係付けられてもよく、いくつかの事例では、送信は、第2のタイプのサービスに関係付けられてもよい。以下の例で説明するように、第1のタイプのサービスはeMBBサービスであってもよく、第2のタイプのサービスはURLLCサービスであってもよいが、第1および第2のタイプのサービスは異なるサービスであってもよい。例えば、第2のタイプのサービスは、第1のタイプのサービスよりもより低いレイテンシ要件を有していてもよく、第1のタイプのサービスよりもより高い信頼性要件を有していてもよく、第1のタイプのサービスよりもより高い優先度に関係付けられていてもよく、第1のタイプのサービスよりもより速い処理時間(例えば、より低い処理タイムライン)に関係付けられていてもよく、および/または、これらに類するものであってもよい。
[0090]
例700では、ある送信が、異なるパラメータにしたがって動作する、異なるタイプのサービスに関係しているかもしれない(例えば、URLLCは、eMBBよりもより高い信頼性および/またはより低いレイテンシを提供する)ので、BS110およびUE120は、送信に関係付けられているサービスのタイプに少なくとも部分的に基づいて、PUCCHリソースを構成および/または使用してもよい。
[0091]
図7中で参照番号710によって示されているように、BS110は、UE120とのPUCCH送信のために使用されるかもしれないサービスのタイプに少なくとも部分的に基づいて、PUCCH送信に対するリソースコンフィギュレーションを決定する。例えば、BS110は、PUCCH送信がeMBBに関係付けられているとき、PUCCH送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを、PUCCH送信がURLLCに関係付けられているとき、PUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定してもよい。
[0092]
PUCCHリソースのコンフィギュレーションは、PUCCH送信のために使用されることになるPUCCHリソース(例えば、リソースブロック)のセットの数、リソースのセット中に含まれることになるリソースの数、および/または、これらに類するものを識別してもよい。PUCCHリソースは、リソースブロックのセットを含んでいてもよい。いくつかのケースでは、PUCCHリソースの各セットは、アップリンク制御情報(UCI)ペイロード範囲に関係付けられる。例えば、PUCCHリソースの第1のセットは、1ビットまたは2ビットのサイズを有するUCIを送信するように構成されていてもよく、PUCCHリソースの第2のセットは、3ビットからXビットのサイズを有するUCIを送信するように構成されていてもよく、PUCCHリソースの第3のセットは、(X+1)ビットからXビットのサイズを有するUCIを送信するように構成されていてもよく、以下同様である。URLLCに対して、高信頼性を達成することを支援するために、UCIのペイロードサイズは、典型的に小さい。したがって、(例えば、4つのセットを使用するかもしれない)eMBBと比較して、PUCCHリソースのより少ないセット(例えば、1つまたは2つのセット)が、URLLCのために必要とされるかもしれない。したがって、eMBBサービスを使用するPUCCH送信に対する第1のコンフィギュレーションは、URLLCサービスを使用するPUCCH送信に対する第2のコンフィギュレーションよりも多くのリソースのセットを含んでいてもよい。
[0093]
いくつかのケースでは、URLLC PUCCHリソースは、eMBB PUCCHリソースよりも細かい粒度で構成されていてもよい。例えば、eMBB PUCCHリソースコンフィギュレーションは、スロットの長さ(例えば、14シンボル)を有するPUCCHリソースを構成してもよいが、URLLC PUCCHリソースコンフィギュレーションは、サブスロット(または、ミニスロット)の長さ(例えば、14シンボル未満)を有するPUCCHリソースを構成してもよい。結果として、eMBB PUCCHリソースコンフィギュレーションは、短い(例えば、1または2シンボル)および長い(例えば、4~14シンボル)PUCCHリソースの両方を構成する必要があるかもしれないが、URLLC PUCCHリソースコンフィギュレーションは、サブスロット(または、ミニスロット)長よりも短いPUCCHリソースだけを構成する必要があるかもしれない。したがって、URLLCに対する各PUCCHリソースセットでは、eMBBと比較して、より少ないリソースが必要とされる。したがって、URLLCサービスに関係付けられているPUCCH送信に対して、リソースの各セットは、eMBBサービスに関係付けられているPUCCH送信よりも少ないリソースを含んでいてもよい。このケースでは、eMBBサービスは、比較的長いPUCCH(14シンボル)を利用するかもしれないが、これは、低いレイテンシを達成するためにより頻繁に(例えば、2シンボル毎に)構成されることになる、URLLCサービスに対して高すぎるレイテンシを引き起こすかもしれない。eMBBサービスに対して、そのように頻繁に構成する必要はないかもしれず、そのようにすることは、シグナリング帯域幅および/またはネットワークリソースの浪費になるかもしれない。したがって、eMBBサービスは、eMBBのために構成されているPUCCH送信に対するリソースのセットおよびサイズを使用してもよく、URLLCサービスは、URLLCのために構成されているPUCCH送信に対するリソースのセットまたはサイズを使用してもよい。
[0094]
いくつかのケースでは、PUCCHリソースを使用して、ダウンリンク半永続的スケジューリング(SPS)送信に関係付けられているHARQ-ACKフィードバックを送信してもよい。ダウンリンクSPSに対するHARQ-ACKフィードバックを送信するためのPUCCHリソースは、ダウンリンクSPSコンフィギュレーションの一部として、無線リソース制御(RRC)メッセージ中で構成されていてもよい。例えば、周期的なPUCCHリソースがRRCメッセージ中で構成されていてもよく、そのPUCCHリソースを使用して、ダウンリンクSPS送信のために、PUCCHを周期的に送信してもよい。ダウンリンクSPSに対するPUCCHリソースコンフィギュレーションは、HARQ-ACKフィードバックのために使用されることになるPUCCHリソースを識別するPUCCH識別子(PUCCH ID)を示していてもよい。しかしながら、eMBBおよびURLLCのためにダウンリンクSPSが別個に構成されているとき、基地局110は、PUCCH IDだけでなく、PUCCHリソースがURLLC送信(または、eMBB送信または他のサービスタイプ)に関係付けられているか否かも示す必要があるかもしれない。このケースでは、UE120は、URLLC送信のために構成されているPUCCHリソースのセットからPUCCHリソースを選択してもよい。したがって、BS110は、BS110とUE120との間の通信において使用されるサービスのタイプ(例えば、eMBBまたはURLLC)に少なくとも部分的に基づいて、ダウンリンクSPS送信に関係付けられているPUCCHリソースに対する別個のコンフィギュレーションを決定してもよい。例えば、ダウンリンクSPSに関係付けられているPUCCHリソースに対して、BS110は、PUCCHおよびダウンリンクSPS送信がeMBBに関係付けられているとき、PUCCH送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを、PUCCHおよびダウンリンクSPS送信がURLLCに関係付けられているとき、PUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定してもよい。
[0095]
いくつかの態様では、BS110は、PUCCHリソースの同じセットがPUCCH送信のためにUE120にアクセス可能であってもよいことを示すリソースコンフィギュレーションを決定してもよいが、リソースコンフィギュレーションは、第1のタイプのサービス、第2のタイプのサービス、または、両方のタイプのサービスとともに使用するためにPUCCHリソースを割り振るパラメータを、PUCCHリソースのそれぞれに割り当ててもよい。例えば、BS110は、PUCCH送信に対するリソースコンフィギュレーションを介して、各PUCCHリソースが、eMBB、URLLC、または、eMBBとURLLCの両方とともに使用されることになるか否かを示すパラメータを各PUCCHリソースに割り当ててもよい。結果として、ここで説明するように、UE120は、eMBB送信とURLLC送信の両方に対して、PUCCHリソースの同じセットにアクセスし、パラメータと、(例えば、PUCCHリソースおよび/またはPUCCHリソースの開始シンボルを識別する)DCI中で受信した情報とにしたがって、PUCCH送信に対する適切なリソースを選択してもよい。
[0096]
図7中で参照番号720によってさらに示されているように、BS110は、リソースコンフィギュレーションを有するPUCCHコンフィギュレーションをUE120に送信する。いくつかの態様では、PUCCHコンフィギュレーションは、第1のタイプのサービス(例えば、eMBB)に関係付けられている送信または通信のためのパラメータの第1のセットと、第2のタイプのサービス(例えば、URLLC)に関係付けられている送信のためのパラメータの第2のセットとを含んでいてもよい。追加的にまたは代替的に、BS110は、第1のタイプのサービスおよび第2のタイプのサービスに対して、個々のPUCCHコンフィギュレーションを送ってもよい。例えば、BS110は、eMBBに対する第1のPUCCHコンフィギュレーションと、URLLCに対する第2のPUCCHコンフィギュレーションとを送ってもよい。いくつかの態様では、最大コーディングレートは、eMBBとURLLCとで異なっていてもよい。例えば、パラメータの第1のセット(および/または、第1のPUCCHコンフィギュレーション)は、パラメータの第2のセット(および/または、第2のPUCCHコンフィギュレーション)とは異なる最大コーディングレートを含んでいてもよい。
[0097]
図7中で参照番号730によってさらに示されているように、BS110は、DCIを有するダウンリンク通信を送信する。ダウンリンク通信は、PUCCH送信に関係付けられているサービスのタイプを示していてもよい、サービスのタイプに関係付けられている1つ以上のパケットを含んでいてもよい。例えば、ダウンリンク通信がeMBB通信である場合、PUCCH送信はeMBBサービスに関係付けられていてもよい。追加的にまたは代替的に、ダウンリンク通信がURLLC通信に関係付けられている場合、PUCCH送信はURLLC通信に関係付けられていてもよい。
[0098]
UE120は、DCIがeMBBまたはURLLCに関係付けられているか否かを決定してもよい。いくつかの態様では、ダウンリンク通信中のDCIは、ここではPUCCHリソースインジケータとして呼ばれる、ACK/NACKリソースインジケータ(ARI)フィールドを含んでいてもよい。いくつかの態様では、UE120は、PUCCH送信のために使用されることになるサービスのタイプ(例えば、eMBBまたはURLLC)に少なくとも部分的に基づいて、PUCCHリソースインジケータのビット幅(すなわち、ビットの数)を決定してもよい。例えば、PUCCH送信がURLLC送信に関係付けられているとき、UE120は、(例えば、PUCCHリソースのセットのリソースの数が4つ以下であることを示す)PUCCHリソースインジケータが2ビットであることを決定してもよい。別の例として、PUCCH送信がeMBB送信に関係付けられているとき、UE120は、(例えば、PUCCHリソースのセットのリソースの数が8つ以下であることを示す)PUCCHリソースインジケータが3ビットであることを決定してもよい。
[0099]
図7中で参照番号740によってさらに示されているように、UE120は、ダウンリンク通信に少なくとも部分的に基づいて、PUCCH送信に関係付けられているサービスのタイプを決定する。いくつかの態様では、UE120は、前のパケットを受信および/または送信するために使用されたサービスのタイプに少なくとも部分的に基づいて、サービスのタイプを決定してもよい。例えば、ダウンリンク通信が第1のサービスを介して受信される場合、UE120は、PUCCH送信が第1のサービスを使用して送信されることになることを決定してもよく、ダウンリンク通信が第2のサービスを介して受信される場合、UE120は、PUCCH送信が第2のサービスを使用して送信されることになることを決定してもよい。
[00100]
図7中で参照番号750によってさらに示されているように、UE120は、PUCCH送信のサービスタイプに関係付けられているリソースコンフィギュレーションにしたがうリソースを使用して、PUCCH送信を送信する。したがって、DCIを使用して、UE120は、どのリソースがPUCCH送信のために使用されることになるかを決定し、そのリソースを使用してPUCCH送信を送信してもよい。
[00101]
いくつかの態様では、UE120は、異なるサービス(例えば、eMBBおよびURLLC)に対応する異なるPUCCHリソースセットを用いて構成されていてもよい。UE120は、サービスタイプに関連する受信したダウンリンク通信内のコンフィギュレーションとDCIとに少なくとも部分的に基づいて、どのリソースがPUCCH送信のために使用されることになるかを決定してもよい。例えば、UE120は、PUCCH送信がeMBBサービスに関係付けられていることを決定してもよい。このケースでは、UE120は、受信したダウンリンク通信内のコンフィギュレーションとDCIとに少なくとも部分的に基づいて、eMBBサービスのために構成されているリソースのセットからPUCCHリソースを選択してもよい。追加的にまたは代替的に、UE120は、PUCCH送信がURLLCサービスに関係付けられていることを決定してもよい。このケースでは、UE120は、受信したダウンリンク通信内のコンフィギュレーションとDCIとに少なくとも部分的に基づいて、URLLCサービスのために構成されているリソースのセットからPUCCHリソースを選択してもよい。DCIは、開始シンボル、使用されることになるOFDMシンボルおよびリソースブロックの数、PUCCHリソースID、ならびに/あるいは、これらに類するものを示していてもよい。
[00102]
いくつかの例では、UE120が複数のタイプのサービスに対して同じPUCCHリソースコンフィギュレーションを使用するとき、UE120は、PUCCHリソースがURLLCとともに使用されるべきか、eMBBとともに使用されるべきか(または、両方とともに使用されるべきか)を示しているテーブルを参照してもよい。例えば、UE120は、eMBBおよびURLLCとともに使用するためのPUCCHリソースを識別する以下のテーブルを参照してもよい:
Figure 0007206296000001
PUCCHリソースが、URLLC PUCCH送信、eMBB PUCCH送信、または、URLLC PUCCH送信とeMBB PUCCH送信の両方とともに使用されることになるかを、URLLC/eMBBフラグは識別する。いくつかの態様では、各PUCCHリソースは、1つはURLLCに対する、1つはeMBBに対する、2つの別個の識別子(例えば、URLLC/eMBBフラグに少なくとも部分的に基づいてUEにおいて暗黙的に決定される仮想ID)を有してもよい。例として、URLLCに関係付けられているPUCCH送信に対して、UE120は、DCI中で(3のURLLC IDを示す)PUCCHリソースインジケータ=3を受信してもよい。したがって、UE120は、PUCCHリソースインジケータ=3を使用し、リソース#0から開始して、リソース#7をPUCCH送信に対するPUCCHリソースとして識別し、リソース#0は、0のURLLC IDを有し、リソース#1は、1のURLLC IDを有し、リソース#6は、2のURLLC IDを有し、リソース#7は、3のURLLC IDを有する。したがって、各リソース#0~7は、PUCCH送信に関係付けられているサービスのタイプ(例えば、eMBBまたはURLLC)に少なくとも部分的に基づく追加の識別子を有していてもよい。
[00103]
いくつかの態様では、UE120は、開始シンボルパラメータを使用して、どのPUCCHリソースがPUCCH送信のために使用されることになるかを決定してもよい。DCI中に含まれるかもしれない例示的な開始シンボルパラメータは、URLLCとeMBBとに対して異なっていてもよい。例えば、eMBBに対して、開始シンボルパラメータは、スロット内の相対インデックスを指していてもよい。追加的にまたは代替的に、URLLCに対して、開始シンボルパラメータは、シグナリング(例えば、ACK/NACKがいつ送信されることになるかを識別する、DCI中のK1シグナリング)に対するタイミングを示していてもよい。
[00104]
いくつかの態様では、(例えば、URLLCサービスPUCCH送信に対する)送信ダイバーシティを達成するために、PUCCH送信は、対応するリソースコンフィギュレーション中で識別されるリソースのセットの2つ以上のリソース上で送信されてもよい。例えば、URLLCサービスに関係付けられているPUCCH送信に対して、PUCCH送信は、送信ダイバーシティ利得を取得するために、URLLCサービスのために割り振られるリソースのセットの2つのリソース上で、少なくとも2つの送信アンテナを介して送信されてもよい。これは、URLLC内のPUCCH送信の信頼性を改善することができる。このようなケースでは、複数のPUCCHリソースは、同じ識別子を用いて構成されていてもよい。したがって、PUCCH送信がその識別子を有するPUCCHリソースを介して送られることになることをDCIが示している場合、複数のリソースを介してPUCCH送信を送ることができる。いくつかのケースでは、DCIは、インデックスkを示していてもよく、UE120は、インデックスと、PUCCHを送信するためにUEに割り振られるPUCCHリソースの数を示す(例えば、DCIを受信する前にRRC通信を介して受信されてもよい)無線リソース制御(RRC)コンフィギュレーションMとに少なくとも部分的に基づいて、PUCCHリソースを使用してもよい。したがって、kは動的に受信されてもよく、Mは半静的に受信されてもよい。UE120は、kおよびMを使用して、使用されることになるリソースの対応するセットのPUCCHリソースを識別してもよい。例えば、UE120は、M(k-1)、M(k-1)+1、...、Mk-1に等しい識別子を有するPUCCHリソースを識別してもよい。追加的にまたは代替的に、UE120は、k、k+1、...、k+M-1に等しい識別子を有するPUCCHリソースを識別してもよい。いくつかの態様では、異なるまたは追加のPUCCHフォーマットを使用して、送信ダイバーシティを達成することができる。例えば、あるPUCCHフォーマットは、URLLCのために構成されていてもよいが、eMBBのためには構成されない。いくつかの態様では、送信ダイバーシティに関して上記で説明したスキームは、URLLC PUCCH送信に適用されてもよいが、eMBB PUCCH送信には適
用されない。
[00105]
ダウンリンク割り当てインデックス(DAI)を使用して、UE120が現在のDCIまでに受信した物理ダウンリンク共有チャネル(PDSCH)通信の数を示してもよい。例えば、UE120は、カウンタDAIおよび/またはトータルDAIの表示を受信してもよい。カウンタDAIの値は、現在の担当セルおよび現在のPDCCH監視機会までに、PDSCH受信またはSPS PDSCH解放が存在する、担当セルPDCCH監視機会の累積数を示していてもよい。トータルDAIの値は、存在する場合、現在のPDCCH監視機会までに、PDSCH受信およびSPS PDSCH解放が存在する、担当セルPDCCH監視機会ペアの総数を示していてもよい。いくつかの態様では、UE120は、URLLCおよびeMBBに対して、DAIの異なるセットを追跡および/または記憶していてもよく、URLLCおよびeMBBに対して、別個のDAIカウントおよび/またはDAI累積を実行してもよい。例えば、UE120は、DAIの2つのセットを追跡および/または記憶していてもよく、{カウンタDAI、トータルDAI}の第1のセットはURLLC送信のみに適用され、{カウンタDAI、トータルDAI}の第2のセットはeMBB送信のみに適用される。このケースでは、URLLC DAIはeMBB DAIに向けてカウントせず、逆もまた同様である。いくつかの態様では、UE120は、PUCCHリソースコンフィギュレーションに少なくとも部分的に基づいて、異なるタイプのサービスに対して別個のDAI動作を実行するように構成されていてもよい。例えば、PUCCH送信中のアップリンク制御情報(UCI)は、PUCCH送信がeMBBに関係付けられているとき、第1のダウンリンク割り当てインデックス(DAI)動作にしたがって決定されてもよく、PUCCH送信中のUCIは、PUCCH送信がURLLCに関係付けられているとき、第2のDAI動作にしたがって決定されてもよい。
[00106]
UE120は、DCIがeMBBに関係付けられているかまたはURLLCに関係付けられているかを決定してもよい。いくつかの態様では、ダウンリンク通信中のDCIは、DAIフィールドを含んでいてもよい。いくつかの態様では、UE120は、PUCCH送信のために使用されることになるサービスのタイプ(例えば、eMBBまたはURLLC)に少なくとも部分的に基づいて、DAIのビット幅(すなわち、ビットの数)を決定してもよい。例えば、UE120は、PUCCH送信がURLLC送信に関係付けられているとき、DAIが1ビットであることを決定してもよい。別の例として、UE120は、PUCCH送信がeMBB送信に関係付けられているとき、DAIが2ビットであることを決定してもよい。
[00107]
例示的なPUCCH送信はACK/NACKであってもよい。ACK/NACKは、(例えば、ダウンリンク通信を受信したことに応答して)動的に、および/または、半永続的スケジューリング(SPS)にしたがって、送られてもよい。いくつかの態様では、eMBBと比較して、URLLCに対するACK/NACKバンドリングに関して異なるDAI動作を実行してもよい。より具体的には、UE120は、PUCCH送信を送るとき、URLLCとeMBBとの間で多重化しないかもしれない。したがって、URLLCパケットの受信に対するACK/NACKは、eMBBパケットの受信に対するACK/NACKとは別個のPUCCH送信で送られてもよい。いくつかの態様では、URLLCとeMBBの両方に対するACK/NACKが時間的にオーバーラップするとき、eMBB ACK/NACKは(例えば、URLLCの低いレイテンシおよび高信頼性要件を満たすために)ドロップされるかもしれない。しかしながら、送信が同じスロット中で行われることになるが、オーバーラップしていない場合、eMBB ACK/NACKはドロップされないかもしれない。例えば、第1のPUCCH送信がシンボル1~5上でスケジュールされ、第2のPUCCH送信がシンボル6~10上でスケジュールされる場合、第1のPUCCH送信も第2のPUCCH送信もドロップされない。追加的にまたは代替的に、2つの送信が部分的にオーバーラップするように構成されているとき、eMBB PUCCH送信のオーバーラップする部分はドロップされるかもしれない。例えば、eMBB PUCCH送信がシンボル1~10上であり、URLLC PUCCH送信がシンボル7~11上であることになる場合、eMBB PUCCH送信のためのシンボル7~10中のデータはドロップされるかもしれない。
[00108]
いくつかの態様では、PUCCH送信は、(例えば、アップリンクリソースを要求する)サービス要求(SR)を、および/または、(例えば、ダウンリンク通信を受信するために使用されるチャネルのステータスを示す)チャネル状態情報(CSI)報告を含んでいてもよい。
[00109]
上記で示したように、図7は例として提供されている。他の例は、図7に関して説明したものとは異なっていてもよい。
[00110]
図8は、URLLCに対するPUCCHリソースを割り振る例810および820を図示しているダイヤグラムである。図8では、サービスのタイプ(例えば、eMBBまたはURLLC)にしたがって割り当てられていてもよいリソースのダイヤグラムが示されている。例810によって示されているように、eMBB PUCCHリソースセットは、URLLCのために割り振られるPUCCHリソースセットとは異なっていてもよい。例えば、eMBB PUCCHリソースは、セットA、B、C、Dを含んでいてもよく、URLLC PUCCHリソースセットは、セットX、Y、Zを含んでいてもよい。さらに、例810によって示されているように、サービスのタイプに少なくとも部分的に基づいて、異なる量のリソースセットが、割り振られてもよい。例えば、4つのPUCCHリソースセットA、B、C、DがeMBBに対して割り振られ、3つのリソースセットX、Y、ZがURLLCに対して割り振られる。
[00111]
例820によって示されているように、いくつかの態様では、複数のタイプのサービスに対して、PUCCHリソースの同じセットを共有してもよく、特定のタイプのリソースセットに対して、いくつかのリソースセットを使用してもよい。例えば、eMBBおよびURLLCの両方がセットABCを使用してもよいが、eMBBのみがセット0を使用してもよく、URLLCのみがセット1を使用してもよい。したがって、PUCCH送信のタイプに少なくとも部分的に基づいて、PUCCH送信のために、PUCCHリソースセットを割り振ることができる。
[00112]
上記で示したように、図8は例として提供されている。他の例は、図8に関して説明したものとは異なっていてもよい。
[00113]
図9は、URLLCに対するPUCCHリソースを割り振る例900を図示しているダイヤグラムである。例900によって示されているように、送信ダイバーシティを達成するために、リソースのセット内の複数のリソースに、同じリソースIDが割り当てられてもよい。図9では、2つのリソースがID=2を有し、4つのリソースがID=3を有する。したがって、PUCCH送信がID=2を有するPUCCHリソースを介して送信されることになることをUE120が決定するとき、UE120は、2つのリソースを介してPUCCH送信を送信してもよい。同様に、PUCCH送信がID=3を有するPUCCHリソースを介して送信されることになることをUE120が決定するとき、UE120は、4つのリソースを介してPUCCH送信を送信してもよい。いくつかの態様では、2つのPUCCHリソースまたは4つのPUCCHリソースが、同じ時間ドメインリソースに関係付けられてもよく(例えば、同じOFDMシンボル上で構成されてもよく)、このケースでは、UE120は、空間ダイバーシティを達成するために、異なる送信アンテナから同時に、これらの示されたPUCCHリソース上でPUCCHを送信する。
[00114]
上記で示したように、図9は例として提供されている。他の例は、図9に関して説明したものとは異なっていてもよい。
[00115]
図10は、本開示のさまざまな態様にしたがう、例えば、UEによって実行される例示的なプロセス1000を図示しているダイヤグラムである。例示的なプロセス1000は、UE(例えば、UE120および/またはこれらに類するもの)が、PUCCHリソースを識別することと、ここで説明するいくつかの例にしたがって割り振られるPUCCHリソースを使用して、PUCCH送信を送ることとに関係付けられている動作を実行する例である。
[00116]
図10中で示されているように、いくつかの態様では、プロセス1000は、PUCCH送信が第1のタイプのサービスに関係付けられているかまたは第2のタイプのサービスに関係付けられているかを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることを含んでいてもよい(ブロック1010)。例えば、上記で説明したように、UEは(例えば、受信プロセッサ258、送信プロセッサ264、制御装置/プロセッサ280、メモリ282、および/または、これらに類するものを使用して)、PUCCH送信が第1のタイプのサービスに関係付けられているかまたは第2のタイプのサービスに関係付けられているかを決定してもよい。いくつかの態様では、第2のタイプのサービスは、第1のタイプのサービスのよりもより高い信頼性またはより低いレイテンシに関係付けられている。
[00117]
図10中でさらに示されているように、いくつかの態様では、プロセス1000は、PUCCH送信が第1のタイプのサービスに関係付けられているとき、リソースの第1のセットを使用して、または、PUCCH送信が第2のタイプのサービスに関係付けられているとき、リソースの第2のセットを使用して、PUCCH送信を送信することを含んでいてもよい(ブロック1020)。例えば、UEは(例えば、受信プロセッサ258、送信プロセッサ264、制御装置/プロセッサ280、メモリ282、および/または、これらに類するものを使用して)、上記で説明したように、PUCCH送信が第1のタイプのサービスに関係付けられているとき、リソースの第1のセットを使用して、または、PUCCH送信が第2のタイプのサービスに関係付けられているとき、リソースの第2のセットを使用して、PUCCH送信を送信してもよい。
[00118]
プロセス1000は、以下で説明する、任意の単一の態様または態様の任意の組み合わせ、および/または、ここでの他の箇所で説明する1つ以上の他のプロセスに関連するような、追加の態様を含んでいてもよい。
[00119]
第1の態様では、第1のタイプのサービスは、拡張移動体ブロードバンド(eMBB)サービスを含み、第2のタイプのサービスは、超高信頼性低レイテンシ通信(URLLC)サービスを含んでいる。
[00120]
第2の態様では、単独で、または、第1の態様と組み合わせて、リソースの第1のセットは、第1のタイプのサービスに対して構成されている複数のリソースセットを含んでいる。
[00121]
第3の態様では、単独で、または、第1および第2の態様のうちの1つ以上と組み合わせて、リソースの第2のセットは、第2のタイプのサービスに対して構成されている複数のリソースセットを含んでいる。
[00122]
第4の態様では、単独で、または、第1~第3の態様のうちの1つ以上と組み合わせて、PUCCH送信は、肯定応答および/または否定応答(ACK/NACK)、サービス要求(SR)、あるいは、チャネル状態情報(CSI)報告のうちの少なくとも1つを含んでいる。
[00123]
第5の態様では、単独で、または、第1~第4の態様のうちの1つ以上と組み合わせて、ACK/NACKは、動的スケジューリングまたは半永続的スケジューリング(SPS)に関係付けられている。
[00124]
第6の態様では、単独で、または、第1~第5の態様のうちの1つ以上と組み合わせて、リソースの第1のセットは4つのリソースセットを含み、リソースの第2のセットは4つ未満のリソースセットを含んでいる。
[00125]
第7の態様では、単独で、または、第1から第6の態様のうちの1つ以上と組み合わせて、リソースの第1のセットは、リソースの第2のセットとは異なる。
[00126]
第8の態様では、単独で、または、第1~第7の態様のうちの1つ以上と組み合わせて、リソースの第2のセット中のリソースセットの数は、リソースの第1のセット中のリソースセットの数よりも少ない。
[00127]
第9の態様では、単独で、または、第1~第8の態様のうちの1つ以上と組み合わせて、リソースの第1のセットのうちの少なくとも1つのリソースセットは、リソースの第2のセット中に含まれるリソースセットと同じリソースセットである。
[00128]
第10の態様では、単独で、または、第1~第9の態様のうちの1つ以上と組み合わせて、リソースの第2のセットの各セット内のリソースの数は、リソースの第1のセットの各セット内のリソースの数よりも少ない。
[00129]
第11の態様では、単独で、または、第1~第10の態様のうちの1つ以上と組み合わせて、UEは、PUCCH送信に関係して基地局から受信したダウンリンク制御情報(DCI)中のPUCCHリソースインジケータフィールドのビット幅に少なくとも部分的に基づいて、リソースの第1のセットまたはリソースの第2のセットの各セット内のリソースの数を決定するように構成されている。
[00130]
第12の態様では、単独で、または、第1~第11の態様のうちの1つ以上と組み合わせて、PUCCH送信は、PUCCH送信が第2のタイプのサービスに関係付けられているという決定に少なくとも部分的に基づいて、リソースの第2のセットの2つ以上のリソース上で送信される。
[00131]
第13の態様では、単独で、または、第1~第12の態様のうちの1つ以上と組み合わせて、PUCCH送信は、PUCCH送信が第2のタイプのサービスに関係付けられているという決定に少なくとも部分的に基づいて、リソースの第2のセットの2つのリソース上で、少なくとも2つの送信アンテナを介して送信される。
[00132]
第14の態様では、単独で、または、第1~第13の態様のうちの1つ以上と組み合わせて、リソースの第2のセットのうちの1つのセットの少なくとも2つのリソースは、同じ識別子を共有し、識別子がPUCCH送信に関係して受信されるとき、PUCCH送信は、少なくとも2つのリソースを使用して送信される。
[00133]
第15の態様では、単独で、または、第1~第14の態様のうちの1つ以上と組み合わせて、基地局から、PUCCH送信に関係して、インデックスと半静的に受信されるコンフィギュレーションとを受信することに少なくとも部分的に基づいて、PUCCH送信は、リソースの第2のセットの1つ以上のリソースを使用して送信される。
[00134]
第16の態様では、単独で、または、第1~第15の態様のうちの1つ以上と組み合わせて、リソースの第2のセットのリソースは、PUCCH送信に関連して使用するために、リソースの第1のセットのリソースとは異なって識別される。
[00135]
第17の態様では、単独で、または、第1~第16の態様のうちの1つ以上と組み合わせて、リソースの第2のセットのリソースは、異なるPUCCHフォーマットを使用することに関連して、PUCCH送信に関連する使用のために、リソースの第1のセットのリソースとは異なって識別される。
[00136]
第18の態様では、単独で、または、第1~第17の態様のうちの1つ以上と組み合わせて、リソースの第1のセットのリソースは、リソースの第1のセットのリソースに関係付けられているパラメータの第1の値に少なくとも部分的に基づいて、第1のタイプのサービスに関係する使用のために識別され、または、リソースの第2のセットのリソースは、リソースの第2のセットのリソースに関係付けられているパラメータの第2の値に少なくとも部分的に基づいて、第2のタイプのサービスに関係する使用のために識別される。
[00137]
第19の態様では、単独で、または、第1~第18の態様のうちの1つ以上と組み合わせて、PUCCH送信のリソースに対して、パラメータは、パラメータの値に少なくとも部分的に基づいて、リソースが、第1のタイプのサービスに、第2のタイプのサービスに、または、第1のタイプのサービスと第2のタイプのサービスの両方に関係付けられているか否かを示している。
[00138]
第20の態様では、単独で、または、第1~第19の態様のうちの1つ以上と組み合わせて、パラメータは、PUCCH送信に対するリソースのコンフィギュレーション内に含まれている。
[00139]
第21の態様では、単独で、または、第1~第20の態様のうちの1つ以上と組み合わせて、パラメータの値は、リソースの第1のセットとリソースの第2のセットの同じリソースが、第1のタイプのサービスと第2のタイプのサービスとに関係付けられていることを示している。
[00140]
第22の態様では、単独で、または、第1~第21の態様のうちの1つ以上と組み合わせて、リソースの第1のセットは、リソースの第2のセットとリソースの同じセットである。いくつかの態様では、リソースの同じセットの各リソースは、PUCCH送信が第1のタイプのサービスに関係付けられているとき、PUCCH送信に対する第1の識別子に関係付けられ、PUCCH送信が第2のタイプのサービスに関係付けられているとき、PUCCH送信に対する第2の識別子に関係付けられている。
[00141]
第23の態様では、単独で、または、第1~第22の態様のうちの1つ以上と組み合わせて、PUCCH送信は、第1のタイプのサービスまたは第2のタイプのサービスに関係付けられているインデックスを示すダウンリンク制御情報を受信することに少なくとも部分的に基づいて、リソースの同じセットのうちの1つを使用して送信される。
[00142]
第24の態様では、単独で、または、第1~第23の態様のうちの1つ以上と組み合わせて、開始シンボルパラメータは、PUCCH送信が第1のタイプのサービスに関係付けられているとき、PUCCH送信が第2のタイプのサービスに関係付けられているときとは異なる開始シンボルを識別する。
[00143]
第25の態様では、単独で、または、第1~第24の態様のうちの1つ以上と組み合わせて、PUCCH送信が第1のタイプのサービスに関係付けられているときの開始シンボルパラメータは、PUCCH送信に対するスロットに関する相対インデックスを識別する。
[00144]
第26の態様では、単独で、または、第1~第25の態様のうちの1つ以上と組み合わせて、PUCCH送信が第2のタイプのサービスに関係付けられているときの開始シンボルパラメータは、ダウンリンク制御情報(DCI)中のシグナリングに関係付けられているタイミングを識別する。
[00145]
第27の態様では、単独で、または、第1~第26の態様のうちの1つ以上と組み合わせて、PUCCH送信が第1のタイプのサービスに関係付けられているとき、PUCCH送信中のアップリンク制御情報(UCI)は、第1のダウンリンク割り当てインデックス(DAI)動作にしたがって決定され、PUCCH送信が第2のタイプのサービスに関係付けられているとき、PUCCH送信中のUCIは、第2のDAI動作にしたがって決定される。
[00146]
第28の態様では、単独で、または、第1~第27の態様のうちの1つ以上と組み合わせて、PUCCH送信が、第1のタイプのサービスに関係付けられている第1のPUCCH送信であり、第2のタイプのサービスに関係付けられている第2のPUCCH送信が、第1のPUCCH送信のシンボルとオーバーラップするシンボルを使用して送信されることになるとき、オーバーラップするシンボルは、第1のPUCCH送信からドロップされる。
[00147]
図10は、プロセス1000の例示的なブロックを示しているが、いくつかの態様では、プロセス1000は、追加のブロック、より少ないブロック、異なるブロック、または、図10中に描いたものとは異なって構成されているブロックを含んでいてもよい。追加的にまたは代替的に、プロセス1000のブロックのうちの2つ以上を並列に実行してもよい。
[00148]
図11は、本開示のさまざまな態様にしたがう、例えば、基地局によって実行される例示的なプロセス1100を図示しているダイヤグラムである。例示的なプロセス1100は、基地局(例えば、基地局110および/またはこれらに類するもの)が、PUCCH送信に関係付けられているサービスのタイプに関連するPUCCHリソースの割り振りに関係付けられている動作を実行する例である。
[00149]
図11中で示されているように、いくつかの態様では、プロセス1100は、第1のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを決定することを含んでいてもよい(ブロック1110)。例えば、基地局は(例えば、制御装置/プロセッサ240、メモリ242、および/または、これらに類するものを使用して)、上記で説明したように、第1のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを決定してもよい。
[00150]
図11中でさらに示されているように、いくつかの態様では、プロセス1100は、第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることを含んでいてもよい(ブロック1120)。例えば、基地局は(例えば、制御装置/プロセッサ240、メモリ242、および/または、これらに類するものを使用して)、上記で説明したように、第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定してもよい。いくつかの態様では、第2のタイプのサービスは、第1のタイプのサービスのよりもより高い信頼性またはより低いレイテンシに関係付けられている。
[00151]
図11中でさらに示されているように、いくつかの態様では、プロセス1100は、第1のコンフィギュレーションと第2のコンフィギュレーションとをユーザ機器(UE)に送信することを含んでいてもよい(ブロック1130)。例えば、基地局は(例えば、送信プロセッサ220、制御装置/プロセッサ240、メモリ242、および/または、これらに類するものを使用して)、上記で説明したように、第1のコンフィギュレーションと第2のコンフィギュレーションとをUEに送信してもよい。
[00152]
プロセス1100は、以下で説明する、任意の単一の態様または態様の任意の組み合わせ、および/または、ここでの他の箇所で説明する1つ以上の他のプロセスに関連するような、追加の態様を含んでいてもよい。
[00153]
第1の態様では、第1のタイプのサービスは、拡張移動体ブロードバンド(eMBB)サービスを含み、第2のタイプのサービスは、超高信頼性低レイテンシ通信(URLLC)サービスを含んでいる。
[00154]
第2の態様では、単独で、または、第1の態様と組み合わせて、第1のコンフィギュレーションは第2のコンフィギュレーションとは異なる。
[00155]
第3の態様では、単独で、または、第1および第2の態様のうちの1つ以上と組み合わせて、第1のコンフィギュレーション中に含まれるPUCCHリソースのセットは、第2のコンフィギュレーション中に含まれるPUCCHリソースのセットとは異なる。
[00156]
第4の態様では、単独で、または、第1~第3の態様のうちの1つ以上と組み合わせて、第2のコンフィギュレーションは、第1のコンフィギュレーションよりもPUCCHリソースのより少ないセットを含んでいる。
[00157]
第5の態様では、単独で、または、第1~第4の態様のうちの1つ以上と組み合わせて、第2のコンフィギュレーション中に含まれるPUCCHリソースの各セット中のPUCCHリソースの数は、第1のコンフィギュレーション中に含まれるPUCCHリソースの各セット中のPUCCHリソースの数よりも少ない。
[00158]
第6の態様では、単独で、または、第1~第5の態様のうちの1つ以上と組み合わせて、ダウンリンク制御情報(DCI)中のPUCCHリソースインジケータのビット幅は、第2のコンフィギュレーション中に含まれるPUCCHリソースの各セット中のPUCCHリソースの数にしたがっている第2のタイプのサービスに対応する。
[00159]
第7の態様では、単独で、または、第1~第6の態様のうちの1つ以上と組み合わせて、第1のコンフィギュレーションおよび第2のコンフィギュレーションの各PUCCHリソースに対して、パラメータは、PUCCHリソースが、第1のタイプのサービスに、第2のタイプのサービスに、または、第1のタイプのサービスと第2のタイプのサービスの両方に関係付けられているか否かを示している。
[00160]
第8の態様では、単独で、または、第1~第7の態様のうちの1つ以上と組み合わせて、第1のコンフィギュレーションのリソースの第1のセットは、第2のコンフィギュレーションのリソースの第2のセットとリソースの同じセットであり、リソースの同じセットの各リソースは、PUCCH送信が第1のタイプのサービスに関係付けられているとき、PUCCH送信に対する第1の識別子に関係付けられ、PUCCH送信が第2のタイプのサービスに関係付けられているとき、PUCCH送信に対する第2の識別子に関係付けられる。
[00161]
第9の態様では、単独で、または、第1~第8の態様のうちの1つ以上と組み合わせて、第1のコンフィギュレーションは、第1のタイプに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第1の複数のコンフィギュレーションのうちの1つである。
[00162]
第10の態様では、単独で、または、第1~第9の態様のうちの1つ以上と組み合わせて、第1のコンフィギュレーションの最大コーディングレートは、第2のコンフィギュレーションの最大コーディングレートとは異なる。
[00163]
図11は、プロセス1100の例示的なブロックを示しているが、いくつかの態様では、プロセス1100は、追加のブロック、より少ないブロック、異なるブロック、または、図11中に描いたものとは異なって構成されているブロックを含んでいてもよい。追加的にまたは代替的に、プロセス1100のブロックのうちの2つ以上を並列に実行してもよい。
[00164]
図12は、本開示のさまざまな態様にしたがう、例えば、UEによって実行される例示的なプロセス1200を図示しているダイヤグラムである。例示的なプロセス1200は、UE(例えば、UE120および/またはこれらに類するもの)が、サービスのタイプにしたがって構成されているPUCCHコンフィギュレーションを使用して、そのサービスのタイプに関係付けられているメッセージを送信することに関係付けられている動作を実行する例である。
[00165]
図12中で示されているように、いくつかの態様では、プロセス1200は、第1のサービスタイプに関係付けられている送信のためのパラメータの第1のセットと、第2のサービスタイプに関係付けられている送信のためのパラメータの第2のセットとを含むPUCCHコンフィギュレーションを受信することを含んでいてもよい(ブロック1210)。例えば、UEは(例えば、受信プロセッサ258、制御装置/プロセッサ280、メモリ282、および/または、これらに類するものを使用して)、上記で説明したように、第1のサービスタイプに関係付けられている送信のためのパラメータの第1のセットと、第2のサービスタイプに関係付けられている送信のためのパラメータの第2のセットとを含むPUCCHコンフィギュレーションを受信してもよい。
[00166]
図12中でさらに示されているように、いくつかの態様では、プロセス1200は、アップリンク制御情報(UCI)を発生させることを含んでいてもよい(ブロック1220)。例えば、UEは(例えば、送信プロセッサ264、制御装置/プロセッサ280、メモリ282、および/または、これらに類するものを使用して)、上記で説明したように、UCIを発生させてもよい。
[00167]
図12中でさらに示されているように、いくつかの態様では、プロセス1200は、PUCCHコンフィギュレーションとメッセージのサービスタイプとにしたがって、UCIを含むメッセージを送信することを含んでいてもよい(ブロック1230)。例えば、UEは(例えば、送信プロセッサ264、制御装置/プロセッサ280、メモリ282、および/または、これらに類するものを使用して)、上記で説明したように、PUCCHコンフィギュレーションとメッセージのサービスタイプとにしたがって、UCIを含むメッセージを送信してもよい。
[00168]
プロセス1200は、以下で説明する、任意の単一の態様または態様の任意の組み合わせ、および/または、ここでの他の箇所で説明する1つ以上の他のプロセスに関連するような、追加の態様を含んでいてもよい。
[00169]
第1の態様では、メッセージのサービスタイプは、基地局から受信したダウンリンク制御情報(DCI)に少なくとも部分的に基づいて決定される。
[00170]
第2の態様では、単独で、または、第1の態様と組み合わせて、パラメータの第1のセットによって示される最大コーディングレートは、パラメータの第2のセットによって示される最大コーディングレートとは異なる。
[00171]
図12は、プロセス1200の例示的なブロックを示しているが、いくつかの態様では、プロセス1200は、追加のブロック、より少ないブロック、異なるブロック、または、図12中に描いたものとは異なって構成されているブロックを含んでいてもよい。追加的にまたは代替的に、プロセス1200のブロックのうちの2つ以上を並列に実行してもよい。
[00172]
図13は、本開示のさまざまな態様にしたがう、例えば、基地局によって実行される例示的なプロセス1300を図示しているダイヤグラムである。例示的なプロセス1300は、BS(例えば、BS110および/またはこれらに類するもの)が複数のタイプのサービス(例えば、eMBBおよびURLLC)に対してPUCCHコンフィギュレーションを実行する例である。
[00173]
図13中で示されているように、いくつかの態様では、プロセス1300は、第1のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHの第1のコンフィギュレーションを決定することを含んでいてもよい(ブロック1310)。例えば、BS110は(例えば、送信プロセッサ220、TX MIMOプロセッサ230、制御装置/プロセッサ240、および/または、これらに類するものを使用して)、上記で説明したように、第1のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHの第1のコンフィギュレーションを決定してもよい。いくつかの態様では、UE120が第1のタイプのサービスを介して通信することが可能であるという表示を受信することに関連して、BS110は第1のコンフィギュレーションを決定してもよい。
[00174]
図13中で示されているように、いくつかの態様では、プロセス1300は、第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定し、第2のタイプのサービスは、第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることを含んでいてもよい(ブロック1320)。例えば、BS110は(例えば、送信プロセッサ220、TX MIMOプロセッサ230、制御装置/プロセッサ240、および/または、これらに類するものを使用して)、上記で説明したように、第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHの第2のコンフィギュレーションを決定してもよい。いくつかの態様では、第2のタイプのサービスは、第1のタイプのサービスのよりもより高い信頼性またはより低いレイテンシに関係付けられている。いくつかの態様では、UE120が第2のタイプのサービスを介して通信することが可能であるという表示を受信することに関連して、BS110は第2のコンフィギュレーションを決定してもよい。
[00175]
図13中で示されているように、いくつかの態様では、プロセス1300は、第1のコンフィギュレーションと第2のコンフィギュレーションとをユーザ機器(UE)に送信することを含んでいてもよい(ブロック1330)。例えば、BS110は(例えば、送信プロセッサ220、TX MIMOプロセッサ230、変調器232、アンテナ234、制御装置/プロセッサ240、および/または、これらに類するものを使用して)、上記で説明したように、第1のコンフィギュレーションと第2のコンフィギュレーションとをUE120に送信してもよい。いくつかの態様では、BS110は、第1のコンフィギュレーションと第2のコンフィギュレーションとを決定することに関連して、第1のコンフィギュレーションと第2のコンフィギュレーションとを送信してもよい。
[00176]
プロセス1300は、以下で説明する、任意の単一の態様または態様の任意の組み合わせ、および/または、ここでの他の箇所で説明する1つ以上の他のプロセスに関連するような、追加の態様を含んでいてもよい。
[00177]
第1の態様において、第1のタイプのサービスは、拡張移動体ブロードバンド(eMBB)サービスを含み、第2のタイプのサービスは、超高信頼性低レイテンシ通信(URLLC)サービスを含んでいる。
[00178]
第2の態様では、単独で、または、第1の態様と組み合わせて、PUCCHの第1のコンフィギュレーションの最大コーディングレートは、第2のPUCCHコンフィギュレーションの最大コーディングレートとは異なる。
[00179]
図13は、プロセス1300の例示的なブロックを示しているが、いくつかの態様では、プロセス1300は、追加のブロック、より少ないブロック、異なるブロック、または、図13中に描いたものとは異なって構成されているブロックを含んでいてもよい。追加的にまたは代替的に、プロセス1300のブロックのうちの2つ以上を並列に実行してもよい。
[00180]
上記の開示は、実例および説明を提供するが、網羅的であること、または、態様を開示した厳密な形態に限定することを意図するものではない。修正およびバリエーションは、上記の開示に照らして行われてもよく、または、態様の実施から取得してもよい。
[00181]
ここで使用するように、コンポーネントという用語は、ハードウェア、ファームウェア、または、ハードウェアとソフトウェアとの組み合わせとして広く解釈されるように意図されている。ここで使用するように、プロセッサは、ハードウェア、ファームウェア、または、ハードウェアとソフトウェアとの組み合わせで実現してもよい。
[00182]
ここで使用するように、しきい値を満たすことは、しきい値よりも大きい、しきい値以上、しきい値未満、しきい値以下、しきい値に等しい、しきい値に等しくない、および/または、これらに類するものである値を指していてもよい。
[00183]
ここで説明するシステムおよび/または方法は、ハードウェア、ファームウェア、または、ハードウェアとソフトウェアとの組み合わせの異なる形態で実現してもよいことが明らかになるだろう。これらのシステムおよび/または方法を実現するために使用される実際の専門制御ハードウェアまたはソフトウェアコードは、態様を限定しない。したがって、システムおよび/または方法の動作および挙動は、特定のソフトウェアコードを参照することなくここで説明されており、ソフトウェアおよびハードウェアは、ここでの説明に少なくとも部分的に基づいて、システムおよび/または方法を実現するように設計できることを理解されたい。
[00184]
特徴の特定の組み合わせが特許請求の範囲に記載され、および/または、本明細書に開示されているが、これらの組み合わせは、さまざまな態様の開示を限定するように意図されていない。実際、これらの特徴の多くは、特許請求の範囲に具体的に記載されていない、および/または、本明細書に開示されていない方法で組み合わせてもよい。以下にリストアップされる各従属請求項は、1つの請求項のみに直接従属しているかもしれないが、さまざまな態様の開示は、請求項セット中の他のあらゆる請求項と組み合わせた各従属請求項を含んでいる。アイテムのリストのうちの「少なくとも1つ」に言及するフレーズは、単一の要素を含む、それらのアイテムのうちの任意の組み合わせに言及する。例として、「a、b、または、cのうちの少なくとも1つ」は、a、b、c、a-b、a-c、b-c、および、a-b-cとともに、複数の同じ要素の任意の組み合わせ(例えば、a-a、a-a-a、a-a-b、a-a-c、a-b-b、a-c-c、b-b、b-b-b、b-b-c、c-c、および、c-c-c、または、a、b、および、cの他の何らかの順序)をカバーするように意図されている。
[00185]
ここで使用される要素、動作、または、命令は、そのように明示的に説明されていない限り、重要または不可欠であるとして解釈すべきではない。また、ここで使用されるように、冠詞「a」および「an」は、1つ以上のアイテムを含むように意図され、「1つ以上」と交換可能に使用されているかもしれない。さらに、ここで使用されるように、「セット」および「グループ」という用語は、1つ以上のアイテム(例えば、関連アイテム、非関連アイテム、関連アイテムと非関連アイテムの組み合わせ、および/または、これらに類するもの)を含むように意図され、「1つ以上」と交換可能に使用されているかもしれない。1つのアイテムのみが意図される場合、用語「1つのみ」または同様の言葉が使用される。また、ここで使用されるように、「有する(has)」、「有する(have)」、「有している(having)」、および/または、これらに類するもののような用語は、拡張可能な用語であるように意図されている。さらに、「に基づいて」というフレーズは、別な方法で明示的に述べられていない限り、「に少なくとも部分的に基づいて」を意味するように意図されている。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
[C1]
ユーザ機器(UE)によって実行されるワイヤレス通信の方法において、
物理アップリンク制御チャネル(PUCCH)送信が第1のタイプのサービスに関係付けられているかまたは第2のタイプのサービスに関係付けられているかを決定し、前記第2のタイプのサービスは、前記第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることと、
前記PUCCH送信が前記第1のタイプのサービスに関係付けられているとき、リソースの第1のセットに少なくとも部分的に基づいて、または、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているとき、リソースの第2のセットに少なくとも部分的に基づいて、前記PUCCH送信を送信することとを含む方法。
[C2]
前記第1のタイプのサービスは、拡張移動体ブロードバンド(eMBB)サービスを含み、前記第2のタイプのサービスは、超高信頼性低レイテンシ通信(URLLC)サービスを含むC1記載の方法。
[C3]
前記リソースの第1のセットは、前記第1のタイプのサービスに対して構成されている複数のリソースセットを含むC1記載の方法。
[C4]
前記リソースの第2のセットは、前記第2のタイプのサービスに対して構成されている複数のリソースセットを含むC1記載の方法。
[C5]
前記PUCCH送信は、
ハイブリッド自動再送要求肯定応答(HARQ-ACK)情報、
サービス要求(SR)、または、
チャネル状態情報(CSI)報告のうちの少なくとも1つを含むC1記載の方法。
[C6]
前記ACK/NACKは、動的スケジューリングまたは半永続的スケジューリング(SPS)に関係付けられているC5記載の方法。
[C7]
前記リソースの第1のセットは4つのリソースセットを含み、前記リソースの第2のセットは4つ未満のリソースセットを含むC1記載の方法。
[C8]
前記リソースの第1のセットは、前記リソースの第2のセットとは異なるC1記載の方法。
[C9]
前記リソースの第2のセット中のリソースセットの数は、前記リソースの第1のセット中のリソースセットの数よりも少ないC1記載の方法。
[C10]
前記リソースの第1のセットのうちの少なくとも1つのリソースセットは、前記リソースの第2のセット中に含まれるリソースセットと同じリソースセットであるC1記載の方法。
[C11]
前記リソースの第2のセットの各セット内のリソースの数は、前記リソースの第1のセットの各セット内のリソースの数よりも少ないC1記載の方法。
[C12]
前記UEは、前記PUCCH送信に関係して基地局から受信したダウンリンク制御情報(DCI)中のPUCCHリソースインジケータフィールドのビット幅に少なくとも部分的に基づいて、前記リソースの第1のセットまたは前記リソースの第2のセットの各セット内のリソースの数を決定するように構成されているC1記載の方法。
[C13]
前記PUCCH送信は、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているという決定に少なくとも部分的に基づいて、前記リソースの第2のセットの2つ以上のリソース上で送信されるC1記載の方法。
[C14]
前記PUCCH送信は、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているという決定に少なくとも部分的に基づいて、前記リソースの第2のセットの2つのリソース上で、少なくとも2つの送信アンテナを介して送信されるC1記載の方法。
[C15]
前記リソースの第2のセットのうちの1つのセットの少なくとも2つのリソースは、同じ識別子を共有し、前記PUCCH送信は、前記識別子が前記PUCCH送信に関係して受信されるとき、前記少なくとも2つのリソースを使用して送信されるC1記載の方法。
[C16]
前記PUCCH送信は、基地局から、前記PUCCH送信に関係して、インデックスと半静的に受信されるコンフィギュレーションとを受信することに少なくとも部分的に基づいて、前記リソースの第2のセットの1つ以上のリソースを使用して送信されるC1記載の方法。
[C17]
前記リソースの第2のセットのリソースは、前記PUCCH送信に関連する使用のために、前記リソースの第1のセットのリソースとは異なって識別されるC1記載の方法。
[C18]
前記リソースの第2のセットのリソースは、異なるPUCCHフォーマットを使用することに関連して、前記PUCCH送信に関連する使用のために、前記リソースの第1のセットのリソースとは異なって識別されるC17記載の方法。
[C19]
前記リソースの第1のセットのリソースは、前記リソースの第1のセットのリソースに関係付けられているパラメータの第1の値に少なくとも部分的に基づいて、前記第1のタイプのサービスに関係する使用のために識別され、または、前記リソースの第2のセットのリソースは、前記リソースの第2のセットのリソースに関係付けられている前記パラメータの第2の値に少なくとも部分的に基づいて、前記第2のタイプのサービスに関係する使用のために識別されるC1記載の方法。
[C20]
前記PUCCH送信のリソースに対して、パラメータは、前記パラメータの値に少なくとも部分的に基づいて、前記リソースが、前記第1のタイプのサービスに、前記第2のタイプのサービスに、または、前記第1のタイプのサービスと前記第2のタイプのサービスの両方に関係付けられているか否かを示すC1記載の方法。
[C21]
前記パラメータは、前記PUCCH送信に対する前記リソースのコンフィギュレーション内に含まれるC20記載の方法。
[C22]
前記パラメータの値は、前記リソースの第1のセットと前記リソースの第2のセットの同じリソースが、前記第1のタイプのサービスと前記第2のタイプのサービスとに関係付けられていることを示すC20記載の方法。
[C23]
前記リソースの第1のセットは、前記リソースの第2のセットとリソースの同じセットであり、前記リソースの同じセットの各リソースは、前記PUCCH送信が前記第1のタイプのサービスに関係付けられているとき、前記PUCCH送信に対する第1の識別子に関係付けられ、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているとき、前記PUCCH送信に対する第2の識別子に関係付けられるC1記載の方法。
[C24]
前記PUCCH送信は、前記第1のタイプのサービスまたは前記第2のタイプのサービスに関係付けられているインデックスを示すダウンリンク制御情報を受信することに少なくとも部分的に基づいて、前記リソースの同じセットのうちの1つを使用して送信されるC23記載の方法。
[C25]
開始シンボルパラメータは、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているときとは異なる開始シンボルを、前記PUCCH送信が前記第1のタイプのサービスに関係付けられるときに識別するC1記載の方法。
[C26]
前記PUCCH送信が前記第1のタイプのサービスに関係付けられているときの、前記開始シンボルパラメータは、前記PUCCH送信に対するスロットに関する相対インデックスを識別するC25記載の方法。
[C27]
前記PUCCH送信が前記第2のタイプのサービスに関係付けられているときの、前記開始シンボルパラメータは、ダウンリンク制御情報(DCI)中のシグナリングに関係付けられているタイミングを識別するC25記載の方法。
[C28]
前記PUCCH送信が前記第1のタイプのサービスに関係付けられているとき、前記PUCCH送信中のハイブリッド自動再送要求肯定応答(HARQ-ACK)情報は、第1のダウンリンク割り当てインデックス(DAI)動作にしたがって決定され、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているとき、前記PUCCH送信中の前記HARQ-ACK情報は、第2のDAI動作にしたがって決定されるC1記載の方法。
[C29]
前記PUCCH送信が、前記第1のタイプのサービスに関係付けられている第1のPUCCH送信であり、前記第2のタイプのサービスに関係付けられている第2のPUCCH送信が、前記第1のPUCCH送信のシンボルとオーバーラップするシンボルを使用して送信されることになるとき、前記オーバーラップするシンボルは、前記第1のPUCCH送信からドロップされるC1記載の方法。
[C30]
基地局(BS)によって実行されるワイヤレス通信の方法において、
第1のタイプのサービスに関係付けられている物理アップリンク制御チャネル(PUCCH)送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを決定することと、
第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定し、前記第2のタイプのサービスは、前記第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることと、
前記第1のコンフィギュレーションと前記第2のコンフィギュレーションとをユーザ機器(UE)に送信することとを含む方法。
[C31]
前記第1のタイプのサービスは、拡張移動体ブロードバンド(eMBB)サービスを含み、前記第2のタイプのサービスは、超高信頼性低レイテンシ通信(URLLC)サービスを含むC30記載の方法。
[C32]
前記第1のコンフィギュレーションは、前記第2のコンフィギュレーションとは異なるC30記載の方法。
[C33]
前記第1のコンフィギュレーション中に含まれるPUCCHリソースのセットは、前記第2のコンフィギュレーション中に含まれるPUCCHリソースのセットとは異なるC30記載の方法。
[C34]
前記第2のコンフィギュレーションは、前記第1のコンフィギュレーションよりもPUCCHリソースのより少ないセットを含むC30記載の方法。
[C35]
前記第2のコンフィギュレーション中に含まれるPUCCHリソースの各セット中のPUCCHリソースの数は、前記第1のコンフィギュレーション中に含まれるPUCCHリソースの各セット中のPUCCHリソースの数よりも少ないC30記載の方法。
[C36]
ダウンリンク制御情報(DCI)中のPUCCHリソースインジケータのビット幅は、前記第2のコンフィギュレーション中に含まれるPUCCHリソースの各セット中のPUCCHリソースの数にしたがっている前記第2のタイプのサービスに対応するC30記載の方法。
[C37]
前記第1のコンフィギュレーションおよび前記第2のコンフィギュレーションの各PUCCHリソースに対して、パラメータは、前記PUCCHリソースが、前記第1のタイプのサービスに、前記第2のタイプのサービスに、または、前記第1のタイプのサービスと前記第2のタイプのサービスの両方に関係付けられているか否かを示すC30記載の方法。
[C38]
前記第1のコンフィギュレーションのリソースの第1のセットは、前記第2のコンフィギュレーションのリソースの第2のセットとリソースの同じセットであり、前記リソースの同じセットの各リソースは、前記PUCCH送信が前記第1のタイプのサービスに関係付けられているとき、PUCCH送信に対する第1の識別子に関係付けられ、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているとき、前記PUCCH送信に対する第2の識別子に関係付けられるC30記載の方法。
[C39]
前記第1のコンフィギュレーションは、前記第1のタイプに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第1の複数のコンフィギュレーションのうちの1つであるC30記載の方法。
[C40]
前記第1のコンフィギュレーションの最大コーディングレートは、前記第2のコンフィギュレーションの最大コーディングレートとは異なるC30記載の方法。
[C41]
ユーザ機器(UE)によって実行されるワイヤレス通信の方法において、
第1のサービスタイプに関係付けられている送信のためのパラメータの第1のセットと、第2のサービスタイプに関係付けられている送信のためのパラメータの第2のセットとを含む物理アップリンク制御チャネル(PUCCH)コンフィギュレーションを受信することと、
アップリンク制御情報(UCI)を発生させることと、
前記PUCCHコンフィギュレーションとメッセージのサービスタイプとにしたがって、前記UCIを含む前記メッセージを送信することとを含む方法。
[C42]
前記メッセージのサービスタイプは、基地局から受信したダウンリンク制御情報(DCI)に少なくとも部分的に基づいて決定されるC41記載の方法。
[C43]
前記パラメータの第1のセットによって示される最大コーディングレートは、前記パラメータの第2のセットによって示される最大コーディングレートとは異なるC41記載の方法。
[C44]
ワイヤレス通信のためのユーザ機器(UE)において、
メモリと、
前記メモリに結合されている1つ以上のプロセッサとを具備し、
前記メモリおよび前記1つ以上のプロセッサは、
物理アップリンク制御チャネル(PUCCH)送信が第1のタイプのサービスに関係付けられているかまたは第2のタイプのサービスに関係付けられているかを決定し、前記第2のタイプのサービスは、前記第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられているように、
前記PUCCH送信が前記第1のタイプのサービスに関係付けられているとき、リソースの第1のセットを使用して、または、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているとき、リソースの第2のセットを使用して、前記PUCCH送信を送信するように構成されているUE。

Claims (15)

  1. ユーザ機器(UE)によって実行されるワイヤレス通信の方法において、
    基地局(BS)からダウンリンク制御情報(DCI)を受信することと、
    物理アップリンク制御チャネル(PUCCH)送信が第1のタイプのサービスに関係付けられているかまたは第2のタイプのサービスに関係付けられているかを決定し、前記第2のタイプのサービスは、前記第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることと、
    前記PUCCH送信が前記第1のタイプのサービスに関係付けられているとき、リソースの第1のセットに少なくとも部分的に基づいて、または、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているとき、リソースの第2のセットに少なくとも部分的に基づいて、前記PUCCH送信を送信することとを含み、
    前記PUCCH送信が前記DCI中に含まれるダウンリンク割り当てインデックス(DAI)フィールドに基づいて決定される、および、
    前記第1のタイプのサービスに対する前記DAIフィールドの第1のビット幅が、前記第2のタイプのサービスに対する前記DAIフィールドの第2のビット幅とは異なる、
    方法。
  2. 前記第1のタイプのサービスは、拡張移動体ブロードバンド(eMBB)サービスを含み、前記第2のタイプのサービスは、超高信頼性低レイテンシ通信(URLLC)サービスを含む請求項1記載の方法。
  3. 前記リソースの第1のセットは、前記第1のタイプのサービスに対して構成されている複数のリソースセットを含み、前記リソースの第2のセットは、前記第2のタイプのサービスに対して構成されている複数のリソースセットを含む、請求項1記載の方法。
  4. 前記PUCCH送信は、
    ハイブリッド自動再送要求肯定応答(HARQ-ACK)情報、
    サービス要求(SR)、または、
    チャネル状態情報(CSI)報告のうちの少なくとも1つを含む請求項1記載の方法。
  5. 前記UEは、前記PUCCH送信に関係して前記基地局から受信したDCI中のPUCCHリソースインジケータフィールドのビット幅に少なくとも部分的に基づいて、前記リソースの第1のセットまたは前記リソースの第2のセットの各セット内のリソースの数を決定するように構成されている請求項1記載の方法。
  6. 前記PUCCH送信は、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているという決定に少なくとも部分的に基づいて、前記リソースの第2のセットの2つのリソース上で、少なくとも2つの送信アンテナを介して送信される請求項1記載の方法。
  7. 前記リソースの第1のセットのリソースは、前記リソースの第1のセットのリソースに関係付けられているパラメータの第1の値に少なくとも部分的に基づいて、前記第1のタイプのサービスに関係する使用のために識別され、または、前記リソースの第2のセットのリソースは、前記リソースの第2のセットのリソースに関係付けられている前記パラメータの第2の値に少なくとも部分的に基づいて、前記第2のタイプのサービスに関係する使用のために識別される請求項1記載の方法。
  8. 前記PUCCH送信のリソースに対して、パラメータは、前記パラメータの値に少なくとも部分的に基づいて、前記リソースが、前記第1のタイプのサービスに、前記第2のタイプのサービスに、または、前記第1のタイプのサービスと前記第2のタイプのサービスの両方に関係付けられているか否かを示し、
    前記パラメータは、前記PUCCH送信に対する前記リソースのコンフィギュレーション内に含まれ、
    前記パラメータの値は、前記リソースの第1のセットと前記リソースの第2のセットの同じリソースが、前記第1のタイプのサービスと前記第2のタイプのサービスとに関係付けられていることを示す、請求項1記載の方法。
  9. 前記リソースの第1のセットは、前記リソースの第2のセットとリソースの同じセットであり、前記リソースの同じセットの各リソースは、前記PUCCH送信が前記第1のタイプのサービスに関係付けられているとき、前記PUCCH送信に対する第1の識別子に関係付けられ、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているとき、前記PUCCH送信に対する第2の識別子に関係付けられ
    前記PUCCH送信は、前記第1のタイプのサービスまたは前記第2のタイプのサービスに関係付けられているインデックスを示すDCIを受信することに少なくとも部分的に基づいて、前記リソースの同じセットのうちの1つを使用して送信される、
    請求項1記載の方法。
  10. 開始シンボルパラメータは、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているときとは異なる開始シンボルを、前記PUCCH送信が前記第1のタイプのサービスに関係付けられるときに識別し、前記PUCCH送信が前記第1のタイプのサービスに関係付けられているときの、前記開始シンボルパラメータは、前記PUCCH送信に対するスロットに関する相対インデックスを識別し、前記PUCCH送信が前記第2のタイプのサービスに関係付けられているときの、前記開始シンボルパラメータは、DCI中のシグナリングに関係付けられているタイミングを識別する、請求項1に記載の方法。
  11. 基地局(BS)によって実行されるワイヤレス通信の方法において、
    第1のタイプのサービスに関係付けられている物理アップリンク制御チャネル(PUCCH)送信のために使用されることになるPUCCHリソースの第1のコンフィギュレーションを決定することと、
    第2のタイプのサービスに関係付けられているPUCCH送信のために使用されることになるPUCCHリソースの第2のコンフィギュレーションを決定し、前記第2のタイプのサービスは、前記第1のタイプのサービスよりもより高い信頼性またはより低いレイテンシに関係付けられていることと、
    前記第1のコンフィギュレーションと前記第2のコンフィギュレーションとダウンリンク制御情報(DCI)とをユーザ機器(UE)に送信することとを含み、
    前記PUCCH送信が前記DCI中に含まれるダウンリンク割り当てインデックス(DAI)フィールドに基づいて決定される、および、
    前記第1のタイプのサービスに対する前記DAIフィールドの第1のビット幅が、前記第2のタイプのサービスに対する前記DAIフィールドの第2のビット幅とは異なる、方法。
  12. 前記第1のタイプのサービスは、拡張移動体ブロードバンド(eMBB)サービスを含み、前記第2のタイプのサービスは、超高信頼性低レイテンシ通信(URLLC)サービスを含む請求項11記載の方法。
  13. I中のPUCCHリソースインジケータのビット幅は、前記第2のコンフィギュレーション中に含まれるPUCCHリソースの各セット中のPUCCHリソースの数にしたがっている前記第2のタイプのサービスに対応する請求項11記載の方法。
  14. 前記第1のコンフィギュレーションおよび前記第2のコンフィギュレーションの各PUCCHリソースに対して、パラメータは、前記PUCCHリソースが、前記第1のタイプのサービスに、前記第2のタイプのサービスに、または、前記第1のタイプのサービスと前記第2のタイプのサービスの両方に関係付けられているか否かを示す請求項11記載の方法。
  15. ワイヤレス通信のためのユーザ機器(UE)において、
    メモリと、
    前記メモリに結合されている1つ以上のプロセッサとを具備し、
    前記メモリおよび前記1つ以上のプロセッサは、請求項1―10のいずれかの方法ステップを実行するように構成されている、UE。
JP2020562689A 2018-05-10 2019-05-09 超高信頼性低レイテンシ通信(urllc)に対する物理アップリンク制御チャネル(pucch)リソース割り振り Active JP7206296B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862669941P 2018-05-10 2018-05-10
US62/669,941 2018-05-10
US16/406,667 US10980049B2 (en) 2018-05-10 2019-05-08 Allocating physical uplink control channel (PUCCH) resources for ultra-reliable low latency communication (URLLC)
US16/406,667 2019-05-08
PCT/US2019/031544 WO2019217696A1 (en) 2018-05-10 2019-05-09 Allocating physical uplink control channel (pucch) resources for ultra-reliable low latency communication (urllc)

Publications (3)

Publication Number Publication Date
JP2021523617A JP2021523617A (ja) 2021-09-02
JPWO2019217696A5 JPWO2019217696A5 (ja) 2022-04-25
JP7206296B2 true JP7206296B2 (ja) 2023-01-17

Family

ID=68463486

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020562689A Active JP7206296B2 (ja) 2018-05-10 2019-05-09 超高信頼性低レイテンシ通信(urllc)に対する物理アップリンク制御チャネル(pucch)リソース割り振り

Country Status (10)

Country Link
US (1) US10980049B2 (ja)
EP (1) EP3791521A1 (ja)
JP (1) JP7206296B2 (ja)
KR (1) KR20210008499A (ja)
CN (1) CN112088516B (ja)
AU (1) AU2019266295B2 (ja)
BR (1) BR112020022764A2 (ja)
SG (1) SG11202010015WA (ja)
TW (1) TWI795564B (ja)
WO (1) WO2019217696A1 (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020504939A (ja) * 2017-06-15 2020-02-13 エルジー エレクトロニクス インコーポレイティド 無線通信システムにおいて端末と基地局の間の確認応答情報を送受信する方法及びそれを支援する装置
TWI715044B (zh) * 2018-05-22 2021-01-01 新加坡商 聯發科技(新加坡)私人有限公司 移動通信中對於不同服務類型報告混合自動重複請求-確認資訊的方法和裝置
CN112335284B (zh) * 2018-06-20 2023-10-20 鸿颖创新有限公司 用于处理eMBB和URLLC同时传输的方法和装置
JP2021532652A (ja) * 2018-07-25 2021-11-25 ソニーグループ株式会社 基地局、ユーザ機器、回線、移動通信システム及び方法
TWI697244B (zh) * 2018-08-07 2020-06-21 財團法人資訊工業策進會 用於行動通訊系統之使用者裝置及基地台
WO2020029816A1 (en) * 2018-08-10 2020-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for channel state information reporting
WO2020064967A1 (en) * 2018-09-27 2020-04-02 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Urllc dai and lti
CN111083782B (zh) * 2018-10-19 2023-09-08 荣耀终端有限公司 一种被用于无线通信的用户设备、基站中的方法和装置
KR20210124209A (ko) * 2019-01-09 2021-10-14 아이디에이씨 홀딩스, 인크. 초신뢰성 송신들의 향상된 제어 시그널링을 위한 방법들, 장치 및 시스템들
CN113303009A (zh) * 2019-01-10 2021-08-24 夏普株式会社 低强度物理上行链路控制信道(pucch)增强和资源配置
CN116743323A (zh) 2019-05-02 2023-09-12 韦勒斯标准与技术协会公司 无线通信系统中的下行数据接收和harq-ack传输的方法、装置和系统
US11564223B2 (en) * 2019-05-30 2023-01-24 Electronics And Telecommunications Research Institute Method and apparatus for uplink communication in unlicensed band
US11818072B2 (en) * 2019-07-02 2023-11-14 Comcast Cable Communications, Llc Wireless resource determination and use
CN112398611B (zh) * 2019-08-15 2022-09-27 上海朗帛通信技术有限公司 一种被用于无线通信的节点中的方法和装置
EP4017184B1 (en) * 2019-11-08 2023-09-27 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Resource set configuration method, terminal, and network device
US11411779B2 (en) 2020-03-31 2022-08-09 XCOM Labs, Inc. Reference signal channel estimation
KR20230091910A (ko) 2020-10-19 2023-06-23 엑스콤 랩스 인코퍼레이티드 무선 통신 시스템에서의 참조 신호
WO2022093988A1 (en) 2020-10-30 2022-05-05 XCOM Labs, Inc. Clustering and/or rate selection in multiple-input multiple-output communication systems

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019522423A (ja) 2016-07-29 2019-08-08 サムスン エレクトロニクス カンパニー リミテッド ダウンリンクデータ送受信方法及びダウンリンクデータ送信基地局並びにダウンリンクデータ受信端末

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8873439B2 (en) * 2010-03-25 2014-10-28 Qualcomm Incorporated Subframe dependent physical uplink control channel (PUCCH) region design
KR101669777B1 (ko) * 2012-10-26 2016-10-26 인텔 코포레이션 사용자 플레인 혼잡의 리포트
EP3349387B1 (en) * 2015-09-09 2021-10-27 LG Electronics Inc. Method and apparatus for transmitting signal in wireless communication system
SG10202001291QA (en) * 2016-04-08 2020-04-29 Idac Holdings Inc Phy layer multiplexing of different types of traffic in 5g systems
WO2017179915A2 (ko) * 2016-04-12 2017-10-19 고려대학교 산학협력단 동일한 자원으로 광대역 트래픽과 기계간 통신 트래픽 또는 초저지연 통신 트래픽을 동시에 다중화하여 전송하는 장치 및 그 방법
CN114866209A (zh) * 2016-07-19 2022-08-05 日本电气株式会社 用于执行通信的方法和设备
WO2018031638A1 (en) * 2016-08-11 2018-02-15 Intel IP Corporation Uplink transmission request for multiple numerologies
CN107734676B (zh) * 2016-08-12 2021-06-08 中兴通讯股份有限公司 一种数据传输的方法和装置
US10412719B2 (en) * 2016-10-21 2019-09-10 Qualcomm Incorporated Service type based control search space monitoring
CN109906576B (zh) * 2016-11-04 2022-05-24 摩托罗拉移动有限责任公司 识别用于发送第一上行链路信道的资源
US10484976B2 (en) * 2017-01-06 2019-11-19 Sharp Kabushiki Kaisha Signaling, procedures, user equipment and base stations for uplink ultra reliable low latency communications
EP3582563B1 (en) * 2017-02-05 2022-08-10 LG Electronics Inc. Method and device for transmitting/receiving signal associated with grant-free resource in wireless communication system
US10411864B2 (en) * 2017-02-06 2019-09-10 Qualcomm Incorporated Resource allocation for physical uplink control channel (PUCCH)
KR102316752B1 (ko) * 2017-03-24 2021-10-25 삼성전자 주식회사 복수의 통신 서비스를 제공하기 위한 정보 송수신 방법 및 장치
WO2018203440A1 (ja) * 2017-05-02 2018-11-08 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 端末及び通信方法
US20180324786A1 (en) * 2017-05-05 2018-11-08 Nokia Technologies Oy Resource determination for uplink control channel for wireless networks
US10944501B2 (en) * 2017-12-15 2021-03-09 Mediatek Singapore Pte. Ltd. Method and apparatus for determining modulation and coding scheme table in mobile communications

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019522423A (ja) 2016-07-29 2019-08-08 サムスン エレクトロニクス カンパニー リミテッド ダウンリンクデータ送受信方法及びダウンリンクデータ送信基地局並びにダウンリンクデータ受信端末

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MediaTek Inc.,Analysis of Compact DCI[online],3GPP TSG RAN WG1 #92 R1-1801675,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_92/Docs/R1-1801675.zip>,2018年02月17日
Nokia, Nokia Shanghai Bell,PUCCH Resource Allocation[online],3GPP TSG RAN WG1 #91 R1-1720014,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_91/Docs/R1-1720014.zip>,2017年11月17日

Also Published As

Publication number Publication date
SG11202010015WA (en) 2020-12-30
AU2019266295B2 (en) 2023-05-18
WO2019217696A1 (en) 2019-11-14
US10980049B2 (en) 2021-04-13
TW201947981A (zh) 2019-12-16
JP2021523617A (ja) 2021-09-02
KR20210008499A (ko) 2021-01-22
TWI795564B (zh) 2023-03-11
BR112020022764A2 (pt) 2021-02-02
CN112088516A (zh) 2020-12-15
US20190349973A1 (en) 2019-11-14
AU2019266295A1 (en) 2020-11-12
EP3791521A1 (en) 2021-03-17
CN112088516B (zh) 2023-11-14

Similar Documents

Publication Publication Date Title
JP7206296B2 (ja) 超高信頼性低レイテンシ通信(urllc)に対する物理アップリンク制御チャネル(pucch)リソース割り振り
JP7314167B2 (ja) 物理アップリンク共有チャネル通信と物理アップリンク制御チャネル通信の選択的な多重化
TWI818048B (zh) 實體上行鏈路控制通道重複配置
TWI813682B (zh) 用於子時槽時域資源配置的訊號傳遞
JP7330990B2 (ja) 送信ギャップ構成
JP7441925B2 (ja) システム情報レートマッチング
TW202110141A (zh) 處理存取鏈路與側鏈路之間的碰撞
KR20200061357A (ko) 듀얼-rat 통신에 대한 시분할 멀티플렉싱을 위한 기법들 및 장치들
KR20200073226A (ko) Rach(random access channel) 프로시저를 위한 업링크 대역폭 부분을 구성하기 위한 기법들 및 장치들
CN111919488B (zh) 选择用于信道状态信息的物理上行链路控制信道(pucch)资源
CN111771347A (zh) 在新无线电中的动态下行链路控制信息定时指示
WO2019192447A1 (en) Transmitting data in a control channel
EP3785387A1 (en) Uplink control information payload size
WO2020197851A1 (en) Single downlink control information for joint downlink and uplink allocation
TW202005315A (zh) 用於決定與通道狀態資訊參考信號(csi-rs)有關的上行鏈路傳輸等時線的技術和裝置
CN112956137A (zh) 波束管理信令
KR20200096527A (ko) 시분할 듀플렉스 무선 통신 시스템들에서 신뢰할 수 있는 낮은 레이턴시 동작들
CN114270768A (zh) 针对非许可频谱中的新无线电的信道状态信息参考信号处理
JP7234230B2 (ja) ランダムアクセスプロシージャメッセージのためのリソース割振り
WO2020020024A1 (en) Utilization of a control region for downlink transmission
US10856284B2 (en) Resource allocation for a short transmission time interval (STTI) system

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220415

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220415

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20221206

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230104

R150 Certificate of patent or registration of utility model

Ref document number: 7206296

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150