特許 7349444 ビーム障害処理方法、端末及びネットワーク機器

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

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

(11)【特許番号】

(24)【登録日】2023-09-13

(45)【発行日】2023-09-22

(54)【発明の名称】ビーム障害処理方法、端末及びネットワーク機器

(51)【国際特許分類】

   H04W 16/28 20090101AFI20230914BHJP

   H04B 7/06 20060101ALI20230914BHJP

   H04B 7/08 20060101ALI20230914BHJP

   H04W 24/04 20090101ALI20230914BHJP

   H04W 72/0453 20230101ALI20230914BHJP

   H04W 72/232 20230101ALI20230914BHJP

   H04W 74/08 20090101ALI20230914BHJP

   H04W 88/02 20090101ALI20230914BHJP

【ＦＩ】

H04W16/28

H04B7/06 950

H04B7/08 800

H04W24/04

H04W72/0453

H04W72/232

H04W74/08

H04W88/02 150

【請求項の数】 11

(21)【出願番号】P 2020551541

(86)(22)【出願日】2019-03-11

(65)【公表番号】

(43)【公表日】2021-07-08

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

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

(87)【国際公開日】2019-10-03

【審査請求日】2020-10-14

【審判番号】

【審判請求日】2022-11-14

(31)【優先権主張番号】201810264915.1

(32)【優先日】2018-03-28

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

(73)【特許権者】

【識別番号】517372494

【氏名又は名称】維沃移動通信有限公司

【氏名又は名称原語表記】ＶＩＶＯ ＭＯＢＩＬＥ ＣＯＭＭＵＮＩＣＡＴＩＯＮ ＣＯ．， ＬＴＤ．

【住所又は居所原語表記】Ｎｏ．１， ｖｉｖｏ Ｒｏａｄ， Ｃｈａｎｇ’ａｎ， Ｄｏｎｇｇｕａｎ，Ｇｕａｎｇｄｏｎｇ ５２３８６３， Ｃｈｉｎａ

(74)【代理人】

【識別番号】110001151

【氏名又は名称】あいわ弁理士法人

(72)【発明者】

【氏名】楊 宇

(72)【発明者】

【氏名】孫 鵬

【合議体】

【審判長】齋藤 哲

【審判官】廣川 浩

【審判官】角張 亜希子

(56)【参考文献】

【文献】国際公開第２０１９／１３０５１８（ＷＯ，Ａ１）

【文献】ＣＡＴＴ，“ＢＷＰ ｆｏｒ Ｂｅａｍ Ｆａｉｌｕｒｅ Ｒｅｃｏｖｅｒｙ”，３ＧＰＰ ＴＳＧ－ＲＡＮ ＷＧ２ ＮＲ Ａｄ ｈｏｃ ０１１８ Ｒ２－１８００１６０，［ｏｎｌｉｎｅ］，２０１８年１月１２日アップロード

【文献】ｖｉｖｏ，“Ｒｅｍａｉｎｉｎｇ ｉｓｓｕｅｓ ｏｎ ｍｅｃｈａｎｉｓｍ ｔｏ ｒｅｃｏｖｅｒ ｆｒｏｍ ｂｅａｍ ｆａｉｌｕｒｅ”，３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１ Ｍｅｅｔｉｎｇ ＃９２ Ｒ１－１８０１５２１，［ｏｎｌｉｎｅ］，２０１８年２月１５日アップロード

【文献】ＮＴＴ ＤＯＣＯＭＯ， ＩＮＣ．（Ｒａｐｐｏｒｔｅｕｒ），“ＲＡＮ ＷＧ’ｓ ｐｒｏｇｒｅｓｓ ｏｎ ＮＲ ＷＩ ｉｎ ｔｈｅ Ｎｏｖｅｍｂｅｒ ｍｅｅｔｉｎｇ ２０１７”，３ＧＰＰ ＴＳＧ－ＲＡＮ ＷＧ２ ＮＲ Ａｄ－ｈｏｃ １８０１ Ｒ２－１８００２１７，［ｏｎｌｉｎｅ］，２０１８年１月１２日アップロード

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

H04B7/24- 7/26

H04W4/00-99/00

3GPP TSG RAN WG1-4

SA WG1-4

CT WG1,4

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

【請求項1】

