JP2023546231A - サイドリンク通信方法および装置 - Google Patents

Abstract

本出願の実施形態は、サイドリンク通信方法および装置を提供する。方法は以下を含む：第１の端末デバイス（送信側）が、送信されるべき第１のデータまたは第１のシグナリングを有するとき、第１の端末デバイスは、まず、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを決定する。第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするとき、第１の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを取得し、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを使用することによって第１のデータまたは第１のシグナリングを送信する。第１のデータまたは第１のシグナリングを送信するために送信側によって使用されるＳＬリソースは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであり、受信側端末デバイスもまた、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で第１のデータまたは第１のシグナリングを受信する。したがって、受信側端末デバイスが、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする第１のデータまたは第１のシグナリングを正常に受信することができることが保証され、それによって、ＳＬ通信品質を向上させることができる。

Description

本出願は、通信技術に関し、特に、サイドリンク通信方法および装置に関する。

ユーザ機器（user equipment、ＵＥ）は、ネットワークを通じて互いに通信してもよいし、互いに直接通信してもよい。ＵＥ間の直接通信は、サイドリンク（sidelink、ＳＬ）通信とも呼ばれる。ＳＬ通信では、ＰＣ５エアインターフェースを介して２つのＵＥ間でデータが送信される。ＳＬ通信の典型的な適用例は、車車間・路車間（vehicle to everything、Ｖ２Ｘ）シナリオである。Ｖ２Ｘシナリオでは、１つの車両が１つのＵＥである。

ＳＬ通信のプロセスにおいて、ＵＥの電力消費を低減するために、送信側ＵＥまたは受信側ＵＥは、間欠受信（discontinuous reception、ＤＲＸ）メカニズムを使用し得る。ＤＲＸメカニズムとは、ＵＥが、送信または受信されるべきデータを有していないとき、ＵＥが、ある時間期間において送信機または受信機をオフにして、電力消費を低減することを意味する。ＤＲＸサイクルは、アクティブ時間（active time）およびスリープ時間（または非アクティブ時間と呼ばれる）を含む。ＵＥは、アクティブ時間にデータを送信または受信し、スリープ時間ではデータを送信または受信しない。従来技術では、ＵＥは、ユニキャスト方式に基づいてＳＬ ＤＲＸをサポートし得、ならびに／またはブロードキャスト方式およびマルチキャスト方式に基づいてＳＬ ＤＲＸをサポートし得る。

しかしながら、送信側ＵＥが、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを送信するとき、送信側ＵＥによって使用されるＳＬ送信リソースは、ブロードキャストおよびマルチキャストＳＬ ＤＲＸ状態にある受信側ＵＥによって使用されるＳＬ受信リソースに対応しないことがある。その結果、受信側ＵＥは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを受信することができず、ＳＬ通信の品質が影響を受ける。

本出願の実施形態は、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするサービスまたはシグナリングの欠落を回避し、ＳＬ通信の品質を向上させるためのサイドリンク通信方法および装置を提供する。

本出願の第１の態様は、第１の端末デバイスに適用されるサイドリンク通信方法を提供する。方法は、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定するステップであって、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである、ステップと、第１のＳＬリソースを取得するステップであって、第１のＳＬリソースは、第１のＤＲＸに対応するＳＬリソースである、ステップと、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信するステップとを含む。マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする対応するデータまたはシグナリングを送信するとき、端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースを取得し、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースを使用することによってデータまたはシグナリングを送信する。送信側によって使用される送信リソースと受信側によって使用される受信リソースの両方がマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであるので、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする対応するデータまたはシグナリングが受信側によって正常に受信されることが保証され、それによって、ＳＬ通信の品質を向上させることができる。

例示的な方式では、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定するステップは、アクセス層が上位層から第１の指示情報を受信し、第１の指示情報は、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示すことを含む。

例示的な方式では、第１の指示情報は、第１のデータに関連付けられたサービスまたはサービス品質（ＱｏＳ）フローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを含む。

例示的な方式では、第１のＳＬリソースを取得するステップは、第１の要求メッセージをネットワークデバイスに送信するステップであって、第１の要求メッセージは、第１のＳＬリソースを要求するためのものである、ステップと、ネットワークデバイスによって送信された第１のＳＬリソースに関する情報を受信するステップとを含む。

任意選択で、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

代替的に、第１の端末デバイスが第１の要求メッセージをネットワークデバイスに送信する前に、第１の端末デバイスは、第２の指示情報をネットワークデバイスに送信し、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである。

第１の要求メッセージが、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであるとき、任意選択で、第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される。

例示的な方式では、第１の要求メッセージは、専用ＳＬ ＳＲであり、第１のＳＬリソースは、専用ＳＬ ＳＲに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

別の例示的な方式では、第１の要求メッセージが専用ＳＬ ＳＲであるとき、第１の端末デバイスが専用ＳＬ ＳＲをネットワークデバイスに送信する前に、第１の端末デバイスは、ＳＵＩメッセージをネットワークデバイスに送信し、ＳＵＩメッセージは第２の指示情報を含み、第１の端末デバイスは、ネットワークデバイスによって構成された専用ＳＬ ＳＲを受信する。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＳＲであるとき、ＳＬ ＳＲは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、第１の端末デバイスは、専用ＬＣＧまたは専用宛先アドレスインデックスを使用することによって、ＳＬ ＢＳＲをネットワークデバイスに送信する。第１のＳＬリソースは、専用ＬＣＧもしくは専用宛先アドレスインデックスに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられるか、またはプロトコルにおいて予め定義される。

別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、第１の端末デバイスが専用ＬＣＧまたは専用宛先アドレスインデックスを使用することによってＳＬ ＢＳＲをネットワークデバイスに送信する前に、第１の端末デバイスは、ＳＵＩメッセージをネットワークデバイスに送信し、ＳＵＩメッセージは第２の指示情報を含み、第１の端末デバイスは、ネットワークデバイスによって送信された、専用ＬＣＧまたは専用宛先アドレスインデックスの構成情報を受信し、専用ＬＣＧまたは専用宛先アドレスインデックスは、第２の指示情報に基づいてネットワークデバイスによって構成される。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲをネットワークデバイスに送信する前に、第１の端末デバイスは、ＳＵＩをネットワークデバイスに送信し、ＳＵＩは第２の指示情報を含む。

さらに別の例示的な方式では、第１の要求メッセージは、特定のフォーマットのＳＬ ＢＳＲであり、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。第１のＳＬリソースは、ＳＬ ＢＳＲのフォーマットに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

別の例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージをネットワークデバイスに送信する前に、第１の端末デバイスは、ＳＵＩメッセージをネットワークデバイスに送信し、ＳＵＩメッセージは第２の指示情報を含む。第１のＳＬリソースは、半永続的スケジューリング（ＳＰＳ）リソースであり、第１のＳＬリソースは、第２の指示情報およびＵＡＩメッセージに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５ ＲＲＣ再構成メッセージのうちの１つまたは複数のシグナリングを含む。

別の例示的な方式では、第１の端末デバイスが第１のサイドリンク（ＳＬ）リソースを取得することは、第１の端末デバイスが、アイドルＳＬリソースを測定することによって第１のＳＬリソースを取得することを含む。

例示的な方式では、第１の端末デバイスが第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信することは、第１の端末デバイスが、送信されるべき宛先アドレスから、第１のデータまたは第１のシグナリングに対応する宛先アドレスのみを、送信のための宛先アドレスとして選択するか、または優先的に選択することを含む。

第１のデータまたは第１のシグナリングに対応する宛先アドレスのみが、送信のために、送信されるべき宛先アドレスから選択されるか、または優先的に選択されるので、第１のデータまたは第１のシグナリングが優先的に送信されることが保証され、それによって、ＬＣＰによる第１のデータもしくは第１のシグナリングの送信遅延または破棄を回避することができる。

別の例示的な方式では、第１の端末デバイスが第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信することは、第１の端末デバイスが、送信されるべき論理チャネルから、第１のデータまたは第１のシグナリングに対応する論理チャネルのみを、送信のための論理チャネルとして選択するか、または優先的に選択することを含む。

第１のデータまたは第１のシグナリングに対応する論理チャネルのみが、送信のために、送信されるべき論理チャネルから選択されるか、または優先的に選択されるので、第１のデータまたは第１のシグナリングが優先的に送信されることが保証され、それによって、ＬＣＰによる第１のデータもしくは第１のシグナリングの送信遅延または破棄を回避することができる。

本出願の第２の態様は、ネットワークデバイスに適用されるサイドリンク通信方法を提供する。方法は、第１の端末デバイスによって送信された第１の要求メッセージを受信するステップであって、第１の要求メッセージは、第１のサイドリンク（ＳＬ）リソースを要求するためのものであり、第１のＳＬリソースは、第１の間欠受信（ＤＲＸ）に対応するＳＬリソースであり、第１のＤＲＸは、マルチキャストまたはブロードキャストＤＲＸである、ステップと、第１の要求メッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるステップとを含む。送信側は、第１の要求メッセージを送信することによって、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースをネットワークデバイスに要求し、ネットワークデバイスは、第１の要求メッセージに基づいて、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースを送信側に割り当てる。送信側によって使用される送信リソースおよび受信側によって使用される受信リソースの両方がマルチキャストまたはブロードキャストに対応するＳＬリソースであるので、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングが受信側によって正常に受信されることが保証され、それによって、ＳＬ通信の品質を向上させることができる。

例示的な方式では、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

例示的な方式では、ネットワークデバイスが第１の端末デバイスによって送信された第１の要求メッセージを受信する前に、方法は、ネットワークデバイスが第１の端末デバイスによって送信された第２の指示情報を受信することをさらに含み、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであり、第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される。

例示的な方式では、第１の要求メッセージは、専用ＳＬ ＳＲであり、専用ＳＬ ＳＲは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを要求するためのものであり、ネットワークデバイスは、専用ＳＬ ＳＲに基づいて、ＳＬ ＳＲによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

別の例示的な方式では、ネットワークデバイスが専用ＳＬ ＳＲを受信する前に、ネットワークデバイスは、第１の端末デバイスによって送信されたＳＵＩメッセージを受信し、ＳＵＩメッセージは第２の指示情報を含み、ネットワークデバイスは、第２の指示情報に基づいて第１の端末デバイスのための専用ＳＬ ＳＲを構成する。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＳＲであるとき、ＳＬ ＳＲは第２の指示情報を含み、ネットワークデバイスは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは、専用ＬＣＧまたは専用宛先アドレスインデックスを使用することによって、第１の端末デバイスによってネットワークデバイスに送信される。ネットワークデバイスは、専用ＬＣＧまたは専用宛先アドレスインデックスに基づいて、ＳＬ ＢＳＲによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ネットワークデバイスがＳＬ ＢＳＲを受信する前に、ネットワークデバイスは、第１の端末デバイスによって送信されたＳＵＩメッセージを受信し、ＳＵＩメッセージは第２の指示情報を含み、第１の端末デバイスは、第２の指示情報に基づいてＳＬ ＢＳＲのための専用ＬＣＧまたは専用宛先アドレスインデックスを構成する。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは第２の指示情報を含む。ネットワークデバイスは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ネットワークデバイスがＳＬ ＢＳＲを受信する前に、ネットワークデバイスは、第１の端末デバイスによって送信されたＳＵＩメッセージを受信し、ＳＵＩは第２の指示情報を含み、ネットワークデバイスは、第２の指示情報およびＳＬ ＢＳＲに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

さらに別の例示的な方式では、第１の要求メッセージは、特定のフォーマットのＳＬ ＢＳＲであり、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。ネットワークデバイスは、ＳＬ ＢＳＲのフォーマットに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージは第２の指示情報を含む。ネットワークデバイスは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

別の例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージを受信する前に、ネットワークデバイスは、第１のネットワークデバイスによって送信されたＳＵＩメッセージを受信し、ＳＵＩメッセージは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報およびＵＡＩメッセージに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられた第１のＳＬリソースであり、第１のＳＬリソースは、半永続的スケジューリング（ＳＰＳ）リソースである。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む。

本出願の第３の態様は、サイドリンク通信方法を提供する。アクセス層は、上位層から第１の指示情報を受信することであって、第１の指示情報は、第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすることを示し、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである、受信することと、第１の指示情報に基づいて、現在受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートすると決定されたとき、第１のＤＲＸをアクティブ化することとを行う。

本出願の第４の態様は、第２の端末デバイスに適用されるサイドリンク通信方法を提供し、方法は、第１の時点において第１の間欠受信（ＤＲＸ）を非アクティブ化するステップであって、第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸであり、第１の時点は、ＳＬユニキャスト接続確立メッセージの受信時点または発見要求メッセージの受信時点である、ステップと、第２の時点において第１のＤＲＸをアクティブ化するステップであって、第２の時点は、ＳＬユニキャスト接続確立受諾メッセージの受信時点、第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である、ステップとを含む。

方法において、受信側端末デバイスは、第１の時点と第２の時点との間で第１のＤＲＸを無効にする。第１のＤＲＸを無効にすることは、受信側端末デバイスが、通常のＳＬリソースに対応するすべての時間期間においてデータを受信することを意味するものであり、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上でのみデータを受信することに限定されない。したがって、受信側端末デバイスが、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするシグナリングまたはデータを正常に受信することが保証され、それによって、ＳＬ通信の品質を向上させることができる。

例示的な方式では、端末デバイスは、第１の時点に第１のタイマを開始する。

例示的な方式では、端末デバイスが第１の時点に第１のＤＲＸを非アクティブ化することは、以下を含む：
端末デバイスが、第１の時点においてプリセット時間が遅延した後に第１のＤＲＸを非アクティブ化すること。

本出願の第５の態様は、第２の端末デバイスに適用されるサイドリンク通信方法を提供し、方法は、第１の端末デバイスによって送信されたＳＣＩを受信するステップと、第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸ状態にあり、ＳＣＩによって示されるＴＢに対応するリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに属さないかまたは部分的に属するとき、ＳＣＩによって示されるＴＢの受信をスキップするか、またはＳＣＩによって示されるＴＢを受信するが、ＳＣＩに対応するＨＡＲＱ ＲＴＴタイマまたは非アクティビティタイマの開始をスキップするステップとを含む。

この実施形態では、第２の端末デバイスがＳＣＩを受信した後、ＳＣＩによって示されるＴＢに対応するＨＡＲＱ ＴＴＴタイマまたはＩＮＡＣＴＩＶＩＴＹタイマが開始されないので、対応する再送データの後続の受信を回避することができ、それによって、端末デバイスのエネルギー消費を低減する。

本出願の第６の態様は、以下を含む第１の端末デバイスを提供する：
第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすると決定するように構成された決定モジュールであって、第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸである、決定モジュール；
第１のＳＬリソースを取得するように構成された取得モジュールであって、第１のＳＬリソースは、第１のＤＲＸに対応するＳＬリソースである、取得モジュール；および
第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信するように構成された送信モジュール。

例示的な方式では、決定モジュールは、第１の端末デバイスの上位層から第１の指示情報を受信するように特に構成され、第１の指示情報は、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示す。

例示的な方式では、第１の指示情報は、第１のデータに関連付けられたサービスまたはサービス品質（ＱｏＳ）フローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを含む。

例示的な方式では、取得モジュールは、第１の要求メッセージをネットワークデバイスに送信することであって、第１の要求メッセージは、第１のＳＬリソースを要求するためのものある、送信することと、ネットワークデバイスによって送信された第１のＳＬリソースに関する情報を受信することとを行うように特に構成される。

任意選択で、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

代替的に、取得モジュールは、第１の要求メッセージをネットワークデバイスに送信する前に、第２の指示情報をネットワークデバイスに送信するようにさらに構成され、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである。

第１の要求メッセージが、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであるとき、任意選択で、第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される。

例示的な方式では、第１の要求メッセージは、専用ＳＬ ＳＲであり、第１のＳＬリソースは、専用ＳＬ ＢＳＲに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

別の例示的な方式では、第１の要求メッセージが専用ＳＬ ＳＲであるとき、取得モジュールが専用ＳＬ ＳＲをネットワークデバイスに送信する前に、取得モジュールは、ＳＵＩメッセージをネットワークデバイスに送信し、ＳＵＩメッセージは第２の指示情報を含み、取得モジュールは、ネットワークデバイスによって構成された専用ＳＬ ＳＲを受信する。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＳＲであるとき、ＳＬ ＳＲは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、取得モジュールは、専用ＬＣＧまたは専用宛先アドレスインデックスを使用することによって、ＳＬ ＢＳＲをネットワークデバイスに送信するように特に構成される。第１のＳＬリソースは、専用ＬＣＧもしくは専用宛先アドレスインデックスに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられるか、またはプロトコルにおいて予め定義される。

別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、専用ＬＣＧまたは専用宛先アドレスを使用することによってＳＬ ＢＳＲをネットワークデバイスに送信する前に、取得モジュールは、第２の指示情報を含むＳＵＩメッセージをネットワークデバイスに送信し、ネットワークデバイスによって送信された、専用ＬＣＧまたは専用宛先アドレスインデックスの構成情報を受信し、専用ＬＣＧまたは専用宛先アドレスインデックスは、第２の指示情報に基づいてネットワークデバイスによって構成される。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲをネットワークデバイスに送信する前に、取得モジュールは、ＳＵＩをネットワークデバイスに送信し、ＳＵＩは第２の指示情報を含む。

さらに別の例示的な方式では、第１の要求メッセージが特定のフォーマットのＳＬ ＢＳＲであるとき、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。第１のＳＬリソースは、ＳＬ ＢＳＲのフォーマットに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

別の例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージをネットワークデバイスに送信する前に、取得モジュールは、ＳＵＩメッセージをネットワークデバイスに送信し、ＳＵＩメッセージは第２の指示情報を含む。第１のＳＬリソースは、半永続的スケジューリング（ＳＰＳ）リソースであり、第１のＳＬリソースは、第２の指示情報およびＵＡＩメッセージに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む。

別の例示的な方式では、取得モジュールは、アイドルＳＬリソースを測定することによって第１のＳＬリソースを取得するように特に構成される。

例示的な方式では、送信モジュールは、送信されるべき宛先アドレスから、第１のデータまたは第１のシグナリングに対応する宛先アドレスのみを、送信のための宛先アドレスとして選択するか、または優先的に選択するように特に構成される。

別の例示的な方式では、送信モジュールは、送信されるべき論理チャネルから、第１のデータまたは第１のシグナリングに対応する論理チャネルのみを、送信のための論理チャネルとして選択するか、または優先的に選択するように特に構成される。

本出願の第６の態様および実装形態において提供される第１の端末デバイスは、本出願の第１の態様および実装形態において提供される方法を実行するように構成され得る。技術的効果は同様であり、詳細は本明細書で改めて説明しない。

本出願の第７の態様は、以下を含むネットワークデバイスを提供する：
第１の端末デバイスによって送信された第１の要求メッセージを受信するように構成された受信モジュールであって、第１の要求メッセージは、第１のサイドリンク（ＳＬ）リソースを要求するためのものであり、第１のＳＬリソースは、第１の間欠受信（ＤＲＸ）に対応するＳＬリソースであり、第１のＤＲＸは、マルチキャストまたはブロードキャストＤＲＸである、受信モジュール；および
第１の要求メッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように構成された割り当てモジュール。

例示的な方式では、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

別の例示的な方式では、受信モジュールは、第１の要求メッセージを受信する前に、第１の端末デバイスによって送信された第２の指示情報を受信するようにさらに構成され、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである。

第１の要求メッセージが、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであるとき、任意選択で、第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される。

例示的な方式では、第１の要求メッセージは、専用ＳＬ ＳＲであり、専用ＳＬ ＳＲは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを要求するためのものであり、割り当てモジュールは、専用ＳＬ ＳＲに基づいて、ＳＬ ＳＲによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成される。

別の例示的な方式では、専用ＳＬ ＳＲを受信する前に、受信モジュールは、第１の端末デバイスによって送信されたＳＵＩメッセージをさらに受信し、ＳＵＩメッセージは第２の指示情報を含み、ネットワークデバイスは、第２の指示情報に基づいて第１の端末デバイスのための専用ＳＬ ＳＲを構成するように構成された構成モジュールをさらに含む。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＳＲであるとき、ＳＬ ＳＲは第２の指示情報を含み、割り当てモジュールは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成される。

例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは、専用ＬＣＧまたは専用宛先アドレスインデックスを使用することによって、第１の端末デバイスによってネットワークデバイスに送信される。割り当てモジュールは、専用ＬＣＧまたは専用宛先アドレスインデックスに基づいて、ＳＬ ＢＳＲによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成される。

別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲを受信する前に、受信モジュールは、第１の端末デバイスによって送信されたＳＵＩメッセージをさらに受信し、ＳＵＩメッセージは第２の指示情報を含み、割り当てモジュールは、第２の指示情報およびＳＬ ＢＳＲに基づいて、ＳＬ ＢＳＲのための専用ＬＣＧまたは専用宛先アドレスインデックスを構成するように特に構成される。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは第２の指示情報を含む。ネットワークデバイスは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ネットワークデバイスがＳＬ ＢＳＲを受信する前に、ネットワークデバイスは、第１の端末デバイスによって送信されたＳＵＩメッセージを受信する。ＳＵＩは、第２の指示情報を含む。ネットワークデバイスは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように構成された構成モジュールをさらに含む。

さらに別の例示的な方式では、第１の要求メッセージは、特定のフォーマットのＳＬ ＢＳＲであり、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。割り当てモジュールは、ＳＬ ＢＳＲのフォーマットに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成される。

例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージは第２の指示情報を含む。割り当てモジュールは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成される。

別の例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージを受信する前に、受信モジュールは、第１のネットワークデバイスによって送信されたＳＵＩメッセージを受信し、ＳＵＩメッセージは第２の指示情報を含む。割り当てモジュールは、第２の指示情報およびＵＡＩメッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成され、第１のＳＬリソースは、半永続的スケジューリング（ＳＰＳ）リソースである。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む。

本出願の第７の態様および実装形態において提供されるネットワークデバイスは、本出願の第２の態様および実装形態において提供される方法を実行するように構成され得る。技術的効果は同様であり、詳細は本明細書で改めて説明しない。

本出願の第８の態様は、以下を含む第２の端末デバイスを提供する：
第２の端末デバイスの上位層から第１の指示情報を受信するように構成された受信モジュールであって、第１の指示情報は、第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすることを示し、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである、受信モジュール；
第１の指示情報に基づいて、現在受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートすると決定するように構成された決定モジュール；および
第１のＤＲＸをアクティブ化するように構成されたアクティブ化モジュール。

本出願の第８の態様において提供される第２の端末デバイスは、本出願の第３の態様において提供される方法を実行するように構成され得、技術的効果は同様である。詳細は本明細書で改めて説明しない。

本出願の第９の態様は、以下を含む端末デバイスを提供する：
第１の時点において第１の間欠受信（ＤＲＸ）を非アクティブ化するように構成された非アクティブ化モジュールであって、第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸであり、第１の時点は、ＳＬユニキャスト接続確立メッセージの受信時点または発見要求メッセージの受信時点である、非アクティブ化モジュール；および
第２の時点において第１のＤＲＸをアクティブ化するように構成されたアクティブ化モジュールであって、第２の時点は、ＳＬユニキャスト接続確立受諾メッセージの受信時点、第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である、アクティブ化モジュール。

例示的な方式では、端末デバイスは、第１の時点に第１のタイマを開始する。

例示的な方式では、非アクティブ化モジュールは、第１の時点においてプリセット時間が遅延した後に第１のＤＲＸを非アクティブ化するように特に構成される。

本出願の第８の態様および実装形態において提供される端末デバイスは、本出願の第４の態様および実装形態において提供される方法を実行するように構成され得る。技術的効果は同様であり、詳細は本明細書で改めて説明しない。

本出願の第１０の態様は、以下を含む第２の端末デバイスを提供する：
第１の端末デバイスによって送信されたＳＣＩを受信するように構成された受信モジュール；
受信モジュールは、第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸ状態にあり、ＳＣＩによって示されるＴＢに対応するリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに属さないかまたは部分的に属するとき、ＳＣＩによって示されるＴＢの受信をスキップするか、またはＳＣＩによって示されるＴＢを受信するが、ＳＣＩに対応するＨＡＲＱ ＲＴＴタイマまたは非アクティビティタイマの開始をスキップするようにさらに構成される。

本出願の第１０の態様において提供される第２の端末デバイスは、本出願の第５の態様において提供される方法を実行するように構成され得、技術的効果は同様である。詳細は本明細書で改めて説明しない。

本出願の第１１の態様は、プロセッサと、メモリと、トランシーバとを含む端末デバイスを提供する。メモリは、命令を記憶するように構成される。トランシーバは、別のデバイスと通信するように構成される。プロセッサは、端末デバイスが、本出願の第１の態様、第３の態様、第４の態様、第５の態様、および実装形態において提供される任意の方法を実行することができるように、メモリに記憶された命令を実行するように構成される。

本出願の第１２の態様は、プロセッサと、メモリと、トランシーバとを含むネットワークデバイスを提供する。メモリは、命令を記憶するように構成される。トランシーバは、別のデバイスと通信するように構成される。プロセッサは、ネットワークデバイスが、本出願の第２の態様および実装形態において提供される任意の方法を実行することができるように、メモリに記憶された命令を実行するように構成される。

本出願の第１３の態様は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、命令を記憶する。命令が実行されると、コンピュータは、本出願の第１の態様、第３の態様、第４の態様、第５の態様、および実装形態において提供される任意の方法を実行することが可能になる。

本出願の第１４の態様は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、命令を記憶する。命令が実行されると、コンピュータは、本出願の第２の態様および実装形態において提供される任意の方法を実行することが可能になる。

本出願の第１５の態様は、コンピュータプログラム製品を提供する。コンピュータプログラム製品は、命令を含む。命令が実行されると、コンピュータは、本出願の第１の態様、第３の態様、第４の態様、第５の態様、および実装形態において提供される任意の方法を実行することが可能になる。

本出願の第１６の態様は、コンピュータプログラム製品を提供する。コンピュータプログラム製品は、命令を含む。命令が実行されると、コンピュータは、本出願の第２の態様および実装形態において提供される任意の方法を実行することが可能になる。

本出願の第１７の態様は、第１の端末デバイスと、第２の端末デバイスと、ネットワークデバイスとを含む通信システムを提供する。第１の端末デバイスは、本出願の第１の態様および実装形態において提供される任意の方法を実行するように構成される。第２の端末デバイスは、本出願の第３の態様において提供される方法を実行するように構成される。ネットワークデバイスは、本出願の第２の態様および実装形態において提供される任意の方法を実行するように構成される。

本出願の実施形態において提供されるサイドリンク通信方法および装置によれば、第１の端末デバイス（送信側）が、送信されるべき第１のデータまたは第１のシグナリングを有するとき、第１の端末デバイスは、まず、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを決定する。第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするとき、第１の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを取得し、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを使用することによって第１のデータまたは第１のシグナリングを送信する。第１のデータまたは第１のシグナリングを送信するために送信側によって使用されるＳＬリソースは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであり、受信側端末デバイスもまた、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で第１のデータまたは第１のシグナリングを受信する。したがって、受信側端末デバイスが、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする第１のデータまたは第１のシグナリングを正常に受信することができることが保証され、それによって、ＳＬ通信品質を向上させることができる。

本出願が適用可能なネットワークアーキテクチャの概略図である。 ＳＬ ＤＲＸのユニキャスト接続確立プロセスの概略図である。 マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソースの概略図である。 マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソースの別の概略図である。 本出願の実施形態１によるサイドリンク通信方法のフローチャートである。 本出願の実施形態２によるサイドリンク通信方法のフローチャートである。 本出願の実施形態３によるサイドリンク通信方法のシグナリングのフローチャートである。 本出願の実施形態４によるサイドリンク通信方法のシグナリングのフローチャートである。 本出願の実施形態５によるサイドリンク通信方法のシグナリングのフローチャートである。 端末デバイスのＳＬリソースの概略図である。 端末デバイスがデータを送信する概略図である。 本出願の実施形態６によるサイドリンク通信方法のフローチャートである。 本出願の実施形態７による第１の端末デバイスの構造の概略図である。 本出願の実施形態８によるネットワークデバイスの構造の概略図である。 本出願の実施形態９による第２の端末デバイスの構造の概略図である。 本出願の実施形態１０による第２の端末デバイスの構造の概略図である。 本出願の実施形態１１による端末デバイスの構造の概略図である。

以下では、本出願の実施形態における添付の図面を参照して、本出願の実施形態における技術的解決策を説明する。本出願では、「少なくとも１つの（at least one）」は１つまたは複数を意味し、「複数の（a plurality of）」は２つ以上を意味する。「および／または（and/or）」という用語は、関連するオブジェクト間の関連関係を説明し、３つの関係が存在し得ることを表す。例えば、Ａおよび／またはＢは、Ａのみが存在する場合、ＡとＢの両方が存在する場合、およびＢのみが存在する場合を表し得、ＡおよびＢは、単数または複数とすることができる。文字「／」は、一般に、関連するオブジェクト間の「または」関係を示す。以下の項目（部分）またはその類似表現のうちの少なくとも１つは、単数の項目（部分）または複数の項目（部分）の任意の組み合わせを含む、これらの項目の任意の組み合わせを指す。例えば、ａ、ｂ、またはｃのうちの少なくとも１つ（部分）は、ａ、ｂ、ｃ、ａおよびｂ、ａおよびｃ、ｂおよびｃ、またはａ、ｂ、およびｃを表し得、ａ、ｂ、およびｃは、単数または複数とすることができる。加えて、本出願の実施形態における技術的解決策を明確に説明するために、本出願の実施形態では「第１の」および「第２の」などの用語を使用して、基本的に同じ機能または目的を提供する同じ項目または同様の項目を区別する。当業者は、「第１の」および「第２の」などの用語が量および実行順序を限定しないことを理解し得る。例えば、本出願の実施形態における第１のデバイスの「第１の」および第２のデバイスの「第２の」は、単に異なるデバイスを区別するために使用される。

本出願では、「例えば（for example）」または「など（such as）」という用語は、例、例示、または説明を与えることを表すために使用されることに留意されたい。本出願において「例」または「例えば」として説明される任意の実施形態または設計方式は、別の実施形態または設計方式よりも好ましい、またはより多くの利点を有するものとして説明されるべきではない。正確には、「例えば（for example）」または「例（example）」などの用語の使用は、関連する概念を特定の方法で提示することを意図している。

