特開 2024-178409 端末装置、ネットワークデバイス、及び方法

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

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

(11)【公開番号】P2024178409

(43)【公開日】2024-12-24

(54)【発明の名称】端末装置、ネットワークデバイス、及び方法

(51)【国際特許分類】

   H04W 72/23 20230101AFI20241217BHJP

   H04W 72/1268 20230101ALI20241217BHJP

   H04W 72/0446 20230101ALI20241217BHJP

【ＦＩ】

H04W72/23

H04W72/1268

H04W72/0446

【審査請求】有

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2024166748

(22)【出願日】2024-09-25

(62)【分割の表示】P 2023029403の分割

【原出願日】2018-12-14

【公序良俗違反の表示】

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

１．３ＧＰＰ

２．ＷＣＤＭＡ

(71)【出願人】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】ユエン ファン

(72)【発明者】

【氏名】リャン リン

(72)【発明者】

【氏名】ワン ガン

(57)【要約】      （修正有）

【課題】マルチ送受信ポイント（ＴＲＰ）送信のための方法、デバイス及びコンピュータ読み取り可能な媒体を提供する。
【解決手段】端末デバイスで実施される方法は、ネットワークデバイスに接続されている第１のＴＲＰを介して受信した第１の指示に基づいて、シンボルの第１のリンク方向を決定する。第１のリンク方向は、第１のＴＲＰを介して端末デバイスとネットワークデバイスとの間でシンボルで実行される第１の送信の方向を示す。方法はまた、ネットワークデバイスに接続している第２のＴＲＰを介して受信した第２の指示に基づいて、シンボルの第２のリンク方向を決定する。第２のリンク方向は、第２のＴＲＰを介して端末デバイスとネットワークデバイスとの間でシンボルで実行される第２の送信の方向を示す。方法はさらに、第１及び第２のリンク方向に基づいて、第１及び第２の送信から、シンボルで実行されるターゲット送信を決定する。
【選択図】図３

【特許請求の範囲】

【請求項1】

端末装置が、
第１のダウンリンク制御情報（ＤＣＩ）に基づく第１の制御リソースセット（ＣＯＲＥＳＥＴ）に関連付けられた第１の物理アップリンク制御チャネル（ＰＵＣＣＨ）と、第２のＤＣＩに基づく第２のＣＯＲＥＳＥＴに関連付けられた第２のＰＵＣＣＨと、を送信する送信処理を実行し、
前記送信処理では、複数の第１のＤＣＩが受信される場合、前記第１のＤＣＩは最後のＤＣＩであり、複数の第２のＤＣＩが受信される場合、前記第２のＤＣＩは最後のＤＣＩであり、前記第１のＰＵＣＣＨおよび前記第２のＰＵＣＣＨは同一のスロットで送信される、
方法。

【請求項2】

前記第１のＰＵＣＣＨは第１のＴＲＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｒｅｃｅｐｔｉｏｎ Ｐｏｉｎｔ）に関連付けられ、前記第２のＰＵＣＣＨは第２のＴＲＰに関連付けられる、
請求項１に記載の方法。

【請求項3】

受信された複数の第１のＤＣＩの最後のＤＣＩにおけるリソースインジケータに基づいて、前記第１のＰＵＣＣＨのリソースを決定し、
受信された複数の第２のＤＣＩの最後のＤＣＩにおけるリソースインジケータに基づいて、前記第２のＰＵＣＣＨのリソースを決定する、
請求項１に記載の方法。

【請求項4】

第１のダウンリンク制御情報（ＤＣＩ）に基づく第１の制御リソースセット（ＣＯＲＥＳＥＴ）に関連付けられた第１の物理アップリンク制御チャネル（ＰＵＣＣＨ）と、第２のＤＣＩに基づく第２のＣＯＲＥＳＥＴに関連付けられた第２のＰＵＣＣＨと、を送信する送信処理を実行し、
前記送信処理では、複数の第１のＤＣＩが受信される場合、前記第１のＤＣＩは最後のＤＣＩであり、複数の第２のＤＣＩが受信される場合、前記第２のＤＣＩは最後のＤＣＩであり、前記第１のＰＵＣＣＨおよび前記第２のＰＵＣＣＨは同一のスロットで送信される、
端末装置。

【請求項5】

前記第１のＰＵＣＣＨは第１のＴＲＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｒｅｃｅｐｔｉｏｎ Ｐｏｉｎｔ）に関連付けられ、前記第２のＰＵＣＣＨは第２のＴＲＰに関連付けられる、
請求項４に記載の端末装置。

【請求項6】

受信された複数の第１のＤＣＩの最後のＤＣＩにおけるリソースインジケータに基づいて、前記第１のＰＵＣＣＨのリソースを決定し、
受信された複数の第２のＤＣＩの最後のＤＣＩにおけるリソースインジケータに基づいて、前記第２のＰＵＣＣＨのリソースを決定する、
請求項４に記載の端末装置。

【請求項7】

