特表2022-554326 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ 北京小米移動軟件有限公司の特許一覧

特表2022-554326ビーム失敗要求リソース割り当て方法、装置および記憶媒体

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-12-28

(54)【発明の名称】ビーム失敗要求リソース割り当て方法、装置および記憶媒体

(51)【国際特許分類】

H04W 16/28 20090101AFI20221221BHJP

H04W 72/04 20090101ALI20221221BHJP

H04W 24/04 20090101ALI20221221BHJP

H04W 76/18 20180101ALI20221221BHJP

【ＦＩ】

H04W16/28

H04W72/04 111

H04W24/04

H04W76/18

H04W72/04 136

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2022525548

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

(85)【翻訳文提出日】2022-04-28

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

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

(87)【国際公開日】2021-05-14

(81)【指定国・地域】

(71)【出願人】

【識別番号】516180667

【氏名又は名称】北京小米移動軟件有限公司

【氏名又は名称原語表記】ＢｅｉｊｉｎｇＸｉａｏｍｉＭｏｂｉｌｅＳｏｆｔｗａｒｅＣｏ．，Ｌｔｄ．

【住所又は居所原語表記】Ｎｏ．０１８，Ｆｌｏｏｒ８，Ｂｕｉｌｄｉｎｇ６，Ｙａｒｄ３３，ＭｉｄｄｌｅＸｉｅｒｑｉＲｏａｄ，ＨａｉｄｉａｎＤｉｓｔｒｉｃｔ，Ｂｅｉｊｉｎｇ１０００８５，Ｃｈｉｎａ

(74)【代理人】

【識別番号】100114557

【弁理士】

【氏名又は名称】河野英仁

(74)【代理人】

【識別番号】100078868

【弁理士】

【氏名又は名称】河野登夫

(72)【発明者】

【氏名】リ，ミンジュ

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067DD11

5K067DD43

5K067EE02

5K067EE10

5K067KK02

5K067KK03

(57)【要約】

【課題】
【解決手段】本開示は、ビーム失敗要求リソース割り当て方法、装置および記憶媒体に関する。ビーム失敗要求リソース割り当て方法は、複数のビーム失敗要求リソースが構成されている端末に適用され、前記複数のビーム失敗要求リソースは、前記端末に構成されている複数のサービングセルグループ内のサービングセルに構成されている物理アップリンク制御チャンネルビーム失敗要求リソースからなる。前記ビーム失敗要求リソース割り当て方法は、ビーム失敗が発生した第１のセカンダリセルが存在するか否かを検出するステップと、ビーム失敗が発生した第１のセカンダリセルが検出された場合、前記第１のセカンダリセルにビーム失敗要求リソースが構成されているか否かに基づいて、前記複数のビーム失敗要求リソースから１つのビーム失敗要求リソースを前記ビーム失敗要求を送信するリソースとして選択するステップと、を含む。本開示によって複数のビーム失敗要求リソースにおいてビーム失敗要求を送信するリソースを決定することが実現される。

【特許請求の範囲】

【請求項1】

端末に適用されているビーム失敗要求リソース割り当て方法であって、前記端末に複数のビーム失敗要求リソースが構成され、前記複数のビーム失敗要求リソースは、前記端末に構成されている複数のサービングセルグループ内のサービングセルに構成されている物理アップリンク制御チャンネルビーム失敗要求リソースからなり、前記方法は、
ビーム失敗が発生した第１のセカンダリセルが存在するか否かを検出するステップと、
ビーム失敗が発生した第１のセカンダリセルが検出された場合、前記第１のセカンダリセルにビーム失敗要求リソースが構成されているか否かに基づいて、前記複数のビーム失敗要求リソースから１つのビーム失敗要求リソースを、前記ビーム失敗要求を送信するリソースとして選択するステップと、を含む、
ことを特徴とするビーム失敗要求リソース割り当て方法。

【請求項2】

