JP2019530268A - Ｖ２ｘ送信用データの改良された初期および再送信 - Google Patents

Abstract

本発明は、サイドリンクインターフェースを介してデータの最初の送信および１回または複数回の再送信を実行する送信装置に関する。受信部およびプロセッサは、リソースセンシング手順を実行して、装置が後の時点でデータを送信するのに使用可能な無線リソースに関する情報を取得する。プロセッサは、リソースセンシング手順により取得された情報に基づいて、自律的な無線リソース割当てを実行することにより、データの最初の送信の実行に用いられる送信ウィンドウ内で時間−周波数無線リソースを選択する。プロセッサは、データの１回または複数回の送信を実行する送信タイミングを示すデータ送信タイミングパターンを決定する。送信部は、選択された時間−周波数無線リソースを用いて最初のデータ送信を実行するとともに、最初のデータ送信に関して決定されたデータ送信タイミングパターンにより規定された送信タイミングでデータ再送信を実行する。

Description

本開示は、サイドリンクインターフェースを介した改良されたデータ送信およびリソース割当てに関する。本開示は、本発明の対応する方法および装置を提供している。

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

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

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

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

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

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

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

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

１つのサブフレームは、２つのスロットから成る。いわゆる「通常の（ｎｏｒｍａｌ）」ＣＰ（サイクリックプレフィックス）が使用されるときにはサブフレーム内に１４個のＯＦＤＭシンボルが存在し、いわゆる「拡張（ｅｘｔｅｎｄｅｄ）」ＣＰが使用されるときにはサブフレーム内に１２個のＯＦＤＭシンボルが存在する。専門用語を目的として、以下では、サブフレーム全体に広がる同じ連続サブキャリアと同等の時間−周波数リソースを「リソースブロックペア（ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ ｐａｉｒ）」または同等の「ＲＢペア（ＲＢ ｐａｉｒ）」もしくは「ＰＲＢペア（ＰＲＢ ｐａｉｒ）」と称する。

用語「コンポーネントキャリア（Ｃｏｍｐｏｎｅｎｔ Ｃａｒｒｉｅｒ）」は、周波数領域におけるいくつかのリソースブロックの組み合わせを表す。ＬＴＥの今後のリリースにおいて、用語「コンポーネントキャリア」はもはや使用されず、代わりに、その専門用語がダウンリンクリソースおよび任意選択でアップリンクリソースの組み合わせを表す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指示される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

無線リンク制御（ＲＬＣ：Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）サブレイヤは、主としてＡＲＱ機能を有しており、また、データの分割および連結をサポートしている。すなわち、ＲＬＣレイヤは、ＲＬＣ ＳＤＵのフレーミングを実行し、ＭＡＣレイヤによって示されるサイズにする。後者の２つによって、データレートとは無関係にプロトコルオーバーヘッドが最小となる。ＲＬＣレイヤは、論理チャネルを介してＭＡＣレイヤに接続されている。各論理チャネルは、様々なタイプのトラフィックを伝える。ＲＬＣレイヤの上のレイヤは通常、ＰＤＣＰレイヤであるが、場合によってはＲＲＣレイヤである。すなわち、論理チャネルＢＣＣＨ（Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＰＣＣＨ（Ｐａｇｉｎｇ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、およびＣＣＣＨ（Ｃｏｍｍｏｎ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）で送信されるＲＲＣメッセージは、セキュリティ保護を必要としないため、ＰＤＣＰレイヤをバイパスしてＲＬＣレイヤに直接渡される。

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

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

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

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

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

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

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

［セミパーシステントスケジューリング（ＳＰＳ：Ｓｅｍｉ−Ｐｅｒｓｉｓｔｅｎｔ Ｓｃｈｅｄｕｌｉｎｇ）］
ダウンリンクおよびアップリンクにおいて、スケジューリングｅＮｏｄｅＢは、Ｌ１／Ｌ２制御チャネル（ＰＤＣＣＨ）を介して、各送信時間間隔でリソースをユーザ機器に割り当てるが、この場合、ユーザ機器は、それぞれの特定のＣ−ＲＮＴＩを介してアドレス指定される。前述の通り、ＰＤＣＣＨのＣＲＣは、アドレス指定されたユーザ機器のＣ−ＲＮＴＩ（いわゆる動的なＰＤＣＣＨ）でマスキングされる。Ｃ−ＲＮＴＩが整合するユーザ機器のみがＰＤＣＣＨの内容を正しく復号化可能である。すなわち、ＣＲＣチェックが肯定される。この種のＰＤＣＣＨシグナリングは、動的な（スケジューリング）グラントとも称する。ユーザ機器は、動的なグラントについて、各送信時間間隔でＬ１／Ｌ２制御チャネルを監視することにより、割り当てられる可能な割当て（ダウンリンクおよびアップリンク）を見つける。

また、Ｅ−ＵＴＲＡＮは、最初のＨＡＲＱ送信に関してパーシステントに、アップリンク／ダウンリンクリソースを割り当てることができる。必要な場合は、Ｌ１／Ｌ２制御チャネルを介して、再送信が明示的に伝えられる。再送信が動的にスケジューリングされることから、この種の動作は、セミパーシステントスケジューリング（ＳＰＳ）と称する。すなわち、リソースは、セミパーシステントに基づいて、ユーザ機器に割り当てられる（セミパーシステントリソース割当て）。その利点として、最初のＨＡＲＱ送信のＰＤＣＣＨリソースが節約される。リリース１０では、セミパーシステントスケジューリングがＰＣｅｌｌにおいて用いられる一方、ＳＣｅｌｌでは用いられない場合もある。

セミパーシステントスケジューリングによってスケジューリング可能なサービスの一例として、ボイスオーバ−ＩＰ（ＶｏＩＰ）がある。トークスパート（ｔａｌｋ−ｓｐｕｒｔ）においては、２０ｍｓごとにｃｏｄｅｃでＶｏＩＰパケットが生成される。したがって、ｅＮｏｄｅＢは、２０ｍｓごとにアップリンクリソースまたは各ダウンリンクリソースをパーシステントに割り当てることも可能であり、その後、ボイスオーバ−ＩＰパケットの送信に使用することも可能である。一般的に、セミパーシステントスケジューリングは、トラフィック挙動が予測可能すなわちビットレートが一定で、パケット到着時間が周期的なサービスに有益である。

また、ユーザ機器は、最初の送信についてパーシステントにリソースが割り当てられたサブフレームにおけるＰＤＣＣＨを監視する。動的な（スケジューリング）グラントすなわちＣＲＣがＣ−ＲＮＴＩでマスキングされたＰＤＣＣＨは、セミパーシステントなリソース割当てに優先し得る。ユーザ機器がセミパーシステントなリソースを割り当てられたサブフレームにおいてＬ１／Ｌ２制御チャネル上でそのＣ−ＲＮＴＩを見つけた場合、このＬ１／Ｌ２制御チャネル割当ては、送信時間間隔においてパーシステントなリソース割当てに優先するため、ユーザ機器は動的なグラントに追従する。ユーザ機器は、動的なグラントを見つけてない場合、セミパーシステントなリソース割当てに従って送信／受信を行うことになる。

セミパーシステントスケジューリングの設定は、ＲＲＣシグナリングによって行われる。たとえば、パーシステントな割当ての周期性（たとえば、ＰＳ＿ＰＥＲＩＯＤ）は、無線リソース制御（ＲＲＣ）シグナリング内で伝えられる。パーシステントな割当てのアクティブ化および正確なタイミングのほか、物理リソースおよびトランスポートフォーマットパラメータについては、ＰＤＣＣＨシグナリングによって送信される。セミパーシステントスケジューリングがアクティブ化されると、ユーザ機器は、ＰＳ＿ＰＥＲＩＯＤごとに、ＳＰＳアクティブ化ＰＳＣＣＨに従って、セミパーシステントなリソース割当てに追従する。本質的に、ユーザ機器は、ＳＰＳアクティブ化ＰＤＣＣＨの内容を格納して、周期性が伝えられたＰＤＣＣＨに追従する。

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

ユーザ機器は、セミパーシステントなリソース割当てが対応するＳＰＳアクティブ化ＰＤＣＣＨによりアクティブ化されたことを検出した場合、ＰＤＣＣＨの内容を格納して（すなわち、セミパーシステントなリソース割当て）、セミパーシステントスケジューリングの間隔（すなわち、ＲＲＣを介して伝えられた周期性）ごとに適用することになる。前述の通り、動的な割当て（すなわち、動的なＰＤＣＣＨ上でのシグナリング）は、「１回の割当て」でしかない。ＳＰＳ割当ての再送信についても、ＳＰＳ Ｃ−ＲＮＴＩを用いて伝えられる。ＳＰＳアクティブ化をＳＰＳ再送信から識別するため、ＮＤＩ（新規データインジケータ）ビットが用いられる。ＳＰＳアクティブ化は、ＮＤＩビットを０に設定することにより指定される。ＮＤＩビットが１に設定されたＳＰＳ ＰＤＣＣＨは、セミパーシステントにスケジューリングされた最初の送信の再送信を示す。

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

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

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

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

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

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

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

Ｄ２Ｄ通信では、特定の１つのＵＥ１が送信の役割を担う場合（送信ユーザ機器または送信端末）、ＵＥ１がデータを送信し、別のＵＥ２（受信ユーザ機器）がそれを受信する。ＵＥ１およびＵＥ２は、それぞれの送信および受信の役割を変更可能である。ＵＥ１からの送信は、１つまたは複数のＵＥ（ＵＥ２等）によって受信可能である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図６は、ＳＣ期間（サイドリンク制御期間）としても知られる１つのＳＡ／データ期間中のモード２（自律的スケジューリング）の場合のＤ２Ｄ通信タイミングの具体的な一例を示している。図７は、１つのＳＡ／データ期間中のモード１（ｅＮＢによる割当てスケジューリング）の場合のＤ２Ｄ通信タイミングを示している。Ｒｅｌ．１３において、３ＧＰＰは、スケジューリング割当ておよびその対応するデータの送信から成る時間周期としてＳＣ期間を規定している。図６から分かるように、ＵＥは、ＳＡオフセット時間の後、モード２におけるスケジューリング割当て用の送信プールリソース（ＳＡ＿Ｍｏｄｅ２＿Ｔｘ＿ｐｏｏｌ）を使用して、スケジューリング割当てを送信する。ＳＡの最初の送信の後、たとえば同じＳＡメッセージを３回再送信する。その後、ＵＥは、（ＳＡ＿ｏｆｆｓｅｔにより与えられる）ＳＡリソースプールの最初のサブフレームから、一部の設定オフセット（Ｍｏｄｅ２ｄａｔａ＿ｏｆｆｓｅｔ）の後、Ｄ２Ｄデータ送信（すなわち、より詳細にはＴ−ＲＰＴビットマップ／パターン）を開始する。ＭＡＣ ＰＤＵ（すなわち、トランスポートブロック）の１回のＤ２Ｄデータ送信は、その１回目の最初の送信および複数回の再送信から成る。図６（および図７）の図示においては、３回の再送信（すなわち、同じＭＡＣ ＰＤＵの２回目、３回目、および４回目の送信）が実行されるものと仮定している。モード２のＴ−ＲＰＴビットマップ（送信の時間リソースパターン（Ｔ−ＲＰＴ））は基本的に、ＭＡＣ ＰＤＵの送信（最初の送信）およびその再送信（２回目、３回目、および４回目の送信）のタイミングを規定する。ＳＡパターンは基本的に、ＳＡの最初の送信およびその再送信（２回目、３回目、および４回目の送信）のタイミングを規定する。Ｔ−ＲＰＴに関する詳細な情報については、非特許文献３の特に第１４項「UE procedures related to the Sidelink」を参照可能であり、参照により本明細書に組み込まれている。

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

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

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

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

たとえば、現在開発中の３ＧＰＰ Ｒｅｌ．１４の場合、３ＧＰＰは、上述のようにＳＣ周期に基づくことなく、異なる（たとえば、Ｕｕインターフェース送信と同一／同様のサブフレームに基づく）ように、送信タイミングを変更することを決定するようにしてもよい。これに対応して、サイドリンク（ＰＣ５）インターフェース上での送信を実行可能とする方法に関して上記詳述した例は、ほんの一例に過ぎず、Ｒｅｌ．１３に当てはまり得るものの、場合によっては、対応する３ＧＰＰ規格の以降のリリースには当てはまらない。

さらに、Ｄ２Ｄフレームワークの今後のリリースにおいては、特に車両通信に関して、固定Ｔ−ＲＰＴに基づく送信が使われなくなる可能性もある。

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

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

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

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

［車両通信−Ｖ２Ｘサービス］
３ＧＰＰのＲｅｌ．１４においては、近接サービス（ＰｒｏＳｅ）およびＬＴＥベースのブロードキャストサービスを含めて、自動車産業に対するＬＴＥの新たな特徴の有用性を考察するため、新しい研究項目が立ち上げられている。このため、上に説明したＰｒｏＳｅ機能は、Ｖ２Ｘサービスの良好な基礎になるものと考えられる。車両通信の送信を強化可能な方法に関して、Ｄ２Ｄフレームワークへの変更を論じる。たとえば、Ｔ−ＲＰＴパターンは、もはや使用されない可能性もある。さらに、データおよびＳＡの送信に関して、前述の通りＴＤＤを使用することの代替または追加として、周波数分割多重が予想され得る。ＩＴＳ（高度道路交通システム）研究分野内の将来的なコネクテッドカーについては、車両シナリオにおける協調サービスが本質的となりつつある。これらは、交通死亡事故を減らし、道路の容量を向上させ、道路輸送の二酸化炭素排出量を低減し、走行中のユーザ体験を強化すると考えられる。

Ｖ２Ｘ通信は、車両から、車両に影響を及ぼし得る任意のエンティティへの情報の移動であり、その逆も同様である。この情報交換は、運転者支援車両安全、速度適応および警告、緊急応答、走行情報、ナビゲーション、交通運行、商用隊列計画、および支払い取引を含むように安全、モビリティ、および環境用途を改善するのに使用可能である。

