JP6997852B2

JP6997852B2 - 無線通信システムにおいてサイドリンク送信リソースを要求するための方法及び機器

Info

Publication number: JP6997852B2
Application number: JP2020205568A
Authority: JP
Inventors: 立▲徳▼ 潘; 豊旗郭
Original assignee: Asustek Computer Inc
Current assignee: Asustek Computer Inc
Priority date: 2020-01-07
Filing date: 2020-12-11
Publication date: 2022-01-18
Anticipated expiration: 2040-12-11
Also published as: TW202127944A; US20220132359A1; US11071006B1; CN113163454B; JP2021111967A; CN113163454A; KR102266530B1; US20210211924A1; TWI742962B; ES2932964T3; EP3849237A1; EP3849237B1

Description

関連出願への相互参照
本願は、２０２０年１月７日に出願された米国仮特許出願第６２／９５８，０６１号の利益を主張するものであり、この文献の開示全体は、その全体が参照により本明細書に組み込まれる。

本開示は、概して、無線通信ネットワーク、より具体的には、無線通信システムにおいてサイドリンク送信リソースを要求するための方法及び機器に関する。

移動通信装置同士の間の大量のデータの通信に対する需要の急速な増大に伴い、従来の移動音声通信ネットワークは、インターネットプロトコル（ＩＰ）データパケットを使用して通信するネットワークに進化している。このようなＩＰデータパケット通信は、モバイル通信装置のユーザにVoice over IP、マルチメディア、マルチキャスト、及びオンデマンド通信サービスを提供できる。

例示的なネットワーク構造は、進化型ユニバーサル地上無線アクセスネットワーク（Ｅ－ＵＴＲＡＮ）である。Ｅ－ＵＴＲＡＮシステムは、上記のVoice over IP及びマルチメディアサービスを実現するために、高いデータスループットを提供できる。次世代の新しい無線技術（例えば、５Ｇ）は、現在３ＧＰＰ規格化団体によって議論されている。従って、３ＧＰＰ規格の現在の主要部への変更が現在提出されており、３ＧＰＰ規格を進化させて完成させることを検討している。

専用のサイドリンク構成を要求する第１のユーザ機器（ＵＥ）の観点からの方法及び機器を開示する。一実施形態では、この方法は、第１のＵＥが第１の無線リソース制御（ＲＲＣ）メッセージをネットワークノードに送信するステップを含み、第１のＲＲＣメッセージはサイドリンクサービス品質（ＱｏＳ）情報を含み、サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのＩＤ（アイデンティティ：識別情報）の存在（presence）が必須であり、サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのＱｏＳプロファイルの存在が随意である。この方法は、第１のＵＥがネットワークノードから第２のＲＲＣメッセージを受信するステップも含み、第２のＲＲＣメッセージは、専用のサイドリンク構成と、専用のサイドリンク構成に関連付けられたサイドリンクＱｏＳフローのＩＤとを含む。

例示的な一実施形態による無線通信システムの図である。例示的な一実施形態による、送信機システム（アクセスネットワークとしても知られている）及び受信機システム（ユーザ機器又はＵＥとしても知られている）のブロック図である。例示的な一実施形態による通信システムの機能ブロック図である。例示的な一実施形態による図３のプログラムコードの機能ブロック図である。３ＧＰＰＴＳ２３．２８７Ｖ１６．０．０の図５．２．１．４－１の写しである。３ＧＰＰＴＳ２３．２８７Ｖ１６．０．０の図６．３．３．１－１の写しである。３ＧＰＰＴＲ３８．８８５Ｖ１６．０．０の図７－１の写しである。３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）で提供される図５．Ｘ．３．１－１の写しである。３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）の図５．Ｘ．９．１．１－１の写しである。３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）の図５．Ｘ．９．１．１－２の写しである。３ＧＰＰＴＳ３８．３２３Ｖ１５．２．０の図６．２．３．２－１の写しである。例示的な一実施形態によるフローチャートである。例示的な一実施形態によるフローチャートである。例示的な一実施形態によるフローチャートである。例示的な一実施形態によるフローチャートである。

以下に説明する例示的な無線通信システム及び装置は、ブロードキャストサービスをサポートする無線通信システムを使用している。無線通信システムは、音声及びデータ等の様々なタイプの通信を提供するために広く展開されている。これらのシステムは、符号分割多元接続（CDMA）、時分割多元接続（TDMA）、直交周波数分割多元接続（OFDMA）、３ＧＰＰＬＴＥ（Long Term Evolution）無線アクセス、３ＧＰＰＬＴＥ－Ａ又はＬＴＥ－Ａｄｖａｎｃｅｄ（Long Term Evolution Advanced）、３ＧＰＰ２ＵＭＢ（Ultra
Mobile Broadband）、ＷｉＭａｘ（登録商標）、３ＧＰＰＮＲ（New Radio）、又はいくつかの他の変調技術に基づき得る。

特に、以下に説明する例示的な無線通信システム装置は、本明細書で３ＧＰＰと呼ばれる「第３世代パートナーシッププロジェクト」と名付けられたコンソーシアムによって提供される規格等の１つ又は複数の規格をサポートするように設計され得、その規格は、ＴＳ２３．２８７Ｖ１６．０．０、“Architecture enhancements for 5G System (5GS) to support
Vehicle-to-Everything (V2X) series (Release 16)”；ＴＲ３８．８８５Ｖ１６．０．０、“NR； Study on NR Vehicle-to-Everything (V2X) (Release 16)”；Ｒ２－１９０８１０７、“Report from session on LTE V2X and NR V2X”；Ｒ２－１９１６２８８、“Report from session on LTE V2X and NR V2X”；３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）、draft_R2-191xxx_Running CR to ＴＳ３８．３３１ for 5G V2X with NR Sidelink_v１；ＴＳ３８．３２２Ｖ１５．１．０、“NR；
Radio Link Control (RLC) protocol specification (Release 15)”；及びＴＳ３８．３２３Ｖ１５．２．０、“NR； Packet Data Convergence Protocol (PDCP) protocol specification
(Release 15)”を含む。上記の規格及び文書は、その全体が参照により明示的に組み込まれる。

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

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

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

アクセスネットワーク（ＡＮ）は、端末と通信するために使用される固定局又は基地局であり得、アクセスポイント、ノードＢ、基地局、拡張型基地局、進化型ノードＢ（eNB）、又は他の用語で呼ばれることもある。アクセス端末（ＡＴ）は、ユーザ機器（UE）、無線通信装置、端末、アクセス端末、又は他の用語と呼ばれることもある。

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

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

各データストリームに関するコード化したデータは、ＯＦＤＭ技術を使用してパイロットデータと共に多重化され得る。パイロットデータは、典型的に、既知の方法で処理される既知のデータパターンであり、受信機システムでチャネル応答を推定するために使用できる。次に、各データストリームに関する多重化したパイロットデータ及びコード化したデータは、そのデータストリームに対して選択された特定の変調方式（例えば、ＢＰＳＫ、ＱＰＳＫ、Ｍ－ＰＳＫ、又はＭ－ＱＡＭ等）に基づいて変調（つまり、シンボルマッピング）され、変調シンボルを提供する。各データストリームのデータレート、コード化、及び変調は、プロセッサ２３０によって実行される命令によって決定され得る。

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

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

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

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

プロセッサ２７０は、どのプリコーディング・マトリックスを使用するかを定期的に決定する（以下で説明する）。プロセッサ２７０は、マトリックス・インデックス部分及びランク値部分を含む逆方向リンクメッセージを作成する。

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

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

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

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

３ＧＰＰＴＳ２３．２８７は、ユニキャストモードに関連するＶ２Ｘ（車両から全ての物）通信を以下のように指定している。
５．２．１．４ＰＣ５参照点を介したユニキャストモード通信
ユニキャスト通信モードは、ＮＲベースのＰＣ５参照点を介してのみサポートされる。図５．２．１．４－１に、ＰＣ５ユニキャストリンクの例が示される。
［“Example of PC5 Unicast Links”という表題の３ＧＰＰＴＳ２３．２８７Ｖ１６．０．０の図５．２．１．４－１を、図５として再現する。］
ＰＣ５ユニキャストリンクを介してＶ２Ｘ通信を伝送する場合に、次の原則が適用される。
－２つのＵＥの間のＰＣ５ユニキャストリンクにより、これらのＵＥにおけるピアＶ２Ｘサービスの１つ又は複数のペアの間のＶ２Ｘ通信が可能になる。同じＰＣ５ユニキャストリンクを使用するＵＥにおける全てのＶ２Ｘサービスは、同じアプリケーション層ＩＤを使用する。
注１：アプリケーション層ＩＤは、プライバシーのために、５．６．１．１項及び６．３．３．２項で説明しているように時間とともに変更される場合がある。これにより、ＰＣ５ユニキャストリンクが再確立されることはない。
－１つのＰＣ５ユニキャストリンクは、これらのＶ２Ｘサービスが少なくともこのＰＣ５ユニキャストリンクのピア・アプリケーション層ＩＤのペアに関連付けられる場合に、１つ又は複数のＶ２Ｘサービス（例えば、ＰＳＩＤ又はＩＴＳ－ＡＩＤ）をサポートする。例えば、図５．２．１．４－１に示されるように、ＵＥＡ及びＵＥＢには２つのＰＣ５ユニキャストリンクがあり、１つはピア・アプリケーション層ＩＤ１／ＵＥＡとアプリケーション層ＩＤ２／ＵＥＢとの間にあり、もう１つはピア・アプリケーション層ＩＤ３／ＵＥＡとアプリケーション層ＩＤ４／ＵＥＢとの間にある。
注２：送信元（source）ＵＥは、異なるＰＣ５ユニキャストリンク上の異なるターゲットアプリケーション層ＩＤが同じターゲットＵＥに属しているかどうかを知る必要はない。
－ＰＣ５ユニキャストリンクは、単一のネットワーク層プロトコル、例えばＩＰ又は非ＩＰを使用したＶ２Ｘ通信をサポートする。
－ＰＣ５ユニキャストリンクは、ＵＥのアプリケーション層がＶ２Ｘサービスのデータ転送を開始すると、ＰＣ５参照点を介したユニキャスト通信モードが必要になる５．４．１項で指定されるフロー毎のＱｏＳモデルをサポートする。
－ピア・アプリケーション層ＩＤのペアとこのＰＣ５ユニキャストリンクのネットワーク層プロトコルとがこのＶ２ＸサービスのためにＵＥのアプリケーション層に必要なものと同一である場合に、ＵＥは、既存のＰＣ５ユニキャストリンクを再利用し、既存のＰＣ５ユニキャストリンクを変更して、６．３．３．４項で指定されるようにこのＶ２Ｘサービスを追加する必要がある。そうでなければ、
－ＵＥは、６．３．３．１項で指定されるように、新しいＰＣ５ユニキャストリンクの確立をトリガーする必要がある。
ＰＣ５ユニキャストリンクの確立が成功した後に、ＵＥＡ及びＵＥＢは、５．６．１．４項で指定されるように、後続のＰＣ５－Ｓシグナリングメッセージ交換及びＶ２Ｘサービスデータ送信に同じペアのレイヤ２ＩＤを使用する。送信側ＵＥのＶ２Ｘ層は、送信がＰＣ５－Ｓシグナリングメッセージ（つまり、直接通信要求／受け入れ、リンク識別子更新要求／応答、切断要求／応答、リンク変更要求／受け入れ）、又はＶ２ＸサービスデータのためのものであるかをＡＳ層に示す。
全てのＰＣ５ユニキャストリンクについて、ＵＥは、ＰＣ５ユニキャストリンクの存続期間中に、ＵＥにおけるＰＣ５ユニキャストリンクを一意に識別する別個のＰＣ５リンク識別子を自己割り当てする。各ＰＣ５ユニキャストリンクは、以下を含むユニキャスト・リンク・プロファイルに関連付けられる：
－サービスタイプ（例えば、ＰＳＩＤ又はＩＴＳ－ＡＩＤ）、ＵＥＡのアプリケーション層ＩＤ及びレイヤ２ＩＤ；
－ＵＥＢのアプリケーション層ＩＤ及びレイヤ２ＩＤ；
－ＰＣ５ユニキャストリンクで使用されるネットワーク層プロトコル；及び
－各Ｖ２Ｘサービスについて、ＰＣ５ＱｏＳフロー識別子（PFI）のセット。
各ＰＦＩは、ＱｏＳパラメータ（つまり、ＰＱＩ及びオプションで範囲）に関連付けられる。
プライバシー上の理由から、アプリケーション層ＩＤ及びレイヤ２ＩＤは、ＰＣ５ユニキャストリンクの存続期間中に、５．６．１．１項及び６．３．３．２項で説明されるように変更される場合があり、その場合に、それに応じてユニキャスト・リンク・プロファイルで更新されるものとする。ＵＥは、ＰＣ５リンク識別子を使用してＰＣ５ユニキャストリンクをＶ２Ｘアプリケーション層に示す。従って、Ｖ２Ｘアプリケーション層は、１つのサービスタイプに関連付けられたユニキャストリンクが複数ある場合でも、対応するＰＣ５ユニキャストリンクを識別する（例えば、ＵＥが同じサービスタイプについて複数のＵＥとマルチユニキャストリンクを確立する）。
ユニキャスト・リンク・プロファイルは、６．３．３．４項で指定されるように、確立したＰＣ５ユニキャストリンクのレイヤ２リンク変更後にそれに応じて更新されるものとする。
［・・・］

