(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-04-03
(54)【発明の名称】通信の方法、端末装置及びコンピュータ可読媒体
(51)【国際特許分類】
H04W 72/40 20230101AFI20240327BHJP
H04W 72/02 20090101ALI20240327BHJP
H04W 72/0446 20230101ALI20240327BHJP
H04W 52/02 20090101ALI20240327BHJP
H04W 92/18 20090101ALI20240327BHJP
【FI】
H04W72/40
H04W72/02
H04W72/0446
H04W52/02 110
H04W92/18
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023560940
(86)(22)【出願日】2021-04-02
(85)【翻訳文提出日】2023-12-01
(86)【国際出願番号】 CN2021085382
(87)【国際公開番号】W WO2022205449
(87)【国際公開日】2022-10-06
(81)【指定国・地域】
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
(71)【出願人】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100103894
【氏名又は名称】家入 健
(72)【発明者】
【氏名】ミャオ ジャオバン
(72)【発明者】
【氏名】ワン ガン
【テーマコード(参考)】
5K067
【Fターム(参考)】
5K067AA21
5K067CC22
5K067DD34
5K067EE02
5K067EE25
5K067EE72
(57)【要約】
本開示の実施形態は、サイドリンク送信のための解決策を提供する。通信のための方法において、第1の端末装置は、第1の端末装置から第2の端末装置へのサイドリンク送信のためのリソース選択ウィンドウを決定する。次に、第1の端末装置は、該リソース選択ウィンドウ内の継続時間を決定する。さらに、第1の端末装置は、継続時間のないリソース選択ウィンドウにおいて、サイドリンク送信のための少なくとも1つのリソースを決定する。こうして、サイドリンク送信のための第1の端末装置のリソース選択ウィンドウが最適化されるため、サイドリンク送信の性能が改善される。
【選択図】
図2
【特許請求の範囲】
【請求項1】
第1の端末装置において、前記第1の端末装置から第2の端末装置へのサイドリンク送信のためのリソース選択ウィンドウを決定することと、
前記リソース選択ウィンドウ内の継続時間を決定することと、
前記継続時間のない前記リソース選択ウィンドウ内で、前記サイドリンク送信のための少なくとも1つのリソースを決定することと、
を含む通信の方法。
【請求項2】
前記継続時間を決定することは、
前記第2の端末装置のサイドリンク不連続受信(DRX:discontinuous reception)設定に基づいて前記継続時間を決定すること
を含む請求項1に記載の方法。
【請求項3】
前記サイドリンクDRX設定に基づいて前記継続時間を決定することは、
前記サイドリンク送信が前記第2の端末装置へのユニキャストサイドリンク送信であるとの決定に従って、前記第2の端末装置の前記DRX設定のオフ継続時間を前記継続時間として決定すること
を含む請求項2に記載の方法。
【請求項4】
前記サイドリンクDRX設定に基づいて前記継続時間を決定することは、
前記サイドリンク送信が、前記第2の端末装置を含む複数の端末装置へのグループキャスト又はブロードキャストサイドリンク送信であるとの決定に従って、前記複数の端末装置のそれぞれのサイドリンクDRX設定の複数のオフ継続時間を決定することと、
前記複数のオフ継続時間の共通オフ継続時間又は結合オフ継続時間を前記継続時間として決定することと、
を含む請求項2に記載の方法。
【請求項5】
前記第1の端末装置からの前のサイドリンク送信が、前記継続時間のないリソース選択ウィンドウの残りの部分内のスロットに関連付けられたセンシングオケージョン内で実行されたとの決定に従って、前記スロットを前記リソース選択ウィンドウの残りの部分から除外すること
をさらに含む請求項1に記載の方法。
【請求項6】
前記継続時間のない前記リソース選択ウィンドウの残りの部分内のスロットの数が閾値よりも少ないとの決定に従って、前記リソース選択ウィンドウの残りの部分を拡張すること
をさらに含む請求項1に記載の方法。
【請求項7】
前記閾値は、
前記第1の端末装置の上位層により事前設定又は設定された値と、
前記上位層により事前設定又は設定される、前記リソース選択ウィンドウ内のスロットの最小数と、
前記最小数と前記サイドリンク送信の再送信のラウンドトリップ時間のためのスロットの数との和と、
のうちの1つである請求項6に記載の方法。
【請求項8】
前記リソース選択ウィンドウの残りの部分を拡張することは、
前記リソース選択ウィンドウの残りの部分の開始時点を早めることと、
前記リソース選択ウィンドウの残りの部分の終了時点を遅延させることと、
のうちの少なくとも1つを含む請求項6に記載の方法。
【請求項9】
前記リソース選択ウィンドウの残りの部分を拡張することは、
前記継続時間が短縮又は除去されるように、前記第2の端末装置の調節されたサイドリンクDRX設定を決定することと、
前記調節されたサイドリンクDRX設定の指示を前記第2の端末装置に送信することと、
を含む請求項6に記載の方法。
【請求項10】
前記少なくとも1つのリソースを決定することは、
前記継続時間のない前記リソース選択ウィンドウの残りの部分から、前記サイドリンク送信のための複数の候補リソースを選択することと、
前記複数の候補リソースをセンシングすることにより、前記複数の候補リソースの中から、前記サイドリンク送信のための複数の利用可能なリソースを決定することと、
前記複数の利用可能なリソースから、前記少なくとも1つのリソースを選択することと、
を含む請求項1に記載の方法。
【請求項11】
前記複数の利用可能なリソースは、連続するスロットの複数のサブセット内に位置し、前記少なくとも1つのリソースを選択することは、
前記複数のサブセット内のサブセットから、リソースを、前記リソースと前記サブセットの最後のスロットとの間の時間領域でのギャップが前記サイドリンク送信の再送信のラウンドトリップ時間よりも長いように、前記少なくとも1つのリソースのうちの1つとして選択することと、
前記複数のサブセット内のサブセットから、前記サブセット内の最も早いリソースを、前記少なくとも1つのリソースのうちの1つとして選択することと、
のうちの少なくとも1つを含む請求項10に記載の方法。
【請求項12】
前記第2の端末装置のサイドリンクDRX設定が前記サイドリンク送信にとって不適切であるとの決定に従って、前記第2の端末装置の調節されたサイドリンクDRX設定を決定することと、
前記調節されたサイドリンクDRX設定の指示を前記第2の端末装置に送信することと、
をさらに含む請求項2に記載の方法。
【請求項13】
前記第2の端末装置のサイドリンクDRX設定が不適切であると決定することは、
前記継続時間のない前記リソース選択ウィンドウの残りの部分内のリソースの総数が前記サイドリンク送信にとって不十分であると決定することと、
前記リソース選択ウィンドウの残りの部分内に、前記サイドリンク送信の再送信のために利用可能なリソースがないと決定することと、
前記リソース選択ウィンドウの残りの部分内で部分的センシングを実行することにより決定された、前記リソース選択ウィンドウの残りの部分内の利用可能なリソースの数が、前記サイドリンク送信にとって不十分であると決定することと、
のうちの少なくとも1つを含む請求項12に記載の方法。
【請求項14】
前記少なくとも1つのリソースを決定することは、
前記継続時間のない前記リソース選択ウィンドウの残りの部分内で、前記第1の端末装置のサイドリンクDRX設定のオン継続時間内に位置するそれぞれのセンシングオケージョンに関連付けられるスロットのセットを決定することと、
前記スロットのセットから前記少なくとも1つのリソースを決定することと、
を含む請求項1に記載の方法。
【請求項15】
前記スロットのセットを決定することは、
前記第1の端末装置の下位層に、前記スロットのセットを決定させること
を含む請求項14に記載の方法。
【請求項16】
前記スロットのセットから前記少なくとも1つのリソースを決定することは、
前記下位層に、前記スロットのセット内の利用可能なリソースを前記第1の端末装置の上位層に報告させることと、
前記上位層に、前記利用可能なリソースから前記少なくとも1つのリソースを選択させることと、
を含む請求項15に記載の方法。
【請求項17】
前記スロットのセットを決定することは、
前記第1の端末装置の上位層に、前記スロットのセットを決定させること
を含む請求項14に記載の方法。
【請求項18】
前記スロットのセットから前記少なくとも1つのリソースを決定することは、
前記第1の端末装置の下位層に、前記リソース選択ウィンドウの残りの部分内の候補リソースを報告させることと、
前記上位層に、前記候補リソースから、前記スロットのセット内に位置する前記少なくとも1つのリソースを選択させることと、
を含む請求項17に記載の方法。
【請求項19】
前記スロットのセットを決定することは、
前記サイドリンク送信に関連付けられるトラフィック優先度が優先度閾値よりも高いとの決定に従って、前記スロットのセットを決定すること
を含む請求項14に記載の方法。
【請求項20】
第2の端末装置において第1の端末装置から、前記第1の端末装置から前記第2の端末装置へのサイドリンク送信のキャストタイプ情報を受信することと、
前記キャストタイプ情報に基づいて、前記サイドリンク送信の間の前記第2の端末装置のサイドリンク不連続受信(DRX)の有効化設定を決定することと、
を含む通信の方法。
【請求項21】
前記有効化設定を決定することは、
前記キャストタイプ情報が、前記サイドリンク送信がユニキャストサイドリンク送信であることを示すとの決定に従って、前記サイドリンク送信の間、前記サイドリンクDRXを有効化すること
を含む請求項20に記載の方法。
【請求項22】
前記有効化設定を決定することは、
前記キャストタイプ情報が、前記サイドリンク送信がグループキャスト又はブロードキャストサイドリンク送信であることを示すとの決定に従って、前記サイドリンク送信の間、前記サイドリンクDRXを無効化すること、
を含む請求項20に記載の方法。
【請求項23】
前記第2の端末装置のサイドリンクDRX設定が、前記サイドリンク送信のためにリソースが選択されたリソースプールについて事前設定又は設定されるとの決定に従って、前記キャストタイプ情報に関係なく、前記サイドリンク送信の間、前記サイドリンクDRXを有効化すること
をさらに含む請求項20に記載の方法。
【請求項24】
請求項1~19の何れか一項に記載の方法を実行するように設定されたプロセッサを備える
第1の端末装置。
【請求項25】
請求項20~23の何れか一項に記載の方法を実行するように設定されたプロセッサを備える
第2の端末装置。
【請求項26】
装置の少なくとも一つのプロセッサ上で実行された場合、前記装置に、請求項1~19の何れか一項に記載の方法を実行させる命令を記憶した
コンピュータ可読媒体。
【請求項27】
装置の少なくとも一つのプロセッサ上で実行された場合、前記装置に、請求項20~23の何れか一項に記載の方法を実行させる命令を記憶した
コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示の実施形態は、全体として通信の分野に関し、より具体的には、サイドリンク送信のための解決策に関する。
【背景技術】
【0002】
5G New Radio(NR)は、統一されたより高性能な5G無線エアインターフェースについての世界規格である。5Gは、マシンやモノ、装置など、ほぼ全ての人とあらゆるものを一つにつなぐように設計された新たな種類のネットワークを実現している。5G NRは、遅延、信頼性、セキュリティ、スケーラビリティ(例えば、モノのインターネットの場合)及び他の要件に関連付けられる新しい要件を満たすように、第3世代パートナープロジェクト(3GPP:Third Generation Partnership Project)により公布された継続的なモバイルブロードバンドエボリューションの一部である。5G NRのいくつかの側面は、4Gロングタームエボリューション(LTE:Long Term Evolution)規格に基づいてもよい。
【0003】
LTE車両対あらゆるもの(V2X:vehicle-to-everything)では、UEが部分的センシングを実行するとき、UEは、自身の実装により、リソース選択ウィンドウ内で少なくともY個のサブフレームからなるサブフレームのセットを決定する。Yは、上位層パラメータminNumCandidateSF以上でなければならない。上記のステップにおけるY個のサブフレームのセットにサブフレームt_yが含まれる場合、上位層パラメータgapCandidateSensingのk番目ビットが1にセットされている場合、UEは任意のサブフレームt_y-k*pを監視すべきである。UEは、復号化された物理サイドリンク制御チャネル(PSCCH:Physical Sidelink Control Channel)及びこれらのサブフレーム内で測定されたサイドリンク受信信号強度インジケータ(S-RSSI:Sidelink Received Signal Strength Indicator)に基づいて、リソース除外行動、すなわち関連する3GPP仕様で定義されているセンシングプロシージャを実行すべきである。しかしながら、いくつかのサイドリンク通信シナリオにおいて、UEの部分的センシングプロシージャにおけるリソース選択ウィンドウを最適化する必要があるかもしれない。
【発明の概要】
【発明が解決しようとする課題】
【0004】
全体として、本開示の実施形態は、サイドリンク送信のための解決策を提供する。
【課題を解決するための手段】
【0005】
第1の態様において、通信方法が提供される。前記方法は、第1の端末装置において、前記第1の端末装置から第2の端末装置へのサイドリンク送信のためのリソース選択ウィンドウを決定することを含む。前記方法は、前記リソース選択ウィンドウ内の継続時間を決定することも含む。前記方法は、前記継続時間のない前記リソース選択ウィンドウ内で、前記サイドリンク送信のための少なくとも1つのリソースを決定することをさらに含む。
【0006】
第2の態様において、通信方法が提供される。前記方法は、第2の端末装置において第1の端末装置から、前記第1の端末装置から前記第2の端末装置へのサイドリンク送信のキャストタイプ情報を受信することを含む。前記方法は、前記キャストタイプ情報に基づいて、前記サイドリンク送信の間の前記第2の端末装置のサイドリンク不連続受信(DRX:discontinuous reception)の有効化設定を決定することを含む。
【0007】
第3の態様において、第1の端末装置が提供される。前記第1の端末装置は、前記第1の態様にかかる方法を実行するように設定されたプロセッサを備える。
【0008】
第4の態様において、第2の端末装置が提供される。前記第2の端末装置は、前記第2の態様にかかる方法を実行するように設定されたプロセッサを備える。
【0009】
第5の態様において、命令を記憶したコンピュータ可読媒体が提供される。前記命令は、装置の少なくとも1つのプロセッサ上で実行された場合、前記装置に第1の態様にかかる方法を実行させる。
【0010】
第6の態様において、命令を記憶したコンピュータ可読媒体が提供される。前記命令は、装置の少なくとも1つのプロセッサ上で実行された場合、前記装置に第2の態様にかかる方法を実行させる。
【0011】
発明の概要部分は、本開示の実施形態の重要又は基本的な特徴を特定することも、本開示の範囲を限定することも意図していないことを理解すべきである。本開示のその他の特徴は、以下の説明により容易に理解できるはずである。
【図面の簡単な説明】
【0012】
図面において本開示のいくつかの実施形態をさらに詳細に説明することで、本開示の上述の及びその他の目的、特徴及び利点を、さらに明らかにする。
【0013】
【
図1A】本開示のいくつかの実施形態を実施可能な例示的な通信環境の模式図である。
【0014】
【
図1B】本開示のいくつかの実施形態を実施可能な別の例示的な通信環境の模式図である。
【0015】
【
図2】本開示のいくつかの実施形態にかかる通信方法の例示的なプロセスを示す図である。
【0016】
【
図3】本開示のいくつかの実施形態にかかる、サイドリンク送信の受信端末装置のオフ継続時間のない、送信端末装置からのサイドリンク送信のためのリソース選択ウィンドウを示す模式図である。
【0017】
【
図4A】本開示のいくつかの実施形態にかかる、グループキャスト又はブロードキャストサイドリンク送信の複数の受信端末装置の共通オフ継続時間及び結合オフ継続時間を示す模式図である。
【0018】
【
図4B】本開示のいくつかの実施形態にかかる、グループキャスト又はブロードキャストサイドリンク送信の複数の受信端末装置の共通オン継続時間及び結合オン継続時間を示す模式図である。
【0019】
【
図5】本開示のいくつかの実施形態にかかる、パーシャルリソース選択ウィンドウがより多くのスロットを含むように拡張されていることを示す模式図である。
【0020】
【
図6】本開示のいくつかの実施形態にかかる、送信端末装置から受信端末装置へのサイドリンク送信のための1つ又は複数のリソースを選択するための例示的なプロセスを示す図である。
【0021】
【
図7A】本開示のいくつかの実施形態にかかる、リソースがサイドリンク送信のために選択された場合、サイドリンク送信の再送信のために利用可能なリソースが存在しない可能性を示す模式図である。
【
図7B】本開示のいくつかの実施形態にかかる、リソースがサイドリンク送信のために選択された場合、サイドリンク送信の再送信のために利用可能なリソースが存在しない可能性を示す模式図である。
【0022】
【
図8】本開示のいくつかの実施形態にかかる、サイドリンク送信の送信端末装置が、送信端末装置のオン継続時間内に位置するセンシングオケージョンに関連付けられたスロット内で候補リソースを選択することができることを示す模式図である。
【0023】
【
図9】本開示のいくつかの実施形態にかかる、第1の端末装置と第2の端末装置との間の例示的な通信プロセスを示す図である。
【0024】
【
図10】本開示のいくつかの実施形態にかかる別の通信方法の例示的なプロセスを示す図である。
【0025】
【
図11】本開示のいくつかの実施形態を実装するのに適した装置の概略ブロック図である。
【0026】
図面において、同一又は類似の参照番号は、同一又は類似の要素を表す。
【発明を実施するための形態】
【0027】
いくつかの実施形態を参照して、本開示の原理を説明する。これらの実施形態は、説明のためにのみ記載され、当業者が本開示を理解し、実施するのを助けるものであり、本開示の範囲に関するいかなる限定も示唆しないことを理解すべきである。本明細書で説明される開示内容は、以下で説明される方法とは異なる様々な方法で実施することができる。
【0028】
以下の説明及び特許請求の範囲において、別途定義されていない限り、本文で使用される全ての技術的及び科学的用語は、本開示の当業者が一般に理解するものと同一の意味を有する。
【0029】
本文で使用される「ネットワーク装置」又は「基地局」(BS:base station)という用語は、端末装置が通信を実行可能なセル又はカバレッジを提供又はホストすることのできる装置を意味する。ネットワーク装置の例としては、ノードB(NodeB又はNB)、EvolvedノードB(eNodeB又はeNB)、次世代ノードB(gNB)、V2X(vehicle-to-everything)通信のためのインフラ装置、送受信ポイント(TRP:Transmission/Reception Point)、リモートラジオユニット(RRU:Remote Radio Unit)、ラジオヘッド(RH:radio head)、リモートラジオヘッド(RRH:remote radio head)、フェムトノード、ピコノードなどの低電力ノードを含むが、これらに限定されない。
【0030】
本文で使用されるように、用語「端末装置」は、無線又は有線の通信能力を有する任意の装置を意味する。端末装置の例としては、ユーザ装置(UE:user equipment)、パーソナルコンピュータ、デスクトップコンピュータ、携帯電話、セルラーホン、スマートフォン、パーソナルデジタルアシスタント(PDA:personal digital assistant)、ポータブルコンピュータ、タブレット、ウェアラブル装置、モノのインターネット(IoT:internet of things)装置、あらゆるモノのインターネット(IoE:Internet of Everything)装置、マシンタイプ通信(MTC:machine type communication)装置、V2X(「X」は歩行者、車両又はインフラストラクチャ/ネットワーク、あるいはデジタルカメラなどの画像取得装置、ゲーム装置、音楽保存及び再生装置、あるいは無線又は有線のインターネットアクセス及び閲覧を可能とするインターネット家電などを表す)通信のための車載装置などを含むが、これらに限定されない。以下、説明のために、UEを端末装置の例として参照していくつかの実施形態を説明し、用語「端末装置」及び「ユーザ装置」(UE)は、本開示のコンテキストにおいて互換的に使用されることができる。
【0031】
いくつかの実施形態において、端末装置は、第1のネットワーク装置及び第2のネットワーク装置に接続されることができる。第1のネットワーク装置と第2のネットワーク装置の一方をマスターノードとして、他方をセカンダリ―ノードとしてもよい。第1のネットワーク装置と第2のネットワーク装置は、異なる無線アクセス技術(RAT:radio access technology)を使用してもよい。いくつかの実施形態において、第1のネットワーク装置は第1のRAT装置であってもよく、第2のネットワーク装置は第2のRAT装置であってもよい。いくつかの実施形態において、第1のRAT装置はeNBであり、第2のRAT装置はgNBである。異なるRATに関する情報は、第1のネットワーク装置と第2のネットワーク装置とのうちの少なくとも一方から端末装置に送信されることができる。いくつかの実施形態において、第1の情報は、第1のネットワーク装置から端末装置に送信されてもよく、第2の情報は、第2のネットワーク装置から直接又は第1のネットワーク装置を介して端末装置に送信されてもよい。いくつかの実施形態において、第2のネットワーク装置により設定された端末装置の設定に関する情報は、第2のネットワーク装置から第1のネットワーク装置を介して送信されてもよい。第2のネットワーク装置により設定された端末装置の再設定に関する情報は、第2のネットワーク装置から直接又は第1のネットワーク装置を介して端末装置に送信されてもよい。
【0032】
本明細書で使用される用語「回路」は、ハードウェア回路及び/又はハードウェア回路とソフトウェアとの組み合わせを意味することができる。例えば、回路は、アナログ及び/又はデジタルハードウェア回路とソフトウェア/ファームウェアとの組み合わせであってもよい。さらに別の例として、回路は、端末装置又はネットワーク装置のような装置に様々な機能を実行させるために協働する、デジタル信号プロセッサ、ソフトウェア及び一つ又は複数のメモリを含むソフトウェアを有するハードウェアプロセッサの任意の部分であってもよい。さらに別の例において、回路は、オペレーションのためにソフトウェア/ファームウェアを必要とするハードウェア回路及び/又はマイクロプロセッサ又はその一部のようなプロセッサであってもよいが、オペレーションのために必要でない場合、ソフトウェアは存在しなくてもよい。本明細書で使用されるように、用語「回路」は、ハードウェア回路又は1つ又は複数のプロセッサのみ、又はハードウェア回路又は1つ又は複数のプロセッサの一部、及びその(又はそれらの)付随するソフトウェア及び/又はファームウェアの実装も含む。
【0033】
本明細書で使用されるように、用語「送受信ポイント」、「送信/受信ポイント」、又は「送信及び受信ポイント」は、一般に、ユーザ装置と通信する局を示すことができる。しかしながら、送受信ポイントは、基地局(BS)、セル、ノードB、evolvedノードB(eNB)、次世代ノードB(gNB)、送受信ポイント(TRP)、セクタ、サイト、ベーストランシーバ基地局(BTS:base transceiver system)、アクセスポイント(AP:access point)、中継ノード(RN:relay node)、遠隔無線ヘッド(RRH)、無線ユニット(RU)、アンテナなどのように、異なる用語で称されてもよい。
【0034】
すなわち、本開示の文脈では、送受信ポイント、基地局(BS)又はセルは、符号分割多元接続(CDMA:code division multiple access)における基地局コントローラ(BSC:base station controller)、WCDMAにおけるNode-B、LTEにおけるeNB又はセクタ(サイト)、NRにおけるgNB又はTRPなどによりカバーされるエリア又は機能の一部を示す包括的概念として解釈されてもよい。したがって、送受信ポイント、基地局(BS)及び/又はセルの概念は、メガセル、マクロセル、マイクロセル、ピコセル、フェムトセルなどの様々なカバレッジエリアを含んでもよい。さらに、このような概念は、中継ノード(RN)、遠隔無線ヘッド(RRH)、又は無線ユニット(RU)の通信範囲を含んでもよい。
【0035】
本開示の文脈では、ユーザ装置及び送信/受信ポイントは、本明細書で開示される技術及び技術概念を具現化するための包括的な意味を有する2つの送信/受信主体とすることができ、特定の用語又は単語に限定されない場合がある。さらに、ユーザ装置及び送信/受信ポイントは、本開示に関連して開示された技術及び技術概念を具現化する包括的な意味を有するアップリンク又はダウンリンク送信/受信主体とすることができ、特定の用語又は単語に限定されない場合がある。本明細書で使用されるように、アップリンク(UL:uplink)送信/受信は、データがユーザ装置から基地局に送信される方式である。代替として、ダウンリンク(DL:downlink)送信/受信は、基地局からユーザ装置にデータを送信する方式である。
【0036】
本明細書で使用される単数形「1つ(a/an)」、及び「前記(the)」は、文脈に明示的に示されていない限り、複数形も含まれる。用語「含む」及びその変型は、「含むが、これらに限定されるものではない」を意味するオープンエンド用語として理解されるべきである。「に基づく」という用語は、「に少なくとも部分的に基づく」と理解されるべきである。「一実施形態」及び「実施形態」という用語は、「少なくとも1つの実施形態」と理解されるべきである。「もう1つの実施形態」という用語は、「少なくとも1つの他の実施形態」と理解されるべきである。「第1」、「第2」などの用語は、異なる又は同一の対象を指してもよい。以下では、その他の明示的及び暗黙的な定義を含む場合がある。
【0037】
いくつかの例において、値、プロシージャ、又は機器は、「最良」、「最低」、「最高」、「最小」、「最大」などと称される。このような説明は、多くの使用される機能的代替案の中から選択することができることを示すことを意図されており、そして、このような選択は、他の選択より良く、より小さく、より高い必要がなく、又はそのほかの点でより好ましい必要はないことが、理解されるであろう。
【0038】
上述したように、いくつかのサイドリンク通信シナリオにおいて、UEの部分的センシングプロシージャにおけるリソース選択ウィンドウを最適化する必要があるかもしれない。従来の解決策におけるこのような技術的問題及び潜在的な他の技術的問題を解決するために、本開示の実施形態は、サイドリンク送信のための解決策を提供する。通信のための方法において、第1の端末装置は、第1の端末装置から第2の端末装置へのサイドリンク送信のためのリソース選択ウィンドウを決定する。次に、第1の端末装置は、該リソース選択ウィンドウ内の継続時間を決定する。さらに、第1の端末装置は、継続時間のないリソース選択ウィンドウにおいて、サイドリンク送信のための少なくとも1つのリソースを決定する。こうして、サイドリンク送信のための第1の端末装置のリソース選択ウィンドウが最適化されるため、サイドリンク送信の性能が改善される。以下に、本開示の原理及び実施態様について詳細に説明する。
【0039】
図1Aは本開示のいくつかの実施形態を実施可能な例示的な通信環境100の模式図である。
図1Aに示すように、通信ネットワーク100と称されてもよい通信環境100は、第1の端末装置110と第2の端末装置120とをサービングするネットワーク装置105を含んでもよい。具体的には、アップリンク送信及びダウンリンク送信は、第1の端末装置110とネットワーク装置105との間で通信リンク114を介して実行されてもよく、アップリンク送信及びダウンリンク送信は、第2の端末装置120とネットワーク装置105との間で通信リンク116を介して実行されてもよい。
【0040】
追加として、第1の端末装置110は、本明細書でサイドリンクとも称される装置間(D2D:device-to-device)リンクを介して第2の端末装置120と通信してもよい。いくつかの状況では、ネットワーク装置105は、第1の端末装置110と第2の端末装置120との間のサイドリンク通信を制御又は補助してもよい。しかしながら、いくつかのケースでは、通信環境100にネットワーク装置105が存在しなくてもよい。例えば、第1の端末装置110と、第2の端末装置120と、他の端末装置(図示せず)とのうちの1つ又は複数は、ネットワーク装置105のカバレッジ115外にあってもよい。このようなケースでは、第1の端末装置110と第2の端末装置120と、場合によっては、
図1Aに示されていない他の端末装置との間には、サイドリンク通信のみが存在する。
【0041】
いくつかの実施形態において、第1の端末装置110と第2の端末装置120との間のサイドリンク通信の間、第1の端末装置110は、送信リソースのセットを使用して第2の端末装置120へのサイドリンク送信112を実行することができる。
図1Aの例示的なシナリオにおいて、サイドリンク送信112は第2の端末装置120にのみ送信されるので、サイドリンク送信112はユニキャストサイドリンク送信であってもよい。本明細書で使用されるように、用語「サイドリンク送信」は、一般的には、1つの端末装置から別の端末装置への、それらの間のサイドリンクチャネルを介して実行される任意の送信を意味する。サイドリンク送信は、サイドリンク通信に関連付けられる任意のデータ又は制御情報、例えば、サイドリンクデータ又はサイドリンク制御情報、又はサイドリンクフィードバック情報を送信するために使用されてもよい。本明細書で使用されるように、用語「サイドリンクチャネル」は、一般的には、物理サイドリンク共有チャネル(PSSCH:Physical Sidelink Shared Channel)、物理サイドリンク制御チャネル(PSCCH:Physical Sidelink Control Channel)、物理サイドリンク発見チャネル(PSDCH:Physical Sidelink Discovery Channel)、物理サイドリンクブロードキャストチャネル(PSBCH:Physical Sidelink Broadcast Channel)、物理サイドリンクフィードバックチャネル(PSFCH:Physical Sidelink Feedback Channel)、及び他の既存又は将来のサイドリンクチャネルなど、サイドリンク通信のための任意のチャネルを指してもよい。
【0042】
いくつかの実施形態において、第1の端末装置110と第2の端末装置120とは、時間単位、例えば、タイムスロット(又は略してスロットと称する)に基づいて、互いに通信してもよい。例えば、サブキャリア間隔設定μの場合、スロットは、サブフレーム内では昇順に
と番号付けされ、フレーム内では昇順に
と番号付けされる。
が関連する3GPP仕様(TS 38.211)で与えられるサイクリックプレフィックスに依存するスロットには、
個の連続する直交周波数分割多重(OFDM)シンボルが存在する。サブフレーム内のスロット
の開始は、同じサブフレーム内のOFDMシンボル
の開始と時間的に揃えられる。スロットの他の関連する定義及び情報は、既存又は将来の3GPP仕様から見出すことができる。より一般的に言えば、本明細書で使用されるスロットという用語は、任意の既存の定義された時間単位、又は任意の将来定義される時間単位を指すことができる。
【0043】
図1Bは、本開示のいくつかの実施形態を実施可能な別の例示的な通信環境120の模式図である。
図1Aのシナリオ例とは異なり、
図1Bの第1の端末装置110は、第2の端末装置120と、第3の端末装置130と、第4の端末装置140とを含む複数の端末装置に同時にサイドリンク送信112を送信してもよい。例えば、
図1Bの例示的なシナリオにおけるサイドリンク送信112は、グループチキャスト又はブロードキャストサイドリンク送信であってもよい。
図1Bには示されていないが、第1、第2、第3及び第4の端末装置110、120、130及び140は、1つ又は複数のネットワーク装置によりサービングされてもよく、これらのネットワーク装置は、端末装置110、120、130及び140間のサイドリンク送信を制御又は補助してもよい。しかしながら、いくつかのケースでは、通信環境102にネットワーク装置が存在しなくてもよい。このようなケースでは、端末装置110、120、130及び140、場合によっては、
図1Bには示されていない他の端末装置の間には、サイドリンク通信のみが存在する。
【0044】
本明細書で使用されるように、用語「リソース」、「送信リソース」、又は「サイドリンクリソース」は、時間領域におけるリソース(例えば、タイムスロット)、周波数領域におけるリソース(例えば、サブチャネル)、空間領域におけるリソース、コード領域におけるリソース、又は通信を可能にする任意の他のリソースなど、端末装置間のサイドリンク通信などの通信を実行するための任意のリソースを指してもよい。以下では、周波数領域と時間領域との両方におけるリソースは、本開示のいくつかの実施形態を説明するためのサイドリンクリソースの例として使用されてもよい。しかしながら、本開示の実施形態は、任意の他の領域における任意の他のリソースにも同様に適用可能であることに留意すべきである。
【0045】
図1A及び
図1Bの通信環境100及び102では、第1の端末装置110、第2の端末装置120、第3の端末装置130、及び第4の端末装置140について説明したが、本開示の実施形態は、互いに通信する任意の他の適切な通信装置にも同様に適用可能であってもよい。すなわち、本開示の実施形態は、
図1A及び
図1Bの例示的なシナリオに限定されない。この点において、第1の端末装置110、第2の端末装置120、第3の端末装置130、及び第4の端末装置140が
図1A及び
図2Aにおいて携帯電話として模式的に図示されているが、この図示は、説明は単なる例であり、いかなる限定を示唆しないことを、理解すべきである。他の実施形態において、第1の端末装置110、第2の端末装置120、第3の端末装置130、及び第4の端末装置140は、車載端末装置のような任意の他の無線通信装置であってもよい。
【0046】
第1の端末装置110、第2の端末装置120、第3の端末装置130、及び第4の端末装置140である場合、これらに関する通信はV2X通信と称されてもよい。より一般的には、
図1A及び
図1Bには示されていないが、第1の端末装置110、第2の端末装置120、第3の端末装置130、及び第4の端末装置140に関連するV2X通信は、第1の端末装置110、第2の端末装置120、第3の端末装置130、及び第4の端末装置140、インフラストラクチャ装置、別の車載端末装置、歩行者装置、路側機等を含むがこれらに限定されない他の通信装置の間の通信を含んでもよい。さらに、図示されていないが、
図1A及び
図1Bに示されているような全ての通信リンクは、1つ又は複数のリレーを介してもよい。
【0047】
図1A及び
図1Bに示されるような端末装置の数及びネットワーク装置の数は、説明のためにのみ使用され、いかなる限定も示唆しないことを理解すべきである。通信環境100及び105は、本開示の実施形態を実現するように適合された任意の適切な数の端末装置、任意の適切な数のネットワーク装置及び任意の適切な数の他の通信装置を含んでもよい。さらに、全ての通信装置の間には、必要であれば、様々な無線通信及び有線通信が存在してもよいことを理解すべきである。
【0048】
通信環境100及び102における通信は、モバイル通信のためのグローバルシステム(GSM:Global System for Mobile Communications)、モノのモバイルインタネットのための拡張カバレッジグローバルシステム(EC-GSM-IoT:Extended Coverage Global System for Mobile Internet of Things)、ロングタームエボリューション(LTE)、LTE-Evolution、LTE-Advanced(LTE-A)、広帯域符号分割多元接続(WCDMA:Wideband Code Division Multiple Access)、符号分割多元接続(CDMA)、GSM EDGE無線アクセスネットワーク(GERAN:GSM EDGE Radio Access Network)などを含むが、これらに限定されない任意の適切な規格に準拠してもよい。さらに、通信は、現在知られている、又は将来開発される任意の世代の通信プロトコルに従って実行されてもよい。通信プロトコルの例は、第1世代(1G)、第2世代(2G)、2.5G、2.75G、第3世代(3G)、第4世代(4G)、4.5G、第5世代(5G)通信プロトコルを含むが、これらに限定されない。
【0049】
図2は本開示のいくつかの実施形態にかかる通信方法の例示的なプロセス200を示す図である。いくつかの実施形態において、該例示的なプロセス200は、端末装置、例えば
図1A又は1Bに示すような第1の端末装置110において実現されてもよい。追加として又は代替として、例示的なプロセス200はまた、
図1A及び
図1Bに示されていない他の端末装置において実現されてもよい。説明のために、
図1A、
図1B及び
図3を参照して一般性を失わずに、第1の端末装置110により実行されるように、例示的なプロセス200を説明する。
図3は、本開示のいくつかの実施形態にかかる、サイドリンク送信の受信端末装置のオフ継続時間のない、送信端末装置からのサイドリンク送信のためのリソース選択ウィンドウを示す模式図である。
【0050】
図2及び
図3を参照し、
図2のブロック210において、第1の端末装置110は、第1の端末装置110から第2の端末装置120へのサイドリンク送信112のためのリソース選択ウィンドウ305を決定してもよい。本明細書で使用されるように、第1の端末装置110により最初に、又は初めに決定されたリソース選択ウィンドウ305は、第1のリソース選択ウィンドウと称されてもよい。より一般的には、少なくとも部分的センシングが事前設定又は設定されたリソースプールにおいて、UEが、周期的な部分的センシングを実行する場合、少なくとも、リソースプールのために別のトランスポートブロック、すなわちTB(サイドリンク制御情報(SCI)内で搬送されるとき)の予約が有効化され、且つ、スロットnにおいてリソース選択又は再選択がトリガされたときに、リソース選択ウィンドウ内のY個の候補スロットのセットを決定することは、UEの実装次第である。いくつかの実施形態において、リソース選択ウィンドウ305は、第1の端末装置110がサイドリンク送信112を送信すると決定するスロットnに基づいて決定されてもよい。例えば、スロットn内で、第1の端末装置110の上位層は、サイドリンク送信112のための候補リソースのサブセットを要求、すなわち、サイドリンク送信112のためのリソース選択をトリガしてもよい。この場合、リソース選択ウィンドウ305は、[n+T1,n+T2]として決定されてもよく、ここで、T1及びT2の選択は、UEの実装によって決まってもよい。いくつかの実施形態において、T1とT2との各々は、予め定義された最大値及び/又は予め定義された最小値を有してもよい。
【0051】
ブロック220において、第1の端末装置110は、リソース選択ウィンドウ305内で1つ又は複数の継続時間を決定してもよい。一般には、第1の端末装置110により決定される1つ又は複数の継続時間は、第1の端末装置110がリソース選択及びサイドリンク送信112を回避する必要のある任意の継続時間であってもよい。例えば、第2の端末装置120に関連する情報に基づいて、第1の端末装置110は、決定された1つ又は複数の継続時間の間、第2の端末装置120がサイドリンク送信112を受信できないと決定してもよい。この場合、第1の端末装置は、第2の端末装置120によりサイドリンク送信112を受信できることを保証するために、1つ又は複数の決定された継続時間のない、リソース選択ウィンドウ305内でサイドリンク送信112のためのリソースを決定する必要があるかもしれない。言い換えれば、第1の端末装置110は、決定された1つ又は複数の継続時間を除外した後のリソース選択ウィンドウ305の残りの部分であるパーシャルリソース選択ウィンドウを決定してもよい。本明細書で使用されるように、決定された1つ又は複数の継続時間のないパーシャルリソース選択ウィンドウは、第2のリソース選択ウィンドウと称されてもよい。以下では、1つの継続時間がリソース選択ウィンドウ305から除外されるとの仮定の下で、いくつかの実施形態について説明する。しかしながら、本開示の実施形態は、2つ以上の継続時間がリソース選択ウィンドウ305から除外されるシナリオにも同様に適用できることを理解すべきである。
【0052】
ブロック230において、第1の端末装置110は、継続時間のないリソース選択ウィンドウ305内の1つ又は複数のリソース、すなわちパーシャルリソース選択ウィンドウを決定してもよい。決定された1つ又は複数のリソースは、第1の端末装置110により、サイドリンク送信112を送信するために使用される。こうして、パーシャルリソース選択ウィンドウは、サイドリンク送信112を阻止する必要があるかもしれない継続時間を含まないので、サイドリンク送信112のための第1の端末装置110のリソース選択ウィンドウが最適化され、それにより、サイドリンク送信112の性能が改善される。
【0053】
いくつかの実施形態において、第2の端末装置120がサイドリンクDRXメカニズムを有効化し、第2の端末装置120のサイドリンクDRX設定を第1の端末装置110に通知してもよいと仮定する。例えば、第1の端末装置110がサイドリンク送信112のための部分的センシングプロシージャを実行する前に、第2の端末装置120は、サイドリンクDRX設定の情報を第1の端末装置110に送信してもい。サイドリンクDRX設定によれば、第2の端末装置120のサイドリンク受信オペレーションについての、オン継続時間(例えば、オン継続時間340)とオフ継続時間(例えば、オフ継続時間320)とが存在する。サイドリンクDRXメカニズムのオン継続時間内で、第2の端末装置120は、アクティブであってもよく、そのため、サイドリンク送信を受信することができ、一方、サイドリンクDRXメカニズムのオフ継続時間内で、第2の端末装置120は、非アクティブであってもよく、そのため、サイドリンク送信を受信することができない。本明細書で使用されるように、オフ継続時間は、非アクティブ時間又は非アクティブ継続時間と称されてもよい。
【0054】
第2の端末装置120がサイドリンクDRXメカニズムを有効化する場合、パーシャルリソース選択ウィンドウ310は、第2の端末装置120のDRXパターンのオフ継続時間(例えば、オフ継続時間320)を含まない、例えば部分310-1及び部分310-2を含む、オリジナルのリソース選択ウィンドウ305内に位置するスロットのセットであってもよい。いくつかの実施形態において、サイドリンク送信112のための1つ又は複数のリソースを決定するために、第1の端末装置110は、パーシャルリソース選択ウィンドウ310から候補リソース(例えば、スロット312及び314内のリソース)を選択してもよい。より一般的には、送信UEは、パーシャルリソース選択ウィンドウ内でY個のスロットを決定してもよい。次に、第1の端末装置110は、それぞれスロット312及び314に関連付けられたセンシングオケージョン(例えば、スロット322及び324)内でセンシング測定を実行してもよい。スロット312又は314とセンシングオケージョン322又は324との間には、間隔302が存在する。いくつかの実施形態において、間隔302は、関連する3GPP仕様(例えば、TS 36.213)で定義されているいくつかのパラメータ(例えば、パラメータk及びp)に従って決定されてもよい。
【0055】
したがって、いくつかの実施形態において、パーシャルリソース選択ウィンドウ310から除外される継続時間を決定する際に、第1の端末装置110は、第2の端末装置120のDRX設定に基づいて該継続時間を決定してもよい。こうして、第1の端末装置110は、第2の端末装置120のDRX設定を考慮してパーシャルリソース選択ウィンドウ310を決定してもよいため、第1の端末装置110の部分的センシングプロシージャは、第2の端末装置120のDRXメカニズムと共に適用されてもよい。したがって、第1の端末装置110と第2の端末装置120との両方の電力消費を効果的に低減させることができる。一方、第1の端末装置110は、DRXの影響下で第2の端末装置120へのサイドリンク送信112が受信可能であることを保証することができる。逆に、従来の部分的センシング解決策はDRXの影響を考慮しないので、受信UEはDRXオフ継続時間中にサイドリンク送信を受信することができない。本開示のいくつかの実施形態は、DRXと部分的センシングとの両方が設定された場合のリソース選択の新しいUE行動を定義する。
【0056】
いくつかの実施形態において、第2の端末装置120のサイドリンクDRX設定に基づいて継続時間を決定する場合、サイドリンク送信112が第2の端末装置120へのユニキャストサイドリンク送信であれば、第1の端末装置110は、第2の端末装置120のDRX設定のオフ継続時間(例えば、オフ継続時間302)を、パーシャルリソース選択ウィンドウ310から除外される継続時間として決定してもよい。こうして、第1の端末装置110は、第2の端末装置120によりサイドリンク送信112を受信できることを保証するため、サイドリンク送信の信頼性を向上させることができる。いくつかの他のシナリオにおいて、例えば
図1Bに示すように、サイドリンク送信112は、複数の端末装置へのグループキャスト又はブロードキャストサイドリンク送信であってもよい。これらのシナリオにおいて、パーシャルリソース選択ウィンドウ310から除外される継続時間を決定する際に、複数の端末装置それぞれのオフ継続時間を考慮する必要があるかもしれない。
図4A及び
図4Bを参照して、このような実施形態について説明する。
【0057】
図4Aは本開示のいくつかの実施形態にかかる、グループキャスト又はブロードキャストサイドリンク送信の複数の受信端末装置の共通オフ継続時間及び結合オフ継続時間を示す模式図である。
図4Aに示すように、第2の端末装置120、第3の端末装置130、及び第4の端末装置140は、それぞれの異なるDRX設定を有してもよい。例えば、第2、第3、及び第4の端末装置120、130及び140は、それぞれの、位置がずれたオフ継続時間を有してもよい。しかしながら、
図4Aから分かるように、第2、第3、及び第4の端末装置120、130及び140のDRX設定の共通オフ継続時間(すなわち、共通部)420と、結合オフ継続時間(すなわち、オフ継続時間の和集合)430-1及び430-2とが存在する。
【0058】
図4Aに示す例示的なシナリオにおいて、第2の端末装置120のサイドリンクDRX設定に基づいて継続時間を決定する場合、第1の端末装置110は、複数の受信端末装置の共通オフ継続時間、又は結合オフ継続時間に基づいて、継続時間を実際に決定してもよい。より具体的には、サイドリンク送信112が、第2の端末装置120を含む複数の端末装置へのグループキャスト又はブロードキャストサイドリンク送信である場合、第1の端末装置110は、複数の端末装置120、130、及び140のそれぞれのサイドリンクDRX設定の複数のオフ継続時間を決定してもよい。次に、第1の端末装置110は、複数のオフ継続時間のうちの共通オフ継続時間420を、パーシャルリソース選択ウィンドウ310から除外される継続時間として決定してもよい。例えば、共通オフ継続時間420は、グループキャストサイドリンク送信におけるメンバUEの共通オフ継続時間であってもよい。こうして、パーシャルリソース選択ウィンドウ310から除外される継続時間を短縮することができ、それにより、パーシャルリソース選択ウィンドウ310に、グループキャスト又はブロードキャストサイドリンク送信のためのより多くの候補リソースが存在してもよくなる。代替として、第1の端末装置110は、複数のオフ継続時間のうちの結合オフ継続時間を、パーシャルリソース選択ウィンドウ310から除外される継続時間として決定してもよい。例えば、結合オフ継続時間430-1又は430-2は、グループキャストサイドリンク送信におけるメンバUEの結合オフ継続時間であってもよい。こうして、第1の端末装置110は、グループキャスト又はブロードキャストサイドリンク送信の全てのターゲット端末装置がグループキャスト又はブロードキャストサイドリンク送信を受信できることを保証することができるため、グループキャスト又はブロードキャストサイドリンク送信の信頼性を向上させることができる。
【0059】
図4Bは本開示のいくつかの実施形態にかかる、グループキャスト又はブロードキャストサイドリンク送信の複数の受信端末装置の共通オン継続時間及び結合オン継続時間を示す模式図である。
図4Bに示すように、第2、第3、及び第4の端末装置120、130及び140のDRX設定の共通オン継続時間440及び結合オン継続時間450-1及び450-2が存在する。共通オン継続時間又は結合オン継続時間の観点から、第1の端末装置110は、共通オン継続時間440をパーシャルリソース選択ウィンドウ310に含めることにより、グループキャスト又はブロードキャストサイドリンク送信の全てのターゲット端末装置がグループキャスト又はブロードキャストサイドリンク送信を受信できることを保証することができる。これとは対照的に、第1の端末装置110は、結合オン継続時間450-1及び450-2をパーシャルリソース選択ウィンドウ310に含めることにより、グループキャスト又はブロードキャストサイドリンク送信のためのパーシャルリソース選択ウィンドウ内により多くの候補リソースが存在してもよくなる。
【0060】
いくつかの実施形態において、第1の端末装置110は、半二重モードでサイドリンク送信を実行してもよく、これは、第1の端末装置110は、同時に、サイドリンク送信を送信し、且つ、別のサイドリンク送信を受信することができないことを意味する。したがって、第1の端末装置110があるスロット内でサイドリンク送信を行う場合、第1の端末装置110は、同じスロットをセンシングオケージョンと監視することができない可能性がある。結果として、第1の端末装置110は、センシングオケージョンに関連付けられる将来のスロット内に別のサイドリンク送信があるか否かを決定することができない。この場合、第1の端末装置110はまた、そのような将来のスロットをパーシャルリソース選択ウィンドウ310から除外することにより、センシング測定後にパーシャルリソース選択ウィンドウ310から決定される利用可能なリソースが他の端末装置により予約されないことを保証することもできる。より具体的には、第1の端末装置110からの前のサイドリンク送信が、パーシャルリソース選択ウィンドウ310内のあるスロットに関連付けられたセンシングオケージョン内で実行された場合、第1の端末装置110は、該スロットをパーシャルリソース選択ウィンドウ310から除外してもよい。言い換えれば、パーシャルリソース選択ウィンドウ310は、スロットセットHをさらに除外してもよい。Hは、関連付けられたセンシングオケージョン(m-k*p)が送信UEのサイドリンク送信が発生したスロットであるスロット(m)表し、ここで、kは、RRCにより設定又は予め定義され、例えば、1、2…であり、pは、リソースプールによりサポートされる予約期間のうちの少なくとも1つとして設定又は予め定義され、スロット数に変換される。こうして、第1の端末装置110は、センシング測定後にパーシャルリソース選択ウィンドウ310から決定された利用可能なリソースが他の端末装置により予約されないことを保証することにより、サイドリンク送信の信頼性を向上させることができる。
【0061】
パーシャルリソース選択ウィンドウ310がオリジナルのリソース選択ウィンドウ305よりも短いので、前述した継続時間、例えば、第2の端末装置120のオフ継続時間を除いた後に、リソース不足問題やリソース選択競合問題が存在する可能性がある。したがって、いくつかの実施形態において、継続時間のないパーシャルリソース選択ウィンドウ310内のスロット数が閾値よりも少ない場合、第1の端末装置110は、パーシャルリソース選択ウィンドウ310を拡張するなどのリソース選択強化を実行してもよい。こうして、拡張されたパーシャルリソース選択ウィンドウ内には、第1の端末装置110により選択可能な候補リソースがより多く存在するかもしれない。いくつかの実施形態において、該閾値は、第1の端末装置110の上位層により事前設定又は設定された値であってもよい。他のいくつかの実施形態において、該閾値は整数であってもよく、RRCメッセージを介して第1の端末装置110に通知されてもよい。こうして、パーシャルリソース選択ウィンドウ310内のスロット数が不足しているか否かを、上位層により、例えばトラフィック状況等に基づいて合理的に制御することができるため、該閾値の合理性を向上させる。
【0062】
いくつかの他の実施形態において、該閾値は、上位層により事前設定又は設定される、リソース選択ウィンドウ305内のスロット最小数であってもよい。言い換えれば、該閾値は、上位層により事前設定又は設定されたYの最小値であってもよい。こうして、該閾値は、既存のパラメータであるリソース選択ウィンドウ305内のスロット最小数と一致するように設定されてもよく、これにより、上位層はスロット最小数に加えて閾値を設定する必要がなくなるため、上位層のオペレーションが簡略化される。いくつかの別の実施形態において、該閾値は、該最小数とサイドリンク送信112の再送信のラウンドトリップ時間(RTT:round trip time)のためのスロット数との和であってもよい。言い換えれば、該閾値は、Yの最小値に少なくとも1回のHARQ再送信のRTTが必要とするスロットのギャップを加算した値であり、ここで、RTT時間は、リソースプールについてのsl-MinTimeGapPSFCH及びsl-PSFCH-Periodにより決定される、第1のリソースの物理サイドリンク共有チャネル(PSSCH)送信の最後のシンボルの終了と、対応する物理サイドリンクフィードバックチャネル(PSFCH)受信の最初のシンボルの開始との間の時間ギャップと、PSFCH受信、処理及び必要な物理チャネルの多重化を含むサイドリンク再送信準備に必要な時間に任意のTX-RX又はRX-TX切替時間を加算した時間と、により決定される。これにより、第1の端末装置110は、サイドリンク送信112の再送信のための利用可能なリソースが存在することを保証することにより、サイドリンク送信112の信頼性を向上させることができる。
【0063】
図5は本開示のいくつかの実施形態にかかる、パーシャルリソース選択ウィンドウがより多くのスロットを含むように拡張されていることを示す模式図である。
図5の例示的なシナリオにおいて、第1の端末装置110が、第2の端末装置120のオフ継続時間505を除外するパーシャルリソース選択ウィンドウ510を決定すると仮定する。いくつかの実施形態において、パーシャルリソース選択ウィンドウ510を拡張するために、第1の端末装置110は、パーシャルリソース選択ウィンドウ510の開始時点512を早めてもよい。例えば、拡張されたパーシャルリソース選択ウィンドウ520は、新しい開始時点522を有してもよい。こうして、第1の端末装置110は、パーシャルリソース選択ウィンドウ510を時間領域において逆方向に拡張することができるため、拡張されたパーシャルリソース選択ウィンドウ520からより多くの候補リソースを選択することができ、これにより、サイドリンク送信112の信頼性を向上させる。
【0064】
代替として又は追加として、第1の端末装置110は、パーシャルリソース選択ウィンドウ510の終了時点514を遅延させてもよい。例えば、拡張されたパーシャルリソース選択ウィンドウ520は、新しい終了時点524を有してもよい。こうして、第1の端末装置110は、パーシャルリソース選択ウィンドウ510を時間領域において前方に拡張することができるため、拡張されたパーシャルリソース選択ウィンドウ520からより多くの候補リソースを選択することができ、これにより、サイドリンク送信112の信頼性を向上させる。いくつかの実施形態において、第1の端末装置110は、拡張されたパーシャルリソース選択ウィンドウ520を、[n+T1,n+T2]に設定してもよく、ここで、T1=0であり、T2=パケット遅延バジェット(PDB:packet delay budget)又は残りのパケット遅延バジェットであるため、[n+T1,n+T2]がより多くのスロットを含むようになる。
【0065】
いくつかの他の実施形態において、パーシャルリソース選択ウィンドウ510を拡張するために、第1の端末装置110は、パーシャルリソース選択ウィンドウ510から除外される継続時間(例えば、第2の端末装置120のオフ継続時間505)が短縮されるか又は除去されるように、第2の端末装置120の調節されたサイドリンクDRX設定を決定してもよい。いくつかの実施形態において、調節されたサイドリンクDRX設定は、前のサイドリンクDRX設定とは異なる完全に再設定されたサイドリンクDRX設定であってもよい。いくつかの他の実施形態において、調節されたサイドリンクDRX設定は、前のサイドリンクDRX設定の修正されたバージョンであってもよい。次に、第1の端末装置110は、調節されたサイドリンクDRX設定の指示を第2の端末装置120に送信してもよい。調節されたサイドリンクDRX設定の指示を受信すると、第2の端末装置120は、調整された適切なサイドリンクDRX設定を適用することにより、継続時間(例えば、第2の端末装置120のオフ継続時間505)を短縮又は除去することができる。こうして、第1の端末装置110は、第2の端末装置120のサイドリンクDRX設定を調節することでパーシャルリソース選択ウィンドウ510を拡張することにより、新しいパーシャルリソース選択ウィンドウからより多くの候補リソースを選択できるようにして、サイドリンク送信112の信頼性を向上させることができる。
【0066】
図6は本開示のいくつかの実施形態にかかる、送信端末装置から受信端末装置へのサイドリンク送信のための1つ又は複数のリソースを選択するための例示的なプロセス600を示す。いくつかの実施形態において、該例示的なプロセス600は、端末装置、例えば
図1A又は1Bに示すような第1の端末装置110において実現されてもよい。追加として又は代替として、例示的なプロセス600はまた、
図1A及び
図1Bに示されていない他の端末装置において実現されてもよい。説明のために、
図1A及び
図1Bを参照して、一般性を失わずに、第1の端末装置110により実行されるように、例示的なプロセス600を説明する。
【0067】
ブロック610において、第1の端末装置110は、パーシャルリソース選択ウィンドウから、サイドリンク送信112のための複数の候補リソースを選択してもよい。例えば、候補リソースは、パーシャルリソース選択ウィンドウ内のY個のスロット内に位置してもよい。ブロック620において、第1の端末装置110は、該複数の候補リソースをセンシングすることにより、該複数の候補リソースの中から、サイドリンク送信112のために複数の利用可能なリソースを決定してもよい。例えば、第1の端末装置110は、復号化された物理サイドリンク制御チャネル(PSCCH)、及び関連するスロット内で測定されたサイドリンク受信信号強度インジケータ(S-RSSI:Sidelink Received Signal Strength Indicator)、サイドリンク参照信号受信電力(S-RSRP:Sidelink Reference Signal received Power)などに基づいて、リソース除外行動を実行してもよい。ブロック630において、第1の端末装置110は、該複数の利用可能なリソースの中から、サイドリンク送信112のための1つ又は複数のリソースを選択してもよい。こうして、第1の端末装置110は、パーシャルリソース選択ウィンドウ内の全てのリソースではなく、選択された候補リソースについてのセンシング測定を制限することができるため、第1の端末装置110の電力消費を低減させることができる。一実施形態において、例示的なプロセス200又は600のうちの少なくとも1つは、決定/選択された少なくとも1つのリソースに基づいてサイドリンク送信を実行することをさらに含む。
【0068】
いくつかの実施形態において、サイドリンク送信112のための1つ又は複数のリソースを選択するときに、サイドリンク送信112の再送信のためのリソースも第1の端末装置110により考慮される場合、サイドリンク送信112を送信するための1つ又は複数のリソースの選択については、より多くの制約が存在するかもしれない。このような実施形態については、
図7A及び
図7Bを参照して説明する。
図7A及び
図7Bは、本開示のいくつかの実施形態にかかる、リソースがサイドリンク送信のために選択された場合、サイドリンク送信の再送信のために利用可能なリソースが存在しない可能性を示す模式図である。
【0069】
図7Aに示すように、パーシャルリソース選択ウィンドウ(
図7Aには示されていない)内で、第1の端末装置110が、サイドリンク送信112を送信するためにスロット710内のリソースを選択する場合、サイドリンク送信112の潜在的な再送信のために利用可能なリソースが存在しない可能性がある。これは、潜在的な再送信とサイドリンク送信112との間のギャップ705が、少なくとも再送信のRTT時間である必要があるためであり、
図7Aの例において、ギャップ705は2つの(2)スロットであるとして仮定され、パーシャルリソース選択ウィンドウは、スロット710のギャップ705だけ後にあるスロット712を含まない。これとは対照的に、第1の端末装置110が、サイドリンク送信112を送信するためにスロット720内のリソースを選択する場合、サイドリンク送信112の潜在的な再送信のために利用可能なリソースが存在する可能性がある。これは、パーシャルリソース選択ウィンドウが、スロット720のギャップ705だけ後にあるスロット722を含むからである。
【0070】
同様に、
図7Bに示すように、第1の端末装置110が、サイドリンク送信112を送信するためにスロット730内のリソースを選択する場合、サイドリンク送信112の潜在的な再送信のために利用可能なリソースが存在しない可能性がある。これは、パーシャルリソース選択ウィンドウが、スロット730のギャップ705だけ後にあるスロット732を含まないからである。これとは対照的に、第1の端末装置110が、サイドリンク送信112を送信するためにスロット740内のリソースを選択する場合、サイドリンク送信112の潜在的な再送信のために利用可能なリソースが存在する可能性がある。これは、パーシャルリソース選択ウィンドウが、スロット740のギャップ705だけ後にあるスロット742を含むからである。
【0071】
したがって、いくつかの実施形態において、センシング測定により決定された複数の利用可能なリソースが、連続するスロットの複数のサブセット(例えば、
図7Aのサブセット702及び704、
図7Bのサブセット706及び708)内に位置する場合、第1の端末装置110は、サイドリンク送信112の潜在的な再送信のための利用可能なリソースが存在するように、サイドリンク送信112のための1つ又は複数のリソースを選択してもよい。より具体的には、連続するスロットのサブセットにおいて、第1の端末装置110は、リソースを、該リソースとサブセットの最後のスロットとの間の時間領域でのギャップが、サイドリンク送信112の再送信のRTTよりも長いように、サイドリンク送信112のための1つ又は複数のリソースのうちの1つとして選択してもよい。言い換えれば、第1の端末装置110は、各サブセットの終了前の少なくとも1つのギャップからリソースを選択することが好ましい。ギャップは(m-RTT)であってもよく、ここで、mはリソースの各サブセットの終了スロットを意味する。例えば、
図7Aの例示的なシナリオにおいて、第1の端末装置110は、サブセット702内のスロット715内、又はサブセット704内のスロット720内のリソースを選択してもよい。これにより、第1の端末装置110は、サイドリンク送信112の再送信のための利用可能なリソースが存在することを保証し、且つDRXの影響下でより多くのHARQ送信機会を得ることにより、サイドリンク送信112の信頼性を向上させることができる。
【0072】
代替として又は追加として、連続するスロットのサブセット内で、第1の端末装置110は、サブセットの最も早いリソースを、サイドリンク送信112を送信するための1つ又は複数のリソースのうちの1つとして選択してもよい。言い換えれば、HARQが有効化されたリソースプールにおいて、UEは、最初のTB送信のために、リソースの各サブセットから最も早い時間リソース及び周波数リソースを選択することが好ましい。例えば、
図7Bの例示的なシナリオにおいて、第1の端末装置110は、サブセット706内のスロット735内、又はサブセット708内のスロット745内のリソースを選択してもよい。こうして、第1の端末装置110は、サイドリンク送信の再送信のために利用可能なリソースが存在する確率を最大化し、DRXの影響下でより多くのHARQ送信機会を得ることにより、サイドリンク送信の信頼性を向上させることができる。
【0073】
いくつかの実施形態において、パーシャルリソース選択ウィンドウ内で、サイドリンク送信112を送信するための1つ又は複数のリソースを決定するとき、第1の端末装置110は、第2の端末装置120のサイドリンクDRX設定がサイドリンク送信112にとって不適切であると決定してもよい。例えば、第1の端末装置110は、パーシャルリソース選択ウィンドウ内のリソースの総数が、サイドリンク送信112のために十分ではないと決定してもよい。言い換えれば、端末装置110は、センシングの前に、パーシャルリソース選択ウィンドウ内に十分なリソースがないと決定してもよい。不適切なサイドリンクDRX設定についてのこのような基準により、第1の端末装置110は、サイドリンク送信112のために十分なリソースが存在する確率を高めることにより、サイドリンク送信112の信頼性を向上させることができる。
【0074】
別の例として、第1の端末装置110は、パーシャルリソース選択ウィンドウ内に、サイドリンク送信の再送信のために利用可能なリソースがないと決定してもよい。より具体的には、第1の端末装置110は、センシングの前に、パーシャルリソース選択ウィンドウ内にHARQ再送信のために選択可能なリソースがない、例えば、パーシャルリソース選択ウィンドウ内のRTTよりも少ない、と決定してもよい。不適切なサイドリンクDRX設定についてのこのような基準により、第1の端末装置110は、サイドリンク送信112のために十分なリソースが存在する確率を高めることにより、サイドリンク送信112の信頼性を向上させることができる。
【0075】
さらに別の例として、第1の端末装置110は、パーシャルリソース選択ウィンドウ内で部分的センシングを実行することにより決定されたパーシャルリソース選択ウィンドウ内の利用可能なリソースの数が、サイドリンク送信112のために十分ではないと決定してもよい。言い換えれば、パーシャルリソース選択ウィンドウ内のセンシング結果では不十分である。不適切なサイドリンクDRX設定についてのこのような基準により、第1の端末装置110は、サイドリンク送信112のために十分なリソースが存在することを保証することにより、サイドリンク送信112の信頼性を向上させることができる。
【0076】
いくつかの実施形態において、第1の端末装置110が、第2の端末装置120のサイドリンクDRX設定がサイドリンク送信112にとって不適切であると決定した場合、第1の端末装置110は、第2の端末装置120の調節されたサイドリンクDRX設定を決定してもよい。すなわち、サイドリンク送信の送信UEが、受信UEのDRX設定が不適切であると決定した場合、送信UEは、受信UEのDRX設定を再設定してもよい。第2の端末装置120の調節されたサイドリンクDRX設定を決定した後、第1の端末装置110は、調節されたサイドリンクDRX設定の指示を第2の端末装置120に送信してもよい。調節されたサイドリンクDRX設定の指示を受信すると、第2の端末装置120は、調整された適切なサイドリンクDRX設定を適用することにより、第1の端末装置110から第2の端末装置120へのサイドリンク送信112を容易にすることができる。こうして、第1の端末装置110は、第2の端末装置120の不適切なサイドリンクDRX設定を適切なサイドリンクDRX設定に変更することにより、パーシャルリソース選択ウィンドウからより多くの候補リソースを選択できるようにして、サイドリンク送信112の信頼性を向上させることができる。
【0077】
図8は本開示のいくつかの実施形態にかかる、サイドリンク送信の送信端末装置が、送信端末装置のオン継続時間内に位置するセンシングオケージョンに関連付けられたスロット内で候補リソースを選択することができることを示す模式図である。
図8に示すように、
図1A又は1Bの例示的なシナリオにおいて、送信端末装置が第1の端末装置110であり、サイドリンク送信がサイドリンク送信112であり、受信端末装置が第2の端末装置120であると仮定する。また、第1の端末装置110が、スロットn内でサイドリンク送信112を送信すると決定し、リソース選択ウィンドウが[n+T1,n+T2]として決定されると仮定する。第1の端末装置110はさらに、第2の端末装置120のオフ継続時間813のないパーシャルリソース選択ウィンドウ810を決定する。
【0078】
スロットのセット820、スロットのセット830、及びスロットのセット840は、それぞれセンシングオケージョン825、センシングオケージョン835及びセンシングオケージョン845に関連付けられていることが分かる。スロットのセットのうちのいずれか1つと、関連付けられるセンシングオケージョンとの間のギャップはギャップ802として示され、ギャップ802は、例えば、関連する3GPP仕様(例えば、TS 36.213)で定義されているいくつかのパラメータ(例えば、パラメータk及びp)に従って決定されてもよい。スロットのセット820に関連付けられたセンシングオケージョン825(利用可能なセンシングオケージョンとも称される)は、第1の端末装置110のオン継続時間815内にあり、一方、スロットのセット830及びスロットのセット840にそれぞれ関連付けられたセンシングオケージョン835及びセンシングオケージョン845は、第1の端末装置110のオフ継続時間中にあることに留意できるはずである。これは、第1の端末装置110がオフ継続時間中にサイドリンク情報又は信号を受信できない可能性があるので、第1の端末装置110は、スロットのセット830及びスロットのセット840内のリソースが他の端末装置により予約されているか否かを決定できない可能性があることを意味する。
【0079】
したがって、いくつかの実施形態において、パーシャルリソース選択ウィンドウ810内でサイドリンク送信112のための1つ又は複数のリソースを決定するとき、第1の端末装置110は、最初に、パーシャルリソース選択ウィンドウ810内でスロットのセット820を決定してもよい。上述したように、スロットのセット820は、第1の端末装置110のサイドリンクDRX設定のオン継続時間815内に位置するそれぞれのセンシングケース825に関連付けられる。次いで、第1の端末装置110は、スロットのセット820から、サイドリンク送信112のために使用される1つ又は複数のリソースを決定してもよい。こうして、第1の端末装置110は、センシング測定後に決定された利用可能な候補リソースが他の端末装置により予約されないことを保証することにより、サイドリンク送信112の信頼性を向上させ、リソース選択を拡張させ、DRXの影響下でのリソース競合を減少させることができる。
【0080】
第1の端末装置110は、センシング測定後に、スロットのセット820からの1つ又は複数のリソースが利用可能であることを保証することができるが、スロットのセット820は、パーシャルリソース選択ウィンドウ810よりも少ないスロットを含んでもよい。言い換えれば、1つ又は複数のリソースがスロットのセット820から選択されるように限定された場合、いくつかの状況において、リソース不足が発生する可能性がある。したがって、いくつかの実施形態において、第1の端末装置110は、重要なトラフィックに関連付けられるサイドリンク送信のためだけに、1つ又は複数のリソースをスロットのセット820にあるように限定してもよい。より具体的には、サイドリンク送信112に関連付けられるトラフィック優先度が優先度閾値よりも高い場合(例えば、トラフィック優先度値が設定された閾値よりも小さい場合)、第1の端末装置110は、センシング測定を実行するためにスロットのセット820を決定してもよい。いくつかの実施形態において、設定された閾値は、予め定義されてもよく、又はRRCメッセージを介して第1の端末装置110に通知されてもよい。いくつかの実施形態において、該設定された閾値は、1から8までの範囲の値を有してもよい。こうして、より重要なトラフィックに関連付けられるサイドリンク送信の信頼性を保証することができる一方、重要度のより低いトラフィックに関連付けられるサイドリンク送信については、リソース選択プロシージャを簡略化することができ、より多くの候補リソースが存在する可能性がある。
【0081】
いくつかの実施形態において、スロットのセット820は、第1の端末装置110の下位層(例えば、物理層)により決定されてもよい。より具体的には、第1の端末装置110は、下位層にスロットのセット820を決定させてもよい。これらの実施形態において、サイドリンク送信112のためにスロットのセット820から1つ又は複数のリソースを決定するとき、第1の端末装置110は、下位層に、スロットのセット820内の利用可能なリソースを第1の端末装置110の上位層(例えば、MAC層)に報告させてもよい。例えば、利用可能なリソースは、スロットのセット820から選択された候補リソースについてのセンシング測定により決定される。次に、第1の端末装置110は、上位層に、利用可能なリソースから1つ又は複数のリソースを選択させてもよい。言い換えれば、物理層内及びパーシャルリソース選択ウィンドウ内で、UEは、単に、又は好ましくは、スロットセットYを、関連付けられたセンシングオケージョンがUEのオン継続時間内に位置するスロットセットSとして決定し、候補リソースをMAC層に報告する。これにより、上位層(例えばMAC層)のオペレーションを簡略化することができる。
【0082】
いくつかの他の実施形態において、スロットのセット820は、第1の端末装置110の上位層(例えば、MAC層)により決定されてもよい。より具体的には、第1の端末装置110は、上位層にスロットのセット820を決定させてもよい。これらの実施形態において、サイドリンク送信112のためにスロットのセット820から1つ又は複数のリソースを決定するとき、第1の端末装置110は、下位層に、パーシャルリソース選択ウィンドウ内の候補リソースを報告させてもよい。次に、第1の端末装置110は、1つ又は複数のリソースがスロットのセット820内に位置するように、上位層に、候補リソースから1つ又は複数のリソースを選択させてもよい。言い換えれば、MAC層内及び物理層からの報告されたリソースセットSA内では、UEは、単に、又は好ましくは、関連付けられたセンシングオケージョンがUEのオン継続時間内に位置するスロットセットS内のリソースを選択してもよい。これにより、下位層(例えば物理層)のオペレーションを簡略化することができる。
【0083】
図9は本開示のいくつかの実施形態にかかる、第1の端末装置110と第2の端末装置120との間の例示的な通信プロセス900を示す図である。説明のために、
図1A及び1Bを参照して通信プロセス900を説明する。しかしながら、通信プロセス900は、2つの端末装置が互いに通信する任意の他の通信シナリオにも同様に適用できることを理解すべきである。
【0084】
図9に示すように、第1の端末装置110がサイドリンク送信112を第2の端末装置120に送信する前に、第1の端末装置110は、キャストタイプ情報915を第2の端末装置120に送信する(910)。例えば、キャストタイプ情報915は、例えば
図1Aに示す例示的なシナリオにおいて、サイドリンク送信112が第1の端末装置110から第2の端末装置120へのユニキャストサイドリンク送信であることを示してもよい。別の例として、キャストタイプ情報915は、例えば
図1Bに示す例示的なシナリオにおいて、サイドリンク送信112が、第1の端末装置110から第2の端末装置120を含む複数の端末装置(例えば、
図1Bの第2、第3、及び第4の端末装置120、130及び140)へのグループキャスト又はブロードキャストサイドリンク送信であることを示してもよい。いくつかの実施形態において、キャストタイプ情報915は、サイドリンク送信112のスケジューリング情報(例えば、サイドリンク制御情報(SCI))を介して送信されてもよい。いくつかの他の実施形態において、キャストタイプ情報915は、サイドリンク送信112のスケジューリング情報以外のシグナリングを介して送信されてもよい。
【0085】
受信側では、第2の端末装置120は、第1の端末装置110からキャストタイプ情報915を受信する(920)。キャストタイプ情報915に基づいて、第2の端末装置120は、サイドリンク送信中に、第2の端末装置120のサイドリンクDRXの有効化設定を決定してもよい(930)。より具体的には、第2の端末装置120は、サイドリンク送信112のために第1の端末装置110により実行される部分的センシングプロシージャについてDRXメカニズムを有効化又は無効化することにより、サイドリンク送信112の送信側での部分的センシングプロシージャを容易にすることができる。例えば、第2の端末装置120は、サイドリンク送信112のキャストタイプ(例えば、ユニキャスト、グループキャスト、又はブロードキャスト)に応じてDRXメカニズムを有効化又は無効化してもよい。これにより、DRXの影響下での、第1の端末装置110から第2の端末装置120へのサイドリンク送信112のより良い送信又は受信効率を達成することができる。
【0086】
いくつかの実施形態において、キャストタイプ情報915が、サイドリンク送信112がユニキャストサイドリンク送信であることを示す場合、例えば、サイドリンク送信112のSCI内で示されたキャストタイプが「ユニキャスト」である場合、第2の端末装置120は、サイドリンク送信112の間、サイドリンクDRXを有効化してもよい。例えば、DRX設定がUEごとに事前設定又は設定される、すなわち、第2の端末装置120について別々に事前設定又は設定される場合がある。こうして、第1の端末装置110の部分的センシングプロシージャを、第2の端末装置120のDRXメカニズムと共に適用することができる。したがって、第1の端末装置110と第2の端末装置120との両方の電力消費を効果的に低減させることができる。
【0087】
いくつかの他の実施形態において、キャストタイプ情報915が、サイドリンク送信112がグループキャスト又はブロードキャストサイドリンク送信であることを示す場合、例えば、サイドリンク送信112のSCI内で示されたキャストタイプが「ユニキャスト」ではない(例えば、グループキャストオプション1、グループキャストオプション2及びブロードキャスト)場合、第2の端末装置は、サイドリンク送信112の間、サイドリンクDRXを無効化してもよい。例えば、DRX設定がUEごとに事前設定又は設定される、すなわち、第2の端末装置120について別々に事前設定又は設定される場合がある。こうして、第1の端末装置110は、パーシャルリソース選択ウィンドウから、グループキャスト又はブロードキャストサイドリンク送信のターゲット端末装置の共通オフ継続時間又は結合オフ継続時間を除外する必要がないので、パーシャルリソース選択ウィンドウから選択できるより多くの候補リソースがあるかもしれない。
【0088】
いくつかの別の実施形態において、第2の端末装置120のサイドリンクDRX設定は、第2の端末装置120について別々に事前設定又は設定されるのではなく、サイドリンク送信112のためにリソースが選択されたリソースプールについて事前設定又は設定されてもよい。言い換えれば、サイドリンクDRX設定は、リソースプールごとに事前設定又は設定される。この場合、第2の端末装置120は、キャストタイプ情報915に関係なく、サイドリンク送信112中にサイドリンクDRXを有効化してもよい。こうして、第1の端末装置110は、パーシャルリソース選択ウィンドウから、グループキャスト又はブロードキャストサイドリンク送信のターゲット端末装置の同じ継続時間を除外する必要があるのみので、パーシャルリソース選択ウィンドウから選択できるより多くの候補リソースがあるかもしれない。したがって、第1の端末装置110の部分的センシングプロシージャを、ターゲット端末装置のDRXメカニズムと共に適用することができる。このため、第1の端末装置110とターゲット端末装置との両方の電力消費を効果的に低減させることができる。
【0089】
図10は本開示のいくつかの実施形態にかかる別の通信方法の例示的なプロセス1000を示す。いくつかの実施形態において、該例示的なプロセス1000は、端末装置、例えば
図1A又は1Bに示すような第2の端末装置120において実現されてもよい。追加として又は代替として、例示的なプロセス1000はまた、
図1A及び
図1B3に示されていない他の端末装置において実現されてもよい。説明のために、
図1A及び
図1Bを参照して、一般性を失わずに、第2の端末装置120により実行されるように、例示的なプロセス1000を説明する。
【0090】
ブロック1010において、第2の端末装置120は、第1の端末装置110から、第1の端末装置110から第2の端末装置120へのサイドリンク送信のキャストタイプ情報を受信する。ブロック1020において、第2の端末装置120は、キャストタイプ情報に基づいて、サイドリンク送信の間の第2の端末装置120のサイドリンクDRXの有効化設定を決定する。
【0091】
いくつかの実施形態において、有効化設定を決定するとき、キャストタイプ情報が、サイドリンク送信がユニキャストサイドリンク送信であることを示す場合、第2の端末装置120は、サイドリンク送信の間、サイドリンクDRXを有効化してもよい。
【0092】
いくつかの実施形態において、有効化設定を決定するとき、キャストタイプ情報が、サイドリンク送信がグループキャスト又はブロードキャストサイドリンク送信であることを示す場合、第2の端末装置120は、サイドリンク送信の間、サイドリンクDRXを無効化してもよい。
【0093】
いくつかの実施形態において、第2の端末装置120のサイドリンクDRX設定は、サイドリンク送信のためにリソースが選択されたリソースプールについて事前設定又は設定される場合、第2の端末装置120は、キャストタイプ情報に関係なく、サイドリンク送信の間、サイドリンクDRXを有効化してもよい。
【0094】
本開示の実施形態によれば、第1の端末装置は回路を備え、前記回路は、前記第1の端末装置から第2の端末装置へのサイドリンク送信のためのリソース選択ウィンドウを決定し、前記リソース選択ウィンドウ内の継続時間を決定し、前記継続時間のない前記リソース選択ウィンドウ内で、前記サイドリンク送信のための少なくとも1つのリソースを決定するように設定されている。
【0095】
いくつかの実施形態において、前記回路は、前記第2の端末装置のサイドリンク不連続受信(DRX)設定に基づいて前記継続時間を決定することにより、前記継続時間を決定するように設定されている。
【0096】
いくつかの実施形態において、前記回路は、前記サイドリンク送信が前記第2の端末装置へのユニキャストサイドリンク送信であるとの決定に従って、前記第2の端末装置の前記DRX設定のオフ継続時間を前記継続時間として決定することにより、前記サイドリンクDRX設定に基づいて前記継続時間を決定するように設定されている。
【0097】
いくつかの実施形態において、前記回路は、前記サイドリンク送信が前記第2の端末装置を含む複数の端末装置へのグループキャスト又はブロードキャストサイドリンク送信であるとの決定に従って、前記複数の端末装置のそれぞれのサイドリンクDRX設定の複数のオフ継続時間を決定し、前記複数のオフ継続時間の共通オフ継続時間又は結合オフ継続時間を前記継続時間として決定することにより、前記サイドリンクDRX設定に基づいて前記継続時間を決定するように設定されている。
【0098】
いくつかの実施形態において、前記回路はさらに、前記第1の端末装置からの前のサイドリンク送信が、前記継続時間のない前記リソース選択ウィンドウの残りの部分内のスロットに関連付けられたセンシングオケージョン内で実行されたとの決定に従って、前記スロットを前記リソース選択ウィンドウの残りの部分から除外するように設定されている。
【0099】
いくつかの実施形態において、前記回路はさらに、前記継続時間のない前記リソース選択ウィンドウの残りの部分内のスロット数が閾値よりも少ないとの決定に従って、前記リソース選択ウィンドウの残りの部分を拡張するように設定されている。
【0100】
いくつかの実施形態において、前記閾値は、前記第1の端末装置の上位層により事前設定又は設定された値と、前記上位層により事前設定又は設定される、前記リソース選択ウィンドウ内のスロット最小数と、前記最小数と前記サイドリンク送信の再送信のラウンドトリップ時間のためのスロット数との和とのうちの1つである。
【0101】
いくつかの実施形態において、前記回路は、前記リソース選択ウィンドウの残りの部分の開始時点を早めることと、前記リソース選択ウィンドウの残りの部分の終了時点を遅延させることと、のうちの少なくとも1つにより、前記リソース選択ウィンドウの残りの部分を拡張するように設定されている。
【0102】
いくつかの実施形態において、前記回路は、前記継続時間が短縮又は除去されるように、前記第2の端末装置の調節されたサイドリンクDRX設定を決定し、前記調節されたサイドリンクDRX設定の指示を前記第2の端末装置に送信することにより、前記リソース選択ウィンドウの残りの部分を拡張するように設定されている。
【0103】
いくつかの実施形態において、前記回路は、前記継続時間のない前記リソース選択ウィンドウの残りの部分から、前記サイドリンク送信のための複数の候補リソースを選択し、前記複数の候補リソースをセンシングすることにより、前記複数の候補リソースの中から、前記サイドリンク送信のための複数の利用可能なリソースを決定し、前記複数の利用可能なリソースから、前記少なくとも1つのリソースを選択することにより、前記少なくとも1つのリソースを決定するように設定されている。
【0104】
いくつかの実施形態において、前記複数の利用可能なリソースは、連続するスロットの複数のサブセット内に位置し、前記回路は、前記複数のサブセット内のサブセットから、リソースを、前記リソースと前記サブセットの最後のスロットとの間の時間領域でのギャップが前記サイドリンク送信の再送信のラウンドトリップ時間よりも長いように、前記少なくとも1つのリソースのうちの1つとして選択し、前記複数のサブセット内のサブセットから、前記サブセット内の最も早いリソースを、前記少なくとも1つのリソースのうちの1つとして選択することにより、前記少なくとも1つのリソースを選択するように設定されている。
【0105】
いくつかの実施形態において、前記回路はさらに、前記第2の端末装置のサイドリンクDRX設定が前記サイドリンク送信にとって不適切であるとの決定に従って、前記第2の端末装置の調節されたサイドリンクDRX設定を決定し、前記調節されたサイドリンクDRX設定の指示を前記第2の端末装置に送信するように設定されている。
【0106】
いくつかの実施形態において、前記第2の端末装置のサイドリンクDRX設定が不適切であると決定することは、前記継続時間のない前記リソース選択ウィンドウの残りの部分内のリソースの総数が前記サイドリンク送信にとって不十分であると決定することと、前記リソース選択ウィンドウの残りの部分内に、前記サイドリンク送信の再送信のために利用可能なリソースがないと決定することと、前記リソース選択ウィンドウの残りの部分内で部分的センシングを実行することにより決定された、前記リソース選択ウィンドウの残りの部分内の利用可能なリソースの数が、前記サイドリンク送信にとって不十分であると決定することと、のうちの少なくとも1つを含む。
【0107】
いくつかの実施形態において、前記回路は、前記継続時間のない前記リソース選択ウィンドウの残りの部分内で、前記第1の端末装置のサイドリンクDRX設定のオン継続時間内に位置するそれぞれのセンシングオケージョンに関連付けられるスロットのセットを決定し、前記スロットのセットから前記少なくとも1つのリソースを決定することにより、前記少なくとも1つのリソースを決定するように設定されている。
【0108】
いくつかの実施形態において、前記回路は、前記第1の端末装置の下位層に前記スロットのセットを決定させることにより、前記スロットのセットを決定するように設定されている。
【0109】
いくつかの実施形態において、前記回路は、前記下位層に、前記スロットのセット内の利用可能なリソースを前記第1の端末装置の上位層に報告させ、前記上位層に、前記候補リソースから前記少なくとも1つのリソースを選択させることにより、前記スロットのセットから前記少なくとも1つのリソースを決定するように設定されている。
【0110】
いくつかの実施形態において、前記回路は、前記第1の端末装置の上位層に前記スロットのセットを決定させることにより、前記スロットのセットを決定するように設定されている。
【0111】
いくつかの実施形態において、前記回路は、前記第1の端末装置の下位層に、前記リソース選択ウィンドウの残りの部分内の候補リソースを報告させ、前記上位層に、前記候補リソースから、前記スロットのセット内に位置する前記少なくとも1つのリソースを選択させることにより、前記スロットのセットから前記少なくとも1つのリソースを決定するように設定されている。
【0112】
いくつかの実施形態において、前記回路は、前記サイドリンク送信に関連付けられるトラフィック優先度が優先度閾値よりも高いとの決定に従って、前記スロットのセットを決定することにより、前記スロットのセットを決定するように設定されている。
【0113】
本開示の実施形態によれば、第2の端末装置は回路を備え、前記回路は、第1の端末装置から、前記第1の端末装置から前記第2の端末装置へのサイドリンク送信のキャストタイプ情報を受信し、前記キャストタイプ情報に基づいて、前記サイドリンク送信の間の前記第2の端末装置のサイドリンク不連続受信(DRX)の有効化設定を決定するように設定されている。
【0114】
いくつかの実施形態において、前記回路は、前記キャストタイプ情報が、前記サイドリンク送信がユニキャストサイドリンク送信であることを示すとの決定に従って、前記サイドリンク送信の間、前記サイドリンクDRXを有効化することにより、前記有効化設定を決定するように設定されている。
【0115】
いくつかの実施形態において、前記回路は、前記キャストタイプ情報が、前記サイドリンク送信がグループキャスト又はブロードキャストサイドリンク送信であることを示すとの決定に従って、前記サイドリンク送信の間、前記サイドリンクDRXを無効化することにより、前記有効化設定を決定するように設定されている。
【0116】
いくつかの実施形態において、前記回路はさらに、前記第2の端末装置のサイドリンクDRX設定が、前記サイドリンク送信のためにリソースが選択されたリソースプールについて事前設定又は設定されるとの決定に従って、前記キャストタイプ情報に関係なく、前記サイドリンク送信の間、前記サイドリンクDRXを有効化する用に設定されている。
【0117】
図11は本開示のいくつかの実施形態を実装するのに適した装置1100の概略ブロック図である。
図1A及び
図1Bに示すように、装置1100は、ネットワーク装置105、第1の端末装置110、第2の端末装置120、第3の端末装置130、及び第4の端末装置140の別の実施形態として考えられてもよい。したがって、装置1100は、ネットワーク装置105、第1の端末装置110、第2の端末装置120、第3の端末装置130、及び第4の端末装置140において、又はそれらの少なくとも一部として実現されてもよい。
【0118】
図示されるように、装置1100は、プロセッサ1110と、プロセッサ1110に結合されたメモリ1120と、プロセッサ1110に結合された適切な送信機(TX)及び受信機(RX)1140と、TX/RX1140に結合された通信インターフェースとを含む。メモリ1120は、プログラム1130の少なくとも一部を記憶する。TX/RX1140は双方向通信に用いられる。TX/RX1140は、通信を容易にするために少なくとも一つのアンテナを有するが、本明細書に言及されたアクセスノードは、実際には複数のアンテナを有してもよい。通信インターフェースは、gNB又はeNB間の双方向通信のためのX2又はXnインターフェース、モビリティ管理エンティティ(MME)/サービングゲートウェイ(S-GW)とeNBとの間の通信のためのS1インターフェース、gNB又はeNBと中継ノード(RN)との間の通信のためのUnインターフェース、又はgNB又はeNBと端末装置との間の通信のためのUuインターフェースなど、他のネットワーク要素との通信に必要な任意のインターフェースを表すことができる。
【0119】
プログラム1130は、上記の図面を参照して本明細書で説明したように、関連付けられたプロセッサ1110により実行された場合、装置1100が本開示の実施形態に従って動作することを可能にするプログラム命令を含むと仮定される。本文の実施形態は、装置1100のプロセッサ1110により実行可能なコンピュータソフトウェアにより、又はハードウェアにより、又はソフトウェアとハードウェアとの組合せにより実現できる。プロセッサ1110は、本開示の様々な実施形態を実施するように設定されてもよい。さらに、プロセッサ1110とメモリ1120との組み合わせは、本開示の様々な実施形態を実現するのに適したプロセッシング手段1150を形成してもよい。
【0120】
メモリ1120は、ローカル技術ネットワークに適した任意のタイプであってもよく、また、非限定的な例として、非一時的なコンピュータ読み取り可能な記憶媒体、半導体に基づくメモリ装置、磁気メモリ装置及びシステム、光学メモリ装置及びシステム、固定メモリ及びリムーバブルメモリなど、任意の適切なデータ記憶技術を使用して実現されてもよい。装置1100内には1つのメモリ1120のみが示されているが、装置1100内にはいくつかの物理的に異なるメモリモジュールが存在してもよい。プロセッサ1110は、ローカル技術ネットワークに適した任意のタイプであってもよく、非限定的な例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ(DSP:digital signal processor)、及びマルチコアプロセッサアーキテクチャに基づくプロセッサのうちの一つ又は複数を含んでもよい。装置1100は、複数のプロセッサ、例えば、メインプロセッサを同期化するクロックに時間的に従属する特定用途向け集積回路チップを有してもよい。
【0121】
本開示の機器及び/又は装置に含まれるコンポーネントは、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせを含む様々な態様で実現されてもよい。いくつかの実施形態において、記憶媒体上に記憶されたマシン実行可能な命令などのようなソフトウェア及び/又はファームウェアを使用して1つ又は複数のユニットを実現してもよい。マシン実行可能な命令に加えて、又はその代わりに、機器及び/又は装置内のユニットの一部又は全部は、少なくとも部分的に、1つ又は複数のハードウェア論理コンポーネントにより実装されてもよい。限定ではなく、一例として、使用可能なハードウェア論理コンポーネントの例示的なタイプは、フィールドプログラマブルゲートアレイ(FPGA:Field-programmable Gate Array)、特定用途向け集積回路(ASIC:Application-specific Integrated Circuit)、特定用途向け汎用製品(ASSP:Application-specific Standard Product)、システムオンチップ(SOC:System-on-a-chip system)、複合プログラマブル論理装置(CPLD:Complex Programmable Logic Device)などを含む。
【0122】
全体として、本開示の様々な実施形態は、ハードウェア又は専用回路、ソフトウェア、論理、又はそれらの任意の組み合わせで実現されてもよい。いくつかの態様は、ハードウェアで実現されてもよく、他の態様は、コントローラ、マイクロプロセッサ、又は他のコンピューティング装置により実行できるファームウェア又はソフトウェアで実現されてもよい。本開示の実施形態の様々な態様は、ブロック図、フローチャート又は他の何らかの絵画的表現を用いて図示及び説明されているが、本明細書に記載されたブロック、機器、システム、技術、又は方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路又は論理、汎用ハードウェア又はコントローラ又は他のコンピューティング装置、又はそれらの何らかの組み合わせで実装されてもよいことを理解すべきである。
【0123】
本開示はまた、非一時的なコンピュータ可読記憶媒体上に有形的に記憶された少なくとも一つのコンピュータプログラム製品を提供する。コンピュータプログラム製品は、図面の何れか一つを参照して上述したプロセス又は方法を実行するために、対象の実プロセッサ又は仮想プロセッサ上の装置内で実行される、プログラムモジュールに含まれる命令などのコンピュータ実行可能な命令を含む。一般に、プログラムモジュールには、特定のタスクを実行したり、特定の抽象データ型を実装したりするルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、データ構造などが含まれる。様々な実施形態において、プログラムモジュールの機能は、必要に応じて、プログラムモジュール間で結合又は分割されてもよい。プログラムモジュールのマシンが実行可能な命令は、ローカル又は分散型装置内で実行されてもよい。分散型装置において、プログラムモジュールは、ローカル記憶媒体及びリモート記憶媒体内の両方に配置されていてもよい。
【0124】
本開示の方法を実行するためのプログラムコードは、一つ又は複数のプログラミング言語の任意の組み合わせで記述されてもよい。これらのプログラムコードは、汎用コンピュータ、専用コンピュータ、又は他のプログラマブルデータプロセッシング機器のプロセッサ又はコントローラに提供され、プロセッサ又はコントローラにより実行された場合、プログラムコードで、フローチャート及び/又はブロック図に指定された機能/動作を実現させる。プログラムコードは、完全にマシン上で、部分的にマシン上で、独立したソフトウェアパッケージとして、部分的にマシン上でかつ部分的にリモートマシン上で、又は完全にリモートマシン又はサーバ上で実行してもよい。
【0125】
上述のプログラムコードは、マシン可読媒体上で実装されてもおく、マシン可読媒体は、命令実行システム、機器、又は装置により利用されるか、又はそれらに関連するプログラムを含むか又は記憶することができる任意の有形媒体であってもよい。マシン可読媒体は、マシン可読信号媒体又はマシン可読記憶媒体であってもよい。マシン可読媒体は、電子、磁気、光学、電磁気、赤外線若しくは半導体のシステム、機器若しくは装置、又は前述の媒体の任意の適切な組み合せを含むことができるが、これらに限定されない。マシンが読み取り可能な記憶媒体のより具体的な例は、一つ又は複数のワイヤを有する電気接続、ポータブルコンピュータディスク、ハードディスク、ランダムアクセスメモリ(RAM:random access memory)、リードオンリーメモリ(ROM:read-only memory)、消去可能プログラマブルリードオンリーメモリ(EPROM(erasable programmable read-only memory)又はフラッシュメモリ)、光ファイバ、ポータブル光ディスクリードオンリーメモリ(CD-ROM:compact disc read-only memory)、光学的記憶装置、磁気記憶装置、又は上述の任意の適切な組合せを含んでもよい。
【0126】
なお、動作について特定の順序で説明を行ったが、所望の結果を得るために、こうした動作を、示された特定の順序で実行するか若しくは連続した順序で実行し、又は、説明された全ての動作を実行することが求められる、と理解されるべきではない。場合によっては、マルチタスクや並列処理が有利になることもある。同様に、いくつかの特定の実施形態の詳細が上記の議論に含まれているが、これらは、本開示の範囲に対する限定として解釈されるべきではなく、特定の実施形態に固有となり得る特徴の説明として解釈されるべきである。個々の実施形態の文脈で説明されたいくつかの特徴は、単一の実施形態において組み合わされて実現されてもよい。逆に、単一の実施形態の文脈で説明された様々な特徴は、複数の実施形態において別々に、又は任意の適切なサブ組合せで実装されてもよい。
【0127】
本開示は、構造的特徴及び/又は方法論的動作に特有の言語で説明されてきたが、添付の特許請求の範囲において定義された本開示は、必ずしも上記の特定の特徴又は動作に限定されないことを理解すべきである。むしろ、上述した特定の特徴及び動作は、特許請求の範囲を実施する例示的な形態として開示されている。
【国際調査報告】