ネットワークデバイスが、
第１のＰＵＣＣＨリソース内の第１の制御リソースセット（ＣＯＲＥＳＥＴ）に関連付けられた第１の物理アップリンク制御チャネル（ＰＵＣＣＨ）と、第２のＰＵＣＣＨリソース内の第２のＣＯＲＥＳＥＴに関連付けられた第２のＰＵＣＣＨとを、同一スロットで、受信する受信処理を実行し、
前記受信処理では、前記第１のＰＵＣＣＨリソースは、複数の第１のＤＣＩの最後のＤＣＩに基づいて決定され、第２のＰＵＣＣＨリソースは、複数の第２のＤＣＩの最後のＤＣＩに基づいて決定される、
方法。

【請求項8】

複数の第１のＤＣＩと、複数の第２のＤＣＩを端末装置に送信する、
請求項７に記載の方法。

【請求項9】

第１のＴＲＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｒｅｃｅｐｔｉｏｎ Ｐｏｉｎｔ）を介して複数の第１のＤＣＩを送信し、
第２のＴＲＰを介して複数の第２のＤＣＩを送信する、
請求項７に記載の方法。

【請求項10】

第１のＰＵＣＣＨリソース内の第１の制御リソースセット（ＣＯＲＥＳＥＴ）に関連付けられた第１の物理アップリンク制御チャネル（ＰＵＣＣＨ）と、第２のＰＵＣＣＨリソース内の第２のＣＯＲＥＳＥＴに関連付けられた第２のＰＵＣＣＨとを、同一スロットで受信する受信処理を実行し、
前記受信処理では、前記第１のＰＵＣＣＨリソースは、複数の第１のＤＣＩの最後のＤＣＩに基づいて決定され、第２のＰＵＣＣＨリソースは、複数の第２のＤＣＩの最後のＤＣＩに基づいて決定される、
ネットワークデバイス。

【請求項11】

第１のＴＲＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｒｅｃｅｐｔｉｏｎ Ｐｏｉｎｔ）を介して複数の第１のＤＣＩを送信し、
第２のＴＲＰを介して複数の第２のＤＣＩを送信する、
請求項１０に記載のネットワークデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本開示の実施形態は、一般的に、通信に関し、特に、マルチ送受信ポイント（ＴＲＰ：ｍｕｌｔｉ－Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｒｅｃｅｐｔｉｏｎ Ｐｏｉｎｔ）送信のための方法、デバイス、及びコンピュータ読み取り可能な媒体に関する。

【背景技術】

【0002】

通信技術は、異なる無線デバイスが自治体、国、地域、並びに、グローバルレベルで通信できるような共通のプロトコルを提供するために、様々な通信規格が開発されている。新たな通信規格の一例として、ＮＲ（ｎｅｗ ｒａｄｉｏ）、例えば５Ｇ無線アクセスが挙げられる。ＮＲは、第３世代パートナーシッププロジェクト（３ＧＰＰ：Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏjｅｃｔ）によって公表されるロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）モバイル規格を強化するためのものである。ＮＲは、周波数効率の向上、コスト削減、サービスの向上、新しいスペクトルの利用、ダウンリンク（ＤＬ：ｄｏｗｎｌｉｎｋ）及びアップリンク（ＵＬ：ｕｐｌｉｎｋ）でサイクリックプレフィックス（ＣＰ：ｃｙｃｌｉｃ ｐｒｅｆｉｘ）を用いたＯＦＤＭＡを採用する他のオープンな規格との統合によって、モバイルブロードバンドインターネットアクセスをより良くサポートするとともに、ビームフォーミング、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ－Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ－Ｏｕｔｐｕｔ）アンテナ技術、キャリアアグリゲーションをサポートするように設計されている。

【0003】

ＮＲでは、ネットワークデバイス（例えば、ｇＮｏｄｅＢ）は、複数のＴＲＰ又はアンテナパネルを備えることができる。即ち、ネットワークデバイスは、複数のＴＲＰのうちの１つ又は複数のＴＲＰを介して、端末デバイス（例えば、ユーザ機器、ＵＥ）と通信することができる。スケジュールされた送信のために構成されたスロットフォーマットやリソースを端末デバイスに示すために、様々な指示が異なるＴＲＰを介して端末デバイスに送信されることがある。従って、異なるＴＲＰからの指示に起因するリンク方向の衝突及びアップリンクリソースの衝突に関する問題を詳細に説明する必要がある。

【発明の概要】

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

【0004】

一般的に、本開示の例示的な実施形態は、マルチＴＲＰ送信のための方法、デバイス、及びコンピュータ読み取り可能な媒体を提供する。

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

【0005】

第１の態様では、端末デバイスで実施される方法が提供される。この方法は、ネットワークデバイスに接続されている第１の送受信ポイントＴＲＰを介して受信した第１の指示に基づいて、前記第１のＴＲＰを介して前記端末デバイスと前記ネットワークデバイスとの間でシンボルで実行される第１の送信の方向を示す、前記シンボルの第１のリンク方向を決定することと、前記ネットワークデバイスに接続されている第２のＴＲＰを介して受信した第２の指示に基づいて、前記第２のＴＲＰを介して前記端末デバイスと前記ネットワークデバイスとの間で前記シンボルで実行される第２の送信の方向を示す、前記シンボルの第２のリンク方向を決定することと、前記第１のリンク方向及び前記第２のリンク方向に基づいて、前記第１の送信及び前記第２の送信から、前記シンボルで実行されるターゲット送信を決定することと、を含む。

【0006】

