JP6923085B2 - ビームレポート送受信のための方法及びデバイス - Google Patents

Description

本開示の非限定的かつ例示的な実施形態は、概ね無線通信技術の分野に関し、より具体的には、ビームレポート送信のための方法、端末デバイスおよび装置、ならびにビームレポート受信のための方法、ネットワークノードおよび装置に関する。

ＮＲシステムまたはＮＲネットワークとも呼ばれる、新無線アクセスシステム（Ｎｅｗ ｒａｄｉｏ ａｃｃｅｓｓ ｓｙｓｔｅｍ）は、次世代通信システムである。３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ワーキンググループのＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）＃７１会議で、ＮＲシステムの検討が承認された。ＮＲシステムは、拡張モバイルブロードバンド、大容量マシンタイプ通信、超高信頼性および低遅延通信などの要件が含まれる、テクニカルレポートＴＲ３８．９１３で定義されている全ての使用シナリオ、要件、および展開シナリオに対処する単一のテクニカルフレームワークを目的とし、１００ＧＨｚまでのレンジの周波数が考慮される。

３ＧＰＰ ＲＡＮ１＃９０ｂｉｓ会議で、以下のことが合意された：
非グループ化ベース（ｎｏｎ−ｇｒｏｕｐｉｎｇ ｂａｓｅｄ）のビームレポートでは、次のレポートパラメータがサポートされている：
・ビーム測定のために設定された送信（Ｔｘ）ビームの最大数：Ｋ＝６４
・１つのインスタンス（ｉｎｓｔａｎｃｅ）でレポートされる設定されたＴｘビームの最大数：Ｎ＿ｍａｘ＝２、４、ここで、Ｎ（Ｎ≦Ｎ＿ｍａｘ、Ｎ＝１、２、３、４）ビームのサブセットは、ｇＮＢによって選択され、かつＵＥに示す（シグナリングメカニズムは今後の検討課題である）ことができる。
・１つのレポートインスタンスで複数のビームがレポートされる場合、差分Ｌ１−参照信号受信電力（Ｌ１−ＲＳＲＰ：Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）がレポートされる。参照されるのは、当該レポートインスタンスで最大のＬ１−ＲＳＲＰである。
・ビット幅：１ｄＢのステップサイズで−１４０ｄＢｍ〜−４４ｄＢｍ範囲のＬ１−ＲＳＲＰでは７ビット（Ｌｏｎｇ タームエボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｖｅｄ）と類似）、差分Ｌ１−ＲＳＲＰでは４ビットである。

さらに、３ＧＰＰ ＲＡＮ１＃９０ｂｉｓにおいて、以下のことも合意された：
ビーム管理のためにレポートするＬ１−ＲＳＲＰおよび／またはビームリソースインジケータ（たとえば、チャネル状態情報参照信号（ＣＳＩ−ＲＳ：Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）または同期信号ブロック（ＳＳＢ：Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ Ｂｌｏｃｋ）のインジケータ）では、次のアップリンク（ＵＬ：ｕｐｌｉｎｋ）チャネルがサポートされている：Ｓｈｏｒｔ 物理アップリンク制御チャネル（Ｓｈｏｒｔ ＰＵＣＣＨ（Ｓｈｏｒｔ Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、またはＳ−ＰＵＣＣＨ）、Ｌｏｎｇ ＰＵＣＣＨ（Ｌ−ＰＵＣＣＨ：ｌｏｎｇ−ＰＵＣＣＨ）、および物理アップリンク共有チャネル（ＰＵＳＣＨ：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）。上記のチャネルのビーム管理では、次のレポートタイプがサポートされている：
・周期的−Ｌｏｎｇ ＰＵＣＣＨとＳｈｏｒｔ ＰＵＣＣＨをサポート
・半永続的−Ｌｏｎｇ ＰＵＣＣＨ、Ｓｈｏｒｔ ＰＵＣＣＨ及びＰＵＳＣＨをサポート
・非周期的−ＰＵＳＣＨとＳｈｏｒｔ ＰＵＣＣＨをサポート

ビームレポート以外に、チャネル状態情報（ＣＳＩ）もＬｏｎｇ ＰＵＣＣＨ、Ｓｈｏｒｔ ＰＵＣＣＨ、およびＰＵＳＣＨで送信され得る。したがって、ビームレポートはＣＳＩレポートと衝突する可能性がある。

ＬＴＥシステムでは、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）のような端末デバイスのための１つのスロットに利用可能なＰＵＣＣＨチャネルが１つしかないが、ＮＲシステムでは、ＵＥは、アップリンク制御情報（ＵＣＩ）送信のための同じスロットで、複数のＰＵＣＣＨ、たとえば、Ｓｈｏｒｔ ＰＵＣＣＨ（≦２ビット）＋Ｓｈｏｒｔ ＰＵＣＣＨ（＞２ビット）、またはＳｈｏｒｔ ＰＵＣＣＨフォーマット２＋Ｌｏｎｇ ＰＵＣＣＨフォーマット３をサポートできる。

ビームレポートインスタンスでは、ＵＥは、同時に受信できるＮ個の異なるＴｘビームをレポートするように構成されることができ、ＮはｇＮＢによって設定され、Ｎ≦Ｎｍａｘである。ただし、ＵＥは所定のレポートインスタンスでＮ個以下のビームをレポートする場合があり、これは、実際のレポートペイロードがＵＥのビーム検出に基づいて異なる場合があることを意味する。

既存のソリューションでは、ビームレポートのためのペイロードは、所定のＰＵＣＣＨフォーマットに均一化され、デフォルト値は、停止中のビームＲＳＲＰを量子化するために使用され、追加のパディングビットを使用することができる。このような場合、ビームレポートは、チャネルリソースをレポートすることによって格納されるものよりもはるかに少ない情報ペイロードを搬送することができる。

上記に鑑みて、ビームレポート送信のための改良されたソリューションを必要とする。

本開示は、先行技術における問題の少なくとも一部を軽減または少なくとも緩和するために、ビームレポートのための新しいソリューションを提供することを目的とする。

本開示の第１の態様によれば、ビームレポート送信のための方法が提供される。この方法は、ビームレポートと他のアップリンク制御情報との間の衝突に対応して、前記ビームレポートと前記他のアップリンク制御情報の送信優先度を定義する所定の優先度ルールに基づいて、前記ビームレポートと前記他のアップリンク制御情報のうちの優先度の低い方をドロップすること、を備えてもよい。

本開示の第２の態様によれば、ビームレポート受信のための方法が提供される。この方法は、ビームレポートと他のアップリンク制御情報との間の衝突に対応して、前記ビームレポートと前記他のアップリンク制御情報の送信優先度を定義する所定の優先度ルールに基づいて、前記ビームレポートと前記他のアップリンク制御情報のうちの優先度の高い方を受信すること、を備えてもよい。

本開示の第３の態様によれば、端末デバイスが提供される。この端末デバイスは、ビームレポートと他のアップリンク制御情報との間の衝突に対応して、前記ビームレポートと前記他のアップリンク制御情報の送信優先度を定義する所定の優先度ルールに基づいて、前記ビームレポートと前記他のアップリンク制御情報のうちの優先度の低い方をドロップするように設定されるプロセッサを備えてもよい。

本開示の第４の態様によれば、ネットワークノードが提供される。このネットワークノードは、ビームレポートと他のアップリンク制御情報との間の衝突に対応して、前記ビームレポートと前記他のアップリンク制御情報の送信優先度を定義する所定の優先度ルールに基づいて、前記ビームレポートと前記他のアップリンク制御情報のうちの優先度の高い方を受信するように設定されるプロセッサを備えてもよい。

本開示の第５の態様によれば、端末デバイスが提供される。この端末デバイスは、プロセッサおよびメモリを備えてもよい。メモリは、プロセッサと結合され、プロセッサで実行されると、端末デバイスに第１の態様の動作を実行させるプログラムコードを有してもよい。

本開示の第６の態様によれば、ネットワークノードが提供される。このネットワークノードは、プロセッサおよびメモリを備えてもよい。メモリは、プロセッサと結合され、プロセッサで実行されると、ネットワークノードに第２の態様の動作を実行させるプログラムコードを有してもよい。

本開示の第７の態様によれば、コンピュータプログラムコードが実装されたコンピュータ読み取り可能な記憶媒体が提供され、コンピュータプログラムコードは、実行されると、装置に第１の態様の任意の実施形態にかかる方法における動作を実行させるように設定される。

本開示の第８の態様によれば、コンピュータプログラムコードが実装されたコンピュータ読み取り可能な記憶媒体が提供され、コンピュータプログラムコードは、実行されると、装置に第２の態様の任意の実施形態にかかる方法における動作を実行させるように設定される。

本開示の第９の態様によれば、第７の態様にかかるコンピュータ読み取り可能な記憶媒体を備えるコンピュータプログラム製品が提供される。

