特許 6983216 送信装置、方法および集積回路

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

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

(11)【特許番号】6983216

(24)【登録日】2021年11月25日

(45)【発行日】2021年12月17日

(54)【発明の名称】送信装置、方法および集積回路

(51)【国際特許分類】

   H04W 72/02 20090101AFI20211206BHJP

   H04W 92/18 20090101ALI20211206BHJP

   H04W 4/46 20180101ALI20211206BHJP

   H04W 80/12 20090101ALI20211206BHJP

   H04W 80/06 20090101ALI20211206BHJP

【ＦＩ】

   H04W72/02

   H04W92/18

   H04W4/46

   H04W80/12

   H04W80/06

【請求項の数】7

【全頁数】55

(21)【出願番号】特願2019-500598(P2019-500598)

(86)(22)【出願日】2017年5月15日

(65)【公表番号】特表2019-522430(P2019-522430A)

(43)【公表日】2019年8月8日

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

(87)【国際公開番号】WO2018016157

(87)【国際公開日】20180125

【審査請求日】2020年3月10日

(31)【優先権主張番号】16179995.2

(32)【優先日】2016年7月18日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】110002952

【氏名又は名称】特許業務法人鷲田国際特許事務所

(72)【発明者】

【氏名】ローア ヨアキム

(72)【発明者】

【氏名】バス マリック プラテーク

(72)【発明者】

【氏名】堀 貴子

【審査官】 伊東 和重

(56)【参考文献】

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

【文献】 Huawei, HiSilicon，Support of QoS for PC5-based V2V transport[online]，3GPP TSG-RAN WG2#94，R2-163811，3GPP，2016年05月27日，検索日[2021.02.25],インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_94/Docs/R2-163811.zip＞

【文献】 Huawei, HiSilicon，QoS Support for V2X transmission[online]，3GPP TSG-RAN WG2#93，R2-161101，3GPP，検索日[2021.07.13],インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_93/Docs/R2-161101.zip＞

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

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

Ｈ０４Ｗ ４／００−９９／００

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

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１，４

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

【請求項1】

１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するための送信装置であって、前記送信装置が、前記サイドリンクインタフェースを介して前記車両データを送信するための自律無線リソース割当てを行い、前記送信装置が、
動作の際、１つまたは複数のサービス品質構成を、無線基地局によってその無線セルでブロードキャストされるシステム情報または個別シグナリングによって受信し、または予め設定し、
動作の際、前記車両データを生成し、前記サイドリンクインタフェースを介する前記車両データの送信の役割を担う送信レイヤに指示と共に前記生成した車両データを転送するアプリケーションレイヤと、
動作の際、前記車両データと共に受け取った前記指示に応じて、前記１つまたは複数のサービス品質構成の１つを決定する前記送信レイヤであって、動作に際して、前記決定した１つのサービス品質構成に基づいて前記自律無線リソース割当てを行う前記送信レイヤとを備え、
前記送信レイヤが、動作に際して、前記行った自律無線リソース割当てに従って前記１つまたは複数の受信装置に前記サイドリンクインタフェースを介して前記車両データを送信し、
前記送信レイヤが、前記車両データを送信するに際して、異なるサイドリンク論理チャネルの前記車両データが１つのトランスポートブロック（ＴＢ）に多重化される場合、前記異なるサイドリンク論理チャネルのうち、最高優先度を有するサイドリンク論理チャネルに関連付けられた前記サービス品質構成に基づいて、前記サイドリンクインタフェースを介して前記ＴＢを送信する、
送信装置。

【請求項2】

前記１つまたは複数のサービス品質構成の各々が、
− パケット遅延バジェット：送信のために利用可能になってから前記車両データを送信するために許容される上限時間を示す
− パケット誤り損失率：損失車両データの許容率を示す
− リソース型：保証ビットレートを有するまたは有しない、の少なくとも１つを示す、
請求項１に記載の送信装置。

【請求項3】

前記送信レイヤに前記車両データと共に送られた前記指示が優先度指示であり、前記車両データの優先度を示し、
前記送信レイヤが、前記受け取った優先度指示、および前記１つまたは複数のサービス品質構成の各々を優先度指示値と関連づける、前記送信装置に記憶されるマッピングを使用して前記１つのサービス品質構成を決定し、前記マッピングが、前記無線基地局によってその無線セルでブロードキャストされる、前記アプリケーションレイヤによって提供される前記システム情報で受け取られる、または事前設定される、
請求項１または２に記載の送信装置。

【請求項4】

前記アプリケーションレイヤが、どのサービス品質構成を使用するべきかを決定し、前記決定した１つのサービス品質構成を示すサービス品質クラス指示を生成し、前記送信レイヤに前記車両データと共に送られた前記指示が、前記生成したサービス品質クラス指示であり、
前記送信レイヤに前記車両データと共に優先度指示が送られ、前記優先度指示が、前記車両データの優先度を示す、
請求項１〜３のいずれか一項に記載の送信装置。

【請求項5】

送信装置から１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するための方法であって、前記送信装置が、前記サイドリンクインタフェースを介して前記車両データを送信するための自律無線リソース割当てを行い、前記方法が、前記送信装置によって行われる以下の、
１つまたは複数のサービス品質構成を、無線基地局によってその無線セルでブロードキャストされるシステム情報または個別シグナリングによって受信する、または予め設定するステップと、
前記車両データをアプリケーションレイヤで生成し、前記サイドリンクインタフェースを介する前記車両データの送信の役割を担う送信レイヤに指示と共に前記生成した車両データを転送するステップと、
前記送信レイヤによって、前記車両データと共に受け取った前記指示に応じて、前記１つまたは複数のサービス品質構成の１つを決定し、前記送信レイヤによって、前記決定した１つのサービス品質構成に基づいて前記自律無線リソース割当てを行うステップと、
前記行った自律無線リソース割当てに従って前記１つまたは複数の受信装置に前記サイドリンクインタフェースを介して前記車両データを送信するステップと、
を含み、
前記車両データを送信するステップでは、異なるサイドリンク論理チャネルの前記車両データが１つのトランスポートブロック（ＴＢ）に多重化される場合、前記異なるサイドリンク論理チャネルのうち、最高優先度を有するサイドリンク論理チャネルに関連付けられた前記サービス品質構成に基づいて、前記サイドリンクインタフェースを介して前記ＴＢを送信する、
方法。

【請求項6】

前記１つまたは複数のサービス品質構成の各々が、
− パケット遅延バジェット：送信のために利用可能になってから前記車両データを送信するために許容される上限時間を示す
− パケット誤り損失率：損失車両データの許容率を示す
− リソース型：保証ビットレートを有するまたは有しない、の少なくとも１つを示す、
請求項５に記載の方法。

【請求項7】

送信装置から１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信する前記送信装置の処理を制御する集積回路であって、前記送信装置が、前記サイドリンクインタフェースを介して前記車両データを送信するための自律無線リソース割当てを行い、前記処理が、前記集積回路によって制御される以下の、
１つまたは複数のサービス品質構成を、無線基地局によってその無線セルでブロードキャストされるシステム情報または個別シグナリングによって受信する、または予め設定するステップと、
前記車両データをアプリケーションレイヤで生成し、前記サイドリンクインタフェースを介する前記車両データの送信の役割を担う送信レイヤに指示と共に前記生成した車両データを転送するステップと、
前記送信レイヤによって、前記車両データと共に受け取った前記指示に応じて、前記１つまたは複数のサービス品質構成の１つを決定し、前記送信レイヤによって、前記決定した１つのサービス品質構成に基づいて前記自律無線リソース割当てを行うステップと、
前記行った自律無線リソース割当てに従って前記１つまたは複数の受信装置に前記サイドリンクインタフェースを介して前記車両データを送信するステップと、
を含み、
前記車両データを送信するステップでは、異なるサイドリンク論理チャネルの前記車両データが１つのトランスポートブロック（ＴＢ）に多重化される場合、前記異なるサイドリンク論理チャネルのうち、最高優先度を有するサイドリンク論理チャネルに関連付けられた前記サービス品質構成に基づいて、前記サイドリンクインタフェースを介して前記ＴＢを送信する、
集積回路。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、サイドリンクインタフェースを介して車両データを送信するための改善されたＱｏＳサポートに関する。本開示は、対応する（車両）移動端末、基地局および対応する方法を提供している。

【背景技術】

【0002】

＜ロングタームエボリューション（ＬＴＥ：Long Term Evolution）＞
ＷＣＤＭＡ（登録商標）無線アクセス技術に基づく第３世代移動システム（３Ｇ）が世界中至る所で広範に展開されつつある。この技術を強化または進化させる際の第１段階は、競争力の高い無線アクセス技術をもたらす、ＨＳＤＰＡ（High-Speed Downlink Packet Access）および、ＨＳＵＰＡ（High Speed Uplink Packet Access）とも称される強化型アップリンクを導入することを伴う。

【0003】

さらに増加するユーザ需要に備え、かつ新たな無線アクセス技術に対して競争力があるために、３ＧＰＰは、ＬＴＥと呼ばれる新たな移動通信システムを導入した。ＬＴＥは、次の１０年間、高速データおよびメディア転送の他に大容量音声サポートの通信事業者要求を満たすように設計されている。高ビットレートを提供できる能力がＬＴＥにとっての主要な方策である。

【0004】

Ｅｖｏｌｖｅｄ ＵＴＲＡ（UMTS Terrestrial Radio Access）およびＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）と呼ばれるＬＴＥに関する作業項目（ＷＩ：work item）仕様がＲｅｌｅａｓｅ８（ＬＴＥ Ｒｅｌ．８）として完成されている。ＬＴＥシステムは、低遅延および低コストでフルＩＰベースの機能性を提供する効率的なパケットベースの無線アクセスおよび無線アクセスネットワークを表している。ＬＴＥでは、所与のスペクトルを用いて柔軟なシステム展開を達成するために、１．４、３．０、５．０、１０．０、１５．０および２０．０ＭＨｚなどのスケーラブルな複数の送信帯域幅が設定される。ダウンリンクでは、直交周波数分割多重（ＯＦＤＭ：Orthogonal Frequency Division Multiplexing）ベースの無線アクセスが、低シンボルレートによるマルチパス干渉（ＭＰＩ）に対するその固有の耐性、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）の使用、および異なる送信帯域幅の配置に対するその親和性のために採用された。ユーザ機器（ＵＥ：User Equipment）の制限される送信電力を考慮すると、ピークデータレートの向上よりも広域カバレージを備えることが優先されるため、アップリンクではシングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ：Single-Carrier Frequency Division Multiple Access）ベースの無線アクセスが採用された。ＬＴＥ Ｒｅｌ．８／９では、多くの主要なパケット無線アクセス技法が、ＭＩＭＯ（Multiple Input Multiple Output）チャネル送信技術を含めて利用され、高効率の制御シグナリング構造が達成される。

【0005】

＜ＬＴＥアーキテクチャ＞
全体的なＬＴＥアーキテクチャを図１に示す。Ｅ−ＵＴＲＡＮはｅＮｏｄｅＢから構成され、ユーザ機器（ＵＥ）に向けたＥ−ＵＴＲＡユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルの終端および制御プレーン（ＲＲＣ）プロトコルの終端を提供する。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）、メディアアクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）および、ユーザプレーンヘッダ圧縮および暗号化の機能を含むパケットデータ制御プロトコル（ＰＤＣＰ）レイヤをホストする。ｅＮｏｄｅＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ：Radio Resource Control）機能も提供する。ｅＮｏｄｅＢは、無線リソース管理、アドミッションコントロール、スケジューリング、ネゴシエートされたアップリンクサービス品質（ＱｏＳ：Quality of Service）の実施、セル情報ブロードキャスト、ユーザおよび制御プレーンデータの暗号化／解読、ならびにダウンリンク／アップリンクユーザプレーンパケットヘッダの圧縮／解凍を含む多くの機能を行う。ｅＮｏｄｅＢは、Ｘ２インタフェースを用いて相互接続される。

【0006】

ｅＮｏｄｅＢはまた、Ｓ１インタフェースを用いてＥＰＣ（Evolved Packet Core）に、より詳細には、Ｓ１−ＭＭＥを用いてＭＭＥ（Mobility Management Entity）に接続され、Ｓ１−Ｕを用いてサービングゲートウェイ（ＳＧＷ：Serving Gateway）に接続される。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多の関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングおよび転送する一方で、ｅＮｏｄｅＢ間でのハンドオーバ中にユーザプレーンのためのモビリティアンカとして、および、（Ｓ４インタフェースを終端し、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間のトラヒックを中継する）ＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカとして機能する。アイドル（Idle）状態のユーザ機器に対しては、ＳＧＷはダウンリンクデータを終端し、ユーザ機器に対してダウンリンクデータが到着するとページングをトリガする。ＳＧＷはユーザ機器コンテキスト、例えば、ＩＰベアラサービスのパラメータ、またはネットワーク内部ルーティング情報を管理および記憶する。ＳＧＷは、合法的傍受の場合にはユーザトラヒックの複製も行う。

【0007】

ＭＭＥは、ＬＴＥアクセスネットワークにとって主要な制御ノードである。ＭＭＥは、再送を含むアイドルモードのユーザ機器のトラッキングおよびページング手順に対する役割を担う。ＭＭＥはベアラアクティブ化／非アクティブ化プロセスに関与し、かつ初期アタッチ時およびコアネットワーク（ＣＮ：Core Network）ノード再配置を伴うＬＴＥ内ハンドオーバ時にユーザ機器に対するＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥで終端し、ＭＭＥは一時的な識別子の生成およびユーザ機器への割当ての役割も担う。ＭＭＥは、サービスプロバイダのＰＬＭＮ（Public Land Mobile Network）にキャンプするためにユーザ機器の認証を確認し、ユーザ機器のローミング制限を実施する。ＭＭＥは、ＮＡＳシグナリングに対する暗号化／整合性保護のためのネットワークにおける終端点であり、セキュリティキー管理を扱う。シグナリングの合法的傍受もＭＭＥによってサポートされる。ＭＭＥは、Ｓ３インタフェースがＳＧＳＮからＭＭＥで終端して、ＬＴＥおよび２Ｇ／３Ｇアクセスネットワーク間のモビリティのための制御プレーン機能も提供する。ＭＭＥは、ローミングユーザ機器に対してホームＨＳＳに向けたＳ６ａインタフェースも終端する。

【0008】

＜ＬＴＥにおけるコンポーネントキャリア構造＞
３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、時間−周波数領域で、いわゆるサブフレームに分割される。３ＧＰＰ ＬＴＥでは、図２に図示すように、各サブフレームは２つのダウンリンクスロットに分割され、ここでは第１のダウンリンクスロットは第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を備える。各サブフレームは時間領域で所与の数のＯＦＤＭシンボル（３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８）では１２または１４個のＯＦＤＭシンボル）から成り、ここでは各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に渡る。ＯＦＤＭシンボルは、したがって各々、それぞれのサブキャリアで送信されるいくつかの変調シンボルから成る。ＬＴＥでは、各スロットでの送信信号は、Ｎ^ＤＬ_ＲＢ×Ｎ^ＲＢ_ＳＣ個のサブキャリアとＮ^ＤＬ_ｓｙｍｂ個のＯＦＤＭシンボルのリソースグリッドによって描写される。Ｎ^ＤＬ_ＲＢは帯域幅内のリソースブロックの数である。量Ｎ^ＤＬ_ＲＢはセルに構成されるダウンリンク送信帯域幅に依存し、
Ｎ^{ｍｉｎ，ＤＬ}_ＲＢ≦Ｎ^ＤＬ_ＲＢ≦Ｎ^{ｍａｘ，ＤＬ}_ＲＢ
を満たすものとし、式中、Ｎ^{ｍｉｎ，ＤＬ}_ＲＢ＝６およびＮ^{ｍａｘ，ＤＬ}_ＲＢ＝１１０はそれぞれ、仕様の現行バージョンによってサポートされる最小および最大ダウンリンク帯域幅である。Ｎ^ＲＢ_ＳＣは１つのリソースブロック内のサブキャリアの数である。通常サイクリックプレフィックスサブフレーム構造の場合、Ｎ^ＲＢ_ＳＣ＝１２およびＮ^ＤＬ_ｓｙｍｂ＝７である。

【0009】

例えば、３ＧＰＰ ＬＴＥに使用されるような、ＯＦＤＭを利用するマルチキャリア通信システムを前提とすると、スケジューラによって割り当てられることができるリソースの最小単位は１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ：Physical Resource Block）は、時間領域では連続するＯＦＤＭシンボル（例えば７つのＯＦＤＭシンボル）、および、周波数領域では図２に例示するように連続するサブキャリア（例えばコンポーネントキャリアにとして１２個のサブキャリア）として定義される。３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８）では、物理リソースブロックはリソースエレメントから成り、時間領域では１つのスロットに、かつ周波数領域では１８０ｋＨｚに対応する（ダウンリンクリソースグリッドに関するさらなる詳細については、例えばｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ参照により本明細書に援用される非特許文献１の６．２節を参照のこと）。

【0010】

１つのサブフレームは２つのスロットから成り、その結果、いわゆる「通常（normal）」ＣＰ（サイクリックプレフィックス）が使用されるときにはサブフレームに１４個のＯＦＤＭシンボルがあり、いわゆる「拡張（extended）」ＣＰが使用されるときにはサブフレームに１２個のＯＦＤＭシンボルがある。専門用語のために、以下では、サブフレーム全体に渡る同じ連続するサブキャリアに相当する時間−周波数リソースを、「リソースブロックペア」または同意義の「ＲＢペア」もしくは「ＰＲＢペア」と呼ぶ。

【0011】

「コンポーネントキャリア」という用語は、周波数領域でのいくつかのリソースブロックの組合せを指す。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、代わりに専門用語は、ダウンリンクおよび任意選択でアップリンクリソースの組合せを指す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間の関連づけ（リンキング）は、ダウンリンクリソースで送信されるシステム情報に示される。

【0012】

コンポーネントキャリア構造に対する同様の前提が、後のリリースにも当てはまることになる。

【0013】

＜より広帯域幅のサポートのためのＬＴＥ−Ａでのキャリアアグリゲーション＞
ＩＭＴ−Ａｄｖａｎｃｅｄのための周波数スペクトルがＷＲＣ−０７（World Radio communication Conference 2007）で決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全周波数スペクトルが決定されたとは言え、実際に利用可能な周波数帯域幅は各地域または国によって異なる。しかしながら、利用可能な周波数スペクトル概要に関する決定に続いて、無線インタフェースの標準化が第３世代パートナーシッププロジェクト（３ＧＰＰ：3rd Generation Partnership Project）で始まった。３ＧＰＰ ＴＳＧ ＲＡＮ＃３９会合で、「Ｅ−ＵＴＲＡに対するさらなる向上（ＬＴＥ−Ａｄｖａｎｃｅｄ）」に関する検討項目明細が承認された。検討項目は、例えばＩＭＴ−Ａｄｖａｎｃｅｄに関する要件を満たすために、Ｅ−ＵＴＲＡの進化に対して考慮すべき技術要素を包含する。

【0014】

ＬＴＥ−Ａｄｖａｎｃｅｄシステムがサポートすることができる帯域幅が１００ＭＨｚである一方で、ＬＴＥシステムは２０ＭＨｚしかサポートすることができない。最近では、電波スペクトルの不足がワイヤレスネットワークの発展のボトルネックになっており、結果として、ＬＴＥ−Ａｄｖａｎｃｅｄシステムのために十分に広いスペクトル帯を見つけることは困難である。結果的に、より広い電波スペクトル帯を得る方途を見つけることが急務であり、ここで考え得る解答がキャリアアグリゲーション機能である。

【0015】

キャリアアグリゲーションでは、１００ＭＨｚまでのより広い送信帯域幅をサポートするために、２つ以上のコンポーネントキャリアがアグリゲートされる。ＬＴＥシステムでのいくつかのセルがアグリゲートされて、たとえＬＴＥでのこれらのセルが異なる周波数帯にあるとしても、１００ＭＨｚに対して十分に広いＬＴＥ−Ａｄｖａｎｃｅｄシステムでの１つのより広いチャネルになる。

【0016】

すべてのコンポーネントキャリアは、少なくともコンポーネントキャリアの帯域幅がＬＴＥ Ｒｅｌ．８／９セルのサポートされる帯域幅を超えない場合、ＬＴＥ Ｒｅｌ．８／９互換性があるように構成されることができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもＲｅｌ．８／９互換性があるわけではなくてもよい。現存のメカニズム（例えば禁止（ｂａｒｒｉｎｇ））を使用して、Ｒｅｌ−８／９ユーザ機器がコンポーネントキャリアにキャンプすることを回避してもよい。

【0017】

ユーザ機器は、その能力に応じて１つまたは複数のコンポーネントキャリア（複数のサービングセルに対応する）を同時に受信または送信してもよい。キャリアアグリゲーションのための受信および／または送信能力を持つＬＴＥ−Ａ Ｒｅｌ．１０ユーザ機器は、複数のサービングセルで同時に受信および／または送信することができる一方で、ＬＴＥ Ｒｅｌ．８／９ユーザ機器は、コンポーネントキャリアの構造がＲｅｌ．８／９仕様に従うとの条件で、単一のサービングセルのみで受信および送信することができる。

【0018】

キャリアアグリゲーションは連続および非連続コンポーネントキャリア両方に対してサポートされるが、各コンポーネントキャリアは（３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）のニューメロロジー（numerology）を用いて）周波数領域で最大で１１０個のリソースブロックに制限される。

【0019】

３ＧＰＰ ＬＴＥ−Ａ（Ｒｅｌｅａｓｅ１０）互換のユーザ機器を、同じｅＮｏｄｅＢ（基地局）から発信し、かつ場合によりアップリンクおよびダウンリンクで異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように構成することが可能である。構成することができるダウンリンクコンポーネントキャリアの数はＵＥのダウンリンクアグリゲーション能力に依存する。反対に、構成することができるアップリンクコンポーネントキャリアの数はＵＥのアップリンクアグリゲーション能力に依存する。移動端末をダウンリンクコンポーネントキャリアよりアップリンクコンポーネントキャリアが多くなるように構成することは、現在、可能でなくてもよい。典型的なＴＤＤ展開では、アップリンクおよびダウンリンクでのコンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は同じである。同じｅＮｏｄｅＢから発信するコンポーネントキャリアが同じカバレージを提供する必要はない。

【0020】

連続してアグリゲートされるコンポーネントキャリアの中心周波数間の間隔は３００ｋＨｚの倍数であるものとする。これは、３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）の１００ｋＨｚ周波数ラスタ（raster）と互換性があり、かつ同時に１５ｋＨｚ間隔を持つサブキャリアの直交性を保持するためである。アグリゲーションシナリオに応じて、ｎ×３００ｋＨｚ間隔は、連続したコンポーネントキャリア間への少数の未使用サブキャリアの挿入によって容易にされることができる。

【0021】

複数のキャリアのアグリゲーションの性質は、ＭＡＣレイヤまでしか明らかにされていない。アップリンクおよびダウンリンク両方に関して、各アグリゲートされるコンポーネントキャリアごとにＭＡＣで１つのＨＡＲＱエンティティが必要とされる。（アップリンクに対するＳＵ−ＭＩＭＯの不在下では）コンポーネントキャリア当たり多くとも１つのトランスポートブロックがある。トランスポートブロックおよびその潜在的なＨＡＲＱ再送信は同じコンポーネントキャリアにマッピングされる必要がある。