端末側に応用されるビーム障害処理方法において、
アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ビーム障害回復要求をネットワーク機器に送信することと、
前記ビーム障害回復要求に基づいて前記ネットワーク機器からフィードバックされた応答情報を、目標下りＢＷＰにおけるビーム障害回復のための制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで受信することと、を含み、
ここで、前記目標下りＢＷＰは、前記アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰが含まれる少なくとも２つのＢＷＰに対応し、前記少なくとも２つのＢＷＰは、１つの前記ＣＯＲＥＳＥＴ－ＢＦＲに対応し、
前記ビーム障害回復要求に基づいて前記ネットワーク機器からフィードバックされた応答情報を、目標下りＢＷＰにおけるビーム障害回復のための制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで受信することは、
前記目標下りＢＷＰがビーム障害事象の発生した前記アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰと異なる場合、ビーム障害回復要求をネットワーク機器に送信した後、前記目標下りＢＷＰに切り替え、前記ビーム障害回復要求に基づいて前記ネットワーク機器からフィードバックされた応答情報を、前記目標下りＢＷＰにおける制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで受信すること、
を含む、ビーム障害処理方法。

【請求項2】

前記ビーム障害回復要求に基づいて前記ネットワーク機器からフィードバックされた応答情報を、目標下りＢＷＰにおけるビーム障害回復のための制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで受信することは、
前記目標下りＢＷＰがビーム障害事象の発生した前記アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰである場合、前記ビーム障害回復要求に基づいて前記ネットワーク機器からフィードバックされた応答情報を、前記目標下りＢＷＰにおける制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで受信すること、
をさらに含む、請求項１に記載のビーム障害処理方法。

【請求項3】

前記目標下りＢＷＰは、予め定義されたもの、又は、ネットワーク機器がビーム障害回復の設定情報で設定したものである、請求項１又は２に記載のビーム障害処理方法。

【請求項4】

前記設定情報は、
前記制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲが存在する目標下りＢＷＰの第１ＢＷＰ情報と、
ビーム障害検出基準信号ＢＦＤ ＲＳの第１リソース情報と、
候補ビーム基準信号の第２リソース情報と、
ビーム障害回復要求伝送のためのランダムアクセスリソース情報と、
前記制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲを除くＣＯＲＥＳＥＴである他のＣＯＲＥＳＥＴが存在する下りＢＷＰの第２ＢＷＰ情報と、
のうちの少なくとも１つを含む、請求項３に記載のビーム障害処理方法。

【請求項5】

前記第１リソース情報は、
前記ビーム障害検出基準信号ＢＦＤ ＲＳの存在するリソースと前記制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲとの疑似コロケーション関係と、
前記ビーム障害検出基準信号ＢＦＤ ＲＳの存在するリソースと番号が所定値である目標ＣＯＲＥＳＥＴとの疑似コロケーション関係と、
のうちの少なくとも１つを含む、請求項４に記載のビーム障害処理方法。

【請求項6】

前記設定情報に候補ビーム基準信号の第２リソース情報及びランダムアクセスリソース情報が含まれる場合、ビーム障害回復要求を前記ネットワーク機器に送信することは、
前記候補ビーム基準信号の第２リソース情報とランダムアクセスリソース情報との対応関係に基づいて、目標ビームに対応する目標ランダムアクセスリソースを決定することと、
ここで、前記目標ビームは、少なくとも１つの候補ビームのうち、所定条件を満たす１つであり、
ビーム障害回復要求を、前記目標ランダムアクセスリソースで前記ネットワーク機器に送信することと、
を含む、請求項４に記載のビーム障害処理方法。

【請求項7】

アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ビーム障害回復要求をネットワーク機器に送信する第１送信モジュールと、
前記ビーム障害回復要求に基づいて前記ネットワーク機器からフィードバックされた応答情報を、目標下りＢＷＰにおけるビーム障害回復のための制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで受信する第１受信モジュールと、を含み、
ここで、前記目標下りＢＷＰは、前記アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰが含まれる少なくとも２つのＢＷＰに対応し、
前記少なくとも２つのＢＷＰは、１つの前記ＣＯＲＥＳＥＴ－ＢＦＲに対応し、
前記第１受信モジュールは、更に、前記目標下りＢＷＰがビーム障害事象の発生した前記アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰと異なる場合、ビーム障害回復要求をネットワーク機器に送信した後、前記目標下りＢＷＰに切り替え、前記ビーム障害回復要求に基づいて前記ネットワーク機器からフィードバックされた応答情報を、前記目標下りＢＷＰにおける制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで受信することに用いられる、端末。

【請求項8】

前記第１受信モジュールは、更に
前記目標下りＢＷＰがビーム障害事象の発生した前記アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰである場合、前記ビーム障害回復要求に基づいて前記ネットワーク機器からフィードバックされた応答情報を、前記目標下りＢＷＰにおける制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで受信すること、
に用いられる、請求項７に記載の端末。

【請求項9】

前記目標下りＢＷＰは、予め定義されたもの、又は、ネットワーク機器がビーム障害回復の設定情報で設定したものである、請求項７又は８に記載の端末。

【請求項10】