本開示の第１０の態様によれば、第８の態様にかかるコンピュータ読み取り可能な記憶媒体を備えるコンピュータプログラム製品が提供される。

本開示の実施形態によれば、衝突に対処するために簡単でありながら効率的なソリューションを提供することができる。

本開示の上記特徴および他の特徴は、添付の図面を参照しつつ実施形態で示され、実施形態の詳細な説明を通してより明らかになる。添付の図面全体において、同じ参照符号は同じまたは類似の構成要素を表す。

本開示の実施形態にかかるビームレポート送信のための方法のフローチャートを概略的に示す。

ビームレポートのためのアップリンクチャネルを概略的に示す。

ＣＳＩレポートのためのアップリンクチャネルを概略的に示す。

本開示の実施形態にかかる、送信優先度を定義するいくつかの例示的な優先度ルールを概略的に示す。 本開示の実施形態にかかる、送信優先度を定義するいくつかの例示的な優先度ルールを概略的に示す。 本開示の実施形態にかかる、送信優先度を定義するいくつかの例示的な優先度ルールを概略的に示す。

本開示の実施形態にかかるビームレポート送信のための別の方法のフローチャートを概略的に示す。

本開示の実施形態にかかる、異なるケースに対応可能なオフロードソリューションのテーブルを概略的に示す。

本開示の実施形態にかかる、ビームレポートおよびＣＳＩレポートのためにＰＵＣＣＨの２つの別個に符号化された部分におけるビーム（ＢＭ）レポートおよびＣＳＩレポートの図を概略的に示す。

本開示の実施形態にかかる、ビームレポートおよびハイブリッド自動再送要求（ＨＡＲＱ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅｑｕｅｓｔ）の多重化戦略のテーブルを概略的に示す。

本開示の実施形態にかかる、ビームレポートおよびＣＳＩレポートのためにＰＵＣＣＨの２つの別個に符号化された部分におけるＢＭレポートおよびＨＡＲＱ送信の図を概略的に示す。

本開示の実施形態にかかるペイロードサイズに基づくビームレポートのリソース選択ルールを概略的に示す。

本開示の実施形態にかかる、レポートされるビームの数に基づくビームレポートのリソース選択ルールを概略的に示す。

本開示の実施形態にかかるビームレポート送信のためのさらなる方法のフローチャートを概略的に示す。

本開示の実施形態にかかる例示的なビームレポートセグメントの図を概略的に示す。

図１３で説明されたソリューションにかかる２つのビームレポートセグメントのペイロードサイズのテーブルを概略的に示す。

本開示の実施形態にかかる２つのビームレポートセグメントの例示的な送信を概略的に示す。

本開示の実施形態に係る２つのビームレポートセグメントの別の例示的な送信を概略的に示す。

本開示の実施形態にかかる２つのビームレポートセグメントのさらなる例示的な送信を概略的に示す。

本開示の実施形態にかかる他の例示的なビームレポートセグメントの図を概略的に示す。

図１８で説明されたソリューションにかかる２つのビームレポートセグメントのペイロードサイズのテーブルを概略的に示す。

本開示の実施形態にかかるさらなる例示的なビームレポートセグメントの図を概略的に示す。

本開示の実施形態にかかる２つのビームレポートセグメントの例示的な送信を概略的に示す。

本開示の実施形態にかかるビームレポート受信のための方法のフローチャートを概略的に示す。

本開示の実施形態にかかるビームレポート受信のための別の方法のフローチャートを概略的に示す。

本開示の実施形態にかかるビームレポート受信のためのさらなる方法のフローチャートを概略的に示す。

本開示の実施形態にかかるビームレポート送信のための装置のブロック図を概略的に示す。

本開示の実施形態にかかるビームレポート受信のための装置のブロック図を概略的に示す。

本明細書で説明される、ｇＮＢのようなネットワークノードとして具現化され又はそれに備えられる装置２７１０、およびＵＥのような端末デバイスとして具現化され又はそれに備えられる装置２７２０の簡略ブロック図を概略的に示す。

以下、本開示で提供されるソリューションは、添付の図面を参照しつつ実施形態を通して詳細に説明する。これらの実施形態は、当業者が本開示をよりよく理解および実施できるようにするためにのみ提示され、本開示の範囲をいかなる方法でも限定することを意図するものではないことが理解される。

添付の図面において、本開示の様々な実施形態は、ブロック図、フローチャート、および他の図で示される。フローチャートまたはブロック図内の各ブロックは、本開示において、特定の論理機能を実行するための１つまたは複数の実行可能命令を含むモジュール、プログラム、またはコードの一部を表すことができ、必ずしも必要ではないブロックを点線で示している。さらに、これらのブロックは、方法のステップを実行するための特定の順序で示されているが、実際には、それらは必ずしも示された順序に厳密に従って実行されなくてもよい。たとえば、それらは逆の順序や同時に実行されてもよく、実行の順序はそれぞれの動作の性質に依存する。なお、ブロック図および／またはフローチャート内の各ブロック、ならびにそれらの組み合わせは、特定の機能／動作を実行するための専用のハードウェアベースのシステムによって、または専用のハードウェアとコンピュータ命令との組み合わせによって実装されてもよいことに留意すべきである。

一般に、特許請求の範囲で使用されるすべての用語は、本明細書で他に明示的に定義されていない限り、その技術分野におけるそれらの通常の意味に従って解釈されるべきである。「１つ（ａ）／１つ（ａｎ）／前記（ｔｈｅ）／この（ｓａｉｄ）［要素、デバイス、コンポーネント、手段、ステップなど］」に対する全ての言及は、特にそうではないと明示的に述べられていない限り、複数のそのようなデバイス、コンポーネント、手段、ユニット、ステップなどを除外するものではなく、少なくとも１つの要素、デバイス、コンポーネント、手段、ユニット、ステップなどの例を指すものとして素直に解釈されるべきである。さらに、本明細書で使用される不定冠詞「１つ（ａ）／１つ（ａｎ）」は、複数のそのようなステップ、ユニット、モジュール、デバイス、およびオブジェクトなどを除外するものではない。

さらに、本開示の文脈において、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）は、端末、モバイル端末（ＭＴ：Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ）、加入者局（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ポータブル加入者局（Ｐｏｒｔａｂｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、移動局（ＭＳ：Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、またはアクセス端末（ＡＴ：Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）を指してもよいし、ＵＥ、端末、ＭＴ、ＳＳ、ポータブル加入者局、ＭＳ、またはＡＴの機能の一部または全てが含まれてもよい。さらに、本開示の文脈では、用語「ＢＳ」は、たとえば、ノードＢ（ＮｏｄｅＢまたはＮＢ）、ｅｖｏｌｖｅｄ ＮｏｄｅＢ（ｅＮｏｄｅＢまたはｅＮＢ）、ｇＮＢ（次世代ＮｏｄｅＢ）、Ｒａｄｉｏ Ｈｅａｄｅｒ（ＲＨ）、Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ（ＲＲＨ）、リレー、またはフェムト、ピコなどの低電力ノードを表してもよい。

本開示では、先行技術における問題の少なくとも一部を軽減または少なくとも緩和することができる、ビームレポート送受信のための新しいソリューションが提案されている。以下、さらに図１から図２７を参照して、本開示で提案されるソリューションを詳細に説明する。以下の実施形態は、例示の目的でのみ提供されるものであり、本開示はそれらに限定されないことが理解される。また、以下では、本開示の異なる態様を別々に説明する場合があるが、これらの態様を組み合わせることもできることが理解される。

まず、本開示の実施形態にかかるビームレポート送信のための方法１００のフローチャートを示す図１を参照する。方法１００は、端末デバイス、たとえば、ＵＥ、または他の同様の端末デバイスで実行されることができる。

図１に示すように、ステップ１０１において、ビームレポートと他のアップリンク制御情報との間の衝突に対応して、ビームレポートと他のアップリンク制御情報の送信優先度を定義する所定の優先度ルールに基づいて、ビームレポートおよび他のアップリンク制御情報のうちの優先度の低い方がドロップされる。

背景技術で述べたように、ビーム管理では、Ｓｈｏｒｔ ＰＵＣＣＨ、Ｌｏｎｇ ＰＵＣＣＨ、およびＰＵＳＣＨがすべてサポートされる。一方、ＣＳＩのような他のアップリンク制御情報も、Ｓｈｏｒｔ ＰＵＣＣＨ、Ｌｏｎｇ ＰＵＣＣＨ、およびＰＵＳＣＨで送信されることができる。したがって、ビームレポートとＣＳＩのような他のアップリンク制御情報の間に送信の衝突が発生する可能性がある。以下では、例示の目的で、ＣＳＩを例として取り上げるが、当業者は、本開示がそれに限定されないことを容易に知ることができ、本明細書で提供されるソリューションは、ビームレポートと衝突する可能性のある任意のアップリンク制御情報に対しても役立つ。

