JP6454757B2 - 無線通信システムにおける中継チャネル上のリソース割当ての方法及び装置 - Google Patents

Description

本願は、２０１６年６月６日に出願された米国仮特許出願第６２／３４６，０７４号と、２０１６年６月６日に出願された米国仮特許出願第６２／３４６，１２０号の利益を主張する。それらの全体が参照により本明細書に組み込まれる。

本開示は、一般に無線通信ネットワークに関し、より詳細には、無線通信システムにおける中継チャネル上のリソース割当ての方法及び装置に関する。

モバイル通信機器との間で大量のデータを通信する要求が急速に高まるにつれて、従来のモバイル音声通信ネットワークは、インターネットプロトコル（Internet Protocol，ＩＰ）データパケットと通信するネットワークに進化している。このようなＩＰデータパケット通信は、モバイル通信機器のユーザに、ボイスオーバーＩＰ、マルチメディア、マルチキャスト及びオンデマンド通信サービスを提供することができる。

例示的なネットワーク構造は、進化型ユニバーサル地上無線アクセスネットワーク（Evolved Universal Terrestrial Radio Access Network，Ｅ−ＵＴＲＡＮ）である。Ｅ−ＵＴＲＡＮシステムは、上述したボイスオーバーＩＰ及びマルチメディアサービスを実現するために、高いデータスループットを提供することができる。現在、３ＧＰＰ標準化団体により、次世代（例えば５Ｇ）のための新しい無線技術が議論されている。したがって、現在の３ＧＰＰ規格への変更が現在提出されており、３ＧＰＰ規格を発展させて確定すると考えられている。

無線通信システムにおけるデバイス間中継通信をサポートする第１のＵＥ（User Equipment，ユーザ装置）に関して、方法及び装置が開示される。一実施形態では、本方法は、第１のＵＥが、第２のＵＥからトランスポートブロックを受信するステップであって、トランスポートブロックはＭＡＣ（媒体アクセス制御）制御要素を含む、ステップ、を含む。加えて、本方法は、第１のＵＥがＢＳＲ（Buffer Status Report，バッファステータスレポート）をトリガするステップ、を含む。また、本方法は、第１のＵＥが送信可能なデータを有さず、ＢＳＲ（バッファステータスレポート）の送信のためのアップリンクリソースを有さない場合、第１のＵＥが、ＳＲ（Scheduling Request，スケジューリングリクエスト）をトリガし基地局に送信するステップ、も含む。本方法は更に、第１のＵＥが、ＢＳＲ（バッファステータスレポート）を基地局に送信するステップであって、ＢＳＲは、ＭＡＣ制御要素をバッファサイズの一部とみなす、ステップ、を含む。

一実施例に係る無線通信システムの図を示す。 一実施例に係る送信器システム（アクセスネットワークとしても知られる）及び受信器システム（ユーザ装置又はＵＥとしても知られる）のブロック図である。 一実施例に係る通信システムの機能ブロック図である。 一実施例に係る、図３のプログラムコードの機能ブロック図である。 3GPP TS 23.303 v13.2.0の図４．２−１の複製である。 3GPP TR 22.861 v1.0.0の図５．２−１の複製である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 3GPP TS 36.331 v13.1.0の図５．１０．２−１の複製である。 3GPP TS36.321 v13.1.0の図６．１．３．１ａ−１の複製である。 3GPP TS 36.300 v13.3.0の図１０．１．５．１−１の複製である。 3GPP TS36.321 v13.1.0の表６．２．１−１の複製である。 3GPP TS36.321 v13.1.0の表６．２．１−２の複製である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係るフローチャートである。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係る図である。 一実施例に係るフローチャートである。 一実施例に係るフローチャートである。

以下に説明する例示的な無線通信システム及びデバイスは、ブロードキャストサービスをサポートする無線通信システムを採用する。無線通信システムは、音声、データ等の様々なタイプの通信を提供するために広く展開されている。これらのシステムは、符号分割多元接続（code division multiple access，ＣＤＭＡ）、時分割多元接続（time division multiple access，ＴＤＭＡ）、直交周波数分割多元接続（orthogonal frequency division multiple access，ＯＦＤＭＡ）、3GPP LTE（Long Term Evolution，ロングタームエボリューション）無線アクセス、3GPP LTE-A又はLTE-Advanced（Long Term Evolution Advanced）、3GPP2 UMB（Ultra Mobile Broadband）、WiMaxその他の何らかの変調技術に基づくことができる。

特に、以下に説明される例示的な無線通信システムデバイスは、RP-160677、“New SI：Further Enhancements LTE Device to Device，UE to Network Relays for Wearables”；TS 23.303 v13.2.0，“Proximity-based services(ProSe)-stage2”;TR 22.861 V1.0.0，"Feasibility Study on New Services and Markets Technology Enablers for Massive Internet of Things；Stage 1"；R2-162529，“On Scenarios and Objectives for Wearables and feD2D”，Ericsson；RP-160183，“NB-IOT Status Report to TSG”；TR 23.720 v13.0.0，“Architecture enhancements for Cellular Internet of Things”；TS 36.213 v13.1.1，“E-UTRA：Physical Layer procedures”；TS 36.212 v13.1.0，“E-UTRA：Multiplexing and channel coding”；TS 36.211，“E-UTRA：Physical channels and modulation”；TS 36.211 v13.1.0，“E-UTRA：Physical channels and modulation”；TS 36.321 v13.1.0，“E-UTRA：Medium Access Control(MAC) Protocol Specification”；TS 24.334 v13.3.1，“Proximity-services (ProSe) User Equipment (UE) to ProSe function protocol aspects；Stage 3”；R2-163056，“Report from LTE Break-Out Session (V2V，V2X，FeD2D，LATRED)”；TS 36.331 v13.1.0，“E-UTRA RRC protocol specification”；TS 36.322 v13.0.0，“E-UTRA RLC protocol specification”；TS 36.323 v13.0.0，“E-UTRA PDCP protocol specification”等の、３ＧＰＰと呼ばれる「第３世代パートナーシップ・プロジェクト」というコンソーシアムによって提供される１つ以上の規格をサポートするように設計されてよい。上記の規格及び文書は、参照によりその全体が本明細書に明確に組み込まれる。

図１は、本発明の一実施形態に係る多元接続無線通信システムを示す。アクセスネットワーク１００（ＡＮ）は複数のアンテナグループを含み、１０４及び１０６を含むグループと、１０８及び１１０を含む別のアンテナグループと、１１２及び１１４を含む追加のアンテナグループとを含む。図１では、アンテナグループごとに２つのアンテナしか示されていないが、各アンテナグループに対して利用されるアンテナの数は、より多くても少なくてもよい。アクセス端末１１６（ＡＴ）は、アンテナ１１２及び１１４と通信する。アンテナ１１２及び１１４は、順方向リンク１２０を介してアクセス端末１１６に情報を送信し、逆方向リンク１１８を介してアクセス端末１１６から情報を受信する。アクセス端末（ＡＴ）１２２は、アンテナ１０６及び１０８と通信する。アンテナ１０６及び１０８は、順方向リンク１２６を介してアクセス端末（ＡＴ）１２２に情報を送信し、逆方向リンク１２４を介してアクセス端末（ＡＴ）１２２から情報を受信する。ＦＤＤシステムでは、通信リンク１１８，１２０，１２４，１２６は、通信のために異なる周波数を用いてよい。例えば、順方向リンク１２０は、逆方向リンク１１８によって用いられる周波数とは異なる周波数を用いてよい。

アンテナの各グループ及び／又はそれらが通信するように設計されているエリアは、アクセスネットワークのセクタと呼ばれることがある。この実施形態では、各アンテナグループは、アクセスネットワーク１００によってカバーされるエリアのセクタ内のアクセス端末に通信するように設計される。

順方向リンク１２０及び１２６を介した通信において、アクセスネットワーク１００の送信アンテナは、異なるアクセス端末１１６及び１２２に対する順方向リンクの信号対雑音比を改善するためにビームフォーミングを利用してよい。また、アクセスネットワークがビームフォーミングを用いて、そのカバレッジを通じてランダムに散在したアクセス端末に送信することにより、単一のアンテナを介してその全てのアクセス端末に送信するアクセスネットワークよりも、隣接セルのアクセス端末への干渉が低減される。

アクセスネットワーク（ＡＮ）は、端末と通信するために用いられる固定局又は基地局であってよく、アクセスポイント、ノードＢ、基地局、拡張基地局、進化型ノードＢ（ｅＮＢ）その他の何らかの用語で称されてもよい。アクセス端末（ＡＴ）は、ユーザ装置（ＵＥ）、無線通信機器、端末、アクセス端末、その他の何らかの用語で称されてもよい。

図２は、ＭＩＭＯシステム２００における送信器システム２１０（アクセスネットワークとしても知られる）及び受信器システム２５０（アクセス端末（ＡＴ）又はユーザ装置（ＵＥ）としても知られる）の実施形態の簡略ブロック図である。送信器システム２１０では、多数のデータストリームのトラフィックデータがデータソース２１２から送信（ＴＸ）データプロセッサ２１４に提供される。

一実施形態では、各データストリームは、それぞれの送信アンテナを介して送信される。ＴＸデータプロセッサ２１４は、符号化データを提供するためにそのデータストリームに対して選択された特定の符号化方式に基づいて、各データストリームのトラフィックデータをフォーマットし、符号化し、インターリーブする。

各データストリームの符号化データは、ＯＦＤＭ技術を用いてパイロットデータと多重化されてよい。パイロットデータは、通常、既知の方式で処理される既知のデータパターンであり、チャネル応答を推定するために受信器システムで用いられてよい。各データストリームの多重化されたパイロット及び符号化データは、そのデータストリームに対して選択された特定の変調方式（例えば、ＢＰＳＫ、ＱＰＳＫ、Ｍ−ＰＳＫ、又はＭ−ＱＡＭ）に基づいて変調（すなわちシンボルマッピング）されて、変調シンボルを提供する。各データストリームのデータレート、符号化及び変調は、プロセッサ２３０によって実行される命令によって決定されてよい。

全てのデータストリームのための変調シンボルはＴＸ ＭＩＭＯプロセッサ２２０に提供され、ＴＸ ＭＩＭＯプロセッサ２２０は更に、（例えばＯＦＤＭのための）変調シンボルを処理してよい。ＴＸ ＭＩＭＯプロセッサ２２０は、Ｎ_Ｔ個の変調シンボルストリームをＮ_Ｔ個の送信器（ＴＭＴＲ）２２２ａ〜２２２ｔに提供する。特定の実施形態では、ＴＸ ＭＩＭＯプロセッサ２２０は、データストリームのシンボルと、シンボルが送信されているアンテナとに、ビームフォーミング重みをかける。

各送信器２２２は、それぞれのシンボルストリームを受信して処理して、１つ以上のアナログ信号を提供し、更に、アナログ信号を調整（例えば増幅、フィルタリング及びアップコンバート）して、ＭＩＭＯチャネルを介した送信に適した変調信号を提供する。送信器２２２ａ〜２２２ｔからのＮ_Ｔ個の変調信号は、それぞれＮ_Ｔ個のアンテナ２２４ａ〜２２４ｔから送信される。

受信器システム２５０では、送信される変調信号は、Ｎ_Ｒ個のアンテナ２５２ａ〜２５２ｒによって受信され、各アンテナ２５２からの受信信号は、それぞれの受信器（ＲＣＶＲ）２５４ａ〜２５４ｒに提供される。各受信器２５４は、それぞれの受信信号を調整（例えばフィルタリング、増幅及びダウンコンバート）し、調整された信号をデジタル化してサンプルを提供し、更に、サンプルを処理して対応する“受信”シンボルストリームを提供する。

次に、ＲＸデータプロセッサ２６０は、特定の受信器処理技術に基づいて、Ｎ_Ｒ個の受信器２５４からのＮ_Ｒ個の受信シンボルストリームを受信及び処理して、Ｎ_Ｔ個の“検出される”シンボルストリームを提供する。次いで、ＲＸデータプロセッサ２６０は、検出された各シンボルストリームを復調し、デインターリーブし、復号して、データストリームのトラフィックデータを復元する。ＲＸデータプロセッサ２６０による処理は、送信器システム２１０におけるＴＸ ＭＩＭＯプロセッサ２２０及びＴＸデータプロセッサ２１４によって実行される処理と相補的である。

プロセッサ２７０は、どのプリコーディング行列を用いるかを周期的に決定する（後述する）。プロセッサ２７０は、行列インデックス部分とランク値部分とを含む逆方向リンクメッセージを定式化する。

逆方向リンクメッセージは、通信リンク及び／又は受信データストリームに関する様々なタイプの情報を含んでよい。次に、逆方向リンクメッセージは、ＴＸデータプロセッサ２３８によって処理され（また、ＴＸデータプロセッサ２３８は、データソース２３６からの多数のデータストリームのトラフィックデータを受信する）、変調器２８０によって変調され、送信器２５４ａ〜２５４ｒによって調整され、送信器システム２１０に返送される。

送信器システム２１０では、受信器システム２５０からの変調信号は、アンテナ２２４によって受信され、受信器２２２によって調整され、復調器２４０によって復調され、ＲＸデータプロセッサ２４２によって処理されて、受信器システム２５０によって送信された予約リンクメッセージを抽出する。次に、プロセッサ２３０は、ビームフォーミング重みを決定するためにどのプリコーディング行列を用いるかを決定し、抽出されたメッセージを処理する。

図３を参照する。この図は、本発明の一実施形態に係る通信機器の、代替の簡略機能ブロック図を示す。図３に示されるように、無線通信システムにおける通信機器３００は、図１のＵＥ（或いはＡＴ）１１６，１２２又は図１の基地局（或いはＡＮ）１００を実現するために利用することができ、無線通信システムは、好ましくはＬＴＥシステムである。通信機器３００は、入力装置３０２、出力装置３０４、制御回路３０６、中央処理装置（ＣＰＵ）３０８、メモリ３１０、プログラムコード３１２及び送受信器３１４を備えてよい。制御回路３０６は、ＣＰＵ３０８を介してメモリ３１０内のプログラムコード３１２を実行することにより、通信機器３００の動作を制御する。通信機器３００は、キーボードやキーパッド等の入力装置３０２を介してユーザによって入力された信号を受信し、モニタやスピーカ等の出力装置３０４を介して画像及び音声を出力することができる。送受信器３１４は、無線信号を受信及び送信し、受信信号を制御回路３０６に送り、制御回路３０６によって生成された信号を無線で出力するために用いられる。無線通信システムにおける通信機器３００は、図１のＡＮ１００を実現するために利用することもできる。

図４は、本発明の一実施形態に係る、図３に示されるプログラムコード３１２の簡略ブロック図である。本実施形態では、プログラムコード３１２は、アプリケーションレイヤ４００、Ｌａｙｅｒ３部分４０２及びＬａｙｅｒ２部分４０４を含み、Ｌａｙｅｒ１部分４０６に結合される。Ｌａｙｅｒ３部分４０２は、一般に無線リソース制御を実行する。Ｌａｙｅｒ２部分４０４は、一般にリンク制御を実行する。Ｌａｙｅｒ１部分４０６は、一般に物理的接続を実行する。

3GPP RP-160677では、ＵＥ‐ネットワーク間の中継を更に強化するための新しい検討事項が導入されている。検討事項に関して、ＩｏＴ（Internet of Things、モノのインターネット）及びウェアラブルデバイスの電力消費を最適化するためにＩｏＴデバイス及び／又はウェアラブルデバイスからのトラフィックを中継するには、ＵＥ‐ネットワーク間の中継を強化する必要がある。ＳＩを仮定すると、ＩｏＴ及びウェアラブルデバイスは、ｅＮＢとＩｏＴ／ウェアラブルデバイス間のＤ２Ｄリンクとを接続するための基本的なＬＴＥ機能を備える。UE-to-Network Relayは、ＰＣ５（Ｓｉｄｅｌｉｎｋ）インタフェース、Ｂｌｕｅｔｏｏｔｈ（登録商標）又はＷｉＦｉとすることができる。

特に、3GPP RP-160677は、次のように述べている。

３ 妥当性
プロキシミティベースサービスの検討（［TR 22.803］でキャプチャされた）は、互いに近接しているＵＥに基づいて３ＧＰＰ ＬＴＥシステムによって提供され得る使用事例及びシナリオを特定した。特定されたシナリオには、［TS 22.278］に文書化されている一般及び公共安全（General and Public Safety）サービスと要件が含まれた。

Proximity Servicesを有効にすることに関する標準的なＲＡＮ作業は、Public Safetyアプリケーションを中心にLTE Rel12 [RP-140518]で開始された。LTE Rel.12では、以下の主要機能が標準化された。

・ネットワークカバレッジでのデバイス間検出（商用とPublic Safetyの両方の使用事例）。

・主にPublic Safetyの使用事例を対象とした、ネットワークカバレッジ内／一部及び外のシナリオでのグループキャスト及びユニキャスト通信をサポートする上位レイヤによる、デバイス間ブロードキャスト通信。

Public Safetサービスに関する作業はLTE Rel.13［RP-150441］で継続され、部分的及び外的なネットワークカバレッジシナリオのためのタイプ1検出と、LTE Rel.12 Ｄ２Ｄ通信を再利用するＬ３ベースのＵＥ‐ネットワーク間中継と、Ｄ２Ｄ通信のための基本的な優先順位処理メカニズムとが可能となった。

低コストＭＴＣデバイスの接続及び管理にＬＴＥ技術を使用することには、多くの関心が寄せられている。このような低コストのデバイスの重要な例のひとつはウェアラブル機器であり、中継装置として機能することのできるスマートフォンにほぼ常に近接しているという利点もある。このＳＩでは、非３ＧＰＰ短距離技術を含むＤ２Ｄの、係るデバイスへの応用を検討することを目指す。特に、Ｄ２Ｄ支援ウェアラブル及びＭＴＣアプリケーションを可能にするために、ＬＴＥ技術において更に強化される２つの主要な側面がある。

