JP2020178351A - Ｖ２ｘ送信のための改良された無線リソース選択およびセンシング - Google Patents

Abstract

【課題】サイドリンクインタフェースを介したデータ送信のための改良されたＵＥによる自律的な無線リソース割当て手順を提供する。【解決手段】送信装置よる手順は、リソースセンシング手順を実行し、使用可能な無線リソースに関する情報を獲得し、データが送信のために利用可能になった後、リソースセンシング手順によって獲得された情報に基づいて、自律的な無線リソース割当てを実行し、データを送信するために使用されるべき送信ウィンドウ内の無線リソースを選択する。自律的な無線リソース割当ては、送信ウィンドウのセカンダリサブフレーム内の無線リソースよりも、送信ウィンドウのプライマリサブフレーム内の無線リソースを選択する。セカンダリサブフレームは、センシングウィンドウの期間にリソースセンシング手順を実行しなかったサブフレームに対応し、プライマリサブフレームは、リソースセンシング手順を実行したサブフレームに対応する。【選択図】図１１

Description

本開示は、無線リソース選択およびセンシング手順を実行するための改良された送信デバイスに関する。本開示は、本発明のための対応する方法およびデバイスを提供する。

[ロングタームエボリューション（ＬＴＥ）]
ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代の移動通信システム（３Ｇ）は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：High-Speed Downlink Packet Access）と、エンハンストアップリンク（高速アップリンクパケットアクセス（ＨＳＵＰＡ：High-Speed Uplink Packet Access）とも称する）とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。

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

Ｅ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access（ＵＴＲＡ））およびＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）と称される、ＬＴＥに関する作業項目（ＷＩ：work item）の仕様は、最終的にリリース８（ＬＴＥリリース８）として公開される。ＬＴＥシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、ＩＰベースの全機能を低遅延かつ低コストで提供する。ＬＴＥでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、スケーラブルな複数の送信帯域幅（例えば、１．４ＭＨｚ、３．０ＭＨｚ、５．０ＭＨｚ、１０．０ＭＨｚ、１５．０ＭＨｚ、および２０．０ＭＨｚ）が指定されている。ダウンリンクには、ＯＦＤＭ（Orthogonal Frequency Division Multiplexing：直交周波数分割多重）をベースとする無線アクセスが採用されている。なぜなら、かかる無線アクセスは、低いシンボルレートのため本質的にマルチパス干渉（ＭＰＩ：multipath interference）を受けにくく、また、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）を使用しており、さらに、様々な送信帯域幅の構成に対応可能だからである。アップリンクには、ＳＣ−ＦＤＭＡ（Single-Carrier Frequency Division Multiple Access）をベースとする無線アクセスが採用されている。なぜなら、ユーザ機器（ＵＥ：User Equipment）の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。ＬＴＥリリース８／９では、数多くの主要なパケット無線アクセス技術（例えば、ＭＩＭＯ（Multiple Input Multiple Output）チャネル伝送技術）が採用され、高効率の制御シグナリング構造が達成されている。

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

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

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

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

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

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

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

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

［より広い帯域幅のサポートのためのＬＴＥ−Ａにおけるキャリアアグリゲーション］
World Radio communication Conference 2007（ＷＲＣ−０７）において、ＩＭＴ−Ａｄｖａｎｃｅｄの周波数スペクトルが決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域または国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、３ＧＰＰ（3rd Generation Partnership Project）において無線インタフェースの標準化が開始された。３ＧＰＰ ＴＳＧ ＲＡＮ ＃３９会合において、「Further Advancements for E-UTRA (LTE-Advanced)」に関する検討項目（study item）の記述が承認された。この検討項目は、Ｅ−ＵＴＲＡを進化・発展させるうえで（例えば、ＩＭＴ−Ａｄｖａｎｃｅｄの要求条件を満たすために）考慮すべき技術要素をカバーしている。

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

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

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

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

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

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

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

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

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

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

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

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

無線リソース制御（ＲＲＣ）レイヤは、無線インタフェースにおけるＵＥとｅＮＢとの間の通信と、いくつかのセルを横切って移動するＵＥのモビリティを制御する。ＲＲＣプロトコルは、ＮＡＳ情報の伝送もサポートする。RRC_IDLEのＵＥに対しては、ＲＲＣはネットワークからの着信呼の通知をサポートする。ＲＲＣ接続制御は、ＲＲＣ接続の確立、変更、および解除に関連するすべての手順（ページング、測定の設定および報告、無線リソースの設定、最初のセキュリティ起動、シグナリング無線ベアラ（ＳＲＢ：Signalling Radio Bearer）およびユーザデータを伝える無線ベアラ（データ無線ベアラ（ＤＲＢ：Data Radio Bearer））の確立を含む）をカバーする。

無線リンク制御（ＲＬＣ：Radio Link Control）サブレイヤは、主としてＡＲＱ（自動再送要求）機能を備えており、また、データの分割および連結をサポートしている。すなわち、ＲＬＣレイヤは、ＲＬＣ ＳＤＵのフレーミングを実行し、ＭＡＣレイヤによって示されるサイズにする。後者の２つによって、データレートとは無関係にプロトコルオーバーヘッドが最小になる。ＲＬＣレイヤは、論理チャネルを介してＭＡＣレイヤに接続されている。各論理チャネルは、様々なタイプのトラフィックを伝える。ＲＬＣレイヤの上のレイヤは、一般にはＰＤＣＰレイヤであるが、場合によってはＲＲＣレイヤである。すなわち、論理チャネルＢＣＣＨ（Broadcast Control Channel）、ＰＣＣＨ（Paging Control Channel）、およびＣＣＣＨ（Common Control Channel）で送信されるＲＲＣメッセージは、セキュリティ保護を必要とせず、したがってＰＤＣＰレイヤをバイパスしてＲＬＣレイヤに直接渡される。

［ＬＴＥにおけるアップリンクアクセス方式］
アップリンク送信では、カバレッジを最大にするため、ユーザ端末は高い電力効率で送信する必要がある。Ｅ−ＵＴＲＡのアップリンク送信方式としては、シングルキャリア伝送と、動的な帯域幅割当てのＦＤＭＡとを組み合わせた方式が選択されている。シングルキャリア伝送が選択された主たる理由は、マルチキャリア信号（ＯＦＤＭＡ）と比較して、ピーク対平均電力比（ＰＡＰＲ：peak to average power ratio）が低く、これに対応して電力増幅器の効率が改善され、カバレッジも改善されるためである（与えられる端末ピーク電力に対してデータレートがより高い）。各時間間隔において、ｅＮｏｄｅＢは、ユーザデータを送信するための固有の時間／周波数リソースをユーザに割り当て、これによってセル内の直交性が確保される。アップリンクにおける直交多元接続によって、セル内干渉が排除されることでスペクトル効率が高まる。マルチパス伝搬に起因する干渉については、送信信号にサイクリックプレフィックスを挿入することにより基地局（ｅＮｏｄｅＢ）において対処する。

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

［Layer 1／Layer 2制御シグナリング］
スケジューリング対象のユーザに、ユーザの割当て状態、トランスポートフォーマット、およびその他の送信関連情報（例：ＨＡＲＱ情報、送信電力制御（ＴＰＣ：Transmit Power Control）コマンド）を通知する目的で、Ｌ１／Ｌ２制御シグナリングがデータと共にダウンリンクで送信される。Ｌ１／Ｌ２制御シグナリングは、サブフレーム内でダウンリンクデータと共に多重化される（ユーザ割当てがサブフレーム単位で変化し得るものと想定する）。なお、ユーザ割当てをＴＴＩ（送信時間間隔）ベースで実行することもできる。その場合、ＴＴＩ長をサブフレームの整数倍とすることができることに留意されたい。ＴＴＩ長は、サービスエリア内ですべてのユーザに対して一定とする、または異なるユーザに対して異なる長さとする、さらにはユーザごとに動的とすることもできる。Ｌ１／Ｌ２制御シグナリングは、一般的にはＴＴＩあたり１回送信するのみでよい。以下では、一般性を失うことなく、ＴＴＩが１サブフレームに等しいものと想定する。

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

アップリンク無線リソースまたはダウンリンク無線リソースを割り当てる目的でＬ１／Ｌ２制御シグナリングで送られる情報は（特にＬＴＥ（−Ａ）リリース１０）、一般的には以下の項目に分類できる。
− ユーザ識別情報（User Identity）： 割り当てる対象のユーザを示す。この情報は、一般には、ＣＲＣをユーザの識別情報によってマスクすることによってチェックサムに含まれる。
− リソース割当て情報（Resource allocation information）： ユーザに割り当てられるリソース（例：リソースブロック（ＲＢ））を示す。あるいはこの情報はリソースブロック割当て（ＲＢＡ：resource block assignment）と称される。なお、ユーザに割り当てられるリソースブロック（ＲＢ）の数は動的とすることができる。
− キャリアインジケータ（Carrier indicator）： 第１のキャリアで送信される制御チャネルが、第２のキャリアに関連するリソース（すなわち第２のキャリアのリソースまたは第２のキャリアに関連するリソース）を割り当てる場合に使用される（クロスキャリアスケジューリング）。
− 変調・符号化方式（Modulation and Coding Scheme）： 採用される変調方式および符号化率を決める。
− ＨＡＲＱ情報： データパケットまたはその一部の再送信時に特に有用である、新規データインジケータ（ＮＤＩ：New Data Indicator）または冗長バージョン（ＲＶ：Redundancy Version）など。
− 電力制御コマンド： 割当て対象のアップリンクのデータまたは制御情報の送信時の送信電力を調整する。
− 参照信号情報： 割当ての対象の参照信号の送信または受信に使用される、適用されるサイクリックシフトまたは直交カバーコード（ＯＣＣ）インデックスなど。
− アップリンク割当てインデックスまたはダウンリンク割当てインデックス： 割当ての順序を識別するために使用され、ＴＤＤシステムにおいて特に有用である。
− ホッピング情報： 例えば、周波数ダイバーシチを増大させる目的でリソースホッピングを適用するかどうか、および適用方法の指示情報。
− ＣＳＩ要求： 割り当てられるリソースにおいてチャネル状態情報（Channel State Information）を送信するようにトリガするために使用される。
− マルチクラスタ情報： シングルクラスタ（ＲＢの連続的なセット）またはマルチクラスタ（連続的なリソースブロックの少なくとも２つの不連続なセット）で送信を行うかを指示して制御するために使用されるフラグである。マルチクラスタ割当ては、３ＧＰＰ ＬＴＥ−（Ａ）リリース１０によって導入された。

なお、上記リストは、すべてを網羅したものではなく、また、使用されるＤＣＩフォーマットによっては、リストした情報項目すべてを各ＰＤＣＣＨ送信に含める必要はないことに留意されたい。

ダウンリンク制御情報はいくつかのフォーマットの形をとり、これらのフォーマットは、全体のサイズと、上述したフィールドに含まれる情報とが異なる。ＬＴＥにおいて現在定義されている様々なＤＣＩフォーマットは以下のとおりであり、非特許文献４の５．３．３．１節（３ＧＰＰのウェブサイト（http://www.3gpp.org）で入手可能であり、参照により本明細書に組み込まれている）に詳しく記載されている。参照により本明細書に組み込まれる非特許文献４は、５．４．３節で、サイドリンクインタフェースのための制御情報を定義している。

［半持続的スケジューリング（ＳＰＳ：Semi-Persistent Scheduling）］
ダウンリンクおよびアップリンクでは、スケジューリングｅＮｏｄｅＢは、各送信時間間隔で、ユーザ機器がそれらの特定のＣ−ＲＮＴＩを介してアドレス指定されるＬ１／Ｌ２制御チャネル（ＰＤＣＣＨ）を介してユーザ機器に動的にリソースを割り当てる。既に前述したように、ＰＤＣＣＨのＣＲＣは、アドレス指定されたユーザ機器のＣ−ＲＮＴＩでマスクされる（いわゆる、動的ＰＤＣＣＨ）。一致するＣ−ＲＮＴＩを有するユーザ機器のみが、ＰＤＣＣＨコンテンツを正しく復号することができる。すなわちＣＲＣチェックは肯定的である。この種のＰＤＣＣＨシグナリングは、動的（スケジューリング）グラントとも呼ばれる。ユーザ機器は、割り当てられた、可能性のある割当て（ダウンリンクおよびアップリンク）を発見するために、動的グラントのためのＬ１／Ｌ２制御チャネルを、各送信時間間隔において監視する。

これに加えて、Ｅ−ＵＴＲＡＮは、最初のＨＡＲＱ送信のためのアップリンク／ダウンリンクリソースを持続的に割り当て得る。必要に応じて、再送信は、Ｌ１／Ｌ２制御チャネルを介して明示的にシグナリングされる。再送信は動的にスケジューリングされるので、この種の動作は、半持続的スケジューリング（ＳＰＳ）と呼ばれる。すなわち、リソースは、半持続的ベースでユーザ機器に割り当てられる（半持続的リソース割当て）。この利点は、最初のＨＡＲＱ送信のためのＰＤＣＣＨリソースが節約されることである。半持続的スケジューリングは、リリース１０におけるＰＣｅｌｌでは使用され得るが、ＳＣｅｌｌでは使用されない。

半持続的スケジューリングを使用してスケジューリングされ得るサービスの一例は、ボイスオーバＩＰ（ＶｏＩＰ）である。２０ｍｓごとに、ＶｏＩＰパケットが、通話中、コーデックにおいて生成される。したがって、ｅＮｏｄｅＢは、２０ｍｓごとにアップリンクまたはそれぞれダウンリンクリソースを持続的に割り当てることができ得る。それはその後、ボイスオーバＩＰパケットの送信のために使用され得る。一般に、半持続的スケジューリングは、予測可能なトラフィック挙動、すなわち、一定のビットレートを有するサービスにとって有益であり、パケット到着時間は周期的である。

また、ユーザ機器は、最初の送信のためのリソースが持続的に割り当てられているサブフレーム内のＰＤＣＣＨを監視する。動的（スケジューリング）グラント、すなわちＣ−ＲＮＴＩマスクされたＣＲＣを有するＰＤＣＣＨは、半持続的リソース割当てを無効にし得る。ユーザ機器が、割り当てられた半持続的リソースを有するサブフレーム内のＬ１／Ｌ２制御チャネルにおいて、ユーザ機器が、そのＣ−ＲＮＴＩを発見した場合、このＬ１／Ｌ２制御チャネル割当ては、その送信時間間隔のための持続的リソース割当てを無効にし、ユーザ機器は、動的グラントに従う。ユーザ機器が、動的グラントを発見しないとき、ユーザ機器は、半持続的リソース割当てに従って送信／受信する。

半持続的スケジューリングの設定は、ＲＲＣシグナリングによって行われる。例えば、持続的割当ての周期性、例えばＰＳ＿ＰＥＲＩＯＤは、無線リソース制御（ＲＲＣ）シグナリング内でシグナリングされる。持続的割当てのアクティベーション、また正確なタイミング、ならびに、物理リソースおよび伝送フォーマットパラメータは、ＰＤＣＣＨシグナリングを介して送信される。半持続的スケジューリングがアクティブ化されると、ユーザ機器は、ＰＳ＿ＰＥＲＩＯＤごとにＳＰＳアクティベーションＰＤＣＣＨに従って、半持続的リソース割当てに従う。本質的に、ユーザ機器は、ＳＰＳアクティベーションＰＤＣＣＨコンテンツを記憶し、シグナリングされた周期で、ＰＤＣＣＨに従う。

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

半持続的リソース割当てが、対応するＳＰＳアクティベーションＰＤＣＣＨによってアクティブ化されたことをユーザ機器が検出した場合、ユーザ機器は、ＰＤＣＣＨコンテンツ（すなわち、半持続的リソース割当て）を記憶し、それを、半持続的スケジューリング間隔ごとに、つまり、ＲＲＣを介してシグナリングされる周期で適用する。既に述べたように、動的割当て、すなわち、動的ＰＤＣＣＨにおいてシグナリングされるものは、「ワンタイム割当て」のみである。ＳＰＳ割当ての再送信も、ＳＰＳ Ｃ−ＲＮＴＩを使用してシグナリングされる。ＳＰＳアクティベーションをＳＰＳ再送信と区別するために、ＮＤＩ（ｎｅｗ ｄａｔａ ｉｎｄｉｃａｔｏｒ：新たなデータインジケータ）ビットが使用される。ＳＰＳアクティベーションは、ＮＤＩビットを０に設定することによって示される。１に設定されたＮＤＩビットを有するＳＰＳ ＰＤＣＣＨは、半持続的にスケジューリングされた最初の送信のための再送信を示す。

半持続的スケジューリングのアクティベーションと同様に、ｅＮｏｄｅＢは、ＳＰＳリソース解除とも呼ばれる半持続的スケジューリングを、非アクティベートすることもでき得る。半持続的スケジューリングの割当て解除がどのようにシグナリングされ得るかについて、いくつかのオプションがある。１つのオプションは、いくつかの事前定義された値に設定されたいくつかのＰＤＣＣＨフィールド、すなわち、ゼロサイズのリソース割当てを示すＳＰＳ ＰＤＣＣＨを用いて、ＰＤＣＣＨシグナリングを使用することであろう。他のオプションは、ＭＡＣ制御シグナリングを使用することであろう。

