特許 7565359 ＮＲネットワーク内でのサイドリンク通信用の経路選択

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-02

(45)【発行日】2024-10-10

(54)【発明の名称】ＮＲネットワーク内でのサイドリンク通信用の経路選択

(51)【国際特許分類】

   H04W 40/02 20090101AFI20241003BHJP

   H04W 88/04 20090101ALI20241003BHJP

   H04W 76/14 20180101ALI20241003BHJP

   H04W 8/00 20090101ALI20241003BHJP

【ＦＩ】

H04W40/02 110

H04W88/04

H04W76/14

H04W8/00 110

【請求項の数】 22

(21)【出願番号】P 2022540874

(86)(22)【出願日】2020-10-02

(65)【公表番号】

(43)【公表日】2023-04-13

(86)【国際出願番号】 EP2020077678

(87)【国際公開番号】W WO2021139906

(87)【国際公開日】2021-07-15

【審査請求日】2022-09-28

(31)【優先権主張番号】62/958,011

(32)【優先日】2020-01-07

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】598036300

【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）

(74)【代理人】

【識別番号】100109726

【弁理士】

【氏名又は名称】園田 吉隆

(74)【代理人】

【識別番号】100161470

【弁理士】

【氏名又は名称】冨樫 義孝

(74)【代理人】

【識別番号】100194294

【弁理士】

【氏名又は名称】石岡 利康

(74)【代理人】

【識別番号】100194320

【弁理士】

【氏名又は名称】藤井 亮

(74)【代理人】

【識別番号】100150670

【弁理士】

【氏名又は名称】小梶 晴美

(72)【発明者】

【氏名】フー， チャン

(72)【発明者】

【氏名】チャン， コンチ

(72)【発明者】

【氏名】コンドルチ， マッシモ

(72)【発明者】

【氏名】エリクソン， アンデシュ エー．

(72)【発明者】

【氏名】ラーション， コニー

【審査官】中元 淳二

(56)【参考文献】

【文献】国際公開第２０１４／１１２８３４（ＷＯ，Ａ１）

【文献】vivo，Solution to support UE-to-UE Relay connection establishment[online]，3GPP TSG SA WG2 #136 S2-1911477，Internet<URL:https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_136_Reno/Docs/S2-1911477.zip>，2019年11月08日

【文献】CATT，Solution to support UE-to-UE Relay[online]，3GPP TSG SA WG2 #136 S2-1911451，Internet<URL:https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_136_Reno/Docs/S2-1911451.zip>，2019年11月08日

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４－７／２６

Ｈ０４Ｗ ４／００－９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

(57)【特許請求の範囲】

【請求項1】

Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信用の要求側ユーザ機器（ＵＥ）（３０、４００、６００）によって実装される方法（１００）であって、前記方法（１００）は、
リモートＵＥ（３０、４００、６００）との通信を開始するＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを、１つまたは複数の近隣ＵＥへブロードキャストすること（１１０）であって、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔが、前記要求側ＵＥ（３０、４００、６００）と前記リモートＵＥ（３０、４００、６００）との間の通信経路に中継が許可されるかどうかを示し、かつ、前記通信経路についての最大ホップ数をさらに示す中継インジケーションを含む、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔをブロードキャストすること（１１０）と、
前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔに応答して、前記近隣ＵＥのうちの１つまたは複数から応答メッセージを受信すること（１２０）と
前記１つまたは複数の応答メッセージに基づいて、前記要求側ＵＥ（３０、４００、６００）と前記リモートＵＥ（３０、４００、６００）との間の前記Ｄ２Ｄ通信用の通信経路を判定すること（１３０）と
を含む、方法（１００）。

【請求項2】

前記通信経路が、リモートＵＥ（３０、４００、６００）によって選択され、前記要求側ＵＥ（３０、４００、６００）が、
単一応答メッセージを近隣ＵＥ（３０、４００、６００）から受信し、
前記応答メッセージが受信された前記近隣ＵＥ（３０、４００、６００）の識別情報に基づいて前記通信経路を判定する、請求項１に記載の方法（１００）。

【請求項3】

前記要求側ＵＥ（３０、４００、６００）が、中継としてサーブする近隣ＵＥ（３０、４００、６００）から前記単一応答メッセージを受信し、前記判定された通信経路が、前記要求側ＵＥ（３０、４００、６００）から前記リモートＵＥ（３０、４００、６００）への２つ以上のホップを含む、または、
前記要求側ＵＥ（３０、４００、６００）が、前記リモートＵＥ（３０、４００、６００）から前記単一応答メッセージを直接受信し、前記判定された通信経路が、前記要求側ＵＥ（３０、４００、６００）と前記リモートＵＥ（３０、４００、６００）との間の経路である、
請求項２に記載の方法（１００）。

【請求項4】

前記要求側ＵＥ（３０、４００、６００）が、
前記１つまたは複数の近隣ＵＥのそれぞれから応答メッセージを受信し、
前記要求側ＵＥ（３０、４００、６００）によって受信された前記１つまたは複数の応答メッセージに基づいて前記通信経路を選択する、請求項１に記載の方法（１００）。

【請求項5】

前記要求側ＵＥ（３０、４００、６００）が、前記リモートＵＥ（３０、４００、６００）から応答メッセージを直接受信すると、前記要求側ＵＥ（３０、４００、６００）は前記要求側ＵＥ（３０、４００、６００）から前記リモートＵＥ（３０、４００、６００）への経路を選択する、請求項４に記載の方法（１００）。

【請求項6】

前記要求側ＵＥ（３０、４００、６００）が、前記１つまたは複数の応答メッセージに含まれる経路選択情報に基づいて前記通信経路を選択し、前記経路選択情報が、チャネル品質情報、負荷情報、またはデバイス能力情報のうちの少なくとも１つを含む、請求項４に記載の方法（１００）。

【請求項7】

前記要求側ＵＥ（３０、４００、６００）が、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔをブロードキャストした後、予め定められた時間前に受信された前記応答メッセージのうちの１つまたは複数に基づいて前記通信経路を判定する、請求項１から６のいずれか一項に記載の方法（１００）。

【請求項8】

Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）（３０、４００、６００）であって、前記ＵＥ（３０、４００、６００）は、
Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを、１つまたは複数の近隣ＵＥへブロードキャストすることであって、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔが、要求側ＵＥ（３０、４００、６００）とリモートＵＥ（３０、４００、６００）との間の通信経路に中継が許可されるかどうかを示し、かつ、前記通信経路についての最大ホップ数をさらに示す中継インジケーションを含む、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔをブロードキャストすることと、
前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔに応答して、前記近隣ＵＥのうちの１つまたは複数から応答メッセージを受信することと、
前記１つまたは複数の応答メッセージに基づいて、前記要求側ＵＥ（３０、４００、６００）と前記リモートＵＥ（３０、４００、６００）との間の前記Ｄ２Ｄ通信用の通信経路を判定することと
を行うように構成される、ユーザ機器（ＵＥ）（３０、４００、６００）。

【請求項9】

請求項２から７のいずれか一項に記載の方法を実行するようにさらに構成される、請求項８に記載のＵＥ（３０、４００、６００）。

【請求項10】

無線通信ネットワーク内のユーザ機器（ＵＥ）（３０、４００、６００）中の処理回路によって実行されると、要求側ＵＥとしての前記ＵＥ（３０、４００、６００）に請求項１から７のいずれか一項に記載の方法を実行させる実行可能命令を含む、コンピュータプログラム（６７０）。

【請求項11】

Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信を中継する中継ユーザ機器（ＵＥ）（３０、４００、６００）によって実装される方法（１５０）であって、前記方法（１５０）は、
リモートＵＥ（３０、４００、６００）との通信を開始する要求側ＵＥ（３０、４００、６００）によってブロードキャストされたＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを受信すること（１６０）であって、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔが、前記要求側ＵＥ（３０、４００、６００）と前記リモートＵＥ（３０、４００、６００）との間の通信経路に中継が許可されるかどうかを示し、かつ、前記通信経路についての最大ホップ数をさらに示す中継インジケーションを含む、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを受信すること（１６０）と、
前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを前記リモートＵＥ（３０、４００、６００）に向けて転送すること（１７０）と
を含む、方法（１５０）。

【請求項12】

前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを前記リモートＵＥ（３０、４００、６００）に向けて転送することが、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを前記中継インジケーションの値に応じて転送することを含む、請求項１１に記載の方法（１５０）。

【請求項13】

前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを前記リモートＵＥ（３０、４００、６００）に向けて転送することが、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔについてのＱｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ（ＱｏＳ）要件、前記中継ＵＥ（３０、４００、６００）の負荷、または前記中継ＵＥ（３０、４００、６００）と前記要求側ＵＥ（３０、４００、６００）との間の通信リンクのチャネル品質のうちの少なくとも１つにさらに応じたものになる、請求項１１または１２に記載の方法（１５０）。

【請求項14】

Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）（３０、４００、６００）であって、前記ＵＥ（３０、４００、６００）は、
リモートＵＥ（３０、４００、６００）との通信を開始する要求側ＵＥ（３０、４００、６００）によってブロードキャストされたＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを受信することであって、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔが、前記要求側ＵＥ（３０、４００、６００）と前記リモートＵＥ（３０、４００、６００）との間の通信経路に中継が許可されるかどうかを示し、かつ、前記通信経路についての最大ホップ数をさらに示す中継インジケーションを含む、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを受信することと、
前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを前記リモートＵＥ（３０、４００、６００）に向けて転送することと
を行うように構成される、ユーザ機器（ＵＥ）（３０、４００、６００）。

【請求項15】

請求項１１から１３のいずれか一項に記載の方法を実行するようにさらに構成される、請求項１４に記載のＵＥ（３０、４００、６００）。

【請求項16】

無線通信ネットワーク内のユーザ機器（ＵＥ）（３０、４００、６００）中の処理回路によって実行されると、中継ＵＥとしての前記ＵＥ（３０、４００、６００）に請求項１１から１３のいずれか一項に記載の方法を実行させる実行可能命令を含む、コンピュータプログラム（６７０）。

【請求項17】

Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信用のリモートユーザ機器（ＵＥ）（３０、４００、６００）によって実装される方法（２００）であって、前記方法（２００）は、
前記リモートＵＥ（３０、４００、６００）との通信を開始する要求側ＵＥ（３０、４００、６００）によってブロードキャストされたＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの１つまたは複数の複製を受信すること（２１０）であって、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔが、前記要求側ＵＥ（３０、４００、６００）と前記リモートＵＥ（３０、４００、６００）との間の通信経路に中継が許可されるかどうかを示し、かつ、前記通信経路についての最大ホップ数をさらに示す中継インジケーションを含む、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの複製を受信すること（２１０）と、
前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの前記１つまたは複数の複製のそれぞれに応答して、前記要求側ＵＥ（３０、４００、６００）に、応答メッセージを、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔが受信された前記通信経路に沿って送信すること（２２０）と
を含む、方法（２００）。

【請求項18】

前記要求側ＵＥ（３０、４００、６００）と前記リモートＵＥ（３０、４００、６００）との間のＤ２Ｄ通信用の通信経路を選択することをさらに含み、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの前記１つまたは複数の複製のそれぞれに応答して前記応答メッセージを送信することが、前記選択された通信経路に沿って単一応答メッセージを送信することを含む、請求項１７に記載の方法（２００）。

【請求項19】

前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの前記１つまたは複数の複製を受信すること（２１０）が、前記要求側ＵＥ（３０、４００、６００）とリモートＵＥ（３０、４００、６００）との間の個々の通信経路に沿って前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの複数の複製を受信することを含み、
前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの前記１つまたは複数の複製のそれぞれに応答して前記応答メッセージを送信することが、複数の応答メッセージを、前記通信経路の個々の経路に沿って前記要求側ＵＥ（３０、４００、６００）に送信することを含む、請求項１７に記載の方法（２００）。

【請求項20】

Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）（３０、４００、６００）であって、前記ＵＥ（３０、４００、６００）は、
リモートＵＥ（３０、４００、６００）との通信を開始する要求側ＵＥ（３０、４００、６００）によってブロードキャストされたＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの１つまたは複数の複製を受信することであって、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔが、前記要求側ＵＥ（３０、４００、６００）と前記リモートＵＥ（３０、４００、６００）との間の通信経路に中継が許可されるかどうかを示し、かつ、前記通信経路についての最大ホップ数をさらに示す中継インジケーションを含む、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの複製を受信することと、
前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの１つまたは複数の複製のそれぞれに応答して、前記要求側ＵＥ（３０、４００、６００）に、応答メッセージを、前記Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔが受信された前記通信経路に沿って送信することと
を行うように構成される、ユーザ機器（ＵＥ）（３０、４００、６００）。

【請求項21】

請求項１７から１９のいずれか一項に記載の方法を実行するようにさらに構成される、請求項２０に記載のＵＥ（３０、４００、６００）。

【請求項22】

無線通信ネットワーク内のユーザ機器（ＵＥ）（３０、４００、６００）中の処理回路によって実行されると、リモートＵＥとしての前記ＵＥ（３０、４００、６００）に請求項１７から１９のいずれか一項に記載の方法を実行させる実行可能命令を含む、コンピュータプログラム（６７０）。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、一般的に無線通信ネットワーク内でのＤ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信に関し、より詳細にはＤ２Ｄ通信用の経路選択に関する。

【背景技術】

【0002】

Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）規格のＲｅｌｅａｓｅ１２（Ｒｅｌ－１２）において、第３世代パートナーシップ（３ＧＰＰ）プロジェクトで導入されたサイドリンク（ＳＬ）インターフェースによって、ユーザ機器（ＵＥ）は、ネットワーク（ＮＷ）にパケットを送信することなく、ピアＵＥと直接通信することができる。ＵＥ－ｔｏ－nｅｔｗｏｒｋ中継ソリューションはまた、セルカバレッジ外のリモートＵＥでも中継ＵＥを介してネットワークに到達することができるように規定される。リモートＵＥは、ＳＬインターフェースを用いて中継ＵＥと通信し、中継ＵＥは、セルとのアップリンク接続とダウンリンク接続を有する。

【0003】

サイドリンクインターフェースの最初の仕様は、主に公共の使用事例を対象としていた。それ以降、Ｄ２Ｄ技術の恩恵を受けることが可能な使用事例を拡大する目的で、多くの拡張が導入されてきた。特に、ＬＴＥ Ｒｅｌｅａｓｅ１４（Ｒｅｌ－１４）およびＲｅｌｅａｓｅ１５（Ｒｅｌ－１５）では、Ｄ２Ｄフレームワークの拡張は、車両、歩行者およびインフラストラクチャの間の直接通信のあらゆる組合せを含むＶ２Ｘ（Ｖｅｈｉｃｌｅ－ｔｏ－Ｅｖｅｒｙｔｈｉｎｇ）通信のサポートに焦点を当てたものであった。

【0004】

ＬＴＥ Ｖ２Ｘは主に交通安全サービスを目的としているが、新無線（Ｎｅｗ Ｒａｄｉｏ）規格におけるＶ２Ｘの実装は、基本的な安全サービスだけでなく、周囲環境の知覚の強化を目的とした車両間でのセンサ／データ共有など、非安全用途を含むより広い範囲にわたる。結果的に、車両の隊列走行、車両同士の協力的な操縦、およびリモート／自律運転などの新しい用途のセットは、強化されたサイドリンクフレームワークの恩恵を享受することができる。

【0005】

現在、ＮＲ規格は、２つのＰｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅ（ＰｒｏＳｅ）ディスカバリ方法をサポートしており、ＵＥが、ディスカバリ側のＵＥの近傍にある近隣ＵＥ３０をディスカバリすることを可能にしている。Ｍｏｄｅｌ Ａと称される１つ目のモデルでは、Ａｎｎｏｕｎｃｉｎｇ（アナウンス側）ＵＥはディスカバリメッセージを、ディスカバリする許可を有するＭｏｎｉｔｏｒｉｎｇ（モニタリング側）ＵＥ３０その近傍に向けて、規定のディスカバリインターバルでブロードキャストする。ディスカバリメッセージは、Ｍｏｎｉｔｏｒｉｎｇ ＵＥ３０が関心を持つ可能性のある情報を含む。ディスカバリメッセージが、Ｍｏｎｉｔｏｒｉｎｇ ＵＥが関心を持つ情報を含む場合、Ｍｏｎｉｔｏｒｉｎｇ ＵＥは応答することが可能である。オープン型および制限型の両方のディスカバリタイプが、Ｍｏｄｅｌ Ａのディスカバリ方法によってサポートされる。Ｍｏｄｅｌ Ｂと称される２つ目のモデルでは、Ｄｉｓｃｏｖｅｒｅｒ（ディスカバリする側）ＵＥは、その具体的な関心についての情報を含む要求を送信する。要求を受信するＤｉｓｃｏｖｅｒｅｅ（ディスカバリされる側）ＵＥは、Ｄｉｓｃｏｖｅｒｅｒ ＵＥの関心に関する何らかの情報で応答することができる。例えば、Ｄｉｓｃｏｖｅｒｅｒ ＵＥは、その要求内に、あるグループに対応するＰｒｏＳｅ Ａｐｐｌｉｃａｔｉｏｎ Ｉｄｅｎｔｉｔｙについての情報を含むことが可能であり、グループのメンバーは応答することができる。Ｐｕｂｌｉｃ Ｓａｆｅｔｙに使用されるＭｏｄｅｌ Ｂディスカバリ方法は、制限される。Ｍｏｎｉｔｏｒｉｎｇ ＵＥ／Ｄｉｓｃｏｖｅｒｅｒ ＵＥは、適当なサービスのディスカバリを実施する権限（予めプロビジョニングされたパラメータなどを通じて）を有している必要がある。