前記設定情報は、
前記制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲが存在する目標下りＢＷＰの第１ＢＷＰ情報と、
ビーム障害検出基準信号ＢＦＤ ＲＳの第１リソース情報と、
候補ビーム基準信号の第２リソース情報と、
ビーム障害回復要求伝送のためのランダムアクセスリソース情報と、
前記制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲを除くＣＯＲＥＳＥＴである他のＣＯＲＥＳＥＴが存在する下りＢＷＰの第２ＢＷＰ情報と、
のうちの少なくとも１つを含む、請求項９に記載の端末。

【請求項11】

前記第１リソース情報は、
前記ビーム障害検出基準信号ＢＦＤ ＲＳの存在するリソースと前記制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲとの疑似コロケーション関係と、
前記ビーム障害検出基準信号ＢＦＤ ＲＳの存在するリソースと番号が所定値である目標ＣＯＲＥＳＥＴとの疑似コロケーション関係と、
のうちの少なくとも１つを含む、請求項１０に記載の端末。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、２０１８年３月２８日に中国特許庁に提出された中国特許出願２０１８１０２６４９１５．１の優先権を主張し、その全ての内容が援用によりここに取り込まれる。
本開示は、通信技術分野に係り、特にビーム障害処理方法、端末及びネットワーク機器に係る。

【背景技術】

【0002】

ＬＴＥ（Ｌｏｎｇ Ｔｉｍｅ Ｅｖｏｌｕｔｉｏｎ）又はＬＴＥ－Ａ（ＬＴＥ－Ａｄｖａｎｃｅｄ）無線アクセス技術は、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）＋ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）技術を用いる。ＭＩＭＯ技術は、アンテナ系を利用して空間自由度を得、ピークレート及びシステムのスペクトル利用率を向上させることができる。

【0003】

将来の５Ｇ（Ｇｅｎｅｒａｔｉｏｎ ）移動通信システム、又はいわゆるＮＲ（Ｎｅｗ Ｒａｄｉｏ）システムでは、サポートする動作周波数帯域は、６ＧＨｚ以上、最高で約１００ＧＨｚまで上げられる。高周波数帯域は、より豊富な空き周波数リソースを有し、より大きなスループットをデータ伝送に提供することができる。ダウンリンク伝送速度２０Ｇｂｐｓ、アップリンク伝送速度１０Ｇｂｐｓの目標を達成するために、高周波アンテナと、より大規模でより多くのアンテナポートとを有するＭＩＭＯ技術が導入される。高周波信号は、波長が短く、低周波数帯域に比べて同じ大きさのパネルに多くのアンテナ素子を設定でき、ビームフォーミング技術を利用して指向性が強く、ローブが狭いビームを形成する。大規模（Ｍａｓｓｉｖｅ）ＭＩＭＯ技術は、大規模なアンテナアレイを使用し、システムの帯域利用効率を格段に向上させ、より多くのアクセスユーザをサポートすることができる。

【0004】

異なる要求のトラフィック及び異なるアプリケーションシーンを満たすために、５Ｇシステムにおいて、ネットワーク機器によってカバーされるセルは、４００ＭＨｚなどの比較的大きい帯域幅をサポートする。端末は、４００ＭＨｚ未満などの比較的小さい動作帯域幅しかサポートできず、その大きい帯域幅内で端末が動作する小さい帯域幅部分は、帯域幅部分ＢＷＰ（Ｂａｎｄｗｉｄｔｈ Ｐａｒｔ）と見なされる。端末は、複数の小さいＢＷＰで動作可能であり、ＢＷＰ毎にそれぞれの数値設定（Ｎｕｍｅｒｏｌｏｇｙ）、帯域幅（ｂａｎｄｗｉｄｔｈ）及び周波数位置（ｆｒｅｑｕｅｎｃｙ ｌｏｃａｔｉｏｎ）が対応付けられる。接続状態にある端末に対して、ネットワーク機器は、データ及び制御のための伝送のために、１つ又は複数のＢＷＰを端末に割り当てるか又はアクティブにすることができる。アクティブ（Ａｃｔｉｖｅ）ＢＷＰの切り替えは、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）、ＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）又はタイマ（ｔｉｍｅｒ）によって実現される。例えば、第１ＣＯＲＥＳＥＴ（Ｃｏｎｔｒｏｌ Ｒｅｓｏｕｒｃｅ Ｓｅｔ）のＤＣＩは、端末が２番目のＣＯＲＥＳＥＴに切り替えることを示す場合、端末が２番目のＣＯＲＥＳＥＴに切り替えると、該ＣＯＲＥＳＥＴがａｃｔｉｖｅ ＢＷＰである。各セルのＢＷＰ毎のＣＯＲＥＳＥＴは、最大で３つであり、ＰＢＣＨ（Ｐｈｙｓｉｃａｌ ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ）で設定されるＣＯＲＥＳＥＴのＩＤは、０である。

【0005】