【0022】

キャリアアグリゲーションが構成されるとき、移動端末は、ネットワークとは１つのＲＲＣ接続しか有しない。ＲＲＣ接続確立／再確立時に、１つのセルが、ＬＴＥ Ｒｅｌ．８／９と同様に、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩおよび１つのＡＲＦＣＮ）ならびに非アクセス層モビリティ情報（例えばＴＡＩ）を提供する。ＲＲＣ接続確立／再確立後に、そのセルに対応するコンポーネントキャリアはダウンリンクプライマリセル（ＰＣｅｌｌ：Primary Cell）と称される。接続状態のユーザ機器当たり常に１つであり、１つだけのダウンリンクＰＣｅｌｌ（ＤＬ ＰＣｅｌｌ）および１つのアップリンクＰＣｅｌｌ（ＵＬ ＰＣｅｌｌ）が構成される。構成された一組のコンポーネントキャリア内で、他のセルはセカンダリセル（ＳＣｅｌｌ：Secondary Cell）と称され、ＳＣｅｌｌのキャリアはＤＬ ＳＣＣ（Downlink Secondary Component Carrier）およびＵＬ ＳＣＣ（Uplink Secondary Component Carrier）である。ＰＣｅｌｌを含めて最大５つのサービングセルが１つのＵＥに対して構成されることができる。

【0023】

＜ＭＡＣレイヤ／エンティティ、ＲＲＣレイヤ、物理レイヤ＞
ＬＴＥレイヤ２ユーザプレーン／制御プレーンプロトコルスタックは、４つのサブレイヤ（ＲＲＣ、ＰＤＣＰ、ＲＬＣおよびＭＡＣ）を備える。ＭＡＣ（Medium Access Control）レイヤはＬＴＥ無線プロトコルスタックのレイヤ２アーキテクチャにおける最下位サブレイヤであり、例えば非特許文献２によって規定される。下位の物理レイヤへの接続はトランスポートチャネルを通じてであり、上位のＲＬＣレイヤへの接続は論理チャネルを通じてである。ＭＡＣレイヤはしたがって、論理チャネルとトランスポートチャネルとの間の多重化および逆多重化を行い、送信側のＭＡＣレイヤは、論理チャネルを通じて受け取られるＭＡＣ ＳＤＵから、トランスポートブロックとして知られるＭＡＣ ＰＤＵを構築し、受信側のＭＡＣレイヤは、トランスポートチャネルを通じて受け取られるＭＡＣ ＰＤＵからＭＡＣ ＳＤＵを復元する。

【0024】

ＭＡＣレイヤは、制御データ（例えばＲＲＣシグナリング）を通知する制御論理チャネルか、またはユーザプレーンデータを通知するトラヒック論理チャネルかである論理チャネルを通じてＲＬＣレイヤにデータ転送サービス（参照により本明細書に援用される非特許文献２の５．４および５．３項を参照のこと）を提供する。他方で、ＭＡＣレイヤからのデータは、ダウンリンクまたはアップリンクと分類されるトランスポートチャネルを通じて物理レイヤと交換される。データは、それがどのように無線で送信されるかに応じてトランスポートチャネルに多重化される。

【0025】

物理レイヤはエアーインタフェースを介するデータおよび制御情報の実際の送信の役割を担う、すなわち、物理レイヤは、送信側のエアーインタフェースを通じてＭＡＣトランスポートチャネルからのすべての情報を通知する。物理レイヤによって行われる重要な機能のいくつかは、符号化および変調、リンク適合（ＡＭＣ）、電力制御、（初期同期およびハンドオーバ目的の）セルサーチ、ならびにＲＲＣレイヤに対する（ＬＴＥシステム内およびシステム間の）他の測定を含む。物理レイヤは、変調方式、符号化率（すなわち変調および符号化方式（ＭＣＳ：Modulation and Coding Scheme））、物理リソースブロックの数などといった送信パラメータに基づいて送信を行う。物理レイヤの機能に関するさらなる情報は、参照により本明細書に援用される非特許文献３に見られることができる。

【0026】

無線リソース制御（ＲＲＣ）レイヤは、無線インタフェースでのＵＥとｅＮＢとの間の通信、およびいくつかのセルを渡って移動するＵＥのモビリティを制御する。ＲＲＣプロトコルはＮＡＳ情報の転送もサポートする。ＲＲＣ＿ＩＤＬＥのＵＥに対して、ＲＲＣは、着呼のネットワークからの通知をサポートする。ＲＲＣ接続制御は、ページング、測定構成および報告、無線リソース構成、初期セキュリティアクティブ化、ならびにシグナリング無線ベアラ（ＳＲＢ：Signaling Radio Bearer）の、およびユーザデータを通知する無線ベアラ（データ無線ベアラ（ＤＲＢ：Data Radio Bearer））の確立を含む、ＲＲＣ接続の確立、修正および解除に関連したすべての手順を包含する。

【0027】

無線リンク制御（ＲＬＣ）サブレイヤは、主にＡＲＱ機能性を構成し、データセグメント化および連結をサポートする、すなわち、ＲＬＣレイヤは、ＲＬＣ ＳＤＵのフレーミングを行って、それらをＭＡＣレイヤによって示されるサイズに収める。後者の２つは、データレートから独立してプロトコルオーバーヘッドを最小化する。ＲＬＣレイヤは論理チャネルを介してＭＡＣレイヤに接続される。各論理チャネルは異なる種類のトラヒックを搬送する。ＲＬＣレイヤより上位のレイヤは典型的にＰＤＣＰレイヤであるが、いくつかの場合には、それはＲＲＣレイヤである、すなわち、論理チャネルＢＣＣＨ（Broadcast Control Channel：ブロードキャスト制御チャネル）、ＰＣＣＨ（Paging Control Channel：ページング制御チャネル）およびＣＣＣＨ（Common Control Channel：共通制御チャネル）で送信されるＲＲＣメッセージはセキュリティ保護を必要とせず、したがって、ＰＤＣＰレイヤをバイパスして直接ＲＬＣレイヤに向かう。

【0028】

＜ＬＴＥのためのアップリンクアクセス方式＞
アップリンク送信に関して、カバレージを最大化するのに電力効率的なユーザ端末送信が必要である。動的帯域幅割当てを伴うＦＤＭＡと合成されるシングルキャリア送信が進化型ＵＴＲＡアップリンク送信方式として選択されている。シングルキャリア送信の選好の主な理由は、マルチキャリア信号（ＯＦＤＭＡ）と比較して低いピーク対平均電力比（ＰＡＰＲ：Peak-to-Average Power Ratio）、ならびに対応する改善された電力増幅器効率および改善されたカバレージ（所与の端末ピーク電力に対して高いデータレート）である。各時間間隔中に、ｅＮｏｄｅＢがユーザに、ユーザデータを送信するための固有の時間／周波数リソースを割り当て、それによってセル内直交性を保証する。アップリンクでの直交アクセスは、セル内干渉を排除することによって上昇したスペクトル効率を約束する。マルチパス伝搬による干渉は、送信信号へのサイクリックプレフィックスの挿入によって補助されつつ、基地局（ｅＮｏｄｅＢ）で処理される。

【0029】

データ送信のために使用される基本的な物理リソースは、１つの時間間隔、例えばサブフレームの間のサイズＢＷｇｒａｎｔの周波数リソースから成り、その上に符号化情報ビットがマッピングされる。送信時間間隔（ＴＴＩ：Transmission Time Interval）とも称されるサブフレームがユーザデータ送信のための最小時間間隔であることに留意するべきである。しかしながら、サブフレームの連結によってユーザに１つのＴＴＩより長い時限に渡って周波数リソースＢＷｇｒａｎｔを割り当てることが可能である。

【0030】

＜レイヤ１／レイヤ２制御シグナリング＞
スケジュールされたユーザに彼らの割当て状況、トランスポートフォーマットおよび他の送信関連情報（例えばＨＡＲＱ情報、送信電力制御（ＴＰＣ：transmit power control）指令）について通知するために、Ｌ１／Ｌ２制御シグナリングがデータと共にダウンリンクで送信される。Ｌ１／Ｌ２制御シグナリングはサブフレームでダウンリンクデータと多重化され、ユーザ割当てがサブフレームごとに変化することができることを前提とする。ユーザ割当てがＴＴＩ（Transmission Time Interval：送信時間間隔）ベースで行われることもあり、ここでＴＴＩ長がサブフレームの倍数であることができることに留意するべきである。ＴＴＩ長は、すべてのユーザに対するサービス範囲で固定されてもよいし、異なるユーザに対して異なってもよいし、または各ユーザに対して動的であってさえもよい。概して、Ｌ１／Ｌ２制御シグナリングはＴＴＩ当たり一度送信されさえすればよい。一般性を失うことなく、以下はＴＴＩが１つのサブフレームに相当することを前提とする。

【0031】

Ｌ１／Ｌ２制御シグナリングは物理ダウンリンク制御チャネル（ＰＤＣＣＨ）で送信される。ＰＤＣＣＨはダウンリンク制御情報（ＤＣＩ）としてのメッセージを通知し、それはほとんどの場合、移動端末またはＵＥのグループに対するリソース割当ておよび他の制御情報を含む。いくつかのＰＤＣＣＨが１つのサブフレームで送信されることができる。

【0032】

一般に、アップリンクまたはダウンリンク無線リソース（特にＬＴＥ（−Ａ）Ｒｅｌｅａｓｅ１０）を割り当てるためのＬ１／Ｌ２制御シグナリングで送られる情報は以下の項目に分類することができる。
− ユーザ識別情報であり、割り当てられるユーザを示す。これは典型的に、ユーザ識別情報でＣＲＣをマスキングすることによって、チェックサムに含まれる。
− リソース割当て情報であり、ユーザが割り当てられるリソース（例えばリソースブロック（ＲＢ））を示す。代替的に、この情報はリソースブロック割当て（ＲＢＡ：Resource Block Assignment）と名付けられる。ユーザが割り当てられるＲＢの数が動的であることができることに留意されたい。
− キャリアインジケータであり、第１のキャリアで送信される制御チャネルが第２のキャリアに関係するリソース、すなわち第２のキャリア上のリソースまたは第２のキャリアに関連したリソースを割り当てる場合に使用される。（クロスキャリアスケジューリング）
− 利用される変調方式および符号化率を決定する変調および符号化方式
− ＨＡＲＱ情報であり、データパケットまたはその一部の再送信に特に有用である新たなデータインジケータ（ＮＤＩ：New Data Indicator）および／または冗長バージョン（ＲＶ：Redundancy Version）など
− 割り当てられるアップリンクデータまたは制御情報送信の送信電力を調節する電力制御指令
− 適用される巡回シフトおよび／または直交カバーコードインデックスなどの参照信号情報であり、割当てに関連した参照信号の送信または受信のために利用されることになる。
− 割当ての順序を識別するために使用されるアップリンクまたはダウンリンク割当てインデックスであり、ＴＤＤシステムで特に有用である。
− ホッピング情報であり、例えば周波数ダイバーシチを増強するためにリソースホッピングを適用するかどうか、およびその仕方の指標
− ＣＳＩ要求であり、割り当てられたリソースでのチャネル状態情報の送信をトリガするために使用される。
− マルチクラスタ情報であり、送信が単一のクラスタ（ＲＢの連続した集合）で発生するか、複数のクラスタ（連続したＲＢの少なくとも２つの不連続集合）で発生するかを示し、かつ制御するために使用されるフラグである。マルチクラスタ割当ては３ＧＰＰ ＬＴＥ−（Ａ）Ｒｅｌｅａｓｅ１０によって導入されている。

【0033】

上記リストが非網羅的であり、使用されるＤＣＩフォーマットに応じて、すべての言及した情報項目が各ＰＤＣＣＨ送信に存在する必要があるわけではないことに留意するべきである。

【0034】

ダウンリンク制御情報は、上述したように、全体サイズが、かつそれらのフィールドに含まれる情報も異なるいくつかのフォーマットで出現する。ＬＴＥのために現在規定されている異なるＤＣＩフォーマットは以下の通りであり、非特許文献４の５．３．３．１節に詳細に記載される（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ参照により本明細書に援用される）。参照により本明細書に援用される非特許文献４は、５．４．３項に、サイドリンクインタフェースのための制御情報を規定する。

【先行技術文献】

【非特許文献】

【0035】

【非特許文献1】3GPP TS 36.211、version 13.1.0

【非特許文献2】3GPP TS 36.321、version 13.1.0

【非特許文献3】3GPP TS 36.213、version 13.1.1

【非特許文献4】3GPP TS 36.212、version v13.1.0

【非特許文献5】3GPP TS 23.203、version 14.0.0

【非特許文献6】3GPP TR 23.713、version v13.0.0

【非特許文献7】3GPP TS 36.300、version 13.3.0

【非特許文献8】3GPP TS 23.303、version 13.4.0

【非特許文献9】3GPP TR 21.905、version 13.0.0

【非特許文献10】ETSI EN 302 637-2 v1.3.1

【非特許文献11】ETSI EN 302 637-3 v 1.2.1

【発明の概要】

【発明が解決しようとする課題】

【0036】

非限定的かつ例証的な実施形態が、車両データを送信するための、およびサービス品質要件を適切に考慮するための改善された送信装置および対応する方法を提供する。独立請求項が非限定的かつ例示的な実施形態を提供する。有利な実施形態は従属請求項に従う。

【課題を解決するための手段】

【0037】

いくつかの態様が、特にＵＥが無線リソース割当ての役割を担うときに、サイドリンクインタフェースを介する車両通信の特定のサービス品質要件をサポートする仕方に関して提供される。根底のシナリオは、送信装置（車両ＵＥなど）が他の装置にサイドリンクインタフェースを介して車両データを送信するものとするということである。車両ＵＥは、ＵＥ自律リソース割当ての他に基地局制御リソース割当てをサポートするものとする。

【0038】

対応して、第１の態様によれば、必要なサービス品質パラメータが、車両データの送信の役割を担う下位レイヤに車両データと共に送信される。サービス品質パラメータは次いで、サービス品質要件を実施しようとすると同時に車両データの送信のために使用されることになる適切な送信パラメータを得るように車両ＵＥによって行われるＵＥ自律リソース割当てに使用される。車両データは次いで、得られた送信パラメータに従って送信される。

【0039】

第２の態様によれば、異なるサービス品質構成（それぞれサービス品質パラメータを持つ）が規定され、車両ＵＥは、サービス品質構成の１つに従ってリソース割当ておよび車両データの送信を行う。特に、アプリケーションレイヤが、車両データの他にＱｏＳ構成指示を生成し、両方とも役割を担う送信レイヤに転送する。次に、送信レイヤは、対応するサービス品質構成およびサービス品質パラメータを決定し、それに基づいて、必要な送信パラメータを得るようにＵＥ自律無線リソース割当てを行う。次いで、送信レイヤは、サイドリンクインタフェースを介して車両データを送信する。

【0040】

第３の態様によれば、ＵＥ自律リソース割当てまたは基地局制御リソース割当てを行うことは、送信されることになるデータに依存してなされる。対応して、車両ＵＥは、サイドリンクインタフェースに提供される両リソース割当てモードをサポートするが、しかしながら、送信されることになるデータに応じて２つのうちの１つを行う。サービス品質が基地局制御リソース割当てによってのみサポートされることを前提とする。特に、アプリケーションレイヤは、車両データを生成し、例えば対応するサービス品質サポート指示を生成して、サービス品質が下位レイヤによってサポートされるべきか否かを示してもよい。サービス品質指示は車両ＵＥの対応する送信レイヤに車両データと共に転送されることができ、車両ＵＥは次いで、サービス品質指示によって示されるようにリソース割当てを行う。このようにして得られた送信パラメータ（サービス品質要件を考慮するまたは考慮しない）は次いで、車両データを実際に送信するために使用される。

【0041】

第４の態様によれば、サイドリンクインタフェースを介して車両ＵＥによって送信される車両データの最大スループットを示す、車両ＵＥに対する総最大ビットレートを追加的に考慮することによって、サイドリンク論理チャネル優先順位付け手順が改善される。この追加パラメータは、サイドリンクインタフェースを介して送信装置によって送信されることになる車両データのスループットを制限する。

【0042】

対応して、１つの一般的な第１の態様では、ここで開示する技術は、１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するための送信装置を特徴とする。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。送信装置のアプリケーションレイヤが、車両データを生成し、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに優先度指示および１つまたは複数のサービス品質パラメータと共に車両データを転送する。送信レイヤは、受け取った優先度指示および１つまたは複数のサービス品質パラメータに基づいて自律無線リソース割当てを行う。送信レイヤは、行った自律無線リソース割当てに従って１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信する。対応して、１つの一般的な第１の態様では、ここで開示する技術は、送信装置から１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するための方法を特徴とする。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。方法は、送信装置によって行われる以下のステップを含む。車両データは、アプリケーションレイヤで生成され、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに優先度指示および１つまたは複数のサービス品質パラメータと共に転送される。送信レイヤは、受け取った優先度指示および１つまたは複数のサービス品質パラメータに基づいて自律無線リソース割当てを行う。送信レイヤは、行った自律無線リソース割当てに従って１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信する。

【0043】

対応して、１つの一般的な第１の態様では、ここで開示する技術は、１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するための送信装置を特徴とする。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。送信装置の受信器が、無線基地局によってその無線セルでブロードキャストされるシステム情報を受信し、システム情報は１つまたは複数のサービス品質構成から成る。送信装置のアプリケーションレイヤが、車両データを生成し、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに指示と共に生成した車両データを転送する。送信レイヤは、車両データと共に受け取った指示に応じて、受け取った１つまたは複数のサービス品質構成の１つを決定する。送信レイヤは、決定した１つのサービス品質構成に基づいて自律無線リソース割当てを行う。送信レイヤは、行った自律無線リソース割当てに従って１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信する。

【0044】

対応して、１つの一般的な第１の態様では、ここで開示する技術は、送信装置から１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するための方法を特徴とする。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。方法は、送信装置によって行われる以下のステップを含む。無線基地局によってその無線セルでブロードキャストされるシステム情報が送信装置によって受信され、システム情報は１つまたは複数のサービス品質構成から成る。車両データは、アプリケーションレイヤで生成され、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに指示と共に転送される。送信レイヤは、車両データと共に受け取った指示に応じて、受け取った１つまたは複数のサービス品質構成の１つを決定し、決定した１つのサービス品質構成に基づいて自律無線リソース割当てを行う。車両データは、行われた自律無線リソース割当てに従って１つまたは複数の受信装置にサイドリンクインタフェースを介して送信される。

【0045】

対応して、１つの一般的な第１の態様では、ここで開示する技術は、１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するための送信装置を特徴とする。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。送信装置に対して総最大ビットレートが規定され、サイドリンクインタフェースを介する送信装置の最大許容総車両データスループットを示す。送信装置のアプリケーションレイヤが、車両データを生成し、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに車両データを転送する。送信レイヤは、周波数−時間無線リソースの選択を含む、車両データのための自律無線リソース割当てを行う。送信レイヤは、選択した周波数−時間無線リソースを割り当てて、車両データを通知するデータパケットを生成するためのサイドリンク論理チャネル優先順位付け手順を行い、サイドリンク論理チャネル手順は総最大ビットレートを、サイドリンクインタフェースを介して送信装置によって送信されることになる車両データのスループットに対する制限として考える。送信レイヤは、割り当てた周波数−時間無線リソースを使用して１つまたは複数の受信装置に、車両データを通知する生成したデータパケットを送信する。

【0046】

対応して、１つの一般的な第１の態様では、ここで開示する技術は、送信装置から１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するための方法を特徴とする。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。送信装置に対して総最大ビットレートが規定され、サイドリンクインタフェースを介する送信装置の最大許容総車両データスループットを示す。方法は、送信装置によって行われる以下のステップを含む。アプリケーションレイヤが車両データを生成し、それはサイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに向かう。送信レイヤは、周波数−時間無線リソースの選択を含む、車両データのための自律無線リソース割当てを行う。送信レイヤは、選択した周波数−時間無線リソースを割り当てて、車両データを通知するデータパケットを生成するためのサイドリンク論理チャネル優先順位付け手順を行い、サイドリンク論理チャネル手順は総最大ビットレートを、サイドリンクインタフェースを介して送信装置によって送信されることになる車両データのスループットに対する制限として考える。送信レイヤは、割り当てた周波数−時間無線リソースを使用して１つまたは複数の受信装置に、車両データを通知する生成したデータパケットを送信する。

【0047】

開示した実施形態の追加の利益および利点は本明細書および図から明らかだろう。利益および／または利点は、明細書および図面の開示の様々な実施形態および特徴によって個々に提供されてもよく、同利益および／または利点の１つまたは複数を得るためにすべて提供される必要があるわけではない。

【0048】

これらの一般的なおよび特定の態様はシステム、方法およびコンピュータプログラム、ならびにシステム、方法およびコンピュータプログラムの任意の組合せを使用して実装されてもよい。

【0049】

以下では、例示的な実施形態が添付の図および図面を参照しつつより詳細に記載される。

【図面の簡単な説明】

【0050】

【図1】３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示す図である。

【図2】３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）に定義されるサブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドを示す図である。

【図3】ＰｒｏＳｅ通信のためのＰＣ５上のレイヤ２リンクの確立のさせ方を概略的に示す図である。

【図4】オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムのための送信／受信リソースの使用を示す図である。

【図5】２つのＵＥに対するスケジューリング割当ておよびＤ２Ｄデータの送信を示す図である。

【図6】ＵＥ自律スケジューリングモード２のためのＤ２Ｄ通信タイミングを示す図である。

【図7】ｅＮＢスケジュールスケジューリングモード１のためのＤ２Ｄ通信タイミングを示す図である。

【図8】非ローミングシナリオについてのＰｒｏＳｅのための例示的なアーキテクチャモデルを示す図である。

【図9】車両の送信ＵＥの動作を示す、第１の実施形態のための図である。

【図10】車両の送信ＵＥの動作を示す、第２の実施形態のための図である。

【図11】車両の送信ＵＥの動作を示す、第３の実施形態のための図である。

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

【0051】

＜本開示の基礎＞
＜サービス品質＞
いかなる時にもＵＥで複数のアプリケーションが走っていてもよく、各１つがそのサービス品質の異なる要件を有する。例えば、ＵＥは、ウェブページを閲覧する、またはＦＴＰファイルをダウンロードすると同時にＶｏＩＰ（ボイスオーバーＩＰ）通話に係わることができる。ＶｏＩＰがウェブ閲覧およびＦＴＰより遅延および遅延ジッタの点でサービス品質の厳しい要件を有する一方で、後者は非常に低いパケット損失率を必要とする。複数のＱｏＳ要件をサポートするために、進化型パケットシステム内に異なるベアラが設定されて、例えばＱｏＳと関連づけられる。

【0052】

