特許 7059373 無線通信システムにおいてビーム失敗復旧を行う方法及びそのための装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-04-15

(45)【発行日】2022-04-25

(54)【発明の名称】無線通信システムにおいてビーム失敗復旧を行う方法及びそのための装置

(51)【国際特許分類】

   H04W 76/18 20180101AFI20220418BHJP

   H04W 74/08 20090101ALI20220418BHJP

   H04W 16/28 20090101ALI20220418BHJP

   H04W 72/04 20090101ALI20220418BHJP

【ＦＩ】

H04W76/18

H04W74/08

H04W16/28

H04W72/04 136

【請求項の数】 8

(21)【出願番号】P 2020527117

(86)(22)【出願日】2018-11-19

(65)【公表番号】

(43)【公表日】2021-02-04

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

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

(87)【国際公開日】2019-05-23

【審査請求日】2020-05-15

(31)【優先権主張番号】62/587,547

(32)【優先日】2017-11-17

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

(73)【特許権者】

【識別番号】502032105

【氏名又は名称】エルジー エレクトロニクス インコーポレイティド

【氏名又は名称原語表記】ＬＧ ＥＬＥＣＴＲＯＮＩＣＳ ＩＮＣ．

【住所又は居所原語表記】１２８， Ｙｅｏｕｉ－ｄａｅｒｏ， Ｙｅｏｎｇｄｅｕｎｇｐｏ－ｇｕ， ０７３３６ Ｓｅｏｕｌ，Ｒｅｐｕｂｌｉｃ ｏｆ Ｋｏｒｅａ

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100123582

【弁理士】

【氏名又は名称】三橋 真二

(74)【代理人】

【識別番号】100165191

【弁理士】

【氏名又は名称】河合 章

(74)【代理人】

【識別番号】100114018

【弁理士】

【氏名又は名称】南山 知広

(74)【代理人】

【識別番号】100159259

【弁理士】

【氏名又は名称】竹本 実

(72)【発明者】

【氏名】カン チウォン

(72)【発明者】

【氏名】キム キチュン

【審査官】松野 吉宏

(56)【参考文献】

【文献】LG Electronics，Discussion on beam failure recovery，3GPP TSG RAN WG1 #90b R1-1717942，フランス，3GPP，2017年10月03日

【文献】MediaTek Inc.，On 4-step RACH procedure，3GPP TSG RAN WG1 adhoc_NR_AH_1706 R1-1710824，フランス，3GPP，2017年06月17日

【文献】NTT DOCOMO, INC.，Resource allocation for PUCCH，3GPP TSG RAN WG1 #90b R1-1718214，フランス，3GPP，2017年10月03日

【文献】Samsung，Beam failure recovery，3GPP TSG RAN WG1 adhoc_NR_AH_1709 R1-1715941，フランス，3GPP，2017年09月12日

【文献】Huawei, HiSilicon，Procedure Details for Beam Failure Recovery，3GPP TSG RAN WG1 #90 R1-1712224，フランス，3GPP，2017年08月12日

【文献】vivo，Group the different RACH events，3GPP TSG RAN WG2 #99bis R2-1710961，フランス，3GPP，2017年09月29日

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４ － ７／２６

Ｈ０４Ｗ ４／００ － ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

無線通信システムにおいて端末（ＵＥ）がビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）を行う方法であって、
ビーム失敗を検出するステップと、
前記ビーム失敗復旧のための新しいビーム（ｎｅｗ ｂｅａｍ）を識別するステップと、
ビーム失敗復旧要求（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）を、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅ）リソースに基づいて、基地局（ＢＳ）に送信するステップと、を含み、
前記ＰＲＡＣＨリソースは、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、
前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースは、ＳＳＢ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ ｂｌｏｃｋ）と関連し、
ＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）は、前記ＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ－ｃｏｌｏｃａｔｅｄ）され、
前記ＳＳＢが前記新しいビームとして識別されることに基づいて、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースに基づいて送信され、
前記ＣＳＩ－ＲＳが前記新しいビームとして識別されることに基づいて、前記ビーム失敗復旧要求は、前記ＳＳＢと関連し、前記第１ＰＲＡＣＨリソースとは異なる前記第２ＰＲＡＣＨリソースに基づいて送信され、
前記ＳＳＢ及び前記ＣＳＩ－ＲＳが前記新しいビームとして定義されることに基づいて、前記ビーム失敗復旧要求は前記ＳＳＢと関連し、前記第１ＰＲＡＣＨリソースとは異なる前記第２ＰＲＡＣＨリソースに基づいて送信される、方法。

【請求項2】

前記新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）である、請求項１に記載の方法。

【請求項3】

無線通信システムにおいて基地局（ＢＳ）がビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）を行う方法であって、
前記ビーム失敗復旧のための新しいビーム識別に関連する情報を端末（ＵＥ）に送信するステップと、
ビーム失敗復旧要求（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）をＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅ）リソース（ｒｅｓｏｕｒｃｅ）に基づいて前記端末から受信するステップと、を含み、
前記ＰＲＡＣＨリソースは、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、
前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ ｂｌｏｃｋ）と関連し、
ＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）は前記ＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ－ｃｏｌｏｃａｔｅｄ）され、
前記新しいビームが前記ＳＳＢであることに基づいて、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースに基づき、
前記新しいビームが前記ＣＳＩ－ＲＳであることに基づいて、前記ビーム失敗復旧要求は前記ＳＳＢと関連し、前記第１ＰＲＡＣＨリソースとは異なる前記第２ＰＲＡＣＨリソースに基づき、
前記ＳＳＢ及び前記ＣＳＩ－ＲＳが前記新しいビームとして定義されることに基づいて、前記ビーム失敗復旧要求は前記ＳＳＢと関連し、前記第１ＰＲＡＣＨリソースとは異なる前記第２ＰＲＡＣＨリソースに基づいて送信される、方法。

【請求項4】

前記新しいビームは、予め定義した条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）である、請求項３に記載の方法。

【請求項5】

無線通信システムにおいてビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）を行うように構成された端末であって、
少なくとも一つのトランシーバと、
少なくとも一つのプロセッサと、
前記少なくとも一つのプロセッサと機能的に接続され、前記少なくとも一つのプロセッサにより実行された場合に、以下の動作を実行させるインストラクションを格納する少なくとも一つのコンピュータメモリと、を含み、
前記動作は、
ビーム失敗を検出することと、
前記ビーム失敗復旧のための新しいビーム（ｎｅｗ ｂｅａｍ）を識別することと、
ビーム失敗復旧要求（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）を、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅ）リソース（ｒｅｓｏｕｒｃｅ）に基づいて基地局に送信することを含み、
前記ＰＲＡＣＨリソースは、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、
前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ ｂｌｏｃｋ）と関連し、
ＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）は前記ＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ－ｃｏｌｏｃａｔｅｄ）され、前記ＳＳＢが前記新しいビームとして識別されるたことに基づいて、前記ビーム失敗復旧要求は、前記第１ＰＲＡＣＨリソースに基づいて送信され、
前記ＣＳＩ－ＲＳが前記新しいビームとして識別されることに基づいて、前記ビーム失敗復旧要求は、前記ＳＳＢと関連し、前記第１ＰＲＡＣＨリソースとは異なる前記第２ＰＲＡＣＨリソースに基づいて送信され、
前記ＳＳＢ及び前記ＣＳＩ－ＲＳが前記新しいビームとして定義されることに基づいて、前記ビーム失敗復旧要求は前記ＳＳＢと関連し、前記第１ＰＲＡＣＨリソースとは異なる前記第２ＰＲＡＣＨリソースに基づいて送信される、端末。

【請求項6】

前記新しいビームは、予め定義した条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）である、請求項５に記載の端末。

【請求項7】

無線通信システムにおいてビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）を行うように構成された端末であって、
少なくとも一つのトランシーバと、
少なくとも一つのプロセッサと、
前記少なくとも一つのプロセッサと機能的に接続され、前記少なくとも一つのプロセッサにより実行されることに基づいて、以下の動作を実行させるインストラクションを格納する少なくとも一つのコンピュータメモリと、を含み、
前記動作は、
複数のＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）に関連するビーム失敗を検出することと、
前記ビーム失敗に基づくＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）に基づいて、ビーム失敗復旧要求を基地局（ＢＳ）へ送信することを含み、
前記複数のＰＤＣＣＨビームの一部が失敗することに基づいて、前記ビーム失敗復旧要求は、第１ＰＵＣＣＨに基づいて送信され、
前記複数のＰＤＣＣＨビームが失敗することに基づいて、前記ビーム失敗復旧要求は、第２ＰＵＣＣＨに基づいて送信され、
前記第１ＰＵＣＣＨは、ＰＵＣＣＨフォーマット２，又はＰＵＣＣＨフォーマット４に基づき、
前記第２ＰＵＣＣＨは、ＰＵＣＣＨフォーマット０に基づく、端末。

【請求項8】

前記第１ＰＵＣＣＨは、予め定義された条件を満たすＰＤＣＣＨと関連する、請求項７に記載の端末。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、無線通信システムに関し、より詳細に、ビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）を行う方法及びそれをサポートする装置に関する。

【背景技術】

【0002】

移動通信システムは、ユーザの活動性を保障しながら音声サービスを提供するために開発された。しかしながら、移動通信システムは、音声だけでなくデータサービスまで領域を拡張し、現在では、爆発的なトラフィックの増加によってリソースの不足現象が引き起こされ、ユーザがより高速のサービスを要求するので、より発展した移動通信システムが要求されている。

【0003】

次世代の移動通信システムの要求条件は大きく、爆発的なデータトラフィックの収容、ユーザ当たりの送信率の画期的な増加、大幅増加した連結デバイス数の収容、非常に低い端対端遅延（Ｅｎｄ－ｔｏ－Ｅｎｄ Ｌａｔｅｎｃｙ）、高エネルギー効率をサポートできなければならない。そのために、二重連結性（Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）、大規模多重入出力（Ｍａｓｓｉｖｅ ＭＩＭＯ：Ｍａｓｓｉｖｅ Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）、全二重（Ｉｎ-ｂａｎｄ Ｆｕｌｌ Ｄｕｐｌｅｘ）、非直交多重接続（ＮＯＭＡ：Ｎｏｎ-Ｏｒｔｈｏｇｏｎａｌ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、超広帯域（Ｓｕｐｅｒ ｗｉｄｅｂａｎｄ）サポート、端末ネットワーキング（Ｄｅｖｉｃｅ Ｎｅｔｗｏｒｋｉｎｇ）など、多様な技術が研究されている。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本明細書は、ＳＳＢ（ＳＳ Ｂｌｏｃｋ）に２つのＰＲＡＣＨリソースを関連させて新しいビームに対する曖昧性を解消できる方法を提供することに目的がある。

【0005】

また、本明細書は、ＳＳＢと、ＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）が両方とも臨界値以上の品質を有する場合、優先順位を設定してビーム使用効率を高める方法を提供することに目的がある。

【0006】

本発明で解決しようとする技術的課題は、以上で言及した技術的課題に制限されず、言及しないまた別の技術的課題は、以下の記載から本発明が属する技術分野で通常の知識を有する者にとって明確に理解されるべきである。

【課題を解決するための手段】

【0007】

本明細書は、無線通信システムにおいてビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）を行う方法を提供する。端末により行われる方法は、ビーム失敗を検出するステップと、前記ビーム失敗復旧のための新しいビーム（ｎｅｗ ｂｅａｍ）を識別するステップと、ビーム失敗復旧要求（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソースを利用して基地局に送信するステップと、を含み、前記ＰＲＡＣＨリソースは第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ Ｂｌｏｃｋ）と関連し、前記ＳＳＢが新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを使用して送信され、ＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）リソースが前記新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用して送信されることを特徴とする。

【0008】

また、本明細書において、前記ＣＳＩ－ＲＳリソースは前記ＳＳＢと空間的にＱＣＬ（ｑｕａｓｉ－ｃｏｌｏｃａｔｅｄ）されていることを特徴とする。

【0009】

また、本明細書において、前記新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）であることを特徴とする。

【0010】

また、本明細書において、前記ＳＳＢ及び前記ＣＳＩ－ＲＳリソースが両方とも前記予め定義された条件を満たす場合、前記ＣＳＩ－ＲＳリソースが前記新しいビームとして識別されることを特徴とする。

【0011】

また、本明細書において、無線通信システムにおいてビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）を行う方法であって、基地局により行われる方法は、前記ビーム失敗復旧のための新しいビーム識別に関する情報を端末に送信するステップと、ビーム失敗復旧要求（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソースを利用して端末から受信するステップと、を含み、前記ＰＲＡＣＨリソースは第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ Ｂｌｏｃｋ）と関連し、前記新しいビームが前記ＳＳＢである場合、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを使用し、前記新しいビームがＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）リソースである場合、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用することを特徴とする。

【0012】

また、本明細書において、前記ＣＳＩ－ＲＳリソースは前記ＳＳＢと空間的にＱＣＬ（ｑｕａｓｉ－ｃｏｌｏｃａｔｅｄ）されていることを特徴とする。

【0013】

また、本明細書において、前記新しいビームは予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）であることを特徴とする。

【0014】

また、本明細書において、前記ＳＳＢ及び前記ＣＳＩ－ＲＳリソースが両方とも前記予め定義された条件を満たす場合、前記ＣＳＩ－ＲＳリソースが前記端末により前記新しいビームとして識別されることを特徴とする。

【0015】

また、本明細書において、無線通信システムにおいてビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）を行う端末は、無線信号を送受信するためのＲＦモジュール（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ ｍｏｄｕｌｅ）と、前記ＲＦモジュールと機能的に接続されているプロセッサと、を含み、前記プロセッサは、ビーム失敗を検出し、前記ビーム失敗復旧のための新しいビーム（ｎｅｗ ｂｅａｍ）を識別し、ビーム失敗復旧要求（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソース（ｒｅｓｏｕｒｃｅ）を利用して基地局に送信し、前記ＰＲＡＣＨリソースは第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含み、前記第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ Ｂｌｏｃｋ）と関連し、前記ＳＳＢが新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第１ＰＲＡＣＨリソースを使用して送信され、ＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）リソースが前記新しいビームとして識別された場合、前記ビーム失敗復旧要求は前記第２ＰＲＡＣＨリソースを使用して送信されることを特徴とする。

【0016】

また、本明細書において、前記ＣＳＩ－ＲＳリソースはＳＳＢと空間的にＱＣＬ（ｑｕａｓｉ－ｃｏｌｏｃａｔｅｄ）されていることを特徴とする。

【0017】

また、本明細書において、前記新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）であることを特徴とする。

【0018】

また、本明細書において、前記ＳＳＢ及び前記ＣＳＩ－ＲＳリソースが両方とも前記予め定義された条件を満たす場合、前記ＣＳＩ－ＲＳリソースが前記新しいビームとして識別されることを特徴とする。

【発明の効果】

【0019】

本明細書は、ＳＳＢ（ＳＳ Ｂｌｏｃｋ）に２つのＰＲＡＣＨリソース（Ｒｅｓｏｕｒｃｅ）を関連させて新しいビームに対する曖昧性を解消することができる。

【0020】

また、本明細書は、ＳＳＢと、ＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）が両方とも臨界値以上の品質を有する場合、優先順位を設定してビームの使用効率を高めることができる。

【0021】

本発明で得ることができる効果は、以上で言及した効果に制限されるものではなく、言及していないまた別の効果は、以下の記載から本発明が属する技術分野で通常の知識を有する者にとって明確に理解されるべきである。

【図面の簡単な説明】

【0022】

本発明に関する理解を助けるために詳細な説明の一部に含まれる添付図は、本発明に対する実施形態を提供し、詳細な説明と共に本発明の技術的特徴を説明する。

【0023】

【図1】本明細書で提案する方法が適用できるＮＲの全体的なシステム構造の一例を示した図である。

【図2】本明細書で提案する方法が適用できる無線通信システムにおけるアップリンクフレームとダウンリンクフレームとの間の関係を示す。

【図3】本明細書で提案する方法が適用できる無線通信システムでサポートするリソースグリッド（ｒｅｓｏｕｒｃｅ ｇｒｉｄ）の一例を示す。

【図4】本明細書で提案する方法が適用できるアンテナポート及びヌメロロジー別リソースグリッドの例を示す。

【図5】アナログビームフォーマ（ａｎａｌｏｇ ｂｅａｍｆｏｒｍｅｒ）及びＲＦチェーン（ＲＦ ｃｈａｉｎ）で構成される送信端（ｔｒａｎｓｍｉｔｔｅｒ）のブロック図（ｂｌｏｃｋ ｄｉａｇｒａｍ）の一例を示す。

【図6】デジタルビームフォーマ（ｄｉｇｉｔａｌ ｂｅａｍｆｏｒｍｅｒ）及びＲＦチェーンで構成される送信端のブロック図の一例を示す。

【図7】アナログビームスキャニング方式の一例を示す。

【図8】ＰＵＳＣＨ ＣＳＩ報告モードの一例を示した図である。

【図9】ＰＵＣＣＨ ＣＳＩ報告モードの一例を示した図である。

【図10】代替ビームの存在有無によるネットワーク動作の一例を示す。

【図11】ビーム関連の設定方法の一例を示した図である。

【図12】ビーム復旧を行う方法の一例を示したフローチャートである。

【図13】ビーム復旧を行う端末の動作の一例を示したフローチャートである。

【図14】ビーム復旧を行う端末の動作のまた別の一例を示したフローチャートである。

【図15】ビーム失敗復旧手続の一例を示したフローチャートである。

【図16】本明細書で提案する方法に適用できるＣＳＩ－ＲＳ及びＳＳブロックの空間カバレッジ（ｓｐａｔｉａｌ ｃｏｖｅｒａｇｅ）の一例を示した図である。

【図17】本明細書で提案するビーム失敗復旧のための端末の動作方法の一例を示したフローチャートである。

【図18】本明細書で提案するビーム失敗復旧のための基地局の動作方法の一例を示したフローチャートである。

【図19】本発明の一実施形態に係る無線通信装置のブロック構成図を例示する。

【図20】本発明の一実施形態に係る通信装置のブロック構成図を例示する。

【図21】本明細書で提案する方法が適用できる無線通信装置のＲＦモジュールの一例を示した図である。

【図22】本明細書で提案する方法が適用できる無線通信装置のＲＦモジュールのまた他の一例を示した図である。

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

【0024】

以下、本発明に係る好ましい実施形態を添付した図面を参照して詳細に説明する。添付した図面と共に以下に開示される詳細な説明は、本発明の例示的な実施形態を説明しようとするものであり、本発明が実施できる唯一の実施形態を示そうとするものではない。以下の詳細な説明は、本発明の完全な理解を提供するために、具体的な細部事項を含む。しかしながら、当業者は、本発明がこのような具体的な細部事項がなくとも実施できるということが分かる。

【0025】

幾つかの場合、本発明の概念が曖昧になることを避けるために公知の構造及び装置は省略されるか、または各構造及び装置の中核機能を中心としたブロック図の形式で示されることができる。

【0026】

本明細書において、基地局は、端末と直接的に通信を行うネットワークの終端ノード（ｔｅｒｍｉｎａｌ ｎｏｄｅ）としての意味を有する。本文書において基地局により行われると説明された特定の動作は、場合によっては、基地局の上位ノード（ｕｐｐｅｒ ｎｏｄｅ）により行われてもよい。すなわち、基地局を含む複数のネットワークノード（ｎｅｔｗｏｒｋ ｎｏｄｅｓ）からなるネットワークにおいて端末との通信のために行われる多様な動作は、基地局または基地局以外の他のネットワークノードにより行われ得ることは自明である。「基地局（ＢＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）」は、固定局（ｆｉｘｅｄ ｓｔａｔｉｏｎ）、Ｎｏｄｅ Ｂ、ｅＮＢ（ｅｖｏｌｖｅｄ－ＮｏｄｅＢ）、ＢＴＳ（ｂａｓｅｔｒａｎｓｃｅｉｖｅｒ ｓｙｓｔｅｍ）、アクセスポイント（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）、ｇＮＢ（ｇｅｎｅｒａｌ ＮＢ）などの用語により代替され得る。また、「端末（Ｔｅｒｍｉｎａｌ）」は、固定されるか、または移動性を有することができ、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＵＴ（ｕｓｅｒ ｔｅｒｍｉｎａｌ）、ＭＳＳ（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ＡＭＳ（Ａｄｖａｎｃｅｄ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＷＴ（Ｗｉｒｅｌｅｓｓ ｔｅｒｍｉｎａｌ）、ＭＴＣ（Ｍａｃｈｉｎｅ－Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）装置、Ｍ２Ｍ（Ｍａｃｈｉｎｅ－ｔｏ－Ｍａｃｈｉｎｅ）装置、Ｄ２Ｄ（Ｄｅｖｉｃｅ－ｔｏ－Ｄｅｖｉｃｅ）装置などの用語に代替され得る。

【0027】

以下で、ダウンリンク（ＤＬ：ｄｏｗｎｌｉｎｋ）は基地局から端末への通信を意味し、アップリンク（ＵＬ：ｕｐｌｉｎｋ）は端末から基地局への通信を意味する。ダウンリンクにおける送信機は基地局の一部であり、受信機は端末の一部であり得る。アップリンクにおける送信機は端末の一部であり、受信機は基地局の一部であり得る。

【0028】

以下の説明で使われる特定用語は本発明の理解を助けるために提供されたものであり、このような特定用語の使用は本発明の技術的思想を外れない範囲で異なる形態に変更され得る。

【0029】

以下の技術は、ＣＤＭＡ（ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＴＤＭＡ（ｔｉｍｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＳＣ-ＦＤＭＡ（ｓｉｎｇｌｅ ｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＮＯＭＡ（ｎｏｎ-ｏｒｔｈｏｇｏｎａｌｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）などの多様な無線アクセスシステムに利用できる。ＣＤＭＡは、ＵＴＲＡ（ｕｎｉｖｅｒｓａｌ ｔｅｒｒｅｓｔｒｉａｌ ｒａｄｉｏ ａｃｃｅｓｓ）やＣＤＭＡ２０００のような無線技術（ｒａｄｉｏ ｔｅｃｈｎｏｌｏｇｙ）で具現できる。ＴＤＭＡは、ＧＳＭ（ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）／ＧＰＲＳ（ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅ）／ＥＤＧＥ（ｅｎｈａｎｃｅｄ ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ ｅｖｏｌｕｔｉｏｎ）のような無線技術で具現できる。ＯＦＤＭＡは、ＩＥＥＥ ８０２．１１（ＷｉＦｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２－２０、Ｅ-ＵＴＲＡ（ｅｖｏｌｖｅｄ ＵＴＲＡ）などの無線技術で具現できる。ＵＴＲＡは、ＵＭＴＳ（ｕｎｉｖｅｒｓａｌ ｍｏｂｉｌｅ ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｙｓｔｅｍ）の一部である。３ＧＰＰ（３ｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ）ＬＴＥ（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）は、Ｅ-ＵＴＲＡを使用するＥ－ＵＭＴＳ（ｅｖｏｌｖｅｄ ＵＭＴＳ）の一部であって、ダウンリンクでＯＦＤＭＡを採用し、アップリンクでＳＣ－ＦＤＭＡを採用する。ＬＴＥ－Ａ（ａｄｖａｎｃｅｄ）は３ＧＰＰ ＬＴＥの進化である。

【0030】

５Ｇ ＮＲ（ｎｅｗ ｒａｄｉｏ）はｕｓａｇｅ ｓｃｅｎａｒｉｏに従って、ｅＭＢＢ（ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）、ｍＭＴＣ（ｍａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、Ｖ２Ｘ（ｖｅｈｉｃｌｅ－ｔｏ－ｅｖｅｒｙｔｈｉｎｇ）定義する。

【0031】

そして、５Ｇ ＮＲ規格（ｓｔａｎｄａｒｄ）は、ＮＲシステムとＬＴＥシステムとの間の共存（ｃｏ－ｅｘｉｓｔｅｎｃｅ）によってＳＡ（ｓｔａｎｄａｌｏｎｅ：ＳＡ）とＮＳＡ（ｎｏｎ－ｓｔａｎｄａｌｏｎｅ）に区分する。

【0032】

そして、５Ｇ ＮＲは、様々なサブキャリア間隔（Ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）をサポートし、ダウンリンクにおいてＣＰ－ＯＦＤＭを、アップリンクにおいてＣＰ－ＯＦＤＭ及びＤＦＴ－ｓ－ＯＦＤＭ（ＳＣ－ＯＦＤＭ）をサポートする。

【0033】

本発明の実施形態は、無線アクセスシステムであるＩＥＥＥ ８０２、３ＧＰＰ及び３ＧＰＰ２の少なくとも１つに開示された標準文書によって裏付けられることができる。即ち、本発明の実施形態のうち、本発明の技術的思想を明確に示すために、説明しない段階又は部分は前記文書によって裏付けられることができる。また、本文書で開示している全ての用語は、前記標準文書によって説明されることができる。

【0034】

説明を明確にするために、３ＧＰＰ ＬＴＥ／ＬＴＥ－Ａ／ＮＲ（Ｎｅｗ Ｒａｄｉｏ）を中心に記述するが、本発明の技術的特徴がこれに制限されるわけではない。

【0035】

用語の定義

【0036】

ｅＬＴＥ ｅＮＢ：ｅＬＴＥ ｅＮＢは、ＥＰＣ及びＮＧＣに対する連結をサポートするｅＮＢの進化（ｅｖｏｌｕｔｉｏｎ）である。

【0037】

ｇＮＢ：ＮＧＣとの連結だけでなく、ＮＲをサポートするノード。

【0038】

新しいＲＡＮ：ＮＲ又はＥ－ＵＴＲＡをサポートするか、ＮＧＣと相互作用する無線アクセスネットワーク。

【0039】

ネットワークスライス（ｎｅｔｗｏｒｋ ｓｌｉｃｅ）：ネットワークスライスは、終端間の範囲と共に特定の要求事項を要求する特定の市場シナリオに対して最適化されたソリューションを提供するようにオペレータによって定義されたネットワーク。

【0040】

ネットワーク機能（ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎ）：ネットワーク機能は、よく定義された外部のインターフェースと、よく定義された機能的動作を有するネットワークインフラ内での論理的ノード。

【0041】

ＮＧ－Ｃ：新しいＲＡＮとＮＧＣ間のＮＧ２リファレンスポイント（ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ）に使用されるコントロールプレーンインターフェース。

【0042】

ＮＧ－Ｕ：新しいＲＡＮとＮＧＣ間のＮＧ３リファレンスポイント（ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ）に使用されるユーザプレーンインターフェース。

【0043】