・ＵＥ‐ネットワーク間中継機能の強化。ProSeにおけるＵＥ‐ネットワーク間中継アーキテクチャは、アクセスレイヤにおいて、リモートＵＥのトラフィックをリレーＵＥのトラフィックと区別しない。このモデルは、課金又はセキュリティのために、リモートＵＥを別個のデバイスとして扱うネットワーク及びオペレータの機能を制限する。特に、３ＧＰＰセキュリティアソシエーションは、ネットワークとリモートＵＥとの間でエンドツーエンドに到達することはなく、これは、リレーＵＥがリモートＵＥの通信に対するクリアテキストアクセスを有することを意味する。ＵＥ‐ネットワーク間の中継は、中継リンク、サービス継続性、Ｅ２Ｅ ＱｏＳ（可能であれば）、複数のリモートＵＥとの効率的な運用、ＵｕとＤ２Ｄのエアインタフェース間の効率的なパススイッチングを介して、エンドツーエンドのセキュリティをサポートするように、強化される必要がある。Ｄ２Ｄを用いる中継は、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＷｉ−Ｆｉ等の非３ＧＰＰ技術に基づくこともできる。サービス継続性等のいくつかの拡張により、商用の使用事例において、そのような技術に対して中継をより魅力的にすることができる。これは、ユーザのスマートフォンに近接した使用パターンや、直接的なＵｕ接続をより実用性の低いものにし得るフォームファクタの制限（バッテリサイズの制限等）により、ウェアラブルに特に有用であり得る。中継は、（そのトラフィックを中継している）リモートＵＥに対して大幅な電力節約を可能にすることができる。これは、特に深いカバレッジのシナリオに当てはまる。中継を導入するコスト効果の高い方法のひとつは、リモートデバイスとリレーデバイス間の単方向Ｄ２Ｄリンクを用いることである。この場合、リレーＵＥは、リモートＵＥからのアップリンクデータのみを中継するために利用される。このアプローチの利点は、Ｄ２Ｄ受信のための追加のＲＦ機能がリモートＵＥに追加されないことである。

・信頼性の高いユニキャストＰＣ５リンクを実現して、低電力、低レート、低複雑性／低コストのデバイスを少なくともサポートするための強化。低コストのＤ２Ｄデバイスは、ＮＢ−ＩｏＴ（Narrow Band−IoT、狭帯域ＩｏＴ）及びｅＭＴＣの研究中に開発されたアイデアを再利用することで可能になり、例えば、ＮＢ−ＩｏＴ／ｅＭＴＣアップリンク波形をＤ２Ｄに再利用することができる。そのようなデバイスは、インターネット/クラウドと通信し近位デバイスと通信するために、潜在的に単一のモデムを使用する。公衆安全の使用事例によって推進されるブロードキャスト指向設計から継承された現在のＰＣ５リンク設計は、リンク適応及びフィードバック機構の欠如により、低電力且つ信頼性の高いＤ２Ｄ通信を妨げるボトルネックとなる。このような欠点により、電力消費、スペクトル効率及びデバイスの複雑さに関して、ウェアラブル及びＭＴＣの使用事例の目標性能メトリックを達成することができない。消費電力の低減と低い複雑さは、小さいフォームファクタと長時間のバッテリ寿命を通常特徴とするウェアラブル及びＭＴＣの使用事例の重要な特質である。

この検討事項は、ウェアラブル及びＭＴＣ適用に焦点を当てたＤ２Ｄ支援サービスのために、拡張されたＵＥ‐ネットワーク間中継の利点を評価及び検討し、ＬＴＥサイドリンクエアインタフェースの拡張形式を使用することを目的とする。このような使用事例を可能にするために、様々なデータレートをサポートするエネルギー効率の高い通信用に、サイドリンクエアインタフェースを最適化する必要がある。

４ 目的
４．１ ＳＩ又はコアパートＷＩ又はテストパートＷＩの目的
ＲＡＮ＃７２までは、ＳＡ ＷＧの進捗状況を考慮してＲＡＮ２のシナリオを評価し、それに応じて目的を絞り込む
［この検討事項の目的は、ウェアラブルの使用事例を対象とした適用のために、ＵＥ‐ネットワーク間中継及びＬＴＥ Ｄ２Ｄフレームワークの強化を検討することである。リモートＵＥが、ＷＡＮとＤ２Ｄ接続の両方をサポートでき、リモートＵＥが３ＧＰＰサブスクリプションの認証情報をもつと想定される。Ｄ２Ｄ接続は、ＬＴＥサイドリンク又は非３ＧＰＰ技術のいずれかによって実現される。ＬＴＥ Ｄ２Ｄの強化については、商用（カバレッジ内のシナリオ）及び公衆安全のケース（カバレッジ内とカバレッジ外のシナリオの両方）のライセンススペクトルを対象としている。］以下は目標のリストである。

１．ネットワークがリレーＵＥを介してリモートＵＥを識別、アドレス及び到達する方法を含む、一般のＵＥ‐ネットワーク間中継アーキテクチャを検討及び定義する［ＲＡＮ２］
ａ．次の使用事例をサポートする共通の解決策の可能性を検討する［ＲＡＮ２］
ｉ．非３ＧＰＰアクセスを介するＵＥ‐ネットワーク間中継（Ｂｌｕｅｔｏｏｔｈ（登録商標）／ＷｉＦｉ）：Ｅ２Ｅ ＱｏＳは保証されない可能性がある
ｉｉ．ＬＴＥサイドリンクを介するＵＥ‐ネットワーク間中継：Ｅ２Ｅ ＱｏＳ規格の影響を評価する
ｉｉｉ．単方向性及び双方向性のＵＥ‐ネットワーク間中継
ｂ．認証、接続セットアップ、ＵＥモビリティ、パラメータ設定、セキュリティ等のプロトコルスタック、プロシージャ及びシグナリングメカニズムへの潜在的な影響を調査し、リレーＵＥを介して複数のリモートＵＥを許可する［ＲＡＮ２、ＲＡＮ３］
ｃ．セルラリンク（Ｕｕエアインタフェース）とリレーリンクとの間のパス選択／スイッチ、及び、サービス継続性を提供する［ＲＡＮ２、ＲＡＮ３］
２．必要なＬＴＥサイドリンクの強化を検討する
ａ．ウェアラブル使用事例の分析に焦点を当てたＴＲ ３６．８４３で定義されているサイドリンク評価方法論に追加の評価仮定を導入する［ＲＡＮ１］
ｂ．より効率的で、信頼性が高く、且つ／又は低い複雑性／コストと低エネルギーのサイドリンクを可能にするメカニズムを特定する［ＲＡＮ１、ＲＡＮ２、ＲＡＮ４］
ｃ．特定された新しいメカニズムにより生じ得る隣接キャリア周波数との追加の共存問題を検討する［ＲＡＮ４］
この作業では、ＦＤＤ、Ｈ−ＦＤＤ、ＴＤＤを考慮する必要がある。他のセルラサービスのセルラトラフィック、スペクトル及びＱｏＳに対するサイドリンク動作の影響は、ネットワークによって完全に制御されると想定される
この検討では、関連要件に対する潜在的なＳＡ１作業の成果を考慮する予定である。この検討に必要と思われる場合は、ＳＡ ＷＧに相談する。目的の一部は、ＳＩ完成日よりも早く締結することができる］
近接サービス、すなわちProSe（Proximity-based Service）又はＤ２Ｄ（Device to Device）の機能性及びインタフェースは、３ＧＰＰ ＴＳ２３．３０３において次のように紹介され、論議されている。

４．２ アーキテクチャ参照モデル
図４．２−１は、非ローミングアーキテクチャの概要を示す。図中、ＵＥ Ａ及びＵＥ Ｂは同じＰＬＭＮのサブスクリプションを使用する。

［「非ローミング参照アーキテクチャ」と題される３ＧＰＰ ＴＳ ２３．３０３ ｖ１３．２．０の図４．２−１は、図５のように再現される］
次の図４．２−２は、非ローミングＰＬＭＮ間アーキテクチャの概要を示す。図中、ＰＬＭＮ ＡはＵＥ ＡのＨＰＬＭＮであり、ＰＬＭＮ ＢはＵＥ ＢのＨＰＬＭＮである。

このＳＩの主なシナリオは、３ＧＰＰ ＴＲ２２．８６１ ｖ１．０．０においてこれまでに検討されており、以下のように引用されている。これは、直接３ＧＰＰ接続と、間接３ＧＰＰ接続（例えば、スマートフォンを介して３ＧＰＰネットワークと通信するスマートウェアラブル）と、直接デバイス接続（例えば、他のバイオメトリックデバイス又は同じ患者に関連付けられたスマートフォンと直接通信するバイオメトリックデバイス）とを含む、３つの接続モデルをカバーする。根本的な前提は、ほとんどの場合、ウェアラブル／ＩＯＴデバイスが、中継装置の近接を利用することにより、中継モードで動作できることである。まれに（中継装置に接近していない場合）、セルラ接続を用いて３ＧＰＰネットワークと直接通信することもできる。また、中継装置とのＤ２Ｄ通信は、３ＧＰＰ技術（例えばサイドリンク）又は非３ＧＰＰ接続技術（例えばＷＬＡＮ）のいずれかを用いて実行することができると仮定される。

特に、３ＧＰＰ ＴＲ ２２．８６１ ｖ１．０．０は次のように述べている。

５．２ 接続の態様
５．２．１ 説明
［２］のSmart Wearables及びBio-Connectivity関連の使用事例で説明したように、Internet of Thingsは様々な接続モデルをサポートする。デバイスは、ネットワークに直接接続することも、別のデバイスをリレーＵＥとして用いてネットワークに接続することもでき、両方のタイプの接続を用いることもできる。デバイスは、スマートウォッチや衣類に埋め込まれたセンサのセット等のシンプルなウェアラブルから、バイオメトリクスをモニタリングするより高度なウェアラブルデバイスまで、多岐にわたることができる。また、それらは、家電製品（例えば、スマートサーモスタット及びエントリーキー）のセット等のパーソナルエリアネットワーク、又はオフィス設定の電子デバイス（例えばスマートプリンタ、又はプラントに水を供給するように遠隔で作動させることができるスマートフラワーポットで通信する、非ウェアラブルデバイスであってもよい。基本的に、以下の接続モデルのうちの１つ以上が任意のデバイスに適用される。図５．２−１に接続モデルを示す。

・直接３ＧＰＰ接続（例えば、３ＧＰＰネットワークを介してアプリケーションサーバ又は別のデバイスと通信するセンサ）
・間接３ＧＰＰ接続（例えば、スマートフォンを介して３ＧＰＰネットワークに通信するスマートウェアラブル）
・直接デバイス接続（例えば、他のバイオメトリックデバイス又は同じ患者に関連付けられたスマートフォンと直接通信するバイオメトリックデバイス）
接続シナリオでは、３ＧＰＰ及び非３ＧＰＰ ＲＡＴがサポートされてよい。接続シナリオでは、ライセンス帯域又は非ライセンス帯域での３ＧＰＰ ＲＡＴがサポートされてよい。

［３ＧＰＰ ＴＲ ２２．８６１ ｖ１．０．０の図５．２−１、「接続性の概要」と題される図は、図６のように再現される。］
サイドリンク共有チャネルとサイドリンク制御チャネルに関連するＵＥ手順は、それぞれ３ＧＰＰ ＴＳ ３６．２１２ ｖ１３．１．１のセクション１４．１と１４．２に記載されている。

一般に、本発明は、ＰＣ５インタフェースを介してリソース割振りに関連する問題を処理することである。Ｒ１３ ProSe通信におけるリソーススケジューリングに関して、ＵＥは、sidelinkUEInformationメッセージを基地局に送信した後に、モード１又はモード２のいずれか（例えば、それぞれスケジュールベースとコンテンションベース）でサイドリンクリソースを用いるように構成される。サイドリンクリソースがスケジューリングベースで構成される場合、ＵＥは、Ｕｕインタフェースを介してサイドリンクリソースを要求し、Ｕｕインタフェースを介してＰＤＣＣＨ（物理ダウンリンク制御チャネル）上でＳＬ−グラントを取得するために、ＳＬ−ＢＳＲ（サイドリンクバッファステータスレポート）等のバッファステータスレポートを送信する。しかしながら、このメカニズムは、消費電力要件のためにＲ１４で調整することができる。問題及び解決策を導入する前に、制御プレーン及びユーザプレーンの潜在的な伝送モデルが分析される。

仮定１：３ＧＰＰ Ｒ２−１６２５２９では、制御プレーンとユーザプレーンの伝送モデルがいくつか提案されている。３ＧＰＰ ＲＰ−１６０１８３で論じられているＮＢ−ＩＯＴ ＷＩ合意を考慮すると、３ＧＰＰ ＴＲ ２３．７２０ ｖ１３．０．０ではＣＰ（制御プレーン）及びＵＰ（ユーザプレーン）ソリューションが定義され、ＣＰソリューションは必須であり、小規模なデータ伝送のために提案される。ＣＰソリューションでは、データはＮＡＳ（Non-Access Stratum、非アクセス層）ＰＤＵ（Protocol Data Unit、プロトコルデータユニット）として搬送される。シグナリングがＵｕインタフェースを介して配信される場合、データはＵｕインタフェースを介して送信され、エネルギーは保存されない。したがって、少なくともアップリンクシグナリング及びアップリンクデータについては、エネルギー節約のために中継リンクを介して配信されると仮定する。深いカバレッジホール内のリモートＵＥを考えると、より多くのＵｕリソースを消費するカバレッジ向上のために、より多くの反復が必要である。一般的な解決策として、ＳＩＢ／ＰＳＳ／ＳＳＳ／ページングが依然としてＵｕインタフェースを介して配信されている間に適切なリレーＵＥが選択された場合、全てのシグナリング及びデータが中継リンクを介して配信されると仮定する。想定される伝送モデルは図７に示され、制御プレーンとユーザプレーンを搬送するために中継リンクを用いている。

仮定２：上記の仮定１に基づいて、ＳＬ−ＢＳＲは中継リンクを介して送信されるものと仮定する。ＳＬ−ｇｒａｎｔに関して、Ｕｕインタフェースを介してＰＤＣＣＨ上で依然として送信される場合、ＵＥは、ＳＩＢ／ページングに加えてＰＤＣＣＨをモニタする必要があり、拡張カバレッジモードにある可能性がある。電力効率を向上させるために、図８（ｂ）のように、中継リンクを介してＳＬ−ｇｒａｎｔ（サイドリンクリソース割振り）が配信されると仮定する。したがって、第１のＳＬ−ｇｒａｎｔは、Ｕｕを介してｅＮＢからリレーＵＥに送信され、リレーＵＥは、ＰＣ５を介して第２のＳＬ−ｇｒａｎｔをリモートＵＥに送信する。特に、ｅＮＢからリレーＵＥに送信される第１のＳＬ−ｇｒａｎｔが、リレーＵＥからリモートＵＥに送信される第２のＳＬ−ｇｒａｎｔと同じであることは、想定も示唆もしない。

課題１と解決策：図９にされるレガシーＲ１３サイドリンク伝送では、ｅＮＢは、Ｕｕインタフェースを介してＵＥにＳＬ−ｇｒａｎｔ（例えばＤＣＩ５）を送信し、ＵＥは、次のＳＣ期間にＳＬ−ｇｒａｎｔを用い、ＳＣＩ０をＳＡプールに送信するとともに、ＳＣＩで指定されたサイドリンクリソースで伝送を行う。リモートＵＥはＳＡプールをモニタして、このＳＣ期間にデータを受信すべきか否かを決定する。サイドリンク伝送の詳細な動作は、３ＧＰＰ ＴＳ ３６．２１３に定義される。また、ＤＣＩ５とＳＣＩ０との関係は、例示的な図１０に示される。

ＳＬ−ｇｒａｎｔがあるときはいつでも、リモートＵＥはＬＣＰ（Logical Channel Prioritization、論理チャネル優先順位付け）を実行するようであり、リレーＵＥはＬＣＰの結果を知ることは期待されない。すなわち、リレーＵＥは、ＳＬ−ｇｒａｎｔに定義されたサイドリンクリソースが、図１１に示されるケース（ａ）又はケース（ｂ）に用いられることを知らない。上記の仮定に基づき、サイドリンクリソース付与をリモートＵＥに配信するためのメカニズムがここに提案され、存在する動作への影響を最小限に抑えることも期待される。すなわち、１）ｅＮＢはＵｕインタフェース上でＳＬ−ｇｒａｎｔ（ＤＣＩ０等）をリレーＵＥに送信し、２）ＳＬ−ｇｒａｎｔが次のＳＣ期間に用いられ、３）ターゲットＵＥがＳＡプールをモニタして、彼のためのトラフィックが存在するか否かを決定する。したがって、本発明は、一般に、図１２に示されるワークフローを設計することである。

図１２では、ｅＮＢは、Ｒ１３ ＳＬ−ｇｒａｎｔとは異なる方法、例えば、異なるＳＬ−ＲＮＴＩ（Sidelink Radio Network Temporary Identifier、サイドリンク無線ネットワーク臨時識別子）を用いて、ＤＣＩ０をリレーＵＥに送信する。リレーＵＥは、ＳＬ−ｇｒａｎｔが１つのリモートＵＥに対するものであること、又はＳＬ−ｇｒａｎｔを復号するためにそれがどの方法によって用いられるのかを知る。ＳＬ−ｇｒａｎｔがリモートＵＥに対するものである場合、次のＳＣ期間において、４つの送信機会がＳＡプールで定義される。前の２回の送信機会は、リレーＵＥが新しいＳＣＩフォーマット（図１２のＳＣＩ１等）であるサイドリンクリソース付与をリモートＵＥに送信するためであり、後の２回の送信機会は、リモートＵＥがＳＣＩ０を送信するためである。その後、リモートＵＥは、図１２の第３のＵＥとして、ＳＣ期間でターゲットＵＥへのトランスポートブロック送信を実行する。ターゲットＵＥは、リレーＵＥその他のＵＥであってよい。

一実施形態では、ｅＮＢは、第１のサイドリンクリソース付与を第１のＵＥに送信する。第１のサイドリンクリソース付与は、第１のサイドリンクリソース付与で定義されたサイドリンクリソースが第１のＵＥの使用のためであるか否かを第１のＵＥに伝えるための第１の情報を搬送する。第１の情報は識別子であってよい。更に、第１の情報はＲＮＴＩであり、ＲＮＴＩは第１のサイドリンクリソース付与をスクランブルするために用いられる。加えて、第１の情報はフラグであってよい。

具体的には、第１のサイドリンクリソース付与で定義されたサイドリンクリソースが第１のＵＥの使用のためである場合、次のＳＣ期間のＳＡプールに定義される２回の送信機会がある。そうでなければ、第１のサイドリンクリソース付与で定義されたサイドリンクリソースが第１のＵＥの使用のためでない場合、次のＳＣ（Sidelink Control、サイドリンク制御）期間のＳＡ（Scheduling Assignment、スケジューリング割当て）プールで定義される２回以上の送信機会（例えば４回の送信機会）が存在する。後者の場合、第１のＵＥは、ＳＡプールの前の２回の送信機会において、或いは、第２のＵＥへのＳＡプールの前の制御信号のための別のリソースプールにおいて、第２のサイドリンクリソース付与を送信する。具体的には、第１のサイドリンクリソース付与のフォーマットは、第２のサイドリンクリソース付与のフォーマットと同じではない。第２のＵＥは、第２のサイドリンクリソース付与を受信し、ＳＡプールの後の２回の送信機会に関するサイドリンクリソース制御情報を送信し、サイドリンクリソース制御情報に定義されたサイドリンクリソース上でトランスポートブロック送信を行う。トランスポートブロック送信の受信器は、複数のＵＥである。また、複数のＵＥは、第１のＵＥを含んでも含まなくてもよい。特に、第２のサイドリンクリソース付与のフォーマットは、サイドリンクリソース制御情報のフォーマットと同じではない。サイドリンクリソース制御情報はＳＣＩ０である。