例示の目的で、図２および図３は、ビームレポートのためのアップリンクチャネルおよびＣＳＩレポートのためのアップリンクチャネルのテーブルをそれぞれ示す。図２と図３からわかるように、ビームレポートおよびＣＳＩレポートのいずれもＬｏｎｇ ＰＵＣＣＨ、Ｓｈｏｒｔ ＰＵＣＣＨ、またはＰＵＳＣＨで送信できるため、ビームレポートがＣＳＩレポートと衝突する可能性がある。このような場合、ビームレポートおよび他のアップリンク制御情報のペイロードサイズは、レポートチャネルで搬送するには大きすぎる可能性がある。本開示では、そのような衝突が発生したときに、それらの少なくとも一部をドロップするドロップ戦略を採用することが提案されている。たとえば、ステップ１０１に示すように、ＵＥは、所定の優先度ルールに基づいて、ビームレポートおよびＣＳＩのうちの優先度の低い方をドロップすることができる。

所定の優先度ルールは、ビームレポートおよび他のアップリンク制御情報（たとえば、ＣＳＩ）の送信優先度を定義することができる。送信優先度を参照して、ＵＥは、ビームレポートおよび他のアップリンク制御情報のうちのどちらがドロップされ得るかを決定することができる。

本開示の一実施形態では、所定の優先度ルールは、タイミング要求に基づいて送信優先度を定義してもよい。情報のタイミングに対する要求が厳格であるほど、送信の優先度が高くなる。たとえば、以下のタイプの情報の時間要求を考慮すると、Ａ（非周期的レポート情報）、Ｓ（半永続的レポート情報）、およびＰ（周期的レポート情報）の送信優先度がＡ＞Ｓ＞Ｐとして決定されてもよい。さらに、Ａ、Ｓ、およびＰのそれぞれで、ビームレポートがＣＳＩレポートよりも高い送信優先度に指定されてもよい。

例示の目的で、図４Ａは、様々なタイプのビームレポートおよびＣＳＩの送信優先度の順位、すなわち｛Ａ＞Ｓ＞Ｐ、ＢＭ＞ＣＳＩ｝を定義する、例示的なタイミング重視（ｔｉｍｉｎｇ−ｆｉｒｓｔ）の優先度ルールを示す。図４に示すように、送信衝突の異なるケースが示され、その中、１行目はＳｈｏｒｔ ＰＵＣＣＨ（Ｓ−ＰＵＣＣＨ）での送信衝突を示し、２行目はＬｏｎｇ ＰＵＣＣＨ（Ｌ−ＰＵＣＣＨ）での送信衝突を示し、３行目はＰＵＳＣＨでの送信衝突を示し、また、「Ｐ」は周期的なレポート情報を表し、「Ｓ」は半永続的なレポート情報を表し、「Ａ」は非周期的なレポート情報を表し、「ＣＳＩ」はチャネル状態情報を表し、「ＢＭ」はビームレポートを表し、「Ｉ」または「ＩＩ」はＮＲシステムで定義されたＣＳＩのタイプを表し、「ＷＢ」は広帯域または部分帯域の周波数粒度を表し、「ＳＢ」はサブ帯域の周波数粒度を表し、「Ｐ１」はＣＳＩ情報の部分１（Ｐａｒｔ １）を表す。

図４Ａにさらに示すように、Ｓ−ＰＵＣＣＨでの送信衝突の場合、送信優先度は、Ａ−ＢＭ、Ａ−ＷＢ−Ｉ−ＣＳＩ、Ｓ−ＢＭ、Ｓ−ＷＢ−ＣＳＩ、Ｐ−ＢＭ、およびＰ−ＷＢ−Ｉ−ＣＳＩの順位であってもよい。Ｌ−ＰＵＣＣＨでの送信衝突の場合、送信優先度は、Ｓ−ＢＭ、Ｓ−ＷＢ−Ｉ−ＣＳＩ、Ｐ−ＢＭ、Ｓ−ＩＩ−ＣＳＩ−Ｐ１、Ｓ−ＳＢ−Ｉ−ＣＳＩ、およびＰ−ＷＢ−Ｉ−ＣＳＩの順位であってもよい。ＰＵＳＣＨでの送信衝突の場合、送信優先度は、Ａ−ＢＭ（非周期的ビームレポート）、Ａ−ＣＳＩ（非周期的ＣＳＩレポート）、Ｓ−ＢＭ（半永続的ビームレポート）、及びＳ−ＣＳＩ（半永続的なＣＳＩレポート）の順位であってもよい。

本開示の別の実施形態では、所定の優先度ルールは、通信システムの機能要求に依存し、たとえば、ＢＭ＞ＣＳＩまたはＣＳＩ＞ＢＭのように、機能要求に基づいて送信優先度を定義してもよい。さらに、ビームレポートと他のアップリンク制御情報のうちの１つ又はそれぞれの異なるタイプの送信優先度を定義する内部優先度ルールをさらに設定することができる。たとえば、ビームレポートの場合、Ａ−ＢＭ、Ｓ−ＢＭおよびＰ−ＢＭ（周期的ビームレポート）の送信優先度を｛Ａ−ＢＭ＞Ｓ−ＢＭ＞Ｐ−ＢＭ｝として決定してもよい。別の例では、ＣＳＩレポートの場合、Ａ−ＣＳＩ、Ｓ−ＣＳＩ、およびＰ−ＣＳＩ（周期的ＣＳＩレポート）の送信優先度を｛Ａ−ＣＳＩ＞Ｓ−ＣＳＩ＞Ｐ−ＣＳＩ｝として決定してもよい。

例示の目的で、図４Ｂおよび４Ｃは、様々なタイプのビームレポートおよびＣＳＩの送信優先度の順位を定義する、例示的な機能重視（ｆｕｎｃｔｉｏｎ−ｆｉｒｓｔ）の優先度ルールを示す。

図４Ａと同様に、図４Ｂは、Ｓ−ＰＵＣＣＨ、Ｌ−ＰＵＣＣＨおよびＰＵＳＣＨでの送信衝突の異なるケースをそれぞれ示すが、図４Ｂは、タイミング重視の優先度の代わりに機能重視の優先度を示す。図示されるように、ＢＭレポートは、ＣＳＩレポートよりも高い送信優先度を有し、すなわち、ＢＭ＞ＣＳＩである。特に、Ｓ−ＰＵＣＣＨでの送信衝突の場合、送信優先度は、Ａ−ＢＭ、Ｓ−ＢＭ、Ｐ−ＢＭ、Ａ−ＷＢ−Ｉ−ＣＳＩ、Ｓ−ＷＢ−ＣＳＩ、およびＰ−ＷＢ−Ｉ−ＣＳＩの順位であってもよい。Ｌ−ＰＵＣＣＨでの送信衝突の場合、送信優先度は、Ｓ−ＢＭ、Ｐ−ＢＭ、Ｓ−ＷＢ−Ｉ−ＣＳＩ、Ｓ−ＩＩ−ＣＳＩ−Ｐ１、Ｓ−ＳＢ−Ｉ−ＣＳＩ、およびＰ−ＷＢ−Ｉ−ＣＳＩの順位であってもよい。ＰＵＳＣＨでの送信衝突の場合、送信優先度は、Ａ−ＢＭ、Ｓ−ＢＭ、Ａ−ＣＳＩ、およびＳ−ＣＳＩの順位であってもよい。

さらに図４Ｃを参照する。図４Ｃは、Ｓ−ＰＵＣＣＨ、Ｌ−ＰＵＣＣＨおよびＰＵＳＣＨでの送信衝突の異なるケースにおける別の機能重視の優先度ルールを示す。図４Ｂとは異なり、ＣＳＩレポートは、ＢＭレポートよりも高い送信優先度を有し、すなわち、ＣＳＩ＞ＢＭである。したがって、図４Ｃでは、Ｓ−ＰＵＣＣＨでの送信衝突の場合、送信優先度は、Ａ−ＷＢ−Ｉ−ＣＳＩ、Ｓ−ＷＢ−ＣＳＩ、Ｐ−ＷＢ−Ｉ−ＣＳＩ、Ａ−ＢＭ、Ｓ−ＢＭ、およびＰ−ＢＭの順位であってもよい。Ｌ−ＰＵＣＣＨでの送信衝突の場合、送信優先度は、Ｓ−ＷＢ−Ｉ−ＣＳＩ、Ｓ−ＩＩ−ＣＳＩ−Ｐ１、Ｓ−ＳＢ−Ｉ−ＣＳＩ、Ｐ−ＷＢ−Ｉ−ＣＳＩ、Ｓ−ＢＭ、およびＰ−ＢＭの順位であってもよい。ＰＵＳＣＨでの送信衝突の場合、送信優先度は、Ａ−ＣＳＩ、Ｓ−ＣＳＩ、Ａ−ＢＭ、およびＳ−ＢＭの順位であってもよい。