【0006】

２つのＵＥ３０間でのＤ２Ｄ通信は、ネットワークカバレッジの外側にあるＵＥからのメッセージを中継するために使用することが可能である。Ｍｏｄｅｌ ＡまたはＭｏｄｅｌ Ｂのディスカバリ方法は、その近傍にありＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ中継としてサーブするＵＥをディスカバリするために、Ａｎｎｏｕｎｃｉｎｇ（アナウンス側）／Ｄｉｓｃｏｖｅｒｅｒ ＵＥによって使用することが可能である。ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ中継として機能するＵＥは、（既に接続されているのでなければ）ネットワークに取り付けられ、Ｐａｃｋｅｔ Ｄａｔａネットワーク（ＰＤＮ）接続に接続することができ、必要な中継トラフィックを可能にしている。

【0007】

ＵＥ－ｔｏ－ＵＥ中継をサポートするためのいくつかの提案が成されているが、既存のソリューションには、１つまたは複数の欠点が存在する。具体的に、既存のソリューションは、中継ディスカバリに望ましくない遅延をもたらし、限られた能力しか提供しない、またはＵＥが前もって中継へのユニキャストリンクを確立することを必要とする（これはさらなる遅延をもたらしリソースを無駄にし得る）可能性がある。追加的に、既存のソリューションは、リモートＵＥによる中継選択をサポートしない。この制限は、リモートＵＥの能力が中継選択において考慮されないため、問題を生じる場合がある。

【0008】

したがって、先行技術ソリューションの欠点を克服するためのソリューションの必要性が残っている。

【発明の概要】

【0009】

本開示は、要求側ＵＥとリモートＵＥとの間のユニキャストＤ２Ｄ通信リンクを、中継ＵＥを介して確立するための方法と装置を提供する。

【0010】

本開示の第１の態様によると、中継ディスカバリを伴わない、リモートＵＥとのユニキャストリンク確立のための手順が提供される。要求側ＵＥは、リモートＵＥと通信する必要がある場合、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ（直接通信要求）を要求側ＵＥの付近にあるすべてのＵＥ３０にブロードキャストする。Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔには、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうか、また任意選択で複数のホップが許可されるかどうかを示す中継インジケーションが含まれる。Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを受信する近隣ＵＥ３０は、要求に直接応答するか、要求を再ブロードキャストするかのいずれかが可能である。故に、リモートＵＥは、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの複数の複製を受信する可能性がある。リモートＵＥは、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔのまたはより多くのインスタンスに応答することが可能である。要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信用の通信経路の選択は、リモートＵＥもしくは要求側ＵＥ、またはリモートＵＥと要求側ＵＥとの組合せによって実施することが可能である。

【0011】

本開示の第２の態様によると、中継ディスカバリを伴う、リモートＵＥとのユニキャストリンク確立のための手順が提供される。各中継ＵＥは、中継ＵＥが到達可能な近隣ＵＥ３０のリストを維持し、定期的にアナウンスメントをブロードキャストして、通信を中継するための利用可能性を示す。アナウンスメントには、アナウンス側ＵＥが到達可能な他のＵＥ３０のインジケーション（例えば、到達可能近隣リスト）が含まれる。中継ＵＥの到達範囲内のＵＥがブロードキャストアナウンスメントを受信すると、ＵＥは、中継ＵＥを使用してＤ２Ｄ通信を中継したいかどうかを決定することができる。中継ＵＥを使用してＤ２Ｄ通信を中継したい場合、受信側ＵＥは、中継用の到達可能近隣リストの複製を自身のローカルメモリに記憶し、中継要求を中継ＵＥに送信する。中継要求を受信すると、中継ＵＥは、要求側ＵＥをその到達可能な近隣に追加して、更新されたリストを次のブロードキャストディスカバリメッセージ内で送信する。要求側ＵＥがリモートＵＥと通信したい場合、要求側ＵＥは、メモリに記憶された到達可能近隣リストのローカル複製に基づいて、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを送信する前に、リモートＵＥに到達することができる中継を選ぶことができる。

【0012】

本開示の第３の態様は、Ｄ２Ｄ通信用のＵＥによって実装される方法を含む。一実施形態では、方法は、リモートＵＥとの通信を開始する要求を１つまたは複数の近隣ＵＥにブロードキャストすることを含む。要求には、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。方法は、要求に応答して、近隣ＵＥのうちの１つまたは複数から応答メッセージを受信することと、１つまたは複数の応答メッセージに基づいて、要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信用の通信経路を判定することとをさらに含む。

【0013】

本開示の第４の態様は、Ｄ２Ｄ通信用に設定されたＵＥを含む。一実施形態では、ＵＥは、リモートＵＥとの通信を開始する要求を１つまたは複数の近隣ＵＥにブロードキャストするように構成される。要求には、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。ＵＥは、要求に応答して、近隣ＵＥのうちの１つまたは複数から応答メッセージを受信することと、１つまたは複数の応答メッセージに基づいて、要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信用の通信経路を判定することとを行うようにさらに構成される。

【0014】

本開示の第５の態様は、無線通信ネットワーク内のＵＥ中の処理回路によって実行されると、ＵＥに第３の態様による方法を実行させる実行可能命令を含む、コンピュータプログラムを含む。

【0015】

本開示の第６の態様は、第５の態様によるコンピュータプログラムを含むことを含み、キャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである。

【0016】

本開示の第７の態様は、Ｄ２Ｄ通信を中継するＵＥによって実装される方法を含む。一実施形態では、方法は、リモートＵＥとの通信を開始する要求側ＵＥによってブロードキャストされた要求を受信することを含む。要求には、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。方法は、要求をリモートＵＥに向けて転送することをさらに含む。

【0017】

本開示の第８の態様は、Ｄ２Ｄ通信を中継するように構成されたＵＥを含む。一実施形態では、ＵＥは、リモートＵＥとの通信を開始する要求側ＵＥによってブロードキャストされた要求を受信するように構成される。要求には、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。ＵＥは、要求をリモートＵＥに向けて転送するようにさらに構成される。

【0018】

本開示の第９の態様は、無線通信ネットワーク内のＵＥ中の処理回路によって実行されると、ＵＥに第７の態様による方法を実行させる実行可能命令を含む、コンピュータプログラムを含む。

【0019】

本開示の第１０の態様は、第９の態様によるコンピュータプログラムを含むことを含み、キャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである。

【0020】

本開示の第１１の態様は、Ｄ２Ｄ通信用に設定されたリモートＵＥによって実装される方法を含む。一実施形態では、方法は、リモートＵＥとの通信を開始する要求側ＵＥによってブロードキャストされた要求の１つまたは複数の複製を受信することを含む。要求には、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。方法は、要求の１つまたは複数の複製のそれぞれに応答して、要求側ＵＥに、応答メッセージを、要求が受信された通信経路に沿って送信することをさらに含む。

【0021】

本開示の第１２の態様は、Ｄ２Ｄ通信用に設定されたリモートＵＥを含む。一実施形態では、ＵＥは、リモートＵＥとの通信を開始する要求側ＵＥによってブロードキャストされた要求の１つまたは複数の複製を受信するように構成される。要求には、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。ＵＥは、要求の１つまたは複数の複製のそれぞれに応答して、要求側ＵＥに、応答メッセージを、要求が受信された通信経路に沿って送信するようにさらに構成される。

【0022】

本開示の第１３の態様は、無線通信ネットワーク内のＵＥ中の処理回路によって実行されると、ＵＥに第１１の態様による方法を実行させる実行可能命令を含む、コンピュータプログラムを含む。

【0023】

本開示の第１４の態様は、第１３の態様によるコンピュータプログラムを含むことを含み、キャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである。

【0024】

本開示の第１５の態様は、Ｄ２Ｄ通信用のＵＥによって実装される方法を含む。一実施形態では、方法は、１つまたは複数の中継ＵＥによってブロードキャストされたアナウンスメントを受信することであって、各アナウンスメントは、中継ＵＥから到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む、アナウンスメントを受信することを含む。方法は、要求を、自身の近隣リストにリモートＵＥを有する中継ＵＥのうち選択された中継ＵＥに送信することであって、要求は、ターゲットとなるリモートＵＥを識別するための識別情報を含む、要求を送信することをさらに含む。方法は、要求に応答して、応答メッセージを中継ＵＥによって中継されるリモートＵＥから受信することをさらに含む。

【0025】

本開示の第１６の態様は、Ｄ２Ｄ通信用に設定されたＵＥを含む。一実施形態では、ＵＥは、１つまたは複数の中継ＵＥによってブロードキャストされたアナウンスメントを受信することであって、各アナウンスメントは、中継ＵＥから到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む、アナウンスメントを受信することを行うように構成される。ＵＥは、要求を、自身の近隣リストにリモートＵＥを有する中継ＵＥのうち選択された中継ＵＥに送信することであって、要求は、ターゲットとなるリモートＵＥを識別するための識別情報を含む、要求を送信することを行うようにさらに構成される。ＵＥは、要求に応答して、応答メッセージを中継ＵＥによって中継されるリモートＵＥから受信するようにさらに構成される。

【0026】

本開示の第１７の態様は、無線通信ネットワーク内のＵＥ中の処理回路によって実行されると、ＵＥに第１５の態様による方法を実行させる実行可能命令を含む、コンピュータプログラムを含む。

【0027】

本開示の第１８の態様は、第１７の態様によるコンピュータプログラムを含むことを含み、キャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである。

【0028】

本開示の第１９の態様は、Ｄ２Ｄ通信を中継するように構成されたＵＥによって実装される方法を含む。一実施形態では、方法はアナウンスメントを１つまたは複数の近隣ＵＥにブロードキャストすることを含む。アナウンスメントは、ＵＥから到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む。方法は、近隣リストにあるターゲットとなるリモートＵＥとのＤ２Ｄ通信を開始する要求側ＵＥから要求を受信することをさらに含む。要求は、ターゲットとなるリモートＵＥを識別するための識別情報を含む。方法は、要求を、要求によって識別されるリモートＵＥに転送することさらに含む。

【0029】

本開示の第２０の態様は、Ｄ２Ｄ通信を中継するように構成されたＵＥを含む。一実施形態では、ＵＥは、アナウンスメントを１つまたは複数の近隣ＵＥにブロードキャストするように構成される。アナウンスメントは、ＵＥから到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む。ＵＥは、近隣リストにあるターゲットとなるリモートＵＥとのＤ２Ｄ通信を開始する要求側ＵＥから要求を受信するようにさらに構成される。要求は、ターゲットとなるリモートＵＥを識別するための識別情報を含む。ＵＥは、要求を、要求によって識別されるリモートＵＥに転送するようにさらに構成される。

【0030】

本開示の第２１の態様は、無線通信ネットワーク内のＵＥ中の処理回路によって実行されると、ＵＥに第１９の態様による方法を実行させる実行可能命令を含む、コンピュータプログラムを含む。

【0031】

本開示の第２２の態様は、第２１の態様によるコンピュータプログラムを含むことを含み、キャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである。

【0032】

本開示の第２３の態様は、Ｄ２Ｄ通信用に設定されたＵＥによって実装される方法を含む。一実施形態において、方法は、中継ＵＥによってブロードキャストされたアナウンスメントを受信することと、アナウンスメントに応答して、中継ＵＥにＤ２Ｄ通信用の中継としてサーブするよう要求する中継要求を、中継ＵＥに送信することとを含む。

【0033】

本開示の第２４の態様は、Ｄ２Ｄ通信用に設定されたＵＥを含む。一実施形態において、ＵＥは、中継ＵＥによってブロードキャストされたアナウンスメントを受信することと、アナウンスメントに応答して、中継ＵＥにＤ２Ｄ通信用の中継としてサーブするよう要求する中継要求を、中継ＵＥに送信することとを行うように構成される。

【0034】

本開示の第２５の態様は、無線通信ネットワーク内のＵＥ中の処理回路によって実行されると、ＵＥに第２３の態様による方法を実行させる実行可能命令を含む、コンピュータプログラムを含む。

【0035】

本開示の第２６の態様は、第２５の態様によるコンピュータプログラムを含むことを含み、キャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである。

【図面の簡単な説明】

【0036】

【図1】本明細書で説明されるようなＵＥ－ｔｏ－ＵＥ中継をサポートする無線通信ネットワークの図である。

【図2】Ｄ２Ｄ通信用の２つのＵＥ３０間のＮＲユニキャストリンクの図である。

【図3】Ｍｏｄｅｌ Ａ ＰｒｏＳｅディスカバリ手順の図である。

【図4】Ｍｏｄｅｌ Ｂ ＰｒｏＳｅディスカバリ手順の図である。

【図5】ＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ中継用の手順の図である。

【図6A】Ｍｏｄｅｌ Ａを用いる緊急通報直接ディスカバリの図である。

【図6B】Ｍｏｄｅｌ Ｂを用いる緊急通報直接ディスカバリの図である。

【図7】Ｄ２Ｄ通信用のＬａｙｅｒ－２リンク確立手順の図である。

【図8A】中継ディスカバリを伴わない、リモートＵＥとのユニキャストリンク確立のための手順の図である。

【図8B】中継ディスカバリを伴わない、リモートＵＥとのユニキャストリンク確立のための別の手順の図である。

【図8C】中継ディスカバリを伴わない、リモートＵＥとのユニキャストリンク確立のための別の手順の図である。

【図9】中継ディスカバリを伴う、リモートＵＥとのユニキャストリンク確立のための手順の図である。

【図10】要求側ＵＥによって実装されるＤ２Ｄ通信の方法の図である。

【図11】要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信をサポートする中継ＵＥによって実装される方法の図である。

【図12】要求側ＵＥによって実装されるＤ２Ｄ通信の方法の図である。

【図13】要求側ＵＥによって実装されるＤ２Ｄ通信の方法の図である。

【図14】要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信をサポートする中継ＵＥによって実装される方法の図である。

【図15】リモートＵＥによって実装されるＤ２Ｄ通信の方法の図である。

【図16A】Ｄ２Ｄ通信用に設定された要求側ＵＥの図である。

【図16B】要求側ＵＥと応答側ＵＥとの間のＤ２Ｄ通信をサポートする中継ＵＥの図である。

【図16C】Ｄ２Ｄ通信用に設定されたリモートＵＥの図である。

【図17A】Ｄ２Ｄ通信用に設定された要求側ＵＥの図である。

【図17B】要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信をサポートする中継ＵＥの図である。

【図17C】中継ＵＥを介するＤ２Ｄ通信用に設定されたリモートＵＥの図である。

【図18】中継を使用するＤ２Ｄ通信用に設定されたＵＥの図である。

【発明を実施するための形態】

【0037】

次に図面を参照して、本開示によるＵＥ－ｔｏ－ＵＥ中継技法を、ＮＲ通信規格を実装する無線通信ネットワークのコンテキストで説明する。しかしながら、当業者であれば、技法はより一般的に、サイドリンクインターフェース上でＤ２Ｄ通信をサポートするあらゆる無線通信ネットワークに適用可能であることを理解されよう。

【0038】

図１は、複数のＵＥ３０にコアネットワーク４０への接続を提供する基地局２０を示す。図１には単一の基地局２０が示されるが、当業者であれば無線通信ネットワーク１０は通常多くの基地局２０を含むことを理解されよう。基地局２０はまた、ＮＲ規格ではエボルブドノードＢ（ｅＮＢ）、５ＧノードＢ（ｇＮＢ）または次世代ｅＮＢ（ｎｇ－ｅＮＢ）と称される場合もある。

【0039】

図１は、４つのＵＥ３０を示しており、それぞれＵＥ－１～ＵＥ－４と表される。ＵＥ－１～ＵＥ－３は基地局２０のカバレッジエリア内にあり、ネットワーク１０とパケットデータネットワーク（ＰＤＮ）接続を確立することが可能である。ＵＥ－４は、基地局２０のカバレッジエリアの外側にある。

【0040】

ＵＥ－１～ＵＥ－４は、サイドリンク（例えば、ＰＣ５インターフェース）上でその近傍の他のＵＥ３０とＤ２Ｄ通信が可能である。ＵＥ－１は、ＵＥ－３とＵＥ－４の近傍にあり、サイドリンクＳＬ１３上とＳＬ１４上でそれぞれＵＥ－３とＵＥ－４と通信することが可能である。ＵＥ－２は、ＵＥ－３の近傍にあり、サイドリンクＳＬ２３上でＵＥ－３と通信することが可能である。ＵＥ－３は、ＵＥ－１、ＵＥ－２、およびＵＥ－４の近傍にあり、それぞれサイドリンクＳＬ１３上、ＳＬ２３上、およびＳＬ３４上でこれらと通信することが可能である。最後に、ＵＥ－４は、ＵＥ－１とＵＥ－３の近傍にあり、サイドリンクＳＬ１４上とＳＬ３４上でそれぞれＵＥ－１とＵＥ－３と通信することが可能である。しかしながら、ＵＥ１およびＵＥ－４は、ＵＥ－２の外側にあり、サイドリンク上でＵＥ－２と直接通信を確立することはできない。ＵＥ１は、基地局２０を介してＵＥ－２と通信することが可能である。しかしながら、ＵＥ－４は、基地局２０のカバレッジの外側にある。

【0041】