課題２とソリューション
仮定３：ＳＬ−ｇｒａｎｔが特定のリモートＵＥに送信されることが決定された場合、この目的のために新しいＳＣＩフォーマットが必要となり、例えば、リレーＵＥからＰＣ５インタフェースを介してリモートＵＥへのサイドリンクリソースを割り当てる。基本的に、新しいＳＣＩフォーマットの長さがＳＣＩ０の長さと等しくない場合、ブラインド復号化の候補が多いために復号化の複雑さが増す。ＩｏＴデバイスが潜在的に低コストであり、複雑性が低いことが予想されることを考慮して、新しいＳＣＩフォーマットの長さはＳＣＩ０の長さと同じであると仮定する。しかしながら、新しいＳＣＩフォーマットの詳細／設計は、本発明に含まれない。更に、新しいＳＣＩフォーマットは、リレーＵＥにデータを送信するためにリモートＵＥに対してのみサイドリンクリソースを割り当てると仮定し、これは最も一般的なケースで有り得る。

上記の仮定に基づいて、ＳＬ−ｇｒａｎｔ（例えば、新しいＳＣＩフォーマットにおける）がリモートＵＥに送信されると、リモートＵＥは、これがＳＣＩ０ではなく新しいＳＣＩフォーマットであることをどのように知るのだろうか。従来のＲ１３サイドリンク制御チャネルでは、ＳＣＩ０のスクランブリングシーケンスは、以下の説明におけるＳＳ０（Scrambling sequence 0、スクランブリングシーケンス０）等、３ＧＰＰ ＴＳ３６．２１１で定義されているようにc_inti＝５１０に固定される。したがって、本発明は、新しいＳＣＩフォーマットに異なるスクランブリングシーケンスを用いることを提案する。従来のＬＴＥシステムとして、スクランブリングシーケンスはＲＮＴＩの一種であってよい。しかしながら、ＩｏＴデバイスの容量が大きい可能性があるので、新しいＳＣＩフォーマット、例えば以下の議論におけるＳＳ１（Scrambling sequence 1）をスクランブルするために、別のＲＮＴＩが採用されるべきである。ＳＳ１はリレーＵＥの範囲内で有効である必要がある。具体的には、ＳＳ１は、ｅＮＢ又はリレーＵＥによって提供されてよい。更に、ＳＳ１は、リレーＵＥのＳＬ−ＲＮＴＩであってもよいし、ｅＮＢによって新たに割り当てられたＲＮＴＩであってもよい。

一実施形態では、リモートＵＥは、リレーＵＥとの中継接続を確立するとき、ｅＮＢによってＳＳ１で構成される。或いは、ＳＳ１は、リレーＵＥによって提供されてよい。その後、リモートＵＥは、ＳＳ０及びＳＳ１を用いて、サイドリンク制御チャネルを復号化する。ＳＣ０がＳＳ０で正常に復号される場合、それはＳＣＩ０であり、このＳＣ期間に送信されたデータはおそらく彼のためである。ＳＣＩがＳＳ１で正常に復号された場合、それは新しいＳＣＩフォーマットであり、リモートＵＥは、新しいＳＣＩフォーマットのコンテンツをチェックして、新しいＳＣＩフォーマットで定義されたサイドリンクリソースがリモートＵＥに対してスケジュールされているか否かを確認する。リソースがリモートＵＥにスケジューリングされる場合、リモートＵＥは、定義されたリソースを用いて、ＳＣ期間中にリレーＵＥにデータを送信することができる。例示的な一実施形態を図１３に示す。

一実施形態では、リモートＵＥが新しいＳＣＩフォーマットで定義されたサイドリンクリソース上の送信電力を制御するために、新しいＳＣＩフォーマットに電力制御フィールドが含まれる。一実施形態では、リモートＵＥがこの新しいＳＣＩフォーマットがそれ自体のためであるか否かを決定するために、新しいＳＣＩフォーマットにターゲットＵＥ識別子が含まれる。具体的には、ターゲットＵＥ識別子は、接続確立時にｅＮＢによって構成されてよい。更に、ターゲットＵＥ識別子はリレーＵＥに特有であってよい。加えて、ターゲットＵＥ識別子はｅＮＢに特有であってよい。

新しいサイドリンクリソース付与は、ＳＣＩ等のレイヤ１コマンドに限定すべきではない。レイヤ２のソリューションを採用することができる。図１４に示されるように、ＭＡＣ（Media Access Control、媒体アクセス制御）制御情報は、リソースオーナーを定義／変更するために用いられ、新たなＳＣＩフォーマットは定義されない。特に、ＭＡＣ制御情報はＭＡＣ ＣＥである。或いは、ＭＡＣ制御情報はＭＡＣサブヘッダである。更に、リモートＵＥがＭＡＣ制御情報を正常に復号し、ＭＡＣ制御情報がいくつかの新しい送信機会がリモートＵＥのために確保されていることを示すインジケータを含む場合、リソースオーナーは、それらの新しい送信機会について、リレーＵＥからリモートＵＥに変更することができる。

送信側と受信側の両方が複数の送信リソースを理解する場合、複数の送信リソース（例えば、ＳＰＳリソース、複数の新しい送信機会）を取得する任意の１対１通信に同様の概念を適用することができる。一実施形態では、インジケータは、３ＧＰＰ ＴＳ ３６．３２１で定義されるＭＡＣサブヘッダに含まれるＬＣＩＤであってよい。或いは、インジケータは、３ＧＰＰ ＴＳ ３６．３２１で定義されたＭＡＣ ＣＥに含まれるブーリアンフラグであってよく、次の新しい送信リソースがリモートＵＥ用に確保されているか否かを示すことができる。しかしながら、MAC PDU復号にはより多くの時間が必要であるので、次の新しい送信機会は、Ｔ−ＲＰＴ（Time Resource Pattern、時間リソースパターン）に従って次のサブフレームになる可能性がある。リモートＵＥは、次の新たな送信機会を使用することができない場合がある。或いは、インジケータは、どの新しい送信機会からリソースオーナーがリモートＵＥに変更されたかを示す値である。或いは、インジケータは、それぞれの新しい送信機会のオーナーを示すビットマップであってよい。更に、ビットマップのビット値０は、リソースがリレーＵＥによって用いられることを意味し、それ以外の場合、リソースはリモートＵＥによって用いられる。各ビットは、それぞれの新しい送信機会、又はそれぞれのスケジュールされたサブフレームを指す。更に、リモートＵＥ（受信側）が新しいＭＡＣ ＣＥを受信した後、リモートＵＥは、残りのリソースを使用するために送信機に変わる。そして、リモートＵＥは、残りのリソースに基づいて、元の送信器にアクナレッジメント又は応答を提供してよい。アクナレッジメント又は応答は、別の新しいＭＡＣ ＣＥ又は物理レイヤシグナリングであってよい。

一般に、本発明は、サイドリンクリソースをリモートＵＥに配信するための効率的且つ互換性のある方法を提供することができる。第１に、リレーＵＥに対するブリンク復号化エフォート（blink decoding effort）は著しく増加しない。第２に、リモートＵＥの挙動はあまり変わらない。リモートＵＥは、ＳＣＩ０及び新しいＳＣＩフォーマットについてＳＡプールをモニタするが、これは追加される新しい挙動を考慮すると必要である。ＳＬ−ｇｒａｎｔは、次のＳＣ期間においても有効である。ＱｏＳ性能は維持されることが期待される。

３ＧＰＰ ＴＳ ３６．３３１は、以下のように、サイドリンクについてのリソース及び通信構成を得る方法を含む、サイドリンク関連手順を要求する詳細手順を記述する。

５．１０ サイドリンク
５．１０．１ 導入
サイドリンク通信及び関連する同期リソース構成は、受信／取得された周波数に適用される。更に、１つ以上のＳＣｅｌｌで構成されたＵＥでは、専用シグナリングによって提供されるサイドリンク通信及び関連する同期リソース構成が、ＰＣｅｌｌ／プライマリ周波数に適用される。サイドリンク検出及び関連する同期リソース構成は、それが受信／取得された周波数又は構成において示された周波数に適用される。１つ以上のＳＣｅｌｌで構成されたＵＥでは、専用シグナリングによって提供されるサイドリンク検出及び関連する同期リソース構成は、ＰＣｅｌｌ／プライマリ周波数／任意の他の示された周波数に適用される。

注１：上位レイヤは、ＵＥを、特定の周波数でサイドリンク通信を受信又は送信して、１つ以上の周波数でサイドリンク検出アナウンスをモニタし、或いは特定の周波数でサイドリンク検出アナウンスを送信するように構成するが、ＵＥがこれらの特定のProSe関連サイドリンクアクティビティを実行する権限がある場合に限る。

注２：所望のサイドリンクアクティビティを実行することができない場合にとるべきアクション（例えばユニキャストサービスの終了、デタッチ）は、ＵＥの実施次第である（例えばＵＥ機能限界を理由とする）。

サイドリンク通信は、１対多と１対１のサイドリンク通信で構成される。１対多のサイドリンク通信は、中継関連及び非中継関連の１対多のサイドリンク通信から成る。１対１のサイドリンク通信は、中継関連及び非中継関連の１対１サイドリンク通信から成る。中継関連１対１サイドリンク通信では、通信相手は、１つのサイドリンクリレーＵＥと１つのサイドリンクリモートＵＥとから成る。

サイドリンク検出は、公衆安全関連（ＰＳ関連）及び非ＰＳ関連のサイドリンク検出から成る。ＰＳ関連サイドリンク検出は、中継関連及び非中継関連のＰＳ関連サイドリンク検出から成る。上位レイヤは、特定のサイドリンクアナウンスがＰＳ関連であるか非ＰＳ関連であるかをＲＲＣに示す。

この仕様は、サイドリンクリレーＵＥ及びサイドリンクリモートＵＥに適用される追加要件を指定することにより、ＵＥをネットワークサイドリンク中継に使用することをカバーする。すなわち、そのようなＵＥについては、特に明示的に述べられていない限り、正規のサイドリンクＵＥの要件が等しく適用される。

５．１０．１ａ サイドリンク動作条件
このセクションで定義された条件が満たされている場合にのみ、ＵＥが特定のサイドリンク動作を実行することが指定される場合、ＵＥは、以下の場合にのみ、関連するサイドリンク動作を実行するものとする。

１＞ＵＥのサービングセルが適切である場合（RRC_IDLE又はRRC_CONNECTED）；サイドリンク動作のために用いられる周波数上の選択されたセルが、ＴＳ ２４．３３４［６９］に規定される登録済み又は同等のＰＬＭＮに属するか、或いはＵＥが、ＴＳ ３６．３０４［４，１１．４］で定義されているような、サイドリンク動作に用いられる周波数のカバレッジから外れている場合。又は、
１＞ＵＥがＴＳ ２３．３０３［６８、４．５．６］に規定されている限定サービス状態でサイドリンク通信をサポートするための条件を満たすサービングセル（RRC_IDLE）にキャンプオンされている場合；サービングセルがサイドリンク動作に用いられる周波数上にある場合、或いはＵＥが、ＴＳ ３６．３０４［４，１１．４］で定義されているような、サイドリンク動作に用いられる周波数のカバレッジから外れている場合。又は、
１＞ＵＥがサービングセルをもたない場合（RRC_IDLE）。

５．１０．２ サイドリンクＵＥ情報
５．１０．２．１ 概要
［３ＧＰＰ ＴＳ ３６．３３１ ｖ１３．１．０の図５．１０．２−１、「サイドリンクＵＥ情報」と題される図は、図１５として再現される］
この手順の目的は、ＵＥがサイドリンクの通信又は検出を受信することに関心がある或いはもはや関心がないことをＥ−ＵＴＲＡＮに通知することと、サイドリンクの通信又は検出のアナウンスの送信リソースの割当て又は解放を要求することと、周波数間／ＰＬＭＮセルのシステム情報からのサイドリンク検出に関連するパラメータを報告することである。

５．１０．２．２ 開始
RRC_CONNECTEDにあるサイドリンク通信又は検出が可能なＵＥは、正常な接続確立時、関心の変更時、SystemInformationBlockType1又はSystemInformationBlockType19をブロードキャストするＰＣｅｌｌへの変更時等、いくつかのケースでサイドリンク通信又は検出を受信している（関心がある）ことを示すための手順を開始してよい。サイドリンク通信又は検出が可能なＵＥは、関連するサイドリンク通信送信又は検出のアナウンスのための専用リソースの割当てを要求する手順を開始してよい。周波数間／ＰＬＭＮサイドリンク検出パラメータ報告が可能なＵＥは、周波数間／ＰＬＭＮセルのシステム情報からサイドリンク検出に関連するパラメータを報告する手順を開始してよい。

注１：サイドリンクの通信/検出アナウンスを送信するように構成されるRRC_IDLEのＵＥは、SystemInformationBlockType18/SystemInformationBlockType19が（通常の状態では）送信するためのリソースを含まないとき、５．３．３．１ａに従って接続確立を開始する。

手順の開始時、ＵＥは以下のようにするものとする。

１＞SystemInformationBlockType18がＰＣｅｌｌによってブロードキャストされる場合、
２＞ＰＣｅｌｌ用の有効なバージョンのSystemInformationBlockType18を確保し、
２＞サイドリンク通信を受信するように上位レイヤによって構成される場合、
３＞最後にRRC_CONNECTED状態に入ってからＵＥがSidelinkUEInformationメッセージを送信しなかった場合、又は、
３＞ＵＥがSidelinkUEInformationメッセージを最後に送信してから、ＵＥがSystemInformationBlockType18をブロードキャストしていないＰＣｅｌｌに接続した場合。又は、
注２：SystemInformationBlockType18をブロードキャストしていないソースＰＣｅｌｌからのハンドオーバ／再確立の後、ＵＥは、そのようなソースＰＣｅｌｌが関心情報を転送しないものとして、以前に提供されたものと同じ関心情報を繰り返す。