前記第１のセカンダリセルにビーム失敗要求リソースが構成されていない場合、
前記第１のセカンダリセルが属するサービングセルグループ内のサービングセルに構成されているビーム失敗要求リソースを選択することと、
時間的に最初に発生するビーム失敗要求リソースを選択することと、
他のアップリンク情報を伝送する必要がないビーム失敗要求リソースを選択することと、
他のアップリンク情報と多重化可能なビーム失敗要求リソースを選択することとのうちの少なくとも１つの方式を利用して前記複数のビーム失敗要求リソースから１つのビーム失敗要求リソースを選択する、
ことを特徴とする請求項１に記載のビーム失敗要求リソース割り当て方法。

【請求項3】

前記第１のセカンダリセルにビーム失敗要求リソースが構成されている場合、前記第１のセカンダリセルが属するサービングセルグループと異なる他のサービングセルグループ内のサービングセルに構成されているビーム失敗要求リソースを選択する、
ことを特徴とする請求項１に記載のビーム失敗要求リソース割り当て方法。

【請求項4】

前記選択されたビーム失敗要求リソースによって要求された物理アップリンク共有チャンネルリソースを利用してメディアアクセス制御情報ユニットを送信するステップをさらに含み、前記メディアアクセス制御情報ユニットは、前記端末に構成されているサービングセル内のセカンダリセルでビーム失敗が発生したか否かを示すために使用される、
ことを特徴とする請求項１に記載のビーム失敗要求リソース割り当て方法。

【請求項5】

前記複数のビーム失敗要求リソースは、プライマリセルまたはプライマリセカンダリセルに構成されているビーム失敗要求リソース、および第２のセカンダリセルに構成されているビーム失敗要求リソースを含み、
選択されたビーム失敗要求リソースがプライマリセルまたはプライマリセカンダリセルに構成されているビーム失敗要求リソースである場合、
前記メディアアクセス制御情報ユニットは、前記端末に構成されているすべてのサービングセル内のセカンダリセルでビーム失敗が発生したか否かを示すために使用される、
ことを特徴とする請求項４に記載のビーム失敗要求リソース割り当て方法。

【請求項6】

前記複数のビーム失敗要求リソースは、プライマリセルまたはプライマリセカンダリセルに構成されているビーム失敗要求リソース、および第２のセカンダリセルに構成されているビーム失敗要求リソースを含み、
選択されたビーム失敗要求リソースが第２のセカンダリセルに構成されているビーム失敗要求リソースである場合、
前記メディアアクセス制御情報ユニットは、前記第２のセカンダリセルが属するサービングセルグループ内の前記第２のセカンダリセル以外の他のセカンダリセルでビーム失敗が発生したか否かを示すために使用される、
ことを特徴とする請求項４に記載のビーム失敗要求リソース割り当て方法。

【請求項7】

前記第１のセカンダリセルに新たなビームが存在することが決定された場合、前記メディアアクセス制御情報ユニットが、前記新たなビームを示すためにも使用されるステップをさらに含む、
ことを特徴とする請求項４～６のいずれかに記載のビーム失敗要求リソース割り当て方法。

【請求項8】

端末に適用されているビーム失敗要求リソース割り当て装置であって、前記端末に複数のビーム失敗要求リソースが構成され、前記複数のビーム失敗要求リソースは、前記端末に構成されている複数のサービングセルグループ内のサービングセルに構成されている物理アップリンク制御チャンネルビーム失敗要求リソースからなり、前記ビーム失敗要求リソース割り当て装置は、
ビーム失敗が発生した第１のセカンダリセルが存在するか否かを検出するように構成される検出ユニットと、
ビーム失敗が発生した第１のセカンダリセルが検出された場合、前記第１のセカンダリセルにビーム失敗要求リソースが構成されているか否かに基づいて、前記複数のビーム失敗要求リソースから１つのビーム失敗要求リソースを前記ビーム失敗要求を送信するリソースとして選択するように構成される選択ユニットと、を含む、
ことを特徴とするビーム失敗要求リソース割り当て装置。

【請求項9】