５．６識別子
５．６．１ＰＣ５参照点を介したＶ２Ｘ通信の識別子
５．６．１．１概略
各ＵＥには、ＰＣ５参照点を介したＶ２Ｘ通信のための１つ又は複数のレイヤ２ＩＤがあり、
－送信元（ソース：source）レイヤ２ＩＤ、及び
－宛先（destination）レイヤ２ＩＤ、で構成される。
送信元及び宛先レイヤ２ＩＤは、ＰＣ５参照点のレイヤ２リンクで送信されるレイヤ２フレームに含まれ、これらのフレームのレイヤ２送信元及び宛先を識別する。送信元レイヤ２ＩＤは、対応するレイヤ２フレームを発信するＵＥによって常に自己割り当てされる。ＵＥによる送信元及び宛先レイヤ２ＩＤの選択は、５．６．１．２、５．６．１．３、及び５．６．１．４項で説明されるように、このレイヤ２リンクのＰＣ５参照点を介したＶ２Ｘ通信の通信モードに依存する。送信元レイヤ２ＩＤは、通信モードによって異なる場合がある。
ＩＰベースのＶ２Ｘ通信がサポートされている場合に、ＵＥは、ＴＳ２３．３０３［１７］の４．５．３項で規定されるように、リンクローカルＩＰｖ６アドレスを送信元ＩＰアドレスとして使用するように構成する。ＵＥは、重複アドレス検出のためのNeighbor Solicitation及びNeighbor
Advertisementメッセージを送信することなく、ＰＣ５参照点を介したＶ２Ｘ通信のためにこのＩＰアドレスを使用することができる。アプリケーションが必要とする特定の短い期間を超えて送信元ＵＥ（例えば、車両）を他のＵＥ（例えば、車両）が追跡又は識別できないようにするために、５．１．２．１項で説明される構成で特定されるように、ＵＥに現在の地理的領域でプライバシーサポートを必要とするアクティブなＶ２Ｘアプリケーションがある場合に、送信元レイヤ２ＩＤは、時間の経過とともに変更され、ランダム化されるものとする。ＰＣ５参照点を介したＩＰベースのＶ２Ｘ通信の場合に、送信元ＩＰアドレスも時間の経過とともに変更され、ランダム化されるものとする。送信元ＵＥの識別子の変更は、ＰＣ５に使用される層間で同期する必要があり、例えば、アプリケーション層ＩＤが変更された場合に、送信元レイヤ２ＩＤ及び送信元ＩＰアドレスを変更する必要がある。

５．６．１．４ＰＣ５参照点を介したユニキャストモードＶ２Ｘ通信の識別子
ＰＣ５参照点を介したＶ２Ｘ通信のユニキャストモードの場合に、使用される宛先レイヤ２ＩＤは、ＰＣ５ユニキャストリンクの確立中に検出された通信ピアによって異なる。ＰＣ５ユニキャストリンクを確立するための開始シグナリングでは、５．１．２．１項で指定されるように、ＰＣ５ユニキャストリンク確立のために構成されたサービスタイプに関連付けられたデフォルトの宛先レイヤ２ＩＤ（例えば、ＰＳＩＤ／ＩＴＳ－ＡＩＤ等）を使用できる。ＰＣ５ユニキャストリンク確立手順中に、レイヤ２ＩＤは、交換され、６．３．３．１項で指定されるように、２つのＵＥの間の将来の通信に使用する必要がある。
アプリケーション層ＩＤは、ＵＥ内の１つ又は複数のＶ２Ｘアプリケーションに関連付けられる。ＵＥが複数のアプリケーション層ＩＤを有している場合に、同じＵＥの各アプリケーション層ＩＤは、ピアＵＥの観点からは異なるＵＥのアプリケーション層ＩＤと見なされる場合がある。
Ｖ２Ｘアプリケーション層がレイヤ２ＩＤを使用しないため、ＵＥは、アプリケーション層ＩＤとＰＣ５ユニキャストリンクに使用される送信元レイヤ２ＩＤとの間のマッピングを維持する。これにより、Ｖ２Ｘアプリケーションを中断することなく送信元レイヤ２ＩＤを変更できる。
アプリケーション層ＩＤが変更された場合に、変更されたアプリケーション層ＩＤとのＶ２Ｘ通信にリンクが使用されていれば、ＰＣ５ユニキャストリンクの送信元レイヤ２ＩＤが変更されるものとする。ＵＥは、ピアＵＥとの複数のＰＣ５ユニキャストリンクを確立し、これらのＰＣ５ユニキャストリンクに対して同じ又は異なる送信元レイヤ２ＩＤを使用することができる。
編集者注：ＲＡＮＷＧフィードバックに基づいて、識別子の説明をさらに更新する必要があり得る。
［・・・］

６．３．３ＰＣ５参照点を介したユニキャストモードＶ２Ｘ通信
６．３．３．１ＰＣ５参照点を介したレイヤ２リンクの確立
ＰＣ５参照点を介してＶ２Ｘ通信のユニキャストモードを実行するために、ＵＥは、５．１．２．１項で説明されるように関連情報で構成される。
図６．３．３．１－１に、ＰＣ５参照点を介したＶ２Ｘ通信のユニキャストモードのレイヤ２リンク確立手順を示す。
［“Layer-2 Link establishment procedure”という表題の３ＧＰＰＴＳ２３．２８７Ｖ１６．０．０の図６．３．３．１－１を、図６として再現する］
１. ＵＥは、５．６．１．４項で指定されるように、ＰＣ５ユニキャストリンク確立のシグナリング受信のための宛先レイヤ２ＩＤを決定する。宛先レイヤ２ＩＤは、５．１．２．１項で指定されるようにＵＥで構成される。
２. ＵＥ－１のＶ２Ｘアプリケーション層は、ＰＣ５ユニキャスト通信にアプリケーション情報を提供する。アプリケーション情報には、Ｖ２Ｘアプリケーションのサービスタイプ（例えば、ＰＳＩＤ又はＩＴＳ－ＡＩＤ）と開始ＵＥのアプリケーション層ＩＤとが含まれる。ターゲットＵＥのアプリケーション層ＩＤは、アプリケーション情報に含まれ得る。
ＵＥ－１のＶ２Ｘアプリケーション層は、このユニキャスト通信のＶ２Ｘアプリケーション要件を提供し得る。ＵＥ－１は、５．４．１．４項で指定されるように、ＰＣ５ＱｏＳパラメータ及びＰＦＩを決定する。
ＵＥ－１が５．２．１．４項で指定されるように既存のＰＣ５ユニキャストリンクを再利用することを決定した場合に、ＵＥは、６．３．３．４項で指定されるようにレイヤ２リンク変更手順をトリガーする。
３. ＵＥ１は、直接通信要求メッセージを送信して、ユニキャストレイヤ２リンク確立手順を開始する。直接通信要求メッセージには、次のものが含まれる：
－送信元ユーザ情報：開始ＵＥのアプリケーション層ＩＤ（つまり、ＵＥ－１のアプリケーション層ＩＤ）；
－Ｖ２Ｘアプリケーション層がステップ２でターゲットＵＥのアプリケーション層ＩＤを提供した場合に、次の情報が含まれる：
－ターゲットユーザ情報：ターゲットＵＥのアプリケーション層ＩＤ（つまり、ＵＥ－２のアプリケーション層ＩＤ）；
－Ｖ２Ｘサービス情報：レイヤ２リンクの確立を要求するＶ２Ｘサービスに関する情報（例えば、ＰＳＩＤ又はＩＴＳ－ＡＩＤ）；
－ＩＰ通信が使用されているかどうかの指標；
－ＩＰアドレス構成：ＩＰ通信の場合に、このリンクにはＩＰアドレス構成が必要であり、次のいずれかの値を示す：
－ＩＰｖ６アドレス割当てメカニズムが開始ＵＥによってサポートされている場合、つまりＩＰｖ６ルーターとして機能している場合に、「ＩＰｖ６ルーター」；又は
－ＩＰｖ６アドレス割当てメカニズムが開始ＵＥによってサポートされていない場合に、「ＩＰｖ６アドレス割当てがサポートされていない」；
－リンクローカルＩＰｖ６アドレス：ＵＥ－１がＩＰｖ６ＩＰアドレス割当てメカニズムをサポートしていない場合、つまりＩＰアドレス構成が「ＩＰｖ６アドレス割当てがサポートされていない」と示す場合に、ＲＦＣ４８６２［２１］に基づいてローカルに形成されたリンクローカルＩＰｖ６アドレス；
－ＱｏＳ情報：ＰＣ５ＱｏＳフローに関する情報。各ＰＣ５ＱｏＳフローについて、ＰＦＩ及び対応するＰＣ５ＱｏＳパラメータ（つまり、ＰＱＩ及び条件付きでＭＦＲＢ／ＧＦＢＲ等の他のパラメータ）。
直接通信要求メッセージの送信に使用される送信元レイヤ２ＩＤ及び宛先レイヤ２ＩＤは、５．６．１．１項及び５．６．１．４項で指定されるように決定される。
ＵＥ－１は、送信元レイヤ２ＩＤ及び宛先レイヤ２ＩＤを使用して、ＰＣ５ブロードキャストを介して直接通信要求メッセージを送信する。
４．直接通信受入れ（direct communication accept）メッセージが次のようにＵＥ－１に送信される：
４ａ（ＵＥ指向（oriented）のレイヤ２リンク確立）ターゲットユーザ情報が直接通信要求メッセージに含まれている場合に、ターゲットＵＥ、つまりＵＥ－２は、直接通信受入れメッセージで応答する。
４ｂ（Ｖ２Ｘサービス指向のレイヤ２リンク確立）ターゲットユーザ情報が直接通信要求メッセージに含まれていない場合に、アナウンスされたＶ２Ｘサービスの使用に関心のあるＵＥは、ＵＥ－１とのレイヤ２リンクを確立することを決定し、直接通信受入れメッセージを送信して要求に応答する（図６．３．３．１－１のＵＥ－２及びＵＥ－４）。
直接通信受入れメッセージには次のものが含まれる：
－送信元ユーザ情報：直接通信受入れメッセージを送信するＵＥのアプリケーション層ＩＤ；
－ＱｏＳ情報：ＰＣ５ＱｏＳフローに関する情報。各ＰＣ５ＱｏＳフローについて、ＵＥ－１によって要求されたＰＦＩ及び対応するＰＣ５ＱｏＳパラメータ（つまり、ＰＱＩ及び条件付きでＭＦＲＢ／ＧＦＢＲ等の他のパラメータ）；
－ＩＰアドレス構成：ＩＰ通信の場合に、このリンクにはＩＰアドレス構成が必要であり、次のいずれかの値を示す：
－ＩＰｖ６アドレス割当てメカニズムがターゲットＵＥによってサポートされている場合、つまりＩＰｖ６ルーターとして機能している場合に、「ＩＰｖ６ルーター」；又は
－ＩＰｖ６アドレス割当てメカニズムがターゲットＵＥによってサポートされていない場合に、「ＩＰｖ６アドレス割当てがサポートされていない」；
－リンクローカルＩＰｖ６アドレス：ターゲットＵＥがＩＰｖ６ＩＰアドレス割当てメカニズムをサポートしていない場合、つまりＩＰアドレス構成が「ＩＰｖ６アドレス割当てがサポートされていない」と示す場合に、ＲＦＣ４８６２［２１］に基づいてローカルに形成されたリンクローカルＩＰｖ６アドレス、及び直接通信要求メッセージにリンクローカルＩＰｖ６アドレスを含めたＵＥ１。ターゲットＵＥには、競合しないリンクローカルＩＰｖ６アドレスを含める必要がある。
リンクローカルＩＰｖ６アドレスを使用するために両方のＵＥ（つまり、開始ＵＥ及びターゲットＵＥ）が選択された場合に、ＲＦＣ４８６２［２１］で規定される重複アドレス検出を無効にする必要がある。
注１：開始ＵＥ又はターゲットＵＥのいずれかがＩＰｖ６ルーターのサポートを示している場合に、対応するアドレス構成手順は、レイヤ２リンクの確立後に実行され、リンクローカルＩＰｖ６アドレスは無視される。
直接通信受入れメッセージの送信に使用される送信元レイヤ２ＩＤは、５．６．１．１項及び５．６．１．４項で指定されるように決定される。宛先レイヤ２ＩＤは、受信した直接通信要求メッセージの送信元レイヤ２ＩＤに設定される。
ピアＵＥから直接通信受入れメッセージを受信すると、ＵＥ－１は、このユニキャストリンクのシグナリング及びデータトラフィックに関して、将来の通信のためにピアＵＥのレイヤ２ＩＤを取得する。
ＰＣ５ユニキャストリンクを確立したＵＥのＶ２Ｘ層は、ユニキャストリンクに割り当てられたＰＣ５リンク識別子及びＰＣ５ユニキャストリンク関連情報をＡＳ層に渡す。ＰＣ５ユニキャストリンク関連情報には、レイヤ２ＩＤ情報（つまり、送信元レイヤ２ＩＤ及び宛先レイヤ２ＩＤ）が含まれる。これにより、ＡＳ層がＰＣ５ユニキャストリンク関連情報と共にＰＣ５リンク識別子を維持できる。
編集者注：相互認証及びセキュリティ関連の確立の手順は、ＳＡＷＧ３からのフィードバックに基づいて決定される。
５．Ｖ２Ｘサービスデータは、以下のように確立したユニキャストリンクを介して送信される。
ＰＣ５リンク識別子及びＰＦＩは、Ｖ２Ｘサービスデータと共にＡＳ層に提供される。
ＵＥ－１は、送信元レイヤ２ＩＤ（つまり、このユニキャストリンクのＵＥ－１のレイヤ２ＩＤ）、及び宛先レイヤ２ＩＤ（つまり、このユニキャストリンクのピアＵＥのレイヤ２ＩＤ）を使用してＶ２Ｘサービスデータを送信する。
注２：ＰＣ５ユニキャストリンクは双方向であるため、ＵＥ－１のピアＵＥは、ＵＥ－１とのユニキャストリンクを介してＶ２ＸサービスデータをＵＥ１に送信できる。
編集者注：直接通信要求／受入れメッセージに含まれるパラメータは、直接通信要求／受入れメッセージがＡＳ層によってどの様に（例えば、ＰＣ５ＲＲＣシグナリングを使用して）送信されるかに関するＲＡＮＷＧの決定に応じて更新できる。
編集者注：直接通信要求／受入れメッセージに含まれる追加のパラメータ（セキュリティ関連等）はＦＦＳである。
編集者注：ユニキャスト通信にリンク層でのセキュリティ保護が必要かどうかは、ＳＡＷＧ３からのフィードバックに基づいて決定される。