３＞SidelinkUEInformationメッセージの最後の送信にcommRxInterestedFreqが含まれていなかった場合、又は、SidelinkUEInformationメッセージの最後の送信以降にサイドリンク通信を受信するために上位レイヤによって構成された周波数が変更された場合、
４＞SidelinkUEInformationメッセージの送信を開始して、５．１０．２．３に従って対象とするサイドリンク通信受信周波数を示す
２＞その他
３＞SidelinkUEInformationメッセージの最後の送信にcommRxInterestedFreqが含まれていた場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、サイドリンク通信受信にもはや関心がないことを示す
２＞非中継関連の１対多サイドリンク通信を伝送するように上位レイヤによって構成されている場合
３＞最後にRRC_CONNECTED状態に入ってからＵＥがSidelinkUEInformationメッセージを送信しなかった場合、又は、
３＞ＵＥが最後にSidelinkUEInformationメッセージを送信してから、SystemInformationBlockType18をブロードキャストしていないＰＣｅｌｌにＵＥが接続した場合、又は、
３＞SidelinkUEInformationメッセージの最後の送信がcommTxResourceReqを含まなかった場合、若しくは、commTxResourceReqによって搬送される情報がSidelinkUEInformationメッセージの最後の送信以降に変更された場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、ＵＥによって要求される非中継関連の１対多サイドリンク通信伝送リソースを示す
２＞その他
３＞SidelinkUEInformationメッセージの最後の送信がcommTxResourceReqを含んだ場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、非中継関連の１対多サイドリンク通信伝送リソースをもはや必要としないことを示す
２＞中継関連の１対多サイドリンク通信を伝送するように上位レイヤによって構成される場合
３＞ＵＥが、RRC_CONNECTED状態に入ってから、SidelinkUEInformationメッセージを送信しなかった場合、又は、
３＞ＵＥがSidelinkUEInformationメッセージを最後に送信してから、SystemInformationBlockType18をブロードキャストしていないＰＣｅｌｌにＵＥが接続したか、SystemInformationBlockType19をブロードキャストしていないか若しくはdiscellfigRelayを含まないSystemInformationBlockType19をブロードキャストしているＰＣｅｌｌに接続した場合
３＞SidelinkUEInformationメッセージの最後の送信がcommTxResourceReqRelayを含まなかった場合、又は、SidelinkUEInformationメッセージの最後の送信以降にcommTxResourceReqRelayによって搬送される情報が変更された場合
４＞ＵＥがサイドリンクリレーＵＥとして動作している場合
５＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、ＵＥによって要求される中継関連の１対多サイドリンク通信伝送リソースを示す
２＞その他
３＞SidelinkUEInformationメッセージの最後の送信がcommTxResourceReqRelayを含んだ場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、中継関連の１対多サイドリンク通信伝送リソースをもはや必要としないことを示す
２＞非中継関連の１対１サイドリンク通信を伝送するように上位レイヤによって構成される場合
３＞ＵＥが、最後にRRC_CONNECTED状態に入ってから、SidelinkUEInformationメッセージを送信しなかった場合、又は、
３＞最後にＵＥがSidelinkUEInformationメッセージを送信してから、SystemInformationBlockType18をブロードキャストしていないＰＣｅｌｌにＵＥが接続したか、若しくは、commTxResourceUC-ReqAllowedを含まないSystemInformationBlockType18をブロードキャストしているＰＣｅｌｌに接続した場合、又は、
３＞SidelinkUEInformationメッセージの最後の送信がcommTxResourceReqUCを含まなかった場合、若しくは、SidelinkUEInformationメッセージの最後の送信以降に、commTxResourceReqUCによって搬送される情報が変更された場合
４＞commTxResourceUC-ReqAllowedがSystemInformationBlockType18に含まれる場合
５＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、ＵＥによって要求される非中継関連の１対１サイドリンク通信の伝送リソースを示す
２＞その他
３＞SidelinkUEInformationメッセージの最後の送信がcommTxResourceReqUC commTxResourceReqUCを含んだ場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、もはや非中継関連の１対１サイドリンク通信の伝送リソースを必要としないことを示す
２＞中継関連の１対１サイドリンク通信を伝送するように上位レイヤによって構成される場合
３＞ＵＥが、最後にRRC_CONNECTED状態に入ってから、SidelinkUEInformationメッセージを送信しなかった場合、又は、
３＞ＵＥが最後にSidelinkUEInformationメッセージを送信してから、SystemInformationBlockType18をブロードキャストしていないＰＣｅｌｌにＵＥが接続し、SystemInformationBlockType19をブロードキャストしていないか、若しくはdiscConfigRelayを含まないSystemInformationBlockType19をブロードキャストしているＰＣｅｌｌに接続した場合、又は、
３＞SidelinkUEInformationメッセージの最後の送信がcommTxResourceReqRelayUCを含まなかった場合、若しくは、SidelinkUEInformationメッセージの最後の送信以降に、commTxResourceReqRelayUCによって搬送される情報が変更された場合
４＞ＵＥがサイドリンクリレーＵＥとして機能している場合、又は、
４＞ＵＥが選択されたサイドリンクリレーＵＥを有する場合、且つ、SystemInformationBlockType19がＰＣｅｌｌによってブロードキャストされ、discConfigRelayを含む場合、且つ、５．１０．１１．５に規定されるサイドリンクリモートＵＥの閾値条件が満たされている場合
５＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、ＵＥによって要求される中継関連の１対１サイドリンク通信の伝送リソースを示す
２＞その他
３＞SidelinkUEInformationメッセージの最後の送信がcommTxResourceReqRelayを含んだ場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、もはや中継関連の１対１サイドリンク通信の伝送リソースを必要としないことを示す
１＞SystemInformationBlockType19がＰＣｅｌｌによってブロードキャストされる場合
２＞ＰＣｅｌｌ用の有効なバージョンのSystemInformationBlockType19を確保する
２＞ＰＣｅｌｌのSystemInformationBlockType19に含まれる場合、サービング周波数又はdiscInterFreqListに含まれる１つ以上の周波数でサイドリンク検出アナウンスを受信するように、上位レイヤによって構成される場合
３＞ＵＥが、最後にRRC_CONNECTED状態に入ってから、SidelinkUEInformationメッセージを送信しなかった場合、又は、
３＞ＵＥが最後にSidelinkUEInformationメッセージを送信してから、SystemInformationBlockType19をブロードキャストしていないＰＣｅｌｌにＵＥが接続した場合、又は、
３＞SidelinkUEInformationメッセージの最後の送信がdiscRxInterestを含まない場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、サイドリンク検出受信に関心があることを示す
２＞その他
３＞SidelinkUEInformationメッセージの最後の送信がdiscRxInterestを含んだ場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、サイドリンク検出受信にもはや関心がないことを示す
２＞ＰＣｅｌｌのSystemInformationBlockType19に含まれるとき、discTxResourcesInterFreqがdiscResourcesNonPS内に含まれ、noTxOnCarrierに設定されていない状態で、プライマリ周波数又はdiscInterFreqListに含まれる１つ以上の周波数上で非ＰＳ関連のサイドリンク検出アナウンスを送信するように、ＵＥが上位レイヤによって構成される場合
３＞ＵＥが、最後にRRC_CONNECTED状態に入ってから、SidelinkUEInformationメッセージを送信しなかった場合、又は、
３＞ＵＥが最後にSidelinkUEInformationメッセージを送信してから、SystemInformationBlockType19をブロードキャストしていないＰＣｅｌｌにＵＥが接続した場合、若しくは、discResourcesNonPS内のdiscTxResourcesInterFreq（或いはdiscTxResourcesInterFreqは、ＵＥがリソースを要求する全ての周波数を含むわけではない）を含まないSystemInformationBlockType19をブロードキャストしているＰＣｅｌｌに接続した場合、又は、
３＞SidelinkUEInformationメッセージの最後の送信がdiscTxResourceReqを含まなかった場合、若しくは、SidelinkUEInformationメッセージの最後の送信以降に、ＵＥによって要求されるサイドリンク検出アナウンスリソースが変更された場合（すなわち、discTxResourceReqが変更された場合）
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、ＵＥによって要求されるサイドリンク検出アナウンスリソースを示す
２＞その他
３＞SidelinkUEInformationメッセージの最後の送信がdiscTxResourceReqを含んだ場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、もはやサイドリンク検出アナウンスリソースを必要としないことを示す
２＞discResourcesPS内にdiscTxResourcesInterFreqが含まれnoTxOnCarrierに設定されていない状態で、プライマリ周波数で、或いは非中継ＰＳ関連のサイドリンク検出アナウンスの場合はdiscInterFreqListに含まれる周波数で、ＰＳ関連のサイドリンク検出アナウンスを送信するように、上位レイヤによって構成される場合
３＞ＵＥが、最後にRRC_CONNECTED状態に入ってから、SidelinkUEInformationメッセージを送信しなかった場合、又は、
３＞ＵＥが最後にSidelinkUEInformationメッセージを送信してから、SystemInformationBlockType19をブロードキャストしていないＰＣｅｌｌにＵＥが接続し、discConfigPSを含まないSystemInformationBlockType19をブロードキャストしているＰＣｅｌｌに接続した場合、或いは非中継ＰＳ関連伝送の場合：（discResourcesPS内にdiscTxResourcesInterFreqを含まないSystemInformationBlockType19をブロードキャストしているＰＣｅｌｌに接続した、若しくは、discTxResourcesInterFreqが、ＵＥがリソースを要求する全ての周波数を含まない）、或いは中継関連ＰＳサイドリンク検出アナウンスの場合:（discConfigRelayを含まないSystemInformationBlockType19をブロードキャストしているＰＣｅｌｌに接続）サイドリンク、又は、
３＞SidelinkUEInformationメッセージの最後の送信がdiscTxResourceReqPSを含まなかった場合、若しくは、SidelinkUEInformationメッセージの最後の送信以降に、ＵＥによって要求されるＰＳ関連のサイドリンク検出アナウンスリソースが変更された場合（すなわちdiscTxResourceReqPSが変更された）
４＞非中継ＰＳ関連のサイドリンク検出アナウンスを伝送するように、上位レイヤによって構成される場合、又は、
４＞ＵＥがサイドリンクリレーＵＥとして機能している場合、且つ、SystemInformationBlockType19がdiscConfigRelayを含む場合、且つ、５．１０．１０．４に規定されるサイドリンクリレーＵＥ閾値条件が満たされる場合、又は、
４＞ＵＥがサイドリンクリレーＵＥを選択している／選択されたサイドリンクリレーＵＥを有する場合、且つ、SystemInformationBlockType19がdiscConfigRelayを含んだ場合、且つ、５．１０．１１．５に規定されるサイドリンクリモートＵＥの閾値条件が満たされている場合
５＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、ＵＥによって要求されるＰＳ関連サイドリンク検出アナウンスリソースを示す
２＞その他
３＞SidelinkUEInformationメッセージの最後の送信がdiscTxResourceReqPSを含んだ場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、ＰＳ関連のサイドリンク検出アナウンスリソースをもはや必要としないことを示す
２＞サイドリンク検出アナウンスをモニタ又は送信し、ＵＥがサイドリンク検出ギャップを必要とする場合、係る動作を実行するように、上位レイヤによって構成される場合
３＞ＵＥが、最後にRRC_CONNECTED状態に入ってから、SidelinkUEInformationメッセージを送信しなかった場合、又は、
３＞ＵＥが最後にSidelinkUEInformationメッセージを送信してから、SystemInformationBlockType19をブロードキャストしていないＰＣｅｌｌにＵＥが接続した場合、若しくは、同時に、ＵＥがgapRequestsAllowedDedicatedで構成されていなかったとき、gapRequestsAllowedCommonを含まないSystemInformationBlockType19をブロードキャストしているＰＣｅｌｌに接続した場合、又は、
３＞SidelinkUEInformationメッセージの最後の送信が、サイドリンク検出アナウンスをモニタ又は送信するために必要なギャップを含まなかった場合（すなわち、ＵＥがdiscTxGapReqが含まれなかった間に検出アナウンスをモニタするためのギャップを必要とする、又は、ＵＥがdiscTxGapReqが含まれなかったときに検出アナウンスを送信するためのギャップを必要とする）、又は、SidelinkUEInformationメッセージの最後の送信以降に、ＵＥによって要求されるサイドリンク検出ギャップが変更された場合（すなわち、discRxGapReq又はdiscTxGapReqが変更された場合）
４＞gapRequestsAllowedDedicatedをtrueに設定してＵＥを設定構成場合、又は、
４＞ＵＥがgapRequestsAllowedDedicatedで構成されておらず、gapRequestsAllowedCommonがSystemInformationBlockType19に含まれる場合
５＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、ＵＥによって要求されるサイドリンク検出ギャップを示す
２＞その他
３＞SidelinkUEInformationメッセージの最後の送信がdiscTxGapReq又はdiscRxGapReqを含んだ場合
４＞５．１０．２．３に従って、SidelinkUEInformationメッセージの送信を開始して、サイドリンク検出ギャップをもはや必要としないことを示す
２＞ＵＥが、discSysInfoToReportConfigに含まれるキャリア上の１つ以上のセルのシステム情報から関連パラメータを取得し、Ｔ３７０が動作している場合
３＞ＵＥが下位レイヤを、それらのセル上でサイドリンク検出アナウンスを送信又はモニタするように構成した場合
４＞SidelinkUEInformationメッセージの送信を開始して、取得されたシステム情報パラメータを報告し、Ｔ３７０を停止する
５．１０．２．３ SidelinkUEInformationメッセージの送信に関連するアクション
ＵＥは、以下のように、SidelinkUEInformationメッセージの内容を設定するものとする
１＞ＵＥがサイドリンクの通信又は検出を受信すること、或いはサイドリンク通信又は検出の伝送リソースを要求する（構成／解放）ことに関心がある（もはや関心がない）ことを示すための手順を開始する（すなわち、ＵＥは、手順をトリガしたものに関係なく、関連する全ての情報を含む）
２＞SystemInformationBlockType18がＰＣｅｌｌによってブロードキャストされる場合
３＞サイドリンク通信を受信するように、上位レイヤによって構成される場合
４＞commRxInterestedFreqを含み、それをサイドリンク通信周波数に設定する
３＞非中継関連の１対多サイドリンク通信を伝送するように、上位レイヤによって構成される場合
４＞commTxResourceReqを含み、そのフィールドを以下のように設定する
５＞含まれていれば、サイドリンク通信周波数すなわちcommRxInterestedFreqに示される値と同じ値を示すように、carrierFreqを設定する
５＞Ｅ−ＵＴＲＡＮに専用リソースの割当てを要求するサイドリンク通信送信先を含めるように、destinationInfoListを設定する
３＞非中継関連の１対１サイドリンク通信を伝送するように、上位レイヤによって構成される場合
３＞commTxResourceUC-ReqAllowedがSystemInformationBlockType18に含まれる場合
４＞commTxResourceReqUCを含み、そのフィールドを以下のように設定する
５＞含まれていれば、サイドリンク１対１通信周波数すなわちcommRxInterestedFreqに示される値と同じ値を示すように、carrierFreqを設定する
５＞Ｅ−ＵＴＲＡＮに専用リソースを割り当てることを要求するサイドリンク１対１通信送信宛先を含めるように、destinationInfoListを設定する
３＞中継関連の１対１サイドリンク通信を伝送するように、上位レイヤによって構成される場合
３＞SystemInformationBlockType19が、ＰＣｅｌｌによってdiscConfigRelayを含んでブロードキャストされる場合
３＞ＵＥがサイドリンクリレーＵＥとして機能している場合、又は、ＵＥが選択されたサイドリンクリレーＵＥを有する場合、且つ、５．１０．１１．５に規定されるサイドリンクリモートＵＥの閾値条件が満たされている場合
４＞commTxResourceReqRelayUCを含み、そのフィールドを以下のように設定する
５＞Ｅ−ＵＴＲＡＮに専用リソースを割り当てることを要求する（ユニキャスト）サイドリンク通信送信先を含むように、destinationInfoListを設定する
４＞ue-Typeを含み、ＵＥがサイドリンクリレーＵＥとして動作している場合はrelayUE-Configに設定し、そうでない場合はリモートＵＥに設定する
３＞中継関連の１対多サイドリンク通信を伝送するように、上位レイヤによって構成される場合
３＞SystemInformationBlockType19が、discConfigRelayを含んでＰＣｅｌｌによってブロードキャストされる場合
３＞ＵＥがサイドリンクリレーＵＥとして機能している場合
４＞commTxResourceReqRelayを含み、そのフィールドを以下のように設定する
５＞Ｅ−ＵＴＲＡＮに専用リソースを割り当てることを要求する（グループキャスト）サイドリンク通信送信先を含むように、destinationInfoListを設定する
４＞ue-Typeを含み、それをrelayUE-Configに設定する
２＞SystemInformationBlockType19がＰＣｅｌｌによってブロードキャストされる場合
３＞SystemInformationBlockType19に含まれる場合、サービング周波数又はdiscInterFreqListに含まれる１つ以上の周波数でサイドリンク検出アナウンスを受信するように、上位レイヤによって構成される場合
４＞discRxInterestを含む
３＞ＵＥが非ＰＳ関連のサイドリンク検出アナウンスを送信するように、上位レイヤによって構成される場合
４＞ＵＥが非ＰＳ関連サイドリンク検出アナウンスを送信するように構成される各周波数について、プライマリ周波数に関係するか、又は、discTxResourcesInterFreqがdiscResourcesNonPS内に含まれ、noTxOnCarrierに設定されていない状態で、discInterFreqListに含まれる
５＞第１の周波数では、discTxResourceReqを含み、プライマリと異なる場合に、Ｅ−ＵＴＲＡＮが専用リソースを割り当てることを要求するサイドリンク検出アナウンスのための検出メッセージの数と、関連する周波数とを示すように設定する
５＞任意の追加の周波数では、discTxResourceReqAddFreqを含み、Ｅ−ＵＴＲＡＮが専用リソースを割り当てることを要求するサイドリンク検出アナウンスのための検出メッセージの数と、関連する周波数とを示すように設定する
３＞PS関連のサイドリンク検出アナウンスを伝送するように、上位レイヤによって構成される場合
３＞ＵＥがＰＳ関連のサイドリンク検出アナウンスを送信するように構成される周波数が、プライマリ周波数に関係するか、或いは、非中継ＰＳ関連のサイドリンク検出アナウンスの場合には、discTxResources InterFreqがdiscResourcesPSに含まれる状態でdiscInterFreqListに含まれ、noTxOnCarrierに設定されない場合
４＞非中継ＰＳ関連のサイドリンク検出アナウンスを送信するように上位レイヤによって構成され、SystemInformationBlockType19がdiscConfigPSを含む場合、又は
４＞ＵＥがサイドリンクリレーＵＥとして機能している場合、且つ、SystemInformationBlockType19がdiscConfigRelayを含む場合、且つ、５．１０．１０．４に規定されるサイドリンクリレーＵＥ閾値条件が満たされる場合、又は、
４＞ＵＥがサイドリンクリレーＵＥを選択している／選択されたサイドリンクリレーＵＥを有する場合、且つ、SystemInformationBlockType19がdiscConfigRelayを含む場合、且つ、５．１０．１１．５に規定されるサイドリンクリモートＵＥの閾値条件が満たされている場合
５＞discTxResourceReqPSを含み、プライマリと異なる場合に、Ｅ−ＵＴＲＡＮに専用リソースを割り当てることを要求するＰＳ関連サイドリンク検出アナウンスのための検出メッセージの数と、関連する周波数とを示すように設定する
１＞さもなければ、ＵＥが送信ギャップ及び／又は受信ギャップを要求する手順を開始する場合
２＞gapRequestsAllowedDedicatedをtrueに設定してＵＥを設定した場合、又は、
２＞ＵＥがgapRequestsAllowedDedicatedで構成されず、gapRequestsAllowedCommonがSystemInformationBlockType19に含まれる場合
３＞ＵＥがサイドリンク検出アナウンスをモニタするためにサイドリンク検出ギャップを必要とする場合、上位レイヤにより、ＵＥはモニタするように構成される
４＞discRxGapReqを含み、プライマリ周波数に関連するか、或いはＵＥがサイドリンク検出アナウンスをモニタするように構成されるdiscInterFreqListに含まれ、サイドリンク検出ギャップがそうすることを要求する各周波数について、ギャップパターン及び関係する周波数を示すように設定する
３＞ＵＥがサイドリンク検出アナウンスをモニタするためにサイドリンク検出ギャップを必要とする場合、上位レイヤにより、ＵＥは送信するように構成される
４＞discTxGapReqを含み、プライマリと異なる場合、プライマリに関連するか、或いはＵＥがサイドリンク検出アナウンスを送信するように構成されるdiscInterFreqListに含まれ、サイドリンク検出ギャップがそうすることを要求する各周波数について、ギャップパターン及び関係する周波数を示すように設定する
１＞そうでなければ、ＵＥがプライマリ以外のキャリアのサイドリンク検出に関連するシステム情報パラメータを報告するための手順を開始する場合
２＞SL-DiscSysInfoReportFreqListを含み、それらのキャリア上のセルから取得されたシステム情報パラメータを報告するように設定する
ＵＥは、送信のために下位レイヤにSidelinkUEInformationメッセージを提出するものとする。

５．１０．３ サイドリンク通信モニタリング
サイドリンク通信を受信するように上位レイヤによって構成される、サイドリンク通信が可能なＵＥは、
１＞５．１０．１ａに定義されるサイドリンク動作条件が満たされる場合
２＞ＴＳ ３６．３０４ ［４，１１．４］で定義されるような、サイドリンク通信に用いられる周波数のカバレッジ内にある場合
３＞サイドリンク通信受信のために選択されたセルが、commRxPoolを含むSystemInformationBlockType18をブロードキャストする場合
４＞サイドリンク制御情報及び対応するデータを、commRxPoolによって示されるリソースのプールを用いてモニタするように、下位レイヤを構成する
注１：commRxPooｌがrxParametersNCellを含む１つ以上のエントリを含む場合、ＵＥは、関連するＰＳＳ／ＳＳＳ又はＳＬＳＳＩＤが検出された場合にのみ、そのようなエントリをモニタしてよい。そのようなプールをモニタするとき、ＵＥは、該当するＰＳＳ／ＳＳＳ又はＳＬＳＳのタイミングを適用する。

２＞その他（つまり、サイドリンクキャリアのカバレッジから外れる）
３＞予め設定されたリソース（すなわち、９．３で定義されたSL-PreconfigurationのpreconfigComm）のプールを用いて、サイドリンク制御情報及び対応するデータをモニタするように、下位レイヤを構成する
注２：ＵＥは、選択されたSyncRef UEのタイミングに従って、或いはＵＥが選択されたSyncRef UEを有さない場合はＵＥ自身のタイミングに基づいて、モニタしてよい。

５．１０．４ サイドリンク通信伝送
サイドリンク通信を送信するように上位レイヤによって構成され、且つ送信すべき関連データを有する、サイドリンク通信が可能なＵＥ、又は、中継関連のサイドリンク通信を送信するように上位レイヤによって構成される、中継関連のサイドリンク通信が可能なＵＥは、
１＞５．１０．１ａに定義されるサイドリンク動作条件が満たされる場合
２＞ＴＳ ３６．３０４ ［４，１１．４］で定義されるような、サイドリンク通信に用いられる周波数のカバレッジ内にある場合
３＞ＵＥがRRC_CONNECTEDにあり、サイドリンク通信にＰＣｅｌｌを用いる場合
４＞ＵＥが、現在のＰＣｅｌｌ／物理レイヤの問題又は無線リンク障害が検出されたＰＣｅｌｌにより、commTxResourcesがスケジュールに設定されている状態で構成される場合
５＞Ｔ３１０又はＴ３１１が実行中の場合；ＵＥにより物理レイヤの問題又は無線リンク障害が検出されたＰＣｅｌｌが、commTxPoolExceptionalを含むSystemInformationBlockType18をブロードキャストする場合、又は、
５＞Ｔ３０１が実行中であり、ＵＥにより接続再確立が開始されたセルが、commTxPoolExceptionalを含むSystemInformationBlockType18をブロードキャストする場合
６＞commTxPoolExceptionalの第１のエントリで示されたリソースのプールを用いて、サイドリンク制御情報及び対応するデータを送信するように、下位レイヤを構成する
５＞その他
６＞Ｅ−ＵＴＲＡＮにサイドリンク通信のための送信リソースを割り当てるように要求するように、下位レイヤを構成する。