本開示の一態様は、Ｄ２Ｄ通信用のＵＥ－ｔｏ－ＵＥ中継を可能にするための方法を含む。図１で示される例では、Ｄ２Ｄ通信技法により、ＵＥ－３は、ＵＥ－２とＵＥ－４との間、またはＵＥ－２とＵＥ－１との間でＤ２Ｄ通信用の中継としてサーブすることができる。

【0042】

ＮＲサイドリンクでは、高信頼度が要求されるサービス向けに、アクセス層でのユニキャストがサポートされる。同一のＵＥペア間には、複数のサイドリンクユニキャストが存在してもよく、図２で示されるように、各ユニキャストリンクは複数のサイドリンクＱｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ（通信品質、ＱｏＳ）フロー／無線ベアラをサポートすることが可能である（３ＧＰＰ ＴＳ２３．２８７）。アクセス層では、各リンクはソースおよびデスティネーションＬａｙｅｒ２識別情報（Ｌ２ ＩＤ）によって識別することが可能である。例えば、図２のＰＣ５ユニキャストリンク１は、Ｌ２ ＩＤ１（つまりアプリケーションＩＤ１に対応する）とＬ２ ＩＤ２（つまりアプリケーションＩＤ２に対応する）のペアによって識別することが可能である。

【0043】

ＵＥ３０同士のＤ２Ｄ通信を可能にするためには、ＵＥ３０が互いにディスカバリできるようにするためのディスカバリ方法が必要とされる。３ＧＰＰ規格ＴＳ２３．３０３、§５．３．１．２では、２つのＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ方法、すなわちＭｏｄｅｌ Ａディスカバリ方法（図３）およびＭｏｄｅｌ Ｂディスカバリ方法（図４）が規定されている。

【0044】

Ｍｏｄｅｌ Ａは、ＰｒｏＳｅ Ｄｉｒｅｃｔ Ｄｉｓｃｏｖｅｒｙに参加しているＰｒｏＳｅ対応ＵＥ３０に２つの役割を規定する。
・Ａｎｎｏｕｎｃｉｎｇ ＵＥ：ディスカバリする許可を有する近傍にあるＵＥ３０によって使用され得る、特定の情報をアナウンスするＵＥ３０。
・Ｍｏｎｉｔｏｒｉｎｇ ＵＥ：アナウンス側ＵＥ３０の近傍にある対象となる特定の情報をモニタリングするＵＥ３０。

【0045】

このモデルでは、Ａｎｎｏｕｎｃｉｎｇ ＵＥ３０は、ディスカバリメッセージを、規定のディスカバリインターバルでブロードキャストし、これらのメッセージに関心のあるＭｏｎｉｔｏｒｉｎｇ ＵＥ３０は、このメッセージを読んで処理する。Ａｎｎｏｕｎｃｉｎｇ ＵＥ３０は、自分自身についての情報、例えばディスカバリメッセージにおける自身のＰｒｏＳｅ Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｄｅをブロードキャストするため、このモデルは、「私はここにいます（Ｉ ａｍ ｈｅｒｅ）」と等価である。オープン型および制限型の両方のディスカバリタイプが、Ｍｏｄｅｌ Ａによってサポートされる。

【0046】

図４には、Ｍｏｄｅｌ Ｂディスカバリ方法が示されている。制限型のディスカバリタイプが使用される場合、このモデルは、ＰｒｏＳｅ Ｄｉｒｅｃｔ Ｄｉｓｃｏｖｅｒｙに参加しているＰｒｏＳｅ対応ＵＥ３０に２つの役割を規定する。
・Ｄｉｓｃｏｖｅｒｅｒ（ディスカバリする側）ＵＥ：ディスカバリする関心事についての特定の情報を含む要求を送信するＵＥ３。
・Ｄｉｓｃｏｖｅｒｅｅ（ディスカバリされる側）ＵＥ：要求メッセージを受信し、ディスカバリする側の要求に関連する何らかの情報で応答することが可能なＵＥ３０。

【0047】

このモデルでは、ＤｉｓｃｏｖｅｒｅｒＵＥ３０による要求には、自身が通信したい他のＵＥ３０についての情報が含まれる。ＤｉｓｃｏｖｅｒｅｒＵＥ３０は、ＤｉｓｃｏｖｅｒｅｒＵＥ３０が応答を受信したい他のＵＥ３０についての情報を送信するので、これは「そこにいるのは誰／あなたはそこにいるのか（ｗｈｏ ｉｓ ｔｈｅｒｅ／ａｒｅ ｙｏｕ ｔｈｅｒｅ）」と等価である。例えば、情報は、グループに対応するＰｒｏＳｅ Ａｐｐｌｉｃａｔｉｏｎ Ｉｄｅｎｔｉｔｙにであってもよく、グループのメンバーが応答することが可能である。Ｐｕｂｌｉｃ Ｓａｆｅｔｙディスカバリは、制限的であると考えられる。Ｍｏｎｉｔｏｒｉｎｇ ＵＥ３０／Ｄｉｓｃｏｖｅｒｅｒ ＵＥ３０は、適当なサービスのディスカバリを実施する権限（予めプロビジョニングされたパラメータなどを通じて）を有している必要がある。

【0048】

現在の規格は、ＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙ（ＴＳ２３．３０３、§５．４．４）を介した直接通信に対するサポートを提供する。この手順では、ＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙ対応のＵＥ３０は、（既に接続されているのでなければ）ネットワークに取り付けられ、ＰＤＮ接続に接続することができ、必要な中継トラフィックを可能にしている。図５は、ＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙ用の手順のコールフローを示す。この手順では、リモートＵＥ３０は、ＭｏｄｅｌＡ（図６Ａ）またはＭｏｄｅｌＢ（図６Ｂ）ディスカバリを使用して、ＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙのディスカバリを実行する。この手順の詳細は、ＴＳ２３．３０３、§５．３．７に記載されている。

【0049】

簡潔には、リモートＵＥ３０は、ＭｏｄｅｌＡ（図６Ａ）またはＭｏｄｅｌＢ（図６Ｂ）ディスカバリを使用して、ＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙのディスカバリを実行する。このディスカバリ手順の詳細は、ＴＳ２３．３０３、§５．３．７に記載されている。ＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙディスカバリおよび選択のための識別子は、ＴＳ２３．３０３、§４．６．４．３において規定される。ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙ Ｄｉｓｃｏｖｅｒｙ Ａｎｎｏｕｎｃｅｍｅｎｔメッセージ（ＭｏｄｅｌＡ）では、次のパラメータが使用される：
・ＰｒｏＳｅ Ｒｅｌａｙ ＵＥ ＩＤ：直接通信に使用され、Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅに関連付けられるリンク層識別子。ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙは、Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅごとに異なるＰｒｏＳｅ Ｒｅｌａｙ ＵＥ ＩＤを有していなければならない。複数のＰＤＮ Ｃｏｎｎｅｃｔｉｏｎのサポートのために、ＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙは、ＰＤＮ Ｃｏｎｎｅｃｔｉｏｎごとに異なるＰｒｏＳｅ Ｒｅｌａｙ ＵＥ ＩＤが割り当てられる。
・アナウンサ情報：アナウンス側ユーザについての情報を提供する。
・Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅ：ＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ ＲｅｌａｙがＰｕｂｌｉｃ Ｓａｆｅｔｙアプリケーションに提供する、接続サービスを識別するパラメータ。Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅは、アドバタイズメント用のＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙにおいて設定される。追加的に、Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅはまた、ＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙがサービスを提供する認可されたユーザを識別し、例えばＲｅｍｏｔｅＵＥ３０とＰｒｏＳｅ ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙとの間での認証と認可に必要な、関連セキュリティポリシまたは情報を選択することができる（例えば、警察関係者専用の中継用Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅは、例えばＩｎｔｅｒｎｅｔ Ａｃｃｅｓｓをサポートするために、潜在的に同一のＡＰＮに接続を提供していても、消防隊員専用の中継用Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅとは異なっている）。

【0050】

ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙ Ｄｉｓｃｏｖｅｒｙ Ｓｏｌｉｃｉｔａｔｉｏｎメッセージ（Ｍｏｄｅｌ Ｂ）では、次のパラメータが使用される：
・Ｄｉｓｃｏｖｅｒｅｒ Ｉｎｆｏ：ディスカバリする側のユーザについての情報を提供する。
・Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅ：Ｄｉｓｃｏｖｅｒｅｒ ＵＥ３０が関心のある接続についての情報。Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅは、関連接続サービスに関心のあるＲｅｍｏｔｅ ＵＥ３０において設定される。
・ＰｒｏＳｅ Ｒｅｌａｙ ＵＥ ＩＤ：直接通信に使用され、Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅに関連付けられるＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙのリンク層識別子。ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙは、Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅごとに異なるＰｒｏＳｅ Ｒｅｌａｙ ＵＥ ＩＤを有していなければならない。ＰｒｏＳｅ Ｒｅｌａｙ ＵＥ ＩＤは任意選択である。

【0051】

ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージ（ＭｏｄｅｌＢ）では、次のパラメータが使用される：
・ＰｒｏＳｅ Ｒｅｌａｙ ＵＥ ＩＤ：直接通信に使用され、Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅに関連付けられるリンク層識別子。ＵＥ－ｔｏ－Ｎｅｔｗｏｒｋ Ｒｅｌａｙは、Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅごとに異なるＰｒｏＳｅ Ｒｅｌａｙ ＵＥ ＩＤを有していなければならない。

【0052】

図７は、ＰＣ５参照点上のＶ２Ｘ通信のユニキャストモードのためのＬａｙｅｒ－２（Ｌ２）リンク確立手順を示す。
１．ＵＥ３０は、ＰＣ５ユニキャストリンク確立の受信をシグナリングするためのデスティネーションＬａｙｅｒ－２ＩＤを、ＴＳ２３．２８７、§５．６．１．４で指定される通りに判定する。デスティネーションＬａｙｅｒ－２ＩＤは、ＴＳ２３．２８７、§５．１．２．１で指定される通りにＵＥ３０で設定される。
２．ＵＥ－１中のＶ２Ｘアプリケーション層は、ＰＣ５ユニキャスト通信用のアプリケーション情報を提供する。アプリケーション情報には、Ｖ２Ｘアプリケーションのサービスタイプ（例えば、ＰＳＩＤまたはＩＴＳ－ＡＩＤ）および要求側ＵＥのＡｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ＩＤが含まれる。ターゲットＵＥのＡｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ＩＤは、アプリケーション情報に含まれてもよい。
・ＵＥ－１中のＶ２Ｘアプリケーション層は、このユニキャスト通信用のＶ２Ｘ Ａｐｐｌｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｍｅｎｔを提供してもよい。ＵＥ－１は、ＰＣ５ ＱｏＳパラメータおよびＰＦＩを、ＴＳ２３．２８７、§５．４．１．４で指定される通りに判定する。
３．ＵＥ－１は、ユニキャスト層２リンク確立手順を開始するために、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信する。Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージは、次を含む：
・Ｓｏｕｒｃｅ Ｕｓｅｒ Ｉｎｆｏ：要求側ＵＥのＡｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ＩＤ（すなわち、ＵＥ－１のＡｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ＩＤ）。
・ステップ２においてＶ２Ｘアプリケーション層がターゲットＵＥのＡｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ＩＤを提供した場合、次の情報が含まれる：
〇Ｔａｒｇｅｔ Ｕｓｅｒ Ｉｎｆｏ：ターゲットＵＥのＡｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ＩＤ（すなわち、ＵＥ－２のＡｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ＩＤ）。
・Ｖ２Ｘ Ｓｅｒｖｉｃｅ Ｉｎｆｏ：Ｌａｙｅｒ－２リンク確立を要求するＶ２Ｘ Ｓｅｒｖｉｃｅについての情報（例えば、ＰＳＩＤまたはＩＴＳ－ＡＩＤ）。
・ＩＰ通信が使用されるかどうかのインジケーション。
・ＩＰ Ａｄｄｒｅｓｓ Ｃｏｎｆｉｇｕｒａｔｉｏｎ：ＩＰ通信では、ＩＰアドレス設定はこのリンク用に必要とされ、次の値のうちの１つを示す：
〇「ＩＰｖ６ Ｒｏｕｔｅｒ」ＩＰｖ６アドレス割り当てメカニズムが要求側ＵＥ３０によってサポートされる場合、つまり、ＩＰｖ６ルータとして機能する場合；または
〇「ＩＰｖ６ ａｄｄｒｅｓｓ ａｌｌｏｃａｔｉｏｎ ｎｏｔ ｓｕｐｐｏｒｔｅｄ」ＩＰｖ６アドレス割り当てメカニズムが要求側ＵＥ３０によってサポートされない場合。
・Ｌｉｎｋ Ｌｏｃａｌ ＩＰｖ６ Ａｄｄｒｅｓｓ：ＵＥ－１がＩＰｖ６のＩＰアドレス割り当てメカニズムをサポートしていない場合、つまり、ＩＰ Ａｄｄｒｅｓｓ Ｃｏｎｆｉｇｕｒａｔｉｏｎが「ＩＰｖ６ ａｄｄｒｅｓｓ ａｌｌｏｃａｔｉｏｎ ｎｏｔ ｓｕｐｐｏｒｔｅｄ」を示す場合、ＲＦＣ４８６２に基づいてローカルに形成されるリンク－ローカルＩＰｖ６アドレス。
・ＱｏＳ Ｉｎｆｏ：ＰＣ５ ＱｏＳ Ｆｌｏｗについての情報。ＰＣ５ ＱｏＳ Ｆｌｏｗごとに、ＰＦＩおよび対応するＰＣ５ＱｏＳパラメータ（つまり、ＰＱＩおよび、条件付きでＭＦＢＲ／ＧＦＢＲなどの他のパラメータ）。
・Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信するために使用されるソースＬａｙｅｒ－２ ＩＤおよびデスティネーションＬａｙｅｒ－２ ＩＤは、条項５．６．１．１および５．６．１．４で指定される通りに判定される。
・ＵＥ－１はＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを、ソースＬａｙｅｒ－２ ＩＤおよびデスティネーションＬａｙｅｒ－２ ＩＤを使用してＰＣ５ブロードキャストを介して送信する。
４．Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｃｃｅｐｔメッセージは、次のようにＵＥ－１に送信される：
４ａ．（ＵＥ指向Ｌａｙｅｒ－２リンク確立）Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージにＴａｒｇｅｔ Ｕｓｅｒ Ｉｎｆｏが含まれる場合、ターゲットＵＥ３０、すなわちＵＥ－２はＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｃｃｅｐｔメッセージで応答する。
４ｂ．（Ｖ２Ｘ Ｓｅｒｖｉｃｅ指向Ｌａｙｅｒ－２リンク確立）Ｔａｒｇｅｔ Ｕｓｅｒ ＩｎｆｏがＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含まれていない場合、アナウンスされるＶ２ＸＳｅｒｖｉｃｅを使用することに関心があり、そのためＵＥ－１とＬａｙｅｒ－２リンクを確立するよう決定するＵＥ３０は、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｃｃｅｐｔメッセージを送信することによって要求に応答する（図６．３．３．１－１におけるＵＥ－２とＵＥ－４）。

