特表2023-548066 | 知財ポータル「IP Force」

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

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

▶ ノキア　テクノロジーズ　オサケユイチアの特許一覧

特表2023-548066マルチキャストトラフィックへの周波数領域リソース割り当て

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

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

< >

1
2
3
4
5A
5B
6
7A
7B
8A
8B
9
10
11
12
13

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

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

(11)【公表番号】

(43)【公表日】2023-11-15

(54)【発明の名称】マルチキャストトラフィックへの周波数領域リソース割り当て

(51)【国際特許分類】

H04W 4/06 20090101AFI20231108BHJP

H04W 72/0453 20230101ALI20231108BHJP

H04W 72/30 20230101ALI20231108BHJP

H04W 72/1273 20230101ALI20231108BHJP

H04W 72/232 20230101ALI20231108BHJP

【ＦＩ】

H04W4/06

H04W72/0453

H04W72/30

H04W72/1273

H04W72/232

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023524881

(86)(22)【出願日】2020-10-22

(85)【翻訳文提出日】2023-06-22

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

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

(87)【国際公開日】2022-04-28

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．３ＧＰＰ

２．ＷＣＤＭＡ

(71)【出願人】

【識別番号】515076873

【氏名又は名称】ノキアテクノロジーズオサケユイチア

(74)【代理人】

【識別番号】100094569

【弁理士】

【氏名又は名称】田中伸一郎

(74)【代理人】

【識別番号】100103610

【弁理士】

【氏名又は名称】▲吉▼田和彦

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚文昭

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤直樹

(74)【代理人】

【識別番号】100176418

【弁理士】

【氏名又は名称】工藤嘉晃

(72)【発明者】

【氏名】プラサドアトゥル

(72)【発明者】

【氏名】バトゥーラウルデヴィッド

(72)【発明者】

【氏名】ナヴラティルデヴィッド

(72)【発明者】

【氏名】チェンナイツェン

(72)【発明者】

【氏名】エルマリウグルバラン

(72)【発明者】

【氏名】パウリヴォルカー

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

5K067

【Ｆターム（参考）】

5K067CC13

5K067DD34

5K067EE22

5K067JJ22

(57)【要約】

本開示の実施形態は、マルチキャストトラフィックへの周波数領域リソース割り当てに関する。方法が、第１のデバイスにおいて、コアネットワーク要素から第２のデバイスのためにスケジュールされるマルチキャストトラフィックを受信することと、第２のデバイスが前記第２のデバイスのために構成された帯域幅部分内で前記マルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする前記第２のデバイスのための支援情報を生成することと、支援情報を第２のデバイスに送信することとを含む。方法は、第２のデバイスにおいて第１のデバイスから支援情報を受信することと、支援情報に基づいてダウンリンク制御情報から周波数領域リソースを判定することとを含む。このようにして、マルチキャストトラフィックをスケジュールする高い柔軟性が提供可能であり、端末デバイスに対する大幅な複雑性低減をもたらすことができる。

【特許請求の範囲】

【請求項1】

少なくとも１つのプロセッサと、
コンピュータプログラムコードを含む少なくとも１つのメモリとを含む第１のデバイスであって、
前記少なくとも１つのメモリと前記コンピュータプログラムコードとが、前記少なくとも１つのプロセッサによって前記第１のデバイスに、
コアネットワーク要素から、第２のデバイスのためにスケジュールされるマルチキャストトラフィックを受信させ、
前記第２のデバイスが前記第２のデバイスのために構成された帯域幅部分内で前記マルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする前記第２のデバイスのための支援情報を生成させ、
前記支援情報を前記第２のデバイスに送信させるように構成されている、第１のデバイス。

【請求項2】

前記支援情報が、
前記周波数領域リソースがスケジュールされる前記帯域幅部分の識別情報、
前記帯域幅部分内の前記周波数領域リソースの開始位置を示すオフセット、または、
前記第２のデバイスのために構成された前記帯域幅部分のサイズに対して相対的に前記マルチキャストトラフィックの帯域幅部分のサイズを適応させるためのパラメータ、
のうちの少なくとも１つを含む、請求項１に記載の第１のデバイス。

【請求項3】

前記支援情報に識別子が関連付けられ、前記識別子がマルチキャストトラフィックに関連付けられている、請求項１に記載の第１のデバイス。

【請求項4】

前記第１のデバイスがさらに、
前記マルチキャストトラフィックをスケジュールするために使用される共通周波数リソースから選択される前記周波数領域リソースを示すフィールドを含むダウンリンク制御情報を生成し、
前記マルチキャストトラフィックに関連付けられた識別子で前記ダウンリンク制御情報をスクランブルし、
スクランブルされた前記ダウンリンク制御情報を前記第２のデバイスに送信するようにされる、請求項１に記載の第１のデバイス。