図１は、本出願が適用可能なネットワークアーキテクチャの概略図である。図１に示すように、ネットワークアーキテクチャは、ネットワークデバイス（例えば、基地局）１１と、第１の端末デバイス１２と、第２の端末デバイス１３とを含む。ネットワークデバイス１１は、Ｕｕエアインターフェースを介して第１の端末デバイス１２および第２の端末デバイス１３と通信する。第１の端末デバイス１２は、ＰＣ５エアインターフェースを介して第２の端末デバイス１３と通信する。ＰＣ５インターフェースを介した通信は、ＳＬ通信とも呼ばれる。図１は、説明のための例にすぎず、限定を構成するものではない。ネットワークアーキテクチャは、より多くのネットワークデバイスおよび端末デバイスをさらに含み得る。

ＳＬ通信のシナリオでは、第１の端末デバイス１２および第２の端末デバイス１３は、同じ基地局（例えば、基地局１１）のカバレッジ内に位置してもよいし、異なる基地局のカバレッジ内に位置してもよい。代替的に、一方の端末デバイスは基地局のカバレッジ内に位置し、他方の端末デバイスは基地局のカバレッジ外に位置する。代替的に、両方の端末デバイスが、基地局のカバレッジ外（out of coverage）に位置する。１つの送信側端末デバイスは、１つまたは複数の受信側端末デバイスとＳＬ通信を実行し得る。受信側端末デバイスの観点から、１つの受信側デバイスはまた、１つまたは複数の送信側端末デバイスとＳＬ通信を実行し得る。

本出願の実施形態における端末デバイスは、端末（terminal）、ユーザ機器（user equipment、ＵＥ）、アクセス端末、加入者ユニット、加入者局、移動局、リモート局、リモート端末、モバイルデバイス、ユーザ端末、ワイヤレス通信デバイス、ユーザエージェント、またはユーザ装置とも呼ばれる。端末デバイスは、ワイヤレスローカルエリアネットワーク（wireless local area network、ＷＬＡＮ）における局（station、ＳＴ）であってもよいし、携帯電話、コードレス電話、セッション開始プロトコル（session initiation protocol、ＳＩＰ）電話、ワイヤレスローカルループ（wireless local loop、ＷＬＬ）局、パーソナルデジタル処理（personal digital assistant、ＰＤＡ）デバイス、ワイヤレス通信機能を有するハンドヘルドデバイス、コンピューティングデバイス、もしくはワイヤレスモデムに接続された別の処理デバイス、ウェアラブルデバイス、車載デバイス、路側ユニット（road side unit、ＲＳＵ）、および次世代通信システム、例えば、第５世代（5-generation、５Ｇ）ネットワーク内の端末デバイス、将来の進化型公衆陸上移動ネットワーク（public land mobile network、ＰＬＭＮ）ネットワーク内の端末デバイス、新無線（new radio、ＮＲ）通信システム内の端末デバイスなどであってもよい。

本出願の実施形態におけるネットワークデバイスは、アクセスネットワークデバイス、基地局などと呼ばれることがある。基地局は、ＷＬＡＮにおけるアクセスポイント（access point、ＡＰ）、汎欧州デジタル移動電話方式（global system for mobile communication、ＧＳＭ（登録商標））もしくは符号分割多元接続（code division multiple access、ＣＤＭＡ）におけるベーストランシーバステーション（base transceiver station、ＢＴＳ）であってもよいし、ＷＣＤＭＡ（登録商標）におけるノードＢ（nodeB、ＮＢ）であってもよいし、ＬＴＥにおける発展型ノードＢ（evolved nodeB、ｅＮＢ、もしくはｅＮｏｄｅＢ）、または中継局もしくはアクセスポイント、ＮＲシステムにおける新世代ノードＢ（new generation nodeB、ｇＮｏｄｅＢ）などであってもよい。任意選択で、ｇＮｏｄｅＢは、中央ユニット（central unit、ＣＵ）と分散ユニット（distributed unit、ＤＵ）とが別個である形態で展開され得る。

ＳＬ通信の典型的な用途は、Ｖ２Ｘ通信である。例えば、Ｖ２Ｘ通信は、車車間通信（vehicle-to-vehicle、Ｖ２Ｖ）、路車間通信（vehicle-to-infrastructure、Ｖ２Ｉ）、車歩行者間通信（vehicle to people、Ｖ２Ｐ）、車対アプリケーションサーバ通信（vehicle-to-network、Ｖ２Ｎ）などを含む。Ｖ２Ｘの具体的な通信シナリオは、本出願の実施形態において限定されない。例えば、Ｖ２Ｘ通信は、車車間通信であってもよいし、車載デバイス間の通信であってもよいし、ＲＳＵと車載デバイスおよび／もしくはネットワークデバイスとの間の通信であってもよいし、ネットワークデバイスと車載デバイスおよび／もしくはＲＳＵとの間の通信であってもよい。ネットワークデバイスは、ＬＴＥ基地局デバイス、ＮＲ基地局デバイス、または後続の進化型システム内の基地局であり得る。

Ｖ２Ｘシナリオでは、端末デバイスは、ユニキャスト、マルチキャスト、またはブロードキャスト通信をサポートする。ユニキャスト通信のためにはユニキャスト接続を確立する必要があり、マルチキャスト通信のためにはマルチキャスト通信グループを確立する必要がある。例えば、車両隊列走行（platooning）サービスでは、移動方向が同じで距離が比較的近い車両が、車両隊列を形成し得、車両隊列内の１台の車両が、車両隊列内の別の車両にデータを送信し得る。さらに、先頭車両は、メンバー車両へのユニキャスト通信接続を確立し、ユニキャスト接続を介してメンバー車両との１対１のデータ送信を実行し得る。

ＳＬ送信を実行する前に、送信側端末デバイスは、送信リソースを取得する必要がある。本出願の実施形態では、ＳＬ通信のために使用される送信リソースは、ＳＬリソースと呼ばれる。従来技術におけるダウンリンクデータリソースとアップリンク送信リソースとを区別するために、ＳＬリソースは、ＳＬグラント（SL grant）とも呼ばれる。それに対応して、受信を実行する前に、受信側端末デバイスはまた、受信リソースを決定する必要がある。現在、送信側端末デバイスは、以下の２つのモード（モード１）でＳＬリソースを取得し得る。

モード１：基地局スケジューリング方式。基地局スケジューリング方式は、Ｕｕインターフェース上のアップリンクリソースを取得する方式と同様である。ＳＬデータが送信されるべきであるとき、端末デバイスは、送信されるべきデータの量を基地局に通知するために、まず、サイドリンクバッファステータスレポート（sidelink buffer status report、ＳＬ ＢＳＲ）を基地局に報告する。基地局は、ＳＬ ＢＳＲに基づいて、ＳＬ送信リソースプール（Tx resource pool）から相当サイズのＳＬリソースを端末デバイスに割り当て得る。周期的サービスの場合、端末デバイスは、周期的サービスの属性を基地局に報告し得る。基地局は、周期的サービスの属性に基づいて、周期的ＳＬリソースを端末デバイスに割り当てる。周期的サービスの属性には、開始時刻、周期、パケットサイズなどが含まれる。周期的ＳＬリソースが割り当てられる端末デバイスは、ＳＬリソースを取得するためにＳＬ ＢＳＲを頻繁に送信する必要はない。

モード２：端末デバイス自律競合方式において、例えば、端末デバイスは、ＳＬ送信リソースプール内の各時間－周波数リソースが占有されているかどうかを測定することによって、送信のために、アイドル（すなわち、占有されていない）ＳＬリソースを選択し得、基地局は、ＳＬリソースをスケジューリングする必要はない。

ＳＬ送信リソースプールは、複数のＳＬリソース（例えば、時間－周波数リソース）を含む。端末デバイスのためにＳＬリソースをスケジューリングするとき、基地局は、ＳＬ送信リソースプールからリソースを選択し得る。同様に、自律的にＳＬリソースを選択する場合、端末デバイスも、ＳＬ送信リソースプールからリソースを選択する。ＳＬ送信リソースプールは、基地局によって端末デバイスのために構成され得る。１つまたは複数のＳＬ送信リソースプールが存在し得ることが理解され得る。

同様に、端末デバイスが、ＳＬ通信を実行するために受信側として使用されるとき、端末デバイスはまた、ＳＬ受信リソースプール（Rx resource pool）から対応するＳＬ受信リソースを決定する必要がある。送信リソースプール内のＳＬリソースは、受信リソースプール内のＳＬリソースに対応し、１つまたは複数のＳＬ受信リソースプールが存在し得ることが理解され得る。

既存の通信プロトコルでは、関心のあるサービスについて、受信側端末デバイスは、可能な送信側端末デバイスによって送信されたメッセージを受信するために、リソースプール内のすべてのＳＬリソースに対応する時点においてサイドリンク制御情報（sidelink control information、ＳＣＩ）を監視する必要がある。しかしながら、送信側端末デバイスは、ほとんどの時間においてデータを送信しない可能性があり、したがって、受信側端末デバイスのエネルギー節約につながらない。

従来技術では、受信側端末デバイスは、エネルギーを節約するためにＤＲＸメカニズムを使用し得る。受信側端末デバイスは、ＤＲＸのアクティブ時間においてのみダウンリンク制御情報（downlink control information、ＤＣＩ）を受信し、ＤＲＸのスリープ時間においてＤＣＩを受信せず、受信側端末デバイスの受信機は、ＤＲＸのスリープ時間にはオフ状態にあり、それによって、エネルギー節約の目的を達成する。

ＤＲＸメカニズム（以下、ＳＬ ＤＲＸと呼ばれる）もＳＬ通信に導入される。ＳＬ ＤＲＸをサポートする受信側端末デバイスは、ＳＬ ＤＲＸのアクティブ時間においてのみＳＣＩを受信し、ＳＬ ＤＲＸのスリープ時間には受信機を無効にし、ＳＣＩを受信しない。ＳＬ ＤＲＸは、ユニキャストＳＬ ＤＲＸおよびマルチキャストまたはブロードキャストＳＬ ＤＲＸを含む。ユニキャストＳＬ ＤＲＸを使用する前に、端末デバイスは、まず、ユニキャスト接続（ＰＣ５－Ｓ接続／ユニキャストリンク）を確立し、次いで、確立されたユニキャスト接続を通じて対応するＳＬ ＤＲＸパラメータを構成する必要がある。

ＳＬ ＤＲＸのユニキャスト接続を確立するプロセスについては、図２に示されるプロセスを参照されたい。図２に示すように、ユニキャスト接続を確立するプロセスは、以下のステップを含む。

Ｓ１０１：第１の端末デバイスが、接続確立要求メッセージを第２の端末デバイスに送信する。

接続確立要求メッセージは、ユニキャスト接続を確立することを要求するためのものである。接続確立要求は、ＰＣ５－Ｓ接続確立要求メッセージとも呼ばれる。接続確立要求メッセージは、直接通信要求メッセージであり得る。

Ｓ１０２：第２の端末デバイスが、セキュリティ確立コマンドメッセージを第１の端末デバイスに送信する。

Ｓ１０３：第１の端末デバイスが、セキュリティ確立完了メッセージを第２の端末デバイスに送信する。

Ｓ１０４：第２の端末デバイスが、接続確立受諾メッセージを第１の端末デバイスに送信する。

セキュリティ確立コマンドメッセージは、ダイレクトセキュリティモードコマンドメッセージであり得る。セキュリティ確立完了メッセージは、ダイレクトセキュリティモード完了メッセージであり得る。接続確立受諾メッセージは、ダイレクト通信受諾メッセージであり得る。接続確立要求メッセージは、ユニキャストまたはブロードキャスト方式で送信され得る。セキュリティ確立コマンドメッセージ、セキュリティ確立完了メッセージ、および接続確立受諾メッセージはすべて、ユニキャスト方式で送信される。

ユニキャスト接続を確立するプロセスでは、対応するセキュリティも確立される。加えて、ユニキャスト接続が確立された後、対応するＰＣ５－ＲＲＣ接続が自動的に存在する。セキュリティは、端末デバイスの上位層（例えば、ＰＣ５－Ｓ層またはＶ２Ｘ層）によって確立され得る。セキュリティを確立した後、上位層は、セキュリティ構成をアクセス（access、ＡＳ）層に通知する。セキュリティ構成は、セキュリティアルゴリズム、セキュリティパラメータ、セキュリティポリシーなどを含む。ＡＳ層は、セキュリティ構成を使用することによって、ＰＣ５－Ｓメッセージ、ＰＣ５－ＲＲＣメッセージ、およびユーザプレーンデータ送信に対してセキュリティ保護を実行し得る。

中継通信のシナリオでは、ユニキャスト接続を確立する前に、端末デバイスは、まず、発見（discovery）メカニズムを使用することによって互いを発見する。端末デバイスは、中継（relay）端末デバイスとリモート（remote）端末デバイスとに分類され得る。中継端末デバイスは、常に基地局のカバレッジ内にあり、基地局と直接通信することができる。リモート端末デバイスは、基地局のカバレッジ内にあってもよいし、基地局のカバレッジ外にあってもよい。データをネットワークに直接送信するために、リモート端末デバイスは、中継端末デバイスを発見して、それに接続する必要がある。

現在、端末デバイス間に２つの発見モードが存在する。発見モードＡでは、中継端末デバイスは、告知メッセージを周囲にブロードキャストして、周囲のリモート端末デバイスに「私はここにいます。そして、あなたは私を見つけることができます。」と通知することができる。発見モードＢでは、リモート端末デバイスは、中継端末デバイスが近くに存在するかどうかを問い合わせるために要請メッセージを送信する。要請メッセージを受信した後、中継端末デバイスは、中継端末デバイスのステータスまたは別の要因に基づいて、応答メッセージを返すべきかどうかを決定する。中継端末デバイスが応答メッセージを返すと、２つの端末デバイスは互いを発見する。

マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするためには、マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソース（またはマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースと呼ばれる）が構成される必要がある。マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソースは、以下の２つの方式で構成され得る。本明細書におけるＳＬリソースは、ＳＬ受信リソースまたはＳＬ送信リソースを含むことが理解され得る。

方式１：いくつかのパターン（サブセットとも呼ばれ得る）が、マルチキャストまたはブロードキャストＳＬ ＤＲＸのために既存のリソースプール（例えば、Ｒ１６リソースプール）からキャプチャされる。図３は、マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソースの概略図である。図３に示すように、灰色の部分は、キャプチャされたパターンを表す。ネットワークデバイスが、パターンリソースの時間－周波数領域位置、周期などを定義または構成し、時間－周波数領域位置、周期などを端末デバイスに通知し得るか、またはプロトコルが、パターンリソースの時間－周波数領域位置、周期などを予め定義する。より多くの不連続パターンリソースがリソースプール内に存在し得、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする端末デバイスは、灰色部分に示されるＳＬリソース上でデータを送信または受信し、マルチキャストまたはブロードキャストサービを正常に送信することができることを保証し得ることが理解され得る。

方式２：専用リソースプール（dedicated resource pool）がマルチキャストまたはブロードキャストＳＬ ＤＲＸのために構成される。図４は、マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソースの別の概略図である。灰色部分は専用リソースプールを示す。専用リソースプールは、マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用される。既存のリソースプールは、専用リソースプールから独立している。マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングが正常に送信され得ることを保証するために、灰色部分に示される専用リソースプール上で、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを送信または受信し得る。

方式１および方式２におけるリソースプールは、送信リソースプールまたは受信リソースプールであり得る。

マルチキャストまたはブロードキャストＳＬ ＤＲＸがサポートされると受信側端末デバイスが決定したとき、受信側端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸのアクティブ時間においてのみＳＣＩをリッスンし、送信側端末デバイスは、任意の時間にデータまたはシグナリングを送信し得る。送信側端末デバイスによって送信されたデータまたはシグナリングが、マルチキャストまたはブロードキャストＳＬ ＤＲＸのアクティブ時間に対応する時間－周波数位置にない場合、受信側端末デバイスは、送信側によって送信されたデータまたはシグナリングを受信することができず、データまたはシグナリングの欠落をもたらす。送信側端末デバイスによって送信されたデータまたはシグナリングが、ブロードキャストまたはマルチキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングである場合、ブロードキャストまたはマルチキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングの欠落は、端末デバイスの通信品質に影響を及ぼす。

本出願の実施形態では、ブロードキャストまたはマルチキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングは、欠落（miss）することができないデータもしくはシグナリング、または破棄することができないデータもしくはシグナリングとも呼ばれるか、または重要なデータもしくはシグナリングと呼ばれるか、またはブロードキャストまたはマルチキャストＳＬ ＤＲＸに対応するＳＬリソース上で受信もしくは送信される必要があるデータもしくはシグナリングと呼ばれるか、または特定のバージョン（例えば、Ｒ１７）のデータもしくはシグナリングと呼ばれる。データおよびシグナリングは、情報（information）とも総称されることがある。したがって、ブロードキャストまたはマルチキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングは、ブロードキャストまたはマルチキャストＳＬ ＤＲＸをサポートする情報とも呼ばれる。

マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするサービスまたはマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするＱｏＳフロー（QoS flow）を含む。ＱｏＳフローは、サービスの粒度よりも小さいまたは細かい粒度を有するデータである（すなわち、１つのサービスが、１つまたは複数のＱｏＳフローを含み得る）。

本出願の実施形態では、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするシグナリングは、ユニキャスト接続を確立するプロセスにおける４つのメッセージ（図２に示される４つのメッセージを参照）、発見プロセスにおけるメッセージ、端末デバイスのＳＬ能力関連メッセージ、および第１のＰＣ５ ＲＲＣ再構成メッセージのうちの１つまたは複数のシグナリングを含む。ユニキャスト接続を確立するプロセスにおける４つのメッセージは、図２に示される、接続確立要求メッセージ、セキュリティ確立コマンドメッセージ、セキュリティ確立完了メッセージ、および接続確立受諾メッセージである。発見プロセスにおけるメッセージは、告知メッセージ、要請メッセージ、および要請メッセージの応答メッセージを含む。端末デバイスのＳＬ能力関連メッセージは、UECapabilityEnquirySidelinkメッセージおよびUECapabilityInformationSidelinkメッセージを含む。

従来技術における問題を解決するために、本出願の実施形態では、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバは、端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸのデータまたはシグナリングをサポートすることを示すか、端末デバイスに、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを示し得る。送信側端末デバイスが、送信されるべきデータを有するとき、送信側端末デバイスは、送信されるべきデータまたはシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングであるかどうかを決定する。送信されるべきデータまたはシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングである場合、送信側端末デバイスは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを使用することによって、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを送信する。受信側端末デバイスは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソース上で、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを受信する。なぜなら、送信側端末デバイスによって使用される送信リソースは、受信側端末によって使用される受信リソースに対応するからである。すなわち、送信リソースおよび受信リソースの両方がマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースである場合、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングが、ＳＬ通信の品質に影響を及ぼすことなく、受信側デバイスによって正常に受信されることができることを保証することができる。

マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングは、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバによって示されてもよいし、端末デバイスにおいて予め構成されてもよい。これは、この実施形態に限定されない。マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータは、マルチキャストまたはブロードキャストＳＬ ＤＲＸサービスまたはＱｏＳフローを含む。コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするサービスタイプ、ＱｏＳフローに関する情報、宛先アドレスなどを示し得る。ＱｏＳフローに関する情報は、ＱｏＳフローの識別子（PC5 QoS flow identifier、ＰＦＩ）であり得る。

この実施形態では、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバは、第１の指示情報を端末デバイスに送信し得る。第１の指示情報は、データまたはシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを示す。端末デバイスの上位層は、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバから第１の指示情報を受信し、第１の指示情報をＡＳ層に送信する。端末デバイスの上位層は、アプリケーション層とＡＳ層との間の層と理解され得る。上位層は、ＰＣ５－Ｓ層またはＶ２Ｘ層を含む。端末デバイスのＡＳ層は、物理層（physical）、媒体アクセス制御（media access control、ＭＡＣ）層、無線リンク制御（radio link control、ＲＬＣ）層、パケットデータコンバージェンスプロトコル（packet data convergence protocol、ＰＤＣＰ）層、サービスデータ適応プロトコル（service data adaptation protocol、ＳＤＡＰ）層、および無線リソース制御（radio resource control、ＲＲＣ）層のうちの１つまたは複数の層を含む。

データがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかをコアネットワークデバイスまたはＶ２Ｘアプリケーションサーバが端末デバイスに示すとき、またはデータがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを端末デバイスの上位層がＡＳ層に示すとき、各サービスタイプ／宛先アドレス／ＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかが示されてもよいし、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするサービスタイプ／宛先アドレス／ＱｏＳフローのみが示されてもよい。ＱｏＳフローは、サービスの粒度よりも細かいまたは小さい粒度を有するデータである。サービスがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかが示されるとき、ＱｏＳフローは、サービスタイプまたは宛先アドレスに対応するデータがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを示し得る。宛先アドレスは、サービスタイプを変換することによって取得され得ることが理解され得る。

１つの宛先アドレスまたはサービスは、複数のＱｏＳフローに対応するかまたは関連付けられ得る。１つの宛先アドレスに対応する複数のＱｏＳフローのうちの一部のＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートし得、他のＱｏＳフローは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートしないであろう。したがって、ＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかをコアネットワークデバイスまたはＶ２Ｘアプリケーションサーバが端末デバイスに示すとき、またはＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを端末デバイスの上位層がＡＳ層に示すとき、宛先アドレスに関連付けられた各ＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかが示されてもよいし、宛先アドレスに関連付けられたどのＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかが示されてもよい。

シグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかをコアネットワークデバイスまたはＶ２Ｘアプリケーションサーバが端末デバイスに示すとき、またはシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを端末デバイスの上位層がＡＳ層に示すとき、各タイプのシグナリング／各宛先アドレスに対応するシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかが示され得るか、または特定の名前のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかが示され得る。

マルチキャストまたはブロードキャストＳＬ ＤＲＸがサポートされるかどうかを端末デバイスの上位層がＡＳ層に示すとき、示された粒度は、端末デバイスの粒度と理解される。

図５は、本出願の実施形態１によるサイドリンク通信方法のフローチャートである。図５に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ２０１：第１の端末デバイスが、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定し、ここで、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである。

第１の端末デバイスは送信側であり、第１のデータまたは第１のシグナリングは、現在送信されるべきデータまたはシグナリングである。第１のデータまたは第１のシグナリングが送信されるべきであるとき、第１の端末デバイスは、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートするかどうかを決定する。

例えば、第１の端末デバイスは、第１の指示情報に基づいて、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定し、第１の指示情報は、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示す。第１の指示情報は、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバによって第１の端末デバイスの上位層に送信され得る。第１の端末デバイスの上位層は、第１の指示情報をＡＳ層に送信する。第１の端末デバイスのＡＳ層は、第１の指示情報に基づいて、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートするかどうかを決定する。

任意選択で、第１の指示情報は、第１のデータに関連付けられたサービスまたはＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを含む。第１の指示情報が、第１のデータに関連付けられたサービスがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示すとき、第１のデータに関連付けられたサービスタイプまたは宛先アドレスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするように示され得る。

一実装形態では、第１のシグナリングが第１のＤＲＸをサポートするかどうかを決定するとき、第１の端末デバイスは、第１の指示情報を使用しなくてもよく、第１の端末デバイスは、第１の端末デバイスのポリシーにしたがって、第１のＤＲＸをサポートするシグナリングを決定する。別の実装形態では、第１の端末デバイスは、第１の指示情報を参照して、第１のシグナリングが第１のＤＲＸをサポートするかどうかを決定し得る。例えば、第１の端末デバイスは、第１の端末デバイスのポリシーにしたがって、第１のシグナリングが第１のＤＲＸをサポートする代替シグナリングであると決定し、シグナリングの宛先アドレスが第１の指示情報において示される宛先アドレスであるかどうかをさらに決定する。シグナリングの宛先アドレスが第１の指示情報に示される宛先アドレスである場合、第１の端末デバイスは、第１のシグナリングが第１のＤＲＸをサポートすると決定する。

任意選択で、第１の端末デバイスは、第１の端末デバイスのポリシーにしたがって、第１のＤＲＸをサポートするシグナリングを決定するか、またはプロトコルにおいて予め定義されたルールにしたがって、第１のＤＲＸをサポートするシグナリングを決定する。

任意選択で、第１の端末デバイスは、端末デバイスの粒度に基づいて、第１の端末デバイスが第１のＤＲＸをサポートすると決定し得る。第１の端末デバイスの上位層は、第１の端末デバイスのＡＳ層が第１のＤＲＸをサポートすることを示し、示される粒度は、端末デバイスの粒度であることが理解され得る。

Ｓ２０２：第１の端末デバイスが、第１のＳＬリソースを取得し、ここで、第１のＳＬリソースは、第１のＤＲＸに対応するＳＬリソースである。

第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると第１の端末デバイスが決定した後、第１の端末デバイスは、第１のデータまたは第１のシグナリングを送信するために使用されるマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソース、すなわち、第１のＳＬリソースを取得する。

第１の端末デバイスは、モデル方式（すなわち、基地局によるスケジューリングの方式）で第１のＳＬリソースを取得し得る。具体的には、第１の端末デバイスは、第１の要求メッセージをネットワークデバイスに送信し、第１の要求メッセージは、第１のＳＬリソースを要求するためのものである。第１の端末デバイスは、ネットワークデバイスによって送信された第１のＳＬリソースに関する情報を受信する。ネットワークデバイスは基地局であり得る。基地局は、第１の要求メッセージのフォーマットおよびタイプまたは第１の要求メッセージ内のコンテンツに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

代替的に、第１の端末デバイスは、モード２方式（すなわち、端末デバイスがリソースを自律的に選択する方式）で第１のＳＬリソースを取得してもよい。具体的には、第１の端末デバイスは、アイドルＳＬリソースを測定することによって第１のＳＬリソースを取得する。例えば、第１の端末デバイスは、センシング方式で、ＳＬリソースがアイドルであるかどうかを測定し、リソース除外を通して最終的に利用可能な第１のＳＬリソースを決定し得る。

基地局によるスケジューリングの方式で第１のＳＬリソースを取得するとき、第１の端末デバイスは、第１の要求メッセージを使用することによって、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであることを知る必要がある。

第１の実装形態では、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであることを示す。第１の要求メッセージを受信した後、基地局は、第１の要求メッセージに含まれる第２の指示情報に基づいて、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを第１の端末デバイスに割り当てる。

本出願の実施形態では、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースは、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって使用される、または必要とされる、または使用されるべきＳＬリソースと理解され得る。

第２の実装形態では、第１の要求メッセージを基地局に送信する前に、第１の端末デバイスは、まず、第２の指示情報を基地局に送信し、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。基地局は、第１の要求メッセージおよび第２の指示情報に基づいて、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを第１の端末デバイスに割り当てる。

第３の実装形態では、第１の端末デバイスは、専用ＬＣＧまたは専用宛先アドレスインデックスを使用することによって、第１の要求メッセージを基地局に送信し、基地局は、第１の要求メッセージを送信するために使用される専用ＬＣＧまたは専用宛先アドレスインデックスに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。代替的に、第１の端末デバイスは、特定のフォーマットの第１の要求メッセージを基地局に送信する。基地局は、第１の要求メッセージのフォーマットに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。代替的に、第１の要求メッセージが専用ＳＲである場合、基地局は、専用ＳＲに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

本出願の実施形態では、第２の指示情報は、宛先アドレスまたはＱｏＳフローに関連付けられることに留意されたい。第２の指示情報が宛先アドレスに関連付けられるとき、第２の指示情報は、宛先アドレスに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。第２の指示情報がＱｏＳフローに関連付けられるとき、第２の指示情報は、ＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第２の指示情報は、代替的に、第１の端末デバイスに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであることを示し得る。言い換えれば、第２の指示情報は、端末デバイスの粒度を有する。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（scheduling request、ＳＲ）、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージである。それに対応して、第２の実装形態では、第２の指示情報は、ＳＵＩメッセージで搬送され得る。

（１）第１の要求メッセージはＳＬ ＳＲである。

例示的な方式では、第１の端末デバイスは、専用ＳＬ ＳＲを基地局に送信する。専用ＳＬ ＳＲを受信した後、基地局は、専用ＳＬ ＳＲに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであると決定する。専用ＳＬ ＳＲは、専用送信リソース上で送信されるＳＲと理解され得る。

専用ＳＬ ＳＲは、第１の端末デバイスのために基地局または別のネットワークデバイスによって予め構成されてもよいし、プロトコルにおいて予め定義されてもよい。第１の端末デバイスについて、ＳＬ ＳＲは、共通ＳＬ ＳＲおよび専用ＳＬ ＳＲという２つのタイプに分類され得る。専用ＳＬ ＳＲは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。共通ＳＬ ＳＲは、非制限ＳＬリソースまたはマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソース以外の別のＳＬリソースを要求するためのものである。基地局は、ＳＬ ＳＲのタイプに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであるかどうかを決定し得る。

例えば、専用ＳＬ ＳＲに対応するＳＲ ＩＤは、プロトコルにおいて予め定義される。第１の端末デバイスがＳＲ ＩＤに対応するリソース上でＳＬ ＳＲをネットワークデバイスに送信するとき、ネットワークデバイスは、リソースまたはＳＲ ＩＤに基づいて、第１の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するサイドリンク送信リソースを要求し、第１の端末デバイスのための対応するサイドリンク送信リソースを構成することを知り得る。

別の実装形態では、専用ＳＬ ＳＲを基地局に送信する前に、第１の端末デバイスは、まず、専用ＳＬ ＳＲを構成するように基地局に要求する。ＳＬ ＳＲを構成するように基地局に要求する前に、第１の端末デバイスは、第２の指示情報を基地局に送信する。基地局は、第２の指示情報に基づいて、第１の端末デバイスのために専用ＳＬ ＳＲを構成する。基地局が専用ＳＬ ＳＲを構成することは、専用送信リソースがＳＬ ＳＲのために構成されることと理解され得る。