高周波数帯域の通信システムでは、無線信号の波長が短いため、信号の伝搬が妨げられるなどの事態が生じ易く、信号の伝搬が途切れる。従来技術の無線リンク再構築を採用すると、時間がかかるので、ＢＦＲ（Ｂｅａｍ Ｆａｉｌｕｒｅ Ｒｅｃｏｖｅｒｙ）メカニズムが導入されている。ビーム障害が発生した後に、端末からネットワーク機器側にビーム障害回復要求を送信し、ネットワーク機器が該ビーム障害回復要求を受信すると、ＣＯＲＥＳＥＴ－ＢＦＲ（ＢＦＲのためのＣＯＲＥＳＥＴ）のｄｅｄｉｃａｔｅｄ ＰＤＣＣＨ（ｄｅｄｉｃａｔｅｄ Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）でビーム障害回復要求の応答（ｒｅｓｐｏｎｓｅ）情報を送信し、端末がネットワーク機器によって設定されるＣＯＲＥＳＥＴ－ＢＦＲでｒｅｓｐｏｎｓｅ情報を傍受する。しかし、ネットワーク機器が端末に対し下りＢＷＰを最大４つ設定し、各々のＢＷＰにＣＯＲＥＳＥＴが最大３つであるため、ネットワーク機器が下りＢＷＰ毎にビーム障害回復メカニズムのためにＣＯＲＥＳＥＴ－ＢＦＲを設定すると、正常の通信手順に供されるＣＯＲＥＳＥＴの数が少なくなり、ＣＯＲＥＳＥＴを多く占有するという問題が生じ、正常の通信に使用されるＣＯＲＥＳＥＴが不足する。

【発明の概要】

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

【0006】

本開示の実施例は、ビーム障害によるＣＯＲＥＳＥＴの占有量が多く、正常の通信に使用されるＣＯＲＥＳＥＴリソースが不足するという従来技術の問題点を解決するために、ビーム障害処理方法、端末及びネットワーク機器を提供する。

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

【0007】

第１態様として、本開示の実施例は、ビーム障害処理方法を提供する。
端末側に応用されるビーム障害処理方法において、
アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ビーム障害回復要求をネットワーク機器に送信することと、
ビーム障害回復要求に基づいてネットワーク機器からフィードバックされた応答情報を、目標下りＢＷＰにおけるビーム障害回復のための制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで受信することと、を含み、
ここで、前記目標下りＢＷＰは、ａｃｔｉｖｅ ＢＷＰが含まれる少なくとも２つのＢＷＰに対応する。

【0008】

第２態様として、本開示の実施例は、端末を更に提供する。
当該端末は、
アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ビーム障害回復要求をネットワーク機器に送信する第１送信モジュールと、
ビーム障害回復要求に基づいてネットワーク機器からフィードバックされた応答情報を、目標下りＢＷＰにおけるビーム障害回復のための制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで受信する第１受信モジュールと、を含み、
ここで、前記目標下りＢＷＰは、ａｃｔｉｖｅ ＢＷＰが含まれる少なくとも２つのＢＷＰに対応する。

【0009】

第３態様として、本開示の実施例は、端末を更に提供する。
当該端末において、
プロセッサと、メモリと、メモリに格納されてプロセッサで動作可能なコンピュータプログラムを含み、
コンピュータプログラムがプロセッサによって実行されると、上記のビーム障害処理方法が実現される。

【0010】

第４態様として、本開示の実施例は、ビーム障害処理方法を提供する。
ネットワーク機器側に応用されるビーム障害処理方法において、
アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ビーム障害回復要求を端末側から受信することと、
ビーム障害回復要求に基づいて、目標下りＢＷＰにおけるビーム障害回復のための制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで端末に応答情報を送信することと、を含み、
ここで、前記目標下りＢＷＰは、ａｃｔｉｖｅ ＢＷＰが含まれる少なくとも２つのＢＷＰに対応する。

【0011】

第５態様として、本開示の実施例は、ネットワーク機器を提供する。
当該ネットワーク機器は、
アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ビーム障害回復要求を端末側から受信する第２受信モジュールと、
ビーム障害回復要求に基づいて、目標下りＢＷＰにおけるビーム障害回復のための制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで端末に応答情報を送信する第２送信モジュールと、を含み、
ここで、前記目標下りＢＷＰは、ａｃｔｉｖｅ ＢＷＰが含まれる少なくとも２つのＢＷＰに対応する。

【0012】

第６態様として、本開示の実施例は、ネットワーク機器を更に提供する。
当該ネットワーク機器において、プロセッサと、メモリと、メモリに格納されてプロセッサで動作可能なコンピュータプログラムを含み、
プロセッサがコンピュータプログラムを実行すると、上記のビーム障害処理方法が実現される。

【0013】

