JP2020535719A - 端末デバイス、ネットワークデバイス、および方法 - Google Patents

Abstract

本開示の実施形態は、ビームトラッキングリクエストを処理するための方法、端末デバイスおよび装置、ならびに、ビームトラッキングリクエストを送信するための方法、ネットワークデバイスおよび装置に関する。本開示の一実施形態では、ビームトラッキングリクエストを処理する方法は、ビーム識別情報を含むビームトラッキングリクエストを受信し、ビームトラッキングリクエストへの応答としてコンファメーションを送信し、コンファメーションとしてアクノレッジメントが送信された場合、ビームトラッキングリクエストに対応する動作を実行してもよい。本開示の実施形態によれば、ビームオペレーションの信頼性を維持しつつ、遅延を低減するソリューションを提供することができ、特に緊急の場合に有効である。【選択図】図４

Description

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

ＮＲシステムまたはＮＲネットワークとも呼ばれる、新無線アクセスシステム（New radio access system）は、次世代通信システムである。３ＧＰＰ（Third Generation Partnership Project）ワーキンググループのＲＡＮ（Radio Access Network）＃７１ミーティングで、ＮＲシステムの検討が承認された。ＮＲシステムは、拡張モバイルブロードバンド、大容量マシンタイプ通信、超高信頼性および低遅延通信などの要件が含まれる、テクニカルレポートＴＲ３８．９１３で定義されている全ての使用シナリオ、要件、および展開シナリオに対処する単一のテクニカルフレームワークを目的とし、１００ＧＨｚまでのレンジの周波数が考慮される。

３ＧＰＰ ＲＡＮ１＃９０では、ビーム障害（beam failure）に関して２つのケースがあることが合意された。第１のケースでは、全てのサービング制御チャネル（serving control channel）が障害（fail）の場合にのみ、ビーム障害が表明される。第２のケースでは、サービング制御チャネルのサブセットが障害となり、そのイベントも処理される必要がある。

ビームレポートインスタンス（beam reporting instance）では、ＵＥは同時に受信できるＮ個の異なる送信（transmit：Ｔｘ）ビームを報告するように構成することができ、ＵＥは所定のレポートインスタンスでＮ個以下のビームを報告してもよい。

さらに、ＰＤＣＣＨ（Physical Downlink Control Channel）のロバスト性を向上させるために、マルチビームオペレーションを使用することが合意された。説明のために、図１にマルチビームオペレーションのために可能なオプションを示す。図１には、４つの可能なＣＯＲＥＳＥＴ（control channel resource set）のコンフィグレーションである、ＣＯＲＥＳＥＴ＃１から＃４を使用した３つのオプションが示されている。オプション１では、ＣＯＮＲＥＳＥＴ＃１および＃２は、ＣＯＲＥＳＥＴレベルで構成（設定）されたマルチビームオペレーションであり、ＣＯＮＲＥＳＥＴ＃１では、全てのＰＤＣＣＨ（Physical Downlink Control Channel）Ｃａｎｄｉｄａｔｅ（候補）＃１からＣａｎｄｉｄａｔｅ＃４は、ドットで塗りつぶされた楕円によって示されたビーム１で搬送（carry）される。ＣＯＮＲＥＳＥＴ＃２では、全てのＰＤＣＣＨ（Physical Downlink Control Channel）Ｃａｎｄｉｄａｔｅ＃１から＃４は、クロスで塗りつぶされた楕円によって示されたビーム２で繰り返し搬送される。オプション２では、ＣＯＲＥＳＥＴ＃３は、ＰＤＣＣＨレベルで構成されたマルチビームオペレーションであり、ＰＤＣＣＨ Ｃａｎｄｉｄａｔｅ＃１および＃２は、ドットで塗りつぶされた楕円によって示されたビーム１で搬送されるのに対し、ＰＤＣＣＨ Ｃａｎｄｉｄａｔｅ＃３および＃４は、クロスで塗りつぶされた楕円によって示されたビーム２で搬送される。オプション３では、ＣＯＲＥＳＥＴ＃４は、ＲＢＧ（resource block group）またはＣＣＥ（control channel element）レベルで構成されたマルチビームオペレーションであり、ＰＤＣＣＨ Ｃａｎｄｉｄａｔｅ＃１から＃４のそれぞれの一部分は、ビーム１で搬送され、その他の部分は、ビーム２で搬送される。

マルチビームオペレーションでは、サービング制御チャネルのサブセットのみが障害となる可能性があり、そのような場合、部分的なビーム障害を処理する必要がある。

３ＧＰＰ技術文書Ｒ１−１７１３４２０では、ビームトラッキングの遅延（latency）と信頼性（reliability）を改善するソリューションが開示されている。図２に示すように、提案されたソリューションでは、ネットワークによってビーム障害が検出された場合、または端末デバイスからビームスイッチリクエストが受信された場合、ＤＣＩ（Downlink Control Information）は、端末デバイスにビームスイッチを通知するためビームスイッチ信号として使用され、ＤＣＩの受信に応答して、端末デバイスは、タイムインターバルｍ以内にアクノレッジメント（ＡＣＫ）をネットワークに送信し、そして、所定のタイムピリオドＳ_ｄが満了した後、ネットワークと端末デバイスは、同時にビームスイッチを実行する。開示されたソリューションでは、ビームスイッチは、端末デバイスからネットワークデバイスに送信されたＡＣＫの後にのみ実行され、それにより長い応答時間が生じる。

国際公開第２０１７／１２３０６０６１号では、ＲＡＣＨ（random access channel）手順（procedure）に基づくビームトラッキングソリューションも提案されている。図３に示すように、端末デバイスは、ビーム変更／スイッチをトリガし得るＲＡＣＨプリアンブルを送信し、ネットワークは、明示的なビーム変更／スイッチ命令をＭｓｇ４と一緒にまたは個別に送信して、端末デバイスにビームの変更を指示する。このソリューションは、ビーム障害の第１のケース、つまり全てのビームが同様に障害となるケースに適しており、また、処理遅延の増加につながる可能性がある。

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

本開示の第１の態様によれば、ビームトラッキングリクエストを処理する方法が提供される。この方法では、ビーム識別情報を含むビームトラッキングリクエストを受信し、前記ビームトラッキングリクエストへの応答としてコンファメーションを送信し、前記コンファメーションとしてアクノレッジメントが送信された場合、前記ビームトラッキングリクエストに対応する動作を実行する。

本開示の第２の態様によれば、ビームトラッキングリクエストを送信する方法が提供される。この方法では、ビーム識別情報を含むビームトラッキングリクエストを送信し、前記ビームトラッキングリクエストへの応答としてコンファメーションを受信し、前記コンファメーションとしてアクノレッジメントを受信したことに応じて、前記ビームトラッキングリクエストに対応する動作を実行する。

本開示の第３の態様によれば、ネットワークノードが提供される。このネットワークノードは、ビーム識別情報を含むビームトラッキングリクエストを受信し、前記ビームトラッキングリクエストへの応答としてコンファメーションを送信するように構成されたトランシーバと、前記コンファメーションとしてアクノレッジメントが送信された場合、前記ビームトラッキングリクエストに対応する動作を実行するように構成されたプロセッサと、を備える。

本開示の第４の態様によれば、端末デバイスが提供される。この端末デバイスは、ビーム識別情報を含むビームトラッキングリクエストを送信し、前記ビームトラッキングリクエストへの応答としてコンファメーションを受信するように構成されたトランシーバと、前記コンファメーションとしてアクノレッジメントを受信したことに応じて、前記ビームトラッキングリクエストに対応する動作を実行するように構成されたプロセッサと、を備える。

本開示の第５の態様によれば、ネットワークデバイスが提供される。このネットワークデバイスは、プロセッサおよびメモリを備える。このメモリは、前記プロセッサに結合され、前記プロセッサで実行することによりネットワークデバイスに第２の態様の方法を実行させるプログラムコードを有する。