［ＬＴＥの装置間（Ｄ２Ｄ：Device to Device）近接サービス（ＰｒｏＳｅ：Proximity Services）］
近接性に基づくアプリケーションおよびサービスは、ソーシャル技術の新しいトレンドである。識別される分野としては、事業者およびユーザにとって関心のある商用サービスおよび公共安全に関連するサービスが挙げられる。ＬＴＥに近接サービス（ＰｒｏＳｅ）機能を導入することにより、３ＧＰＰ業界は、この成長の見込まれる市場にサービスを提供できると同時に、連係してＬＴＥを使用するいくつかの公共安全コミュニティの緊急なニーズに応えることができる。

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

ＬＴＥにおけるＤ２Ｄ通信は、ディスカバリおよび通信という２つの分野に焦点をあてている。

ＰｒｏＳｅ（近接サービス）直接ディスカバリ（ProSe Direct Discovery）は、ＰｒｏＳｅ対応ユーザ機器が、近傍の別の（１つまたは複数の）ＰｒｏＳｅ対応ユーザ機器を、ＰＣ５インタフェースを介してＥ−ＵＴＲＡ直接無線信号を使用して発見するために使用される手順と定義されている。

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

Ｄ２Ｄは、アップリンクＬＴＥ周波数帯（ＦＤＤの場合）において動作する、またはカバレッジを提供しているセルのアップリンクサブフレーム（ＴＤＤの場合、ただしカバレッジ外のときを除く）において動作するものと想定する。さらに、Ｄ２Ｄ送信／受信では、与えられたキャリアにおいて全二重を使用しない。個々のユーザ機器の観点からは、与えられたキャリアにおいて、Ｄ２Ｄ信号受信およびＬＴＥアップリンク送信が全二重を使用しない（すなわちＤ２Ｄ信号受信およびＬＴＥアップリンク送信を同時に行うことはできない）。

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

［ＰｒｏＳｅ直接通信のレイヤ２リンク］
簡潔に言えば、２つのＵＥの間でＰＣ５を通じてセキュアなレイヤ２リンクを確立することによって、１対１のＰｒｏＳｅ直接通信が実現される。各ＵＥは、ユニキャスト通信用のレイヤ２ ＩＤを有する。このレイヤ２ ＩＤは、ＵＥがレイヤ２リンクで送信する各フレームのSource Layer-2 ID（送信元レイヤ２ ＩＤ）フィールドと、ＵＥがレイヤ２リンクで受信する各フレームのDestination Layer-2 ID（宛先レイヤ２ ＩＤ）に含まれる。ＵＥは、ユニキャスト通信用のレイヤ２ ＩＤが少なくともローカル範囲内で一意であることを確保する必要がある。したがって、ＵＥは、隣接するＵＥとのレイヤ２ ＩＤの衝突を、規定されていないメカニズム（例えば、衝突が検出されたときユニキャスト通信用の新しいレイヤ２ ＩＤを自身で割り当てる）を使用して処理するように構成されているべきである。１対１のＰｒｏＳｅ直接通信のためのレイヤ２リンクは、２つのＵＥのレイヤ２ ＩＤの組み合わせによって識別される。すなわち、ＵＥは、同じレイヤ２ ＩＤを使用して、１対１のＰｒｏＳｅ直接通信のための複数のレイヤ２リンクに関与できる。

１対１のＰｒｏＳｅ直接通信は、非特許文献５の７．１．２節（参照により本明細書に組み込まれている）に詳しく説明されているように、次の手順から構成される。
・ ＰＣ５を通じてセキュアなレイヤ２リンクを確立する
・ ＩＰアドレス／プレフィックスを割り当てる
・ ＰＣ５を通じてレイヤ２リンクを維持・管理する
・ ＰＣ５を通じてレイヤ２リンクを解除する

図３は、ＰＣ５インタフェースを通じてセキュアなレイヤ２リンクを確立する方法を示している。
１． 相互認証をトリガする目的で、ＵＥ−１が直接通信要求（Direct Communication Request）メッセージをＵＥ−２に送信する。ステップ１を実行するためには、リンク開始側（ＵＥ−１）が相手側（ＵＥ−２）のレイヤ２ ＩＤを知っている必要がある。一例として、リンク開始側は、最初にディスカバリ手順を実行することによって、または相手側を含む１対多のＰｒｏＳｅ通信に参加することによって、相手側のレイヤ２ ＩＤを認識できる。
２． ＵＥ−２が相互認証の手順を開始する。認証手順が正常に終了すると、ＰＣ５を通じてのセキュアなレイヤ２リンクの確立が完了する。

単独の（中継されない）１対１通信に関与するＵＥは、リンクローカルアドレスを使用することもできる。ＰＣ５シグナリングプロトコルは、ＵＥがＰｒｏＳｅ通信範囲内ではないときに検出するために使用されるキープアライブ機能をサポートする。したがって、このようなＵＥは、レイヤ２リンクの暗黙的な解除に進むことができる。ＰＣ５を通じてのレイヤ２リンクの解除は、他方のＵＥに送信される接続解除要求（Disconnect Request）メッセージを使用することによって実行できる。他方のＵＥは、関連するすべてのコンテキストデータも削除する。他方のＵＥは、接続解除要求メッセージを受信した時点で、接続解除応答（Disconnect Response）メッセージによって応答し、レイヤ２リンクに関連付けられるすべてのコンテキストデータを削除する。

［ＰｒｏＳｅ直接通信に関連する識別情報］
非特許文献６の８．３節には、ＰｒｏＳｅ直接通信に使用するための次の識別情報が定義されている。
・ ＳＬ−ＲＮＴＩ（サイドリンク無線ネットワーク一時識別子）： ＰｒｏＳｅ直接通信のスケジューリングに使用される一意の識別情報
・ 送信元レイヤ２ ＩＤ（Source Layer 2 ID）： サイドリンクＰｒｏＳｅ直接通信におけるデータの送信者を識別する。送信元レイヤ２ ＩＤは２４ビット長であり、受信機におけるＲＬＣ ＵＭエンティティおよびＰＤＣＰエンティティを識別するため、ＰｒｏＳｅレイヤ２宛先ＩＤおよびＬＣＩＤと共に使用される。
・ 宛先レイヤ２ ＩＤ（Destination Layer 2 ID）： サイドリンクＰｒｏＳｅ直接通信におけるデータの対象者を識別する。宛先レイヤ２ ＩＤは２４ビット長であり、ＭＡＣレイヤにおいて２つのビットストリングに分割される。
・ 一方のビットストリングは、宛先レイヤ２ ＩＤの最下位部分（８ビット）であり、サイドリンク制御レイヤ１ ＩＤとして物理レイヤに転送される。これは、サイドリンク制御における意図するデータの対象者を識別し、物理レイヤにおいてパケットをフィルタリングするために使用される。
・ ２番目のビットストリングは、宛先レイヤ２ ＩＤの最上位部分（１６ビット）であり、ＭＡＣヘッダ内で伝えられる。これは、ＭＡＣレイヤにおいてパケットをフィルタリングするために使用される。

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

［近接サービスにおける無線リソース割当て］
送信側ＵＥの観点からは、近接サービスに対応するＵＥ（Proximity-Service-enabled UE。ＰｒｏＳｅ対応ＵＥ）は、リソース割当ての以下の２つのモードで動作できる。

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

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

これに代えて、ｅＮＢが別のリソースプールを定義してＳＩＢ１８で（すなわちcommTxPoolExceptionalフィールドを使用することによって）シグナリングし、ＵＥは例外的なケースにおいてこのリソースプールを使用できる。

ＵＥがどのリソース割当てモードを使用するかは、ｅＮＢによって設定可能である。さらに、ＵＥがＤ２Ｄデータ通信用にどのリソース割当てモードを使用するかを、ＲＲＣ状態（すなわちRRC_IDLEまたはRRC_CONNECTED）と、ＵＥのカバレッジ状態（すなわちカバレッジ内またはカバレッジ外）によっても決定できる。ＵＥがサービングセルを有する（すなわちＵＥがRRC_CONNECTEDである、またはRRC_IDLEにおいて特定のセルにキャンプオンしている）場合、そのＵＥはカバレッジ内にあるとみなされる。

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

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

［Ｄ２Ｄ通信における送信手順］
Ｒｅｌ．１２／１３に従うＤ２Ｄデータ送信手順は、リソース割当てモードに依存して異なる。上述したように、モード１の場合には、スケジューリング割当て（ＳＡ）およびＤ２Ｄデータを伝えるためのリソースを、ＵＥからの対応する要求の後にｅＮＢが明示的にスケジューリングする。特に、Ｄ２Ｄ通信は基本的に許可されるがモード２のリソース（すなわち、リソースプール）が提供されないことを、ｅＮＢがＵＥに通知できる。この通知は、例えば、ＵＥによるＤ２Ｄ通信関心通知（D2D communication Interest Indication）と、対応する応答であるＤ２Ｄ通信応答（D2D Communication Response）を交換することによって、行うことができる。この場合、対応する例示的なProseCommConfig情報要素にcommTxPoolNormalCommonが含まれない。すなわち、送信を含む直接通信の開始を望むＵＥは、個々の送信ごとにリソース割当てをＥ−ＵＴＲＡＮに要求しなければならない。したがって、このような場合、ＵＥは、個々の送信のリソースを要求しなければならない。以下、モード１のリソース割当ての場合の要求／割当て手順の一連のステップを例示的に示す。
・ ステップ１ ＵＥがスケジューリング要求（ＳＲ：Scheduling Request）をＰＵＣＣＨを介してｅＮＢに送信する。
・ ステップ２ ｅＮＢは、Ｃ−ＲＮＴＩによってスクランブルされたＰＤＣＣＨを介して、（ＵＥがサイドリンクＢＳＲを送信するための）ＵＬリソースをグラントする。
・ ステップ３ ＵＥは、ＰＵＳＣＨを介して、バッファ状態を示すＤ２Ｄ／サイドリンクＢＳＲを送る。
・ ステップ４ ｅＮＢが、（ＵＥがデータを送信するための）Ｄ２Ｄリソースを、Ｄ２Ｄ−ＲＮＴＩによってスクランブルされたＰＤＣＣＨを介して割り当てる。
・ ステップ５ Ｄ２Ｄ送信側ＵＥが、ステップ４で受信したグラントに従って、ＳＡ（スケジューリング割当て）／Ｄ２Ｄデータを送信する。

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

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

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

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

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

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

サイドリンクデータの送信手順は、３ＧＰＰ標準規格書である非特許文献２の５．１４節（参照により本明細書に組み込まれている）に記載されている。この文書には、モード２の自律的なリソース選択が詳しく記載されており、１つの無線リソースプールまたは複数の無線リソースプールが設定されている場合が区別されている。

上述した内容は、Ｄ２Ｄ通信に関する３ＧＰＰ標準規格の現在の状況である。しかしながら、Ｄ２Ｄ通信をさらに改良および強化する方策について検討が進められており、結果として今後のリリースにおいてＤ２Ｄ通信にいくつかの変更が導入される可能性が高いことに留意されたい。後から説明する本発明は、そのような今後のリリースにも適用可能であるものとする。

例えば、現在開発中の３ＧＰＰ Ｒｅｌ．１４の場合、３ＧＰＰは、上記で論じたようにＳＣ期間にもはや基づかないように、しかし異なるように（例えば、Ｕｕインタフェース送信と同じ／類似のサブフレームに基づいて）送信タイミングを変更することを決定し得る。これに対応して、サイドリンク（ＰＣ５）インタフェースを介した送信がどのように実行され得るかについての上記詳述された例は、単なる例示であり、Ｒｅｌ．１３には適合し得るが、恐らくは、対応する３ＧＰＰ規格の今後のリリースには適合しない。

さらに、Ｄ２Ｄフレームワークの将来のリリースでは、特に、車両通信に関連して、Ｔ−ＲＰＴは、もはや使用されなくなる可能性がある。

［ＰｒｏＳｅネットワークのアーキテクチャおよびＰｒｏＳｅエンティティ］
図８は、非ローミングの場合の高レベルの例示的なアーキテクチャを示しており、ＵＥ ＡおよびＵＥ Ｂにおける異なるＰｒｏＳｅアプリケーションと、ネットワーク内のＰｒｏＳｅアプリケーションサーバおよびＰｒｏＳｅ機能を含む。図８のアーキテクチャの例は、非特許文献７の４．２節「Architectural Reference Model（アーキテクチャの基準モデル）」（参照により本明細書に組み込まれている）からの引用である。

これらの機能エンティティは、非特許文献７の４．４節「Functional Entities（機能エンティティ）」（参照により本明細書に組み込まれている）に提示および詳しく説明されている。ＰｒｏＳｅ機能は、ＰｒｏＳｅに要求されるネットワーク関連動作に使用される論理機能であり、ＰｒｏＳｅの特徴それぞれにおいて異なる役割を果たす。ＰｒｏＳｅ機能は、３ＧＰＰのＥＰＣ（Evolved Packet Core）の一部であり、近接サービスに関係する認可、認証、データ処理など、関連するネットワークサービスすべてを提供する。ＰｒｏＳｅ直接ディスカバリおよび直接通信において、ＵＥは、固有のＰｒｏＳｅ ＵＥ識別情報、他の設定情報、および認証を、ＰｒｏＳｅ機能からＰＣ３基準点（PC3 reference point）を通じて取得できる。ネットワーク内に複数のＰｒｏＳｅ機能を配備できるが、説明を容易にするため、１つのＰｒｏＳｅ機能を示してある。ＰｒｏＳｅ機能は、ＰｒｏＳｅの特徴に応じた異なる役割を実行する３つのメインのサブ機能、すなわち直接提供機能（ＤＰＦ：Direct Provision Function）、直接ディスカバリネーム管理機能（Direct Discovery Name Management Function）、およびＥＰＣレベルディスカバリ機能（EPC-level Discovery Function）、から構成されている。ＤＰＦは、ＰｒｏＳｅ直接ディスカバリおよびＰｒｏＳｅ直接通信を使用するための必要なパラメータをＵＥに提供するために使用される。

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

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

［車両通信−Ｖ２Ｘサービス］
近接サービス（ＰｒｏＳｅ）とＬＴＥベースのブロードキャストサービスとを含む、自動車産業への新たなＬＴＥ機能の有用性を考慮するために、Ｒｅｌ．１４の３ＧＰＰにおいて、新たな研究項目が設定された。したがって、上記で説明されたＰｒｏＳｅ機能は、Ｖ２Ｘサービスの優れた基盤を提供するものと考慮される。Ｄ２Ｄフレームワークへの変更は、車両通信の送信がどのように強化され得るかに関して議論される。例えば、Ｔ−ＲＰＴパターンは、これ以上使用されない可能性がある。さらに、データおよびＳＡの送信のために、以前に論じたようにＴＤＤを使用する代わりに、またはそれに加えて、周波数分割多重化が予測され得る。車両シナリオにおける協調サービスは、ＩＴＳ（高度道路交通システム）研究分野内の将来の接続された車両にとって不可欠になりつつある。これらは、道路事故を減らし、道路の容量を改善し、道路輸送の二酸化炭素排出量を減らし、そして移動中のユーザ体験を向上させると考えられている。

Ｖ２Ｘ通信は、車両から、その車両に影響を与える可能性のあるいずれかのエンティティへの、およびその逆への、情報の受け渡しである。この情報交換は、運転手の援助による車両の安全性、スピードへの適応と警告、緊急応答、移動情報、ナビゲーション、交通運行、商用車両群の計画および支払取引を含む安全性、機動性、および環境への応用を改善するために使用され得る。

Ｖ２ＸサービスのためのＬＴＥサポートは、次の３つのタイプの異なる使用事例を含む。
・Ｖ２Ｖ：車両間のＬＴＥベースの通信をカバーする。
・Ｖ２Ｐ：車両と、個人によって携帯されるデバイス（例えば、歩行者、サイクリスト、運転手または同乗者によって携帯される携帯端末）との間のＬＴＥベースの通信をカバーする。
・Ｖ２Ｉ：車両と路側機との間のＬＴＥベースの通信をカバーする。

これら３つのタイプのＶ２Ｘは、エンドユーザのためのより知的なサービスを提供するために、「協調認識」を使用し得る。これは、協調衝突警告や自律的な運転のように、より知的なサービスを提供するために、車両、路側インフラストラクチャ、および歩行者のような伝送エンティティが、その地域の環境に関する知識（例えば、近隣における他の車両またはセンサ機器から受信した情報）を収集し、その知識を処理および共有できることを意味する。

Ｖ２Ｖ通信に関して、許可、認証、および近接基準が満たされるとき、Ｅ−ＵＴＲＡＮは、互いに近接しているそのような（車両）ＵＥが、Ｅ−ＵＴＲＡ（Ｎ）を使用して、Ｖ２Ｖ関連情報を交換することを可能にする。近接基準は、ＭＮＯ（Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｏｒ：移動ネットワークオペレータ）によって設定され得る。しかしながら、Ｖ２ＶサービスをサポートするＵＥは、Ｖ２ＸサービスをサポートするＥ−ＵＴＲＡＮによってサービス提供されても、サービス提供されなくても、そのような情報を交換し得る。

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

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