４＞さもなければ、ＵＥがcommTxPoolNormalDedicatedで構成される場合、
５＞commTxPoolNormalDedicatedのエントリにpriorityListが含まれる場合
６＞commTxPoolNormalDedicatedによって示されるリソースの１つ以上のプールを用いて、サイドリンク制御情報及び対応するデータを送信するように、下位レイヤを構成する、すなわち、このフィールドの全てのエントリを下位レイヤに示す
５＞その他
６＞commTxPoolNormalDedicated内の第１のエントリによって示されるリソースのプールを用いて、サイドリンク制御情報及び対応するデータを送信するように、下位レイヤを構成する
３＞その他（すなわち、RRC_IDLEにおけるサイドリンク通信、又は、RRC_CONNECTEDのＰＣｅｌｌ以外のセル）:
４＞サイドリンク通信伝送のために選択されたセルが、SystemInformationBlockType18をブロードキャストする場合
５＞SystemInformationBlockType18がcommTxPoolNormalCommonを含む場合
６＞commTxPoolNormalCommon又はcommTxPoolNormalCommonExtのエントリにpriorityListが含まれる場合
７＞commTxPoolNormalCommon及び／又はcommTxPoolNormalCommonExtによって示されるリソースの１つ以上のプールを用いて、サイドリンク制御情報及び対応するデータを送信するように、下位レイヤを構成する、すなわち、これらのフィールドの全てのエントリを下位レイヤに示す
６＞その他
７＞commTxPoolNormalCommonの第１のエントリによって示されるリソースのプールを用いて、サイドリンク制御情報及び対応するデータを送信するように、下位レイヤを構成する。

５＞さもなければ、SystemInformationBlockType18がcommTxPoolExceptionalを含む場合
６＞ＵＥが接続確立を開始してから、sl-CommConfigを含むRRCConnectionReconfigurationを受信するまで、或いは、RRCConnectionRelease又はRRCConnectionRejectを受信するまで
７＞commTxPoolExceptionalの第１のエントリによって示されるリソースのプールを用いて、サイドリンク制御情報及び対応するデータを送信するように、下位レイヤを構成する
２＞その他（つまり、サイドリンクキャリアのカバレッジから外れる）
３＞９．３で定義されるSL-PreconfigurationのpreconfigCommのエントリにpriorityListが含まれる場合
４＞preconfigCommによって示される１つ以上のリソースのプールを用いて、サイドリンク制御情報及び対応するデータを送信するように下位レイヤを構成する、すなわち、選択されたSyncRef UEのタイミングに従って、或いは、ＵＥが選択されたSyncRef UEをもたない場合にはＵＥ自身のタイミングに基づいて、このフィールドの全てのエントリを下位レイヤに示す
３＞その他
４＞予め構成された、すなわち、９．３で定義されるSL-PreconfigurationのpreconfigCommの第１のエントリによって示されるリソースのプールを用いて、選択されたSyncRef UEのタイミングに従って、或いは、ＵＥが選択されたSyncRef UEをもたない場合にはＵＥ自身のタイミングに基づいて、サイドリンク制御情報及び対応するデータを送信するように下位レイヤを構成する
１＞送信がサイドリンク中継通信に関係する場合；ＵＥは、サイドリンク中継又はサイドリンクリモート操作が可能である
２＞ＵＥがRRC_IDLE状態である場合；ＵＥが選択されたサイドリンク中継を有する場合：以下の条件が満たされる場合にのみ、このセクションで前述したように、リソースを用いてサイドリンク制御情報及び対応するデータを送信するように、下位レイヤを構成する
３＞５．１０．１１．５に規定されるサイドリンクリモートＵＥの閾値条件が満たされる場合
２＞以下の条件が満たされる場合に限り、このセクションで前述したように、リソースを用いてサイドリンク制御情報及び対応するデータを送信するように、下位レイヤを構成する
３＞UEがSystemInformationBlockType18（すなわち、commTxPoolNormalCommon、commTxPoolNormalCommonExt又はcommTxPoolExceptional）に含まれるリソースのプールで下位レイヤを構成した場合；commTxAllowRelayCommonがSystemInformationBlockType18に含まれる、又は、
３＞ＵＥが専用シグナリング（すなわちcommTxResources）によって提供されるリソースで下位レイヤを構成した場合；ＵＥは、commTxAllowRelayDedicatedをtrueに設定して構成される
［…］
３ＧＰＰ ＴＳ３６．３２１は、以下のように、サイドリンクＢＳＲメカニズム、サイドリンク付与の受信、ＬＣＰ手順及びサイドリンク通信メカニズムを含む、サイドリンクリソース要求メカニズムに関する詳細を記述する。

５．１４ ＳＬ−ＳＣＨデータ転送
５．１４．１ ＳＬ−ＳＣＨデータ送信
５．１４．１．１ SL Grant受信及びＳＣＩ送信
ＳＬ−ＳＣＨ上で送信するために、ＭＡＣエンティティは少なくとも１つのサイドリンク付与を有さなければならない。サイドリンク付与は以下のように選択される。

−ＭＡＣエンティティが、ＰＤＣＣＨ上で単一のサイドリンク付与を動的に受信するように構成され、現在のＳＣ期間で送信できる更に多くのデータがＳＴＣＨで利用可能である場合、ＭＡＣエンティティは、以下のように構成されるものとする。

−受信されたサイドリンク付与を用いて、［２］の第１４．２．１節に従って、ＳＣＩの送信と第１のトランスポートブロックの送信が発生するサブフレームのセットを決定する
−受信されたサイドリンク付与を、サイドリンク付与が受信されたサブフレームの少なくとも４つのサブフレーム後に始まる第１の利用可能なＳＣ期間の始めから開始するサブフレーム内で発生する、構成済みのサイドリンク付与であるとみなし、可能であれば、同じＳＣ期間内に発生する以前に構成されたサイドリンク付与を上書きする
−対応するＳＣ期間の最後に設定されたサイドリンク付与をクリアする
−そうでなければ、ＭＡＣエンティティが上位レイヤにより、ＰＤＣＣＨ上で複数のサイドリンク付与を動的に受信するように構成され、現在のＳＣ期間中に送信できる更に多くのデータがＳＴＣＨで利用可能である場合、ＭＡＣエンティティは、受信された各サイドリンク付与について、以下のように構成されるものとする。

−受信されたサイドリンク付与を用いて、［２］の第１４．２．１節に従って、ＳＣＩの送信と第１のトランスポートブロックの送信が発生するサブフレームのセットを決定する
−受信されたサイドリンク付与を、サイドリンク付与が受信されたサブフレームの少なくとも４つのサブフレーム後に始まる第１の利用可能なＳＣ期間の始めから開始するサブフレーム内で発生する、構成済みのサイドリンク付与であるとみなし、可能であれば、同じＳＣフレーム期間内に発生するこの構成済みのサイドリンク付与と同じサブフレーム番号であるが異なる無線フレームで受信された、以前に構成されたサイドリンク付与を上書きする
−対応するＳＣ期間の終わりに設定されたサイドリンク付与をクリアする
−そうでなければ、ＭＡＣエンティティが、［８］の第５．１０．４節に示すように、１つ以上のリソースプールを用いて送信するように上位レイヤによって構成され、現在のＳＣ期間中に送信できる更に多くのデータがＳＴＣＨで利用可能である場合、ＭＡＣエンティティは、選択される各サイドリンク付与について、以下のように構成されるものとする。

−単一のリソースプールを使用するように、上位レイヤによって構成される場合
−使用するリソースのプールを選択する
−そうでなければ、複数のリソースプールを使用するように上位レイヤによって構成される場合
−関連する優先度リストが、送信されるMAC PDUにおけるサイドリンク論理チャネルの最高優先度の優先度を含む上位レイヤによって構成されるリソースのプールから、使用するリソースのプールを選択する
・注：複数のリソースプールが、送信されるMAC PDUにおける最も高い優先度を有するサイドリンク論理チャネルの優先度を含む関連優先度リストを有する場合、それらのリソースプールの１つを選択ことは、ＵＥ実装に委ねられる。

−選択されたリソースプールから、サイドリンク付与のＳＬ−ＳＣＨ及びＳＣＩのための時間及び周波数リソースをランダムに選択する。ランダム関数は、許容される選択肢［２］の各々が等しい確率で選択されるようなものでなければならない。

−選択されたサイドリンク付与を用いて、［２］の第１４．２．１節に従って、ＳＣＩの送信と第１のトランスポートブロックの送信が発生するサブフレームセットを決定する
−選択されたサイドリンク付与が、サイドリンク付与が選択されたサブフレームの少なくとも４つのサブフレーム後に始まる第１の利用可能なＳＣ期間の開始時に開始するサブフレーム内で発生する、構成済みのサイドリンク付与であるとみなす
−対応するＳＣ期間の最後に設定されたサイドリンク付与をクリアする
・注：ＳＬ−ＳＣＨの再送信は、構成済みのサイドリンク付与がクリアされた後は実行できない。

・注：ＭＡＣエンティティが、［８］の第５．１０．４節に示すように、１つ以上のリソースプールを用いて送信するように上位レイヤによって構成される場合、サイドリンクプロセスの数を考慮して、１つのＳＣ期間内にいくつのサイドリンク付与を選択するかは、ＵＥ実装に委ねられる。

ＭＡＣエンティティは、各サブフレームについて、以下のように構成されるものとする。

−ＭＡＣエンティティが、このサブフレームで発生する構成済みのサイドリンク付与を有する場合
−構成済みのサイドリンク付与がＳＣＩの送信に対応する場合
−構成済みのサイドリンク付与に対応するＳＣＩを送信するように、物理レイヤに指示する
−そうでなければ、構成済みのサイドリンク付与が第１のトランスポートブロックの送信に対応する場合
−このサブフレームのために、構成済みのサイドリンク付与及び関連ＨＡＲＱ情報をサイドリンクＨＡＲＱエンティティに配信する
・注：ＭＡＣエンティティが１つのサブフレームで発生する複数の構成済み付与を有し、それらの全てを単一クラスタＳＣ−ＦＤＭ制限のために処理できるわけではない場合、それらのうちどれが上記の手順に従って処理されるかは、ＵＥ実装に委ねられる。

５．１４．１．２ サイドリンクＨＡＲＱ動作
５．１４．１．２．１ サイドリンクＨＡＲＱエンティティ
ＭＡＣエンティティには、ＳＬ−ＳＣＨ上で送信するための１つのサイドリンクＨＡＲＱエンティティが存在し、複数の並列サイドリンクプロセスを維持する。

Sidelink HARQエンティティに関連する送信Sidelinkプロセスの数は［８］で定義される。

配信され構成されるサイドリンク付与と関連ＨＡＲＱ情報は、サイドリンクプロセスに関連付けられる。

Sidelink HARQエンティティは、ＳＬ−ＳＣＨの各サブフレームと各サイドリンクプロセスについて、以下のように構成されるものとする。

−このサイドリンクプロセスについてサイドリンク付与が指示され、ＳＬデータが存在する場合、このサイドリンク付与に関連付けられたProSe宛先のサイドリンク論理チャネルについて、送信に利用可能である
−“Multiplexing and assembly”エンティティからMAC PDUを取得する。

−MAC PDUとサイドリンク付与とＨＡＲＱ情報を、このサイドリンクプロセスに配信する
−このサイドリンクプロセスに、新しい送信をトリガするよう指示する
−そうでなければ、このサブフレームがこのサイドリンクプロセスの再送信機会に対応する場合
このサイドリンクプロセスに、再送信をトリガするように指示する
・注：再送機会のためのリソースは、［２］の第１４．２．１節に規定される。

５．１４．１．２．２ サイドリンクプロセス
サイドリンクプロセスは、ＨＡＲＱバッファに関連付けられる。

冗長バージョンのシーケンスは０，２，３，１である。変数CURRENT_IRVは、冗長バージョンのシーケンスへのインデックスである。この変数はモジュロ４で更新される。

所与のＳＣ期間の新しい送信及び再送信は、サイドリンク付与に示されるリソース及び上位レイヤ（構成されている場合）によって構成されたＭＣＳで実行される。

サイドリンクＨＡＲＱエンティティが新たな送信を要求する場合、サイドリンクプロセスは以下のように構成されるものとする。

−CURRENT_IRVを0に設定する
−MAC PDUを関連するＨＡＲＱバッファに格納する
−サイドリンクＨＡＲＱエンティティから受信したサイドリンクの付与を格納する
−以下に説明するように送信を生成する。

Sidelink HARQエンティティが再送信を要求する場合、サイドリンクプロセスは、
−以下に説明するように送信を生成するものとする。

送信を生成するために、サイドリンクプロセスは以下のように構成されるものとする。

−アップリンク送信が存在しない場合、又はＭＡＣエンティティが送信時に、アップリンク送信とＳＬ−ＳＣＨ上の送信を同時に実行できる場合
−Sidelink Discovery Gap for Transmissionが存在しないか、或いは伝送の時点でＰＳＤＣＨ上の伝送が存在しない場合
−CURRENT_IRV値に対応する冗長バージョンを用いて、記憶されたサイドリンク付与に従って送信を生成するように、物理レイヤに指示する
−CURRENT_IRVを１だけインクレメントする。

５．１４．１．３ 多重化とアセンブリ
１つのＳＣＩに関連するＰＤＵについて、ＭＡＣは、同じSource Layer-2 ID-Destination Layer-2 IDペアを伴う論理チャネルのみを考慮する。

重複するＳＣ期間内の異なるProSe宛先への多重送信は、単一クラスタＳＣ−ＦＤＭ制約の対象となる。

５．１４．１．３．１ 論理チャネルの優先順位付け
論理チャネル優先順位付け手順は、新しい伝送が実行されるときに適用される。各サイドリンク論理チャネルには、ＰＰＰＰである関連優先度がある。複数のサイドリンク論理チャネルは、同じ関連優先度を有することができる。優先度とＬＣＩＤとの間のマッピングは、ＵＥ実装に委ねられる。

ＭＡＣエンティティは、ＳＣ期間中に送信された各ＳＣＩについて、以下の論理チャネル優先順位付け手順を実行するものとする。

−ＭＡＣエンティティは、以下のステップで、サイドリンクの論理チャネルにリソースを割り当てる。

−ステップ０：送信可能なデータを有するサイドリンク論理チャネルの中で最も優先度の高いサイドリンク論理チャネルを有するProSe宛先（このＳＣ期間に以前に選択されていない）を選択する
−ステップ１：選択されたProSe宛先に属し、送信可能なデータを有するサイドリンク論理チャネルの中で、優先度が最も高いサイドリンク論理チャネルにリソースを割り当てる
−ステップ２：リソースが残っている場合、選択されたProSe宛先に属するサイドリンクの論理チャネルが、サイドリンク論理チャネルかＳＬ付加のデータのいずれかが消耗するまで、どちらか早い方で、優先度が降順に提供される。等しい優先度で構成されたサイドリンクの論理チャネルは、等しく配信される必要がある。

−また、ＵＥは、上記のスケジューリング手順の間、以下の規則に従うものとする。

−ＵＥは、ＳＤＵ全体（又は部分的に送信されたＳＤＵ）が残りのリソースにフィットする場合、ＲＬＣ ＳＤＵ（又は部分的に送信されたＳＤＵ）をセグメント化してはならない
−ＵＥがサイドリンク論理チャネルからＲＬＣ ＳＤＵをセグメント化する場合、ＵＥは、可能な限り付与を満たすためにセグメントのサイズを最大化するものとする
−ＵＥは、データの送信を最大化すべきである
−ＭＡＣエンティティが送信可能なデータを有する一方、１０バイト以上のサイドリンク付与サイズが与えられた場合、ＭＡＣエンティティはパディングのみを送信しないものとする。

５．１４．１．３．２ ＭＡＣ ＳＤＵの多重化
ＭＡＣエンティティは、第５．１４．１．３．１節と第６．１．６節に従って、MAC PDUにＭＡＣ ＳＤＵを多重化するものとする
５．１４．１．４ バッファステータス報告
サイドリンクバッファステータスレポート手順は、サービングｅＮＢに、ＭＡＣエンティティに関連するＳＬバッファにおける送信に利用可能なサイドリンクデータの量に関する情報を提供するために用いられる。ＲＲＣは、periodic-BSR-TimerSLとretx-BSR-TimerSLの２つのタイマを構成することにより、サイドリンクのＢＳＲレポートを制御する。各サイドリンクの論理チャネルは、ProSe Destinationに属する。各サイドリンク論理チャネルは、サイドリンク論理チャネルの優先度と、ＬＣＧ ＩＤと、logicalChGroupInfoList[8]の上位レイヤによって提供される優先度との間のマッピングに応じて、ＬＣＧに割り当てられる。ＬＣＧは、ProSe Destinationごとに定義される。

サイドリンクバッファステータスレポート（ＢＳＲ）は、以下のいずれかのイベントが発生すると、トリガされるものとする。

−ＭＡＣエンティティが構成されたＳＬ−ＲＮＴＩを有する場合
−ProSe Destinationのサイドリンク論理チャネルについて、ＳＬデータは、ＲＬＣエンティティ又はＰＤＣＰエンティティにおいて送信可能になり（どのデータが送信可能とみなされるかの定義は、［３］及び［４］でそれぞれ規定される）、データは、同じProSe Destinationに属し且つ既にデータが送信可能である任意のＬＣＧに属するサイドリンク論理チャネルの優先度よりも高い優先度を有するサイドリンク論理チャネルに属すか、或いは、現在、同じProSe Destinationに属するサイドリンク論理チャネルのいずれにも送信可能なデータがない（この場合、サイドライクＢＳＲを以下では“Regular Sidelink BSR”と呼ぶ）
−ＵＬリソースが割り当てられ、Padding BSRがトリガされた後に残るパディングビットの数が、ProSe Destinationとそのサブヘッダとの少なくとも１つのＬＣＧのバッファステータスを含むサイドリンクＢＳＲ ＭＡＣ制御要素のサイズ以上である（この場合、以下、サイドリンクＢＳＲを“Padding Sidelink BSR”と呼ぶ）
−retx-BSR-TimerSLが満了し、ＭＡＣエンティティは、サイドリンク論理チャネルのうちいずれかのための送信可能なデータを有する（この場合、サイドリンクＢＳＲは以下では“Regular Sidelink BSR”と呼ぶ）
−periodic-BSR-TimerSLが満了する（この場合、サイドリンクＢＳＲは以下では“Periodic Sidelink BSR”と呼ぶ）
−その他
−ＳＬ−ＲＮＴＩは上位レイヤによって構成され、ＳＬデータは、ＲＬＣエンティティ又はＰＤＣＰエンティティにおいて送信可能である（どのデータが送信可能とみなされるかについての定義は、［３］及び［４］でそれぞれ規定される）（この場合、サイドリンクＢＳＲは以下では“Regular Sidelink BSR”と呼ぶ）。

