特表 2024-507056 単一の送信／受信ポイント（ＴＲＰ）または複数のＴＲＰへの物理アップリンク共有チャネル（ＰＵＳＣＨ）送信の動的インジケーション

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-02-16

(54)【発明の名称】単一の送信／受信ポイント（ＴＲＰ）または複数のＴＲＰへの物理アップリンク共有チャネル（ＰＵＳＣＨ）送信の動的インジケーション

(51)【国際特許分類】

   H04W 72/1268 20230101AFI20240208BHJP

   H04W 72/232 20230101ALI20240208BHJP

   H04W 72/0457 20230101ALI20240208BHJP

【ＦＩ】

H04W72/1268

H04W72/232

H04W72/0457 110

【審査請求】有

【予備審査請求】有

(21)【出願番号】P 2023541656

(86)(22)【出願日】2022-01-13

(85)【翻訳文提出日】2023-09-07

(86)【国際出願番号】 IB2022050274

(87)【国際公開番号】W WO2022153218

(87)【国際公開日】2022-07-21

(31)【優先権主張番号】63/138,732

(32)【優先日】2021-01-18

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．３ＧＰＰ

２．ＰＹＴＨＯＮ

(71)【出願人】

【識別番号】598036300

【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）

(74)【代理人】

【識別番号】110003281

【氏名又は名称】弁理士法人大塚国際特許事務所

(72)【発明者】

【氏名】ガオ， シウェイ

(72)【発明者】

【氏名】ムルガナタン， シヴァ

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067DD34

5K067EE02

5K067EE10

5K067KK02

(57)【要約】

単一の送信/受信ポイント(TRP)または複数のTRPへの物理アップリンク共有チャネル(PUSCH)送信の動的インジケーションのための方法、システム、および装置が開示される。
一態様によれば、ネットワークノードにおける方法は、物理アップリンク共有チャネル(PUSCH)について第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットを用いて前記WDを設定することと、ダウンリンク制御情報(DCI)を前記WDに送信することによって、前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1および第2のSRSリソースセットの両方、の1つに関連づけられた少なくとも1つのPUSCH送信機会における前記WDによるPUSCH送信をスケジュールすることを含む。
【選択図】図１１

【特許請求の範囲】

【請求項1】

無線機器(WD)(22)と通信するように構成されたネットワークノード(16)であって、前記ネットワークノード(16)は処理回路(68)を有し、前記処理回路(68)は、
第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットを用いて、物理アップリンク共有チャネル(PUSCH)について前記WD(22)を設定し、
ダウンリンク制御情報(DCI)を前記WD(22)に送信することによって、前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1および第2のSRSリソースセットの両方、の1つに関連づけられた少なくとも1つのPUSCH送信機会における前記WD(22)によるPUSCH送信をスケジュールする、ように構成される、ネットワークノード(16)。

【請求項2】

前記DCIは、前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1および前記第2のSRSリソースセットの両方、のいずれが前記PUSCH送信に関連付けられるかを前記WD(22)に示すビットフィールドを有する、請求項1に記載のネットワークノード(16)。

【請求項3】

前記ビットフィールドは少なくとも3つのコードポイントからなり、第1のコードポイントは前記第1のSRSリソースセットを示し、第2のコードポイントは前記第2のSRSリソースセットを示し、第3のコードポイントは前記第1および前記第2のSRSリソースセットの両方を示す、請求項2に記載のネットワークノード(16)。

【請求項4】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2のサウンディング基準信号リソースインジケータ(SRI)フィールドを含む、請求項2に記載のネットワークノード(16)。

【請求項5】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信プリコーディング行列インジケータ(TPMI)フィールドを含む、請求項2から4のいずれか1項に記載のネットワークノード(16)。

【請求項6】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信電力制御(TPC)コマンドフィールドを含む、請求項2から5のいずれか1項に記載のネットワークノード(16)。

【請求項7】

前記第1のSRSリソースセットに関連づけられた前記WD(22)による前記PUSCH送信が、第1のSRSリソースインジケータ(SRI)、第1の送信プリコーディング行列インジケータ(TPMI)、および第1の送信電力制御(TPC)コマンドに従って前記PUSCHを送信することを含む、請求項1から6のいずれか1項に記載のネットワークノード(16)。

【請求項8】

前記第2のSRSリソースセットに関連づけられた前記WD(22)による前記PUSCH送信が、第2のSRSリソースインジケータ(SRI)、第2の送信プリコーディング行列インジケータ(TPMI)、および第2の送信電力制御(TPC)コマンドに従って前記PUSCHを送信することを含む、請求項1から6のいずれか1項に記載のネットワークノード(16)。

【請求項9】

無線機器(WD)(22)と通信するように構成されたネットワークノード(16)において実行される方法であって、
第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットを用いて、物理アップリンク共有チャネル(PUSCH)について前記WD(22)を設定すること(S140)と、
ダウンリンク制御情報(DCI)を前記WD(22)に送信することによって、前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1および第2のSRSリソースセットの両方、の1つに関連づけられた少なくとも1つのPUSCH送信機会における前記WD(22)によるPUSCH送信をスケジュールすること(S142)と、を有する、方法。

【請求項10】

前記DCIは、前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1および前記第2のSRSリソースセットの両方、のいずれが前記PUSCH送信に関連付けられるかを前記WD(22)に示すビットフィールドを有する、請求項9に記載の方法。

【請求項11】

前記ビットフィールドは少なくとも3つのコードポイントからなり、第1のコードポイントは前記第1のSRSリソースセットを示し、第2のコードポイントは前記第2のSRSリソースセットを示し、第3のコードポイントは前記第1および前記第2のSRSリソースセットの両方を示す、請求項10に記載の方法。

【請求項12】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2のサウンディング基準信号リソースインジケータ(SRI)フィールドを含む、請求項10に記載の方法。

【請求項13】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信プリコーディング行列インジケータ(TPMI)フィールドを含む、請求項10から12のいずれか1項に記載の方法。

【請求項14】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信電力制御(TPC)コマンドフィールドを含む、請求項10から13のいずれか1項に記載の方法。

【請求項15】

前記第1のSRSリソースセットに関連づけられた前記WD(22)による前記PUSCH送信が、第1のSRSリソースインジケータ(SRI)、第1の送信プリコーディング行列インジケータ(TPMI)、および第1の送信電力制御(TPC)コマンドに従って前記PUSCHを送信することを含む、請求項9から14のいずれか1項に記載の方法。

【請求項16】

前記第2のSRSリソースセットに関連づけられた前記WD(22)による前記PUSCH送信が、第2のSRSリソースインジケータ(SRI)、第2の送信プリコーディング行列インジケータ(TPMI)、および第2の送信電力制御(TPC)コマンドに従って前記PUSCHを送信することを含む、請求項9から14のいずれか1項に記載の方法。

【請求項17】

1つ以上のネットワークノード(16)と通信するように構成された無線機器(WD)(22)であって、前記WD(22)は無線インタフェース(82)を有し、前記無線インタフェース(82)は、
前記1つ以上のネットワークノード(16)の1つから、物理アップリンク共有チャネル(PUSCH)送信に関連づけられた第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットの設定を受信し、
少なくとも1つのPUSCH送信機会において前記WD(22)によってPUSCHを送信するためのダウンリンク制御情報(DCI)を受信し、ここで前記DCIは、
前記第1のSRSリソースセットと、
前記第2のSRSリソースセットと、
前記第1および前記第2のSRSリソースセットの両方と、
のうちの１つに関連付けられた前記PUSCH送信を示すビットフィールドを有し、
前記少なくとも1つのPUSCH送信機会において、前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1および前記第2のSRSリソースセットの両方、のうち、示された1つに関連付けられた前記PUSCHを送信する、ように構成される、WD(22)。

【請求項18】

前記ビットフィールドの第1のコードポイントが前記第1のSRSリソースセットに関連づけられた前記PUSCH送信を示し、前記ビットフィールドの第2のコードポイントが前記第2のSRSリソースセットに関連づけられた前記PUSCH送信を示し、前記ビットフィールドの第3のコードポイントが前記第1および前記第2のSRSリソースセットの両方に関連づけられた前記PUSCH送信を示す、請求項17に記載のWD(22)。

【請求項19】

前記無線インタフェース(82)が、前記第1および第2のSRSリソースセットの少なくとも1つが示される場合に、第1および第2のサウンディング基準信号リソースインジケータ(SRI)の1つ、第1および第2の送信プリコーディング行列インジケータ(TPMI)の1つ、ならびに第1および第2の送信電力制御(TPC)コマンドの1つに従って、前記少なくとも1つのPUSCH送信機会に前記PUSCHを送信するようにさらに構成される、請求項17に記載のWD(22)。

【請求項20】

前記無線インタフェース(82)が、前記第3のコードポイントによって前記第1および前記第2のSRSリソースセットの両方が示される場合、少なくとも第1の送信機会に第1のサウンディング基準信号リソースインジケータ(SRI)、第1のTPMI、および第1のTPCの1つに従って前記PUSCHを送信し、(1つ以上の)第2の送信機会に第2のSRI、第2のTPMI、および第2のTPCの1つに従って、前記PUSCHを送信するようにさらに構成される、請求項17に記載のWD(22)。

【請求項21】

1つ以上のネットワークノード(16)と通信するように構成された無線機器(WD)(22)における方法であって、
前記1つ以上のネットワークノード(16)の1つから、物理アップリンク共有チャネル(PUSCH)送信に関連づけられた第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットの設定を受信すること(S144)と、
少なくとも1つのPUSCH送信機会において前記WD(22)によってPUSCHを送信するためのダウンリンク制御情報(DCI)を受信すること(S146)と、ここで前記DCIは、
前記第1のSRSリソースセット(S148)と、
前記第2のSRSリソースセット(S150)と、
前記第1および前記第2のSRSリソースセット(S152)の両方と、
のうちの１つに関連付けられた前記PUSCH送信を示すビットフィールドを有し、
前記少なくとも1つのPUSCH送信機会において、前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1および前記第2のSRSリソースセットの両方、のうち、示された1つに関連付けられた前記PUSCHを送信すること(S154)と、を有する、方法。

【請求項22】

前記ビットフィールドの第1のコードポイントが前記第1のSRSリソースセットに関連づけられた前記PUSCH送信を示し、前記ビットフィールドの第2のコードポイントが前記第2のSRSリソースセットに関連づけられた前記PUSCH送信を示し、前記ビットフィールドの第3のコードポイントが前記第1および前記第2のSRSリソースセットの両方に関連づけられた前記PUSCH送信を示す、請求項21に記載の方法。

【請求項23】

前記第1および第2のSRSリソースセットの少なくとも1つが示される場合に、第1および第2のサウンディング基準信号リソースインジケータ(SRI)の1つ、第1および第2の送信プリコーディング行列インジケータ(TPMI)の1つ、ならびに第1および第2の送信電力制御(TPC)コマンドの1つに従って、前記少なくとも1つのPUSCH送信機会に前記PUSCHを送信すること、をさらに有する、請求項21に記載の方法。

【請求項24】

前記第3のコードポイントによって前記第1および前記第2のSRSリソースセットの両方が示される場合、少なくとも第1の送信機会に第1のサウンディング基準信号リソースインジケータ(SRI)、第1のTPMI、および第1のTPCの1つに従って前記PUSCHを送信することと、(1つ以上の)第2の送信機会に第2のSRI、第2のTPMI、および第2のTPCの1つに従って、前記PUSCHを送信することと、をさらに有する、請求項21に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は無線通信に関し、特には単一の送信/受信ポイント(TRP)または複数のTRPへの物理アップリンク共有チャネル(PUSCH)送信の動的インジケーションに関する。

【背景技術】

【0002】

第3世代パートナーシッププロジェクト(3GPP)は第4世代(4G)(ロングタームエボリューション(LTE)とも呼ばれる)および第5世代(5G)(ニューラジオ(NR)とも呼ばれる)無線通信システムのための規格を開発し、また発展させている。
そのようなシステムは、特に、ネットワークノード間やモバイル無線機器(WD)間だけでなく、通信基地局などのネットワークノードとWDとの間でのブロードバンド通信を提供する。

【0003】

NRフレーム構造およびリソースグリッド
NRは、ダウンリンク(DL)(すなわち、gNBまたは基地局などのネットワークノードから無線機器またはWDへ)およびアップリンク(UL)(すなわち、WDからネットワークノードへ)の両方において、サイクリックプレフィックス直交周波数分割多重化(CP-OFDM)を用いる。離散フーリエ変換(DFT)拡散OFDMもアップリンクでサポートされる。時間領域において、NRダウンリンクおよびアップリンクは各1msの等サイズのサブフレームに編成される。サブフレームは、持続時間が等しい複数のスロットにさらに分割される。スロット長は、サブキャリア間隔に依存する。Δf=15KHzのサブキャリア間隔の場合、サブフレームあたり1スロットのみが存在し、各スロットは14OFDMシンボルからなる。

【0004】

NRにおけるデータスケジューリングは、通常、スロットベースである。図1は14シンボルスロットの一例の図であり、最初の2シンボルが物理ダウンリンク制御チャネル(PDCCH)通信を格納し、残りのシンボルが物理共有データチャネル、物理ダウンリンク共有チャネル(PDSCH)、または物理アップリンク共有チャネル(PUSCH)のいずれかを格納する。

【0005】

NRでは、異なったサブキャリア間隔値をサポートする。サポートされるサブキャリア間隔値(異なるヌメロロジとも呼ばれる)は、Δf = (15×2^μ) KHz、μ ∈ {0, 1, 2, 3, 4}で与えられ、Δf = 15KHzは基本サブキャリア間隔である。異なるサブキャリア間隔でのスロット持続時間は、1/ (2^μ) msで与えられる。

【0006】

周波数領域において、システム帯域幅は、それぞれが12の連続するサブキャリアに対応する、複数のリソースブロック(RB)に分割される。RBは、システム帯域幅の一端から、0で始まる番号が付与される。基本NR物理時間-周波数リソースグリッドを図2に示す。ここでは14シンボルスロット内の1つのリソースブロック(RB)のみを示している。1つのOFDMシンボル間隔中の1つのOFDMサブキャリアは、1つのリソース要素(RE)を形成する。

【0007】

3GPP NR Technical Release 15(3GPP Rel-15)では、物理ダウンリンク制御チャネル(PDCCH)で搬送されるダウンリンク制御情報(DCI)に含まれるアップリンクグラントによって、アップリンク(UL)データ送信を動的にスケジュールすることができる。WDはまずアップリンクグラントを復号し、次いで、アップリンクグラント中の復号された制御情報に基づいてPUSCHを送信する。

【0008】

動的スケジューリングに加えて、NRは、設定されたグラント(CG)を用いたPUSCH送信もサポートする。CGには、NRで定義されるタイプ1とタイプ2の2タイプがある。CGタイプ1では、PUSCH送信の開始と停止だけでなく、周期性もRRCによって半静的に設定される。CGタイプ2では、周期性はRRCによって設定されるが、rPUSCH送信の開始と停止はDCIによって動的にシグナリング(通知)される。

【0009】

NRでは、DCIフォーマット0_0、DCIフォーマット0_1、およびDCIフォーマット0_2の3つのUL DCIフォーマットがサポートされる。各DCIはいくつかのビットフィールドを含み、各ビットフィールドは、以下の1つ以上を含む情報を搬送する。
・ サウンディングリソースインジケータ(SRI)、
・ プリコーディング情報およびレイヤ数、および/または
・ スケジュールされたPUSCHに対するTCP(送信電力制御)コマンド。

【0010】

サウンディングリソースインジケータ(SRI)は、サウンディング基準信号(SRS)リソースまたはPUSCHに関連付けられたリソースを示すために使用される。「プリコーディング情報およびレイヤ数」は、送信プリコーディング行列インジケータ(TPMI)およびPUSCHについてのランクを示すために使用される。送信電力制御コマンド(TPC)は、PUSCHの閉ループ電力補正を示すために使用される。

【0011】

3GPP NR Rel-15では、スロットベースのPUSCH繰り返し(またはPUSCH繰り返しタイプA)がサポートされ、RRCで、動的にスケジュールされるグラントタイプ2と、設定されるグラントタイプ2の両方についての集約(アグリゲーション)スロット数がRRCで設定される。3GPP NR Rel-16では、繰り返し回数を動的に示すことができるように、すなわち、あるPUSCHスケジューリング機会から次のPUSCHスケジューリング機会に変更できるように強化された。すなわち、開始シンボルS、およびPUSCHの長さLに加えて、いくつかの公称繰り返しKが、時間領域リソース割り当て(TDRA)の一部として通知される。

【0012】

PUSCH繰り返しタイプBは、PUSCHを複数のミニスロットで繰り返すことができる3GPP NR Rel-16で導入される。PUSCH繰り返しタイプBで送信をスケジューリングする場合、開始シンボルS、およびPUSCHの長さLに加えて、いくつかの公称繰り返しKが、時間領域リソース割り当て(TDRA)の一部として通知される。

【0013】

PUSCH送信方式
NRでは、2つのPUSCH送信方式、すなわち、コードブックベース方式と非コードブックベース方式とがある。

【0014】

コードブックベースのPUSCH方式
上位レイヤパラメータtxConfig =コードブックの場合、コードブックベースのPUSCHが有効になる。動的にスケジュールされたPUSCHおよび設定されたグラントPUSCHタイプ2について、コードブックベースのPUSCH送信方式は、以下のように要約することができる。
・ PUSCHは、上位レイヤパラメータ使用方法が「CodeBook」に設定されたSRSリソースセット内の1つまたは2つのSRSリソースの1つに関連付けられる。使用方法を「コードブック」に設定することができるSRSリソースセットは１つのみであることに留意されたい。
・ ネットワークノード、例えば、gNBは、SRSリソースセットに設定された1つまたは2つのSRSリソースのうち、選択されたUL SRS(サウンディング基準信号)リソースに基づいて、ランクと、コードブック内の好ましいULプリコーダとを決定する。
・ ネットワークノード、たとえば、gNBは、PUSCHをスケジューリングするDCIの1ビットSRIフィールドを用い、選択されたSRSリソースを示す。SRSリソースセットに設定されたSRSリソースが1つだけの場合、SRIフィールドはDCIに存在しない。
・ ネットワークノード、例えば、gNBはまた、DCIの「プリコーディング情報およびレイヤ数」フィールドを用いて、ランクおよび好ましいULプリコーダを示す。
・ WDは、示されたTPMIと、示されたSRSリソースに関連づけられた自身のアンテナポートのランクとを用いて、PUSCH送信を実行する。PUSCHは、示されたSRSリソースにおける最新のSRS送信と空間的に関連する。
3GPP NR Rel-15では、使用方法を「コードブック」に設定することができるSRSリソースセットは１つのみである。

【0015】

非コードブックベースのPUSCH方式
WDで設定されたDLチャネル状態情報参照信号（CSI-RS）に基づいてSRSプリコーディングが導出される相互性ベースのPUSCH伝送を可能にするため、非コードブックベースのUL伝送がサポートされる。WDはSRS送信のためにプリコーダを適用し、その結果、各々が空間レイヤに対応する1つ以上の(仮想)SRSポートが得られるものとする。WDは1つのSRSリソースセットで最大4つのSRSリソースを設定でき、それぞれが1つの（仮想）SRSポートを有する。WDは最大4つのSRSリソースでSRSを送信することができ、gNBは受信したSRSに基づいてULチャネルを測定し、PUSCH送信のための好ましい(1以上の)SRSリソースを決定する。

【0016】

PUSCH送信についてgNBは、選択されたSRSリソースをSRSリソースインジケータ（SRI）によって示し、選択されたSRSリソースは

【数1】

ビットを用いてジョイント符号化される。ここで、N_SRSは設定されたSRSリソースの数を示し、L_MAXはPUSCHについてサポートされるレイヤの最大数を示す。3GPP NR Rel-15では、使用方法を「非コードブック」に設定することができるSRSリソースセットは１つのみであることに留意されたい。

【0017】

PUSCH電力制御
各SRIについて、経路損失基準信号(RS)および電力制御パラメータセット(たとえば、分数電力制御係数(P0)閉ループインデックス)が事前設定され、WDに通知される。PUSCH開ループ送信電力は、PUSCHおよび関連する経路損失RSをスケジューリングするDCIで示されるSRIと、電力制御パラメータセットとに基づいて導出される。

【0018】

閉ループ電力制御は、PUSCHをスケジューリングするDCIの、2ビットの「スケジュールされたPUSCHのためのTPCコマンド」フィールドにで送信電力制御コマンド(TPC)を送信することによって行われる。TPC値と電力補正とのマッピングは、3GPP Technical Standard (3GPP TS) 38.213の7.1.1.節に規定されるように規定されうる。

【0019】

複数のTRPへのUL信号の送信
3GPP NR Rel-16までは、PUSCHが常に、WDによって同一の単一の送信および受信ポイント(TRP)に送信されるものとされている。3GPP NR Rel-17では、単一のDCIによってスケジュールされたPUSCHを2つのTRPに向けて繰り返すことができるPUSCH拡張が導入されることになっている。それをサポートするため、2つのSRSリソースセットを設定可能であり、各SRSリソースセットは、コードブックベースおよび非コードブックベースのPUSCH方式の両方のための2つのTRPの1つに関連付けられる。加えて、WDは、それぞれが2つのTRPの1つに関連付けられる、2つのSRI、2つのTMPI、2つのTPCを示されうる。

【0020】

既存の3GPP NR Rel-15/16 UL DCIフォーマットは、2つのTRPへの送信が既存のシステムにおいてサポートされないことがあるように、単一のTRPに向けてPUSCH送信をスケジュールすることのみ適しているかもしれない。