Ｖ２Ｉ通信に関して、Ｖ２Ｉアプリケーションをサポートするデバイスは、アプリケーションレイヤ情報を路側機に送り、次に、路側機は、アプリケーションレイヤ情報を、デバイスのグループへ、または、Ｖ２Ｉアプリケーションをサポートするデバイスに送り得る。

一方のパーティがＵＥであり、他方のパーティがサービングエンティティであり、どちらもＶ２Ｎ（Ｖｅｈｉｃｌｅ ｔｏ Ｎｅｔｗｏｒｋ：車両−ネットワーク、ｅＮＢ／ＣＮ）アプリケーションをサポートし、ＬＴＥネットワークを介して互いに通信している場合、Ｖ２Ｎも導入される。

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

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

Ｖ２Ｐは、（一方は車両用で、他方は歩行者用の）別個のＵＥ間のＶ２Ｐ関連アプリケーション情報の直接交換、および／または、Ｖ２Ｐの限られた直接通信範囲により、別個のＵＥ間のＶ２Ｐ関連アプリケーション情報の、例えば、ＲＳＵ、アプリケーションサーバ等のようなＶ２Ｘサービスをサポートするインフラストラクチャを介した交換を含む。

この新たな研究アイテムであるＶ２Ｘのために、３ＧＰＰは、このアプリケーションのために再使用され得る非特許文献８における特定の用語および定義を提供した。
路側機（ＲＳＵ）：Ｖ２Ｉアプリケーションを使用してＵＥとの間で送信および受信できるＶ２Ｉサービスをサポートするエンティティ。ＲＳＵは、ｅＮＢまたは固定ＵＥにおいて実施され得る。
Ｖ２Ｉサービス：一方のパーティがＵＥであり、他方のパーティがＲＳＵであり、どちらもＶ２Ｉアプリケーションを使用するＶ２Ｘサービスのタイプ。
Ｖ２Ｎサービス：一方のパーティがＵＥであり、他方のパーティがサービングエンティティであり、どちらもＶ２Ｎアプリケーションを使用し、ＬＴＥネットワークエンティティを介して互いに通信するＶ２Ｘサービスのタイプ。
Ｖ２Ｐサービス：通信の両パーティが、Ｖ２Ｐアプリケーションを使用するＵＥであるＶ２Ｘサービスのタイプ。
Ｖ２Ｖサービス：通信の両パーティが、Ｖ２Ｖアプリケーションを使用するＵＥであるＶ２Ｘサービスのタイプ。
Ｖ２Ｘサービス：３ＧＰＰトランスポートを介してＶ２Ｖアプリケーションを使用する送信ＵＥまたは受信ＵＥを含む通信サービスのタイプ。通信に含まれる他方のパーティに基づいて、それはさらに、Ｖ２Ｖサービス、Ｖ２Ｉサービス、Ｖ２Ｐサービス、およびＶ２Ｎサービスに分類され得る。

多くのＩＴＳサービスは、共通の通信要件を有する。
・周期的ステータス交換。ＩＴＳサービスは通常、車両または路側端末のステータスについて知る必要がある。これは、位置、速度、識別子等に関する情報を有するデータパケットの周期的な交換を意味する。
・非同期通知。この種のメッセージは、特定のサービスイベントについて通知するために使用される。以前のステータスメッセージとは対照的に、これらのメッセージを単一の端末またはそれらのグループへの確実な配信が、通常、重要な要件である。

第１の通信タイプの用途の例は、車両から周期的なステータスデータを収集する、遠隔車両監視のような交通効率化サービス、または潜在的な影響を検出するために周辺車両に関する運動学的情報を必要とする協調衝突回避のような安全サービスにおいて発見され得る。非同期通知は、滑りやすい舗道や衝突後の警告のような安全サービスにおいて主に発見され得る。

Ｖ２Ｖ通信のために、様々なタイプのメッセージが定義される。２つの異なるタイプのメッセージが、高度道路交通システム（ＩＴＳ）用のためにＥＴＳＩによって既に定義されている。対応する欧州規格ＥＴＳＩ ＥＮ ３０２ ６３７−２ ｖ１．３．１およびＥＴＳＩ ＥＮ ３０２ ６３７−３ ｖ １．２．１を参照されたい。
・協調認識メッセージ（ＣＡＭ）。これは、車両のステータスを反映するために、車両動特性によって継続的にトリガされる。
・分散型環境通知メッセージ（ＤＥＮＭ）。これは、車両関連の安全イベントが発生したときにのみトリガされる。

Ｖ２ＶおよびＩＴＳの規格化は、どちらかと言えばまだ始まったばかりなので、将来、他のメッセージが定義され得ることが予想される。

ＣＡＭは、他のＩＴＳ−ステーション（ＩＴＳ−Ｓ）とステータス情報を交換するために、ＩＴＳ−Ｓによって継続的（周期的）にブロードキャストされ、したがって、イベントトリガ型（非周期的）ＤＥＮＭメッセージよりもトラフィック負荷に大きな影響を及ぼす。本質的に、ＣＡＭメッセージは、存在、位置、温度、および基本的なステータスの情報を提供するために、各車両によってその近隣に周期的にブロードキャストされるハートビートメッセージの一種である。逆に、ＤＥＮＭは、道路利用者に、危険なイベントを警告するためにブロードキャストされるイベントトリガメッセージである。この理由により、ＩＴＳのためにＥＴＳＩによって定義されているようなＣＡＭメッセージのトラフィック特性は、Ｖ２Ｖトラフィックをより代表していると考慮される。

協調認識メッセージ（ＣＡＭ）は、互いのアウェアネスを形成および維持し、道路ネットワークを使用して車両の協調性能をサポートするために、ＩＴＳ−Ｓ間でＩＴＳネットワークにおいて交換されるメッセージである。ＣＡＭが、発信側ＩＴＳ−Ｓから、発信側ＩＴＳ−Ｓの直接通信範囲内に位置する受信側ＩＴＳ−Ｓに送信されるように、ポイントツーマルチポイント通信が、ＣＡＭを送信するために使用されるものとする。ＣＡＭ生成は、２つの連続するＣＡＭ生成間の時間間隔を定義する、協調認識基本サービスによってトリガおよび管理されるものとする。現在、送信間隔の上限および下限は、１００ｍｓ（すなわち、１０ＨｚのＣＡＭ生成速度）および１０００ｍｓ（すなわち、１ＨｚのＣＡＭ生成速度）である。ＥＴＳＩ ＩＴＳの基本的な考え方は、共有する新たな情報（例えば、新たな位置、新たな加速度、または新たな方位の値）があるときにＣＡＭを送ることである。これに対応して、車両がゆっくりと一定の方位および速度で動いているとき、ＣＡＭは、最小の差分しか表示しないので、高いＣＡＭ生成速度は、実際の利益をもたらさない。１つの車両のＣＡＭの送信周波数は、車両の動特性（例えば、速度、加速度、および方位）の関数として、１Ｈｚから１０Ｈｚの間で変化する。例えば、車両がより遅く移動するほど、トリガされ送信されるＣＡＭの数は、より少なくなる。車両速度は、ＣＡＭトラフィックの生成に対して、大きな影響を与える要因である。

以上、周期的な協調認識メッセージが記述された。しかしながら、上記情報の一部は既に規格化されているが、周期性やメッセージサイズのような他の情報はまだ規格化されておらず、仮定に基づいていることが注目されるべきである。さらに、規格化は将来変わる可能性があり、したがって、ＣＡＭがどのように生成され、送信されるのかの態様も、変化する可能性がある。

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

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

Ｖ２Ｘサイドリンクのための自律的なリソース制御／選択メカニズムを支援するために、半持続的送信と共にセンシングメカニズムをサポートすることが合意された。ＵＥは、ＰＳＣＣＨ（ＳＡ／ＳＣＩ）内に、リソース選択が発生するまで、周期的に発生するリソースの、選択されたセットに関するデータを有することを示すであろう。（ＳＣＩ内でシグナリングされる）このリソース予約情報は、他のＵＥによって既に予約／ブックされているリソースが、無線リソース選択のために考慮されないように、リソースの選択のためにＶ２Ｘメッセージを送信することを意図する他のＵＥによって使用され得る。このリソース予約／ブッキング手順は、例えばＣＡＭメッセージのように、パケットが一定の周期で到着するトラフィックのために特に適切である。

上述のようにスケジューリング情報内において予約された無線リソースのインジケーションは、他の（車両）デバイスによって監視（「センシング」）され得る。一般に、センシング手順は、無線リソースに関する情報を収集し、したがって、送信のためのリソース候補のセットを識別するために、リソース割当て手順において使用され得る将来の無線リソースに関する予測を可能にする。３ＧＰＰによって既に合意されているものはほとんどないが、センシング処理は、時間周波数リソースを、以下に分類することが仮定され得る。
・「利用できない」リソース。これらのリソースは、他のＵＥによって既にブック／予約されているので、ＵＥは、送信することを許可されていないリソースである。
・「候補（または利用可能な）リソース」。これらは、ＵＥが送信を実行し得る／でき得るリソースである。

さらに、３ＧＰＰは、センシング手順のためのエネルギ測定も実行することに同意したが、この合意は、どのようにそしてどのエネルギ測定が実行されるべきであるかについての詳細を提供しなかった。したがって、エネルギベースのセンシングは、ＵＥがＰＳＳＣＨ無線リソースおよび／またはＰＳＣＣＨ無線リソースにおいて受信信号強度を測定する処理として理解され得る。エネルギベースのセンシングは、基本的に、近距離対遠距離の干渉の識別に役立ち得る。

さらに、データの優先順位（priority）（または、対応する無線リソース予約）が、リソース割当て手順で使用され得るようにスケジューリング割当て（ＳＣＩ）に示されるかどうかについて議論されたが、優先順位がどのようにして効率的に使用されるかについては合意されなかった。

議論中に生まれたさらなるトピックは、ＥＴＳＩ規格から既に知られている（例えば、ＥＴＳＩ ＥＮ ３０２ ５７１ ｖ．２．０．０および１０２ ６８７ ｖ１．１．１を参照されたい）チャネルビジー率（ＣＢＲ）に類似し得るリソース割当て手順のために（すなわち、ＰＣ５インタフェースの）チャネルの輻輳レベルを使用することであった。繰り返すが、そのような輻輳レベルを正確に使用する方法に関する合意はもちろんのこと、この点に関して詳細は議論されていない。

ＵＥの複雑さをさほど増やさないために、センシングは単純な手法で実施可能であるべきである。センシングアルゴリズムをどのように実施するかについて多数の手法／オプションが存在し得ることも注目されるべきである。

ＰＣ５インタフェースを介したＶ２Ｘ送信のためのセンシングおよびリソース予約に関して一般的な合意に達したが、これらのメカニズムを現在のシステムに実施することは、問題および非効率をもたらす可能性がある。

3GPP TS 36.211 V13.1.0, "Physical Channels and Modulation (Release 8)" 3GPP TS 36.321 V13.2.0, "Medium Access Control (MAC) protocol specification" 3GPP TS 36.213 V13.1.1, "Physical layer procedures" 3GPP TS 36.212 V13.1.0, "Multiplexing and channel coding" 3GPP TR 23.713 V13.0.0, "Study on extended architecture support for proximity-based services" 3GPP TS 36.300 V13.3.0, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2" 3GPP TS 23.303 V13.2.0, "Proximity-based services (ProSe); Stage 2" 3GPP TR 21.905 V13.0.0

非限定的で例示的な実施形態は、サイドリンクインタフェースを介したデータ送信のための改良されたＵＥによる自律的な無線リソース割当て手順を提供する。独立請求項は、非限定的で例示的な実施形態を提供する。有利な実施形態は、従属請求項の対象となる。

第１の態様によれば、サイドリンクインタフェースを介した他のデバイスへのデータ（例えば、車両の周期的または非周期的データ）の送信のための無線リソースを決定するための送信デバイスが提供される。将来の無線リソースに関する情報を獲得するために、送信デバイスによってリソースセンシング手順が継続的に実行されると仮定される。一例によれば、無線リソースセンシングは、後の時点で無線リソースをアナウンスおよび／または予約する他のデバイスによって送信されたスケジューリング割当てを監視することを少なくとも備える。その後、予約された無線リソースは、無線リソース選択から除外され得る。センシングすることはまた、無線リソースにおける受信信号エネルギを測定することを備え得る。将来的には、センシング中、他の情報も収集され得る。しかしながら、受信および送信の動作は、デバイスによって同時に実行され得ないので、センシング手順は、デバイスが送信を実行するサブフレームにおいて実行されないことが注目されるべきである。

特定の時間において、データが送信のために利用可能になり、デバイスが、データ送信のために使用される実際の周波数時間無線リソースを含む関連する送信パラメータを決定するために、ＵＥによる自律的なリソース割当て手順を実行し始めることが仮定される。データが利用可能になった時点において始まる送信ウィンドウが定義され得る。その中では、例えば、データの遅延要件に準拠するために、送信（および、恐らくは再送信）が終了されるべきである。一方、センシングウィンドウは、データが利用可能になる前の期間として定義され得、その間、センシング動作は、送信ウィンドウ内の無線リソースに関する情報を取得する。無線リソース割当て手順中、車両ＵＥは、送信パラメータを自律的に決定し、送信ウィンドウ内でデータ送信を実行するために無線リソースを選択する。

センシング手順の結果に基づいて、無線リソース選択は、送信ウィンドウ内のプライマリサブフレームとセカンダリサブフレームとを区別する。ここで、セカンダリサブフレームに対応するセンシングウィンドウ内の少なくとも１つのサブフレームでは、車両ＵＥが送信を実行し、したがって、リソースセンシング手順を実行できなかったので、セカンダリサブフレームは、リソースセンシング手順が、可能であるよりも少ない情報しか提供しない送信ウィンドウにおけるサブフレームである。逆に、車両ＵＥは、センシングウィンドウの、対応するすべてのサブフレームにおいてリソースセンシング手順を実行したため、プライマリサブフレームは、車両ＵＥによって実行されるリソースセンシング手順が、すべての可能な情報を収集した送信ウィンドウ内のサブフレームである。例えば、センシングウィンドウのサブフレームｔにおいて実行されていないリソースセンシング手順は、データ送信の可能な周期によって隔てられた将来のサブフレームにおける情報の欠如をもたらすことになる。例示的に、最小１００ｍｓおよび最大１０００ｍｓを有する１００ｍｓの倍数の周期を仮定すると、車両ＵＥの送信ウィンドウ内にあるとき、サブフレームｔ＋１００ｍｓ、ｔ＋２００ｍｓ、ｔ＋３００ｍｓ、・・・、およびｔ＋１０００ｍｓが、セカンダリサブフレームとして考慮されるであろう。

車両ＵＥは、セカンダリサブフレームからの無線リソースよりも、プライマリサブフレームからの無線リソースを好適に選択する。この点に関して、複数の可能な無線リソース候補がある場合、無線リソース候補の順位付けは、プライマリサブフレームとセカンダリサブフレームとの間で別個であるべきであり、ＵＥは、データの送信のために使用されるべき最高の順位付けの候補を選択するものとする。オプションで、最高の順位付けの候補を使用することができなかった（例えば、他のＵＥへの衝突を引き起こす）場合、２番目に高い順位付けの候補が使用され得る等である。そのような順位付け手順は、異なる方式で実行され得る。候補を順位付けするためのセンシング手順中に、無線リソース候補とデータの到着時間との間の時間遅延、ならびに無線リソース候補について取得されたエネルギ予測値を使用することは有利である。短い時間遅延を被る無線リソース候補は、より長い遅延を被るものよりも好ましい。一方、低いエネルギ予測値を有する無線リソース候補は、センシング手順が、高い送信エネルギを予測するものよりも好ましい。

エネルギ予測のために、センシングウィンドウのすべてのサブフレームにわたって測定値を使用することは可能であるが、さらなる変形は、無線リソース候補のサブフレームに関連するサブフレームのみを考慮することによって、特定の無線リソース候補のエネルギ予測を改良する。この関連は、データの可能な周期、すなわち、既に上記で論じたように、−１００ｍｓ、−２００ｍｓ、−３００ｍｓ、・・・、−１０００ｍｓに基づいている。

さらなる態様によれば、スケジューリング割当てのために車両ＵＥによって実行される無線リソース選択および送信は、データ送信について行われたのと同様に改良される。これに対応して、スケジューリング割当ての送信のために、無線リソース予約が行われ得、車両ＵＥは、無線リソースセンシング手順を実行し、その結果は、スケジューリング割当て送信のための無線リソース選択のために使用され得る。スケジューリング割当てのためのリソース予約は、データのための無線リソース予約とは別個にまたは共通して実施され得る。データリソースの予約と共通して実施されるとき、車両ＵＥは、データとスケジューリングの割当ての両方に対して、無線リソースを予約するか、または、それらのいずれに対しても、無線リソースを予約しない。受信したスケジューリング割当てが、スケジューリング割当ておよび／またはデータの１つまたは複数の将来の送信のための無線リソースも予約することを、受信エンティティが学習するように、対応するインジケーションが、スケジューリング割当てにおいて提供され得る。