【0053】

Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｃｃｅｐｔメッセージは、次を含む：
・Ｓｏｕｒｃｅ Ｕｓｅｒ Ｉｎｆｏ：Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｃｃｅｐｔメッセージを送信するＵＥ３０のＡｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ＩＤ。
・ＱｏＳ Ｉｎｆｏ：ＰＣ５ ＱｏＳ Ｆｌｏｗについての情報。ＰＣ５ ＱｏＳ Ｆｌｏｗごとに、ＵＥ－１によって要求されるＰＦＩおよび対応するＰＣ５ ＱｏＳパラメータ（つまり、ＰＱＩおよび、条件付きでＭＦＢＲ／ＧＦＢＲなどの他のパラメータ）。
・ＩＰ Ａｄｄｒｅｓｓ Ｃｏｎｆｉｇｕｒａｔｉｏｎ：ＩＰ通信では、ＩＰアドレス設定はこのリンク用に必要とされ、次の値のうちの１つを示す：
〇「ＩＰｖ６ Ｒｏｕｔｅｒ」ＩＰｖ６アドレス割り当てメカニズムがターゲットＵＥ３０によってサポートされる場合、つまり、ＩＰｖ６ルータとして機能する場合；または
〇「ＩＰｖ６ ａｄｄｒｅｓｓ ａｌｌｏｃａｔｉｏｎ ｎｏｔ ｓｕｐｐｏｒｔｅｄ」ＩＰｖ６アドレス割り当てメカニズムがターゲットＵＥ３０によってサポートされない場合。
・Ｌｉｎｋ Ｌｏｃａｌ ＩＰｖ６ Ａｄｄｒｅｓｓ：ターゲットＵＥ３０がＩＰｖ６のＩＰアドレス割り当てメカニズムをサポートしていない場合、つまり、ＩＰ Ａｄｄｒｅｓｓ Ｃｏｎｆｉｇｕｒａｔｉｏｎが「ＩＰｖ６ ａｄｄｒｅｓｓ ａｌｌｏｃａｔｉｏｎ ｎｏｔ ｓｕｐｐｏｒｔｅｄ」を示し、ＵＥ－１がＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージ中にリンク－ローカルＩＰｖ６アドレスを含んでいた場合、ＲＦＣ４８６２に基づいてローカルに形成されるリンク－ローカルＩＰｖ６アドレス。ターゲットＵＥ３０は、競合しないリンク－ローカルＩＰｖ６アドレスを含まなければならない。
・ＵＥ３０（すなわち要求側ＵＥ３０およびターゲットＵＥ３０の両方が、リンクローカルＩＰｖ６アドレスを使用するよう選択した場合、これらＵＥはＲＦＣ４８６２で規定される重複アドレス検出を無効にする。
注釈１：要求側ＵＥ３０またはターゲットＵＥ３０のいずれかがＩＰｖ６ルータのサポートを示す場合、対応するアドレス設定手順がＬａｙｅｒ－２リンクの確立後に行われ、リンクローカルＩＰｖ６アドレスは無視される。
・Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｃｃｅｐｔメッセージを送信するために使用されるソースＬａｙｅｒ－２ ＩＤは、条項５．６．１．１および５．６．１．４で指定される通りに判定される。デスティネーションＬａｙｅｒ－２ ＩＤは、受信したＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージのソースＬａｙｅｒ－２ ＩＤにセットされる。
・ピアＵＥ３０からＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｃｃｅｐｔメッセージを受信すると、ＵＥ－１は、将来的な通信用に、このユニキャストリンクのためのシグナリングとデータトラフィックのために、ピアＵＥのＬａｙｅｒ－２ＩＤを取得する。
・ＰＣ５ユニキャストリンクを確立したＵＥ３０のＶ２Ｘ層は、ユニキャストリンクに割り当てられたＰＣ５ Ｌｉｎｋ ＩｄｅｎｔｉｆｉｅｒおよびＰＣ５ユニキャストリンク関連情報を、ＡＳ層に渡す。ＰＣ５ユニキャストリンク関連情報には、Ｌａｙｅｒ－２ ＩＤ情報が含まれる（すなわち、ソースＬａｙｅｒ－２ ＩＤおよびデスティネーションＬａｙｅｒ－２ ＩＤ）。これにより、ＡＳ層が、ＰＣ５ Ｌｉｎｋ ＩｄｅｎｔｉｆｉｅｒをＰＣ５ユニキャストリンク関連情報とともに維持することができる。
５．Ｖ２Ｘサービスデータは、確立されたユニキャストリンク上を、次のように送信される：
・ＰＣ５ Ｌｉｎｋ ＩｄｅｎｔｉｆｉｅｒおよびＰＦＩが、Ｖ２ＸサービスデータとともにＡＳ層に提供される。
・ＵＥ－１は、ソースＬａｙｅｒ－２ ＩＤ（すなわち、このユニキャストリンクについてのＵＥ－１のＬａｙｅｒ－２ ＩＤ）およびデスティネーションＬａｙｅｒ－２ ＩＤ（すなわち、このユニキャストリンクについてのピアＵＥのＬａｙｅｒ－２ ＩＤ）を使用してＶ２Ｘサービスデータを送信する。
注釈２：ＰＣ５ユニキャストリンクは双方向性であるため、ＵＥ－１のピアＵＥ３０は、Ｖ２Ｘサービスデータを、ＵＥ－１とのユニキャストリンク上でＵＥ－１に送信することが可能である。

【0054】

本開示の一態様は、ＵＥ－ｔｏ－ＵＥ中継のためのサポートを提供することである。ＵＥ－ｔｏ－ＵＥ中継をサポートするためのいくつかの提案がなされているが、既存のソリューションには、１つまたは複数の欠点が存在する。具体的に、既存のソリューションは、中継ディスカバリに望ましくない遅延をもたらし、限られた能力しか提供しない、またはＵＥ３０が前もって中継へのユニキャストリンクを確立することを必要とする（これはさらなる遅延をもたらしリソースを無駄にし得る）可能性がある。追加的に、既存のソリューションは、リモートＵＥ３０による中継選択のサポートを提供しない。この制限は、リモートＵＥ３０の能力が中継選択において考慮されないため、問題を生じる場合がある。

【0055】

本明細書で説明されるソリューションは、ＴＳ２３．３０３とＴＳ２３．２８７で規定されるサービスディスカバリおよびユニキャストリンク確立方法を、いくつかの変更を用いて再使用するため、相当する製品への影響は小さい。方法は、要求側ＵＥ３０および本明細書ではターゲットＵＥ３０とも称されるリモートＵＥ３０の両方によって、中継選択をサポートしており、中継選択用にリモートＵＥ３０のステータスを考慮することができる。また、中継選択を行うために、中継からの要求および応答の収集のための新しいタイマが導入される。本明細書で説明される方法はまた、より複雑な中継選択手法の実装をサポートするために、潜在的な中継によって、より多くの情報を交換できるようにする。例えば、本明細書で説明される方法は、負荷分散および他の中継選択ポリシをサポートすることが可能である。

【0056】

本明細書で説明される技法の１つの目的は、要求側ＵＥ３０とターゲットＵＥ３０との間での中継ディスカバリが、要求側ＵＥ３０とターゲットＵＥ３０との間で中継ＵＥ３０がどのようにトラフィックを転送するか、例えばＬ２それともＬ３中継か、に依存することがないよう確実にすることである。技法は、ＵＥ－ｔｏ－ＵＥディスカバリと選択とを、ＴＳ２３．２８７の条項６．３．３で説明されるようなユニキャストリンク確立手順に統合することが可能であるという概念に依拠するものである。

【0057】

以下の説明では、リモートＵＥ３０との通信を開始するＵＥ３０を、要求側ＵＥ３０または開始側ＵＥ３０と称する。本明細書ではリモートＵＥ３０はまた、ターゲットＵＥ３０とも称される。ＵＥ－ｔｏ－ＵＥ中継としてサーブするＵＥ３０は、中継ＵＥ３０と呼ばれる。

【0058】

図８Ａ～図８Ｃは、中継ディスカバリを伴わずにリモートＵＥ３０とのユニキャストリンクを確立するための、ユニキャストリンク確立手順を図示している。要求側ＵＥ３０（本明細書では、発信側ＵＥ３０または開始側ＵＥ３０とも称される）は、ＵＥ－１で表されており、リモートＵＥ３０（ターゲットＵＥ３０または応答側ＵＥ３０とも称される）はＵＥ－２で表される。要求側ＵＥ３０（例えば、図８Ａ～図８ＣにおけるＵＥ－１）がリモートＵＥ３０（図８Ａ～図８ＣにおけるＵＥ－２）とユニキャスト通信を確立したい場合、要求側ＵＥ３０は、ＴＳ２３．３０３で規定されるようなＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージをブロードキャストする。Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージは、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎと呼ばれる新しいフィールドを含むように編集され、中継が通信に許可されるかどうかを示す。ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎフィールドはまた、要求側ＵＥ３０とリモートＵＥ３０との間の通信経路に許可される最大ホップ数を示すことが可能である。Ｒｅｌｅａｓｅ１７では、インジケーションの値は単一ホップに制限されると想定する。

【0059】

ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎフィールドの値は、０または正の整数、例えば１、２、・・・、ｎであることが可能である。一例では、要求側ＵＥ３０は、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ値を、ＵＥ３０によって選ばれる０からＭの間で選択し、この時Ｍは上限を表す。ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ値は、要求側ＵＥ３０によって許可される中継の最大数として考えることが可能であり、つまり値０は、許可される中継がないことを意味し（中継することが認められない）、値１は１つの中継だけが許可されることを意味する（ＵＥ－ｒｅｌａｙ－ＵＥ）、などである。許可される最大ホップ数は、中継の数に１をプラスしたものであり、この１は、要求側ＵＥ３０とリモートＵＥ３０との間の直接通信経路である。この値は、いくつかの手法に従ってセットすることが可能である。一手法では、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ値は、リンク確立が参照するアプリケーションによってセットすることが可能であり、アプリケーションのタイプによって変わることができる。別の手法では、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ値は、チップセットの特徴としてセットされる場合もある。別の手法では、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ値は、（例えば、ＳＩＭベースで、またはネットワークシグナリングを介して）事前設定されたか、（例えば、ネットワークシグナリングを介して）様々な用途に応じて変わる動的なポリシに従って、ネットワークによってセットすることも可能である。

【0060】

いくつかの実施形態では、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎフィールドは、中継が許可されるかどうかを示すブール値（ＴｒｕｅまたはＦａｌｓｅ）であってもよい。Ｔｒｕｅに等しいブール値は、中継が許可されることを示す。Ｆａｌｓｅに等しいブール値は、中継が許可されないことを示す。

【0061】

潜在的なＵＥ－ｔｏ－ＵＥ中継が、０より大きいｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎとともにＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージを受信する場合、この潜在的なＵＥ－ｔｏ－ＵＥ中継は、転送する（つまり、このメッセージをその近隣にブロードキャストする）かどうかを決定する。Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを転送するか再ブロードキャストするかどうかの決定は、例えば、要求中のＱｏＳ要件、中継の現在のトラフィック負荷、要求側ＵＥ３０と中継ＵＥ３０との間のリンク品質（例えば、要求メッセージの受信電力を測定することによって判定される）などの要因、または何らかの他のポリシ（例えば、一部の特定のＵＥ３０にだけサーブする）に基づくことが可能である。異なる要求には異なる転送手法を使用することが可能である。要求を転送するために従う手法は、チップセットの設計により進められるか、アプリケーション決定によって進められ得る。

【0062】

潜在的な中継が要求を転送する／再ブロードキャストすると決定した場合、潜在的な中継は、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ値を１減少させる。受信した要求を転送する際、潜在的な中継は、整数値が使用される場合、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ値以外の受信した要求に含まれるどのパラメータも変えない。しかし潜在的な中継は、中継負荷情報、中継ＱｏＳサポートなどの追加的な情報を受信した要求に付け加えることが可能である。

【0063】

中継がＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージを、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ値０で受信し、中継が要求のターゲットではない場合、中継はそのメッセージをドロップすることができる。中継が、既に以前転送したことのある通信要求（例えば、何らかの要求ＩＤによって識別することが可能である）を受信する場合、中継は現在の要求をドロップすることができる。

【0064】

ターゲットＵＥ３０に到達するために複数の中継ＵＥ３０を使用することができるか、ターゲットＵＥ３０がさらに、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージを要求側ＵＥ３０から直接受信してもよい、複数のシナリオが存在し得る。ターゲットＵＥ３０は、信号強度、ローカルポリシ（例えば、中継ＵＥ３０のトラフィック負荷）またはオペレータポリシ（例えば、常に直接通信を好ましいとするか、何らかの特定の中継ＵＥ３０だけを使用する）などの要因に従って、返信するものを選んでもよい。

【0065】

要求側ＵＥ３０はまた、応答メッセージを複数の中継ＵＥ３０から、またさらにターゲットＵＥ３０から直接受信してもよい。この場合、ソースＵＥ３０は、信号強度、ローカルポリシ（例えば、中継ＵＥ３０のトラフィック負荷）またはオペレータポリシ（例えば、常に直接通信を好ましいとするか、何らかの特定の中継ＵＥ３０だけを使用する）などの要因に従って、通信経路を選ぶ。

【0066】

図８Ａを参照すると、この例では、Ｒｅｌａｙ－１、Ｒｅｌａｙ－２およびＵＥ－２がＵＥ－１（要求側ＵＥ３０）から直接到達可能であると想定する。Ｒｅｌａｙ－１およびＲｅｌａｙ－２は、すべてＵＥ－１からのＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを転送したがっている。ＵＥ－２（リモートＵＥ３０）はまた、Ｒｅｌａｙ－１とＲｅｌａｙ－２から到達可能である。

【0067】

ステップ１では、ＵＥ－１はＵＥ－２とのユニキャスト通信を確立したがっており、通信は、ＵＥ－２との直接的なリンクを通じて、またはＵＥ－ｔｏ－ＵＥ中継を介してのいずれかで可能である。ＵＥ－１は、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔをｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ＝１でブロードキャストする。Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔはまた、要求識別子（ＩＤ）を含んでもよい。ＵＥ－１は、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔをブロードキャストする場合、任意選択でＴｉｍｅｒ１と示されるタイマを開始することが可能であり、Ｔｉｍｅｒ１はＵＥ－１が応答を待機する時間に対して上限を設定する。Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔは、Ｒｅｌａｙ－１、Ｒｅｌａｙ－２およびＵＥ－２によって受信される。ＵＥ－１はリモートＵＥ３０の識別情報を知る必要がないことに留意されたい。アプリオリな情報に基づいてＵＥ－１がＵＥ－２を意識する場合、要求は、任意選択でＵＥ－２用の識別子を含んでもよいし、または意図されるターゲットについての他の情報を含んでもよい。

【0068】

ステップ２では、Ｒｅｌａｙ－１とＲｅｌａｙ－２は、ＵＥ－１からのＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを転送する／ブロードキャストするよう決定する。Ｒｅｌａｙ－１とＲｅｌａｙ－２の両方は、同一のＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔをｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ＝０で、近隣ＵＥ３０に再ブロードキャストする。別の中継がこのメッセージを受信した場合、このメッセージはドロップされるだけである。例えば、Ｒｅｌａｙ－２が再ブロードキャストされたメッセージをＲｅｌａｙ－１から受信すると、Ｒｅｌａｙ－２は要求ＩＤを、以前に転送された要求と一致すると認識し、メッセージをドロップする。

【0069】

ステップ３では、ＵＥ－２はＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの複製を、ＵＥ－１、Ｒｅｌａｙ－１およびＲｅｌａｙ－２から直接受信する。この場合、ＵＥ－１がＵＥ－２に到達可能な３つの経路が存在する：直接的な経路、Ｒｅｌａｙ－１を介する経路、およびＲｅｌａｙ－２を介する経路。本方法の様々な実施形態では、ＵＥ－１とＵＥ－２との間の通信用の通信経路は、ＵＥ－２（リモートＵＥ３０）、ＵＥ－１（要求側ＵＥ３０）によって、またはＵＥ－１とＵＥ－２との組合せによって選択することが可能である。

【0070】

リモートＵＥ３０が通信経路を選択する実施形態では、リモートＵＥ３０はＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの第１の複製を受信した後、図８ＡでＴｉｍｅｒ２として示されるタイマを開始する。この例では、受信された第１の複製は、直接ＵＥ－１からの要求である。タイマは、遅延に対して上限を確立する一方で、リモートＵＥ３０は異なる経路に沿って伝播するＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの複製を収集する。タイマの値は、チップセット実装であってもよく、アプリケーションによってセットされるか、ネットワークによって与えられる（例えば、事前設定されるか、ネットワークシグナリングを介して提供される）。タイマが失効した後に受信した要求の複製はいずれも無視することができる。図８Ａで示される例では、Ｒｅｌａｙ－２からのＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの複製は、Ｔｉｍｅｒ２が失効した後に到達しているため、無視される。

【0071】

Ｔｉｍｅｒ２が終了した後、信号強度（受信した要求の強度を測定することによって判定される）、中継に対する負荷（中継ＵＥ３０によって要求に加わる）、ローカルポリシ（例えば、アプリケーションまたはチップセット設計によって提供される）またはオペレータポリシ（事前設定されるか、ネットワークシグナリングを介して提供される）などの要因に基づいて、ＵＥ－２はどの要求に返信するかを決定する。選択基準の例としては、例えば、最大の信号強度を有する要求を選択すること、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎパラメータの最大値を有する要求（最も少ない回数で転送された要求であることを意味し、潜在的に最短経路であることを示している）を選択することが挙げられる。決定はまた、要因の組合せに基づいてもよい。例えば、複数の要求が同一のｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ値を有する場合、最大信号強度に関連付けられる要求を選択することが可能である。

【0072】

先述のように、潜在的な中継がＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを転送する場合、この中継はまた、負荷情報、ＱｏＳサポートなどのさらなる情報をメッセージに追加することが可能である。この場合、リモートＵＥは、その情報を使用して通信経路を選ぶことが可能である。例えば、同一のｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎ値を有する２つの要求が受信された場合、リモートＵＥ３０は、負荷が軽いほうの値を選択することが可能である。

【0073】

いくつかの実施形態では、リモートＵＥ３０は、要求の第１の複製を受信する経路を常に選ぶように構成することが可能である。この場合、Ｔｉｍｅｒ２は必要ない。むしろ、リモートＵＥ３０は、第１の受信された要求の経路を直接選び、リモートＵＥ３０が受信する同一の要求ＩＤを有するいずれの後続の要求もドロップする。また、リモートＵＥ３０ポリシが、要求側ＵＥ３０からの最小ホップ数に関連付けられた経路を常に選ぶことである場合、リモートＵＥ３０は、要求側ＵＥ３０によって受信される要求を直接選択することが可能である。この場合、リモートＵＥ３０はＴｉｍｅｒ２を停止して、同一の要求ＩＤを有する後続の要求を無視することが可能である。別の例では、リモートＵＥ３０（すなわち、ＵＥ－２）が、ＵＥ－１とＵＥ－２との間で利用可能な良好な直接リンクを意味するＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを要求側ＵＥ３０（例えば、ＵＥ－１）から受信すると、ＵＥ－２は要求を受け入れてＴｉｍｅｒ２を停止してもよいが、中継ＵＥ３０から転送された他の要求は処理しない。

【0074】

いくつかの実施形態では、リモートＵＥ３０は、同一の接続用に１つまたは複数の通信経路を選択するように構成することが可能である。この場合、リモートＵＥ３０は、複数のＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔに返信することが可能であり、これらは１つだけの要求に返信する（つまり、初めの２つの受信要求に返信する）場合と同じ方法でポリシに従って選択される。この場合、要求側ＵＥ３０は、リモートＵＥ３０によって２つ以上の経路が選択されると、複数の通信経路を使用するように構成することが可能である。代替的に、要求側ＵＥ３０は任意選択で、リモートＵＥ３０によって示される通信経路のセットから、単一の通信経路（または、示される通信経路のすべてより少ない経路）を選択するように構成することが可能である。

