JP6757800B2 - Ｖ２ｖトラフィックのための改善されたセミパーシステントリソース割当て - Google Patents

Description

本開示は、移動端末と無線基地局との間の改善されたセミパーシステントリソース割当てに関する。本開示は、対応する（車両用）移動端末および無線基地局を提供している。

＜ロングタームエボリューション（ＬＴＥ）＞
ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代の移動通信システム（３Ｇ）は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：Ｈｉｇｈ−Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）、および高速アップリンクパケットアクセス（ＨＳＵＰＡ：Ｈｉｇｈ Ｓｐｅｅｄ Ｕｐｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）とも呼ばれるエンハンストアップリンクが導入され、極めて競争力の高い無線アクセス技術を提供している。

ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保するために、３ＧＰＰは、ロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）と称される新しい移動通信システムを導入した。ＬＴＥは、今後１０年間にわたり、高速のデータおよびメディア伝送ならびに大容量の音声サポートのためのキャリアニーズを満たすように設計されている。高いビットレートを提供する能力は、ＬＴＥにおける重要な方策である。

進化したＵＭＴＳ地上無線アクセス（ＵＴＲＡ：ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）およびＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ：ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）と称される、ロングタームエボリューション（ＬＴＥ）に関する作業項目（ＷＩ：ｗｏｒｋ ｉｔｅｍ）の仕様が、リリース８（ＬＴＥリリース８）として確定された。ＬＴＥシステムは、フルＩＰベースの機能性を低遅延かつ低コストで提供する、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークの代表である。ＬＴＥでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、１．４ＭＨｚ、３．０ＭＨｚ、５．０ＭＨｚ、１０．０ＭＨｚ、１５．０ＭＨｚ、および２０．０ＭＨｚなどのスケーラブルな複数の送信帯域幅が指定されている。ダウンリンクでは、低いシンボルレートに起因してマルチパス干渉（ＭＰＩ：ｍｕｌｔｉｐａｔｈ ｉｎｔｅｒｆｅｒｅｎｃｅ）に対する固有の耐性があること、サイクリックプレフィックス（ＣＰ：ｃｙｃｌｉｃ ｐｒｅｆｉｘ）を使用すること、およびさまざまな送信帯域幅配列と相性が良いことから、直交周波数分割多重（ＯＦＤＭ：Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）ベースの無線アクセスが採用された。アップリンクでは、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）の送信電力が限られていることを考慮し、ピークデータレートを向上させるよりも広いエリアカバレッジを提供することが優先されることから、シングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ：Ｓｉｎｇｌｅ−ｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）ベースの無線アクセスが採用された。ＬＴＥリリース８／９では、多入力多出力（ＭＩＭＯ：ｍｕｌｔｉｐｌｅ−ｉｎｐｕｔ ｍｕｌｔｉｐｌｅ−ｏｕｔｐｕｔ）チャネル伝送技術を含んで多くの主要なパケット無線アクセス技術が採用され、高効率の制御シグナリング構造が達成されている。

＜ＬＴＥアーキテクチャ＞
図１に、ＬＴＥアーキテクチャ全体を示している。Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢから構成され、ユーザ機器（ＵＥ）に向かう、Ｅ−ＵＴＲＡのユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルおよび制御プレーン（ＲＲＣ）プロトコルの終端を提供している。ｅＮｏｄｅＢ（ｅＮＢ）は、ユーザプレーンのヘッダ圧縮および暗号化の機能性を含む、物理（ＰＨＹ）レイヤ、媒体アクセス制御（ＭＡＣ：Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ、無線リンク制御（ＲＬＣ：Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤ、およびパケットデータ制御プロトコル（ＰＤＣＰ：Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）レイヤをホストする。ｅＮｏｄｅＢ（ｅＮＢ）は、制御プレーンに対応する無線リソース制御（ＲＲＣ：Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）機能性も提供する。ｅＮｏｄｅＢ（ｅＮＢ）は、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクサービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）の実施、セル情報ブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号化、ならびにダウンリンク／アップリンクのユーザプレーンパケットヘッダの圧縮／復元を含む、多くの機能を実行する。ｅＮｏｄｅＢは、Ｘ２インタフェースによって相互接続されている。

また、複数のｅＮｏｄｅＢは、Ｓ１インタフェースによってＥＰＣ（進化したパケットコア：Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）に、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（移動管理エンティティ：Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）に、およびＳ１−Ｕによってサービングゲートウェイ（ＳＧＷ：Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）に接続されている。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多の関係をサポートする。ＳＧＷは、ｅＮｏｄｅＢ間のハンドオーバ時におけるユーザプレーンのモビリティアンカーとして、およびＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカー（Ｓ４インタフェースを終端させ、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間でトラフィックを中継する）としても機能する一方で、ユーザデータパケットをルーティングして転送する。アイドル状態のユーザ機器に対しては、ＳＧＷは、ダウンリンクデータ経路を終端させ、そのユーザ機器のためのダウンリンクデータが到着したときにページングをトリガする。ＳＧＷは、ユーザ機器のコンテキスト、例えばＩＰベアラサービスのパラメータ、またはネットワーク内部ルーティング情報、を管理する、および格納する。ＳＧＷは、合法傍受（ｌａｗｆｕｌ ｉｎｔｅｒｃｅｐｔｉｏｎ）の場合には、ユーザトラフィックの複製も行う。

ＭＭＥは、ＬＴＥアクセスネットワークのための主要な制御ノードである。ＭＭＥは、再送信を含んで、アイドルモードのユーザ機器の追跡およびページング手順の役割を担う。ＭＭＥは、ベアラのアクティブ化／非アクティブ化プロセスに関与し、最初のアタッチ時およびコアネットワーク（ＣＮ：Ｃｏｒｅ Ｎｅｔｗｏｒｋ）ノードの再配置を伴うＬＴＥ内ハンドオーバ時に、ユーザ機器のためにＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングは、ＭＭＥにおいて終端され、ＭＭＥは、一時的なＩＤを生成してユーザ機器に割り当てる役割も担う。ＭＭＥは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ：Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）にキャンプオンするためにユーザ機器の承認をチェックし、ユーザ機器のローミング制約を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／完全性保護のためのネットワーク内の終端点であり、セキュリティキーの管理を取り扱う。シグナリングの合法的な傍受もＭＭＥによってサポートされる。ＭＭＥは、ＬＴＥのアクセスネットワークと２Ｇ／３Ｇのアクセスネットワークとの間のモビリティのための制御プレーン機能に、ＳＧＳＮからでＭＭＥで終端するＳ３インタフェースも提供する。ＭＭＥは、ユーザ機器をローミングするためのホームＨＳＳに向かうＳ６ａインタフェースも終端させる。

＜ＬＴＥにおけるコンポーネントキャリア構造＞
３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、時間−周波数領域において、いわゆるサブフレームにさらに分割される。３ＧＰＰ ＬＴＥにおいて、各サブフレームは、図２に示すように２つのダウンリンクスロットに分割され、第１のダウンリンクスロットは、第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を含んでいる。各サブフレームは、時間領域内において所与の数のＯＦＤＭシンボルで構成され（３ＧＰＰ ＬＴＥ（リリース８）では１２個または１４個のＯＦＤＭシンボル）、各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に広がる。このように、ＯＦＤＭシンボルそれぞれは、それぞれのサブキャリア上で送信されるいくつかの変調シンボルで構成される。ＬＴＥでは、各スロットにいて送信される信号は、

個のサブキャリアと

個のＯＦＤＭシンボルのリソースグリッドによって記述される。

は、帯域幅内のリソースブロックの数である。

は、セルにおいて設定されているダウンリンク送信帯域幅に依存し、

を満たし、この場合、

および

は、それぞれ、現在のバージョンの仕様によってサポートされている最小ダウンリンク帯域幅および最大ダウンリンク帯域幅である。

は、１つのリソースブロック内のサブキャリアの数である。通常のサイクリックプレフィックスのサブフレーム構造の場合、

および

である。

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

１つのサブフレームは、２つのスロットで構成され、したがって、いわゆる「通常の」ＣＰ（サイクリックプレフィックス）が使用されるときにはサブフレーム内に１４個のＯＦＤＭシンボルが存在し、いわゆる「拡張」ＣＰが使用されるときにはサブフレーム内に１２個のＯＦＤＭシンボルが存在する。専門用語を目的として、以下で、サブフレーム全体に広がる同じ連続するサブキャリアと同等の時間−周波数リソースは、「リソースブロックペア」または同意義の「ＲＢペア」もしくは「ＰＲＢペア」と呼ばれる。

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

コンポーネントキャリア構造に関する同様の想定は、以降のリリースにも適用される。

＜より広い帯域幅のサポートのためのＬＴＥ−Ａにおけるキャリアアグリゲーション＞
世界無線通信会議２００７（ＷＲＣ−０７）において、ＩＭＴ−Ａｄｖａｎｃｅｄの周波数スペクトルが決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、それぞれの地域や国によって異なる。しかしながら、利用可能な周波数スペクトルの概要の決定を受けて、第３世代パートナーシッププロジェクト（３ＧＰＰ：３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において無線インタフェースの標準化が開始された。３ＧＰＰ ＴＳＧ ＲＡＮ ＃３９会合において、「Ｆｕｒｔｈｅｒ Ａｄｖａｎｃｅｍｅｎｔｓ ｆｏｒ Ｅ−ＵＴＲＡ（ＬＴＥ−Ａｄｖａｎｃｅｄ）」に関する検討項目の記述が承認された。この検討項目は、例えば、ＩＭＴ−Ａｄｖａｎｃｅｄの要求条件を満たすために、Ｅ−ＵＴＲＡを進化・発展させるうえで考慮すべき技術要素をカバーしている。

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

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

少なくとも、コンポーネントキャリアの帯域幅が、ＬＴＥリリース８／９のセルのサポートされる帯域幅を超えないときには、すべてのコンポーネントキャリアをＬＴＥリリース８／９互換であるように設定することができる。ユーザ機器によってアグリゲーションされるすべてのコンポーネントキャリアが必ずしもリリース８／９互換である必要はなくてもよい。リリース８／９のユーザ機器がコンポーネントキャリアにキャンプオンすることを回避するため、既存のメカニズム（例えばバーリング）を使用し得る。

ユーザ機器は、自身の能力に応じて１つまたは複数のコンポーネントキャリア（複数のサービングセルに対応する）上で同時に受信または送信し得る。キャリアアグリゲーションのための受信能力および／または送信能力を備えた、ＬＴＥ−Ａリリース１０のユーザ機器は、複数のサービングセル上で同時に受信する、および／または送信することができ、一方で、ＬＴＥリリース８／９のユーザ機器は、コンポーネントキャリアの構造がリリース８／９の仕様に従う限り、１つのサービングセル上でしか受信および送信を行うことができない。

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

同じｅＮｏｄｅＢ（基地局）に由来し、場合によってはアップリンクとダウンリンクとで異なる帯域幅の、異なる数のコンポーネントキャリアをアグリゲーションするように、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）互換のユーザ機器を設定することが可能である。設定することができるダウンリンクコンポーネントキャリアの数は、ＵＥのダウンリンクアグリゲーション能力に依存する。逆に、設定することができるアップリンクコンポーネントキャリアの数は、ＵＥのアップリンクアグリゲーション能力に依存する。ダウンリンクコンポーネントキャリアよりも多くのアップリンクコンポーネントキャリアを備える移動端末を設定することが現在は不可能な場合がある。一般的なＴＤＤ配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同じである。同じｅＮｏｄｅＢに由来するコンポーネントキャリアは、同じカバレッジを提供する必要はない。

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

複数のキャリアをアグリゲーションする影響は、ＭＡＣレイヤにまで及ぶのみである。アップリンクおよびダウンリンクの両方について、アグリゲーションされたコンポーネントキャリア毎に１つのＨＡＲＱエンティティがＭＡＣにおいて要求される。コンポーネントキャリアあたりの最大で１つのトランスポートブロックが存在する（アップリンク用にＳＵ−ＭＩＭＯがない場合）。トランスポートブロックおよび可能性のあるそれのＨＡＲＱ再送信は、同じコンポーネントキャリアにマッピングする必要がある。

キャリアアグリゲーションが設定されているとき、移動端末はネットワークとの１つのＲＲＣ接続のみを有する。ＲＲＣ接続の確立／再確立時、ＬＴＥリリース８／９と同様に、１つのセルが、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩ、および１つのＡＲＦＣＮ）および非アクセス層モビリティ情報（例えばＴＡＩ）を提供する。ＲＲＣ接続の確立／再確立の後、当該のセルに対応するコンポーネントキャリアは、ダウンリンクプライマリセル（ＰＣｅｌｌ：Ｐｒｉｍａｒｙ Ｃｅｌｌ）と称される。接続状態では、ユーザ機器あたり常に唯一のダウンリンクＰＣｅｌｌ（ＤＬ ＰＣｅｌｌ：Ｄｏｗｎｌｉｎｋ ＰＣｅｌｌ）および唯一のアップリンクＰＣｅｌｌ（ＵＬ ＰＣｅｌｌ：Ｕｐｌｉｎｋ ＰＣｅｌｌ）が設定される。設定されたコンポーネントキャリアのセット内で、他のセルはセカンダリセル（ＳＣｅｌｌ：Ｓｅｃｏｎｄａｒｙ Ｃｅｌｌ）と呼ばれ、ＳＣｅｌｌのキャリアは、ダウンリンクセカンダリコンポーネントキャリア（ＤＬ ＳＣＣ：Ｄｏｗｎｌｉｎｋ Ｓｅｃｏｎｄａｒｙ Ｃｏｍｐｏｎｅｎｔ Ｃａｒｒｉｅｒ）およびアップリンクセカンダリコンポーネントキャリア（ＵＬ ＳＣＣ：Ｕｐｌｉｎｋ Ｓｅｃｏｎｄａｒｙ Ｃｏｍｐｏｎｅｎｔ Ｃａｒｒｉｅｒ）と称される。１つのＵＥに対して、ＰＣｅｌｌを含んで最大５つのサービングセルを設定することができる。

＜ＭＡＣレイヤ／エンティティ、ＲＲＣレイヤ、物理レイヤ＞
ＬＴＥレイヤ２のユーザプレーン／制御プレーンプロトコルスタックは、４つのサブレイヤＲＲＣ、ＰＤＣＰ、ＲＬＣおよびＭＡＣを含んでいる。媒体アクセス制御（ＭＡＣ）レイヤは、ＬＴＥ無線プロトコルスタックのレイヤ２アーキテクチャ内の最下位のサブレイヤであり、例えば非特許文献２の現在のバージョン１３．０．０によって規定されている。下位の物理レイヤへの接続は、トランスポートチャネルを経由し、上位のＲＬＣレイヤへの接続は論理チャネルを経由する。そのため、ＭＡＣレイヤは、論理チャネルとトランスポートチャネルとの間で多重化および多重分離を行い、つまり、送信側のＭＡＣレイヤは、論理チャネルを経由して受信したＭＡＣ ＳＤＵから、トランスポートブロックとして知られているＭＡＣ ＰＤＵを構築し、受信側のＭＡＣレイヤは、トランスポートチャネル経由で受信したＭＡＣ ＰＤＵからＭＡＣ ＳＤＵを復元する。

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

物理レイヤは、エアーインタフェースを介してのデータ情報および制御情報の実際の送信の役割を担い、すなわち、物理レイヤは、送信側のエアーインタフェースを介してＭＡＣトランスポートチャネルからのすべての情報を伝える。物理レイヤが実行する重要な機能のいくつかには、符号化および変調、リンクアダプテーション（ＡＭＣ）、電力制御、セルサーチ（初期同期およびハンドオーバ目的のため）ならびにＲＲＣレイヤのためのその他の計測（ＬＴＥシステム内およびシステム間）が含まれる。物理レイヤは、変調方式、符号化率（すなわち変調・符号化方式、ＭＣＳ：ｍｏｄｕｌａｔｉｏｎ ａｎｄ ｃｏｄｉｎｇ ｓｃｈｅｍｅ）、物理リソースブロック数などの、送信パラメータに基づいて、送信を実行する。物理レイヤの機能についての詳細情報は、参照により本明細書に組み込まれている、非特許文献３の現在のバージョン１３．０．０に記載されている。

無線リソース制御（ＲＲＣ）レイヤは、無線インタフェースにおけるＵＥとｅＮＢとの間の通信、およびいくつかのセルにまたがって移動するＵＥのモビリティを制御する。ＲＲＣプロトコルは、ＮＡＳ情報の伝送もサポートする。ＲＲＣ＿ＩＤＬＥ状態にあるＵＥについて、ＲＲＣは、ネットワークからの着信の通知をサポートする。ＲＲＣ接続制御は、ページング、測定設定および測定通知、無線リソース設定、初期セキュリティアクティブ化、およびシグナリング無線ベアラ（ＳＲＢ：Ｓｉｇｎａｌｌｉｎｇ Ｒａｄｉｏ Ｂｅａｒｅｒ）の確立およびユーザデータを運ぶ無線ベアラ（データ無線ベアラ、ＤＲＢ：Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）の確立を含んで、ＲＲＣ接続の確立、変更および解放に関するすべての手順をカバーする。

無線リンク制御（ＲＬＣ：ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ）サブレイヤは、主にＡＲＱ機能性を備え、データのセグメント化および連結をサポートし、すなわちＲＬＣレイヤはＲＬＣ ＳＤＵをＭＡＣレイヤによって示されたサイズにするためにＲＬＣ ＳＤＵのフレーミングを行う。後ろの２つによって、データレートとは無関係に、プロトコルオーバーヘッドを最小化する。ＲＬＣレイヤは、論理チャネルを介してＭＡＣレイヤに接続される。各論理チャネルは、異なったタイプのトラフィックを伝送する。ＲＬＣレイヤの上位のレイヤは、通常はＰＤＣＰレイヤであるが、ＲＲＣレイヤである場合もあり、すなわち、論理チャネルＢＣＣＨ（ブロードキャスト制御チャネル：Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＰＣＣＨ（ページング制御チャネル：Ｐａｇｉｎｇ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）およびＣＣＣＨ（共通制御チャネル：Ｃｏｍｍｏｎ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）上で送信されたＲＲＣメッセージは、セキュリティ保護を必要としないため、ＰＤＣＰレイヤをバイパスして直接ＲＬＣレイヤに入る。ＲＬＣサブレイヤのメインのサービスおよび機能は、以下のことを含む。
・ＡＭ、ＵＭまたはＴＭデータ伝送をサポートする、より上位のレイヤのＰＤＵの伝送
・ＡＲＱを通じた誤り訂正
・ＴＢのサイズに従ったセグメント化
・必要なとき（例えば、無線品質、すなわちサポートされるＴＢサイズが変化するとき）の再セグメント化
・同じ無線ベアラのためのＳＤＵの連結はＦＦＳである
・より上位のレイヤのＰＤＵの順番どおりの配信
・重複検出
・プロトコルエラー検出およびリカバリ
・ＳＤＵの廃棄
・リセット
ＲＬＣによって提供されるＡＲＱ機能性は、後の部分でより詳細に論じる。

＜ＬＴＥのためのアップリンクアクセス方式＞
アップリンク送信には、カバレッジを最大にするために、電力効率の良いユーザ機器の送信が必要である。動的帯域割当てを伴うＦＤＭＡと組み合わせたシングルキャリア送信が、進化型ＵＴＲＡアップリンク送信方式として選択されてきた。シングルキャリア送信が好まれる主な理由は、マルチキャリア信号（ＯＦＤＭＡ）と比べて低いピーク対平均電力比（ＰＡＰＲ：Ｐｅａｋ−ｔｏ−Ａｖｅｒａｇｅ Ｐｏｗｅｒ Ｒａｔｉｏ）、ならびに対応する改善された電力アンプの効率および改善されたカバレッジ（所与の端末ピーク電力に対する、より高いデータレート）である。各時間間隔の間、ｅＮｏｄｅＢは、ユーザデータを送信するための一意の時間／周波数リソースをユーザに割り当て、それによって、セル内直交性を確保する。アップリンクにおける直交アクセスは、セル内干渉をなくすことによってスペクトル効率を高めることを保証する。マルチパス伝搬に起因する干渉は、送信信号へのサイクリックプレフィックスの挿入による助けのもとで、基地局（ｅＮｏｄｅＢ）で処理される。

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

＜レイヤ１／レイヤ２制御シグナリング＞
スケジューリング対象のユーザに、ユーザの割当て状態、トランスポートフォーマット、およびその他の送信関連情報（例えば、ＨＡＲＱ情報、送信電力制御（ＴＰＣ：ｔｒａｎｓｍｉｔ ｐｏｗｅｒ ｃｏｎｔｒｏｌ）コマンド）を知らせるために、Ｌ１／Ｌ２制御シグナリングがデータと一緒にダウンリンクで送信される。Ｌ１／Ｌ２制御シグナリングは、ユーザ割当てがサブフレーム単位で変化することができると想定して、サブフレーム内でダウンリンクデータと多重化される。ユーザ割当てをＴＴＩ（送信時間間隔：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）ベースでも実行し得、その場合、ＴＴＩ長をサブフレームの倍数とすることができることに留意するべきである。ＴＴＩ長は、サービスエリア内ですべてのユーザに対して固定とし得るか、異なるユーザに対して異なるものとし得るか、またはユーザ毎に動的なものとさえし得る。一般に、Ｌ１／２制御シグナリングは、ＴＴＩあたり１回送信するのみでよい。一般性を損なうことなく、以下では、ＴＴＩが１サブフレームであると想定している。