スケジューリング割当て送信のために実行される無線リソース選択手順はまた、データ送信に関して上記で論じたように、プライマリサブフレームとセカンダリサブフレームとを区別でき得る。センシング手順の対応する結果は、リソースセンシング手順が、（結果として、プライマリサブフレームとなる）すべての可能な情報を獲得したか、または（結果として、セカンダリサブフレームとなる）すべての可能な情報を取得した訳でもない送信ウィンドウ内のサブフレームを区別するために、前記観点において使用される。センシングウィンドウ内の非センシングサブフレームｔは、ｔ＋１００ｍｓ、ｔ＋２００ｍｓ、ｔ＋３００ｍｓ、・・・、ｔ＋１０００ｍｓにおいてセカンダリサブフレームとなる。繰り返すが、プライマリサブフレームからのリソースは、スケジューリング割当ての送信のための選択手順を実行するために、セカンダリサブフレーム内のリソースよりも好適に選択されるものとする。プライマリサブフレーム内およびセカンダリサブフレーム内の候補の順位付け手順は、互いに別個に実行されるべきである。スケジューリング割当て送信のためのリソース候補の実際の順位付け手順は、データ送信のためのリソース候補の順位付けについて既に上記で論じられたものと同じ方式で実行され得る。例えば、短い時間遅延を被る無線リソース候補は、より長い遅延を被るものよりも好適である。一方、低いエネルギ予測値を有する無線リソース候補は、センシング手順が、高い送信エネルギを予測するものよりも好適である。

これに対応して、１つの一般的な第１の態様において、本明細書において開示された技術は、サイドリンクインタフェースを介した、送信デバイスから、１つまたは複数の受信デバイスへのデータ送信のために使用されるべき無線リソースを決定するための送信デバイスを提供する。送信デバイスの受信機およびプロセッサは、送信デバイスが、後の時点においてデータを送信するために使用可能な無線リソースに関する情報を獲得するために、リソースセンシング手順を実行する。データが送信のために利用可能になった後、プロセッサは、データが送信のために利用可能になる前に、センシングウィンドウ中、リソースセンシング手順によって獲得された情報に基づいて、データを送信するために使用されるべき送信ウィンドウ内の無線リソースを選択するために、自律的な無線リソース割当てを実行する。自律的な無線リソース割当ては、送信ウィンドウのセカンダリサブフレーム内の無線リソースよりも、送信ウィンドウのプライマリサブフレーム内の無線リソースを好適に選択することを備える。送信ウィンドウ内のセカンダリサブフレームは、その間に送信デバイスがリソースセンシング手順を実行しなかったセンシングウィンドウ内のサブフレームに対応し、送信ウィンドウ内のプライマリサブフレームは、その間に送信デバイスがリソースセンシング手順を実行したセンシングウィンドウ内のサブフレームに対応する。

これに対応して、１つの一般的な第１の態様において、本明細書において開示される技術は、サイドリンクインタフェースを介した、送信デバイスから、１つまたは複数の受信デバイスへのデータ送信のために使用されるべき無線リソースを決定する送信デバイスのための方法を提供する。この方法は、送信デバイスが後の時点においてデータを送信するために使用可能な無線リソースに関する情報を獲得するために、送信デバイスによってリソースセンシング手順を実行することを備える。データが送信のために利用可能になった後、送信デバイスは、データが送信のために利用可能になる前に、センシングウィンドウ中、リソースセンシング手順によって獲得された情報に基づいて、データを送信するために使用されるべき送信ウィンドウ内の無線リソースを選択するために、自律的な無線リソース割当てを実行する。自律的な無線リソース割当ては、送信ウィンドウのセカンダリサブフレーム内の無線リソースよりも、送信ウィンドウのプライマリサブフレーム内の無線リソースを好適に選択することを備える。送信ウィンドウ内のセカンダリサブフレームは、その間に送信デバイスがリソースセンシング手順を実行しなかったセンシングウィンドウ内のサブフレームに対応し、送信ウィンドウ内のプライマリサブフレームは、その間に送信デバイスがリソースセンシング手順を実行したセンシングウィンドウ内のサブフレームに対応する。

これに対応して、１つの一般的な第１の態様では、本明細書で開示される技術は、スケジューリング割当ておよびデータを、サイドリンクインタフェースを介して、１つまたは複数の受信デバイスに送信するための送信デバイスを提供する。送信デバイスの受信機およびプロセッサは、後の時点においてスケジューリング割当てを送信するために送信デバイスによって使用可能な無線リソースに関する情報を獲得するために、リソースセンシング手順を実行する。第１のデータが送信のために利用可能になった後、プロセッサは、第１のデータを送信するための送信ウィンドウ内の無線リソースを選択するため、および、第１のデータが送信のために利用可能になる前に、センシングウィンドウ中、リソースセンシング手順によって獲得された情報に基づいて、第１のスケジューリング割当てを送信するための送信ウィンドウ内の無線リソースを選択するために、自律的な無線リソース割当て手順を実行する。第１のスケジューリング割当ては、第１のデータを送信するために、送信ウィンドウ内の選択された無線リソースに関する情報を備える。送信デバイスの送信機は、選択された無線リソースを使用して第１のスケジューリング割当てを送信し、選択された無線リソースを使用して第１のデータを送信する。第１のスケジューリング割当てはさらに、第２のデータのための第２のスケジューリング割当てを送信するために、送信デバイスによって、後の時点において使用可能な、予約された無線リソースを示す。

これに対応して、１つの一般的な第１の態様では、本明細書で開示される技術は、スケジューリング割当ておよびデータを、サイドリンクインタフェースを介して、１つまたは複数の受信デバイスに送信する送信デバイスのための方法を提供する。この方法は、後の時点においてスケジューリング割当てを送信するために、送信デバイスによって使用可能な無線リソースに関する情報を獲得するために、リソースセンシング手順を実行することを備える。第１のデータが、送信のために利用可能になった後、この方法は、第１のデータを送信するために送信ウィンドウ内の無線リソースを選択するために、自律的な無線リソース割当て手順を実行することと、第１のデータが送信のために利用可能になる前に、センシングウィンドウ中、リソースセンシング手順によって獲得された情報に基づいて、第１のスケジューリング割当てを送信するための送信ウィンドウ内の無線リソースを選択することとを備える。第１のスケジューリング割当ては、第１のデータを送信するために、送信ウィンドウ内の選択された無線リソースに関する情報を備える。この方法は、その後、選択された無線リソースを使用して、第１のスケジューリング割当てを送信することを備え、選択された無線リソースを使用して、第１のデータを送信する。第１のスケジューリング割当てはさらに、第２のデータのための第２のスケジューリング割当てを送信するために、送信デバイスによって、後の時点において使用可能な、予約された無線リソースを示す。

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

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

以下では、例示的な実施形態について、添付の図面を参照しながらさらに詳しく説明する。

３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示している。 ３ＧＰＰ ＬＴＥ（リリース８／９）において定義されているサブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドを示している。 ＰｒｏＳｅ通信においてＰＣ５を通じてレイヤ２リンクを確立する方法を概略的に示している。 オーバーレイ（ＬＴＥ）システムおよびアンダーレイ（Ｄ２Ｄ）システムにおける送信／受信リソースの使用を示している。 ２つのＵＥの場合のスケジューリング割当て（ＳＡ）およびＤ２Ｄデータの送信を示している。 ＵＥの自律的なスケジューリングモード２におけるＤ２Ｄ通信タイミングを示している。 ｅＮＢによってスケジューリングされるスケジューリングモード１におけるＤ２Ｄ通信タイミングを示している。 非ローミングシナリオの場合のＰｒｏＳｅの例示的なアーキテクチャモデルを示している。 データが送信のために利用可能になる時間Ｐにおいて、送信ウィンドウとセンシングウィンドウとに分割された車両ＵＥのためのデータリソースプールの周波数時間無線リソースを例示する図である。 送信ウィンドウのサブフレームが、センシング手順に依存してプライマリまたはセカンダリサブフレームとして分類される、第１の実施形態の例示的な実施に従う、車両ＵＥのためのデータリソースプールの周波数時間無線リソースを例示する図である。 第１の実施形態の例示的な実施に従うＵＥ挙動のためのシーケンス図である。 第１の実施形態の例示的な実施に従う車両ＵＥのためのデータリソースプールの周波数時間無線リソースを例示し、これに加えて、送信ウィンドウ内の無線リソース候補についての検出ウィンドウ内の改良されたエネルギセンシング手順を例示する図である。 プライマリおよびセカンダリサブフレームにおいてリソースが発見されない場合に実行されるべきプリエンプション手順をさらに例示する、第１の実施形態の例示的な実施に従うＵＥ挙動のためのシーケンス図である。 図１３に例示されるようなプリエンプション手順のシーケンス図である。 チャネルビジー率低下機能をさらに例示する、第１の実施形態の例示的な実施に従うＵＥ挙動のためのシーケンス図である。 ＳＡとデータ送信との可能な衝突を検出するための衝突機能をさらに例示する、第１の実施形態の例示的な実施に従うＵＥ挙動のためのシーケンス図である。 第２の実施形態の例示的な実施に従うＵＥ挙動のためのシーケンス図である。 送信のサブフレームが、センシング手順に依存してプライマリまたはセカンダリサブフレームとして分類される第２の実施形態の例示的な実施に従う車両ＵＥのためのスケジューリング割当てリソースプールの周波数時間無線リソースを例示する図である。

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

特許請求の範囲および本出願において使用されている用語「無線リソース（radio resource）」は、物理無線リソース（時間−周波数リソースなど）を意味するものと広義に理解されたい。

本出願において使用されている用語「直接通信送信（direct communication transmission）」は、２つのユーザ機器の間の直接的な（すなわち無線基地局（例えばｅＮＢ）を介さない）送信として広義に理解されたい。これに対応して、直接通信送信は、「直接サイドリンク接続」を通じて実行され、「直接サイドリンク接続（direct sidelink connection）」は、２つのユーザ機器の間に直接確立される接続に対して使用される用語である。例えば３ＧＰＰでは、Ｄ２Ｄ（装置間）通信、またはＰｒｏＳｅ通信、またはサイドリンク通信という専門用語が使用される。用語「直接サイドリンク接続」、「サイドリンクインタフェース」は、広義に理解されるものとし、３ＧＰＰの文脈では背景技術のセクションで説明したＰＣ５インタフェースとして理解することができる。

本出願において使用されている用語「ＰｒｏＳｅ」またはその非短縮形である「近接サービス（proximity service）」は、背景技術のセクションで例示的に説明したように、ＬＴＥシステムでは近接性に基づくアプリケーションおよびサービスの文脈において適用される。この文脈では、近接サービスにおける装置間通信を意味する目的で、「Ｄ２Ｄ」などの別の専門用語も使用される。

本出願を通して使用される「車両用移動端末」という用語は、背景技術のセクションで説明したように、それぞれ新しい３ＧＰＰ研究項目の作業項目Ｖ２Ｘ（車両通信）の文脈で理解されるべきである。これに対応して、車両用移動端末は、車両通信を実行するために車両（例えば、自動車、商用トラック、オートバイ等）に具体的に搭載された、すなわち、例えば、安全または運転手の支援の目的のために、車両に関連する情報を、（車両、インフラストラクチャ、歩行者のような）他のエンティティへ渡す移動端末として広く理解されるものとする。オプションで、車両用移動端末は、地図情報等のように、ナビゲーションシステム（これもまた、車内に搭載されていると仮定される）において利用可能な情報へのアクセスを有し得る。

本出願を通して使用される「自律的な無線リソース割当て」（逆に「無線基地局制御型無線リソース割当て」）という用語は、リソース割当てのための２つのモードを可能にする３ＧＰＰ近接サービス、つまり、これに従って無線基地局が割当てを制御するモード１（すなわち、無線基地局制御型無線リソース割当て）と、これに従って端末（または送信デバイス）が（無線基地局なしで）リソースを自律的に選択するモード２（すなわち、自律的な無線リソース割当て）との文脈において例示的に理解され得る。

背景技術のセクションで説明したように、３ＧＰＰはＬＴＥ支援型車両通信に関する新しいスタディアイテム（study item）を導入し、これは、様々な車両用移動端末と他の局との間でＶ２Ｘトラフィックを交換するために、ＰｒｏＳｅ手順に基づくものとする。さらに、ある種の半持続的無線リソース割当てが、Ｖ２Ｘトラフィックのためにサポートされるものとし、特に、ＵＥによる自律的なリソース割当てモード（モード２とも称される）のために、無線リソース予約ならびにセンシングのためのメカニズムが、前記目的のためにサポートされることが合意されている。しかしながら、効率的で完璧な動作を保証するために、どのようにしてそれを実施するか、および他のメカニズムをどのように適応させるかについての詳細を提供することなしに、センシングおよび無線リソース予約に関する一般的な合意にしか達していない。

例えば、リソースセンシングメカニズムが、どの程度正確に実施されるかは不明のままである。より具体的には、モード２無線リソース割当て中、エネルギ測定値がどのように計算され、リソースがどのようにセンシングメカニズムに基づいて選択されるかは明確ではない。

１つの可能な解決策が、車両ＵＥ（一般に送信デバイス）のデータリソースプールの周波数時間無線リソースを例示する図９を参照して以下に説明される。図中の周波数時間無線リソースを例示的に説明するための単位として、ＰＲＢペア（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ ｐａｉｒ：物理リソースブロックペア；１サブフレームに対して１２サブキャリア）が採用される。図９は、解決策を説明するための例示的かつ簡略化された例示である。時間Ｐにおいて、データが送信のために利用可能になり（すなわち、パケット到着）、データの送信（恐らくは、再送信も）が、送信ウィンドウとして示され、送信されるべきデータの遅延要件に依存する時間Ｌ（例えば、１００ｍｓ；Ｌ＝Ｐ＋１００ｍｓ）において終了されるべきであることが仮定される。例えば、パケット到着前、１０００ｍｓからなるセンシングウィンドウ内に取得されたセンシング手順の結果は、データを送信するための周波数時間無線リソース（および、恐らくは他の送信パラメータ）を選択するために、車両ＵＥによって実行されるべき無線リソース割当て手順のために考慮されるものとする。例示的に、データの送信のために、３つの（物理的）リソースブロックペアが必要であると仮定される（現在の規格化によれば、リソースブロックは連続しているべきである）。

センシング手順から取得される１つの情報は、送信ウィンドウ内の特定の無線リソースが既に他のデバイスによって予約されており、したがって、車両ＵＥによって使用されるべきではないということである。対応するボックスは、縦方向にストライプ付けされている。車両ＵＥがデータを送信するのに利用可能な完全な送信ウィンドウ内の残りの無線リソース候補（３つの連続するリソースブロックペア）は、図９に枠で囲まれているように例示される。送信ウィンドウには全部で６つの候補があり、それらのすべては、例えば、センシングウィンドウ内のセンシング手順中に実行されたエネルギ測定に基づいて順位付けされ得る。

より詳細には、関連する無線リソース候補についてセンシングウィンドウ全体にわたってエネルギ（例えば、受信信号強度）を測定することが可能である。例示的に、対応する無線リソース候補は、エネルギ測定値に基づいて、図９に示されるように、１から４に順位付けされると仮定される。これに対応して、センシングウィンドウにおいて、同じ対応する周波数無線リソースを有する無線リソース候補２が、等しく順位付けされる。同図下部における２つのリソース候補３についても同様である。図９は、センシングウィンドウの対応する無線リソースを斜めストライプで例示し、測定されたエネルギは平均されて、無線リソース候補２のためのエネルギを予測する。同様に、図９は、リソース候補４のためのエネルギ測定のために使用されるセンシングウィンドウ内の対応する周波数時間無線リソースが、水平方向にストライプ付けされていることを示す。説明を容易にするために図９には例示されていないが、対応するエネルギ測定および処理は、候補１および３に対応するセンシングウィンドウ内の無線リソースに対しても同様に実行される。これに対応して、車両ＵＥは、例えば、最低のエネルギ予測値を有する候補のように、データを送信するために使用されるための最高の順位付けの無線リソース候補（この例では候補１）を選択し得る。

上記は、センシング手順および対応する無線リソース割当てを実施するための可能な解決策を提供する。

そのオプションの実施は、（例えば、他のデバイスによって予約されている無線リソースが多すぎる場合のような、）無線リソース候補が利用可能ではない状況を取り扱う。したがって、車両ＵＥは、他のデバイスによって既に予約されている無線リソースと衝突する無線リソース候補を選択することがあり得る。この手順は、「プリエンプション（preemption）」と示され得る。プリエンプション手順中、車両ＵＥは、送信ウィンドウ内の予約された無線リソースの中からランダムに適切な無線リソースを選択するか、または、比較的低い受信信号強度予測値を有する、予約された適切な無線リソースを選択してよい。あるいは、予約された無線リソースについても優先順位が示されるならば、車両ＵＥは、最低の優先順位を有する、予約された無線リソースを選択してよい。