【発明の概要】

【0021】

いくつかの実施形態は、本開示は無線通信に関し、特には単一の送信/受信ポイント(TRP)または複数のTRPへの物理アップリンク共有チャネル(PUSCH)送信の動的インジケーションのための方法、システム、および装置を有利に提供する。

【0022】

いくつかの実施形態では、新しいTRPインジケータ(TRPI)ビットフィールドが、DCIフォーマット0_1およびDCIフォーマット0_2の1つ以上に導入される。TRPIは、PUSCHが第1のTRPにスケジュールされているか、第2のTRPにスケジュールされているか、またはTRPの両方にスケジュールされているかを示すために用いることができる。

【0023】

たとえば、いくつかの実施形態では、DCIの第1のビットフィールドおよび第2のビットフィールドがそれぞれ第1のTRPおよび第2のTRPに関連付けられる場合、TRPIは第1のフィールド、第2のフィールド、第1のフィールドと第2のフィールドの両方、のいずれが利用可能または有効であるかを示すために用いることができる。具体的には、
・ TRPI = 0:第1のビットフィールドが有効である、
・ TRPI = 1:第2のビットフィールドが有効である、
・ TRPI = 2:第1および第2のビットフィールドの両方が有効である。
いくつかの方法は、同じDCIフォーマットを用いて、単一TRPとマルチTRP PUSCHスケジューリングとの間の動的スイッチングを可能にする。

【0024】

一態様によれば、無線機器(WD)と通信するように構成されたネットワークノードは、物理アップリンク共有チャネル(PUSCH)について第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットを用いて前記WDを設定し、ダウンリンク制御情報(DCI)を前記WDに送信することによって、前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1および第2のSRSリソースセットの両方、の1つに関連づけられた少なくとも1つのPUSCH送信機会における前記WDによるPUSCH送信をスケジュールする、ように構成された処理回路を含む。

【0025】

この態様によれば、いくつかの実施形態において、前記DCIは、前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1のSRSリソースセットと前記第2のSRSリソースセットの両方、のいずれが前記PUSCH送信に関連付けられるかを前記WDに示すビットフィールドを有する。いくつかの実施形態において、前記ビットフィールドは少なくとも3つのコードポイントからなり、第1のコードポイントは前記第1のSRSリソースセットを示し、第2のコードポイントは前記第2のSRSリソースセットを示し、第3のコードポイントは前記第1のSRSリソースセットと前記第2のSRSリソースセットの両方を示す。いくつかの実施形態では、前記PUSCH送信をスケジュールする前記DCIが、第1および第2のサウンディング基準信号リソースインジケータ(SRI)フィールドを含む。いくつかの実施形態では、前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信プリコーディング行列インジケータ(TPMI)フィールドを含む。いくつかの実施形態では、前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信電力制御(TPC)コマンドフィールドを含む。いくつかの実施形態では、前記第1のSRSリソースセットに関連づけられた前記WDによる前記PUSCH送信が、第1のSRSリソースインジケータ(SRI)、第1の送信プリコーディング行列インジケータ(TPMI)、および第1の送信電力制御(TPC)コマンドに従って前記PUSCHを送信することを含む。いくつかの実施形態では、前記第2のSRSリソースセットに関連づけられた前記WDによる前記PUSCH送信が、第2のSRSリソースインジケータ(SRI)、第2の送信プリコーディング行列インジケータ(TPMI)、および第2の送信電力制御(TPC)コマンドに従って前記PUSCHを送信することを含む。

【0026】

一態様によれば、WDと通信するように構成されたネットワークノード16における方法は、第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットを用いて、物理アップリンク共有チャネル(PUSCH)についてWDを設定することを含む。方法はまた、ダウンリンク制御情報(DCI)を前記WDに送信することによって、前記第1のSRSリソースセット、前記第2のSRSリソースセット、前記第1および第2のSRSリソースセットの両方、の1つに関連づけられた少なくとも1つのPUSCH送信機会における前記WDによるPUSCH送信をスケジューリングすることを含む。

【0027】

この態様によれば、いくつかの実施形態において、前記DCIは、前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1のSRSリソースセットと前記第2のSRSリソースセットの両方、のいずれが前記PUSCH送信に関連付けられるかを前記WDに示すビットフィールドを有する。いくつかの実施形態において、前記ビットフィールドは少なくとも3つのコードポイントからなり、第1のコードポイントは前記第1のSRSリソースセットを示し、第2のコードポイントは前記第2のSRSリソースセットを示し、第3のコードポイントは前記第1のSRSリソースセットと前記第2のSRSリソースセットの両方を示す。いくつかの実施形態では、前記PUSCH送信をスケジュールする前記DCIが、第1および第2のサウンディング基準信号リソースインジケータ(SRI)フィールドを含む。いくつかの実施形態では、前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信プリコーディング行列インジケータ(TPMI)フィールドを含む。いくつかの実施形態では、前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信電力制御(TPC)コマンドフィールドを含む。いくつかの実施形態では、前記第1のSRSリソースセットに関連づけられた前記WDによる前記PUSCH送信が、第1のSRSリソースインジケータ(SRI)、第1の送信プリコーディング行列インジケータ(TPMI)、および第1の送信電力制御(TPC)コマンドに従って前記PUSCHを送信することを含む。いくつかの実施形態では、前記第2のSRSリソースセットに関連づけられた前記WDによる前記PUSCH送信が、第2のSRSリソースインジケータ(SRI)、第2の送信プリコーディング行列インジケータ(TPMI)、および第2の送信電力制御(TPC)コマンドに従って前記PUSCHを送信することを含む。

【0028】

さらに別の態様によれば、1つ以上のネットワークノードと通信するように構成されたWDは、前記1つ以上のネットワークノードの1つから、物理アップリンク共有チャネル(PUSCH)送信に関連づけられた第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットの設定を受信するように構成された無線インタフェースを含む。前記無線インタフェースは、少なくとも1つのPUSCH送信機会においてWDがPUSCHを送信するためのダウンリンク制御情報(DCI)を受信するようにさらに構成され、前記DCIは、前記PUSCH送信が前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1および前記第2のSRSリソースセットの両方、の1つに関連づけられていることを示すビットフィールドを有する。
前記無線インタフェースは、前記少なくとも1つのPUSCH送信機会において、前記第1のSRSリソースセット、前記第2のSRSリソースセット、前記第1および前記第2のSRSリソースセットの両方のうち、前記示された1つに関連付けられた前記PUSCHを送信するようにさらに構成される。

【0029】

この態様によれば、いくつかの実施形態において、前記ビットフィールドの第1のコードポイントが前記第1のSRSリソースセットに関連づけられた前記PUSCH送信を示し、前記ビットフィールドの第2のコードポイントが前記第2のSRSリソースセットに関連づけられた前記PUSCH送信を示し、前記ビットフィールドの第3のコードポイントが前記第1および前記第2のSRSリソースセットの両方に関連づけられたPUSCH送信を示す。いくつかの実施形態では、前記WDが、前記第1および第2のSRSリソースセットの少なくとも1つが示される場合に、第1および第2のサウンディング基準信号リソースインジケータ(SRI)の1つ、第1および第2の送信プリコーディング行列インジケータ(TPMI)の1つ、ならびに第1および第2の送信電力制御(TPC)コマンドの1つに従って、前記少なくとも1つのPUSCH送信機会に前記PUSCHを送信するように構成された無線インタフェースをさらに含む。いくつかの実施形態では、前記WDが、前記第3のコードポイントによって前記第1および前記第2のSRSリソースセットの両方が示される場合、少なくとも第1の送信機会に第1のサウンディング基準信号リソースインジケータ(SRI)、第1のTPMI、および第1のTPCの1つに従って、(1つ以上の)第2の送信機会に第2のSRI、第2のTPMI、および第2のTPCの1つに従って、前記PUSCHを送信するように構成された無線インタフェースをさらに含む。

【0030】

さらに別の態様によれば、WDにおける方法は、1つ以上のネットワークノードの1つから、物理アップリンク共有チャネル(PUSCH)送信に関連づけられた第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットの設定を受信することを含む。前記方法は、少なくとも1つのPUSCH送信機会においてWDがPUSCHを送信するためのダウンリンク制御情報(DCI)を受信することをさらに含み、前記DCIは、前記PUSCH送信が前記第1のSRSリソースセット、前記第2のSRSリソースセット、および前記第1および前記第2のSRSリソースセットの両方、の1つに関連づけられていることを示すビットフィールドを有する。前記無線インタフェースは、前記少なくとも1つのPUSCH送信機会において、前記第1のSRSリソースセット、前記第2のSRSリソースセット、前記第1および前記第2のSRSリソースセットの両方のうち、前記示された1つに関連付けられた前記PUSCHを送信するようにさらに構成される。

【0031】

この態様によれば、いくつかの実施形態において、前記ビットフィールドの第1のコードポイントが前記第1のSRSリソースセットに関連づけられた前記PUSCH送信を示し、前記ビットフィールドの第2のコードポイントが前記第2のSRSリソースセットに関連づけられた前記PUSCH送信を示し、前記ビットフィールドの第3のコードポイントが前記第1および前記第2のSRSリソースセットの両方に関連づけられたPUSCH送信を示す。いくつかの実施形態では、前記方法が、前記第1および第2のSRSリソースセットの少なくとも1つが示される場合に、第1および第2のサウンディング基準信号リソースインジケータ(SRI)の1つ、第1および第2の送信プリコーディング行列インジケータ(TPMI)の1つ、ならびに第1および第2の送信電力制御(TPC)コマンドの1つに従って、前記少なくとも1つのPUSCH送信機会に前記PUSCHを送信することをさらに含む。いくつかの実施形態では、前記方法が、前記第3のコードポイントによって前記第1および前記第2のSRSリソースセットの両方が示される場合、少なくとも第1の送信機会に第1のサウンディング基準信号リソースインジケータ(SRI)、第1のTPMI、および第1のTPCの1つに従って、(1つ以上の)第2の送信機会に第2のSRI、第2のTPMI、および第2のTPCの1つに従って、前記PUSCHを送信することをさらに含む。

【図面の簡単な説明】

【0032】

本実施形態および、本実施形態に付随する利点および特徴のより完全な理解は、以下の詳細な説明を添付の図面と併せて考慮して参照することによってより容易に理解されるであろう。

【0033】

【図1】図1は、15kHzのサブキャリア間隔を有する例示的なNR時間領域構造の図である。

【図2】図2は、例示的なNR物理リソースグリッドの図である。

【図3】図3は、本開示の原理による、中間ネットワークを介してホストコンピュータに接続された通信システムを示す例示的なネットワークアーキテクチャの概略図である。

【図4】図4は、本開示のいくつかの実施形態による、少なくとも一部が無線である接続を通じ、ネットワークノードを介して無線機器と通信するホストコンピュータのブロック図である。

【図5】図5は、本開示のいくつかの実施形態にしたがって無線機器でクライアントアプリケーションを実行するための、ホストコンピュータと、ネットワークノードと、無線機器とを含む通信システムで実施される例示的な方法を示すフローチャートである。

【図6】図6は、本開示のいくつかの実施形態にしたがって無線機器でユーザデータを受信するための、ホストコンピュータと、ネットワークノードと、無線機器とを含む通信システムで実施される例示的な方法を示すフローチャートである。

【図7】図7は、本開示のいくつかの実施形態にしたがってホストコンピュータで無線機器からユーザデータを受信するための、ホストコンピュータと、ネットワークノードと、無線機器とを含む通信システムで実施される例示的な方法を示すフローチャートである。

【図8】図8は、本開示のいくつかの実施形態にしたがってホストコンピュータでユーザデータを受信するための、ホストコンピュータと、ネットワークノードと、無線機器とを含む通信システムで実施される例示的な方法を示すフローチャートである。

【図9】図9は、本開示のいくつかの実施形態による、ネットワークノードにおける例示的な手順のフローチャートである。

【図10】図10は、本開示のいくつかの実施形態による、無線機器における例示的な手順のフローチャートである。

【図11】図11は、本開示のいくつかの実施形態による、ネットワークノードにおける別の手順方法のフローチャートである。

【図12】図12は、本開示のいくつかの実施形態による、WDにおける別の手順のフローチャートである。

【図13】図13は、本開示のいくつかの実施形態による、単一のDCIによって同じまたは異なるTRPへの1つ以上のPUSCH送信をスケジュールする一例の図である。

【図14】図14は、本開示のいくつかの実施形態による、PDCCHの図である。

【図15】図15は、本開示のいくつかの実施形態による、リソース割り当ての図である。

【図16】図16は、本開示のいくつかの実施形態による、別のリソース割り当ての図である。

【図17】図17は、本開示のいくつかの実施形態による、様々なフォーマットについての性能を示す図である。

【発明を実施するための形態】

【0034】

上述のように、既存の3GPP NR Rel-15/16 UL DCIフォーマットは、単一のTRPに向けてPUSCH送信をスケジュールする場合のみに適しうる。複数のTRPへのPUSCH送信をサポートするために、2つのTRPへのPUSCH送信のためのUL DCIフォーマットで2つのSRI、2つのTMPI、および2つのTPCが検討されているが、単一のTRPへのPUSCH送信と複数のTRPへのPUSCH送信を同じDCIフォーマットでどのようにサポートするかは未解決の課題である。本開示は少なくとも部分的に、上述の問題および/または本明細書に記載の他の問題を解決する。

【0035】

例示的な実施形態を詳細に説明する前に、実施形態は、単一の送信/受信ポイント(TRP)または複数のTRPへの物理アップリンク共有チャネル(PUSCH)送信の動的指示に関連する、装置の構成要素および処理ステップの組合せに主に存在することに留意されたい。

【0036】

したがって、構成要素は、本明細書の説明から利益を享受する当業者には容易に明らかであろう詳細で本開示を曖昧にしないよう、実施形態を理解するのに適切な特定の詳細のみを示す従来の記号によって、図面において適宜表現されている。同様の番号は、説明全体を通して同様の要素を示す。

【0037】

本明細書で使用される場合、「第1」および「第2」、「上部」および「下部」などの関係用語は、1つのエンティティまたは要素を別のエンティティまたは要素と区別するためにのみ用いられうる。そして、必ずしも、そのようなエンティティまたは要素間の任意の物理的または論理的関係または順序を要求したりまたは暗示したりすることはない。本明細書で使用される用語は特定の実施形態を説明することのみを目的としており、本明細書で説明される概念を限定することを意図するものではない。本明細書において、単数形「a」および「an」は文脈上明らかに背反する場合を除き、複数形も含むことが意図される。本明細書において、用語「有する(comprisesまたはcomprising)」および/または「含む(includesまたはincluding)」は、述べられた機能、整数、ステップ、動作、要素、および/または構成要素の存在を特定するが、1つ以上の他の機能、整数、ステップ、動作、要素、構成要素、および/またはそれらのグループの存在を除外しない。

【0038】

本明細書に記載される実施形態において、「～と通信中」などの接合用語は、電気的またはデータ通信を示すために使用されうる。これは、例えば、物理的接触、誘導、電磁放射、無線シグナリング、赤外線シグナリング、または光シグナリングによって達成されうる。当業者であれば、複数の構成要素が相互に動作することができ、電気通信およびデータ通信を達成するための修正および変形が可能であることを理解するのであろう。

【0039】

本明細書で説明するいくつかの実施形態では「結合された」、「接続された」などという用語は、必ずしも直接的であることは必要ないが、接続を示すために本明細書で用いられうる。また、有線接続および/または無線接続を含みうる。

【0040】

本明細書で使用される用語「ネットワークノード」は無線ネットワークに含まれる任意の種類のネットワークであってよく、基地局(BS)、無線基地局、基地送受信局(BTS)、基地局コントローラ(BSC)、無線ネットワークコントローラ(RNC)、ノードB(gNB)、発展型ノードB(eNBまたはeノードB)、ノードB、MSR BS、マルチセル/マルチキャスト協調エンティティ(MCE)、統合アクセスおよびバックホール(IAB)ノード、中継ノード、ドナーノード制御無線アクセスポイント(AP)、送信ポイント、送信ノード、遠隔無線ユニット(RRU)遠隔無線ヘッド(RRH)、コアネットワークノード(たとえば、モバイル管理エンティティ(MME)、自己組織化ネットワーク(SON)ノード、協調ノード、測位ノード、MDTノードなど)、外部ノード(たとえば、サードパーティノード、現在のネットワークの外部にあるノード)、分散アンテナシステム(DAS)のノード、スペクトルアクセスシステム(SAS)ノード、要素管理システム(EMS)などの任意のものを含みうる。ネットワークノードはまた、試験機器を含んでもよい。

【0041】

本明細書で使用される用語「無線ノード」は、無線機器(WD)または無線ネットワークノードなどの無線機器(WD)も示すために使用されうる。本開示では、用語ネットワークノードが、用語gNBと互換的に使用されうる。しかしながら、本明細書で開示される原理は、gNBに限らず、本明細書で説明される原理に従って動作するように構成される様々な種類の基地局および/または他のネットワークノードに適用されうる。

【0042】

いくつかの実施形態では、無線機器(WD)またはユーザ装置(UE)という非限定的な用語が互換的に使用される。本明細書のWDは、無線機器(WD)のような、無線信号を通じてネットワークノードまたは別のWDとの通信が可能な任意のタイプの無線機器であってよい。WDはまた、無線通信デバイス、ターゲットデバイス、デバイスツーデバイス(D2D)WD、マシンタイプWDまたはマシンツーマシン通信(M2M)が可能なWD、低コストおよび/または低複雑性WD、WDを装備したセンサ、タブレット、モバイル端末、スマートフォン、組み込み型ラップトップ(LEE)、ラップトップ搭載機器(LME)、USBドングル、顧客宅内機器(CPE)、モノのインターネット(IoT)デバイス、または狭帯域IoT(NB-IOT)デバイスなどでありうる。

【0043】

また、いくつかの実施形態において、一般的な用語「無線ネットワークノード」が用いられる。それは、基地局、無線基地局、基地送受信局、基地局コントローラ、ネットワークコントローラ、RNC、発展型ノードB(eNB)、ノードB、gNB、マルチセル/マルチキャスト協調エンティティ(MCE)、IABノード、リレーノード、アクセスポイント、無線アクセスポイント、遠隔無線ユニット(RRU)遠隔無線ヘッド(RRH)のいずれかを有しうる、任意の種類の無線ネットワークノードでありうる。

【0044】

たとえば、3GPP LTEおよび/またはNew Radio(NR)など、1つの特定のワイヤレスシステムからの用語が本開示で使用されうるが、これは本開示の範囲をそれらシステムのみに限定するものと見なされるべきではないことに留意されたい。広帯域符号分割多元接続(WCDMA(登録商標))、マイクロ波アクセスのための世界規模の相互運用性(WiMax)、ウルトラモバイルブロードバンド(UMB)、および移動通信のためのグローバルシステム(GSM(登録商標))を非限定的に含む他の無線システムも、本開示でカバーされるアイデアを活用することで利益をうることができる。

【0045】

いくつかの実施形態では、送信受信ポイント(TRP)がネットワークノード、無線ヘッドなどのいずれかでありうる。TRPは、いくつかの実施形態では空間関係またはTCI状態によって表されうる。いくつかの実施形態では、TRPが複数のTCI状態を使用することができる。くつかの実施形態では、TRPは、その要素に固有の物理層特性とパラメータに従って前記WDとの間で無線信号を送受信するネットワークノードの一部である可能性がある。いくつかの実施形態では、複数送信/受信ポイント(multi-TRP)動作において、サービングセルは2つのTRPからWDをスケジュールすることができ、より良好なPDSCHカバレッジ、信頼性、および/またはデータレートを提供する。マルチTRPには、単一DCIとマルチDCIの2つの異なる動作モードがある。両方のモードについて、アップリンクおよびダウンリンク動作の制御は、物理レイヤおよび媒体アクセス制御(MAC)の両方によって行われる。単一DCIモードではWDが両方のTRPに対して同一のDCIによってスケジュールされ、マルチDCIモードではWDが各TRPからの独立したDCIによってスケジュールされる。ここで、TRPはネットワークノードであってもよい。通常、同一WDとの間の通信に関与する複数のネットワークノードが存在しうるが、そのようなネットワークノードの各々はWDに対するTRPである。

【0046】

さらに、無線機器またはネットワークノードによって実行されるものとして本明細書で説明する機能は、複数の無線機器および/またはネットワークノードにわたって分散されうることに留意されたい。言い換えれば、本明細書で説明するネットワークノードおよび無線機器の機能は単一の物理デバイスによる実行に限定されず、実際にはいくつかの物理デバイス間で分散されうることが想定されている。

【0047】

別段の定義がない限り、本明細書で使用されるすべての用語(技術用語および科学用語を含む)は、本開示が属する技術分野の当業者によって一般に理解されるものと同じ意味を有する。さらに、本明細書で使用される用語は、本明細書および関連技術の文脈における意味と一致する意味を有するものとして解釈されるべきであり、本明細書で明示的にそのように定義されない限り、理想化された意味または過度に形式的な意味で解釈されないことが理解されよう。

【0048】

いくつかの実施形態は、単一の送信/受信ポイント(TRP)または複数のTRPへの物理アップリンク共有チャネル(PUSCH)送信の動的インジケーションを提供する。

【0049】