非独立型（Ｎｏｎ－ｓｔａｎｄａｌｏｎｅ）ＮＲ：ｇＮＢがＬＴＥ ｅＮＢをＥＰＣにコントロールプレーンの連結のためのアンカーとして要求するか、又はｅＬＴＥ ｅＮＢをＮＧＣにコントロールプレーンの連結のためのアンカーとして要求する配置構成。

【0044】

非独立型Ｅ－ＵＴＲＡ：ｅＬＴＥ ｅＮＢがＮＧＣにコントロールプレーンの連結のためのアンカーとしてｇＮＢを要求する配置構成。

【0045】

ユーザプレーンゲートウェイ：ＮＧ－Ｕインターフェースの終端点。

【0046】

システム一般

【0047】

図１は、本明細書で提案する方法が適用できるＮＲの全体的なシステム構造の一例を示した図である。

【0048】

図１を参照すると、ＮＧ-ＲＡＮはＮＧ-ＲＡユーザプレーン（新しいＡＳ ｓｕｂｌａｙｅｒ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）及びＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）に対するコントロールプレーン（ＲＲＣ）プロトコル終端を提供するｇＮＢで構成される。

【0049】

前記ｇＮＢは、Ｘｎインターフェースを介して相互連結される。

【0050】

前記ｇＮＢは、また、ＮＧインターフェースを介してＮＧＣに連結される。

【0051】

より具体的には、前記ｇＮＢはＮ２インターフェースを介してＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）に、Ｎ３インターフェースを介してＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）に連結される。

【0052】

ＮＲ（Ｎｅｗ Ｒａｔ）ヌメロロジー（Ｎｕｍｅｒｏｌｏｇｙ）及びフレーム（ｆｒａｍｅ）構造

【0053】

ＮＲシステムでは、多数のヌメロロジー（ｎｕｍｅｒｏｌｏｇｙ）がサポートできる。ここで、ヌメロロジーはサブキャリア間隔（ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）とＣＰ（Ｃｙｃｌｉｃ Ｐｒｅｆｉｘ）のオーバーヘッドにより定義されることができる。このとき、多数のサブキャリア間隔は基本サブキャリア間隔を整数Ｎ（または、μ）にスケーリング（ｓｃａｌｉｎｇ）することにより誘導できる。また、非常に高い搬送波周波数で非常に低いサブキャリア間隔を用いないと仮定されても、用いられるヌメロロジーは周波数帯域と独立に選択されることができる。

【0054】

また、ＮＲシステムでは多数のヌメロロジーに従う多様なフレーム構造がサポートされることができる。

【0055】

以下、ＮＲシステムで考慮されることができるＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）ヌメロロジー及びフレーム構造を見る。

【0056】

ＮＲシステムでサポートされる多数のＯＦＤＭヌメロロジーは、表１のように定義されることができる。

【0057】

【表1】

【0058】

ＮＲシステムにおけるフレーム構造（ｆｒａｍｅｓｔｒｕｃｔｕｒｅ）と関連して、時間領域の多様なフィールドのサイズは

の時間単位の倍数で表現される。ここで、

であり、

である。ダウンリンク（ｄｏｗｎｌｉｎｋ）及びアップリンク（ｕｐｌｉｎｋ）送信は

の区間を有する無線フレーム（ｒａｄｉｏ ｆｒａｍｅ）で構成される。ここで、無線フレームは各々

の区間を有する１０個のサブフレーム（ｓｕｂｆｒａｍｅ）で構成される。この場合、アップリンクに対する１セットのフレーム及びダウンリンクに対する１セットのフレームが存在することができる。

【0059】

図２は、本明細書で提案する方法が適用できる無線通信システムにおけるアップリンクフレームとダウンリンクフレームとの間の関係を示す。

【0060】

図２に示すように、端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ）からのアップリンクフレーム番号ｉの送信は、該当端末での該当ダウンリンクフレームの開始より

以前に開始しなければならない。

【0061】

ヌメロロジーμに対して、スロット（ｓｌｏｔ）はサブフレーム内で

の増加する順に番号が付けられて、無線フレーム内で

の増加する順に番号が付けられる。１つのスロットは

の連続するＯＦＤＭシンボルで構成され、

は用いられるヌメロロジー及びスロット設定（ｓｌｏｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ）によって決定される。サブフレームでスロット

の開始は同じサブフレームでＯＦＤＭシンボル

の開始と時間的に整列される。

【0062】

全ての端末が同時に送信及び受信できるものではなく、これはダウンリンクスロット（ｄｏｗｎｌｉｎｋ ｓｌｏｔ）又はアップリンクスロット（ｕｐｌｉｎｋ ｓｌｏｔ）の全てのＯＦＤＭシンボルが用いられることはできないということを意味する。

【0063】

表２はヌメロロジーμでの一般（ｎｏｒｍａｌ）ＣＰに対するスロット当たりのＯＦＤＭシンボルの数を示し、表３はヌメロロジーμでの拡張（ｅｘｔｅｎｄｅｄ）ＣＰに対するスロット当たりのＯＦＤＭシンボルの数を示す。

【0064】

【表2】

【0065】

【表3】

【0066】

ＮＲ物理リソース（ＮＲ Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ）

【0067】

ＮＲシステムにおける物理リソース（ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ）と関連して、アンテナポート（ａｎｔｅｎｎａ ｐｏｒｔ）、リソースグリッド（ｒｅｓｏｕｒｃｅ ｇｒｉｄ）、リソース要素（ｒｅｓｏｕｒｃｅ ｅｌｅｍｅｎｔ）、リソースブロック（ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）、キャリアパート（ｃａｒｒｉｅｒ ｐａｒｔ）などが考慮できる。

【0068】

以下、ＮＲシステムで考慮できる前記物理リソースに対して具体的に見る。

【0069】

まず、アンテナポートと関連して、アンテナポートはアンテナポート上のシンボルが運搬されるチャネルが同じアンテナポート上の他のシンボルが運搬されるチャネルから推論できるように定義される。１つのアンテナポート上のシンボルが運搬されるチャネルの広範囲特性（ｌａｒｇｅ-ｓｃａｌｅ ｐｒｏｐｅｒｔｙ）が他のアンテナポート上のシンボルが運搬されるチャネルから類推できる場合、２つのアンテナポートはＱＣ／ＱＣＬ（ｑｕａｓｉｃｏ-ｌｏｃａｔｅｄまたはｑｕａｓｉ ｃｏ-ｌｏｃａｔｉｏｎ）関係にあるということができる。ここで、前記広範囲特性は遅延拡散（Ｄｅｌａｙ ｓｐｒｅａｄ）、ドップラー拡散（Ｄｏｐｐｌｅｒ ｓｐｒｅａｄ）、周波数シフト（Ｆｒｅｑｕｅｎｃｙ ｓｈｉｆｔ）、平均受信パワー（Ａｖｅｒａｇｅ ｒｅｃｅｉｖｅｄ ｐｏｗｅｒ）、受信タイミング（Ｒｅｃｅｉｖｅｄ Ｔｉｍｉｎｇ）のうち、１つ以上を含む。

【0070】

図３は、本明細書で提案する方法が適用できる無線通信システムでサポートするリソースグリッド（ｒｅｓｏｕｒｃｅ ｇｒｉｄ）の一例を示す。

【0071】

図３を参考すると、リソースグリッドが周波数領域上に

サブキャリアで構成され、１つのサブフレームが１４・２μＯＦＤＭシンボルで構成されることを例示的に記述するが、これに限定されるものではない。

【0072】

ＮＲシステムにおいて、送信される信号（ｔｒａｎｓｍｉｔｔｅｄ ｓｉｇｎａｌ）は

サブキャリアで構成される１つまたはそれ以上のリソースグリッド及び

のＯＦＤＭシンボルにより説明される。ここで、

である。前記

は最大送信帯域幅を示し、これは、ヌメロロジーだけでなく、アップリンクとダウンリンクとの間でも変わり得る。

【0073】

この場合、図４のように、ヌメロロジーμ及びアンテナポートｐ別に１つのリソースグリッドが設定できる。

【0074】

図４は、本明細書で提案する方法が適用できるアンテナポート及びヌメロロジー別のリソースグリッドの例を示す。

【0075】

ヌメロロジーμ及びアンテナポートｐに対するリソースグリッドの各要素はリソース要素（ｒｅｓｏｕｒｃｅ ｅｌｅｍｅｎｔ）と称され、インデックス対

により固有的に識別される。ここで、

は周波数領域上のインデックスであり、

はサブフレーム内でシンボルの位置を称する。スロットでリソース要素を称する時には、インデックス対

が用いられる。ここで、

である。

【0076】

ヌメロロジーμ及びアンテナポートｐに対するリソース要素

は複素値（ｃｏｍｐｌｅｘ ｖａｌｕｅ）

に該当する。混同（ｃｏｎｆｕｓｉｏｎ）する危険がない場合、または特定アンテナポートまたはヌメロロジーが特定されない場合には、インデックスｐ及びμはドロップ（ｄｒｏｐ）されることができ、その結果、複素値は

または

になることができる。

【0077】

また、物理リソースブロック（ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）は周波数領域上の

の連続的なサブキャリアで定義される。周波数領域上で、物理リソースブロックは０から

まで番号が付けられる。このとき、周波数領域上の物理リソースブロック番号（ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ ｎｕｍｂｅｒ）

とリソース要素

との間の関係は、数式１のように与えられる。

【0078】

【数1】

【0079】

また、キャリアパート（ｃａｒｒｉｅｒ ｐａｒｔ）と関連して、端末はリソースグリッドのサブセット（ｓｕｂｓｅｔ）のみを用いて受信または送信するように設定されることができる。このとき、端末が受信又は送信するように設定されたリソースブロックの集合（ｓｅｔ）は周波数領域上で０から

まで番号が付けられる。

【0080】

アップリンク制御チャネル（Ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）

【0081】

物理アップリンク制御シグナリング（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｓｉｇｎａｌｉｎｇ）は、少なくともｈｙｂｒｉｄ－ＡＲＱ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＣＳＩ報告（ＣＳＩ ｒｅｐｏｒｔ）（可能であれば、ビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）情報を含む）、及びスケジューリング要求（ｓｃｈｅｄｕｌｉｎｇ ｒｅｑｕｅｓｔ）を運ぶことができなければならない。

【0082】

ＮＲシステムでサポートするアップリンク制御チャネル（ＵＬ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）に対して少なくとも二つの送信方法がサポートされる。

【0083】

アップリンク制御チャネルは、スロット（ｓｌｏｔ）の最後に送信されたアップリンクシンボルの周囲で短期間（ｓｈｏｒｔ ｄｕｒａｔｉｏｎ）で送信されることができる。この場合、アップリンク制御チャネルはスロット内でアップリンクデータチャネル（ＵＬ ｄａｔａ ｃｈａｎｎｅｌ）と時間－分割－多重化（ｔｉｍｅ－ｄｉｖｉｓｉｏｎ－ｍｕｌｔｉｐｌｅｘｅｄ）及び／又は周波数－分割－多重化（ｆｒｅｑｕｅｎｃｙ－ｄｉｖｉｓｉｏｎ－ｍｕｌｔｉｐｌｅｘｅｄ）される。短期間のアップリンク制御チャネルに対して、スロットの１シンボル単位の送信がサポートされる。

【0084】

－短いアップリンク制御情報（Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ、ＵＣＩ）及びデータは、少なくとも短いＵＣＩ及びデータに対する物理リソースブロック（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ、ＰＲＢ）が重ならない場合、端末（ＵＥ）及び端末間で周波数－分割－多重化される。

【0085】

－同じスロット内の異なる端末からの短いＰＵＣＣＨ（ｓｈｏｒｔ ＰＵＣＣＨ）の時間分割多重化（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ、ＴＤＭ）をサポートするために、短いＰＵＣＣＨを送信するスロット内のシンボルが、少なくとも６ＧＨｚ以上でサポートされるか否かを端末に知らせるメカニズム（ｍｅｃｈａｎｉｓｍ）がサポートされる。

【0086】

－１シンボル期間（１－ｓｙｍｂｏｌ ｄｕｒａｔｉｏｎ）に対しては、少なくとも１）参照信号（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ、ＲＳ）が多重化されると、ＵＣＩとＲＳは周波数分割多重化（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ、ＦＤＭ）方式で与えられたＯＦＤＭシンボルに多重化される点、及び２）同じスロットでダウンリンク（ＤＬ）／アップリンク（ＵＬ）データと短期間のＰＵＣＣＨとの間のサブキャリア間隔（ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）が同一である点がサポートされる。

【0087】

－少なくとも、スロットの２シンボル期間（２－ｓｙｍｂｏｌ ｄｕｒａｔｉｏｎ）にかけた短期間のＰＵＣＣＨがサポートされる。このとき、同じスロットでダウンリンク（ＤＬ）／アップリンク（ＵＬ）データと短期間のＰＵＣＣＨとの間のサブキャリア間隔が同一である。

【0088】

－少なくとも、スロット内の与えられた端末のＰＵＣＣＨリソース、即ち、異なる端末の短いＰＵＣＣＨは、スロットで与えられた持続期間（ｄｕｒａｔｉｏｎ）内に時分割多重化されることができる半静的構成（ｓｅｍｉ－ｓｔａｔｉｃ ｃｏｎｆｉｇｕｒａｔｉｏｎ）がサポートされる。

【0089】

－ＰＵＣＣＨリソースには、時間領域（ｔｉｍｅ ｄｏｍａｉｎ）、周波数領域（ｆｒｅｑｕｅｎｃｙ ｄｏｍａｉｎ）、及び適用可能な場合には、コード領域（ｃｏｄｅ ｄｏｍａｉｎ）が含まれる。

【0090】

－短期間のＰＵＣＣＨは、端末の観点から、スロットの端まで拡張されることができる。このとき、短期間のＰＵＣＣＨ以降、明示的なギャップシンボル（ｅｘｐｌｉｃｉｔ ｇａｐ ｓｙｍｂｏｌ）が不要である。

【0091】

－短いアップリンク部分（ｓｈｏｒｔ ＵＬ ｐａｒｔ）を有するスロット（即ち、ＤＬ中心のスロット（ＤＬ－ｃｅｎｔｒｉｃ ｓｌｏｔ））に対して、データが短いアップリンク部分でスケジューリング（ｓｃｈｅｄｕｌｉｎｇ）されると、「短いＵＣＩ」及びデータは、１つの端末によって周波数分割多重化されることができる。

【0092】

アップリンク制御チャネルは、カバレッジ（ｃｏｖｅｒａｇｅ）を改善するために、多数のアップリンクシンボルにかけて長期間（ｌｏｎｇ－ｄｕｒａｔｉｏｎ）で送信されることができる。この場合、アップリンク制御チャネルは、スロット内のアップリンクデータチャネルと周波数分割多重化される。

【0093】

－少なくともＰＡＰＲ（Ｐｅａｋ ｔｏ Ａｖｅｒａｇｅ Ｐｏｗｅｒ Ｒａｔｉｏ）が低い設計で長時間のアップリンク制御チャネル（ｌｏｎｇ ｄｕｒａｔｉｏｎ ＵＬ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）によって運ばれるＵＣＩは、１つのスロット又は多数のスロットで送信されることができる。

【0094】

－多数のスロットを用いる送信は、少なくとも一部の場合に、総持続時間（ｔｏｔａｌ ｄｕｒａｔｉｏｎ）（例：１ｍｓ）の間に許容される。

【0095】

－長時間のアップリンク制御チャネルの場合、ＲＳとＵＣＩ間の時間分割多重化（ＴＤＭ）は、ＤＦＴ－Ｓ－ＯＦＤＭに対してサポートされる。

【0096】

－スロットの長いアップリンク部分（ｌｏｎｇ ＵＬ ｐａｒｔ）は、長時間のＰＵＣＣＨ送信に用いられることができる。即ち、長時間のＰＵＣＣＨはアップリンク専用のスロット（ＵＬ－ｏｎｌｙ ｓｌｏｔ）と最小４個のシンボルで構成される可変個数のシンボルを有するスロットの全てに対してサポートされる。

【0097】

－少なくとも１又は２ビットのＵＣＩに対して、前記ＵＣＩはＮ個のスロット（Ｎ＞１）内で繰り返されてもよく、前記Ｎ個のスロットは長時間のＰＵＣＣＨが許容されるスロットで隣接してもよく、又は隣接しなくてもよい。

【0098】

－少なくとも長いＰＵＣＣＨ（ｌｏｎｇ ＰＵＣＣＨ）に対して、ＰＵＳＣＨとＰＵＣＣＨの同時送信（ｓｉｍｕｌｔａｎｅｏｕｓ ｔｒａｎｓｍｉｓｓｉｏｎ）がサポートされる。即ち、データが存在する場合にも、ＰＵＣＣＨリソースに対するアップリンク制御が送信される。また、ＰＵＣＣＨ－ＰＵＳＣＨの同時送信以外にも、ＰＵＳＣＨでのＵＣＩがサポートされる。

【0099】

－ＴＴＩ内でのスロット周波数ホッピング（ｉｎｔｒａ－ＴＴＩ ｓｌｏｔ ｆｒｅｑｕｅｎｃｙ ｈｏｐｐｉｎｇ）がサポートされる。

【0100】

－ＤＦＴ－ｓ－ＯＦＤＭの波形（ｗａｖｅｆｏｒｍ）がサポートされる。

【0101】

－送信アンテナダイバーシティ（ｔｒａｎｓｍｉｔ ａｎｔｅｎｎａ ｄｉｖｅｒｓｉｔｙ）がサポートされる。

【0102】

短期間のＰＵＣＣＨと長期間のＰＵＣＣＨとの間のＴＤＭ及びＦＤＭは、少なくとも１つのスロットで別の端末に対してサポートされる。周波数領域で、ＰＲＢ（又は多数のＰＲＢ）はアップリンク制御チャネルに対する最小リソース単位サイズ（ｍｉｎｉｍｕｍ ｒｅｓｏｕｒｃｅ ｕｎｉｔ ｓｉｚｅ）である。ホッピング（ｈｏｐｐｉｎｇ）が用いられる場合、周波数リソース及びホッピングは、キャリア帯域幅（ｃａｒｒｉｅｒ ｂａｎｄｗｉｄｔｈ）に拡散されないことがある。また、端末特定ＲＳは、ＮＲ－ＰＵＣＣＨ送信に用いられる。ＰＵＣＣＨリソースの集合（ｓｅｔ）は、上位層のシグナリング（ｈｉｇｈｅｒ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）によって設定され、設定された集合内のＰＵＣＣＨリソースは、ダウンリンク制御情報（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ、ＤＣＩ）によって指示される。

【0103】

ＤＣＩの一部であって、データ受信（ｄａｔａ ｒｅｃｅｐｔｉｏｎ）とｈｙｂｒｉｄ－ＡＲＱ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ送信間のタイミング（ｔｉｍｉｎｇ）は、ダイナミックに（ｄｙｎａｍｉｃａｌｌｙ）（少なくともＲＲＣと共に）指示できなければならない。半静的構成（ｓｅｍｉ－ｓｔａｔｉｃ ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び（少なくとも一部類型のＵＣＩ情報に対する）ダイナミックなシグナリング（ｄｙｎａｍｉｃ ｓｉｇｎａｌｉｎｇ）の結合は、「長い及び短いＰＵＣＣＨフォーマット」に対するＰＵＣＣＨリソースを決定するために用いられる。ここで、ＰＵＣＣＨリソースは、時間領域、周波数領域、及び適用可能な場合には、コード領域を含む。ＰＵＳＣＨ上のＵＣＩ、即ち、ＵＣＩに対するスケジュールされたリソースの一部を使用することはＵＣＩとデータの同時送信の場合にサポートされる。

【0104】

また、少なくとも単一のＨＡＲＱ－ＡＣＫビットのアップリンク送信が少なくともサポートされる。また、周波数ダイバーシティ（ｆｒｅｑｕｅｎｃｙ ｄｉｖｅｒｓｉｔｙ）を可能にするメカニズムがサポートされる。また、ＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ－Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の場合、端末に対して設定されたスケジューリング要求（ＳＲ）リソース間の時間間隔（ｔｉｍｅ ｉｎｔｅｒｖａｌ）は、１つのスロットよりも小さいことがある。

【0105】

ビーム管理（Ｂｅａｍ ｍａｎａｇｅｍｅｎｔ）

【0106】

ＮＲにおけるビーム管理は次のように定義される。

【0107】

ビーム管理（Ｂｅａｍ ｍａｎａｇｅｍｅｎｔ）：ＤＬ及びＵＬの送受信に使用されることができるＴＲＰ及び／又はＵＥビームのセット（ｓｅｔ）を取得して維持するためのＬ１／Ｌ２手続のセットであって、少なくとも次の事項を含む：

【0108】

－ビーム決定：ＴＲＰ又はＵＥが自身の送信／受信ビームを選択する動作。

【0109】

－ビーム測定：ＴＲＰ又はＵＥが受信されたビーム形成の信号の特性を測定する動作。

【0110】

－ビーム報告：ＵＥがビーム測定に基づいてビーム形成された信号の情報を報告する動作。

【0111】

－ビームスイーピング（Ｂｅａｍ ｓｗｅｅｐｉｎｇ）：予め決定された方式で時間間隔の間に送信及び／又は受信されたビームを用いて空間領域をカバーする動作。

【0112】

また、ＴＲＰ及びＵＥにおけるＴｘ／Ｒｘビームの対応（ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ）は、次のように定義される。

【0113】

－ＴＲＰにおけるＴｘ／Ｒｘビームの対応は、次のうち少なくとも１つが満たされると維持される。

【0114】

－ＴＲＰは、ＴＲＰの１つ以上の送信ビームに対するＵＥのダウンリンクの測定に基づいて、アップリンク受信のためのＴＲＰ受信ビームを決定することができる。

【0115】

－ＴＲＰは、ＴＲＰの１つ以上のＲｘビームに対するＴＲＰのアップリンクの測定に基づいて、ダウンリンク送信に対するＴＲＰ Ｔｘビームを決定することができる。

【0116】

－ＵＥにおけるＴｘ／Ｒｘビームの対応は、次のうち少なくとも１つが満たされると維持される。

【0117】

－ＵＥは、ＵＥの１つ以上のＲｘビームに対するＵＥのダウンリンクの測定に基づいて、アップリンク送信のためのＵＥ Ｔｘビームを決定することができる。

【0118】

－ＵＥは、１つ以上のＴｘビームに対するアップリンクの測定に基づいたＴＲＰの指示に基づいて、ダウンリンク受信のためのＵＥ受信ビームを決定することができる。

【0119】

－ＴＲＰにＵＥビームの対応に関する情報の能力指示がサポートされる。

【0120】

次のようなＤＬにおけるＬ１／Ｌ２のビーム管理手続が、１つ又は多数のＴＲＰ内でサポートされる。

【0121】

Ｐ－１：ＴＲＰ Ｔｘビーム／ＵＥ Ｒｘビームの選択をサポートするために、異なるＴＲＰ Ｔｘビームに対するＵＥの測定を可能にするために使用される。

【0122】

－ＴＲＰにおけるビームフォーミングの場合、一般に互いに異なるビームセットでイントラ（ｉｎｔｒａ）／インター（ｉｎｔｅｒ）－ＴＲＰ Ｔｘビームスイープ（ｓｗｅｅｐ）を含む。ＵＥにおけるビームフォーミングのために、それは通常異なるビームのセットからのＵＥ Ｒｘビームスイープを含む。

【0123】

Ｐ－２：異なるＴＲＰ Ｔｘビームに対するＵＥの測定が、インター／イントラ－ＴＲＰ Ｔｘビームを変更させるために使用される。

【0124】

Ｐ－３：ＵＥがビームフォーミングを使用する場合に、同じＴＲＰ Ｔｘビームに対するＵＥの測定が、ＵＥ Ｒｘビームを変更させるのに使用される。

【0125】

少なくともネットワークによってトリガーされた非周期的報告（ａｐｒｅｉｏｄｉｃ ｒｅｐｏｒｔｉｎｇ）は、Ｐ－１、Ｐ－２、及びＰ－３に関する動作でサポートされる。

【0126】

ビーム管理（少なくともＣＳＩ－ＲＳ）のためのＲＳに基づいたＵＥの測定は、Ｋ（ビームの総数）ビームで構成され、ＵＥは、選択されたＮ個のＴｘビームの測定結果を報告する。ここで、Ｎは、必ずしも固定された数ではない。移動性の目的のためのＲＳに基づいた手続は排除されない。報告情報は、少なくともＮ＜Ｋである場合、Ｎ個のビームに対する測定量及びＮ個のＤＬ送信ビームを示す情報を含む。特に、ＵＥがＫ’＞１ノン－ゼロ－パワー（ＮＺＰ）ＣＳＩ－ＲＳリソースに対して、ＵＥは、Ｎ’のＣＲＩ（ＣＳＩ－ＲＳリソースの指示子）を報告することができる。

【0127】

ＵＥはビーム管理のために次のような上位層のパラメータ（ｈｉｇｈｅｒ ｌａｙｅｒ ｐａｒａｍｅｔｅｒ）に設定されることができる。

【0128】

－Ｎ≧１報告設定（ｓｅｔｔｉｎｇ）、Ｍ≧１リソース設定

【0129】

－報告設定とリソース設定間のリンクは、合意されたＣＳＩ測定設定で設定される。

【0130】

－ＣＳＩ－ＲＳベースのＰ－１及びＰ－２は、リソース及び報告設定でサポートされる。

【0131】

－Ｐ－３は、報告設定の有無に関係なくサポートされることができる。

【0132】

－少なくとも以下の事項を含む報告設定（ｒｅｐｏｒｔｉｎｇ ｓｅｔｔｉｎｇ）

【0133】

－選択されたビームを示す情報

【0134】

－Ｌ１測定報告（Ｌ１ ｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔｉｎｇ）

【0135】

－時間領域動作（例：非周期的（ａｐｅｒｉｏｄｉｃ）動作、周期的（ｐｅｒｉｏｄｉｃ）動作、半持続的（ｓｅｍｉ－ｐｅｒｓｉｓｔｅｎｔ）動作）

【0136】

－色々な周波数細分性（ｆｒｅｑｕｅｎｃｙ ｇｒａｎｕｌａｒｉｔｙ）がサポートされる場合の周波数細分性

【0137】

－少なくとも以下の事項を含むリソース設定（ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）

【0138】

－時間領域動作（例：非周期的動作、周期的動作、半持続的動作）

【0139】

－ＲＳ類型：少なくともＮＺＰ ＣＳＩ－ＲＳ

【0140】