しかしながら、上記で提示された解決策に関連していくつかの問題がある。例えば、特定の無線リソース候補の受信信号強度予測（送信エネルギ）は、センシングウィンドウ全体にわたって対応する周波数無線リソースで得られた受信信号強度測定値に基づいており、したがって、リソース候補が配置されている１つのサブフレームにおける実際の送信状況を反映していない。１つの特定のサブフレームにおける無線リソース候補についてのセンシングウィンドウ全体にわたるエネルギ測定値を平均化することは、データおよびスケジューリング割当ての送信が、通常は周期的に、すなわち、特定のサブフレームにおいてのみ発生することを考慮しない。さらに、図９に関連して上記に例示されたような無線リソース選択は、かなり遅い、すなわち、送信ウィンドウの終了時における送信機会となり、その結果、車両ＵＥならびに受信エンティティは、データを長い間待たなければならず、データの待ち時間が長くなる。上記で論じたように、プリエンプション手順中に優先順位を使用する場合、プリエンプションされたＵＥ（すなわち、選択された無線リソース候補と衝突するリソースのＵＥ）が、車両ＵＥに近接して配置されることが可能であり、これによって、２つの「衝突している（colliding）」送信間で、深刻な干渉が発生する。

背景技術のセクションで説明したように、サイドリンクインタフェースを介したＤ２Ｄ送信は、全二重ではなく半二重を使用するので、同時のＶ２Ｘ送信および受信は可能ではない。したがって、車両ＵＥが送信（例えば、スケジューリング割当ておよび／またはデータ）を行うこれらサブフレームでは、車両ＵＥによってセンシング手順は実行されない。これら見逃されたセンシング機会が、車両ＵＥによって実行される無線リソース割当て手順にどのように影響するかは不明である。

本発明者は、上に説明した問題点を軽減する目的で、以下の例示的な実施形態を着想した。

様々な実施形態の特定の実装形態は、３ＧＰＰ標準規格によって与えられる、一部を背景技術のセクションで説明した幅広い仕様の中で実施され、特に重要な特徴は、以下の実施形態において説明するように追加される。実施形態は、例えば、上記背景技術のセクションにおいて記述されたような３ＧＰＰ ＬＴＥ−Ａ（リリース１０／１１／１２／１３／１４、または今後のリリース）通信システムのような移動通信システムにおいて有利に使用され得るが、実施形態は、これらの特定の例示的な通信ネットワークにおけるその使用に限定されないことが注目されるべきである。

以下の説明は、本開示の範囲を制限するものとしてではなく、本開示を深く理解するための実施形態の単なる例として理解されたい。当業者には、請求項に記載されている本開示の一般的な原理を、様々なシナリオに、以下に明示的には記載されていない方法で適用できることが認識されるであろう。例示のためにいくつかの仮定がなされているが、それらは以下の実施形態の範囲を限定しないものとする。

様々な実施形態は、データを、１つまたは複数の受信デバイスに送信するときに、車両ＵＥによって実行される無線リソース割当て手順を主に提供する。他の機能（すなわち、様々な実施形態によって変更されない機能）は、背景技術のセクションで説明されたものと全く同じままであり得、または、様々な実施形態に何ら影響を与えずに変更され得る。これは、例えば、後続するデータの送信がどのようにして車両ＵＥによって正確に実行されるか、または様々な送信デバイスがどのようにして互いを発見するかのような他の手順を含み得る。

様々な実施形態が適用され得る１つの例示的なシナリオは、背景技術のセクションで例示されたようなＶ２Ｘ通信である。したがって、送信デバイスおよび受信デバイスは、例えば、車両内のＵＥ、路側機、歩行者によって携帯される「通常の」移動端末等であり得る。さらに、データは、例えばＣＡＭメッセージのような（周期的な）車両データであり得る。これは、様々な車両エンティティ間で継続的に交換されるものとし、そのためのリソースセンシング手順および半持続的リソースが、３ＧＰＰにおいて論じられている。

以下の例示的な実施形態は、そのようなＶ２Ｘ通信シナリオに関連して例示目的のために説明されるが、本発明はそれに限定されないものとする。

［第１の実施形態］
以下では、前述した（１つまたは複数の）問題点を解決するための第１の実施形態について詳しく説明する。第１の実施形態の様々な実装形態およびバリエーションも説明する。

既に上述したように、例示的に、本出願の背景技術のセクションで説明したように、車両に設置され、Ｄ２Ｄフレームワークに基づいて車両通信を実行することができる車両ＵＥが仮定される。これに対応して、車両データ（例えば、周期的および非周期的データ）は、車両ＵＥによって、データに関心のある他のエンティティに送信されるものとする。

ＵＥは、モード２無線リソース割当てをサポートし、主に実行し、スケジューリング情報ならびにデータをＰＣ５（サイドリンク）インタフェースを介して送信するための無線リソースを自律的に選択できるように、必要なリソースプールを用いて適切に設定されていると仮定される。

車両ＵＥによって送信されるべき周期的データは、背景技術のセクションで詳細に説明された協調認識メッセージ（ＣＡＭ）によって例示される。背景技術のセクションで説明したように、センシングおよび無線リソース予約は、周期的なデータの送信に関連して将来の規格リリースに含まれるべきであることが３ＧＰＰによって一般に承認されている。特に、送信側における無線リソース予約は、例えば、周期的データのさらなるパケットを送信するために、１つまたは複数の後の時間インスタンスに対しても現在使用されているものと同じリソースを予約することによって、一種の「半持続的（semi-persistent）」無線リソース割当てを実施することを可能にする。その結果、周期的データを送信できるようにするために、後の時間インスタンスにおいて、車両ＵＥが再びリソース選択／要求（モード１またはモード２のリソース割当て）を実行する必要はない。無線リソース予約は、異なる手法で実施され得、３ＧＰＰによってまだ決定されていない。例えば、無線リソース予約は、次の送信インスタンスのために、または、より長い期間のために（すなわち、周期的データのすぐ次よりも多くの送信インスタンスのために）行われ得る。サイドリンクデータと共に送信されるスケジューリング情報（ＳＣＩ）は、送信のために使用された無線リソースを識別し、したがって、受信エンティティが、サイドリンクデータを適切に受信し、処理／復号することを可能にする。スケジューリング情報は、さらに、例えば、無線リソースがどの時間（例えばサブフレーム）に予約されているかを、受信エンティティが判定できるように、データの時間または周期を示すことによって、無線リソース予約を示すために使用され得る。

車両ＵＥはさらに、将来の無線リソースに関する情報を獲得するために、背景技術のセクションで説明したように無線センシング手順を継続的に実行するものとする。この情報は、その後、データ（ならびに対応するスケジューリング割当て）を送信するための無線リソース（および、おそらくは他の送信パラメータ）を選択するために、車両ＵＥによって実行されるモード２無線リソース割当て手順中に使用され得る。センシング手順は、予約された無線リソースを識別するために、他のデバイスによって送信されたスケジューリング割当てを復号することを含む。オプションで、センシング手順はさらに、車両ＵＥのために設定されたデータ送信のための周波数リソース全体にわたるエネルギ測定（例えば、受信信号強度、ＲＳＳＩ）を備える。

リソースセンシング手順の１つの可能性のある実施オプションは、すべてのＵＥが、次のサブフレームから開始して、例えば、１００ｍｓ（例えば、最大１秒）にわたる周波数リソースの予測を有するマップを有することである。次に、パケットがＵＥ内のバッファに到着する時間Ｐにおいて、ＵＥは既に、サブフレームＰからＬまでのすべての周波数リソースのマップ（送信ウィンドウと呼ばれ得る）を準備している。ここで、Ｌは基本的に、パケットが送信されるまでの（ＱｏＳに従う）最大時間スパンに対応する。周波数マップは、利用不可能な無線リソースと利用可能な無線リソースとを区別し得る（そして、恐らくは、異なる無線リソースの予測エネルギレベルに関する情報も備える）。無線センシング手順の他の実施も等しく可能であり、例えば、ここでは、ＵＥは、そのような将来のリソースマップを継続的に更新するのではなく、むしろ必要なときにのみセンシングウィンドウ内の過去の測定から無線リソースを予測する。

要約すると、車両ＵＥは、将来の無線リソースに関する情報を（予約および／またはＲＳＳＩ予測、または他の情報をも）獲得するために、無線リソースセンシング手順を継続的に実行すると仮定される。車両ＵＥはさらに、周期的（および非周期的データ）を送信することができるものとし、それに関連して、（さらに、ＭＣＳ等のような他の送信パラメータの決定を含み得る）データの送信のために使用されるべき送信ウィンドウ内の無線リソースを選択するために、モード２リソース割当て手順（ＵＥによる自律的）を実行するものとする。（変調スキーム、符号化率等のような）送信パラメータに基づいて、車両ＵＥは、送信のために必要なリソースブロックの数を決定し、その後、この決定されたリソースブロックの数を使用して、データの送信のために可能な無線リソースを識別する。例示的に、連続するリソースブロックのみが、サイドリンク送信のために使用されるものと仮定される。

第１の実施形態は、以前に実行されたセンシング手順から取得された結果を考慮した、改良された無線リソース割当て手順を提供する。第１の実施形態によれば、送信ウィンドウ内の無線リソース（すなわち、ＵＥが、送信のために適切な無線リソースを選択し得る無線リソース）は、プライマリサブフレームの無線リソースと、セカンダリサブフレームの無線リソースとで区別される。送信ウィンドウのセカンダリサブフレームは、車両ＵＥがリソースセンシング手順を実行しなかったため、センシングを通じて少ない情報しか取得しなかったセンシングウィンドウ内のサブフレームに対応するものとする。逆に、送信ウィンドウのサブフレームは、車両ＵＥがセンシング手順を実行したセンシングウィンドウ内のサブフレームに対応する場合のプライマリサブフレームである。したがって、セカンダリサブフレームのための予測は、プライマリサブフレームのためよりも正確ではないと考慮されるべきであり、したがって、セカンダリサブフレームからの無線リソースは、リソース割当て手順中に選択されるためには、あまり好ましくない。

より詳細には、サイドリンクインタフェース上の同時送信および受信は、車両ＵＥによってサポートされないので（背景技術のセクションを参照）、車両ＵＥは、サブフレーム内で送信を実行する場合、同時に受信動作を実行できず、したがって、リソースセンシング手順を実行できない。リソースセンシング手順は、無線リソース割当て手順中に使用されるために、将来の無線リソースに関する情報を収集する。現在合意されているように、センシング手順は、少なくとも、無線リソース予約を監視することと、おそらくは、エネルギ測定を実行することとを含む。将来の３ＧＰＰリリースでは、センシング手順中、他のタイプの情報が取得され得、本明細書に提示された実施形態は、依然として適用可能であろう。

例示的に、車両ＵＥは、サブフレームｔにおいて送信を実行し、したがって、そのサブフレームにおいてセンシング手順を実行できなかったと仮定される。したがって、車両ＵＥは、１つまたは複数の他の送信デバイスによるスケジューリング割当ての送信（予約あり、または、予約なし）、および／または、データの送信を見逃している可能性がある。

現在規格化されているように、（ＣＡＭメッセージのような）周期的な車両データは、１００ｍｓの倍数の周期（例えば、２００ｍｓ、３００ｍｓ、４００ｍｓ、・・・、２つのＣＡＭメッセージ間の最大周期は１秒、最小周期は１００ｍｓ）で送信される。異なる周期または追加の周期が将来定義され得、また本明細書に提示された実施形態によって網羅されるものとする。無線リソース予約は、通常、周期的データに対して実行され、したがって、周期的データの上述した可能な周期性に基づく。

センシング手順が実行されなかったサブフレームでは、見逃された可能性のあるスケジューリング割当ては、周期的データについて可能である上記で論じられた周期性に依存して、あらかじめ決定されたいくつかの時間距離においてのみ、無線リソースを予約している可能性がある。簡略のために、スケジューリング割当ては一般に、スケジューリング割当てと同じサブフレーム内のデータ送信のための無線リソースを示し、その結果、サブフレームｔにおいて見逃された無線リソース予約は、例えば、ｔ＋１００ｍｓ、ｔ＋２００ｍｓ、ｔ＋３００ｍｓ、・・・、ｔ＋１０００ｍｓのように、対応するデータ周期離れたサブフレーム内の無線リソースを予約した可能性がある。上記の理由で、サブフレームｔで送信を実行し、したがって、サブフレームｔにおいてセンシング手順を実行しなかった車両ＵＥは、可能な無線リソース割当て手順中（送信ウィンドウ内にある場合）、関連するすべてのサブフレームｔ＋１００ｍｓ、ｔ＋２００ｍｓ、ｔ＋３００ｍｓ、・・・、ｔ＋１０００ｍｓを、セカンダリサブフレームとして考慮する。

同様に、サブフレームｔにおいて見逃されたデータまたはＳＡ送信は、受信信号強度測定によって、車両ＵＥによってセンシングされない。周期的なデータ送信が、固定された時間距離（例えば、１００ｍｓ、または２００ｍｓ、または３００ｍｓ、または・・・、または１０００ｍｓ）でのみ発生し得ることを再度考慮すると、サブフレームｔのための測定情報の欠如により、車両ＵＥは、サブフレームｔ＋１００ｍｓ、およびｔ＋２００ｍｓ、およびｔ＋３００ｍｓ、および・・・ｔ＋１０００ｍｓについてのエネルギ予測は、それほど正確ではないと考慮する。

このように、センシングされないサブフレームは、後続のサブフレームについての予測情報の欠如をもたらし、したがって、第１の実施形態に従って、センシング手順がすべての可能な情報（例えば、無線リソースが予約されているか否か、および、そのサブフレームのすべての周波数無線リソースについてのエネルギ測定値）を取得したプライマリサブフレームとは対照的に、セカンダリサブフレームとして考慮される。

車両ＵＥは、送信ウィンドウ内で、セカンダリサブフレームからの無線リソースよりも、プライマリサブフレームからの無線リソースを好適に選択するものとする。言い換えれば、データを送信するための無線リソースを決定する場合に、プライマリサブフレームから利用可能な無線リソースがない場合に限り、車両ＵＥは、セカンダリサブフレームから無線リソースを選択するものとする。

一般に、無線リソースの選択は、データを送信するために使用されるべき変調スキームおよび符号化率のような送信パラメータの以前の決定に基づく。したがって、車両ＵＥは、送信のために必要となるリソースブロックの数を決定する。３ＧＰＰにおける現在の合意および議論に沿って、連続するリソースブロックが、サイドリンク送信のために使用されるべきであると仮定される。以下の例示的な例示では、データの送信のために３つの連続するリソースブロックが必要とされることが仮定される。したがって、このようにして得られたリソース候補はそれぞれ、以下の図に例示されている。図１０を参照されたい。

この手順に関連して、プライマリサブフレームの無線リソース候補を、セカンダリサブフレームの無線リソース候補とは別個に順位付けすることも有利である。これに対応して、モード２リソース割当て手順中、車両ＵＥは、プライマリサブフレーム内の複数の無線リソース候補を決定した後、データを送信するための最適な候補を選択できるように、これら複数の無線リソース候補を順位付けする。セカンダリサブフレーム内の可能な無線リソース候補は、それとは別個に順位付けされる。すなわち、この順位付けは、セカンダリサブフレームのみの無線リソース候補内で実行される。無線リソース割当て手順中、車両ＵＥは、その後、プライマリサブフレームから最高の順位付けの候補を選択し、利用可能なものがなければ、セカンダリサブフレームから最高の順位付けの候補を選択する。

図１０は、データリソースプールの周波数時間リソース図であり、第１の実施形態の１つの例示的な実施に従うセンシングおよび無線リソース割当て手順の結果を例示的に例示している。図１０は、サイドリンクインタフェースを介して車両ＵＥがデータ送信を実行するために一般に利用可能な、例えば、背景技術のセクションで記述されたような、データ無線リソースプールからの適切な無線リソースである、周波数時間無線リソースを開示している。これに対応して、例えば、データ送信リソースプールの無線リソースのような、これら無線リソースに対して、（センシングウィンドウ内で実行される）センシング手順も実行される。例示の容易のために、図９に例示されるような、送信ウィンドウ内の無線リソース候補に対するセンシングウィンドウ内の関連するエネルギ測定は、図１０から省略されている。これから明らかなように、サブフレームｔにおけるＵＥ送信、ならびに結果として得られるセカンダリサブフレームｍは、ｔ＋６００ｍｓにおいて例示される。図１０の例示では、サブフレームｔ内の見逃されたセンシング機会は、送信ウィンドウ内に単一のセカンダリサブフレームｍしかもたらさないと仮定される。例えば、送信ウィンドウは、わずか１００ｍｓである。送信ウィンドウの長さに依存して、サブフレームｔにおけるＵＥ送信は、２つ以上のセカンダリサブフレーム（すなわち、ｔ＋６００ｍｓ、およびｔ＋７００ｍｓ、ｔ＋８００ｍｓ、・・・）をもたらし得る。プライマリサブフレームの無線リソース候補内ならびにセカンダリサブフレームの無線リソース候補内の別個の順位付け手順も図１０から明らかである。セカンダリ無線リソース候補は破線で囲まれている。特に、プライマリサブフレームからの（１から４に順位付けされた）４つの無線リソース候補があり、プライマリ無線リソース候補が利用可能ではない場合、セカンダリサブフレームからの（１から２に順位付けされた）２つの無線リソース候補がある。