本開示の実施形態では、上記の優先度ルールは、ＵＥおよびｇＮＢの両方によって知られている所定のルールであってもよい。また、より柔軟な使い方も可能である。たとえば、ｇＮＢは、ＤＣＩに所定のビットを設定することにより、使用される優先度ルールをＵＥに通知してもよい。たとえば、「０」は図４Ａに示すタイミング重視の優先度ルールを示し、「１」は図４Ｃに示す機能重視の優先度ルールを示してもよい。さらに、優先度ルールが図４Ｂに示すルールに変更されるように、ＵＥはまた、ビーム障害回復要求（ＢＦＲＱ：ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）をｇＮＢに送信することによって優先度ルールの変更を行ってもよい。

本開示は、上記の例示的な優先度ルールに限定されないことに留意されたい。本開示のいくつかの他の実施形態では、様々なタイプの情報を逆の順序で順位付けることができ、これは、送信優先度が高いほど、情報の順位が低くなることを意味する。したがって、重要度の低い（送信優先度が低い）情報タイプはより高く順位付けられ、ドロップ操作は順位の高い情報から開始されている。また、優先度ルールを示す方法も例示の目的で提供されるものであり、本発明はそれに限定されないことにも留意されたい。

優先度のより低い部分をドロップすることにより、ビームレポートと別のアップリンク制御情報との間の送信衝突は、簡単でありながら効率的な方法で対処することができる。

本開示の別の態様では、衝突に対処する別の方法がさらに提供され、図５を参照して以下で説明される。方法５００は、端末デバイス、たとえば、ＵＥ、または他の同様の端末デバイスで実行されることができる。

図５は、本開示の実施形態にかかるビームレポート送信のための別の方法のフローチャートを概略的に示す。図５に示すように、ステップ５０１において、ＵＥは、所定のリソースセットに衝突に対処するのに利用可能なアップリンク送信リソースがあるかどうかをチェックする。衝突に対処するためのアップリンク送信リソースがある場合、ステップ５０２において、ビームレポートおよび他のアップリンク制御情報は、衝突に対処するのに利用可能なアップリンク送信リソースに多重化され得る。したがって、図１のソリューションとは異なり、図５で提案されているソリューションでは、衝突に対処するために、ビームレポートとＣＳＩのような他のアップリンク制御情報に多重化戦略が採用されている。言い換えれば、衝突した情報は、他の利用可能な送信リソースにオフロードできる。

ビームレポートおよびＣＳＩのような他のアップリンク制御情報の多重化に関して、多重化の選択肢は、場合によっては異なっていてもよい。たとえば、ビームレポートと他のアップリンク制御情報は、ＰＵＣＣＨの２つの別個に符号化された部分に多重化されることができる。つまり、衝突した情報を、ＰＵＣＣＨの２つの別個に符号化された部分にオフロードすることができる。別の例として、ビームレポートおよび他のアップリンク制御情報は、ＰＵＳＣＨに多重化されることができ、言い換えれば、衝突した情報をＰＵＳＣＨにオフロードすることができる。多重化の選択肢が複数ある場合、所定の選択優先度に基づいて、多重化をさらに選択することができる。優先度は、ｇＮＢによって事前定義された利用可能なレポートリソースのＵＣＩのペイロードサイズに従って、ＵＥで暗黙的に決定できる（たとえば、ＰＵＳＣＨ＞ＰＵＣＣＨ）。さらに、選択優先度は、上位レイヤシグナリング（メディアアクセス制御（ＭＡＣ：Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）制御要素（ＣＥ：Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）または無線リソース制御（ＲＲＣ：Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）シグナリング）を介して半静的に設定され、または、ネットワークノードから、たとえばＤＣＩを介して、動的に示されることができる。

例示の目的で、図６は、異なるケースに対応可能なオフロードソリューションを示す。図示するように、衝突がＳｈｏｒｔ ＰＵＣＣＨで発生する場合、衝突した情報をＬｏｎｇ ＰＵＣＣＨの２つの別個に符号化された部分またはＰＵＳＣＨにオフロードすることができる。衝突がＬｏｎｇ ＰＵＣＣＨで発生する場合、衝突した情報を、より大きなペイロードサイズを格納する別のＬｏｎｇ ＰＵＣＣＨの２つの別個に符号化された部分（たとえば、フォーマット３からフォーマット４にフォーマットが変更されたもの）またはＰＵＳＣＨにオフロードすることができる。衝突がＰＵＳＣＨで発生する場合、衝突した情報をオフロードするのに利用可能なリソースがない。このような場合、たとえば、図１から４を参照して説明したようなドロップ戦略を採用することができる。

例示の目的で、図７は、ビームレポートおよびＣＳＩ送信のためのＰＵＣＣＨの２つの別個に符号化された部分を示す。図７に示すように、ＢＭ（ビーム）レポートとＣＳＩレポートは、２つの情報ブロックとして、場合によっては別々に２つのＣＲＣブロックとともに符号化され、かつ２つの異なる符号化部分として送信されることができる。

さらに、ＰＵＳＣＨでの送信衝突に加えて、衝突に対処するのに利用可能なアップリンク送信リソースがない場合、図１のドロップ戦略を本明細書で説明される多重化戦略と組み合わせることも可能であることに留意されたい。言い換えれば、ビームレポートと別のアップリンク制御情報の間に送信の衝突がある場合、優先度の低い部分をドロップする前に、まず、衝突に対処するのに利用可能なアップリンク送信リソースが事前に設定されたリソースセットにあるかどうかをチェックする。このようなアップリンク送信リソースがある場合、ビームレポートおよび他のアップリンク制御情報をアップリンク送信リソースに多重化することができる。このようなアップリンク送信リソースがない場合、ドロップ戦略を採用し、所定の優先度ルールに基づいて、ビームレポートおよび他のアップリンク制御情報のうちの優先度の低い方をドロップする。

本開示のさらなる態様では、ビームレポートをハイブリッド自動再送要求（ＨＡＲＱ）と多重化するソリューションがさらに提供される。ビームレポートとＨＡＲＱの間の多重化は、同じスロット内の異なるＰＵＣＣＨチャネル、同じＰＵＣＣＨチャネル内の同じ符号化部分、または同じＰＵＣＣＨチャネル内の異なる符号化部分で実行されることができる。使用される特定の多重化モードは、ネットワークノードからのリソース設定インジケータによって示されることができる。

例示の目的で、図８は、ビームレポート（ＢＭ）とＨＡＲＱとの間の例示的な多重化戦略を示す。図８では、「０００」、「００１」、「０１１」、「０１０」、「１００」、「１０１」を含む６つの可能なリソース設定インジケータの値が示されている。インジケータ値「０００」の場合、ビームレポート（周期的、半永続的、非周期的ビームレポートを含む）およびＨＡＲＱが時分割多重（ＴＤＭ：ｔｉｍｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ）モードで２つのＳｈｏｒｔ ＰＵＣＣＨに多重化されることを示す。インジケータ値「００１」の場合、ビームレポート（周期的、半永続的、非周期的ビームレポートを含む）およびＨＡＲＱが、Ｓｈｏｒｔ ＰＵＣＣＨの２つの別個に符号化された部分、たとえばＨＡＲＱについて部分１とＢＭについて部分２で多重化されることを示す。インジケータ値「０１１」の場合、ビームレポート（周期的および半永続的ビームレポートを含む）およびＨＡＲＱが、時分割多重（ＴＤＭ）モードでＳｈｏｒｔ ＰＵＣＣＨおよびＬｏｎｇ ＰＵＣＣＨに多重化されることを示す。インジケータ値「０１０」の場合、ビームレポート（周期的および半永続的ビームレポートを含む）およびＨＡＲＱが、Ｌｏｎｇ ＰＵＣＣＨの２つの別個に符号化された部分に多重化されることを示す。インジケータ値「１００」の場合、ビームレポート（半永続的および非周期的ビームレポートを含む）およびＨＡＲＱがＰＵＳＣＨで搬送できることを示す。インジケータ値「１０１」の場合、ビームレポート（半永続的および非周期的ビームレポートを含む）はＰＵＳＣＨで搬送でき、ＨＡＲＱは同じスロット内のＰＵＣＣＨで搬送できることを示す。

図９は、ビームレポートおよびＨＡＲＱのためのＰＵＣＣＨの２つの別個に符号化された部分を示す。図９に示すように、インジケータ値「００１」および「０１０」について、ＢＭレポートおよびＨＡＲＱは、２つの情報ブロックとして、場合によっては別々に２つのＣＲＣブロックとともに符号化され、かつ２つの異なる符号化部分として送信されることができる。

本開示のさらに他の態様では、ビームレポートのための新しいリソース選択方式が提供される。図２に示すように、ビームレポートのタイプごとに利用可能なチャネルが複数あるような場合、所定のリソース選択ルールに基づいて、ビームレポート用のアップリンク送信リソースを選択してもよい。所定の選択ルールは、ペイロードサイズまたはレポートされるビームの数のいずれかに基づいてもよい。