－少なくとも１つのＣＳＩ－ＲＳリソースのセット。各ＣＳＩ－ＲＳリソースのセットは、Ｋ≧１ ＣＳＩ－ＲＳリソースを含む（Ｋ個のＣＳＩ－ＲＳリソースの一部パラメータは同一であってもよい。例えば、ポートの番号、時間領域動作、密度、及び周期）

【0141】

また、ＮＲは、Ｌ＞１であるＬグループを考慮し、次のビーム報告をサポートする。

【0142】

－最小限のグループを示す情報

【0143】

－Ｎ１ビームに対する測定量（ｍｅａｓｕｒｅｍｅｎｔ ｑｕａｎｔｉｔｙ）（Ｌ１ ＲＳＲＰ及びＣＳＩ報告サポート（ＣＳＩ－ＲＳがＣＳＩ取得のための場合））

【0144】

－適用可能な場合、Ｎ１個のＤＬ送信ビームを示す情報

【0145】

前述したようなグループベースのビーム報告は、ＵＥ単位で構成することができる。また、前記グループベースのビーム報告は、ＵＥ単位でターンオフ（ｔｕｒｎ－ｏｆｆ）されることができる（例えば、Ｌ＝１又はＮｌ＝１である場合）。

【0146】

ＮＲは、ＵＥがビーム失敗から復旧するメカニズムをトリガーすることができることをサポートする。

【0147】

ビーム失敗（ｂｅａｍ ｆａｉｌｕｒｅ）のイベントは、関連した制御チャネルのビーム対リンク（ｂｅａｍ ｐａｉｒ ｌｉｎｋ）の品質が充分に低いときに発生する（例えば、臨界値との比較、関連したタイマーのタイムアウト）。ビーム失敗（又は障害）から復旧するメカニズムは、ビーム障害が発生するときにトリガーされる。

【0148】

ネットワークは、復旧の目的でＵＬ信号を送信するためのリソースを有するＵＥに明示的に構成する。リソースの構成は、基地局が全体又は一部方向から（例えば、ｒａｎｄｏｍ ａｃｃｅｓｓ ｒｅｇｉｏｎ）聴取（ｌｉｓｔｅｎｉｎｇ）するところでサポートされる。

【0149】

ビーム障害を報告するＵＬ送信／リソースは、ＰＲＡＣＨ（ＰＲＡＣＨリソースに直交するリソース）と同一の時間インスタンス（ｉｎｓｔａｎｃｅ）に、又はＰＲＡＣＨと異なる時間インスタンス（ＵＥに対して構成可能）に位置し得る。ＤＬ信号の送信は、ＵＥが新しい潜在的なビームを識別するためにビームをモニターすることができるようにサポートされる。

【0150】

ＮＲは、ビーム関連の指示（ｂｅａｍ－ｒｅｌａｔｅｄ ｉｎｄｉｃａｔｉｏｎ）に関係なく、ビーム管理をサポートする。ビーム関連の指示が提供される場合、ＣＳＩ－ＲＳベースの測定のために使用されたＵＥ側のビーム形成／受信手続に関する情報は、ＱＣＬを介してＵＥに指示されることができる。ＮＲでサポートするＱＣＬパラメータとしては、ＬＴＥシステムで使用していた遅延（ｄｅｌａｙ）、ドップラー（Ｄｏｐｐｌｅｒ）、平均利得（ａｖｅｒａｇｅ ｇａｉｎ）等に対するパラメータだけでなく、受信端におけるビームフォーミングのための空間パラメータが追加される予定であり、端末の受信ビームフォーミングの観点から、到達角（ａｎｇｌｅ ｏｆ ａｒｒｉｖａｌ）関連のパラメータ及び／又は基地局の受信ビームフォーミングの観点から、発信角（ａｎｇｌｅ ｏｆ ｄｅｐａｒｔｕｒｅ）関連のパラメータが含まれることができる。ＮＲは制御チャネル及び該当データチャネルの送信で同一であるか異なるビームを使用することをサポートする。

【0151】

ビーム対リンクブロッキング（ｂｅａｍ ｐａｉｒ ｌｉｎｋ ｂｌｏｃｋｉｎｇ）に対する堅固性（ｒｏｂｕｓｔｎｅｓｓ）をサポートするＮＲ－ＰＤＣＣＨ送信のために、ＵＥは、同時にＭ個のビーム対リンク上でＮＲ－ＰＤＣＣＨをモニターするように構成されることができる。ここで、Ｍ≧１及びＭの最大値は、少なくともＵＥの能力に依存し得る。

【0152】

ＵＥは、異なるＮＲ－ＰＤＣＣＨ ＯＦＤＭシンボルで異なるビーム対リンク上のＮＲ－ＰＤＣＣＨをモニターするように構成されることができる。多数のビーム対リンク上でＮＲ－ＰＤＣＣＨをモニターするためのＵＥ Ｒｘビームの設定に関するパラメータは、上位層のシグナリング又はＭＡＣ ＣＥによって構成されるか、及び／又は探索空間の設計で考慮される。

【0153】

少なくとも、ＮＲはＤＬ ＲＳアンテナポートとＤＬ制御チャネルの復調のためのＤＬ ＲＳアンテナポート間の空間のＱＣＬ仮定の指示をサポートする。ＮＲ－ＰＤＣＣＨ（即ち、ＮＲ－ＰＤＣＣＨをモニターする構成方法）に対するビーム指示のための候補のシグナリング方法は、ＭＡＣ ＣＥシグナリング、ＲＲＣシグナリング、ＤＣＩシグナリング、スペックトランスペアレント及び／又は暗示的方法、及びこれらのシグナリング方法の組み合わせである。

【0154】

ユニキャストのＤＬデータチャネルの受信のために、ＮＲはＤＬ ＲＳアンテナポートとＤＬデータチャネルのＤＭＲＳアンテナポート間の空間ＱＣＬ仮定の指示をサポートする。

【0155】

ＲＳアンテナポートを示す情報は、ＤＣＩ（ダウンリンクの許可）を介して表される。また、この情報は、ＤＭＲＳアンテナポートとＱＣＬされているＲＳアンテナポートを示す。ＤＬデータチャネルに対するＤＭＲＳアンテナポートの異なるセットは、ＲＳアンテナポートの別のセットとＱＣＬとして示し得る。

【0156】

ハイブリッドビームフォーミング（Ｈｙｂｒｉｄ ｂｅａｍｆｏｒｍｉｎｇ）

【0157】

多重アンテナ（ｍｕｌｔｉｐｌｅ ａｎｔｅｎｎａ）を利用する既存のビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）技術は、ビームフォーミングの加重値ベクトル（ｗｅｉｇｈｔ ｖｅｃｔｏｒ）／プリコーディングベクトル（ｐｒｅｃｏｄｉｎｇ ｖｅｃｔｏｒ）を適用する位置に応じて、アナログビームフォーミング（ａｎａｌｏｇ ｂｅａｍｆｏｒｍｉｎｇ）技法とデジタルビームフォーミング（ｄｉｇｉｔａｌ ｂｅａｍｆｏｒｍｉｎｇ）技法とに区分できる。

【0158】

アナログビームフォーミング技法は、初期の多重アンテナ構造に適用されたビームフォーミング技法である。これは、デジタル信号の処理が完了したアナログ信号を多数の経路に分岐した後、各径路に対して位相シフト（Ｐｈａｓｅ－Ｓｈｉｆｔ、ＰＳ）と電力増幅器（Ｐｏｗｅｒ Ａｍｐｌｉｆｉｅｒ、ＰＡ）の設定を適用してビームを形成する技法を意味することができる。

【0159】

アナログビームフォーミングのためには、各アンテナに連結されたＰＡとＰＳが単一のデジタル信号から派生したアナログ信号を処理（ｐｒｏｃｅｓｓ）する構造が要求される。言い換えると、アナログ段で前記ＰＡ及び前記ＰＳが複素加重値（ｃｏｍｐｌｅｘ ｗｅｉｇｈｔ）を処理する。

【0160】

図５は、アナログビームフォーマ（ａｎａｌｏｇ ｂｅａｍｆｏｒｍｅｒ）及びＲＦチェーン（ＲＦ ｃｈａｉｎ）で構成される送信端（ｔｒａｎｓｍｉｔｔｅｒ）のブロック図（ｂｌｏｃｋ ｄｉａｇｒａｍ）の一例を示す。図５は、単に説明の便宜のためのものであるだけで、本発明の範囲を制限するものではない。

【0161】

図５において、ＲＦチェーンは基底帯域（ｂａｓｅｂａｎｄ、ＢＢ）信号がアナログ信号へ変換される処理ブロックを意味する。アナログビームフォーミング技法は、前記ＰＡと前記ＰＳの素子の特性によってビームの正確度が決定され、前記素子の制御特性上、狭帯域（ｎａｒｒｏｗｂａｎｄ）送信に有利であり得る。

【0162】

また、アナログビームフォーミング技法の場合、多重ストリーム（ｓｔｒｅａｍ）の送信を具現しにくいハードウェア構造で構成されるので、送信率増大のための多重化利得（ｍｕｌｔｉｐｌｅｘｉｎｇ ｇａｉｎ）が相対的に小さい。また、この場合、直交リソース割り当てベースの端末別ビームフォーミングが容易ではないこともある。

【0163】

これと異なり、デジタルビームフォーミング技法の場合、ＭＩＭＯ環境でダイバーシティ（ｄｉｖｅｒｓｉｔｙ）と多重化利得を最大化するためにＢＢ（Ｂａｓｅｂａｎｄ）プロセスを用いてデジタル段でビームフォーミングが行われる。

【0164】

図６は、デジタルビームフォーマ（ｄｉｇｉｔａｌ ｂｅａｍｆｏｒｍｅｒ）及びＲＦチェーンで構成される送信端のブロック図の一例を示す。図６は、単に説明の便宜のためのものであるだけで、本発明の範囲を制限するものではない。

【0165】

図６の場合、ビームフォーミングは、ＢＢプロセスでプリコーディングが行われることによって行われることができる。ここで、ＲＦチェーンはＰＡを含む。これは、デジタルビームフォーミング技法の場合、ビームフォーミングのために導出された複素加重値が送信データに直接的に適用されるためである。

【0166】

また、端末別に異なるビームフォーミングが行われることができるので、同時に多重ユーザのビームフォーミングをサポートすることができる。のみならず、直交リソースが割り当てられた端末別に独立なビームフォーミングが可能であるので、スケジューリングの柔軟性が向上し、これによって、システムの目的に符合する送信端の運用が可能である。また、広帯域送信をサポートする環境でＭＩＭＯ－ＯＦＤＭのような技術が適用される場合に、副搬送波（ｓｕｂｃａｒｒｉｅｒ）別に独立なビームが形成されることもできる。

【0167】

従って、デジタルビームフォーミング技法は、システムの容量増大と強化したビーム利得に基づいて、単一端末（又はユーザ）の最大送信率を極大化することができる。前述したような特徴に基づき、既存の３Ｇ／４Ｇ（例：ＬＴＥ（－Ａ））システムではデジタルビームフォーミングベースのＭＩＭＯ技法が導入された。

【0168】

ＮＲシステムで、送受信アンテナが大きく増加する大規模（ｍａｓｓｉｖｅ）ＭＩＭＯ環境が考慮できる。一般に、セルラー（ｃｅｌｌｕｌａｒ）通信では、ＭＩＭＯ環境に適用される最大の送受信アンテナが８本と仮定される。しかし、大規模ＭＩＭＯ環境が考慮されることによって、前記送受信アンテナの数は、数十又は数百本以上に増加し得る。

【0169】

このとき、大規模ＭＩＭＯ環境で、前記で説明されたデジタルビームフォーミング技術が適用されると、送信端はデジタル信号の処理のためにＢＢプロセスを介して数百本のアンテナに対する信号処理を行わなければならない。これによって、信号処理の複雑度が非常に大きくなり、アンテナの数だけのＲＦチェーンが必要であるので、ハードウェア具現の複雑度も非常に大きくなることがある。

【0170】

また、送信端は全てのアンテナに対して独立なチャネル推定（ｃｈａｎｎｅｌ ｅｓｔｉｍａｔｉｏｎ）が必要である。のみならず、ＦＤＤシステムの場合、送信端は全てのアンテナで構成された大規模ＭＩＭＯチャネルに対するフィードバック情報が必要であるので、パイロット（ｐｉｌｏｔ）及び／又はフィードバックのオーバーヘッドが非常に大きくなることがある。

【0171】

反面、大規模ＭＩＭＯ環境で前記で説明されたアナログビームフォーミング技術が適用されると、送信端のハードウェアの複雑度は相対的に低い。

【0172】

これに対して、多数のアンテナを利用した性能の増加程度は非常に小さく、リソース割り当ての柔軟性が低くなることがある。特に、広帯域送信の際、周波数別にビームを制御することが容易ではない。

【0173】

従って、大規模ＭＩＭＯ環境ではアナログビームフォーミングとデジタルビームフォーミングの技法のうち、１つのみを排他的に選択するものではなく、アナログビームフォーミングとデジタルビームフォーミングの構造が結合されたハイブリッド（ｈｙｂｒｉｄ）形態の送信端の構成方式が必要である。

【0174】

アナログビームスキャニング（ａｎａｌｏｇ ｂｅａｍ ｓｃａｎｎｉｎｇ）

【0175】

一般に、アナログビームフォーミングは純粋アナログビームフォーミングの送受信端とハイブリッドビームフォーミングの送受信端で利用されることができる。このとき、アナログビームスキャニングは、同じ時間に１つのビームに対する推定を行うことができる。従って、ビームスキャニングに必要なビームトレーニング（ｂｅａｍ ｔｒａｉｎｉｎｇ）の時間は全体候補ビームの数に比例することになる。

【0176】

前述したように、アナログビームフォーミングの場合、送受信端のビーム推定のために、時間領域でのビームスキャニング過程が必ず要求される。このとき、全体送受信ビームに対する推定時間ｔ_ｓは、下記数式２のように表現され得る。

【0177】

【数2】

【0178】

数式２において、ｔ_ｓは１つのビームスキャニングのために必要な時間を意味し、Ｋ_Ｔは送信ビームの数を意味し、Ｋ_Ｒは受信ビームの数を意味する。

【0179】

図７は、本発明の多様な実施形態に係るアナログビームスキャニング方式の一例を示す。図７は、単に説明の便宜のためのものであるだけで、本発明の範囲を制限するものではない。

【0180】

図７の場合、全体送信ビームの数Ｋ_ＴがＬであり、全体受信ビームの数Ｋ_Ｒが１である場合が仮定される。この場合、全体候補ビームの数は計Ｌ個になるので、時間領域でＬ個の時間区間が要求される。

【0181】

言い換えると、アナログビーム推定のために単一時間区間で１個のビーム推定のみが行われることができるので、図７に示されたように、全体Ｌ個のビーム（Ｐ_１乃至Ｐ_Ｌ）推定を行うために、Ｌ個の時間区間が要求される。端末は、アナログビーム推定手続が終了した後、最も高い信号強度を有するビームの識別子（例：ＩＤ）を基地局にフィードバックする。即ち、送受信アンテナの数の増加によって、個別ビームの数が増加するほど、より長いトレーニング時間が要求され得る。

【0182】

アナログビームフォーミングは、ＤＡＣ（Ｄｉｇｉｔａｌ－ｔｏ－Ａｎａｌｏｇ Ｃｏｎｖｅｒｔｅｒ）以降に時間領域の連続的な波形（ｃｏｎｔｉｎｕｏｕｓ ｗａｖｅｆｏｒｍ）のサイズと位相角を変化させるため、デジタルビームフォーミングと異なり、個別ビームに対するトレーニング区間が保障される必要がある。従って、前記トレーニング区間の長さが増加するほど、システムの効率が減少（即ち、システムの損失（ｌｏｓｓ）が増加）し得る。

【0183】

チャネル状態情報（Ｃｈａｎｎｅｌ ｓｔａｔｅ ｉｎｆｏｒｍａｔｉｏｎ：ＣＳＩ）のフィードバック（ｆｅｅｄｂａｃｋ）

【0184】

ＬＴＥシステムを含む大半のセルラーシステム（ｃｅｌｌｕｌａｒ ｓｙｓｔｅｍ）で、端末はチャネル推定のためのパイロット信号（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）を基地局から受信してＣＳＩ（ｃｈａｎｎｅｌ ｓｔａｔｅ ｉｎｆｏｒｍａｔｉｏｎ）を計算し、これを基地局に報告する。

【0185】

基地局は、端末からフィードバックを受けたＣＳＩ情報をもとにデータ信号を送信する。

【0186】

ＬＴＥシステムで端末がフィードバックするＣＳＩ情報には、ＣＱＩ（ｃｈａｎｎｅｌ ｑｕａｌｉｔｙ ｉｎｆｏｒｍａｔｉｏｎ）、ＰＭＩ（ｐｒｅｃｏｄｉｎｇ ｍａｔｒｉｘ ｉｎｄｅｘ）、ＲＩ（ｒａｎｋ ｉｎｄｉｃａｔｏｒ）がある。

【0187】

ＣＱＩフィードバックは、基地局がデータを送信するとき、どんなＭＣＳ（ｍｏｄｕｌａｔｉｏｎ ＆ ｃｏｄｉｎｇ ｓｃｈｅｍｅ）を適用するかに対するガイドを提供しようとする目的（リンク適応用途）で基地局に提供する無線チャネル品質情報である。

【0188】

基地局と端末との間で無線品質が高いと、端末は高いＣＱＩ値をフィードバックし、基地局は相対的に高い変調次数（ｍｏｄｕｌａｔｉｏｎ ｏｒｄｅｒ）と低いチャネルコーディング率（ｃｈａｎｎｅｌ ｃｏｄｉｎｇ ｒａｔｅ）を適用してデータを送信し、逆の場合、端末は低いＣＱＩ値をフィードバックし、基地局は相対的に低い変調次数（ｍｏｄｕｌａｔｉｏｎ ｏｒｄｅｒ）と高いチャネルコーディング率（ｃｈａｎｎｅｌ ｃｏｄｉｎｇ ｒａｔｅ）を適用してデータを送信する。

【0189】

ＰＭＩのフィードバックは、基地局が多重アンテナを設置した場合、どんなＭＩＭＯプリコーディング方式（ｐｒｅｃｏｄｉｎｇ ｓｃｈｅｍｅ）を適用するかに対するガイドを提供しようとする目的で、基地局に提供する好まれたプリコーディングマトリクス（ｐｒｅｆｅｒｒｅｄ ｐｒｅｃｏｄｉｎｇ ｍａｔｒｉｘ）情報である。

【0190】

端末は、パイロット信号から基地局と端末間のダウンリンクＭＩＭＯチャネル（ｄｏｗｎｌｉｎｋ ＭＩＭＯ ｃｈａｎｎｅｌ）を推定し、基地局がどんなＭＩＭＯプリコーディングを適用すればよいかをＰＭＩフィードバックを介して推薦する。

【0191】

ＬＴＥシステムでは、ＰＭＩの構成において、行列の形態で表現可能な線形ＭＩＭＯプリコーディング（ｌｉｎｅａｒ ＭＩＭＯ ｐｒｅｃｏｄｉｎｇ）のみ考慮する。

【0192】

基地局と端末は、多数のプリコーディングの行列で構成されたコードブックを共有しており、コードブック内にそれぞれのＭＩＭＯプリコーディング行列は、固有のインデックスを有している。

【0193】

従って、端末は、コートブック内で最も好むＭＩＭＯプリコーディング行列に該当するインデックスをＰＭＩとしてフィードバックすることによって、端末のフィードバック情報量を最小化する。

【0194】

ＰＭＩ値が必ずしも１つのインデックスのみで行われるべきものではない。一例として、ＬＴＥシステムで送信アンテナポートの数が８本である場合、二つのインデックス（ｆｉｒｓｔ ＰＭＩ ＆ ｓｅｃｏｎｄ ＰＭＩ）を結合してこそ、最終的な８ｔｘ ＭＩＭＯプリコーディング行列を導出することができるように構成されている。

【0195】

ＲＩフィードバックは、基地局と端末が多重アンテナを設置し、空間多重化（ｓｐａｔｉａｌ ｍｕｌｔｉｐｌｅｘｉｎｇ）を介した多重レイヤー（ｍｕｌｔｉ－ｌａｙｅｒ）の送信が可能である場合、端末が好む送信レイヤーの数に対するガイドを提供しようとする目的で基地局に提供する好む送信レイヤーの数に対する情報である。

【0196】

ＲＩは、ＰＭＩと非常に密接な関係を有する。それは、送信レイヤーの数に応じて、基地局はそれぞれのレイヤーにどんなプリコーディングを適用すべきか分からなければならないためである。

【0197】

ＰＭＩ／ＲＩフィードバックの構成において、単一レイヤー（ｓｉｎｇｌｅ ｌａｙｅｒ）の送信を基準に、ＰＭＩコードブックを構成した後、レイヤー別にＰＭＩを定義してフィードバックできるが、このような方式は、送信レイヤーの数の増加によってＰＭＩ／ＲＩフィードバックの情報量が大きく増加するというデメリットがある。

【0198】

従って、ＬＴＥシステムでは、それぞれの送信レイヤーの数によるＰＭＩコードブックを定義した。即ち、Ｒ－レイヤーの送信のために、サイズＮｔ×Ｒ行列Ｎ個をコードブック内に定義する（ここで、Ｒは、レイヤーの数、Ｎｔは送信アンテナポートの数、Ｎはコードブックのサイズ）。

【0199】

従って、ＬＴＥでは、送信レイヤーの数に関係なく、ＰＭＩコードブックのサイズが定義される。結果、このような構造でＰＭＩ／ＲＩを定義しているため、送信レイヤーの数（Ｒ）は、結局のところプリコーディング行列（Ｎｔ×Ｒ行列）のランク値と一致することになるので、ｒａｎｋ ｉｎｄｉｃａｔｏｒ（ＲＩ）という用語を使用することになった。

【0200】

本明細書で記述されるＰＭＩ／ＲＩは、必ずしもＬＴＥシステムにおけるＰＭＩ／ＲＩのように、Ｎｔ×Ｒ行列で表現されるプリコーディング行列のインデックス値と、プリコーディング行列のランク値を意味するものと制限されない。

【0201】

本明細書で記述されるＰＭＩは、送信端で適用可能なＭＩＭＯプリコーダのうち好むＭＩＭＯプリコーダ情報を示すものであって、そのプリコーダの形態がＬＴＥシステムでのように行列で表現可能な線形プリコーダのみに限定されない。また、本明細書で記述されるＲＩは、ＬＴＥにおけるＲＩよりもさらに広い意味で、好む送信レイヤーの数を示すフィードバック情報を全て含む。

【0202】

ＣＳＩ情報は、全体システム周波数領域から求められてもよく、一部周波数領域から求められてもよい。特に、広帯域システムでは、端末別に好む一部周波数領域（例えば、サブバンド）に対するＣＳＩ情報を求めてフィードバックすることが有用であり得る。

【0203】

ＬＴＥシステムでＣＳＩフィードバックはアップリンクチャネルを介して行われるが、一般に周期的なＣＳＩフィードバックは、ＰＵＣＣＨ（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を介して行われ、非周期的なＣＳＩフィードバックは、アップリンクデータチャネルであるＰＵＳＣＨ（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）を介して行われる。

【0204】

非周期的なＣＳＩフィードバックは、基地局がＣＳＩフィードバックの情報を望む時にのみ一時的にフィードバックすることを意味するもので、基地局がＰＤＣＣＨ／ｅＰＤＣＣＨのようなダウンリンクコントロールチャネルを介してＣＳＩフィードバックをトリガー（ｔｒｉｇｇｅｒ）する。

【0205】

ＬＴＥシステムでは、ＣＳＩフィードバックがトリガーされたとき、端末がどんな情報をフィードバックすべきかが図８のようにＰＵＳＣＨ ＣＳＩ報告モード（ｒｅｐｏｒｔｉｎｇ ｍｏｄｅ）に区分されており、端末がどんなＰＵＳＣＨ ＣＳＩ報告モード（ｒｅｐｏｒｔｉｎｇ ｍｏｄｅ）で動作すべきかは、上位層のメッセージを介して端末に予め知らせる。

【0206】

図８は、ＰＵＳＣＨ ＣＳＩ報告モードの一例を示した図である。

【0207】

ＰＵＣＣＨを介した周期的ＣＳＩフィードバックに対して、ＰＵＣＣＨ ＣＳＩ報告モードやはり定義される。

【0208】

図９は、ＰＵＣＣＨ ＣＳＩ報告モードの一例を示した図である。

【0209】

ＰＵＣＣＨの場合、ＰＵＳＣＨよりも一度に送ることができるデータ量（ｐａｙｌｏａｄ ｓｉｚｅ）が小さいので、送ろうとするＣＳＩ情報を一度に送ることが難しい。

【0210】

従って、各ＣＳＩ報告モードによって、ＣＱＩ及びＰＭＩを送信する時点とＲＩを送信する時点とが異なる。例えば、報告モード１－０では、特定ＰＵＣＣＨ送信時点にはＲＩのみ送信し、別のＰＵＣＣＨ送信時点に広帯域ＣＱＩを送信する。特定ＰＵＣＣＨ送信時点に構成されるＣＳＩ情報の種類によって、ＰＵＣＣＨ報告タイプが定義される。例えば、前記例でＲＩのみ送信する報告タイプは、タイプ３に該当し、広帯域ＣＱＩのみ送信する報告タイプは、タイプ４に該当する。ＲＩフィードバックの周期及びオフセット値とＣＱＩ／ＰＭＩフィードバックの周期及びオフセット値は、上位層のメッセージを介して端末に設定される。

【0211】

前記ＣＳＩフィードバック情報は、アップリンクコントロール情報（ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ、ＵＣＩ）に含まれる。

【0212】

ＬＴＥにおける基準信号（Ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌｓ ｉｎ ＬＴＥ）

【0213】

ＬＴＥシステムでパイロット或いはＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）の用途は、大きく次のように分けられる。

【0214】

１．測定ＲＳ：チャネル状態測定用パイロット

【0215】

Ａ．ＣＳＩ測定／報告用途（ｓｈｏｒｔ ｔｅｒｍ ｍｅａｓｕｒｅｍｅｎｔ）：リンク適応（Ｌｉｎｋ ａｄａｐｔａｔｉｏｎ）、ランク適応（ｒａｎｋ ａｄａｐｔａｔｉｏｎ）、閉ループＭＩＭＯプリコーディング（ｃｌｏｓｅｄ ｌｏｏｐ ＭＩＭＯ ｐｒｅｃｏｄｉｎｇ）等の目的

【0216】