Ｖ２Ｘサービスに対するＬＴＥサポートには、以下のような３種類の異なる使用事例を含む。
・ Ｖ２Ｖ：車両間のＬＴＥベースの通信を網羅する。
・ Ｖ２Ｐ：車両と個人が携行するデバイス（たとえば、歩行者、自転車運転者、運転者、または乗員が携行する手持ち端末）との間のＬＴＥベースの通信を網羅する。
・ Ｖ２Ｉ：車両と路側ユニットとの間のＬＴＥベースの通信を網羅する。

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

Ｖ２Ｖ通信に関して、Ｅ−ＵＴＲＡＮによれば、互いに近接するこのような（車両）ＵＥは、許可、認可、および近接性基準が満たされている場合に、Ｅ−ＵＴＲＡ（Ｎ）を用いてＶ２Ｖ関連の情報を交換することができる。近接性基準は、ＭＮＯ（モバイルネットワーク事業者）により設定可能である。ただし、Ｖ２ＶサービスをサポートするＵＥは、Ｖ２ＸサービスをサポートするＥ−ＵＴＲＡＮにより提供される場合にも提供されない場合にも、このような情報を交換することができる。

Ｖ２Ｖアプリケーションをサポートするデバイス（車両ＵＥ）は、（たとえば、Ｖ２Ｖサービスの一部としての位置、運動、および属性に関する）アプリケーションレイヤ情報を送信する。Ｖ２Ｖペイロードは、様々な情報コンテンツに対応するため、柔軟性が必要であり、この情報は、ＭＮＯが提供する設定に従って周期的に送信可能である。

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

Ｖ２Ｉ通信に関して、Ｖ２Ｉアプリケーションをサポートするデバイスは、アプリケーションレイヤ情報を路側ユニットに送信し、これを受けて路側ユニットは、アプリケーションレイヤ情報をデバイス群またはＶ２Ｉアプリケーションをサポートするデバイスに送信することができる。

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

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

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

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

この新しい研究項目Ｖ２Ｘに関して、３ＧＰＰは、非特許文献８において特定の用語および定義を提供しており、本願に再利用可能である。
路側ユニット（ＲＳＵ）：Ｖ２Ｉアプリケーションを用いてＵＥとの送受信が可能なＶ２Ｉサービスをサポートするエンティティ。ＲＳＵは、ｅＮＢまたは固定ＵＥにおいて実装可能である。
Ｖ２Ｉサービス：一方の参加者がＵＥであり、他方の参加者がＲＳＵであり、両者がＶ２Ｉアプリケーションを使用するＶ２Ｘサービスの一種
Ｖ２Ｎサービス：一方の参加者がＵＥであり、他方の参加者がサービングエンティティであり、両者がＶ２Ｎアプリケーションを使用するとともにＬＴＥネットワークエンティティを介して互いに通信するＶ２Ｘサービスの一種
Ｖ２Ｐサービス：通信の両参加者がＵＥであり、Ｖ２Ｐアプリケーションを使用するＶ２Ｘサービスの一種
Ｖ２Ｖサービス：通信の両参加者がＵＥであり、Ｖ２Ｖアプリケーションを使用するＶ２Ｘサービスの一種
Ｖ２Ｘサービス：３ＧＰＰトランスポートを介してＶ２Ｖアプリケーションを使用する送信または受信ＵＥを含む通信サービスの一種。通信に含まれる他方の参加者に基づいて、Ｖ２Ｖサービス、Ｖ２Ｉサービス、Ｖ２Ｐサービス、およびＶ２Ｎサービスへとさらに分割可能である。

多くのＩＴＳサービスでは、通信要件が共通する。
・ 周期的ステータス交換。ＩＴＳサービスでは通常、車両または路側端末のステータスを把握しておく必要がある。これは、位置、速度、識別子等に関する情報を伴うデータパケットの周期的な交換を暗示する。
・ 非同期通知。この種のメッセージは、特定のサービスイベントに関する通知に用いられる。上記ステータスメッセージとは対照的に、これらメッセージの単一端末または端末群への確実な伝達が通例は重要な要件である。

最初の通信タイプの使用例は、車両から周期的なステータスデータを集める遠隔車両監視等の交通効率化サービスまたは潜在的な衝突を検出するために周囲の車両に関する運動学的情報を必要とする協調衝突回避等の安全サービスに見られる。非同期通知は主として、滑りやすい舗装または衝突後警報等の安全サービスに見られる。

Ｖ２Ｖ通信については、様々な種類のメッセージが規定されており、また、今後も規定される。高度道路交通システム（ＩＴＳ）に対してＥＴＳＩにより、以下のような２種類の異なるメッセージがすでに規定されている（対応する欧州規格である非特許文献９および非特許文献１０を参照）。
・ 車両ステータスを反映するように車両運動によって継続的にトリガーされる協調認識メッセージ（ＣＡＭ：Ｃｏｏｐｅｒａｔｉｖｅ Ａｗａｒｅｎｅｓｓ Ｍｅｓｓａｇｅ）
・ 車両関連の安全イベントが発生した場合にのみトリガーされる分散環境通知メッセージ（ＤＥＮＭ：Ｄｅｃｅｎｔｒａｌｉｚｅｄ Ｅｎｖｉｒｏｎｍｅｎｔａｌ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｍｅｓｓａｇｅ）

Ｖ２ＶおよびＩＴＳの標準化は、緒に就いたばかりであるため、将来的には他のメッセージが規定される可能性もあると考えられる。

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

協調認識メッセージ（ＣＡＭ）は、ＩＴＳネットワークにおいてＩＴＳ−Ｓ間で交換されることにより、互いの認識を生成・維持するとともに、道路ネットワークを用いて車両の協調性能をサポートするメッセージである。ＣＡＭの送信には、送信元のＩＴＳ−Ｓから、送信元ＩＴＳ−Ｓの直接通信範囲に位置付けられた受信側ＩＴＳ−ＳへとＣＡＭが送信されるように、１対多点通信が用いられるものとする。ＣＡＭの生成は、２つの連続するＣＡＭ生成間の時間間隔を規定する協調認識基本サービスによってトリガーされ、管理されるものとする。現在のところ、送信間隔の上限および下限は、１００ｍｓ（すなわち、１０ＨｚのＣＡＭ生成レート）および１０００ｍｓ（すなわち、１ＨｚのＣＡＭ生成レート）である。ＥＴＳＩ ＩＴＳの根底にある原理は、共有すべき新たな情報（たとえば、新しい位置、新しい加速度、または新しい方位の値）が存在する場合にＣＡＭを送信することである。これに対応して、車両がゆっくりと一定の方位および速度で移動している場合は、ＣＡＭが最小限の差異しか示さないため、高いＣＡＭ生成レートでは現実的な利益がもたらされない。１つの車両のＣＡＭの送信頻度は、車両運動（たとえば、速度、加速度、および方位）の関数として、１Ｈｚ〜１０Ｈｚで変動する。たとえば、車両が遅くなると、トリガーされて送信されるＣＡＭの数も少なくなる。ＣＡＭトラフィック生成の主要な影響因子は、車両速度である。

上記においては、周期的な協調認識メッセージを説明した。ただし、上記情報の一部がすでに標準化されているとはいえ、周期性およびメッセージサイズ等の他の情報については、未だ標準化されておらず、仮定に基づいていることに留意されたい。さらに、この標準化は、将来的に変更となる可能性もあるため、ＣＡＭの生成・送信方法に関する態様も変更となる可能性がある。

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

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

また、Ｖ２Ｘサイドリンクの自律的なリソース制御／選択メカニズムの支援のため、セミパーシステントな送信と併せて、センシングメカニズムをサポートすることも合意されている。ＵＥは、リソース選択が発生するまで、選択された一組の周期的発生リソース上にデータを有することをＰＳＣＣＨ（ＳＡ／ＳＣＩ）において示すことになる。このリソース予約情報（ＳＣＩにおいて伝えられる）は、他のＵＥによりすでに予約／予定されたリソースが無線リソース選択において考慮されないように、リソースの選択に向けてＶ２Ｘメッセージの送信を意図する他のＵＥにより使用可能である。このリソース予約／予定手順は、パケットが特定の周期性で到着するトラフィック（たとえば、ＣＡＭメッセージ）に特に適している。

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

さらに、３ＧＰＰでは、センシング手順のエネルギー測定を実行することにも合意しているが、この合意は、実行するエネルギー測定の方法および対象についての詳細を一切示していない。エネルギーベースのセンシングは、ＰＳＳＣＨ無線リソースおよび／またはＰＳＣＣＨ無線リソース上でＵＥが受信信号強度を測定するプロセスとして理解可能である。エネルギーベースのセンシングは本質的に、遠距離の干渉に対して近距離の干渉を識別するのに役立ち得る。

さらに、リソース割当て手順において使用できるようにデータ（または、対応する無線リソース予約）の優先順位をスケジューリング割当て（ＳＣＩ）において指定するかが議論されたものの、優先順位の効果的な使用方法については、合意に至っていない。

議論中に持ち上がった別の話題として、リソース割当て手順におけるチャネル（すなわち、ＰＣ５インターフェース）の輻輳レベルの使用があるが、これについては、ＥＴＳＩ規格によりすでに把握されているチャネルビジー率（ＣＢＲ：Ｃｈａｎｎｅｌ Ｂｕｓｙ Ｒａｔｅ）に類似する可能性もある（たとえば、非特許文献１１および非特許文献１２を参照）。この場合も、上記の点に関する詳細は議論されておらず、このような輻輳レベルを正しく使用する方法についての合意は言うまでもない。

図６および図７に関して上記説明した通り、送信の信頼性を向上させるため、各トランスポートブロックおよびスケジューリング割当ては、サイドリンクを通じて繰り返し送信される。すなわち、スケジューリング割当てまたはデータの最初の送信が１回または複数回繰り返される。３ＧＰＰにおいて継続中の議論では、データ／ＳＡの最初の送信と繰り返し送信とを識別しておらず、この点において、Ｖ２Ｘ送信のセミパーシステントなスケジューリングおよびリソースセンシングの実現方法が不明瞭なままである。

センシングおよびセミパーシステントなスケジューリングは、ＵＥがあまりにも複雑とならないように、簡単な方法で実現可能であるものとする。ＰＣ５インターフェースを通じたＶ２Ｘ通信のセンシングおよびリソース予約に関しては、大略合意に達しているものの、これらのメカニズムを現行システムに実装するには、問題および非効率性を生じる可能性もある。

3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)", current version 13.1.0 3GPP technical standard TS 36.321, current version 13.2.0 3GPP technical standard 36.213, current version 13.1.1 3GPP TS 36.212, "Multiplexing and channel coding", current version 13.1.0 3GPP TR 23.713, current version 13.0.0 3GPP TS 36.300, current version 13.3.0 3GPP TS 23.303, current version 13.2.0 3GPP TR 21.905, current version 13.0.0 ETSI EN 302 637-2, v 1.3.1 ETSI EN 302 637-3, v 1.2.1 ETSI EN 302 571, v 2.0.0 ETSI EN 102 68, v1.1.1

非限定的かつ例示的な実施形態は、サイドリンクインターフェースを介してデータの最初の送信および再送信を実行する送信デバイスの改良された送信手順を提供する。独立請求項は、非限定的かつ例示的な実施形態を提供する。有利な実施形態は、従属請求項の対象である。

第１の態様によれば、サイドリンクインターフェースを介した他のデバイスへの最初のデータ送信およびデータ再送信を実行する送信デバイスが提供される。将来的な無線リソースに関する情報を取得するようにリソースセンシング手順が送信デバイスにより継続的に実行されるものと仮定する。一例によれば、無線リソースセンシングには、後の時点で無線リソースを予約する他のデバイスにより送信されたスケジューリング割当てを監視することを少なくとも含むが、これは後で、無線リソース選択から除外可能である。また、センシングには、任意選択で無線リソース中の受信信号エネルギーを測定することを含んでいてもよい。将来的には、センシング中に他の情報が同様に収集される可能性もある。

第１の態様によれば、１回のデータ送信（たとえば、最初の送信）は、データが送信に利用可能となる前にセンシングウィンドウにおいて無線センシング手順から取得された情報に基づいて１回のデータ送信の無線リソースを選択するように車両ＵＥがリソース割当て手順を実行する点において、残りの（再）送信よりも「優先」される。その結果、この（最初の）送信に選択された無線リソースは、他のＵＥからの送信と衝突を起こさないため、高い信頼性で送信されるはずである。一方、残りのデータ（再）送信に用いられる無線リソースは、選択の柔軟性が低く、シグナリングオーバヘッドを低減できない。特に、残りのデータ（再）送信に関して、車両ＵＥは、１回または複数回のデータ送信のタイミングを規定する適当なデータ送信タイミングパターン（以下では、Ｔ−ＲＰＴとも称する）を選択するものとし、これが車両ＵＥにより、残りのデータ（再）送信を実行する基準として最初のデータ送信で用いられる。データ送信用に車両ＵＥにより送信されたスケジューリング情報はこれに対応して、最初の送信の時間−周波数リソースのほか、最初の送信およびすべての再送信に車両ＵＥが使用する送信タイミングを受信エンティティが導出するデータ送信タイミングパターンを示す。周波数リソースに関して、車両ＵＥにより実行されるデータ再送信では、最初のデータ送信に用いられたのと同じ周波数を使用するようにしてもよいし、周波数ホッピングパターンに基づいて最初に用いられた周波数から導出された周波数を使用するようにしてもよい。また、後者の変形例において、スケジューリング情報は、データ再送信に用いられる周波数の決定にホッピングが用いられるか否かを示すものとする。

一変形例によれば、選択されたデータ送信タイミングパターンは、データに関して実行されるすべての送信または再送信を識別済みとなる。これに対応して、（再）送信は、データ送信タイミングパターンにより与えられた期間内（たとえば、８ビットのデータ送信タイミングパターンの場合は８サブフレーム内）に完了となる。

第１の態様の別の変形例によれば、選択されたデータ送信タイミングパターンは、１回の送信のみを示すことになり、この１回送信のデータ送信タイミングパターンは、最初のデータ送信後の送信ウィンドウ全体で繰り返されることになる。選択された１回送信のデータ送信タイミングパターンを順次位置決めすることにより、送信を示す繰り返しタイミングパターンの位置で様々なデータ再送信候補が規定される。車両ＵＥでは、様々なデータ再送信候補のうち、実際にデータの再送信に用いられる候補を選択することが必要となる。１回送信Ｔ−ＲＰＴの選択は、車両ＵＥによって、リソースセンシング手順により取得された情報を用いて実行可能であり、その結果のデータ送信候補、特に、後々の実際の使用目的で選択されたデータ再送信候補は、衝突頻度および干渉の観点から最適である。