本開示の一実施形態では、所定の選択ルールは、ペイロードサイズに基づいてもよい。たとえば、ペイロードサイズが小さいビームレポートの場合、Ｓｈｏｒｔ ＰＵＣＣＨを使用し、ペイロードサイズがミディアムのビームレポートの場合、Ｌｏｎｇ ＰＵＣＣＨを使用し、ペイロードサイズが大きいビームレポートの場合、ＰＵＳＣＨを使用してもよい。

図１０は、ペイロードサイズに基づく例示的なリソース選択ルールを示し、ここで、ペイロードサイズＬ１からＬ６は、Ｌ１＜Ｌ２＜Ｌ３＜Ｌ４＜Ｌ５＜Ｌ６を満たす。図１０から明らかなように、Ｐ１は小さいペイロード範囲、Ｐ２はミディアムのペイロード範囲、Ｐ３は大きいペイロード範囲である。Ｐ１のペイロードの場合、ビームレポートのためにＳｈｏｒｔ ＰＵＣＣＨを選択してもよい。Ｐ２のペイロードの場合、ビームレポートのためにＬｏｎｇ ＰＵＣＣＨを選択してもよい。Ｐ３のペイロードの場合、ビームレポートのためにＰＵＳＣＨを選択してもよい。さらに、Ｐ１とＰ２の間にオーバーラップ範囲Ｌ２−Ｌ３があり、Ｐ２とＰ３の間に別のオーバーラップ範囲Ｌ４−Ｌ５があることもわかる。したがって、このようなオーバーラップ範囲に含まれるペイロードには、複数のリソース選択肢がある。このような場合、ｇＮＢは、半静的上位レイヤ（ＲＲＣシグナリングまたはＭＡＣ ＣＥ）またはＤＣＩのような動的な指示によって、ビームレポート送信のためのアップリンク送信リソースの選択順序を示すことができる。

本開示の別の実施形態では、所定の選択ルールは、レポートされるビームの数に基づいてもよい。たとえば、第１の数範囲のレポートされるビームの数について、Ｓｈｏｒｔ ＰＵＣＣＨを使用し、別の数範囲のレポートされるビームの数について、ＵＥの能力に依存するＰＳＵＣＨまたはＬｏｎｇ ＰＵＣＣＨをさらに採用してもよい。

例示の目的で、図１１は、レポートされるビームの数に基づく例示的なリソース選択ルールを示し、Ｎ≦２の場合、ＵＥはＳｈｏｒｔ ＰＵＣＣＨを使用し、Ｎ≦４の場合、ＵＥは、その能力に基づいてＬｏｎｇ ＰＵＣＣＨまたはＰＵＳＣＨを選択してもよい。したがって、レポートされるビームが１つまたは２つである場合、Ｌｏｎｇ ＰＵＣＣＨとＰＵＳＣＨのうちの少なくとも１つ、およびＳｈｏｒｔ ＰＵＣＣＨを含む選択肢がある。レポートされるビームが３つまたは４つである場合、少なくともＬｏｎｇ ＰＵＣＣＨとＰＵＳＣＨを含む選択肢がある。このような場合、所定の選択ルールは、ＵＥがこれらの利用可能なレポートチャネルから１つのレポートチャネルを選択できるように、ビームレポート送信のためのアップリンク送信リソースの選択順序をさらに定義してもよい。ＵＥでのデフォルトの選択順序は、たとえば、Ｓｈｏｒｔ ＰＵＣＣＨ＞ＰＵＳＣＨ＞Ｌｏｎｇ ＰＵＣＣＨがあってもよい。さらに、選択順序は、半静的上位レイヤ（ＭＡＣ ＣＥまたはＲＲＣシグナリングなど）によって設定され、または、ＤＣＩによって動的に示すこともできる。

本開示のさらに他の態様では、送信リソース浪費問題に対処するための別のビームレポート送信ソリューションがさらに提供される。次に、図１２を参照して詳細に説明する。

図１２は、本開示の実施形態にかかるビームレポート送信のための方法１２００のフローチャートを概略的に示す。方法１２００は、端末デバイス、たとえばＵＥ、または他の同様の端末デバイスで実行されることができる。

図１２に示すように、ステップ１２０１において、第１のビームレポートセグメントが送信される。ここで、第１のビームレポートセグメントは、第１のビームのアイデンティティ、第１のビームのチャネル品質指示（ｃｈａｎｎｅｌ ｑｕａｌｉｔｙ ｉｎｄｉｃａｔｉｏｎ）、および後続ビームレポートセグメントが存在するかどうかを示す後続セグメント指示情報を含む。次に、ステップ１２０２において、後続ビームレポートセグメントが存在することを後続セグメント指示情報が示す場合のみ、少なくとも１つの後続ビームに関する情報を含む少なくとも１つの後続ビームレポートセグメントが、送信される。したがって、本開示では、ビームレポートを少なくとも２つのセグメントに分割することが提案されている。第１のセグメントは、後続ビームレポートセグメントが存在するか否かを示すことができる後続セグメント指示情報を含み、第２のビームレポートセグメントは、後続ビームレポートセグメントがある場合のみ送信される。このようにして、後続のセグメントは、パディングビットの代わりに、必要な場合のみ送信されるため、送信リソースをより効率的に利用できる。さらに、第１のセグメントのみが送信される場合、ＵＥは、第１のセグメントをよりコンパクトかつ確実に送信するために、異なるＰＵＣＣＨフォーマットおよび／または符号化レートを選択してもよい。以下、図１３から２１を参照して、本明細書で提供されるサーバ固有の実装を説明する。

図１３は、本開示の実施形態にかかる２つの例示的なビームレポートセグメントの図を概略的に示す。図１３に示すように、ビームレポートは２つのセグメント、つまりセグメント１とセグメント２に分割されている。セグメント１には、第１のビーム（たとえば、最も強いビーム）のビームＩＤ１（６ビット）、第２のビーム（たとえば、２番目に強いビーム）のＲＳＲＰ値ＲＳＲＰ１（７ビット）および差分ＲＳＲＰ値ＲＳＲＰ２（４ビット）が含まれている。ＲＳＲＰ２では、差分ＲＳＲＰのための４ビットの１５個の値のほか、残りの値を、ビームＲＳＲＰの停止を示すのに用いることができ、ここで、停止は、差分ＲＳＲＰ値が１６＊ステップサイズより大きいことを意味する。ＲＳＲＰ２の４ビットの値が通常の差分値を表す場合、後続ビームレポートセグメントがあることを意味する。これに対して、４ビットの値が停止を表す場合、送信される後続のセグメントがない。セグメント２には、レポートされるビームの第１のビームを除くビームＩＤと、すでにセグメント１に含まれているものを除くさまざまなＲＳＲＰ値が含まれていてもよい。セグメント２の破線は、セグメント１とは異なり、セグメント１に含まれるＲＳＲＰ２の値によってセグメント２が存在しない可能性があることを意味する。

図１４は、図１３で説明されたソリューションにかかる２つのビームレポートセグメントのペイロードサイズのテーブルを示す。セグメント１およびセグメント２の合計ペイロードサイズは、いかなる追加のビットがないため、既存のソリューションと同様である。ただし、セグメント２が送信されない可能性があるため、送信リソースを削減することができる。

２つのビームレポートセグメントは、同じレポートチャネルまたは異なるレポートチャネルで送信できることに留意されたい。たとえば、図１５に示すように、セグメント１をＳｈｏｒｔ ＰＤＣＣＨで送信し、セグメント２をＬｏｎｇ ＰＤＣＣＨで送信することができる。別の例として、図１６に示すように、２つのビームレポートセグメントをＬｏｎｇ ＰＤＣＣＨで送信することもできる。

さらに、同じレポートチャネルで、２つのビームレポートセグメントは、同じ符号化部分で送信されることもできる。代替的に、同じレポートチャネルの別個に符号化された部分で送信されてもよい。図１７に示すように、セグメント１は第１の情報ブロックで送信され、セグメント２は第２の情報ブロックで送信されることができ、ここで、第１および第２の情報ブロックは２つのＣＲＣとともに別々に符号化される。セグメント１へのリソース割り当ては、上位レイヤのシグナリングを通じてｇＮＢによって設定されることができる。セグメント２へのリソース割り当ては、事前定義されたアップリンクリソースセットから選択されたリソースを使用するＤＣＩを介してｇＮＢによって動的に示されることができる。

図１８は、本開示の実施形態にかかる他の例示的なビームレポートセグメントの図を概略的に示す。図１３に示されるものとは異なり、ＲＳＲＰ２は、セグメント１に含まれて停止を示すものではない。代わりに、後続のセグメントがあるかどうかを示す１つの新しいビット「ａ」が含まれる。たとえば、「０」は、後続のセグメントがないことを示すのに用いられる。「ａ」ビットが「０」である場合、セグメント２は送信されない。

図１９は、図２８に説明されるソリューションにかかる２つのビームレポートセグメントのペイロードサイズを示す。セグメント１およびセグメント２の合計ペイロードサイズは、新たに追加されたビットａのため、既存のソリューションよりも１ビット多い。ただし、セグメント２が送信されない可能性があるため、送信リソースを削減することもできる。