Ｂ．長期間測定（Ｌｏｎｇ ｔｅｒｍ ｍｅａｓｕｒｅｍｅｎｔ）／報告用途：ハンドオーバー（Ｈａｎｄｏｖｅｒ）、セル選択（ｃｅｌｌ ｓｅｌｅｃｔｉｏｎ）／再選択（ｒｅｓｅｌｅｃｔｉｏｎ）等の目的

【0217】

２．復調ＲＳ（Ｄｅｍｏｄｕｌａｔｉｏｎ ＲＳ）：物理チャネル受信用パイロット

【0218】

３．位置決めＲＳ（Ｐｏｓｉｔｉｏｎｉｎｇ ＲＳ）：端末位置推定用パイロット

【0219】

４．ＭＢＳＦＮ ＲＳ：マルチキャスト／ブロードキャスト（Ｍｕｌｔｉ－ｃａｓｔ／Ｂｒｏａｄｃａｓｔ）サービスのためのパイロット

【0220】

ＬＴＥ Ｒｅｌ－８では、大半のダウンリンク物理チャネルに対する測定（用途１Ａ／Ｂ）及び復調（用途２）のためにＣＲＳ（Ｃｅｌｌ－ｓｐｅｃｉｆｉｃ ＲＳ）を使用したが、アンテナの数が多くなることによるＲＳのオーバーヘッドの問題を解決するために、ＬＴＥ Ａｄｖａｎｃｅｄ（Ｒｅｌ－１０）からはＣＳＩ測定（用途１Ａ）専用としてＣＳＩ－ＲＳとダウンリンクデータチャネル（ＰＤＳＣＨ）に対する受信（用途２）専用としてＵＥ－ｓｐｅｃｉｆｉｃ ＲＳを使用する。

【0221】

ＣＳＩ－ＲＳは、ＣＳＩ測定及びフィードバック専用に設計されたＲＳであって、ＣＲＳに比べて非常に低いＲＳのオーバーヘッドを有することが特徴であり、ＣＲＳは４本の多重アンテナポートまでサポートするのに対して、ＣＳＩ－ＲＳは８本の多重アンテナポートまでサポート可能なように設計された。ＵＥ－ｓｐｅｃｉｆｉｃ ＲＳは、データチャネルの復調専用に設計されてＣＲＳと異なり、該当ＵＥにデータ送信時に適用されたＭＩＭＯプリコーディング技法がパイロット信号に同じように適用されたＲＳ（ｐｒｅｃｏｄｅｄ ＲＳ）という点が特徴である。

【0222】

従って、ＵＥ特定ＲＳ（ＵＥ－ｓｐｅｃｉｆｉｃ ＲＳ）はＣＲＳ、ＣＳＩ－ＲＳのようにアンテナポートの数だけ送信される必要がなく、送信レイヤーの数（送信ランク）だけ送信すればよい。

【0223】

また、ＵＥ特定ＲＳは、基地局のスケジューラ（ｓｃｈｅｄｕｌｅｒ）を介して、各ＵＥに割り当てられたデータチャネルのリソース領域と同じリソース領域に該当ＵＥのデータチャネル受信用途で送信されるので、端末特定的ＲＳという特徴がある。

【0224】

ＣＲＳはセル内の全てのＵＥが測定及び復調用途で使用できるようにシステム帯域幅内で同じパターンで常時送信されるので、セル特定的である。

【0225】

ＬＴＥのアップリンクでは、測定ＲＳとしてＳｏｕｎｄｉｎｇ ＲＳ（ＳＲＳ）が設計され、アップリンクデータチャネル（ＰＵＳＣＨ）に対する復調ＲＳ（ＤＭＲＳ）とＡＣＫ／ＮＡＣＫ及びＣＳＩフィードバックのためのアップリンクコントロールチャネル（ＰＵＣＣＨ）に対するＤＭＲＳがそれぞれ設計された。

【0226】

ビーム管理及びビーム復旧（Ｂｅａｍ ｍａｎａｇｅｍｅｎｔ ａｎｄ ｂｅａｍ ｒｅｃｏｖｅｒｙ）

【0227】

基地局は端末に周期的（ｐｅｒｉｏｄｉｃ）ＣＳＩ報告、半固定的（ｓｅｍｉ－ｐｅｒｓｉｓｔｅｎｔ）ＣＳＩ報告（特定時間区間の間にのみ周期的ＣＳＩ報告が活性化（ａｃｔｉｖａｔｉｏｎ）されるか、或いは連続的な複数回のＣＳＩ報告を実行）、若しくは非周期的（ａｐｅｒｉｏｄｉｃ）ＣＳＩ報告を要求することができる。

【0228】

ここで、前記周期的（ｐｅｒｉｏｄｉｃ）及び半固定的（ｓｅｍｉ－ｐｅｒｓｉｓｔｅｎｔ、ＳＰ）ＣＳＩ報告は、報告が活性化された期間には端末に特定周期にＣＳＩ報告のためのＵＬ（ｕｐｌｉｎｋ）リソース（例えば、ＰＵＣＣＨ ｉｎ ＬＴＥ）が割り当てられる。

【0229】

端末のＣＳＩ測定のためには、基地局のダウンリンク（ＤＬ）参照信号（ＲＳ）の送信が必要である。

【0230】

（アナログ）ビームフォーミングが適用されたビームフォーミングされたシステム（ｂｅａｍｆｏｒｍｅｄ ｓｙｓｔｅｍ）の場合、前記ＤＬ ＲＳ送信／受信のためのＤＬ送信（Ｔｘ）／ｒｅｃｅｐｔｉｏｎ（Ｒｘ）ビーム対（ｂｅａｍ ｐａｉｒ）と、ＵＣＩ（ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ：例えば、ＣＳＩ、ＡＣＫ／ＮＡＣＫ）送信／受信のためのＵＬ Ｔｘ／Ｒｘビーム対の決定が必要である。

【0231】

ＤＬビーム対の決定手続は、（１）複数個のＴＲＰ Ｔｘビームに該当するＤＬ ＲＳを基地局が端末へ送信する手続と、（２）前記端末がこのうち１つを選択／又は報告するＴＲＰ Ｔｘビーム選択手続と、（３）基地局が各ＴＲＰ Ｔｘビームに該当する同じＲＳ信号を繰り返し送信する手続と、（４）前記端末が前記繰り返し送信された信号に互いに異なるＵＥ Ｒｘビームで測定し、ＵＥ Ｒｘビームを選択する手続の組み合わせで構成されることができる。

【0232】

また、ＵＬビーム対決定手続は、（１）複数個のＵＥ Ｔｘビームに該当するＵＬ ＲＳを端末が基地局が送信する手続と、（２）基地局がこのうち１つを選択及び／又はシグナリングするＵＥ Ｔｘビーム選択手続と、（３）前記端末が各ＵＥ Ｔｘビームに該当する同じＲＳ信号を基地局へ繰り返し送信する手続と、（４）前記基地局が前記繰り返し送信された信号に互いに異なるＴＲＰ Ｒｘビームで測定し、ＴＲＰ Ｒｘビームを選択する手続と、の組み合わせで構成されることができる。

【0233】

ＤＬ／ＵＬのビーム相互性（ｂｅａｍ ｒｅｃｉｐｒｏｃｉｔｙ）（又はビーム対応（ｂｅａｍ ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ））が成立する場合、即ち、基地局と端末間の通信で基地局のＤＬ Ｔｘビームと基地局のＵＬ Ｒｘビームとが一致し、端末のＵＬ Ｔｘビームと端末のＤＬ Ｒｘビームとが一致すると仮定できる場合、ＤＬビーム対とＵＬビーム対のうちいずれか１つのみ決定すると、もう１つを決定する手続を省略することができる。

【0234】

ＤＬ及び／又はＵＬビーム対に対する決定過程は、周期的又は非周期的に行われることができる。

【0235】

候補（ｃａｎｄｉｄａｔｅ）ビームの数が多い場合、要求されるＲＳのオーバーヘッドが大きいことがあるため、前記ＤＬ及び／又はＵＬビーム対に対する決定過程がよく発生することは好ましくない。

【0236】

ＤＬ／ＵＬビーム対決定過程が完了した以降、端末は周期的（ｐｅｒｉｏｄｉｃ）又はＳＰ（Ｓｅｍｉ－Ｐｅｒｓｉｓｔｅｎｔ）ＣＳＩ報告を行うと仮定しよう。

【0237】

ここで、端末のＣＳＩ測定（ｍｅａｓｕｒｅｍｅｎｔ）のための単一又は複数個のアンテナポートを含むＣＳＩ－ＲＳは、ＤＬビームで決定されたＴＲＰ Ｔｘビームでビームフォーミングされて送信されてもよく、ＣＳＩ－ＲＳの送信周期は、ＣＳＩ報告（ｒｅｐｏｒｔｉｎｇ）周期と同一であってもよく、又はさらによく送信されてもよい。

【0238】

或いは、端末は、非周期的（ａｐｅｒｉｏｄｉｃ）ＣＳＩ－ＲＳをＣＳＩ報告周期に合わせて、又はさらによく送信することも可能である。

【0239】

端末（例：ＵＥ）は、測定されたＣＳＩ情報を周期的にＵＬビーム対決定過程で既決定されたＵＬ Ｔｘビームに送信することができる。

【0240】

ＤＬ／ＵＬビーム管理過程を行うにあたって、設定されたビーム管理の周期によって、ビーム不一致（ｍｉｓｍａｔｃｈ）の問題が発生し得る。

【0241】

特に、端末が位置を移動したり、端末が回転したり、又は前記端末周辺の物体の移動で無線チャネルの環境が変わる場合（例えば、ＬｏＳ（Ｌｉｎｅ－ｏｆ－Ｓｉｇｈｔ）環境であったが、ビームがブロックされて、非ＬｏＳ環境に変わる場合）、最適のＤＬ／ＵＬビーム対は変わることがある。

【0242】

このような変化を一般的にネットワークの指示によって行うビーム管理過程でトラッキングが失敗したとき、ビーム失敗イベント（ｂｅａｍ ｆａｉｌｕｒｅ ｅｖｅｎｔ）が発生したといえる。

【0243】

このようなビーム失敗イベントの発生可否は、端末がダウンリンクＲＳの受信品質を通じて判断することができ、このような状況に対する報告メッセージ又はビーム復旧要求のためのメッセージ（以下、「ビーム復旧要求メッセージ（ｂｅａｍ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）」と定義する）が端末から伝達されなければならない。

【0244】

前記ビーム復旧要求メッセージは、ビーム失敗復旧要求メッセージ、制御信号、制御メッセージ、ファーストメッセージ（ｆｉｒｓｔ ｍｅｓｓａｇｅ）などで多様に表現され得る。

【0245】

前記端末から前記ビーム復旧要求メッセージを受信した基地局は、ビーム復旧のために端末へビームＲＳ送信、ビーム報告要求等、多様な過程を通じてビーム復旧を行うことができる。

【0246】

このような一連のビーム復旧過程を「ビーム復旧（ｂｅａｍ ｒｅｃｏｖｅｒｙ）」と表現することとする。

【0247】

３ＧＰＰでＬＴＥ以降のＮＲ（ｎｅｗ ｒａｄｉｏ ｏｒ Ｎｅｗ Ｒａｔ）と名付けた新しい通信システムに対する標準化が進んでおり、ビーム管理（ｂｅａｍ ｍａｎａｇｅｍｅｎｔ）に関して、下記のような内容が含まれる。

【0248】

（内容１）

【0249】

ＮＲは、ＵＥがビーム失敗（ｂｅａｍ ｆａｉｌｕｒｅ）から復旧（ｒｅｃｏｖｅｒｙ）するメカニズムをトリガーできることをサポートする。

【0250】

ネットワークは、復旧の目的のために信号のＵＬ送信に対するリソースをＵＥに明示的に構成する。

【0251】

基地局が全体又は一部方向から聴取（ｌｉｓｔｅｎｉｎｇ）しているリソースの構成をサポートする（例えば、ランダムアクセス領域）。

【0252】

（後日議論）ＲＳ／制御チャネル／データチャネルのモニタリングのＵＥ動作と関連した復旧信号（新規又は既存の信号）のトリガー条件

【0253】

ＵＥが新しい潜在的なビームを識別するために、ビームをモニターできるように許容するＤＬ信号の送信をサポートする。

【0254】

（後日議論）ビームスイープ（ｂｅａｍ ｓｗｅｅｐ）制御チャネルの送信が排除されない。

【0255】

このメカニズムは、性能とＤＬシグナリングオーバーヘッド間のかね合い（ｔｒａｄｅｏｆｆ）を考慮しなければならない。

【0256】

（内容２）

【0257】

できるだけ下記の候補ソリューションを考慮し、ビーム管理オーバーヘッド及び遅延時間は、ＮＲのビーム管理のためのＣＳＩ－ＲＳの設計中に考慮されなければならない。

【0258】

Ｏｐｔ１．ＩＦＤＭＡ

【0259】

Ｏｐｔ２．大きい副搬送波間隔（ｌａｒｇｅ ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）

【0260】

ＮＲのビーム管理のためのＣＳＩ－ＲＳの設計中に考慮される他の側面は、例えば、ＣＳＩ－ＲＳ多重化、ＵＥのビームスイッチレイテンシ及びＵＥ具現の複雑性（例えば、ＡＧＣトレーニング時間）、ＣＳＩ－ＲＳのカバレッジなどを含む。

【0261】

（内容３）

【0262】

ＣＳＩ－ＲＳは、ＤＬ Ｔｘビームスイーピング及びＵＥ Ｒｘビームスイーピングをサポートする。

【0263】

ＮＲのＣＳＩ－ＲＳは、次のマッピング構造をサポートする。

【0264】

ＮＰ ＣＳＩ－ＲＳポートは、（サブ）時間単位別にマッピングされることができる。

【0265】

（サブ）時間単位（ｕｎｉｔ）にかけて同じＣＳＩ－ＲＳアンテナポートがマッピングされることができる。

【0266】

ここで、「時間単位」は、設定された／参照ヌメロロジー（ｃｏｎｆｉｇｕｒｅｄ／ｒｅｆｅｒｅｎｃｅ ｎｕｍｅｒｏｌｏｇｙ）で、ｎ ＯＦＤＭシンボル（ｎ＞＝１）を示す。

【0267】

各時間単位は、サブ－時間単位でパーティション（ｐａｒｔｉｔｉｏｎ）できる。

【0268】

このマッピング構造は、多数のパネル／Ｔｘチェーンをサポートするために使用されることができる。

【0269】

（オプション１）

【0270】

Ｔｘビームは、各時間単位内のサブ時間単位にかけて同一である。

【0271】

Ｔｘビームは、時間単位に応じて異なる。

【0272】

（オプション２）

【0273】

Ｔｘビームは、各時間単位内でサブ時間単位毎に異なる。

【0274】

Ｔｘビームは、時間単位で同一である。

【0275】

（オプション３）：オプション１とオプション２との組み合わせ

【0276】

１つの時間単位内で、Ｔｘビームはサブ時間単位で同一である。

【0277】

別の時間単位内で、Ｔｘビームはサブ時間単位毎に異なる。

【0278】

以下、端末のビーム失敗復旧メカニズム（Ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｍｅｃｈａｎｉｓｍ）について簡略に見る。

【0279】

前記端末のビーム失敗復旧メカニズムは、下記（１）乃至（４）の過程を含む。

【0280】

（１）ビーム失敗を感知する。

【0281】

（２）新しい候補ビームを識別する。

【0282】

（３）ビーム失敗復旧要求を送信する。

【0283】

（４）ＵＥはビーム失敗復旧要求に対するｇＮＢの応答をモニターする。

【0284】

まず、ビーム失敗感知過程について見ると、ＵＥは、ビーム失敗のトリガー条件が満たされたか否かを評価するために、ビーム失敗感知ＲＳをモニターする。

【0285】

また、ビーム失敗感知ＲＳは、少なくともビーム管理のための周期的なＣＳＩ－ＲＳを含む。ここで、ＳＳ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）ブロック（ｂｌｏｃｋ）もビーム管理に使用されることができ、ＳＳブロックがビーム管理に使用される場合、サービングセル内ＳＳブロックが考慮できる。

【0286】

ここで、ＳＳブロックは、同期信号（ＳＳ）がスロット単位又は特定の時間単位で送信されると解釈され得る。

【0287】

ここで、ビーム失敗感知ＲＳは、該当ＲＳの品質自体を測定する場合だけでなく、該当ＲＳとＱＣＬ（Ｑｕａｓｉ Ｃｏ－Ｌｏｃａｔｉｏｎ）指示子等で関連した無線チャネルの検出／復調（ｄｅｔｅｃｔｉｏｎ／ｄｅｍｏｄｕｌａｔｉｏｎ）の品質を測定する場合を含む。例えば、（ｐｒｉｍａｒｙ）ＰＤＣＣＨのモニタリングのために指示されたＣＳＩ－ＲＳ或いはＳＳブロック関連のＩＤを前記ビーム失敗感知ＲＳと理解でき、このとき、ビーム失敗イベントの発生可否は、該当ＰＤＣＣＨの検出／復調（ｄｅｔｅｃｔｉｏｎ／ｄｅｍｏｄｕｌａｔｉｏｎ）性能が一定以下である場合と定義されることができる。

【0288】

前記ビーム失敗イベントの発生は、関連した（ａｓｓｏｃｉａｔｅｄ）制御チャネルのビーム対リンクの品質が一定レベル以下に下げたときに発生し得る。

【0289】

具体的に、前記関連した制御チャネルのビーム対リンクの品質は、ＰＤＣＣＨ検出性能（ｄｅｔｅｃｔｉｏｎ ｐｅｒｆｏｒｍａｎｃｅ）で決定されることもできる。

【0290】

例えば、端末がＰＤＣＣＨをモニタリング（又はブラインドデコーディング）する過程で、ＣＲＣチェックの結果、ＰＤＣＣＨ検出性能がよくない場合、端末はビーム失敗を検出することができるようになる。

【0291】

或いは、多重ＰＤＣＣＨｓが多重ビームを介して（又は多重ＰＤＣＣＨｓがそれぞれ互いに異なるビームに）送信される場合、特定ＰＤＣＣＨ（例：サービングビームと関連したＰＤＣＣＨ）に対する検出性能で前記ビーム失敗イベントの発生可否を判断することができる。

【0292】

ここで、多重ＰＤＣＣＨｓのそれぞれは、互いに異なる制御チャネル領域（例：シンボル、スロット、サブフレームなど）で互いに異なるビーム別に送信及び／又は受信されることができる。

【0293】

この場合、ビーム別制御チャネル領域が予め定義されてもよく、上位層のシグナリング（ｈｉｇｈｅｒ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を介して送受信されてもよい。

【0294】

また、前記関連した制御チャネルのビーム対リンクの品質で前記ビーム失敗イベントの発生可否を判断するとき、ＤＬビームの品質のみが一定レベル以下に下げたか、又はＵＬビームの品質のみが一定レベル以下に下げたか、又はＤＬビームとＵＬビームの品質がいずれも一定レベル以下に下げたかに応じて、前記ビーム失敗イベントの発生可否が決定されることができる。

【0295】

ここで、前記一定レベル以下は、臨界値以下、関連したタイマーのｔｉｍｅ－ｏｕｔ等であり得る。

【0296】

また、前記ビーム失敗を検出する信号として、ＢＲＳ、ファインタイミング（ｆｉｎｅ ｔｉｍｉｎｇ）／周波数トラッキング（ｆｒｅｑｕｅｎｃｙ ｔｒａｃｋｉｎｇ）のためのＲＳ、ＳＳブロック、ＰＤＣＣＨのためのＤＭ－ＲＳ、ＰＤＳＣＨのためのＤＭ－ＲＳ等が使用できる。

【0297】

次に、新しい候補ビームの識別過程について見ると、ＵＥはビーム識別ＲＳをモニタリングし、新しい候補ビームを見つける。

【0298】

－ビーム識別ＲＳは、１）ＮＷによって構成された場合、ビーム管理のための周期的ＣＳＩ－ＲＳ、２）ＳＳブロックがビーム管理に使用される場合、サービングセル内の周期的なＣＳＩ－ＲＳ及びＳＳブロックに対する情報を含む。

【0299】

次に、ビーム失敗復旧要求送信過程について見ると、ビーム失敗復旧要求によって運ばれる情報は、１）ＵＥ及び新しいｇＮＢ ＴＸビーム情報を識別するための明示的／暗示的情報、又は２）ＵＥを識別して新しい候補ビームが存在するか否かに対する明示的／暗示的情報のうち少なくとも１つを含む。

【0300】

また、ビーム失敗復旧要求の送信は、ＰＲＡＣＨ、ＰＵＣＣＨ、ＰＲＡＣＨ－ｌｉｋｅ（例えば、ＰＲＡＣＨからのプリアンブルシーケンスに対する異なるパラメータ）のうち１つを選択することができる。

【0301】

－ビーム失敗復旧要求リソース／信号は、スケジューリング要求にさらに使用されることができる。

【0302】

次に、ＵＥはビーム失敗復旧要求に対するｇＮＢ応答を受信するために、制御チャネルの検索空間をモニターする。

【0303】

また、ビーム失敗復旧要求の送信に対して、下記のトリガリング条件をサポートする。

【0304】

－条件：ＣＳＩ－ＲＳのみが新しい候補ビームの識別のために使用される場合、ビーム失敗が検出され、候補ビームが識別される場合

【0305】

また、ビーム失敗復旧要求の送信のために下記のようなチャネルをサポートする。

【0306】

－ＰＲＡＣＨに基づく非競合ベースのチャネル、ＦＤＭに対して少なくとも異なるＰＲＡＣＨ送信のリソースに直交するリソースを使用する。

【0307】

－ビーム失敗復旧要求の送信のためのＰＵＣＣＨをサポートする。

【0308】

前記で見た通り、ＮＲの場合、ビーム復旧要求メッセージ（ｂｅａｍ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）は、（１）ＰＲＡＣＨと同じシンボルを用いて送信されるか（一番目）、（２）ＰＲＡＣＨ以外のシンボルを用いて送信する（二番目）、二つのメカニズムが全てサポートされることができる。

【0309】

一番目は、ビーム失敗（ｆａｉｌｕｒｅ）により、アップリンクの同期まで失った場合（ビームの品質が相対的に多く落ちるか、代替ビームがない場合）、及び／又はビーム失敗イベント（ｂｅａｍ ｆａｉｌｕｒｅ ｅｖｅｎｔ）の発生時点と、既設定されたＰＲＡＣＨリソースが時間的に近い場合、有用なメカニズムであり得る。

【0310】

二番目は、ビーム失敗（ｆａｉｌｕｒｅ）の状況であるが、アップリンクの同期は失わない場合（ビームの品質が相対的に少し落ちるか、代替ビームがある場合）、及び／又はビーム失敗イベントの発生時点と既設定されたＰＲＡＣＨリソースが時間的に遠くて、ＰＲＡＣＨリソース（例：シンボル）まで待つには早いビーム復旧が難しい場合に有用なメカニズムであり得る。

【0311】

また、端末は、ビーム失敗（ｂｅａｍ ｆａｉｌｕｒｅ）の際、基地局にビーム復旧要求メッセージを所定回数送信した後、前記基地局から前記要求に対する応答を受信できない場合、ＲＬＦ（Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ）動作を行うことができる。

【0312】

端末の移動などにより、ビーム失敗（ｂｅａｍ ｆａｉｌｕｒｅ）が発生した場合、ビームを復旧（ｒｅｃｏｖｅｒｙ）するための方法について見ることとする。

【0313】

特に、本明細書は、代替ビームの存在可否に応じて、ビームを復旧する方法が異なって行われることができ、具体的な内容については後述することとする。

【0314】

本明細書で使用するビームＲＳ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）（ＢＲＳ）は、ビーム管理（ｍａｎａｇｅｍｅｎｔ）のために使用されるダウンリンク物理信号として、ＣＳＩ－ＲＳ、Ｍｏｂｉｌｉｔｙ ＲＳ（ＭＲＳ）、同期信号（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）等がビームＲＳとして使用されることができる。

【0315】

前記ビームＲＳは、ビーム管理フレームワーク（ｂｅａｍ ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅｗｏｒｋ）（又はＣＳＩフレームワーク）上でリソースセッティング（ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）によって（ＲＲＣレイヤーメッセージとして）設定されることができる。即ち、前記リソースセッティングによって、前記ビームＲＳは、予め設定されることができる。

【0316】

後述するように、前記ビーム管理フレームワークは、ビーム報告セッティング（Ｂｅａｍ ｒｅｐｏｒｔｉｎｇ ｓｅｔｔｉｎｇ（ｓ））、ビームリソースセッティング（Ｂｅａｍ ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ（ｓ））、ビームリソースセット（Ｂｅａｍ ｒｅｓｏｕｒｃｅ ｓｅｔ）、測定セッティング（Ｍｅａｓｕｒｅｍｅｎｔ ｓｅｔｔｉｎｇ（ｓ））の関連関係を示す構造である。これに関するより具体的な内容は後述することとする。

【0317】

また、本明細書で使用するビーム報告（Ｂｅａｍ ｒｅｐｏｒｔｉｎｇ）は、ビームと関連した端末のフィードバック情報を意味し、ビーム品質関連の情報及び／又はビーム指示情報を含むことができる。

【0318】

本明細書で、「Ａ及び／又はＢ」、「Ａそして／又はＢ」、「Ａ／Ｂ」は、「Ａ又はＢのうち少なくとも１つを含む」という意味と同様に解釈され得る。

【0319】

前記ビーム品質関連の情報は、ＣＱＩ（Ｃｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ）、レイヤー３のＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌｓ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）、レイヤー１のＲＳＲＰ等であってもよい。

【0320】

また、前記ビーム指示情報は、ＣＲＩ（ＣＳＩ－ＲＳ ｒｅｓｏｕｒｃｅ ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ Ｍａｔｒｉｘ Ｉｎｄｉｃａｔｏｒ）、ＲＳポートインデックス等であってもよい。

【0321】

前記ビームに関するフィードバック情報、パラメータ（ｐａｒａｍｅｔｅｒ）、報告周期、周波数単位（ｇｒａｎｕｌａｒｉｔｙ）（例えば、広帯域フィードバック、サブバンドフィードバック）等は、前記ビーム管理フレームワーク（又はＣＳＩフレームワーク）上で報告セッティング（ｒｅｐｏｒｔｉｎｇ ｓｅｔｔｉｎｇ）によって（ＲＲＣレイヤーメッセージとして）設定されることができる。

【0322】

即ち、前記報告セッティングにより、前記ビームと関連したフィードバック情報、報告周期、周波数単位等が予め設定されることができる。

【0323】

