知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-05
(54)【発明の名称】サイドリンク通信方法および装置
(51)【国際特許分類】
H04W 72/40 20230101AFI20240829BHJP
H04W 92/18 20090101ALI20240829BHJP
H04W 16/14 20090101ALI20240829BHJP
H04W 72/54 20230101ALI20240829BHJP
H04W 24/08 20090101ALI20240829BHJP
H04W 72/0453 20230101ALI20240829BHJP
【ＦＩ】
H04W72/40
H04W92/18
H04W16/14
H04W72/54 110
H04W24/08
H04W72/0453
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024513467
(86)(22)【出願日】2022-08-23
(85)【翻訳文提出日】2024-04-09
(86)【国際出願番号】 CN2022114176
(87)【国際公開番号】W WO2023030088
(87)【国際公開日】2023-03-09
(31)【優先権主張番号】202111011966.1
(32)【優先日】2021-08-31
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
(71)【出願人】
【識別番号】503433420
【氏名又は名称】華為技術有限公司
【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100229448
【弁理士】
【氏名又は名称】中槇 利明
(72)【発明者】
【氏名】プオン，ウエンジエ
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067EE02
5K067EE10
5K067EE25
5K067JJ03
(57)【要約】
本出願の実施形態は、サイドリンク通信方法およびデバイスを提供する。本方法は、第１通信デバイスが、ネットワークデバイスから構成情報を受信することを含む。構成情報は、第１リソースプールにおいて発生した一貫したリッスンビフォアトークLBT失敗を検出するために第１通信デバイスによって使用され、構成情報は、第１キャリアまたは第１リソースプールに関連付けられ、第１リソースプールは、第１キャリアに属している。加えて、第１通信デバイスは、第１指示情報をネットワークデバイスに送信する。第１指示情報は、一貫したLBT失敗が発生した第１リソースプールを示す。本方法では、サイドリンクリソースプールまたはキャリアの送信リソースの有効性を保証することができ、かつ、ネットワーク通信の信頼性を改善することができる。
【特許請求の範囲】
【請求項1】
サイドリンク通信方法であって、第１通信デバイスによって、ネットワークデバイスから構成情報を受信するステップであり、
前記構成情報は、第１リソースプールにおいて発生した、一貫したリッスンビフォアトークLBT失敗を検出するために、前記第１通信デバイスによって使用され、
前記構成情報は、第１キャリアまたは前記第１リソースプールに関連付けられ、
前記第１リソースプールは、前記第１キャリアに属している、ステップと、
前記第１通信デバイスによって、第１指示情報を前記ネットワークデバイスに送信するステップであり、
前記第１指示情報は、前記一貫したLBT失敗が発生した前記第１リソースプールを示す、ステップと、
を含む、方法。
【請求項2】
前記構成情報は、前記一貫したLBT失敗の数の最大値およびタイマ長を含み、前記第１通信デバイスの物理PHYエンティティは、前記第１通信デバイスのメディアアクセス制御MACエンティティに対して、前記第１リソースプールにおいて発生した前記LBT失敗を示し、
前記MACエンティティは、前記第１リソースプールに対応しているタイマを開始し、かつ、前記第１リソースプールにおいて発生した前記LBT失敗に基づいて、前記第１リソースプールに対応しているカウンタのカウント値を増加させ、
前記カウンタの前記カウント値が前記最大値に達したときに、前記MACエンティティは、前記第１リソースプールにおいて前記一貫したLBT失敗が発生したと決定する、
請求項１に記載の方法。
【請求項3】
前記方法は、さらに、前記第１通信デバイスによって、既定時間内に、前記第１リソースプールにおけるリソース選択を停止するステップ、または、
前記第１通信デバイスによって、前記第１キャリアの全てのリソースプールにおいて前記一貫したLBT失敗が発生したときに、前記サイドリンクの第２キャリアを再選択するステップ、
を含む、請求項１または２に記載の方法。
【請求項4】
前記方法は、さらに、前記第１通信デバイスによって、第２通信デバイスから第２指示情報を受信するステップであり、
前記第２指示情報は、前記サイドリンク上にあり、かつ、前記一貫したLBT失敗が発生した、第２リソースプールまたは第２キャリアを示す、ステップ、
を含む、請求項１または２に記載の方法。
【請求項5】
前記方法は、さらに、前記第１通信デバイスによって、第３指示情報を前記ネットワークデバイスに送信するステップであり、
前記第３指示情報は、前記第２リソースプールまたは前記第２キャリアを示す、ステップ、
を含む、請求項４に記載の方法。
【請求項6】
前記第３指示情報は、さらに、前記第１通信デバイスと前記第２通信デバイスとの間のユニキャスト接続を示す、請求項５に記載の方法。
【請求項7】
前記方法は、さらに、前記第１通信デバイスによって、第３リソースプールにおけるリソース、または、前記サイドリンク上での第３キャリア上のリソースを選択し、かつ、前記リソースに基づいて、前記第２通信デバイスとユニキャスト接続通信を実行するステップ、を含み、
前記第３リソースプールは、前記第２リソースプールとは異なり、または、前記第３キャリアは、前記第２キャリアとは異なる
請求項６に記載の方法。
【請求項8】
前記方法は、さらに、前記第１通信デバイスによって、サイドリンクグラントリソースを取得するステップであり、
前記グラントリソースは、前記第２リソースプール内または前記第２キャリア上に置かれている、ステップと、
前記第１通信デバイスによって、前記グラントリソースを使用することなく、前記第２通信デバイスと前記ユニキャスト接続通信を実行するステップと、
を含む、請求項６または７に記載の方法。
【請求項9】
前記方法は、さらに、前記第１通信デバイスによって、第４指示情報を第２通信デバイスに送信するステップであり、
前記第４指示情報は、前記一貫したLBT失敗が発生した前記第１リソースプールまたは前記第１キャリアを示す、ステップ、
を含む、請求項１乃至３いずれか一項に記載の方法。
【請求項10】
前記サイドリンクが複数のキャリアを含むときに、前記第１指示情報は、さらに、前記第１リソースプールが属するキャリアを示す、請求項１乃至９いずれか一項に記載の方法。
【請求項11】
前記方法は、さらに、前記第１通信デバイスによって、前記ネットワークデバイスからサイドリンクグラントリソースを受信するステップと、
前記グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、前記第１通信デバイスによって、前記グラントリソース上でのLBT検出をスキップし、または、中断するステップと、
を含む、請求項１乃至７いずれか一項に記載の方法。
【請求項12】
前記方法は、さらに、前記第１通信デバイスによって、前記ネットワークデバイスからサイドリンクグラントリソースを受信するステップと、
前記第１通信デバイスによって、前記グラントリソース上でLBT検出を実行するステップと、
前記グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在する場合に、前記第１通信デバイスによって、否定確認応答NACKを前記ネットワークデバイスにフィードバックするステップと、
前記グラントリソースに対応する前記プロセスにおいて送信されるべきデータが存在しない場合に、前記第１通信デバイスによって、肯定確認応答ACKを前記ネットワークデバイスにフィードバックするステップと、
を含む、請求項１乃至７いずれか一項に記載の方法。
【請求項13】
サイドリンク通信方法であってネットワークデバイスによって、構成情報を第１通信デバイスに送信するステップであり、
前記構成情報は、第１キャリアまたは第１リソースプールに関連付けられており、かつ、前記第１リソースプールは、前記第１キャリアに属している、ステップと、
前記ネットワークデバイスによって、前記第１通信デバイスから第１指示情報を受信するステップであり、
前記第１指示情報は、一貫したLBT失敗が発生した前記第１リソースプールを示す、ステップと、
を含む、方法。
【請求項14】
前記構成情報は、前記LBT失敗の最大回数、および、タイマ長を含む、請求項１３に記載の方法。
【請求項15】
前記第１指示情報は、さらに、前記第１通信デバイスと第２通信デバイスとの間のユニキャスト接続を示す、請求項１３または１４に記載の方法。
【請求項16】
前記サイドリンクが複数のキャリアを含む場合に、前記第１指示情報は、さらに、前記第１リソースプールが属しているキャリアを示す、請求項１３乃至１５いずれか一項に記載の方法。
【請求項17】
サイドリンク通信方法であって、第１通信デバイスによって、第２通信デバイスから第１指示情報を受信するステップであり、
前記第１指示情報は、サイドリンク上にあり、かつ、一貫したリッスンビフォアトークLBT失敗が発生した第１リソースプールまたは第１キャリアを示す、ステップと、
前記第１通信デバイスによって、第２指示情報をネットワークデバイスに送信するステップであり、
前記第２指示情報は、前記第１リソースプールまたは前記第１キャリアを示す、ステップと、
を含む、方法。
【請求項18】
前記第２指示情報は、さらに、前記第１通信デバイスと前記第２通信デバイスとの間のユニキャスト接続を示す、請求項１７に記載の方法。
【請求項19】
前記第１通信デバイスにおいて、第２リソースプールにおけるリソース、または、前記サイドリンク上での第２キャリア上のリソースを選択し、かつ、前記リソースに基づいて、前記第２通信デバイスとユニキャスト接続通信を実行するステップ、を含み、前記第２リソースプールは、前記第２リソースプールとは異なり、または、前記第２キャリアは、前記第２キャリアとは異なる、
請求項１８に記載の方法。
【請求項20】
前記方法は、さらに、前記第１通信デバイスによって、サイドリンクグラントリソースを取得するステップであり、
前記グラントリソースは、前記第１リソースプール内または前記第１キャリア上に置かれている、ステップと、
前記第１通信デバイスによって、前記グラントリソースを使用することなく、前記第２通信デバイスと前記ユニキャスト接続通信を実行するステップと、
を含む、請求項１７乃至１９いずれか一項に記載の方法。
【請求項21】
前記サイドリンクが複数のキャリアを含む場合に、前記第１指示情報は、さらに、前記第１リソースプールが属しているキャリアを示す、請求項１７乃至２０いずれか一項に記載の方法。
【請求項22】
前記方法は、さらに、前記第１通信デバイスによって、前記ネットワークデバイスからサイドリンクグラントリソースを受信するステップと、
前記グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、前記第１通信デバイスによって、前記グラントリソース上でのLBT検出をスキップし、または、中断するステップと、
を含む、請求項１７乃至１９いずれか一項に記載の方法。
【請求項23】
前記方法は、さらに、前記第１通信デバイスによって、前記ネットワークデバイスからサイドリンクグラントリソースを受信するステップと、
前記第１通信デバイスによって、前記グラントリソース上でLBT検出を実行するステップと、
前記グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在する場合に、前記第１通信デバイスによって、否定確認応答NACKを前記ネットワークデバイスにフィードバックするステップと、
前記グラントリソースに対応する前記プロセスにおいて送信されるべきデータが存在しない場合に、前記第１通信デバイスによって、肯定確認応答ACKを前記ネットワークデバイスにフィードバックするステップと、
を含む、請求項１７乃至１９いずれか一項に記載の方法。
【請求項24】
装置であって、請求項１乃至２３いずれか一項に記載の方法を実行するように構成されている、
装置。
【請求項25】
装置であって、前記装置は、プロセッサ、メモリ、および、前記メモリに保管されており、かつ、前記プロセッサ上で実行されることが可能な命令、を含み、
前記命令が実行されると、前記装置は、請求項１乃至１２および１７乃至２３いずれか一項に記載の方法を実行することができる、
装置。
【請求項26】
装置であって、前記装置は、プロセッサ、メモリ、および、前記メモリに保管されており、かつ、前記プロセッサ上で実行されることが可能な命令、を含み、
前記命令が実行されると、前記装置は、請求項１３乃至１６いずれか一項に記載の方法を実行することができる、
装置。
【請求項27】
請求項２５に記載の装置を備える、端末。
【請求項28】
請求項２６に記載の装置を備える、基地局。
【請求項29】
通信システムであって、請求項２７に記載の端末、および、請求項２８に記載の基地局を備える、
通信システム。
【請求項30】
命令を含む、コンピュータ可読記憶媒体であって、前記命令がコンピュータ上で実行されると、前記コンピュータは、請求項１乃至２３いずれか一項に記載の方法を実行することができる、
コンピュータ可読記憶媒体。
【請求項31】
コンピュータプログラム製品であって、前記コンピュータプログラム製品がコンピュータ上で実行されると、前記コンピュータは、請求項１乃至２３いずれか一項に記載の方法を実行することができる、
コンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、無線通信技術の分野に関する。そして、特には、サイドリンク通信方法および装置に関する。
【背景技術】
【0002】
無線通信技術の発展に伴い、将来指向の通信システム、例えば、第５世代移動通信(5th Generation mobile communication、5G)システムまたは新無線(new radio、NR)システムが開発されている。上記の通信システムでは、サイドリンク(sidelink)を介して、端末間で直接通信が実行され得る。サイドリンク通信の典型的な適用シナリオは、車両対全て(vehicle-to-everything、V2X)である。V2Xにおいて、各車両は端末として理解され得る。端末は、サイドリンクを介して相互に通信することができ、例えば、直接接続方式で情報伝送を実行することができる。このことは、通信遅延を効果的に低減する。
【0003】
無線通信は、スペクトルリソースに基づいて実行され、そして、スペクトルリソースは、２つのタイプへと分類され得る。すなわち、ライセンス（licensed）スペクトル(非共有スペクトル)およびアンライセンス（unlicensed）スペクトル(共有スペクトル)である。モバイルデータのサービス量が継続的に増加するにつれて、スペクトルリソースはますます圧迫（strained）されてきている。ライセンススペクトルリソースのみを使用することによって実行されるサービス送信は、サービス量の要件を満たすことができない。従って、ロングタームエボリューション(Long Term Evolution、LTE)システム、新無線(new radio、NR)システムなどにおいて、アンライセンススペクトル上で実行されるサービス送信が検討されている。アンライセンススペクトルは、多くの異なるエアインターフェイス技術、例えば、電気電子技術者協会(Institute of Electrical and Electronics Engineers、IEEE)802.11プロトコルおよびLTEライセンススペクトル支援アクセス(Licensed Assisted Access、LAA)を満たす、無線ローカルエリアネットワークによって共有され得るスペクトルである。
【0004】
アンライセンススペクトルは共有スペクトルリソースであるので、異なるエアインターフェイス技術における異なる通信デバイスが、アンライセンススペクトル上で共存することを確実にするためには、異なる通信デバイス間の相互干渉を回避するためのメカニズムが必要とされる。本メカニズムは、リッスンビフォアトーク(listen before talk、LBT)であり、そして、また、チャネルアクセスプロセスとも称され得る。アンライセンススペクトル上で通信を実行するとき、通信デバイスは、チャネルアクセスプロセスを介して、アンライセンススペクトルにおいてチャネルコンテンション（contention）を実行し得る。チャネルアクセスが成功した場合に、サービス送信は、アンライセンススペクトルを使用することによって実行され得る。チャネルアクセスが失敗した場合に、サービス送信は実行され得ない。
【0005】
しかしながら、前述のソリューションにおいては、端末と基地局との間の無線通信プロセスのみがLBT構成の最中に考慮され、そして、端末間のサイドリンク通信プロセスは考慮されない。従って、サイドリンク通信要件に基づくLBT設計を導入するための技術が提供される必要がある。
【発明の概要】
【0006】
本出願は、端末間の情報伝送を実施するための、サイドリンク通信方法およびデバイスを説明する。
【0007】
第１態様に従って、通信方法が提供される。本方法は、以下を含む。第１通信デバイスは、ネットワークデバイスから構成情報を受信する。構成情報は、第１リソースプールにおいて発生した一貫したリッスンビフォアトークLBT失敗を検出するために第１通信デバイスによって使用され、構成情報は、第１キャリアまたは第１リソースプールに関連付けられ、第１リソースプールは、第１キャリアに属している。加えて、第１通信デバイスは、第１指示情報をネットワークデバイスに送信する。第１指示情報は、一貫したLBT失敗が発生した第１リソースプールを示す。
【0008】
構成情報が第１キャリアまたは第１リソースプールに関連付けられることは、構成が、キャリア粒度または帯域幅部分(bandwidth part、BWP)粒度に基づき得ること、または、リソースプール粒度に基づき得ることであると理解され得る。キャリア粒度は、LBT検出が、粒度としてキャリアを使用することによって独立して構成されるものとして理解され得る。BWP粒度は、LBT検出が粒度としてBWPを使用することによって独立して構成されるものとして理解され得る。リソースプール粒度は、LBT検出が、粒度としてリソースプールを使用することによって独立して構成されるものとして理解され得る。任意的に、１つのキャリアは１つ以上のBWPを含み、１つのBWPは１つ以上のリソースプールを含む。１つのキャリアが１つのBWPを含む場合、BWP粒度はキャリア粒度であり得る。
【0009】
第１通信デバイス、例えば、第１端末は、異なる方法でリソースプール構成を取得し得る。第１方式において、ネットワークデバイス、例えば、基地局は、専用シグナリングまたはシステムブロードキャストを介して、第１端末のためのリソースプールを構成する。第２方式において、第１端末は、事前構成に基づいてリソースプールを取得する。
【0010】
本通信方式に基づいて、端末間のサイドリンク通信のフレキシブルな構成を実施することができ、システム適応の信頼性を改善することができる。
【0011】
サイドリンクリソースを取得する方式は、基地局スケジューリングモード(Mode １、モード1)およびUE選択モード(Mode 2、モード2)へと分類され得ることが理解され得る。基地局スケジューリングモード(モード1)において、基地局は、現在スケジューリングされているリソースが属しているリソースプールを指示することができる。UE選択モード(モード2)において、UEがサイドリンクリソースを決定した後で、UEの挙動は、基地局スケジューリングモードにおける基地局の挙動と同様である。しかしながら、サイドリンクリソースを決定する前に、UEは、リソースプールを自律的に選択する必要がある。具体的に、モード2について、前述の選択は、ランダムに実行されてよく、もしくは、検知(sensing)または部分的検知(partial sensing)の結果に基づいて実行されてよい。
【0012】
一般的に、チャネルアクセスプロセスが実行されるときに、２つの結果が取得され得る。すなわち、チャネルアクセスプロセスが完了したこと(LBT成功としても、また、称される)、および、チャネルアクセスプロセスが完了していないこと(LBT失敗としても、また、称される)である。データ伝送に使用される時間周波数リソースにおいて、複数の時間領域開始位置が存在している。任意の時間領域開始位置の前に、チャネルがアイドルであると決定された場合には、チャネルアクセスプロセスが完了したものと見なされ得る。全ての時間領域開始位置の前に、チャネルがビジーであると決定された場合には、チャネルアクセスプロセスは完了していないものと見なされ得る。
【0013】
一貫したLBT失敗が、キャリア上で、または、サイドリンク上のリソースプールにおいて発生したと決定したとき、第１端末は、LBT失敗を示すメディアアクセス制御(medium access control、MAC)制御要素(control element、CE)をネットワークデバイスに送信し得る。MAC CEは、複数のリソースプール識別子フィールドを含むことができ、そして、さらに、リソースプールが属しているキャリアに関する情報、例えば、キャリア識別子フィールドを含み得る。
【0014】
可能な実装において、構成情報は、LBT失敗の数の最大値およびタイマ長を含む。第１通信デバイスの物理(physical、PHY)エンティティは、第１通信デバイスのメディアアクセス制御(MAC)エンティティに対して、第１リソースプールにおいて発生したLBT失敗を示す。MACエンティティは、第１リソースプールに対応するタイマを開始し、かつ、第１リソースプールにおいて発生したLBT失敗に基づいて、第１リソースプールに対応するカウンタのカウント値を増加させる。カウンタのカウント値が最大値に達したときに、MACエンティティは、第１リソースプールにおいて一貫したLBT失敗が発生したと決定する。
【0015】
前述のLBT検出は、第１通信デバイスが、可能なLBT失敗ステータスをリアルタイムで知ることを確保し、タイムリーな方法で処理を実行し、かつ、サイドリンク通信の有効性を保証する。
【0016】
可能な実装において、第１通信デバイスは、既定時間内に、第１リソースプールにおけるリソース選択を停止する。代替的に、第１キャリアの全てのリソースプールにおいて一貫したLBT失敗が発生したときに、第１通信デバイスは、サイドリンクの第２キャリアを再選択する。
【0017】
任意的に、第１通信デバイスは、第２通信デバイスから第２指示情報を受信する。ここで、第２指示情報は、サイドリンク上にあり、かつ、一貫したLBT失敗が発生した、第２リソースプールまたは第２キャリアを示す。
【0018】
第２指示情報に基づいて、第１通信デバイスは、第２リソースプールまたは第２キャリアに基づき第２通信デバイスとサイドリンク通信を実行するか否かを決定してよく、例えば、既定時間内に前述のリソースを使用しないか、または、別のリソースを使用するように変更して、信頼できる通信を保証する。
【0019】
可能な実装において、第１通信デバイスは、第３指示情報をネットワークデバイスに送信する。ここで、第３指示は、第２リソースプールまたは第２キャリアを示す。
【0020】
サイドリンク通信システムにおいて、基地局は、リソース構成の一貫性を保証するために、基地局によってサービスされる端末について同じリソースプール構成を提供し得ることが理解され得る。例えば、第１通信デバイスのサービング基地局によって第１通信デバイスに提供されるリソースプール構成は、第２通信デバイスのサービング基地局によって第２通信デバイスに提供されるリソースプール構成と同じである。この場合、第１通信デバイスが、第２通信デバイスに対して、一貫したLBT失敗が発生したリソースプールを示すとき、第２通信デバイスは、正しく理解することができる。
【0021】
可能な実装において、第３指示情報は、さらに、第１通信デバイスと第２通信デバイスとの間のユニキャスト接続を示す。本指示は、ネットワークデバイスが、一貫したLBT失敗が発生した特定の接続を検知し、それに応じて、区別された処理を実行することを可能にし、その結果、ユニキャスト接続通信の信頼性が保証される一方で、他のユニキャスト/ブロードキャスト/マルチキャストサイドリンク通信は影響を受けない。
【0022】
第３情報に基づいて、ネットワークデバイスは、第１通信デバイスに対して前述のリソースをスケジューリングしなくてよく、または、別のリソースプールもしくはキャリアに基づいて、第１通信デバイスに対してリソースをスケジューリングしてよく、第１通信デバイスと第２通信デバイスとの間のリアルタイムの有効な通信を保証し、そして、スケジューリングの信頼性を向上させる。
【0023】
可能な実装において、第１通信デバイスは、サイドリンク上の第３リソースプールにおけるリソース、または、第３キャリア上のリソースを選択し、かつ、当該リソースに基づいて、第２通信デバイスとユニキャスト接続通信を実行する。
【0024】
第３リソースプールは第２リソースプールとは異なり、または、第３キャリアは第２キャリアとは異なる。
【0025】
前述の方式においては、リソース選択の最中に、一貫したLBT失敗が発生した、識別されたリソースが、ユニキャスト接続のために選択されるケースが回避され得る。このことは、第１通信デバイスと第２通信デバイスとの間での信頼できるユニキャスト接続通信を確実にする。
【0026】
例えば、第１通信デバイスは、サイドリンク上の別のリソースプールにおけるリソースまたは別のキャリア上のリソースを選択し、そして、当該リソースに基づいて、第２通信デバイスとユニキャスト接続通信を実行する。別のリソースプールは、一貫したLBT失敗が発生したリソースプールとは異なり、または、別のキャリアは、一貫したLBT失敗が発生したキャリアとは異なる。代替的に、第１通信デバイスは、サイドリンクグラントリソースを取得する。グラントリソースは、一貫したLBT失敗が発生したリソースプール、または、一貫したLBT失敗が発生したキャリアに置かれている。従って、第１通信デバイスは、UE1とユニキャスト接続通信を実行するために、サイドリンクグラントリソースを使用しない。
【0027】
可能な実装において、第１通信デバイスは、サイドリンクグラントリソースを取得する。ここで、グラントリソースは、第２リソースプール内または第２キャリア上に置かれている。
【0028】
第１通信デバイスは、第２通信デバイスとユニキャスト接続通信を実行するために、グラントリソースを使用しない。
【0029】
より多くの適合性が考慮されるシナリオにおいて、第１通信デバイスは、各グラントリソースが適用可能であるか否かを決定し、第１通信デバイスと第２通信デバイスとの間の信頼できるユニキャスト接続通信を保証する。
【0030】
例えば、第１通信デバイスのMACエンティティは、論理チャネル優先順位付け(logical channel prioritization、LCP)プロセスを実行し得る。例えば、第１通信デバイスのMAC層がLCPプロセスを行う場合、第１通信デバイスと第２通信デバイスとの間のユニキャスト接続は、除外される。物理層が、MACエンティティに対して、現在のスケジューリングされたリソースが別のリソースプールまたはキャリアに属し、かつ、別のリソースプールまたはキャリアがユニキャスト接続通信のために使用され得ることを示す場合に、第１通信デバイスは、優先度に基づいて、ユニキャスト接続上でデータを送信するためにリソースを使用すべきか否かを決定し得る。
【0031】
可能な実装において、第１通信デバイスは、第４指示情報を第２通信デバイスに送信する。ここで、第４指示情報は、一貫したLBT失敗が発生した第１リソースプールまたは第１キャリアを示す。従って、第２通信デバイスが、一貫したLBT失敗が発生したリソースに基づいて、第１通信デバイスにデータを送信するケースが、回避され得る。このことは、信頼性を向上させる。
【0032】
可能な実装において、サイドリンクが複数のキャリアを含むときに、第１指示情報は、さらに、第１リソースプールが属するキャリアを示し、リソースプールの正確な指示を保証する。
【0033】
可能な実装において、第１通信デバイスは、ネットワークデバイスからサイドリンクグラントリソースを受信する。グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、第１通信デバイスは、グラントリソース上でのLBT検出をスキップし、または、中断する。従って、不必要なLBTを回避することができ、そして、電力が節約される。
【0034】
可能な実装において、第１通信デバイスは、ネットワークデバイスからサイドリンクグラントリソースを受信し、そして、第１通信デバイスは、グラントリソースに対してLBT検出を実行する。グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在する場合に、第１通信デバイスは、否定確認応答(negative acknowledgement、NACK)をネットワークデバイスにフィードバックする。代替的に、グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、第１通信デバイスは、肯定応答(acknowledgement、ACK)をネットワークデバイスにフィードバックする。従って、第１通信デバイスは、適切なシナリオで基地局にNACKを示すことが可能になり、タイムリーに再送スケジューリングおよび信頼できる通信を保証する。
【0035】
通信デバイスの前述の挙動に基づいて、ネットワークデバイスが無効な、または、無用なリソーススケジューリングを実行するケースが、回避され得る。このことは、リソーススケジューリングの有効性を達成する。
【0036】
可能な実装において、通信デバイスは端末であり、そして、ネットワークデバイスは基地局であり、または、ネットワークデバイスは中央ユニット(central unit、CU)である。
【0037】
第２態様に従って、サイドリンク通信方法が提供される。本方法は、以下を含む。第１通信デバイスは、第２通信デバイスから第１指示情報を受信する。ここで、第１指示情報は、サイドリンク上にあり、かつ、LBT失敗が発生した第１リソースプールまたは第１キャリアを示す。加えて、第１通信デバイスは、第２指示情報をネットワークデバイスに送信する。ここで、第２指示情報は、第１リソースプールまたは第１キャリアを示す。
【0038】
可能な実装において、第２指示情報は、さらに、第１通信デバイスと第２通信デバイスとの間のユニキャスト接続を示す。
【0039】
可能な実装において、第１通信デバイスは、第２リソースプールにおけるリソース、または、サイドリンク上での第２キャリア上のリソースを選択し、かつ、前記リソースに基づいて、前記第２通信デバイスとユニキャスト接続通信を実行する。
【0040】
第２リソースプールは第２リソースプールとは異なり、または、第２キャリアは第２キャリアとは異なる。
【0041】
可能な実装において、第１通信デバイスは、サイドリンクグラントリソースを取得する。ここで、グラントリソースは、第１リソースプール内または第１キャリア上に置かれている。第１通信デバイスは、グラントリソースを使用することなく、第２通信デバイスとユニキャスト接続通信を実行する。
【0042】
可能な実装において、サイドリンクが複数のキャリアを含む場合に、第１指示情報は、さらに、第１リソースプールが属しているキャリアを示す。
【0043】
可能な実装において、第１通信デバイスは、ネットワークデバイスからサイドリンクグラントリソースを受信する。グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、第１通信デバイスは、グラントリソース上でのLBT検出をスキップし、または、中断する。
【0044】
可能な実装において、第１通信デバイスは、ネットワークデバイスからサイドリンクグラントリソースを受信する。第１通信デバイスは、グラントリソース上でLBT検出を実行する。グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在する場合に、第１通信デバイスは、NACKをネットワークデバイスにフィードバックする。代替的に、グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、第１通信デバイスは、ACKをネットワークデバイスにフィードバックする。
【0045】
可能な実装において、通信デバイスは端末であり、ネットワークデバイスは基地局であり、または、ネットワークデバイスはCUである。
【0046】
第３態様に従って、サイドリンク通信方法が提供される。本方法は、以下を含む。ネットワークデバイスは、構成情報を第１通信デバイスに送信する。ここで、構成情報は、第１キャリアまたは第１リソースプールに関連付けられ、かつ、第１リソースプールは、第１キャリアに属している。加えて、ネットワークデバイスは、第１指示情報を第１通信デバイスから受信する。ここで、第１指示情報は、一貫したLBT失敗が発生した第１リソースプールを示す。
【0047】
可能な実装において、構成情報は、LBT失敗の数の最大値およびタイマ長を含む。
【0048】
可能な実装において、第１指示情報は、さらに、第１通信デバイスと第２通信デバイスとの間のユニキャスト接続を示す。
【0049】
可能な実装において、サイドリンクが複数のキャリアを含む場合に、第１指示情報は、さらに、第１リソースプールが属しているキャリアを示す。
【0050】
第４態様に従って、サイドリンク通信において使用される装置が提供される。本装置は、第１態様、第２態様、並びに、第１態様および第２態様の任意の可能な実装形態における通信デバイスの動作を実行するように構成され得る。具体的に、装置は、第１態様または第２態様の任意の可能な実装における通信デバイスの動作を実行するように構成されたモジュールおよびユニットを含み得る。
【0051】
第５態様に従って、サイドリンク通信において使用される装置が提供される。本装置は、第３態様および第３態様の任意の可能な実装におけるネットワークデバイスの動作を実行するように構成され得る。具体的に、装置は、第３態様の任意の可能な実装におけるネットワークデバイスの動作を実行するように構成されたモジュールおよびユニットを含み得る。
【0052】
第６態様に従って、端末デバイスが提供される。本端末デバイスは、プロセッサ、トランシーバ、およびメモリを含む。プロセッサ、トランシーバ、およびメモリは、内部接続経路を介して、相互に通信する。メモリは、命令を保管するように構成されており、かつ、プロセッサは、メモリに保管された命令を実行するように構成されている。プロセッサがメモリに保管された命令を実行すると、その実行は、端末デバイスが、第１態様または第２態様の任意の可能な実装における任意の方法を実行することを可能にするか、または、その実行は、端末デバイスが、第４態様において提供される装置を実装することを可能にする。
【0053】
第７態様に従って、ネットワークデバイスが提供される。本ネットワークデバイスは、プロセッサ、トランシーバ、およびメモリを含む。プロセッサ、トランシーバ、およびメモリは、内部接続経路を介して、相互に通信する。メモリは、命令を保管するように構成されており、かつ、プロセッサは、メモリに保管された命令を実行するように構成されている。プロセッサがメモリに保管された命令を実行すると、その実行は、ネットワークデバイスが第３態様の任意の可能な実装における任意の方法を実行することを可能にするか、または、その実行は、ネットワークデバイスが第５態様において提供される装置を実装することを可能にする。
【0054】
第８態様に従って、メモリおよびプロセッサを含む、チップシステムが提供される。メモリは、コンピュータプログラムを保管するように構成されており、そして、プロセッサは、メモリからコンピュータプログラムを呼び出し、かつ、コンピュータプログラムを実行するように構成されており、その結果、チップシステムがインストールされたデバイス(例えば、ネットワークデバイスまたは端末デバイス)は、第１態様、第２態様、または第３態様、および、第１態様、第２態様、または第３態様の可能な実装形態のうちのいずれか１つにおける任意の方法を実行する。
【0055】
第９態様に従って、コンピュータプログラム製品が提供される。本コンピュータプログラム製品は、コンピュータプログラムコードを含む。コンピュータプログラムコードが、通信ユニットおよび処理ユニットによって、または、デバイス(例えば、ネットワークデバイスまたは端末デバイス)のトランシーバおよびプロセッサによって実行されるとき、通信デバイスは、第１態様、第２態様、または第３態様、および、第１態様、第２態様、または第３態様の可能な実装のうちのいずれか１つにおける任意の方法を実行する。
【0056】
第１０態様に従って、コンピュータ可読記憶媒体が提供される。本コンピュータ可読記憶媒体は、プログラムを保管し、そして、プログラムは、デバイス(例えば、ネットワークデバイスまたは通信デバイス)が、第１態様、第２態様、または第３態様、および、第１態様、第２態様、または第３態様の可能な実装のうちのいずれか１つにおける任意の方法を実行することを可能にする。
【0057】
第１１態様に従って、コンピュータプログラムが提供される。本コンピュータプログラムが、コンピュータ上で実行されるとき、コンピュータは、第１態様、第２態様、または第３態様、および、第１態様、第２態様、または第３態様の可能な実装のうちのいずれか１つにおける任意の方法を実施することが可能にされる。
【図面の簡単な説明】
【0058】
【発明を実施するための形態】
【0059】
以下は、本発明の実施形態における添付の図面を参照して、本発明の実施形態における技術的ソリューションを明確かつ完全に説明する。
【0060】
異なる通信シナリオでは端末間の送信を実行することができないという従来技術における問題を解決するために、本発明の実施形態は、通信システムにおける送信有効性（validity）を改善するために、図1aの通信システムに基づく技術的ソリューションを提供する。
【0061】
図1aは、本出願の実施形態が適用可能である、可能なシステムアーキテクチャの概略図である。図1aに示されるシステムアーキテクチャは、第２デバイス101および第１デバイス102を含んでいる。本出願のこの実施形態における第２デバイスは、無線方式で第１デバイスに接続されてよい。別の言葉で言えば、第２デバイスは、ワイヤレスネットワークを介して、第１デバイスと通信し得る。図1aは、単に通信システムアーキテクチャの概略図に過ぎないことが理解されるべきである。通信システムにおける第１デバイスの数および第２デバイスの数は、本出願の実施形態において限定されない。この実施形態において、無線方式は、サイドリンク通信及び／又は無線リンク通信として理解されてよい。
【0062】
一つの例において、前述のシステムアーキテクチャにおける第１デバイスおよび第２デバイスは、サイドリンク通信を実行し得る。図1bは、サイドリンク通信シナリオの概略図である。図1bに示されるように、通信シナリオには、ネットワークデバイス105、および、１つ以上の端末デバイス(例えば、端末デバイス1061および端末デバイス1062)が含まれてよい。ネットワークデバイス105と、端末デバイス1061および端末デバイス1062それぞれとの間で、エアインターフェイスリソースを介して、データ伝送が実行され、そして、端末デバイス1061と端末デバイス1062との間で、サイドリンクリソースを介して、データ伝送が実行され得る。第１デバイスは端末デバイス1061であり、かつ、第２デバイスは端末デバイス1062であってよく、もしくは、その逆であってもよい。図1bでは、一つの例として、アップリンク送信が使用されている。ネットワークデバイス105と端末デバイス(端末デバイス1061または端末デバイス1062)との間でアップリンクデータ送信が実行されるデータチャネルは、第１アップリンク(uplink、UL)キャリアまたは補助アップリンク(supplementary UL、SUL)キャリア上で搬送され得る。端末デバイス1061と端末デバイス1062との間でデータ送信が実行されるデータチャネルは、SLキャリア上で搬送され得る。一つの例において、SLキャリアは、第２ULキャリアであり得る。第１ULキャリアおよび第２ULキャリアは、同じキャリアであり得る。
【0063】
サイドリンク(sidelink、SL)通信は、端末デバイスが相互に通信することを可能にする技術であり、そして、端末デバイスの通信を搬送するために使用されるリソースは、サイドリンクリソースと称され得る。サイドリンク通信は、異なる端末デバイス間の直接通信を実施することができるので、高データレート、低遅延、および、低消費電力を実施することができる。サイドリンク通信は、例えば、車車間(vehicle-to-vehicle)、路車間(vehicle-to-infrastructure)、歩車間(vehicle-to-pedestrian)、および、デバイス間(device-to-device)の通信を含み得る。産業用インターネット通信シナリオおよび無線グリッドネットワーク通信シナリオの両方において、サイドリンク通信技術が使用され得ることが理解されるだろう。
【0064】
図1cに示されるように、通信システムは、少なくとも中央ユニット(central unit、CU)10cおよび分散ユニット(distributed、DU)11cを含んでいる。DU 11cは、端末12cと通信する。例えば、NR基地局のいくつかの機能はCUに配備され、そして、残りの機能はDUに配備されている。この場合には、１つ以上のDUが存在してよく、そして、複数のDUが１つのCUを共有してもよい。このことは、コストを削減し、ネットワーク拡張を容易にする。具体的に、CU-DU分割は、プロトコルスタックに基づいて実行され得る。可能な方式において、以下のプロトコル層のうちの少なくとも１つが、CU上に配備される。すなわち、無線リソース制御(Radio Resource Control、RRC)層、サービスデータ適応プロトコル(service data adaptation protocol、SDAP)層、および、パケットデータコンバージェンスプロトコル(Packet Data Convergence Protocol、PDCP)層である。以下の残りのプロトコル層のうちの少なくとも１つが、DU上に展開される。すなわち、無線リンク制御(Radio Link Control、RLC)層、メディアアクセス制御(Media Access Control、MAC)層、または、物理層である。CUおよびDUは、F1インターフェイスを介して、接続され得る。CUは、NR基地局とNRコアネットワークとの間の接続を表している。当業者であれば、CUおよびDUが異なる物理エンティティ上に位置し得るか、または、NR基地局から独立し得ることを理解するだろう。別の言葉で言えば、CUおよびDUは、NR基地局の機能を実装するため、または、NR基地局を置換するために組み合わされる。
【0065】
前述のネットワークアーキテクチャにおいては、CUによって生成されたシグナリング（signaling）が、DUを介して端末デバイスに送信されてよく、または、端末デバイスによって生成されたシグナリングが、DUを介してCUに送信されてもよい。DUは、シグナリングを構文解析（parsing）することなく、プロトコル層においてシグナリングを直接的にカプセル化することによって、端末デバイスまたはCUに対して、シグナリングを透過的に送信し得る。以下の実施形態において、DUと端末デバイスとの間のそうしたシグナリングの送信が関与する場合に、DUによるシグナリングの送信または受信は、このシナリオを含む。例えば、RRCまたはPDCP層でのシグナリングは、端末デバイスに送信されるように、最終的にPHY層におけるシグナリングとして処理され、または、受信されたPHY層のシグナリングから変換される。このアーキテクチャにおいては、RRC層またはPDCP層におけるシグナリングが、DUによって送信されるか、または、DUおよび無線周波数装置によって送信されることが、代替的に考えられてもよい。
【0066】
本発明の実施形態で説明されるシステムアーキテクチャおよびサービスシナリオは、本発明の実施形態における技術的ソリューションをより明確に説明するように意図されたものであり、そして、本発明の実施形態で提供される技術的ソリューションに対する限定を構成するものではない。当業者であれば、以下のことを知っているだろう。すなわち、ネットワークアーキテクチャの進化、および、新しいサービスシナリオの出現に伴い、本発明の実施形態で提供される技術的ソリューションは、また、同様の技術的問題にも適用可能であること。
【0067】
本出願の実施形態における技術的ソリューションは、移動通信用グローバルシステム(global system for mobile communication、GSM(登録商標))、符号分割多元接続(code division multiple access、CDMA)システム、広帯域符号分割多元接続(wideband code division multiple access、WCDMA(登録商標))システム、汎用パケット無線サービス(general packet radio service、GPRS)システム、ロングタームエボリューション(long term evolution、LTE)システム、LTE周波数分割複信(frequency division duplex、FDD)システム、LTE時分割複信(time division duplex、TDD)システム、ユニバーサル移動体通信システム(universal mobile telecommunications system、UMTS)、マイクロ波アクセス用ワールドワイドインターオペラビリティ(worldwide interoperability for microwave access、WiMAX)通信システム、将来の第５世代(5th generation、5G)システム、新しい無線(new radio、NR)システムといった様々な通信システムに対して適用され得る。本出願の実施形態における技術的ソリューションは、さらに、デバイスツーデバイス(device-to-device、D2D)通信、マシンツーマシン(machine-to-machine、M2M)通信、マシンタイプ通信(machine type communication、MTC)、および、車両のインターネットシステムにおける通信に対して適用され得る。車両インターネットシステムにおける通信方式は、V2X(Xは全て（everything）を表す)と総称される。例えば、V2X通信は、車車間(vehicle-to-vehicle、V2V)通信、路車間(vehicle-to-infrastructure、V2I)通信、歩車間(vehicle-to-pedestrian、V2P)通信、または車両対ネットワーク(vehicle-to-network、V2N)通信を含む。
【0068】
通信システムにおけるネットワークデバイスは、ワイヤレストランシーバ機能を有する任意のデバイス、または、デバイス内に配置され得るチップであってよい。デバイスは、これらに限定されるわけではないが、ワイヤレスフィデリティ(wireless fidelity、Wi-Fi)システムにおける、発展型ノードB(evolved NodeB、eNB)、無線ネットワークコントローラ(radio network controller、RNC)、ノードB(NodeB、NB)、基地局コントローラ(base station controller、BSC)、基地トランシーバ局(base transceiver station、BTS)、ホームノードB(例えば、home evolved NodeB、または、home NodeB、HNB)、ドナーeNB(donor eNB、DeNB)、ベースバンドユニット(baseband Unit、BBU)、アクセスポイント(access point、AP)、ワイヤレス中継ノード、ワイヤレスバックホールノード、送信ポイント(transmission point、TP)、送受信ポイント(transmission and reception point、TRP)などを含む。代替的に、デバイスは、5Gシステム、例えば、NRシステムにおけるgNBまたは送信ポイント(TRPまたはTP)であってよく、5Gシステムにおける基地局のアンテナパネルまたはアンテナパネルのグループ(複数のアンテナパネルを含む)であってよく、または、ネットワークノード、例えば、gNBまたは送信ポイントを構成するベースバンドユニット(BBU)または分散ユニット(distributed unit、DU)であり得る。
【0069】
いくつかの展開において、gNBは、CUおよびDUを含み得る。gNBは、さらに、無線周波数ユニット(radio frequency unit、RFU)を含み得る。CUは、gNBのいくつかの機能を実装し、そして、DUは、gNBのいくつかの機能を実装する。RRC層での情報は、最終的にはPHY層での情報になるか、または、PHY層での情報から変換される。従って、アーキテクチャにおいて、RRC層シグナリングまたはPHCP層シグナリングといった上位層シグナリングは、代替的に、DUによって送信される、または、DUおよびRUによって送信されるものと見なされ得る。ネットワークデバイスは、CUノード、DUノード、または、CUノードおよびDUノードを含むデバイスであってよいことが理解され得る。加えて、CUは、アクセスネットワークRAN内のネットワークデバイスとして分類されてよく、または、CUは、コアネットワークCN内のネットワークデバイスとして分類されてよい。これは、本明細書では限定されない。
【0070】
通信システムにおける端末デバイスは、また、ユーザ機器(user equipment、UE)、アクセス端末、加入者ユニット、加入者局、移動局、移動局、遠隔局、遠隔端末、モバイルデバイス、ユーザ端末、端末、ワイヤレス通信デバイス、ユーザエージェント、またはユーザ装置とも称される得ることが、さらに、理解されるべきである。本出願の実施形態における端末デバイスは、携帯電話(mobile phone)、タブレット(Pad)、無線トランシーバ機能を有するコンピュータ、仮想現実(virtual reality、VR)端末デバイス、拡張現実(augmented reality、AR)端末デバイス、産業制御(industrial control)における無線端末、自動運転(self-driving)における無線端末、遠隔医療(remote medical)における無線端末、スマートグリッド(smart grid)における無線端末、交通安全(transportation safety)における無線端末、スマートシティ(smart city)における無線端末、スマートホーム(smart home)における無線端末、などであり得る。適用シナリオは、本出願の実施形態において限定されない。本出願において、前述の端末デバイスおよび前述の端末デバイスに配置され得るチップは、端末デバイスと総称される。本出願の理解を容易にするために、本出願で提供される通信方法が説明される前に、本出願における概念が、最初に、簡潔に説明される。
【0071】
理解を容易にするために、本出願の実施形態における関連用語および技術が、最初に、簡潔に説明される。
【0072】
スプレッドタイプのサイドリンク通信
【0073】
サイドリンク通信システムは、無線通信システムと同様であり、そして、また、ブロードキャスト、ユニキャスト、およびマルチキャスト送信方式をサポートすることもできる。ブロードキャスト通信は、基地局が端末にシステム情報をブロードキャストする場合と同様である。例えば、基地局は、ブロードキャストサービスのデータを暗号化することなくUEに送信し、そして、UEがブロードキャストサービスに関心がある場合には、有効受信範囲内の別のUEがブロードキャストサービスデータを受信し得る。ユニキャスト通信は、UEと基地局との間でRRC接続が確立された後に実行されるデータ通信と同様である。ユニキャスト接続は、２つのUE間で、最初に、確立される必要がある。ユニキャスト接続が確立された後で、２つのUEは、ネゴシエートされた識別子に基づいて、データ通信を実行し得る。データは、暗号化されても、されなくてもよい。ブロードキャスト通信と比較して、ユニキャスト通信は、ユニキャスト接続を確立する２つのUE間でのみ実行され得る。マルチキャスト通信は、通信グループ内の全てのUE間の通信を指し、そして、グループ内の任意のUEは、マルチキャストサービスのデータを受信および送信することができる。
【0074】
具体的に、ブロードキャスト送信は、ブロードキャストサイドリンク信号通信と称されてよく、もしくは、ブロードキャストサービスのサイドリンク通信、または、送信タイプがブロードキャストであるサイドリンク通信と称されてよい。マルチキャスト送信は、マルチキャストサイドリンク信号通信と称されてよく、もしくは、マルチキャストサービスのサイドリンク通信、または、送信タイプがマルチキャストであるサイドリンク通信と称されてよい。ユニキャスト通信は、ユニキャストサイドリンク信号通信と称されてよく、もしくは、ユニキャストサービスのサイドリンク通信、または、送信タイプがユニキャストであるサイドリンク通信と称されてよい。
【0075】
前述のスプレッドタイプのいずれか１つに基づいて、データ送信がサイドリンク上で実行されるときに、送信元識別子(source ID)および宛先識別子(destination ID)が搬送される必要がある。この実施形態において、識別子は、UEの層2(layer 2、L2)についてのものである。具体的に、UEの上位層はP、C5-S層であり、そして、UE間の通信に使用される。上位層は、非アクセス階層(Non-access stratum、NAS)、V2X層、またはPC5-S層と称され得る。UEの層2は、AS層であってよく、そして、端末と基地局との間の通信に使用される。ブロードキャスト通信について、宛先識別子は、ブロードキャストサービスに対応し、そして、送信元識別子は、送信側UEの識別子として理解されてよい。ユニキャスト通信について、宛先識別子は、受信側UEによってユニキャスト接続に割り当てられたL2識別子であり、そして、送信元識別子は、送信側UEによってユニキャスト接続に割り当てられたL2識別子である。マルチキャスト通信について、宛先識別子は、グループに対応し、そして、送信元識別子は、送信側UEの識別子として理解されてよい。
【0076】
可能な方法において、図2aおよび図2bに示されるように、データは、D2DまたはV2Xサイドリンク(sidelink、SL)上で受信および送信される。SLは、図2aに示されるD2Dリンク、および、図2bに示されるSLリンクを意味する。SL上で、端末デバイス間で送信されるデータは、ネットワークデバイスによって転送されなくてよい。別の言葉で言えば、SLは、端末デバイス間の伝送リンクであってよい。
【0077】
図2bに示されるように、車両は、V2V、V2I、V2P、またはV2N通信を介して、タイムリーに道路状況情報を取得し、または、情報サービスを受信することができる。これらの通信方式は、V2X通信と総称され得る。図2bにおいて、図(1)、図(2)、図(3)は、それぞれに、V2V、V2I、V2P通信の模式図である。110はネットワークデバイスである。120は車両を表し、130は路側インフラストラクチャを表し、そして、140は歩行者を表し得る。最も一般的なV2V通信およびV2I通信が一つの例として使用されている。図2bの図(1)に示されるように、車両は、V2V通信を介して、周辺車両に対して、車両の速度、走行方向、特定位置、非常ブレーキの有無といった車両に関する情報をブロードキャストすることができる。周辺車両の運転者は、この情報を取得して、見通し外の交通状況をよりよく把握し、危険な状況を事前に予測し、そして、危険な状況を回避することができる。図2bの図(2)に示されるV2I通信について、セキュリティ情報の前述の交換に加えて、路側インフラストラクチャ、例えば、路側ユニット(roadside unit、RSU)は、車両のための様々なタイプのサービス情報およびデータネットワークアクセスを提供することができ、そして、電子料金徴収および車載エンターテインメントといった機能は、交通インテリジェンスを大幅に改善する。
【0078】
サイドリンクリソース
【0079】
サイドリンクリソースは、端末間の通信のために使用されるリソースである。サイドリンクリソースは、周波数領域におけるサイドリンクリソース、および、時間領域におけるサイドリンクリソースを含み得る。加えて、本出願におけるサイドリンクリソースは、また、サイドリンクまたはサイドリンクとしても称され得る。以下では、統一された方法でサイドリンクを説明する。
【0080】
送信タイプの観点から、サイドリンクリソースは、サイドリンク送信リソースおよびサイドリンク受信リソースを含み得る。サイドリンク送信リソースは、情報を送信するため、例えば、制御情報及び／又はデータを送信するために使用される。サイドリンク受信リソースは、情報を受信するため、例えば、制御情報及び／又はデータを受信するために使用される。当業者であれば、送信リソースおよび受信リソースが同じ時間領域及び／又は周波数領域範囲に配置され得ることを理解するだろう。例えば、時分割システムに基づいて、送信および受信は、同じ周波数領域リソースを共有し得る。周波数分割システムに基づいて、送信および受信は、同じ時間領域リソースを共有することができる。
【0081】
任意的に、サイドリンク信号は、サイドリンクチャネル上で搬送される制御情報、及び／又はデータ、及び／又はフィードバック情報を含み得る。
【0082】
任意的に、制御情報は、データをスケジューリングするために使用される情報、例えば、従来技術におけるダウンリンク制御情報(downlink control information、DCI)、および、サイドリンク制御情報(sidelink control information、SCI)であり得る。フィードバック情報は、例えば、従来技術におけるアップリンク制御情報(uplink control information、UCI)、および、サイドリンクフィードバック情報(sidelink feedback information、SFI)をフィードバックするための情報であり得る。制御情報は、制御チャネル、例えば、PSCCH、すなわち、物理サイドリンク制御チャネル上で搬送され得る。フィードバック情報は、フィードバックチャネル、例えば、PSFCH、すなわち、物理サイドリンクフィードバックチャネル上で搬送され得る。
【0083】
任意的に、データは、広い意味での信号であってよく、データパケットであってよく、もしくは、トランスポートブロックまたはコードワードであってよい。データは、データチャネル、例えば、物理サイドリンク共有チャネル(physical sidelink shared channel、PSSCH)上で搬送され得る。
【0084】
サイドリンクデータ無線ベアラ
【0085】
NRサイドリンクネットワークにおける通信は、サービスフローに基づいて分類され得る。例えば、IPフローまたはイーサネット(登録商標)フローは、異なるサービスに対応するものとして理解され得る。前述のサービスフローは、異なるQoSパラメータまたは特徴に基づいて、異なるサービス品質(quality of service、QoS)フローに分類される。具体的に、基地局は、QoSフローをサイドリンクデータ無線ベアラ(data radio bearer、DRB)にマッピングし、または、QoSフローとサイドリンクDRBとの間のマッピング関係を定義し得る。例えば、基地局は、異なるQoSフローを異なるサイドリンクDRBにマッピングし、または、類似のパラメータを有するQoSフローを同じサイドリンクDRBにマッピングする。端末は、マッピング関係に基づいて、サイドリンクDRBを確立し、そして、サイドリンクDRBを介して、対応するQoSフローを別の端末に送信し得る。サイドリンクDRBは、端末間でデータを送信するために使用されるDRBである。任意的に、端末は、事前構成に基づいて、代替的にマッピング関係を決定し、そして、サイドリンクDRBを確立し得る。
【0086】
サイドリンク論理チャネル
【0087】
データは、端末の異なるタイプの送信サービスに基づいて分類され、そして、異なる論理チャネルに対応し得る。それに対応して、論理チャネル情報は、論理チャネル(logic channel、LCH)識別子、及び／又は、論理チャネルグループ(logic channel group、LCG)識別子であってよい。当業者であれば、論理チャネルまたは論理チャネルグループを識別するために使用される任意の識別子が本発明の保護範囲内に入ることを理解し得る。LCGは、少なくとも１つのLCHを含み得る。例えば、4個のLCHまたは8個のLCHが、それぞれ、１つのLCGを形成し得る。違いは、異なる量のLCHによって形成されるLCGのデータ量が異なることである。一般的に、異なるLCHに対応するリソースタイプは、同じであっても、または異なってもよく、１つのLCG内の異なるLCHに対応しているリソースタイプは、同じであっても、または異なってもよく、そして、１つのLCHは、少なくとも１つのリソースタイプに対応し得る。別の例について、異なるLCH/LCGの優先順位シーケンスは、LCH/LCGにおいて搬送されるデータの特徴によって決定され得る。LC H/LCGの優先順位シーケンスは、端末が基地局にデータを送信するシーケンスとして理解されてよい。例えば、LCH/LCGの優先順位シーケンスは、以下のケースのうちの任意の１つ以上に基づいて決定され得る。すなわち、
データの遅延要求の厳しさ、
データ量、
バッファ内の前記データの待ち時間、または、
データタイプ、である。
データの遅延要求の厳しさ、
データ量、
バッファ内の前記データの待ち時間、または、
データタイプ、である。
【0088】
代替的に、LCGの優先度は、LCG内のLCHに関連付けられ得る。例えば、LCGは、LCH 1およびLCH 2を含み、そして、LCG 1の優先度は、LCG 2の優先度より高い。この場合、LCGの優先度について、LCG 1の優先度が参照されてよく、または、LCGの優先度はLCG 1の優先度と同じである。
【0089】
本出願の実施形態において、「ネットワーク（“network”）」および「システム（“system”）」という用語は、たいてい、交換可能に使用されるが、用語の意味は、当業者によって理解され得ることが留意されるべきである。「コンポーネントキャリア（“component carrier”）」、「キャリアユニット（“carrier unit”）」、および「キャリア（“carrier”）」という用語は、たいてい、交換可能に使用されるが、当業者であれば、それらの用語の意味を理解することができる。「情報(information)」、「信号(signal)」、「メッセージ(message)」、および「チャネル(channel)」は、ときどき、交換可能に使用され得る。用語の違いが強調されない場合、用語によって表される意味は一貫していることが留意されるべきである。「の(of)」および「対応する(corresponding、relevant)」という用語は、ときどき、交換可能に使用され得る。用語の違いが強調されない場合、用語によって表される意味は一貫していることが留意されるべきである。
【0090】
本出願の実施形態においては、「識別子(identifier、ID)」および「インデックス(index)」は、たいてい、交換可能に使用されるが、当業者であれば、それらの用語の意味を理解することができることが、さらに、留意されるべきである。用語の違いが強調されない場合、用語によって表される意味は一貫していることが留意されるべきである。
【0091】
本出願の実施形態において、「少なくとも１つ（“at least one”）」は、「１つ以上（“one or more”）」を意味し得ることが、さらに、留意されるべきである。例えば、方式A、方式B、または方式Cのうちの少なくとも１つが実装のために使用されるということは、方式Aが実装のために使用され得ること、方式Bが実装のために使用され得ること、または、方式Cが実装のために使用され得ることを意味し、もしくは、代替的に、方式Aおよび方式Bが実装のために使用され得ること、方式Bおよび方式Cが実装のために使用され得ること、または、方式Aおよび方式Cが実装のために使用され得ること、もしくは、方式Aおよび方式Bおよび方式Cが実装のために使用され得ること、を意味し得る。同様に、「少なくとも２つ（“at least two”）」は、「２つ以上（“two or more”）」を意味し得る。
【0092】
以下の実施形態において、「第１（“first”）」、「第２（“second”）」、「第３（“third”）」などは、異なる対象を区別することを意図しているが、本出願に対するいかなる限定も構成するべきではないことが、さらに、留意されるべきである。
【0093】
「及び／又は（“and/or”）」という用語は、関連するオブジェクトを説明するための関連関係を説明し、３つの関係が存在し得ることを表すことが、さらに、留意されるべきである。例えば、A及び／又はBは、以下の３つの場合を表すことができる。すなわち、Aのみが存在すること、AおよびBの両方が存在すること、そして、Bのみが存在すること、である。文字「/」は、一般的に、関連するオブジェクト間の「または（“or”）」関係を示す。「少なくとも１つ」は、「A及び／又はB」と同様に、関連するオブジェクト間の関連関係を説明し、そして、３つの関係が存在し得ることを表している。例えば、AおよびBのうち少なくとも１つは、以下の３つの場合を表すことができる。すなわち、Aのみが存在すること、AおよびBの両方が存在すること、Bのみが存在すること、である。本出願において提供される技術的ソリューションは、添付の図面を参照して、以下で詳細に説明される。
【0094】
本出願の実施形態において、V2Xシステムが一つの例として使用されている。ブロードキャスト、ユニキャスト、またはマルチキャストにかかわらず、サイドリンクのカバレッジエリア内の端末が相互に正常に通信する必要がある場合には、情報送信を実行するために、利用可能またはアイドルのアンライセンススペクトルにおける利用可能またはアイドルのサイドリンクリソースを見つけるように、LBTプロセスが、一般的には、最初に、実行される必要がある。
【0095】
サイドリンクリソースを取得する方式は、基地局スケジューリングモード(Mode 1、mode 1)、および、UE選択モード(Mode 2、mode 2)へと分類され得る。
【0096】
基地局スケジューリングモード(Mode 1)において、基地局は、現在スケジューリングされているリソースが属するリソースプールを指示することができる。具体的に、基地局は、DCIを使用することによって、UEのためのリソースをスケジューリングし、または、RRCメッセージを使用することによって、サイドリンク構成グラント(configured grant)をUEに割り当てることができる。
【0097】
UE選択モード(Mode 2)において、UEがサイドリンクリソースを決定した後で、UEの挙動（behavior）は、基地局スケジューリングモードにおける基地局の挙動と同様である。しかしながら、サイドリンクリソースを決定する前に、UEは、リソースプールを自律的に選択する必要がある。１つの可能性は、UEが選択を実行することである。別の言葉で言えば、UEは、特定のリソースプールを選択することを自律的に決定する。例えば、UEは、基地局からリソースプール構成を受信し、または、事前構成からリソースプール構成を取得し、そして、次いで、サイドリンク通信を実行するために、リソースプールからリソースを選択する。
【0098】
具体的に、前述の選択は、ランダムに実行されてよく、もしくは、検知(sensing)または部分的検知(partial sensing)の結果に基づいて、実行されてもよい。検知は、また、フル検知(full sensing)として理解されてもよい。端末は、利用可能なリソースを決定するために、サイドリンクチャネル、例えば、サイドリンク上の物理サイドリンク制御チャネル(physical sidelink control channel、PSCCH)、または、SCIを継続的に検知する必要がある。フル検知と比較して、部分的検知は、その名前が示すように、利用可能なリソースを決定するために、端末がいくつかの時間領域リソースのみを検知することを必要とする。部分的検知は、フル検知よりも多くの電力を節約する。いくつかのリソースプールでのランダム選択について、検知または部分的検知は実行されなくてよく、そして、利用可能なリソースはランダムに選択される。時間領域リソースは、サイドリンク上の時間単位、例えば、フレーム、サブフレーム、スロット、シンボルなどであってもよいことが、理解され得る。これは、本発明において限定されない。
【0099】
一般的に、LBTは、チャネル(例えば、20MHz)を粒度（granularity）として使用することによって実行される。チャネル(例えば、第１チャネルとして示される)上で信号(例えば、データ信号)を送信する前に、通信デバイスは、第１チャネルがアイドルであるか否かを、最初に、検出し、例えば、近くの通信デバイスが信号を送信するために第１チャネルを占有しているか否かを検出し得る。検出プロセスは、クリアチャネルアセスメント(clear channel assessment、CCA)プロセスまたはチャネルアクセスプロセスと称され得る。
【0100】
具体的には、２つのタイプのチャネルアクセスプロセスが存在しており、そして、第１タイプのチャネルアクセスプロセスおよび第２タイプのチャネルアクセスプロセスとして示されている。
【0101】
第１タイプのチャネルアクセスプロセス(固定持続時間ベースのチャネルアクセスプロセスとしても、また、称され得るもの)は、以下のようである。
【0102】
固定持続時間ベースのエネルギ検出では、特定の帯域幅(例えば、20メガヘルツまたは20MHz)について、固定持続時間内に通信デバイス(端末であってよく、または、ネットワークデバイスであり得る)によって受信された信号エネルギが第１事前設定閾値以下である場合には、チャネルがアイドルであると考えられ、その結果、通信デバイスは、データを送信するためにアイドルチャネルを使用することができる。そうでなければ、チャネルがビジーであると考えられ、その結果、通信デバイスは、データを送信するためにビジーチャネルを使用しない。
【0103】
代替的に、固定持続期間ベースのチャネルアクセスプロセスにおいて、通信デバイスは、固定持続期間を検出する。チャネルで検出された信号エネルギが固定持続期間内に事前設定された閾値未満である場合には、チャネルはアイドル状態にあると考えられ、そして、チャネルが占有され得る。そうでなければ、チャネル競合が再び実行される必要がある。
【0104】
第２タイプのチャネルアクセスプロセス(ロールバックベースのチャネルアクセスプロセスとしても、また、称され得るもの)は、以下のようである。
【0105】
ロールバックメカニズムに基づくエネルギ検出では、特定の帯域幅に対してウィンドウが定義され、ウィンドウは、検出されるべきスロットの量の範囲を定義する。通信デバイスは、ウィンドウ(または、値範囲)から、値Aをランダムに選択する。アイドルエネルギ検出が実行される少なくともA個のスロットを検出した後で、通信デバイスは、チャネルがアイドルであると見なし、その結果、通信デバイスは、データを送信するためにチャネルを使用することができる。そうでなければ、チャネルがビジーであると考えられ、その結果、通信デバイスは、データを送信するためにビジーチャネルを使用しない。アイドルエネルギ検出は、固定持続時間内に受信された信号エネルギが第２事前設定された閾値以下であることを意味する。第１事前設定された閾値および第２事前設定された閾値は、事前に定義され、例えば、プロトコルにおいて事前に定義され得る。これは、限定されない。加えて、第１事前設定された閾値と第２事前設定された閾値との間には限定関係が存在しない、そして、第１事前設定された閾値および第２事前設定された閾値は同じであってよく、または、異なっていてもよい。
【0106】
具体的に、通信デバイスは、コンテンションウィンドウ内で値Aをランダムに選択する。少なくともA個のアイドルスロットを検出した後で、通信デバイスは、チャネルがアイドル状態にあると決定してよく、その結果、チャネルは占有され得る。そうでなければ、チャネル競合が再び実行される必要がある。アイドルスロットは、１つのスロット内のチャネルで検出された信号エネルギが事前設定された閾値未満であることを意味する。このタイプのチャネルアクセスプロセスでは、４つのチャネルアクセス優先度クラス(channel access priority classes、CAPC)が導入されている。異なるCAPCは、異なるチャネルアクセスパラメータに対応している。チャネルアクセスパラメータは、コンテンションウィンドウのサイズ、対応するサービスステータス、チャネル占有時間(channel occupancy time、COT)情報、などを含む。COTは、チャネルアクセスプロセスが成功した後で、チャネルが使用され得る持続時間である。
【0107】
チャネルアクセスプロセスが実行されるとき、２つの結果が取得され得る。すなわち、チャネルアクセスプロセスが完了していること(LBT成功としても、また、称される)、および、チャネルアクセスプロセスが完了していないこと(LBT失敗としても、また、称される)である。データ伝送に使用される時間周波数リソースには、複数の時間領域開始位置が存在している。任意の時間領域開始位置の前にチャネルがアイドルであると決定された場合には、チャネルアクセスプロセスが完了したものと見なされ得る。全ての時間領域開始位置の前にチャネルがビジーであると決定された場合には、チャネルアクセスプロセスが完了していないものと見なされ得る。
【0108】
違いは、ライセンススペクトルベースの動作シナリオにおいて、スケジューリングされたリソースを取得した後で、UEが、サービス送信を実行するためにリソースを直接的に使用し得ることにある。しかしながら、アンライセンススペクトルベースの動作シナリオにおいて、スケジューリングされたリソースを取得した後で、UEは、さらに、リソース上でLBTを実行する必要があり、そして、LBTが成功した後で、サービス送信を実行するためにリソースを使用する必要がある。
【0109】
本発明の実施形態において、サイドリンク上で有効なLBTプロセスを実行するために、サイドリンク通信においてアンライセンススペクトルが適用され、その結果、サイドリンク通信の信頼性が達成され、そして、端末間の通信効率が改善される。以下に、詳細な説明を提供する。
【0110】
図3は、本出願に従った、通信方法の概略フローチャートである。サイドリンクシナリオでは、説明のために、通信デバイスが端末として使用され、そして、ネットワークデバイスが基地局として使用されている。通信デバイスおよびネットワークデバイスは、それぞれ、チップであってよく、または、チップによって実装されてもよい。このことは、本出願の実施形態において限定されない。説明を容易にするために、以下で説明される通信デバイスは、また、端末またはUEとしても称され得る。
【0111】
本方法は、以下のステップを含んでいる。
【0112】
301:第１通信デバイスは、構成情報（configuration information）を取得する。構成情報は、第１リソースプールにおいて発生した、一貫したリッスンビフォアトークLBT失敗（LBT failure）を検出するために第１通信デバイスによって使用され、構成情報は、第１キャリアまたは第１リソースプールに関連付けられ、そして、第１リソースプールは、第１キャリアに属している。
【0113】
303:第１通信デバイスは、第１指示情報をネットワークデバイスに送信する。第１指示情報は、一貫したLBT失敗が発生した第１リソースプールを示す。
【0114】
一般的に、NRにおけるキャリアの帯域幅は、LTEにおけるキャリアの帯域幅よりも広い。例えば、NRにおけるキャリアの帯域幅は、100MHzであり得る。しかしながら、異なる端末は、異なる無線周波数能力を有しており、そして、異なる最大帯域幅をサポートすることができる。従って、帯域幅部分(bandwidth part、BWP)の概念が導入される。図3aは、BWPの概略図である。BWPは、キャリア上の連続したRBリソースのグループである。異なるBWPは、部分的にオーバーラップするが異なる帯域幅を有する周波数領域リソースを占有してよく、または、異なるヌメロロジ（numerologies）を有し、かつ、周波数領域においてオーバーラップしなくてよい、帯域幅リソースであってもよい。１つの端末デバイスに対して最大４つのBWPが構成され得る一つの例が、説明のために使用されている。例えば、４つのBWPが周波数分割複信(frequency division duplex、FDD)で構成され、または、４つのBWPが時分割複信(time division duplex、TDD)で構成されている。各キャリア（carrier）上で１つのBWPが同時に動作化（activated）されることができ、そして、データが、サイドリンクに基づいて、動作化されたBWP上で端末間において送信および受信され得る。
【0115】
本出願のこの実施形態において、ネットワークデバイスは、アンライセンススペクトル上で端末のためのBWPを構成し、そして、構成されたBWPのうちの１つを動作化することができる。端末は、アンライセンススペクトルを使用することによって、相互にサイドリンク通信を実行し得る。構成情報が第１キャリアまたは第１リソースプールに関連付けられることは、また、構成が、キャリア粒度またはBWP粒度に基づき得る、もしくは、リソースプール粒度に基づき得るものとして理解されてもよい。キャリア粒度は、LBT検出が、粒度としてキャリアを使用することによって、独立して構成されるものとして理解され得る。BWP粒度は、LBT検出が、粒度としてBWPを使用することによって、独立して構成されるものとして理解され得る。リソースプール粒度は、LBT検出が、粒度としてリソースプールを使用することによって独立して構成されるものとして理解され得る。任意的に、１つのキャリアは１つ以上のBWPを含み、そして、１つのBWPは１つ以上のリソースプールを含んでいる。１つのキャリアが１つのBWPを含むとき、BWP粒度は、キャリア粒度であり得る。従って、リソースプール粒度は、ネットワークのフレキシブルな構成を可能にすることができ、そして、キャリア粒度またはBWP粒度は、シグナリングオーバーヘッドを低減することができる。
【0116】
301において、第１端末は、異なる方法でリソースプール構成を取得し得る。第１方式において、ネットワークデバイス、例えば、基地局は、専用シグナリングまたはシステムブロードキャストを介して、第１端末のためのリソースプールを構成する。第２方式において、第１端末は、事前構成に基づいてリソースプールを取得する。事前構成は、端末において、または、加入者識別モジュール(Subscriber Identity Module、SIM)カードにおいて事前に保管されてよく、もしくは、端末デバイスは、コアネットワークから構成を受信する。SIMカードは、また、テレホンカード、または、加入者識別データ、SMSデータ、および電話番号といった情報を保管するために主に使用されるスマートカードとしても称され得る。
【0117】
第１方式において、ネットワークデバイスは、リソースプールを構成する。これは、モード1に対応している。第２方式において、第１端末は、リソースプールを構成する。これは、モード2に対応している。別の言葉で言えば、第１方式において、リソースプール構成は、ネットワークアクセス端末が、有効なリソースプール構成を取得し、かつ、リソースプール構成に基づいてサイドリンク通信を実行することができることを保証するために、第１端末のためにネットワークデバイスによって提供される。第２方式において、リソースプール構成は、第１端末が、ネットワークカバレッジが存在しないときに、事前構成されたリソースプールに基づいてサイドリンク通信を実行することができることを保証するために、第１端末において、または、SIMカードにおいて事前構成される。
【0118】
第１方式において、基地局によって送信され、第１端末によって受信された構成情報は、ブロードキャストまたはRRC専用シグナリングを介して、基地局によってUEに送信され得る。例えば、UEがアイドル状態または非アクティブ状態にあるとき、基地局は、ブロードキャストメッセージを介して、UEに構成情報を送信する。UEが接続状態にあるとき、基地局は、RRC専用シグナリングを介して、UEに構成情報を送信する。
【0119】
例えば、アクセスネットワークデバイスまたは基地局は、システム情報またはRRC共通情報を端末に送信する。システム情報またはRRC共通情報は、セルレベルパラメータであってよい。リソースプールが、端末について、システム情報設定またはRRC共通情報設定を介して、設定され得る。具体的な実装の最中に、アクセスネットワークデバイスは、システム情報またはRRC共通情報を端末に送信することができ、そして、システム情報またはRRC共通情報は、各端末のためのリソースプールを構成するために使用される。システム情報またはRRC共通情報が端末に送信されるので、システム情報またはRRC共通情報を使用することによって送信される構成情報は、端末間のマルチキャスト送信のために使用され得る。例えば、送信端（sending end）UEは、システム情報またはRRC共通情報を使用することによって構成された、サイドリンクリソースを使用することによってデータ及び／又は制御情報をマルチキャストすることができ、そして、別の端末、例えば、受信端UEは、対応するサイドリンクリソースプールにおいてデータまたは制御情報を受信することができる。
【0120】
別の例において、アクセスネットワークデバイスまたは基地局は、RRC専用情報を端末に送信する。RRC専用情報は、端末においてパラメータ構成を実行するために使用される端末レベルパラメータ(または、UEレベルパラメータと称される)であり得る。RRC専用情報の構成方式において、リソースプールは、単一の端末のために構成され得る。具体的な実装の最中に、アクセスネットワークデバイスは、RRC専用情報を単一の端末に送信することができ、そして、RRC専用情報は、端末のためのリソースプールを構成するために使用される。RRC専用情報が単一の端末に送信されるので、RRC専用情報を使用することによって送信される構成情報は、端末間のユニキャスト送信のために使用され得る。例えば、端末1は、RRC専用情報を使用することによって送信された構成情報を使用することによって、ユニキャスト方式で端末2にデータまたは制御情報を送信することができる。
【0121】
代替的に、オペレータは、端末のためにサイドリンクリソースプールを事前構成するか、または、標準プロトコルにおいて事前定義された方法で端末のためにサイドリンクリソースプールを事前構成する。事前構成方式において、リソースプール構成は、１つ以上の端末において実行され得る。具体的な実装の最中に、コアネットワークデバイス(例えば、ポリシ制御機能Policy Control Functionネットワーク要素、PCFネットワーク要素)は、事前構成情報を各端末に別々に送信することができ、そして、事前構成情報は、各端末においてリソースプール構成を別々に実行するために使用される。事前構成情報が複数の端末に送信されるので、事前構成情報は、端末間のブロードキャスト送信のために使用され得る。例えば、端末1は、事前構成情報を使用することによってデータ及び／又は制御情報をブロードキャストすることができ、そして、別の端末、例えば、端末2は、事前構成情報に基づいてデータを受信し、かつ／あるいは、情報を制御することができる。
【0122】
実際のアプリケーションにおいて、システム情報、RRC共通情報、RRC専用情報、または事前構成情報は、全てが、ブロードキャスト、マルチキャスト、及び／又は、ユニキャスト情報送信のために使用され得る。これは、本出願において限定されない。
【0123】
図2cに示されるように、端末のサイドリンク通信ベースのプロトコルスタックは、以下のプロトコル層(またはエンティティ)のうちの少なくとも１つを含んでいる。すなわち、サイドリンクサービスデータ適応(Service Data Adaptation Protocol、SDAP)層、サイドリンクパケットデータコンバージェンスプロトコル(PDCP、Packet Data Convergence Protocol)層、サイドリンク無線リンク制御(RLC、Radio Link Control)層、サイドリンクメディアアクセス制御(MAC、Media Access Control)層、および、サイドリンク物理(PHY、Physical)層である。
【0124】
SL PDCP層は、主に、情報を圧縮および解凍／暗号化および復号するために使用される。SL RLC層は、主に、自動再送要求(ARQ、Automatic Repeat Request)に関連する機能を実装し、そして、情報をセグメント化および連結するか、または、セグメント化および連結された情報を再アセンブルするために使用される。SL MAC層は、主に、伝送フォーマットの組み合わせを選択し、そして、スケジューリングおよびハイブリッド自動再送要求(HARQ、Hybrid Automatic Repeat Request)に関連する機能を実装するために使用される。SL PHY層は、主に、MAC層および上位層に情報伝送サービスを提供し、そして、選択された伝送フォーマットの組み合わせに基づいて、コーディングおよび変調、または、復調およびデコーディングを実行するために使用される。従って、本発明のこの実施形態において、端末のプロトコルスタックは、PDCP層、RLC層、またはMAC層における任意のプロトコル層で集約され得る。例えば、プロトコルスタックは、PDCP層で集約されてよく、その結果、情報送信の信頼性が、暗号化および復号を介して改善され得る。前述の適応層（adaptation layer）は、基地局と端末のプロトコルスタックとの間のデータに対して変換を実行するために使用される。適応層を設定することによって、プロトコルスタック間の変換を確実にすることができ、その結果、基地局におけるプロトコルスタックの構成が、よりフレキシブルになる。
【0125】
一般的に、301における構成情報は、LBT失敗の最大回数およびタイマ長を含み得る。
【0126】
具体的に、サイドリンクキャリアに基づく設定情報は、１つのキャリアが１つの設定に対応するか、または、１つの設定を有することを意味し得る。従って、キャリアにおける全てのリソースプールは、一貫したLBT失敗を復元するために、同じ構成に基づいて使用され得る。代替的に、サイドリンクリソースプールに基づく設定情報は、１つのリソースプールが１つの設定に対応するか、または、１つの設定を有することを意味し得る。LBT失敗が発生した場合に、第１通信デバイスの物理PHYエンティティは、第１通信デバイスのメディアアクセス制御MACエンティティに対して、第１リソースプールにおいて発生したLBT失敗を示す。MACエンティティは、第１リソースプールに対応するタイマを開始または再開し、そして、第１リソースプールにおいて発生したLBT失敗に基づいて、第１リソースプールに対応するカウンタのカウント値を増加させる。カウンタのカウント値が最大値に達したときに、MACエンティティは、第１リソースプールにおいて一貫したLBT失敗が発生したと決定する。任意的に、第１通信デバイスの物理層は、第１リソースプールにおける各サイドリンクグラントリソースに対してLBT検出を実行する。
【0127】
例えば、粒度はBWPである(ここで、１つのキャリアが１つのBWPを有するとき、BWP粒度は、キャリア粒度として理解され得る)。BWPにおいてLBT検出を実行し、かつ、BWPにおいてLBT失敗が毎回発生すると決定したときに、第１端末は、以下の動作を実行し得る。
【0128】
1.第１端末は、BWPのカウンタのカウント値(LBT_FAIL_COUNTERとして称され得る)を1だけ増加させる。ここで、カウンタの初期値は0である。
【0129】
2.第１ターミナルは、BWPのタイマ(lbtFailureDetectionTimerとして称され得る)を開始または再開する。ここで、タイマのタイミング持続期間は、第１ターミナルまたは基地局によって構成された期間であってよい。
【0130】
タイマが満了する前に、カウンタのカウント値が閾値に達した場合に、第１端末は、BWPにおいて一貫したアップリンクLBT失敗(consistent uplink LBT failure)が発生したと決定し得る。タイマが満了すると、端末は、カウンタのカウント値を0にリセットし得る。カウンタおよびタイマは、BWPまたはキャリアに対応するカウンタおよびタイマである。
【0131】
粒度がリソースプールである場合に、同様の設計が存在する。相違点は、第１端末が、各リソースプール上でカウンタおよびタイマに対する動作を実行し、そして、リソースプールにおいて一貫したLBT失敗が発生したか否かを決定することにある。
【0132】
構成情報が、キャリア/BWPまたはリソースプールに関連付けられているかにかかわらず、第１端末は、一貫したLBT失敗を検出するために、タイマおよびカウンタを、リソースプール粒度に維持し得ることが理解されるだろう。別の言葉で言えば、第１端末は、異なるリソースプールについて、タイマおよびカウンタを別々に維持する。代替的に、構成情報は、キャリアに関連付けられ、そして、第１端末は、一貫したLBT失敗を検出するために、タイマおよびカウンタを、キャリア粒度に維持し得る。別の言葉で言えば、第１端末は、異なるキャリアについて、タイマおよびカウンタを別々に維持する。
【0133】
本発明のこの実施形態において、303は、主に、第１端末のRRCステータスが接続(connected)状態にある場合のためのものである。別の言葉で言えば、第１端末が接続状態にあるときに、第１端末は、基地局に対して、一貫したLBT失敗が発生したリソースプールを示すことができる。第１端末がアイドル(idle)状態、または、非アクティブ(inactive)状態にあるときに、第１端末は、基地局上での指示の実行をスキップするか、または、303の実行をスキップすることができる。接続状態にある第１端末は、基地局が検知することを可能にするために、MAC CEを基地局に報告し、その結果、基地局は、リソースプール構成またはリソースプールのLBT関連構成を更新し得ることが理解されるだろう。それどころとか、アイドル状態または非アクティブ状態にある第１端末は、基地局と通信しない。従って、このステップはスキップされてよい。
【0134】
一貫したLBT失敗が、キャリア上、または、サイドリンク上のリソースプールで発生したと決定したときに、第１端末は、LBT失敗をネットワークデバイスに対して迅速に示すために、LBT失敗を示すメディアアクセス制御(medium access control、MAC)制御要素(control element、CE)をネットワークデバイスに送信し得る。詳細が、以下で説明される。
【0135】
例えば、図3bに示されるMAC CEは、複数のリソースプール識別子フィールドを含み、8個のリソースプール識別子フィールド、すなわちRP0からRP7まで、を含んでいる。リソースプール識別子フィールドに対応しているビットの値が第１値であるとき、それは、リソースプール識別子フィールドに対応しているリソースプールにおける端末上で一貫したLBT失敗が発生したことを示す。リソースプール識別子フィールドに対応するビットの値が第２値であるとき、それは、リソースプール識別子フィールドに対応しているリソースプールにおける端末上で一貫したLBT失敗が発生していないことを示す。第１値および第２値の具体的な値は、限定されない。例えば、第１値は1であり、そして、第２値は0である。
【0136】
複数のサイドリンクキャリアがサポートされるシナリオを考慮して、第１端末は、さらに、リソースプールが属するキャリアに関する情報を、MAC CEにおいて、含んでよい。図3cに示されるように、MAC CEは、キャリア識別子フィールドを含み得る。例えば、8個のキャリアは、それぞれC0からC7までとして表されており、そして、図中の各Ciフィールドは、１つのキャリアに対応している。第１キャリアに対応するCiフィールドが第１値であるとき、それは、第１キャリアに対応している8個のリソースプール識別子フィールドが、さらに、MAC CEにおいて識別され得ることを示す。第１キャリアに対応するCiフィールドが第２値であるとき、それは、第１キャリアに対応している8個のリソースプール識別子フィールドが、MAC CEにおいて識別され得ないことを示す。実際のアプリケーションにおいて、キャリアフィールドは、代替的に、別の方式で示されてよい。このことは、本出願の実施形態において限定されない。キャリア識別子フィールドは、一貫したLBT失敗が、キャリア上の端末で発生したか否かを示す。同様に、キャリア識別子フィールドに対応するビットの値が第１値であるとき、それは、一貫したLBT失敗が、キャリア上の端末で発生したことを示す。キャリア識別子フィールドに対応するビットの値が第２値であるとき、それは、キャリア上の端末で一貫したLBT失敗が発生していないことを示す。第１値および第２値の具体的な値は、限定されない。例えば、第１値は1であり、そして、第２値は0である。
【0137】
第１端末が接続モードにあり、かつ、リソースプールにおいて一貫したLBT失敗が発生した場合、第１端末は、基地局に対して、一貫したLBT失敗が発生したリソースプールに関する情報を指示するために、MAC CEを生成する。例えば、MAC CEは、一貫したLBT失敗が発生したリソースプールの指示情報を含み、そして、指示情報は、リソースプールインデックスまたはリソースプール識別子であってよい。
【0138】
一般的に、MAC CEは、１つの論理チャネル識別子(LCH_ID)に対応し得る。例えば、LCH IDは、MAC CEを識別するために使用され、そして、LCH IDは、MAC CEと一対一の対応関係にある。任意的に、基地局は、MAC CEについてスケジューリング要求(scheduling request、SR)リソースを構成することができ、MAC CEについて基地局からのエアインターフェイス(Uuインターフェイス)リソースを要求する。
【0139】
第１端末は、既定時間内にリソースプールにおいてリソース選択を実行することを停止してよく、または、一貫したLBT失敗が、キャリアの全てのリソースプールにおいて発生した場合、第１端末は、サイドリンク上で別のキャリアを再選択し得ること、が理解され得る。
【0140】
以下は、異なるモードにおける、一貫したLBT失敗が発生した後の第１端末または基地局の挙動を説明している。
【0141】
1.第１端末は、モード1にある。
【0142】
端末が、基地局に対して、一貫したLBT失敗が発生したリソースプールに関する情報を示すためにMAC CEを報告した後で、基地局は、端末について、第１リソースプールにおけるリソースを既定時間内にスケジュールしない。
【0143】
さらに、既定時間の後で、基地局は、端末について、リソースプールにおけるリソースを再スケジューリングし得る。LBT失敗が再び発生した場合に、基地局は、端末について、リソースプールにおけるリソースを第２既定時間内にスケジュールしない。第２既定時間は、第１既定時間以上の時間である。
【0144】
任意的に、前述のメカニズムは、さらに、時間領域及び／又は周波数領域リソースがリソースプールとオーバーラップする別のリソースプールに適用され得る。別の言葉で言えば、異なるリソースプールにおける時間領域または周波数領域リソースが、オーバーラップし、かつ、一貫したLBT失敗が、そうしたリソースプールのうちの少なくとも１つで発生する場合に、基地局は、そうしたリソースプールにおけるあらゆるリソースを既定時間内にスケジュールしなくてよい。
【0145】
前述の挙動は、基地局の頻繁な試行によって引き起こされる信頼できない通信を回避することができる。加えて、周波数領域位置がオーバーラップするリソースプールに対して同じ処理が実行され、その結果、信頼性を改善することができる。
【0146】
2.第１端末は、モード2にある。
【0147】
接続状態にある第１端末は、MAC CEを基地局に報告する。
【0148】
MAC CEが報告されるか否かにかかわらず、第１端末は、一貫したLBT失敗が発生したリソースプールにおけるリソースを選択するための試行を続け、そして、リソースが利用可能であるか否かを決定するためにLBTを実行し得る。代替的に、第１端末は、いくつかのリソースを選択することを回避するために、以下の方式のうちの少なくとも１つで動作を実行し得る。
【0149】
方式1：リソースが、一貫したLBT失敗が発生したリソースプールから、もはや選択されない。
【0150】
方式2：リソースが、既定時間内にリソースプールから、もはや選択されない。既定時間の持続時間は、基地局によって構成されてよく、または、端末によって決定されてよい。
【0151】
方式3：基地局がリソースプールを再構成する前に、リソースが、リソースプールから、もはや選択されない。リソースプールの再構成は、リソースプールのLBT再構成であり得る。
【0152】
従って、前述の方式において、第１通信デバイスと別の通信デバイス(例えば、第２通信デバイス)との間のサイドリンク通信の信頼性を保証することができる。
【0153】
本発明のこの実施形態において、方式1または方式2は、非接続状態の端末に適用可能であり得る。そして、方式3は、接続状態の端末に適用可能である。
【0154】
さらに、マルチキャリアシナリオを考慮して、MAC CEは、さらに、リソースプールに対応しているキャリアに関する情報を搬送し得る。
【0155】
任意的に、第１端末は、RRCを使用することによって、基地局に対して、第１端末にサービスを提供する指示情報を代替的に送信し得る。
【0156】
さらに、特定のキャリア上の全てのリソースプールにおいて一貫したLBT失敗が発生したとき、別のキャリアが存在している場合に、第１端末は、サービス送信のための別のキャリアを選択するために、キャリア再選択を実行し得る。一貫したLBT失敗が全てのキャリア上で発生した(例えば、一貫したLBT失敗が全てのキャリア上の全てのリソースプールにおいて発生した)場合に、第１端末は、PC5インターフェイスが利用不可能であることを示すために、第１端末の上位層(例えば、PC5-S層、V2X層、または、アプリケーション層)に対して指示情報を送信し得る。それに対応して、アプリケーション層は、エアインターフェイス(Uuインターフェイス)を使用することによって、サービス送信を実行し得る。
【0157】
この実施形態において、端末は、リソースプールに基づいて、LBT失敗処理を実行するようにイネーブルされてよく、そして、基地局が指示され、または、サイドリンク通信の信頼性を保証するために、端末の挙動が制限される。
【0158】
第２方式、すなわち、第１端末が事前構成に基づいて構成情報を取得する場合について、以下は、端末間のインタラクションを詳細に説明している。図3に示されるように、例えば、UE 1のサービング基地局はBS 1であり、そして、ユニキャスト接続は、UE 2とUE 1との間の通信に使用されている。UE 2は、アイドル状態、非アクティブ状態、または接続状態にある。UE 2が接続状態にある場合に、UE 2に対応するサービング基地局はBS 2である。この実施形態において、BS 2およびBS 1は、同一の基地局であってよい。
【0159】
UE 1が、第１リソースプールにおいて一貫したLBT失敗が発生したと決定した後で、この実施形態は、さらに、以下のステップを含み得る。
【0160】
305：UE 1は、UE 2に対して、一貫したLBT失敗が発生した第１リソースプールまたは第１キャリアを示す。
【0161】
307:UE 2は、BS 2に対して、一貫したLBT失敗が発生した第１リソースプールまたは第１キャリアを示す。
【0162】
ユニキャスト接続における端末間の前述のシグナリングインタラクションは、端末間の通信の信頼性および有効性を改善することができる。
【0163】
ユニキャスト接続通信シナリオについて、UE 1は、303をスキップし得ることが理解されるだろう。別の言葉で言えば、UE 1は、BS 1に対して、一貫したLBT失敗が発生したリソースプールを示す必要はない。例えば、301を実行した後で、UE 1は、303をスキップし、そして、直接的に305を実行する。代替的に、305または307におけるUE 1およびUE 2は、交換されてよい。例えば、UE 1は、UE 2によって示され、かつ、一貫したLBT失敗が発生した、リソースプールまたはキャリアを受信し、次いで、BS 1に対して、指示情報を送信し得る。このようにして、同じUE 1について、UE 1は、一貫したLBT失敗が発生したリソースプールまたはキャリアを検出するだけでなく、ピアUE 2から、また、一貫したLBT失敗が発生した別のリソースプールまたはキャリアを取得することができ、UE 1とUE 2との間のサイドリンク通信の信頼性を保証する。
【0164】
UE 1が、一貫したLBT失敗が発生したリソースプールを使用することによってUE 2にサービスを送信する場合に、UE 2は、サービスの受信に失敗し、または、受信失敗を経験することがある。従って、UE 1は、リソースプールの構成をUE 2に示し、そして、UE 2は、UE 1によって示されたリソースプール情報に基づいて、一貫したLBT失敗が発生したリソースプールを決定し、そして、次いで、リソースプールを、基地局から、または、事前構成からUE 2によって取得されたリソースプールにマッピングすることができる。例えば、マッピングは、UE 2が、UE 1からリソースプールの指示情報(リソースプール識別子、または、リソースプールインデックス)を取得し、そして、UE 2が、指示情報に基づいてリソースプールの時間-周波数領域リソースを決定することを意味し得る。時間-周波数領域リソースは、UE 2について基地局によって構成されてよく、または、事前構成に基づいて、UE 2によって取得されてよい。
【0165】
任意的に、サイドリンク通信システムにおける各基地局は、リソース構成の一貫性を保証するために、基地局によってサービスされるUEに対して同じリソースプール構成を提供し得る。例えば、UE 1のサービング基地局BS 1によってUE 1のために提供されるリソースプール構成は、UE 2のサービング基地局BS 2によってUE 2のために提供されるリソースプール構成と同じである。この場合、UE 1が、UE 2に対して、一貫したLBT失敗が発生したリソースプールを示すときに、UE 2は、正しく理解することができる。代替的に、同じ基地局がUE 1およびUE 2についてサービスを提供する。このシナリオにおいて、基地局は、異なるUEに対して同じリソースプール構成を提供し得る。
【0166】
UE 1によって送信され、かつ、一貫したLBT失敗が発生したリソースプールまたはキャリアを示している指示情報を受信した後で、接続状態にあるUE 2は、さらに、UE 2のサービング基地局BS 2に指示情報を送信してよく、その結果、UE 2のためのリソースをその後にスケジューリングするときに、BS 2は、一貫したLBT失敗が発生したリソースプールまたはキャリアを回避し得る。
【0167】
具体的に、UE 2は、MAC CEを使用することによって、BS 2に指示情報を送信し得る。MAC CEは、UE 2が一貫したLBT失敗が発生したリソースプールを検出するときに、UE 2によって使用されるMAC CEと同じであっても、または、異なってもよい。MAC CEが同じである場合に、MAC CEは、さらに、一貫したLBT失敗がUE 2によって検出されたか、または、ピアUEによって検出されたかを示す指示情報を含み得る。任意的に、MAC CEは、さらに、UE 1とUE 2との間のユニキャスト接続を含むか、または、示し得る。従って、基地局は、異なるシナリオについて対応する処理を実行することが可能にされ得る。
【0168】
さらに、マルチキャリアシナリオを考慮して、MAC CEは、さらに、リソースプールに対応しているキャリアに関する情報を搬送し得る。
【0169】
任意的に、UE 2は、代替的に、RRCを使用することによって、BS 2に指示情報を送信し得る。
【0170】
一般的に、アイドル状態または非アクティブ状態にあるUE 2は、307をスキップしてよく、または、307を実行しなくてよい。UE 2がいくつかのリソースを回避することを決定する動作ソリューションについては、第１端末に係る前述の関連する説明を参照のこと。例えば、UE 1の指示情報を受信した後で、ユニキャスト接続のためのサイドリンクリソースを選択するときに、UE 2は、一貫したLBT失敗が発生したリソースプールにおけるリソースを選択せず、または、回避し、もしくは、ある期間内にリソースプールにおけるリソースを選択しない。
【0171】
可能な場合において、UE 1がBS 1によって再構成された場合、または、UE 1が通信のためにリソースプールにおけるリソースを再び使用し始めた場合に、一貫したLBT失敗が識別されない場合、または、一貫したLBT失敗がある期間内に識別されない場合、UE 1は、UE 2に指示情報を送信することができ、ここで、指示情報は、リソースプールが利用可能であることを示している。別の可能な場合には、UE 2が、リソースプールにおいてUE 1からサービス送信またはデータを受信した場合に、ユニキャスト接続のためのサイドリンクリソースを選択するとき、UE 2は、リソースプールにおけるリソースを再選択する。
【0172】
上記は、UE 2がUE 1の指示を受信した後の、UE間でのインタラクションおよびUE 2の挙動を説明するために、一つの例として、一貫したLBT失敗が発生したリソースプールを使用していることが、留意されるべきである。任意的に、前述のプロセスにおいては、サイドリンクキャリア情報が交換され得るが、サイドリンクリソースプール情報は交換されない。例えば、UE 1は、UE 2に対して、一貫したLBT失敗が発生したキャリアに関する情報を示し、そして、UE 2は、サービング基地局BS 2に対して、一貫したLBT失敗が発生したキャリアに関する情報を示す。任意的に、端末間のインタラクションは、対応するサイドリンクユニキャスト接続情報を含み得る。リソースプール構成が一貫性を有さないシナリオでは、通信の信頼性を保証し、そして、さらに、シグナリングオーバーヘッドを低減するために、インタラクションは、キャリア粒度で実行され得る。
【0173】
一貫したLBT失敗が発生したキャリアに関する情報のみが提供される場合に、一貫したLBT失敗がキャリア上で発生したと端末または基地局が決定するための条件については、前述の説明を参照のこと。例えば、一貫したLBT失敗は、サイドリンク上のキャリア上の全てのリソースプール上で発生し、そして、回復されない。しかしながら、本発明の実施形態は、これに限定されない。
【0174】
以下は、UE 2がUE 1の指示情報を取得した後のUE 2に係る挙動の２つの実装について説明している。例えば、UE 2は、通信信頼性を保証するために、リソースプール選択または再選択を実行する。
【0175】
方式1：
【0176】
UE 2は、サイドリンク上の、別のリソースプールにおけるリソースまたは別のキャリア上のリソースを選択し、そして、そのリソースに基づいて、UE 1とのユニキャスト接続通信を実行する。別のリソースプールは、一貫したLBT失敗が発生したリソースプールとは異なり、または、別のキャリアは、一貫したLBT失敗が発生したキャリアとは異なるものである。
【0177】
方式2：
【0178】
UE 2は、サイドリンクグラントリソース（grant resource）を取得する。グラントリソースは、一貫したLBT失敗が発生したリソースプールにおいて、または、キャリア上に置かれている。この場合、UE 2は、UE 1とユニキャスト接続通信を実行するために、サイドリンクグラントリソースを使用しない。
【0179】
例えば、UE 2は、サイドリンク上の別のリソースプールにおけるリソース、または、別のキャリア上のリソースを選択し、そして、そのリソースに基づいて、UE 2とユニキャスト接続通信を実行する。別のリソースプールは、一貫したLBT失敗が発生したリソースプールまたはキャリアとは異なるものである。代替的に、UE 2は、サイドリンクグラントリソースを取得する。グラントリソースは、一貫したLBT失敗が発生したリソースプールにおいて、または、キャリア上に置かれている。UE 2は、UE 1とユニキャスト接続通信を実行するために、サイドリンクグラントリソースを使用しない。
【0180】
具体的に、現在スケジューリングされたリソースが、一貫したLBT失敗が発生し、かつ、UE 1によって示される、リソースプールまたはキャリアにおけるリソースであることが決定された場合に、リソースのために送信されるべきデータを選択するとき、UE 2は、UE 1に対するユニキャスト接続を除外する。例えば、UE 2の物理層は、UE 2のMACエンティティに対して、現在スケジューリングされたリソースは、一貫したLBT失敗が発生したリソースプールまたはキャリアに属していることを示す。本発明のこの実施形態において、UE 2のMACエンティティは、論理チャネル優先順位付け(logical channel prioritization、LCP)プロセスを実行し得る。例えば、UE 2のMAC層がLCPプロセスを実行するとき、UE 2とUE 1との間のユニキャスト接続は除外される。物理層が、MACエンティティに対して、現在スケジューリングされたリソースが別のリソースプールまたはキャリアに属しており、そして、別のリソースプールまたはキャリアがユニキャスト接続通信のために使用され得ることを示す場合には、優先度に基づいて、ユニキャスト接続上でデータを送るためにリソースを使用するか否かが決定され得る。
【0181】
UE 2は、一貫したLBT失敗が発生しない別のリソースプールまたはキャリアのリソースを選択してよく、そして、UE 2のMAC層は、リソースプールまたはキャリアに対応しているユニキャスト接続上のデータをMACパケットデータユニット(packet data unit、PDU)へと変換し、そして、対応するリソースを使用することによって、PC5インターフェイスを介して、情報を送信する。
【0182】
結論として、UE 2が、UE 1から、一貫したLBT失敗が発生したリソースプールまたはキャリアに関する情報を受信した後で、LCPプロセスまたはリソース選択/再選択は、影響を受け得る。前述の情報は、UE 1とUE 2との間のユニキャスト接続に対して適用可能である。従って、通信プロセスにおいて、BS 2は、UE 2のためにリソースプールまたはキャリアのリソースをスケジューリングしてよく、または、UE 2は、モード2に基づいて、リソースプールまたはキャリアを選択してよい。別の言葉で言えば、UE 2は、別のユニキャスト/ブロードキャスト/マルチキャスト通信要件に起因して、リソースプールまたはキャリアのリソースを取得し得る。この場合、LCPプロセスを実行するときに、UE 2は、リソースプールまたはキャリアに対応するユニキャスト接続を除外する必要がある。
【0183】
前述のソリューションにおいて、UE 1は、UE 1とのユニキャスト接続におけるピアUE 2に対して、UE 1によって検出され、かつ、そこで一貫したLBT失敗が発生した、リソースプールまたはキャリアに関する情報を示して、UE 2がリソース選択を行うのをサポートする。このようにして、UE 2は、UE 1とのサイドリンク通信を実行するためにリソースプールのリソースまたはキャリアを使用することを回避することができる。
【0184】
以下では、単一のLBT失敗が発生するシナリオを説明している。このようにして、サイドリンク通信の信頼性が改善され得る。単一のLBT失敗について、以下の方法は、上述の一貫したLBT失敗の前に、かつ、端末間、または、端末と基地局との間で失敗情報が交換される(例えば、303から307まで)前に実行されてよく、もしくは、前述の交換とは独立していてよいことが理解されるだろう。例えば、第１端末は、取得されたサイドリンクグラントリソースに基づいて、LBT検出を実行するか否かを決定し得る。第１端末がLBT検出を実行しないと決定した場合に、検出は、後続の一貫したLBT動作に対して実行されなくてよい。第１端末がLBT検出を実行すると決定した場合に、第１端末は、さらに、プロセスにおいて送信されるべきデータが存在するか否かのケースに基づいて、ACKまたはNACKを基地局にフィードバックすることを決定し得る。代替的に、第１端末は、さらに、複数回のLBT検出を実行し、そして、検出の結論、例えば、一貫したLBT失敗の発生を、ピア端末または基地局と交換し得る。複数回実行されるLBT検出に関連する方法については、前述の説明を参照のこと。詳細は、再度説明されない。
【0185】
場合によって、本発明のこの実施形態は、さらに、以下を含み得る。
【0186】
第１端末は、基地局からサイドリンクグラントリソースを受信する。
【0187】
サイドリンクグラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合、第１端末は、サイドリンクグラントリソース上でのLBT検出をスキップし、または、一時停止する。
【0188】
別の場合に、本発明のこの実施形態は、さらに、以下を含み得る。
【0189】
第１端末は、基地局からサイドリンクグラントリソースを受信する。
【0190】
第１端末は、サイドリンクグラントリソース上でLBT検出を実行する。
【0191】
サイドリンクグラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しており、かつ、LBT失敗が発生した場合、第１端末は、否定確認応答（negative acknowledgement）NACKを基地局にフィードバックする。
【0192】
サイドリンクグラントリソースに対応しているプロセスにおいて送信されるべきデータが存在せず、かつ、LBT失敗が発生した場合に、第１端末は、肯定確認応答（acknowledgement）ACKを基地局にフィードバックする。
【0193】
一般的に、第１ターミナルは、サイドリンク構成許可(sidelink configured grant、sidelink CG)を実行するように、基地局に要求するために、ターミナル支援情報(UEAssistanceInformation)を基地局へ送信し得る。例えば、支援情報は、サービス周期、メッセージサイズ、時間オフセット、またはQoSフロー識別子のうちの１つ以上を搬送することができ、そして、以前に受信されたQoSフローに対応するQoSパラメータに基づいて、第１端末のためのサイドリンクCGを構成することを決定するために、基地局によって使用される。例えば、時間オフセットは、発見情報の第１ピースが到着した時点と、基準時点との間の時間オフセットを示している。例えば、基準時点は、システムフレーム番号(system frame number、SFN)0のサブフレーム0であり得る。
【0194】
基地局は、第１端末の要求に基づいて、第１端末のためのサイドリンクCGを設定する。任意的に、サイドリンクCG構成は、リソースプールの指示情報を搬送し、そして、指示情報は、サイドリンクCGがリソースプールにおけるリソースであることを示している。
【0195】
例えば、基地局によってスケジューリングされたサイドリンクグラントを受信した後で、第１端末は、グラントにおいてLBT検出を実行し、そして、LBT失敗が発生したことを第１端末が決定した場合に、第１端末は、グラントを使用してNACKを基地局にフィードバックする。
【0196】
一般的に、DCIを使用することによって、基地局により示されたサイドリンクグラントを受信した後で、第１端末は、グラントをMAC層に示す。次いで、MAC層は、グラントに基づいて、伝送ブロック(transmission block、TB)を取得し、TBをPHY層に送信し、そして、PHY層がTBを送信するのを待つ。アンライセンススペクトルに基づいて、PHY層は、グラントが到着する前に、LBT検出を実行する。
【0197】
サイドリンク通信シナリオにおいて、第１端末によって受信されたリソースまたはグラントは、送信される必要がある、対応するサービスまたはデータを有していないことがある。この場合、第１端末のMAC層は、電力を節約するために、LBT検出を実行することをスキップするように、または、実行されているLBT検出を中断するように、PHY層に指示し得る。任意的に、第１端末がLBT検出をスキップせず、かつ、単一のLBT失敗が発生した場合に、第１端末は、基地局にNACKをフィードバックし得る。サービスデータがグラントにおいて送信される必要がない場合に、第１端末は、基地局が再送リソースをスケジューリングし続けることを回避するために、基地局にACKをフィードバックし得る。
【0198】
図4は、本出願の一つの実施形態に従った、通信デバイス40のハードウェアの概略構造図である。通信デバイス40は、少なくとも１つのプロセッサ401、通信バス402、メモリ403、および、少なくとも１つの通信インターフェイス404を含んでいる。
【0199】
プロセッサ401は、汎用中央処理装置(central processing unit、CPU)、マイクロプロセッサ、特定用途向け集積回路(application-specific integrated circuit、ASIC)、または、本出願におけるソリューションのプログラム実行を制御するように構成された１つ以上の集積回路であってよい。
【0200】
通信バス402は、上記のコンポーネント間で情報が送信される経路を含み得る。
【0201】
通信インターフェイス404は、任意のトランシーバタイプの装置を使用し、そして、別のデバイス、もしくは、イーサネット(登録商標)、無線アクセスネットワーク(radio access network、RAN)、またはワイヤレスローカルエリアネットワーク(wireless local area network、WLAN)のような、通信ネットワークと通信するように構成されている。
【0202】
メモリ403は、読み出し専用メモリ(read-only memory、ROM)、または、静的情報および命令を保管することができる別のタイプの静的ストレージデバイス、もしくは、ランダムアクセスメモリ(random access memory、RAM)、または、情報および命令を保管することができる別のタイプの動的ストレージデバイスであり得る。代替的に、メモリ403は、電気的消去可能プログラマブル読取り専用メモリ(electrically erasable programmable read-only memory、EEPROM)、コンパクトディスク読取り専用メモリ(compact disc read-only memory、CD-ROM)、もしくは、別のコンパクトディスクストレージ、光ディスクストレージ(コンパクト光ディスク、レーザディスク、光ディスク、デジタル多用途ディスク、ブルーレイ（登録商標）ディスク、などを含む)、磁気ディスクストレージ媒体または別の磁気ストレージデバイス、もしくは、命令またはデータ構造の形態の予想されるプログラムコードを搬送または保管するために使用され、コンピュータによってアクセスされ得る、任意の他の媒体であってよい。しかしながら、メモリ403は、これに限定されるものではない。メモリは、独立して存在してよく、そして、バスを介して、プロセッサに接続されている。メモリは、代替的に、プロセッサと一体化されてよい。
【0203】
メモリ403は、本出願のソリューションにおけるアプリケーションプログラムコードを保管し、かつ、実行するように構成されており、そして、プロセッサ401は、実行を制御する。プロセッサ401は、メモリ403に保管されたアプリケーションプログラムコードを実行するように構成されており、本出願の前述の実施形態による通信方法を実施する。
【0204】
代替的には、任意的に、本出願のこの実施形態において、プロセッサ401は、本出願の前述の実施形態で提供される通信方法における処理関連の機能を実行し得る。通信インターフェイス404は、別のデバイスまたはネットワークと通信することを担う。これは、本出願の実施形態において、特には限定されない。
【0205】
具体的な実施の最中に、一つの実施形態において、プロセッサ401は、図4におけるCPU 0およびCPU 1といった、１つ以上のCPUを含み得る。
【0206】
具体的な実施の最中に、一つの実施形態において、通信デバイス40は、複数のプロセッサ、例えば、図4におけるプロセッサ401およびプロセッサ408を含み得る。各プロセッサは、シングルコア(シングルCPU)のプロセッサであってよく、または、マルチコア(マルチCPU)のプロセッサであってもよい。本明細書におけるプロセッサは、データ(例えば、コンピュータプログラム命令)を処理するように構成された１つ以上のデバイス、回路、及び／又は、処理コアであってよい。図4は、通信デバイス40の簡略化された設計のみを示していることが理解されるだろう。実際の適用の最中に、通信デバイスは、任意の数の入力デバイス、出力デバイス、プロセッサ、メモリ、および、通信インターフェイスを含んでよく、そして、前述の機能は、任意の数の通信ユニットによって、別々に、または、組合せの形で提供され得る。
【0207】
具体的な実施の最中に、一つの実施形態において、通信デバイス40は、さらに、出力デバイス405および入力デバイス406を含み得る。出力デバイス405は、プロセッサ401と通信し、そして、複数の方法で情報を表示し得る。例えば、出力デバイス405は、液晶ディスプレイ(liquid crystal display、LCD)、発光ダイオード(light emitting diode、LED)ディスプレイデバイス、ブラウン管(cathode ray tube、CRT)ディスプレイデバイス、プロジェクタ(projector)など、であってよい。入力デバイス406は、プロセッサ401と通信し、そして、複数の方法でユーザ入力を受信し得る。例えば、入力デバイス406は、マウス、キーボード、タッチスクリーン装置、または、センサ装置であってよい。
【0208】
加えて、上述のように、本出願のこの実施形態において提供される通信デバイス40は、チップ、端末、基地局、通信デバイス、ネットワークデバイス、CU、または、DU、もしくは、図4の構造と同様の構造を有するデバイスであってよい。通信デバイス40のタイプは、本出願の実施形態において限定されない。
【0209】
図5は、本出願の一つの実施形態に従った、通信方法における通信デバイス500の構造の概略図である。通信デバイスは、実施形態における端末、基地局、通信デバイス、ネットワークデバイス、端末または基地局の機能を有する装置、チップなどであってよい。以下の用語もしくは名詞の、意味または機能は、前述の説明を参照して理解されてよく、そして、以下のステップもしくはアクションの、詳細または実装も、また、前述の説明を参照して理解されてよい。図5に示されるように、通信デバイス500は、処理ユニット510およびトランシーバユニット530を含み得る。代替的に、通信デバイス内のトランシーバユニットは、受信モジュールおよび送信モジュールを含んでよく、そして、受信モジュールおよび送信モジュールは、アンテナに基づいて接続され得る。
【0210】
トランシーバユニット530は、通信デバイスとネットワークデバイスとの間の情報の受信および送信をサポートするように構成され得る。代替的に、トランシーバユニット530は、前述の実施形態において説明された通信方法において通信デバイスまたはネットワークデバイスによって実行される処理を実行するように構成され得る。
【0211】
可能な設計において、通信デバイスは、端末デバイス、または、端末デバイス内に構成されたチップであってよい。以下では、説明のために、実行主体として、第１通信デバイスまたは第２通信デバイスを使用している。
【0212】
第１の可能な実装において、第１通信デバイスは、トランシーバユニット530を使用することによってネットワークデバイスから構成情報を受信する。構成情報は、第１リソースプールにおいて発生したLBT失敗を検出するために第１通信デバイスによって使用され、構成情報は、第１キャリアまたは第１リソースプールに関連付けられ、第１リソースプールは、第１キャリアに属している。加えて、第１通信デバイスは、トランシーバユニット530を使用することによって、第１指示情報をネットワークデバイスに送信する。第１指示情報は、一貫したLBT失敗が発生した第１リソースプールを示す。
【0213】
本通信方式に基づいて、端末間のサイドリンク通信のフレキシブルな構成を実施することができ、かつ、システム適応の信頼性を改善することができる。
【0214】
任意的に、構成情報は、LBT失敗の最大回数およびタイマ長を含む。第１通信デバイスのPHYエンティティは、第１通信デバイスのMACエンティティに対して、第１リソースプールにおいて発生したLBT失敗を示す。MACエンティティは、第１リソースプールに対応しているタイマを開始し、かつ、第１リソースプールにおいて発生したLBT失敗に基づいて、第１リソースプールに対応しているカウンタのカウント値を増加させる。カウンタのカウント値が最大値に達したときに、MACエンティティは、一貫したLBT失敗が発生したと決定する。
【0215】
前述のLBT検出は、第１通信デバイスが可能なLBT失敗ステータスをリアルタイムで知ることを保証し、タイムリーに回復を実行し、そして、サイドリンク通信の有効性を保証することができる。
【0216】
任意的に、第１通信デバイスは、既定時間内に第１リソースプールにおけるリソース選択を停止する。代替的に、第１キャリアの全てのリソースプールにおいて一貫したLBT失敗が発生したときに、第１通信デバイスは、サイドリンクの第２キャリアを再選択する。
【0217】
任意的に、第１通信デバイスは、トランシーバユニット530を使用することによって、第２通信デバイスから第２指示情報を受信する。第２指示情報は、サイドリンク上にあり、かつ、一貫したLBTが失敗した、第２リソースプールまたは第２キャリアを示す。
【0218】
第２指示情報に基づいて、第１通信デバイスは、第２リソースプールまたは第２キャリアに基づいて、第２通信デバイスとサイドリンク通信を実行するか否かを決定してよく、例えば、既定時間内に前述のリソースを使用しないか、または、別のリソースを使用するように変更して、リアルタイム通信を確実にする。
【0219】
任意的に、第１通信デバイスは、トランシーバユニット530を使用することによって、第３指示情報をネットワークデバイスに送信する。第３指示は、第２リソースプールまたは第２キャリアを示す。
【0220】
任意的に、第３指示情報は、さらに、第１通信デバイスと第２通信デバイスとの間のユニキャスト接続を示す。
【0221】
第３情報に基づいて、ネットワークデバイスは、第１通信デバイスと第２通信デバイスとの間のリアルタイムの有効な通信を保証し、かつ、スケジューリングの信頼性を向上させるために、第１通信デバイスに対して前述のリソースをスケジューリングしなくてよく、もしくは、別のリソースプールまたはキャリアに基づいて、第１通信デバイスに対してリソースをスケジューリングしてよい。
【0222】
任意的に、第１通信デバイスは、処理ユニット510を使用することによって、第３リソースプールにおけるリソース、または、サイドリンク上での第３キャリア上のリソースを選択し、かつ、リソースに基づいて第２通信デバイスとのユニキャスト接続通信を実行する。
【0223】
第３リソースプールは、第２リソースプールとは異なり、または、第３キャリアは、第２キャリアとは異なる。
【0224】
任意的に、第１通信デバイスは、処理ユニット510またはトランシーバユニット530を使用することによって、サイドリンクグラントリソースを取得する。グラントリソースは、第２リソースプール内または第２キャリア上に置かれている。
【0225】
第１通信デバイスは、第２通信デバイスとユニキャスト接続通信を実行するために、グラントリソースを使用しない。
【0226】
任意的に、第１通信デバイスは、トランシーバユニット530を使用することによって、第４指示情報を第２通信デバイスに送信する。第４指示情報は、一貫したLBT失敗が発生した第１リソースプールまたは第１キャリアを示す。
【0227】
任意的に、サイドリンクが複数のキャリアを含むときに、第１指示情報は、さらに、第１リソースプールが属するキャリアを示す。
【0228】
任意的に、第１通信デバイスは、トランシーバユニット530を使用することによって、ネットワークデバイスからサイドリンクグラントリソースを受信する。グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、第１通信デバイスは、グラントリソース上でのLBT検出をスキップし、または、中断する。
【0229】
任意的に、第１通信デバイスは、トランシーバユニット530を使用することによって、ネットワークデバイスからサイドリンクグラントリソースを受信し、そして、第１通信デバイスは、グラントリソース上でLBT検出を実行する。グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在する場合に、第１通信デバイスは、トランシーバユニット530を使用することによって、NACKをネットワークデバイスにフィードバックする。代替的に、グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、第１通信デバイスは、トランシーバユニット530を使用することによって、ACKをネットワークデバイスにフィードバックする。
【0230】
通信デバイスの前述の挙動に基づいて、ネットワークデバイスが無効な、または、無用なリソーススケジューリングを実行するケースが回避され得る。これは、リソーススケジューリングの有効性を達成する。
【0231】
第２の可能な実装において、第１通信デバイスは、トランシーバユニット530を使用することによって、第２通信デバイスから第１指示情報を受信する。第１指示情報は、サイドリンク上にあり、かつ、一貫したリッスンビフォアトークLBT失敗が発生した第１リソースプールまたは第１キャリアを示す。加えて、第１通信デバイスは、トランシーバユニット530を使用することによって、第２指示情報をネットワークデバイスに送信する。第２指示情報は、第１リソースプールまたは第１キャリアを示す。
【0232】
任意的に、第２指示情報は、さらに、第１通信デバイスと第２通信デバイスとの間のユニキャスト接続を示す。
【0233】
任意的に、第１通信デバイスは、処理ユニット510を使用することによって、第２リソースプールにおけるリソース、または、サイドリンク上での第２キャリア上のリソースを選択し、かつ、リソースに基づいて、第２通信デバイスとユニキャスト接続通信を実行する。
【0234】
第２リソースプールは、第２リソースプールとは異なり、または、第２キャリアは、第２キャリアとは異なる。
【0235】
任意的に、第１通信デバイスは、トランシーバユニット530または処理ユニット510を使用することによって、サイドリンクグラントリソースを取得する。グラントリソースは、第１リソースプール内または第１キャリア上に置かれている。第１通信デバイスは、第２通信デバイスとユニキャスト接続通信を実行するために、グラントリソースを使用しない。
【0236】
任意的に、サイドリンクが複数のキャリアを含む場合に、第１指示情報は、さらに、第１リソースプールが属しているキャリアを示す。
【0237】
任意的に、第１通信デバイスは、トランシーバユニット530を使用することによって、ネットワークデバイスからサイドリンクグラントリソースを受信する。グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、第１通信デバイスは、グラントリソース上でのLBT検出をスキップし、または、中断する。
【0238】
任意的に、第１通信デバイスは、トランシーバユニット530を使用することによって、ネットワークデバイスからサイドリンクグラントリソースを受信する。第１通信デバイスは、グラントリソース上でLBT検出を実行する。グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在する場合に、第１通信デバイスは、トランシーバユニット530を使用することによって、NACKをネットワークデバイスにフィードバックする。代替的に、グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、第１通信デバイスは、トランシーバユニット530を使用することによって、ACKをネットワークデバイスにフィードバックする。
【0239】
別の可能な設計において、通信装置は、ネットワークデバイス、または、ネットワークデバイス内で構成されたチップであってよい。以下は、説明のために、実行主体としてネットワークデバイスを使用している。
【0240】
可能な実装において、ネットワークデバイスは、トランシーバユニット530を使用することによって、構成情報を第１通信デバイスに送信する。構成情報は、第１キャリアまたは第１リソースプールに関連付けられており、かつ、第１リソースプールは、第１キャリアに属している。加えて、ネットワークデバイスは、第１通信デバイスから第１指示情報を受信する。第１指示情報は、一貫したLBT失敗が発生した第１リソースプールを示す。
【0241】
任意的に、構成情報は、LBT検出の最大回数、および、タイマ長を含む。
【0242】
任意的に、第１指示情報は、さらに、第１通信デバイスと第２通信デバイスとの間のユニキャスト接続を示す。
【0243】
任意的に、サイドリンクが複数のキャリアを含む場合に、第１指示情報は、さらに、第１リソースプールが属しているキャリアを示す。
【0244】
この実施形態において、通信デバイスまたはネットワークデバイスは、統合された形での分割を介して所得される機能モジュールまたはユニットの形態で提示される。本明細書における「モジュール（“module”）」または「ユニット（“unit”）」は、特定用途向け集積回路(Application-Specific Integrated Circuit、ASIC)、１つ以上のソフトウェアプログラムまたはファームウェアプログラムを実行する回路、プロセッサおよびメモリ、集積論理回路、及び／又は、前述の機能を提供することができる別のコンポーネントであってよい。簡単な実施形態において、当業者であれば、装置500が図4に示される形態であってよいことを理解するだろう。例えば、図5のトランシーバユニット530の機能/実装プロセスは、図4のプロセッサ401およびメモリ403によって実装され得る。具体的に、メモリ403に保管されたアプリケーションプログラムコードは、プロセッサ401によって呼び出されてよい。これは、本出願の実施形態において限定されない。代替的には、任意的に、図5のトランシーバユニット530の機能/実装プロセスは、図4のプロセッサ401によって実装されてよく、または、図4の通信インターフェイス404によって実装されてもよい。これは、本出願の実施形態において限定されない。具体的に、メモリ403に保管されたアプリケーションプログラムコードは、プロセッサ401によって呼び出されてよい。これは、本出願の実施形態において限定されない。
【0245】
任意的に、本出願の一実施形態は、チップシステムを提供する。チップシステムは、前述の通信方法を実施する通信デバイスをサポートするように構成されたプロセッサを含む。可能な設計において、チップシステムは、さらに、メモリを含む。メモリは、通信デバイスに必要なプログラム命令およびデータを保管するように構成されている。チップシステムは、チップを含んでよく、または、チップおよび別のディスクリートデバイスを含んでもよい。これは、本出願の実施形態において特に限定されない。
【0246】
本発明における基地局、端末、基地局または端末を実行するように構成されたコントローラ/プロセッサは、中央処理装置(CPU)、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または、別のプログラマブル論理デバイス、トランジスタ論理デバイス、ハードウェアコンポーネント、もしくは、それらの任意の組合せであってよい。コントローラ/プロセッサは、本発明で開示された内容を参照して説明された様々な例示的な論理ブロック、モジュール、および回路を実装または実行し得る。プロセッサは、コンピューティング機能を実装するプロセッサの組合せ、例えば、１つ以上のマイクロプロセッサの組合せ、または、DSPとマイクロプロセッサとの組合せであり得る。
【0247】
本発明で開示された内容と組み合わせて説明された方法またはアルゴリズムステップは、ハードウェアによって実施されてよく、または、ソフトウェア命令を実行することによって、プロセッサによって実施されてもよい。ソフトウェア命令は、対応するソフトウェアモジュールを含み得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルハードディスク、CD-ROMメモリ、または、当技術分野でよく知られている任意の他の形態のストレージ媒体に保管され得る。例えば、ストレージ媒体は、プロセッサがストレージ媒体から情報を読み取り、ストレージ媒体に情報を書き込むことができるように、プロセッサに結合されている。確かに、ストレージ媒体は、プロセッサのコンポーネントであってよい。プロセッサおよびストレージ媒体は、ASIC内に配置されてよい。加えて、ASICは、端末または基地局に配置されてもよい。確かに、プロセッサおよびストレージ媒体は、端末または基地局内に個別コンポーネントとして存在してよい。
【0248】
当業者であれば、前述の１つ以上の例において、本発明において説明された機能が、ハードウェア、ソフトウェア、ファームウェア、または、それらの任意の組合せによって実装され得ることを認識すべきである。機能がソフトウェアによって実装されるとき、前述の機能は、コンピュータ可読媒体に保管されてよく、もしくは、コンピュータ可読媒体内の１つ以上の命令またはコードとして送信されてもよい。コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含み、通信媒体は、コンピュータプログラムがある場所から別の場所に送信されることを可能にする任意の媒体を含む。ストレージ媒体は、汎用または専用コンピュータにアクセス可能な任意の利用可能な媒体であり得る。
【0249】
本発明の前述の実施形態において、本発明の実施形態で提供される通信方法は、各ネットワーク要素およびネットワーク要素間のインタラクションの観点から説明されている。端末または通信デバイスのような各ネットワーク要素は、前述の機能を実装するために、対応する機能を実行するためのハードウェア構造及び／又はソフトウェアモジュールを含むことが理解され得る。当業者であれば、本明細書に開示された実施形態に記載された例、ユニット、アルゴリズム、およびステップと組み合わせて、本発明が、ハードウェア、または、ハードウェアとコンピュータソフトウェアとの組み合わせによって実装され得ることを容易に認識するはずである。機能が、ハードウェアによって実行されるか、または、コンピュータソフトウェアによって駆動されるハードウェアによって実行されるかは、技術的ソリューションの特定の用途および設計制約に依存する。当業者であれば、各特定のアプリケーションについて説明された機能を実施するために異なる方法を使用し得るが、その実施は、本発明の範囲を超えると考えられるべきではない。
【0250】
本発明の目的、技術的ソリューション、および、有益な効果は、前述の具体的な実装形態において、さらに、詳細に説明されている。前述の説明は、本発明の特定の実施形態に過ぎず、そして、本発明の保護範囲を限定することを意図するものではないことが理解されるべきである。本発明の技術的ソリューションに基づいて行われる任意の修正、等価な置換、改善などは、本発明の保護範囲内に入るものとする。
【図1a】
【図1b】
【図1c】
【図2a】
【図2b】
【図2c】
【図3】
【図3a】
【図3b】
【図3c】
【図4】
【図5】
【手続補正書】
【提出日】2024-06-05
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
サイドリンク通信方法であって、第１通信デバイスによって、ネットワークデバイスから構成情報を受信するステップであり、
前記構成情報は、第１リソースプールにおいて発生した、一貫したリッスンビフォアトーク（LBT）失敗を検出するために、前記第１通信デバイスによって使用され、
前記構成情報は、第１キャリアまたは前記第１リソースプールに関連付けられ、
前記第１リソースプールは、前記第１キャリアに属している、ステップと、
前記第１通信デバイスによって、第１指示情報を前記ネットワークデバイスに送信するステップであり、
前記第１指示情報は、前記一貫したLBT失敗が発生した前記第１リソースプールを示す、ステップと、
を含む、方法。
【請求項2】
前記構成情報は、前記一貫したLBT失敗の数の最大値およびタイマ長を含み、前記第１通信デバイスの物理（PHY）エンティティは、前記第１通信デバイスのメディアアクセス制御（MAC）エンティティに対して、前記第１リソースプールにおいて発生した前記LBT失敗を示し、
前記MACエンティティは、前記第１リソースプールに対応しているタイマを開始し、かつ、前記第１リソースプールにおいて発生した前記LBT失敗に基づいて、前記第１リソースプールに対応しているカウンタのカウント値を増加させ、
前記カウンタの前記カウント値が前記最大値に達したときに、前記MACエンティティは、前記第１リソースプールにおいて前記一貫したLBT失敗が発生したと決定する、
請求項１に記載の方法。
【請求項3】
前記方法は、さらに、前記第１通信デバイスによって、既定時間内に、前記第１リソースプールにおけるリソース選択を停止するステップ、または、
前記第１通信デバイスによって、前記第１キャリアの全てのリソースプールにおいて前記一貫したLBT失敗が発生したときに、前記サイドリンクの第２キャリアを再選択するステップ、
を含む、請求項１または２に記載の方法。
【請求項4】
前記方法は、さらに、前記第１通信デバイスによって、第２通信デバイスから第２指示情報を受信するステップであり、
前記第２指示情報は、前記サイドリンク上にあり、かつ、前記一貫したLBT失敗が発生した、第２リソースプールまたは第２キャリアを示す、ステップ、
を含む、請求項１に記載の方法。
【請求項5】
前記方法は、さらに、前記第１通信デバイスによって、第３指示情報をネットワークデバイスに送信するステップであり、
前記第３指示情報は、前記第２リソースプールまたは前記第２キャリアを示す、ステップ、
を含む、請求項４に記載の方法。
【請求項6】
前記第３指示情報は、さらに、前記第１通信デバイスと前記第２通信デバイスとの間のユニキャスト接続を示す、請求項５に記載の方法。
【請求項7】
前記方法は、さらに、前記第１通信デバイスによって、第３リソースプールにおけるリソース、または、前記サイドリンク上での第３キャリア上のリソースを選択し、かつ、前記リソースに基づいて、前記第２通信デバイスとユニキャスト接続通信を実行するステップ、を含み、
前記第３リソースプールは、前記第２リソースプールとは異なり、または、前記第３キャリアは、前記第２キャリアとは異なる
請求項６に記載の方法。
【請求項8】
前記方法は、さらに、前記第１通信デバイスによって、サイドリンクグラントリソースを取得するステップであり、
前記グラントリソースは、前記第２リソースプール内または前記第２キャリア上に置かれている、ステップと、
前記第１通信デバイスによって、前記グラントリソースを使用することなく、前記第２通信デバイスと前記ユニキャスト接続通信を実行するステップと、
を含む、請求項７に記載の方法。
【請求項9】
前記方法は、さらに、前記第１通信デバイスによって、第４指示情報を第２通信デバイスに送信するステップであり、
前記第４指示情報は、前記一貫したLBT失敗が発生した前記第１リソースプールまたは前記第１キャリアを示す、ステップ、
を含む、請求項１または２に記載の方法。
【請求項10】
前記サイドリンクが複数のキャリアを含むときに、前記第１指示情報は、さらに、前記第１リソースプールが属するキャリアを示す、請求項１または２に記載の方法。
【請求項11】
前記方法は、さらに、前記第１通信デバイスによって、前記ネットワークデバイスからサイドリンクグラントリソースを受信するステップと、
前記グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、前記第１通信デバイスによって、前記グラントリソース上でのLBT検出をスキップし、または、中断するステップと、
を含む、請求項１または２に記載の方法。
【請求項12】
前記方法は、さらに、前記第１通信デバイスによって、前記ネットワークデバイスからサイドリンクグラントリソースを受信するステップと、
前記第１通信デバイスによって、前記グラントリソース上でLBT検出を実行するステップと、
前記グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在する場合に、前記第１通信デバイスによって、否定確認応答NACKを前記ネットワークデバイスにフィードバックするステップと、
前記グラントリソースに対応する前記プロセスにおいて送信されるべきデータが存在しない場合に、前記第１通信デバイスによって、肯定確認応答ACKを前記ネットワークデバイスにフィードバックするステップと、
を含む、請求項１または２に記載の方法。
【請求項13】
サイドリンク通信方法であってネットワークデバイスによって、構成情報を第１通信デバイスに送信するステップであり、
前記構成情報は、第１キャリアまたは第１リソースプールに関連付けられており、かつ、前記第１リソースプールは、前記第１キャリアに属している、ステップと、
前記ネットワークデバイスによって、前記第１通信デバイスから第１指示情報を受信するステップであり、
前記第１指示情報は、一貫したLBT失敗が発生した前記第１リソースプールを示す、ステップと、
を含む、方法。
【請求項14】
前記構成情報は、前記LBT失敗の最大回数、および、タイマ長を含む、請求項１３に記載の方法。
【請求項15】
前記第１指示情報は、さらに、前記第１通信デバイスと第２通信デバイスとの間のユニキャスト接続を示す、請求項１３または１４に記載の方法。
【請求項16】
前記サイドリンクが複数のキャリアを含む場合に、前記第１指示情報は、さらに、前記第１リソースプールが属しているキャリアを示す、請求項１３または１４に記載の方法。
【請求項17】
サイドリンク通信方法であって、第１通信デバイスによって、第２通信デバイスから第１指示情報を受信するステップであり、
前記第１指示情報は、サイドリンク上にあり、かつ、一貫したリッスンビフォアトーク（LBT）失敗が発生した第１リソースプールまたは第１キャリアを示す、ステップと、
前記第１通信デバイスによって、第２指示情報をネットワークデバイスに送信するステップであり、
前記第２指示情報は、前記第１リソースプールまたは前記第１キャリアを示す、ステップと、
を含む、方法。
【請求項18】
前記第２指示情報は、さらに、前記第１通信デバイスと前記第２通信デバイスとの間のユニキャスト接続を示す、請求項１７に記載の方法。
【請求項19】
前記第１通信デバイスにおいて、第２リソースプールにおけるリソース、または、前記サイドリンク上での第２キャリア上のリソースを選択し、かつ、前記リソースに基づいて、前記第２通信デバイスとユニキャスト接続通信を実行するステップ、を含み、前記第２リソースプールは、前記第１リソースプールとは異なり、または、前記第２キャリアは、前記第１キャリアとは異なる、
請求項１８に記載の方法。
【請求項20】
前記方法は、さらに、前記第１通信デバイスによって、サイドリンクグラントリソースを取得するステップであり、
前記グラントリソースは、前記第１リソースプール内または前記第１キャリア上に置かれている、ステップと、
前記第１通信デバイスによって、前記グラントリソースを使用することなく、前記第２通信デバイスと前記ユニキャスト接続通信を実行するステップと、
を含む、請求項１９に記載の方法。
【請求項21】
前記サイドリンクが複数のキャリアを含む場合に、前記第１指示情報は、さらに、前記第１リソースプールが属しているキャリアを示す、請求項１７乃至１９いずれか一項に記載の方法。
【請求項22】
前記方法は、さらに、前記第１通信デバイスによって、前記ネットワークデバイスからサイドリンクグラントリソースを受信するステップと、
前記グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在しない場合に、前記第１通信デバイスによって、前記グラントリソース上でのLBT検出をスキップし、または、中断するステップと、
を含む、請求項１７乃至１９いずれか一項に記載の方法。
【請求項23】
前記方法は、さらに、前記第１通信デバイスによって、前記ネットワークデバイスからサイドリンクグラントリソースを受信するステップと、
前記第１通信デバイスによって、前記グラントリソース上でLBT検出を実行するステップと、
前記グラントリソースに対応しているプロセスにおいて送信されるべきデータが存在する場合に、前記第１通信デバイスによって、否定確認応答NACKを前記ネットワークデバイスにフィードバックするステップと、
前記グラントリソースに対応する前記プロセスにおいて送信されるべきデータが存在しない場合に、前記第１通信デバイスによって、肯定確認応答ACKを前記ネットワークデバイスにフィードバックするステップと、
を含む、請求項１７乃至１９いずれか一項に記載の方法。
【請求項24】
装置であって、請求項１、２、５～７、１３、１４、１７～１９のうちいずれか一項に記載の方法を実行するように構成されている、
装置。
【請求項25】
装置であって、前記装置は、プロセッサ、メモリ、および、前記メモリに保管されており、かつ、前記プロセッサ上で実行されることが可能な命令、を含み、
前記命令が実行されると、前記装置は、請求項１に記載の方法を実行することができる、
装置。
【請求項26】
装置であって、前記装置は、プロセッサ、メモリ、および、前記メモリに保管されており、かつ、前記プロセッサ上で実行されることが可能な命令、を含み、
前記命令が実行されると、前記装置は、請求項１３に記載の方法を実行することができる、
装置。
【請求項27】
請求項２５に記載の装置を備える、端末。
【請求項28】
請求項２６に記載の装置を備える、基地局。
【請求項29】
通信システムであって、請求項２７に記載の端末、および、請求項２８に記載の基地局を備える、
通信システム。
【請求項30】
命令を含む、コンピュータ可読記憶媒体であって、前記命令がコンピュータ上で実行されると、前記コンピュータは、請求項１、２、５～７、１３、１４、１７～１９のうちいずれか一項に記載の方法を実行することができる、
コンピュータ可読記憶媒体。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】００２６
【補正方法】変更
【補正の内容】
【0026】
例えば、第１通信デバイスは、サイドリンク上の別のリソースプールにおけるリソースまたは別のキャリア上のリソースを選択し、そして、当該リソースに基づいて、第２通信デバイスとユニキャスト接続通信を実行する。別のリソースプールは、一貫したLBT失敗が発生したリソースプールとは異なり、または、別のキャリアは、一貫したLBT失敗が発生したキャリアとは異なる。代替的に、第１通信デバイスは、サイドリンクグラントリソースを取得する。グラントリソースは、一貫したLBT失敗が発生したリソースプール、または、一貫したLBT失敗が発生したキャリアに置かれている。従って、第１通信デバイスは、第２通信デバイスとユニキャスト接続通信を実行するために、サイドリンクグラントリソースを使用しない。
【手続補正3】
【補正対象書類名】明細書
【補正対象項目名】００５９
【補正方法】変更
【補正の内容】
【0059】
以下は、本発明の実施形態における添付の図面を参照して、本発明の実施形態における技術的ソリューションを明確に説明する。
【手続補正4】
【補正対象書類名】明細書
【補正対象項目名】００６１
【補正方法】変更
【補正の内容】
【0061】
図1aは、本出願の実施形態が適用可能である、可能なシステムアーキテクチャの概略図である。図1aに示されるシステムアーキテクチャは、第１デバイス101および第２デバイス102を含んでいる。本出願のこの実施形態における第２デバイスは、無線方式で第１デバイスに接続されてよい。別の言葉で言えば、第２デバイスは、ワイヤレスネットワークを介して、第１デバイスと通信し得る。図1aは、単に通信システムアーキテクチャの概略図に過ぎないことが理解されるべきである。通信システムにおける第１デバイスの数および第２デバイスの数は、本出願の実施形態において限定されない。この実施形態において、無線方式は、サイドリンク通信及び／又は無線リンク通信として理解されてよい。
【手続補正5】
【補正対象書類名】明細書
【補正対象項目名】００７０
【補正方法】変更
【補正の内容】
【0070】
通信システムにおける端末デバイスは、また、ユーザ機器(user equipment、UE)、アクセス端末、加入者ユニット、加入者局、移動局、遠隔局、遠隔端末、モバイルデバイス、ユーザ端末、端末、ワイヤレス通信デバイス、ユーザエージェント、またはユーザ装置とも称される得ることが、さらに、理解されるべきである。本出願の実施形態における端末デバイスは、携帯電話(mobile phone)、タブレット(Pad)、無線トランシーバ機能を有するコンピュータ、仮想現実(virtual reality、VR)端末デバイス、拡張現実(augmented reality、AR)端末デバイス、産業制御(industrial control)における無線端末、自動運転(self-driving)における無線端末、遠隔医療(remote medical)における無線端末、スマートグリッド(smart grid)における無線端末、交通安全(transportation safety)における無線端末、スマートシティ(smart city)における無線端末、スマートホーム(smart home)における無線端末、などであり得る。適用シナリオは、本出願の実施形態において限定されない。本出願において、前述の端末デバイスおよび前述の端末デバイスに配置され得るチップは、端末デバイスと総称される。本出願の理解を容易にするために、本出願で提供される通信方法が説明される前に、本出願における概念が、最初に、簡潔に説明される。
【手続補正6】
【補正対象書類名】明細書
【補正対象項目名】０１２１
【補正方法】変更
【補正の内容】
【0121】
代替的に、オペレータは、端末のためにサイドリンクリソースプールを事前構成するか、または、標準プロトコルにおいて事前定義された方法で端末のためにサイドリンクリソースプールを事前構成する。事前構成方式において、リソースプール構成は、１つ以上の端末において実行され得る。具体的な実装の最中に、コアネットワークデバイス(例えば、ポリシ制御機能ネットワーク要素、PCFネットワーク要素)は、事前構成情報を各端末に別々に送信することができ、そして、事前構成情報は、各端末においてリソースプール構成を別々に実行するために使用される。事前構成情報が複数の端末に送信されるので、事前構成情報は、端末間のブロードキャスト送信のために使用され得る。例えば、端末1は、事前構成情報を使用することによってデータ及び／又は制御情報をブロードキャストすることができ、そして、別の端末、例えば、端末2は、事前構成情報に基づいてデータを受信し、かつ／あるいは、情報を制御することができる。
【手続補正7】
【補正対象書類名】明細書
【補正対象項目名】０１３６
【補正方法】変更
【補正の内容】
【0136】
複数のサイドリンクキャリアがサポートされるシナリオを考慮して、第１端末は、さらに、リソースプールが属するキャリアに関する情報を、MAC CEにおいて、含んでよい。図3cに示されるように、MAC CEは、キャリア識別子フィールドを含み得る。例えば、8個のキャリアは、それぞれC0からC7までとして表されており、そして、図中の各Ciフィールドは、１つのキャリアに対応している。第１キャリアに対応するCiフィールドが第１値であるとき、それは、第１キャリアに対応している8個のリソースプール識別子フィールドが、さらに、MAC CEにおいて識別され得ることを示す。第１キャリアに対応するCiフィールドが第２値であるとき、それは、第１キャリアに対応している8個のリソースプール識別子フィールドが、MAC CEにおいて識別され得ないことを示す。実際のアプリケーションにおいて、キャリア識別子フィールドは、代替的に、別の方式で示されてよい。このことは、本出願の実施形態において限定されない。キャリア識別子フィールドは、一貫したLBT失敗が、キャリア上の端末で発生したか否かを示す。同様に、キャリア識別子フィールドに対応するビットの値が第１値であるとき、それは、一貫したLBT失敗が、キャリア上の端末で発生したことを示す。キャリア識別子フィールドに対応するビットの値が第２値であるとき、それは、キャリア上の端末で一貫したLBT失敗が発生していないことを示す。第１値および第２値の具体的な値は、限定されない。例えば、第１値は1であり、そして、第２値は0である。
【国際調査報告】