本開示の第６の態様によれば、端末デバイスが提供される。この端末デバイスは、プロセッサおよびメモリを備える。このメモリは、前記プロセッサに結合され、前記プロセッサで実行することにより端末デバイスに第１の態様の方法を実行させるプログラムコードを有する。

本開示の第７の態様によれば、コンピュータプログラムコードを有するコンピュータ可読記憶媒体が提供され、このコンピュータプログラムコードは、実行されることにより、装置に、第１の態様の任意の実施形態に係る方法の動作を実行させるように構成される。

本開示の第８の態様によれば、コンピュータプログラムコードを有するコンピュータ可読記憶媒体が提供され、このコンピュータプログラムコードは、実行されることにより、装置に、第２の態様の任意の実施形態に係る方法の動作を実行させるように構成される。

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

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

本開示の実施形態によれば、ビームオペレーションの信頼性を維持しつつ、遅延を低減するソリューションを提供することができ、特に緊急の場合に有効である。

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

図１は、マルチビームオペレーションのための可能なオプションを概略的に示す。

図２は、ビームトラッキングの遅延および信頼性を改善するための既存のソリューションを概略的に示す。

図３は、ＲＡＣＨ（Random Access Channel）手順によるネットワークベースのビームトラッキングを概略的に示す。

図４は、本開示の実施形態に係るビームトラッキングリクエストを処理する方法のフローチャートを概略的に示す。

図５Ａは、本開示の実施形態に係るビームトラッキングリクエストのコンファメーションの例示的な伝送オプションを概略的に示す。 図５Ｂは、本開示の実施形態に係るビームトラッキングリクエストのコンファメーションの例示的な伝送オプションを概略的に示す。 図５Ｃは、本開示の実施形態に係るビームトラッキングリクエストのコンファメーションの例示的な伝送オプションを概略的に示す。 図５Ｄは、本開示の実施形態に係るビームトラッキングリクエストのコンファメーションの例示的な伝送オプションを概略的に示す。 図５Ｅは、本開示の実施形態に係るビームトラッキングリクエストのコンファメーションの例示的な伝送オプションを概略的に示す。

図６は、本開示の実施形態に係る可能な信号パスを概略的に示す。

図７Ａは、本開示の実施形態に係るビームトラッキングリクエストに対応する例示的な動作を概略的に示す。 図７Ｂは、本開示の実施形態に係るビームトラッキングリクエストに対応する例示的な動作を概略的に示す。 図７Ｃは、本開示の実施形態に係るビームトラッキングリクエストに対応する例示的な動作を概略的に示す。 図７Ｄは、本開示の実施形態に係るビームトラッキングリクエストに対応する例示的な動作を概略的に示す。

図８は、本開示の実施形態に係るビームトラッキング手順のシグナリング図を概略的に示す。

図９Ａは、本開示の実施形態に係る例示的な可能なＰＤＣＣＨ伝送オプションを概略的に示す。 図９Ｂは、本開示の実施形態に係る例示的な可能なＰＤＣＣＨ伝送オプションを概略的に示す。 図９Ｃは、本開示の実施形態に係る例示的な可能なＰＤＣＣＨ伝送オプションを概略的に示す。

図１０Ａは、本開示の実施形態に係る例示的なビームセットアップデートを概略的に示す。 図１０Ｂは、本開示の実施形態に係る例示的なビームセットアップデートを概略的に示す。

図１１は、本開示の実施形態に係る例示的な障害のビームインディケーションを概略的に示す。

図１２Ａは、本開示の実施形態に係る例示的なビーム品質インディケーションを概略的に示す。 図１２Ｂは、本開示の実施形態に係る例示的なビーム品質インディケーションを概略的に示す。

図１３は、本開示の実施形態に係るビームトラッキングリクエストを送信する方法のフローチャートを概略的に示す。

図１４は、本開示の実施形態に係るビームトラッキングリクエストを処理する装置のブロック図を概略的に示す。

図１５は、本開示の実施形態に係るビームトラッキングリクエストを送信する装置のブロック図を概略的に示す。

図１６は、本明細書に記載されている、ｇＮＢのようなネットワークデバイスとして具現化または構成される装置１６１０、およびＵＥのような端末デバイスとして具現化または構成される装置１６２０の簡略ブロック図を概略的に示す。

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

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

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

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

背景で述べたように、既存のソリューションはネットワークベースのビームスイッチソリューションであり、処理遅延の増加につながる可能性がある。このために、本開示では、処理遅延を低減するためのビームトラッキングリクエストのための新しいソリューションを提案する。提案されたソリューションでは、リクエストおよびグラントモードを採用し、ビームトラッキングリクエストのための明示的な「グラント（許可、承認）」により、遅延を増加させることなく、対応する動作を実行できるようにする。

以下、さらに図４から図１６を参照して、本開示で提案されるソリューションを詳細に説明する。以下の実施形態は、例示の目的でのみ提供されるものであり、本開示はそれらに限定されないことが理解される。

まず図４を参照する。図４は、本開示の一実施形態に係るビームトラッキングリクエストを処理する方法のフローチャートを概略的に示す。方法４００は、例えばｇＮＢなどのネットワークデバイスやネットワークノード、または、他の同様のネットワークデバイスで実行することができる。

図４に示すように、まずステップ４０１で、ネットワークデバイスは、端末デバイスからビームトラッキングリクエスト（beam tracking request）を受信する。ビームモニタリング中に、端末デバイスは、サービングビームが障害（fail：フェイル）となったこと、新しいビームがあること、または劣化（degrade：デグレード）したビームからより良いビームへのビームスイッチが必要であることなどを検出し、そのような場合、端末デバイスは、ネットワークデバイスへビームトラッキングリクエストを送信できる。ビームトラッキングリクエストは、ネットワークがビームトラッキングリクエストに対応する動作（オペレーション）を実行できることを知ることができるように、ビーム識別情報（beam identification information）を含んでもよい。ビーム識別情報は、例えば、障害のビーム（failed beam：フェイルビーム）ＩＤ、新しいビームＩＤ、またはそれらの両方を含んでもよい。ビームトラッキングリクエストは、必要に応じて、ビームトラッキングタイプ情報をさらに含んでもよい。ビームトラッキングにビーム識別情報のみが含まれる場合、デフォルトのビームトラッキングタイプがあるときは、ビームトラッキングタイプ情報は明示的に送信されなくてもよい。ビームトラッキングリクエストのタイプには、以下が含まれるが、これらに限定されない。（１）劣化したサービングビームからより良いビームへのビームスイッチのためのリクエスト、（２）現在のサービングビームセットから障害のビームをリムーブするためのリクエスト、（３）現在のサービングビームセットに新しいビームを追加するためのリクエスト、（４）さらなるビームマネジメントのないビームリカバリのためのリクエスト。ビームリカバリでは、端末デバイスによって提供された新しいビームを使用することによって、ダウンリンクの障害のビームを回復する。ビームトラッキングリクエストは、ＰＵＣＣＨ（Physical Uplink Control Channel）で送信されてもよい。別の例として、ビームトラッキングリクエストは、ＰＲＡＣＨ（Physical Random Channel）で送信されてもよい。

次に、ステップ４０２で、ネットワークデバイスは、ビームトラッキングリクエストに対する応答としてコンファメーション（confirmation：確認）を送信する。ビームトラッキングリクエストを受信すると、ネットワークデバイスがビームトラッキングリクエストに対応する動作（オペレーション）を実行することを決定した場合、ネットワークデバイスは、直ちにビームトラッキングリクエストの肯定的コンファメーションを端末デバイスに送信する。肯定的コンファメーションは、例えば、アクノレッジメント（acknowledgement：ＡＣＫ）であり得る。ネットワークがビームトラッキングリクエストに対応する動作を実行しないことを決定した場合、ネットワークは、否定的アクノレッジメント（ＮＡＣＫ）を送信して端末デバイスに明示的に通知してもよいし、また、何も送信せずに暗黙的に端末デバイスに通知してもよい。以下では、例示の目的で、コンファメーションの例としてＡＣＫを採用するが、当業者は、ＡＣＫのいくつかの説明がＮＡＣＫにも適用できることを理解することができる。