データ再送信候補の選択は、送信の信頼性を向上させるとともに他のＵＥの送信との衝突を回避するため、ランダムに実行されるようになっていてもよいし、上記の点に関するセンシング手順の結果に基づいていてもよい。そして、たとえばデータ送信用に車両ＵＥが送信するスケジューリング情報の一部として、車両ＵＥが実際に使用するデータ再送信候補を受信エンティティに示すことが必要となる。周波数リソースに関して、選択されたデータ再送信候補に従って実行されるデータ再送信では、最初のデータ送信用に車両ＵＥがすでに採用している周波数を使用することも可能であるし、最初のデータ送信に用いられた周波数から始まる周波数ホッピングパターンに従うことも可能である。

第１の態様の別の変形例によれば、１回送信のＴ−ＲＰＴの選択は、以下のようにリソースセンシング手順のセンシング結果に基づく。車両ＵＥは最初に、（最初のデータ送信後の）送信ウィンドウ全体で好適なデータ再送信候補（たとえば、２番目に高いランクの考え得るデータ再送信候補）を決定した後、これを用いて、送信ウィンドウ全体で繰り返された場合に好適なデータ再送信候補と一致する「１」を有する１回送信のＴ−ＲＰＴを決定する。その結果、最初の送信および１回のデータ再送信（すなわち、好適なデータ送信候補）の周波数および時間領域リソースは、センシング結果に基づいて車両ＵＥにより自由に決定されるため、データ送信の信頼性が向上するとともに、衝突頻度が低下する。この変形例の場合、スケジューリング情報は、最初の送信の時間−周波数無線リソースを示すのみならず、この好適なデータ再送信の周波数リソースも別個に示すものとする。これは、たとえば最初のデータ送信について与えられた周波数指定に関する周波数オフセットを設けることによって実現可能である。前述の通り、Ｔ−ＲＰＴは、スケジューリング割当てにおいて示されているため、最初のデータ送信を基準として用いることにより、すべての再送信の送信タイミングを与えることができる。

別の態様によれば、データ送信用に車両ＵＥが利用可能な無線リソースは一般的に、最初のデータ送信に用いられる無線リソースおよびデータ再送信に用いられる無線リソースに分割されるものとする。無線リソースの分割によって、データの再送信と最初の送信とが衝突せず、最も重要な最初の送信が保護されるようになる。

上記に対応して、一般的な第１の態様において、ここに開示の技術は、サイドリンクインターフェースを介してデータを１つまたは複数の受信デバイスに送信する送信デバイスを特徴とする。データの送信は、データの最初の送信と、最初のデータ送信の後、データの１回または複数回の再送信とを含む。送信デバイスの受信部およびプロセッサは、リソースセンシング手順を実行して、送信デバイスが後の時点でデータを送信するのに使用可能な無線リソースに関する情報を取得する。プロセッサは、データが送信に利用可能となった後、データが送信に利用可能となる前にセンシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて、自律的な無線リソース割当てを実行することにより、データの最初の送信の実行に用いられる送信ウィンドウ内で時間−周波数無線リソースを選択する。プロセッサは、データの１回または複数回の送信を実行する送信タイミングをそれぞれ示す複数のデータ送信タイミングパターンのうちの１つを決定する。送信デバイスの送信部は、選択された時間−周波数無線リソースを用いて最初のデータ送信を実行するとともに、最初のデータ送信に関して決定されたデータ送信タイミングパターンにより規定された送信タイミングで１回または複数回のデータ再送信を実行する。

上記に対応して、一般的な第１の態様において、ここに開示の技術は、サイドリンクインターフェースを介してデータを１つまたは複数の受信デバイスに送信する送信デバイスのための方法を特徴とする。データの送信は、データの最初の送信と、最初のデータ送信の後、データの１回または複数回の再送信とを含む。この方法は、送信デバイスにより実行される以下のステップを含む。リソースセンシング手順を実行して、送信デバイスが後の時点でデータを送信するのに使用可能な無線リソースに関する情報を取得する。データが送信に利用可能となった後、データが送信に利用可能となる前にセンシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて、自律的な無線リソース割当てを実行することにより、データの最初の送信の実行に用いられる送信ウィンドウ内で時間−周波数無線リソースを選択する。送信デバイスは、データの１回または複数回の送信を実行する送信タイミングをそれぞれ示す複数のデータ送信タイミングパターンのうちの１つを決定する。送信デバイスは、選択された時間−周波数無線リソースを用いて最初のデータ送信を実行するとともに、最初のデータ送信に関して決定されたデータ送信タイミングパターンにより規定された送信タイミングで１回または複数回のデータ再送信を実行する。

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

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

以下、添付の図面を参照して、例示的な実施形態をより詳しく説明する。

３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示した図である。 ３ＧＰＰ ＬＴＥ（Ｒｅｌ．８／９）において規定されたサブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドを示した図である。 ＰｒｏＳｅ通信のＰＣ５を通じてレイヤ２リンクを確立する方法を概略的に示した図である。 オーバーレイ（ＬＴＥ）システムおよびアンダーレイ（Ｄ２Ｄ）システムにおける送信／受信リソースの使用を示した図である。 ２つのＵＥのスケジューリング割当ておよびＤ２Ｄデータの送信を示した図である。 ＵＥ自律スケジューリングモード２のＤ２Ｄ通信タイミングを示した図である。 ｅＮＢによるスケジューリングモード１のＤ２Ｄ通信タイミングを示した図である。 非ローミングシナリオのＰｒｏＳｅの例示的なアーキテクチャモデルを示した図である。 データが送信に利用可能となる時間Ｐに送信ウィンドウおよびセンシングウィンドウに分割された車両ＵＥのデータリソースプールの周波数−時間無線リソースを示した図である。 第１の実施形態の例示的な一実装形態に係る、ＵＥ挙動のシーケンス図である。 第１の実施形態の例示的な実装形態に係る、送信ウィンドウの一連のサブフレームならびに最初のデータ送信およびデータ再送信を示した図である。 第１の実施形態の例示的な実装形態に係る、送信ウィンドウの一連のサブフレームならびに最初のデータ送信およびデータ再送信を示した図である。 第１の実施形態の別の例示的な実装形態に係る、送信ウィンドウの一連のサブフレームならびに最初のデータ送信およびデータ再送信を示した図である。 第１の実施形態の別の例示的な実装形態に係る、送信ウィンドウの一連のサブフレームならびに最初のデータ送信およびデータ再送信を示した図である。 第１の実施形態の改良された一実装形態に係る、送信ウィンドウの一連のサブフレームならびに最初のデータ送信およびデータ再送信を示した図である。 第１の実施形態の別の改良された実装形態に係る、送信ウィンドウの一連のサブフレームならびに最初のデータ送信およびデータ再送信を示した図である。

移動局、移動ノード、ユーザ端末、またはユーザ機器は、通信ネットワーク内の物理エンティティである。１つのノードが複数の機能エンティティを有していてもよい。機能エンティティは、所定のセットの機能の実装ならびに／またはノードもしくはネットワークの他の機能エンティティへの提供を行うソフトウェアまたはハードウェアモジュールを表す。ノードは、通信を可能にする通信設備または媒体にノードを接続する１つまたは複数のインターフェースを有していてもよい。同様に、ネットワークエンティティは、他の機能エンティティまたは対応するノードとの通信を可能にする通信設備または媒体に機能エンティティを接続する論理インターフェースを有していてもよい。

一組の請求項および本願において使用する用語「無線リソース」は、時間−周波数無線リソース等の物理的な無線リソースを表すものとして広く理解されるものとする。

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

本願において使用する用語「ＰｒｏＳｅ」またはその非短縮形である「近接サービス」は、背景技術の項で例示的に説明した通り、ＬＴＥシステムにおける近接性に基づくアプリケーションおよびサービスの文脈において適用される。この文脈では、近接サービスの場合のデバイス間通信を表すのに、「Ｄ２Ｄ」等の別の専門用語も使用される。

本願の全体で使用する用語「車両移動端末」は、背景技術の項で説明した新しい３ＧＰＰの研究項目または作業項目Ｖ２Ｘ（車両通信）の文脈で理解されるものとする。これに対応して、車両移動端末は、具体的には車両（たとえば、自動車、商用トラック、バイク等）に設置され、車両通信すなわち安全または運転者支援等を目的とした車両関連情報の他のエンティティ（車両、インフラ、歩行者等）への伝達を実行する移動端末として広く理解されるものとする。任意選択で、車両移動端末は、マップ情報等、（同じく自動車に設置されることを前提とした）ナビゲーションシステムで利用可能な情報にアクセス可能であってもよい。

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

本願の全体で使用する用語「データ送信タイミングパターン」は、送信のタイミングを規定する情報（たとえば３ＧＰＰのＤ２Ｄ技術の文脈で知られているＴ−ＲＰＴ（time resource pattern of transmission（送信の時間リソースパターン））として例示的に理解されていてもよい。実際の導入に応じて、データ送信タイミングパターンは、最初のデータ送信のほか、データの再送信を示すのに用いられるようになっていてもよいし、データの再送信を示す場合にのみ使用され、最初のデータ送信が別個に示されるようになっていてもよい。

背景技術の項で説明した通り、３ＧＰＰは、ＬＴＥ支援車両通信に関する新しい検討項目（study item）を導入しており、これは、様々な車両移動端末と他局との間でＶ２Ｘトラフィックを交換するＰｒｏＳｅ手順に基づくものとする。さらに、Ｖ２Ｘトラフィックに対して、一種のセミパーシステントな無線リソース割当てがサポートされるものとし、この目的で、特にＵＥ自律リソース割当てモード（モード２とも称する）に関して、無線リソース予約およびセンシングのメカニズムがサポートされることが合意されている。ただし、センシングおよび無線リソース予約に関しては、一般合意にしか達しておらず、その実装方法および効率的かつ完璧な運用のための他のメカニズムの適応方法に関する詳細は示されていない。たとえば、リソースセンシングメカニズムおよび無線リソース予約をどのように正しく実装するかについては、不明瞭なままである。

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

センシング手順により得られる情報として、送信ウィンドウ中の特定の無線リソースが他のデバイスによってすでに予約されているため、車両ＵＥは使用すべきでない、ということが挙げられる。予約された無線リソースの対応するボックスは、垂直方向のストライプを施している。図９で囲っているように、車両ＵＥがデータの送信に利用し得る送信ウィンドウ全体での無線リソース候補（それぞれ３つの連続するリソースブロックペア）を示している。送信ウィンドウには合計６つの候補が存在し、それらはすべて、１つまたは複数の具体的特性に従ってランク付けされていてもよい。一例として、ランク付け手順では、センシングウィンドウ中のセンシング手順において実行されたエネルギー測定に基づいて、様々な無線リソース候補をランク付けするようにしてもよい。より詳細に、関連する無線リソース候補について、センシングウィンドウ全体でエネルギー（たとえば、受信信号強度）を測定することができる。図９に示すように、対応する無線リソース候補は、エネルギー測定に基づいて１〜４にランク付けされるものと例示的に仮定する。これに対応して、センシングウィンドウにおいて対応する同じ周波数無線リソースを有する無線リソース候補２は、等しくランク付けされている。同じことが、２つのリソース候補３にも当てはまる。図９では、センシングウィンドウの対応する無線リソースを斜めのストライプで示しており、この測定エネルギーの平均によって、無線リソース候補２のエネルギーが予測される。同様に、図９では、水平方向のストライプのように、リソース候補４のエネルギー測定に用いられるセンシングウィンドウ中の対応する周波数−時間無線リソースを示している。説明の容易化のため図９には示していないものの、候補１および３に対応するセンシングウィンドウにおいても同様に、無線リソースの対応するエネルギー測定および処理が実行される。

車両ＵＥは、１つのトランスポートブロックについて、４回の送信、すなわち、最初の送信および３回の再送信を実行するものと例示的に仮定する。考え得る実装形態としては、データの各送信、すなわち、データの最初の送信および再送信にリソースセンシング手順の結果を使用する。これにより図９の上記例において、車両ＵＥは、４回の（再）送信を送信するため、最も高いランクの４つのリソース候補を選択することも可能である。この解決手段は柔軟であり、データ（すなわち、１つのトランスポートブロック）の送信について、時間領域および周波数領域において最も利用可能な無線リソースを効率的に使用する。

ただし、受信エンティティの各（再）送信に用いられる無線リソース（すなわち、送信ウィンドウ内の時間および周波数）を示すため、各（再）送信についてスケジューリング割当てを送信することも可能である。あるいは、受信エンティティが最初の送信およびすべての再送信を受信して適正に復号するのに必要なすべての情報を含む１つのスケジューリング割当てを送信することも可能である。いずれの場合も、従来技術の解決手段と比較して、シグナリングオーバヘッドが大幅に増加する。図６に例示する従来技術においては、すべての送信の時間−周波数リソースを示すとともに、すべての（再）送信のタイミングを一意に規定する対応Ｔ−ＲＰＴパターンを示す１つのスケジューリング割当てがすべての（再）送信に対して送信される。従来技術において、再送信に用いられる周波数リソースは、（ＳＡにおいて明示的に示される）最初のデータ送信に用いられたのと同じであるか、または、最初のデータ送信に用いられた周波数リソースから始まる周波数ホッピングパターンに従う（スケジューリング割当ては、周波数ホッピングパターンが用いられるか否かを示す）。最初の送信と再送信との間にこのような時間および／または周波数の固定関係がない場合は、送信ごとに、実際に使用される時間−周波数無線リソースに関する別個の情報を受信エンティティに提供する必要がある。

さらに、受信エンティティは、たとえばデータのソフト合成（soft-combining）を可能にするため、１つのトランスポートブロックの最初の送信および再送信を一体的に関連付け得る必要がある。この点において、送信が発生するサブフレームを示す長さＬ−Ｐのビットマップ（１００ビットによって、１００ｍｓの送信ウィンドウ内の送信を示し得る）を伝えることも可能であり、これによって、受信エンティティは、１つのトランスポートブロックのすべての送信を一体的に関連付けることができる。ただし、ビットマップは、長くなるため、シグナリングオーバヘッドがさらに増加することになる。さらに、送信ウィンドウの長さは異なる可能性があるため、最も長いと考えられる送信ウィンドウを示すことができるようにビットマップを非常に長くするか、または、送信ウィンドウの長さに応じてビットマップのサイズを変更することが必要であるが、これら２つの解決手段はいずれも都合が悪い。