端末がビーム復旧要求（Ｂｅａｍ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）をネットワーク（例：基地局）へ送信する場合、前記ネットワークは下記のように二つの動作（方法１及び方法２）を取ることができる。

【0324】

（方法１）

【0325】

方法１は、代替ビーム（例：代替ＤＬビーム対）がない場合のネットワーク動作を示す。

【0326】

即ち、方法１は、ネットワークが端末からビーム復旧要求を受信した場合、（非周期的）ビームＲＳを端末へ送信し（又はビームＲＳをトリガーし）、（非周期的）ビーム報告トリガーを端末へ送信する方法に関する。

【0327】

前記代替ビームとは、基地局が周期的なビーム管理又はモニタリングのために設定したＲＳセットで理解されることができ、端末が測定可能なビームのセットよりも同じでもよく、小さくてもよい。

【0328】

即ち、前記代替ビームは、ビーム管理の目的で設定されたＲＳのうち、特定品質以上を有するＲＳ（ｓ）であってもよい。

【0329】

例えば、ネットワークが端末に周期的なビーム管理又はモニタリングのためにＮ個のＣＳＩ－ＲＳリソースを設定することができる。

【0330】

しかし、端末は、Ｎ個のＣＳＩ－ＲＳリソースだけでなく（さらに広いカバレッジを有する）Ｍ個のビームフォーミングされたＳＳブロックから信号の品質を測定することができる。従って、ある端末は、設定されたＮ個のＣＳＩ－ＲＳのうちからは代替ビームがないが、Ｍ個のＳＳブロックのうちからは代替ビーム、即ち、特定品質以上の信号を見つけることもできる。しかし、このような場合、ＳＳブロックは、セル特定的（ｃｅｌｌ－ｓｐｅｃｉｆｉｃ）であり、周期的な属性を有するので、要求に応じて端末特定的に（ＵＥ－ｓｐｅｃｉｆｉｃ）送信すべき前記記述した（非周期的）ビームＲＳ範疇に含むには適さない。従って、このような場合は、代替ＳＳブロックビームがあっても（非周期的）ビームＲＳ（例えば、ＣＳＩ－ＲＳ）を端末へ送信する後続過程が必要な方法１の範疇と見ることができる。

【0331】

図１０は、代替ビームの存在有無によるネットワーク動作の一例を示す。

【0332】

具体的に、図１０ａは、方法１を図式化した図である。

【0333】

ここで、前記ビームＲＳトリガー及びビーム報告トリガーは、独立にシグナリングされるか、一緒に（ｊｏｉｎｔｌｙ）シグナリングされることができる。

【0334】

一例として、ネットワークは１つのＤＣＩを用いてビームＲＳ及びビーム報告を共にトリガーすることができる。

【0335】

図１０ａを参照すると、ネットワークは端末へ周期的（Ｐｅｒｉｏｄｉｃ）ビームＲＳをＤＬに送信する。

【0336】

以降、前記ネットワークが前記端末からビーム復旧要求を受信した場合、（方法１によって）前記ネットワークは前記端末へ（非周期的）ビームＲＳと（非周期的）ビーム報告を共にトリガーする。

【0337】

これによって、前記端末は、基準リソース（ｒｅｆｅｒｅｎｃｅ ｒｅｓｏｕｒｃｅ）を介して、ビーム測定（ｂｅａｍ ｍｅａｓｕｒｅｍｅｎｔ）を行い、前記ビーム測定の結果を前記ネットワークに報告する。

【0338】

前記基準リソースを決定する具体的な方法については後述することとする。

【0339】

（方法２）

【0340】

方法２は、代替ＤＬビーム対がある場合のネットワーク動作を示す。

【0341】

即ち、方法２は、ネットワークが端末からビーム復旧要求を受信した場合、前記ネットワークは図１０ｂに示されたように、（非周期的）ビーム報告トリガーを行う。

【0342】

図１０ｂは、方法２を図式化した図である。

【0343】

図１０ｂを参照すると、ネットワークは端末に周期的（Ｐｅｒｉｏｄｉｃ）ビームＲＳをＤＬへ送信する。

【0344】

以降、前記ネットワークが前記端末からビーム復旧要求を受信した場合、前記ネットワークは前記端末へ（非周期的）ビーム報告をトリガーする。

【0345】

ここで、方法２は方法１と異なり、端末が代替ＤＬビーム対を知っているため、前記ネットワークは該当端末へ（非周期的）ビームＲＳを別に送信しない（又はトリガーしない）。

【0346】

これによって、前記端末は基準リソース（ｒｅｆｅｒｅｎｃｅ ｒｅｓｏｕｒｃｅ）を介してビーム測定（ｂｅａｍ ｍｅａｓｕｒｅｍｅｎｔ）を行い、前記ビーム測定の結果を前記ネットワークに報告する。

【0347】

ここで、前記ビーム報告の過程で好まれる送信ビーム指示子（ｐｒｅｆｅｒｒｅｄ Ｔｘ ｂｅａｍ Ｉｎｄｉｃａｔｏｒ）とビーム品質メトリック（Ｂｅａｍ ｑｕａｌｉｔｙ ｍｅｔｒｉｃ）とが共に送信されることができる。これに対する具体的な説明は、後述することとする。

【0348】

見てきたように、方法２は、端末が既設定されたＲＳを介して測定したチャネルから代替できるＤＬ Ｔｘビーム（又はＤＬビーム対）情報を知っているとき、ネットワークのビームＲＳ送信と端末のビームＲＳ受信を省略し得るので、有用な方式である。

【0349】

これに対して、前記で見た方法１は、代替ビームがないか、基地局が代替ビームの有無に対する情報を知ることができないとき、有用な方式である。

【0350】

また、前記方法１及び方法２に対して（ビーム）報告セッティングが区別されないことがある。

【0351】

即ち、方法１及び方法２で、ビーム報告は同じフィードバックの情報を構成し、端末の同じ時間領域行動（ｔｉｍｅ ｄｏｍａｉｎ ｂｅｈａｖｉｏｒ）（例えば、非周期的報告）を有し、同じ周波数側細分性（ｇｒａｎｕｌａｒｉｔｙ）を有することができる。

【0352】

前記同じフィードバックの情報は、例えば、好まれるＤＬ送信ビーム指示子（ｐｒｅｆｅｒｒｅｄ ＤＬ Ｔｘ ｂｅａｍ ｉｎｄｉｃａｔｏｒ（ｓ））及びビーム品質メトリック（ｂｅａｍ ｑｕａｌｉｔｙ ｍｅｔｒｉｃ（ｓ））を含むことができる。

【0353】

前記好まれるＤＬ送信ビーム指示子は、例えば、ビームＩＤ、ＣＲＩ（ＣＳＩ－ＲＳ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）、ＲＳポートインデックス等であってもよい。

【0354】

前記ビーム品質メトリックは、例えば、Ｌ１ ＲＳＲＰ、ＣＱＩ等であってもよい。

【0355】

ビーム復旧方法で、ネットワークはＲＲＣシグナリングを介して、端末に次のうち少なくとも１つの設定方式をサポートすることができる。

【0356】

図１１は、ビーム関連の設定方法の一例を示した図である。

【0357】

（設定方法１）

【0358】

図１１ａを参照すると、報告セッティング（Ｒｅｐｏｒｔｉｎｇ ｓｅｔｔｉｎｇ）は、１つの非周期的ＣＳＩ／ビーム報告セッティングを含み、リソースセッティング（Ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）は１つの非周期的ビームＲＳセッティング（例えば、ＣＳＩ－ＲＳ）と１つの周期的／半固定的ビームＲＳセッティングを含むことができる。

【0359】

ここで、複数の報告セッティングは、報告セッティング等で表現されることができ、複数のリソースセッティングは、リソースセッティング等で表現されることができる。

【0360】

また、リソースセッティングは、１つ以上のリソースセットを含むことができる。

【0361】

図１１ａを参照すると、測定セッティング（Ｍｅａｓｕｒｅｍｅｎｔ ｓｅｔｔｉｎｇ）で１つの報告セッティングと二つのリソースセッティングがそれぞれリンク（又はチャネル）で連結されることを見ることができる。

【0362】

（設定方法２）

【0363】

図１１ｂを参照すると、報告セッティング（Ｒｅｐｏｒｔｉｎｇ ｓｅｔｔｉｎｇ）は、１つの非周期的ＣＳＩ／ビーム報告セッティングを含み、リソースセッティング（Ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）は１つのビームＲＳセッティングを含み、前記ビームＲＳセッティングは、下記のように少なくとも二つのリソースセットを含む。

【0364】

－非周期的ビームＲＳを有するリソースセット（Ｒｅｓｏｕｒｃｅ ｓｅｔ ｗｉｔｈ ａｐｅｒｉｏｄｉｃ ｂｅａｍ ＲＳ（ｓ））（例えば、ＣＳＩ－ＲＳ）

【0365】

－周期的／半固定的ビームＲＳを有するリソースセット（Ｒｅｓｏｕｒｃｅ ｓｅｔ ｗｉｔｈ ｐｅｒｉｏｄｉｃ／ｓｅｍｉ－ｐｅｒｓｉｓｔｅｎｔ ｂｅａｍ ＲＳ（ｓ））（例えば、ＣＳＩ－ＲＳ）

【0366】

また、前記二つのセッティング（報告セッティング、リソースセッティング）は、測定セッティング（Ｍｅａｓｕｒｅｍｅｎｔ ｓｅｔｔｉｎｇ）内の１つのリンク（又はチャネル）で連結される。

【0367】

前記で見たように、設定方法１は、時間－領域行動（ｔｉｍｅ－ｄｏｍａｉｎ ｂｅｈａｖｉｏｒ）（非周期的、半固定的（ＳＰ）、周期的）がリソースセッティング（Ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）単位で共通設定されるときに有用である。

【0368】

また、設定方法２は、時間－領域行動（ｔｉｍｅ－ｄｏｍａｉｎ ｂｅｈａｖｉｏｒ）がリソースセッティング（Ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）内のリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）単位で共通設定されるときに有用であり得る。

【0369】

次に、端末が前記で見た方法１と方法２のうちどの方法を好むかに対する情報又は既測定されたＲＳから代替ビームの存在有無（又は測定値存在の有無）に対する情報をネットワーク（又は基地局）に知らせる方法について具体的に見る。

【0370】

前記端末がネットワークへ送信するどんな方法を好むかに対する情報又は代替ビームの有無に対する情報を以下「制御情報」と表現することとする。

【0371】

ここで、前記制御情報は、ビーム復旧要求（ｂｅａｍ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）の信号又はビーム失敗報告（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｐｏｒｔｉｎｇ）の信号に含まれることができる。

【0372】

前記制御情報は代替ビームの存在有無を直接的に指示する指示子又は指示情報であるか、予め設定された非周期的ビーム報告セッティング（ｐｒｅ－ｃｏｎｆｉｇｕｒｅｄ ａｐｅｒｉｏｄｉｃ ｂｅａｍ ｒｅｐｏｒｔｉｎｇ ｓｅｔｔｉｎｇ）に関連した（ａｓｓｏｃｉａｔｅｄ）好まれたリンク情報（設定方法１の場合）、好まれたリソースセッティング情報（設定方法１の場合）、或いは好まれたリソースセット情報（設定方法２の場合）であり得る。

【0373】

前記制御情報は、ＬＴＥシステムでのＵＣＩ（Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）のように物理層の制御情報としてネットワークに伝達されてもよく、上位層のメッセージ形態（例えば、ＭＡＣ ＣＥ）で伝達されてもよい。

【0374】

特に、端末は、前記制御情報をＰＲＡＣＨと同じリソース（例：シンボル）を用いて送信することができる。

【0375】

前記端末が前記ＰＲＡＣＨとＣＤＭ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）されるか、ＦＤＭ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）された信号をビーム復旧要求の信号として使用（又は送信）する場合、代替ビームの存在有無によってＰＲＡＣＨで使用されるシーケンスセット（ｓｅｑｕｅｎｃｅ ｓｅｔ）を分けて使用することができる。

【0376】

例えば、ＰＲＡＣＨで使用されるシーケンスセットを分けて使用する場合、分離されたルートインデックス（ｓｅｐａｒａｔｅｄ ｒｏｏｔ ｉｎｄｅｘ（ｅｓ））又はサイクリックシフト値（ｃｙｃｌｉｃ ｓｈｉｆｔ ｖａｌｕｅｓ）等が使用されることができる。

【0377】

或いは、前記端末が前記ＰＲＡＣＨとＣＤＭされるか、ＦＤＭされた信号をビーム復旧要求の信号として使用する場合、前記ＰＲＡＣＨで使用されるシーケンスセットと同じシーケンスセットを使用することができる。但し、この場合、ＰＲＡＣＨであるか、又はビーム復旧要求の信号であるかは、互いに異なる時間領域／周波数領域ＯＣＣ（Ｏｒｔｈｏｇｏｎａｌ Ｃｏｖｅｒ Ｃｏｄｅ）を適用して区別することができる。

【0378】

また、ネットワーク（又は基地局）は、上位層のメッセージであるＭＡＣ ＣＥ（ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）及び／又は物理層のメッセージであるＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）に非周期的報告トリガリング（ａｐｅｒｉｏｄｉｃ ｒｅｐｏｒｔｉｎｇ ｔｒｉｇｇｅｒｉｎｇ）を端末へ指示するとき、下記情報（（１）乃至（４））のうち少なくとも１つを含むことができる。

【0379】

（１）予め関連したセッティング内有効／有効ではないリンク（Ｖａｌｉｄ／ｉｎｖａｌｉｄ Ｌｉｎｋ ｗｉｔｈｉｎ ｔｈｅ ｐｒｅ－ａｓｓｏｃｉａｔｅｄ ｓｅｔｔｉｎｇｓ）に対する情報（設定方法１の場合）

【0380】

：端末は測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ ｓｅｔｔｉｎｇ）で予め関連した（ｐｒｅ－ａｓｓｏｃｉａｔｅｄ）複数のリソースセッティングのうち、有効なリンク（ｖａｌｉｄ ｌｉｎｋ）に指示される（又は有効ではないリンク（ｉｎｖａｌｉｄ ｌｉｎｋ）に指示されない）リソースセッティングに含まれたＲＳのみを基準リソース（ｒｅｆｅｒｅｎｃｅ ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定と前記ビーム測定に対するビーム報告（ビーム測定及びビーム報告）を行う。

【0381】

（２）予め関連したセッティング内有効／有効ではないリソースセッティング（Ｖａｌｉｄ／ｉｎｖａｌｉｄ Ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ ｗｉｔｈｉｎ ｔｈｅ ｐｒｅ－ａｓｓｏｃｉａｔｅｄ ｓｅｔｔｉｎｇｓ）に対する情報（設定方法２の場合）

【0382】

：端末は、測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ ｓｅｔｔｉｎｇ）で予め関連した（ｐｒｅ－ａｓｓｏｃｉａｔｅｄ）複数のリソースセッティングのうち、有効なリソースセッティングに含まれた（又は有効ではないリソースセッティングに含まれない）ＲＳのみを基準リソース（ｒｅｆｅｒｅｎｃｅ ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定及びビーム報告を行う。

【0383】

（３）予め関連したリソースセッティング内に有効／有効ではないリソースセットに対する情報（設定方法２の場合）

【0384】

：端末は、測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ ｓｅｔｔｉｎｇ）で予め関連したリソースセッティング（ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）内で有効なリソースセット（ｖａｌｉｄ ｒｅｓｏｕｒｃｅ ｓｅｔ）に含まれたＲＳのみを基準リソース（ｒｅｆｅｒｅｎｃｅ ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定とビーム報告を行う。

【0385】

（４）報告タイプ／モード（Ｒｅｐｏｒｔｉｎｇ ｔｙｐｅ／ｍｏｄｅ）設定情報（設定方法１及び設定方法２に全て適用）

【0386】

：報告タイプ／モード設定情報は非周期的リソースのトリガリングと非周期的報告のトリガリングが共に指示されるか、それとも非周期的報告トリガリングのみ指示されるかに対する指示子又は指示情報を示す。

【0387】

ここで、非周期的リソースのトリガリングと非周期的報告のトリガリングが共に指示される場合の報告タイプ又はモードは、共同トリガリングモード又は第１モードで表現されることができ、非周期的報告トリガリングのみ指示される場合の報告タイプ又はモードは、報告トリガリング専用モード（ｒｅｐｏｒｔｉｎｇ ｔｒｉｇｇｅｒｉｎｇ ｏｎｌｙ ｍｏｄｅ）又は第２モードで表現されることができる。

【0388】

前記共同トリガリングモード（又は第１モード）である場合、端末はＲＲＣに設定されたリソースセッティング（ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）（設定方法１）又はリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）（設定方法２）のうち、非周期的リソースセッティング／リソースセット（ａｐｅｒｉｏｄｉｃ ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ／ｒｅｓｏｕｒｃｅ ｓｅｔ）のみを基準リソース（ｒｅｆｅｒｅｎｃｅ ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定及びビーム報告を行う。

【0389】

即ち、端末は非周期的報告（ａｐｅｒｉｏｄｉｃ ｒｅｐｏｒｔｉｎｇ）と連結設定された周期的リソース／半固定的リソースを無視する。

【0390】

また、報告トリガリング専用モード（又は第２モード）である場合、端末はＲＲＣに設定されたリソースセッティング（ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）（設定方法１）／リソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）（設定方法２）のうち、周期的（ｐｅｒｉｏｄｉｃ）又は半固定的（ｓｅｍｉ－ｐｅｒｓｉｓｔｅｎｔ）リソースセッティング／リソースセットのみを基準リソース（ｒｅｆｅｒｅｎｃｅ ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定及びビーム報告を行う。

【0391】

即ち、端末は非周期的報告（ａｐｅｒｉｏｄｉｃ ｒｅｐｏｒｔｉｎｇ）と連結設定された非周期的リソース（ａｐｅｒｉｏｄｉｃ ｒｅｓｏｕｒｃｅ）を無視する。

【0392】

さらに、端末が基地局へ方法１と方法２のうちどの方法を好むかに対する情報又は既測定されたＲＳから代替ビームの存在有無（又は測定値存在の有無）に対する情報を報告した場合、基地局は端末の報告情報に対する適用可否を示す情報（確認メッセージ又はＡＣＫ／ＮＡＣＫ）を端末へ送信することができる。

【0393】

前記端末の報告情報が前記で見た基地局の非周期的報告トリガリング（ａｐｅｒｉｏｄｉｃ ｒｅｐｏｒｔｉｎｇ ｔｒｉｇｇｅｒｉｎｇ）を指示する前に基地局へ送信された場合、前記端末の報告情報に対する適用可否を示す情報は、前記の（１）乃至（４）の情報と共に基地局の非周期的報告トリガリングを指示するときに送信されることもできる。

【0394】

端末が基地局へ方法１と方法２のうちどの方法を好むかに対する情報又は既測定されたＲＳから代替ビームの存在有無（又は測定値存在の有無）に対する情報を送信する場合、基地局は該当端末へ該当情報の受信及び適用を確定する情報を送信することができる。

【0395】

例えば、基地局が確認（ｃｏｎｆｉｒｍｅｄ）（又はＡＣＫ）メッセージを端末へ送信した場合、これは、端末が送信した情報を基地局で適用することを確定することを示す。

【0396】

或いは、基地局が確認メッセージを送信しないか、未確認（ｎｏｔ－ｃｏｎｆｉｒｍｅｄ）（又はＮＡＣＫ）メッセージを端末へ送信した場合、前記基地局は、前記で見た（１）乃至（４）の情報のうち、一部情報をさらに送信するように端末に要求するか、該当端末にとって方法１と方法２のうちどの方法を好むかに対する情報又は代替ビームの有無（或いは測定値存在の有無）に対する情報を再送信するようにすることができる。

【0397】

前記で見たように、前記方法１と方法２のうちどの方法を好むかに対する情報又は代替ビームの存在有無（或いは測定値存在の有無）に対する情報は、簡単に「制御情報」と呼ばれ得る。

【0398】

また、前記で見た（１）乃至（４）の情報は、端末が方法１と方法２のうちどの方法を好むかに対する情報又は代替ビームの存在有無（或いは測定値存在の有無）に対する情報を基地局に（先に）報告した場合、省略されることもある。

【0399】

次に、端末がビーム測定及びビーム報告のために基準リソースを決定（又は判断）する方法について見ることとする。

【0400】

端末はビーム復旧要求（ｂｅａｍ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）の信号（又はビーム失敗報告信号）に（ｉ）代替ビームに対する測定値がある（又は方法２を好む）という情報を基地局へ明示的又は暗示的に（ｅｘｐｌｉｃｉｔ又はｉｍｐｌｉｃｉｔ）報告する。

【0401】

以降、前記端末が（特定時間以内に、又は特定タイマー満了前に）基地局から非周期的ビーム報告トリガリング（ａｐｅｒｉｏｄｉｃ ｂｅａｍ ｒｅｐｏｒｔｉｎｇ ｔｒｉｇｇｅｒｉｎｇ）の指示を受けた場合、前記端末は、該当非周期的ビーム報告に連結されたリソースセッティング（設定方法１）／リソースセット（設定方法２）に含まれたリソース（ＲＳ）のうち、報告トリガリングメッセージを受信したスロット（ｓｌｏｔ）以前に活性化（又はトリガー又は設定）されて測定（ｍｅａｓｕｒｅｍｅｎｔ）が可能なリソース（例：周期的ＲＳ、活性化された半固定的ＲＳ、又は予めトリガーされた非周期的ＲＳ）を基準リソース（ｒｅｆｅｒｅｎｃｅ ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定及びビーム報告を行うことができる。

【0402】

即ち、前記基準リソースは、前記報告トリガリングメッセージを受信したスロット以前に活性化された特定リソースで決定される。

【0403】

これに関する内容は、方法２を説明した図１０ｂを参照することとする。

【0404】

また別の一例として、端末がビーム復旧要求信号（又はビーム失敗報告信号）に（ｉｉ）代替ビームに対する測定値がない（又は方法１を好む）という情報を明示的又は暗示的に基地局に報告する。

【0405】

以降、前記端末が（特定時間以内に又は特定タイマー満了前に）基地局から非周期的ビーム報告トリガリングの指示を受けた場合、前記端末は、該当非周期的ビーム報告に関連したリソースセッティング（設定方法１）／リソースセット（設定方法２）に含まれたリソース（ＲＳ）のうち、報告トリガリングメッセージを受信したスロットと同じスロット（例えば、一緒にトリガーされた非周期的ＲＳ）又は以降の時点に活性化（又はトリガー又は設定）されるリソース（例：ｔｒｉｇｇｅｒｅｄ／ａｃｔｉｖａｔｅｄ ａｐｅｒｉｏｄｉｃ ＲＳ ｉｎ ｌａｔｅｒ ｓｌｏｔ（ｓ））を参照リソース（ｒｅｆｅｒｅｎｃｅ ｒｅｓｏｕｒｃｅ）と判断し、ビーム測定及びビーム報告を行うことができる。これに関する内容は、方法１を説明した図１０ａを参照することとする。

【0406】

即ち、前記基準リソースは、前記報告トリガリングメッセージを受信したスロットと同じスロット又は前記報告トリガリングメッセージを受信した以降、スロットに活性化される特定リソースで決定される。

【0407】

図１２は、ビーム復旧を行う方法の一例を示したフローチャートである。

【0408】

まず、端末はビーム管理（ｂｅａｍ ｍａｎａｇｅｍｅｎｔ）に使用されるビーム基準信号（ｂｅａｍ ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ：ＢＲＳ）を基地局から受信する（Ｓ１２１０）。

【0409】

以降、前記端末は、ビーム失敗イベント（ｂｅａｍ ｆａｉｌｕｒｅ ｅｖｅｎｔ）が検出された場合、ビーム失敗復旧要求（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）のための制御信号を前記基地局に送信する（Ｓ１２２０）。

【0410】

前記ビーム失敗イベントは、前記受信されたビーム基準信号に基づいて検出されることができる。

【0411】

前記制御信号は、代替ビームが存在するか否かを示す指示情報を含む。

【0412】

前記で見たように、前記代替ビームは、前記ビーム管理のために設定された基準信号のうち、特定チャネルの品質よりも大きいチャネルの品質を有する基準信号を意味することができる。

【0413】

以降、前記端末はビーム報告（ｂｅａｍ ｒｅｐｏｒｔｉｎｇ）がトリガーされた（ｔｒｉｇｇｅｒｅｄ）場合、特定リソースでビーム測定の結果を前記基地局に報告（ｒｅｐｏｒｔ）する（Ｓ１２３０）。

【0414】

前記制御信号は、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）と同じ時間リソースを使用することができる。

【0415】

この場合、前記制御信号は、前記ＰＲＡＣＨと前記時間リソースでＣＤＭ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）又はＦＤＭ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）されることができる。

【0416】

前記制御信号は、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介して送信されることができる。

【0417】

前記制御信号は、前記代替ビームの存在有無によって互いに異なる時間及び／又は周波数リソース、互いに異なるシーケンスセット（ｓｅｑｕｅｎｃｅ ｓｅｔ）、及び／又は互いに異なるＵＣＩ（Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）を使用することができる。

【0418】

この場合、前記互いに異なるシーケンスセットは、ルートシーケンスインデックス（ｒｏｏｔ ｓｅｑｕｅｎｃｅ ｉｎｄｅｘ）又はサイクリックシフト値（ｃｙｃｌｉｃ ｓｈｉｆｔ ｖａｌｕｅ）によって区別されることができる。

【0419】

また、前記指示情報は、予め設定された非周期的ビーム報告セッティング（ｂｅａｍ ｒｅｐｏｒｔｉｎｇ ｓｅｔｔｉｎｇ）に関連した（ａｓｓｏｃｉａｔｅｄ）好まれるリンクに対する情報、予め設定された非周期的ビーム報告セッティングに関連した好まれるリソースセッティング（ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）に対する情報又は予め設定された非周期的ビーム報告セッティングに関連した好まれるリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）に対する情報であり得る。

【0420】

さらに、前記端末は、前記ビーム報告のトリガリング（ｔｒｉｇｇｅｒｉｎｇ）を指示する指示メッセージを前記基地局から受信することができる。

【0421】

ここで、前記ビーム報告は、前記指示メッセージに基づいてトリガーされることができる。

【0422】