３ＧＰＰＴＳ３８．８８５は、ＮＲ（New RAT/Radio）Ｖ２Ｘユニキャストモード通信のためのＱｏＳ（サービス品質）管理を以下のように指定する：
７ＱｏＳ管理
ＱｏＳ管理は、リソース割当て、輻輳制御、装置内共存、電力制御、及びＳＬＲＢ構成での使用のコンテキストでＶ２Ｘに関連している。ＱｏＳ管理に関連する物理層パラメータは、配信されるトラフィックの優先度、遅延、信頼性、及び必要最小限の通信範囲（上位層で規定される）である。ＡＳではデータレート要件もサポートされる。ＳＬ輻輳メトリックと、少なくともリソース割当てモード２では、輻輳制御のメカニズムとが必要である。ＳＬ輻輳メトリックをｇＮＢに報告することは有益である。
ＳＬユニキャスト、グループキャスト、及びブロードキャストの場合に、Ｖ２ＸパケットのＱｏＳパラメータは上位層によってＡＳに提供される。ＳＬユニキャストの場合に、ＳＬＲＢは、図７－１及び７－２に示されるシグナリングフロー及び手順に基づいて（事前に）構成される。［６］で説明されるフロー毎のＱｏＳモデルは、上位層で想定される。
［“SLRB-Configuration for unicast (UE-specific)”という表題の３ＧＰＰＴＳ３８．８８５Ｖ１６．０．０の図７－１を、図７として再現する。］
図７－１のステップ０では、ＰＣ５ＱｏＳプロファイル、つまり特定のＰＣ５ＱｏＳパラメータのセット、及び各ＰＣ５ＱｏＳフローのＰＣ５ＱｏＳルールが、［６］のようにサービス認証及びプロビジョニング手順によって事前にＵＥにプロビジョニングされる；同様に、各ＱｏＳフローのＰＣ５ＱｏＳプロファイルも、事前にｇＮＢ／ｎｇ－ｅＮＢにプロビジョニングされる。次に、パケットが到着すると、ＵＥは、最初にステップ０で構成されたＰＣ５ＱｏＳルールに基づいて関連するＰＣ５ＱｏＳフローの識別子（つまり、ＰＣ５ＱＦＩ）を導出し、次に導出したＰＣ５ＱＦＩをステップ３でｇＮＢ／ｎｇ－ｅＮＢに報告することができる。ｇＮＢ／ｎｇ－ｅＮＢは、ステップ０での５ＧＣからのプロビジョニングに基づいて、これらの報告されたＰＣ５ＱＦＩのＱｏＳプロファイルを導出でき、ステップ４でＲＲＣ専用シグナリングを介して報告されたＰＣ５ＱＦＩＵＥに関連付けられたＳＬＲＢの構成を通知できる。これらのＳＬＲＢ構成には、ＰＣ５ＱｏＳフローからＳＬＲＢへのマッピング、ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＬＣＨ構成等が含まれ得る。ステップ５では、ＡＳにおけるＵＥは、ｇＮＢ／ｎｇ－ｅＮＢ構成に従って、パケットのＰＣ５ＱＦＩに関連付けられたＳＬＲＢをピアＵＥと確立し、利用可能なパケットを確立したＳＬＲＢにマッピングする。次に、ＳＬユニキャスト送信が発生し得る。
注：ＰＣ５ＱＦＩがどの様に規定されるかは、ＳＡ２ＷＧ２までである。
［・・・］

３ＧＰＰＲ２－１９０８１０７は、ＮＲＳＬＱｏＳ及びＳＬＲＢ構成に関するＲＡＮ２＃１０６合意を次のように得る。

３ＧＰＰＲ２－１９１６２８８は、ＲＬＣ及びＬＣＩＤの不一致に関するＲＡＮ２＃１０８合意を次のように得る。

２０１９年１２月２６日に配布されたＮＲサイドリンク合意を使用して新しい５ＧＶ２Ｘを得るためのＴＳ３８．３３１への更新された実行ＣＲ（３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei））は、ＮＲＶ２Ｘのサイドリンク関連の手順及びメッセージを次のように指定する。
５．３．５ＲＲＣ再構成
［・・・］
５．３．５．３ＵＥによるＲＲＣ再構成の受信
ＵＥは、ＲＲＣ再構成（RRCReconfiguration）を受信すると、次のアクションを実行するものとする。
［・・・］
１＞ RRCReconfiguration（ＲＲＣ再構成）メッセージにsl-ConfigDedicatedNRが含まれる場合に：
２＞５．３．５．Ｘで指定されるサイドリンク専用の構成手順を実行する。
［・・・］
－ＲＲＣ再構成
RRCReconfigurationメッセージは、ＲＲＣ接続を変更するためのコマンドである。そのメッセージは、測定構成、モビリティ制御、無線リソース構成（ＲＢ、ＭＡＣメイン構成、物理チャネル構成を含む）、及びＡＳセキュリティ構成に関する情報を伝達し得る。
シグナリング無線ベアラ：ＳＲＢ１又はＳＲＢ３
ＲＬＣ－ＳＡＰ：ＡＭ
論理チャネル：ＤＣＣＨ
方向：ネットワークからＵＥ
ＲＲＣ再構成メッセージ

－ SL-ConfigDedicatedNR
IE SL-ConfigDedicatedNRは、ＮＲサイドリンク通信の専用構成情報を指定する。
SL-ConfigDedicatedNR情報要素

［・・・］
－ SL-RadioBearerConfig
IE SL-RadioBearerConfigは、ＮＲサイドリンク通信のサイドリンクＤＲＢ構成情報を指定する。
SL-RadioBearerConfig情報要素

［・・・］
－ SL-SDAP-Config
IE SL-SDAP-Configは、サイドリンクＤＲＢの構成可能なＳＤＡＰパラメータを設定するために使用される。
SL-SDAP-CONFIG情報要素

［・・・］
５．Ｘ．３ＮＲサイドリンク通信のためのサイドリンクＵＥ情報
５．Ｘ．３．１概略
［“Sidelink UE information for NR sidelink communication”という表題の３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）の図５．Ｘ．３．１－１を、図８として再現する。］
この手順の目的は、ＵＥがＮＲサイドリンク通信の受信に関心がある、又はもはや関心がなくなったことをネットワークに通知し、ＮＲサイドリンク通信の送信リソースの割当て又は解放を要求し、ＮＲサイドリンク通信に関連するパラメータを報告することである。
５．Ｘ．３．２開始
RRC_CONNECTEDにあるＮＲサイドリンク通信が可能なＵＥは、接続の確立が成功したとき、又は再開したとき、関心対象の変更時、sl-ConfigCommonNRを含むＳＩＢＸを提供するＰＣｅｌｌへの変更時等、いくつかの場合にＮＲサイドリンク通信を受信する（に関心がある）ことを示す手順を開始できる。ＮＲサイドリンク通信が可能なＵＥは、ＮＲサイドリンク通信送信のための専用リソースの割当てを要求する手順を開始することができる。
この手順を開始すると、ＵＥは次のことを行うものとする：
１＞ sl-ConfigCommonNRを含むＳＩＢＸがＰＣｅｌｌによって提供される場合に：
２＞ＰＣｅｌｌのための有効なバージョンのＳＩＢＸがあることを確認する；
２＞ＰＣｅｌｌのＳＩＢＸでのsl-FreqInfoListに含まれる周波数でＮＲサイドリンク通信を受信するように上位層によって構成される場合に：
３＞最後にRRC_CONNECTED状態に入ってからＵＥがSidelinkUEInformationNR（サイドリンクＵＥ情報ＮＲ）メッセージを送信しなかった場合に、又は
３＞最後にＵＥがSidelinkUEInformationNRメッセージを送信してから、ＰＣｅｌｌに接続されたＵＥがsl-ConfigCommonNRを含むＳＩＢＸを提供していない場合に、又は
３＞ SidelinkUEInformationNRメッセージの最後の送信にsl-RxInterestedFreqListが含まれていなかった場合に、又は、ＮＲサイドリンク通信を受信するように上位層によって構成された周波数が、SidelinkUEInformationNRメッセージの最後の送信以降に変更された場合に：
４＞ SidelinkUEInformationNRメッセージの送信を開始して、５．Ｘ．３．３に従って関心対象のＮＲサイドリンク通信の受信周波数を示す；
２＞それ以外の場合に：
３＞ SidelinkUEInformationNRメッセージの最後の送信にsl-RxInterestedFreqListが含まれている場合に：
４＞ SidelinkUEInformationNRメッセージの送信を開始して、５．Ｘ．３．３に従ってＮＲサイドリンク通信の受信にもはや関心がなくなったことを示す；
２＞ＰＣｅｌｌのＳＩＢＸでのsl-FreqInfoListに含まれる周波数でＮＲサイドリンク通信を送信するように上位層によって構成される場合に：
３＞最後にRRC_CONNECTED状態に入ってからＵＥがSidelinkUEInformationNRメッセージを送信しなかった場合に；又は
３＞最後にＵＥがSidelinkUEInformationNRメッセージを送信してから、ＰＣｅｌｌに接続されたＵＥがsl-ConfigCommonNRを含むＳＩＢＸを提供していない場合に；又は
３＞ SidelinkUEInformationNRメッセージの最後の送信にsl-TxResourceReqListが含まれていなかった場合に、又は、sl-TxResourceReqListによって伝達される情報が、SidelinkUEInformationNRメッセージの最後の送信以降に変更された場合に：
４＞ SidelinkUEInformationNRメッセージの送信を開始して、５．Ｘ．３．３に従ってＵＥが要求するＮＲサイドリンク通信送信リソースを示す；
２＞それ以外の場合に：
３＞ SidelinkUEInformationNRメッセージの最後の送信にsl-TxResourceReqListが含まれている場合に：
４＞ SidelinkUEInformationNRメッセージの送信を開始して、５．Ｘ．３．３に従ってＮＲサイドリンク通信送信リソースがもはや不要になったことを示す。