Ｌ１／Ｌ２制御シグナリングは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）上で送信される。ＰＤＣＣＨは、ダウンリンク制御情報（ＤＣＩ：Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）としてメッセージを伝え、ほとんどの場合、ＤＣＩは、移動端末またはＵＥのグループのためのリソース割当ておよびその他の制御情報を含んでいる。１つのサブフレーム内でいくつかのＰＤＣＣＨを送信することができる。

一般に、アップリンク無線リソースまたはダウンリンク無線リソースを割り当てるためにＬ１／Ｌ２制御シグナリング内で送信される情報（特に、ＬＴＥ（−Ａ）リリース１０）は、以下の項目に分類することができる。

−ユーザ識別情報：割り当てる対象のユーザを示す。これは、通常、ＣＲＣをユーザ識別情報でマスクすることによってチェックサムに含まれる。
−リソース割当情報：ユーザが割り当てられるリソース（例えばリソースブロック（ＲＢ：Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ））を示す。あるいは、この情報はリソースブロック割当て（ＲＢＡ：ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ ａｓｓｉｇｎｍｅｎｔ）と称される。ユーザを割り当てられるＲＢの数は、動的なものとすることができることに留意されたい。
−キャリアインジケータ：第１のキャリア上で送信される制御チャネルが、第２のキャリアに関連するリソース、すなわち第２のキャリア上のリソースまたは第２のキャリアに関連するリソースを割り当てる場合に使用される（クロスキャリアスケジューリング：ｃｒｏｓｓ ｃａｒｒｉｅｒ ｓｃｈｅｄｕｌｉｎｇ）。
−変調・符号化方式：採用される変調方式および符号化率を決定する。
−ＨＡＲＱ情報：データパケットまたはその一部の再送信時に特に有用である、新規データインジケータ（ＮＤＩ：ｎｅｗ ｄａｔａ ｉｎｄｉｃａｔｏｒ）および／または冗長バージョン（ＲＶ：ｒｅｄｕｎｄａｎｃｙ ｖｅｒｓｉｏｎ）など。
−電力制御コマンド：割当て対象の、アップリンクデータまたは制御情報送信の、送信電力を調整する。
−基準信号情報：割当てに関連して基準信号の送信または受信に使用される、適用されるサイクリックシフトおよび／または直交カバーコードインデックスなど。
−アップリンク割当てインデックスまたはダウンリンク割当てインデックス：割当ての順序を識別するために使用され、ＴＤＤシステムにおいて特に有用である。
−ホッピング情報：例えば、周波数ダイバーシチを増大させるためにリソースホッピングを適用するかどうか、およびどのようにして適用するかの指示情報。
−ＣＳＩ要求：割り当てられたリソースにおいて、チャネル状態情報の送信をトリガするために使用される。
−マルチクラスタ情報：シングルクラスタ（連続したＲＢのセット）で送信が発生するか、それともマルチクラスタ（少なくとも２つの不連続な、連続したＲＢのセット）で送信が発生するかを示す、および制御するために使用されるフラグである。マルチクラスタ割当ては、３ＧＰＰ ＬＴＥ−（Ａ）リリース１０によって導入された。

なお上のリストは、すべてを網羅したものではなく、また、使用されるＤＣＩ ｆｏｒｍａｔに応じて、リストした情報項目すべてが各ＰＤＣＣＨ送信の中に存在している必要はないことに留意されたい。

ダウンリンク制御情報はいくつかのフォーマットの形で発生し、これらのフォーマットは、全体のサイズ、および上述したフィールドに含まれる情報も異なる。ＬＴＥのために現在定義されている異なるＤＣＩ ｆｏｒｍａｔは、以下のとおりであり、非特許文献４の５．３．３．１節（現在のバージョン１３．０．０がｈｔｔｐ：／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、参照により本明細書に組み込まれている）に詳しく記載されている。例えば、以下のＤＣＩ Ｆｏｒｍａｔは、アップリンクのためのリソースグラントを伝えるために使用することができる。

−Ｆｏｒｍａｔ ０：ＤＣＩ Ｆｏｒｍａｔ ０は、アップリンク送信モード１または２でシングルアンテナポート送信を使用する、ＰＵＳＣＨのためのリソースグラントの送信のために使用される。

−Ｆｏｒｍａｔ ４：ＤＣＩ ｆｏｒｍａｔ ４は、アップリンク送信モード２での閉ループ空間多重化送信を使用する、ＰＵＳＣＨのスケジューリングのために使用される。

非特許文献４の現在のバージョン１３．０．０は、５．４．３節でサイドリンクのための制御情報を定義しており、参照により本明細書に組み込まれている。

＜セミパーシステントスケジューリング（ＳＰＳ）＞
ダウンリンクおよびアップリンクでは、ｅＮｏｄｅＢをスケジューリングすることによって、各送信時間間隔において、Ｌ１／Ｌ２制御チャネル（ＰＤＣＣＨ）を介してリソースをユーザ機器に動的に割り当て、Ｌ１／Ｌ２制御チャネル（ＰＤＣＣＨ）では、ユーザ機器はそれらの固有のＣ−ＲＮＴＩを介してアドレス指定される。既に上述したように、ＰＤＣＣＨのＣＲＣは、アドレス指定されたユーザ機器のＣ−ＲＮＴＩでマスクされる（いわゆる動的ＰＤＣＣＨ）。一致するＣ−ＲＮＴＩを持つユーザ機器のみが、ＰＤＣＣＨに内容を正しく復号化することができ、すなわち、ＣＲＣチェックが役に立つ。この種類のＰＤＣＣＨシグナリングは、動的（スケジューリング）グラントとも称される。ユーザ機器は、それが割り当てられる、可能性のある割当て（ダウンリンクおよびアップリンク）を見つけるために、各送信時間間隔において、動的グラントについてＬ１／Ｌ２制御チャネルをモニタする。

また、Ｅ−ＵＴＲＡＮは、初期ＨＡＲＱ送信のためのアップリンク／ダウンリンクリソースをパーシステントに割り当てることができる。要求があれば、Ｌ１／Ｌ２制御チャネルを介して再送信が明示的にシグナリングされる。再送信は動的にスケジューリングされるため、この種の動作はセミパーシステントスケジューリング（ＳＰＳ）と称され、すなわち、リソースは、セミパーシステントなベースでユーザ機器に割り当てられる（セミパーシステントリソース割当て：ｓｅｍｉ−ｐｅｒｓｉｓｔｅｎｔ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）。利点は、初期ＨＡＲＱ送信のためのＰＤＣＣＨリソースが節約されるということである。セミパーシステントスケジューリングは、リリース１０のＰＣｅｌｌにおいて使用し得るが、ＳＣｅｌｌにおいては使用し得ない。

セミパーシステントスケジューリングを使用してスケジューリングされ得るサービスについての一例は、ボイスオーバＩＰ（ＶｏＩＰ：Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）である。トークスパートの間、コーデックにおいて、２０ｍｓ毎にＶｏＩＰパケットが生成される。そのため、ｅＮｏｄｅＢは、アップリンクまたは個別にダウンリンクリソースを２０ｍｓ毎にパーシステントに割り当てることができ、その結果、リソースは、ボイスオーバＩＰパケットの送信のために使用することができる。一般に、セミパーシステントスケジューリングは、予測可能なトラフィック挙動を伴う、すなわち固定ビットレート、パケット到着時間が周期的である、サービスに有益である。

ユーザ機器は、初期送信のためにパーシステントにリソースを割り当てられている、サブフレーム内のＰＤＣＣＨもモニタする。動的（スケジューリング）グラント、すなわち、Ｃ−ＲＮＴＩでマスクされたＣＲＣを有するＰＤＣＣＨは、セミパーシステントリソース割当てをオーバーライドすることができる。割り当てられたセミパーシステントリソースをユーザ機器が有するサブフレーム内のＬ１／Ｌ２制御チャネル上で、ユーザ機器が自身のＣ−ＲＮＴＩを見つけた場合、このＬ１／Ｌ２制御チャネル割当ては、当該の送信時間間隔のためのパーシステントリソース割当てをオーバーライドし、ユーザ機器は、動的グラントにまさに従う。ユーザ機器が動的グラントを見つけなかったときは、セミパーシステントリソース割当てに従って送信／受信を行う。

セミパーシステントスケジューリングの設定は、ＲＲＣシグナリングによって行われる。例えば、パーシステント割当ての周期性、例えばＰＳ＿ＰＥＲＩＯＤは、無線リソース制御（ＲＲＣ：Ｒａｄｉｏ ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）シグナリング内でシグナリングされる。パーシステント割当てのアクティブ化および正確なタイミングならびに物理リソースおよびトランスポートフォーマットパラメータは、ＰＤＣＣＨシグナリングを介して送信される。セミパーシステントスケジューリングがアクティブ化された時点で、ユーザ機器は、ＳＰＳアクティブ化ＰＤＣＣＨに従ってＰＳ＿ＰＥＲＩＯＤ毎にセミパーシステントリソース割当てに従う。本質的に、ユーザ機器は、ＳＰＳアクティブ化ＰＤＣＣＨの内容を格納し、シグナリングされた周期性でＰＤＣＣＨに従う。

動的ＰＤＣＣＨを、セミパーシステントスケジューリングをアクティブ化するＰＤＣＣＨ（ＳＰＳアクティブ化ＰＤＣＣＨとも称される）と区別するために、個別の識別情報が導入されている。基本的に、ＳＰＳアクティブ化ＰＤＣＣＨのＣＲＣは、以下においてＳＰＳ Ｃ−ＲＮＴＩと称されるこの追加の識別子でマスクされる。ＳＰＳ Ｃ−ＲＮＴＩのサイズも１６ビットであり、通常のＣ−ＲＮＴＩと同じである。さらには、ＳＰＳ Ｃ−ＲＮＴＩも、ユーザ機器固有であり、すなわち、セミパーシステントスケジューリング用に設定された各ユーザ機器は、固有のＳＰＳ Ｃ−ＲＮＴＩを割り当てられる。

ユーザ機器が、対応するＳＰＳアクティブ化ＰＤＣＣＨによってセミパーシステントリソース割当てがアクティブ化されたことを検知した場合、ユーザ機器は、ＰＤＣＣＨの内容（すなわちセミパーシステントリソース割当て）を格納して、セミパーシステントスケジューリング間隔、すなわちＲＲＣを介してシグナリングされた周期性毎にそれを適用する。既に述べたように、動的割当て、すなわち動的ＰＤＣＣＨ上でシグナリングされた割当ては、「１回限りの割当て」に過ぎない。ＳＰＳ割当ての再送信も、ＳＰＳ Ｃ−ＲＮＴＩを使用してシグナリングされる。ＳＰＳアクティブ化をＳＰＳ再送信と区別するために、ＮＤＩビット（新たなデータインジケータ：ｎｅｗ ｄａｔａ ｉｎｄｉｃａｔｏｒ）が使用される。ＳＰＳアクティブ化は、ＮＤＩビットを０に設定することによって示される。ＮＤＩビットが１にセットされた状態のＳＰＳ ＰＤＣＣＨは、セミパーシステントにスケジューリングされた初期送信のための再送信を示す。

セミパーシステントスケジューリングのアクティブ化と同様に、ｅＮｏｄｅＢは、セミパーシステントスケジューリングを非アクティブ化することもでき、ＳＰＳリソース解放とも称される。セミパーシステントスケジューリング割当て解除をどのようにしてシグナリングすることができるかにはいくつかの選択肢がある。１つの選択肢は、いくつかのＰＤＣＣＨフィールドが何らかの所定の値に設定されたＰＤＣＣＨシグナリング、すなわちゼロサイズのリソース割当てを示すＳＰＳ ＰＤＣＣＨを使用することである。別の選択肢は、ＭＡＣ制御シグナリングを使用することである。

以下では、ＵＥによって周期的データが送信されるかどうか、およびいつＳＰＳ設定を何とかしてセットアップするのかをｅＮＢがどのようにして知るかに関してさらなる情報が提供される。

新たなベアラが確立されたとき、非特許文献５の専用のベアラアクティブ化手順に従って、ＭＭＥは、ベアラ設定要求（Ｂｅａｒｅｒ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ）（ＥＰＳベアラ識別情報（ＥＰＳ Ｂｅａｒｅｒ Ｉｄｅｎｔｉｔｙ）、ＥＰＳベアラＱｏＳ（ＥＰＳ Ｂｅａｒｅｒ ＱｏＳ）、セッション管理要求（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｒｅｑｕｅｓｔ）、Ｓ１−ＴＥＩＤ）メッセージをｅＮｏｄｅＢにシグナリングする。ｅＮｏｄｅＢは、ＥＰＳベアラＱｏＳを無線ベアラＱｏＳ（Ｒａｄｉｏ Ｂｅａｒｅｒ ＱｏＳ）にマッピングする。次いで、ｅＮｏｄｅＢは、ＲＲＣ接続再構成（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）（無線ベアラＱｏＳ、セッション管理要求、ＥＰＳ ＲＢ 識別情報（ＥＰＳ ＲＢ Ｉｄｅｎｔｉｔｙ））メッセージをＵＥにシグナリングする。

ＥＰＳベアラＱｏＳプロファイルは、パラメータＱＣＩ、ＡＲＰ、ＧＢＲおよびＭＢＲを含む。各ＥＰＳベアラ（ＧＢＲおよび非ＧＢＲ）は、以下のベアラレベルのＱｏＳパラメータと関連付けられる。

−ＱｏＳクラス識別子（ＱＣＩ：ＱｏＳ Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｅｒ）
−割当・保持優先順位（ＡＲＰ：Ａｌｌｏｃａｔｉｏｎ ａｎｄ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ）
ＱＣＩは、ベアラレベルパケット転送処理（例えば、スケジューリング重み、許可しきい値、キュー管理しきい値、リンクレイヤプロトコル設定など）を制御する、ノード固有のパラメータにアクセスするための参照として使用されるスカラであり、アクセスノード（例えばｅＮｏｄｅＢ）を所有する事業者によってあらかじめ設定されている。標準化されたＱＣＩ値の、標準化された特性への１対１マッピングは、非特許文献６にあるものをベースとした以下の表に示すように、非特許文献６が取り込まれている。

表から明らかなように、ＱＣＩ値１は「会話音声」すなわちボイスオーバＩＰ（ＶｏＩＰ）に対応する。ｅＮＢが、ＱＣＩ値１の「ベアラ設定要求」メッセージを受信したとき、ｅＮＢは、このベアラがＶｏＩＰのために確立され、ＵＥがＶｏＩＰデータを送信するために周期的リソースを割り当てるためにＳＰＳ設定を適用することができる、ということが分かる。

＜ＬＴＥデバイス間（Ｄ２Ｄ）近傍サービス（ＰｒｏＳｅ）＞
近傍ベースのアプリケーションおよびサービスは、新たに起こりつつある社会−技術的傾向を表している。特定された領域には、事業者およびユーザにとって関心のある商用サービスおよび治安に関連するサービスが含まれる。ＬＴＥにおける近傍サービス（ＰｒｏＳｅ）能力の導入により、３ＧＰＰ業界がこの発展する市場に役立つと同時に、連帯してＬＴＥに託されているいくつかの治安コミュニティの緊急ニーズに役立つことを可能にする。

デバイス間（Ｄ２Ｄ）通信は、ＬＴＥリリース１２によって導入された技術コンポーネントであり、セルラネットワークに対するアンダーレイとしてＤ２Ｄがスペクトル効率を高めることを可能にする。例えば、セルラネットワークがＬＴＥである場合、データを伝えるすべての物理チャネルはＤ２ＤシグナリングのためにＳＣ−ＦＤＭＡを使用する。Ｄ２Ｄ通信では、ユーザ機器は、無線基地局を経由する代わりに、セルラリソースを使用して直接リンクを通じて互いにデータシグナルを送信する。本発明を通して、用語「Ｄ２Ｄ」、「ＰｒｏＳｅ」および「サイドリンク」は入替えが可能である。

ＬＴＥにおけるＤ２Ｄ通信は、ディスカバリ（Ｄｉｓｃｏｖｅｒｙ）および通信（Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の２つの領域に重点をおいている。

ＰｒｏＳｅ（Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ Ｓｅｒｖｉｃｅ）直接ディスカバリ（Ｄｉｒｅｃｔ Ｄｉｓｃｏｖｅｒｙ）は、ＰｒｏＳｅ対応ＵＥ（ＰｒｏＳｅ−ｅｎａｂｌｅｄ ＵＥ）によって、ＰｒｏＳｅ対応の他のＵＥを、ＰＣ５インタフェースを介してＥ−ＵＴＲＡ直接無線シグナルを使用してその近くに発見するために使用される手順として定義されている。

Ｄ２Ｄ通信では、ＵＥは、基地局（ＢＳ：ｂａｓｅ ｓｔａｔｉｏｎ）を経由する代わりに、セルラリソースを使用して直接リンクを通じて互いにデータシグナルを送信する。Ｄ２Ｄユーザは、ＢＳの制御下にある間、すなわち、少なくともｅＮＢのカバレッジ内にあるときは、直接通信を行う。そのため、Ｄ２Ｄは、セルラリソースを再利用することによってシステムパフォーマンスを改善することができる。

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

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

＜ＰｒｏＳｅ直接通信レイヤ２リンク＞
簡潔に述べると、ＰｒｏＳｅ直接１対１通信は、２つのＵＥ間にＰＣ５を介したセキュアなレイヤ２リンクを確立することによって実現される。各ＵＥは、ＵＥがレイヤ２リンク上で送信するあらゆるフレームの発信元レイヤ２ ＩＤフィールド内、およびＵＥがレイヤ２リンク上で受信するあらゆるフレームの宛先レイヤ２ ＩＤ内に含まれている、ユニキャスト通信のためのレイヤ２ ＩＤを有する。ＵＥは、ユニキャスト通信のためのレイヤ２ ＩＤが、少なくとも局所的に一意であることを保証する必要がある。そのため、ＵＥは、指定されていないメカニズムを使用して、隣接するＵＥとのレイヤ２ ＩＤ衝突を処理することに備えるべきである（例えば、衝突が検出されたときに、ユニキャスト通信のための新たなレイヤ２ ＩＤを自己割当てする）。ＰｒｏＳｅ直接通信１対１のためのレイヤ２リンクは、２つのＵＥのレイヤ２ ＩＤの組合せによって識別される。これは、ＵＥが、同じレイヤ２ ＩＤを使用してＰｒｏＳｅ直接通信１対１のための複数のレイヤ２リンクに携わることができることを意味する。

ＰｒｏＳｅ直接通信１対１は、参照により本明細書に組み込まれている非特許文献７の現在のバージョンｖ１３．０．０の７．１．２節に詳細に説明されているような、以下の手順から構成される。
・ＰＣ５を介したセキュアなレイヤ２リンクの確立。
・ＩＰアドレス／プレフィックス割当て。
・ＰＣ５を介したレイヤ２リンクの維持。
・ＰＣ５を介したレイヤ２リンクの解放。

図３は、ＰＣ５インタフェースを介したセキュアなレイヤ２リンクを確立する方法を示している。

１．ＵＥ−１が、相互認証をトリガするために直接通信要求（Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージをＵＥ−２に送信する。リンクイニシエータ（ＵＥ−１）は、ステップ１を実行するために、ピア（ＵＥ−２）のレイヤ２ ＩＤを知る必要がある。一例として、リンクイニシエータは、最初にディスカバリ手順を実行することによって、または、ピアを含むＰｒｏＳｅ１対多通信に参加することによって、ピアのレイヤ２ ＩＤを学習し得る。

２．ＵＥ−２が、相互認証のための手順を開始する。認証手順が首尾よく完了すると、ＰＣ５を介したセキュアなレイヤ２リンクの確立が完了する。

隔離された（非中継）１対１通信に携わるＵＥは、リンクローカルアドレスも使用し得る。ＰＣ５シグナリングプロトコル（Ｓｉｇｎａｌｌｉｎｇ Ｐｒｏｔｏｃｏｌ）は、ＵＥが黙示的なレイヤ２リンク解放を進めることができるように、ＵＥがＰｒｏＳｅ通信範囲内にないときを検出するために使用されるキープアライブ機能をサポートするものとする。ＰＣ５を介したレイヤ２リンク解放は、他方のＵＥに送信される切断要求（Ｄｉｓｃｏｎｎｅｃｔ Ｒｅｑｕｅｓｔ）メッセージを使用することによって行うことができ、他方のＵＥも、すべての関連するコンテキストデータを削除する。切断要求メッセージを受信した時点で、他方のＵＥは、切断応答（Ｄｉｓｃｏｎｎｅｃｔ Ｒｅｓｐｏｎｓｅ）メッセージで応答し、レイヤ２リンクと関連付けられたすべてのコンテキストデータを削除する。