一般に、ベアラは、それらが提供するサービス品質、最低保証ビットレート（ＧＢＲ：Guaranteed Bit Rate）ベアラおよび非ＧＢＲベアラの性質に基づいて２つのカテゴリに分類することができる。ＧＢＲベアラは、ボイスオーバーＩＰなどのアプリケーションのために使用されることができ、個別送信リソースが永久に割り当てられる（例えばｅＮｏｄｅＢにおけるアドミッションコントロール機能によって）関連するＧＢＲ値を有する。リソースが利用可能であれば、ＧＢＲベアラに対してＧＢＲより高いビットレートが許容されてもよい。そのような場合、最大ビットレート（ＭＢＲ：Maximum Bit Rate）パラメータが、ＧＢＲベアラから期待することができるビットレートに上限を設定する。非ＧＢＲベアラは、いかなる特定のビットレートも保証せず、ウェブ閲覧またはＦＴＰ転送などのアプリケーションのために使用されることができる。これらのベアラに関して、帯域幅リソースはベアラに永久には割り当てられない。

【0053】

アクセスネットワークでは、無線インタフェースを通じてベアラに必要なＱｏＳを保証することはｅＮｏｄｅＢの責任である。新たなベアラが確立されるとき、ＭＭＥはｅＮｏｄｅＢにベアラ設定要求（ＥＰＳベアラ識別情報、ＥＰＳベアラＱｏＳ、セッション管理要求、Ｓ１−ＴＥＩＤ）メッセージをシグナリングし、ｅＮｏｄｅＢは次いで無線ベアラＱｏＳにＥＰＳベアラＱｏＳをマッピングする。ｅＮｏｄｅＢは次にＵＥにＲＲＣ接続再構成（無線ベアラＱｏＳ、セッション管理要求、ＥＰＳ ＲＢ識別情報）メッセージをシグナリングする。

【0054】

ＥＰＳベアラＱｏＳプロファイルはパラメータＱＣＩ（QoS Class Identifier：ＱｏＳクラス識別子）、ＡＲＰ（Allocation and Retention Priority：割当ておよび保持優先度）、ＧＢＲ（保証ビットレート）ならびにＭＢＲ（最大ビットレート）を含む。各ＥＰＳベアラ（ＧＢＲおよび非ＧＢＲ型の）は以下のベアラレベルＱｏＳパラメータと関連づけられる：
− ＱｏＳクラス識別子（ＱＣＩ）；
− 割当ておよび保持優先度（ＡＲＰ）。

【0055】

ＱＣＩは、ＬＴＥノードによって行われることになるベアラレベルパケット転送処理（例えばスケジューリング重み、アドミッション閾値、待ち行列管理閾値、リンクレイヤプロトコル構成など）を制御し、かつアクセスノード（例えばｅＮｏｄｅＢ）を所有する事業者によって予め設定されているアクセスノード特定パラメータへの参照として使用されるスカラである。標準化特性への標準化ＱＣＩ値の１対１マッピングが、非特許文献５における表６．１．７に基づく以下の表に示すように非特許文献５に表される。

【0056】

【表1】

【0057】

明らかなように、各ＱＣＩは、リソース型（ＧＢＲまたは非ＧＢＲ）、優先度（１−９；低い値ほど高い優先度を意味する）、パケット遅延バジェット（５０ｍｓから３００ｍｓに及ぶ許容パケット遅延）、パケット誤り損失率（１０^−２から１０^−６の許容パケット損失）などの標準化特性を含む。各ＱＣＩ値の性能特性を予め規定および標準化することによって、ネットワーク事業者は、いくつかのベンダーからの様々なノードから成るＬＴＥネットワークで使用される異なるサービス／アプリケーションに、必要とされる同じ最小レベルのＱｏＳが提供されることを保証することができる。

【0058】

ＱＣＩからの優先度およびパケット遅延バジェット（およびある程度、許容パケット損失率）は、ＲＬＣモード構成（すなわち透過的、未承認、了承済）を、およびＭＡＣにおけるスケジューラが（例えばスケジューリングポリシー、待ち行列管理ポリシーおよびレートシェーピングポリシーの点で）ベアラを通じて送信されるパケットをどのように扱うかを決定する。

【0059】

＜論理チャネル優先順位付け（ＬＣＰ：Logical Channel Prioritization）手順＞
アップリンクについて、ＵＥが、割り当てられた無線リソースを使用して送信されることになるＭＡＣ ＰＤＵを作成するプロセスは完全に標準化されるが、ＬＣＰ手順は、最適でかつ異なるＵＥ実装間で一貫した方途でＵＥが各構成された無線ベアラのＱｏＳを充足することを保証するように設計される。ＰＤＣＣＨでシグナリングされるアップリンク送信リソースグラントメッセージに基づいて、ＵＥは、新たなＭＡＣ ＰＤＵに含まれるべき各論理チャネルに対するデータ量を決定しなければならず、必要ならば、ＭＡＣ制御要素のためにスペースも割り当てなければならない。

【0060】

複数の論理チャネルからのデータでＭＡＣ ＰＤＵを構築する際、最も単純かつ最も直観的な方法は絶対優先度ベースの方法であり、この方法ではＭＡＣ ＰＤＵスペースは論理チャネル優先度の降順に論理チャネルに割り当てられる。つまり、最高優先度の論理チャネルからのデータがＭＡＣ ＰＤＵで最初に扱われ、次の最高優先度の論理チャネルからのデータが後続し、ＭＡＣ ＰＤＵスペースが尽きるまで続く。絶対優先度ベースの方法はＵＥ実装の点で非常に単純であるとは言え、その方法は時には低優先度の論理チャネルからのデータの枯渇につながる。枯渇は、高優先度の論理チャネルからのデータがすべてのＭＡＣ ＰＤＵスペースを占めるために低優先度の論理チャネルからのデータが送信されることができないことを意味する。

【0061】

ＬＴＥでは、重要性の順にデータを送信するが、しかしより低い優先度を持つデータの枯渇を回避もするために、優先ビットレート（ＰＢＲ：Prioritized Bit Rate）が各論理チャネルに対して規定される。ＰＢＲは、論理チャネルに対して保証される最小データレートである。たとえ論理チャネルが低優先度を有するとしても、ＰＢＲを保証するために、少なくとも小量のＭＡＣ ＰＤＵスペースが割り当てられる。したがって、ＰＢＲを使用することによって、枯渇の問題は回避されることができる。

【0062】

論理チャネル優先順位付けは、例えば参照によって本明細書に援用される非特許文献２の５．４．３．１項に標準化される。論理チャネル優先順位付け（ＬＣＰ：Logical Channel Prioritization）手順は、新たな送信が行われるときに適用される。

【0063】

＜ＬＴＥデバイスツーデバイス（Ｄ２Ｄ：Device to Device）近接サービス（ＰｒｏＳｅ：Proximity Services）＞
近接ベースのアプリケーションおよびサービスが、新興の社会的技術的傾向を表している。特定される領域は、事業者およびユーザにとって関心があろう商用サービスおよび公衆安全（Public Safety）に関連したサービスを含む。ＬＴＥへの近接サービス（ＰｒｏＳｅ）能力の導入は、３ＧＰＰ業界がこの発展市場に応対するのを許容し、同時に、ＬＴＥに共同で関与するいくつかの公衆安全地域の急務を満たすであろう。

【0064】

デバイスツーデバイス（Ｄ２Ｄ：Device to Device）通信は、セルラネットワークに対するアンダーレイとしてのＤ２Ｄがスペクトル効率を上昇させるのを許容するＬＴＥ−Ｒｅｌ．１２により導入される技術要素である。例えば、セルラネットワークがＬＴＥであれば、すべてのデータ通知用物理チャネルはＤ２ＤシグナリングのためにＳＣ−ＦＤＭＡを使用する。Ｄ２Ｄ通信では、ユーザ機器は、無線基地局を通しての代わりにセルラリソースを使用する直接リンクを通じて互いにデータ信号を送信する。本開示を通して、「Ｄ２Ｄ」、「ＰｒｏＳｅ」および「サイドリンク」という用語は交換可能である。

【0065】

ＬＴＥでのＤ２Ｄ通信は２つの領域：発見および通信に重点を置いている。

【0066】

ＰｒｏＳｅ（近接ベースのサービス）直接発見（Direct Discovery）が、ＰｒｏＳｅ対応ＵＥによって、ＰＣ５インタフェースを介してＥ−ＵＴＲＡ直接無線信号を使用してその近接の他のＰｒｏＳｅ対応ＵＥを発見するために使用される手順として規定される。

【0067】

Ｄ２Ｄ通信では、ＵＥは、基地局（ＢＳ：Base Station）を通しての代わりにセルラリソースを使用する直接リンクを通じて互いにデータ信号を送信する。Ｄ２Ｄユーザは、ＢＳ下で制御されたまま、すなわち少なくともｅＮＢのカバレージにいるときに直接通信する。したがって、Ｄ２Ｄは、セルラリソースを再使用することによってシステム性能を向上させることができる。

【0068】

Ｄ２Ｄは、（ＦＤＤの場合）アップリンクＬＴＥスペクトル、または、（カバレージ外の場合を除き、ＴＤＤの場合）カバレージを与えるセルのアップリンクサブフレームで動作することを前提とする。さらには、Ｄ２Ｄ送信／受信は所与のキャリアで全二重を使用しない。個々のＵＥの観点から、所与のキャリアで、Ｄ２Ｄ信号受信およびＬＴＥアップリンク送信は全二重を使用しない、すなわちＤ２Ｄ信号受信およびＬＴＥ ＵＬ送信の同時は不可能である。

【0069】

Ｄ２Ｄ通信では、１つの特定のＵＥ１が送信の役割を有するとき（送信ユーザ機器または送信端末）、ＵＥ１はデータを送信し、別のＵＥ２（受信ユーザ機器）がそのデータを受信する。ＵＥ１およびＵＥ２はそれらの送信および受信役割を交換することができる。ＵＥ１からの送信は、ＵＥ２のような１つまたは複数のＵＥによって受信されることができる。

【0070】

＜ＰｒｏＳｅ直接通信レイヤ２リンク＞
要するに、２つのＵＥ間にＰＣ５上の安全なレイヤ２リンクを確立することによって、ＰｒｏＳｅ直接１対１通信が実現される。各ＵＥは、それがレイヤ２リンクで送信するあらゆるフレームのソースレイヤ２ＩＤフィールドに、およびそれがレイヤ２リンクで受信するあらゆるフレームの宛先レイヤ２ＩＤに含まれるユニキャスト通信のためのレイヤ２ＩＤを有する。ＵＥは、ユニキャスト通信のためのレイヤ２ＩＤが少なくともローカルで一意であることを保証する必要がある。そこで、ＵＥは、不特定のメカニズムを使用して隣接するＵＥとのレイヤ２ＩＤ競合を取り扱う（例えば、競合が検出されると、ユニキャスト通信のための新たなレイヤ２ＩＤを自己割り当てする）備えができているべきである。ＰｒｏＳｅ１対１直接通信のためのレイヤ２リンクは、２つのＵＥのレイヤ２ＩＤの組合せによって識別される。これは、ＵＥが、同じレイヤ２ＩＤを使用してＰｒｏＳｅ１対１直接通信のための複数のレイヤ２リンクに係わることができることを意味する。

【0071】

ＰｒｏＳｅ１対１直接通信は、参照により本明細書に援用される非特許文献６の７．１．２節に詳細に説明される以下の手順で構成される。
− ＰＣ５上の安全なレイヤ２リンクの確立。
− ＩＰアドレス／プレフィックス割当て。
− ＰＣ５上のレイヤ２リンク維持。
− ＰＣ５上のレイヤ２リンク解除。

【0072】

図３は、ＰＣ５インタフェース上の安全なレイヤ２リンクの確立のさせ方を例示する。
１. ＵＥ−１が、相互認証をトリガするためにＵＥ−２に直接通信要求（Direct Communication Request）メッセージを送信する。リンクイニシエータ（ＵＥ−１）は、ステップ１を実行するためにピア（ＵＥ−２）のレイヤ２ＩＤを知る必要がある。例として、リンクイニシエータは、最初に発見手順を実行することによって、またはピアを含むＰｒｏＳｅ一対多通信に関与したことによってピアのレイヤ２ＩＤを学習してもよい。
２. ＵＥ−２が、相互認証のための手順を開始する。認証手順の完了成功が、ＰＣ５上の安全なレイヤ２リンクの確立を完了する。

【0073】

絶縁（非リレー）１対１通信に係わるＵＥはリンクローカルアドレスも使用してもよい。ＰＣ５シグナリングプロトコル（Signaling Protocol）は、ＵＥがＰｒｏＳｅ通信距離にない時を検出するために使用されるキープアライブ機能をサポートするものとし、その結果ＵＥは非明示的なレイヤ２リンク解除に移ることができる。ＰＣ５上のレイヤ２リンク解除は、他方のＵＥに送信される切断要求（Disconnect Request）メッセージを使用することによって行われることができ、これはすべての関連するコンテキストデータも削除する。切断要求メッセージの受信に応じて、他方のＵＥは、切断応答（Disconnect Response）メッセージで応答し、レイヤ２リンクと関連づけられるすべてのコンテキストデータを削除する。

【0074】

＜ＰｒｏＳｅ直接通信関連識別情報＞
非特許文献７の現行バージョン１３．３．０が、ＰｒｏＳｅ直接通信のために使用する以下の識別情報を８．３項に規定する：
− ＳＬ−ＲＮＴＩ：ＰｒｏＳｅ直接通信スケジューリングのために使用される固有の識別；
− ソースレイヤ２ＩＤ：サイドリンクＰｒｏＳｅ直接通信でデータの送信側を識別する。ソースレイヤ２ＩＤは長さ２４ビットであり、受信側でのＲＬＣ ＵＭエンティティおよびＰＤＣＰエンティティの識別のためのＰｒｏＳｅレイヤ２宛先ＩＤおよびＬＣＩＤと共に使用される；
− 宛先レイヤ２ＩＤ：サイドリンクＰｒｏＳｅ直接通信でデータのターゲットを識別する。宛先レイヤ２ＩＤは長さ２４ビットであり、ＭＡＣレイヤで２つのビット列に分割される：
−− １つのビット列は宛先レイヤ２ＩＤのＬＳＢ部（８ビット）であり、サイドリンク制御レイヤ１ＩＤとして物理レイヤに転送される。これはサイドリンク制御の意図されたデータのターゲットを識別し、物理レイヤでパケットフィルタリングのために使用される。
−− 第２のビット列は宛先レイヤ２ＩＤのＭＳＢ部（１６ビット）であり、ＭＡＣヘッダ内で通知される。これはＭＡＣレイヤでパケットフィルタリングのために使用される。

【0075】

アクセス層シグナリングは、グループ形成のために、ならびにＵＥでソースレイヤ２ＩＤ、宛先レイヤ２ＩＤおよびサイドリンク制御Ｌ１ＩＤを設定するために必要とされない。これらの識別情報は上位レイヤによって提供されるか、または上位レイヤによって提供される識別情報から導出されるかいずれかである。グループキャストおよびブロードキャストの場合には、上位レイヤによって提供されるＰｒｏＳｅ ＵＥ ＩＤはソースレイヤ２ＩＤとして直接使用され、上位レイヤによって提供されるＰｒｏＳｅレイヤ２グループＩＤはＭＡＣレイヤで宛先レイヤ２ＩＤとして直接使用される。１対１通信の場合には、上位レイヤがソースレイヤ２ＩＤおよび宛先レイヤ２ＩＤを提供する。

【0076】

＜近接サービスのための無線リソース割当て＞
送信ＵＥの観点から、近接サービス対応ＵＥ（ＰｒｏＳｅ対応ＵＥ）は、リソース割当てのための２つのモードで動作することができる。

【0077】

モード１はｅＮＢスケジュールリソース割当てモードを指し、ここでＵＥがｅＮＢ（またはリリース１０中継ノード）に送信リソースを要求し、ｅＮｏｄｅＢ（またはリリース１０中継ノード）は次いで直接データおよび直接制御情報を送信するためにＵＥによって使用されるリソースをスケジュールする（例えばスケジューリング割当て）。ＵＥは、データを送信するためにＲＲＣ＿ＣＯＮＮＥＣＴＥＤである必要がある。特に、ＵＥはｅＮＢにスケジューリング要求（Ｄ−ＳＲまたはランダムアクセス）を送信し、通例のようにサイドリンクバッファ状況報告（ＢＳＲ：Buffer Status Report）が後続する（以下の章「Ｄ２Ｄ通信のための送信手順」も参照のこと）。ＢＳＲに基づいて、ｅＮＢは、ＵＥがＰｒｏＳｅ直接通信送信のためのデータを有すると判定することができ、送信のために必要とされるリソースを推定することができる。

【0078】

他方では、モード２はＵＥ自律リソース選択モードを指し、ここでＵＥが、直接データおよび直接制御情報を送信するためにリソースプールからリソース（時間および周波数）を単独で選択する（すなわちＳＡ）。少なくとも１つのリソースプールが、例えばＳＩＢ１８の内容によって、すなわちフィールドｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎによって規定され、これらの特定の１つまたは複数のリソースプールはセルでブロードキャストされ、次いでなおＲＲＣ＿Ｉｄｌｅ状態のセルにおけるすべてのＵＥに共通に利用可能である。実際上、ｅＮＢは、上記プールの４つまでの異なるインスタンス、それぞれＳＡメッセージおよび直接データの送信のための４つのリソースプールを規定してもよい。しかしながら、たとえ複数のリソースプールを設定されたとしても、Ｒｅｌ−１２においてＵＥは列記に規定される第１のリソースプールを常に使用するものとする。この制約はＲｅｌ−１３に関しては取り払われた、すなわちＵＥは一ＳＣ周期内で構成されたリソースプールのうちの複数で送信することができる。ＵＥが送信のためのリソースプールをどのように選択するかは以下にさらに概説される（非特許文献２にさらに明記される）。

【0079】

代替策として、別のリソースプールがｅＮＢによって規定され、ＳＩＢ１８で、すなわちフィールドｃｏｍｍＴｘＰｏｏｌＥｘｃｅｐｔｉｏｎａｌを使用することによってシグナリングされることができ、そのリソースプールは例外的な場合にＵＥによって使用されることができる。

【0080】

ＵＥがどのリソース割当てモードを使用する予定かは、ｅＮＢによって設定可能である。さらには、ＵＥがＤ２Ｄデータ通信のためにどのリソース割当てモードを使用する予定かは、また、ＲＲＣ状態、すなわちＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ、およびＵＥのカバレージ状態、すなわちカバレージ内、カバレージ外に依存してもよい。ＵＥは、それがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤであるかまたはＲＲＣ＿ＩＤＬＥのセルにキャンプしている）とすれば、カバレージ内と考えられる。

【0081】

図４は、オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムのための送信／受信リソースの使用を例示する。

【0082】

基本的に、ｅＮｏｄｅＢは、ＵＥがモード１またはモード２送信を適用してもよいかどうかを制御する。一旦ＵＥが、それがＤ２Ｄ通信を送信（または受信）することができるそのリソースを知ると、ＵＥは対応する送信／受信のための対応するリソースのみを使用する。例えば、図４で、Ｄ２Ｄサブフレームは、Ｄ２Ｄ信号を受信または送信するためにのみ使用されることになる。Ｄ２ＤデバイスとしてのＵＥは半二重モードで動作するであろうから、ＵＥは任意の時点でＤ２Ｄ信号を受信かまたは送信かいずれかすることができる。同様に、図４に例示するその他のサブフレームは、ＬＴＥ（オーバーレイ）送信および／または受信のために使用することができる。

【0083】

＜Ｄ２Ｄ通信のための送信手順＞
Ｒｅｌ．１２／１３によるＤ２Ｄデータ送信手順は、リソース割当てモードに応じて異なる。モード１について上記したように、ｅＮＢは、ＵＥからの対応する要求後、スケジューリング割当ておよびＤ２Ｄデータ通信のためのリソースを明示的にスケジュールする。特に、ＵＥは、Ｄ２Ｄ通信が通常許容されるが、しかしモード２リソース（すなわちリソースプール）は提供されないことをｅＮＢによって通知されてもよく；これは、例えばＵＥによるＤ２Ｄ通信関心インジケーションおよび対応する応答（Ｄ２Ｄ通信応答）の交換で行われてもよく、ここで、対応する例示的なＰｒｏｓｅＣｏｍｍＣｏｎｆｉｇ情報要素はｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎを含まないであろうから、送信を伴う直接通信を開始したいＵＥがＥ−ＵＴＲＡＮに各個々の送信のためのリソースを割り当てるように要求しなければならないことを意味する。したがって、そのような場合に、ＵＥは各個々の送信のためのリソースを要求しなければならず、以下に要求／グラント手順の異なるステップがこのモード１リソース割当てに関して例示的に列記される：
− ステップ１：ＵＥがＰＵＣＣＨを介してｅＮＢにＳＲ（スケジューリング要求）を送信する；
− ステップ２：ｅＮＢがＰＤＣＣＨを介して（ＵＥがサイドリンクＢＳＲを送信するための）ＵＬリソースを、Ｃ−ＲＮＴＩによってスクランブルして許可する；
− ステップ３：ＵＥがＰＵＳＣＨを介してバッファ状況を示すＤ２Ｄ／サイドリンクＢＳＲを送信する；
− ステップ４：ｅＮＢがＰＤＣＣＨを介して（ＵＥがデータを送信するための）Ｄ２Ｄリソースを、Ｄ２Ｄ−ＲＮＴＩによってスクランブルして許可する。
− ステップ５：Ｄ２Ｄ Ｔｘ ＵＥがステップ４で受信したグラントに従ってＳＡ／Ｄ２Ｄデータを送信する。

【0084】

ＳＣＩ（Sidelink Control Information：サイドリンク制御情報）とも名付けられるスケジューリング割当て（ＳＡ：Scheduling Assignment）は、制御情報、例えば対応するＤ２Ｄデータ送信のための時間／周波数リソースへのポインタ、変調および符号体系ならびにグループ宛先ＩＤ（Group Destination ID）を含むコンパクトな（低ペイロード）メッセージである。ＳＣＩは、１つの（ＰｒｏＳｅ）宛先ＩＤに対するサイドリンクスケジューリング情報を搬送する。ＳＡ（ＳＣＩ）の内容は基本的に、上記ステップ４で受信したグラントに従う。Ｄ２ＤグラントおよびＳＡ内容（すなわちＳＣＩ内容）は、参照により本明細書に援用される非特許文献４の５．４．３項に規定され、特にＳＣＩ ｆｏｒｍａｔ０を規定する（上記ＳＣＩ ｆｏｒｍａｔ０の内容を参照のこと）。

【0085】

他方では、モード２リソース割当てに関して、上記ステップ１〜４は基本的に必要でなく、ＵＥは、ｅＮＢによって設定および提供される送信リソースプールからＳＡおよびＤ２Ｄデータ送信のための無線リソースを自律的に選択する。

【0086】

図５は、２つのＵＥ（ＵＥ−１およびＵＥ−２）に対するスケジューリング割当ておよびＤ２Ｄデータの送信を例示的に示し、ここでスケジューリング割当てを送信するためのリソースは周期的であり、Ｄ２Ｄデータ送信のために使用されるリソースは対応するスケジューリング割当てによって示される。

【0087】