第２の態様では、端末デバイスで実施される方法が提供される。この方法は、ネットワークデバイスに接続されている第１のＴＲＰを介して前記端末デバイスと通信する前記ネットワークデバイスから指示を受信することと、前記指示が前記ネットワークデバイスに接続されている第２のＴＲＰのアクティブ化を示すと決定したことに応答して、前記第２のＴＲＰを介して前記ネットワークデバイスとの通信を実行することと、を含む。

【0007】

第３の態様では、ネットワークデバイスで実装される方法が提供される。この方法は、前記ネットワークデバイスに接続されている第１のＴＲＰを介して前記ネットワークデバイスと通信する端末デバイスへ送信される、前記ネットワークデバイスに接続されている第２のＴＲＰのアクティブ化を示す指示を決定することと、前記指示を前記端末デバイスに送信することと、前記第２のＴＲＰを介して前記端末デバイスとの通信を実行することとを含む。

【0008】

第４の態様では、端末デバイスが提供される。この端末デバイスは、プロセッサと、前記プロセッサに接続され、前記プロセッサによって実行されると、前記端末デバイスに第１の態様に記載の方法を実行させる命令が格納されたメモリと、を備える。

【0009】

第５の態様では、端末デバイスが提供される。この端末デバイスは、プロセッサと、前記プロセッサに接続され、前記プロセッサによって実行されると、前記端末デバイスに第２の態様に記載の方法を実行させる命令が格納されたメモリと、を備える。

【0010】

第６の態様では、ネットワークデバイスが提供される。このネットワークデバイスは、プロセッサと、前記プロセッサに接続され、前記プロセッサによって実行されると、前記ネットワークデバイスに第３の態様に記載の方法を実行させる命令が格納されたメモリと、を備える。

【0011】

第７の態様では、少なくとも１つのプロセッサで実行されると、前記少なくとも１つのプロセッサに第１の態様に記載の方法を実行させる命令が格納されたコンピュータ読み取り可能な媒体が提供される。

【0012】

第８の態様では、少なくとも１つのプロセッサで実行されると、前記少なくとも１つのプロセッサに第２の態様に記載の方法を実行させる命令が格納されたコンピュータ読み取り可能な媒体が提供される。

【0013】

第９の態様では、少なくとも１つのプロセッサで実行されると、前記少なくとも１つのプロセッサに第３の態様に記載の方法を実行させる命令が格納されたコンピュータ読み取り可能な媒体が提供される。

【0014】

本開示の他の特徴は、以下の説明により容易に理解できるようになる。

【図面の簡単な説明】

【0015】

添付図面を参照しながら本開示のいくつかの実施形態をより詳細に説明することを通して、本開示の上記及び他の目的、特徴、及び利点がより明らかになる。

【0016】

【図1】図１は、本開示の実施形態が実施されることができる通信環境の模式図である。

【図2】図２は、マルチＴＲＰ送信のプロセスを示す模式図である。

【図3】図３は、本開示のいくつかの実施形態にかかる例示的な方法のフローチャートを示す。

【図4A】図４Ａは、本開示のいくつかの実施形態にかかるリンク方向の衝突を例示する模式図を示す。

【図4B】図４Ｂは、本開示のいくつかの実施形態にかかるリンク方向の衝突の対処を例示する模式図を示す。

【図4C】図４Ｃは、本開示のいくつかの実施形態にかかるリンク方向の衝突の対処を例示する模式図を示す。

【図5】図５は、本開示のいくつかの実施形態にかかるスケジュールされたアップリンク送信を部分的にドロップする模式図を示す。

【図6】図６は、本開示のいくつかの実施形態にかかるスケジュールされたダウンリンク送信をドロップする模式図を示す。

【図7A】図７Ａは、本開示のいくつかの実施形態にかかるＵＬ衝突を例示する模式図を示す。

【図7B】図７Ｂは、本開示のいくつかの実施形態にかかるＵＬ衝突の対処を例示する模式図を示す。

【図7C】図７Ｃは、本開示のいくつかの実施形態にかかるＵＬ衝突の対処を例示する模式図を示す。

【図8】図８は、本開示のいくつかの実施形態にかかるマルチＴＲＰ送信のプロセス８００を示す模式図である。

【図9】図９は、本開示のいくつかの実施形態にかかるマルチＴＲＰ送信を示す模式図である。

【図10】図１０は、本開示のいくつかの実施形態にかかる例示的な方法のフローチャートである。

【図11】図１１は、本開示のいくつかの実施形態にかかる例示的な方法のフローチャートである。

【図12】図１２は、本開示の実施形態の実施に適したデバイスの簡略化したブロック図である。

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

表１において、第１列は、基準（Ｒｅｆ）ＴＲＰからの指示に基づいて決定されたシンボルタイプを示し、第２列は、他のＴＲＰからの指示に基づいて決定されたシンボルタイプを示す。表１から分かるように、シンボルタイプは、上記したように、「ＳＦＩ Ｄ」、「ＳＦＩ Ｕ」、「ＲＲＣ Ｄ」、「ＲＲＣ Ｕ」、「Ｄｙｎａｍｉｃ Ｄ」及び「Ｄｙｎａｍｉｃ Ｕ」を含むことができる。第３列は、端末デバイスの対応動作を示す。また、第１列は、任意のＴＲＰに明示的に関連付けられていないセル固有の指示に基づいて決定されたシンボルタイプを示し、Ｒｅｆ ＴＲＰはこれらのセル固有の指示と一致してもよい。
表１ マルチＴＲＰでのリンク方向の衝突の例