上記は、同じデータの最初の送信および再送信のセンシング手順および対応する無線リソース割当てを実現するための考え得る解決手段を提供するが、いくつかの不都合および問題を伴う。

本発明者らは、上記説明の不都合および問題を軽減する以下の例示的な実施形態を着想した。

３ＧＰＰ規格により与えられるとともに背景技術の項で一部説明した広い仕様において、種々の実施形態の特定の実装形態が実現されるものとし、以下の実施形態で説明する通り、特定の重要な特徴がこれに追加される。これらの実施形態は、たとえば背景技術の項で説明した３ＧＰＰ ＬＴＥ−Ａ（リリース１０／１１／１２／１３／１４またはそれ以降のリリース）通信システム等の移動体通信システムにおいて都合良く用いられるようになっていてもよいが、これら特定の例示的な通信ネットワークにおける使用に限定されない。

上記説明は、本開示の範囲を限定するものではなく、本開示をより深く理解するための実施形態の一例に過ぎないことが了解されるものとする。当業者であれば、本明細書に明示していない方法で、特許請求の範囲に記載の本開示の一般原理を異なるシナリオに適用可能であることが認識されよう。例示を目的としていくつかの仮定を導入しているが、これらは、以下の実施形態の範囲を制限しないものとする。

種々の実施形態は主として、無線リソース割当ておよびサイドリンクインターフェースを介したデータの送信を送信デバイスが実行する方法の改善に焦点を当てており、この点において、データ送信用にデバイスが送信するスケジューリング割当ての内容の改善も示唆している。詳細については、以下に説明する実施形態から明らかとなるであろう。他の機能（すなわち、種々の実施形態により変更とならない機能）については、背景技術の項で説明したものとまったく同じであってもよいし、種々の実施形態への影響なく変更されてもよい。

種々の実施形態を適用可能な１つの例示的なシナリオとして、背景技術の項で説明したＶ２Ｘ通信がある。結果的に、送信デバイスおよび受信デバイスとしては、たとえば車両中のＵＥ，路側ユニット、歩行者が携行する「通常の」移動端末等が可能である。さらに、データは、（周期的な）車両データ（たとえば、ＣＡＭメッセージ）であってもよく、様々な車両エンティティ間で継続的に交換されるものとし、また、３ＧＰＰにおいては、これらについてのリソースセンシング手順およびセミパーシステントなリソースを議論済みである。以下の例示的な実施形態は、このようなＶ２Ｘ通信シナリオに関して、例示を目的として説明するが、本発明はこれに限定されないものとする。

［第１の実施形態］
以下、前述の問題を解決する第１の実施形態を詳しく説明する。第１の実施形態の様々な実装形態および変形例についても同様に説明する。

前述した通り、車両に設置され、本明細書の背景技術の項で説明したＤ２Ｄフレームワークに基づいて車両通信を実行可能なＵＥを例示的に仮定する。これに対応して、車両ＵＥにより、車両データ（たとえば、周期的および非周期的なデータ）に関心がある他のエンティティへとデータが送信されるものとする。ＵＥは、モード２無線リソース割当てをサポートするとともに主として実行し、ＰＣ５（サイドリンク）インターフェースを介してスケジューリング情報およびデータを送信する無線リソースを自律的に選択できるように、（データおよびスケジューリング割当ての）必要なリソースプールが適正に設定されているものと仮定する。

車両ＵＥにより送信される周期的データは、背景技術の項で詳しく説明した協調認識メッセージ（ＣＡＭ）により例示される。背景技術の項で説明した通り、センシングおよび無線リソース予約は一般的に、周期的な車両データの送信に関して、今後の規格リリースにおいて含まれるべく３ＧＰＰにより承認されている。特に、送信側での無線リソース予約によれば、たとえば現在使われているのと同じリソースを後々の１つまたは複数の時点にも予約して周期的データの別のパケットを送信することにより、一種の「セミパーシステント」な無線リソース割当ての実装が可能となる。その結果、このような後の時点において、車両ＵＥは、周期的なデータを送信できるようにリソース選択／要求（モード１またはモード２リソース割当て）を再度実行する必要がなくなる。無線リソース予約は、様々な方法で実装可能であり、３ＧＰＰでは未だ固定されていない。たとえば、無線リソース予約は、次の送信インスタンスまたはより長い期間（すなわち、周期的データの次の送信インスタンス以上）にわたって実行可能である。サイドリンクデータとともに送信されるスケジューリング情報（ＳＣＩ）は、送信に用いられた無線リソースを識別するため、受信エンティティは、サイドリンクデータを適正に受信して処理／復号することができる。また、スケジューリング情報は、たとえば無線リソースが予約された時間（たとえば、サブフレーム）を受信エンティティが決定できるようにデータの時間または周期性を示すことによって、無線リソース予約を指定するのに用いられるようになっていてもよい。

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

リソースセンシング手順の潜在的な一実装形態の選択肢として、たとえば次のサブフレームから始まって１００ｍｓ（たとえば、最大１秒）に及ぶ周波数リソースの予測を伴うマップをすべてのＵＥが有する。そして、パケットがＵＥのバッファに到着する時間Ｐでは、（送信ウィンドウと称し得る）サブフレームＰ〜Ｌのすべての周波数リソースのマップをＵＥがすでに準備している。ここで、Ｌは基本的に、パケットが送信されるまでの（ＱｏＳに応じた）最大期間に対応する。周波数マップは、利用不可能な無線リソースと利用可能な無線リソースとを識別可能である（また、様々な無線リソースの予測エネルギーレベルに関する情報を含む可能性がある）。無線センシング手順の他の実装形態についても同等に可能であり、たとえば、ＵＥは、このような将来的なリソースマップを継続的に更新しないものの、必要な場合にのみ、センシングウィンドウの過去の測定結果から無線リソースを予測する。

データの送信は、データの最初の送信のほか、データの１回または複数回の再送信を含む。たとえば、以下では、総送信回数が４回であること、または、データの最初の送信に加えて３回の再送信が実行されることを主として仮定する。データの総送信回数は、（たとえば、規格またはネットワーク事業者によって）予め決定することも可能であるし、（たとえば、車両ＵＥを制御するｅＮｏｄｅＢまたは車両ＵＥ自体によって）設定可能でもある。総送信回数が設定可能な場合、データの受信者は、予想すべき総送信回数を何とかして把握する必要がある。これは、たとえばスケジューリング割当てにおいて対応する情報を提供することまたはセル中のｅＮｏｄｅＢにより情報をブロードキャストすることによっても可能である。

例示的な一実装形態には、３ＧＰＰによりすでに知られている増分冗長性（ＩＲ：Ｉｎｃｒｅｍｅｎｔａｌ Ｒｅｄｕｎｄａｎｃｙ）の使用を伴う。特に、ＨＡＲＱ動作において、ｅＮＢは、ＵＥが増分冗長性（ＩＲ）合成を採用することにより、合成利得によって符号化利得を追加で得られるように、再送信において元のトランスポートブロック（すなわち、送信対象のデータ）を様々に符号化したバージョンを送信可能である。同様に、サイドリンクインターフェースを通じたＶ２Ｘ送信では、たとえば所定の冗長バージョンシーケンス（ＨＡＲＱ同期非適応再送信に対して規定済みの０、２、３、１等）に続いて、同じデータの様々な冗長バージョンが送信されるように、増分冗長性を再送信に使用することができる。その結果、同じデータ（たとえば、１つのトランスポートブロック）の最初の送信および再送信が実行されることを説明する場合は、厳密に同じデータであるもののを意味するものと解釈されるものとせず、その表現はむしろ、同じデータの様々な冗長バージョンが送信される場合も網羅すべきである。

以上をまとめて、車両ＵＥは、無線リソースセンシング手順を継続的に実行して、将来的な無線リソースに関する情報（予約および／もしくはＲＳＳＩ予測、または他の情報の場合もある）を取得するものと仮定する。車両ＵＥは、さらに周期的（および、非周期的）なデータを送信可能であるとともに、これに関して、モード２リソース割当て手順（ＵＥ自律的）を実行することにより、データの送信に用いられる送信ウィンドウ内で無線リソースを選択するものとする（ＭＣＳ等の他の送信パラメータの決定をさらに含んでいてもよい）。リソースセンシング手順により取得された情報は、リソース割当て手順において使用され、これを改善するものとする。

以下、第１の実施形態の様々な変形例を説明する。第１の実施形態は、ＰＣ５サイドリンクインターフェースを介して実行されるデータ送信の改良された送信手順を提供する。第１の実施形態では、リソース割当ての無線リソースセンシング結果を十分に利用してデータ送信のうちの１つ（たとえば、最初のデータ送信）を優先することにより、最初の送信の信頼性を向上させる。一方、このリソース割当ては、残りのデータ（再）送信には柔軟性が低いため、最初の送信と同様にリソースセンシング手順からの利益を得られないが、シグナリングオーバヘッドの低減は可能である。増分冗長性を使用する場合は、最初の送信が最も重要である。受信エンティティが受信する最初の送信であるとともに、自己復号化可能なためである（これは、他の冗長バージョンには当てはまらない可能性もある）。

データが送信に利用可能となった場合、車両ＵＥは、ＵＥ自律無線リソース割当て手順を実行することにより、保留データの最初の送信を実行するための送信ウィンドウ内の時間−周波数無線リソースの選択を含めて、必要な送信パラメータを取得するものとする。リソース割当て手順では、データの最初の送信に用いられる無線リソースを決定する場合、データ到着前のセンシングウィンドウ（図９のセンシングウィンドウ参照）においてセンシング手順により得られた結果を十分に考慮するものとする。たとえば、予約された無線リソースは回避されるものとし、また、センシングウィンドウにおいて実行されたエネルギー測定に基づいてランク付けされた様々な候補のうち、最良の無線リソース候補を選択可能である。

また、データの再送信を実行する方法を決定するため、送信デバイスは、１回または複数回のデータ送信のタイミングパターンを規定する適当なデータ送信タイミングパターン（背景技術の項により把握されるＴ−ＲＰＴ等）を決定するものとする。Ｔ−ＲＰＴは通例、複数ビット（たとえば、８ビット）の長さを有するビットマップであり、各ビットは、データの送信可能タイミング（たとえば、１つのサブフレーム）と関連付けられている。複数のＴ−ＲＰＴを規定可能である。たとえば、Ｔ−ＲＰＴは、異なる回数の送信を有することができ、８ビットのＴ−ＲＰＴでは、１〜８回の送信を示すことができる。さらに、送信の位置は、Ｔ−ＲＰＴにおいて変動する可能性があり、たとえば、８つの異なるＴ−ＲＰＴが１つの送信を示すことも可能である。何個のどのＴ−ＲＰＴが送信デバイスにおいて規定されるかは、（たとえば、規格またはネットワーク事業者によって）予め決定することも可能であるし、（たとえば、車両ＵＥを制御するｅＮｏｄｅＢによって）設定可能であってもよい。一例によれば、３ＧＰＰ リリース１２および１３においてＤ２Ｄ通信に規定済みのＴ−ＲＰＴを再利用可能である。いずれの場合も、車両ＵＥは、適当なＴ−ＲＰＴを選択して、データの再送信が実行されるタイミングを決定するものとする。Ｔ−ＲＰＴひいてはこれにより示されるデータ送信は、最初の送信を基準として使用することにより、送信ウィンドウにおいてこのように位置決めされる。たとえば、選択されたＴ−ＲＰＴは、最初のデータ送信の直後に続いていてもよいし、Ｔ−ＲＰＴの一部として最初のデータ送信を含んでいてもよい。

上記に対応して、車両ＵＥは、選択された時間−周波数無線リソースに従って最初のデータ送信を実行した後、選択されたＴ−ＲＰＴにより規定された送信タイミングでデータ再送信を実行することになる。さらに、車両ＵＥにより実行される再送信には、最初の送信に用いられたのと同じ周波数（すなわち、ＰＲＢ）を使用することも可能であるし、（たとえば、従来技術により把握される）周波数ホッピングパターンに基づいて、最初の送信の周波数から導出された周波数を使用することも可能である。

したがって、第１の実施形態は、センシング結果に基づく改良された最初のデータ送信と、簡単な送信パターンを用いて、基準としての最初の送信とデータ再送信とを協調させることを組み合わせた解決手段を提供する。これに対応して、受信エンティティに提供される情報は、このようにむしろ制限されているため、シグナリングオーバヘッドが増加しない。特に、データ送信に関して車両ＵＥにより送信されたスケジューリング割当ては、最初の送信の時間−周波数無線リソースと、選択されたＴ−ＲＰＴとを示すため、受信エンティティは、最初のデータ送信およびデータ再送信を受信することができる。任意選択で、スケジューリング割当ては、データ再送信に用いられた周波数リソースに周波数ホッピングパターンが使用されたかについての情報をさらに含んでいてもよい。

図１０は、上記説明に従う第１の実施形態の例示的な一実装形態に係る、ＵＥ挙動のシーケンス図である。この図から明らかなように、リソースセンシング手順は、送信用に保留しているデータの送信にＵＥが実行する一連のステップとは別個に示している。図１０では、破線を使用して、無線リソース予約またはセンシングウィンドウにおいてなされたエネルギー予測等、リソースセンシング手順により与えられる情報を手順の様々なステップで入力として使用可能な方法を示している。たとえば、ＵＥ自律無線リソース割当てでは、選択から予約無線リソースを除外して、干渉を回避することができる。また、適当なＴ−ＲＰＴの選択は、センシング手順により取得された情報に基づくことも可能であり、これについては、本実施形態の他の実装形態と関連してより詳しく説明する。

上述の一般的な第１の実施形態の詳細な第１の実装形態を図１１および図１２に関して説明するが、両図は、送信ウィンドウの一連のサブフレーム、および、データの最初の送信および３回の再送信を含む対応するデータ送信のタイミングを示している。この例示的な図示においては、データが有効となるサブフレームＰのほか、最新のサブフレームでありながらデータの遅延要件に適合しているサブフレームＬを含むように送信ウィンドウを示している。また、送信ウィンドウは、たとえば処理時間を考慮して、サブフレーム１０あるいはそれ以降のサブフレーム１１、・・・を含まないように、異なる規定も可能である。