図６は、ＳＣ周期（Sidelink Control period：サイドリンク制御周期）としても知られる一ＳＡ／データ周期間のモード２（自律スケジューリング）のＤ２Ｄ通信タイミングの１つの具体例を示す。図７は、一ＳＡ／データ周期間のモード１（ｅＮＢスケジュール割当て）のＤ２Ｄ通信タイミングを示す。Ｒｅｌ．１３で、３ＧＰＰはＳＣ周期を、スケジューリング割当ておよびその対応するデータの送信から成る時限であるとして定義した。図６から分かるように、ＵＥはＳＡオフセット時間後に、モード２のスケジューリング割当てのための送信プールリソース（ＳＡ＿Ｍｏｄｅ２＿Ｔｘ＿ｐｏｏｌ）を使用してスケジューリング割当てを送信する。ＳＡの１回目の送信に、例えば同じＳＡメッセージの３回の再送信が後続する。次いで、ＵＥは、（ＳＡ＿ｏｆｆｓｅｔによって与えられる）ＳＡリソースプールの第１のサブフレーム後いくらかの設定したオフセット（Ｍｏｄｅ２ｄａｔａ＿ｏｆｆｓｅｔ）で、Ｄ２Ｄデータ送信、すなわちより詳しくはＴ−ＲＰＴビットマップ／パターンを開始する。ＭＡＣ ＰＤＵ（すなわちトランスポートブロック）の１つのＤ２Ｄデータ送信はその１回目の初期送信および数回の再送信から成る。図６の（および図７の）例について、３回の再送信が行われること（すなわち同じＭＡＣ ＰＤＵの２回目、３回目および４回目の送信）を前提とする。Ｍｏｄｅ２ Ｔ−ＲＰＴビットマップ（送信の時間リソースパターン（Ｔ−ＲＰＴ））は基本的に、ＭＡＣ ＰＤＵ送信（１回目の送信）ならびにその再送信（２回目、３回目および４回目の送信）のタイミングを規定する。ＳＡパターンは基本的に、ＳＡの初期送信ならびにその再送信（２回目、３回目および４回目の送信）のタイミングを規定する。

【0088】

現在規格に明記されているように、例えばｅＮＢによって送信されるか、またはＵＥ自体によって選択されるかいずれかの１つのサイドリンクグラントに対して、ＵＥは、１つのＰｒｏＳｅ宛先グループだけであるが複数のトランスポートブロック（ＭＡＣ ＰＤＵ）を（サブフレーム（ＴＴＩ）当たり１つだけ、すなわち次々と）送信することができる。また、１つのトランスポートブロックの再送信は、次のトランスポートブロックの１回目の送信が開始する前に終了されなければならない、すなわち複数のトランスポートブロックの送信のためにサイドリンクグラント当たり１つのＨＡＲＱプロセスしか使用されない。さらには、ＵＥはＳＣ周期当たりいくつかのサイドリンクグラントを有して使用することができるが、それらの各々に対して異なるＰｒｏＳｅ宛先が選択される。したがって、一ＳＣ周期で、ＵＥは１つのＰｒｏＳｅ宛先に１度しかデータを送信することができない。

【0089】

図７から明らかなように、ｅＮＢスケジュールリソース割当てモード（モード１）に関して、Ｄ２Ｄデータ送信、すなわちより詳しくはＴ−ＲＰＴパターン／ビットマップは、ＳＡリソースプールでの最後のＳＡ送信繰返し後、次のＵＬサブフレームで開始する。図６に関して既に説明したように、Ｍｏｄｅ１ Ｔ−ＲＰＴビットマップ（送信の時間リソースパターン（Ｔ−ＲＰＴ））は基本的に、ＭＡＣ ＰＤＵ送信（１回目の送信）ならびにその再送信（２回目、３回目および４回目の送信）のタイミングを規定する。

【0090】

サイドリンクデータ送信手順は、参照により本明細書に援用される非特許文献２の５．１４節に見られることができる。同文献では、モード２自律リソース選択が詳細に記載され、単一の無線リソースプールまたは複数の無線リソースプールが設定されることを区別している。

【0091】

上記がＤ２Ｄ通信についての３ＧＰＰ規格の現状である。しかしながら、Ｄ２Ｄ通信をさらに改善および強化する仕方に関する検討が継続中であり、おそらく将来のリリースでＤ２Ｄ通信に多少の変更が導入されるという結果になることに留意するべきである。本開示は、後述するように、それらの後のリリースにも適用可能であるものとする。

【0092】

例えば、現在作成中である３ＧＰＰ Ｒｅｌ．１４に関して、３ＧＰＰは、もはや上記したＳＣ周期に基づくのではなく、異なる（例えばＵｕインタフェース送信と同じ／同様のサブフレームに基づく）ように送信タイミングを変えることに決定する可能性がある。対応して、サイドリンク（ＰＣ５）インタフェース上の送信がどのように行われることができるかに関する上記の詳細な例は単に例示的であり、Ｒｅｌ．１３に当てはまっても、場合により対応する３ＧＰＰ規格の後のリリースには当てはまらないかもしれない。

【0093】

＜ＰｒｏＳｅネットワークアーキテクチャおよびＰｒｏＳｅエンティティ＞
図８は、それぞれのＵＥ ＡおよびＢにおける異なるＰｒｏＳｅアプリケーションの他に、ネットワークにおけるＰｒｏＳｅアプリケーションサーバおよびＰｒｏＳｅ機能を含む、非ローミングケースについての高レベルの例示的なアーキテクチャを例示する。図８のアーキテクチャ例は、参照により本明細書に援用される非特許文献８のバージョン１３．２．０の４．２章「Architectural Reference Model」から取られている。

【0094】

機能エンティティは、参照により本明細書に援用される、上記引用した非特許文献８の４．４項「Functional Entities」に詳細に提示および説明されている。ＰｒｏＳｅ機能は、ＰｒｏＳｅのために必要とされるネットワーク関連行動のために使用される論理機能であり、ＰｒｏＳｅの特徴の各々のための異なる役割を果たす。ＰｒｏＳｅ機能は３ＧＰＰのＥＰＣの一部であり、近接サービスに関連した、許可、認証、データ操作などのようなすべての関連するネットワークサービスを提供する。ＰｒｏＳｅ直接発見および通信に関して、ＵＥは、ＰＣ３基準点を通じてＰｒｏＳｅ機能から、特定のＰｒｏＳｅ ＵＥ識別情報、他の構成情報の他に許可を得てもよい。ネットワークには複数のＰｒｏＳｅ機能を展開することができるが、例解の容易さのために、単一のＰｒｏＳｅ機能を提示する。ＰｒｏＳｅ機能は、ＰｒｏＳｅ特徴に応じて異なる役割を行う３つの主な副機能：直接供給機能（ＤＰＦ：Direct Provision Function）、直接発見名管理機能およびＥＰＣレベル発見機能から成る。ＤＰＦは、ＰｒｏＳｅ直接発見およびＰｒｏＳｅ直接通信を使用するために、ＵＥに必要なパラメータを供給するために使用される。

【0095】

上記関連で使用される用語「ＵＥ」は、以下などのＰｒｏＳｅ機能性をサポートするＰｒｏＳｅ対応ＵＥを指す：
− ＰＣ３基準点を通じたＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間のＰｒｏＳｅ制御情報の交換。
− ＰＣ５基準点を通じた他のＰｒｏＳｅ対応ＵＥの公開ＰｒｏＳｅ直接発見のための手順。
− ＰＣ５基準点を通じた１対多ＰｒｏＳｅ直接通信のための手順。
− ＰｒｏＳｅ ＵＥ−ネットワークリレー（UE-to-Network Relay）として作用する手順。リモートＵＥはＰＣ５基準点を通じてＰｒｏＳｅ ＵＥ−ネットワークリレーと通信する。ＰｒｏＳｅ ＵＥ−ネットワークリレーはレイヤ３パケット転送を使用する。
− 例えばＵＥ−ネットワークリレー検出およびＰｒｏＳｅ直接発見のための、ＰＣ５基準点を通じたＰｒｏＳｅ ＵＥ間の制御情報の交換。
− ＰＣ３基準点を通じた別のＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間のＰｒｏＳｅ制御情報の交換。ＰｒｏＳｅ ＵＥ−ネットワークリレーの場合には、リモートＵＥはＰＣ５ユーザプレーンを通じてこの制御情報を送信し、ＰｒｏＳｅ機能に向けてＬＴＥ−Ｕｕインタフェースを通じて中継されることになる。
− パラメータ（例えばＩＰアドレス、ＰｒｏＳｅレイヤ２グループＩＤ、グループセキュリティ事柄、無線リソースパラメータを含む）の設定。これらのパラメータは、ＵＥに予め設定されるか、またはカバレージ内であれば、ネットワークにおけるＰｒｏＳｅ機能にＰＣ３基準点を通じてシグナリングによって供給されることができる。

【0096】

ＰｒｏＳｅアプリケーションサーバは、ＥＰＣ ＰｒｏＳｅユーザＩＤおよびＰｒｏＳｅ機能ＩＤの記憶、ならびにアプリケーションレイヤユーザＩＤおよびＥＰＣ ＰｒｏＳｅユーザＩＤのマッピングをサポートする。ＰｒｏＳｅアプリケーションサーバ（ＡＳ：Application Server）は３ＧＰＰの範囲外のエンティティである。ＵＥにおけるＰｒｏＳｅアプリケーションは、アプリケーションレイヤ基準点ＰＣ１を介してＰｒｏＳｅ ＡＳと通信する。ＰｒｏＳｅ ＡＳはＰＣ２基準点を介して３ＧＰＰネットワークに接続される。

【0097】

＜Ｄ２Ｄ（サイドリンク）論理チャネルのためのＬＣＰ手順＞
Ｒｅｌ．１３によるＤ２ＤのためのＬＣＰ手順は、Ｕｕインタフェースで送信される「通常の」アップリンクＬＴＥデータのための以上提示したＬＣＰ手順とは異なることになる。以下の情報は、非特許文献２の、ＰｒｏＳｅのためのＬＣＰ手順を記載する５．１４．１．３．１項から取られており、それは参照によりその全体が本明細書に援用される。

【0098】

論理チャネル優先順位付け手順は新たな送信が行われるときに適用される。各サイドリンク論理チャネルは、ＰＰＰＰ（ProSe Per Packet Priority：ＰｒｏＳｅパケット毎優先度、後に説明する）であることができる、関連する優先度を有する。複数のサイドリンク論理チャネルが同じ関連する優先度を有してもよい。優先度とＬＣＩＤとの間のマッピングはＵＥ実装次第である。

【0099】

ＭＡＣエンティティは、ＳＣ周期に送信される各ＳＣＩに対して以下の論理チャネル優先順位付け手順を行うものとする：
− ＭＡＣエンティティは、以下のステップでサイドリンク論理チャネルにリソースを割り当てるものとする：
−− ステップ０：送信のために利用可能なデータを有するサイドリンク論理チャネルの中で最高優先度を持つサイドリンク論理チャネルを有する、このＳＣ周期に対して既に選択されていないＰｒｏＳｅ宛先を選択する。
−− ステップ１：選択したＰｒｏＳｅ宛先に帰属し、かつ送信のために利用可能なデータを有するサイドリンク論理チャネルの中で、最高優先度を持つサイドリンク論理チャネルにリソースを割り当てる。
−− ステップ２：いずれかのリソースが残れば、どちらが先にせよサイドリンク論理チャネルのためのデータかまたはＳＬグラントかいずれかが尽きるまで、選択したＰｒｏＳｅ宛先に帰属するサイドリンク論理チャネルが優先度の降順に扱われる。等しい優先度が設定されるサイドリンク論理チャネルは等しく扱われるべきである。
− ＵＥは、以上のスケジューリング手順の間、以下の規則にも従うものとする：
ＵＥは、以下の規則に従ってサイドリンク論理チャネルにリソースを割り当てるものとする：
− ＵＥは、全体のＳＤＵ（または部分的に送信されるＳＤＵ）が残りのリソースに収まれば、ＲＬＣ ＳＤＵ（または部分的に送信されるＳＤＵ）をセグメント化するべきでない。
− ＵＥがサイドリンク論理チャネルからのＲＬＣ ＳＤＵをセグメント化する場合、ＵＥは、可能な限りグラントを満たすようにセグメントのサイズを最大化するものとする。
− ＵＥはデータの送信を最大化するべきである。
− ＭＡＣエンティティが、送信のために利用可能なデータを有しつつ、１０バイト以上であるサイドリンクグラントサイズを与えられれば、ＭＡＣエンティティは、パディングのみを送信することはしないものとする。
注：以上の規則は、サイドリンク論理チャネルが扱われる順序がＵＥ実装次第であることを暗示する。

【0100】

概して、１つのＭＡＣ ＰＤＵのために、ＭＡＣは同じソースレイヤ２ＩＤ−宛先レイヤ２ＩＤ対を持つ論理チャネルのみを考えるものとし、すなわち１つのＭＡＣ ＰＤＵのために、ＵＥにおけるＭＡＣエンティティは同じＰｒｏＳｅ宛先グループの論理チャネルのみを考えるものとし、これは基本的に、ＵＥがＬＣＰ手順の間にＰｒｏＳｅ宛先を選択することを意味する。Ｒｅｌ−１３では、ＳＣ周期内に２つ以上のサイドリンクグラントを有することが許容される。各サイドリンクグラントに対して、ＵＥは、Ｒｅｌ−１２でのように、１つのＰｒｏＳｅ宛先グループのデータしか送信することができない。しかしながら、ＵＥが１つのＳＣ周期内に２つ以上の有効なサイドリンクグラントを有するように構成されることができるので、送信ＵＥは異なるＰｒｏＳｅ宛先にデータを送信することができる、すなわち各ＳＬグラントは異なるＰｒｏＳｅ宛先にデータを送信しなければならない。

【0101】

＜ＰｒｏＳｅのためのＱｏＳサポート＞
Ｒｅｌ−１３では、概してＰｒｏＳｅ一対多通信のためにＱｏＳがサポートされる。その理由で、例えば非特許文献８の５．４．６節で、いわゆるＰｒｏＳｅパケット毎優先度（ＰＰＰＰ）が導入された。ＰｒｏＳｅパケット毎優先度は、プロトコルデータユニット、例えばＩＰパケットと関連づけられ、そのプロトコルデータユニットの送信に適用されることになる優先度処理、すなわちＰＣ５インタフェース上の送信のための優先度処理を規定するスカラ値である。言い換えると、ＰｒｏＳｅ ＰＰＰは、ＰｒｏＳｅ ＵＥ−ＵＥのため、およびＰｒｏＳｅリレーのためも含むＰｒｏＳｅ直接通信を使用するときにパケットの優先順位付けを許容するために使用されるメカニズムである。

【0102】

ＰｒｏＳｅ上位レイヤ（すなわちＰＣ５アクセス層より上位）がＰＣ５アクセス層に送信のためのプロトコルデータユニットを渡すとき、ＰｒｏＳｅ上位レイヤは８つの可能な値の範囲からＰｒｏＳｅパケット毎優先度を提供する。

【0103】

ＰｒｏＳｅパケット毎優先度は宛先レイヤ２ＩＤから独立しており、１対１および１対多の両方のＰｒｏＳｅ直接通信に適用される。ＰｒｏＳｅパケット毎優先度は、例えば本明細書の範囲外である様々な判定基準（音声パケット送信のようなサービスまたはフロア制御関連シグナリングのような制御シグナリングの遅延要件など）に基づいて、アプリケーションレイヤによって選択される。

【0104】

ＰｒｏＳｅパケット毎優先度は、ＵＥがメディアにアクセスするモード、すなわちＰｒｏＳｅ通信のために使用されるリソース割当てモードがｅＮＢスケジュールかまたはＵＥ自律か、から独立している。アプリケーションレイヤは、ＰｒｏＳｅ−ＵＥの下位レイヤによってどちらの割当てモードが使用されているかを知らない。ＰｒｏＳｅアクセス層は、上位のレイヤから受け取られるプロトコルデータユニットと関連づけられたＰｒｏＳｅパケット毎優先度を使用して、他のＵＥ内送信（すなわち同じＵＥ内部で送信を待っている、異なる優先度と関連づけられたプロトコルデータユニット）およびＵＥ間送信（すなわち異なるＵＥ内部で送信を待っている、異なる優先度と関連づけられたプロトコルデータユニット）に関して送信に優先順位を付ける。

【0105】

優先順位付き待ち行列（ＵＥ内およびＵＥ間の両方）は厳密な優先度順に扱われるものとされる、すなわちＵＥまたはｅＮＢは、ＰｒｏＳｅパケット毎優先度Ｎと関連づけられたすべてのパケットを扱ってから優先度Ｎ＋１と関連づけられたパケットを扱う（低い数ほど高い優先度を意味する）。

【0106】

ＰＣ５インタフェース自体への優先度処理は非特許文献２、すなわち論理チャネル優先順位付け（ＬＣＰ）手順に明記されることになる。各サイドリンク論理チャネルに対して、例えばレガシーＬＴＥ ＵＬ動作での論理チャネル優先度と同様の関連する優先度があることになる。サイドリンク論理チャネルの作成はＵＥ実装次第であることになり、Ｒｅｌ−１２と同様である。論理チャネルを作成するときにパケットのソース／宛先ＩＤを考慮することに加えて、ＵＥはパケットの優先度も考慮することになる。本質的に、同じＰＰＰＰ値（および同じソース／宛先ＩＤ）を有するプロトコルデータユニットは、ＰＰＰＰと同じである一定の関連する論理チャネル優先度を持つ１つのサイドリンク論理チャネルによって扱われることになる。

【0107】

以上説明したように、論理チャネル優先順位付け手順の間、ＵＥがＳＬグラントを受信すると、ＵＥは、ＳＬデータを有するサイドリンク論理チャネルの中で最高ＰＰＰＰを持つサイドリンク論理チャネルを有するＰｒｏＳｅグループを選択し、次いで選択したＰｒｏＳｅ宛先グループに帰属するすべてのサイドリンク論理チャネルを優先度降順に扱う。

【0108】

＜車両通信−Ｖ２Ｘサービス＞
近接サービス（ＰｒｏＳｅ）およびＬＴＥベースのブロードキャストサービスを含め−自動車業界への新たなＬＴＥ特徴の有用性を考慮するためにＲｅｌ．１４で３ＧＰＰに新たな検討項目が設定された。ＰｒｏＳｅ機能性は、したがって、Ｖ２Ｘサービスの良好な基礎を提供すると考えられる。車両シナリオにおける協調サービスが、ＩＴＳ（Intelligent Transportation Systems：高度道路交通システム）研究分野内の将来の接続車両のために重要になっている。それらのサービスは、道路死者数を減少させ、道路の容量を改善し、道路輸送のカーボンフットプリントを低減させ、走行中のユーザ体験を強化するものとされる。

【0109】

Ｖ２Ｘ通信は、車両からその車両に作用することができる任意のエンティティへの、およびその逆への情報の伝達である。この情報交換は、安全性、移動性および環境適用を改善して、運転者支援車両安全性、速度適応および警報、緊急応答、走行情報、ナビゲーション、交通運用、商用運行計画ならびに支払取引を含めるために使用されることができる。

【0110】

Ｖ２ＸサービスのためのＬＴＥサポートは、以下である３種類の異なるユースケースを含む：
− Ｖ２Ｖ：車両間のＬＴＥベースの通信をカバーする。
− Ｖ２Ｐ：車両と個人によって携行されるデバイス（例えば歩行者、サイクリスト、運転者または乗客によって携行されるハンドヘルド端末）との間のＬＴＥベースの通信をカバーする。
− Ｖ２Ｉ：車両と路側ユニットとの間のＬＴＥベースの通信をカバーする。

【0111】

これらの３種類のＶ２Ｘは「協調認識」を使用して、エンドユーザにより高度なサービスを提供することができる。これは、車両、路側インフラおよび歩行者などの輸送エンティティがそれらの局所環境についての知識（例えば、近接の他の車両またはセンサ機器から受信される情報）を収集して、協調衝突警報または自律運転など、より高度なサービスを提供するために、その知識を処理および共有することができることを意味する。

【0112】

Ｖ２Ｖ通信に関して、Ｅ−ＵＴＲＡＮは、互いの近接にあるような（車両）ＵＥが、容認、許可および近接判定基準が満たされる場合にＥ−ＵＴＲＡ（Ｎ）を使用してＶ２Ｖ関連情報を交換するのを許容する。近接判定基準はＭＮＯ（Mobile Network Operator：移動通信事業者）によって設定されることができる。しかしながら、Ｖ２ＶサービスをサポートするＵＥは、Ｖ２ＸサービスをサポートするＥ−ＵＴＲＡＮによって応対されているとき、または応対されていないときに、そのような情報を交換することができる。

【0113】

Ｖ２Ｖアプリケーションをサポートするデバイス（車両ＵＥ）はアプリケーションレイヤ情報（例えばＶ２Ｖサービスの一部としてのその場所、動態および属性について）を送信する。Ｖ２Ｖペイロードは、異なる情報内容を収容するために柔軟でなければならず、情報は、ＭＮＯによって提供される構成に従って周期的に送信されることができる。

【0114】

Ｖ２Ｖは主にブロードキャストベースであり、Ｖ２Ｖは、直接異なったデバイス間のＶ２Ｖ関連アプリケーション情報の交換、および／またはＶ２Ｖの限られた直接通信距離のため、Ｖ２Ｘサービスをサポートするインフラ、例えば、ＲＳＵ、アプリケーションサーバなどを介する異なったデバイス間のＶ２Ｖ関連アプリケーション情報の交換を含む。

【0115】

Ｖ２Ｉ通信に関して、Ｖ２Ｉアプリケーションをサポートするデバイスは路側ユニット（Road Side Unit）にアプリケーションレイヤ情報を送信し、路側ユニットは次いで、Ｖ２Ｉアプリケーションをサポートする一群のデバイスまたは単一のデバイスにアプリケーションレイヤ情報を送信することができる。

【0116】

Ｖ２Ｎ（車両−ネットワーク（ｅＮＢ／ＣＮ））も導入され、ここでは一方の当事者がＵＥであり、他方の当事者がサービングエンティティであり、両方ともＶ２Ｎアプリケーションをサポートし、ＬＴＥネットワークを介して互いと通信する。

【0117】

Ｖ２Ｐ通信に関して、Ｅ−ＵＴＲＡＮは、互いの近接にあるようなＵＥが、容認、許可および近接判定基準が満たされる場合にＥ−ＵＴＲＡＮを使用してＶ２Ｐ関連情報を交換するのを許容する。近接判定基準はＭＮＯによって設定されることができる。しかしながら、Ｖ２ＰサービスをサポートするＵＥは、Ｖ２ＸサービスをサポートするＥ−ＵＴＲＡＮによって応対されていないときでも、そのような情報を交換することができる。

【0118】

Ｖ２ＰアプリケーションをサポートするＵＥはアプリケーションレイヤ情報を送信する。そのような情報は、Ｖ２Ｘサービス（例えば、歩行者への警報）をサポートするＵＥを持つ車両によって、および／またはＶ２Ｘサービス（例えば、車両への警報）をサポートするＵＥを持つ歩行者によってブロードキャストされることができる。

【0119】