ここで、同様の要素が同様の参照符号によって参照される図面に戻ると、図3には、LTEおよび/またはNR (5G)などの規格をサポートしうる3GPPタイプのセルラネットワークのような、一実施形態に係る通信システム10の模式図が示されている。通信システム10は、無線アクセスネットワークなどのアクセスネットワーク12と、コアネットワーク14とを有する。アクセスネットワーク12はNB、eNB、gNB、または他のタイプの無線アクセスポイントなどの複数のネットワークノード16a、16b、16c(ネットワーク16と総称する)を有し、それぞれは対応するカバレッジエリア18a、18b、18c(カバレッジエリア18と総称する)を規定する。各ネットワークノード16a、16b、16cは、有線または無線接続20を通じてコアネットワーク14に接続可能である。カバレッジエリア18aに位置する第1の無線機器(WD)22aは、対応するネットワークノード16aに無線接続するか、ネットワークノード16aにページングされるように構成される。カバレッジエリア18b内の第2のWD22bは、対応するネットワークノード16bに無線接続可能である。この例では複数のWD22a、22b(無線機器22と総称する)を示しているが、開示される実施形態はただ1つのWDがカバレッジエリア内に存在する状況、またはただ1つのWDが対応するネットワークノード16に接続している状況にも等しく適用可能である。便宜上、2つのWD22および3つのネットワークノード16のみを示しているが、通信システムはより多くのWD22およびネットワークノード16を含み得ることに留意されたい。

【0050】

また、あるWD22は同時に通信することができ、および/または2つ以上のネットワークノード16および2つ以上のタイプのネットワークノード16と別個に通信するように構成することができることが想定されている。そのようなネットワークノード16の各々は、WD22に対してTRPとして振る舞う。たとえば、あるWD22は、LTEをサポートするネットワークノード16aと、NRをサポートする同じまたは異なるネットワークノード16bとのデュアルコネクティビティを有することができる。一例として、WD22aは、LTE/E-UTRANのためのeNBおよびNR/Next Generation-RANのためのgNBと通信中でありうる。したがって、図3は、2つのネットワークノードTRP16aおよび16bによってサーブされているWD16aを示す。いくつかの実施形態では、2つ以上のネットワークノードが同一のWDに対するTRPとして機能することができる。

【0051】

通信システム10はそれ自体がホストコンピュータ24に接続されており、ホストコンピュータ24は、スタンドアロンサーバ、クラウド実装サーバ、分散サーバ、のハードウェアおよび／またはソフトウェアで実施されてもよいし、サーバファーム内の処理リソースとして実施されてもよい。ホストコンピュータ24は、サービスプロバイダの所有または管理下にある場合もあれば、サービスプロバイダによって、またはサービスプロバイダに代わって運用されている場合もある。電気通信ネットワーク10とホストコンピュータ24との間の接続26および28は、コアネットワーク14からホストコンピュータ24に直接延びてもよいし、オプションの中間ネットワーク30を経由してもよい。中間ネットワーク30は、パブリックネットワーク、プライベートネットワーク、またはホステッドネットワークの1つ、または2つ以上の組合せであってよい。存在する場合、中間ネットワーク30はバックボーンネットワークまたはインターネットであってもよい。いくつかの実施形態では、中間ネットワーク30が2つ以上のサブネットワーク(図示せず)を有してもよい。

【0052】

図3の通信システムは、全体として、接続されたWD22a、22bの1つとホストコンピュータ24との間の接続性を実現する。この接続性は、オーバーザトップ(OTT)接続として記述されうる。ホストコンピュータ24および接続されたWD22a、22bは、アクセスネットワーク12、コアネットワーク14、任意の中間ネットワーク30、および場合によってはさらなるインフラストラクチャ（図示せず）を媒介として使用して、OTT接続を通じてデータおよび／またはシグナリングを通信するように構成される。OTT接続は、OTT接続が通過する参加通信装置の少なくとも一部がアップリンク通信およびダウンリンク通信のルーティングに気付かないという意味で、透過的でありうる。例えば、ネットワークノード16は、接続されたWD22aに転送される(例えばハンドオーバされる)ホストコンピュータ24から発信されるデータをもつ入方向ダウンリンク通信の過去のルーティングについて通知されないか、通知される必要がないであろう。同様に、ネットワークノード16は、WD22aからホストコンピュータ24に向けて発信される出方向アップリンク通信の将来のルーティングを意識する必要はない。

【0053】

ネットワークノード16は、物理アップリンク共有チャネル(PUSCH)について、WD22を、第1のサウンディング基準信号(SRS)リソースセットと、第2のSRSリソースセットとを用いて設定するように構成された設定ユニット32を含むように構成される。無線機器22は、少なくとも1つのPUSCH送信機会において、第1のSRSリソースセット、第2のSRSリソースセット、第1および前記第2のSRSリソースセットの両方のうち、示された1つに関連付けられたPUSCHを送信するように構成された無線インタフェース82を含むように構成される。無線機器はまた、物理アップリンク共有チャネル(PUSCH)送信を送信するための1つ以上の送信/受信ポイント(TRP)を選択するように構成されたTRP選択ユニット34(図示せず)をさらに含むことができ、TRPは、ネットワークノードから受信されたダウンリンク制御情報(DCI)に従って選択される。

【0054】

先の段落で論じたWD22、ネットワークノード16、およびホストコンピュータ24の、一実施形態による例示的な実装を、図4を参照して説明する。通信システム10において、ホストコンピュータ24は、通信システム10の異なる通信装置のインタフェースとの有線または無線接続をセットアップおよび維持するように構成された通信インタフェース40を含むハードウェア(HW)38を有する。ホストコンピュータ24は、記憶および／または処理能力を有することができる処理回路42をさらに有する。処理回路42は、プロセッサ44およびメモリ46を含みうる。特に、中央演算処理装置のようなプロセッサおよびメモリに加えて、またはその代わりに、処理回路42は、処理および/または制御のための集積回路、たとえば、命令を実行するように適合された、1つ以上のプロセッサおよび/またはプロセッサコアおよび/またはFPGA(フィールドプログラマブルゲートアレイ)および/またはASIC(特定用途向け集積回路)を有しうる。プロセッサ44は、任意の種類の揮発性および/または不揮発性メモリ、例えば、キャッシュおよび/またはバッファメモリおよび/またはRAM(ランダムアクセスメモリ)および/またはROM(読み出し専用メモリ)および/または光メモリおよび/またはEPROM(消去可能プログラマブル読み出し専用メモリ)を有しうるメモリ46に、アクセス(例えば、書き込みおよび/または読み出し)するように構成されうる。

【0055】

処理回路42は、本明細書で説明する方法および/または手順のいずれかを制御するように、および/または、例えばホストコンピュータ24によって、そのような方法および/または手順を実行させるように構成されてもよい。プロセッサ44は、本明細書で説明するホストコンピュータ24の機能を実行するための1つ以上のプロセッサ44に対応する。ホストコンピュータ24は、データ、プログラムソフトウェアコード、および/または本明細書で説明する他の情報を格納するように構成されたメモリ46を含む。いくつかの実施形態では、ソフトウェア48および/またはホストアプリケーション50が、プロセッサ44および/または処理回路42によって実行されると、プロセッサ44および/または処理回路42に、ホストコンピュータ24に関して本明細書で説明する手順を実行させる命令を含みうる。命令は、ホストコンピュータ24に関連付けられたソフトウェアであってもよい。

【0056】

ソフトウェア48は、処理回路42によって実行可能でありうる。ソフトウェア48は、ホストアプリケーション50を含む。ホストアプリケーション50は、WD22およびホストコンピュータ24で終端するOTT接続52を介して接続するWD22のようなリモートユーザに、サービスを提供するように動作可能であってよい。サービスをリモートユーザに提供する際に、ホストアプリケーション50は、OTT接続52を使用して送信されるユーザデータを提供することができる。「ユーザデータ」は、本明細書で説明する機能を実施するためのデータおよび情報であってよい。一実施形態において、ホストコンピュータ24は、制御および機能をサービスプロバイダに提供するように構成されてよく、またサービスプロバイダによって、またはサービスプロバイダに代わって運用されてよい。ホストコンピュータ24の処理回路42は、ホストコンピュータ24によるネットワークノード16および/または無線機器22の観察、監視、制御、ネットワークノード16および/または無線機器22への送信、および/または、ネットワークノード16および/または無線機器22からの受信を可能にしうる。

【0057】

通信システム10は、通信システム10に設けられた基地局16であって、基地局16がホストコンピュータ24およびWD22と通信することを可能にするハードウェア58を有する基地局16をさらに含む。ハードウェア58は、通信システム10の様々な通信機器のインタフェースとの有線または無線接続をセットアップおよび維持するための通信インタフェース60、ならびにネットワークノード16によってサーブされるカバレッジエリア18内に位置するWD22との少なくとも無線接続64をセットアップおよび維持するための無線インタフェース62を含みうる。無線インタフェース62はたとえば、1つ以上のRF送信器、1つ以上のRF受信器、および/または1つ以上のRF送受信器として形成されてもよいし、それらを含んでもよい。通信インタフェース60は、ホストコンピュータ24への接続66を容易にするように構成されうる。接続66は、直接接続であってもよく、または通信システム10のコアネットワーク14を経由してもよく、および/または通信システム10の外部の1つ以上の中間ネットワーク30を経由してもよい。

【0058】

図示の実施形態では、ネットワークノード16のハードウェア58が処理回路68をさらに含む。処理回路68は、プロセッサ70およびメモリ72を含みうる。特に、中央演算処理装置のようなプロセッサおよびメモリに加えて、またはその代わりに、処理回路68は、処理および/または制御のための集積回路、たとえば、命令を実行するように適合された、1つ以上のプロセッサおよび/またはプロセッサコアおよび/またはFPGA(フィールドプログラマブルゲートアレイ)および/またはASIC(特定用途向け集積回路)を有しうる。プロセッサ70は、任意の種類の揮発性および/または不揮発性メモリ、例えば、キャッシュおよび/またはバッファメモリおよび/またはRAM(ランダムアクセスメモリ)および/またはROM(読み出し専用メモリ)および/または光メモリおよび/またはEPROM(消去可能プログラマブル読み出し専用メモリ)を有しうるメモリ72に、アクセス(例えば、書き込みおよび/または読み出し)するように構成されうる。

【0059】

したがって、ネットワークノード16はさらに、内部に(例えばメモリ72に)格納された、または外部接続を通じてネットワークノード16がアクセス可能な外部メモリ(例えば、データベース、ストレージアレイ、ネットワークストレージデバイスなど)に格納されたソフトウェア74を有する。ソフトウェア74は、処理回路68によって実行可能であってよい。処理回路68は、本明細書で説明される方法および/または手順のいずれかを制御するように、および/または、そのような方法および/または手順を(例えばネットワークノード16に)実行させるように構成されうる。プロセッサ70は、本明細書で説明するネットワークノード16の機能を実行するための1つ以上のプロセッサ70に対応する。メモリ72は、データ、プログラムソフトウェアコード、および/または本明細書で説明する他の情報を格納するように構成される。いくつかの実施形態では、ソフトウェア74が、プロセッサ70および/または処理回路68によって実行されると、プロセッサ70および/または処理回路68に、ネットワークノード16に関して本明細書で説明する手順を実行させる命令を含みうる。たとえば、ネットワークノード16の処理回路68は、物理アップリンク共有チャネル(PUSCH)について、第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセット)を用いてWD22を設定するように構成された設定ユニット32を含みうる。.

【0060】

通信システム10は、既に言及したWD22をさらに含む。WD22は、WD22が現在位置するカバレッジエリア18をサーブするネットワークノード16との無線接続64をセットアップおよび維持するように構成された無線インタフェース82を含み得るハードウェア80を有しうる。無線インタフェース82はたとえば、1つ以上のRF送信器、1つ以上のRF受信器、および/または1つ以上のRF送受信器として形成されてもよいし、それらを含んでもよい。1つ以上の実施形態において、無線インタフェース82は、少なくとも1つのPUSCH送信機会において、第1のSRSリソースセット、第2のSRSリソースセット、第1および第2のSRSリソースセットの両方のうち、示された1つに関連付けられたPUSCHを送信するようにさらに構成される。

【0061】

WD22のハードウェア80は、処理回路84をさらに含む。処理回路84は、プロセッサ86およびメモリ88を含みうる。特に、中央演算処理装置のようなプロセッサおよびメモリに加えて、またはその代わりに、処理回路84は、処理および/または制御のための集積回路、たとえば、命令を実行するように適合された、1つ以上のプロセッサおよび/またはプロセッサコアおよび/またはFPGA(フィールドプログラマブルゲートアレイ)および/またはASIC(特定用途向け集積回路)を有しうる。プロセッサ86は、任意の種類の揮発性および/または不揮発性メモリ、例えば、キャッシュおよび/またはバッファメモリおよび/またはRAM(ランダムアクセスメモリ)および/またはROM(読み出し専用メモリ)および/または光メモリおよび/またはEPROM(消去可能プログラマブル読み出し専用メモリ)を有しうるメモリ88に、アクセス(例えば、書き込みおよび/または読み出し)するように構成されうる。

【0062】

したがって、WD22はさらに、WD22のメモリ88に格納された、またはWD22によってアクセス可能な外部メモリ(例えば、データベース、ストレージアレイ、ネットワークストレージデバイスなど)に格納された、ソフトウェア90を有しうる。ソフトウェア90は、処理回路84によって実行可能であってよい。ソフトウェア90は、クライアントアプリケーション92を含みうる。クライアントアプリケーション92はホストコンピュータ24のサポートにより、WD22を通じて人間または人間以外のユーザにサービスを提供するように動作可能であってもよい。ホストコンピュータ24において、実行中のホストアプリケーション50は、UE1630およびホストコンピュータ24で終端するOTT接続52を介して、実行中のクライアントアプリケーション92と通信することができる。サービスをユーザに提供する際に、クライアントアプリケーション92は、ホストアプリケーション50から要求データを受信し、要求データに応答してユーザデータを提供してもよい。OTT接続52は、要求データおよびユーザデータの両方を転送することができる。クライアントアプリケーション92は、ユーザと対話して、提供するユーザデータを生成することができる。

【0063】

処理回路84は、本明細書で説明される方法および/または手順のいずれかを制御するように、および/または、そのような方法および/または手順を(例えばWD22に)実行させるように構成されうる。プロセッサ86は、本明細書で説明するWD22の機能を実行するための1つ以上のプロセッサ86に対応する。WD22は、データ、プログラムソフトウェアコード、および/または本明細書で説明する他の情報を格納するように構成されたメモリ88を含む。いくつかの実施形態では、ソフトウェア90および/またはクライアントアプリケーション92が、プロセッサ86および/または処理回路84によって実行されると、プロセッサ86および/または処理回路84に、WD22に関して本明細書で説明する手順を実行させる命令を含みうる。たとえば、無線機器22の処理回路84は物理アップリンク共有チャネル(PUSCH)送信を送信するための1つ以上の送信/受信ポイント(TRP)を選択するように構成されたTRP選択ユニット34を含むことができ、TRPはネットワークノードから受信されたダウンリンク制御情報(DCI)に従って選択される。

【0064】

いくつかの実施形態ではネットワークノード16、WD22、およびホストコンピュータ24の内部動作は図4に示されるようなものであってもよく、独立して、周囲のネットワークトポロジは図3のものであってもよい。

【0065】

図4において、OTT接続52は、ネットワークノード16を介したホストコンピュータ24と無線機器22との間の通信を説明するために抽象的に描かれており、中間装置やこれらの装置を介したメッセージの正確なルーティングについては明示的に示されていない。ネットワークインフラストラクチャは、WD22から、またはサービスプロバイダが運用するホストコンピュータ24から、あるいはその両方から隠すように構成されてもよいルーティングを決定することができる。OTT接続52がアクティブである間、ネットワークインフラストラクチャはルーティングを動的に変更する決定を（例えば、負荷分散の考慮やネットワークの再構成に基づいて）さらに行いうる。

【0066】

WD22とネットワークノード16との間の無線接続64は、本開示全体にわたって説明される実施形態の教示に従う。様々な実施形態のうちの1つ以上は、無線接続64が最後のセグメントを形成するOTT接続52を使用して、WD22に提供されるOTTサービスの性能を改善する。より正確には、これらの実施形態のいくつかの教示は、データレート、レイテンシおよび/または電力消費を改善する可能性があり、それによって、ユーザ待機時間の短縮、ファイルサイズに対する制限の緩和、より良好な応答性、バッテリ寿命の延長などの利点を提供することができる。

【0067】

いくつかの実施形態において、データレート、レイテンシ、および1つ以上の実施形態が改善する他のネットワーク動作態様を監視するために測定手順が提供されてもよい。さらに、測定結果の変動に応答して、ホストコンピュータ24とWD22との間のOTT接続52を再構成するためのオプションネットワーク機能があってもよい。OTT接続52を再構成するための測定手順および／またはネットワーク機能は、ホストコンピュータ24のソフトウェア48、またはWD22のソフトウェア90、あるいはその両方で実施することができる。いくつかの実施形態において、OTT接続52が経由する通信機器の中または通信機器に付随してセンサ（図示せず）を設けることができ、センサは、先に例示した監視量の値を供給することによって、またはソフトウェア48、90が監視量を計算または推定しうる他の物理量の値を供給することによって、測定手順に参加することができる。OTT接続52の再構成は、メッセージフォーマット、再送信設定、優先ルーティングなどを含むことができる。再構成は、ネットワークノード16に影響を与える必要はなく、ネットワークノード16には不明または感知不能であってもよい。このような手順および機能のいくつかは当技術分野で公知かつ実践されているであろう。特定の実施形態において、測定は、スループット、伝搬時間、遅延などのホストコンピュータ24の測定を容易にする、専用のWDシグナリングを伴いうる。いくつかの実施形態において、測定は、ソフトウェア48および90が伝搬時間、エラーなどを監視しながら、OTT接続52を使用して、メッセージ、特に空または「ダミー」メッセージを送信させることによって実施することができる。

【0068】

したがって、いくつかの実施形態においてホストコンピュータ24は、ユーザデータを提供するように構成された処理回路42と、WD22への送信のためにユーザデータをセルラーネットワークに転送するように構成された通信インタフェース40とを含む。いくつかの実施形態においてセルラーネットワークは、無線インタフェース62を有するネットワークノード16を含む。いくつかの実施形態においてネットワークノード16は、および/またはネットワークノード16の処理回路68は、WD22への送信を準備/開始/維持/サポート/終了するため、および/またはWD22からの送信の受信を準備/終了/維持/サポート/終了するために、本明細書で説明する機能および／または方法を実行するように構成される。

【0069】

いくつかの実施形態においてホストコンピュータ24は、処理回路42と、WD22からネットワークノード16への送信に由来するユーザデータを受信するように構成された通信インタフェース40とを含む。いくつかの実施形態においてWD22は、ネットワークノード16への送信を準備/開始/維持/サポート/終了するため、および/またはネットワークノード16の送信の受信を準備/終了/維持/サポート/終了するために、本明細書で説明する機能および／または方法を実行するように構成され、および/または、本明細書で説明する機能および／または方法を実行するように構成された無線インタフェース82および/または処理回路84を有する。

【0070】

図3および図4には、設定ユニット32およびTRP選択ユニット34などの様々な「ユニット」が、それぞれのプロセッサ内にあるものとして示しているが、これらのユニットは、ユニットの一部が処理回路内の対応するメモリに格納されるように実装されうることが想定されている。言い換えれば、ユニットは、処理回路内のハードウェアで、またはハードウェアとソフトウェアとの組合せで実装されうる。

【0071】

図5は、一実施形態による、例えば図3および図4の通信システムなどの通信システムにおいて実施される例示的な方法を示すフローチャートである。通信システムはホストコンピュータ24と、ネットワークノード16と、WD22とを含むことができ、これらは、図4を参照して説明したものであってよい。方法の1番目のステップにおいて、ホストコンピュータ24は、ユーザデータを提供する(ブロックS100)。1番目のステップのオプションのサブステップにおいて、ホストコンピュータ24は、例えばホストアプリケーション50などのホストアプリケーションを実行することにより、ユーザデータを供給する(ブロックS102)。2番目のステップにおいて、ホストコンピュータ24は、ユーザデータをWD22に搬送する送信を開始する(ブロックS104)。オプションである3番目のステップにおいて、ネットワークノード16は、本開示全体にわたって説明される実施形態の教示に従って、ホストコンピュータ24が開始した送信において搬送されたユーザデータをWD22に送信する。オプションである4番目のステップにおいて、WD22は、例えばホストコンピュータ24で実行されるホストアプリケーション50に関連づけられたクライアントアプリケーション(例えばクライアントアプリケーション92など)を実行する(ブロックS108)。

【0072】

図6は、一実施形態による、例えば図3の通信システムなどの通信システムにおいて実施される例示的な方法を示すフローチャートである。通信システムはホストコンピュータ24と、ネットワークノード16と、WD22とを含むことができ、これらは、図3および図4を参照して説明したものであってよい。方法の1番目のステップにおいて、ホストコンピュータ24は、ユーザデータを提供する(ブロックS110)。オプションのサブステップ(図示せず)において、ホストコンピュータ24は、例えばホストアプリケーション50などのホストアプリケーションを実行することにより、ユーザデータを供給する。2番目のステップにおいて、ホストコンピュータ24は、ユーザデータをWD22に搬送する送信を開始する(ブロックS112)。送信は、本開示全体にわたって説明される実施形態の教示に従って、ネットワークノード16を介して渡されうる。オプションである3番目のステップにおいて、WD22は、送信で搬送されたユーザデータを受信する(ブロックS114)。

【0073】