図２０は、本開示の実施形態にかかるさらなる例示的なビームレポートセグメントの図を概略的に示す。図１２および１８に示すものとは異なり、レポートされるビームの数（これらのビームは停止していない）がセグメント１に含まれて、後続のセグメントの数を示す。ビームの数がゼロである場合、後続のセグメントがないことを意味し、ビームの数が１より大きい場合、後続のセグメントの存在を意味する。これらのセグメントは、図２１に示すように、別々のセグメントとして同じレポートリソース、たとえばＬｏｎｇ ＰＵＣＣＨで、送信されることができる。

本開示のいくつかの態様または実施形態をそれぞれ説明したが、これらを組み合わせて新しいソリューションを形成することもできることに留意されたい。一方、本開示のいくつかの態様または実施形態を、他の態様または実施形態と組み合わせて説明したが、これらは、独立のソリューションとして別個に実施されることもできる。

以上、端末デバイス側でのビームレポート送信のためのソリューションについて、図１から２１を参照して説明したが、次に、ネットワーク側でのビームレポート受信のためのソリューションを、図２２から２４を参照して説明する。

図２２は、本開示の実施形態にかかるビームレポート受信のための方法のフローチャートを概略的に示す。方法２２００は、ネットワークノード、たとえばｇＮＢ、または他の同様のネットワークノードで実行されることができる。

図２２に示すように、ステップ２２０１において、ｇＮＢは、ビームレポートと別のアップリンク制御情報との間の衝突に対応して、ビームレポートおよび他のアップリンク制御情報の送信優先度を定義する所定の優先度ルールに基づいて、ビームレポートおよび他のアップリンク制御情報のうちの優先度の高い方を受信することができる。ビームレポートと別のアップリンク制御情報との間の衝突が存在する場合、ｇＮＢは、ＵＥと同じ所定の優先度ルールを使用して、ビームレポートと他のアップリンク制御情報のどちらをドロップし、どちらを送信するかを決定できる。このようにして、ビームレポートと他のアップリンク制御情報のうち優先度の高い方のみがｇＮＢで受信される。

端末デバイスにおける所定の優先度ルールと同様に、ｇＮＢにおける所定の優先度ルールは、タイミング要求または機能要求のいずれかに基づいて送信優先度を定義することができる。さらに、所定の優先度は、ビームレポートおよび他のアップリンク制御情報のうちの１つまたはそれぞれの異なるタイプに対して設定された内部送信優先度をさらに含んでもよい。端末デバイスとネットワークノードで使用される優先度ルールはまったく同じものであるため、優先度ルールの詳細については、図１から４Ｃを参照した説明を参照することができる。

図２３は、本開示の実施形態にかかるビームレポート受信のための別の方法のフローチャートを概略的に示す。方法２３００は、ネットワークノード、たとえばｇＮＢ、または他の同様のネットワークノードで実行されることができる。

図２３に示すように、ステップ２３０１において、アップリンク制御情報を受信する前に、ｇＮＢは、所定のリソースセットに衝突に対処するのに利用可能なアップリンク送信リソースがあるかどうかをチェックする。衝突に対処するためのアップリンク送信リソースがある場合、ステップ２３０２において、ｇＮＢは、衝突に対処するのに利用可能なアップリンク送信リソースでのビームレポートおよび他のアップリンク制御情報を受信することができる。

したがって、図２２のソリューションとは異なり、図２３で提案されたソリューションでは、ｇＮＢは、まず、衝突に対処するために端末デバイスでビームレポートおよび他のアップリンク制御情報に多重化戦略が採用されたかどうかを判断し、ＹＥＳの場合、ｇＮＢは、利用可能なアップリンク送信リソースでのビームレポートおよび他のアップリンク制御情報を受信する。

ビームレポートおよびＣＳＩのような他のアップリンク制御情報の多重化に関して、多重化の選択は、図６を参照して説明したように、場合によっては異なっていてもよい。したがって、ビームレポートおよび他のアップリンク制御情報を搬送するアップリンク送信リソースは、物理アップリンク制御チャネル（ＰＵＣＣＨ）および物理アップリンク共有チャネル（ＰＵＳＣＨ）のいずれかを含む可能性がある。さらに、ビームレポートおよび他のアップリンク制御情報は、図６にも示すように、ＰＵＣＣＨで２つの別個に符号化された部分で搬送されることができる。多重化の選択肢が複数ある場合、ビームレポートおよび他のアップリンク制御情報を搬送するアップリンクリソースは、端末デバイスと同様に所定の選択優先度に基づいて決定されてもよい。

本開示の別の態様では、ビームレポート受信は、異なるレポートチャネル、同じレポートチャネルの同じ符号化部分、同じレポートチャネルの異なる符号化部分のいずれかに／内でビームレポートおよびハイブリッド自動再送要求（ＨＡＲＱ）を受信することをさらに含んでもよい。言い換えれば、ｇＮＢは、多重化されたビームレポートおよびＨＡＲＱを受信してもよい。ビームレポートとＨＡＲＱの多重化戦略の詳細については、図８と９を参照した説明を参照する。

本開示の別の実施形態では、ビームレポート受信の場合、方法は、所定の選択ルールに基づいて、事前設定されたリソースセットから、ビームレポートのためのアップリンク送信リソースを決定することをさらに含んでもよい。所定の選択は、ペイロードサイズまたはレポートされるビームの数のいずれかに基づいてもよい。複数のレポートリソース選択肢がある場合、ビームレポート送信のためのアップリンク送信リソースの選択順序に基づいて、ビームレポートのためのアップリンク送信リソースをさらに決定することができる。このような選択順序によって、ｇＮＢは、ビームレポート送信のために端末デバイスによって使用されたアップリンク送信リソースを確定し、かつアップリンク送信リソースでのビームレポートを受信することができる。

図２４は、本開示の実施形態にかかるビームレポート受信のためのさらなる方法のフローチャートを概略的に示す。方法２４００は、ネットワークノード、たとえば、ｇＮＢ、または他の同様のネットワークノードで実行されることができる。

図２４に示すように、まず、ステップ２４０１において、ｇＮＢは、第１のビームのアイデンティティ、第１のビームのチャネル品質指示、および後続セグメント指示情報を含む第１のビームレポートセグメントを受信する。後続セグメント指示情報は、後続ビームレポートセグメントが存在するかどうかを示す。次に、ｇＮＢは、後続セグメント指示情報によって後続ビームレポートセグメントが存在することを示すことを検出した場合、少なくとも１つの後続のビームに関する情報を含む少なくとも１つの後続ビームレポートセグメントを受信する。言い換えれば、第１のセグメントはセグメント２の前に復号され、セグメント２は、後続セグメント指示情報が後続のセグメントの存在を示す場合のみ復号される。

図１３を参照して説明したように、後続セグメント指示情報は、後続のビームのチャネル品質指示の所定の値によって示されることができる。また、図１８および２０も参照して説明したように、後続セグメント指示情報は、所定のビットで示される。所定のビットは、後続のセグメントがあるかどうかを簡単に示す単一ビット（図１８を参照）、または後続のセグメントの数を示すいくつかのビット（たとえば２ビット）（図２０を参照）とすることができる。

上記では、ビームレポート受信の方法の実施形態を、図２２から２４を参照して上記で簡単に説明した。しかし、端末デバイスでの動作は、ネットワークノードでの動作に対応し、したがって、動作のいくつかの詳細については、図１から２１を参照した説明を参照することができることが理解され得る。

図２５は、本開示の実施形態にかかるビームレポート送信のための装置のブロック図をさらに概略的に示す。装置２５００は、端末デバイス、たとえばＵＥ、または他の同様の端末デバイスで実装されることができる。

図２５に示すように、装置２５００は、ビームレポートと別のアップリンク制御情報との間の衝突に対応して、ビームレポートおよび他のアップリンク制御情報の送信優先度を定義する所定の優先度ルールに基づいて、ビームレポートおよび他のアップリンク制御情報のうちの優先度の低い方をドロップするように設定され得る情報ドロップモジュール２５０１を備える。

本開示の実施形態では、所定の優先度ルールは、タイミング要求または機能要求のいずれかに基づいて送信優先度を定義する。

本開示の別の実施形態では、所定の優先度ルールは、ビームレポートおよび他のアップリンク制御情報のうちの１つまたはそれぞれの異なるタイプについて設定された内部送信優先度をさらに含んでもよい。

本開示のさらなる実施形態では、装置２５００は、リソースチェックモジュール２５０２および送信多重化モジュール２５０３をさらに含んでもよい。リソースチェックモジュールは、ドロップする前に、衝突に対処するために事前設定されたリソースセットに利用可能なアップリンク送信リソースがあるかどうかをチェックするように設定されてもよい。送信多重化モジュール２５０３は、衝突に対処するために利用可能なアップリンク送信リソースがある場合、アップリンク送信リソースでビームレポートおよび他のアップリンク制御情報を多重化するように設定されてもよい。