本開示の一実施形態では、コンファメーションは、ＰＤＣＣＨ（Physical Downlink Control Channel）で送信することができる。図５Ａに示すように、ビームトラッキングリクエストは、ＰＵＣＣＨまたはＰＲＡＣＨによって搬送することができ、ＡＣＫは、ＰＤＣＣＨでＤＣＩに含めることができる。このような場合、ＡＣＫ／ＮＡＣＫを搬送するためのいくつかのオプションがある。

一つのオプションでは、ＡＣＫは、ＴＡ（Time Advance）、ＲＡ（Resource Allocation）、ＱＣＬ（Quasi-colocation）インディケータなどの他のコンテンツを含むことなく、端末デバイスアイデンティティ（identity）によってスクランブルされたＰＤＣＣＨで示される（インディケートされる）ことができる。言い換えると、端末デバイスがＰＤＣＣＨのデスクランブルに成功した場合、それは以前に送信されたビームトラッキングリクエストに対するＡＣＫを意味する。ＰＤＣＣＨをスクランブル／デスクランブルするための端末デバイスアイデンティティは、ビームトラッキングの目的にのみ使用される特別な目的のアイデンティティでもよいし、または、他の目的のためのアイデンティティを再利用してもよい。さらに、端末デバイスアイデンティティは、特定のランダムシーケンス、時間−周波数リソースアサイメント、またはＣＲＣコードなどに基づいて決定されてもよい。

別のオプションでは、ＡＣＫ／ＮＡＣＫは、ＬＴＥのＤＣＩフォーマット３のように、端末デバイスのグループに共通のアイデンティティによってスクランブルされたＰＤＣＣＨ内のターゲット端末デバイスに対応するビットによって示されることができる。ＰＤＣＣＨによって搬送されるＤＣＩは、複数のビットフィールドを含み、そのそれぞれは、グループ内の端末デバイスの１つに専用である。これにより、端末デバイスのグループは、ＰＤＣＣＨを受信することができ、各端末デバイスは、端末デバイス専用のビットフィールドでそのＡＣＫ／ＮＡＣＫを取得することができる。

さらなるオプションでは、ＰＤＣＣＨのＤＣＩに新しいビットを追加できる。このＤＣＩには、ＴＡ、ＲＡ、ＱＣＬ（Quasi-colocation）インディケータなどの他のコンテンツが含まれてもよい。言い換えれば、ＡＣＫ／ＮＡＣＫは、ＰＤＣＣＨのＤＣＩにおける新しいビットによって示されてもよい。

さらに別のオプションでは、ＡＣＫは、ＰＤＣＣＨにおいてビームトラッキングリクエストを繰り返す情報によって示されることができる。言い換えると、ビームトラッキングリクエストに含まれるものと同じ情報を含むように、ビームトラッキングリクエストをＰＤＣＣＨで再送信することができ、端末デバイスはビームトラッキングリクエストのためのＡＣＫとしてそれを識別できるようになる。

図５Ｂは、本開示の一実施形態に係るビームトラッキングリクエストのコンファメーションの別の例示的な伝送オプションを概略的に示す。図５Ｂに示されるように、ビームトラッキングリクエストは、ＰＵＣＣＨまたはＰＲＡＣＨによって搬送することができ、ＡＣＫは、ＰＤＣＣＨでＤＣＩに含めることができる。しかしながら、図５Ａとは異なり、ＰＤＣＣＨは２つの部分を含み、一方の部分はＰＵＣＣＨのＡＣＫのために新しく追加されたビットを含み、他方の部分は他の目的のためのＤＣＩである。

図５Ｃは、本開示の一実施形態に係るビームトラッキングリクエストのコンフィグレーション（構成、設定）のさらなる例示的な伝送オプションを概略的に示す。図５Ｃでは、ビームトラッキングリクエストは、ＰＵＣＣＨまたはＰＲＡＣＨによって搬送することができ、ビームトラッキングリクエストに対するＡＣＫは、コンファメーションを端末デバイスに通知するためにＭＡＣ−ＣＥで搬送することができる。

図５Ｄは、本開示の一実施形態に係るビームトラッキングリクエストのコンファメーションのさらに別の例示的な伝送オプションを概略的に示す。図５Ｄでは、ビームトラッキングリクエストは、ＰＵＣＣＨまたはＰＲＡＣＨによって搬送することができ、ビームトラッキングリクエストに対するＡＣＫは、アップリンクデータ伝送がない場合、ＰＨＩＣＨ（Physical Hybrid-ARQ Indicator Channel）で搬送することができる。そのような場合、端末デバイスへのＰＨＩＣＨのダウンリンクリソースは、ＰＵＣＣＨおよびＤＭＲＳのＩＤのリソースアロケーションに基づくことができる。

図５Ｅは、本開示の一実施形態に係るビームトラッキングリクエストのコンファメーションのなおさらなる例示的な伝送オプションを概略的に示す。図５Ｅでは、ビームトラッキングリクエストとアップリンクデータが同時に伝送（送信）され、２つの伝送（送信）のためのコンファメーションが必要である。そのような場合、ビームトラッキングリクエストは、ＰＵＣＣＨまたはＰＲＡＣＨによって搬送することができ、ビームトラッキングリクエストに対するＡＣＫおよびＰＵＳＣＨのアップリンクデータ伝送に対するＡＣＫは、それぞれＰＨＩＣＨおよびＰＤＣＣＨによって搬送することができる。例えば、ビームトラッキングリクエストのコンファメーションをＰＤＣＣＨで送信し、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションをＰＨＩＣＨで送信してもよい。別の例として、ビームトラッキングリクエストのコンファメーションをＰＨＩＣＨで送信し、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションをＰＤＣＣＨで送信してもよい。

ビームトラッキングリクエストとアップリンクデータ伝送のコンファメーションは、別の方法で送信してもよい。例えば、ビームトラッキングリクエストのコンファメーションは、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションと多重化されてもよい。多重化は、周波数分割多重または符号分割多重のいずれかを使用してもよい。

さらに、ビームトラッキングリクエストとアップリンクデータ伝送のコンファメーションは、一緒にバンドルされてもよい（まとめてもよい）。言い換えると、ビームトラッキングリクエストのコンファメーションは、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションをさらに示してもよい。説明のために、２つの例示的なバンドリングの設定Ａおよび設定Ｂを示す。
・設定Ａ：
１．データＡＣＫ＋ビームトラッキングリクエストＡＣＫ＝ＡＣＫ
２．データＮＡＣＫ＋ビームトラッキングリクエストＮＡＣＫ＝ＮＡＣＫ
３Ａ．データＮＡＣＫ＋ビームトラッキングリクエストＡＣＫ＝ＮＡＣＫ
４Ａ．データＡＣＫ＋ビームトラッキングリクエストＮＡＣＫ＝ＡＣＫ
・設定Ｂ：
１．データＡＣＫ＋ビームトラッキングリクエストＡＣＫ＝ＡＣＫ
２．データＮＡＣＫ＋ビームトラッキングリクエストＮＡＣＫ＝ＮＡＣＫ
３Ｂ．データＮＡＣＫ＋ビームトラッキングリクエストＡＣＫ＝ＡＣＫ
４Ｂ．データＡＣＫ＋ビームトラッキングリクエストＮＡＣＫ＝ＮＡＣＫ

設定Ａまたは設定Ｂの選択は、端末デバイスへのＲＲＣ（Radio Resource Control）シグナリングによって構成（設定）できる。ネットワークデバイスは、構成された設定を使用してコンファメーションを送信することができ、それによって、端末デバイスは、ＲＲＣシグナリングによって構成された設定に基づいてコンファメーションを判断することができる。