両図において、車両ＵＥは、サブフレーム１２の時間−周波数無線リソースが最初のデータ送信に最適と判定するものと仮定する。受信エンティティがデータを受信できるように、対応する指示が、対応するスケジューリング割当てに含まれることになる。これまでに仮定した通り、データ（たとえば、１つのトランスポートブロック）は、計４回の送信が実行され、送信の信頼性が高くなる。これにより、本実装形態において、車両ＵＥは、実行される合計回数の送信に従ってＴ−ＲＰＴを選択することになる。図１１および図１２に示す２つの変形例では、Ｔ−ＲＰＴが最初のデータ送信を含むか含まないかを区別する。このため、図１１に示す変形例において、車両ＵＥは、Ｔ−ＲＰＴのうち、計４回の送信を有するＴ−ＲＰＴを選択することになる。図１１には、車両ＵＥにより選択し得る例示的なＴ−ＲＰＴを示す。一方、図１２に示す変形例において、車両ＵＥは、最初の送信がＴ−ＲＰＴに含まれないことを考慮して、Ｔ−ＲＰＴのうち、計３回の送信を有するＴ−ＲＰＴを選択することになる。

図１２の変形例のＴ−ＲＰＴは例示的に、最初の送信が実行されるサブフレームの直後に開始となる。あるいは、Ｔ−ＲＰＴ（ひいては、再送信タイミング）の開始の基準としてサブフレーム１２（すなわち、最初のデータ送信のタイミング）を使用しつつ、最初のデータ送信タイミングと異なるタイミングオフセットを使用することも可能である。たとえば、Ｔ−ＲＰＴは、最初のデータ送信から１つまたは複数のサブフレームの距離で開始となってもよい。タイミングオフセットは、（たとえば、車両ＵＥまたはｅＮｏｄｅＢによって）設定可能であってもよいし、事前設定されていてもよいが、受信エンティティが把握しておく必要はある。

さらに、様々なサブフレーム（図１１の変形例のサブフレーム１４、１５、および１９または図１２の変形例のサブフレーム１５、１６、および２０）で実行される再送信では、最初のデータ送信に用いられたのと同じ周波数を使用することも可能であるし、（既知の周波数ホッピングパターンに基づいて）最初のデータ送信に用いられた周波数から導出された「ホッピング」周波数を使用することも可能である。

前述の通り、Ｔ−ＲＰＴの選択は、総送信回数（図１１参照）または再送信回数（図１２参照）によって制限される。この制限とは別に、例示的な一変形例において、車両ＵＥは、上記必要回数の（再）送信を有するすべてのＴ−ＲＰＴのうち、（必要回数の（再）送信を有する）Ｔ−ＲＰＴをランダムに決定するようにしてもよい。これは、単純な実装形態ではあるものの、ランダムに選定されたタイミングパターンでは、他のデバイスの送信と大きく干渉する再送信タイミング（サブフレーム）となって、都合が悪くなる場合がある。上述の通り、周波数リソースは、最初のデータ送信用に選択された周波数リソースに固定され、同じ周波数無線リソースであるか、または、その周波数ホッピングパターンに従う。

あるいは、Ｔ−ＲＰＴをランダムに決定する代わりに、車両ＵＥは、センシング手順の結果を可能な限り考慮することができる。特に、センシング情報に基づいてＴ−ＲＰＴを適当に選択することにより、車両ＵＥが他のＵＥからの送信との干渉を可能な限り抑えられるように、あるサブフレームにおいて予約された同じ物理リソースブロックを別のサブフレームでも利用可能とし得る。

同様に、たとえば干渉が最小になると考えられる周波数リソースに応じて車両ＵＥが周波数領域にホッピングを使うか使わないかを選定できるように、周波数領域のリソースにホッピングを使用するか否かをセンシング手順の結果に基づいて決めることも可能である。

異なるサブフレームにおける異なる周波数は、異なる衝突および干渉を生じることになるため、タイミングパターンおよび周波数ホッピングを使用するか否かの決定は、相互に関係する。これに対応して、適当なＴ−ＲＰＴおよび周波数ホッピングを使用するか否かは、一体的な決定によって、最適なＴ−ＲＰＴおよび最適なＰＲＢを選択する利益を組み合わせることができる。

前述の通り、データ送信全体にわたって送信されるスケジューリング割当ては、受信エンティティがデータの最初の送信および残りの再送信のタイミングを導出するための主要な情報であり、選択Ｔ−ＲＰＴと最初のデータ送信のための時間−周波数リソースを示す必要がある。任意選択で、スケジューリング割当ては、最初の送信に用いられた周波数に関する周波数ホッピングが使用されたか否かに関する情報をさらに含んでいてもよい。これに対応して、スケジューリング割当てはコンパクトであり、シグナリングオーバヘッドが増加することはない。

上記のように、データの再送信は、決定されたＴ−ＲＰＴが与える期間内に完了することになり、この例示的な事例では、７つ（図１１参照）または８つ（図１２参照）のサブフレーム内である。言い換えると、再送信は、特に１００ｍｓという例示的な遅延要件と比較して、比較的短い時間ウィンドウ内に実行される必要がある。これにより、再送信を送信する車両ＵＥの柔軟性が低下する。ただし、一変形例では、センシング結果も考慮に入れる。他のＵＥによるデータ送信との衝突の可能性は依然として高く、ほとんど回避できない。上記変形例では、ごく短い時間フレーム内に異なるＴ−ＲＰＴがわずかにしか存在せず、柔軟性が非常に限られているためである。

以下、第１の実施形態の上述の変形例を改善する第１の実施形態の他の実装形態を提供する。図１３および図１４に関して説明する通り、（図１１および図１２のように）タイミングパターンの長さが与える特定の時間フレームに再送信を制限する代わりに、第１の実施形態の別の例示的な実装形態によれば、残りの送信ウィンドウ全体に再送信の可能性が広がる。特に、図１１および図１２に関して説明したのと同様に、車両ＵＥは、リソースセンシング手順により取得された情報に基づいて、データの最初の送信の最適な無線リソースを決定する無線リソース割当てを実行するものとする。本例においては、車両ＵＥがサブフレーム１４において最適な時間−周波数無線リソースを決定することにより、このようにサブフレーム１４の決定された周波数で最初の送信が実行されるものと仮定する。

一方、車両ＵＥによって、１回の送信すなわちＴ−ＲＰＴ全体で１回の送信のみを含むデータ送信タイミングパターンが選択される。ただし、この１回送信のＴ−ＲＰＴは、最初の送信後、最初のデータ送信タイミングを基準として有する残りの送信ウィンドウ全体で繰り返されることにより、複数のデータ再送信候補が規定される。たとえば、図１４に示すように、繰り返しＴ−ＲＰＴは、最初のデータ送信タイミング後の次のサブフレームで開始となり得る（図１２に関して上述した通り、最初のデータ送信タイミングからの他のタイミングオフセットも同様に可能である）。あるいは、図１３に示すように、繰り返しＴ−ＲＰＴは、その最初（より厳密には、最初のＴ−ＲＰＴビットマップ中の「１」）が最初のデータ送信タイミングと一致するように開始となる。

このように、最初のデータ送信タイミング後に繰り返しＴ−ＲＰＴを位置決めすることによって、各Ｔ−ＲＰＴは、１回の送信を指定するサブフレームにおいて、１つのデータ再送信候補を規定する。データ再送信候補は、このように（たとえば、最初のデータ送信タイミング後の）残りの送信ウィンドウ全体に分散され、Ｔ−ＲＰＴの長さに従って互いに等間隔となる。たとえば、図１３に示す例示的な実装形態においては、最初のデータ送信がサブフレーム１４で発生するように規定されるため、データ再送信候補は、サブフレーム２２、３０、３８、４６・・・１１０に存在することになる（それぞれの間の距離は、Ｔ−ＲＰＴの長さに一致する８つのサブフレームである）。

送信ウィンドウが１００ｍｓであり、送信パターンが８ビットであるものと仮定すると、（使用する実際の実装形態に応じて）最大１２個（たとえば、図１４の場合）〜１４個（たとえば、図１３の場合）の異なるデータ再送信候補が存在し得る。最後のＴ−ＲＰＴは、不完全となり得るため、（不完全な）Ｔ−ＲＰＴ内の「１」のデータ送信の位置に応じて、別のデータ再送信機会を生じてもよいし、生じなくてもよい。

そして、車両ＵＥは、上記のように規定されたデータ再送信候補のうち、データ再送信に実際に用いられるデータ再送信候補を選択することができる。当然のことながら、この決定もまた、総送信回数（すなわち、総再送信回数）に依存する。図１３に仮定する例示的なシナリオにおいては、利用可能なデータ再送信候補から車両ＵＥが１つだけ選択すれば済むように、計２回の送信のみが実行されるものと仮定する。すなわち、必要な再送信は１回のみである。図１３に示す例示的なシナリオにおいては、一連のＴ−ＲＰＴのうちの３番目と関連付けられた単一のデータ再送信をサブフレーム３０で送信することを車両ＵＥが決定するものと仮定する。図１４に示す例示的なシナリオにおいては、車両ＵＥにより計３回のデータ送信が実行されるものと仮定し、これにより、車両ＵＥが２つの再送信候補を選択する必要がある。これは、サブフレーム２２および３８に存在するものと考えられ、この場合も、繰り返しＴ−ＲＰＴの１番目および３番目である。

車両ＵＥが最初の送信および再送信を実行する場所を受信エンティティが把握するため、スケジューリング割当ては、（前述の通り）最初の送信および選択Ｔ−ＲＰＴの時間−周波数無線リソースを示すのみならず、車両ＵＥがデータ（再）送信に実際に使用するデータ再送信候補に関する情報も示すものとする。すべての候補のうち、使用するデータ再送信候補を示す方法に関する考え得る一選択肢として、スケジューリング割当てにおいてビットマップ（たとえば、Ｔ−ＲＰＴ選択ビットマップと称する）を与える。Ｔ−ＲＰＴ選択ビットマップの各ビットは、繰り返しＴ−ＲＰＴと関連付けられているため、繰り返しＴ−ＲＰＴのうちの１つを一意に識別する。図１３および図１４に示すように、Ｔ−ＲＰＴ選択ビットマップは、実装形態に応じて異なる長さが可能であり、すべてのデータ再送信候補を柔軟に示すことができる長さを有するものとする。両図から明らかなように、Ｔ−ＲＰＴ選択ビットマップの「１」は、車両ＵＥが再送信の実行に実際に使用したＴ−ＲＰＴを示す。Ｔ−ＲＰＴ選択ビットマップは、スケジューリング割当てに含まれるものとする。シグナリングオーバヘッドがわずかに増加するものの、再送信を実行する柔軟性が大幅に向上する利点がある。

再送信の信頼性を向上させるとともに他のデータ送信との衝突の可能性を抑えるため、車両ＵＥは、１回送信のＴ−ＲＰＴのほか、センシング手順により得られた結果に基づいて、再送信に実際に用いられるデータ再送信候補を決定するようにしてもよい。特に、異なる１回送信のＴ−ＲＰＴ（８ビットのＴ−ＲＰＴと仮定）は、多くても８つであり、それぞれ、送信ウィンドウ全体で異なるデータ再送信候補を規定することになる。さらに、このように規定されたデータ再送信候補（たとえば、１３個の候補）のうち、データ再送信を実行する異なる複数組の候補が存在する。全体としては、１回送信のＴ−ＲＰＴおよびデータ再送信を実行する結果的な選択肢に応じて、車両ＵＥは、たとえばセンシング手順により得られた予測に従って干渉が最小となるＴ−ＲＰＴおよびデータ再送信候補の組み合わせを選択するものとする。

さらに、車両ＵＥは、最初のデータ送信に用いられたのと同じ周波数を使用するようにしてもよいし、ホッピングパターンに基づいて最初のデータ送信の周波数から導出された周波数を使用するようにしてもよい。上記説明の通り、この決定自体も、センシング手順の結果に基づくことができ、たとえば、１つのサブフレーム内のＰＲＢごとに無線リソース予約が異なり得ることを考慮に入れる。その結果、データ再送信の信頼性を最適化するのに車両ＵＥが利用可能な３つの異なる自由度が存在し得る。すなわち、１回送信のＴ−ＲＰＴ、すべての再送信候補のうちの実際に使用される再送信候補、およびホッピングに基づく周波数リソースまたは基づかない周波数リソースである。これら３つの自由度は相互に関係しており、単純な（再）送信手順を可能にしつつセンシング結果から可能な限り利益を得られるように、センシングウィンドウにおいて以前に取得されたセンシング結果に基づいて一体的に選定可能である。

別の実装形態によれば、図１３および図１４に関して提示するとともに上述した解決手段は、以下のようにセンシング結果に基づいてデータ再送信リソースのうちの１つを選択することによって、さらに改善される。特に、図１５は、ＵＥがデータ送信に利用可能な送信ウィンドウの一連のサブフレームを示しており、上述の図１４に類似する。図１３および図１４に関して提示した解決手段の場合と同様に、車両ＵＥは、リソースセンシング手順により取得された情報に基づいて、最初のデータ送信の最適な無線リソースを決定する無線リソース割当て手順を実行するものとする。さらに、車両ＵＥによって、最初のデータ送信を基準とする残りの送信ウィンドウ全体で繰り返し位置決めされる１回送信のＴ−ＲＰＴが選択されるものとする。上記解決手段と異なり、Ｔ−ＲＰＴを決定するため、車両ＵＥは最初に、センシング結果に基づいて、残りの送信ウィンドウ内で（すなわち、最初のデータ送信後）最適な再送信候補を決定するものとする。センシング結果に基づいて、車両ＵＥは、他のＵＥによる送信との衝突を回避できるように、この好適な再送信候補の周波数および時間リソースを自由に選択することができる。