【請求項5】

前記第１のデバイスがネットワークデバイスであり、前記第２のデバイスが端末デバイスである、請求項１に記載の第１のデバイス。

【請求項6】

少なくとも１つのプロセッサと、
コンピュータプログラムコードを含む少なくとも１つのメモリとを含む第２のデバイスであって、
前記少なくとも１つのメモリと前記コンピュータプログラムコードとが、前記少なくとも１つのプロセッサによって前記第２のデバイスに、
前記第２のデバイスが前記第２のデバイスのために構成された帯域幅部分内でマルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする支援情報を、第１のデバイスから受信させ、
前記第１のデバイスから受信され、前記周波数領域リソースを示すフィールドを含むダウンリンク制御情報から、前記支援情報に基づいて前記周波数領域リソースを判定させるように構成されている、第２のデバイス。

【請求項7】

【請求項8】

前記支援情報に識別子が関連付けられ、前記識別子がマルチキャストトラフィックに関連付けられている、請求項６に記載の第２のデバイス。

【請求項9】

前記第２のデバイスがさらに、
ダウンリンク制御チャネルから、前記マルチキャストトラフィックに関連付けられた識別子でスクランブルされたダウンリンク制御情報を受信し、
スクランブルされた前記ダウンリンク制御情報をスクランブル解除することによって前記ダウンリンク制御情報を判定するようにされる、請求項６に記載の第２のデバイス。

【請求項10】

前記第２のデバイスが、
前記パラメータに基づいて前記フィールドのサイズを判定することと、
前記フィールドのサイズに基づいて前記ダウンリンク制御情報から前記フィールドを取得することと、
前記フィールドに基づいて前記周波数領域リソースを判定することとによって、
前記周波数領域リソースを判定するようにされる、請求項７に記載の第２のデバイス。

【請求項11】

前記第２のデバイスが、
前記フィールドがビットマップを含むとの判定に従って、前記フィールドの始めを第１の数の第１のビットでパディングし、前記フィールドの終わりを第２の数の前記第１のビットでパディングすることによって、前記フィールドのサイズが前記第２のデバイスのために構成された前記帯域幅部分のサイズと等しくなるように前記フィールドを拡張することであって、前記第１の数が前記オフセットと等しく、前記第１のビットがデータがスケジュールされていないことを示す、前記フィールドを拡張することと、
拡張された前記フィールドに基づいて前記第２のデバイスの前記帯域幅部分のための前記周波数領域リソースを判定することとによって、
前記周波数領域リソースを判定するようにされる、請求項７に記載の第２のデバイス。

【請求項12】

前記第２のデバイスが、
前記フィールドが開始リソースブロックのインデックス情報とリソースブロック数とを含むとの判定に従って、前記インデックス情報と前記オフセットとに基づいてさらなるインデックス情報を取得することと、
前記さらなるインデックス情報と前記パラメータと前記リソースブロック数とに基づいてリソース標識値を判定することと、
前記リソース標識値に基づいて前記周波数領域リソースを判定することとによって、
前記周波数領域リソースを判定するようにされる、請求項７に記載の第２のデバイス。

【請求項13】

前記第１のデバイスがネットワークデバイスであり、前記第２のデバイスが端末デバイスである、請求項６に記載の第２のデバイス。

【請求項14】

通信方法であって、
第１のデバイスにおいて、コアネットワーク要素から第２のデバイスのためにスケジュールされるマルチキャストトラフィックを受信することと、
前記第２のデバイスが前記第２のデバイスのために構成された帯域幅部分内で前記マルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする前記第２のデバイスのための支援情報を生成することと、
前記支援情報を前記第２のデバイスに送信することとを含む、方法。

【請求項15】

【請求項16】

前記支援情報に識別子が関連付けられ、前記識別子がマルチキャストトラフィックに関連付けられている、請求項１４に記載の方法。

【請求項17】

前記マルチキャストトラフィックをスケジュールするために使用される共通周波数リソースから選択される前記周波数領域リソースを示すフィールドを含むダウンリンク制御情報を生成することと、
前記マルチキャストトラフィックに関連付けられた識別子で前記ダウンリンク制御情報をスクランブルすることと、
スクランブルされた前記ダウンリンク制御情報を前記第２のデバイスに送信することとをさらに含む、請求項１４に記載の方法。

【請求項18】

前記第１のデバイスがネットワークデバイスであり、前記第２のデバイスが端末デバイスである、請求項１４に記載の方法。

【請求項19】