例えば、第１の端末デバイスは、ＳＵＩメッセージを基地局に送信し、ＳＵＩメッセージは、宛先アドレスおよび宛先アドレスに対応するＱｏＳフローを含む。従来技術とは異なり、この実施形態では、ＳＵＩメッセージは、第２の指示情報をさらに含む。ＳＵＩメッセージを受信した後、基地局は、ＳＵＩメッセージに含まれる第２の指示情報に基づいて、専用ＳＬ ＳＲを第１の端末デバイスに割り当てる。言い換えれば、基地局は、第２の指示情報に対応する宛先アドレスまたはＱｏＳフローに関連付けられたＬＣＨ（論理チャネル）のための専用ＳＬ ＳＲを構成し得る。ネットワークは、専用ＳＬ ＳＲに対応するＳＲ ＩＤを構成し、第１の端末デバイスがＳＲ ＩＤに対応するリソース上でＳＬ ＳＲをネットワークデバイスに送信するとき、ネットワークデバイスは、リソースまたはＳＲ ＩＤに基づいて、第１の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するサイドリンク送信リソースを要求し、第１の端末デバイスのための対応するサイドリンク送信リソースを構成し得ることを知ることが理解され得る。

さらに別の例示的な方式では、ＳＬ ＳＲは第２の指示情報を含み、基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。このように、専用ＳＬ ＳＲが定義される必要はなく、すべての通常のＳＬ ＳＲまたは共通ＳＬ ＳＲが第２の指示情報を含み得る。

（２）第１の要求メッセージはＳＬ ＢＳＲである。

例示的な方式では、第１の端末デバイスは、専用論理チャネルグループ（logical channel group、ＬＣＧ）を使用することによってＳＬ ＢＳＲを基地局に送信し得る。ＳＬ ＢＳＲを受信した後、基地局は、ＳＬ ＢＳＲを送信するＬＣＧに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

ＳＬ ＢＳＲを送信するための専用ＬＣＧ（例えば、専用論理チャネルグループ識別子）は、第１の端末デバイスのために基地局または別のネットワークデバイスによって予め構成されてもよいし、プロトコルにおいて予め定義されてもよい。第１の端末デバイスについて、ＳＬ ＢＳＲを送信するためのＬＣＧは、共通ＬＣＧおよび専用ＬＣＧという２つのタイプに分類される。専用ＬＣＧは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。共通ＬＣＧは、非制限ＳＬリソースまたはマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソース以外の別のＳＬリソースを要求するためのものである。基地局は、ＳＬ ＢＳＲを送信するためのＬＣＧのタイプに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであるかどうかを決定し得る。

別の実装形態では、専用ＬＣＧを使用することによってＳＬ ＢＳＲを基地局に送信する前に、第１の端末デバイスは、まず、専用ＬＣＧを構成するように基地局に要求する。専用ＬＣＧを構成するように基地局に要求する前に、第１の端末デバイスは、第２の指示情報を基地局に送信し、基地局は、第２の指示情報に基づいて、第１の端末デバイスのために専用ＬＣＧを構成する。

例えば、第１の端末デバイスは、ＳＵＩメッセージを基地局に送信する。ＳＵＩメッセージは、宛先アドレスと、宛先アドレスに対応するＱｏＳフローとを含み、ＳＵＩメッセージは、第２の指示情報をさらに含む。ＳＵＩメッセージを受信した後、基地局は、ＳＵＩメッセージに含まれる第２の指示情報に基づいて、ＳＬ ＢＳＲを送信するための専用ＬＣＧを第１の端末デバイスに割り当てる。言い換えれば、基地局は、第２の指示情報に対応する宛先アドレスまたはＱｏＳフローが専用ＬＣＧ上で送信されるように構成し得る。

さらに別の例示的な方式では、第１の端末デバイスは、専用宛先アドレスインデックス（destination index）を使用することによって、ＳＬ ＢＳＲを基地局に送信し得る。ＳＬ ＢＳＲを受信した後、基地局は、ＳＬ ＢＳＲを送信するための宛先アドレスインデックスに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。専用宛先アドレスインデックスは、専用宛先アドレスを一意に識別することができる。

ＳＬ ＢＳＲを送信するための専用宛先アドレスインデックスは、第１の端末デバイスのために基地局または別のネットワークデバイスによって予め構成されてもよいし、プロトコルにおいて予め定義されてもよい。第１の端末デバイスについて、ＳＬ ＢＳＲを送信するための宛先アドレスインデックスは、共通宛先アドレスインデックスおよび専用宛先アドレスインデックスのという２つのタイプに分類される。専用宛先アドレスインデックスは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものであり、共通宛先アドレスインデックスは、非制限ＳＬリソースまたはマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソース以外の別のＳＬリソースを要求するためのものである。基地局は、ＳＬ ＢＳＲを送信するための宛先アドレスインデックスのタイプに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであるかどうかを決定し得る。

さらに別の例示的な方式では、ＳＬ ＢＳＲは第２の指示情報を含み、基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。このように、専用ＬＣＧまたは専用宛先アドレスインデックスは、ＳＬ ＢＳＲのために構成される必要はない。

さらに別の例示的な方式では、第１の端末デバイスは、共通ＬＣＧまたは共通宛先アドレスインデックスを使用することによってＳＬ ＢＳＲを基地局に送信し、ＳＬ ＢＳＲを基地局に送信する前に、第２の指示情報をＳＬ ＢＳＲに含める。例えば、宛先アドレスインデックスに対応するＬＣＧまたはＳＬ ＢＳＲに含まれる宛先アドレスインデックスが、第２の指示情報に関連付けられ得る。ＳＬ ＢＳＲを受信した後、基地局は、第２の指示情報および宛先アドレスインデックスに対応するＬＣＧまたはＳＬ ＢＳＲに含まれる宛先アドレスインデックスに基づいて、第１の端末デバイスによって要求されたＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

具体的には、第１の端末デバイスは、宛先アドレスに関連付けられた第１の指示情報に基づいて、ＳＬ ＢＳＲにおける宛先アドレスインデックスが第２の指示情報に関連付けられていると決定するか、または、第１の端末デバイスは、ＱｏＳフローに関連付けられた第１の指示情報に基づいて、ＳＬ ＢＳＲにおいてＱｏＳフローがマッピングされるＬＣＧが第２の指示情報に関連付けられていると決定する。

さらに別の例示的な方式では、第１の端末デバイスは、特定のフォーマット（format）のＳＬ ＢＳＲを基地局に送信し、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。

ＳＬ ＢＳＲのフォーマットは、第１の端末デバイスのために基地局または別のネットワークデバイスによって予め構成されるか、またはプロトコルにおいて予め定義され得る。第１の端末デバイスについて、ＳＬ ＢＳＲのフォーマットは、共通のフォーマットおよび特定のフォーマットという２つのタイプに分類される。特定のフォーマットのＳＬ ＢＳＲは、新たに定義されたフォーマットまたは新たな媒体アクセス制御の制御要素（media access control control element、ＭＡＣ ＣＥ）要素であり、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。共通のフォーマットのＳＬ ＢＳＲは、非制限ＳＬリソースまたはマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソース以外の別のＳＬリソースを要求するために使用される様々な既存のフォーマットを含む。基地局は、ＳＬ ＢＳＲのフォーマットに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであるかどうかを決定し得る。

（３）第１の要求メッセージはＵＡＩメッセージである。

例示的な方式では、第１の端末デバイスは、ＵＡＩメッセージを基地局に送信し、ＵＡＩメッセージは、ＱｏＳフロー情報およびサービスモードを含む。従来技術とは異なり、ＵＡＩメッセージは、第２の指示情報をさらに含む。ＵＡＩメッセージを受信した後、基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

例えば、ＵＡＩメッセージ内のＱｏＳフロー情報またはサービスモードが、第２の指示情報に関連付けられる。

別の実装形態では、ＵＡＩメッセージを基地局に送信する前に、第１の端末デバイスは、まず、第２の指示情報を基地局に送信し、すなわち、ＵＡＩメッセージは第２の指示情報を含まない。例えば、第１の端末デバイスは、宛先アドレスまたはＱｏＳフローに関連付けられた第２の指示情報を、送信されるＳＵＩメッセージに含める。さらに、ＳＵＩメッセージおよびＵＡＩメッセージに基づいて、ＳＵＩメッセージ内の第２の指示情報に関連付けられたＱｏＳフローまたは宛先アドレスがＵＡＩメッセージのＱｏＳフローまたはサービスモードに対応すると決定したとき、基地局は、第１の端末デバイスによって要求されたＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