Ｖ２Ｐは、直接異なったＵＥ（一方が車両のため、他方が歩行者ため）間のＶ２Ｐ関連アプリケーション情報の交換、および／またはＶ２Ｐの限られた直接通信距離のため、Ｖ２Ｘサービスをサポートするインフラ、例えば、ＲＳＵ、アプリケーションサーバなどを介する異なったＵＥ間のＶ２Ｐ関連アプリケーション情報の交換を含む。

【0120】

この新たな検討項目Ｖ２Ｘに関して、３ＧＰＰは、非特許文献９で特定の用語および定義を提供しており、それを本出願のために再使用することができる。

【0121】

路側ユニット（ＲＳＵ）：Ｖ２Ｉアプリケーションを使用するＵＥに送信およびＵＥから受信することができる、Ｖ２Ｉサービスをサポートするエンティティ。ＲＳＵはｅＮＢまたは固定ＵＥに実装されることができる。

【0122】

Ｖ２Ｉサービス：Ｖ２Ｘサービスの一種であって、一方の当事者がＵＥであり、他方の当事者がＲＳＵであり、両方ともＶ２Ｉアプリケーションを使用する。

【0123】

Ｖ２Ｎサービス：Ｖ２Ｘサービスの一種であって、一方の当事者がＵＥであり、他方の当事者がサービングエンティティであり、両方ともＶ２Ｎアプリケーションを使用し、ＬＴＥネットワークエンティティを介して互いと通信する。

【0124】

Ｖ２Ｐサービス：Ｖ２Ｘサービスの一種であって、通信の両当事者がＶ２Ｐアプリケーションを使用するＵＥである。

【0125】

Ｖ２Ｖサービス：Ｖ２Ｘサービスの一種であって、通信の両当事者がＶ２Ｖアプリケーションを使用するＵＥである。

【0126】

Ｖ２Ｘサービス：３ＧＰＰ搬送を介してＶ２Ｖアプリケーション使用する送信または受信ＵＥを伴う一種の通信サービス。通信に関与する他方の当事者に基づいて、Ｖ２Ｘサービスは、Ｖ２Ｖサービス、Ｖ２Ｉサービス、Ｖ２ＰサービスおよびＶ２Ｎサービスにさらに分割されることができる。

【0127】

多くのＩＴＳサービスが共通の通信要件を有する：
− 周期的状況交換。ＩＴＳサービスは典型的に、車両または路側端末の状況について知る必要がある。これは、場所、速度、識別子などについての情報を持つデータパケットの周期的交換を暗示する。
− 非同期通知。この種類のメッセージは特定のサービスイベントについて通知するために使用される。先の状況メッセージとは対照的に、これらのメッセージの単一または一群の端末への確実な配信が通常主要な要件である。

【0128】

第１の通信型の使用法の例は、車両から周期状況データを集める、遠隔車両監視などの交通効率サービス、または周囲車両についての運動情報を必要として潜在的な衝撃を検出する、協調衝突回避などの安全サービスに見られることができる。非同期通知は主に、滑り易い舗装または衝突後警報などの安全サービスに見られる。

【0129】

異なる種類のメッセージがＶ２Ｖ通信のために規定されており、かつ規定されることになる。２つの異なる種類のメッセージが高度道路交通システム（ＩＴＳ）のためにＥＴＳＩによって既に規定されており、対応する非特許文献１０および非特許文献１１を参照のこと：
− 協調認識メッセージ（ＣＡＭ：Cooperative Awareness Message）であって、車両動態によって連続的にトリガされて車両状況を反映する。
− 分散環境通知メッセージ（ＤＥＮＭ：Decentralized Environmental Notification Message）であって、車両関連安全イベントが発生する場合にだけトリガされる。

【0130】

Ｖ２ＶおよびＩＴＳ標準化がむしろ始めのうちであるので、将来に他のメッセージが規定される可能性があると予期される。

【0131】

ＣＡＭは、ＩＴＳ局（ＩＴＳ−Ｓ）によって連続的（周期的）にブロードキャストされて他のＩＴＳ−Ｓと状況情報を交換し、したがってイベントトリガ型（非周期）ＤＥＮＭメッセージよりトラヒック負荷への影響が大きい。本質的に、ＣＡＭメッセージは、各車両によってその隣接物に周期的にブロードキャストされて存在、位置、温度および基本状況の情報を提供する一種のハートビートメッセージである。逆に、ＤＥＮＭは、ブロードキャストされて道路ユーザに危険イベントについて警告するイベントトリガ型メッセージである。この理由で、ＩＴＳのためにＥＴＳＩによって規定されるＣＡＭメッセージのトラヒック特性は、Ｖ２Ｖトラヒックをより表すと考えられる。

【0132】

以上では、周期協調認識メッセージを記載した。しかしながら、上記情報のいくつかが既に標準化されているとは言え、周期性およびメッセージサイズなどの他の情報がまだ標準化されておらず、かつ前提に基づくことに留意するべきである。さらには、標準化は、将来に変更される可能性があり、したがってＣＡＭがどのように生成および送信されるかの態様を変更する可能性もある。結果的に、ＣＡＭの上記の詳細な説明は、例示目的で考案された例として理解するべきである。

【0133】

車両ＵＥがサイドリンク上に無線リソースを有してＣＡＭを送信するために、Ｍｏｄｅ１および／またはＭｏｄｅ２無線リソース割当てが以上説明したように想定される。モード１無線リソース割当てに関して、ｅＮＢは、各ＳＡ周期の間、ＳＡメッセージおよびデータのためのリソースを割り当てる。しかしながら、多くのトラヒック（例えば高周波周期的トラヒック）がある場合、ＵＥからｅＮＢへのＵｕリンク上のオーバーヘッドは大きくなりえる。

【0134】

上記から明らかなように、多くのＶ２Ｖトラヒックが周期的であり、そのため３ＧＰＰは、サイドリンクＶ２Ｖ通信モード１（すなわちｅＮＢスケジュール無線リソース割当て）に関して、ｅＮＢおよびＵＥによってサイドリンクセミパーシステント無線リソース割当てがサポートされることに同意した。

【0135】

ＵＥ自律リソース割当てモード（モード２）に関して、衝突問題、すなわち２つ以上のＴｘ ＵＥが同じＲＢをメッセージを配信するように選択する時が、ユーザによって経験されるＱｏＳに影響を与えることが明らかである。Ｒｅｌ−１２／１３に関して、ＰＣ５／サイドリンクに対するＱｏＳが重大な要件でなかったので、ＵＥ自律リソース割当てモードに対するデータ（ＰＳＳＣＨ）衝突問題は論じなかった。しかしながら、Ｖ２Ｘサービスの場合、ＵＥ自律リソース割当てモードに対してＱｏＳを改善することは不可避である。３ＧＰＰは概して、検知および「セミパーシステント」送信（無線リソース予約とも称されてもよい）によってＵＥ自律リソース選択のＱｏＳを改善することに同意した。

【0136】

より詳細には、Ｖ２Ｘサイドリンクのための自律リソース制御／選択メカニズムとしてセミパーシステント送信と共に検知メカニズムをサポートすることが同意された。ＵＥは、リソース選択が起こるまで、ＵＥが選択された一組の周期的に発生するリソース上にデータを有することをＰＳＳＣＨ（ＳＡ／ＳＣＩ）内で示すであろう。このリソース予約情報（ＳＣＩ内でシグナリングされる）は、他のＵＥによって既に予約／予定されているリソースが無線リソース選択のために考慮されないように、リソースの選択のためにＶ２Ｘメッセージを送信することを意図している他のＵＥによって使用されることができる。このリソース予約／予定手順は、パケットが一定の周期性で到着するトラヒック（例えばＣＡＭメッセージ）にだけ適用されるのものとする。

【0137】

上述したスケジューリング情報での予約無線リソースの指示は他の（車両）デバイスによってモニタリング（「検知」）されることができる。一般に、検知は、送信のための一組の候補リソースを識別するときに使用される。この目的で、検知プロセスは周波数リソースを異なるグループに分類する：
− 「利用不可」リソース。これらは、それらのリソースが他のＵＥによって既に予定／予約されているので、ＵＥが送信するのを許容されないリソースである。
− 「候補リソース」。これらは、ＵＥが送信を行ってもよい／行うことができるリソースであり、「プライマリリソース」および「セカンダリリソース」にさらに分類してもよい。

【0138】

ＵＥの複雑さをあまり増さないために、検知は簡単な方途で実装可能であるべきである。検知アルゴリズムを実装する仕方に関する複数の方途／オプションがある可能性があることも留意するべきである。１つの潜在的な実装オプションは、あらゆるＵＥが、次のサブフレームから始まる、多くとも例えば１秒に渡る周波数リソースの予測を持つマップを有するということである。すなわち、パケットがＵＥにおけるバッファに到着する時間Ｐに、ＵＥはサブフレームＰ〜Ｌに対するすべての周波数リソースのマップを有し、Ｌは基本的に、リソースの各々が「利用不可」であろうと候補であろうと、パケットが送信されるべきであるまでの最大時間帯（ＱｏＳに係る）を示す。

【0139】

「利用不可」リソースはＳＣＩ復号（リソース予定／予約）に基づいて決定される。送信のための実際のリソースの選択（一組のリソース候補から）の詳細が３ＧＰＰでまだ最終的に確定されておらず、今なお検討に委ねられていることに留意するべきである。１つの例示的な手法は、送信のために使用される実際のリソースの選択が一組の候補リソース内で、すべての選択肢に等しい確率を割り当てて、ランダムに行われるということであろう。リソースの同様のマップを持つＵＥが異なるリソースを選択することを保証するために、ランダム性が適切であろう。一組の候補リソースが十分に大きい限り、ランダム選択を使用することは、相関観測を持つＵＥが同じリソースを選ぶ確率が低いことを保証する。基礎として、ＵＥは最も近いリソースを、トランスポートブロックの（再）送信のための候補リソースとして分類したと考える。候補リソースが遅延、帯域幅などといった他の関連した要件を満たすことを保証するために、さらなる制約が適用されてもよい。すべてのこれらのリソースは送信のための一組の候補リソースを構成する。別の手法は、（ランダム選択とは対照的に）候補リソースの中で実際の送信リソースを選択するために、エネルギーベースの検知結果もさらに使用することであろう。ＲＢレベルの情報を持つマップを有することによって、ＵＥが完全な柔軟性を有し、検知するときにスケジュールするトランスポートブロックのサイズを知る必要はないことに留意するべきである。

【0140】

Ｖ２Ｘサービスの異なるＱｏＳ要件をよりよくサポートおよび保証するために、３ＧＰＰでの現在の検討が、追加ＱｏＳパラメータが使用される解決策を提供する。ＰＣ５インタフェースおよびＵｕインタフェースは区別される。

【0141】

例えば、ＰＣ５インタフェースに対してこれまでに提案された１つの解決策は、ＭＭＥがＵＥコンテキスト情報の一部としてｅＮＢにＵＥ−ＰＣ５−ＡＭＢＲ（Aggregated Maximum Bit Rate：総最大ビットレート）を提供するということである。ｅＮＢは、したがって、ＵＥ−ＰＣ５−ＡＭＢＲを使用して、リソースを適切に割り当てることによってＵＥ ＰＣ５送信を制限することができる。説明したように、アプリケーションレイヤからの優先度情報（例えばＰＰＰＰ）は、リソースを要求するときに（モード１−ｅＮＢスケジュール）、ＵＥによってｅＮＢに送信される。ｅＮＢは次いで、ＵＥによって提供された優先度情報からパケット遅延バジェットおよび信頼性を推論するものとし、それを優先度処理のために使用する。優先度情報とパケット遅延バジェット／信頼性との間のマッピングは、例えばＯ＆Ｍ構成を供給することに基づいてもよく、または仕様で規定されてもよい。

【0142】

モード２ ＵＥ自律リソース割当てに対しては適切な解決策は現在検討されておらず、そのためＱｏＳ要件はモード１に対してのみ保証されることができる。しかしながら、モード１およびモード２のＱｏＳ要件の等しい処理が好ましく思われ、Ｖ２Ｘアプリケーションが−現在−Ｖ２Ｘデータを送信するために下位レイヤによって利用されるモードについて通知されていないことを考慮すればなおさらである。

【0143】

その上、Ｕｕインタフェースに対して３ＧＰＰで現在調査されている１つの解決策は、Ｖ２Ｘサービスのために１つのＧＢＲ ＱＣＩおよび１つの非ＧＢＲ ＱＣＩを導入することである。

【0144】

【表2】

【0145】

明らかなように、３ＧＰＰ団体は、Ｖ２Ｘデータの送信のためのＱｏＳを最もよく実装する仕方に関する異なる解決策を現在調査している。

【0146】

本開示は、したがって、上述した課題の１つまたは複数を克服することを容易にする解決策を提示するものとする。

【0147】

＜本開示の詳細な説明＞
移動局または移動ノードまたはユーザ端末またはユーザ機器は、通信ネットワーク内の物理エンティティである。１つのノードがいくつかの機能エンティティを有してもよい。機能エンティティは、所定の機能の集合をノードの他の機能エンティティまたはネットワークに実装および／または提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードが通信するために介することができる通信機構または媒体にノードを取り付ける１つまたは複数のインタフェースを有してもよい。同様に、ネットワークエンティティは、機能エンティティが他の機能エンティティまたは対応ノードと通信するために介してもよい通信機構または媒体に機能エンティティを取り付ける論理インタフェースを有してもよい。

【0148】

用語「無線リソース」および「周波数−時間無線リソース」は、本願の請求項でおよび本出願で使用する場合、時間−周波数リソースなどの物理無線リソースを指すとして広く理解しなければならない。

【0149】

用語「直接通信送信」は、本出願で使用する場合、直接に２つのユーザ機器間の、すなわち無線基地局（例えばｅＮＢ）を介さない送信として広く理解しなければならない。対応して、直接通信送信は「直接サイドリンク接続」を通じて行われ、これは直接に２つのユーザ機器間に確立される接続のために使用される用語である。例えば、３ＧＰＰでは、Ｄ２Ｄ（デバイスツーデバイス）通信またはＰｒｏＳｅ通信またはサイドリンク通信の専門用語が使用される。用語「直接サイドリンク接続」、「サイドリンクインタフェース」は、背景に記載したＰＣ５インタフェースとして広く理解しなければならず、かつ３ＧＰＰコンテキストで理解することができる。

【0150】

本出願で使用する用語「ＰｒｏＳｅ」またはその非省略形で「近接サービス（Proximity Service）」は、背景で例示的に説明したように、ＬＴＥシステムでの近接ベースのアプリケーションおよびサービスの文脈で適用される。「Ｄ２Ｄ」などの他の専門用語もこの文脈で使用して、近接サービスのためのデバイスツーデバイス通信を指す。

【0151】

用語「車両移動端末」は、本出願を通して使用する場合、背景で説明したように、新たな３ＧＰＰ検討項目ないし作業項目Ｖ２Ｘ（車両通信）の文脈で例示的に理解してもよい。対応して、車両移動端末は、特に車両（例えば車、商用トラック、オートバイなど）に設置されて車両通信を行う、すなわち、例えば安全性または運転者支援の目的で他のエンティティ（車両、インフラ、歩行者など）に車両に関連した情報を渡す移動端末として広く理解するものとする。任意選択で、車両移動端末は、マップ情報などといった、ナビゲーションシステムで利用可能な情報にアクセスできてもよい（それも車に設置されるとの条件で）。

【0152】

用語「自律無線リソース割当て」および「無線基地局制御無線リソース割当て」は、本出願を通して使用する場合、リソース割当てに２つのモード；すなわち、無線基地局が割当てを制御するモード１（すなわち、無線基地局制御無線リソース割当て）および端末（または送信装置）がリソースを（無線基地局なしで）自律的に選択するモード２（すなわち自律無線リソース割当て）を許容する３ＧＰＰ近接サービスの文脈で例示的に理解してもよい。

【0153】

用語「アプリケーションレイヤ」および「送信レイヤ」は、本出願を通して使用する場合、それぞれの手順、すなわちアプリケーションデータ（車両データなど）の生成ないしデータの送信（例えば無線リソース割当ても含む）を担うＵＥ／送信装置内の抽象エンティティとして例示的に理解してもよい。「アプリケーションレイヤ」および「送信レイヤ」は、ＯＳＩ（Open Systems Interconnection：開放システム相互接続）レイヤモデルにおけるレイヤに対応しても、またはしなくてもよい。レイヤ自体はソフトウェアおよび／またはハードウェアで例示的に実装されて、その機能を行ってもよい。１つの例では、「アプリケーションレイヤ」はＵＥ／送信装置またはＰｒｏＳｅレイヤのレイヤ３の一部であることができる。他方で、「送信レイヤ」は例示的にＵＥ／送信装置のレイヤ１および２（すなわち、物理レイヤないしＰＤＣＰ、ＲＬＣ、ＭＡＣレイヤ）であることができる。

【0154】

背景で説明したように、３ＧＰＰはＬＴＥ支援車両通信のための新たな検討項目を導入しており、これはＰｒｏＳｅ手順に基づいて様々な車両移動端末と他局との間でＶ２Ｘトラヒックを交換するものとする。さらには、特にサイドリンクインタフェースを介する車両通信のサービス品質要件をサポートするための検討および提議が継続中である。検討は、これまで、ｅＮＢに適切なサービス品質パラメータを提供することに焦点を合わせた。その場合、しかしながら、少なくとも１つの問題が残る、すなわち車両データの送信のためにリソース割当てモード２を使用して、ＵＥが無線リソース割当てを自律的に、すなわちｅＮＢからの支援なしで行うときに、車両通信のためのサービス品質をサポートする仕方である。

【0155】

以上説明した１つまたは複数の課題を軽減するために、以下の例示的な実施形態が発明者らによって考えられる。

【0156】

様々な実施形態の特定の実装が、以下の実施形態で説明するように特定の主要な特徴を追加しつつ、３ＧＰＰ規格によって与えられ、かつ背景で部分的に説明したような広範な仕様で実装されるものである。実施形態は、例えば上記技術背景に記載したように、３ＧＰＰ ＬＴＥ−Ａ（Ｒｅｌｅａｓｅ１０／１１／１２／１３／１４またはそれより後のリリース）通信システムなどの移動通信システムに有利に使用されることができるが、しかし実施形態はこれらの特定の例示的な通信ネットワークでのその使用に限定されないことに留意するべきである。

【0157】

説明のためになされるシナリオおよび前提は、本開示の範囲を限定するとしてではなく、本開示をよりよく理解するための単なる例として理解すべきである。当業者は、請求項に述べるような本開示の一般的な原理が異なるシナリオに、かつ本明細書に明記しない方途で適用されることができることを認識しているべきである。

【0158】

様々な実施形態は主に、サイドリンクインタフェースを介する送信装置から１つまたは複数の受信装置への車両データの改善された送信を提供し、これには無線リソースの割当ても伴う。他の機能性（すなわち様々な実施形態によって変更されない機能性）は、背景で説明したのと厳密に同じままでもよいし、または様々な実施形態へのいかなる影響もなしで変更されてもよい。これは、例えばリソース割当てを通じて得られた送信パラメータを使用して周期データの送信が送信装置によって厳密に行われる仕方、または様々なＰｒｏＳｅデバイスが互いを発見する仕方などの他の手順を含んでもよい。

【0159】

様々な実施形態が適用されることができる１つの例示的なシナリオは、背景で例示したＶ２Ｘ通信である。結果的に、送信および受信装置は、例えば車両におけるＵＥ、路側ユニット、歩行者によって携行される「標準」移動端末などであることができる。

【0160】

様々な異なる実施形態が、以下から明らかになるように、例示的かつ例証的なＶ２Ｘシナリオに関連して提示および説明される。車両に設置され、かつ本出願の背景で説明したようにＤ２Ｄフレームワークに基づいて（すなわちサイドリンクＰＣ５インタフェースを介して）車両通信を行うことが可能である車両ＵＥ（一般に、送信装置）が前提とされる。対応して、車両データは、車両ＵＥによってデータの対象である他のエンティティ（一般に、受信装置）に送信されるものとする。

【0161】

さらには、車両ＵＥが両リソース割当てモード、すなわちｅＮｏｄｅＢ制御リソース割当てモード１の他にＵＥ自律リソース割当てモード２をサポートすることを前提とし、その例示的な実装は背景で説明される。いくつかの実施形態は、サービス品質要件を適切にサポートして満たすようにＵＥ自律リソース割当てモード２を改善することに焦点を合わせる。２つのリソース割当てのいずれかが車両ＵＥによって行われて、必要な送信パラメータを得、次いでそれらの送信パラメータに基づいて車両データの実際の送信を行う。

【0162】

例示目的で、車両ＵＥは、レイヤ１（物理）、レイヤ２（ＰＤＣＰ、ＲＬＣ、ＭＡＣ）、レイヤ３（ＩＰプロトコル、ＰｒｏＳｅ機能などの非アクセス層レイヤ）などの様々なレイヤを備えるプロトコルスタックを有すると考えられる。それぞれのレイヤによって異なる機能が行われる。説明目的で、プロトコルスタックは、１つまたは複数のアプリケーションレイヤおよび送信レイヤのみを備えるように単純化され、ここではアプリケーションレイヤが基本的に、アプリケーションのデータ（車両アプリケーションの車両データなど）を生成する役割を担う一方で、送信レイヤは、（サイドリンク）インタフェースを通じてデータを送信する役割を担う（例えばそれぞれのアプリケーションレイヤによって生成された車両データまたは他の非車両データは送信レイヤに渡される）。

【0163】

（第１の実施形態）
以下に、上述の課題を解決するための第１の実施形態を詳細に記載することにする。第１の実施形態の異なる実装および変形も説明することになる。

【0164】

背景で説明したように、いわゆるＰｒｏＳｅパケット毎優先度（ＰＰＰＰ）がＲｅｌｅａｓｅ１３で導入されて、ＰｒｏＳｅ１対多通信のための優先度処理およびサービス品質処理をサポートした。ＰＰＰＰは、ＰｒｏＳｅ上位レイヤ（すなわちデータを生成する役割を担うアプリケーションレイヤ）が送信のための下位レイヤ（すなわち送信レイヤ）に（ＰＰＰＰと共に）渡されるデータパケットに優先順位を付けるのを許容する。送信レイヤは、したがって、ＰＰＰＰを使用して、例えば他のＵＥ内データ（すなわち同じ車両ＵＥ内の他のアプリケーションからのデータ）に関して、受け取ったデータに優先順位を付けてもよい。

【0165】

要するに、第１の実施形態によれば、ＰＰＰＰに加えて、アプリケーションレイヤは、送信レイヤに車両データのサービス品質要件に関連したパラメータを転送してもよい。送信レイヤで行われるモード２による無線リソース割当て手順が、受け取ったパラメータ、すなわちＰＰＰＰおよびＱｏＳパラメータを考慮して、受信エンティティへの車両データの送信のために使用されることになる送信パラメータを得る。それによって、ＵＥ自律リソース割当てモードに対しても車両データを送信するためのＱｏＳサポートを実装することが可能である。

【0166】