図7は、一実施形態による、例えば図3の通信システムなどの通信システムにおいて実施される例示的な方法を示すフローチャートである。通信システムはホストコンピュータ24と、ネットワークノード16と、WD22とを含むことができ、これらは、図3および図4を参照して説明したものであってよい。オプションである方法の1番目のステップにおいて、WD22は、ホストコンピュータ24によって供給される入力データを受信する(ブロックS116)。1番目のステップのオプションのサブステップにおいて、WD22は、ホストコンピュータ24によって供給された受信入力データに応答してユーザデータを供給するクライアントアプリケーション92を実行する(ブロックS118)。追加的にまたは代替的に、オプションである2番目のステップにおいて、WD22は、ユーザデータを供給する(ブロックS120)。2番目のステップのオプションのサブステップにおいて、WDは、例えばクライアントアプリケーション92などのクライアントアプリケーションを実行することにより、ユーザデータを供給する(ブロックS122)。ユーザデータを供給する際に、実行されたクライアントアプリケーション92は、ユーザから受け取ったユーザ入力をさらに考慮してもよい。ユーザデータが供給された具体的な方法にかかわらず、WD22は、オプションである3番目のサブステップにおいて、ユーザデータのホストコンピュータ24への送信を開始する(ブロックS124)。方法の4番目のステップにおいて、ホストコンピュータ24は、本開示全体にわたって説明される実施形態の教示に従って、WD22から送信されたユーザデータを受信する(ブロックS126)。

【0074】

図8は、一実施形態による、例えば図3の通信システムなどの通信システムにおいて実施される例示的な方法を示すフローチャートである。通信システムはホストコンピュータ24と、ネットワークノード16と、WD22とを含むことができ、これらは、図3および図4を参照して説明したものであってよい。オプションである1番目のステップにおいて、本開示全体にわたって説明される実施形態の教示に従って、ネットワークノード16は、WD22からユーザデータを受信する(ブロックS128)。オプションである2番目のステップにおいて、ネットワークノード16は、受信したユーザデータのホストコンピュータ24への送信を開始する(ブロックS130)。3番目のステップにおいて、ホストコンピュータ24は、ネットワークノード16によって開始された送信で搬送されるユーザデータを受信する(ブロックS132)。

【0075】

図9は、単一の送信/受信ポイント(TRP)または複数のTRPへの物理アップリンク共有チャネル(PUSCH)送信の動的インジケーションのための、ネットワークノード16における例示的な手順のフローチャートである。本明細書で説明する1つ以上のブロックは、(設定ユニット32を含む)処理回路68、プロセッサ70、無線インタフェース62、および/または通信インタフェース60の1つ以上など、ネットワークノード16の1つ以上の要素によって実行されうる。ネットワークノード16は、第1の送信/受信ポイント(TRP)に関連付けられた第1のサウンディング基準信号(SRS)セットと、第2のTRPに関連付けられた第2のSRSとを用いて、WDを設定するように構成される(ブロックS134)。手順はまた、第1のTRP、第2のTRP、または第1のTRPおよび第2のTRPの両方への物理アップリンク共有チャネル(PUSCH)送信をスケジュールするようにWDを設定することを含む(ブロックS136)。いくつかの実施形態では、これらのステップの一部のみがネットワークノード16によって実行される。これらの実施形態のいくつかでは、ネットワークノード16によって実行されないステップに関する結果が、他の場所で実行され、異なる方法でネットワークノード16によって導出および/または取得されるか、代替ステップによって置き換えられうる。

【0076】

図10は、本開示のいくつかの実施形態による、無線機器22における例示的な手順のフローチャートである。本明細書で説明する1つ以上のブロックは、(設定ユニット34を含む)処理回路84、プロセッサ86、無線インタフェース82、および/または通信インタフェース60の1つ以上など、無線機器22の1つ以上の要素によって実行されうる。無線機器22は、物理アップリンク共有チャネル(PUSCH)送信を送信するための1つ以上の送信/受信ポイント(TRP)を選択するように構成され、TRPはネットワークノードから受信されたダウンリンク制御情報(DCI)に従って選択される(ブロックS138)。これらの実施形態のいくつかでは、WD22によって実行されないステップに関する結果が、他の場所で実行され、異なる方法でWD22によって導出および/または取得されるか、代替ステップによって置き換えられうる。

【0077】

図11は、本開示のいくつかの実施形態による、ネットワークノード16における例示的な手順のフローチャートである。本明細書で説明する1つ以上のブロックは、(設定ユニット32を含む)処理回路68、プロセッサ70、無線インタフェース62、および/または通信インタフェース60の1つ以上など、ネットワークノード16の1つ以上の要素によって実行されうる。ネットワークノード16は、物理アップリンク共有チャネルPUSCHについて、第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットを用いてWD22を設定するように構成される(ブロックS140)。手順はまた、ダウンリンク制御情報(DCI)をWD22に送信することによって、第1のSRSリソースセット、第2のSRSリソースセット、第1および第2のSRSリソースセットの両方、の1つに関連づけられた少なくとも1つのPUSCH送信機会におけるWD22によるPUSCH送信をスケジュールすることを含む(ブロックS142)。

【0078】

いくつかの実施形態において、DCIは、第1のSRSリソースセット、第2のSRSリソースセット、および第1および第2のSRSリソースセットの両方、のいずれがPUSCH送信に関連付けられるかをWD22に示すビットフィールドを有する。いくつかの実施形態において、ビットフィールドは少なくとも3つのコードポイントからなり、第1のコードポイントは第1のSRSリソースセットを示し、第2のコードポイントは第2のSRSリソースセットを示し、第3のコードポイントは第1および第2のSRSリソースセットの両方を示す。いくつかの実施形態では、PUSCH送信をスケジュールするDCIが、第1および第2のサウンディング基準信号リソースインジケータ(SRI)フィールドを含む。いくつかの実施形態では、PUSCH送信をスケジュールするDCIが、第1および第2の送信プリコーディング行列インジケータ(TPMI)フィールドを含む。

【0079】

いくつかの実施形態では、PUSCH送信をスケジュールするDCIが、第1および第2の送信電力制御(TPC)コマンドフィールドを含む。いくつかの実施形態では、第1のSRSリソースセットに関連づけられたWD22によるPUSCH送信が、第1のSRSリソースインジケータ(SRI)、第1の送信プリコーディング行列インジケータ(TPMI)、および第1の送信電力制御(TPC)コマンドに従ってPUSCHを送信することを含む。いくつかの実施形態では、第2のSRSリソースセットに関連づけられたWD22によるPUSCH送信が、第2のSRSリソースインジケータ(SRI)、第2の送信プリコーディング行列インジケータ(TPMI)、および第2の送信電力制御(TPC)コマンドに従ってPUSCHを送信することを含む。いくつかの実施形態では、第1および第2のSRSリソースセットに関連づけられたWD22によるPUSCH送信が、第1および第2のSRSリソースインジケータ(SRI)、第1および第2の送信プリコーディング行列インジケータ(TPMI)、および第1および第2の送信電力制御(TPC)コマンドに従ってPUSCHを送信することを含む。

【0080】

図12は、本開示のいくつかの実施形態による、無線機器22における例示的な手順のフローチャートである。本明細書で説明する1つ以上のブロックは、処理回路84、プロセッサ86、無線インタフェース82、および/または通信インタフェース60の1つ以上など、無線機器22の1つ以上の要素によって実行されうる。無線機器22は、1つ以上のネットワークノードの1つから、物理アップリンク共有チャネル(PUSCH)送信に関連づけられた第1のサウンディング基準信号(SRS)リソースセットおよび第2のSRSリソースセットの設定を受信するように構成される(ブロックS144)。方法はされに、少なくとも1つのPUSCH送信機会においてWD22によってPUSCHを送信するためのダウンリンク制御情報(DCI)を受信することを含み(ブロックS146)、DCIは、第1のSRSリソースセット(ブロックS148)、第2のSRSリソースセット(ブロックS150)、および第1および第2のSRSリソースセットの両方(ブロックS152)、の1つに関連づけられたPUSCH送信を示すビットフィールドを有する。無線インタフェース82は、少なくとも1つのPUSCH送信機会において、第1のSRSリソースセット、第2のSRSリソースセット、第1および第2のSRSリソースセットの両方のうち、示された1つに関連付けられたPUSCHを送信するようにさらに構成される(ブロックS154)。

【0081】

この態様によれば、いくつかの実施形態において、ビットフィールドの第1のコードポイントが第1のSRSリソースセットに関連づけられたPUSCH送信を示し、ビットフィールドの第2のコードポイントが第2のSRSリソースセットに関連づけられたPUSCH送信を示し、ビットフィールドの第3のコードポイントが第1および第2のSRSリソースセットの両方に関連づけられたPUSCH送信を示す。いくつかの実施形態では、方法が、第1および第2のSRSリソースセットの少なくとも1つが示される場合に、第1および第2のサウンディング基準信号リソースインジケータ(SRI)の1つ、第1および第2の送信プリコーディング行列インジケータ(TPMI)の1つ、ならびに第1および第2の送信電力制御(TPC)コマンドの1つに従って、少なくとも1つのPUSCH送信機会にPUSCHを送信することをさらに含む。いくつかの実施形態では、方法が、第3のコードポイントによって第1および第2のSRSリソースセットの両方が示される場合、少なくとも第1の送信機会に第1のサウンディング基準信号リソースインジケータ(SRI)、第1のTPMI、および第1のTPCの1つに従って、(1つ以上の)第2の送信機会に第2のSRI、第2のTPMI、および第2のTPCの1つに従って、PUSCHを送信することをさらに含む。

【0082】

本開示の取り決め(arrangement)の一般的な手順の流れを説明し、本開示の手順および機能を実施するためのハードウェアおよびソフトウェアの取り決めの例を提供してきたが、以下のセクションでは、単一の送信/受信ポイント(TRP)または複数のTRPへの物理アップリンク共有チャネル(PUSCH)送信の動的インジケーションのための取り決めの詳細および例を提供する。さらに、以下の実施形態はTRPに関して説明されるが、TRPは理解を容易にするためにネットワークノード16の観点から説明される。すなわち、以下で説明する1つ以上のTRP/ネットワークノード16の機能の1つ以上は、処理回路68、プロセッサ70、設定ユニット32、無線インタフェース62などの1つ以上によって実行されうる。すなわち、TRPは先に説明および規定したように、例えば、ネットワークノード16、ネットワークノード16の一部などに対応しうる。しかしながら、そのような説明は、実施形態をネットワークノード16のみに限定することを意図するものではないことに留意されたい。さらに、以下で説明する無線機器22の機能の1つ以上は、処理回路84、プロセッサ86、TRP選択ユニット34、無線インタフェース82などの1つ以上によって実行されうる。

【0083】

単一のTRPまたは複数のTRPへのPUSCH送信の動的インジケーション
この実施形態では、2つのTRPに向けて1つ以上のPUSCH送信機会をスケジュールするために単一のDCIを用いるものとする。複数のPUSCH送信機会がある場合、異なる機会は同じトランスポートブロック(TB)または異なるTBに対応し、同じTRPまたは異なるTRPに向かう。一例を図13に示す。

【0084】

2つのTRPに向けてPUSCHをスケジュールするために、2つのTRPに関連づけられた、少なくとも以下のパラメータを含むいくつかのTRP固有パラメータはDCIで動的に示されうる。
・ 2つのSRSリソースインジケータ(SRI)、
・ 2つのTPMIおよびランク(たとえば、送信レイヤの数)インジケータ、および/または
・ 2つのTPCコマンド。

【0085】

DCIでTRP固有パラメータを示すためのオプションは2つある。
・ 選択肢1：TRPごとの別個のビットフィールド。TRP固有パラメータ/インジケータ用に2つのフィールドを用いる(TRPごとに1つ)。
一例を以下に示す。
TRP #1に関連付けられた、パラメータ1用の第1のビットフィールド、
TRP #1に関連付けられた、パラメータ2用の第1のビットフィールド、
...
TRP #1に関連付けられた、パラメータN用の第1のビットフィールド、
TRP #2に関連付けられた、パラメータ1用の第2のビットフィールド、
TRP #2に関連付けられた、パラメータ2用の第2のビットフィールド、
...
TRP #2に関連付けられた、パラメータN用の第2のビットフィールド。
・ 選択肢2：両方のTRPに対する同じビットフィールド：各TRP固有パラメータ/インジケータ用にジョイント符号化を用いた単一フィールドを用いる。一例を表1に示す。

【表1】

【0086】

いずれの選択肢においても、設計目標の1つは単一TRPモードと呼ばれる単一のTRPへのPUSCH送信と、マルチTRPモードと呼ばれる2つのTRPへのPUSCH送信との動的切り替えをサポートすることであってよい。単一TRPモードおよびマルチTRPモードの両方について、DCIフィールドならびに各フィールドのサイズは同じであってよい。たとえば、SRIインジケーションのために、DCIは、各フィールドが異なるTRPに対応する同サイズの2つのSRIフィールドを含みうる。DCIは、TPMIインジケーションのために、同サイズの(コードブックベースのPUSCH送信のための)2つのTPMIフィールドをさらに含むことができ、各フィールドは異なるTRPに対応する。DCIはさらに、TPCのために同サイズの2つのTPCフィールドを含むことができ、各フィールドは異なるTRPに対応する。

【0087】

一実施形態において、PUSCHがTRP#1、TRP#2、または両方のTRPのいずれに送信されるかを示すために、新規のTRPインジケータ(TRPI)ビットフィールドをDCIに導入してもよい。

【0088】

TRPごとに別個のビットフィールドが用いられる場合、TRPIフィールドは、第1のビットフィールド、第2のビットフィールド、または第1および第2のビットフィールドの両方のいずれが有効化されているかを示すために用いることができる。以下、一例を示すとともに説明する。

【0089】

新規の2ビットTRPインジケータ(TRPI)フィールド
・ TRPI = 0：第1のビットフィールドが有効である、
・ TRPI = 1：第2のビットフィールドが有効である、
・ TRPI = 2：第1および第2のビットフィールドの両方が有効である。
・ TRP #1に関連付けられた、パラメータ1用の第1のビットフィールド、
・ TRP #1に関連付けられた、パラメータ2用の第1のビットフィールド、
・ ...
・ TRP #1に関連付けられた、パラメータN用の第1のビットフィールド、
・ TRP #2に関連付けられた、パラメータ1用の第2のビットフィールド、
・ TRP #2に関連付けられた、パラメータ2用の第2のビットフィールド、
・ ...
・ TRP #2に関連付けられた、パラメータN用の第2のビットフィールド。

【0090】

TRPIは、PUSCHが1つのTRPのみにスケジュールされている場合、WD22が第1または第2のビットフィールドの解析をスキップすることを可能にする。

【0091】

ジョイント符号化を用いた単一ビットフィールドが所与のパラメータについて両方のTRPに用いられる場合、TPRIはまた、TRP#1、TRP#2、または両方のTRPのいずれが適用可能か、すなわち、表1のどの1つ以上の列を用いるべきかを示す際に用いることができる。

【0092】

いくつかの実施形態では、PUSCHがTRP#1、TRP#2、または両方のTRPのいずれに送信されるかは、フィールド内の予約済みまたは予約されていないコードポイントインジケーションを用いて暗示される。所与のTRPに関連づけられたビットフィールドが無効化されていることを示すために、そのビットフィールドのいくつかのコードポイントが予約されてもよく、予約されたコードポイントがそのビットフィールドで示される場合、その特定のビットフィールドは無効化されている(すなわち、そのビットフィールドに対応するTRPに向かうPUSCH送信がない)。

【0093】

例示的な一実施形態では、SRIフィールドが、予約済みのコードポイントにマッピングされているSIRがないことを示す少なくとも1つの予約済みコードポイントを含むことができる。PUSCHがTRP#1のみに向けて送信されることを示す以下の第1の例を考える。
・ TRP #1に関連づけられた、SRI用の第1のビットフィールドは、1つ以上のSRIにマッピングされている予約されていないコードポイントを示す。これは、SRI用の第1のビットフィールドが有効化され、TRP #1へのPUSCH送信があることを意味する。
・ TRP #2に関連づけられた、SRI用の第2のビットフィールドは、どのSRIにもマッピングされていない予約済みコードポイントを示す。これは、SRI用の第2のビットフィールドが無効化され、TRP #2へのPUSCH送信がないことを意味する。

【0094】

以下に示す第2の例において、PUSCHはTRP #2”に向けて送信される。
・ TRP #1に関連づけられた、SRI用の第1のビットフィールドは、どのSRIにもマッピングされていない予約済みコードポイントを示す。これは、SRI用の第1のビットフィールドが無効化され、TRP #1へのPUSCH送信がないことを意味する。
・ TRP #2に関連づけられた、SRI用の第2のビットフィールドは、1つ以上のSRIにマッピングされている予約されていないコードポイントを示す。これは、SRI用の第2のビットフィールドが有効化され、TRP #2へのPUSCH送信があることを意味する。

【0095】

以下に示す第3の例において、PUSCHはTRP #1およびTRP #2の両方に向けて送信される。
・ TRP #1に関連づけられた、SRI用の第1のビットフィールドは、1つ以上のSRIにマッピングされている予約されていないコードポイントを示す。これは、SRI用の第1のビットフィールドが有効化され、TRP #1へのPUSCH送信があることを意味する。
・ TRP #2に関連づけられた、SRI用の第2のビットフィールドは、1つ以上のSRIにマッピングされている予約されていないコードポイントを示す。これは、SRI用の第2のビットフィールドが有効化され、TRP #2へのPUSCH送信があることを意味する。

【0096】

いくつかの実施形態では、SRIフィールドが無効化されれていれば、対応するTPMIフィールドおよび/またはTPCフィールドも無効化される。

【0097】

別の例示的な実施形態においてTPMIフィールドは、予約済みコードポイントにマッピングされているTPMIがないことを示す少なくとも1つの予約済みコードポイントを含みうる。PUSCHがTRP#1のみに向けて送信されることを示す以下の第1の例を考える。
・ TRP #1に関連づけられた、TPMI用の第1のビットフィールドは、1つ以上のTPMIにマッピングされている予約されていないコードポイントを示す。これは、TPMI用の第1のビットフィールドが有効化され、TRP #1へのPUSCH送信があることを意味する。
・ TRP #2に関連づけられた、TPMI用の第2のビットフィールドは、どのTPMIにもマッピングされていない予約済みコードポイントを示す。これは、TPMI用の第2のビットフィールドが無効化され、TRP #2へのPUSCH送信がないことを意味する。

【0098】

以下に示す第2の例において、PUSCHはTRP #2に向けて送信される。
・ TRP #1に関連づけられた、TPMI用の第1のビットフィールドは、どのTPMIにもマッピングされていない予約済みコードポイントを示す。これは、TPMI用の第1のビットフィールドが無効化され、TRP #1へのPUSCH送信がないことを意味する。
・ TRP #2に関連づけられた、TPMI用の第2のビットフィールドは、1つ以上のTPMIにマッピングされている予約されていないコードポイントを示す。これは、TPMI用の第2のビットフィールドが有効化され、TRP #2へのPUSCH送信があることを意味する。

【0099】

以下に示す第3の例において、PUSCHはTRP #1およびTRP #2の両方に向けて送信される。
・ TRP #1に関連づけられた、TPMI用の第1のビットフィールドは、1つ以上のTPMIにマッピングされている予約されていないコードポイントを示す。これは、TPMI用の第1のビットフィールドが有効化され、TRP #1へのPUSCH送信があることを意味する。
・ TRP #2に関連づけられた、TPMI用の第2のビットフィールドは、1つ以上のTPMIにマッピングされている予約されていないコードポイントを示す。これは、TPMI用の第2のビットフィールドが有効化され、TRP #2へのPUSCH送信があることを意味する。

【0100】

いくつかの実施形態では、TPMIフィールドが無効化されれていれば、対応するSRIフィールドおよび/またはTPCフィールドも無効化される。

【0101】

別の例示的な実施形態においてTPCフィールドは、予約済みコードポイントにマッピングされているTPCがないことを示す少なくとも1つの予約済みコードポイントを含みうる。PUSCHがTRP#1のみに向けて送信されることを示す以下の第1の例を考える。
・ TRP #1に関連づけられた、TPC用の第1のビットフィールドは、1つ以上のTPCにマッピングされている予約されていないコードポイントを示す。これは、TPC用の第1のビットフィールドが有効化され、TRP #1へのPUSCH送信があることを意味する。
・ TRP #2に関連づけられた、TPC用の第2のビットフィールドは、どのTPCにもマッピングされていない予約済みコードポイントを示す。これは、TPC用の第2のビットフィールドが無効化され、TRP #2へのPUSCH送信がないことを意味する。

【0102】

以下に示す第2の例において、PUSCHはTRP #2に向けて送信される。
・ TRP #1に関連づけられた、TPC用の第1のビットフィールドは、どのTPCにもマッピングされていない予約済みコードポイントを示す。これは、TPC用の第1のビットフィールドが無効化され、TRP #1へのPUSCH送信がないことを意味する。
・ TRP #2に関連づけられた、TPC用の第2のビットフィールドは、1つ以上のTPCにマッピングされている予約されていないコードポイントを示す。これは、TPC用の第2のビットフィールドが有効化され、TRP #2へのPUSCH送信があることを意味する。

【0103】

以下に示す第3の例において、PUSCHはTRP #1およびTRP #2の両方に向けて送信される。
・ TRP #1に関連づけられた、TPC用の第1のビットフィールドは、1つ以上のTPCにマッピングされている予約されていないコードポイントを示す。これは、TPC用の第1のビットフィールドが有効化され、TRP #1へのPUSCH送信があることを意味する。
・ TRP #2に関連づけられた、TPC用の第2のビットフィールドは、1つ以上のTPCにマッピングされている予約されていないコードポイントを示す。これは、TPC用の第2のビットフィールドが有効化され、TRP #2へのPUSCH送信があることを意味する。