ＵＡＩメッセージに基づいて基地局によって第１の端末デバイスに割り当てられ得る第１のＳＬリソースは、半永続的スケジューリング(semi-persistent scheduling、ＳＰＳ）リソースであり、ＳＰＳリソースは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースである。

Ｓ２０３：第１の端末デバイスが、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信する。

それに対応して、第２の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で第１のデータまたは第１のシグナリングを受信し、第２の端末デバイスは、受信側端末デバイスである。第１の端末デバイスは、マルチキャストまたはブロードキャスト方式で第１のデータまたは第１のシグナリングを送信する。任意選択で、第１の端末デバイスは、ユニキャスト方式で第１のシグナリングを送信し得る。

受信側として、第２の端末デバイスはまた、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバから第１の指示情報を受信する。第１の指示情報は、まず、第２の端末デバイスの上位層に送信される。第２の端末デバイスのＡＳ層は、上位層から第１の指示情報を受信する。第２の端末デバイスは、第１の指示情報に基づいて、現在受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートするかどうかを決定する。第２の端末デバイスが、現在受信されるべきデータおよび／またはシグナリングが第１のＤＲＸをサポートすると決定した場合、第２の端末デバイスは、第１のＤＲＸをアクティブ化する。第１のＤＲＸをアクティブ化した後、第２の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で第１の端末デバイスによって送信されたデータまたはシグナリングを第２の端末デバイスが受信することができるように、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上でデータまたはシグナリングを受信し得る。

第２の端末デバイスによって受信されるべきデータは、第２の端末デバイスが関心を持っているデータ、または第２の端末デバイスの上位層によって示されるようにＡＳ層が受信する必要があるデータと理解され得る。

任意選択で、現在受信されるべきデータおよび／またはシグナリングが第１のＤＲＸをサポートするとき、第１のＤＲＸをアクティブ化するステップは、複数の受信されるべきデータおよび／またはシグナリングが存在し、複数のデータおよび／またはシグナリングのすべてが第１のＤＲＸをサポートするとき、第１のＤＲＸをアクティブ化する、または、複数のデータおよび／またはシグナリングのうちの一部のデータもしくは一部のシグナリングが第１のＤＲＸをサポートするとき、第１のＤＲＸをアクティブ化するという２つのケースを含む。

複数のデータおよび／またはシグナリングのうちの一部のデータまたはシグナリングが第１のＤＲＸをサポートするとき、第１のＤＲＸがアクティブ化された後、複数のデータおよび／またはシグナリングのうちの第１のＤＲＸをサポートしないデータまたはシグナリングは、受信側端末デバイスによって受信されないであろう。しかしながら、複数のデータおよび／またはシグナリングのうちのデータまたはシグナリングが第１のＤＲＸをサポートするとき、第１のＤＲＸがアクティブ化された後、複数のデータおよび／またはシグナリングは、受信側端末デバイスによって受信されることができる。

受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートするかどうかを決定するステップは、具体的には、受信されるべきデータまたはシグナリングの宛先アドレスまたはＱｏＳフローを、第１の指示情報によって示される宛先アドレスまたはＱｏＳフローと比較するステップと、受信されるべきデータまたはシグナリングの宛先アドレスまたはＱｏＳフローが、第１の指示情報によって示される宛先アドレスまたはＱｏＳフローに属する場合、受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートすると決定するステップとである。

第２の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース（すなわち、第１の端末デバイスのために構成されたマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応する送信リソースプール）上にあり、第１の端末デバイスが具体的にデータを送信するリソースを知らないが、第１のＤＲＸをアクティブ化した後、第２の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース（すなわち、第２の端末デバイスのために構成されたマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応する受信リソースプール）のすべてのリソース上でデータを受信することが理解され得る。このように、第１のデータまたは第１のシグナリングを正常に受信することができる。

任意選択で、第２の端末デバイスが第１のＤＲＸをアクティブ化しないとき、第２の端末デバイスは、受信リソースプールに対応するフルセット時間－周波数リソース位置においてデータを受信する。マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースが通常（normal）受信リソースプールのサブセットである場合、第２の端末はまた、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上でデータを受信する。

任意選択で、第２の端末デバイスの上位層は、第１の指示情報をＡＳ層に送信する。第１の指示情報は、第２の端末デバイスが第１のＤＲＸをサポートするかどうかを示し得る。言い換えれば、第１の指示情報の粒度は、端末デバイスの粒度である。第２の端末デバイスが、第１の指示情報に基づいて、第１のＤＲＸが現在サポートされていると決定した場合、第２の端末デバイスは、第１のＤＲＸをアクティブ化する。

この実施形態では、第１の端末デバイスが、送信されるべき第１のデータまたは第１のシグナリングを有するとき、第１の端末デバイスは、まず、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを決定する。第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするとき、第１の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを取得し、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを使用することによって第１のデータまたは第１のシグナリングを送信する。第１のデータまたは第１のシグナリングを送信するために送信側端末デバイスによって使用されるＳＬリソースは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであり、受信側端末デバイスもまた、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で第１のデータまたは第１のシグナリングを受信する。したがって、受信側端末デバイスが、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする第１のデータまたは第１のシグナリングを正常に受信することができることが保証され、それによって、ＳＬ通信品質を向上させることができる。

図６は、本出願の実施形態２によるサイドリンク通信方法のフローチャートである。実施形態１に基づいて、この実施形態は、ステップＳ２０３を詳細に説明する。図６に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ３０１：第１の端末デバイスが、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定し、ここで、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである。

Ｓ３０２：第１の端末デバイスが、第１のＳＬリソースを取得し、ここで、第１のＳＬリソースは、第１のＤＲＸに対応するＳＬリソースである。

ステップＳ３０１およびＳ３０２の具体的な実装形態ついては、実施形態１におけるステップ２０１およびＳ２０２の説明を参照されたく、詳細は本明細書で改めて説明しない。

Ｓ３０３：第１の端末デバイスが、送信されるべき宛先アドレス／論理チャネル（logical channel、ＬＣＨ）から、第１のデータまたは第１のシグナリングに対応する宛先アドレス／論理チャネルのみを、第１のＳＬリソース上での送信のために選択するか、または優先的に選択する。

複数の論理チャネルが送信されるべきデータを有し、送信されるべきデータの総量が現在の送信時間間隔（transmission time interval、ＴＴＩ）の送信能力を超えるとき、データを優先的に送信するための論理チャネルを決定する問題が考慮される必要があり、これは、論理チャネル優先順位付け（logical channel prioritization、ＬＣＰ）と呼ばれる。ＴＴＩは、無線リソーススケジューリングの最小単位である。ネットワークの進化または変化に伴い、無線リソーススケジューリングの最小単位が変化し得ることは理解され得る。

サイドリンク送信の間、送信リソースを端末デバイスに割り当てるとき、基地局は、どのリソースがどの宛先アドレスまたは論理チャネルによって使用されるべきかを指定しない。送信リソースを取得した後、端末デバイスは、各論理チャネルのステータスに基づいて、論理チャネルの優先度を決定し得る。一般に、制御論理チャネルの優先度は、データ論理チャネルの優先度よりも高く、データ論理チャネルの優先度は、データ論理チャネル上で送信されるデータのＱｏＳパラメータに基づいて決定され得る。

ＳＬ ＬＣＰの間、第１の端末デバイスは、２つの選択を実行する必要がある。まず、第１の端末デバイスは、送信のための宛先アドレスを選択する。宛先アドレスは、複数のＱｏＳフローに対応する。異なるＱｏＳフローは、異なる論理チャネルにマッピングされる。論理チャネルの優先度は、論理チャネル上で搬送されるＱｏＳフローの優先度に基づいて決定される。

Ｓ３０４は、第１の端末デバイスが第１のＳＬリソースを取得したときにのみ実行されることが理解され得る。送信のための宛先アドレスを選択するとき、第１の端末デバイスは、送信されるべき宛先アドレスから、第１のデータまたは第１のシグナリングに対応する宛先アドレスのみを、送信のための宛先アドレスとして選択するか、または優先的に選択し、選択された宛先アドレスを送信のための論理チャネルにマッピングする。

送信されるべき宛先アドレスは、第１のデータまたは第１のシグナリングに対応する宛先アドレスと別の宛先アドレスとを含み得る。第１のデータまたは第１のシグナリングに対応する宛先アドレスのみが、送信されるべき宛先アドレスから選択されることは、第１のＳＬリソースについて、第１のデータまたは第１のシグナリングに対応する宛先アドレスのみが現在の送信における送信のために選択され、他の宛先アドレスは送信のために選択されないことと理解され得る。

代替的に、第１のデータまたは第１のシグナリングに対応する宛先アドレスが、送信されるべき宛先アドレスから優先的に選択されることは、送信のための宛先アドレスが、送信されるべき宛先アドレスの優先度に基づいて選択されることと理解され得る。第１のデータまたは第１のシグナリングに対応する宛先アドレスの優先度は最も高く設定され、第１の端末デバイスは、優先度が最も高い宛先アドレスを、送信のために優先的に選択する。したがって、第１の端末デバイスは、第１のデータまたは第１のシグナリングに対応する宛先アドレスを優先的に選択することができる。第１のデータまたは第１のシグナリングに対応する宛先アドレスが存在しないとき、別の宛先アドレスが送信のために選択され得ることが理解され得る。

第１の端末デバイスが論理チャネルを送信のために選択するとき、第１の端末デバイスは、送信されるべき論理チャネルから、第１のデータまたは第１のシグナリングに対応する論理チャネルのみを、送信のための論理チャネルとして選択するか、または優先的に選択する。

送信されるべき宛先論理チャネルが第１のデータまたは第１のシグナリングに対応する論理チャネルおよび別の論理チャネルを含み得るとき、第１のデータまたは第１のシグナリングに対応する論理チャネルのみが、伝送されるべき論理チャネルから選択されることは、第１のＳＬリソースについて、第１のデータまたは第１のシグナリングに対応する論理チャネルのみが、現在の送信における送信のために選択され、他の論理チャネルは送信のために選択されないことと理解され得る。

代替的に、送信されるべき論理チャネルから、第１のデータまたは第１のシグナリングに対応する論理チャネルを優先的に選択することは、送信されるべき論理チャネルの優先度に基づいて、論理チャネルを送信のために選択することと理解され得る。この実施形態では、第１のデータまたは第１のシグナリングに対応する論理チャネルの優先度は最も高く設定される。従来技術では、論理チャネルの優先度は、通常、論理チャネル上で搬送されるＱｏＳフローの論理チャネルに基づいて決定され、第１の端末デバイスは、送信のために優先度が最も高い論理チャネルを優先的に選択する。したがって、第１の端末デバイスは、第１のデータまたは第１のシグナリングに対応する論理チャネルを優先的に選択することができる。送信されるべき論理チャネル内の別の論理チャネルが送信されるとき、論理チャネルの優先度は、論理チャネル上で搬送されるＱｏＳフローの論理チャネルに基づいて決定され得る。第１のデータまたは第１のシグナリングに対応する論理チャネルが存在しないとき、別の論理チャネルが送信のために選択され得ることが理解され得る。

本出願の別の実施形態では、第１の端末デバイスは、代替的に、既存の解決策を使用することによって、送信のために第１のデータまたは第１のシグナリングに対応する宛先アドレス／論理チャネルを選択し得ることが理解され得る。

この実施形態では、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信するとき、第１の端末デバイスは、送信されるべき宛先アドレス／論理チャネルから、第１のデータまたは第１のシグナリングに対応する宛先アドレス／論理チャネルのみを、送信のために選択するか、または優先的に選択し、その結果、第１のデータまたは第１のシグナリングが優先的に送信されることが保証され、それによって、ＬＣＰによる第１のデータもしくは第１のシグナリングの送信遅延または破棄を回避することができる。マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする第１のデータまたは第１のシグナリングは、通常、重要なデータまたはシグナリングであるので、第１のデータまたは第１のシグナリングは優先的に送信され、それによって、ＳＬ通信の品質がさらに向上する。

図７は、本出願の実施形態３によるサイドリンク通信方法のシグナリングフローチャートである。実施形態１および実施形態２に基づいて、この実施形態では、基地局によるスケジューリングが、サイドリンク通信方法を説明するための例として使用される。この実施形態では、ネットワークデバイスが基地局である例が説明のために使用される。図７に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ４０１：第１の端末デバイスが、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定し、ここで、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである。

このステップの具体的な実装形態については、実施形態１におけるステップＳ２０１の説明を参照されたく、詳細は本明細書で改めて説明しない。

Ｓ４０２：第１の端末デバイスが、第１の要求メッセージを基地局に送信し、ここで、第１の要求メッセージは第２の指示情報を含む。

第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。任意選択で、第１の要求メッセージは、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージである。それに対応して、第２の指示情報は、ＳＵＩメッセージで搬送され得る。

Ｓ４０３：基地局が、第１の要求メッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

第１の要求メッセージがＳＬ ＳＲであるとき、例示的な方式では、第１の端末デバイスは、専用ＳＬ ＳＲを基地局に送信する。専用ＳＬ ＳＲを受信した後、基地局は、専用ＳＬ ＳＲに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。専用ＳＬ ＳＲは、第１の端末デバイスのために基地局または別のネットワークデバイスによって予め構成されてもよいし、プロトコルにおいて定義されてもよい。このように、専用ＳＬ ＳＲは、第２の指示情報を含まなくてもよく、基地局は、専用ＳＬ ＳＲに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し得る。任意選択で、専用ＳＬ ＳＲは、代替的に、第２の指示情報を含んでいてもよい。基地局は、専用ＳＬ ＳＲおよび第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

例えば、専用ＳＬ ＳＲに対応するＳＲ ＩＤは、プロトコルにおいて予め定義される。第１の端末デバイスがＳＲ ＩＤに対応するリソース上でＳＬ ＳＲをネットワークデバイスに送信するとき、ネットワークデバイスは、リソースに基づいて、第１の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するサイドリンク送信リソースを要求し、第１の端末デバイスのための対応するサイドリンク送信リソースを構成することを知ることができる。

別の実装形態では、専用ＳＬ ＳＲを受信する前に、基地局は、第１の端末デバイスの要求に基づいて、第１の端末デバイスのために専用ＳＬ ＳＲを構成する。専用ＳＬ ＳＲを構成することを要求するとき、第１の端末デバイスは、第２の指示情報を搬送する要求メッセージを基地局に送信する。基地局は、第２の指示情報に基づいて第１の端末デバイスのために専用ＳＬ ＳＲを構成する。

第１の要求メッセージがＳＬ ＳＲであるとき、別の例示的な方式では、第１の端末デバイスは、ＳＬ ＳＲ（共通ＳＬ ＳＲと呼ばれることもある）を基地局に送信し、ＳＬ ＳＲは第２の指示情報を含む。基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

第１の要求メッセージがＳＬ ＢＳＲであるとき、例示的な方式では、第１の端末デバイスは、専用ＬＣＧまたは専用宛先アドレスインデックスを使用することによって、ＳＬ ＢＳＲを基地局に送信し得る。ＳＬ ＢＳＲを受信した後、基地局は、ＳＬ ＢＳＲの専用ＬＣＧまたは専用宛先アドレスインデックスに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。専用ＬＣＧまたは専用宛先アドレスインデックスは、第１の端末デバイスのために基地局もしくは別のネットワークデバイスによって予め構成されてもよいし、プロトコルにおいて定義されてもよい。このように、ＳＬ ＢＳＲは、第２の指示情報を含まなくてもよく、基地局は、専用ＬＣＧまたは専用宛先アドレスインデックスに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し得る。任意選択で、ＳＬ ＢＳＲは、代替的に、第２の指示情報を含んでいてもよい。基地局は、専用ＬＣＧまたは専用宛先アドレスインデックスおよび第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

第１の要求メッセージがＳＬ ＢＳＲであるとき、別の例示的な方式では、第１の端末デバイスは、ＳＬ ＢＳＲの共通ＬＣＧまたは共通宛先アドレスインデックスを使用することによってＳＬ ＢＳＲを基地局に送信し、ＳＬ ＢＳＲは第２の指示情報を含む。基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

第１の要求メッセージがＳＬ ＢＳＲであるとき、さらに別の例示的な方式では、第１の端末デバイスは、特定のフォーマット（format）のＳＬ ＢＳＲを基地局に送信し、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。ＳＬ ＢＳＲを受信した後、基地局は、ＳＬ ＢＳＲのフォーマットに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージを受信した後、基地局は、ＵＡＩメッセージに含まれる第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

代替的に、ＵＡＩメッセージを受信する前に、基地局は、第１の端末デバイスによって送信されたＳＵＩメッセージを受信する。ＳＵＩメッセージは第２の指示情報を含み、第２の指示情報は、ＳＵＩメッセージに含まれる宛先アドレスまたはＱｏＳフローに関連付けられる。ＵＡＩメッセージを受信した後、ＵＡＩメッセージに含まれるＱｏＳフローまたはサービスモードが第２の指示情報に関連付けられた宛先アドレスまたはＱｏＳフローに対応するとき、基地局は、第１の端末デバイスによって要求されたＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

Ｓ４０４：基地局が、第１のＳＬリソースに関する情報を第１の端末デバイスに送信する。

基地局は、第１の要求メッセージの応答メッセージ、ＲＲＣ再構成メッセージ、または第１のＳＬリソースに関する情報を搬送するＤＣＩを第１の端末デバイスに送信し得る。

Ｓ４０５：第１の端末デバイスが、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを第２の端末デバイスに送信する。

第１の端末デバイスは、既存のＬＣＰ規則を使用することによって、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信してもよいし、実施形態２における方法を使用することによって、送信されるべき宛先アドレス／論理チャネルから、第１のデータまたは第１のシグナリングに対応する宛先アドレス／論理チャネルのみを選択するか、もしくは優先的に選択して、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信してもよい。具体的な実装形態については、実施形態２のステップ３０４の説明を参照されたい。詳細は本明細書で改めて説明しない。

それに対応して、第２の端末デバイスは、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを受信する。第１の端末デバイスは、マルチキャストまたはブロードキャスト方式で第１のデータまたは第１のシグナリングを送信し、マルチキャストまたはブロードキャスト受信範囲内の端末デバイスは、第１のデータまたは第１のシグナリングを受信するための第２の端末デバイスとして使用され得ることが理解され得る。

この実施形態では、第１の端末デバイスが第１の基地局にリソースを要求するとき、第２の指示情報は、第１の要求メッセージで搬送され、基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定して、要求されたリソースを第１の端末デバイスに割り当て得る。

図８は、本出願の実施形態４によるサイドリンク通信方法のシグナリングフローチャートである。この実施形態と実施形態３との間の違いは、以下の通りである：第１の要求メッセージを基地局に送信する前に、第１の端末デバイスは、まず、第２の指示情報を基地局に送信し、基地局は、第２の指示情報および第１の要求メッセージに基づいて、リソースを第１の端末デバイスに割り当てる。図８に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ５０１：第１の端末デバイスが、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定し、ここで、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである。

Ｓ５０２：第１の端末デバイスが、ＳＵＩメッセージを基地局に送信し、ここで、ＳＵＩメッセージは第２の指示情報を含む。

この実施形態は、第２の指示情報がＳＵＩメッセージで搬送される例を使用することによって説明される。第２の指示情報は別のメッセージで搬送されてもよく、この実施形態では限定されないことが理解され得る。

Ｓ５０３：第１の端末デバイスが、第１の要求メッセージを基地局に送信する。

任意選択で、第１の要求メッセージは、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージである。

Ｓ５０４：基地局が、第１の要求メッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

第１の要求メッセージがＳＬ ＳＲであるとき、例示的な方式では、第１の端末デバイスは、専用ＳＬ ＳＲを基地局に送信する。専用ＳＬ ＳＲを受信した後、基地局は、専用ＳＬ ＳＲに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。専用ＳＬ ＳＲは、ＳＵＩメッセージ内の第２の指示情報に基づいて、基地局によって第１の端末デバイスに割り当てられる。それに対応して、Ｓ５０３の前に、基地局は、ＳＵＩ応答メッセージまたは別のメッセージを通じて、専用ＳＬ ＳＲの構成情報を第１の端末デバイスに送信する。

第１の要求メッセージがＳＬ ＢＳＲであるとき、例示的な方式では、第１の端末デバイスは、専用ＬＣＧまたは専用宛先アドレスインデックスを使用することによって、ＳＬ ＢＳＲを基地局に送信し得る。ＳＬ ＢＳＲを受信した後、基地局は、ＳＬ ＢＳＲの専用ＬＣＧまたは専用宛先アドレスインデックスに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。専用ＬＣＧまたは専用宛先アドレスインデックスは、ＳＵＩメッセージ内の第２の指示情報に基づいて、第１の端末デバイスのために基地局によって構成される。それに対応して、Ｓ５０３の前に、基地局は、ＳＵＩ応答メッセージまたは別のメッセージを通じて、専用ＬＣＧまたは専用宛先アドレスインデックスの構成情報を第１の端末デバイスに送信する。

任意選択で、ＳＬ ＢＳＲは、代替的に、第２の指示情報を含んでいてもよい。基地局は、専用ＬＣＧまたは専用宛先アドレスインデックスおよび第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

第１の要求メッセージがＳＬ ＢＳＲであるとき、別の例示的な方式では、第１の端末デバイスは、共通ＬＣＧまたは共通宛先アドレスインデックスを使用することによって、ＳＬ ＢＳＲを基地局に送信する。ＳＬ ＢＳＲは、宛先アドレスインデックスまたはＱｏＳフロー識別子を含む。基地局は、第２の指示情報に関連付けられた宛先アドレスまたはＱｏＳフローと、ＳＬ ＢＳＲに含まれる宛先アドレスインデックスまたはＱｏＳフロー識別子とに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。具体的には、ＳＬ ＢＳＲに含まれる宛先アドレスインデックスまたはＱｏＳフロー識別子が、第２の指示情報に関連付けられた宛先アドレスまたはＱｏＳフローに対応するとき、基地局は、第１の端末デバイスによって要求されたＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージを受信した後、ＵＡＩメッセージに含まれるＱｏＳフロー情報およびサービスモードが第２の指示情報に関連付けられた宛先アドレスまたはＱｏＳフローに対応するとき、基地局は、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

Ｓ５０５：基地局が、第１のＳＬリソースに関する情報を第１の端末デバイスに送信する。

Ｓ５０６：第１の端末デバイスが、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを第２の端末デバイスに送信する。

この実施形態では、第１の基地局にリソースを要求する前に、第１の端末デバイスは、第２の指示情報を基地局に送信し、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示し、第１の要求メッセージを使用することによって基地局に第１のＳＬリソースを要求する。基地局は、第２の指示情報および第１の要求メッセージに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定して、要求されたリソースを第１の端末デバイスに割り当てる。

実際の適用では、端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸおよびユニキャストＳＬ ＤＲＸの両方をサポートする。ユニキャスト接続が確立される前に、端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースのみを使用することによって、送信または受信を実行し得る。具体的には、端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに対応する時間においてのみ無線周波数受信機を有効にする。端末デバイスは、いくつかの時点において（すなわち、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに対応する時間において）のみ受信を実行することができるので、送信側端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに対応する時間以外の時間においてデータを送信し、受信側端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに対応する時間においてのみデータを受信する場合、ユニキャスト接続を確立するプロセスにおけるメッセージは欠落し、ユニキャスト接続の確立に影響を及ぼす。

上記の問題を解決するために、本出願の実施形態５は、サイドリンク通信方法を提供する。図９は、本出願の実施形態５によるサイドリンク通信方法のシグナリングフローチャートである。この実施形態は、受信側の観点から説明される。図９に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ６０１：端末デバイスが、第１の時点において第１のＤＲＸの送信を非アクティブ化し、ここで、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸであり、第１の時点は、ＳＬユニキャスト接続確立要求メッセージの受信時点または発見要求メッセージの受信時点である。

この実施形態では、端末デバイスは、第１の時点において第１のＤＲＸを直ちに非アクティブ化し得るか、または第１の時点において予め設定された遅延時間の後に第１のＤＲＸを非アクティブ化し得る。予め設定された遅延時間は、ネットワークデバイスによって構成され得る。

任意選択で、第１の時点は、代替的に、告知メッセージの送信時点であってもよい。

Ｓ６０２：端末デバイスが、第２の時点において第１のＤＲＸをアクティブ化し、ここで、第２の時点は、ＳＬユニキャスト接続確立受諾メッセージの送信時点、第１のＰＣ５ ＲＲＣ再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である。

方法において、受信側端末デバイスは、第１の時点と第２の時点との間で第１のＤＲＸを無効にし、受信側端末デバイスは、通常のＳＬリソースに対応するすべての時間期間においてデータを受信する。この実施形態では、受信側端末デバイスが第１の時点と第２の時点との間で第１のＤＲＸを無効にした後、受信側端末デバイスは、第１の時点と第２の時点との間の受信リソースプールに対応するすべての時間にデータを受信することができることを意味し、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上でのみデータを受信することに限定されない。

第１の時点は、ＳＬユニキャスト接続確立メッセージ（すなわち、図３に示される第１のメッセージ）の受信時点または発見要求メッセージ（例えば、要請の発見メッセージ）の受信時点であり、第２の時点に受信されるメッセージは、第１の時点に受信されるメッセージに対応する。それに対応して、第２の時点は、ＳＬユニキャスト接続確立受諾メッセージ（すなわち、図３に示される第４のメッセージ）の送信時点、第１のＰＣ５ ＲＲＣ再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である。

任意選択で、第１のタイマは、第１の時点に開始され、第１のタイマのタイミング期間は、予め構成されるか、または予め定義される。任意選択で、端末デバイスは、代替的に、第１の時点から特定の時間の遅延の後に第１のタイマを有効にしてもよい。

第１の時点および第２の時点の値から、この実施形態における方法は、ユニキャスト接続の確立の開始からユニキャスト接続の確立の完了までの時間期間において第１のＤＲＸを無効にすることと同等であり、すなわち、受信側端末デバイスは、ユニキャスト接続の確立の開始からユニキャスト接続の確立の完了までの時間期間においてデータを正常に受信することができ、ユニキャスト接続を確立するプロセスにおいて送信側デバイスによって送信されたすべてのメッセージを受信側端末デバイスが受信することができ、ユニキャスト接続を確立するプロセスにおけるメッセージが欠落せず、マルチキャストまたはブロードキャストＳＬ ＤＲＸがユニキャスト接続の確立に影響を及ぼさないことを保証することがわかる。

この実施形態では、受信側の観点から、送信側にも同様の問題が存在する。この実施形態では、送信側端末デバイスは、第３の時点において第１のＤＲＸを非アクティブ化し、第４の時点において第１のＤＲＸをアクティブ化し得る。言い換えれば、送信側端末デバイスは、第３の時点と第４の時点との間の第１のＤＲＸを無効にする。第３の時点は、ＳＬユニキャスト接続確立メッセージの送信時点または発見要求メッセージの送信時点であり得る。それに対応して、第４の時点は、ＳＬユニキャスト接続確立受諾メッセージの受信時点、第１のＰＣ５ ＲＲＣ再構成メッセージの送信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマの有効化時点である。

任意選択で、第３の時点は、代替的に、告知メッセージの受信時点であってもよい。

ユニキャスト接続が確立された後には、マルチキャストまたはブロードキャストＳＬ ＤＲＸおよびユニキャストＳＬ ＤＲＸの両方が存在する。それに対応して、端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを使用することによって送信または受信を実行することができ、またはユニキャスト接続に対応するＳＬリソースを使用することによって送信または受信を実行することができる。この実施形態では、端末デバイスは、時間領域におけるマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースとユニキャストＳＬ ＤＲＸに対応するリソースとの和集合を、端末デバイスがデータを送信または受信するための時間として使用し得る。

図１１は、端末デバイスがデータを送信する概略図である。図１１に示すように、データを送信するために第１の端末デバイスによって占有されるＳＬリソース（すなわち、図中の斜線部分によって示されるリソース）の一部は、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース（すなわち、図中の灰色部分によって示されるリソース）内に位置し、他の部分は、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースの外側に位置する。例えば、第１の端末デバイスによって送信されるデータ内のＳＣＩによって占有されるリソースは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース内に位置し、ＳＣＩによって示されるトランスポートブロック（transport block、ＴＢ）により占有されるリソースの全部または一部は、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースの外側に位置する。この場合、第２の端末デバイスが第１の端末デバイスによって送信されたデータに関心があり、第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸをアクティブ化する場合、第２の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上でＳＣＩを正常に受信し得るが、ＳＣＩによって示されるＴＢを、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で受信することはできない。従来の技術では、ＴＢをどのように処理するかが説明されておらず、これは、ＳＬ通信における例外または端末デバイスの受信例外を引き起こし得る。

前述の問題を解決するために、一実施形態は、サイドリンク通信方法を提供する。図１２は、本出願の実施形態６によるサイドリンク通信方法のフローチャートである。図１２に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ７０１：第２の端末デバイスが、第１の端末デバイスによって送信されたＳＣＩを受信する。

Ｓ７０２：第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸ状態にあり、ＳＣＩによって示されるＴＢに対応するリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに属さないかまたは部分的に属するとき、第２の端末デバイスが、ＳＣＩによって示されるＴＢを受信しないか、または第２の端末デバイスが、ＳＣＩによって示されるＴＢを受信するが、ＳＣＩに対応するハイブリッド自動再送要求ラウンドトリップタイマ（hybrid automatic repeat request round trip time、ＨＡＲＱ ＴＴＴ）タイマまたは非アクティビティ（ＩＮＡＣＴＩＶＩＴＹ）タイマを有効にしない。

第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸ状態にあることは、第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸを現在アクティブ化していること、または第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを使用することによってデータを現在受信していることと理解され得る。

ＨＡＲＱ ＴＴＴタイマは、ＨＡＲＱプロセスに関連付けられる。ＨＡＲＱ ＴＴＴタイマが動作しているとき、端末デバイスは、物理サイドリンク制御チャネル（physical sidelink control channel、ＰＳＣＣＨ）チャネルをリッスンする必要はなく、ＰＳＣＣＨチャネルは、ＳＣＩを送信するために使用される。従来技術では、ＳＣＩを受信した後、第２の端末デバイスは、ＨＡＲＱ ＴＴＴタイマを有効にし、ＳＣＩによって示されるＴＢを受信する。この実施形態では、ＳＣＩを受信した後、第２の端末デバイスは、ＨＡＲＱ ＴＴＴタイマを有効にせず、対応する再送データの後続の受信を回避する。

ＩＮＡＣＴＩＶＩＴＹタイマは、ユニキャスト接続に関連付けられる。ＩＮＡＣＴＩＶＩＴＹタイマが動作しているとき、端末デバイスは、ＰＳＣＣＨチャネルをリッスンする必要がある。従来技術では、ＳＣＩを受信した後、ＳＣＩが新規送信を示す場合、第２の端末デバイスは、ＩＮＡＣＴＩＶＩＴＹタイマを有効にし、ＳＣＩによって示されるＴＢを受信する。この実施形態では、ＳＣＩを受信した後、第２の端末デバイスは、ＩＮＡＣＴＩＶＩＴＹタイマを有効にせず、対応する再送データの後続の受信を回避する。

この実施形態では、第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸ状態にあり、受信されたＳＣＩによって示されるＴＢに対応するリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに属さないかまたは部分的に属するとき、第２の端末デバイスのアクションが指定され、すなわち、第２の端末デバイスは、ＳＣＩによって示されるＴＢを受信しないか、またはＳＣＩによって示されるＴＢを受信するが、ＳＣＩに対応するＨＡＲＱ ＲＴＴタイマまたはＩＮＡＣＴＩＶＩＴＹタイマを有効にせず、その結果、通常のＳＬ通信を保証することができる。

図１３は、本出願の実施形態７による第１の端末デバイスの構造の概略図である。図１３に示すように、この実施形態において提供される第１の端末デバイス２００は、決定モジュール２１と、取得モジュール２２と、送信モジュール２３とを含む。

決定モジュール２１は、第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすると決定するように構成され、第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸである。

取得モジュール２２は、第１のＳＬリソースを取得するように構成され、第１のＳＬリソースは、第１のＤＲＸに対応するＳＬリソースである。

送信モジュール２３は、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信するように構成される。

任意選択で、決定モジュール２１は、第１の端末デバイスの上位層から第１の指示情報を受信するように特に構成され、第１の指示情報は、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示す。

任意選択で、第１の指示情報は、第１のデータに関連付けられたサービスまたはＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを含む。

任意選択で、取得モジュール２２は、第１の要求メッセージをネットワークデバイスに送信することであって、第１の要求メッセージは、第１のＳＬリソースを要求するためのものである、送信することと、ネットワークデバイスによって送信された第１のＳＬリソースに関する情報を受信することとを行うように特に構成される。

例示的な方式では、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

別の例示的な方式では、取得モジュール２２は、第１の要求メッセージをネットワークデバイスに送信する前に、第２の指示情報をネットワークデバイスに送信するようにさらに構成され、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージである。

第１の要求メッセージが、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージであるとき、任意選択で、第２の指示情報は、ＳＵＩメッセージで搬送される。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む。

任意選択で、取得モジュール２２は、アイドルＳＬリソースを測定することによって第１のＳＬリソースを取得するように特に構成される。

任意選択で、送信モジュール２３は、送信されるべき宛先アドレスから、第１のデータまたは第１のシグナリングに対応する宛先アドレスのみを、送信のための宛先アドレスとして選択するか、または優先的に選択するように、または送信されるべき論理チャネルから、第１のデータまたは第１のシグナリングに対応する論理チャネルのみを、送信のための論理チャネルとして選択するか、または優先的に選択するように特に構成される。

この実施形態において提供される第１の端末デバイス２００は、実施形態１から実施形態４における第１の端末デバイスによって実行される方法ステップを実行するように構成され得る。具体的な実装形態および技術的効果は同様であり、詳細は本明細書で改めて説明しない。

図１４は、本出願の実施形態８によるネットワークデバイスの構造の概略図である。図１４に示すように、この実施形態において提供されるネットワークデバイス３００は、受信モジュール３１および割り当てモジュール３２を含む。

受信モジュール３１は、第１の端末デバイスによって送信された第１の要求メッセージを受信するように構成され、第１の要求メッセージは、第１のサイドリンク（ＳＬ）リソースを要求するためのものであり、第１のＳＬリソースは、第１の間欠受信（ＤＲＸ）に対応するＳＬリソースであり、第１のＤＲＸは、マルチキャストまたはブロードキャストＤＲＸである。

割り当てモジュール３２は、第１の要求メッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように構成される。

例示的な方式では、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

別の例示的な方式では、受信モジュール３１は、第１の要求メッセージを受信する前に、第１の端末デバイスによって送信された第２の指示情報を受信するようにさらに構成され、第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージである。

第１の要求メッセージが、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージであるとき、任意選択で、第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む。

この実施形態において提供されるネットワークデバイス３００は、実施形態１から実施形態４におけるネットワークデバイスによって実行される方法ステップを実行するように構成され得る。具体的な実装形態および技術的効果は同様であり、詳細は本明細書で改めて説明しない。

図１５は、本出願の実施形態９による第２の端末デバイスの構造の概略図である。図１５に示すように、この実施形態において提供される第２の端末デバイス４００は、受信モジュール４１と、決定モジュール４２と、アクティブ化モジュール４３とを含む。

受信モジュール４１は、第２の端末デバイスの上位層から第１の指示情報を受信するように構成され、第１の指示情報は、第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすることを示し、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである。

決定モジュール４２は、第１の指示情報に基づいて、現在受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートすると決定するように構成される。

アクティブ化モジュール４３は、第１のＤＲＸをアクティブ化するように構成される。

受信モジュール４１およびアクティブ化モジュール４３は、代替的に、１つのモジュール、例えば、処理モジュールを使用することによって実装されてもよいことが理解され得る。処理モジュールは、受信モジュール４１およびアクティブ化モジュール４３のすべての機能を実装する。

この実施形態において提供される第２の端末デバイス４００は、実施形態１から実施形態４における第２の端末デバイスによって実行される方法ステップを実行するよう構成され得る。具体的な実装形態および技術的効果は同様であり、詳細は本明細書で改めて説明しない。

図１６は、本出願の実施形態１０による第２の端末デバイスの構造の概略図である。図１６に示すように、この実施形態において提供される第２の端末デバイス５００は、非アクティブ化モジュール５１およびアクティブ化モジュール５２を含む。

非アクティブ化モジュール５１は、第１の時点において第１の間欠受信（ＤＲＸ）を非アクティブ化するように構成され、第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸであり、第１の時点は、ＳＬユニキャスト接続確立メッセージの受信時点または発見要求メッセージの受信時点である。

アクティブ化モジュール５２は、第２の時点において第１のＤＲＸをアクティブ化するように構成され、第２の時点は、ＳＬユニキャスト接続確立受諾メッセージの受信時点、第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である。

任意選択で、端末デバイスは、第１の時点に第１のタイマを開始する。

任意選択で、非アクティブ化モジュール５１は、第１の時点においてプリセット時間が遅延した後に第１のＤＲＸを非アクティブ化するように特に構成される。

非アクティブ化モジュール５１およびアクティブ化モジュール５２は、代替的に、１つのモジュール、例えば、処理モジュールを使用することによって実装されてもよいことが理解され得る。処理モジュールは、非アクティブ化モジュール５１およびアクティブ化モジュール５２のすべての機能を実装する。

この実施形態において提供される第２の端末デバイス５００は、実施形態５における方法を実行するように構成され得る。具体的な実装形態および技術的効果は同様であり、詳細は本明細書で改めて説明しない。

本出願の実施形態におけるモジュールは、ユニットとも呼ばれ得ることが理解され得る。例えば、非アクティブ化モジュールは、非アクティブ化ユニットと呼ばれることもある。

本出願で説明されるシステム、装置、および方法は、他の方式で実装され得る。例えば、上述した装置の実施形態は単なる例である。例えば、ユニット／モジュールの分割は、単なる論理的な機能分割であり、実際の実装時には他の分割であってもよい。例えば、複数のユニットまたは構成要素は、別のシステムに結合または統合されてもよいし、一部の特徴が無視されたり実行されなかったりしてもよい。加えて、表示または議論された相互結合または直接結合または通信接続は、いくつかのインターフェースを介して実装され得る。装置またはユニット間の間接結合または通信接続は、電子的に、機械的に、または他の形態で実装され得る。

加えて、本出願の実施形態における機能ユニットは、１つの処理ユニットに統合されてもよく、ユニットの各々は、物理的に独立して存在してもよく、または２つ以上のユニットが１つのユニットに統合されてもよい。

前述のモジュールまたはユニットは、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせを使用することによって実装され得る。例えば、図１３の決定モジュールは、ソフトウェアに基づいて実装され得る。

本出願では、「ソフトウェアを使用することによって実装される」は、プロセッサが、メモリに記憶されたプログラム命令を読み取って実行し、前述のモジュールまたはユニットに対応する機能を実装することを意味する。プロセッサは、プログラム命令を実行する機能を有する処理回路であり、限定はしないが、中央処理装置（central processing unit、ＣＰＵ）、マイクロプロセッサ、デジタルシグナルプロセッサ（digital signal processor、ＤＳＰ）、マイクロコントローラユニット（microcontroller unit、ＭＣＵ）、または人工知能プロセッサなどの、プログラム命令を実行することができる以下の処理回路のうちの少なくとも１つを含む。いくつかの他の実施形態では、プロセッサは、別の処理機能を有する回路（例えば、ハードウェアアクセラレーションのために使用されるハードウェア回路、バス、およびインターフェース回路）をさらに含み得る。プロセッサは、集積チップの形態で提示され得、例えば、処理機能がソフトウェア命令実行機能のみを含む集積チップの形態で提示されてもよいし、ＳｏＣ（system on a chip、システムオンチップ）の形態で提示されてもよい。すなわち、プログラム命令を実行することができる処理回路（通常、「コア」と呼ばれる）に加えて、チップは、特定の機能を実装するように構成された別のハードウェア回路（ＡＳＩＣまたはＦＰＧＡに基づいて実装され得る）をさらに含む。それに対応して、ソフトウェア命令実行機能に加えて、処理機能は、様々なハードウェアアクセラレーション機能（ＡＩ計算、符号化および復号、ならびに圧縮および解凍など）をさらに含み得る。

本出願では、「ハードウェアによって実装される」は、前述のモジュールまたはユニットの機能が、プログラム命令を処理する機能を有さないハードウェア処理回路を通して実装されることを意味する。ハードウェア処理回路は、ディスクリートハードウェア構成要素を含み得るか、または集積回路であり得る。電力消費およびサイズを低減するために、通常、集積回路が実装に使用される。ハードウェア処理回路は、特定用途向け集積回路（application-specific integrated circuit、ＡＳＩＣ）またはプログラマブル論理デバイス（programmable logic device、ＰＬＤ）を含み得る。ＰＬＤは、フィールドプログラマブルゲートアレイ（field programmable gate array、ＦＰＧＡ）、複合プログラマブル論理デバイス（complex programmable logic device、ＣＰＬＤ）などをさらに含み得る。これらのハードウェア処理回路は、個別にパッケージ化された半導体チップであってもよいし、他の回路（ＣＰＵ、ＤＳＰなど）と集積されてパッケージ化された半導体チップであってもよい。例えば、ＡＳＩＣおよびＣＰＵは、一緒に統合されてＳｏＣを形成してもよく、ＳｏＣは、チップに独立してパッケージ化されるか、または、ＦＰＧＡおよびＣＰＵは、一緒に統合されてＳｏＰＣ（システムオンプログラマブルチップ、system on a programmable chip）を形成してもよい。

本出願がソフトウェア、ハードウェア、またはソフトウェアとハードウェアとの組み合わせを使用することによって実装されるとき、本出願は、１つのタイプのソフトウェアまたはハードウェアのみに限定されない、異なるソフトウェアおよびハードウェアを使用することによって実装され得ることに留意されたい。例えば、モジュールまたはユニットのうちの１つは、ＣＰＵを通して実装され得、別のモジュールまたはユニットは、ＤＳＰを通して実装され得る。同様に、ハードウェアが実装に使用されるとき、モジュールまたはユニットのうちの１つは、ＡＳＩＣを通して実装され得、別のモジュールまたはユニットは、ＦＰＧＡを通して実装され得る。当然ながら、いくつかまたはすべてのモジュールまたはユニットが、同じタイプのソフトウェアを使用することによって（例えば、ＣＰＵを通して）、または同じタイプのハードウェアを使用することによって（例えば、ＡＳＩＣを通して）実装されることも指定されない。加えて、当業者であれば、ソフトウェアは通常、ハードウェアよりも柔軟性は良好であるが性能は低く、ハードウェアは対蹠的であることを知っているであろう。したがって、当業者は、実際の要件に基づいて、実装のためにソフトウェア、ハードウェア、またはそれらの組み合わせを選択し得る。

図１７は、本出願の実施形態１１による端末デバイスの構造の概略図である。図１７に示すように、端末デバイス６００は、プロセッサ６１と、メモリ６２と、トランシーバ６３とを含む。メモリ６２は、命令を記憶するように構成される。トランシーバ６３は、別のデバイスと通信するように構成される。プロセッサ６１は、端末デバイス６００が、前述の方法の実施形態における第１の端末デバイスまたは第２の端末デバイスによって実行される方法を実行することができるように、メモリに記憶された命令を実行するように構成される。

本出願の実施形態１２は、ネットワークデバイスを提供する。ネットワークデバイスの構造については、図１７を参照されたい。メモリ６２は、命令を記憶するように構成される。トランシーバ６３は、別のデバイスと通信するように構成される。プロセッサ６１は、ネットワークデバイスが、前述の方法の実施形態におけるネットワークデバイスによって実行される方法を実行することができるように、メモリ６２に記憶された命令を実行するように構成される。

具体的な実装形態では、一実施形態において、ネットワークデバイスまたは端末デバイスは、複数のプロセッサを含み得る。プロセッサの各々は、シングルコアプロセッサ（シングルＣＰＵ）であってもよいし、マルチコアプロセッサ（マルチＣＰＵ）であってもよい。プロセッサは、デジタルシグナルプロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、別の同等の集積またはディスクリート論理回路などであってもよい。

メモリは、読取り専用メモリ(read-only memory、ＲＯＭ）もしくは静的情報および命令を記憶することができる別のタイプの静的記憶デバイス、またはランダムアクセスメモリ（random access memory、ＲＡＭ）もしくは情報および命令を記憶することができる別のタイプの動的記憶デバイスであってもよいし、電気的消去可能プログラマブル読取り専用メモリ（Electrically Erasable Programmable Read-Only Memory、ＥＥＰＲＯＭ）、コンパクトディスク読取り専用メモリ（Compact Disc Read-Only Memory、ＣＤ－ＲＯＭ）もしくは別のコンパクトディスクストレージ、または光ディスクストレージ（圧縮光ディスク、レーザディスク、光ディスク、デジタル多用途ディスク、ブルーレイディスクなどを含む）、磁気ディスクストレージ媒体もしくは別の磁気記憶デバイス、または予想されるプログラムコードを命令もしくはデータ構造の形態で搬送もしくは記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の媒体であってもよいが、これらに限定されない。メモリは、独立して存在してもよく、通信バスによってプロセッサに接続されてもよい。メモリは、代替的に、プロセッサと統合されてもよい。

本出願の実施形態１３は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は命令を記憶し、命令が実行されると、コンピュータは、前述の方法の実施形態における第１の端末デバイスまたは第２の端末デバイスによって実行される方法を実行することが可能になる。

本出願の実施形態１４は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は命令を記憶し、命令が実行されると、コンピュータは、前述の方法の実施形態におけるネットワークデバイスによって実行される方法を実行することが可能になる。

本出願は、コンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータによって実行されると、前述の方法の実施形態のいずれか１つの機能が実装される。

前述の説明は、本出願の例示的な具体的な実装形態にすぎず、本出願の保護範囲を限定するものではない。本出願において開示される技術的範囲内で当業者によって容易に考え出される任意の変形または置換は、本出願の保護範囲内に入るものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

本出願は、通信技術に関し、特に、サイドリンク通信方法および装置に関する。

ユーザ機器（user equipment、ＵＥ）は、ネットワークを通じて互いに通信してもよいし、互いに直接通信してもよい。ＵＥ間の直接通信は、サイドリンク（sidelink、ＳＬ）通信とも呼ばれる。ＳＬ通信では、ＰＣ５エアインターフェースを介して２つのＵＥ間でデータが送信される。ＳＬ通信の典型的な適用例は、車車間・路車間（vehicle to everything、Ｖ２Ｘ）シナリオである。Ｖ２Ｘシナリオでは、１つの車両が１つのＵＥである。

ＳＬ通信のプロセスにおいて、ＵＥの電力消費を低減するために、送信側ＵＥまたは受信側ＵＥは、間欠受信（discontinuous reception、ＤＲＸ）メカニズムを使用し得る。ＤＲＸメカニズムとは、ＵＥが、送信または受信されるべきデータを有していないとき、ＵＥが、ある時間期間において送信機または受信機をオフにして、電力消費を低減することを意味する。ＤＲＸサイクルは、アクティブ時間（active time）およびスリープ時間（または非アクティブ時間と呼ばれる）を含む。ＵＥは、アクティブ時間にデータを送信または受信し、スリープ時間ではデータを送信または受信しない。従来技術では、ＵＥは、ユニキャスト方式に基づいてＳＬ ＤＲＸをサポートし得、ならびに／またはブロードキャスト方式およびマルチキャスト方式に基づいてＳＬ ＤＲＸをサポートし得る。

しかしながら、送信側ＵＥが、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを送信するとき、送信側ＵＥによって使用されるＳＬ送信リソースは、ブロードキャストおよびマルチキャストＳＬ ＤＲＸ状態にある受信側ＵＥによって使用されるＳＬ受信リソースに対応しないことがある。その結果、受信側ＵＥは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを受信することができず、ＳＬ通信の品質が影響を受ける。

本出願の実施形態は、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするサービスまたはシグナリングの欠落を回避し、ＳＬ通信の品質を向上させるためのサイドリンク通信方法および装置を提供する。

本出願の第１の態様は、第１の端末デバイスに適用されるサイドリンク通信方法を提供する。方法は、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定するステップであって、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである、ステップと、第１のＳＬリソースを取得するステップであって、第１のＳＬリソースは、第１のＤＲＸに対応するＳＬリソースである、ステップと、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信するステップとを含む。マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする対応するデータまたはシグナリングを送信するとき、第１の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースを取得し、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースを使用することによってデータまたはシグナリングを送信する。送信側によって使用される送信リソースと受信側によって使用される受信リソースの両方がマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであるので、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする対応するデータまたはシグナリングが受信側によって正常に受信されることが保証され、それによって、ＳＬ通信の品質を向上させることができる。

例示的な方式では、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定するステップは、アクセス層が上位層から第１の指示情報を受信し、第１の指示情報は、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示すことを含む。

例示的な方式では、第１の指示情報は、第１のデータに関連付けられたサービスまたはサービス品質（ＱｏＳ）フローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを含む。

例示的な方式では、第１のＳＬリソースを取得するステップは、第１の要求メッセージをネットワークデバイスに送信するステップであって、第１の要求メッセージは、第１のＳＬリソースを要求するためのものである、ステップと、ネットワークデバイスによって送信された第１のＳＬリソースに関する情報を受信するステップとを含む。

任意選択で、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

代替的に、第１の端末デバイスが第１の要求メッセージをネットワークデバイスに送信する前に、第１の端末デバイスは、第２の指示情報をネットワークデバイスに送信し、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである。

第１の要求メッセージが、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであるとき、任意選択で、第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される。

例示的な方式では、第１の要求メッセージは、専用ＳＬ ＳＲであり、第１のＳＬリソースは、専用ＳＬ ＳＲに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

別の例示的な方式では、第１の要求メッセージが専用ＳＬ ＳＲであるとき、第１の端末デバイスが専用ＳＬ ＳＲをネットワークデバイスに送信する前に、第１の端末デバイスは、ＳＵＩメッセージをネットワークデバイスに送信し、ＳＵＩメッセージは第２の指示情報を含み、第１の端末デバイスは、ネットワークデバイスによって構成された専用ＳＬ ＳＲを受信する。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＳＲであるとき、ＳＬ ＳＲは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、第１の端末デバイスは、専用ＬＣＧまたは専用宛先インデックスを使用することによって、ＳＬ ＢＳＲをネットワークデバイスに送信する。第１のＳＬリソースは、専用ＬＣＧもしくは専用宛先インデックスに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられるか、またはプロトコルにおいて予め定義される。

別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、第１の端末デバイスが専用ＬＣＧまたは専用宛先インデックスを使用することによってＳＬ ＢＳＲをネットワークデバイスに送信する前に、第１の端末デバイスは、ＳＵＩメッセージをネットワークデバイスに送信し、ＳＵＩメッセージは第２の指示情報を含み、第１の端末デバイスは、ネットワークデバイスによって送信された、専用ＬＣＧまたは専用宛先インデックスの構成情報を受信し、専用ＬＣＧまたは専用宛先インデックスは、第２の指示情報に基づいてネットワークデバイスによって構成される。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲをネットワークデバイスに送信する前に、第１の端末デバイスは、ＳＵＩをネットワークデバイスに送信し、ＳＵＩは第２の指示情報を含む。

さらに別の例示的な方式では、第１の要求メッセージは、特定のフォーマットのＳＬ ＢＳＲであり、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。第１のＳＬリソースは、ＳＬ ＢＳＲのフォーマットに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

別の例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージをネットワークデバイスに送信する前に、第１の端末デバイスは、ＳＵＩメッセージをネットワークデバイスに送信し、ＳＵＩメッセージは第２の指示情報を含む。第１のＳＬリソースは、半永続的スケジューリング（ＳＰＳ）リソースであり、第１のＳＬリソースは、第２の指示情報およびＵＡＩメッセージに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５ ＲＲＣ再構成メッセージのうちの１つまたは複数のシグナリングを含む。

別の例示的な方式では、第１の端末デバイスが第１のサイドリンク（ＳＬ）リソースを取得することは、第１の端末デバイスが、アイドルＳＬリソースを測定することによって第１のＳＬリソースを取得することを含む。

例示的な方式では、第１の端末デバイスが第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信することは、第１の端末デバイスが、送信されるべき宛先から、第１のデータまたは第１のシグナリングに対応する宛先のみを、送信のための宛先として選択するか、または優先的に選択することを含む。

第１のデータまたは第１のシグナリングに対応する宛先のみが、送信のために、送信されるべき宛先から選択されるか、または優先的に選択されるので、第１のデータまたは第１のシグナリングが優先的に送信されることが保証され、それによって、ＬＣＰによる第１のデータもしくは第１のシグナリングの送信遅延または破棄を回避することができる。

別の例示的な方式では、第１の端末デバイスが第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信することは、第１の端末デバイスが、送信されるべき論理チャネルから、第１のデータまたは第１のシグナリングに対応する論理チャネルのみを、送信のための論理チャネルとして選択するか、または優先的に選択することを含む。

第１のデータまたは第１のシグナリングに対応する論理チャネルのみが、送信のために、送信されるべき論理チャネルから選択されるか、または優先的に選択されるので、第１のデータまたは第１のシグナリングが優先的に送信されることが保証され、それによって、ＬＣＰによる第１のデータもしくは第１のシグナリングの送信遅延または破棄を回避することができる。

本出願の第２の態様は、ネットワークデバイスに適用されるサイドリンク通信方法を提供する。方法は、第１の端末デバイスによって送信された第１の要求メッセージを受信するステップであって、第１の要求メッセージは、第１のサイドリンク（ＳＬ）リソースを要求するためのものであり、第１のＳＬリソースは、第１の間欠受信（ＤＲＸ）に対応するＳＬリソースであり、第１のＤＲＸは、マルチキャストまたはブロードキャストＤＲＸである、ステップと、第１の要求メッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるステップとを含む。送信側は、第１の要求メッセージを送信することによって、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースをネットワークデバイスに要求し、ネットワークデバイスは、第１の要求メッセージに基づいて、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースを送信側に割り当てる。送信側によって使用される送信リソースおよび受信側によって使用される受信リソースの両方がマルチキャストまたはブロードキャストに対応するＳＬリソースであるので、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングが受信側によって正常に受信されることが保証され、それによって、ＳＬ通信の品質を向上させることができる。

例示的な方式では、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

例示的な方式では、ネットワークデバイスが第１の端末デバイスによって送信された第１の要求メッセージを受信する前に、方法は、ネットワークデバイスが第１の端末デバイスによって送信された第２の指示情報を受信することをさらに含み、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであり、第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される。

例示的な方式では、第１の要求メッセージは、専用ＳＬ ＳＲであり、専用ＳＬ ＳＲは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを要求するためのものであり、ネットワークデバイスは、専用ＳＬ ＳＲに基づいて、ＳＬ ＳＲによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

別の例示的な方式では、ネットワークデバイスが専用ＳＬ ＳＲを受信する前に、ネットワークデバイスは、第１の端末デバイスによって送信されたＳＵＩメッセージを受信し、ＳＵＩメッセージは第２の指示情報を含み、ネットワークデバイスは、第２の指示情報に基づいて第１の端末デバイスのための専用ＳＬ ＳＲを構成する。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＳＲであるとき、ＳＬ ＳＲは第２の指示情報を含み、ネットワークデバイスは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは、専用ＬＣＧまたは専用宛先インデックスを使用することによって、第１の端末デバイスによってネットワークデバイスに送信される。ネットワークデバイスは、専用ＬＣＧまたは専用宛先インデックスに基づいて、ＳＬ ＢＳＲによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ネットワークデバイスがＳＬ ＢＳＲを受信する前に、ネットワークデバイスは、第１の端末デバイスによって送信されたＳＵＩメッセージを受信し、ＳＵＩメッセージは第２の指示情報を含み、第１の端末デバイスは、第２の指示情報に基づいてＳＬ ＢＳＲのための専用ＬＣＧまたは専用宛先インデックスを構成する。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは第２の指示情報を含む。ネットワークデバイスは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ネットワークデバイスがＳＬ ＢＳＲを受信する前に、ネットワークデバイスは、第１の端末デバイスによって送信されたＳＵＩメッセージを受信し、ＳＵＩは第２の指示情報を含み、ネットワークデバイスは、第２の指示情報およびＳＬ ＢＳＲに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

さらに別の例示的な方式では、第１の要求メッセージは、特定のフォーマットのＳＬ ＢＳＲであり、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。ネットワークデバイスは、ＳＬ ＢＳＲのフォーマットに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージは第２の指示情報を含む。ネットワークデバイスは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

別の例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージを受信する前に、ネットワークデバイスは、第１の端末デバイスによって送信されたＳＵＩメッセージを受信し、ＳＵＩメッセージは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報およびＵＡＩメッセージに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられた第１のＳＬリソースであり、第１のＳＬリソースは、半永続的スケジューリング（ＳＰＳ）リソースである。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む。

本出願の第３の態様は、サイドリンク通信方法を提供する。アクセス層は、上位層から第１の指示情報を受信することであって、第１の指示情報は、第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすることを示し、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである、受信することと、第１の指示情報に基づいて、現在受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートすると決定されたとき、第１のＤＲＸをアクティブ化することとを行う。

本出願の第４の態様は、第２の端末デバイスに適用されるサイドリンク通信方法を提供し、方法は、第１の時点において第１の間欠受信（ＤＲＸ）を非アクティブ化するステップであって、第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸであり、第１の時点は、ＳＬユニキャスト接続確立メッセージの受信時点または発見要求メッセージの受信時点である、ステップと、第２の時点において第１のＤＲＸをアクティブ化するステップであって、第２の時点は、ＳＬユニキャスト接続確立受諾メッセージの受信時点、第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である、ステップとを含む。

方法において、受信側端末デバイスは、第１の時点と第２の時点との間で第１のＤＲＸを無効にする。第１のＤＲＸを無効にすることは、受信側端末デバイスが、通常のＳＬリソースに対応するすべての時間期間においてデータを受信することを意味するものであり、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上でのみデータを受信することに限定されない。したがって、受信側端末デバイスが、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするシグナリングまたはデータを正常に受信することが保証され、それによって、ＳＬ通信の品質を向上させることができる。

例示的な方式では、端末デバイスは、第１の時点に第１のタイマを開始する。

例示的な方式では、端末デバイスが第１の時点に第１のＤＲＸを非アクティブ化することは、以下を含む：
端末デバイスが、第１の時点においてプリセット時間が遅延した後に第１のＤＲＸを非アクティブ化すること。

本出願の第５の態様は、第２の端末デバイスに適用されるサイドリンク通信方法を提供し、方法は、第１の端末デバイスによって送信されたＳＣＩを受信するステップと、第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸ状態にあり、ＳＣＩによって示されるＴＢに対応するリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに属さないかまたは部分的に属するとき、ＳＣＩによって示されるＴＢの受信をスキップするか、またはＳＣＩによって示されるＴＢを受信するが、ＳＣＩに対応するＨＡＲＱ ＲＴＴタイマまたは非アクティビティタイマの開始をスキップするステップとを含む。

この実施形態では、第２の端末デバイスがＳＣＩを受信した後、ＳＣＩによって示されるＴＢに対応するＨＡＲＱ ＲＴＴタイマまたはＩＮＡＣＴＩＶＩＴＹタイマが開始されないので、対応する再送データの後続の受信を回避することができ、それによって、端末デバイスのエネルギー消費を低減する。

本出願の第６の態様は、以下を含む第１の端末デバイスを提供する：
第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすると決定するように構成された決定モジュールであって、第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸである、決定モジュール；
第１のＳＬリソースを取得するように構成された取得モジュールであって、第１のＳＬリソースは、第１のＤＲＸに対応するＳＬリソースである、取得モジュール；および
第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信するように構成された送信モジュール。

例示的な方式では、決定モジュールは、第１の端末デバイスの上位層から第１の指示情報を受信するように特に構成され、第１の指示情報は、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示す。

例示的な方式では、第１の指示情報は、第１のデータに関連付けられたサービスまたはサービス品質（ＱｏＳ）フローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを含む。

例示的な方式では、取得モジュールは、第１の要求メッセージをネットワークデバイスに送信することであって、第１の要求メッセージは、第１のＳＬリソースを要求するためのものある、送信することと、ネットワークデバイスによって送信された第１のＳＬリソースに関する情報を受信することとを行うように特に構成される。

任意選択で、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

代替的に、取得モジュールは、第１の要求メッセージをネットワークデバイスに送信する前に、第２の指示情報をネットワークデバイスに送信するようにさらに構成され、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである。

第１の要求メッセージが、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであるとき、任意選択で、第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される。

例示的な方式では、第１の要求メッセージは、専用ＳＬ ＳＲであり、第１のＳＬリソースは、専用ＳＬ ＳＲに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

別の例示的な方式では、第１の要求メッセージが専用ＳＬ ＳＲであるとき、取得モジュールが専用ＳＬ ＳＲをネットワークデバイスに送信する前に、取得モジュールは、ＳＵＩメッセージをネットワークデバイスに送信し、ＳＵＩメッセージは第２の指示情報を含み、取得モジュールは、ネットワークデバイスによって構成された専用ＳＬ ＳＲを受信する。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＳＲであるとき、ＳＬ ＳＲは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、取得モジュールは、専用ＬＣＧまたは専用宛先インデックスを使用することによって、ＳＬ ＢＳＲをネットワークデバイスに送信するように特に構成される。第１のＳＬリソースは、専用ＬＣＧもしくは専用宛先インデックスに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられるか、またはプロトコルにおいて予め定義される。

別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、専用ＬＣＧまたは専用宛先を使用することによってＳＬ ＢＳＲをネットワークデバイスに送信する前に、取得モジュールは、第２の指示情報を含むＳＵＩメッセージをネットワークデバイスに送信し、ネットワークデバイスによって送信された、専用ＬＣＧまたは専用宛先インデックスの構成情報を受信し、専用ＬＣＧまたは専用宛先インデックスは、第２の指示情報に基づいてネットワークデバイスによって構成される。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲをネットワークデバイスに送信する前に、取得モジュールは、ＳＵＩをネットワークデバイスに送信し、ＳＵＩは第２の指示情報を含む。

さらに別の例示的な方式では、第１の要求メッセージが特定のフォーマットのＳＬ ＢＳＲであるとき、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。第１のＳＬリソースは、ＳＬ ＢＳＲのフォーマットに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージは第２の指示情報を含む。第１のＳＬリソースは、第２の指示情報に基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

別の例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージをネットワークデバイスに送信する前に、取得モジュールは、ＳＵＩメッセージをネットワークデバイスに送信し、ＳＵＩメッセージは第２の指示情報を含む。第１のＳＬリソースは、半永続的スケジューリング（ＳＰＳ）リソースであり、第１のＳＬリソースは、第２の指示情報およびＵＡＩメッセージに基づいて、ネットワークデバイスによって第１の端末デバイスに割り当てられる。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む。

別の例示的な方式では、取得モジュールは、アイドルＳＬリソースを測定することによって第１のＳＬリソースを取得するように特に構成される。

例示的な方式では、送信モジュールは、送信されるべき宛先から、第１のデータまたは第１のシグナリングに対応する宛先のみを、送信のための宛先として選択するか、または優先的に選択するように特に構成される。

別の例示的な方式では、送信モジュールは、送信されるべき論理チャネルから、第１のデータまたは第１のシグナリングに対応する論理チャネルのみを、送信のための論理チャネルとして選択するか、または優先的に選択するように特に構成される。

本出願の第６の態様および実装形態において提供される第１の端末デバイスは、本出願の第１の態様および実装形態において提供される方法を実行するように構成され得る。技術的効果は同様であり、詳細は本明細書で改めて説明しない。

本出願の第７の態様は、以下を含むネットワークデバイスを提供する：
第１の端末デバイスによって送信された第１の要求メッセージを受信するように構成された受信モジュールであって、第１の要求メッセージは、第１のサイドリンク（ＳＬ）リソースを要求するためのものであり、第１のＳＬリソースは、第１の間欠受信（ＤＲＸ）に対応するＳＬリソースであり、第１のＤＲＸは、マルチキャストまたはブロードキャストＤＲＸである、受信モジュール；および
第１の要求メッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように構成された割り当てモジュール。

例示的な方式では、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

別の例示的な方式では、受信モジュールは、第１の要求メッセージを受信する前に、第１の端末デバイスによって送信された第２の指示情報を受信するようにさらに構成され、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである。

第１の要求メッセージが、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであるとき、任意選択で、第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される。

例示的な方式では、第１の要求メッセージは、専用ＳＬ ＳＲであり、専用ＳＬ ＳＲは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを要求するためのものであり、割り当てモジュールは、専用ＳＬ ＳＲに基づいて、ＳＬ ＳＲによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成される。

別の例示的な方式では、専用ＳＬ ＳＲを受信する前に、受信モジュールは、第１の端末デバイスによって送信されたＳＵＩメッセージをさらに受信し、ＳＵＩメッセージは第２の指示情報を含み、ネットワークデバイスは、第２の指示情報に基づいて第１の端末デバイスのための専用ＳＬ ＳＲを構成するように構成された構成モジュールをさらに含む。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＳＲであるとき、ＳＬ ＳＲは第２の指示情報を含み、割り当てモジュールは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成される。

例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは、専用ＬＣＧまたは専用宛先インデックスを使用することによって、第１の端末デバイスによってネットワークデバイスに送信される。割り当てモジュールは、専用ＬＣＧまたは専用宛先インデックスに基づいて、ＳＬ ＢＳＲによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成される。

別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲを受信する前に、受信モジュールは、第１の端末デバイスによって送信されたＳＵＩメッセージをさらに受信し、ＳＵＩメッセージは第２の指示情報を含み、割り当てモジュールは、第２の指示情報およびＳＬ ＢＳＲに基づいて、ＳＬ ＢＳＲのための専用ＬＣＧまたは専用宛先インデックスを構成するように特に構成される。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ＳＬ ＢＳＲは第２の指示情報を含む。ネットワークデバイスは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

さらに別の例示的な方式では、第１の要求メッセージがＳＬ ＢＳＲであるとき、ネットワークデバイスがＳＬ ＢＳＲを受信する前に、ネットワークデバイスは、第１の端末デバイスによって送信されたＳＵＩメッセージを受信する。ＳＵＩは、第２の指示情報を含む。ネットワークデバイスは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように構成された構成モジュールをさらに含む。

さらに別の例示的な方式では、第１の要求メッセージは、特定のフォーマットのＳＬ ＢＳＲであり、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。割り当てモジュールは、ＳＬ ＢＳＲのフォーマットに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成される。

例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージは第２の指示情報を含む。割り当てモジュールは、第２の指示情報に基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成される。

別の例示的な方式では、第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージを受信する前に、受信モジュールは、第１のネットワークデバイスによって送信されたＳＵＩメッセージを受信し、ＳＵＩメッセージは第２の指示情報を含む。割り当てモジュールは、第２の指示情報およびＵＡＩメッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように特に構成され、第１のＳＬリソースは、半永続的スケジューリング（ＳＰＳ）リソースである。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む。

本出願の第７の態様および実装形態において提供されるネットワークデバイスは、本出願の第２の態様および実装形態において提供される方法を実行するように構成され得る。技術的効果は同様であり、詳細は本明細書で改めて説明しない。

本出願の第８の態様は、以下を含む第２の端末デバイスを提供する：
第２の端末デバイスの上位層から第１の指示情報を受信するように構成された受信モジュールであって、第１の指示情報は、第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすることを示し、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである、受信モジュール；
第１の指示情報に基づいて、現在受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートすると決定するように構成された決定モジュール；および
第１のＤＲＸをアクティブ化するように構成されたアクティブ化モジュール。

本出願の第８の態様において提供される第２の端末デバイスは、本出願の第３の態様において提供される方法を実行するように構成され得、技術的効果は同様である。詳細は本明細書で改めて説明しない。

本出願の第９の態様は、以下を含む端末デバイスを提供する：
第１の時点において第１の間欠受信（ＤＲＸ）を非アクティブ化するように構成された非アクティブ化モジュールであって、第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸであり、第１の時点は、ＳＬユニキャスト接続確立メッセージの受信時点または発見要求メッセージの受信時点である、非アクティブ化モジュール；および
第２の時点において第１のＤＲＸをアクティブ化するように構成されたアクティブ化モジュールであって、第２の時点は、ＳＬユニキャスト接続確立受諾メッセージの受信時点、第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である、アクティブ化モジュール。

例示的な方式では、端末デバイスは、第１の時点に第１のタイマを開始する。

例示的な方式では、非アクティブ化モジュールは、第１の時点においてプリセット時間が遅延した後に第１のＤＲＸを非アクティブ化するように特に構成される。

本出願の第８の態様および実装形態において提供される端末デバイスは、本出願の第４の態様および実装形態において提供される方法を実行するように構成され得る。技術的効果は同様であり、詳細は本明細書で改めて説明しない。

本出願の第１０の態様は、以下を含む第２の端末デバイスを提供する：
第１の端末デバイスによって送信されたＳＣＩを受信するように構成された受信モジュール；
受信モジュールは、第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸ状態にあり、ＳＣＩによって示されるＴＢに対応するリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに属さないかまたは部分的に属するとき、ＳＣＩによって示されるＴＢの受信をスキップするか、またはＳＣＩによって示されるＴＢを受信するが、ＳＣＩに対応するＨＡＲＱ ＲＴＴタイマまたは非アクティビティタイマの開始をスキップするようにさらに構成される。

本出願の第１０の態様において提供される第２の端末デバイスは、本出願の第５の態様において提供される方法を実行するように構成され得、技術的効果は同様である。詳細は本明細書で改めて説明しない。

本出願の第１１の態様は、プロセッサと、メモリと、トランシーバとを含む端末デバイスを提供する。メモリは、命令を記憶するように構成される。トランシーバは、別のデバイスと通信するように構成される。プロセッサは、端末デバイスが、本出願の第１の態様、第３の態様、第４の態様、第５の態様、および実装形態において提供される任意の方法を実行することができるように、メモリに記憶された命令を実行するように構成される。

本出願の第１２の態様は、プロセッサと、メモリと、トランシーバとを含むネットワークデバイスを提供する。メモリは、命令を記憶するように構成される。トランシーバは、別のデバイスと通信するように構成される。プロセッサは、ネットワークデバイスが、本出願の第２の態様および実装形態において提供される任意の方法を実行することができるように、メモリに記憶された命令を実行するように構成される。

本出願の第１３の態様は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、命令を記憶する。命令が実行されると、コンピュータは、本出願の第１の態様、第３の態様、第４の態様、第５の態様、および実装形態において提供される任意の方法を実行することが可能になる。

本出願の第１４の態様は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、命令を記憶する。命令が実行されると、コンピュータは、本出願の第２の態様および実装形態において提供される任意の方法を実行することが可能になる。

本出願の第１５の態様は、コンピュータプログラム製品を提供する。コンピュータプログラム製品は、命令を含む。命令が実行されると、コンピュータは、本出願の第１の態様、第３の態様、第４の態様、第５の態様、および実装形態において提供される任意の方法を実行することが可能になる。

本出願の第１６の態様は、コンピュータプログラム製品を提供する。コンピュータプログラム製品は、命令を含む。命令が実行されると、コンピュータは、本出願の第２の態様および実装形態において提供される任意の方法を実行することが可能になる。

本出願の第１７の態様は、第１の端末デバイスと、第２の端末デバイスと、ネットワークデバイスとを含む通信システムを提供する。第１の端末デバイスは、本出願の第１の態様および実装形態において提供される任意の方法を実行するように構成される。第２の端末デバイスは、本出願の第３の態様において提供される方法を実行するように構成される。ネットワークデバイスは、本出願の第２の態様および実装形態において提供される任意の方法を実行するように構成される。

本出願の実施形態において提供されるサイドリンク通信方法および装置によれば、第１の端末デバイス（送信側）が、送信されるべき第１のデータまたは第１のシグナリングを有するとき、第１の端末デバイスは、まず、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを決定する。第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするとき、第１の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを取得し、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを使用することによって第１のデータまたは第１のシグナリングを送信する。第１のデータまたは第１のシグナリングを送信するために送信側によって使用されるＳＬリソースは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであり、受信側端末デバイスもまた、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で第１のデータまたは第１のシグナリングを受信する。したがって、受信側端末デバイスが、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする第１のデータまたは第１のシグナリングを正常に受信することができることが保証され、それによって、ＳＬ通信品質を向上させることができる。

本出願が適用可能なネットワークアーキテクチャの概略図である。 ＳＬ ＤＲＸのユニキャスト接続確立プロセスの概略図である。 マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソースの概略図である。 マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソースの別の概略図である。 本出願の実施形態１によるサイドリンク通信方法のフローチャートである。 本出願の実施形態２によるサイドリンク通信方法のフローチャートである。 本出願の実施形態３によるサイドリンク通信方法のシグナリングのフローチャートである。 本出願の実施形態４によるサイドリンク通信方法のシグナリングのフローチャートである。 本出願の実施形態５によるサイドリンク通信方法のシグナリングのフローチャートである。 端末デバイスのＳＬリソースの概略図である。 端末デバイスがデータを送信する概略図である。 本出願の実施形態６によるサイドリンク通信方法のフローチャートである。 本出願の実施形態７による第１の端末デバイスの構造の概略図である。 本出願の実施形態８によるネットワークデバイスの構造の概略図である。 本出願の実施形態９による第２の端末デバイスの構造の概略図である。 本出願の実施形態１０による第２の端末デバイスの構造の概略図である。 本出願の実施形態１１による端末デバイスの構造の概略図である。

以下では、本出願の実施形態における添付の図面を参照して、本出願の実施形態における技術的解決策を説明する。本出願では、「少なくとも１つの（at least one）」は１つまたは複数を意味し、「複数の（a plurality of）」は２つ以上を意味する。「および／または（and/or）」という用語は、関連するオブジェクト間の関連関係を説明し、３つの関係が存在し得ることを表す。例えば、Ａおよび／またはＢは、Ａのみが存在する場合、ＡとＢの両方が存在する場合、およびＢのみが存在する場合を表し得、ＡおよびＢは、単数または複数とすることができる。文字「／」は、一般に、関連するオブジェクト間の「または」関係を示す。以下の項目（部分）またはその類似表現のうちの少なくとも１つは、単数の項目（部分）または複数の項目（部分）の任意の組み合わせを含む、これらの項目の任意の組み合わせを指す。例えば、ａ、ｂ、またはｃのうちの少なくとも１つ（部分）は、ａ、ｂ、ｃ、ａおよびｂ、ａおよびｃ、ｂおよびｃ、またはａ、ｂ、およびｃを表し得、ａ、ｂ、およびｃは、単数または複数とすることができる。加えて、本出願の実施形態における技術的解決策を明確に説明するために、本出願の実施形態では「第１の」および「第２の」などの用語を使用して、基本的に同じ機能または目的を提供する同じ項目または同様の項目を区別する。当業者は、「第１の」および「第２の」などの用語が量および実行順序を限定しないことを理解し得る。例えば、本出願の実施形態における第１のデバイスの「第１の」および第２のデバイスの「第２の」は、単に異なるデバイスを区別するために使用される。

本出願では、「例えば（for example）」または「など（such as）」という用語は、例、例示、または説明を与えることを表すために使用されることに留意されたい。本出願において「例」または「例えば」として説明される任意の実施形態または設計方式は、別の実施形態または設計方式よりも好ましい、またはより多くの利点を有するものとして説明されるべきではない。正確には、「例えば（for example）」または「例（example）」などの用語の使用は、関連する概念を特定の方法で提示することを意図している。

図１は、本出願が適用可能なネットワークアーキテクチャの概略図である。図１に示すように、ネットワークアーキテクチャは、ネットワークデバイス（例えば、基地局）１１と、第１の端末デバイス１２と、第２の端末デバイス１３とを含む。ネットワークデバイス１１は、Ｕｕエアインターフェースを介して第１の端末デバイス１２および第２の端末デバイス１３と通信する。第１の端末デバイス１２は、ＰＣ５エアインターフェースを介して第２の端末デバイス１３と通信する。ＰＣ５インターフェースを介した通信は、ＳＬ通信とも呼ばれる。図１は、説明のための例にすぎず、限定を構成するものではない。ネットワークアーキテクチャは、より多くのネットワークデバイスおよび端末デバイスをさらに含み得る。

ＳＬ通信のシナリオでは、第１の端末デバイス１２および第２の端末デバイス１３は、同じ基地局（例えば、基地局１１）のカバレッジ内に位置してもよいし、異なる基地局のカバレッジ内に位置してもよい。代替的に、一方の端末デバイスは基地局のカバレッジ内に位置し、他方の端末デバイスは基地局のカバレッジ外に位置する。代替的に、両方の端末デバイスが、基地局のカバレッジ外（out of coverage）に位置する。１つの送信側端末デバイスは、１つまたは複数の受信側端末デバイスとＳＬ通信を実行し得る。受信側端末デバイスの観点から、１つの受信側端末デバイスはまた、１つまたは複数の送信側端末デバイスとＳＬ通信を実行し得る。

本出願の実施形態における端末デバイスは、端末（terminal）、ユーザ機器（user equipment、ＵＥ）、アクセス端末、加入者ユニット、加入者局、移動局、リモート局、リモート端末、モバイルデバイス、ユーザ端末、ワイヤレス通信デバイス、ユーザエージェント、またはユーザ装置とも呼ばれる。端末デバイスは、ワイヤレスローカルエリアネットワーク（wireless local area network、ＷＬＡＮ）における局（station、ＳＴ）であってもよいし、携帯電話、コードレス電話、セッション開始プロトコル（session initiation protocol、ＳＩＰ）電話、ワイヤレスローカルループ（wireless local loop、ＷＬＬ）局、パーソナルデジタル処理（personal digital assistant、ＰＤＡ）デバイス、ワイヤレス通信機能を有するハンドヘルドデバイス、コンピューティングデバイス、もしくはワイヤレスモデムに接続された別の処理デバイス、ウェアラブルデバイス、車載デバイス、路側ユニット（road side unit、ＲＳＵ）、および次世代通信システム、例えば、第５世代（5-generation、５Ｇ）ネットワーク内の端末デバイス、将来の進化型公衆陸上移動ネットワーク（public land mobile network、ＰＬＭＮ）ネットワーク内の端末デバイス、新無線（new radio、ＮＲ）通信システム内の端末デバイスなどであってもよい。

本出願の実施形態におけるネットワークデバイスは、アクセスネットワークデバイス、基地局などと呼ばれることがある。基地局は、ＷＬＡＮにおけるアクセスポイント（access point、ＡＰ）、汎欧州デジタル移動電話方式（global system for mobile communication、ＧＳＭ（登録商標））もしくは符号分割多元接続（code division multiple access、ＣＤＭＡ）におけるベーストランシーバステーション（base transceiver station、ＢＴＳ）であってもよいし、ＷＣＤＭＡ（登録商標）におけるノードＢ（nodeB、ＮＢ）であってもよいし、ＬＴＥにおける発展型ノードＢ（evolved nodeB、ｅＮＢ、もしくはｅＮｏｄｅＢ）、または中継局もしくはアクセスポイント、ＮＲシステムにおける新世代ノードＢ（new generation nodeB、ｇＮｏｄｅＢ）などであってもよい。任意選択で、ｇＮｏｄｅＢは、中央ユニット（central unit、ＣＵ）と分散ユニット（distributed unit、ＤＵ）とが別個である形態で展開され得る。

ＳＬ通信の典型的な用途は、Ｖ２Ｘ通信である。例えば、Ｖ２Ｘ通信は、車車間通信（vehicle-to-vehicle、Ｖ２Ｖ）、路車間通信（vehicle-to-infrastructure、Ｖ２Ｉ）、車歩行者間通信（vehicle to people、Ｖ２Ｐ）、車対アプリケーションサーバ通信（vehicle-to-network、Ｖ２Ｎ）などを含む。Ｖ２Ｘの具体的な通信シナリオは、本出願の実施形態において限定されない。例えば、Ｖ２Ｘ通信は、車車間通信であってもよいし、車載デバイス間の通信であってもよいし、ＲＳＵと車載デバイスおよび／もしくはネットワークデバイスとの間の通信であってもよいし、ネットワークデバイスと車載デバイスおよび／もしくはＲＳＵとの間の通信であってもよい。ネットワークデバイスは、ＬＴＥ基地局デバイス、ＮＲ基地局デバイス、または後続の進化型システム内の基地局であり得る。

Ｖ２Ｘシナリオでは、端末デバイスは、ユニキャスト、マルチキャスト、またはブロードキャスト通信をサポートする。ユニキャスト通信のためにはユニキャスト接続を確立する必要があり、マルチキャスト通信のためにはマルチキャスト通信グループを確立する必要がある。例えば、車両隊列走行（platooning）サービスでは、移動方向が同じで距離が比較的近い車両が、車両隊列を形成し得、車両隊列内の１台の車両が、車両隊列内の別の車両にデータを送信し得る。さらに、先頭車両は、メンバー車両へのユニキャスト通信接続を確立し、ユニキャスト接続を介してメンバー車両との１対１のデータ送信を実行し得る。

ＳＬ送信を実行する前に、送信側端末デバイスは、送信リソースを取得する必要がある。本出願の実施形態では、ＳＬ通信のために使用される送信リソースは、ＳＬリソースと呼ばれる。従来技術におけるダウンリンクデータリソースとアップリンク送信リソースとを区別するために、ＳＬリソースは、ＳＬグラント（SL grant）とも呼ばれる。それに対応して、受信を実行する前に、受信側端末デバイスはまた、受信リソースを決定する必要がある。現在、送信側端末デバイスは、以下の２つのモード（モード１およびモード２）でＳＬリソースを取得し得る。

モード１：基地局スケジューリング方式。基地局スケジューリング方式は、Ｕｕインターフェース上のアップリンクリソースを取得する方式と同様である。ＳＬデータが送信されるべきであるとき、端末デバイスは、送信されるべきデータの量を基地局に通知するために、まず、サイドリンクバッファステータスレポート（sidelink buffer status report、ＳＬ ＢＳＲ）を基地局に報告する。基地局は、ＳＬ ＢＳＲに基づいて、ＳＬ送信リソースプール（Tx resource pool）から相当サイズのＳＬリソースを端末デバイスに割り当て得る。周期的サービスの場合、端末デバイスは、周期的サービスの属性を基地局に報告し得る。基地局は、周期的サービスの属性に基づいて、周期的ＳＬリソースを端末デバイスに割り当てる。周期的サービスの属性には、開始時刻、周期、パケットサイズなどが含まれる。周期的ＳＬリソースが割り当てられる端末デバイスは、ＳＬリソースを取得するためにＳＬ ＢＳＲを頻繁に送信する必要はない。

モード２：端末デバイス自律競合方式において、例えば、端末デバイスは、ＳＬ送信リソースプール内の各時間－周波数リソースが占有されているかどうかを測定することによって、送信のために、アイドル（すなわち、占有されていない）ＳＬリソースを選択し得、基地局は、ＳＬリソースをスケジューリングする必要はない。

ＳＬ送信リソースプールは、複数のＳＬリソース（例えば、時間－周波数リソース）を含む。端末デバイスのためにＳＬリソースをスケジューリングするとき、基地局は、ＳＬ送信リソースプールからリソースを選択し得る。同様に、自律的にＳＬリソースを選択する場合、端末デバイスも、ＳＬ送信リソースプールからリソースを選択する。ＳＬ送信リソースプールは、基地局によって端末デバイスのために構成され得る。１つまたは複数のＳＬ送信リソースプールが存在し得ることが理解され得る。

同様に、端末デバイスが、ＳＬ通信を実行するために受信側として使用されるとき、端末デバイスはまた、ＳＬ受信リソースプール（Rx resource pool）から対応するＳＬ受信リソースを決定する必要がある。送信リソースプール内のＳＬリソースは、受信リソースプール内のＳＬリソースに対応し、１つまたは複数のＳＬ受信リソースプールが存在し得ることが理解され得る。

既存の通信プロトコルでは、関心のあるサービスについて、受信側端末デバイスは、可能な送信側端末デバイスによって送信されたメッセージを受信するために、リソースプール内のすべてのＳＬリソースに対応する時点においてサイドリンク制御情報（sidelink control information、ＳＣＩ）を監視する必要がある。しかしながら、送信側端末デバイスは、ほとんどの時間においてデータを送信しない可能性があり、したがって、受信側端末デバイスのエネルギー節約につながらない。

従来技術では、受信側端末デバイスは、エネルギーを節約するためにＤＲＸメカニズムを使用し得る。受信側端末デバイスは、ＤＲＸのアクティブ時間においてのみダウンリンク制御情報（downlink control information、ＤＣＩ）を受信し、ＤＲＸのスリープ時間においてＤＣＩを受信せず、受信側端末デバイスの受信機は、ＤＲＸのスリープ時間にはオフ状態にあり、それによって、エネルギー節約の目的を達成する。

ＤＲＸメカニズム（以下、ＳＬ ＤＲＸと呼ばれる）もＳＬ通信に導入される。ＳＬ ＤＲＸをサポートする受信側端末デバイスは、ＳＬ ＤＲＸのアクティブ時間においてのみＳＣＩを受信し、ＳＬ ＤＲＸのスリープ時間には受信機を無効にし、ＳＣＩを受信しない。ＳＬ ＤＲＸは、ユニキャストＳＬ ＤＲＸおよびマルチキャストまたはブロードキャストＳＬ ＤＲＸを含む。ユニキャストＳＬ ＤＲＸを使用する前に、端末デバイスは、まず、ユニキャスト接続（ＰＣ５－Ｓ接続／ユニキャストリンク）を確立し、次いで、確立されたユニキャスト接続を通じて対応するＳＬ ＤＲＸパラメータを構成する必要がある。

ＳＬ ＤＲＸのユニキャスト接続を確立するプロセスについては、図２に示されるプロセスを参照されたい。図２に示すように、ユニキャスト接続を確立するプロセスは、以下のステップを含む。

Ｓ１０１：第１の端末デバイスが、接続確立要求メッセージを第２の端末デバイスに送信する。

接続確立要求メッセージは、ユニキャスト接続を確立することを要求するためのものである。接続確立要求メッセージは、ＰＣ５－Ｓ接続確立要求メッセージとも呼ばれる。接続確立要求メッセージは、直接通信要求メッセージであり得る。

Ｓ１０２：第２の端末デバイスが、セキュリティ確立コマンドメッセージを第１の端末デバイスに送信する。

Ｓ１０３：第１の端末デバイスが、セキュリティ確立完了メッセージを第２の端末デバイスに送信する。

Ｓ１０４：第２の端末デバイスが、接続確立受諾メッセージを第１の端末デバイスに送信する。

セキュリティ確立コマンドメッセージは、ダイレクトセキュリティモードコマンドメッセージであり得る。セキュリティ確立完了メッセージは、ダイレクトセキュリティモード完了メッセージであり得る。接続確立受諾メッセージは、ダイレクト通信受諾メッセージであり得る。接続確立要求メッセージは、ユニキャストまたはブロードキャスト方式で送信され得る。セキュリティ確立コマンドメッセージ、セキュリティ確立完了メッセージ、および接続確立受諾メッセージはすべて、ユニキャスト方式で送信される。

ユニキャスト接続を確立するプロセスでは、対応するセキュリティも確立される。加えて、ユニキャスト接続が確立された後、対応するＰＣ５－ＲＲＣ接続が自動的に存在する。セキュリティは、端末デバイスの上位層（例えば、ＰＣ５－Ｓ層またはＶ２Ｘ層）によって確立され得る。セキュリティを確立した後、上位層は、セキュリティ構成をアクセス（access、ＡＳ）層に通知する。セキュリティ構成は、セキュリティアルゴリズム、セキュリティパラメータ、セキュリティポリシーなどを含む。ＡＳ層は、セキュリティ構成を使用することによって、ＰＣ５－Ｓメッセージ、ＰＣ５－ＲＲＣメッセージ、およびユーザプレーンデータ送信に対してセキュリティ保護を実行し得る。

中継通信のシナリオでは、ユニキャスト接続を確立する前に、端末デバイスは、まず、発見（discovery）メカニズムを使用することによって互いを発見する。端末デバイスは、中継（relay）端末デバイスとリモート（remote）端末デバイスとに分類され得る。中継端末デバイスは、常に基地局のカバレッジ内にあり、基地局と直接通信することができる。リモート端末デバイスは、基地局のカバレッジ内にあってもよいし、基地局のカバレッジ外にあってもよい。データをネットワークに直接送信するために、リモート端末デバイスは、中継端末デバイスを発見して、それに接続する必要がある。

現在、端末デバイス間に２つの発見モードが存在する。発見モードＡでは、中継端末デバイスは、告知メッセージを周囲にブロードキャストして、周囲のリモート端末デバイスに「私はここにいます。そして、あなたは私を見つけることができます。」と通知することができる。発見モードＢでは、リモート端末デバイスは、中継端末デバイスが近くに存在するかどうかを問い合わせるために要請メッセージを送信する。要請メッセージを受信した後、中継端末デバイスは、中継端末デバイスのステータスまたは別の要因に基づいて、応答メッセージを返すべきかどうかを決定する。中継端末デバイスが応答メッセージを返すと、２つの端末デバイスは互いを発見する。

マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするためには、マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソース（またはマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースと呼ばれる）が構成される必要がある。マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソースは、以下の２つの方式で構成され得る。本明細書におけるＳＬリソースは、ＳＬ受信リソースまたはＳＬ送信リソースを含むことが理解され得る。

方式１：いくつかのパターン（サブセットとも呼ばれ得る）が、マルチキャストまたはブロードキャストＳＬ ＤＲＸのために既存のリソースプール（例えば、Ｒ１６リソースプール）からキャプチャされる。図３は、マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソースの概略図である。図３に示すように、灰色の部分は、キャプチャされたパターンを表す。ネットワークデバイスが、パターンリソースの時間－周波数領域位置、周期などを定義または構成し、時間－周波数領域位置、周期などを端末デバイスに通知し得るか、またはプロトコルが、パターンリソースの時間－周波数領域位置、周期などを予め定義する。より多くの不連続パターンリソースがリソースプール内に存在し得、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする端末デバイスは、灰色部分に示されるＳＬリソース上でデータを送信または受信し、マルチキャストまたはブロードキャストサービを正常に送信することができることを保証し得ることが理解され得る。

方式２：専用リソースプール（dedicated resource pool）がマルチキャストまたはブロードキャストＳＬ ＤＲＸのために構成される。図４は、マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用されるＳＬリソースの別の概略図である。灰色部分は専用リソースプールを示す。専用リソースプールは、マルチキャストまたはブロードキャストＳＬ ＤＲＸのために使用される。既存のリソースプールは、専用リソースプールから独立している。マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングが正常に送信され得ることを保証するために、灰色部分に示される専用リソースプール上で、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを送信または受信し得る。

方式１および方式２におけるリソースプールは、送信リソースプールまたは受信リソースプールであり得る。

マルチキャストまたはブロードキャストＳＬ ＤＲＸがサポートされると受信側端末デバイスが決定したとき、受信側端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸのアクティブ時間においてのみＳＣＩをリッスンし、送信側端末デバイスは、任意の時間にデータまたはシグナリングを送信し得る。送信側端末デバイスによって送信されたデータまたはシグナリングが、マルチキャストまたはブロードキャストＳＬ ＤＲＸのアクティブ時間に対応する時間－周波数位置にない場合、受信側端末デバイスは、送信側端末デバイスによって送信されたデータまたはシグナリングを受信することができず、データまたはシグナリングの欠落をもたらす。送信側端末デバイスによって送信されたデータまたはシグナリングが、ブロードキャストまたはマルチキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングである場合、ブロードキャストまたはマルチキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングの欠落は、端末デバイスの通信品質に影響を及ぼす。

本出願の実施形態では、ブロードキャストまたはマルチキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングは、欠落（miss）することができないデータもしくはシグナリング、または破棄することができないデータもしくはシグナリングとも呼ばれるか、または重要なデータもしくはシグナリングと呼ばれるか、またはブロードキャストまたはマルチキャストＳＬ ＤＲＸに対応するＳＬリソース上で受信もしくは送信される必要があるデータもしくはシグナリングと呼ばれるか、または特定のバージョン（例えば、Ｒ１７）のデータもしくはシグナリングと呼ばれる。データおよびシグナリングは、情報（information）とも総称されることがある。したがって、ブロードキャストまたはマルチキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングは、ブロードキャストまたはマルチキャストＳＬ ＤＲＸをサポートする情報とも呼ばれる。

マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするサービスまたはマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするＱｏＳフロー（QoS flow）を含む。ＱｏＳフローは、サービスの粒度よりも小さいまたは細かい粒度を有するデータである（すなわち、１つのサービスが、１つまたは複数のＱｏＳフローを含み得る）。

本出願の実施形態では、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするシグナリングは、ユニキャスト接続を確立するプロセスにおける４つのメッセージ（図２に示される４つのメッセージを参照）、発見プロセスにおけるメッセージ、端末デバイスのＳＬ能力関連メッセージ、および第１のＰＣ５ ＲＲＣ再構成メッセージのうちの１つまたは複数のシグナリングを含む。ユニキャスト接続を確立するプロセスにおける４つのメッセージは、図２に示される、接続確立要求メッセージ、セキュリティ確立コマンドメッセージ、セキュリティ確立完了メッセージ、および接続確立受諾メッセージである。発見プロセスにおけるメッセージは、告知メッセージ、要請メッセージ、および要請メッセージの応答メッセージを含む。端末デバイスのＳＬ能力関連メッセージは、UECapabilityEnquirySidelinkメッセージおよびUECapabilityInformationSidelinkメッセージを含む。

従来技術における問題を解決するために、本出願の実施形態では、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバは、端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸのデータまたはシグナリングをサポートすることを示すか、端末デバイスに、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを示し得る。送信側端末デバイスが、送信されるべきデータを有するとき、送信側端末デバイスは、送信されるべきデータまたはシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングであるかどうかを決定する。送信されるべきデータまたはシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングである場合、送信側端末デバイスは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを使用することによって、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを送信する。受信側端末デバイスは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソース上で、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングを受信する。なぜなら、送信側端末デバイスによって使用される送信リソースは、受信側端末デバイスによって使用される受信リソースに対応するからである。すなわち、送信リソースおよび受信リソースの両方がマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースである場合、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングが、ＳＬ通信の品質に影響を及ぼすことなく、受信側端末デバイスによって正常に受信されることができることを保証することができる。

マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータまたはシグナリングは、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバによって示されてもよいし、端末デバイスにおいて予め構成されてもよい。これは、この実施形態に限定されない。マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするデータは、マルチキャストまたはブロードキャストＳＬ ＤＲＸサービスまたはＱｏＳフローを含む。コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするサービスタイプ、ＱｏＳフローに関する情報、宛先などを示し得る。ＱｏＳフローに関する情報は、ＱｏＳフローの識別子（PC5 QoS flow identifier、ＰＦＩ）であり得る。

この実施形態では、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバは、第１の指示情報を端末デバイスに送信し得る。第１の指示情報は、データまたはシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを示す。端末デバイスの上位層は、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバから第１の指示情報を受信し、第１の指示情報をＡＳ層に送信する。端末デバイスの上位層は、アプリケーション層とＡＳ層との間の層と理解され得る。上位層は、ＰＣ５－Ｓ層またはＶ２Ｘ層を含む。端末デバイスのＡＳ層は、物理層（physical）、媒体アクセス制御（media access control、ＭＡＣ）層、無線リンク制御（radio link control、ＲＬＣ）層、パケットデータコンバージェンスプロトコル（packet data convergence protocol、ＰＤＣＰ）層、サービスデータ適応プロトコル（service data adaptation protocol、ＳＤＡＰ）層、および無線リソース制御（radio resource control、ＲＲＣ）層のうちの１つまたは複数の層を含む。

データがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかをコアネットワークデバイスまたはＶ２Ｘアプリケーションサーバが端末デバイスに示すとき、またはデータがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを端末デバイスの上位層がＡＳ層に示すとき、各サービスタイプ／宛先／ＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかが示されてもよいし、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするサービスタイプ／宛先／ＱｏＳフローのみが示されてもよい。ＱｏＳフローは、サービスの粒度よりも細かいまたは小さい粒度を有するデータである。サービスがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかが示されるとき、ＱｏＳフローは、サービスタイプまたは宛先に対応するデータがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを示し得る。宛先は、サービスタイプを変換することによって取得され得ることが理解され得る。

１つの宛先またはサービスは、複数のＱｏＳフローに対応するかまたは関連付けられ得る。１つの宛先に対応する複数のＱｏＳフローのうちの一部のＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートし得、他のＱｏＳフローは、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートしないであろう。したがって、ＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかをコアネットワークデバイスまたはＶ２Ｘアプリケーションサーバが端末デバイスに示すとき、またはＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを端末デバイスの上位層がＡＳ層に示すとき、宛先に関連付けられた各ＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかが示されてもよいし、宛先に関連付けられたどのＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかが示されてもよい。

シグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかをコアネットワークデバイスまたはＶ２Ｘアプリケーションサーバが端末デバイスに示すとき、またはシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを端末デバイスの上位層がＡＳ層に示すとき、各タイプのシグナリング／各宛先に対応するシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかが示され得るか、または特定の名前のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかが示され得る。

マルチキャストまたはブロードキャストＳＬ ＤＲＸがサポートされるかどうかを端末デバイスの上位層がＡＳ層に示すとき、示された粒度は、端末デバイスの粒度と理解される。

図５は、本出願の実施形態１によるサイドリンク通信方法のフローチャートである。図５に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ２０１：第１の端末デバイスが、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定し、ここで、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである。

第１の端末デバイスは送信側であり、第１のデータまたは第１のシグナリングは、現在送信されるべきデータまたはシグナリングである。第１のデータまたは第１のシグナリングが送信されるべきであるとき、第１の端末デバイスは、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートするかどうかを決定する。

例えば、第１の端末デバイスは、第１の指示情報に基づいて、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定し、第１の指示情報は、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示す。第１の指示情報は、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバによって第１の端末デバイスの上位層に送信され得る。第１の端末デバイスの上位層は、第１の指示情報をＡＳ層に送信する。第１の端末デバイスのＡＳ層は、第１の指示情報に基づいて、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートするかどうかを決定する。

任意選択で、第１の指示情報は、第１のデータに関連付けられたサービスまたはＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを含む。第１の指示情報が、第１のデータに関連付けられたサービスがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示すとき、第１のデータに関連付けられたサービスタイプまたは宛先は、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするように示され得る。

一実装形態では、第１のシグナリングが第１のＤＲＸをサポートするかどうかを決定するとき、第１の端末デバイスは、第１の指示情報を使用しなくてもよく、第１の端末デバイスは、第１の端末デバイスのポリシーにしたがって、第１のＤＲＸをサポートするシグナリングを決定する。別の実装形態では、第１の端末デバイスは、第１の指示情報を参照して、第１のシグナリングが第１のＤＲＸをサポートするかどうかを決定し得る。例えば、第１の端末デバイスは、第１の端末デバイスのポリシーにしたがって、第１のシグナリングが第１のＤＲＸをサポートする代替シグナリングであると決定し、シグナリングの宛先が第１の指示情報において示される宛先であるかどうかをさらに決定する。シグナリングの宛先が第１の指示情報に示される宛先である場合、第１の端末デバイスは、第１のシグナリングが第１のＤＲＸをサポートすると決定する。

任意選択で、第１の端末デバイスは、第１の端末デバイスのポリシーにしたがって、第１のＤＲＸをサポートするシグナリングを決定するか、またはプロトコルにおいて予め定義されたルールにしたがって、第１のＤＲＸをサポートするシグナリングを決定する。

任意選択で、第１の端末デバイスは、端末デバイスの粒度に基づいて、第１の端末デバイスが第１のＤＲＸをサポートすると決定し得る。第１の端末デバイスの上位層は、第１の端末デバイスのＡＳ層が第１のＤＲＸをサポートすることを示し、示される粒度は、端末デバイスの粒度であることが理解され得る。

Ｓ２０２：第１の端末デバイスが、第１のＳＬリソースを取得し、ここで、第１のＳＬリソースは、第１のＤＲＸに対応するＳＬリソースである。

第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると第１の端末デバイスが決定した後、第１の端末デバイスは、第１のデータまたは第１のシグナリングを送信するために使用されるマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソース、すなわち、第１のＳＬリソースを取得する。

第１の端末デバイスは、モデル方式（すなわち、基地局によるスケジューリングの方式）で第１のＳＬリソースを取得し得る。具体的には、第１の端末デバイスは、第１の要求メッセージをネットワークデバイスに送信し、第１の要求メッセージは、第１のＳＬリソースを要求するためのものである。第１の端末デバイスは、ネットワークデバイスによって送信された第１のＳＬリソースに関する情報を受信する。ネットワークデバイスは基地局であり得る。基地局は、第１の要求メッセージのフォーマットおよびタイプまたは第１の要求メッセージ内のコンテンツに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

代替的に、第１の端末デバイスは、モード２方式（すなわち、端末デバイスがリソースを自律的に選択する方式）で第１のＳＬリソースを取得してもよい。具体的には、第１の端末デバイスは、アイドルＳＬリソースを測定することによって第１のＳＬリソースを取得する。例えば、第１の端末デバイスは、センシング方式で、ＳＬリソースがアイドルであるかどうかを測定し、リソース除外を通して最終的に利用可能な第１のＳＬリソースを決定し得る。

基地局によるスケジューリングの方式で第１のＳＬリソースを取得するとき、第１の端末デバイスは、第１の要求メッセージを使用することによって、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースであることを知る必要がある。

第１の実装形態では、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであることを示す。第１の要求メッセージを受信した後、基地局は、第１の要求メッセージに含まれる第２の指示情報に基づいて、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを第１の端末デバイスに割り当てる。

本出願の実施形態では、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースは、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって使用される、または必要とされる、または使用されるべきＳＬリソースと理解され得る。

第２の実装形態では、第１の要求メッセージを基地局に送信する前に、第１の端末デバイスは、まず、第２の指示情報を基地局に送信し、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。基地局は、第１の要求メッセージおよび第２の指示情報に基づいて、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを第１の端末デバイスに割り当てる。

第３の実装形態では、第１の端末デバイスは、専用ＬＣＧまたは専用宛先インデックスを使用することによって、第１の要求メッセージを基地局に送信し、基地局は、第１の要求メッセージを送信するために使用される専用ＬＣＧまたは専用宛先インデックスに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。代替的に、第１の端末デバイスは、特定のフォーマットの第１の要求メッセージを基地局に送信する。基地局は、第１の要求メッセージのフォーマットに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。代替的に、第１の要求メッセージが専用ＳＲである場合、基地局は、専用ＳＲに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

本出願の実施形態では、第２の指示情報は、宛先またはＱｏＳフローに関連付けられることに留意されたい。第２の指示情報が宛先に関連付けられるとき、第２の指示情報は、宛先に対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。第２の指示情報がＱｏＳフローに関連付けられるとき、第２の指示情報は、ＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第２の指示情報は、代替的に、第１の端末デバイスに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであることを示し得る。言い換えれば、第２の指示情報は、端末デバイスの粒度を有する。

任意選択で、第１の要求メッセージは、ＳＬスケジューリング要求（scheduling request、ＳＲ）、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージである。それに対応して、第２の実装形態では、第２の指示情報は、ＳＵＩメッセージで搬送され得る。

（１）第１の要求メッセージはＳＬ ＳＲである。

例示的な方式では、第１の端末デバイスは、専用ＳＬ ＳＲを基地局に送信する。専用ＳＬ ＳＲを受信した後、基地局は、専用ＳＬ ＳＲに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであると決定する。専用ＳＬ ＳＲは、専用送信リソース上で送信されるＳＲと理解され得る。

専用ＳＬ ＳＲは、第１の端末デバイスのために基地局または別のネットワークデバイスによって予め構成されてもよいし、プロトコルにおいて予め定義されてもよい。第１の端末デバイスについて、ＳＬ ＳＲは、共通ＳＬ ＳＲおよび専用ＳＬ ＳＲという２つのタイプに分類され得る。専用ＳＬ ＳＲは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。共通ＳＬ ＳＲは、非制限ＳＬリソースまたはマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソース以外の別のＳＬリソースを要求するためのものである。基地局は、ＳＬ ＳＲのタイプに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであるかどうかを決定し得る。

例えば、専用ＳＬ ＳＲに対応するＳＲ ＩＤは、プロトコルにおいて予め定義される。第１の端末デバイスがＳＲ ＩＤに対応するリソース上でＳＬ ＳＲをネットワークデバイスに送信するとき、ネットワークデバイスは、リソースまたはＳＲ ＩＤに基づいて、第１の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するサイドリンク送信リソースを要求し、第１の端末デバイスのための対応するサイドリンク送信リソースを構成することを知り得る。

別の実装形態では、専用ＳＬ ＳＲを基地局に送信する前に、第１の端末デバイスは、まず、専用ＳＬ ＳＲを構成するように基地局に要求する。ＳＬ ＳＲを構成するように基地局に要求する前に、第１の端末デバイスは、第２の指示情報を基地局に送信する。基地局は、第２の指示情報に基づいて、第１の端末デバイスのために専用ＳＬ ＳＲを構成する。基地局が専用ＳＬ ＳＲを構成することは、専用送信リソースがＳＬ ＳＲのために構成されることと理解され得る。

例えば、第１の端末デバイスは、ＳＵＩメッセージを基地局に送信し、ＳＵＩメッセージは、宛先および宛先に対応するＱｏＳフローを含む。従来技術とは異なり、この実施形態では、ＳＵＩメッセージは、第２の指示情報をさらに含む。ＳＵＩメッセージを受信した後、基地局は、ＳＵＩメッセージに含まれる第２の指示情報に基づいて、専用ＳＬ ＳＲを第１の端末デバイスに割り当てる。言い換えれば、基地局は、第２の指示情報に対応する宛先またはＱｏＳフローに関連付けられたＬＣＨ（論理チャネル）のための専用ＳＬ ＳＲを構成し得る。ネットワークは、専用ＳＬ ＳＲに対応するＳＲ ＩＤを構成し、第１の端末デバイスがＳＲ ＩＤに対応するリソース上でＳＬ ＳＲをネットワークデバイスに送信するとき、ネットワークデバイスは、リソースまたはＳＲ ＩＤに基づいて、第１の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するサイドリンク送信リソースを要求し、第１の端末デバイスのための対応するサイドリンク送信リソースを構成し得ることを知ることが理解され得る。

さらに別の例示的な方式では、ＳＬ ＳＲは第２の指示情報を含み、基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。このように、専用ＳＬ ＳＲが定義される必要はなく、すべての通常のＳＬ ＳＲまたは共通ＳＬ ＳＲが第２の指示情報を含み得る。

（２）第１の要求メッセージはＳＬ ＢＳＲである。

例示的な方式では、第１の端末デバイスは、専用論理チャネルグループ（logical channel group、ＬＣＧ）を使用することによってＳＬ ＢＳＲを基地局に送信し得る。ＳＬ ＢＳＲを受信した後、基地局は、ＳＬ ＢＳＲを送信するＬＣＧに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

ＳＬ ＢＳＲを送信するための専用ＬＣＧ（例えば、専用論理チャネルグループ識別子）は、第１の端末デバイスのために基地局または別のネットワークデバイスによって予め構成されてもよいし、プロトコルにおいて予め定義されてもよい。第１の端末デバイスについて、ＳＬ ＢＳＲを送信するためのＬＣＧは、共通ＬＣＧおよび専用ＬＣＧという２つのタイプに分類される。専用ＬＣＧは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。共通ＬＣＧは、非制限ＳＬリソースまたはマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソース以外の別のＳＬリソースを要求するためのものである。基地局は、ＳＬ ＢＳＲを送信するためのＬＣＧのタイプに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであるかどうかを決定し得る。

別の実装形態では、専用ＬＣＧを使用することによってＳＬ ＢＳＲを基地局に送信する前に、第１の端末デバイスは、まず、専用ＬＣＧを構成するように基地局に要求する。専用ＬＣＧを構成するように基地局に要求する前に、第１の端末デバイスは、第２の指示情報を基地局に送信し、基地局は、第２の指示情報に基づいて、第１の端末デバイスのために専用ＬＣＧを構成する。

例えば、第１の端末デバイスは、ＳＵＩメッセージを基地局に送信する。ＳＵＩメッセージは、宛先と、宛先に対応するＱｏＳフローとを含み、ＳＵＩメッセージは、第２の指示情報をさらに含む。ＳＵＩメッセージを受信した後、基地局は、ＳＵＩメッセージに含まれる第２の指示情報に基づいて、ＳＬ ＢＳＲを送信するための専用ＬＣＧを第１の端末デバイスに割り当てる。言い換えれば、基地局は、第２の指示情報に対応する宛先またはＱｏＳフローが専用ＬＣＧ上で送信されるように構成し得る。

さらに別の例示的な方式では、第１の端末デバイスは、専用宛先インデックス（destination index）を使用することによって、ＳＬ ＢＳＲを基地局に送信し得る。ＳＬ ＢＳＲを受信した後、基地局は、ＳＬ ＢＳＲを送信するための宛先インデックスに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。専用宛先インデックスは、専用宛先を一意に識別することができる。

ＳＬ ＢＳＲを送信するための専用宛先インデックスは、第１の端末デバイスのために基地局または別のネットワークデバイスによって予め構成されてもよいし、プロトコルにおいて予め定義されてもよい。第１の端末デバイスについて、ＳＬ ＢＳＲを送信するための宛先インデックスは、共通宛先インデックスおよび専用宛先インデックスのという２つのタイプに分類される。専用宛先インデックスは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものであり、共通宛先インデックスは、非制限ＳＬリソースまたはマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソース以外の別のＳＬリソースを要求するためのものである。基地局は、ＳＬ ＢＳＲを送信するための宛先インデックスのタイプに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであるかどうかを決定し得る。

さらに別の例示的な方式では、ＳＬ ＢＳＲは第２の指示情報を含み、基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。このように、専用ＬＣＧまたは専用宛先インデックスは、ＳＬ ＢＳＲのために構成される必要はない。

さらに別の例示的な方式では、第１の端末デバイスは、共通ＬＣＧまたは共通宛先インデックスを使用することによってＳＬ ＢＳＲを基地局に送信し、ＳＬ ＢＳＲを基地局に送信する前に、第２の指示情報をＳＬ ＢＳＲに含める。例えば、宛先インデックスに対応するＬＣＧまたはＳＬ ＢＳＲに含まれる宛先インデックスが、第２の指示情報に関連付けられ得る。ＳＬ ＢＳＲを受信した後、基地局は、第２の指示情報および宛先インデックスに対応するＬＣＧまたはＳＬ ＢＳＲに含まれる宛先インデックスに基づいて、第１の端末デバイスによって要求されたＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

具体的には、第１の端末デバイスは、宛先に関連付けられた第１の指示情報に基づいて、ＳＬ ＢＳＲにおける宛先インデックスが第２の指示情報に関連付けられていると決定するか、または、第１の端末デバイスは、ＱｏＳフローに関連付けられた第１の指示情報に基づいて、ＳＬ ＢＳＲにおいてＱｏＳフローがマッピングされるＬＣＧが第２の指示情報に関連付けられていると決定する。

さらに別の例示的な方式では、第１の端末デバイスは、特定のフォーマット（format）のＳＬ ＢＳＲを基地局に送信し、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。

ＳＬ ＢＳＲのフォーマットは、第１の端末デバイスのために基地局または別のネットワークデバイスによって予め構成されるか、またはプロトコルにおいて予め定義され得る。第１の端末デバイスについて、ＳＬ ＢＳＲのフォーマットは、共通のフォーマットおよび特定のフォーマットという２つのタイプに分類される。特定のフォーマットのＳＬ ＢＳＲは、新たに定義されたフォーマットまたは新たな媒体アクセス制御の制御要素（media access control control element、ＭＡＣ ＣＥ）要素であり、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。共通のフォーマットのＳＬ ＢＳＲは、非制限ＳＬリソースまたはマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソース以外の別のＳＬリソースを要求するために使用される様々な既存のフォーマットを含む。基地局は、ＳＬ ＢＳＲのフォーマットに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであるかどうかを決定し得る。

（３）第１の要求メッセージはＵＡＩメッセージである。

例示的な方式では、第１の端末デバイスは、ＵＡＩメッセージを基地局に送信し、ＵＡＩメッセージは、ＱｏＳフロー情報およびサービスモードを含む。従来技術とは異なり、ＵＡＩメッセージは、第２の指示情報をさらに含む。ＵＡＩメッセージを受信した後、基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

例えば、ＵＡＩメッセージ内のＱｏＳフロー情報またはサービスモードが、第２の指示情報に関連付けられる。

別の実装形態では、ＵＡＩメッセージを基地局に送信する前に、第１の端末デバイスは、まず、第２の指示情報を基地局に送信し、すなわち、ＵＡＩメッセージは第２の指示情報を含まない。例えば、第１の端末デバイスは、宛先またはＱｏＳフローに関連付けられた第２の指示情報を、送信されるＳＵＩメッセージに含める。さらに、ＳＵＩメッセージおよびＵＡＩメッセージに基づいて、ＳＵＩメッセージ内の第２の指示情報に関連付けられたＱｏＳフローまたは宛先がＵＡＩメッセージのＱｏＳフローまたはサービスモードに対応すると決定したとき、基地局は、第１の端末デバイスによって要求されたＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

ＵＡＩメッセージに基づいて基地局によって第１の端末デバイスに割り当てられ得る第１のＳＬリソースは、半永続的スケジューリング(semi-persistent scheduling、ＳＰＳ）リソースであり、ＳＰＳリソースは、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースである。

Ｓ２０３：第１の端末デバイスが、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信する。

それに対応して、第２の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で第１のデータまたは第１のシグナリングを受信し、第２の端末デバイスは、受信側端末デバイスである。第１の端末デバイスは、マルチキャストまたはブロードキャスト方式で第１のデータまたは第１のシグナリングを送信する。任意選択で、第１の端末デバイスは、ユニキャスト方式で第１のシグナリングを送信し得る。

受信側として、第２の端末デバイスはまた、コアネットワークデバイスまたはＶ２Ｘアプリケーションサーバから第１の指示情報を受信する。第１の指示情報は、まず、第２の端末デバイスの上位層に送信される。第２の端末デバイスのＡＳ層は、上位層から第１の指示情報を受信する。第２の端末デバイスは、第１の指示情報に基づいて、現在受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートするかどうかを決定する。第２の端末デバイスが、現在受信されるべきデータおよび／またはシグナリングが第１のＤＲＸをサポートすると決定した場合、第２の端末デバイスは、第１のＤＲＸをアクティブ化する。第１のＤＲＸをアクティブ化した後、第２の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で第１の端末デバイスによって送信されたデータまたはシグナリングを第２の端末デバイスが受信することができるように、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上でデータまたはシグナリングを受信し得る。

第２の端末デバイスによって受信されるべきデータは、第２の端末デバイスが関心を持っているデータ、または第２の端末デバイスの上位層によって示されるようにＡＳ層が受信する必要があるデータと理解され得る。

任意選択で、現在受信されるべきデータおよび／またはシグナリングが第１のＤＲＸをサポートするとき、第１のＤＲＸをアクティブ化するステップは、複数の受信されるべきデータおよび／またはシグナリングが存在し、複数のデータおよび／またはシグナリングのすべてが第１のＤＲＸをサポートするとき、第１のＤＲＸをアクティブ化する、または、複数のデータおよび／またはシグナリングのうちの一部のデータもしくは一部のシグナリングが第１のＤＲＸをサポートするとき、第１のＤＲＸをアクティブ化するという２つのケースを含む。

複数のデータおよび／またはシグナリングのうちの一部のデータまたはシグナリングが第１のＤＲＸをサポートするとき、第１のＤＲＸがアクティブ化された後、複数のデータおよび／またはシグナリングのうちの第１のＤＲＸをサポートしないデータまたはシグナリングは、受信側端末デバイスによって受信されないであろう。しかしながら、複数のデータおよび／またはシグナリングのうちのデータまたはシグナリングが第１のＤＲＸをサポートするとき、第１のＤＲＸがアクティブ化された後、複数のデータおよび／またはシグナリングは、受信側端末デバイスによって受信されることができる。

受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートするかどうかを決定するステップは、具体的には、受信されるべきデータまたはシグナリングの宛先またはＱｏＳフローを、第１の指示情報によって示される宛先またはＱｏＳフローと比較するステップと、受信されるべきデータまたはシグナリングの宛先またはＱｏＳフローが、第１の指示情報によって示される宛先またはＱｏＳフローに属する場合、受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートすると決定するステップとである。

第２の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース（すなわち、第１の端末デバイスのために構成されたマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応する送信リソースプール）上にあり、第１の端末デバイスが具体的にデータを送信するリソースを知らないが、第１のＤＲＸをアクティブ化した後、第２の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース（すなわち、第２の端末デバイスのために構成されたマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応する受信リソースプール）のすべてのリソース上でデータを受信することが理解され得る。このように、第１のデータまたは第１のシグナリングを正常に受信することができる。

任意選択で、第２の端末デバイスが第１のＤＲＸをアクティブ化しないとき、第２の端末デバイスは、受信リソースプールに対応するフルセット時間－周波数リソース位置においてデータを受信する。マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースが通常（normal）受信リソースプールのサブセットである場合、第２の端末デバイスはまた、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上でデータを受信する。

任意選択で、第２の端末デバイスの上位層は、第１の指示情報をＡＳ層に送信する。第１の指示情報は、第２の端末デバイスが第１のＤＲＸをサポートするかどうかを示し得る。言い換えれば、第１の指示情報の粒度は、端末デバイスの粒度である。第２の端末デバイスが、第１の指示情報に基づいて、第１のＤＲＸが現在サポートされていると決定した場合、第２の端末デバイスは、第１のＤＲＸをアクティブ化する。

この実施形態では、第１の端末デバイスが、送信されるべき第１のデータまたは第１のシグナリングを有するとき、第１の端末デバイスは、まず、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするかどうかを決定する。第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートするとき、第１の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを取得し、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを使用することによって第１のデータまたは第１のシグナリングを送信する。第１のデータまたは第１のシグナリングを送信するために送信側端末デバイスによって使用されるＳＬリソースは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであり、受信側端末デバイスもまた、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で第１のデータまたは第１のシグナリングを受信する。したがって、受信側端末デバイスが、マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする第１のデータまたは第１のシグナリングを正常に受信することができることが保証され、それによって、ＳＬ通信品質を向上させることができる。

図６は、本出願の実施形態２によるサイドリンク通信方法のフローチャートである。実施形態１に基づいて、この実施形態は、ステップＳ２０３を詳細に説明する。図６に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ３０１：第１の端末デバイスが、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定し、ここで、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである。

Ｓ３０２：第１の端末デバイスが、第１のＳＬリソースを取得し、ここで、第１のＳＬリソースは、第１のＤＲＸに対応するＳＬリソースである。

ステップＳ３０１およびＳ３０２の具体的な実装形態ついては、実施形態１におけるステップＳ２０１およびＳ２０２の説明を参照されたく、詳細は本明細書で改めて説明しない。

Ｓ３０３：第１の端末デバイスが、送信されるべき宛先／論理チャネル（logical channel、ＬＣＨ）から、第１のデータまたは第１のシグナリングに対応する宛先／論理チャネルのみを、第１のＳＬリソース上での送信のために選択するか、または優先的に選択する。

複数の論理チャネルが送信されるべきデータを有し、送信されるべきデータの総量が現在の送信時間間隔（transmission time interval、ＴＴＩ）の送信能力を超えるとき、データを優先的に送信するための論理チャネルを決定する問題が考慮される必要があり、これは、論理チャネル優先順位付け（logical channel prioritization、ＬＣＰ）と呼ばれる。ＴＴＩは、無線リソーススケジューリングの最小単位である。ネットワークの進化または変化に伴い、無線リソーススケジューリングの最小単位が変化し得ることは理解され得る。

サイドリンク送信の間、送信リソースを端末デバイスに割り当てるとき、基地局は、どのリソースがどの宛先または論理チャネルによって使用されるべきかを指定しない。送信リソースを取得した後、端末デバイスは、各論理チャネルのステータスに基づいて、論理チャネルの優先度を決定し得る。一般に、制御論理チャネルの優先度は、データ論理チャネルの優先度よりも高く、データ論理チャネルの優先度は、データ論理チャネル上で送信されるデータのＱｏＳパラメータに基づいて決定され得る。

ＳＬ ＬＣＰの間、第１の端末デバイスは、２つの選択を実行する必要がある。まず、第１の端末デバイスは、送信のための宛先を選択する。宛先は、複数のＱｏＳフローに対応する。異なるＱｏＳフローは、異なる論理チャネルにマッピングされる。論理チャネルの優先度は、論理チャネル上で搬送されるＱｏＳフローの優先度に基づいて決定される。

Ｓ３０４は、第１の端末デバイスが第１のＳＬリソースを取得したときにのみ実行されることが理解され得る。送信のための宛先を選択するとき、第１の端末デバイスは、送信されるべき宛先から、第１のデータまたは第１のシグナリングに対応する宛先のみを、送信のための宛先として選択するか、または優先的に選択し、選択された宛先を送信のための論理チャネルにマッピングする。

送信されるべき宛先は、第１のデータまたは第１のシグナリングに対応する宛先と別の宛先とを含み得る。第１のデータまたは第１のシグナリングに対応する宛先のみが、送信されるべき宛先から選択されることは、第１のＳＬリソースについて、第１のデータまたは第１のシグナリングに対応する宛先のみが現在の送信における送信のために選択され、他の宛先は送信のために選択されないことと理解され得る。

代替的に、第１のデータまたは第１のシグナリングに対応する宛先が、送信されるべき宛先から優先的に選択されることは、送信のための宛先が、送信されるべき宛先の優先度に基づいて選択されることと理解され得る。第１のデータまたは第１のシグナリングに対応する宛先の優先度は最も高く設定され、第１の端末デバイスは、優先度が最も高い宛先を、送信のために優先的に選択する。したがって、第１の端末デバイスは、第１のデータまたは第１のシグナリングに対応する宛先を優先的に選択することができる。第１のデータまたは第１のシグナリングに対応する宛先が存在しないとき、別の宛先が送信のために選択され得ることが理解され得る。

第１の端末デバイスが論理チャネルを送信のために選択するとき、第１の端末デバイスは、送信されるべき論理チャネルから、第１のデータまたは第１のシグナリングに対応する論理チャネルのみを、送信のための論理チャネルとして選択するか、または優先的に選択する。

送信されるべき宛先論理チャネルが第１のデータまたは第１のシグナリングに対応する論理チャネルおよび別の論理チャネルを含み得るとき、第１のデータまたは第１のシグナリングに対応する論理チャネルのみが、伝送されるべき論理チャネルから選択されることは、第１のＳＬリソースについて、第１のデータまたは第１のシグナリングに対応する論理チャネルのみが、現在の送信における送信のために選択され、他の論理チャネルは送信のために選択されないことと理解され得る。

代替的に、送信されるべき論理チャネルから、第１のデータまたは第１のシグナリングに対応する論理チャネルを優先的に選択することは、送信されるべき論理チャネルの優先度に基づいて、論理チャネルを送信のために選択することと理解され得る。この実施形態では、第１のデータまたは第１のシグナリングに対応する論理チャネルの優先度は最も高く設定される。従来技術では、論理チャネルの優先度は、通常、論理チャネル上で搬送されるＱｏＳフローの論理チャネルに基づいて決定され、第１の端末デバイスは、送信のために優先度が最も高い論理チャネルを優先的に選択する。したがって、第１の端末デバイスは、第１のデータまたは第１のシグナリングに対応する論理チャネルを優先的に選択することができる。送信されるべき論理チャネル内の別の論理チャネルが送信されるとき、論理チャネルの優先度は、論理チャネル上で搬送されるＱｏＳフローの論理チャネルに基づいて決定され得る。第１のデータまたは第１のシグナリングに対応する論理チャネルが存在しないとき、別の論理チャネルが送信のために選択され得ることが理解され得る。

本出願の別の実施形態では、第１の端末デバイスは、代替的に、既存の解決策を使用することによって、送信のために第１のデータまたは第１のシグナリングに対応する宛先／論理チャネルを選択し得ることが理解され得る。

この実施形態では、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信するとき、第１の端末デバイスは、送信されるべき宛先／論理チャネルから、第１のデータまたは第１のシグナリングに対応する宛先／論理チャネルのみを、送信のために選択するか、または優先的に選択し、その結果、第１のデータまたは第１のシグナリングが優先的に送信されることが保証され、それによって、ＬＣＰによる第１のデータもしくは第１のシグナリングの送信遅延または破棄を回避することができる。マルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートする第１のデータまたは第１のシグナリングは、通常、重要なデータまたはシグナリングであるので、第１のデータまたは第１のシグナリングは優先的に送信され、それによって、ＳＬ通信の品質がさらに向上する。

図７は、本出願の実施形態３によるサイドリンク通信方法のシグナリングフローチャートである。実施形態１および実施形態２に基づいて、この実施形態では、基地局によるスケジューリングが、サイドリンク通信方法を説明するための例として使用される。この実施形態では、ネットワークデバイスが基地局である例が説明のために使用される。図７に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ４０１：第１の端末デバイスが、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定し、ここで、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである。

このステップの具体的な実装形態については、実施形態１におけるステップＳ２０１の説明を参照されたく、詳細は本明細書で改めて説明しない。

Ｓ４０２：第１の端末デバイスが、第１の要求メッセージを基地局に送信し、ここで、第１の要求メッセージは第２の指示情報を含む。

第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。任意選択で、第１の要求メッセージは、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージである。それに対応して、第２の指示情報は、ＳＵＩメッセージで搬送され得る。

Ｓ４０３：基地局が、第１の要求メッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

第１の要求メッセージがＳＬ ＳＲであるとき、例示的な方式では、第１の端末デバイスは、専用ＳＬ ＳＲを基地局に送信する。専用ＳＬ ＳＲを受信した後、基地局は、専用ＳＬ ＳＲに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。専用ＳＬ ＳＲは、第１の端末デバイスのために基地局または別のネットワークデバイスによって予め構成されてもよいし、プロトコルにおいて定義されてもよい。このように、専用ＳＬ ＳＲは、第２の指示情報を含まなくてもよく、基地局は、専用ＳＬ ＳＲに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し得る。任意選択で、専用ＳＬ ＳＲは、代替的に、第２の指示情報を含んでいてもよい。基地局は、専用ＳＬ ＳＲおよび第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

例えば、専用ＳＬ ＳＲに対応するＳＲ ＩＤは、プロトコルにおいて予め定義される。第１の端末デバイスがＳＲ ＩＤに対応するリソース上でＳＬ ＳＲをネットワークデバイスに送信するとき、ネットワークデバイスは、リソースに基づいて、第１の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するサイドリンク送信リソースを要求し、第１の端末デバイスのための対応するサイドリンク送信リソースを構成することを知ることができる。

別の実装形態では、専用ＳＬ ＳＲを受信する前に、基地局は、第１の端末デバイスの要求に基づいて、第１の端末デバイスのために専用ＳＬ ＳＲを構成する。専用ＳＬ ＳＲを構成することを要求するとき、第１の端末デバイスは、第２の指示情報を搬送する要求メッセージを基地局に送信する。基地局は、第２の指示情報に基づいて第１の端末デバイスのために専用ＳＬ ＳＲを構成する。

第１の要求メッセージがＳＬ ＳＲであるとき、別の例示的な方式では、第１の端末デバイスは、ＳＬ ＳＲ（共通ＳＬ ＳＲと呼ばれることもある）を基地局に送信し、ＳＬ ＳＲは第２の指示情報を含む。基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

第１の要求メッセージがＳＬ ＢＳＲであるとき、例示的な方式では、第１の端末デバイスは、専用ＬＣＧまたは専用宛先インデックスを使用することによって、ＳＬ ＢＳＲを基地局に送信し得る。ＳＬ ＢＳＲを受信した後、基地局は、ＳＬ ＢＳＲの専用ＬＣＧまたは専用宛先インデックスに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。専用ＬＣＧまたは専用宛先インデックスは、第１の端末デバイスのために基地局もしくは別のネットワークデバイスによって予め構成されてもよいし、プロトコルにおいて定義されてもよい。このように、ＳＬ ＢＳＲは、第２の指示情報を含まなくてもよく、基地局は、専用ＬＣＧまたは専用宛先インデックスに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し得る。任意選択で、ＳＬ ＢＳＲは、代替的に、第２の指示情報を含んでいてもよい。基地局は、専用ＬＣＧまたは専用宛先インデックスおよび第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

第１の要求メッセージがＳＬ ＢＳＲであるとき、別の例示的な方式では、第１の端末デバイスは、ＳＬ ＢＳＲの共通ＬＣＧまたは共通宛先インデックスを使用することによってＳＬ ＢＳＲを基地局に送信し、ＳＬ ＢＳＲは第２の指示情報を含む。基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

第１の要求メッセージがＳＬ ＢＳＲであるとき、さらに別の例示的な方式では、第１の端末デバイスは、特定のフォーマット（format）のＳＬ ＢＳＲを基地局に送信し、特定のフォーマットのＳＬ ＢＳＲは、特に、マルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースを要求するためのものである。ＳＬ ＢＳＲを受信した後、基地局は、ＳＬ ＢＳＲのフォーマットに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージを受信した後、基地局は、ＵＡＩメッセージに含まれる第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

代替的に、ＵＡＩメッセージを受信する前に、基地局は、第１の端末デバイスによって送信されたＳＵＩメッセージを受信する。ＳＵＩメッセージは第２の指示情報を含み、第２の指示情報は、ＳＵＩメッセージに含まれる宛先またはＱｏＳフローに関連付けられる。ＵＡＩメッセージを受信した後、ＵＡＩメッセージに含まれるＱｏＳフローまたはサービスモードが第２の指示情報に関連付けられた宛先またはＱｏＳフローに対応するとき、基地局は、第１の端末デバイスによって要求されたＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

Ｓ４０４：基地局が、第１のＳＬリソースに関する情報を第１の端末デバイスに送信する。

基地局は、第１の要求メッセージの応答メッセージ、ＲＲＣ再構成メッセージ、または第１のＳＬリソースに関する情報を搬送するＤＣＩを第１の端末デバイスに送信し得る。

Ｓ４０５：第１の端末デバイスが、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを第２の端末デバイスに送信する。

第１の端末デバイスは、既存のＬＣＰ規則を使用することによって、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信してもよいし、実施形態２における方法を使用することによって、送信されるべき宛先／論理チャネルから、第１のデータまたは第１のシグナリングに対応する宛先／論理チャネルのみを選択するか、もしくは優先的に選択して、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信してもよい。具体的な実装形態については、実施形態２のステップ３０４の説明を参照されたい。詳細は本明細書で改めて説明しない。

それに対応して、第２の端末デバイスは、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを受信する。第１の端末デバイスは、マルチキャストまたはブロードキャスト方式で第１のデータまたは第１のシグナリングを送信し、マルチキャストまたはブロードキャスト受信範囲内の端末デバイスは、第１のデータまたは第１のシグナリングを受信するための第２の端末デバイスとして使用され得ることが理解され得る。

この実施形態では、第１の端末デバイスが第１の基地局にリソースを要求するとき、第２の指示情報は、第１の要求メッセージで搬送され、基地局は、第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定して、要求されたリソースを第１の端末デバイスに割り当て得る。

図８は、本出願の実施形態４によるサイドリンク通信方法のシグナリングフローチャートである。この実施形態と実施形態３との間の違いは、以下の通りである：第１の要求メッセージを基地局に送信する前に、第１の端末デバイスは、まず、第２の指示情報を基地局に送信し、基地局は、第２の指示情報および第１の要求メッセージに基づいて、リソースを第１の端末デバイスに割り当てる。図８に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ５０１：第１の端末デバイスが、第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定し、ここで、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである。

Ｓ５０２：第１の端末デバイスが、ＳＵＩメッセージを基地局に送信し、ここで、ＳＵＩメッセージは第２の指示情報を含む。

この実施形態は、第２の指示情報がＳＵＩメッセージで搬送される例を使用することによって説明される。第２の指示情報は別のメッセージで搬送されてもよく、この実施形態では限定されないことが理解され得る。

Ｓ５０３：第１の端末デバイスが、第１の要求メッセージを基地局に送信する。

任意選択で、第１の要求メッセージは、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージである。

Ｓ５０４：基地局が、第１の要求メッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。

第１の要求メッセージがＳＬ ＳＲであるとき、例示的な方式では、第１の端末デバイスは、専用ＳＬ ＳＲを基地局に送信する。専用ＳＬ ＳＲを受信した後、基地局は、専用ＳＬ ＳＲに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。専用ＳＬ ＳＲは、ＳＵＩメッセージ内の第２の指示情報に基づいて、基地局によって第１の端末デバイスに割り当てられる。それに対応して、Ｓ５０３の前に、基地局は、ＳＵＩ応答メッセージまたは別のメッセージを通じて、専用ＳＬ ＳＲの構成情報を第１の端末デバイスに送信する。

第１の要求メッセージがＳＬ ＢＳＲであるとき、例示的な方式では、第１の端末デバイスは、専用ＬＣＧまたは専用宛先インデックスを使用することによって、ＳＬ ＢＳＲを基地局に送信し得る。ＳＬ ＢＳＲを受信した後、基地局は、ＳＬ ＢＳＲの専用ＬＣＧまたは専用宛先インデックスに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。専用ＬＣＧまたは専用宛先インデックスは、ＳＵＩメッセージ内の第２の指示情報に基づいて、第１の端末デバイスのために基地局によって構成される。それに対応して、Ｓ５０３の前に、基地局は、ＳＵＩ応答メッセージまたは別のメッセージを通じて、専用ＬＣＧまたは専用宛先インデックスの構成情報を第１の端末デバイスに送信する。

任意選択で、ＳＬ ＢＳＲは、代替的に、第２の指示情報を含んでいてもよい。基地局は、専用ＬＣＧまたは専用宛先インデックスおよび第２の指示情報に基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

第１の要求メッセージがＳＬ ＢＳＲであるとき、別の例示的な方式では、第１の端末デバイスは、共通ＬＣＧまたは共通宛先インデックスを使用することによって、ＳＬ ＢＳＲを基地局に送信する。ＳＬ ＢＳＲは、宛先インデックスまたはＱｏＳフロー識別子を含む。基地局は、第２の指示情報に関連付けられた宛先またはＱｏＳフローと、ＳＬ ＢＳＲに含まれる宛先インデックスまたはＱｏＳフロー識別子とに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てる。具体的には、ＳＬ ＢＳＲに含まれる宛先インデックスまたはＱｏＳフロー識別子が、第２の指示情報に関連付けられた宛先またはＱｏＳフローに対応するとき、基地局は、第１の端末デバイスによって要求されたＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定する。

第１の要求メッセージがＵＡＩメッセージであるとき、ＵＡＩメッセージを受信した後、ＵＡＩメッセージに含まれるＱｏＳフロー情報およびサービスモードが第２の指示情報に関連付けられた宛先またはＱｏＳフローに対応するとき、基地局は、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定し、第１のＳＬリソースを第１の端末デバイスに割り当てる。

Ｓ５０５：基地局が、第１のＳＬリソースに関する情報を第１の端末デバイスに送信する。

Ｓ５０６：第１の端末デバイスが、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを第２の端末デバイスに送信する。

この実施形態では、第１の基地局にリソースを要求する前に、第１の端末デバイスは、第２の指示情報を基地局に送信し、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示し、第１の要求メッセージを使用することによって基地局に第１のＳＬリソースを要求する。基地局は、第２の指示情報および第１の要求メッセージに基づいて、第１の端末デバイスによって要求されたリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであると決定して、要求されたリソースを第１の端末デバイスに割り当てる。

実際の適用では、端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸおよびユニキャストＳＬ ＤＲＸの両方をサポートする。ユニキャスト接続が確立される前に、端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースのみを使用することによって、送信または受信を実行し得る。具体的には、端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに対応する時間においてのみ無線周波数受信機を有効にする。端末デバイスは、いくつかの時点において（すなわち、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに対応する時間において）のみ受信を実行することができるので、送信側端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに対応する時間以外の時間においてデータを送信し、受信側端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに対応する時間においてのみデータを受信する場合、ユニキャスト接続を確立するプロセスにおけるメッセージは欠落し、ユニキャスト接続の確立に影響を及ぼす。

上記の問題を解決するために、本出願の実施形態５は、サイドリンク通信方法を提供する。図９は、本出願の実施形態５によるサイドリンク通信方法のシグナリングフローチャートである。この実施形態は、受信側の観点から説明される。図９に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ６０１：端末デバイスが、第１の時点において第１のＤＲＸの送信を非アクティブ化し、ここで、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸであり、第１の時点は、ＳＬユニキャスト接続確立要求メッセージの受信時点または発見要求メッセージの受信時点である。

この実施形態では、端末デバイスは、第１の時点において第１のＤＲＸを直ちに非アクティブ化し得るか、または第１の時点において予め設定された遅延時間の後に第１のＤＲＸを非アクティブ化し得る。予め設定された遅延時間は、ネットワークデバイスによって構成され得る。

任意選択で、第１の時点は、代替的に、告知メッセージの送信時点であってもよい。

Ｓ６０２：端末デバイスが、第２の時点において第１のＤＲＸをアクティブ化し、ここで、第２の時点は、ＳＬユニキャスト接続確立受諾メッセージの送信時点、第１のＰＣ５ ＲＲＣ再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である。

方法において、受信側端末デバイスは、第１の時点と第２の時点との間で第１のＤＲＸを無効にし、受信側端末デバイスは、通常のＳＬリソースに対応するすべての時間期間においてデータを受信する。この実施形態では、受信側端末デバイスが第１の時点と第２の時点との間で第１のＤＲＸを無効にした後、受信側端末デバイスは、第１の時点と第２の時点との間の受信リソースプールに対応するすべての時間期間にデータを受信することができることを意味し、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上でのみデータを受信することに限定されない。

第１の時点は、ＳＬユニキャスト接続確立メッセージ（すなわち、図３に示される第１のメッセージ）の受信時点または発見要求メッセージ（例えば、要請の発見メッセージ）の受信時点であり、第２の時点に受信されるメッセージは、第１の時点に受信されるメッセージに対応する。それに対応して、第２の時点は、ＳＬユニキャスト接続確立受諾メッセージ（すなわち、図３に示される第４のメッセージ）の送信時点、第１のＰＣ５ ＲＲＣ再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である。

任意選択で、第１のタイマは、第１の時点に開始され、第１のタイマのタイミング期間は、予め構成されるか、または予め定義される。任意選択で、端末デバイスは、代替的に、第１の時点から特定の時間の遅延の後に第１のタイマを有効にしてもよい。

第１の時点および第２の時点の値から、この実施形態における方法は、ユニキャスト接続の確立の開始からユニキャスト接続の確立の完了までの時間期間において第１のＤＲＸを無効にすることと同等であり、すなわち、受信側端末デバイスは、ユニキャスト接続の確立の開始からユニキャスト接続の確立の完了までの時間期間においてデータを正常に受信することができ、ユニキャスト接続を確立するプロセスにおいて送信側デバイスによって送信されたすべてのメッセージを受信側端末デバイスが受信することができ、ユニキャスト接続を確立するプロセスにおけるメッセージが欠落せず、マルチキャストまたはブロードキャストＳＬ ＤＲＸがユニキャスト接続の確立に影響を及ぼさないことを保証することがわかる。

この実施形態では、受信側の観点から、送信側にも同様の問題が存在する。この実施形態では、送信側端末デバイスは、第３の時点において第１のＤＲＸを非アクティブ化し、第４の時点において第１のＤＲＸをアクティブ化し得る。言い換えれば、送信側端末デバイスは、第３の時点と第４の時点との間の第１のＤＲＸを無効にする。第３の時点は、ＳＬユニキャスト接続確立メッセージの送信時点または発見要求メッセージの送信時点であり得る。それに対応して、第４の時点は、ＳＬユニキャスト接続確立受諾メッセージの受信時点、第１のＰＣ５ ＲＲＣ再構成メッセージの送信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマの有効化時点である。

任意選択で、第３の時点は、代替的に、告知メッセージの受信時点であってもよい。

ユニキャスト接続が確立された後には、マルチキャストまたはブロードキャストＳＬ ＤＲＸおよびユニキャストＳＬ ＤＲＸの両方が存在する。それに対応して、端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを使用することによって送信または受信を実行することができ、またはユニキャスト接続に対応するＳＬリソースを使用することによって送信または受信を実行することができる。この実施形態では、端末デバイスは、時間領域におけるマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するリソースとユニキャストＳＬ ＤＲＸに対応するリソースとの和集合を、端末デバイスがデータを送信または受信するための時間として使用し得る。

図１１は、端末デバイスがデータを送信する概略図である。図１１に示すように、データを送信するために第１の端末デバイスによって占有されるＳＬリソース（すなわち、図中の斜線部分によって示されるリソース）の一部は、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース（すなわち、図中の灰色部分によって示されるリソース）内に位置し、他の部分は、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースの外側に位置する。例えば、第１の端末デバイスによって送信されるデータ内のＳＣＩによって占有されるリソースは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース内に位置し、ＳＣＩによって示されるトランスポートブロック（transport block、ＴＢ）により占有されるリソースの全部または一部は、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースの外側に位置する。この場合、第２の端末デバイスが第１の端末デバイスによって送信されたデータに関心があり、第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸをアクティブ化する場合、第２の端末デバイスは、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上でＳＣＩを正常に受信し得るが、ＳＣＩによって示されるＴＢを、マルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソース上で受信することはできない。従来の技術では、ＴＢをどのように処理するかが説明されておらず、これは、ＳＬ通信における例外または端末デバイスの受信例外を引き起こし得る。

前述の問題を解決するために、一実施形態は、サイドリンク通信方法を提供する。図１２は、本出願の実施形態６によるサイドリンク通信方法のフローチャートである。図１２に示すように、この実施形態において提供される方法は、以下のステップを含む。

Ｓ７０１：第２の端末デバイスが、第１の端末デバイスによって送信されたＳＣＩを受信する。

Ｓ７０２：第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸ状態にあり、ＳＣＩによって示されるＴＢに対応するリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに属さないかまたは部分的に属するとき、第２の端末デバイスが、ＳＣＩによって示されるＴＢを受信しないか、または第２の端末デバイスが、ＳＣＩによって示されるＴＢを受信するが、ＳＣＩに対応するハイブリッド自動再送要求ラウンドトリップタイマ（hybrid automatic repeat request round trip time、ＨＡＲＱ ＲＴＴ）タイマまたは非アクティビティ（ＩＮＡＣＴＩＶＩＴＹ）タイマを有効にしない。

第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸ状態にあることは、第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸを現在アクティブ化していること、または第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースを使用することによってデータを現在受信していることと理解され得る。

ＨＡＲＱ ＲＴＴタイマは、ＨＡＲＱプロセスに関連付けられる。ＨＡＲＱ ＲＴＴタイマが動作しているとき、端末デバイスは、物理サイドリンク制御チャネル（physical sidelink control channel、ＰＳＣＣＨ）をリッスンする必要はなく、ＰＳＣＣＨチャネルは、ＳＣＩを送信するために使用される。従来技術では、ＳＣＩを受信した後、第２の端末デバイスは、ＨＡＲＱ ＲＴＴタイマを有効にし、ＳＣＩによって示されるＴＢを受信する。この実施形態では、ＳＣＩを受信した後、第２の端末デバイスは、ＨＡＲＱ ＲＴＴタイマを有効にせず、対応する再送データの後続の受信を回避する。

ＩＮＡＣＴＩＶＩＴＹタイマは、ユニキャスト接続に関連付けられる。ＩＮＡＣＴＩＶＩＴＹタイマが動作しているとき、端末デバイスは、ＰＳＣＣＨチャネルをリッスンする必要がある。従来技術では、ＳＣＩを受信した後、ＳＣＩが新規送信を示す場合、第２の端末デバイスは、ＩＮＡＣＴＩＶＩＴＹタイマを有効にし、ＳＣＩによって示されるＴＢを受信する。この実施形態では、ＳＣＩを受信した後、第２の端末デバイスは、ＩＮＡＣＴＩＶＩＴＹタイマを有効にせず、対応する再送データの後続の受信を回避する。

この実施形態では、第２の端末デバイスがマルチキャストまたはブロードキャストＳＬ ＤＲＸ状態にあり、受信されたＳＣＩによって示されるＴＢに対応するリソースがマルチキャストまたはブロードキャストＳＬ ＤＲＸに対応するＳＬリソースに属さないかまたは部分的に属するとき、第２の端末デバイスのアクションが指定され、すなわち、第２の端末デバイスは、ＳＣＩによって示されるＴＢを受信しないか、またはＳＣＩによって示されるＴＢを受信するが、ＳＣＩに対応するＨＡＲＱ ＲＴＴタイマまたはＩＮＡＣＴＩＶＩＴＹタイマを有効にせず、その結果、通常のＳＬ通信を保証することができる。

図１３は、本出願の実施形態７による第１の端末デバイスの構造の概略図である。図１３に示すように、この実施形態において提供される第１の端末デバイス２００は、決定モジュール２１と、取得モジュール２２と、送信モジュール２３とを含む。

決定モジュール２１は、第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすると決定するように構成され、第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸである。

取得モジュール２２は、第１のＳＬリソースを取得するように構成され、第１のＳＬリソースは、第１のＤＲＸに対応するＳＬリソースである。

送信モジュール２３は、第１のＳＬリソース上で第１のデータまたは第１のシグナリングを送信するように構成される。

任意選択で、決定モジュール２１は、第１の端末デバイスの上位層から第１の指示情報を受信するように特に構成され、第１の指示情報は、第１のデータまたは第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示す。

任意選択で、第１の指示情報は、第１のデータに関連付けられたサービスまたはＱｏＳフローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを含む。

任意選択で、取得モジュール２２は、第１の要求メッセージをネットワークデバイスに送信することであって、第１の要求メッセージは、第１のＳＬリソースを要求するためのものである、送信することと、ネットワークデバイスによって送信された第１のＳＬリソースに関する情報を受信することとを行うように特に構成される。

例示的な方式では、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

別の例示的な方式では、取得モジュール２２は、第１の要求メッセージをネットワークデバイスに送信する前に、第２の指示情報をネットワークデバイスに送信するようにさらに構成され、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージである。

第１の要求メッセージが、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージであるとき、任意選択で、第２の指示情報は、ＳＵＩメッセージで搬送される。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む。

任意選択で、取得モジュール２２は、アイドルＳＬリソースを測定することによって第１のＳＬリソースを取得するように特に構成される。

任意選択で、送信モジュール２３は、送信されるべき宛先から、第１のデータまたは第１のシグナリングに対応する宛先のみを、送信のための宛先として選択するか、または優先的に選択するように、または送信されるべき論理チャネルから、第１のデータまたは第１のシグナリングに対応する論理チャネルのみを、送信のための論理チャネルとして選択するか、または優先的に選択するように特に構成される。

この実施形態において提供される第１の端末デバイス２００は、実施形態１から実施形態４における第１の端末デバイスによって実行される方法ステップを実行するように構成され得る。具体的な実装形態および技術的効果は同様であり、詳細は本明細書で改めて説明しない。

図１４は、本出願の実施形態８によるネットワークデバイスの構造の概略図である。図１４に示すように、この実施形態において提供されるネットワークデバイス３００は、受信モジュール３１および割り当てモジュール３２を含む。

受信モジュール３１は、第１の端末デバイスによって送信された第１の要求メッセージを受信するように構成され、第１の要求メッセージは、第１のサイドリンク（ＳＬ）リソースを要求するためのものであり、第１のＳＬリソースは、第１の間欠受信（ＤＲＸ）に対応するＳＬリソースであり、第１のＤＲＸは、マルチキャストまたはブロードキャストＤＲＸである。

割り当てモジュール３２は、第１の要求メッセージに基づいて、第１のＳＬリソースを第１の端末デバイスに割り当てるように構成される。

例示的な方式では、第１の要求メッセージは第２の指示情報を含み、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

別の例示的な方式では、受信モジュール３１は、第１の要求メッセージを受信する前に、第１の端末デバイスによって送信された第２の指示情報を受信するようにさらに構成され、第２の指示情報は、宛先またはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す。

任意選択で、第１の要求メッセージは、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージである。

第１の要求メッセージが、ＳＬ ＳＲ、ＳＬ ＢＳＲ、およびＵＡＩメッセージのうちのいずれか１つのメッセージであるとき、任意選択で、第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される。

任意選択で、第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む。

この実施形態において提供されるネットワークデバイス３００は、実施形態１から実施形態４におけるネットワークデバイスによって実行される方法ステップを実行するように構成され得る。具体的な実装形態および技術的効果は同様であり、詳細は本明細書で改めて説明しない。

図１５は、本出願の実施形態９による第２の端末デバイスの構造の概略図である。図１５に示すように、この実施形態において提供される第２の端末デバイス４００は、受信モジュール４１と、決定モジュール４２と、アクティブ化モジュール４３とを含む。

受信モジュール４１は、第２の端末デバイスの上位層から第１の指示情報を受信するように構成され、第１の指示情報は、第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすることを示し、第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである。

決定モジュール４２は、第１の指示情報に基づいて、現在受信されるべきデータまたはシグナリングが第１のＤＲＸをサポートすると決定するように構成される。

アクティブ化モジュール４３は、第１のＤＲＸをアクティブ化するように構成される。

受信モジュール４１およびアクティブ化モジュール４３は、代替的に、１つのモジュール、例えば、処理モジュールを使用することによって実装されてもよいことが理解され得る。処理モジュールは、受信モジュール４１およびアクティブ化モジュール４３のすべての機能を実装する。

この実施形態において提供される第２の端末デバイス４００は、実施形態１から実施形態４における第２の端末デバイスによって実行される方法ステップを実行するよう構成され得る。具体的な実装形態および技術的効果は同様であり、詳細は本明細書で改めて説明しない。

図１６は、本出願の実施形態１０による第２の端末デバイスの構造の概略図である。図１６に示すように、この実施形態において提供される第２の端末デバイス５００は、非アクティブ化モジュール５１およびアクティブ化モジュール５２を含む。

非アクティブ化モジュール５１は、第１の時点において第１の間欠受信（ＤＲＸ）を非アクティブ化するように構成され、第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸであり、第１の時点は、ＳＬユニキャスト接続確立メッセージの受信時点または発見要求メッセージの受信時点である。

アクティブ化モジュール５２は、第２の時点において第１のＤＲＸをアクティブ化するように構成され、第２の時点は、ＳＬユニキャスト接続確立受諾メッセージの受信時点、第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である。

任意選択で、第２の端末デバイスは、第１の時点に第１のタイマを開始する。

任意選択で、非アクティブ化モジュール５１は、第１の時点においてプリセット時間が遅延した後に第１のＤＲＸを非アクティブ化するように特に構成される。

非アクティブ化モジュール５１およびアクティブ化モジュール５２は、代替的に、１つのモジュール、例えば、処理モジュールを使用することによって実装されてもよいことが理解され得る。処理モジュールは、非アクティブ化モジュール５１およびアクティブ化モジュール５２のすべての機能を実装する。

この実施形態において提供される第２の端末デバイス５００は、実施形態５における方法を実行するように構成され得る。具体的な実装形態および技術的効果は同様であり、詳細は本明細書で改めて説明しない。

本出願の実施形態におけるモジュールは、ユニットとも呼ばれ得ることが理解され得る。例えば、非アクティブ化モジュールは、非アクティブ化ユニットと呼ばれることもある。

本出願で説明されるシステム、装置、および方法は、他の方式で実装され得る。例えば、上述した装置の実施形態は単なる例である。例えば、ユニット／モジュールの分割は、単なる論理的な機能分割であり、実際の実装時には他の分割であってもよい。例えば、複数のユニットまたは構成要素は、別のシステムに結合または統合されてもよいし、一部の特徴が無視されたり実行されなかったりしてもよい。加えて、表示または議論された相互結合または直接結合または通信接続は、いくつかのインターフェースを介して実装され得る。装置またはユニット間の間接結合または通信接続は、電子的に、機械的に、または他の形態で実装され得る。

加えて、本出願の実施形態における機能ユニットは、１つの処理ユニットに統合されてもよく、ユニットの各々は、物理的に独立して存在してもよく、または２つ以上のユニットが１つのユニットに統合されてもよい。

前述のモジュールまたはユニットは、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせを使用することによって実装され得る。例えば、図１３の決定モジュールは、ソフトウェアに基づいて実装され得る。

本出願では、「ソフトウェアを使用することによって実装される」は、プロセッサが、メモリに記憶されたプログラム命令を読み取って実行し、前述のモジュールまたはユニットに対応する機能を実装することを意味する。プロセッサは、プログラム命令を実行する機能を有する処理回路であり、限定はしないが、中央処理装置（central processing unit、ＣＰＵ）、マイクロプロセッサ、デジタルシグナルプロセッサ（digital signal processor、ＤＳＰ）、マイクロコントローラユニット（microcontroller unit、ＭＣＵ）、または人工知能プロセッサなどの、プログラム命令を実行することができる以下の処理回路のうちの少なくとも１つを含む。いくつかの他の実施形態では、プロセッサは、別の処理機能を有する回路（例えば、ハードウェアアクセラレーションのために使用されるハードウェア回路、バス、およびインターフェース回路）をさらに含み得る。プロセッサは、集積チップの形態で提示され得、例えば、処理機能がソフトウェア命令実行機能のみを含む集積チップの形態で提示されてもよいし、ＳｏＣ（system on a chip、システムオンチップ）の形態で提示されてもよい。すなわち、プログラム命令を実行することができる処理回路（通常、「コア」と呼ばれる）に加えて、チップは、特定の機能を実装するように構成された別のハードウェア回路（ＡＳＩＣまたはＦＰＧＡに基づいて実装され得る）をさらに含む。それに対応して、ソフトウェア命令実行機能に加えて、処理機能は、様々なハードウェアアクセラレーション機能（ＡＩ計算、符号化および復号、ならびに圧縮および解凍など）をさらに含み得る。

本出願では、「ハードウェアによって実装される」は、前述のモジュールまたはユニットの機能が、プログラム命令を処理する機能を有さないハードウェア処理回路を通して実装されることを意味する。ハードウェア処理回路は、ディスクリートハードウェア構成要素を含み得るか、または集積回路であり得る。電力消費およびサイズを低減するために、通常、集積回路が実装に使用される。ハードウェア処理回路は、特定用途向け集積回路（application-specific integrated circuit、ＡＳＩＣ）またはプログラマブル論理デバイス（programmable logic device、ＰＬＤ）を含み得る。ＰＬＤは、フィールドプログラマブルゲートアレイ（field programmable gate array、ＦＰＧＡ）、複合プログラマブル論理デバイス（complex programmable logic device、ＣＰＬＤ）などをさらに含み得る。これらのハードウェア処理回路は、個別にパッケージ化された半導体チップであってもよいし、他の回路（ＣＰＵ、ＤＳＰなど）と集積されてパッケージ化された半導体チップであってもよい。例えば、ＡＳＩＣおよびＣＰＵは、一緒に統合されてＳｏＣを形成してもよく、ＳｏＣは、チップに独立してパッケージ化されるか、または、ＦＰＧＡおよびＣＰＵは、一緒に統合されてＳｏＰＣ（システムオンプログラマブルチップ、system on a programmable chip）を形成してもよい。

本出願がソフトウェア、ハードウェア、またはソフトウェアとハードウェアとの組み合わせを使用することによって実装されるとき、本出願は、１つのタイプのソフトウェアまたはハードウェアのみに限定されない、異なるソフトウェアおよびハードウェアを使用することによって実装され得ることに留意されたい。例えば、モジュールまたはユニットのうちの１つは、ＣＰＵを通して実装され得、別のモジュールまたはユニットは、ＤＳＰを通して実装され得る。同様に、ハードウェアが実装に使用されるとき、モジュールまたはユニットのうちの１つは、ＡＳＩＣを通して実装され得、別のモジュールまたはユニットは、ＦＰＧＡを通して実装され得る。当然ながら、いくつかまたはすべてのモジュールまたはユニットが、同じタイプのソフトウェアを使用することによって（例えば、ＣＰＵを通して）、または同じタイプのハードウェアを使用することによって（例えば、ＡＳＩＣを通して）実装されることも指定されない。加えて、当業者であれば、ソフトウェアは通常、ハードウェアよりも柔軟性は良好であるが性能は低く、ハードウェアは対蹠的であることを知っているであろう。したがって、当業者は、実際の要件に基づいて、実装のためにソフトウェア、ハードウェア、またはそれらの組み合わせを選択し得る。

図１７は、本出願の実施形態１１による端末デバイスの構造の概略図である。図１７に示すように、端末デバイス６００は、プロセッサ６１と、メモリ６２と、トランシーバ６３とを含む。メモリ６２は、命令を記憶するように構成される。トランシーバ６３は、別のデバイスと通信するように構成される。プロセッサ６１は、端末デバイス６００が、前述の方法の実施形態における第１の端末デバイスまたは第２の端末デバイスによって実行される方法を実行することができるように、メモリに記憶された命令を実行するように構成される。

本出願の実施形態１２は、ネットワークデバイスを提供する。ネットワークデバイスの構造については、図１７を参照されたい。メモリ６２は、命令を記憶するように構成される。トランシーバ６３は、別のデバイスと通信するように構成される。プロセッサ６１は、ネットワークデバイスが、前述の方法の実施形態におけるネットワークデバイスによって実行される方法を実行することができるように、メモリ６２に記憶された命令を実行するように構成される。

具体的な実装形態では、一実施形態において、ネットワークデバイスまたは端末デバイスは、複数のプロセッサを含み得る。プロセッサの各々は、シングルコアプロセッサ（シングルＣＰＵ）であってもよいし、マルチコアプロセッサ（マルチＣＰＵ）であってもよい。プロセッサは、デジタルシグナルプロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、別の同等の集積またはディスクリート論理回路などであってもよい。

メモリは、読取り専用メモリ(read-only memory、ＲＯＭ）もしくは静的情報および命令を記憶することができる別のタイプの静的記憶デバイス、またはランダムアクセスメモリ（random access memory、ＲＡＭ）もしくは情報および命令を記憶することができる別のタイプの動的記憶デバイスであってもよいし、電気的消去可能プログラマブル読取り専用メモリ（Electrically Erasable Programmable Read-Only Memory、ＥＥＰＲＯＭ）、コンパクトディスク読取り専用メモリ（Compact Disc Read-Only Memory、ＣＤ－ＲＯＭ）もしくは別のコンパクトディスクストレージ、または光ディスクストレージ（圧縮光ディスク、レーザディスク、光ディスク、デジタル多用途ディスク、ブルーレイディスクなどを含む）、磁気ディスクストレージ媒体もしくは別の磁気記憶デバイス、または予想されるプログラムコードを命令もしくはデータ構造の形態で搬送もしくは記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の媒体であってもよいが、これらに限定されない。メモリは、独立して存在してもよく、通信バスによってプロセッサに接続されてもよい。メモリは、代替的に、プロセッサと統合されてもよい。

本出願の実施形態１３は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は命令を記憶し、命令が実行されると、コンピュータは、前述の方法の実施形態における第１の端末デバイスまたは第２の端末デバイスによって実行される方法を実行することが可能になる。

本出願の実施形態１４は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は命令を記憶し、命令が実行されると、コンピュータは、前述の方法の実施形態におけるネットワークデバイスによって実行される方法を実行することが可能になる。

本出願は、コンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータによって実行されると、前述の方法の実施形態のいずれか１つの機能が実装される。

前述の説明は、本出願の例示的な具体的な実装形態にすぎず、本出願の保護範囲を限定するものではない。本出願において開示される技術的範囲内で当業者によって容易に考え出される任意の変形または置換は、本出願の保護範囲内に入るものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

Claims (49)

1. 第１の端末デバイスに適用されるサイドリンク通信方法であって、
   第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすると決定するステップであって、前記第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸである、ステップと、
   第１のＳＬリソースを取得するステップであって、前記第１のＳＬリソースは、前記第１のＤＲＸに対応するＳＬリソースである、ステップと、
   前記第１のＳＬリソース上で前記第１のデータまたは前記第１のシグナリングを送信するステップと
   を含む方法。
2. 第１のデータまたは第１のシグナリングが第１のＤＲＸをサポートすると決定する前記ステップは、
   前記第１の端末デバイスのアクセス層が、上位層から第１の指示情報を受信するステップであって、前記第１の指示情報は、前記第１のデータまたは前記第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示す、ステップ
   を含む、請求項１に記載の方法。
3. 前記第１の指示情報は、前記第１のデータに関連付けられたサービスまたはサービス品質（ＱｏＳ）フローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを含む、請求項１に記載の方法。
4. 第１のＳＬリソースを取得する前記ステップは、
   第１の要求メッセージをネットワークデバイスに送信するステップであって、前記第１の要求メッセージは、前記第１のＳＬリソースを要求するためのものである、ステップと、
   前記ネットワークデバイスによって送信された前記第１のＳＬリソースに関する情報を受信するステップと
   を含む、請求項１から３のいずれか一項に記載の方法。
5. 前記第１の要求メッセージは第２の指示情報を含み、前記第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す、請求項４に記載の方法。
6. 第１の要求メッセージをネットワークデバイスに送信する前記ステップの前に、前記方法は、
   第２の指示情報を前記ネットワークデバイスに送信するステップであって、前記第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す、ステップ
   をさらに含む、請求項４に記載の方法。
7. 前記第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである、請求項４から６のいずれか一項に記載の方法。
8. 前記第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであり、前記第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される、請求項６に記載の方法。
9. 前記第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む、請求項１から８のいずれか一項に記載の方法。
10. 第１のサイドリンク（ＳＬ）リソースを取得する前記ステップは、
    アイドルＳＬリソースを測定することによって前記第１のＳＬリソースを取得するステップ
    を含む、請求項１から３のいずれか一項に記載の方法。
11. 前記第１のＳＬリソース上で前記第１のデータまたは前記第１のシグナリングを送信する前記ステップは、
    送信されるべき宛先アドレスから、前記第１のデータまたは前記第１のシグナリングに対応する宛先アドレスのみを、送信のための宛先アドレスとして選択するか、または優先的に選択するステップ
    を含む、請求項１から１０のいずれか一項に記載の方法。
12. 前記第１のＳＬリソース上で前記第１のデータまたは前記第１のシグナリングを送信する前記ステップは、
    送信されるべき論理チャネルから、前記第１のデータまたは前記第１のシグナリングに対応する論理チャネルのみを、送信のための論理チャネルとして選択するか、または優先的に選択するステップ
    を含む、請求項１から１０のいずれか一項に記載の方法。
13. 端末デバイスに適用されるサイドリンク通信方法であって、
    第１の端末デバイスによって送信された第１の要求メッセージを受信するステップであって、前記第１の要求メッセージは、第１のサイドリンク（ＳＬ）リソースを要求するためのものであり、前記第１のＳＬリソースは、第１の間欠受信（ＤＲＸ）に対応するＳＬリソースであり、前記第１のＤＲＸは、マルチキャストまたはブロードキャストＤＲＸである、ステップと、
    前記第１の要求メッセージに基づいて、前記第１のＳＬリソースを前記第１の端末デバイスに割り当てるステップと
    を含む方法。
14. 前記第１の要求メッセージは第２の指示情報を含み、前記第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す、請求項１３に記載の方法。
15. 第１の端末デバイスによって送信された第１の要求メッセージを受信する前記ステップの前に、前記方法は、
    前記第１の端末デバイスによって送信された第２の指示情報を受信するステップであって、前記第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す、ステップ
    をさらに含む、請求項１３に記載の方法。
16. 前記第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである、請求項１３から１５のいずれか一項に記載の方法。
17. 前記第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであり、前記第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される、請求項１５に記載の方法。
18. 前記第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む、請求項１３から１７のいずれか一項に記載の方法。
19. 第２の端末デバイスに適用されるサイドリンク通信方法であって、
    アクセス層が、上位層から第１の指示情報を受信するステップであって、前記第１の指示情報は、第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすることを示し、前記第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである、ステップと、
    前記第１の指示情報に基づいて、現在受信されるべきデータまたはシグナリングが前記第１のＤＲＸをサポートすると決定されたとき、前記第１のＤＲＸをアクティブ化するステップと
    を含む方法。
20. 第２の端末デバイスに適用されるサイドリンク通信方法であって、
    第１の時点において第１の間欠受信（ＤＲＸ）を非アクティブ化するステップであって、前記第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸであり、前記第１の時点は、ＳＬユニキャスト接続確立メッセージの受信時点または発見要求メッセージの受信時点である、ステップと、
    第２の時点において前記第１のＤＲＸをアクティブ化するステップであって、前記第２の時点は、ＳＬユニキャスト接続確立要求メッセージの受信時点、第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージの送信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である、ステップ
    を含む方法。
21. 前記第１のタイマは、前記第１の時点に開始される、請求項２０に記載の方法。
22. 第１の時点において第１のＤＲＸを非アクティブ化する前記ステップは、
    前記第１の時点においてプリセット時間が遅延した後に前記第１のＤＲＸを非アクティブ化するステップ
    を含む、請求項２０または２１に記載の方法。
23. 第１の端末デバイスであって、
    第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすると決定するように構成された決定モジュールであって、前記第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸである、決定モジュールと、
    第１のＳＬリソースを取得するように構成された取得モジュールであって、前記第１のＳＬリソースは、前記第１のＤＲＸに対応するＳＬリソースである、取得モジュールと、
    前記第１のＳＬリソース上で前記第１のデータまたは前記第１のシグナリングを送信するように構成された送信モジュールと
    を備えるデバイス。
24. 前記決定モジュールは、
    前記第１の端末デバイスの上位層から第１の指示情報を受信するように特に構成され、前記第１の指示情報は、前記第１のデータまたは前記第１のシグナリングがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを示す、
    請求項２３に記載のデバイス。
25. 前記第１の指示情報は、前記第１のデータに関連付けられたサービスまたはサービス品質（ＱｏＳ）フローがマルチキャストまたはブロードキャストＳＬ ＤＲＸをサポートすることを含む、請求項２３に記載のデバイス。
26. 前記取得モジュールは、
    第１の要求メッセージをネットワークデバイスに送信することであって、前記第１の要求メッセージは、前記第１のＳＬリソースを要求するためのものである、送信することと、
    前記ネットワークデバイスによって送信された前記第１のＳＬリソースに関する情報を受信することと
    を行うように特に構成される、請求項２３から２５のいずれか一項に記載のデバイス。
27. 前記第１の要求メッセージは第２の指示情報を含み、前記第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す、請求項２６に記載のデバイス。
28. 前記取得モジュールは、
    前記第１の要求メッセージを前記ネットワークデバイスに送信する前に、第２の指示情報を前記ネットワークデバイスに送信するようにさらに構成され、前記第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す、
    請求項２６に記載のデバイス。
29. 前記第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである、請求項２６から２８のいずれか一項に記載のデバイス。
30. 前記第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであり、前記第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される、請求項２８に記載のデバイス。
31. 前記第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む、請求項２３から３０のいずれか一項に記載のデバイス。
32. 前記取得モジュールは、
    アイドルＳＬリソースを測定することによって前記第１のＳＬリソースを取得するように特に構成される、
    請求項２３から２５のいずれか一項に記載のデバイス。
33. 前記送信モジュールは、
    送信されるべき宛先アドレスから、前記第１のデータまたは前記第１のシグナリングに対応する宛先アドレスのみを、送信のための宛先アドレスとして選択するか、または優先的に選択するように特に構成される、
    請求項２３から３２のいずれか一項に記載のデバイス。
34. 前記送信モジュールは、
    送信されるべき論理チャネルから、前記第１のデータまたは前記第１のシグナリングに対応する論理チャネルのみを、送信のための論理チャネルとして選択するか、または優先的に選択するように特に構成される、
    請求項２３から３２のいずれか一項に記載のデバイス。
35. ネットワークデバイスであって、
    第１の端末デバイスによって送信された第１の要求メッセージを受信するように構成された受信モジュールであって、前記第１の要求メッセージは、第１のサイドリンク（ＳＬ）リソースを要求するためのものであり、前記第１のＳＬリソースは、第１の間欠受信（ＤＲＸ）に対応するＳＬリソースであり、前記第１のＤＲＸは、マルチキャストまたはブロードキャストＤＲＸである、受信モジュールと、
    前記第１の要求メッセージに基づいて、前記第１のＳＬリソースを前記第１の端末デバイスに割り当てるように構成された割り当てモジュールと
    を備えるデバイス。
36. 前記第１の要求メッセージは第２の指示情報を含み、前記第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す、請求項３５に記載のデバイス。
37. 前記受信モジュールは、
    前記第１の要求メッセージを受信する前に、前記第１の端末デバイスによって送信された第２の指示情報を受信するようにさらに構成され、前記第２の指示情報は、宛先アドレスまたはＱｏＳフローに対応するデータまたはシグナリングによって必要とされるＳＬリソースがマルチキャストまたはブロードキャストＤＲＸに対応するＳＬリソースであることを示す、
    請求項３５に記載のデバイス。
38. 前記第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージである、請求項３５から３７のいずれか一項に記載のデバイス。
39. 前記第１の要求メッセージは、ＳＬスケジューリング要求（ＳＲ）、ＳＬバッファステータスレポート（ＢＳＲ）、およびユーザ支援情報（ＵＡＩ）メッセージのうちのいずれか１つのメッセージであり、前記第２の指示情報は、サイドリンクユーザ情報（ＳＵＩ）メッセージで搬送される、請求項３７に記載のデバイス。
40. 前記第１のシグナリングは、ＳＬユニキャスト接続確立プロセスにおけるメッセージ、リレーＵＥ発見プロセスにおけるメッセージ、ＵＥのＳＬ能力関連メッセージ、および第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージのうちの１つまたは複数のシグナリングを含む、請求項３５から３９のいずれか一項に記載のデバイス。
41. 第２の端末デバイスであって、
    前記第２の端末デバイスの上位層から第１の指示情報を受信するように構成された受信モジュールであって、前記第１の指示情報は、第１のデータまたは第１のシグナリングが第１の間欠受信（ＤＲＸ）をサポートすることを示し、前記第１のＤＲＸはマルチキャストまたはブロードキャストＳＬ ＤＲＸである、受信モジュールと、
    前記第１の指示情報に基づいて、現在受信されるべきデータまたはシグナリングが前記第１のＤＲＸをサポートすると決定するように構成された決定モジュールと、
    前記第１のＤＲＸをアクティブ化するように構成されたアクティブ化モジュールと
    を備えるデバイス。
42. 端末デバイスであって、
    第１の時点において第１の間欠受信（ＤＲＸ）を非アクティブ化するように構成された非アクティブ化モジュールであって、前記第１のＤＲＸはマルチキャストまたはブロードキャストサイドリンク（ＳＬ）ＤＲＸであり、前記第１の時点は、ＳＬユニキャスト接続確立メッセージの受信時点または発見要求メッセージの受信時点である、非アクティブ化モジュールと、
    第２の時点において前記第１のＤＲＸをアクティブ化するように構成されたアクティブ化モジュールであって、前記第２の時点は、ＳＬユニキャスト接続確立受諾メッセージの受信時点、第１のＰＣ５無線リソース制御（ＲＲＣ）再構成メッセージの受信時点、ユニキャスト接続ＤＲＸ構成の完了時点、または第１のタイマのタイムアウト時点である、アクティブ化モジュールと
    を備えるデバイス。
43. 前記端末デバイスは、前記第１の時点に前記第１のタイマを開始する、請求項４２に記載のデバイス。
44. 前記非アクティブ化モジュールは、
    前記第１の時点においてプリセット時間が遅延した後に前記第１のＤＲＸを非アクティブ化するように特に構成される、
    請求項４２または４３に記載のデバイス。
45. プロセッサと、メモリと、トランシーバとを備える端末デバイスであって、前記メモリは、命令を記憶するように構成され、前記トランシーバは、別のデバイスと通信するように構成され、前記プロセッサは、前記端末デバイスが請求項１から１２、請求項１９、および請求項２０から２２のいずれか一項に記載の方法を実行するように、前記メモリに記憶された前記命令を実行するように構成される、端末デバイス。
46. プロセッサと、メモリと、トランシーバとを備えるネットワークデバイスであって、前記メモリは、命令を記憶するように構成され、前記トランシーバは、別のデバイスと通信するように構成され、前記プロセッサは、前記ネットワークデバイスが請求項１３から１８のいずれか一項に記載の方法を実行するように、前記メモリに記憶された前記命令を実行するように構成される、ネットワークデバイス。
47. コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体は命令を記憶し、前記命令が実行されると、コンピュータが請求項１から２２のいずれか一項に記載の方法を実行することが可能になる、コンピュータ可読記憶媒体。
48. コンピュータプログラム製品であって、前記コンピュータプログラム製品は命令を含み、前記命令が実行されると、コンピュータは、請求項１から２２のいずれか一項に記載の方法を実行することが可能になる、コンピュータプログラム製品。
49. 第１の端末デバイスと、第２の端末デバイスと、ネットワークデバイスとを備える通信システムであって、前記第１の端末デバイスは、請求項１から１２のいずれか一項に記載の方法を実行するように構成され、前記第２の端末デバイスは、請求項１９に記載の方法を実行するように構成され、前記ネットワークデバイスは、請求項１３から１８のいずれか一項に記載の方法を実行するように構成される、通信システム。

Images