Regular及びPeriodic Sidelink BSRについて、
−ＵＬ付与のビット数が、送信可能なデータとそのサブヘッダを有する全てのＬＣＧのバッファステータスを含むサイドリンクＢＳＲのサイズ以上である場合
−送信可能なデータを有する全てのＬＣＧのバッファステータスを含むサイドリンクＢＳＲを報告する
−そうでなければ、ＵＬグラントのビット数を考慮して、送信可能なデータを有するＬＣＧの数ができるだけ多いバッファステータスを含むトランケーテッドサイドリンクＢＳＲを報告する。

Padding Sidelink BSRについて
−Padding BSRがトリガされた後に残っているパディングビットの数が、送信可能なデータとそのサブヘッダを有する全てのＬＣＧのバッファステータスを含むサイドリンクＢＳＲのサイズ以上である場合
−送信可能なデータを有する全てのＬＣＧのバッファステータスを含むサイドリンクＢＳＲを報告する
−そうでなければ、ＵＬ付与のビット数を考慮して、送信可能なデータを有するＬＣＧの数ができるだけ多いバッファステータスを含むトランケーテッドサイドリンクＢＳＲを報告する。

バッファステータスレポート手順が、少なくとも１つのサイドリンクＢＳＲがトリガされキャンセルせれていないと決定した場合
−ＭＡＣエンティティがこのＴＴＩの新たな送信に割り当てられたＵＬリソースを有し、割り当てられたＵＬリソースが、論理チャネル優先順位付けの結果として、サイドリンクＢＳＲ ＭＡＣ制御要素とそのサブヘッダを収容することができる場合
−サイドリンクＢＳＲ ＭＡＣ制御要素を生成するように、多重化及びアセンブリ手順に指示する
−生成された全てのサイドリンクＢＡＲがトランケーテッドサイドリンクＢＳＲである場合を除いて、periodic-BSR-TimerSLを開始又は再開する
−retx-BSR-TimerSLを開始又は再開する
−そうでなければ、Regular Sidelink BSRがトリガされている場合
−アップリンク付与が構成されていない場合
−スケジューリングリクエストがトリガされるものとする。

MAC PDUは、複数のイベントがサイドリンクＢＳＲを送信できる時間までにサイドリンクＢＳＲをトリガしても、多くても１つのサイドリンクＢＳＲ ＭＡＣ制御要素を含むものとする。この場合、Regular Sidelink BSRとPeriodic Sidelink BSRは、Padding Sidelink BSRよりも優先される。

MACエンティティは、SL付与の受信時にretx-BSR-TimerSLを再開するものとする。

このSC期間に有効な残りの構成済みSL付与が、全ての保留中の送信可能なデータを収容できる場合、トリガされたレギュラーサイドリンクBSRは全てキャンセルされるものとする。MACエンティティがいずれかのサイドリンク論理チャネルのための送信可能なデータを有していない場合、全てのトリガされたサイドリンクBSRはキャンセルされるものとする。全てのトリガされたサイドリンクBSRは、サイドリンクBSR（Truncated Sidelink BSRを除く）が送信のためのMAC PDUに含まれるときに、キャンセルされるものとする。上位レイヤが自律的なリソース選択を構成する場合、全てのトリガされたサイドリンクBSRはキャンセルされるものとし、retx-BSR-TimerSL及びperiodic-BSR-TimerSLは停止されるものとする。

ＭＡＣエンティティは、ＴＴＩにおいて最大でも１つのRegular/Periodic Sidelink BSRを送信するものとする。ＭＡＣエンティティがＴＴＩにおいて複数のMAC PDUを送信することを要求された場合、Regular/Periodic Sidelink BSRを含まないMAC PDUのいずれかにパディングサイドリンクＢＳＲを含めることができる。

ＴＴＩで送信される全てのサイドリンクＢＳＲは、全てのMAC PDUがこのＴＴＩ用に構築された後、常にバッファステータスを反映する。各ＬＣＧは、ＴＴＩあたり最大で１つのバッファステータス値を報告するものとし、この値は、このＬＣＧのバッファステータスを報告する全てのサイドリンクＢＳＲで報告されるものとする。

・注：Padding Sidelink BSRは、トリガされたRegular／Periodic Sidelink BSRをキャンセルすることはできない。Padding Sidelink BSRは、特定のMAC PDUに対してのみトリガされ、このMAC PDUが構築されるとトリガはキャンセルされる。

５．１４．２ ＳＬ−ＳＣＨデータ受信
５．１４．２．１ ＳＣＩ受信
ＰＳＣＣＨ上で送信されるＳＣＩは、ＳＬ−ＳＣＨ上に送信があるかどうかを示し、関連するＨＡＲＱ情報を提供する。

ＭＡＣエンティティは、以下のように構成されるものとする。

−ＭＡＣエンティティがＰＳＣＣＨをモニタする各サブフレームについて
−このサブフレームのＳＣＩが、このＭＡＣエンティティに関心のあるGroup Destination IDと共にＰＳＣＣＨ上で受信された場合
４−受信されたＳＣＩを用いて、［２］の第１４．２．２節に従って、第１のトランスポートブロックの受信が発生するサブフレームのセットを決定する
５−ＳＣＩ及び関連ＨＡＲＱ情報を、各トランスポートブロックの第１の送信に対応するサブフレームに対して有効なＳＣＩとして格納する
−ＭＡＣエンティティが有効なＳＣＩを有する各サブフレームについて
−ＳＣＩ及び関連ＨＡＲＱ情報をサイドリンクＨＡＲＱエンティティに配信する。

５．１４．２．２ サイドリンクＨＡＲＱ動作
５．１４．２．２．１ サイドリンクＨＡＲＱエンティティ
複数の並列サイドリンクプロセスを維持するＳＬ−ＳＣＨの受信のために、ＭＡＣエンティティには１つのサイドリンクＨＡＲＱエンティティが存在する。各サイドリンクプロセスは、ＭＡＣエンティティがＳＣＩのGroup Destination IDによって決定されるように関心をもつＳＣＩに関連付けられる。サイドリンクＨＡＲＱエンティティは、ＳＬ−ＳＣＨ上で受信されたＨＡＲＱ情報及び関連ＴＢを、対応するサイドリンクプロセスに誘導する。

サイドリンク ＨＡＲＱエンティティに関連する受信側のSidelinkプロセスの数は、［８］で定義される。

サイドリンクＨＡＲＱエンティティは、ＳＬ−ＳＣＨの各サブフレームについて、以下のように構成されるものとする。

−このサブフレームで有効な各ＳＣＩに対して
−物理レイヤから受信されたＴＢ及び関連すＨＡＲＱ情報をSidelinkプロセスに割り当て、このSidelinkプロセスをこのＳＣＩに関連付け、この送信を新しい送信とみなす
−各サイドリンクプロセスについて
６−このサブフレームが、関連ＳＣＩに従って、Sidelinkプロセスの再送信機会に対応する場合
−物理レイヤから受信されたＴＢと関連ＨＡＲＱ情報をSidelinkプロセスに割り当て、この送信を再送信とみなす。

５．１４．２．２．２ サイドリンクプロセス
Sidelinkプロセスのために送信が行われる各サブフレームについて、１つのＴＢ及び関連ＨＡＲＱ情報がサイドリンクＨＡＲＱエンティティから受信される。冗長バージョンのシーケンスは０，２，３，１である。変数CURRENT_IRVは、冗長バージョンのシーケンスへのインデックスである。この変数はモジュロ４で更新される。

受信されたＴＢ及び関連ＨＡＲＱ情報の各々について、サイドリンクプロセスは以下のように構成されるものとする。

−これが新しい送信である場合
−CURRENT_IRVを０に設定する
−受信されたデータをソフトバッファに格納し、任意に、CURRENT_IRVに従って受信データの復号を試みる。

−そうでなければ、これが再送信である場合
−このＴＢのデータがまだ正常に復号されていない場合
７−CURRENT_IRVを１だけインクリメントする
８−受信されたデータをこのＴＢ用のソフトバッファ内に現在あるデータと組み合わせ、任意に、CURRENT_IRVに従って結合データの復号を試みる。

−ＭＡＣエンティティが復号を試みたデータが、このＴＢに対して正常に復号された場合
−これがこのＴＢのデータの最初の正常な復号である場合
９−復号されたMAC PDUサブヘッダのＤＳＴフィールドが、対応するＳＣＩにおいて８つのＬＳＢがGroup Destination IDと等しいＵＥのDestination Layer-2 IDのうちいずれかの１６ＭＳＢに等しい場合、
−復号されたMAC PDUを、ディスアセンブリ及び逆多重化エンティティに配信する。

５．１４．２．３ ディスアセンブリ及び逆多重化
ＭＡＣエンティティは、第６．１．６節に定義されるMAC PDUをディスアセンブリし、逆多重化するものとする。

［…］
６．１．３．１ａ サイドリンクＢＳＲ ＭＡＣ制御要素
Sidelink BSR及びTruncated Sidelink BSR MAC制御要素は、報告ターゲットグループごとに、１つのDestination Indexフィールドと、１つのLCG IDフィールドと、１つの対応するBuffer Sizeフィールドで構成される。

Sidelink BSR MAC制御要素は、表６．２．１−２に指定されるＬＣＩＤを伴うMAC PDUサブヘッダによって識別される。それらは可変サイズを有する。

含まれるグループごとに、フィールドは以下のように定義される（図６．１．３．１ａ−１及び図６．１．３．１ａ−２）
−Destination Index：Destination Indexフィールドは、ProSe Destinationを識別する。このフィールドの長さは４ビットである。値はdestinationInfoListで報告される宛先のインデックスに設定され、destinationInfoListUCも報告される場合、値は、［８］で指定される両方のリストにわたって順番に索引付けされる。

−LCG ID：Logical Channel Group IDフィールドは、バッファステータスが報告されている論理チャネルのグループを識別する。フィールドの長さは２ビットである。

−Buffer Size：Buffer Sizeフィールドは、ＴＴＩの全てのMAC PDUが構築された後、ProSe DestinationのＬＣＧの全ての論理チャネルで利用可能なデータの総量を識別する。データ量はバイト数で示される。それは、ＲＬＣレイヤ及びＰＤＣＰレイヤにおいて送信可能な全てのデータを含むものとする。どのデータが送信可能であるとみなされるかの定義は、［３］及び［４］でそれぞれ規定される。ＲＬＣ及びＭＡＣヘッダのサイズは、バッファサイズの計算では考慮されない。このフィールドの長さは６ビットである。バッファサイズフィールドによってとられる値を表６．１．３．１−１に示す。

−R：Reservedビット、“０”に設定される。

ＬＣＧのバッファサイズは、Destination Indexフィールドの値に関わらず、ＬＣＧに属するサイドリンク論理チャネルの最高優先度の降順で含まれる。

［３ＧＰＰ ＴＳ３６．３２１ ｖ１３．１．０の図６．１．３．１ａ−１、題名「偶数ＮのSidelink BSRとTruncated Sidelink BSR MAC制御要素」は、図１６として再現される］
［３ＧＰＰ ＴＳ３６．３２１ ｖ１３．１．０の図６．１．３．１ａ−２、題名「奇数ＮのSidelink BSRとTruncated Sidelink BSR MAC制御要素」は、図１７として再現される］
［…］
［３ＧＰＰ ＴＳ３６．３２１ ｖ１３．１．０の表６．２．１−１、題名「ＤＬ−ＳＣＨのＬＣＩＤの値」は、図１８として再現される］
［３ＧＰＰ ＴＳ３６．３２１ ｖ１３．１．０の表６．２．１−２、題名「ＵＬ−ＳＣＨのＬＣＩＤの値」は、図１９として再現される］
［…］
新しいＳＩについて、新しいタイプのＵＥ‐ネットワーク間中継は、商用のＩｏＴとウェアラブルをサポートするように設計される。要件に基づいて、新しいタイプのＵＥ‐ネットワーク間中継の設計は、リモートＵＥの電力効率、セキュリティ及びエンドツーエンドの到達可能性を考慮に入れるものとする。ＲＡＮ２＃９３ｂｉｓの議論（３ＧＰＰ Ｒ２−１６３０５６に記載されている）では、新しいタイプのＵＥ‐ネットワーク間中継のためのレイヤ２中継設計は、要件を達成するための一種の解決策である。しかしながら、リレーＵＥ、リモートＵＥ及びｅＮＢ間のレイヤ２マッピングを確立する方法の詳細は明確ではない。更に、新しいＳＩは、Ｒｅｌ−１３中継アーキテクチャでは達成できないＥ２Ｅ（エンドツーエンド）ＱｏＳ（サービス品質）の向上も考慮する。したがって、このような拡張を実現するためには、ＰＣ５インタフェースのリソース利用が重要な機能となる。我々の前提では、リモートＵＥは、Ｄ２Ｄインタフェース上でリレーＵＥとの双方向通信パスを確立する。そして、消費電力を低減するために、全てのアップリンクデータ伝送は中継セッションを通過する。一般に、本発明は概して、上記の仮定に基づき、以下のリモートＵＥのＥ２Ｅ ＱｏＳを達成する方法に焦点を当てる。以下の議論は、リモートＵＥがどのようにそのバッファ状態をリレーＵＥに／リレーＵＥを介して提供するかに関する態様と、ｅＮＢがリレーＵＥからリモートＵＥのバッファ状態をどのように取得するかに関する態様とに関する。リモートＵＥのバッファステータスは、従来と同様のＢＳＲ ＣＥ（制御要素）として送信することができる。Ｓｉｄｅｌｉｎｋ ＢＳＲは、ＢＳＲ ＣＥの例として用いられる。ＢＳＲ ＣＥはまた、新しいタイプのＢＳＲ ＣＥ又はアップリンクＢＳＲ ＣＥであってもよい。

課題３及び解決策：特定の仮定に基づき、リモートＵＥは、省電力のために、そのサイドリンクＢＳＲをＰＣ５インタフェースを介して関連リレーＵＥに送信する。通常のサイドリンクＢＳＲでは、競合ベースリソース又は専用リソースのいずれかを用いて送信することに問題はない。しかしながら、周期的なサイドリンクＢＳＲでは、多数のＩｏＴデバイスがそれらの周期的なサイドリンクＢＳＲを同時に提供する可能性があり、よって衝突率が増加する可能性があるので、競合ベースリソースを使用することは推奨されない。また、無制限の周期的な伝送にも消費電力の問題がある。このベースラインのメカニズムを図２０に示す。

サイドリンクＢＳＲがリレーＵＥによって中継されることを考慮すると、ｅＮＢは、サイドリンクＢＳＲがいつトリガされるかについて全く知らない。加えて、リレーＵＥは、全てのリモートＵＥからのサイドリンクＢＳＲ上にそのＬＣＰを強制するので、リモートＵＥのサイドリンクＢＳＲのｅＮＢに対する遅延変動が大きくなる可能性がある。その結果、ｅＮＢはリモートＵＥのバッファ状態を誤って解釈し、誤った理解に基づいてリソースをスケジュールすることがある。図２１及び図２２に、その可能性のある例示的なケースを示す。図２１において、ネットワークは、３つの送信機会で分離された３０ユニットのリソースで、すなわち送信機会ごとに１０ユニットで、サイドリンク付与を割り振る。更新されたサイドリンクＢＳＲは、リモートＵＥから第２の送信機会でリレーＵＥに送信され、サイドリンクＢＳＲは、５ユニットのリソースをとる。ｅＮＢはリレーＵＥから最後のサイドリンクＢＳＲを受信したが、ｅＮＢは、第２の送信機会の状態において、最後のサイドリンクＢＳＲがリモートＵＥのバッファステータスを表すことを知らない可能性がある。したがって、最後のサイドリンクＢＳＲに基づいてリソースをスケジュールするか否かを、ｅＮＢが決定することは困難である。同様の条件が図２２に生じる。

リモートＵＥのＥ２Ｅ ＱｏＳを達成するために、ｅＮＢは、必要に応じてサイドリンクリソースを提供し、遅延要件を満たすことが期待される。本発明は、ｅＮＢにリモートＵＥのバッファステータスを良好に推定させるアイデアを提案する。本発明の概念は、固定／所定のタイミングで、サイドリンクＢＳＲ（定期的且つ周期的なサイドリンクＢＳＲであってよい）をトリガ及び送信することをリモートＵＥに強制することである。

より具体的には、固定／所定のタイミングは、リモートＵＥに割り当てられたＳＬ付与（例えば、特定の新しい送信機会、第１の新しい送信機会、最後の新しい送信機会等）の送信機会に関連付けられる。よって、ｅＮＢは、トラフィック量を考慮してリモートＵＥのバッファステータスを推定及び／又は予測し、そのサイドリンクＢＳＲのタイミングを報告することができる。具体的には、リモートＵＥが、Ｕｕインタフェース上のＰＤＣＣＨを介してｅＮＢから、あるはＰＣ５インタフェースを介してリレーＵＥから送信されたサイドリンク付与を受信すると、リモートＵＥは、次のＳＣ期間にデータ伝送を実行する。リモートＵＥは、ＳＣ期間中にいくつかの新しい送信機会を有することができる。サイドリンクＢＳＲは、最後の新しい送信機会でトリガされ、送信される可能性がある。サイドリンクリソースはｅＮＢによってスケジューリングされるので。ｅＮＢは、最後の新しい送信のタイミングでサイドリンクＢＳＲがリモートＵＥのバッファステータスを反映することを知っている。或いは、サイドリンクＢＳＲをトリガして、第１の新しい送信機会で送信することができる。

一実施形態では、サイドリンクＢＳＲは定期的なサイドリンクＢＳＲである。或いは、サイドリンクＢＳＲは周期的なサイドリンクＢＳＲである。更に、ＵＥにデータが残っていなければ、サイドリンクＢＳＲはキャンセルされる。加えて、そのようなサイドリンクＢＳＲ設計は、リレーＵＥがリモートＵＥのサイドリンクバッファステータスを処理する応答であるというシナリオにも有益であり得る。新たにトリガされたサイドリンクＢＳＲは、最新のバッファステータスを常に反映することができる（例えば、最後の新しい送信機会で常に送信する）ことができるので、リレーＵＥは、異なるケースについて複雑な計算をすることなく、バッファステータスを簡単に更新することができる。

実際の実施では、Sidelink BSRを早期にトリガすることができるが、Sidelink BSRは所定のタイミングに含まれる。したがって、外部挙動は、所定のタイミング（例えば、第１の新しい送信機会、最後の送信機会等）のリレーＵＥへの送信が常にサイドラインＢＳＲを含むことである。