前記指示メッセージは、測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ ｓｅｔｔｉｎｇ）に予め関連した（ｐｒｅ－ａｓｓｏｃｉａｔｅｄ）セッティング内で有効（ｖａｌｉｄ）又は有効ではない（ｉｎｖａｌｉｄ）リンクと関連した情報、前記測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ ｓｅｔｔｉｎｇ）に予め関連した（ｐｒｅ－ａｓｓｏｃｉａｔｅｄ）セッティング内で有効又は有効ではないリソースセッティング（ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）と関連した情報、前記測定セッティング（ｍｅａｓｕｒｅｍｅｎｔ ｓｅｔｔｉｎｇ）に予め関連した（ｐｒｅ－ａｓｓｏｃｉａｔｅｄ）セッティング内で有効又は有効ではないリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）と関連した情報又はビーム報告モード設定情報のうち少なくとも１つを含むことができる。

【0423】

前記測定セッティングは、１つの報告セッティングと二つのリソースセッティングがそれぞれリンク（ｌｉｎｋ）で連結されるか、又は１つの報告セッティングと１つのリソースセッティングがリンクで連結されることができる。

【0424】

前記ビーム報告モード設定情報は、非周期的ビーム基準信号の送信と非周期的ビーム報告が共にトリガーされる第１モード又は非周期的ビーム報告のみトリガーされる第２モードを指示することができる。

【0425】

前記第１モードは、前記で見た共同トリガリングモードを示し、前記第２モードは、前記で見た報告トリガリング専用モードを示す。

【0426】

もし、前記ビーム報告モード設定情報が前記第１モードに設定された場合、前記特定リソースは、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）に設定されたリソースセッティング（ｒｅｓｏｕｒｃｅ ｓｅｔｔｉｎｇ）又はリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）のうち、非周期的リソースセッティング又は非周期的リソースセットであり得る。

【0427】

この場合、前記特定リソースは、前記指示メッセージを受信したスロットと同じスロット又は前記指示メッセージを受信したスロット以降のビーム測定が可能なように活性化されたリソースであり得る。

【0428】

或いは、前記ビーム報告モード設定情報が前記第２モードに設定された場合、前記特定リソースはＲＲＣに設定されたリソースセッティング又はリソースセットのうち、周期的又は半固定的リソースセッティング又はリソースセットであり得る。

【0429】

この場合、前記特定リソースは、前記指示メッセージを受信したスロット以前にビーム測定が可能なように活性化されたリソースであり得る。

【0430】

さらに、前記端末は、前記基地局から前記報告に対する応答を受信することができる。

【0431】

もし、前記応答がＮＡＣＫである場合、前記端末は、前記指示情報又は前記指示メッセージに含まれた情報のうち少なくとも１つを含む情報を前記基地局に再送信することができる。

【0432】

以下、ビーム復旧要求（ｂｅａｍ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）を行うＵＬリソースのタイプ（ｔｙｐｅ）及び／又はＵＬリソースの設定によって異なってビーム失敗報告（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｐｏｒｔｉｎｇ）と共にビーム報告情報のうち一部又は全てを共に行う方法について見ることとする。

【0433】

前記ビーム復旧要求（ｂｅａｍ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）は、ビーム失敗報告（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｐｏｒｔｉｎｇ）で表現されることもできる。

【0434】

前記ビーム報告（ｂｅａｍ ｒｅｐｏｒｔｉｎｇ）情報は、例えば、好まれるＤＬ送信ビーム指示子（ｐｒｅｆｅｒｒｅｄ ＤＬ Ｔｘ ｂｅａｍ ｉｎｄｉｃａｔｏｒ（ｓ））、ビーム品質メトリック（ｂｅａｍ ｑｕａｌｉｔｙ ｍｅｔｒｉｃ（ｓ））（例えば、Ｌ１ ＲＳＲＰ、ＣＱＩ））等であってもよい。

【0435】

前記好まれるＤＬ送信ビーム指示子（ｐｒｅｆｅｒｒｅｄ ＤＬ Ｔｘ ｂｅａｍ ｉｎｄｉｃａｔｏｒ（ｓ））は、例えば、ビームＩＤ、ＣＲＩ（ＣＳＩ－ＲＳ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）、ＲＳポートのインデックス、同期信号ブロック（ＳＳＢ）のインデックス、ＰＢＣＨ ＤＭＲＳのインデックス等であってもよい。

【0436】

前記ビーム品質メトリック（ｂｅａｍ ｑｕａｌｉｔｙ ｍｅｔｒｉｃ（ｓ））は、例えば、Ｌ１ ＲＳＲＰ、ＣＱＩ等であってもよい。

【0437】

もし、前記ビーム報告情報を全て報告する場合、前記で見た（方法２の）設定方法２で基地局の非周期的ビーム報告トリガリング（ａｐｅｒｉｏｄｉｃ ｂｅａｍ ｒｅｐｏｒｔｉｎｇ ｔｒｉｇｇｅｒｉｎｇ）過程と後続する端末のビーム報告（ｂｅａｍ ｒｅｐｏｒｔｉｎｇ）過程が省略されることができ、これを「設定方法３」と定義することができる。

【0438】

また、前記ビーム報告情報を一部報告する方式は、一部の情報のみを報告する方式だけでなく、粗い（ｃｏａｒｓｅ）情報（又はｌｏｗｅｒ ｇｒａｎｕｌｉｔｙの情報）を送る方式も含む。

【0439】

例えば、ビーム失敗報告（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｐｏｒｔｉｎｇ）と共に送信するＬ１ ＲＳＲＰは、後続するビーム報告過程を通じて送信するＬ１ ＲＳＲＰに比べてより少ないビット数を含み（又は割り当て）、より少ない量子レベル（ｑｕａｎｔｉｚａｔｉｏｎ ｌｅｖｅｌ）を有するように設定することができる。

【0440】

或いは、基地局は端末に、以前時点に（ビーム失敗を）報告した報告値に対して差異値を計算及び報告するようにして、（ビーム失敗）報告情報量を減らすようにすることもできる。

【0441】

例えば、端末は、異なる（ｄｉｆｆｅｒｅｎｔｉａｌ）ＣＱＩ、異なる（ｄｉｆｆｅｒｅｎｔｉａｌ）ＲＳＲＰをビーム失敗報告と共に送信することができる。

【0442】

見てきたように、ＮＲシステムでビーム復旧要求（ＢＲＲ）を送信するリソースは、ＰＲＡＣＨとＣＤＭ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）又はＦＤＭ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）されて、時間リソースを共有するＵＬリソース（以下、「ＵＬタイプＩ」という）と、ＰＲＡＣＨと異なる時間リソースを使用するＵＬリソース（以下、「ＵＬタイプＩＩ」という）が全て使用されることができる。

【0443】

前記ＵＬタイプＩは、ＰＲＡＣＨと同じように相対的にＵＬリソースが多いスロットタイプ／設定（例えば、ＵＬスロット、ＵＬドミナントスロット）に設定されることができ、ＵＬタイプＩＩは、ＰＵＣＣＨのようにＵＬリソースが少ないスロットでも設定されることができる。

【0444】

前記ＵＬタイプＩは、ビーム復旧要求（又はビーム失敗報告要求）を目的で別に設定されたＰＲＡＣＨプリアンブルであり得る。

【0445】

即ち、ビーム復旧要求のためにＰＲＡＣＨが使用されることができ、前記ＰＲＡＣＨは、競合フリー（ｃｏｎｔｅｎｔｉｏｎ－ｆｒｅｅ）（又は非競合（ｎｏｎ－ｃｏｎｔｅｎｔｉｏｎ））ベースのＰＲＡＣＨ又は競合ベースのＰＲＡＣＨであり得る。

【0446】

ここで、競合フリー（ｃｏｎｔｅｎｔｉｏｎ－ｆｒｅｅ）ベースのＰＲＡＣＨリソースは、別の競合フリー（ｃｏｎｔｅｎｔｉｏｎ－ｆｒｅｅ）ベースのＰＲＡＣＨリソースとＦＤＭ又はＣＤＭされることができる（同じ時間又は周波数リソースを使用するが、シーケンスは異なる）。

【0447】

例えば、前記ＵＬタイプＩは、ビーム失敗報告要求（ＢＦＲＱ）の目的で設定されたＰＲＡＣＨプリアンブル、前記ＵＬタイプＩＩは、短い／長いＰＵＣＣＨリソースであり得る。

【0448】

また、端末が前記ＵＬタイプＩＩを使用してＢＦＲＱを送信する場合にのみ、ビーム品質（Ｌ１－ＲＳＲＰ）を報告することができる。

【0449】

ＮＲシステムで、ＰＵＣＣＨは２種類（短いＰＵＣＣＨ又は長いＰＵＣＣＨ）に分けられる。

【0450】

前記短いＰＵＣＣＨは１～２シンボルで構成され、スロットの最後に位置することができ、最大数十ビットのＵＣＩ（ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を送信することができる。

【0451】

また、前記長いＰＵＣＣＨは、４～１２シンボル（又は１４シンボル）で構成され、最大数百ビットのＵＣＩを送信することができる。

【0452】

前記ＵＬタイプＩＩは、ＰＵＳＣＨを介して送信されるか、又は短い／長いＰＵＣＣＨを介して送信されるか、又は別途に定義されるアップリンクチャネルを介して送信されることができる。

【0453】

しかしながら、ビーム失敗（ｂｅａｍ ｆａｉｌｕｒｅ）状況でのリンク適応（ｌｉｎｋ ａｄａｐｔａｔｉｏｎ）の問題、ＵＬリソース割り当ての問題等を考慮したとき、前記ＵＬタイプＩＩは、短いＰＵＣＣＨ及び／又は長いＰＵＣＣＨを使用して送信されることがさらに好ましい。

【0454】

本明細書で使用される「Ａ及び／又はＢ」は、「Ａ又はＢのうち少なくとも１つを含む」と同じ意味と解釈され得る。

【0455】

前記ＵＬタイプＩは、ＰＲＡＣＨと同じ時間リソースを使用するので、基地局は該当信号（ビーム復旧要求の信号）を受信するために（全方向に）受信ビームスイーピング（Ｒｘ ｂｅａｍ ｓｗｅｅｐｉｎｇ）を適用すると仮定することができる。

【0456】

従って、特定ビームに該当する時間／周波数リソースでのみよい品質で信号が受信されるため、前記ビーム復旧要求の信号は、少ない情報が繰り返して送信される構造を有するように設計されることがより有利である。

【0457】

従って、前記ＵＬタイプＩは、前記で見た更なるビーム報告情報（好まれるＤＬ送信ビーム指示子、ビーム品質メトリック）が含まれないか、又はＵＬタイプＩＩよりも少ないビット数で構成されたビーム報告情報のみ含まれるように設定されることが好ましい。

【0458】

また、前記ＵＬタイプＩの場合、（方法２の）設定方法３がサポートされない。

【0459】

前記ＵＬタイプＩＩの場合、やはりＰＵＣＣＨタイプ（短いＰＵＣＣＨ又は長いＰＵＣＣＨ）及びＰＵＣＣＨリソースのサイズ（シンボルの数及び／又はＰＲＢサイズ）によってサポートされるメカニズム（ｍｅｃｈａｎｉｓｍ）が異なって定義又は設定されることができる。

【0460】

例えば、長いＰＵＣＣＨを介して送ることができるビーム情報は、ビーム識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のためのＲＳ指示子だけでなく、該当Ｌ１ ＲＳＲＰを送信することができるが、短いＰＵＣＣＨを介して送ることができるビーム情報は、Ｌ１ ＲＳＲＰが省略されることができる。

【0461】

或いは、短いＰＵＣＣＨは、前記更なるビーム報告情報が含まれないように設計又は定義することもできる。

【0462】

また、短い／永井PUCCHシンボルの数（の範囲）に応じてサポートされるビーム報告情報が異なって設計されることもできる。

【0463】

また、短いＰＵＣＣＨは、早い（ｆａｓｔ）ＡＣＫ／ＮＡＣＫのための目的で設計される側面が強いので、ＲＲＣに半静的（ｓｅｍｉ－ｓｔａｔｉｃ）に割り当て（又は設定）られることは好ましくない。

【0464】

従って、前記ＵＬタイプＩＩは、長いＰＵＣＣＨでのみ送信されるようにすることがより好ましい。

【0465】

前記で見た説明では、ＵＬタイプＩとＵＬタイプＩＩを差別的に（又はそれぞれ）設計または定義することを仮定したが、統合的な設計やはり可能である。

【0466】

以下で、ＵＬタイプＩとＵＬタイプＩＩを統合的に設計する方法について見る。

【0467】

基地局は、ビーム失敗報告（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｐｏｒｔｉｎｇ）と共に送信できる情報の特性及び情報量に応じて別途の（複数個の）ＵＬリソースをＲＲＣに設定することができる。

【0468】

このとき、周期「Ｎ」（Ｎは自然数）に設定された特定ＵＬリソースは、Ｎ掛け整数倍の周期ではＰＲＡＣＨリソースとＣＤＭまたはＦＤＭされ、残りの時点ではＰＲＡＣＨリソースとＴＤＭされることができる。

【0469】

ここで、該当リソースで送信される情報の構成は、報告時点と関係なく同じように構成されることができる。

【0470】

代替ビームの有無に対する情報送信方法

【0471】

前記で見た代替ビームの有無に対する暗示的／明示的（ｉｍｐｌｉｃｉｔ／ｅｘｐｌｉｃｉｔ）指示（ｉｎｄｉｃａｔｉｏｎ）のフィードバック情報やはり、ＵＬリソースのタイプ及び／又は設定に応じて異なって（または差別的に）ビーム報告情報に含まれるか、またはビーム復旧要求と共に送信されることができる。

【0472】

例えば、ＵＬタイプＩの場合、基地局は全方向に信号を受信し、少ないフィードバックペイロード（ｆｅｅｄｂａｃｋ ｐａｙｌｏａｄ）のみサポートできるので、前記基地局は端末からビーム復旧要求（ｂｅａｍ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）と共に代替ビームの有無を含めて報告を受けることができる（設定方法１及び／又は設定方法２をサポート）。

【0473】

また、ＵＬタイプＩＩの場合、基地局は特定方向に信号を受信するので、代替ビームがある場合にのみ使用するように定義し、ビーム復旧要求（ｂｅａｍ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）と共に代替ビームの有無情報は送信しないようにし、ビーム識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のための情報（及びビーム品質情報）を含めて端末が報告するようにすることができる（設定方法２及び／又は設定方法３をサポート）。

【0474】

前記ビーム識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）情報は、暗示的な方式で伝達されることもできる。

【0475】

これは（チャネル相互関係が成立（またはビーム対応が成立）する端末に対して）ＤＬリソースに対応するＵＬリソースが設定された場合（例えば、ＤＬ ＲＳリソースｘの品質に優れた端末は、ＵＬリソースｙを使用して信号を送信するようにする形態で）、端末が信号を送信するＵＬリソース情報によって基地局は該当端末に対するＤＬビーム情報を暗示的に取得できる。

【0476】

即ち、複数個のＤＬリソース（例えば、同期信号ブロック、ＰＢＣＨ ＤＭＲＳリソース、ＣＳＩ－ＲＳリソース）のそれぞれに対応する複数個のＵＬリソース（例えば、ＵＬタイプＩまたはＵＬタイプＩＩ）がマッピングされて設定される状況で、端末が一個又は複数個のＵＬリソースを選択して信号を送信することによって、基地局は暗示的にどのＤＬリソースに対応するＤＬ Ｔｘビームが（代替ビームとして）品質に優れるかを識別することができる。

【0477】

図１３及び図１４は、ビーム復旧を行う端末の動作の一例を示したフローチャートである。

【0478】

図１４に関する説明は、図１３と同じ部分は図１３を参照し、差のある部分のみ別に表示して見ることとする。

【0479】

まず、端末は、ビーム管理（ｂｅａｍ ｍａｎａｇｅｍｅｎｔ）に使用されるビーム基準信号（ｂｅａｍ ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）を基地局から受信する（Ｓ１３１０）。

【0480】

以降、前記端末は、ビーム失敗イベント（ｂｅａｍ ｆａｉｌｕｒｅ ｅｖｅｎｔ）が検出された場合、ビーム失敗復旧要求（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）と関連した制御信号を送信するためのＵＬ（ｕｐｌｉｎｋ）リソースを決定する（Ｓ１３２０）。

【0481】

ここで、前記ＵＬリソースは、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）と同じ時間リソースを使用するタイプ１のリソース、又は前記ＰＲＡＣＨと互いに異なる時間リソースを使用するタイプ２のリソースであり得る。

【0482】

また、前記タイプ１のリソースは、前記ＰＲＡＣＨとＦＤＭ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）及び／又はＣＤＭ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）されることができる。

【0483】

また、前記タイプ２のリソースは、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）リソース又はＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）リソースであってもよい。

【0484】

もし、前記タイプ２のリソースがＰＵＣＣＨリソースである場合、前記ＰＵＣＣＨリソースは短いＰＵＣＣＨ又は長いＰＵＣＣＨのうち少なくとも１つであってもよい。

【0485】

以降、前記端末は、前記決定されたＵＬリソースで前記制御信号を前記基地局に送信する（Ｓ１３３０）。

【0486】

ここで、前記制御信号は、ビーム報告と関連した情報の一部又は全てを含むか、又は前記ビーム報告と関連した情報を含まないことがある。

【0487】

もし、前記ＵＬリソースがタイプ１のリソースである場合、前記制御信号は、前記ビーム報告と関連した情報の一部のみ含み、前記ビーム報告と関連した情報は、代替ビームの有無に対する情報を含むことができる。

【0488】

前記代替ビームは、前記ビーム管理のために設定された基準信号のうち、特定チャネルの品質よりも大きいチャネル品質を有する基準信号を意味することができる。

【0489】

もし、前記ＵＬリソースがタイプ２のリソースである場合、前記制御信号は、前記ビーム報告と関連した情報の全てを含むことができる。

【0490】

この場合、前記ビーム報告と関連した情報は、ビーム識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のためのビーム識別情報又はビーム品質（ｑｕａｌｉｔｙ）を示すビーム品質情報のうち少なくとも１つを含むことができる。

【0491】

さらに、前記制御信号が前記ビーム報告と関連した情報の一部を含む場合、端末は特定リソースでビーム測定の結果を前記基地局に報告（ｒｅｐｏｒｔ）する（Ｓ１４４０）。 ここで、前記ビーム測定の結果に対する報告は、ビーム報告（ｂｅａｍ ｒｅｐｏｒｔｉｎｇ）がトリガーされた（ｔｒｉｇｇｅｒｅｄ）場合に行われることができる。

【0492】

図１４のＳ１４１０乃至Ｓ１４３０は、図１３のＳ１３１０乃至Ｓ１３３０の段階と同一である。

【0493】

図１５は、ビーム失敗復旧手続の一例を示したフローチャートである。

【0494】

ＢＦＲ手続は、（１）ビーム失敗検出（Ｂｅａｍ ｆａｉｌｕｒｅ ｄｅｔｅｃｔｉｏｎ）ステップ（Ｓ１５１０）、（２）新しいビーム識別（Ｎｅｗ ｂｅａｍ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）ステップ（Ｓ１５２０）、（３）ビーム失敗復旧要求（Ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ：ＢＦＲＱ）ステップ（Ｓ１５３０）及び（４）基地局からＢＦＲＱに対する応答（ｒｅｓｐｏｎｓｅ）をモニターするステップ（Ｓ１５４０）を含む。

【0495】

ここで、Ｓ１５３０ステップ、すなわち、ＢＦＲＱ送信のために、ＰＲＡＣＨプリアンブル（ｐｒｅａｍｂｌｅ）又はＰＵＣＣＨが使用できる。

【0496】

前記Ｓ１５１０ステップ、すなわち、ビーム失敗検出（Ｂｅａｍ ｆａｉｌｕｒｅ ｄｅｔｅｃｔｉｏｎ）についてより具体的に説明する。

【0497】

全てのサービングビーム（ｓｅｒｖｉｎｇ ｂｅａｍ）のＢＬＥＲ（ｂｌｏｃｋ ｅｒｒｏｒ ｒａｔｅ）が臨界値以上であるとき、ビーム失敗インスタンス（ｂｅａｍ ｆａｉｌｕｒｅ ｉｎｓｔａｎｃｅ）と呼ばれる。

【0498】

端末がモニターするＲＳ（ｑｏ）はＲＲＣにより明示的に設定されるか又は暗示的に制御チャネル（ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）のためのビームＲＳにより決定される。

【0499】

上位層へのビーム失敗インスタンス（ｂｅａｍ ｆａｉｌｕｒｅ ｉｎｓｔａｎｃｅ）の指示（ｉｎｄｉｃａｔｉｏｎ）は周期的（ｐｅｒｉｏｄｉｃ）であり、指示間隔（ｉｎｄｉｃａｔｉｏｎ ｉｎｔｅｒｖａｌ）はＢＦＤ（ｂｅａｍ ｆａｉｌｕｒｅ ｄｅｔｅｃｔｉｏｎ） ＲＳの最も低い周期により決定される。

【0500】

もし、評価（ｅｖａｌｕａｔｉｏｎ）がビーム失敗インスタンスＢＬＥＲ臨界値（ｂｅａｍ ｆａｉｌｕｒｅ ｉｎｓｔａｎｃｅ ＢＬＥＲ ｔｈｒｅｓｈｏｌｄ）より低いとき、上位層への指示は行われない。

【0501】

Ｎ個の連続的なビーム失敗インスタンスが発生する場合、ビーム失敗が宣言（ｄｅｃｌａｒｅ）される。

【0502】

ここで、ＮはＲＲＣにより設定されるＮｒｏｆＢｅａｍＦａｉｌｕｒｅＩｎｓｔａｎｃｅパラメータである。

【0503】

１－ｐｏｒｔ ＣＳＩ－ＲＳ及びＳＳＢがＢＦＤ ＲＳセットに対してサポートされる。

【0504】

次に、Ｓ１５２０ステップ、すなわち、新しいビーム指示（ｎｅｗ ｂｅａｍ ｉｎｄｉｃａｔｉｏｎ）について説明する。

【0505】

ネットワーク（ＮＷ）は、１つ又は多数のＰＲＡＣＨリソース／シーケンスを端末に設定することができる。

【0506】

ＰＲＡＣＨシーケンス（ｓｅｑｕｅｎｃｅ）は、少なくとも１つの新しい候補ビーム（ｃａｎｄｉｄａｔｅ ｂｅａｍ）にマッピングされる。

【0507】

端末は、Ｌ１－ＲＳＲＰがＲＲＣと設定された臨界値（ｔｈｒｅｓｈｏｌｄ）以上である候補ビーム（ｃａｎｄｉｄａｔｅ ｂｅａｍ）の間で新しいビームを選択し、前記選択されたビームを介してＰＲＡＣＨを送信する。ここで、端末がどのビームを選択するかは端末実現イシューであり得る。

【0508】

次に、Ｓ１５３０及びＳ１５３０ステップ、すなわち、ＢＦＲＱ送信及びＢＦＲＱに対する応答のモニタリングについて説明する。

【0509】

端末は、ウィンドウ（Ｗｉｎｄｏｗ）の時間持続区間（ｔｉｍｅ ｄｕｒａｔｉｏｎ）及びＢＦＲＱに対する基地局の応答をモニターするために、ＲＲＣにより専用（ｄｅｄｉｃａｔｅｄ）ＣＯＲＥＳＥＴが設定されることができる。

【0510】

端末は、ＰＲＡＣＨ送信の４スロット後にモニタリングを開始する。

【0511】

端末は、専用ＣＯＲＥＳＥＴがビーム失態復旧要求(ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ)においてＵＥ－識別された候補ビーム（ｃａｎｄｉｄａｔｅ ｂｅａｍ）のＤＬ ＲＳと空間（ｓｐａｔｉａｌ）ＱＣＬされていると仮定する。

【0512】

もし、タイマーが満了するか又はＰＲＡＣＨ送信の個数が最大個数に到達すると、端末はＢＦＲ手続を中断する。

【0513】

ここで、ＰＲＡＣＨ送信の最大個数とタイマーはＲＲＣに設定される。

【0514】

以下、ＳＳＢ（ＳＳ ｂｌｏｃｋ）指示（ｉｎｄｉｃａｔｉｏｎ）及びビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）について説明する。

【0515】

少なくともサービングセル（ｓｅｒｖｉｎｇ ｃｅｌｌ）に対するレートマッチング（ｒａｔｅ ｍａｔｃｈｉｎｇ）目的のために、６ＧＨｚ以下に対して、全体ビットマップ（８ｂｉｔｓ）は実際ＳＳ／ＰＢＣＨブロック送信の指示（ｉｎｄｉｃａｔｉｏｎ）のために使用される。

【0516】

全体ビットマップを有するＵＥ－特定（ｓｐｅｃｉｆｉｃ）ＲＲＣシグナリングは、６ＧＨｚ以下（ｓｕｂ－６ＧＨｚ）のケース及び６ＧＨｚ以上（ｏｖｅｒ－６ＧＨｚ）のケースの全てに対して実際に送信されたＳＳブロックを指示するために使用される。

【0517】

実際に送信されたＳＳブロックは６ＧＨｚ以下（ｓｕｂ－６ＧＨｚ）のケース及び６ＧＨｚ以上（ｏｖｅｒ－６ＧＨｚ）のケースの全てに対してＲＭＳＩ（ｒｅｍａｉｎｉｎｇ ｍｉｎｉｍｕｍ ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ）において指示（ｉｎｄｉｃａｔｉｏｎ）される。

【0518】

前記指示は、６ＧＨｚ以上で圧縮された形態であり、指示方法は以下の代案から選択される。

【0519】

（代案１）：グループ－ビットマップ（Ｇｒｏｕｐ－Ｂｉｔｍａｐ）及びグループ内のビットマップ

【0520】

グループは、連続的なＳＳ／ＰＢＣＨブロックで定義される。

【0521】

グループ内のビットマップは、どのようばＳＳ／ＰＢＣＨブロックがグループ内において実際に送信されるかを指示することができ、各グループはＳＳ／ＰＢＣＨブロックの同一の送信パターンを有し、グループ－ビットマップはどのようなグループが実際に送信されるかを指示することができる。

【0522】

例えば、グループ別８個のグループと８個のＳＳ／ＰＢＣＨブロックの場合、［８］＋［８］ビット。

【0523】

（対案２）：グループ－ビットマップ及びグループにおいて実際に送信されるＳＳ／ＰＢＣＨブロックの数（ＳＳ／ＰＢＣＨブロックの固定された開始インデックス）

【0524】

グループは、連続するＳＳ／ＰＢＣＨブロックで定義される。

【0525】