５．Ｘ．３．３ SidelinkUEInformationNRメッセージの送信に関連するアクション
ＵＥは、SidelinkUEInformationNRメッセージのコンテンツを次のように設定することになる：
１＞ＵＥが手順を開始して、ＮＲサイドリンク通信の受信又はＮＲサイドリンク通信送信リソースの要求（構成／解放）に関心がある（もはや関心がない）ことを示すための手順を開始する場合（つまり、手順をトリガーしたものに関係なく、ＵＥには全ての関連情報が含まれる）：
２＞ sl-ConfigCommonNRを含むＳＩＢＸがＰＣｅｌｌによって提供される場合に：
３＞ＮＲサイドリンク通信を受信するように上位層によって構成されている場合に：
４＞ sl-RxInterestedFreqListを含め、そのリストをＮＲサイドリンク通信受信の周波数に設定する；
３＞ＮＲサイドリンク通信を送信するように上位層によって構成されている場合に：
４＞ sl-TxResourceReqListを含め、ネットワークにＮＲサイドリンク通信リソースの割当てを要求する宛先毎にそのフィールドを次のように設定する：
５＞ sl-DestinationIdentiyを、ＮＲサイドリンク通信送信のために上位層によって構成された宛先ＩＤに設定する；
５＞ sl-CastTypeを、ＮＲサイドリンク通信送信のために上位層によって構成された関連する宛先ＩＤのキャストタイプに設定する；
５＞関連する双方向サイドリンクＤＲＢの追加がRRCReconfigurationSidelink（ＲＲＣ再構成サイドリンク）による構成によるものである場合に、ＲＬＣモードと、関連するＲＬＣモードのサイドリンクＱｏＳフローのオプションでＱｏＳプロファイルとを含むようにsl-RLC-ModeIndicationを設定する；
５＞サイドリンクＲＬＦが検出された場合に、ＮＲサイドリンク通信送信の関連する宛先にsl-Failureを設定する；
５＞ＮＲサイドリンク通信送信のために上位層によって構成された関連する宛先のサイドリンクＱｏＳフローのＱｏＳプロファイルを含むように、sl-QoS-InfoListを設定する；
５＞ＮＲサイドリンク通信送信の周波数を示すように、sl-InterestedFreqListを設定する；
５＞ sl-TypeTxSyncListを、ＮＲサイドリンク通信送信のための関連するsl-InterestedFreqListで使用されている現在の同期参照タイプに設定する：
１＞ＵＥは、送信のためにSidelinkUEInformationNRメッセージを下位層に送信する必要がある。
［・・・］
－ SidelinkUEInformationNR
SidelinkUEinformationNRメッセージは、ネットワークへのＮＲサイドリンクＵＥ情報の指標に使用される。
シグナリング無線ベアラ：ＳＲＢ１
ＲＬＣ－ＳＡＰ：ＡＭ
論理チャネル：ＤＣＣＨ
方向：ＵＥからネットワーク
SidelinkUEInformationNRメッセージ

［・・・］

［・・・］
５．Ｘ．９サイドリンクＲＲＣ手順
５．Ｘ．９．１サイドリンクＲＲＣ再構成
５．Ｘ．９．１．１概略
［“Sidelink RRC configuration, successful”という表題の３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）の図５．Ｘ．９．１．１－１を、図９として再現する。］
［“Sidelink RRC configuration, failure”という表題の３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）の図５．Ｘ．９．１．１－２を、図１０として再現する。］
この手順の目的は、サイドリンクＤＲＢを確立／変更／解放するか、ＰＣ５ＲＲＣ接続のＮＲサイドリンク測定及びレポートを構成することである。
ＵＥは、次の場合に、サイドリンクＲＲＣ再構成手順を開始し、５．Ｘ．９．１．２サブ項の操作をピアＵＥに対して実行できる：
－５．Ｘ．９．１．４サブ項で指定されるように、ピアＵＥに関連付けられたサイドリンクＤＲＢのリリース；
－５．Ｘ．９．１．５サブ項で指定されるように、ピアＵＥに関連付けられたサイドリンクＤＲＢの確立；
－５．Ｘ．９．１．５サブ項で指定されるように、ピアＵＥに関連付けられたサイドリンクＤＲＢのSLRB-Configに含まれるパラメータの変更；
－ＮＲサイドリンクの測定及びレポートを実行するためのピアＵＥの構成。

５．Ｘ．９．１．２ RRCReconfigurationSidelinkメッセージの送信に関連するアクション
ＵＥは、RRCReconfigurationSidelinkメッセージのコンテンツを次のように設定するものとする：
１＞ sl-ConfigDedicatedNR、SIBX、SidelinkPreconfigNR、又は上位層による構成によって、５．Ｘ．９．１．４．１サブ項に従って、解放されるサイドリンクＤＲＢ毎に：
２＞サイドリンクＤＲＢに対応するsrlb-ConfigToReleaseListに含まれるslrb-PC5-ConfigIndexを設定する；
１＞ sl-ConfigDedicatedNR、SIBX、SidelinkPreconfigNRの受信によって、５．Ｘ．９．１．５．１サブ項に従って、確立又は変更されるサイドリンクＤＲＢ毎に：
２＞サイドリンクＤＲＢに対応する受信したsl-RadioBearerConfig及びsl-RLC-BearerConfigに従って、SLRB-ConfigToAddModListに含まれるSLRB-Configを設定する；
１＞構成されるＮＲサイドリンク測定及びレポート毎に：
２＞格納されるＮＲサイドリンク測定構成情報に従ってsl-MeasConfigを設定する；
１＞サイドリンクＤＲＢに関連付けられた宛先のタイマーＴ４００を開始する。
ＵＥは、送信のためにRRCReconfigurationSidelinkメッセージを下位層に送信する必要がある。

５．Ｘ．９．１．３ＵＥによるRRCReconfigurationSidelinkの受信
ＵＥは、RRCReconfigurationSidelinkを受信すると、次のアクションを実行することになる：
１＞ RRCReconfigurationSidelinkにslrb-ConfigToReleaseListが含まれている場合に：
２＞現在のＵＥサイドリンク構成の一部であるsrlb-ConfigToReleaseListに含まれる各slrb-PC5-ConfigIndex値に対して；
３＞５．Ｘ．９．１．４サブ項に従って、サイドリンクＤＲＢ解放手順を実行する；
１＞ RRCReconfigurationSidelinkにslrb-ConfigToAddModListが含まれている場合に：
２＞現在のＵＥサイドリンク構成の一部ではないslrb-ConfigToAddModListに含まれる各slrb-PC5-ConfigIndex値に対して：
３＞含まれる場合には、sl-MappedQoS-FlowsToAddList及びsl-MappedQoS-FlowsToReleaseListを適用する；
３＞５．Ｘ．９．１．５サブ項に従って、サイドリンクＤＲＢ追加手順を実行する；
２＞現在のＵＥサイドリンク構成の一部であるslrb-ConfigToAddModListに含まれる各slrb-PC5-ConfigIndex値に対して：
３＞含まれる場合には、sl-MappedQoS-FlowsToAddList及びsl-MappedQoS-FlowsToReleaseListを適用する；
３＞５．Ｘ．９．１．４及び５．Ｘ．９．１．５サブ項に従って、サイドリンクＤＲＢの解放又は変更手順を実行する。
１＞ＵＥがRRCReconfigurationFailureSidelinkに含まれる構成（の一部）に準拠できない（つまり、サイドリンクＲＲＣ再構成の失敗）場合に：
２＞ RRCReconfigurationFailureSidelinkメッセージを受信する前に使用した構成を引き続き使用する；
２＞ RRCReconfigurationFailureSidelinkメッセージのコンテンツを設定する；
３＞送信のためにRRCReconfigurationFailureSidelinkメッセージを下位層に送信する；
１＞それ以外の場合に：
２＞ RRCReconfigurationCompleteSidelinkメッセージのコンテンツを設定する；
３＞送信のためにRRCReconfigurationCompleteSidelinkメッセージを下位層に送信する。
注Ｘ：同じ論理チャネルが別のＵＥによって異なるＲＬＣモードで構成されている場合に、ＵＥは、そのケースをサイドリンクＲＲＣ再設定の失敗として処理する。
［・・・］
－ RRCReconfigurationSidelink
RRCReconfigurationSidelinkメッセージは、ＰＣ５ＲＲＣ接続のＡＳ構成へのコマンドである。そのメッセージは、ＮＲサイドリンク通信のユニキャストにのみ適用される。
シグナリング無線ベアラ：ＰＣ５ＲＲＣのサイドリンクＳＲＢ
ＲＬＣ－ＳＡＰ：ＡＭ
論理チャネル：ＳＣＣＨ
方向：ＵＥからＵＥ

［・・・］

－ RRCReconfigurationCompleteSidelink
RRCReconfigurationCompleteSidelinkメッセージは、ＰＣ５ＲＲＣＡＳ再構成が成功裏に完了したことを確認するために使用される。そのメッセージは、ＮＲサイドリンク通信のユニキャストにのみ適用される。
シグナリング無線ベアラ：ＰＣ５－ＲＲＣのサイドリンクＳＲＢ
ＲＬＣ－ＳＡＰ：ＡＭ
論理チャネル：ＳＣＣＨ
方向：ＵＥからＵＥ
RRCReconfigurationCompleteSidelinkメッセージ

３ＧＰＰＴＳ３８．３２２は、以下のようにＲＬＣステータスレポートを導入した。
５．２．３ＡＭデータ転送
５．２．３．１送信操作
５．２．３．１．１概略
ＡＭＲＬＣエンティティの送信側は、ＡＭＤＰＤＵよりもＲＬＣ制御ＰＤＵの送信を優先する必要がある。ＡＭＲＬＣエンティティの送信側は、以前に送信したＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメントを含まないＡＭＤＰＤＵの送信よりも、以前に送信したＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメントを含むＡＭＤＰＤＵの送信を優先する必要がある。
ＡＭＲＬＣエンティティの送信側は、次のように状態変数TX_Next_Ackに従って送信ウィンドウを維持する必要がある。
－ TX_Next_Ack <= SN <TX_Next_Ack + AM_Window_Sizeの場合に、ＳＮは送信ウィンドウ内にある；
－それ以外の場合に、ＳＮは送信ウィンドウの外にある。
ＡＭＲＬＣエンティティの送信側は、ＳＮが送信ウィンドウの外にあるＡＭＤＰＤＵを下位層に送信してはならない。
上位層から受信した各ＲＬＣＳＤＵに対して、ＡＭＲＬＣエンティティは、
－ＳＮをTX_Nextに等しいＲＬＣＳＤＵに関連付け、ＡＭＤＰＤＵのＳＮをTX_Nextに設定することによりＡＭＤＰＤＵを作成すること；
－ TX_Nextを１だけインクリメントすること；を行う必要がある。
ＲＬＣＳＤＵのセグメントを含むＡＭＤＰＤＵを下位層に送信する場合に、ＡＭＲＬＣエンティティの送信側は、
－ＡＭＤＰＤＵのＳＮを対応するＲＬＣＳＤＵのＳＮに設定すること；を行う必要がある。
ＡＭＲＬＣエンティティの送信側は、
－ピアＡＭＲＬＣエンティティからのＳＴＡＴＵＳＰＤＵ（ステータスＰＤＵ）によって、ＲＬＣＳＤＵの肯定応答（ピアＡＭＲＬＣエンティティによる受信成功の確認）を受信できる。
ＳＮ＝ｘのＲＬＣＳＤＵの肯定応答を受信する場合に、ＡＭＲＬＣエンティティの送信側は、
－ＲＬＣＳＤＵの成功裏の配信の指標を上位層に送信すること；
－ TX_Next_Ackを、ＳＮが最小の状態のＲＬＣＳＤＵのＳＮと等しくなるように設定すること；を行う必要があり、このＳＮは、TX_Next_Ack <= SN <= TX_Nextの範囲内にあり、肯定応答を未だ受信していない。
［・・・］

