(57)【特許請求の範囲】
【請求項１】
第1のモバイルデバイスにより、データパケットを取得するステップと、
前記第1のモバイルデバイスにより、リソースの第1のセットから、前記データパケットに関連付けられたスケジューリング情報を送信するための制御リソースを決定するステップであって、前記制御リソースが物理サイドリンク制御チャネル（PSCCH）を備える、ステップと、
前記スケジューリング情報が、前記データパケットを送信するための送信情報、前記データパケットを肯定応答(ACK)／否定応答(NACK)で確認されることの指示、および宛先識別子(ID)を備え、前記データパケットを送信するための前記送信情報によって示されるリソースのセットは、物理サイドリンク共有チャネル(PSSCH)を含む、ステップと、
前記第1のモバイルデバイスにより、第2のモバイルデバイスに、前記制御リソース上で前記スケジューリング情報を送信し、前記スケジューリング情報の前記送信情報によって示されたリソースのセット上で前記データパケットを送信するステップと、
前記第1のモバイルデバイスにより、前記ACK／NACKリソース上で前記第2のモバイルデバイスによって送信されたACK／NACKをリッスンするステップと、
前記第1のモバイルデバイスにより、前記第2のモバイルデバイスから、前記ACK／NACKリソース上でACKまたはNACKを受信するステップと、
前記ACKまたは前記NACKに従ってグループメンバ識別子（ID）を決定するステップと、
前記グループメンバIDについてグループメンバIDリストを調査することに少なくとも部分的に基づいて、前記グループメンバIDリストに前記グループメンバIDを追加するステップと
を備える、方法。
【請求項２】
前記第1のモバイルデバイスにより、前記第2のモバイルデバイスに、前記制御リソース上で前記スケジューリング情報を送信するステップが、前記第1のモバイルデバイスにより、前記PSCCH上で前記データパケットに関連付けられた前記スケジューリング情報をブロードキャストするステップであって、前記スケジューリング情報がサイドリンク制御情報（SCI）としてブロードキャストされる、ステップを備える、請求項1に記載の方法。
【請求項３】
前記送信情報によって示されたリソースの前記セット上で前記データパケットを送信するステップが、前記第2のモバイルデバイスを備えるモバイルデバイスのグループに前記データパケットをグループキャストするステップを備える、請求項1または2に記載の方法。
【請求項４】
前記ACK／NACKリソース上で受信されたACK／NACKの数をカウントするステップと、
受信されたACK／NACKの前記数および前記モバイルデバイスのグループ内のモバイルデバイスの数に少なくとも部分的に基づいて、前記データパケットを再送信するステップと
をさらに備える、請求項1から3のいずれか一項に記載の方法。
【請求項５】
リソースの第2のセットがACK／NACKプールを備え、
前記データパケットを送信するための前記送信情報によって示されたリソースの前記セットが、物理サイドリンク共有チャネル（PSSCH）を備え、
前記第1のモバイルデバイスにより、リソースの前記第2のセットから、前記データパケットに関連付けられた前記ACK／NACKリソースを決定するステップが、ダウンリンク制御インジケータ（DCI）に従って前記ACK／NACKプールから前記ACK／NACKリソースを選択するステップを備える、
請求項1から4のいずれか一項に記載の方法。
【請求項６】
前記第1のモバイルデバイスにより、eノードB（eNB）から、リソースの前記第2のセットを示すダウンリンク制御インジケータ（DCI）を受信するステップをさらに備える、請求項1から5のいずれか一項に記載の方法。
【請求項７】
前記データパケットを送信するための前記送信情報が、前記データパケットを再送信するための再送信情報であり、
前記第1のモバイルデバイスにより、前記第2のモバイルデバイスに、前記送信情報によって示されたリソースの前記セット上で前記データパケットを送信するステップが、前記再送信情報によって示されたリソースの前記セット上で前記データパケットを再送信するステップを備える、
請求項1から6のいずれか一項に記載の方法。
【請求項８】
前記ACK／NACKリソース上で前記第2のモバイルデバイスによって送信された前記ACK／NACKを受信するステップであって、前記ACK／NACKがACKであり、前記ACKが前記第2のモバイルデバイスによる前記データパケットの受信を示す、ステップをさらに備える、請求項1から7のいずれか一項に記載の方法。
【請求項９】
前記ACK／NACKリソースが復調基準信号（DMRS）に隣接している、請求項1から8のいずれか一項に記載の方法。
【請求項１０】
第1のモバイルデバイスにより、第2のモバイルデバイスから、制御リソース上でデータパケットに関連付けられたスケジューリング情報を受信するステップであって、前記制御リソースが物理サイドリンク制御チャネル（PSCCH）を備え、前記スケジューリング情報が、前記第2のモバイルデバイスによって前記データパケットを送信するための送信情報、前記データパケットを肯定応答(ACK)／否定応答(NACK)で確認されることの指示、および宛先識別子(ID)を備え、前記スケジューリング情報がサイドリンク制御情報（SCI）を含むかまたはサイドリンク制御情報（SCI）として通信され、前記データパケットを送信するための前記送信情報によって示されるリソースのセットは、物理サイドリンク共有チャネル(PSSCH)を含む、ステップと、
前記第1のモバイルデバイスにより、前記第2のモバイルデバイスから、前記送信情報によって示されたリソース上で前記データパケットを受信するステップと、
前記第1のモバイルデバイスにより、ACKを送信するか、またはNACKを送信するように決定することに応答して、前記第1のモバイルデバイスのグループメンバ識別子に基づいて、符号分割多重化(CDM)を通じて前記第2のモバイルデバイスに、前記ACK／NACKリソース上で前記ACKまたは前記NACKを送信するステップと
を備える、方法。
【請求項１１】
前記SCIの位置に従って前記ACK／NACKリソースを決定するステップをさらに備える、請求項10に記載の方法。
【請求項１２】
前記ACKまたは前記NACKがインジケータの一部であり、前記インジケータが、ACKまたはNACKを示す第1のビットと、チャネル品質を示す第2のビットとを備える、請求項10または11に記載の方法。
【請求項１３】
前記ACKまたは前記NACKを送信するステップが波形を送信するステップであって、前記波形が前記ACKまたは前記NACKおよびチャネル品質を示す、ステップを備える、請求項10から12のいずれか一項に記載の方法。
【請求項１４】
前記SCIのリソースの論理インデックスのマッピングに従って、前記ACK／NACKリソースを決定するステップをさらに備える、請求項10から13のいずれか一項に記載の方法。
【請求項１５】
前記方法が、前記データパケットが前記SCIに従ってブロードキャストされるかグループキャストされるかを判定するステップをさらに備え、
前記第1のモバイルデバイスにより、前記ACKを送信するか、または前記NACKを送信するように決定することに応答して、前記第2のモバイルデバイスに、前記ACK／NACKリソース上で前記ACKまたは前記NACKを送信するステップが、前記データパケットがグループキャストされると判定すると、前記ACKまたは前記NACKを送信するステップを備える、
請求項10から14のいずれか一項に記載の方法。
【請求項１６】
前記ACKまたは前記NACKを送信するステップが、前記スケジューリング情報に従って物理サイドリンクハイブリッド自動再送要求（HARQ）インジケータチャネル（PSHICH）上で前記ACKまたは前記NACKを送信するステップを備える、請求項10から15のいずれか一項に記載の方法。
【請求項１７】
前記ACKまたは前記NACKを送信するステップが、前記第1のモバイルデバイスのグループメンバ識別子（ID）に関連付けられた符号分割多元接続（CDMA）コードを使用して、前記ACKまたは前記NACKを送信するステップを備える、請求項10から16のいずれか一項に記載の方法。
【請求項１８】
前記ACKまたは前記NACKが、前記第1のモバイルデバイスを識別するカバーコードを使用するリソース上で送信される、請求項10から17のいずれか一項に記載の方法。
【請求項１９】
前記第1のモバイルデバイスが、前記第2のモバイルデバイスから受信された前記SCIの電力レベルまたは前記第2のモバイルデバイスから受信された前記データパケットの電力レベルに従って、オープンループ電力制御を使用して前記ACKまたは前記NACKを送信する、請求項10から18のいずれか一項に記載の方法。
【請求項２０】
前記第1のモバイルデバイスにより、第3のモバイルデバイスから第2のデータパケットを受信するステップと、
前記データパケットの優先度レベル、前記データパケットの電力レベル、または前記データパケットに対する待ち時間要件に従って、前記第2のデータパケットに対応する第2のACKまたはNACKを送信する前に、前記ACKまたは前記NACKを送信するように決定するステップと
をさらに備える、請求項10から19のいずれか一項に記載の方法。
【請求項２１】
装置であって、前記装置は、請求項1から20のいずれか一項に記載の方法を実施するように構成されている、装置。
【請求項２２】
少なくとも1つの命令を備えるコンピュータ可読媒体であって、前記少なくとも1つの命令が実行されると、請求項1から20のいずれか一項に記載の方法を実行させる、コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、参照により本明細書に組み込まれる、2017年8月10日に出願された「SYSTEM AND METHOD FOR SIDELINK FEEDBACK」と題する米国仮出願第62／543，744号、および2018年8月9日に出願された「SYSTEM AND METHOD FOR SIDELINK FEEDBACK」と題する米国出願第16／059，998号の利益を主張する。
【０００２】
本開示は、一般に、ワイヤレス通信に関し、特定の実施形態では、サイドリンクフィードバックのためのシステムおよび方法に関する。
【背景技術】
【０００３】
ワイヤレス通信ネットワークにおけるモバイルデバイスは、様々な方法で互いに通信する。たとえば、モバイルデバイスは、1つまたは複数の基地局などの、ネットワーク内に位置する1つまたは複数の構成要素を介して互いに通信することができる。追加または代替として、モバイルデバイスは互いに直接通信することができる。今日使用されている1つのワイヤレス通信規格は、モバイルデバイスがそれによって通信する複数のメカニズムを提供する、第3世代パートナーシッププロジェクト（3GPP）のLong−Term Evolution（LTE）規格である。たとえば、LTEでは、モバイルデバイスは、ダウンリンクインターフェースを介して基地局からデータを受信することができる。別の例として、LTEでは、モバイルデバイスは、アップリンクインターフェースを介して基地局に（たとえば、1つまたは複数の他のモバイルデバイスが受信することが可能な）データを通信することができる。別の例として、LTEでは、モバイルデバイスは、サイドリンクインターフェースを介して1つまたは複数の他のモバイルデバイスと直接通信することができる。
【発明の概要】
【課題を解決するための手段】
【０００４】
特定の実施形態では、方法は、第1のモバイルデバイスにより、データパケットを取得するステップと、リソースの第1のセットから、データパケットに関連付けられたスケジューリング情報を送信するための制御リソースを決定するステップとを含む。制御リソースは物理サイドリンク制御チャネル（PSCCH）を含む。方法は、第1のモバイルデバイスにより、リソースの第2のセットから、データパケットに関連付けられ、制御リソースに関連する肯定応答（ACK）／否定応答（NACK）リソースを決定するステップを含む。スケジューリング情報は、データパケットを送信するための送信情報およびACK／NACKリソースの指示を含む。方法は、第1のモバイルデバイスにより、第2のモバイルデバイスに、制御リソース上でスケジューリング情報を送信し、送信情報によって示されたリソースのセット上でデータパケットを送信するステップと、第1のモバイルデバイスにより、ACK／NACKリソース上で第2のモバイルデバイスによって送信されたACK／NACKをリッスンするステップとを含む。
【０００５】
特定の実施形態では、第1のモバイルデバイスは車両ユーザ機器（UE）である。
【０００６】
特定の実施形態では、第1のモバイルデバイスにより、第2のモバイルデバイスに、制御チャネル上でスケジューリング情報を送信するステップは、第1のモバイルデバイスにより、PSCCH上でデータパケットに関連付けられたスケジューリング情報をブロードキャストするステップを備え、スケジューリング情報はサイドリンク制御情報（SCI）としてブロードキャストされる。
【０００７】
特定の実施形態では、送信情報によって示されたリソースのセット上でデータパケットを送信するステップは、第2のモバイルデバイスを備えるモバイルデバイスのグループにデータパケットをグループキャストするステップを含む。
【０００８】
特定の実施形態は、ACK／NACKリソース上で受信されたACK／NACKの数をカウントするステップと、受信されたACK／NACKの数およびモバイルデバイスのグループ内のモバイルデバイスの数に少なくとも部分的に基づいて、データパケットを再送信するステップとを含む。
【０００９】
特定の実施形態は、第1のモバイルデバイスにより、第2のモバイルデバイスから、ACK／NACKリソース上でACKまたはNACKを受信するステップと、ACKまたはNACKに従ってグループメンバ識別子（ID）を決定するステップと、グループメンバIDおよびグループメンバIDリストを調査することに少なくとも部分的に基づいて、グループメンバIDリストにグループメンバIDを追加するステップとを含む。特定の実施形態は、グループメンバIDがグループメンバIDリスト上にあると判断することに応答して、グループメンバIDに対応するカウンタをリセットするステップと、グループメンバIDリスト上の第2のグループメンバIDに対応する第2のカウンタをデクリメントするステップと、第2のカウンタがゼロに達したことに応答して、グループメンバIDリストから第2のグループメンバIDを削除するステップとを含む。
【００１０】
特定の実施形態では、スケジューリング情報（たとえば、SCIメッセージ）は、第1のモバイルデバイスが第2のモバイルデバイスによって送信されるACKまたはNACKなどの確認応答を予想するというインジケータを含む。
【００１１】
特定の実施形態では、リソースの第2のセットはACK／NACKプールを備え、データパケットを送信するための送信情報によって示されたリソースのセットは、物理サイドリンク共有チャネル（PSSCH）を備え、第1のモバイルデバイスにより、リソースの第2のセットから、データパケットに関連付けられたACK／NACKリソースを決定するステップは、PSCCHの位置に従ってACK／NACKプールからACK／NACKリソースを選択するステップを含む。
【００１２】
特定の実施形態は、第1のモバイルデバイスにより、eノードB（eNB）から、ACK／NACKプールなどのリソースの第2のセットを示すダウンリンク制御インジケータ（DCI）を受信するステップを含む。
【００１３】
特定の実施形態では、データパケットを送信するための送信情報はデータパケットを再送信するための再送信情報であり、第1のモバイルデバイスにより、第2のモバイルデバイスに、送信情報によって示されたリソースのセット上でデータパケットを送信するステップは、再送信情報によって示されたリソースのセット上でデータパケットを再送信するステップを含む。
【００１４】
特定の実施形態は、ACK／NACKリソース上で第2のモバイルデバイスによって送信されたACK／NACKを受信するステップを含み、ACK／NACKはACKであり、ACKは第2のモバイルデバイスによるデータパケットの受信を示す。
【００１５】
特定の実施形態では、ACK／NACKリソースは、復調基準信号（DMRS）に隣接するか、またはそうでない場合それと関連付けられる。
【００１６】
特定の実施形態では、ACK／NACKリソースは、第2のモバイルデバイスによって使用される制御チャネルおよびデータチャネルと周波数分割多重化（FDM）される。
【００１７】
特定の実施形態では、ACK／NACKリソースは、制御チャネルと同じ周波数リソース上の制御チャネル上で時分割多重化（TDM）される。
【００１８】
特定の実施形態では、ACK／NACKリソースは、制御チャネルおよびデータチャネルとTDMされる。
【００１９】
特定の実施形態では、ACK／NACKリソースは、制御チャネルとデータチャネルとの間の周波数サブチャネル上にある。
【００２０】
特定の実施形態では、方法は、第1のモバイルデバイスにより、第2のモバイルデバイスから、制御リソース上でデータパケットに関連付けられたスケジューリング情報を受信するステップを含む。制御リソースはPSCCHを含む。スケジューリング情報は、第2のモバイルデバイスによってデータパケットを送信するための送信情報を含み、データパケットに関連付けられたACK／NACKリソースの指示を含む。スケジューリング情報はSCIを含む。方法は、第1のモバイルデバイスにより、第2のモバイルデバイスから、送信情報によって示されたリソース上でデータパケットを受信するステップを含む。方法は、第1のモバイルデバイスにより、ACKを送信するか、またはNACKを送信するように決定することに応答して、第2のモバイルデバイスに、ACK／NACKリソース上でACKまたはNACKを送信するステップを含む。
【００２１】
特定の実施形態では、第1のモバイルデバイスは車両ユーザ機器（UE）である。
【００２２】
特定の実施形態は、SCIの位置に従ってACK／NACKリソースを決定するステップを含む。
【００２３】
特定の実施形態では、ACKまたはNACKはインジケータの一部であり、インジケータは、ACKまたはNACKを示す第1のビットと、チャネル品質を示す第2のビットとを含む。
【００２４】
特定の実施形態では、ACKまたはNACKを送信するステップは波形を送信するステップを含み、波形はACKまたはNACKおよびチャネル品質を示す。
【００２５】
特定の実施形態は、SCIのリソースの論理インデックスのマッピングに従って、ACK／NACKリソースを決定するステップを含む。
【００２６】
特定の実施形態では、ACK／NACKリソース上でACKまたはNACKを送信するステップは、ACK／NACKリソース上で擬似ランダムにACKまたはNACKを送信するステップを含む。
【００２７】
特定の実施形態では、方法は、データパケットがSCIに従ってブロードキャストされるかグループキャストされるかを判定するステップを含み、第1のモバイルデバイスにより、ACKを送信するか、またはNACKを送信するように決定することに応答して、第2のモバイルデバイスに、ACK／NACKリソース上でACKまたはNACKを送信するステップは、データパケットがグループキャストされると判定すると、ACKまたはNACKを送信するステップを含む。
【００２８】
特定の実施形態では、ACKまたはNACKを送信するステップは、スケジューリング情報に従って物理サイドリンクハイブリッド自動再送要求（HARQ）インジケータチャネル（PSHICH）上でACKまたはNACKを送信するステップを含む。
【００２９】
特定の実施形態では、ACKまたはNACKを送信するステップは、第1のモバイルデバイスのグループメンバIDに関連付けられた符号分割多元接続（CDMA）コードを使用して、ACKまたはNACKを送信するステップを含む。
【００３０】
特定の実施形態では、ACKまたはNACKは、第1のモバイルデバイスを識別するカバーコードを使用するリソース上で送信される。
【００３１】
特定の実施形態では、第1のモバイルデバイスは、第2のモバイルデバイスから受信されたSCIの電力レベルまたは第2のモバイルデバイスから受信されたデータパケットの電力レベルに従って、オープンループ電力制御を使用してACKまたはNACKを送信する。
【００３２】
特定の実施形態は、第1のモバイルデバイスにより、第3のモバイルデバイスから第2のデータパケットを受信するステップと、データパケットの優先度レベル、データパケットの電力レベル、またはデータパケットに対する待ち時間要件に従って、第2のデータパケットに対応する第2のACKまたはNACKを送信する前に、ACKまたはNACKを送信するように決定するステップとを含む。
【００３３】
特定の実施形態は、SCIからグループIDを抽出するステップと、グループIDがグループIDのリスト上にまだないと判断することに応答して、グループIDのリストにグループIDを追加するステップと、グループIDがグループIDのリスト上にあると判断することに応答して、グループIDに関連付けられたカウンタをリセットするステップと、グループIDのリスト上の第2のグループIDに関連付けられた第2のカウンタをデクリメントするステップと、第2のカウンタがゼロに達したことに応答して、グループIDのリストから第2のグループIDを削除するステップとを含む。
【００３４】
特定の実施形態は、SCIからグループメンバIDを抽出するステップと、グループメンバIDがグループメンバIDリスト上にないと判断することに応答して、グループIDに関連付けられたグループメンバIDのリストにグループメンバIDを追加するステップと、グループメンバIDがグループメンバIDのリスト上にあると判断することに応答して、グループメンバIDに関連付けられたカウンタをリセットするステップと、グループメンバIDリストからの第2のグループメンバIDに関連付けられた第2のカウンタをデクリメントするステップと、第2のカウンタがゼロに達したことに応答して、グループメンバIDリストから第2のグループメンバIDを削除するステップとを含む。
【００３５】
特定の実施形態では、モバイルデバイスは、1つまたは複数のプロセッサと、命令を記憶する非一時的メモリストレージとを含む。命令は、1つまたは複数のプロセッサによって実行されると、データパケットを取得することと、リソースの第1のセットから、データパケットに関連付けられたスケジューリング情報を送信するための制御リソースを決定することとを含む動作を、1つまたは複数のプロセッサに実行させるように構成される。制御リソースは物理サイドリンク制御チャネル（PSCCH）を含む。動作は、第1のモバイルデバイスにより、リソースの第2のセットから、データパケットに関連付けられ、制御リソースに関連する肯定応答（ACK）／否定応答（NACK）リソースを決定することをさらに含む。スケジューリング情報は、データパケットを送信するための送信情報およびACK／NACKリソースの指示を含む。動作は、PSCCH上でデータパケットに関連付けられたSCIを第2のモバイルデバイスに送信することをさらに含む。SCIは、データパケットに関連付けられたACK／NACKリソースを示す。動作は、第1のモバイルデバイスにより、第2のモバイルデバイスに、制御リソース上でスケジューリング情報を送信し、送信情報によって示されたリソースのセット上でデータパケットを送信することと、第1のモバイルデバイスにより、ACK／NACKリソース上で第2のモバイルデバイスによって送信されたACK／NACKをリッスンすることとをさらに含む。
【００３６】
上記は、以下の詳細な説明がよりよく理解され得るように、本開示の特定の実施形態の特徴を概説している。本開示の特許請求の範囲の主題を形成する、本開示の実施形態のさらなる特徴および利点が記載される。開示された概念および特定の実施形態は、本開示の同じ目的を実行するための他の構造またはプロセスを修正または設計するための基礎として容易に利用され得ることを当業者なら諒解されよう。また、そのような均等な構造物は、添付の特許請求の範囲に記載される本開示の趣旨および範囲から逸脱しないことも当業者なら認識されよう。
【００３７】
本開示およびその利点をより完全に理解するために、次に、添付図面と併用される以下の説明に対して参照が行われる。
【図面の簡単な説明】
【００３８】
【図１】本開示の特定の実施形態による、データを通信するための例示的なワイヤレスネットワークの図である。
【図２Ａ】本開示の特定の実施形態による、例示的な車両間（V2V）通信を示す図である。
【図２Ｂ】本開示の特定の実施形態による、例示的な車両間（V2V）通信を示す図である。
【図２Ｃ】本開示の特定の実施形態による、例示的な車両間（V2V）通信を示す図である。
【図３Ａ】本開示の特定の実施形態による、例示的な車両カバレージシナリオを示す図である。
【図３Ｂ】本開示の特定の実施形態による、例示的な車両カバレージシナリオを示す図である。
【図３Ｃ】本開示の特定の実施形態による、例示的な車両カバレージシナリオを示す図である。
【図４】本開示の特定の実施形態による、隊列走行の例を示す図である。
【図５】本開示の特定の実施形態による、例示的なロングタームエボリューション（LTE）のフレーム構造を示す図である。
【図６】本開示の特定の実施形態による、サイドリンク通信用の例示的な送信プールおよび受信プールを示す図である。
【図７】本開示の特定の実施形態による、ソースモバイルデバイスによって実行され、ソースモバイルデバイスが確認応答を予想する、サイドリンク上でパケットを送信する例示的な方法のフローチャートである。
【図８】本開示の特定の実施形態による、モバイルデバイス間の通信についての例示的なメッセージ図である。
【図９】本開示の特定の実施形態による、ソースモバイルデバイスによって実行される肯定応答（ACK）／否定応答（NACK）手順のための例示的な方法のフローチャートである。
【図１０】本開示の特定の実施形態による、ソースモバイルデバイスによって実行される、ACK／NACKを監視するための例示的な方法用のフローチャートである。
【図１１Ａ】本開示の特定の実施形態による、例示的な車両グループキャストシナリオを示す図である。
【図１１Ｂ】本開示の特定の実施形態による、例示的な車両グループキャストシナリオを示す図である。
【図１２Ａ】本開示の特定の実施形態による、シングルキャリア周波数分割多元接続（SC−FDMA）との例示的な車両連携を示す図である。
【図１２Ｂ】本開示の特定の実施形態による、シングルキャリア周波数分割多元接続（SC−FDMA）との例示的な車両連携を示す図である。
【図１３Ａ】本開示の特定の実施形態による、制御およびデータを多重化するための例示的なフレーム構造を示す図である。
【図１３Ｂ】本開示の特定の実施形態による、制御およびデータを多重化するための例示的なフレーム構造を示す図である。
【図１４】本開示の特定の実施形態による、デバイス間（D2D）通信用のフレームの例示的なシーケンスおよびV2V通信用のフレームの例示的なシーケンスを示す図である。
【図１５】本開示の特定の実施形態による、新無線（NR）におけるフレームの例示的なシーケンスを示す図である。
【図１６】本開示の特定の実施形態による、ACK／NACKが復調基準信号（DMRS）の周囲に配置される例示的なフレーム構造を示す図である。
【図１７Ａ】本開示の特定の実施形態による、周波数領域内のACK／NACKプールの多重化の例を示す図である。
【図１７Ｂ】本開示の特定の実施形態による、周波数領域内のACK／NACKプールの多重化の例を示す図である。
【図１８Ａ】本開示の特定の実施形態による、例示的なACK／NACKプールを示す図である。
【図１８Ｂ】本開示の特定の実施形態による、例示的なACK／NACKプールを示す図である。
【図１９】本開示の特定の実施形態による、例示的なフレーム構造を示す図である。
【図２０】本開示の特定の実施形態による、宛先モバイルデバイスによって実行されるACK／NACK送信の例示的な方法のフローチャートである。
【図２１】本開示の特定の実施形態による、宛先モバイルデバイスによって実行される、ACK／NACKを送信するかどうかを判定する例示的な方法のフローチャートである。
【図２２】本開示の特定の実施形態による、ソースモバイルデバイスによって実行される、ACK／NACKに反応する例示的な方法のフローチャートである。
【図２３】本開示の特定の実施形態による、例示的なフレーム多重化構造を示す図である。
【図２４】本開示の特定の実施形態による、例示的な処理システムのブロック図である。
【図２５】本開示の特定の実施形態による、例示的なトランシーバのブロック図である。
【発明を実施するための形態】
【００３９】
異なる図の中の対応する数字およびシンボルは、特に明記しない限り、一般に対応する部分を指す。図は、実施形態の関連する態様を明確に示すために描かれており、必ずしも縮尺通りに描かれていない。
【００４０】
1つまたは複数の実施形態の例示的な実装形態が以下に提供されるが、開示されるシステムおよび／または方法は、現在知られているか否かにかかわらず、任意の数の技法を使用して実装されてよいことが最初に理解されるべきである。本開示は、本明細書において図示または記載される例示的な設計および実装形態を含む、以下に示される例示的な実装形態、図面、および技法に決して限定されるべきでなく、それらの均等物の全範囲とともに添付特許請求の範囲の範囲内で修正されてよい。
【００４１】
ユーザ機器（UE）、車両（たとえば、車両UE）、または他のタイプのモバイルデバイスなどのモバイルデバイスが、様々な状況で互いに直接通信することが望ましい場合がある。たとえば、モバイルデバイスが非車両UEである場合、デバイス間の直接通信は、デバイス間（D2D）通信と呼ばれる場合がある。別の例として、モバイルデバイスのうちの少なくとも1つが車両である場合、車両と他のデバイス（たとえば、別の車両、非車両UE、基盤、歩行者、グリッド）との間の直接通信は、車両対すべて（V2X）通信と呼ばれる場合がある。両方のモバイルデバイスが車両である例では、直接通信は車両間（V2V）通信と呼ばれることがある。V2Xは、モバイルデバイスのうちの少なくとも1つが車両であるD2D通信のサブセットと見なされてよい。LTE規格に従って通信をサポートするモバイルデバイスの場合、モバイルデバイスはサイドリンクインターフェースを使用して互いに直接通信することができる。
【００４２】
1つの具体例の使用ケースでは、V2V通信は複数の車両の小隊において使用されてよく、そこでは、1つまたは複数の後続車両が、先行車両の挙動を模倣することにより、先行車両から十分に安全な距離を維持しようと試みる。たとえば、先行車両が加速していると、後続車両も加速する。隊列走行が車両間の通信なしに動作することは可能かもしれないが、車両間の通信を介して提供される追加情報は、センサ（たとえば、レーダー、近接センサ、または他のタイプのセンサ）からの情報を増強して、動作のより高い密度および改善を可能にすることができる。
【００４３】
D2D通信およびV2V通信では、モバイルデバイスからの通信は、基地局（たとえば、E−UTRANノードB、もしくはeNB）または他のタイプのネットワーク側機器を介して送信されることなく、1つのUEから1つまたは複数の他のUEに移動するサイドリンク上のメッセージを含んでよいが、サイドリンク通信を含むいくつかのシナリオでは、基地局または他のネットワーク側機器が関与する場合があることに留意されたい。D2DおよびV2Vにおけるメッセージは、物理サイドリンク発見チャネル（PSDCH）、物理サイドリンク共有チャネル（PSSCH）、物理サイドリンク制御チャネル（PSCCH）、物理サイドリンクブロードキャストチャネル（PSBC）、および1次サイドリンク同期信号（PSSS）または2次サイドリンク同期信号（SSSS）などの他のシグナリング上で送信されてよい。いくつかのシナリオでは、サイドリンクはアップリンクリソースを使用することができる。
【００４４】
LTEのD2DおよびV2Vでは、物理層におけるサイドリンク上の送信は、潜在的な受信者のモバイルデバイスの位置を事前に知ることなく、ソースモバイルデバイスによるメッセージのブロードキャストを介して行われる。物理層においてサイドリンク上でメッセージをブロードキャストするソースモバイルデバイスに加えて、またはその代替として、本開示の実施形態は、物理層においてユニキャスト通信またはグループキャスト通信を使用することを実現し、それにより、サイドリンク通信が改善されてよい。本開示の実施形態は、基地局（たとえば、eNB）などの集中型コントローラを巻き込むことなく、サイドリンク送信においてフィードバックを実現するためのメカニズムを導入する。特定の実施形態では、（たとえば、D2D通信およびV2V通信による）サイドリンク送信との関連でフィードバックを実現できると、送信の信頼性が改善されてよい。さらに、特定の実施形態は、集中型コントローラとモバイルデバイスとの間のアップリンク送信およびダウンリンク送信に依存しないフィードバックを可能にし、それにより、アップリンクリソースおよびダウンリンクリソース、ならびにコントローラ処理リソースが、他の需要で使用するために解放されてよい。
【００４５】
特定の実施形態では、方法は、第1のモバイルデバイス（たとえば、ソースモバイルデバイス）により、データパケットを取得するステップと、リソースの第1のセットから、データパケットに関連付けられたスケジューリング情報を送信するための制御リソースを決定するステップとを含む。制御リソースは物理サイドリンク制御チャネル（PSCCH）を含む。方法は、第1のモバイルデバイスにより、リソースの第2のセットから、データパケットに関連付けられ、制御リソースに関連する肯定応答（ACK）／否定応答（NACK）リソースを決定するステップを含む。スケジューリング情報は、データパケットを送信するための送信情報およびACK／NACKリソースの指示を含む。方法は、第1のモバイルデバイスにより、第2のモバイルデバイス（たとえば、宛先モバイルデバイス）に、制御リソース上でスケジューリング情報を送信し、送信情報によって示されたリソースのセット上でデータパケットを送信するステップを含む。特定の実施形態では、制御リソース上でのスケジューリング情報の第1のモバイルデバイスによる送信は、ブロードキャスト送信である。特定の実施形態では、スケジューリング情報は、サイドリンク制御情報（SCI）を含むか、またはサイドリンク制御情報（SCI）として通信されてよい。方法は、第1のモバイルデバイスにより、ACK／NACKリソース上で第2のモバイルデバイスによって送信されたACK／NACKをリッスンするステップを含む。第2のモバイルデバイスによって第1のモバイルデバイスに通信されるACKまたはNACKは、ACK／NACKリソースを使用して第2のモバイルデバイスから第1のモバイルデバイスに向けられる通信であってよい。特定の実施形態では、ACK／NACKリソースをスケジュールすることにより、衝突が低減または除去されてよい。
【００４６】
特定の実施形態では、方法は、第1のモバイルデバイス（たとえば、宛先モバイルデバイス）により、第2のモバイルデバイス（たとえば、ソースモバイルデバイス）から、制御リソース上でデータパケットに関連付けられたスケジューリング情報を受信するステップを含む。制御リソースはPSCCHを含んでよい。スケジューリング情報は、第2のモバイルデバイスによってデータパケットを送信するための送信情報を含み、データパケットに関連付けられたACK／NACKリソースの指示を含む。スケジューリング情報はSCIを含む。特定の実施形態では、制御リソース上で第1のモバイルデバイスによって受信されるスケジューリング情報は、第2のモバイルデバイスからのブロードキャスト送信である。方法は、第1のモバイルデバイスにより、第2のモバイルデバイスから、送信情報によって示されたリソース上でデータパケットを受信するステップを含む。たとえば、第1のモバイルデバイスは、送信情報によって示された物理サイドリンク共有チャネル（PSSCH）上でデータパケットを受信することができる。方法は、第1のモバイルデバイスにより、ACKを送信するか、またはNACKを送信するように決定することに応答して、第2のモバイルデバイスに、ACK／NACKリソース上でACKまたはNACKを送信するステップを含む。第1のモバイルデバイスによって第2のモバイルデバイスに通信されるACKまたはNACKは、ACK／NACKリソースを使用して第2のモバイルデバイスから第1のモバイルデバイスに向けられる通信であってよい。
【００４７】
この説明は主にモバイルデバイスが車両UEである（かつD2D通信がV2V通信である）実施形態に焦点を当てているが、本説明は、特定の実施形態の説明において指定されているかどうかにかかわらず、D2D、V2V、V2E、および他の適切なデバイスの組合せに等しく適用可能である記載された技法を想定している。さらに、モバイルとして記載されているが、本開示は、モバイルデバイスが、サイドリンク通信が可能な任意の適切なタイプのデバイスであることを想定している。
【００４８】
図1は、本開示の特定の実施形態による、データを通信するための例示的なワイヤレスネットワーク100の図を示す。ネットワーク100は、カバレージエリア106を有する基地局102と、モバイルデバイス104およびモバイルデバイス105を含む複数のモバイルデバイスと、バックホールネットワーク108とを含む。この実施形態では、2つのモバイルデバイスが描写されているが、さらに多くのモバイルデバイスが存在してもよい。基地局102は、モバイルデバイス104および／または105から基地局102にデータを搬送し、その逆も行うように働く、モバイルデバイス104および／またはモバイルデバイス105とのアップリンク接続および／またはダウンリンク接続を確立することにより、ワイヤレスアクセスを提供することが可能な任意の構成要素であってよい。アップリンク／ダウンリンク接続を介して搬送されるデータは、モバイルデバイス104とモバイルデバイス105との間で通信されるデータ、ならびにバックホールネットワーク108を経由してリモートエンドと通信されるデータを含む。モバイルデバイス104とモバイルデバイス105との間のサイドリンク接続も示されている。上述されたように、サイドリンク接続は、モバイルデバイス104および105が互いに直接通信するための機能を提供する。
【００４９】
この説明の目的で、基地局という用語は、ノードB、発展型ノードB（eNB）、gNB、アクセスポイント、ピコセル、フェムトセル、マクロセル、Wi−Fiアクセスポイント（AP）、リレーノード、および他のワイヤレス対応デバイスなどの、ネットワークへのワイヤレスアクセスを実現するように構成された任意の構成要素（または構成要素の集合）を指す。基地局は、1つまたは複数のワイヤレス通信プロトコル、たとえば、ロングタームエボリューション（LTE）、LTEアドバンスト（LTE−A）、高速パケットアクセス（HSPA）、新無線（NR）、Wi−Fi 802．11a／b／g／n／acなどによるワイヤレスアクセスを提供することができる。
【００５０】
モバイルデバイス104およびモバイルデバイス105は、ユーザ機器（UE）、移動局（STA）、携帯電話、スマートフォン、タブレット、センサ、車両、および他のワイヤレス対応デバイスなどの、基地局102とのワイヤレス接続を確立することが可能な任意の構成要素（または構成要素の集合）であってよい。UEという用語は、上記に列挙されたデバイスのタイプのうちの1つまたは複数（たとえば、車両UE）を含んでよいことを理解されたい。いくつかの実施形態では、ネットワーク100は、リレー、低電力ノード、および他のタイプのワイヤレスデバイスなどの、様々な他のワイヤレスデバイスを含んでよい。
【００５１】
図2A〜図2Cは、本開示の特定の実施形態による、例示的なV2V通信を示す。図2Aでは、車両112は、データパケットをブロードキャストすることにより、車両114および車両116とのサイドリンク通信を試みる。車両114は車両112の範囲内にあり、車両114によってブロードキャストされたデータパケットを受信する。しかしながら、車両116は車両112の範囲外にあり、車両116は車両112によってブロードキャストされたデータパケットを受信しない。
【００５２】
図2Bでは、車両112はネットワークブロードキャストを実行する。詳細には、車両112は、路側ユニット（RSU）122にアップリンクでデータパケットを送信する。次いで、RSU122は、車両114および車両116にダウンリンクでデータパケットを転送またはブロードキャストする。RSU122は、ブロードキャストメッセージ内のいくつかのアップリンク送信を結合または連結することができる。したがって、RSU122は、サイドリンクで利用可能な範囲を超えてV2Vカバレージを拡張する。
【００５３】
図2Cは、直接V2V通信とネットワークブロードキャストの両方を示す。車両112はデータパケットをブロードキャストし、データパケットは車両112の範囲内にある車両124によって受信される。車両114および車両116は車両112の範囲内になく、車両112によってブロードキャストされたデータパケットを受信しない。しかしながら、車両112はまた、転送のためにアップリンクでRSU122にデータパケットを送信する。次いで、RSU122は、車両112から受信されたデータパケットをブロードキャストする。車両114はRSU122の範囲内にあり、RSU122によってブロードキャストされたデータパケットを受信する。一方、車両116はRSU122の範囲内になく、車両116はRSU122によってブロードキャストされたデータパケットを受信しない。しかしながら、車両114はまた、RSU122から受信されたデータパケットを転送またはブロードキャストする。車両116は車両114の範囲内にあり、車両116は車両114によってブロードキャストされたデータパケットを受信する。
【００５４】
図3A〜図3Cは、本開示の特定の実施形態による、例示的な車両カバレージシナリオを示す。図3Aでは、車両246、248、および250のいずれも、基地局242（たとえば、eNB）のカバレージエリア244内にない。図3Bでは、車両246、248、および250のすべてが基地局242のカバレージエリア244内にある。図3Cでは、車両248および250は基地局242のカバレージエリア244内にあり、車両246は基地局242のカバレージエリア244外にある。
【００５５】
D2D通信、V2X通信、およびV2V通信は、LTEとNRの両方の下で将来拡張されることが予想される。隊列走行および自動合流などの車両サービスは、自律走行車への移行を容易にするために開発されている。隊列走行では、1つまたは複数の後続車両は、先行車両の挙動を模倣することにより、先行車両から許容可能な距離を維持しようと試みる。隊列走行は車両間の通信なしに動作することができるが、追加情報の送信により、燃料節約および車両密度の増加などの利点が与えられてよい。
【００５６】
後続車が先頭車両または先行車両の後に続く隊列走行は、V2V通信なしに実現されてよい。たとえば、適応走行制御（ACC）では、後続車両上のセンサは先行車両の動態を監視し、走行制御モジュールに入力を提供するので、後続車両は先行車両を追跡することができる。しかしながら、V2V通信は、単独でもセンサ入力と組み合わされても、利点を与えることができる。たとえば、先行車両からの通信は、速度、方向、位置、および加速度などの追加情報を提供することができるので、後続車両は後続車両の動作用の入力を生成することができる。追加または代替として、後続車両は、先行車両から受信された通信を介して提供された情報を、より良い追跡、たとえば、協調ACC（CACC）のための独自のセンサ情報で増強することができる。V2V通信が使用されると、メッセージレートおよび車両密度に対する特定の制限により、小隊内でのメッセージングに課題が提示される場合がある。本開示の特定の実施形態は、本開示でより詳細に記載されるように、これらの課題を低減または除去することができる。
【００５７】
図4は、本開示の特定の実施形態による、隊列走行の例を示す。車両212、214、および216は小隊210内にあり、車両212は小隊210の小隊長である。また、小隊220は、小隊長である車両222と、車両222の後を追っている車両224とを含む。車両202、204、および206は小隊に属していない。車両212、216、204、および206はブロードキャストしている。
【００５８】
一例では、車両214は、車両216および車両204からの同時送信によって引き起こされる干渉のために、車両212からの送信を受信することができない。車両206と車両214との間の距離は、車両206から送信される信号を著しく減衰させるので、車両206からの送信は、それほど干渉に寄与しない可能性がある。車両216も現在送信しているので、車両212からの送信を受信することができない。
【００５９】
小隊の調整により、車両のグループ内のメッセージングの信頼性が向上する場合がある。たとえば、車両がブロードキャストしているとき、小隊内の他の車両の送信を防止すると、小隊内のメッセージングの信頼性が向上する場合がある。一例では、車両212が送信している間に車両214および216が送信しないように防止することにより、小隊210内で車両212からの送信を受信する信頼性が2倍向上する。
【００６０】
図5は、本開示の特定の実施形態による、例示的なLTEフレーム構造を示す。このフレーム構造を理解すると、サイドリンク送信に関連する本開示の特定の態様の理解が容易になり得る。LTEなどのワイヤレス通信システムでは、無線フレームは情報をワイヤレスで送信するためのデジタル送信単位である。一例では、フレームは10ミリ秒（ms）であり、10msフレームは10個の1msサブフレームを含んでいる。LTEでは、少なくとも2つのタイプのフレーム構造が定義されている。1つ目はタイプ1のフレーム構造と呼ばれ、LTE周波数分割複信（FDD）モードシステムに使用される。2つ目はタイプ2のフレーム構造と呼ばれ、LTE時分割複信（TDD）モードシステムに使用される。FDDでは、ダウンリンク（DL）キャリアおよびアップリンク（UL）キャリアまたはサイドリンク（SL）キャリアが存在する。TDDでは、フレームは複数のサブフレームを含んでいる。
【００６１】
サイドリンク用のリソースはアップリンク用のリソースのサブセットである。たとえば、DLフレーム146およびUL／SLフレーム148は、10個の1msサブフレームを含む10msフレームである。eNBなどの基地局は、サイドリンク動作用のアップリンクサブフレームの数を構成することができる。サイドリンクサブフレームは、アップリンク動作とサイドリンク動作の両方に使用されてよい。
【００６２】
所与のキャリアの場合、サブフレームは、PRBペア144などのいくつかの物理リソースブロック（PRB）ペアを含む。図5は、ダウンリンク、アップリンク、およびサイドリンク用の同じ数のPRBペア144を示すが、ダウンリンク、アップリンク、およびサイドリンクには異なる数のPRBペアが存在してよい。LTEでは、15個のPRBペアが3MHz帯域幅に対応し、各PRBペアは15kHz間隔の12個のサブキャリアを含む。通常のサイクリックプレフィックスの場合、PRBペアは時間において14個のシンボルにまたがる。したがって、PRBペアには12＊14＝168個のリソース要素（RE）が存在する。
【００６３】
ダウンリンク上で、サブフレームは、物理ダウンリンク制御チャネル（PDCCH）152を送信するために使用される制御領域、および物理ダウンリンク共有チャネル（PDSCH）154を送信するために使用されるデータ領域、ならびに拡張PDCCH（EPDCCH）に分割されてよい。EPDCCHはPDCCHの任意の機能を提供することができる。PDCCHまたはEPDCCHはダウンリンク制御情報（DCI）を搬送する。
【００６４】
アップリンク上で、いくつかのPRBペアがサイドリンク動作向けに構成される。PSCCH162は、PSSCH160において送信されるデータペイロード用のSCIを使用して、スケジューリング情報を提供する。いくつかの実施形態では、PSCCHおよび対応するPSSCHは同じサブフレーム内で送信される。加えて、物理アップリンク共有チャネル（PUSCH）158は、UEからeNBなどの基地局にデータパケットを搬送する。また、物理アップリンク制御チャネル（PUCCH）164は、アップリンク制御情報（UCI）を搬送する。
【００６５】
LTEでは、物理層におけるサイドリンク上の送信はブロードキャストを介して行われ、それにより、送信の信頼性が制限される場合がある。本開示の特定の実施形態によって可能にされるように、物理層においてユニキャスト通信またはグループキャスト通信を使用すると、サイドリンク通信が改善され得る。加えて、サイドリンクにおいてハイブリッド自動再送要求（HARQ）を使用すると、送信が目的のターゲットに到達したかどうかに関するフィードバックを送信デバイスが受信し、そうでない場合に是正処置（たとえば、再送信）を取るためのメカニズムを提供することにより、サイドリンクにおける信頼性が向上する場合がある。一実施形態は、サイドリンクにおけるユニキャスト送信またはグループキャスト送信のためのHARQサポートを提供する。
【００６６】
第5世代（5G）とも呼ばれるNRでは、ダウンリンク上で直交周波数分割多重化（OFDM）が使用される。アップリンクは、シングルキャリア周波数分割多元接続（SC−FDMA）およびサイクリックプレフィックス（CP）−OFDMをサポートする。SC−FDMAは、サブキャリアを連続するように制限しながら、ピーク対平均電力比（PAPR）を低下させることにつながる可能性がある。CP−OFDMは連続するサブキャリア要件を緩和する。NRでは、ダウンリンク送信の場合、特定のスロット構成の下で、確認応答用のアップリンクリソースがダウンリンク共有チャネルの送信のすぐ後に続く。同様のスロット構造がサイドリンクに使用されてよい。
【００６７】
LTEでは、基地局（たとえば、eNB）からUEへのPDSCHのユニキャスト送信の場合、PDSCHはアップリンクリソース上で特定の時間後にUEによって確認される。たとえば、FDDでは、ダウンリンク上で、基地局（たとえば、eNB）は、サブフレームn内の制御チャネル要素（CCE）上に位置するPDCCH上でDCIを送信する。DCIは対応するPDSCH送信用のリソースを示す。PDSCH送信もサブフレームn上で行われてよい。サブフレームn＋4上で、UEはPDSCH送信に対するACK／NACKを送信する。ACK／NACKはUCIメッセージ内で伝達される。UCIは、PUCCH上で送信されるか、またはPUSCH用のリソースをパンクチャすることによって送信されてよい。PUCCHが使用されるとき、UEは、PDSCHに関連付けられたPDCCHの最も低いCCEインデックスの機能であるリソース上のPUCCH上、および基地局（たとえば、eNB）によって構成されたリソース、たとえば、アップリンク上の最小番号および最大番号のPRB上でUCIを送信する。TDDでは、ACK／NACKは時間n＋kに送信され、ここで、k≧4はアップリンク−ダウンリンク構成、およびPDSCHが受信されたサブフレーム番号に従って決定される。
【００６８】
アップリンク共有チャネル送信の場合、UEはサブフレームn内でPDCCHを受信する。FDDでは、UEはサブフレームn＋4上でPUSCHを送信する。次いで、基地局（たとえば、eNB）は、サブフレームn＋8上の物理HARQインジケータチャネル（PHICH）内でACK／NACKを送信することができる。PHICHは、いくつかの受信されたPUSCHに対するACK／NACKを伝達することができる。
【００６９】
図6は、本開示の特定の実施形態による、サイドリンク通信用の例示的な送信プールおよび受信プールを示す。詳細には、図6は、例示的なサイドリンク通信用の送信プール（Tx）プール172およびサイドリンク通信用の受信プール（RX）プール174を示す。
【００７０】
基地局（たとえば、eNB）は、どのULサブフレームおよび特定のULサブフレーム上のどのPRBペアが、サイドリンクTxプール172上の送信機会のために構成され得るかを示すことができる。基地局（たとえば、eNB）は、どのULサブフレームおよび特定のサブフレーム上のどのPRBペアが、サイドリンクRxプール174上の送信（受信）を監視するために構成され得るかを示すことができる。図示された例では、Txプール172は、サブフレーム2上のPRBペア3〜13、サブフレーム7上のPRBペア0〜9、および次のフレームのサブフレーム2であるサブフレーム12上のPRBペア0〜14のために構成される。加えて、Rxプール174は、サブフレーム2上のPRBペア0〜14、サブフレーム7上のPRBペア5〜14、サブフレーム12上のPRBペア0〜9、およびサブフレーム14（次のフレームのサブフレーム4）上のPRBペア0〜14のために構成される。図示されたように、Txプール172は、Rxプール174とは異なっていても、ばらばらであってもよい。いくつかの実施形態では、TxプールはRxプールと重複する。他の実施形態では、TxプールはRxプールと同じであってよい。いくつかの実施形態では、TxプールおよびRxプールは周波数が連続していない。
【００７１】
特定の実施形態によれば、ネットワークモード（D2D用のサイドリンク送信モード1）では、2ステッププロセスにより、UE（たとえば、ソースモバイルデバイス）がサイドリンク上でデータを送信することが可能になってよい。最初に、基地局（たとえば、eNB）は、特定のUE（たとえば、ソースモバイルデバイス）向けにPDCCH上でDCIを送信し、UE（たとえば、ソースモバイルデバイス）は、16ビット無線ネットワーク一時識別子（RNTI）を割り当てられる。一例として、特定の規格によれば、DCIフォーマット5はD2D用のサイドリンク通信をスケジュールするために使用される。たとえば、「3GPP TS36．212 V12．4．0、セクション5．4．3および5．3．3．1（2015−03）」、「第3世代パートナーシッププロジェクト、技術仕様グループ無線アクセスネットワーク、発展型ユニバーサル地上波無線アクセス（E−UTRA）、多重化およびチャネルコーディング（リリース12）」、ならびに「3GPP TS36．213 V12．11．0、セクション14．1および14．2（2016−09）」、「第3世代パートナーシッププロジェクト、技術仕様グループ無線アクセスネットワーク、発展型ユニバーサル地上波無線アクセス（E−UTRA）、物理層手順（リリース12）」を参照されたい。PDCCHを受信することに応答して、ソースモバイルデバイスは、PSCCHを使用してSCIまたはスケジューリング割当て（SA）を送信する。SCI内で伝達されるフィールドは、共有チャネル（PSSCH）、変調／コーディング方式（MCS）、優先度、送信／再送信番号、および宛先識別子（ID）のためのリソース位置の任意の適切な組合せを含んでよい。
【００７２】
後のサブフレームでは、ソースモバイルデバイスは、サイドリンク上でPSSCHを使用してデータを送信する。ソースモバイルデバイスが、DCIフォーマット5などのサイドリンクディレクティブを含むPDCCHを受信するときのサブフレームと、PSCCHの送信との間にタイミング関係が存在する。
FDDの場合、サイドリンク上で、PDCCHを受信した後に少なくとも4つのサブフレームにおいてPSCCHが送信される。
ソースモバイルデバイスがPSSCH上でデータを送信する前に、ソースモバイルデバイスはPSCCH上でSCIを送信し、SCIはPSSCH用のスケジューリング情報を含む。
いくつかの実施形態では、DCIフォーマット5のいくつかのフィールドは、ソースモバイルデバイスによってSCIフォーマット0にコピーされる。特定の実施形態では、基地局（たとえば、eNB）は、ソースモバイルデバイスがPSCCH上で送信するデータペイロードまたはコンテンツの知識をもたない。
【００７３】
宛先モバイルデバイスの場合、サイドリンクキャリアは、事前に決められた時間に、周波数リソースのセット（たとえば、プール）上でPSCCHについて監視される。PSCCHが検出されると、宛先モバイルデバイスはSCIを処理して、対応するPSSCH用のリソースの位置を特定する。次いで、宛先モバイルデバイスは、受信されたPSSCHからデータパケットを取得しようと試みる。
【００７４】
この手順は1つまたは複数の欠点をもつ可能性がある。たとえば、特定の宛先モバイルデバイスにユニキャストされるか、または宛先モバイルデバイスのグループにグループキャスト／マルチキャストされるのではなく、データパケットはブロードキャストされ、ユニキャストはグループキャストの特殊なケースである。したがって、データパケットがブロードキャストされることに起因して、宛先モバイルデバイスがブロードキャストメッセージに応答してACKまたはNACKを送信することを控えるので、ソースモバイルデバイスは、宛先モバイルデバイスがデータパケットを正しく受信したかどうかを示すACK／NACKを受信しない。
【００７５】
別の例として、モバイルデバイスはある時間期間（たとえば、いくつかのサブフレーム）の間、サイドリンクキャリア上で送信または受信する可能性があるので、モバイルデバイスは同時に送信および受信していない。したがって、宛先モバイルデバイスは、ソースモバイルデバイスが送信している間に送信している可能性があり、それにより、宛先モバイルデバイスがソースモバイルデバイスからの送信を受信しないようになる可能性がある。同様に、ソースモバイルデバイスは、宛先モバイルデバイスからの送信を受信できない可能性がある。
【００７６】
別の例として、メッセージングレートが増大すると、データパケットを受信する信頼性が低下する可能性がある。モバイルデバイスの密度が高い（たとえば、エリア内のUEの数が多い）ほど、同時に多くのモバイルデバイスが送信されるため、干渉の量が増加する。多くのモバイルデバイスが送信を試みているときに送信する機会を見つけることは、チャネルの検知測定に基づくブロッキングのために問題になる可能性がある。干渉を管理するために、モバイルデバイス送信のタイミングの調整が使用されてよい。
【００７７】
D2D通信モードでは、UEはサブフレームn内でDCIを受信する。次いで、UEはサブフレームn＋l’内でSCIを送信し、ここで、l’はPSCCH用に構成された最初の利用可能なサブフレームであり、サブフレームnの後のl’≧4である。PSCCHの2つの送信が存在する。次に、UEはサブフレームn＋l’＋l”内でPSSCHを送信し、ここで、l”はサブフレームn＋l’およびl”≧4の後にPSCCH用に構成された最初の利用可能なサブフレームである。PSSCHの再送信は、基地局（たとえば、eNB）によって示されたサブフレーム内で行われる。
【００７８】
V2Vのネットワークモード（サイドリンク送信モード3またはスケジュールされたリソース割当て）では、特定の規格に従って、V2X用のサイドリンク通信をスケジュールするためにDCIフォーマット5Aが使用される。たとえば、「3GPP TS36．212 V14．4．0、セクション5．4．3および5．3．3．1（2017−09）」、「第3世代パートナーシッププロジェクト、技術仕様グループ無線アクセスネットワーク、発展型ユニバーサル地上波無線アクセス（E−UTRA）、多重化およびチャネルコーディング（リリース14）」、ならびに「3GPP TS36．213 V14．7．0、セクション14．1および14．2（2018−06）」、「第3世代パートナーシッププロジェクト、技術仕様グループ無線アクセスネットワーク、発展型ユニバーサル地上波無線アクセス（E−UTRA）、物理層手順（リリース14）」を参照されたい。ソース車両がPSSCH上でペイロードデータを送信するとき、ソース車両は、同じサブフレーム内のPSCCH上でSCI（たとえば、SCIフォーマット1）を送信する。いくつかの例では、DCIフォーマット5Aのいくつかのフィールドは、ソース車両によってSCIフォーマット1にコピーされる。
【００７９】
サイドリンク送信モード3では、最初にUEはサブフレームn内でDCIを受信する。次いで、UEはサブフレームn＋l’内でSCIを送信し、ここで、l’はPSCCH用に構成された最初の利用可能なサブフレームであり、サブフレームnの後のl’≧4である。また、UEはサブフレームn＋1’＋1”内でPSCCHを送信する。l”＝0であるとき、PSCCHはSCIと同じサブフレーム内で送信される。通知されると、PSSCHはSCIに含まれる情報によって示されたサブフレーム内で再送信される。
【００８０】
半持続的スケジューリング（SPS）を使用すると、ネットワークは、SPS−ConfigSL情報要素およびDCIフォーマット5Aなどの高レベルシグナリングを使用して、PSCCH／PSSCHの送信向けの定期的なプロセスを定義することができる。
【００８１】
特定の実施形態では、他の車両がPSCCH／PSSCHを受信することができるように、ソース車両によって送信されたPSCCH／PSSCHが有効なプール内にあることを保証することは、ネットワークの責任である。
【００８２】
自律モード（サイドリンク送信モード4またはV2V）では、ソース車両は最初に、リソースを監視することにより、たとえば、Txプール内の信号レベルを測定すること（検知）、およびTxプール内のリソースをランダムに選択することにより、Txプール内でいつ送信することができるかを判断する。ソース車両は、リソース上のメッセージの優先度レベルと比較して（ソース車両によって送信されるべき）メッセージ用の優先度レベルを調査し、占有時間を調査する。ソース車両がいつどのリソース上で送信することができるかを識別した後、ソース車両はPSSCH上でデータパケットを送信し、PSCCH用の対応するSCIフォーマットを生成し送信する。
【００８３】
本開示の特定の実施形態は、サイドリンク手順を拡張して、ユニキャストおよび／またはグループキャストをサポートする。たとえば、サイドリンクにおいてユニキャストおよびグループキャストをサポートするために、制御シグナリングが修正される。本開示の特定の実施形態は、フィードバックを提供する宛先モバイルデバイスをサポートし、関連するフィードバック手順を定義する。加えて、HARQシグナリングのタイムラインが組み込まれてよい。
【００８４】
UEのグループを確立することが望ましい場合がある。UEのグループは様々な方式で確立されてよい。基地局（たとえば、eNB）または他のネットワーク構成要素は、グループを作成することができる。他の例では、公共安全モバイルデバイスのグループまたは自宅内の電子デバイスなどのグループは、事前に構成または再構成される。グループは、モバイルデバイスの物理的な近接度に基づいて作成されてよい。たとえば、特定のモバイルデバイスの所与の距離内にあるモバイルデバイスは、設定された継続時間の間一緒にグループ化されてよい。
【００８５】
LTEは、ダウンリンク（たとえば、PDSCH）上で送信されたパケット、およびアップリンク（たとえば、PUSCH）上で送信されたパケットに対する確認応答のためのいくつかのフィードバックメカニズムを含む。PDSCHの場合、UEはPUCCH上でUCIを送信することができる。PUCCHは、いくつかの形式の多重化：時間（たとえば、スロット）、周波数（たとえば、PRB）、およびコード（たとえば、同じ時間／周波数リソース上で送信するUEを分離するため）を有する。UEは、PUSCH上でUCIを多重化またはピギーバックすることもできる。UEは、PUSCHなしにPRBペア上でUCIを送信することができる。PUSCHに対する確認応答の場合、基地局（たとえば、eNB）はPHICH上でACK／NACKを送信する。1つのPHICHグループに対して、最大8つのACK／NACKがサポートされてよい。HARQを使用して、ソースUEはパケットを送信し、パケットに対する応答、たとえば、ACK／NACKを受信することを予想する。
【００８６】
図7は、本開示の特定の実施形態による、ソースモバイルデバイスによって実行され、ソースモバイルデバイスが確認応答を予想する、サイドリンク上でパケットを送信する例示的な方法430のフローチャートを示す。この例では、アプリケーション層は、データパケット用のグループを使用するように物理層に指示することができる。
【００８７】
ブロック432において、ソースモバイルデバイスは、送信用のデータパケットが存在するかどうかを判定する。データパケットは、物理層によって上位層から取得されてよい。送信用のデータパケットが存在しないとソースモバイルデバイスが判定すると、手順はブロック442において終了する。一方、送信用のデータパケットが存在するとソースモバイルデバイスが判定すると、手順はブロック434に進む。
【００８８】
ブロック434において、ソースモバイルデバイスは、データパケット用のスケジューリングを実行する。データパケットは、たとえば、LTE規格の適切なバージョンからの手順を用いて送信媒体を検知することにより、スケジュールされてよい。たとえば、「3GPP TS36．213 V14．7．0、セクション14．1および14．2（2018−06）」、「第3世代パートナーシッププロジェクト、技術仕様グループ無線アクセスネットワーク、発展型ユニバーサル地上波無線アクセス（E−UTRA）、物理層手順（リリース14）」、ならびに「3GPP TS36．321 V14．4．0、セクション5．14（2017−09）」、「第3世代パートナーシッププロジェクト、技術仕様グループ無線アクセスネットワーク、発展型ユニバーサル地上波無線アクセス（E−UTRA）、媒体アクセス制御（MAC）プロトコル仕様（リリース14）」を参照されたい。別の例では、ネットワークは（たとえば、eNBなどの基地局を介して）、たとえば、DCIメッセージまたはSPSプロセスを使用して、送信用のリソースを提供する。
【００８９】
ソースモバイルデバイスはまた、データパケットに関連付けられたスケジューリング情報、およびスケジューリング情報を送信するための制御リソースを決定する。制御リソースは、リソースの第1のセットから決定されてよい。特定の実施形態では、制御リソースはPSCCHを備える。スケジューリング情報は、データパケットに関連付けられたSCIであってもよく、それを含んでもよい。たとえば、スケジューリング情報（たとえば、SCI）は、データパケットの宛先である宛先モバイルデバイスを示すことができる。別の例として、スケジューリング情報（たとえば、SCI）は、たとえば、ビットインジケータまたはグループIDを使用して、データパケットが（たとえば、ACKまたはNACKで）確認応答されるべきであるという指示を含んでよい。別の例として、スケジューリング情報（たとえば、SCI）は、ACK／NACK用の時間／周波数リソース割当てを含んでよい。別の例として、スケジューリング情報は、ソースモバイルデバイスからデータパケットを送信するための送信情報を含んでよい。特定の例として、送信情報は、ソースモバイルデバイスからデータパケットを送信するために使用されるべき特定のPSSCHを示すことができる。これらの特定のパラメータが記載されているが、本開示は、特定の実装形態に従って、任意の適切な送信パラメータを含むスケジューリング情報を想定している。いくつかのシナリオでは、以下でより詳細に記載されるように、データパケットを送信するための送信情報はデータパケットを再送信するための再送信情報であり、第1のモバイルデバイスにより、第2のモバイルデバイスに、送信情報によって示されたリソースのセット上でデータパケットを送信するステップは、再送信情報によって示されたリソースのセット上でデータパケットを再送信するステップを含む。
【００９０】
一例では、符号分割多元接続（CDMA）が使用され、グループ内の各宛先モバイルデバイスは、グループ内で一意のID（たとえば、グループメンバID）を有する。CDMAコードは、この一意のグループメンバIDに基づいて選択されてよい。一例として、グループメンバIDは4ビットであってよく、選択されたCDMAコードは、インデックスIDに対応するアダマールシーケンス（または別の適切なエラー訂正コード）である。所与の宛先モバイルデバイスのACK／NACKを含むメッセージは、パケット確認応答のための時間／周波数リソース上でソースモバイルデバイスに送信されてよく、メッセージはCDMAコードで拡張されてよい。特定の実施形態では、宛先モバイルデバイスは、たとえば、スケジューリング情報（たとえば、SCI）またはデータパケットの受信電力レベルに基づいて、オープンループ電力制御を使用してACKまたはNACKを送信し、それにより、遠近問題が低減または除去されてよい。特定の実施形態では、宛先モバイルデバイスは、ランダムまたは擬似ランダムにACKまたはNACKを送信し、ACKまたはNACK用の領域は、特定の時間／周波数リソースとではなく、宛先モバイルデバイスに送信されたスケジューリング情報内でソースモバイルデバイスによって示される。
【００９１】
また、ブロック436において、ソースモバイルデバイスは、リソースの第2のセットから、データパケットに関連付けられたACK／NACKリソースを決定する。言い換えれば、ソースモバイルデバイスは、ACKまたはNACKを送信するために宛先モバイルデバイスによって使用されるべきACK／NACKリソースを決定する。特定の実施形態では、ブロック436はブロック434と一緒に実行されてよい。特定の実施形態では、第1のモバイルデバイスはリソースの第2のセットを示すDCIをeNBから受信する。
【００９２】
ソースモバイルデバイスは、様々な方法でACK／NACKリソースを決定することができる。たとえば、ACK／NACKリソースは、リソースの第2のセットであり得る、事前定義されたACK／NACKリソースプールから選択されてよい。別の例として、ACK／NACK用の時間／周波数リソースは、スケジューリング情報（たとえば、SCI）の位置、またはデータパケットが送信される位置から暗黙的に導出されてよい。特定の例として、スケジューリング情報（たとえば、SCI）は、スケジューリング情報（たとえば、SCI）の送信に続く少なくとも事前定義された時間、たとえば、4msにおいて、リソースプール内のリソース内で送信される。別の特定の例として、SCIリソースは論理的にインデックス付けされてよく、ACK／NACKリソースは論理的にインデックス付けされてよい。SCIリソースとACK／NACKリソースの間で、1対1のマッピングが使用されてよい。たとえば、SCIリソース＃kが使用されるとき、ACK／NACKリソース＃kが使用される。リソース番号はサブチャネル番号であってよい。別の例では、リソース番号はTxプール内のPRBインデックスに関連する。一実施形態では、ACK／NACKリソースは、SCIと同じ周波数リソース上でのSCI送信の4サブフレーム後に、ACK／NACKリソースプール内で配置される。
【００９３】
ブロック438において、ソースモバイルデバイスは、データパケットおよび関連するスケジューリング情報を宛先モバイルデバイスに送信する。ソースモバイルデバイスは、サイドリンクインターフェースを使用して、データパケットおよび関連するスケジューリング情報（たとえば、SCI）を通信する。たとえば、ソースモバイルデバイスは、宛先モバイルデバイスに、スケジューリング情報を送信するための制御リソース上でスケジューリング情報を、スケジューリング情報の送信情報によって示されたリソースのセット上でデータパケットを送信することができる。特定の例として、スケジューリング情報は、送信情報内で特定のPSSCHを指定することができ、ソースモバイルデバイスは、特定のPSSCHを使用してデータパケットを送信することができる。スケジューリング情報は、特定のPSCCHなどの、ステップ434において決定された特定の制御リソースを使用して、宛先モバイルデバイスに送信されてよい。
【００９４】
特定の実施形態では、第1のモバイルデバイスは、決定された制御リソース上でスケジューリング情報を含むメッセージをブロードキャストすることにより、第1のモバイルデバイスからのスケジューリング情報を1つまたは複数の宛先モバイルデバイスに送信する。たとえば、第1のモバイルデバイスは、第1のモバイルデバイスにより、PSCCH上でデータパケットに関連付けられたスケジューリング情報をブロードキャストすることにより、制御チャネル上でスケジューリング情報を第2のモバイルデバイスに送信することができ、スケジューリング情報はサイドリンク制御情報（SCI）としてブロードキャストされる。特定の実施形態では、第1のモバイルデバイスは、データッパケットを含むメッセージをブロードキャストすることにより、第1のモバイルデバイスからのデータパケットを1つまたは複数の宛先モバイルデバイスに送信する。特定の実施形態では、データパケットおよびSCIは、結合メッセージの一部として一緒にブロードキャストされてよい。
【００９５】
ブロック440において、ソースモバイルデバイスは、ACK／NACKリソース（たとえば、ブロック436において決定されたACK／NACKリソース）上で宛先モバイルデバイスによって送信されたACK／NACKをリッスンする。ランダム送信が使用されるとき、特定の実施形態では、ソースモバイルデバイスは、領域内のすべてのリソース上でACK／NACKを検出しようと試みる。宛先モバイルデバイスは、領域内のリソース上で擬似ランダムまたはランダムにACK／NACKを送信する。同じリソース上で送信された複数の宛先モバイルデバイスからのACK／NACK送信間で衝突が発生する可能性がある。
【００９６】
図8は、本開示の特定の実施形態による、モバイルデバイス間の通信についての例示的なメッセージ図260を示す。図示された例では、モバイルデバイスは車両（すなわち、ソース車両262および宛先車両264）と呼ばれるが、本開示は、モバイルデバイスが任意の適切なタイプのモバイルデバイスであることを想定している。
【００９７】
ソース車両262は、トランスポートブロック（TB）の送信ステータス、たとえば、新しい送信か再送信かを特定する。この説明全体を通して、送信ブロックはデータパケットと呼ばれる場合もある。最初の送信では、スケジューリング情報（たとえば、SCI）内のフィールドが準備され、カウンタがリセットされる。再送信の場合、スケジューリング情報（たとえば、SCI）内のフィールドが準備され、カウンタが更新される。カウンタは、図9を参照して以下で詳細に記載される。ソース車両262は、スケジューリング情報（たとえば、SCI）を符号化し、符号化されたスケジューリング情報（たとえば、符号化されたSCI）を、メッセージ266内の決定された制御リソース（たとえば、PSCCH）上で、宛先車両264に送信する。TBも、スケジューリング情報（たとえば、SCI）のフィールドに従って、符号化され、変調され、サイドリンクリソース上に配置されてよい。TBは、スケジューリング情報の送信情報によって示されたリソース上で、ソース車両262によって宛先車両264に送信される。たとえば、TBは、メッセージ266内のPSSCH上でソース車両262によって送信されてよい。
【００９８】
メッセージ266に応答して、宛先車両264は、メッセージ266に含まれるパラメータ（たとえば、スケジューリング情報）に従って、メッセージ268上でソース車両262にACKまたはNACKを送信する。スケジューリング情報によって示されたACK／NACKリソース上で宛先車両264からACK／NACKを受信した後、ソース車両262はACK／NACKを処理する。
【００９９】
図9は、本開示の特定の実施形態による、ソースモバイルデバイスによって実行されるACK／NACK手順のための例示的な方法450のフローチャートを示す。一例として、方法450は図7のブロック434および438の詳細を示す。ソースモバイルデバイスは、たとえば、V2V通信を実行する車両、またはD2D通信を実行する別のUEであってよい。ブロック452において、ソースモバイルデバイスは手順を開始する。
【０１００】
ブロック454において、ソースモバイルデバイスは、送信がTBの初期送信であるか再送信であるかを判定する。送信が初期送信であるとき、ソースモバイルデバイスはブロック456に進んで、第1の方式でスケジューリング情報の（たとえば、SCIの）フィールドを設定する。一方、送信が再送信であるとき、ソースモバイルデバイスはブロック460に進んで、第2の方式でスケジューリング情報の（たとえば、SCIの）フィールドを設定する。
【０１０１】
ブロック456において、初期送信の場合、ソースモバイルデバイスは、第1の方式でスケジューリング情報の（たとえば、SCIの）フィールドを設定する。たとえば、SCIの新データインジケータ（NDI）フィールドの値が切り替えられてよい。特定の例として、NDIが現在0の値をもつとき、それは1の値に変更され、NDIが現在1の値をもつとき、それは0の値に変更される。SCI内の他のフィールドが設定されてよい。たとえば、MCSフィールドおよびリソース割当てフィールドは、それらのフィールドに値を割り当てることによって設定されてよい。また、グループに関連付けられたSCIフォーマット0などのグループIDがSCIに挿入されてよい。一例では、グループIDは8ビットまたは12ビットなどの小さいサイズのフィールドである。加えて、SCIは、アダマールシーケンスまたは他のタイプのエラー訂正コード用のインジケータを含んでよい。ソースモバイルデバイスはまた、冗長バージョン（RV）フィールドを0に設定してよい。ブロック458において、ソースモバイルデバイスは、このTBの送信回数用のカウンタをリセットする。スケジューリング情報の（たとえば、SCIの）特定のフィールドの準備が記載されているが、本開示は、任意の適切な方式でスケジューリング情報の（たとえば、SCIの）任意の適切なフィールドを設定することを想定している。
【０１０２】
ブロック460において、再送信の場合、ソースモバイルデバイスは、第2の方式でスケジューリング情報の（たとえば、SCIの）フィールドを設定する。たとえば、ソースモバイルデバイスは、NDIビットの値を保持してよい（たとえば、NDIビットの値は変更されないままである）。別の例として、ソースモバイルデバイスはRVフィールドを更新してよい。RVフィールドを更新する1つの例示的な方法は値の循環に従うことである。この値の循環の一例として、RVフィールドの値が最初に0であるとき、RVフィールドの値は2に移行し、RVフィールドの値が最初に2であるとき、RVフィールドの値は3に移行し、RVフィールドの値が最初に3であるとき、RVフィールドの値は1に移行し、RVフィールドの値が最初に1であるとき、RVフィールドの値は0に移行する。ソースモバイルデバイスはまた、SCI内の他のフィールドを設定してよい。たとえば、ソースモバイルデバイスは、MCSフィールドおよびリソース割当てフィールドを設定してよい  また、グループに関連付けられたSCIフォーマット0などのグループIDがSCIに挿入されてよい。グループIDは小さいサイズのフィールド、たとえば8ビットまたは12ビットであってよい。加えて、SCIは、アダマールシーケンスまたは他のタイプのエラー訂正コードへのインジケータを含んでよい。ブロック462において、ソースモバイルデバイスは、このTBの送信回数用のカウンタを更新する。一例では、ブロック454において送信が再送信であるとソースモバイルデバイスが判定するたびに、カウンタがインクリメントされる。繰返しになるが、スケジューリング情報の（たとえば、SCIの）特定のフィールドの準備が記載されているが、本開示は、任意の適切な方式でスケジューリング情報の（たとえば、SCIの）任意の適切なフィールドを設定することを想定している。
【０１０３】
ブロック464において、ソースモバイルデバイスは、制御リソース上（たとえば、PSCCH上）で宛先モバイルデバイスにスケジューリング情報（たとえば、SCI）を送信する。たとえば、ソースモバイルデバイスはSCIを符号化し、PSCCH上で宛先モバイルデバイスにそれを送信する。
【０１０４】
ブロック466において、ソースモバイルデバイスは、PSSCH上で宛先モバイルデバイスにTBを送信する。たとえば、ソースモバイルデバイスは、SCIのフィールドに従って、TBを符号化し、変調し、サイドリンクリソース上に配置する。PSSCHは、宛先モバイルデバイスに送信されるスケジューリング情報の送信情報内で示されてよい。ブロック468において方法は終了する。
【０１０５】
図10は、本開示の特定の実施形態による、ソースモバイルデバイスによって実行される、ACK／NACKを監視するための例示的な方法470用のフローチャートを示す。一例として、方法470は図7のブロック440のさらなる詳細を示す。ソースモバイルデバイスは、V2V通信を実行する車両、またはD2D通信を実行するUEであってよい。
【０１０６】
ブロック472において、ソースモバイルデバイスは、宛先モバイルデバイスから、ACKまたはNACKを含むACK／NACKリソースを受信する。ACK／NACKは、制御リソース（たとえば、PSCCH）上でソースモバイルデバイスによって送信されたスケジューリング情報によって以前に示されたACK／NACKリソース上で受信されてよく、宛先モバイルデバイスはACK／NACKで部分的に応答している（すなわち、宛先モバイルデバイスがAKC／NACKを送信したものに応答している）。ACK／NACKリソース上でのACK／NACKの宛先モバイルデバイスからソースモバイルデバイスへの通信は、（たとえば、ブロードキャストメッセージではなく）ソースモバイルデバイスに向けられた通信であってよい。ACKは、宛先モバイルデバイスが、スケジューリング情報によって示された送信リソース（たとえば、PSSCH）上でソースモバイルデバイスによって送信されたデータパケットを正しく受信したことを示すことができる。NACKは、宛先モバイルデバイスが、スケジューリング情報によって示された送信リソース（たとえば、PSSCH）上でソースモバイルデバイスによって送信されたデータパケットを少なくとも部分的に正しく受信しなかったことを示すことができる。ブロック474において、ソースモバイルデバイスは、ブロック472において受信されたリソースからACK／NACKを抽出する。
【０１０７】
ソースモバイルデバイスは、データパケットの送信に応答して受信されたACK／NACKの数をカウントし、受信されたACK／NACKの数およびモバイルデバイスのグループ内のモバイルデバイスの数に少なくとも部分的に基づいて、データパケットを再送信するかどうかを判定することができる。たとえば、ブロック476において、ソースモバイルデバイスは、ACK／NACKの数がグループのグループサイズと一致するかどうかを判定する。グループは、データパケットの送信の宛先である宛先モバイルデバイスを含む。ACK／NACKの数がグループサイズと一致するとソースモバイルデバイスが判定した場合、ソースモバイルデバイスはブロック477に進んで、受信されたACK／NACKのいずれかがNACKであるかどうかを判定する。あるいは、ブロック477において、ソースモバイルデバイスは、受信されたACK／NACKのすべてがACKであるかどうかを判定することができる。ソースモバイルデバイスが、ブロック477において、受信されたACK／NACKのいずれもNACKではないと（または、代替の判定において、受信されたACK／NACKのすべてがACKであると）判定した場合、ソースモバイルデバイスはブロック484に進む。一方、ソースモバイルデバイスが、ブロック477において、受信されたACK／NACKの少なくとも1つがNACKあると（または、代替の判定において、受信されたACK／NACKのすべてがACKであるとは限らないと）判定した場合、ソースモバイルデバイスはブロック478に進む。ブロック476に戻り、ACK／NACKの数がグループサイズと一致しないとソースモバイルデバイスが判定した場合、ソースモバイルデバイスはまたブロック478に進む。
【０１０８】
ブロック478において、ソースモバイルデバイスは、ACK／NACKを送信したモバイルデバイスを識別する。ブロック480において、ソースモバイルデバイスは、カウンタの上限に達したかどうかを判定する。このカウンタは、ACK／NACKが正しく受信されなかったときにストールを防止するために、ソースモバイルデバイスによって使用されてよい。カウンタの上限に達すると、ソースモバイルデバイスはブロック484に進む。一方、カウンタの上限に達していないとき、ソースモバイルデバイスはブロック482に進む。
【０１０９】
ブロック482において、ソースモバイルデバイスはTBの再送信のための準備をする。次いで、ソースモバイルデバイスは図9に示された方法を実行してよい。
【０１１０】
ブロック484において、ソースモバイルデバイスは、送信のために次のTBを準備する。次いで、ソースモバイルデバイスは図9に示された方法を実行してよい。
【０１１１】
特定の実施形態では、グループIDは2つのセットに分割され、ゼロの値はブロードキャストを示し、非ゼロの値は特定のグループに関連付けられる。たとえば、4ビットのグループメンバIDが2つのセットに分割されてよく、「oooo」の値は送信がブロードキャストされることを示し、「0001」などの非ゼロの値は、送信モバイルデバイスに関連付けられたグループメンバIDである。一例では、送信がブロードキャストであることをグループメンバIDが示すとき、宛先モバイルデバイスからの確認応答は予想されない。また、送信がブロードキャストであることをグループIDが示すとき、グループメンバIDは無視されてよい。グループIDフィールドが特定のグループIDを示すとき、宛先モバイルデバイスは、ACKまたはNACKを送信することによって送信に確認応答することが予想される。別の例では、スケジューリング情報内のビット（たとえば、SCIのビット）は、PSSCHがブロードキャストされるかグループキャストされるかを示す。特定の実施形態では、PSSCHがブロードキャストされるとき、確認応答は予想されないが、PSSCHがグループキャストされるとき、確認応答が予想される。
【０１１２】
宛先モバイルデバイスがソースモバイルデバイスにHARQフィードバックを送信し、ソースモバイルデバイスがLTEおよびNRのフレームワーク内でACK／NACKフィードバックを受信することが望ましい場合がある。セルラーシステムなどの集中型システムでは、中央コントローラ（たとえば、LTEのeNBまたはNRのgNB）は、ACK／NACKを送信するためにUEにリソースを割り当てる。分散システムでは、集中型コントローラが存在しない可能性がある。したがって、分散システムでは、ソースモバイルデバイスがACK／NACKを予想しているが、ACK／NACKを受信していないときにソースモバイルデバイスが送信しないメカニズムを有することが望ましい。
【０１１３】
グループキャストでは、複数のモバイルデバイスが同時に送信または受信すると、以下でより詳細に記載されるように、衝突および他の問題につながる可能性がある。
【０１１４】
図11A〜図11Bは、本開示の特定の実施形態による、例示的な車両グループキャストシナリオを示す。図示された例では、グループキャスト送信が問題につながる。図11aでは、車両272は車両274および車両276へのグループキャストを実行する。図11bは、車両272の観点から、1つのSCIおよび1つの共有チャネルを含む、送信されたサブフレーム280を示す。サブフレーム280はPSSCH282およびPSCCH284を含む。
【０１１５】
車両274および車両276がフィードバックを送信するときに衝突があり得る。車両274および車両276が異なるリソース上で同時に送信するとき、フィードバックからの受信電力は、2つの受信信号において異なる場合がある。車両274および車両276からのフィードバックは、フィードバックが同じリソース上で同時に送信されたときに車両272において衝突する可能性がある。衝突があるとき、受信電力にも差があり得る。別の考えられる問題は、車両274がサブフレームn内で車両272から第1のメッセージを受信し、車両276がサブフレームn＋k内で車両272から第2のメッセージを受信するとき、TDDルールのために、車両274からのフィードバックが遅延し、車両276からのフィードバックと同じサブフレーム上にあることである。
【０１１６】
図12A〜図12Bは、本開示の特定の実施形態による、SC−FDMAとの例示的な車両調整を示す。詳細には、図12A〜図12Bは、SC−FDMAとの潜在的な調整問題を示す。図12aは、車両272が車両274からメッセージを受信し、車両272が車両276から異なるメッセージを受信するシナリオを示す。図12bは、車両272の観点からのサブフレーム300を示す。サブフレーム300は、2つの共有チャネル、車両274からのPSSCH302および車両276からのPSSCH306を含む。また、サブフレーム300は、2つのSCI、車両274からのPSCCH304および車両276からのPSCCH308を含む。車両272が同じサブフレーム内の2つの異なるリソース上でフィードバックを送信することは問題になる可能性がある。いくつかのシナリオでは、車両272はサブフレーム内の1つのリソース上での送信のみをサポートする。また、キャリアアグリゲーションルールが問題につながる可能性がある。
【０１１７】
ACK／NACKは、通常、チャネル上で送信される。LTEでは、PDSCH上で送信されるダウンリンクデータに対するACK／NACKは、特定のPUCCHリソース上で送信されるか、またはPUSCH上でパンクチャされる。PHICHは、受信されたPUSCHのACK／NACKを伝達するために基地局（たとえば、eNB）によって送信される。サイドリンク送信では、ACK／NACKはPSSCH上で送信されてよく、ペイロードサイズが異なるか、または新しいチャネル上で送信される可能性がある。新しいチャネル、たとえば、物理サイドリンクHARQインジケータチャネル（PSHICH）は、信頼性が高いACK／NACK受信用のリソースを有する可能性がある。
【０１１８】
一実施形態では、ACK／NACK送信のためのリソースプールが事前に定義されている。リソースプールはデータ送信にリンクされているので、ソースモバイルデバイスおよび宛先モバイルデバイス（たとえば、UE）は、所与の送信用のリソースプールの位置を知っている。一実施形態では、上述されたように、特定のACK／NACK用のリソースは、データ送信に関連付けられたスケジューリング情報（たとえば、SCI）から、明示的または暗黙的に取得されてよい。一実施形態では、ACK／NACKは特定のフォーマットを使用して送信され、特定のフォーマットは、ソースモバイルデバイス（すなわち、ソースモバイルデバイスからの以前の送信に応答してACK／NACKを受信しているモバイルデバイス）によるACK／NACKの信頼できる検出を容易にすることができる。
【０１１９】
特定の実施形態はACK／NACKフィードバックを実装するが、他の形態のフィードバックに同じまたは同様の技法が使用されてもよい。たとえば、チャネル品質インジケータ（CQI）、プリコーディングマトリクスインジケータ（PMI）、およびランクインジケータ（RI）は、ACK／NACK送信に使用される同じリソースを使用して送信されてよい。複数のタイプのフィードバックに同じリソース技法を使用すると、効率的なMCS適応、周波数選択的スケジューリング、および複数入力複数出力（MIMO）技法の使用を容易にすることができる。
【０１２０】
図13A〜図13Bは、本開示の特定の実施形態による、制御およびデータを多重化するための例示的なフレーム構造を示す。詳細には、図13A〜図13Bは制御およびデータの多重化の2つの例を示す。図13aによって示された周波数分割多重化（FDM）では、制御領域314（たとえば、PSCCH）は、周波数領域内でデータ領域312（たとえば、PSSCH）と多重化される。LTEでは、PSCCH用の開始リソース位置はサブチャネルインデックスに関連する。構成により、V2V用の送信プールはm個のサブチャネルに分割される。ソース車両は、特定のサブチャネルを使用するために、それ自体で、またはDCIメッセージ内の基地局（たとえば、eNB）によるシグナリングに基づいて、m個のサブチャネルのうちの1つを選択する。ソース車両はPSSCHをPSCCHよりも高い周波数に配置する。V2Vでは、PSCCHは2つのPRBを占有する。D2Dでは、PSCCHは1つのPRBを占有し、V2VのPSCCHと比較して、D2DのPSCCHを復調するための復調基準信号（DMRS）は少ない。
【０１２１】
図13bによって示された時分割多重化（TDM）では、制御領域322（たとえば、PSCCH）は、時間領域内でデータ領域324（たとえば、PSSCH）と多重化される。D2Dの場合、PSCCHはPSSCHの少なくとも4サブフレーム前に送信される。
【０１２２】
別の実施形態では、PSCCHおよびPSSCHは同じサブフレーム上で送信される。
【０１２３】
図14は、本開示の特定の実施形態による、D2D通信用のフレームの例示的なシーケンス（シーケンス342）およびV2V通信用のフレームの例示的なシーケンス（シーケンス344）を示す。PSSCH上でデータパケットを送信した後、ACK／NACK送信に事前に割り当てられたリソースのプールが存在してよい。
【０１２４】
D2D（たとえば、シーケンス342）の場合、基地局（たとえば、eNB）のカバレージエリア内にあるソースモバイルデバイス（たとえば、UE）は、サブフレーム332内で基地局からDCIを受信する。ソースモバイルデバイス（たとえば、UE）は、サブフレーム334内でPSCCHを送信する。この例では少なくとも4サブフレーム後に、ソースモバイルデバイス（たとえば、UE）は、サブフレーム346内でPSSCHを送信する。次いで、この例ではPSSCHを送信した少なくとも4サブフレーム後に、ソースモバイルデバイス（たとえば、UE）は、宛先モバイルデバイス（たとえば、UE）からサブフレーム348内でACK／NACKを受信する。ソースモバイルデバイス（たとえば、UE）が基地局のカバレージ外にあるとき、サブフレーム332内でDCIを受信する動作は実行されない可能性がある。
【０１２５】
V2V（たとえば、シーケンス344）の場合、基地局（たとえば、eNB）のカバレージエリア内にあるソース車両は、基地局からサブフレーム330内でDCIを受信する。ソース車両は、サブフレーム338内でPSCCHおよびPSSCHを送信する。次いで、この例では少なくとも4サブフレーム後に、ソース車両はサブフレーム336内でACK／NACKを受信する。ソース車両が基地局（たとえば、eNB）のカバレージ外にあるとき、サブフレーム330内でDCIを受信する動作は実行されない可能性がある。
【０１２６】
図15は、本開示の特定の実施形態による、NRにおけるフレームの例示的なシーケンスを示す。詳細には、図15は、NRにおけるサブフレーム内の可能なシンボルシーケンス350を示す。一実施形態では、ACK／NACKのシンボル位置は事前に定義されている。最初のシンボル、シンボル352は、自動利得制御（AGC）に使用されてよい。シンボル352に続く1つまたは複数のシンボルであるデータシンボル354は、データおよび基準信号の送信用である。シンボル356は予約シンボルであってよい。最後のデータシンボル354のいくつかのシンボル内で、受信モバイルデバイス（たとえば、UE）は、シンボル352内でACK／NACKを送信する。シンボル352のACK／NACKの後に、別の予約シンボル358が存在してよい。
【０１２７】
基地局（たとえば、eNB）は、システム情報ブロック内のACK／NACKプールについての構成を、基地局のカバレージエリアにあるすべてのモバイルデバイス（たとえば、UE）にブロードキャストすることができる。構成は、共有チャネルプールに対するACK／NACKプールの時間関係、およびACK／NACKプールの周波数リソースを含んでよい。ソースモバイルデバイス（たとえば、UE）は、PSSCHの位置に従って特定のACK／NACKリソースの位置を特定することができる。たとえば、PSSCHがサブチャネル4上で送信されるとき、ゼロベースの番号付けを使用して、V2Vの場合、PSSCHに対するACK／NACKはACK／NACKプールの5番目のPRBであってよい。
【０１２８】
基地局（たとえば、eNB）のカバレージエリア内にあるモバイルデバイスについての別の例では、基地局は、DCI内でACK／NACKリソース（たとえば、時間リソースおよび周波数リソース）の位置を送信することができる。ソースモバイルデバイス（たとえば、UE）は、SCI内のDCIから決定されたACK／NACKリソースのこの位置情報を転送することができる。位置情報を含むSCIフォーマットは、ソースモバイルデバイス（たとえば、UE）によって送信される。また、ソースモバイルデバイス（たとえば、UE）は、DCIからACK／NACKの位置を取得することができる。
【０１２９】
追加または代替として、周波数におけるACK／NACKプールの開始位置は、基地局（たとえば、eNB）によって送信される。PSCCHがサブチャネル4上で送信されるとき、ゼロベースの番号付けを使用して、V2Vの場合、PSSCHに対するACK／NACKはACK／NACKプールの5番目のPRBであってよい。
【０１３０】
基地局（たとえば、eNB）のカバレージエリア外にあるモバイルデバイス（たとえば、UE）の場合、ACK／NACKプールの構成は事前に構成されてよい。事前に構成されたACK／NACKプールは、共有チャネルプールに対するACK／NACKプールの時間関係、およびACK／NACKプールの周波数リソースを含んでよい。ソースモバイルデバイス（たとえば、UE）は、PSCCHの位置に従って特定のACK／NACKリソースの位置を特定することができる。
【０１３１】
基地局（たとえば、eNB）のカバレージエリア外にあるモバイルデバイス（たとえば、UE）についての別の例では、ACK／NACKプールの位置情報を含む新しいSCIフォーマットが、ソースモバイルデバイス（たとえば、UE）によって送信される。ソースモバイルデバイス（たとえば、UE）は、処理するためのACK／NACKの位置を知っている。別の実施形態では、ACK／NACKプールの周波数における開始位置は、ソースモバイルデバイス（たとえば、UE）によって送信される。
【０１３２】
2つ以上の宛先モバイルデバイス（たとえば、UE）の場合、同じリソース上で異なるモバイルデバイス（たとえば、UE）からのACK／NACKを多重化するために、符号分割多重化（CDM）手法が使用されてよい。グループ内の各宛先モバイルデバイス（たとえば、UE）は、グループ内で一意のID（グループメンバID）を有する。一意のグループメンバIDに基づいて、CDMAコードが選択される。たとえば、4ビットのグループメンバIDの場合、選択されたCDMAコードは、アダマールシーケンスまたは別の適切なエラー訂正コードであってよい。宛先モバイルデバイス（たとえば、UE）のACK／NACKを含むメッセージは、パケット確認応答用の時間／周波数リソース上で送信され、メッセージはCDMAコードで拡張される。
【０１３３】
同じリソース上で異なるモバイルデバイス（たとえば、UE）から受信されたACK／NACKの間に電力差が存在する場合がある。遠近問題を低減または除去するために、オープンループ電力制御が使用されてよい。特定の実施形態では、宛先モバイルデバイスは、たとえば、スケジューリング情報（たとえば、SCI）またはデータパケットの受信電力レベルに基づいて、オープンループ電力制御を使用してACKまたはNACKを送信する。オープンループ制御の一例では、（宛先モバイルデバイス用の）HARQ−ACKチャネル用の送信電力PCHは、PCH＝min（PCMAX，PCH＿RECEIVED＿TARGET＿POWER＋PL）［dBm］によって決定されてよく、ここで、PCMAXは事前に構成されたUE送信電力であり、PLはサイドリンク経路損失推定値である。PCH＿RECEIVED＿TARGET＿POWERは、チャネル向けのサイドリンク上で電力を受信するように事前に構成されたターゲットである。経路損失は、PPSCCH、ソースモバイルデバイスからのPSCCHの送信電力MPSCCH、PSCCHに使用されるリソースの数、および場合によっては（事前）構成条件POおよびα：
PPSCCH＝min｛PCMAX，10log10（MPSCCH）＋PO＋α・PL｝
に基づいて決定されてよい。
いくつかのシナリオでは、PPSCCHの指示は、たとえば、電力レベルを示すビットフィールドとしてSCI内で通知される。
【０１３４】
宛先モバイルデバイス（たとえば、UE）が2つ以上のグループに属するとき、宛先モバイルデバイスは、同じサブフレーム内で2つ以上の受信PSSCHに対するACK／NACKを送信することができる。宛先モバイルデバイス（たとえば、UE）がネットワーク制御下にある間、基地局（たとえば、eNB）は、衝突を防止するために異なるグループに互いに素なリソースを割り当てる。モバイルデバイス（たとえば、UE）がネットワーク制御下にないときの分散送信の場合、ACK／NACK送信は、優先度、待ち時間、および電力の任意の適切な組合せに基づいてよく、高電力メッセージが最初に送信される。優先度が使用されるとき、優先度の高いメッセージが最初に確認応答される。優先度は、スケジューリング情報（たとえば、SCI）内のフィールドであってよい。
【０１３５】
ACK／NACKプールがPSSCHの送信の直後に続くとき、たとえば、ACK／NACKプールがPSSCHの4サブフレーム後であるとき、システム容量が制限される場合がある。たとえば、V2Vの場合、PSSCHの再送信は、最初の送信の1〜15サブフレーム後になる場合がある。PSSCHの4サブフレーム後に続くACK／NACKにより、サブフレーム2からサブフレーム30まで1サブフレームおきに再送信が発生する可能性がある。一実施形態では、NRにおいて、ACK／NACKプール用の1つのシンボルはサブフレームの最後にあり、ソースモバイルデバイス（たとえば、UE）はACK／NACKの位置を示す。
【０１３６】
特定の実施形態では、アップリンク送信に対するサイドリンク送信の優先度を示す優先度ルールが存在してよい。宛先モバイルデバイス（たとえば、UE）は、サイドリンク上でACK／NACKを送信する代わりに、アップリンク送信を送ってよく、ACK／NACKが決して送信されない可能性がある
【０１３７】
同様に、ソースモバイルデバイス（たとえば、UE）は、サイドリンク上でACK／NACKを受信する代わりに、アップリンク送信を送ってよい。ソースモバイルデバイス（たとえば、UE）は、データを再送信する機会が多いとき、再送信することを決定してよい。データを再送信する機会がこれ以上ないとき、今後新しいメッセージが送信されてよい。ACK／NACKがないので、グループ管理にいくつかの修正があってよい。
【０１３８】
フレーム構成、たとえば、TDD内の変更により、ACK／NACKはn＋4において送信されない。特定の実施形態では、ACK／NACKを送信するより上のACK／NACKを受信するための優先度があってよい。
【０１３９】
特定の実施形態では、宛先モバイルデバイスがACKまたはNACKを送信することは、波形を送信することを含んでよく、波形はACKまたはNACKおよびチャネル品質を示す。第1の例として、ACK／NACKインジケータは、表1によって示されるように1ビットであってよく、PRB内の1つのシンボルが使用される。そのような例では、ACK／NACKインジケータを波形または信号にマッピングするために、12個のリソース要素が利用可能である。表1では、0の値はNACKを示し、宛先モバイルデバイス（たとえば、UE）がPSSCHを復号できないことを示す。さらに、表1では、1の値はPSSCHの復号の成功に対するACKを示す。ACK／NACKビットは、波形、たとえば、直交位相シフトキーイング（QPSK）波形またはZadoff−Chu波形にマッピングされてもよい。加えて、ウォルシュ波形（＋1，−1）による信号にの乗算があってよい。
【０１４０】
【表１】
0006952871.tif 000002
【０１４１】
別の例として、フィードバックは、ACK／NACKおよびチャネル品質の測定値を含んでよい。一実施形態では、フィードバックに2ビットが使用され、1番目のビットは上記の表1によって与えられるACK／NACKを示し、2番目のビットは下記の表2によって与えられるチャネル品質を示す。チャネル品質のインジケータ用の0の値は、チャネル品質が（事前に）構成されたしきい値未満であることを示し、チャネル品質のインジケータ用の1の値は、チャネル品質が（事前に）構成されたしきい値以上であることを示す。チャネル品質のインジケータを決定するために使用される測定値は、PSCCHの受信信号強度であってよい。一実施形態では、各ビットは個別に変調される。別の実施形態では、2ビットは、表3に示される波形内で一緒にマッピングされる。パターン「xxxx」、「wwww」、「yyyy」、および「zzzz」は、特定の波形または実際の波形に対応するビットマッピングであってよい。
【０１４２】
【表２】
0006952871.tif 000003
【０１４３】
【表３】
0006952871.tif 000004
【０１４４】
図16は、本開示の特定の実施形態による、ACK／NACKが復調基準信号（DMRS）の周囲に配置される例示的なフレーム構造を示す。基準信号の周囲にACK／NACKを配置すると、ACK／NACKを受信するモバイルデバイスにACK／NACKを探す場所を示すことができる。
【０１４５】
ACK／NACKチャネル、たとえば、PSHICHは様々な位置に置かれてよい。DMRSが存在するとき、図16に示されたように、ACK／NACKチャネルはDRMSの周囲に配置されてよい。V2Vサブフレームレイアウト360は、4つのDMRSシンボル362を含んでいる。グループの16個の可能なメンバに対して、位置（時間）とウォルシュコード（カバーコード、アダマールコード）のマッピングが存在してよい。たとえば、宛先モバイルデバイスのグループメンバIDがmであるとき、位置（364、366、368、369）はm mod 4であってよい。以下の表4は、カバーコードの例示的なセットを示す。ソースモバイルデバイス（たとえば、UE）は、波形の位置およびカバーコードを識別することにより、宛先モバイルデバイス（たとえば、UE）のグループメンバIDを決定することができる。あるいは、時間インデックスtの範囲が0から
【数１】
0006952871.tif 000005
であり、サブフレーム当たり
【数２】
0006952871.tif 000006
個のACK／NACKリソースの例では、時間インデックスtは、関係
【数３】
0006952871.tif 000007
を使用して宛先モバイルデバイスのグループメンバID mから決定することができる。t＝0は364に対応し、t＝1は366に対応し、t＝2は368に対応し、t＝3は369に対応する。コードインデックスcは、時間リソース当たりコードリソースの最大数
【数４】
0006952871.tif 000008
を使用して、同様の方式
【数５】
0006952871.tif 000009
で計算されてよい。時間リソース当たり
【数６】
0006952871.tif 000010
が存在し、
【数７】
0006952871.tif 000011
であるとき、最大
【数８】
0006952871.tif 000012
個のグループメンバIDが可能である。
【０１４６】
【表４】
0006952871.tif 000013
【０１４７】
図17A〜図17Bは、本開示の特定の実施形態による、周波数領域内のACK／NACKプールの多重化の例を示す。FDMでは、ACK／NACKプールは周波数領域内で多重化されてよい。図17aに示されたフレーム構造370では、ACK／NACKプール374は、周波数領域内で制御領域376とデータ領域372との間にある。図17bは、ACK／NACKプール382が周波数領域内でデータ領域384および制御領域386の後にある、フレーム構造380を示す。図17a〜図17bは、制御領域および／またはデータ領域に隣接する制御プールを示すが、ACK／NACKプールは、PRBまたはサブキャリアなどの隣接または非隣接の周波数リソースを含んでよい。一実施形態では、ACK／NACKプールはすべての時間リソース上に存在する。あるいは、ACK／NACKプールはすべての時間リソース上に存在するとは限らない。
【０１４８】
一実施形態では、ACK／NACKプールは、専用または共通の無線リソース制御（RRC）シグナリングを使用して通知される。ACK／NACKプールシグナリングは、周波数リソース、時間リソース、または送信電力などの他のパラメータを含んでよい。加えて、サブフレームのビットマップは、どのサブフレーム送信に対して確認応答されており、どのサブフレーム送信に対して確認応答されていないかを示すために送信されてよい。この情報は明示的であっても暗黙的であってもよい。どのサブフレーム送信に対して確認応答されているかを暗黙的に示す一例は、ACK／NACKリソースプールが存在しないと、送信がHARQを使用しないことを示すことである。ACK／NACKリソースプールが占有されていないとき、ACK／NACKプールのリソースはデータまたはSCIの送信に使用されてよい。
【０１４９】
図18A〜図18Bは、本開示の特定の実施形態による、例示的なACK／NACKプールを示す。図18aは、ACK／NACKプール394がデータ領域392の下の制御領域396内で時間多重化されている、フレーム構造390を示す。ACK／NACKプール394の周波数リソースは制御領域396の周波数リソースと同じであり、ACK／NACKプール394の時間リソースは制御領域396の時間リソースとは異なる。ACK／NACKプール394は、制御領域396とは異なるメッセージ内で通信されてよい。別の例では、ACK／NACKプール394は制御領域396と同じメッセージ上だが、異なるフィールド内で通信される。
【０１５０】
図18bは、サブチャネルのような構成においてACK／NACKプール404が順序付けられたフレーム構造400を示す。ACK／NACKプール404は、複数の制御領域402とデータ領域406との間に挟まれている。このサブチャネルのような構成は、サイドリンク送信が隣接する制御およびデータの送信を使用するときに有用である。
【０１５１】
一実施形態では、SCI内のビットインジケータは、ACK／NACKプールの存在または不在を示す。V2Vでは、周波数（たとえば、PRB）における順序付けは、最低周波数から最高周波数である。制御（たとえば、PSCCH）が最初に配置され、その後にデータ（たとえば、PSSCH）が続く。PSCCHによって搬送されるSCI内のリソース割当てフィールドは、PSSCH用のPRBの数を示す。SCIはビットフィールドで増強されてよく、「0」の値はこのモバイルデバイス（たとえば、UE）用のACK／NACKプールの不在を示し、「1」の値はこのモバイルデバイス（たとえば、UE）用のACK／NACKプールの存在を示す。あるいは、「1」の値はこのモバイルデバイス（たとえば、UE）用のACK／NACKプールの不在を示し、「0」の値はこのモバイルデバイス（たとえば、UE）用のACK／NACKプールの存在を示す。ACK／NACKプール用のリソースの数は固定されていてよい。別の実施形態では、ビットフィールドはnビットを含み、ACK／NACKプール用のPRBの数を示す。n＝2の実施形態では、「00」はACK／NACKプールの不在を示し、「01」の値はACK／NACKプール内の1つのPRBを示し、「10」の値はACK／NACKプール内の2つのPRBを示し、「11」の値はACK／NACKプール内の3つのPRBを示す。ACK／NACKプールが存在するとき、リソース割当てフィールドによって示されるPSSCH用のPRBの数は、ACK／NACKプールのサイズだけ減少する。
【０１５２】
図19は、本開示の特定の実施形態による、例示的なフレーム構造410を示す図である。TDMでは、フレーム構造410によって示されたように、ACK／NACKプール414は時間領域内で制御領域412とデータ領域416との間にある。図19に示すされた例では、ACK／NACKプール414は制御領域412に隣接するように示されているが、ACK／NACKプール414は制御領域412に隣接していなくてもよい。一実施形態では、ACK／NACKプールはすべてのリソース内に存在する。あるいは、特定の実施形態では、ACK／NACKプールはすべての時間リソース上に存在するとは限らない。特定の実施形態では、ACK NACKプールは、利用可能な周波数リソースの一部のみを占有してよく、それらは隣接であっても非隣接であってもよい。
【０１５３】
専用または共通のRRCシグナリングは、ACK／NACKプールを示すために使用されてよい。ACK／NACKプールシグナリングは、周波数リソース、時間リソース、または送信電力などの他のパラメータを含んでよい。加えて、サブフレームのビットマップは、どのサブフレーム送信に対して確認応答されており、どのサブフレーム送信に対して確認応答されていないかを示すために送信されてよい。この情報は明示的であっても暗黙的であってもよい。どのサブフレーム送信に対して確認応答されているかを暗黙的に示す一例は、ACK／NACKリソースプールが存在しないと、送信がHARQを使用しないことを示すことである。ACK／NACKリソースプールが占有されていないとき、ACK／NACKプールのリソースはデータまたはSCIの送信に使用されてよい。どのサブフレーム送信に対して確認応答されており、どのサブフレーム送信に対して確認応答されていないかを示す、サブフレームのビットマップが送信されてよい。
【０１５４】
特定の実施形態では、制御領域およびACK／NACKプールは、同じプールまたはゾーン内で多重化される。この多重化は、時間領域内であっても、周波数領域内であってもよい。
【０１５５】
図20は、本開示の特定の実施形態による、宛先モバイルデバイスによって実行されるACK／NACK送信の例示的な方法490のフローチャートを示す。宛先モバイルデバイスは、D2DのUEであっても、V2Vの車両であってもよい。ブロック492において、宛先モバイルデバイスは、制御リソース上でソースモバイルデバイスからスケジューリング情報（たとえば、SCI）を受信する。制御リソースはPSCCH上にあってよい。言い換えれば、スケジューリング情報はPSCCH上で受信されてよい。スケジューリング情報はデータパケットと関連付けられる。上述されたように、スケジューリング情報は、ソースモバイルデバイスによってデータパケットを送信するための送信情報を含んでよく、スケジューリング情報は、データパケットに関連付けられたACK／NACKリソースの指示を含んでよい。宛先モバイルデバイスは、スケジューリング情報（たとえば、SCI）を処理して、データパケットを探すかどうか、および（仮にあったとしても）どのように応答するかを判定する。
【０１５６】
加えて、ブロック492において、宛先モバイルデバイスは、スケジューリング情報からの送信情報によるリソース指示に基づいて、ソースモバイルデバイスからデータパケットを受信する。たとえば、宛先モバイルデバイスはPSSCH上でデータパケットを受信してよい。処理されたSCIを使用して、宛先モバイルデバイスは、PSSCH上で受信されたデータを復号しようと試み、PSSCHを処理する。
【０１５７】
ブロック494において、宛先モバイルデバイスは、ACK／NACKを送信するための送信における位置を決定する。特定の実施形態では、スケジューリング情報は、たとえば、PSHICH上のACK／NACK送信のための位置を示す。別の実施形態では、PSSCHのリソースがACK／NACKの位置を示す。
【０１５８】
ブロック496において、宛先モバイルデバイスは、ブロック494において決定されたリソース上でソースモバイルデバイスにACKまたはNACKを送信する。ブロック492においてPSSCHが正しく受信されると、宛先モバイルデバイスはACKを送信する。一方、ブロック492においてPSSCHが正しく受信されなかったとき、宛先モバイルデバイスはNACKを送信する。
【０１５９】
図21は、本開示の特定の実施形態による、宛先モバイルデバイスによって実行される、ACK／NACKを送信するかどうかを判定する例示的な方法500のフローチャートを示す。宛先モバイルデバイスは、D2DのUEであっても、V2Vの車両であってもよい。
【０１６０】
ブロック502において、宛先モバイルデバイスはソースモバイルデバイスからサブフレームを受信する。サブフレームは、グループIDを含む場合があるスケジューリング情報（たとえば、SCI）を含む。ブロック504において、宛先モバイルデバイスはサブフレームからグループIDを抽出する。たとえば、宛先モバイルデバイスは、サブフレームのスケジューリング情報（たとえば、SCI）からグループIDを抽出する。以下でさらに記載されるように、グループIDは、ACK／NACKの送信が適切であるかどうかを判定するために、宛先モバイルデバイスによって使用されてよい。グループIDが記載されているが、本開示は、ACK／NACKの送信が適切であるかどうかを判定するために、スケジューリング情報（たとえば、SCI）の他のフィールド、またはサブフレームの他の部分さえ使用することを想定している。
【０１６１】
ブロック506において、ブロック504において抽出されたグループIDに基づいて、宛先モバイルデバイスは、データパケットがブロードキャストメッセージとして送信されたかどうかを判定する。たとえば、ブロック504において抽出されたグループIDに基づいて、宛先モバイルデバイスは、PSSCHがブロードキャストメッセージであるかどうかを判定する。データパケット（たとえば、PSSCH）がブロードキャストメッセージであると判定することに少なくとも部分的に基づいて、宛先モバイルデバイスはブロック512に進み、データパケット（たとえば、PSSCH）を処理した後にACK／NACKを生成しない。一方、データパケット（たとえば、PSSCH）がブロードキャストメッセージではないと判定することに少なくとも部分的に基づいて、宛先モバイルデバイスはブロック508に進む。
【０１６２】
ブロック508において、メッセージから抽出されたグループIDに基づいて、宛先モバイルデバイスはグループIDリストを更新する。たとえば、宛先モバイルデバイスはグループIDのリストを保持し、グループIDごとに、グループメンバのリストを保持する。ブロック510において、宛先モバイルデバイスは、宛先モバイルデバイスのグループIDが受信メッセージのグループIDと一致するかどうかを判定する。宛先モバイルデバイスのグループIDが受信メッセージのグループIDと一致しないと判定することに少なくとも部分的に基づいて、宛先モバイルデバイスはブロック512に進み、データパケット（たとえば、PSSCH）を処理した後にACK／NACKを生成しない。ブロック510に戻り、宛先モバイルデバイスのグループIDが受信メッセージのグループIDと一致すると判定することに少なくとも部分的に基づいて、宛先モバイルデバイスはブロック514に進む。
【０１６３】
ブロック514において、宛先モバイルデバイスはグループメンバIDを抽出する。ブロック516において、宛先モバイルデバイスは、抽出されたグループメンバIDに基づいてグループメンバIDリストを更新する。ブロック518において、グループメンバIDに少なくとも部分的に基づいて、宛先モバイルデバイスは、メッセージがブロードキャストメッセージであるかどうかを判定する。メッセージがブロードキャストメッセージであると判定することに少なくとも部分的に基づいて、宛先モバイルデバイスはブロック512に進み、データパケット（たとえば、PSSCH）を処理した後にACK／NACKを生成しない。一方、メッセージがブロードキャストメッセージではないと判定することに少なくとも部分的に基づいて、宛先モバイルデバイスはブロック520に進み、データパケット（たとえば、PSSCH）を処理した後にACK／NACKを生成する。言い換えれば、データパケットがグループキャストされると判断すると、宛先モバイルデバイスは、制御リソース（たとえば、PSCCH）上でソースモバイルデバイスによって送信されたスケジューリング情報（たとえば、SCI）によって示されたACK／NACKリソース上でACKまたはNACKをソースモバイルデバイスに送信する。
【０１６４】
特定の一例では、宛先モバイルデバイスは、バイナリで「1111 1111」または16進数で0xFFのグループIDをもつグループに属する。宛先モバイルデバイスは、サブフレームn上で、グループID 0xDE、0xAD、および0xFFのリストを受信する。宛先モバイルデバイスは、0xDE、0xAD、および0xFFでグループIDのリストを更新する。加えて、カウンタ、たとえば、事前に構成されたグループIDカウンタ値が設定される。特定の例として、グループIDごとに、宛先モバイルデバイスは、事前に構成されたグループカウンタ値（たとえば、10）にカウンタを設定する。次のサブフレームn＋1上で、宛先モバイルデバイスはグループID 0xADおよび0xABを受信する。宛先モバイルデバイスは、グループIDのリストに0xABを追加し、0xAB用のカウンタをグループカウンタ値に設定する。加えて、宛先モバイルデバイスは、グループID 0xAD用のカウンタをグループカウンタ値に設定する。リスト内の他のグループID、0xDEおよび0xFFの場合、各カウンタは1つだけデクリメントされる。カウンタがゼロの値に達すると、グループIDがリストから削除される。これにより、グループIDの再利用が可能になる。
【０１６５】
サブフレームnでは、特定のグループ0xFFについて、宛先モバイルデバイスは同様の方式でグループメンバのリストを更新する。受信されたグループメンバIDごとに、そのグループメンバIDがリスト上にまだないとき、リストはそのグループメンバIDによって増強されてよい。加えて、カウンタ、たとえば、事前に構成されたグループメンバカウンタ値が設定される。リスト上の他のグループメンバIDの場合、各カウンタはそのサブフレーム内で1つだけデクリメントされる。カウンタがゼロに達すると、グループメンバIDがグループメンバIDリストから削除される。リストの長さは、宛先モバイルデバイスがグループ用のソースモバイルデバイスとして機能しているときに予想されるACKの数を示すことができる。宛先モバイルデバイスがグループメンバIDをもたないとき、宛先モバイルデバイスは、たとえば、擬似ランダムに未使用のグループメンバIDを選択することができる。
【０１６６】
宛先モバイルデバイスはまた、スケジューリング情報（たとえば、PSCCH）またはデータパケット（たとえば、PSSCH）の受信電力に注意してよい。PSCCHの送信電力が知られているとき、ACK／NACK応答用の送信電力は、上述されたように、オープンループ技法を使用して選択されてよい。たとえば、推定経路損失は、受信電力から送信電力を引いたものに関連する。オープンループ技法は、PSCCHまたはPSSCHが占有するPRBの数を使用してもよい。
【０１６７】
図22は、本開示の特定の実施形態による、ソースモバイルデバイスによって実行される、ACK／NACKに反応する例示的な方法530のフローチャートを示す。たとえば、ソースモバイルデバイスはPSHICHを受信することに反応してよい。ブロック532において、ソースモバイルデバイスは、（たとえば、ACK／NACKプール内の）ACK／NACKリソース上でACK／NACKを受信する。ブロック534において、ソースモバイルデバイスは、たとえば、拡張／カバーコードおよびACK／NACKの位置を処理することにより、ACKおよびNACKを送信した宛先モバイルデバイスの識別情報を特定するために、ACK／NACK送信用のACK／NACKプールを調査する。
【０１６８】
ブロック536において、ソースモバイルデバイスはグループ管理を実行する。特定の実施形態では、ソースモバイルデバイスは、グループの一部であるモバイルデバイス用のグループメンバIDカウンタをデクリメントする。検出されたACK／NACKごとに、ソースモバイルデバイスはメンバID yを決定する。ID yがグループメンバIDリスト上にすでにあるとき、ソースモバイルデバイスはグループメンバID用のカウンタをリセットする。ID yがグループメンバIDリストにまだないとき、ソースモバイルデバイスはグループメンバIDのリストにID yを追加し、グループ用のカウンタをリセットする。ソースモバイルデバイスはまた、ACK／NACK応答をログに記録する。グループメンバカウンタがゼロに達すると、ソースモバイルデバイスは、対応するモバイルデバイスをリストから削除する。受信されたACK／NACKの数が、予想された数、たとえば非ゼロ値のカウンタをもつモバイルデバイスの数よりも少ないとき、ソースモバイルデバイスは、再送信カウンタに達していないとき、メッセージ（たとえば、PSSCH上のデータパケット）を再送信してよい。再送信カウンタに達すると、ソースモバイルデバイスは、MCS、電力レベル、使用されるリソース、および／または他の適切な特性などの送信特性を変更することができるので、今後の送信が確実に受信される。予想された数のACK／NACKが受信されると、ソースモバイルデバイスは、今後の送信に、より高いMCSレベル、より少ない電力、またはより少ないリソースを使用してよい。
【０１６９】
ブロック538において、ソースモバイルデバイスは、ソースモバイルデバイスが基地局のカバレージエリア内にあるときに、送信品質を示すレポートを基地局（たとえば、eNB）に送信する。
【０１７０】
表5は、基地局に送信品質を報告するために、ソースモバイルデバイスによってサイドリンクチャネル品質用の2ビットインジケータ（b1 b0）が使用される実施形態を示す。00の値はチャネル品質が不十分なNACKを示す。ソースモバイルデバイスは適切な場合再送信する。加えて、ソースモバイルデバイスは、今後の送信のために電力を上げ、MCSを低下させる。01の値はACKを示すが、チャネル品質は不十分である。今後の送信のために、より多くの電力が使用されてよい。10の値はチャネル品質が良好なNACKを示す。ソースモバイルデバイスは適切な場合再送信する。より攻撃的でないMCSが使用されてよい。11の値はチャネル品質が良好なACKを示す。今後の送信のために、より攻撃的なMCSまたはより低い電力が使用されてよい。
【０１７１】
【表５】
0006952871.tif 000014
【０１７２】
FDMの動作は対称であっても、非対称であってもよい。対称動作では、パケット送信と確認応答（ACK／NACK）との間に1対1の対応関係が存在する。送信されたパケットごとに、ACK／NACKリソースプール内のリソースがACK／NACKを送信するために割り当てられる。ACK／NACKを受信するために、ソースモバイルデバイスは、ACK／NACKを受信することを予想する時点で他のパケット送信をスケジュールせず、それによってソースモバイルデバイスが制約される。
【０１７３】
一実施形態では、ACK／NACKプール用の専用リソースを使用するので、専用リソースの時点において、データまたはSCIの送信はスケジュールされない。たとえば、サブフレームの最後のシンボルは、データまたはSCIの送信なしに、ACK／NACK送信用に予約されてよい。そのシンボルの周囲のガード時間が使用されてよい。
【０１７４】
図23は、本開示の特定の実施形態による、例示的なフレーム多重化構造420を示す。詳細には、図23は、ACK／NACK426内のACK／NACK用の専用時間スロット（シンボル）用の実施形態の多重化構造を有するフレーム420を示す。フレーム420は制御領域422およびデータ領域424を含む。
【０１７５】
別の実施形態では、ACK／NACK送信に多重化ルールが使用されるので、非対称動作におけるように、ACK／NACKは同時に送信される。
【０１７６】
非対称動作では、パケット送信と確認応答との間に1対1の対応関係は存在してもよく、存在しなくてもよい。ACK／NACKリソースプール内は、SCIリソース内よりもリソースが少ない。所与のACK／NACKリソースは、複数のパケットに確認応答することができる。一実施形態では、多重化ルールが使用されてよい。ACK／NACKは、対応するパケットが受信された順序で送信されてよい。しかしながら、これにより、たとえば、対応するSCIが受信されていないためにパケットが受信されず、宛先モバイルデバイスがそのパケットに確認応答していないときに混乱が生じる可能性があり、他のパケットに対するACK／NACKが誤って多重化されることにつながる。この混乱および誤った多重化を低減または除去するための1つの技法は、宛先モバイルデバイスが復号しようと試みたパケットのパケットIDを送信するための技法である。しかしながら、この技法はオーバーヘッドが高くなる可能性がある。オーバーヘッドを低減するために、ソースモバイルデバイスは、SCI内のパケットごとに短い論理ID、たとえば、3ビットを含んでよい。宛先モバイルデバイスは、ACK／NACKとともに、SCIが受信されたパケット用の論理IDを送信することができる。
【０１７７】
別の実施形態では、ACK／NACKは、LTEのTDMルールと同様のルールを使用して送信されてよい。サブフレームは、たとえば、絶対タイミングに基づいて分割される。
【０１７８】
TDMでは、ACK／NACKリソースよりもさらに多くのデータ／SCIリソースが存在してよく、多重化ルールが使用されてよい。SCIおよび／またはデータのリソースは、たとえば、送信ポイントインデックスを使用して論理的にインデックス付けされてよい。
【０１７９】
データプールのサイズが大きいとき、複数のモバイルデバイスは、同じACK／NACKプール内でACK／NACKを送信する必要があり得、これにより、両方のモバイルデバイスがACK／NACKプール上で同時にリッスンし送信する必要があるので、問題が発生する可能性がある。優先度ルールは、所与のデータプール内でパケットを受信したモバイルデバイスは、同じACK／NACKプール内でACKにつながるいかなるリソース上でも送信することができないと述べている場合がある。別の実施形態では、所与のデータプール内でパケットを受信したモバイルデバイスは、同じデータプール内でまだ送信することができるが、その送信をスケジュールするため、または別のSCI内のいずれかで、SCI内でACK／NACKを送信することによって受信されたパケットに確認応答する。そのモバイルデバイスはそのACK／NACKをすでに送信しているので、ACK／NACKリソースプール内で自身のパケットに対するACK／NACKをリッスンすることができる。
【０１８０】
モバイルデバイスが複数のキャリア上で送信することができるときのACK／NACKの利用にはいくつかのオプションがある。モバイルデバイスは、アンカーキャリア上でACK／NACKを送信してよく、複数のキャリアに多重化ルールが使用される。多重化ルールは、LTEにおけるPUCCHフォーマット3用の多重化ルールと同様であってよい。別の実施形態では、パケットは、それが受信された同じキャリア上で確認応答される。たとえば、キャリアA上で受信されたパケットはキャリアA上で確認応答される。これは、同時に複数のキャリア上での送信を含むが、異なるデバイスが異なるキャリア構成をもつことを可能にする。
【０１８１】
図24は、本開示の特定の実施形態による、例示的な処理システム600のブロック図を示す。処理システム600は、本開示に記載された方法を実行するように構成されてよく、ホストデバイスにインストールされてよい。図示されたように、処理システム600は、図24に示されたように配置されてよい（または配置されなくてよい）、プロセッサ604、メモリ606、およびインターフェース610〜614を含む。プロセッサ604は、計算および／または他の処理に関連するタスクを実行するように適合された任意の構成要素または構成要素の集合であってよく、メモリ606は、プロセッサ604による実行用のプログラミングおよび／または命令を記憶するように適合された任意の構成要素または構成要素の集合であってよい。一実施形態では、メモリ606は非一時的コンピュータ可読媒体を含む。コンピュータ可読非一時的媒体は、磁気記憶媒体、光記憶媒体、および半導体記憶媒体を含むすべてのタイプのコンピュータ可読媒体を含み、詳細には信号を除外する。ソフトウェアはデバイスにインストールされ、デバイスとともに販売できることを理解されたい。あるいは、ソフトウェアは、ディスク媒体を介して、または、たとえばソフトウェア作成者が所有するサーバから、もしくはソフトウェア作成者が所有していないが使用するサーバからを含む、任意の方式のネットワークもしくは分配システムから、ソフトウェアを取得することを含む、取得することができるか、またはデバイスにロードすることができる。ソフトウェアは、たとえば、インターネット上の配布用のサーバに記憶することができる。
【０１８２】
いくつかの実施形態では、処理システム600は、電気通信ネットワークにアクセスするか、またはそうでない場合その一部であるネットワークデバイス内に含まれる。一例では、処理システム600は、基地局、中継局、スケジューラ、コントローラ、ゲートウェイ、ルータ、アプリケーションサーバ、または電気通信ネットワーク内の任意の他のデバイスなどの、ワイヤレスまたは有線の電気通信ネットワーク内のネットワーク側デバイス内にある。他の実施形態では、処理システム600は、移動局、ユーザ機器（UE）、パーソナルコンピュータ（PC）、タブレット、ウェアラブル通信デバイス（たとえば、スマートウォッチなど）、または電気通信ネットワークにアクセスするように適合された任意の他のデバイスなどの、ワイヤレスまたは有線の電気通信ネットワークにアクセスするユーザ側デバイス内にある。
【０１８３】
図25は、本開示の特定の実施形態による、例示的なトランシーバ700のブロック図を示す。トランシーバ700は、電気通信ネットワークを介して信号を送受信するように適合される。いくつかの実施形態では、図25に示され、図25を参照して記載されたインターフェース610、612、614のうちの1つまたは複数は、電気通信ネットワークを介してシグナリングを送受信するように適合されたトランシーバ（たとえば、トランシーバ700）に処理システム600を接続する。トランシーバ700はホストデバイスにインストールされてよい。図示されたように、トランシーバ700は、ネットワーク側インターフェース702、カプラ704、送信機706、受信機708、信号プロセッサ710、およびデバイス側インターフェース712を備える。ネットワーク側インターフェース702は、ワイヤレスまたは有線の電気通信ネットワークを介してシグナリングを送信または受信するように適合された任意の構成要素または構成要素の集合を含んでよい。カプラ704は、ネットワーク側インターフェース702を介する双方向通信を容易にするように適合された任意の構成要素または構成要素の集合を含んでよい。送信機706は、ベースバンド信号を、ネットワーク側インターフェース702を介する送信に適した変調キャリア信号に変換するように適合された任意の構成要素または構成要素の集合（たとえば、アップコンバータ、電力増幅器など）を含んでよい。受信機708は、ネットワーク側インターフェース702を介して受信されたキャリア信号をベースバンド信号に変換するように適合された任意の構成要素または構成要素の集合（たとえば、ダウンコンバータ、低雑音増幅器など）を含んでよい。信号プロセッサ710は、ベースバンド信号を、デバイス側インターフェース712を介する通信に適したデータ信号に、またはその逆に変換するように適合された任意の構成要素または構成要素の集合を含んでよい。デバイス側インターフェース712は、信号プロセッサ710とホストデバイス内の構成要素（たとえば、処理システム600、ローカルエリアネットワーク（LAN）ポートなど）との間でデータ信号を通信するように適合された任意の構成要素または構成要素の集合を含んでよい。
【０１８４】
トランシーバ700は、任意のタイプの通信媒体を介してシグナリングを送受信することができる。いくつかの実施形態では、トランシーバ700は、ワイヤレス媒体を介してシグナリングを送受信する。たとえば、トランシーバ700は、セルラープロトコル（たとえば、ロングタームエボリューション（LTE）など）、ワイヤレスローカルエリアネットワーク（WLAN）プロトコル（たとえば、Wi−Fiなど）、または任意の他のタイプのワイヤレスプロトコル（たとえば、Bluetooth(登録商標)、近距離無線通信（NFC）など）などのワイヤレス電気通信プロトコルに従って通信するように適合されたワイヤレストランシーバであってよい。そのような実施形態では、ネットワーク側インターフェース702は、1つまたは複数のアンテナ／放射素子を備える。たとえば、ネットワーク側インターフェース702は、単一のアンテナ、複数の個別アンテナ、または、マルチレイヤ通信、たとえば、単一入力複数出力（SIMO）、複数入力単一出力（MISO）、複数入力複数出力（MIMO）など向けに構成されたマルチアンテナアレイを含んでよい。他の実施形態では、トランシーバ700は、有線媒体、たとえば、ツイストペアケーブル、同軸ケーブル、光ファイバなどを介してシグナリングを送受信する。特定の処理システムおよび／またはトランシーバは、示された構成要素のすべて、または構成要素のサブセットのみを利用することができ、一体化レベルはデバイスごとに異なってよい。
【０１８５】
本開示は様々な実施形態とともに記載されている。しかしながら、開示された実施形態に対する他の変形および修正は、図面、開示、および添付の特許請求の範囲の研究から理解および達成することができ、そのような変形および修正は、添付の特許請求の範囲に包含されると解釈されるべきである。特許請求の範囲において、「備える」という単語は他の要素またはステップを排除せず、不定冠詞「a」または「an」は複数を排除しない。単一のプロセッサまたは他のユニットが、特許請求の範囲に列挙されたいくつかの項目の機能を実現してもよい。特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これらの手段の組合せが有利に使用できないことを示すか、排除するか、または示唆するものではない。コンピュータプログラムは、他のハードウェアと一緒に、または他のハードウェアの一部として供給される光記憶媒体または半導体媒体などの適切な媒体上に記憶または分散されてよいが、インターネットまたは他の有線もしくはワイヤレスの通信システムなどを介して、他の形態で分散されてもよい。
【符号の説明】
【０１８６】
100  ワイヤレスネットワーク
102  基地局
104  モバイルデバイス
105  モバイルデバイス
106  カバレージエリア
108  バックホールネットワーク
112  車両
114  車両
116  車両
122  路側ユニット（RSU）
124  車両
144  PRBペア
146  DLフレーム
148  UL／SLフレーム
152  物理ダウンリンク制御チャネル（PDCCH）
154  物理ダウンリンク共有チャネル（PDSCH）
158  物理アップリンク共有チャネル（PUSCH）
160  物理サイドリンク共有チャネル（PSSCH）
162  物理サイドリンク制御チャネル（PSCCH）
164  物理アップリンク制御チャネル（PUCCH）
172  送信プール（Tx）プール
174  受信プール（Rx）プール
202  車両
204  車両
206  車両
210  小隊
212  車両
214  車両
216  車両
220  小隊
222  車両
224  車両
242  基地局
244  カバレージエリア
246  車両
248  車両
250  車両
260  メッセージ図
262  ソース車両
264  宛先車両
266  メッセージ
268  メッセージ
272  車両
274  車両
276  車両
280  サブフレーム
282  PSSCH
284  PSCCH
300  サブフレーム
302  PSSCH
304  PSCCH
306  PSSCH
308  PSCCH
312  データ領域
314  制御領域
322  制御領域
324  データ領域
330  サブフレーム
332  サブフレーム
334  サブフレーム
336  サブフレーム
338  サブフレーム
342  シーケンス
344  シーケンス
346  サブフレーム
348  サブフレーム
350  シンボルシーケンス
352  シンボル
354  データシンボル
356  予約シンボル
358  予約シンボル
360  V2Vサブフレームレイアウト
362  DMRSシンボル
364  位置
366  位置
368  位置
369  位置
370  フレーム構造
372  データ領域
374  ACK／NACKプール
376  制御領域
380  フレーム構造
382  ACK／NACKプール
384  データ領域
386  制御領域
390  フレーム構造
392  データ領域
394  ACK／NACKプール
396  制御領域
400  フレーム構造
402  制御領域
404  ACK／NACKプール
406  データ領域
410  フレーム構造
412  制御領域
414  ACK／NACKプール
416  データ領域
420  フレーム多重化構造
422  制御領域
424  データ領域
426  ACK／NACK
430  方法
450  方法
470  方法
490  方法
500  方法
530  方法
600  処理システム
604  プロセッサ
606  メモリ
610  インターフェース
612  インターフェース
614  インターフェース
700  トランシーバ
702  ネットワーク側インターフェース
704  カプラ
706  送信機
708  受信機
710  信号プロセッサ
712  デバイス側インターフェース
【図１】
0006952871.tif 000015
【図２Ａ】
0006952871.tif 000016
【図２Ｂ】
0006952871.tif 000017
【図２Ｃ】
0006952871.tif 000018
【図３Ａ】
0006952871.tif 000019
【図３Ｂ】
0006952871.tif 000020
【図３Ｃ】
0006952871.tif 000021
【図４】
0006952871.tif 000022
【図５】
0006952871.tif 000023
【図６】
0006952871.tif 000024
【図７】
0006952871.tif 000025
【図８】
0006952871.tif 000026
【図９】
0006952871.tif 000027
【図１０】
0006952871.tif 000028
【図１１Ａ】
0006952871.tif 000029
【図１１Ｂ】
0006952871.tif 000030
【図１２Ａ】
0006952871.tif 000031
【図１２Ｂ】
0006952871.tif 000032
【図１３Ａ】
0006952871.tif 000033
【図１３Ｂ】
0006952871.tif 000034
【図１４】
0006952871.tif 000035
【図１５】
0006952871.tif 000036
【図１６】
0006952871.tif 000037
【図１７Ａ】
0006952871.tif 000038
【図１７Ｂ】
0006952871.tif 000039
【図１８Ａ】
0006952871.tif 000040
【図１８Ｂ】
0006952871.tif 000041
【図１９】
0006952871.tif 000042
【図２０】
0006952871.tif 000043
【図２１】
0006952871.tif 000044
【図２２】
0006952871.tif 000045
【図２３】
0006952871.tif 000046
【図２４】
0006952871.tif 000047
【図２５】
0006952871.tif 000048