通信方法であって、
第２のデバイスにおいて、前記第２のデバイスが前記第２のデバイスのために構成された帯域幅部分内でマルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする支援情報を、第１のデバイスから受信することと、
前記第１のデバイスから受信され、前記周波数領域リソースを示すフィールドを含むダウンリンク制御情報から、前記支援情報に基づいて前記周波数領域リソースを判定することとを含む、方法。

【請求項20】

【請求項21】

前記支援情報に識別子が関連付けられ、前記識別子がマルチキャストトラフィックに関連付けられている、請求項１９に記載の方法。

【請求項22】

ダウンリンク制御チャネルから、前記マルチキャストトラフィックに関連付けられた識別子でスクランブルされたダウンリンク制御情報を受信することと、
スクランブルされた前記ダウンリンク制御情報をスクランブル解除することによって前記ダウンリンク制御情報を判定することとをさらに含む、請求項１９に記載の方法。

【請求項23】

前記周波数領域リソースを判定することが、
前記パラメータに基づいて前記フィールドのサイズを判定することと、
前記フィールドのサイズに基づいて前記ダウンリンク制御情報から前記フィールドを取得することと、
前記フィールドに基づいて前記周波数領域リソースを判定することとを含む、請求項２０に記載の方法。

【請求項24】

前記周波数領域リソースを判定することが、
前記フィールドがビットマップを含むとの判定に従って、前記フィールドの始めを第１の数の第１のビットでパディングし、前記フィールドの終わりを第２の数の前記第１のビットでパディングすることによって、前記フィールドのサイズが前記第２のデバイスのために構成された前記帯域幅部分のサイズと等しくなるように前記フィールドを拡張することであって、前記第１の数が前記オフセットと等しく、前記第１のビットがデータがスケジュールされていないことを示す、前記フィールドを拡張することと、
拡張された前記フィールドに基づいて前記第２のデバイスの前記帯域幅部分のための前記周波数領域リソースを判定することとを含む、請求項２０に記載の方法。

【請求項25】

前記周波数領域リソースを判定することが、
前記フィールドが開始リソースブロックのインデックス情報とリソースブロック数とを含むとの判定に従って、前記インデックス情報と前記オフセットとに基づいてさらなるインデックス情報を取得することと、
前記さらなるインデックス情報と前記パラメータと前記リソースブロック数とに基づいてリソース標識値を判定することと、
前記リソース標識値に基づいて前記周波数領域リソースを判定することとを含む、請求項２０に記載の方法。

【請求項26】

前記第１のデバイスがネットワークデバイスであり、前記第２のデバイスが端末デバイスである、請求項１９に記載の方法。

【請求項27】

通信装置であって、
第１のデバイスにおいて、コアネットワーク要素から第２のデバイスのためにスケジュールされるマルチキャストトラフィックを受信する手段と、
前記第２のデバイスが前記第２のデバイスのために構成された帯域幅部分内で前記マルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする前記第２のデバイスのための支援情報を生成する手段と、
前記支援情報を前記第２のデバイスに送信する手段とを含む、通信装置。

【請求項28】

通信装置であって、
第２のデバイスにおいて、前記第２のデバイスが前記第２のデバイスのために構成された帯域幅部分内でマルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする支援情報を、第１のデバイスから受信する手段と、
前記第１のデバイスから受信され、前記周波数領域リソースを示すフィールドを含むダウンリンク制御情報から、前記支援情報に基づいて前記周波数領域リソースを判定する手段とを含む、通信装置。

【請求項29】

装置に請求項１４～１８のいずれか１項に記載の方法を実行させるプログラム命令を含む、非一時的コンピュータ可読媒体。

【請求項30】

装置に請求項１９～２６のいずれか１項に記載の方法を実行させるプログラム命令を含む、非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示の実施形態は、一般には遠隔通信の分野に関し、具体的には、マルチキャストトラフィックへの周波数領域リソース割り当てを最適化する通信の方法、デバイスおよびコンピュータ可読記憶媒体に関する。

【背景技術】

【0002】

ニューラジオ（ｎｅｗｒａｄｉｏ（ＮＲ））マルチキャスト技術の発展にともなって、第３世代パートナーシッププロジェクト（３ＧＰＰ）は現在、多数の端末デバイスへのマルチキャストトラフィックおよび／またはブロードキャストトラフィックの配信を可能にするための機構を定義している。１つの重要な目標は、現在定義されているユニキャストスケジューリングおよび動作機構との最大の共通性を維持しながら、共通のデータチャネルリソースを使用してマルチキャストトラフィックおよび／またはブロードキャストトラフィックをスケジュールすることを可能にするグループスケジューリング機構を定義することである。

【0003】