＜ＰｒｏＳｅ直接通信関連識別情報＞
非特許文献８の現行バージョン１３．２．０が、ＰｒｏＳｅ直接通信のために使用する以下の識別情報を８．３節に定義している。
・ＳＬ−ＲＮＴＩ：ＰｒｏＳｅ直接通信スケジューリングのために使用される固有の識別情報。
・発信元レイヤ２（Ｓｏｕｒｃｅ Ｌａｙｅｒ−２） ＩＤ：サイドリンクＰｒｏＳｅ直接通信におけるデータの送信者を識別する。発信元レイヤ２ ＩＤは、２４ビット長であり、受信部におけるＲＬＣ ＵＭエンティティおよびＰＤＣＰエンティティの識別のためのＰｒｏＳｅレイヤ２宛先ＩＤおよびＬＣＩＤと一緒に使用される。
・宛先レイヤ２（Ｄｅｓｔｉｎａｔｉｏｎ Ｌａｙｅｒ−２） ＩＤ：サイドリンクＰｒｏＳｅ直接通信におけるデータのターゲットを識別する。宛先レイヤ２ ＩＤは２４ビット長であり、ＭＡＣレイヤにおいて２つのビット列に分割される。
・１つのビット列は宛先レイヤ２ ＩＤのＬＳＢ部（８ビット）であり、サイドリンク制御レイヤ１ ＩＤ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｌａｙｅｒ−１ ＩＤ）として物理レイヤに転送される。これはサイドリンク制御（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ）において意図されたデータのターゲットを識別し、物理レイヤにおいてパケットをフィルタリングするために使用される。
・第２のビット列は宛先レイヤ２ ＩＤのＭＳＢ部（１６ビット）であり、ＭＡＣヘッダ内で伝えられる。これはＭＡＣレイヤにおいてパケットをフィルタリングするために使用される。

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

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

モード１は、ｅＮＢによってスケジューリングされるリソース割当てのことを指し、ＵＥがｅＮＢ（またはリリース１０中継ノード）から送信リソースを要求し、ｅＮｏｄｅＢ（またはリリース１０中継ノード）は、次いで直接データおよび直接制御情報を送信するためにＵＥによって使用されるリソースをスケジューリングする（例えばスケジューリング割当て（Ｓｃｈｅｄｕｌｉｎｇ Ａｓｓｉｇｎｍｅｎｔ））。ＵＥは、データを送信するためにＲＲＣ＿ＣＯＮＮＥＣＴＥＤである必要がある。具体的には、ＵＥはｅＮＢにスケジューリング要求（Ｄ−ＳＲまたはランダムアクセス（Ｒａｎｄｏｍ Ａｃｃｅｓｓ））を送信し、通常の方法でバッファ状態通知（ＢＳＲ：Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｒｅｐｏｒｔ）が後に続く（以下の章「Ｄ２Ｄ通信のための送信手順」も参照）。ＢＳＲに基づいて、ｅＮＢは、ＵＥがＰｒｏＳｅ直接通信送信のためのデータを有していると判定することができ、送信のために必要とされるリソースを推定することができる。

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

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

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

リソース割当てモードに関して以下の規則がＵＥに適用される。
・ＵＥがカバレッジ外である場合、ＵＥはモード２のみを使用することができる。
・ＵＥがカバレッジ内である場合、ＵＥは、ｅＮＢがＵＥをそれに応じて設定していればモード１を使用し得る。
・ＵＥがカバレッジ内である場合、ＵＥは、ｅＮＢがＵＥをそれに応じて設定していればモード２を使用し得る。
・例外的条件が存在しないときには、ＵＥは、ｅＮＢによってそうするように設定されている場合に限り、モード１からモード２に、またはその逆に変化し得る。ＵＥがカバレッジ内である場合、ＵＥは、例外的なケースの１つが発生しない限り、ｅＮＢ設定によって示されたモードのみを使用するものとする。
・ＵＥは、例えばＴ３１１またはＴ３０１が実行中である間、自身が例外的条件にあるものと見なす。
・例外的なケースが発生したとき、ＵＥは、モード１を使用するように設定されている場合でも、一時的にモード２を使用することが許可される。

Ｅ−ＵＴＲＡセルのカバレッジエリア内にある間は、ＵＥは、たとえ当該キャリアのリソースが例えばＵＩＣＣ（汎用ＩＣカード：Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）においてあらかじめ設定されている場合でも、当該セルによって割り当てられたリソースにおいてのみ、ＵＬキャリア上でＰｒｏＳｅ直接通信送信を実行するものとする。

ＲＲＣ＿ＩＤＬＥ状態にあるＵＥに対しては、ｅＮＢは次の選択肢の１つを選択し得る。
・ｅＮＢは、モード２の送信リソースプールをＳＩＢの中で提供し得る。ＰｒｏＳｅ直接通信が承認されているＵＥは、ＲＲＣ＿ＩＤＬＥ状態においてＰｒｏＳｅ直接通信のためにこれらのリソースを使用する。
・ｅＮＢは、自身がＤ２ＤをサポートしているがＰｒｏＳｅ直接通信のためのリソースを提供しないことをＳＩＢの中で示し得る。ＵＥは、ＰｒｏＳｅ直接通信送信を実行するためにはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に入る必要がある。

ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥについては、以下のとおりである。
・ＰｒｏＳｅ直接通信送信を実行することが承認されている、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥは、ＰｒｏＳｅ直接通信送信を実行する必要があるとき、ＰｒｏＳｅ直接通信送信をしたいということをｅＮＢに示す。
・ｅＮＢは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥがＰｒｏＳｅ直接通信送信を承認されているかどうかを、ＭＭＥから受信したＵＥコンテキストを使用して確認する。
・ｅＮＢは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥを、専用シグナリングによって、そのＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態である間は制約無しで使用し得るモード２リソース割当て送信リソースプールで設定し得る。あるいは、ｅＮＢは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥを、専用シグナリングによって、そのＵＥが例外的なケースにおいてのみ使用して、そうでない場合はモード１に依存することが許される、モード２のリソース割当て送信リソースプールで設定し得る。

ＵＥがカバレッジ外のときのスケジューリング割当てのためのリソースプールは、以下のように設定することができる。
・受信のために使用されるリソースプールは、あらかじめ設定される。
・送信のために使用されるリソースプールは、あらかじめ設定される。

ＵＥがカバレッジ内のときのスケジューリング割当てのためのリソースプールは、以下のように設定することができる。
・受信のために使用されるリソースプールは、ＲＲＣを介して、専用シグナリングまたはブロードキャストシグナリング内で、ｅＮＢによって設定される。
・モード２リソース割当てが使用される場合、送信のために使用されるリソースプールは、ＲＲＣを介してｅＮＢによって設定される。
・モード１リソース割当てが使用される場合、送信のために使用されるＳＣＩ（サイドリンク制御情報：Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）リソースプール（スケジューリング割当て（ＳＡ）リソースプールとも称される）は、ＵＥには知られない。
・モード１リソース割当てが使用される場合、ｅＮＢは、サイドリンク制御情報（スケジューリング割当て）送信のために使用する特定のリソースをスケジューリングする。ｅＮＢによって割り当てられた特定のリソースは、ＵＥへ提供されているＳＣＩの受信のためのリソースプール内にある。

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

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

＜Ｄ２Ｄ通信のための送信手順＞
Ｄ２Ｄデータ通信手順は、リソース割当てモードによって異なる。上記のように、モード１について、ｅＮＢは、スケジューリング割当ておよびＤ２Ｄデータ通信のためのリソースを、ＵＥからの対応する要求の後に明示的にスケジューリングする。具体的には、ＵＥは、Ｄ２Ｄ通信は基本的に許可されるがモード２のリソース（すなわちリソースプール）が提供されないことを、ｅＮＢによって通知され得、これは、例えば、ＵＥによるＤ２Ｄ通信関心通知（Ｄ２Ｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｉｎｔｅｒｅｓｔ Ｉｎｄｉｃａｔｉｏｎ）と、対応する応答であるＤ２Ｄ通信応答（Ｄ２Ｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）を交換することによって行われ得、対応する例示的なＰｒｏｓｅＣｏｍｍＣｏｎｆｉｇの情報エレメントはｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎを含まず、すなわち、送信を含む直接通信を開始したいＵＥは、個々の送信毎にリソース割当てをＥ−ＵＴＲＡＮに要求しなければならない。このように、こうしたケースでは、ＵＥは、個々の送信毎にリソースを要求しなければならず、以下に、このモード１リソース割当てについて、要求／許可手順の異なったステップを例示的に列挙する。
・ステップ１：ＵＥが、ＰＵＣＣＨを介してｅＮＢにＳＲ（スケジューリング要求：Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ）を送信する。
・ステップ２：ｅＮＢが、Ｃ−ＲＮＴＩによってスクランブルして、ＰＤＣＣＨを介して（ＵＥがＢＳＲを送信するための）ＵＬリソースを許可する。
・ステップ３：ＵＥが、ＰＵＳＣＨを介してバッファの状態を示すＤ２Ｄ ＢＳＲを送信する。
・ステップ４：ｅＮＢが、Ｄ２Ｄ−ＲＮＴＩによってスクランブルして、ＰＤＣＣＨを介して（ＵＥがデータを送るための）Ｄ２Ｄリソースを許可する。
・ステップ５：Ｄ２Ｄ送信ＵＥが、ステップ４で受信したグラントに従って、ＳＡ／Ｄ２Ｄデータを送信する。

スケジューリング割当て（ＳＡ）は、ＳＣＩ（サイドリンク制御情報：Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）とも称され、制御情報、例えば、対応するＤ２Ｄデータ送信のための時間−周波数リソースへのポインタ、変調および符号化方式、ならびにグループ宛先ＩＤ（Ｇｒｏｕｐ Ｄｅｓｔｉｎａｔｉｏｎ ＩＤ）を含む、コンパクトな（低ペイロードの）メッセージである。ＳＣＩは、１つの（ＰｒｏＳｅ）宛先ＩＤのためのサイドリンクスケジューリング情報を伝送する。ＳＡ（ＳＣＩ）の内容は、基本的には上記のステップ４で受信されたグラントに従う。Ｄ２ＤグラントおよびＳＡの内容は、参照により本明細書に組み込まれている非特許文献４の現在のバージョン１３．０．０の５．４．３節で定義されており、ＳＣＩフォーマット０を具体的に定義している（上記のＳＣＩフォーマット０の内容を参照）。

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

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

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

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

図７から明らかなように、ｅＮＢによってスケジューリングされるリソース割当てモード（モード１）については、Ｄ２Ｄデータ送信、すなわちより詳細には、Ｔ−ＲＰＴパターン／ビットマップは、ＳＡリソースプールでの最後のＳＡ送信繰り返しの後に次のＵＬサブフレームにおいて始まる。図６について既に説明したように、モード１ Ｔ−ＲＰＴビットマップ（送信の時間リソースパターン、Ｔ−ＲＰＴ：ｔｉｍｅ ｒｅｓｏｕｒｃｅ ｐａｔｔｅｒｎ ｏｆ ｔｒａｎｓｍｉｓｓｉｏｎ）は基本的に、ＭＡＣ ＰＤＵ送信（１番目の送信）およびその再送信（２番目、３番目および４番目の送信）のタイミングを定義する。

サイドリンクデータ送信手順は、参照により本明細書に組み込まれている、非特許文献２のｖ１３．０．０の５．１４節に記載されている。その中に、モード２の自律的リソース選択が詳細に記載されており、単一無線リソースプールでの構成と複数無線リソースプールでの構成とを区別している。非特許文献２の前記の節から以下のステップが取られており、モード２の自律的リソース選択を想定している。

ＳＬ−ＳＣＨ（サイドリンク共有チャネル：ｓｉｄｅｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）上で送信するためには、ＭＡＣエンティティは、少なくとも１つのサイドリンクグラントを有しなければならない。サイドリンクグラントは、以下のように選択される。

ＭＡＣエンティティが、１または複数の、リソースのプールを使用して送信するように、より上位のレイヤによって設定され、現在のＳＣ期間に送信することができるよりも多くのデータがＳＴＣＨ（サイドリンクトラフィックチャネル：ｓｉｄｅｌｉｎｋ ｔｒａｆｆｉｃ ｃｈａｎｎｅｌ）内で利用可能である場合、選択されるべき各サイドリンクグラントについてＭＡＣエンティティは、以下のとおりとする。
・より上位のレイヤによって、単一の、リソースのプールを使用するように設定される場合：
−当該のリソースのプールを使用に選択する。
・さもなければ、より上位のレイヤによって、複数の、リソースのプールを使用するように設定される場合：
−関連付けられた優先度リストが、送信されるべきＭＡＣ ＰＤＵにおけるサイドリンク論理チャネルのうちで最も優先度の高い優先度を含む、より上位のレイヤによって設定されるリソースのプールから、リソースのプールを使用に選択する。

注記：２つ以上の、リソースのプールが、送信されるべきＭＡＣ ＰＤＵにおいて最も高い優先度のサイドリンク論理チャネルの優先度を含んだ関連付けられた優先度リストを有する場合、これらの、リソースのプールのうちのどの１つを選択するかは、ＵＥの実施にゆだねられる。
・選択されたリソースプールから、ＳＬ−ＳＣＨおよびサイドリンクグラントのＳＣＩのための、時間および周波数リソースをランダムに選択する。ランダム関数は、許容された選択のそれぞれを等しい確率で選択することができるものであること。
・参照により本明細書に組み込まれている非特許文献３の１４．２．１節に従ってＳＣＩの送信および最初のトランスポートブロックの送信が発生するサブフレームのセットを決定するために、選択されたサイドリンクグラントを使用する（このステップは、図７と関連付けて説明するように、Ｔ−ＲＰＴおよびＳＡパターンの選択のことを指す）。
・選択されたサイドリンクグラントを、サイドリンクグラントが選択されたサブフレームの少なくとも４サブフレーム後に始まる最初の利用可能なＳＣ期間の開始で始まるサブフレーム内で発生する、設定されたサイドリンクグラントと見なす。
・設定されたサイドリンクグラントを、対応するＳＣ期間の最後でクリアする。

注記：ＳＬ−ＳＣＨ上での再送信は、設定されたサイドリンクグラントがクリアされてしまった後は発生することができない。

注記：より上位のレイヤによって、１または複数の、リソースのプールを使用して送信するようにＭＡＣエンティティが設定される場合、サイドリンクプロセスの数を考慮して、１つのＳＣ期間内にいくつのサイドリンクグラントを選択するかは、ＵＥの実施にゆだねられる。

ＭＡＣエンティティは、各サブフレームについて以下のとおりとする。

−ＭＡＣエンティティがこのサブフレーム内で発生する設定されたサイドリンクグラントを有している場合
−設定されたサイドリンクグラントがＳＣＩの送信に対応している場合
−物理レイヤに、設定されたサイドリンクグラントに対応するＳＣＩを送信するように命令する。
−さもなければ、設定されたサイドリンクグラントが第１のトランスポートブロックの送信に対応している場合、
−このサブフレームのために、設定されたサイドリンクグラントおよび関連付けられたＨＡＲＱ情報をサイドリンクＨＡＲＱエンティティに配信する。

注記：ＭＡＣエンティティが、１つのサブフレーム内で発生する複数の設定されたグラントを有している場合、および、単一クラスタＳＣ−ＦＤＭの制約に起因してそれらのすべてを処理することができるわけではない場合、それらのどの１つを上記の手順に従って処理するかは、ＵＥの実施にゆだねられる。

３ＧＰＰ技術標準から取られた上記の文章は、さらに明確にすることができる。例えば、時間および周波数リソースをランダムに選択するステップは、どの特定の時間／周波数リソースが選択されるかに関してはランダムであるが、例えば、合計で選択される時間／周波数リソースの量に関してはランダムではない。リソースプールから選択されるリソースの量は、自律的に選択されるべき前記サイドリンクで送信されるべきデータの量に依存する。次いで、送信されるべきデータの量は、ＰｒｏＳｅ宛先グループを選択する、前のステップ、および、対応する、前記ＰｒｏＳｅ宛先グループ宛の送信準備ができているデータの量に依存する。サイドリンクＬＣＰ手順で後に記載するように、ＰｒｏＳｅ宛先が最初に選択される。

さらには、参照により本明細書に組み込まれている非特許文献２のｖ１３．０．０の５．１４．１．２．２節から明らかなように、サイドリンクＨＡＲＱエンティティに関連付けられたサイドリンクプロセスは、それに応じて送信を生成し、および実行するように、物理レイヤに命令する役割を担う。簡潔に述べると、サイドリンクグラント、および送信すべきサイドリンクデータを決定した後、物理レイヤは、サイドリンクグラントおよび必要な送信パラメータに基づいて、サイドリンクデータが実際に送信されるように注意を払う。

上記で論じたのは、Ｄ２Ｄ通信についての３ＧＰＰ標準の現在の状態である。ただし、将来のリリースにおいてＤ２Ｄ通信に何らかの変更が導入されるという結果になりそうな、Ｄ２Ｄ通信のさらなる改善および拡張の方法については、進行中の議論があることに留意すべきである。本発明は、後に記載するように、これら後のリリースにも適用することができるものとする。

＜ＰｒｏＳｅネットワークアーキテクチャおよびＰｒｏＳｅエンティティ＞
図８は、それぞれのＵＥ ＡおよびＢ内の異なるＰｒｏＳｅアプリケーション、ならびに、ネットワーク内のＰｒｏＳｅアプリケーションサーバおよびＰｒｏＳｅ機能を含む、非ローミングケースについての高レベルの例示的なアーキテクチャを示している。図８のアーキテクチャ例は、参照によって本明細書に組み込まれている非特許文献９のｖ．１３．２．０の４．２章「Ａｒｃｈｉｔｅｃｔｕｒａｌ Ｒｅｆｅｒｅｎｃｅ Ｍｏｄｅｌ」から取られている。

機能エンティティは、参照によって本明細書に組み込まれている非特許文献９の４．４節「Ｆｕｎｃｔｉｏｎａｌ Ｅｎｔｉｔｉｅｓ」に詳細に提示および説明されている。ＰｒｏＳｅ機能は、ＰｒｏＳｅのために要求されるネットワーク関連動作のために使用される論理機能であり、ＰｒｏＳｅの特徴のそれぞれのために異なった役割を果たす。ＰｒｏＳｅ機能は、３ＧＰＰのＥＰＣの一部分であり、近傍サービスに関係する、承認、認証、データ操作などのような、関連するすべてのネットワークサービスを提供する。ＰｒｏＳｅ直接ディスカバリおよび通信について、ＵＥは、特定のＰｒｏＳｅ ＵＥ識別情報、他の設定情報、および承認をＰｒｏＳｅ機能からＰＣ３基準点を通じて取得し得る。ネットワークには複数のＰｒｏＳｅ機能を展開することができるが、説明図を容易にするために、単一のＰｒｏＳｅ機能を提示している。ＰｒｏＳｅ機能は、ＰｒｏＳｅの特徴に応じた異なる役割を実行する３つの主なサブ機能、すなわち、直接供給機能（ＤＰＦ：Ｄｉｒｅｃｔ Ｐｒｏｖｉｓｉｏｎ Ｆｕｎｃｔｉｏｎ）、直接ディスカバリ名管理機能（Ｄｉｒｅｃｔ Ｄｉｓｃｏｖｅｒｙ Ｎａｍｅ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）およびＥＰＣレベルディスカバリ機能（ＥＰＣ−ｌｅｖｅｌ Ｄｉｓｃｏｖｅｒｙ Ｆｕｎｃｔｉｏｎ）から構成されている。ＤＰＦは、ＰｒｏＳｅ直接ディスカバリおよびＰｒｏＳｅ直接通信を使用するために、必要なパラメータをＵＥに供給するために使用される。

前記文脈で使用される用語「ＵＥ」は、例えば以下のＰｒｏＳｅ機能性をサポートするＰｒｏＳｅ対応ＵＥのことを指す。
・ＰＣ３基準点を通じたＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間でのＰｒｏＳｅ制御情報の交換。
・ＰＣ５基準点を通じた他のＰｒｏＳｅ対応ＵＥのオープンＰｒｏＳｅ直接ディスカバリのための手順。
・ＰＣ５基準点を通じた１対多ＰｒｏＳｅ直接通信のための手順。
・ＰｒｏＳｅ ＵＥ−ネットワーク中継器（ＰｒｏＳｅ ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ Ｒｅｌａｙ）として動作するための手順。リモートＵＥ（Ｒｅｍｏｔｅ ＵＥ）は、ＰＣ５基準点を通じてＰｒｏＳｅ ＵＥ−ネットワーク中継器と通信する。ＰｒｏＳｅ ＵＥ−ネットワーク中継器は、レイヤ３パケット転送を使用する。
・例えば、ＵＥ−ネットワーク中継器検出およびＰｒｏＳｅ直接ディスカバリのために、ＰＣ５基準点を通じてＰｒｏＳｅ ＵＥ間での制御情報の交換。
・ＰＣ３基準点を通じて、別のＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間でのＰｒｏＳｅ制御情報の交換。ＰｒｏＳｅ ＵＥ−ネットワーク中継器のケースでは、リモートＵＥは、ＬＴＥ−Ｕｕインタフェースを通じてＰｒｏＳｅ機能に向けて中継されるべきＰＣ５ユーザプレーンを通じてこの制御情報を送信する。
・パラメータ（例えば、ＩＰアドレス、ＰｒｏＳｅレイヤ２グループＩＤ、グループセキュリティマテリアル（Ｇｒｏｕｐ ｓｅｃｕｒｉｔｙ ｍａｔｅｒｉａｌ）、無線リソースパラメータを含む）の設定。これらのパラメータは、ＵＥにおいてあらかじめ設定することができるか、または、カバレッジ内にある場合には、ＰＣ３基準点を通じたシグナリングによってネットワーク内のＰｒｏＳｅ機能に提供することができる。

ＰｒｏＳｅアプリケーションサーバは、ＥＰＣ ＰｒｏＳｅユーザＩＤ（ＥＰＣ ＰｒｏＳｅ Ｕｓｅｒ ＩＤ）およびＰｒｏＳｅ機能ＩＤ（ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ ＩＤ）の格納、ならびにアプリケーションレイヤユーザＩＤ（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ Ｕｓｅｒ ＩＤ）およびＥＰＣ ＰｒｏＳｅユーザＩＤのマッピングをサポートする。ＰｒｏＳｅアプリケーションサーバ（ＡＳ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）は３ＧＰＰの範囲外のエンティティである。ＵＥにおけるＰｒｏＳｅアプリケーションは、アプリケーションレイヤ基準点ＰＣ１を介してＰｒｏＳｅ ＡＳと通信する。ＰｒｏＳｅ ＡＳは、ＰＣ２基準点を介して３ＧＰＰネットワークに接続されている。