５．３．２再送信
ＡＭＲＬＣエンティティの送信側は、
－ピアＡＭＲＬＣエンティティからのＳＴＡＴＵＳＰＤＵによって、ＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメントの否定応答（ピアＡＭＲＬＣエンティティによる受信失敗の通知）を受信できる。
ピアＡＭＲＬＣエンティティからのＳＴＡＴＵＳＰＤＵによってＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメントの否定応答を受信したする場合に、ＡＭＲＬＣエンティティの送信側は、
－対応するＲＬＣＳＤＵのＳＮが、TX_Next_Ack <= SN <TX_Nextの範囲内にある場合に：
－否定応答を受信したＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメントを再送信のために検討することを行う必要がある。
ＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメントの再送信が検討される場合に、ＡＭＲＬＣエンティティの送信側は、
－ＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメントが初めて再送信のために検討される場合に：
－ＲＬＣＳＤＵに関連付けられたRETX_COUNTをゼロに設定する；
－それ以外の場合に、それ（再送信が検討されているＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメント）が再送信を既に保留しておらず、同じＳＴＡＴＵＳＰＤＵ内の別の否定応答のために、ＲＬＣＳＤＵに関連付けられたRETX_COUNTがインクリメントされていない場合に：
－ RETX_COUNTをインクリメントする；
－ RETX_COUNT = maxRetxThresholdの場合に：
－最大再送信に達したことを上位層に示すことを行う必要がある。
ＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメントを再送信するときに、ＡＭＲＬＣエンティティの送信側は、
－必要に応じて、ＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメントをセグメント化する；
－特定の送信機会で下位層によって示されるＡＭＤＰＤＵの合計サイズ内に収まる新しいＡＭＤＰＤＵを形成する；
－新しいＡＭＤＰＤＵを下位層に送信することを行う必要がある。
新しいＡＭＤＰＤＵを形成するときに、ＡＭＲＬＣエンティティの送信側は、
－元のＲＬＣＳＤＵ又はＲＬＣＳＤＵセグメントのみを新しいＡＭＤＰＤＵのデータフィールドにマッピングする；
－６．２．２．４サブ項の説明に従って、新しいＡＭＤＰＤＵのヘッダーを変更する；
－５．３．３サブ項に従ってＰフィールドを設定することを行う必要がある。
［・・・］

５．３．４ステータスレポート
ＡＭＲＬＣエンティティは、ＲＬＣＳＤＵ（又はそれらの一部）の肯定応答及び／又は否定応答を提供するために、ＳＴＡＴＵＳＰＤＵをピアＡＭＲＬＣエンティティに送信する。
ステータスレポートを開始するトリガーは：
－ピアＡＭＲＬＣエンティティからのポーリングを含み：
－ＳＮ＝ｘでＰフィールドが「１」に設定されたＡＭＤＰＤＵを下位層から受信した場合に、ＡＭＲＬＣエンティティの受信側は、
－５．２．３．２．２項で指定されるようにＡＭＤＰＤＵを破棄すべき場合に；又は
－ x < RX_Highest_Status又はx >= RX_Next +
AM_Window_Sizeの場合に：
－ステータスレポートをトリガーすることを行う必要がある；
－それ以外の場合に：
－ x < RX_Highest_Status又はx >= RX_Next +
AM_Window_Sizeまでステータスレポートのトリガーを遅らせる；
注１：これにより、ＨＡＲＱの並べ替え後にＲＬＣステータスレポートが確実に送信される：
－ＡＭＤＰＤＵの受信失敗の検出を含み；
－ＡＭＲＬＣエンティティの受信側は、t-Reassemblyの期限が切れたときにステータスレポートをトリガーすることを行う必要がある；
注２：t-Reassemblyの期限満了は、RX_Highest_Statusの更新とステータスレポートのトリガーとの両方をトリガーするが、ステータスレポートは、RX_Highest_Statusの更新後にトリガーされる。
ステータスレポートがトリガーされたときに、ＡＭＲＬＣエンティティの受信側は：
－ t-StatusProhibitが：
－下位層によって示される最初の送信機会で実行されていない場合に、ＳＴＡＴＵＳＰＤＵを作成し、これを下位層に送信する；
－それ以外の場合に：
－ t-StatusProhibitの期限が切れた後に、下位層によって示される最初の送信機会で実行されていない場合に、t-StatusProhibitの実行中にステータスレポートが複数回トリガーされた場合にでも、単一のＳＴＡＴＵＳＰＤＵを作成し、これを下位層に送信することを行う必要がある。
ＳＴＡＴＵＳＰＤＵが下位層に送信されたときに、ＡＭＲＬＣエンティティの受信側は、
－ t-StatusProhibitを開始することを行う必要がある。
ＳＴＡＴＵＳＰＤＵを作成するときに、ＡＭＲＬＣエンティティは、
－ RX_Next <= SN <RX_Highest_Statusとなるように、未だ完全に受信していないＳＮを含むＲＬＣＳＤＵについて、ＲＬＣＳＤＵのＳＮ順位を増やし、ＲＬＣＳＤＵ内のバイトセグメント順位を増やし、SN = RX_Nextから開始して結果として得られるＳＴＡＴＵＳＰＤＵが、下位層で示されるＲＬＣＰＤＵの合計サイズに適合するまで行う：
－バイトセグメントを未だ受信していないＲＬＣＳＤＵについて：
－ＲＬＣＳＤＵのＳＮに設定されているNACK_SNをＳＴＡＴＵＳＰＤＵに含める；
－部分的に受信したが、未だ（全て）受信していないＲＬＣＳＤＵのバイトセグメントの連続シーケンスについて：
－ＳＴＡＴＵＳＰＤＵに、NACK_SN、SOstart、及びSOendのセットを含める；
－未だ受信していないＲＬＣＳＤＵの連続シーケンスについて：
－ＳＴＡＴＵＳＰＤＵに、NACK_SN及びNACK範囲のセットを含める；
－必要に応じて、ＳＴＡＴＵＳＰＤＵに、SOstart及びSOendのペアを含める；
－ ACK_SNを、結果として得られるＳＴＡＴＵＳＰＤＵで欠落していると示されていない次の受信していないＲＬＣＳＤＵのＳＮに設定することを行う必要がある。
［・・・］

６．１．３ＲＬＣ制御ＰＤＵ
ａ）ＳＴＡＴＵＳＰＤＵ
ＳＴＡＴＵＳＰＤＵは、ＡＭＲＬＣエンティティの受信側によって使用され、成功裏に受信したＲＬＣデータＰＤＵ、及びＡＭＲＬＣエンティティの受信側によって欠落していることが検出されたＲＬＣデータＰＤＵについてピアＡＭＲＬＣエンティティに通知する。

３ＧＰＰＴＳ３８．３２３は、以下のように、ＲｏＨＣフィードバックのためのＰＤＣＰ制御ＰＤＵを導入した。
５．７．６散在するＲＯＨＣフィードバックのためのＰＤＣＰ制御ＰＤＵ
５．７．６．１送信操作
散在するＲＯＨＣフィードバックがヘッダー圧縮プロトコルによって生成される場合に、送信側ＰＤＣＰエンティティは：
－６．２．３．２項で指定されるように、つまりＰＤＣＰＳＮを関連付けたり、暗号化を実行したりせずに、対応するＰＤＣＰ制御ＰＤＵを下位層に送信することを行う必要がある。
５．７．６．２受信操作
下位層からの散在するＲＯＨＣフィードバックのためのＰＤＣＰ制御ＰＤＵの受信時に、受信側ＰＤＣＰエンティティは：
－解読を実行せずに、対応する散在するＲＯＨＣフィードバックをヘッダー圧縮プロトコルに配信することを行う必要がある。
［・・・］
６．２．３制御ＰＤＵ
［・・・］
６．２．３．２散在するＲＯＨＣフィードバックのための制御ＰＤＵ
図６．２．３．２－１は、１つの散在するＲＯＨＣフィードバックを伝送するＰＤＣＰ制御ＰＤＵのフォーマットを示している。この形式は、ＵＭＤＲＢ及びＡＭＤＲＢに適用できる。
［“PDCP Control PDU format for interspersed ROHC feedback”という表題の３ＧＰＰＴＳ３８．３２３Ｖ１５．２．０の図６．２．３．２－１を、図１１として再現する。］

３ＧＰＰＴＳ２３．２８７は、６．３．３．１節において、ＰＣ５参照点を介したＶ２Ｘ通信のユニキャストモードのためのレイヤ２リンク確立手順を指定している。例えば、開始ＵＥ（例えば、ＵＥ１）は、直接通信要求メッセージを送信し、１つ又は複数のピアＵＥ（例えば、ＵＥ２）から直接通信受入れメッセージを受信する。３ＧＰＰＴＳ２３．２８７の５．６．１．４節によると、ＰＣ５ユニキャストリンクを確立するための初期シグナリングは、初期シグナリングにデフォルトの宛先レイヤ２ＩＤを使用して、Ｖ２Ｘサービス、又はＶ２Ｘサービスを提供するＶ２Ｘアプリケーション（例えば、ＰＳＩＤ又はＩＴＳ－ＡＩＤ）のユニキャストリンクを確立できる。

直接通信要求メッセージには、ＵＥ２のアプリケーション層ＩＤ及びＵＥ１のアプリケーション層ＩＤが含まれているので、ＵＥ２は、直接通信要求メッセージに応答するかどうかを決定することができる。ＵＥ２が直接通信要求メッセージに応答すると決定した場合に、ＵＥ２は、セキュリティコンテキストを確立するために使用される手順を開始することができる。例えば、ＵＥ１は、直接通信要求をＵＥ２に送信する。直接通信要求には、セキュリティコンテキストを確立するために使用されるいくつかのパラメータを含めることができる。直接通信要求を受信すると、ＵＥ２は、ＵＥ１との直接認証及び鍵確立手順を開始することができる。次に、ＵＥ２は直接セキュリティモードコマンドをＵＥ１に送信し、ＵＥ１は直接セキュリティモード完了（complete）でＵＥ２に応答する。さらに、直接セキュリティモード完了を成功裏に受信した場合に、ＵＥ２は、直接通信受入れをＵＥ１に送信することができる。ユニキャストリンクにセキュリティが必要ない場合には、セキュリティ構成手順を省略でき、ＵＥ２は、直接通信受入れをＵＥ１に直接応答できる。

直接通信要求メッセージを送信するときに、送信元レイヤ２ＩＤは、開始ＵＥのレイヤ２ＩＤに設定され、宛先レイヤ２ＩＤは、サービスタイプ（例えば、Ｖ２Ｘサービス又はＶ２Ｘアプリケーション）に関連付けられたデフォルトの宛先レイヤ２ＩＤに設定される。従って、ＵＥ２は、ＵＥ１のＬ２ＩＤ及びＵＥ２のＬ２ＩＤに基づいて、セキュリティ確立手順におけるシグナリングを交換し始める可能性がある。

３ＧＰＰＴＲ３８．８８５及び３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）によれば、RRC_CONNECTEDのＵＥは、レイヤ２リンク（又はユニキャストリンク）が確立された後に、サイドリンクＵＥ情報メッセージ（例えば、SidelinkUEInformationNR）をｇＮＢに送信して、サイドリンクトラフィックを送信するためのサイドリンクリソースを要求する必要がある。次に、ｇＮＢは、ＵＥへのＮＲサイドリンク通信のための専用のサイドリンク構成情報（例えば、IE SL-ConfigDedicatedNR）を提供する。

３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）で指定されるように、SidelinkUEInformationNRは、ユニキャストリンクに関連する以下の情報要素（ＩＥ）を含み得る：sl-DestinationIdentity、sl-CastType、sl-RLC、sl-RLC_ModeIndication、sl-QoS-InfoList、sl-Failure、sl-TypeTxSyncList、及びsl-TxInterestedFreqListを含む。また、sl-QoS-InfoListにはsl-QoS-Infoのリストが含まれており、このリストは、ＴＳ２３．２８７でサイドリンクＱｏＳフローのＱｏＳプロファイルを含むように指定されており、各sl-QoS-Infoにはsl-QoS-FlowIdentity、及びsl-QoS-Profileが含まれている。SidelinkUEInformationNRの受信に応答して、ｇＮＢは、ＲＲＣ接続再構成メッセージ（例えば、RRCReconfiguration）で応答して、sl-QoS-FlowIdentityによって識別される関連するサイドリンクＱｏＳフローの専用のサイドリンク構成を構成することができる。例えば、RRCReconfigurationには、専用のサイドリンク構成を示す情報を含むIE SL-ConfigDedicatedNRが含まれ得る。また、そのRRCReconfigurationには、サイドリンクＱｏＳフローがどのＳＬＲＢ（又はＳＬＬＣＨ）にマップされるかを示す情報（例えば、sl-MappedQoS-Flows）が含まれる場合もある。サイドリンクＱｏＳフローは、既存のＳＬＲＢ又は新しいＳＬＲＢにマッピングできる。新しいＳＬＲＢが必要な場合には、ＳＬＲＢ構成（例えば、sl-RadioBearerToAddModList）及び／又は論理チャネル構成（例えば、sl-RLC-BearerToAddModList）が新しいＳＬＲＢに含まれる。各ＳＬＲＢがＳＬＬＣＨに関連付けられることに留意されたい。

（３ＧＰＰＲ２－１９０８１０７で議論される）ＲＡＮ２＃１０６会議で合意されたように、ＳＬユニキャストの場合に、開始ＵＥは、ＴＸとＲＸとの両方に関連し、且つピアＵＥと調整する必要があるＳＬＲＢパラメータをピアＵＥに通知する。例えば、開始ＵＥは、RRCReconfigurationSidelinkメッセージを送信して、（３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）で議論されているように）ピアＵＥに通知することができる。ここで、Slrb-PC5-ConfigIndexには、ピアＵＥで確立されるＳＬＲＢにＳＬＲＢ構成を示すためにRRCReconfigurationSidelinkが含まれる。応答して、ピアＵＥは、RRCReconfigurationCompleteSidelinkメッセージで応答することができる。