【0075】

図８Ａで示される例では、ＵＥ－２がマルチリンク接続をセットアップしたがっていると想定する。したがって、ステップ４では、ＵＥ－２はＵＥ－１から直接受信したＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ、およびＲｅｌａｙ－１を介して受信したＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔに対して、その直接通信経路上とＲｅｌａｙ－１を介してＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージを送信することによって、返信する。Ｔｉｍｅｒ１が終了すると、ＵＥ－１はＵＥ－２とのＤ２Ｄ通信に使用する通信経路を判定する。この例では、両方の応答がＴｉｍｅｒ１の失効より先に受信されると想定する。いくつかの実施形態では、リモートＵＥ３０が複数経路を選択してある場合、要求側ＵＥ３０は、リモートＵＥ３０との通信には、常に複数の通信経路を使用するように構成することが可能である。他の実施形態では、要求側ＵＥ３０は、リモートＵＥ３０によって示された複数の通信経路のうち、リモートＵＥ３０とのＤ２Ｄ通信にどれを使用するかを選択するように構成することが可能である。ステップ５では、ＵＥ－１とＵＥ－２は選択された１つまたは複数の経路を使用してユニキャスト通信に関与する。

【0076】

いくつかの実施形態では、経路選択は、要求側ＵＥ３０によって行われる。この実施形態では、ＵＥ－１はＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔをブロードキャストするときにＴｉｍｅｒ１を開始して、応答を待機する。Ｔｉｍｅｒ１が失効すると、ＵＥ－１は、ＵＥ－２との通信にどの通信経路を使用するかを、タイマ失効より先に受信するあらゆるＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージに基づいて判定する。図８Ａで示される例では、ＵＥ－２はステップ４でＵＥ－１から直接受信したＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ、およびＲｅｌａｙ－１を介して受信されたＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔに対して応答する。ＵＥ－１は、Ｔｉｍｅｒ１の失効より先に両方の応答を、１つはＵＥ－２から直接、およびもう１つはＲｅｌａｙ－１を介して受信する。要求側ＵＥ３０は、信号強度、中継に対する負荷（中継によってＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージに加わる）、中継によるＱｏＳサポート（中継によってＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージに加わる）、ローカルポリシ（例えば、アプリケーションまたはチップセット設計によって提供される）またはオペレータポリシ（事前設定されるか、ネットワークシグナリングを介して提供される）などの要因に基づいて、通信経路を選択することが可能である。選択基準の例としては、例えば、最大の信号強度に関連付けられる通信経路を選択すること、中継に対する負荷が最も軽い通信経路を選択すること、利用可能であれば直接的な経路を選択することが挙げられる。決定はまた、要因の組合せに基づいてもよい。例えば、要求側ＵＥ３０は、直接的な経路が最低限の信号品質基準を満たしていればその経路を選択するように、または最低限の信号品質基準を満たす最も負荷の軽い中継を選択するように構成することが可能である。

【0077】

いくつかの実施形態では、要求側ＵＥ３０は、第１のＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージを受信する経路を常に選ぶように構成することが可能である。この場合、要求側ＵＥ３０はＴｉｍｅｒ１を停止して、第１のメッセージの後に受信したあらゆる後続のＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージを無視することが可能である。別の例では、要求側ＵＥ３０（すなわち、ＵＥ－２）が、ＵＥ－１とＵＥ－２との間で利用可能な良好な直接リンクを意味するＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔをリモートＵＥ３０（例えば、ＵＥ－１）から受信すると、ＵＥ－１はＴｉｍｅｒ１が失効してＴｉｍｅｒ１を停止するのを待機せずに、ただちに直接通信経路を選択してもよい。ステップ５では、ＵＥ－１とＵＥ－２は選択された１つまたは複数の経路を使用してユニキャスト通信に関与する。

【0078】

いくつかの実施形態では、リモートＵＥ３０が、複数の経路が通信に利用可能であると示している場合、経路選択は部分的にリモートＵＥ３０によって、また部分的に要求側ＵＥ３０によって行われてもよい。この場合、リモートＵＥ３０は、１つまたは複数の好ましい経路を選択するように構成される。要求側ＵＥ３０がＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔに応答して複数のＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージを受信する場合、要求側ＵＥ３０には、リモートＵＥ３０によって示される利用可能な通信経路から選択するという選択肢がある。要求側ＵＥ３０は、リモートＵＥ３０によって示される通信経路のすべて、または通信経路のすべてより少ない何らかの数を選択することが可能である。ステップ５では、ＵＥ－１とＵＥ－２は選択された１つまたは複数の経路を使用してユニキャスト通信に関与する。

【0079】

図８Ｂを参照すると、この例では、Ｒｅｌａｙ－１、Ｒｅｌａｙ－２およびＵＥ－２がＵＥ－１（要求側ＵＥ３０）から直接到達可能であると想定する。Ｒｅｌａｙ－１およびＲｅｌａｙ－２は、ＵＥ－１からのＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを転送したがっている。ＵＥ－２（リモートＵＥ３０）はまた、Ｒｅｌａｙ－１とＲｅｌａｙ－２から到達可能である。

【0080】

ステップ０では、ＵＥ３０はＵＥ－ｔｏ－ＵＥ中継によって与えられるサービスを使用するよう認可される。ＵＥ－ｔｏ－ＵＥ中継は、ＵＥ３０同士のトラフィックを中継するサービスを提供するよう認可される。ＵＥ／中継がネットワークに登録されると、認可を行うことが可能である。必要であればＵＥ３０と中継が互いに認可を検証できるように、セキュリティ関連パラメータがプロビジョニングされてもよい。

【0081】

ステップ１では、ＵＥ－１はＵＥ－２とのユニキャスト通信を確立したがっており、通信は、ＵＥ－２との直接的なリンクを通じて、またはＵＥ－ｔｏ－ＵＥ中継を介してのいずれかで可能である。ＵＥ－１は、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎを「有効（ｅｎａｂｌｅｄ）」に設定してブロードキャストする。Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔはまた、要求識別子（ＩＤ）を含んでもよい。Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔは、Ｒｅｌａｙ－１、Ｒｅｌａｙ－２によって受信される。Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔはまた、ＵＥ－２がＵＥ－１の近傍にあればＵＥ－２によって受信されてもよい。

【0082】

ステップ２では、Ｒｅｌａｙ－１とＲｅｌａｙ－２は、ＵＥ－１からのＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを転送する／ブロードキャストするよう決定する。Ｒｅｌａｙ－１とＲｅｌａｙ－２の両方は、同一のＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎを伴わずに、近隣ＵＥ３０にブロードキャストする。別の中継がこのメッセージを受信した場合、このメッセージはドロップされるだけである。例えば、Ｒｅｌａｙ－２が再ブロードキャストされたメッセージをＲｅｌａｙ－１から受信すると、Ｒｅｌａｙ－２は要求ＩＤを、以前に転送された要求と一致すると認識し、メッセージをドロップする。中継は、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを転送するとき、自身のＲｅｌａｙ ＩＤまたはＲｅｌａｙ ＵＥ情報をメッセージに含める。

【0083】

ステップ３では、ＵＥ－２はＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔの複製を、Ｒｅｌａｙ－１およびＲｅｌａｙ－２から受信する。

【0084】

ステップ４では、ＵＥ－２はＲｅｌａｙ－１を選び、Ｒｅｌａｙ－１を介してＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージで返信する。Ｒｅｌａｙ－１は、Ｒｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージを転送するとき、自身のＲｅｌａｙ ＩＤまたはＲｅｌａｙ ＵＥ情報をメッセージに含める。ＵＥ－２がＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔをＵＥ－１から直接受信する場合、ＵＥ－２はＲｅｑｕｅｓｔ ＡｃｃｅｐｔをＵＥ－１に直接送信することによって、直接通信リンクをセットアップすることを選んでもよい。

【0085】

ステップ５では、ＵＥ－１はＲｅｌａｙ－１からＲｅｑｕｅｓｔ Ａｃｃｅｐｔを受信する。ＵＥ－１はポリシ（例えば、可能であれば常に直接的な経路を選ぶ）、信号強度などに従って、経路を選ぶ。ＵＥ－１がＲｅｑｕｅｓｔ ＡｃｃｅｐｔをＵＥ－２から直接受信する場合、ＵＥ－１は、ＴＳ２３．２８７の条項６．３．３に説明されるように直接的なＬ２リンクをセットアップすることを選んでもよい。この場合、ステップ６はスキップされる。

【0086】

ステップ６では、ＵＥ－１とＵＥ－２は、ＵＥ－ｔｏ－ＵＥ中継を選んだことを通じて、通信リンクをセットアップする。リンクのセットアップ情報は、中継のタイプ、例えばＬ２中継か、それともＬ３中継か、に応じて変わることがある。

【0087】

図８Ｃを参照すると、Ｒｅｌａｙ－１、Ｒｅｌａｙ－２およびＵＥ－２がＵＥ－１（要求側ＵＥ３０）から直接到達可能であると想定する。Ｒｅｌａｙ－１およびＲｅｌａｙ－２は、すべてＵＥ－１からのＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを転送したがっている。ＵＥ－２（リモートＵＥ３０）はまた、Ｒｅｌａｙ－１とＲｅｌａｙ－２から到達可能である。

【0088】

ステップ０では、ＵＥ３０がＵＥ－ｔｏ－ＵＥ中継によって与えられるサービスを使用するよう認可される。ＵＥ－ｔｏ－ＵＥ中継は、ＵＥ３０同士のトラフィックを中継するサービスを提供するよう認可される。ＵＥ／中継がネットワークに登録されると、認可を行うことが可能である。セキュリティ関連パラメータは、必要であればＵＥ３０と中継が互いに認可を検証できるようにプロビジョニングされてもよい。

【0089】

ステップ１では、ＵＥ－１はＵＥ－２とのユニキャスト通信を確立したがっており、通信は、ＵＥ－２との直接的なリンクを通じて、またはＵＥ－ｔｏ－ＵＥ中継を介してのいずれかで可能である。ＵＥ－１は、Ｓｏｌｉｃｉｔａｔｉｏｎメッセージを、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎを「有効（ｅｎａｂｌｅｄ）」に設定してブロードキャストする。Ｓｏｌｉｃｉｔａｔｉｏｎメッセージはまた、要求識別子（ＩＤ）を含んでもよい。Ｓｏｌｉｃｉｔａｔｉｏｎメッセージは、Ｒｅｌａｙ－１およびＲｅｌａｙ－２によって受信される。Ｓｏｌｉｃｉｔａｔｉｏｎメッセージは、ＵＥ－２ ＩＤまたはＵＥ－２のＡｐｐｌｉｃａｔｉｏｎ Ｕｓｅｒ Ｉｎｆｏ、ＵＥ－１ ＩＤまたはＵＥ－１のＡｐｐｌｉｃａｔｉｏｎ Ｕｓｅｒ Ｉｎｆｏを含む。メッセージはまた、ＵＥ－２がＵＥ－１の近傍にあればＵＥ－２によって受信されてもよい。

【0090】

ステップ２では、Ｒｅｌａｙ－１とＲｅｌａｙ－２は、ＳｏｌｉｃｉｔａｔｉｏｎメッセージをＵＥ－１から転送する／ブロードキャストするよう決定する。Ｒｅｌａｙ－１とＲｅｌａｙ－２の両方が、Ｓｏｌｉｃｉｔａｔｉｏｎメッセージを、ｒｅｌａｙ＿ｉｎｄｉｃａｔｉｏｎを伴わずに近隣ＵＥ３０にブロードキャストする。別の中継がこのメッセージを受信した場合、このメッセージはドロップされるだけである。中継は、Ｓｏｌｉｃｉｔａｔｉｏｎメッセージを転送するとき、自身のＲｅｌａｙ ＩＤまたはＲｅｌａｙ ＵＥ情報をメッセージに含める。

【0091】

ステップ３では、ＵＥ－２はＳｏｌｉｃｉｔａｔｉｏｎメッセージの複製を、Ｒｅｌａｙ－１およびＲｅｌａｙ－２から受信する。

【0092】

ステップ４では、ＵＥ－２はＲｅｌａｙ－１を選び、Ｒｅｌａｙ－１を介してＲｅｓｐｏｎｓｅメッセージで返信する。Ｒｅｌａｙ－１は、Ｒｅｓｐｏｎｓｅメッセージを転送するとき、自身のＲｅｌａｙ ＩＤまたはＲｅｌａｙ ＵＥ情報をメッセージに含める。ＵＥ－２がＳｏｌｉｃｉｔａｔｉｏｎメッセージをＵＥ－１から直接受信する場合、ＵＥ－２はＲｅｓｐｏｎｓｅメッセージをＵＥ－１に直接送信することによって、直接通信リンクをセットアップすることを選んでもよい。

【0093】

ステップ５では、ＵＥ－１はＲｅｌａｙ－１からＲｅｑｕｅｓｔ Ａｃｃｅｐｔを受信する。ＵＥ－１はポリシ（例えば、可能であれば常に直接的な経路を選ぶ）、信号強度などに従って、経路を選ぶ。ＵＥ－１がＲｅｑｕｅｓｔ ＡｃｃｅｐｔをＵＥ－２から直接受信する場合、ＵＥ－１は、ＴＳ２３．２８７の条項６．３．３に説明されるように直接的なＬ２リンクをセットアップすることを選んでもよい。この場合、ステップ６はスキップされる。

【0094】

ステップ６では、ＵＥ－１とＵＥ－２は、ＵＥ－ｔｏ－ＵＥ中継を選んだことを通じて、通信リンクをセットアップする。リンクのセットアップ情報は、中継のタイプ、例えばＬ２中継か、それともＬ３中継か、に応じて変わることがある。

【0095】

図８Ａ～図８Ｃに示される実施形態において中継または経路選択を行うために、要求側ＵＥ３０はＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ（またはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）を送出した後に、決定を行う前に対応するＲｅｑｕｅｓｔ Ａｃｃｅｐｔ（またはＲｅｓｐｏｎｓｅ）メッセージを収集するためのタイマをセットアップすることが可能である。同様に、ターゲットＵＥ３０はまた、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ（またはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）の第１の複製を受信した後に、決定を行う前に異なる経路からメッセージの複数の複製を収集するためのタイマをセットアップすることが可能である。

【0096】

要求側ＵＥ３０が初めてＵＥ－ｔｏ－ＵＥ中継からメッセージを受信するときは、要求側ＵＥ３０は、中継ＵＥ３０がＵＥ－ｔｏ－ＵＥ中継として認可されているかどうかを検証する必要がある場合がある。同様に、ＵＥ－ｔｏ－ＵＥ中継はまた、要求側ＵＥ３０が中継サービスを使用するよう認可されているかどうかを検証する必要がある場合がある。検証の詳細、および２つのＵＥ３０間の通信をＵＥ－ｔｏ－ＵＥ中継を通じてどのようにセキュアにするかは、規格によって規定することが可能である。

【0097】

図９は、中継ディスカバリを伴う、リモートＵＥ３０へのユニキャストリンク確立のための手順の図である。各中継は、中継から到達可能な近隣ＵＥ３０のリストを維持し、定期的にアナウンスメントをブロードキャストして、通信を中継するための利用可能性を示す（ステップ０）。アナウンスメントには、中継ＵＥ３０が到達可能な他のＵＥ３０のインジケーション（例えば、到達可能近隣リスト）が含まれる。中継ＵＥ３０の到達範囲内の近隣ＵＥ３０がブロードキャストアナウンスメントを受信すると、中継ＵＥ３０は、中継ＵＥ３０を使用してＤ２Ｄ通信を中継したいかどうかを決定することができる。中継ＵＥ３０を使用してＤ２Ｄ通信を中継したい場合、受信側ＵＥ３０は、中継ＵＥ３０用の到達可能近隣リストの複製を自身のローカルメモリに記憶し、中継要求を中継ＵＥ３０に送信する。中継要求を受信すると、中継ＵＥ３０は、要求側ＵＥ３０をその到達可能な近隣に追加して、更新されたリストを次のブロードキャストディスカバリメッセージ内で送信する。要求側ＵＥ３０がリモートＵＥ３０と通信したい場合、要求側ＵＥ３０は、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを送信する前に、リモートＵＥ３０に到達することができる中継ＵＥ３０を選ぶことができる。この点において、選ばれた中継ＵＥ３０は選択された通信経路における第１のホップであるため、中継ＵＥ３０を選ぶことは、経路を選ぶことと等価である。

【0098】