第１の実施形態の１つの例示的な実装では、３ＧＰＰ ＬＴＥのために既に標準化されているＱＣＩ特性の１つまたは複数をＱｏＳパラメータとして再使用することができる。特に、３ＧＰＰは異なるパラメータを標準化して、リソース型（ＧＢＲまたは非ＧＢＲ）、優先度レベル、パケット遅延バジェットの他にパケット誤り損失率などのＱｏＳをサポートしている（参照により本明細書に援用される非特許文献５の６．１．７．２項「Standardized QCI characteristics」を参照のこと）。６．１．７．２項で標準化された優先度レベルは、ＰＰＰＰ（ＰｒｏＳｅ通信のために導入されたと上述した）に対応すると見られ得、そのためその他のＱｏＳパラメータと別のパラメータとして見なされ得る。代替的に、ＰＰＰＰは別のＱｏＳパラメータとして見なされ得る。

【0167】

要するに、リソース型は基本的に、データを送信するときに特定のビットレートが保証されることになるか否かを示す。パケット遅延バジェットは、パケットが送信エンティティ（車両ＵＥ）から受信エンティティへの配信のために要するであろう時間に対する上限を規定する。パケット誤り損失率（ＰＥＬＲ：Packet Error Loss Rate）は、受信エンティティに正常に配信されないパケットの率に対する上限を規定する。パケット誤り損失率は、より高いＰＥＬＲを引き起こす可能性がある低パケット遅延バジェットを考慮しつつ、アプリケーションレイヤメッセージ再送信を必要とすることなく高信頼性をサポートするように設定されてもよい。

【0168】

第１の実施形態によれば、車両通信の役割を担うアプリケーションレイヤはＶ２Ｘデータを生成する。前述したように、アプリケーションレイヤは、Ｖ２Ｘメッセージを送信のための下位レイヤに渡すときにＶ２ＸメッセージのＰＰＰＰを設定する。アプリケーションレイヤＶ２Ｘメッセージ優先度のＰＰＰＰへのマッピングは、例えばＵＥにおける事前設定に基づく。ＵＥでのそのようなマッピングの構成は３ＧＰＰの範囲外であり、本明細書で論ずる実施形態とは関係ない。アプリケーションレイヤが送信されることになるＶ２Ｘデータの種類を一般に認識しているので、アプリケーションレイヤは−対応するＰＰＰＰと同様で−生成したＶ２Ｘデータに対応する上述のＱｏＳパラメータの１つまたは複数も下位レイヤに提供してもよい。再び、アプリケーションレイヤＶ２ＸデータとＱｏＳパラメータとの間のマッピングは、例えばＵＥにおける事前設定に基づく。Ｖ２Ｘデータ、ＰＰＰＰおよび１つまたは複数のＱｏＳパラメータは、プロトコルスタックに沿って、無線リソース割当ておよびＶ２Ｘデータの送信を行う役割を担う送信レイヤに渡される。

【0169】

１つの例によれば、ＱｏＳパラメータ（の他にＰＰＰＰ）は、あらゆるパケットと共に送信レイヤに転送される。それによって、同一のＰＰＰＰのＱｏＳ要件を選択的に区別することによって、いかなるデータパケット送信のためのＱｏＳも適切にサポートすることが可能である。代替的に、ＰＰＰＰがあらゆるパケットと転送されるのに対して、ＱｏＳパラメータは、始めに（例えば一度）、すなわち新たなサービスが開始され、下位レイヤにおける対応するサイドリンク論理チャネルが設定されるときに、送信レイヤに提供されるだけでもよい。次いで、車両ＵＥの送信レイヤは、受け取ったＰＰＰＰに基づいて、同じＰＰＰＰと共に転送される以降のデータパケットを、既に受け取ったＱｏＳパラメータに関連づけることができ；特定のＰＰＰＰに対して構成される１つのサイドリンク論理チャネルが、そのサイドリンク論理チャネルが設定されたときに受け取られたＱｏＳパラメータと関連づけられる。このことは、ＱｏＳパラメータがあらゆるデータパケットと送信される必要がないので、レイヤ間通信が減少されるという利点を有する。

【0170】

上述したように、車両ＵＥは、モード２（すなわちＵＥ自律）に従ってリソース割当てを行って必要な送信パラメータを得、それによって、例えばモード１リソース割当てのためにｅＮＢによってなされる対応するように、ＰＰＰＰおよびＱｏＳパラメータをさらに考慮するものとする。より詳細に、モード２リソース割当てを行うことは典型的に、符号化データを送信するのに適切な変調方式および符号化率を選択することの他に十分な周波数−時間無線リソースの選択を伴う。加えて、Ｄ２Ｄデータ送信は、送信信頼性を増すために、おそらくトランスポートブロックのブラインド反復（例えばＨＡＲＱフィードバックなし）を伴うであろう。全送信数が柔軟であり、予め設定されていないことを前提として、無線リソース割当ては、車両ＵＥ全体によって行われるべきであるデータパケットの送信数を決定することを伴ってもよい。

【0171】

リソース割当ては、送信されることになるＶ２Ｘデータに対して上位のレイヤから受け取られるパラメータに基づいて行われるものとする。例えば、変調方式および／または符号化率は、パケット誤り損失率がおそらく満たされるように選択されることができる。同様に、１つのトランスポートブロックのための総送信数を増加させることによって、車両ＵＥはパケット誤り損失率を減少させることができる。したがって、送信数はパケット誤り損失率を基礎として選択されてもよい。

【0172】

他方で、パケット遅延バジェットは、無線リソース割当ての間、例えば車両ＵＥが既に得られた検知結果に基づいて利用可能な周波数時間無線リソースを決定するときに使用され得る。車両データのＰＣ５送信のための自律リソース制御／選択メカニズムのためのセミパーシステント送信で検知をサポートすることが同意されたので、送信装置は、検知ウィンドウに渡って行われる検知結果に基づいてデータパケットの送信（再送信を含む）のための未使用／空き無線リソースを選択し、ここでは送信リソースが遅延パケットバジェット内にあるものとする。例えば、パケット遅延バジェットが２０ｍｓである場合、車両ＵＥは、データパケットのすべての送信が、パケットがＵＥのバッファに到着してから２０ｍｓ以内に起こることを保証するものとする。その上、パケット遅延バジェットは、車両ＵＥで使用されて、失効データパケット（すなわちパケット遅延バジェットが超過されたデータパケット）を決定することができ、その場合データパケットは破棄されることができる。

【0173】

アプリケーションレイヤから受け取られる優先度レベル（またはＰＰＰＰ）は、例えばサイドリンク論理チャネル優先順位付け手順で、決定した周波数−時間無線リソースを割り当てて、Ｖ２Ｘデータを通知するトランスポートブロックを生成するときに使用されることができる。１つの例示的な実装では、周波数−時間無線リソースは、Ｖ２Ｘデータ（より詳細には、Ｖ２ＸデータのＰＰＰＰに従って設定される論理チャネルの）のＰＰＰＰの降順にデータを送信することに割り当てられる。このようにして作成されたトランスポートブロックは次いで、車両ＵＥによって他の受信装置に送信される。

【0174】

図９は、アプリケーションおよび送信レイヤによって行われる機能を示す、第１の実施形態の例示的な実装を示す図である。それから明らかなように、アプリケーションレイヤはＶ２Ｘデータを生成し、その後Ｖ２Ｘデータに対する対応する優先度およびＱｏＳパラメータを決定し、それを送信の役割を担う下位送信レイヤに提供する。送信レイヤは次いで、受け取ったパラメータおよび優先度に基づいてＵＥ自律リソース割当てを行い、他のデバイスにＰＣ５インタフェースを介してＶ２Ｘデータを送信し始める。

【0175】

その上、第１の実施形態のさらなる実装によれば、車両ＵＥは、ＵＥ−ＰＣ５−ＡＭＢＲ（サイドリンクインタフェースのための総最大ビットレート）に関する情報が提供されてもよい。ＵＥ−ＰＣ５−ＡＭＢＲは、サイドリンクインタフェースを通じた送信のためにＵＥに対して許容される最大総データスループットとして理解することができる。換言すれば、ＵＥは、サイドリンクインタフェースを介してデータを送信するときに特定の平均ビットレート（単位時間当たりのデータ）に制限される。この一般的定義によれば、ＡＭＢＲはＵＥ固有である他にインタフェース固有であるが、しかしすべてのサイドリンク論理チャネル、すなわち車両または非車両データを通知するサイドリンク論理チャネルに適用される。

【0176】

１つの変形では、ＵＥ−ＰＣ５−ＡＭＢＲは、例えばアタッチ手順の間にｅＮＢから対応する個別メッセージで車両ＵＥに提供されることができる。アタッチ手順の間に、ＭＭＥは、ＨＳＳ（Home Subscriber Server：ホーム加入者サーバ）からのＵＥ加入契約およびネットワーク事業者のポリシーに従ってＵＥ−ＰＣ５−ＡＭＢＲを得る。このＵＥ−ＰＣ５−ＡＭＢＲは次いで、ＵＥのための初期コンテキスト設定手順の間にＭＭＥからｅＮＢに送信される。ｅＮＢは次いでＵＥにＵＥ−ＰＣ５−ＡＭＢＲ値についてさらに通知することができる。代替的に、ＵＥは、何らかの事前設定に基づいて上位レイヤ（アプリケーション）からＵＥ−ＰＣ５−ＡＭＢＲ値が提供されることができる。

【0177】

ＵＥ−ＰＣ５−ＡＭＢＲは、サイドリンクインタフェースを介して送信されることになるデータ量を制限するようにサイドリンク論理チャネル優先順位付け手順でパラメータとして使用されることができる。１つの例示的な実装では、サイドリンクＬＣＰ手順でトークンバケットアルゴリズムが使用されて、この制限を実装することができる（例えば背景で説明した通常のレガシーＬＣＰ手順と同様）。特に、サイドリンク論理チャネルに対してトークンバケットが規定されることができ、そのため無線リソースは、バケットが空でない（すなわち＞０）限り、サイドリンク論理チャネルに割り当てられることができるだけである。しかしながら、トークンバケットアルゴリズムを使用しない他の実装もＵＥ−ＰＣ５−ＡＭＢＲパラメータによって与えられる制限を適用すると予期されてもよい。

【0178】

そのような適合サイドリンクＬＣＰ手順の具体的で例示的な実装を以下に与える。現行のサイドリンク論理チャネル優先順位付け手順でなされるように、ＵＥは、厳密な優先度順にサイドリンク論理チャネルにリソースを割り当てることになる。宛先（ＰｒｏＳｅ宛先）の選択は簡略化の理由でここでは考慮しない。対応する下位レイヤ（すなわちＭＡＣ）は、以下のステップで（関連する）サイドリンク論理チャネルにリソースを割り当てるものとする：
１．どちらが先にせよサイドリンク論理チャネルのためのデータかもしくはＳＬグラントかいずれかが尽きる、またはバケットが空であるまで、送信のために利用可能なデータを有するすべてのサイドリンク論理チャネルが優先度の降順に扱われる。
２．ＭＡＣエンティティが、上記ステップで扱われるＭＡＣ ＳＤＵの総サイズだけバケットレベルをデクリメントするものとする。

【0179】

さらなる例示的な実装によれば、下位レイヤ−送信レイヤ−は、車両ＵＥが構成されている／使用しているリソース割当てモードをアプリケーションレイヤに示す。この情報は、送信レイヤにデータパケットに対するＱｏＳパラメータが提供される必要があるかどうかを決定するためにアプリケーションで使用される。より詳細には、車両ＵＥがＵＥ自律リソース割当てモード（モード２）で動作している場合にのみ、アプリケーションレイヤは下位レイヤにＱｏＳ情報／パラメータを提供する必要がある。

【0180】

（第２の実施形態）
以下に、第２の実施形態を提示し、第１の実施形態によって解決されるもの、すなわち詳細な説明の始めで説明したものと同じ課題、すなわち、特に車両ＵＥがＵＥ自律無線リソース割当てを行っている、サイドリンクインタフェースを介する車両通信のためのサービス品質サポートを実装する仕方を取り扱う。

【0181】

要するに、第２の実施形態によれば、少なくとも１つのサービス品質構成が規定され、１つまたは複数のサービス品質パラメータを示す。ＱｏＳ構成を所有している送信装置は次いで、サイドリンクインタフェースを介して送信されることになる車両データに従って適切なＱｏＳ構成を選択する。第１の実施形態でと同様にして、モード２に従って車両ＵＥによって行われる無線リソース割当ては、送信パラメータを得るときに１つのＱｏＳ構成のＱｏＳパラメータを考慮する。車両データは、行われた無線リソース割当ておよび対応して得られた送信パラメータに従って送信される。結果的に、モード２リソース割当てを行うときにも、ＰＣ５インタフェースを介してＶ２Ｘデータを送信するための異なるＱｏＳ要件をサポートすることが可能である。

【0182】

第１の実施形態に関連して既に説明したように、標準化３ＧＰＰ ＬＴＥ ＱｏＳパラメータの１つまたは複数を、サービス品質、すなわちパケット遅延バジェット、パケット誤り損失率、リソース型を実装するために再使用することができる。第１の実施形態に関連してなされたこれらのＱｏＳパラメータに関するより詳細な説明を参照する。

【0183】

様々な異なるＱｏＳ構成（ＱｏＳクラスと名付けられてもよい）が規定されて、車両データに適切なサービス品質要件を区別することができる。背景で説明したように、ＵｕインタフェースでのＶ２Ｘデータ送信のＱｏＳ要件を規定する方法に関する提案が既になされている。特に、以下の２つの異なるＱｏＳ構成（それぞれＱＣＩ７５および７９によって識別される）が提案されている：

【0184】

【表3】

【0185】

表のこれらのＱｏＳ構成は、第２の実施形態に従ってＰＣ５サイドリンクインタフェースでのＶ２Ｘデータ送信にＱｏＳを適用する仕方に関する指針として取ることができる。特に、一方の可能なＱｏＳ構成は、リソース型がＧＢＲであり、パケット遅延バジェットが５０ｍｓであり、かつパケット誤り損失率が１０^−２であると規定する一方で、他方のＱｏＳ構成は、リソース型が非ＧＢＲであり、パケット遅延バジェットが５０ｍｓであり、かつパケット誤り損失率が１０^−２であると規定するものである。上記が単に例であり、パラメータに対する異なるコンステレーションおよび値が適宜選択されることができることに留意するべきである。

【0186】

上記の表から明らかなように、Ｕｕインタフェースを通じたＱｏＳ要件に対して異なる優先度レベルが予期される。サイドリンクインタフェースのためのＱｏＳサポートに関しては、ＰｒｏＳｅパケット毎優先度（ＰＰＰＰ）がＤ２Ｄ（車両）データの優先度を示すために既に標準化されていることに鑑みて、列記されるＱｏＳ構成の優先度レベルパラメータは必要とされなくてもよい。言い換えると、ＰＰＰＰはＱｏＳ構成とは別に使用されてもよい。

【0187】

他方で、車両データを生成する特定のアプリケーションレイヤから独立した車両データに対する一貫したＱｏＳ定義を有するように異なるＱｏＳ構成のための優先度レベルを標準化することも関心を引くかもしれない。この場合、ＰＰＰＰは使用されない（したがって、それとして下位レイヤに転送されない）ものであるか、またはＰＰＰＰは（アプリケーションによって生成されれば）、選択されるＱｏＳ構成によって与えられる優先度レベルによって上書きされ得る（さらに代替的にＰＰＰＰは、転送されれば、優先度レベルを上書きし得る）。

【0188】

任意選択で、サイドリンクインタフェースを介する車両データ送信のためのさらなる可能なＱｏＳパラメータが反復数、すなわち第１の実施形態でより詳細に説明したトランスポートブロックに対する総送信数であろう。

【0189】

いかなる場合にも、異なるＱｏＳ構成がこのように規定され、それぞれＱｏＳパラメータ（パケット遅延バジェット、パケット誤り損失率およびリソース型など）の１つまたは複数間で区別することができる。事実上、異なる車両データは、したがって、それらのＱｏＳ要件に関しては異なって扱われることができる。

【0190】

ＱｏＳ構成がどのように車両ＵＥに提供されることができるかに関していくつかの可能性がある。第２の実施形態の１つの例示的な実装によれば、ｅＮＢはその無線セルで異なるＱｏＳ構成に関する情報をブロードキャストし、そのためすべての（車両）ＵＥが情報を受信する。例えば、Ｖ２Ｘ固有システム情報ブロックが、ＱｏＳ構成（および場合により他のＶ２Ｘ関連情報も）を含め、ｅＮＢによってブロードキャストされ得る。代替的に、車両ＵＥは、例えばリソース割当てモードを設定するときに、個別シグナリングによってＱｏＳ構成が提供され得るか、または車両ＵＥはＱｏＳ構成が予め設定され得る。

【0191】

いかなる場合にも、車両ＵＥが、このように異なるＱｏＳ構成を提供され、したがって適切なＱｏＳ構成を選択的に使用して、サイドリンクインタフェースを介する車両データの送信の一定のＱｏＳ要件を満たすことができることを前提とする。ＱｏＳ構成は、送信されることになる車両データに適切であるように選択されるものとする。アプリケーションレイヤＶ２Ｘデータと適切なＱｏＳ構成との間のマッピングは、例えばＵＥにおける事前設定に基づく。代替的に、Ｖ２Ｘ−ＱｏＳクラスマッピングは、上記概説したようにｅＮｏｄｅＢによってブロードキャストされるシステム情報ブロック（例えば上述のＶ２Ｘ固有システム情報ブロック）または個別シグナリングを使用することによって車両ＵＥに提供されることができる。

【0192】

車両データを生成するアプリケーションレイヤは、生成したＶ２ＸデータにどのＱｏＳ構成が最も適切であるかを適切に決定することができ、サイドリンクインタフェースを介するＶ２Ｘデータの送信の役割を担う下位レイヤ（送信レイヤ）に生成したデータと共に対応する指示を提供することができる。次に、送信レイヤはＱｏＳ構成および、したがって、対応するＱｏＳパラメータを決定することができ、それらは次いで無線リソース割当て手順の間に使用されてＶ２Ｘデータの送信のための必要なパラメータを得る。アプリケーションレイヤによって生成されて、生成されたＶ２Ｘデータのために選択されるＱｏＳ構成を識別する上述の指示は、例えばＱＣＩ、すなわち３ＧＰＰ規格から既に知られているＱｏＳクラスインジケータと同様であることができる。上記の表に提示したように、Ｕｕインタフェースを介して送信される車両メッセージに対して規定される２つのＱｏＳクラスを識別するためにＱＣＩ値７５および７９が３ＧＰＰ検討中に例示的に提起された。同様にして、車両ＵＥによって使用されることになる異なるＱｏＳ構成間を区別するためにＱＣＩ値を使用することができる。送信レイヤは、ＱｏＳ構成インジケータ値について通知されてから、Ｖ２Ｘデータの送信のために満たされるものと意図される対応するＱｏＳ構成を決定することができる。第１の実施形態の１つの例示的な実装によれば、アプリケーションレイヤは、下位レイヤにデータパケットと共にＱｏＳ構成インジケータを転送する。この情報に基づいて、下位レイヤ−送信レイヤ−は、このデータパケットの送信のためにどのＱｏＳ構成を適用するべきかを知る。任意選択で、アプリケーションレイヤは、特にＱｏＳ構成が優先度レベルを明記しない場合に、送信レイヤにＶ２Ｘデータに対するＰＰＰＰも転送してもよい。他方で、ＱｏＳ構成がＶ２Ｘデータの特定の優先度レベルも明記する場合には、別のＰＰＰＰ指示は理論的には必要でないであろう（またはＰＰＰＰはＱｏＳ構成によって与えられる優先度レベルによって上書きされる、もしくはその逆であろう）。

【0193】

図１０は、ＱＣＩがアプリケーションおよび送信レイヤ間でインジケータとして使用されて対応するＱｏＳ構成を識別する、第２の実施形態の例示的な実装を示す図である。それから明らかなように、Ｖ２Ｘデータを生成してから、アプリケーションレイヤは、Ｖ２Ｘデータに対する対応する優先度（例えばＰＰＰＰ）の他に上記Ｖ２Ｘデータのために下位レイヤで実施されるものとするＱｏＳ構成を決定する。対応するＱｏＳクラス指示（すなわちＱＣＩ）が送信レイヤにＶ２Ｘデータと共に、の他に任意選択で優先度と共に提供される。次に、送信レイヤは、受け取ったＱＣＩに基づいてＱｏＳ構成および、したがって、対応するＱｏＳパラメータを決定する。ＵＥ自律リソース割当ては、受け取った優先度および決定したＱｏＳ構成のＱｏＳパラメータに基づいて送信レイヤによって行われ、次いでそれに従ってＶ２Ｘデータの実際の送信を行うことができる。

【0194】

代替的に（図１０に図示せず）、データパケット（または、それぞれサイドリンク論理チャネル）のＱｏＳ構成を識別するためのインジケータとしてＱｏＳ構成インジケータを使用する代わりに、上記の点でＰＰＰＰを使用することができる。前に説明したように、ＰＰＰＰはアプリケーションレイヤで生成される車両データの優先度を示し、アプリケーションレイヤＶ２Ｘメッセージ優先度のＰＰＰＰへのマッピングは、例えばＵＥにおける事前設定に基づく。次いで、送信レイヤはアプリケーションレイヤから車両データの他にＰＰＰＰを受け取り、それを基礎として、上記Ｖ２Ｘデータの送信にどのＱｏＳ構成が適用されることになるかを決定する。異なるＰＰＰＰ値とＱｏＳ構成との間の適切なマッピングは、例えばＵＥにおける事前設定に基づくことができる。別のオプションは、ＰＰＰＰ−ＱｏＳ構成マッピングがｅＮｏｄｅＢによってブロードキャストされる対応するシステム情報ブロックで受信される、またはｅＮＢから個別シグナリングを介して受信されることである。代替的に、ＰＰＰＰ−ＱｏＳクラスマッピングはアプリケーションレイヤから送信レイヤに提供されることができる。

【0195】

１つの例では、指示は（ＱｏＳ構成インジケータであろうとＰＰＰＰであろうと）、あらゆるパケットとアプリケーションレイヤから送信レイヤに転送されることができる。

【0196】

以上の説明は、送信されることになる車両データに基づいてＱｏＳが決定されるようなものである。しかしながら、第２の実施形態の実装は、ＱｏＳ構成がそれぞれのサイドリンク論理チャネルに適用されることになるという点でも見ることができる。特に、車両データは、例えば、同じ優先度を有する（かつ同じソースおよび宛先ＩＤを有する）車両データが同じサイドリンク論理チャネルによって扱われるようにそれらの優先度によって区別される異なるサイドリンク論理チャネルを通じて扱われる。ＱｏＳは、通例はベアラ／論理チャネル特定レベルに適用される概念として見なすことができる。結果的に、ＱｏＳ（構成）が適用されることになるサイドリンク論理チャネルを送信レイヤが識別するとも言われていてもよい。

【0197】

異なるサイドリンク論理チャネルのデータが、例えばサイドリンク論理チャネル手順の間に１つのＴＢに多重化される場合、無線リソース選択およびＰＣ５インタフェースを通じたトランスポートブロックの以降の送信のために使用されるＱｏＳパラメータ、例えばパケット遅延バジェットまたは信頼性は、最高優先度を有する論理チャネルに基づいて選択されるべきである。代替的に、無線リソース選択およびトランスポートブロックの以降の送信のために使用されるＱｏＳパラメータは、最も厳しい要件を有するＱｏＳパラメータに基づく、すなわち関与する論理チャネルの最小パケット遅延バジェットを使用するべきである。