上述のようなバンドリング設定およびリソース多重化では、アップリンクデータおよびビームトラッキングリクエストのコンファメーションは、同じまたは異なる優先度を有してもよく、ビームトラッキングリクエストを搬送するＰＵＣＣＨおよびアップリンクデータを搬送するＰＵＳＣＨは、同じタイムスロット内に配置されるべきと理解される。さらに、ＡＣＫは、ＰＨＩＣＨまたはＰＤＣＣＨのいずれかでもよいことも理解される。

図４に戻って参照すると、ステップ４０３において、ネットワークは、ビームトラッキングリクエストに対する応答としてＡＣＫが送信された場合、ビームトラッキングリクエストに対応する動作（オペレーション）を実行する。この動作には、ビームスイッチ、障害のビームのリムーブ、新しいビームの追加、さらなるビームマネジメントのないビームリカバリ、または任意の他の所定のビームトラッキングタイプが含まれてもよい。以下、図６を参照してこれらの動作を説明する。

図６は、本開示の一実施形態に係る可能な信号パスを概略的に示す。図６から、良いパス（good path）は、望ましい信号パスであり、普通のパス（trivial path）は、可能なパスであるが、システムに深刻な影響を与えないことを示し、一方、悪いパス（bad path）は、システムに深刻な影響を与える可能性がある望ましくないパスである。この問題に対処するために、いくつかの改善されたスキームを使用することが提案される。例えば、ネットワークデバイスから端末デバイスにＮＡＣＫを明示的に送信しないことが可能である。これにより、ＡＣＫなしまたは送信なしは、端末デバイスでＮＡＣＫとして理解することができる。別の例として、ＰＵＣＣＨのＵＣＩ（Uplink Control Information）で送信されるビームトラッキングリクエストに、ＣＲＣを追加することができる。これにより、ネットワークは、ＣＲＣチェックを実行してデコードエラーを検出し、誤った受信の可能性を回避できる。したがって、端末デバイスからのビームトラッキングリクエストへの応答として、誤認識を招く可能性のあるコンファメーションの送信が防止される。さらに、ネットワークデバイスが、ＰＤＣＣＨのＤＣＩにおいて端末デバイスのビームトラッキングリクエストを繰り返すことも可能である。このような方法により、端末デバイスにおける誤認識の可能性を適切に低減できる。

図７Ａから７Ｄは、本開示の実施形態に係るビームトラッキングリクエストの異なるタイプに対応して実行される例示的な動作（オペレーション）をさらに概略的に示す。図７Ａは、本開示の一実施形態に係るビームトラッキングリクエストの一つのタイプに対応するビームスイッチ（切り替え）オペレーションを示す。図７Ａに示されるように、ビームトラッキングリクエストに応答して、伝送（送信）は、サービングビームサブセットにおいてより低いチャネル品質を有するビームから、サービングビームサブセットにおいてより良いチャネル品質を有する別のビームに切り替えられる。図７Ｂは、本開示の一実施形態に係るビームトラッキングリクエストの別のタイプに対応する障害のビームのリムーブ（削除）オペレーションを示す。図７Ｂに示すように、ビームトラッキングリクエストに応答して、ビームトラッキングリクエストによって示される、サービングビームサブセット内の障害のビームは、サービングビームサブセットから削除（除去）される。図７Ｃは、本開示の一実施形態に係るビームトラッキングリクエストの別のタイプに対応する新しいビームの追加オペレーションを示す。図７Ｃに示されるように、ビームトラッキングリクエストに応答して、良好なチャネル品質を有する新しいビームが、サービングビームサブセットに追加される。図７Ｄは、本開示の一実施形態に係るビームトラッキングリクエストに対応するさらなるビームマネジメントのないビームリカバリ（回復）オペレーションを示す。図７Ｄに示されるように、ビームトラッキングリクエストに応答して、良好なチャネル品質を有する新しいビームは、サービングビームサブセットにおけるダウンリンク伝送のための障害のビームをリプレースする（置き換える）。ビームトラッキングリクエストは、ビーム識別情報を含んでもよく、必要に応じて、ネットワークデバイスに正確なビームトラッキングタイプを指定するビームトラッキングタイプ情報をさらに含んでもよい。ビームトラッキングタイプ情報は、ビームスイッチ、障害のビームのリムーブ、新しいビームの追加、さらなるビームマネジメントのないビームリカバリオペレーション、および任意の他の所定のビームトラッキングタイプを示すための情報でもよい。所定のビームトラッキングタイプのセットは、端末デバイスへのＲＲＣシグナリングによって構成（設定）できる。ビームトラッキングタイプの一つをデフォルトのビームトラッキングタイプとして暗黙的に設定してもよいし、または、ＲＲＣシグナリングがビームトラッキングタイプの一つをデフォルトとして明示的に設定してもよい。例えば、ビームリカバリリクエストは、ネットワークデバイスと端末デバイスの両方でデフォルトとされてもよい。そのような場合、ビームトラッキングリクエストはビーム識別情報のみを含んでもよく、デフォルトのビームトラッキングタイプは、ビームトラッキングリクエストに応答してネットワークデバイスと端末デバイスの両方で実行される。

ビームトラッキングオペレーションは、ビームトラッキングリクエストを介してＰＵＣＣＨのＵＣＩで要求（リクエスト）され、ＰＤＣＣＨまたはＰＨＩＣＨで承認（アクノレッジ）され得ることが理解される。さらに、ビームが障害とならないサブセットを使用して、必要なＤＬシグナリングを伝達してもよい。

図８は、本開示の一実施形態に係るビームトラッキング手順のシグナリング図を概略的に示す。図８に示すように、まずステップ８０１で、ＵＥのような端末デバイスはビームモニタリングを実行する。ビームモニタリングに基づいてビームトラッキングリクエストを送信する必要があると判断されると、ＵＥは、ステップ８０２で、少なくともビームＩＤとともにビームトラッキングリクエストをネットワークであるｇＮＢに送信する。ビームトラッキングリクエストを受信すると、ｇＮＢは、必要に応じて、ステップ８０３で、ＵＥのリクエストに対する応答としてＡＣＫを送信する。応答シグナリングは、残存（survived：サバイブ）ＤＬビームにオフロードされる。一方、ＵＥは、残存ＤＬビームで応答を受信することのみを期待できる。例えば、ＡＣＫ信号は、ＵＥによってリクエストされた残存ビームの一つで送信される。ビームトラッキングオペレーションは、ＡＣＫ送信／受信から所定の時間オフセットの後に、ネットワークデバイスおよび端末デバイスで同時に実行することができる。所定の時間オフセットは、ＲＲＣシグナリング、及び／または、ＭＡＣ ＣＥシグナリングによって設定（構成）できる。

このような場合、ｇＮＢは、追加の動作（オペレーション）を実行する必要がある。例えば、図９Ａに示すように、ＣＯＲＥＳＴ＃１または＃２をオン／オフしてもよい。図９Ｂに示すように、ＰＤＣＣＨレベルでＰＤＣＣＨ Ｃａｎｄｉｄａｔｅ（候補）のリスケジューリングを選択してもよい。あるいは、図９Ｃに示すように、ｇＮＢは、ＣＣＥまたはＲＧＢレベルでＰＤＣＣＨ Ｃａｎｄｉｄａｔｅのためのリソースをリアサインしてもよい。

さらに、提案されたソリューションでは、２つの定期的なフルレポート間で柔軟なビームセットのアップデートを可能にすることができる。図１０Ａに示すように、サービングビームサブセットが要求される数のビームを含む場合、端末デバイスは、障害のビームがあるとき、障害のビームをリムーブするため、ビームトラッキングリクエストを送信し（１００１ａ）、良好なチャネル品質を有する新しいビームがあるとき、新しいビームを追加するため、別のビームトラッキングリクエストを送信してもよい（１００２ａ）。図１０Ｂに示す別の実施形態では、サービングビームサブセットが要求されるよりも少ないビームを含む場合、端末デバイスは、良好なチャネル品質を有する新しいビームが存在するとき、新しいビームを追加するため、ビームトラッキングリクエストをまず送信し（１００１ｂ）、障害のビームがあるとき、障害のビームをリムーブするため、別のビームトラッキングリクエストを送信してもよい（１００２ｂ）。シンプルなアトミックオペレーションにより、サービングビームサブセットを柔軟な方法でアップデートできる。