＜車両通信−Ｖ２Ｘサービス＞
自動車業界に対する新たなＬＴＥの特徴の有用性を考慮するための新たな検討項目が３ＧＰＰにおいて定められ、近傍サービス（ＰｒｏＳＥ）およびＬＴＥベースのブロードキャストサービスを含んでいる。このように、ＰｒｏＳｅ機能性は、Ｖ２Ｘサービスのための良好な基盤を提供するものと見なされている。コネクテッドビークル技術は、安全性、モビリティ、トラフィック効率など、陸上輸送業界における最大の課題のいくつかに取り組むことを目標にしている。

Ｖ２Ｘ通信は、車両から、車両に影響し得る任意のエンティティへ、およびその逆への情報の伝達である。この情報交換は、安全性、モビリティおよび環境のアプリケーションを改善して運転者支援車両安全、速度適応および警告、緊急応答、交通情報、ナビゲーション、交通運行、商用車運行管理および支払い手続きを含むようにするために使用することができる。

Ｖ２ＸサービスのためのＬＴＥサポートには、以下のとおり、異なった３つのタイプの使用ケースが含まれる。
・Ｖ２Ｖ（Vehicle-to-Vehicle）：車両間のＬＴＥベースの通信をカバーする。
・Ｖ２Ｐ（Vehicle-to-Pedestrian）：車両と個人によって持ち運ばれるデバイス（例えば、歩行者、サイクリスト、ドライバまたは旅客によって持ち運ばれるハンドヘルド端末）との間のＬＴＥベースの通信をカバーする。
・Ｖ２Ｉ（Vehicle-to-Infrastructure）：車両と路側機との間のＬＴＥベースの通信をカバーする。

これらの３つのタイプのＶ２Ｘは、エンドユーザに向けてよりインテリジェントなサービスを提供するために、「協調的認識」を使用することができる。これは、車両、路側インフラ、および歩行者などのトランスポートエンティティが、それぞれの局所環境についての知識（例えば、近傍の、他の車両またはセンサ装置から受信した情報）を収集して、協調的衝突警告または自動運転などのよりインテリジェントなサービスを提供するために、その知識を処理し、および共有することができる。

Ｖ２Ｖ通信に関しては、Ｅ−ＵＴＲＡＮは、許可、承認および近傍性基準が満たされたとき、互いの近傍にいるＵＥが、Ｅ−ＵＴＲＡ（Ｎ）を使用してＶ２Ｖ関連の情報を交換することを可能にする。近傍性基準は、ＭＮＯ（移動体通信事業者：Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｏｒ）によって設定することができる。ただし、Ｖ２ＶサービスをサポートしているＵＥは、Ｖ２ＸサービスをサポートするＥ−ＵＴＲＡＮによってサービスされるときまたはサービスされないときに、こうした情報を交換することができる。

Ｖ２ＶアプリケーションをサポートしているＵＥは、アプリケーションレイヤの情報（例えば、Ｖ２Ｖサービスの一部としてその位置、ダイナミクス、および属性）を送信する。Ｖ２Ｖペイロードは、異なる情報内容を収容するためにフレキシブルでなければならず、情報は、ＭＮＯによって提供された設定に従って周期的に送信することができる。

Ｖ２Ｖは、主にブロードキャストベースであり、Ｖ２Ｖは、別個のＵＥ間のＶ２Ｖ関連のアプリケーション情報の、直接の交換、および／または、Ｖ２Ｖの直接通信範囲が制限されていることから、別個のＵＥ間のＶ２Ｖ関連のアプリケーション情報の、Ｖ２Ｘサービスをサポートしているインフラ、例えばＲＳＵ、アプリケーションサーバなどを介しての交換を含んでいる。

Ｖ２Ｉ通信に関しては、Ｖ２ＩアプリケーションをサポートしているＵＥは、アプリケーションレイヤの情報を路側機に送信し、その路側機は次いでアプリケーションレイヤの情報をＶ２ＩアプリケーションをサポートしているＵＥのグループまたはＵＥに送信することができる。

Ｖ２Ｎ（Vehicle-to-Network、ｅＮＢ／ＣＮ）も導入され、一方の通信主体はＵＥで他方の通信主体はサービングエンティティで、両方ともＶ２Ｎアプリケーションをサポートし、ＬＴＥネットワークを介して互いに通信する。

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

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

Ｖ２Ｐは、別個のＵＥ（一方は車両用で、他方は歩行者用）間のＶ２Ｐ関連のアプリケーション情報の、直接の交換、および／または、Ｖ２Ｐの直接通信範囲が制限されていることから、別個のＵＥ間のＶ２Ｐ関連のアプリケーション情報の、Ｖ２Ｘサービスをサポートしているインフラ、例えばＲＳＵ、アプリケーションサーバなどを介しての交換を含んでいる。

この新たな検討項目Ｖ２Ｘのために、３ＧＰＰは固有の用語および定義を非特許文献１０の現在のバージョン１３．０．０で提供しており、本願のために再利用することができる。

路側機（ＲＳＵ：Ｒｏａｄ Ｓｉｄｅ Ｕｎｉｔ）：Ｖ２Ｉアプリケーションを使用しているＵＥへ送信し、およびそこから受信することができるＶ２Ｉサービスをサポートしているエンティティ。ＲＳＵは、ｅＮＢまたは据付けのＵＥに実装することができる。
Ｖ２Ｉサービス：Ｖ２Ｘサービスの１つのタイプであり、１つの通信主体はＵＥで、他方の通信主体はＲＳＵで、両方共にＶ２Ｉアプリケーションを使用する。
Ｖ２Ｎサービス：Ｖ２Ｘサービスの１つのタイプであり、一方の通信主体はＵＥで他方の通信主体はサービングエンティティで、両方ともＶ２Ｎアプリケーションを使用し、ＬＴＥネットワークエンティティを介して互いに通信する。
Ｖ２Ｐサービス：Ｖ２Ｘサービスの１つのタイプであり、通信の両方の通信主体は、Ｖ２Ｐアプリケーションを使用しているＵＥである。
Ｖ２Ｖサービス：Ｖ２Ｘサービスの１つのタイプであり、通信の両方の通信主体は、Ｖ２Ｖアプリケーションを使用しているＵＥである。

Ｖ２Ｘサービス：３ＧＰＰトランスポートを介してＶ２Ｖアプリケーションを使用している送信または受信ＵＥに関与する通信サービスの１つのタイプ。Ｖ２Ｘサービスは、通信に関与している他方の通信主体に基づいて、Ｖ２Ｖサービス、Ｖ２Ｉサービス、Ｖ２Ｐサービス、およびＶ２Ｎサービスにさらに分けることができる。

Ｖ２Ｖ通信について、異なるタイプのメッセージが定義されており、また、定義される。高度道路交通システム（ＩＴＳ：Ｉｎｔｅｌｌｉｇｅｎｔ Ｔｒａｎｓｐｏｒｔ Ｓｙｓｔｅｍ）のために、２つの異なったタイプのメッセージがＥＴＳＩによって既に定義されており、対応する欧州規格である非特許文献１１のｖ１．３．１および非特許文献１２のｖ１．２．１を参照されたい。

・協調認識メッセージ（ＣＡＭ：Ｃｏｏｐｅｒａｔｉｖｅ Ａｗａｒｅｎｅｓｓ Ｍｅｓｓａｇｅ）：車両状態を反映するために車両ダイナミクスによって継続的にトリガされる。
・分散型環境通知メッセージ（ＤＥＮＭ：Ｄｅｃｅｎｔｒａｌｉｚｅｄ Ｅｎｖｉｒｏｎｍｅｎｔａｌ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｍｅｓｓａｇｅ）：車両関連の安全性に関わる事象が発生したときにのみトリガされる。

Ｖ２Ｖ標準化およびＩＴＳ標準化は、どちらかといえば始まりにあり、将来他のメッセージが定義され得ることが期待される。

ＣＡＭは、他のＩＴＳ局（ＩＴＳ−Ｓ：ＩＴＳ Ｓｔａｔｉｏｎ）とステータス情報を交換するためにＩＴＳ−Ｓによって継続的にブロードキャストされるので、イベントトリガされるＤＥＮＭメッセージよりも大きな影響をトラフィック負荷に与える。この理由により、ＩＴＳのためにＥＴＳＩによって定義されるＣＡＭメッセージのトラフィック特徴は、Ｖ２Ｖトラフィックをより代表するものと見なされている。

協調認識メッセージ（ＣＡＭ）は、ＩＴＳネットワークにおいて、互いについての認識を生み出して維持し、道路ネットワークを使用して車両の協調動作をサポートするためにＩＴＳ−Ｓ間で交換されるメッセージである。ポイントツーマルチポイント通信は、発信ＩＴＳ−Ｓから、発信ＩＴＳ−Ｓの直接通信範囲内に位置する受信ＩＴＳ−ＳへＣＡＭが送信されるように、ＣＡＭを送信するために使用されるものとする。ＣＡＭ生成は、２つの連続するＣＡＭメッセージ間の時間間隔を定義する、協調認識基本サービスによってトリガおよび管理されるものとする。現在のところ、送信間隔の上限および下限は、１００ｍｓ（すなわちＣＡＭ生成レート１０Ｈｚ）および１０００ｍｓ（すなわちＣＡＭ生成レート１Ｈｚ）である。ＥＴＳＩ ＩＴＳの根底にある原理は、共有すべき新たな情報（例えば、新たな位置、新たな加速度または新たな進行方向値）が存在するときにＣＡＭを送信することである。それに応じて、車両がゆっくり、そして一定の進行方向および速度で移動しているとき、高いＣＡＭ生成レートは真の利益はもたらさず、ＣＡＭは最小限の違いを表示するのみである。１つの車両のＣＡＭ送信頻度は、車両ダイナミクス（例えば、速度、加速度、および進行方向）の関数として１Ｈｚ〜１０Ｈｚの範囲で変化する。例えば、車両がゆっくり走行すればするほど、より少ない数のＣＡＭがトリガおよび送信される。車両速度は、ＣＡＭトラフィック生成に対する主要な影響要因である。

ＣＡＭ生成のトリガ条件は、非特許文献１１のｖ１．３．１の６．１．３条に現在定義されており、以下に示す。

１） 最後のＣＡＭ生成後の経過時間が、Ｔ＿ＧｅｎＣａｍ＿Ｄｃｃ（分散渋滞制御（ＤＣＣ：ｄｅｃｅｎｔｒａｌｉｚｅｄ ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ）のチャネル使用要件に従ってＣＡＭ生成を減らすために２つの連続するＣＡＭ生成間の最小の時間間隔を提供するパラメータ）と等しいかそれより大きく、以下のＩＴＳ−Ｓダイナミクスに関連した条件の１つがが与えられる。
・発信ＩＴＳ−Ｓの現在の進行方向と発信ＩＴＳ−Ｓによって前に送信されたＣＡＭに含まれていた進行方向との差の絶対値が４°を超える。
・発信ＩＴＳ−Ｓの現在の位置と発信ＩＴＳ−Ｓによって前に送信されたＣＡＭに含まれていた位置との間の距離が４ｍを超える。
・発信ＩＴＳ−Ｓの現在の速度と発信ＩＴＳ−Ｓによって前に送信されたＣＡＭに含まれていた速度との差の絶対値が０．５ｍ／ｓを超える。

２） 最後のＣＡＭ生成後の経過時間が、Ｔ＿ＧｅｎＣａｍと等しいかそれより大きく、かつ、Ｔ＿ＧｅｎＣａｍ＿Ｄｃｃと等しいかそれより大きい。パラメータＴ＿ＧｅｎＣａｍは、ＣＡＭ生成間隔の現在有効な上限を表す。

上記の２つの条件の１つが満たされた場合、ＣＡＭは、即座に生成されるものとする。

ＣＡＭは、発信ＩＴＳ−Ｓの状態情報および属性情報を含んでいる。ＣＡＭの内容は、以下でより詳細に説明するように、ＩＴＳ−Ｓのタイプに応じて変化する。車両ＩＴＳ−Ｓについては、ステータス情報は、時間、位置、運動状態、アクティブ化されているシステムなどを含み得、属性情報は、寸法、車両タイプ、および道路トラフィックにおける役割についてのデータを含み得る。ＣＡＭを受信すると、受信ＩＴＳ−Ｓは、発信ＩＴＳ−Ｓの存在、タイプ、および状態を知るようになる。受信した情報は、受信ＩＴＳ−ＳによっていくつかのＩＴＳアプリケーションをサポートするために使用することができる。例えば、発信ＩＴＳ−Ｓのステータスを自身のステータスと比較することによって、受信ＩＴＳ−Ｓは、発信ＩＴＳ−Ｓとのコリジョンのリスクを評価し、必要であればＨＭＩ（ヒューマンマシンインタフェース：Ｈｕｍａｎ Ｍａｃｈｉｎｅ Ｉｎｔｅｒｆａｃｅ）を介して運転者に知らせ得る。参照により本明細書に組み込まれている非特許文献１１のｖ１．３．１の７条に詳細に記載されているように、ＣＡＭは、１つの共通のＩＴＳ ＰＤＵヘッダと複数のコンテナから構成され、それらが一緒になってＣＡＭを構成する。ＩＴＳ ＰＤＵヘッダは、プロトコルバージョン、メッセージタイプ、および発信ＩＴＳ−ＳのＩＴＳ−Ｓ ＩＤについての情報を含んでいる共通のヘッダである。車両ＩＴＳ−Ｓについては、ＣＡＭは、１つの基本コンテナと１つの高頻度コンテナを含むものとし、１つの低頻度コンテナと１または複数の他の特別コンテナも含み得る。基本コンテナは、発信ＩＴＳ−Ｓに関連する基本情報を含んでいる。高頻度コンテナは、発信ＩＴＳ−Ｓの高度に動的な情報を含んでいる。低頻度コンテナは、発信ＩＴＳ−Ｓの静的な情報、および高度に動的ではない情報を含んでいる。特別車両コンテナは、発信車両ＩＴＳ−Ｓの車両役割に固有の情報を含んでいる。ＣＡＭの一般的な構成を図９に示す。

以下の表に、Ｖ２Ｖメッセージデータの異なるコンポーネントの概要およびパケットサイズを示す。

車両ＩＴＳ−Ｓは、少なくとも１つの高頻度車両コンテナ、および任意に低頻度車両コンテナを含むものとするＣＡＭを生成する。公共輸送など、道路トラフィックにおける特定の役割を持つ車両ＩＴＳ−Ｓは、特別車両コンテナ内にステータス情報を提供するものとする。

車両間で交換される各Ｖ２Ｖメッセージは、匿名性および完全性保護を含む、セキュリティ要件を満たさなければならない。異なるセキュリティ方式は、異なるセキュリティ性能およびオーバーヘッドレベルを有することができ、これはパケットサイズ（セキュリティオーバーヘッドに起因して）およびメッセージ頻度（例えば、どれくらいの頻度でセキュリティ証明書が添付されるか）に直接影響する。

ＥＴＩＳ ＩＴＳおよびＩＥＥＥ １６０９．２は両方とも、Ｖ２Ｘ通信のために公共鍵インフラストラクチャ（ＰＫＩ：ｐｕｂｌｉｃ ｋｅｙ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）ベースのセキュリティソリューションを考慮しており、非対称ベースのアプリケーションレイヤのセキュリティソリューションである。通常は、あらゆるＶ２Ｘメッセージは、匿名性および完全性保護を達成するために署名、および証明書または証明書のダイジェストのいずれかを伝える必要がある。署名、ダイジェスト、および証明書のための通常サイズは、それぞれ、６４バイト、８バイト、および１１７バイトである。

上記に説明したように、ＣＡＭメッセージは、異なる周期性および／または異なるメッセージサイズを有し得る。さらには、周期性は、速度、および進行方向または角度などの他の（影響の少ない）要因に応じて時間と共に変化さえし得る。概要を提供するために、可能性のある異なったメッセージコンポーネント（ＨＦ、ＬＦ、証明書）ならびに、結果としての、３つの異なった典型的な速度範囲に応じた周期性およびメッセージサイズを特定する、以下の表を提供する。

上記の表から明らかなように、コンポーネントのサイズ、したがってＣＡＭのサイズは、同じままであるが、それらの生成／送信頻度は、異なった速度範囲に応じて変化する。上記の表について、ＣＡＭ ＨＦコンポーネントは署名およびダイジェストと一緒に送信されると想定され、結果としてほぼ１２２バイトのメッセージサイズになる（すなわち、ヘッダのために８バイト、基本コンテナのために１８バイト、高頻度コンテナのために２３バイト、署名のために６４バイト、およびダイジェストのために８バイトを送信するのに十分である）。ＣＡＭ ＬＦコンポーネントは、高頻度コンポーネントにピギーバックされており、追加でほぼ６０バイトのサイズがあり、その結果、結果としての、すべてのコンテナ／コンポーネントを有するＣＡＭサイズは１８２バイトである。高頻度コンポーネントにピギーバックされている証明書コンポーネント（セキュリティコンポーネントとも称される）は、追加でほぼ１１７バイトのサイズがあり、その結果、結果としての、すべてのコンテナ／コンポーネントを有するＣＡＭサイズは２９９バイト、すなわちＣＡＭ ＬＦコンテナ／コンポーネント無しで２３９バイトである。

図１０は、上記で導入された３つの異なった速度範囲に応じた３つの異なったコンポーネントの発生、ならびにこのことがどのようにして、異なった全体のメッセージサイズおよび全体の周期性という結果になるかを示している。図１０において、破線の四角形は、異なったコンポーネントを含んでおり、コンポーネントは別々には送信されるのではなく１つのＣＡＭメッセージとして送信されることを示すものとする。

上記では、周期的な協調認識メッセージを極めて詳細に記載してきており、また、それらの異なった内容、固有の周期性およびメッセージサイズも規定している。ただし、上記の情報のいくつかは既に標準化されているが、周期性およびメッセージサイズなどのその他の情報は、まだ標準化されておらず、想定に基づいていることに留意すべきである。さらには、標準化は、将来変化し得、したがって、ＣＡＭがどのようにして生成および送信されるかについての側面も変化し得る。さらには、現在のところ、上記で論じた異なったコンポーネント（ＣＡＭ ＨＦ、ＣＡＭ ＬＦ、証明書）は、一緒に収まる場合には、一緒に、すなわち１つのメッセージとして送信されるが、このことは、必ずしもそうでなければならないとは限らない。将来は、これらのコンテナ／コンポーネントを互いに別々に送信もし得、そのときは、おそらくそれぞれにヘッダおよびもしかすると基本コンテナも含む。その結果として、ＣＡＭに関する上記の詳細な記載は、メッセージサイズおよび周期性は現実的であり、シミュレーション結果に基づいているが、説明目的のために考えられた一例として理解されるべきである。上記のＣＡＭメッセージおよびその内容、周期性、ならびにメッセージサイズは、本発明の基本原理を説明するために本願を通して使用される。本発明について重要なのは、周期的な方法で異なったデータを送信することをＶ２Ｖ通信が車両用ＵＥに要求することであり、（相対）速度、角度、進行方向、および場合によっては車両距離などの他の要因、などの車両ダイナミクスの関数として周期性が素早く変化し得ることが予測できる。その結果として、課題は、車両用ＵＥが、異なった周期かつ変化する周期の、異なったメッセージサイズのいくつかの周期的パケットを送信することができるものとすることである。

車両用ＵＥが、ＣＡＭを送信するためにサイドリンク上に無線リソースを有するために、上記で説明したように、モード１および／またはモード２無線リソース割当てが構想される。モード１無線リソース割当てについては、ｅＮＢは、ＳＡ期間毎にＳＡメッセージおよびデータのためにリソースを割り当てる。ただし、トラフィックが多いとき（例えば高頻度の周期的トラフィック）は、ＵＥからｅＮＢへのＵｕリンク上のオーバーヘッドは大きい可能性がある。

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

ただし、現在標準化されているセミパーシステント割当てのメカニズムは、改善し、Ｖ２Ｖトラフィックの要件および課題に適応する必要がある。

３ＧＰＰ ＴＳ ３６．２１１，"Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌｓ ａｎｄ Ｍｏｄｕｌａｔｉｏｎ（Ｒｅｌｅａｓｅ ８）" ３ＧＰＰ ＴＳ ３６．３２１ ３ＧＰＰ ＴＳ ３６．２１３ ３ＧＰＰ ＴＳ ３６．２１２，"Ｍｕｌｔｉｐｌｅｘｉｎｇ ａｎｄ ｃｈａｎｎｅｌ ｃｏｄｉｎｇ" ３ＧＰＰ ＴＳ ２３．４０１ ３ＧＰＰ ＴＳ ２３．２０３ ３ＧＰＰ ＴＲ ２３．７１３ ３ＧＰＰ ＴＳ ３６．３００ ３ＧＰＰ ＴＳ ２３．３０３ ３ＧＰＰ ＴＲ ２１．９０５ ＥＴＳＩ ＥＮ ３０２ ６３７−２ ＥＴＳＩ ＥＮ ３０２ ６３７−３ ３ＧＰＰ ＴＳ ３６．３３１

非限定的かつ例示的実施形態は、車両用移動端末用の車両通信のための改善されたリソース割当て方法を提供する。