別の方法は、Sidelink BSRによって報告される内容を変更することである。現在、Ｕｕリンクで送信されるサイドリンクＢＳＲは、サイドリンクＢＳＲ伝送のサブフレームにおけるバッファステータスを報告するためのものである。そして、本発明は、ＰＣ５インタフェース上で伝送されるサイドリンクＢＳＲが、利用可能な全てのサイドリンクリソースを考慮して残りのデータのバッファステータスを報告することを提案する。言い換えれば、ＵＥは、全てのサイドリンク付与における残りの全ての送信機会によって収容可能な合計データサイズだけ縮小された現在のバッファサイズとして、レポート内のバッファステータスを計算する。

課題４及び解決策：リモートＵＥのＥ２Ｅ ＱｏＳを改善するために、最も簡単な方法は、ｅＮＢに、リモートＵＥの要求に基づいて、リモートＵＥをスケジューリングすることができるようにすることである。しかしながら、リモートＵＥは節電のためにｅＮＢと直接通信しないので、ｅＮＢは、リモートＵＥの要求を理解することができず、リモートＵＥの要求に基づいて更にリソースをスケジュールすることができない。ここでは、ｅＮＢがリモートＵＥのリソース需要に関する情報を取得するための、少なくとも２種類のメカニズムについて議論する。

第１の種類のメカニズムは、リレーＵＥが、リモートＵＥのサイドリンクＢＳＲをｅＮＢに転送することである。この種のメカニズムでは、リモートＵＥは、そのリソース需要を報告するために従来のサイドリンクＢＳＲメカニズムを再使用することが想定される。しかしながら、従来と比較したときのひとつの違いは、リモートＵＥが、トリガされたサイドリンクＢＳＲをＰＣ５インタフェース上でリレーＵＥに転送のために送信することである。詳細には、リモートＵＥは、トリガされたサイドリンクＢＳＲが定期的なサイドリンクＢＳＲである場合、トリガされたサイドリンクＢＳＲを送信するために競合リソースを用いてよい。トリガされたサイドリンクＢＳＲが周期的なサイドリンクＢＳＲである場合、それは、割り当てられた専用サイドリンクリソース（例えば、リレーＵＥ又はｅＮＢから受信されたＰＣ５リソース）を介してリレーＵＥに送信されてよい。一実施形態では、パディングサイドリンクＢＳＲは、サイドリンク付与を介して送信することができない。

リモートＵＥのサイドリンクＢＳＲがリレーＵＥによって受信されると、リレーＵＥはリモートＵＥのサイドリンクＢＳＲの送信を処理する必要がある。リレーＵＥは、リモートＵＥのサイドリンクＢＳＲを転送するためにアップリンクリソースを必要とする。可能な転送フォーマットを図２３に示す。

従来の設計コンセプトを考慮すると、簡単な方法のひとつは、リモートＵＥのサイドリンクＢＳＲを新しいタイプのレギュラーＢＳＲとみなすことであり、ＳＲ送信をトリガすることができる。このようにして、リレーＵＥは、リモートＵＥのサイドリンクＢＳＲのためのアップリンクリソースが存在することを確認することができる。しかしながら、これにはいくつかの欠点がある。

１つの欠点は、リレーＵＥが、リモートＵＥから受信したサイドリンクＢＳＲに基づいて周期的なサイドリンクＢＳＲと定期的なサイドリンクＢＳＲとを区別することができないので、周期的／定期的なサイドリンクＢＳＲが連続的にリモートＵＥから来た場合に、ＳＲが頻繁にトリガされることである。その結果、リレーＵＥは、ＰＤＣＣＨモニタリングでより多くの電力を消費することになる。別の欠点は、リレーＵＥからＳＲに応答するための適切なＵＬリソースをｅＮＢが割り当てることがより困難になることである。加えて、新しいタイプのレギュラーＢＳＲは、新しいフォーマットを必要とし、より多くのアップリンクソースを消費する可能性がある。欠点を考慮して、リモートＵＥのサイドリンクＢＳＲを転送するためのリソースを要求する別の可能な方法が提案される。リモートＵＥのサイドリンクＢＳＲは、特別なアップリンクデータとみなされ、リソースを要求するためのＵＬ ＢＳＲをトリガする。一方、リレーＵＥのサイドリンクＢＳＲは依然として従来のままである。一実施形態では、リモートＵＥのサイドリンクＢＳＲは、最高優先順位のアップリンクデータとみなすことができる。

一般に、ＳＲ送信のためのこの種のトリガは、リモートＵＥのサイドリンクＢＳＲに限定されなくてよい。リモートＵＥからのいくつかのトラフィックは、ＳＲ送信をトリガするイベントとして扱われてよい。本発明の概念は、アップリンクリソースが存在しない場合、リモートＵＥから送信されたＭＡＣ ＣＥがリレーＵＥ側でＳＲ送信をトリガできることである。具体的には、リレーＵＥがリモートＵＥからトランスポートブロックを受信するとき、トランスポートブロックは、サイドリンクＢＳＲ ＭＡＣ ＣＥ及び／又は電力ヘッドルームレポートＭＡＣ ＣＥを含む。このような種類のＣＥは時間に敏感であり、できるだけ早くｅＮＢに送信する必要がある。したがって、リレーＵＥは、このシナリオを新しいタイプの定期的なＢＳＲとみなしてよく、よって、利用可能なアップリンクリソースが存在しない場合にはＳＲ送信をトリガしてよい。より具体的には、トランスポートブロックがＭＡＣ ＳＤＵを含む場合、それらのＭＡＣ ＳＤＵは、最終的に、リレーＵＥ側で定期的なＢＳＲをトリガすることができる。したがって、本方法は、ＭＡＣ ＣＥのみを含む（すなわち、中継のためのＭＡＣ ＳＤＵもＭＡＣ ＳＤＵもない）リモートＵＥから送信されたトランスポートブロックに適用されるように、更に強化することができる。

或いは、リレーＵＥは、リモートＵＥから送信されたサイドリンクＢＳＲ ＭＡＣ ＣＥ及び／又は電力ヘッドルームレポートＭＡＣ ＣＥをより高い優先順位のデータとして扱い、アップリンクＢＳＲをトリガしてよい。アップリンクＢＳＲのバッファステータスは、サイドリンクＢＳＲ ＭＡＣ ＣＥ及び／又はパワーヘッドルームレポートＭＡＣ ＣＥのサイズを含む。

図２４は、一実施例に係る、デバイス間リレー通信をサポートする第１のＵＥの観点からのフローチャート２４００である。ステップ２４０５において、第１のＵＥが、第２のＵＥからトランスポートブロックを受信する。トランスポートブロックはＭＡＣ制御要素を含む。

一実施形態では、第１のＵＥはリレーＵＥとすることができ、第２のＵＥはリモートＵＥとすることができる。一実施形態では、デバイス間リレー通信は、第１のＵＥが、第２のＵＥのデータを基地局に中継することとすることができる。更に、デバイス間リレー通信は、第１のＵＥが、第２のＵＥのデータを基地局から第２のＵＥに中継することとすることができる。

一実施形態では、トランスポートブロックは、リレーされる必要のあるＭＡＣ ＳＤＵ（サービスデータユニット）を含まない。更に、ＭＡＣ制御要素は、サイドリンクのためのＭＡＣ制御要素とすることができる。

一実施形態では、ＭＡＣ ＳＤＵは、基地局に中継される第２のＵＥからのデータを指す。加えて、ＭＡＣ ＳＤＵは、基地局に中継されるＭＡＣ ＳＤＵであってよい。

ステップ２４１０において、第１のＵＥがＢＳＲをトリガする。ステップ２４１５において、第１のＵＥが送信可能なデータを有さず、ＢＳＲの送信のためのアップリンクリソースを有さない場合、第１のＵＥが、ＳＲ（スケジューリングリクエスト）をトリガし基地局に送信する。ステップ２４２０において、第１のＵＥがＢＳＲを基地局に送信する。ＢＳＲは、ＭＡＣ制御要素をバッファサイズの一部とみなす。

再び図３及び図４を参照する。第１のＵＥの例示的な一実施形態において、デバイス３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、第１のＵＥが、（ｉ）第２のＵＥからトランスポートブロックを受信することを可能にし、トランスポートブロックはＭＡＣ制御要素を含み、（ｉｉ）ＢＳＲ（バッファステータスレポート）をトリガすることを可能にし、ｉｉｉ）第１のＵＥが送信可能なデータを有さず、ＢＳＲの送信のためのアップリンクリソースを有さない場合、ＳＲ（スケジューリングリクエスト）をトリガし基地局に送信することを可能にし、（ｉｖ）ＢＳＲを基地局に送信することを可能にすることができる。ＢＳＲは、ＭＡＣ制御要素をバッファサイズの一部とみなす。更に、ＣＰＵ３０８は、プログラムコード３１２を実行して、上述した全てのアクション及びステップ又は本明細書に記載された他のものを実行することができる。

課題５及び解決策：上記の方法に基づいて、最終的に、リレーＵＥは、ｅＮＢからアップリンク付与を受信する。更に、リレーＵＥは、ＬＣＰ手順に基づいて、どのコンテンツがトランスポートブロックに含まれるかを決定する必要がある。この手順では、２つの潜在的な課題を処理する必要があります。第１に、リモートＵＥのサイドリンクＢＳＲのどの優先順位をＬＣＰ手順で考慮すべきか。第２に、リモートＵＥのサイドリンクＢＳＲを複数のＵＬグラントを介して送信することができるか。

第１の課題に関して、リレーＵＥにおけるリモートＵＥのサイドリンクＢＳＲに対する可能な優先順位の設定を以下に列挙する。

オプション１：リレーＵＥのＣＣＣＨ（共通制御チャネル）＞リレーＵＥのＢＳＲ＞リレーＵＥのＰＨＲ（電力ヘッドルームレポート）＞リレーＵＥのサイドリンクＢＳＲ＝リモートＵＥのサイドリンクＢＳＲ（ＬＣＧ又はＰＰＰＰに基づく）＞データ＞パディング。

オプション２：リレーＵＥのＣＣＣＨ＞リレーＵＥのＢＳＲ＞リレーＵＥのＰＨＲ＞リレーＵＥのサイドリンクＢＳＲ＞リモートＵＥのサイドリンクＢＳＲ＞データ＞パディング。

注：ＰＨＲは、拡張ＰＨＲ、ｄｕａｌＣｏｎｎｅｃｔｉｖｉｔｙＰＨＲ、或いは他の将来のアップリンク電力レポート関連制御要素であってもよい。

しかしながら、不十分なアップリンク付与の場合を考慮して、リモートＵＥのサイドリンクＢＳＲは、アップリンク付与に従って作成されるＴＢ（トランスポートブロック）に部分的に含まれてよい。通常、ＵＥは、より重要な情報（例えば、より高い優先度）を可能な限りＴＢに含める。しかしながら、リモートＵＥから受信したサイドリンクＢＳＲ又はＭＡＣ ＳＤＵに関して、リレーＵＥは、そのような受信された情報の優先順位を理解できない場合がある。例えば、従来では、サイドリンクＢＳＲには多くのＬＣＧ（論理チャネルグループ）が含まれ、各ＬＣＧは特定の論理チャネル優先度セットに関連付けられる。この関連付けは、ｅＮＢによって決定され、ＵＥに対して専用に構成される。以前の状態では、リレーＵＥがリモートＵＥからサイドリンクＢＳＲを受信すると、リレーＵＥは、ＬＣＧと論理チャネル優先度（例えばＰＰＰＰ（Pro-Se Per Packet Priority））との間の関連を知らないので、情報のどの部分が最初に含まれているかを決定することができない。したがって、ｅＮＢは、できるだけ早く重要な情報を得ることができない可能性がある。この問題を解決するために、ｅＮＢは、リレーＵＥが包含順序の適切な決定を行えるように、リレーＵＥにリモートＵＥの関連付けを提供することができる。リレーＵＥは、オプション１とオプション２の両方について、関連付けを考慮する。更に、オプション１では、リレーＵＥは、ＬＣＧと論理チャネル優先度との間のリモートＵＥの関連付けと自身の関連付けの両方を更に考慮する。

更に、リレーＵＥがリモートＵＥのバッファステータスを転送しない場合であっても、リモートＵＥの構成情報をリレーＵＥに提供することは、リモートＵＥから受信したサイドリンクＢＳＲ内の各ＬＣＧの優先順位をリレーＵＥが正しく理解するのに有益であろう。それに基づいて、リレーＵＥは、バッファステータスを再編成し、情報を課題６（以下で議論する）の解決策として更新してもよいし、リソースをリモートＵＥのより高い優先度のデータに直接スケジューリングしてもよい。或いは、構成を調整し更には構成を理解するために、リレーＵＥがそのＬＣＧ／ＰＰＰＰ構成（上述）をリモートＵＥに渡すことによって行うことができる。

リレーＵＥは、リレーＵＥの優先順位付け規則に従って、リモートＵＥから受信した任意の制御要素又はパッカーを処理することができる。或いは、リモートＵＥの構成の理解を調整するために、全てのＵＥにブロードキャストすることができる。このようにして、リレーＵＥは情報を共有することができる。一実施形態では、リレーＵＥは、ブロードキャストメッセージ内で構成を適用しない。或いは、リレーＵＥは、ブロードキャストメッセージに同じ構成を適用することができる。

一方、リレーＵＥが包含順序を決定する場合、リレーＵＥは、上述の場合に対して、リモートＵＥから受信した部分的なサイドリンクＢＳＲ情報をＴＢに含める。ＵＥはまた、部分的なサイドリンクＢＳＲを少し変更して含めてよい。例えば、新しいＭＡＣサブヘッダを置き換えることや、他の目的のために部分的なサイドリンクＢＳＲに追加の指示を追加することができる。

不十分なアップリンク付与の場合について、ネットワークは、アップリンクＢＳＲ、リレーＵＥのサイドリンクＢＳＲ及びリモートＵＥのサイドリンクＢＳＲを収容するための十分なアップリンク付与を提供しない場合があるので、リレーＵＥは、これらのＢＳＲの一部をＴＢに含める。従来の設計に従えば、サイドリンク ＢＳＲを部分的にＴＢに含めることができ、含まれる部分のサブヘッダは、残りの部分が存在することをｅＮＢに知らせるために、トランケーテッドサイドリンクＢＳＲに設定されるものとする。このメカニズムは、新しいタイプのＢＳＲ、例えばリモートＵＥのサイドリンクＢＳＲで再使用することもできることは妥当であろう。しかしながら、含まれる全てのＢＳＲが完全なＢＳＲである場合に問題が発生する可能性があるが、一部の新しいタイプのレギュラーＢＳＲが残っている可能性がある。そのような場合、該タイプのレギュラーＢＳＲは自律的にＳＲをトリガすることができるが、そのようなメカニズムに依存することには、いくつかのペナルティ（例えば冗長ＳＲ送信、遅延等）をある可能性がある。

この問題を解決するひとつの方法は、ＵＥに保留中の制御要素が存在することを表すための新しいＬＣＩＤを定義することである。一実施形態では、新しいＬＣＩＤは、ＢＳＲのサブヘッダで使用することができる。加えて、ＢＳＲはサイドリンクＢＳＲであってよく、サイドリンクＢＳＲは、リモートＵＥから転送のために受信されたサイドリンクＢＳＲであってよい。

別の実施例では、新しいＬＣＩＤは、ＢＳＲのバッファステータスが既に制御要素を考慮しているか否かを示すために用いることができる。一実施形態では、サイドリンクＢＳＲがＴＢに不完全に含まれる場合、ＵＥは新しいＬＣＩＤをサイドリンクＢＳＲに設定しない。

別の実施形態では、新しいＬＣＩＤは新しいＭＡＣ制御要素で用いられてよい。加えて、新しいＭＡＣ制御要素は、いくつの保留中の制御要素がＵＥ（例えばリレーＵＥ）内に存在するかを示すことができる。一実施形態では、保留中の制御要素は、サイドリンクＢＳＲ制御要素であってよい。加えて、保留中の制御要素は、他のＵＥから受信された制御要素であってよい。更に、保留中の制御要素は、ＵＥ内の制御要素（例えばＰＨＲ ＣＥ、Ｓｉｄｅｌｉｎｋ ＢＳＲ ＣＥ等）であってよい。

一実施形態では、新しいＭＡＣ制御要素は、現在のＬＣＰ手順においてＢＳＲ制御要素よりも高い優先度を有する。別の実施形態では、新しいＭＡＣ制御要素は、現在のＬＣＰ手順においてサイドリンクＢＳＲ制御要素よりも高い優先度を有する。更に別の実施形態では、新しいＭＡＣ制御要素は、現在のＬＣＰ手順においてアップリンクＰＨＲ制御要素よりも高い優先度を有する。

この問題を解決する別の方法は、同じか類似する目的の複数の制御要素を示すために、全てのリモートＵＥのサイドリンクＢＳＲ ＣＥがＭＡＣサブヘッダを共有するようにすることである。一実施形態では、新しいＭＡＣサブヘッダは、どのターゲットＵＥの制御要素かを指示するためのフィールドと、同じターゲットＵＥのバッファステータス制御要素の境界又は番号を示すための別のフィールドとを含むことができる。例示的な実施形態を図２５に示す。図２５において、リモートＵＥインデックスは、ｅＮＢが制御要素の所属を識別するためのものである。各ＬＣＧペア（例えば、宛先インデックス＋ＬＣＧ＋バッファサイズ）は同じ長さを有するので、ＬＣＧ番号のフィールドは、制御要素の長さ又は境界を示すことができる。

課題６及び解決策：ｅＮＢがリモートＵＥのリソース需要に関する情報を取得するための別のメカニズムは、リレーＵＥがリモートＵＥの要求のためにサイドリンクＢＳＲをトリガし報告することである。このメカニズムを用いると、リモートＵＥは従来のサイドリンクＢＳＲメカニズムを維持する。しかしながら、トリガされたサイドリンクＢＳＲは、ＰＣ５インタフェースを介してリレーＵＥに送信される。詳細は、上記の関連コンテンツを参照することができる。

リレーＵＥがリモートＵＥからサイドリンクＢＳＲを受信するとき、リモートＵＥからのサイドリンクＢＳＲの内容は、リレーＵＥによってリンクの新しいタイプの利用可能データとみなされる。従来のサイドリンクＢＳＲメカニズムに従うと、リレーＵＥは、新しいタイプの利用可能なデータをリレーＵＥのサイドリンクＢＳＲに反映し、サイドリンクリソースを要求するために、リレーＵＥのサイドリンクＢＳＲを基地局に送信する。更に、リレーＵＥはリモートＵＥのデータを実際に所有していないので、リレーＵＥは、リモートＵＥからサイドリンクＢＳＲを受信するとき、新しいタイプの利用可能なデータのバッファステータスを最新の状態に更新する必要がある。