本開示の一実施形態では、ビームトラッキングリクエストに含まれるビーム識別情報は、より効率的な方法で示されることができる。例えば、ＵＣＩは、ＵＣＩフィールド１を有してもよく、これは、低オーバヘッドのビットマップによって障害のサービングビームを示すために使用される。提案されたインディケーションスキームでは、ビーム識別情報は、サービングビームセットに基づくビーム識別（identification）を示す。例えば、ビットマップは、現在のサービングビームサブセット、すなわち以前に報告または承認（acknowledge）されたサービングサブセットのみを参照する。例えば、図１１に示すように、８つのビームがあるため、フルビームセット＝｛１、２、３、４、５、６、７、８｝となり、現在、４つのサービングビームしかないため、現在のサービングビームサブセット＝{１、４、５、８}となる。ビーム４とビーム５が障害となった場合、ビットマップは０１１０になり得る。つまり、フルビームセットを考慮せずに、現在のサービングビームセットの２番目と３番目のビームを示す。このような方法により、４ビットのビットマップのみで十分となる。ビットマップは障害のビームと新しいビームの両方を示すために使用できることが理解される。

本開示の別の実施形態では、ＵＣＩは、別のＵＣＩフィールド２をさらに提供してもよく、これは、ビームチャネル品質情報を含む。ビームチャネル品質情報は、サービングビームセットにおける残存ビームに関して報告されたビームの品質関係を表すビーム品質パターンによって示される。

ここで、「ビーム品質パターン」とは、ビーム品質閾値に対するそれぞれのビームの品質関係を示すパターンである。特に、ビーム品質パターンは、その中にそれぞれのビームが配置される閾値レンジを示すことができる。したがって、既存のソリューションとは異なり、ビーム品質パターンに関する情報をネットワークデバイスに送信して、ビーム品質の大まかな情報を提供できる。

ここで、「ビーム品質」とは、ビームのチャネル品質を表すことができる情報であり、ビーム測定量（beam measurement quantity）、ビーム測定値（beam measurement value）、ビームのＣＱＩなど、別の言い方で呼ぶこともできる。例として、ビーム品質は、ビームのＲＳＲＰ（Reference Signal Receiving Power）により示すことができる。以下では、ＲＳＲＰがビーム品質情報の例として採用される。しかしながら、当業者は、それが単に例示の目的で提供され、本開示がそれに限定されないことを容易に理解することができ、実際には、ビーム品質を表すために任意の他の測定（測定値、測定量）を使用することが可能である。

例えば、ビームトラッキングリクエストを搬送するＰＵＣＣＨにファイルされたＵＣＩには、新しいサービングビームＩＤと、オプションでビームチャネル品質オーダー情報を含めることができる。オーダー情報には、さらに、オーダーされたサブセットとビーム品質パターンの２つの部分が含まれてもよい。ビーム品質パターンは、サービングビームセット内の残存ビームのビーム品質に基づいて決定されてもよい。特に、残存ビームのビーム品質は、ビーム品質閾値として使用されてもよい。図１２Ａに示すように、４つの非サービングノード｛２、３、６、７｝があり、ビーム｛３、６｝は、サービングビームサブセットに追加される新しいビームである。オーダーされたサブセットは｛１０、０１｝であり、残存ビーム１および８のＲＳＲＰ値（RSRP value）Ｔ１およびＴ２は、ビーム品質パターンのビーム品質閾値として使用できる。図１２Ｂにさらに示されるように、２つのビーム間には４つの可能なビーム品質関係がある。端末デバイスは、ビーム４および５のパターンを決定し、それをＵＣＩフィールド２に含めてもよい。図１２に示す例では、このパターンはパターンＢであり、例えば１０により示すことができる。その情報を受信した後、ｇＮＢは、基準閾値（reference threshold）Ｔ１およびＴ２に基づいて、ＵＣＩ内に含まれるオーダー情報を知ることができる。

本開示の一実施形態では、異なるＲＳ（reference signal：参照信号）のためのさらに提案される可能なＲＳＲＰテーブルが存在する。提案されたソリューションでは、異なるＲＳＲＰダイナミックレンジを異なる参照信号のために使用できる。例えば、同期信号ブロック（synchronization signal block）は、Ｐ−ＣＳＩ（Periodic Channel State Information）ＲＳよりも小さいＲＳＲＰダイナミックレンジを有することができ、定期的なＣＳＩ ＲＳは、ＡＰ−ＣＳＩ（Aperiodic Channel State Information）ＲＳよりも小さいＲＳＲＰダイナミックレンジを有することができる。説明のために、表１から３にＲＳＲＰテーブルの例を示す。より少ない数のＲＳＲＰステータスに対応するより小さいダイナミックレンジにより、端末デバイスからネットワークデバイスへのＲＳＲＰレポートオーバーヘッドを少なくすることができる。

したがって、提案されたソリューションでは、端末デバイスは、参照信号のタイプに基づいてＲＳＲＰレポートマッピングを選択する。ネットワーク側では、ＲＳＲＰインデックスを受信した後、ｇＮＢは、まず、参照信号のタイプに基づいて使用するＲＳＲＰマッピングテーブルを決定し、次に、ＲＳＲＰインデックスを使用して、決定されたマッピングテーブルから報告されたＲＳＲＰ値を取得する。

本開示の別の実施形態では、一つの標準ＲＳＲＰテーブルのみを使用することも可能であるが、異なる参照信号は、それぞれの閾値レンジに対応するＲＳＲＰインデックスのみを使用する。さらに、異なるタイプの参照信号では、異なるシフト値（shift value）を使用してもよい。例えば、表１を標準マッピングテーブルとして提供することが可能であり、ＳＳＢでは、標準マッピングテーブルを使用できる。一方、Ｐ−ＣＳＩでは、シフト値１０ｄＢｍを各ＲＳＲＰ閾値に適用して、Ｐ−ＣＳＩの新しいテーブルを取得できる。あるいは、同じ標準テーブルを使用してもよいが、対応するシフト値をＲＳＲＰ値に毎回適用して、Ｐ−ＣＳＩのための変更（modify）されたＲＳＲＰ値を取得してもよい。

図１３は、本開示の一実施形態に係るビームトラッキングリクエストを受信する方法１３００のフローチャートを概略的に示す。方法１３００は、例えばＵＥなどの端末デバイス、または他の同様の端末デバイスで実行することができる。

図１３に示すように、まずステップ１３０１で、端末デバイスは、ビーム識別情報を含むビームトラッキングリクエストを送信する。端末デバイス側では、端末デバイスは、全てのビームをモニタすることができ、トリガ条件を満たす場合に、端末デバイスは、ビームトラッキングリクエストをネットワークデバイスに送信できる。ビームトラッキングリクエストは、ネットワークがビームトラッキングリクエストに対応して実行される動作（オペレーション）を知ることができるように、ビーム識別情報を含んでもよい。ビーム識別情報は、例えば、障害のビームＩＤ、新しいビームＩＤ、またはそれらの両方を含んでもよい。ビームトラッキングリクエストは、必要に応じて、ビームトラッキングタイプ情報をさらに含んでもよい。ビーム識別情報のみを含むビームトラッキングリクエストのためにデフォルトのビームトラッキングタイプがある場合、ビームトラッキングタイプ情報は、ビームトラッキングリクエストで送信されなくてもよい。ビームトラッキングリクエストのタイプには、以下が含まれるが、これらに限定されない。（１）劣化したサービングビームからより良いビームへのビームスイッチのためのリクエスト、（２）現在のサービングビームセットから障害のビームをリムーブするためのリクエスト、（３）現在のサービングビームセットに新しいビームを追加するためのリクエスト、（４）さらなるビームマネジメントのないビームリカバリのためのリクエスト。ビームリカバリでは、端末デバイスによって提供された新しいビームを使用することによって、ダウンリンクの障害のビームを回復する。ビームトラッキングリクエストは、ＰＵＣＣＨ（Physical Uplink Control Channel）で送信されてもよい。別の例として、ビームトラッキングリクエストは、ＰＲＡＣＨ（Physical Random Channel）で送信されてもよい。