第１の実施形態の１つの例示的実施に従う車両ＵＥの挙動を例示する簡略化された例示的シーケンス図が図１１に提示されている。一般に上記で説明されたような車両ＵＥによって実行されるべき様々なステップが図１１に描写される。リソースセンシング手順は、リソースセンシングが継続的に実行されるべきであることを示すために、個別に描写されている。プライマリサブフレームおよびセカンダリサブフレームのためのリソースセンシング手順から無線リソース候補検索および順位付けステップまでの破線は、情報の入力（例えば、無線リソース予約、および無線リソースエネルギ測定）として理解されるものとする。

無線リソース候補順位付け手順をどのように実行するかについて、いくつかのオプションがある。１つの可能な、不利ではある解決策が、上記の図９に関連して提示される。あるいは、候補順位付けは、無線リソース候補とパケット到着時間との間の時間遅延のみに基づいてもよく、すなわち、短い遅延のみをもたらす候補が、長い遅延を被る候補よりも好適になるように、順位付けにエネルギ測定値／予測を考慮しない。第１の実施形態の変形として、他の特に有利な順位付け手順が以下に記述される。順位付け手順は、データが送信のために利用可能になった時点からの無線リソース候補の時間距離だけでなく、センシングウィンドウ中に実行されたエネルギ測定に基づき得る。データの送信のための候補を使用することによって生じるであろう遅延をさらに考慮することによって、データ送信の待ち時間は減少されるであろう。同時に、無線リソース候補のリソース占有尤度も、過去のＲＳＳＩ測定値を考慮することによって考慮され得る。

順位付けのために考慮される２つの特性であるエネルギ予測および遅延は、異なる方式で考慮され得る。特に、無線リソース候補とパケット到着時間との間の遅延が、最初に考慮され得、同じ時間遅延を有する複数の無線リソース候補がある場合、同じ遅延を有する候補を順位付けするために、受信信号強度予測が使用され得る。リソース候補は、例えば、最低のエネルギ予測値を有する候補が、そのサブフレームについて最高の順位付けの候補となるように、ＲＳＳＩが増加する順に高いものから低いものへ順位付けされる。逆に、受信信号強度予測が最初に考慮され、その後、同じ受信信号強度予測を有する複数の無線リソース候補がある場合には、時間遅延が、順位付けのために使用され得、ここでは、より短い時間遅延は、より長い時間遅延よりも高く順位付けされる。さらなる代替によれば、遅延および受信信号強度予測の関数が、無線リソース候補を順位付けするために使用され得る。例示的な関数は、Ｚ_ｉ＝Ｘ＊Ｔ_ｉ＋Ｙ＊ＲＳＳＩ_ｉであり得る。ＸとＹはそれぞれ時間遅延と受信信号強度特性に与えられる重みである。Ｔ_ｉは、無線リソース候補ｉとパケット到着時刻との間の時間距離を示す。ＲＳＳＩ_ｉは、（センシングウィンドウ中の以前の測定値に基づいて）無線リソース候補ｉの受信信号強度に関する予測値を示す。値Ｚ_ｉが小さいほど、リソース候補ｉの順位が高い。重みＸおよびＹは、例えば、ｅＮＢによって設定され得るか、そうでなければ、あらかじめ決定され得る。

上記で記述されたように時間遅延を主に考慮する例示的な順位付け手順の結果が図１０に例示される。これから明らかなように、最高に順位付けされた（順位付け値１）プライマリ無線リソース候補は、パケット到着時間に関して最小の遅延を有するプライマリサブフレーム内の無線リソース候補である。プライマリサブフレーム内の残りの無線リソース候補もまた、パケット到着時刻までの時間距離に基づいて順位付けされる。一方、セカンダリサブフレームｍの順位付け手順は、２つの無線リソース候補を区別するために、センシングウィンドウ中に実行されたエネルギ測定値にさらに依存する必要がある。例示的な順位付けが、図１０に例示される。

第１の実施形態のさらに有利な変形は、無線リソース候補のための受信エネルギレベルの予測を改良する。図９に関連して説明したように、１つの可能なオプションは、特定の無線リソース候補の受信信号強度を予測するために、全センシングウィンドウにわたって、特定の無線リソース候補の無線リソースに対応する無線リソースにおけるエネルギ測定値を使用することである。しかしながら、これは、無線リソース候補のこの１つのサブフレームにおける実際の送信状況を反映しないかもしれないという欠点を有する。送信エネルギ予測を改良するために、関連サブフレームのみが予測のために考慮されるべきである。より詳細には、センシングウィンドウ内の関連サブフレームは、順位付けされるべき無線リソース候補に関して可能なデータ周期の時間距離を有するものである。データ送信について現在仮定されているように、データ周期は、１００ｍｓの倍数（最小１００ｍｓおよび最大１０００ｍｓ）である。結果として、送信ウィンドウ内の特定のサブフレームｍについて改良されたエネルギ予測に関し、センシングウィンドウ内の関連サブフレームは、ｍ−１００ｍｓ、ｍ−２００ｍｓ、ｍ−３００ｍｓ、ｍ−４００ｍｓ・・・、およびｍ−１０００ｍｓである。センシングウィンドウのそれらの関連サブフレームにおいて実行されたエネルギ測定のみが、送信ウィンドウのサブフレームｍにおけるエネルギを予測するために使用される。

図１２は、図１０に関して既に採用された仮定に基づいて、この改良された送信エネルギ予測を例示的に示し、プライマリサブフレームおよびセカンダリサブフレームについて決定された６つの無線リソース候補を区別する。これから明らかなように、図１２は、サブフレームｕにおけるプライマリ無線リソース候補１について、サブフレームｕ−６００ｍｓおよびｕ−１０００ｍｓの対応する無線リソースにおけるエネルギ測定を示す。センシングウィンドウの残りの関連サブフレーム、すなわち、ｕ−１００ｍｓ、ｕ−２００ｍｓ、・・・、ｕ−５００ｍｓ、ｕ−７００ｍｓ、ｕ−８００ｍｓ、ｕ−９００ｍｓにおけるエネルギ測定もまた、例示の容易のために、それらが図１２に図示されていないが、考慮される。同様に、関連サブフレームの異なる無線リソースにおけるエネルギ測定が使用されるが、セカンダリサブフレームｍの無線リソース候補の両方は、センシングウィンドウ内のサブフレームｍ−１００ｓ、ｍ−２００ｍｓ、・・・、ｍ−１０００ｍｓに関連する。これに対応して、図１２は、エネルギ予測のために使用されるサブフレームｍ−１０００ｍｓ内の関連無線リソースをマークする。サブフレームｍ−６００ｍｓの無線リソースにおけるエネルギ測定は、車両ＵＥによって実行される送信のために可能ではなかったことが注目されるべきである。以前に論じたように、送信ウィンドウのサブフレームｍへの影響を有する６００ｍｓの周期を有する可能な周期的送信は、センシングされないであろう。これは、サブフレームｍを、無線リソース割当て手順にとって単に２次的であるとして分類する理由の１つである。関連サブフレームの無線リソースにおいて測定された受信信号強度（すなわち、エネルギ）は、例えば、送信ウィンドウのサブフレームにおける無線リソース候補の予測を得るために平均化され得る。

この利点は、改良されたエネルギ予測は、データ送信の可能な周期を考慮するので、より正確であるということである。

第１の実施形態の他の有利な実施は、プライマリサブフレームまたはセカンダリサブフレームのいずれにおいても適切な無線リソースが発見されない場合の解決策を提供する。以前に論じたように、プリエンプション手順は、それらが他の送信デバイスによって既に予約されているときでも、送信ウィンドウ内の無線リソースの中から無線リソースを選択することを可能にする。

図１３は、図１１の図に基づいて、（また、プライマリサブフレーム内のリソースを発見することに失敗した後に）車両ＵＥが、セカンダリサブフレーム内のリソースを発見することができない場合のステップとして、プリエンプション手順を用いて拡張されるＵＥ挙動の例示的シーケンス図である。図１３から明らかなように、プリエンプション手順中に無線リソースを決定した後、車両ＵＥは、スケジューリング割当てのための対応する無線リソースを決定し、その後、ＳＡとデータとの両方を送信する。さらに、プリエンプションボックスは、無線リソースに関するエネルギ測定、他のデバイスによって行われる無線リソース予約、および、恐らくは、無線リソース予約の優先順位に関する情報のような情報を、リソースセンシング手順から入力として受信する。後者の情報は、（ＰＰＰＰ、ＰｒｏＳｅ−Ｐｅｒ−Ｐａｃｋｅｔ−Ｐｒｉｏｒｉｔｙ：ＰｒｏＳｅパケットごと優先順位のような）優先順位情報が、無線リソース予約と共に送信され、したがって、センシング手順中に車両ＵＥによって復号され記憶されることを必要とする。

図１４は、無線リソースが利用可能ではない場合に車両ＵＥによって実行され得、図１３に例示されたプリエンプション手順の１つの可能な実施として見られるべきであるプリエンプション手順についての簡略化された例示的なシーケンス図である。プリエンプション手順の開始時に実行されるべきオプションのチェックは、送信されるべきデータが破棄され得る（すなわち、送信されないように破棄される）か否かである。１つの実施例では、車両ＵＥは、データの優先順位に基づいてデータが破棄されるべきか否かを決定する。このデータの優先順位は、適切な優先順位しきい値と比較され得る。データは通常、データの優先順位を示すＰｒｏＳｅパケットごと優先順位（ＰＰＰＰ）に関連付けられる。適切な優先順位しきい値は、例えばｅＮｏｄｅＢによって、車両ＵＥにおいて定義され得る。そして、破棄され得るデータとされ得ないデータとを区別するために使用される。優先順位が十分に高くない（例えば、優先順位しきい値を下回る）場合、データは破棄される。そうではない場合、プリエンプション手順は、今度はデータの送信のために使用されるべき無線リソースを選択することに進むが、しかしながら、これに加えて、プライマリサブフレームおよびセカンダリサブフレーム内の以前の候補サーチから最初に除外された予約無線リソースも考慮に入れる。上述したように、データの破棄は、車両ＵＥによって実行されるオプションのチェックであり、したがって、例えば、ｅＮＢによって、または、車両ＵＥの上位レイヤによって設定可能であり得る。

プリエンプション手順の一部であるとして例示されているが、破棄チェックは、実際のプリエンプション手順外で実行され得、その結果、（破棄チェックなしの）プリエンプション手順は、パケットが破棄されないときにのみ実行される。

さらに、データを破棄するか否かについての決定は、（ＲＲＣまたはアプリケーションレイヤのような）車両ＵＥの上位レイヤによって行われ得る。

プリエンプションは、データを送信するために他の送信デバイスによって既に予約されている無線リソースを、選択して、使用する処理を称する。したがって、予約された無線リソースの中には、それ自体の送信によって「上書き（overwritten）」されるものがあり、これは深刻な干渉を引き起こす可能性があるため、可能であれば回避されるべきである。それにも関わらず、データが十分に重要である場合、車両ＵＥは、部分的にまたは全部において、予約された無線リソースを備えた、適切なリソースブロックサイズを有する１つまたは複数の無線リソース候補を決定するべきである。利用可能な複数のリソース候補がある場合、車両ＵＥは、最も適切な候補を決定する必要がある。１つの可能なオプションは、以前に既に論じたように、送信ウィンドウ全体にわたって、または好適には、プライマリサブフレーム内で、次に、セカンダリサブフレーム内で、候補のランダム選択を実行することである。

第１の実施形態の有利な実施によれば、プリエンプション手順中の無線リソース候補の選択は、無線リソースの優先順位、および／または、センシングウィンドウ内においてセンシング手順中に決定されたＲＳＳＩ予測値を考慮することによって、プリエンプションによって引き起こされるあらゆる問題を緩和するように改良される。一例では、車両ＵＥは、予約された無線リソースのうち、最低の優先順位を有する無線リソース候補を選択することによって、プリエンプションを実行する。その後、同じ優先順位を有するいくつかの候補が残っている場合、車両ＵＥは、最低のＲＳＳＩ予測値を有するその候補を選択し得る。第２の例では、車両ＵＥは最低のＲＳＳＩ予測レベルを有する無線リソース候補を選択し、いくつかの候補が残っている場合には、最低の優先順位を有する無線リソースを有する候補が、データを送信するために選択される。あるいは、別個に重み付けされた２つのパラメータ、すなわち、予約優先順位およびＲＳＳＩに基づいて関数が定義され得る。例示的な関数は、Ｚ_ｉ＝ｗ１＊１／Ｐ_ｉ＋ｗ２＊ＲＳＳＩ_ｉであり得る。ｗ１およびｗ２はそれぞれ、優先順位（最低の優先順位値が、最高の優先順位）および受信信号強度特性に与えられる重みである。Ｐ_ｉは、リソース候補ｉの一部として特定の無線リソース予約に与えられた優先順位を表し、ＲＳＳＩ_ｉは、無線リソース候補ｉの受信信号強度の予測値を示す。車両ＵＥは、小さい（最小の）Ｚ_ｉ値を有する無線リソース候補を選択するものとする。

オプションで、予約された無線リソースのみが、送信されるべきデータよりも低い優先順位を有してプリエンプションされるように、予約の優先順位が、データの優先順位と比較され得る。別のオプションとして、無線リソースの選択を、両方のしきい値を下回る「最適な」無線リソースのみに制限できるように、対応する優先順位およびエネルギしきい値を定義することが可能であり得、しきい値を超える無線リソースは除外される。オプションの追加として、プリエンプション手順は、プライマリサブフレームとセカンダリサブフレームとを区別することもでき、その後、セカンダリサブフレーム内の候補よりも、プライマリサブフレームから、好適に候補を選択するものとする。

これに加えて、または、その代わりに、プリエンプション手順は、好適には、最小量の予約された無線リソースを無効にするデータの送信のための無線リソース候補を決定するべきである。特に、サイドリンクを介したデータ送信のために、連続するリソースブロックのセットしか使用されないことを考慮すると、データを送信するのに十分大きなリソースブロックセットを取得するために、わずかな予約リソースブロックをプリエンプションするだけで十分である。それにより、他の送信ＵＥとの干渉が低減される。

プリエンプション手順のさらなる可能な基準として、プリエンプションによって影響を受けるであろう他のデバイスの数を最小化するように、または、各デバイスが、データをまだ復号できる間に、プリエンプションによってさほど影響されないよう、他のデバイスの数を最大化するように、予約無線リソースが選択され得る。

上記の例のうちのいずれかに従って２つまたは３つのパラメータ（予約優先順位、データ優先順位、またはＲＳＳＩ）を考慮した後にいくつかの候補が残っている場合、車両ＵＥは、残りの無線リソース候補のうちの１つをランダムに選択し得る。

プリエンプション手順のためにエネルギ予測値を考慮することによって、車両ＵＥによって実行されるデータ送信と、近くに位置する車両ＵＥのプリエンプションデータ送信との強い干渉が回避されるはずである。

このように、データの送信のために適切な無線リソースを決定した後、図１３に例示されるように、車両ＵＥは、スケジューリング割当てを送信するためのリソースを選択し、その後、スケジューリング割当てとデータの両方を送信する。

第１の実施形態のさらに有利な実施によれば、サイドリンクチャネルの輻輳レベルが、車両ＵＥにおいて実行される無線リソース割当て手順のために考慮される。サイドリンクチャネルの輻輳レベル（チャネルビジー率、ＣＢＲとも称され得る）は、例えば、十分なサンプルのエネルギレベルを、帯域幅全体にわたって、または１つのリソースプール内でのみ、しきい値と比較することによって、車両ＵＥによって決定される。例えば、サンプルの９０％が、しきい値より高いエネルギレベルを有している場合、ＣＢＲは９０％である。しきい値は、ｅＮＢによって固定または設定され得るか、または事前設定され得る。ＣＢＲは、キャリアまたはリソースプールのビジーレベルの尺度となる。ＣＢＲは、チャネル状態を考慮して、データを破棄するか否かを決定するために、車両ＵＥによって使用され得る。一般に、このＣＢＲチェックはオプションであり、例えば、ｅＮｏｄｅＢによって設定され得るか、または（例えば、オペレータによって）事前設定され得、それによって、ＣＢＲチェックが実行されるべきか否か、および、どのように実行されるべきかについてＵＥを設定する。例えば、ｅＮｏｄｅＢが保守的であり、サイドリンクキャリアを保護したい場合、そのようなＣＢＲチェックを実行するように（例えば、システム情報ブロードキャストによって）セル内のいくつかまたはすべてのＵＥを設定し得る。一方、ｅＮｏｄｅＢが、より高いスループットを達成することに関心がある場合、ｅＮｏｄｅＢは、このＣＢＲチェックを実行しないようにＵＥを設定し得る。ＣＢＲチェックの１つの可能な実施は、送信されるべきデータの優先順位を採り、それを優先順位しきい値と比較する。優先順位しきい値は、オプションで、サイドリンクチャネルについて検出されたＣＢＲに依存し得る。例えば、送信されるべきデータの優先順位が十分に高い場合にのみ、チャネルの高い輻輳レベルにも関わらず、手順が進行する。一方、低い優先順位データは、ビジーチャネルを考慮して破棄され得る。