【0104】

いくつかの実施形態では、TPCフィールドが無効化されれていれば、対応するSRIフィールドおよび/またはTPCフィールドも無効化される。

【0105】

予約済みコードポイントフィールドに関する先のの実施形態は、1つのフィールドが2つのTRPに対応するパラメータを合同で示すために用いられる場合にも拡張することができる。一例を以下の表2に示す。
以下の例において、コードポイント0はTRP #1のみへのPUSCH送信に対応する。コードポイント1はTRP #2のみへのPUSCH送信に対応する。コードポイント2はTRP #1および#2へのPUSCH送信に対応する。

【表2】

【0106】

いくつかの実施形態では、予約済みのコードポイントを使用する代わりに、各フィールドに追加ビットが含まれうる。そのビットが第1の値に設定されている場合、そのフィールドの残りが無効化され、対応するTRPへのPUSCH送信が無効化される。そのビットが第2の値に設定されている場合、そのフィールドの残りが有効化され、対応するTRPへのPUSCH送信が有効化される。

【0107】

いくつかの例は、以下を含みうる。
1. 第1のTRPと第2のTRPとWD22とを有する無線ネットワークにおいて、同一のDCIフォーマットを用いて単一TRPおよびマルチTRP PUSCHスケジューリングを動的に切り替える方法であって、
ネットワークノード16により、前記第1および前記第2のTRPにそれぞれ関連づけられた第1および第2のSRSリソースセットを用いてWD22を設定することと、
TRPインジケータ(TRPI)に加え、第1および第2のSRSリソースインジケータ(SRI)と、第1および第2の送信プリコーディング行列インジケータと(TPMI)と、インジケータと、第1および第2の送信電力制御コマンド(TPC)との少なくとも1つを含むDCIによって、PUSCH送信をスケジュールすることと、
前記TRPI、前記第1および第2のSRI、TMPI、およびTPCに従って、前記PUSCHを第1のTRP、第2のTRP、または前記第1および前記第2のTRPの両方に送信することと、を有する、方法。

【0108】

2. 前記TRPIが、前記第1、前記第2、または前記第1および前記第2の両方の、SRI、TMPI、およびTPCのいずれが、前記PUSCHに適用可能であるかを示す、例1の方法。

【0109】

3. 例1の方法であって、前記TRPIが、
・ TRPI = 0：前記第1のSRI、TMPI、およびTPCが有効化され、適用可能である、
・ TRPI = 1：前記第2のSRI、TMPI、およびTPCが有効化され、適用可能である、
・ TRPI = 2：前記第1および前記第2の両方のSRI、TMPI、およびTPCが有効化され、適用可能である、と符号化されうる、方法。

【0110】

4. 前記TRPIは、DCIにおいて独立したビットフィールドにある、1の方法。

【0111】

5. 前記第1および前記第2のSRI、TMPI、およびTPCは、前記DCIにおいて異なるビットフィールドにある、1の方法。

【0112】

6. 前記第1および前記第2のSRI、TMPI、およびTPCが、前記DCIにおける単一ビットフィールドに合同で符号化される、例1の方法。

【0113】

7. 前記TRPIが、前記SRI、TPMI、およびTPCフィールドの1つ以上におけるコードポイントである、例1の方法。

【0114】

一態様によれば、ネットワークノード16は、無線機器(WD)と通信するように構成される。ネットワークノード16は、第1の送信/受信ポイント(TRP)に関連づけられた第1のサウンディング基準信号(SRS)セットと、第2のTRPに関連づけられた第2のSRSとを用いてWD22を設定し、WD22を、前記第1のTRPまたは前記第2のTRPへ、あるいは前記第1のTRPと第2のTRPとの両方へ、物理アップリンク共有チャネル(PUSCH)送信をスケジュールするように設定する、ように構成された、無線インタフェース62を含み、および/またはそのように構成された処理回路68を有する。

【0115】

この態様によれば、いくつかの実施形態において前記WD22は、1つ以上の前記TRPのどれが前記WD22から前記PUSCHを受信すべきかを前記WD22に示すダウンリンク制御情報(DCI)のフィールドによって前記PUSCHをスケジュールするようにさらに構成される。いくつかの実施形態では、前記PUSCHをスケジュールする前記DCIが、前記1つ以上のTRPの各々に対するサウンディング基準信号リソースインジケータ(SRI)を含む。いくつかの実施形態では、前記PUSCHをスケジュールする前記DCIが、前記1つ以上のTRPの各々に対する送信プリコーダ行列インジケーション(TPMI)を含む。いくつかの実施形態では、前記PUSCHをスケジューリングする前記DCIが、前記1つ以上のTRPの各々に対する送信電力制御(TPC)コマンドを含む。いくつかの実施形態では、TRPインジケータ(TRPI)が、前記SRI、前記TPMI、および/または前記TPCの1つ以上におけるコードポイントである。

【0116】

別の態様によれば、ネットワークノード16において実施される方法は、第1の送信/受信ポイント(TRP)に関連付けられた第1のサウンディング基準信号(SRS)セットと、第2のTRPに関連付けられた第2のSRSとを用いてWD22を設定することと、前記WD22を、前記第1のTRPまたは前記第2のTRPへ、あるいは前記第1のTRPと第2のTRPの両方へ、物理アップリンク共有チャネル(PUSCH)送信をスケジュールするように設定することと、を含む。

【0117】

この態様によれば、いくつかの実施形態において前記WD22は、1つ以上の前記TRPのどれが前記WD22から前記PUSCHを受信すべきかを前記WD22に示すダウンリンク制御情報(DCI)のフィールドによって前記PUSCHをスケジュールするようにさらに構成される。いくつかの実施形態では、前記PUSCHをスケジュールする前記DCIが、前記1つ以上のTRPの各々に対するサウンディング基準信号リソースインジケータ(SRI)を含む。いくつかの実施形態では、前記PUSCHをスケジュールする前記DCIが、前記1つ以上のTRPの各々に対する送信プリコーダ行列インジケーション(TPMI)を含む。いくつかの実施形態では、前記PUSCHをスケジューリングする前記DCIが、前記1つ以上のTRPの各々に対する送信電力制御(TPC)コマンドを含む。いくつかの実施形態では、TRPインジケータ(TRPI)が、前記SRI、前記TPMI、および/または前記TPCの1つ以上におけるコードポイントである。

【0118】

さらに別の態様によれば、WD22は複数のネットワークノード16と通信するように構成され、前記WD22は、物理アップリンク共有チャネル(PUSCH)送信を送信するための1つ以上の送信/受信ポイント(TRP)を選択するように構成され、および/またはそのように構成された無線インタフェース82および/または処理回路84を有し、前記TRPはネットワークノード16から受信されたダウンリンク制御情報(DCI)に従って選択される。

【0119】

この態様によれば、いくつかの実施形態において、前記WD22、無線インタフェース82、および/または処理回路84は、サウンディング基準信号インジケータ(SRI)、送信プリコーダ行列インジケータ(TPMI)、および/または送信電力制御(TPC)コマンドの異なる1つを、選択されたTRPのそれぞれに送信するようにさらに構成される。いくつかの実施形態では、前記WD22による送信が第1のTRP、第2のTRP、または第1および第2のTRPの両方のいずれへの送信かを、前記DCIが選択する。

【0120】

別の態様によれば、無線機器(WD)22において実施される方法は、物理アップリンク共有チャネル(PUSCH)送信を送信するための1つ以上の送信/受信ポイント(TRP)を選択することを含み、前記TRPは、ネットワークノード16から受信されたダウンリンク制御情報(DCI)に従って選択される。

【0121】

この態様によれば、いくつかの実施形態では、前記方法が、サウンディング基準信号インジケータ(SRI)、送信プリコーダ行列インジケータ(TPMI)、および/または送信電力制御(TPC)コマンドの異なる1つを、選択されたTRPのそれぞれに送信することをさらに含む。いくつかの実施形態では、前記WD22による送信が第1のTRP、第2のTRP、または第1および第2のTRPの両方のいずれへの送信かを、前記DCIが選択する。

【0122】

いくつかの例は、以下の1つ以上を含み得る。
例A1
無線機器22(WD22)と通信するように構成されたネットワークノード16であって、
第1の送信/受信ポイント(TRP)に関連付けられた第1のサウンディング基準信号(SRS)セットと、第2のTRPに関連付けられた第2のSRSとを用いてWD22を設定し、前記WD22を、前記第1のTRPまたは前記第2のTRPへ、あるいは前記第1のTRPと第2のTRPの両方へ、物理アップリンク共有チャネル(PUSCH)送信をスケジュールするように設定する、ように構成され、および/またはそのように構成された無線インタフェース62および/または処理回路68を有する、ネットワークノード16。

【0123】

例A2
前記WD22は、1つ以上の前記TRPのどれが前記WD22から前記PUSCHを受信すべきかを前記WD22に示すダウンリンク制御情報(DCI)のフィールドによって、前記PUSCHをスケジュールするように、前記ネットワークノードによってさらに設定される、例A1のネットワークノード16。

【0124】

例A3
前記PUSCHをスケジューリングする前記DCIが、前記1つ以上のTRPの各々に対するサウンディング基準信号リソースインジケータ(SRI)を含む、例A2のネットワークノード16。

【0125】

例A4
前記PUSCHをスケジューリングする前記DCIが、前記1つ以上のTRPの各々に対する送信プリコーダ行列インジケーション(TPMI)を含む、例A2のネットワークノード16。

【0126】

例A5
前記PUSCHをスケジューリングする前記DCIが、前記1つ以上のTRPの各々に対する送信電力制御(TPC)コマンドを含む、例A2のネットワークノード16。

【0127】

例A6
TRPインジケータ(TRPI)が、前記SRI、前記TPMI、および/または前記TPCの1つ以上におけるコードポイントである、例A2からA5のネットワークノード16。

【0128】

例B1
ネットワークノード16で実施される方法であって、
第1の送信/受信ポイント(TRP)に関連付けられた第1のサウンディング基準信号(SRS)セットと、第2のTRPに関連付けられた第2のSRSとを用いてWD22を設定することと、前記WD22を、前記第1のTRPまたは前記第2のTRPへ、あるいは前記第1のTRPと第2のTRPの両方へ、物理アップリンク共有チャネル(PUSCH)送信をスケジュールするように設定することと、を含む、方法。

【0129】

例B2
前記WD22は、1つ以上の前記TRPのどれが前記WD22から前記PUSCHを受信すべきかを前記WD22に示すダウンリンク制御情報(DCI)のフィールドによって、前記PUSCHをスケジュールするようにさらに設定される、例B1の方法。

【0130】

例B3
前記PUSCHをスケジューリングする前記DCIが、前記1つ以上のTRPの各々に対するサウンディング基準信号リソースインジケータ(SRI)を含む、例B2の方法。

【0131】

例B4
前記PUSCHをスケジュールする前記DCIが、前記1つ以上のTRPの各々に対する送信プリコーダ行列インジケーション(TPMI)を含む、例B2の方法。

【0132】

例B5
前記PUSCHをスケジューリングする前記DCIが、前記1つ以上のTRPの各々に対する送信電力制御(TPC)コマンドを含む、例B2の方法。

【0133】

例B6
TRPインジケータ(TRPI)が、前記SRI、前記TPMI、および/または前記TPCの1つ以上におけるコードポイントである、例B2からB5の方法。

【0134】

例C1
複数のネットワークノード16と通信するように構成された無線機器22(WD22)であって、
物理アップリンク共有チャネル(PUSCH)送信を送信するための1つ以上の送信/受信ポイント(TRP)を選択する、ように構成され、および/または、そのように構成された無線インタフェース82および/または処理回路84を有し、前記TRPはネットワークノード16から受信されるダウンリンク制御情報(DCI)に従って選択される、WD22。

【0135】

例C2
前記WD22、無線インタフェース82、および/または処理回路84は、サウンディング基準信号インジケータ(SRI)、送信プリコーダ行列インジケータ(TPMI)、および/または送信電力制御(TPC)コマンドの異なる1つを、選択されたTRPのそれぞれに送信するようにさらに構成される、例C1のWD22。

【0136】

例C3
前記WD22による送信が第1のTRP、第2のTRP、または第1および第2のTRPの両方のいずれへの送信かを、前記DCIが選択する、例C1のWD22。

【0137】

例D1
無線機器22(WD22)で実施される方法であって、
物理アップリンク共有チャネル(PUSCH)送信を送信するための1つ以上の送信/受信ポイント(TRP)を選択することを有し、前記TRPはネットワークノード16から受信されるダウンリンク制御情報(DCI)に従って選択される、方法。

【0138】

例D2
サウンディング基準信号インジケータ(SRI)、送信プリコーダ行列インジケータ(TPMI)、および/または送信電力制御(TPC)コマンドの異なる1つを、選択されたTRPのそれぞれに送信することをさらに有する、例D1の方法。

【0139】

例D3
前記WD22による送信が第1のTRP、第2のTRP、または第1および第2のTRPの両方のいずれへの送信かを、前記DCIが選択する、例D1のの方法。

【0140】

いくつかの実施形態は、3GPP規格を参照して以下でさらに論じられる。
RAN1#103eでは、NR Rel-17におけるマルチTRPによるPDCCH、PUSCH、およびPUCCHの強化がさらに議論され、いくつかの合意がなされた。多くの詳細がさらに検討される。

【0141】

マルチTRPのためのPDCCH、PUSCH、およびPUCCH拡張に関する様々な設計詳細を開示する。
PDCCHの信頼性向上のために、SFN方式+ Alt1-1をサポートする。
・ 追加検討事項(FFS)：CORESETのためのTCI状態アクティブ化、デフォルトビームへの影響、BFRのためのBFDリソース。
非SFN方式を用いたPDCCH信頼性向上のために、少なくともオプション2+ケース1をサポートする。
・ リンクされたPDCCH候補の最大個数は2つ。
・ FFS：2つのPDCCH候補がBD制限にどのようにカウントされるか、オーバーブッキングに影響がある場合はその影響などの詳細。
・ Alts 1-2 / 1-3 / 2 / 3 から少なくとも1つのAltをダウン選択する。
・ FFS：同じPDCCH候補インデックスに基づく固定ルール、開始CCEに基づくリンクオプション、設定に基づくリンクオプションなど。
・ FFS：ソフト結合を容易にするための追加の制限。
・ FFS：リソースセット内の8を超えるPUCCHリソースに対する暗黙的なPUCCHリソースの決定、"timeDurationForQCL "に対するスケジューリングオフセット、PDCCH-to-PDSCHおよびPDCCH-to-PUSCHに対するアウトオブオーダー/インオーダーの規定、Type-2コードブック用DAI、同じPDSCH/PUSCH/CSI-RS/SRSをスケジュールするためのスロットオフセット、スケジューリングDCI周りのPDSCHのレートマッチング。
・ FFS：DCI format 2_xをサポートするかどうかと、サポート方法。
FFS：DCI format 2をサポートするかどうかと、サポート方法。
非SFN方式およびオプション2+ケース1を用いたPDCCH信頼性向上のために、Alt3(対応するCORESETに関連づけられた2つのSSセット)をサポートする。

【0142】

PDCCHの拡張
前回のRAN1会合では、PDCCHの強化について以下の合意が成立した。
このサブセクションでは、残りの問題を開示する。

【0143】

Alts 1-2 / 1-3 / 2 / 3 および作業前提
このセクションでは、非SFN PDCCH繰り返しのための様々な代替手法/オプションが開示される。

【0144】

Alt.1-2では、CORESETが2つのTCI状態を用いてアクティブ化され、SSセットに関連付けられる。
1つの可能性は異なるPDCCH候補を異なるTCI状態に関連付けることであり、PDCCHは、異なるTCI状態に関連付けられた2つのPDCCH候補において繰り返される。PDCCHのCCEベースのリソース割り当て(REへのマッピング)の既存の方法に起因して、2つのTRPから2つのPDCCH候補を送信する場合、PDCCH間のマッピングはFDMとなるであろう。

【0145】

FR2のマルチTRP拡張でPDCCHをサポートするためには、TDMマッピングが必要であり、これをサポートするためには、PDCCH候補が複数のシンボルで構成されたCORESETの1つのOFDMシンボル内にのみ配置されるように変更する必要がある。この変更は既存のCCEベースのPDCCH割り当てからの大きな逸脱であろう。

【0146】

Alt.1-2では、PDCCHの候補は事実上FDM:edであり、FR2では使用できない。TDMをサポートするために、既存のCCEベースのPDCCHリソース割振りに対する変更が必要となりうる。

【0147】

Alt.1-3では、CORESETが2つのTCI状態を用いてアクティブ化され、2つのSSセットに関連付けられる。1つの可能性は異なるPDCCH候補を異なるTCI状態に関連付け、同じTCI状態を有するPDCCH候補を同じSSセットに割り当てることである。そして、異なるTCI状態またはSSセットに関連付けられた2つのPDCCH候補においてPDCCHが繰り返される。ここでも、PDCCHのCCEベースのリソース割り当ての既存の方法に起因して、2つのTRPから2つのPDCCH候補を送信するためのPDCCH間のマッピングはFDMとなるであろう。関連するSSセットは、周期性／スロットオフセット、スロット内の監視パターンなど、異なる構成を持つ可能性がある。しかしながら、そのような柔軟性の利点は不明である。

【0148】

Alt.1-3では、PDCCHの候補は事実上FDM:edであり、FR2では使用できない。Alt.1-3によって可能になる追加の柔軟性の利点は不明である。

【0149】

Alt.2とAlt.3は、要求される仕様変更がかなり似ている。Alt.2ではSSセットが2つのCORESETに関連付けられることを可能にするために仕様変更が必要であり、Alt.3では2つのSSセットをリンクするために仕様変更が必要である。

【0150】

Alt.3では、2つのリンクされたSSセットが、周期性/スロットオフセットの監視、スロット内の監視パターン、持続時間、および各アグリゲーションレベルに対するPDCCH候補の数に関して異なる構成を有することができる。例えば、1つのSSセットが2つのPDCCH候補を用いて構成され、他のリンクされたSSセットが所与のアグリゲーションレベルのための4つのPDCCH候補で構成される場合、2つのSSセットのPDCCH候補をどのようにリンクするかは、不明瞭な問題となる。

【0151】

別の例では、1つのSSセットが1つの監視機会で構成され、もう1つのSSセットが1スロットで2つの監視機会で構成されている場合、2つのSSセットのPDCCH候補をどのようにリンクするかはまた別の問題である。したがって、あまりにも多くの組合せを扱うことを回避するために、追加の制約が必要とされうる。Alt.2にはこのような不明確な問題はない。

【0152】

しかし、Alt.3の支持が多数派であることから、作業前提を確認する支持があるはずである。

【0153】

非SFN方式とオプション2+ケース1を用いて、すなわちAlt 3 (対応するCORESETに関連付けられた2つのSSセット) をサポートすることによるPDCCH信頼性強化のための作業前提を確認する。

【0154】

リンクされるPDCCH候補の最大数
未解決の問題は、リンクされるPDCCH候補の最大数、すなわちPDCCHの繰り返し数である。ある見解では、PDCCHの2回の繰り返しが基本であり、デフォルトであるべきであるが、メリットが明確に示されるのであれば、WDの能力より高い数を設定することも検討されている。

【0155】

WD22に対してPDCCH繰り返しが有効化される場合、2つのPDCCH候補がリンクされることがデフォルトである。FFS：2つを超える数がリンクされるように設定可能とするかどうか。

【0156】

ブラインドデコード制限
ある3GPP会議において、この議論は、以下の代替案を中心としたものであった。
仮定1：WD22は、個々のPDCCH候補は復号せずに、結合された候補のみを復号する。
仮定2：WD22は、個々のPDCCH候補をデコードする。
仮定3：WD22は、第1のPDCCH候補および結合された候補をデコードする。
仮定4：WD22は、各PDCCH候補を個別に復号し、さらに結合された候補を復号する。

【0157】

仮定1に関する3GPP会議では、WD22が候補を結合する方が処理負荷が高いため、仮定1のBD数を1より多くカウントすることが議論された。しかし、この場合、BDの数は1のままであるため、WD22に対する他の処理要求(実際のブラインドデコード処理以外)も含むようにBDの定義を拡張することはできないかもしれない。したがって、仮定に対するBDの数は、それぞれ1、2、2、および3のままとすることが有用でありうる。

【0158】

それにもかかわらず、PDCCH候補が別の候補とリンクされるとき、PDCCH候補をデコードするために2つのBDをカウントすることがサポートされる。WD22がどの仮定を使用しているかを指定するのか、あるいはWD22の実装のみに委ねるのか、さらに検討する必要があるかもしれない。

【0159】

PDCCHがリンクされた2つのPDCCH候補で構成される場合、PDCCHペアあたり2つのブラインド復号は、WD22のBD制限にカウントされる。

【0160】

PUCCHリソースの決定
前回の会議から、以下の選択肢が考えられる。
Alt 1：(リンクオプションに基づく)同じ開始CCEインデックスと同じ数のCCEが(CORESET構成の制約に基づく)2つのCORESETに含まれるようにする
Alt 2：リンクされたPDCCH候補の1つのCORESET内の開始CCEインデックスとCCE数が適用される
FFS：リンクされたPDCCH候補のどれを用いるか。
Alt 3：リンクされた2つのPDCCH候補のいずれかの開始CCEインデックスとCORESET内のCCE数に基づいてPUCCHリソースを決定することをWD22に任せる。
他の選択肢を排除しない。

【0161】