次に、ステップ１３０２で、端末デバイスは、ビームトラッキングリクエストに対する応答としてコンファメーションを受信する。ビームトラッキングリクエストを受信すると、ネットワークがビームトラッキングリクエストに対応する動作（オペレーション）を実行することを決定した場合、ネットワークは、直ちにビームトラッキングリクエストの肯定的コンファメーションを端末デバイスに送信する。このような場合、端末デバイスは、ネットワークデバイスからビームトラッキングリクエストのコンファメーションを受信してもよい。肯定的コンファメーションは、例えば、ＡＣＫであり得る。必要に応じて、ネットワークは、ＮＡＣＫを送信して端末デバイスに明示的に通知してもよいし、また、何も送信せずに暗黙的に端末デバイスに通知してもよい。

コンファメーションは、ＰＤＣＣＨで受信することができる。例えば、コンファメーションは、端末デバイスアイデンティティによってスクランブルされた任意のＰＤＣＣＨによって示されてもよい。一例として、コンファメーションは、端末デバイスのグループに共通のアイデンティティによってスクランブルされたＰＤＣＣＨにおけるターゲット端末デバイスに対応するビットによって示されてもよい。別の例として、コンファメーションは、ＰＤＣＣＨのＤＣＩ（Downlink Control Information）における新しいビットによって示されてもよい。さらなる例として、コンファメーションは、ＰＤＣＣＨにおいてビームトラッキングリクエストを繰り返す情報によって示されてもよい。ＰＤＣＣＨにおけるコンファメーション伝送オプションの詳細については、図５Ａから５Ｅを参照できる。

コンファメーションは、ＭＡＣ ＣＥによっても搬送することができる。また、ＰＨＩＣＨを使用してコンファメーションを搬送してもよい。例えば、ビームトラッキングリクエストのコンファメーションをＰＨＩＣＨで送信し、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションをＰＤＣＣＨで送信してもよい。別の例として、ビームトラッキングリクエストのコンファメーションをＰＤＣＣＨで送信し、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションをＰＨＩＣＨで送信してもよい。

コンファメーションは、周波数分割多重または符号分割多重のいずれかにより、ＰＵＳＣＨ（Physical Uplink Shared Channel）におけるアップリンクデータ伝送のコンファメーションと多重化されてもよい。さらに、このコンファメーションは、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションとバンドルされてもよい。言い換えると、コンファメーションは、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションをさらに示してもよい。

悪いパス（bad path）からの信号を防ぐために、サーバルスキームがある。本開示の一実施形態では、コンファメーションは、ビームトラッキングリクエストに対するアクノレッジメントのみを含み、ビームトラッキングリクエストに対する否定的アクノレッジメントは送信されなくてもよい。本開示の別の実施形態では、ビームトラッキングリクエストは、ＣＲＣ（Cyclic Redundancy Check：巡回冗長検査）コードとともに送信されてもよい。さらに、ビームトラッキングリクエストは、ＰＤＣＣＨで再送信されてもよい。

本開示の別の実施形態では、柔軟なサービングビームのアップデートを提供するため、ビームトラッキングリクエストは、２つのフルビームレポート間で送信される。

本開示の別の実施形態では、ビームトラッキングリクエストは、ビームチャネル品質情報をさらに含み、ビームチャネル品質情報は、サービングビームセットにおける残存ビームに関して報告されたビームの品質関係を表すビーム品質パターンによって示される。ビーム品質パターンにより、ＲＳＲＰを効率的に報告することができる。

ＡＣＫの受信に応答して、端末デバイスは、ステップ１３０３で、コンファメーションとしてアクノレッジメントを受信したことに応じて、ビームトラッキングリクエストに対応する動作（オペレーション）を実行する。ビームトラッキングリクエストは、ビームスイッチ、障害のビームのリムーブ、新しいビームの追加、さらなるビームマネジメントのないビームリカバリのいずれかの動作（オペレーション）に対応する。

以上、図１３を参照して、ビームトラッキングリクエストを受信する方法の実施形態を簡単に説明した。しかし、端末デバイスにおける動作は、ネットワークデバイスにおける動作に対応しているため、動作のいくつかの詳細については、図４から１２の説明を参照できる。

図１４は、本開示の一実施形態に係るビームトラッキングリクエストを処理する装置のブロック図を概略的に示す。装置１４００は、ｇＮＢなどのネットワークデバイスで実装することができる。

図１４に示すように、装置１４００は、リクエスト受信モジュール１４０１、コンファメーション送信モジュール１４０２、および、オペレーション実行モジュール１４０３を含む。リクエスト受信モジュール１４０１は、ビーム識別情報を含むビームトラッキングリクエストを受信するように構成される。コンファメーション送信モジュール１４０２は、ビームトラッキングリクエストへの応答としてコンファメーションを送信するように構成される。オペレーション実行モジュール１４０３は、コンファメーションとしてアクノレッジメントが送信された場合、ビームトラッキングリクエストに対応する動作（オペレーション）を実行するように構成される。

本開示の一実施形態では、コンファメーションは、ＰＤＣＣＨ、ＭＡＣ ＣＥ、ＰＨＩＣＨのいずれかで送信されてもよい。

本開示の別の実施形態では、コンファメーションは、周波数分割多重または符号分割多重のいずれかにより、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションと多重化されてもよい。

本開示のさらなる実施形態では、コンファメーションは、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションをさらに示してもよい。

本開示のさらに別の実施形態では、コンファメーションは、端末デバイスアイデンティティによってスクランブルされたＰＤＣＣＨ、端末デバイスのグループに共通のアイデンティティによってスクランブルされたＰＤＣＣＨにおけるターゲット端末デバイスに対応するビット、ＰＤＣＣＨのダウンリンク制御情報（Downlink Control Information）の新しいビット、ＰＤＣＣＨにおいてビームトラッキングリクエストを繰り返す情報のいずれかによって示されてもよい。

本開示の別の実施形態では、コンファメーションは、ビームトラッキングリクエストに対するアクノレッジメントのみを含み、ビームトラッキングリクエストに対する否定的アクノレッジメントは送信されなくてもよい。

本開示のさらなる実施形態では、ビームトラッキングリクエストは、ＣＲＣコードを含んでもよい。

本開示の実施形態では、ビームトラッキングリクエストは、２つのフルビームレポートの間で受信されてもよい。

本開示の別の実施形態では、ビーム識別情報は、サービングビームセットに基づくビーム識別（identification）を示してもよい。

本開示の実施形態では、ビームトラッキングリクエストは、ビームチャネル品質情報をさらに含んでもよい。ビームチャネル品質情報は、サービングビームセットにおける残存ビームに関して報告されたビームの品質関係を表すビーム品質パターンによって示されてもよい。

本開示の実施形態では、ビームトラッキングリクエストは、ビームスイッチ、障害のビームのリムーブ、新しいビームの追加、さらなるビームマネジメントのないビームリカバリのいずれかの動作（オペレーション）に対応してもよい。

図１５は、本開示の実施形態に係るビームトラッキングリクエストを受信する装置のブロック図を概略的に示す。装置１５００は、ＵＥなどの端末デバイスで実装することができる。

図１５に示すように、装置１５００は、リクエスト送信モジュール１５０１、コンファメーション受信モジュール１５０２、およびオペレーション実行モジュール１５０３を含む。リクエスト送信モジュール１５０１は、ビーム識別情報を含むビームトラッキングリクエストを送信するように構成される。コンファメーション受信モジュール１５０２は、ビームトラッキングリクエストへの応答としてコンファメーションを受信するように構成される。オペレーション実行モジュール１５０３は、コンファメーションとしてとしてアクノレッジメントが送信された場合、ビームトラッキングリクエストに対応する動作（オペレーション）を実行するように構成される。