さらに、（３ＧＰＰＲ２－１９１６２８８で議論されるように）ＲＡＮ２＃１０８合意によれば、ピアＵＥは、RRC_CONNECTEDのピアＵＥが開始ＵＥからのＲＬＣＡＭ／ＵＭを使用したＳＬＲＢ構成を受信したときであって、ＬＣＨがピアＵＥで構成されていない場合に、開始ＵＥによって示される少なくともＲＬＣモードをそのｇＮＢに報告する必要がある。そのＲＡＮ２＃１０８では、サイドリンクＱｏＳプロファイルはオプションで報告することも合意された。以前の合意は、３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）で得られた。ここで、SidelinkUEInformationNRメッセージで規定されたIE sl-QoS-InfoListはオプションとして指定される。sl-QoS-InfoListが存在する場合に、ピアＵＥには、sl-QoS-InfoListのsl-QoS-FlowIdentityによって識別されるサイドリンクＱｏＳフローからの送信に使用できるデータがあることを意味する。それ以外の場合に（つまり、sl-QoS-InfoListが存在しない場合に）、それには、ピアＵＥには、sl-QoS-InfoListのsl-QoS-FlowIdentityによって識別されるサイドリンクＱｏＳフローからの送信に使用できるデータがないことを意味する。後者の場合に、ピアＵＥには、ＲＬＣ制御ＰＤＵ（ＲＬＣＡＭモードの場合に）又はＰＤＣＰ制御ＰＤＵ（ＲＯＨＣフィードバックの場合に）しかないため、sl-QoS-InfoListを含める必要はないことを意味する。SidelinkUEInformationNRメッセージを受信した後に、ｇＮＢは、sl-QoS-InfoListが存在するかどうかに応じて、適切な専用のサイドリンク構成をピアＵＥに割り当てることができる。

開始ＵＥが、RRCReconfigurationSidelinkメッセージを送信して、（３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）で議論されるように）ピアＵＥに通知して、複数のＳＬＲＢを確立することができるので、ピアＵＥは、ピアＵＥにＳＬＲＢにマッピングされた関連するサイドリンクＱｏＳフローからの送信に使用できるデータがない場合に、どのＳＬＲＢ（又はＳＬＬＣＨ）を、そのｇＮＢによってRRCReconfigurationで提供される専用構成情報に関連付ける必要があるかを知る必要がある。（３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）で議論されるように）ピアＵＥがＲＲＣ実行ＣＲに従う場合に、ピアＵＥは、ピアＵＥに関連するサイドリンクＱｏＳフローからの送信用のトラフィックがない場合に、SidelinkUEInformationNRのsl-QoS-InfoListにsl-QoS-Infoを含めない。このようにして、SidelinkUEInformationNRにはsl-QoS-FlowIdentityが含まれていないため、ｇＮＢは、RRCReconfigurationのSL-RadioBearerConfigにsl-MappedQoS-Flowを含めることはできない。この状況では、ピアＵＥは、RRCReconfigurationによって構成されたＳＬＲＢ（又はＳＬＬＣＨ）をRRCReconfigurationSidelinkによって構成されたＳＬＲＢ（又はＳＬＬＣＨ）にどの様に関連付けるかを知らない。

例えば、RRCReconfigurationSidelinkには、サイドリンクパケットをＵＥからピアＵＥに送信するためにＲＬＣＡＭを使用して第１のＳＬＬＣＨにマッピングされる第１のサイドリンクＱｏＳフローの第１のＩＤ（アイデンティティ）と、サイドリンクパケットをＵＥからピアＵＥに送信するためにＲＬＣＵＭを使用して第２のＳＬＬＣＨにマッピングされる第２のサイドリンクＱｏＳフローの第２のＩＤとを含む。ピアＵＥには現在第１又は第２のＳＬＬＣＨで送信するトラフィックがないため、ピアＵＥはSidelinkUEInformationNRをｇＮＢに依然として送信するが、SidelinkUEInformationNRはサイドリンクＱｏＳプロファイル及び／又は第１／第２のサイドリンクＱｏＳのサイドリンクＱｏＳフローＩＤを報告しない。このSidelinkUEInformationNRを受信すると、ｇＮＢは、第１のＳＬＲＢ又はＳＬＬＣＨに対応する第１の専用構成情報と、第２のＳＬＲＢ又はＳＬＬＣＨに対応する第２の専用構成情報とを含むRRCReconfigurationをピアＵＥに送信できる。ただし、ピアＵＥは、（第１又は第２の）専用構成情報に第１サイドリンクＱｏＳフローの第１のＩＤも第２サイドリンクＱｏＳの第２のＩＤも含まれていないため、どの専用構成情報をどのＳＬＲＢ又はＳＬＬＣＨに関連付けることができない。この問題に対処するために、いくつかの解決策を検討することができる。

１つのオプションの解決策は、ピアＵＥが、関係するＳＬＲＢ（又はＳＬＬＣＨ）に関連する情報をSidelinkUEInformationNRに含めて、そのｇＮＢが、ピアＵＥがどのＳＬＲＢ（又はＳＬＬＣＨ）を専用構成情報に関連付ける必要があるかを知るためにRRCconfiguration内の情報を繰り返すことができるようにすることである。おそらく、関連するＳＬＲＢ（又はＳＬＬＣＨ）に関連する情報は、RRCReconfigurationSidelinkから導出できる。例えば、ピアＵＥは、SiderlinkUEInformationNRにslrb-PC5-ConfigIndexを含めることができ、ｇＮＢは、RRCReconfigurationを介してslrb-PC5-ConfigIndexに専用のサイドリンク構成を提供できる。別の例として、ピアＵＥは、SidelinkUEInformationNRにsl-LogicalChannelIdentityを含めることができ、ｇＮＢは、RRCReconfigurationを介してsl-LogicalChannelIdentityに専用のサイドリンク構成を提供できる。slrb-PC5-ConfigIndex又はsl-LogicalChannelIdentityは、元々RRCReconfigurationSidelinkに含まれており、サイドリンクパケットをＵＥからピアＵＥに送信するように構成されたＳＬＲＢ（又はＳＬＬＣＨ）を識別するために使用される。このようにして、ピアＵＥは、どのＳＬＲＢ（又はＳＬＬＣＨ）をそのｇＮＢによって提供される専用のサイドリンク構成（例えば、IE SL-ConfigDedicatedNR）に関連付ける必要があるかを知ることができる。

あるいはまた、ピアＵＥは、SidelinkUEInformationNRメッセージをそのｇＮＢに送信するときに、sl-QoS-InfoListにsl-QoS-FlowIdentityを含めて、sl-QoS-InfoListにsl-QoS-Profileを含めなくてもよく、ｇＮＢは、サイドリンクＱｏＳフローに専用のサイドリンク構成を提供できる。このようにして、ピアＵＥは、サイドリンクＱｏＳフローが関連するＳＬＲＢ（又はＳＬＬＣＨ）にマッピングされるため、どのＳＬＲＢ（又はＳＬＬＣＨ）を、そのｇＮＢによって提供される専用のサイドリンク構成（例えば、IE SL-ConfigDedicatedNR）に関連付けるべきかを知ることもできる。この代替案は、以前の解決策と比較して、（３ＧＰＰ電子メールディスカッション［１０８＃４４］［Ｖ２Ｘ］３８．３３１実行ＣＲ（Huawei）で議論されるように）現在のＲＲＣ実行ＣＲへの変更が少ない可能性がある。

例えば、ピアＵＥは、ＵＥからRRCReconfigurationSidelinkを受信することができる。RRCReconfigurationSidelinkでは、サイドリンクパケットをＵＥからピアＵＥに送信するために、サイドリンクＱｏＳフローのＩＤがＳＬＲＢ（又はＳＬＬＣＨ）にマッピングされる。次に、ピアＵＥはSidelinkUEInformationNRをｇＮＢに送信できる。SidelinkUEInformationNRでは、サイドリンクＱｏＳフローのＩＤが報告される。SidelinkUEInformationNRの送信後に、ピアＵＥは、ｇＮＢからRRCReconfigurationを受信する。RRCReconfigurationには、サイドリンクパケットをピアＵＥからＵＥに送信するためのＳＬＲＢ（又はＳＬＬＣＨ）を構成するための専用の構成情報が含まれている。専用構成情報には、サイドリンクＱｏＳフローのＩＤが含まれているため、ピアＵＥは、専用構成情報によって構成されたＳＬＲＢ（又はＳＬＬＣＨ）を、RRCReconfigurationSidelinkによって構成されたＳＬＲＢ（又はＳＬＬＣＨ）に関連付ける必要があることを認識する。

あるいはまた、sl-MappedQoS-Flowを含まない各専用の構成情報は、SidelinkUEInformationNRメッセージにSL-QoS-Infoを含めずに１つのSL-TxResourceReqに順序正しくと関連付けることができる。基本的に、ピアＵＥが、SidelinkUEInformationNRメッセージにSL-TxResourceReqのリストを独自に作成するため、ピアＵＥは、SL-QoS-Infoを含まないSL-TxResourceReqを、SRCReconfigurationSidelinkによって構成されたどの１つのＳＬＲＢ（又はＳＬＬＣＨ）に関連付けるかを知る必要がある。従って、ピアＵＥは、sl-MappedQoS-Flowsを含まない専用の構成情報が、このＳＬＲＢ（又はＳＬＬＣＨ）に関してSL-QoS-Infoが報告されない１つのＳＬＲＢ（又はＳＬＬＣＨ）に関連付けられることを知ることができる。

例えば、ＵＥは、サイドリンクパケットをＵＥからピアＵＥに送信するために３つのＳＬＲＢ（又はＳＬＬＣＨ）を確立することができ、１つはＲＬＣＡＭを使用する第１のＳＬＲＢであり、別のはＲＬＣＵＭを使用する第２のＳＬＲＢであり、残りはＲＬＣＡＭを使用する第３のＳＬＲＢである。第１のＳＬＲＢはサイドリンクＱｏＳフローＩＤ１にマップされる。第２のＳＬＲＢはサイドリンクＱｏＳフローＩＤ２＆３にマップされる。第３のＳＬＲＢは、サイドリンクＱｏＳフローＩＤ４＆５にマッピングされる。ＵＥは、RRCReconfigurationSidelinkメッセージをピアＵＥに送信することができ、ここで、RRCReconfigurationSidelinkメッセージは、以下の表１に示されるように、これらの３つのＳＬＲＢを構成するためのＩＥを含む。
RRCReconfigurationSidelinkの表１

RRCReconfigurationSidelinkメッセージを受信すると、ピアＵＥは、SidelinkUEInformationNRメッセージをｇＮＢに送信する。この時点で、ピアＵＥは、ＰＦＩ２＆３に関連付けられたサイドリンクＱｏＳフローでのみ送信するトラフィックを有し得る。従って、ピアＵＥは、SidelinkUEInformationNRメッセージでＰＦＩ２＆３のみを報告する。ＰＦＩ２＆３は、sl-UM-QoS-InfoList又はsl-QoS-InfoListを介して報告できる。表２－１及び表２－２にＰＦＩ２＆３を別々に報告する２つの例がある。
SidelinkUEInformationNRの例１の表２－１

SidelinkUEInformationNRの例２の表２－２

SidelinkUEInformationNRメッセージを受信すると、ｇＮＢは、RRCconfigurationメッセージをピアＵＥに応答する。ｇＮＢは、様々な方法でRRCconfigurationメッセージにＩＥを含めることができる。RRCconfigurationメッセージには、第１の専用構成情報（SL-RadioBearerConfig#1及びSL-RLC-BearerConfig#1）、第２の専用構成情報（SL-RadioBearerConfig#2及びSL-RLC-BearerConfig#2）、及び第３の専用構成情報（SL-RadioBearerConfig#3及びSL-RLC-BearerConfig#3）が含まれている。sl-MappedQoS-FlowsのSL-QoS-FlowIdentityとsl-QoS-FlowIdentityとの両方がＳＬＲＢ２にマッピングされる（つまり、sl-MappedQoS-FlowsのSL-QoS-FlowIdentityはsl-QoS-FlowIdentityと同じである）ため、ピアＵＥは、ＰＦＩ２＆３を含む専用の設定情報をＳＬＲＢ２に関連付けることができる。

一例を表３－１に示すことができる。このRRCconfigurationメッセージを使用して、ピアＵＥは、第１の専用構成情報をＳＬＲＢ１に関連付け、且つ第３の専用構成情報をＳＬＲＢ３に関連付ける。
RRCReconfigurationの例１の表３－１

