図1Aは、1つまたは複数の開示される実施形態が実施され得る例示的な通信システム100を示す図である。通信システム100は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数の無線ユーザに提供する多重アクセスシステムであることができる。通信システム100は、複数の無線ユーザが、無線帯域幅を含むシステム資源の共有を通じてこのようなコンテンツにアクセスすることを可能にする。例えば、通信システム100は、コード分割多重アクセス(CDMA)、時分割多重アクセス(TDMA)、周波数分割多重アクセス(FDMA)、直交FDMA(OFDMA)、単一キャリアFDMA(SC−FDMA)、ゼロテールユニークワードDFT拡散OFDM(ZT UW DTS−s OFDM)、ユニークワードOFDM(UW−OFDM)、リソースブロックフィルタ処理済みOFDM、フィルタバンクマルチキャリア(FBMC)などの1つまたは複数のチャネルアクセス方法を採用することができる。
図1Aに示されるように、通信システム100は、無線送受信ユニット(WTRU)102a、102b、102c、102d、RAN104/113、CN106/115、公衆交換電話回線網(PSTN)108、インターネット110、および他のネットワーク112を含むことができるが、開示される実施形態は任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を考慮することが諒解されよう。WTRU102a、102b、102c、102dの各々は、無線環境において動作および/または通信するように構成される任意のタイプのデバイスであることができる。例えば、いずれかが「局」および/または「STA」として参照される場合があるWTRU102a、102b、102c、102dは、無線信号を送信および/または受信するように構成され得、ユーザ機器(UE)、移動局、固定またはモバイル加入者ユニット、サブスクリプションに基づくユニット、ページャ、セルラ電話、PDA、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、ホットスポットまたはMi−Fiデバイス、IoTデバイス、腕時計または他のウェアラブル、ヘッドマウントディスプレイ(HMD)、車両、ドローン、医療デバイスおよびアプリケーション(例えば、遠隔手術)、産業用デバイスおよびアプリケーション(例えば、産業および/または自動処理チェーンコンテキストで動作するロボットおよび/または他の無線デバイス)、家庭用電子機器デバイス、商用および/または産業用無線ネットワーク上で動作するデバイスなどを含み得る。WTRU102a、102b、102cおよび102dのいずれかは、互換的にUEとして参照される場合がある。
通信システム100はまた、基地局114aおよび/または基地局114bをも含むことができる。基地局114a、114bの各々は、CN106/115、インターネット110、および/または他のネットワーク112などの1つまたは複数の通信ネットワークへのアクセスを容易にするために、WTRU102a、102b、102c、102dの少なくとも1つと無線でインターフェースするように構成される任意のタイプのデバイスであることができる。例えば、基地局114a、114bは、ベーストランシーバ基地局(BTS)、Node−B、eNode B、Home Node B、Home eNode B、gNB、NR NodeB、サイトコントローラ、アクセスポイント(AP)、無線ルータなどであることができる。基地局114a、114bは各々単一の要素として描かれているが、基地局114a、114bは、任意の数の相互接続された基地局および/またはネットワーク要素を含んでもよいことが諒解されよう。
基地局114aは、RAN104/113の一部であってもよく、これは、基地局コントローラ(BSC)、無線通信ネットワークコントローラ(RNC)、中継ノードなどの、他の基地局および/またはネットワーク要素(図示せず)も含むことができる。基地局114aおよび/または基地局114bは、セル(図示せず)として参照される場合がある1つまたは複数の搬送波周波数において無線信号を送信および/また受信するように構成されることができる。これらの周波数は、認可スペクトル、無認可スペクトル、または認可スペクトルと無認可スペクトルとの組み合わせ中にあり得る。セルは、比較的固定され得るか、または時間とともに変化し得る特定の地理的領域に無線サービスのためのカバレージを与えることができる。セルは、複数のセルセクタにさらに分割されることができる。例えば、基地局114aに関連付けられるセルは、3つのセクタに分割されることができる。従って、1つの実施形態では、基地局114aは、3つの送受信機、すなわち、セルのセクタごとに1つずつ、を含むことができる。一実施形態において、基地局114aはMIMO技術を採用してもよく、セルのセクタごとに複数の送受信機を利用してもよい。例えば、所望の空間的方向内で信号を送信および/または受信するために、ビームフォーミングが使用され得る。
基地局114a、114bは、エアインターフェース116を介してWTRU102a、102b、102c、102dの1つまたは複数と通信することができ、このエアインターフェースは、任意の適切な無線通信リンク(例えば、無線周波数(RF)、マイクロ波、センチメートル波、マイクロメートル波、赤外線(IR)、紫外線(UV)、可視光など)であることができる。エアインターフェース116は、任意の適切な無線通信アクセス技術(RAT)を使用して確立されることができる。
より具体的には、上記のように、通信システム100は、多重アクセスシステムであることができ、CDMA、TDMA、FDMA、OFDMA、SC−FDMAなどの1つまたは複数のチャネルアクセス方式を採用することができる。例えば、RAN104/113内の基地局114aおよびWTRU102a、102b、102cは、広帯域CDMA(WCDMA(登録商標))を使用してエアインターフェース115/116/117を確立することができる、ユニバーサルモバイルテレコミュニケーションシステム(UMTS)地上波無線通信アクセス(UTRA)などの無線技術を実施することができる。WCDMAは、高速パケットアクセス(HSPA)および/または発展型HSPA(Evolved HSPA)(HSPA+)などの通信プロトコルを含むことができる。HSPAは、高速ダウンリンク(DL)パケットアクセス(HSDPA)および/または高速ULパケットアクセス(HSUPA)を含むことができる。
一実施形態において、基地局114aおよびWTRU102a、102b、102cは、ロングタームエボリューション(LTE)および/またはLTE−Advanced(LTE−A)および/またはLTE−Advanced Pro(LTE−A Pro)を使用してエアインターフェース116を確立することができる、発展型UMTS地上波無線通信アクセス(E−UTRA)などの無線技術を実施してもよい。
一実施形態において、基地局114aおよびWTRU102a、102b、102cは、新無線(NR)を使用してエアインターフェース116を確立することができる、NR無線アクセスなどの無線技術を実施することができる。
一実施形態では、基地局114aおよびWTRU102a、102b、102cは、複数の無線アクセス技術を実施することができる。例えば、基地局114aおよびWTRU102a、102b、102cは、例えば、デュアル接続性(DC)原理を使用してLTE無線アクセスとNR無線アクセスとをともに実施することができる。従って、WTRU102a、102b、102cによって利用されるエアインターフェースは、複数のタイプの無線アクセス技術および/または複数のタイプの基地局(例えば、eNBおよびgNB)との間で送られる送信によって特徴づけられ得る。
他の実施形態において、基地局114aおよびWTRU102a、102b、102cは、IEEE802.11(すなわち、WiFi)、IEEE802.16(すなわち、WiMAX)、CDMA2000、CDMA2000 1X、CDMA2000EV−DO、IS−2000(Interim Standard2000)、IS−95(Interim Standard95)、IS−856(Interim Standard856)、移動体通信用グローバルシステム(GSM(登録商標))、GSM進化型高速データレート(EDGE)、GSM EDGE(GERAN)などの無線技術を実施してもよい。
図1A中の基地局114bは、例えば、無線ルータ、Home Node B、Home eNode B、またはアクセスポイントであることができ、職場、家庭、車両、構内、産業設備、(例えば、ドローンが使用するための)空中回廊、道路などの局所的領域における無線接続を容易にするために任意の適切なRATを利用することができる。1つの実施形態では、基地局114bおよびWTRU102c、102dは、無線ローカルエリアネットワーク(WLAN)を確立するためにIEEE802.11などの無線技術を実施することができる。一実施形態では、基地局114bおよびWTRU102c、102dは、無線パーソナルエリアネットワーク(WPAN)を確立するために、IEEE802.15などの無線技術を実施してもよい。別の実施形態では、基地局114bおよびWTRU102c、102dは、ピコセルまたはフェムトセルを確立するためにセルラベースのRAT(例えば、WCDMA、CDMA2000、GSM、LTE、LTE−A、LTE−A Pro、NRなど)を利用することができる。図1Aに示されるように、基地局114bはインターネット110に直接接続することができる。従って、基地局114bは、CN106/115を介してインターネット110にアクセスしなくてもよい。
RAN104/113は、CN106/115と通信することができ、これは、WTRU102a、102b、102c、102dの1つまたは複数に音声、データ、アプリケーション、および/またはVoIPサービスを提供するように構成される任意のタイプのネットワークであることができる。データは、異なるスループット要件、レイテンシ要件、誤り耐性要件、信頼性要件、データスループット要件、モビリティ要件などの変動するサービス品質(QoS)要件を有し得る。CN106/115は、呼制御、課金サービス、モバイル位置情報サービス、プリペイド発呼、インターネット接続、ビデオ配信などを可能にし、および/またはユーザ認証などの高レベルなセキュリティ機能を実行することができる。図1Aには示されていないが、RAN104/113および/またはCN106/115は、RAN104/113と同じRATまたは異なるRATを採用する他のRANと直接または間接的に通信することができることが諒解されよう。例えば、RAN104/113に接続されていることに加えて、これはNR無線技術を利用することであり得るが、CN106/115は、GSM、UMTS、CDMA2000、WiMAX、E−UTRA、またはWiFi無線技術を採用する別のRAN(図示せず)とも通信することができる。
CN106/115はまた、PSTN108、インターネット110、および/または他のネットワーク112にアクセスするためにWTRU102a、102b、102c、102dのためのゲートウェイとしての役割を果たすことができる。PSTN108は、基本電話サービス(POTS)を提供する回線交換電話回線網を含み得る。インターネット110は、相互接続されたコンピュータネットワークと、TCP/IPインターネットプロコトルスイート内のTCP、UDP、および/またはIPなどの共通の通信プロトコルを使用するデバイスとから成る地球規模のシステムを含むことができる。ネットワーク112は、他のサービス提供者によって所有および/または運営される有線および/または無線通信ネットワークを含むことができる。例えば、ネットワーク112は、RAN104/113と同じRATまたは異なるRATを採用することができる、1つまたは複数のRANに接続される別のCNを含んでもよい。
通信システム100内のWTRU102a、102b、102c、102dのいくつかまたは全ては、マルチモード機能を含むことができる(例えば、WTRU102a、102b、102c、102dは、種々の無線リンクにわたって種々の無線ネットワークと通信するための複数の送受信機を含むことができる)。例えば、図1Aに示されるWTRU120cは、これは、セルラベースの無線技術を採用することができる基地局114aと通信し、IEEE802無線技術を採用することができる基地局114bと通信するように構成されることができる。
図1Bは、例示的なWTRU102を示すシステム図である。図1Bに示されるように、WTRU102は、とりわけ、プロセッサ118、送受信機120、送受信要素122、スピーカ/マイク124、キーパッド126、ディスプレイ/タッチパッド128、固定メモリ130、取り外し可能メモリ132、電源134、GPSチップセット136および/または他の周辺機器138を含むことができる。WTRU102が、実施形態に一致したままでありながら、上記要素の任意の部分組合せを含み得ることを諒解されよう。
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと協働する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、任意の他のタイプの集積回路(IC)、状態機械などであることができる。プロセッサ118は、信号符号化、データ処理、電力制御、入力/出力処理、および/または、WTRU102が無線環境において動作することを可能にする任意の他の機能を実行することができる。プロセッサ118は、送受信機120に結合されることができ、この送受信機は、送受信要素122に結合されることができる。図1Bはプロセッサ118と送受信機120とを別個の構成要素として描いているが、プロセッサ118および送受信機120は電子パッケージまたはチップ内にともに統合されてもよいことが諒解されよう。
送受信要素122は、エアインターフェース116を介して基地局(例えば、基地局114a)へ信号を送信するか、または基地局から信号を受信するように構成され得る。例えば、1つの実施形態では、送受信要素122は、RF信号を送信および/または受信するように構成されるアンテナであってもよい。一実施形態では、送受信要素122は、例えば、IR信号、UV信号または可視光信号を送信および/または受信するように構成されるエミッタ/検出器であってもよい。さらに別の実施形態では、送受信要素122は、例えば、RF信号および光信号の両方を送信および/または受信するように構成されてもよい。送受信要素122は、無線信号の任意の組み合わせを送信および受信するように構成されてもよいことが諒解されよう。
送受信要素122は、図1Bにおいては単一の要素として描かれているが、WTRU102は任意の数の送受信要素122を含んでもよい。より具体的には、WTRU102はMIMO技術を採用してもよい。従って、1つの実施形態では、WTRU102は、エアインターフェース116を介して無線信号を送信および受信するために、2つ以上の送受信要素122(例えば、複数のアンテナ)を含んでもよい。
送受信機120は、送受信要素122によって送信される信号を変調するとともに、送受信要素122によって受信される信号を復調するように構成されることができる。上記のように、WTRU102はマルチモード機能を有することができる。従って、送受信機120は、WTRU102が、例えば、NRおよびIEEE802.11などの複数のRATを介して通信することを可能にするために、複数の送受信機を含むことができる。
WTRU102のプロセッサ118は、スピーカ/マイク124、キーパッド126、および/またはディスプレイ/タッチパッド128(例えば、液晶ディスプレイ(LCD)表示ユニットまたは有機発光ダイオード(OLED)表示ユニット)に結合されることができ、それらからユーザ入力データを受信することができる。プロセッサ118は、ユーザデータをスピーカ/マイク124、キーパッド126、および/またはディスプレイ/タッチパッド128に出力することもできる。加えて、プロセッサ118は、固定メモリ130および/または取り外し可能メモリ132などの任意のタイプの適切なメモリの情報にアクセスすることができ、その中にデータを記憶することができる。固定メモリ130は、RAM、ROM、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。取り外し可能メモリ132は、SIMカード、メモリスティック、SDメモリカード、などを含むことができる。他の実施形態では、プロセッサ118は、サーバまたはホームコンピュータ(図示せず)などにある、物理的にWTRU102上には位置していないメモリからの情報にアクセスすることができ、その中にデータを記憶することができる。
プロセッサ118は電源134から電力を受け取ることができ、電力を、WTRU102内の他の構成要素に分散させ、かつ/または制御することができる。電源134は、WTRU102に給電する任意の適切なデバイスであることができる。例えば、電源134は、1つまたは複数の乾電池(例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li−ion)他)、太陽電池、燃料電池などを含むことができる。
プロセッサ118はGPSチップセット136にも結合されることができ、これは、WTRU102の現在のロケーションに関連するロケーション情報(例えば、経度および緯度)を提供するように構成されることができる。GPSチップセット136からの情報に加えて、またはその代わりに、WTRU102は、基地局(例えば、基地局114a、114b)からエアインターフェース116を介してロケーション情報を受信し、かつ/または2つ以上の近隣の基地局から受信されている信号のタイミングに基づいてそのロケーションを決定することができる。WTRU102は、実施形態との一貫したままで任意の適切な定位方法によってロケーション情報を獲得してもよいことが諒解されよう。
プロセッサ118は、他の周辺機器138にさらに結合されることができ、この周辺機器は、追加の特徴、機能および/または有線もしくは無線接続を提供する1つまたは複数のソフトウェアモジュールおよび/またはハードウェアモジュールを含むことができる。例えば、周辺機器138は、加速度計、電子コンパス、衛星送受信機、デジタルカメラ(写真および/またはビデオ用)、USBポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)無線装置、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実および/または拡張現実(VR/AR)デバイス、アクティビティトラッカなどを含むことができる。周辺機器138は、1つまたは複数のセンサを含むことができ、センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁力計、向きセンサ、近接センサ、温度センサ、時間センサ、ジオロケーションセンサ、高度計、光センサ、タッチセンサ、磁力計、気圧計、ジェスチャセンサ、生体センサ、および/または湿度センサのうちの1つまたは複数であってもよい。
WTRU102は、(例えば、(例えば、送信のための)ULと(例えば、受信のための)DLとの両方のための特定のサブフレームに関連する)信号の一部または全部の送信および受信が並列および/または同時であり得る全二重無線を含むことができる。全二重無線は、ハードウェア(例えば、チョーク)またはプロセッサ(例えば、別個のプロセッサ(図示せず)またはプロセッサ118)を介した信号処理のいずれかを介して自己干渉を小さくするかおよび/または実質的になくすために干渉管理ユニット139を含むことができる。一実施形態では、WTRU102は、(例えば、(例えば、送信のための)ULまたは(例えば、受信のための)DLのいずれかのための特定のサブフレームに関連する)信号の一部または全部の送信および受信のための半二重無線を含んでもよい。
図1Cは、一実施形態による、RAN104およびCN106を示すシステム図である。上記のように、RAN104は、エアインターフェース116を介してWTRU102a、102b、102cと通信するためにE−UTRA無線技術を採用することができる。RAN104はまた、CN106と通信することもできる。
RAN104は、eNode−B160a、160b、160cを含むことができるが、RAN104は実施形態との一貫性を維持しながら、任意の数のeNode−Bを含んでもよいことが諒解されよう。eNode−B160a、160b、160cは各々、エアインターフェース116を介してWTRU102a、102b、102cと通信するために1つまたは複数の送受信機を含むことができる。1つの実施形態では、eNode−B160a、160b、160cはMIMO技術を実施してもよい。従って、eNode−B160aは、例えば、無線信号をWTRU102aに送信し、および/または、無線信号をWTRU102aから受信するために、複数のアンテナを使用してもよい。
eNode−B160a、160b、160cの各々は、特定のセル(図示せず)に関連付けられることができ、無線リソース管理に関する決定、ハンドオーバに関する決定、ULおよび/またはDLにおけるユーザのスケジューリングなどをハンドリングするように構成されることができる。図1Cに示されるように、eNode−B160a、160b、160cは、X2インターフェースを介して互いに通信することができる。
図1Cに示されるCN106は、モビリティ管理エンティティ(MME)162、サービングゲートウェイ(SGW)164、パケットデータネットワーク(PDN)ゲートウェイ(またはPGW)166を含むことができる。上記の要素の各々はCN106の一部として描かれているが、これらの要素のいずれかはCNのオペレータ以外のエンティティによって所有および/または操作されてもよいことが諒解されよう。
MME162は、S1インターフェースを介してRAN104中のeNode−B162a、162b、162cの各々に接続され、制御ノードとしての役割を果たすことができる。例えば、MME162は、WTRU102a、102b、102cの初期接続の間の、WTRU102a、102b、102cのユーザの認証、ベアラの起動/停止、特定のサービングゲートウェイの選択などに関与することができる。MME162は、RAN104と、GSMおよび/またはWCDMAのような他の無線技術を採用する他のRAN(図示せず)との間で切り替えるための制御プレーン機能を提供することができる。
SGW164は、S1インターフェースを介してRAN104中のeNode B160a、160b、160cの各々に接続され得る。SGW164は一般的に、ユーザデータパケットをWTRU102a、102b、102cから/WTRU102a、102b、102cにルーティングおよび転送することができる。SGW164は、eNode B間のハンドオーバ中のユーザプレーンのアンカリング、WTRU102a、102b、102cにとってDLデータが利用可能であるときのページングのトリガ、WTRU102a、102b、102cのコンテキストの管理および記憶などの、他の機能を実行することができる。
SGW164はPGW166に接続されることができ、これは、WTRU102a、102b、102cおよびIP使用可能デバイスの間の通信を容易にするために、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供することができる。
CN106は、他のネットワークとの通信を容易にすることができる。例えば、CN106は、WTRU102a、102b、102cと従来の固定通信デバイスとの間の通信を容易にするためにPSTN108などの回線交換ネットワークへのアクセスをWTRU102a、102b、102cに提供することができる。例えば、CN106は、CN106とPSTN108との間のインターフェースの役割を果たすIPゲートウェイ(例えば、IPマルチメディアサブシステム(IMS)サーバ)を含むことができるか、またはそれと通信することができる。加えて、CN106は、他のネットワーク112に対するアクセスをWTRU102a、102b、102cに提供することができ、他のネットワーク112は、他のサービス提供者によって所有および/または運営される有線ネットワークおよび/または無線ネットワークを含むことができる。
図1A〜図1DにおいてWTRUは無線端末として記載されているが、いくつかの代表的な実施形態では、そのような端末は(例えば、一時的にまたは永続的に)通信ネットワークとの有線通信インターフェースを使用し得ることが企図されている。
代表的な実施形態では、他のネットワーク112は、WLANであり得る。
インフラストラクチャ基本サービスセット(BSS)モードのWLANは、BSSのためのアクセスポイント(AP)と、APに関連する1つまたは複数の局(STA)とを有することができる。APは、BSSを出入りするトラフィックを搬送するディストリビューションシステム(DS)または別のタイプの有線/無線ネットワークへのアクセスまたはインターフェースを有することができる。BSSの外部から発信するSTAへのトラフィックは、APを通して到着し得、STAに送達され得る。STAからBSS外の宛先に発信されるトラフィックは、それぞれの宛先に配信されるためにAPに送られ得る。BSS内のSTA間のトラフィックは、APを通して送られ得、例えば、発信元STAはAPにトラフィックを送り得、APは、宛先STAにトラフィックを送達し得る。BSS内のSTA間のトラフィックは、ピアツーピアトラフィックと考えられ、および/または参照される場合がある。ピアツーピアトラフィックは、直接リンクセットアップ(DLS)を用いて発信元STAと宛先STAとの間で(例えば、それらの間で直接)送られ得る。いくつかの代表的な実施形態では、DLSは、802.11eDLSまたは802.11zトンネリングされたDLS(TDLS:tunneled DLS)を使用し得る。独立BSS(IBSS)モードを使用するWLANはAPを有しないことがあり、IBSS内のまたはそれを使用するSTA(例えば、STAの全て)は互いに直接的に通信し得る。IBSS通信モードは、本明細書では「アドホック」通信モードとして参照される場合がある。
802.11acインフラストラクチャ動作モードまたは同様の動作モードを使用するとき、APは、1次チャネルなどの固定チャネル上でビーコンを送信し得る。1次チャネルは、固定幅(例えば、20MHz幅の帯域幅)であるか、またはシグナリングを介して動的に設定された幅であり得る。1次チャネルは、BSSの動作チャネルであり得、APとの接続を確立するためにSTAによって使用され得る。いくつかの代表的な実施形態では、キャリア検知多重アクセス/衝突回避(CSMA/CA)が、例えば、802.11システムにおいて実施され得る。CSMA/CAでは、APを含むSTA(例えば、あらゆるSTA)が1次チャネルを検知し得る。1次チャネルが特定のSTAによって検知/検出されるおよび/またはビジーであると決定される場合、特定のSTAはバックオフし得る。1つのSTA(例えば、ただ1つの局)が、所与のBSS中で任意の所与の時間に送信することができる。
高スループット(HT)のSTAは、40MHz幅のチャネルを形成するために、例えば、隣接するまたは隣接していない20MHzのチャネルとの1次の20MHzのチャネルの組み合わせを介した通信のために40MHz幅のチャネルを使用することができる。
極高スループット(VHT)のSTAは、20MHz、40MHz、80MHzおよび/または160MHz幅のチャネルをサポートすることができる。40MHzおよび/または80MHzのチャネルは、連続する20MHzのチャネルを組み合わせることによって形成され得る。160MHzのチャネルは、8つの連続する20MHzのチャネルを組み合わせることによって、または80+80構成と呼ばれることがある2つの不連続の80MHzのチャネルを組み合わせることによって形成され得る。80+80構成では、データは、チャネル符号化後に、2つのストリームにデータを分割し得るセグメントパーサを通して渡され得る。逆高速フーリエ変換(IFFT)処理と時間領域処理とが、各ストリームに対して別個に行われ得る。ストリームは、2つの80MHzのチャネル上にマッピングされ得、データは、送信STAによって送信され得る。受信STAの受信機では、80+80構成について上述された動作が逆行され得、組み合わされたデータが媒体アクセス制御(MAC)に送られ得る。
802.11afおよび802.11ahによってサブ1GHz動作モードがサポートされる。チャネル動作帯域幅およびキャリアは、802.11nおよび802.11acで使用されるものと比較して、802.11afおよび802.11ahでは低減される。802.11afは、TVホワイトスペース(TVWS)スペクトル中の5MHz、10MHz、および20MHzの帯域幅をサポートし、802.11ahは、非TVWSスペクトルを使用して1MHz、2MHz、4MHz、8MHz、および16MHzの帯域幅をサポートする。代表的な実施形態によれば、802.11ahは、マクロカバレッジエリア中のMTCデバイスなどのメータ型制御/マシン型通信をサポートし得る。MTCデバイスは、特定の能力、例えば、いくつかのおよび/または限定された帯域幅のサポート(例えば、それだけのサポート)を含む限定された能力を有し得る。MTCデバイスは、(例えば、非常に長いバッテリ寿命を維持するために)閾値を上回るバッテリ寿命を有するバッテリを含むことができる。
802.11n、802.11ac、802.11afおよび802.11ahなどの複数のチャネルおよびチャネル帯域幅をサポートすることができるWLANシステムは、1次チャネルとして指定され得るチャネルを含む。1次チャネルは、BSS中の全てのSTAによってサポートされる最大の共通動作帯域幅に等しい帯域幅を有し得る。1次チャネルの帯域幅は、BSS中で動作する全てのSTAの中から、最小の帯域幅動作モードをサポートするSTAによって設定および/または限定され得る。802.11ahの例では、APおよびBSS中の他のSTAが、2MHz、4MHz、8MHz、16MHzおよび/または他のチャネル帯域幅動作モードをサポートする場合でも、1次チャネルは、1MHzモードをサポートする(例えば、それだけをサポートする)STA(例えば、MTCタイプのデバイス)について1MHz幅であり得る。キャリア検知および/またはネットワーク割り振りベクトル(NAV)の設定は、1次チャネルのステータスに依存し得る。例えば(1MHz動作モードのみをサポートする)STAのために1次チャネルがビジーである場合、周波数帯域の大部分がアイドルのままであり、利用可能であり得る場合であっても、APに利用可能な周波数帯域全体を送信することが、ビジーであると考えられ得る。
米国では、802.11ahによって使用され得る利用可能な周波数帯域は、902MHzから928MHzまでである。韓国では、利用可能な周波数帯域は、917.5MHzから923.5MHzまでである。日本では、利用可能な周波数帯域は、916.5MHzから927.5MHzまでである。802.11ahのために利用可能な総帯域幅は、国コードに応じて6MHzから26MHzである。
図1Dは、一実施形態による、RAN113およびCN115を示すシステム図である。上記のように、RAN113は、エアインターフェース116を介してWTRU102a、102b、102cと通信するためにNR無線技術を採用することができる。RAN113はまた、CN115と通信することもできる。
RAN113は、gNB180a、180b、180cを含むことができるが、RAN113は実施形態との一貫性を維持しながら、任意の数のgNBを含んでもよいことが諒解されよう。gNB180a、180b、180cは各々、エアインターフェース116を介してWTRU102a、102b、102cと通信するために1つまたは複数の送受信機を含むことができる。1つの実施形態では、gNB180a、180b、180cはMIMO技術を実施してもよい。例えば、gNB180a、180bは、gNB180a、180b、180cに信号を送信し、および/またはそれから信号を受信するためにビームフォーミングを利用し得る。従って、gNB180aは、例えば、無線信号をWTRU102aに送信し、および/または、無線信号をWTRU102aから受信するために、複数のアンテナを使用してもよい。一実施形態では、gNB180a、180b、180cはキャリアアグリゲーション技術を実施してもよい。例えば、gNB180aは、WTRU102a(図示せず)に複数のコンポーネントキャリアを送信することができる。これらのコンポーネントキャリアのサブセットは、無認可スペクトル上にあり得、一方、残りのコンポーネントキャリアは、認可スペクトル上にあり得る。一実施形態では、gNB180a、180b、180cは、協調マルチポイント(CoMP)技術を実施してもよい。例えば、WTRU102aは、gNB180aおよびgNB180b(および/またはgNB180c)から協調送信を受信することができる。
WTRU102a、102b、102cは、スケーラブルなヌメロロジに関連する送信を使用してgNB180a、180b、180cと通信することができる。例えば、OFDMシンボル間隔および/またはOFDMサブキャリア間隔は、異なる送信、異なるセル、および/または無線送信スペクトルの異なる部分ごとに変動し得る。WTRU102a、102b、102cは、(例えば、様々な数のOFDMシンボルを含んでいるおよび/または変動する長さの絶対時間の間続く)様々なまたはスケーラブルな長さのサブフレームまたは送信時間間隔(TTI)を使用してgNB180a、180b、180cと通信することができる。
gNB180a、180b、180cは、スタンドアロン構成および/または非スタンドアロン構成においてWTRU102a、102b、102cと通信するように構成され得る。スタンドアロン構成では、WTRU102a、102b、102cは、他のRAN(例えば、eNode−B160a、160b、160cなど)にアクセスすることもなしにgNB180a、180b、180cと通信し得る。スタンドアロン構成では、WTRU102a、102b、102cは、gNB180a、180b、180cのうちの1つまたは複数をモビリティアンカーポイントとして利用し得る。スタンドアロン構成では、WTRU102a、102b、102cは、無認可帯域中の信号を使用してgNB180a、180b、180cと通信し得る。非スタンドアロン構成では、WTRU102a、102b、102cは、eNode−B160a、160b、160cなどの別のRANとも通信しながら/それにも接続しながらgNB180a、180b、180cと通信し得る/それに接続し得る。例えば、WTRU102a、102b、102cは、1つまたは複数のgNB180a、180b、180cおよび1つまたは複数のeNode−B160a、160b、160cと実質的に同時に通信するためにDC原理を実施し得る。非スタンドアロン構成では、eノードB160a、160b、160cは、WTRU102a、102b、102cのモビリティアンカーとしての役割を果たし得、gNB180a、180b、180cは、WTRU102a、102b、102cにサービスするための追加のカバレッジおよび/またはスループットを与え得る。
gNB180a、180b、180cの各々は、特定のセル(図示せず)に関連付けられ得、無線リソース管理の決定、ハンドオーバの決定、ULおよび/またはDLにおけるユーザのスケジューリング、ネットワークスライシングのサポート、デュアル接続性、NRとE−UTRAとの間の相互接続、ユーザプレーン機能(UPF)184a、184bに向けたユーザプレーンデータのルーティング、アクセスおよびモビリティ管理機能(AMF)182a、182bに向けた制御プレーン情報のルーティングなどをハンドリングするように構成され得る。図1Dに示すように、gNB180a、180b、180cは、Xnインターフェースを介して互いと通信することができる。
図1Dに示すCN115は、少なくとも1つのAMF182a、182bと、少なくとも1つのUPF184a、184bと、少なくとも1つのセッション管理機能(SMF)183a、183bと、場合によっては、データネットワーク(DN)185a、185bとを含むことができる。上記の要素の各々はCN115の一部として描かれているが、これらの要素のいずれかはCNのオペレータ以外のエンティティによって所有および/または操作されてもよいことが諒解されよう。
AMF182a、182bは、N2インターフェースを介してRAN113中のgNB180a、180b、180cのうちの1つまたは複数に接続され得、制御ノードとしての役割を果たすことができる。例えば、AMF182a、182bは、WTRU102a、102b、102cのユーザを認証すること、ネットワークスライシング(例えば、異なる要件を有する異なるPDUセッションのハンドリング)のサポート、特定のSMF183a、183bを選択すること、登録エリアの管理、NASシグナリングの終了、モビリティ管理などを担当し得る。ネットワークスライシングは、利用されているWTRU102a、102b、102cであるサービスのタイプに基づいてWTRU102a、102b、102cのCNサポートをカスタマイズするために、AMF182a、182bによって使用され得る。例えば、異なるネットワークスライスは、超高信頼低遅延(URLLC)アクセスに依拠するサービス、高速大容量モバイルブロードバンド(eMBB)アクセスに依拠するサービス、マシン型通信(MTC)アクセスのサービスなどの異なる使用事例のために確立され得る。AMF162は、RAN113と、LTE、LTE−A、LTE−A Pro、および/またはWiFiなどの非3GPPアクセス技術などの他の無線技術を採用する他のRAN(図示せず)との間で切り替えるための制御プレーン機能を提供することができる。
SMF183a、183bは、N11インターフェースを介してCN115中のAMF182a、182bに接続され得る。SMF183a、183bはまた、N4インターフェースを介してCN115中のUPF184a、184bにも接続され得る。SMF183a、183bは、UPF184a、184bを選択および制御し、UPF184a、184bを通してトラフィックのルーティングを構成し得る。SMF183a、183bは、UEのIPアドレスを管理し、割り振ること、PDUセッションを管理すること、ポリシの執行およびQoSを制御すること、ダウンリンクデータの通知を提供することなどの他の機能を実行することができる。PDUセッションのタイプは、IPに基づくもの、IPに基づかないもの、イーサネットに基づくものなどであり得る。
UPF184a、184bは、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にするためにインターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供することができる、N3インターフェースを介してRAN113中のgNB180a、180b、180cのうちの1つまたは複数に接続され得る。UPF184、184bは、パケットをルーティングおよび転送すること、ユーザプレーンのポリシを執行すること、マルチホームPDUセッションをサポートすること、ユーザプレーンQoSをハンドリングすること、ダウンリンクパケットをバッファリングすること、モビリティアンカリングを提供することなどの他の機能を実行することができる。
CN115は、他のネットワークとの通信を容易にすることができる。例えば、CN115は、CN115とPSTN108との間のインターフェースの役割を果たすIPゲートウェイ(例えば、IPマルチメディアサブシステム(IMS)サーバ)を含むことができるか、またはそれと通信することができる。また、CN115は、他のネットワーク112に対するアクセスをWTRU102a、102b、102cに提供することができ、他のネットワーク112は、他のサービス提供者によって所有および/または運営される有線ネットワークおよび/または無線ネットワークを含むことができる。1つの実施形態では、WTRU102a、102b、102cは、UPF184a、184bへのN3インターフェース、および、UPF184a、184bとDN185a、185bとの間のN6インターフェースとを介して、UPF184a、184bを通してローカルデータネットワーク(DN)185a、185bに接続され得る。
図1A〜図1Dおよび図1A〜図1Dの対応する説明に鑑みて、WTRU102a〜d、基地局114a〜b、eNode−B160a〜c、MME162、SGW164、PGW166、gNB180a〜c、AMF182a〜b、UPF184a〜b、SMF183a〜b、DN185a〜b、および/または本明細書で説明されている任意の他のデバイスのうちの1つまたは複数に関して本明細書で説明されている機能のうちの1つもしくは複数または全ては、1つまたは複数のエミュレーションデバイス(図示せず)によって実行されてもよい。エミュレーションデバイスは、本明細書で説明されている機能のうちの1つもしくは複数または全てをエミュレートするように構成された1つまたは複数のデバイスであり得る。例えば、エミュレーションデバイスは、他のデバイスをテストする、並びに/またはネットワークおよび/もしくはWTRU機能をシミュレートするために使用され得る。
エミュレーションデバイスは、ラボ環境においておよび/またはオペレータネットワーク環境において他のデバイスの1つまたは複数のテストを実施するように設計され得る。例えば、1つまたは複数のエミュレーションデバイスは、通信ネットワーク内の他のデバイスをテストするために有線および/または無線通信ネットワークの一部として完全にまたは部分的に実施および/または展開されながら、1つもしくは複数または全ての機能を実行することができる。1つまたは複数のエミュレーションデバイスは、有線および/または無線通信ネットワークの一部として一時的に実施/展開されながら、1つもしくは複数または全ての機能を実行することができる。エミュレーションデバイスは、テストする目的で別のデバイスに直接的に結合され得、および/または、無線ワイヤレス通信を使用してテストを実行することができる。
1つまたは複数のエミュレーションデバイスは、有線および/または無線通信ネットワークの一部として実施/展開されることなく、全てを含む1つまたは複数の機能を実行することができる。例えば、エミュレーションデバイスは、1つまたは複数の構成要素のテストを実施するために試験所並びに/または展開されていない(例えば、テスト用の)有線および/もしくは無線通信ネットワーク中のテストシナリオで利用され得る。1つまたは複数のエミュレーションデバイスは、テスト機器であり得る。データを送信および/または受信するためにエミュレーションデバイスによって、直接RF結合および/または(例えば、1つまたは複数のアンテナを含み得る)RF回路を介した無線通信が使用され得る。
LTEにおいて、ターボコーダインターリーバは、制限された数のコードブロック(CB)サイズに対してのみ定義され、最大ブロックサイズは6144ビットである。結果として、24ビットのTB巡回冗長検査(CRC)を含むトランスポートブロック(TB)が、この6144ビットの制限を超える場合、各TBは、ターボコーディングの前に、より小さいCBへとセグメント化される。
図2は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、コードブロック(CB)セグメント化250およびCBごとの巡回冗長検査(CRC)の挿入270の一例200を示す。図2に示されるように、TB205におけるCBセグメント化250は、CB#1 215にフィラービット260(すなわち、ターボコーダによってサポートされるサイズに第1のCBを合わせるためのフィラー)を挿入するターボコーディングプロセスに先行し得る。CBセグメント化250の間、各CB(すなわち、CB#1 215、CB#2 217、CB#M 218)は、それに付加されているCRC230、232、234を有することができる。このCRC230、232、234はまた、24ビットの長さをも含み得るが、これはTB CRC210とは異なる。CB215、217、218ごとにCRC230、232、234を有することによって、チャネルコード化280のために正確に復号されたCBを早期に検出することを可能にすることができ、これによって、そのCB215、217、218の反復復号プロセスを早期に終了することが可能である。これは、WTRU処理の複雑度およびエネルギー消費を低減するために使用され得る。TB CRC210とCB CRC230、232、234とを組み合わせることによって、復号されたTBの誤りが検出されない危険性を最小限に抑えることができる。
LTEにおいて、TBのサイズ、すなわちトランスポートブロックサイズ(TBS)は、20MHzのシステム帯域幅に基づいて、97,896ビット程度の大きさであり得る。この結果、TBあたりCBはおよそ16個になり得る。LTEにおいては、たとえ復号に失敗したCBが単一であっても、TB全体が再送信される。6GHz未満に対するシステム帯域幅が100MHzであり、可能性としてmmW帯域についてGHz単位までになる新無線(NR)において、TBSは、LTEの20MHz帯域幅のスケーリングに基づいて、例えば、100MHzに対して80個のCBなど、はるかにより大きくなり得る。
高速大容量モバイルブロードバンド(eMBB)、超高信頼低遅延通信(URLLC)、および大規模マシンタイプ通信(mMTC)などの複数の使用事例が提供されるNRにおいては、無線リソースを利用する効率的な方法が必要とされ得る。例えば、URLLC WTRUは、それらの厳密な遅延要件を満たすために、直ちにサービスされる必要があり得る。この結果、eMBBトラフィックをプリエンプトすることが必要になり得、eMBBトラフィックのためにスケジューリングされているリソースが、URLLCトラフィックにサービスするためにプリエンプトされ得る。リソースのこのプリエンプションは、ミニスロット(すなわち、シンボルの単位)レベルであり得、少数のCBにしか影響を与えない。従って、LTEの場合のようにTB全体を再送信することは、リソースに関して非効率であり、無駄が多い。結果として、CB、CBのグループ(CBG)、TB、またはそれらの任意の組み合わせに基づいて動作することができるより柔軟な再送信方式が必要であり得る。
図3は、超高信頼低遅延(URLLC)トラフィックによる高速大容量モバイルブロードバンド(eMBB)トラフィックの例示的なプリエンプションを示す。例えば、CB1から28は元々、eMBBトラフィックのためにスケジューリングされている。しかしながら、URLLCトラフィックがサービスされる必要があるとき、eMBBトラフィックのためにスケジューリングされているCBは、領域305および315に示されているように、URLLCトラフィックにサービスするためにプリエンプトされ得る。LTEにおいては、プリエンプトされる領域305、315内のCB(またはeMBBトラフィックのための領域内の任意のCB)が適切に復号されない場合、TB全体が再送信される必要がある。上述したように、この結果として、無線リソースの使用が非常に非効率になる。
CBGに基づく再送信をサポートするために、マルチビットHARQフィードバックが必要とされ得る。マルチビットフィードバックは、WTRUが、基地局(例えば、次世代ノードB(gNB))からいずれのCB/CBGまたは他のリソース(例えば、PRBまたはPRBのグループ)の再送信を要求しているかを示すために使用され得る。
WTRUまたはWTRUのセット/グループは、HARQフィードバック、単一ビットHARQフィードバック、またはマルチビットHARQを利用しないように半静的にまたは動的に構成され得る。これは、サービスされているeMBBトラフィックのタイプ/クラス(例えば、ライブストリーミングビデオ対非ライブビデオコンテンツ)と、eMBBトラフィックをプリエンプトしているURLLCトラフィックの周波数の両方に応じ得る。WTRUに対するフィードバックフォーマットの構成(または再構成)は、BS(例えば、gNB)によって、シグナリングメッセージを介して決定され得る。例えば、半静的構成は、RRCシグナリングを介して決定され得、WTRUまたはWTRUのセット/グループが提供するHARQフィードバックのタイプが長い時間期間にわたって変化し得ないことを示すことができる。例えば、WTRUがセル内でマルチビットHARQフィードバックを提供するように半静的に構成されるとき、WTRUは、単一ビットHARQフィードバックのみを許容することができる異なるセルに移動するまで、そのHARQフィードバック構成を変化させない。対照的に、動的構成は、DCIを介して決定され得、WTRUまたはWTRUのセット/グループが提供するHARQフィードバックのタイプが、必要とされるときに短い時間期間内で変化し得ることを示すことができる。例えば、DCIは、WTRUが提供しているHARQフィードバックのタイプを変更するためのパラメータを含むことができる。
一実施形態において、eMBBトラフィックが、ライブストリーミングビデオなどの、主に時間に敏感なトラフィックから構成され、URLLCトラフィック負荷が低く、それによって、eMBBリソースのプリエンプションが相対的に低頻度になる場合、BS(例えば、gNB)は、HARQフィードバックを利用しないように、WTRUまたはWTRUのグループを半静的または動的に(再)構成することができる。WTRUはこのとき、このタイプのサービスについてのHARQに基づく再送信と関連付けられる遅延にとって、いくつかのパケットの損失が好ましいため、順方向誤り訂正(FEC)に依拠し得る。
代替的にまたは付加的に、URLLCトラフィックの頻度が高く、結果、eMBBリソースのプリエンプションの度合いが高くなる場合、BS(例えば、gNB)は、マルチビットHARQフィードバックを利用するように、影響されるWTRUまたはWTRUのグループを半静的または動的に(再)構成することができる。マルチビットHARQフィードバックが受信されると、BSは、データの影響を受ける部分を再送信することができ、結果、WTRUまたはWTRUのグループは、影響を受けるTBを効率的に復号することができる。これらの再送信は、CB/CBG、ミニスロットレベルの再送信であり得、遅延に関して視る者の体験に劇的に影響しないようにしながら、WTRUまたはWTRUのグループが追加のデータ送信から受益することを可能にする。
別の実施形態において、BS(例えば、gNB)は、マルチビットHARQフィードバックの特定の予め定められたマッピングを使用するように、WTRUまたはWTRUのグループを半静的に構成することができる。これらのマッピングは、マルチビットHARQフィードバックが、CBレベルの粒度、CBGレベルの粒度、またはさらには時間−周波数リソースを可能にするか否かを示すことができる。そのようなマッピングの例が、図4A〜図4Cに示されている。
図4Aは、本明細書において説明されている他の実施形態のいずれかと組み合わせて使用され得る、例示的なマルチビットHARQフィードバック405を示す。図4Aに示されているように、マルチビットHARQフィードバック405は、CBレベルの粒度の再送信を可能にすることができる。ここで、粒度は、マルチビットHARQフィードバックの各ビット(すなわち、各HARQ情報ビット)内に含まれるCB/CBGの数を意味する。具体的には、CBレベルの粒度は、マルチビットHARQフィードバック405内の各ビットが、個々のCBを表すことができることを意味する。この例において、マルチビットHARQフィードバック405は、各CB(すなわち、CB1〜CB12)を表す12個のHARQ情報ビットを含む。12個のHARQ情報ビットは、WTRUが再送信を要求しているそれぞれのCBを示すことができる。例えば、CB1が、正確に復号されない(すなわち、破損されている)場合、WTRUは、CB1を表す第1のHARQ情報ビットを、NACKとして決定することができる。CB1が首尾よく復号される場合、WTRUは、第1のHARQ情報ビットを、ACKとして決定することができる。0のHARQ情報ビット値がNACKを表すことができ、一方、1のHARQ情報ビット値がACKを表すことができ、またはその逆であってもよい。これは、WTRUが、首尾よく復号するのに失敗したCBを正確に指定することができるという点で、最大の柔軟性を提供する。従って、BSは、再送信リソースの使用を最小限に抑えることができる。これは、TBサイズが小さい場合に特に魅力的であり得る。しかしながら、TBサイズがさらに適度に大きい場合、この手法は、多数のHARQフィードバックビットを必要とし得、シグナリングオーバーヘッドが大きく増大する。
図4Bは、本明細書において説明されている他の実施形態のいずれかと組み合わせて使用され得る、HARQフィードバック410がコードブロックグループ(CBG)レベルの粒度の再送信を可能にする、例示的なマルチビットHARQフィードバック410を示す。CBGレベルの粒度は、マルチビットHARQフィードバック410内の各ビットが、CBのグループ(すなわち、CBG)415、420、425、430を表すことができることを意味する。この例において、マルチビットHARQフィードバック410は、CBG415、420、425、430の各々を表す4個のHARQ情報ビットを含む。4個のHARQ情報ビットの各々は、WTRUが再送信を要求しているそれぞれのCBG415、420、425、430を示すことができる。例えば、マルチビットHARQフィードバック410の第1のビットは、第1のCBG415(すなわち、CB1、CB2、CB3から成るグループ)を表し、第1のCBGが再送信を要求されているか否かを示す。例えば、第1のCBG415内のCBのいずれかが正確に復号されない(すなわち、破損されている)場合、WTRUは、第1のCBG415を表す第1のHARQ情報ビットを、NACKとして決定することができる。第1のCBG415内のCBの全てが首尾よく復号される場合、WTRUは、第1のCBG415を表す第1のビットを、ACKとして決定することができる。上記で説明されているように、0のHARQ情報ビット値がNACKを表すことができ、一方、1のHARQ情報ビット値がACKを表すことができ、またはその逆であってもよい。
図4Cは、本明細書において説明されている他の実施形態のいずれかと組み合わせて使用され得る、HARQフィードバック435がCBGレベルの粒度の再送信を可能にする、別の例示的なマルチビットHARQフィードバック435を示す。CBGレベルの粒度は、マルチビットHARQフィードバック410内のビットが、CBのグループ(すなわち、CBG)440、445を表すことができることを意味する。図4Cに示されているように、各HARQ情報ビットは、この場合は各々が6個のCBから成る2つのCBGグループである、CBG440、445にマッピングする。例えば、マルチビットHARQフィードバック435の第1のビットは、第1のCBG440(すなわち、CB1、CB2、CB3、CB4、CB5、CB6から成るグループ)を表し、第1のCBGが再送信を要求されているか否かを示す。第1のCBG415内のCBの全てが首尾よく復号される場合、WTRUは、第1のCBG440を表す第1のビットを、ACKとして決定することができる。第1のCBG440内のCBのいずれかが正確に復号されない(例えば、破損されている)場合、WTRUは、第1のCBG440を表す第1のHARQ情報ビットを、NACKとして決定することができる。言い換えれば、関連するCBGグループ内のいずれかのCBが誤っている場合、この結果として、NACKフィードバックが生じ得、その結果、そのCBG内の全てのCBが再送信されることになる。WTRUが、CBGの全てのコードブロックを正確に受信した場合、WTRUは、CBGのHARQ−ACK情報ビットのACKを生成することができる。WTRUが、CBGの少なくとも1つのコードブロックを正確に受信しなかった場合、WTRUは、CBGのHARQ−ACK情報ビットのNACKを生成することができる。上述されているように、0のHARQ情報ビット値がNACKを表すことができ、一方、1のHARQ情報ビット値がACKを表すことができ、またはその逆であってもよい。
一実施形態において、WTRUは、複数のHARQフィードバックのオプションを利用するように構成され得る。例えば、WTRUは、マルチビットHARQフィードバックと単一ビットHARQフィードバックの両方を提供するように構成され得る。WTRUは、2つのうちのいずれの1つを利用すべきかを判断し、必要とされる場合に2つの間で切り替える柔軟性を有することができる。例えば、WTRUが、特定のTBについて少数のCBを首尾よく復号することができない場合、それは、基地局(例えば、gNB)がいずれのCBを再送信すべきかをシグナリングするために、マルチビットHARQフィードバックを利用することを選択する(またはそうするように切り替える)ことができる。
代替的にまたは付加的に、WTRUが、相当数のCB(例えばTB全体のうちの大きい割合)を復号することができない場合、それは、プリエンプションが複数のCB/CBGに影響を与えており、BS(例えば、gNB)がTB全体を再送信することがより良好であり得ることを知らせることができる。そのような事例において、WTRUは、単一ビットHARQフィードバックを利用することを選択する(または、そのように切り替える)ことができ、これは、シグナリングオーバーヘッドも同時に低減しながら、TB全体を再送信するようにBS(例えば、gNB)に通知する。BS(例えば、gNB)は、単一ビットHARQフィードバックとマルチビットHARQフィードバックとの間の切り替えを容易にするために、閾値パラメータ「δ」を用いてWTRUを構成することができる。
TBに基づく再送信を要求している単一ビットHARQフィードバックと、CBGに基づく再送信を要求しているマルチビットHARQフィードバックとの間の切り替えを容易にするために、WTRUは、BS(例えば、gNB)によって、各々が異なるペイロード(例えば、アップリンク制御情報(UCI))サイズを有する、複数のPUCCHフォーマットを利用するように構成され得る。WTRUは、このとき、HARQフィードバック要件に基づいて適切なPUCCHフォーマットを選択することができる。このシナリオの下では、BS(例えば、gNB)は、いずれのフォーマットが、および、いずれのフィードバックオプションがWTRUによって利用されているかを確認するために、PUCCHをブラインド復号する必要があり得る。
WTRUは、無線リソース制御(RRC)シグナリングを介して複数のPUCCHリソースセットを用いて構成され得、ここで、リソースセットは、UCIペイロード容量に基づいて分割される。例えば、単純なシナリオにおいて、「K=2」個の構成済みリソースセットがあり得る。第1のリソースセットは、HARQ−ACKフィードバック、従って、最大2ビットのUCIペイロードサイズを有するPUCCHフォーマットに対して定義され得る。一方、第2のリソースセットは、HARQ−ACKフィードバック、従って、2ビットよりも大きいUCIペイロードサイズを有するPUCCHフォーマットに対して定義され得る。別の例において、WTRUは、粒度が追加された、「K=3」個のリソースセットを用いて構成され得る。例えば、第1のリソースセットは、最大2ビットのUCIペイロードサイズに対して定義され得る。第2のリソースセットは、2ビットよりも大きく19ビット未満のUCIペイロードサイズを利用するPUCCHフォーマットに対して定義され得る。第3のリソースセットは、20ビット以上のUCIペイロードサイズに対して定義され得る。また別の例において、「K=4」個のPUCCHリソースセットがあり得、(「K=3」の場合のように)第1のリソースセットは最大2ビットのUCIペイロードサイズに対して定義され、第2のリソースセットは2ビットよりも大きく19ビット未満のUCIペイロードサイズを利用するPUCCHフォーマットに対して定義される。しかしながら、第3のリソースセットおよび第4のリソースセットは、第3のリソースセットが、20よりも大きく、何らかの値「L」(一例としてL=80)未満であるUCIペイロードサイズから定義され、第4のリソースセットが、Lよりも大きいUCIペイロードサイズに対して定義されることによって、増大された粒度を提供することができる。
リソースセットの数と、リソースセットあたりの利用可能なPUCCHリソース(リソースブロック)の数との間にはトレードオフがあり得る。ここで、PUCCHリソースの総数はより多数のリソースセットの間で分割される必要があるため、より多数のPUCCHリソースセットを有する結果として、セットあたりのPUCCHリソースは少なくなり得る。より多数のリソースセットを有することは、相当数のWTRUがより高いUCIペイロードを有し得ると一般的に予測される場合に、有益であり得る。この事例において、これらのペイロードの分布は多様であり、PUCCHリソースセットは、UCIペイロードの分布に対して微調整され得、それによって、これらのリソースの最適な使用が可能になる。より多数のリソースセットを有することが有益であり得る例示的なソリューションは、UCIペイロードの大きな変動が可能である場合であり得る。CBGに基づく(再)送信の事例において、これは、単一のHARQフィードバックの応答が、複数のスロット/CCなどにわたる複数のPDSCH送信に提供される必要があり得る、フィードバックのHARQ多重化があるときに発生し得る。そのような状況において、かつ、特にCBGに基づく(再)送信について、HARQビットの数は相当になり得、例えば、TBあたり8個のCBGによって構成されるWTRUについて、5個のCCで、HARQフィードバックについて40ビットのUCIペイロードが予測され得、一方、2個のCCについて、16ビットのUCIペイロードが予測され得る。そのようなシナリオでは、より多数のPUCCHリソースセット(例えば、「K=3」とは対照的に「K=4」)を有することがより良好であり得、セットの間のPUCCHリソースの分布は、より多数のリソースがK=3の場合について供給されるようなものであり得る。これは、40ビットのHARQフィードバックが提供される確率が、3と何らかの中間の数(例えば、「K=4」の場合の第3のセットについての上記における19ビット)との間のHARQ、および、従って、UCIペイロードが提供される確率よりもはるかに低いと予期され得るためである。
WTRUは、このとき、HARQペイロード(UCI)サイズに基づいて適切なリソースセットを選択することができる。例えば、WTRUがTBあたり2個のCBGおよび単一のみのコードワード(CW)によって構成される上記のシナリオにおいて、WTRUは、2ビットのマルチビットフィードバックを報告する必要があり得る。そのような事例のシナリオにおいて、WTRUは、最大2ビットのUCIのPUCCHフォーマットに対して定義されるPUCCHリソースセット(すなわち、上記の例の各々における第1のセット)を選択することができる。
別の実施形態において、単一のCW構成についてTBあたり8個のCBGによって構成されるWTRUは、8ビットのサイズのマルチビットフィードバックを報告する必要があり得る。WTRUは、上記の例の第2のセットにおいて示されている2ビットよりも大きいUCIをサポートすることが可能であるPUCCHフォーマットに対して定義されるPUCCHリソースセットを選択することができる。
また別の例において、WTRUが複数のPUCCHリソースセットによって構成され得ることが可能であり、ここで、2つ以上のリソースセットが、HARQペイロードサイズ(またはより一般的には、特定のサイズのUCIペイロード)をサポートすることが可能であるPUCCHフォーマットに対して定義される。例えば、WTRUは、K=4個のセットを用いて構成され得、ここで、2つのセットが最大2ビットのUCIペイロードのPUCCHフォーマットに対して定義され、一方で、残りの2つのリソースセットは、2ビットよりも大きいUCIペイロードのPUCCHフォーマットに対して定義される。そのようなシナリオにおいて、WTRUは、いずれかのペイロード事例に対して2つの定義されているセットの間から一方を無作為に選ぶことができる。これは、PUCCHリソースセットあたり多数のWTRUが割り振られる場合に、複数のWTRUの間の衝突の可能性を低減するのに役立ち得る。
選択されているPUCCHフォーマットが、適度なUCI(HARQ)ペイロードが可能であり、複数の/いくつかのシンボル/ミニスロット/サブスロットにわたって送信される場合(例えば、単一のリソース−ブロック対にわたるPUCCHフォーマット4などの長い持続時間にわたるPUCCH)、PUCCHリソースセットを効率的に活用するために、複数のWTRUが同じリソース−ブロック対を共有することができる。シンボル/ミニスロット内で同じリソース−ブロック対を共有するデバイスは、周波数領域シーケンスの異なる直交位相回転(例えば、時間領域におけるサイクリックシフト)によって分離され得る。代替的にまたは付加的に、複数のリソース−ブロック対が使用される、例えば、2ビットよりも大きいなど、より大きいUCIペイロードフォーマット(例えば、PUCCHフォーマット2または3)について、シンボル/ミニスロット/サブスロットの多重化容量は、複数のWTRUに同じリソース−ブロック対を共有させることによって増大され得、ここで、各WTRUは、異なる直交カバーシーケンスを使用する。これによって、HARQフィードバックに必要とされ得るPUCCHリソースの数を低減することができる。
適切なリソースセットを(例えば、HARQ−ACKペイロードサイズに基づいて)選択することに加えて、BS(例えば、gNB)は、WTRUによって、そのHARQフィードバックを提供するために使用されることになるPUCCHリソースを微調整することができる。これは、PUCCHリソースおよび/またはPUCCHリソースセット内のフォーマットを動的に制御するために使用され得る、LTEにおける2ビットのACK−NACKオフセットフィールド(ANO)と同様のACK−NACKリソースインジケータ(ARI)フィールドを利用することによって行われ得る。
1つの実施形態において、2ビットのARIは、以下のようにPUCCHリソースのインデックスを提供することができ、すなわち、選択されているPUCCHリソースセット内で、00は第1のPUCCHリソースをインデックス付けし、01は第2のPUCCHリソースをインデックス付けし、10は第3のPUCCHリソースをインデックス付けし、11は第4のPUCCHリソースをインデックス付けする。
別の実施形態において、ARIは、特定のPUCCHフォーマットのPUCCHリソースインデックスのインデックスを提供することができる。例えば、WTRUが2ビットよりも大きいUCIペイロードの短いPUCCHと長いPUCCHの両方に対して構成される場合、これは、2つの異なるPUCCHフォーマットによって構成され得る。一実施形態において、一方のPUCCHフォーマットが短いPUCCHに使用され得、他方のPUCCHフォーマットが長いPUCCH送信に使用され得る。ARIインデックスは、このとき、PUCCHリソースインデックスおよびPUCCHフォーマットに関する情報を提供するために利用され得る。例えば、ARIインデックスに基づいて、WTRUは、一方のフォーマット(例えば、PUCCHa)が短い持続時間のPUCCHの送信のためのものであり、他方のフォーマット(例えば、PUCCHb)が長い持続時間のためのものである、両方が2ビットよりも大きいUCIペイロードを搬送することが可能な2つのPUCCHフォーマット(例えば、PUCCHaおよびPUCCHb)を有するPUCCHリソースセットを選択することができる。具体的には、ARIインデックス00は、PUCCHaのPUCCHリソース1を示すことができ、インデックス01は、PUCCHaのPUCCHリソース2を示すことができ、インデックス10は、PUCCHbのPUCCHリソース1を示すことができ、インデックス11は、PUCCHbのPUCCHリソース2を示すことができる。
また別の実施形態において、短いPUCCHフォーマットと長いPUCCHフォーマットの両方によって構成されているWTRUは、特定の予め定められた基準に基づいて、1つのPUCCHフォーマットを判断することができる。例えば、WTRUが電力を制限されているかまたはカバレッジを制約されている場合、WTRUは、長いPUCCHフォーマットを利用するように判断することができる。そのような事例において、最良の適切なPUCCHフォーマットを選ぶ柔軟性を有するWTRUは、PUCCHリソースインデックスを示すためにのみ、DCI内のARIフィールドを使用することができる。
加えて、適切なPUCCHリソースを選択する柔軟性を有することによって、WTRUが、結果生じ得るフィードバック粒度の任意の変化に適合することが可能であり得る。例えば、CBGに基づく(再)送信のためにマルチビットHARQフィードバックを提供するように構成されているWTRUは、BS(例えば、gNB)がPDCCH上のフォールバックDCIを使用してPDSCHをスケジューリングする場合、TBに基づく(再)送信のための単一ビットHARQフィードバックによって応答することができる。フォールバックDCIは、BSが、送信されているトランスポートブロック(TB)のCBGに基づく再送信をサポートしないことを示し得る。WTRUがフォールバックDCIを受信するとき、単一または2つのコードワード(またはTB)の再送信を要求している単一ビットHARQフィードバックにはそれで十分であるため、2ビットのより小さいUCIペイロードサイズをサポートするPUCCHフォーマット向けに構成されているPUCCHリソースセットを選択し得る。このように、まずマルチビットHARQフィードバックを提供するように構成されているWTRUは、(より大きいUCIペイロード向けに構成されているリソースセットを利用することによる)CBGに基づく再送信のためのマルチビットHARQフィードバックと、(より小さいUCIペイロードサイズ向けに構成されているリソースセットを利用することによる)TBに基づく再送信のための単一ビットHARQフィードバックとの間で切り替えることができる。このフォールバックDCIの事例において、BS(例えば、gNB)は、HARQペイロードサイズが(マルチビットHARQフィードバックから単一ビットHARQフィードバックへと)変化しており、それに応じてPUCCHフォーマットの変化しているため、WTRUが、異なるPUCCHリソースセットに切り替わっているという事実を考慮に入れて、(ARIフィールドを介して)更新されたPUCCHリソースインデックス情報を提供することができる。新たなARIは、その後、このPUCCHリソースセットのPUCCHリソースインデックス情報を反映するように修正され得る。
WTRUがPUSCH上でデータを送信している一実施形態において、WTRUは、再送信のより微細な粒度を提供するために、マルチビットHARQフィードバックを利用することを選択することができる。この例において、WTRUはまた、より厳密な閾値パラメータ「δs」(δs>δ)に基づいて、マルチビットHARQフィードバックから単一ビットHARQフィードバックへと切り替えることもできる。これは、TB全体が誤っている場合にのみ単一ビットに切り替えることを暗示する、例えば、δs=1の、HARQフィードバックがPUCCH上で送信される場合よりも厳密である。
別の実施形態において、WTRUは、マルチビットHARQフィードバックと単一ビットHARQフィードバックの両方を同時にBS(例えば、gNB)に提供するなど、複数のHARQフィードバックのオプションを提供するように構成され得る。両方のタイプのHARQフィードバックを提供することは、組み込み誤り検出およびHARQフィードバックの誤りに対する追加されたロバスト性を必要とし得る。例えば、プリエンプションによって影響される単一のCBGを用いるWTRUは、影響されるCBGに関するマルチビットHARQフィードバックと、TBに関する単一ビットフィードバックの両方を提供することができる。これは、マルチビットHARQフィードバックが、影響されるCBGに関する単一のNACKを含み、単一ビットHARQフィードバックが、TBに関する単一のNACKを含むことを意味する。いずれかのNACKビットがNACK−ACKの誤りによって影響される場合、BS(例えば、gNB)は依然として、TBの少なくとも何らかの部分がWTRUによって正確に復号されなかったことを伝達することが可能であり得る。この事例において、BS(例えば、gNB)は、TB全体を再送信する(影響されるCBGに関する単一のNACKがACKに反転される場合)か、または、NACKを受信したCBGのみを再送信するように判断することができる。前者の場合(すなわち、TB全体の再送信)の結果として、不要な送信が発生し得るが、これは、影響されるCBGの再送信は、RLCプロトコルによって補正される可能性があることに起因して、(例えば、TB全体を首尾よく受信するまで)TB全体を再送信するよりも長い時間がかかる場合があるため、代替形態(すなわち、影響されるCBGの再送信)よりも好ましい場合がある。
マルチビットHARQフィードバックを提供するように構成されているWTRUはまた、フィードバックオーバーヘッドを低減するための方法としてのフォールバックのオプションとして、単一ビットフィードバックに戻るかまたはこれを利用することもできる。WTRUはまた、マルチビットHARQフィードバックと単一ビットHARQフィードバックの両方のオプションによって構成されてもよく、BS(例えば、gNB)によってスケジューリングされている(再)送信が、少なくとも1つの(再)送信されているCBGに誤り(すなわち、NACK)をもたらす限り、マルチビットHARQフィードバックを提供することができる。全てのCBG(および、従って、TB全体)がWTRUによって首尾よく受信されると、WTRUはその後、TB全体がその時点で首尾よく受信されたことをBS(例えば、gNB)に通知するために、単一ビットHARQフィードバックメッセージを送ることができる。このマルチビットHARQフィードバックから単一ビットHARQフィードバックへの切り替えの結果として、性能に悪影響を与えないままで、オーバーヘッドが低減されるようにすることができる。
別の実施形態において、マルチビットHARQフィードバックと単一ビットHARQフィードバックの両方のオプションによって構成されているWTRUは、プリエンプトされているデータに起因して(例えば、CBGの絶対数または構成されているCBGの割合/比などの何らかの閾値に基づいて)相当数のCBGが復号不可能である場合、TBに基づく再送信のために単一ビットHARQフィードバックを選択するように判断することができる。そのような事例において、WTRUは、TB全体の再送信を要求することが最良であり得ると判断し得る。TB全体の再送信を要求するために、WTRUは、単一ビットHARQ−NACKを送ることができる。
また別の実施形態において、マルチビットHARQフィードバック向けに構成されている(または、マルチビットHARQフィードバックと単一ビットHARQフィードバックの両方向けに構成されている)WTRUは、PDSCHをスケジューリングするために利用されるDCIの変化に起因して単一ビットフィードバックに切り替わる(またはそれを選択する)ように要求され得る。例えば、CBGに基づく(再)送信およびDCIを介してスケジューリングされているPDSCHのためのマルチビットHARQフィードバックを用いて構成されているWTRUが、CBGに基づく送信をサポートしない場合、WTRUは、フォールバックDCIフォーマットが利用されるため、単一ビットHARQフィードバックに切り替わる(またはそれを選択する)必要があり得る。そのようなシナリオにおいて、フォールバックDCIを用いてPDSCHをスケジューリングすることは、WTRUが、TBに基づく再送信のために単一ビットHARQフィードバックを用いて応答する必要があることの指標と考えられ得る。周期的なDCI(または非フォールバックDCI)は、WTRUがCBG(またはCB)に基づく再送信のためにマルチビットHARQフィードバックを用いて応答するはずであることの指標と考えられ得る。
各PDCCHは、WTRUまたはWTRUのグループのリソース割り当ておよび他の制御情報を含む、DCIとして知られるメッセージを搬送することができる。例えば、DCIは、ダウンリンクおよびアップリンクスケジューリング情報、非周期的なチャネル品質指標(CQI)のレポート、または、1つのセルおよび1つの無線ネットワーク一時識別子(RNTI)に対するアップリンク電力制御コマンドを輸送することができる。情報内容に応じて、DCIは、下記の表1に示されているように、異なるDCIメッセージフォーマットを有し得る。
例えば、1つのセルにおけるPDSCHのスケジューリングに使用されるDCIフォーマット1_1は、少なくとも1つのトランスポートブロック(TB)のためのコードブロックグループ(CBG)に基づく(再)送信を示すフィールドを含むことができる。周期的なDCI(または非フォールバックDCI)は、WTRUがCBG(またはCB)に基づく再送信のためにマルチビットHARQフィードバックを用いて応答するはずであることを明示的に示すために、このDCIフォーマット1_1であり得る。他方、1つのDLセルにおけるPDSCHのスケジューリングに使用されるDCIフォーマット1_0は、CBGに基づく(再)送信を示すフィールドを含まない場合がある。このシナリオにおいて、DCIフォーマット1_0を用いてPDSCHをスケジューリングすることは、WTRUが、TBに基づく(再)送信のために単一ビットHARQフィードバックを用いて応答する必要があることの黙示的な指標と考えられ得る。上述されているように、WTRUは、DCIフォーマット1_0を受信すると、CBGに基づく再送信のために単一ビットHARQフィードバックに切り替わるかまたはそれを選択することができる。その上、WTRUが、DCIフォーマット1_0を有するPDCCHによってスケジューリングされているPDSCHを受信した場合、WTRUは、PDSCHにおけるトランスポートブロックのみに関するHARQフィードバック情報を生成することができる。上述されているフォールバックDCIは、このDCIフォーマット1_0であり得る。
WTRUによる、PUCCHリソース/フォーマットの選択は、WTRUが、純粋にそれ自体の判断決定に基づいて(例えば、上述されているように誤りがあったCBGの数に基づいて)マルチビットHARQフィードバックから単一ビットHARQフィードバックに切り替わったか否か、または、それが、PDSCHがBS(例えば、gNB)によってスケジューリングされた方法(例えば、フォールバックDCI)の変化に基づいていたか否かに基づいて、異なり得る。切り替えがフォールバックDCIに起因する後者の事例において、BS(例えば、gNB)は、選択されているPUCCHリソースセットからの使用されるべきPUCCHリソースのARIを動的に示すことができ、セット選択は、以前に言及されているようなUCIペイロードサイズに基づくことができる。これの動的に示されるリソースはその後、WTRUによって、単一ビットHARQフィードバックに使用され得る。
WTRUがマルチビットHARQフィードバックから単一ビットHARQフィードバックへと切り替わることを自動的に判断する事例において、WTRUは、予め構成されているPUCCHリソース(例えば、アップリンク制御情報(UCI))を利用することができる。この目的のために、BS(例えば、gNB)は、適切なPUCCHリソースセットを含むPUCCHリソースを半静的に構成することができる。この事例において、PUCCHリソースセットは、2ビット未満のUCIペイロードをハンドリングするように構成されているセットであり得る(PUCCHフォーマット0/1)。この予め構成されているリソースは、CBGに基づく(再)送信のためにPDSCHをスケジューリングする、フォールバックに基づかないDCIにおけるARIを介して動的に示されるPUCCHリソースに優先し得る。これは、このDCIにおいて示されるPUCCHリソースが、マルチビットフィードバックのペイロードサイズおよび対応するPUCCHリソースに特異的であったためである。
代替的にまたは付加的に、WTRUは、BS(例えば、gNB)に単一ビットHARQフィードバックを提供する目的のために、マルチビットHARQフィードバック向けに指定されているPUCCHリソースを利用することができる。この事例において、PUCCHフォーマット0およびPUCCHフォーマット2などの両方のPUCCHフォーマットが、同じPUCCHリソースに使用され得る。例えば、PUCCHフォーマット0は1〜2ビットのUCIペイロード向けに指定され得、PUCCHフォーマット2は、2ビットよりも大きいUCIペイロードに対して定義され得る。
先行する例にて、構成されているPUCCHリソースセットの数およびそれらのUCIペイロード容量に関する情報は、WTRUが送信されるPDSCHに対するHARQ応答を提供するときに、WTRUが、単一ビットHARQフィードバックまたはマルチビットHARQフィードバックの間で自律的に判断する能力を制限し得る。例えば、WTRUが、UCIペイロード容量の小さい単一のPUCCHリソースセットのみを用いて構成される場合、WTRUは、これを、常に単一ビットHARQを用いて応答すると予測されることの指標と解釈することができる。一方、WTRUが、大きいUCIペイロードを搬送することが可能な、UCIペイロードの大きいPUCCHリソースセットを用いて構成される場合、WTRUは、これを、このPDSCHに対して常にマルチビットHARQフィードバックを用いて応答すると予測されることの明示的な指標と解釈することができる。
また別の実施形態において、2つ以上のPUCCHリソースセットを用いて構成されているWTRUは、これを、適切なフィードバック粒度を選択するのはWTRU次第であることの黙示的な指示と解釈することができる。この事例において、BS(例えば、gNB)は、いずれのPUCCHフォーマットが、WTRUによって選択されたかを確認するために、PUCCHをブラインド復号する必要があり得る。
代替的にまたは付加的に、マルチビットHARQフィードバックのオプションのみを用いて構成されているWTRUは、TBレベルのフィードバックを提供するためにこの構成を利用することができる。図2に示されているように、TB205はCRC210を有し、各CB(すなわち、CB#1 215、CB#2 217、CB#M 218)は、それに付加されているCRC230、232、234を有する。WTRUが全てのCB215、217、218を含むTB205を受信した後、WTRUにおけるCBレベルのCRC検査が合格であるが、WTRUにおけるTBレベルのCRC検査が失格である場合、マルチビットHARQフィードバックフィールドは、このTBレベルのNACKフィードバックを含むことができる。このTBレベルのNACKフィードバック(例えば、NACKフィードバックビット0)は、N回繰り返され得、NはCBG/CBの数であるか、または、Nは、CBG/CBの最大数である。例えば、マルチビットHARQフィードバックを提供するように半静的に構成されているWTRUは、16個のCBGを含む2つのTBを受信し、ここで、各TBは8個のCBGを含む。第1のTBに関するCBレベルのCRCおよびTBレベルのCRC検査が合格になった場合、WTRUは、ACK情報ビットを8回繰り返すことによって(すなわち、11111111)、TBレベルのACKフィードバックを生成することができる。第2のTBに関して、全てのCBレベルのCRC検査が合格になったが、TBレベルのCRC検査が不合格になった場合、WTRUは、NACK情報ビットを8回繰り返すことによって(すなわち、00000000)、TBレベルのNACKフィードバックを生成することができる。WTRUは、マルチビットHARQフィードバックを提供するように半静的に構成されているため、マルチビットHARQフィードバック内のビット数は、CBGの最大数(この例では16ビット)である必要があり得る。従って、2つの8ビット(すなわち、第1のTBの11111111および第2のTBの00000000)が多重化された後、WTRUは、16ビットのマルチビットHARQフィードバック(すなわち、1111111100000000)を生成することができる。
言い換えれば、WTRUがN個のCBGの各々を正確に検出し、N個のCBGのTBを正確に検出しない場合、WTRUは、N個のCBGの各々についてNACKビットを生成することができる。他方、WTRUがN個のCBGの各々を正確に検出し、また、N個のCBGのTBも正確に検出する場合、WTRUは、N個のCBGの各々についてACKビットを生成することができる。1つまたは複数のTBが使用される場合、各TBの単一のHARQコードブックが多重化される必要があり、それによって、マルチビットHARQフィードバックが生成される。そのような手法は、HARQフィードバックに冗長性を付加するのを助けることができ、それによって、誤検出の確率が低減し、遅延が低減し、追加のオーバーヘッド/コストを受けない。これは、WTRUが、マルチビットフィードバックフォーマットのペイロードを搬送するように意図されているPUCCHフォーマットを使用するようにすでに構成されているためである。
一実施形態において、WTRUが、フォールバックDCIを用いたPDCCHによってスケジューリングされているPDSCHを受信し、かつ、WTRUが、マルチビットHARQフィードバックを提供するために上位レイヤのパラメータを用いて半静的に構成されている場合、WTRUは、N個のHARQ ACKまたはNACK情報ビットを生成するために、PDSCHにおけるTBについてHARQ ACKまたはNACKをN回(すなわち、BSによって構成されているCBGの数またはCBGの最大数)繰り返すことができる。
図5は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、DCIに基づいて単一ビットHARQフィードバックおよび/またはマルチビットHARQフィードバックを提供するための例示的なシグナリング手順500を示す。図5に示されているように、WTRU505は、基地局(BS)510から無線リソース制御(RRC)メッセージ515を受信することができる。RRCメッセージ515は、メッセージを送信するレイヤが媒体アクセス制御(MAC)レイヤよりも高い、上位レイヤのメッセージとして交換可能に参照され得る。RRCレイヤは、BS(例えば、gNB/eNB)内に配置され、制御プレーンプロトコルをハンドリングすることができる。例えば、RRCレイヤは、システム情報のブロードキャスト、接続管理、モビリティ、WTRU能力などの、RANに関係付けられる手順を管理する。これらのメッセージは、共通のまたは専用にされた制御チャネルのいずれかにマッピングされる、無線ベアラを使用して送信され得る。
RRCメッセージ515は、ステップ520においてCBGに基づく(再)送信のために、CBGの最大数に基づいてマルチビットHARQフィードバックを提供するように、WTRUを半静的に構成する上位レイヤのパラメータ(例えば、CBG−DL=ON)を含むことができる。例えば、WTRUが、CBGの最大数を含む上位レイヤによって構成される場合、WTRUは、TB受信のためのそれぞれのHARQフィードバック情報を生成するために、最大数のCBGを使用する必要があり得る。例えば、受信されているTBが8つのCBGを含むが、上位レイヤのパラメータによって構成されているCBGの最大数が10である場合、WTRUは、マルチビットHARQフィードバックのために10個のHARQ情報ビットを生成することができる。この事例において、最初の8ビットはCBG(またはTB)の復号の結果によって決定され得、最後の2ビットは、ダミービット(例えば、ACKまたはNACKビット)に基づいて付加または挿入され得る。マルチビットHARQフィードバックのペイロードサイズは、CBGの構成されている数によって決定され得る。例えば、マルチビットHARQフィードバックのペイロードサイズは、CBGの最大数と同じであり得る。
RRCメッセージ515を受信した後、WTRU505は、上述されているようにマルチビットHARQフィードバックおよび/または単一ビットHARQフィードバックを提供するように構成され得る。WTRU505は、PDCCHを介して、PDSCHスケジューリングのための周期的な(非フォールバック)DCI525を受信することができる。周期的なDCI525に基づいて、WTRUは、PDSCHを介してデータ(すなわち、TB)530を受信することができる。WTRU505は周期的なDCI525を受信しているため、受信されているTB内の少なくとも1つのCBがステップ535において適切に復号されていないとき、WTRU505は、PUCCHを介してBS510にマルチビットHARQフィードバック540を送信することができる。このマルチビットHARQフィードバック540は、UCI内に含まれ得る。マルチビットHARQフィードバック540はまた、WTRU505が再送信を要求しているCBGの1つまたは複数のHARQ NACK情報ビットをも含むことができる。マルチビットHARQフィードバック540を送信した後、WTRU505は、再送信のためにスケジューリングされているCBG550について、PDCCHを介して周期的な(非フォールバック)DCI545を受信することができる。周期的なDCI545がCBGの再送信をスケジューリングする場合、DCI545は、CBG送信情報(CBGTI:CBG transmission information)フィールドを含むことができる。CBGTIフィールドは、TBの各CBGとの1対1のマッピングを有するビットマップを含むことができる。WTRU505は、CBGTIフィールドの対応する値に基づいて、CBGが再送信されるか否かを決定することができる。例えば、2進数0は、対応するCBGが再送信されることを示し、2進数1は、対応するCBGが再送信されないことを示す。
WTRU505はまた、PDSCHスケジューリングのために、PDCCHを介してフォールバックDCI555をも受信することができる。フォールバックDCI555に基づいて、WTRUは、PDSCHを介してデータ(すなわち、TB)560を受信することができる。WTRU505はフォールバックDCI555を受信しているため、受信されているTB内の少なくとも1つのCBがステップ565において適切に復号されていないとき、WTRU505は、PUCCHを介してBS510に単一ビットHARQフィードバック570を送信することができる。この単一ビットHARQフィードバック570もまた、UCI内に含まれ得る。単一ビットHARQフィードバック570はまた、WTRU505が再送信を要求しているTGの複数のHARQ NACK情報ビットを含むことができる。単一ビットHARQフィードバック570を送信した後、WTRU505は、再送信のためにスケジューリングされているTB580について、PDCCHを介してフォールバックDCI575を受信することができる。単一ビットHARQフィードバック570がNACK(すなわち、2進数0)である場合、WTRU505は、BS510によって再送信されている対応するTBを受信することができる。単一ビットHARQフィードバック570がACK(すなわち、2進数1)である場合、WTRU505は、BS510からさらなる再送信を一切受信しない。
図6は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、DCIに基づいて単一ビットHARQフィードバックおよび/またはマルチビットHARQフィードバックを提供するための例示的な手順600を示す。ステップ605において、WTRUは、上述されているようにマルチビットHARQフィードバックおよび/または単一ビットHARQフィードバックを提供するように構成され得る。ステップ610において、WTRUは、PDSCHスケジューリングのために、PDCCHを介してDCIを受信することができる。ステップ615において、WTRUはデータ(すなわち、TB)を受信することができる。ステップ620において、受信されているDCIがフォールバックDCIであり、かつ、受信されているTB内の少なくとも1つのCBが正確に復号されない場合、WTRUは、ステップ625において単一ビットHARQフィードバックを送信することができる。単一ビットHARQフィードバック570がNACK(すなわち、2進数0)である場合、WTRUは、ステップ630において、BS510によって再送信されている対応するTBを受信することができる。
ステップ620において、受信されているDCIが非フォールバックDCIであり、かつ、受信されているTB内の少なくとも1つのCBが正確に復号されない場合、WTRUは、ステップ635においてマルチビットHARQフィードバックを送信することができる。マルチビットHARQフィードバックは、WTRUが再送信を要求しているCBGの1つまたは複数のHARQ NACK情報ビットを含むことができる。ステップ635においてマルチビットHARQフィードバックを送信した後、WTRUは、再送信のためにスケジューリングされているCBGについて、PDCCHを介して周期的な(非フォールバック)DCIを受信することができる。周期的なDCIがCBGの再送信をスケジューリングする場合、周期的なDCIは、CBG送信情報(CBGTI)フィールドを含むことができる。CBGTIフィールドは、TBの各CBGとの1対1のマッピングを有するビットマップを含むことができる。WTRUは、CBGTIフィールドの対応する値に基づいて、CBGが再送信されるか否かを決定することができる。例えば、2進数0は、対応するCBGが再送信されることを示し、2進数1は、対応するCBGが再送信されないことを示す。ステップ640において、CBGTIフィールドに基づいて、WTRUは、BSによって再送信されているCBGを受信することができる。
図7は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、WTRUが提供すべきである単一ビットHARQフィードバックおよび/またはマルチビットHARQフィードバックを決定するための例示的な手順700を示す。ステップ705において、WTRUが、最初の(TB)送信またはCBGに基づく再送信をBSから受信することができる。ステップ710において、WTRUは、単一ビットHARQフィードバックおよび/またはマルチビットHARQフィードバックの間からWTRUが提供すべきであるHARQフィードバックを考慮することができる。ステップ730において、単一ビットHARQフィードバックとマルチビットHARQフィードバックを考慮することを決定する場合、WTRUは最初に、BSから受信されている全てのCBGに誤りがないかを検査することができる。全ての受信されているCBGに誤りがない場合、WTRUは、ステップ720において、単一ビットHARQフィードバックを生成することができる。これは、単一ビットHARQ ACKであり得る。受信されているCBGに誤りがある場合、WTRUは、ステップ735において、単一ビットHARQフィードバックおよびマルチビットHARQフィードバックを生成することができる。これは、WTRUが、単一ビットおよびマルチビットHARQフィードバックを多重化することによって、単一のHARQフィードバックメッセージを介して、複数のTB(例えば、PDSCH)に対するHARQフィードバックを提供している事例に関連し得る。
ステップ710において、WTRUが、単一ビットHARQフィードバックおよび/またはマルチビットHARQフィードバックの間からWTRUが提供すべきであるHARQフィードバックを考慮しないと決定する場合、WTRUは、WTRUがいずれのHARQフィードバックを選択するかを決定するために他の要因を考慮することができる。例えばステップ715において、WTRUは、TB内の全CBGに対する、誤りのあるCBGの比を考慮することができる。TB内の全CBGに対する、誤りのあるCBGの比が予め定められた閾値(δ)よりも大きい場合、WTRUは、ステップ720において、TBに基づく再送信のために、単一ビットHARQフィードバックを生成することができる。TB内の全CBGに対する、誤りのあるCBGの比が予め定められた閾値(δ)よりも小さい場合、WTRUは、ステップ725において、CBGに基づく再送信のために、マルチビットHARQフィードバックを生成することができる。最後に、WTRUは、ステップ740において、決定されているHARQフィードバックをBSに送信することができる。
1つの実施形態において、WTRUは、マルチビットHARQフィードバックのオプションを利用するように構成され得る。マルチビットHARQフィードバックのオプションは、CBに基づいてもよく、CBGに基づいてもよく、CBに基づくのとCBGに基づくのとの間で切り替わってもよい。例えば、WTRUまたはWTRUのグループは、CBGに基づく再送信のためにマルチビットHARQを利用するように半静的に構成され得る。ネットワークは、低遅延トラフィックが、「X」msごとに送信機会を必要とする、本質的に周期的なものであることを経時的に推測することができ、これは転じて、WTRUまたはWTRUのグループのためのCBの数が制限されていることを意味し得る。そのような事例において、システムがCBに基づくマルチビットHARQフィードバックに切り替わることが有益である。これを行うために、BS(例えば、gNB)は、WTRUの影響されるセットを動的に(再)構成することができる。
別の実施形態において、BS(例えば、gNB)によってサービスされるWTRUは、デフォルトのHARQフィードバック設定によって初期化され得る。初期/デフォルトのHARQフィードバック設定は、単一ビットHARQフィードバックまたはマルチビットHARQフィードバックであってもよい。マルチビットHARQフィードバックがデフォルトの設定である場合、システムは、予め定められた最大ビット数「N_max」を有することができ、各ビットは、CB、または、複数のCBを含むCBGのいずれかに適用される。加えて、各ビットは、CBに適用されるかまたはCBGに適用されるかにかかわらず、システムの最大のTBをカバーすることが可能である。N_maxの選択は、N_maxの可能な最大値に関して低い複雑度から適度な複雑度までを維持しながら、再送信のために十分に微細な粒度の選択が可能であることに関する、柔軟性の間のトレードオフを提供し得る。
CBGに基づく再送信を可能にするために、BS(例えば、gNB)は、TBに基づく初期送信と、CBGに基づく(再)送信の両方をスケジューリングする必要があり得る。BS(例えば、gNB)は、CBGに基づく(再)送信をスケジューリングするために別個のDCIフォーマット(例えば、非フォールバックDCI)を利用しながら、初期のTBに基づく送信をスケジューリングするために、スケジューリング割り当て(例えば、フォールバックDCI)を使用することができる。スケジューリング割り当て(すなわち、DCI)は、変調符号化方式(MCS)、冗長バージョン(RV)、新規データインジケータ(NDI)などのフィールドを含むことができる。代替的にまたは付加的に、スケジューリング割り当ては、CBGが再送信のためにスケジューリングされていることをWTRUに明示的に示すために、CBGインジケータフィールド(CBGIF:CBG indicator field)またはCBG送信情報(CBGTI)フィールドを含むことができる。
代替的にまたは付加的に、BS(例えば、gNB)は、既存のフィールドが初期TBフィールドに適用されるか否かであって、それらの既存のフィールドは、それらの元々の有意性を有する、適用されるか否か、または、それらの既存のフィールドがCBGに基づく再送信に適用されるか否かを集合的に示すための既存のNDIフィールドまたは新たなフラグなどの、単一ビットフラグを有する、例えば、MCS/NDI/RVなどの、既存のフィールドを再使用するDCIフォーマットを利用することができる。
1つの実施形態において、BS(例えば、gNB)は、MCSフィールドまたはMCSフィールドの拡張されたバージョンが、いずれのCBGが再送信されているかに関する情報を搬送することを、WTRUに通知するために、NDIおよびRVフィールドを利用することができる。BS(例えば、gNB)は、以前に送信されているTBのスケジューリングされている送信がCBGに基づく再送信であり、元々と同じRVを再送信することをWTRUに通知するために、NDIを使用することができる。NDIフィールドまたはフラグの使用は、端末が、MCSフィールドをCBGのCBGIF(またはCBGTI)が再送信されていることを示すものとして解釈でき、また再送信が元々の送信と同じMCSを利用していると仮定することもできることの黙示的な指標とみなされ得る。
別の実施形態において、BS(例えば、gNB)は、CBGに基づく再送信をスケジューリングするために特定的に指定されている拡張されたDCIフォーマットを利用することができる。この拡張されたDCIフォーマットは、例えば、MCS/RV/NDIなど、LTEによって利用されるものと同じ元々のフィールドを含むことができる。元々のフィールドに加えて、拡張されたDCIフォーマットは、再送信されているCBGを通知するために、追加のCBGIF(またはCBGTI)を含むことができる。CBGIFまたはCBGTIフィールドによって、BS(例えば、gNB)はCBGに基づく再送信にMCS/RVフィールドを利用することができるため、BS(例えば、gNB)は、初期送信と再送信との間で送信パラメータを適合させることに関する最大の柔軟性を有することができる。
また別の実施形態において、BS(例えば、gNB)は、初期のTB送信とCBに基づく(再)送信の両方をスケジューリングするために、単一の共通のDCIフォーマットを利用することができる。そのような手法は、WTRUにおいて必要とされるブラインド復号の試行の数を低減することができる。利用されるDCIフォーマットは、LTEによって利用されるもの(MCS/RV/HARQプロセスID/PUCCH電力制御など)と同じ元々のフィールド、および、追加のCBGIFまたはCBGTIを含むことができる。CBGIFまたはCBGTIフィールドは、CBG再送信の場合にいずれのCBGが再送信されているかを示すために使用され得る。代替的にまたは付加的にCBGIFまたはCBGTI内の全ての「1」の状態またはビットは、TB全体の送信/再送信を示し得る。この共通のDCIのDCIペイロードサイズを低減するために、BS(例えば、gNB)によってコンパクトな割り当てフォーマットが利用され得る。例えば、連続したリソースブロック(リソース割り振りタイプ2)のみをサポートすることによって、スケジューリングの柔軟性がわずかに低減されることと引き換えに、DCIペイロードサイズを低減することができる。
別の実施形態において、BS(例えば、gNB)は、CBGIFを用いずに、かつ、CBGに基づくスケジューリング割り当てのためにいずれのCBGが再送信されているかを明示的に示すことなく、TBに基づくおよび/またはCBGに基づく再送信をスケジューリングするために、DCIフォーマットを利用することができる。2つのスケジューリング割り当ては、NDIなどの既存のフィールドを利用し得るか、または、初期のTBに基づく送信とCBGに基づく再送信との間の区別を可能にする追加のフィールドを有し得る、フラグに関して異なり得る。そのような事例において、BS(例えば、gNB)は、いずれのCBGが再送信されているかを示していないため、WTRUは、HARQフィードバックを提供するときに、WTRUが否定応答されている(NACK−ed)ものとして示したCBGを再送信していると黙示的に仮定し得る。スケジューリング割り当ては、既存のLTE DCIフォーマットからMCS/RVフィールドを保持することができ、これによって、TBに基づく再送信からCBGに基づく再送信に移行するときに、必要とされるように、例えば、MCS/RVなどの送信パラメータを適合させることに関して最大の柔軟性を可能にし得る。
上述されているように、HARQビットの数は、柔軟性とフィードバックオーバーヘッドとの間のトレードオフを提供するように選択され得る。BS(例えば、gNB)は、マルチビットフィードバックに「N」ビットを利用するようにWTRUまたはWTRUのグループを構成することができ、各ビットはCBまたはCBGに適用される。例えば、CBGレベルのマルチビットHARQフィードバックは、再送信の粒度に関する柔軟性を提供しながら、フィードバックオーバーヘッドを制限することができる。各ビットがCBGに適用される「N」ビットのマルチビットHARQフィードバック方式であって、「N」はTBにかかわらず固定されている、方式を利用するために、CBG内のCBの数「K」は、TBに従って変化し得、より大きいTBはより大きい「K」をもたらし、より小さいTBは、「K」がより小さいため、より微細な粒度の再送信をもたらす。
代替的にまたは付加的に、BS(例えば、gNB)は、その後、BS(例えば、gNB)が半静的に適合することができる、ネットワークによって観測される最大のトランスポートブロックサイズ(TBS)に基づいて、マルチビットHARQフィードバックのために「N」ビットを利用するように、WTRUのグループを半静的に構成することができる。これはその後、適切なCBからCBGへのグループ化を決定するために使用され得る(例えば、「K」個のCBがCBGを形成し、「K」は固定され、最大の観測されているTBSに基づいて決定される)。
また別の実施形態において、BS(例えば、gNB)は、TBSとは無関係に選択される固定された「K」のCBからCBGへのグループ化を利用することができる。この結果として、異なるTBに対して異なる数のCBGがもたらされ、HARQフィードバック方式に対して異なるビット数(「N」)がもたらされる。
別の実施形態において、BS(例えば、gNB)は、DCIを介して、マルチビットHARQフィードバックのための「N」ビットを用いて、WTRUを動的に構成することができる。上記で定義されている「N」と「K」は両方とも、TBの初期または最初の送信のTBに基づいて決定され得、このTBの全ての再送信にわたって変化され得ない。
HARQフィードバックサイズの半静的および/または動的な構成を採用するのに加えて、WTRUは、マルチビットHARQフィードバックのためのCBGの数(すなわち、サイズ「N」)を黙示的に導出することができる。これは、WTRUまたはWTRUのグループに対して指定されている構成済みPUCCHフォーマットのUCIペイロードサイズに基づいて行われ得る。例えば、LTEにおけるPUCCHフォーマット3と同様のフォーマットを用いて構成されているWTRUは、マルチビットHARQフィードバックのために10ビットを仮定し得、一方、LTEにおけるPUCCHフォーマット1bと同様のフォーマットを用いて構成されているWTRUは、マルチビットHARQフィードバックのために4ビットを黙示的に仮定し得る。
BS(例えば、gNB)は、WTRUのマルチビットHARQフィードバックサイズを再構成するために、半静的および/または動的なシグナリングを利用することができる。例えば、BS(例えば、gNB)は、パラメータ「N」を用いてWTRUを半静的に構成することができ、「N」は、TB内のCBGの総数を示す。パラメータ「N」によって、BSはまた、「N」ビットのHARQフィードバック(CBGあたり1ビット)が予測されることをWTRUに通知することもできる。加えて、BS(例えば、gNB)は、異なる値「N1」(N1≦N)を動的に示すことができ、それによって、ここで、任意の再送信に対して「N1」ビットのHARQフィードバックが提供されるべきであることを、WTRUに通知する。「N1」のこの値は、TB内の全てのCBGとは対照的に、再送信のためにスケジューリングされているCBGに基づき得る。
代替的にまたは付加的に、マルチビットHARQフィードバックサイズの明示的な指標として使用されるCBGの数の代わりに、WTRUは、CBG再送信のスケジューリングDCIに基づいて、この情報を黙示的に導出することができる。例えば、WTRUが、フォールバックDCIを有するPDCCHによってスケジューリングされているPDSCHを受信した場合、WTRUは、PDSCHにおけるTBのみに関するHARQフィードバック情報ビットを生成することができる。例えば、変動するUCIペイロードを搬送することが可能である複数のPUCCHフォーマットを用いて構成されているWTRUは、これを黙示的な指標として解釈することができる。従って、WTRUは、再送信されるCBGに関するHARQフィードバックを提供するために、ペイロードサイズのより小さいPUCCHフォーマットを利用することができる。いずれのCBGがスケジューリングされているかに関する情報が、スケジューリングDCIのCBGIF(またはCBGTI)から導出され得る。この結果として、この可変サイズのマルチビットHARQフィードバックの信頼性が保証され得る限り、全体的な性能に影響を与えることなく、同じTBの複数の(CBGに基づく)再送信を確認応答するときに、HARQフィードバック(すなわち、UCIサイズ)が低減され得る。
マルチビットHARQフィードバックは、再送信の間に再構成され得る。上述されているように、UCIに対するマルチビットHARQフィードバックの影響も考慮されるべきであるが、より多数のHARQフィードバックビットは、再送信の粒度に関してより高い柔軟性およびスペクトル効率の向上を可能にする。
初期のTBの部分を形成する全てのCBGにフィードバックを提供するのとは対照的に、HARQフィードバックビットの数を制限することは、再送信のために明示的にスケジューリングされているCBGのみに対してACK/NACKフィードバックを提供することによって達成され得る。
1つの実施形態において、BS(例えば、gNB)は、BS(例えば、gNB)によって再送信のためにスケジューリングされているCBGの数にかかわらず、例えば、TB内の全てのCBGなど、固定されているCBG割り当て/スケジューリングのセットに基づいて、HARQフィードバックを報告するように、WTRUまたはWTRUのグループを構成することができる。HARQフィードバックビットの数は、固定されており、TBの初期の送信、および、このTBに関する、全ての後続するCBGに基づく再送信のためのCBGの総数に等しいため、これはHARQ設計を単純化することができ、結果として、HARQフィードバックビットがいずれのCBGに適用され得るかに関して曖昧さがなくなる。このシナリオの下で、WTRUは、BS(例えば、gNB)によって再送信されないCBGに関する何らかの予め定められた規則に従うことができる。例えば、WTRUは、これらのCBGについて、それらはWTRUによって首尾よく受信(または復号)されたため、ACKを報告することができる。WTRUが、TBの以前の送信と同じHARQプロセスに対応するTBの再送信に応答してHARQ ACKフィードバックを生成する場合、WTRUは、TBの以前の送信においてWTRUが正確に復号した各CBGのACKを生成することができる。
別の実施形態において、BSは、BSによって再送信のためにスケジューリングされているCBGの数にかかわらず、TB内の最大数のCBGに基づいて、HARQフィードバックを報告するように、WTRUまたはWTRUのグループを構成することができる。WTRUが、CBGの最大数を含む上位レイヤによって構成される場合、WTRUは、TB受信のためのそれぞれのHARQフィードバック情報を生成するために、最大数のCBGを使用する必要があり得る。例えば、受信されているTBが8つのCBGを含むが、上位レイヤのパラメータによって構成されているCBGの最大数が10である場合、WTRUは、マルチビットHARQフィードバックのために10個のHARQ情報ビットを生成することができる。この事例において、最初の8ビットはCBG(またはTB)の復号の結果によって決定され得、最後の2ビットは、ダミービット(例えば、ACKまたはNACKビット)に基づいて付加または挿入され得る。この例において、マルチビットHARQフィードバックのペイロードサイズは、CBGの最大数と同じであり得る。
別の例において、BS(例えば、gNB)は、再送信のために現在スケジューリングされているCBGに純粋に基づく、可変ビットのHARQフィードバック方式を採用するように、WTRUまたはWTRUのグループを構成することができる。このフィードバック方式は、特に、プリエンプションが、初期のTB送信および任意の後続する再送信における全CBGの非常に小さい比にしか影響しない場合に、HARQフィードバックオーバーヘッドを大幅に低減することができる。WTRUは、BS(例えば、gNB)に報告されているマルチビットHARQフィードバックに小さいCRC(例えば、単一のパリティビットまたは3ビットのCRC)を付加することができる。フィードバックビットの数は、再送信の間に変化し得、NACKとACKとの誤りの結果として、以前に送信されているCBGを復元するのが困難になり得るため、これは、可変ビットのHARQフィードバック方法にとって有益であり得る。
図8は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、固定ビットのCBGに基づくHARQフィードバック815または可変ビットのCBGに基づくHARQフィードバック820、825に基づく、マルチビットHARQフィードバックの例示的な再構成を示す。上述されているように、マルチビットHARQフィードバックは、WTRUが再送信を要求しているCBGの1つまたは複数のHARQ NACK情報ビットを含むことができる。マルチビットHARQフィードバックを送信した後、WTRUは、再送信のためにスケジューリングされているCBGについて、PDCCHを介してDCIを受信することができる。DCIは、送信のためにスケジューリングされているCBG805のビットマップを含むことができる。図8に示されているように、CBG805のビットマップは、CBG2、CBG3、CBG4、CBG5およびCBG6 810が再送信のためにスケジューリングされているCBGであることを示す。WTRUが、再送信されているCBG810(すなわち、CBG2、CBG3、CBG4、CBG5およびCBG6)を受信すると、WTRUは、固定ビットのCBGに基づくHARQフィードバック815または可変ビットのCBGに基づくHARQフィードバック820、825に基づいて、マルチビットHARQフィードバックを再構成することができる。
WTRUが、固定ビットのCBGに基づくHARQフィードバック815を提供するように再構成される場合、WTRUは、TB内のCBGの総数に基づいて、マルチビットHARQフィードバック(すなわち、固定ビットのCBGに基づくHARQフィードバック815)を生成することができる。図8に示されているように、マルチビットHARQフィードバックは、その固定ビットのCBGに基づくHARQフィードバック815のために12ビットを含むことができる。WTRUは、復号の結果に基づいて再送信されているCBG810のACKまたはNACKビット816を生成することができる。以前の送信において首尾よく受信(または復号)されたCBG(すなわち、CBG1、CBG7〜12)について、WTRUは、ACKビット817を生成することができる。
WTRUが、可変ビットのCBGに基づくHARQフィードバック820、825を提供するように再構成される場合、WTRUは、スケジューリングされているCBGの総数に基づいて、マルチビットHARQフィードバック(すなわち、可変ビットのCBGに基づくHARQフィードバック820、825)を生成することができる。図8に示されているように、マルチビットHARQフィードバックは、その可変ビットのCBGに基づくHARQフィードバック820のために5ビットを含むことができる。WTRUは、復号の結果に基づいて再送信されているCBG810のACKまたはNACKビット820を生成することができる。加えて、可変ビットのCBGに基づくHARQフィードバック825は、誤り検出のためのCRC830を含むことができる。例えば、単一ビットのCRC830または3ビットのCRC830が、BSに報告されているマルチビットHARQフィードバック(すなわち、可変ビットのCBGに基づくHARQフィードバック825)に付加され得る。例えば、スケジューリングされているCBGの数が少なく、かつ/または、NACKとACKとの誤りの確率が低い場合、WTRUは、誤り検出のために単一のパリティビットのみを含むことを選択することができる。代替的にまたは付加的に、スケジューリングされているCBGの数が多く、かつ/または、NACKとACKとの誤りに遭遇する可能性がある場合、WTRUは、より長い、例えば、3ビットのCRCを利用することを選択することができる。HARQフィードバックを受信すると、BS(例えば、gNB)は、CRCを検査することができる。CRC検査が不合格である場合、BSは、WTRUに、HARQフィードバックを再送することを求めることができる。代替的にまたは付加的に、BSが、いずれのビットに誤りがあるかを検出することが可能である場合、BSは、誤りがあるHARQビットに対応するCBGのみを再送信することを選択することができる。
パリティビットまたは小さいCRCを使用することによっていくらかの追加のオーバーヘッドビットがHARQフィードバックに加わるにもかかわらず、そのような手法は、少ない数「k」のCBG(k<<N)のみが再送信のためにスケジューリングされている、固定「N」ビットのHARQフィードバック方式を利用する代わりに使用され得る。
上述されているように、BS(例えば、gNB)は、固定マルチビットHARQまたは可変ビットHARQフィードバック方式を利用するように、WTRUまたはWTRUのグループを半静的または動的に構成することができる。1つの例において、BS(例えば、gNB)は、LTEにおけるPUCCHフォーマット4または5と同様に、ペイロードのより大きいPUCCHフォーマットを使用して固定マルチビットHARQフィードバックを報告するように、WTRUを構成することができる。別の例において、BS(例えば、gNB)は、LTEにおけるPUCCHフォーマット1bまたは3と同様に、ペイロードのより小さいPUCCHフォーマットを使用して可変マルチビットフィードバックを報告するように、WTRUを構成することができる。
加えて、WTRUまたはWTRUのグループは、固定ビットHARQフィードバック報告方式と、可変ビットHARQフィードバック報告方式との間で半静的にまたは動的に切り替えられ得る。この切り替えは、WTRUのeMBBトラフィックをプリエンプトしているURLLCトラフィックの周波数、プリエンプションによって影響されている時間−周波数(T−F)リソースの量、または、観測されている干渉の変化などのような要因によって容易にされ得る。
HARQフィードバックサイズの半静的および/または動的な構成に加えて、WTRUは、マルチビットHARQフィードバックに利用するためのビット数「N」を黙示的に導出することができる。これは、WTRUまたはWTRUのグループに対して指定されている構成済みPUCCHフォーマットに基づいて行われ得る。例えば、ペイロードサイズのより小さいPUCCHフォーマットを用いて構成されているWTRUは、可変ビットHARQフィードバックフォーマットを利用するための黙示的な指標としてこれを使用することができ、WTRUは、BS(例えば、gNB)によって再送信のためにスケジューリングされているCBGのHARQフィードバックのみを提供し得る。代替的にまたは付加的に、WTRUが全CBGセット(TB内の全てのCBGから成るセット)の全ての「N」ビットに対応することができる、ペイロードサイズのより大きいPUCCHフォーマットを用いて構成される場合、WTRUは、TB内の全てのCBGのHARQフィードバックを提供するための指標としてこれを使用することができる。
一実施形態において、WTRUは、UCIペイロードサイズが変動する複数のPUCCHフォーマットを利用するように構成され得、ここで、これらのフォーマットの間で選択するというオプションがある。例えば、カバレッジまたは電力が制約されたWTRUは、電力消費を低減するための手段として、TB内の全てのCBGとは対照的に、ペイロードのより小さいPUCCHフォーマットを選択することによって、BS(例えば、gNB)によって再送信されるCBGのみに対するHARQフィードバックを提供することができる。BS(例えば、gNB)はこのとき、PUCCHフォーマット、および、従って、例えば固定または可変ビットなど、いずれのタイプのフィードバックがWTRUによって提供されているかを決定するために、PUCCHをブラインド復号する必要があり得る。
別の実施形態において、固定ビットHARQフィードバックと可変ビットHARQフィードバックの両方を利用することができるように構成されているWTRUは、1つのオプションを使用して開始し、その後、プリエンプトしているトラフィックの周波数、プリエンプションによって影響されるCBG、影響されるWTRUの数、干渉などの様々な要因に基づいて、他方のオプションに切り替えることができる。例えば、WTRUは、初期送信のためのCBGセット全体(例えば、TB内の全てのCBG)に対して固定ビットHARQフィードバックを提供することができる。しかしながら、第2の送信において、再送信されているCBGの数が大幅に少ない場合、WTRUは、現在の再送信のためにスケジューリングされているCBGに対してのみ、可変ビットHARQフィードバックを報告することがより効率的であると判断することができる。
BS(例えば、gNB)は、特定のフィードバックオプションをデフォルトのフィードバックモードとして使用するように、WTRUを半静的に構成することができる。例えば、WTRUは、全CBGセットに基づいて固定ビットHARQフィードバックを利用するように構成され得るが、UCIオーバーヘッドの観点からこれが非効率であることが判明している場合、可変ビットフィードバックのオプションに切り替えることができる。例えば、誤りがあるCBGが少数のみであるために、BS(例えば、gNB)が、多数の再送信をスケジューリングする必要がある場合、固定ビットフィードバック方式の下で多数のHARQフィードバックビットが送られる必要があるため、これは大きいアップリンクオーバーヘッドを引き起こす。デフォルトのフィードバックオプションは、いくつかのTB送信に適用されるように構成され得、一方、優先的なオプションは、送信されている現在のTBのみに適用され得る。
別の実施形態において、WTRUは、可変ビットHARQフィードバックのオプションをデフォルトのオプションとして利用するように構成され得るが、固定ビットHARQフィードバックに切り替えることができる。例えば、いくつかの可変ビットフィードバックメッセージが(これらのHARQフィードバックメッセージのCRC検査に不合格になり、結果として、BSによってHARQフィードバックの再送信が要求されることに起因して)WTRUによって再送信される必要がある場合、この結果として、追加のHARQオーバーヘッドおよび/またはデータ再送信が生じ得る。そのような事例において、WTRUが、固定ビットHARQフィードバックのオプションに戻ることがより効率的である場合がある。
別の実施形態において、WTRUは、デフォルトのフィードバック構成から代替的なフィードバックオプションへと(例えば、可変ビットHARQフィードバックから固定ビットHARQフィードバックへと)自律的に切り替えることができる。これは、複数のPUCCHフォーマットを用いてWTRUを構成することによって容易にされ得る。代替的にまたは付加的に、HARQフィードバックオプションの切り替えまたは再構成は、DCIを介して明示的に、または、PUCCHフォーマットの再構成などに基づいて黙示的にシグナリングされ得る。
複数のPDSCHに対するマルチビットHARQフィードバックが本明細書において説明されている。マルチキャリアスケジューリングの事例において、WTRUは、複数のTBに対して、アグリゲートされたHARQフィードバックを提供する必要があり得る。例えば、DL送信のための複数のスロットが、単一のHARQ−ACKフィードバックスロットによって確認応答される必要があり得る。ペイロードのより大きいPUCCHフォーマットを用いてさえ、送信に利用可能なHARQフィードバックビットの数は、UCIペイロードサイズによって制限され得る。複数のPDSCHは、複数のコンポーネントキャリア(CC)、複数のセル、複数のスロット/ミニスロット/サブスロット/非スロット、複数の帯域幅部分(BWP)などにわたってスケジューリングされているものとして考えられ得る。本明細書において開示されている方法は、単一のHARQフィードバックメッセージによって確認応答される必要がある複数のPDSCHの上記シナリオのいずれかに適用することができる。
一実施形態において、BS(例えば、gNB)は、RRCシグナリングを介して、および/または、動的にL1/L2レイヤシグナリングを介して、複数のTBのためのフィードバックを提供するために固定されたHARQ−ACKフィードバックフォーマットを利用するように、WTRUを半静的に構成することができる。WTRUは、その後、単一のHARQ−ACKフィードバックメッセージにおいて全てのTBにわたって、例えば、TB内の全てのCBGなど、CBGセット全体に関するACK−NACK情報を送る、複数のPDSCH TBに対するHARQ−ACKフィードバックを多重化することができる。複数のTBに対するHARQフィードバックを多重化することは、WTRUまたはWTRUのグループが、同じマルチビットHARQフィードバックにおいて複数のTBの受信を確認応答することを意味し得る。例えば、WTRUが2つのTBを受信する場合、WTRUは、第1のTBのHARQ−ACK情報ビットの後に、第2のTBのHARQ−ACK情報ビットを連結することができる。例えば、WTRUが2つのTBを受信し、各TBが8つのCBGを含む場合、マルチビットHARQフィードバックは、2つのTBの16個のHARQ−ACK情報ビットを含むことができる。最初の8ビットは、第1のTB内のCBGのHARQ−ACK情報ビットを表すことができ、第2の8ビットは、第2のTB内のCBGのHARQ情報ビットを表すことができる。WTRUが、CBGの全てのCBを正確に受信した場合、WTRUは、CBGのHARQ−ACK情報ビットのACKを生成することができる。WTRUが、CBGの少なくとも1つのCBを正確に受信しなかった場合、WTRUは、CBGのHARQ−ACK情報ビットのNACKを生成することができる。
代替的にまたは付加的に、BS(例えば、gNB)は、複数のTBのフィードバックを提供するのに必要とされるHARQフィードバックビットの総数を低減するために、可変ビットHARQ−ACKフィードバックを利用するように、WTRUまたはWTRUのグループを半静的および/または動的に構成することができる。WTRUは、その後、単一のHARQ−ACKフィードバックメッセージにおいて全てのTBにわたって再送信のためにスケジューリングされているCBGのみに関するACKまたはNACKを送る、複数のPDSCHに対するHARQ−ACKフィードバックを多重化することができる。
別の実施形態において、BS(例えば、gNB)は、ペイロードが変動する1つまたは複数のPUCCHフォーマットタイプを利用するように、WTRUまたはWTRUのグループを構成することができる。WTRUはこのとき、これは、特定のフィードバックフォーマットを利用するための黙示的な指標であると仮定することができる。例えば、小さいUCIペイロードのみを搬送することが可能なPUCCHフォーマットを用いて構成されているWTRUは、BS(例えば、gNB)がTBに基づくHARQフィードバックのみを予測することの指標として解釈され得る。WTRUはこのとき、各TBのACK−NACKフィードバックを多重化し、これをフィードバックとしてBS(例えば、gNB)に提供することができる。
別の実施形態において、BS(例えば、gNB)は、大きいUCIペイロードを搬送することが可能である単一のPUCCHフォーマットを利用するように、WTRUまたはWTRUのグループを構成することができる。これは、BS(例えば、gNB)が、各多重化されたPDSCHについて、CBGに基づくHARQフィードバックまたはCBGレベルとTBレベルとが組み合わされたフィードバックを予測することの指標として解釈され得る。
また別の実施形態において、複数のPUCCHリソース/リソースセット/フォーマットを用いて構成されているWTRUは、UCIペイロードに基づいて、PUCCHリソース/リソースセット/フォーマットの中から1つまたは複数のリソースを選択することができる。例えば、WTRUが、複数のT−Fリソース(例えば、スロット、セル、CC、BWPなど)にわたるいくつかのPDSCHに対するマルチビットHARQフィードバック応答を提供する必要がある場合、WTRUは、最大のUCIペイロードサイズ向けに構成されているPUCCHリソースセットを選択することができる。しかしながら、WTRUが、少数のPDSCHに対するマルチビットHARQフィードバックを提供する必要がある場合、WTRUは、わずかにより小さいUCIペイロードサイズ向けに構成されているPUCCHリソースセットを選択することによって最良にサービスされ得る。PUCCHリソースセット/フォーマットおよびPUCCHリソース選択に関する追加の詳細が、本明細書において開示されている。
別の実施形態において、複数のPUCCHフォーマットオプションを用いて構成されているWTRUは、(例えば、CBGに基づくおよび/またはTBに基づくフィードバックを多重化することによって)TBに対して単一ビットHARQフィードバックを提供しようとしているか、または、マルチビットHARQフィードバックを提供しようとしているかを自律的に判断することができる。例えば、WTRUは、HARQフィードバックのサイズに基づいて、複数のPUCCHフォーマットの中から適切なPUCCHフォーマットを選択することができる。適切なPUCCHフォーマットは、大きいまたは小さいUCIペイロード容量をサポートすることができるフォーマットであり得る。適切なPUCCHフォーマットおよびHARQフィードバックのサイズに基づいて、WTRUは、提供すべきHARQフィードバックのタイプを決定することができる。加えて、BS(例えば、gNB)は、その後、PUCCHをブラインド復号することによって、いずれのタイプのフィードバックが提供されたかを確認することができる。
代替的にまたは付加的に、確認応答される必要がある全てのTBのCBGにわたってマルチビットHARQフィードバックを多重化する代わりに、BS(例えば、gNB)は、WTRUに、全てのTBのサブセットに対するCBGに基づくマルチビットHARQフィードバックと、残りのTBに対するTBに基づく単一ビットHARQフィードバックとを多重化する柔軟性を提供することができる。具体的には、上位レイヤのパラメータを用いて半静的および/または動的に構成されているWTRUは、残りのTBに対するTBに基づく単一ビットHARQフィードバックを提供しながら、TBのサブセットに対するCBGに基づくマルチビットHARQフィードバックを多重化することができる。例えば、それぞれ5つのコンポーネントキャリアを介して5つのTBを受信したWTRUは、最初の3つのCCに対するCBGにマルチビットHARQフィードバック、および、残りの2つのCCに対するTBに基づく単一ビットHARQフィードバックを提供するように構成され得る。これは、WTRUが、最初の3つのCCを介して受信される最初の3つのTBに対するマルチビットHARQフィードバック、および、残りの2つのCCを介して受信される残りのTBに対する単一ビットHARQフィードバックを提供することができることを意味する。これらのマルチビットHARQフィードバックおよび単一ビットHARQフィードバックは、単一のフィードバックメッセージに多重化(または連結)され得る。この技法は、動的なコードブック設計として参照される場合がある。例えば、多重化されたフィードバックメッセージは、マルチビットHARQフィードバックおよび単一ビットHARQフィードバックを含むことができ、第1のサブコードブックおよび第2のサブコードブックを含むコードブックに基づいて生成され得る。第1のサブコードブックは、フォールバックDCIによってスケジューリングされるTBに基づくPDSCH受信に基づいて決定され得る。第2のサブコードブックは、非フォールバックDCIによってスケジューリングされるCBGに基づくPDSCH受信に基づいて決定され得る。
CBGに基づくマルチビットHARQフィードバックは、プリエンプションによって影響されるTBに利用され得、一方、プリエンプションによって影響されないかまたは全てのCBGを首尾よく受信する(すなわち、TB全体を正確に受信する)TBは、TBに基づく単一ビットHARQフィードバックによって確認応答され得る。CBGに基づくマルチビットHARQフィードバックという用語は、マルチビットHARQフィードバックと交換可能に使用され得、TBに基づく単一ビットHARQフィードバックという用語は、単一ビットHARQフィードバックと交換可能に使用され得る。
BS(例えば、gNB)は、WTRUが、単一のHARQフィードバックメッセージにおいて、いくつかのPDSCHに対するこの多重化されたCBGに基づくマルチビットHARQフィードバックおよびTBに基づく単一ビットHARQフィードバックを提供することを可能にするフィードバック構成(すなわち、PUCCHフォーマット)を用いてWTRUを構成することができる。例えば、WTRUが、PUCCHフォーマット2またはPUCCHフォーマット3またはPUCCHフォーマット4を使用してHARQフィードバックを送信する場合、WTRUは、この単一のHARQフィードバックメッセージを提供するために上位レイヤのパラメータを用いて半静的および動的に構成され得る。上位レイヤのパラメータは、WTRUがHARQフィードバックを提供するように半静的に構成されていることを示すインジケータ(例えば、CBG−DL=ON)を含むことができる。インジケータ(例えば、CBG−DL=OFF)はまた、WTRUがHARQフィードバックを提供するように動的に構成されていることも示すことができる。一実施形態において、WTRUは上位レイヤのパラメータを用いて構成されないが、WTRUは、多重化されたCBGに基づくマルチビットHARQフィードバックおよびTBに基づく単一ビットHARQフィードバックを提供することができる。構成済みフィードバックフォーマットは、各PDSCHに対するCBGに基づくマルチビットHARQフィードバックとTBに基づく単一ビットHARQフィードバックの両方のフィールドを提供することができる。WTRUは、これらのPDSCH送信がCBGに基づくマルチビットHARQフィードバックによってより良好にサービスされ得ることの指標として、BS(例えば、gNB)によって送信されるプリエンプション指標の存在を利用することができ、一方、復号されるのに失敗し、プリエンプトされなかった(すなわち、プリエンプション指標が存在しない)PDSCHは、TB全体を再送信することによって、より良好にサービスされ得る。TBとCBGの両方のレベルのフィードバックをサポートする単一のPUCCHフォーマットを使用することによって、WTRUに、一切の追加のULシグナリングを必要とすることなく、PDSCHごとにPDSCHに関するCBGおよび/またはTBレベルのフィードバックを提供すべきか否かを選択する柔軟性を提供することができるため、一定程度の柔軟性を提供しながら、フィードバック設計を単純化することができる。WTRUはまた、その判断決定の補助においてプリエンプション指標などの追加のシグナリングの存在を利用することもできる。
WTRUは、TBビットマップなどのPUCCHフィールド内のフィールドを介してTBのサブセットを示すことができる。WTRUが、単一のHARQ−ACKフィードバックメッセージにおいて複数のTBを確認応答する方法の決定において柔軟性を有することを可能にすることは、特に、WTRUが電力またはカバレッジを制約されているときに有益であり得る。この事例において、PUCCHあたりの送信されているビット数を制限することによって、ダウンリンクスペクトル効率に対する影響を無視できる程度にしながら、ULカバレッジを改善することができる。
一実施形態において、WTRUは、単一のフィードバックメッセージにおいて、全てのTBに対する、または、TBのサブセットのみに対する、バンドル化されたHARQフィードバックを提供することができる。例えば、WTRUは、WTRUによって正確に受信されたTBのみにわたって、各TBからの単一ビットのACKを多重化し、または、誤って受信されている各TBからの単一ビットのNACKを多重化することができる。
単一のPDSCHの事例と同様に、WTRUまたはWTRUのグループは、構成済みPUCCHフォーマットに基づいてHARQフィードバックフォーマットについて判断することができる。例えば、小さい(または最小の)PUCCHペイロードフォーマットを用いて構成されているWTRUは、BS(例えば、gNB)が、全てのPDSCHに対する多重化されたTBに基づく単一ビットHARQフィードバックを受信すると予測することの黙示的な指標としてこれを解釈することができ、一方、大きいPUCCHペイロードフォーマットを用いて構成されているWTRUは、BS(例えば、gNB)が、いくつかのPDSCHに対する、TBに基づくマルチビットとCBGに基づく単一ビットの両方の多重化されたHARQフィードバックを含む単一のフィードバックメッセージを受信すると予測することの指標としてこれを解釈することができる。
複数のPDSCHに対するフィードバックオプションを容易にするために、HARQコードブック設計の様々な態様が考慮され得る。1つの例において、CBGに基づくマルチビットHARQフィードバックの事例について、マルチビットHARQフィードバックのサイズが全てのPDSCHにわたって固定されている半静的なコードブック設計が、CBGに基づくマルチビットHARQフィードバックに対して採用され得る。これは、全てのPDSCHにわたる最大数のCBGなどの、CBGの構成されている数に基づき得る。半静的なコードブック設計は、WTRUが、全てのPDSCHにわたって固定されたマルチビットフィードバックサイズを構成することを可能にすることができ、これは、全ての構成済みコンポーネントキャリア(すなわち、スケジューリングされているおよびスケジューリングされていないPDSCHを含む全ての可能なPDSCH)に対するフィードバックを提供することと組み合わされる。従って、半静的なコードブック設計の結果として、複雑度が低減され得る。しかしながら、構成済みCBGおよびコンポーネントキャリアの数に起因して、UCIペイロードが過度に大きくされ得る。
上述されているように、上位レイヤのパラメータを用いてサービングセルごとに半静的に構成されているWTRUは、TBのCBGを含むPDSCHを受信することができる。WTRUが半静的に構成されている場合、WTRUは、半静的なコードブックを生成するために、サービングセルごとの上位レイヤのパラメータによって最大数のCBGを用いて構成され得る。この半静的なコードブックは、TB受信のためにそれぞれのHARQ−ACK情報ビットを含むことができる。HARQ−ACK情報ビットの各々は、TB内の全てのCBG(スケジューリングされていないCBGを含む)に対応することができる。半静的なコードブックのペイロードサイズは、CBGの構成されている数(すなわち、CBGの最大数)と同じであり得る。
別の実施形態において、WTRUは、HARQフィードバックメッセージを提供するために動的なHARQコードブック設計を利用することができ、ここで、マルチビットHARQフィードバックのサイズは全てのPDSCHにわたって固定される。例えば、マルチビットHARQフィードバックのサイズは、半静的なHARQコードブック設計と同様に、全てのPDSCHにわたって、構成済みCBGの最大数に基づいて決定され得る。しかしながら、動的なHARQコードブック設計においては、WTRUは、全ての構成済みPDSCHではなく、スケジューリングされているPDSCHに対するHARQフィードバックを提供することができる。これは、ダウンリンク割り当てインデックス(DAI)のタイプのメカニズムを利用することによって容易にされ得る。そのような手法は、HARQフィードバックのペイロードサイズの低減をもたらすことができる。しかしながら、スケジューリングされているPDSCHにわたる構成済みCBGの数の差などの、他の要因が、この節約をオフセットする可能性がある。
フィードバックリソースを効率的に利用し、無駄にされるリソースを最小限に抑えるための追加の実施形態が、本明細書において説明され得る。一例は、複数のTBにわたるTBあたりの構成済みCBGの数が同様であることを保証することであり、それによって、結果として、多重化されたPDSCHのセットについて送信される不要なフィードバックビットの数が最小限に抑えられる。これは、複数のPDSCHにわたる全てのTBを、同じ数のCBGを用いて、または、何らかの差分値(例えば、0もしくは1)内で構成することによって行われ得る。この結果として、これらのTBにわたるCBGを形成するCBの数に関して異なる粒度をもたらすことができ、また、結果として、(再)送信の異なる粒度ももたらすことができる。しかしながら、これは、特に異なるセルが異なるカバレッジを有する場合に、TB(またはセル/CC)ごとに大きいフィードバックサイズを有するために好適であり得る。加えて、カバレッジおよび電力が制約されているWTRUに対するフィードバックビット(および、一般的に全体的なフィードバック)の数を制限することがより重要であり得る。これらの要因を考慮して、BS(例えば、gNB)は、このカバレッジおよび電力が制約されているWTRUに対するHARQフィードバックサイズ(対CBG(再)送信の粒度)に関して最良のトレードオフを提供するものをファクタリングしながら、TBあたりのCBGの数を構成することができる。
代替的にまたは付加的に、BS(例えば、gNB)は、スケジューリングされているPDSCHを確認応答するためにWTRUによって送られる必要があるフィードバックビットの数を低減/最適化することができるように、PDSCHをスケジューリングすることができる。例えば、BS(例えば、gNB)は、連続するタイムスロットにおいて構成済みCBGの何らかの「δ」内にあるPDSCHをスケジューリングするように試行することができる。この結果として、無駄にされるまたは不要なHARQビットの数を大幅に低減することができる。同様のサイズにされているPDSCHをこのようにスケジューリングする結果として、特定の事例において追加のフィードバック節約をもたらすことができる。例えば、スケジューリングされているPDSCHがいずれも低遅延トラフィックによってプリエンプトされていない場合、WTRUは、全てのPDSCHに対する単一ビットHARQフィードバックの多重化/バンドル化に戻るまたはフォールバックすることができる。特に、PDSCHあたりの(スケジューリングされているPDSCHの)CBGの数が少ないとき、そのようなシナリオの結果として、送信窓が、例えば、PDSCHあたりの構成済みCBGの数がより多いときよりも小さくなり得るため、低遅延トラフィックがこれらの送信に影響を与える機会をより少なくすることができる。
構成済みCBGの数に基づくPDSCHのスケジューリングは、この結果として、低遅延トラフィックによって、スケジューリングされているPDSCHの全てが影響を受けるかまたはPDSCHのいずれもが影響を受けないかのいずれかになり得るため、低遅延トラフィックのプリエンプションが本質的に周期的である事例において、効率的なフィードバック多重化をもたらすことができる。第1のシナリオは、低遅延トラフィックが周期的かつ頻繁である事例であり得る。第2のシナリオは、プリエンプションのトラフィックが周期的かつ相対的に頻繁でない事例であり得る。これらの事例のいずれかにおいて、WTRUは、1つのタイプのフィードバック、例えば、第1のシナリオのマルチビットHARQフィードバックおよび第2のシナリオの単一ビットHARQフィードバックを必要とし得る。これによって、WTRUが、フィードバックリソースを効率的に使用することが可能になり得る。
代替的にまたは付加的に、BS(例えば、gNB)は、割り当てられているコンポーネントキャリア(CC)に基づいてPDSCHをスケジューリングすることができる。割り当てられているCCに基づくPDSCHのスケジューリングは、これが、低遅延トラフィックをスケジューリングするためにいずれのリソースが利用される可能性が高いかに関する情報を利用する場合に有用であり得る。特定のCCが優先度の高い低遅延トラフィックをスケジューリングするために指定または利用される場合、BS(例えば、gNB)は、連続するスロットにおいてこれらのCCをスケジューリングすること、または、連続的なスロットに対してこれらのCCを回避することのいずれかを考慮することができる。この結果として、このとき、全てのPDSCHが単純にマルチビットHARQフィードバック(スケジューリングされているCC送信がプリエンプトされる事例において)または単一ビットHARQフィードバック(スケジューリングされているPDSCHのいずれもがプリエンプションによって影響されない事例において)を必要とし得るため、フィードバックの多重化がより効率的になり得る。
代替的にまたは付加的に、CC/サービングセルのカバレッジが、スケジューリングされているPDSCHに対する適切なHARQフィードバックフォーマットの選択における決定要因であり得る。例えば、いくつかのCCのカバレッジに起因してWTRUの電力が制約されている場合、それは、これらのセルにおけるWTRUのULカバレッジを改善するために、全てのスケジューリングされているPDSCHに対するTBに基づく単一ビットHARQフィードバックの多重化に戻るまたはフォールバックする必要があり得る。
代替的にまたは付加的に、それは、スケジューリングされているPDSCHに対する、TBに基づく単一ビットおよび/またはCBGに基づくマルチビットの多重化されたHARQフィードバックの何らかの組み合わせを提供する必要があり得る。これは、PDSCHのサブセットのいくつかがプリエンプションによって影響されるシナリオに当てはまり得る。この事例において、プリエンプションによって影響されるWTRUは、個々のCBGに対するフィードバックを提供するために、マルチビットHARQフィードバックを提供する必要があり得る。しかしながら、プリエンプションによって影響されないWTRUについては、単一ビットフィードバックで十分であり得る。TBに基づくフィードバックとCBGに基づくフィードバックの両方のオプションを提供するために、各個々のフィードバックメッセージは、固定された単一ビットおよびマルチビットのフィードバックフィールドを含み得る。スケジューリングされているPDSCHに対するTBに基づくフィードバックとCBGに基づくフィードバックの両方を提供することが可能である結果として、それは、BS(例えば、gNB)に、再送信の最適な粒度(CBG対TB)における完全な柔軟性を提供することができる。単一のPDSCHと同様に、TBに基づくフィードバックとCBGに基づくフィードバックの両方を利用することによって、HARQフィードバックの誤りのための組み込み誤り検出(ロバスト性が追加される)を提供することもできる。そのような手法の不都合な点は、UCIペイロードが大きい事例であり得る。
WTRUは、スケジューリングされている各PDSCHに対してCBGに基づくマルチビットおよび/またはTBに基づく単一ビットHARQフィードバックを提供すべきかに関するその判断決定を補助するために、BS(例えば、gNB)によるプリエンプション指標の存否を利用することができる。例えば、WTRUは、BS(例えば、gNB)が、影響されるPDSCHに対してCBGに基づくマルチビットHARQフィードバックを予測することの明示的な指標として、この信号を知覚することができる。別の例では、WTRUは、いずれのタイプのフィードバックフォーマットを利用すべきかに関して自律性を有することができる。例えば、全てのスケジューリングされているPDSCHにおいて多数のCBGが首尾よく復号されることが不可能であり、かつ、WTRUが、多重化されたTBに基づく単一ビットHARQフィードバックまたは多重化されたCBGに基づくマルチビットHARQフィードバックのいずれかをサポートするために2つのPUCCHフォーマットを用いて構成されている場合、WTRUは、全てのPDSCHに対してTB全体の再送信を要求した方がよいと判断することができる。WTRUは、全てのPDSCHに対してTB全体の再送信を要求すると判断するため、WTRUは、それに応じて、全てのPDSCHに対する単一ビットHARQフィードバックを用いて応答することができる。
上述されているように、スケジューリングされているPDSCHにわたってHARQフィードバックを多重化するための様々なオプションが、半静的と動的の両方のコードブック設計に適用され得る。結果として、多重化されたPDSCHのセットに対する、TBに基づく単一ビットHARQフィードバックおよび/またはCBGに基づくマルチビットHARQフィードバック、または、両方のフィードバックの組み合わせは、半静的と動的の両方のコードブック設計に利用され得る。
動的なHARQフィードバックコードブック設計(スケジューリングされているセル/CCに基づく)の事例について、BS(例えば、gNB)は、PDSCHに対してスケジューリングされている各DL割り当てにおけるカウンタダウンリンク割り当てインジケータ(DAI)および/または全DAIを使用することによって、このコードブックサイズを示すことができる。WTRUはその後、たとえいくつかのDL割り当てが失われている場合であっても、スケジューリングされているPDSCHの数を確実に決定することができる。PDSCHあたりの構成済みCBGの数はWTRUに示されるため、WTRUは、その後、PDSCHに対するマルチビットHARQフィードバックを決定するために、各PDSCHのスケジューリングされているDCIからのCBGIFビットマップ(またはCBGTIビットマップ)とともに、この情報を使用することができる。DAIタイプフィールドを利用することは、各TBが同じマルチビットHARQフィードバックサイズを有するシナリオ(上述されているように全てのPDSCHにわたる構成済みCBGの最大数に基づき得る)に役立ち得る。
単一のPDSCHまたは多重化されていないHARQフィードバックの事例と同様に、いくつかのPDSCHに対する多重化されたマルチビットHARQフィードバックを提供するために、マルチビットHARQフィードバック向けに半静的に構成されているWTRUは、それらのそれぞれのHARQフィードバック応答において確認応答されているPDSCHのうちの1つまたは複数が、CBG(再)送信をサポートしていないDCIを用いてスケジューリングされているとき(例えば、PDSCHがフォールバックDCIを介してスケジューリングされているとき)、これらのPDSCHに対する単一ビットHARQフィードバックに戻る必要があり得る。
上述されているように、半静的なコードブック設計について、コードブックサイズは、構成済みCCの数、CBGの構成されている数、HARQタイミング窓などに依存し得る。例えば、TBあたり6つのCBGによって構成されるWTRUは、5つのTBに対して単一ビットHARQフィードバック応答を提供する必要があり得る。単一のHARQフィードバック応答は、各TBの各コードブックを、TB全体の単一のコードブックに多重化することによって生成され得る。1つの例において、5つ全てのTBが、CBGに基づく(再)送信が可能であるDCIによってスケジューリングされ得、WTRUは、単純に、5*6=30ビットのHARQフィードバック応答によって応答することができる。しかしながら、1つまたは複数のTBがフォールバックDCIを介してスケジューリングされる事例においては、TB全体がTBに基づく再送信のためにスケジューリングされ得る。WTRUは、単一ビットHARQフィードバックによって応答すべきか、または、マルチビットHARQフィードバックによって応答すべきかを判断する必要があり得る。様々なTBに対して単一ビットとマルチビットとのHARQフィードバックを混合させることによって、フィードバックが誤って解釈される可能性がある。
一実施形態において、WTRUは、同じフィードバック応答を維持する(例えば、それらが通常のまたはフォールバックDCIを介してスケジューリングされているか否かにかかわらず、全てのTBに対してマルチビットフィードバックによって応答する)ことを選択することができる。マルチビットHARQフィードバックを提供するように構成されているが、フォールバックDCIを介してスケジューリングされているWTRUについて、WTRUは、TBが正確に受信されたか否かを示すために、単純に、単一ビットのTB ACKまたはNACKをN回繰り返すことができる。ここで、NはTB内のCBGの数またはTB全体であり得る。これによって、フィードバックオーバーヘッドが増大されることと引き換えには成るが、設計が単純化され得る。例えば、マルチビットHARQフィードバックを提供するように半静的に構成されているWTRUは、2つのTBを受信し、ここで、各TBは8個のCBGを有する。第1のTBに関して、全てのCBレベルのCRCおよびTBレベルのCRC検査が合格になった場合、WTRUは、ACK情報ビットを8回繰り返すことによって(すなわち、11111111)、TBレベルのACKフィードバックを生成することができる。第2のTBに関して、全てのCBレベルのCRC検査が合格になったが、TBレベルの検査が不合格になった場合、WTRUは、NACK情報ビットを8回繰り返すことによって(すなわち、00000000)、TBレベルのNACKフィードバックを生成することができる。WTRUは、マルチビットHARQフィードバックを提供するように半静的に構成されているため、2つの8ビットの結果(すなわち、第1のTBの11111111および第2のTBの00000000)は、多重化される必要があり得る。従って、WTRUは、第1のTBに対する第1のマルチビットHARQフィードバックおよび第2のTBに対する第2のマルチビットHARQフィードバックを含むマルチビットHARQフィードバックメッセージ(すなわち、1111111100000000)を送信することができる。
別の実施形態において、フォールバックDCIを用いてスケジューリングされている単一のTBを有するWTRUは、それが、CC/HARQタイミング窓内で全てのTBに対して単一ビットHARQフィードバックによって応答する必要があることの指標としてこれを解釈することができる。例えば、WTRUがそれぞれ5つのCCにおいてフォールバックDCIを用いてスケジューリングされている5つのTBを受信し、かつ、各TBが6つのCBGを含む場合、WTRUは、WTRUがマルチビットHARQフィードバックを提供するように構成されている場合に30ビット(すなわち6ビット*5つのTB)を提供する必要があり得る。しかしながら、WTRUが全てのTBに対して単一ビットHARQフィードバックを提供することができる場合、HARQフィードバック内のビット数は、30ビットから5ビットのみに降下し得る。この結果として、UCIペイロードははるかに小さくなり得るが、そのような手法の不都合な点は、不要な可能性がある再送信の回数が大きく、スペクトル効率が無駄にされることであり得る。
また別の実施形態において、複数のアグリゲートされたPDSCHに対して、単一ビットのHARQフィードバック応答によって応答すべきか、それに対して、マルチビットHARQフィードバック応答によって応答すべきかの選択は、確認応答される必要がある各PDSCHの復号結果に基づき得る。
別の実施形態において、単一のTBがフォールバックDCIを介してスケジュールされているが、WTRUが、相当数の他のPDSCHがCBGに基づく(再)送信のためにスケジュールされている、または、相当数のCBGが低遅延トラフィックをプリエンプトすることによって影響されると決定する場合、WTRUは、これらのPDSCHについて、TB全体の再送信を要求するように判断することができる。結果として、WTRUはこのとき、全てのPDSCHに対する単一ビットHARQフィードバックメッセージによって応答することができる。この決定は、何らかの閾値に基づき得る。そのような閾値は、限定ではないが、PDSCHの何らかの数、または、アグリゲートされたPDSCHの割合(x%)を含むことができる。アグリゲートされたPDSCHに対して、単一ビットとマルチビットとの間でHARQフィードバックを切り替えるためのそのようなメカニズムを利用する結果として、フィードバックリソースの使用が最適になり(例えば、UCIペイロードを制限する)、また、結果生じ得る不要な再送信の回数も最小になる。
WTRUが、マルチビットHARQフィードバックを用いて構成されており、HARQ信頼性を改善する手段として単一ビットHARQフィードバックおよび/またはマルチビットHARQフィードバックを示すDCI内の1つまたは複数のフィールドを提供するフィードバックフォーマットを利用する場合、WTRUは、PDSCHをスケジューリングするためにフォールバックDCIが利用されたか、または、非フォールバックDCIが利用されたかに応じて、これらのフィールドを適切に利用することができる。例えば、非フォールバックDCIを用いてスケジューリングされているPDSCHについて、WTRUは、各CBGに対してHARQフィードバックを提供するためにマルチビットフィードバックを利用することができる。フォールバックDCIを用いてスケジューリングされているPDSCHについて、WTRUは、TBの復号結果に基づいて単一ビットHARQフィードバックを提供するために、単一ビットのフィードバックフィールドを使用する(またはまったく使用しない)ことができる。他方、フォールバックDCIを介してスケジューリングされているPDSCHについて、単一ビットのTBの結果が関連し、WTRUは、マルチビットのフィードバックフィールドに対して単一ビットフィードバックの結果を繰り返すことを選択することもできる(例えば、TBが首尾よく復号されることができたか否かに基づいて、全てのCBGに対してACKまたはNACK)。これは、フォールバックDCIの事例において、単一ビットフィールドがより妥当であるが、マルチビットフィールドも、TBに基づくマルチビットHARQフィードバックを提供するために使用され得ることを意味する。
上記実施形態において、構成されているPUCCHリソースセットの数およびそれらのUCIペイロード容量に関する情報は、複数のアグリゲートされているPDSCHに対してHARQフィードバック応答を提供するときに、WTRUが、単一ビットHARQフィードバックまたはマルチビットHARQフィードバックの間で自律的に判断する能力を制限し得る。例えば、WTRUが、UCIペイロード容量の小さい単一のPUCCHリソースセットのみを用いて構成される場合、WTRUは、これを、全てのアグリゲートされたPDSCHに対して、常に単一ビットHARQを用いて応答すると予測されることの指標と解釈することができる。一方、WTRUが、大きいUCIペイロードを搬送することが可能な、UCIペイロードの大きいPUCCHリソースセットを用いて構成される場合、WTRUは、これを、アグリゲートされたPDSCHの各々に対して常にマルチビットHARQフィードバックを用いて応答すると予測されることの明示的な指標と解釈することができる。
また別の実施形態において、2つ以上のPUCCHリソースセットを用いて構成されているWTRUは、これを、適切なフィードバック粒度を選択するのはWTRU次第であることの黙示的な指示と解釈することができる。この事例において、BS(例えば、gNB)は、いずれのフォーマットが、従って、いずれのフォーマットがWTRUによって選択されたかを確認するために、PUCCHをブラインド復号する必要があり得る。
WTRUが、全てのスケジューリングされているPDSCHの構成済みCBGの数が同じである、動的なHARQコードブックの事例においてフォールバックDCIと非フォールバックDCIとの混合に遭遇するとき、WTRUは、上述されているように、これらのアグリゲートされたPDSCHに対して、単一ビットのみおよび/またはマルチビットのHARQフィードバックを利用することを選択することができる。
上述されている動的なコードブック設計は、全ての構成済みセルとは対照的に、スケジューリングされているセル/CCに対してHARQフィードバックを考慮することができる。CBGに基づくスケジューリングを用いると、コードブック設計の動的な態様に対して追加の次元の可能性が存在し、これは、CBGに基づくスケジューリング/送信の粒度の結果である。マルチビットHARQフィードバックのサイズは、TB内のCBGの総数(すなわち、CBGの構成されている数)または(再)送信のためにスケジューリングされているCBGの数に基づき得る。(再)送信のためにスケジューリングされているサイズCBGに基づいてサイズを決定する結果として、同じTB内の再送信の間のHARQフィードバックビットの数が可変になり得る。PDSCH間の(およびPDSCH内の)可変ビット数を考慮に入れるために、動的なコードブック設計のDAI機能は、全ての可能な状態を考慮に入れるように拡張され得る。例えば、PDSCHの4つの構成済みCBGによって、HARQフィードバックビットの数は、1から4の間で変化し得る。連続的な欠けているDL割り当てをハンドリングするために、DAIは、可能な12個の状態をサポートするために4ビットを必要とし得る。構成済みCBGの数に応じて、DAIサイズ、および、DCIメッセージは、大幅に増大し得る。代替的にまたは付加的に、異なるPDSCHは異なる数の構成済みCBGを有し、DAIフィールドサイズを効率的に設計するのを困難にし得る。複雑度およびDCIオーバーヘッドを制限しながら、可変ビットのフィードバックを可能にするために、様々な技法が本明細書において説明され得る。
一実施形態において、ネットワークは、PDSCHごとに構成されているCBGの数を制限することを考慮することができ、これによって、DAIによってカバーされる必要がある可能な状態の数を制限することができる。代替的にまたは付加的に、DCIの2つの特色が使用され得、それらの各々は、異なるDAIフィールドサイズを有する。これは、BS(例えば、gNB)が、大きいかまたは小さいかにかかわらず、同様の数の構成済みCBGを有するPDSCHを多重化することを考慮する場合に有益であり得、これによって、2つの特色の間で選択することが可能である。これによって、このとき、より少数の構成済みCBGを有するPDSCHのDCIサイズを制限することができ、これによってまた、このフィールドを利用する効率的な方法が可能になる。
別の実施形態において、DCIの2つの特色は、フィードバック長の変動性に基づいて区別され得る。例えば、一方の特色は、PDSCHごとに固定されたフィードバックビット数が利用される事例のものであり(この事例においては、LTEからの2ビットのDAIフィールドがそのまま使用され得る)、他方の特色は、PDSCHごとに可変ビット数が利用される事例のものであり、これは、より大きいDAIサイズを有するDCIを必要とし得る。WTRUが、両方のDCI特色をモニタリングする必要があるか否かは、上位レイヤのシグナリングによって構成され得、BS(例えば、gNB)が、RRCシグナリングを介してWTRUごとに、TB/PDSCHあたりのCBGの数を構成するときに同時に行われ得る(DAIサイズはTB内のCBGの数に直に依存するため)。
また別の実施形態において、DCIの2つの特色は、LTEにおけるDCIフォーマットに基づき得る。例えば、拡張されたDAIフィールドが、既存のDCIフォーマットフィールドによって再使用され得る。例えば、5ビットのDAIフィールド(TBあたり10個のCBGをサポートすることが可能)が、既存の2ビットのDAIおよび3ビットのキャリアインジケータフィールド(CIF)を組み合わせることによって考慮され得る。この結果として、クロスキャリアスケジューリングの柔軟性が損失し得るが、例えば、マクロのみの展開を考慮するとき、これ自体は問題になり得ない。これは、複数のPDSCHのHARQ多重化を考慮するときに、フィードバックオーバーヘッドを低減するのを大きく助けることができる。
WTRUは、BS(例えば、gNB)によって、各PUCCHフォーマットが異なるペイロード(UCI)サイズを有する、複数のPUCCHフォーマットを利用するように構成され得る。WTRUは、このとき、上述されているHARQフィードバック要件に基づいて、その適切なPUCCHフォーマットを選択する場合を考慮することができる。そのようなシナリオの下では、BS(例えば、gNB)は、いずれのフォーマットおよびフィードバックオプションがコードブックによって利用されているかを確認するために、PUCCHをブラインド復号する必要があり得る。
BS(例えば、gNB)は、影響されるWTRUまたはWTRUのグループに、プリエンプションによって影響される時間−周波数(T−F)領域を黙示的または明示的のいずれかで示すことができる。システムは、低遅延トラフィックに対応するために、システム帯域幅の特定の部分が利用されることを指定することができる。指定されている領域は、DLシステム帯域幅全体をカバーし得、または、全DLシステム帯域幅の何らかの部分に制限され得る。指定されている領域はまた、半静的に割り当てられ得るか、または、動的に変化し得る。
図9は、DLシステム帯域幅の中間部分がプリエンプション可能な領域925として指定されている、例示的な、黙示的なプリエンプション指標900を示す。例えば、BS(例えば、gNB)は、RRCシグナリングを介して、全システム帯域幅のうちのいずれの部分がBS(例えば、gNB)によって低遅延トラフィックに対応するために利用され得るかをWTRUまたはWTRUのグループに半静的に示すことができる。半静的な構成は、黙示的なプリエンプション指標900として考えられることができ、BS(例えば、gNB)は、プリエンプション中に影響されるリソースをWTRUに明示的に示さない。この黙示的なプリエンプション指標900は、その後、WTRUによって、影響されているCB/CBG/TBを復号するのを助けるために利用され得る。例えば、この情報を用いて構成されているWTRUは、最初に、この指定されている領域においてPRBを復号するように試行することができる。この領域内のCB/CBGのいずれかに誤りがある場合、WTRUは、残りのPRBをさらに処理する前に、これらのCBのインデックスを示すマルチビットHARQフィードバックを送ることができる。これは、黙示的なプリエンプション指標900に基づく早期のHARQフィードバックメカニズムとして考えられ得る。早期のHARQフィードバックは、早期の再送信をトリガすることができ、それによって、遅延が改善する。図9に示されているように、システム帯域幅の中間部分は、予め定められたプリエンプション可能な領域925として指定され得る。指定されているプリエンプション可能な領域925は、CB2、CB3、CB6、CB7、CB14、CB15、CB18、CB19、CB22、CB23、CB26、およびCB27を含むPRBを含むことができる。プリエンプション可能な領域925内のCBの中で、CB10 905、CB11 915の一部、およびCB18 910は、低遅延トラフィックに対応するためにプリエンプトされていることができる。上部領域920および下部領域930は、eMBBトラフィックCBのためにスケジューリングされ得る。例えば、上部領域920および下部領域930は、CB1、CB4、CB5、CB8、CB9、CB12、CB13、CB16、CB17、CB20、CB21、CB24、CB25、およびCB28を含むことができる。この黙示的なプリエンプション指標900を用いて構成されているWTRUは、最初に、プリエンプション可能な領域925においてCBを復号しようと試行することができる。WTRUが、プリエンプション可能な領域925においてCBのいずれかを復号することができない場合、WTRUは、残りのCBを処理する前に、これらのCBのインデックスを示すマルチビットHARQフィードバックを送ることができる。
受信されているCBGに基づく送信/(再)送信を迅速/積極的に処理する能力を保持するWTRUは、そのような早期のフィードバックメカニズムを利用することができる。そのようなWTRUは、積極的/高速/高機能WTRUとして分類されることができ、送信されるスロット内でシンボル、ミニスロット、サブスロット、非スロットなどを積極的/迅速に処理/復号することができる。これは、WTRUが、早期のHARQフィードバック(すなわち、早期のHARQタイミングに基づく早期のHARQ−NACK)を提供することを可能にすることができる。スロットに基づく通常のHARQフィードバックタイミングとは異なり、早期のHARQ−NACKフィードバックタイミングは、シンボル、ミニスロット、サブスロット、非スロットのタイミングなどに基づき得る。結果として、早期のHARQフィードバックを提供することが可能なWTRUは、より高速の再送信を要求することができ、それによって、再送信遅延が低減する。
一実施形態において、プリエンプション可能な領域を用いて半静的に構成されている高機能WTRU/WTRUのグループは、スロット(例えば、シンボル、サブスロット、ミニスロット、非スロットなど)内でプリエンプション可能な領域内のリソースの復号を優先順位付けすることができる。例えば、スロット内の各ミニスロット、サブスロット、非スロットについて、WTRUは、低遅延トラフィックをプリエンプトすることによって影響されている可能性があり得るCBGを識別することができる。WTRUはその後、CBG内のCBを決定することができ、CBGの、プリエンプションによって影響されている可能性がある部分であるCBの復号に進む。WTRUはその後、CBG内の失敗したCBの数を決定することができる。この数が何らかの閾値を超える場合、WTRUは、CBGを、復号不可能であり、失敗したと考える。1つもしくは複数のCBGまたはCBGの何らかの閾値が失敗したと考えられる場合、WTRUは、例えば、ミニスロット/非スロット/サブスロットのタイミングに基づいて早期のHARQフィードバックを開始することができる。早期のHARQフィードバックは、単一ビットまたはマルチビットのHARQフィードバックであってもよい。一例において、CBGに基づくマルチビットHARQフィードバックを用いて構成されているWTRUは、失敗したCBGの再送信を要求するために、ミニスロットのタイミングにおいてこれを利用することができる。例えば、TBあたり8つのCBGを用いて構成されているWTRUは、8ビットのマルチビットHARQフィードバックを含むことができる。このWTRUは、これらのシンボルまたはミニスロット内のそれらのリソースの復号を優先順位付けするために、構成済みのプリエンプション可能な領域の知識を利用することができる。何らかの数(例えば、少なくとも1つのCBG)または閾値(例えば、構成済みCBGのある割合または比)に基づいて、影響されており、失敗したと考えられ得るCBGの数が相当であると考えられる場合、WTRUは、これらの影響されている(否定応答されている)CBGを再送信するようにBS(例えば、gNB)に通知するために、マルチビットフィードバックを利用することができる。
別の実施形態において、構成済みのプリエンプション可能な領域についてシンボルまたはミニスロット内のリソースの復号を優先順位付けするWTRUは、特定のCBGとは対照的に、TB全体の(早期の)再送信を要求するために、早期のHARQフィードバックを利用することができる。これは、相当数のCBGが、プリエンプトしているトラフィックによって影響されるシナリオにおいて発生し得る。例えば、早期のHARQフィードバックが、8つの可能な(または構成済み)CBGのうちの5つに基づき、これらの5つのCBGのうちの4つが破損されているとWTRUが決定した場合、WTRUは、BS(例えば、gNB)が、選択されるCBGとは対照的にTB全体を再送信することを要求するマルチビット(8ビット)の全てのNACKのフィードバックを送ることができる。
また別の実施形態において、マルチビットHARQフィードバックを用いて構成されているWTRUは、TBに基づく単一ビットHARQフィードバックの形態で、早期のHARQフィードバックを提供することができる。例えば、CBGに基づく(再)送信のために構成されているWTRUは、CBGに基づく(再)送信をサポートしないが、TBに基づく(再)送信をサポートするDCIによってスケジューリングされているPDSCHを有し、WTRUは、TBに基づく単一ビットHARQフィードバックの形態で、早期のHARQフィードバックを提供することができる。このために、BS(例えば、gNB)は、例えば、CBG送信インジケータ(CBGTI)フィールドまたはCBG送信情報(CBGTI)フィールドを含まないフォールバックDCIを利用することができる。そのような事例において、たとえWTRUがCBGに基づく(再)送信向けに構成されている場合であっても、フォールバックDCIは、WTRUがTBに基づく単一ビットHARQフィードバックによって応答することの明示的な指標として機能することができる。そのようなシナリオにおいて、単一のCBGがプリエンプトされているトラフィックによって影響される場合、WTRUは再び、これらのシンボル/ミニスロット内のリソースの復号を優先順位付けするために、構成済みのプリエンプション可能な領域の知識を利用することができる。この事例において、影響されている可能性があるCBGのいずれか(すなわち、少なくとも1つ)が、プリエンプトされているトラフィックに起因して復号されることが不可能である場合、WTRUは、通常のHARQタイムラインを待つ必要があるのとは対照的に、ミニスロットのタイミングにおいて、TBに基づく単一ビットのNACK早期HARQフィードバックを提供することができ、結果として、BS(例えば、gNB)によるTB全体の再送信がより高速になる。上述されているように、フォールバックDCIは、TBに基づく単一ビットHARQフィードバックのサポートを示すためのCBGTIフィールドを含まない場合がある。周期的な(非フォールバック)DCIは、CBGに基づくマルチビットHARQフィードバックのサポートを示すためのCBGTIフィールドを含み得る。
上述されているように、マルチビットHARQフィードバックを用いて構成されているWTRUは、TBに基づく単一ビットHARQフィードバックによって応答することができる。このシナリオにおいて、WTRUが、相当数の早期のCBGがプリエンプトしているトラフィックによって影響されていることに気付いた場合、WTRUは、TBに基づく単一ビットの早期のHARQ−NACFKフィードバックメッセージを介して(特定のCBGとは対照的に)TB全体の再送信を要求するのに最良の(すなわち、最も適切な)フィードバックフォーマットを選択する自律性を有することができる。ミニスロットのHARQタイミングに基づく早期のHARQフィードバックと、通常の(スロットに基づく)HARQタイミングに基づく通常のHARQフィードバックの単一ビットHARQフィードバックフォーマットとマルチビットHARQフィードバックフォーマットとの間で自律的に切り替える柔軟性によって、WTRUは、PUCCHリソースセット/フォーマット/リソースの間で切り替えることができるため、WTRUは、PUCCHリソースを最適に使用することを可能にすることができる。この結果として、様々なPUCCHリソースセット/リソースにわたって均等に分散させることができ(マルチビットHARQフィードバック向けに構成されている全てのWTRUが、フィードバックのミニスロットのHARQタイミングまたはフィードバックのスロットに基づくタイミングのみを排他的に利用する事例とは対照的に)、それによって、PUCCHが衝突する可能性が低減する。
代替的にまたは付加的に、WTRUの早期のHARQフィードバックのための窓は、WTRUに、早期のHARQフィードバックを提供する複数の機会を提供することができる。HARQフィードバックを提供する各機会は、スケジューリングされているPDSCH送信スロット内のいくつかのシンボル/ミニスロット/サブスロット/非スロットの境界のうちの1つの上にあり得る。複数の早期のHARQフィードバックの機会を提供することによって、結果として再送信遅延を低減する最適なHARQ性能を可能にすることができる。早期のHARQフィードバックの機会は、累積的なHARQ−NACKフィードバックを提供するために利用され得る。それらは、PDSCH送信の開始から現在の/最近復号されたCBG結果までの、全てのCBGに対するHARQ−NACKフィードバックを示すことができ、それによって、CBGあたり複数の可能なHARQ−NACKを提供する。代替的にまたは付加的に、早期のHARQフィードバックの機会は、最後の早期のHARQフィードバックのミニスロット境界と、現在のHARQフィードバックのミニスロット境界との間のCBGに対するHARQ−NACKフィードバックを提供するために利用され得、これは、CBGあたり単一のHARQ−NACKフィードバックを暗示する。第1の(累積的な早期のフィードバックの)オプションは、オーバーヘッドが増大されることと引き換えに、より高い信頼性を提供することが可能であり得る。例えば、TBあたり8つのCBGを用いて構成されているWTRUは、2回の早期のHARQ−NACKの機会を有することができる。第1の機会は、最初の2つのCBGの復号結果に基づき得、第2の機会は、最初の5つのCBGの復号結果に基づき得る。最初の2つのCBGのうちの1つがプリエンプションに起因して破損される場合、WTRUは、第2のHARQフィードバックのミニスロット境界にある破損されているCBGのNACKを示すマルチビット(例えば、8ビット)HARQフィードバックメッセージによって応答することができる。WTRUが、第1のHARQKフィードバックのミニスロット境界と第2のHARQフィードバックのミニスロット境界との間で、追加の2つのCBG(3つのCBGのうちの)が破損されていると認識した場合、WTRUは、5つのCBGのうち3つの破損されているCBGのNACKを示す別のマルチビットHARQフィードバックメッセージによって応答することができる。2つのHARQフィードバックメッセージが、破損されているCBGに対して有効かつ累積的に提供されているため、この累積的な早期のフィードバックは、最初の2つのCBGの信頼性を改善することができる。これは、結果として再送信遅延が増大されることになり得るNACK−ACKの誤り、または、結果として不要な再送信をもたらし得るACK−NACKの誤りの可能性を低減することができる。
加えて、早期のHARQフィードバックレポートをBS(例えば、gNB)に送信することができるWTRUは、スロットに基づくHARQフィードバックのレポートの送信が、再送信がすでに要求されているために不要であると考えられ得るときには、これを控えることができる。これは、WTRUが早期のHARQフィードバックを利用する複数の機会を有しており、実際に、特定のCBGおよび/またはTB全体の再送信を要求するためにこれらの機会を利用している事例に特に関連し得る。通常のHARQフィードバック応答を控えることは、複数のWTRUの間で、早期のHARQと通常のスロットに基づくHARQの両方のフィードバックを提供するために利用されるPUCCHリソースのセット(例えば、リソースブロック)の重なりがある場合に、特に関連し得る。これは、PUCCHリソースの不要な使用の可能性および異なるWTRUの間の可能性のある衝突を低減するのを助けることができる。
加えて、早期のHARQフィードバックが利用されようとしているために、通常のHARQフィードバックが必要ないことをWTRUが知っている場合、それは、PUCCHリソース/PUCCH送信持続時間に関する可能性のある制約およびWTRU間の衝突の可能性、並びに、信頼できるPUCCH性能を保証するために必要とされ得るPUCCHリソースの全体的な数を低減することができる。
図10は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、ミニスロットのタイミングによるスロット内の例示的な早期のHARQフィードバックのタイミング1000を示す。図10に示されているように、TB(またはスロット)1001は、低遅延トラフィックのためのCBG2 1020、CBG4 1030、およびCBGn−1 1034を含むプリエンプション領域1005を有して構成され得る。プリエンプション領域1001内のCBGの間で、CBG2 1020およびCBG4 1030のいくつかの部分1010は、低遅延トラフィックに対応するためにプリエンプトされ(すなわち、低遅延トラフィックによってプリエンプトされ)得る。WTRUは、複数の(この事例においては2回の)早期のHARQフィードバックの機会(すなわち、早期のHARQ1 1040および早期のHARQ2 1045)を有する。第1の早期のHARQの機会(すなわち、早期のHARQ1 1040)について、WTRUが、第1の2つのCBG(すなわち、CBG1 1015およびCBG2 1020)のいずれかがプリエンプトしている低遅延トラフィックによって影響されているか否かを決定した後、WTRUは、早期のHARQ−NACK応答を、早期のHARQ1ミニスロットタイミング1040において送信すべきか否かを決定することができる。第2の早期のHARQの機会(すなわち、早期のHARQ2 1045)について、WTRUが、第2の2つのCBG(すなわち、CBG3 1025およびCBG4 1030)のいずれかがプリエンプトしている低遅延トラフィックによって影響されているか否か、または、累積的なCBG(すなわち、CBG1 1015、CBG2 1020、CBG3 1025、およびCBG4 1030)のいずれかがプリエンプトしている低遅延トラフィックによって影響されているか否かを決定した後、WTRUは、その後、上述されているように、CBG3およびCBG4 1025、1030に対してのみ、または、CBG1〜4 1015、1020、1025、1030(累積的)に対して、早期のHARQ2ミニスロットタイミング1045において、早期のHARQ−NACK応答を提供すべきかを判断することができる。WTRUが、早期のHARQ1ミニスロットタイミング1040または早期のHARQ2ミニスロットタイミング1045のいずれにおいても早期のHARQフィードバックを送信しないことを選択した場合、WTRUは、全てのCBG(すなわち、CBG1 1015、CBG2 1020、CBG3 1025、CBG4 1030...CBGn−1 1034、およびCBGn 1035)について、通常のHARQタイミング1050において通常のHARQフィードバック1050を送信することができる。
図11は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、ミニスロットのタイミングによるスロット内での早期のHARQフィードバックを決定するための例示的な手順1100を示す。図11に示されているように、WTRUは、スロット内のプリエンプション領域リソースの優先順位付けされている復号に基づいて、早期のHARQ NACKフィードバックを提供すべきか否かを決定することができる。例えば、ステップ1105において、WTRUは、上述されているように、低遅延トラフィックのためのプリエンプション領域を用いて構成され得る。ステップ1110において、WTRUは、スロット内でプリエンプション領域内のリソースの復号を優先順位付けすることができる。ステップ1115において、WTRUは、各ミニスロットについて低遅延トラフィックによって影響される可能性があるCBGを識別することができる。ステップ1120において、WTRUは、識別されているCBG内の影響されている可能性があるCBを復号するように試行することができる。ステップ1125において、識別されているCBG内のCBの数が予め定められた閾値よりも大きい場合、WTRUは、ステップ1130において、各ミニスロットについて、失敗した(または破損されている)CBを含むCBGをさらに識別することができる。WTRUはその後、ステップ1135において、ミニスロットに基づくHARQタイミングに従って、スロット内で早期のHARQフィードバックを生成することができる。一方、ステップ1125において、識別されているCBG内のCBの数が予め定められた閾値よりも小さい場合、WTRUは、ステップ1140において、スロットに基づくHARQタイミングに従って通常のHARQフィードバックを生成することができる。予め定められた閾値は、BSからのブロードキャストメッセージまたはRRCメッセージを介して受信され得る。予め定められた閾値はまた、WTRUのメモリ内で予め構成されてもよい。
一実施形態において、早期のHARQフィードバックは、eMBBデータが低遅延データによってプリエンプトされるときに、再送信遅延を低減するために使用される。WTRUが、プリエンプション領域内のCBGの過度に多いCBを復号するのに失敗するとき、早期のHARQフィードバックは、ミニスロットHARQタイミングに従って送信され得る。例えば、WTRUは最初に、構成済みプリエンプションリソースにおけるPDSCH送信の1つまたは複数のCBG(すなわち、プリエンプション可能なCBG)内のCBの復号を優先順位付けすることができ、ここで、CBGはCBのセットを含むことができる。WTRUは、その後、PDSCHトランスポートブロック(TB)の送信において1つまたは複数のプリエンプション可能なCBGを決定することができる。決定されている1つまたは複数のプリエンプション可能なCBGのうちのプリエンプション可能なCBGについて、WTRUは、対応するCBのうちの1つまたは複数を受信し、これを復号するように試行することができる。WTRUは、復号が失敗されたプリエンプション可能なCBG内のCBの数を決定することができる。WTRUは、プリエンプション可能なCBG内の失敗したCBの数が予め定められた閾値を超えるときに、ミニスロットのHARQタイミングに基づいて早期のHARQフィードバックを送信することができる。代替的にまたは付加的に、WTRUは、スロット内のプリエンプション可能なCBGの各々のうちの失敗したCBの数が予め定められた閾値以下であるときに、スロットに基づくHARQタイミングに基づいて周期的なHARQフィードバックを送信することができる。
別の実施形態において、指定されているプリエンプション領域に関する情報を用いてWTRUを(例えば、RRCシグナリングを介して)半静的に構成することに加えて、BS(例えば、gNB)は、動的なシグナリングを介して、影響される時間/周波数リソースの位置を明示的に示すことができる。WTRUが、影響されるCB/CBG/TBの復号を助けるために利用することができるように、これは、WTRUに、影響される時間または周波数リソースの明示的な位置を提供することができる。例えば、黙示的な指標の事例と同様に、WTRUは、最初に、示されている/影響されているPRB内のCBを復号するように試行することができる。WTRUはその後、この復号の結果に基づいて、HARQフィードバックを送ることができ、早期の再送信が可能になる。この明示的な指標は、より大きいシグナリングオーバーヘッドを有し得るが、黙示的な指標の事例からの差異は、影響されるリソースに関するより正確な情報が提供されることである。
BS(例えば、gNB)は、WTRUまたはWTRUのグループに、WTRUが早期のHARQフィードバックメッセージを送るための、追加のタイミングおよび/またはリソース位置情報を動的に提供することができる。この情報は、プリエンプション指標シグナリングの一部として提供され得る。WTRUは、影響されるリソースの位置(時間および/または周波数的な)に基づいて早期のHARQフィードバックメッセージを送ることを選択することができる。例えば、プリエンプトされているリソースの位置は、最初の数シンボルのうちの1つのような、スケジューリングされているスロット内の早期に生じ得る。WTRUは、低遅延トラフィックに対応するために利用される可能性が高い周波数リソースの位置に関する情報を有することができる。そのようなシナリオにおいて、WTRUは、これらのシンボルにおける周波数リソースの復号結果に基づいて、早期のHARQフィードバックを提供することができる。代替的にまたは付加的に、WTRUは、プリエンプトされているリソースの位置が、WTRU処理時間に適切でない制約を課す場合、例えば、プリエンプションが、スケジューリングスロットの端部に向かうところにあるシンボル/シンボルのグループに影響を与える場合、早期のHARQフィードバックメッセージを提供しないと判断することができる。
別の実施形態において、WTRUは、早期のHARQフィードバックを提供する目的で特定的に利用されることになるPUCCHリソースのセットを用いて半静的に予め構成され得る。PUCCHリソースのセットは、通常の(スロットに基づく)HARQフィードバック向けに予め構成されているリソースセットに共通のリソースを含むことができる。代替的にまたは付加的に、これらのリソースは、通常のスロットに基づくHARQタイミングに基づく通常のHARQフィードバックに利用される他のPUCCHリソースセットとは別個のものであってもよい。
選択されているPUCCHフォーマットが、適度なUCI(HARQ)ペイロードを含むことができ、複数の/いくつかのシンボル/ミニスロット/サブスロットにわたって送信される場合(例えば、単一のリソース−ブロック対にわたる長い持続時間(PUCCHフォーマット4)にわたるPUCCH)、PUCCHリソースセットを効率的に活用するために、複数のWTRUが同じリソース−ブロック対を共有することができる。シンボル/ミニスロット内で同じリソース−ブロック対を共有するデバイスは、周波数領域シーケンスの異なる直交位相回転(例えば、時間領域におけるサイクリックシフト)によって分離され得る。代替的にまたは付加的に、複数のリソース−ブロック対が使用される、より大きい(例えば、2ビットよりも大きい)UCIペイロードフォーマット(例えば、PUCCHフォーマット2または3)について、シンボル/ミニスロット/非スロットの多重化容量は、複数のWTRUに同じリソース−ブロック対を共有させることによって増大され得、ここで、各WTRUは、異なる直交カバーシーケンスを使用し、それによって、早期のHARQフィードバックに必要とされ得るPUCCHリソースの数が低減する。
積極的なHARQ処理が可能な高機能WTRUの数は、サービスされる全WTRUのうちの小さい比であり得るため、これらのリソースは制限され得、場合によって、WTRUまたは高機能WTRUのグループの間で共有され得る。BS(例えば、gNB)は、いずれの割合のWTRUが高機能WTRUであるかを決定するために、WTRUから受信されたHARQフィードバックデータを利用することができる。BSはまた、いずれの比のこれらのWTRUが実際に早期のHARQ−NACKフィードバックを送信しているかを決定することもできる。BS(例えば、gNB)はその後、リソース使用を最適化するために、PUCCHリソースセットを半静的に再構成するために、このデータを利用することができる。
早期のHARQフィードバックは、単一ビットまたはマルチビットのHARQフィードバック(上述されているような)であり得るため、WTRUは、BS(例えば、gNB)に早期のHARQフィードバックを提供するために、2つ以上のPUCCHリソースセット/フォーマットを半静的に予め構成され得る。これらのPUCCHリソースセットは、ペイロードサイズに基づいて、通常のスロットに基づくHARQペイロードサイズとして区別され得る。
別の実施形態にて、WTRUは、スロットに基づくHARQフィードバックに対して定義されている同じPUCCHリソース(リソースブロック)を利用することができる。
上記の実施形態のいずれかにおいて、WTRUは、早期のHARQフィードバックリソースを提供するために必要とされるリソースが、時間/周波数領域においてスロットに基づくHARQフィードバックを提供するために利用されるリソースと競合する場合があるという事実を考慮に入れる必要があり得る。例えば、早期のHARQがスロット内のシンボル/ミニスロットの特定のセットにわたるリソース(リソースブロック)を利用する場合、これらの送信は重なり合い、それゆえ、スロットに基づくHARQフィードバックの送信窓に影響する場合がある。代替的にまたは付加的に、高機能WTRU(例えば、早期のHARQフィードバックが可能)およびベースライン機能WTRU(すなわち、通常のHARQフィードバックのみが可能)に対応する必要があることによって、PUCCH使用を制限するために、様々なWTRUの間でPUCCHリソースを共有する必要があり得る。しかしながら、これによって、WTRU間の衝突の可能性が増大し得る。
衝突の可能性を回避する単純な方法は、早期のHARQフィードバックが送信されていることを受けて、通常のHARQ送信を控えることである。上記で開示されているように、これは、全体的な再送信の信頼性を損なうことなく、また、異なるWTRUのPUCCH送信の間で衝突する可能性なしに、早期のHARQフィードバックに対する任意の制約を低減することができる。
WTRUは、高信頼性用途に関連する早期のHARQフィードバックと通常のHARQフィードバックの両方を送信する必要があり得る。早期のHARQ(ミニスロットタイミングに基づく)フィードバックが通常のHARQフィードバックに影響しないことを保証するために、WTRUは、早期のHARQフィードバックを短い持続時間のPUCCH送信に制限することができ、それによって、スロットに基づくHARQフィードバックの送信窓の前に、早期のHARQフィードバック送信が終了することを保証する。短い持続時間のPUCCH送信を利用することは、任意の所与の時点において、システム内の全WTRUのうちの小さい割合のみが制限された電力または制限されたカバレッジを有し、ほとんどのWTRUは長い持続時間のPUCCH送信を必要としないと仮定され得るため、それが、HARQフィードバックの信頼性に悪影響を与え得ないという点において、許容可能であり得る。
別の実施形態において、WTRUは、スロット内の利用可能な早期のHARQフィードバックの送信機会の数に関して制約され得る。例えば、図10において、2回の早期のHARQフィードバックの送信機会(早期のHARQ1 1040および早期のHARQ2 1045)の代わりに、WTRUは、単一の早期のHARQフィードバック機会(すなわち、早期のHARQ1 1040)に制限され得る。この制約は、HARQフィードバックに対して短いまたは長いPUCCH送信が構成/利用されるかに基づき得る。例えば、WTRUが、HARQフィードバックに対して長い持続時間のPUCCH送信を利用する必要がある場合、それは、早期のHARQ1 1040が早期のHARQフィードバックの唯一の機会を提供すると決定することができる。他方、WTRUが、短い持続時間のPUCCH送信を利用する必要がある場合、いずれも通常の(スロットに基づく)HARQ送信1050と干渉し得ないため、それは、両方のHARQフィードバック機会(すなわち、早期のHARQ1 1040および早期のHARQ2 1045)を提供するのに満足なものであり得る。
別の実施形態において、WTRUは、異なるアンテナ上で異なるリソース(時間および周波数リソースに加えて、コード領域も利用する)を使用することによって、空間的に直行するリソース送信ダイバーシティ(例えば、LTEにおける)と同様である送信ダイバーシティを利用することができる。これは、異なるアンテナからのPUCCH送信が、基本的に、(PUCCHリソースの量が2倍になることと引き換えに)2つの異なるWTRUからの2つのPUCCH送信に見えることを可能にすることができる。これは、早期および通常のHARQフィードバックに対して同じPUCCHリソースを使用する代わりに、WTRUが、2つのHARQフィードバック送信を分離するために、コード領域(例えば、各アンテナ上で異なるコード)を利用することができることを意味する。これは実効的に、早期のHARQフィードバックと通常のHARQフィードバックの両方の送信を可能にすることができる。
別の実施形態において、低遅延トラフィック(例えば、URLLC)がeMBB WTRUリソースをプリエンプトする場合、BS(例えば、gNB)は、プリエンプトされているリソースの明示的な指標を送るのに加えて、たとえそれがWTRUからHARQフィードバックを受信する前であっても、影響されるCB/CBGを自動的に再送信する(またはその後続の送信を実施する)と判断することができる。後続の送信の存在は、1ビットのフラグを介してWTRUまたは影響されるWTRUのセットに示され得、明示的な指標の信号とともにWTRUに送られ得る。
初期送信が失敗した場合に影響されるCBを復号するためにWTRUが使用することができるフォローアップ送信を知っているため、WTRUはその後、いかなるHARQフィードバックも提供しないことによって、このフラグを使用することができる。そのようなメカニズムは、追加の送信リソースを使用することと引き換えに、遅延を改善しながらシグナリングオーバーヘッドを低減するという二重の利益を有することができる。
別の実施形態において、WTRUが、元々スケジューリングされているリソースがプリエンプトされているか否かに関する情報を有しない可能性がある。これは以下の場合に当てはまり得る。(i)予め定められたプリエンプション可能な領域に関する、半静的に構成されている情報がない。(ii)ダウンリンク制御情報(DCI)を介して受信されるプリエンプションリソースの動的な指標が、ACK/NACKフィードバックの前に到達することに失敗する。または、(iii)開始するためのプリエンプトされているリソースの明示的な指標がない。そのような事例において、WTRUは、先行するスロット/ミニスロット内で送信されるように元々スケジューリングされていたTBの任意のCB/CBGが、ここで、後続の送信としてスケジューリングされているか否かを確認するために、後続のスケジューリング割り当て(例えば、後続のスロット)をモニタリングすることができる。
BS(例えば、gNB)は、WTRUに、低遅延トラフィックをプリエンプトすることによって影響されるリソース、および、従ってCB/CBGを通知するために、プリエンプション指標を送信することができる。このプリエンプション指標および結果としての再送信は、影響されるCBGをハンドリングし、TBを復号する方法を決定するときに、WTRUを助けることができる。
一実施形態において、WTRUは、全ての影響されているCBGまたは影響されているCBGのサブセットに関係付けられるソフトバッファ内容をフラッシュし、これらの影響されているCBGの再送信を復号に利用すると判断することができる。CBGの全ての関係付けられる内容をフラッシュアウトするこの手法は、影響されているCBG内の相当数のCBがプリエンプションに起因して破損されている場合に特に有益であり得る。この事例において、信頼性を著しく欠く初期送信とは対照的に、将来の再送信にわたるHARQ合成を利用することが最良であり得る。
別の実施形態において、WTRUは、CBG全体とは対照的に、CBGの影響されているセット内のCBのサブセットに関係付けられるソフトバッファ内容をフラッシュすると判断することができる。そのようなシナリオ下では、WTRUは、復号成功を改善するための手段として、再送信が初期送信と同じ増分冗長(IR)に基づく場合にはチェース合成を利用することができ、または、フラッシュされなかったソフトバッファ内のCBの再送信に異なる冗長バージョン(RV)が利用される場合には増分冗長HARQを利用することができる。WTRUは、CBG内のいずれのCBがフラッシュされる必要があるかを判断するための方法として、CBレベルのCRC検査を利用することができる。この手法は、CBG内の少数のCBがプリエンプションに起因して破損されている場合に特に有益であり得る。
CBGに基づく送信のタイミングは、WTRUのHARQフィードバックに影響し得る。BS(例えば、gNB)は、プリエンプトされている低遅延トラフィックによって影響されているTBのCBGに基づく再送信をスケジューリングすることができる。このBS(例えば、gNB)は、この再送信を、積極的に(すなわち、WTRUからHARQフィードバックを受信する前に)、または、WTRUによって提供される結果としてのHARQ ACK−NACKフィードバックに基づいて開始することができる。
一実施形態において、BS(例えば、gNB)は、プリエンプションによって影響されているCBGを、積極的に、例えば、WTRUからの結果としてのHARQ応答を待つことなく再送信すると判断することができる。これは、影響されているリソース、および、従って、影響されているCBGの数などに基づく何らかの推定される復号失敗の確率に基づいて行われてもよい。積極的なまたは後続の送信の事例において、BS(例えば、gNB)は、WTRUが利用する必要があるHARQフィードバックのためのタイミングおよびリソースをWTRUに示すことができる。
そのようなシナリオの下で、WTRUは、2つの別個のHARQフィードバックメッセージによって応答すると判断することができる。第1のHARQメッセージは、元々のPDSCH(TB)送信タイミングに基づき得、第2のHARQメッセージは、後続の送信によって提供される新たな/更新されたリソース/タイミング情報に基づき得る。WTRUは、初期送信と、第2のHARQメッセージのための後続の送信とのHARQ合成を利用することができる。代替的にまたは付加的に、2つのHARQメッセージは、フィードバックフォーマットの粒度(例えばマルチビット対単一ビット)などに関して異なり得る。例えば、プリエンプションを伴う初期送信の結果として、いくつかのCBGが不正確に復号される場合、WTRUは、いずれのCBGが再送信される必要があるかをBS(例えば、gNB)に通知するために、CBGに基づくマルチビットHARQフィードバックを提供することができる。初期送信と後続の送信とのHARQ合成が、依然として、誤りのあるいくつかのCBGをもたらすか、または、TB全体が首尾よく復号されるようにする場合、WTRUは、これらの事例のいずれかについて単一ビットHARQフィードバックメッセージを提供すると判断することができる。これは、BS(例えば、gNB)が次の再送信においてTB全体を再送信すべきであることの黙示的な指標として解釈され得る。
代替的にまたは付加的に、初期送信と後続の送信の両方が、結果として、誤りのある少数のCBGをもたらす場合、周波数スペクトル効率の観点から、BS(例えば、gNB)が、結果としてTB全体が再送信されるようにする単一ビットのフィードバックとは対照的に、WTRUによって要求されるCBGを再送信することができるように、BS(例えば、gNB)に、CBGに基づくHARQフィードバックを提供することがより効率的であり得る。
各メッセージについて最良のフィードバックオプションを選択するためのWTRUの柔軟性は、スペクトル効率に関して最良の性能を提供しながら、UCIオーバーヘッドを低減するのを助けることができる。代替的にまたは付加的に、2つのHARQフィードバックメッセージを使用する結果としてまた、ACK−NACKメッセージのロバスト性も改善され得る。
異なるPUCCHフォーマットを用いてWTRUを構成することによって、HARQフィードバックオプション間での切り替えが容易にされ得る。BS(例えば、gNB)はその後、フィードバックメッセージの粒度を確認するために、PUCCHをブラインド復号することができる。一実施形態において、WTRUは、BS(例えば、gNB)による後続の再送信手順が、2つの送信のHARQ合成の結果に基づくときに、単一のHARQフィードバック応答によって応答するように構成され得る。これは、明示的または黙示的のいずれかで構成され得る。例えば、BS(例えば、gNB)による後続の送信の指標は、単一のHARQ応答を送るための信号として解釈され得る。WTRUはその後、2つの送信のHARQ合成の結果に基づいて、単一のHARQ応答を送ることができる。応答のタイミングは、WTRUに適切な処理時間を提供するために、新たに示されたタイミング/リソースに基づくことができる。代替的にまたは付加的に、WTRUは、この単一のHARQフィードバック応答のためのフォーマット(例えば、単一ビット対マルチビット)を自律的に判断することができる。例えば、少数のCBGのみに誤りがある場合、CBGに基づくマルチビットHARQフィードバックによって応答することがより良好であり得る。一方、相当数のCBGに誤りがあるままである場合、WTRUは、BS(例えば、gNB)がTB全体を再送信する必要があることを示す、単一ビットのNACKによって応答することができる。単一のHARQフィードバックメッセージによる応答はまた、フィードバックオーバーヘッドの節約をももたらすことができる。例えば、後続の送信の結果として、任意の以前に破損されたCBGが首尾よく受信される場合、単一のHARQメッセージを送るのを待っているWTRUは、この時点でTB全体が受信されていることを知らせる単一ビットのACKを送信することができる。対照的に、2つのHARQフィードバックメッセージによるHARQに基づく再送信または後続の送信に依拠することは、結果として、少なくとも1つのマルチビットHARQメッセージ、および、それに続く、別のマルチビットまたは単一ビットのHARQメッセージをもたらし得る。上記で言及されている手順は、BS(例えば、gNB)がプリエンプション後に複数の後続の送信をスケジューリングする事例に拡張され得る。代替的にまたは付加的に、BS(例えば、gNB)が、WTRUによって提供されるHARQフィードバックに基づいてCBG再送信をスケジューリングした場合、WTRUは、単純に、元々のTB送信と関連付けられるタイミングに従うことができる。
代替的にまたは付加的に、WTRUのHARQ処理機能は、HARQ処理およびフィードバック応答時間に影響し得る。例において、高機能WTRUが元々の送信、および、それに続く、後続の送信を受信する場合、WTRUは、元々の送信に対して、(ミニスロットタイミングに基づく)早期のHARQフィードバックおよび/または(スロットに基づく)通常のHARQフィードバックを利用することができる。WTRUはその後、(元々の送信とのHARQ合成の後)後続の送信に同じことを実施することができる。これは、HARQ信頼性を改善するための方法として利用され得る。
別の実施形態において、WTRUは、初期送信に対して、スロットに基づくHARQ応答によってのみ応答することができ、それに続いて、元々の送信とのHARQ合成後の後続の送信に対して、(ミニスロットに基づく)早期のHARQフィードバックおよび/または(スロットに基づく)通常のHARQフィードバックの組み合わせによって応答することができる。
別の実施形態において、WTRUは、初期送信に対してHARQ応答を送るのを控え、HARQフィードバック応答を送る前に、後続の再送信を待つことができる。結果としてのHARQフィードバック応答は、初期送信と、後続の送信とのHARQ合成に基づくことができ、早期のHARQフィードバックおよび/または通常のHARQフィードバックを含むことができる。
上記の例における後続の送信の送信中に生成される早期のHARQフィードバックは、初期送信(すでに受信されている)のHARQ合成結果に基づくことができ、ここで、CBGは後続の送信の初期シンボル/ミニスロット内で受信される。図10において、2つの連続する(TB/スロット1001)送信(TB/スロットの第2の送信は図10には示されていない)を考慮すると、早期のHARQミニスロットタイミングの機会は、第2のスロットの(後続の送信)のシンボル/ミニスロット/非スロット内で生じ得る。この事例について、WTRUは、後続の送信がBS(例えば、gNB)によってスケジューリングされ得るか否かの決定において、プリエンプション指標(グループ共通のPDCCHを介した)およびCGBフラッシュアウト指標(CBGFI)情報を利用することができる。これは、HARQ応答によって応答する前にこの後続の送信の受信を待つ代わりに、初期送信に基づいてHARQフィードバック応答をスキップすることを正当化することができる。
初期および/または後続の送信に対する早期および/または通常のHARQフィードバック応答の粒度(例えば、単一ビット対マルチビット)およびフォーマットは、上述されている手順に従うことができる。
特徴および要素が特定の組み合わせにおいて上述されているが、各特徴および要素は単独で、または他の特徴および要素との任意の組み合わせにおいて使用されることができることを、当業者には諒解されよう。本明細書に記載の方法は、コンピュータまたはプロセッサによる実行のために、コンピュータ可読媒体内に組み込まれるコンピュータプログラム、ソフトウェア、またはファームウェア内で実施されることができる。コンピュータ可読媒体の例は、電子信号(有線または無線接続にわたって送信される)およびコンピュータ可読記憶媒体を含むことができる。コンピュータ可読記憶媒体の例は、限定ではないが、ROM、RAM、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクおよび取り外し可能ディスクなどの磁気媒体、磁気光媒体、並びにCD−ROMディスクおよびDVDなどの光媒体を含む。ソフトウェアに関連するプロセッサは、WTRU、UE、端末、基地局、RNC、または任意のホストコンピュータにおいて使用するための無線周波数送受信機を実施するために使用されることができる。