図９で示される例では、ＵＥ－１がＵＥ－２と直接通信することができないと想定する。Ｒｅｌａｙ－１およびＲｅｌａｙ－２は、ＵＥ－１およびＵＥ－２両方に到達可能である。ステップ０では、Ｒｅｌａｙ－１およびＲｅｌａｙ－２は、通信を中継する利用可能性が示されたアナウンスメントをブロードキャストする。ＵＥ－１がＲｅｌａｙ－１およびＲｅｌａｙ－２からブロードキャストされたメッセージを受信すると、ＵＥ－１は両方の中継ＵＥ３０をＤ２Ｄ通信に使用するよう決定する。ステップ１では、ＵＥ－１は中継要求をＲｅｌａｙ－１およびＲｅｌａｙ－２に送信する。Ｒｅｌａｙ－１およびＲｅｌａｙ－２は、ＵＥ－１から応答を受信すると、ＵＥ－１を自身の到達可能近隣リストに追加し、更新されたリストを次のブロードキャストディスカバリ内で送信する。同じように、ＵＥ－２はＲｅｌａｙ－２からアナウンスメントを受信して、Ｒｅｌａｙ－２を使用するよう決定する。ステップ２では、ＵＥ－２は中継要求をＲｅｌａｙ－２に送信する。Ｒｅｌａｙ－２は、ＵＥ－２から応答を受信すると、ＵＥ－１およびＵＥ－２を自身の到達可能近隣リストに追加し、更新されたリストを次のブロードキャストディスカバリメッセージ内で送信する。アナウンスメントがブロードキャストされる都度、Ｒｅｌａｙ－１およびＲｅｌａｙ－２の近隣にあるＵＥ３０は、Ｒｅｌａｙ－２についての到達可能リストの自身のローカル複製を、最後のブロードキャストから変わっていれば、更新する。

【0099】

要求側ＵＥ３０がリモートＵＥ３０に通信を送信する必要がある場合、要求側ＵＥ３０は、通信経路を、メモリに記憶されている近隣リストの自身のローカル複製に基づいて選択する。中継の信号強度（ブロードキャストアナウンスメントを測定することによって判定される）、中継の負荷（アナウンスメントに含まれる）、中継によって与えられるＱｏＳサポート（アナウンスメントに含まれる）など）の、追加的なメモリがさらに記憶されてもよい。利用可能な２つ以上の通信経路が存在する場合があるため、要求側ＵＥ３０は、先述したように、信号強度、中継の負荷（アナウンスメントメッセージに含まれる）、中継によってサポートされるＱｏＳ（アナウンスメントメッセージに含まれる）、ローカルポリシ（例えば、アプリケーションまたはチップセット設計によって提供される）またはオペレータポリシ（事前設定されるか、ネットワークシグナリングを介して提供される）などの要因に基づいて通信経路を選択する。図９で示される例では、ＵＥ－１はＲｅｌａｙ－２を選択し、ステップ３において、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔをＲｅｌａｙ－２に送信する。Ｒｅｌａｙ－２はＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔをリモートＵＥ３０に転送する。ステップ４では、リモートＵＥ３０は、Ｒｅｌａｙ－２を介してＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージを要求側ＵＥ３０に送信する。次いで、ＵＥ－１およびＵＥ－２は、Ｒｅｌａｙ－２を介してユニキャスト通信リンクを確立し、通信を始める。

【0100】

中継要求またはＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔは、中継からブロードキャストメッセージを受信した後、直接送信することが可能であるか、後で送信することも可能である。中継ＵＥ３０は、ブロードキャストアナウンスメントメッセージ内にｖａｌｉｄｉｔｙ＿ｔｉｍｅｒパラメータを含み追加することが可能であり、このパラメータは中継ＵＥ３０がどれくらい長く、応答を受け付けるかを示す。ブロードキャストアナウンスメントメッセージを送信するとき、中継ＵＥ３０はｖａｌｉｄｉｔｙ＿ｔｉｍｅｒを開始し、このタイマの失効まで応答を処理する。ＵＥ３０は、中継ＵＥ３０からアナウンスメントメッセージを受信すると、その中継に関連付けられたｖａｌｉｄｉｔｙ＿ｔｉｍｅｒを開始する。続いてＵＥ３０が、この中継を介して到達可能なＵＥ３０とのリンクを確立する必要がある場合、ＵＥ３０は、ｖａｌｉｄｉｔｙ＿ｔｉｍｅｒが失効していなければ、要求メッセージを中継に送信することが可能である。

【0101】

図１０は、Ｄ２Ｄ通信用の要求側ＵＥ３０によって実装される例示的な方法１００を図示している。要求側ＵＥ３０は、リモートＵＥ３０との通信を開始する要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）を、１つまたは複数の近隣ＵＥ３０にブロードキャストする（ブロック１１０）。要求には、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。いくつかの実施形態では、中継インジケーションは、通信経路についての最大中継数、または最大ホップ数をさらに示す場合がある。要求側ＵＥ３０は、要求に応答して、応答メッセージ（例えば、Ｒｅｑｕｅｓｔ受け入れ、またはＳｏｌｉｃｉｔａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ）を、近隣ＵＥ３０のうちの１つまたは複数から、さらに受信する（ブロック１２０）。要求側ＵＥ３０は、要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信用の通信経路を、１つまたは複数の応答メッセージに基づいて判定する（ブロック１３０）。

【0102】

方法１００のいくつかの実施形態では、通信経路はリモートＵＥ３０によって選択される。要求側ＵＥ３０は、単一応答メッセージを近隣ＵＥ３０から受信し、応答メッセージが受信された近隣ＵＥ３０の識別情報に基づいて通信経路を判定する。

【0103】

方法１００のいくつかの実施形態では、要求側ＵＥ３０は、中継としてサーブする近隣ＵＥ３０から単一応答メッセージを受信し、判定された通信経路は、要求側ＵＥ３０から応答側ＵＥ３０への２つ以上のホップを含む。

【0104】

方法１００のいくつかの実施形態では、要求側ＵＥ３０は、リモートＵＥ３０から直接単一応答メッセージを受信し、判定された通信経路は、要求側ＵＥ３０とリモートＵＥ３０との間の経路である。

【0105】

方法１００のいくつかの実施形態では、要求側ＵＥ３０は、１つまたは複数の近隣ＵＥ３０のそれぞれから応答メッセージを受信し、要求側ＵＥ３０によって受信された１つまたは複数の応答メッセージに基づいて通信経路を選択する。

【0106】

方法１００のいくつかの実施形態では、ＵＥ３０が、リモートＵＥ３０から直接応答メッセージを受信すると、ＵＥ３０は要求側ＵＥ３０からリモートＵＥ３０への経路を選択する。

【0107】

方法１００のいくつかの実施形態では、要求側ＵＥ３０は、１つまたは複数の応答メッセージに含まれる経路選択情報に基づいて通信経路を選択する。

【0108】

方法１００のいくつかの実施形態では、経路選択情報は、チャネル品質情報、負荷情報、またはデバイス能力情報のうちの少なくとも１つを含む。

【0109】

方法１００のいくつかの実施形態では、要求側ＵＥ３０は、要求をブロードキャストした後、予め定められた時間前に受信された応答メッセージのうちの１つまたは複数に基づいて通信経路を判定する。

【0110】

方法１０のいくつかの実施形態は、判定された通信経路を使用してリモートＵＥ３０と通信することをさらに含む。

【0111】

方法１００のいくつかの実施形態では、要求メッセージはＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを含み、応答メッセージはＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージを含む。

【0112】

方法１００のいくつかの実施形態では、要求メッセージはＳｏｌｉｃｉｔａｔｉｏｎメッセージを含み、応答メッセージはＲｅｓｐｏｎｓｅメッセージを含む。

【0113】

図１１は、要求側ＵＥ３０とリモートＵＥ３０との間のＤ２Ｄ通信を中継する中継ＵＥ３０によって実装される例示的な方法１５０を示している。中継ＵＥ３０は、リモートＵＥ３０との通信を開始する要求側ＵＥによってブロードキャストされた要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）を受信する（ブロック１６０）。要求には、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。いくつかの実施形態では、中継インジケーションは、通信経路についての最大中継数、または最大ホップ数をさらに示す場合がある。中継ＵＥ３０は、要求をリモートＵＥに向けてさらに転送する（ブロック１７０）。

【0114】

方法１５０のいくつかの実施形態では、要求をリモートＵＥ３０に向けて転送することは、要求を中継インジケーションの値に応じて転送することを含む。

【0115】

方法１５０のいくつかの実施形態では、要求をリモートＵＥ３０に向けて転送することは、要求についてのＱｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ（ＱｏＳ）要件、ＵＥ３０の負荷、またはＵＥ３０と要求側ＵＥ３０との間の通信リンクのチャネル品質のうちの少なくとも１つにさらに応じたものになる。

【0116】

方法１５０のいくつかの実施形態では、ＵＥ３０は、中継インジケーションの値が予め定められた値より大きくなると、要求を転送する。

【0117】

方法１５０のいくつかの実施形態は、中継インジケーションが予め定められた値に等しくなると、要求を破棄することをさらに含む。

【0118】

方法１５０のいくつかの実施形態は、要求内の中継インジケーションの値を、要求を転送することに先立って、予め定められた分デクリメントすることをさらに含む。

【0119】

方法１５０のいくつかの実施形態は、要求側ＵＥ３０とリモートＵＥ３０との間でＤ２Ｄ通信を中継することをさらに含み、リモートＵＥ３０は判定された通信経路を使用する。

【0120】

方法１５０のいくつかの実施形態では、要求メッセージはＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを含み、応答メッセージはＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージを含む。

【0121】

方法１５０のいくつかの実施形態では、要求メッセージはＳｏｌｉｃｉｔａｔｉｏｎメッセージを含み、応答メッセージはＲｅｓｐｏｎｓｅメッセージを含む。

【0122】

図１２は、Ｄ２Ｄ通信用のリモートＵＥ３０によって実装される例示的な方法２００を図示している。リモートＵＥ３０は、リモートＵＥ３０との通信を開始する要求側ＵＥ３０によってブロードキャストされた要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）の１つまたは複数の複製を受信する（ブロック２１０）。要求には、要求側ＵＥ３０とリモートＵＥ３０との間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。いくつかの実施形態では、中継インジケーションは、通信経路についての最大中継数、または最大ホップ数をさらに示す場合がある。リモートＵＥ３０は、要求の１つまたは複数の複製のそれぞれに応答して、要求側ＵＥ３０に、応答メッセージ（例えば、Ｒｅｑｕｅｓｔ ＡｃｃｅｐｔまたはＳｏｌｉｃｉｔａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ）を、要求が受信された通信経路に沿ってさらに送信する（ブロック２２０）。

【0123】

方法２００のいくつかの実施形態は、要求側ＵＥ３０とリモートＵＥ３０との間のＤ２Ｄ通信用の通信経路を選択することをさらに含む。

【0124】

方法２００のいくつかの実施形態では、要求の１つまたは複数の複製のそれぞれに応答して応答メッセージを送信することは、選択された通信経路に沿って単一応答メッセージを送信することを含む。

【0125】

方法２００のいくつかの実施形態は、要求の複数の複製を要求側ＵＥ３０とリモートＵＥ３０との間の個々の通信経路に沿って受信することをさらに含み、要求の１つまたは複数の複製のそれぞれに応答して応答メッセージを送信することは、複数の応答メッセージを、通信経路の個々の経路に沿ってＵＥ３０に送信することを含む。

【0126】

方法２００のいくつかの実施形態では、応答メッセージは、予め定められた時間ウィンドウ内に受信された要求に応答して送信される。

【0127】

方法２００のいくつかの実施形態は、要求側ＵＥ３０またはリモートＵＥ３０によって選択された通信経路のうちの１つを使用してリモートＵＥ３０と通信することをさらに含む。

【0128】

方法２００のいくつかの実施形態では、要求メッセージはＤｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔを含み、応答メッセージはＲｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージを含む。

【0129】

方法２００のいくつかの実施形態では、要求メッセージはＳｏｌｉｃｉｔａｔｉｏｎメッセージを含み、応答メッセージはＲｅｓｐｏｎｓｅメッセージを含む。

【0130】

図１３は、Ｄ２Ｄ通信用に設定された要求側ＵＥ３０によって実装される例示的な方法２５０を図示している。要求側ＵＥ３０は、１つまたは複数の中継ＵＥ３０によってブロードキャストされたアナウンスメントを受信する（ブロック２６０）。各アナウンスメントは、中継ＵＥ３０から到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む。要求側ＵＥ３０は、要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）を、自身の近隣リストにリモートＵＥ３０を有する中継ＵＥ３０のうち選択された中継ＵＥ３０にさらに送信する（ブロック２７０）。要求は、ターゲットとなるリモートＵＥ３０を識別するための識別情報を含む。要求側ＵＥ３０は、要求に応答して、応答メッセージ（例えば、Ｒｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージ、またはＳｏｌｉｃｉｔａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ）を、中継ＵＥ３０によって中継されるリモートＵＥから、さらに受信する（ブロック２８０）。

【0131】

方法２５０のいくつかの実施形態では、自身の近隣リストにリモートＵＥ３０を有する近隣ＵＥの１つに要求を送信することは、要求側ＵＥ３０からリモートＵＥ３０への通信経路を選択することであって、通信経路は近隣ＵＥのうちの１つを含む、通信経路を選択することと、要求を選択された通信経路上で、近隣ＵＥ３０に送信することとを含む。

【0132】

方法２５０のいくつかの実施形態では、要求側ＵＥ３０からリモートＵＥ３０への通信経路を選択することは、ＵＥ３０と近隣ＵＥとの間のチャネル品質を示すチャネル品質情報、近隣ＵＥについての負荷情報、または近隣ＵＥについてのデバイス能力情報のうちの１つに少なくとも部分的に基づいている。

【0133】

方法２５０のいくつかの実施形態では、アナウンスメントのうちの１つまたは複数は、近隣ＵＥ３０が要求を受け入れる期間を示す時間パラメータを含む。

【0134】

方法２５０のいくつかの実施形態では、要求を近隣ＵＥのうちの１つに送信することは、示された期間に要求を送信することを含む。

【0135】

方法２５０のいくつかの実施形態は、判定された通信経路を使用してリモートＵＥ３０と通信することをさらに含む。

【0136】

図１４は、要求側ＵＥ３０とリモートＵＥ３０との間のＤ２Ｄ通信を中継する中継ＵＥ３０によって実装される例示的な方法３００を示している。中継ＵＥ３０は、１つまたは複数の近隣ＵＥ３０にアナウンスメントをブロードキャストする（ブロック３１０）。アナウンスメントは、中継ＵＥ３０から到達可能な１つまたは複数の潜在的なリモートＵＥ３０を識別する近隣リストを含む。アナウンスメントは、定期的にブロードキャストすることが可能である。いくつかの実施形態では、中継ＵＥ３０は、中継ＵＥ３０にＵＥ－ｔｏ－ＵＥ中継としてサーブするよう要求する、１つまたは複数の近隣ＵＥ３０から中継要求を受信する（ブロック３２０）。中継ＵＥ３００は、これらの近隣ＵＥ３０を自身の近隣リストに追加して、更新されたリストを次のブロードキャストインターバルでブロードキャストする。中継ＵＥ３０は、近隣リストにあるリモートＵＥ３０とのＤ２Ｄ通信を開始する要求側ＵＥから要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）をさらに受信する（ブロック３３０）。要求は、ターゲットとなるリモートＵＥ３０を識別するための識別情報を含む。中継ＵＥ３０は、要求によって識別されるリモートＵＥに向けて、要求をさらに転送する（ブロック３４０）。

【0137】

方法３００のいくつかの実施形態は、アナウンスメントに応答して、１つまたは複数の中継要求を近隣ＵＥのうちの異なるＵＥから受信することと、中継要求を送った近隣ＵＥ３０を後続のアナウンスメントのために近隣リストに追加することとをさらに含む。

【0138】

方法３００のいくつかの実施形態では、要求をリモートＵＥ３０に向けて転送することは、アナウンスメントに続いて予め定められた期間に受信した要求を転送することを含む。

【0139】

方法３００のいくつかの実施形態は、要求に応答して、応答メッセージをリモートＵＥ３０から受信することをさらに含み、応答メッセージを要求側ＵＥ３０に転送する。

【0140】

方法３００のいくつかの実施形態では、アナウンスメントは、要求側ＵＥ３０からの要求を受け入れるための期間を示す時間パラメータを含む。

【0141】

方法３００のいくつかの実施形態は、要求側ＵＥ３０とリモートＵＥ３０との間でＤ２Ｄ通信を中継することをさらに含む。

【0142】

図１５は、Ｄ２Ｄ通信用のリモートＵＥ３０によって実装される例示的な方法３５０を図示している。リモートＵＥ３０は、中継ＵＥ３０によってブロードキャストされたアナウンスメントを受信する（ブロック３６０）。リモートＵＥ３０は、アナウンスメントに応答して、中継ＵＥ３０にＤ２Ｄ通信用の中継としてサーブするよう要求する中継要求を、中継ＵＥ３０にさらに送信する（ブロック３７０）。いくつかの実施形態では、リモートＵＥ３０は、中継ＵＥを介して、要求側ＵＥから発信される要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）をさらに受信してもよい（ブロック３８０）。リモートＵＥ３０は、要求に応答して、応答メッセージ（例えば、Ｒｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージ、またはＳｏｌｉｃｉｔａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ）を、中継ＵＥを介して要求側ＵＥに、さらに送信する（ブロック３９０）。

【0143】

方法３５０のいくつかの実施形態は、中継ＵＥ３０を介して、要求側ＵＥ３０から発信される要求を受信することと、要求に応答して、中継ＵＥ３０を介して応答メッセージを要求側ＵＥ３０に送信することとをさらに含む。

【0144】

方法３５０のいくつかの実施形態では、アナウンスメントは、中継ＵＥ３０がグループに参加する要求を受け入れる期間を示す時間パラメータを含む。

【0145】

方法３５０のいくつかの実施形態では、中継要求を送信することは、アナウンスメントで示された期間に中継要求を送信することを含む。

【0146】

方法３５０のいくつかの実施形態は、要求側ＵＥ３０またはリモートＵＥ３０によって選択された通信経路のうちの１つを使用して要求側ＵＥ３０と通信することをさらに含む。