一実施形態では、基地局は、リレーＵＥのサイドリンクＢＳＲに基づいてリレーＵＥにリソースをスケジュールすることができる。更に、リレーＵＥは、スケジュールされたサイドリンクリソースの一部又は全部をリモートＵＥに提供してよい。或いは、基地局は、リモートＵＥにリソースを直接スケジューリングすることができる。例示的な実施形態を図２６に示す。この場合のＳｉｄｅｌｉｎｋのＬＣＰ手順に関して、リレーＵＥは、受信されたＳＬ付与をどのように用いるかを決定する必要があるかもしれない。リレーＵＥが、リレーリンク（例えばＰＰＰＰ情報に基づく、ＬＣＧ）の新しいタイプの利用可能なデータに対して、受信されたＳＬ付与を使用することを決定した場合、リレーＵＥは、受信されたＳＬ付与をリモートＵＥに提供する。

この解決策の主な利点は、リモートＵＥのバッファステータスをリレーＵＥのバッファステータスと区別するために、Ｕｕインタフェース上に新しいＭＡＣ ＣＥを作成することを避けることである。しかしながら、この解決策には２つの潜在的な欠点がある。第１に、基地局が、受信されたサイドリンクＢＳＲにおいて、リモートＵＥのバッファステータスをリレーＵＥのバッファステータスと区別することが困難であるかもしれない。よって、リレーＵＥとリモートＵＥとの間のリンクのためのスケジューリングは、リソースの浪費のリスクを有する可能性がある。第２に、リモートＵＥは、この方法によって他のＰＣ５リンクリソースを要求することができない。

第１の欠点に関して、ペナルティを緩和するための可能な方法がいくつか存在する。ひとつの可能な方法は、リモートＵＥとリレーＵＥのバッファステータスをリンクの異なるＬＣＧに分離することである。これは、基地局構成によって達成することができる。例示的な実施形態を図２７に示す。

別の可能な方法は、リモートＵＥ及びリレーＵＥのバッファステータスを異なるサイドリンクＢＳＲに分離することである。この方法を達成するために、リレーＵＥは、リモートＵＥのバッファステータスを報告するために別のリンクを作成する必要がある。したがって、リレーＵＥはSidelinkUEInformationを介して、中継セッションのＤＬ方向のための１つのリンク（従来の設計に従って行われる）と、中継セッションのＵＬ方向の１つのリンク（例えば、リレーＵＥのProSe UE IDをdestinationInfoListに含めるか、commTxResourceReqRelayに類似した新しいＩＥを作成する）とを含む、中継セッションのための２つのリンクを報告してよい。

リレーＵＥが中継セッションに関連付けられたリモートＵＥからサイドリンクＢＳＲを受信するとき、サイドリンクＢＳＲのバッファステータスは、中継セッションのＵＬ方向を表すリンクの新しい利用可能データとみなされる。この実施形態の例を図２８及び図２９に示す。リレーＵＥは、ＳＬ付与を受信し、それを中継セッションのＵＬ方向を表すリンク上で使用することを決定したとき、中継セッションに関連するリモートＵＥにＳＬ付与を提供してよい。

図３０は、一実施例に係るフローチャート３０００である。ステップ３００５では、第１のＵＥが、ＢＳＲの宛先インデックスと第２のＵＥのリンクとの関連を確立するために、メッセージを基地局に送信する。第２のＵＥはリンクのソースである。ステップ３０１０では、第１のＵＥが、ＢＳＲをトリガし基地局に送信する。宛先インデックス関連バッファステータスは、リンクに対する第２のＵＥのリソース要求を含む。

一実施形態では、メッセージは、第２のＵＥの識別情報を含むことができる。或いは、メッセージは、第１のＵＥの識別情報と第２のＵＥの識別情報をペアとして含むことができる。加えて、メッセージは、宛先インデックス及び第２のＵＥの識別情報を含むことができる。更に、メッセージは、SidelinkUEInformation又はＲＲＣ（無線リソース制御）メッセージであってよい。

一実施形態では、第１のＵＥがＢＳＲを送信するとき、第２のＵＥのバッファステータスに関連するデータは、第２のＵＥにおいて保留中であってよい。更に、ＢＳＲはサイドリンクＢＳＲであってよい。加えて、第２のＵＥのリンクは、第２のＵＥからデバイス間インタフェースを介して別のＵＥ（第１のＵＥを含む）にデータを転送するためのものであってよい。

再び図３及び図４を参照する。第１のＵＥの例示的な一実施形態において、デバイス３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、第１のＵＥが、（ｉ）ＢＳＲの宛先インデックスと第２のＵＥのリンクとの関連を確立するために、メッセージを基地局に送信することを可能にし、第２のＵＥはリンクのソースであり、（ｉｉ）ＢＳＲをトリガし基地局に送信することを可能にし、宛先インデックス関連バッファステータスは、リンクに対する第２のＵＥのリソース要求を含む。更に、ＣＰＵ３０８は、プログラムコード３１２を実行して、上述した全てのアクション及びステップ又は本明細書に記載された他のものを実行することができる。

図３１は、一実施例に係る、ＵＥの観点からのフローチャート３１００である。ステップ３１０５において、第１のＵＥが、ＢＳＲの宛先インデックスと第２のＵＥのリンクとの関連を確立するために、基地局から構成を受信する。第２のＵＥはリンクのソースである。

一実施形態では、構成は、第２のＵＥの識別情報（例えばProSe UE ID）、ペアとしての第１のＵＥの識別情報及び第２のＵＥの識別情報、並びに／又は、宛先インデックス及び第２のＵＥの識別情報を含んでよい。更に、構成は、RRCConnectionReconfiguration又はＲＲＣメッセージに含めることができる。

ステップ３１１０において、第１のＵＥが、ＢＳＲをトリガし基地局に送信する。宛先インデックス関連バッファステータスは、リンクに対する第２のＵＥのリソース要求を含む。一実施形態では、第１のＵＥはリレーＵＥとすることができ、第２のＵＥはリモートＵＥとすることができる。

一実施形態では、デバイス間リレー通信は、第１のＵＥが、第２のＵＥのデータを基地局に中継することとすることができる。或いは、デバイス間リレー通信は、第１のＵＥが、第２のＵＥのデータを基地局から第２のＵＥに中継することとすることができる。

一実施形態では、第２のＵＥのリンクは、第２のＵＥがメッセージを第１のＵＥに送信するためのリンクとすることができる。或いは、第２のＵＥのリンクは、第２のＵＥが中継のためにメッセージを第１のＵＥに送信するためのリンクである。

再び図３及び図４を参照する。第１のＵＥの例示的な一実施形態において、デバイス３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、第１のＵＥが、（ｉ）ＢＳＲの宛先インデックスと第２のＵＥのリンクとの関連を確立するために、基地局から構成を受信することを可能にし、（ｉｉ）ＢＳＲをトリガし基地局に送信することを可能にし、宛先インデックス関連バッファステータスは、リンクに対する第２のＵＥのリソース要求を含む。ＢＳＲは、ＭＡＣ制御要素をバッファサイズの一部とみなす。更に、ＣＰＵ３０８は、プログラムコード３１２を実行して、上述した全てのアクション及びステップ又は本明細書に記載された他のものを実行することができる。

本開示の様々な態様を上記で説明した。本明細書における教示は、広範な様々な形態で具体化することができ、本明細書に開示された任意の具体的な構造、機能又はその両方は、代表的なものにすぎないことは明らかである。本明細書の教示に基づいて、当業者は、本明細書で開示された態様が任意の他の態様から独立して実施することができ、これらの態様の２つ以上を様々な方法で組み合わせられることを理解すべきである。例えば、本明細書に記載の任意の数の態様を採用して、装置を実施してよく、或いは方法を実施してよい。加えて、本明細書に記載の態様の１つ以上に加えて、或いはそれ以外に、他の構造、機能又は構造及び機能を採用して、係る装置を実施してよく、或いは係る方法を実施してよい。上記の概念の一部の例として、一部の態様では、パルス繰返し周波数に基づいて同時チャネルを確立することができる。一部の態様では、パルス位置又はオフセットに基づいて同時チャネルを確立することができる。一部の態様では、時間ホッピングシーケンスに基づいて同時チャネルを確立することができる。一部の態様では、パルス繰返し周波数と、パルス位置又はオフセットと、時間ホッピングシーケンスとに基づいて、同時チャネルを確立することができる。

当業者であれば、様々な異なる技術と技法のうちいずれかを用いて情報及び信号を表すことができることを理解するであろう。例えば、上記の説明を通して参照することのできるデータ、命令、コマンド、情報、信号、ビット、シンボル及びチップは、電圧、電流、電磁波、磁場又は粒子、光学フィールド又は粒子、或いはそれらの任意の組合わせによって表されてよい。

当業者であれば、本明細書で開示された態様に関連して説明された様々な例示的な論理ブロック、モジュール、プロセッサ、手段、回路及びアルゴリズムステップは、電子ハードウェア（例えば、ソースコーディングその他の何らかの技法を用いて設計することのできるデジタル実装、アナログ実装、或いはその２つの組合わせ）、命令を組み込んだ様々な形態のプログラム又は設計コード（便宜上、「ソフトウェア」又は「ソフトウェアモジュール」と呼ばれることがある）、或いは両方の組合わせとして実施されてよいことが更に理解できるであろう。このようなハードウェアとソフトウェアとの互換性を明確に説明するために、様々な例示的なコンポーネント、ブロック、モジュール、回路及びステップを、一般にそれらの機能性に関して上記で説明した。そのような機能性がハードウェア又はソフトウェアとして実装されるかどうかは、システム全体に課される特定の適用及び設計の制約に依存する。当業者であれば、説明した機能を特定の適用ごとに様々な方法で実施することができるが、そのような実施の決定は、本開示の範囲から逸脱するものと解釈されるべきではない。

加えて、本明細書で開示された態様に関連して説明された様々な例示の論理ブロック、モジュール及び回路は、集積回路（“ＩＣ”）、アクセス端末又はアクセスポイント内で実施されてよく、或いはこれらによって実行されてよい。ＩＣは、本明細書で説明された機能を実行するように設計された汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）その他のプログラマブル論理デバイス、ディスクリートゲート又はトランジスタロジック、ディスクリートハードウェアコンポーネント、電気部品、光学部品、機械部品、又はそれらの任意の組合わせを含み、ＩＣ内、ＩＣ外又はその両方に存在するコード又は命令を実行してよい。汎用プロセッサはマイクロプロセッサであってよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ又は状態機械であってよい。プロセッサはまた、コンピューティングデバイスの組合わせとして実施されてよく、例えば、ＤＳＰとマイクロプロセッサとの組合わせ、複数のマイクロプロセッサ、ＤＳＰコアと組み合わせた１つ以上のマイクロプロセッサ、その他のそのような構成として実施されてよい。

任意の開示されたプロセスにおけるステップの具体的な順序又は階層は、サンプルアプローチの一例であることが理解される。設計嗜好に基づき、プロセスにおけるステップの具体的な順序又は階層は、本開示の範囲内に留まれば再編成されてよいことが理解される。添付の方法の請求項は、様々なステップの要素をサンプル順に提示し、提示される具体的な順序又は階層に限定されることを意味しない。

本明細書で開示された態様に関連して説明された方法又はアルゴリズムのステップは、ハードウェア、プロセッサによって実行されるソフトウェアモジュール、又はその２つの組合わせで直接的に実施されてよい。ソフトウェアモジュール（例えば、実行可能命令及び関連データを含む）その他のデータは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭその他の、従来技術において既知のコンピュータ可読記憶媒体の任意の形態等のデータメモリに存在してよい。サンプル記憶媒体は、例えばコンピュータ／プロセッサ（本明細書では便宜上「プロセッサ」と呼ばれることがある）のような機械に結合されてよく、そのようなプロセッサは、記憶媒体から情報（例えばコード）を読み取り、記憶媒体に情報を書き込むことができる。サンプル記憶媒体は、プロセッサに一体化されてよい。プロセッサ及び記憶媒体は、ＡＳＩＣ内に存在してよい。ＡＳＩＣは、ユーザ装置内に存在してよい。或いは、プロセッサ及び記憶媒体は、ユーザ装置内のディスクリートコンポーネントとして存在してよい。更に、いくつかの態様では、任意の適切なコンピュータプログラム製品が、本開示の１つ以上の態様に関連するコードを含むコンピュータ可読記憶媒体を備えてよい。一部の態様では、コンピュータプログラム製品は、包装材料を含んでよい。

様々な態様に関連して本発明を説明してきたが、本発明は更なる変更が可能であることが理解されるであろう。本願は、一般に本発明の原理に従い、本発明が関連する技術分野における既知の習慣的な実施の範囲内にある本開示からの逸脱を含む、本発明のあらゆる変形、使用又は適合を包含するものである。

Claims (20)

1. 無線通信システムにおけるデバイス間リレー通信をサポートするための第１のＵＥ（User Equipment、ユーザ装置）の方法であって、
   前記第１のＵＥが、第２のＵＥからトランスポートブロックを受信するステップであって、前記トランスポートブロックはＭＡＣ（Media Access Control、媒体アクセス制御）制御要素を含む、ステップと、
   前記第１のＵＥが、ＢＳＲ（Buffer Status Report、バッファステータスレポート）をトリガし基地局に送信するステップであって、前記ＢＳＲは、前記ＭＡＣ制御要素をバッファサイズの一部とみなす、ステップと、
   を含む方法。
2. 前記第１のＵＥが送信可能なデータを有さず、前記ＢＳＲの送信のためのアップリンクリソースを有さない場合、前記第１のＵＥが、ＳＲ（Scheduling Request、スケジューリングリクエスト）をトリガし前記基地局に送信する、
   請求項１に記載の方法。
3. 前記トランスポートブロックは、リレーされる必要のあるＭＡＣ ＳＤＵ（Service Data Unit、サービスデータユニット）を含まない、
   請求項１に記載の方法。
4. 前記ＭＡＣ制御要素は、サイドリンク又はアップリンクＢＳＲのためのＭＡＣ制御要素、又は新しいタイプのＢＳＲ制御要素である、
   請求項１に記載の方法。
5. 無線通信システムにおけるデバイス間通信をサポートする方法であって、
   第１のＵＥ（ユーザ装置）が、ＢＳＲ（バッファステータスレポート）の宛先インデックスと第２のＵＥのリンクとの関連を確立するために、メッセージを基地局に送信するステップであって、前記第２のＵＥは前記リンクのソースである、ステップと、
   前記第１のＵＥが、ＢＳＲをトリガし前記基地局に送信するステップであって、前記宛先インデックス関連バッファステータスは、前記リンクに対する前記第２のＵＥのリソース要求を含み、前記第１のＵＥは前記第２のＵＥではない、ステップと、
   を含む、方法。
6. 前記メッセージは、前記第２のＵＥの識別情報を含む、
   請求項５に記載の方法。
7. 前記メッセージは、前記第１のＵＥの識別情報と前記第２のＵＥの識別情報をペアとして含む、
   請求項５に記載の方法。
8. 前記第１のＵＥが前記ＢＳＲを送信するとき、前記リンクに関する前記第２のＵＥの前記バッファステータスに関連するデータは、前記第２のＵＥにおいて保留中である、
   請求項５に記載の方法。
9. 前記ＢＳＲは、サイドリンクＢＳＲ、又はアップリンクＢＳＲ、又は新しいタイプのＢＳＲ制御要素である、
   請求項５に記載の方法。
10. 前記第２のＵＥの前記リンクは、デバイス間インタフェースを介して前記第２のＵＥから別のＵＥ（前記第１のＵＥを含む）にデータを転送するためのものである、
    請求項５に記載の方法。
11. 制御回路と、
    前記制御回路に設けられたプロセッサと、
    前記制御回路に設けられ、且つ前記プロセッサに動作可能に結合されたメモリと、
    を備える第１のユーザ装置（User Equipment、UE）であって、
    前記プロセッサは、前記メモリに記憶されたプログラムコードを実行して、
    第２のＵＥからトランスポートブロックを受信するように構成され、前記トランスポートブロックは媒体アクセス制御（Media Access Control、ＭＡＣ）制御要素を含み、且つ、
    バッファステータスレポート（Buffer Status Report、ＢＳＲ）をトリガし基地局に送信するように構成され、前記ＢＳＲは、前記ＭＡＣ制御要素をバッファサイズの一部とみなす、
    第１のＵＥ。
12. 前記第１のＵＥが送信可能なデータを有さず、前記ＢＳＲの送信のためのアップリンクリソースを有さない場合、前記第１のＵＥが、スケジューリングリクエスト（Scheduling Request、ＳＲ）をトリガし前記基地局に送信する、
    請求項１１に記載の第１のＵＥ。
13. 前記トランスポートブロックは、リレーされる必要のあるサービスデータユニット（Service Data Unit、ＭＡＣ ＳＤＵ）を含まない、
    請求項１１に記載の第１のＵＥ。
14. 前記ＭＡＣ制御要素は、サイドリンクのためのＭＡＣ制御要素、又はアップリンクＢＳＲ、又は新しいタイプのＢＳＲ制御要素である、
    請求項１１に記載の第１のＵＥ。
15. 制御回路と、
    前記制御回路に設けられたプロセッサと、
    前記制御回路に設けられ、且つ前記プロセッサに動作可能に結合されたメモリと、
    を備える第１のユーザ装置（User Equipment、UE）であって、
    前記プロセッサは、前記メモリに記憶されたプログラムコードを実行して、
    バッファステータスレポート（Buffer Status Report、ＢＳＲ）の宛先インデックスと第２のＵＥのリンクとの関連を確立するために、メッセージを基地局に送信するように構成され、前記第２のＵＥは前記リンクのソースであり、且つ、
    ＢＳＲをトリガし前記基地局に送信するように構成され、前記宛先インデックス関連バッファステータスは、前記リンクに対する前記第２のＵＥのリソース要求を含み、前記第１のＵＥは前記第２のＵＥではない、
    第１のＵＥ。
16. 前記メッセージは、前記第２のＵＥの識別情報を含む、
    請求項１５に記載の第１のＵＥ。
17. 前記メッセージは、前記第１のＵＥの識別情報と前記第２のＵＥの識別情報をペアとして含む、
    請求項１５に記載の第１のＵＥ。
18. 前記第１のＵＥが前記ＢＳＲを送信するとき、前記リンクに関する前記第２のＵＥの前記バッファステータスに関連するデータは、前記第２のＵＥにおいて保留中である、
    請求項１５に記載の第１のＵＥ。
19. 前記ＢＳＲは、サイドリンクＢＳＲ、又はアップリンクＢＳＲ、又は新しいタイプのＢＳＲ制御要素である、
    請求項１５に記載の第１のＵＥ。
20. 前記第２のＵＥの前記リンクは、デバイス間インタフェースを介して前記第２のＵＥから別のＵＥ（前記第１のＵＥを含む）にデータを転送するためのものである、
    請求項１５に記載の第１のＵＥ。

Images