別の例が、表３－２に例示され得る。このRRCReconfigurationメッセージを使用して、ピアＵＥは、第２の専用構成情報をＳＬＲＢ１に関連付け、且つ第３の専用構成情報をＳＬＲＢ３に関連付ける。
RRCReconfigurationの例２の表３－２

別の例が、表３－３に例示され得る。このRRCReconfigurationメッセージを使用して、ピアＵＥは、第１の専用構成情報をＳＬＲＢ１に関連付け、且つ第２の専用構成情報をＳＬＲＢ３に関連付ける。
RRCReconfigurationの例３の表３－３

図１２は、専用のサイドリンク構成を要求する第１のＵＥの観点からの例示的な一実施形態によるフローチャート１２００である。ステップ１２０５において、第１のＵＥは、第１のＲＲＣメッセージをネットワークノードに送信し、第１のＲＲＣメッセージはサイドリンクＱｏＳ情報を含み、サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのＩＤ（アイデンティティ）の存在は必須であり、サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのＱｏＳプロファイルの存在は随意（オプション）である。ステップ１２１０において、第１のＵＥは、ネットワークノードから第２のＲＲＣメッセージを受信し、第２のＲＲＣメッセージは、専用のサイドリンク構成と、専用のサイドリンク構成に関連付けられたサイドリンクＱｏＳフローのＩＤとを含む。

一実施形態では、サイドリンクＱｏＳ情報は、サイドリンクＱｏＳフローのＩＤを含み得、サイドリンクＱｏＳフローからの送信に利用可能なデータがない場合に、サイドリンクＱｏＳフローのＱｏＳプロファイルを含まない場合がある。さらに、サイドリンクＱｏＳ情報は、サイドリンクＱｏＳフローのＩＤを含み得、サイドリンクＱｏＳフローからの送信に利用可能なデータがある場合に、サイドリンクＱｏＳフローのＱｏＳプロファイルも含み得る。

一実施形態では、第１のＵＥは、第１のＲＲＣメッセージをネットワークノードに送信する前に、第２のＵＥから第１のサイドリンクＲＲＣメッセージを受信することができる。第１のサイドリンクＲＲＣメッセージには、受信のためのＳＬＲＢ構成、ＳＬＲＢ構成に対するインデックス（例えば、slrb-PC5-ConfigIndex）、及び／又は論理チャネル構成が含まれ得る。第１のサイドリンクＲＲＣメッセージは、RRCReconfigurationSidelinkメッセージであり得る。さらに、第１のＵＥは、専用のサイドリンク構成によって構成されたカウンターＳＬＲＢを、サイドリンクＱｏＳフローのＩＤに従って第１のサイドリンクＲＲＣメッセージによって構成されたＳＬＲＢに関連付けることができる。ＳＬＲＢは、パケットを第２のＵＥから第１のＵＥに送信するために使用され得、カウンターＳＬＲＢは、パケットを第１のＵＥから第２のＵＥに送信するために使用される。

一実施形態では、第１のＲＲＣメッセージは、SidelinkUEInformationNRメッセージであり得、第２のＲＲＣメッセージは、RRCReconfigurationメッセージであり得る。

一実施形態では、ネットワークノードは、基地局（例えば、ｇＮＢ）であり得る。

図３及び図４を再び参照すると、専用のサイドリンク構成を要求する第１のＵＥの例示的な一実施形態において、第１のＵＥ３００は、メモリ３１０に格納されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、第１のＵＥが、（ｉ）第１のＲＲＣメッセージをネットワークノードに送信できるようにし、第１のＲＲＣメッセージはサイドリンクＱｏＳ情報を含み、サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのＩＤ（アイデンティティ）の存在は必須であり、サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのＱｏＳプロファイルの存在は随意（オプション）であり、（ｉｉ）ネットワークノードから第２のＲＲＣメッセージを受信し、第２のＲＲＣメッセージは、専用のサイドリンク構成と、専用のサイドリンク構成に関連付けられたサイドリンクＱｏＳフローのＩＤとを含む。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上記の全てのアクション及びステップ、又は本明細書で説明する他のものを実行することができる。

図１３は、専用のサイドリンク構成を要求する第１のＵＥの観点からの例示的な一実施形態によるフローチャート１３００である。ステップ１３０５において、第１のＵＥは、第１のＲＲＣメッセージをネットワークノードに送信し、第１のＲＲＣメッセージはサイドリンクＱｏＳ情報を含み、サイドリンクＱｏＳ情報は、サイドリンクＱｏＳフローのＩＤを含むが、サイドリンクＱｏＳフローのＱｏＳプロファイルを含まない。ステップ１３１０において、第１のＵＥは、ネットワークノードから第２のＲＲＣメッセージを受信し、第２のＲＲＣメッセージは、専用のサイドリンク構成と、専用のサイドリンク構成に関連付けられたサイドリンクＱｏＳフローのＩＤとを含む。

一実施形態では、第１のＲＲＣメッセージは、宛先ＩＤ（例えば、宛先レイヤ２ＩＤ）、キャストタイプ、ＲＬＣモード指標、及び／又は周波数を含み得る。第２のＲＲＣメッセージは、リソース割当てモード、送信のためのＳＬＲＢ構成、及び／又は論理チャネル構成を含み得る。

一実施形態では、第１のＵＥは、第１のＲＲＣメッセージを送信する前に、第２のＵＥから第１のサイドリンクＲＲＣメッセージを受信することができる。さらに、第１のＵＥは、第２のＵＥからの第１のサイドリンクＲＲＣメッセージの受信に応答して、第１のＲＲＣメッセージを送信することができる。第１のサイドリンクＲＲＣメッセージは、受信のためのＳＬＲＢ構成、ＳＬＲＢ構成に対するインデックス（例えば、slrb-PC5-ConfigIndex）、及び／又は論理チャネル構成を含み得る。さらに、第１のＵＥは、第２のサイドリンクＲＲＣメッセージで第２のＵＥに応答することができる。

一実施形態では、第１のＲＲＣメッセージは、SidelinkUEInformationNRメッセージであり得る。第２のＲＲＣメッセージは、RRCReconfigurationメッセージであり得る。第１のサイドリンクＲＲＣメッセージは、RRCReconfigurationSidelinkメッセージであり得る。第２のサイドリンクＲＲＣメッセージは、RRCReconfigurationCompleteSidelinkメッセージであり得る。

図３及び図４を再び参照すると、専用サイドリンクリソースを要求する第１のＵＥの一例の実施形態において、第１のＵＥ３００は、メモリ３１０に格納されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、第１のＵＥが、（ｉ）第１のＲＲＣメッセージをネットワークノードに送信できるようにし、第１のＲＲＣメッセージはサイドリンクＱｏＳ情報を含み、サイドリンクＱｏＳ情報は、サイドリンクＱｏＳフローのＩＤ（アイデンティティ）を含むが、サイドリンクＱｏＳフローのＱｏＳプロファイルを含まず、（ｉｉ）ネットワークノードから第２のＲＲＣメッセージを受信し、第２のＲＲＣメッセージは、専用のサイドリンク構成と、専用のサイドリンク構成に関連付けられたサイドリンクＱｏＳフローのＩＤとを含む。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上記の全てのアクション及びステップ、又は本明細書で説明する他のものを実行することができる。

図１４は、サイドリンク無線ベアラ（ＳＬＲＢ）構成を要求する第１のＵＥの観点からの例示的な一実施形態によるフローチャート１４００である。ステップ１４０５において、第１のＵＥは、第１のＲＲＣメッセージをネットワークノードに送信し、第１のＲＲＣメッセージは、１つ又は複数のＳＬＲＢ構成を要求するための送信リソース要求のリストを含み、送信リソース要求のリスト内の各エントリには、サイドリンクＱｏＳ情報のための少なくとも１つのＩＥがある。ステップ１４１０において、第１のＵＥは、ネットワークノードから第２のＲＲＣメッセージを受信し、第２のＲＲＣメッセージは、１つ又は複数のＳＬＲＢ構成を含む。ステップ１４１５において、第１のＵＥは、第２のＲＲＣメッセージのサイドリンクＱｏＳフローＩＤに関連付けられていない各ＳＬＲＢ構成を、第１のＲＲＣメッセージの送信リソース要求のリスト内のサイドリンクＱｏＳ情報を示さない１つのエントリに順番に対応させる。ステップ１４２０において、第１のＵＥは、第２のＲＲＣメッセージのＳＬＲＢ構成に基づいて、ＳＬＬＣＨ上でのサイドリンク制御パケットを第２のＵＥに送信する。

一実施形態では、送信リソース要求のリスト内の各エントリには、ＲＬＣモード指標のための１つのＩＥもある。

一実施形態では、第１のＵＥは、第２のＵＥからＰＣ５ＲＲＣメッセージを受信することができ、ＰＣ５ＲＲＣメッセージは、第１のＬＣＩＤ及びＲＬＣモードを使用する第１のＳＬＲＢ（又は第１のＳＬＬＣＨ）の確立を示し、第１のＳＬＲＢは、第１のＰＦＩ及び／又は第１のサイドリンクＱｏＳプロファイルに関連付けられた第１のサイドリンクＱｏＳフローにマッピングされる。ＰＣ５ＲＲＣメッセージはまた、第２のＬＣＩＤ及びＲＬＣモードを使用する第２のＳＬＲＢ（又は第２のＳＬＬＣＨ）の確立を示し得、第２のＳＬＲＢは、第２のＰＦＩ及び／又は第２のサイドリンクＱｏＳプロファイルに関連する第２のサイドリンクＱｏＳフローにマッピングされる。

一実施形態では、送信リソース要求のリストの第１のエントリは、第１のＳＬＲＢのＲＬＣモードを示し得るが、第１のＰＦＩ及び／又は第１のサイドリンクＱｏＳプロファイルを含まない場合がある。さらに、送信リソース要求のリストの第２のエントリは、第２のＳＬＲＢのＲＬＣモードを示し得るが、第２のＰＦＩ及び／又は第２のサイドリンクＱｏＳプロファイルを含まない場合がある。第２のＲＲＣメッセージは、どのＰＦＩにも関連付けられていない第１のＳＬＲＢ構成と、どのＰＦＩにも順番に関連付けられていない第２のＳＬＲＢ構成とを含み得る。

一実施形態では、第１のエントリは、１つのＳＬＲＢの１つのＲＬＣモードを示し得るが、ＰＦＩ及び／又はサイドリンクＱｏＳプロファイルを含まない場合がある、送信リソース要求のリストの第１のエントリであり得る。第２のエントリは、送信リソース要求のリストの第１のエントリに続くエントリであり、１つのＳＬＲＢの１つのＲＬＣモードを示し得るが、ＰＦＩ及び／又はサイドリンクＱｏＳプロファイルを含まない場合がある。

一実施形態では、第１のＳＬＲＢ構成は、このＳＬＲＢ構成に関連する任意のＰＦＩを示し得る、第２のＲＲＣメッセージにおける第１のＳＬＲＢ構成であり得る。第２のＳＬＲＢ構成は、第２のＲＲＣメッセージの第１のＳＬＲＢ構成に続くＳＬＲＢ構成であり得、このＳＬＲＢ構成に関連付けられたＰＦＩを示さない場合がある。

一実施形態では、第１のＵＥは、第１のＳＬＲＢ構成に基づいて、第１のＬＣＩＤに関連付けられた１つのＳＬＬＣＨ上で１つ又は複数のサイドリンク制御パケットを送信することができる。第１のＵＥはまた、第２のＳＬＲＢ構成に基づいて、第２のＬＣＩＤに関連付けられた１つのＳＬＬＣＨ上で１つ又は複数のサイドリンク制御パケットを送信することができる。

一実施形態では、第１のＲＲＣメッセージは、SidelinkUEInformationNRメッセージであり得る。第２のＲＲＣメッセージは、RRCReconfigurationメッセージであり得る。ＰＣ５ＲＲＣメッセージは、RRCReconfigurationSidelinkメッセージであり得る。

一実施形態では、サイドリンク制御パケットは、ＲＬＣステータスレポート又はＲｏＨＣフィードバックであり得る。サイドリンクＱｏＳ情報は、サイドリンク又はＰＣ５ＱｏＳフローＩＤ（ＰＦＩ）及び／又はサイドリンクＱｏＳフローのためのサイドリンクＱｏＳプロファイルを含み得る。

