(57)【要約】  本明細書は、無線通信システムにおいてビームの失敗を回復するための方法を提供する。  本明細書において端末によって実行される方法は、ビーム失敗の回復要請（beam failure recovery request）に関する資源の設定を基地局から受信するステップと、ビーム管理（beam management）に使用されるビーム基準信号（beam reference signal：ＢＲＳ）を前記基地局から受信するステップと、ビーム失敗イベント（beam failure event）が検出された場合、前記資源設定に基づいて、ビーム失敗の回復要請（beam failure recovery request）を第１資源を用いて前記基地局に伝送するステップと、ビームレポート（beam reporting）がトリガされた（triggered）場合、前記ビーム基準信号による測定結果を前記基地局に報告するステップを含むことができる。【選択図】図９
2020523938.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システムでビーム失敗の回復（beam failure recovery）を実行する方法において、端末によって実行される方法は、
ビーム失敗の回復要請（beam failure recovery request）に関する資源の設定（resource configuration）を基地局から受信するステップと、
ビーム管理（beam management）に使用されるビーム基準信号（beam reference signal：ＢＲＳ）を前記基地局から受信するステップと、
ビーム失敗イベント（beam failure event）が検出された場合、前記資源設定に基づいて、ビーム失敗の回復要請（beam failure recovery request）を第１資源を用いて前記基地局に伝送するステップと、
ビームレポート（beam reporting）がトリガされた（triggered）場合、前記ビーム基準信号による測定結果を前記基地局に報告する段階を含み、
前記第１資源は、ＰＲＡＣＨ（Physical Random Access Channel）またはＰＵＣＣＨ（Physical Uplink Control Channel）であることを特徴とする方法。
【請求項２】
前記第１資源が前記ＰＲＡＣＨの場合、前記ＰＲＡＣＨは、非‐競合ベース（non-contention based）ＰＲＡＣＨであることを特徴とする、請求項１に記載の方法。
【請求項３】
前記第１資源が前記ＰＵＣＣＨである場合、前記ビーム失敗の回復要請は、ビームが失敗するかどうかだけを知らせる指示子タイプ（indicator type）ＰＵＣＣＨまたは候補ビーム（candidate beam）の情報を含むメッセージタイプ（message type）ＰＵＣＣＨを用いることを特徴とする、請求項１に記載の方法。
【請求項４】
前記ビーム失敗イベントが特定のサービングビームリンク（serving beam link）のビームが失敗である場合、前記ビーム失敗の回復要請は、前記メッセージタイプＰＵＣＣＨを用いることを特徴とする、請求項３に記載の方法。
【請求項５】
前記ビーム失敗の回復要請に対する応答を、前記基地局から受信していない場合には、前記ビーム失敗の回復要請を第２資源を用いて再伝送するステップをさらに含むことを特徴とする、請求項２に記載の方法。
【請求項６】
前記第２資源は、競合ベースの（contention based）ＰＲＡＣＨであることを特徴とする、請求項５に記載の方法。
【請求項７】
前記第１資源で、前記ビーム失敗の回復要請が他のＰＵＣＣＨフォーマット（format）と重畳する場合、前記他のＰＵＣＣＨ formatをドロップ（drop）することを特徴とする、請求項３に記載の方法。
【請求項８】
前記ビーム失敗の回復要請がメッセージタイプ（message type）ＰＵＣＣＨである場合、前記候補ビームのＲＳ（Reference Signal）にＱＣＬ（Quasi co-location）を仮定して、前記ビーム失敗の回復要請に対する応答を受信することを特徴とする、請求項３に記載の方法。
【請求項９】
無線通信システムでビーム失敗の回復（beam failure recovery）を実行するための端末において、
無線信号を送受信するためのＲＦモジュール（radio frequency module）と、
前記ＲＦモジュールと機能的に接続されているプロセッサを含み、
前記プロセッサは、
ビーム失敗の回復要請（beam failure recovery request）に関連した資源の設定を基地局から受信し、
ビーム管理（beam management）に使用されるビーム基準信号（beam reference signal：ＢＲＳ）を前記基地局から受信し、
ビーム失敗イベント（beam failure event）が検出された場合、前記資源設定に基づいて、ビーム失敗の回復要請（beam failure recovery request）を第１資源を用いて前記基地局に伝送し、と
ビームレポート（beam reporting）がトリガされた（triggered）場合には、前記ビーム基準信号による測定結果を前記基地局に報告（report）するように設定され、
前記第１資源は、ＰＲＡＣＨ（Physical Random Access Channel）またはＰＵＣＣＨ（Physical Uplink Control Channel）であることを特徴とする端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムに関し、さらに詳細にビーム失敗の回復（beam  failure recovery）を実行する方法と、これをサポートするデバイスに関する。
【背景技術】
【０００２】
移動通信システムは、ユーザの活動性を保障しながら、音声サービスを提供するために開発された。しかしながら、移動通信システムは、音声だけでなく、データサービスまで領域を拡張し、現在には爆発的なトラフィックの増加によって資源の不足現象が引起こされ、ユーザがより高速のサービスを要求するので、より発展した移動通信システムが要求されている。
【０００３】
次世代の移動通信システムの要求条件は大きく、爆発的なデータトラフィックの収容、ユーザ当たり送信率の画期的な増加、大幅増加した接続デバイス個数の収容、非常に低い端対端遅延（End-to-End Latency）、高エネルギー効率をサポートできなければならない。このために、二重接続性（Dual Connectivity）、 大規模多重入出力（Massive MIMO：Massive Multiple Input Multiple Output）、全二重（In-band Full Duplex）、非直交多重接続（ＮＯＭＡ：Non-Orthogonal Multiple Access）、超広帯域（Super wideband）サポート、端末ネットワーキング（Device Networking）など、多様な技術が研究されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本明細書は、ビーム失敗の回復と関連した資源を設定する方法を提供することに目的がある。
【０００５】
また、本明細書は、ビーム失敗の回復要請を伝送するための制御チャネルまたは制御信号を定義することに目的がある。
【０００６】
また、本明細書は、ビーム失敗の回復要請と他の制御チャネル間の伝送の優先順位の関係を定義する方法を提供することに目的がある。
【０００７】
また、本明細書においては、ビーム失敗の回復要請に対する応答を受信しなかった場合、端末の動作方法を定義することに目的がある。
【０００８】
本発明において解決しようとする技術的課題は、以上で言及した技術的課題に限定されず、言及しない、また他のの技術的課題は、下の記載から、本発明が属する技術分野で通常の知識を有する者に明確に理解することができる。
【課題を解決するための手段】
【０００９】
本明細書においては、無線通信システムでビーム失敗の回復（beam failure recovery）を実行する方法において、端末によって実行される方法は、ビーム失敗の回復要請（beam failure recovery request）に関する資源の設定を基地局から受信するステップと、ビーム管理（beam management）に使用されるビーム基準信号（beam reference signal：ＢＲＳ）を前記基地局から受信するステップと、ビーム失敗イベント（beam failure event）が検出された場合、前記資源設定に基づいて、ビーム失敗の回復要請（beam failure recovery request）を第１資源を用いて前記基地局に伝送するステップと、ビームレポート（beam reporting）がトリガされた（triggered）場合、前記ビーム基準信号による測定結果を前記基地局に報告（report）する段階を含み、前記第１資源は、ＰＲＡＣＨ（Physical Random Access Channel）またはＰＵＣＣＨ（Physical Uplink Control Channel）であることを特徴とする。
【００１０】
また、本明細書において、前記第１資源が前記ＰＲＡＣＨの場合、前記ＰＲＡＣＨは、非 - 競合ベース（non-contention based）ＰＲＡＣＨであることを特徴とする。
【００１１】
また、本明細書において、前記第１資源が前記ＰＵＣＣＨである場合、前記ビーム失敗の回復要請は、ビームが失敗するかどうかだけを知らせる指示子タイプ（indicator type）ＰＵＣＣＨまたは候補ビーム（candidate beam）の情報を含むメッセージタイプ（message type）ＰＵＣＣＨを用いることを特徴とする。
【００１２】
また、本明細書において、前記ビーム失敗イベントが特定のサービングビームリンク（serving beam link）のビームが失敗である場合、前記ビーム失敗の回復要請は、前記メッセージタイプＰＵＣＣＨを用いることを特徴とする。
【００１３】
また、本明細書において、前記ビーム失敗の回復要請に対する応答を、前記基地局から受信していない場合、前記ビーム失敗の回復要請を第２資源を用いて再伝送するステップをさらに含むことを特徴とする。
【００１４】
また、本明細書において、前記第２資源は、競合ベースの（contention based）ＰＲＡＣＨであることを特徴とする。
【００１５】
また、本明細書において、前記第１資源で、前記ビーム失敗の回復要請が他のＰＵＣＣＨフォーマット（format）と重畳する場合には、前記他のＰＵＣＣＨ formatをドロップ（drop）することを特徴とする。
【００１６】
また、本明細書において、前記ビーム失敗の回復要請がメッセージタイプ（message type）ＰＵＣＣＨである場合、前記候補ビームのＲＳ（Reference Signal）にＱＣＬ（Quasi co-location）を仮定して、前記ビーム失敗の回復要請の応答を受信することを特徴とする。
【００１７】
また、本明細書は、無線通信システムでビーム失敗回復（beam failure recovery）を実行するための端末において、無線信号を送受信するためのＲＦモジュール（radio frequency module）と、前記ＲＦモジュールと機能的に接続されてあるプロセッサを含み、前記プロセッサは、、ビーム失敗の回復要請（beam failure recovery request）と関連した資源の設定を基地局から受信し、ビーム管理（beam management）に使用されるビーム基準信号（beam reference signal：ＢＲＳ）を前記基地局から受信し、ビーム失敗イベント（beam failure event）が検出された場合、前記資源設定に基づいて、ビーム失敗の回復要請（beam failure recovery request）を第１資源を用いて前記基地局に伝送し、とビームレポート（beam reporting）がトリガされた（triggered）場合、前記ビーム基準信号による測定結果を前記基地局に報告（report）するように設定され、前記第１資源は、ＰＲＡＣＨ（Physical Random Access Channel）またはＰＵＣＣＨ（ Physical Uplink Control Channel）であることを特徴とする。
【発明の効果】
【００１８】
本明細書は、ビーム失敗の回復要請を伝送するための制御チャネルを定義することで、端末からビーム失敗発生時、速めにビーム失敗の回復を実行することができる効果がある。
【００１９】
また、本明細書は、ビーム失敗の回復要請に最も高い優先順位を置くことにより、他の制御チャネルとの重畳問題を解決することができる効果がある。
【００２０】
本発明で得られる効果は、以上で言及した効果に制限されず、言及していないまた他の効果は以下の記載から、本発明が属する技術分野で通常の知識を有する者に明確に理解されることができる。
【図面の簡単な説明】
【００２１】
本発明に係る理解を助けるために詳細な説明の一部として含まれる、添付図面は、本発明の実施例を提供し、詳細な説明と一緒に本発明の技術的特徴を説明する。
【００２２】
【図１】本明細書で提案する方法が適用されることができるＮＲの全体的なシステムの構造の一例を示した図である。
【図２】本明細書で提案する方法が適用されることができる無線通信システムでアップリンクフレームとダウンリンクフレームとの間の関係を示す。
【図３】本明細書で提案する方法が適用されることができる無線通信システムでサポートされる資源グリッド（resource grid）の一例を示す。
【図４】本明細書で提供する方法が適用されることができるアンテナポートとヌメロロジー別の資源グリッドの例を示す。
【図５】ＴＸＲＵとアンテナ要素の接続方式の一例を示す。
【図６】ＴＸＲＵ別サービス領域の様々な一例を示す。
【図７】shows a description for Case 1。
【図８】shows a description for Case 2。
【図９】本明細書で提案するビームの失敗の回復を実行する方法の一例を示したフローチャートである。
【図１０】本発明の一実施例に係る無線通信装置のブロック構成図を例示する。
【図１１】本発明の一実施形態に係る通信装置のブロック構成図を例示する。
【発明を実施するための形態】
【００２３】
以下、本発明に係る好適な実施の形態を添付の図面を参照して、詳細に説明する。添付された図面と一緒に以下に開示される詳細な説明は、本発明の例示的な実施形態を説明しようとするものであり、本発明が実施されることができる唯一の実施形態を示しようとするのではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部を含む。しかし、当業者は、本発明が、このような具体的な詳細事項がなくても実施できることを知る。
【００２４】
いくつかの場合、本発明の概念が曖昧になることを避けるために、公知の構造及び装置は省略されるか、各構造及び装置の核心機能を中心としたブロック図の形式で示されることができる。
【００２５】
本明細書で基地局は、端末と直接通信を行うネットワークの終端ノード（terminal node）としての意味を有する。本書で基地局によって実行されるものとして説明された特定の動作は、場合によっては、基地局の上位ノード（upper node）によって行われることもある。つまり、基地局を含む多数のネットワークノード（network nodes）からなるネットワークで端末との通信のために行われる様々な動作は、基地局または基地局以外の他のネットワークノードによって実行されることができることは自明である。 「基地局（ＢＳ：Base Station）」は、固定局（fixed station）、Ｎｏｄｅ Ｂ、ｅＮＢ（evolved-NodeB）、ＢＴＳ（base transceiver system）、アクセスポイント（ＡＰ：Access Point）、ｇＮＢ（general ＮＢ）などの用語で置き換えることができる。また、「端末（Terminal）」は、固定されたり移動性を有することができ、ＵＥ（User Equipment）、ＭＳ（Mobile Station）、ＵＴ（user terminal）、ＭＳＳ（Mobile Subscriber Station）、ＳＳ（Subscriber Station）、ＡＭＳ（Advanced Mobile Station）、ＷＴ（Wireless terminal）、ＭＴＣ（Machine-Type Communication）装置、Ｍ２Ｍ（Machine-to-Machine）装置、Ｄ２Ｄ（Device-to-Device）装置などの用語に置き換えることができる。
【００２６】
以下において、下りリンク（ＤＬ：downlink）は、基地局から端末への通信を意味し、アップリンク（ＵＬ：uplink）は、端末から基地局への通信を意味する。下りリンクにおいて送信機は、基地局の一部であり、受信機は端末の一部で有り得る。アップリンクにおいて送信機は端末の一部であり、受信機は、基地局の一部で有り得る。
【００２７】
以下の説明において使用される特定の用語は、本発明の理解を助けるために提供されたものであり、このような特定用語の使用は、本発明の技術的思想を逸脱しない範囲で他の形態に変更されることができる。
【００２８】
以下の技術は、ＣＤＭＡ（code division multiple access）、ＦＤＭＡ（frequency division multiple access）、ＴＤＭＡ（time division multiple access）、ＯＦＤＭＡ（orthogonal frequency division multiple access）、ＳＣ−ＦＤＭＡ（single carrier frequency division multiple access ）、ＮＯＭＡ（non-orthogonal multiple access）などのような、さまざまな無線接続システムに使用することができる。 ＣＤＭＡはＵＴＲＡ（universal terrestrial radio access）やＣＤＭＡ２０００のような無線技術（radio technology）に実現されることができる。 ＴＤＭＡは、ＧＳＭ（global system for mobile communications）/ ＧＰＲＳ（general packet radio service/ＥＤＧＥ（enhanced data rates for GSM evolution）のような無線技術で実現されることができる。 ＯＦＤＭＡは、ＩＥＥＥ ８０２．１１（Wi-Fi）、ＩＥＥＥ ８０２．１６（WiMAX）、ＩＥＥＥ ８０２−２０、Ｅ−ＵＴＲＡ（evolved ＵＴＲＡ）などのような無線技術で実現されることができる。 ＵＴＲＡは、ＵＭＴＳ（universal mobile telecommunications system）の一部である。 ３ＧＰＰ（3rd generation partnership project）ＬＴＥ（long term evolution）は、Ｅ−ＵＴＲＡを使用するＥ−ＵＭＴＳ（evolved UMTS）の一部として、下りリンクでＯＦＤＭＡを採用し、アップリンクでＳＣ−ＦＤＭＡを採用する。 ＬＴＥ−Ａ（advanced）は、３ＧＰＰ ＬＴＥの進化である。
【００２９】
本発明の実施例は、無線接続システムのＩＥＥＥ ８０２、３ＧＰＰ及び３ＧＰＰ２の内、少なくとも一つに開示された標準文書により裏付けされることができる。すなわち、本発明の実施例中、本発明の技術的思想を明確に現すために説明しない段階または部分は、前記文書により裏打ちされることができる。また、本文書で開示しているすべての用語は、前記標準文書により説明されることができる。
【００３０】
説明を明確にするために、３ＧＰＰ ＬＴＥ／ＬＴＥ−Ａ、５Ｇ（New Rat）を中心に記術するが、本発明の技術的特徴が、これに制限されるものではない。
【００３１】
用語の定義
【００３２】
ｅＬＴＥ ｅＮＢ：ｅＬＴＥ ｅＮＢは、ＥＰＣとＮＧＣへの接続をサポートするｅＮＢの進化（evolution）である。
【００３３】
ｇＮＢ：ＮＧＣとの接続だけでなく、ＮＲをサポートするノード。
【００３４】
新ＲＡＮ：ＮＲまたはＥ−ＵＴＲＡをサポートしたり、ＮＧＣと相互作用する無線アクセスネットワーク。
【００３５】
ネットワークスライス（network slice）：ネットワークスライスは、エンドツーエンド間の範囲と共に、特定の要求事項を要求する特定の市場のシナリオに対して最適化されたソリューションを提供するようにｏｐｅｒａｔｏｒによって定義されたネットワーク。
【００３６】
ネットワーク機能（network function）：ネットワーク機能は、よく定義された外部インターフェースとよく定義された機能的動作を有するネットワークインフラ内での論理的なノード。
【００３７】
ＮＧＣ：新しいＲＡＮとＮＧＣの間のＮＧ２リファレンスポイント（reference point）に使用される制御平面インターフェース。
【００３８】
ＮＧ−Ｕ：新しいＲＡＮとＮＧＣの間のＮＧ３リファレンスポイント（reference point）に使用されるユーザ平面インターフェース。
【００３９】
非独立（Non-standalone）ＮＲ：ｇＮＢがＬＴＥ ｅＮＢをＥＰＣに制御プレーン接続のためのアンカーとして要請したり、またはｅＬＴＥ ｅＮＢをＮＧＣに制御プレーン接続のためのアンカーとして要求する配置構成。
【００４０】
非独立圭Ｅ−ＵＴＲＡ：ｅＬＴＥ ｅＮＢがＮＧＣに制御プレーン接続のためのアンカーとしてｇＮＢを要求する配置構成。
【００４１】
ユーザ平面ゲートウェイ：ＮＧ−Ｕインターフェースのエンドポイント。
【００４２】
システム一般
【００４３】
図１は、本明細書で提案する方法が適用されることができるＮＲの全体的なシステムの構造の一例を示した図である。
【００４４】
図１を参照すると、ＮＧ−ＲＡＮはＮＧ−ＲＡユーザ平面（新しいＡＳ sublayeｒ/ＰＤＣＰ/ＲＬＣ/ＭＡＣ/ＰＨＹ）とＵＥ（User Equipment）の制御平面（ＲＲＣ）プロトコル終端を提供するgNBで構成される。
【００４５】
前記gＮＢはＸｎインターフェースを介して互に接続される。
【００４６】
前記ｇＮＢはまた、ＮＧインターフェースを介してＮＧＣに接続される。
【００４７】
さらに具体的には、前記ｇＮＢはＮ２インターフェースを介してＡＭＦ（Access and Mobility Management Function）に、Ｎ３インターフェースを介してＵＰＦ（User Plane Function）に接続される。
【００４８】
NR（New Rat）ヌメロロジー（Numerology）とフレーム（frame）の構造
【００４９】
ＮＲシステムにおいては、多数のヌメロロジー（numerology）がサポートされることができる。ここで、はサブキャリア間隔（subcarrier spacing）とＣＰ（Cyclic Prefix）オーバーヘッドによって定義することができる。このとき、多数のサブキャリア間隔は基本サブキャリア間隔を整数Ｎ
2020523938.tif 000003
でスケーリング（scaling）することにより、誘導することができる。また、非常に高い搬送波周波数で非常に低いサブキャリア間隔を利用しないと仮定されるとしても、利用されるヌメロロジーは周波数帯域と独立して選択されることができる。
【００５０】
また、 ＮＲシステムにおいては、多数のヌメロロジーによる様々なフレーム構造がサポートされることができる。
【００５１】
以下、ＮＲシステムで考慮することができるＯＦＤＭ（Orthogonal Frequency Division  Multiplexing）ヌメロロジーとフレーム構造を注意深く見る。
【００５２】
ＮＲシステムでサポートされる多数のＯＦＤＭヌメロロジーは表1のように定義することができる。
【００５３】
【表１】
2020523938.tif 000004
【００５４】
ＮＲシステムでのフレーム構造（frame structure）に関連して、時間領域のさまざまなフィールドの大きさは、
2020523938.tif 000005
の時間の単位の倍数で表現される。ここで、
2020523938.tif 000006
であり、
2020523938.tif 000007
である。下りリンク（downlink）とアップリンク（uplink）伝送は、
2020523938.tif 000008
の区間を有する無線フレーム（radio frame）で構成される。ここで、無線フレームは、それぞれ
2020523938.tif 000009
の区間を有する１０個のサブフレーム（subframe）で構成される。この場合、アップリンクの１セットのフレーム及び下りリンクの１セットのフレームが存在することができる。
【００５５】
図２は、本明細書で提案する方法が適用されることができる無線通信システムでアップリンクフレームとダウンリンクフレームとの間の関係を示す。
【００５６】
図２に示すように、端末（User Equipment、ＵＥ）からのアップリンクフレーム番号iの伝送は、その端末からの対応する下りリンクフレームの開始より
2020523938.tif 000010
の前に開始しなければならない。
【００５７】
ヌメロロジー
2020523938.tif 000011
について、スロット（slot）は、サブフレーム内で
2020523938.tif 000012
の増加する順序で番号が付けられ、無線フレーム内で
2020523938.tif 000013
の増加する順序で番号が付けられる。一つのスロットは、
2020523938.tif 000014
の連続するＯＦＤＭシンボルで構成され、
2020523938.tif 000015
は、利用されるヌメロロジーとスロットの設定（slot configuration）に基づいて決定される。サブフレームでスロット
2020523938.tif 000016
の開始は、同一サブフレームでＯＦＤＭシンボ
2020523938.tif 000017
の開始と時間的に整列される。
【００５８】
すべての端末が同時に送信及び受信を行うことができるわけではなく、これは、ダウンリンクスロット（downlink slot）またはアップリンクスロット（uplink slot）のすべてのＯＦＤＭシンボルが利用されることはできないことを意味する。
【００５９】
表２は、ヌメロロジー
2020523938.tif 000018
での一般（normal）ＣＰのスロットごとのＯＦＤＭシンボルの数を示し、表３は、ヌメロロジー
2020523938.tif 000019
での拡張（extended）ＣＰのスロットごとのＯＦＤＭシンボルの数を示す。
【００６０】
【表２】
2020523938.tif 000020
【００６１】
【表３】
2020523938.tif 000021
【００６２】
ＮＲ物理資源（NR Physical Resource）
【００６３】
ＮＲシステムでの物理資源（physicalresource）と関連して、アンテナポート（antenna port）、資源グリッド（resource grid）、資源要素（resource element）、資源ブロック（resource block）、キャリアパーツ（carrier part ）などが考慮されることができる。
【００６４】
以下、ＮＲシステムで考慮することができる前記物理資源について具体的に注意深く見る。
【００６５】
まず、アンテナポートに関連して、アンテナポートは、アンテナポート上のシンボルが運搬されるチャンネルが同じアンテナポート上の他のシンボルが運搬されるチャネルから推論されるように定義される。 1つのアンテナポート上のシンボルが運搬されるチャンネルの広範囲特性（large-scale property）が、他のアンテナポート上のシンボルが運搬されるチャネルから類推することができる場合、２つのアンテナポートは、ＱＣ/ＱＣＬ（quasi co-locatedあるいはquasi co-location）の関係にあるとすることができる。ここで、前記広範囲の特性は、遅延拡散（Delay spread）、ドップラー拡散（Doppler spread）、周波数シフト（Frequency shift）、平均受信パワー（Average received power）、受信タイミング（Received Timing）の内、いずれか１つ以上を含む。
【００６６】
図３は、本明細書で提案する方法が適用されることができる無線通信システムでサポートされる資源グリッド（resource grid）の一例を示す。
【００６７】
図３を参考にすれば、資源グリッドが周波数領域上で
2020523938.tif 000022
サブキャリアで構成され、一つのサブフレームが１４・２μＯＦＤＭシンボルで構成されることを例示的に記述するが、これに限定されるものではない。
【００６８】
ＮＲシステムにおいて、伝送される信号（transmitted signal）は
2020523938.tif 000023
サブキャリアで構成される一つまたはその以上の資源グリッド及
2020523938.tif 000024
のＯＦＤＭシンボルによって説明される。ここで、
2020523938.tif 000025
である。前記
2020523938.tif 000026
は、最大伝送帯域幅を示し、これは、ヌメロロジーだけでなく、アップリンクとダウンリンクの間でも異なることができる。
【００６９】
この場合、図４のように、ヌメロロジー
2020523938.tif 000027
とアンテナポートｐごとに１つの資源グリッドが設定されることができる。
【００７０】
図４は、本明細書で提案する方法が適用されることができるアンテナポートとヌメロロジー別資源グリッドの例を示す。
【００７１】
ヌメロロジー
2020523938.tif 000028
とアンテナポートｐに対する資源グリッドの各要素は、資源要素（resource element）と呼ばれ、インデックス対
2020523938.tif 000029
によって固有的に識別される。ここで、
2020523938.tif 000030
は、周波数領域上のインデックスであり、
2020523938.tif 000031
は、サブフレーム内でシンボルの位置を指す。スロットでの資源要素を指すときは、インデックス対
2020523938.tif 000032
が使用される。ここで、
2020523938.tif 000033
である。
【００７２】
ヌメロロジー
2020523938.tif 000034
とアンテナポートｐに対する資源要素
2020523938.tif 000035
は、複素値（complex value）
2020523938.tif 000036
に該当する。混同（confusion）になる危険性がない場合、あるいは、特定のアンテナポートまたはヌメロロジーが特定されない場合には、インデックスｐ及びドロップ（drop）されることができ、その結果、複素値は
2020523938.tif 000037
または
2020523938.tif 000038
になることができる。
【００７３】
また、物理資源ブロック（physical resource block）は、周波数領域上の
2020523938.tif 000039
連続的なサブキャリアとして定義される。周波数領域上で、物理資源ブロックは、０から
2020523938.tif 000040
まで番号が付けられる。このとき、周波数領域上の物理資源ブロック番号（physical resource block number）
2020523938.tif 000041
と資源要素
2020523938.tif 000042
間の関係は、数式１のように与えられる。
【００７４】
【数１】
2020523938.tif 000043
【００７５】
また、キャリアパーツ（carrier part）に関連して、端末は、資源グリッドのサブセット（subset）のみを用いて、受信または伝送するように設定されることができる。このとき、端末が受信または伝送するように設定を受けた資源ブロックのセット（set）は、周波数領域上で０から
2020523938.tif 000044
まで番号が付けられる。
【００７６】
アップリンク制御チャネル（Uplink control channel）
【００７７】
物理アップリンク制御シグナリング（physical uplink control signaling）は、少なくともhybrid-ARQ acknowledgement、ＣＳＩレポート （ＣＳＩreport）（可能であればビームフォーミング（beamforming）情報を含む）、及びスケジューリング要請（schedulingrequest）を運ぶことができなければならない。
【００７８】
ＮＲシステムでサポートするアップリンク制御チャネル（ＵＬ control channel）について、少なくとも二つの伝送方法がサポートされる。
【００７９】
アップリンク制御チャネルは、スロット（slot）の最後に伝送されたアップリンクシンボルの周囲で、短期間（short duration）に伝送されることができる。この場合、アップリンク制御チャネルは、スロット内でアップリンクデータチャンネル（ＵＬ data channel）と時間−分割−多重化（time-division-multiplexed）及び/または周波数−分割−多重化（frequency-division-multiplexed）される。短期間のアップリンク制御チャネルに対し、スロットの１シンボル単位の伝送がサポートされる。
【００８０】
- ショートアップリンク制御情報（Uplink Control Information、ＵＣＩ）、及びデータは、少なくとも短いＵＣＩ及びデータの物理資源ブロック（Physical Resource Block、ＰＲＢ）が重畳されていない場合、端末（ＵＥ）と端末の間で周波数−分割−多重化される。
【００８１】
- 同じスロット内の異なる端末からの短いＰＵＣＣＨ（short ＰＵＣＣＨ）の時分割多重化（Time Division Multiplexing、ＴＤＭ）をサポートするために、短いＰＵＣＣＨを伝送するスロット内のシンボルが、少なくとも６ＧＨｚ以上でサポートされるかを端末に通知するメカニズム（mechanism）がサポートされる。
【００８２】
- １シンボル期間（１-symbol duration）には、少なくとも１）参照信号（Reference Signal、ＲＳ）が多重化されると、ＵＣＩとＲＳは、周波数分割多重化（Frequency Division Multiplexing、ＦＤＭ）方式で与えられたＯＦＤＭシンボルに多重化される点と、２）同一のスロットで下りリンク（ＤＬ/アップリンク（ＵＬ）データと短期間のＰＵＣＣＨとの間のサブキャリア間隔（subcarrier spacing）が同じ点がサポートされる。
【００８３】
- 少なくとも、スロットの２シンボル期間（２−symbol duration）にかけ、短期間のＰＵＣＣＨがサポートされる。このとき、同じスロットで下りリンク（ＤＬ/アップリンク（ＵＬ）データと短期間のＰＵＣＣＨとの間のサブキャリア間隔が同一である。
【００８４】
- 少なくとも、スロット内の与えられた端末のＰＵＣＣＨ資源、すなわち、異なる端末のショートＰＵＣＣＨはスロットで与えられた 持続期（duration）内に時分割多重化することができる半−静的構成（semi-staticconfiguration）がサポートされる。
【００８５】
- ＰＵＣＣＨ資源には、時間領域（timedomain）、周波数領域（frequency domain）、及び適用可能な場合には、コード領域（code domain）が含まれる。
【００８６】
- 短期間のＰＵＣＣＨは、端末の観点からスロットの最後まで拡張することができる。このとき、短期間のＰＵＣＣＨ以降、明示的なギャップのシンボル（explicit gap symbol）が不要である。
【００８７】
- 短いアップリンク部分（short ＵＬ part）を有するスロット（つまり、ＤＬ中心のスロット（ＤＬ−centric slot））について、データが短いアップリンク部分でスケジューリング（scheduling）されると、「短いＵＣＩ」とデータは、単一の端末によって周波数分割多重化されることができる。
【００８８】
アップリンク制御チャネルは、カバレッジ（coverage）を改善するために、多数のアップリンクシンボルに渡って長期間（long-duration）に伝送されることができる。この場合には、アップリンク制御チャネルは、スロット内のアップリンクデータチャネルと周波数分割多重化される。
【００８９】
- 少なくともＰＡＰＲ（Peak to Average Power Ratio）が低い設計で、長時間のアップリンク制御チャネル（long duration UL control  channel）によって運ばれるＵＣＩは、単一のスロットまたは複数のスロットにおいて伝送されることができる。
【００９０】
- 複数のスロットを用いる伝送は、少なくとも一部の場合に総持続時間（total duration）（例えば、1ms）間許容される。
【００９１】
- 長時間のアップリンク制御チャネルの場合、ＲＳとＵＣＩの間の時間分割多重化（ＴＤＭ）はＤＦＴ−Ｓ−ＯＦＤＭに対してサポートされる。
【００９２】
- スロットの長いアップリンク部分（long UL part）は、長時間のＰＵＣＣＨ伝送に利用することができる。つまり、長時間のＰＵＣＣＨは、アップリンク専用スロット（ＵＬ-only slot）と、少なくとも４つのシンボルで構成される可変数のシンボルを有するスロットのすべてにサポートされる。
【００９３】
- 少なくとも１または２ビットＵＣＩについて、前記ＵＣＩは、Ｎ個のスロット（Ｎ> １）内で繰り返すことができ、前記Ｎ個のスロットは、長時間のＰＵＣＣＨが許容されるスロットにおいて隣接するか、または隣接しないことがある。
【００９４】
- 少なくとも長いＰＵＣＣＨ（long  ＰＵＣＣＨ）のＰＵＳＣＨとＰＵＣＣＨの同時伝送（simultaneous transmission）がサポートされる。つまり、データが存在する場合でも、ＰＵＣＣＨ資源へのアップリンク制御が伝送される。また、ＰＵＣＣＨ-ＰＵＳＣＨの同時伝送外にも、ＰＵＳＣＨでのＵＣＩがサポートされる。
【００９５】
- ＴＴＩ内でのスロット周波数ホッピング（intra-TTI slot frequency hopping）がサポートされる。
【００９６】
- ＤＦＴ−ｓ−ＯＦＤＭ波形（waveform）がサポートされる。
【００９７】
- 伝送アンテナダイバーシティ（transmit antenna  diversity）がサポートされる。
【００９８】
短期間のＰＵＣＣＨと長期間のＰＵＣＣＨとの間のＴＤＭとＦＤＭは、少なくとも一つのスロットで他の端末に対しサポートされる。周波数領域において、ＰＲＢ（または複数のＰＲＢ）は、アップリンク制御チャネルの最小資源ユニットサイズ（minimum resource unit size）である。ホッピン（hopping）が利用される場合、周波数資源とホッピングは、キャリアの帯域幅（carrier bandwidth）に拡散されないことがある。また、端末特定ＲＳは、ＮＲ−ＰＵＣＣＨ伝送に使用される。 ＰＵＣＣＨ資源のセット（set）は、上位層シグナリング（higher layer signaling）によって設定され、設定を受けたセット内のＰＵＣＣＨ資源は、ダウンリンク制御情報（Downlink Control Information、DCI）によって指示される。
【００９９】
ＤＣＩの一部として、データ受信（data reception）とhybrid−ＡＲＱ acknowledgement伝送間のタイミング（timing）はダイナミックに（dynamically）（少なくともＲＲＣと一緒に）指示することができるべきである。半−静的構成（semi-static configuration）と（少なくとも一部のタイプのＵＣＩ情報の）ダイナミックなシグナリング（dynamic signaling）の組み合わせは、「長いおよび短いＰＵＣＣＨフォーマット」のＰＵＣＣＨ資源を決定するために利用される。ここでは、ＰＵＣＣＨ資源は、時間領域、周波数領域、及び適用可能な場合には、コード領域を含む。 ＰＵＳＣＨ上ＵＣＩつまり、ＵＣＩのスケジュールされた資源の一部を使用することはＵＣＩとデータの同時伝送の場合にサポートされる。
【０１００】
さらに、少なくとも単一のＨＡＲＱ−ＡＣＫビットのアップリンク伝送が、少なくともサポートされる。また、周波数ダイバーシティ（frequency diversity）を可能にするメカニズムがサポートされる。また、ＵＲＬＬＣ（Ultra-Reliable and Low-Latency Communication）の場合、端末に設定を受けたスケジューリング要請（ＳＲ）資源間の時間間隔（time interval）は、一スロットより小さいことがある。
【０１０１】
ビーム管理（Beam management）
【０１０２】
ＮＲにおいてビーム管理は、次のように定義される。
【０１０３】
ビーム管理（Beam management）：ＤＬ及びＵＬ送受信に使用することができるＴＲＰ及び/またはＵＥビームのセット（set）を獲得し、維持するためのＬ１/Ｌ２手順のセットとして、少なくとも次の事項を含む：
【０１０４】
- ビーム決定：ＴＲＰまたはＵＥが自分の伝送/受信ビームを選択する動作。
【０１０５】
− ビーム測定：ＴＲＰまたはＵＥが受信されたビーム形成信号の特性を測定する動作。
【０１０６】
- ビームレポート：ＵＥがビームの測定に基づいてビーム形成された信号の情報を報告する動作。
【０１０７】
-ビームスイープ（Beam sweeping）：予め決定された方法での時間間隔の間に伝送及び/または受信されたビームを用いて、空間領域をカバーする動作。
【０１０８】
さらに、ＴＲＰとＵＥでのＴｘ/Ｒｘビーム対応（correspondence）は、次のように定義される。
【０１０９】
- ＴＲＰでのＴｘ/Ｒｘビーム対応は、以下の内、少なくとも一つが満たされると、維持される。
【０１１０】
- ＴＲＰは、ＴＲＰの1つ以上の送信ビームのＵＥの下りリンクの測定に基づいてアップリンク受信のためのＴＲＰ受信ビームを決定することができる。
【０１１１】
- ＴＲＰは、ＴＲＰの1つ以上のＲｘビームのＴＲＰのアップリンク測定に基づいて下りリンク伝送のＴＲＰ Ｔｘビームを決定することができる。
【０１１２】
- ＵＥでのＴｘ/Ｒｘビーム対応は、以下の内、少なくとも一つが満たされると、維持される。
【０１１３】
- ＵＥは、ＵＥの1つ以上のＲｘビームのＵＥの下りリンクの測定に基づいてアップリンク伝送のためのＵＥ Ｔｘビームを決定することができる。
【０１１４】
- ＵＥは、1つ以上のＴｘビームのアップリンクの測定に基づいたＴＲＰの指示に基づいて、下りリンクの受信のためのＵＥ受信ビームを決定することができる。
【０１１５】
- ＴＲＰでＵＥビーム対応関連情報の能力指示がサポートされる。
【０１１６】
次のようなＤＬ Ｌ１/Ｌ２ビーム管理手順が1つまたは複数のＴＲＰの内でサポートされる。
【０１１７】
Ｐ−１：ＴＲＰ Ｔｘビーム/ＵＥ Ｒｘビームの選択を支援するために、異なるＴＲＰ ＴｘビームのＵＥ測定を可能にするために使用される。
【０１１８】
- ＴＲＰでのビームフォーミングの場合、一般的に、互いに異なるビームセットでイントラ（intra／インター（inter）−ＴＲＰ Ｔｘビームスイープ（sweep）を含む。 ＵＥからのビームフォーミングのために、それは一般的に異なるビームのセットからのＵＥ Ｒｘビームsweepを含む。
【０１１９】
Ｐ−２：異なるＴＲＰ ＴｘビームのＵＥ測定がインター／イントラ−ＴＲＰ Ｔｘビームを変更しようとするために使用される。
【０１２０】
Ｐ−３：ＵＥがビームフォーミングを使用する場合に同じＴＲＰ ＴｘビームのＵＥ測定がＵＥ Ｒｘビームを変更するために使用される。
【０１２１】
少なくともネットワークによってトリガーされた非周期的レポート（apreiodic reporting）は、Ｐ−１、Ｐ−２及びＰ−３関連動作でサポートされる。
【０１２２】
ビーム管理（少なくともＣＳＩ−ＲＳ）のためのＲＳに基づくＵＥ測定は、Ｋ（ビームの総数）のビームで構成され、ＵＥは、選択されたＮ個のＴｘビームの測定結果を報告する。ここで、Ｎは必ずしも固定された数ではない。移動性の目的のためのＲＳに基づいた手順は排除されない。レポート情報は、少なくともＮ <Ｋである場合、Ｎ個のビームの測定量とＮ個のＤＬ送信ビームを示す情報を含む。特に、ＵＥが、Ｋ ‘> １ノン-ゼロ-パワー（ＮＺＰ）ＣＳＩ−ＲＳ資源について、ＵＥは、Ｎ’のＣＲＩ（ＣＳＩ−ＲＳ資源の指示子）を報告することができる。
【０１２３】
ＵＥは、ビームを管理するために、次のような上位層のパラメータ（higher layer parameter）で設定されることができる。
【０１２４】
- Ｎ≧１レポート設定（setting）、Ｍ≧１資源の設定
【０１２５】
- レポート設定と資源の設定との間のリンクは、合意されたＣＳＩ測定設定で設定される。
【０１２６】
- ＣＳＩ−ＲＳベースＰ−１とＰ−２は、資源とレポート設定でサポートされる。
【０１２７】
- Ｐ−３は、レポート設定の有無にかかわらずサポートされることができる。
【０１２８】
- 少なくとも以下の事項を含むレポート設定（reporting setting）
【０１２９】
- 選択されたビームを示す情報
【０１３０】
- Ｌ１測定レポート（Ｌ１ measurement reporting）
【０１３１】
時間領域動作（例えば、非周期的（aperiodic）動作、周期的（periodic）動作、反− 持続的（semi-persistent）動作）
【０１３２】
- いろいろ周波数の細分（frequencygranularity）がサポートされる場合の周波数細分性
【０１３３】
- 少なくとも以下の事項を含む資源の設定（resource setting）
【０１３４】
- 時間領域の動作（例えば、非周期的動作、周期動作、反 -持続的動作
【０１３５】
- ＲＳタイプ：少なくともＮＺＰ ＣＳＩ−ＲＳ
【０１３６】
- 少なくとも一つのＣＳＩ−ＲＳの資源セット。各ＣＳＩ−ＲＳ資源セットは、Ｋ≧１ＣＳＩ−ＲＳ資源を含む（Ｋ個のＣＳＩ−ＲＳの資源の一部パラメータは、同じであることができる。例えば、ポート番号、時間領域の動作、密度及び周期）
【０１３７】
また、ＮＲはＬ> １のＬグループを考慮して、次のビーム報告をサポートします。
【０１３８】
- 最小限のグループを示す情報
【０１３９】
- Ｎ１ビームの測定量（measurement quantity）（Ｌ１ ＲＳＲＰとＣＳＩレポートのサポート（ＣＳＩ−ＲＳがＣＳＩ獲得のための場合））
【０１４０】
- 適用可能な場合、Ｎｌ個のＤＬ送信ビームを示す情報
【０１４１】
前述したようなグループベースのビームレポートはＵＥ単位で構成することができる。また、前記グループベースのビームレポートはＵＥ単位でターン - オフ（turn-off）することができる（例えば、Ｌ ＝ １またはＮｌ ＝ １の場合）。
【０１４２】
ＮＲはＵＥがビーム失敗から回復するメカニズムをトリガすることができることを支援する。
【０１４３】
ビーム失敗（beam failure）のイベントは、関連付けられた制御チャネルのビームペアリンク（beam pair link）の品質が十分に低い場合に発生する（例えば、しきい値との比較、関連タイマーのタイムアウト）。ビーム失敗（または障害）から回復するメカニズムは、ビーム障害が発生するときトリガされる。
【０１４４】
ネットワークは、回復の目的でＵＬ信号を伝送するための資源を有するＵＥに明示的に構成する。資源の構成は、基地局が全体または一部の方向から（例えば、random access region）聴取（listening）するところでサポートされる。
【０１４５】
ビーム障害を報告するＵＬ送信／資源はＰＲＡＣＨ（ＰＲＡＣＨ資源に直交する資源）と同じ時間インスタンス（instance）またはＰＲＡＣＨと他の時間インスタンス（ＵＥに対して構成可能）に位置することができる。 ＤＬ信号の送信は、ＵＥが新しい潜在的なビームを識別するためにビームを監視することができるよう支援する。
【０１４６】
ＮＲはビームに関連指示（beam-related indication）に関係なく、ビーム管理をサポートします。ビーム関連の指示が提供される場合、ＣＳＩ−ＲＳベースの測定のために使用されたＵＥ側ビーム形成/受信手順についての情報は、ＱＣＬを介してＵＥに指示することができる。ＮＲでサポートするＱＣＬパラメータには、ＬＴＥシステムで用いていたdelay、Doppler、average gainなどのパラメータだけでなく、受信端でのビームフォーミングのためのスペースのパラメータが追加される予定であり、端末の受信ビームフォーミングの観点からangle of arrival関連パラメータと／または基地局の受信ビームフォーミングの観点からangle of departure関連パラメータが含まれることができる。 ＮＲは、制御チャネルとデータチャネルの伝送で同じかまたは別のビームを使用することをサポートする。
【０１４７】
ビームペアリンクブロッキング（beam pair link blocking）の堅牢性（robustness）をサポートするＮＲ−ＰＤＣＣＨ伝送のために、ＵＥは、同時にＭ個のビーム対リンク上でＮＲ−ＰＤＣＣＨを監視するように構成されることができる。ここで、Ｍ≧１とＭの最大値は、少なくともＵＥ能力に依存することができる。
【０１４８】
ＵＥは、異なるＮＲ−ＰＤＣＣＨ ＯＦＤＭシンボルにおいて異なるビームペアリンク上のＮＲ−ＰＤＣＣＨを監視するように構成されることができる。多数のビーム対リンクに上でＮＲ−ＰＤＣＣＨを監視するためのＵＥ Ｒｘビームの設定に関するパラメータは、上位層シグナリングまたはＭＡＣ ＣＥによって構成されるか、及び/または検索空間設計で考慮される。
【０１４９】
少なくとも、ＮＲはＤＬ ＲＳアンテナポートとＤＬ制御チャネルの復調のためのＤＬ ＲＳアンテナポートとの間の空間ＱＣＬ仮定の指示を支援する。ＮＲ−ＰＤＣＣＨ（つまり、ＮＲ−ＰＤＣＣＨを監視する構成方法）のビーム指示のための候補シグナリング方法は、ＭＡＣ ＣＥシグナリング、ＲＲＣシグナリング、ＤＣＩシグナリング、スペックtransparent及び/または暗黙的な方法、及びこれらのシグナリング方法の組み合わせある。
【０１５０】
ユニキャストＤＬデータチャネルの受信のために、ＮＲはＤＬ ＲＳアンテナポートとＤＬデータチャネルのＤＭＲＳアンテナポートとの間の空間ＱＣＬ仮定の指示を支援する。
【０１５１】
ＲＳアンテナポートを示す情報は、ＤＣＩ（ダウンリンク許可）を介して表示される。また、この情報は、ＤＭＲＳアンテナポートとＱＣＬされているＲＳアンテナポートを示す。 ＤＬデータチャネルのＤＭＲＳアンテナポートの異なるセットは、ＲＳアンテナポートの他のセットとＱＣＬとして表すことができる。
【０１５２】
以下本明細書で提案する方法を具体的に説明する前に、本明細書で提案する方法と直接/間接的に関連した内容に対して、まず簡略に注意深く見る。
【０１５３】
５Ｇ、Ｎｅｗ Ｒａｔ（ＮＲ）などの次世代通信においては、さらに多くの通信機器がさらに大きな通信容量を要求することに伴い、従来のradio access technology（ＲＡＴ）に比べて向上されたmobile broadband通信の必要性が台頭している。
【０１５４】
さらに、多数の機器と物事を接続して、いつでもどこでも、様々なサービスを提供するmassive ＭＴＣ（Machine Type Communications）もまた次世代通信で考慮される重要な イッシュの一つである。
【０１５５】
だけではなく、信頼性（reliability）と遅延（latency）に敏感なサービス及び/または端末（ＵＥ）を考慮した通信システムの設計や構造が議論されている。
【０１５６】
このように、enhanced mobile broadband（ｅＭＢＢ）communication、massive MTC（ｍＭＴＣ）、ＵＲＬＬＣ（Ultra-Reliable and Low Latency Communication）などを考慮した次世代radio access technology（ＲＡＴ）の導入が現在議論されており、本明細書においては便宜上そのtechnologyを「new ＲＡＴ（ＮＲ）」と通称することにする。
【０１５７】
ＮＲでのＯＦＤＭ numerology
【０１５８】
Ｎｅｗ ＲＡＴシステムはＯＦＤＭ伝送方式または類似の伝送方式を使用し、代表的に、以下の表４のＯＦＤＭ numerologyを有する。
【０１５９】
即ち、表４は、New ＲＡＴシステムのＯＦＤＭ parameterの一例を示す。
【０１６０】
【表４】
2020523938.tif 000045
【０１６１】
アナログビームフォーミング（Analog beamforming）
【０１６２】
ミリ波（Millimeter Wave、ｍｍＷ）においては、波長が短くなって、同じ面積に多数のアンテナelementの設置が可能になる。
【０１６３】
即ち、３０ＧＨｚ帯で波長は１ｃｍとして４ ｘ ４ｃｍのパネル（panel）に０．５ lambda（波長）間隔で２−dimension配列の形で総６４（８ｘ８）個のアンテナelement設置が可能である。
【０１６４】
したがって、ｍｍＷでは多数個のアンテナelementを用いてbeamforming（ＢＦ）の利得を高め、カバレッジを増加させたり、throughputを高めようとする。
【０１６５】
この場合に、アンテナelementごとに伝送パワーと位相調整が可能なようにＴＸＲＵ（Transceiver Unit）を有せば、周波数資源ごとに独立したbeamformingが可能である。
【０１６６】
しかし、約１００個のアンテナelementのすべてにＴＸＲＵを設置するには、価格の面で実効性が落ちる問題を有するようになる。
【０１６７】
したがって、一つのＴＸＲＵに多数個のアンテナelementをmappingし、アナログ位相シフタ（analog phase shifter）でbeamの方向を調節する方式が考慮されている。
【０１６８】
このようなanalog beamforming方式は、全帯域における一つのbeam方向だけ作成することがあり、周波数選択的beamformingをしてくれることができない欠点を有する。
【０１６９】
このような理由のために、Digital ＢＦとanalog ＢＦの中間形態でＱ個のアンテナelementより少ない数であるＢ個のＴＸＲＵを有するhybrid ＢＦ（ＨＢＦ）を考慮することができる。
【０１７０】
ＨＢＦは、Ｂ個のＴＸＲＵとＱ個のアンテナelementの接続方法によって差はあるが、同時に伝送できるbeamの方向は、Ｂ個以下に制限されることになる。
【０１７１】
図５は、ＴＸＲＵとアンテナelementの接続方法の一例を示す。
【０１７２】
ここで、 ＴＸＲＵ仮想化（virtualization）モデルは、ＴＸＲＵの出力signalとantenna elementsの出力signalの関係を示す。
【０１７３】
図５aは、ＴＸＲＵがsub-arrayに接続された方式の一例を示す。
【０１７４】
図５ａを参照すると、アンテナelementは、単一のＴＸＲＵのみ接続される。図５aとは異なり、図５bは、ＴＸＲＵがすべてのアンテナelementに接続された方式を示す。
【０１７５】
すなわち、図５ｂの場合、アンテナelementは、すべてＴＸＲＵに接続される。
【０１７６】
図５において、Ｗはanalog phase shifterによって乗算される位相ベクトルを示す。
【０１７７】
即ち、Ｗによってanalog beamformingの方向が決定される。ここで、ＣＳＩ−ＲＳ antenna portsとＴＸＲＵとのmappingは１−ｔｏ−１または１−ｔｏ−ｍａｎｙで有り得る。
【０１７８】
参照信号の仮想化（ＲＳ virtualization）
【０１７９】
ｍｍＷでanalog beamformingによって１時点に１つのanalog beam方向にのみＰＤＳＣＨ伝送が可能である。
【０１８０】
それで、基地局は、特定の方向にあるい一部少数のＵＥにのみデータを伝送することになる。
【０１８１】
したがって、必要に応じ、アンテナポートごとにanalog beam方向を異なりに設定して、複数のanalog beam方向の多数のＵＥに同時にデータ伝送を行うことができるようにする。
【０１８２】
図６は、ＴＸＲＵ別サービス領域の様々な一例を示す。
【０１８３】
図６の場合、２５６ antenna elementを４等分して４つのsub-arrayを形成し、各sub-arrayにＴＸＲＵを接続した構造に関するもので、これを例に挙げて説明する。
【０１８４】
各sub-arrayが２−dimension配列の形で総６４（８ｘ８）のアンテナelementで構成されれば、特定のanalog beamformingによって１５度の水平角領域と１５度の垂直角領域に該当する地域をカバーすることができるようになる。
【０１８５】
すなわち、基地局がサービスしなければならない地域を多数個の領域に分けて、一度に一つずつサービスになる。
【０１８６】
以下の説明においてＣＳＩ−ＲＳ antenna portとＴＸＲＵは１−ｔｏ−１ mappingされたと仮定する。
【０１８７】
したがって、antenna portとＴＸＲＵは以下の説明で、同じ意味を有するものと解釈されることができる。
【０１８８】
図６aのように、すべてのＴＸＲＵ（アンテナポート、sub-array）が同じanalog beamforming方向を有せば、さらに高いresolutionを有するdigital beamを形成し、当該地域のthroughputを増加させることができる。
【０１８９】
また、当該地域に伝送データのランク（rank）を増加させて、当該地域のthroughputを増加させることができる。
【０１９０】
また、図６ｂのように、各ＴＸＲＵ（アンテナポート、sub-array）が、他のanalog beamforming方向を有せば、さらに広い領域に分布されたＵＥに当該subframe（ＳＦ）で同時にデータ伝送が可能になる。
【０１９１】
図６ｂに示すように、４つのアンテナポートの内から２つは領域1のＵＥ１にＰＤＳＣＨ伝送のために使用し、残りの２つは領域２のＵＥ２にＰＤＳＣＨ伝送のために使用するようにする。
【０１９２】
また、図６ｂは、ＵＥ１に伝送されるＰＤＳＣＨ １とＵＥ２に伝送されるＰＤＳＣＨ  ２がＳＤＭ（Spatial DivisionMultiplexing）された例を示す。
【０１９３】
これとは異なり、図６ｃのように、ＵＥ１に伝送されるＰＤＳＣＨ １とＵＥ２に伝送されるＰＤＳＣＨ  ２がＦＤＭ（Frequency Division Multiplexing）されて伝送されることもある。
【０１９４】
すべてのアンテナポートを用いて、１領域をサービスする方式とアンテナポートを分けて複数の領域を同時にサービスする方式の内からcell throughputを最大化（maximization）するために、ＵＥにサービスするＲＡＮＫとＭＣＳによって好まれる方法が変わることがある。
【０１９５】
また、各ＵＥに伝送されるデータの量によっても好まれる方式が変わることになる。
【０１９６】
基地局は、すべてのアンテナポートを用いて領域をサービスする際に得ることができるcell throughputまたはscheduling metricを計算し、アンテナポートを分けて二つの領域をサービスする際に得ることができるcell throughputまたはscheduling metricを計算する。
【０１９７】
基地局は、各方式を介して得ることができるcell throughputまたはscheduling metricを比較して、最終の伝送方式を選択するようにする。
【０１９８】
結果的に、ＳＦ−ｂｙ−ＳＦにＰＤＳＣＨ伝送に参加するアンテナポートの数が変動することになる。
【０１９９】
基地局がアンテナポートの数に応じたＰＤＳＣＨの伝送ＭＣＳを計算しschedulingアルゴリズムに反映するために、それに適合したＵＥからのＣＳＩフィードバックが要求される。
【０２００】
ＣＳＩ feedback
【０２０１】
３ＧＰＰ ＬＴＥ（−Ａ）システムにおいては、ユーザ機器（ＵＥ）がチャネルの状態情報（ＣＳＩ）を基地局（ＢＳ）に報告するように定義されている。
【０２０２】
ここで、チャネルの状態情報（ＣＳＩ）とは、ＵＥとアンテナポート間に形成される無線チャネル（あるいは「リンク」とも称する）の品質を示すことができる情報を通称する。
【０２０３】
例えば、ランク指示子（rank indicator、ＲＩ）、フリーコーディング行列指示子（precoding matrix indicator、ＰＭＩ）、チャネル品質指示子（channel quality indicator、ＣＱＩ）などがこれに該当する。
【０２０４】
ここで、ＲＩは、チャネルのランク（rank）の情報を示し、これはＵＥが同じ時間−周波数資源を介して受信するストリームの数を意味する。この値は、チャンネルのロングタームフェージング（fading）によって従属して決定されるので、ＰＭＩ、ＣＱＩより通常さらに長い周期を有しているＵＥからＢＳにフィードバックされる。
【０２０５】
ＰＭＩは、チャネル空間の特性を反映した値で、ＳＩＮＲなどの指標（metric）に基づいてＵＥが好ましいプリコーディングインデックスを示す。
【０２０６】
ＣＱＩは、チャネルの強さを示す値で、一般的に基地局（ＢＳ）がＰＭＩを用いたとき得られる受信ＳＩＮＲを意味する。
【０２０７】
３ＧＰＰ ＬＴＥ（−Ａ）システムで基地局は、多数個のＣＳＩプロセスをＵＥに設定してくれ、各プロセスのＣＳＩの報告を受けることができる。
【０２０８】
ここで、ＣＳＩプロセスは、基地局からの信号の品質の特定のためのＣＳＩ−ＲＳとの干渉を測定するためのＣＳＩ−interference measurement（ＣＳＩ−ＩＭ）資源で構成される。
【０２０９】
Ｔｘ−Ｒｘビーム関連（beam association）
【０２１０】
Networkは、cellで使用しようとする（あるいはｅＮＢが使用できる）beamsのmeasurementをＵＥが実行できるようにするために、各beamが適用されたknown signal（eg、measurement reference signal（ＭＲＳ）、beam reference signal（ＢＲＳ）、beamformed ＣＳＩ−ＲＳ（channel state information reference signal）などで構成され得、以下では、説明の便宜のために「ＢＲＳ」と通称する）を非周期/周期的に伝送することができる。
【０２１１】
また、ＵＥは、ＢＲＳのmeasurementを介してＵＥに適合したｅＮＢ Ｔｘ beamを選別することができる。
【０２１２】
ＵＥのＲｘ beamまで考慮する場合、ＵＥは、互いに異なるＲｘ beamを用いてmeasurementを実行し、ｅＮＢのＴｘ beamとＵＥのＲｘ beamを考慮したbeam組み合わせを選択することができる。
【０２１３】
このような過程を実行した以降、ｅＮＢとＵＥのＴｘ−Ｒｘ beam associationはexplicitに、あるいはimplicitに決定することができる。
【０２１４】
（1）ネットワーク決定ベースビーム関連（Network decision based beam association）
【０２１５】
NetworkはＵＥにmeasurement結果上部Ｘ個のＴｘ−Ｒｘ beam組み合わせをreportするように指示することができる。このとき、reportするbeam組み合わせの数は、予め定義されたり、networkによって（high layer signalingなどを通じて）signalingされるか、measurement結果が特定のthresholdを超えるbeam組み合わせをすべてreportことができる。
【０２１６】
このとき、特定thresholdは、予め定義されたりnetworkによってsignalingことができ、ＵＥごとdecoding性能が異なる場合、ＵＥのdecoding性能を考慮したcategoryが定義され、category別thresholdが定義されることもある。
【０２１７】
また、beam組み合わせのreportは、周期的及び/または（and /or）非周期的にnetworkの指示によって行われることができる。あるいは、前のreport結果と現在のmeasurement結果が一定レベル以上変化する場合event-triggered reportingを行うことができる。このとき、一定レベルは、予め定義されるか、またはnetworkが（high layer signalingなどを介して）signalingすることができる。
【０２１８】
ＵＥは、前記の方法により決定された（一つのまたは多数の）beam associationをreportすることができる。多数のbeam indexがreportされる場合、beam別priorityが付与されることもある。たとえば、最初（1st）のpreferred beam、第二（２nd）preferred beamなどのような形で解釈されるようreportすることがある。
【０２１９】
（２）ＵＥ決定ベースビーム関連（ＵＥ decision based beam association）
【０２２０】
ＵＥ decision based beam associationでＵＥのpreferred beam reportingは、先で注意深く見たexplicit beam associationの様な方式で実行されることができる。
【０２２１】
測定するためのＲｘ beam仮定（Rx beam assumption for the measurement） 
【０２２２】
さらに、ＵＥがreportするbest beamは、一つのＲｘ beamを仮定したときのmeasurement結果であるか、多数のＲｘ beamsを仮定したときのmeasurement結果で有り得、Ｒｘ beamの仮定はnetworkによってconfigureすることができる。
【０２２３】
例えば、networkが一つのＲｘ beamを仮定したときのmeasurement結果を３つreportしようと指示する場合、ＵＥは、すべてのＲｘ beamを用いてmeasurementを行い、measurement結果の内、最も良い（ｅＮＢ） Ｔｘ beamを選択した後、当該Ｔｘ beam measurementに使用されたＲｘ beamによるmeasurement結果の内、１ｓｔ、２ｎｄ、３ｒｄ best結果をreportすることができる。
【０２２４】
また、reportされるmeasurement結果は、特定thresholdを超えたことで制限することもできる。例えば、ＵＥが特定Ｒｘ beamにmeasureした１ｓｔ、２ｎｄ、３ｒｄ best beamの内、measurement値が（予め定義されるか、またはnetworkによってconfigureされた）特定thresholdを超えるbeamが1st best beamだけの場合には、ＵＥは、１st best beamだけを基地局にreportすることができる。
【０２２５】
Quasi co-location（ＱＣＬ）
【０２２６】
端末がデータ（e.g.、ＰＤＳＣＨ）を受信するとき、特定のＤＭＲＳのようなＵＥ-specific ＲＳに復調（demodulation）をするようにする方式を考慮する。このようなＤＭＲＳは、当該ＰＤＳＣＨのscheduled ＲＢ（ｓ）に対してのみ共に伝送されscheduled ＰＤＳＣＨが伝送される時間区間の間にのみ伝送されるため、当該ＤＭＲＳ自体のみのチャネル推定を実行するために受信性能の限界が存在することができる。
【０２２７】
例えば、チャネル推定を行うことにおいて無線チャネルの主なlarge-scale parameter（ＬＳＰ）の推定値が必要であり、これを前記scheduled ＰＤＳＣＨが伝送されるtime／frequency領域に存在するＤＭＲＳだけで得るには、ＤＭＲＳ densityが不足することがある。
【０２２８】
したがって、このような端末の実現をサポートするためにＬＴＥ−Ａでは、以下のようなＲＳ port間のquasi co-location signaling／assumption／behaviorを定義し、それに応じて端末を設定／動作させることができる方式をサポートしている。
【０２２９】
つまり、１つのアンテナポート上のシンボルが伝達されるチャンネルのlarge-scale特性が他のアンテナポート上のシンボルが伝送されるチャネルから推論されることができれば、２つのアンテナポートは、quasi co-located（ＱＣＬ）されていると言われる。
【０２３０】
ここで、large-scale特性は、遅延拡散、ドップラー拡散、ドップラーシフト、平均利得及び平均遅延の内、いずれか一つ以上を含む。
【０２３１】
さらに、ＵＥは、アンテナポート０〜３を仮定することができ、サービングセルのプライマリ/セカンダリ同期信号のアンテナポートは、ドップラーシフトと平均遅延についてＱＣＬされている。
【０２３２】
ＰＤＳＣＨ（Physical Downlink Shared Channel）の資源マッピングパラメータ（resource mapping parameters）
【０２３３】
与えられたサービング・セルの伝送モード１０で構成された（configured）ＵＥは、ＵＥと与えられたサービングセルに対して意図されたＤＣＩフォーマット２Ｄを有する検出されたＰＤＣＣＨ/ＥＰＤＣＣＨによりＰＤＳＣＨをデコードするために、上位層シグナリングによって４つのパラメータセットまで構成することができる。 ＵＥは、ＰＤＳＣＨ ＲＥマッピングを決定するためにそれと、ＵＥがＴｙｐｅ Ｂ ＱＣＬタイプで構成された場合ＰＤＳＣＨのアンテナポートＱＣＬを決定するためにＤＣＩフォーマット２Ｄを有した検出されたＰＤＣＣＨ/ＥＰＤＣＣＨで「ＰＤＳＣＨ ＲＥ ＭａｐｐｉｎｇとＱｕａｓｉ−Ｃｏ−Ｌｏｃａｔｉｏｎ ｉｎｄｉｃａｔｏｒ」 フィールドの値に基づいて設定を受けたパラメータを使用する。
【０２３４】
対応するＰＤＣＣＨ/ＥＰＤＣＣＨがないＰＤＳＣＨの場合、ＵＥは、ＰＤＳＣＨ ＲＥマッピングとＰＤＳＣＨのアンテナポートＱＣＬを決定するために、関連するＳＰＳの活性化に対応するＤＣＩフォーマット２Ｄを有するＰＤＣＣＨ/ＥＰＤＣＣＨで指示されたパラメータセットを使用する。
【０２３５】
以下の表５は、ＤＣＩ format ２ＤでのＰＤＳＣＨ ＲＥ Mapping and Ｑｕａｓｉ−Ｃｏ−Ｌｏｃａｔｉｏｎ Indicator fieldを示す。
【０２３６】
【表５】
2020523938.tif 000046
【０２３７】
ＰＤＳＣＨ ＲＥマッピング及びＰＤＳＣＨアンテナポートＱＣＬを決定するための以下のパラメータは、各パラメータセットの上位層シグナリングを介して構成される：
【０２３８】
- crs-PortsCount-r11
【０２３９】
- crs-FreqShift-r11
【０２４０】
- mbsfn-SubframeConfigList-r11
【０２４１】
- csi-RS-ConfigZPId-r11
【０２４２】
- pdsch-Start-r11
【０２４３】
- qcl-CSI-RS-ConfigNZPId-r11
【０２４４】
- ＵＥがＴＤＤサービングセルの上位層のパラメータｅＭＩＭＯ−Ｔｙｐｅで構成される場合、zeroTxPowerCSI-RS2-r12
【０２４５】
ＰＤＳＣＨのアンテナポートＱＣＬ
【０２４６】
サービングセルのための送信モード８−１０で構成されたＵＥは、サービングセルのアンテナポート７−１４が遅延スプレッド（delay spread）、ドップラースプレッド（Doppler spread）、Doppler shift、average gain及びaverage delayについて与えられたサブフレームのＱＣＬと仮定することができる。
【０２４７】
サービングセルのための送信モード１−９で構成されたＵＥは、サービングセルのアンテナポート０−３、５、７−３０がDoppler shift、Doppler spread、average delay、delay spreadについてＱＣＬと仮定することができる。
【０２４８】
サービングセルのための伝送モード１０で構成されたＵＥは、アンテナポート７−１４と関連送信方式に基づいてＰＤＳＣＨをデコードするために、上位層のパラメータＱＣＬ動作によってサービング・セルの２つのＱＣＬタイプの内いずれか１つで構成される：
【０２４９】
- タイプＡ：ＵＥは、サービングセルのアンテナポート０−３、７−３０がdelay spread、Doppler spread、Doppler shift、及びaverage delayのＱＣＬと仮定することができる。
【０２５０】
− タイプＢ：ＵＥは、上位層のパラメータｑｃｌ−ＣＳＩ−ＲＳ−ＣｏｎｆｉｇＮＺＰＩｄ−ｒ１１によって識別されたＣＳＩ−ＲＳ資源の構成に対応するアンテナポート１５〜３０とＰＤＳＣＨと関連付けられたアンテナポート７−１４はDoppler shift 、Doppler spread、average delay、及びdelay spreadのＱＣＬと仮定することができる。
【０２５１】
ＬＡＡ Ｓｃｅｌｌの場合、ＵＥは、ＱＣＬ type Ｂで構成されるものと予想されない。
【０２５２】
Channel-State Information  -  Reference Signal（ＣＳＩ−ＲＳ）の定義
【０２５３】
伝送モード９で構成され上位層パラメータｅＭＩＭＯ−Ｔｙｐｅで構成されないサービングセルとＵＥに対して、ＵＥは、一つのＣＳＩ−ＲＳの資源の構成（configuration）で構成されることができる。
【０２５４】
伝送モード９で構成され上位層パラメータｅＭＩＭＯ−Ｔｙｐｅで構成されてｅＭＩＭＯ−Ｔｙｐｅが「class Ａ」に設定を受けたサービングセル及びＵＥに対して、ＵＥは、一つのＣＳＩ−ＲＳ資源の構成で構成されることができる。
【０２５５】
伝送モード９で構成され上位層パラメータｅＭＩＭＯ−Ｔｙｐｅで構成されてｅＭＩＭＯ−Ｔｙｐｅが「class Ｂ」に設定を受けたサービングセルとＵＥに対して、ＵＥは、一つ以上のＣＳＩ−ＲＳ資源の構成で構成されることができる。
【０２５６】
伝送モード１０で構成されたサービングセルとＵＥに対して、ＵＥは、 一つ以上のＣＳＩ−ＲＳ資源構成で構成されることができる。 ＵＥがＣＳＩ−ＲＳについてnon-zero送信電力を仮定しなければなら次のパラメータは、各ＣＳＩ−ＲＳ資源構成の上位層シグナリングを介して構成される：
【０２５７】
- ＵＥが伝送モード１０に構成されると、ＣＳＩ−ＲＳの資源の構成identity
【０２５８】
- ＣＳＩ−ＲＳポートの数
【０２５９】
- ＣＳＩ ＲＳ構成
【０２６０】
- ＣＳＩ ＲＳサブフレーム構成
2020523938.tif 000047
【０２６１】
- ＵＥが伝送モード９に設定される場合、ＣＳＩフィードバックのための基準ＰＤＳＣＨ伝送電力
2020523938.tif 000048
のＵＥ仮定
【０２６２】
- ＵＥが伝送モード１０で構成された場合、各ＣＳＩプロセスのＣＳＩフィードバックのための基準ＰＤＳＣＨ伝送電力
2020523938.tif 000049
のＵＥ仮定
【０２６３】
- もしＣＳＩサブフレームセット
2020523938.tif 000050
及び、
2020523938.tif 000051
が一つのＣＳＩプロセスの上位層シグナリングで構成された場合、
2020523938.tif 000052
は、当該ＣＳＩプロセスの各ＣＳＩサブフレームセットに対して設定される。
【０２６４】
- Pseudo-randomシーケンスジェネレーターパラメータ
2020523938.tif 000053
【０２６５】
- ＵＥが上位層パラメータｅＭＩＭＯ−Ｔｙｐｅで構成され、ｅＭＩＭＯ−ＴｙｐｅがＣＳＩプロセスの「class Ａ」に設定を受けた場合、ＣＤＭタイプパラメータ。
【０２６６】
- ＵＥが伝送モード１０で構成された場合、ＱＣＬタイプＢの上位層パラメータｑｃｌ−ＣＲＳ−Ｉｎｆｏ−ｒ１１ＣＲＳ、次のパラメータを有するＣＲＳアンテナポートとＣＳＩ−ＲＳアンテナポートのＵＥ仮定：
【０２６７】
- qcl-ScramblingIdentity-r11。
【０２６８】
- crs-PortsCount-r11。
【０２６９】
- mbsfn-SubframeConfigList-r11。
【０２７０】
2020523938.tif 000054
はＵＥがＣＳＩフィードバックを導出し１ｄＢステップ（step）サイズで[−８、１５] ｄＢの範囲の値をとるときＣＳＩ−ＲＳ ＥＰＲＥのＰＤＳＣＨ ＥＰＲＥの仮定された比率である。
【０２７１】
ここで、ＰＤＳＣＨ ＥＰＲＥはＰＤＳＣＨ ＥＰＲＥとセル特定ＲＳ ＥＰＲＥとの比率が
2020523938.tif 000055
で表示されるシンボルに該当する。
【０２７２】
ＵＥは、サービングセルの同じサブフレームでＣＳＩ−ＲＳとＰＭＣＨの構成を期待しない。
【０２７３】
フレーム構造タイプ２サービングセルと４つのＣＲＳポートについて、ＵＥは、normal ＣＰ caseのセット[２０−３１]またはextended ＣＰ caseのセット[１６−２７]に属するＣＳＩ−ＲＳ configuration indexを受信することを期待しない。
【０２７４】
ＵＥは、ＣＳＩ−ＲＳ資源構成のＣＳＩ−ＲＳアンテナポートがdelay spread、Doppler spread、Doppler shift、average gain、及びaverage delayのＱＣＬと仮定することができる。
【０２７５】
送信モード１０とＱＣＬタイプＢで構成されたＵＥは、ＣＳＩ−ＲＳ資源構成に対応するｑｃｌ−ＣＲＳ−Ｉｎｆｏ−ｒ１１と関連付けられるアンテナポート０〜３、及びＣＳＩ−ＲＳ資源の構成に対応するアンテナポート１５〜３０はDoppler shiftとDoppler spreadのＱＣＬと仮定することができる。
【０２７６】
伝送モード１０で構成され上位層パラメータｅＭＩＭＯ−Ｔｙｐｅで構成されｅＭＩＭＯ−Ｔｙｐｅが「クラスＢ」に設定され、構成されたＣＳＩ資源の数が一つのＣＳＩプロセスの1より多くＱＣＬタイプＢを有するＵＥは、上位層のパラメータｑｃｌ−ＣＲＳ−Ｉｎｆｏ−ｒ１１の異なる値を有するＣＳＩプロセスのＣＳＩ−ＲＳの資源構成を受信することを期待していない。
【０２７７】
ＣＥＭｏｄｅＡまたはＣＥＭｏｄｅＢで構成されたＢＬ/ＣＥ ＵＥはnon-zero送信電力ＣＳＩ−ＲＳで構成されるものと期待しない。
【０２７８】
Assumptions independent of physical channel
【０２７９】
ＵＥは異なるように明示しない限り、２つのアンテナポートがＱＣＬと仮定しない。
【０２８０】
ＵＥは、サービングセルのアンテナポート０〜３がdelay spread、Doppler spread、Doppler shift、average gain、及びaverage delayのＱＣＬと仮定することができる。
【０２８１】
ディスカバリー信号ベースの測定の目的のために、ＵＥは、ディスカバリー信号以外の他の信号または物理チャンネルがあると仮定しない。
【０２８２】
ＵＥがｄｉｓｃｏｖｅｒｙＳｉｇｎａｌｓＩｎＤｅａｃｔＳＣｅｌｌ−ｒ１２をサポートし、同じキャリア周波数でセカンダリセルに適用可能なキャリア周波数でディスカバリー信号に基づいたＲＲＭ測定でＵＥが構成されており、セカンダリセルが非活性化されてあり、ＵＥがセカンダリセルでＭＢＭＳを受信するために、上位層によって構成されない場合、ＵＥは、ディスカバリー信号の伝送を除外しＰＳＳ、ＳＳＳ、ＰＢＣＨ、ＣＲＳ、ＰＣＦＩＣＨ、ＰＤＳＣＨ、ＰＤＣＣＨ、ＥＰＤＣＣＨ、ＰＨＩＣＨ、ＤＭＲＳ及びＣＳＩ−ＲＳが活性化コマンドがセカンダリセルにの受信されたサブフレームまで、当該セカンダリセルによって伝送されない。
【０２８３】
先に注意深く見た動作において、例えば、ＱＣＬ Ｔｙｐｅ Ｂに設定される端末の場合、scheduled ＰＤＳＣＨで伝送されるＤＭＲＳのチャネル推定支援を受けるためには、そのscheduling ＤＣＩで指示する特定ＱＣＬｅｄ ＣＳＩ−ＲＳ resourceから推定されたＬＳＰを使用できるように制限している。
【０２８４】
しかし、本明細書で考慮するNew ＲＡＴ（ＮＲ）環境では、ＣＳＩ−ＲＳの伝送自体が従来の周期的な形態を脱し必要なときだけ伝送するという観点からのaperiodic ＣＳＩ−ＲＳ伝送方式を考慮 していて、ＱＣＬ ＣＳＩ −ＲＳとして活用するためのＲＳ densityが従来比大幅に不足することに成り得るという問題点がある。
【０２８５】
ＮＲ環境で考慮するＱＣＬ parametersとして、次の内、少なくとも一つが定義／設定することができる：
【０２８６】
− 遅延拡散（Delay spread）
【０２８７】
- ドップラー拡散（Doppler spread）
【０２８８】
- ドップラー遷移（Doppler shift）
【０２８９】
- 平均利得（Average gain）
【０２９０】
- 平均遅延（Average delay）
【０２９１】
- 平均角度（Average angle、ＡＡ）：
【０２９２】
ＡＡの観点からＱＣＬが保障されるantenna portsの間、例えば、特定のantenna portから推定されるＡＡをに基づいて、また別のantenna port（s）からの伝送信号を受信しようとするときの受信ビーム方向（それと／または受信ビーム幅／sweeping程度）などを同じかまたは（これと関連して）類似に設定し受信処理することが可能であることを意味することができる（このように動作したときの受信性能が特定レベル以上に保障されることを意味する）。
【０２９３】
ＡＡは、例えば、「（Almost）Dominant arrival angle "などの名称でも表現することができる。
【０２９４】
結局、特定のantennaportから測定される信号の特定dominant（arrival）angle Ｓがあるとするとき、これとＱＣＬ仮定可能な他のantennaportから測定される信号の特定dominant（arrival）angleは、前記Ｓと "ほぼ（ almost）"類似であると意味を有することができる。
【０２９５】
即ち、このようなＱＣＬ仮定が可能な場合に受信機は、特定指示されたQCLed ＲＳ/ＳＳから推定されたＡＡを「almost」そのまま受信処理に活用/適用してもとよいという意味になり、効率的な受信機の実現／動作ができるようにするという利点がある。
【０２９６】
Ａｎｇｕｌａｒ ｓｐｒｅａｄ（ＡＳ）：
【０２９７】
Two antenna portsの間ＡＳ観点からＱＣＬという意味は、一つのportから推定されるＡＳが他のportから推定されるＡＳから誘導または推定または適用されることができるということを意味する。
【０２９８】
このとき、ＡＳはAｚｉｍｕｔｈ及び/またはＺｅｎｉｔｈ ＡＳとして、それぞれの特定dimension別に定義することもあるか、または一緒に定義することもでき、また、departure及び/またはarrival観点から、それぞれ別々に、または一緒に定義することもできる。
【０２９９】
ＡＳ観点からＱＣＬが保障されるantenna portsの間には、例えば、特定antenna portから推定されるＡＳに基づいて、また他のantenna port（s）からの伝送信号を受信しようとするときの受信ビーム幅／sweeping程度（それと／または受信ビームの方向）などを同じかまたは（これと関連して）類似に設定し受信処理することが可能であることを意味することができる（このように動作したときの受信性能が特定レベル以上に保障されることを意味する）。
【０３００】
即ち、前記ＡＡが平均的な、（最も）有効する／dominant beam directionを意味する特徴があると、ＡＳは（前記ＡＡを中心／基準に）反射体分布などによっていくらビーム方向が広がって、受信されるかについてのパラメータとして解釈されることができる。 
【０３０１】
ビーム管理とビーム失敗回復（Beam management and beam failure recovery）
【０３０２】
基地局は、端末に周期的（periodic）ＣＳＩレポート、半-固定的（semi-persistent）ＣＳＩレポート（特定時間区間の間だけ、周期的ＣＳＩ報告が活性化（activation）されたり、あるいは連続した複数回のＣＳＩ報告を行う） 、または非周期的（aperiodic）ＣＳＩ報告を要請することができる。
【０３０３】
ここで、前記周期的（periodic）と半−固定的（semi-persistent、ＳＰ）ＣＳＩ reportingは報告が活性化された期間には、端末に特定周期でＣＳＩ報告のためのＵＬ（uplink）資源（e．g． ＰＵＣＣＨ ｉｎ ＬＴＥ）が割り当てられる。
【０３０４】
端末のＣＳＩ測定のためには、基地局のdownlink（ＤＬ）reference signal（ＲＳ）の伝送が必要である。
【０３０５】
（アナログ）ビームフォーミングが適用されたbeamformedsystemの場合、前記ＤＬ ＲＳ伝送／受信のためのＤＬ transmission（Ｔｘ）／ reception（Ｒｘ）ビーム対（beam pair）とＵＣＩ（uplink control information：ｅ．ｇ． ＣＳＩ、ＡＣＫ/ＮＡＣＫ）伝送/受信のためのＵＬ Ｔｘ/Rx beam pairの決定が必要である。
【０３０６】
ＤＬ beam pairの決定手順は、（１）複数のＴＲＰ Ｔｘ beamに対応するＤＬ ＲＳを基地局が端末に伝送する手順と、（２）前記端末がこれらの内、いずれか１つを選択及び/または報告するＴＲＰ Ｔｘ beam選択手順と、（３）基地局が、各ＴＲＰ Ｔｘ beamに対応する同じＲＳ信号を繰り返し伝送する手順と、（４）前記端末が、前記繰り返し伝送された信号に互いに異なるＵＥ Ｒｘ beamで測定してＵＥ Ｒｘ beamを選択するための手順の組み合わせで構成されることができる。
【０３０７】
また、ＵＬ beam pair決定手順は、（１）複数のＵＥ Ｔｘ beamに対応するＵＬ ＲＳを端末が基地局に伝送する手順と、（２）基地局がこれらの内、いずれか１つを選択、及び/またはsignalingするＵＥ Ｔｘ beam選択手順と、（３）前記端末が各ＵＥ Ｔｘ beamに対応する同じＲＳ信号を基地局に繰り返し伝送する手順と、（４）前記基地局が前記繰り返し伝送された信号に互いに異なるＴＲＰ Ｒｘ beamで測定してＴＲＰ Ｒｘ beamを選択する手順の組み合わせで構成されることができる。
【０３０８】
ＤＬ/ＵＬのbeam reciprocity（あるいはbeam correspondence）が成立する場合、すなわち、基地局と端末間の通信で基地局ＤＬ Ｔｘビームと基地局ＵＬ Ｒｘビームが一致し、端末ＵＬ Ｔｘビームと端末ＤＬ Ｒｘビームが一致すると仮定することができる場合、ＤＬ beam pairとＵＬ beam pairの内、いずれか１つだけを決定すれば、他の１つを決定する手順を省略することができる。
【０３０９】
ＤＬ及び／またはＵＬビームpairの決定過程は、周期的あるいは非周期的に行うことができる。
【０３１０】
候補（candidate）ビーム数が多い場合、要求されるＲＳ overheadが大きいことがあるため、前記ＤＬ及び/またはＵＬビームpairの決定過程が頻繁に発生するのは望ましくない。
【０３１１】
ＤＬ/ＵＬビームpair決定プロセスが完了した後、端末は周期的（periodic）またはＳＰ（Semi-Persistent）ＣＳＩ reportingを行うと仮定する
【０３１２】
ここで、端末のＣＳＩ測定（measurement）のための単一または複数のantenna portを含むＣＳＩ−ＲＳは、ＤＬビームで決定されたＴＲＰ Ｔｘ beamでビームフォーミングされて伝送されることができ、ＣＳＩ−ＲＳの伝送周期はＣＳＩレポート（reporting）周期と同じか、あるいはさらに頻繁に伝送されることができる。
【０３１３】
または、端末は非周期的（aperiodic）ＣＳＩ−ＲＳをＣＳＩレポート周期に合わせて、あるいは、さらに頻繁に伝送することも可能である。
【０３１４】
端末（例えば、ＵＥ）は、測定されたＣＳＩ情報を周期的にＵＬ beam pair決定過程で既に決定されたＵＬ Ｔｘ beamに伝送することができる。
【０３１５】
ＤＬ/ＵＬ beam managementプロセスを遂行するにあたり、設定を受けたbeam managementの周期に応じてビームの不一致（mismatch）の問題が発生することができる。
【０３１６】
特に、端末が位置を移動したり、端末が回転したり、あるいは前記端末の周辺物体の移動に無線チャネル環境が変わる場合（例えば、ＬｏＳ（Ｌｉｎｅ−ｏｆ−Ｓｉｇｈｔ）環境でありながら、ビームがblockされてＮｏｎ−ＬｏＳ環境に変わる場合）、最適のＤＬ/ＵＬ beam pairは変えることができる。
【０３１７】
このような変化を、一般的に、ネットワークの指示によって行われるビームmanagement過程で trackingが失敗したときのビーム失敗イベント（beam failure event）が発生したとすることができる。
【０３１８】
このようなbeam failure eventが発生するかどうかは、端末が下りリンクＲＳの受信品質を介して判断することができ、このような状況についての報告メッセージまたはビーム回復を要請するためのメッセージ（以下、「ビーム回復要請メッセージ（beam recovery request message）」と定義される）が端末から伝達されるべきである。
【０３１９】
前記ビーム回復要請メッセージは、ビーム失敗の回復要請メッセージ、制御信号、制御メッセージ、first messageなどで多様に表現することができる。
【０３２０】
前記端末から前記ビーム回復要請メッセージを受信した基地局は、ビームの回復のために端末にbeam ＲＳの伝送、beam reporting要請など、様々な過程を介してbeam回復を実行することができる。
【０３２１】
このような一連のビーム回復過程を「ビーム回復（beam recovery）」と表現する。
【０３２２】
３ＧＰＰでＬＴＥ以降ＮＲ（new radio or New Ｒａｔ）と命名した新しい通信システムの標準化が進行中であり、ビーム管理（beam management）関連して、以下のような内容が含まれる。
【０３２３】
（内容１）
【０３２４】
ＮＲはＵＥがビーム失敗（beam failure）からの回復（recovery）するメカニズムをトリガーすることができることを支援する。
【０３２５】
ネットワークは、回復の目的のために信号のＵＬ伝送の資源をＵＥに明示的に構成する。
【０３２６】
基地局が全体または一部方向から聴取（listening）している資源の構成をサポートする（例えば、ランダムアクセス領域）。
【０３２７】
（後で議論）ＲＳ/制御チャネル/データチャンネル監視のＵＥ動作に関する回復信号（新規または既存の信号）のトリガ条件
【０３２８】
ＵＥが新しい潜在的なビームを識別するために、ビームを監視できるようにするＤＬ信号の伝送をサポートする。
【０３２９】
（後で議論）beam sweep制御チャネルの伝送が排除されない。
【０３３０】
このメカニズムは、性能とＤＬシグナリングオーバーヘッドとの間のバランス（tradeoff）を考慮しなければならない。
【０３３１】
内容２）
【０３３２】
可能な下の候補ソリューションを考慮して、ビーム管理オーバーヘッドと遅延時間はＮＲビームを管理するためのＣＳＩ−ＲＳの設計中に考慮されるべきである。
【０３３３】
Ｏｐｔ１． ＩＦＤＭＡ
【０３３４】
Ｏｐｔ２．大きな副搬送波間隔（large subcarrier spacing）
【０３３５】
ＮＲビームを管理するためのＣＳＩ−ＲＳの設計中に考慮される他の側面は、例えば、ＣＳＩ−ＲＳの多重化、ＵＥビームswitch latency及びＵＥの実装の複雑さ（例えば、AGCトレーニング時間）、CSI-RSのカバレッジなどを含む。
【０３３６】
（内容３）
【０３３７】
ＣＳＩ−ＲＳは、ＤＬ ＴｘビームsweepingとUE Rxビームsweepingをサポートする。
【０３３８】
ＮＲ ＣＳＩ−ＲＳは、次のマッピング構造をサポートする。
【０３３９】
ＮＰ ＣＳＩ−ＲＳポートは（サブ）時間単位ごとにマッピングすることができる。
【０３４０】
（サブ）時間単位（unit）にかけ同じＣＳＩ−ＲＳアンテナポートがマッピングされることができる。
【０３４１】
ここで、「時間単位」は、configured/reference numerologyでｎ> ＝ １ＯＦＤＭシンボルを示す。
【０３４２】
各時間単位は、サブ−時間単位でpartitionすることができる。
【０３４３】
このマップ構造は、多数のパネル/Ｔｘ chainをサポートするために使用することができる。
【０３４４】
（Ｏｐｔｉｏｎ １）
【０３４５】
Ｔｘビームは、各時間単位内のサブ単位時間に渡って同一である。
【０３４６】
Ｔｘビームは、時間単位により異なる。
【０３４７】
（Ｏｐｔｉｏｎ  ２）
【０３４８】
Ｔｘビームは、各時間単位内でサブ時間単位ごとに異なる。
【０３４９】
Ｔｘビームは、時間単位で同じである。
【０３５０】
（Ｏｐｔｉｏｎ ３）：Ｏｐｔｉｏｎ １とＯｐｔｉｏｎ  ２の組み合わせ
【０３５１】
１つの時間単位内において、Ｔｘビームは、サブ時間単位で同じである。
【０３５２】
他の時間単位内において、Ｔｘビームは、サブ時間単位ごとに異なる。
【０３５３】
以下、本明細書で提案する方法と関連した端末のビーム失敗回復メカニズム（Beam failure recovery mechanism）について簡略に見る。
【０３５４】
前記端末のビーム失敗回復メカニズムは以下の（１）乃至（４）の過程を含む。
【０３５５】
（１）ビームの失敗を感知する。
【０３５６】
（２）新たな候補ビームを識別する。
【０３５７】
ビーム失敗の回復要請を伝送する。
【０３５８】
（４）ＵＥは、ビーム失敗の回復要請に対するｇＮＢの応答を監視する。
【０３５９】
まず、ビームの失敗を感知するプロセスに注意深く見ると、ＵＥは、ビーム失敗トリガ条件が満たされているかどうかを評価するために、ビームの失敗の感知ＲＳを監視する。
【０３６０】
それと、ビームの失敗感知ＲＳは、少なくともビームを管理するための周期的なＣＳＩ−ＲＳを含む。ここで、ＳＳ（Synchronization Signal）ブロック（block）もビーム管理に使用することができ、ＳＳ blockがビーム管理に使用される場合、サービングセル内ＳＳブロックが考慮されることができる。
【０３６１】
ここで、ＳＳ blockは、同期信号（ＳＳ）がスロット単位または特定の時間単位で伝送されるものと解釈されることができる。
【０３６２】
ここで、ビームの失敗感知ＲＳは、当該ＲＳの品質自体を測定する場合だけでなく、そのＲＳとＱＣＬ（Quasi Co-Location）指示子などに関連付けられる無線チャネルのdetection／demodulation品質を測定する場合を含む。たとえば、（primary）ＰＤＣＣＨを監視するために指示されたＣＳＩ−ＲＳもしくはＳＳ block関連ＩＤを前記ビーム失敗感知ＲＳとして理解することができ、このとき、ビーム失敗イベントが発生するかどうかは、そのＰＤＣＣＨのdetection／demodulation性能が一定以下である場合と定義することができる。
【０３６３】
前記ビーム失敗イベントの発生は、関連付けられる（associated）制御チャネルのbeam pair linkの品質が一定レベル以下に落ちたときに発生することもある。
【０３６４】
具体的に、前記関連制御チャネルのbeam pair linkの品質は、ＰＤＣＣＨ検出性能（detection performance）で決定されることもある。
【０３６５】
例えば、端末がＰＤＣＣＨを監視（またはblind decoding）する過程でＣＲＣ check結果ＰＤＣＣＨ detection性能が良くない場合、端末は、ビームの失敗を検出することができるようになる。
【０３６６】
または、multiple ＰＤＣＣＨｓがmultiple beamsを介して（またはmultiple ＰＤＣＣＨｓがそれぞれ互いに異なるbeamに）伝送された場合、特定ＰＤＣＣＨ（例えば、serving beamとassociated ＰＤＣＣＨ）の検出性能で前記ビーム失敗イベントが発生するかどうかを判断することができる。
【０３６７】
ここで、multiple ＰＤＣＣＨそれぞれは、互いに異なるcontrol channel領域（例えば、symbol、slot、subframeなど）で互いに異なるbeamごとに伝送及び/または受信することができる。
【０３６８】
この場合、beam別control  channel領域が予め定義することができたり、higher layer signalingを介して送受信することができる。
【０３６９】
また、前記関連された制御チャネルのbeam pair linkの品質で前記ビーム失敗イベントが発生するかどうかを判断するとき、ＤＬ beamの品質だけが一定水準以下に落ちたのか、またはＵＬ beamの品質だけが一定レベル以下に落ちたのか、またはＤＬ beamとＵＬ beamの品質のすべてが一定レベル以下に落ちたのかに応じて前記ビーム失敗イベントが発生するかどうかが決定されることができる。
【０３７０】
ここで、前記一定水準以下は、しきい値以下、関連付けられるタイマーのtime-outなどで有り得る。
【０３７１】
また、前記ビームの失敗を検出するsignalでＢＲＳ、fine timing/ frequency trackingのためのＲＳ、ＳＳ Blocks、ＰＤＣＣＨのためのＤＭ−ＲＳ、ＰＤＳＣＨのためのＤＭ−ＲＳなどが使用されることができる。
【０３７２】
次、新しい候補別ビーム識別プロセスについて注意深く見ると、ＵＥは、ビーム識別ＲＳを監視して、新しい候補ビームを探す。
【０３７３】
− ビーム識別ＲＳは１）ＮＷによって構成された場合、ビーム管理するための周期的ＣＳＩ−ＲＳ、２）ＳＳブロックがビーム管理に使用される場合、サービングセル内の周期的なＣＳＩ−ＲＳとＳＳブロックの情報を含む。
【０３７４】
次、ビーム失敗の回復要請の伝送プロセスについて注意深く見ると、ビーム失敗の回復要請によって運ばれる情報は、１）ＵＥと新しいｇＮＢ ＴＸビーム情報を識別するための明示的／暗黙的情報、または２）ＵＥを識別し、新しい候補ビームが存在するかどうかを明示的／暗黙的情報の内、少なくとも一つを含む。
【０３７５】
また、ビーム失敗の回復要請の伝送は、ＰＲＡＣＨ、ＰＵＣＣＨ、ＰＲＡＣＨ-like（例えば、ＰＲＡＣＨからのプリアンブルシーケンスの異なるパラメータ）のいずれか１つを選択することができる。
【０３７６】
- ビーム失敗の回復要請資源／信号は、 スケジューリング要請に加え使用することができる。
【０３７７】
次、ＵＥは、ビーム失敗の回復要請に対するｇＮＢ応答を受信するために制御チャネル検索空間を監視する。
【０３７８】
また、ビーム失敗の回復要請伝送に対して以下のトリガ条件をサポートする。
【０３７９】
− 条件：ＣＳＩ−ＲＳだけが新しい候補ビームの識別のために使用されている場合、ビームの失敗が検出され候補ビームが識別される場合
【０３８０】
また、ビーム失敗の回復要請伝送のために次のようなチャネルをサポートする。
【０３８１】
- ＰＲＡＣＨに基づいた非-競争ベースチャンネル、ＦＤＭの少なくとも他のＰＲＡＣＨ伝送の資源に直交する資源を使用する。
【０３８２】
- ビーム失敗の回復要請の伝送のためのＰＵＣＣＨをサポートする。
【０３８３】
先に注意深く見たように、ＮＲの場合、ビームの回復要請メッセージ（beam recovery request message）は、（１）ＰＲＡＣＨと同じシンボルを用いて伝送されたり（ 第１）、（２）ＰＲＡＣＨ以外のシンボルを用いて伝送する（第２）二つのメカニズム(mechanism)がすべてサポートされることができる。
【０３８４】
第１は、ビームの失敗（failure）により、アップリンク同期まで失われた場合（ビーム品質が相対的に多く落としたり、代替ビームがない場合）、それと/またはビーム失敗イベント（beam failure event）発生時点と既に設定を受けたＰＲＡＣＨ資源が時間的に近い場合に有用なメカニズムで有り得る。
【０３８５】
第２は、ビームの失敗（failure）状況やアップリンク同期は失われていない場合（ビーム品質が相対的に少し落としたり、代替ビームがある場合）、それと/またはbeam failure event発生時点と既に設定されＰＲＡＣＨ資源が時間的に遠くてＰＲＡＣＨ資源（例えば、シンボル）まで待つには、速いビーム回復が困難な場合に有用するメカニズムで有り得る。
【０３８６】
また、端末は、ビームの失敗（beam failure）の際、基地局にビーム回復要請メッセージを所定回数伝送した後、前記基地局から前記要請に対する応答を受信しなかった場合、ＲＬＦ（Radio Link Failure）の動作を実行するすることができる。
【０３８７】
以下、ビーム失敗が発生した場合に、ビームの失敗回復のためのメカニズムが簡略に記述される。
【０３８８】
ビームの失敗イベント（beam failure event）は、関連付けられた制御チャネルのビームペアリンク（beam pair link（s））の品質が十分に低くなるときに発生する（例えば、しきい値（threshold）との比較、関連付けられたタイマーのタイム - アウト（time-out）。
【０３８９】
ビームの失敗を回復するメカニズムは、ビームの失敗が発生する時にトリガされる。
【０３９０】
ここで、ビームペアリンクは便宜上使用されるものであり、使用することも使用されないことがある。
【０３９１】
品質がＮＲ−ＰＤＳＣＨと関連するビーム対リンクの品質をさらに含むことができるかどうか。
【０３９２】
複数のＹビームペアリンクが設定されるとき、Ｙビームペアリンクの内のＸ（<＝ Ｙ）がビーム失敗条件を履行するどのようなしきい値を下回すると、ビームの失敗を宣言することができる。
【０３９３】
関連ＮＲ−ＰＤＣＣＨの検索空間（端末特定対共通（ＵＥ−specific vs. common））が定義されることがある。
【０３９４】
端末の場合にＮＲ−ＰＤＣＣＨのシグナリングメカニズムは、ＮＲ−ＰＤＣＣＨの 複数のビーム対リンクを監視するように設定される。
【０３９５】
下記の信号は端末がビームの失敗を検出するためにそして端末が新しい潜在的なビームを識別するために設定されることができる。
【０３９６】
信号、例えば、ビーム管理するためのＲＳ、微細タイミング／周波数追跡（tracking）のためのＲＳ、ＳＳブロック、（グループ共通ＰＤＣＣＨ及び/または端末特定ＰＤＣＣＨを含む）ＰＤＣＣＨのＤＭ− ＲＳ、ＰＤＳＣＨのためのＤＭＲＳがある。
【０３９７】
ビームの失敗イベントが発生し、サービングセルに新しい潜在的なビームがなければ、端末がＬ３に指示（indication）を提供するかどうか。
【０３９８】
無線リンク失敗を宣言する基準は、ＲＡＮ２のために決定するものである。
【０３９９】
ＮＲは回復の目的のための要請をＲＡＣＨを含むシンボルで伝送し、及び/または他の指示されたシンボルで要請をスケジューリングするための資源の設定をサポートする。
【０４００】
下記のメカニズムは、ＮＲでサポートされるべきである：
【０４０１】
ビームの失敗を報告するＵＬ伝送は、ＰＲＡＣＨと同じ時間インスタンス（time instance）に位置することがある。
【０４０２】
ＰＲＡＣＨ資源に直交する資源
【０４０３】
周波数及び/またはシーケンス（sequence）での直交（ＰＲＡＣＨの設計に影響を及ぼさないように）
【０４０４】
ビームの失敗を報告するＵＬ伝送は、ＰＲＡＣＨと他の（端末に対して設定可能する）時間インスタンスに位置されることがある。
【０４０５】
ＰＲＡＣＨの外部にあるスロットに位置されたビームの失敗を報告するためにＵＬ信号の設定でＲＡＣＨ周期性（periodicity）の影響を考慮する。
【０４０６】
他のチャンネル／信号を使用した追加的なメカニズムが排除されない（例えば、ＳＲ、ＵＬグラントフリーＰＵＳＣＨ（ＵＬ grant free ＰＵＳＣＨ）、ＵＬ制御）。
【０４０７】
ＵＥビーム失敗回復メカニズムは、次の事項を含む：
【０４０８】
- ビーム失敗検出
【０４０９】
- 新しい候補ビーム識別
【０４１０】
- ビーム失敗の回復要請の伝送
【０４１１】
- 端末は、ビーム失敗の回復要請に対するｇＮＢの応答を監視する。
【０４１２】
ビーム失敗の検出：
【０４１３】
- 端末は、ビーム失敗トリガ条件が満たされたかどうかを評価するために、ビーム失敗の感知ＲＳを監視する
【０４１４】
- ビーム失敗感知ＲＳは、少なくともビームを管理するための周期的なＣＳＩ−ＲＳを含む
【０４１５】
ＳＳブロックもまた、ビーム管理に使用される場合、サービングセル内のＳＳブロックも考慮することができる。
【０４１６】
新しいビーム識別：
【０４１７】
- 端末は、ビーム識別ＲＳを監視して、新しい候補ビームを探す。
【０４１８】
- ビーム識別ＲＳは下記のものを含む：
【０４１９】
ＮＷによって設定を受けた場合、ビームを管理するための周期的ＣＳＩ−ＲＳ。
【０４２０】
ＳＳブロックもはまた、ビーム管理に使用される場合、サービングセル内の周期的ＣＳＩ−ＲＳとＳＳブロック。
【０４２１】
ビーム失敗の回復要請の伝送：
【０４２２】
ビームの失敗回復要請によって運ばれる情報は下記の少なくとも1つを含む。
【０４２３】
端末と新しいｇＮＢ ＴＸビーム情報を識別するための明示的／暗黙的情報
【０４２４】
端末を識別し、新しい候補ビームが存在するかどうかを明示的／暗黙的情報
【０４２５】
ビーム失敗の回復要請伝送の、次のオプションの間ダウン選択（down-selection）
【０４２６】
- ＰＲＡＣＨ
【０４２７】
− ＰＵＣＣＨ
【０４２８】
− ＰＲＡＣＨ-like（例えば、ＰＲＡＣＨとプリアンブルシーケンスの異なるパラメータ）
【０４２９】
ビーム失敗の回復要請資源/信号は、スケジューリングリクエストに加えて使用することができる
【０４３０】
端末は、ビーム失敗の回復要請に対するｇＮＢ応答を受信するために制御チャネル検索空間を監視する
【０４３１】
制御チャネル検索空間は、サービングＢＰＬと関連付けられる現在の制御チャネル検索スペースと同じか異なることができる。
【０４３２】
ｇＮＢがビーム失敗の回復要請伝送を受信しない場合、端末の追加反応
【０４３３】
ＮＷがビーム失敗の回復要請を受信するとき、少なくとも一つのメカニズムをサポートする方法を研究
【０４３４】
例えば、ＮＷはビーム報告のためのＵＬ grantを割り当て、ＮＷはビームを管理するためのＤＬ ＲＳを伝送し、ＮＷはビーム指示または確認を端末にシグナリングする。
【０４３５】
例えば、どのようなメカニズムを適用するかのＮＷ決定の端末のサポート。
【０４３６】
特定のメカニズムが仕様（specification）に影響を与えるかどうか。
【０４３７】
ビーム失敗の回復要請伝送に対して、少なくとも下記トリガ条件をサポートする：
【０４３８】
- 条件１：ＣＳＩ−ＲＳだけが新しい候補ビームの識別に使用される場合については、少なくともビームの失敗が検出され候補ビームが識別されるとき 
【０４３９】
- 条件２：互恵（reciprocity）がない場合に対して、少なくともビームの失敗が単独で検出される。
【０４４０】
回復要請が候補ビームの知識なしで伝送される方法。
【０４４１】
前記２つの条件がサポートされると、端末がどのようなトリガ条件を使用するかはｇＮＢ設定と端末能力（capability）にかかっている。
【０４４２】
［ビーム失敗の回復要請伝送のために下記のチャンネルをサポートする：
【０４４３】
- ＰＲＡＣＨに基づいた非-競争ベースチャンネル、これは少なくともＦＤＭ場合について、他のＰＲＡＣＨ伝送の資源に直交する資源を使用する。
【０４４４】
直交、例えば、他のＰＲＡＣＨ資源を有しているＣＤＭ/ＴＤＭを達成するための他の方法
【０４４５】
他の目的のためにＰＲＡＣＨと他のシーケンス及び／またはフォーマットを有しているかどうか
【０４４６】
これは、他の案件の項目でビーム失敗の回復要請を伝送するためＰＲＡＣＨ設計をの最適化試みを防止しない。
【０４４７】
このＰＲＡＣＨ資源の再伝送の動作は、規則的なＲＡＣＨ手順と類似である。
【０４４８】
- ビーム失敗の回復要請を伝送のためのＰＵＣＣＨ使用をサポートする
【０４４９】
ＰＵＣＣＨがビームスイーピングを有しているかどうか
【０４５０】
これは、ＰＵＣＣＨの設計に影響を与えることも与えないこともできる
【０４５１】
− 無競争（contention-free）ビームの失敗の回復資源の補完としての競争ベースＰＲＡＣＨ資源
【０４５２】
- 従来ＲＡＣＨ資源プール（pool）から
【０４５３】
- ４−段階ＲＡＣＨ手順が使用される
【０４５４】
- 新しい候補ビームが無競争ＰＲＡＣＨ−ｌｉｋｅ伝送（contention-free ＰＲＡＣＨ−like transmission）の資源を有してない場合は、例えば、競合ベースのＰＲＡＣＨ資源が使用される。
【０４５５】
端末がそれらの内、一つまたは２つすべてを使用するために半-固定的に（semi-statically）設定されるかどうか、もし全てであれば、端末が二つ全てで設定される場合に端末がチャネルのいずれか１つを動的選択することをサポートするかどうか。
【０４５６】
ビーム失敗の回復要請に対するｇＮＢ応答を受信するために、端末は、該当するＰＤＣＣＨ ＤＭ−ＲＳが端末で識別された候補ビーム（ＵＥ−identified candidate beam）のＲＳと空間的（spatial ）ＱＣＬになるという仮定を有してＮＲ ＰＤＣＣＨを監視する。
【０４５７】
候補ビームが予め設定を受けたセット（preconfigured set）から識別されるかどうか
【０４５８】
タイムウィンドウ（time window）の間にビーム失敗の回復要請に対するｇＮＢ応答の検出がサポートされる
【０４５９】
タイムウィンドウは設定を受けたり、予め設定される
【０４６０】
タイムウィンドウ内で監視の場合（occasion）の回数
【０４６１】
タイムウィンドウのサイズ／位置
【０４６２】
ウィンドウ内で検出される応答がない場合、端末は、要請の再送信を行うことができる。
【０４６３】
一定回数の伝送後も検出されない場合、端末は、上位層エンティティ（higher layer entities）を通知する。
【０４６４】
伝送回数または可能すると、タイマーと組み合わせて、またはタイマーによって単独で決定される
【０４６５】
ビームフォーミングシステム（beamformed system）で、端末の移動性/回転とビーム障害はＬ１/Ｌ２で頻繁のＨＡＲＱ再伝送とＬ３でリンク失敗などのＬ１、Ｌ２、及びＬ３の動作に影響を与えることができる。
【０４６６】
ＲＡＮ２観点から、ＮＲで速いリンク回復を提供する方法は、これと関連して、重要な主題になることができる。しかし、リンク失敗の状況（つまり、長時間一定のしきい値の下にあるリンクの品質）を最大限に防止するために、物理階層メカニズムを提供することが、さらに良い。
【０４６７】
ＲＡＮ１観点から、ビームの速いスイッチングをサポートするメカニズムは、制御/データチャネルの堅牢性を提供するために考慮されることができる。ネットワーク開示方法及び端末開示の方法のすべてを考慮することができる。ネットワーク開示方法について、ネットワークは、ＤＬまたはＵＬ ＲＳ伝送をトリガ、または活性化させることができる。端末は、指示/設定されるときのみビーム情報を報告することができる。これらの方法は、端末が比較的長時間の間いかなる信号も、フィードバック情報も伝送しないときに制限される。
【０４６８】
例えば、周期的ビームレポート及び周期的ＣＳＩレポートは速いリンク適応のために端末に設定されることができる。レポート期間が短すぎると、本来の目的が満たされることがないが、あまりにも多くのＤＬ/ＵＬ資源を消費することができる。
【０４６９】
それで、ネットワーク開示方法だけでなく、端末開示方法をサポートすることに同意した。端末がビームを管理するための周期的ＣＳＩ−ＲＳからビーム/リンク品質の劣化を検出するときにＵＬ伝送が実行されることにも同意した。
【０４７０】
サービングセル内ＳＳブロックもＣＳＩ−ＲＳのオーバーヘッド（overhead）を減らすために、ビーム管理に使用することができる。また、ＮＲ−ＰＤＣＣＨのサービングビームは、ビームを管理するためのＣＳＩ−ＲＳを用いてビーム精製（refinement）手順が実行されるまでＳＳブロックと関連付けされる。ネットワークは、ビーム管理にどのようなＲＳを使用するかを自由に選択することができる。高移動性ＵＥのために、例えば、ネットワークは、ＵＥの移動性により容易にひっくり返る（outdated）不必要な測定と報告を避けるために、ビーム管理ＲＳだけＳＳブロックを構成することができる。したがって、ＳＳブロックは、端末がビームを管理するためのＳＳブロックだけを使用するように設定されると、ビームの失敗の検出に使用される必要がある。
【０４７１】
＜提案１>
【０４７２】
ビーム管理について、ＳＳブロックベースのビーム管理とＣＳＩ−ＲＳベースビーム管理のすべてをサポートする。ネットワークは、ビームレポートセッティングにいずれのＲＳを使用するかを設定することができる。
【０４７３】
＜提案２＞
【０４７４】
ビームの失敗イベントは、ＳＳブロックビーム管理またはＣＳＩ−ＲＳビームを管理するために設定を受けたＲＳに対し定義される。
【０４７５】
端末がＣＳＩ−ＲＳベースビーム管理で動作するように設定されると、ビームの回復が下記の２つの場合に使用することができる。
【０４７６】
場合１：設定を受けたＣＳＩ−ＲＳビームの内、サービングＣＳＩ−ＲＳビームを変更。
【０４７７】
場合２：新しいＣＳＩ−ＲＳビームを伝送要請。
【０４７８】
図７は、場合１の技術を例示して、図８は、場合2の技術を例示する。
【０４７９】
図７に示すように場合１において、端末は、ビーム管理のために周期的に伝送された／設定を受けたＣＳＩ−ＲＳから新しいＣＳＩ−ＲＳビームを見つけることができると仮定される。それでは、ＵＬビーム失敗回復信号がビーム情報報告のためのＵＬ容器（container）を獲得するように伝送される。この場合に、サービングＳＳブロックに関連付けられたＵＬチャネルは、ビームの回復要請を伝送するためにに使用することができる。
【０４８０】
図８に示すようにケース２において、ビーム管理のために周期的に伝送された／設定を受けたＣＳＩ−ＲＳから新しいＣＳＩ−ＲＳビームがないと仮定される。ＳＳバーストセット（burst set）から、端末は、最高のＳＳブロックが新しい候補ビームと見なされることができ、ビームの回復要請を伝送するためのＵＬチャネルを識別するために使用することができるようビーム 失敗から回復するように最高のＳＳブロックを見つけることができる。この場合に、ＴＲＰは、ＵＬ信号の受信時にビーム精製のためのＣＳＩ−ＲＳを端末に伝送することができ、その次に、端末はＣＳＩ−ＲＳビーム情報を報告することができる
【０４８１】
＜提案３＞
【０４８２】
ＳＳブロックはまた、新しい候補ビーム識別に使用される。
【０４８３】
前記で言及されたように、ｇＮＢは、ＵＬ信号を介してビームの失敗を認識することができ、ＣＳＩ−ＲＳビーム情報を報告するようにＵＬ資源の割り当て（つまり、場合１）またはビーム精製のためのＣＳＩ−ＲＳの伝送（つまり、場合２）などの適切な措置をとる必要がある。回復要請に関して、ｇＮＢはどのような措置を適用するかの最終決定を下すことができる。 ｇＮＢは端末が以前に測定されたＣＳＩ−ＲＳビームの情報を有しているかどうかについてのいかなる情報も有していないので、端末が速いで効率的なビーム精製のための新しい候補ＣＳＩ−ＲＳビームの情報を有しているかどうかについての情報を報告する必要がある。この情報は、ＵＬビーム回復要請信号／資源に含まれることができる。例えば、端末が場合１と２の間の好みをｇＮＢに指示することができるようビーム回復のためのＵＬ信号／資源が別に場合１と２にそれぞれ割り当てることができる。
【０４８４】
＜提案４＞
【０４８５】
ＮＲは新しいＣＳＩ−ＲＳビームが存在するかどうかを指示するための明示的／暗黙的シグナリングをサポートする。
【０４８６】
ビーム回復を要請するためＵＬ伝送に対して、ネットワークは 回復の目的のための信号のＵＬ伝送のための資源として端末に明示的に設定することに同意した。 ＵＬタイミング同期化（timing synchronization）側面、要請を聞くためのＴＲＰ Ｒｘビームセッティング、及び標準の影響（standard impact）を考慮すると、解決策の一つは、ビーム回復要請を目的として、一部のＰＲＡＣＨ資源を専用する（dedicate）もので有り得る。 ＴＲＰは、端末がランダムアクセスまたはＰＲＡＣＨ信号の感知からビーム回復を必要とするかを区別することができる。十分なＰＲＡＣＨ資源があると、非-競争ベースＰＲＡＣＨがこの目的に適切なようだ。 ＰＲＡＣＨの設計に影響を与えないために、ＦＤＭまたはＣＤＭ方式でＰＲＡＣＨ資源に直交する資源で伝送されたＵＬ信号も考慮することができる。ここで、ＦＤＭの場合がサポートされた。
【０４８７】
それでは、 ＣＤＭの場合もＰＲＡＣＨをベースにした非-競争ベースのチャネルに好まれる。ＰＲＡＣＨの一部シーケンスは、追加時間／周波数資源がＣＤＭの場合で必要としないようにビーム回復要請の使用に專用されることができる。
【０４８８】
ＰＲＡＣＨ資源とＦＤＭされた／ ＣＤＭされた（ＦＤＭｅｄ/ＣＤＭｅｄ）資源に伝送されたビームの失敗回復のためのＵＬ信号／資源は、便宜上専用（dedicated）ＰＲＡＣＨビーム回復資源と称する。専用ＰＲＡＣＨ資源と伝送可能な情報のペイロードサイズが非常に小さいことができるようＴＲＰは、専用ＰＲＡＣＨ資源の受信のためのそのＲｘビームをスイープ（sweep）することができる。また、競争ベースＰＲＡＣＨ資源も専用ＰＲＡＣＨビーム回復資源を補うために、ビームの回復要請の伝送に使用することができる。
【０４８９】
ビームの失敗回復のためのＵＬ信号／資源がＰＲＡＣＨと他の時間インスタンスで伝送されることができるということがサポートされる。
【０４９０】
ビーム回復要請のため のＰＲＡＣＨ-like資源だけでなく、ＰＵＣＣＨを使用することが 同意される。ビーム回復要請のためＰＵＣＣＨ伝送のための候補ビームは、予め設定を受けたセットから識別される。また、このＰＵＣＣＨ資源もＵＬビームペアリンクがまだ生きている（alive）時、速いビーム失敗の回復要請に使用することができる。専用ＰＲＡＣＨ資源は、ＰＵＣＣＨがさらに短い期間を有して使用することが設定されるようにＰＲＡＣＨ設定に基づいて、長い周期性を有することができる。従って、ＰＲＡＣＨとＴＤＭされた資源が必要としないように、さらに短いデューティサイクル（duty cycle）を有したＰＵＣＣＨが専用のＰＲＡＣＨ資源を十分に補うことができる。 ＴＲＰはＰＵＣＣＨを設定することができ、優先のＴｘビーム指示子（indicator）及び/またはそのサイズ（例えば、シンボルの数）に応じたそのビーム品質などの、さらに多くのビーム情報を含むことができる。ビーム回復要請のためＰＵＣＣＨのペイロードサイズに応じて、後続の手順、すなわち、ビーム報告トリガとビーム報告が必要としないことがある。部分ビーム情報（例えば、差動（differential）ＲＳＲＰがビーム失敗の回復要請と一緒に報告されたことも考慮することができる。
【０４９１】
＜提案５＞
【０４９２】
ビーム失敗の回復要請の伝送するためにトリガ条件をサポートする：
【０４９３】
条件２：ビームの失敗は、単独で検出される。
【０４９４】
＜提案６＞
【０４９５】
ビーム失敗の回復要請の伝送するために下記チャンネルをサポートする。
【０４９６】
ＰＲＡＣH資源とＣＤＭされた非-競争ベースチャンネルベース（non-contention based channel based）ＰＲＡＣＨ
【０４９７】
ＴＤＭ場合は必要でない。
【０４９８】
ＦＤＭの場合は、すでにサポートされる。
【０４９９】
非-競争ベースチャンネルベースＰＲＡＣＨを補うための競争ベースＰＲＡＣＨ
【０５００】
＜提案７＞
【０５０１】
ＰＵＣＣＨを使用する際、ビーム情報の一部は、ＰＵＣＣＨのペイロードサイズに応じてビーム失敗の回復要請と一緒に報告されることができる。
【０５０２】
ビーム失敗の回復要請に対して、端末は、専用ＰＲＡＣＨとＰＵＣＣＨなどの多数の資源を同時に使用するように設定することができる。この場合に、この資源の1つは、ビーム回復要請を再伝送するために使用されるように制限されることができる。例えば、ビーム失敗の回復要請後ｇＮＢから応答がない場合、端末は、ＰＵＣＣＨの代わりに専用のＰＲＡＣＨ資源のみを使用することで、要請メッセージを再伝送する必要があることがある。これは、ＰＵＣＣＨが速いビーム回復要請に使用することができるがチャンネルの変動に脆弱であるため、メッセージを再送信するために専用ＰＲＡＣＨ資源を使用することがさらに安全である。
【０５０３】
＜提案８＞
【０５０４】
端末がビーム回復要請のために専用ＰＲＡＣＨとＰＵＣＣＨのすべてを使用するように設定すると、専用ＰＲＡＣＨは、初期要請を伝達しなかった場合に使用される必要がある。
【０５０５】
ビームの失敗を回復するためのメカニズムが研究されており、次のように提案された：
【０５０６】
（提案１）：ビーム管理については、ＳＳブロックベースのビーム管理とＣＳＩ−ＲＳベースビーム管理のすべてをサポートする。ネットワークは、ビーム報告セッティングにいずれののＲＳを使用するかを設定することができる。
【０５０７】
（提案２）：ビームの失敗イベントは、ＳＳブロックビーム管理またはＣＳＩ−ＲＳビーム管理のために設定を受けたＲＳに対して定義される。
【０５０８】
（提案３）：ＳＳブロックは、また新たな候補ビームの識別に使用される。
【０５０９】
（提案４）：ＮＲは、新しいＣＳＩ−ＲＳビームが存在するかどうかを指示するための明示的/暗黙的シグナリングをサポートする。
【０５１０】
（提案５）：ビーム失敗の回復要請の伝送のための下記トリガ条件をサポートする：
【０５１１】
条件２：ビーム失敗は、単独で検出される。
【０５１２】
（提案６）：ビーム失敗の回復要請の伝送のための下記チャンネルをサポートする。
【０５１３】
ＰＲＡＣＨ資源とＣＤＭされた非-競争ベースチャンネルベース（non-contention based channel based）ＰＲＡＣＨ
【０５１４】
ＴＤＭ場合は必要しない。
【０５１５】
ＦＤＭの場合は、すでにサポートされている。
【０５１６】
非-競争ベースチャンネルベースＰＲＡＣＨを補うための競争ベースＰＲＡＣＨ
【０５１７】
（提案７）：ＰＵＣＣＨを使用する場合、ビーム情報の一部は、ＰＵＣＣＨのペイロードサイズに応じてビーム失敗の回復要請と一緒に報告されることができる。
【０５１８】
（提案８）：端末がビーム回復要請のために専用ＰＲＡＣＨとＰＵＣＣＨすべてを使用するように設定すると、専用ＰＲＡＣＨは、初期要請を伝達しなかった場合に使用される必要がある。
【０５１９】
前述したように、端末がビーム失敗の回復要請（beam failure recovery request）を基地局に伝送するために、多数のビーム回復要請チャンネル／信号（beam recovery request channel/signal）が考慮されることができる。
【０５２０】
前記ビーム回復要請チャンネル（または信号）は、ＰＲＡＣＨ（Physical Random Access Channel）と同じ時間資源（time resource）を使用することで、ＰＲＡＣＨ資源とＦＤＭされるか、またはＣＤＭされた非-競争ベースＰＲＡＣＨチャンネル（non- contention based channel based on ＰＲＡＣＨ ＦＤＭｅｄ/ＣＤＭｅｄ with ＲＲＡＣＨ resource）または競合ベースのＰＲＡＣＨチャンネル（contention based ＰＲＡＣＨ channel）を考慮し（以下、「タイプＡ回復資源（type Ａ recovery resource）」と称する）することができる。
【０５２１】
または、前記ビーム回復要請チャンネル（または信号）は、ＰＲＡＣＨ以外の時間資源（timeresource）を使用することで、ＰＵＣＣＨ及び/またはＰＲＡＣＨ資源とＴＤＭされた非-競争ベースＰＲＡＣＨチャンネル（non-contention based channel based ＰＲＡＣＨ ＴＤＭｅｄ with ＲＲＡＣＨ resource）も考慮（以下、「タイプＢの回復資源（type Ｂ recovery resource）」と称する）することができる。
【０５２２】
すなわち、前記タイプＡ回復資源はＰＲＡＣＨと同じ時間資源を使用する場合をいい、前記タイプＢ回復資源はＰＲＡＣＨと、他の時間資源を使用する場合を言うことができる。
【０５２３】
そして、前記端末は、前記基地局からビーム失敗回復（beam failure recovery）のために、様々な資源（resource）の設定を受けることができる。
【０５２４】
以下、本明細書で提案する複数のビーム回復要請（beam recovery request）資源の設定を受けた端末の動作について、様々な実施例を介して注意深く見る。
【０５２５】
（第１実施例）
【０５２６】
第１実施例は、端末が基地局から多数のビーム回復要請（beam recovery request）資源を割り当てられた（または設定を受けた（cofigured））場合、前記割り当てられた資源の内、一部は、前記ビームの回復要請の再伝送資源として制約される指示または設定を前記基地局から受信することができる。
【０５２７】
もし端末がビームの失敗を検出（Beam failure detection）した場合、前記端末は、前記基地局から割り当てを受けた、または設定を受けた資源の内、一つに前記基地局にビーム（失敗）の回復（beam（failure）recovery）を要請することができる。
【０５２８】
前記端末が前記基地局にビーム回復（Beam recovery）を要請した後、前記端末が一定時間ウィンドウ（time window）の間に基地局（例えば、ｇＮＢ）から前記要請に対する応答（response）を受信しなかった場合、前記端末は、ビームの回復要請（beam recovery request）を再び前記基地局に要請することができる。
【０５２９】
このとき、前記ビームの回復要請（beam recovery request）資源の一部（eg、ＰＵＣＣＨ、またはＰＲＡＣＨ資源とＴＤＭされた非-競争ベースＰＲＡＣＨチャンネル）は、速いビーム回復（fast beam recovery）のために割り当てることができる。
【０５３０】
または、前記ビーム回復要請資源の一部は、特定または一部のＤＬ beam fair linkのみfailである場合、及び/またはＵＬ beam fair linkが存在する場合に有用する可能性が大きいため、基地局は、これを考慮して再伝送資源としての使用に関する制限を前記端末に指示または設定することができる。
【０５３１】
例えば、ＰＵＣＣＨ資源（ie、type Ｂrecovery resource）を再伝送資源として使用しない端末の場合には、ＰＵＣＣＨで初期にbeam recovery requestを要請し、前記ビームの回復要請に対する応答（response）を基地局から受信しない場合（つまり、fast beam recoveryが不可能なほどのチャンネル変動が激しいか、または、および/またはＵＬ beam failure linkがfailされたと考えか、及び/またはＤＬ beam fair linkがすべてfailの場合）、前記端末は前記ＰＵＣＣＨで再伝送をせずにType Ａ recovery resourceを用いて、ビームの回復要請（beam recovery request）を基地局に伝送することができる。
【０５３２】
（方法１）
【０５３３】
端末が基地局から多数のビーム回復要請（beam recovery request）資源を割り当て、または設定を受けた場合、前記端末は、ビームの回復要請（beam recovery request）のための伝送優先順位（priority）または条件を前記基地局から設定または指示を受けることができる。
【０５３４】
ここで、先、注意深く見たtype Ａ recovery resourceとtype Ｂ recoveryresourceの要請（request）の可能伝送周期またはタイミング（timing）は、タイプ別にたがいに異なるように定義することができる。
【０５３５】
最も簡単な方法として、端末がビーム失敗検出（beam failure detection）を判断する場合には、前記端末は、最も早いタイミング（timing）に設定されたビームの回復要請（beam recovery request）資源を用いて、ビームの回復要請（recovery request）を実行することができる。
【０５３６】
もし、type Ａ recovery resourceとtype Ｂ recovery resourceの伝送timing差が特定の基地局が設定した「ｘ」slots（またはsymbols）以内である場合、前記端末は、前記type Ｂ recovery  resourceのtimingが先来してもtype Ａ recovery resourceを優先的に伝送するようしようとする優先順位（priority）の指示や設定を基地局から受信することができる。
【０５３７】
また、ビーム失敗（beam failure）の条件は、多数のしきい値（threshold）またはビーム失敗リンク（beam fail link）の数に応じて多数の状態（state）を有することができる。
【０５３８】
したがって、前記基地局は、前記ビームの失敗状態（beam failure state）に基づいてビーム回復要請（beam recovery request）の伝送のための資源を端末に指示または設定することができる。
【０５３９】
例えば、一部のビームのみfailたり、beam fail程度が低い場合（ｅ．ｇ、ビーム失敗状態１（beam failure state １））、端末は、type Ｂ recovery resourceを優先的に用いてbeam recoveryを実行し、ほとんどのビームがfailしたり、beam failure程度が高い場合（ｅ．ｇ、ビーム失敗状態２（beam failure state ２））、前記端末は、type Ａ recovery resourceを優先的に用いてbeam recoveryを実行するように基地局は、前記端末に指示または設定することができる。
【０５４０】
また、前記特定、または一部のビームfair linkのみfailされるか、またはビームlink failが起こる場合には、前記端末がtype B（e．g、ＰＵＣＣＨ）recovery resourceを（優先的に）ビーム失敗回復（beam failure recovery）に使用する場合、基地局は、前記端末に前記type Ｂ recovery resourceにどのbeam linkがfailであるかのindexまたはinformationを伝送することができる。
【０５４１】
（第２実施例）
【０５４２】
次に、ビーム回復要請のためにtype Ｂ recovery resourceを使用する場合について、第２実施例を介してさらに具体的に注意深く見ることにする。
【０５４３】
第２実施例は、ビーム失敗の回復（Beam failure recovery）のためにＰＵＣＣＨ format（あるいはUCI）を用いている場合は、前記ＰＵＣＣＨ formatは、他のＰＵＣＣＨ format（あるいはＵＣＩ）（e．g、ＣＳＩレポート用のＰＵＣＣＨ、Ａｃｋ/Ｎａｃｋ用ＰＵＣＣＨ format、データスケジューリング要請（data scheduling request）用ＰＵＣＣＨ）に比べて、さらに高い優先順位（higher priority）を有するように定義することができる。
【０５４４】
第１実施例注意深く見たように、ビーム失敗の回復要請（beam failure recovery request）のために、端末はＰＵＣＣＨを用いることができる（type B recovery resource）。
【０５４５】
したがって、前記ビーム失敗の回復（beam failure recovery）のために、別のＰＵＣＣＨ format（あるいはＵＣＩ）の伝送を考慮することができる。
【０５４６】
前記ビーム失敗回復（Beam failure recovery）のためのＰＵＣＣＨ format（あるいはＵＣＩ伝送）は、速いリンクの回復（link recovery）のために、他のＰＵＣＣＨ format（あるいはＵＣＩ伝送）に比べ、さらに高い優先順位（higher priority）を有することができる。
【０５４７】
例えば、ＣＳＩ報告のためのＰＵＣＣＨ、ＡＣＫ（Acknowledgement／ ＮＡＣＫ（Non-Acknowledgement）用ＰＵＣＣＨの伝送、ＵＬ data scheduling request用ＰＵＣＣＨがそのslot（またはsubframe）にconfigureされた端末に対してビーム回復（ beam recovery）が必要な場合、端末は、ビームの失敗の回復（beam failure recovery）ＰＵＣＣＨ format（またはＵＣＩ（Uplink Control Information））を優先的に基地局に伝送する。
【０５４８】
もし、前記ビーム失敗回復ＰＵＣＣＨ foramtと他のＰＵＣＣＨ formatの同時伝送が不可能な場合、前記他のＰＵＣＣＨ format（あるいはＵＣＩ伝送）は、ドロップ（drop）することができる
【０５４９】
前記ＰＵＣＣＨ伝送のための優先順位のルール（priority rule）は、予め基地局が端末に上位層シグナリング（higher layer signaling）を介して指示または設定可能である。
【０５５０】
また、ビーム失敗の回復要請（beam failure recovery request）のためのＰＵＣＣＨを二つのtypeで考慮することができる。
【０５５１】
第１のtypeは、data scheduling requestのようにon/offあるいは１ｂｉt beam failureの可否だけを知らせるbeam failure indication type（以下、「indicator type ＰＵＣＣＨ」と称する）である。
【０５５２】
第２のtypeは、当該ＰＵＣＣＨに新たに見つかったbeam candidateのindex、ＲＳＲＰ、既存のどのserving beam linkが壊れているかのindexなどのビーム回復要請（beam recovery request）だけでなく、追加的な情報を含む‘message type ＰＵＣＣＨ’である。
【０５５３】
このとき、「indicator type ＰＵＣＣＨ」は競争ベース（contention based）ＰＲＡＣＨと類似に、基地局が運営するＮ個の（アナログ）ビームのそれぞれについてassociatedされ、端末に総Ｎ個（あるいは<Ｎ個）の資源がconfigureことができる。
【０５５４】
例えば、beam failureが起きた場合、端末は、新しいbeam candidateを見つけることができ、前記新しいbeamにconfiguredされた「indicator type ＰＵＣＣＨ」を用いて、beam failure recovery request動作を行うことができる。
【０５５５】
ここで、基地局は、前記indicator type  ＰＵＣＣＨの場合、基地局運ビームとの関連（association）を用いて、そのＰＵＣＣＨを受信した場合、端末の新しいbeam candidateをimplicitに知ることができる。
【０５５６】
前記「message type  ＰＵＣＣＨ」は、基地局がその端末から特定Ｋ（<Ｎ）個のbest beam（あるいはserving beam link）にassociatedされて設定してくれることができる。
【０５５７】
例えば、first best beam（あるいはfirst serving beam link）がbeam failure宣言された場合、前記first best beamにconfiguredされたmessage type ＰＵＣＣＨを用いて端末が基地局にbeam failure recovery要請することができる。
【０５５８】
このとき、さらに前述したように、追加の新しいbeam candidateに関する情報の伝送を介して、速いビーム回復（fast beam recovery）を実行することができる。
【０５５９】
前記indicator type ＰＵＣＣＨ、message type ＰＵＣＣＨ及び/または、非-競争ベースＰＲＡＣＨ channel（e.g．、type Ａ recovery resource）のすべてが割り当てられた端末に対して、端末は、段階的にbeam failure recovery requestをすることができる。
【０５６０】
（１）第１段階（Ｓｔｅｐ１）
【０５６１】
第１段階 は、特定、あるいは一部のserving beam linkがbeam  failure発生時、前記best beamに対応するmessage type ＰＵＣＣＨを介してbeam failure recovery requestを実行する。
【０５６２】
（２）第２段階（Ｓｔｅｐ２）
【０５６３】
第２段階は、もし第1段階にrequest実行が失敗して、基地局responseを受信しなかった場合、端末はindicator type ＰＵＣＣＨまたは非-競争ベースＰＲＡＣＨ（non-contention based channel based ＰＲＡＣＨ）を用いてrecovery requestを実行する。
【０５６４】
（３）第３段階（Step ３）：もしStep ２まで失敗した場合には、端末は、競争ベースＰＲＡＣＨ channel（contention based ＰＲＡＣＨ）を用いてrecovery requestを実行する。
【０５６５】
また、ビーム失敗の回復要請のtime window内のすべてのserving beam linkにbeam failureが発生した場合、ＵＬ干渉（interference）とパワー消費（power consumption）を減らすために、端末はmessage type ＰＵＣＣＨを除外してindicator type ＰＵＣＣＨ及び/または非-競争ベースＰＲＡＣＨ channel（non-contention based channel based ＰＲＡＣＨ）を介してbeam recovery要請をすることができる。
【０５６６】
次、「Message type ＰＵＣＣＨ」でビーム失敗の回復要請（beam failure recovery request）を実行した端末の場合、前記回復要請（recovery request）の基地局のresponseに対し既存の設定されたspatial ＱＣＬ parameterを仮定してＰＤＣＣＨを受信することができる。
【０５６７】
前記端末が ビーム失敗の回復要請に対するｇＮＢの応答を受信するために、前記端末は、該当するＰＤＣＣＨ ＤＭ−ＲＳが端末で識別された候補ビームのＲＳとspatial ＱＣＬされたと仮定を有してＮＲ ＰＤＣＣＨを監視する。
【０５６８】
即ち、端末は、ビームの回復要請に対する基地局の応答（response）を受信するために、自分が探した候補ビーム（candidate beam）のＲＳにspatial ＱＣＬを仮定してＰＤＣＣＨを受信することができる。
【０５６９】
つまり、端末が見つかったcandidate beam ＲＳの受信ビームに前記端末は、基地局から前記回復要請のresponseを受信する。
【０５７０】
「Message type ＰＵＣＣＨ」の場合、前述のように、特定、あるいは一部のＤＬ beam fair linkのみfailである場合、またはＵＬ beam fair linkがまだ生きている時、主に使用することができる。
【０５７１】
例えば、基地局が端末に２つのserving beamで（e.g、secondary serving beamさらに短い周期を有するprimary serving beam、primary serving beamより長い周期を有するsecondary serving beam）マルチビーム（multi beam ）ＰＤＣＣＨ monitoringを指示または設定与えることができる。
【０５７２】
このとき、前記「Message type ＰＵＣＣＨ」は、主にprimary serving beamのみbeam failure発生時、前記secondary beamの互恵的なＵＬ beamにbeam recovery requestを実行するか、または、予め設定されたＵＬ beamにbeam recovery requestを実行することができる。
【０５７３】
このとき、端末は前記message type ＰＵＣＣＨを用いたrecovery requestの基地局のresponseの受信を、既存secondary serving beamの対応ＰＤＣＣＨに期待することができるので、既存の設定されたspatial ＱＣＬ parameterを仮定してＰＤＣＣＨを受信する。
【０５７４】
すなわち、前記message type ＰＵＣＣＨはmain serving beam（s）switch requestとして動作することができる。
【０５７５】
図９は、本明細書で提案するビーム失敗の回復を実行する方法の一例を示したフローチャートである。
【０５７６】
まず、端末は、ビーム失敗の回復要請（beam failure recovery request）に関する資源の設定を基地局から受信する（Ｓ９１０）。
【０５７７】
ここで、前記ビーム失敗の回復要請に関連する資源の特定の資源は、後述する第２資源に利用されないことがある。
【０５７８】
以降、前記端末は、ビーム管理（beam management）に使用されるビーム基準信号（beam reference signal：ＢＲＳ）を前記基地局から受信する（Ｓ９２０）。
【０５７９】
以降、前記端末は、ビーム失敗イベント（beam failure event）が検出された場合、前記資源設定に基づいて、ビーム失敗の回復要請（beam failure recovery request）を第１資源を用いて前記基地局に伝送する（Ｓ９３０）。
【０５８０】
ここで、前記ビーム失敗の回復要請はＰＲＡＣＨ（Physical Random Access Channel）と同じ時間資源を使用することができ、前記ＰＲＡＣＨと前記時間資源でＦＤＭ（Frequency Division  Multiplexing）されることができる。
【０５８１】
または、前記第１資源は、非 - 競合ベース（non-contention based）ＰＲＡＣＨで有り得る。
【０５８２】
この場合、後述する第２資源は、競合ベースの（contention based）ＰＲＡＣＨで有り得る。
【０５８３】
すなわち、端末は非-競争ベースＰＲＡＣＨを介してビーム失敗の回復要請を伝送し、前記基地局から前記ビーム失敗の回復要請に対する応答を受信しなかった場合には、競争ベースのＰＲＡＣＨを介して前記ビーム失敗の回復要請を伝送することができる。
【０５８４】
また、前記ビーム失敗の回復要請はＰＵＣＣＨ（Physical Uplink Control Channel）を介して伝送されることができる。
【０５８５】
具体的には、前記ビーム失敗の回復要請は、ビームが失敗するかどうかだけを知らせる指示子タイプ（indicator type）ＰＵＣＣＨまたは候補ビーム（candidate beam）の情報を含むメッセージタイプ（message type）ＰＵＣＣＨを用いて前記基地局に伝送されることができる。
【０５８６】
もし、前記ビーム失敗の回復要請がメッセージタイプ（message type）ＰＵＣＣＨである場合、前記端末は、前記候補ビームのＲＳ（Reference Signal）にＱＣＬを仮定して、前記ビーム失敗の回復要請に対する応答を受信することができる。
【０５８７】
すなわち、前記端末は、前記候補ビームのＲＳを受信するビームとして前記ビーム失敗の回復要請に対する応答（ＰＤＣＣＨ）を受信することができる。
【０５８８】
さらに、前記端末が、前記ビーム失敗の回復要請に対する応答を、前記基地局から受信していない場合、前記端末は、前記ビーム失敗の回復要請を第２資源を用いて再伝送することができる。
【０５８９】
ここで、前記ビーム失敗の回復要請のために、前記指示子タイプＰＵＣＣＨと前記メッセージタイプＰＵＣＣＨが割り当てられ、前記ビーム失敗イベントが特定のサービングビームリンク（serving beam link）のビーム失敗である場合、前記端末は、前記第１資源で、前記メッセージタイプＰＵＣＣＨを用いて、ビーム失敗の回復要請を伝送し、前記ビーム失敗の回復要請に対する応答を受信しなかった場合、前記端末は、前記第２資源で、前記指示子タイプＰＵＣＣＨを用いて前記ビーム失敗の回復要請を再伝送することができる。
【０５９０】
また、前記第１資源で、前記ビーム失敗の回復要請が他のＰＵＣＣＨ formatと重畳する場合には、前記他のＰＵＣＣＨ formatはドロップ（drop）することができる。
【０５９１】
すなわち、前記ビーム失敗の回復要請が最も高い優先順位を有することができる。
【０５９２】
以降、前記端末は、ビームレポート（beam reporting）がトリガされた（triggered）場合、前記ビーム基準信号による測定結果を前記基地局に報告し（report）する（Ｓ９４０）。
【０５９３】
本発明が適用されることができる装置一般
【０５９４】
図１０は、本発明の一実施形態に係る無線通信装置のブロック構成図を例示する。
【０５９５】
図１０を参照すると、無線通信システムは、基地局（またはネットワーク）１０１０と端末１０２０を含む。
【０５９６】
基地局１０１０は、プロセッサ（processor、１０１１）、メモリ（memory、１０１２）、及び通信モジュール（communication module、１０１３）を含む。
【０５９７】
プロセッサ１３１１は、先に図１〜図９で提案された機能、プロセス及び/または方法を実現する。有線/無線インターフェースプロトコルの階層は、プロセッサ１０１１によって実現されることができる。メモリ１０１２は、プロセッサ１０１１と接続されて、プロセッサ１０１１を駆動するための様々な情報を貯蔵する。通信モジュール１０１３は、プロセッサ１０１１と接続されて、有/無線信号を送信及び/または受信する。
【０５９８】
前記通信モジュール１０１３は、無線信号を送／受信するためのＲＦ部（radio frequency unit）を含むことができる。
【０５９９】
端末１０２０は、プロセッサ１０２１、メモリ１０２２及び通信モジュール（またはＲＦ部）１０２３を含む。プロセッサ１０２１は、先に図１〜図９で提案された機能、プロセス及び/または方法を実装する。無線インターフェースプロトコルの階層は、プロセッサ１０２１によって実現されることができる。メモリ１０２２は、プロセッサ１０２１と接続され、プロセッサ１０２１を駆動するための様々な情報を貯蔵する。通信モジュール１０２３は、プロセッサ１０２１と接続されて、無線信号を送信及び/または受信する。
【０６００】
メモリ（１０１２、１０２２）は、プロセッサ（１０１１、１０２１）の内部または外部にあることができ、よく知られている様々な手段でプロセッサ（１０１１、１０２１）と接続することができる。
【０６０１】
また、基地局１０１０、及び/または端末１０２０は、一本のアンテナ（single antenna）、または多重アンテナ（multiple antenna）を有することができる。
【０６０２】
図１１は、本発明の一実施形態に係る通信装置のブロック構成図を例示する。
【０６０３】
特に、図１１においては、先の図１０の端末をさらに詳細に例示する図である。
【０６０４】
図１１を参照すると、端末は、プロセッサ（またはデジタル信号プロセッサ（ＤＳＰ：digital signal processor）１１１０、ＲＦモジュール（ＲＦ module）（またはＲＦユニット）１１３５、パワー管理モジュール（power management module ）１１０５、アンテナ（antenna）１１４０、バッテリー（battery）１１５５、ディスプレイ（display）１１１５、キーパッド（keypad）１１２０、メモリ（memory）１１３０、ＳＩＭカード（ＳＩＭ（ Subscriber Identification Module）card１１２５この構成では、オプションです）、スピーカー（speaker）１１４５及びマイクロフォン（microphone）１１５０を含みから構成されることができる。端末はまた、単一のアンテナまたは多重のアンテナを含むことができる。
【０６０５】
プロセッサ１１１０は、先の図１〜図９で提案された機能、プロセス及び/または方法を実現する。無線インターフェースプロトコルの階層は、プロセッサ１１１０によって実現されることができる。
【０６０６】
メモリ１１３０は、プロセッサ１１１０と接続され、プロセッサ１１１０の動作と関連した情報を貯蔵する。メモリ１１３０は、プロセッサ１１１０の内部または外部に有り得、よく知られた様々な手段でプロセッサ１１１０と接続することができる。
【０６０７】
ユーザは、例えば、キーパッド１１２０のボタンを押すか、（あるいはタッチするか、）またはマイクロフォン１１５０を用いた音声駆動（voice activation）によって電話番号などのコマンド情報を入力する。プロセッサ１１１０は、このようなコマンドの情報を受信し、電話番号に電話をかけるなど、適切な機能を実行するように処理する。駆動上のデータ（operational data）は、ＳＩＭカード１１２５またはメモリ１１３０から抽出することができる。また、プロセッサ１１１０は、ユーザが認知し、また利便性のために、コマンド情報または駆動情報をディスプレイ１１１５上に表示することができる。
【０６０８】
ＲＦモジュール１１３５は、プロセッサ１１１０に接続されて、ＲＦ信号を送信及び/または受信する。プロセッサ１１１０は、通信を開始するために、例えば、音声通信データを構成する無線信号を伝送するように命令情報をＲＦモジュール１１３５に伝達する。 ＲＦモジュール１１３５は、無線信号を受信及び送信するために受信機（receiver）と伝送機（transmitter）で構成される。アンテナ１１４０は、無線信号を送信及び受信する機能をする。無線信号を受信すると、ＲＦモジュール１１３５は、プロセッサ１１１０によって処理するために信号を伝達し、ベースバンドに信号を変換することができる。処理された信号は、スピーカー１１４５を介して出力される可聴または可読情報に変換することができる。
【０６０９】
以上で説明した実施例は、本発明の構成要素と特徴が所定の形態で結合されたものである。各構成要素または特徴は、別の明示的な言及がない限り選択的なものを検討されるべきである。各構成要素または特徴は、他の構成要素や特徴と結合されない形態で実施されることができる。また、一部の構成要素及び/または特徴を結合して、本発明の実施例を構成することも可能である。本発明の実施例で説明される動作の順序は変更されることができる。どの実施例の一部の構成や特徴は、他の実施例に含まれることができ、または他の実施形態に対応する構成または特徴と交替されることができる。特許請求の範囲で明示的な引用関係がない請求項を結合して実施例を構成したり、出願後の補正により新しい請求項として含めることができることは自明である。
【０６１０】
本発明に係る実施例は、様々な手段、例えば、ハードウェア、ファームウェア（firmware）、ソフトウェアまたはそれらの組み合わせなどにより実現されることができる。ハードウェアによる実現の場合、本発明の一実施例は、一つまたはそれ以上のＡＳＩＣｓ（application specific integrated circuits）、ＤＳＰｓ（digital signal processors）、ＤＳＰＤｓ（digital signal processing devices）、ＰＬＤｓ（programmable logic devices）、ＦＰＧＡｓ（ field programmable gate arrays）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどにより実現されることができる。
【０６１１】
ファームウェアやソフトウェアによる実現の場合、本発明の一実施例は、以上で説明した機能または動作を実行するモジュール、プロシージャ、関数などの形態で実現されることができる。ソフトウェアコードは、メモリに貯蔵されてプロセッサによって駆動されることができる。前記メモリは、前記プロセッサの内部または外部に位置し、既に公知された多様な手段により、前記プロセッサとデータを送受信することができる。
【０６１２】
本発明は、本発明の必須の特徴を逸脱しない範囲で他の特定の形態で具体化されることができることは、通常の技術者にとって自明である。したがって、前述した詳細な説明は、すべての面で制限的に解釈してはならないし、例示的なものとみなされるべきである。本発明の範囲は、添付された請求項の合理的解釈によって決定されるべきで、本発明の等価的範囲内でのすべての変更は、本発明の範囲に含まれる。
【産業上の利用可能性】
【０６１３】
本発明の無線通信システムにおいてビームを用いた信号送受信方法は、３ＧＰＰ ＬＴＥ/ＬＴＥ−Ａシステムで、５Ｇに適用される例を中心に説明したが、他にも様々な無線通信システムに適用することが可能である。
【図１】
2020523938.tif 000056
【図２】
2020523938.tif 000057
【図３】
2020523938.tif 000058
【図４】
2020523938.tif 000059
【図５（ａ）】
2020523938.tif 000060
【図５（ｂ）】
2020523938.tif 000061
【図６】
2020523938.tif 000062
【図７】
2020523938.tif 000063
【図８】
2020523938.tif 000064
【図９】
2020523938.tif 000065
【図１０】
2020523938.tif 000066
【図１１】
2020523938.tif 000067
【手続補正書】
【提出日】令和2年1月30日(2020.1.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線通信システムにおいてビーム失敗の回復（beam failure recovery）を端末が実行する方法であって、
前記ビーム失敗の回復に関する資源設定（resource configuration）を基地局から受信するステップと、
ビーム測定（beam measurement）に使用される基準信号（reference signal：ＲＳ）を前記基地局から受信するステップと、
前記基準信号に対するビーム失敗イベント（beam failure event）が検出された時、前記資源設定に基づいて、第１資源を用いてビーム失敗の回復要請（beam failure recovery request）を前記基地局に伝送するステップとを含み、
前記第１資源は、ＰＲＡＣＨ（Physical Random Access Channel）である、方法。
【請求項２】
前記第１資源は、非‐競合ベース（non-contention based）ＰＲＡＣＨである、請求項１に記載の方法。
【請求項３】
前記端末が前記ビーム失敗の回復要請に対する応答を前記基地局から受信していない時、前記ビーム失敗の回復要請を第２資源を用いて再伝送するステップをさらに含む、請求項２に記載の方法。
【請求項４】
前記第２資源は、競合ベースの（contention based）ＰＲＡＣＨである、請求項３に記載の方法。
【請求項５】
前記第１資源において、前記ビーム失敗の回復要請が他のＰＵＣＣＨフォーマット（format）と重畳する時、前記他のＰＵＣＣＨ formatをドロップ（drop）する、請求項１に記載の方法。
【請求項６】
無線通信システムにおいてビーム失敗の回復（beam failure recovery）を実行するための端末であって、
無線信号を送受信するためのＲＦモジュール（radio frequency module）と、
前記ＲＦモジュールと機能的に接続されるプロセッサを含み、
前記プロセッサは、
前記ビーム失敗の回復（beam failure recovery）に関連した資源設定を基地局から受信し、
ビーム測定（beam measurement）に使用される基準信号（ reference signal：ＲＳ）を前記基地局から受信し、
前記ＲＳに対するビーム失敗イベント（beam failure event）が検出された時、前記資源設定に基づいて、第１資源を用いてビーム失敗の回復要請（beam failure recovery request）を前記基地局に伝送しするように設定され、
前記第１資源は、ＰＲＡＣＨ（Physical Random Access Channelである、端末。
【請求項７】
前記第１資源は、非‐競合ベース（non-contention based）ＰＲＡＣＨである、請求項６に記載の端末。
【請求項８】
前記プロセッサは、
前記端末が前記ビーム失敗の回復要請に対する応答を前記基地局から受信していない時、前記ビーム失敗の回復要請を第２資源を用いて再伝送するようにさらに設定された、請求項７に記載の端末。
【請求項９】
前記第２資源は、競合ベースの（contention based）ＰＲＡＣＨである、請求項８に記載の端末。
【請求項１０】
前記第１資源において、前記ビーム失敗の回復要請が他のＰＵＣＣＨフォーマット（format）と重畳する時、前記他のＰＵＣＣＨ formatをドロップする、請求項６に記載の端末。
【国際調査報告】
2020523938.tif 000068
2020523938.tif 000069