独立請求項は、非限定的かつ例示的な実施形態を提供する。有利な実施形態は、従属請求項に従う。

それに応じて、１つの一般的な第１の態様では、ここで開示される技術は、周期的データを１または複数の受信エンティティに送信するための車両用移動端末を特徴としている。車両用移動端末は、可能性のある異なった送信周期性および／または可能性のある異なったメッセージサイズで送信されるべき１または複数の異なったデータコンポーネントを含む周期的データの送信をサポートする。車両用移動端末の送信部は、周期的データに関する情報を、無線リソースを車両用移動端末に割り当てる役割を担う無線基地局に送信する。送信された、周期的データに関する情報は、それによって無線基地局が、周期的データの１または複数のデータコンポーネントの、可能性のある異なった送信周期性および／または可能性のある異なったメッセージサイズを決定することができるようなものである。車両用移動端末の受信部は、受信した、周期的データに関する情報に基づいて無線基地局によって設定された複数のセミパーシステント無線リソース設定を、無線基地局から受信する。複数のセミパーシステント無線リソース設定のそれぞれは、サポートされるデータコンポーネントの少なくとも１つを送信するために使用することができるように構成される。次いで、送信部は、車両用移動端末によってデータコンポーネントの１または複数が送信されるべきであることを無線基地局に示す。受信部は、示されたデータコンポーネントのそれぞれを送信するために車両用移動端末のために無線リソースを周期的に割り当てるための複数のセミパーシステント無線リソース設定の１または複数をアクティブ化するためにアクティブ化コマンドを、無線基地局から受信する。次いで、送信部は、アクティブ化された１または複数のセミパーシステント無線リソース設定によって設定されたとおり、無線リソースおよび送信周期性に基づいて、１または複数のデータコンポーネントを、１または複数の受信エンティティに送信する。

それに応じて、１つの一般的な第１の態様では、ここで開示される技術は、周期的データを１または複数の受信エンティティに送信するために車両用移動端末に無線リソースを割り当てるための無線基地局を特徴としている。車両用移動端末は、可能性のある異なった送信周期性および／または可能性のある異なったメッセージサイズで送信されるべき１または複数の異なったデータコンポーネントを含む周期的データの送信をサポートする。無線基地局の受信部は、車両用移動端末によって１または複数の受信エンティティに送信されるべき周期的データに関する情報を、車両用移動端末から受信する。無線基地局のプロセッサは、サポートされる異なったデータコンポーネント、ならびに１または複数のデータコンポーネントの、可能性のある異なった送信周期性および／または可能性のある異なったメッセージサイズを決定する。プロセッサは、決定された送信周期性および／または決定されたメッセージサイズに基づいて、複数のセミパーシステント無線リソース設定を設定する。複数のセミパーシステント無線リソース設定のそれぞれは、サポートされるデータコンポーネントの少なくとも１つを送信するために使用することができるように構成される。無線基地局の送信部は、設定された複数のセミパーシステント無線リソース設定に関する情報を、車両用移動端末に送信する。受信部は、データコンポーネントの１または複数が車両用移動端末によって送信されるべきであるという指示情報を、車両用移動端末から受信する。次いで、プロセッサは、示されたデータコンポーネントのそれぞれを送信するために車両用移動端末のために無線リソースを周期的に割り当てるために車両用移動端末のためにアクティブ化されるべき複数のセミパーシステント無線リソース設定のうちの１または複数を選択する。送信部は、車両用移動端末のための選択された１または複数のセミパーシステント無線リソース設定をアクティブ化するために車両用移動端末にアクティブ化コマンドを送信するようにさらに構成される。

開示されている実施形態のさらなる利益および利点は、本明細書および図面から明らかであろう。これらの利益および／または利点は、本明細書および図面による開示内容のさまざまな実施形態および特徴によって個別に提供され得、これらの利益および／または利点の１または複数を得るためにすべてが提供される必要はない。

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

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

３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示している。 ３ＧＰＰ ＬＴＥ（リリース８／９）において定義されているサブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドを示している。 ＰｒｏＳｅ通信のためにＰＣ５を通じたレイヤ２リンクを確立する方法を模式的に示している。 オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムのための送信／受信リソースの使用を示している。 ２つのＵＥのためのスケジューリング割当ておよびＤ２Ｄデータの送信を示している。 ＵＥ自律スケジューリングモード２のためのＤ２Ｄ通信タイミングを示している。 ｅＮＢによってスケジューリングされるスケジューリングモード１のためのＤ２Ｄ通信タイミングを示している。 非ローミングシナリオのためのＰｒｏＳｅのための例示的なアーキテクチャモデルを示している。 ＣＡＭメッセージの例示的な構成を示している。 ３つの異なった速度範囲について、変化する周期性およびメッセージサイズでの、いくつかの異なったＣＡＭコンポーネントの送信を示している。 第１の実施形態の例示的な一実施態様に係る、３つの異なったＣＡＭコンポーネントの送信、およびＣＡＭの送信のための３つのＳＰＳ設定の使用を示している。 第１の実施形態のさらなる例示的な実施態様に係る、３つの異なったＣＡＭコンポーネントの送信、およびＣＡＭの送信のための３つのＳＰＳ設定の使用も示しており、ここでは、ＳＰＳ設定によって割り当てられた無線リソースが一緒に結合されている。 第１の実施形態のさらなる例示的な実施態様に係る、３つの異なったＣＡＭコンポーネントの送信、およびＣＡＭの送信のための３つのＳＰＳ設定の使用も示しており、ここでは、対応するＳＰＳ設定によって割り当てられた無線リソースが、完全なＣＡＭメッセージを送信するのに十分である。 第１の実施形態のさらなる例示的な実施態様に係る、３つの異なったＣＡＭコンポーネントの送信、およびＣＡＭの送信のための９つの異なったＳＰＳ設定の使用も示しており、車両用ＵＥが３つの異なる速度範囲をサポートすることを想定している。 第１の実施形態のさらなる例示的な実施態様に係る、３つの異なったＣＡＭコンポーネントの送信、およびＣＡＭの送信のための１０個の異なったＳＰＳ設定の使用も示しており、車両用ＵＥが３つの異なる速度範囲をサポートすることを想定している。

「移動局」または「移動ノード」または「ユーザ端末」または「ユーザ機器」は、通信ネットワーク内の物理エンティティである。１つのノードは、いくつかの機能エンティティを有し得る。機能エンティティとは、所定の一連の機能を、実施、および／または、ノードまたはネットワークの別の機能エンティティに提供する、ソフトウェアモジュールまたはハードウェアモジュールのことを指す。ノードは、それを通じてノードが通信することができる、通信機器または通信媒体にノードをアタッチする、１または複数のインタフェースを有し得る。同様に、ネットワークエンティティは、機能エンティティを、それを通じてネットワークエンティティが別の機能エンティティまたは通信相手ノードと通信し得る、通信機器または通信媒体にアタッチする論理インタフェースを有し得る。

特許請求の範囲一式および本願において使用されている用語「無線リソース」は、時間−周波数リソースなどの物理無線リソースのことを指すものと広義に理解されるべきである。

本願において使用されている用語「直接通信送信」は、２つのユーザ機器間の直接の、すなわち、無線基地局（例えばｅＮＢ）を介さない送信として広義に理解されるべきである。それに応じて、直接通信送信は、「直接サイドリンクコネクション」を通じて実行され、「直接サイドリンクコネクション」は、２つのユーザ機器間で直接的に確立されたコネクションを指して使用される用語である。例えば、３ＧＰＰにおいては、専門用語のＤ２Ｄ（Ｄｅｖｉｃｅ−ｔｏ−Ｄｅｖｉｃｅ）通信が使用され、またはＰｒｏＳｅ通信、またはサイドリンク通信が使用されている。用語「直接サイドリンクコネクション」は、背景技術のセクションで記載したＰＣ５インタフェースとして、広義に理解されるべきであり、３ＧＰＰの文脈において理解することができる。

本願において使用されている用語「ＰｒｏＳｅ」またはその略されていない形である「Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅｓ」は、背景技術のセクションで例示的に説明するように、ＬＴＥシステムにおける近傍ベースの（Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ）アプリケーションおよびサービスの文脈において適用される。「Ｄ２Ｄ」などの他の専門用語も、近傍サービスのためのＤｅｖｉｃｅ−ｔｏ−Ｄｅｖｉｃｅ通信を指して本文脈において使用されている。

本願を通して使用されている用語「車両用移動端末」は、背景技術のセクションで説明するように、新たな３ＧＰＰ検討項目Ｖ２Ｘ（車両用通信：ｖｅｈｉｃｕｌａｒ ｃｏｍｍｕｎｉｃａｔｉｏｎ）の文脈において理解されるべきである。それに応じて、車両用移動端末は、例えば安全性または運転者支援の目的で、車両用通信、すなわち、車両に関係する情報を他のエンティティ（車両、インフラ、歩行者など）に伝えることを実行するために、車両（例えば、乗用車、商用トラック、オートバイなど）に特に実装される移動端末として、広義に理解されるものとする。任意に、車両用移動端末は、地図情報などのナビゲーションシステム（それも自動車に実装されているという条件で）で利用可能な情報にアクセスでき得る。

背景技術のセクションで説明したように、３ＧＰＰは、ＬＴＥ支援（ＬＴＥ−ａｓｓｉｓｔｅｄ）の車両用通信のための新たな検討項目を導入しており、それは、さまざまな車両用移動端末と他の局との間でＶ２Ｖトラフィックを交換するためのＰｒｏＳｅ手順に基づくものとしている。さらには、セミパーシステント無線リソース割当ては、ｅＮＢによって実行されるスケジューリングの量を減らすように、モード１サイドリンク割当てのためのＶ２Ｖトラフィックによってサポートされるものとする。ただし、現在のＳＰＳメカニズムは、Ｖ２Ｖトラフィックおよびその特性に適合していない。例えば、Ｕｕリンク上での（すなわちｅＮＢとＵＥとの間の）通常のセミパーシステントスケジューリングのために、ｅＮＢはＭＭＥ（移動管理エンティティ）からＱＣＩ情報（ＱｏＳクラス識別子）を受信する。ＱＣＩ情報は、ｅＮＢとＵＥとの間で構成されたある特定のベアラがＶｏＩＰトラフィックを伝送するように構成されることを示し、その結果、ｅＮＢは当該ベアラ上でＵＥによって生成される周期的トラフィックのことを学習する。次いで、ｅＮＢは、ＳＰＳ周期性を設定するためにＵＥにＲＲＣシグナリングを送信することによって、ＵＥのためにセミパーシステント無線リソース割当てを設定することができる。次いで、当該のベアラを通じてＵＥがＶｏＩＰデータを実際に送信する必要があり、およびＶｏＩＰトラフィックのために送信されるべきデータが存在することを示す対応するバッファ状態通知を送信するとき、ｅＮＢは、ＳＰＳ設定をアクティブ化するためにＰＤＣＣＨをＵＥに送信し、そのＳＰＳ設定の中で、ＰＤＣＣＨメッセージは、ＵＥがどの無線リソースを周期的に使用することを許可されるのかも示す（このようにして、特定量の無線リソースを割り当てる）。それに応じて、ＵＥは、ＶｏＩＰトラフィックを周期的に送信するためにＳＰＳリソースを使用する。

ただし、ｅＮＢは、サイドリンクコネクションを通じて特定の車両によって送信されるトラフィックタイプ（例えば、周期性またはメッセージサイズ）についての知識を有しておらず、その結果、ｅＮＢは、セミパーシステント無線リソース割当てを通して割り当てるべきリソースの量も、これらのセミパーシステント無線リソースの周期性も適切に決定することができない。

たとえ、ｅＮＢが、車両用ＵＥによって送信されるべきトラフィックについての情報を何とかして受信したとしても、車両用ＵＥが、異なった周期性および／または異なったメッセージサイズのＶ２Ｖトラフィックを送信しなければならないことに留意すべきであり、このことは、それ用に現在のＳＰＳメカニズムが設計されたＶｏＩＰトラフィックタイプとは著しく異なる。さらには、Ｖ２Ｖトラフィックが送信されるべき周期性は、例えば、車両が走行する速度などの車両ダイナミクスに応じて、周期性が変化し得るので可変である。そのため、現在標準化されているＳＰＳメカニズムは、これら異なったＶ２Ｖ使用シナリオに対処するには不十分である。

以下の例示的な実施形態は、上記に説明した問題の１または複数を緩和するために発明家によって着想されている。

さまざまな実施形態の特定の実施態様は、さまざまな実施形態に関係して、以下に説明するように特定の主要な特徴が追加され、３ＧＰＰ標準によって与えられ、背景技術のセクションにおいて部分的に説明しているように、広い仕様で実施されるべきである。実施形態は、上記の技術背景のセクションに記載の３ＧＰＰ ＬＴＥ−Ａ（リリース１０／１１／１２／１３）の通信システム（または後のリリース）などの、例えば移動通信システムにおいて有利に使用し得るが、実施形態は、この特定の例示的な通信ネットワークにおいてのそれの使用に限定されるものではないことに留意すべきである。

説明は、本開示の範囲を制限するものとして解釈されるべきではなく、本開示をよりよく理解するための実施形態の単なる例として解釈されるべきである。当業者は、特許請求の範囲に明確に述べた本開示の一般的な原理は、異なったシナリオに対して、および、本明細書に明示的に記載していない方法で、適用することができるということを分かっているべきである。説明のために、いくつかの想定が行われているが、ただし、それらは以下の実施形態の範囲を制限しないものとする。

さまざまな実施形態は、（車両用の）ＵＥと、無線リソースを（車両用の）ＵＥに割り当てる役割を担うｅＮＢとの間の、改善されたセミパーシステントリソース割当て手順を主に提供する。そのため、他の機能性（すなわち、さまざまな実施形態によって変化しない機能性）は、背景技術のセクションで説明したのとまったく同じままであり得るか、またはさまざまな実施形態に対していかなる結果ももたらさずに変更され得る。これは、例えば、車両用ＵＥが適切なセミパーシステント無線リソースを割り当てられた後、周期的データの実際の送信が車両用ＵＥによってどのようにして実行されるかに関する他の手順を含む。

（第１の実施形態）
以下では、上述の問題を解決するための第１の実施形態を詳細に記載する。第１の実施形態の異なった実施態様およびさまざまな変化形も説明する。

例示的に、車両に実装され、本願の背景技術のセクションで説明したＤ２Ｄの枠組みに基づいて車両用通信を実行することができる車両用ＵＥが想定されている。ただし、後により詳細に説明するように、本発明の根底にある原理は、車両用ＵＥによって単に適用されるように制約されるのではなく、例えば、Ｕｕインタフェースを介してｅＮＢへ、またはＰＣ５インタフェース（サイドリンクコネクション）を介して他のＵＥへ周期データを送信する通常の（すなわち非車両用）ＵＥによっても実施され得る。とはいえ、以下の議論については、Ｖ２Ｖデータを周期的に送信する必要のある車両用ＵＥであることが想定されている。

周期的データが他の（車両用）ＵＥ（ＰＣ５インタフェースを介して）、それのｅＮＢ（Ｕｕインタフェースを介して）、路側機（場合によってはＰＣ５インタフェースを介して）、および／または、車両用ＵＥによって送信される周期的データに関心がある他の適切な局に送信されることも可能であり得るが、車両用ＵＥが他の（車両用）ＵＥ宛の周期的データを送信（ブロードキャスト）することがさらに想定されており、車両用ＵＥからの送信は、ポイントツーマルチポイントであると想定することができるのでそれのエリア内のすべての受信エンティティに届く。

車両用ＵＥによって送信されるべき周期的データは、例えば、背景技術のセクションで詳細に説明した協調認識メッセージ（ＣＡＭ）である。本発明に関係するＣＡＭの特性は、ＣＡＭが周期的な形で送信されることである。ただし、ＣＡＭは、異なった、変化さえする送信周期性および／または異なったメッセージサイズ（すなわち、送信されるべき、そしてそれのために車両用ＵＥが無線リソースを必要とする、データ量）が存在するという点で、セミパーシステントスケジューリングシナリオの通常のＶｏＩＰ使用のシナリオとは大きく異なっている。ＶｏＩＰは、セミパーシステント無線リソース割当てによって扱いやすい固定の周期性および固定のメッセージサイズを明示している。

ＣＡＭは、こうした周期的データの単なる一例に過ぎないこと、および本発明は、車両用または非車両用の通信のために将来標準化され得る他のデータタイプにも適用し得ることに留意するべきである。特に車両用の通信については、車両用ＵＥは、異なったおよび／または変化さえする周期性で（ステータスおよび属性）データを周期的にブロードキャストしなければならない可能性が高いため、異なった周期性に起因して、異なったタイムインスタンスで、より多くのデータまたはより少ないデータを有するメッセージを送信しなければならないことがあり得る。

以下で詳細に説明するように、ＣＡＭメッセージはこの種の周期的データの適切な例であるため、今述べたように、本発明がそれに制限されるわけではないが、第１の実施形態およびその変化形を説明するために使用される。

車両用ＵＥによって周期的に、しかし異なった周期性で、ブロードキャストされる必要がある異なったＣＡＭコンポーネント（例えば、ＣＡＭ ＨＦ、ＣＡＭ ＬＦ、証明書は、それに基づいて以下で本発明を説明する、ＣＡＭコンポーネントである）が存在する。以下では、特定のタイムインスタンスにおいて１つのＣＡＭメッセージのみが車両用ＵＥによって送信／ブロードキャストされ、ただし前記ＣＡＭメッセージは、当該のタイムインスタンスにおいて送信されるべき、異なったＣＡＭコンポーネント（すなわち、異なった周期性を有していることにかかわらず、当該のタイムインスタンスにおいて発生するＣＡＭコンポーネント）を含んでいることが、大部分において想定されている。言い換えれば、異なったＣＡＭコンポーネントが車両用ＵＥによって同時に（ＰＣ５インタフェースのＳＣ期間）送信されるべきケースでは、異なったＣＡＭコンポーネントが一緒にピギーバックされて単一のＣＡＭメッセージを形成し、次いでそれが送信される。ピギーバックすることが実際に機能するために、異なったＣＡＭコンポーネントが特定の同じタイムインスタンスにおいて実際に占拠するように、異なったＣＡＭコンポーネントの周期性が調整される（すなわち、互いの倍数である）必要がある。このように、単一のＣＡＭは、単一の周期性（送信されるべきＣＡＭコンポーネントの最高送信速度によって与えられる（例えば、ＣＡＭ ＨＦコンポーネント））ではあるが、異なった内容、およびそのため異なったメッセージサイズ（すなわち、異なったタイムインスタンスにおいて異なったＣＡＭコンポーネントが単一のＣＡＭメッセージに含まれる）で、周期的な形で送信され、その異なったメッセージサイズも周期的に変化する（例えば図１０および関連する記載を参照）。このように、無線リソース割当てメカニズムは、異なったタイムインスタンスにおいて異なった量の無線リソースを割り当てる必要がある。

あるいは、異なった周期性を有する異なったＣＡＭコンポーネントは別々のＣＡＭメッセージとして送信することも可能である。別々のＣＡＭメッセージのそれぞれが、少なくともヘッダ、および場合によっては基本コンテナ（図９および関連する記載を参照）も含む必要があることになり得るため、より多くの無線リソースが必要とされることを考慮すると、これは不利になり得るが、これは、第１の代替案においてＣＡＭコンポーネントを一緒にピギーバックすることによって回避される。ただし、別々のＣＡＭメッセージを提供することには、それぞれのＣＡＭコンポーネントの異なった周期性を調整する必要性を回避し得る、すなわち、それぞれのＣＡＭコンポーネントの周期性を自由に定義し得る、という利点がある。この場合、ＣＡＭメッセージは、異なる周期性および異なるメッセージサイズを有している。

３ＧＰＰ標準化は、異なったＣＡＭコンポーネントの送信速度について、ピギーバックすることを任意とするのかそれとも必須とするのかについて、または厳密にどのようにして、異なったＣＡＭコンポーネントが送信されるのかについて、まだ完全には合意していない。いずれの場合も、将来のリリースで変更されることになり得る。本発明の根本の原理は、これらの変更を構成するためにわずかな適合を適用しなければならないことになり得る場合でも、これらの変更のいずれにも適用することができる。

以下では、特定のタイムインスタンスにおいて１つのＣＡＭメッセージのみが車両用ＵＥによって送信されること、すなわち、異なったＣＡＭコンポーネントが単一のＣＡＭメッセージを形成することが、主に想定される。

さらには、要求された、ＣＡＭコンポーネントの送信周期性は、速度、進行方向、および／または角度などの車両ダイナミクスの関数として時間と共に素早く変化し得、場合によると他の要因が将来定義され得ることが予想される。

要約すると、（車両用）ＵＥは、他の受信エンティティ（例えば、車両用の他の局）に周期的データ（例えばＣＡＭ）を送信する。周期的データを送信するために、車両用ＵＥは、例えば、背景技術のセクションで説明したＰｒｏＳｅモード１無線リソース割当てに従って、例えばｅＮＢによって割り当てられ得る無線リソースを必要とする。第１の実施形態によれば、それによって車両用ＵＥが、待機中の周期的データを周期的に送信することができるように、ｅＮｏｄｅＢが、車両用ＵＥにセミパーシステント無線リソースを割り当てる。