【表1】

【0055】

説明の目的のために、表１に示すように「ＲＲＣ Ｄ」及び「Ｄｙｎａｍｉｃ Ｕ」の例に関して説明する。いくつかの実施形態では、リンク方向の衝突が発生する１つ又は複数のシンボルについて、端末デバイス１２０は、２つのＴＲＰの優先順位に基づいて、この１つ又は複数のシンボルのリンク方向を決定してもよい。例えば、端末デバイス１２０は、表１の「ｒｅｆ ＴＲＰに従う」で示されるように、より高い優先順位を有するＲｅｆ ＴＲＰに従ってもよい。他のいくつかの実施形態では、リンク方向の衝突が発生する１つ又は複数のシンボルについて、端末デバイス１２０は、指示のタイプに基づいて、この１つ又は複数のシンボルのリンク方向を決定してもよい。例えば、端末デバイス１２０は、表１の「Ｄｙｎａｍｉｃ Ｕを優先する」で示されるように、第３の指示タイプの指示に従うように決定してもよい。このように、この例では、１つ又は複数のシンボルのリンク方向がアップリンクとして決定される。このアプローチは、ＤＣＩからのより柔軟でダイナミックなスケジューリングを可能にする。

【0056】

例えばＳＦＩ、ＤＣＩ及びＲＲＣシグナリングの特性により、表１のいくつかの例は「エラーケース」として示されており、「エラーケース」として示されているこれらの例について、端末デバイス１２０は、そのような指示がネットワークデバイス１１０によって示されると期待しないことに留意されたい。さらに、２つのＴＲＰの間で理想的なバックホールが維持されている場合、表１に示されているすべての例は、「エラーケース」として見なされる。

【0057】

表１の「Ｄｙｎａｍｉｃ Ｄ」及び「Ｄｙｎａｍｉｃ Ｕ」の例について、図４Ａ～図４Ｃを参照して実施形態を詳細に説明する。図４Ａは、本開示のいくつかの実施形態にかかるリンク方向の衝突を例示する模式図４００を示す。

【0058】

図４Ａには、９つのシンボル４１１～４１７が示されており、そのうち、シンボル４１１～４１２はダウンリンクシンボルとして構成され、シンボル４１８～４１９はアップリンクシンボルとして構成されている。シンボル４１３～４１７は、フレキシブルシンボルである。フレキシブルシンボルは、ＤＣＩ指示に基づいて、ダウンリンク用又はアップリンク用のいずれかとされることができる。例えば、１）ＴＤＤ－ＤＬ－ＵＬ－ＣｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｍｏｎ又はＴＤＤ－ＤＬ－ＵＬ－ＣｏｎｆｉｇＤｅｄｉｃａｔｅｄがなく、且つ、ＳＦＩ－ＤＣＩ（ＤＣＩフォーマット２_０）がない場合、２）ＴＤＤ－ＤＬ－ＵＬ－ＣｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｍｏｎ又はＴＤＤ－ＤＬ－ＵＬ－ＣｏｎｆｉｇＤｅｄｉｃａｔｅｄによってフレキシブルシンボルとして構成され、且つ、ＳＦＩ－ＤＣＩがない場合、３）ＴＤＤ－ＤＬ－ＵＬ－ＣｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｍｏｎ又はＴＤＤ－ＤＬ－ＵＬ－ＣｏｎｆｉｇＤｅｄｉｃａｔｅｄ、及びＳＦＩ－ＤＣＩの両方によってフレキシブルシンボルとして構成される場合、シンボルをフレキシブルシンボルとみなす。

【0059】

第１のＴＲＰ１３１と第２のＴＲＰ１３２との間に理想的なバックホールがある場合、ネットワークデバイス１１０は、２つのＴＲＰの間で調整を行い、いかなるリンク方向の衝突も発生しない。即ち、端末デバイス（例えばＵＥ）がフレキシブルシンボルとみなすスロットのシンボルセットについて、端末デバイスは、同一のサービングセルにおけるＤＣＩの指示に基づいて、ＵＥから１つのＴＲＰにスロットのシンボルセットで送信し、別のＴＲＰからスロットのシンボルセットで受信すると期待されない。

【0060】

非理想的なバックホールの場合、異なるＴＲＰを介して受信したＤＣＩの指示に起因して、リンク方向の衝突が発生する可能性がある。図４Ａに示すように、第１のＴＲＰ１３１を介して受信したＤＣＩ４０１は、第１のＴＲＰ１３１を介してのネットワークデバイス１１０と端末デバイス１２０との間の第１の送信用のダウンリンクリソース４２１を示し、第２のＴＲＰ１３２を介して受信したＤＣＩ４０２は、第２のＴＲＰ１３２を介してのネットワークデバイス１１０と端末デバイス１２０との間の第２の送信用のアップリンクリソース４２２を示す。ダウンリンクリソース４２１とアップリンクリソース４２２とは、フレキシブルシンボルであるシンボル４１５～４１６にわたってオーバーラップしている。従って、端末デバイス１２０は、リンク方向の衝突を対処する必要がある。例えば、端末デバイス１２０は、ダウンリンクリソース４２１及びアップリンクリソース４２２から、ネットワークデバイス１１０との通信を実行するターゲットリソースを決定してもよい。