本開示のさらに他の実施形態では、ビームレポートおよび他のアップリンク制御情報の多重化は、物理アップリンク制御チャネル（ＰＵＣＣＨ）への２つの別個に符号化された部分におけるビームレポートおよび他のアップリンク制御情報の多重化と、物理アップリンク共有チャネル（ＰＵＳＣＨ）へのビームレポートおよび他のアップリンク制御情報の多重化とのいずれかの選択肢を含んでもよい。

本開示のさらに他の実施形態では、多重化は、所定の選択優先度に基づいて選択される。

本開示の別の実施形態では、送信多重化モジュール２５０３は、同じスロット内の異なるＰＵＣＣＨチャネル、同じＰＵＣＣＨチャネル内の同じ符号化部分、および同じＰＵＣＣＨチャネル内の異なる符号化部分のいずれかに／内で、ビームレポートをハイブリッド自動再送要求（ＨＡＲＱ）と多重化するようにさらに設定されてもよい。

本開示のさらなる実施形態では、装置２５００は、ペイロードサイズまたはレポートされるビームの数のいずれかに関する所定の選択ルールに基づいて、事前設定されたリソースセットから、ビームレポートのためのアップリンク送信リソースを選択するように設定されるリソース選択モジュール２５０４をさらに含んでもよい。

本開示のさらに他の実施形態では、所定の選択ルールは、ビームレポート送信のためのアップリンク送信リソースの選択順序をさらに定義してもよい。

本開示のさらに他の実施形態では、ビームレポート送信の場合、装置２５００は、第１のセグメント送信モジュール２５０５および第２のセグメント送信モジュール２５０６をさらに含んでもよい。第１のセグメント送信モジュール２５０５は、第１のビームのアイデンティティ、第１のビームのチャネル品質指示、および後続ビームレポートセグメントが存在するかどうかを示す後続セグメント指示情報を含む第１のビームレポートセグメントを送信するように設定されることができる。第２のセグメント送信モジュール２５０６は、後続セグメント指示情報によって後続ビームレポートセグメントが存在することを示す場合のみ、少なくとも１つの後続のビームに関する情報を含む少なくとも１つの後続ビームレポートセグメントを送信するように設定されることができる。

本開示の別の実施形態では、後続セグメント指示情報は、後続のビームのチャネル品質指示の所定の値によって示されてもよい。

本開示のさらなる実施形態では、後続セグメント指示情報は、所定のビットによって示されても良い。

本開示のさらに他の実施形態では、第１のビームレポートセグメントおよび少なくとも１つの後続のセグメントは、異なるレポートチャネル、同じレポートチャネルの同じ符号化部分、同じレポートチャネルの異なる符号化部分のいずれかに／内で送信されてもよい。

図２６は、本開示のさらなる実施形態にかかるビームレポート受信のための装置のブロック図を概略的に示す。装置２６００は、ネットワークノード、たとえば、ｇＮＢ、または他の同様のネットワークノードで実装されることができる。

図２６に示すように、装置２６００は、ビームレポートと別のアップリンク制御情報との間の衝突に対応して、ビームレポートおよび他のアップリンク制御情報の送信優先度を定義する所定の優先度ルールに基づくビームレポートおよび他のアップリンク制御情報のうちの高い優先度の方を受信するように設定される制御情報受信モジュール２６０１を備えてもよい。

本開示の一実施形態では、所定の優先度ルールは、タイミング要求または機能要求のいずれかに基づいて送信優先度を定義してもよい。

本開示の別の実施形態では、所定の優先度は、ビームレポートおよび他のアップリンク制御情報の１つまたはそれぞれの異なるタイプについて設定された内部送信優先度をさらに含んでもよい。

本開示のさらなる実施形態では、装置２６００は、受信する前に、衝突に対処するために事前設定されたリソースセットに利用可能なアップリンク送信リソースがあるかどうかをチェックするように設定されるリソースチェックモジュール２６０２をさらに含んでもよい。情報受信モジュール２６０１は、衝突に対処するために事前設定されたリソースセットに利用可能なアップリンク送信リソースがある場合、アップリンク送信リソースでのビームレポートおよび他のアップリンク制御情報を受信するように設定されてもよい。

本開示のさらに他の実施形態では、アップリンク送信リソースは、物理アップリンク制御チャネル（ＰＵＣＣＨ）、物理アップリンク共有チャネル（ＰＵＳＣＨ）のいずれかを含んでもよい。

本開示のさらに他の実施形態では、ビームレポートおよび他のアップリンク制御情報を搬送するアップリンク送信リソースは、所定の選択優先度に基づいて決定されてもよい。

本開示の別の実施形態では、情報受信モジュール２６０１は、ビームレポートおよびハイブリッド自動再送要求（ＨＡＲＱ）を、異なるレポートチャネル、同じレポートチャネル内の同じ符号化部分、同じレポートチャネル内の異なる符号化部分のいずれかに／内で受信するようにさらに設定されてもよい。

本開示のさらなる実施形態では、ビームレポート受信の場合、装置２６００は、事前設定されたリソースセットから、ペイロードのサイズまたはレポートされるビームの数のいずれかに関する所定の選択ルールに基づくビームレポートのためのアップリンク送信リソースを確定するリソース確定モジュール２６０３をさらに含んでもよい。

本開示のさらに他の実施形態では、所定の選択ルールは、ビームレポート送信のためのアップリンク送信リソースの選択順序をさらに定義してもよい。

本開示のさらに他の実施形態では、装置２６００は、第１のセグメント受信モジュール２６０４および第２の受信モジュール２６０５をさらに含んでもよい。第１のセグメント受信モジュール２６０４は、第１のビームのアイデンティティ、第１のビームのチャネル品質指示、および後続ビームレポートセグメントが存在するかどうかを示す後続セグメント指示情報を含む第１のビーム受信セグメントを受信するように設定されてもよい。第２のセグメント受信モジュール２６０５は、後続セグメント指示情報によって後続ビームレポートセグメントが存在することを示す場合のみ、少なくとも１つの後続のビームに関する情報を含む少なくとも１つの後続ビームレポートセグメントを受信するように設定されてもよい。

本開示の別の実施形態では、後続セグメント指示情報は、後続のビームのチャネル品質指示の所定の値によって示されてもよい。

本開示のさらなる実施形態では、後続セグメント指示情報は、所定のビットによって示されてもよい。

本開示のさらに他の実施形態では、第１のビームレポートセグメントおよび少なくとも１つの後続のセグメントは、異なるレポートチャネル、同じレポートチャネル内の同じ符号化部分、同じレポートチャネル内の異なる符号化部分のいずれかに／内で受信されてもよい。

以上、図２５と２６を参照して、装置２５００および２６００について概要が説明された。装置２５００および２６００は、図１から２４を参照して説明された機能を実装するように設定され得ることに留意されたい。したがって、これらの装置内のモジュールの動作の詳細については、図１から２４を参照して方法のそれぞれのステップに関してなされた説明を参照できる。

さらに、装置２５００および２６００の構成要素は、ハードウェア、ソフトウェア、ファームウェア、および／またはそれらの任意の組み合わせで具現化され得ることに留意されたい。たとえば、装置２５００および２６００の構成要素は、回路、プロセッサ、または他の任意の適切な選択デバイスによってそれぞれ実装されてもよい。

前述の例は例示のためにのみ示されており限定されるものではなく、本開示はそれに限定されないことが、当業者にとって理解される。本明細書で提供される教示から多くの変形、追加、削除および修正を容易に想定することができ、これらの変形、追加、削除および修正はすべて本開示の保護範囲に含まれる。

さらに、本開示のいくつかの実施形態では、装置２５００および２６００は、少なくとも１つのプロセッサを備えてもよい。本開示の実施形態と共に使用するために適した少なくとも１つのプロセッサは、一例として、既に知られているかまたは将来開発される汎用および専用プロセッサの両方を含んでもよい。装置２５００および２６００は、少なくとも１つのメモリをさらに備えてもよい。少なくとも１つのメモリは、例えば、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイスどの半導体メモリデバイスを含んでもよい。少なくとも１つのメモリは、コンピュータ実行可能命令のプログラムを格納するために使用されてもよい。プログラムは、ハイレベルおよび／またはローレベルの適合可能または解釈可能な任意のプログラミング言語で記述できる。実施形態によれば、コンピュータ実行可能命令は、少なくとも１つのプロセッサにより、装置２５００および２６００に、少なくとも図１から２４を参照して説明した方法にかかる動作を実行させるように構成されることができる。

図２７は、本明細書で説明される、無線ネットワーク内の基地局（ｇＮＢ）のようなネットワークノードとして具現化されまたはそれに備えられる装置２７１０、およびＵＥのような端末デバイスとして具現化されまたはそれに備えられる装置２７２０の簡略ブロック図を概略的に示す。