グループ－ビットマップ（ｇｒｏｕｐ－ｂｉｔｍａｐ）は、どのグループが実際に送信されるか、グループ内のＳＳ／ＰＢＣＨブロックが論理的に連続するかを指示し、実際に送信されるＳＳ／ＰＢＣＨブロックの数はどれだけ多くの論理的に連続するＳＳ／ＰＢＣＨブロックが第１インデックス（ｆｉｒｓｔ ｉｎｄｅｘ）から開始して実際に送信されるかを指示し、該当個数は送信される全てのグループに共通に適用される。

【0526】

例えば、グループ別の８つのグループ及び８つのＳＳ／ＰＢＣＨブロックの場合、［８］＋［３］ビット。

【0527】

（対案３）：グループ内のビットマップ及び実際に送信されるグループの数（グループの固定された開始インデックス）

【0528】

グループは、連続するＳＳ／ＰＢＣＨブロックで定義される。

【0529】

グループ内のビットマップは、当該グループ内においてどのＳＳ／ＰＢＣＨブロックが実際に送信されるかを示し、各グループは、ＳＳ／ＰＢＣＨブロック送信の同一のパターンを有し、実際に送信されたグループの数はどれだけ多くの連続するグループが第１グループから開始して実際に送信されるかを指示する。

【0530】

例えば、グループ別の８つのグループ及び８つのＳＳ／ＰＢＣＨブロックの場合、［８］＋［３］ビット。

【0531】

（対案４）：グループ－ビットマップ及び各グループにおいて実際に送信されたＳＳ／ＰＢＣＨブロックの数

【0532】

グループは、連続するＳＳ／ＰＢＣＨブロックで定義される。

【0533】

グループ－ビットマップは、どのグループが実際に送信されるかを、グループ内のＳＳ／ＰＢＣＨブロックが論理的に連続するかを指示することができ、各グループに対して実際に送信されるＳＳ／ＰＢＣＨブロックの数は、どれだけ多くの論理的に連続するＳＳ／ＰＢＣＨブロックが第１インデックス（ｆｉｒｓｔ ｉｎｄｅｘ）から開始して実際に送信されるかを指示する。

【0534】

グループ別の８つのグループ及び８つのＳＳ／ＰＢＣＨブロックの場合、最小［８］＋［３］ビット、最大［８］＋［３］＊［８］ビット。

【0535】

（対案５）：実際に送信されるＳＳ／ＰＢＣＨブロックの数、開始インデックス（Ｓｔａｒｔｉｎｇ ｉｎｄｅｘ）及び２つの連続するＳＳ／ＰＢＣＨブロック間の間隔（ｇａｐ）は［６］＋［６］＋［６］ビット。

【0536】

（対案６）：グループビットマップ（ｇｒｏｕｐ－ｂｉｔｍａｐ）

【0537】

グループは、連続するＳＳ／ＰＢＣＨブロックで定義される。

【0538】

グループ－ビットマップは、どのグループが実際に送信されるか、送信されるグループ内の全てのＳＳ／ＰＢＣＨブロックが実際に送信されるかを指示することができる。

【0539】

例えば、グループ別の８つのグループ及び８つのＳＳ／ＰＢＣＨブロックの場合、［８］ビット。

【0540】

指示されるリソースは、実際に送信されるＳＳブロックのために予約される。

【0541】

データチャネル（Ｄａｔａ ｃｈａｎｎｅｌ）は実際に送信されるＳＳブロックの周辺においてレートマッチングされる（ｒａｔｅ－ｍａｔｃｈｅｄ）。

【0542】

次に、ビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）に関連した内容について説明する。

【0543】

ビーム失敗（ｂｅａｍ ｆａｉｌｕｒｅ）は、全てのサービング（ｓｅｒｖｉｎｇ）制御チャネルが失敗するときにのみ宣言（ｄｅｃｌａｒｅ）される。

【0544】

周期的（ｐｅｒｉｏｄｉｃ）ＣＳＩ－ＲＳ以外にも、サービングセル内のＳＳブロックは新しい候補ビーム識別（ｎｅｗ ｃａｎｄｉｄａｔｅ ｂｅａｍ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のために使用できる。

【0545】

次のオプションは、新しい候補ビーム識別（ｎｅｗ ｃａｎｄｉｄａｔｅ ｂｅａｍ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のために設定（ｃｏｎｆｉｇｕｒｅ）されることができる。

【0546】

－ＣＳＩ－ＲＳリソースのみ（ＣＳＩ－ＲＳ ｒｅｓｏｕｒｃｅｓ ｏｎｌｙ）

【0547】

この場合、ＳＳＢは新しい候補ビームの識別のために設定されない。

【0548】

－ＳＳブロックリソースのみ（ＳＳ ｂｌｏｃｋ ｒｅｓｏｕｒｃｅｓ ｏｎｌｙ）

【0549】

この場合、ＣＳＩ－ＲＳは新しい候補ビーム識別のために設定されない。

【0550】

－ＳＳブロックリソースとＣＳＩ－ＲＳリソースの両方（Ｂｏｔｈ ＳＳ ｂｌｏｃｋ ｒｅｓｏｕｒｃｅｓ ａｎｄ ＣＳＩ－ＲＳ ｒｅｓｏｕｒｃｅｓ）

【0551】

競合フリー（ｃｏｎｔｅｎｔｉｏｎ－ｆｒｅｅ）のＰＲＡＣＨ（ｐｈｙｓｉｃａｌ ｒａｎｄｏｍ ａｃｃｅｓｓ ｃｈａｎｎｅｌ）上でビーム失敗復旧要求送信（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ ｔｒａｎｓｍｉｓｓｉｏｎ）に対して、他のＰＲＡＣＨリソースとＣＤＭ（ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ）されるか、ＦＤＭ（ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ）される別途のＰＲＡＣＨリソースを用いることがサポートされる。すなわち、基地局は、ＢＦＲの目的で別途の競合フリーのＰＲＡＣＨリソースを設定することができ、端末が該当ＰＲＡＣＨリソースを送信して基地局がこれを受信した場合、該当端末がビーム失敗の状態であることを暗示的に把握することができる。

【0552】

ここで、ＣＤＭはＰＲＡＣＨプリアンブル（ｐｒｅａｍｂｌｅ）と同一のシーケンス設計を意味する。

【0553】

ビーム失敗復旧要求送信のためのＰＲＡＣＨプリアンブルは、Ｒｅｌ－１５の競合フリー（ｃｏｎｔｅｎｔｉｏｎ－ｆｒｅｅ）のＰＲＡＣＨ動作のためのプリアンブルから選択される。

【0554】

次に、ビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）のためのＳＳブロックの用途（ｕｓａｇｅ）及び設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）について説明する。

【0555】

以下で使用される「ＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）」は同期信号（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｓｉｇｎａｌ：ＳＳ）、ＳＳブロック、物理チャネル（ｐｈｙｓｉｃａｌ ｃｈａｎｎｅｌ）などの無線信号を意味し得る。

【0556】

また、本明細書において使用される「設定」は、「指示」又は「指定」と同一の意味として解釈されることができる。

【0557】

また、本明細書において使用されるＳＳブロック（ｂｌｏｃｋ）は、ＳＳ／ＰＢＣＨブロック（ｂｌｏｃｋ）、ＳＳＢと同一の意味として解釈されることができる。

【0558】

新しい候補ビームを識別するためにＣＳＩ－ＲＳだけでなくＳＳブロック（ｂｌｏｃｋ）が使用されることができる。

【0559】

ＤＬ ＲＳ設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）の観点から、ＵＥが新しい候補ビーム、すなわち、現在サービングＤＬＲＳより良い品質のビームを見つけるために検索するＤＬ ＲＳは、ネットワークにより明示的に設定（ｃｏｎｆｉｇｕｒｅ）されることができる。

【0560】

あるＤＬ ＲＳ品質がビーム対応（ｂｅａｍ ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ）を有するＵＥに対して特にさらに良い時、また他の必要なＤＬ ＲＳ設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）は、どのＵＬリソースが使用できるかを指示するものである。あるいは、送信ビームと受信ビーム間の対応がよく一致しない端末であっても（非ビーム対応ＵＥ（ｎｏｎ－ｂｅａｍ ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ ＵＥ））、前述したアップリンクビームマネジメント過程により端末がどのようなアップリンクビームを使用したとき、基地局がどのような受信ビームが最適であるかを予め把握することができる。

【0561】

従って、特定のダウンリンクビームが優れている場合又は悪い場合、どのようなアップリンクビームを使用してＰＲＡＣＨを送信するかに対して基地局と端末との約束のみすれば、基地局が当該ＰＲＡＣＨに対する受信及び当該ＰＲＡＣＨ受信時に当該端末のどのようなダウンリンクビームが優れているか又は悪いかを把握するのに問題はない。

【0562】

ビーム失敗の場合、ＵＥは多数のＢＦＲ（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ ｒｅｓｏｕｒｃｅ）が設定されることができる。

【0563】

ここで、前記ＢＦＲは、ビーム失敗復旧要求に使用されるためにＰＲＡＣＨとＦＤＭ、ＣＤＭ又はＴＤＭされたＵＬリソースをいう。

【0564】

ビーム対応（ｂｅａｍ ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ）を有するＵＥに対して、それぞれのＢＦＲはＰＲＡＣＨと類似してＤＬビーム（ら）と関連（ａｓｓｏｃｉａｔｉｏｎ）し得る。

【0565】

その理由は、ＰＲＡＣＨリソースはＳＳブロック又はＣＳＩ－ＲＳと関連し得るためである。

【0566】

また、前述したように、非ビーム対応ＵＥ（ｎｏｎ－ｂｅａｍ ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ ＵＥ）に対してもそれぞれのＢＦＲはＤＬビーム（ら）に関連し得る。

【0567】

それぞれのＢＦＲとＳＳブロック又はＣＳＩ－ＲＳの関連（ａｓｓｏｃｉａｔｉｏｎ）に対するＲＲＣ設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）をサポートすることは非常に自然である。

【0568】

結局、ビーム復旧のために、以下のような２つのＤＬ ＲＳ設定が必要であり得る。

【0569】

ＤＬ ＲＳセット設定１．サービングビームが失敗した場合、端末が見つける新しい候補ＤＬ ＲＳビームリスト

【0570】

ＤＬ ＲＳセット設定２．特定候補ＤＬ ＲＳビームが良いとき、どのようなＢＦＲを使うかに対するリスト（各ＢＦＲに関連したＤＬ ＲＳリソース情報）

【0571】

本明細書において提案するビーム失敗復旧方法について説明する前に、ビーム失敗復旧に関連する内容についてまず簡単にまとめる。

【0572】

本明細書において記述される「新しいビーム識別のためのＣＳＩ－ＲＳ＋ＳＳＢ」の表現は、新しいビーム識別のためにＣＳＩ－ＲＳとＳＳＢが両方とも使われる場合を意味し得る。

【0573】

（１）新しい候補ビーム識別のためにＲＳリソースを設定するためのＲＲＣパラメータがサポートされる。

【0574】

ビーム失敗検出（ｂｅａｍ ｆａｉｌｕｒｅ ｄｅｔｅｃｔｉｏｎ）は仮想（ｈｙｐｏｔｈｅｔｉｃａｌ）ＰＤＣＣＨ ＢＬＥＲの品質測定（ｑｕａｌｉｔｙ ｍｅａｓｕｒｅ）に基づいて決定される。

【0575】

（２）Ｂｅａｍ－ｆａｉｌｕｒｅ－ｒｅｃｏｖｅｒｙ－ｒｅｑｕｅｓｔ－ＲＡＣＨ－Ｒｅｓｏｕｒｃｅパラメータがサポートされる。

【0576】

ビーム失敗復旧のための専用（ｄｅｄｉｃａｔｅｄ）ＰＲＡＣＨリソースに対するパラメータは以下の通りである。

【0577】

－プリアンブルシーケンス関連パラメータ、例えば、ルートシーケンス（ｒｏｏｔ ｓｅｑｕｅｎｃｅ）、循環シフト（ｃｙｃｌｉｃ ｓｈｉｆｔ）、及びプリアンブルインデックス（ｐｒｅａｍｂｌｅ ｉｎｄｅｘ）。

【0578】

－最大送信回数

【0579】

－最大パワーランピング（ｐｏｗｅｒ ｒａｍｐｉｎｇ）回数

【0580】

－目標受信電力

【0581】

－再送信のためのタイマー

【0582】

－再送信Ｔｘ電力ランピング段階サイズ

【0583】

－ビーム失敗復旧タイマー

【0584】

連続して検出されるビーム失敗インスタンス（ｂｅａｍ ｆａｉｌｕｒｅ ｉｎｓｔａｎｃｅ）の数が設定された最大数を超過する場合、ビーム復旧要求は送信される。

【0585】

もし、仮想のＰＤＣＣＨ ＢＬＥＲが臨界値以上であると、ビーム失敗インスタンスとしてカウントされる。

【0586】

参考として、ビーム失敗は全てのサービングビームが失敗するときに決定される。

【0587】

候補ビーム（ｃａｎｄｉｄａｔｅ ｂｅａｍ）のメトリックＸが臨界値より高い場合、候補ビームは識別される。

【0588】

前記臨界値は１つ又は２つであり、もし、臨界値が２つである場合、１つはＳＳＢのためのものであり、他の１つはＣＳＩ－ＲＳのためのものである。

【0589】

（３）新しい候補ビーム識別のためにＣＳＩ－ＲＳ＋ＳＳブロックケースがサポートされる。

【0590】

前記ケースはｇＮＢにより設定される。

【0591】

専用（Ｄｅｄｉｃａｔｅｄ）ＰＲＡＣＨリソースはＳＳＢ又はＣＳＩ－ＲＳリソースとして設定される。

【0592】

ＵＥがＣＳＩ－ＲＳ＋ＳＳＢとして新しい候補ビーム識別のために設定されるとき、次の２つのシナリオがサポートされる。

【0593】

－シナリオ１：ＰＲＡＣＨはＳＳＢにのみ連結される

【0594】

シナリオ１は、新しいビーム識別のためのＣＳＩ－ＲＳリソースがＳＳＢとＱＣＬ連結から発見できる。

【0595】

－シナリオ２：多数のＰＲＡＣＨのそれぞれはＳＳＢ又はＣＳＩ－ＲＳリソースと関連する。

【0596】

（４）ｇＮＢがＵＥのビーム失敗復旧要求送信においてＵＥ ＩＤを固有に識別するために、ＰＲＡＣＨシーケンスはＵＥに設定される。

【0597】

（５）ｇＮＢ応答はＣ－ＲＮＴＩに向かう（ａｄｄｒｅｓｓｅｄ）ＰＤＣＣＨを介して送信される。

【0598】

ｇＮＢ応答のためのＤＣＩフォーマットは追って決定されてもよい。

【0599】

ＢＦＲＱに対するｇＮＢ応答をモニターするために専用ＣＯＲＥＳＥＴが適用される。

【0600】

前記専用ＣＯＲＥＳＥＴは、以下の２つの対案から選択される。

【0601】

－代案１（Ａｌｔ１）：以前のビーム失敗と同一のＣＯＲＥＳＥＴ（ら）。

【0602】

－代案２（Ａｌｔ２）：ビームエラー復旧のために専用に（ｄｅｄｉｃａｔｅｄｌｙ）設定されたＣＯＲＥＳＥＴ。

【0603】

（６）ビーム失敗復旧要求に対するｇＮＢ応答をモニターするために、ＵＥが時間ウインドウ及び専用（ｄｅｄｉｃａｔｅｄ）ＣＯＲＥＳＥＴに対する時間持続区間（ｔｉｍｅ ｄｕｒａｔｉｏｎ）のＲＲＣ設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）をサポートする。

【0604】

ＵＥは、専用（ｄｅｄｉｃａｔｅｄ）ＣＯＲＥＳＥＴがビーム失敗復旧要求においてＵＥ－専用候補ビームのＤＬ ＲＳと空間的にＱＣＬされたと仮定する。

【0605】

以下、本明細書で提案するビーム失敗復旧手続の各ステップについてより具体的に説明する。

【0606】

第１に、新しいビーム識別のための過程について説明する。

【0607】

メトリック（Ｍｅｔｒｉｃ）Ｘに対して、サービングビームの失敗が仮想（ｈｙｐｏｔｈｅｔｉｃａｌ）ＢＬＥＲ（Ｂｌｏｃｋ Ｅｒｒｏｒ Ｒａｔｅ）により決定されるとしても、Ｌ１－ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）の利用が（新しいビーム識別のために）仮想（ｈｙｐｏｔｈｅｔｉｃａｌ）のＢＬＥＲより有用であり得る。

【0608】

ここで、前記ｍｅｔｒｉｃ Ｘは、前述したように候補ビーム識別のために臨界値（ｔｈｒｅｓｈｏｌｄ）と比較される値である。

【0609】

まず、端末（ＵＥ）が新しい候補ビーム（ｎｅｗ ｃａｎｄｉｄａｔｅ ｂｅａｍ）の品質を報告するように要求されたとき、前記Ｌ１－ＲＳＲＰは当該ビーム報告媒介変数（ｂｅａｍ ｒｅｐｏｒｔｉｎｇ ｐａｒａｍｅｔｅｒ）と一致し得る。

【0610】

第２に、ＢＬＥＲ臨界値は、ネットワークにより悲観的（ｐｅｓｓｉｍｉｓｔｉｃ）方式で設定できるので、新しいビーム識別のために他のメトリック（ｍｅｔｒｉｃ）を使用することは大きな問題とならない。ビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）はリンク失敗（ｌｉｎｋ ｆａｉｌｕｒｅ）となる可能性を減らすための手続に該当する。端末（ＵＥ）がＬ１－ＲＳＲＰ臨界値を満たすある新しい候補ビームを発見できない場合（又は、検出できない場合）、端末（ＵＥ）は、リンク復旧（ｌｉｎｋ ｒｅｃｏｖｅｒｙ）を行うことができる。最後に、端末（ＵＥ）側においてＢＬＥＲの演算負担はＬ１－ＲＳＲＰより非常に高くなり得る。端末（ＵＥ）が数十又は数百のＢＬＥＲを計算する必要がある場合、これは端末（ＵＥ）の実現の観点から非常に重要な影響を及ぼす。

【0611】

従って、前記事項に基づいて新しいビーム識別に対する以下の５つの提案を定義する。

【0612】

（提案１）

【0613】

提案１は、Ｌ１－ＲＳＲＰを新しい候補ビーム識別のためのＭｅｔｒｉｃ（例えば、ｍｅｔｒｉｃ Ｘ）として使用することである。

【0614】

Ｍｅｔｒｉｃ Ｘに対する臨界値の設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）について、ｇＮＢの設定可能性（ｃｏｎｆｉｇｕｒａｂｉｌｉｔｙ）がネットワークがＰＲＡＣＨと類似してセル配置（ｃｅｌｌ ｄｅｐｌｏｙｍｅｎｔ）環境に依存する他の臨界値（ら）を設定するように要求される。

【0615】

（提案２）

【0616】

提案２は、新しいビーム識別（すなわち、ｍｅｔｒｉｃ Ｘ）のための臨界値の基地局設定の可能性をサポートすることである。２つの臨界値が新しいビーム識別のためのＣＳＩ－ＲＳ＋ＳＳＢのケースのためにサポートされる。

【0617】

以下のシナリオ１及び２は新しいビーム識別のためのＣＳＩ－ＲＳ＋ＳＳＢケースの一例である。

【0618】

シナリオ１：ＰＲＡＣＨｓはもっぱらＳＳＢと関連（ａｓｓｏｃｉａｔｉｏｎ）される。シナリオ１において、新しいビーム識別のためのＣＳＩ－ＲＳリソースはＳＳＢ（ｓ）とＱＣＬ連関から見つけることができる。

【0619】

シナリオ２：多数のＰＲＡＣＨのそれぞれはＳＳＢ又はＣＳＩ－ＲＳリソースと関連する。

【0620】

前述した２つのシナリオを比較すると、シナリオ２が基地局（ｇＮＢ）／端末（ＵＥ）の動作の側面においてさらに簡単である。しかしながら、シナリオ１は必要なＰＲＡＣＨリソースを大きく節約することができる。

【0621】

図１６は、本明細書で提案する方法に適用できるＣＳＩ－ＲＳ及びＳＳブロックの空間カバレッジ（ｓｐａｔｉａｌ ｃｏｖｅｒａｇｅ）の一例を示した図である。

【0622】

図１６に示すように、ＣＳＩ－ＲＳリソースの空間カバレッジ（又は、ビーム－幅）１６２０がＳＳＢの空間カバレッジ１６１０より狭いとき、ＰＲＡＣＨリソースに対する節約（ｓａｖｉｎｇ）効果はさらに大きくなる。

【0623】

図１６において６つのＣＳＩ－ＲＳリソースはＳＳＢ＃１とＱＣＬｅｄされていることが分かる。ＣＳＩ－ＲＳリソースのうち１つはサービングビーム（すなわち、ＰＤＣＣＨと空間的にＱＣＬされる）として役割を果たすと仮定する。

【0624】

ここで、シナリオ１が適用される場合は、単に４つのＰＲＡＣＨリソースが設定される必要があるが（すなわち、１つのＳＳＢに対して１つのＰＲＡＣＨ）、シナリオ２の場合、１０個のＰＲＡＣＨリソースが設定される必要がある。図１６において、基地局は、広いビーム（すなわち、ＳＳＢのビーム幅）を使ってＰＲＡＣＨを受信する反面、端末（ＵＥ）のためのダウンリンク送信に対して、狭いビーム（すなわち、ＣＳＩ－ＲＳのビーム幅）を使用する。

【0625】

端末がＣＳＩ－ＲＳリソースを新しい候補ビームとして発見した場合、端末は、発見されたＣＳＩ－ＲＳリソースとともに空間的にＱＣＬｅｄされているＳＳＢに関連したＰＲＡＣＨリソースを使用してＢＦＲＱを送信することができる。端末は、ＢＦＲＱ（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）に対する基地局の応答により割り当てられたＰＵＳＣＨを使用して新しいビーム（例：ＣＲＩ）に対するより詳細な情報を基地局に送信することができる。

【0626】

（提案３）

【0627】

提案３は、新しいビーム識別のためのＣＳＩ＋ＳＳＢのシナリオ１に対して、

【0628】

－発見された新しいビームがＣＳＩ－ＲＳであると、端末は、前述した臨界条件を満たすＣＳＩ－ＲＳと空間的にＱＣＬｅｄされたＳＳＢに連関するＰＲＡＣＨを介してＢＦＲＱを送信する。

【0629】

－発見された新しいビームがＳＳＢであると、端末は、前述された臨界条件を満たすＳＳＢと関連したＰＲＡＣＨを介してＢＦＲＱを送信する。

【0630】

シナリオ１に対して、基地局（ｇＮＢ）は、ＢＦＲＱが受信されるＰＲＡＣＨと関連したＳＳＢにおいて新しいビームを発見したか又は該当ＳＳＢとＱＣＬｅｄされたＣＳＩ－ＲＳリソースにおいて新しいビームを発見したかに対して曖昧さ（ａｍｂｉｇｕｉｔｙ）が発生し得る。この曖昧さは、ＢＦＲＱを受信した後、割り当てられるかトリガーされたＰＵＳＣＨ／ＰＵＣＣＨで端末に新しいビームに関するより多くの情報を要求することにより解決できる。

【0631】

最初からこの曖昧さを除去するために、基地局（ｇＮＢ）が１つのＳＳＢと関連した最大２つのＰＲＡＣＨリソースを設定するようにすることができる。端末（ＵＥ）は、新しいビームがＱＣＬｅｄされたＣＳＩ－ＲＳリソースから発見される場合、１番目のＰＲＡＣＨリソースを介してＢＦＲＱを送信することができる。端末は、新しいビームがＳＳＢ自体であると、２番目のＰＲＡＣＨリソースを介してＢＦＲＱを送信することができる。このような方式で、基地局（ｇＮＢ）は、端末（ＵＥ）の状況を区別することができる。基地局（ｇＮＢ）が１番目のＰＲＡＣＨを介してＢＦＲＱを受信する場合、基地局（ｇＮＢ）はＣＲＩ及び該当するＬ１－ＲＳＲＰ（すなわち、周期的ビーム報告のみをトリガリング）を受信するためにＰＵＳＣＨを直接割り当てることができる。この場合、基地局（ｇＮＢ）は、端末（ＵＥ）にビームを精製（ｒｅｆｉｎｅ）するためにＣＳＩ－ＲＳリソースを送信する必要がない。基地局（ｇＮＢ）は、２番目のＰＲＡＣＨを介してＢＦＲＱを受信する場合、基地局（ｇＮＢ）は、ＰＵＳＣＨだけでなくＣＳＩ－ＲＳリソースをトリガーする必要がある。図１６の例に前記方法を適用する場合（４ないし５のＰＲＡＣＨリソース）、ただ１つのＰＲＡＣＨリソースのみがさらにＵＥに設定される必要がある。これは、シナリオ２に対して要求されるＰＲＡＣＨリソースの半分にしかならない。

【0632】

（提案４）

【0633】

提案４は、ＣＳＩ－ＲＳ＋ＳＳＢのシナリオ１に対して、１つのＳＳＢと関連したＰＲＡＣＨリソースを最大２つまでサポートすることである。ここで、端末（ＵＥ）が関連したＳＳＢを新しいビームとして発見した場合、１つの（ＰＲＡＣＨ）リソースが使用され、端末が関連したＳＳＢと空間的にＱＣＬｅｄされたＣＳＩ－ＲＳリソースを新しいビームとして発見した場合、他の（ＰＲＡＣＨ）リソースが使用される。

【0634】

新しいビーム識別用途としてＳＳＢとＣＳＩ－ＲＳを両方とも使用する場合、ＳＳＢとＣＳＩ－ＲＳは両方とも予め定められた条件（ｃｏｎｄｉｔｉｏｎ）（例えば、特定臨界値（ｔｈｒｅｓｈｏｌｄ）以上の品質を有すること）を満たすとき、（１）端末はＣＳＩ－ＲＳを優先的に選択して新しいビーム（ＲＳ）としてビーム報告を行うことができる。

【0635】

または、（２）ＳＳＢとＣＳＩ－ＲＳのどちらを優先的に選択して新しいビーム（ＲＳ）として報告を行うかを基地局が（ＲＲＣメッセージ、ＭＡＣメッセージ、ＤＣＩなどを介して）設定することができる。

【0636】

または、（３）端末は、ＳＳＢを優先的に選択して新しいビーム（ＲＳ）として報告を行うことができる。

【0637】