現在までのところ、グループスケジューリング機構の強化は主としてダウンリンクデータトラフィックスケジューリングおよび関連する無線リソース最適化に関係するものであった。信頼性向上技術に関する様々な解決策もある。しかし、特にシグナリングに関して、制御チャネル強化に与えられる注目は限定されていた。具体的には、自身の固有帯域幅構成に応じてグループ内の個々のユーザまたは端末デバイスによって異なって解釈され得る、ユーザのグループに対する周波数領域リソース割り当て情報のための制御シグナリング強化についてはこれまで考慮されていなかった。

【発明の概要】

【0004】

一般には、本開示の例示の実施形態は、マルチキャストトラフィックへの周波数領域リソース割り当てを最適化する解決策を提供する。

【0005】

第１の態様では、第１のデバイスが提供される。第１のデバイスは、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを含み、少なくとも１つのメモリとコンピュータプログラムコードとが、少なくとも１つのプロセッサによって第１のデバイスに、コアネットワーク要素から第２のデバイスのためにスケジュールされるマルチキャストトラフィックを受信させ、第２のデバイスが第２のデバイスのために構成された帯域幅部分（ｂａｎｄｗｉｄｔｈｐａｒｔ）内でマルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする第２のデバイスのための支援情報（ａｓｓｉｓｔａｎｃｅｉｎｆｏｒｍａｔｉｏｎ）を生成させ、支援情報を第２のデバイスに送信させるように構成されている。

【0006】

第２の態様では、第２のデバイスが提供される。第２のデバイスは、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを含み、少なくとも１つのメモリとコンピュータプログラムコードとが、少なくとも１つのプロセッサによって第２のデバイスに、第２のデバイスが第２のデバイスのために構成された帯域幅部分内でマルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする支援情報を、第１のデバイスから受信させ、第１のデバイスから受信され、周波数領域リソースを示すフィールドを含むダウンリンク制御情報から、支援情報に基づいて周波数領域リソースを判定させるように構成される。

【0007】

第３の態様では、通信方法が提供される。方法は、第１のデバイスにおいてコアネットワーク要素から、第２のデバイスのためにスケジュールされるマルチキャストトラフィックを受信することと、第２のデバイスが第２のデバイスのために構成された帯域幅部分内でマルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする第２のデバイスのための支援情報を生成することと、支援情報を第２のデバイスに送信することとを含む。

【0008】

第４の態様では、通信方法が提供される。方法は、第２のデバイスにおいて、第２のデバイスが第２のデバイスのために構成された帯域幅部分内でマルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする支援情報を、第１のデバイスから受信することと、第１のデバイスから受信され、周波数領域リソースを示すフィールドを含むダウンリンク制御情報から、支援情報に基づいて周波数領域リソースを判定することとを含む。

【0009】

第５の態様では、通信装置が提供される。装置は、第１のデバイスにおいてコアネットワーク要素から、第２のデバイスのためにスケジュールされるマルチキャストトラフィックを受信する手段と、第２のデバイスが第２のデバイスのために構成された帯域幅部分内でマルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする第２のデバイスのための支援情報を生成する手段と、支援情報を第２のデバイスに送信する手段とを含む。

【0010】

第６の態様では、通信装置が提供される。装置は、第２のデバイスにおいて、第２のデバイスが２のデバイスのために構成された帯域幅部分内でマルチキャストトラフィックに割り当てられた周波数領域リソースを特定することができるようにする支援情報を、第１のデバイスから受信する手段と、第１のデバイスから受信され、周波数領域リソースを示すフィールドを含むダウンリンク制御情報から、支援情報に基づいて周波数領域リソースを判定する手段とを含む。

【0011】

第７の態様では、非一時的なコンピュータ可読媒体が提供される。非一時的なコンピュータ可読媒体は、装置に第３の態様による方法を行わせるプログラム命令を含む。

【0012】

第８の態様では、非一時的なコンピュータ可読媒体が提供される。非一時的なコンピュータ可読媒体は、装置に第４の態様による方法を行わせるプログラム命令を含む。

【0013】

発明の概要の項は、本開示の実施形態の重要または必須の特徴を特定することは意図しておらず、本開示の範囲を限定するために使用されることも意図していない。本開示の他の特徴は、以下の説明から容易に理解可能になるであろう。

【0014】

いくつかの例示の実施形態について、以下に添付図面を参照しながら説明する。

【図面の簡単な説明】

【0015】

【図1】本開示の例示の実施形態を実装可能な例示の通信ネットワークを示す図である。

【図2】帯域幅部分（ｂａｎｄｗｉｄｔｈｐａｒｔ（ＢＷＰ））構成を示す図である。

【図3】ＮＲマルチキャストのために考慮された制御信号シナリオを示す図である。

【図4】従来の解決策によるマルチキャストトラフィックをスケジュールするための単純なＢＷＰ構成を示す図である。