送信されるべきデータのトラフィックタイプもまた、データの優先順位に加えて、または、その代わりに、ＣＢＲ破棄機能に考慮され得る。例えば、安全トラフィック（safety traffic）と非安全トラフィック（non-safety traffic）とのために、異なるしきい値が定義され得る。数字が大きいほど優先順位が低くなる１から５までの優先順位レベルを仮定する。９０％であるＣＢＲの場合、優先順位レベル５の安全トラフィックと、優先順位レベル５、４、および３の非安全トラフィックとは、破棄されるべきである。一方、ＣＢＲが８０％である場合、安全トラフィックは破棄されないが、優先順位レベル５の非安全トラフィックだけが破棄される。ＣＢＲが７０％の場合、安全トラフィックは破棄されず、優先順位レベル５または４の非安全トラフィックは破棄されるものといった具合である。

データが破棄された場合、担当する上位レイヤは、データの送信の失敗について通知され、その結果、例えば、上位レイヤは、後にデータを再度送信することを決定するか、または、上位レイヤにおいてもデータを破棄して、ユーザに、失敗した送信を通知することができる。

図１５は、図１１の図に基づき、上記で論じたようにＣＢＲチェックを用いて拡張された例示的なシーケンス図である。特に、データが送信のために利用可能になった後、車両ＵＥは、チャネルビジー率を考慮することによって、データを破棄するか否かを決定し得る。車両ＵＥがデータを破棄しないことを決定した場合、図１１から知られ、上記で詳細に記述された手順が、その後、継続される。

ＣＢＲチェックは、リソース割当てが開始されるべきか否かを判定するために、リソース割当て手順の一部、または、リソース割当て前のステップのいずれかと考慮され得る。

さらに、無線リソースセンシング手順は、モード２リソース割当てのために車両ＵＥ内に設定された無線リソースプールごとに実行され得る。前記の場合、車両ＵＥがＣＢＲチェックを使用するか否か、またどのように使用するかが、リソースプールごとに設定され得る。例えば、データリソースプールの設定中、ｅＮｏｄｅＢは、ＣＢＲチェックが実行されるべきか否か、および、どのように実行されるべきであるかを示し得る。カバレッジ外のＵＥ、および、対応する無線リソースプールの場合、ＣＢＲ設定は、各リソースプールの事前設定の一部であり得る。

第１の実施形態のさらに有利な実施によれば、スケジューリング割当てそれぞれとデータの計画された送信が、別のＵＥのデータ送信と衝突するか否かを判定するために、衝突チェックが提供される。図１６は、図１１の図に基づいており、以下に論じられるように衝突チェックの１つの実施で拡張された例示的なシーケンス図である。図１６から明らかなように、スケジューリング割当ておよびデータを送信するために適切なリソースを選択した後、車両ＵＥは、センシング手順を実行し続け、したがって、他のＵＥによって送信されるスケジューリング割当てを監視して、恐らくは、将来のためのリソース予約を行う。他のＵＥから受信されたスケジューリング割当てに基づいて、車両ＵＥは、計画されたスケジューリング割当ての送信が、監視されたスケジューリング割当てによって示されるように、他のＵＥによってアナウンスされた送信と衝突するか否かをチェックし得る。衝突の場合、車両ＵＥは、どのようにしてさらに進むべきかを決定することができ、例えば、衝突している２つの送信、すなわち、それ自体のＳＡ送信および他のＵＥの送信の優先順位を比較し得る。自身のＳＡ送信が、より高い優先順位を有する場合、車両ＵＥは、既に計画されているように、スケジューリング割当ての送信を続ける。他の場合では、車両ＵＥは、スケジューリング割当てのために、そして必要であればデータ送信のために、新たな無線リソースを決定するように、無線リソース割当て手順の最初のステップに戻り得る。あるいは、衝突の場合、特に、自身のＳＡ送信の優先順位がより低いときに、ＳＡおよびデータは破棄される。

衝突検出は、データ送信に対しても同様に機能する。データ送信のためのスケジューリング割当てが送信されたと仮定される。センシング手順は、データ送信時まで車両ＵＥによって継続的に実行され、したがって、自身のデータ送信と衝突する、他のデバイスによる可能なデータ送信が、検出され得る。このような衝突の場合、車両ＵＥは、例えば、２つのデータ送信の優先順位を比較し得る。自身のデータ送信が、より高い優先順位を有する場合、車両ＵＥは、以前に計画されたようにデータの送信を継続する。他の場合では、車両ＵＥは、データおよびＳＡ送信のための新たな無線リソースを決定するために、無線リソース割当て手順の最初のステップに戻る必要があり得る。あるいは、衝突の場合、特に自身のデータ送信の優先順位が低いとき、データは破棄される。

上記では、第１の実施形態の異なる実施が記述された。ここでは、図１１に関連して「基本的な」実施が記述され、前記「基本的な」実施に対する拡張が、図１３、図１４、図１５、および図１６においてそれぞれ記述される。この拡張は個別に記述および図示されているが、完全なＵＥ挙動を形成するために、それらの一部または全部を組み合わせることができ、これは、図１３のプリエンプション手順、および／または図１５のＣＢＲ破棄機能、および／または図１６の衝突チェックを備える。

上記では、車両ＵＥは、ＵＥによる自律的なリソース割当て（モード２）のために、センシング手順の結果を常に使用すると仮定された。しかしながら、リソース割当てのためにセンシングを使用するか否か、およびどのように使用するかが、代わりに、設定可能であり得、および／または、車両ＵＥが送信のために無線リソースを選択している無線リソースプールに依存し得る。より詳細には、１つの実施では、車両ＵＥを担当するｅＮｏｄｅＢは、センシング手順が無線リソース割当てに影響を与えるべきか否か、およびどのように影響を与えるべきかを制御する。例えば、ｅＮｏｄｅＢは、セル内の対応する設定をブロードキャストして、設定を受信するセル内のすべての車両ＵＥが、ＵＥによる自律的なリソース割当てのためにセンシングを使用するか否か、およびどのように使用するかを学習する。あるいは、１つまたは複数の車両ＵＥにおいて、センシング手順が実施されるべきか否か、およびどのように実施されるべきかを制御するために、無線基地局から、これら車両ＵＥのみに、専用メッセージが送信される。

［第２の実施形態］
以下では、第１の実施形態の様々な実施と組み合わせて使用され得る第２の実施形態が記述される。第１の実施形態に関連して、車両ＵＥが実際にどのようにリソース選択を行うかについて詳細に説明することなく、車両ＵＥが、スケジューリング割当てを送信するためのリソースを選択すると単に仮定された。背景技術のセクションで説明したように、スケジューリング割当ての送信のためのリソースの選択は、３ＧＰＰの以前のリリースでは明確に定義されている。要するに、ＵＥによる自律的な無線リソース割当て（モード２）の場合、車両ＵＥは、対応するスケジューリング割当てリソースプールから、無線リソースをランダムに選択し、さらにこのスケジューリング割当ての繰り返しのためにＴ−ＲＰＴパターンを選択し得る。しかしながら、３ＧＰＰは、データ送信のためのリソース選択のための改良を実施することを議論し合意する（上記で論じたように、無線リソース予約メカニズムならびにセンシング手順が導入された）一方で、スケジューリング割当ての送信が将来のリリースでどのように改良されるかに関して、議論も合意もなされていない。Ｖ２Ｘデータ送信に関して合意された改良のための１つの動機付けは、そのような送信の信頼性を高めることであり、それは（例えば、衝突率に関して）データ送信のための無線リソースの純粋なランダム選択では保証されないかもしれない。例えば、車両ＵＥの数は将来増加すると思われ、スケジューリング割当ての送信のためのランダムなリソース選択メカニズムは、衝突による失敗数の増加につながる可能性がある。しかしながら、特に車両通信の環境におけるスケジューリング割当てのロバストな送信は、データの確実な送信と同様に重要である。

したがって、第２の実施形態は、スケジューリング割当て送信のための無線リソースを選択するための、改良されたＵＥによる自律的な無線リソース割当て手順を提供する。スケジューリング割当ての送信は、第１の実施形態に関して論じられたように、データ送信のために予想される改良を模倣するように改良される。これに対応して、第２の実施形態の実施は、スケジューリング割当てを送信するために送信デバイスによって使用可能である１つまたは複数のＳＡリソースプールの無線リソースのために、車両ＵＥによって実行されるリソースセンシング手順を提供する。第１の実施形態において記述されたような無線リソースセンシング手順が、恐らくは、異なる無線リソース、すなわちデータを送信するために送信デバイスによって使用可能なデータリソースプールの無線リソースをセンシングすることが、注目されるべきである。しかしながら、スケジューリング割当てリソースプールの無線リソースと、データリソースプールの無線リソースとは重複し得る。いずれにせよ、第１の実施形態で詳細に記述されたものと同様の方式で、車両ＵＥは、それらの無線リソースにおけるセンシング手順を継続的に実行することによって、将来のスケジューリング割当て無線リソースに関する情報を獲得するものとする。

第２の実施形態の以下の実施においてより詳細に記述されるように、無線リソース予約は、第１の実施形態において記述されたようなデータの送信のためだけでなく、スケジューリング割当ての送信のためにも実施されるものとする。スケジューリング割当ておよびデータのための無線リソース予約は類似し得る。要するに、スケジューリング割当てにおいて適切なインジケーションを提供することによって、現在のスケジューリング割当ての送信のために使用される無線リソースは、将来の１つまたは複数のスケジューリング割当て送信のために予約され得る。

他のデバイスによって送信されたスケジューリング割当てを監視することによって、リソースセンシング手順はまた、無線リソースが、スケジューリング割当ての送信のために、他の送信デバイスによって予約されているか否か、および、どの無線リソースが予約されているかに関する情報を、車両ＵＥが獲得することを可能にするものとする。これらの予約された無線リソースは、スケジューリング割当てを送信するための無線リソースを選択するために、車両ＵＥによって実行される無線リソース割当て手順から除外され得る。無線センシング手順はまた、スケジューリング割当ての送信のために設定された周波数リソース全体にわたるエネルギ測定（例えば、受信信号強度、ＲＳＳＩ）をも備え得る。将来的には、他のタイプの情報も、同様に収集され得る。したがって、センシング手順は、スケジューリング割当てを送信するために使用されるべき将来の無線リソースに関する情報を収集する。これは、スケジューリング割当てを送信するための最適な無線リソースを選択するために、リソース割当て手順中に使用され得る。

車両ＵＥは、スケジューリング割当ておよび保留データを送信するためのリソースを決定するために、周期的データを送信し、ＵＥによる自律的な無線リソース割当て手順を実行するものとすると仮定される。

第１の実施形態に関連して既に詳細に論じたように、無線リソース割当て手順は、センシング手順から取得された結果を考慮して、プライマリサブフレームの無線リソースと、セカンダリサブフレームの無線リソースとを区別することによって改良され得る。送信ウィンドウのセカンダリサブフレームは、センシングウィンドウにおけるサブフレームに対応するものとする。ここでは、車両ＵＥは、必ずしも、常にリソースセンシング手順を実行した訳ではない。したがって、車両ＵＥが常にセンシング手順を実行し、可能なすべての情報を取得する、センシングウィンドウにおけるサブフレームに対応するプライマリサブフレームと比較して、センシングによって少ない情報しか取得しない。したがって、第１の実施形態に関して詳細に説明されるように、車両ＵＥは、セカンダリサブフレーム内の別のＵＥによるスケジューリング割当て送信の予約を見逃している、または、セカンダリサブフレームのエネルギ予測に影響を及ぼすエネルギ測定を逃している。

したがって、セカンダリサブフレームに対する予測は、プライマリサブフレームに対する予測よりも正確ではなく、セカンダリサブフレームからの無線リソースは、プライマリサブフレームからの無線リソースよりも、好適に選択されるべきではない。

結果として、データ送信のための無線リソースの選択に関連して、第１の実施形態について詳細に提示されたリソース割当て手順のこの改良は、第２の実施形態に従って、スケジューリング割当ての送信のための無線リソースの選択に適用され得る。

図１７は、第１の実施形態の図１１と同様、第２の実施形態の実施に従う例示的かつ簡略化されたＵＥ挙動を例示するシーケンス図である。これから明らかなように、スケジューリング割当てを送信するための無線リソースの選択は、プライマリサブフレームにおけるサーチと、セカンダリサブフレームにおける後続するサーチとに分割される。特に、データが、送信のために利用可能になった後、車両ＵＥは、送信ウィンドウ内で、プライマリサブフレームから、ＳＡ送信のための無線リソースを好適に選択するものとし、ＳＡ送信のための無線リソースが、プライマリサブフレームから利用できない場合、車両ＵＥは、セカンダリサブフレーム内のＳＡ送信のための無線リソースをサーチするものとする。その後、手順は、スケジューリング割当ての送信、および後続する保留データの送信を続ける。

図１８は、スケジューリング割当てリソースプールのための周波数時間無線リソースを例示しており、リソースは、スケジューリング割当てを送信するために、車両ＵＥに利用可能である。図１０でなされたものと類似した方式で、図１８は、センシングウィンドウの１つのサブフレームにおける未実行のセンシング手順の結果として、プライマリサブフレームおよびセカンダリサブフレームが送信ウィンドウ内でどのように定義されるのかを例示する。また、スケジューリング割当ての送信に関し、車両ＵＥはまず、適切な送信パラメータ、したがって、ＳＡ送信のために必要となるリソースブロックの数を決定しなければならない。現在合意されているように、２つの物理リソースブロックペアが、スケジューリング割当ての送信のために使用されるものとする。その後、車両ＵＥは、スケジューリング割当ての送信のために利用可能となる可能な無線リソース候補を決定し、候補サーチの例示的な結果が、図１８に例示される。

プライマリサブフレームの無線リソース候補は、例えば、第１の実施形態について論じられたものと同じまたは類似の方式で、セカンダリサブフレームからの無線リソース候補とは別個に順位付けされるものとする。これは図１８にも例示されており、図１８は、４つのプライマリＳＡ無線リソース候補と、別個に２つのセカンダリＳＡ無線リソース候補を図示している。特に、第１の実施形態に従うデータの送信に関して論じられたような順位付け手順の様々な異なる実施は、スケジューリング割当てを送信するために使用可能な無線リソース候補を順位付けするためにも再使用され得る。例えば、図９に関連して論じられたような順位付けは、可能であるが不利である。あるいは、候補順位付けは、特に、スケジューリング割当てが、データ送信として、以前に（または、同じサブフレームで）送信される必要があることを考慮して、無線リソース候補とパケット到着時刻との間の時間遅延のみに基づき得る。候補順位付けのための別のオプションは、センシング手順中に実行されたエネルギ測定に基づいて、無線リソース候補についての時間遅延とエネルギ予測との両方を考慮し、第１の実施形態に関連して様々な異なる実施が上記において提示され、第２の実施形態の実施に対して本明細書で再使用され得る。

図１２に関連して説明したように、第１の実施形態の特に有利な実施形態は、エネルギ予測を改良する。これらの改良されたエネルギ測定および予測はまた、スケジューリング割当てを送信するのに使用可能な無線リソースに関して、車両ＵＥによって実行されるリソースセンシング検知手順にも適用され得る。これに対応して、サブフレームｍ内の特定のリソース候補に対するエネルギ予測は、リソース候補のサブフレームに関連するサブフレーム、すなわち、可能な周期であるｍ−１００ｍｓ、ｍ−２００ｍｓ、ｍ−３００ｍｓ、・・・、ｍ−１０００ｍｓ離れたサブフレームのみの感知ウィンドウにおける測定を考慮するものとする。

図１７に例示されるように、プライマリおよびセカンダリサブフレーム内に適切な無線リソースが発見されない場合のためのリソース割当て手順中に、プリエンプション手順が予測され得る。第１の実施形態において詳細に論じられたものと類似の方式で、スケジューリング割当ての送信のために他のＵＥによって予約されている無線リソースは、依然としてスケジューリング割当てを送信できるように、車両ＵＥによってプリエンプションされ得る。さらに、プリエンプション手順は、スケジューリング割当てが破棄されるべきか否かに関する決定を備えてもよく、その決定は、スケジューリング割当てが送信されるデータの優先順位に基づくことができ、この優先順位は、適切な優先順位しきい値と比較されてよい。データ、ここではスケジューリング割当てが、十分な優先順位を有する場合、車両ＵＥは、スケジューリング割当ての送信のためのリソース候補を決定することに進み、今度は、予約された無線リソースをも考慮する。プリエンプション手順の様々な有利な実施形態は、第１の実施形態に関連して詳細に論じられており、スケジューリング割当ての送信のための無線リソース候補の選択を改良するために再使用されてよい。例えば、センシングウィンドウ内のセンシング手順中に決定された、予約された無線リソースの優先順位および／またはＲＳＳＩ予測が、考慮され得る。さらに、予約された無線リソースの優先順位が、送信されるべきデータの優先順位と比較され得る。また、プリエンプション手順は、プライマリサブフレームとセカンダリサブフレームとを区別し得、プライマリサブフレームから無線リソース候補を好適に選択するものとする。