【0061】

図４Ｂは、本開示のいくつかの実施形態にかかるリンク方向の衝突の対処を例示する模式図４１０を示す。図４Ｃは、本開示のいくつかの実施形態にかかるリンク方向の衝突の対処を例示する模式図４２０を示す。

【0062】

上記したように、いくつかの実施形態では、端末デバイス１２０は、予め定義されたタイミング優先順位に基づいてターゲットリソースを決定してもよい。予め定義されたタイミング優先順位は、開始／終了ＤＣＩシンボル、ＤＣＩデコードレイテンシ、スケジュールされた送信の開始シンボル及び／又は持続時間のうちの少なくとも１つに関連してもよい。例えば、ＤＣＩ４０１の開始シンボルがＤＣＩ４０２の開始シンボルの前にある場合、ダウンリンクリソース４２１がターゲットリソースとして決定され、端末デバイス１２０は、スケジュールされた送信をリソース４２１で実行する。

【0063】

別の例として、ＤＣＩ４０１のデコードよりも前にＤＣＩ４０２のデコードが完了した場合、端末デバイス１２０は、図４Ｂに模式的に示すように、アップリンクリソース４２２をターゲットリソースとして決定してもよい。そして、端末デバイス１２０は、スケジュールされた送信をリソース４２２で実行してもよい。

【0064】

さらなる例として、図４Ｃに示すように、ダウンリンクリソース４２１の開始シンボル４１３は、アップリンクリソース４２２の開始シンボル４１５の前にある。従って、端末デバイス１２０は、ダウンリンクリソース４２１をターゲットリソースとして決定してもよい。

【0065】

いくつかの実施形態では、端末デバイス１２０は、ＴＲＰの優先順位に基づいてターゲットリソースを決定してもよい。例えば、端末デバイス１２０は、基準ＴＲＰ、例えば、第１のＴＲＰ１３１に従うように構成されてもよい。ＴＲＰの優先順位は、例えば、ＴＲＰＩＤなどの他の基準に基づいて決定されてもよい。より低いＴＲＰ ＩＤ値を有するＴＲＰは、より高い優先順位を有することができる。

【0066】

端末デバイス１２０によって選択されていない送信は、部分的に又は全体としてドロップされてもよい。図５は、本開示のいくつかの実施形態にかかるスケジュールされたアップリンク送信を部分的にドロップする模式図５００を示す。図５に示すように、第１のＴＲＰ１３１を介して受信したＤＣＩ５０１は、アップリンクリソース５２１を示し、第２のＴＲＰ１３２を介して受信したＤＣＩ５０２は、ダウンリンクリソース５２２を示す。ダウンリンクリソース５２２は、端末デバイス１２０によってターゲットリソースとして決定される。

【0067】

図示のように、アップリンクリソース５２１の開始シンボルは、ダウンリンクリソース５２２の開始シンボルの前にある。このような場合、端末デバイス１２０は、アップリンクリソース５２１でのスケジュールされた送信を部分的にドロップしてもよい。アップリンク送信には、端末デバイス１２０の処理能力に応じて決定されるＵＬ準備時間が必要である。その結果、ＵＬ準備時間内に、アップリンク送信がリソース５２１の最初の部分５３１で実行されてもよい。ＵＬ準備時間が経過した後、端末デバイス１２０は、リソース５２１の残りの部分５３２による送信をキャンセルし、ダウンリンクリソース５２２の残りの部分５３４で受信を実行してもよい。このように、リソース５２２の最初の部分５３３による受信は実行されない。

【0068】

図６は、本開示のいくつかの実施形態にかかるスケジュールされたダウンリンク送信をドロップする模式図６００を示す。図６に示すように、第１のＴＲＰ１３１を介して受信されたＤＣＩ６０１はダウンリンクリソース６２１を示し、第２のＴＲＰ１３２を介して受信されたＤＣＩ６０２はアップリンクリソース６２２を示す。アップリンクリソース６２２は、端末デバイス１２０によってターゲットリソースとして決定される。図５に示す実施形態とは異なり、少なくともオーバーラップしているリソースのシンボルにおいて、ダウンリンクリソース６２１でのスケジュールされた送信はドロップされ、また、スケジュールされたアップリンク送信はリソース６２２で実行される。

【0069】

上記したように、場合によってはＵＬ衝突が発生することがある。ここで、ＵＬ衝突を対処する方法の詳細を、表２及び図７Ａ～図７Ｃを参照して説明する。

【0070】

表２は、マルチＴＲＰでのＵＬ衝突の例、及び、それに対応する端末デバイス１２０の動作をまとめたものである。上記したように、いくつかのシナリオでは、ネットワークデバイスに接続されている複数のＴＲＰは互いに同等なものではなく、複数のＴＲＰのうちの１つが基準ＴＲＰ（略してＲｅｆ ＴＲＰ）として使用されてもよい。説明の目的のために、図１を参照して表２を説明し、第１のＴＲＰ１３１をＲｅｆ ＴＲＰとみなす。

【0071】