そして、Ｔ−ＲＰＴを決定するため、この選択された好適な再送信候補の時間位置が車両ＵＥにより使用される。これを図１５に関して説明する。好適な再送信候補がサブフレーム２６に見つかったものと例示的に仮定する（たとえば、これは２番目に高いランクの候補である一方、最も高いランクの候補は、データの最初の送信に用いられるようにＵＥによって選択されている）。長さ８ビットの繰り返しＴ−ＲＰＴの位置決めが最初のデータ送信の直後に開始となるものと例示的に仮定すると（図１５参照）、車両ＵＥは、繰り返しＴ−ＲＰＴの「１」のうちの１つが以前選択された好適なデータ再送信候補（サブフレーム２６参照）と一致するように、Ｔ−ＲＰＴ ０００１００００を選択することになる。これに対応して、車両ＵＥにより実行されるデータ再送信のうちの１回は、センシング結果に基づいてリソース割当て手順で選択された周波数にてサブフレーム２６で発生するものとする（すなわち、サブフレーム２６で使用される周波数は、サブフレーム１４において最初のデータ送信に用いられた周波数とは異なり得る）。図１５においては、最初のデータ送信が好適なデータ再送信候補で実行される一方、別の再送信が次の再送信（場合により、サブフレーム３４）で実行されるものと例示的に仮定する。前述のＴ−ＲＰＴ選択ビットマップは、これらの再送信を示すことが必要となるため、データ再送信に車両ＵＥが使用する２番目および３番目のＴ−ＲＰＴを示す。

上記実装形態において説明した通り、車両ＵＥは、残りのデータ再送信候補から別のデータ再送信候補を選択することが必要となり得る。これは、たとえばセンシング手順の結果を用いて行われるようになっていてもよく、他のＵＥの送信との衝突が回避される。

この図１５の改良された解決手段によれば、以前に得られたセンシング結果に基づいてデータ再送信のうちの１回の時間および周波数リソースをさらに選択することにより、衝突頻度が低下するため、データ送信の信頼性が向上する。ただし、この解決手段では、シグナリングオーバヘッドがわずかに増加する。図１３および図１４に係る実装形態について前述した通り、データに関して車両ＵＥが送信するスケジューリング割当ては、最初のデータ送信のほか、選択Ｔ−ＲＰＴおよびＴ−ＲＰＴ選択ビットマップの時間−周波数無線リソースを示す。Ｔ−ＲＰＴ選択ビットマップと組み合わされ、最初のデータ送信タイミングを基準とするＴ−ＲＰＴが残りのデータ再送信すべてのタイミングを一意に識別する一方、受信エンティティは、車両ＵＥが好適な無線リソース（たとえば、上記サブフレーム２６参照）でデータ再送信を送信するのに使用する周波数について把握しておく必要がある。周波数がセンシング結果に基づいて自由に選択されることで、最初のデータ送信のスケジューリング割当てにおいて指定済みの周波数と一致しなくなる（あるいは、周波数ホッピングパターンに適合しなくなる）ためである。そこで、１つの解決手段として、サブフレーム２６でこの１回の再送信に用いられる他方の周波数に関する情報を含むものとする。これは、周波数を明示的に識別することによっても可能であるし、最初のデータ送信に用いられた周波数からの周波数オフセット含めることによっても可能である。周波数オフセットは、サブフレーム２６で１回のデータ再送信に用いられる周波数を決定するため、受信エンティティにより用いられるようになっていてもよい。

さらに、最初の送信または１回の好適なデータ再送信に用いられたのと同じ周波数を残りのデータ再送信の送信に用いることも可能である。あるいは、最初のデータ送信または好適なデータ再送信に用いられた周波数に関する周波数ホッピングパターンを残りのデータ再送信に使用することも可能である。この点において、スケジューリング割当てにおいて対応する周波数ホッピングの指定が受信エンティティに適宜通知される。

以下、最初のデータ送信およびデータ再送信について実行される無線リソース割当ての別の改良例を説明する。例示的な一実装形態によれば、図９において簡単に示した複数の時間−周波数無線リソースを含むデータリソースプールは、最初のデータ送信の実行にのみ利用可能な時間−周波数無線リソースに分割される一方、データリソースプールの残りの時間−周波数無線リソースは、データ再送信の実行にのみ利用可能である。あるいは、最初のデータ送信用の一方のデータリソースプールおよびデータ再送信用の他方のデータリソースプールという２つの異なるデータリソースプールを設けることができる。いずれの場合は、リソース割当て手順において、車両ＵＥは、最初の送信およびデータ再送信に異なるリソースを使用する。データリソースプールの分離は、たとえば対応するセルのすべての車両ＵＥに当てはまるものとする。したがって、データ送信に利用可能なリソースを最初のデータ送信とデータ再送信とで分離することにより、最初の送信をさらに保護することができる。理論上、再送信との衝突が不可能となるためである。

利用可能な時間−周波数リソースの分離は、様々に実行可能である。たとえば、対応する式を提供し、これを車両ＵＥおよび他のＵＥが使用することによって、最初のデータ送信およびデータ再送信に使用すべき時間−周波数無線リソースを決定することができる。簡単な式は、たとえばモジュロ演算に基づくことができる。さらに、最初のデータ送信およびデータ再送信の異なるデータリソースプールは、システム情報を適当にブロードキャストすることによって、ｅＮｏｄｅＢにより設定可能である。

特定の例示的な一変形例においては、サブフレームが最初の送信または再送信に用いられるように、分離が時間領域で実行される。

この改良は、たとえば車両ＵＥが各（再）送信の無線リソース割当て手順を実行する図９に関して上述した実装形態に適用可能である。さらに、この改良は、図１１〜図１５に関して上述した実装形態にも適用可能である。たとえば、図１１および図１２に提示の解決手段に関して、さらに改良された解決手段であれば、最初の送信にのみ利用可能な時間−周波数リソースの中で、最初の送信の無線リソース選択を実行することになる。そして、（ランダム選択またはセンシング結果に基づく選択によって）選択されたＴ−ＲＰＴパターンは、データ再送信を対象とするデータリソースプールにおいて実際に利用可能なサブフレームのみを示すことになる。図１６は、再送信に利用不可能なサブフレームが抹消された一実装形態を例示的に示している。たとえば、３つごとのサブフレームのみ（特に、サブフレーム１４、１７、２０、２３、２６、２９等）を再送信に利用可能であるものと仮定する。図から明らかなように、Ｔ−ＲＰＴビットマップの各ビットは、再送信に実際に利用可能なサブフレームのみを対応的に示す（ただし、この変形例においては、最初の送信を示すものと仮定したＴ−ＲＰＴの最初のビットを例外とする）。結果として、図１１で使用した例示的なシナリオと同じＴ−ＲＰＴビットマップ（１０１１０００１）を使用することにより、車両ＵＥは、サブフレーム１７、２０、および３２で再送信を実行することになる。

同様に、図１３、図１４、および図１５に係る実装形態の場合は、再送信が制限されたデータリソースプールに属する送信ウィンドウのサブフレーム全体で繰り返しＴ−ＲＰＴパターンが繰り返されることになる。図１５の解決手段に関して、（サブフレーム２６における）１回の好適なデータ再送信に対して排他的に実行される無線リソース割当てでは、再送信が制限されたデータリソースプール内のリソースを選択することになる。

［他の実施形態］
第１の態様によれば、サイドリンクインターフェースを介してデータを１つまたは複数の受信デバイスに送信する送信デバイスが提供される。データの送信は、データの最初の送信と、最初のデータ送信の後、データの１回または複数回の再送信とを含む。送信デバイスの受信部およびプロセッサは、リソースセンシング手順を実行して、送信デバイスが後の時点でデータを送信するのに使用可能な無線リソースに関する情報を取得する。プロセッサは、データが送信に利用可能となった後、データが送信に利用可能となる前にセンシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて、自律的な無線リソース割当てを実行することにより、データの最初の送信の実行に用いられる送信ウィンドウ内で時間−周波数無線リソースを選択する。プロセッサは、データの１回または複数回の送信を実行する送信タイミングをそれぞれ示す複数のデータ送信タイミングパターンのうちの１つを決定する。送信デバイスの送信部は、選択された時間−周波数無線リソースを用いて最初のデータ送信を実行するとともに、最初のデータ送信に関して決定されたデータ送信タイミングパターンにより規定された送信タイミングで１回または複数回のデータ再送信を実行する。

第１の態様に追加して与えられる第２の態様によれば、複数のデータ送信タイミングパターンは、異なる回数のデータ送信を示す。プロセッサは、データ送信タイミングパターンのうち、データに関して実行される合計回数の送信に対応する１つのデータ送信タイミングパターンを決定する。任意選択的な一実装形態において、データに関して実行される合計回数の送信は、プロセッサにより決定されるか、または、事前設定される。一選択肢によれば、１回または複数回のデータ再送信は、１つの決定されたデータ送信タイミングパターンの長さにより規定された期間内に実行される。データ送信タイミングパターンは、プロセッサによって、ランダムに決定されるか、または、センシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて決定される。

第１または第２の態様に追加して与えられる第３の態様によれば、送信部は、最初のデータ送信に関して選択された時間−周波数無線リソースを示すとともに決定されたデータ送信タイミングパターンを識別するスケジューリング割当てを送信する。

第１の態様に追加して与えられる第４の態様によれば、決定されたデータ送信タイミングパターンは、１回のデータ送信のみを示す。プロセッサは、最初のデータ送信のタイミングに関して送信ウィンドウ内で決定されたデータ送信タイミングパターンを複数回繰り返した後、繰り返されるデータ送信タイミングパターンごとに１回の指定されたデータ送信により与えられるタイミング位置を識別することによって、１回または複数回のデータ再送信を実行する送信ウィンドウ内でデータ再送信候補を決定する。プロセッサは、任意選択でデータに関して実行される合計回数の送信であり、プロセッサによる決定または事前設定が可能である、合計回数の送信に応じて、１回または複数回のデータ再送信の実行に用いられるデータ再送信候補を決定する。一選択肢によれば、プロセッサは、センシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて、データ送信タイミングパターンのほか、データ再送信に用いられるデータ再送信候補を決定する。

第１〜第４の態様のいずれか１つに追加して与えられる第５の態様によれば、１回または複数回のデータ再送信は、最初のデータ送信に用いられたのと同じ周波数無線リソースまたは周波数ホッピングパターンに基づいて最初のデータ送信に用いられた周波数無線リソースからプロセッサにより決定された周波数無線リソースを用いて実行される。一選択肢によれば、プロセッサは、１回または複数回のデータ再送信に関して、センシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて、最初のデータ送信と同じ周波数無線リソースを使用するか、周波数ホッピングパターンに従う周波数無線リソースを使用するかを判定する。別の選択肢によれば、スケジューリング割当ては、送信デバイスによって、１回または複数回のデータ再送信の送信に用いられる周波数無線リソースの決定に周波数ホッピングパターンが用いられるか否かをさらに示す。

第１の態様に追加して与えられる第６の態様によれば、決定されたデータ送信タイミングパターンは、１回の送信のみを示す。プロセッサは、１回または複数回のデータ再送信のうちの１回に関して、センシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて、最初のデータ送信タイミング後の好適な送信タイミングを決定する。プロセッサは、最初のデータ送信のタイミングに関して送信ウィンドウ内でデータ送信タイミングパターンが複数回繰り返される場合に、データ送信タイミングパターンの１回の指定されたデータ送信が決定された好適な送信タイミングと一致するように、データ送信タイミングパターンを決定する。データ送信タイミングパターンを繰り返した後、繰り返されるデータ送信タイミングパターンごとに１回の指定されたデータ送信により与えられるタイミング位置を識別することによって、データ再送信のうちの１回または複数回を実行する送信ウィンドウ内でデータ再送信候補が規定される。プロセッサは、任意選択でセンシングウィンドウにおいてリソースセンシング手順により取得された情報に基づき、データに関して実行される合計回数の送信に応じて、残りのデータ再送信の実行に用いられるデータ再送信候補を決定する。合計回数のデータ送信は、プロセッサによる決定も可能であるし、事前設定も可能である。送信部は、決定された好適な送信タイミングで１回のデータ再送信を送信するとともに、使用が決定された再送信候補で残りのデータ再送信を送信する。

第６の態様に追加して与えられる第７態様によれば、送信部により送信されたスケジューリング割当ては、好適な送信タイミングでデータ再送信の周波数無線リソースを示す。たとえば、好適な送信タイミングでのデータ再送信の周波数リソースの指定としては、最初のデータ送信の周波数無線リソースに関するオフセットが可能である。一選択肢によれば、残りのデータ再送信は、最初のデータ送信に用いられたのと同じ周波数無線リソースまたは好適な送信タイミングでのデータ再送信に用いられたのと同じ周波数無線リソースを用いて実行される。あるいは、残りのデータ再送信は、最初のデータ送信に用いられた周波数無線リソースまたは好適な送信タイミングでのデータ再送信に用いられた周波数無線リソースから周波数ホッピングパターンに基づいてプロセッサにより決定された周波数無線リソースを用いて実行される。これに対応して、スケジューリング割当ては、送信デバイスによって、１回または複数回のデータ再送信の送信に用いられる周波数無線リソースの決定に周波数ホッピングパターンが用いられるか否かをさらに示す。

第４〜第７の態様のいずれか１つに追加して与えられる第８の態様によれば、送信部は、最初のデータ送信に関して選択された時間−周波数無線リソースを示すとともに決定されたデータ送信タイミングパターンを識別するスケジューリング割当てを送信する。スケジューリング割当ては、複数の繰り返されるデータ送信タイミングパターンのうち、１回または複数回のデータ再送信を実行する送信タイミングを規定するデータ送信タイミングパターンをさらに示す。任意選択で、データ送信タイミングパターンの指定は、ビットマップとして符号化されており、ビットマップのビットがそれぞれ、複数の繰り返されるデータ送信タイミングパターンのうちの１つと関連付けられている。

第１〜第８の態様のいずれか１つに追加して与えられる第９の態様によれば、データ送信タイミングパターンは、複数ビットの長さを有する。データ送信タイミングパターンの各ビットは、各ビットの位置と関連付けられた送信タイミングでデータの送信が実行されるか否かを示す。任意選択で、データ送信タイミングパターンは、最初のデータ送信も示すか、または、示すことのないように、最初のデータ送信に関してタイミングウィンドウに位置決めされている。