要約すると、車両ＵＥは、スケジューリング割当てを送信するために最適な無線リソースを選択する。上記で論じたように、車両ＵＥはまた、スケジューリング割当ての次の送信のために無線リソースを予約するものとする。

第２の実施形態のいくつかの実施では、車両ＵＥが、スケジューリング割当ての送信に、半持続的スケジューリング（例えば、無線リソース予約およびセンシング手順）を適用するか否かは、設定可能であり得る。１つの例示的な実施によれば、車両ＵＥを制御するｅＮｏｄｅＢは、スケジューリング割当ての将来の送信のための無線リソースをさらに予約し、対応するＳＡリソースプールの無線リソースにおけるセンシング手順の結果に基づいて無線リソース選択を実行することによって、セル内のいくつかまたはすべてのＵＥが、スケジューリング割当て送信を改良するか否かを決定し得る。その後、ｅＮｏｄｅＢは、それに応じて車両ＵＥに通知し得る。例えば、ｅＮｏｄｅＢのセル内のすべてのＵＥが、同じ方式で設定される場合、ｅＮｏｄｅＢは、そのセル内でシステム情報メッセージをブロードキャストし、前記ブロードキャストメッセージを受信するすべてのＵＥが、指示通りにＳＡ送信手順を設定する。

一方、スケジューリング割当てをどのように送信するかは、データを送信するときに車両ＵＥが従う送信手順に結合され得る。その結果、車両ＵＥが、半持続的スケジューリングをデータ送信に適用する場合、対応するＳＡ送信にも、同様にセンシング手順のために、半持続的スケジューリングを適用するものとする。ＵＥが半持続的スケジューリングを使用しない場合、スケジューリング割当ての送信は、例えば、センシング手順の結果を参照せずに、適切なＳＡ無線リソースプールから無線リソースをランダムに選択することによって、従来技術で記述されたものと同じ方式で取り扱われ得る。

セル内でブロードキャストメッセージを送信する代わりに、またはそれに加えて、ｅＮｏｄｅＢは、選択された車両ＵＥに専用メッセージを送信し得る。したがって、これらのＵＥは、専用メッセージにおける命令に従って、自身を設定する。それによって、ｅＮｏｄｅＢは、スケジューリング割当てを送信するための半持続的スケジューリングを実行するように、車両ＵＥを選択的に設定でき得る。

スケジューリング割当て送信を実行するか否か、および、どのように実行するかの設定は、特定のＳＡリソースプールにも依存され得、したがって、センシング手順と同様に、半持続的スケジューリングもまた、特定の設定された無線リソースプールから、スケジューリング割当ての送信のための無線リソースを選択するときに実行される。最初に無線リソースプールを設定するときの対応するインジケーションは、例えば、データのために１ビット、および、ＳＡ送信のために１ビットのように、十分であり得る。

以下に記述されるように、第２の実施形態は、スケジューリング割当てを受信するデバイスが、受信されたスケジューリング割当てが１つまたは複数の将来のスケジューリング割当ての送信のための無線リソースも予約するか否かをどのように推定するかに関するいくつかの実施を提供する。１つのオプションは、スケジューリング割当てにおいて、対応するフィールド（例えば、１ビット）を提供することであり、１ビット値は、スケジューリング割当てが、１つまたは複数の将来のスケジューリング割当ての送信のための無線リソース（例えば、現在のスケジューリング割当ての送信のために使用されるこれら無線リソース）を予約することを示す。反対に、スケジューリング割当てフィールドの他のビット値は、スケジューリング割当て送信のために無線リソース予約が行われていないことを示すものとして、受信エンティティによって理解される。あるいは、スケジューリング割当てのための無線リソースの予約のために、別個のフィールドを提供する代わりに、第２の実施形態の他の実装は、例えば、無線リソース予約が、データ送信のために実行されるか否かを示すために、スケジューリング割当ての、対応するフィールドを使用するような、暗黙的なインジケーション（implicit indication）に基づいている。したがって、スケジューリング割当ては、データリソースが予約されている限り、対応するスケジューリング割当てリソースも予約されるものであることを示す。例えば、スケジューリング割当ては、恐らくは、無線リソース予約の周期性、予約のインスタンス数等を示す「周期性」フィールドを含み得る。（ＳＡ送信と同様にデータ送信のための）無線予約しないことは、例えば、この周期性フィールドに値０を含めることによって、示される。

第２の実施形態の上記の実施では、スケジューリング割当てのために実行されるべき再送信は、まだ考慮されていなかった。それにも関わらず、スケジューリング割当て送信のロバスト性を高めるために、スケジューリング割当ての１つまたは複数の再送信は、サイドリンクインタフェースを介して車両ＵＥによって実行されるべきである。前記関連では、１つの例示的な実施において、固定数の（再）送信が、事前設定され得る。従来技術におけるように、車両ＵＥは、スケジューリング割当ての最初の送信に関して、固定された時間関係でスケジューリング割当ての再送信を送信し得る。あるいは、スケジューリング割当ての最初の送信と再送信との間の別の関連付けは、車両ＵＥと、可能な受信エンティティとの間で合意され得る。さらに別の解決策によれば、車両ＵＥはまた、最初の送信に関して行われるように、スケジューリング割当ての再送信のための無線リソースをランダムに選択し得る。例えば、スケジューリング割当ての送信のために利用可能な無線リソースはさらに、最初の送信のためのリソースと、スケジューリング割当てのさらなる再送信のためのリソースとに分割され得る。

しかしながら、割当ての再送信のために無線リソースもランダムに選択することは、問題があり得る。特に、スケジューリング割当ては、無線リソースのセット内の特定の無線リソースを使用して送信され、潜在的な受信エンティティは、（無線リソースサーチ空間とも呼ばれる）無線リソースセット内のブラインド復号によってスケジューリング割当てを検出する。従来技術の手順では、スケジューリング割当ての再送信は、（例えば、スケジューリング割当てを正常に復号するソフトコンバイニング（soft combining）を適切に実行するために、）受信エンティティが１つの特定のスケジューリング割当てのどの（再）送信が共に属しているのかを知ることができるように、スケジューリング割当ての最初の送信に関して固定時間関係で実行される。しかしながら、スケジューリング割当ての再送信に対してもランダムなリソース選択を実施することによって、そのような固定された時間関係はもはや保証され得ない。

したがって、受信エンティティが、１つの特定のスケジューリング割当てについてすべての送信および再送信を関連付けることを可能にする新たなメカニズムを提供することが必要である。第２の実施形態の１つの例示的な実施によれば、それらを共に関連付けるために、共通の識別子が、スケジューリング割当て送信に含まれ得る。これに対応して、１つの特定のスケジューリング割当てについて様々な送信を受信する受信デバイスは、その後、共通の識別子に基づいて、スケジューリング割当ての正しい送信を関連付け得る。一例によれば、共通の識別子は、送信のソースとしての車両ＵＥ、および／または、スケジューリング割当てが送信されるデータを生成する現在のアプリケーションの両方を識別するソース識別子であり得る。共通の識別子は、スケジューリング割当ての一部であり得るか、または、レイヤ１識別子またはＣＲＣチェックの一部へ符号化され得る。

第２の実施形態のさらなる実施は、（例えば、上記で論じられたスケジューリング割当ての最初の送信と同じ方式で）センシング手順の結果に、リソース選択を基づけることによって、スケジューリング割当ての再送信のための無線リソースの選択を改良する。ＳＡ送信のための無線リソースの上記のランダム選択について既に論じられたように、センシング結果に基づいて無線リソースの選択を改良するとき、最初の送信と再送信との間の固定された時間関係は、もはや保証され得ない。それゆえ、受信エンティティが、１つの特定のスケジューリング割当てについてすべての送信および再送信を関連付けることを可能にする新たなメカニズムを提供することが必要である。第２の実施形態の１つの例示的な実施によれば、上記で既に説明したような共通の識別子が、それらを共に関連付けるために、スケジューリング割当て送信に含まれ得る。一例によれば、共通の識別子は、送信のソースとしての車両ＵＥと、および／または、スケジューリング割当てが送信されるデータを生成する現在のアプリケーションとの両方を識別するソース識別子であり得る。共通の識別子は、スケジューリング割当ての一部であり得るか、または、レイヤ１識別子の一部へ符号化され得る。

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

様々な実施形態は、コンピューティングデバイス（プロセッサ）を使用して実施または実行され得るものとさらに認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Array）、または、その他プログラマブルロジックデバイスなどである。様々な実施形態は、これらのデバイスの組み合わせによっても実行または具体化され得る。特に、上述した各実施形態の説明に用いた各機能ブロックは、集積回路であるＬＳＩによって実施できる。これらの機能ブロックは、個々のチップから構成されてもよいし、機能ブロックの一部またはすべてを含むように１つのチップから構成されてもよい。これらのチップは、自身に結合されているデータの入力と出力を含むことができる。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、またはウルトラＬＳＩと呼称される。しかしながら、集積回路を実施する技術は、ＬＳＩに限るものではなく、専用回路または汎用プロセッサを使用することによって達成できる。さらには、ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ、またはＬＳＩ内部の回路セルの接続または設定を再設定可能なリコンフィギャラブル・プロセッサを利用してもよい。

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

具体的な実施形態に示した本開示には、広義に記載されている本発明の概念または範囲から逸脱することなく、様々な変更および／または修正を行うことができることが、当業者には理解されるであろう。したがって、本明細書に示した実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものとみなされる。

Claims (8)

1. サイドリンクインタフェースを介した、１つまたは複数の受信装置へのデータ送信のために使用されるべき無線リソースを決定するための送信装置の処理を制御する集積回路であって、前記処理は、
   前記送信装置が、リソースセンシング手順を実行し、後の時点においてデータを送信するために使用可能な無線リソースに関する情報を獲得し、
   データが送信のために利用可能になった後、前記データが送信のために利用可能になる前に、センシングウィンドウ中、前記リソースセンシング手順によって獲得された前記情報に基づいて、自律的な無線リソース割当てを実行し、前記データを送信するために使用されるべき送信ウィンドウ内の無線リソースを選択し、
   前記自律的な無線リソース割当ては、前記送信ウィンドウのセカンダリサブフレーム内の無線リソースよりも、前記送信ウィンドウのプライマリサブフレーム内の無線リソースを選択し、
   前記送信ウィンドウ内の前記セカンダリサブフレームは、前記センシングウィンドウの期間に前記送信装置が前記リソースセンシング手順を実行しなかった前記センシングウィンドウ内のサブフレームに対応し、前記送信ウィンドウ内の前記プライマリサブフレームは、前記センシングウィンドウの期間に前記送信装置が前記リソースセンシング手順を実行した前記センシングウィンドウ内のサブフレームに対応し、前記セカンダリサブフレームは、他の送信装置によってなされ得る前記無線リソースの予約の最小の周期に基づいて決定される、
   集積回路。
2. 前記リソースセンシング手順は、
   ・他の送信装置によって予約された無線リソースを判定するために、後の時点のために、前記他の送信装置によって予約された無線リソースを示す、他の送信装置によって送信されたスケジューリング情報を監視することと、
   ・送信のために他の送信装置によって使用された無線リソースを識別するために、無線リソース内の受信信号エネルギを測定することとを備える、
   請求項１に記載の集積回路。
3. 前記自律的な無線リソース割当てはさらに、前記プライマリサブフレーム内の１つまたは複数のプライマリ送信無線リソース候補を決定することと、前記セカンダリサブフレーム内の１つまたは複数のセカンダリ送信無線リソース候補を決定することとを備え、
   複数のプライマリ送信無線リソース候補がある場合、前記プライマリ送信無線リソース候補の候補順位付けを実行し、複数のセカンダリ送信無線リソース候補がある場合、前記セカンダリ送信無線リソース候補の候補順位付けを実行し、前記１つまたは複数のプライマリ送信無線リソース候補の前記候補順位付けは、前記１つまたは複数のセカンダリ送信無線リソース候補の順位付けと別個であり、
   前記候補順位付けは、前記データが送信のために利用可能になった時点からの前記無線リソース候補の時間距離、ならびに、順位付けされるべき前記無線リソースについて前記リソースセンシング手順によって取得された受信信号エネルギの予測値を考慮し、
   順位付けされるべき前記無線リソースの前記受信信号エネルギの予測値は、前記センシングウィンドウのすべてのサブフレーム内の対応する無線リソースの前記受信信号エネルギの測定値に基づく、または、無線リソースが順位付けされるべき前記サブフレームに関連する前記センシングウィンドウのサブフレーム内の対応する無線リソースの前記受信信号エネルギの測定値に基づき、前記関連するサブフレームは、他の送信装置による多数の可能な送信周期の順位付けされるべき前記無線リソースからの時間距離を有する前記センシングウィンドウのサブフレームであり、
   前記候補順位付けはまず、前記時間距離を、次に前記受信信号エネルギを考慮するか、または、前記候補順位付けはまず、前記受信信号エネルギを、次に前記時間距離を考慮するか、または、前記候補順位付けは、前記時間距離と前記受信信号エネルギとの関数に基づく、
   請求項１〜２のいずれか一項に記載の集積回路。
4. 前記送信装置は、サブフレーム内のデータ送信のためにデータ送信またはスケジューリング割当て送信を実行するとき、そのサブフレーム内で前記リソースセンシング手順を実行しない、
   請求項１〜３のいずれか一項に記載の集積回路。
5. 前記データの送信のために使用されるべき無線リソースを選択することができない場合、送信のために利用可能な前記データの優先順位が、プリエンプション優先順位しきい値を下回る場合、前記データを破棄するように決定し、前記データが破棄されない場合、リソースプリエンプション手順を実行し、前記他の送信装置のうちの１つまたは複数によって予約された前記無線リソースの中から、前記データの送信のために使用されるべき無線リソースを選択し、
   前記リソースプリエンプション手順を実行するときに、前記データの送信のために使用されるべき前記無線リソースを、前記予約された無線リソースの優先順位、および／または、送信されるべき前記データの前記優先順位、および／または、前記センシングウィンドウ内の対応するサブフレームの無線リソース内の前記リソースセンシング手順によって測定された受信信号エネルギに基づいて選択し、前記リソースプリエンプション手順における前記無線リソースの選択は、まず前記優先順位を、次に前記予約された無線リソースの前記受信信号エネルギを考慮するか、または、まず前記受信信号エネルギを、次に前記予約された無線リソースの前記優先順位を考慮するか、または、前記予約された無線リソースの前記優先順位と前記受信信号エネルギとの関数に基づくか、のいずれかである、
   請求項１〜４のいずれか一項に記載の集積回路。
6. 前記処理は、前記サイドリンクインタフェースの輻輳レベルを示す前記サイドリンクインタフェースのチャネルビジー率を決定し、送信のために利用可能になったデータが破棄されるべきか否かを決定するために、前記サイドリンクインタフェースの、前記決定されたチャネルビジー率に基づいて、前記自律的な無線リソース割当てを実行する前に、データ破棄手順を実行し、前記データを破棄しないと決定した場合、前記自律的な無線リソース割当てを実行し、
   前記データ破棄手順中、送信のために利用可能になった前記データの優先順位が、チャネル優先順位しきい値よりも低いと決定したときに、前記データを破棄し、前記チャネル優先順位しきい値は、前記サイドリンクインタフェースの、前記決定されたチャネルビジー率に依存し、
   前記送信装置は、前記データ破棄手順を実行するまたは実行しないように前記送信装置を制御する無線基地局によって設定され、前記データ破棄手順の前記設定は、データを送信するための無線リソースを選択するために前記送信装置によって使用可能な複数のリソースプールのおのおのについて別個であり、
   前記チャネル優先順位しきい値はさらに、送信のために利用可能になった前記データのタイプに依存し、安全データ関連チャネル優先順位しきい値は、非安全データ関連チャネル優先順位しきい値よりも低い、
   請求項１〜５のいずれか一項に記載の集積回路。
7. 前記自律的な無線リソース割当てが、複数の前記無線リソースから前記他の送信装置によって予約された無線リソースを除外することを備え、および／または、
   サブフレーム内の無線リソース候補は、周波数領域において連続する１つまたは複数のリソースブロックを備える、
   請求項１〜６のいずれか一項に記載の集積回路。
8. 前記自律的な無線リソース割当てのために考慮された前記センシングウィンドウは、前記データが送信のために利用可能になる前の、あらかじめ決定された時点を開始し、前記データが送信のために利用可能になった時点で終了する、周波数時間無線リソースを備え、
   前記送信ウィンドウは、前記データが送信のために利用可能になったサブフレームの直後である開始サブフレームで始まり、前記開始サブフレームからあらかじめ決定された時間距離離れたサブフレームで終了する周波数時間無線リソースを備え、前記時間距離は、前記送信装置によって満たされるべき送信のために利用可能になったデータの遅延要件に依存する、
   請求項１〜７のいずれか一項に記載の集積回路。
   

Images