概要をあらかじめ提供すると、第１の実施形態は準備フェーズと実行フェーズとに概念的に分割され得る。準備フェーズでは、車両用ＵＥによってサポートされており、したがって将来車両用ＵＥによって送信され得る、周期的データの、後の送信のために、異なったＳＰＳ設定がｅＮｏｄｅＢによって設定される。車両用ＵＥは、必要に応じて実行フェーズの間にアクティブ化され得るさまざまな異なったＳＰＳを設定される。実行フェーズは、車両用ＵＥによる、サポートされる周期的データの一部またはすべての送信が始まるときに始まるものと見なされ得る。それに応じて、前に用意されたＳＰＳ設定のうちの、特定のＳＰＳ設定がＵＥ内でアクティブ化され、次いで、待機中の周期的データを送信するために車両用ＵＥによって使用される。実行フェーズの間、待機中の周期的データのメッセージサイズまたは周期性のいずれかが変化し得、その結果、前に用意されたＳＰＳ設定のうちの、異なったＳＰＳ設定が、異なった周期性で、または異なったメッセージサイズで周期的データを送信することがなおもできるように、車両用ＵＥ内でアクティブ化されなければならない。

ここで、準備フェーズをさらに詳しく説明する。ｅＮｏｄｅＢが、ＵＥによってサポートされる周期的データのために適切なＳＰＳ設定をセットアップすることができるために、ｅＮｏｄｅＢは、将来車両用ＵＥによって送信され得る周期的データについて知る必要がある。通常、ＳＰＳ設定は、特定の量の無線リソースを、周期的な形で（すなわち周期的なタイムインスタンスにおいて）割り当て、特定の量の無線リソースは、ＵＥが送信する必要のあるデータ量（例えばＣＡＭメッセージのサイズ）に依存する。それに応じて、ｅＮｏｄｅＢが、車両用ＵＥによって将来送信され得る、１または複数の、可能性のある異なった周期性および／または可能性のある異なったメッセージサイズを決定することができるように、車両用ＵＥは、周期的データに関する情報をｅＮｏｄｅＢに送信する。この情報を学習して、その結果、車両用ＵＥのためにこれらのＳＰＳ設定の１または複数を後にアクティブ化することによって、車両用ＵＥが、アクティブ化されたＳＰＳ設定によって周期的に割り当てられた無線リソースを使用して、サポートされる周期的データの１または複数を実際に送信することができるようにされるような方法で、ｅＮｏｄｅＢは、複数の異なったＳＰＳ設定を設定することができる。

このように、複数のＳＰＳ設定をセットアップしてしまった後、将来アクティブ化され得る複数のＳＰＳ設定を車両用ＵＥが知るように、ｅＮｏｄｅＢは、複数のＳＰＳ設定に関する対応する情報を車両用ＵＥに提供する。このようにして、ｅＮｏｄｅＢおよび車両用ＵＥは、サポートされる周期的データの１または複数の送信を扱う準備が整う。

ここで、実行フェーズをさらに詳しく説明する。次に、車両用ＵＥが、最終的に、ＣＡＭデータコンポーネントの一部またはすべてを送信したくなって、送信を実行するために（セミパーシステントに割り当てられた）無線リソースを必要とすることが想定されている。それに応じて、車両用ＵＥは、自身がどのＣＡＭコンポーネントを送信したいのかについてｅＮＢに知らせ、ｅＮＢは、応答として、あらかじめ用意されたＳＰＳ設定のうちから、現在待機中のＣＡＭコンポーネントのすべてを送信するように適切な無線リソースを車両用ＵＥに割り当てる、１または複数のＳＰＳ設定を選択する。次いで、それに応じてｅＮＢは、例えば、適切なアクティブ化コマンドを送信することによって、ＵＥ内の選択された１または複数のＳＰＳ設定をアクティブ化する。

それに応じて車両用ＵＥは、ｅＮｏｄｅＢによって命令されたとおり、特定のＳＰＳ設定をアクティブ化するので、待機中の１または複数のＣＡＭデータコンポーネントを他の（車両用）ＵＥに送信するために、アクティブ化されたＳＰＳ設定によってスケジューリングされた周期的無線リソースを使用することができる。

上記に説明したように、第１の実施形態によれば、車両用ＵＥによって送信されるべきデータの周期性および／またはメッセージサイズが変化し得る場合でも、ＳＰＳリソースを車両用ＵＥに割り当てることが可能である。その結果として、そうでない場合はＳＣ期間毎に動的無線リソース割当て（例えば、背景技術のセクションのＰｒｏＳｅモード１の説明を参照）を繰り返し実行する必要のある、ｅＮｏｄｅＢとＵＥとの間のＵｕリンク上のシグナリングオーバーヘッドを軽減することが可能である。さらには、（周期的）データが送信待機中であることを示すために車両用ＵＥによって使用されるバッファ状態通知は、ＵＥ側にやって来る周期的データがあるたびに動的リソースを割り当てることをトリガするためにＵＥからｅＮＢに送信する必要がない。

図１１は、第１の実施形態の例示的な一実施態様に係る、３つの異なったＣＡＭコンポーネント（証明書、ＣＡＭ ＬＦコンポーネント、およびＣＡＭ ＨＦコンポーネント）の送信を可能にするために３つの異なったＳＰＳ設定がアクティブ化されることを例示的に示している。第１の実施形態のこの例示的な実施態様については、１つの特定のＣＡＭデータコンポーネントのために１つのＳＰＳ設定が設定される。それに応じて、３つの異なったＣＡＭコンポーネントを送信したい車両用ＵＥは、ＣＡＭ ＨＦコンポーネントを送信するために、ＳＰＳ設定１によって割り当てられた周期的無線リソースを使用することができ、ＣＡＭ ＬＦコンポーネントを送信するために、ＳＰＳ設定２によって割り当てられた周期的無線リソースを使用することができ、証明書を送信するために、ＳＰＳ設定３によって割り当てられた周期的無線リソースを使用することができる。

異なったＣＡＭコンポーネントが１つのメッセージで、それとも別々のメッセージで送信されるのかに依存して、異なったＳＰＳ設定は、より大きな結合されたＣＡＭメッセージを送信することができるように車両用ＵＥによって結合することができるか、または別々のＣＡＭメッセージを送信するために互いに別々に使用され得る。

第１の実施形態がとり得る、より具体的な実施態様を以下に示す。

第１の実施形態の広範な実施態様では、車両用ＵＥが、可能性のある異なった送信周期性および／または可能性のある異なったメッセージサイズで送信されるべき１または複数の異なったデータコンポーネントを含む周期的データの送信をサポートするということが、より詳細に述べてはいないが想定されている。上記に説明したように、第１の実施形態のＳＰＳ割当てメカニズムに課せられた課題は、車両用データの送信が、可能性のある異なった周期性および／または異なったメッセージサイズを伴うということである。このことを、背景技術のセクションで紹介したＣＡＭメッセージに基づいてより詳細に説明する。

可能性のある例示的な一シナリオによれば、車両用ＵＥは、いくつかのＣＡＭコンポーネント、例えばＣＡＭ ＨＦコンポーネント、ＣＡＭ ＬＦコンポーネント、およびセキュリティ証明書の送信をサポートする。それに応じて、可能性のあるメッセージサイズは、ＣＡＭメッセージでどのＣＡＭコンポーネントが送信されるのかによって異なる。可能性のある異なったメッセージサイズの概要は、以下の表で与えられる。

上記の表について、同じタイムインスタンスにおいて送信された異なったＣＡＭコンポーネントは、ＣＡＭ ＬＦコンポーネントおよびＣＡＭセキュリティ証明書が、最高の送信速度で送信される基本ＣＡＭ ＨＦコンポーネントにそれぞれピギーバックされるような１つの単一ＣＡＭメッセージを形成することが想定されている。それに応じて、メッセージサイズは、表の右側の列に挙げられているように、および図１１に例示的に示しているように、タイムインスタンスに応じて変化する（想定された、ＣＡＭコンポーネントの異なった周期性に起因して、図１１は、ＣＡＭ ＨＦコンポーネント＋ＣＡＭセキュリティ証明書の送信を示しておらず、前記の点においては、図１０の中央部分を参照）。

異なったＣＡＭコンポーネントは、特定のタイムインスタンスにおいて送信されるべき、可能性のあるＣＡＭメッセージのそれぞれが、以下の表で例示的に示すように異なった周期性で送信されなければならないように、異なった周期性で送信されるべきである。

上記で想定されている送信周期性の値は、最低の送信速度を持つ、ＣＡＭメッセージ内の当該のＣＡＭコンポーネントの周期性（例えば、ＣＡＭ ＨＦコンポーネントおよびＣＡＭ ＬＦコンポーネントを含むＣＡＭメッセージについては、ＣＡＭ ＬＦコンポーネントの５００ｍｓ）に実際に関係している。示された送信周期性は、特定のＣＡＭメッセージの送信周期性として理解されるべきではない。例えば、ＣＡＭ ＨＦコンポーネントおよびＣＡＭ ＬＦコンポーネントを含むＣＡＭメッセージは、実際に５００ｍｓ毎には送信されない（１０００ｍｓ毎に送信され、図１１を参照）。

送信周期性について上記の表で例示的に想定された値は、１４４ｋｍ／ｈ超の単一の車両速度範囲について想定されたものであり、その速度範囲が、車両用ＵＥによってサポートされるただ１つのものであると想定されている。

可能性のある別の例示的なシナリオによれば、車両用ＵＥは、１つのＣＡＭコンポーネントのみ、例えばＣＡＭ ＨＦコンポーネント、したがって、予測される固定サイズが１２２バイト（上記の表を参照）で、予測される固定周期性が１００ｍｓ（上表を参照）の送信をサポートする。ただし、Ｖ２Ｖデータの特殊な特性は、異なったＣＡＭコンポーネントの周期性が車両ダイナミクス、例えば車両用ＵＥが走行している速度によって変化し得ることである。その結果、車両用ＵＥが１つのＣＡＭコンポーネントのみの送信をサポートしている場合でも、１つのＣＡＭコンポーネントが送信されるべき周期性がやがて変化し、ＳＰＳ割当てメカニズムによっていくつかの周期性が考慮に入れられる必要があるという結果を再びもたらし得る。これを、以下の表に例示する。

可能性のある別の例示的なシナリオによれば、車両用ＵＥは、さまざまなＣＡＭコンポーネント（例えばＣＡＭ ＨＦ、ＣＡＭ ＬＦ、およびセキュリティ証明書の３つのすべてのＣＡＭコンポーネント）の送信をサポートし、それに加えていくつかの速度（範囲）をサポートするものとする。結果としての変化する周期性およびメッセージサイズは、以下の表から明らかになる。

上記に例示したように、多くの異なった、ＣＡＭコンポーネントの組合せ（上記の表の左側の列）が存在し得、可能性のある異なったＣＡＭメッセージサイズ（例えば１２２バイト、１８２バイト、２９９バイト、または２３９バイト）という結果をもたらし、また、車両用ＵＥのための特定のＣＡＭコンポーネントおよび／または場合によってはサポートされる速度（範囲）に応じて、可能性のある異なった周期性（例えば１００ｍｓ、２００ｍｓ、３００ｍｓ、５００ｍｓ、６００ｍｓ、１０００ｍｓ、１２００ｍｓ）という結果をもたらす。準備フェーズにおいてｅＮＢによって設定されるＳＰＳ設定は、このことを考慮に入れる必要があり、車両用ＵＥが、サポートされる周期的データのいずれか（組合せ）を送信することができるように、適切なＳＰＳ設定が後にアクティブ化されるように、車両用ＵＥによってサポートされる、結果としてのＣＡＭメッセージ送信周期性および／または結果としてのＣＡＭメッセージサイズと一致するものとする。

上記の選択された例について例示するように、さまざまな異なったＳＰＳ設定が、ｅＮｏｄｅＢによって用意される。特に、最初は、簡潔にするため、いくつかの異なった周期性が考量に入れられるべきではあるが、周期性自体は時間と共に（例えば、速度変化に起因して）変化しないように、車両用ＵＥは、いくつかのＣＡＭコンポーネントの送信をサポートするが、１つの速度範囲、例えば１４４ｋｍ／ｈ超の最高の速度範囲のみをサポートすることが想定される。

上記の、第１の実施形態の例示的な実施態様では、車両用ＵＥが送信するようにサポートされる、可能性のあるＣＡＭコンポーネントのそれぞれに一致する１つの別々のＳＰＳ設定が存在するように、３つの異なったＳＰＳ設定１、２および３が、ｅＮｏｄｅＢによって設定される。可能性のある、ＣＡＭ ＨＦコンポーネントとＣＡＭセキュリティ証明書との組合せについては、別々のＣＡＭコンポーネントのための例示的な周期性に起因してこの特定の組合せは起こらないことを考慮して、この特定の例では別々のＳＰＳ設定は必要ではないことに留意するべきである。

ＳＰＳ設定１は、ＣＡＭ ＨＦコンポーネントの周期性である１００ｍｓ毎に１２２バイトの基本のＣＡＭ ＨＦコンポーネントを送信するのに十分な特定の無線リソースを割り当てる。それに応じて、ＵＥは、ＣＡＭ ＨＦコンポーネントを含むＣＡＭメッセージを送信するために、ＳＰＳ設定１によって割り当てられた周期的無線リソースを使用する。

また、ＳＰＳ設定２は、ＣＡＭ ＬＦコンポーネントの周期性である５００ｍｓ毎に６０バイトの追加の（ピギーバックされた）ＣＡＭ ＬＦコンポーネントを送信するのに十分な特定の無線リソースを割り当てる。それに応じて、ＵＥは、ＣＡＭ ＬＦコンポーネントを含むＣＡＭメッセージを送信するために、ＳＰＳ設定２によって割り当てられた周期的無線リソースを使用する。さらには、ＳＰＳ設定３は、セキュリティ証明書の周期性に対応した１０００ｍｓ毎に１１７バイトの追加の（ピギーバックされた）セキュリティ証明書を送信するのに十分な特定の無線リソースを割り当てる。それに応じて、ＵＥは、セキュリティ証明書を含むＣＡＭメッセージを送信するために、ＳＰＳ設定３によって割り当てられた周期的無線リソースを使用する。

図１２は、第１の実施形態の例示的な一実施態様に係る、車両用ＵＥによるＣＡＭメッセージの送信について上記で例示的に想定した３つのＳＰＳ設定の使用を示している。図１２から明らかなように、３つのＳＰＳ設定は、車両用ＵＥによって送信されるべき３つの異なったデータコンポーネントに一致している。同じタイムインスタンスにおいて送信されるべき複数のデータコンポーネントを包含している破線の四角は、上記で例示的に想定したように、これらの異なったデータコンポーネントが１つのＣＡＭメッセージとして送信されることを示すものとする。図１２から明らかなように、いくつかのＣＡＭコンポーネントが１つのＣＡＭメッセージ内で送信されるべきタイムインスタンスにおいて、車両用ＵＥは、ＣＡＭメッセージ全体（すなわち、複数のＣＡＭコンポーネントを含む）を送信するために利用可能な十分な無線リソースを有するように、複数のＳＰＳ設定によって割り当てられた無線リソースを結合する。例えば、ＣＡＭ ＨＦコンポーネントをＣＡＭ ＬＦコンポーネントと一緒に送信するとき、ＳＰＳ設定１および２を介して割り当てられた無線リソースが結合されて（すなわち、合計され、ともに使用されて）、その結果、送信に利用可能な十分な無線リソースを有す。同様に、ＣＡＭ ＨＦコンポーネントをＣＡＭ ＬＦコンポーネントおよびセキュリティ証明書と一緒に送信するとき、ＳＰＳ設定１、２および３を介して割り当てられた無線リソースが結合されて、その結果、結合されたＣＡＭメッセージ全体を送信するために利用可能な十分な無線リソースを有す。

ちょうど説明したように、異なったＳＰＳ設定によって割り当てられた無線リソースは、車両用ＵＥがより大きな結合されたＣＡＭメッセージを送信するタイムインスタンスのために結合されなければならない場合がある。以下の、第１の実施形態の代替的な実施態様によれば、ＳＰＳ設定によって別々に割り当てられた無線リソースのこの結合は、もはや必要ではない。代わりに、別々のＳＰＳ設定は、結果としての、単一のＣＡＭメッセージのサイズをあらかじめ考慮に入れたような方法で、設定される。上記の議論に沿って、以下の表は、第１の実施形態のこの代替的な実施態様を例示的に示している。

表から明らかなように、ＳＰＳ設定は、それぞれのＳＰＳ設定によって割り当てられた無線リソースの量がより大きく、それによって、いくつかのＣＡＭコンポーネントが１つのＣＡＭメッセージ内で送信されるときにより大きなＣＡＭメッセージサイズを考慮に入れている点が、前の実施態様とは異なる。

図１２に対応して、図１３は、周期的なＣＡＭデータ（コンポーネント）を送信するために異なったＳＰＳ設定が車両用ＵＥによってどのように使用されるかを示している。車両用ＵＥが１つのＣＡＭメッセージ内でいくつかのＣＡＭコンポーネントを送信するタイムインスタンスにおいて、車両用ＵＥは、アクティブ化されているＳＰＳ設定のうち、より大きなＣＡＭメッセージを送信するのに十分な無線リソースを提供するＳＰＳ設定を選択するものとする。第１の実施形態の、前の例示的な実施態様にあるように、車両用ＵＥは、ＣＡＭ ＨＦコンポーネントのみを含むＣＡＭメッセージを送信するためにＳＰＳ設定１を選択する。一方で、ＣＡＭ ＨＦコンポーネントをＣＡＭ ＬＦコンポーネントと一緒に送信するとき、合計で１８２バイトを送信するために無線リソースが必要とされ、その結果、ＣＡＭ ＨＦコンポーネントおよびＣＡＭ ＬＦコンポーネントを含む前記ＣＡＭメッセージを送信するために、車両ＵＥは、ＳＰＳ設定２を選択し、ＳＰＳ設定２によって割り当てられた特定の無線リソースを使用するものとする。それに対応して、ＣＡＭ ＨＦコンポーネントをＣＡＭ ＬＦコンポーネントおよびセキュリティ証明書と一緒に送信するとき、合計で２９９バイトを送信するために無線リソースが必要とされ、その結果、車両用ＵＥは、ＳＰＳ設定３を選択するものとする。このように、車両用ＵＥは、３つのコンポーネントを含む前記ＣＡＭメッセージを送信するために、ＳＰＳ設定３によって割り当てられた特定の無線リソースを使用する。

図１２および図１３に従った、第１の実施形態の上記で論じた実施態様は、車両用ＵＥが、いくつかの速度範囲、例えば、３つの想定された速度範囲の、１４４超、７２〜１４４、および４８〜７２、もサポートする、より複雑なケースにも適用することができ、それぞれのＣＡＭコンポーネントのためにサポートされる追加の異なった周期性を結果としてもたらす。

以下の表は、異なったＳＰＳ設定によって割り当てられた無線リソースは、いくつかのデータコンポーネントを含む結合されたＣＡＭメッセージを送信することができるように十分な無線リソースを集めるために、車両用ＵＥによって結合することができることを想定している（図１２についての議論を参照）。

上記の表から明らかなように、準備フェーズにおいてｅＮｏｄｅＢは、後に１または複数のＳＰＳ設定をアクティブ化した時点で車両用ＵＥが、対応するＣＡＭコンポーネントを周期的な方法で送信することができるようにするように、適切な周期性で無線リソースをそれぞれ割り当てる、９つの別々のＳＰＳ設定を設定する。

車両用ＵＥの現在の速度に応じて、ｅＮｏｄｅＢは、速度が１４４ｋｍ／ｈ超のときはＳＰＳ設定１、２、および３のいずれかをアクティブ化し、または速度が７２ｋｍ／ｈ〜１４４ｋｍ／ｈのときはＳＰＳ設定４、５、および６をアクティブ化し、または速度が４８ｋｍ／ｈ〜７２ｋｍ／ｈのときはＳＰＳ設定７、８、および９をアクティブ化しているように車両用ＵＥを設定する。

図１４は、９つの別々のＳＰＳ設定を、異なったサイズのＣＡＭメッセージを周期的に送信するために車両用ＵＥによって使用することができる方法を示している。図１４の上の部分（すなわち、速度１４４ｋｍ／ｈ超を参照して）は、基本的に図１２に対応しているため、再度説明はしない。速度範囲７２ｋｍ／ｈ〜１４４ｋｍ／ｈについて、図１４は、異なったサイズのＣＡＭメッセージを送信することができるようにするように、車両用ＵＥが、アクティブ化されたＳＰＳ設定４、５、および６によって割り当てられた無線リソースをどのようにして結合するかを示している。特に、ＣＡＭ ＨＦコンポーネントおよびＣＡＭ ＬＦコンポーネントから構成されたＣＡＭメッセージは、ＳＰＳ設定４および５によって割り当てられた無線リソースを結合することによって、車両用ＵＥによって送信し得る。３つのコンポーネントすべて（ＣＡＭ ＨＦ、ＣＡＭ ＬＦ、セキュリティ証明書）から構成されたＣＡＭメッセージは、ＳＰＳ設定４、５および６によって割り当てられた無線リソースを結合し、および使用することによって、車両用ＵＥによって送信することができる。ＣＡＭ ＨＦコンポーネントおよびセキュリティ証明書から構成されたＣＡＭメッセージは、ＳＰＳ設定４および６によって割り当てられた無線リソースを結合および使用することによって、車両用ＵＥによって送信することができる。