【0198】

いかなる場合にも、送信レイヤは、Ｖ２Ｘデータの送信のために満たされるべきである関連するＱｏＳパラメータを得る。送信レイヤ（例えば、特にＭＡＣおよび物理レイヤ）は、したがって、ＱｏＳパラメータを考慮して、モード２無線リソース割当ておよびＶ２Ｘデータの実際の送信も行うことができる。異なるＱｏＳパラメータをどのように考慮することができるかに関する詳細は、第１の実施形態に関連して既に提供されている。要するに、変調方式および／または符号化率は、パケット誤り損失率が満たされるように選択されることができる。パケット誤り損失率は、１つのトランスポートブロックのための総送信数を決定する重要なパラメータである。パケット遅延バジェットは、無線リソース割当ての間、既に得られた検知結果に基づいて利用可能なリソースを決定するために使用されることができ、それによってデータパケットの送信がパケット遅延バジェット内で起こるものとすることを考慮する。さらには、失効データパケットの廃棄は、パケット遅延バジェットにも依存することができる。ＱｏＳ構成の優先度レベル、または代替的にＰＰＰＰは、例えばサイドリンク論理チャネル優先順位付け手順内で、無線リソースを割り当てるときにサイドリンク論理チャネルに優先順位を付けるように使用される。

【0199】

第２の実施形態のさらなる実装によれば、車両ＵＥは、ＵＥ−ＰＣ５−ＡＭＢＲ（サイドリンクインタフェースのための総最大ビットレート）に関する情報が提供されてもよい。第１の実施形態に関連して既に説明したように、ＵＥ−ＰＣ５−ＡＭＢＲは、サイドリンクインタフェースを通じた送信のためにＵＥに対して許容される最大総データスループットとして理解することができる。車両ＵＥが、例えばＱｏＳ構成を通知するシステム情報ブロードキャスト内でなど、どのようにＵＥ−ＰＣ５−ＡＭＢＲを提供されることができるかに関していくつかの可能性がある。代替的に、ＵＥ−ＰＣ５−ＡＭＢＲは、例えばアタッチ手順の間にｅＮＢから対応する個別メッセージで車両ＵＥに提供されることができ、詳細については、第１の実施形態のために作成された対応するくだりを参照のこと。ＵＥ−ＰＣ５−ＡＭＢＲは、サイドリンクインタフェースを介して送信されることになるデータ量を制限するようにサイドリンク論理チャネル優先順位付け手順でパラメータとして使用されることができる。第１の実施形態に関して既に説明したように、パラメータは、トークンバケットアルゴリズムでパラメータとして使用されてもよい。サイドリンクＬＣＰ手順のためのそのようなトークンバケットアルゴリズムの１つの具体的で例示的な実装が第１の実施形態に関連して提示されており、第２の実施形態の文脈でも使用されることができる。

【0200】

結果的に、リソース割当てモード１で、ＱｏＳ処理が上記の点を担うｅＮＢに委ねられているのに対して、第２の実施形態は、ＰＣ５インタフェースを介して車両データを送信するときに車両ＵＥによって行われるＵＥ自律リソース割当てモード２に対してもＱｏＳ処理をサポートすることが可能である解決策を提供する。

【0201】

（第３の実施形態）
以下に、第３の実施形態を提示し、第１および２の実施形態によって解決されるもの、すなわち詳細な説明の始めで説明したものと同じ課題、すなわち、特に車両ＵＥが自律無線リソース割当てを行っている、サイドリンクインタフェースを介する車両通信のためのサービス品質サポートを実装する仕方を取り扱う。第３の実施形態に関して、ＱｏＳサポートが主にモード１リソース割当てによって提供される一方で、モード２に係るＵＥ自律リソース割当てが必ずしもＱｏＳ要件の充足をサポートするわけではないことを例示的に前提とする。特に、１つの例示的な前提は、例えば、無線リソースを要求するときにスケジューリング要求および／またはバッファ状況報告と共に車両ＵＥによって送信されるＰＰＰＰから、ｅＮｏｄｅＢが車両データに対するＱｏＳパラメータを決定する、モード１リソース割当てで、ＱｏＳサポートが主に適用されるということである。受信したＰＰＰＰおよびＱｏＳパラメータ（例えば対応するＱｏＳ構成の）との間の対応するマッピングを、例えばｅＮｏｄｅＢに予め設定することができる。この例示的な前提によれば、車両ＵＥは、しかしながら、ＱｏＳパラメータに関する必要な情報が提供されず、そのため車両ＵＥは、ＵＥ自律リソース割当て（モード２）を行うときにデータのＱｏＳ要件を考慮することができない。

【0202】

第３の実施形態によれば、車両ＵＥは、両リソース割当てモードをサポートし、送信されることになる車両データに応じて無線リソース割当てを行うようにさらに構成される。より詳細に、背景で説明したように、先行技術では、車両ＵＥは、ｅＮｏｄｅＢからの構成に従って（例えば対応するＵＥ自律モード２リソースプールの存在を基礎として）どちらの無線リソース割当てを適用するべきかを決定する。代替的に、ＵＥがどのリソース割当てモードを使用するつもりであるかは、ＲＲＣ状態（すなわち車両ＵＥがＲＲＣ接続されているか否か）に依存、またはＵＥのカバレージ状態（すなわちカバレージ内、カバレージ外）に依存してもよい。他方で、第３の実施形態は、異なるデータを区別し、モード１リソース割当てまたはモード２リソース割当てを選択的に適用することによって解決策を提供する。

【0203】

要するに、車両ＵＥ（例えばアプリケーションレイヤ）は、送信されることになる車両データを生成し、それを実際の送信の役割を担う送信レイヤに渡す。車両データ（例えばそのデータに対してＱｏＳがサポートされるべきであるか否かを問わず）に応じて、適切な無線リソース割当てモードが選択され、次いで選択されたリソース割当て手順が行われて適切な送信パラメータを得る。例えば、特定の車両データに対してＱｏＳがサポートされるべきであれば、車両ＵＥはモード１リソース割当てを選択し、対応して、特定の車両データのＱｏＳ要件を考慮して送信パラメータを決定するｅＮｏｄｅＢに無線リソースを要求するであろう。他方で、特定の車両データに対してＱｏＳがサポートされるべきでなければ、車両ＵＥはモード２リソース割当てを選択し、送信パラメータ自体を自律的に決定するであろう。いずれの場合にも、得られた送信パラメータで、送信レイヤは次いでデータの送信を行う。結果的に、モード１無線リソース割当て（特定のＱｏＳ要件を満たすことができるため）かまたはモード２無線リソース割当て（特定のＱｏＳがサポートされるべきでない場合）かいずれかを行うことによって特定の車両データ送信にＱｏＳサポートを選択的に適用することが可能である。

【0204】

図１１は、第３の実施形態の実装を例示的に示す図である。それから明らかなように、送信レイヤは、Ｖ２Ｘデータに基づいて、例えば適切なマッピングに基づいてモード１またはモード２いずれのリソース割当てを使用するかを決定する役割を担う。結果として、送信レイヤは次いで、上記決定したように対応するモード１またはモード２リソース割当てを行い、次いでリソース割当てによって得られる送信パラメータに従ってＶ２Ｘデータを送信し始める。

【0205】

第３の実施形態の例示的な実装では、使用されることになる適切な無線リソース割当てモードの選択は、アプリケーションレイヤからの指示に基づくことができる。言い換えると、車両データを生成するアプリケーションレイヤは、特定の車両データに対してＱｏＳが適用されるものであるか否かを示すことになる。対応して、適切なＱｏＳサポート指示が役割を担う送信レイヤに車両データと共に転送され、送信レイヤは次いで、受け取った指示に従って、対応する無線リソース割当て（モード１またはモード２に係る）を行って必要な送信パラメータを得る。１つの例示的な実装では、車両データと共に下位レイヤに転送されるＱｏＳサポート指示としてフラグが使用され得る。

【0206】

別の例示的な実装では、ＰＰＰＰは、モード１かまたはモード２かいずれかの無線リソース割当てモードと特定のＰＰＰＰ値を関連づけることによって、ＱｏＳサポート指示として使用することができる。同様に、ＰＰＰＰ当たり１つのサイドリンク論理チャネルがあるようにＰＰＰＰ（同じソース宛先ＩＤのための）を考慮してサイドリンク論理チャネルが設定されることを考慮すれば、一定のサイドリンク論理チャネルが、ＱｏＳ準拠を保証するためにモード１リソース割当てを使用するように構成されることができる一方で、他のサイドリンク論理チャネルは、特定のＱｏＳ要件の充足が保証されないモード２リソース割当てを使用するように構成されることになる。言い換えると、車両ＵＥは、送信のために利用可能なデータを有するサイドリンク論理チャネルに基づいて、適用されることになる無線リソース割当てモードを決定する。

【0207】

どの論理チャネル（ないしＰＰＰＰまたは特定の固有データ）をどのリソース割当てモードを使用するように構成するかの仕方に関するいくつかの可能性がある。適切なマッピングが上位のレイヤ（車両データを生成するアプリケーションレイヤ）によって規定されるか、またはｅＮｏｄｅＢによって構成されることもできる。例えば、ｅＮｏｄｅＢは、その無線セルで、セルにおけるすべての車両ＵＥによって得られるように適切なマッピングをブロードキャストしてもよく、またはｅＮｏｄｅＢは、上記の点で車両ＵＥに別々に個別メッセージを送信してもよい。例として、一定の高優先度車両サービス（セキュリティ関連送信または音声通話関連送信など）は、ＱｏＳサポート（例えば短パケット遅延バジェットまたは低パケット誤り損失率）付きで送信されるように構成してもよく、したがってモード１無線リソース割当てモードを使用して送信されるべきである。反対に、他の車両のサービスはＱｏＳサポートから恩恵をうけなくてもよく、したがってモード２に係るリソース割当てで十分であろう。

【0208】

結果として、無線リソース割当てモードに応じて、車両ＵＥは最初にｅＮｏｄｅＢに接続されなければならないことがある。特に、モード１無線リソース割当てが行われることになるサイドリンク論理チャネルの車両データを送信するとき、車両ＵＥはｅＮｏｄｅＢと接続されなければならず（スケジューリング要求および／またはバッファ状況報告を送信することができるために）、したがってまだｅＮｏｄｅＢに接続されてなければｅＮｏｄｅＢとのＲＲＣ接続を最初に設定しなければならない。次いで、送信装置は、例えば最初にスケジューリング要求を送信し、適切な周波数時間無線リソースが提供されることに応じて、送信されることになる車両データ量（モード１リソース割当てと関連づけられたサイドリンク論理チャネルに対してのみ）を示すサイドリンクバッファ状況報告を送信することを含め、無線基地局に送信パラメータを要求することによって、通例のようにモード１リソース割当てを行ってもよい。前述したように、ｅＮｏｄｅＢは、上記の点で適切な送信パラメータを選択することによって車両データに関連してＱｏＳ要件を扱う役割を担う。送信パラメータ（例えば、周波数時間リソース、変調および符号化方式、任意選択でトランスポートブロックのために行われることになる総送信数）は次いで、送信レイヤによって使用されて車両データの送信を行う。

【0209】

結果的に、第３の実施形態によれば、モード１ないしモード２リソース割当てはデータに応じて行われ、したがってＱｏＳはデータに応じて（または、換言すれば、データを扱うサイドリンク論理チャネルに応じて）選択的にサポートされる。したがって、モード２無線リソース割当て自体がＱｏＳをサポートするのに適切でない場合でさえ、特定の車両データ（すなわちＱｏＳから恩恵をうける）のための一貫したＱｏＳサポートを実装することが可能である。

【0210】

結果として、ＵＥが同時に、すなわち１つのサブフレームで２つ以上の別々のトランスポートブロックを送信するときに（例えばＭＩＭＯを使用するときに、またはキャリアアグリゲーションを使用するときに）、両無線リソース割当てを行うことが可能であり得る。

【0211】

その上、第３の実施形態によれば、構成したサイドリンク論理チャネルが場合により異なる無線リソース割当てモードと関連づけられることを考慮すると、サイドリンク論理チャネル優先順位付け手順は、上記の点で適合される必要がある。特に、対応する送信パラメータ（割り当てられることになる周波数時間リソースを含む）が提供された後に、送信レイヤは通例、送信のために利用可能なデータを有するサイドリンク論理チャネルにその受け取った周波数時間無線リソースを割り当てるようにサイドリンク論理チャネル優先順位付け手順を行う。この場合、しかしながら、サイドリンクＬＣＰ手順は、サイドリンクＬＣＰ手順によって割り当てられることになる周波数時間無線リソースを提供したリソース割当てモードに関連づけられるサイドリンク論理チャネルのみを考慮するものとする。例えば、車両ＵＥがモード１無線リソース割当てを行い、対応してｅＮｏｄｅＢから送信パラメータを受信したことを前提とすると、以降のサイドリンクＬＣＰ手順は、利用可能な周波数時間無線リソースが優先度ベースでモード１サイドリンク論理チャネルに割り当てられるように、モード１無線リソース割当てと関連づけられるサイドリンク論理チャネルのみを考慮するべきである。反対に、車両ＵＥがモード２無線リソース割当てを行い、対応して送信パラメータを自律的に決定したことを前提とすると、以降のサイドリンクＬＣＰ手順は、利用可能な周波数時間無線リソースが優先度ベースでモード２サイドリンク論理チャネルに割り当てられるように、モード２無線リソース割当てと関連づけられるサイドリンク論理チャネルのみを考慮するべきである。

【0212】

例示的な実装が２つの別々のＭＡＣエンティティを予期してもよく、一方がモード１サイドリンク論理チャネルのためのサイドリンクＬＣＰ手順を行う役割を担い、もう一方がモード２サイドリンク論理チャネルのためのサイドリンクＬＣＰ手順を行う役割を担う。代替的に、車両ＵＥに１つのＭＡＣエンティティだけが設けられてもよく、次いで必要に応じてモード１かまたはモード２かいずれかのサイドリンク論理チャネルのためのサイドリンクＬＣＰ手順を行う役割を交互に担う。

【0213】

（第４の実施形態）
以下に、第４の実施形態を提示し、先の実施形態によって解決されるものと同様の課題を取り扱う。特に、サイドリンクインタフェースを介する車両データの送信のための改善されたＱｏＳサポートが提供されるものとする。

【0214】

第１および第２の実施形態の具体的な実装では、さらなるＱｏＳパラメータ（ＵＥ−ＰＣ５−ＡＭＢＲ（サイドリンクインタフェースのための総最大ビットレート））は、ＵＥ自律リソース割当てのために使用される、特に車両ＵＥによって行われて、送信のために利用可能な車両データを有する様々なサイドリンク論理チャネルに無線リソースを割り当てるサイドリンク論理チャネル優先順位付け手順で使用されると考えられた。

【0215】

第４の実施形態によれば、さらなるＱｏＳパラメータ、すなわちＶ２Ｘ固有ＵＥ−ＰＣ５−ＡＭＢＲが予期され、サイドリンクインタフェースを通じた車両データの送信のためにＵＥに対して許容される最大スループットを規定する。対応して、ＵＥは、サイドリンクインタフェースを介して車両データを送信するときに特定の平均、最大ビットレートに制限される。前述のＵＥ−ＰＣ５−ＡＭＢＲとは異なり、この新たなＱｏＳパラメータ（例えばＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲと名付けられてもよい）は車両データを、すなわち車両データを通知するサイドリンク論理チャネルを指すのみであり、それは、サイドリンクインタフェースを介する非車両データの送信のスループットを制限するために適用されるべきではない。ＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲは、したがって、ＵＥに、サイドリンクインタフェースに、他にＶ２Ｘサイドリンク論理チャネルに固有である。

【0216】

ＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲは様々な方途で車両ＵＥに提供することができる。第４の実施形態の例示的な実装によれば、ｅＮｏｄｅＢは、例えばアタッチ手順の間に対応する個別メッセージでパラメータを送信することができる（第１および第２の実施形態におけるパラメータＵＥ−ＰＣ５−ＡＭＢＲに対して記載したのと同様にして）。特に、アタッチ手順の間に、ＭＭＥは、ＨＳＳからのＵＥ加入契約およびネットワーク事業者のポリシーに従ってＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲを得る。ＭＭＥは次いで、ＵＥのための初期コンテキスト設定手順の間にこの情報をｅＮｏｄｅＢに転送することができ、ｅＮｏｄｅＢは次いで、ブロードキャストかまたは個別かいずれかのメッセージで情報をさらにＵＥに転送することができる。代替的に、ＵＥは、何らかの事前設定に基づいて上位レイヤ（アプリケーション）からＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲが提供されることができる。

【0217】

ＵＥ−ＰＣ５−ＡＭＢＲの代わりに、新たなＱｏＳパラメータＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲは、サイドリンク論理チャネル優先順位付け手順の間に、サイドリンクインタフェースを介してＵＥによって送信されることができる時間当たりの車両データ量を制限するように使用されることができる。１つの例示的な実装では、上記の点でトークンバケットアルゴリズムを使用することができる。車両データを通知するサイドリンク論理チャネルに対してトークンバケットが規定されることができ、そのため無線リソースは、バケットが空でない（すなわち＞０）限り、Ｖ２Ｘサイドリンク論理チャネルに割り当てられることができるだけである。しかしながら、トークンバケットアルゴリズムを使用しない他の実装もＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲパラメータによって与えられる制限を適用すると予期されてもよい。そのような適合サイドリンクＬＣＰ手順の具体的で例示的な実装を以下に与える。対応する下位レイヤ（すなわちＭＡＣ）は、以下のステップで（関連する車両）サイドリンク論理チャネルにリソースを割り当てるものとする：
１．どちらが先にせよサイドリンク論理チャネルのためのデータかもしくはＳＬグラントかいずれかが尽きる、またはバケットが空であるまで、送信のために利用可能なデータを有するすべてのサイドリンク論理チャネルが優先度の降順に扱われる。
２．ＭＡＣエンティティが、上記ステップで車両サイドリンク論理チャネルに対して扱われるＭＡＣ ＳＤＵの総サイズだけバケットレベルをデクリメントするものとする。

【0218】

ＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲは、例えばＭＣＰＴＴ、ミッションクリティカルプッシュツートークのデータを通知するサイドリンク論理チャネルなどの、非車両サイドリンク論理チャネルに関してサイドリンク論理チャネル優先順位付け手順で考慮されないことになる。換言すれば、非車両データの送信のための制限がないことになり、サイドリンクＬＣＰ手順は、利用可能な周波数時間無線リソースをそのような制限なく非車両サイドリンク論理チャネルに割り当てることになる。代替的に、前述のＵＥ−ＰＣ５−ＡＭＢＲは、サイドリンクＬＣＰ手順の間、非車両データのスループットを制限するために使用され得る。第１の実施形態に関連して上記記述を参照する。

【0219】

実施形態に係るＵＥは、ＵＥがＰＣ５インタフェースでの送信のために同時に確立される車両および非車両サイドリンク論理チャネル（例えばＭＣＰＴＴトラヒックまたは音声通話）を有する場合には、１つのトランスポートブロック（ＴＢ）に車両および非車両データを多重化しないことになる。それゆえ、実装によれば、ＵＥは、リソース選択および論理チャネル優先順位付け手順を行うときに、一定のサイドリンク論理チャネルのみ−すべての車両かまたはすべての非車両かいずれかのサイドリンク論理チャネルのみを考慮することになる。その目的で、下位レイヤは、どのサイドリンク論理チャネルが車両サイドリンク論理チャネルまたは非車両サイドリンク論理チャネルであるか、ないしアプリケーションレイヤによって提供されるデータパケットが車両データを通知するか非車両データを通知するかを認識しているべきである。この情報は、１つの例示的な実装によれば、例えばデータパケットと共にアプリケーションレイヤによって下位（送信）レイヤに提供される。代替的に、ＰＰＰＰは、データパケットが車両／非車両データを含むかどうか、すなわち一定のＰＰＰＰ値が車両データのために予約されているかどうかを示し得る。別の代替例として、ソースレイヤ２ＩＤまたは宛先レイヤ２ＩＤは、サイドリンク論理チャネルのデータパケットが車両／非車両データを通知しているかどうかを示し得る。

【0220】

車両ＵＥは、したがって、モード２無線リソース割当てに対してもＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲパラメータを実施することができる。

【0221】

（さらなる実施形態）
Ｖ２Ｘデータがサイドリンクインタフェースを介して送信されることになるシナリオに対してＱｏＳサポートを実装する仕方に関して４つの異なる実施形態を以上記載した。以下に説明するように、以上の様々な実施形態は互いに組み合わされてもよい。

【0222】

第４の実施形態は、ＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲ（すなわちＰＣ５インタフェースを介する車両データ送信のためのＶ２Ｘ固有総最大ビットレート）を追加的に考慮することによって、車両ＵＥによって行われるサイドリンクＬＣＰ手順を改善する。第４の実施形態のこの改善は、第１、第２および第３の実施形態のいずれとも組み合わされることができる。

【0223】

例えば、第１および第２の実施形態において、ＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲは、車両ＵＥが、様々なＶ２Ｘサイドリンク論理チャネルに周波数時間無線リソース（例えば第１／第２の実施形態に従って無線リソース割当てを行うことによって得られる）を割り当てるときに追加的に考慮することになるパラメータであろう。ＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲは、第１の実施形態で説明したＵＥ−ＰＣ５−ＡＭＢＲを置き換え得るか、またはサイドリンクＬＣＰ手順の間、車両データの送信スループットを制限するために使用されてもよい一方で、ＵＥ−ＰＣ５−ＡＭＢＲパラメータが非車両データの送信スループットを制限するために使用され得る。

【0224】

その上、第３の実施形態に関して、ＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲは、ｅＮｏｄｅＢから対応する送信パラメータを得た後に車両ＵＥによって行われるサイドリンク論理チャネル優先順位付け手順で使用されてもよい。モード１リソース割当てに関して、ＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲによって与えられる対応する制限がｅＮｏｄｅＢによって既に適用されることを前提としてもよいとは言え、車両ＵＥによって行われるサイドリンクＬＣＰ手順に対応する制限を実装することも等しく可能である。同様に、モード２リソース割当てに関して、他のいかなるＱｏＳパラメータもリソース割当ての間に考慮されなかったとは言え、ＵＥ−ＰＣ５−Ｖ２Ｘ−ＡＭＢＲはサイドリンクＬＣＰ手順で依然として使用され得る。

【0225】