【0147】

装置は、あらゆる機能的手段、モジュール、ユニット、または回路網を実装することによって、本明細書で説明される方法のいずれかを実行することが可能である。一実施形態では、例えば、装置は、方法図面で示されるステップを実行するように構成された個々の回路または回路網を含む。この点において、回路または回路網は、特定の機能的な処理を実行することに特化した回路および／または１つもしくは複数のマイクロプロセッサをメモリと併せて含んでもよい。例えば、回路網は、１つまたは複数のマイクロプロセッサまたはマイクロコントローラ、ならびに他のデジタルハードウェアを含んでもよく、これらはデジタル信号プロセッサ（ＤＳＰ）、専用デジタルロジックなどを含み得る。処理回路は、メモリに記憶されたプログラムコードを実行するように設定することができ、メモリとしては、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ、キャッシュメモリ、フラッシュメモリデバイス、光学記憶デバイスなどの１つまたはいくつかのタイプのメモリを挙げることができる。メモリに記憶されたプログラムコードは、１つまたは複数の通信および／またはデータ通信プロトコルを実行するためのプログラム命令、ならびにいくつかの実施形態において本明細書で説明される技法のうちの１つまたは複数を実行するための命令を含んでもよい。メモリを採用する実施形態では、メモリは、１つまたは複数のプロセッサによって実行されると、本明細書で説明される技法を実行するプログラムコードを記憶する。

【0148】

図１６Ａ～図１６Ｃは、Ｄ２Ｄ通信用に設定されたＵＥ４００の例示的な実施形態を示している。図１６Ａ～図１６Ｃに示される実施形態のそれぞれでは、ＵＥ４００は、基地局２０および他のＵＥ４００と通信するための１つまたは複数のアンテナ４１０を含むアンテナアレイ４０５を備える。ＵＥ４００は、要求側ＵＥ、中継ＵＥ、リモートＵＥ、またはそれらのあらゆる組合せとして機能するように構成することが可能である。

【0149】

図１６Ａは、要求側ＵＥ４００の機能的コンポーネントを示している。図１６Ａに示される要求側ＵＥ４００は、ブロードキャスティングユニット４１５、受信ユニット４２０、および判定ユニット４２５を備える。様々なユニット４１５～４２５は、１つまたは複数のマイクロプロセッサ、ハードウェア回路、ファームウェア、またはそれらの組合せによって実装されてもよい。ブロードキャスティングユニット４１５は、リモートＵＥ３０との通信を開始する要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）を、１つまたは複数の近隣ＵＥ３０にブロードキャストするように構成される。要求には、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。いくつかの実施形態では、中継インジケーションは、通信経路についての最大中継数、または最大ホップ数をさらに示す場合がある。受信ユニット４２０は、要求に応答して、応答メッセージ（例えば、Ｒｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージ、またはＳｏｌｉｃｉｔａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ）を、近隣ＵＥ３０のうちの１つまたは複数から受信するように構成される。判定ユニット４２５は、要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信用の通信経路を、１つまたは複数の応答メッセージに基づいて判定するように構成される。

【0150】

図１６Ｂは、中継ＵＥ４００の機能的コンポーネントを示している。図１６Ｂに示される中継ＵＥ４００は、受信ユニット４３０、および転送ユニット４３５をさらに備える。様々なユニット４３０～４３５は、１つまたは複数のマイクロプロセッサ、ハードウェア回路、ファームウェア、またはそれらの組合せによって実装されてもよい。受信ユニット４３０は、リモートＵＥ３０との通信を開始する要求側ＵＥによってブロードキャストされた要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）を受信するように構成される。要求には、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。いくつかの実施形態では、中継インジケーションは、通信経路についての最大中継数、または最大ホップ数をさらに示す場合がある。転送ユニット４３５は、要求をリモートＵＥに向けて転送するように構成される。

【0151】

図１６Ｃは、リモートＵＥ４００の機能的コンポーネントを示している。図１６Ｃに示されるリモートＵＥ４００は、受信ユニット４４５、および送信ユニット４５０をさらに備える。様々なユニット４４５～４５０は、１つまたは複数のマイクロプロセッサ、ハードウェア回路、ファームウェア、またはそれらの組合せによって実装されてもよい。受信ユニット４４５は、リモートＵＥ３０との通信を開始する要求側ＵＥによってブロードキャストされた要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）の１つまたは複数の複製を受信するように構成される。要求には、要求側ＵＥ３０とリモートＵＥ３０との間の通信経路に中継が許可されるかどうかを示す中継インジケーションが含まれる。いくつかの実施形態では、中継インジケーションは、通信経路についての最大中継数、または最大ホップ数をさらに示す場合がある。送信ユニット４５０は、要求の１つまたは複数の複製のそれぞれに応答して、要求側ＵＥに、応答メッセージ（例えば、Ｒｅｑｕｅｓｔ ＡｃｃｅｐｔまたはＳｏｌｉｃｉｔａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ）を、要求が受信された通信経路に沿ってさらに送信するように構成される。

【0152】

図１７Ａ～図１７Ｃは、Ｄ２Ｄ通信用に設定されたＵＥ５００の例示的な実施形態を示している。図１７Ａ～図１７Ｃに示される実施形態のそれぞれでは、ＵＥ５００は、基地局２０と通信するための１つまたは複数のアンテナ５１０を含むアンテナアレイ５０５を備える。ＵＥ５００は、要求側ＵＥ、中継ＵＥ、リモートＵＥ、またはそれらのあらゆる組合せとして機能するように構成することが可能である。

【0153】

図１７Ａは、要求側ＵＥ５００の機能的コンポーネントを示している。図１７Ａに示される要求側ＵＥ５００は、第１の受信ユニット５１５、送信ユニット５２０、および第２の受信ユニット５２５をさらに備える。様々なユニット５１５～５２５は、１つまたは複数のマイクロプロセッサ、ハードウェア回路、ファームウェア、またはそれらの組合せによって実装されてもよい。第１の受信ユニット５１５は、１つまたは複数の中継ＵＥ３０によってブロードキャストされたアナウンスメントを受信するように構成される。各アナウンスメントは、中継ＵＥ３０から到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む。送信ユニット５２０は、要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）を、自身の近隣リストにリモートＵＥ３０を有する中継ＵＥ３０のうち選択された中継ＵＥ３０に送信するように構成され、要求は、ターゲットとなるリモートＵＥを識別するための情報（例えば、ＵＥ ＩＤ）を識別することを含む。第２の受信ユニット５２５は、要求に応答して、応答メッセージ（例えば、Ｒｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージ、またはＳｏｌｉｃｉｔａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ）を、中継ＵＥ３０によって中継されたリモートＵＥ３０から受信するように構成される。

【0154】

図１７Ｂは、中継ＵＥ５００の機能的コンポーネントを示している。図１７Ｂに示される中継ＵＥ５００は、ブロードキャストユニット５３０、近隣リストユニット５３５、第２の受信ユニット５４０、および転送ユニット５４５をさらに備える。様々なユニット５３０～５４５は、１つまたは複数のマイクロプロセッサ、ハードウェア回路、ファームウェア、またはそれらの組合せによって実装されてもよい。ブロードキャストユニット５３０は、アナウンスメントを１つまたは複数の近隣ＵＥ３０へブロードキャストするように構成される。アナウンスメントは、中継ＵＥ３０から到達可能な１つまたは複数の潜在的なリモートＵＥ３０を識別する近隣リストを含む。アナウンスメントは、定期的にブロードキャストすることが可能である。近隣リストユニット５３５を含む実施形態では、中継ＵＥ３０は、中継ＵＥ３０にＵＥ－ｔｏ－ＵＥ中継としてサーブするよう要求する、１つまたは複数の近隣ＵＥ３０から中継要求を受信し、これらの近隣ＵＥ３０をその近隣リストに追加する（ブロック３２０）。ブロードキャスト５３０は、更新されたリストを次のブロードキャストインターバルでブロードキャストする。受信ユニット５４０は、近隣リストにあるリモートＵＥとのＤ２Ｄ通信を開始する要求側ＵＥから要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）を受信するように構成される。要求は、ターゲットとなるリモートＵＥ３０を識別するための識別情報（例えば、ＵＥ ＩＤ）を含む。転送ユニット５４５は、要求を、要求によって識別されるリモートＵＥ３０に転送するように構成される。

【0155】

図１７Ｃは、リモートＵＥ５００の機能的コンポーネントを示している。図１７Ｃに示される中継ＵＥ５００は、第１の受信ユニット５５０、第１の送信ユニット５５５、第２の受信ユニット５６０、および第２の送信ユニット５６５をさらに備える。様々なユニット５５０～５６５は、１つまたは複数のマイクロプロセッサ、ハードウェア回路、ファームウェア、またはそれらの組合せによって実装されてもよい。第１の受信ユニット５５０は、中継ＵＥ３０によってブロードキャストされたアナウンスメントを受信するように構成される。第１の送信ユニット５５５は、アナウンスメントに応答して、中継ＵＥ３０にＤ２Ｄ通信用の中継としてサーブするよう要求する中継要求を、中継ＵＥ３０に送信するように構成される。第２の受信ユニット５６０は、中継ＵＥ３０を介して、要求側ＵＥ３０から発信される要求（例えば、Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ＲｅｑｕｅｓｔまたはＳｏｌｉｃｉｔａｔｉｏｎメッセージ）を受信するように構成される。第２の送信ユニット５６５は、要求に応答して、応答メッセージ（例えば、Ｒｅｑｕｅｓｔ Ａｃｃｅｐｔメッセージ、またはＳｏｌｉｃｉｔａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ）を、中継ＵＥ３０を介して要求側ＵＥ３０に送信するように構成される。

【0156】

図１８は、別の実施形態によるＵＥ６００を示す。ＵＥ６００は、１つまたは複数のアンテナ６１５、通信回路網６２０、処理回路６６０、およびメモリ６４０を有するアンテナアレイ６１０を備える。

【0157】

通信回路網６２０は、アンテナ６１０に結合され、無線通信チャネルで信号を送受信するために必要な無線周波（ＲＦ）回路網（例えば、送信機（Ｔｘ）６３０および受信機（Ｒｘ）６４０）を備える。処理回路６５０は、メモリ６６０に記憶されたプログラム命令に従ってＵＥ６００の全体的な動作を制御する。処理回路６５０は、１つまたは複数のマイクロプロセッサ、ハードウェア、ファームウェア、またはそれらの組合せを含んでもよい。

【0158】

メモリ６６０は、コンピュータプログラムコードおよび処理回路６５０によって演算に必要とされるデータを記憶するための、揮発性および非揮発性の両方のメモリを含む。メモリ６６０は、データを記憶するための、あらゆる有形で、非一時的なコンピュータ可読記憶媒体を含んでもよく、電子的、磁気的、光学的、電磁気的、または半導体のデータ記憶装置が挙げられる。メモリ６６０は、処理回路６５０が、本明細書で説明されるようにそれぞれ図１０～図１５による方法１００、１５０、２００、２５０、３００、３５０のうちの１つまたは複数を実装するように設定する、実行可能命令を含むコンピュータプログラム６７０を記憶する。この点で、コンピュータプログラム６７０は、上述の手段またはユニットに相当する１つまたは複数のコードモジュールを含んでもよい。一般に、コンピュータプログラム命令および設定情報は、ＲＯＭ、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）またはフラッシュメモリなどの非揮発性メモリに記憶される。演算中に生成される一時的なデータは、ランダムアクセスメモリ（ＲＡＭ）などの揮発性メモリに記憶される場合がある。いくつかの実施形態では、本明細書で説明されるような処理回路６５０を設定するためのコンピュータプログラム６５０は、ポータブルコンパクトディスク、ポータブルデジタルビデオディスク、または他のリムーバブル媒体などのリムーバブルメモリに記憶されてもよい。コンピュータプログラム６７０はまた、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体などのキャリアとして具体化されてもよい。

【0159】

当業者であれば、本明細書における実施形態は、対応するコンピュータプログラムをさらに含むことも諒解されよう。コンピュータプログラムは、装置の少なくとも１つのプロセッサで実行されると、装置に上述の個々の処理のいずれかを実行させる命令を含む。この点で、コンピュータプログラムは、上述の手段またはユニットに相当する１つまたは複数のコードモジュールを含んでもよい。

【0160】

実施形態は、そのようなコンピュータプログラムを含むキャリアをさらに含む。このキャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つを含んでもよい。

【0161】

この点において、本明細書における実施形態はまた、非一時的なコンピュータ可読（記憶または記録）媒体に記憶され、装置のプロセッサによって実行されると、装置を上述のように動作させる命令を含むコンピュータプログラム製品を含む。

【0162】

実施形態は、コンピュータプログラム製品がコンピューティングデバイスによって実行されると、本明細書における実施形態のいずれかのステップを実行するためのプログラムコード部分を含むコンピュータプログラム製品をさらに含む。このコンピュータプログラム製品は、コンピュータ可読記録媒体に記憶されてもよい。

【0163】

次に追加的な実施形態を説明する。これらの実施形態の少なくとも一部は、例証的な目的で、特定のコンテキストおよび／または無線ネットワークタイプに適用可能であるとして説明される場合があるが、実施形態は、明示的に説明されない他のコンテキストおよび／または無線ネットワークタイプに同様に適用可能である。

【0164】

本開示の様々な実施形態を、以下で列挙される実施形態において説明する。実施形態は２つのグループに分けられ、Ｇｒｏｕｐ１およびＧｒｏｕｐと表す。リスト化された実施形態における従属関係は、同一グループにおける先行する実施形態を参照する。

【0165】

Ｇｒｏｕｐ１－中継ディスカバリを伴わないユニキャストリンク確立
１．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信用の要求側ユーザ機器（ＵＥ）によって実装される方法であって、方法は、
リモートＵＥとの通信を開始する直接通信要求を、１つまたは複数の近隣ＵＥへブロードキャストすることであって、直接通信要求が、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションを含む、直接通信要求をブロードキャストすることと、
直接通信要求に応答して、近隣ＵＥのうちの１つまたは複数から要求受け入れメッセージを受信することと
１つまたは複数の要求受け入れメッセージに基づいて、要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信用の通信経路を判定することと
を含む、方法。

【0166】

２．通信経路が、リモートＵＥによって選択され、要求側ＵＥが、
単一要求受け入れメッセージを近隣ＵＥから受信し、
要求受け入れメッセージが受信された近隣ＵＥの識別情報に基づいて通信経路を判定する、実施形態１に記載の方法。

【0167】

３．要求側ＵＥが、中継としてサーブする近隣ＵＥから単一要求受け入れメッセージを受信し、判定された通信経路が、要求側ＵＥから応答側ＵＥへの２つ以上のホップを含む、実施形態２に記載の方法。

【0168】

４．要求側ＵＥが、リモートＵＥから単一要求受け入れメッセージを直接受信し、判定された通信経路が、要求側ＵＥとリモートＵＥとの間の直接通信経路である、実施形態２に記載の方法。

【0169】

５．要求側ＵＥが、
１つまたは複数の近隣ＵＥのそれぞれから要求受け入れメッセージを受信し、
要求側ＵＥによって受信された１つまたは複数の要求受け入れメッセージに基づいて通信経路を選択する、実施形態１に記載の方法。

【0170】

６．ＵＥが、リモートＵＥから要求受け入れメッセージを直接受信すると、ＵＥは要求側ＵＥからリモートＵＥへの直接通信経路を選択する、実施形態５に記載の方法。

【0171】

７．要求側ＵＥが、１つまたは複数の要求受け入れメッセージに含まれる経路選択情報に基づいて通信経路を選択する、実施形態５に記載の方法。

【0172】

８．経路選択情報が、チャネル品質情報、負荷情報、またはデバイス能力情報のうちの少なくとも１つを含む、実施形態７に記載の方法。

【0173】

９．要求側ＵＥが、直接通信要求をブロードキャストした後、予め定められた時間前に受信された要求受け入れメッセージのうちの１つまたは複数に基づいて通信経路を判定する、実施形態１から８のいずれか１つに記載の方法。

【0174】

１０．判定された通信経路を使用してリモートＵＥと通信することをさらに含む、実施形態１から９のいずれか１つに記載の方法。

【0175】

１１．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
サイドリンク上で１つまたは複数の近隣ＵＥと通信するための通信回路網と、
通信回路網に動作可能に接続された処理回路であって、
直接通信要求を、１つまたは複数の近隣ＵＥへブロードキャストすることであって、直接通信要求が、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションを含む、直接通信要求をブロードキャストすることと、
直接通信要求に応答して、近隣ＵＥのうちの１つまたは複数から要求受け入れメッセージを受信することと、
１つまたは複数の要求受け入れメッセージに基づいて、要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信用の通信経路を判定することと
を行うように構成される、処理回路と
を含む、ユーザ機器（ＵＥ）。

【0176】

１２．処理回路が、実施形態２から１０のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態１１に記載のＵＥ。

【0177】

１３．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
直接通信要求を、１つまたは複数の近隣ＵＥへブロードキャストすることであって、直接通信要求が、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションを含む、直接通信要求をブロードキャストすることと、
直接通信要求に応答して、近隣ＵＥのうちの１つまたは複数から要求受け入れメッセージを受信することと、
１つまたは複数の要求受け入れメッセージに基づいて、要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信用の通信経路を判定することと
を行うように構成される、ユーザ機器（ＵＥ）。