【図5A】従来の解決策によるマルチキャストトラフィックをスケジュールするための柔軟なＢＷＰ構成を示す図である。

【図5B】従来の解決策によるマルチキャストトラフィックをスケジュールするための別の柔軟なＢＷＰ構成を示す図である。

【図6】本開示の一部の実施形態による通信のプロセスを示すフローチャートである。

【図7A】本開示の一部の実施形態による、リソース割り当て（ＲＡ）タイプ０のマルチキャストトラフィックのための周波数領域リソースの判定例を示す図である。

【図7B】本開示の一部の実施形態による、リソース割り当て（ＲＡ）タイプ０のマルチキャストトラフィックのための周波数領域リソースの別の判定例を示す図である。

【図8A】本開示の一部の実装形態による、ＲＡタイプ１のマルチキャストトラフィックのための周波数領域リソースの判定例を示す図である。

【図8B】本開示の一部の実施形態による、ＲＡタイプ１のマルチキャストトラフィックのための周波数領域リソースの判定例を示す図である。

【図9】本開示の例示の実装形態による、第１のデバイスにおいて実施される通信方法を示すフローチャートである。

【図10】本開示の例示の実施形態による、第２のデバイスにおいて実施される通信方法を示すフローチャートである。

【図11】本開示の例示の実装形態によるマルチキャストトラフィックのための周波数領域リソースを判定する方法を示すフローチャートである。

【図12】本開示の例示の実施形態を実装するのに適した装置を示す概略ブロック図である。

【図13】本開示の例示の実施形態による、例示のコンピュータ可読媒体を示すブロック図である。

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

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

実施形態によっては、支援情報は、ＢＷＰ内の周波数領域リソースの開始位置を示すオフセット（本明細書では周波数リソースオフセット（ＦＲＯ）とも呼ぶ）を含んでもよい。実施形態によっては、支援情報は、第２のデバイス１２０のために構成されたＢＷＰのサイズに対して相対的にマルチキャストトラフィックのＢＷＰのサイズを適応させるためのパラメータ（本明細書ではＢＷＰサイズ適応化パラメータ（ＢＷＰ_SA）とも呼ぶ）を含み得る。実施形態によっては、ＦＲＯおよびＢＷＰ_SAは、マルチキャストトラフィックのため、または第２のデバイス１２０のために使用または構成されるリソース割り当て（ＲＡ）タイプ（タイプ０またはタイプ１）に応じて、第２のデバイス１２０にシグナリングされる任意選択によるパラメータであってもよい。

【0054】

上記は支援情報の例に過ぎず、支援情報は、第２のデバイス１２０が、第２のデバイス１２０のために構成されたＢＷＰ内のマルチキャストトラフィックのために割り当てられた周波数領域リソースを特定することを可能にする他の適切な情報も含み得ることを理解されたい。

【0055】

支援情報により、第２のデバイス１２０専用のＢＷＰサイズとマルチキャストトラフィックのための共通周波数リソースとの最善の態様を組み合わせることによって、ＭＢＳＰＤＳＣＨをスケジュールするための高い柔軟性を第１のデバイス１１０に与えることができる。また、第１のデバイス１１０は、第２のデバイス１２０専用の柔軟なＢＷＰ構成を可能にすることによって、同じスロット内で第２のデバイス１２０のためのユニキャストトラフィックとマルチキャストトラフィックとをスケジュールすることが可能になる。

【0056】

実施形態によっては、支援情報には、マルチキャストトラフィックに関連付けられた識別子が関連付けられてもよい。たとえば、識別子はマルチキャストトラフィックのＧ－ＲＮＴＩなどの共通グループ識別子であってもよい。この場合、Ｇ－ＲＮＴＩと支援情報との間に１対１対応関係があってもよい。言い換えると、支援情報はマルチキャストサービスごとに構成されてもよく、その有効性が個別のマルチキャストサービスに限定されてもよい。このようにして、異なるマルチキャストサービスのために異なる支援情報が提供されてもよく、マルチキャストトラフィックのための周波数領域リソースのスケジューリングをより柔軟な方法で行うことができる。

【0057】

支援情報が生成されると、第１のデバイス１１０は支援情報を第２のデバイス１２０に送信する６３０。実施形態によっては、支援情報はＧ－ＲＮＴＩ構成とともに送信されてもよい。実施形態によっては、第１のデバイス１１０は、支援情報をＲＲＣシグナリングなどのより上位層のシグナリングを介して送信してもよい。支援情報をやり取りするための他の適切な手段も可能であることを理解されたい。

【0058】