第７態様として、本開示の実施例は、コンピュータプログラムが格納されているコンピュータ読み取り可能な記憶媒体を提供し、コンピュータプログラムがプロセッサによって実行されると、上記のビーム障害処理方法が実現される。

【発明の効果】

【0014】

このように、本開示の実施例において、ＣＯＲＥＳＥＴ－ＢＦＲが設定された目標下りＢＷＰの数を端末の下りＢＷＰの設定数よりも少なくすることで、端末のａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ＣＯＲＥＳＥＴ－ＢＦＲが設定された目標下りＢＷＰにより、ビーム障害回復応答情報の受信を行うことができる。これにより、ビーム障害回復手順が正常に行われることを保証すると同時に、正常な通信手順で使用するＣＯＲＥＳＥＴ個の数を多くして、正常な通信に十分な伝送リソースを確保する。

【0015】

本開示の実施例の技術手段をより明確に説明するために、以下、本開示の実施例の記載に必要とされる図面を簡単に紹介する。明らかに、以下の記載に関する図面は、単に本開示の一部の実施例である。当業者にとって、創造性のある作業をしない前提で、これらの図面から他の図面を得ることもできる。

【図面の簡単な説明】

【0016】

【図1】本開示の実施例に係る端末のビーム障害処理方法のフローチャートである。

【図2】本開示の実施例に係る端末のモジュール構造図である。

【図3】本開示の実施例に係る端末のブロック図である。

【図4】本開示の実施例に係るネットワーク機器のビーム障害処理方法のフローチャートである。

【図5】本開示の実施例に係るネットワーク機器のモジュール構造図である。

【図6】本開示の実施例に係るネットワーク機器のブロック図である。

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

【0017】

以下、図面を参照して本開示の例示的な実施例を更に詳細に記載する。本開示の例示的な実施例を図面に示しているが、本開示は、ここで説明した実施例に限定されることなく様々な形態で実現されることが理解されるべきである。これらの実施例を示すことは、本開示をより徹底的に理解してもらい、本開示の範囲を当業者に全面的に伝えるためである。

【0018】

本願の明細書及び特許請求の範囲における「第１」、「第２」などは、類似の対象を区別するために用いられるものであり、特定の順番や前後順序を記載するために用いられるものではない。このように使用されるデータは、ここに記載の本願の実施例が例えばここに図示又は記載のもの以外の順序でも実施可能となるように、適宜に互いに交換可能である。また、「含む」や「有する」及びそれらのあらゆる変形は、非排他的に含むことを意味する。例えば、一連のステップ又はユニットを含むプロセス、方法、システム、製品又は機器は、明確に列挙されているステップ又はユニットに限られず、明確に列挙されていないものや、これらのプロセス、方法、製品又は機器に固有の他のステップ又はユニットを含んでもよい。

【0019】

本開示の実施例は、端末側に応用されるビーム障害処理方法を提供する。図１に示すように、該方法において、以下のステップを含む。

【0020】

ステップ１１において、アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ビーム障害回復要求をネットワーク機器に送信する。

【0021】

高周波数帯域の通信システムでは、無線信号の波長が短いため、信号の伝搬が妨げられるなどの事態が生じ易く、信号の伝搬が途切れる。従来の無線リンク再構築手順を用いる場合、時間がかかるので、以下を含むビーム障害回復メカニズムが導入される。

【0022】

ビーム障害検出：
端末は、物理層でＢＦＤ ＲＳ（Ｂｅａｍ Ｆａｉｌｕｒｅ Ｄｅｔｅｃｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）を測定し、測定結果からビーム障害事象が発生したか否かを判断する。ここで、端末がビーム障害事象の発生を判断する条件は、以下を含む。全てのサービス制御ビーム（ｓｅｒｖｉｎｇ ｃｏｎｔｒｏｌ ｂｅａｍ）のメトリック（ｍｅｔｒｉｃ）が所定の条件を満たし、例えば、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）のＢＬＥＲ（Ｂｌｏｃｋ Ｅｒｒｏｒ Ｒａｔｉｏ）が所定の閾値を超えることを検出した場合に、一回のビーム障害例（ｂｅａｍ ｆａｉｌｕｒｅ ｉｎｓｔａｎｃｅ）と決定する。端末の物理層は、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層のような上位層に指示を報告し、該報告手順が周期的である。それに対応して、端末の物理層がビーム障害例が発生していないと決定した場合、上位層に指示を送信しない。端末の上位層は、物理層から報告される指示をカウンタ（ｃｏｕｎｔｅｒ）でカウントする。ネットワークによって設定された最大回数に達すると、端末は、ビーム障害事象（ｂｅａｍ ｆａｉｌｕｒｅ ｅｖｅｎｔ）が発生したと決定する。

【0023】