第１〜第９の態様のいずれか１つに追加して与えられる第１０の態様によれば、送信デバイスがデータ送信を実行するのに利用可能な複数の時間−周波数無線リソースをデータリソースプールが含む。データリソースプールは、最初のデータ送信の実行に利用可能な時間−周波数無線リソースおよびデータ再送信の実行に利用可能な時間−周波数無線リソースに分割されている。そして、プロセッサは、自律的な無線リソース割当てにおいて、最初のデータ送信の実行に利用可能な時間−周波数無線リソースのうち、最初のデータ送信の実行に用いられる時間−周波数無線リソースを選択する。任意選択で、データリソースプールの複数の時間−周波数無線リソースは、時間領域において、最初のデータ送信およびデータ再送信用の時間−周波数無線リソース間で分割されている。別の選択肢として、データリソースプールの分割は、事前設定されるか、または、送信デバイスを制御する無線基地局により設定される。

第７〜第１０の態様のいずれか１つに追加して与えられる第１１の態様によれば、リソースセンシング手順は、
・ 他の送信デバイスにより予約された無線リソースを決定するため、受信部およびプロセッサが、動作時に、後の時点用に他の送信デバイスにより予約された無線リソースを示す他の送信デバイスにより送信されたスケジューリング割当てを監視することと、
・ 任意選択で、無線リソースにおける受信信号エネルギーを測定して、他の送信デバイスにより送信に用いられた無線リソースを識別することと、
を含む。

一選択肢として、自律的な無線リソース割当ては、複数の送信無線リソースから、他の送信デバイスにより予約された無線リソースを除外することを含む。

第１２の態様によれば、サイドリンクインターフェースを介してデータを１つまたは複数の受信デバイスに送信する送信デバイスのための方法が提供される。データの送信は、データの最初の送信と、最初のデータ送信の後、データの１回または複数回の再送信とを含む。この方法は、送信デバイスにより実行される以下のステップを含む。リソースセンシング手順を実行して、送信デバイスが後の時点でデータを送信するのに使用可能な無線リソースに関する情報を取得する。データが送信に利用可能となった後、データが送信に利用可能となる前にセンシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて、自律的な無線リソース割当てを実行することにより、データの最初の送信の実行に用いられる送信ウィンドウ内で時間−周波数無線リソースを選択する。送信デバイスは、データの１回または複数回の送信を実行する送信タイミングをそれぞれ示す複数のデータ送信タイミングパターンのうちの１つを決定する。送信デバイスは、選択された時間−周波数無線リソースを用いて最初のデータ送信を実行するとともに、最初のデータ送信に関して決定されたデータ送信タイミングパターンにより規定された送信タイミングで１回または複数回のデータ再送信を実行する。

第１２の態様に追加して与えられる第１３の態様によれば、複数のデータ送信タイミングパターンは、異なる回数のデータ送信を示す。この方法は、データ送信タイミングパターンのうち、データに関して実行される合計回数の送信に対応する１つのデータ送信タイミングパターンを決定することを含む。任意選択で、データに関して実行される合計回数の送信は、送信デバイスにより決定されるか、または、事前設定される。任意選択で、１回または複数回のデータ再送信は、１つの決定されたデータ送信タイミングパターンの長さにより規定された期間内に実行される。任意選択で、データ送信タイミングパターンは、送信デバイスによって、ランダムに決定されるか、または、センシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて決定される。

第１２または第１３の態様に追加して与えられる第１４の態様によれば、この方法は、最初のデータ送信に関して選択された時間−周波数無線リソースを示すとともに決定されたデータ送信タイミングパターンを識別するスケジューリング割当てを送信するステップをさらに含む。

第１２の態様に追加して与えられる第１５の態様によれば、決定されたデータ送信タイミングパターンは、１回のデータ送信のみを示す。この方法は、最初のデータ送信のタイミングに関して送信ウィンドウ内で決定されたデータ送信タイミングパターンを複数回繰り返した後、繰り返されるデータ送信タイミングパターンごとに１回の指定されたデータ送信により与えられるタイミング位置を識別することによって、１回または複数回のデータ再送信を実行する送信ウィンドウ内でデータ再送信候補を決定するステップを含む。この方法は、任意選択でデータに関して実行される合計回数の送信であり、プロセッサにより決定されるか、または、事前設定された、合計回数の送信に応じて、１回または複数回のデータ再送信の実行に用いられるデータ再送信候補を決定するステップを含む。任意選択で、この方法は、センシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて、データ送信タイミングパターンのほか、データ再送信に用いられるデータ再送信候補を決定するステップを含む。

第１２〜第１５の態様のいずれか１つに追加して与えられる第１６の態様によれば、１回または複数回のデータ再送信は、最初のデータ送信に用いられたのと同じ周波数無線リソースまたは周波数ホッピングパターンに基づいて最初のデータ送信に用いられた周波数無線リソースから決定された周波数無線リソースを用いて実行される。任意選択で、この方法は、１回または複数回のデータ再送信に関して、センシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて、最初のデータ送信と同じ周波数無線リソースを使用するか、周波数ホッピングパターンに従う周波数無線リソースを使用するかを判定するステップを含む。任意選択して、スケジューリング割当ては、送信デバイスによって、１回または複数回のデータ再送信の送信に用いられる周波数無線リソースの決定に周波数ホッピングパターンが用いられるか否かをさらに示す。

第１２の態様に追加して与えられる第１７の態様によれば、決定されたデータ送信タイミングパターンは、１回の送信のみを示す。この方法は、１回または複数回のデータ再送信のうちの１回に関して、センシングウィンドウにおいてリソースセンシング手順により取得された情報に基づいて、最初のデータ送信タイミング後の好適な送信タイミングを決定するステップを含む。この方法は、最初のデータ送信のタイミングに関して送信ウィンドウ内でデータ送信タイミングパターンが複数回繰り返される場合に、データ送信タイミングパターンの１回の指定されたデータ送信が決定された好適な送信タイミングと一致するように、データ送信タイミングパターンを決定するステップを含む。データ送信タイミングパターンを繰り返した後、繰り返されるデータ送信タイミングパターンごとに１回の指定されたデータ送信により与えられるタイミング位置を識別することによって、データ再送信のうちの１回または複数回を実行する送信ウィンドウ内でデータ再送信候補が規定される。この方法は、任意選択でセンシングウィンドウにおいてリソースセンシング手順により取得された情報に基づき、データに関して実行される合計回数の送信であり、送信デバイスにより決定されるか、または、事前設定された、合計回数の送信に応じて、残りのデータ再送信の実行に用いられるデータ再送信候補を決定するステップを含む。この方法は、決定した好適な送信タイミングで１回のデータ再送信を送信するとともに、使用が決定された再送信候補で残りのデータ再送信を送信するステップを含む。

第１７の態様に追加して与えられる第１８態様によれば、送信部により送信されたスケジューリング割当ては、任意選択で最初のデータ送信の周波数無線リソースに関するオフセットとして、好適な送信タイミングでデータ再送信の周波数無線リソースを示す。任意選択で、残りのデータ再送信は、最初のデータ送信に用いられたのと同じ周波数無線リソースまたは好適な送信タイミングでのデータ再送信に用いられたのと同じ周波数無線リソースを用いて実行される。あるいは、残りのデータ再送信は、最初のデータ送信に用いられた周波数無線リソースまたは好適な送信タイミングでのデータ再送信に用いられた周波数無線リソースから周波数ホッピングパターンに基づいてプロセッサにより決定された周波数無線リソースを用いて実行される。スケジューリング割当ては、送信デバイスによって、１回または複数回のデータ再送信の送信に用いられる周波数無線リソースの決定に周波数ホッピングパターンが用いられるか否かをさらに示す。

第１５〜第１８の態様のいずれか１つに追加して与えられる第１９の態様によれば、この方法は、最初のデータ送信に関して選択された時間−周波数無線リソースを示すとともに決定されたデータ送信タイミングパターンを識別するスケジューリング割当てを送信するステップをさらに含む。スケジューリング割当ては、複数の繰り返されるデータ送信タイミングパターンのうち、１回または複数回のデータ再送信を実行する送信タイミングを規定するデータ送信タイミングパターンをさらに示す。任意選択で、データ送信タイミングパターンの指定は、ビットマップとして符号化されており、ビットマップのビットがそれぞれ、複数の繰り返されるデータ送信タイミングパターンのうちの１つと関連付けられている。

第１２〜第１９の態様のいずれか１つに追加して与えられる第２０の態様によれば、データ送信タイミングパターンは、複数ビットの長さを有する。データ送信タイミングパターンの各ビットは、各ビットの位置と関連付けられた送信タイミングでデータの送信が実行されるか否かを示す。任意選択で、データ送信タイミングパターンは、最初のデータ送信も示すか、または、示すことのないように、最初のデータ送信に関してタイミングウィンドウに位置決めされている。

第１２〜第２０の態様のいずれか１つに追加して与えられる第２１の態様によれば、送信デバイスがデータ送信を実行するのに利用可能な複数の時間−周波数無線リソースをデータリソースプールが含む。データリソースプールは、最初のデータ送信の実行に利用可能な時間−周波数無線リソースおよびデータ再送信の実行に利用可能な時間−周波数無線リソースに分割されている。この方法は、自律的な無線リソース割当てにおいて、最初のデータ送信の実行に利用可能な時間−周波数無線リソースのうち、最初のデータ送信の実行に用いられる時間−周波数無線リソースを選択するステップを含む。任意選択で、データリソースプールの複数の時間−周波数無線リソースは、時間領域において、最初のデータ送信およびデータ再送信用の時間−周波数無線リソース間で分割されている。任意選択で、データリソースプールの分割は、事前設定されるか、または、送信デバイスを制御する無線基地局により設定される。

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

コンピュータデバイス（プロセッサ）を用いて種々実施形態が実装または実行され得ることもさらに認識される。コンピュータデバイスまたはプロセッサは、たとえば汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のプログラム可能な論理デバイス等であってもよい。また、種々実施形態は、これらのデバイスの組み合わせによって実行または具現化されていてもよい。特に、上述の各実施形態の説明に使用した各機能ブロックは、集積回路としてのＬＳＩにより実現可能である。これらは、チップとして個々に形成されていてもよいし、機能ブロックの一部または全部を含むように１つのチップが形成されていてもよい。これらは、データ入出力が結合されていてもよい。ここで、ＬＳＩは、集積度の違いに応じて、ＩＣ、システムＬＳＩ、超ＬＳＩ、極超ＬＳＩとも称し得る。ただし、集積回路を実装する技術はＬＳＩに限定されず、個別回路または汎用プロセッサを用いることにより実現されるようになっていてもよい。また、ＬＳＩの製造後にプログラム可能なＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＬＳＩの内側に配設された回路セルの接続および設定を再構成可能な再構成可能プロセッサが用いられるようになっていてもよい。

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

当業者には当然のことながら、特定の実施形態に示すように、本開示の多くの変形および／または改良が可能である。したがって、本実施形態は、あらゆる点で例示に過ぎず、何ら限定的なものではないと考えるべきである。

Claims (21)

1. サイドリンクインターフェースを介してデータを１つまたは複数の受信装置に送信する送信装置であって、前記データの前記送信が、前記データの最初の送信と、前記最初のデータ送信の後、前記データの１回または複数回の再送信とを含み、
   前記送信装置は、
   動作時に、リソースセンシング手順を実行して、前記送信装置が、後の時点でデータを送信するのに使用可能な無線リソースに関する情報を取得する、受信部およびプロセッサ、
   を備え、
   前記プロセッサが、動作時およびデータが送信に利用可能となった後、前記データが送信に利用可能となる前にセンシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づいて、自律的な無線リソース割当てを実行することにより、前記データの最初の送信の実行に用いられる送信ウィンドウ内で時間−周波数無線リソースを選択し、
   前記プロセッサが、動作時に、データの１回または複数回の送信を実行する送信タイミングをそれぞれ示す複数のデータ送信タイミングパターンのうちの１つを決定し、
   前記送信装置は、
   動作時に、前記選択された時間−周波数無線リソースを用いて前記最初のデータ送信を実行し、前記最初のデータ送信に関して前記決定されたデータ送信タイミングパターンにより規定された送信タイミングで前記１回または複数回のデータ再送信を実行する送信部、を備える、
   送信装置。
2. 前記複数のデータ送信タイミングパターンが、異なる回数のデータ送信を示しており、前記プロセッサが、動作時に、データ送信タイミングパターンのうち、前記データに関して実行される合計回数の送信に対応する１つのデータ送信タイミングパターンを決定し、任意選択で、前記データに関して実行される前記合計回数の送信が、前記プロセッサにより決定されるか、または、事前設定され、
   任意選択で、前記１回または複数回のデータ再送信が、前記１つの決定されたデータ送信タイミングパターンの長さにより規定された期間内に実行され、
   任意選択で、前記データ送信タイミングパターンが、前記プロセッサによって、ランダムに決定されるか、または、前記センシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づいて決定される、
   請求項１に記載の送信装置。
3. 前記送信部が、動作時に、前記最初のデータ送信に関して前記選択された時間−周波数無線リソースを示し、前記決定されたデータ送信タイミングパターンを識別する、スケジューリング割当てを送信する、
   請求項１または２に記載の送信装置。
4. 前記決定されたデータ送信タイミングパターンが、１回のデータ送信のみを示しており、前記プロセッサが、動作時に、前記最初のデータ送信のタイミングに関して前記送信ウィンドウ内で前記決定されたデータ送信タイミングパターンを複数回繰り返した後、繰り返されるデータ送信タイミングパターンごとに前記１回の指定されたデータ送信により与えられるタイミング位置を識別することによって、前記１回または複数回のデータ再送信を実行する前記送信ウィンドウ内でデータ再送信候補を決定し、
   前記プロセッサが、動作時に、任意選択で前記データに関して実行される合計回数の送信であり、前記プロセッサにより決定されるか、または、事前設定された、合計回数の送信に応じて、前記１回または複数回のデータ再送信の実行に用いられるデータ再送信候補を決定し、
   任意選択で、前記プロセッサが、動作時に、前記センシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づいて、前記データ送信タイミングパターンと、前記データ再送信に用いられる前記データ再送信候補とを決定する、
   請求項１に記載の送信装置。