実施形態によっては、第１のデバイス１１０は、周波数領域リソースを示すフィールド（本明細書ではＦＤＲＡフィールドとも呼ぶ）を含むＤＣＩを生成する６４０。たとえば、ＤＣＩは形式１＿０であってもよく、図３のＦＤＲＡフィールド３１０を含んでもよい。別の実施例として、ＤＣＩは形式１＿１であってもよく、図３のＦＤＲＡフィールド３２０を含んでもよい。ＤＣＩのために他の適切な形式も可能であることを理解されたい。

【0059】

実施形態によっては、第１のデバイス１１０は、マルチキャストトラフィックのスケジューリングのために使用される共通周波数リソースから周波数領域リソースを判定または選択してもよい。

【0060】

実施形態によっては、第１のデバイス１１０は、マルチキャストトラフィックに関連付けられた識別子でＤＣＩをスクランブルしてもよい６５０。たとえば、第１のデバイス１１０はＧ－ＲＮＴＩでＤＣＩの巡回冗長検査（ＣＲＣ）スクランブリングを行ってもよい。次に、第１のデバイス１１０は、スクランブルされたＤＣＩを第２のデバイス１２０に送信してもよい。

【0061】

したがって、第２のデバイス１２０は、第１のデバイス１１０から、支援情報を受信し、ＤＣＩも受信してもよい。実施形態によっては、第２のデバイス１２０は、ダウンリンク制御チャネルから、マルチキャストトラフィックに関連付けられた識別子でスクランブルされたＤＣＩを受信してもよい。たとえば、第２のデバイス１２０は、ＰＤＣＣＨからマルチキャストトラフィックに対応するＧ－ＲＮＴＩでスクランブルされたＤＣＩを受信してもよい。次に、第２のデバイス１２０は、スクランブルされたＤＣＩをスクランブル解除することによってＤＣＩを判定してもよい。

【0062】

実施形態によっては、第２のデバイス１２０は、支援情報内のＢＷＰ_SAに基づいてＤＣＩ内のＦＤＲＡフィールドのサイズを判定してもよい６７０。次に、第２のデバイス１２０は、フィールドのサイズに基づいてＤＣＩからフィールドを取得またはデコードしてもよい６８０。このプロセスをＤＣＩサイズ推定と呼ぶ場合がある。これは、構成された異なるＢＷＰを有し得るすべての第２のデバイスが、可能なＤＣＩサイズに関して確実に同期されるようにするために行われる。このようにして、簡略化されたブラインドデコーディングを行うことができる。

【0063】

第２のデバイス１２０は、支援情報に基づいてＤＣＩ内のＦＤＲＡフィールドから周波数領域リソースを判定する６９０。実施形態によっては、第２のデバイス１２０は、Ｇ－ＲＮＴＩに対応するそれぞれの支援情報を判定してもよい。このようにして、異なるマルチキャストサービスに異なる支援情報が提供されてもよく、マルチキャストトラフィックへの周波数領域リソース割り当てをより柔軟な方式で行うことができる。

【0064】

ＦＤＲＡフィールドを判定すると、第２のデバイス１２０は、第２のデバイス１２０のために構成されたＲＡタイプを判定してもよい６９１。実施形態によっては、ＲＡタイプは、ＦＤＲＡフィールドがビットマップを含むタイプ０であってもよい。図７Ａに、本開示の一部の実施形態によるリソース割り当て（ＲＡ）タイプ０のマルチキャストトラフィックのための周波数領域リソースの判定例の図７００Ａを示し、図７Ｂに、本開示の一部の実施形態によるリソース割り当て（ＲＡ）タイプ０のマルチキャストトラフィックのための周波数領域リソースの別の判定例の図７００Ｂを示す。図７Ａおよび図７Ｂに示すＦＤＲＡフィールド７０１はＲＡタイプ０のものであり、ビットマップの形態である。この実施例では、ビットマップフィールド「１」は、対応するＰＲＢにデータがスケジュールされることになることを示し、「０」は対応するＰＲＢにデータがスケジュールされないことを示す。当然ながら、実施形態によっては、ビットマップフィールド「１」が対応するＰＲＢにデータがスケジュールされないことを示してもよく、「０」が対応するＰＲＢにデータがスケジュールされることになることを示してもよい。

【0065】