速度範囲４８ｋｍ／ｈ〜７２ｋｍ／ｈについて、図１４は、異なったサイズのＣＡＭメッセージを送信することができるように、車両用ＵＥが、アクティブ化されたＳＰＳ設定７、８、および９によって割り当てられた無線リソースをどのようにして結合するかを示している。特に、ＣＡＭ ＨＦコンポーネントおよびＣＡＭ ＬＦコンポーネントから構成されたＣＡＭメッセージは、ＳＰＳ設定７および８によって割り当てられた無線リソースを結合することによって、車両用ＵＥによって送信し得る。３つのコンポーネントすべて（ＣＡＭ ＨＦ、ＣＡＭ ＬＦ、セキュリティ証明書）から構成されたＣＡＭメッセージは、ＳＰＳ設定７、８および９によって割り当てられた無線リソースを結合および使用することによって、車両用ＵＥによって送信することができる。

以下では、図１３と関連付けて説明した、第１の実施形態の代替的な実施態様は、ここでいくつかの速度範囲をサポートする車両用ＵＥにも拡張することができる。

図１５は、可能性のあるさまざまなＣＡＭメッセージを送信するための、車両用ＵＥによる、対応する、異なったＳＰＳ設定の使用を示している。図１５の上の部分（速度１４４ｋｍ／ｈ超を参照して）は、基本的に図１３に対応しているため、再度説明はしない。速度範囲７２ｋｍ／ｈ〜１４４ｋｍ／ｈについて、可能性のあるすべてのＣＡＭコンポーネントの送信をサポートするために、４つの異なったＳＰＳ設定がｅＮｏｄｅＢによって設定される。速度範囲１４４ｋｍ／ｈ超についてのシナリオとは異なり、車両用ＵＥは実際、ＣＡＭ ＨＦコンポーネントおよびＣＡＭセキュリティ証明書から構成されるＣＡＭメッセージを送信しなければならない。第１の実施形態のこの代替的な実施態様では、ｅＮｏｄｅＢは、可能性のあるこのＣＡＭメッセージのために、このように別々のＳＰＳ設定、すなわち、１０００ｍｓ毎に２３９バイトを送信するのに十分な特定の無線リソースを割り当てるＳＰＳ設定７、を設定しなければならない。ＳＰＳ設定４および６の無線リソースが、ＣＡＭ ＨＦコンポーネントおよびセキュリティ証明書から構成されるＣＡＭメッセージを送信するために十分な（しかし多すぎない）リソースを割り当てるようにフレキシブルに結合することができた（図１４を参照）ので、このＳＰＳ設定７は、第１の実施形態の、前の実施態様では必要ではなかった。

繰り返し述べるように、（さまざまなＣＡＭデータコンポーネントの周期性に影響する車両ダイナミクスの一例として）ＵＥが走行し得る、可能性のある異なった速度範囲をサポートするために、ｅＮｏｄｅＢによっていくつかのＳＰＳ設定が準備される。こうしたシナリオでは、複数のＳＰＳ設定を用意するとき、車両用ＵＥによってサポートされる、可能性のある速度範囲が、考慮に入れられるべき異なった周期性に影響するため、ｅＮＢは、それらに関して通知されることも必要である。１つの選択肢は、車両用ＵＥによってサポートされる速度範囲に関する明示的な情報を、ｅＮＢがその情報から、複数のＳＰＳ設定を用意するときに考慮される必要がある、結果としての、周期的データコンポーネントの異なった周期性を決定することができるように、例えば、周期性に関する情報と一緒に、またはそれとは別に、ｅＮＢに送信することである。別の選択肢は、サポートされる速度範囲に関してＵＥがｅＮＢに追加で通知する必要がないように、車両用ＵＥが、サポートされる速度範囲における周期性も含む、可能性のあるさまざまな周期性をあらかじめ送信することであり、ｅＮＢは、異なった速度範囲におけるＣＡＭメッセージおよびコンポーネントの周期性についての標準化された定義など、この関係を築くことができるようにする特定の情報へｅＮＢがアクセスできることを想定して、通知された異なった周期性から、サポートされる速度範囲を推定し得る。

さらには、ＵＥが周期的データの送信を実際に開始したいとき、ｅＮＢが、車両用ＵＥが現在経験している当該の示された速度範囲のために用意されたＳＰＳ設定を選択およびアクティブ化し得るように、ＵＥは、ｅＮＢに、自身の現在の速度について（または、自身が現在いる速度範囲について）通知するものとする。現在の速度に関する情報は、例えば、車両用ＵＥがどのデータコンポーネントを送信したいのかの指示情報と一緒に、またはそれとは別に、車両用ＵＥによって送信することができる。例えば、第１の実施形態の例示的な一実施態様は、この指示情報が、特定の論理チャネルグループについてＵＥ内の対応するバッファ内でデータが待機中であることを示すバッファ状態通知であることを規定している。それに応じて、車両用ＵＥの現在の速度に関する情報も、バッファ状態通知内で送信することができる。

さらには、上述のように、ＣＡＭデータコンポーネントの周期性は、速度などの車両ダイナミクス、ただしそれは時間と共に変化し得るが、それに依存し得る。そのため、第１の実施形態のさらなる実施態様は、現在の車両ダイナミクス（例えば、車両用ＵＥの速度）に応じて、アクティブ化されるＳＰＳ設定を変えることができるようにする。前記の点において、車両用ＵＥは、それ自身の速度をモニタし得、自身が前にいた速度範囲と比べて速度範囲が変化してしまっているかどうかを判定し得る。この場合、車両用ＵＥは、この速度範囲の変化についてｅＮｏｄｅＢに通知し得る。あるいは、ＳＰＳ設定に関わる速度範囲を特定の車両用ＵＥが変更するときをｅＮｏｄｅＢ自身が判定し得るように、車両用ＵＥは、自身の現在の速度に関する情報をｅＮｏｄｅＢに定期的に送信し得る。いずれの場合も、このように、速度範囲の変化が、前にアクティブ化されたＳＰＳ設定の代わりに、当該の示された速度範囲のために用意された異なったＳＰＳ設定を選択およびアクティブ化するように、ｅＮｏｄｅＢをトリガし得る。車両用ＵＥは、変化したＳＰＳ設定のためのこうしたアクティブ化コマンドを受信して、前にアクティブ化されたＳＰＳ設定をもはや使用せず、新たにアクティブ化されたＳＰＳ設定を使用する。

第１の実施形態の別の代替的な実施態様によれば、現在の速度または現在の変更された速度範囲をｅＮｏｄｅＢに送信する代わりに、車両用ＵＥは、自身が特定の速度範囲を変更したと判定するとき、当該の変更された速度範囲のために必要な対応するＳＰＳ設定を実際に特定し得、速度範囲の変化によってこれらの新たなＳＰＳ設定を使用するためにｅＮｏｄｅＢに要求を送信し得る。次に、ｅＮｏｄｅＢがこの要求を受信し、自身が要求に従うか否かを決定し得る。それに応じて、ｅＮｏｄｅＢは、ＳＰＳ設定の変化が妥当であることを判定し得るため、要求されたＳＰＳ設定をアクティブ化するように、要求に対する応答をそれに応じて送信する。このように、車両用ＵＥは、前にアクティブ化されたＳＰＳ設定をもはや使用せず、今度は新たにアクティブ化されたＳＰＳ設定を使用する。

ちょうど説明したように、車両ダイナミクス（例えば速度）の変化に起因して、車両用ＵＥ内のＳＰＳ設定を変更するとき、第１の実施形態の可能な一実施態様によれば、車両用ＵＥは、速度の頻繁な変更、およびその結果としてのＳＰＳ設定の頻繁な変更によってコンポーネントのいくつかが送信されないということを避けるために、ＣＡＭコンポーネントのすべて（すなわち、すべてのＣＡＭコンポーネントを含むＣＡＭメッセージ）を送信することから常に始め得る。

上記に説明したように、車両用ＵＥは、ｅＮＢに、車両用ＵＥが将来送信しなければならないことになり得る、サポートされる周期的データに関する情報を送信する。第１の実施形態の以下の実施態様を参照しつつ詳細に説明するように、これは、さまざまな方法で実施され得る。第１の実施形態の例示的な一実施態様によれば、車両用ＵＥは、車両用ＵＥがサポートしており、その結果、将来実際に送信されなければならないことになり得るＣＡＭメッセージ／コンポーネントの、可能性のある異なった周期性および／または可能性のある異なったメッセージサイズについて、ｅＮｏｄｅＢに明示的に通知し得る。このように、例えば、周期的データに関する情報は、車両用ＵＥによってサポートされる、可能性のある周期性および／または可能性のあるＣＡＭメッセージサイズのリストを含み得る。このように、ｅＮｏｄｅＢは、サポートされるさまざまな異なった周期性および／またはメッセージサイズのために適切なＳＰＳ設定を用意することができる。

第１の実施形態のこの実施態様の変化形によれば、周期的データに関する情報は、１つのメッセージ内で、または少なくとも２つの別々のメッセージ内で送信され得る。特に、可能性のある周期性および可能性のあるメッセージサイズに関する情報は、１つのメッセージ、例えば、ｅＮｏｄｅＢにサイドリンク情報を示すために標準内で現在規定されているＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ（例えば、ＵＥがサイドリンク通信をすることに関心がある周波数、およびＵＥがそれのために専用リソースを割り当てられるよう要求するサイドリンク通信送信先）（参照により本明細書に組み込まれている非特許文献１３のｖ１３．０．０の６．２．２節を参照）に基づいているメッセージ内で送信され得る。以下に、第１の実施形態のこの実施態様に係る、例示的な拡張されたＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎメッセージを定義する。
＜ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎメッセージ＞
−−ＡＳＮ１ＳＴＡＲＴ
ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ−ｒ１２：：＝ＳＥＱＵＥＮＣＥ｛
ｃｒｉｔｉｃａｌＥｘｔｅｎｓｉｏｎｓ ＣＨＯＩＣＥ｛
ｃ１ ＣＨＯＩＣＥ｛
ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ−ｒ１２ ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ−ｒ１２−ＩＥｓ，
ｓｐａｒｅ３ ＮＵＬＬ，ｓｐａｒｅ２ ＮＵＬＬ，ｓｐａｒｅ１ ＮＵＬＬ
｝，
ｃｒｉｔｉｃａｌＥｘｔｅｎｓｉｏｎｓＦｕｔｕｒｅ ＳＥＱＵＥＮＣＥ｛｝
｝
｝
ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ−ｒ１２−ＩＥｓ：：＝ＳＥＱＵＥＮＣＥ｛
ｃｏｍｍＲｘＩｎｔｅｒｅｓｔｅｄＦｒｅｑ−ｒ１２ ＡＲＦＣＮ−ＶａｌｕｅＥＵＴＲＡ−ｒ９ ＯＰＴＩＯＮＡＬ，
ｃｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑ−ｒ１２ ＳＬ−ＣｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑ−ｒ１２ ＯＰＴＩＯＮＡＬ，
ｄｉｓｃＲｘＩｎｔｅｒｅｓｔ−ｒ１２ ＥＮＵＭＥＲＡＴＥＤ｛ｔｒｕｅ｝ ＯＰＴＩＯＮＡＬ，
ｄｉｓｃＴｘＲｅｓｏｕｒｃｅＲｅｑ−ｒ１２ ＩＮＴＥＧＥＲ （１．．６３） ＯＰＴＩＯＮＡＬ，
ｌａｔｅＮｏｎＣｒｉｔｉｃａｌＥｘｔｅｎｓｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ ＯＰＴＩＯＮＡＬ，
ｎｏｎＣｒｉｔｉｃａｌＥｘｔｅｎｓｉｏｎ ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ−ｖ１３ｘ０−ＩＥｓ ＯＰＴＩＯＮＡＬ
｝
ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ−ｖ１３ｘ０−ＩＥｓ：：＝ＳＥＱＵＥＮＣＥ｛
ｃｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑ１２１−ｒ１３ ＳＬ−ＣｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑＵＣ−ｒ１３ ＯＰＴＩＯＮＡＬ，
ｃｏｍｍＴｘＲｅｓｏｕｒｃｅＩｎｆｏＲｅｑＲｅｌａｙ−ｒ１３ ＳＥＱＵＥＮＣＥ｛
ｃｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑＲｅｌａｙ−ｒ１３ ＳＬ−ＣｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑＵＣ−ｒ１３，
ｕｅ−Ｔｙｐｅ−ｒ１３ ＥＮＵＭＥＲＡＴＥＤ｛ｒｅｌａｙＵＥ，ｒｅｍｏｔｅＵＥ｝
｝
ＯＰＴＩＯＮＡＬ，
ｄｉｓｃＴｘＲｅｓｏｕｒｃｅＲｅｑ−ｖ１３ｘ０ ＳＥＱＵＥＮＣＥ｛
ｃａｒｒｉｅｒＦｒｅｑＤｉｓｃＴｘ−ｒ１３ ＩＮＴＥＧＥＲ（１．．ｍａｘＦｒｅｑ），
ｄｉｓｃＴｘＲｅｓｏｕｒｃｅＲｅｑＡｄｄＦｒｅｑ−ｒ１３ ＳＬ−ＤｉｓｃＴｘＲｅｓｏｕｒｃｅＲｅｑＰｅｒＦｒｅｑＬｉｓｔ−ｒ１３ ＯＰＴＩＯＮＡＬ
｝
ＯＰＴＩＯＮＡＬ，
ｄｉｓｃＴｘＲｅｓｏｕｒｃｅＲｅｑＰＳ−ｒ１３ ＳＬ−ＤｉｓｃＴｘＲｅｓｏｕｒｃｅＲｅｑ−ｒ１３ ＯＰＴＩＯＮＡＬ，
ｄｉｓｃＲｘＧａｐＲｅｑ−ｒ１３ ＳＬ−ＧａｐＲｅｑｕｅｓｔ−ｒ１３ ＯＰＴＩＯＮＡＬ，
ｄｉｓｃＴｘＧａｐＲｅｑ−ｒ１３ ＳＬ−ＧａｐＲｅｑｕｅｓｔ−ｒ１３ ＯＰＴＩＯＮＡＬ，
ｄｉｓｃＳｙｓＩｎｆｏＲｅｐｏｒｔＬｉｓｔ−ｒ１３ ＳＬ−ＳｙｓＩｎｆｏＲｅｐｏｒｔＬｉｓｔ−ｒ１３ ＯＰＴＩＯＮＡＬ，
ｎｏｎＣｒｉｔｉｃａｌＥｘｔｅｎｓｉｏｎ ＳＥＱＵＥＮＣＥ｛｝ ＯＰＴＩＯＮＡＬ
｝
ＳＬ−ＣｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑ−ｒ１２：：＝ＳＥＱＵＥＮＣＥ｛
ｃａｒｒｉｅｒＦｒｅｑ−ｒ１２ ＡＲＦＣＮ−ＶａｌｕｅＥＵＴＲＡ−ｒ９ ＯＰＴＩＯＮＡＬ，
ｄｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔ−ｒ１２ ＳＬ−ＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔ−ｒ１２
｝
ＳＬ−ＣｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑＵＣ−ｒ１３：：＝ＳＥＱＵＥＮＣＥ｛
ｃａｒｒｉｅｒＦｒｅｑ−ｒ１３ ＡＲＦＣＮ−ＶａｌｕｅＥＵＴＲＡ−ｒ９ ＯＰＴＩＯＮＡＬ，
ｄｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔＵＣ−ｒ１３ ＳＬ−ＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔＵＣ−ｒ１３
｝
ＳＬ−ＤｉｓｃＴｘＲｅｓｏｕｒｃｅＲｅｑＰｅｒＦｒｅｑＬｉｓｔ−ｒ１３：：＝ＳＥＱＵＥＮＣＥ （ＳＩＺＥ （１．．ｍａｘＦｒｅｑ）） ＯＦ ＳＬ−ＤｉｓｃＴｘＲｅｓｏｕｒｃｅＲｅｑ−ｒ１３
ＳＬ−ＤｉｓｃＴｘＲｅｓｏｕｒｃｅＲｅｑ−ｒ１３：：＝ＳＥＱＵＥＮＣＥ｛
ｃａｒｒｉｅｒＦｒｅｑ−ｒ１３ ＡＲＦＣＮ−ＶａｌｕｅＥＵＴＲＡ−ｒ９ ＯＰＴＩＯＮＡＬ，
ｄｉｓｃＴｘＲｅｓｏｕｒｃｅＲｅｑ−ｒ１３ ＩＮＴＥＧＥＲ （１．．６３）
｝
ＳＬ−ＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔ−ｒ１２：：＝ＳＥＱＵＥＮＣＥ （ＳＩＺＥ （１．．ｍａｘＳＬ−Ｄｅｓｔ−ｒ１２）） ＯＦ ＳＬ−ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ−ｒ１２
ＳＬ−ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ−ｒ１２：：＝ＢＩＴ ＳＴＲＩＮＧ （ＳＩＺＥ （２４））
ＳＬ−ＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔＵＣ−ｒ１３：：＝ＳＬ−ＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔ−ｒ１２
ＳＬ−ＳｙｓＩｎｆｏＲｅｐｏｒｔＬｉｓｔ−ｒ１３：：＝ＳＥＱＵＥＮＣＥ （ＳＩＺＥ （１．．ｍａｘＳＬ−ＤｉｓｃＳｙｓＩｎｆｏＲｅｐｏｒｔＦｒｅｑ−ｒ１３）） ＯＦ ＳＬ−ＳｙｓＩｎｆｏＲｅｐｏｒｔ−ｒ１３
ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ−ｖ１４ｘ０−ＩＥｓ：：＝ＳＥＱＵＥＮＣＥ｛
ｃｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑ１２１−ｒ１４ ＳＬ−ＣｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑ−１４ ＯＰＴＩＯＮＡＬ，
．．．．．｝
ＳＬ−ＣｏｍｍＴｘＲｅｓｏｕｒｃｅＲｅｑ−ｒ１４：：＝ＳＥＱＵＥＮＣＥ｛
ｃａｒｒｉｅｒＦｒｅｑ−ｒ１４ ＡＲＦＣＮ−ＶａｌｕｅＥＵＴＲＡ−ｒ９ Ｏｐｔｉｏｎａｌ
ｄｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔＵＣ−ｒ１４ ＳＬ−ＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔ−ｒ１４
ＳＬ−Ｔｒａｆｆｉｃ−ｒ１４ ＳＬ−ＴｒａｆｆｉｃＬｉｓｔ−ｒ１４ Ｏｐｔｉｏｎａｌ
｝
ＳＬ−ＴｒａｆｆｉｃＬｉｓｔ−ｒ１４：：＝ＳＥＱＵＥＮＣＥ （ＳＩＺＥ （１．．ｍａｘＳＬ−Ｔｒａｆｆｉｃ−ｒ１４）） ＯＦ ＳＬ−ＴｒａｆｆｉｃＴｙｐｅ−ｒ１４
ＳＬ−ＴｒａｆｆｉｃＴｙｐｅ−ｒ１４：：＝ＳＥＱＵＥＮＣＥ｛
ｔｒａｆｆｉｃＴｙｐｅ ＥＮＵＭＥＲＡＴＥＤ｛ｐｅｒｉｏｄｉｃ，ｎｏｎ−ｐｅｒｉｏｄｉｃ｝
ｐｅｒｉｏｄｉｃｉｔｙ ＥＮＵＭＥＲＡＴＥＤ｛
ｓｆ１００，ｓｆ２００，ｓｆ３００，ｓｆ５００，
ｓｆ６００，ｓｆ１０００，ｓｆ１２００，ｓｐａｒｅ１０，
ｓｐａｒｅ９，ｓｐａｒｅ８，ｓｐａｒｅ７，ｓｐａｒｅ６，
ｓｐａｒｅ５，ｓｐａｒｅ４，ｓｐａｒｅ３，ｓｐａｒｅ２，
ｓｐａｒｅ１｝
ｍｅｓｓａｇｅＳｉｚｅ ＩＮＴＥＧＥＲ （１．．．３００）

第１の実施形態のこの実施態様のＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎメッセージに例示的に導入される追加のエレメントは、上記において太字でかつ枠で囲まれている。それから明らかなように、ＣＡＭメッセージについて上記で述べたものなど、さまざまな異なった周期性を示すことができるようにする周期性フィールドが存在する。同様に、それぞれ１〜３００バイトの値のさまざまな異なったメッセージサイズを示すことができるようにするメッセージサイズフィールドが提供される。任意に、トラフィックタイプフィールドは、ＵＥが、データが周期的かそれとも非周期的かについてｅＮｏｄｅＢに通知することを可能にする。

あるいは、可能性のある周期性と一緒にメッセージサイズを示す代わりに、第１の実施形態のさらなる変化形によれば、メッセージサイズ（すなわち、ＵＥが送信したいデータ量）は、バッファ状態通知と一緒に送信され、バッファ状態通知は、データが車両用ＵＥによって送信されるのを待機中であることを示す。この場合、準備フェーズの一例において、ｅＮｏｄｅＢは、可能性のある異なった周期性に関する情報のみを受信し、可能性のある異なったメッセージサイズに関する情報は受信しないため、可能性のある異なった周期性の情報に基づいて、異なったＳＰＳ設定の用意に進む。例えば、ｅＮｏｄｅＢによって用意された複数のＳＰＳ設定は、周期性に関して異なるが、どの無線リソースが、およびいくつの無線リソースがＳＰＳ設定によって割り当てられるのかに関して明確ではない。次いで、車両用ＵＥが、可能性のあるデータコンポーネントの１または複数を実際に送信し始めたい時点で、対応するバッファが埋められ、その結果として、バッファ状態通知がｅＮｏｄｅＢに送信されるのをトリガし、それに基づいて、１または複数の、可能性のあるデータコンポーネントのためにＵＥが通信したいデータの量を実際に決定し得る。それに応じて、ｅＮｏｄｅＢは、（対応する適切な周期性の、）対応する適切なＳＰＳ設定を選択およびアクティブ化し、次いで、車両用ＵＥのための選択されたＳＰＳ設定をアクティブ化すると同時に、それぞれのアクティブ化されたＳＰＳ設定について、どのリソースがそれぞれのアクティブ化されたＳＰＳ設定によって割り当てられるのかを示す。