表２において、第１列は、Ｒｅｆ ＴＲＰからの指示に基づいて決定されたシンボルタイプを示し、第２列は、他のＴＲＰからの指示に基づいて決定されたシンボルタイプを示す。表２から分かるように、シンボルタイプは、上記したように「ＲＲＣ Ｕ」及び「Ｄｙｎａｍｉｃ Ｕ」を含んでもよい。第３列は、端末デバイス１２０の対応動作を示す。
表２ マルチＴＲＰでのＵＬ衝突の例

【表2】

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

いくつかの実施形態では、アクティブ化指示及び／又は非アクティブ化指示は、媒体アクセス制御（ＭＡＣ：ｍｅｄｉａ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）制御要素（ＣＥ：ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）に含まれてもよい。指示は、媒体アクセス制御層からの制御要素、即ち、ＭＡＣ ＣＥを介して送信されることができ、この制御要素は、表３に示すように、以下のフィールドのいずれかを含むことができる。
表３ ＴＲＰのアクティブ化及び非アクティブ化のためのＭＡＣ ＣＥ

【表3】

【0098】

「Ａ／Ｄ」フィールドは、ＭＡＣ ＣＥが、示されたＴＲＰをアクティブ化にするために使用されるか、非アクティブ化にするために使用されるかを示し、このフィールドは、アクティブ化を示すために「１」に設定され、それ以外の場合に、非アクティブ化を示す。「セルＩＤ」フィールドは、ＭＡＣ ＣＥが適用されるサービングセルのＩＤを示すものであり、５ビットのサイズを有してもよい。「ＢＷＰ ＩＤ」フィールドは、ＭＡＣ ＣＥが適用されるダウンリンク帯域幅部分を示すものであり、２ビットのサイズを有してもよい。「ＴＲＰ ＩＤ」フィールドは、ＭＡＣ ＣＥが適用される１つ又は複数のＴＲＰを示し、２ビットのサイズを有してもよい。「Ｒ」フィールドは、予約ビットを意味する。なお、表３に示すＭＡＣ ＣＥフォーマットは、本開示の範囲を制限することなく、説明の目的のみであることに注意されたい。他のＭＡＣ ＣＥフォーマットも可能である。

【0099】

代替的又は追加的に、第２のＴＲＰ１３２がアクティブ化されている期間を決定するために、端末デバイス１２０によって第２のＴＲＰ１３２用のタイマーを維持してもよい。

【0100】

第２のＴＲＰ１３２がアクティブ化されているタイマー期間（時刻９５１から時刻９５２まで）、端末デバイス１２０は、ＣＯＲＥＳＥＴ９１３及び９１４（ＣＯＲＥＳＥＴ９２３及び９２４はドロップされる）でのＰＤＣＣＨを監視するだけでなく、ＣＯＲＥＳＥＴ９０３及び９０４でのＰＤＣＣＨも監視する。

【0101】

時間的にオーバーラップしている探索空間をドロップするための任意のルールは、異なるＴＲＰ間ではなく、ＴＲＰごとに適用されてもよい。例えば、図９に模式的に示すように、ＣＯＲＥＳＥＴ９０３、９１３、９２３は、時間的にオーバーラップしているので、互いに衝突する可能性がある。ＣＯＲＥＳＥＴ９１３及び９２３は、第１のＴＲＰ１３１に関連付けられており、ＣＯＲＥＳＥＴ９０３は、第２のＴＲＰ１３２に関連付けられている。１つの同じＴＲＰに関連付けられた複数のＣＯＲＥＳＥＴについては、衝突を解決するために、より低い優先順位を有するＣＯＲＥＳＥＴ（及び／又はこのＣＯＲＥＳＥＴに関連付けられた探索空間）をドロップする必要がある。例えば、第１のＴＲＰ１３１に関連付けられたＣＯＲＥＳＥＴ９２３は、ＣＯＲＥＳＥＴ９０３よりも高い優先順位を有するかもしれないが、ＣＯＲＥＳＥＴ９０３は、別のＴＲＰ、即ち、この例では第２のＴＲＰ１３１に関連付けられているので、ＣＯＲＥＳＥＴ９２３をドロップする必要がある。

【0102】

さらに、ＤＣＩにおけるＡＣＫ／ＮＡＣＫリソースインジケータ（ＡＲＩ：ＡＣＫ／ＮＡＣＫ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）は、ＤＣＩのＡＣＫ／ＮＡＣＫビットを送信するためのＰＵＣＣＨを選択するために使用される。異なるＤＣＩによるＡＣＫ／ＮＡＣＫビットを同一のスロットで送信する必要がある場合、ＡＣＫ／ＮＡＣＫビットのＰＵＣＣＨ送信を選択するためのＡＲＩは、異なるＴＲＰ間ではなく、ＴＲＰごとに決定されてもよい。例えば、図９に模式的に示すように、第１のＴＲＰ１３１について、最終ＡＲＩ９１６は、例えば第１のＴＲＰ１３１に関連付けられたＣＯＲＥＳＥＴ９１３及び９１４で受信された最後のＤＣＩに基づいて決定される。第２のＴＲＰ１３２について、最終ＡＲＩ９０６は、例えば第２のＴＲＰ１３２に関連付けられたＣＯＲＥＳＥＴ９０３及び９０４で受信された最後のＤＣＩに基づいて決定される。

【0103】