5. 前記１回または複数回のデータ再送信が、前記最初のデータ送信に用いられたのと同じ周波数無線リソース、または、周波数ホッピングパターンに基づいて前記最初のデータ送信に用いられた前記周波数無線リソースから前記プロセッサにより決定された周波数無線リソースを用いて実行され、
   任意選択で、前記プロセッサが、動作時に、前記１回または複数回のデータ再送信に関して、前記センシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づいて、前記最初のデータ送信と同じ周波数無線リソースを使用するか、前記周波数ホッピングパターンに従う周波数無線リソースを使用するかを判定し、
   任意選択で、前記スケジューリング割当てが、前記送信装置によって、前記１回または複数回のデータ再送信の送信に用いられる周波数無線リソースの決定に周波数ホッピングパターンが用いられるか否かをさらに示す、
   請求項１〜４のいずれか一項に記載の送信装置。
6. 前記決定されたデータ送信タイミングパターンが、１回の送信のみを示しており、前記プロセッサが、動作時に、前記１回または複数回のデータ再送信のうちの１回に関して、前記センシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づいて、前記最初のデータ送信タイミング後の好適な送信タイミングを決定し、前記プロセッサが、動作時に、前記最初のデータ送信のタイミングに関して前記送信ウィンドウ内で前記データ送信タイミングパターンが複数回繰り返される場合に、前記データ送信タイミングパターンの前記１回の指定されたデータ送信が前記決定された好適な送信タイミングと一致するように、前記データ送信タイミングパターンを決定し、
   前記データ送信タイミングパターンを繰り返した後、繰り返されるデータ送信タイミングパターンごとに前記１回の指定されたデータ送信により与えられるタイミング位置を識別することによって、前記データ再送信のうちの１回または複数回を実行する前記送信ウィンドウ内でデータ再送信候補が規定されており、
   前記プロセッサが、動作時に、任意選択で前記センシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づき、前記データに関して実行される合計回数の送信であり、前記プロセッサにより決定されるか、または、事前設定された、合計回数の送信に応じて、残りのデータ再送信の実行に用いられるデータ再送信候補を決定し、
   前記送信部が、動作時に、前記決定された好適な送信タイミングで１回のデータ再送信を送信し、使用が決定された前記再送信候補で前記残りのデータ再送信を送信する、
   請求項１に記載の送信装置。
7. 前記送信部により送信されたスケジューリング割当てが、任意選択で前記最初のデータ送信の前記周波数無線リソースに関するオフセットとして、前記好適な送信タイミングで前記データ再送信の前記周波数無線リソースを示しており、
   任意選択で、前記残りのデータ再送信が、前記最初のデータ送信に用いられたのと同じ周波数無線リソースもしくは前記好適な送信タイミングでの前記データ再送信に用いられたのと同じ周波数無線リソースを用いて実行されるか、または、前記残りのデータ再送信が、前記最初のデータ送信に用いられた前記周波数無線リソースもしくは前記好適な送信タイミングでの前記データ再送信に用いられた前記周波数無線リソースから周波数ホッピングパターンに基づいて前記プロセッサにより決定された周波数無線リソースを用いて実行され、前記スケジューリング割当てが、前記送信装置によって、前記１回または複数回のデータ再送信の送信に用いられる周波数無線リソースの決定に周波数ホッピングパターンが用いられるか否かをさらに示す、
   請求項６に記載の送信装置。
8. 前記送信部が、動作時に、前記最初のデータ送信に関して前記選択された時間−周波数無線リソースを示すとともに前記決定されたデータ送信タイミングパターンを識別するスケジューリング割当てを送信し、
   前記スケジューリング割当てが、前記複数の繰り返されるデータ送信タイミングパターンのうち、前記１回または複数回のデータ再送信を実行する前記送信タイミングを規定するデータ送信タイミングパターンをさらに示しており、任意選択で、前記データ送信タイミングパターンの指定が、ビットマップとして符号化されており、前記ビットマップのビットがそれぞれ、前記複数の繰り返されるデータ送信タイミングパターンのうちの１つと関連付けられた、
   請求項４〜７のいずれか一項に記載の送信装置。
9. 前記データ送信タイミングパターンが、複数ビットの長さを有しており、前記データ送信タイミングパターンの各ビットが、前記各ビットの位置と関連付けられた送信タイミングで前記データの送信が実行されるか否かを示しており、
   任意選択で、前記データ送信タイミングパターンが、前記最初のデータ送信も示すか、または、示すことのないように、前記最初のデータ送信に関して前記タイミングウィンドウに位置決めされた、
   請求項１〜８のいずれか一項に記載の送信装置。
10. データリソースプールが、前記送信装置がデータ送信を実行するのに利用可能な複数の時間−周波数無線リソースを含み、前記データリソースプールが、最初のデータ送信の実行に利用可能な時間−周波数無線リソースおよびデータ再送信の実行に利用可能な時間−周波数無線リソースに分割されており、
    前記プロセッサが、動作時に、前記自律的な無線リソース割当てにおいて、最初のデータ送信の実行に利用可能な前記時間−周波数無線リソースのうち、前記最初のデータ送信の実行に用いられる時間−周波数無線リソースを選択し、
    任意選択で、前記データリソースプールの前記複数の時間−周波数無線リソースが、時間領域において、最初のデータ送信およびデータ再送信用の時間−周波数無線リソース間で分割されており、
    任意選択で、前記データリソースプールの前記分割が、事前設定されているか、または、前記送信装置を制御する無線基地局により設定された、
    請求項１〜９のいずれか一項に記載の送信装置。
11. 前記リソースセンシング手順が、
    他の送信装置により予約された無線リソースを決定するため、前記受信部および前記プロセッサが、動作時に、後の時点用に前記他の送信装置により予約された無線リソースを示す前記他の送信装置により送信されたスケジューリング割当てを監視することと、
    任意選択で、無線リソースにおける受信信号エネルギーを測定して、他の送信装置により送信に用いられた無線リソースを識別することと、
    を含み、
    任意選択で、前記自律的な無線リソース割当てが、前記複数の送信無線リソースから、他の送信装置により予約された前記無線リソースを除外することを含む、
    請求項１〜１０のいずれか一項に記載の送信装置。
12. サイドリンクインターフェースを介してデータを１つまたは複数の受信装置に送信する送信装置のための方法であって、前記データの前記送信が、前記データの最初の送信と、前記最初のデータ送信の後、前記データの１回または複数回の再送信とを含み、前記送信装置により実行される以下のステップ、すなわち、
    リソースセンシング手順を実行して、前記送信装置が後の時点でデータを送信するのに使用可能な無線リソースに関する情報を取得するステップと、
    データが送信に利用可能となった後、前記データが送信に利用可能となる前にセンシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づいて、自律的な無線リソース割当てを実行することにより、前記データの最初の送信の実行に用いられる送信ウィンドウ内で時間−周波数無線リソースを選択するステップと、
    データの１回または複数回の送信を実行する送信タイミングをそれぞれ示す複数のデータ送信タイミングパターンのうちの１つを決定するステップと、
    前記選択した時間−周波数無線リソースを用いて前記最初のデータ送信を実行し、前記最初のデータ送信に関して前記決定したデータ送信タイミングパターンにより規定された送信タイミングで前記１回または複数回のデータ再送信を実行するステップと、
    を含む、方法。
13. 前記複数のデータ送信タイミングパターンが、異なる回数のデータ送信を示しており、前記方法が、データ送信タイミングパターンのうち、前記データに関して実行される合計回数の送信に対応する１つのデータ送信タイミングパターンを決定することを含み、任意選択で、前記データに関して実行される前記合計回数の送信が、前記送信装置により決定されるか、または、事前設定され、
    任意選択で、前記１回または複数回のデータ再送信が、前記１つの決定したデータ送信タイミングパターンの長さにより規定された期間内に実行され、
    任意選択で、前記データ送信タイミングパターンが、前記送信装置によって、ランダムに決定されるか、または、前記センシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づいて決定される、
    請求項１２に記載の方法。
14. 前記最初のデータ送信に関して前記選択した時間−周波数無線リソースを示し、前記決定したデータ送信タイミングパターンを識別するスケジューリング割当てを送信するステップをさらに含む、
    請求項１２または１３に記載の方法。
15. 前記決定したデータ送信タイミングパターンが、１回のデータ送信のみを示しており、前記方法が、
    前記最初のデータ送信のタイミングに関して前記送信ウィンドウ内で前記決定されたデータ送信タイミングパターンを複数回繰り返した後、繰り返すデータ送信タイミングパターンごとに前記１回の指定されたデータ送信により与えられるタイミング位置を識別することによって、前記１回または複数回のデータ再送信を実行する前記送信ウィンドウ内でデータ再送信候補を決定するステップと、
    任意選択で前記データに関して実行される合計回数の送信であり、前記プロセッサにより決定されるか、または、事前設定された、合計回数の送信に応じて、前記１回または複数回のデータ再送信の実行に用いられるデータ再送信候補を決定するステップと、
    を含み、
    任意選択で、前記方法が、前記センシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づいて、前記データ送信タイミングパターンと、前記データ再送信に用いられる前記データ再送信候補を決定するステップを含む、
    請求項１２に記載の方法。
16. 前記１回または複数回のデータ再送信が、前記最初のデータ送信に用いられたのと同じ周波数無線リソースまたは周波数ホッピングパターンに基づいて前記最初のデータ送信に用いられた周波数無線リソースから決定された周波数無線リソースを用いて実行され、
    任意選択で、前記方法が、前記１回または複数回のデータ再送信に関して、前記センシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づいて、前記最初のデータ送信と同じ周波数無線リソースを使用するか、前記周波数ホッピングパターンに従う周波数無線リソースを使用するかを判定するステップを含み、
    任意選択で、前記スケジューリング割当てが、前記送信装置によって、前記１回または複数回のデータ再送信の送信に用いられる周波数無線リソースの決定に周波数ホッピングパターンが用いられるか否かをさらに示す、
    請求項１２〜１５のいずれか一項に記載の方法。
17. 前記決定したデータ送信タイミングパターンが、１回の送信のみを示しており、前記方法が、
    前記１回または複数回のデータ再送信のうちの１回に関して、前記センシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づいて、前記最初のデータ送信タイミング後の好適な送信タイミングを決定するステップと、
    前記最初のデータ送信のタイミングに関して前記送信ウィンドウ内で前記データ送信タイミングパターンが複数回繰り返される場合に、前記データ送信タイミングパターンの前記１回の指定されたデータ送信が前記決定した好適な送信タイミングと一致するように、前記データ送信タイミングパターンを決定するステップであり、
    前記データ送信タイミングパターンを繰り返した後、繰り返すデータ送信タイミングパターンごとに前記１回の指定されたデータ送信により与えられるタイミング位置を識別することによって、前記データ再送信のうちの１回または複数回を実行する前記送信ウィンドウ内でデータ再送信候補が規定される、ステップと、
    任意選択で前記センシングウィンドウにおいて前記リソースセンシング手順により取得された前記情報に基づき、前記データに関して実行される合計回数の送信であり、前記送信装置により決定されるか、または、事前設定された、合計回数の送信に応じて、残りのデータ再送信の実行に用いられるデータ再送信候補を決定するステップと、
    前記決定した好適な送信タイミングで１回のデータ再送信を送信し、使用が決定された前記再送信候補で前記残りのデータ再送信を送信するステップと、
    を含む、
    請求項１２に記載の方法。
18. 前記送信部により送信されたスケジューリング割当てが、任意選択で前記最初のデータ送信の前記周波数無線リソースに関するオフセットとして、前記好適な送信タイミングで前記データ再送信の前記周波数無線リソースを示しており、
    任意選択で、前記残りのデータ再送信が、前記最初のデータ送信に用いられたのと同じ周波数無線リソースもしくは前記好適な送信タイミングでの前記データ再送信に用いられたのと同じ周波数無線リソースを用いて実行されるか、または、前記残りのデータ再送信が、前記最初のデータ送信に用いられた前記周波数無線リソースもしくは前記好適な送信タイミングでの前記データ再送信に用いられた前記周波数無線リソースから周波数ホッピングパターンに基づいて前記プロセッサにより決定された周波数無線リソースを用いて実行され、前記スケジューリング割当てが、前記送信装置によって、前記１回または複数回のデータ再送信の送信に用いられる周波数無線リソースの決定に周波数ホッピングパターンが用いられるか否かをさらに示す、
    請求項１７に記載の方法。
19. 前記最初のデータ送信に関して前記選択した時間−周波数無線リソースを示すとともに前記決定したデータ送信タイミングパターンを識別するスケジューリング割当てを送信するステップをさらに含み、
    前記スケジューリング割当てが、前記複数の繰り返すデータ送信タイミングパターンのうち、前記１回または複数回のデータ再送信を実行する前記送信タイミングを規定するデータ送信タイミングパターンをさらに示しており、任意選択で、前記データ送信タイミングパターンの指定が、ビットマップとして符号化されており、前記ビットマップのビットがそれぞれ、前記複数の繰り返すデータ送信タイミングパターンのうちの１つと関連付けられた、
    請求項１５〜１８のいずれか一項に記載の方法。
20. 前記データ送信タイミングパターンが、複数ビットの長さを有しており、前記データ送信タイミングパターンの各ビットが、前記各ビットの位置と関連付けられた送信タイミングで前記データの送信が実行されるか否かを示しており、
    任意選択で、前記データ送信タイミングパターンが、前記最初のデータ送信も示すか、または、示すことのないように、前記最初のデータ送信に関して前記タイミングウィンドウに位置決めされた、
    請求項１２〜１９のいずれか一項に記載の方法。
21. データリソースプールが、前記送信装置がデータ送信を実行するのに利用可能な複数の時間−周波数無線リソースを含み、前記データリソースプールが、最初のデータ送信の実行に利用可能な時間−周波数無線リソースおよびデータ再送信の実行に利用可能な時間−周波数無線リソースに分割されており、
    前記方法が、前記自律的な無線リソース割当てにおいて、最初のデータ送信の実行に利用可能な前記時間−周波数無線リソースのうち、前記最初のデータ送信の実行に用いられる時間−周波数無線リソースを選択するステップを含み、
    任意選択で、前記データリソースプールの前記複数の時間−周波数無線リソースが、時間領域において、最初のデータ送信およびデータ再送信用の時間−周波数無線リソース間で分割されており、
    任意選択で、前記データリソースプールの前記分割が、事前設定されているか、または、前記送信装置を制御する無線基地局により設定された、
    請求項１２〜２０のいずれか一項に記載の方法。

Images