好ましくは、ステップ１１の前に、該方法は、ａｃｔｉｖｅ ＢＷＰでＢＦＤ ＲＳを検出し、ビーム障害事象が発生したか否を決定するステップを更に含む。ここで、ビーム障害事象が発生する条件は、該下りａｃｔｉｖｅ ＢＷＰでのｂｅａｍ ｆａｉｌｕｒｅ ｉｎｓｔａｎｃｅの連続回数がネットワーク機器の設定値に達したことである。ｂｅａｍ ｆａｉｌｕｒｅ ｉｎｓｔａｎｃｅとは、全てのｓｅｒｖｉｎｇ ｃｏｎｔｒｏｌ ｂｅａｍのＢＦＤ ＲＳ検出結果が所定の条件を満たすことを意味する。

【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】

本開示の実施例の端末は、ａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ＣＯＲＥＳＥＴ－ＢＦＲが設定された目標下りＢＷＰにより、ビーム障害回復応答情報の受信を行うことで、ビーム障害回復手順が正常に行われることを保証することができる。同時に目標下りＢＷＰの数を端末の下りＢＷＰの設定数よりも少なくすることで、正常な通信手順で使用するＣＯＲＥＳＥＴ個の数を多くして、正常な通信に十分な伝送リソースを確保する。

【0058】

なお、本開示の実施例において、ラジオ周波数ユニット３１は、情報の送受信又は通話中で信号の送受信に用いられ、具体的に、基地局からの下りデータを受信した後、プロセッサ３１０による処理に供し、また、上りデータを基地局に送信する。一般に、ラジオ周波数ユニット３１は、アンテナ、少なくとも１つの増幅器、トランシーバ、結合器、低雑音増幅器、デュプレクサなどを含むが、それらに限定されない。また、ラジオ周波数ユニット３１は、無線通信システムを介してネットワークや他の機器と通信を行うこともできる。

【0059】

端末は、ネットワークモジュール３２を介して、電子メールの送受信、ウェブページの閲覧、ストリーミングメディアへのアクセスを支援するなど、無線ブロードバンドインターネットアクセスをユーザに提供する。

【0060】

音声出力ユニット３３は、ラジオ周波数ユニット３１やネットワークモジュール３２が受信した音声データや、メモリ３９に記憶された音声データを音声信号に変換して音声として出力することができる。また、音声出力ユニット３３は、端末３０が実行する特定の機能に関する音声（例えば、呼出信号着信音、メッセージ着信音等）を出力してもよい。音声出力ユニット３３は、スピーカ、ブザー及びレシーバなどを含む。

【0061】

入力ユニット３４は、音声や映像の信号を受信することに用いられる。入力ユニット３４は、ビデオキャプチャモード又は画像キャプチャモードでカメラなどの画像キャプチャ装置によって取得された静止画又は動画の画像データを処理するグラフィックスプロセッサＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３４１と、マイク３４２とを含む。処理された画像フレームは、表示ユニット３６上に表示される。グラフィックスプロセッサ３４１で処理された画像フレームは、メモリ３９（又は他の記憶媒体）に記憶されるか、又はラジオ周波数ユニット３１又はネットワークモジュール３２を介して送信される。マイク３４２は、音声を受信し、音声データに加工することができる。処理された音声データは、電話通話モードの場合、ラジオ周波数ユニット３１を介して移動体通信基地局に送信可能な形式に変換して出力することができる。

【0062】

端末３０は、光センサ、モーションセンサ及び他のセンサのような少なくとも１つのセンサ３５を更に含む。具体的には、光センサは、周辺光センサ及び近接センサを含む。周辺光センサは、周辺光の明暗に応じて表示パネル３６１の輝度を調節し、近接センサは、端末３０が耳に移動したときに表示パネル３６１やバックライトを消灯する。モーションセンサの１種として、加速度計センサは、様々な方向（一般的には３軸）の加速度の大きさを検出でき、静止時は重力の大きさ及び方向を検出でき、端末姿勢の認識（例えば、縦横画面切替、関連ゲーム、磁力計姿勢キャリブレーション）、振動認識関連機能（たとえば、歩数計、ストローク）などに用いることができる。センサ３５は、指紋センサ、圧力センサ、虹彩センサ、分子センサ、ジャイロスコープ、気圧計、湿度計、温度計、赤外線センサなどを更に含むことができるが、ここでは枚挙しない。

【0063】

表示ユニット３６は、ユーザが入力した情報やユーザに提供した情報を表示するために用いられる。表示ユニット３６は、液晶ディスプレイＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）、有機発光ダイオードＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ－Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）などからなる表示パネル３６１を含んでもよい。

【0064】