現在、PUCCHリソースの第1のセットにおけるPUCCHリソースの数R_PUCCHが8より大きい場合、WD22は、HARQ-ACK情報を搬送するために、インデックスr_PUCCH、0 ≦ r_PUCCH ≦ R_PUCCH-1を有するPUCCHリソースを次のように決定する。

【数2】

ここで、N_CCE,Pは同一スロット内でWDがPUCCH送信で受信したDCIのうち、最後のDCIが受信されたCORESET_pのCCE数であり、n_CCE,PはPDCCH受信の最初のCCEのインデックスであり、Δ_PRIは最後のDCIのPUCCHリソースインジケータフィールドの値である。

【0162】

リンクされた2つのPDCCH候補の場合、2つのPDCCH候補に対する最初のCCEのインデックスは異なるのが一般的である。これら2つのPDCCHが異なる2つのCORESETにある場合、2つのCORESETのCCEの数も異なることがある。

【0163】

Alt.1では、2つのCORESETSに同数のCCEが必要であり、これは合理的でありうる。加えて、リンクされたPDCCH候補はまた、同じ開始CCEインデックスを有する必要があり、これは、PDCCH候補とCCEとの間の新しいマッピングを必要とする。

【0164】

Alt.3では、WDの実装によっては、2つの異なるPUCCHリソースが異なるWD22によって選択される可能性があり、その場合gNBは2つのPUCCHリソースでブラインド検出を実行する必要があるため望ましくない可能性があり、またPUCCHリソースを浪費する。

【0165】

Alt.2では、PUCCHリソースがリンクされたPDCCH候補の1つの第1のCCEインデックスと、対応するCORESETのCCEの数とに基づいている。これはより柔軟であり、PDCCH候補マッピングの変更を必要としない。判定に用いられるPDCCH候補は、controlResourceSetIdが最小のCORESET内のものであってもよいし、リンクされたSSセットの中でsearchSpaceIdが最小のSSセット内のものであってもよい。

【0166】

提案
Alt.2をサポートし、controlResourceSetIdが最小のCORESET、またはリンクされたSSセットの中でsearchSpaceIdが最小のSSセット内でリンクされたPDCCH候補の1つを用いる。

【0167】

PDCCH検出時間基準
別の未解決の問題は、以下のFFS項目で述べるように、スケジューリングオフセットの決定においてPDCCH検出時間をどのように規定するかである。
FFS：リソースセット内の8を超えるPUCCHリソースに対する暗黙的なPUCCHリソースの決定、"timeDurationForQCL "に対するスケジューリングオフセット、PDCCH-to-PDSCHおよびPDCCH-to-PUSCHに対するアウトオブオーダー/インオーダーの規定、Type-2コードブック用DAI、同じPDSCH/PUSCH/CSI-RS/SRSをスケジュールするためのスロットオフセット、スケジューリングDCI周りのPDSCHのレートマッチング。

【0168】

WD22が適切な動作を決定するためにPDCCHの最後のシンボルを用いるいくつかのシナリオが存在する。例の一部は以下を含む。
アウトオブオーダー検出のために「所与のスケジュール済みセル内の任意の2つのHARQプロセスIDについて、WDがシンボルiで終了するPDCCHによってシンボルjで開始する最初のPDSCHの受信を開始するようにスケジュールされている場合、WDはシンボルiよりも後に終了するPDCCHにより、最初のPDSCHの終了よりも早く開始するPDSCHを受信するようにスケジュールされることを想定しない」。

【0169】

現在、DCIによってスケジュールされたすべてのPDSCHについて、WD22は、DCIの受信と対応するPDSCHとの時間オフセットが閾値timeDurationForQCLに対して小さいか、等しいか、大きいかを判定する。
そして、判定結果に応じて、WD22は異なるアクションを取りうる。

【0170】

DCIによる非周期的CSI-RSトリガについて、WD22は、トリガするDCIを搬送するPDCCHの最後のシンボルと、上位レイヤパラメータtrs-Infoなしで設定されたNZP-CSI-RS-ResourceSet内の非周期的CSI-RSリソースの最初のシンボルとのスケジューリングオフセットが、閾値beamSwitchTiming＋d・2^μCSIRS/2^μPDCCHに対して小さいか、等しいか、大きいかを判定する。
そして、判定結果に応じて、WD22は異なるアクションを取りうる。

【0171】

PUSCHスケジューリングの場合、「WDは、シンボルiの終了がシンボルjの開始の少なくともN₂シンボル前でなければ、同じサービングセル上のシンボルjで開始する、[3GPP TS 38.321]に従った設定グラントでWDがPUSCHを送信することを許可されている送信機会と時間的に重複する所定のサービングセル上でPUSCHを送信するために、シンボルiで終了するPDCCHによってスケジューリングされることを想定しない。」

【0172】

したがって、2つのPDCCH候補によるPDCCH繰り返しのためには、最後のPDCCHシンボルを明確に規定する必要がある。ある見解では、最後のシンボルは、図14に示すように、リンクされたPDCCH候補のうち、時間的に後に発生するPDCCH候補(または関連する監視機会)の最後のシンボルであるべきである。

【0173】

図14は、リンクされたPDCCH候補の最後のシンボルを、PDCCHの終わりとして規定する提案である。

【0174】

WDが実際にどの(1つ以上の)PDCCH候補を検出したかに関わらず、リンクされたPDCCH候補のペアのうち、時間的に最も遅れて発生するPDCCHシンボルを最後のシンボルと規定する。

【0175】

タイプ2HARQコードブックのためのDAI
別の問題は、PDCCH繰り返しの場合に、タイプ2のHARQ Ackコードブックをどのように構築するかである。タイプ2のHARQ-ACKコードブックでは、HARQ-ACK情報ビットの順序付けと、おこりうる(1つ以上の)DCIの欠落検出とに、DCIのカウンタDAIと合計DAIが用いられる。カウンタDAIの値は、現在のサービングセルcおよび現在のPDCCH監視機会mまでに、DCIに関連する(1つ以上の)PDSCH受信またはSPS PDSCHリリースが存在する｛サービングセル、PDCCH監視機会｝-(1つ以上の)ペアの累積数を示す。合計DAIの値は、現在のPDCCH監視機会mまでに、DCIに関連する(1つ以上の)PDSCH受信またはSPS PDSCHリリースが存在する｛サービングセル、PDCCH監視機会｝-(1つ以上の)ペアの総数を示し、PDCCH監視機会ごとに更新される。

【0176】