本開示の一実施形態では、コンファメーションは、ＰＤＣＣＨ、ＭＡＣ ＣＥ、およびＰＨＩＣＨのいずれかで受信されてもよい。

本開示の別の実施形態では、コンファメーションは、周波数分割多重または符号分割多重化のいずれかにより、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションと多重化されてもよい。

本開示のさらなる実施形態では、コンファメーションは、ＰＵＳＣＨにおけるアップリンクデータ伝送のコンファメーションをさらに示してもよい。

本開示のさらに別の実施形態では、コンファメーションは、所定の端末デバイスアイデンティティによってスクランブルされたＰＤＣＣＨ、端末デバイスのグループに共通のアイデンティティによってスクランブルされたＰＤＣＣＨにおけるターゲット端末デバイスに対応するビット、ＰＤＣＣＨのダウンリンク制御情報（Downlink Control Information）の新しいビット、ＰＤＣＣＨにおいてビームトラッキングリクエストを繰り返す情報のいずれかによって示されてもよい。

本開示のさらに別の実施形態では、コンファメーションは、ビームトラッキングリクエストに対するアクノレッジメントのみを含み、ビームトラッキングリクエストに対する否定的アクノレッジメントは送信されなくてもよい。

本開示の別の実施形態では、ビームトラッキングリクエストは、ＣＲＣコードとともに送信されてもよい。

本開示のさらなる実施形態では、ビームトラッキングリクエストは、２つのフルビームレポートの間で送信されてもよい。

本開示のなおさらなる実施形態では、ビーム識別情報は、サービングビームセットに基づくビーム識別を示してもよい。

本開示のさらなる実施形態では、ビームトラッキングリクエストは、ビームチャネル品質情報をさらに含み、ビームチャネル品質情報は、サービングビームセットにおける残存ビームに関して報告されたビームの品質関係を表すビーム品質パターンによって示されてもよい。

本開示の別の実施形態では、ビームトラッキングリクエストは、ビームスイッチ、障害のビームのリムーブ、新しいビームの追加、さらなるビームマネジメントのないビームリカバリのいずれかの動作（オペレーション）に対応してもよい。

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

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

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

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

図１６は、本明細書に記載されている、無線ネットワーク内の基地局（ｇＮＢ）のようなネットワーク装置として具現化または構成される装置１６１０、およびＵＥのような端末デバイスとして具現化または構成される装置１６２０の簡略ブロック図をさらに示している。

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

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

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

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

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

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

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

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

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

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

例えば、ビームトラッキングリクエストを搬送するＰＵＣＣＨにファイルされたＵＣＩには、新しいサービングビームＩＤと、オプションでビームチャネル品質オーダー情報を含めることができる。オーダー情報には、さらに、オーダーされたサブセットとビーム品質パターンの２つの部分が含まれてもよい。ビーム品質パターンは、サービングビームセット内の残存ビームのビーム品質に基づいて決定されてもよい。特に、残存ビームのビーム品質は、ビーム品質閾値として使用されてもよい。図１２Ａに示すように、４つの非サービングノード｛２、４、５、７｝があり、ビーム｛３、６｝は、サービングビームサブセットに追加される新しいビームである。オーダーされたサブセットは｛１０、０１｝であり、残存ビーム１および８のＲＳＲＰ値（RSRP value）Ｔ１およびＴ２は、ビーム品質パターンのビーム品質閾値として使用できる。図１２Ｂにさらに示されるように、２つのビーム間には４つの可能なビーム品質関係がある。端末デバイスは、ビーム４および５のパターンを決定し、それをＵＣＩフィールド２に含めてもよい。図１２に示す例では、このパターンはパターンＢであり、例えば１０により示すことができる。その情報を受信した後、ｇＮＢは、基準閾値（reference threshold）Ｔ１およびＴ２に基づいて、ＵＣＩ内に含まれるオーダー情報を知ることができる。

図１５は、本開示の実施形態に係るビームトラッキングリクエストを送信する装置のブロック図を概略的に示す。装置１５００は、ＵＥなどの端末デバイスで実装することができる。

図１５に示すように、装置１５００は、リクエスト送信モジュール１５０１、コンファメーション受信モジュール１５０２、およびオペレーション実行モジュール１５０３を含む。リクエスト送信モジュール１５０１は、ビーム識別情報を含むビームトラッキングリクエストを送信するように構成される。コンファメーション受信モジュール１５０２は、ビームトラッキングリクエストへの応答としてコンファメーションを受信するように構成される。オペレーション実行モジュール１５０３は、コンファメーションとしてとしてアクノレッジメントが受信された場合、ビームトラッキングリクエストに対応する動作（オペレーション）を実行するように構成される。

Claims (38)

1. ビームトラッキングリクエストを処理する方法であって、
   ビーム識別情報を含むビームトラッキングリクエストを受信し、
   前記ビームトラッキングリクエストへの応答としてコンファメーションを送信し、
   前記コンファメーションとしてアクノレッジメントが送信された場合、前記ビームトラッキングリクエストに対応する動作を実行する、
   方法。
2. 前記コンファメーションは、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ） ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）、およびＰＨＩＣＨ（Ｐｈｙｓｉｃａｌ Ｈｙｂｒｉｄ−ＡＲＱ Ｉｎｄｉｃａｔｏｒ Ｃｈａｎｎｅｌ）のいずれかで送信される、
   請求項１に記載の方法。
3. 前記コンファメーションは、周波数分割多重または符号分割多重のいずれかにより、ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）におけるアップリンクデータ伝送のコンファメーションと多重化される、
   請求項１または２に記載の方法。
4. 前記コンファメーションは、ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）におけるアップリンクデータ伝送のコンファメーションをさらに示す、
   請求項１乃至３のいずれかに記載の方法。
5. 前記コンファメーションは、端末デバイスアイデンティティによってスクランブルされたＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、端末デバイスのグループに共通のアイデンティティによってスクランブルされたＰＤＣＣＨにおけるターゲット端末デバイスに対応するビット、ＰＤＣＣＨのＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）における新しいビット、およびＰＤＣＣＨにおいて前記ビームトラッキングリクエストを繰り返す情報のいずれかによって示される、
   請求項１乃至４のいずれかに記載の方法。
6. 前記コンファメーションは、前記ビームトラッキングリクエストに対するアクノレッジメントのみを含み、前記ビームトラッキングリクエストに対する否定的アクノレッジメントは送信されない、
   請求項１乃至５のいずれかに記載の方法。
7. 前記ビームトラッキングリクエストは、ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）コードを含む、
   請求項１乃至６のいずれかに記載の方法。
8. 前記ビームトラッキングリクエストは、２つのフルビームレポートの間で受信される、
   請求項１乃至７のいずれかに記載の方法。
9. 前記ビーム識別情報は、サービングビームセットに基づくビーム識別を示す、
   請求項１乃至８のいずれかに記載の方法。
10. 前記ビームトラッキングリクエストは、ビームチャネル品質情報をさらに含み、前記ビームチャネル品質情報は、前記サービングビームセットにおける残存ビームに関して報告されたビームの品質関係を表すビーム品質パターンによって示される、
    請求項１乃至９のいずれかに記載の方法。
11. 前記ビームトラッキングリクエストは、ビームスイッチ、障害のビームのリムーブ、新しいビームの追加、および、さらなるビームマネジメントのないビームのリカバリのいずれかの動作に対応する、
    請求項１乃至１０のいずれかに記載の方法。
12. ビームトラッキングリクエストを送信する方法であって、
    ビーム識別情報を含むビームトラッキングリクエストを送信し、
    前記ビームトラッキングリクエストへの応答としてコンファメーションを受信し、
    前記コンファメーションとしてアクノレッジメントを受信したことに応じて、前記ビームトラッキングリクエストに対応する動作を実行する、
    方法。