前記（３）、すなわち、ＳＳＢを新しいビームとして優先的に選択する理由は、ＳＳＢがＣＳＩ－ＲＳよりさらに広いビーム幅とカバレッジを有するためである。また、前記（２）、すなわち、基地局の設定により新しいビームが選択される場合は、基地局が（ビーム別のトラフィック、干渉など）状況に応じて（端末別に）優先的に選択するＲＳタイプ（ｔｙｐｅ）を制御することがより良い可能性があるからである。または、前記（２）は、ＲＳタイプ（ｔｙｐｅ）及び／又はどのようなＲＳセットのうち優先的にビームを選択するかを基地局が設定／指定できるからである。

【0638】

ここで、前記ＲＳセットは、ＳＳＢ ＩＤ（ｓ）及び／又はＣＳＩ－ＲＳリソースＩＤ（ｓ）が（混合して）設定されることもできる。

【0639】

追加的に、前記優先（ｐｒｉｏｒｉｔｙ）順位は、ｈｉｇｈ／ｌｏｗの２段階であり、３段階（ｈｉｇｈ／ｍｉｄ／ｌｏｗ）以上でもあり得る。前記優先順位規則（ｐｒｉｏｒｉｔｙ ｒｕｌｅ）に従って選択されたビームは、ビームＩＤ及び品質報告だけでなく、当該ビームと関連したＢＦＲリソースを選択してＢＦＲＱ（ＢＦＲ ｒｅｑｕｅｓｔ）信号を送信するようにすることができる。

【0640】

新しいビーム識別のためのＣＳＩ－ＲＳ＋ＳＳＢケースについて、まず端末（ＵＥ）はＣＳＩ－ＲＳリソース（Ｒｅｓｏｕｒｃｅ）を介して検索を行い、その後、ＣＳＩ－ＲＳが臨界条件を満たさない場合、ＳＳＢを検索する。これは、大部分のシナリオにおいてＣＳＩ－ＲＳのビーム幅がＳＳＢのビーム幅より狭いか等しいためである。これにより、端末（ＵＥ）は、ＣＳＩ－ＲＳリソースのうち新しい候補ビームを発見すると、ＳＳＢより新しいビームとしてＣＳＩ－ＲＳリソースを使用することが良いかもしれない。このような観点から、以下の提案５について説明する。

【0641】

（提案５）

【0642】

提案５は、新しいビーム識別のためのＣＳＩ－ＲＳ＋ＳＳＢに対して、ＣＳＩ－ＲＳとＳＳＢが両方とも臨界条件を満たすと、端末（ＵＥ）がＣＳＩ－ＲＳを選択することである。

【0643】

第２に、ビーム失敗復旧のためのＰＵＣＣＨの使用方法について説明する。

【0644】

ＢＦＲＱを送信するためにＰＵＣＣＨを使用する方法の２つのケースは以下の通りである。

【0645】

－ケース１：ＰＤＣＣＨビームのサブセットが失敗するとき、

【0646】

－ケース２：ビーム失敗が検出されるとき（すなわち、全てのＰＤＣＣＨビームが失敗）

【0647】

ケース１に対して、少なくとも１つのＰＵＣＣＨが各サービングＰＤＣＣＨビームと関連していると仮定すると、ＵＬビームペアリンク（ｂｅａｍ ｐａｉｒ ｌｉｎｋ）のうち１つが依然として生きている可能性があるため、ＰＵＣＣＨリソースは速いビーム失敗復旧要求（ＢＦＲＱ）のために使用できる。ケース１において、端末（ＵＥ）はＰＵＣＣＨのリンク品質が深刻に損なわれるとは予想していないため、ＰＵＣＣＨを介して直接新しいビームに関する相当な量の情報を送ることができる。ＰＵＣＣＨフォーマット２、３及び／又は４は、報告ビームＩＤ及び当該Ｌ１－ＲＳＲＰのために考慮されることができる。

【0648】

ケース２の場合、潜在的にさらに大きな範囲とタイミングエラーにさらに強力なＰＲＡＣＨを使用することがより安全である。しかしながら、ケース２において、ＰＵＣＣＨはＰＲＡＣＨの補完チャネルとして使用してＢＦＲＱを端末（ＵＥ）に送信するのにさらに頻繁な機会を提供することができる。この場合、端末（ＵＥ）はＰＵＣＣＨからの応答がない場合、ＰＲＡＣＨをフォールバック（ｆａｌｌｂａｃｋ）として使用しなければならない。この場合、端末（ＵＥ）はＰＵＣＣＨのリンク品質が低下する可能性があるため、強力なＰＵＣＣＨ形式を使用しなければならない。従って、この場合、ＰＵＣＣＨフォーマット０及び／又は１が適合する。

【0649】

（提案６）

【0650】

提案６の場合、サービング制御チャネルのサブセットが失敗すると、ＰＵＣＣＨはネットワークにイベントの発生を知らせるのに使われる。全てのサービング制御チャネルが失敗する場合（すなわち、ビーム失敗）、ＰＲＡＣＨはビーム失敗復旧を要求する基本（ｂａｓｅｌｉｎｅ）として使用され、ＰＵＣＣＨは追加的に（ｃｏｍｐｌｅｍｅｎｔａｒｙ）使用されることができる。

【0651】

本明細書で提案するまた他の特徴は、ケース１とケース２によってＰＵＣＣＨフォーマットを異なるように設定／使用することである。

【0652】

ケース１、すなわち、複数のＰＤＣＣＨビームが設定された場合、端末が受信する或いはモニターするＰＤＣＣＨ（又は、ＣＯＲＥＳＥＴ又は検索空間（ｓｅａｒｃｈ ｓｐａｃｅ））に設定されたビーム情報（すなわち、空間ＲＸパラメータ（ｓｐａｔｉａｌ ＲＸ ｐａｒａｍｅｔｅｒ）の観点からのＱＣＬされたＲＳ情報）が複数であるとき、一部のＰＤＣＣＨ ＢＬＥＲは特定品質（例えば、Ｑ＿ｏｕｔ）以下であるが、残りのＰＤＣＣＨ ＢＬＥＲは特定品質（例えば、Ｑ＿ｉｎ）以上である場合、特定品質以上であるＰＤＣＣＨと空間（ｓｐａｔｉａｌ）ＱＣＬされたＲＳと（ＤＬ－ＵＬ観点から）関連したＢＦＲがＰＵＣＣＨである場合、該当ＰＵＣＣＨフォーマットは一般的なビーム／ＣＳＩ報告を実行できる（例えば、数十ビット以上のＵＣＩ報告をサポートする）ＰＵＣＣＨフォーマットである２、３及び／又は４などを使用する。

【0653】

そして、全てのＰＤＣＣＨ ＢＬＥＲが特定品質以下である場合、ＢＦＲのうち設定されたＰＵＣＣＨを使用する場合、当該ＰＵＣＣＨはより少ない情報を送るが、より強力な（例えば、低いコーディングレートでエンコードされた）ＰＵＣＣＨフォーマット０及び／又は１を使用する。

【0654】

ＢＦＲＱのために設定されたＰＵＣＣＨリソースは、端末（ＵＥ）がＰＵＣＣＨでＢＦＲＱを送信する必要がある場合、他の目的に設定されたＰＵＣＣＨリソースより優先順位が高くなければならない。

【0655】

（提案７）

【0656】

提案７は、ＢＦＲＱ送信のためのＰＵＣＣＨが他のＰＵＣＣＨより優先順位が高くなければならないということである。

【0657】

次に、ＢＦＲＱに対する基地局応答について説明する。

【0658】

端末（ＵＥ）がＢＦＲＱの基地局（ｇＮＢ）応答をモニターするために、Ｃ－ＲＮＴＩと指定（ｄｅｄｉｃａｔｅｄ）ＣＯＲＥＳＥＴが使用される。非周期的（ａｐｅｒｉｏｄｉｃ）ビーム報告に対するＰＵＳＣＨリソース割り当ては前記ＢＦＲＱに対する基地局応答に含まれるべき必須情報であり得る。また、前記ＢＦＲＱに対する基地局応答に非周期的ＣＳＩ－ＲＳトリガリングメッセージは含まれなければならず、このメッセージは非周期的ビーム報告トリガリングとともにエンコードされることができる。

【0659】

このようなメッセージは、スケジューリングがＤＬ ＤＣＩ形式に基づいたＰＤＳＣＨにおいてＵＬ ＤＣＩ又はＭＡＣ層メッセージ形式で端末（ＵＥ）に送信されることができる。空間基準（ｓｐａｔｉａｌ ｒｅｆｅｒｅｎｃｅ、例えば、ＣＲＩ（ＣＳＩ－ＲＳ ｒｅｓｏｕｒｃｅ ｉｎｄｅｘ）、ＳＲＩ）の明示的シグナリングがない場合、ＰＵＳＣＨ送信のためのＴｘビームはＰＲＡＣＨに使用されるのと同一に設定されることができる。すなわち、ＰＵＳＣＨのための空間基準は、端末（ＵＥ）がＢＦＲＱに対する応答を受信するＰＤＣＣＨにより決定される。

【0660】

（提案８）

【0661】

提案８は、ＰＲＡＣＨがＢＦＲＱを送信するのに使用される場合、ＢＦＲＱに対する応答としてメッセージ／ＤＣＩは少なくとも次のような情報を含むべきである。

【0662】

－ＰＵＳＣＨリソース割り当てに伴う非周期ビーム報告トリガリング

【0663】

－非周期ＣＳＩ－ＲＳトリガリング

【0664】

非周期ＣＳＩ－ＲＳが常にトリガーされないことがある。

【0665】

（提案９）

【0666】

提案９はデフォルトであり、ＢＦＲＱに対する応答に割り当てられたＰＵＳＣＨの空間基準は端末（ＵＥ）がＢＦＲＱに対する応答を受信するＰＤＣＣＨにより決定できるということである。

【0667】

提案９は、ＢＦＲＱに対する応答を受信する用途として設定されたＣＯＲＥＳＥＴにおいて受信するＰＤＣＣＨに対して（ＰＵＳＣＨをスケジューリングする）ＵＬ関連（ｒｅｌａｔｅｄ）ＤＣＩを使用するか、コンパクトフォーマット（ｃｏｍｐａｃｔ ｆｏｒｍａｔ）のＤＬ ＤＣＩを使用するが、ＭＡＣメッセージでＰＵＳＣＨをスケジューリングし、ここで、ＣＳＩ／ビーム報告トリガリングフィールド（ＣＳＩ／ｂｅａｍ ｒｅｐｏｒｔｉｎｇ ｔｒｉｇｇｅｒｉｎｇ ｆｉｅｌｄ）とＣＳＩ－ＲＳトリガリングフィールドが該当ＤＣＩ又はＭＡＣメッセージに含まれる特徴を有する。ここで、前記２つのフィールドはジョイントエンコード（ｊｏｉｎｔ ｅｎｃｏｄｉｎｇ）されて１つのフィールドで構成される。

【0668】

図１７は、本明細書で提案するビーム失敗復旧のための端末の動作方法の一例を示したフローチャートである。

【0669】

まず、端末は、ビーム失敗を検出する（Ｓ１７１０）。

【0670】

次に、端末は、ビーム失敗復旧のための新しいビームを識別する（Ｓ１７２０）。

【0671】

ここで、新しいビームは予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）であり得る。

【0672】

ＲＳは、ＳＳＢ（ＳＳ Ｂｌｏｃｋ）又はＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）リソースであり得る。

【0673】

また、ＣＳＩ－ＲＳリソースは、ＳＳＢと空間的にＱＣＬ（ｑｕａｓｉ－ｃｏｌｏｃａｔｅｄ）されていることがある。

【0674】

ＣＳＩ－ＲＳリソースは、複数のＣＳＩ－ＲＳリソースを含む。

【0675】

前記予め定義された条件は、特定条件で表現されることができ、例えば、設定された（又は、予め定義された）臨界値より高い品質であるか又はＣＳＩ－ＲＳ／ＳＳＢブロックをサポートするよりも優れた品質であり得る。

【0676】

また、前記臨界値は、候補ビーム（識別と関連した）ＲＳがビーム失敗復旧のために使用できるか否かを決定するために使用される値を意味し、基地局により設定される。

【0677】

また、ＳＳＢ（ＳＳ Ｂｌｏｃｋ）及びＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）リソースの全てが予め定義された条件を満たす場合、ＣＳＩ－ＲＳリソースが新しいビームとして識別される。

【0678】

次に、端末は、ビーム失敗復旧要求（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソースを利用して基地局に送信する（Ｓ１７３０）。

【0679】

ＰＲＡＣＨリソースは、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含む。また、第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ Ｂｌｏｃｋ）と関連する。

【0680】

また、ＳＳＢが新しいビームとして識別された場合、ビーム失敗復旧要求は第１ＰＲＡＣＨリソースを使用して送信され、ＣＳＩ－ＲＳリソースが新しいビームとして識別された場合、ビーム失敗復旧要求は第２ＰＲＡＣＨリソースを使用して送信される。

【0681】

図１８は、本明細書で提案するビーム失敗復旧のための基地局の動作方法の一例を示したフローチャートである。

【0682】

まず、基地局は、ビーム失敗復旧（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ）のための新しいビーム識別に関する情報を端末に送信する（Ｓ１８１０）。

【0683】

次に、基地局は、ビーム失敗復旧要求（ｂｅａｍ ｆａｉｌｕｒｅ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ）をＰＲＡＣＨリソースを用いて端末から受信する（Ｓ１８２０）。

【0684】

ここで、ＰＲＡＣＨリソースは第１ＰＲＡＣＨリソース及び第２ＰＲＡＣＨリソースを含む。また、第１ＰＲＡＣＨリソース及び前記第２ＰＲＡＣＨリソースはＳＳＢ（ＳＳ Ｂｌｏｃｋ）と関連する。

【0685】

新しいビームがＳＳＢである場合、ビーム失敗復旧要求は第１ＰＲＡＣＨリソースを使用し、新しいビームがＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）－ＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）リソースである場合、ビーム失敗復旧要求は第２ＰＲＡＣＨリソースを使用する。

【0686】

また、新しいビームは、予め定義された条件を満たす少なくとも１つのＲＳ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）であり得る。

【0687】

ＲＳは、ＳＳＢ又はＣＳＩ－ＲＳリソースであり得る。

【0688】

ＣＳＩ－ＲＳリソースは、複数のＣＳＩ－ＲＳリソースを含む。

【0689】

ＣＳＩ－ＲＳリソースは、ＳＳＢと空間的にＱＣＬ（Ｑｕａｓｉ－ｃｏｌｏｃａｔｅｄ）されていることがある。

【0690】

ここで、ＳＳＢ及びＣＳＩ－ＲＳリソースが全て予め定義された条件を満たす場合、ＣＳＩ－ＲＳリソースが端末により新しいビームとして識別されることができる。

【0691】

図１８と関連した説明において言及された内容以外にも、図１７と同一の内容については図１７を参考とする。

【0692】

本発明が適用できる装置の一般

【0693】

図１９は、本発明の一実施形態に係る無線通信装置のブロック構成図を例示する。

【0694】

図１９に示すように、無線通信システムは、基地局（又は、ネットワーク）１９１０と端末１９２０を含む。

【0695】

基地局１９１０は、プロセッサ（ｐｒｏｃｅｓｓｏｒ）１９１１、メモリ（ｍｅｍｏｒｙ）１９１２及び通信モジュール（ｃｏｍｍｕｎｉｃａｔｉｏｎ ｍｏｄｕｌｅ）１９１３を含む。

【0696】

プロセッサ１９１１は、前記図１ないし図１８で提案された機能、過程及び／又は方法を実現する。有／無線インタフェースプロトコル層はプロセッサ１９１１により実現される。メモリ１９１２は、プロセッサ１９１１と接続されて、プロセッサ１９１１を駆動するための様々な情報を格納する。通信モジュール１９１３は、プロセッサ１９１１と接続されて、有／無線信号を送信及び／又は受信する。

【0697】

前記通信モジュール１９１３は、無線信号を送受信するためのＲＦ部（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ ｕｎｉｔ）を含む。

【0698】

端末１９２０は、プロセッサ１９２１、メモリ１９２２及び通信モジュール（又は、ＲＦ部）１９２３を含む。プロセッサ１９２１は、前記図１ないし図１８で提案された機能、過程及び／又は方法を実現する。無線インタフェースプロトコル層はプロセッサ１９２１により実現される。メモリ１９２２は、プロセッサ１９２１と接続されて、プロセッサ１９２１を駆動するための様々な情報を格納する。通信モジュール１９２３は、プロセッサ１９２１接続されて、無線信号を送信及び／又は受信する。

【0699】

メモリ１９１２、１９２２は、プロセッサ１９１１、１９２１の内部又は外部にあり、広く知られた様々な手段でプロセッサ１９１１、１９２１と接続される。

【0700】

また、基地局１９１０及び／又は端末１９２０は、１つのアンテナ（ｓｉｎｇｌｅ ａｎｔｅｎｎａ）又は多重アンテナ（ｍｕｌｔｉｐｌｅ ａｎｔｅｎｎａ）を有してもよい。

【0701】

図２０は、本発明の一実施形態に係る通信装置のブロック構成図を例示する。

【0702】

特に、図２０は、前記図１９の端末をより詳細に例示する図である。

【0703】

図２０に示すように、端末は、プロセッサ（又は、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）２０１０、ＲＦモジュール（ＲＦ ｍｏｄｕｌｅ）（又は、ＲＦユニット）２０３５、パワー管理モジュール（ｐｏｗｅｒ ｍａｎａｇｅｍｅｎｔ ｍｏｄｕｌｅ）２０１５、アンテナ（ａｎｔｅｎｎａ）２０４０、バッテリ（ｂａｔｔｅｒｙ）２０５５、ディスプレイ（ｄｉｓｐｌａｙ）２０１５、キーパッド（ｋｅｙｐａｄ）２０２０、メモリ（ｍｅｍｏｒｙ）２０３０、ＳＩＭカード(ＳＩＭ(Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｍｏｄｕｌｅ) ｃａｒｄ２０２５（この構成は選択的である）、スピーカ（ｓｐｅａｋｅｒ）２０４５及びマイクロホン（ｍｉｃｒｏｐｈｏｎｅ）２０５０を含んで構成される。端末は、また、単一のアンテナ又は多重のアンテナを含んでもよい。

【0704】

プロセッサ２０１０は、前記図１ないし図１８で提案された機能、過程及び／又は方法を実現する。無線インタフェースプロトコル層はプロセッサにより実現できる。

【0705】

メモリ２０３０は、プロセッサと接続されて、プロセッサの動作に関する情報を格納する。メモリは、プロセッサの内部又は外部にあり、よく知られた様々な手段でプロセッサと接続される。

【0706】

ユーザは、例えば、キーパッド２０２０のボタンを押すか（又は、タッチするか）又はマイクロホン２０５０を利用した音声駆動（ｖｏｉｃｅ ａｃｔｉｖａｔｉｏｎ）により電話番号などのような命令情報を入力する。プロセッサ２０１０は、このような命令情報を受信し、電話番号で電話をかけるなどの適切な機能を果たすように処理する。駆動上のデータ（ｏｐｅｒａｔｉｏｎａｌ ｄａｔａ）はＳＩＭカード２０２５又はメモリ２０３０から抽出できる。また、プロセッサ２０１０は、ユーザの認知又は便宜のために命令情報又は駆動情報をディスプレイ２０１５上に表示する。

【0707】

ＲＦモジュール２０３５は、プロセッサ２０１０に接続されて、ＲＦ信号を送信及び／又は受信する。プロセッサ２０１０は通信を開始するために、例えば、音声通信データを構成する無線信号を送信するように命令情報をＲＦモジュール２０３５に伝達する。ＲＦモジュール２０３５は、無線信号を受信及び送信するために受信機（ｒｅｃｅｉｖｅｒ）及び送信機（ｔｒａｎｓｍｉｔｔｅｒ）から構成される。アンテナ２０４０は、無線信号を送信及び受信する機能を有する。無線信号を受信するとき、ＲＦモジュール２０３５は、プロセッサ２０１０により処理するために信号を伝達し、基底帯域に信号を変換することができる。処理された信号はスピーカ２０４５を介して出力される可聴又は可読情報に変換できる。

【0708】

図２１は、本明細書で提案する方法が適用できる無線通信装置のＲＦモジュールの一例を示した図である。

【0709】

具体的に、図２１は、ＦＤＤ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ）システムにおいて実現できるＲＦモジュールの一例を示す。

【0710】

まず、送信経路において、図１９及び図２０で記述されたプロセッサは、送信されるデータをプロセッシングしてアナログ出力信号を送信機２１１０に提供する。

【0711】

送信機２１１０内において、アナログ出力信号は、デジタル－対－アナログ変換（ＡＤＣ）により発生するイメージを除去するために低域通過フィルタ（Ｌｏｗ Ｐａｓｓ Ｆｉｌｔｅｒ：ＬＰＦ）２１１１によりフィルタリングされ、アップコンバータ（Ｍｉｘｅｒ）２１１２により基底帯域からＲＦにアップコンバートされ、可変利得増幅器（Ｖａｒｉａｂｌｅ Ｇａｉｎ Ａｍｐｌｉｆｉｅｒ：ＶＧＡ）２１１３により増幅され、増幅された信号はフィルタ２１１４によりフィルタリングされ、電力増幅器（Ｐｏｗｅｒ Ａｍｐｌｉｆｉｅｒ：ＰＡ）によりさらに増幅され、デュプレクサ（ら）２１５０／アンテナスイッチ（ら）２１６０を介してルーティングされ、アンテナ２１７０を介して送信される。

【0712】

また、受信経路において、アンテナ２１７０は、外部から信号を受信して受信された信号を提供し、この信号はアンテナスイッチ（ら）２１６０／デュプレクサ２１５０を介してルーティングされ、受信機２１２０に提供される。

【0713】

受信機２１２０内において、受信された信号は低雑音増幅器（Ｌｏｗ Ｎｏｉｓｅ Ａｍｐｌｉｆｉｅｒ：ＬＮＡ）２１２３により増幅され、帯域通過フィルタ２１２４によりフィルタリングされ、ダウンコンバータ（Ｍｉｘｅｒ）２１２５によりＲＦから基底帯域にダウンコンバートされる。

【0714】

前記ダウンコンバートされた信号は、低域通過フィルタ（ＬＰＦ）２１２６によりフィルタリングされ、ＶＧＡ２１２７により増幅されてアナログ入力信号を取得し、これは、図１９及び図２０で記述されたプロセッサに提供される。

【0715】

また、ローカルオシレータ（ｌｏｃａｌ ｏｓｃｉｌｌａｔｏｒ：ＬＯ）発生器２１４０は、送信及び受信ＬＯ信号を発生及びアップコンバータ２１１２及びダウンコンバータ２１２５にそれぞれ提供する。

【0716】

また、位相固定ループ（Ｐｈａｓｅ Ｌｏｃｋｅｄ Ｌｏｏｐ：ＰＬＬ）２１３０は、適切な周波数で送信及び受信ＬＯ信号を生成するためにプロセッサから制御情報を受信し、制御信号をＬＯ発生器２１４０に提供する。

【0717】

また、図２１に示す回路は、図２１に図示された構成と異なるように配列されてもよい。

【0718】

図２２は、本明細書で提案する方法が適用できる無線通信装置のＲＦモジュールのまた他の一例を示した図である。

【0719】

具体的に、図２２は、ＴＤＤ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ）システムにおいて実現できるＲＦモジュールの一例を示す。

【0720】

ＴＤＤシステムにおけるＲＦモジュールの送信機２２１０及び受信機２２２０は、ＦＤＤシステムにおけるＲＦモジュールの送信機及び受信機の構造と同一である。

【0721】

以下、ＴＤＤシステムのＲＦモジュールは、ＦＤＤシステムのＲＦモジュールと異なる構造についてのみ説明し、同一の構造については、図２１の説明を参照する。

【0722】

送信機の電力増幅器（Ｐｏｗｅｒ Ａｍｐｌｉｆｉｅｒ：ＰＡ）２２１５により増幅された信号は、バンド選択スイッチ（Ｂａｎｄ Ｓｅｌｅｃｔ Ｓｗｉｔｃｈ）２２５０、バンド通過フィルタ（ＢＰＦ）２２６０及びアンテナスイッチ（ら）２２７０によりルーティングされ、アンテナ２２８０を介して送信される。

【0723】

また、受信経路において、アンテナ２２８０は、外部から信号を受信して受信された信号を提供し、この信号は、アンテナスイッチ２２７０、バンド通過フィルタ２２６０及びバンド選択スイッチ２２５０によりルーティングされ、受信機２２２０に提供される。

【0724】

以上で説明された実施形態は本発明の構成要素と特徴が所定の形態に結合されたものである。各構成要素または特徴は別途の明示的な言及がない限り、選択的なものとして考慮されなければならない。各構成要素または特徴は他の構成要素や特徴と結合されない形態に実施できる。また、一部の構成要素及び／又は特徴を結合して本発明の実施形態を構成することも可能である。本発明の実施形態で説明される動作の順序は変更できる。ある実施形態の一部の構成や特徴は他の実施形態に含まれることができ、または他の実施形態の対応する構成または特徴と取替できる。特許請求範囲で明示的な引用関係がない請求項を結合して実施形態を構成するか、または出願後の補正により新たな請求項に含めることができることは自明である。

【0725】

本発明による実施形態は、多様な手段、例えば、ハードウェア、ファームウエア（ｆｉｒｍｗａｒｅ）、ソフトウェア、またはそれらの結合などにより実現できる。ハードウェアによる実現の場合、本発明の一実施形態は１つまたはそれ以上のＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ ｄｅｖｉｃｅｓ）、ＰＬＤｓ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙｓ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどにより実現できる。

【0726】

ファームウエアやソフトウェアによる実現の場合、本発明の一実施形態は以上で説明された機能または動作を遂行するモジュール、手続、関数などの形態で実現できる。ソフトウェアコードはメモリに格納されてプロセッサにより駆動できる。前記メモリは前記プロセッサの内部または外部に位置し、既に公知された多様な手段により前記プロセッサとデータをやり取りすることができる。

【0727】

本発明は、本発明の必須的な特徴を逸脱しない範囲で他の特定の形態に具体化できることは通常の技術者に自明である。従って、前述した詳細な説明は全ての面で制限的に解釈されてはならず、例示的なものとして考慮されなければならない。本発明の範囲は添付した請求項の合理的な解釈により決定されなければならず、本発明の等価的な範囲内での全ての変更は本発明の範囲に含まれる。

【産業上の利用可能性】

【0728】

本発明の無線通信システムにおいて、ビーム失敗復旧実行方法は、３ＧＰＰ ＬＴＥ／ＬＴＥ－Ａシステム、５Ｇに適用される例を中心に説明したが、これ以外にも様々な無線通信システムに適用可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10(a)】

【図10(b)】

【図11(a)】

【図11(b)】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】