(57)【要約】本明細書は、無線通信システムにおいてビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う方法を提供する。本明細書において、端末により行われるビーム失敗復旧方法は、ビーム失敗を検出するステップと、前記ビーム失敗復旧のための新しいビームを識別するステップと、ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソースを用いて基地局に送信するステップと、を含み、前記ＰＲＡＣＨリソースは、前記１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、前記１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ  Ｂｌｏｃｋ）と関連し、前記ＳＳＢが前記新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを使用して送信され、ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースが前記新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用して送信されることを特徴とする。【選択図】図１７
2021503261.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システムにおいてビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う方法であって、端末により行われる方法は、
ビーム失敗を検出するステップと、
前記ビーム失敗復旧のための新しいビーム（ｎｅｗ  ｂｅａｍ）を識別するステップと、
ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソースを利用して基地局に送信するステップと、を含み、
前記ＰＲＡＣＨリソースは、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、
前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ  Ｂｌｏｃｋ）と関連し、
前記ＳＳＢが前記新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを使用して送信され、ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースが前記新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用して送信されることを特徴とする方法。
【請求項２】
前記ＣＳＩ−ＲＳリソースは、前記ＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）されていることを特徴とする請求項１に記載の方法。
【請求項３】
前記新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）であることを特徴とする請求項１に記載の方法。
【請求項４】
前記ＳＳＢ及び前記ＣＳＩ−ＲＳリソースが両方とも前記予め定義された条件を満たす場合、前記ＣＳＩ−ＲＳリソースが前記新しいビームとして識別されることを特徴とする請求項３に記載の方法。
【請求項５】
無線通信システムにおいてビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う方法であって、基地局により行われる方法は、
前記ビーム失敗復旧のための新しいビーム識別に関する情報を端末に送信するステップと、
ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソース（ｒｅｓｏｕｒｃｅ）を利用して端末から受信するステップと、を含み、
前記ＰＲＡＣＨリソースは、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、
前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ  Ｂｌｏｃｋ）と関連し、
前記新しいビームが前記ＳＳＢである場合、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを使用し、前記新しいビームがＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースである場合、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用することを特徴とする方法。
【請求項６】
前記ＣＳＩ−ＲＳリソースは前記ＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）されていることを特徴とする請求項５に記載の方法。
【請求項７】
前記新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）であることを特徴とする請求項５に記載の方法。
【請求項８】
前記ＳＳＢ及び前記ＣＳＩ−ＲＳリソースが両方とも前記予め定義された条件を満たす場合、前記ＣＳＩ−ＲＳリソースが前記端末により前記新しいビームとして識別されることを特徴とする請求項７に記載の方法。
【請求項９】
無線通信システムにおいてビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う端末であって、
無線信号を送受信するためのＲＦモジュール（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ  ｍｏｄｕｌｅ）と、
前記ＲＦモジュールと機能的に接続されているプロセッサと、を含み、
前記プロセッサは、
ビーム失敗を検出し、前記ビーム失敗復旧のための新しいビーム（ｎｅｗ  ｂｅａｍ）を識別し、ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソース（ｒｅｓｏｕｒｃｅ）を利用して基地局に送信し、
前記ＰＲＡＣＨリソースは、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、
前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ  Ｂｌｏｃｋ）と関連し、
前記ＳＳＢが前記新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを使用して送信され、ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースが前記新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用して送信されることを特徴とする端末。
【請求項１０】
前記ＣＳＩ−ＲＳリソースはＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）されていることを特徴とする請求項９に記載の端末。
【請求項１１】
前記新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）であることを特徴とする端末。
【請求項１２】
前記ＳＳＢ及び前記ＣＳＩ−ＲＳリソースが全て前記予め定義された条件を満たす場合、前記ＣＳＩ−ＲＳリソースが前記新しいビームとして識別されることを特徴とする請求項１１に記載の端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムに関し、より詳細に、ビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う方法及びそれをサポートする装置に関する。
【背景技術】
【０００２】
移動通信システムは、ユーザの活動性を保障しながら音声サービスを提供するために開発された。しかしながら、移動通信システムは、音声だけでなくデータサービスまで領域を拡張し、現在では、爆発的なトラフィックの増加によってリソースの不足現象が引き起こされ、ユーザがより高速のサービスを要求するので、より発展した移動通信システムが要求されている。
【０００３】
次世代の移動通信システムの要求条件は大きく、爆発的なデータトラフィックの収容、ユーザ当たりの送信率の画期的な増加、大幅増加した連結デバイス数の収容、非常に低い端対端遅延（Ｅｎｄ−ｔｏ−Ｅｎｄ  Ｌａｔｅｎｃｙ）、高エネルギー効率をサポートできなければならない。そのために、二重連結性（Ｄｕａｌ  Ｃｏｎｎｅｃｔｉｖｉｔｙ）、大規模多重入出力（Ｍａｓｓｉｖｅ  ＭＩＭＯ：Ｍａｓｓｉｖｅ  Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）、全二重（Ｉｎ-ｂａｎｄ  Ｆｕｌｌ  Ｄｕｐｌｅｘ）、非直交多重接続（ＮＯＭＡ：Ｎｏｎ-Ｏｒｔｈｏｇｏｎａｌ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）、超広帯域（Ｓｕｐｅｒ  ｗｉｄｅｂａｎｄ）サポート、端末ネットワーキング（Ｄｅｖｉｃｅ  Ｎｅｔｗｏｒｋｉｎｇ）など、多様な技術が研究されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本明細書は、ＳＳＢ（ＳＳ  Ｂｌｏｃｋ）に２つのＰＲＡＣＨリソースを関連させて新しいビームに対する曖昧性を解消できる方法を提供することに目的がある。
【０００５】
また、本明細書は、ＳＳＢと、ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ）が両方とも臨界値以上の品質を有する場合、優先順位を設定してビーム使用効率を高める方法を提供することに目的がある。
【０００６】
本発明で解決しようとする技術的課題は、以上で言及した技術的課題に制限されず、言及しないまた別の技術的課題は、以下の記載から本発明が属する技術分野で通常の知識を有する者にとって明確に理解されるべきである。
【課題を解決するための手段】
【０００７】
本明細書は、無線通信システムにおいてビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う方法を提供する。端末により行われる方法は、ビーム失敗を検出するステップと、前記ビーム失敗復旧のための新しいビーム（ｎｅｗ  ｂｅａｍ）を識別するステップと、ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソースを利用して基地局に送信するステップと、を含み、前記ＰＲＡＣＨリソースは第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ  Ｂｌｏｃｋ）と関連し、前記ＳＳＢが新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを使用して送信され、ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースが前記新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用して送信されることを特徴とする。
【０００８】
また、本明細書において、前記ＣＳＩ−ＲＳリソースは前記ＳＳＢと空間的にＱＣＬ（ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）されていることを特徴とする。
【０００９】
また、本明細書において、前記新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）であることを特徴とする。
【００１０】
また、本明細書において、前記ＳＳＢ及び前記ＣＳＩ−ＲＳリソースが両方とも前記予め定義された条件を満たす場合、前記ＣＳＩ−ＲＳリソースが前記新しいビームとして識別されることを特徴とする。
【００１１】
また、本明細書において、無線通信システムにおいてビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う方法であって、基地局により行われる方法は、前記ビーム失敗復旧のための新しいビーム識別に関する情報を端末に送信するステップと、ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソースを利用して端末から受信するステップと、を含み、前記ＰＲＡＣＨリソースは第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ  Ｂｌｏｃｋ）と関連し、前記新しいビームが前記ＳＳＢである場合、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを使用し、前記新しいビームがＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースである場合、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用することを特徴とする。
【００１２】
また、本明細書において、前記ＣＳＩ−ＲＳリソースは前記ＳＳＢと空間的にＱＣＬ（ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）されていることを特徴とする。
【００１３】
また、本明細書において、前記新しいビームは予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）であることを特徴とする。
【００１４】
また、本明細書において、前記ＳＳＢ及び前記ＣＳＩ−ＲＳリソースが両方とも前記予め定義された条件を満たす場合、前記ＣＳＩ−ＲＳリソースが前記端末により前記新しいビームとして識別されることを特徴とする。
【００１５】
また、本明細書において、無線通信システムにおいてビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う端末は、無線信号を送受信するためのＲＦモジュール（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ  ｍｏｄｕｌｅ）と、前記ＲＦモジュールと機能的に接続されているプロセッサと、を含み、前記プロセッサは、ビーム失敗を検出し、前記ビーム失敗復旧のための新しいビーム（ｎｅｗ  ｂｅａｍ）を識別し、ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソース（ｒｅｓｏｕｒｃｅ）を利用して基地局に送信し、前記ＰＲＡＣＨリソースは第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ  Ｂｌｏｃｋ）と関連し、前記ＳＳＢが新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを使用して送信され、ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースが前記新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用して送信されることを特徴とする。
【００１６】
また、本明細書において、前記ＣＳＩ−ＲＳリソースはＳＳＢと空間的にＱＣＬ（ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）されていることを特徴とする。
【００１７】
また、本明細書において、前記新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）であることを特徴とする。
【００１８】
また、本明細書において、前記ＳＳＢ及び前記ＣＳＩ−ＲＳリソースが両方とも前記予め定義された条件を満たす場合、前記ＣＳＩ−ＲＳリソースが前記新しいビームとして識別されることを特徴とする。
【発明の効果】
【００１９】
本明細書は、ＳＳＢ（ＳＳ  Ｂｌｏｃｋ）に２つのＰＲＡＣＨリソース（Ｒｅｓｏｕｒｃｅ）を関連させて新しいビームに対する曖昧性を解消することができる。
【００２０】
また、本明細書は、ＳＳＢと、ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ）が両方とも臨界値以上の品質を有する場合、優先順位を設定してビームの使用効率を高めることができる。
【００２１】
本発明で得ることができる効果は、以上で言及した効果に制限されるものではなく、言及していないまた別の効果は、以下の記載から本発明が属する技術分野で通常の知識を有する者にとって明確に理解されるべきである。
【図面の簡単な説明】
【００２２】
本発明に関する理解を助けるために詳細な説明の一部に含まれる添付図は、本発明に対する実施形態を提供し、詳細な説明と共に本発明の技術的特徴を説明する。
【００２３】
【図１】本明細書で提案する方法が適用できるＮＲの全体的なシステム構造の一例を示した図である。
【図２】本明細書で提案する方法が適用できる無線通信システムにおけるアップリンクフレームとダウンリンクフレームとの間の関係を示す。
【図３】本明細書で提案する方法が適用できる無線通信システムでサポートするリソースグリッド（ｒｅｓｏｕｒｃｅ  ｇｒｉｄ）の一例を示す。
【図４】本明細書で提案する方法が適用できるアンテナポート及びヌメロロジー別リソースグリッドの例を示す。
【図５】アナログビームフォーマ（ａｎａｌｏｇ  ｂｅａｍｆｏｒｍｅｒ）及びＲＦチェーン（ＲＦ  ｃｈａｉｎ）で構成される送信端（ｔｒａｎｓｍｉｔｔｅｒ）のブロック図（ｂｌｏｃｋ  ｄｉａｇｒａｍ）の一例を示す。
【図６】デジタルビームフォーマ（ｄｉｇｉｔａｌ  ｂｅａｍｆｏｒｍｅｒ）及びＲＦチェーンで構成される送信端のブロック図の一例を示す。
【図７】アナログビームスキャニング方式の一例を示す。
【図８】ＰＵＳＣＨ  ＣＳＩ報告モードの一例を示した図である。
【図９】ＰＵＣＣＨ  ＣＳＩ報告モードの一例を示した図である。
【図１０】代替ビームの存在有無によるネットワーク動作の一例を示す。
【図１１】ビーム関連の設定方法の一例を示した図である。
【図１２】ビーム復旧を行う方法の一例を示したフローチャートである。
【図１３】ビーム復旧を行う端末の動作の一例を示したフローチャートである。
【図１４】ビーム復旧を行う端末の動作のまた別の一例を示したフローチャートである。
【図１５】ビーム失敗復旧手続の一例を示したフローチャートである。
【図１６】本明細書で提案する方法に適用できるＣＳＩ−ＲＳ及びＳＳブロックの空間カバレッジ（ｓｐａｔｉａｌ  ｃｏｖｅｒａｇｅ）の一例を示した図である。
【図１７】本明細書で提案するビーム失敗復旧のための端末の動作方法の一例を示したフローチャートである。
【図１８】本明細書で提案するビーム失敗復旧のための基地局の動作方法の一例を示したフローチャートである。
【図１９】本発明の一実施形態に係る無線通信装置のブロック構成図を例示する。
【図２０】本発明の一実施形態に係る通信装置のブロック構成図を例示する。
【図２１】本明細書で提案する方法が適用できる無線通信装置のＲＦモジュールの一例を示した図である。
【図２２】本明細書で提案する方法が適用できる無線通信装置のＲＦモジュールのまた他の一例を示した図である。
【発明を実施するための形態】
【００２４】
以下、本発明に係る好ましい実施形態を添付した図面を参照して詳細に説明する。添付した図面と共に以下に開示される詳細な説明は、本発明の例示的な実施形態を説明しようとするものであり、本発明が実施できる唯一の実施形態を示そうとするものではない。以下の詳細な説明は、本発明の完全な理解を提供するために、具体的な細部事項を含む。しかしながら、当業者は、本発明がこのような具体的な細部事項がなくとも実施できるということが分かる。
【００２５】
幾つかの場合、本発明の概念が曖昧になることを避けるために公知の構造及び装置は省略されるか、または各構造及び装置の中核機能を中心としたブロック図の形式で示されることができる。
【００２６】
本明細書において、基地局は、端末と直接的に通信を行うネットワークの終端ノード（ｔｅｒｍｉｎａｌ  ｎｏｄｅ）としての意味を有する。本文書において基地局により行われると説明された特定の動作は、場合によっては、基地局の上位ノード（ｕｐｐｅｒ  ｎｏｄｅ）により行われてもよい。すなわち、基地局を含む複数のネットワークノード（ｎｅｔｗｏｒｋ  ｎｏｄｅｓ）からなるネットワークにおいて端末との通信のために行われる多様な動作は、基地局または基地局以外の他のネットワークノードにより行われ得ることは自明である。「基地局（ＢＳ：Ｂａｓｅ  Ｓｔａｔｉｏｎ）」は、固定局（ｆｉｘｅｄ  ｓｔａｔｉｏｎ）、Ｎｏｄｅ  Ｂ、ｅＮＢ（ｅｖｏｌｖｅｄ−ＮｏｄｅＢ）、ＢＴＳ（ｂａｓｅｔｒａｎｓｃｅｉｖｅｒ  ｓｙｓｔｅｍ）、アクセスポイント（ＡＰ：Ａｃｃｅｓｓ  Ｐｏｉｎｔ）、ｇＮＢ（ｇｅｎｅｒａｌ  ＮＢ）などの用語により代替され得る。また、「端末（Ｔｅｒｍｉｎａｌ）」は、固定されるか、または移動性を有することができ、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ）、ＵＴ（ｕｓｅｒ  ｔｅｒｍｉｎａｌ）、ＭＳＳ（Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｔａｔｉｏｎ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅｒ  Ｓｔａｔｉｏｎ）、ＡＭＳ（Ａｄｖａｎｃｅｄ  Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ）、ＷＴ（Ｗｉｒｅｌｅｓｓ  ｔｅｒｍｉｎａｌ）、ＭＴＣ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）装置、Ｍ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）装置、Ｄ２Ｄ（Ｄｅｖｉｃｅ−ｔｏ−Ｄｅｖｉｃｅ）装置などの用語に代替され得る。
【００２７】
以下で、ダウンリンク（ＤＬ：ｄｏｗｎｌｉｎｋ）は基地局から端末への通信を意味し、アップリンク（ＵＬ：ｕｐｌｉｎｋ）は端末から基地局への通信を意味する。ダウンリンクにおける送信機は基地局の一部であり、受信機は端末の一部であり得る。アップリンクにおける送信機は端末の一部であり、受信機は基地局の一部であり得る。
【００２８】
以下の説明で使われる特定用語は本発明の理解を助けるために提供されたものであり、このような特定用語の使用は本発明の技術的思想を外れない範囲で異なる形態に変更され得る。
【００２９】
以下の技術は、ＣＤＭＡ（ｃｏｄｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＴＤＭＡ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＳＣ-ＦＤＭＡ（ｓｉｎｇｌｅ  ｃａｒｒｉｅｒ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＮＯＭＡ（ｎｏｎ-ｏｒｔｈｏｇｏｎａｌｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）などの多様な無線アクセスシステムに利用できる。ＣＤＭＡは、ＵＴＲＡ（ｕｎｉｖｅｒｓａｌ  ｔｅｒｒｅｓｔｒｉａｌ  ｒａｄｉｏ  ａｃｃｅｓｓ）やＣＤＭＡ２０００のような無線技術（ｒａｄｉｏ  ｔｅｃｈｎｏｌｏｇｙ）で具現できる。ＴＤＭＡは、ＧＳＭ（ｇｌｏｂａｌ  ｓｙｓｔｅｍ  ｆｏｒ  ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）／ＧＰＲＳ（ｇｅｎｅｒａｌ  ｐａｃｋｅｔ  ｒａｄｉｏ  ｓｅｒｖｉｃｅ）／ＥＤＧＥ（ｅｎｈａｎｃｅｄ  ｄａｔａ  ｒａｔｅｓ  ｆｏｒ  ＧＳＭ  ｅｖｏｌｕｔｉｏｎ）のような無線技術で具現できる。ＯＦＤＭＡは、ＩＥＥＥ  ８０２．１１（ＷｉＦｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２−２０、Ｅ-ＵＴＲＡ（ｅｖｏｌｖｅｄ  ＵＴＲＡ）などの無線技術で具現できる。ＵＴＲＡは、ＵＭＴＳ（ｕｎｉｖｅｒｓａｌ  ｍｏｂｉｌｅ  ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ｓｙｓｔｅｍ）の一部である。３ＧＰＰ（３ｒｄ  ｇｅｎｅｒａｔｉｏｎ  ｐａｒｔｎｅｒｓｈｉｐ  ｐｒｏｊｅｃｔ）ＬＴＥ（ｌｏｎｇ  ｔｅｒｍ  ｅｖｏｌｕｔｉｏｎ）は、Ｅ-ＵＴＲＡを使用するＥ−ＵＭＴＳ（ｅｖｏｌｖｅｄ  ＵＭＴＳ）の一部であって、ダウンリンクでＯＦＤＭＡを採用し、アップリンクでＳＣ−ＦＤＭＡを採用する。ＬＴＥ−Ａ（ａｄｖａｎｃｅｄ）は３ＧＰＰ  ＬＴＥの進化である。
【００３０】
５Ｇ  ＮＲ（ｎｅｗ  ｒａｄｉｏ）はｕｓａｇｅ  ｓｃｅｎａｒｉｏに従って、ｅＭＢＢ（ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）、ｍＭＴＣ（ｍａｓｓｉｖｅ  Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＵＲＬＬＣ（Ｕｌｔｒａ−Ｒｅｌｉａｂｌｅ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、Ｖ２Ｘ（ｖｅｈｉｃｌｅ−ｔｏ−ｅｖｅｒｙｔｈｉｎｇ）定義する。
【００３１】
そして、５Ｇ  ＮＲ規格（ｓｔａｎｄａｒｄ）は、ＮＲシステムとＬＴＥシステムとの間の共存（ｃｏ−ｅｘｉｓｔｅｎｃｅ）によってＳＡ（ｓｔａｎｄａｌｏｎｅ：ＳＡ）とＮＳＡ（ｎｏｎ−ｓｔａｎｄａｌｏｎｅ）に区分する。
【００３２】
そして、５Ｇ  ＮＲは、様々なサブキャリア間隔（Ｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇ）をサポートし、ダウンリンクにおいてＣＰ−ＯＦＤＭを、アップリンクにおいてＣＰ−ＯＦＤＭ及びＤＦＴ−ｓ−ＯＦＤＭ（ＳＣ−ＯＦＤＭ）をサポートする。
【００３３】
本発明の実施形態は、無線アクセスシステムであるＩＥＥＥ  ８０２、３ＧＰＰ及び３ＧＰＰ２の少なくとも１つに開示された標準文書によって裏付けられることができる。即ち、本発明の実施形態のうち、本発明の技術的思想を明確に示すために、説明しない段階又は部分は前記文書によって裏付けられることができる。また、本文書で開示している全ての用語は、前記標準文書によって説明されることができる。
【００３４】
説明を明確にするために、３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａ／ＮＲ（Ｎｅｗ  Ｒａｄｉｏ）を中心に記述するが、本発明の技術的特徴がこれに制限されるわけではない。
【００３５】
用語の定義
【００３６】
ｅＬＴＥ  ｅＮＢ：ｅＬＴＥ  ｅＮＢは、ＥＰＣ及びＮＧＣに対する連結をサポートするｅＮＢの進化（ｅｖｏｌｕｔｉｏｎ）である。
【００３７】
ｇＮＢ：ＮＧＣとの連結だけでなく、ＮＲをサポートするノード。
【００３８】
新しいＲＡＮ：ＮＲ又はＥ−ＵＴＲＡをサポートするか、ＮＧＣと相互作用する無線アクセスネットワーク。
【００３９】
ネットワークスライス（ｎｅｔｗｏｒｋ  ｓｌｉｃｅ）：ネットワークスライスは、終端間の範囲と共に特定の要求事項を要求する特定の市場シナリオに対して最適化されたソリューションを提供するようにオペレータによって定義されたネットワーク。
【００４０】
ネットワーク機能（ｎｅｔｗｏｒｋ  ｆｕｎｃｔｉｏｎ）：ネットワーク機能は、よく定義された外部のインターフェースと、よく定義された機能的動作を有するネットワークインフラ内での論理的ノード。
【００４１】
ＮＧ−Ｃ：新しいＲＡＮとＮＧＣ間のＮＧ２リファレンスポイント（ｒｅｆｅｒｅｎｃｅ  ｐｏｉｎｔ）に使用されるコントロールプレーンインターフェース。
【００４２】
ＮＧ−Ｕ：新しいＲＡＮとＮＧＣ間のＮＧ３リファレンスポイント（ｒｅｆｅｒｅｎｃｅ  ｐｏｉｎｔ）に使用されるユーザプレーンインターフェース。
【００４３】
非独立型（Ｎｏｎ−ｓｔａｎｄａｌｏｎｅ）ＮＲ：ｇＮＢがＬＴＥ  ｅＮＢをＥＰＣにコントロールプレーンの連結のためのアンカーとして要求するか、又はｅＬＴＥ  ｅＮＢをＮＧＣにコントロールプレーンの連結のためのアンカーとして要求する配置構成。
【００４４】
非独立型Ｅ−ＵＴＲＡ：ｅＬＴＥ  ｅＮＢがＮＧＣにコントロールプレーンの連結のためのアンカーとしてｇＮＢを要求する配置構成。
【００４５】
ユーザプレーンゲートウェイ：ＮＧ−Ｕインターフェースの終端点。
【００４６】
システム一般
【００４７】
図１は、本明細書で提案する方法が適用できるＮＲの全体的なシステム構造の一例を示した図である。
【００４８】
図１を参照すると、ＮＧ-ＲＡＮはＮＧ-ＲＡユーザプレーン（新しいＡＳ  ｓｕｂｌａｙｅｒ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）及びＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）に対するコントロールプレーン（ＲＲＣ）プロトコル終端を提供するｇＮＢで構成される。
【００４９】
前記ｇＮＢは、Ｘｎインターフェースを介して相互連結される。
【００５０】
前記ｇＮＢは、また、ＮＧインターフェースを介してＮＧＣに連結される。
【００５１】
より具体的には、前記ｇＮＢはＮ２インターフェースを介してＡＭＦ（Ａｃｃｅｓｓ  ａｎｄ  Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｆｕｎｃｔｉｏｎ）に、Ｎ３インターフェースを介してＵＰＦ（Ｕｓｅｒ  Ｐｌａｎｅ  Ｆｕｎｃｔｉｏｎ）に連結される。
【００５２】
ＮＲ（Ｎｅｗ  Ｒａｔ）ヌメロロジー（Ｎｕｍｅｒｏｌｏｇｙ）及びフレーム（ｆｒａｍｅ）構造
【００５３】
ＮＲシステムでは、多数のヌメロロジー（ｎｕｍｅｒｏｌｏｇｙ）がサポートできる。ここで、ヌメロロジーはサブキャリア間隔（ｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇ）とＣＰ（Ｃｙｃｌｉｃ  Ｐｒｅｆｉｘ）のオーバーヘッドにより定義されることができる。このとき、多数のサブキャリア間隔は基本サブキャリア間隔を整数Ｎ（または、μ）にスケーリング（ｓｃａｌｉｎｇ）することにより誘導できる。また、非常に高い搬送波周波数で非常に低いサブキャリア間隔を用いないと仮定されても、用いられるヌメロロジーは周波数帯域と独立に選択されることができる。
【００５４】
また、ＮＲシステムでは多数のヌメロロジーに従う多様なフレーム構造がサポートされることができる。
【００５５】
以下、ＮＲシステムで考慮されることができるＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）ヌメロロジー及びフレーム構造を見る。
【００５６】
ＮＲシステムでサポートされる多数のＯＦＤＭヌメロロジーは、表１のように定義されることができる。
【００５７】
【表１】
2021503261.tif 000003
【００５８】
ＮＲシステムにおけるフレーム構造（ｆｒａｍｅｓｔｒｕｃｔｕｒｅ）と関連して、時間領域の多様なフィールドのサイズは
2021503261.tif 000004
の時間単位の倍数で表現される。ここで、
2021503261.tif 000005
であり、
2021503261.tif 000006
である。ダウンリンク（ｄｏｗｎｌｉｎｋ）及びアップリンク（ｕｐｌｉｎｋ）送信は
2021503261.tif 000007
の区間を有する無線フレーム（ｒａｄｉｏ  ｆｒａｍｅ）で構成される。ここで、無線フレームは各々
2021503261.tif 000008
の区間を有する１０個のサブフレーム（ｓｕｂｆｒａｍｅ）で構成される。この場合、アップリンクに対する１セットのフレーム及びダウンリンクに対する１セットのフレームが存在することができる。
【００５９】
図２は、本明細書で提案する方法が適用できる無線通信システムにおけるアップリンクフレームとダウンリンクフレームとの間の関係を示す。
【００６０】
図２に示すように、端末（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ、ＵＥ）からのアップリンクフレーム番号ｉの送信は、該当端末での該当ダウンリンクフレームの開始より
2021503261.tif 000009
以前に開始しなければならない。
【００６１】
ヌメロロジーμに対して、スロット（ｓｌｏｔ）はサブフレーム内で
2021503261.tif 000010
の増加する順に番号が付けられて、無線フレーム内で
2021503261.tif 000011
の増加する順に番号が付けられる。１つのスロットは
2021503261.tif 000012
の連続するＯＦＤＭシンボルで構成され、
2021503261.tif 000013
は用いられるヌメロロジー及びスロット設定（ｓｌｏｔ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）によって決定される。サブフレームでスロット
2021503261.tif 000014
の開始は同じサブフレームでＯＦＤＭシンボル
2021503261.tif 000015
の開始と時間的に整列される。
【００６２】
全ての端末が同時に送信及び受信できるものではなく、これはダウンリンクスロット（ｄｏｗｎｌｉｎｋ  ｓｌｏｔ）又はアップリンクスロット（ｕｐｌｉｎｋ  ｓｌｏｔ）の全てのＯＦＤＭシンボルが用いられることはできないということを意味する。
【００６３】
表２はヌメロロジーμでの一般（ｎｏｒｍａｌ）ＣＰに対するスロット当たりのＯＦＤＭシンボルの数を示し、表３はヌメロロジーμでの拡張（ｅｘｔｅｎｄｅｄ）ＣＰに対するスロット当たりのＯＦＤＭシンボルの数を示す。
【００６４】
【表２】
2021503261.tif 000016
【００６５】
【表３】
2021503261.tif 000017
【００６６】
ＮＲ物理リソース（ＮＲ  Ｐｈｙｓｉｃａｌ  Ｒｅｓｏｕｒｃｅ）
【００６７】
ＮＲシステムにおける物理リソース（ｐｈｙｓｉｃａｌ  ｒｅｓｏｕｒｃｅ）と関連して、アンテナポート（ａｎｔｅｎｎａ  ｐｏｒｔ）、リソースグリッド（ｒｅｓｏｕｒｃｅ  ｇｒｉｄ）、リソース要素（ｒｅｓｏｕｒｃｅ  ｅｌｅｍｅｎｔ）、リソースブロック（ｒｅｓｏｕｒｃｅ  ｂｌｏｃｋ）、キャリアパート（ｃａｒｒｉｅｒ  ｐａｒｔ）などが考慮できる。
【００６８】
以下、ＮＲシステムで考慮できる前記物理リソースに対して具体的に見る。
【００６９】
まず、アンテナポートと関連して、アンテナポートはアンテナポート上のシンボルが運搬されるチャネルが同じアンテナポート上の他のシンボルが運搬されるチャネルから推論できるように定義される。１つのアンテナポート上のシンボルが運搬されるチャネルの広範囲特性（ｌａｒｇｅ-ｓｃａｌｅ  ｐｒｏｐｅｒｔｙ）が他のアンテナポート上のシンボルが運搬されるチャネルから類推できる場合、２つのアンテナポートはＱＣ／ＱＣＬ（ｑｕａｓｉｃｏ-ｌｏｃａｔｅｄまたはｑｕａｓｉ  ｃｏ-ｌｏｃａｔｉｏｎ）関係にあるということができる。ここで、前記広範囲特性は遅延拡散（Ｄｅｌａｙ  ｓｐｒｅａｄ）、ドップラー拡散（Ｄｏｐｐｌｅｒ  ｓｐｒｅａｄ）、周波数シフト（Ｆｒｅｑｕｅｎｃｙ  ｓｈｉｆｔ）、平均受信パワー（Ａｖｅｒａｇｅ  ｒｅｃｅｉｖｅｄ  ｐｏｗｅｒ）、受信タイミング（Ｒｅｃｅｉｖｅｄ  Ｔｉｍｉｎｇ）のうち、１つ以上を含む。
【００７０】
図３は、本明細書で提案する方法が適用できる無線通信システムでサポートするリソースグリッド（ｒｅｓｏｕｒｃｅ  ｇｒｉｄ）の一例を示す。
【００７１】
図３を参考すると、リソースグリッドが周波数領域上に
2021503261.tif 000018
サブキャリアで構成され、１つのサブフレームが１４・２μＯＦＤＭシンボルで構成されることを例示的に記述するが、これに限定されるものではない。
【００７２】
ＮＲシステムにおいて、送信される信号（ｔｒａｎｓｍｉｔｔｅｄ  ｓｉｇｎａｌ）は
2021503261.tif 000019
サブキャリアで構成される１つまたはそれ以上のリソースグリッド及び
2021503261.tif 000020
のＯＦＤＭシンボルにより説明される。ここで、
2021503261.tif 000021
である。前記
2021503261.tif 000022
は最大送信帯域幅を示し、これは、ヌメロロジーだけでなく、アップリンクとダウンリンクとの間でも変わり得る。
【００７３】
この場合、図４のように、ヌメロロジーμ及びアンテナポートｐ別に１つのリソースグリッドが設定できる。
【００７４】
図４は、本明細書で提案する方法が適用できるアンテナポート及びヌメロロジー別のリソースグリッドの例を示す。
【００７５】
ヌメロロジーμ及びアンテナポートｐに対するリソースグリッドの各要素はリソース要素（ｒｅｓｏｕｒｃｅ  ｅｌｅｍｅｎｔ）と称され、インデックス対
2021503261.tif 000023
により固有的に識別される。ここで、
2021503261.tif 000024
は周波数領域上のインデックスであり、
2021503261.tif 000025
はサブフレーム内でシンボルの位置を称する。スロットでリソース要素を称する時には、インデックス対
2021503261.tif 000026
が用いられる。ここで、
2021503261.tif 000027
である。
【００７６】
ヌメロロジーμ及びアンテナポートｐに対するリソース要素
2021503261.tif 000028
は複素値（ｃｏｍｐｌｅｘ  ｖａｌｕｅ）
2021503261.tif 000029
に該当する。混同（ｃｏｎｆｕｓｉｏｎ）する危険がない場合、または特定アンテナポートまたはヌメロロジーが特定されない場合には、インデックスｐ及びμはドロップ（ｄｒｏｐ）されることができ、その結果、複素値は
2021503261.tif 000030
または
2021503261.tif 000031
になることができる。
【００７７】
また、物理リソースブロック（ｐｈｙｓｉｃａｌ  ｒｅｓｏｕｒｃｅ  ｂｌｏｃｋ）は周波数領域上の
2021503261.tif 000032
の連続的なサブキャリアで定義される。周波数領域上で、物理リソースブロックは０から
2021503261.tif 000033
まで番号が付けられる。このとき、周波数領域上の物理リソースブロック番号（ｐｈｙｓｉｃａｌ  ｒｅｓｏｕｒｃｅ  ｂｌｏｃｋ  ｎｕｍｂｅｒ）
2021503261.tif 000034
とリソース要素
2021503261.tif 000035
との間の関係は、数式１のように与えられる。
【００７８】
【数１】
2021503261.tif 000036
【００７９】
また、キャリアパート（ｃａｒｒｉｅｒ  ｐａｒｔ）と関連して、端末はリソースグリッドのサブセット（ｓｕｂｓｅｔ）のみを用いて受信または送信するように設定されることができる。このとき、端末が受信又は送信するように設定されたリソースブロックの集合（ｓｅｔ）は周波数領域上で０から
2021503261.tif 000037
まで番号が付けられる。
【００８０】
アップリンク制御チャネル（Ｕｐｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）
【００８１】
物理アップリンク制御シグナリング（ｐｈｙｓｉｃａｌ  ｕｐｌｉｎｋ  ｃｏｎｔｒｏｌ  ｓｉｇｎａｌｉｎｇ）は、少なくともｈｙｂｒｉｄ−ＡＲＱ  ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＣＳＩ報告（ＣＳＩ  ｒｅｐｏｒｔ）（可能であれば、ビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）情報を含む）、及びスケジューリング要求（ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ）を運ぶことができなければならない。
【００８２】
ＮＲシステムでサポートするアップリンク制御チャネル（ＵＬ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）に対して少なくとも二つの送信方法がサポートされる。
【００８３】
アップリンク制御チャネルは、スロット（ｓｌｏｔ）の最後に送信されたアップリンクシンボルの周囲で短期間（ｓｈｏｒｔ  ｄｕｒａｔｉｏｎ）で送信されることができる。この場合、アップリンク制御チャネルはスロット内でアップリンクデータチャネル（ＵＬ  ｄａｔａ  ｃｈａｎｎｅｌ）と時間−分割−多重化（ｔｉｍｅ−ｄｉｖｉｓｉｏｎ−ｍｕｌｔｉｐｌｅｘｅｄ）及び／又は周波数−分割−多重化（ｆｒｅｑｕｅｎｃｙ−ｄｉｖｉｓｉｏｎ−ｍｕｌｔｉｐｌｅｘｅｄ）される。短期間のアップリンク制御チャネルに対して、スロットの１シンボル単位の送信がサポートされる。
【００８４】
−短いアップリンク制御情報（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ、ＵＣＩ）及びデータは、少なくとも短いＵＣＩ及びデータに対する物理リソースブロック（Ｐｈｙｓｉｃａｌ  Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ、ＰＲＢ）が重ならない場合、端末（ＵＥ）及び端末間で周波数−分割−多重化される。
【００８５】
−同じスロット内の異なる端末からの短いＰＵＣＣＨ（ｓｈｏｒｔ  ＰＵＣＣＨ）の時間分割多重化（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ、ＴＤＭ）をサポートするために、短いＰＵＣＣＨを送信するスロット内のシンボルが、少なくとも６ＧＨｚ以上でサポートされるか否かを端末に知らせるメカニズム（ｍｅｃｈａｎｉｓｍ）がサポートされる。
【００８６】
−１シンボル期間（１−ｓｙｍｂｏｌ  ｄｕｒａｔｉｏｎ）に対しては、少なくとも１）参照信号（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ、ＲＳ）が多重化されると、ＵＣＩとＲＳは周波数分割多重化（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ、ＦＤＭ）方式で与えられたＯＦＤＭシンボルに多重化される点、及び２）同じスロットでダウンリンク（ＤＬ）／アップリンク（ＵＬ）データと短期間のＰＵＣＣＨとの間のサブキャリア間隔（ｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇ）が同一である点がサポートされる。
【００８７】
−少なくとも、スロットの２シンボル期間（２−ｓｙｍｂｏｌ  ｄｕｒａｔｉｏｎ）にかけた短期間のＰＵＣＣＨがサポートされる。このとき、同じスロットでダウンリンク（ＤＬ）／アップリンク（ＵＬ）データと短期間のＰＵＣＣＨとの間のサブキャリア間隔が同一である。
【００８８】
−少なくとも、スロット内の与えられた端末のＰＵＣＣＨリソース、即ち、異なる端末の短いＰＵＣＣＨは、スロットで与えられた持続期間（ｄｕｒａｔｉｏｎ）内に時分割多重化されることができる半静的構成（ｓｅｍｉ−ｓｔａｔｉｃ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）がサポートされる。
【００８９】
−ＰＵＣＣＨリソースには、時間領域（ｔｉｍｅ  ｄｏｍａｉｎ）、周波数領域（ｆｒｅｑｕｅｎｃｙ  ｄｏｍａｉｎ）、及び適用可能な場合には、コード領域（ｃｏｄｅ  ｄｏｍａｉｎ）が含まれる。
【００９０】
−短期間のＰＵＣＣＨは、端末の観点から、スロットの端まで拡張されることができる。このとき、短期間のＰＵＣＣＨ以降、明示的なギャップシンボル（ｅｘｐｌｉｃｉｔ  ｇａｐ  ｓｙｍｂｏｌ）が不要である。
【００９１】
−短いアップリンク部分（ｓｈｏｒｔ  ＵＬ  ｐａｒｔ）を有するスロット（即ち、ＤＬ中心のスロット（ＤＬ−ｃｅｎｔｒｉｃ  ｓｌｏｔ））に対して、データが短いアップリンク部分でスケジューリング（ｓｃｈｅｄｕｌｉｎｇ）されると、「短いＵＣＩ」及びデータは、１つの端末によって周波数分割多重化されることができる。
【００９２】
アップリンク制御チャネルは、カバレッジ（ｃｏｖｅｒａｇｅ）を改善するために、多数のアップリンクシンボルにかけて長期間（ｌｏｎｇ−ｄｕｒａｔｉｏｎ）で送信されることができる。この場合、アップリンク制御チャネルは、スロット内のアップリンクデータチャネルと周波数分割多重化される。
【００９３】
−少なくともＰＡＰＲ（Ｐｅａｋ  ｔｏ  Ａｖｅｒａｇｅ  Ｐｏｗｅｒ  Ｒａｔｉｏ）が低い設計で長時間のアップリンク制御チャネル（ｌｏｎｇ  ｄｕｒａｔｉｏｎ  ＵＬ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）によって運ばれるＵＣＩは、１つのスロット又は多数のスロットで送信されることができる。
【００９４】
−多数のスロットを用いる送信は、少なくとも一部の場合に、総持続時間（ｔｏｔａｌ  ｄｕｒａｔｉｏｎ）（例：１ｍｓ）の間に許容される。
【００９５】
−長時間のアップリンク制御チャネルの場合、ＲＳとＵＣＩ間の時間分割多重化（ＴＤＭ）は、ＤＦＴ−Ｓ−ＯＦＤＭに対してサポートされる。
【００９６】
−スロットの長いアップリンク部分（ｌｏｎｇ  ＵＬ  ｐａｒｔ）は、長時間のＰＵＣＣＨ送信に用いられることができる。即ち、長時間のＰＵＣＣＨはアップリンク専用のスロット（ＵＬ−ｏｎｌｙ  ｓｌｏｔ）と最小４個のシンボルで構成される可変個数のシンボルを有するスロットの全てに対してサポートされる。
【００９７】
−少なくとも１又は２ビットのＵＣＩに対して、前記ＵＣＩはＮ個のスロット（Ｎ＞１）内で繰り返されてもよく、前記Ｎ個のスロットは長時間のＰＵＣＣＨが許容されるスロットで隣接してもよく、又は隣接しなくてもよい。
【００９８】
−少なくとも長いＰＵＣＣＨ（ｌｏｎｇ  ＰＵＣＣＨ）に対して、ＰＵＳＣＨとＰＵＣＣＨの同時送信（ｓｉｍｕｌｔａｎｅｏｕｓ  ｔｒａｎｓｍｉｓｓｉｏｎ）がサポートされる。即ち、データが存在する場合にも、ＰＵＣＣＨリソースに対するアップリンク制御が送信される。また、ＰＵＣＣＨ−ＰＵＳＣＨの同時送信以外にも、ＰＵＳＣＨでのＵＣＩがサポートされる。
【００９９】
−ＴＴＩ内でのスロット周波数ホッピング（ｉｎｔｒａ−ＴＴＩ  ｓｌｏｔ  ｆｒｅｑｕｅｎｃｙ  ｈｏｐｐｉｎｇ）がサポートされる。
【０１００】
−ＤＦＴ−ｓ−ＯＦＤＭの波形（ｗａｖｅｆｏｒｍ）がサポートされる。
【０１０１】
−送信アンテナダイバーシティ（ｔｒａｎｓｍｉｔ  ａｎｔｅｎｎａ  ｄｉｖｅｒｓｉｔｙ）がサポートされる。
【０１０２】
短期間のＰＵＣＣＨと長期間のＰＵＣＣＨとの間のＴＤＭ及びＦＤＭは、少なくとも１つのスロットで別の端末に対してサポートされる。周波数領域で、ＰＲＢ（又は多数のＰＲＢ）はアップリンク制御チャネルに対する最小リソース単位サイズ（ｍｉｎｉｍｕｍ  ｒｅｓｏｕｒｃｅ  ｕｎｉｔ  ｓｉｚｅ）である。ホッピング（ｈｏｐｐｉｎｇ）が用いられる場合、周波数リソース及びホッピングは、キャリア帯域幅（ｃａｒｒｉｅｒ  ｂａｎｄｗｉｄｔｈ）に拡散されないことがある。また、端末特定ＲＳは、ＮＲ−ＰＵＣＣＨ送信に用いられる。ＰＵＣＣＨリソースの集合（ｓｅｔ）は、上位層のシグナリング（ｈｉｇｈｅｒ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）によって設定され、設定された集合内のＰＵＣＣＨリソースは、ダウンリンク制御情報（Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ、ＤＣＩ）によって指示される。
【０１０３】
ＤＣＩの一部であって、データ受信（ｄａｔａ  ｒｅｃｅｐｔｉｏｎ）とｈｙｂｒｉｄ−ＡＲＱ  ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ送信間のタイミング（ｔｉｍｉｎｇ）は、ダイナミックに（ｄｙｎａｍｉｃａｌｌｙ）（少なくともＲＲＣと共に）指示できなければならない。半静的構成（ｓｅｍｉ−ｓｔａｔｉｃ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び（少なくとも一部類型のＵＣＩ情報に対する）ダイナミックなシグナリング（ｄｙｎａｍｉｃ  ｓｉｇｎａｌｉｎｇ）の結合は、「長い及び短いＰＵＣＣＨフォーマット」に対するＰＵＣＣＨリソースを決定するために用いられる。ここで、ＰＵＣＣＨリソースは、時間領域、周波数領域、及び適用可能な場合には、コード領域を含む。ＰＵＳＣＨ上のＵＣＩ、即ち、ＵＣＩに対するスケジュールされたリソースの一部を使用することはＵＣＩとデータの同時送信の場合にサポートされる。
【０１０４】
また、少なくとも単一のＨＡＲＱ−ＡＣＫビットのアップリンク送信が少なくともサポートされる。また、周波数ダイバーシティ（ｆｒｅｑｕｅｎｃｙ  ｄｉｖｅｒｓｉｔｙ）を可能にするメカニズムがサポートされる。また、ＵＲＬＬＣ（Ｕｌｔｒａ−Ｒｅｌｉａｂｌｅ  ａｎｄ  Ｌｏｗ−Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の場合、端末に対して設定されたスケジューリング要求（ＳＲ）リソース間の時間間隔（ｔｉｍｅ  ｉｎｔｅｒｖａｌ）は、１つのスロットよりも小さいことがある。
【０１０５】
ビーム管理（Ｂｅａｍ  ｍａｎａｇｅｍｅｎｔ）
【０１０６】
ＮＲにおけるビーム管理は次のように定義される。
【０１０７】
ビーム管理（Ｂｅａｍ  ｍａｎａｇｅｍｅｎｔ）：ＤＬ及びＵＬの送受信に使用されることができるＴＲＰ及び／又はＵＥビームのセット（ｓｅｔ）を取得して維持するためのＬ１／Ｌ２手続のセットであって、少なくとも次の事項を含む：
【０１０８】
−ビーム決定：ＴＲＰ又はＵＥが自身の送信／受信ビームを選択する動作。
【０１０９】
−ビーム測定：ＴＲＰ又はＵＥが受信されたビーム形成の信号の特性を測定する動作。
【０１１０】
−ビーム報告：ＵＥがビーム測定に基づいてビーム形成された信号の情報を報告する動作。
【０１１１】
−ビームスイーピング（Ｂｅａｍ  ｓｗｅｅｐｉｎｇ）：予め決定された方式で時間間隔の間に送信及び／又は受信されたビームを用いて空間領域をカバーする動作。
【０１１２】
また、ＴＲＰ及びＵＥにおけるＴｘ／Ｒｘビームの対応（ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ）は、次のように定義される。
【０１１３】
−ＴＲＰにおけるＴｘ／Ｒｘビームの対応は、次のうち少なくとも１つが満たされると維持される。
【０１１４】
−ＴＲＰは、ＴＲＰの１つ以上の送信ビームに対するＵＥのダウンリンクの測定に基づいて、アップリンク受信のためのＴＲＰ受信ビームを決定することができる。
【０１１５】
−ＴＲＰは、ＴＲＰの１つ以上のＲｘビームに対するＴＲＰのアップリンクの測定に基づいて、ダウンリンク送信に対するＴＲＰ  Ｔｘビームを決定することができる。
【０１１６】
−ＵＥにおけるＴｘ／Ｒｘビームの対応は、次のうち少なくとも１つが満たされると維持される。
【０１１７】
−ＵＥは、ＵＥの１つ以上のＲｘビームに対するＵＥのダウンリンクの測定に基づいて、アップリンク送信のためのＵＥ  Ｔｘビームを決定することができる。
【０１１８】
−ＵＥは、１つ以上のＴｘビームに対するアップリンクの測定に基づいたＴＲＰの指示に基づいて、ダウンリンク受信のためのＵＥ受信ビームを決定することができる。
【０１１９】
−ＴＲＰにＵＥビームの対応に関する情報の能力指示がサポートされる。
【０１２０】
次のようなＤＬにおけるＬ１／Ｌ２のビーム管理手続が、１つ又は多数のＴＲＰ内でサポートされる。
【０１２１】
Ｐ−１：ＴＲＰ  Ｔｘビーム／ＵＥ  Ｒｘビームの選択をサポートするために、異なるＴＲＰ  Ｔｘビームに対するＵＥの測定を可能にするために使用される。
【０１２２】
−ＴＲＰにおけるビームフォーミングの場合、一般に互いに異なるビームセットでイントラ（ｉｎｔｒａ）／インター（ｉｎｔｅｒ）−ＴＲＰ  Ｔｘビームスイープ（ｓｗｅｅｐ）を含む。ＵＥにおけるビームフォーミングのために、それは通常異なるビームのセットからのＵＥ  Ｒｘビームスイープを含む。
【０１２３】
Ｐ−２：異なるＴＲＰ  Ｔｘビームに対するＵＥの測定が、インター／イントラ−ＴＲＰ  Ｔｘビームを変更させるために使用される。
【０１２４】
Ｐ−３：ＵＥがビームフォーミングを使用する場合に、同じＴＲＰ  Ｔｘビームに対するＵＥの測定が、ＵＥ  Ｒｘビームを変更させるのに使用される。
【０１２５】
少なくともネットワークによってトリガーされた非周期的報告（ａｐｒｅｉｏｄｉｃ  ｒｅｐｏｒｔｉｎｇ）は、Ｐ−１、Ｐ−２、及びＰ−３に関する動作でサポートされる。
【０１２６】
ビーム管理（少なくともＣＳＩ−ＲＳ）のためのＲＳに基づいたＵＥの測定は、Ｋ（ビームの総数）ビームで構成され、ＵＥは、選択されたＮ個のＴｘビームの測定結果を報告する。ここで、Ｎは、必ずしも固定された数ではない。移動性の目的のためのＲＳに基づいた手続は排除されない。報告情報は、少なくともＮ＜Ｋである場合、Ｎ個のビームに対する測定量及びＮ個のＤＬ送信ビームを示す情報を含む。特に、ＵＥがＫ’＞１ノン−ゼロ−パワー（ＮＺＰ）ＣＳＩ−ＲＳリソースに対して、ＵＥは、Ｎ’のＣＲＩ（ＣＳＩ−ＲＳリソースの指示子）を報告することができる。
【０１２７】
ＵＥはビーム管理のために次のような上位層のパラメータ（ｈｉｇｈｅｒ  ｌａｙｅｒ  ｐａｒａｍｅｔｅｒ）に設定されることができる。
【０１２８】
−Ｎ≧１報告設定（ｓｅｔｔｉｎｇ）、Ｍ≧１リソース設定
【０１２９】
−報告設定とリソース設定間のリンクは、合意されたＣＳＩ測定設定で設定される。
【０１３０】
−ＣＳＩ−ＲＳベースのＰ−１及びＰ−２は、リソース及び報告設定でサポートされる。
【０１３１】
−Ｐ−３は、報告設定の有無に関係なくサポートされることができる。
【０１３２】
−少なくとも以下の事項を含む報告設定（ｒｅｐｏｒｔｉｎｇ  ｓｅｔｔｉｎｇ）
【０１３３】
−選択されたビームを示す情報
【０１３４】
−Ｌ１測定報告（Ｌ１  ｍｅａｓｕｒｅｍｅｎｔ  ｒｅｐｏｒｔｉｎｇ）
【０１３５】
−時間領域動作（例：非周期的（ａｐｅｒｉｏｄｉｃ）動作、周期的（ｐｅｒｉｏｄｉｃ）動作、半持続的（ｓｅｍｉ−ｐｅｒｓｉｓｔｅｎｔ）動作）
【０１３６】
−色々な周波数細分性（ｆｒｅｑｕｅｎｃｙ  ｇｒａｎｕｌａｒｉｔｙ）がサポートされる場合の周波数細分性
【０１３７】
−少なくとも以下の事項を含むリソース設定（ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）
【０１３８】
−時間領域動作（例：非周期的動作、周期的動作、半持続的動作）
【０１３９】
−ＲＳ類型：少なくともＮＺＰ  ＣＳＩ−ＲＳ
【０１４０】
−少なくとも１つのＣＳＩ−ＲＳリソースのセット。各ＣＳＩ−ＲＳリソースのセットは、Ｋ≧１  ＣＳＩ−ＲＳリソースを含む（Ｋ個のＣＳＩ−ＲＳリソースの一部パラメータは同一であってもよい。例えば、ポートの番号、時間領域動作、密度、及び周期）
【０１４１】
また、ＮＲは、Ｌ＞１であるＬグループを考慮し、次のビーム報告をサポートする。
【０１４２】
−最小限のグループを示す情報
【０１４３】
−Ｎ１ビームに対する測定量（ｍｅａｓｕｒｅｍｅｎｔ  ｑｕａｎｔｉｔｙ）（Ｌ１  ＲＳＲＰ及びＣＳＩ報告サポート（ＣＳＩ−ＲＳがＣＳＩ取得のための場合））
【０１４４】
−適用可能な場合、Ｎ１個のＤＬ送信ビームを示す情報
【０１４５】
前述したようなグループベースのビーム報告は、ＵＥ単位で構成することができる。また、前記グループベースのビーム報告は、ＵＥ単位でターンオフ（ｔｕｒｎ−ｏｆｆ）されることができる（例えば、Ｌ＝１又はＮｌ＝１である場合）。
【０１４６】
ＮＲは、ＵＥがビーム失敗から復旧するメカニズムをトリガーすることができることをサポートする。
【０１４７】
ビーム失敗（ｂｅａｍ  ｆａｉｌｕｒｅ）のイベントは、関連した制御チャネルのビーム対リンク（ｂｅａｍ  ｐａｉｒ  ｌｉｎｋ）の品質が充分に低いときに発生する（例えば、臨界値との比較、関連したタイマーのタイムアウト）。ビーム失敗（又は障害）から復旧するメカニズムは、ビーム障害が発生するときにトリガーされる。
【０１４８】
ネットワークは、復旧の目的でＵＬ信号を送信するためのリソースを有するＵＥに明示的に構成する。リソースの構成は、基地局が全体又は一部方向から（例えば、ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｒｅｇｉｏｎ）聴取（ｌｉｓｔｅｎｉｎｇ）するところでサポートされる。
【０１４９】
ビーム障害を報告するＵＬ送信／リソースは、ＰＲＡＣＨ（ＰＲＡＣＨリソースに直交するリソース）と同一の時間インスタンス（ｉｎｓｔａｎｃｅ）に、又はＰＲＡＣＨと異なる時間インスタンス（ＵＥに対して構成可能）に位置し得る。ＤＬ信号の送信は、ＵＥが新しい潜在的なビームを識別するためにビームをモニターすることができるようにサポートされる。
【０１５０】
ＮＲは、ビーム関連の指示（ｂｅａｍ−ｒｅｌａｔｅｄ  ｉｎｄｉｃａｔｉｏｎ）に関係なく、ビーム管理をサポートする。ビーム関連の指示が提供される場合、ＣＳＩ−ＲＳベースの測定のために使用されたＵＥ側のビーム形成／受信手続に関する情報は、ＱＣＬを介してＵＥに指示されることができる。ＮＲでサポートするＱＣＬパラメータとしては、ＬＴＥシステムで使用していた遅延（ｄｅｌａｙ）、ドップラー（Ｄｏｐｐｌｅｒ）、平均利得（ａｖｅｒａｇｅ  ｇａｉｎ）等に対するパラメータだけでなく、受信端におけるビームフォーミングのための空間パラメータが追加される予定であり、端末の受信ビームフォーミングの観点から、到達角（ａｎｇｌｅ  ｏｆ  ａｒｒｉｖａｌ）関連のパラメータ及び／又は基地局の受信ビームフォーミングの観点から、発信角（ａｎｇｌｅ  ｏｆ  ｄｅｐａｒｔｕｒｅ）関連のパラメータが含まれることができる。ＮＲは制御チャネル及び該当データチャネルの送信で同一であるか異なるビームを使用することをサポートする。
【０１５１】
ビーム対リンクブロッキング（ｂｅａｍ  ｐａｉｒ  ｌｉｎｋ  ｂｌｏｃｋｉｎｇ）に対する堅固性（ｒｏｂｕｓｔｎｅｓｓ）をサポートするＮＲ−ＰＤＣＣＨ送信のために、ＵＥは、同時にＭ個のビーム対リンク上でＮＲ−ＰＤＣＣＨをモニターするように構成されることができる。ここで、Ｍ≧１及びＭの最大値は、少なくともＵＥの能力に依存し得る。
【０１５２】
ＵＥは、異なるＮＲ−ＰＤＣＣＨ  ＯＦＤＭシンボルで異なるビーム対リンク上のＮＲ−ＰＤＣＣＨをモニターするように構成されることができる。多数のビーム対リンク上でＮＲ−ＰＤＣＣＨをモニターするためのＵＥ  Ｒｘビームの設定に関するパラメータは、上位層のシグナリング又はＭＡＣ  ＣＥによって構成されるか、及び／又は探索空間の設計で考慮される。
【０１５３】
少なくとも、ＮＲはＤＬ  ＲＳアンテナポートとＤＬ制御チャネルの復調のためのＤＬ  ＲＳアンテナポート間の空間のＱＣＬ仮定の指示をサポートする。ＮＲ−ＰＤＣＣＨ（即ち、ＮＲ−ＰＤＣＣＨをモニターする構成方法）に対するビーム指示のための候補のシグナリング方法は、ＭＡＣ  ＣＥシグナリング、ＲＲＣシグナリング、ＤＣＩシグナリング、スペックトランスペアレント及び／又は暗示的方法、及びこれらのシグナリング方法の組み合わせである。
【０１５４】
ユニキャストのＤＬデータチャネルの受信のために、ＮＲはＤＬ  ＲＳアンテナポートとＤＬデータチャネルのＤＭＲＳアンテナポート間の空間ＱＣＬ仮定の指示をサポートする。
【０１５５】
ＲＳアンテナポートを示す情報は、ＤＣＩ（ダウンリンクの許可）を介して表される。また、この情報は、ＤＭＲＳアンテナポートとＱＣＬされているＲＳアンテナポートを示す。ＤＬデータチャネルに対するＤＭＲＳアンテナポートの異なるセットは、ＲＳアンテナポートの別のセットとＱＣＬとして示し得る。
【０１５６】
ハイブリッドビームフォーミング（Ｈｙｂｒｉｄ  ｂｅａｍｆｏｒｍｉｎｇ）
【０１５７】
多重アンテナ（ｍｕｌｔｉｐｌｅ  ａｎｔｅｎｎａ）を利用する既存のビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）技術は、ビームフォーミングの加重値ベクトル（ｗｅｉｇｈｔ  ｖｅｃｔｏｒ）／プリコーディングベクトル（ｐｒｅｃｏｄｉｎｇ  ｖｅｃｔｏｒ）を適用する位置に応じて、アナログビームフォーミング（ａｎａｌｏｇ  ｂｅａｍｆｏｒｍｉｎｇ）技法とデジタルビームフォーミング（ｄｉｇｉｔａｌ  ｂｅａｍｆｏｒｍｉｎｇ）技法とに区分できる。
【０１５８】
アナログビームフォーミング技法は、初期の多重アンテナ構造に適用されたビームフォーミング技法である。これは、デジタル信号の処理が完了したアナログ信号を多数の経路に分岐した後、各径路に対して位相シフト（Ｐｈａｓｅ−Ｓｈｉｆｔ、ＰＳ）と電力増幅器（Ｐｏｗｅｒ  Ａｍｐｌｉｆｉｅｒ、ＰＡ）の設定を適用してビームを形成する技法を意味することができる。
【０１５９】
アナログビームフォーミングのためには、各アンテナに連結されたＰＡとＰＳが単一のデジタル信号から派生したアナログ信号を処理（ｐｒｏｃｅｓｓ）する構造が要求される。言い換えると、アナログ段で前記ＰＡ及び前記ＰＳが複素加重値（ｃｏｍｐｌｅｘ  ｗｅｉｇｈｔ）を処理する。
【０１６０】
図５は、アナログビームフォーマ（ａｎａｌｏｇ  ｂｅａｍｆｏｒｍｅｒ）及びＲＦチェーン（ＲＦ  ｃｈａｉｎ）で構成される送信端（ｔｒａｎｓｍｉｔｔｅｒ）のブロック図（ｂｌｏｃｋ  ｄｉａｇｒａｍ）の一例を示す。図５は、単に説明の便宜のためのものであるだけで、本発明の範囲を制限するものではない。
【０１６１】
図５において、ＲＦチェーンは基底帯域（ｂａｓｅｂａｎｄ、ＢＢ）信号がアナログ信号へ変換される処理ブロックを意味する。アナログビームフォーミング技法は、前記ＰＡと前記ＰＳの素子の特性によってビームの正確度が決定され、前記素子の制御特性上、狭帯域（ｎａｒｒｏｗｂａｎｄ）送信に有利であり得る。
【０１６２】
また、アナログビームフォーミング技法の場合、多重ストリーム（ｓｔｒｅａｍ）の送信を具現しにくいハードウェア構造で構成されるので、送信率増大のための多重化利得（ｍｕｌｔｉｐｌｅｘｉｎｇ  ｇａｉｎ）が相対的に小さい。また、この場合、直交リソース割り当てベースの端末別ビームフォーミングが容易ではないこともある。
【０１６３】
これと異なり、デジタルビームフォーミング技法の場合、ＭＩＭＯ環境でダイバーシティ（ｄｉｖｅｒｓｉｔｙ）と多重化利得を最大化するためにＢＢ（Ｂａｓｅｂａｎｄ）プロセスを用いてデジタル段でビームフォーミングが行われる。
【０１６４】
図６は、デジタルビームフォーマ（ｄｉｇｉｔａｌ  ｂｅａｍｆｏｒｍｅｒ）及びＲＦチェーンで構成される送信端のブロック図の一例を示す。図６は、単に説明の便宜のためのものであるだけで、本発明の範囲を制限するものではない。
【０１６５】
図６の場合、ビームフォーミングは、ＢＢプロセスでプリコーディングが行われることによって行われることができる。ここで、ＲＦチェーンはＰＡを含む。これは、デジタルビームフォーミング技法の場合、ビームフォーミングのために導出された複素加重値が送信データに直接的に適用されるためである。
【０１６６】
また、端末別に異なるビームフォーミングが行われることができるので、同時に多重ユーザのビームフォーミングをサポートすることができる。のみならず、直交リソースが割り当てられた端末別に独立なビームフォーミングが可能であるので、スケジューリングの柔軟性が向上し、これによって、システムの目的に符合する送信端の運用が可能である。また、広帯域送信をサポートする環境でＭＩＭＯ−ＯＦＤＭのような技術が適用される場合に、副搬送波（ｓｕｂｃａｒｒｉｅｒ）別に独立なビームが形成されることもできる。
【０１６７】
従って、デジタルビームフォーミング技法は、システムの容量増大と強化したビーム利得に基づいて、単一端末（又はユーザ）の最大送信率を極大化することができる。前述したような特徴に基づき、既存の３Ｇ／４Ｇ（例：ＬＴＥ（−Ａ））システムではデジタルビームフォーミングベースのＭＩＭＯ技法が導入された。
【０１６８】
ＮＲシステムで、送受信アンテナが大きく増加する大規模（ｍａｓｓｉｖｅ）ＭＩＭＯ環境が考慮できる。一般に、セルラー（ｃｅｌｌｕｌａｒ）通信では、ＭＩＭＯ環境に適用される最大の送受信アンテナが８本と仮定される。しかし、大規模ＭＩＭＯ環境が考慮されることによって、前記送受信アンテナの数は、数十又は数百本以上に増加し得る。
【０１６９】
このとき、大規模ＭＩＭＯ環境で、前記で説明されたデジタルビームフォーミング技術が適用されると、送信端はデジタル信号の処理のためにＢＢプロセスを介して数百本のアンテナに対する信号処理を行わなければならない。これによって、信号処理の複雑度が非常に大きくなり、アンテナの数だけのＲＦチェーンが必要であるので、ハードウェア具現の複雑度も非常に大きくなることがある。
【０１７０】
また、送信端は全てのアンテナに対して独立なチャネル推定（ｃｈａｎｎｅｌ  ｅｓｔｉｍａｔｉｏｎ）が必要である。のみならず、ＦＤＤシステムの場合、送信端は全てのアンテナで構成された大規模ＭＩＭＯチャネルに対するフィードバック情報が必要であるので、パイロット（ｐｉｌｏｔ）及び／又はフィードバックのオーバーヘッドが非常に大きくなることがある。
【０１７１】
反面、大規模ＭＩＭＯ環境で前記で説明されたアナログビームフォーミング技術が適用されると、送信端のハードウェアの複雑度は相対的に低い。
【０１７２】
これに対して、多数のアンテナを利用した性能の増加程度は非常に小さく、リソース割り当ての柔軟性が低くなることがある。特に、広帯域送信の際、周波数別にビームを制御することが容易ではない。
【０１７３】
従って、大規模ＭＩＭＯ環境ではアナログビームフォーミングとデジタルビームフォーミングの技法のうち、１つのみを排他的に選択するものではなく、アナログビームフォーミングとデジタルビームフォーミングの構造が結合されたハイブリッド（ｈｙｂｒｉｄ）形態の送信端の構成方式が必要である。
【０１７４】
アナログビームスキャニング（ａｎａｌｏｇ  ｂｅａｍ  ｓｃａｎｎｉｎｇ）
【０１７５】
一般に、アナログビームフォーミングは純粋アナログビームフォーミングの送受信端とハイブリッドビームフォーミングの送受信端で利用されることができる。このとき、アナログビームスキャニングは、同じ時間に１つのビームに対する推定を行うことができる。従って、ビームスキャニングに必要なビームトレーニング（ｂｅａｍ  ｔｒａｉｎｉｎｇ）の時間は全体候補ビームの数に比例することになる。
【０１７６】
前述したように、アナログビームフォーミングの場合、送受信端のビーム推定のために、時間領域でのビームスキャニング過程が必ず要求される。このとき、全体送受信ビームに対する推定時間ｔｓは、下記数式２のように表現され得る。
【０１７７】
【数２】
2021503261.tif 000038
【０１７８】
数式２において、ｔｓは１つのビームスキャニングのために必要な時間を意味し、ＫＴは送信ビームの数を意味し、ＫＲは受信ビームの数を意味する。
【０１７９】
図７は、本発明の多様な実施形態に係るアナログビームスキャニング方式の一例を示す。図７は、単に説明の便宜のためのものであるだけで、本発明の範囲を制限するものではない。
【０１８０】
図７の場合、全体送信ビームの数ＫＴがＬであり、全体受信ビームの数ＫＲが１である場合が仮定される。この場合、全体候補ビームの数は計Ｌ個になるので、時間領域でＬ個の時間区間が要求される。
【０１８１】
言い換えると、アナログビーム推定のために単一時間区間で１個のビーム推定のみが行われることができるので、図７に示されたように、全体Ｌ個のビーム（Ｐ１乃至ＰＬ）推定を行うために、Ｌ個の時間区間が要求される。端末は、アナログビーム推定手続が終了した後、最も高い信号強度を有するビームの識別子（例：ＩＤ）を基地局にフィードバックする。即ち、送受信アンテナの数の増加によって、個別ビームの数が増加するほど、より長いトレーニング時間が要求され得る。
【０１８２】
アナログビームフォーミングは、ＤＡＣ（Ｄｉｇｉｔａｌ−ｔｏ−Ａｎａｌｏｇ  Ｃｏｎｖｅｒｔｅｒ）以降に時間領域の連続的な波形（ｃｏｎｔｉｎｕｏｕｓ  ｗａｖｅｆｏｒｍ）のサイズと位相角を変化させるため、デジタルビームフォーミングと異なり、個別ビームに対するトレーニング区間が保障される必要がある。従って、前記トレーニング区間の長さが増加するほど、システムの効率が減少（即ち、システムの損失（ｌｏｓｓ）が増加）し得る。
【０１８３】
チャネル状態情報（Ｃｈａｎｎｅｌ  ｓｔａｔｅ  ｉｎｆｏｒｍａｔｉｏｎ：ＣＳＩ）のフィードバック（ｆｅｅｄｂａｃｋ）
【０１８４】
ＬＴＥシステムを含む大半のセルラーシステム（ｃｅｌｌｕｌａｒ  ｓｙｓｔｅｍ）で、端末はチャネル推定のためのパイロット信号（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）を基地局から受信してＣＳＩ（ｃｈａｎｎｅｌ  ｓｔａｔｅ  ｉｎｆｏｒｍａｔｉｏｎ）を計算し、これを基地局に報告する。
【０１８５】
基地局は、端末からフィードバックを受けたＣＳＩ情報をもとにデータ信号を送信する。
【０１８６】
ＬＴＥシステムで端末がフィードバックするＣＳＩ情報には、ＣＱＩ（ｃｈａｎｎｅｌ  ｑｕａｌｉｔｙ  ｉｎｆｏｒｍａｔｉｏｎ）、ＰＭＩ（ｐｒｅｃｏｄｉｎｇ  ｍａｔｒｉｘ  ｉｎｄｅｘ）、ＲＩ（ｒａｎｋ  ｉｎｄｉｃａｔｏｒ）がある。
【０１８７】
ＣＱＩフィードバックは、基地局がデータを送信するとき、どんなＭＣＳ（ｍｏｄｕｌａｔｉｏｎ  ＆  ｃｏｄｉｎｇ  ｓｃｈｅｍｅ）を適用するかに対するガイドを提供しようとする目的（リンク適応用途）で基地局に提供する無線チャネル品質情報である。
【０１８８】
基地局と端末との間で無線品質が高いと、端末は高いＣＱＩ値をフィードバックし、基地局は相対的に高い変調次数（ｍｏｄｕｌａｔｉｏｎ  ｏｒｄｅｒ）と低いチャネルコーディング率（ｃｈａｎｎｅｌ  ｃｏｄｉｎｇ  ｒａｔｅ）を適用してデータを送信し、逆の場合、端末は低いＣＱＩ値をフィードバックし、基地局は相対的に低い変調次数（ｍｏｄｕｌａｔｉｏｎ  ｏｒｄｅｒ）と高いチャネルコーディング率（ｃｈａｎｎｅｌ  ｃｏｄｉｎｇ  ｒａｔｅ）を適用してデータを送信する。
【０１８９】
ＰＭＩのフィードバックは、基地局が多重アンテナを設置した場合、どんなＭＩＭＯプリコーディング方式（ｐｒｅｃｏｄｉｎｇ  ｓｃｈｅｍｅ）を適用するかに対するガイドを提供しようとする目的で、基地局に提供する好まれたプリコーディングマトリクス（ｐｒｅｆｅｒｒｅｄ  ｐｒｅｃｏｄｉｎｇ  ｍａｔｒｉｘ）情報である。
【０１９０】
端末は、パイロット信号から基地局と端末間のダウンリンクＭＩＭＯチャネル（ｄｏｗｎｌｉｎｋ  ＭＩＭＯ  ｃｈａｎｎｅｌ）を推定し、基地局がどんなＭＩＭＯプリコーディングを適用すればよいかをＰＭＩフィードバックを介して推薦する。
【０１９１】
ＬＴＥシステムでは、ＰＭＩの構成において、行列の形態で表現可能な線形ＭＩＭＯプリコーディング（ｌｉｎｅａｒ  ＭＩＭＯ  ｐｒｅｃｏｄｉｎｇ）のみ考慮する。
【０１９２】
基地局と端末は、多数のプリコーディングの行列で構成されたコードブックを共有しており、コードブック内にそれぞれのＭＩＭＯプリコーディング行列は、固有のインデックスを有している。
【０１９３】
従って、端末は、コートブック内で最も好むＭＩＭＯプリコーディング行列に該当するインデックスをＰＭＩとしてフィードバックすることによって、端末のフィードバック情報量を最小化する。
【０１９４】
ＰＭＩ値が必ずしも１つのインデックスのみで行われるべきものではない。一例として、ＬＴＥシステムで送信アンテナポートの数が８本である場合、二つのインデックス（ｆｉｒｓｔ  ＰＭＩ  ＆  ｓｅｃｏｎｄ  ＰＭＩ）を結合してこそ、最終的な８ｔｘ  ＭＩＭＯプリコーディング行列を導出することができるように構成されている。
【０１９５】
ＲＩフィードバックは、基地局と端末が多重アンテナを設置し、空間多重化（ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）を介した多重レイヤー（ｍｕｌｔｉ−ｌａｙｅｒ）の送信が可能である場合、端末が好む送信レイヤーの数に対するガイドを提供しようとする目的で基地局に提供する好む送信レイヤーの数に対する情報である。
【０１９６】
ＲＩは、ＰＭＩと非常に密接な関係を有する。それは、送信レイヤーの数に応じて、基地局はそれぞれのレイヤーにどんなプリコーディングを適用すべきか分からなければならないためである。
【０１９７】
ＰＭＩ／ＲＩフィードバックの構成において、単一レイヤー（ｓｉｎｇｌｅ  ｌａｙｅｒ）の送信を基準に、ＰＭＩコードブックを構成した後、レイヤー別にＰＭＩを定義してフィードバックできるが、このような方式は、送信レイヤーの数の増加によってＰＭＩ／ＲＩフィードバックの情報量が大きく増加するというデメリットがある。
【０１９８】
従って、ＬＴＥシステムでは、それぞれの送信レイヤーの数によるＰＭＩコードブックを定義した。即ち、Ｒ−レイヤーの送信のために、サイズＮｔ×Ｒ行列Ｎ個をコードブック内に定義する（ここで、Ｒは、レイヤーの数、Ｎｔは送信アンテナポートの数、Ｎはコードブックのサイズ）。
【０１９９】
従って、ＬＴＥでは、送信レイヤーの数に関係なく、ＰＭＩコードブックのサイズが定義される。結果、このような構造でＰＭＩ／ＲＩを定義しているため、送信レイヤーの数（Ｒ）は、結局のところプリコーディング行列（Ｎｔ×Ｒ行列）のランク値と一致することになるので、ｒａｎｋ  ｉｎｄｉｃａｔｏｒ（ＲＩ）という用語を使用することになった。
【０２００】
本明細書で記述されるＰＭＩ／ＲＩは、必ずしもＬＴＥシステムにおけるＰＭＩ／ＲＩのように、Ｎｔ×Ｒ行列で表現されるプリコーディング行列のインデックス値と、プリコーディング行列のランク値を意味するものと制限されない。
【０２０１】
本明細書で記述されるＰＭＩは、送信端で適用可能なＭＩＭＯプリコーダのうち好むＭＩＭＯプリコーダ情報を示すものであって、そのプリコーダの形態がＬＴＥシステムでのように行列で表現可能な線形プリコーダのみに限定されない。また、本明細書で記述されるＲＩは、ＬＴＥにおけるＲＩよりもさらに広い意味で、好む送信レイヤーの数を示すフィードバック情報を全て含む。
【０２０２】
ＣＳＩ情報は、全体システム周波数領域から求められてもよく、一部周波数領域から求められてもよい。特に、広帯域システムでは、端末別に好む一部周波数領域（例えば、サブバンド）に対するＣＳＩ情報を求めてフィードバックすることが有用であり得る。
【０２０３】
ＬＴＥシステムでＣＳＩフィードバックはアップリンクチャネルを介して行われるが、一般に周期的なＣＳＩフィードバックは、ＰＵＣＣＨ（ｐｈｙｓｉｃａｌ  ｕｐｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）を介して行われ、非周期的なＣＳＩフィードバックは、アップリンクデータチャネルであるＰＵＳＣＨ（ｐｈｙｓｉｃａｌ  ｕｐｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ）を介して行われる。
【０２０４】
非周期的なＣＳＩフィードバックは、基地局がＣＳＩフィードバックの情報を望む時にのみ一時的にフィードバックすることを意味するもので、基地局がＰＤＣＣＨ／ｅＰＤＣＣＨのようなダウンリンクコントロールチャネルを介してＣＳＩフィードバックをトリガー（ｔｒｉｇｇｅｒ）する。
【０２０５】
ＬＴＥシステムでは、ＣＳＩフィードバックがトリガーされたとき、端末がどんな情報をフィードバックすべきかが図８のようにＰＵＳＣＨ  ＣＳＩ報告モード（ｒｅｐｏｒｔｉｎｇ  ｍｏｄｅ）に区分されており、端末がどんなＰＵＳＣＨ  ＣＳＩ報告モード（ｒｅｐｏｒｔｉｎｇ  ｍｏｄｅ）で動作すべきかは、上位層のメッセージを介して端末に予め知らせる。
【０２０６】
図８は、ＰＵＳＣＨ  ＣＳＩ報告モードの一例を示した図である。
【０２０７】
ＰＵＣＣＨを介した周期的ＣＳＩフィードバックに対して、ＰＵＣＣＨ  ＣＳＩ報告モードやはり定義される。
【０２０８】
図９は、ＰＵＣＣＨ  ＣＳＩ報告モードの一例を示した図である。
【０２０９】
ＰＵＣＣＨの場合、ＰＵＳＣＨよりも一度に送ることができるデータ量（ｐａｙｌｏａｄ  ｓｉｚｅ）が小さいので、送ろうとするＣＳＩ情報を一度に送ることが難しい。
【０２１０】
従って、各ＣＳＩ報告モードによって、ＣＱＩ及びＰＭＩを送信する時点とＲＩを送信する時点とが異なる。例えば、報告モード１−０では、特定ＰＵＣＣＨ送信時点にはＲＩのみ送信し、別のＰＵＣＣＨ送信時点に広帯域ＣＱＩを送信する。特定ＰＵＣＣＨ送信時点に構成されるＣＳＩ情報の種類によって、ＰＵＣＣＨ報告タイプが定義される。例えば、前記例でＲＩのみ送信する報告タイプは、タイプ３に該当し、広帯域ＣＱＩのみ送信する報告タイプは、タイプ４に該当する。ＲＩフィードバックの周期及びオフセット値とＣＱＩ／ＰＭＩフィードバックの周期及びオフセット値は、上位層のメッセージを介して端末に設定される。
【０２１１】
前記ＣＳＩフィードバック情報は、アップリンクコントロール情報（ｕｐｌｉｎｋ  ｃｏｎｔｒｏｌ  ｉｎｆｏｒｍａｔｉｏｎ、ＵＣＩ）に含まれる。
【０２１２】
ＬＴＥにおける基準信号（Ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌｓ  ｉｎ  ＬＴＥ）
【０２１３】
ＬＴＥシステムでパイロット或いはＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）の用途は、大きく次のように分けられる。
【０２１４】
１．測定ＲＳ：チャネル状態測定用パイロット
【０２１５】
Ａ．ＣＳＩ測定／報告用途（ｓｈｏｒｔ  ｔｅｒｍ  ｍｅａｓｕｒｅｍｅｎｔ）：リンク適応（Ｌｉｎｋ  ａｄａｐｔａｔｉｏｎ）、ランク適応（ｒａｎｋ  ａｄａｐｔａｔｉｏｎ）、閉ループＭＩＭＯプリコーディング（ｃｌｏｓｅｄ  ｌｏｏｐ  ＭＩＭＯ  ｐｒｅｃｏｄｉｎｇ）等の目的
【０２１６】
Ｂ．長期間測定（Ｌｏｎｇ  ｔｅｒｍ  ｍｅａｓｕｒｅｍｅｎｔ）／報告用途：ハンドオーバー（Ｈａｎｄｏｖｅｒ）、セル選択（ｃｅｌｌ  ｓｅｌｅｃｔｉｏｎ）／再選択（ｒｅｓｅｌｅｃｔｉｏｎ）等の目的
【０２１７】
２．復調ＲＳ（Ｄｅｍｏｄｕｌａｔｉｏｎ  ＲＳ）：物理チャネル受信用パイロット
【０２１８】
３．位置決めＲＳ（Ｐｏｓｉｔｉｏｎｉｎｇ  ＲＳ）：端末位置推定用パイロット
【０２１９】
４．ＭＢＳＦＮ  ＲＳ：マルチキャスト／ブロードキャスト（Ｍｕｌｔｉ−ｃａｓｔ／Ｂｒｏａｄｃａｓｔ）サービスのためのパイロット
【０２２０】
ＬＴＥ  Ｒｅｌ−８では、大半のダウンリンク物理チャネルに対する測定（用途１Ａ／Ｂ）及び復調（用途２）のためにＣＲＳ（Ｃｅｌｌ−ｓｐｅｃｉｆｉｃ  ＲＳ）を使用したが、アンテナの数が多くなることによるＲＳのオーバーヘッドの問題を解決するために、ＬＴＥ  Ａｄｖａｎｃｅｄ（Ｒｅｌ−１０）からはＣＳＩ測定（用途１Ａ）専用としてＣＳＩ−ＲＳとダウンリンクデータチャネル（ＰＤＳＣＨ）に対する受信（用途２）専用としてＵＥ−ｓｐｅｃｉｆｉｃ  ＲＳを使用する。
【０２２１】
ＣＳＩ−ＲＳは、ＣＳＩ測定及びフィードバック専用に設計されたＲＳであって、ＣＲＳに比べて非常に低いＲＳのオーバーヘッドを有することが特徴であり、ＣＲＳは４本の多重アンテナポートまでサポートするのに対して、ＣＳＩ−ＲＳは８本の多重アンテナポートまでサポート可能なように設計された。ＵＥ−ｓｐｅｃｉｆｉｃ  ＲＳは、データチャネルの復調専用に設計されてＣＲＳと異なり、該当ＵＥにデータ送信時に適用されたＭＩＭＯプリコーディング技法がパイロット信号に同じように適用されたＲＳ（ｐｒｅｃｏｄｅｄ  ＲＳ）という点が特徴である。
【０２２２】
従って、ＵＥ特定ＲＳ（ＵＥ−ｓｐｅｃｉｆｉｃ  ＲＳ）はＣＲＳ、ＣＳＩ−ＲＳのようにアンテナポートの数だけ送信される必要がなく、送信レイヤーの数（送信ランク）だけ送信すればよい。
【０２２３】
また、ＵＥ特定ＲＳは、基地局のスケジューラ（ｓｃｈｅｄｕｌｅｒ）を介して、各ＵＥに割り当てられたデータチャネルのリソース領域と同じリソース領域に該当ＵＥのデータチャネル受信用途で送信されるので、端末特定的ＲＳという特徴がある。
【０２２４】
ＣＲＳはセル内の全てのＵＥが測定及び復調用途で使用できるようにシステム帯域幅内で同じパターンで常時送信されるので、セル特定的である。
【０２２５】
ＬＴＥのアップリンクでは、測定ＲＳとしてＳｏｕｎｄｉｎｇ  ＲＳ（ＳＲＳ）が設計され、アップリンクデータチャネル（ＰＵＳＣＨ）に対する復調ＲＳ（ＤＭＲＳ）とＡＣＫ／ＮＡＣＫ及びＣＳＩフィードバックのためのアップリンクコントロールチャネル（ＰＵＣＣＨ）に対するＤＭＲＳがそれぞれ設計された。
【０２２６】
ビーム管理及びビーム復旧（Ｂｅａｍ  ｍａｎａｇｅｍｅｎｔ  ａｎｄ  ｂｅａｍ  ｒｅｃｏｖｅｒｙ）
【０２２７】
基地局は端末に周期的（ｐｅｒｉｏｄｉｃ）ＣＳＩ報告、半固定的（ｓｅｍｉ−ｐｅｒｓｉｓｔｅｎｔ）ＣＳＩ報告（特定時間区間の間にのみ周期的ＣＳＩ報告が活性化（ａｃｔｉｖａｔｉｏｎ）されるか、或いは連続的な複数回のＣＳＩ報告を実行）、若しくは非周期的（ａｐｅｒｉｏｄｉｃ）ＣＳＩ報告を要求することができる。
【０２２８】
ここで、前記周期的（ｐｅｒｉｏｄｉｃ）及び半固定的（ｓｅｍｉ−ｐｅｒｓｉｓｔｅｎｔ、ＳＰ）ＣＳＩ報告は、報告が活性化された期間には端末に特定周期にＣＳＩ報告のためのＵＬ（ｕｐｌｉｎｋ）リソース（例えば、ＰＵＣＣＨ  ｉｎ  ＬＴＥ）が割り当てられる。
【０２２９】
端末のＣＳＩ測定のためには、基地局のダウンリンク（ＤＬ）参照信号（ＲＳ）の送信が必要である。
【０２３０】
（アナログ）ビームフォーミングが適用されたビームフォーミングされたシステム（ｂｅａｍｆｏｒｍｅｄ  ｓｙｓｔｅｍ）の場合、前記ＤＬ  ＲＳ送信／受信のためのＤＬ送信（Ｔｘ）／ｒｅｃｅｐｔｉｏｎ（Ｒｘ）ビーム対（ｂｅａｍ  ｐａｉｒ）と、ＵＣＩ（ｕｐｌｉｎｋ  ｃｏｎｔｒｏｌ  ｉｎｆｏｒｍａｔｉｏｎ：例えば、ＣＳＩ、ＡＣＫ／ＮＡＣＫ）送信／受信のためのＵＬ  Ｔｘ／Ｒｘビーム対の決定が必要である。
【０２３１】
ＤＬビーム対の決定手続は、（１）複数個のＴＲＰ  Ｔｘビームに該当するＤＬ  ＲＳを基地局が端末へ送信する手続と、（２）前記端末がこのうち１つを選択／又は報告するＴＲＰ  Ｔｘビーム選択手続と、（３）基地局が各ＴＲＰ  Ｔｘビームに該当する同じＲＳ信号を繰り返し送信する手続と、（４）前記端末が前記繰り返し送信された信号に互いに異なるＵＥ  Ｒｘビームで測定し、ＵＥ  Ｒｘビームを選択する手続の組み合わせで構成されることができる。
【０２３２】
また、ＵＬビーム対決定手続は、（１）複数個のＵＥ  Ｔｘビームに該当するＵＬ  ＲＳを端末が基地局が送信する手続と、（２）基地局がこのうち１つを選択及び／又はシグナリングするＵＥ  Ｔｘビーム選択手続と、（３）前記端末が各ＵＥ  Ｔｘビームに該当する同じＲＳ信号を基地局へ繰り返し送信する手続と、（４）前記基地局が前記繰り返し送信された信号に互いに異なるＴＲＰ  Ｒｘビームで測定し、ＴＲＰ  Ｒｘビームを選択する手続と、の組み合わせで構成されることができる。
【０２３３】
ＤＬ／ＵＬのビーム相互性（ｂｅａｍ  ｒｅｃｉｐｒｏｃｉｔｙ）（又はビーム対応（ｂｅａｍ  ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ））が成立する場合、即ち、基地局と端末間の通信で基地局のＤＬ  Ｔｘビームと基地局のＵＬ  Ｒｘビームとが一致し、端末のＵＬ  Ｔｘビームと端末のＤＬ  Ｒｘビームとが一致すると仮定できる場合、ＤＬビーム対とＵＬビーム対のうちいずれか１つのみ決定すると、もう１つを決定する手続を省略することができる。
【０２３４】
ＤＬ及び／又はＵＬビーム対に対する決定過程は、周期的又は非周期的に行われることができる。
【０２３５】
候補（ｃａｎｄｉｄａｔｅ）ビームの数が多い場合、要求されるＲＳのオーバーヘッドが大きいことがあるため、前記ＤＬ及び／又はＵＬビーム対に対する決定過程がよく発生することは好ましくない。
【０２３６】
ＤＬ／ＵＬビーム対決定過程が完了した以降、端末は周期的（ｐｅｒｉｏｄｉｃ）又はＳＰ（Ｓｅｍｉ−Ｐｅｒｓｉｓｔｅｎｔ）ＣＳＩ報告を行うと仮定しよう。
【０２３７】
ここで、端末のＣＳＩ測定（ｍｅａｓｕｒｅｍｅｎｔ）のための単一又は複数個のアンテナポートを含むＣＳＩ−ＲＳは、ＤＬビームで決定されたＴＲＰ  Ｔｘビームでビームフォーミングされて送信されてもよく、ＣＳＩ−ＲＳの送信周期は、ＣＳＩ報告（ｒｅｐｏｒｔｉｎｇ）周期と同一であってもよく、又はさらによく送信されてもよい。
【０２３８】
或いは、端末は、非周期的（ａｐｅｒｉｏｄｉｃ）ＣＳＩ−ＲＳをＣＳＩ報告周期に合わせて、又はさらによく送信することも可能である。
【０２３９】
端末（例：ＵＥ）は、測定されたＣＳＩ情報を周期的にＵＬビーム対決定過程で既決定されたＵＬ  Ｔｘビームに送信することができる。
【０２４０】
ＤＬ／ＵＬビーム管理過程を行うにあたって、設定されたビーム管理の周期によって、ビーム不一致（ｍｉｓｍａｔｃｈ）の問題が発生し得る。
【０２４１】
特に、端末が位置を移動したり、端末が回転したり、又は前記端末周辺の物体の移動で無線チャネルの環境が変わる場合（例えば、ＬｏＳ（Ｌｉｎｅ−ｏｆ−Ｓｉｇｈｔ）環境であったが、ビームがブロックされて、非ＬｏＳ環境に変わる場合）、最適のＤＬ／ＵＬビーム対は変わることがある。
【０２４２】
このような変化を一般的にネットワークの指示によって行うビーム管理過程でトラッキングが失敗したとき、ビーム失敗イベント（ｂｅａｍ  ｆａｉｌｕｒｅ  ｅｖｅｎｔ）が発生したといえる。
【０２４３】
このようなビーム失敗イベントの発生可否は、端末がダウンリンクＲＳの受信品質を通じて判断することができ、このような状況に対する報告メッセージ又はビーム復旧要求のためのメッセージ（以下、「ビーム復旧要求メッセージ（ｂｅａｍ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ  ｍｅｓｓａｇｅ）」と定義する）が端末から伝達されなければならない。
【０２４４】
前記ビーム復旧要求メッセージは、ビーム失敗復旧要求メッセージ、制御信号、制御メッセージ、ファーストメッセージ（ｆｉｒｓｔ  ｍｅｓｓａｇｅ）などで多様に表現され得る。
【０２４５】
前記端末から前記ビーム復旧要求メッセージを受信した基地局は、ビーム復旧のために端末へビームＲＳ送信、ビーム報告要求等、多様な過程を通じてビーム復旧を行うことができる。
【０２４６】
このような一連のビーム復旧過程を「ビーム復旧（ｂｅａｍ  ｒｅｃｏｖｅｒｙ）」と表現することとする。
【０２４７】
３ＧＰＰでＬＴＥ以降のＮＲ（ｎｅｗ  ｒａｄｉｏ  ｏｒ  Ｎｅｗ  Ｒａｔ）と名付けた新しい通信システムに対する標準化が進んでおり、ビーム管理（ｂｅａｍ  ｍａｎａｇｅｍｅｎｔ）に関して、下記のような内容が含まれる。
【０２４８】
（内容１）
【０２４９】
ＮＲは、ＵＥがビーム失敗（ｂｅａｍ  ｆａｉｌｕｒｅ）から復旧（ｒｅｃｏｖｅｒｙ）するメカニズムをトリガーできることをサポートする。
【０２５０】
ネットワークは、復旧の目的のために信号のＵＬ送信に対するリソースをＵＥに明示的に構成する。
【０２５１】
基地局が全体又は一部方向から聴取（ｌｉｓｔｅｎｉｎｇ）しているリソースの構成をサポートする（例えば、ランダムアクセス領域）。
【０２５２】
（後日議論）ＲＳ／制御チャネル／データチャネルのモニタリングのＵＥ動作と関連した復旧信号（新規又は既存の信号）のトリガー条件
【０２５３】
ＵＥが新しい潜在的なビームを識別するために、ビームをモニターできるように許容するＤＬ信号の送信をサポートする。
【０２５４】
（後日議論）ビームスイープ（ｂｅａｍ  ｓｗｅｅｐ）制御チャネルの送信が排除されない。
【０２５５】
このメカニズムは、性能とＤＬシグナリングオーバーヘッド間のかね合い（ｔｒａｄｅｏｆｆ）を考慮しなければならない。
【０２５６】
（内容２）
【０２５７】
できるだけ下記の候補ソリューションを考慮し、ビーム管理オーバーヘッド及び遅延時間は、ＮＲのビーム管理のためのＣＳＩ−ＲＳの設計中に考慮されなければならない。
【０２５８】
Ｏｐｔ１．ＩＦＤＭＡ
【０２５９】
Ｏｐｔ２．大きい副搬送波間隔（ｌａｒｇｅ  ｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇ）
【０２６０】
ＮＲのビーム管理のためのＣＳＩ−ＲＳの設計中に考慮される他の側面は、例えば、ＣＳＩ−ＲＳ多重化、ＵＥのビームスイッチレイテンシ及びＵＥ具現の複雑性（例えば、ＡＧＣトレーニング時間）、ＣＳＩ−ＲＳのカバレッジなどを含む。
【０２６１】
（内容３）
【０２６２】
ＣＳＩ−ＲＳは、ＤＬ  Ｔｘビームスイーピング及びＵＥ  Ｒｘビームスイーピングをサポートする。
【０２６３】
ＮＲのＣＳＩ−ＲＳは、次のマッピング構造をサポートする。
【０２６４】
ＮＰ  ＣＳＩ−ＲＳポートは、（サブ）時間単位別にマッピングされることができる。
【０２６５】
（サブ）時間単位（ｕｎｉｔ）にかけて同じＣＳＩ−ＲＳアンテナポートがマッピングされることができる。
【０２６６】
ここで、「時間単位」は、設定された／参照ヌメロロジー（ｃｏｎｆｉｇｕｒｅｄ／ｒｅｆｅｒｅｎｃｅ  ｎｕｍｅｒｏｌｏｇｙ）で、ｎ  ＯＦＤＭシンボル（ｎ＞＝１）を示す。
【０２６７】
各時間単位は、サブ−時間単位でパーティション（ｐａｒｔｉｔｉｏｎ）できる。
【０２６８】
このマッピング構造は、多数のパネル／Ｔｘチェーンをサポートするために使用されることができる。
【０２６９】
（オプション１）
【０２７０】
Ｔｘビームは、各時間単位内のサブ時間単位にかけて同一である。
【０２７１】
Ｔｘビームは、時間単位に応じて異なる。
【０２７２】
（オプション２）
【０２７３】
Ｔｘビームは、各時間単位内でサブ時間単位毎に異なる。
【０２７４】
Ｔｘビームは、時間単位で同一である。
【０２７５】
（オプション３）：オプション１とオプション２との組み合わせ
【０２７６】
１つの時間単位内で、Ｔｘビームはサブ時間単位で同一である。
【０２７７】
別の時間単位内で、Ｔｘビームはサブ時間単位毎に異なる。
【０２７８】
以下、端末のビーム失敗復旧メカニズム（Ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｍｅｃｈａｎｉｓｍ）について簡略に見る。
【０２７９】
前記端末のビーム失敗復旧メカニズムは、下記（１）乃至（４）の過程を含む。
【０２８０】
（１）ビーム失敗を感知する。
【０２８１】
（２）新しい候補ビームを識別する。
【０２８２】
（３）ビーム失敗復旧要求を送信する。
【０２８３】
（４）ＵＥはビーム失敗復旧要求に対するｇＮＢの応答をモニターする。
【０２８４】
まず、ビーム失敗感知過程について見ると、ＵＥは、ビーム失敗のトリガー条件が満たされたか否かを評価するために、ビーム失敗感知ＲＳをモニターする。
【０２８５】
また、ビーム失敗感知ＲＳは、少なくともビーム管理のための周期的なＣＳＩ−ＲＳを含む。ここで、ＳＳ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｓｉｇｎａｌ）ブロック（ｂｌｏｃｋ）もビーム管理に使用されることができ、ＳＳブロックがビーム管理に使用される場合、サービングセル内ＳＳブロックが考慮できる。
【０２８６】
ここで、ＳＳブロックは、同期信号（ＳＳ）がスロット単位又は特定の時間単位で送信されると解釈され得る。
【０２８７】
ここで、ビーム失敗感知ＲＳは、該当ＲＳの品質自体を測定する場合だけでなく、該当ＲＳとＱＣＬ（Ｑｕａｓｉ  Ｃｏ−Ｌｏｃａｔｉｏｎ）指示子等で関連した無線チャネルの検出／復調（ｄｅｔｅｃｔｉｏｎ／ｄｅｍｏｄｕｌａｔｉｏｎ）の品質を測定する場合を含む。例えば、（ｐｒｉｍａｒｙ）ＰＤＣＣＨのモニタリングのために指示されたＣＳＩ−ＲＳ或いはＳＳブロック関連のＩＤを前記ビーム失敗感知ＲＳと理解でき、このとき、ビーム失敗イベントの発生可否は、該当ＰＤＣＣＨの検出／復調（ｄｅｔｅｃｔｉｏｎ／ｄｅｍｏｄｕｌａｔｉｏｎ）性能が一定以下である場合と定義されることができる。
【０２８８】
前記ビーム失敗イベントの発生は、関連した（ａｓｓｏｃｉａｔｅｄ）制御チャネルのビーム対リンクの品質が一定レベル以下に下げたときに発生し得る。
【０２８９】
具体的に、前記関連した制御チャネルのビーム対リンクの品質は、ＰＤＣＣＨ検出性能（ｄｅｔｅｃｔｉｏｎ  ｐｅｒｆｏｒｍａｎｃｅ）で決定されることもできる。
【０２９０】
例えば、端末がＰＤＣＣＨをモニタリング（又はブラインドデコーディング）する過程で、ＣＲＣチェックの結果、ＰＤＣＣＨ検出性能がよくない場合、端末はビーム失敗を検出することができるようになる。
【０２９１】
或いは、多重ＰＤＣＣＨｓが多重ビームを介して（又は多重ＰＤＣＣＨｓがそれぞれ互いに異なるビームに）送信される場合、特定ＰＤＣＣＨ（例：サービングビームと関連したＰＤＣＣＨ）に対する検出性能で前記ビーム失敗イベントの発生可否を判断することができる。
【０２９２】
ここで、多重ＰＤＣＣＨｓのそれぞれは、互いに異なる制御チャネル領域（例：シンボル、スロット、サブフレームなど）で互いに異なるビーム別に送信及び／又は受信されることができる。
【０２９３】
この場合、ビーム別制御チャネル領域が予め定義されてもよく、上位層のシグナリング（ｈｉｇｈｅｒ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を介して送受信されてもよい。
【０２９４】
また、前記関連した制御チャネルのビーム対リンクの品質で前記ビーム失敗イベントの発生可否を判断するとき、ＤＬビームの品質のみが一定レベル以下に下げたか、又はＵＬビームの品質のみが一定レベル以下に下げたか、又はＤＬビームとＵＬビームの品質がいずれも一定レベル以下に下げたかに応じて、前記ビーム失敗イベントの発生可否が決定されることができる。
【０２９５】
ここで、前記一定レベル以下は、臨界値以下、関連したタイマーのｔｉｍｅ−ｏｕｔ等であり得る。
【０２９６】
また、前記ビーム失敗を検出する信号として、ＢＲＳ、ファインタイミング（ｆｉｎｅ  ｔｉｍｉｎｇ）／周波数トラッキング（ｆｒｅｑｕｅｎｃｙ  ｔｒａｃｋｉｎｇ）のためのＲＳ、ＳＳブロック、ＰＤＣＣＨのためのＤＭ−ＲＳ、ＰＤＳＣＨのためのＤＭ−ＲＳ等が使用できる。
【０２９７】
次に、新しい候補ビームの識別過程について見ると、ＵＥはビーム識別ＲＳをモニタリングし、新しい候補ビームを見つける。
【０２９８】
−ビーム識別ＲＳは、１）ＮＷによって構成された場合、ビーム管理のための周期的ＣＳＩ−ＲＳ、２）ＳＳブロックがビーム管理に使用される場合、サービングセル内の周期的なＣＳＩ−ＲＳ及びＳＳブロックに対する情報を含む。
【０２９９】
次に、ビーム失敗復旧要求送信過程について見ると、ビーム失敗復旧要求によって運ばれる情報は、１）ＵＥ及び新しいｇＮＢ  ＴＸビーム情報を識別するための明示的／暗示的情報、又は２）ＵＥを識別して新しい候補ビームが存在するか否かに対する明示的／暗示的情報のうち少なくとも１つを含む。
【０３００】
また、ビーム失敗復旧要求の送信は、ＰＲＡＣＨ、ＰＵＣＣＨ、ＰＲＡＣＨ−ｌｉｋｅ（例えば、ＰＲＡＣＨからのプリアンブルシーケンスに対する異なるパラメータ）のうち１つを選択することができる。
【０３０１】
−ビーム失敗復旧要求リソース／信号は、スケジューリング要求にさらに使用されることができる。
【０３０２】
次に、ＵＥはビーム失敗復旧要求に対するｇＮＢ応答を受信するために、制御チャネルの検索空間をモニターする。
【０３０３】
また、ビーム失敗復旧要求の送信に対して、下記のトリガリング条件をサポートする。
【０３０４】
−条件：ＣＳＩ−ＲＳのみが新しい候補ビームの識別のために使用される場合、ビーム失敗が検出され、候補ビームが識別される場合
【０３０５】
また、ビーム失敗復旧要求の送信のために下記のようなチャネルをサポートする。
【０３０６】
−ＰＲＡＣＨに基づく非競合ベースのチャネル、ＦＤＭに対して少なくとも異なるＰＲＡＣＨ送信のリソースに直交するリソースを使用する。
【０３０７】
−ビーム失敗復旧要求の送信のためのＰＵＣＣＨをサポートする。
【０３０８】
前記で見た通り、ＮＲの場合、ビーム復旧要求メッセージ（ｂｅａｍ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ  ｍｅｓｓａｇｅ）は、（１）ＰＲＡＣＨと同じシンボルを用いて送信されるか（一番目）、（２）ＰＲＡＣＨ以外のシンボルを用いて送信する（二番目）、二つのメカニズムが全てサポートされることができる。
【０３０９】
一番目は、ビーム失敗（ｆａｉｌｕｒｅ）により、アップリンクの同期まで失った場合（ビームの品質が相対的に多く落ちるか、代替ビームがない場合）、及び／又はビーム失敗イベント（ｂｅａｍ  ｆａｉｌｕｒｅ  ｅｖｅｎｔ）の発生時点と、既設定されたＰＲＡＣＨリソースが時間的に近い場合、有用なメカニズムであり得る。
【０３１０】
二番目は、ビーム失敗（ｆａｉｌｕｒｅ）の状況であるが、アップリンクの同期は失わない場合（ビームの品質が相対的に少し落ちるか、代替ビームがある場合）、及び／又はビーム失敗イベントの発生時点と既設定されたＰＲＡＣＨリソースが時間的に遠くて、ＰＲＡＣＨリソース（例：シンボル）まで待つには早いビーム復旧が難しい場合に有用なメカニズムであり得る。
【０３１１】
また、端末は、ビーム失敗（ｂｅａｍ  ｆａｉｌｕｒｅ）の際、基地局にビーム復旧要求メッセージを所定回数送信した後、前記基地局から前記要求に対する応答を受信できない場合、ＲＬＦ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｆａｉｌｕｒｅ）動作を行うことができる。
【０３１２】
端末の移動などにより、ビーム失敗（ｂｅａｍ  ｆａｉｌｕｒｅ）が発生した場合、ビームを復旧（ｒｅｃｏｖｅｒｙ）するための方法について見ることとする。
【０３１３】
特に、本明細書は、代替ビームの存在可否に応じて、ビームを復旧する方法が異なって行われることができ、具体的な内容については後述することとする。
【０３１４】
本明細書で使用するビームＲＳ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ）（ＢＲＳ）は、ビーム管理（ｍａｎａｇｅｍｅｎｔ）のために使用されるダウンリンク物理信号として、ＣＳＩ−ＲＳ、Ｍｏｂｉｌｉｔｙ  ＲＳ（ＭＲＳ）、同期信号（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｓｉｇｎａｌ）等がビームＲＳとして使用されることができる。
【０３１５】
前記ビームＲＳは、ビーム管理フレームワーク（ｂｅａｍ  ｍａｎａｇｅｍｅｎｔ  ｆｒａｍｅｗｏｒｋ）（又はＣＳＩフレームワーク）上でリソースセッティング（ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）によって（ＲＲＣレイヤーメッセージとして）設定されることができる。即ち、前記リソースセッティングによって、前記ビームＲＳは、予め設定されることができる。
【０３１６】
後述するように、前記ビーム管理フレームワークは、ビーム報告セッティング（Ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ  ｓｅｔｔｉｎｇ（ｓ））、ビームリソースセッティング（Ｂｅａｍ  ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ（ｓ））、ビームリソースセット（Ｂｅａｍ  ｒｅｓｏｕｒｃｅ  ｓｅｔ）、測定セッティング（Ｍｅａｓｕｒｅｍｅｎｔ  ｓｅｔｔｉｎｇ（ｓ））の関連関係を示す構造である。これに関するより具体的な内容は後述することとする。
【０３１７】
また、本明細書で使用するビーム報告（Ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ）は、ビームと関連した端末のフィードバック情報を意味し、ビーム品質関連の情報及び／又はビーム指示情報を含むことができる。
【０３１８】
本明細書で、「Ａ及び／又はＢ」、「Ａそして／又はＢ」、「Ａ／Ｂ」は、「Ａ又はＢのうち少なくとも１つを含む」という意味と同様に解釈され得る。
【０３１９】
前記ビーム品質関連の情報は、ＣＱＩ（Ｃｈａｎｎｅｌ  Ｑｕａｌｉｔｙ  Ｉｎｆｏｒｍａｔｉｏｎ）、レイヤー３のＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌｓ  Ｒｅｃｅｉｖｅｄ  Ｐｏｗｅｒ）、レイヤー１のＲＳＲＰ等であってもよい。
【０３２０】
また、前記ビーム指示情報は、ＣＲＩ（ＣＳＩ−ＲＳ  ｒｅｓｏｕｒｃｅ  ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）、ＲＳポートインデックス等であってもよい。
【０３２１】
前記ビームに関するフィードバック情報、パラメータ（ｐａｒａｍｅｔｅｒ）、報告周期、周波数単位（ｇｒａｎｕｌａｒｉｔｙ）（例えば、広帯域フィードバック、サブバンドフィードバック）等は、前記ビーム管理フレームワーク（又はＣＳＩフレームワーク）上で報告セッティング（ｒｅｐｏｒｔｉｎｇ  ｓｅｔｔｉｎｇ）によって（ＲＲＣレイヤーメッセージとして）設定されることができる。
【０３２２】
即ち、前記報告セッティングにより、前記ビームと関連したフィードバック情報、報告周期、周波数単位等が予め設定されることができる。
【０３２３】
端末がビーム復旧要求（Ｂｅａｍ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をネットワーク（例：基地局）へ送信する場合、前記ネットワークは下記のように二つの動作（方法１及び方法２）を取ることができる。
【０３２４】
（方法１）
【０３２５】
方法１は、代替ビーム（例：代替ＤＬビーム対）がない場合のネットワーク動作を示す。
【０３２６】
即ち、方法１は、ネットワークが端末からビーム復旧要求を受信した場合、（非周期的）ビームＲＳを端末へ送信し（又はビームＲＳをトリガーし）、（非周期的）ビーム報告トリガーを端末へ送信する方法に関する。
【０３２７】
前記代替ビームとは、基地局が周期的なビーム管理又はモニタリングのために設定したＲＳセットで理解されることができ、端末が測定可能なビームのセットよりも同じでもよく、小さくてもよい。
【０３２８】
即ち、前記代替ビームは、ビーム管理の目的で設定されたＲＳのうち、特定品質以上を有するＲＳ（ｓ）であってもよい。
【０３２９】
例えば、ネットワークが端末に周期的なビーム管理又はモニタリングのためにＮ個のＣＳＩ−ＲＳリソースを設定することができる。
【０３３０】
しかし、端末は、Ｎ個のＣＳＩ−ＲＳリソースだけでなく（さらに広いカバレッジを有する）Ｍ個のビームフォーミングされたＳＳブロックから信号の品質を測定することができる。従って、ある端末は、設定されたＮ個のＣＳＩ−ＲＳのうちからは代替ビームがないが、Ｍ個のＳＳブロックのうちからは代替ビーム、即ち、特定品質以上の信号を見つけることもできる。しかし、このような場合、ＳＳブロックは、セル特定的（ｃｅｌｌ−ｓｐｅｃｉｆｉｃ）であり、周期的な属性を有するので、要求に応じて端末特定的に（ＵＥ−ｓｐｅｃｉｆｉｃ）送信すべき前記記述した（非周期的）ビームＲＳ範疇に含むには適さない。従って、このような場合は、代替ＳＳブロックビームがあっても（非周期的）ビームＲＳ（例えば、ＣＳＩ−ＲＳ）を端末へ送信する後続過程が必要な方法１の範疇と見ることができる。
【０３３１】
図１０は、代替ビームの存在有無によるネットワーク動作の一例を示す。
【０３３２】
具体的に、図１０ａは、方法１を図式化した図である。
【０３３３】
ここで、前記ビームＲＳトリガー及びビーム報告トリガーは、独立にシグナリングされるか、一緒に（ｊｏｉｎｔｌｙ）シグナリングされることができる。
【０３３４】
一例として、ネットワークは１つのＤＣＩを用いてビームＲＳ及びビーム報告を共にトリガーすることができる。
【０３３５】
図１０ａを参照すると、ネットワークは端末へ周期的（Ｐｅｒｉｏｄｉｃ）ビームＲＳをＤＬに送信する。
【０３３６】
以降、前記ネットワークが前記端末からビーム復旧要求を受信した場合、（方法１によって）前記ネットワークは前記端末へ（非周期的）ビームＲＳと（非周期的）ビーム報告を共にトリガーする。
【０３３７】
これによって、前記端末は、基準リソース（ｒｅｆｅｒｅｎｃｅ  ｒｅｓｏｕｒｃｅ）を介して、ビーム測定（ｂｅａｍ  ｍｅａｓｕｒｅｍｅｎｔ）を行い、前記ビーム測定の結果を前記ネットワークに報告する。
【０３３８】
前記基準リソースを決定する具体的な方法については後述することとする。
【０３３９】
（方法２）
【０３４０】
方法２は、代替ＤＬビーム対がある場合のネットワーク動作を示す。
【０３４１】
即ち、方法２は、ネットワークが端末からビーム復旧要求を受信した場合、前記ネットワークは図１０ｂに示されたように、（非周期的）ビーム報告トリガーを行う。
【０３４２】
図１０ｂは、方法２を図式化した図である。
【０３４３】
図１０ｂを参照すると、ネットワークは端末に周期的（Ｐｅｒｉｏｄｉｃ）ビームＲＳをＤＬへ送信する。
【０３４４】
以降、前記ネットワークが前記端末からビーム復旧要求を受信した場合、前記ネットワークは前記端末へ（非周期的）ビーム報告をトリガーする。
【０３４５】
ここで、方法２は方法１と異なり、端末が代替ＤＬビーム対を知っているため、前記ネットワークは該当端末へ（非周期的）ビームＲＳを別に送信しない（又はトリガーしない）。
【０３４６】
これによって、前記端末は基準リソース（ｒｅｆｅｒｅｎｃｅ  ｒｅｓｏｕｒｃｅ）を介してビーム測定（ｂｅａｍ  ｍｅａｓｕｒｅｍｅｎｔ）を行い、前記ビーム測定の結果を前記ネットワークに報告する。
【０３４７】
ここで、前記ビーム報告の過程で好まれる送信ビーム指示子（ｐｒｅｆｅｒｒｅｄ  Ｔｘ  ｂｅａｍ  Ｉｎｄｉｃａｔｏｒ）とビーム品質メトリック（Ｂｅａｍ  ｑｕａｌｉｔｙ  ｍｅｔｒｉｃ）とが共に送信されることができる。これに対する具体的な説明は、後述することとする。
【０３４８】
見てきたように、方法２は、端末が既設定されたＲＳを介して測定したチャネルから代替できるＤＬ  Ｔｘビーム（又はＤＬビーム対）情報を知っているとき、ネットワークのビームＲＳ送信と端末のビームＲＳ受信を省略し得るので、有用な方式である。
【０３４９】
これに対して、前記で見た方法１は、代替ビームがないか、基地局が代替ビームの有無に対する情報を知ることができないとき、有用な方式である。
【０３５０】
また、前記方法１及び方法２に対して（ビーム）報告セッティングが区別されないことがある。
【０３５１】
即ち、方法１及び方法２で、ビーム報告は同じフィードバックの情報を構成し、端末の同じ時間領域行動（ｔｉｍｅ  ｄｏｍａｉｎ  ｂｅｈａｖｉｏｒ）（例えば、非周期的報告）を有し、同じ周波数側細分性（ｇｒａｎｕｌａｒｉｔｙ）を有することができる。
【０３５２】
前記同じフィードバックの情報は、例えば、好まれるＤＬ送信ビーム指示子（ｐｒｅｆｅｒｒｅｄ  ＤＬ  Ｔｘ  ｂｅａｍ  ｉｎｄｉｃａｔｏｒ（ｓ））及びビーム品質メトリック（ｂｅａｍ  ｑｕａｌｉｔｙ  ｍｅｔｒｉｃ（ｓ））を含むことができる。
【０３５３】
前記好まれるＤＬ送信ビーム指示子は、例えば、ビームＩＤ、ＣＲＩ（ＣＳＩ−ＲＳ  Ｒｅｓｏｕｒｃｅ  Ｉｎｄｉｃａｔｏｒ）、ＲＳポートインデックス等であってもよい。
【０３５４】
前記ビーム品質メトリックは、例えば、Ｌ１  ＲＳＲＰ、ＣＱＩ等であってもよい。
【０３５５】
ビーム復旧方法で、ネットワークはＲＲＣシグナリングを介して、端末に次のうち少なくとも１つの設定方式をサポートすることができる。
【０３５６】
図１１は、ビーム関連の設定方法の一例を示した図である。
【０３５７】
（設定方法１）
【０３５８】
図１１ａを参照すると、報告セッティング（Ｒｅｐｏｒｔｉｎｇ  ｓｅｔｔｉｎｇ）は、１つの非周期的ＣＳＩ／ビーム報告セッティングを含み、リソースセッティング（Ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）は１つの非周期的ビームＲＳセッティング（例えば、ＣＳＩ−ＲＳ）と１つの周期的／半固定的ビームＲＳセッティングを含むことができる。
【０３５９】
ここで、複数の報告セッティングは、報告セッティング等で表現されることができ、複数のリソースセッティングは、リソースセッティング等で表現されることができる。
【０３６０】
また、リソースセッティングは、１つ以上のリソースセットを含むことができる。
【０３６１】
図１１ａを参照すると、測定セッティング（Ｍｅａｓｕｒｅｍｅｎｔ  ｓｅｔｔｉｎｇ）で１つの報告セッティングと二つのリソースセッティングがそれぞれリンク（又はチャネル）で連結されることを見ることができる。
【０３６２】
（設定方法２）
【０３６３】
図１１ｂを参照すると、報告セッティング（Ｒｅｐｏｒｔｉｎｇ  ｓｅｔｔｉｎｇ）は、１つの非周期的ＣＳＩ／ビーム報告セッティングを含み、リソースセッティング（Ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）は１つのビームＲＳセッティングを含み、前記ビームＲＳセッティングは、下記のように少なくとも二つのリソースセットを含む。
【０３６４】
−非周期的ビームＲＳを有するリソースセット（Ｒｅｓｏｕｒｃｅ  ｓｅｔ  ｗｉｔｈ  ａｐｅｒｉｏｄｉｃ  ｂｅａｍ  ＲＳ（ｓ））（例えば、ＣＳＩ−ＲＳ）
【０３６５】
−周期的／半固定的ビームＲＳを有するリソースセット（Ｒｅｓｏｕｒｃｅ  ｓｅｔ  ｗｉｔｈ  ｐｅｒｉｏｄｉｃ／ｓｅｍｉ−ｐｅｒｓｉｓｔｅｎｔ  ｂｅａｍ  ＲＳ（ｓ））（例えば、ＣＳＩ−ＲＳ）
【０３６６】
また、前記二つのセッティング（報告セッティング、リソースセッティング）は、測定セッティング（Ｍｅａｓｕｒｅｍｅｎｔ  ｓｅｔｔｉｎｇ）内の１つのリンク（又はチャネル）で連結される。
【０３６７】
前記で見たように、設定方法１は、時間−領域行動（ｔｉｍｅ−ｄｏｍａｉｎ  ｂｅｈａｖｉｏｒ）（非周期的、半固定的（ＳＰ）、周期的）がリソースセッティング（Ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）単位で共通設定されるときに有用である。
【０３６８】
また、設定方法２は、時間−領域行動（ｔｉｍｅ−ｄｏｍａｉｎ  ｂｅｈａｖｉｏｒ）がリソースセッティング（Ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）内のリソースセット（ｒｅｓｏｕｒｃｅ  ｓｅｔ）単位で共通設定されるときに有用であり得る。
【０３６９】
次に、端末が前記で見た方法１と方法２のうちどの方法を好むかに対する情報又は既測定されたＲＳから代替ビームの存在有無（又は測定値存在の有無）に対する情報をネットワーク（又は基地局）に知らせる方法について具体的に見る。
【０３７０】
前記端末がネットワークへ送信するどんな方法を好むかに対する情報又は代替ビームの有無に対する情報を以下「制御情報」と表現することとする。
【０３７１】
ここで、前記制御情報は、ビーム復旧要求（ｂｅａｍ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）の信号又はビーム失敗報告（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｐｏｒｔｉｎｇ）の信号に含まれることができる。
【０３７２】
前記制御情報は代替ビームの存在有無を直接的に指示する指示子又は指示情報であるか、予め設定された非周期的ビーム報告セッティング（ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄ  ａｐｅｒｉｏｄｉｃ  ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ  ｓｅｔｔｉｎｇ）に関連した（ａｓｓｏｃｉａｔｅｄ）好まれたリンク情報（設定方法１の場合）、好まれたリソースセッティング情報（設定方法１の場合）、或いは好まれたリソースセット情報（設定方法２の場合）であり得る。
【０３７３】
前記制御情報は、ＬＴＥシステムでのＵＣＩ（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）のように物理層の制御情報としてネットワークに伝達されてもよく、上位層のメッセージ形態（例えば、ＭＡＣ  ＣＥ）で伝達されてもよい。
【０３７４】
特に、端末は、前記制御情報をＰＲＡＣＨと同じリソース（例：シンボル）を用いて送信することができる。
【０３７５】
前記端末が前記ＰＲＡＣＨとＣＤＭ（Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）されるか、ＦＤＭ（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）された信号をビーム復旧要求の信号として使用（又は送信）する場合、代替ビームの存在有無によってＰＲＡＣＨで使用されるシーケンスセット（ｓｅｑｕｅｎｃｅ  ｓｅｔ）を分けて使用することができる。
【０３７６】
例えば、ＰＲＡＣＨで使用されるシーケンスセットを分けて使用する場合、分離されたルートインデックス（ｓｅｐａｒａｔｅｄ  ｒｏｏｔ  ｉｎｄｅｘ（ｅｓ））又はサイクリックシフト値（ｃｙｃｌｉｃ  ｓｈｉｆｔ  ｖａｌｕｅｓ）等が使用されることができる。
【０３７７】
或いは、前記端末が前記ＰＲＡＣＨとＣＤＭされるか、ＦＤＭされた信号をビーム復旧要求の信号として使用する場合、前記ＰＲＡＣＨで使用されるシーケンスセットと同じシーケンスセットを使用することができる。但し、この場合、ＰＲＡＣＨであるか、又はビーム復旧要求の信号であるかは、互いに異なる時間領域／周波数領域ＯＣＣ（Ｏｒｔｈｏｇｏｎａｌ  Ｃｏｖｅｒ  Ｃｏｄｅ）を適用して区別することができる。
【０３７８】
また、ネットワーク（又は基地局）は、上位層のメッセージであるＭＡＣ  ＣＥ（ｃｏｎｔｒｏｌ  ｅｌｅｍｅｎｔ）及び／又は物理層のメッセージであるＤＣＩ（Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）に非周期的報告トリガリング（ａｐｅｒｉｏｄｉｃ  ｒｅｐｏｒｔｉｎｇ  ｔｒｉｇｇｅｒｉｎｇ）を端末へ指示するとき、下記情報（（１）乃至（４））のうち少なくとも１つを含むことができる。
【０３７９】
（１）予め関連したセッティング内有効／有効ではないリンク（Ｖａｌｉｄ／ｉｎｖａｌｉｄ  Ｌｉｎｋ  ｗｉｔｈｉｎ  ｔｈｅ  ｐｒｅ−ａｓｓｏｃｉａｔｅｄ  ｓｅｔｔｉｎｇｓ）に対する情報（設定方法１の場合）
【０３８０】
：端末は測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ  ｓｅｔｔｉｎｇ）で予め関連した（ｐｒｅ−ａｓｓｏｃｉａｔｅｄ）複数のリソースセッティングのうち、有効なリンク（ｖａｌｉｄ  ｌｉｎｋ）に指示される（又は有効ではないリンク（ｉｎｖａｌｉｄ  ｌｉｎｋ）に指示されない）リソースセッティングに含まれたＲＳのみを基準リソース（ｒｅｆｅｒｅｎｃｅ  ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定と前記ビーム測定に対するビーム報告（ビーム測定及びビーム報告）を行う。
【０３８１】
（２）予め関連したセッティング内有効／有効ではないリソースセッティング（Ｖａｌｉｄ／ｉｎｖａｌｉｄ  Ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ  ｗｉｔｈｉｎ  ｔｈｅ  ｐｒｅ−ａｓｓｏｃｉａｔｅｄ  ｓｅｔｔｉｎｇｓ）に対する情報（設定方法２の場合）
【０３８２】
：端末は、測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ  ｓｅｔｔｉｎｇ）で予め関連した（ｐｒｅ−ａｓｓｏｃｉａｔｅｄ）複数のリソースセッティングのうち、有効なリソースセッティングに含まれた（又は有効ではないリソースセッティングに含まれない）ＲＳのみを基準リソース（ｒｅｆｅｒｅｎｃｅ  ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定及びビーム報告を行う。
【０３８３】
（３）予め関連したリソースセッティング内に有効／有効ではないリソースセットに対する情報（設定方法２の場合）
【０３８４】
：端末は、測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ  ｓｅｔｔｉｎｇ）で予め関連したリソースセッティング（ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）内で有効なリソースセット（ｖａｌｉｄ  ｒｅｓｏｕｒｃｅ  ｓｅｔ）に含まれたＲＳのみを基準リソース（ｒｅｆｅｒｅｎｃｅ  ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定とビーム報告を行う。
【０３８５】
（４）報告タイプ／モード（Ｒｅｐｏｒｔｉｎｇ  ｔｙｐｅ／ｍｏｄｅ）設定情報（設定方法１及び設定方法２に全て適用）
【０３８６】
：報告タイプ／モード設定情報は非周期的リソースのトリガリングと非周期的報告のトリガリングが共に指示されるか、それとも非周期的報告トリガリングのみ指示されるかに対する指示子又は指示情報を示す。
【０３８７】
ここで、非周期的リソースのトリガリングと非周期的報告のトリガリングが共に指示される場合の報告タイプ又はモードは、共同トリガリングモード又は第１モードで表現されることができ、非周期的報告トリガリングのみ指示される場合の報告タイプ又はモードは、報告トリガリング専用モード（ｒｅｐｏｒｔｉｎｇ  ｔｒｉｇｇｅｒｉｎｇ  ｏｎｌｙ  ｍｏｄｅ）又は第２モードで表現されることができる。
【０３８８】
前記共同トリガリングモード（又は第１モード）である場合、端末はＲＲＣに設定されたリソースセッティング（ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）（設定方法１）又はリソースセット（ｒｅｓｏｕｒｃｅ  ｓｅｔ）（設定方法２）のうち、非周期的リソースセッティング／リソースセット（ａｐｅｒｉｏｄｉｃ  ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ／ｒｅｓｏｕｒｃｅ  ｓｅｔ）のみを基準リソース（ｒｅｆｅｒｅｎｃｅ  ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定及びビーム報告を行う。
【０３８９】
即ち、端末は非周期的報告（ａｐｅｒｉｏｄｉｃ  ｒｅｐｏｒｔｉｎｇ）と連結設定された周期的リソース／半固定的リソースを無視する。
【０３９０】
また、報告トリガリング専用モード（又は第２モード）である場合、端末はＲＲＣに設定されたリソースセッティング（ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）（設定方法１）／リソースセット（ｒｅｓｏｕｒｃｅ  ｓｅｔ）（設定方法２）のうち、周期的（ｐｅｒｉｏｄｉｃ）又は半固定的（ｓｅｍｉ−ｐｅｒｓｉｓｔｅｎｔ）リソースセッティング／リソースセットのみを基準リソース（ｒｅｆｅｒｅｎｃｅ  ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定及びビーム報告を行う。
【０３９１】
即ち、端末は非周期的報告（ａｐｅｒｉｏｄｉｃ  ｒｅｐｏｒｔｉｎｇ）と連結設定された非周期的リソース（ａｐｅｒｉｏｄｉｃ  ｒｅｓｏｕｒｃｅ）を無視する。
【０３９２】
さらに、端末が基地局へ方法１と方法２のうちどの方法を好むかに対する情報又は既測定されたＲＳから代替ビームの存在有無（又は測定値存在の有無）に対する情報を報告した場合、基地局は端末の報告情報に対する適用可否を示す情報（確認メッセージ又はＡＣＫ／ＮＡＣＫ）を端末へ送信することができる。
【０３９３】
前記端末の報告情報が前記で見た基地局の非周期的報告トリガリング（ａｐｅｒｉｏｄｉｃ  ｒｅｐｏｒｔｉｎｇ  ｔｒｉｇｇｅｒｉｎｇ）を指示する前に基地局へ送信された場合、前記端末の報告情報に対する適用可否を示す情報は、前記の（１）乃至（４）の情報と共に基地局の非周期的報告トリガリングを指示するときに送信されることもできる。
【０３９４】
端末が基地局へ方法１と方法２のうちどの方法を好むかに対する情報又は既測定されたＲＳから代替ビームの存在有無（又は測定値存在の有無）に対する情報を送信する場合、基地局は該当端末へ該当情報の受信及び適用を確定する情報を送信することができる。
【０３９５】
例えば、基地局が確認（ｃｏｎｆｉｒｍｅｄ）（又はＡＣＫ）メッセージを端末へ送信した場合、これは、端末が送信した情報を基地局で適用することを確定することを示す。
【０３９６】
或いは、基地局が確認メッセージを送信しないか、未確認（ｎｏｔ−ｃｏｎｆｉｒｍｅｄ）（又はＮＡＣＫ）メッセージを端末へ送信した場合、前記基地局は、前記で見た（１）乃至（４）の情報のうち、一部情報をさらに送信するように端末に要求するか、該当端末にとって方法１と方法２のうちどの方法を好むかに対する情報又は代替ビームの有無（或いは測定値存在の有無）に対する情報を再送信するようにすることができる。
【０３９７】
前記で見たように、前記方法１と方法２のうちどの方法を好むかに対する情報又は代替ビームの存在有無（或いは測定値存在の有無）に対する情報は、簡単に「制御情報」と呼ばれ得る。
【０３９８】
また、前記で見た（１）乃至（４）の情報は、端末が方法１と方法２のうちどの方法を好むかに対する情報又は代替ビームの存在有無（或いは測定値存在の有無）に対する情報を基地局に（先に）報告した場合、省略されることもある。
【０３９９】
次に、端末がビーム測定及びビーム報告のために基準リソースを決定（又は判断）する方法について見ることとする。
【０４００】
端末はビーム復旧要求（ｂｅａｍ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）の信号（又はビーム失敗報告信号）に（ｉ）代替ビームに対する測定値がある（又は方法２を好む）という情報を基地局へ明示的又は暗示的に（ｅｘｐｌｉｃｉｔ又はｉｍｐｌｉｃｉｔ）報告する。
【０４０１】
以降、前記端末が（特定時間以内に、又は特定タイマー満了前に）基地局から非周期的ビーム報告トリガリング（ａｐｅｒｉｏｄｉｃ  ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ  ｔｒｉｇｇｅｒｉｎｇ）の指示を受けた場合、前記端末は、該当非周期的ビーム報告に連結されたリソースセッティング（設定方法１）／リソースセット（設定方法２）に含まれたリソース（ＲＳ）のうち、報告トリガリングメッセージを受信したスロット（ｓｌｏｔ）以前に活性化（又はトリガー又は設定）されて測定（ｍｅａｓｕｒｅｍｅｎｔ）が可能なリソース（例：周期的ＲＳ、活性化された半固定的ＲＳ、又は予めトリガーされた非周期的ＲＳ）を基準リソース（ｒｅｆｅｒｅｎｃｅ  ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定及びビーム報告を行うことができる。
【０４０２】
即ち、前記基準リソースは、前記報告トリガリングメッセージを受信したスロット以前に活性化された特定リソースで決定される。
【０４０３】
これに関する内容は、方法２を説明した図１０ｂを参照することとする。
【０４０４】
また別の一例として、端末がビーム復旧要求信号（又はビーム失敗報告信号）に（ｉｉ）代替ビームに対する測定値がない（又は方法１を好む）という情報を明示的又は暗示的に基地局に報告する。
【０４０５】
以降、前記端末が（特定時間以内に又は特定タイマー満了前に）基地局から非周期的ビーム報告トリガリングの指示を受けた場合、前記端末は、該当非周期的ビーム報告に関連したリソースセッティング（設定方法１）／リソースセット（設定方法２）に含まれたリソース（ＲＳ）のうち、報告トリガリングメッセージを受信したスロットと同じスロット（例えば、一緒にトリガーされた非周期的ＲＳ）又は以降の時点に活性化（又はトリガー又は設定）されるリソース（例：ｔｒｉｇｇｅｒｅｄ／ａｃｔｉｖａｔｅｄ  ａｐｅｒｉｏｄｉｃ  ＲＳ  ｉｎ  ｌａｔｅｒ  ｓｌｏｔ（ｓ））を参照リソース（ｒｅｆｅｒｅｎｃｅ  ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定及びビーム報告を行うことができる。これに関する内容は、方法１を説明した図１０ａを参照することとする。
【０４０６】
即ち、前記基準リソースは、前記報告トリガリングメッセージを受信したスロットと同じスロット又は前記報告トリガリングメッセージを受信した以降、スロットに活性化される特定リソースで決定される。
【０４０７】
図１２は、ビーム復旧を行う方法の一例を示したフローチャートである。
【０４０８】
まず、端末はビーム管理（ｂｅａｍ  ｍａｎａｇｅｍｅｎｔ）に使用されるビーム基準信号（ｂｅａｍ  ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ：ＢＲＳ）を基地局から受信する（Ｓ１２１０）。
【０４０９】
以降、前記端末は、ビーム失敗イベント（ｂｅａｍ  ｆａｉｌｕｒｅ  ｅｖｅｎｔ）が検出された場合、ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）のための制御信号を前記基地局に送信する（Ｓ１２２０）。
【０４１０】
前記ビーム失敗イベントは、前記受信されたビーム基準信号に基づいて検出されることができる。
【０４１１】
前記制御信号は、代替ビームが存在するか否かを示す指示情報を含む。
【０４１２】
前記で見たように、前記代替ビームは、前記ビーム管理のために設定された基準信号のうち、特定チャネルの品質よりも大きいチャネルの品質を有する基準信号を意味することができる。
【０４１３】
以降、前記端末はビーム報告（ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ）がトリガーされた（ｔｒｉｇｇｅｒｅｄ）場合、特定リソースでビーム測定の結果を前記基地局に報告（ｒｅｐｏｒｔ）する（Ｓ１２３０）。
【０４１４】
前記制御信号は、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）と同じ時間リソースを使用することができる。
【０４１５】
この場合、前記制御信号は、前記ＰＲＡＣＨと前記時間リソースでＣＤＭ（Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）又はＦＤＭ（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）されることができる。
【０４１６】
前記制御信号は、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）を介して送信されることができる。
【０４１７】
前記制御信号は、前記代替ビームの存在有無によって互いに異なる時間及び／又は周波数リソース、互いに異なるシーケンスセット（ｓｅｑｕｅｎｃｅ  ｓｅｔ）、及び／又は互いに異なるＵＣＩ（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）を使用することができる。
【０４１８】
この場合、前記互いに異なるシーケンスセットは、ルートシーケンスインデックス（ｒｏｏｔ  ｓｅｑｕｅｎｃｅ  ｉｎｄｅｘ）又はサイクリックシフト値（ｃｙｃｌｉｃ  ｓｈｉｆｔ  ｖａｌｕｅ）によって区別されることができる。
【０４１９】
また、前記指示情報は、予め設定された非周期的ビーム報告セッティング（ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ  ｓｅｔｔｉｎｇ）に関連した（ａｓｓｏｃｉａｔｅｄ）好まれるリンクに対する情報、予め設定された非周期的ビーム報告セッティングに関連した好まれるリソースセッティング（ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）に対する情報又は予め設定された非周期的ビーム報告セッティングに関連した好まれるリソースセット（ｒｅｓｏｕｒｃｅ  ｓｅｔ）に対する情報であり得る。
【０４２０】
さらに、前記端末は、前記ビーム報告のトリガリング（ｔｒｉｇｇｅｒｉｎｇ）を指示する指示メッセージを前記基地局から受信することができる。
【０４２１】
ここで、前記ビーム報告は、前記指示メッセージに基づいてトリガーされることができる。
【０４２２】
前記指示メッセージは、測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ  ｓｅｔｔｉｎｇ）に予め関連した（ｐｒｅ−ａｓｓｏｃｉａｔｅｄ）セッティング内で有効（ｖａｌｉｄ）又は有効ではない（ｉｎｖａｌｉｄ）リンクと関連した情報、前記測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ  ｓｅｔｔｉｎｇ）に予め関連した（ｐｒｅ−ａｓｓｏｃｉａｔｅｄ）セッティング内で有効又は有効ではないリソースセッティング（ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）と関連した情報、前記測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ  ｓｅｔｔｉｎｇ）に予め関連した（ｐｒｅ−ａｓｓｏｃｉａｔｅｄ）セッティング内で有効又は有効ではないリソースセット（ｒｅｓｏｕｒｃｅ  ｓｅｔ）と関連した情報又はビーム報告モード設定情報のうち少なくとも１つを含むことができる。
【０４２３】
前記測定セッティングは、１つの報告セッティングと二つのリソースセッティングがそれぞれリンク（ｌｉｎｋ）で連結されるか、又は１つの報告セッティングと１つのリソースセッティングがリンクで連結されることができる。
【０４２４】
前記ビーム報告モード設定情報は、非周期的ビーム基準信号の送信と非周期的ビーム報告が共にトリガーされる第１モード又は非周期的ビーム報告のみトリガーされる第２モードを指示することができる。
【０４２５】
前記第１モードは、前記で見た共同トリガリングモードを示し、前記第２モードは、前記で見た報告トリガリング専用モードを示す。
【０４２６】
もし、前記ビーム報告モード設定情報が前記第１モードに設定された場合、前記特定リソースは、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）に設定されたリソースセッティング（ｒｅｓｏｕｒｃｅ  ｓｅｔｔｉｎｇ）又はリソースセット（ｒｅｓｏｕｒｃｅ  ｓｅｔ）のうち、非周期的リソースセッティング又は非周期的リソースセットであり得る。
【０４２７】
この場合、前記特定リソースは、前記指示メッセージを受信したスロットと同じスロット又は前記指示メッセージを受信したスロット以降のビーム測定が可能なように活性化されたリソースであり得る。
【０４２８】
或いは、前記ビーム報告モード設定情報が前記第２モードに設定された場合、前記特定リソースはＲＲＣに設定されたリソースセッティング又はリソースセットのうち、周期的又は半固定的リソースセッティング又はリソースセットであり得る。
【０４２９】
この場合、前記特定リソースは、前記指示メッセージを受信したスロット以前にビーム測定が可能なように活性化されたリソースであり得る。
【０４３０】
さらに、前記端末は、前記基地局から前記報告に対する応答を受信することができる。
【０４３１】
もし、前記応答がＮＡＣＫである場合、前記端末は、前記指示情報又は前記指示メッセージに含まれた情報のうち少なくとも１つを含む情報を前記基地局に再送信することができる。
【０４３２】
以下、ビーム復旧要求（ｂｅａｍ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）を行うＵＬリソースのタイプ（ｔｙｐｅ）及び／又はＵＬリソースの設定によって異なってビーム失敗報告（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｐｏｒｔｉｎｇ）と共にビーム報告情報のうち一部又は全てを共に行う方法について見ることとする。
【０４３３】
前記ビーム復旧要求（ｂｅａｍ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）は、ビーム失敗報告（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｐｏｒｔｉｎｇ）で表現されることもできる。
【０４３４】
前記ビーム報告（ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ）情報は、例えば、好まれるＤＬ送信ビーム指示子（ｐｒｅｆｅｒｒｅｄ  ＤＬ  Ｔｘ  ｂｅａｍ  ｉｎｄｉｃａｔｏｒ（ｓ））、ビーム品質メトリック（ｂｅａｍ  ｑｕａｌｉｔｙ  ｍｅｔｒｉｃ（ｓ））（例えば、Ｌ１  ＲＳＲＰ、ＣＱＩ））等であってもよい。
【０４３５】
前記好まれるＤＬ送信ビーム指示子（ｐｒｅｆｅｒｒｅｄ  ＤＬ  Ｔｘ  ｂｅａｍ  ｉｎｄｉｃａｔｏｒ（ｓ））は、例えば、ビームＩＤ、ＣＲＩ（ＣＳＩ−ＲＳ  Ｒｅｓｏｕｒｃｅ  Ｉｎｄｉｃａｔｏｒ）、ＲＳポートのインデックス、同期信号ブロック（ＳＳＢ）のインデックス、ＰＢＣＨ  ＤＭＲＳのインデックス等であってもよい。
【０４３６】
前記ビーム品質メトリック（ｂｅａｍ  ｑｕａｌｉｔｙ  ｍｅｔｒｉｃ（ｓ））は、例えば、Ｌ１  ＲＳＲＰ、ＣＱＩ等であってもよい。
【０４３７】
もし、前記ビーム報告情報を全て報告する場合、前記で見た（方法２の）設定方法２で基地局の非周期的ビーム報告トリガリング（ａｐｅｒｉｏｄｉｃ  ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ  ｔｒｉｇｇｅｒｉｎｇ）過程と後続する端末のビーム報告（ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ）過程が省略されることができ、これを「設定方法３」と定義することができる。
【０４３８】
また、前記ビーム報告情報を一部報告する方式は、一部の情報のみを報告する方式だけでなく、粗い（ｃｏａｒｓｅ）情報（又はｌｏｗｅｒ  ｇｒａｎｕｌｉｔｙの情報）を送る方式も含む。
【０４３９】
例えば、ビーム失敗報告（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｐｏｒｔｉｎｇ）と共に送信するＬ１  ＲＳＲＰは、後続するビーム報告過程を通じて送信するＬ１  ＲＳＲＰに比べてより少ないビット数を含み（又は割り当て）、より少ない量子レベル（ｑｕａｎｔｉｚａｔｉｏｎ  ｌｅｖｅｌ）を有するように設定することができる。
【０４４０】
或いは、基地局は端末に、以前時点に（ビーム失敗を）報告した報告値に対して差異値を計算及び報告するようにして、（ビーム失敗）報告情報量を減らすようにすることもできる。
【０４４１】
例えば、端末は、異なる（ｄｉｆｆｅｒｅｎｔｉａｌ）ＣＱＩ、異なる（ｄｉｆｆｅｒｅｎｔｉａｌ）ＲＳＲＰをビーム失敗報告と共に送信することができる。
【０４４２】
見てきたように、ＮＲシステムでビーム復旧要求（ＢＲＲ）を送信するリソースは、ＰＲＡＣＨとＣＤＭ（Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）又はＦＤＭ（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）されて、時間リソースを共有するＵＬリソース（以下、「ＵＬタイプＩ」という）と、ＰＲＡＣＨと異なる時間リソースを使用するＵＬリソース（以下、「ＵＬタイプＩＩ」という）が全て使用されることができる。
【０４４３】
前記ＵＬタイプＩは、ＰＲＡＣＨと同じように相対的にＵＬリソースが多いスロットタイプ／設定（例えば、ＵＬスロット、ＵＬドミナントスロット）に設定されることができ、ＵＬタイプＩＩは、ＰＵＣＣＨのようにＵＬリソースが少ないスロットでも設定されることができる。
【０４４４】
前記ＵＬタイプＩは、ビーム復旧要求（又はビーム失敗報告要求）を目的で別に設定されたＰＲＡＣＨプリアンブルであり得る。
【０４４５】
即ち、ビーム復旧要求のためにＰＲＡＣＨが使用されることができ、前記ＰＲＡＣＨは、競合フリー（ｃｏｎｔｅｎｔｉｏｎ−ｆｒｅｅ）（又は非競合（ｎｏｎ−ｃｏｎｔｅｎｔｉｏｎ））ベースのＰＲＡＣＨ又は競合ベースのＰＲＡＣＨであり得る。
【０４４６】
ここで、競合フリー（ｃｏｎｔｅｎｔｉｏｎ−ｆｒｅｅ）ベースのＰＲＡＣＨリソースは、別の競合フリー（ｃｏｎｔｅｎｔｉｏｎ−ｆｒｅｅ）ベースのＰＲＡＣＨリソースとＦＤＭ又はＣＤＭされることができる（同じ時間又は周波数リソースを使用するが、シーケンスは異なる）。
【０４４７】
例えば、前記ＵＬタイプＩは、ビーム失敗報告要求（ＢＦＲＱ）の目的で設定されたＰＲＡＣＨプリアンブル、前記ＵＬタイプＩＩは、短い／長いＰＵＣＣＨリソースであり得る。
【０４４８】
また、端末が前記ＵＬタイプＩＩを使用してＢＦＲＱを送信する場合にのみ、ビーム品質（Ｌ１−ＲＳＲＰ）を報告することができる。
【０４４９】
ＮＲシステムで、ＰＵＣＣＨは２種類（短いＰＵＣＣＨ又は長いＰＵＣＣＨ）に分けられる。
【０４５０】
前記短いＰＵＣＣＨは１〜２シンボルで構成され、スロットの最後に位置することができ、最大数十ビットのＵＣＩ（ｕｐｌｉｎｋ  ｃｏｎｔｒｏｌ  ｉｎｆｏｒｍａｔｉｏｎ）を送信することができる。
【０４５１】
また、前記長いＰＵＣＣＨは、４〜１２シンボル（又は１４シンボル）で構成され、最大数百ビットのＵＣＩを送信することができる。
【０４５２】
前記ＵＬタイプＩＩは、ＰＵＳＣＨを介して送信されるか、又は短い／長いＰＵＣＣＨを介して送信されるか、又は別途に定義されるアップリンクチャネルを介して送信されることができる。
【０４５３】
しかしながら、ビーム失敗（ｂｅａｍ  ｆａｉｌｕｒｅ）状況でのリンク適応（ｌｉｎｋ  ａｄａｐｔａｔｉｏｎ）の問題、ＵＬリソース割り当ての問題等を考慮したとき、前記ＵＬタイプＩＩは、短いＰＵＣＣＨ及び／又は長いＰＵＣＣＨを使用して送信されることがさらに好ましい。
【０４５４】
本明細書で使用される「Ａ及び／又はＢ」は、「Ａ又はＢのうち少なくとも１つを含む」と同じ意味と解釈され得る。
【０４５５】
前記ＵＬタイプＩは、ＰＲＡＣＨと同じ時間リソースを使用するので、基地局は該当信号（ビーム復旧要求の信号）を受信するために（全方向に）受信ビームスイーピング（Ｒｘ  ｂｅａｍ  ｓｗｅｅｐｉｎｇ）を適用すると仮定することができる。
【０４５６】
従って、特定ビームに該当する時間／周波数リソースでのみよい品質で信号が受信されるため、前記ビーム復旧要求の信号は、少ない情報が繰り返して送信される構造を有するように設計されることがより有利である。
【０４５７】
従って、前記ＵＬタイプＩは、前記で見た更なるビーム報告情報（好まれるＤＬ送信ビーム指示子、ビーム品質メトリック）が含まれないか、又はＵＬタイプＩＩよりも少ないビット数で構成されたビーム報告情報のみ含まれるように設定されることが好ましい。
【０４５８】
また、前記ＵＬタイプＩの場合、（方法２の）設定方法３がサポートされない。
【０４５９】
前記ＵＬタイプＩＩの場合、やはりＰＵＣＣＨタイプ（短いＰＵＣＣＨ又は長いＰＵＣＣＨ）及びＰＵＣＣＨリソースのサイズ（シンボルの数及び／又はＰＲＢサイズ）によってサポートされるメカニズム（ｍｅｃｈａｎｉｓｍ）が異なって定義又は設定されることができる。
【０４６０】
例えば、長いＰＵＣＣＨを介して送ることができるビーム情報は、ビーム識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のためのＲＳ指示子だけでなく、該当Ｌ１  ＲＳＲＰを送信することができるが、短いＰＵＣＣＨを介して送ることができるビーム情報は、Ｌ１  ＲＳＲＰが省略されることができる。
【０４６１】
或いは、短いＰＵＣＣＨは、前記更なるビーム報告情報が含まれないように設計又は定義することもできる。
【０４６２】
また、短い／永井PUCCHシンボルの数（の範囲）に応じてサポートされるビーム報告情報が異なって設計されることもできる。
【０４６３】
また、短いＰＵＣＣＨは、早い（ｆａｓｔ）ＡＣＫ／ＮＡＣＫのための目的で設計される側面が強いので、ＲＲＣに半静的（ｓｅｍｉ−ｓｔａｔｉｃ）に割り当て（又は設定）られることは好ましくない。
【０４６４】
従って、前記ＵＬタイプＩＩは、長いＰＵＣＣＨでのみ送信されるようにすることがより好ましい。
【０４６５】
前記で見た説明では、ＵＬタイプＩとＵＬタイプＩＩを差別的に（又はそれぞれ）設計または定義することを仮定したが、統合的な設計やはり可能である。
【０４６６】
以下で、ＵＬタイプＩとＵＬタイプＩＩを統合的に設計する方法について見る。
【０４６７】
基地局は、ビーム失敗報告（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｐｏｒｔｉｎｇ）と共に送信できる情報の特性及び情報量に応じて別途の（複数個の）ＵＬリソースをＲＲＣに設定することができる。
【０４６８】
このとき、周期「Ｎ」（Ｎは自然数）に設定された特定ＵＬリソースは、Ｎ掛け整数倍の周期ではＰＲＡＣＨリソースとＣＤＭまたはＦＤＭされ、残りの時点ではＰＲＡＣＨリソースとＴＤＭされることができる。
【０４６９】
ここで、該当リソースで送信される情報の構成は、報告時点と関係なく同じように構成されることができる。
【０４７０】
代替ビームの有無に対する情報送信方法
【０４７１】
前記で見た代替ビームの有無に対する暗示的／明示的（ｉｍｐｌｉｃｉｔ／ｅｘｐｌｉｃｉｔ）指示（ｉｎｄｉｃａｔｉｏｎ）のフィードバック情報やはり、ＵＬリソースのタイプ及び／又は設定に応じて異なって（または差別的に）ビーム報告情報に含まれるか、またはビーム復旧要求と共に送信されることができる。
【０４７２】
例えば、ＵＬタイプＩの場合、基地局は全方向に信号を受信し、少ないフィードバックペイロード（ｆｅｅｄｂａｃｋ  ｐａｙｌｏａｄ）のみサポートできるので、前記基地局は端末からビーム復旧要求（ｂｅａｍ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）と共に代替ビームの有無を含めて報告を受けることができる（設定方法１及び／又は設定方法２をサポート）。
【０４７３】
また、ＵＬタイプＩＩの場合、基地局は特定方向に信号を受信するので、代替ビームがある場合にのみ使用するように定義し、ビーム復旧要求（ｂｅａｍ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）と共に代替ビームの有無情報は送信しないようにし、ビーム識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のための情報（及びビーム品質情報）を含めて端末が報告するようにすることができる（設定方法２及び／又は設定方法３をサポート）。
【０４７４】
前記ビーム識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）情報は、暗示的な方式で伝達されることもできる。
【０４７５】
これは（チャネル相互関係が成立（またはビーム対応が成立）する端末に対して）ＤＬリソースに対応するＵＬリソースが設定された場合（例えば、ＤＬ  ＲＳリソースｘの品質に優れた端末は、ＵＬリソースｙを使用して信号を送信するようにする形態で）、端末が信号を送信するＵＬリソース情報によって基地局は該当端末に対するＤＬビーム情報を暗示的に取得できる。
【０４７６】
即ち、複数個のＤＬリソース（例えば、同期信号ブロック、ＰＢＣＨ  ＤＭＲＳリソース、ＣＳＩ−ＲＳリソース）のそれぞれに対応する複数個のＵＬリソース（例えば、ＵＬタイプＩまたはＵＬタイプＩＩ）がマッピングされて設定される状況で、端末が一個又は複数個のＵＬリソースを選択して信号を送信することによって、基地局は暗示的にどのＤＬリソースに対応するＤＬ  Ｔｘビームが（代替ビームとして）品質に優れるかを識別することができる。
【０４７７】
図１３及び図１４は、ビーム復旧を行う端末の動作の一例を示したフローチャートである。
【０４７８】
図１４に関する説明は、図１３と同じ部分は図１３を参照し、差のある部分のみ別に表示して見ることとする。
【０４７９】
まず、端末は、ビーム管理（ｂｅａｍ  ｍａｎａｇｅｍｅｎｔ）に使用されるビーム基準信号（ｂｅａｍ  ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）を基地局から受信する（Ｓ１３１０）。
【０４８０】
以降、前記端末は、ビーム失敗イベント（ｂｅａｍ  ｆａｉｌｕｒｅ  ｅｖｅｎｔ）が検出された場合、ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）と関連した制御信号を送信するためのＵＬ（ｕｐｌｉｎｋ）リソースを決定する（Ｓ１３２０）。
【０４８１】
ここで、前記ＵＬリソースは、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）と同じ時間リソースを使用するタイプ１のリソース、又は前記ＰＲＡＣＨと互いに異なる時間リソースを使用するタイプ２のリソースであり得る。
【０４８２】
また、前記タイプ１のリソースは、前記ＰＲＡＣＨとＦＤＭ（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）及び／又はＣＤＭ（Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）されることができる。
【０４８３】
また、前記タイプ２のリソースは、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）リソース又はＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）リソースであってもよい。
【０４８４】
もし、前記タイプ２のリソースがＰＵＣＣＨリソースである場合、前記ＰＵＣＣＨリソースは短いＰＵＣＣＨ又は長いＰＵＣＣＨのうち少なくとも１つであってもよい。
【０４８５】
以降、前記端末は、前記決定されたＵＬリソースで前記制御信号を前記基地局に送信する（Ｓ１３３０）。
【０４８６】
ここで、前記制御信号は、ビーム報告と関連した情報の一部又は全てを含むか、又は前記ビーム報告と関連した情報を含まないことがある。
【０４８７】
もし、前記ＵＬリソースがタイプ１のリソースである場合、前記制御信号は、前記ビーム報告と関連した情報の一部のみ含み、前記ビーム報告と関連した情報は、代替ビームの有無に対する情報を含むことができる。
【０４８８】
前記代替ビームは、前記ビーム管理のために設定された基準信号のうち、特定チャネルの品質よりも大きいチャネル品質を有する基準信号を意味することができる。
【０４８９】
もし、前記ＵＬリソースがタイプ２のリソースである場合、前記制御信号は、前記ビーム報告と関連した情報の全てを含むことができる。
【０４９０】
この場合、前記ビーム報告と関連した情報は、ビーム識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のためのビーム識別情報又はビーム品質（ｑｕａｌｉｔｙ）を示すビーム品質情報のうち少なくとも１つを含むことができる。
【０４９１】
さらに、前記制御信号が前記ビーム報告と関連した情報の一部を含む場合、端末は特定リソースでビーム測定の結果を前記基地局に報告（ｒｅｐｏｒｔ）する（Ｓ１４４０）。  ここで、前記ビーム測定の結果に対する報告は、ビーム報告（ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ）がトリガーされた（ｔｒｉｇｇｅｒｅｄ）場合に行われることができる。
【０４９２】
図１４のＳ１４１０乃至Ｓ１４３０は、図１３のＳ１３１０乃至Ｓ１３３０の段階と同一である。
【０４９３】
図１５は、ビーム失敗復旧手続の一例を示したフローチャートである。
【０４９４】
ＢＦＲ手続は、（１）ビーム失敗検出（Ｂｅａｍ  ｆａｉｌｕｒｅ  ｄｅｔｅｃｔｉｏｎ）ステップ（Ｓ１５１０）、（２）新しいビーム識別（Ｎｅｗ  ｂｅａｍ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）ステップ（Ｓ１５２０）、（３）ビーム失敗復旧要求（Ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ：ＢＦＲＱ）ステップ（Ｓ１５３０）及び（４）基地局からＢＦＲＱに対する応答（ｒｅｓｐｏｎｓｅ）をモニターするステップ（Ｓ１５４０）を含む。
【０４９５】
ここで、Ｓ１５３０ステップ、すなわち、ＢＦＲＱ送信のために、ＰＲＡＣＨプリアンブル（ｐｒｅａｍｂｌｅ）又はＰＵＣＣＨが使用できる。
【０４９６】
前記Ｓ１５１０ステップ、すなわち、ビーム失敗検出（Ｂｅａｍ  ｆａｉｌｕｒｅ  ｄｅｔｅｃｔｉｏｎ）についてより具体的に説明する。
【０４９７】
全てのサービングビーム（ｓｅｒｖｉｎｇ  ｂｅａｍ）のＢＬＥＲ（ｂｌｏｃｋ  ｅｒｒｏｒ  ｒａｔｅ）が臨界値以上であるとき、ビーム失敗インスタンス（ｂｅａｍ  ｆａｉｌｕｒｅ  ｉｎｓｔａｎｃｅ）と呼ばれる。
【０４９８】
端末がモニターするＲＳ（ｑｏ）はＲＲＣにより明示的に設定されるか又は暗示的に制御チャネル（ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）のためのビームＲＳにより決定される。
【０４９９】
上位層へのビーム失敗インスタンス（ｂｅａｍ  ｆａｉｌｕｒｅ  ｉｎｓｔａｎｃｅ）の指示（ｉｎｄｉｃａｔｉｏｎ）は周期的（ｐｅｒｉｏｄｉｃ）であり、指示間隔（ｉｎｄｉｃａｔｉｏｎ  ｉｎｔｅｒｖａｌ）はＢＦＤ（ｂｅａｍ  ｆａｉｌｕｒｅ  ｄｅｔｅｃｔｉｏｎ）  ＲＳの最も低い周期により決定される。
【０５００】
もし、評価（ｅｖａｌｕａｔｉｏｎ）がビーム失敗インスタンスＢＬＥＲ臨界値（ｂｅａｍ  ｆａｉｌｕｒｅ  ｉｎｓｔａｎｃｅ  ＢＬＥＲ  ｔｈｒｅｓｈｏｌｄ）より低いとき、上位層への指示は行われない。
【０５０１】
Ｎ個の連続的なビーム失敗インスタンスが発生する場合、ビーム失敗が宣言（ｄｅｃｌａｒｅ）される。
【０５０２】
ここで、ＮはＲＲＣにより設定されるＮｒｏｆＢｅａｍＦａｉｌｕｒｅＩｎｓｔａｎｃｅパラメータである。
【０５０３】
１−ｐｏｒｔ  ＣＳＩ−ＲＳ及びＳＳＢがＢＦＤ  ＲＳセットに対してサポートされる。
【０５０４】
次に、Ｓ１５２０ステップ、すなわち、新しいビーム指示（ｎｅｗ  ｂｅａｍ  ｉｎｄｉｃａｔｉｏｎ）について説明する。
【０５０５】
ネットワーク（ＮＷ）は、１つ又は多数のＰＲＡＣＨリソース／シーケンスを端末に設定することができる。
【０５０６】
ＰＲＡＣＨシーケンス（ｓｅｑｕｅｎｃｅ）は、少なくとも１つの新しい候補ビーム（ｃａｎｄｉｄａｔｅ  ｂｅａｍ）にマッピングされる。
【０５０７】
端末は、Ｌ１−ＲＳＲＰがＲＲＣと設定された臨界値（ｔｈｒｅｓｈｏｌｄ）以上である候補ビーム（ｃａｎｄｉｄａｔｅ  ｂｅａｍ）の間で新しいビームを選択し、前記選択されたビームを介してＰＲＡＣＨを送信する。ここで、端末がどのビームを選択するかは端末実現イシューであり得る。
【０５０８】
次に、Ｓ１５３０及びＳ１５３０ステップ、すなわち、ＢＦＲＱ送信及びＢＦＲＱに対する応答のモニタリングについて説明する。
【０５０９】
端末は、ウィンドウ（Ｗｉｎｄｏｗ）の時間持続区間（ｔｉｍｅ  ｄｕｒａｔｉｏｎ）及びＢＦＲＱに対する基地局の応答をモニターするために、ＲＲＣにより専用（ｄｅｄｉｃａｔｅｄ）ＣＯＲＥＳＥＴが設定されることができる。
【０５１０】
端末は、ＰＲＡＣＨ送信の４スロット後にモニタリングを開始する。
【０５１１】
端末は、専用ＣＯＲＥＳＥＴがビーム失態復旧要求(ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ)においてＵＥ−識別された候補ビーム（ｃａｎｄｉｄａｔｅ  ｂｅａｍ）のＤＬ  ＲＳと空間（ｓｐａｔｉａｌ）ＱＣＬされていると仮定する。
【０５１２】
もし、タイマーが満了するか又はＰＲＡＣＨ送信の個数が最大個数に到達すると、端末はＢＦＲ手続を中断する。
【０５１３】
ここで、ＰＲＡＣＨ送信の最大個数とタイマーはＲＲＣに設定される。
【０５１４】
以下、ＳＳＢ（ＳＳ  ｂｌｏｃｋ）指示（ｉｎｄｉｃａｔｉｏｎ）及びビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）について説明する。
【０５１５】
少なくともサービングセル（ｓｅｒｖｉｎｇ  ｃｅｌｌ）に対するレートマッチング（ｒａｔｅ  ｍａｔｃｈｉｎｇ）目的のために、６ＧＨｚ以下に対して、全体ビットマップ（８ｂｉｔｓ）は実際ＳＳ／ＰＢＣＨブロック送信の指示（ｉｎｄｉｃａｔｉｏｎ）のために使用される。
【０５１６】
全体ビットマップを有するＵＥ−特定（ｓｐｅｃｉｆｉｃ）ＲＲＣシグナリングは、６ＧＨｚ以下（ｓｕｂ−６ＧＨｚ）のケース及び６ＧＨｚ以上（ｏｖｅｒ−６ＧＨｚ）のケースの全てに対して実際に送信されたＳＳブロックを指示するために使用される。
【０５１７】
実際に送信されたＳＳブロックは６ＧＨｚ以下（ｓｕｂ−６ＧＨｚ）のケース及び６ＧＨｚ以上（ｏｖｅｒ−６ＧＨｚ）のケースの全てに対してＲＭＳＩ（ｒｅｍａｉｎｉｎｇ  ｍｉｎｉｍｕｍ  ｓｙｓｔｅｍ  ｉｎｆｏｒｍａｔｉｏｎ）において指示（ｉｎｄｉｃａｔｉｏｎ）される。
【０５１８】
前記指示は、６ＧＨｚ以上で圧縮された形態であり、指示方法は以下の代案から選択される。
【０５１９】
（代案１）：グループ−ビットマップ（Ｇｒｏｕｐ−Ｂｉｔｍａｐ）及びグループ内のビットマップ
【０５２０】
グループは、連続的なＳＳ／ＰＢＣＨブロックで定義される。
【０５２１】
グループ内のビットマップは、どのようばＳＳ／ＰＢＣＨブロックがグループ内において実際に送信されるかを指示することができ、各グループはＳＳ／ＰＢＣＨブロックの同一の送信パターンを有し、グループ−ビットマップはどのようなグループが実際に送信されるかを指示することができる。
【０５２２】
例えば、グループ別８個のグループと８個のＳＳ／ＰＢＣＨブロックの場合、［８］＋［８］ビット。
【０５２３】
（対案２）：グループ−ビットマップ及びグループにおいて実際に送信されるＳＳ／ＰＢＣＨブロックの数（ＳＳ／ＰＢＣＨブロックの固定された開始インデックス）
【０５２４】
グループは、連続するＳＳ／ＰＢＣＨブロックで定義される。
【０５２５】
グループ−ビットマップ（ｇｒｏｕｐ−ｂｉｔｍａｐ）は、どのグループが実際に送信されるか、グループ内のＳＳ／ＰＢＣＨブロックが論理的に連続するかを指示し、実際に送信されるＳＳ／ＰＢＣＨブロックの数はどれだけ多くの論理的に連続するＳＳ／ＰＢＣＨブロックが第１インデックス（ｆｉｒｓｔ  ｉｎｄｅｘ）から開始して実際に送信されるかを指示し、該当個数は送信される全てのグループに共通に適用される。
【０５２６】
例えば、グループ別の８つのグループ及び８つのＳＳ／ＰＢＣＨブロックの場合、［８］＋［３］ビット。
【０５２７】
（対案３）：グループ内のビットマップ及び実際に送信されるグループの数（グループの固定された開始インデックス）
【０５２８】
グループは、連続するＳＳ／ＰＢＣＨブロックで定義される。
【０５２９】
グループ内のビットマップは、当該グループ内においてどのＳＳ／ＰＢＣＨブロックが実際に送信されるかを示し、各グループは、ＳＳ／ＰＢＣＨブロック送信の同一のパターンを有し、実際に送信されたグループの数はどれだけ多くの連続するグループが第１グループから開始して実際に送信されるかを指示する。
【０５３０】
例えば、グループ別の８つのグループ及び８つのＳＳ／ＰＢＣＨブロックの場合、［８］＋［３］ビット。
【０５３１】
（対案４）：グループ−ビットマップ及び各グループにおいて実際に送信されたＳＳ／ＰＢＣＨブロックの数
【０５３２】
グループは、連続するＳＳ／ＰＢＣＨブロックで定義される。
【０５３３】
グループ−ビットマップは、どのグループが実際に送信されるかを、グループ内のＳＳ／ＰＢＣＨブロックが論理的に連続するかを指示することができ、各グループに対して実際に送信されるＳＳ／ＰＢＣＨブロックの数は、どれだけ多くの論理的に連続するＳＳ／ＰＢＣＨブロックが第１インデックス（ｆｉｒｓｔ  ｉｎｄｅｘ）から開始して実際に送信されるかを指示する。
【０５３４】
グループ別の８つのグループ及び８つのＳＳ／ＰＢＣＨブロックの場合、最小［８］＋［３］ビット、最大［８］＋［３］＊［８］ビット。
【０５３５】
（対案５）：実際に送信されるＳＳ／ＰＢＣＨブロックの数、開始インデックス（Ｓｔａｒｔｉｎｇ  ｉｎｄｅｘ）及び２つの連続するＳＳ／ＰＢＣＨブロック間の間隔（ｇａｐ）は［６］＋［６］＋［６］ビット。
【０５３６】
（対案６）：グループビットマップ（ｇｒｏｕｐ−ｂｉｔｍａｐ）
【０５３７】
グループは、連続するＳＳ／ＰＢＣＨブロックで定義される。
【０５３８】
グループ−ビットマップは、どのグループが実際に送信されるか、送信されるグループ内の全てのＳＳ／ＰＢＣＨブロックが実際に送信されるかを指示することができる。
【０５３９】
例えば、グループ別の８つのグループ及び８つのＳＳ／ＰＢＣＨブロックの場合、［８］ビット。
【０５４０】
指示されるリソースは、実際に送信されるＳＳブロックのために予約される。
【０５４１】
データチャネル（Ｄａｔａ  ｃｈａｎｎｅｌ）は実際に送信されるＳＳブロックの周辺においてレートマッチングされる（ｒａｔｅ−ｍａｔｃｈｅｄ）。
【０５４２】
次に、ビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）に関連した内容について説明する。
【０５４３】
ビーム失敗（ｂｅａｍ  ｆａｉｌｕｒｅ）は、全てのサービング（ｓｅｒｖｉｎｇ）制御チャネルが失敗するときにのみ宣言（ｄｅｃｌａｒｅ）される。
【０５４４】
周期的（ｐｅｒｉｏｄｉｃ）ＣＳＩ−ＲＳ以外にも、サービングセル内のＳＳブロックは新しい候補ビーム識別（ｎｅｗ  ｃａｎｄｉｄａｔｅ  ｂｅａｍ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のために使用できる。
【０５４５】
次のオプションは、新しい候補ビーム識別（ｎｅｗ  ｃａｎｄｉｄａｔｅ  ｂｅａｍ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のために設定（ｃｏｎｆｉｇｕｒｅ）されることができる。
【０５４６】
−ＣＳＩ−ＲＳリソースのみ（ＣＳＩ−ＲＳ  ｒｅｓｏｕｒｃｅｓ  ｏｎｌｙ）
【０５４７】
この場合、ＳＳＢは新しい候補ビームの識別のために設定されない。
【０５４８】
−ＳＳブロックリソースのみ（ＳＳ  ｂｌｏｃｋ  ｒｅｓｏｕｒｃｅｓ  ｏｎｌｙ）
【０５４９】
この場合、ＣＳＩ−ＲＳは新しい候補ビーム識別のために設定されない。
【０５５０】
−ＳＳブロックリソースとＣＳＩ−ＲＳリソースの両方（Ｂｏｔｈ  ＳＳ  ｂｌｏｃｋ  ｒｅｓｏｕｒｃｅｓ  ａｎｄ  ＣＳＩ−ＲＳ  ｒｅｓｏｕｒｃｅｓ）
【０５５１】
競合フリー（ｃｏｎｔｅｎｔｉｏｎ−ｆｒｅｅ）のＰＲＡＣＨ（ｐｈｙｓｉｃａｌ  ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｃｈａｎｎｅｌ）上でビーム失敗復旧要求送信（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ  ｔｒａｎｓｍｉｓｓｉｏｎ）に対して、他のＰＲＡＣＨリソースとＣＤＭ（ｃｏｄｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）されるか、ＦＤＭ（ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）される別途のＰＲＡＣＨリソースを用いることがサポートされる。すなわち、基地局は、ＢＦＲの目的で別途の競合フリーのＰＲＡＣＨリソースを設定することができ、端末が該当ＰＲＡＣＨリソースを送信して基地局がこれを受信した場合、該当端末がビーム失敗の状態であることを暗示的に把握することができる。
【０５５２】
ここで、ＣＤＭはＰＲＡＣＨプリアンブル（ｐｒｅａｍｂｌｅ）と同一のシーケンス設計を意味する。
【０５５３】
ビーム失敗復旧要求送信のためのＰＲＡＣＨプリアンブルは、Ｒｅｌ−１５の競合フリー（ｃｏｎｔｅｎｔｉｏｎ−ｆｒｅｅ）のＰＲＡＣＨ動作のためのプリアンブルから選択される。
【０５５４】
次に、ビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）のためのＳＳブロックの用途（ｕｓａｇｅ）及び設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）について説明する。
【０５５５】
以下で使用される「ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）」は同期信号（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ｓｉｇｎａｌ：ＳＳ）、ＳＳブロック、物理チャネル（ｐｈｙｓｉｃａｌ  ｃｈａｎｎｅｌ）などの無線信号を意味し得る。
【０５５６】
また、本明細書において使用される「設定」は、「指示」又は「指定」と同一の意味として解釈されることができる。
【０５５７】
また、本明細書において使用されるＳＳブロック（ｂｌｏｃｋ）は、ＳＳ／ＰＢＣＨブロック（ｂｌｏｃｋ）、ＳＳＢと同一の意味として解釈されることができる。
【０５５８】
新しい候補ビームを識別するためにＣＳＩ−ＲＳだけでなくＳＳブロック（ｂｌｏｃｋ）が使用されることができる。
【０５５９】
ＤＬ  ＲＳ設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）の観点から、ＵＥが新しい候補ビーム、すなわち、現在サービングＤＬＲＳより良い品質のビームを見つけるために検索するＤＬ  ＲＳは、ネットワークにより明示的に設定（ｃｏｎｆｉｇｕｒｅ）されることができる。
【０５６０】
あるＤＬ  ＲＳ品質がビーム対応（ｂｅａｍ  ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ）を有するＵＥに対して特にさらに良い時、また他の必要なＤＬ  ＲＳ設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）は、どのＵＬリソースが使用できるかを指示するものである。あるいは、送信ビームと受信ビーム間の対応がよく一致しない端末であっても（非ビーム対応ＵＥ（ｎｏｎ−ｂｅａｍ  ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ  ＵＥ））、前述したアップリンクビームマネジメント過程により端末がどのようなアップリンクビームを使用したとき、基地局がどのような受信ビームが最適であるかを予め把握することができる。
【０５６１】
従って、特定のダウンリンクビームが優れている場合又は悪い場合、どのようなアップリンクビームを使用してＰＲＡＣＨを送信するかに対して基地局と端末との約束のみすれば、基地局が当該ＰＲＡＣＨに対する受信及び当該ＰＲＡＣＨ受信時に当該端末のどのようなダウンリンクビームが優れているか又は悪いかを把握するのに問題はない。
【０５６２】
ビーム失敗の場合、ＵＥは多数のＢＦＲ（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ  ｒｅｓｏｕｒｃｅ）が設定されることができる。
【０５６３】
ここで、前記ＢＦＲは、ビーム失敗復旧要求に使用されるためにＰＲＡＣＨとＦＤＭ、ＣＤＭ又はＴＤＭされたＵＬリソースをいう。
【０５６４】
ビーム対応（ｂｅａｍ  ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ）を有するＵＥに対して、それぞれのＢＦＲはＰＲＡＣＨと類似してＤＬビーム（ら）と関連（ａｓｓｏｃｉａｔｉｏｎ）し得る。
【０５６５】
その理由は、ＰＲＡＣＨリソースはＳＳブロック又はＣＳＩ−ＲＳと関連し得るためである。
【０５６６】
また、前述したように、非ビーム対応ＵＥ（ｎｏｎ−ｂｅａｍ  ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ  ＵＥ）に対してもそれぞれのＢＦＲはＤＬビーム（ら）に関連し得る。
【０５６７】
それぞれのＢＦＲとＳＳブロック又はＣＳＩ−ＲＳの関連（ａｓｓｏｃｉａｔｉｏｎ）に対するＲＲＣ設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）をサポートすることは非常に自然である。
【０５６８】
結局、ビーム復旧のために、以下のような２つのＤＬ  ＲＳ設定が必要であり得る。
【０５６９】
ＤＬ  ＲＳセット設定１．サービングビームが失敗した場合、端末が見つける新しい候補ＤＬ  ＲＳビームリスト
【０５７０】
ＤＬ  ＲＳセット設定２．特定候補ＤＬ  ＲＳビームが良いとき、どのようなＢＦＲを使うかに対するリスト（各ＢＦＲに関連したＤＬ  ＲＳリソース情報）
【０５７１】
本明細書において提案するビーム失敗復旧方法について説明する前に、ビーム失敗復旧に関連する内容についてまず簡単にまとめる。
【０５７２】
本明細書において記述される「新しいビーム識別のためのＣＳＩ−ＲＳ＋ＳＳＢ」の表現は、新しいビーム識別のためにＣＳＩ−ＲＳとＳＳＢが両方とも使われる場合を意味し得る。
【０５７３】
（１）新しい候補ビーム識別のためにＲＳリソースを設定するためのＲＲＣパラメータがサポートされる。
【０５７４】
ビーム失敗検出（ｂｅａｍ  ｆａｉｌｕｒｅ  ｄｅｔｅｃｔｉｏｎ）は仮想（ｈｙｐｏｔｈｅｔｉｃａｌ）ＰＤＣＣＨ  ＢＬＥＲの品質測定（ｑｕａｌｉｔｙ  ｍｅａｓｕｒｅ）に基づいて決定される。
【０５７５】
（２）Ｂｅａｍ−ｆａｉｌｕｒｅ−ｒｅｃｏｖｅｒｙ−ｒｅｑｕｅｓｔ−ＲＡＣＨ−Ｒｅｓｏｕｒｃｅパラメータがサポートされる。
【０５７６】
ビーム失敗復旧のための専用（ｄｅｄｉｃａｔｅｄ）ＰＲＡＣＨリソースに対するパラメータは以下の通りである。
【０５７７】
−プリアンブルシーケンス関連パラメータ、例えば、ルートシーケンス（ｒｏｏｔ  ｓｅｑｕｅｎｃｅ）、循環シフト（ｃｙｃｌｉｃ  ｓｈｉｆｔ）、及びプリアンブルインデックス（ｐｒｅａｍｂｌｅ  ｉｎｄｅｘ）。
【０５７８】
−最大送信回数
【０５７９】
−最大パワーランピング（ｐｏｗｅｒ  ｒａｍｐｉｎｇ）回数
【０５８０】
−目標受信電力
【０５８１】
−再送信のためのタイマー
【０５８２】
−再送信Ｔｘ電力ランピング段階サイズ
【０５８３】
−ビーム失敗復旧タイマー
【０５８４】
連続して検出されるビーム失敗インスタンス（ｂｅａｍ  ｆａｉｌｕｒｅ  ｉｎｓｔａｎｃｅ）の数が設定された最大数を超過する場合、ビーム復旧要求は送信される。
【０５８５】
もし、仮想のＰＤＣＣＨ  ＢＬＥＲが臨界値以上であると、ビーム失敗インスタンスとしてカウントされる。
【０５８６】
参考として、ビーム失敗は全てのサービングビームが失敗するときに決定される。
【０５８７】
候補ビーム（ｃａｎｄｉｄａｔｅ  ｂｅａｍ）のメトリックＸが臨界値より高い場合、候補ビームは識別される。
【０５８８】
前記臨界値は１つ又は２つであり、もし、臨界値が２つである場合、１つはＳＳＢのためのものであり、他の１つはＣＳＩ−ＲＳのためのものである。
【０５８９】
（３）新しい候補ビーム識別のためにＣＳＩ−ＲＳ＋ＳＳブロックケースがサポートされる。
【０５９０】
前記ケースはｇＮＢにより設定される。
【０５９１】
専用（Ｄｅｄｉｃａｔｅｄ）ＰＲＡＣＨリソースはＳＳＢ又はＣＳＩ−ＲＳリソースとして設定される。
【０５９２】
ＵＥがＣＳＩ−ＲＳ＋ＳＳＢとして新しい候補ビーム識別のために設定されるとき、次の２つのシナリオがサポートされる。
【０５９３】
−シナリオ１：ＰＲＡＣＨはＳＳＢにのみ連結される
【０５９４】
シナリオ１は、新しいビーム識別のためのＣＳＩ−ＲＳリソースがＳＳＢとＱＣＬ連結から発見できる。
【０５９５】
−シナリオ２：多数のＰＲＡＣＨのそれぞれはＳＳＢ又はＣＳＩ−ＲＳリソースと関連する。
【０５９６】
（４）ｇＮＢがＵＥのビーム失敗復旧要求送信においてＵＥ  ＩＤを固有に識別するために、ＰＲＡＣＨシーケンスはＵＥに設定される。
【０５９７】
（５）ｇＮＢ応答はＣ−ＲＮＴＩに向かう（ａｄｄｒｅｓｓｅｄ）ＰＤＣＣＨを介して送信される。
【０５９８】
ｇＮＢ応答のためのＤＣＩフォーマットは追って決定されてもよい。
【０５９９】
ＢＦＲＱに対するｇＮＢ応答をモニターするために専用ＣＯＲＥＳＥＴが適用される。
【０６００】
前記専用ＣＯＲＥＳＥＴは、以下の２つの対案から選択される。
【０６０１】
−代案１（Ａｌｔ１）：以前のビーム失敗と同一のＣＯＲＥＳＥＴ（ら）。
【０６０２】
−代案２（Ａｌｔ２）：ビームエラー復旧のために専用に（ｄｅｄｉｃａｔｅｄｌｙ）設定されたＣＯＲＥＳＥＴ。
【０６０３】
（６）ビーム失敗復旧要求に対するｇＮＢ応答をモニターするために、ＵＥが時間ウインドウ及び専用（ｄｅｄｉｃａｔｅｄ）ＣＯＲＥＳＥＴに対する時間持続区間（ｔｉｍｅ  ｄｕｒａｔｉｏｎ）のＲＲＣ設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）をサポートする。
【０６０４】
ＵＥは、専用（ｄｅｄｉｃａｔｅｄ）ＣＯＲＥＳＥＴがビーム失敗復旧要求においてＵＥ−専用候補ビームのＤＬ  ＲＳと空間的にＱＣＬされたと仮定する。
【０６０５】
以下、本明細書で提案するビーム失敗復旧手続の各ステップについてより具体的に説明する。
【０６０６】
第１に、新しいビーム識別のための過程について説明する。
【０６０７】
メトリック（Ｍｅｔｒｉｃ）Ｘに対して、サービングビームの失敗が仮想（ｈｙｐｏｔｈｅｔｉｃａｌ）ＢＬＥＲ（Ｂｌｏｃｋ  Ｅｒｒｏｒ  Ｒａｔｅ）により決定されるとしても、Ｌ１−ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｅｄ  Ｐｏｗｅｒ）の利用が（新しいビーム識別のために）仮想（ｈｙｐｏｔｈｅｔｉｃａｌ）のＢＬＥＲより有用であり得る。
【０６０８】
ここで、前記ｍｅｔｒｉｃ  Ｘは、前述したように候補ビーム識別のために臨界値（ｔｈｒｅｓｈｏｌｄ）と比較される値である。
【０６０９】
まず、端末（ＵＥ）が新しい候補ビーム（ｎｅｗ  ｃａｎｄｉｄａｔｅ  ｂｅａｍ）の品質を報告するように要求されたとき、前記Ｌ１−ＲＳＲＰは当該ビーム報告媒介変数（ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ  ｐａｒａｍｅｔｅｒ）と一致し得る。
【０６１０】
第２に、ＢＬＥＲ臨界値は、ネットワークにより悲観的（ｐｅｓｓｉｍｉｓｔｉｃ）方式で設定できるので、新しいビーム識別のために他のメトリック（ｍｅｔｒｉｃ）を使用することは大きな問題とならない。ビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）はリンク失敗（ｌｉｎｋ  ｆａｉｌｕｒｅ）となる可能性を減らすための手続に該当する。端末（ＵＥ）がＬ１−ＲＳＲＰ臨界値を満たすある新しい候補ビームを発見できない場合（又は、検出できない場合）、端末（ＵＥ）は、リンク復旧（ｌｉｎｋ  ｒｅｃｏｖｅｒｙ）を行うことができる。最後に、端末（ＵＥ）側においてＢＬＥＲの演算負担はＬ１−ＲＳＲＰより非常に高くなり得る。端末（ＵＥ）が数十又は数百のＢＬＥＲを計算する必要がある場合、これは端末（ＵＥ）の実現の観点から非常に重要な影響を及ぼす。
【０６１１】
従って、前記事項に基づいて新しいビーム識別に対する以下の５つの提案を定義する。
【０６１２】
（提案１）
【０６１３】
提案１は、Ｌ１−ＲＳＲＰを新しい候補ビーム識別のためのＭｅｔｒｉｃ（例えば、ｍｅｔｒｉｃ  Ｘ）として使用することである。
【０６１４】
Ｍｅｔｒｉｃ  Ｘに対する臨界値の設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）について、ｇＮＢの設定可能性（ｃｏｎｆｉｇｕｒａｂｉｌｉｔｙ）がネットワークがＰＲＡＣＨと類似してセル配置（ｃｅｌｌ  ｄｅｐｌｏｙｍｅｎｔ）環境に依存する他の臨界値（ら）を設定するように要求される。
【０６１５】
（提案２）
【０６１６】
提案２は、新しいビーム識別（すなわち、ｍｅｔｒｉｃ  Ｘ）のための臨界値の基地局設定の可能性をサポートすることである。２つの臨界値が新しいビーム識別のためのＣＳＩ−ＲＳ＋ＳＳＢのケースのためにサポートされる。
【０６１７】
以下のシナリオ１及び２は新しいビーム識別のためのＣＳＩ−ＲＳ＋ＳＳＢケースの一例である。
【０６１８】
シナリオ１：ＰＲＡＣＨｓはもっぱらＳＳＢと関連（ａｓｓｏｃｉａｔｉｏｎ）される。シナリオ１において、新しいビーム識別のためのＣＳＩ−ＲＳリソースはＳＳＢ（ｓ）とＱＣＬ連関から見つけることができる。
【０６１９】
シナリオ２：多数のＰＲＡＣＨのそれぞれはＳＳＢ又はＣＳＩ−ＲＳリソースと関連する。
【０６２０】
前述した２つのシナリオを比較すると、シナリオ２が基地局（ｇＮＢ）／端末（ＵＥ）の動作の側面においてさらに簡単である。しかしながら、シナリオ１は必要なＰＲＡＣＨリソースを大きく節約することができる。
【０６２１】
図１６は、本明細書で提案する方法に適用できるＣＳＩ−ＲＳ及びＳＳブロックの空間カバレッジ（ｓｐａｔｉａｌ  ｃｏｖｅｒａｇｅ）の一例を示した図である。
【０６２２】
図１６に示すように、ＣＳＩ−ＲＳリソースの空間カバレッジ（又は、ビーム−幅）１６２０がＳＳＢの空間カバレッジ１６１０より狭いとき、ＰＲＡＣＨリソースに対する節約（ｓａｖｉｎｇ）効果はさらに大きくなる。
【０６２３】
図１６において６つのＣＳＩ−ＲＳリソースはＳＳＢ＃１とＱＣＬｅｄされていることが分かる。ＣＳＩ−ＲＳリソースのうち１つはサービングビーム（すなわち、ＰＤＣＣＨと空間的にＱＣＬされる）として役割を果たすと仮定する。
【０６２４】
ここで、シナリオ１が適用される場合は、単に４つのＰＲＡＣＨリソースが設定される必要があるが（すなわち、１つのＳＳＢに対して１つのＰＲＡＣＨ）、シナリオ２の場合、１０個のＰＲＡＣＨリソースが設定される必要がある。図１６において、基地局は、広いビーム（すなわち、ＳＳＢのビーム幅）を使ってＰＲＡＣＨを受信する反面、端末（ＵＥ）のためのダウンリンク送信に対して、狭いビーム（すなわち、ＣＳＩ−ＲＳのビーム幅）を使用する。
【０６２５】
端末がＣＳＩ−ＲＳリソースを新しい候補ビームとして発見した場合、端末は、発見されたＣＳＩ−ＲＳリソースとともに空間的にＱＣＬｅｄされているＳＳＢに関連したＰＲＡＣＨリソースを使用してＢＦＲＱを送信することができる。端末は、ＢＦＲＱ（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）に対する基地局の応答により割り当てられたＰＵＳＣＨを使用して新しいビーム（例：ＣＲＩ）に対するより詳細な情報を基地局に送信することができる。
【０６２６】
（提案３）
【０６２７】
提案３は、新しいビーム識別のためのＣＳＩ＋ＳＳＢのシナリオ１に対して、
【０６２８】
−発見された新しいビームがＣＳＩ−ＲＳであると、端末は、前述した臨界条件を満たすＣＳＩ−ＲＳと空間的にＱＣＬｅｄされたＳＳＢに連関するＰＲＡＣＨを介してＢＦＲＱを送信する。
【０６２９】
−発見された新しいビームがＳＳＢであると、端末は、前述された臨界条件を満たすＳＳＢと関連したＰＲＡＣＨを介してＢＦＲＱを送信する。
【０６３０】
シナリオ１に対して、基地局（ｇＮＢ）は、ＢＦＲＱが受信されるＰＲＡＣＨと関連したＳＳＢにおいて新しいビームを発見したか又は該当ＳＳＢとＱＣＬｅｄされたＣＳＩ−ＲＳリソースにおいて新しいビームを発見したかに対して曖昧さ（ａｍｂｉｇｕｉｔｙ）が発生し得る。この曖昧さは、ＢＦＲＱを受信した後、割り当てられるかトリガーされたＰＵＳＣＨ／ＰＵＣＣＨで端末に新しいビームに関するより多くの情報を要求することにより解決できる。
【０６３１】
最初からこの曖昧さを除去するために、基地局（ｇＮＢ）が１つのＳＳＢと関連した最大２つのＰＲＡＣＨリソースを設定するようにすることができる。端末（ＵＥ）は、新しいビームがＱＣＬｅｄされたＣＳＩ−ＲＳリソースから発見される場合、１番目のＰＲＡＣＨリソースを介してＢＦＲＱを送信することができる。端末は、新しいビームがＳＳＢ自体であると、２番目のＰＲＡＣＨリソースを介してＢＦＲＱを送信することができる。このような方式で、基地局（ｇＮＢ）は、端末（ＵＥ）の状況を区別することができる。基地局（ｇＮＢ）が１番目のＰＲＡＣＨを介してＢＦＲＱを受信する場合、基地局（ｇＮＢ）はＣＲＩ及び該当するＬ１−ＲＳＲＰ（すなわち、周期的ビーム報告のみをトリガリング）を受信するためにＰＵＳＣＨを直接割り当てることができる。この場合、基地局（ｇＮＢ）は、端末（ＵＥ）にビームを精製（ｒｅｆｉｎｅ）するためにＣＳＩ−ＲＳリソースを送信する必要がない。基地局（ｇＮＢ）は、２番目のＰＲＡＣＨを介してＢＦＲＱを受信する場合、基地局（ｇＮＢ）は、ＰＵＳＣＨだけでなくＣＳＩ−ＲＳリソースをトリガーする必要がある。図１６の例に前記方法を適用する場合（４ないし５のＰＲＡＣＨリソース）、ただ１つのＰＲＡＣＨリソースのみがさらにＵＥに設定される必要がある。これは、シナリオ２に対して要求されるＰＲＡＣＨリソースの半分にしかならない。
【０６３２】
（提案４）
【０６３３】
提案４は、ＣＳＩ−ＲＳ＋ＳＳＢのシナリオ１に対して、１つのＳＳＢと関連したＰＲＡＣＨリソースを最大２つまでサポートすることである。ここで、端末（ＵＥ）が関連したＳＳＢを新しいビームとして発見した場合、１つの（ＰＲＡＣＨ）リソースが使用され、端末が関連したＳＳＢと空間的にＱＣＬｅｄされたＣＳＩ−ＲＳリソースを新しいビームとして発見した場合、他の（ＰＲＡＣＨ）リソースが使用される。
【０６３４】
新しいビーム識別用途としてＳＳＢとＣＳＩ−ＲＳを両方とも使用する場合、ＳＳＢとＣＳＩ−ＲＳは両方とも予め定められた条件（ｃｏｎｄｉｔｉｏｎ）（例えば、特定臨界値（ｔｈｒｅｓｈｏｌｄ）以上の品質を有すること）を満たすとき、（１）端末はＣＳＩ−ＲＳを優先的に選択して新しいビーム（ＲＳ）としてビーム報告を行うことができる。
【０６３５】
または、（２）ＳＳＢとＣＳＩ−ＲＳのどちらを優先的に選択して新しいビーム（ＲＳ）として報告を行うかを基地局が（ＲＲＣメッセージ、ＭＡＣメッセージ、ＤＣＩなどを介して）設定することができる。
【０６３６】
または、（３）端末は、ＳＳＢを優先的に選択して新しいビーム（ＲＳ）として報告を行うことができる。
【０６３７】
前記（３）、すなわち、ＳＳＢを新しいビームとして優先的に選択する理由は、ＳＳＢがＣＳＩ−ＲＳよりさらに広いビーム幅とカバレッジを有するためである。また、前記（２）、すなわち、基地局の設定により新しいビームが選択される場合は、基地局が（ビーム別のトラフィック、干渉など）状況に応じて（端末別に）優先的に選択するＲＳタイプ（ｔｙｐｅ）を制御することがより良い可能性があるからである。または、前記（２）は、ＲＳタイプ（ｔｙｐｅ）及び／又はどのようなＲＳセットのうち優先的にビームを選択するかを基地局が設定／指定できるからである。
【０６３８】
ここで、前記ＲＳセットは、ＳＳＢ  ＩＤ（ｓ）及び／又はＣＳＩ−ＲＳリソースＩＤ（ｓ）が（混合して）設定されることもできる。
【０６３９】
追加的に、前記優先（ｐｒｉｏｒｉｔｙ）順位は、ｈｉｇｈ／ｌｏｗの２段階であり、３段階（ｈｉｇｈ／ｍｉｄ／ｌｏｗ）以上でもあり得る。前記優先順位規則（ｐｒｉｏｒｉｔｙ  ｒｕｌｅ）に従って選択されたビームは、ビームＩＤ及び品質報告だけでなく、当該ビームと関連したＢＦＲリソースを選択してＢＦＲＱ（ＢＦＲ  ｒｅｑｕｅｓｔ）信号を送信するようにすることができる。
【０６４０】
新しいビーム識別のためのＣＳＩ−ＲＳ＋ＳＳＢケースについて、まず端末（ＵＥ）はＣＳＩ−ＲＳリソース（Ｒｅｓｏｕｒｃｅ）を介して検索を行い、その後、ＣＳＩ−ＲＳが臨界条件を満たさない場合、ＳＳＢを検索する。これは、大部分のシナリオにおいてＣＳＩ−ＲＳのビーム幅がＳＳＢのビーム幅より狭いか等しいためである。これにより、端末（ＵＥ）は、ＣＳＩ−ＲＳリソースのうち新しい候補ビームを発見すると、ＳＳＢより新しいビームとしてＣＳＩ−ＲＳリソースを使用することが良いかもしれない。このような観点から、以下の提案５について説明する。
【０６４１】
（提案５）
【０６４２】
提案５は、新しいビーム識別のためのＣＳＩ−ＲＳ＋ＳＳＢに対して、ＣＳＩ−ＲＳとＳＳＢが両方とも臨界条件を満たすと、端末（ＵＥ）がＣＳＩ−ＲＳを選択することである。
【０６４３】
第２に、ビーム失敗復旧のためのＰＵＣＣＨの使用方法について説明する。
【０６４４】
ＢＦＲＱを送信するためにＰＵＣＣＨを使用する方法の２つのケースは以下の通りである。
【０６４５】
−ケース１：ＰＤＣＣＨビームのサブセットが失敗するとき、
【０６４６】
−ケース２：ビーム失敗が検出されるとき（すなわち、全てのＰＤＣＣＨビームが失敗）
【０６４７】
ケース１に対して、少なくとも１つのＰＵＣＣＨが各サービングＰＤＣＣＨビームと関連していると仮定すると、ＵＬビームペアリンク（ｂｅａｍ  ｐａｉｒ  ｌｉｎｋ）のうち１つが依然として生きている可能性があるため、ＰＵＣＣＨリソースは速いビーム失敗復旧要求（ＢＦＲＱ）のために使用できる。ケース１において、端末（ＵＥ）はＰＵＣＣＨのリンク品質が深刻に損なわれるとは予想していないため、ＰＵＣＣＨを介して直接新しいビームに関する相当な量の情報を送ることができる。ＰＵＣＣＨフォーマット２、３及び／又は４は、報告ビームＩＤ及び当該Ｌ１−ＲＳＲＰのために考慮されることができる。
【０６４８】
ケース２の場合、潜在的にさらに大きな範囲とタイミングエラーにさらに強力なＰＲＡＣＨを使用することがより安全である。しかしながら、ケース２において、ＰＵＣＣＨはＰＲＡＣＨの補完チャネルとして使用してＢＦＲＱを端末（ＵＥ）に送信するのにさらに頻繁な機会を提供することができる。この場合、端末（ＵＥ）はＰＵＣＣＨからの応答がない場合、ＰＲＡＣＨをフォールバック（ｆａｌｌｂａｃｋ）として使用しなければならない。この場合、端末（ＵＥ）はＰＵＣＣＨのリンク品質が低下する可能性があるため、強力なＰＵＣＣＨ形式を使用しなければならない。従って、この場合、ＰＵＣＣＨフォーマット０及び／又は１が適合する。
【０６４９】
（提案６）
【０６５０】
提案６の場合、サービング制御チャネルのサブセットが失敗すると、ＰＵＣＣＨはネットワークにイベントの発生を知らせるのに使われる。全てのサービング制御チャネルが失敗する場合（すなわち、ビーム失敗）、ＰＲＡＣＨはビーム失敗復旧を要求する基本（ｂａｓｅｌｉｎｅ）として使用され、ＰＵＣＣＨは追加的に（ｃｏｍｐｌｅｍｅｎｔａｒｙ）使用されることができる。
【０６５１】
本明細書で提案するまた他の特徴は、ケース１とケース２によってＰＵＣＣＨフォーマットを異なるように設定／使用することである。
【０６５２】
ケース１、すなわち、複数のＰＤＣＣＨビームが設定された場合、端末が受信する或いはモニターするＰＤＣＣＨ（又は、ＣＯＲＥＳＥＴ又は検索空間（ｓｅａｒｃｈ  ｓｐａｃｅ））に設定されたビーム情報（すなわち、空間ＲＸパラメータ（ｓｐａｔｉａｌ  ＲＸ  ｐａｒａｍｅｔｅｒ）の観点からのＱＣＬされたＲＳ情報）が複数であるとき、一部のＰＤＣＣＨ  ＢＬＥＲは特定品質（例えば、Ｑ＿ｏｕｔ）以下であるが、残りのＰＤＣＣＨ  ＢＬＥＲは特定品質（例えば、Ｑ＿ｉｎ）以上である場合、特定品質以上であるＰＤＣＣＨと空間（ｓｐａｔｉａｌ）ＱＣＬされたＲＳと（ＤＬ−ＵＬ観点から）関連したＢＦＲがＰＵＣＣＨである場合、該当ＰＵＣＣＨフォーマットは一般的なビーム／ＣＳＩ報告を実行できる（例えば、数十ビット以上のＵＣＩ報告をサポートする）ＰＵＣＣＨフォーマットである２、３及び／又は４などを使用する。
【０６５３】
そして、全てのＰＤＣＣＨ  ＢＬＥＲが特定品質以下である場合、ＢＦＲのうち設定されたＰＵＣＣＨを使用する場合、当該ＰＵＣＣＨはより少ない情報を送るが、より強力な（例えば、低いコーディングレートでエンコードされた）ＰＵＣＣＨフォーマット０及び／又は１を使用する。
【０６５４】
ＢＦＲＱのために設定されたＰＵＣＣＨリソースは、端末（ＵＥ）がＰＵＣＣＨでＢＦＲＱを送信する必要がある場合、他の目的に設定されたＰＵＣＣＨリソースより優先順位が高くなければならない。
【０６５５】
（提案７）
【０６５６】
提案７は、ＢＦＲＱ送信のためのＰＵＣＣＨが他のＰＵＣＣＨより優先順位が高くなければならないということである。
【０６５７】
次に、ＢＦＲＱに対する基地局応答について説明する。
【０６５８】
端末（ＵＥ）がＢＦＲＱの基地局（ｇＮＢ）応答をモニターするために、Ｃ−ＲＮＴＩと指定（ｄｅｄｉｃａｔｅｄ）ＣＯＲＥＳＥＴが使用される。非周期的（ａｐｅｒｉｏｄｉｃ）ビーム報告に対するＰＵＳＣＨリソース割り当ては前記ＢＦＲＱに対する基地局応答に含まれるべき必須情報であり得る。また、前記ＢＦＲＱに対する基地局応答に非周期的ＣＳＩ−ＲＳトリガリングメッセージは含まれなければならず、このメッセージは非周期的ビーム報告トリガリングとともにエンコードされることができる。
【０６５９】
このようなメッセージは、スケジューリングがＤＬ  ＤＣＩ形式に基づいたＰＤＳＣＨにおいてＵＬ  ＤＣＩ又はＭＡＣ層メッセージ形式で端末（ＵＥ）に送信されることができる。空間基準（ｓｐａｔｉａｌ  ｒｅｆｅｒｅｎｃｅ、例えば、ＣＲＩ（ＣＳＩ−ＲＳ  ｒｅｓｏｕｒｃｅ  ｉｎｄｅｘ）、ＳＲＩ）の明示的シグナリングがない場合、ＰＵＳＣＨ送信のためのＴｘビームはＰＲＡＣＨに使用されるのと同一に設定されることができる。すなわち、ＰＵＳＣＨのための空間基準は、端末（ＵＥ）がＢＦＲＱに対する応答を受信するＰＤＣＣＨにより決定される。
【０６６０】
（提案８）
【０６６１】
提案８は、ＰＲＡＣＨがＢＦＲＱを送信するのに使用される場合、ＢＦＲＱに対する応答としてメッセージ／ＤＣＩは少なくとも次のような情報を含むべきである。
【０６６２】
−ＰＵＳＣＨリソース割り当てに伴う非周期ビーム報告トリガリング
【０６６３】
−非周期ＣＳＩ−ＲＳトリガリング
【０６６４】
非周期ＣＳＩ−ＲＳが常にトリガーされないことがある。
【０６６５】
（提案９）
【０６６６】
提案９はデフォルトであり、ＢＦＲＱに対する応答に割り当てられたＰＵＳＣＨの空間基準は端末（ＵＥ）がＢＦＲＱに対する応答を受信するＰＤＣＣＨにより決定できるということである。
【０６６７】
提案９は、ＢＦＲＱに対する応答を受信する用途として設定されたＣＯＲＥＳＥＴにおいて受信するＰＤＣＣＨに対して（ＰＵＳＣＨをスケジューリングする）ＵＬ関連（ｒｅｌａｔｅｄ）ＤＣＩを使用するか、コンパクトフォーマット（ｃｏｍｐａｃｔ  ｆｏｒｍａｔ）のＤＬ  ＤＣＩを使用するが、ＭＡＣメッセージでＰＵＳＣＨをスケジューリングし、ここで、ＣＳＩ／ビーム報告トリガリングフィールド（ＣＳＩ／ｂｅａｍ  ｒｅｐｏｒｔｉｎｇ  ｔｒｉｇｇｅｒｉｎｇ  ｆｉｅｌｄ）とＣＳＩ−ＲＳトリガリングフィールドが該当ＤＣＩ又はＭＡＣメッセージに含まれる特徴を有する。ここで、前記２つのフィールドはジョイントエンコード（ｊｏｉｎｔ  ｅｎｃｏｄｉｎｇ）されて１つのフィールドで構成される。
【０６６８】
図１７は、本明細書で提案するビーム失敗復旧のための端末の動作方法の一例を示したフローチャートである。
【０６６９】
まず、端末は、ビーム失敗を検出する（Ｓ１７１０）。
【０６７０】
次に、端末は、ビーム失敗復旧のための新しいビームを識別する（Ｓ１７２０）。
【０６７１】
ここで、新しいビームは予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）であり得る。
【０６７２】
ＲＳは、ＳＳＢ（ＳＳ  Ｂｌｏｃｋ）又はＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースであり得る。
【０６７３】
また、ＣＳＩ−ＲＳリソースは、ＳＳＢと空間的にＱＣＬ（ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）されていることがある。
【０６７４】
ＣＳＩ−ＲＳリソースは、複数のＣＳＩ−ＲＳリソースを含む。
【０６７５】
前記予め定義された条件は、特定条件で表現されることができ、例えば、設定された（又は、予め定義された）臨界値より高い品質であるか又はＣＳＩ−ＲＳ／ＳＳＢブロックをサポートするよりも優れた品質であり得る。
【０６７６】
また、前記臨界値は、候補ビーム（識別と関連した）ＲＳがビーム失敗復旧のために使用できるか否かを決定するために使用される値を意味し、基地局により設定される。
【０６７７】
また、ＳＳＢ（ＳＳ  Ｂｌｏｃｋ）及びＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースの全てが予め定義された条件を満たす場合、ＣＳＩ−ＲＳリソースが新しいビームとして識別される。
【０６７８】
次に、端末は、ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソースを利用して基地局に送信する（Ｓ１７３０）。
【０６７９】
ＰＲＡＣＨリソースは、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含む。また、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ  Ｂｌｏｃｋ）と関連する。
【０６８０】
また、ＳＳＢが新しいビームとして識別された場合、ビーム失敗復旧要求は第１ＰＲＡＣＨリソースを使用して送信され、ＣＳＩ−ＲＳリソースが新しいビームとして識別された場合、ビーム失敗復旧要求は第２ＰＲＡＣＨリソースを使用して送信される。
【０６８１】
図１８は、本明細書で提案するビーム失敗復旧のための基地局の動作方法の一例を示したフローチャートである。
【０６８２】
まず、基地局は、ビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）のための新しいビーム識別に関する情報を端末に送信する（Ｓ１８１０）。
【０６８３】
次に、基地局は、ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソースを用いて端末から受信する（Ｓ１８２０）。
【０６８４】
ここで、ＰＲＡＣＨリソースは第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含む。また、第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ  Ｂｌｏｃｋ）と関連する。
【０６８５】
新しいビームがＳＳＢである場合、ビーム失敗復旧要求は第１ＰＲＡＣＨリソースを使用し、新しいビームがＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースである場合、ビーム失敗復旧要求は第２ＰＲＡＣＨリソースを使用する。
【０６８６】
また、新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）であり得る。
【０６８７】
ＲＳは、ＳＳＢ又はＣＳＩ−ＲＳリソースであり得る。
【０６８８】
ＣＳＩ−ＲＳリソースは、複数のＣＳＩ−ＲＳリソースを含む。
【０６８９】
ＣＳＩ−ＲＳリソースは、ＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）されていることがある。
【０６９０】
ここで、ＳＳＢ及びＣＳＩ−ＲＳリソースが全て予め定義された条件を満たす場合、ＣＳＩ−ＲＳリソースが端末により新しいビームとして識別されることができる。
【０６９１】
図１８と関連した説明において言及された内容以外にも、図１７と同一の内容については図１７を参考とする。
【０６９２】
本発明が適用できる装置の一般
【０６９３】
図１９は、本発明の一実施形態に係る無線通信装置のブロック構成図を例示する。
【０６９４】
図１９に示すように、無線通信システムは、基地局（又は、ネットワーク）１９１０と端末１９２０を含む。
【０６９５】
基地局１９１０は、プロセッサ（ｐｒｏｃｅｓｓｏｒ）１９１１、メモリ（ｍｅｍｏｒｙ）１９１２及び通信モジュール（ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｍｏｄｕｌｅ）１９１３を含む。
【０６９６】
プロセッサ１９１１は、前記図１ないし図１８で提案された機能、過程及び／又は方法を実現する。有／無線インタフェースプロトコル層はプロセッサ１９１１により実現される。メモリ１９１２は、プロセッサ１９１１と接続されて、プロセッサ１９１１を駆動するための様々な情報を格納する。通信モジュール１９１３は、プロセッサ１９１１と接続されて、有／無線信号を送信及び／又は受信する。
【０６９７】
前記通信モジュール１９１３は、無線信号を送受信するためのＲＦ部（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ  ｕｎｉｔ）を含む。
【０６９８】
端末１９２０は、プロセッサ１９２１、メモリ１９２２及び通信モジュール（又は、ＲＦ部）１９２３を含む。プロセッサ１９２１は、前記図１ないし図１８で提案された機能、過程及び／又は方法を実現する。無線インタフェースプロトコル層はプロセッサ１９２１により実現される。メモリ１９２２は、プロセッサ１９２１と接続されて、プロセッサ１９２１を駆動するための様々な情報を格納する。通信モジュール１９２３は、プロセッサ１９２１接続されて、無線信号を送信及び／又は受信する。
【０６９９】
メモリ１９１２、１９２２は、プロセッサ１９１１、１９２１の内部又は外部にあり、広く知られた様々な手段でプロセッサ１９１１、１９２１と接続される。
【０７００】
また、基地局１９１０及び／又は端末１９２０は、１つのアンテナ（ｓｉｎｇｌｅ  ａｎｔｅｎｎａ）又は多重アンテナ（ｍｕｌｔｉｐｌｅ  ａｎｔｅｎｎａ）を有してもよい。
【０７０１】
図２０は、本発明の一実施形態に係る通信装置のブロック構成図を例示する。
【０７０２】
特に、図２０は、前記図１９の端末をより詳細に例示する図である。
【０７０３】
図２０に示すように、端末は、プロセッサ（又は、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒ）２０１０、ＲＦモジュール（ＲＦ  ｍｏｄｕｌｅ）（又は、ＲＦユニット）２０３５、パワー管理モジュール（ｐｏｗｅｒ  ｍａｎａｇｅｍｅｎｔ  ｍｏｄｕｌｅ）２０１５、アンテナ（ａｎｔｅｎｎａ）２０４０、バッテリ（ｂａｔｔｅｒｙ）２０５５、ディスプレイ（ｄｉｓｐｌａｙ）２０１５、キーパッド（ｋｅｙｐａｄ）２０２０、メモリ（ｍｅｍｏｒｙ）２０３０、ＳＩＭカード(ＳＩＭ(Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｍｏｄｕｌｅ)  ｃａｒｄ２０２５（この構成は選択的である）、スピーカ（ｓｐｅａｋｅｒ）２０４５及びマイクロホン（ｍｉｃｒｏｐｈｏｎｅ）２０５０を含んで構成される。端末は、また、単一のアンテナ又は多重のアンテナを含んでもよい。
【０７０４】
プロセッサ２０１０は、前記図１ないし図１８で提案された機能、過程及び／又は方法を実現する。無線インタフェースプロトコル層はプロセッサにより実現できる。
【０７０５】
メモリ２０３０は、プロセッサと接続されて、プロセッサの動作に関する情報を格納する。メモリは、プロセッサの内部又は外部にあり、よく知られた様々な手段でプロセッサと接続される。
【０７０６】
ユーザは、例えば、キーパッド２０２０のボタンを押すか（又は、タッチするか）又はマイクロホン２０５０を利用した音声駆動（ｖｏｉｃｅ  ａｃｔｉｖａｔｉｏｎ）により電話番号などのような命令情報を入力する。プロセッサ２０１０は、このような命令情報を受信し、電話番号で電話をかけるなどの適切な機能を果たすように処理する。駆動上のデータ（ｏｐｅｒａｔｉｏｎａｌ  ｄａｔａ）はＳＩＭカード２０２５又はメモリ２０３０から抽出できる。また、プロセッサ２０１０は、ユーザの認知又は便宜のために命令情報又は駆動情報をディスプレイ２０１５上に表示する。
【０７０７】
ＲＦモジュール２０３５は、プロセッサ２０１０に接続されて、ＲＦ信号を送信及び／又は受信する。プロセッサ２０１０は通信を開始するために、例えば、音声通信データを構成する無線信号を送信するように命令情報をＲＦモジュール２０３５に伝達する。ＲＦモジュール２０３５は、無線信号を受信及び送信するために受信機（ｒｅｃｅｉｖｅｒ）及び送信機（ｔｒａｎｓｍｉｔｔｅｒ）から構成される。アンテナ２０４０は、無線信号を送信及び受信する機能を有する。無線信号を受信するとき、ＲＦモジュール２０３５は、プロセッサ２０１０により処理するために信号を伝達し、基底帯域に信号を変換することができる。処理された信号はスピーカ２０４５を介して出力される可聴又は可読情報に変換できる。
【０７０８】
図２１は、本明細書で提案する方法が適用できる無線通信装置のＲＦモジュールの一例を示した図である。
【０７０９】
具体的に、図２１は、ＦＤＤ（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）システムにおいて実現できるＲＦモジュールの一例を示す。
【０７１０】
まず、送信経路において、図１９及び図２０で記述されたプロセッサは、送信されるデータをプロセッシングしてアナログ出力信号を送信機２１１０に提供する。
【０７１１】
送信機２１１０内において、アナログ出力信号は、デジタル−対−アナログ変換（ＡＤＣ）により発生するイメージを除去するために低域通過フィルタ（Ｌｏｗ  Ｐａｓｓ  Ｆｉｌｔｅｒ：ＬＰＦ）２１１１によりフィルタリングされ、アップコンバータ（Ｍｉｘｅｒ）２１１２により基底帯域からＲＦにアップコンバートされ、可変利得増幅器（Ｖａｒｉａｂｌｅ  Ｇａｉｎ  Ａｍｐｌｉｆｉｅｒ：ＶＧＡ）２１１３により増幅され、増幅された信号はフィルタ２１１４によりフィルタリングされ、電力増幅器（Ｐｏｗｅｒ  Ａｍｐｌｉｆｉｅｒ：ＰＡ）によりさらに増幅され、デュプレクサ（ら）２１５０／アンテナスイッチ（ら）２１６０を介してルーティングされ、アンテナ２１７０を介して送信される。
【０７１２】
また、受信経路において、アンテナ２１７０は、外部から信号を受信して受信された信号を提供し、この信号はアンテナスイッチ（ら）２１６０／デュプレクサ２１５０を介してルーティングされ、受信機２１２０に提供される。
【０７１３】
受信機２１２０内において、受信された信号は低雑音増幅器（Ｌｏｗ  Ｎｏｉｓｅ  Ａｍｐｌｉｆｉｅｒ：ＬＮＡ）２１２３により増幅され、帯域通過フィルタ２１２４によりフィルタリングされ、ダウンコンバータ（Ｍｉｘｅｒ）２１２５によりＲＦから基底帯域にダウンコンバートされる。
【０７１４】
前記ダウンコンバートされた信号は、低域通過フィルタ（ＬＰＦ）２１２６によりフィルタリングされ、ＶＧＡ２１２７により増幅されてアナログ入力信号を取得し、これは、図１９及び図２０で記述されたプロセッサに提供される。
【０７１５】
また、ローカルオシレータ（ｌｏｃａｌ  ｏｓｃｉｌｌａｔｏｒ：ＬＯ）発生器２１４０は、送信及び受信ＬＯ信号を発生及びアップコンバータ２１１２及びダウンコンバータ２１２５にそれぞれ提供する。
【０７１６】
また、位相固定ループ（Ｐｈａｓｅ  Ｌｏｃｋｅｄ  Ｌｏｏｐ：ＰＬＬ）２１３０は、適切な周波数で送信及び受信ＬＯ信号を生成するためにプロセッサから制御情報を受信し、制御信号をＬＯ発生器２１４０に提供する。
【０７１７】
また、図２１に示す回路は、図２１に図示された構成と異なるように配列されてもよい。
【０７１８】
図２２は、本明細書で提案する方法が適用できる無線通信装置のＲＦモジュールのまた他の一例を示した図である。
【０７１９】
具体的に、図２２は、ＴＤＤ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）システムにおいて実現できるＲＦモジュールの一例を示す。
【０７２０】
ＴＤＤシステムにおけるＲＦモジュールの送信機２２１０及び受信機２２２０は、ＦＤＤシステムにおけるＲＦモジュールの送信機及び受信機の構造と同一である。
【０７２１】
以下、ＴＤＤシステムのＲＦモジュールは、ＦＤＤシステムのＲＦモジュールと異なる構造についてのみ説明し、同一の構造については、図２１の説明を参照する。
【０７２２】
送信機の電力増幅器（Ｐｏｗｅｒ  Ａｍｐｌｉｆｉｅｒ：ＰＡ）２２１５により増幅された信号は、バンド選択スイッチ（Ｂａｎｄ  Ｓｅｌｅｃｔ  Ｓｗｉｔｃｈ）２２５０、バンド通過フィルタ（ＢＰＦ）２２６０及びアンテナスイッチ（ら）２２７０によりルーティングされ、アンテナ２２８０を介して送信される。
【０７２３】
また、受信経路において、アンテナ２２８０は、外部から信号を受信して受信された信号を提供し、この信号は、アンテナスイッチ２２７０、バンド通過フィルタ２２６０及びバンド選択スイッチ２２５０によりルーティングされ、受信機２２２０に提供される。
【０７２４】
以上で説明された実施形態は本発明の構成要素と特徴が所定の形態に結合されたものである。各構成要素または特徴は別途の明示的な言及がない限り、選択的なものとして考慮されなければならない。各構成要素または特徴は他の構成要素や特徴と結合されない形態に実施できる。また、一部の構成要素及び／又は特徴を結合して本発明の実施形態を構成することも可能である。本発明の実施形態で説明される動作の順序は変更できる。ある実施形態の一部の構成や特徴は他の実施形態に含まれることができ、または他の実施形態の対応する構成または特徴と取替できる。特許請求範囲で明示的な引用関係がない請求項を結合して実施形態を構成するか、または出願後の補正により新たな請求項に含めることができることは自明である。
【０７２５】
本発明による実施形態は、多様な手段、例えば、ハードウェア、ファームウエア（ｆｉｒｍｗａｒｅ）、ソフトウェア、またはそれらの結合などにより実現できる。ハードウェアによる実現の場合、本発明の一実施形態は１つまたはそれ以上のＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｄｅｖｉｃｅｓ）、ＰＬＤｓ（ｐｒｏｇｒａｍｍａｂｌｅ  ｌｏｇｉｃ  ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙｓ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどにより実現できる。
【０７２６】
ファームウエアやソフトウェアによる実現の場合、本発明の一実施形態は以上で説明された機能または動作を遂行するモジュール、手続、関数などの形態で実現できる。ソフトウェアコードはメモリに格納されてプロセッサにより駆動できる。前記メモリは前記プロセッサの内部または外部に位置し、既に公知された多様な手段により前記プロセッサとデータをやり取りすることができる。
【０７２７】
本発明は、本発明の必須的な特徴を逸脱しない範囲で他の特定の形態に具体化できることは通常の技術者に自明である。従って、前述した詳細な説明は全ての面で制限的に解釈されてはならず、例示的なものとして考慮されなければならない。本発明の範囲は添付した請求項の合理的な解釈により決定されなければならず、本発明の等価的な範囲内での全ての変更は本発明の範囲に含まれる。
【産業上の利用可能性】
【０７２８】
本発明の無線通信システムにおいて、ビーム失敗復旧実行方法は、３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステム、５Ｇに適用される例を中心に説明したが、これ以外にも様々な無線通信システムに適用可能である。
【図１】
2021503261.tif 000039
【図２】
2021503261.tif 000040
【図３】
2021503261.tif 000041
【図４】
2021503261.tif 000042
【図５】
2021503261.tif 000043
【図６】
2021503261.tif 000044
【図７】
2021503261.tif 000045
【図８】
2021503261.tif 000046
【図９】
2021503261.tif 000047
【図１０（ａ）】
2021503261.tif 000048
【図１０（ｂ）】
2021503261.tif 000049
【図１１（ａ）】
2021503261.tif 000050
【図１１（ｂ）】
2021503261.tif 000051
【図１２】
2021503261.tif 000052
【図１３】
2021503261.tif 000053
【図１４】
2021503261.tif 000054
【図１５】
2021503261.tif 000055
【図１６】
2021503261.tif 000056
【図１７】
2021503261.tif 000057
【図１８】
2021503261.tif 000058
【図１９】
2021503261.tif 000059
【図２０】
2021503261.tif 000060
【図２１】
2021503261.tif 000061
【図２２】
2021503261.tif 000062
【手続補正書】
【提出日】令和2年5月15日(2020.5.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線通信システムにおいて端末（ＵＥ）がビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う方法であって、
ビーム失敗を検出するステップと、
前記ビーム失敗復旧のための新しいビーム（ｎｅｗ  ｂｅａｍ）を識別するステップと、
ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅ）リソースを利用して基地局（ＢＳ）に送信するステップと、を含み、
前記ＰＲＡＣＨリソースは、ＳＳＢ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｓｉｇｎａｌ  ｂｌｏｃｋ）と関連する第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、
前記ＳＳＢが前記新しいビームとして識別されることに基づいて、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを利用して送信され、
ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースが前記新しいビームとして識別されることに基づいて、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用して送信される、方法。
【請求項２】
前記ＣＳＩ−ＲＳリソースは、前記ＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）される、請求項１に記載の方法。
【請求項３】
前記新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）である、請求項１に記載の方法。
【請求項４】
前記ＳＳＢ及び前記ＣＳＩ−ＲＳリソースの両方が前記予め定義された条件を満たす時、前記ＣＳＩ−ＲＳリソースは前記新しいビームとして識別される、請求項３に記載の方法。
【請求項５】
無線通信システムにおいて基地局（ＢＳ）がビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う方法であって、
前記ビーム失敗復旧のための新しいビーム識別に関連する情報を端末（ＵＥ）に送信するステップと、
ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅ）リソース（ｒｅｓｏｕｒｃｅ）を利用して前記端末から受信するステップと、を含み、
前記ＰＲＡＣＨリソースは、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、
前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｓｉｇｎａｌ  ｂｌｏｃｋ）と関連し、
前記新しいビームが前記ＳＳＢであることに基づいて、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを利用し、
前記新しいビームがＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースであることに基づいて、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを利用する、方法。
【請求項６】
前記ＣＳＩ−ＲＳリソースは前記ＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）される、請求項５に記載の方法。
【請求項７】
前記新しいビームは、予め定義した条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）である、請求項５に記載の方法。
【請求項８】
前記ＳＳＢ及び前記ＣＳＩ−ＲＳリソースの両方が前記予め定義した条件を満たす時、前記ＣＳＩ−ＲＳリソースは前記端末により前記新しいビームとして識別される、請求項７に記載の方法。
【請求項９】
無線通信システムにおいてビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う端末であって、
無線信号を送受信するように構成された少なくとも一つのトランシーバと、
前記少なくとも一つのトランシーバと機能的に接続される少なくとも一つのプロセッサと、を含み、
前記少なくとも一つのプロセッサは、
ビーム失敗を検出し、
前記ビーム失敗復旧のための新しいビーム（ｎｅｗ  ｂｅａｍ）を識別し、
ビーム失敗復旧要求（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ  ｒｅｑｕｅｓｔ）をＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅ）リソース（ｒｅｓｏｕｒｃｅ）を利用して基地局に送信し、
前記ＰＲＡＣＨリソースは、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、
前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｓｉｇｎａｌ  ｂｌｏｃｋ）と関連し、
前記ＳＳＢが前記新しいビームとして識別したことに基づいて、前記ビーム失敗復旧要求は送信され、
ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）−ＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）リソースが前記新しいビームとして識別された時、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを利用して送信される、端末。
【請求項１０】
前記ＣＳＩ−ＲＳリソースは前記ＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ−ｃｏｌｏｃａｔｅｄ）される、請求項９に記載の端末。
【請求項１１】
前記新しいビームは、予め定義した条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）である、請求項９に記載の端末。
【請求項１２】
前記ＳＳＢ及び前記ＣＳＩ−ＲＳリソースの両方が前記予め定義した条件を満たす時、前記ＣＳＩ−ＲＳリソースは前記新しいビームとして識別される、請求項１１に記載の端末。
【請求項１３】
無線通信システムにおいてビーム失敗復旧（ｂｅａｍ  ｆａｉｌｕｒｅ  ｒｅｃｏｖｅｒｙ）を行う端末であって、
無線信号を送受信するように構成された少なくとも一つのトランシーバと、
前記少なくとも一つのトランシーバと機能的に接続される少なくとも一つのプロセッサと、を含み、
前記少なくとも一つのプロセッサは、
複数のＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）に関連するビーム失敗を検出し、
前記ビーム失敗に基づいてＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  ＣＨａｎｎｅｌ）又はＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）を利用して、ビーム失敗復旧要求を基地局（ＢＳ）へ送信し、
前記複数のＰＤＣＣＨビームの一部が失敗することに基づいて、前記ビーム失敗復旧要求は、予め定義した条件を満足するＰＤＣＣＨと関連する第１ＰＵＣＣＨを利用して送信され、
前記複数のＰＤＣＣＨビームが失敗することに基づいて、前記ビーム失敗復旧要求は、前記ＰＲＡＣＨ又は第２ＰＵＣＣＨを利用して送信される、端末。
【請求項１４】
前記第１ＰＵＣＣＨは、ＰＵＣＣＨフォーマット２、ＰＵＣＣＨフォーマット３又はＰＵＣＣＨフォーマット４に基づき、
前記第２ＰＵＣＣＨは、ＰＵＣＣＨフォーマット０又はＰＵＣＣＨフォーマット１に基づく、請求項１３に記載の端末。
【請求項１５】
前記複数のＰＤＣＣＨビームが失敗した時、前記ＰＲＡＣＨは前記第２ＰＵＣＣＨに優先して利用される、請求項１３に記載の端末。
【国際調査報告】
2021503261.tif 000063
2021503261.tif 000064
2021503261.tif 000065
2021503261.tif 000066