13. 前記コンファメーションは、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ） ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）、およびＰＨＩＣＨ（Ｐｈｙｓｉｃａｌ Ｈｙｂｒｉｄ−ＡＲＱ Ｉｎｄｉｃａｔｏｒ Ｃｈａｎｎｅｌ）のいずれかで受信される、
    請求項１２に記載の方法。
14. 前記コンファメーションは、周波数分割多重または符号分割多重のいずれかにより、ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）におけるアップリンクデータ伝送のコンファメーションと多重化される、
    請求項１２または１３に記載の方法。
15. 前記コンファメーションは、ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）におけるアップリンクデータ伝送のコンファメーションをさらに示す、
    請求項１２乃至１４のいずれかに記載の方法。
16. 前記コンファメーションは、端末デバイスアイデンティティによってスクランブルされたＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、端末デバイスのグループに共通のアイデンティティによってスクランブルされたＰＤＣＣＨにおけるターゲット端末デバイスに対応するビット、ＰＤＣＣＨのＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）における新しいビット、およびＰＤＣＣＨにおいて前記ビームトラッキングリクエストを繰り返す情報のいずれかによって示される、
    請求項１２乃至１５のいずれかに記載の方法。
17. 前記コンファメーションは、前記ビームトラッキングリクエストに対するアクノレッジメントのみを含み、前記ビームトラッキングリクエストに対する否定的アクノレッジメントは送信されない、
    請求項１２乃至１６のいずれかに記載の方法。
18. 前記ビームトラッキングリクエストは、ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）コードとともに送信される、
    請求項１２乃至１７のいずれかに記載の方法。
19. 前記ビームトラッキングリクエストは、２つのフルビームレポートの間で送信される、
    請求項１２乃至１８のいずれかに記載の方法。
20. 前記ビーム識別情報は、サービングビームセットに基づくビーム識別を示す、
    請求項１２乃至１９のいずれかに記載の方法。
21. 前記ビームトラッキングリクエストは、ビームチャネル品質情報をさらに含み、前記ビームチャネル品質情報は、前記サービングビームセットにおける残存ビームに関して報告されたビームの品質関係を表すビーム品質パターンによって示される、
    請求項１２乃至２０のいずれかに記載の方法。
22. 前記ビームトラッキングリクエストは、ビームスイッチ、障害のビームのリムーブ、新しいビームの追加、および、さらなるビームマネジメントのないビームのリカバリのいずれかの動作に対応する、
    請求項１２乃至２１のいずれかに記載の方法。
23. ビーム識別情報を含むビームトラッキングリクエストを受信し、前記ビームトラッキングリクエストへの応答としてコンファメーションを送信するように構成されたトランシーバと、
    前記コンファメーションとしてアクノレッジメントが送信された場合、前記ビームトラッキングリクエストに対応する動作を実行するように構成されたプロセッサと、
    を備えるネットワークノード。
24. 前記コンファメーションは、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ） ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）、およびＰＨＩＣＨ（Ｐｈｙｓｉｃａｌ Ｈｙｂｒｉｄ−ＡＲＱ Ｉｎｄｉｃａｔｏｒ Ｃｈａｎｎｅｌ）のいずれかで送信される、
    請求項２３に記載のネットワークノード。
25. 前記コンファメーションは、周波数分割多重または符号分割多重のいずれかにより、ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）におけるアップリンクデータ伝送のコンファメーションと多重化され、および／または、
    前記コンファメーションは、ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）におけるアップリンクデータ伝送のコンファメーションをさらに示す、
    請求項２３または２４に記載のネットワークノード。
26. 前記コンファメーションは、端末デバイスアイデンティティによってスクランブルされたＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、端末デバイスのグループに共通のアイデンティティによってスクランブルされたＰＤＣＣＨにおけるターゲット端末デバイスに対応するビット、ＰＤＣＣＨのＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）における新しいビット、およびＰＤＣＣＨにおいて前記ビームトラッキングリクエストを繰り返す情報のいずれかによって示される、
    請求項２３乃至２５のいずれかに記載のネットワークノード。
27. 前記コンファメーションは、前記ビームトラッキングリクエストに対するアクノレッジメントのみを含み、前記ビームトラッキングリクエストに対する否定的アクノレッジメントは送信されず、および／または、
    前記ビームトラッキングリクエストは、ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）コードとともに受信される、
    請求項２３乃至２６のいずれかに記載のネットワークノード。
28. 前記ビームトラッキングリクエストは、２つのフルビームレポートの間で受信される、
    請求項２３乃至２７のいずれかに記載のネットワークノード。
29. 前記ビーム識別情報は、サービングビームセットに基づくビーム識別を示し、および／または、
    前記ビームトラッキングリクエストは、ビームチャネル品質情報をさらに含み、前記ビームチャネル品質情報は、前記サービングビームセットにおける残存ビームに関して報告されたビームの品質関係を表すビーム品質パターンによって示される、
    請求項２３乃至２８のいずれかに記載のネットワークノード。
30. ビーム識別情報を含むビームトラッキングリクエストを送信し、前記ビームトラッキングリクエストへの応答としてコンファメーションを受信するように構成されたトランシーバと、
    前記コンファメーションとしてアクノレッジメントを受信したことに応じて、前記ビームトラッキングリクエストに対応する動作を実行するように構成されたプロセッサと、
    を備える端末デバイス。
31. 前記コンファメーションは、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ） ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）、およびＰＨＩＣＨ（Ｐｈｙｓｉｃａｌ Ｈｙｂｒｉｄ−ＡＲＱ Ｉｎｄｉｃａｔｏｒ Ｃｈａｎｎｅｌ）のいずれかで受信される、
    請求項３０に記載の端末デバイス。
32. 前記コンファメーションは、周波数分割多重または符号分割多重のいずれかにより、ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）におけるアップリンクデータ伝送のコンファメーションと多重化され、および／または、
    前記コンファメーションは、ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）におけるアップリンクデータ伝送のコンファメーションをさらに示す、
    請求項３０または３１に記載の端末デバイス。
33. 前記コンファメーションは、端末デバイスアイデンティティによってスクランブルされたＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、端末デバイスのグループに共通のアイデンティティによってスクランブルされ低減されたＰＤＣＣＨにおけるターゲット端末デバイスに対応するビット、ＰＤＣＣＨのＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）における新しいビット、およびＰＤＣＣＨにおいて前記ビームトラッキングリクエストを繰り返す情報のいずれかによって示される、
    請求項３０乃至３２のいずれかに記載の端末デバイス。
34. 前記コンファメーションは、前記ビームトラッキングリクエストに対するアクノレッジメントのみを含み、前記ビームトラッキングリクエストに対する否定的アクノレッジメントは送信されず、および／または、
    前記ビームトラッキングリクエストは、ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）コードとともに送信される、
    請求項３０乃至３２のいずれかに記載の端末デバイス。
35. 前記ビームトラッキングリクエストは、２つのフルビームレポートの間で送信される、
    請求項３０乃至３４のいずれかに記載の端末デバイス。
36. 前記ビーム識別情報は、サービングビームセットに基づくビーム識別を示し、および／または、
    前記ビームトラッキングリクエストは、ビームチャネル品質情報をさらに含み、前記ビームチャネル品質情報は、前記サービングビームセットにおける残存ビームに関して報告されたビームの品質関係を表すビーム品質パターンによって示される、
    請求項３０乃至３５のいずれかに記載の端末デバイス。
37. プロセッサと、
    前記プロセッサに結合され、前記プロセッサで実行することによりネットワークデバイスに請求項１乃至１１のいずれかの方法を実行させるプログラムコードを有するメモリと、
    を備えるネットワークデバイス。
38. プロセッサと、
    前記プロセッサに結合され、前記プロセッサで実行することにより端末デバイスに請求項１２乃至２２のいずれかの方法を実行させるプログラムコードを有するメモリと、
    を備える端末デバイス。

Images