前記第１のセカンダリセルがビーム失敗要求リソースが構成されている第２のセカンダリセルでない場合、前記選択ユニットは、
前記第１のセカンダリセルが属するサービングセルグループ内のサービングセルに構成されているビーム失敗要求リソースを選択することと、
時間的に最初に発生するビーム失敗要求リソースを選択することと、
他のアップリンク情報を伝送する必要がないビーム失敗要求リソースを選択することと、
他のアップリンク情報と多重化可能なビーム失敗要求リソースを選択することとのうちの少なくとも１つの方式を利用して前記複数のビーム失敗要求リソースから１つのビーム失敗要求リソースを選択する、
ことを特徴とする請求項８に記載のビーム失敗要求リソース割り当て装置。

【請求項10】

前記第１のセカンダリセルにビーム失敗要求リソースが構成されている場合、前記選択ユニットは、前記第１のセカンダリセルが属するサービングセルグループと異なる他のサービングセルグループ内のサービングセルに構成されているビーム失敗要求リソースを選択する、
ことを特徴とする請求項８に記載のビーム失敗要求リソース割り当て装置。

【請求項11】

プロセッサと、
プロセッサによって実行可能な指令を記憶するためのメモリと、を含み、
ここで、前記プロセッサは、請求項１～７のいずれかに記載のビーム失敗要求リソース割り当て方法を実行するように構成される、
ことを特徴とするビーム失敗要求リソース割り当て装置。

【請求項12】

非一時的なコンピュータ読み取り可能な記憶媒体であって
前記記憶媒体内の指令がモバイル端末のプロセッサによって実行される場合、モバイル端末が請求項１～７のいずれかに記載のビーム失敗要求リソース割り当て方法を実行する、
ことを特徴とする非一時的なコンピュータ読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、通信技術分野に関し、特に、ビーム失敗要求リソース割り当て方法、装置および記憶媒体に関する。

【背景技術】

【0002】

新しい無線技術（ＮｅｗＲａｄｉｏ、ＮＲ）通信システムでは、カバレッジ範囲を確保し、経路損失に耐えるために、通常、ビーム（ｂｅａｍ）に基づいてデータを送受信する必要がある。しかしながら、ＮＲにおいて、制御チャンネルもビームに基づく送受信を使用する必要があるので、端末が移動したり、アンテナの方向が回転したりすると、現在送受信のために端末に構成されているビームに問題が発生する可能性があり、すなわち、ビーム失敗の問題が発生する。

【0003】

関連技術では、端末がセカンダリセル（ＳＣｅｌｌ）のビーム失敗を検出した場合、ネットワーク機器は、ビーム失敗が発生したことを示すＢＦＲをネットワーク機器に送信するために、端末に物理アップリンク制御チャンネル－ビーム失敗要求（ｐｈｙｓｉｃａｌｕｐｌｉｎｋｃｏｎｔｒｏｌｃｈａｎｎｅｌ－ｂｅａｍｆａｉｌｕｒｅｒｅｑｕｅｓｔ、ＰＵＣＣＨ－ＢＦＲ）を送信するリソースを構成する必要がある。現在、端末に対して、ネットワーク機器（例えば、基地局）は、その異なるサービングセルに複数のＰＵＣＣＨ－ＢＦＲリソースを構成する可能性があり、複数のＰＵＣＣＨ－ＢＦＲリソースからＢＦＲを送信するためのＰＵＣＣＨ－ＢＦＲリソースをどのように選択するかは、解決すべき問題である。

【発明の概要】

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

【0004】

関連技術において存在する問題を克服するために、本開示は、ビーム失敗要求リソース割り当て方法、装置および記憶媒体を提供する。

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

【0005】

本開示の実施例の第１の態様によれば、端末に適用されているビーム失敗要求リソース割り当て方法を提供し、前記端末に複数のビーム失敗要求リソースが構成され、前記複数のビーム失敗要求リソースは、前記端末に構成されている複数のサービングセルグループ内のサービングセルに構成されている物理アップリンク制御チャンネルビーム失敗要求リソースからなる。前記ビーム失敗要求リソース割り当て方法は、ビーム失敗が発生した第１のセカンダリセルが存在するか否かを検出するステップと、ビーム失敗が発生した第１のセカンダリセルが検出された場合、前記第１のセカンダリセルにビーム失敗要求リソースが構成されているか否かに基づいて、前記複数のビーム失敗要求リソースから１つのビーム失敗要求リソースを前記ビーム失敗要求を送信するリソースとして選択するステップと、を含む。