【0178】

１４．処理回路が、実施形態２から１０のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態１３に記載のＵＥ。

【0179】

１５．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態１から１０のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラム。

【0180】

１６．実施形態１５に記載のコンピュータプログラムを含むキャリアであって、キャリアが、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである、コンピュータプログラムを含むキャリア。

【0181】

１７．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態１から１０のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラムを含む非一時的なコンピュータ可読記憶媒体。

【0182】

１８．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信を中継するユーザ機器（ＵＥ）によって実装される方法であって、方法は、
リモートＵＥとの通信を開始する要求側ＵＥによってブロードキャストされた直接通信要求を受信することであって、直接通信要求が、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションを含む、直接通信要求を受信することと、
直接通信要求をリモートＵＥに向けて転送することと
を含む、方法。

【0183】

１９．直接通信要求をリモートＵＥに向けて転送することが、直接通信要求を中継インジケーションの値に応じて転送することを含む、実施形態１８に記載の方法。

【0184】

２０．直接通信要求をリモートＵＥに向けて転送することが、直接通信要求についてのＱｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ（ＱｏＳ）要件、ＵＥの負荷、またはＵＥと要求側ＵＥとの間の通信リンクのチャネル品質のうちの少なくとも１つにさらに応じたものになる、実施形態１９、２０、および２２のいずれか１つに記載の方法。

【0185】

２１．ＵＥが、中継インジケーションの値が予め定められた値より大きくなると、直接通信要求を転送する、実施形態１９または２０に記載の方法。

【0186】

２２．中継インジケーションが予め定められた値に等しくなると、直接通信要求を破棄することをさらに含む、実施形態１９から２１のいずれか１つに記載の方法。

【0187】

２３．直接通信要求内の中継インジケーションの値を、直接通信要求を転送することに先立って、予め定められた分デクリメントすることをさらに含む、実施形態１９から２１のいずれか１つに記載の方法。

【0188】

２４．要求側ＵＥとリモートＵＥとの間でＤ２Ｄ通信を中継することをさらに含み、リモートＵＥが判定された通信経路を使用する、実施形態１８から２３のいずれか１つに記載の方法。

【0189】

２５．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
サイドリンク上で１つまたは複数の近隣ＵＥと通信するための通信回路網と、
通信回路網に動作可能に接続された処理回路であって、
リモートＵＥとの通信を開始する要求側ＵＥによってブロードキャストされた直接通信要求を受信することであって、直接通信要求が、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションを含む、直接通信要求を受信することと、
直接通信要求をリモートＵＥに向けて転送することと
を行うように構成される、処理回路と
を含む、ユーザ機器（ＵＥ）。

【0190】

２６．処理回路が、実施形態１９から２４のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態２５に記載のＵＥ。

【0191】

２７．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
リモートＵＥとの通信を開始する要求側ＵＥによってブロードキャストされた直接通信要求を受信することであって、直接通信要求が、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションを含む、直接通信要求を受信することと、
直接通信要求をリモートＵＥに向けて転送することと
を行うように構成される、ユーザ機器（ＵＥ）。

【0192】

２８．処理回路が、実施形態１９から２４のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態２７に記載のＵＥ。

【0193】

２９．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態１８から２４のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラム。

【0194】

３０．実施形態２９に記載のコンピュータプログラムを含むキャリアであって、キャリアが、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである、コンピュータプログラムを含むキャリア。

【0195】

３１．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態１８から２４のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラムを含む非一時的なコンピュータ可読記憶媒体。

【0196】

３２．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信のリモートユーザ機器（ＵＥ）によって実装される方法であって、方法は、
リモートＵＥとの通信を開始する要求側ＵＥによってブロードキャストされた直接通信要求の１つまたは複数の複製を受信することであって、直接通信要求が、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションを含む、要求の複製を受信することと、
直接通信要求の１つまたは複数の複製のそれぞれに応答して、要求側ＵＥに、要求受け入れメッセージを、直接通信要求が受信された通信経路に沿って送信することと
を含む、方法。

【0197】

３３．要求側ＵＥとリモートＵＥとの間のＤ２Ｄ通信用の通信経路を選択することをさらに含む、実施形態３２に記載の方法。

【0198】

３４．直接通信要求の１つまたは複数の複製のそれぞれに応答して、要求受け入れメッセージを送信することが、選択された通信経路に沿って単一要求受け入れメッセージを送信することを含む、実施形態３３に記載の方法。

【0199】

３５．直接通信要求の複数の複製を要求側ＵＥとリモートＵＥとの間の個々の通信経路に沿って受信すること
をさらに含み、
直接通信要求の１つまたは複数の複製のそれぞれに応答して、要求受け入れメッセージを送信することが、複数の要求受け入れメッセージを、通信経路の個々の経路に沿ってＵＥに送信することを含む、実施形態３３に記載の方法。

【0200】

３６．要求受け入れメッセージが、予め定められた時間ウィンドウ内に受信された直接通信要求に応答して送信される、実施形態３２から３５のいずれか１つに記載の方法。

【0201】

３７．要求側ＵＥまたはリモートＵＥによって選択された通信経路のうちの１つを使用してリモートＵＥと通信することをさらに含む、実施形態３２から３６のいずれか１つに記載の方法。

【0202】

３８．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
サイドリンク上で１つまたは複数の近隣ＵＥと通信するための通信回路網と、
通信回路網に動作可能に接続された処理回路であって、
リモートＵＥとの通信を開始する要求側ＵＥによってブロードキャストされた直接通信要求の１つまたは複数の複製を受信することであって、直接通信要求が、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションを含む、要求の複製を受信することと、
直接通信要求の１つまたは複数の複製のそれぞれに応答して、要求側ＵＥに、要求受け入れメッセージを、直接通信要求が受信された通信経路に沿って送信することと
を行うように構成される、処理回路と
を含む、ユーザ機器（ＵＥ）。

【0203】

３９．処理回路が、実施形態３２から３５のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態３８に記載のＵＥ。

【0204】

４０．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
リモートＵＥとの通信を開始する要求側ＵＥによってブロードキャストされた直接通信要求の１つまたは複数の複製を受信することであって、直接通信要求が、要求側ＵＥとリモートＵＥとの間の通信経路に中継が許可されるかどうかを示す中継インジケーションを含む、要求の複製を受信することと、
直接通信要求の１つまたは複数の複製のそれぞれに応答して、要求側ＵＥに、要求受け入れメッセージを、直接通信要求が受信された通信経路に沿って送信することと
を行うように構成される、ユーザ機器（ＵＥ）。

【0205】

４１．処理回路が、実施形態３４から３７のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態４０に記載のＵＥ。

【0206】

４２．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態３１から３７のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラム。

【0207】

４３．実施形態４２に記載のコンピュータプログラムを含むキャリアであって、キャリアが、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである、コンピュータプログラムを含むキャリア。

【0208】

４４．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態３１から３７のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラムを含む非一時的なコンピュータ可読記憶媒体。

【0209】

Ｇｒｏｕｐ２－中継ディスカバリを伴うユニキャストリンク確立
１．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信用の発信側ユーザ機器（ＵＥ）によって実装される方法であって、方法は、
１つまたは複数の中継ＵＥによってブロードキャストされたアナウンスメントを受信することであって、各アナウンスメントが、中継ＵＥから到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む、アナウンスメントを受信することと、
直接通信要求を、自身の近隣リストにリモートＵＥを有する中継ＵＥのうち選択された中継ＵＥに送信することであって、直接通信要求は、ターゲットとなるリモートＵＥを識別するための識別情報を含む、直接通信要求を送信することと、
直接通信要求に応答して、中継ＵＥによって中継されるリモートＵＥから要求受け入れメッセージを受信することと
を含む、方法。

【0210】

２．自身の近隣リストにリモートＵＥを有する近隣ＵＥの１つに直接通信要求を送信することが、
要求側ＵＥからリモートＵＥへの通信経路を選択することであって、通信経路が近隣ＵＥのうちの１つを含む、通信経路を選択することと、
直接通信要求を選択された通信経路上で近隣ＵＥに送信することと
を含む、実施形態１に記載の方法。

【0211】

３．要求側ＵＥからリモートＵＥへの通信経路を選択することが、ＵＥと近隣ＵＥとの間のチャネル品質を示すチャネル品質情報、近隣ＵＥについての負荷情報、または近隣ＵＥについてのデバイス能力情報のうちの１つに少なくとも部分的に基づいている、実施形態１または２に記載の方法。

【0212】

４．アナウンスメントのうちの１つまたは複数が、近隣ＵＥが直接通信要求を受け入れる期間を示す時間パラメータを含む、実施形態１から３のいずれか１つに記載の方法。

【0213】

５．直接通信要求を近隣ＵＥのうちの１つに送信することが、示された期間に直接通信要求を送信することを含む、実施形態４に記載の方法。

【0214】

６．判定された通信経路を使用してリモートＵＥと通信することをさらに含む、実施形態１から５のいずれか１つに記載の方法。

【0215】

７．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
サイドリンク上で１つまたは複数の近隣ＵＥと通信するための通信回路網と、
通信回路網に動作可能に接続された処理回路であって、
１つまたは複数の中継ＵＥによってブロードキャストされたアナウンスメントを受信することであって、各アナウンスメントが、中継ＵＥから到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む、アナウンスメントを受信することと、
直接通信要求を、自身の近隣リストにリモートＵＥを有する中継ＵＥのうち選択された中継ＵＥに送信することであって、直接通信要求は、ターゲットとなるリモートＵＥを識別するための識別情報を含む、直接通信要求を送信することと、
直接通信要求に応答して、中継ＵＥによって中継されるリモートＵＥから要求受け入れメッセージを受信することと、
を行うように構成される、処理回路と
を含む、ユーザ機器（ＵＥ）。

【0216】

８．処理回路が、実施形態２から６のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態７に記載のＵＥ。

【0217】

９．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
１つまたは複数の中継ＵＥによってブロードキャストされたアナウンスメントを受信することであって、各アナウンスメントが、中継ＵＥから到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む、アナウンスメントを受信することと、
直接通信要求を、自身の近隣リストにリモートＵＥを有する中継ＵＥのうち選択された中継ＵＥに送信することであって、直接通信要求は、ターゲットとなるリモートＵＥを識別するための識別情報を含む、直接通信要求を送信することと、
直接通信要求に応答して、中継ＵＥによって中継されるリモートＵＥから要求受け入れメッセージを受信することと、
を行うように構成される、ユーザ機器（ＵＥ）。

【0218】

１０．処理回路が、実施形態２から６のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態９に記載のＵＥ。

【0219】

１１．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態１から６のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラム。

【0220】

１２．実施形態１１に記載のコンピュータプログラムを含むキャリアであって、キャリアが、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである、コンピュータプログラムを含むキャリア。

【0221】

１３．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態１から６のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラムを含む非一時的なコンピュータ可読記憶媒体。

【0222】

１４．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信を中継するユーザ機器（ＵＥ）によって実装される方法であって、方法は、
アナウンスメントを１つまたは複数の近隣ＵＥへブロードキャストすることであって、アナウンスメントが、ＵＥから到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む、アナウンスメントをブロードキャストすることと、
近隣リストにあるターゲットとなるリモートＵＥとのＤ２Ｄ通信を開始する要求側ＵＥから直接通信要求を受信することであって、直接通信要求が、ターゲットとなるリモートＵＥを識別するための識別情報を含む、直接通信要求を受信することと、
直接通信要求を直接通信要求によって識別されるリモートＵＥに転送することと
を含む、方法。

【0223】

１５．
アナウンスメントに応答して、１つまたは複数の中継要求を近隣ＵＥのうちの異なるＵＥから受信することと、
中継要求を送った近隣ＵＥを後続のアナウンスメントのために近隣リストに追加することとをさらに含む、実施形態１４に記載の方法。

【0224】

１６．直接通信要求をリモートＵＥに向けて転送することが、アナウンスメントに続いて予め定められた期間に受信した直接通信要求を転送することを含む、実施形態１４または１５に記載の方法。

【0225】

１７．
直接通信要求に応答して、リモートＵＥから要求受け入れメッセージを受信することと、
要求受け入れメッセージを要求側ＵＥに転送することと
をさらに含む、実施形態１４から１６のいずれか１つに記載の方法。

【0226】

１８．アナウンスメントが、要求側ＵＥからの直接通信要求を受け入れるための期間を示す時間パラメータを含む、実施形態１４から１７のいずれか１つに記載の方法。

【0227】

１９．要求側ＵＥとリモートＵＥとの間でＤ２Ｄ通信を中継することをさらに含む、実施形態１４から１８のいずれか１つに記載の方法。

【0228】

２０．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
サイドリンク上で１つまたは複数の近隣ＵＥと通信するための通信回路網と、
通信回路網に動作可能に接続された処理回路であって、
アナウンスメントを１つまたは複数の近隣ＵＥへブロードキャストすることであって、アナウンスメントが、ＵＥから到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む、アナウンスメントをブロードキャストすることと、
近隣リストにあるリモートＵＥとのＤ２Ｄ通信を開始する要求側ＵＥから直接通信要求を受信することであって、直接通信要求が、ターゲットとなるリモートＵＥを識別するための識別情報を含む、直接通信要求を受信することと、
直接通信要求を直接通信要求によって識別されるリモートＵＥに転送することと
を行うように構成される、処理回路と
を含む、ユーザ機器（ＵＥ）。

【0229】

２１．処理回路が、実施形態１５から１９のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態２５に記載のＵＥ。

【0230】

２２．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
アナウンスメントを１つまたは複数の近隣ＵＥへブロードキャストすることであって、アナウンスメントが、ＵＥから到達可能な１つまたは複数の潜在的なリモートＵＥを識別する近隣リストを含む、アナウンスメントをブロードキャストすることと、
近隣リストにあるリモートＵＥとのＤ２Ｄ通信を開始する要求側ＵＥから直接通信要求を受信することであって、直接通信要求が、ターゲットとなるリモートＵＥを識別するための識別情報を含む、直接通信要求を受信することと、
直接通信要求を直接通信要求によって識別されるリモートＵＥに転送することと
を行うように構成される、ユーザ機器（ＵＥ）。

【0231】

２３．処理回路が、実施形態１５から１９のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態２７に記載のＵＥ。

【0232】

２４．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態１４から１９のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラム。

【0233】

２５．実施形態２４に記載のコンピュータプログラムを含むキャリアであって、キャリアが、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである、コンピュータプログラムを含むキャリア。

【0234】

２６．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態１４から１９のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラムを含む非一時的なコンピュータ可読記憶媒体。

【0235】

２７．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信のユーザ機器（ＵＥ）によって実装される方法であって、方法は、
中継ＵＥによってブロードキャストされたアナウンスメントを受信することと、
アナウンスメントに応答して、中継ＵＥにＤ２Ｄ通信用の中継としてサーブするよう要求する中継要求を、中継ＵＥに送信することと
を含む、方法。

【0236】

２８．
中継ＵＥを介して、要求側ＵＥから発信される直接通信要求を受信することと、
直接通信要求に応答して、中継ＵＥを介して、要求受け入れメッセージを要求側ＵＥに送信することと
をさらに含む、実施形態２７に記載の方法。

【0237】

２９．アナウンスメントが、中継ＵＥが直接通信グループに参加する要求を受け入れる期間を示す時間パラメータを含む、実施形態２８に記載の方法。

【0238】

３０．中継要求を送信することが、アナウンスメントで示された期間に中継要求を送信することを含む、実施形態２９に記載の方法。

【0239】

３１．要求側ＵＥまたはリモートＵＥによって選択された通信経路のうちの１つを使用して要求側ＵＥと通信することをさらに含む、実施形態２７から３０のいずれか１つに記載の方法。

【0240】

３２．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
サイドリンク上で１つまたは複数の近隣ＵＥと通信するための通信回路網と、
通信回路網に動作可能に接続された処理回路であって、
中継ＵＥによってブロードキャストされたアナウンスメントを受信することと、
アナウンスメントに応答して、中継ＵＥにＤ２Ｄ通信用の中継としてサーブするよう要求する中継要求を、中継ＵＥに送信することと
を行うように構成される、処理回路と
を含む、ユーザ機器（ＵＥ）。

【0241】

３３．処理回路が、実施形態２８から３１のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態３２に記載のＵＥ。

【0242】

３４．Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信が可能なユーザ機器（ＵＥ）であって、ＵＥは、
中継ＵＥによってブロードキャストされたアナウンスメントを受信することと、
アナウンスメントに応答して、中継ＵＥにＤ２Ｄ通信用の中継としてサーブするよう要求する中継要求を、中継ＵＥに送信することと
を行うように構成される、ユーザ機器（ＵＥ）。

【0243】

３５．処理回路が、実施形態２８から３１のいずれか１つに記載の方法を実行するようにさらに構成される、実施形態３４に記載のＵＥ。

【0244】

３６．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態２７から３１のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラム。

【0245】

３７．実施形態３６に記載のコンピュータプログラムを含むキャリアであって、キャリアが、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである、コンピュータプログラムを含むキャリア。

【0246】

３８．無線通信ネットワーク内のユーザ機器中の処理回路によって実行されると、ユーザ機器に実施形態２７から３１のいずれか１つに記載の方法を実行させる実行可能命令を含む、コンピュータプログラムを含む非一時的なコンピュータ可読記憶媒体。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8A】

【図8B】

【図8C】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16A】

【図16B】

【図16C】

【図17A】

【図17B】

【図17C】

【図18】