図３及び図４を再び参照すると、ＳＬＲＢ構成を要求する第１のＵＥの一例の実施形態において、第１のＵＥ３００は、メモリ３１０に格納されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、第１のＵＥが、（ｉ）第１のＲＲＣメッセージをネットワークノードに送信できるようにし、第１のＲＲＣメッセージは、１つ又は複数のＳＬＲＢ構成を要求するための送信リソース要求のリストを含み、送信リソース要求のリスト内の各エントリには、サイドリンクＱｏＳ情報のための少なくとも１つのＩＥがあり、（ｉｉ）ネットワークノードから第２のＲＲＣメッセージを受信し、第２のＲＲＣメッセージは１つ又は複数のＳＬＲＢ構成を含み、（ｉｉｉ）第２のＲＲＣメッセージのサイドリンクＱｏＳフローＩＤに関連付けられていない各ＳＬＲＢ構成を、第１のＲＲＣメッセージの送信リソース要求のリストにあるサイドリンクＱｏＳ情報を示さない１つのエントリに順番に対応させ、（ｉｖ）第２のＲＲＣメッセージのＳＬＲＢ構成に基づいて、ＳＬＬＣＨ上でサイドリンク制御パケットを第２のＵＥに送信する。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上記の全てのアクション及びステップ、又は本明細書で説明する他のものを実行することができる。

図１５は、専用のサイドリンク構成を割り当てるネットワークノードの観点からの例示的な一実施形態によるフローチャート１５００である。ステップ１５０５において、ネットワークノードは、第１のＵＥから第１のＲＲＣメッセージを受信し、第１のＲＲＣメッセージはサイドリンクＱｏＳ情報を含み、サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのＩＤ（アイデンティティ）の存在は必須であり、サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのＱｏＳプロファイルの存在は随意（オプション）である。ステップ１５１０において、ネットワークノードは、第２のＲＲＣメッセージを第１のＵＥに送信し、第２のＲＲＣメッセージは、専用のサイドリンク構成と、専用のサイドリンク構成に関連付けられたサイドリンクＱｏＳフローのＩＤとを含む。

一実施形態では、サイドリンクＱｏＳ情報は、サイドリンクＱｏＳフローのＩＤを含み得、サイドリンクＱｏＳフローからの送信のために第１のＵＥに利用可能なデータがない場合に、サイドリンクＱｏＳフローのＱｏＳプロファイルを含まない場合がある。あるいはまた、サイドリンクＱｏＳ情報は、サイドリンクＱｏＳフローのＩＤを含み得、サイドリンクＱｏＳフローからの送信のために第１のＵＥに利用可能なデータがある場合に、サイドリンクＱｏＳフローのＱｏＳプロファイルも含み得る。

一実施形態では、第１のＲＲＣメッセージは、SidelinkUEInformationNRメッセージであり得、第２のＲＲＣメッセージは、RRCReconfigurationメッセージである。

図３及び図４を再び参照すると、専用のサイドリンク構成を割り当てるネットワークノードの観点からのＳＬＲＢ構成を要求する第１のＵＥの例示的な一実施形態では、ネットワークノード３００は、メモリ３１０に格納されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、ネットワークノードが、（ｉ）第１のＵＥから第１のＲＲＣメッセージを受信できるようにし、第１のＲＲＣメッセージはサイドリンクＱｏＳ情報を含み、サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのＩＤ（アイデンティティ）の存在は必須であり、サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのＱｏＳプロファイルの存在は随意（オプション）であり、（ｉｉ）第２のＲＲＣメッセージを第１のＵＥに送信し、第２のＲＲＣメッセージは、専用のサイドリンク構成と、専用のサイドリンク構成に関連付けられたサイドリンクＱｏＳフローのＩＤとを含む。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上記の全てのアクション及びステップ、又は本明細書で説明する他のものを実行することができる。

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

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

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

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

開示されたプロセスにおけるステップの特定の順序又は階層は、サンプルアプローチの例であることが理解される。設計の好みに基づいて、プロセスのステップの特定の順序又は階層は、本開示の範囲内にとどまりながら再配置され得ることが理解される。付随する方法は、サンプル順序で様々なステップの要素を提示すことを主張し、提示される特定の順序又は階層に限定されることを意味するものではない。

本明細書に開示する態様に関連して説明する方法又はアルゴリズムのステップは、ハードウェア、プロセッサによって実行されるソフトウェアモジュール、又はこれら２つの組合せで直接具体化され得る。ソフトウェアモジュール（例えば、実行可能命令及び関連データを含む）及び他のデータは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ－ＲＯＭ、又は当技術分野で知られている他の形式のコンピュータ可読記憶媒体等のデータメモリに存在し得る。サンプル記憶媒体は、例えば、コンピュータ／プロセッサ（本明細書では、便宜上、「プロセッサ」と呼ばれ得る）等のマシンに結合することができ、そのようなプロセッサは、記憶媒体から情報（例えば、コード）を読み取り、且つ記憶媒体に情報を書き込むことができる。サンプル記憶媒体は、プロセッサに一体化され得る。プロセッサ及び記憶媒体はＡＳＩＣに存在してもよい。ＡＳＩＣはユーザ機器に存在してもよい。代替構成では、プロセッサ及び記憶媒体は、ユーザ機器内の個別のコンポーネントとして存在してもよい。さらに、いくつかの態様では、任意の適切なコンピュータプログラム製品は、本開示の１つ又は複数の態様に関連するコードを含むコンピュータ可読媒体を含み得る。いくつかの態様では、コンピュータプログラム製品は、パッケージング材料を含み得る。

本発明について様々な態様に関連して説明してきたが、本発明は更なる修正が可能であることが理解されよう。本願は、一般に、本発明の原理に従い、本発明が関係する当技術分野内の既知の慣習的慣行の範囲内にある本開示からの逸脱を含む、本発明の任意の変形、使用、又は適合を網羅することを意図している。

Claims

第１のユーザ機器（ＵＥ）が専用のサイドリンク構成を要求するための方法であって、当該方法は、
第２のＵＥから前記第１のＵＥへの送信に使用される第１のサイドリンク無線ベアラ（ＳＬＲＢ）を構成するために、第１のサイドリンク無線リソース制御（ＲＲＣ）メッセージを前記第２のＵＥから受信するステップと、
前記第２のＵＥから前記第１のサイドリンクＲＲＣメッセージを受信することに応答して、第１のＲＲＣメッセージをネットワークノードに送信するステップであって、前記第１のＲＲＣメッセージはサイドリンクサービス品質（ＱｏＳ）情報を含み、該サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのアイデンティティ（ＩＤ）の存在が必須であり、前記サイドリンクＱｏＳ情報における前記サイドリンクＱｏＳフローのＱｏＳプロファイルの存在が随意である、送信するステップと、
前記ネットワークノードから第２のＲＲＣメッセージを受信するステップであって、該第２のＲＲＣメッセージは、前記第１のＵＥから前記第２のＵＥへの送信に使用される第２のＳＬＲＢを構成するための第２の専用のサイドリンク構成と、該第２の専用のサイドリンク構成に関連付けられた前記サイドリンクＱｏＳフローの前記ＩＤとを含む、受信するステップと、を含む、
方法。
前記サイドリンクＱｏＳ情報は、前記サイドリンクＱｏＳフローの前記ＩＤを含み、前記第１のＵＥから前記第２のＵＥへの送信に利用可能な前記サイドリンクＱｏＳフローのデータがない場合に、前記サイドリンクＱｏＳフローのＱｏＳプロファイルを含まない、請求項１に記載の方法。
前記サイドリンクＱｏＳ情報は、前記サイドリンクＱｏＳフローの前記ＩＤを含み、前記第１のＵＥから前記第２のＵＥへの送信に利用可能な前記サイドリンクＱｏＳフローのデータがある場合に、前記サイドリンクＱｏＳフローの前記ＱｏＳプロファイルも含む、請求項１に記載の方法。
前記第１のサイドリンクＲＲＣメッセージは、前記第１のＳＬＲＢのための第１の専用のサイドリンク構成、該第１の専用のサイドリンク構成に対するインデックス、及び／又は論理チャネル構成を含む、請求項１に記載の方法。
前記第１のサイドリンクＲＲＣメッセージは、ＲＲＣ再構成サイドリンク（RRCReconfigurationSidelink）メッセージである、請求項１に記載の方法。
前記第２のＳＬＲＢを、前記サイドリンクＱｏＳフローの前記ＩＤに従って前記第１のＳＬＲＢに関連付けるステップをさらに含む、請求項１に記載の方法。
前記第１のＲＲＣメッセージは、サイドリンクＵＥ情報ＮＲ（SidelinkUEInformationNR）メッセージであり、前記第２のＲＲＣメッセージは、ＲＲＣ再構成（RRCReconfiguration）メッセージである、請求項１に記載の方法。
前記ネットワークノードは、基地局である、請求項１に記載の方法。
第１のユーザ機器（ＵＥ）であって、当該第１のＵＥは、
制御回路と、
該制御回路に取り付けられたプロセッサと、
前記制御回路に取り付けられ、且つ前記プロセッサに動作可能に結合されたメモリと、を含み、
前記プロセッサは、前記メモリに格納されたプログラムコードを実行して、
第２のＵＥから前記第１のＵＥへの送信に使用される第１のサイドリンク無線ベアラ（ＳＬＲＢ）を構成するために、第１のサイドリンク無線リソース制御（ＲＲＣ）メッセージを第２のＵＥから受信することと、
前記第２のＵＥから前記第１のサイドリンクＲＲＣメッセージを受信することに応答して、第１のＲＲＣメッセージをネットワークノードに送信することであって、前記第１のＲＲＣメッセージはサイドリンクサービス品質（ＱｏＳ）情報を含み、該サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのアイデンティティ（ＩＤ）の存在は必須であり、前記サイドリンクＱｏＳ情報における前記サイドリンクＱｏＳフローのＱｏＳプロファイルの存在は随意である、前記送信することと、
前記ネットワークノードから第２のＲＲＣメッセージを受信することであって、該第２のＲＲＣメッセージは、前記第１のＵＥから前記第２のＵＥへの送信に使用される第２のＳＬＲＢを構成するための第２の専用のサイドリンク構成と、該第２の専用のサイドリンク構成に関連付けられた前記サイドリンクＱｏＳフローの前記ＩＤとを含む、前記受信することと、を行うように構成される、
第１のＵＥ。
前記サイドリンクＱｏＳ情報は、前記サイドリンクＱｏＳフローの前記ＩＤを含み、前記第１のＵＥから前記第２のＵＥへの送信に利用可能な前記サイドリンクＱｏＳフローのデータがない場合に、前記サイドリンクＱｏＳフローのＱｏＳプロファイルを含まない、請求項９に記載の第１のＵＥ。
前記サイドリンクＱｏＳ情報は、前記サイドリンクＱｏＳフローの前記ＩＤを含み、前記第１のＵＥから前記第２のＵＥへの送信に利用可能な前記サイドリンクＱｏＳフローのデータがある場合に、前記サイドリンクＱｏＳフローの前記ＱｏＳプロファイルも含む、請求項９に記載の第１のＵＥ。
前記第１のサイドリンクＲＲＣメッセージは、前記第１のＳＬＲＢのための第１の専用のサイドリンク構成、該第１の専用のサイドリンク構成に対するインデックス、及び／又は論理チャネル構成を含む、請求項９に記載の第１のＵＥ。
ネットワークノードが専用のサイドリンク構成を割り当てるための方法であって、当該方法は、
第１のユーザ機器（ＵＥ）から第１の無線リソース制御（ＲＲＣ）メッセージを受信するステップであって、該第１のＲＲＣメッセージはサイドリンクサービス品質（ＱｏＳ）情報を含み、該サイドリンクＱｏＳ情報におけるサイドリンクＱｏＳフローのアイデンティティ（ＩＤ）の存在は必須であり、前記サイドリンクＱｏＳ情報における前記サイドリンクＱｏＳフローのＱｏＳプロファイルの存在は随意であり、前記サイドリンクＱｏＳ情報は、前記第１のＵＥから前記第２のＵＥへの送信のために前記第１のＵＥに利用可能な前記サイドリンクＱｏＳフローのデータがある場合に、前記サイドリンクＱｏＳフローの前記ＱｏＳプロファイルを含む、受信するステップと、
第２のＲＲＣメッセージを前記第１のＵＥに送信するステップであって、前記第２のＲＲＣメッセージは、前記第１のＵＥから前記第２のＵＥへの送信に使用されるＳＬＲＢを構成するための専用のサイドリンク構成と、該専用のサイドリンク構成に関連付けられた前記サイドリンクＱｏＳフローの前記ＩＤとを含む、送信するステップと、を含む、
方法。
前記サイドリンクＱｏＳ情報は、前記第１のＵＥから前記第２のＵＥへの送信のために前記第１のＵＥに利用可能な前記サイドリンクＱｏＳフローのデータがない場合に、前記サイドリンクＱｏＳフローのＱｏＳプロファイルを含まない、請求項１３に記載の方法。
前記第１のＲＲＣメッセージは、サイドリンクＵＥ情報ＮＲ（SidelinkUEInformationNR）メッセージであり、前記第２のＲＲＣメッセージは、ＲＲＣ再構成（RRCReconfiguration）メッセージである、請求項１３に記載の方法。
前記ネットワークノードは、基地局である、請求項１３に記載の方法。