【0006】

本開示の実施例の第２の態様によれば、端末に適用されているビーム失敗要求リソース割り当て装置を提供し、前記端末に複数のビーム失敗要求リソースが構成され、前記複数のビーム失敗要求リソースは、前記端末に構成されている複数のサービングセルグループ内のサービングセルに構成されている物理アップリンク制御チャンネルビーム失敗要求リソースからなり、前記ビーム失敗要求リソース割り当て装置は、ビーム失敗が発生した第１のセカンダリセルが存在するか否かを検出するように構成される検出ユニットと、ビーム失敗が発生した第１のセカンダリセルが検出された場合、前記第１のセカンダリセルにビーム失敗要求リソースが構成されているか否かに基づいて、前記複数のビーム失敗要求リソースから１つのビーム失敗要求リソースを前記ビーム失敗要求を送信するリソースとして選択するように構成される選択ユニットと、を含む。

【発明の効果】

【0007】

本開示の実施例に係る技術案は、以下の有益な効果を含むことができる。ビーム失敗が発生したセカンダリセルが検出された場合、セカンダリにビーム失敗要求リソースが構成されているか否かに基づいて、複数のビーム失敗要求リソースから１つのビーム失敗要求リソースを、ビーム失敗要求を送信するためのリソースとして選択し、複数のビーム失敗要求リソースにおいてビーム失敗要求を送信するためのリソースを決定することが実現される。

【0008】

なお、以上の一般的な説明および後述の詳細な説明は、例示的および解釈的なものであり、本開示を限定するためのものではない。

【図面の簡単な説明】

【0009】

ここでの図面は、明細書に組み込まれて本明細書の一部を構成し、本開示に適合する実施例が示され、明細書とともに本開示の原理を説明するために使用される。

【図1】例示的な一実施例に係る無線通信システムの概略図である。

【図2】例示的な一実施例に係るビーム失敗要求リソース構成方法のフローチャートである。

【図3】例示的な一実施例に係るビーム失敗要求リソース構成方法のフローチャートである。

【図4】例示的な一実施例に係るビーム失敗要求リソース構成装置のブロック図である。

【図5】例示的な一実施例に係る装置のブロック図である。

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

【0010】

ここでは、例示的な実施例を詳しく説明し、その例を図面に示す。以下の説明は、図面に関する場合、別段の表示がない限り、異なる図面における同一の数字は、同一または類似の要素を示す。以下の例示的な実施例において説明される実施形態は、本開示と一致するすべての実施形態を表すものではない。むしろ、それらは、添付された特許請求の範囲に詳述された、本開示のいくつかの態様と一致する装置および方法の例に過ぎない。

【0011】

本開示の実施例によって提供されるビーム失敗要求リソース割り当て方法は、図１に示す無線通信システムに適用することができる。図１を参照すると、当該無線通信システムには、ネットワーク機器および端末が含まれている。端末は、無線リソースを介してネットワーク機器に接続され、データを伝送する。

【0012】

なお、図１に示す無線通信システムは、例示的な説明に過ぎず、無線通信システムは、他のネットワーク機器、例えば、コアネットワーク機器、無線中継機器および無線返信機器を含むこともできるが、図１には示されていない。本開示の実施例は、当該無線通信システムに含まれているネットワーク機器の数および端末の数を限定しない。

【0013】