PDCCHの繰り返しの場合、カウンタDAIはPDCCHの最初の送信時(すなわち、最初のPDCCH監視機会m1における最初のPDCCH機会)のみインクリメントされ、PDCCHの繰り返し(すなわち、2番目のPDCCHモニタリング機会m2における2番目のPDCCH機会、ここでm2≧m1）においても同じDAI値が使用されることが論理的である。

【0177】

したがって、HARQ-ACKの位置は、PDCCHが第1のPDCCHまたは/および第2のPDCCHのいずれで検出されたかに関係なく、PDCCH監視機会における第1のPDCCH機会m1に基づいて決定されるべきである。タイプ2HARQ-ACKコードブックを構築するために、対応するDCIにカウンタDAIフィールドを持つすべての検出されたPDCCHについて、最初のPDCCH機会および関連するPDCCH監視機会を特定する必要がある。そして、HARQ-ACKコードブック構築のための既存の手順は、PDCCH繰り返しの場合、第1のPDCCH機会に対してのみ適用される。

【0178】

DAIカウンタDAIはPDCCH候補のリンクされたペアにおいて、PDCCHが最初に送信されるとき(すなわち、第1のPDCCH機会)にのみインクリメントされる。

【0179】

タイプ2のHARQ-ACKコードブック構築のための既存の手順は、PDCCHが最初のPDCCHまたは/および2番目のPDCCHのどちらで実際に検出されたかに関係なく、PDCCH繰り返しの場合には最初のPDCCH機会に対してのみ適用される。

【0180】

PDCCH候補のレートマッチング
未解決の問題は、CORESET全体をPDSCHに使用できないように設定していない場合のPDCCH候補のレートマッチングである。この場合、リンクされたPDCCH候補の結合を中心としたレートマッチングをサポートするのは簡単かもしれない。

【0181】

CORESETがPDSCHに利用できないように設定されておらず、PDCCHのペアによってスケジュールされたPDSCHが、PDCCHを含むCORESETのリソースと重複する場合、PDSCHレートマッチングは、リンクされたPDCCH候補と対応するDM-RSの結合(union)を中心に行われる。

【0182】

共通DCIフォーマット2_xのサポート
タイプ1またはタイプ2のCGを有するPUSCHの場合、閉ループ電力制御は、TPSコマンドを受信するためのDCIフォーマット2_2のみに依存することができる。CGはURLLCタイプのトラフィックに使用される可能性が高いので、信頼性のある閉ループ電力制御が必要とされる。同様に、SRSのための閉ループ電力制御も、DCIフォーマット2_3のタイムリーかつ信頼できる復号に依存する。したがって、DCIフォーマット2_2および2_3でもPDCCHの拡張をサポートすることは理にかなっていると思われる。

【0183】

DCIフォーマット2-2/2-3は、マルチTRPベースのPDCCH拡張によってもサポートされる。

【0184】

SFNのための2つのTCI状態でアクティブ化されたCORESETの影響
別の未解決の問題は、2つのTCI状態を用いてCORESETをアクティブ化する方法と、以下のFFS項目で述べるように、CORESETがスロットに最小のCORESET IDを有する場合のデフォルトのTCI状態を決定する方法である。
FFS：CORESETのためのTCI状態アクティブ化、デフォルトビームへの影響、BFRのためのBFDリソース。

【0185】

CORESETに対して2つのTCI状態がアクティブ化され、CORESETがWDによって監視されるスロット内のCORESETの中で最小のCORESET IDを有する場合、1つの疑問は、PDSCHをスケジューリングするスロット内のDL DCI受信とPDSCHとの間の時間オフセットが閾値timeDurationForQCL未満である場合に、PDSCHのデフォルトTCI状態をどのように規定するかということである。2つの可能なオプションがある。すなわち、
オプション1：CORESETについて有効化された2つのTCI状態の1つのみが、PDSCHに対するデフォルトTCI状態として使用される(例えば、アクティブ化MAC CEにおいて指定されるかまたは示されるかのいずれか)。
オプション2：WDによってサポートされる場合、CORESTについてアクティブ化された2つのTCI状態の両方がPDSCHに対するデフォルトTCI状態として用いられる。

【0186】

デフォルトTCI状態は、経路損失RSが設定されていない場合のUL電力制御や、リンク監視RSが設定されていない場合のリンク監視にも用いられることに留意されたい。これらの場合、1つのDL RSのみが必要である。したがって、オプション1が好ましいと思われる。

【0187】

2つのアクティブ化されたTCI状態の1つが、デフォルトTCI状態として使用される。FFS：TCI状態をアクティブ化するMAC CEにおいてそれを指定すもしくは示すかどうか。

【0188】

現在、MAC CEによってCORESETに対して単一のTCI状態のみをアクティブ化することができる。したがって、CORESETに対して2つのTCI状態をアクティブ化するために、新しいMAC CEが必要であるように思われる。

【0189】

CORESETに対して2つのTCI状態をアクティブ化するために、新しいMAC CEが必要である。
スロット内繰り返しvsスロット間繰り返し
PDCCH繰り返しについて、スロット内繰り返しは低遅延のため、URLLCにより適している。スロット間繰り返しでは、2つのPDCCHとスケジュールされたPDSCH/PUSCH間のスロット数が異なるため、スケジュールされた同じPDSCH/PUSCHの2つの異なるスロットでK0/K2は異なるであろう。DCIコンテンツはスロットごとに異なりうるため、いくつかの追加の変更が導入されない限り、ソフト結合はできなくなる。

【0190】

提案：スロット内PDCCH繰り返しを用いたPDCCH拡張の確定をまず検討する。

【0191】

PUSCHの拡張
あるRAN1会合では、PUSCHの拡張について以下の合意が成立した。このサブセクションでは、残っている問題のいくつかを提示する。単一DCIベースのM-TRP PUSCH繰り返し方式では、コードブックベースのPUSCH伝送をサポートし、以下の機能拡張を行う。
・ 2つのSRIのインジケーションをサポート。
・ Alt1：SRIのビットフィールドを拡張する。
・ Alt2：SRIフィールドに変更なし。
・ 2つのTPMIのインジケーションをサポート。
・ 2つのTPMIが示されている場合、両方のTPMIに対して同じレイヤ数が適用される。
・ 2つのTRP間のSRSポート番号は同じであるべきである。
・ FFS：2つのTPMIを示すことの詳細(例えば、1つのTPMIフィールドまたは2つのTPMIフィールド)。
・ SRSリソースセットの最大数を2に増加する。
・ FFS：各SRSリソースセットの構成の詳細(例えば、リソースセット内のSRSリソースの数)。

【0192】

単一DCIベースのM-TRP PUSCH繰り返し方式では、以下の点を考慮して非コードブックベースのPUSCH伝送をサポートする。
・ SRSリソースセットの最大数を2に増加させ、関連するCSI-RSリソースをSRSリソースセットごとに構成可能にする。
・ FFS：繰り返し用の2つのビームを示すための、DCIにおけるSRIフィールドの拡張。
単一DCIベースのM-TRP PUSCH繰り返しタイプBの場合、ビームをマッピングするために少なくとも公称繰り返し(nominal repetitions)が用いられる。
・ 各マッピング方法の詳細と適用性のさらなる検討。
・ スロットの境界をまたぐ公称繰り返しの場合の、スロットベースのビームマッピングのさらなる検討。
PUSCH マルチTRP拡張の場合
・ PUSCHに対するTRPごとの閉ループ電力制御について、「closedLoopIndex」値が異なる場合は以下の選択肢をさらに検討する。
・ オプション1：DCIフォーマット0_1/0_2では単一のTPCフィールドが用いられ、TPC値は両方のPUSCHビームに適用される。
・ オプション2：DCI フォーマット0_1/0_2では単一のTPCフィールドが用いられ、TPC値はスロットの2つのPUSCHビームの1つに適用される。
・ オプション3：DCIフォーマット0_1/0_2で第2のTPCフィールドが追加される。
・ オプション4：DCIフォーマット0_1/0_2では単一のTPCフィールドが用いられ、2つのPUSCHビームのそれぞれに適用される2つのTPC値を示す。
・ FFS：ビーム/電力/周波数変更のための遷移期間。
MTRPへのタイプ1およびタイプ2のCG PUSCH送信の両方をサポートする。
以下の選択肢についてさらに検討する。
・ Alt.1：単一のCG構成
・ 単一CG構成の複数のPUSCH送信機会において、MTPRに向かって送信されるTBの繰り返し。
・ 少なくともコードブックベースのCG PUSCHについては、2つのSRI/TPMIの設定をサポートする。
・ Alt.2：複数のCG構成
・ 1を超えるPUSCH送信機会において、MTRPに向けて送信されるTBの繰り返し(1つ以上の送信機会は1つのCG構成からのものであり、別の1つ以上のPUSCH送信機会は別のCG構成からである)。
・ 1 SRI/TPMIは、CG構成ごとに設定され/示される。
・ Alt.1およびAlt.2について、ビームマッピングの原理、低オーバーヘッドのビーム選択メカニズム、その他の機能強化について、さらなる検討が必要である。
M-TRP PUSCHの信頼性向上のために、マルチDCIに基づくPUSCH送信／繰り返し方式について、以下の点を考慮してさらに議論する。
・ 同じTBが異なるビームで複数のTRPに向かって繰り返され、1つ以上のPUSCHの繰り返しがあるDCIによってスケジュールされ、別の1つ以上のPUSCHの繰り返しが別のDCIによってスケジューリングされる。
・ FFS：タイムライン制限およびビームマッピングに関連する詳細。
・ Rel-15/16のMCS、TBS決定、およびULリソース割り当てに関する変更は、この方式では想定していない。
・ この方式は、単一DCIベースのPUSCH繰り返し方式よりも有利で、同様の方式がm-TRP PDCCHでサポートされていない場合にのみサポートされると考えられる(例えばオプション3)。

【0193】

各社は、次回のRAN1会合でこの方式のサポートを決定するため、シミュレーション結果を提供することが奨励される。3GPP Rel-17におけるマルチDCIベースのPUSCH送信/繰り返し方式のサポートは、RAN1#104-eにおいて決定されうる。

【0194】

単一DCIベースのPUSCHマルチTRP拡張では、PUSCH繰り返しタイプAについて以下のRVマッピングをサポートする。
・ DCIは最初のPUSCH繰り返しの最初のRVを示し、RVパターン(0 2 3 1)は異なるTRPのPUSCH繰り返しに別個に適用され、第2のTRPの開始RVのRVオフセットを設定することが可能である(PDSCH方式4と同じ方式)。
・ FFS：PUSCH繰り返しタイプBに対する同じ方法の再利用。
単一DCIベースのM-TRP PUSCH繰り返しタイプAおよびBについて、さらなる検討はPTRS-DMRS関連付けの拡張を必要とする。
単一DCIベースのM-TRP PUSCH繰り返しタイプAおよびBについて、ULビームのサイクリックマッピングまたはシーケンシャルマッピングのいずれかを設定可能である。
・ サイクリックマッピングのサポートは、繰り返し回数が2より大きい場合のためのオプションWD機能とすることができる。
・ FFS：ハーフハーフマッピングのサポート。
・ FFS：マッピングパターン(必要なビーム切り替えギャップを含む)に関するさらなる考慮。
・ 各社は、詳細を決定するために、さらなるシミュレーション結果を提供することが奨励される。

【0195】

2つのSRIのインジケーション
ある3GPP会合において、2つのSRSリソースセット(TRPごとに1つ)がサポートされること、2つのSRIが導入されること、SRIはそれぞれ2つのSRSリソースセットの1つにおける1つ以上のSRSリソースを示すことが合意された。以下に2つの選択肢を提案する。
Alt1：SRIのビットフィールドを拡張する。
Alt2：SRIフィールドに変更なし。

【0196】

RAN1#103-eでは、2つのSRIをどのように示すかについて2つの異なるアプローチが開示された。
第1のアプローチは、単一のSRIフィールドを維持することと、1つまたは2つのSRIの異なる組み合わせを示すために(すなわち、単一のTRPおよび複数のTRPへの(1つ以上の)PUSCHの送信の動的な切り替えをサポートするために)、単一のSRIフィールドのビット数を増加させることとを含む。
第2のアプローチは、第1のSRIフィールドがTRP1に対応する(すなわち、コードブック／非コードブックPUSCH用の第1のSRSリソースセットからの)(1つ以上の)SRIを示し、第2のSRIフィールドがTRP2に対応する(すなわち、コードブック／非コードブックPUSCH用の第2のSRSリソースセットからの)(1つ以上の)SRIを示すように、DCIに追加のSRIフィールドを導入することを含む。ある見解によれば、2つのSRIを最小限の標準化作業でサポートするために、第1SRIフィールドと第2SRIフィールドの2つのSRIフィールドを指定することは、簡単かつ明解である。

【0197】

コードブック/非コードブックベースのマルチTRP PUSCHの場合、DCIで2つの独立したSRIフィールドをサポートし、第1のSRIフィールドは第1のTRPに対応する(1つ以上の)SRIを示し、第2のSRIフィールドは第2のTRPに対応する(1つ以上の)SRIを示す。

【0198】

2つのTPMIのインジケーション
2つのTPMIをサポートすることが3GPP会合で合意された。未解決の問題は、以下のFFS項目で述べるように、2つのTMPIを示すために、1つまたは2つのTPMIフィールドのどちらをサポートすべきかである。
FFS：2つのTPMIを示すことの詳細(例えば、1つのTPMIフィールドまたは2つのTPMIフィールド)。

【0199】

2つのTPMIを示すための2つのアプローチがある。第1のアプローチは、単一のTPMIフィールドを維持することと、1つまたは2つのTPMIの異なる組み合わせを示すために(すなわち、単一のTRPおよび複数のTRPへの(1つ以上の)PUSCHの送信の動的な切り替えをサポートするために)、単一のTPMIフィールドのビット数を増加させることとを含む。

【0200】

第2のアプローチは第1のTPMIフィールドがTRP1に対応するTPMIを示し、第2のTPMIフィールドがTRP2に対応するTPMIを示すように、DCIに追加のTPMIフィールドを導入することを含む。「2つのTPMIが示されている場合、両方のTPMIに対して同じレイヤ数が適用される」こともRAN1#103eで合意されている。したがって、2つのTPMIフィールドが導入される場合、2つのTPMIフィールドに示されるレイヤの数は同一である必要がある。

【0201】

コードブックベースのマルチTRP PUSCHの場合、DCIで2つの独立したTPMIフィールドをサポートし、第1のTPMIフィールドは第1のTRPに対応するTPMIを示し、第2のTPMIフィールドは第2のTRPに対応するTPMIを示す。第1のTPMIフィールドおよび第2のTPMIフィールドに示されるレイヤの数は同じである。

【0202】

TPCインジケーション
複数のTRPに関連する閉ループ電力制御のために、直近のRAN1会合において以下のオプションが提案された。
オプション1：DCIフォーマット0_1/0_2では単一のTPCフィールドが用いられ、TPC値は両方のPUSCHビームに適用される。
オプション2：DCI フォーマット0_1/0_2では単一のTPCフィールドが用いられ、TPC値はスロットの2つのPUSCHビームの1つに適用される。
オプション3：DCIフォーマット0_1/0_2で第2のTPCフィールドが追加される。
オプション4：DCIフォーマット0_1/0_2では単一のTPCフィールドが用いられ、2つのPUSCHビームのそれぞれに適用される2つのTPC値を示す。

【0203】

オプション1では、同じTPCコマンドが2つのTRPへのPUSCH送信に適用される。これは2つのTRPがWDに対して同じ経路損失を有し、同じ受信器雑音およびUL干渉レベルを有することを前提としている。これはいくつかのシナリオには該当しうるが、すべてのシナリオに該当するわけではない。

【0204】

オプション2では、2つのTRPの一方へのPUSCH送信のみにTPCコマンドが適用され、他方のTRPには閉ループ電力制御が適用されない。これは、時間が経つにつれて、他方へのTRPへの送信電力がドリフトし、望ましい受信目標から大きく逸脱する可能性があることを意味する。

【0205】

オプション3：第2のTRP用に第2のTPCフィールドが追加される。したがって、両方のTRPを独立して電力制御することができる。このオプションはより柔軟であり、標準化労力は最小である。

【0206】

オプション4では、TRPごとに1つずつの2つのTPCコマンドを示すために単一のTPCフィールドが用いられる。各TPCに2ビットが割り当てられる場合は同じ機能を持つが、フィールドサイズを小さくして1ビットのフィールドを持つことを目標とする場合、フィールドサイズと電力制御ステップ数の間に何らかのトレードオフが必要となる。

【0207】

4つの選択肢を比較し、2つのSRIとTPMIをサポートすることに関する上述の検討を踏まえると、オプション3が好ましいかもしれない。

【0208】

PUSCHに対するTRPごとの閉ループ電力制御について、オプション3は、第2のTPCフィールドがDCIフォーマット0_1/0_2で追加される場合にサポートされる。

【0209】

単一TRPとマルチTRPとの動的切り替え
いくつかのシナリオでは、WDは異なるタイプのトラフィック(すなわち、URLLCトラフィックとeMBBトラフィック)を用いてサービスされうる。これらのシナリオでは、マルチTRPベースのPUSCH送信と単一TRPベースのPUSCH繰り返しとの間の動的切り替え(すなわち、スケジュールされたPUSCHごとの)をサポートすることが有益である。同様の原理はNR Rel-16でも使用されており、マルチTRPベースのPDSCH受信とシングルTRPベースのPDSCH受信の動的切り替えがサポートされている。

【0210】

単一TRPおよびマルチTRPへのPUSCH送信の動的切り替えをサポートすべきであり、すなわち、各PUSCH送信は、1つまたは2つのTRPでの受信を目標とする。

【0211】

単一のTRPへのPUSCH送信と2つのTRPへのPUSCH送信との間の動的切り替えは、同じDCIでサポートされるべきであることに留意されたい。単一のTRPへの送信の場合、2つのSRI/2つのTMPI/2つのTPCの1つのみが使用される。この目的のために、DCIが単一のTRPに対するPUSCHであるか、または2つのTRPに対するDCIであるかについての何らかのインジケーションが必要であろう。

【0212】

たとえば、2つのSRIフィールドがサポートされていると仮定すると、単一のTRPへのPUSCH送信を示すために、SRIフィールドの1つは、いずれのSRI値にも関連付けられていない予約済みコードポイントを示しうる。両方のSRIフィールドが、SRI値に関連づけられた予約されていないコードポイントを示す場合、複数のTRPへのPUSCH送信が示される。

【0213】

第1および第2のフィールドを有するTPMIおよびTPCなどの他のTRP固有のパラメータについても、同様の手法を用いることができる。
2つのSRI/TPMIフィールドが、m-TRPに向かうPUSCH繰り返しのためにサポートされる。

【0214】

単一TRPまたは複数TRPへのPUSCH送信を動的に示すために、各SRI/TPMIフィールドは、SRI/TPMIフィールドが無効化されているか否かを示すコードポイントを格納する。

【0215】

TRPからPUSCHへのマッピング
TRPからPUSCHの送信機会へのマッピングについて、前回の会合では以下の作業前提に至った。
単一DCIベースのM-TRP PUSCH繰り返しタイプAおよびBについて、ULビームのサイクリックマッピングまたはシーケンシャルマッピングのいずれかを設定可能である。
サイクリックマッピングのサポートは、繰り返し回数が2より大きい場合のためのオプションWD機能とすることができる。
FFS：ハーフハーフマッピングのサポート。
FFS：マッピングパターン(必要なビーム切り替えギャップを含む)に関するさらなる考慮。
各社は、詳細を決定するために、さらなるシミュレーション結果を提供することが奨励される。

【0216】

サイクリックマッピングについて一部の企業から懸念の声が上がっているのは、切り替えにタイムギャップが必要になる可能性があることである。このために、そのようなギャップが必要かどうかについて、LSがRAN4に送られた。しかし、WDが2回の繰り返しのサイクリック・マッピングをサポートできるのに、なぜ2回以上の繰り返しのサイクリックマッピングをサポートできないのかは、ここで対処する問題である。WDがサイクリックマッピングに対応できるかどうかを判断する上で、繰り返し回数は判断材料にすべきではない。したがって、この作業前提を確認する前に、LSに対するRAN4の応答を待つことが好ましいかもしれない。

【0217】

CGサポートオプション
構成グラントのサポートについて、3GPP会合では以下の2つの選択肢が提案された。
Alt.1：単一のCG構成
単一CG構成の複数のPUSCH送信機会において、MTPRに向かって送信されるTBの繰り返し。
少なくともコードブックベースのCG PUSCHについては、2つのSRI/TPMIの設定をサポートする。
Alt.2：複数のCG構成
1を超えるPUSCH送信機会において、MTRPに向けて送信されるTBの繰り返し(1つ以上の送信機会は1つのCG構成からのものであり、別の1つ以上のPUSCH送信機会は別のCG構成からである)。

【0218】

1 SRI/TPMIは、CG構成ごとに設定され/示される。
Alt.1は動的スケジューリングについての合意の拡張であり、同じTBのためのPUSCHが2つのTRPに向かって繰り返される。これは、同じCG内でTBを送信/再送信する既存のCG構成に沿ったものである。Alt.2では、異なるCGから同じTBを送信/再送信することができる。CG構成の観点からは、これはCG構成の変更を必要としないかもしれない（すなわち、単一のSRI/TPMIが各CGに設定される）。しかしながら、Alt.2は、同じHARQ手順が2つ以上のCGによって共有されることを暗に示している。これは、CGに関する既存のHARQ動作からの逸脱であり、大きな標準化努力を必要としうる。さらに、Alt.2の利点も不明である。したがって、Alt.1のサポートが好ましいであろう。
複数のTRPへのCG PUSCH送信について、Alt.1をサポートする。

【0219】

PUSCH繰り返しタイプBのRVマッピング
3GPP会合では、PUSCH繰り返しタイプAについて、以下のRVマッピングが合意された。
DCIは最初のPUSCH繰り返しの最初のRVを示し、RVパターン(0 2 3 1)は異なるTRPのPUSCH繰り返しに別個に適用され、第2のTRPの開始RVのRVオフセットを設定することが可能である(PDSCH方式4と同じ方式)。

【0220】

PUSCH反復タイプBのRVマッピングに関しては、以下のFFSが捕捉された。
FFS：PUSCH繰り返しタイプBに対する同じ方法の再利用。
1つの見解によれば、同じRVマッピングが両方のPUSCH繰り返しタイプに適用されうる。

【0221】

提案
PUSCH繰り返しタイプBの場合、PUSCH繰り返しタイプAと同じRVマッピング方法を再利用する。

【0222】

マルチDCIベースのPUSCH送信方式
同じTBでありながら2つの異なるTRPをターゲットとするPUSCHのスケジューリングに複数のDCIを使用する利点の1つは、異なるTRPに関連づけられたチャネルに合わせて、異なるPUSCHに対して異なるMCS、リソース割り当て、PMI、レイヤ数を柔軟に選択できることである。しかしながら、3GPP TS 38.214によれば、以下のようなスケジューリング制限がある。
「WDは、所与のHARQ手順について、そのHARQ手順に関する最後のPUSCHの予期される送信が終了するまで、C-RNTIまたはMCS-C-RNTIによってスクランブルされたDCIフォーマット0_0、0_1または0_2によって別のPUSCHを送信するようにスケジュールされることを想定していない。」

【0223】

上述の3GPPの文書では、同じHARQプロセスに対応する次のPUSCHに対するPDCCHの受信は、前のPUSCHが送信されるまで発生しえないことを述べている。図15に、このPUSCHスケジューリング制限の例を示す。図15において、PDCCH1およびPDCCH2は、同じHARQ手順に対応する最初のPUSCHおよび再送信されるPUSCHをスケジュールする。したがって、図15に示すように、PDCCH2がWDによって受信されるのは、PDCCH1によってスケジュールされた最初のPUSCH送信が終了した後であるというのが1つの理解である。したがって、現在のNR仕様では、PUSCHの繰り返しが複数のDCIでスケジュールされる場合、厳しい遅延要件を満たすことは困難である。これは、同じHARQ手順での送信(すなわち、同じHARQ手順で2つのPUSCHを用いて異なるRVで同じTBを送信すること)を含むことに留意されたい。

【0224】

2つの異なるDCIを使用するマルチTRP拡張でのPUSCH繰り返しの場合、厳しい遅延要件を満たすことは困難である。

【0225】

図15は、NR Rel-15/16に規定された制限に従って、同じHARQ手順に対する2つのアップリンクDCIを用いてスケジュールされた2つのPUSCHの送信を示す。

【0226】

URLLCの場合、PUSCHが異なるDCIによってスケジュールされている複数のTRP上で、PUSCHのバックツーバック(再)送信を許すことが有益である。このようにして、信頼性および遅延時間の削減の両方に対処できる。異なるDCIを用いるバックツーバックPUSCH繰り返しを図16に示す。

【0227】

2つの異なるDCIを用いるマルチTRP拡張でのPUSCHの繰り返しについて、複数のTRP上でのPUSCHのバックツーバック(再)送信を許すことが有益である。

【0228】

図16は、異なるDCIを用いるバックツーバックPUSCH繰り返しの例である。
NR Rel-17では、複数のTRP上での複数のDCIによるPUSCH繰り返しのバックツーバックスケジューリングを許可することを検討する。

【0229】

PUSCH上の非周期的CSI
3GPPリリース16までのNRでは、PUSCHが繰り返される場合でも、非周期的CSIレポートはPUSCHに1回だけ多重化される(すなわち、A-CSIが最初のPUSCHでてPUSCHに多重化される)。A-CSIレポートがgNBによって正しく復号されない場合、gNBはレポートを破棄し、別のA-CSIレポートについてWD22をトリガする。TRPに関連づけられたチャネルがブロックされている場合にスロットでWD22がA-CSIを送信すると、A-CSIを十分な品質で受信することができず、gNBでのA-CSIの復号に失敗する場合がある。A-CSIの信頼性を改善するため、異なるTRPをターゲットにして送信される複数のPUSCHにわたってA-CSIを繰り返すことが有益でありうる。

【0230】

A-CSIが1つのPUSCH機会にのみ搬送される場合、WDとTRPとの間のチャネルがブロックされるとA-CSIはgNBによって受信されないことがある。
A-CSIの信頼性を改善するため、NR Rel-17において、異なるTRPに向かう少なくとも2つのPUSCH機会でのA-CSI多重化をサポートする。

【0231】

マルチTRP PUCCH送信方式の場合
・ マルチTRPスロット間繰り返しをサポートする(方式1)。
・ 1つのPUCCHリソースはUCIを搬送し、別のPUCCHリソースまたは別の1つ以上のスロットにおける同じPUCCHリソースは、UCIの繰り返しを搬送する。
・ FFS：繰り返し回数。
・ 以下の(一方または両方)の方式のサポートをさらに検討する。
・ マルチTRPスロット内ビームホッピング(方式2)
・ UCIは1つのPUCCHリソースで送信され、PUCCHリソース内の異なるシンボルセットは異なるビームを持つ。
・ FFS：PUCCHリソースあたり2つを超えるビームホッピングインスタンス。
・ マルチTRPスロット内繰り返し(方式3)
・ 1つのPUCCHリソースはUCIを搬送し、別のPUCCHリソース、またはスロット内の別の1つ以上のサブスロット内の同じPUCCHリソースはUCIの繰り返しを搬送する。
・ 注1：2つのPUCCHリソースをサポートするか、同じPUCCHリソースで方式1と方式3とで異なるビームをサポートするかは、別途検討する。
マルチTRP PUCCH送信方式の場合
・ 方式1については、少なくともPUCCHフォーマット1/3/4を用いることができる。
・ FFS：方式1に対するPUCCHフォーマット0/2のサポート。
・ FFS：方式2および/または方式3に対するPUCCHフォーマットのサポート(方式が合意される場合)。
FR2におけるPUCCH マルチTRP拡張の場合
・ PUCCH空間関係情報を用いて電力制御パラメータを関連付けることにより、異なるTRPに対して個別の電力制御パラメータをサポートする。
・ 注：仕様への影響はない。
・ PUCCHに対するTRPごとの閉ループ電力制御について、2つのPUCCH空間関係情報に関連づけられた「closedLoopIndex」値が異なる場合、TPCコマンドを考慮した以下の選択肢をさらに検討する。
・ オプション1：DCIフォーマット1_1/1_2では単一のTPCフィールドが用いられ、TPC値は両方のPUCCHビームに適用される。
・ オプション2：DCI フォーマット1_1/1_2では単一のTPCフィールドが用いられ、TPC値はスロットの2つのPUCCHビームの1つに適用される。
・ TPC値は、別のスロットで他方のPUCCHビームに対して適用されてもよい。
・ オプション3：DCIフォーマット1_1/1_2で第2のTPCフィールドが追加される。
・ オプション4：DCIフォーマット1_1/1_2では単一のTPCフィールドが用いられ、2つのPUCCHビームのそれぞれに適用される2つのTPC値を示す。
・ FFS：ビーム/電力/周波数変更のための遷移期間。
・ FFS：FR1に対して必要な電力制御の拡張。

【0232】

方式1のPUCCH繰り返し回数の設定/インジケーションについて、繰り返し回数の設定に3GPP Rel-15のフレームワークを用いることに制限はない。
・ 3GPP Rel-17 feMIMOはさらに、RAN1 #104会合における繰り返し回数の動的インジケーションのサポートを追加考慮してもよい。
PUCCHの拡張
あるRAN1会合では、PUCCHの強化について以下の合意が成立した。このサブセクションでは、残りの問題を提示する。
マルチTRP TDM PUCCH送信方式の場合
・ 単一のPUCCHリソースの使用をサポートする。
・ MAC CEを用いてPUCCHリソースごとに最大2つの空間関係情報をアクティブ化することができる。
・ FFS：FR1に対して必要な拡張。
・ FFS：複数のPUCCHリソースの使用。
・ FR1におけるPUCCHマルチTRP拡張の場合
・ 異なるTRPに対する個別の電力制御をサポートする。
・ FFS：PUCCHとTRPとの間の関連付けを規定する方法。
・ FFS：必要な拡張。

【0233】

方式1におけるPUCCHマルチTRP拡張について、PUCCH繰り返しにわたる空間関係情報のサイクリックマッピングまたはシーケンシャルマッピングのいずれかを設定可能である。
・ FFS：異なる切り替えギャップに対するマッピングパターンの適用性。
・ サイクリックマッピングのサポートは、繰り返し回数が2より大きい場合のためのオプションWD機能とすることができる。
・ 注：方式1について、サイクリックマッピングパターンおよびシーケンシャルマッピングパターンは以下の通りである。
・ サイクリックマッピングパターン：第1および第2のビームはそれぞれ第1および第2のPUCCH繰り返しに適用され、同じビームマッピングパターンが残りのPUCCH繰り返しに対しても継続される。
・ シーケンシャルマッピングパターン：第1のビームは第1および第2のPUCCH繰り返しに適用され、第2のビームは第3および第4のPUCCH繰り返しに適用され、以下同様のビームマッピングパターンである。

【0234】

スロット内ビームホッピング
直近の会合でのFFS項目の1つは、スロット内ビームホッピング(方式2)をサポートすべきかどうかである。
以下の(一方または両方)の方式のサポートをさらに検討する。

【0235】

マルチTRPスロット内ビームホッピング(方式2)
UCIは1つのPUCCHリソースで送信され、PUCCHリソース内の異なるシンボルセットは異なるビームを持つ。"
FFS：PUCCHリソースあたり2つを超えるビームホッピングインスタンス。

【0236】

スロット内ビームホッピングでは、異なるビームを用いて、異なるTRPに、異なるセットのシンボルが1つのPUCCHリソースで送信されうる。1つのシナリオでは、周波数ホッピングで同じ周波数を有するシンボルのセットが同じビームに関連付けられうる。この場合、この方式では仕様変更が少ないように見える。しかし、この方式の欠点は、1つのビーム/TRPが完全にブロックされた場合、一般にPUCCHはシンボルの半分では復号できないため、PUCCHが失われることである。さらに、1つのTRPは完了したPUCCH送信にアクセスできないため、両方のTRPから受信したデータがPUCCH復号のために必要である。したがって、gNB側では、生データサンプルを一方のTRPから他方のTRPに転送する必要があり、ネットワーク側の実装の複雑さとバックホール特性に対する厳しい要件に大きな負担がかかる。これらの欠点を考慮すると、スロット内ビームホッピングの利点は、一面では限定的である。

【0237】

一方のTRPから受信したデータはPUCCH復号のために他方のTRPに転送する必要があるため、スロット内ビームホッピングについてはTRPごとの独立した復号は不可能である。
スロット内ビームホッピング(方式2)は、NR Rel-17ではサポートされない。

【0238】

スロット内繰り返し
別の関連する未解決の問題は、スロット内PUCCH繰り返し(方式3)がサポートされるべきかどうかである。

【0239】

マルチTRPスロット内繰り返し(方式3)
1つのPUCCHリソースはUCIを搬送し、別のPUCCHリソース、またはスロット内の別の1つ以上のサブスロット内の同じPUCCHリソースはUCIの繰り返しを搬送する。

【0240】

スロット内PUCCH繰り返しにおいて、PUCCHは、あるスロット内の2つの異なるシンボルセットで繰り返される。2つのPUCCH送信機会の各々は、2つのビームの1つを用いて2つのTRPの1つに送信される。スロット内ビームホッピングの場合とは異なり、この方式では各TRPでPUCCHを復号可能である。従って、gNBでは、各TRPで個別に復号するか、ソフトコーミングによるジョイント復号を行うことができる。さらに重要なことは、一方のビーム/TRPが完全にブロックされても、他方のTRPでPUCCHを復号できることである。

【0241】

スロット内PUCCH繰り返しでは、1つのTRPが完全にブロックされていてもPUCCHを復号することができる。

【0242】

図17は、同じ総シンボル数でスロット内繰り返しと単一のTRPへの送信を比較した評価結果を示す。シミュレーションは30GHzで2つのTRPを用いて行った。任意の所与のスロットにおいて、TRPの1つは、10%の確率で10dBだけブロックされる。PUCCHフォーマット0/1//2/4を評価した。その他のシミュレーションの前提は付録に記載されている。チャネルブロッキングの下では、2つのTRPにわたる繰り返しは同じ総数のシンボルに対して単一のTRPよりもはるかに良好に機能することが分かる。

【0243】

図17は、4GHzの屋内ホットスポットシナリオの下で、2つのTRPにわたる繰り返しを伴うPUCCH性能改善を示す。

【0244】

同じ総シンボル数と異なるPUCCHフォーマットにおいて、スロット内繰り返しによる単一TRPよりも大きな性能向上が観察される。

【0245】

したがって、1つの見解において、スロット内PUCCHの繰り返しはサポートされるべきである。

【0246】

NR Rel-17でのマルチTRPスロット内繰り返し(方式3)のサポート。
スロット間繰り返しのためのPUCCHフォーマット0/2のサポート。
3GPPのある会合では、スロット間PUCCH繰り返しの方式1が合意され、方式1ではPUCCHフォーマット1/3/4がサポートされることになった。1つのFFS項目は、ショートPUCCHフォーマット0/2も方式1においてサポートされるべきかどうかである。別のFFS項目は、方式2および3が合意された場合、方式2および3でどのPUCCHフォーマットをサポートすべきかである。

【0247】

マルチTRP PUCCH送信方式の場合
方式1については、少なくともPUCCHフォーマット1/3/4を用いることができる。
FFS：方式1に対するPUCCHフォーマット0/2のサポート。
FFS：方式2および/または方式3に対するPUCCHフォーマットのサポート(方式が合意される場合)。

【0248】

ショートPUCCHフォーマット0/2は、関連するPDSCHと同じスロットでのHARQ Ackフィードバックを目的としたものである。ある見解では、1つのTRPがブロックされた場合の信頼性を向上させるには、1つまたは2つのシンボルでPUCCHフォーマット0/2のスロット内繰り返しをサポートする方が有用である。

【0249】

スロット内繰り返しの場合、1つのシミュレーション結果は、TRPブロッキングの場合、ショートPUCCHフォーマットとロングPUCCHフォーマットの両方に対して大きな性能利得を達成できることを示している。

【0250】

提案：スロット内繰り返しに対してショートおよびロングPUCCHフォーマットの両方がサポートされる。

【0251】

電力制御
ある3GPP会合において、異なるTRPに対する別個の閉ループ電力制御が2つのTRPへのPUCCH繰り返しについてサポートされることが合意された。DCIフォーマット1_1/1_2における対応するTPCのインジケーション方法に関して、以下のオプションが提案された。

【0252】

オプション1：DCIフォーマット1_1/1_2では単一のTPCフィールドが用いられ、TPC値は両方のPUCCHビームに適用される。
オプション2：DCI フォーマット1_1/1_2では単一のTPCフィールドが用いられ、TPC値はスロットの2つのPUCCHビームの1つに適用される。TPC値は、別のスロットで他方のPUCCHビームに対して適用されてもよい。
オプション3：DCIフォーマット1_1/1_2で第2のTPCフィールドが追加される。
オプション4：DCIフォーマット1_1/1_2では単一のTPCフィールドが用いられ、2つのPUCCHビームのそれぞれに適用される2つのTPC値を示す。

【0253】

オプション1では同じTPCが両方のビーム/TRPに適用されるため、異なるTRPに対する別個の閉ループ電力制御がサポートされるという合意と矛盾する。

【0254】

オプション2では単一のTPCが示されるとともに2つのTRPの一方に適用され、他方のTRPは電力制御されないか、または次のスケジューリング時間に制御される。1つの見解では、これは各TRPのための別個の電力制御のための適切な方法ではない。

【0255】

オプション3およびオプション4の両方において、TRPごとに1つの、2つのTPC値が示される。相違点は、オプション3では2つのTPCフィールドがサポートされ、オプション4では1つのTPCフィールドが用いられることである。両方とも、TRPごとの電力制御を達成することができる。オプション4については、2つのTPC値をどのように共同符号化するか、既存の2ビットのTPCフィールドで十分か、それともそれ以上のビットが必要かについて、さらなる検討が必要である。

【0256】

提案：PUCCHのTRPごとの閉ループ電力制御については、NR Rel-17でオプション3(DCI 1_1/1_2の2つのTPC フィールド)またはオプション4(2つのTPC値を示すTPCフィールドの1つのコードポイント)のいずれかをサポートする。

【0257】

また、直近の会合から以下の2つの関連FFS項目が存在する。
FFS：ビーム/電力/周波数変更のための遷移期間。
FFS：FR1に対して必要な電力制御の拡張。

【0258】

同様の内容がPUCCHにも適用可能であるべきである。FR1の電力制御拡張に関しては、FR1の場合、経路損失RSはPUCCHに対して明示的に設定されない可能性がある、というのが1つの理解である。その場合、デフォルトのRSが用いられる。2つのTRPへのPUCCH繰り返しのためには、デフォルトのRSでは不十分であり、2つの経路損失RSを明示的に設定する必要がある。したがって、WD22は、2つの経路損失RSを追跡する必要がある。

【0259】

TRPからPUCCHへのマッピング
方式1におけるTRPからPUCCHへの送信機会マッピングについては、直近の会合で、サイクリックまたはシーケンシャルの両方のマッピングをサポートするという作業前提に達した。PUSCHと同様に、サイクリックマッピングについても、TRP間の切り替えに必要な時間ギャップについて、一部の企業から懸念の声が上がっていた。そのため、作業前提に以下のような文節が追加された。

【0260】

サイクリックマッピングのサポートは、繰り返し回数が2より大きい場合のためのオプションWD機能とすることができる。
しかし、2回の繰り返しのサイクリックマッピングをサポートできるWD22が、なぜ2回以上の繰り返しのサイクリックマッピングをサポートできないのかについては、その理由が問われるかもしれない。WDがサイクリックマッピングに対応できるかどうかを判断する上で、繰り返し回数は判断材料にすべきではない。

【0261】

前節までの議論に基づき、以下を提案する。
提案１：非SFN方式とオプション2+ケース1を用いて、すなわちAlt 3 (対応するCORESETに関連付けられた2つのSSセット) をサポートすることによるPDCCH信頼性強化のための作業前提を確認する。
提案２：WD22に対してPDCCH繰り返しが有効化される場合、2つのPDCCH候補がリンクされることがデフォルトである。
提案３： PDCCHがリンクされた2つのPDCCH候補で構成される場合、PDCCHペアあたり2つのブラインド復号は、WD22のBD制限にカウントされる。
提案４：Alt.2をサポートし、controlResourceSetIdが最小のCORESET、またはリンクされたSSセットの中でsearchSpaceIdが最小のSSセット内でリンクされたPDCCH候補の1つを用いる。
提案５：WDが実際にどの(1つ以上の)PDCCH候補を検出したかに関わらず、リンクされたPDCCH候補のペアのうち、時間的に最も遅れて発生するPDCCHシンボルを最後のシンボルと規定する。
提案６：DAIカウンタDAIはPDCCH候補のリンクされたペアにおいて、PDCCHが最初に送信されるとき(すなわち、第1のPDCCH機会)にのみインクリメントされる。
提案７：タイプ2のHARQ-ACKコードブック構築のための既存の手順は、PDCCHが最初のPDCCHまたは/および2番目のPDCCHのどちらで実際に検出されたかに関係なく、PDCCH繰り返しの場合には最初のPDCCH機会に対してのみ適用される。
提案８：CORESETがPDSCHに利用できないように設定されておらず、PDCCHのペアによってスケジュールされたPDSCHが、PDCCHを含むCORESETのリソースと重複する場合、PDSCHレートマッチングは、リンクされたPDCCH候補と対応するDM-RSの結合(union)を中心に行われる。
提案９：DCIフォーマット2-2/2-3は、マルチTRPベースのPDCCH拡張によってもサポートされる。
提案１０：CORESETについて有効化された2つのTCI状態の1つのみが、PDSCHに対するデフォルトTCI状態として使用される。FFS：アクティブ化MAC CEにおいて指定されるかまたは示されるかのいずれか
提案１１：スロット内PDCCH繰り返しを用いたPDCCH拡張の確定をまず検討する。
提案１２：コードブック/非コードブックベースのマルチTRP PUSCHの場合、DCIで2つの独立したSRIフィールドをサポートし、第1のSRIフィールドは第1のTRPに対応する(1つ以上の)SRIを示し、第2のSRIフィールドは第2のTRPに対応する(1つ以上の)SRIを示す。
提案１３：コードブックベースのマルチTRP PUSCHの場合、DCIで2つの独立したTPMIフィールドをサポートし、第1のTPMIフィールドは第1のTRPに対応するTPMIを示し、第2のTPMIフィールドは第2のTRPに対応するTPMIを示す。第1のTPMIフィールドおよび第2のTPMIフィールドに示されるレイヤの数は同じである。
提案１４：PUSCHに対するTRPごとの閉ループ電力制御について、オプション3は、第2のTPCフィールドがDCIフォーマット0_1/0_2で追加される場合にサポートされる。
提案１５：単一TRPおよびマルチTRPへのPUSCH送信の動的切り替えをサポートすべきであり、すなわち、各PUSCH送信は、1つまたは2つのTRPでの受信を目標とする。
提案１６：2つのSRI/TPMIフィールドが、m-TRPに向かうPUSCH繰り返しのためにサポートされる。
提案１７：単一TRPまたは複数TRPへのPUSCH送信を動的に示すために、各SRI/TPMIフィールドは、SRI/TPMIフィールドが無効化されているか否かを示すコードポイントを格納する。
提案１８：複数のTRPへのCG PUSCH送信について、Alt.1をサポートする。
提案１９：PUSCH繰り返しタイプBの場合、PUSCH繰り返しタイプAと同じRVマッピング方法を再利用する。
提案２０：NR Rel-17では、複数のTRP上での複数のDCIによるPUSCH繰り返しのバックツーバックスケジューリングを許可することを検討する。
提案２１：A-CSIの信頼性を改善するため、NR Rel-17において、異なるTRPに向かう少なくとも2つのPUSCH機会でのA-CSI多重化をサポートする。
提案２２：スロット内ビームホッピング(方式2)は、NR Rel-17ではサポートされない。
提案２３：NR Rel-17でのマルチTRPスロット内繰り返し(方式3)のサポート。
提案２４：スロット内繰り返しに対してショートおよびロングPUCCHフォーマットの両方がサポートされる。
提案２５：PUCCHのTRPごとの閉ループ電力制御については、NR Rel-17でオプション3(DCI 1_1/1_2の2つのTPC フィールド)またはオプション4(2つのTPC値を示すTPCフィールドの1つのコードポイント)のいずれかをサポートする。

【表3】

【0262】

当業者には理解されるように、本明細書に記載される概念は、方法、データ処理システム、コンピュータプログラム製品、および／または実行可能なコンピュータプログラムを記憶するコンピュータ記憶媒体として実施されうる。したがって、本明細書で説明する概念は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはソフトウェアとハードウェアの側面を組み合わせた実施形態の形態をとることができ、これらはすべて、本明細書では一般に「回路」または「モジュール」と呼ばれる。本明細書に記載される任意のプロセス、ステップ、アクション、および/または機能は、ソフトウェアおよび/またはファームウェアおよび/またはハードウェアで実施されうる、対応するモジュールによって実施されうる、および/または対応するモジュールに関連付けられうる。さらに、本開示は、コンピュータによって実行可能な媒体中に具現化されたコンピュータプログラムコードを有する有形コンピュータ使用可能記憶媒体上のコンピュータプログラム製品の形態をとることができる。ハードディスク、CD-ROM、電子記憶装置、光学記憶装置、磁気記憶装置など、任意の適切な有形コンピュータ可読媒体を利用することができる。

【0263】

本明細書では、方法、システム、およびコンピュータプログラム製品のフローチャート図および/またはブロック図を参照して、いくつかの実施形態を説明する。フローチャート図および/またはブロック図の各ブロック、ならびにフローチャート図および/またはブロック図のブロックの組み合わせは、コンピュータプログラム命令によって実施できることが理解されよう。これらのコンピュータプログラム命令は、(特殊用途コンピュータを作成するための)汎用コンピュータ、特殊用途コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供され、コンピュータまたは他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートおよび/またはブロック図ブロックまたはブロックに指定された機能/動作を実施するための手段を作成するように、機械を生成することができる。これらのコンピュータプログラム命令は、(専用コンピュータを作成するための)汎用コンピュータのプロセッサ、専用コンピュータ、または他のプログラマブルデータ処理装置に提供されて、コンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行される命令がフローチャートおよび/またはブロック図のブロックまたはブロックで指定された機能/動作を実施するための手段を作成するように、装置を作成することができる。

【0264】

これらのコンピュータプログラム命令は、コンピュータ可読メモリ又は記憶媒体に格納することもでき、コンピュータ可読メモリに格納された命令が、フローチャートおよび/またはブロック図のブロックまたははブロックで指定された機能/動作を実施する命令手段を含む製造品を製造するように、コンピュータまたは他のプログラム可能なデータ処理装置に特定の方法で機能するように指示することができる。

【0265】

また、コンピュータプログラム命令は、コンピュータまたは他のプログラマブル装置上で実行される命令がフローチャートおよび/またはブロック図のブロックまたはブロックに指定された機能/動作を実施するためのステップを提供するように、コンピュータまたは他のプログラマブル装置上で一連の動作ステップを実行させてコンピュータ実装プロセスを生成するために、コンピュータまたは他のプログラマブルデータ処理装置にロードすることもできる。

【0266】

ブロックに記載された機能/動作は、動作図に記載された順序から外れて発生し得ることを理解されたい。例えば、連続して示される2つのブロックは、実際には実質的に同時に実行されてもよく、またはブロックが関連する機能に応じて、逆の順序で実行されてもよい。いくつかの図には、通信の主な方向を示すために通信経路に矢印が描かれているが、描かれている矢印とは逆方向に通信が行われる場合もあることを理解されたい。

【0267】

本明細書で説明される概念の動作を実行するためのコンピュータプログラムコードは、Python、Java(登録商標)、またはC++などのオブジェクト指向プログラミング言語で記述されうる。しかしながら、本開示の動作を実行するためのコンピュータプログラムコードはまた、「C」プログラミング言語などの従来の手続き型プログラミング言語で書かれてもよい。プログラムコードは、完全にユーザーのコンピュータ上で実行されてもよいし、一部はユーザーのコンピュータ上で実行されてもよいし、スタンドアロンソフトウェアパッケージとして実行されてもよいし、一部はユーザーのコンピュータ上で実行されてもよいし、一部はリモートコンピュータ上で実行されてもよいし、完全にリモートコンピュータ上で実行されてもよい。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（LAN）またはワイドエリアネットワーク（WAN）を介してユーザーのコンピュータに接続される場合もあれば、(例えば、インターネットサービスプロバイダーを使用してインターネットを介して)外部のコンピュータに接続される場合もある。

【0268】

上記の説明および図面に関連して、多くの異なる実施形態が本明細書に開示されている。これらの実施形態のすべての組合せおよび下位組合せを文字通り説明し図示することは、不当に繰り返しが多く難解であることが理解されよう。したがって、全ての実施形態は、任意の方法および/または組み合わせで組み合わせることができ、図面を含む本明細書は、本明細書に記載される実施形態の全ての組み合わせおよびサブコンビネーション、ならびにそれらを製造および使用する方法および手順に関する完全な書面による説明を構成するものと解釈され、そのような組み合わせまたはサブコンビネーションに対する特許請求の範囲をサポートするものとする。

【0269】

当業者であれば、本明細書で説明する実施形態は、本明細書で先に特に示し説明したものに限定されないことが理解されよう。加えて、反対の言及がない限り、添付図面はすべて縮尺通りではないことに留意されたい。以下の特許請求の範囲から逸脱することなく、上記の教示に照らして様々な修正および変形が可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【手続補正書】

【提出日】2022-12-15

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

無線機器(WD)(22)と通信するように構成されたネットワークノード(16)であって、前記ネットワークノード(16)は処理回路(68)を有し、前記処理回路(68)は、
送信および受信ポイントインジケータ(TRPI)を用いて前記WD(22)を設定し、ここで前記TRPIフィールドは、物理アップリンク共有チャネル(PUSCH)が送信されるべき第1のTRPおよび第2のTRPの一方または両方を示し、前記TRPIフィールドは、前記示される一方または両方についてサウンディング基準信号(SRS)リソースセット内の複数のSRSのどれが有効化されているかを示し、
ダウンリンク制御情報(DCI)を前記WD(22)に送信することによって、前記第1のTRPおよび前記第2のTRPの前記一方または両方に関連づけられた少なくとも1つのPUSCH送信機会における前記WD(22)によるPUSCH送信をスケジュールする、ように構成される、ネットワークノード(16)。

【請求項2】

前記ビットフィールドは少なくとも3つのコードポイントからなり、第1のコードポイントは第1のSRSリソースセットを示し、第2のコードポイントは第2のSRSリソースセットを示し、第3のコードポイントは前記第1および前記第2のSRSリソースセットの両方を示す、請求項1に記載のネットワークノード(16)。

【請求項3】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2のサウンディング基準信号リソースインジケータ(SRI)フィールドを含む、請求項1に記載のネットワークノード(16)。

【請求項4】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信プリコーディング行列インジケータ(TPMI)フィールドを含む、請求項1から3のいずれか1項に記載のネットワークノード(16)。

【請求項5】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信電力制御(TPC)コマンドフィールドを含む、請求項1から4のいずれか1項に記載のネットワークノード(16)。

【請求項6】

前記WD(22)による前記スケジュールされたPUSCH送信が、第1のSRSリソースインジケータ(SRI)、第1の送信プリコーディング行列インジケータ(TPMI)、および第1の送信電力制御(TPC)コマンドに従う、請求項1に記載のネットワークノード(16)。

【請求項7】

無線機器(WD)(22)と通信するように構成されたネットワークノード(16)において実行される方法であって、
送信および受信ポイントインジケータ(TRPI)を用いて前記WD(22)を設定すること(S140)と、ここで前記TRPIフィールドは、物理アップリンク共有チャネル(PUSCH)が送信されるべき第1のTRPおよび第2のTRPの一方または両方を示し、前記TRPIフィールドは、前記示される一方または両方についてサウンディング基準信号(SRS)リソースセット内の複数のSRSのどれが有効化されているかを示し、
ダウンリンク制御情報(DCI)を前記WD(22)に送信することによって、前記第1のTRPおよび前記第2のTRPの前記一方または両方に関連づけられた少なくとも1つのPUSCH送信機会における前記WD(22)によるPUSCH送信をスケジュールすること(S142)と、を有する、方法。

【請求項8】

前記ビットフィールドは少なくとも3つのコードポイントからなり、第1のコードポイントは第1のSRSリソースセットを示し、第2のコードポイントは第2のSRSリソースセットを示し、第3のコードポイントは前記第1および前記第2のSRSリソースセットの両方を示す、請求項7に記載の方法。

【請求項9】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2のサウンディング基準信号リソースインジケータ(SRI)フィールドを含む、請求項7に記載の方法。

【請求項10】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信プリコーディング行列インジケータ(TPMI)フィールドを含む、請求項7から9のいずれか1項に記載の方法。

【請求項11】

前記PUSCH送信をスケジュールする前記DCIが、第1および第2の送信電力制御(TPC)コマンドフィールドを含む、請求項7から10のいずれか1項に記載の方法。

【請求項12】

前記WD(22)による前記スケジュールされたPUSCH送信が、第1のSRSリソースインジケータ(SRI)、第1の送信プリコーディング行列インジケータ(TPMI)、および第1の送信電力制御(TPC)コマンドに従う、請求項7に記載の方法。

【請求項13】

1つ以上のネットワークノード(16)と通信するように構成された無線機器(WD)(22)であって、前記WD(22)は無線インタフェース(82)を有し、前記無線インタフェース(82)は、
前記1つ以上のネットワークノード(16)の1つから、送信および受信ポイントインジケータ(TRPI)の設定を受信し、ここで前記TRPIフィールドは、物理アップリンク共有チャネル(PUSCH)が送信されるべき第1のTRPおよび第2のTRPの一方または両方を示し、前記TRPIフィールドは、前記示される一方または両方についてサウンディング基準信号(SRS)リソースセット内の複数のSRSのどれが有効化されているかを示し、
少なくとも1つのPUSCH送信機会におけるPUSCH送信をスケジュールするように構成されたダウンリンク制御情報(DCI)を受信し、
前記少なくとも1つのPUSCH送信機会の間に、前記スケジュールされたPUSCH送信を、前記第1のTRPおよび前記第2のTRPの前記示された一方または両方に送信する、ように構成される、WD(22)。

【請求項14】

前記ビットフィールドの第1のコードポイントが第1のSRSリソースセットを示し、前記ビットフィールドの第2のコードポイントが第2のSRSリソースセットを示し、前記ビットフィールドの第3のコードポイントが前記第1および前記第2のSRSリソースセットの両方を示す、請求項13に記載のWD(22)。

【請求項15】

前記無線インタフェース(82)が、第1および第2のサウンディング基準信号リソースインジケータ(SRI)の1つ、第1および第2の送信プリコーディング行列インジケータ(TPMI)の1つ、ならびに第1および第2の送信電力制御(TPC)コマンドの1つに従って、前記少なくとも1つのPUSCH送信機会に前記スケジュールされたPUSCHを送信するようにさらに構成される、請求項13に記載のWD(22)。

【請求項16】

前記無線インタフェース(82)が、前記第3のコードポイントによって前記第1および前記第2のSRSリソースセットの両方が示される場合、少なくとも第1の送信機会に第1のサウンディング基準信号リソースインジケータ(SRI)、第1のTPMI、および第1のTPCの1つに従って前記スケジュールされたPUSCHを送信し、(1つ以上の)第2の送信機会に第2のSRI、第2のTPMI、および第2のTPCの1つに従って、前記スケジュールされたPUSCHを送信するようにさらに構成される、請求項14に記載のWD(22)。

【請求項17】

１つ以上のネットワークノード(16)と通信するように構成された無線機器(WD)(22)における方法であって、
前記1つ以上のネットワークノード(16)の1つから、送信および受信ポイントインジケータ(TRPI)の設定を受信すること(S144)と、ここで前記TRPIフィールドは、物理アップリンク共有チャネル(PUSCH)が送信されるべき第1のTRPおよび第2のTRPの一方または両方を示し、前記TRPIフィールドは、前記示される一方または両方についてサウンディング基準信号(SRS)リソースセット内の複数のSRSのどれが有効化されているかを示し、
少なくとも1つのPUSCH送信機会におけるPUSCH送信をスケジュールするように構成されたダウンリンク制御情報(DCI)を受信すること(S146)と、
前記少なくとも1つのPUSCH送信機会において、前記スケジュールされたPUSCH送信を、前記第1のTRPおよび前記第2のTRPの前記示された一方または両方に送信すること(S154)と、を有する、方法。

【請求項18】

前記ビットフィールドの第1のコードポイントが第1のSRSリソースセットを示し、前記ビットフィールドの第2のコードポイントが第2のSRSリソースセットを示し、前記ビットフィールドの第3のコードポイントが前記第1および前記第2のSRSリソースセットの両方を示す、請求項17に記載の方法。

【請求項19】

第1および第2のサウンディング基準信号リソースインジケータ(SRI)の1つ、第1および第2の送信プリコーディング行列インジケータ(TPMI)の1つ、ならびに第1および第2の送信電力制御(TPC)コマンドの1つに従って、前記少なくとも1つのPUSCH送信機会に前記スケジュールされたPUSCHを送信すること、をさらに有する、請求項17に記載の方法。

【請求項20】

前記第3のコードポイントによって前記第1および前記第2のSRSリソースセットの両方が示される場合、少なくとも第1の送信機会に第1のサウンディング基準信号リソースインジケータ(SRI)、第1のTPMI、および第1のTPCの1つに従って前記スケジュールされたPUSCHを送信することと、(1つ以上の)第2の送信機会に第2のSRI、第2のTPMI、および第2のTPCの1つに従って、前記スケジュールされたPUSCHを送信することと、をさらに有する、請求項18に記載の方法。

【国際調査報告】