ユーザ入力ユニット３７は、数字や文字情報の入力を受け付け、ユーザによる端末の設定や機能制御に関するキー信号の入力を行うことに用いられる。具体的に、ユーザ入力ユニット３７は、タッチスクリーン３７１と、その他の入力機器３７２とを含む。タッチスクリーン３７１は、タッチスクリーンとも呼ばれ、その上又は付近でのユーザのタッチ操作を取得可能である（たとえばユーザが指やスタイラスなどの任意の適切な物体や付属部材を用いたタッチスクリーン３７１の上又はタッチスクリーン３７１の付近での操作）。タッチスクリーン３７１は、タッチ検出装置とタッチコントローラの２つの部分を含む。ここで、タッチ検出装置は、ユーザのタッチ方位を検出し、タッチ操作による信号を検出してタッチコントローラに伝達する。タッチコントローラは、タッチ検出装置からのタッチ情報を受信し、それを接点座標に変換してプロセッサ３１０に送り、プロセッサ３１０からの命令を受信して実行する。なお、タッチスクリーン３７１は、抵抗膜式、静電容量式、赤外線、表面弾性波など、種々の方式を用いて実現することができる。ユーザ入力ユニット３７は、タッチスクリーン３７１の他に、他の入力機器３７２を含んでもよい。具体的に、他の入力機器３７２は、物理的なキーボード、機能キー（例えば、音量調節キー、スイッチキーなど）、トラックボール、マウス、レバーを含むが、ここでは枚挙しない。

【0065】

更に、タッチスクリーン３７１は、表示パネル３６１に重ねられる。タッチスクリーン３７１は、その上又はその近くでタッチ操作を検出すると、プロセッサ３１０に送信して、タッチイベントのタイプを決定する。次いで、プロセッサ３１０は、タッチイベントのタイプに応じて、対応する視覚的出力を表示パネル３６１に提供する。図３では、タッチスクリーン３７１と表示パネル３６１は、独立した２つの部品として端末の入出力機能を実現するが、実施例によっては、タッチスクリーン３７１と表示パネル３６１を一体化して端末の入出力機能を実現することもでき、具体的にここでは限定しない。

【0066】

インタフェースユニット３８は、外部装置と端末３０とを接続するためのインタフェースである。例えば、外部装置は、有線又は無線ヘッドホンポート、外部電源（又はバッテリ充電器）ポート、有線又は無線データポート、メモリカードポート、識別モジュールを有する装置を接続するためのポート、オーディオ入出力（Ｉ／Ｏ）ポート、ビデオＩ／Ｏポート、ヘッドホンポート等を含む。インタフェースユニット３８は、外部装置から入力（たとえば、データ情報、電力など）を受信し、受信した入力を端末３０内の１つ以上の要素に伝送するために使用されてもよく、又は端末３０と外部装置との間でデータを伝送するために使用されてもよい。

【0067】

メモリ３９は、ソフトウェアプログラム及び様々なデータを格納するために使用される。メモリ３９は、オペレーティングシステム、少なくとも１つの機能に必要なアプリケーション（たとえば、音声再生機能、画像再生機能など）などを格納することができるプログラム格納領域と、データ格納領域とを主に含んでもよい。データ格納領域は、音声データや電話帳など、携帯電話機の使用に応じて作成されたデータを記憶することができる。更に、メモリ３９は、高速ランダムアクセスメモリを含んでもよく、少なくとも１つの磁気ディスク記憶装置、フラッシュメモリデバイス、又は他の揮発性固体記憶デバイスなどの不揮発性メモリを含んでもよい。

【0068】

プロセッサ３１０は、端末の制御センタであり、各種インタフェースや回線を用いて端末全体の各部を接続し、メモリ３９に格納されたソフトウェアプログラムやモジュールを実行、メモリ３９に格納されたデータを呼び出して端末の各種機能及び処理データを実行し、端末全体の監視を行う。プロセッサ３１０は、１つ以上の処理ユニットを含んでもよい。選択可能に、プロセッサ３１０は、オペレーティングシステム、ユーザインターフェース及びアプリケーションなどを主に処理するアプリケーションプロセッサと、ワイヤレス通信を主に処理するモデムプロセッサとを統合することができる。上述のモデムプロセッサは、プロセッサ３１０に統合されなくてもよいことが理解される。

【0069】

端末３０は、各構成要素に電力を供給するためのバッテリのような電源３１１を更に含んでもよい。選択可能に、電源３１１は、電源管理システムを介してプロセッサ３１０に論理的に接続されてもよく、電源管理システムを介して充電、放電、及び消費電力管理などを管理する機能を実現してもよい。

【0070】

また、端末３０は、図示しない機能モジュールを更に含んでもよく、ここでの説明は省略する。

【0071】