さらに、本開示の実施例の無線通信システムが、無線通信機能を提供するネットワークであることを理解することができる。無線通信システムは、符号分割多元接続（ｃｏｄｅｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ、ＣＤＭＡ）、広帯域符号分割多元接続（Ｗｉｄｅｂａｎｄｃｏｄｅｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ、ＷＣＤＭＡ：登録商標）、時分割多元接続（ｔｉｍｅｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ、ＴＤＭＡ）、周波数分割多元接続（ｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ、ＦＤＭＡ）、直交周波数分割多元接続（Ｏｒｔｈｏｇｏｎａｌｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ、ＯＦＤＭＡ）、シングルキャリア周波数分割多元接続（ｓｉｎｇｌｅＣａｒｒｉｅｒＦＤＭＡ、ＳＣ－ＦＤＭＡ）、キャリアセンス多重アクセス／衝突回避（ＣａｒｒｉｅｒＳｅｎｓｅＭｕｌｔｉｐｌｅＡｃｃｅｓｓｗｉｔｈＣｏｌｌｉｓｉｏｎＡｖｏｉｄａｎｃｅ）などの異なる通信技術を使用することができる。ネットワークは、異なるネットワークの容量、速度、遅延などの要素に応じて、２Ｇ（英語：ｇｅｎｅｒａｔｉｏｎ）ネットワーク、３Ｇネットワーク、４Ｇネットワーク、または５Ｇネットワークのような将来の進化型ネットワークに分類することができ、５Ｇネットワークは、新しい無線ネットワーク（ＮｅｗＲａｄｉｏ、ＮＲ）とも呼ばれる。説明の便宜上、本開示では、無線通信ネットワークを単にネットワークと称することがある。

【0014】

さらに、本開示に係るネットワーク機器は、無線アクセスネットワーク機器と称することもできる。当該無線アクセスネットワーク機器は、基地局、進化型基地局（ＥｖｏｌｖｅｄｎｏｄｅＢ、基地局）、ホーム基地局、ワイヤレス・フィディリティ（ｗｉｒｅｌｅｓｓｆｉｄｅｌｉｔｙ、ＷＩＦＩ）システムにおけるアクセスポイント（ａｃｃｅｓｓｐｏｉｎｔ、ＡＰ）、無線中継ノード、無線返信ノード、トランスポートポイント（ＴＰ）または送受信ポイント（ｔｒａｎｓｍｉｓｓｉｏｎａｎｄｒｅｃｅｐｔｉｏｎｐｏｉｎｔ、ＴＲＰ）などであってもよく、ＮＲシステムにおけるｇＮＢであってもよく、あるいは、基地局を構成するコンポーネントまたは一部の機器などであってもよい。なお、本開示の実施例では、ネットワーク機器に採用される具体的な技術および具体的な機器形態は限定されない。本開示では、ネットワーク機器は、特定の地理的領域に通信カバレッジを提供し、当該カバレッジ領域（セル）内に位置する端末と通信することができる。また、ネットワーク機器は、コネクテッドカー（Ｖ２Ｘ）通信システムである場合、車載機器であってもよい。

【0015】

さらに、本開示に係る端末は、端末機器、ユーザ機器（ＵｓｅｒＥｑｕｉｐｍｅｎｔ、ＵＥ）、モバイルステーション（ＭｏｂｉｌｅＳｔａｔｉｏｎ、ＭＳ）、モバイル端末（ＭｏｂｉｌｅＴｅｒｍｉｎａｌ、ＭＴ）などとも呼ばれ、音声および／またはデータ接続性をユーザに提供する機器であり、例えば、端末は、無線接続機能を有するハンドヘルド機器、車載機器などとすることができる。現在、いくつかの端末としては、スマートフォン（ＭｏｂｉｌｅＰｈｏｎｅ）、ポケットコンピュータ（ＰｏｃｋｅｔＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ、ＰＰＣ）、ハンドヘルド、パーソナルデジタルアシスタント（ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔ、ＰＤＡ）、ノートパソコン、タブレット、ウェアラブル機器、または車載機器などが挙げられる。また、コネクテッドカー（Ｖ２Ｘ）通信システムである場合、端末機器は車載機器であってもよい。なお、本開示の実施例は、端末によって採用される具体的な技術および具体的な機器形態に限定されない。

【0016】

ＮＲでは、特に通信帯域がｆｒｅｑｕｅｎｃｙｒａｎｇｅ２の場合、高周波チャンネルの減衰が速いため、カバレッジを確保するために、端末とネットワーク機器との間でビームベース（ｂｅａｍ）の送受信が必要となる。

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

本開示は、以上に説明され、図面に示された正確な構造に限定されず、その範囲を逸脱することなく、様々な修正および変更が可能であることを理解すべきである。本開示の範囲は、添付された特許請求の範囲のみによって限定される。

【図1】