図１０は、本開示のいくつかの実施形態にかかる例示的な方法１０００のフローチャートを示す。方法１０００は、図１に示す端末デバイス１２０で実施されることができる。方法１０００は、図示されない追加のブロックを含んでもよく、及び／又は図示されているいくつかのブロックを省略してもよく、本開示の範囲はこの点で限定されないことを理解されたい。説明の目的のために、図１を参照して方法１０００を説明する。

【0104】

ブロック１０１０において、端末デバイス１２０は、ネットワークデバイス１１０から指示を受信する。端末デバイス１２０は、ネットワークデバイス１１０に接続されている第１のＴＲＰ１３１を介して、ネットワークデバイス１１０と通信している。

【0105】

ブロック１０２０において、端末デバイス１２０は、指示がネットワークデバイス１１０に接続されている第２のＴＲＰ１３２のアクティブ化を示すか否かを決定する。端末デバイス１２０は、指示が第２のＴＲＰ１３２のアクティブ化を示すと決定した場合、処理はブロック１０３０に進む。ブロック１０３０において、端末デバイス１２０は、第２のＴＲＰ１３２を介してネットワークデバイス１１０との通信を実行する。

【0106】

いくつかの実施形態では、指示は、ＭＡＣ ＣＥに含まれる。

【0107】

図１１は、本開示のいくつかの実施形態にかかる例示的な方法１１００のフローチャートを示す。方法１１００は、図１に示すネットワークデバイス１１０で実施されることができる。方法１１００は、図示されない追加のブロックを含んでもよく、及び／又は図示されているいくつかのブロックを省略してもよく、本開示の範囲はこの点で限定されないことを理解されたい。説明の目的のために、図１を参照して方法１１００を説明する。

【0108】

ブロック１１１０において、ネットワークデバイス１１０は、端末デバイス１２０に送信される指示を決定する。端末デバイス１２０は、ネットワークデバイス１１０に接続されている第１のＴＲＰ１３１を介してネットワークデバイス１１０と通信しており、指示は、ネットワークデバイス１１０に接続されている第２のＴＲＰ１３２のアクティブ化を示す。

【0109】

ブロック１１２０において、ネットワークデバイス１１０は、指示を端末デバイス１２０に送信する。ブロック１１３０において、ネットワークデバイス１１０は、第２のＴＲＰ１３１を介して、端末デバイス１２０との通信を実行する。

【0110】

図１２は、本開示のいくつかの実施形態の実施に適したデバイス１２００の簡略化したブロック図である。デバイス１２００は、図１に示すネットワークデバイス１１０又は端末デバイス１２０のさらなる例示的な実施形態とみなすことができる。従って、デバイス１２００は、ネットワークデバイス１１０或いは端末デバイス１２０の少なくとも一部で実施され、又はネットワークデバイス１１０或いは端末デバイス１２０の少なくとも一部として実施されることができる。

【0111】

図示されるように、デバイス１２００は、プロセッサ１２１０と、プロセッサ１２１０に接続されているメモリ１２２０と、プロセッサ１２１０に接続されている適切な送信機（ＴＸ）及び受信機（ＲＸ）１２４０と、ＴＸ／ＲＸ１２４０に接続されている通信インターフェースとを含む。メモリ１２２０は、プログラム１２３０の少なくとも一部を格納する。ＴＸ／ＲＸ１２４０は、双方向通信用である。ＴＸ／ＲＸ１２４０は、通信を容易にするために少なくとも１つのアンテナを有するが、実際には、本願で言及されるアクセスノードは複数のアンテナを有してもよい。通信インターフェースは、ｅＮＢ間の双方向通信用のＸ２インターフェース、モビリティマネジメントエンティティ（ＭＭＥ：Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／サービングゲートウェイ（Ｓ－ＧＷ：Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）とｅＮＢとの間の通信用のＳ１インターフェース、ｅＮＢとリレーノード（ＲＮ：ｒｅｌａｙ ｎｏｄｅ）との間の通信用のＵｎインターフェース、又はｅＮＢと端末デバイスとの間の通信用のＵｕインターフェースなど、他のネットワーク要素との通信に必要な任意のインターフェースを表してもよい。

【0112】

プログラム１２３０は、関連するプロセッサ１２１０によって実行されると、デバイス１２００が、本明細書で図３、図１０及び図１１を参照して説明したように、本開示の実施形態に従って動作することを可能にするプログラム命令を含むと想定される。本明細書の実施形態は、デバイス１２００のプロセッサ１２１０によって実行可能なコンピュータソフトウェアにより、又はハードウェアにより、又はソフトウェアとハードウェアとの組み合わせにより実施されてもよい。プロセッサ１２１０は、本開示の様々な実施形態を実施するように構成されてもよい。さらに、プロセッサ１２１０とメモリ１２２０の組み合わせは、本開示の様々な実施形態の実施に適した処理手段１２５０を形成してもよい。

【0113】