第３の実施形態は基本的に、リソース割当てが送信されることになるデータに依存しているのを許容する、または換言すれば、リソース割当てが特定のサイドリンク論理チャネルに固有であることができる解決策を提供する。それによって、特定のデータのためのＱｏＳ要件を実施することが、そのデータ（または、むしろ対応するサイドリンク論理チャネル）をモード１リソース割当てと関連づけることによって可能であり、第３の実施形態において、モード２リソース割当てがＱｏＳをサポートしない−または、少なくとも限られた方式でのみサポートする−ことを例示的に前提とする。第１および第２の実施形態を第３の実施形態と組み合わせることが可能である。第１および第２の実施形態が、車両ＵＥによって行われるモード２リソース割当てもＱｏＳパラメータを考慮する解決策を提供するとは言え、車両ＵＥが特定の車両データに対して特定のリソース割当てモードを行うように、車両ＵＥの制御権を有することは依然としてｅＮｏｄｅＢの関心であろう。さらには、第３の実施形態に関連して言及したＱｏＳサポート指示は、第１の実施形態の様々な実装での下位レイヤに車両データと共に転送されるさらなるＱｏＳパラメータとして見なすことができる。他方で、第２の実施形態に関しては、リソースモード指示は、ＱｏＳクラス／構成におけるさらなるＱｏＳパラメータであり得る。対応して、第１および第２の両実施形態において、送信レイヤは、ＱｏＳパラメータによって示される対応するリソース割当てモードを行うことになる。

【0226】

（さらなる実施形態）
第１の態様によれば、１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するために送信装置が提供される。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。送信装置のアプリケーションレイヤが、車両データを生成し、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに優先度指示および１つまたは複数のサービス品質パラメータと共に車両データを転送する。送信レイヤは、受け取った優先度指示および１つまたは複数のサービス品質パラメータに基づいて自律無線リソース割当てを行う。送信レイヤは、行った自律無線リソース割当てに従って１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信する。

【0227】

第１の態様に加えて提供される第２の態様によれば、１つまたは複数のサービス品質パラメータは：
− パケット遅延バジェット：送信のために利用可能になってから車両データを送信するために許容される上限時間を示す
− パケット誤り損失率：損失車両データの許容率を示す
− リソース型：保証ビットレートを有するまたは有しない、の少なくとも１つを示す。

【0228】

第１〜第２の態様の１つに加えて提供される第３の態様によれば、車両データの送信のために自律無線リソース割当てを行うことは：
− 周波数時間無線リソースを選択すること、ならびに／または
− 任意選択でパケット誤り損失率に基づいて、変調および符号化方式を選択すること、ならびに／または
− 任意選択でパケット誤り損失率に基づいて、車両データの送信数を示す反復数を決定すること、から成る。

【0229】

第１〜第３の態様の１つに加えて第４の態様によれば、送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当ておよび無線基地局制御無線リソース割当てをサポートする。送信装置は、送信されることになるデータに応じて自律無線リソース割当ておよび無線基地局制御無線リソース割当てを行うように構成される。送信レイヤは、車両データに応じて車両データを送信するためにどちらの無線リソース割当てを使用するべきかを決定する。送信レイヤは、自律無線リソース割当てを行い、行った自律無線リソース割当てに従って車両データを送信する。

【0230】

第１〜第４の態様の１つに加えて第５の態様によれば、送信装置に対して総最大ビットレートが規定され、サイドリンクインタフェースを介する送信装置の最大許容総データスループットを示す。任意選択で、総最大ビットレートは、送信装置を制御する無線基地局によって設定される。総最大ビットレートは、サイドリンク論理チャネル優先順位付け手順のために、サイドリンクインタフェースを介する送信装置によるデータスループットの量に対する制限として使用され、サイドリンク論理チャネル優先順位付け手順は、送信装置によって、無線リソースを割り当てて、車両データを通知するデータパケットを生成するために行われる。

【0231】

第１〜第５の態様の１つに加えて第６の態様によれば、送信装置は、車両データに対してパケット遅延バジェットが超過されるかどうかを決定し、陽性の場合、車両データを廃棄する。

【0232】

第７の態様によれば、送信装置から１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するために方法が提供される。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。方法は、送信装置によって行われる以下のステップを含む。車両データは、アプリケーションレイヤで生成され、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに優先度指示および１つまたは複数のサービス品質パラメータと共に転送される。送信レイヤは、受け取った優先度指示および１つまたは複数のサービス品質パラメータに基づいて自律無線リソース割当てを行う。送信レイヤは、行った自律無線リソース割当てに従って１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信する。

【0233】

第７の態様に加えて第８の態様によれば、１つまたは複数のサービス品質パラメータは：
− パケット遅延バジェット：送信のために利用可能になってから車両データを送信するために許容される上限時間を示す
− パケット誤り損失率：損失車両データの許容率を示す
− リソース型：保証ビットレートを有するまたは有しない、の少なくとも１つを示す。

【0234】

第７または第８の態様に加えて第９の態様によれば、車両データの送信のための自律無線リソース割当てを行うことは：
− 周波数時間無線リソースを選択すること、ならびに／または
− 任意選択でパケット誤り損失率に基づいて、変調および符号化方式を選択すること、ならびに／または
− 任意選択でパケット誤り損失率に基づいて、車両データの送信数を示す反復数を決定すること、から成る。

【0235】

第７〜第９の態様の１つに加えて第１０の態様によれば、送信装置に対して総最大ビットレートが規定され、サイドリンクインタフェースを介する送信装置の最大許容総データスループットを示す。任意選択で、総最大ビットレートは、送信装置を制御する無線基地局によって設定される。総最大ビットレートは、サイドリンク論理チャネル優先順位付け手順のために、サイドリンクインタフェースを介する送信装置によるデータスループットの量に対する制限として使用され、サイドリンク論理チャネル優先順位付け手順は、送信装置によって、無線リソースを割り当てて、車両データを通知するデータパケットを生成するために行われる。

【0236】

第７〜第１０の態様の１つに加えて第１１の態様によれば、方法は、送信装置によって、車両データに対してパケット遅延バジェットが超過されるかどうかを決定し、陽性の場合、車両データを廃棄するステップをさらに含む。

【0237】

第１２の態様によれば、１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するために送信装置が提供される。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。送信装置の受信器が、無線基地局によってその無線セルでブロードキャストされるシステム情報を受信し、システム情報は１つまたは複数のサービス品質構成から成る。送信装置のアプリケーションレイヤが、車両データを生成し、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに指示と共に生成した車両データを転送する。送信レイヤは、車両データと共に受け取った指示に応じて、受け取った１つまたは複数のサービス品質構成の１つを決定する。送信レイヤは、決定した１つのサービス品質構成に基づいて自律無線リソース割当てを行う。送信レイヤは、行った自律無線リソース割当てに従って１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信する。

【0238】

第１２の態様に加えて提供される第１３の態様によれば、システム情報は車両通信に固有のシステム情報ブロックで受信される。

【0239】

第１２または第１３の態様に加えて提供される第１４の態様によれば、１つまたは複数のサービス品質構成の各々は：
− パケット遅延バジェット：送信のために利用可能になってから車両データを送信するために許容される上限時間を示す
− パケット誤り損失率：損失車両データの許容率を示す
− リソース型：保証ビットレートを有するまたは有しない、の少なくとも１つを示す。

【0240】

第１２〜第１４の態様の１つに加えて提供される第１５の態様によれば、システム情報は総最大ビットレートをさらに含み、サイドリンクインタフェースを介する送信装置の最大許容総データスループットを示す。総最大ビットレートは、サイドリンク論理チャネル優先順位付け手順のために、サイドリンクインタフェースを介する送信装置によるデータスループットの量に対する制限として使用され、サイドリンク論理チャネル優先順位付け手順は、送信装置によって、無線リソースを割り当てて、車両データを通知するデータパケットを生成するために行われる。

【0241】

第１２〜第１５の態様の１つに加えて提供される第１６の態様によれば、送信レイヤに車両データと共に送られる指示は優先度指示であり、車両データの優先度を示す。送信レイヤは、受け取った優先度指示、および１つまたは複数のサービス品質構成の各々を優先度指示値と関連づける、送信装置に記憶されるマッピングを使用して１つのサービス品質構成を決定する。任意選択で、マッピングは、無線基地局によってその無線セルでブロードキャストされる、またはアプリケーションレイヤによって提供されるシステム情報で受け取られる。

【0242】

第１２〜第１６の態様の１つに加えて提供される第１７の態様によれば、アプリケーションレイヤは、どのサービス品質構成を使用するべきかを決定し、決定した１つのサービス品質構成を示すサービス品質クラス指示を生成する。送信レイヤに車両データと共に送られる指示は、生成されたサービス品質クラス指示である。任意選択で、送信レイヤに車両データと共に優先度指示が送られ、優先度指示が車両データの優先度を示す。

【0243】

第１８の態様によれば、送信装置から１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するために方法が提供される。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。方法は、送信装置によって行われる以下のステップを含む。無線基地局によってその無線セルでブロードキャストされるシステム情報が送信装置によって受信され、システム情報は１つまたは複数のサービス品質構成から成る。アプリケーションレイヤが、車両データを生成し、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに指示と共に生成した車両データを転送する。送信レイヤは、車両データと共に受け取った指示に応じて、受け取った１つまたは複数のサービス品質構成の１つを決定し、決定した１つのサービス品質構成に基づいて自律無線リソース割当てを行う。車両データは、行われた自律無線リソース割当てに従って１つまたは複数の受信装置にサイドリンクインタフェースを介して送信される。

【0244】

第１８の態様に加えて提供される第１９の態様によれば、１つまたは複数のサービス品質構成の各々は：
− パケット遅延バジェット：送信のために利用可能になってから車両データを送信するために許容される上限時間を示す
− パケット誤り損失率：損失車両データの許容率を示す
− リソース型：保証ビットレートを有するまたは有しない、の少なくとも１つを示す。

【0245】

第１８または第１９の態様に加えて提供される第２０の態様によれば、システム情報は総最大ビットレートをさらに含み、サイドリンクインタフェースを介する送信装置の最大許容総データスループットを示す。総最大ビットレートは、サイドリンク論理チャネル優先順位付け手順のために、サイドリンクインタフェースを介する送信装置によるデータスループットの量に対する制限として使用され、サイドリンク論理チャネル優先順位付け手順は、送信装置によって、無線リソースを割り当てて、車両データを通知するデータパケットを生成するために行われる。第１８〜２０の態様の１つに加えて提供される２１の態様によれば、送信レイヤに車両データと共に送られる指示は優先度指示であり、車両データの優先度を示す。送信レイヤは、受け取った優先度指示、および１つまたは複数のサービス品質構成の各々を優先度指示値と関連づける、送信装置に記憶されるマッピングを使用して１つのサービス品質構成を決定する。任意選択で、マッピングは、無線基地局によってその無線セルでブロードキャストされる、またはアプリケーションレイヤによって提供されるシステム情報で受け取られる。

【0246】

第１８〜第２１の態様の１つに加えて提供される第２２の態様によれば、方法は、アプリケーションレイヤによって、どのサービス品質構成を使用するべきかを決定するステップと、アプリケーションレイヤによって、決定した１つのサービス品質構成を示すサービス品質クラス指示を生成するステップとをさらに含む。送信レイヤに車両データと共に送られる指示は、生成されたサービス品質クラス指示である。任意選択で、方法は、送信レイヤに車両データと共に優先度指示を送るステップであって、優先度指示が車両データの優先度を示す、優先度指示を送るステップをさらに含む。

【0247】

第２３の態様によれば、１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するために送信装置が提供される。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当ておよび無線基地局制御無線リソース割当てをサポートする。送信装置は、送信されることになるデータに応じて自律無線リソース割当ておよび無線基地局制御無線リソース割当てを行うように構成される。送信装置のアプリケーションレイヤが第１の車両データおよび第２の車両データを生成する。アプリケーションレイヤは、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに第１および第２の車両データを転送する。送信レイヤは、第１の車両データに応じて第１の車両データを送信するためにどちらの無線リソース割当てを使用するべきかを決定し、第２の車両データに応じて第２の車両データを送信するためにどちらの無線リソース割当てを使用するべきかを決定する。送信レイヤは、第１の車両データのために、決定した無線リソース割当てを行い、決定した無線リソース割当てに従ってサイドリンクインタフェースを介して１つまたは複数の受信装置に第１の車両データを送信する。送信レイヤは、第２の車両データのために、決定した無線リソース割当てを行い、決定した無線リソース割当てに従ってサイドリンクインタフェースを介して１つまたは複数の受信装置に第２の車両データを送信する。

【0248】

第２３の態様に加えて提供される第２４の態様によれば、無線基地局制御無線リソース割当てを行うときにデータの送信の１つまたは複数のサービス品質要件が考慮され、自律無線リソース割当てを行うときに考慮されない。

【0249】

第２３のまたは第２４の態様に加えて提供される第２５の態様によれば、複数のサイドリンク論理チャネルの各々が、自律無線リソース割当てかまたは無線基地局制御無線リソース割当てかいずれかと関連づけられる。送信装置は、車両データが帰属するサイドリンク論理チャネルに基づいて、車両データを送信するためにどちらの無線リソース割当てを使用するべきかを決定する。任意選択で、複数のサイドリンク論理チャネルは、車両データを送信するために設定され、車両データと共にアプリケーションレイヤによって提供される優先度指示に基づいて構成される。

【0250】

第２３〜第２５の態様の１つに加えて提供される第２６の態様によれば、複数のサイドリンク論理チャネルの各々と特定の無線リソース割当てとの間の関連づけは：
− 送信装置を制御する無線基地局であり、任意選択で、無線基地局が、関連づけに関する情報を含むブロードキャストまたは個別メッセージを送信装置に送信する、または
− 送信装置のアプリケーションレイヤ、によって設定される。

【0251】

第２３〜第２６の態様の１つに加えて提供される第２７の態様によれば、車両データの送信のための無線基地局制御無線リソース割当ては：
− 送信装置が無線基地局に接続されていない場合に無線基地局に接続すること、
− スケジューリング要求および／または無線基地局制御無線リソース割当てを使用して送信されることになる車両データ量を示すサイドリンクバッファ状況報告を送信することによって無線基地局に送信パラメータを要求すること、
− 要求に応じて、車両データを送信するための無線基地局からの送信パラメータを受信することであって、任意選択で、送信パラメータが、周波数時間無線リソース、変調および符号化方式、ならびに車両データの送信数を示す反復数の少なくとも１つから成る、送信パラメータを受信すること、から成る。

【0252】

第１の車両データの送信のための自律無線リソース割当ては：
− 周波数時間無線リソースを選択すること、ならびに／または
− 変調および符号化方式を選択すること、ならびに／または
− 車両データの送信数を示す反復数を決定すること、から成る。

【0253】

第２８の態様によれば、送信装置から１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するために方法が提供される。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当ておよび無線基地局制御無線リソース割当てをサポートする。送信装置は、送信されることになるデータに応じて自律無線リソース割当ておよび無線基地局制御無線リソース割当てを行うように構成される。方法は、送信装置によって行われる以下のステップを含む。送信装置のアプリケーションレイヤは、第１の車両データおよび第２の車両データを生成し、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに第１および第２の車両データを転送する。送信装置の送信レイヤは、第１の車両データに応じて第１の車両データを送信するためにどちらの無線リソース割当てを使用するべきかを決定する。さらに、送信レイヤは、第２の車両データに応じて第２の車両データを送信するためにどちらの無線リソース割当てを使用するべきかを決定する。送信レイヤは、第１の車両データのために、決定した無線リソース割当てを行い、決定した無線リソース割当てに従ってサイドリンクインタフェースを介して１つまたは複数の受信装置に第１の車両データを送信する。送信レイヤは、第２の車両データのために、決定した無線リソース割当てを行い、決定した無線リソース割当てに従ってサイドリンクインタフェースを介して１つまたは複数の受信装置に第２の車両データを送信する。

【0254】

第２８の態様に加えて提供される第２９の態様によれば、無線基地局制御無線リソース割当てを行うときにデータの送信の１つまたは複数のサービス品質要件が考慮され、自律無線リソース割当てを行うときに考慮されない。

【0255】

第２８または第２９の態様に加えて提供される第３０の態様によれば、複数のサイドリンク論理チャネルの各々が、自律無線リソース割当てかまたは無線基地局制御無線リソース割当てかいずれかと関連づけられる。方法は、送信装置によって、車両データが帰属するサイドリンク論理チャネルに基づいて、車両データを送信するためにどちらの無線リソース割当てを使用するべきかを決定するステップをさらに含む。任意選択で、複数のサイドリンク論理チャネルは、車両データを送信するために設定され、車両データと共にアプリケーションレイヤによって提供される優先度指示に基づいて構成される。

【0256】

第２８〜第３０の態様の１つに加えて提供される第３１の態様によれば、複数のサイドリンク論理チャネルの各々と特定の無線リソース割当てとの間の関連づけは：
− 送信装置を制御する無線基地局であり、任意選択で無線基地局が、関連づけに関する情報を含むブロードキャストまたは個別メッセージを送信装置に送信する、または
− 送信装置のアプリケーションレイヤ、によって設定される。

【0257】

第２８〜第３１の態様の１つに加えて提供される第３２の態様によれば、車両データの送信のための無線基地局制御無線リソース割当ては：
− 送信装置が無線基地局に接続されていない場合に無線基地局に接続すること、
− スケジューリング要求および／または無線基地局制御無線リソース割当てを使用して送信されることになる車両データ量を示すサイドリンクバッファ状況報告を送信することによって無線基地局に送信パラメータを要求すること、
− 要求に応じて、車両データを送信するための無線基地局からの送信パラメータを受信することであって、任意選択で、送信パラメータが、周波数時間無線リソース、変調および符号化方式、ならびに車両データの送信数を示す反復数の少なくとも１つから成る、送信パラメータを受信すること、から成る。

【0258】

第１の車両データの送信のための自律無線リソース割当ては：
− 周波数時間無線リソースを選択すること、ならびに／または
− 変調および符号化方式を選択すること、ならびに／または
− 車両データの送信数を示す反復数を決定すること、から成る。

【0259】

第３３の態様によれば、１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するために送信装置が提供される。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。送信装置に対して総最大ビットレートが規定され、サイドリンクインタフェースを介する送信装置の最大許容総車両データスループットを示す。送信装置のアプリケーションレイヤが、車両データを生成し、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに車両データを転送する。送信装置の送信レイヤは、周波数−時間無線リソースの選択を含む、車両データのための自律無線リソース割当てを行う。送信レイヤは、選択した周波数−時間無線リソースを割り当てて、車両データを通知するデータパケットを生成するためのサイドリンク論理チャネル優先順位付け手順を行う。サイドリンク論理チャネル手順は総最大ビットレートを、サイドリンクインタフェースを介して送信装置によって送信されることになる車両データのスループットに対する制限として考える。送信レイヤは、割り当てた周波数−時間無線リソースを使用して１つまたは複数の受信装置に、車両データを通知する生成したデータパケットを送信する。

【0260】

第３３の態様に加えて提供される第３４の態様によれば、総最大ビットレートは、サイドリンク論理チャネル優先順位付けにおいて、車両データに対するトークンバケットアルゴリズムにおけるトークンバケットの上限パラメータとして使用される。

【0261】

第３３または第３４の態様に加えて提供される第３５の態様によれば、アプリケーションレイヤは非車両データを生成し、サイドリンク論理チャネル優先順位付け手順は、無線リソースを割り当てて、非車両データを通知するデータパケットを生成するときに総最大ビットレートを考慮しない。

【0262】

第１〜第３５の態様のいずれかに加えて提供される第３６の態様によれば、送信装置は車両移動端末、路側ユニットまたは移動端末である。

【0263】

第３７の態様によれば、送信装置から１つまたは複数の受信装置にサイドリンクインタフェースを介して車両データを送信するために方法が提供される。送信装置は、サイドリンクインタフェースを介して車両データを送信するための自律無線リソース割当てを行う。送信装置に対して総最大ビットレートが規定され、サイドリンクインタフェースを介する送信装置の最大許容総車両データスループットを示す。方法は、送信装置によって行われる以下のステップを含む。送信装置のアプリケーションレイヤが、車両データを生成し、サイドリンクインタフェースを介する車両データの送信の役割を担う送信レイヤに車両データを転送する。送信装置の送信レイヤは、周波数−時間無線リソースの選択を含む、車両データのための自律無線リソース割当てを行う。送信レイヤは、選択した周波数−時間無線リソースを割り当てて、車両データを通知するデータパケットを生成するためのサイドリンク論理チャネル優先順位付け手順を行う。サイドリンク論理チャネル手順は総最大ビットレートを、サイドリンクインタフェースを介して送信装置によって送信されることになる車両データのスループットに対する制限として考える。送信レイヤは、割り当てた周波数−時間無線リソースを使用して１つまたは複数の受信装置に、車両データを通知する生成したデータパケットを送信する。

【0264】

第３７の態様に加えて提供される第３８の態様によれば、総最大ビットレートは、サイドリンク論理チャネル優先順位付けにおいて、車両データに対するトークンバケットアルゴリズムにおけるトークンバケットの上限パラメータとして使用される。

【0265】

第３７または第３８の態様に加えて提供される第３９の態様によれば、アプリケーションレイヤは非車両データを生成し、サイドリンク論理チャネル優先順位付け手順は、無線リソースを割り当てて、非車両データを通知するデータパケットを生成するときに総最大ビットレートを考慮しない。

【0266】

＜本開示のハードウェアおよびソフトウェア実装＞
他の例示的な実施形態は、ハードウェア、ソフトウェア、またはハードウェアと協働したソフトウェアを使用する上記した様々な実施形態の実装に関する。これに関連して、ユーザ端末（移動端末）が提供される。ユーザ端末は、受信器、送信器、プロセッサなど、本明細書に記載した方法に適切に関与する対応するエンティティを含め、同方法を行う。

【0267】

様々な実施形態がコンピューティング装置（プロセッサ）を使用して実装されてもまたは行われてもよいとさらに認識される。コンピューティング装置またはプロセッサは、例えば汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Array）または他のプログラマブル論理装置などでもよい。様々な実施形態はこれらの装置の組合せによって行われてもまたは具象化されてもよい。特に、上記した各実施形態の記載に使用される各機能ブロックは、集積回路としてのＬＳＩによって実現されることができる。それらはチップとして個々に形成されてもよいし、または１つのチップが、機能ブロックの一部または全部を含むように形成されてもよい。それらは、そこに結合されるデータ入出力を含んでもよい。ＬＳＩはここで、集積度の相違に応じて、ＩＣ、システムＬＳＩ、超ＬＳＩまたは極超ＬＳＩと称されてもよい。しかしながら、集積回路を実装する技術はＬＳＩに限定されず、専用回路または汎用プロセッサを使用することによって実現されてもよい。加えて、ＬＳＩの製造後にプログラムされることができるＦＰＧＡ（Field Programmable Gate Array）、またはＬＳＩ内部に設けられる回路セルの接続および設定が再構成されることができる再構成可能プロセッサが使用されてもよい。

【0268】

さらに、様々な実施形態はソフトウェアモジュールを用いて実装されてもよく、ソフトウェアモジュールはプロセッサによってまたはハードウェアで直接実行される。また、ソフトウェアモジュールおよびハードウェア実装の組合せも可能だろう。ソフトウェアモジュールは任意の種類のコンピュータ可読記憶媒体、例えばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに記憶されてもよい。異なる実施形態の個々の特徴が個々にまたは任意の組合せで別の実施形態の主題であることにさらに留意するべきである。

【0269】

当業者によって、多数の変形および／または修正が具体的な実施形態に示すように本開示になされてもよいことが認識されるであろう。本実施形態は、したがって、すべての点で例示的であり限定的でないと考えられるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】