好ましくは、本開示の実施例は、プロセッサ３１０と、メモリ３９と、メモリ３９に格納されて前記プロセッサ３１０で動作可能なコンピュータプログラムを含む端末を更に提供し、該コンピュータプログラムがプロセッサ３１０によって実行されると、上記ビーム障害処理方法の実施例の各プロセスが実現され、且つ同じ技術効果を奏することもできるので、重複を避けるために、ここでは繰り返して記載しない。ここで、端末は、無線端末であってもよく有線端末であってもよい。無線端末とは、音声や他のサービスデータ接続性をユーザに提供する機器を指し、無線接続機能の携帯式機器、又は、無線モデムに接続される他の処理機器を有する。無線端末は、無線アクセスネットワーク（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ、ＲＡＮと略称される）を介して１つ又は複数のコアネットワークと通信可能である。無線端末は、移動電話（又は「セルラー」電話と称される）などの移動端末、移動端末を有するコンピュータなどである。たとえば、端末は、携帯式、ポータブル式、ハンドヘルド式、コンピュータ内蔵式又は車載の移動装置であり、無線アクセスネットワークとは音声やデータのやり取りを行う。例えば、ＰＣＳ（Ｐｅｒｓｏｎａｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ）電話、コードレス電話、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）電話機、ＷＬＬ（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ｌｏｏｐ）局、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）などの機器である。無線端末は、システム、受信契約ユニット（Ｓｕｂｓｃｒｉｂｅｒ Ｕｎｉｔ）、受信契約局（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、移動局（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、モバイル（Ｍｏｂｉｌｅ）、リモートステーション（Ｒｅｍｏｔｅ Ｓｔａｔｉｏｎ）、リモート端末（Ｒｅｍｏｔｅ Ｔｅｒｍｉｎａｌ）、アクセス端末（Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）、ユーザ端末（Ｕｓｅｒ Ｔｅｒｍｉｎａｌ）、ユーザエージェント（Ｕｓｅｒ Ａｇｅｎｔ）、ユーザ機器（Ｕｓｅｒ Ｄｅｖｉｃｅ ｏｒ Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）と呼ばれてもよいが、ここでは限定されない。

【0072】

本開示の実施例は、コンピュータプログラムが格納されているコンピュータ読み取り可能な記憶媒体を更に提供し、当該コンピュータプログラムがプロセッサによって実行されると、上記ビーム障害処理方法の実施例の各プロセスが実現され、且つ同じ技術効果を奏することもできるので、重複を避けるために、ここでは繰り返して記載しない。ここで、コンピュータ読み取り可能な記憶媒体は、たとえば、リードオンリーメモリＲＯＭ（Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ランダムアクセスメモリＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク又は光ディスクなどなどである。

【0073】

以上の実施例は、端末側から本開示のビーム障害処理方法を紹介したが、以下、本実施例は、更に、ネットワーク機器側のビーム障害処理方法について図面とともに紹介する。

【0074】

図４に示すように、本開示の実施例のネットワーク機器側に応用されるビーム障害処理方法は、以下のステップを含む。

【0075】

ステップ４１において、アクティブ帯域幅部分ａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ビーム障害回復要求を端末側から受信する。

【0076】

端末のａｃｔｉｖｅ ＢＷＰでビーム障害事象が発生した場合、ネットワーク機器は、端末からランダムアクセスリソースで送信されるビーム障害回復要求を受信する。ここで、端末によるビーム障害回復要求の送信方式は、端末側の実施形態を参照する。それに対応し、ネットワーク機器は、対応するリソースで受信する。ゆえに、ここでは繰り返して記載しない。

【0077】

ステップ４２において、ビーム障害回復要求に基づいて、目標下りＢＷＰにおけるビーム障害回復のための制御リソースセットＣＯＲＥＳＥＴ－ＢＦＲで端末に応答情報を送信する。

【0078】

ここで、目標下りＢＷＰは、少なくとも２つのＢＷＰに対応し、少なくとも２つのＢＷＰには、ａｃｔｉｖｅ ＢＷＰが含まれる。すなわち、端末の複数の下りＢＷＰに共通にＣＯＲＥＳＥＴ－ＢＦＲを設定することで、ビーム障害回復手順が正常に行われることを保証し、正常な通信手順に予約されるＣＯＲＥＳＥＴの数が多くなり、正常な通信に十分な送信リソースを保証する。なお、上記ＣＯＲＥＳＥＴ－ＢＦＲは、ビーム障害回復メカニズムに加えて、正常の通信手順にも適用可能である。すなわち、ビーム障害回復メカニズムのために予約されたＣＯＲＥＳＥＴリソースは、正常の通信のＣＯＲＥＳＥＴリソースと同じであっても異なっていてもよい。

【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】

以上記載されたのは、本開示の好適な実施形態である。当業者は、本開示に記載されている原理を逸脱せずに様々な改良や修飾をすることもできる。これらの改良や修飾も、本開示の保護範囲内にある。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】