実施形態によっては、ＲＡタイプは、ＦＤＲＡフィールドが開始リソースブロック（ＲＢ）のインデックス情報（本明細書ではＲＢ＿Ｓｔａｒｔとも呼ぶ）とＲＢの数（本明細書では長さとも呼ぶ）とを含む、タイプ１であってもよい。実施形態によっては、インデックス情報は、開始ＲＢのインデックスであってもよい。実施形態によっては、インデックス情報は、第２のデバイス１２０が開始ＲＢを判定するために使用することができるリソース標識値であってもよい。この場合、開始ＲＢのインデックスは、リソース標識値に基づいて判定されてもよい。開始ＲＢのインデックスは、そこからデータがスケジュールされるＰＲＢを示し、ＲＢの数は、第２のデバイス１２０が受信に関心を持っているデータがスケジュールされることになるＲＢのサイズで表したデータ伝送のサイズを示す。図８Ａに、本開示の一部の実施形態によるタイプ１のマルチキャストトラフィックのための周波数領域リソースの判定例の図８００Ａを示し、図８Ｂに、本開示の一部の実施形態によるタイプ１のマルチキャストのための周波数領域リソースの別の判定例の図８００Ｂを示す。図８Ａおよび図８Ｂに示すＦＤＲＡフィールドはＲＡタイプ１のものであり、２つの部分、すなわちＲＢ＿Ｓｔａｒｔ８０１と長さ８０２とを含む。

【0066】

実施形態によっては、ＦＤＲＡフィールドがビットマップを含む、すなわちＦＤＲＡフィールドがＲＡタイプ０であると判定された場合、第２のデバイス１２０のアクティブＢＷＰ内のＦＤＲＡフィールドにおけるビットマップ構成の相対位置を計算するためにＦＲＯが使用されてもよい。ＢＷＰ_SAはＦＤＲＡフィールドと同じサイズであってもよく、グループ共通ＰＤＳＣＨのための共通周波数リソースのサイズを示す。

【0067】

実施形態によっては、第２のデバイス１２０は、ＦＤＲＡフィールドの始めと終わりに、データがスケジュールされないことを示すビット（本明細書では第１のビットとも呼ぶ）をパディングすることによって、ＦＤＲＡフィールドのサイズが第２のデバイスのために構成されたＢＷＰのサイズと等しくなるようにＦＤＲＡフィールドが拡張されてもよい６９２。第１のビットは「０」であるものとする。当然ながら、他の適切なビットも可能である。実施形態によっては、第２のデバイス１２０は、ＦＤＲＡフィールドの始めを第１の数の第１のビットでパディングしてもよく、第１の数＝ＦＲＯである。この場合、第２のデバイス１２０は、ＦＤＲＡフィールドの終わりを第２の数の第１のビットでパディングしてもよく、第２の数＝ＢＷＰのサイズ－ＦＲＯ－ＢＷＰ_SAである。

【0068】

例示のために、図７Ａおよび図７Ｂに関連していくつかの実施例について説明する。これらの実施例では、共通周波数リソースを介してマルチキャストトラフィックを受信する２つの異なるＵＥ－１およびＵＥ－２を考える。ＵＥ－１の場合、これらの共通周波数リソースはＢＷＰ－１の一部であり、ＵＥ－２の場合、これらの共通周波数リソースはＢＷＰ－２の一部である。ＢＷＰ－１の合計サイズとＢＷＰ－２の合計サイズはＵＥ－１とＵＥ－２とで異なる。

【0069】

図７Ａの実施例では、ＢＷＰのサイズは７１０で示すように２０であり、ＦＲＯ＝５およびＢＷＰ_SA＝８である。ＤＣＩから取得されたＦＤＲＡフィールドが７１１で示されている。ＦＤＲＡフィールド７１１のサイズ＝ＢＷＰ_SA＝８である。７１２で示すようにＦＤＲＡフィールド７１１の始まりにサイズ＝ＦＲＯ＝５の「０」ビットがパディングされ、ＦＤＲＡフィールド７１１の終わりにサイズ＝ＢＷＰのサイズ－ＦＲＯ－ＢＷＰ_SA＝２０－５－８＝７の「０」ビットがパディングされる。

【0070】

図７Ｂの実施例では、７２０で示すようにＢＷＰのサイズは１０であり、ＦＲＯ＝１およびＢＷＰ_SA＝８である。ＤＣＩから取得されたＦＤＲＡフィールドが７２１で示されている。ＦＤＲＡフィールド７２１のサイズ＝ＢＷＰ_SA＝８である。７２２で示すようにＦＤＲＡフィールド７２１の始めがサイズ＝ＦＲＯ＝１の「０」ビットでパディングされ、ＦＤＲＡフィールド７２１の終わりがサイズ＝ＢＷＰ－ＦＲＯ－ＢＷＰ_SA＝１０－１－８＝１の「０」ビットでパディングされる。

【0071】

図７Ａおよび図７Ｂから、ＢＷＰ－１の合計サイズとＢＷＰ－２の合計サイズがＵＥ－１とＵＥ－２とで異なるにもかかわらず、ＵＥ－１とＵＥ－２は両方とも、支援情報を使用して、グループ共通ＭＢＳデータがスケジュールされる適切なＰＲＢを正しく特定することができる。ビットマップ構成はＵＥ－１とＵＥ－２とで共通であり、支援情報により、ＵＥ－１とＵＥ－２の両方が、データがスケジュールされると予期されるＰＲＢインデックスを判定することができる。