装置２７１０は、データプロセッサ（ＤＰ）などの少なくとも１つのプロセッサ２７１１と、プロセッサ２７１１に結合された少なくとも１つのメモリ（ＭＥＭ）２７１２とを備える。装置２７１０は、装置２７２０に通信可能に接続するように動作可能な、プロセッサ２７１１に結合された送信機ＴＸおよび受信機ＲＸ２７１３をさらに備えてもよい。ＭＥＭ２７１２は、プログラム（ＰＲＯＧ）２７１４を格納する。ＰＲＯＧ２７１４は、関連付けられたプロセッサ２７１１上で実行されると、装置２７１０が本開示の実施の形態に従って動作し、例えば、方法２２００、２３００、２４００、またはそれらの組み合わせのいずれかを実行することを可能にする命令を含んでもよい。少なくとも１つのプロセッサ２７１１と少なくとも１つのＭＥＭ２７１２との組み合わせは、本開示の様々な実施形態を実装するのに適合された処理手段２７１５を形成してもよい。

装置２７２０は、ＤＰなどの少なくとも１つのプロセッサ２７２１と、プロセッサ２７２１に結合された少なくとも１つのＭＥＭ２７２２とを備える。装置２７２０は、装置２７１０との無線通信のために動作可能な、プロセッサ２７２１に結合された適切なＴＸ／ＲＸ２７２３をさらに備えてもよい。ＭＥＭ２７２２は、ＰＲＯＧ２７２４を格納する。ＰＲＯＧ２７２４は、関連付けられたプロセッサ２７２１上で実行されると、装置２７２０が本開示の実施形態に従って動作し、たとえば、方法１００、５００、１２００、またはそれらの組み合わせのいずれかを実行することを可能にする命令を含んでもよい。少なくとも１つのプロセッサ２７２１と少なくとも１つのＭＥＭ２７２２の組み合わせは、本開示の様々な実施形態を実装するのに適合された処理手段２７２５を形成してもよい。

本開示の様々な実施形態は、プロセッサ２７１１、２７２１のうちの１つ以上によって実行可能なコンピュータプログラム、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組み合わせによって実装されてもよい。

ＭＥＭ２７１２および２７２２は、ローカルの技術的環境に適した任意のタイプのものでもよく、非限定的な例として、半導体ベースのメモリデバイス、磁気メモリデバイスおよびシステム、光学メモリデバイスおよびシステム、固定メモリおよびリムーバブルメモリなど、任意の適切なデータ記憶技術を使用して実装されてもよい。

プロセッサ２７１１および２７２１は、ローカルの技術的環境に適した任意のタイプでもよく、非限定的な例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタルシグナルプロセッサＤＳＰおよびマルチコアプロセッサアーキテクチャに基づくプロセッサのうちの１つ以上を含んでもよい。

加えて、本開示は、また、上述のようなコンピュータプログラムを含むキャリアを提供してもよく、キャリアは、電子信号、光信号、無線信号、またはコンピュータ読み取り可能な記憶媒体のうちの１つでもよい。コンピュータ読み取り可能な記憶媒体は、例えば、光学コンパクトディスク、またはＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（読み取り専用メモリ）、フラッシュメモリ、磁気テープ、ＣＤ−ＲＯＭ、ＤＶＤ、Ｂｌｕｅ−ｒａｙディスクなどのような電子メモリデバイスでもよい。

本明細書で説明された技術は、様々な手段で実施されてもよい。そのため、実施形態で説明された対応する装置の１つまたは複数の機能を実装する装置が先行技術の手段を備えるだけでなく、実施形態で説明された対応する装置の１つまたは複数の機能を実装するための手段を備え、別々の機能のための別々の手段を備えてもよいし、２つ以上の機能を実行するように設定される手段を備えてもよい。例えば、これらの技術は、ハードウェア（１つ以上の装置）、ファームウェア（１つ以上の装置）、ソフトウェア（１つ以上のモジュール）、またはそれらの組み合わせで実装されてもよい。ファームウェアまたはソフトウェアの場合、本明細書で説明された機能を実行するモジュール（例えば、手順、機能など）を介して実装されてもよい。

本明細書における例示的な実施形態は、方法および装置のブロック図およびフローチャート図を参照して上記で説明された。ブロック図およびフローチャート図の各ブロック、ならびにブロック図およびフローチャート図におけるブロックの組み合わせは、それぞれ、コンピュータプログラム命令を含む様々な手段によって実装できることが理解される。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、または機械を製造するための他のプログラム可能なデータ処理装置にロードされ、コンピュータまたは他のプログラム可能なデータ処理装置で実行される命令が、フローチャートのブロックで特定された機能を実行するための手段を形成するようにしてもよい。

本明細書は多くの具体的な実装の詳細を含むが、これらはいかなる実装または特許請求の範囲に対する限定とするものではなく、むしろ特定の実装の特定の実施形態に特有の機能の説明として解釈されるべきである。本明細書において別々の実施形態の文脈で説明された特定の特徴は、単一の実施形態において組み合わせて実装されることもできる。逆に、単一の実施形態の文脈で説明された様々な特徴は、別々にまたは任意の適切なサブコンビネーションで複数の実施形態で実装されることもできる。さらに、特徴が特定の組み合わせで動作するものとして上記で説明され、当初はそのように特許請求されていても、請求された組み合わせからの１つ以上の特徴は、場合によっては、その組み合わせから除外することができ、請求された組み合わせはサブコンビネーションまたはサブコンビネーションのバリエーションに向けられてもよい。

技術の進歩にしたがい、本発明の概念を様々な方法で実施できることは、当業者にとって明らかである。上記の実施形態は、本開示を限定するのではなく説明するために提供され、当業者が容易に理解するように、本開示の意図および範囲から逸脱することなく修正および変更することができる。そのような修正および変更は、本開示の範囲および添付の特許請求の範囲内にあると見なされる。本開示の保護範囲は、添付の特許請求の範囲によって定義される。

Claims (4)

1. 第１のレポートと第２のレポートが衝突する場合に、送信優先度に基づいて、前記第１のレポートまたは前記第２のレポートのいずれかのみを送信する端末であって、
   PUSCH (Physical Uplink Shared CHannel) における、前記送信優先度は、
   L1-RSRP (Reference Signal Received Power) を含む非周期的なレポート、
   非周期的な CSI (Channel State Information) レポート、
   L1-RSRPを含む半永続的なレポート、
   半永続的な CSIレポート、
   の順であって、
   前記非周期的な CSIレポートは、前記L1-RSRPを含む非周期的なレポートとは、異なるレポートであり、
   前記半永続的な CSIレポートは、前記L1-RSRPを含む半永続的なレポートとは、異なるレポートである、
   端末。
2. 第１のレポートと第２のレポートが衝突する場合に、送信優先度に基づいて、前記第１のレポートまたは前記第２のレポートのいずれかのみを送信する端末であって、
   PUCCH (Physical Uplink Control CHannel) における、前記送信優先度は、
   L1-RSRP (Reference Signal Received Power) を含む半永続的なレポート、
   半永続的なCSI (Channel State Information) レポート、
   L1-RSRPを含む周期的なレポート、
   周期的な CSIレポート、
   の順であって、
   前記半永続的な CSIレポートは、前記L1-RSRPを含む半永続的なレポートとは、異なるレポートであり、
   前記周期的な CSIレポートは、前記L1-RSRPを含む周期的なレポートとは、異なるレポートである、
   端末。
3. 第１のレポートと第２のレポートが衝突する場合に、送信優先度に基づいて、前記第１のレポートまたは前記第２のレポートのいずれかのみを送信し、
   PUSCH (Physical Uplink Shared CHannel) における、前記送信優先度は、
   L1-RSRP (Reference Signal Received Power) を含む非周期的なレポート、
   非周期的な CSI (Channel State Information) レポート、
   L1-RSRPを含む半永続的なレポート、
   半永続的な CSIレポート、
   の順であって、
   前記非周期的な CSIレポートは、前記L1-RSRPを含む非周期的なレポートとは、異なるレポートであり、
   前記半永続的な CSIレポートは、前記L1-RSRPを含む半永続的なレポートとは、異なるレポートである、
   方法。
4. 第１のレポートと第２のレポートが衝突する場合に、送信優先度に基づいて、前記第１のレポートまたは前記第２のレポートのいずれかのみを送信し、
   PUCCH (Physical Uplink Control CHannel) における、前記送信優先度は、
   L1-RSRP (Reference Signal Received Power) を含む半永続的なレポート、
   半永続的な CSI (Channel State Information) レポート、
   L1-RSRPを含む周期的なレポート、
   周期的な CSIレポート、
   の順であって、
   前記半永続的な CSIレポートは、前記L1-RSRPを含む半永続的なレポートとは、異なるレポートであり、
   前記周期的な CSIレポートは、前記L1-RSRPを含む周期的なレポートとは、異なるレポートである、
   方法。

Images