メモリ１２２０は、ローカル技術ネットワークに適した任意のタイプのものであってもよく、非限定的な例として、非一時的コンピュータ読み取り可能な記憶媒体、半導体系のメモリデバイス、磁気メモリデバイス及びシステム、光メモリデバイス及びシステム、固定メモリデバイス及びリムーバブルメモリなどの任意の適切なデータ記憶技術を使用して実施されてもよい。デバイス１２００には１つのメモリ１２２０のみが示されているが、デバイス１２００には物理的に別個である複数のメモリモジュールがあってもよい。プロセッサ１２１０は、ローカル技術ネットワークに適した任意のタイプのものであってもよく、非限定的な例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、及びマルチコアプロセッサアーキテクチャに基づくプロセッサのうちの１つ又は複数を含んでもよい。デバイス１２００は、メインプロセッサを同期させるクロックに時間的に従属する特定用途向け集積回路チップなどの複数のプロセッサを有してもよい。

【0114】

一般的に、本開示の様々な実施形態は、ハードウェア又は専用回路、ソフトウェア、ロジック、又はそれらの任意の組み合わせで実施されてもよい。いくつかの態様はハードウェアで実施され、他の態様はコントローラ、マイクロプロセッサ、又は他のコンピューティングデバイスによって実行され得るファームウェア又はソフトウェアで実施されてもよい。本開示の実施形態の様々な態様は、ブロック図、フローチャート、又は他の何らかの画像表現を使用して例示及び説明されたが、本明細書に記載されるこれらのブロック、装置、システム、技術又は方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路又はロジック、汎用ハードウェア又はコントローラ又は他のコンピューティングデバイス、又はそれらのいくつかの組み合わせで実施されてもよいことを理解されたい。

【0115】

本開示は、さらに、非一時的なコンピュータ読み取り可能な記憶媒体に有形に格納された少なくとも１つのコンピュータプログラム製品を提供する。コンピュータプログラム製品は、図２、図３、図８、図１０及び図１１を参照して上記したプロセス又は方法を実行するために、プログラムモジュールに含まれるものなどの、対象の実プロセッサ又は仮想プロセッサ上のデバイスで実行されるコンピュータ実行可能な命令を含む。一般的に、プログラムモジュールは、特定のタスクを実行したり、特定の抽象データ型を実施したりするルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、データ構造などを含む。プログラムモジュールの機能は、様々な実施形態で記載されたプログラムモジュール間で組み合わせる、又は分割されることができる。プログラムモジュールのためのマシン実行可能な命令は、ローカルデバイス又は分散型デバイス内で実行されてもよい。分散型デバイスでは、プログラムモジュールがローカル記憶媒体とリモート記憶媒体の両方に配置されてもよい。

【0116】

本開示の方法を実行するためのプログラムコードは、１つ又は複数のプログラミング言語の任意の組み合わせで書かれてもよい。これらのプログラムコードは、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能なデータ処理装置のプロセッサ又はコントローラに提供されることにより、プログラムコードがプロセッサ又はコントローラによって実行されると、フローチャート及び／又はブロック図に規定される機能／動作が実現される。プログラムコードは、完全にマシンで実行されてもよく、その一部がマシンで実行されてもよく、スタンドアロンのソフトウェアパッケージとして実行されてもよく、一部がマシンで実行され且つ一部がリモートマシンで実行されてもよく、完全にリモートマシン又はサーバで実行されてもよい。

【0117】

上記プログラムコードは、命令実行システム、装置、又はデバイスによって、又はそれと関連して使用されるためのプログラムを含む、又は格納することができる任意の有形媒体であり得るマシン読み取り可能な媒体で具現化されてもよい。マシン読み取り可能な媒体は、マシン読み取り可能な信号媒体又はマシン読み取り可能な記憶媒体であってもよい。マシン読み取り可能な媒体は、電子、磁気、光学、電磁気、赤外線、又は半導体システム、装置、デバイス、あるいは前記の任意の適切な組み合わせを含むが、これらに限定されない。マシン読み取り可能な記憶媒体のより具体的な例として、１つ又は複数のワイヤによる電気的接続、ポータブルコンピュータディスケット、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、消去可能なプログラム可能な読み取り専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）、光ファイバー、ポータブルコンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、光学式ストレージデバイス、磁気ストレージデバイス、又は前記の任意の適切な組み合わせが挙げられる。

【0118】

さらに、動作が特定の順序で描かれているが、これは、望ましい結果を達成するために、そのような動作が図示の特定の順序又は連続順序で実行されること、又はすべての描かれた動作が実行されることを要求するものとして理解されるべきではない。特定の状況では、マルチタスク及び並列処理が有利である場合がある。同様に、上記の説明にはいくつかの特定の実施形態の詳細が含まれているが、これらは本開示の範囲を限定するものとして解釈されるべきではなく、特定の実施形態に特有の特徴の説明として解釈されるべきである。別々の実施形態の文脈で説明されている特定の特徴は、単一の実施形態に組み合わせて実施されてもよい。逆に、単一の実施形態の文脈で説明されている様々な特徴も、複数の実施形態で別々に、又は任意の適切なサブコンビネーションで実施されてもよい。

【0119】

本開示は、構造的特徴及び／又は方法論的動作に特有の用語で説明されたが、添付の特許請求の範囲で限定される本開示は、必ずしも上記した特定の特徴又は動作に限定されないことを理解されたい。むしろ、上記した特定の特徴及び動作は、特許請求の範囲を実施する例示的な形態として開示されている。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図4C】

【図5】

【図6】

【図7A】

【図7B】

【図7C】

【図8】

【図9】

【図10】

【図11】

【図12】