【0072】

拡張されたフィールドに基づいて、第２のデバイス１２０は、図７Ａの７１３および図７Ｂの７２３で示すように、第２のデバイスのために構成されたＢＷＰ内のマルチキャストトラフィックのためにスケジュールされた周波数領域リソースを特定してもよい６９３。

【0073】

実施形態によっては、ＦＤＲＡフィールドが開始ＲＢのインデックス情報とＲＢの数とを含むと判定された場合、すなわちＦＤＲＡフィールドがＲＡタイプ１のものである場合、第２のデバイス１２０はインデックス情報とＲＢの数と支援情報とに基づいてリソース標識値（ＲＩＶ）を判定してもよい６９２’。実施形態によっては、第２のデバイス１２０は、開始ＲＢのインデックス情報とＦＲＯとに基づいてさらなるインデックス情報（本明細書ではＲＢ＿Ｓｔａｒｔ＿Ａｃｔｕａｌとも呼ぶ）を取得してもよい。たとえば、ＲＢ＿Ｓｔａｒｔ＿Ａｃｔｕａｌ＝ＦＲＯ＋ＲＢ＿Ｓｔａｒｔである。実施形態によっては、グループ共通ＤＣＩ内のインデックス情報は常に０（すなわちＲＢ＿Ｓｔａｒｔ＝０）であってもよい。ここで、ＲＢの数≦ＢＷＰ_SAである。この場合、ＢＷＰ_SAは支援情報では設定されなくてもよい。実施形態によっては、ＲＢ＿Ｓｔａｒｔ＋長さ＝ＢＷＰのサイズである場合、ＢＷＰ_SAは省かれてもよい。

【0074】

実施形態によっては、第２のデバイス１２０は、さらなるインデックス情報とＢＷＰ_SAとＲＢの数とに基づいてＲＩＶを判定してもよい。たとえば、ＢＷＰのサイズがＢＷＰ_SAで、開始ＲＢのインデックスがＲＢ＿Ｓｔａｒｔ＿Ａｃｔｕａｌであることを前提として、ＲＩＶは以下の式（１）および（２）によって判定可能である。

【0075】

【数1】

である場合、

【数2】

それ以外の場合、

【数3】

ここで、Ｌ_RBsはＲＢの数を示し、ＲＢ_startは開始ＲＢのインデックスを示し、

【数4】

はＢＷＰのサイズを示す。Ｌ_RBs≧１であり、

【数5】

を超えてはならず、

【数6】

であり、ＲＢ_start＝ＲＢ＿Ｓｔａｒｔ＿Ａｃｔｕａｌである。

【0076】

上記の式は一例に過ぎず、ＲＩＶを計算するために他の適切な方法も可能であることを理解されたい。ＲＩＶに基づいて、第２のデバイス１２０は、第２のデバイス１２０のために構成されたＢＷＰ内でマルチキャストトラフィックのためにスケジュールされた周波数領域リソースを判定可能である６９３’。

【0077】

例示のために、いくつかの実施例について図８Ａおよび図８Ｂに関連して説明する。これらの実施例では、共通周波数リソースを介してマルチキャストトラフィックを受信する２つの異なるＵＥ－１およびＵＥ－２を考える。ＵＥ－１の場合、共通周波数リソースはＢＷＰ－１の一部であり、ＵＥ－２の場合、これらの共通周波数リソースはＢＷＰ－２の一部である。ＢＷＰ－１の合計サイズとＢＷＰ－２の合計サイズはＵＥ－１とＵＥ－２とで異なる。

【0078】

図８Ａの実施例では、８１０で示すようにＢＷＰのサイズは２０であり、８１１で示すようにＦＲＯ＝５であり、８１２で示すようにＢＷＰ_SA＝８である。マルチキャストトラフィックのために判定された共通周波数リソース（ＰＲＢインデックス）は８１３で示されている。図８Ｂの実施例では、８２０で示すようにＢＷＰのサイズは１０であり、８２１で示すようにＦＲＯ＝１であり、８２２で示すようにＢＷＰ_SA＝８である。マルチキャストトラフィックのために判定された共通周波数リソース（ＰＲＢインデックス）は８２３で示されている。

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

本開示について構造的特徴および／または方法論的動作に特有の言葉で記載しているが、添付の特許請求の範囲で定義されている本開示は、上述の特定の特徴または動作には必ずしも限定されないことを理解されたい。むしろ、上述の特定の特徴および動作は、特許請求の範囲を実装する例示の形態として開示されている。

【図1】