言い換えれば、図１１から図１５と関連付けて前に説明したのとは異なり、第１の実施形態のこの特定の変化形では、ｅＮｏｄｅＢは、無線リソースをあらかじめ指定（例えば、１２２バイトを送信するのに十分な無線リソースを定義するＳＰＳ設定１）せず、周期性のみを指定する。例えば、ｅＮｏｄｅＢは、（速度範囲１４４ｋｍ／ｈ超を想定して）１００ｍｓの周期性で車両用ＵＥによるＣＡＭ ＨＦコンポーネントの送信をサポートするためにＳＰＳ設定１を用意し得、その他のＳＰＳ設定についても同様である。図１２について想定されるシナリオについて、ｅＮｏｄｅＢは、このように、すなわち、１００ｍｓ、５００ｍｓ、および１０００ｍｓ毎の３つの周期性についてそれぞれに、３つの異なったＳＰＳ設定を用意する。図１４について想定されるシナリオについて、ｅＮｏｄｅＢは、速度範囲毎にそれぞれ３つで、９つの異なったＳＰＳ設定を用意する。

第１の実施形態の別の例示的な実施態様によれば、可能性のある異なった周期性および／または可能性のある異なったメッセージサイズに関する情報を送信することに加えて、またはその代わりに、車両用ＵＥが送信することをサポートされる、特定のデータコンポーネントに関して、車両用ＵＥは、ｅＮｏｄｅＢに通知し得る。例えば、このように、周期性に関する情報は、将来車両用ＵＥが送信することをサポートされるデータコンポーネントを特定するリストを含み得る。ｅＮｏｄｅＢは、これらの特定されたデータコンポーネントと関連付けられている、可能性のある周期性およびメッセージサイズについての情報へアクセスすることができ、例えば、３ＧＰＰ標準は、可能性のある異なったＣＡＭおよびそれらのコンポーネントのためにサイズおよび周期性を明示的に定義し得る。この方法では、このように、ｅＮｏｄｅＢは、サポートされるさまざまな異なった周期性および／またはメッセージサイズのために適切なＳＰＳ設定を用意することができる。

上記では詳細に規定しないが、選択されたＳＰＳ設定をアクティブ化するためにｅＮｏｄｅＢによって車両用ＵＥに送信されるアクティブ化コマンドは、ＰＤＣＣＨすなわち物理ダウンリンク制御チャネルを介して送信されるメッセージとして例示的に実装され得る。例えば、現在指定されているＳＰＳメカニズムについてと同様の方法で、ｅＮｏｄｅＢは、前に設定されたＳＰＳ設定の１または複数をアクティブ化するために１または複数のＤＣＩを送信し得る。一例では、ＤＣＩがサイドリンクＳＰＳ用であり、Ｕｕ ＳＰＳまたはＵｕリンクダイナミック割当て用ではないことをＵＥが知る必要があるため、サイドリンクアクティブ化／非アクティブ化のためのＤＣＩのために新たなＣ−ＲＮＴＩが使用され得る。上述のとおり、第１の実施形態の特定の実施態様については、ＰＤＣＣＨメッセージも、アクティブ化されたＳＰＳ設定のためにＵＥが使用することになっている特定の無線リソースを特定し得る。

上記で詳細には規定されていないが、ｅＮｏｄｅＢは、複数のＳＰＳ設定を決定した後、複数のＳＰＳ設定についてＵＥに通知するものとする。これは、例えば、ｒａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄメッセージ内のｓｐｓ−ＣｏｎｆｉｇＳｉｄｅｌｉｎｋなどのＲＲＣメッセージとして実装され得る。Ｕｕリンクのための現在のＳＰＳ設定は、ｒａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄメッセージ内で送信される。サイドリンクのためのＳＰＳ設定を示すために、新たなエレメントをｓｐｓ−ＣｏｎｆｉｇＳｉｄｅｌｉｎｋとして生成することができ、これも、ｒａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄメッセージ内で送信することができる。上記に説明したように、準備フェーズにおいてｅＮｏｄｅＢによって設定される複数のＳＰＳ設定は、例えば、周期性および無線リソースの両方を特定することができるか、または周期性のみを設定し得る（この場合、無線リソースは、次いで、ｅＮｏｄｅＢからＵＥに送信されるアクティブ化コマンドと一緒に特定することができる）。

第１の実施形態の実施態様を、Ｖ２Ｖ、および他の車両用ＵＥとサイドリンクコネクションを介して通信する車両用ＵＥに基づいて説明してきたが、第１の実施形態の根底にある原理は、Ｕｕインタフェースを介して車両用ＵＥと例えばｅＮｏｄｅＢとの間で、または例えばＰＣ５インタフェースを介して車両用ＵＥと路側機との間で、車両用データを送信するためにも適用することができる。

さらには、第１の実施形態の実施態様を、車両用ＵＥに基づいて説明してきたが、第１の実施形態の根底にある原理は、サイドリンクコネクションを介してｅＮＢと、または他の「普通の」もしくは車両用のＵＥと通信する「普通の」ＵＥによっても実行することができる。

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

さまざまな実施形態は、コンピューティングデバイス（プロセッサ）を使用して実施または実行され得るものとさらに認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他のプログラマブルロジックデバイスなどであってもよい。さまざまな実施形態は、これらのデバイスの組合せによって実行または具現化されてもよい。具体的には、上記の実施形態のそれぞれの記載において使用される各機能ブロックは、集積回路としてＬＳＩによって実現することができる。これらの機能ブロックは、チップとして個別に形成してもよく、または、機能ブロックの一部またはすべてを含むように１つのチップを形成してもよい。これらのチップは、自身に結合されているデータ入出力部を含んでもよい。ここで、ＬＳＩは、集積度の違いに応じて、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、またはウルトラＬＳＩとも称され得る。ただし、集積回路を実施する技術は、ＬＳＩに限定されず、専用回路または汎用プロセッサを使用することによって実現してもよい。また、ＬＳＩの製造後にプログラムすることができるＦＰＧＡ（フィールドプログラマブルゲートアレイ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、またはＬＳＩ内部に配置されている回路セルの接続および設定を再設定できるリコンフィギャラブルプロセッサを使用してもよい。

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

具体的な実施形態に示した本開示に対してさまざまな変更および／または修正を行い得ることが、当業者には理解されるであろう。したがって、本実施形態は、あらゆる点において例示的であって、制限しようとするものではないと見なされるべきである。

Claims (15)

1. 周期的データを１または複数の受信エンティティに送信するための車両用移動端末であって、
   前記車両用移動端末は、可能性のある異なった送信周期性および／または可能性のある異なったメッセージサイズで送信されるべき１または複数の異なったデータコンポーネントを含む前記周期的データの送信をサポートし、
   前記周期的データに関する情報を、前記車両用移動端末に無線リソースを割り当てる役割を担う無線基地局に送信するように構成された送信部であって、前記周期的データに関する前記送信された情報は、前記無線基地局が、前記周期的データの前記１または複数のデータコンポーネントの、前記可能性のある異なった送信周期性および／または前記可能性のある異なったメッセージサイズを決定できるようにする、前記送信部と、
   前記周期的データに関する前記送信した情報に基づいて、前記無線基地局によって設定された複数のセミパーシステント無線リソース設定を、前記無線基地局から、受信するように構成され、前記複数のセミパーシステント無線リソース設定のそれぞれは、前記サポートされるデータコンポーネントの少なくとも１つを送信するために使用することができるように構成される、受信部と、を備え、
   前記送信部は、前記データコンポーネントの１または複数は、前記車両用移動端末によって送信されるべきであることを前記無線基地局に示すようにさらに構成され、
   前記受信部は、前記データコンポーネントのそれぞれを送信するために前記車両用移動端末のための無線リソースを周期的に割り当てるための前記複数のセミパーシステント無線リソース設定の１または複数をアクティブ化するアクティブ化コマンドを前記無線基地局から受信するようにさらに構成され、
   前記送信部は、前記アクティブ化された１または複数のセミパーシステント無線リソース設定によって設定されるように、前記無線リソースおよび前記送信周期性に基づいて、前記１または複数のデータコンポーネントを前記１または複数の受信エンティティに送信するようにさらに構成される、
   車両用移動端末。
2. 前記周期的データに関する前記送信された情報は、
   前記１または複数のデータコンポーネントの、前記可能性のある異なった送信周期性および／または可能性のある異なったメッセージサイズの、一部または全部に関する情報であって、前記車両用移動端末によって送信されるべき少なくとも１つのデータコンポーネントのメッセージサイズに関する前記情報は、データが前記１つのデータコンポーネントについて送信されるのを待機していることを示すバッファ状態通知と一緒に前記車両用移動端末によって送信される、情報、または、
   前記無線基地局が、前記可能性のある異なったデータコンポーネントに関する前記受信した情報に基づいて、前記可能性のある異なった送信周期性および／または前記可能性のある異なったメッセージサイズを決定できるようにする、前記異なったデータコンポーネントに関する情報、を含む、
   請求項１に記載の車両用移動端末。
3. 前記送信部は、前記車両用移動端末によってサポートされる、少なくとも速度を含む車両ダイナミクスを示す車両パラメータに関する情報を、前記無線基地局に送信するようにさらに構成され、前記車両パラメータに関する前記情報は、前記１または複数のサポートされるデータコンポーネントの前記可能性のある異なった送信周期性を決定するために前記無線基地局によって使用することができ、
   前記送信部は、前記車両用移動端末が現在経験している前記車両パラメータに関する情報を前記無線基地局に送信するようにさらに構成され、前記現在経験している前記車両パラメータに関する情報は、アクティブ化するべき、前記複数のセミパーシステント無線リソース設定の前記１または複数を選択するために、前記無線基地局によって使用することができ、前記現在の車両パラメータに関する前記情報は、１または複数のデータコンポーネントが前記車両用移動端末によって送信されるべきであるという指示情報と一緒に送信される、
   請求項１または２に記載の車両用移動端末。
4. 前記車両パラメータの１つが所定のしきい値以上変化するとき、前記送信部は、変化した前記車両パラメータに関する情報を前記無線基地局に送信するようにさらに構成され、前記受信部は、前記無線基地局から返信として、あらかじめアクティブ化されたセミパーシステント無線リソース設定の代わりに他のセミパーシステント無線リソース設定をアクティブ化するためのさらなるアクティブ化コマンドを受信するように適合される、または、
   前記車両パラメータの１つが所定のしきい値以上変化するとき、前記送信部は、あらかじめアクティブ化されたセミパーシステント無線リソース設定以外のセミパーシステント無線リソース設定をアクティブ化するように前記無線基地局へ要求するようにさらに構成され、前記受信部は、前記無線基地局から返信として、前記あらかじめアクティブ化されたセミパーシステント無線リソース設定の代わりに前記他の要求されたセミパーシステント無線リソース設定をアクティブ化するためのさらなるアクティブ化コマンドを受信するように適合され、
   前記送信部は、前記アクティブ化された他のセミパーシステント無線リソース設定によって設定されたように、前記無線リソースおよび前記送信周期性に基づいて、前記１または複数のデータコンポーネントを送信するようにさらに構成され、
   前記さらなるアクティブ化コマンドは、ＰＤＣＣＨすなわち物理ダウンリンク制御チャネル（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介したメッセージ内で受信される、
   請求項３に記載の車両用移動端末。
5. 前記周期的データに関する前記情報は、１つのメッセージ内で送信される、または、
   前記周期的データに関する前記情報は、少なくとも２つの別々のメッセージ内で送信され、前記１または複数のサポートされるデータコンポーネントの前記可能性のある異なった周期性に関する情報は、第１のメッセージ内で送信され、前記車両用移動端末によって送信されるべき少なくとも１つのデータコンポーネントのメッセージサイズに関する情報は、前記１つのデータコンポーネントのデータが送信のために待機中であることを示すバッファ状態通知と一緒に、前記車両用移動端末によって送信される、
   請求項１から４のいずれか一項に記載の車両用移動端末。
6. 前記受信した複数のセミパーシステント無線リソース設定のそれぞれは、
   前記サポートされるデータコンポーネントの少なくとも１つを送信するために適した無線リソースおよび周期性であって、前記複数のセミパーシステント無線リソース設定は、無線リソース制御（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）すなわちＲＲＣプロトコルのメッセージ内で受信される、無線リソースおよび周期性、または、
   前記データコンポーネントの少なくとも１つを送信するための周期性であって、前記データコンポーネントの少なくとも１つを送信するために前記車両用移動端末によって使用することができる前記無線リソースに関する情報は、前記複数のセミパーシステント無線リソース設定の１または複数をアクティブ化するための前記アクティブ化コマンドと一緒に受信され、前記アクティブ化コマンド、および前記無線リソースに関する前記情報は、ＰＤＣＣＨすなわち物理ダウンリンク制御チャネルを介したメッセージ内で受信される、周期性、を特定する、
   請求項１から５のいずれか一項に記載の車両用移動端末。
7. 同じタイムインスタンスにおいて送信されるべき、前記データコンポーネントは、１つのメッセージまたは個別のメッセージの、いずれかとして送信される、
   請求項１から６のいずれか一項に記載の車両用移動端末。
8. 前記受信エンティティは、他の、車両用移動端末または非車両用移動端末を備え、前記周期的データは、サイドリンクコネクションを介して送信され、および／または前記受信エンティティは、前記無線基地局を備え、前記周期的データは、無線接続を介して送信される、
   請求項１から７のいずれか一項に記載の車両用移動端末。
9. 前記複数のセミパーシステント無線リソース設定は、固有のメッセージサイズおよび固有の送信周期性を有するデータコンポーネント毎に１つのセミパーシステント無線リソース設定が存在するように設定される、または、
   同じタイムインスタンスにおいて送信される前記データコンポーネントは、１つのメッセージとして送信され、前記複数のセミパーシステント無線リソース設定は、前記車両用移動端末によって送信されるべき前記データコンポーネントの１または複数を含む、可能性のあるメッセージ毎に、１つのセミパーシステント無線リソース設定が存在するように設定され、前記送信部は、送信されるべき前記メッセージの前記含まれたデータコンポーネントに対応する前記アクティブ化されたセミパーシステント無線リソース設定に基づいて、前記１または複数のデータコンポーネントを含む前記メッセージを送信するように構成される、
   請求項１から８のいずれか一項に記載の車両用移動端末。
10. １または複数の受信エンティティに周期的データを送信するために車両用移動端末に無線リソースを割り当てるための無線基地局であって、前記車両用移動端末は、可能性のある異なった送信周期および／または可能性のある異なったメッセージサイズで送信されるべき１または複数の異なったデータコンポーネントを含む前記周期的データの送信をサポートし、前記無線基地局は、
    前記車両用移動端末によって前記１または複数の受信エンティティに送信されるべき前記周期的データに関する情報を、前記車両用移動端末から受信するように構成された受信部と、
    前記異なったサポートされるデータコンポーネント、および前記１または複数のデータコンポーネントの、前記可能性のある異なった送信周期性および／または前記可能性のある異なったメッセージサイズを決定するように構成されたプロセッサと、
    前記決定された送信周期性および／または前記決定されたメッセージサイズに基づいて複数のセミパーシステント無線リソース設定を設定するように構成された前記プロセッサであって、前記複数のセミパーシステント無線リソース設定のそれぞれは、前記サポートされるデータコンポーネントの少なくとも１つを送信するために使用できるように構成された、前記プロセッサと、
    前記設定された複数のセミパーシステント無線リソース設定に関する情報を前記車両用移動端末に送信するように構成された送信部と、
    前記車両用移動端末から、前記データコンポーネントの１または複数が前記車両用移動端末によって送信されるべきであるという指示情報を受信するようにさらに構成された前記受信部と、
    前記車両用移動端末が前記データコンポーネントのそれぞれを送信するために、前記車両用移動端末のために無線リソースを周期的に割り当てるためにアクティブ化されるべき、前記複数のセミパーシステント無線リソース設定のうちの１または複数を選択するようにさらに構成された前記プロセッサと、
    前記車両用移動端末のために前記選択された１または複数のセミパーシステント無線リソース設定をアクティブ化するために前記車両用移動端末にアクティブ化コマンドを送信するようにさらに構成された前記送信部と、
    を備える無線基地局。
11. 前記周期的データに関する前記受信した情報は、
    前記１または複数のデータコンポーネントの、前記可能性のある異なった送信周期性および／または可能性のある異なったメッセージサイズの、一部または全部に関する情報であって、前記車両用移動端末によって送信されるべき少なくとも１つのデータコンポーネントのメッセージサイズに関する前記情報は、データが前記１つのデータコンポーネントについて送信されるのを待機していることを示すバッファ状態通知と一緒に前記車両用移動端末から受信される、情報、または、
    前記異なったデータコンポーネントに関する情報であって、前記プロセッサは、前記可能性のある異なったデータコンポーネントに関して前記受信した情報に基づいて、前記可能性のある異なった送信周期性および／または前記可能性のある異なったメッセージサイズを決定するようにさらに構成される、情報、を含む、
    請求項１０に記載の無線基地局。
12. 前記受信部は、前記車両用移動端末から、前記車両用移動端末によってサポートされる、少なくとも速度を含む車両ダイナミクスを示す車両パラメータに関する情報を受信するようにさらに構成され、前記プロセッサは、前記車両パラメータに関する前記受信した情報に基づいて、前記１または複数のサポートされるデータコンポーネントの前記可能性のある異なった送信周期性を決定するようにさらに構成され、
    前記受信部は、前記車両用移動端末から、前記車両用移動端末が現在経験している前記車両パラメータに関する情報を受信するようにさらに構成され、前記プロセッサは、前記受信した現在の車両パラメータに基づいて、アクティブ化するべき、前記複数のセミパーシステント無線リソース設定のうちの前記１または複数を選択するようにさらに適合され、前記現在の車両パラメータに関する前記情報は、１または複数のデータコンポーネントが前記車両用移動端末によって送信されるべきであるという指示情報と一緒に、前記車両用移動端末から受信される、
    請求項１０または１１に記載の無線基地局。
13. 前記受信部は、前記車両用移動端末から、変化した車両パラメータに関する情報を受信するように適合され、前記プロセッサは、前記変化した車両パラメータに基づいて、前に選択およびアクティブ化されたセミパーシステント無線リソース設定の代わりに他のセミパーシステント無線リソース設定を選択するように構成され、前記送信部は、前記選択された他のセミパーシステント無線リソース設定をアクティブ化するために、さらなるアクティブ化コマンドを前記車両用移動端末に送信するように構成される、または、
    前記受信部は、前記車両用移動端末からの、あらかじめアクティブ化されたセミパーシステント無線リソース設定以外のセミパーシステント無線リソース設定をアクティブ化する要求を受信するように適合され、前記プロセッサは、前記他のセミパーシステント無線リソース設定をアクティブ化するか否かを決定するように構成され、肯定の場合、前記送信部は、あらかじめアクティブ化されたセミパーシステント無線リソース設定の代わりに他のセミパーシステント無線リソース設定をアクティブ化するためにさらなるアクティブ化コマンドを前記車両用移動端末に送信するように構成され、
    前記さらなるアクティブ化コマンドは、ＰＤＣＣＨすなわち物理ダウンリンク制御チャネルを介したメッセージ内で送信される、
    請求項１２に記載の無線基地局。
14. 前記設定および送信された複数のセミパーシステント無線リソース設定のそれぞれは、
    前記サポートされるデータコンポーネントの少なくとも１つを送信するために適した無線リソースおよび周期性であって、前記複数のセミパーシステント無線リソース設定は、無線リソース制御（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）すなわちＲＲＣプロトコルのメッセージ内で送信される、無線リソースおよび周期性、または、
    前記データコンポーネントの少なくとも１つを送信するための周期性であって、前記データコンポーネントの少なくとも１つを送信するために前記車両用移動端末によって使用することができる前記無線リソースに関する情報は、前記複数のセミパーシステント無線リソース設定の１または複数をアクティブ化するためのアクティブ化コマンドと一緒に前記送信部によって送信され、前記アクティブ化コマンド、および前記無線リソースに関する前記情報は、ＰＤＣＣＨすなわち物理ダウンリンク制御チャネルを介したメッセージ内で送信される、周期性、を特定する、
    請求項１０から１３のいずれか一項に記載の無線基地局。
15. 前記複数のセミパーシステント無線リソース設定は、固有のメッセージサイズおよび固有の送信周期性を有するデータコンポーネント毎に１つのセミパーシステント無線リソース設定が存在するように設定される、または、
    前記車両用移動端末によって同じタイムインスタンスにおいて送信される前記データコンポーネントは、１つのメッセージとして送信され、前記複数のセミパーシステント無線リソース設定は、前記車両用移動端末が、送信されるべき前記メッセージの前記含まれたデータコンポーネントに対応する前記アクティブ化されたセミパーシステント無線リソース設定に基づいて、前記１または複数のデータコンポーネントを含む前記メッセージを送信するように、前記車両用移動端末によって送信されるべき前記データコンポーネントの１または複数を含む、可能性のあるメッセージ毎に１つのセミパーシステント無線リソース設定が存在するように設定される、
    請求項１０から１４のいずれか一項に記載の無線基地局。

Images