特許 6709291 車両用通信のための改善された無線リソース割当て

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

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

(11)【特許番号】6709291

(24)【登録日】2020年5月26日

(45)【発行日】2020年6月10日

(54)【発明の名称】車両用通信のための改善された無線リソース割当て

(51)【国際特許分類】

   H04W 72/04 20090101AFI20200601BHJP

   H04W 92/18 20090101ALI20200601BHJP

   H04W 4/40 20180101ALI20200601BHJP

   H04W 72/02 20090101ALI20200601BHJP

【ＦＩ】

   H04W72/04 131

   H04W92/18

   H04W4/40

   H04W72/02

【請求項の数】23

【全頁数】52

(21)【出願番号】特願2018-549795(P2018-549795)

(86)(22)【出願日】2016年3月25日

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

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

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

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

(87)【国際公開日】20170928

【審査請求日】2019年1月18日

(73)【特許権者】

【識別番号】514136668

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

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

(74)【代理人】

【識別番号】110002952

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

(72)【発明者】

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

(72)【発明者】

【氏名】ロアー ヨアヒム

(72)【発明者】

【氏名】鈴木 秀俊

(72)【発明者】

【氏名】ワン リレイ

【審査官】 久松 和之

(56)【参考文献】

【文献】 国際公開第２０１０／１１３２１９（ＷＯ，Ａ１）

【文献】 独国特許出願公開第１０２００９００８２４１（ＤＥ，Ａ１）

【文献】 Intel Corporation，Support of geo-based transmission schemes for V2V communication，3GPP TSG RAN WG1#84 R1-160431，２０１６年 ２月 ６日

【文献】 Beijing Xinwei Telecom Techn.，Discussion on enhancement of V2X resource allocation，3GPP TSG RAN WG1#83 R1-157534，２０１５年１１月２４日

【文献】 LG Electronics，Discussion on enhancement for PC5 based V2V resource allocation，3GPP TSG RAN WG1#83 R1-157435，２０１５年１１月２４日

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

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

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

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

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

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

【請求項1】

通信システムにおいて少なくとも１つの第２の移動端末と通信するために無線リソースを決定する車両用移動端末であって、
プロセッサを含み、前記プロセッサは、
前記車両用移動端末の位置に基づいて無線リソースを決定するか否かを、前記通信システムのエンティティから受信する情報に基づいて判断し、
前記無線リソースが前記車両用移動端末の位置に基づいて選択される場合、前記車両用移動端末の位置を決定し、
前記車両用移動端末の前記決定された位置に基づいて、少なくとも前記第２の移動端末との通信のための無線リソースを決定する、
車両用移動端末。

【請求項2】

前記通信システムにおいて前記エンティティから前記車両用移動端末が受信する前記情報は、
・ 前記車両用移動端末が位置する無線基地局のセル内で該無線基地局によってブロードキャストされたシステム情報において提供される情報であって、前記無線リソースを決定することが前記車両用移動端末の位置に基づくべきか否かを示すフラグである情報、または
・ 前記車両用移動端末の位置を決定する際または前記無線リソースを決定する際に前記車両用移動端末が使用するパラメータに関する情報である、
請求項１に記載の車両用移動端末。

【請求項3】

前記プロセッサは、前記車両用移動端末の地理的座標を決定することによって、および／または、
前記車両用移動端末が位置する道路の区画を識別することによって前記車両用移動端末の位置を決定する、
請求項１または２に記載の車両用移動端末。

【請求項4】

前記車両用移動端末が位置する前記道路の区画の識別することは、
・ 前記車両用移動端末の地理的座標を決定すること、および
・ 前記車両用移動端末の前記決定された地理的座標と道路が分割された複数の区画との関連に基づいて前記道路の区画を決定することを含む、
請求項３に記載の車両用移動端末。

【請求項5】

前記無線リソースを決定することは、前記車両用移動端末の前記決定された位置に関連付けられた無線リソースプール内に定義された無線リソースの中から前記車両用移動端末が無線リソースを選択することを含む、
請求項１〜４のいずれか一項に記載の車両用移動端末。

【請求項6】

前記車両用移動端末には、複数の無線リソースプールが設定されており、前記複数の無線リソースプールは、それぞれ、前記車両用移動端末が位置することができる異なる位置に関連付けられており、前記複数の無線リソースプールの設定は、システム情報として、または車両用移動端末への専用メッセージ内で前記車両用移動端末に送信され、
前記複数の無線リソースプールおよび前記複数の無線リソースプールのそれぞれの中の各無線リソースに関する明示的情報を提供することによって、またはどのように無線リソースが前記複数の無線リソースプールに分割されているかを定義する規則に基づいて、前記複数の無線リソースプールが、前記車両用移動端末に設定されている、
請求項５に記載の車両用移動端末。

【請求項7】

前記無線リソースを決定することは、
・ 前記車両用移動端末が位置する前記セルを制御する無線基地局に無線リソースを要求すること、
・ 前記車両用移動端末の前記決定された位置に関する情報であって、前記車両用移動端末が位置する道路の区画の地理的座標または識別子である情報を前記無線基地局に送信すること、および、
・ 少なくとも前記第２の移動端末との通信に使用される無線リソースのインジケーションを前記無線基地局から受信することを含む、
請求項２に記載の車両用移動端末。

【請求項8】

前記プロセッサは、無線リソースを決定する際、無線リソース候補が他の移動端末によって使用されているかまたは使用されるかを判断し、前記プロセッサは、前記無線リソース候補が他の移動端末によって使用されているかまたは使用される場合に、これらの無線リソースを決定せずに、異なる無線リソースを決定する、
請求項１〜７のいずれか一項に記載の車両用移動端末。

【請求項9】

前記無線リソースを決定することは、前記車両用移動端末の前記決定された位置に関連付けられた無線リソースプール内に定義された無線リソースの中から前記車両用移動端末が無線リソースを選択することを含み、前記プロセッサは、他の端末によって使用されていないかまたは使用されない無線リソース候補が前記関連付けられた無線リソースプール内で選択可能でない場合に、前記車両用移動端末の位置以外の他の位置に関連付けられた他の無線リソースプールから無線リソースを選択し、該他の位置は、前記車両用移動端末の位置の近傍である、
請求項８に記載の車両用移動端末。

【請求項10】

前記車両用移動端末の位置は、前記車両用移動端末が位置する道路を覆う格子に基づいており、前記車両用移動端末が位置する道路の部分は、複数の区画に分割されており、前記複数の区画は、それぞれ、前記道路の全車線に亘り、
前記複数の区画は、すべて、複数の重複しない同一の小区画に細分されており、前記複数の小区画は、それぞれ、前記道路の車線の少なくとも１つに亘り、
前記複数の小区画は、それぞれ、無線リソースプールに関連付けられている、
請求項１〜９のいずれか一項に記載の車両用移動端末。

【請求項11】

前記複数の小区画と関連付けられた前記無線リソースは、互いに直交しており、また、前記複数の区画および前記複数の小区画は、前記複数の小区画に関連付けられた前記無線リソースによって隣接区画間の干渉が低減される状態になっており、
前記複数の区画を小区画に分割することは、１つの車両用移動端末が各小区画に位置すること、または２つ以上の車両用移動端末が各小区画に位置することを想定している、
請求項１０に記載の車両用移動端末。

【請求項12】

前記車両用移動端末の位置を決定することは、前記車両用移動端末が位置する前記区画のおよび／または前記小区画の識別子を決定することを含む、
請求項１０に記載の車両用移動端末。

【請求項13】

前記プロセッサは、前記車両用移動端末が無線基地局のカバレッジ内にいるか、カバレッジ外にいるかを判断し、カバレッジ外の場合、前記プロセッサは、前記無線リソースが
前記車両用移動端末の位置に基づいては選択されないと判断する、
請求項１〜１２のいずれか一項に記載の車両用移動端末。

【請求項14】

前記通信システムの前記エンティティは、前記車両用移動端末が少なくとも前記第２の移動端末との通信のために使用する無線リソースが、前記車両用移動端末の位置に基づいて決定されるか否かを判断し、該判断の結果に関する情報は、前記通信システムにおける前記エンティティによって前記車両用移動端末に提供され、
前記通信システムの前記エンティティは、前記車両用移動端末が位置する前記セルを制御する無線制御エンティティであるか、または、制御ネットワーク内のエンティティである、
請求項２に記載の車両用移動端末。

【請求項15】

通信システムにおいて少なくとも第２の移動端末と通信するための無線リソースを車両用移動端末が決定することを支援する、前記通信システムにおける無線基地局であって、
無線リソースが前記車両用移動端末の位置に基づいて決定されるか否かを、少なくとも前記無線基地局のセル内の各車両用移動端末に関する情報に基づいて判断するプロセッサと、
前記車両用移動端末が前記車両用移動端末の位置に基づいて無線リソースを決定するか否かを判断する際に準拠する情報を、前記車両用移動端末に送信する送信部と、を備えた、
無線基地局。

【請求項16】

前記情報は、
・ 前記無線基地局のセル内で前記無線基地局によってブロードキャストされるシステム情報において前記車両用移動端末に提供され、前記情報は、前記無線リソースを決定することが前記車両用移動端末の位置に基づくべきか否かを示すフラグである、あるいは、前記車両用移動端末の位置を決定する際または前記無線リソースを決定する際に前記車両用移動端末によって使用されるパラメータとして前記車両用移動端末に提供される、
請求項１５に記載の無線基地局。

【請求項17】

前記送信部が、複数の無線リソースプールに関する情報を車両用移動端末に送信し、かつ、前記複数の無線リソースプールが、それぞれ、前記車両用移動端末が位置することができる異なる位置に関連付けられている結果、前記車両用移動端末は、前記車両用移動端末の位置に関連付けられた無線リソースプール内に定義された無線リソースの中から無線リソースを選択することができ、複数の無線リソースプールに関する前記情報は、システム情報として、または前記車両用移動端末への専用メッセージ内で前記無線基地局によって送信される、
請求項１５または１６に記載の無線基地局。

【請求項18】

前記車両用移動端末によって他の移動端末との通信に使用される無線リソースの要求を前記車両用移動端末から受信するように、また、前記車両用移動端末の位置に関する情報であって、前記車両用移動端末が位置する道路の区画の地理的座標または識別子である情報を受信する受信部を備え、
前記プロセッサは、前記車両用移動端末によって他の移動端末との通信に使用される無線リソースを決定し、
前記送信部は、前記決定された無線リソースに関する情報を前記車両用移動端末に送信する、
請求項１５〜１７のいずれか一項に記載の無線基地局。

【請求項19】

前記車両用移動端末の位置は、前記車両用移動端末が位置する道路を覆う格子（グリッ
ド）に基づいており、前記車両用移動端末が位置する道路の部分は、複数の区画に分割されており、前記複数の区画は、それぞれ、前記道路の全車線に亘り、
前記複数の区画は、すべて、複数の重複しない同一の小区画に細分されており、前記複数の小区画は、それぞれ、前記道路の車線の少なくとも１つに亘り、前記複数の小区画は、それぞれ、無線リソースプールに関連付けられており、
前記送信部が、前記格子、前記複数の区画、および前記複数の小区画に関する情報を前記車両用移動端末に送信する結果、前記車両用移動端末は、当該情報を使用して前記車両用移動端末の位置を区画および／または小区画として決定することができ、
前記無線基地局の受信部は、前記車両用移動端末の位置に関する情報として前記区画のおよび／または前記小区画の識別子を前記車両用移動端末から受信する、
請求項１５〜１８のいずれか一項に記載の無線基地局。

【請求項20】

通信システムにおいて少なくとも１つの第２の移動端末と通信するために無線リソースを決定する車両用移動端末により実行される方法であって、
前記車両用移動端末の位置に基づいて無線リソースを決定するか否かを、前記通信システムのエンティティから受信する情報に基づいて判断することと、
前記無線リソースが前記車両用移動端末の位置に基づいて選択される場合、前記車両用移動端末の位置を決定することと、
前記車両用移動端末の前記決定された位置に基づいて、少なくとも前記第２の移動端末との通信のための無線リソースを決定することと、
を含む、方法。

【請求項21】

通信システムにおいて少なくとも１つの第２の移動端末と通信するために無線リソースを決定する車両用移動端末の処理を制御する集積回路であって、前記処理は、
前記車両用移動端末の位置に基づいて無線リソースを決定するか否かを、前記通信システムのエンティティから受信する情報に基づいて判断することと、
前記無線リソースが前記車両用移動端末の位置に基づいて選択される場合、前記車両用移動端末の位置を決定することと、
前記車両用移動端末の前記決定された位置に基づいて、少なくとも前記第２の移動端末との通信のための無線リソースを決定することと、
を含む、集積回路。

【請求項22】

通信システムにおいて少なくとも第２の移動端末と通信するための無線リソースを車両用移動端末が決定することを支援する、前記通信システムにおける無線基地局により実行される方法であって、
無線リソースが前記車両用移動端末の位置に基づいて決定されるか否かを、少なくとも前記無線基地局のセル内の各車両用移動端末に関する情報に基づいて判断することと、
前記車両用移動端末が前記車両用移動端末の位置に基づいて無線リソースを決定するか否かを判断する際に準拠する情報を、前記車両用移動端末に送信することと、
を含む、方法。

【請求項23】

通信システムにおいて少なくとも第２の移動端末と通信するための無線リソースを車両用移動端末が決定することを支援する、前記通信システムにおける無線基地局の処理を制御する集積回路であって、前記処理は、
無線リソースが前記車両用移動端末の位置に基づいて決定されるか否かを、少なくとも前記無線基地局のセル内の各車両用移動端末に関する情報に基づいて判断することと、
前記車両用移動端末が前記車両用移動端末の位置に基づいて無線リソースを決定するか否かを判断する際に準拠する情報を、前記車両用移動端末に送信することと、
を含む、集積回路。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、車両用移動端末のための改善された無線リソース割当てに関する。本開示は、対応する車両用移動端末、無線基地局、システム、および方法を提供している。

【背景技術】

【0002】

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

【0003】

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

【0004】

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

【0005】

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

【0006】

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

【0007】

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

【0008】

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

【数1】

個のサブキャリアと

【数2】

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

【数3】

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

【数4】

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

【数5】

を満たすものとし、この場合、

【数6】

および

【数7】

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

【数8】

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

【数9】

および

【数10】

である。

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

−ユーザ識別情報：割り当てる対象のユーザを示す。これは、通常、ＣＲＣをユーザ識別情報でマスクすることによってチェックサムに含まれる。

【0034】

−リソース割当情報：ユーザが割り当てられるリソース（例えばリソースブロック（ＲＢ：Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ））を示す。あるいは、この情報はリソースブロック割当て（ＲＢＡ：Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ Ａｓｓｉｇｎｍｅｎｔ）と称される。ユーザを割り当てられるＲＢの数は、動的なものとすることができることに留意されたい。

【0035】

−キャリアインジケータ：第１のキャリア上で送信される制御チャネルが、第２のキャリアに関連するリソース、すなわち第２のキャリア上のリソースまたは第２のキャリアに関連するリソースを割り当てる場合に使用される（クロスキャリアスケジューリング：ｃｒｏｓｓ ｃａｒｒｉｅｒ ｓｃｈｅｄｕｌｉｎｇ）。

【0036】

−変調・符号化方式：採用される変調方式および符号化率を決定する。

【0037】

−ＨＡＲＱ情報：データパケットまたはその一部の再送信時に特に有用である、新規データインジケータ（ＮＤＩ：Ｎｅｗ Ｄａｔａ Ｉｎｄｉｃａｔｏｒ）および／または冗長バージョン（ＲＶ：Ｒｅｄｕｎｄａｎｃｙ Ｖｅｒｓｉｏｎ）など。

【0038】

−電力制御コマンド：割当て対象の、アップリンクデータまたは制御情報送信の、送信電力を調整する。

【0039】

−基準信号情報：割当てに関連して基準信号の送信または受信に使用される、適用されるサイクリックシフトおよび／または直交カバーコードインデックスなど。

【0040】

−アップリンク割当てインデックスまたはダウンリンク割当てインデックス：割当ての順序を識別するために使用され、ＴＤＤシステムにおいて特に有用である。

【0041】

−ホッピング情報：例えば、周波数ダイバーシチを増大させるためにリソースホッピングを適用するかどうか、およびどのようにして適用するかの指示情報。

【0042】

−ＣＳＩ要求：割り当てられたリソースにおいて、チャネル状態情報の送信をトリガするために使用される。

【0043】

−マルチクラスタ情報：シングルクラスタ（連続したＲＢのセット）で送信が発生するか、それともマルチクラスタ（少なくとも２つの不連続な、連続したＲＢのセット）で送信が発生するかを示す、および制御するために使用されるフラグである。マルチクラスタ割当ては、３ＧＰＰ ＬＴＥ−（Ａ）リリース１０によって導入された。

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

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

【0113】

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

【0114】

３ＧＰＰは、Ｖ２Ｘ通信のためのいくつかの潜在的な要件についても合意しており、関連するもののうちのいくつかを以下に示す。

【0115】

［ＣＰＲ−０１１］Ｅ−ＵＴＲＡ（Ｎ）は、１秒・１Ｖ２Ｘエンティティ（例えば、ＵＥおよびＲＳＵ）あたり１０Ｖ２Ｘメッセージの最大頻度をサポートすることができるものとする。

【0116】

［ＣＰＲ−０１５］特定の用途（すなわち、プリクラッシュセンシング）についてのみ、Ｅ−ＵＴＲＡ（Ｎ）は、Ｖ２Ｖサービスをサポートする２つのＵＥ間でＶ２Ｘメッセージを最大遅延２０ｍｓで送信することができるべきである。

【0117】

［ＣＰＲ−０１８］３ＧＰＰネットワークは、Ｖ２Ｘサービスをサポートする加入済のＵＥに対しても、リソース効率の良い方法で、サポートされているいかなる潜在的な精度改善技術（例えば、ＤＧＰＳおよび／またはＯＴＤＯＡ）も利用可能にするべきである。

【0118】

［ＣＰＲ−０２６］３ＧＰＰシステムは、サービス条件（例えば、ＵＥの速度、ＵＥの密集度）に応じて送信レートおよびカバレッジエリアを変化させることができるものとする。

【0119】

［ＣＰＲ−０３０］Ｅ−ＵＴＲＡＮは、Ｖ２Ｖサービスをサポートする最大相対速度２８０ｋｍ／ｈのＵＥ間で、Ｖ２Ｘメッセージを送信することができるものとする。

【0120】

車両用通信は、おそらくＰｒｏＳｅ直接通信に基づく。ただし、通常のリリース１２のＤ２Ｄリソース割当ては、新たなＶ２Ｘ使用のシナリオには不十分かもしれない。特に、上記に説明したように、ランダム化は、Ｄ２Ｄ通信において、具体的には、ＵＥが、通信のための無線リソースを、設定された無線リソースプールから自律的かつランダムに選択する、モード２のために使用される基本原理である。Ｄ２Ｄベースの車両用通信は、例えば、（頻繁に、かつ大量のデータを場合によって送信する車両用アプリケーションに起因して）パケットサイズが増大し得、また、都市シナリオなど、密集したＵＥ配置シナリオでは特に、対象のカバレッジ内に多数のＵＥが存在するため、時間・周波数リソースのコリジョンは、より深刻な問題となり得る。

【0121】

それに応じて、Ｄ２Ｄに基づいた車両用通信のために現在想定されるリソース割当ては、最適ではないかもしれず、新たな使用シナリオに対するさまざまな適合を必要とする。

【先行技術文献】

【非特許文献】

【0122】

【非特許文献1】３ＧＰＰ ＴＳ ３６．２１１，“Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌｓ ａｎｄ Ｍｏｄｕｌａｔｉｏｎ（Ｒｅｌｅａｓｅ ８）”

【非特許文献2】３ＧＰＰ ＴＳ ３６．３２１

【非特許文献3】３ＧＰＰ ＴＳ ３６．２１３

【非特許文献4】３ＧＰＰ ＴＳ ３６．２１２，“Ｍｕｌｔｉｐｌｅｘｉｎｇ ａｎｄ ｃｈａｎｎｅｌ ｃｏｄｉｎｇ”

【非特許文献5】ＴＲ ２３．７１３

【非特許文献6】３ＧＰＰ ＴＳ ３６．３００

【非特許文献7】ＴＳ ２３．３０３

【非特許文献8】ＴＲ ２１．９０５

【発明の概要】

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

【0123】

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

【0124】

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

【0125】

本明細書に記載のいくつかの態様によれば、別の移動端末（車両用移動端末または通常の移動端末の場合も）との通信のために車両用移動端末によって使用されるべき無線リソースの決定が改善されるものとする。

【0126】

これらの態様を論じるために、以下の例示的な想定を行う。他の移動端末と直接通信を行うために適切に、すなわち対応するサイドリンクコネクションを介して通信を行うように、セットアップされている、車両用移動端末が想定される。車両用移動端末は、他の移動端末と通信したいので、前記の点において使用されるべき特定のサイドリンク無線リソースを決定する必要があるということがさらに想定される。

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

【0127】

第１の態様によれば、これらの無線リソースの決定が改善される。具体的には、第１の態様は、２つの異なった無線リソース決定を区別し、１つは車両用移動端末の位置が考慮され、もう１つは車両用移動端末の位置が考慮されない。背景技術のセクションから分かるように、通常のサイドリンクリソース割当て（例えば、モード１およびモード２）は、（車両用）移動端末の位置を考慮せず、例えば、移動端末は、無線リソースプールから無線リソースを自律的に選択し（すなわちモード２）、無線基地局は、移動端末の位置を参照することなく無線リソースを決定する。

【0128】

一方、第１の態様によれば、車両用通信のためのリソース割当ては、車両用移動端末の位置を考慮に入れることによって改善されるものとする。例えば、これは、車両用移動端末に対して通常は利用可能である無線リソースが、車両用移動端末の位置に基づいて「制限される」ように、実施することができる。

【0129】

例示的に、ＵＥ自律的リソース選択（モード２）を想定すると、車両用移動端末が、車両用移動端末の特定の位置と関連付けられている無線リソースプールから無線リソースを選択するように、異なった無線リソースプールを、車両の、可能性のある異なった位置に対して定義することができる。車両用移動端末は、自身の決定された位置に基づいて、さまざまな無線リソースプールの中から自身が自律的に選択できるように、これらの異なった無線リソースプールが設定される。どのようにして車両用移動端末にこれらの異なった無線リソースプールを設定することができるかに関してはいくつかの方法がある。１つの方法によれば、例えば、無線基地局によってそのセルにおいてブロードキャストされるシステム情報内で、または車両用移動端末専用のメッセージ内で、無線リソースプールに関する明示的な情報（無線リソース、および可能性のある、車両用移動端末の位置との関連付けなど）を車両用移動端末に提供することができる。別の実施態様では、異なった無線リソースプールは、車両用移動端末に明示的に通知され得ず、利用可能な無線リソースに関する一般的な情報、および利用可能な無線リソースを車両用移動端末のそれぞれ可能性のある位置に対して車両用移動端末が自力で割り当て、それによって、車両用移動端末が、必要な無線リソースを次いで選択することができる異なった無線リソースプールを定義することができるようにする、一式の規則に基づいて、車両用移動端末自体によって決定し得る。

【0130】

一方、例示的に、ｅＮＢによってスケジューリングされるリソース割当て（すなわちモード１）を想定すると、今度は、車両用移動端末が自身の位置を決定し、それに関する情報を何らかの形で無線基地局に提供し、無線基地局は、次いで、受信した、車両用移動端末の位置情報に基づいて、適切な無線リソースを選択することができる（例えば無線リソースプールからであるが、必ずしもその必要はない）。例えば、無線基地局は、近くにある他の（車両用）移動端末が、車両用移動端末の通信から干渉を受けないような無線リソースを選択することができる。それに応じて、次いで、無線基地局は、車両用移動端末が、他の移動端末との通信のために、決定された無線リソースを使用し得るように、決定された無線リソースについて車両用移動端末に通知する。

【0131】

一般に、位置支援によるリソース割当ては、近隣の車両移動端末が同時に通信を行ったときに、それらの間の干渉を低減するか、または完全に回避するように、互いに直交する無線リソースの割当てを支援するものとする。

【0132】

ただし、この改善されたリソース割当ては、すべての状況において最適ではないかもしれないため、第１の態様に従って選択的に使用されるものとする。より詳細には、通信システム内のいくつかのエンティティ（例えばｅＮＢ、またはＰｒｏＳｅ関連エンティティ、またはＭＭＥ）は、改善された位置支援によるリソース割当てを使用するべきか、それとも車両用移動端末の位置を考慮しない通常のリソース割当てを使用するべきかを制御し得る。このエンティティは、各エリア内の車両数、車両の速度、それぞれのエリアのセルのトポロジ（例えば、幹線道路または都心または地方など）および場合によっては他の情報など、さまざまな異なったパラメータに基づいて決定し得る。例えば、密集していて、ゆっくり動いているトラフィック状況では、エンティティは、車両位置によるリソース割当てを支援しないと決定し得る。例えば、車両位置によるリソース割当ての支援が役に立たないほど、近隣の車両用移動端末のさまざまな位置を区別することが困難であり得る。一方、スムーズに流れている、場合によっては中高速のトラフィックの場合、エンティティは、他の移動端末との通信のために無線リソースを決定するとき、車両位置も考慮するのが有利であると決定し得る。一方、密集したトラフィック状況では、車両の密集度が高い（同じ位置エリア内に、フリーウェイに比べて多くのＵＥがある）ことがリソースに対する需要を押し上げることを考慮して、逆に決定することも可能であり得る。さらには、位置支援によるリソース割当てを使用するべきか、それとも位置支援無しを使用するべきかは、時間にも依存し得、例えば、ピーク時にはトラフィックが通常密集するが、一方で他の時間は、トラフィック状況は異なる。

【0133】

さらに、車両用移動端末は、特定の時点で自身がどのリソース割当て（すなわち、位置支援によってか、または自身の位置を考慮せずにか）を使用することになっているかを何とかして決定できるものとする。その結果、対応する情報が車両用移動端末に提供されなければならず、これは、異なったさまざまな形で行われ得、そのうちの２つの例を以下で簡潔に論じる。可能性のある一実施態様によれば、車両用移動端末は、決定の結果に関する明示的な情報を、例えば、車両位置を使用するか否かを車両用移動端末に命令する、無線基地局のシステム情報の中で無線基地局によってブロードキャストされるフラグによって提供される。可能性のある別の実施態様では、車両用移動端末が、自身の位置を考慮すべきかどうかを、車両用移動端末内に設定されたパラメータから、例えば、この改善された位置支援によるリソース割当てに関連しており、自身の位置を決定するとき、または無線リソースを決定するときに車両用移動端末によって使用されるパラメータから推定することができるようにする。

【0134】

ここまで、第１の態様を、車両用移動端末の位置に関連して一般論として記載した。ただし、どのようにして車両用移動端末の位置を決定して表すことができるかに関してはいろいろな方法がある。可能性がある１つの方法は、例えば、通常ＧＰＳから分かる、緯度および経度などの地理的座標を使用することである。第１の態様の改善によれば、車両用移動端末の位置は、車両用移動端末が現在走行している道路の区画および／または小区画として決定される。そのため、この意味において、各道路には、対応するＩＤ、例えば、道路名もしくはストリート名、および／または番号および対応する開始・終了位置がある。また、地図に関する情報が車両用ＵＥに利用可能であり、その情報は、特定の道路の端についての情報も含み得る。具体的には、道路は、区画および／または小区画に分割され、したがって、実際に、車両用移動端末の位置が、地理的座標を使用する代わりに道路の区画および／または小区画のＩＤによって単純に表すことができるようにしている。それに応じて、車両用移動端末は、自身の位置を道路の区画として決定する（これには、車両用移動端末が、地理的座標をまず決定し、次いで、これらの地理的座標を、自身が位置している、可能性のある道路の区画／小区画に変換することがまだ必要であり得る）。このことは、送信される必要がある情報量をこのように減少させることができるので、決定された、車両用移動端末の位置の情報が、無線基地局に送信されるべき場合（例えば、無線基地局が無線リソースを決定する、モード１リソース割当てにとって）にも有利である。

【0135】

道路の例示的な分割は、道路を覆う格子に基づいており、したがって格子が区画を定義し、次いで、区画は小区画にさらに細分される。例えば、各区画は、道路のすべての車線をカバーし得、道路の特定の長さにわたり得る。次いで、この区画は、複数の小区画に分割され、例えば、１つの小区画は、すべての車線ではなく、道路の１または複数の車線のみをカバーし得る。小区画は、区画と同じ、道路の長さにわたり得るか、または区画の一部分のみにわたり得る一方で、区画の長さの残りは、他の小区画によって「カバーされる」。さらには、同じかまたは同様の特性の特定のエリア内において、各区画は、区画から区画へと道路に沿って格子が繰り返されるように、同じ複数の小区画にセットアップ（すなわち分割）されるものとする。

【0136】

区画および小区画におけるこの分割は、あらゆる区画に対して、区画内の位置（すなわち、車両の可能な位置としての小区画）と当該の小区画内に位置する車両用移動端末に利用可能な特定の無線リソースとの間の同じ関係付けを繰り返し得る。各区画内で、区画の複数の小区画の間の利用可能な無線リソースの分配は、干渉が軽減または回避されるようなものとする。例えば、区画内の小区画と関連付けられたさまざまな無線リソースは、互いに直交するものとする。さらには、区画および小区画、ならびに、それらの関連付けられた（直交）無線リソースは、それら自身を繰り返すため、隣接する区画において通信する車両用移動端末に起因する干渉も、軽減または回避されるはずである。

【0137】

第１の態様のさらなる改善によれば、リソース割当ては、無線リソース候補が別の移動端末によって使用されているかどうか、または使用されるかどうかを判断するように、センシング能力を車両用移動端末に実装することによってさらに改善され、使用されているかまたは使用される場合、可能であればこれらの無線リソース候補はブロックされ、使用されるべきではない。具体的には、ＵＥ自律無線リソース選択（モード２）を例示的に想定して、車両用移動端末は、自身の位置に関連付けられた無線リソースプールから無線リソースを実際に選択する前に、これらの無線リソース候補（すなわち、車両用移動端末によって選択される過程にある）が、別の移動端末によって実際既に使用されているかどうかを判断する。例えば、車両用移動端末は、例えば、ＲＳＳＩ（受信信号強度表示：Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｉｏｎ）測定を使用してこれを判断することができ、ＲＳＳＩ測定で、車両用移動端末は、候補の（時間周波数）リソース、例えばＰＲＢペアの、対応するリソースエレメント（ＲＥ：Ｒｅｓｏｕｒｃｅ Ｅｌｅｍｅｎｔ）上の合計の受信信号強度（送信されたエネルギの測定値）を測定する。ＲＳＳＩが一定の閾値よりも大きい場合、車両用移動端末は、前記のリソースが占有されていると推定する。また、車両用移動端末は、一定の時間（例えば、ＴＴＩ数）、前記リソースが「ｂｕｓｙ（ビジー）」のままになると、統計的に推定し得る。この統計的推定は、同じかまたは隣接するプール内のリソースの過去の「ｂｕｓｙ−ｎｅｓｓ（忙しさ）」のＵＥでの実装に基づくことができるか、またはネットワークによって例えばＲＲＣシグナリング（ブロードキャストまたは専用の）内でシグナリングすることができる。例えば、「ｂｕｓｙ−ｎｅｓｓ（忙しさ）」の２は、観測インスタンスの後、２制御／データサイクルの間、平均して、リソースが「ｂｕｓｙ」のままであることを意味する。

【0138】

代替的または追加的な方法によれば、個々の候補のＳＡメッセージ（ＰＳＣＣＨ）が受信され、および復号化され、車両用移動端末は、やってくる制御／データサイクルにおける何らかの将来の「ｂｕｓｙ−ｎｅｓｓ」をこれらが示しているかどうかをチェックすることができる。個々の候補のＳＡが現在送信されていない場合、車両用ＵＥは、制御（ＳＡ）および対応するデータリソースを「フリー」であると想定することができる。ＳＡメッセージ内の「ｂｕｓｙ−ｎｅｓｓ」は、車両用ＵＥが、対応する制御／データリソース上で送信し続けようとする、対応するＢｕｓｙ−ｎｅｓｓの期間も示し得る。最も単純な形では、それは「ｂｕｓｙ−ｎｅｓｓ」期間を１サイクルまたは何か他の「固定」数のサイクルとして示すブール値となる。

【0139】

次いで、潜在的に選択されるべき無線リソースが別の移動端末によってブロックされているような場合は、車両用移動端末は、異なった無線リソースを選択するものとする。

【0140】

さらには、車両用移動端末の位置に関連付けられた無線リソースプールから他のリソースを選択できない場合（例えば、上記で説明したブロックによっては）、車両用移動端末は、別の無線リソースプール、すなわち、車両用移動端末の位置ではない位置に関連付けられた無線リソースプールから無線リソースを選択することができるものとする。例えば、この、他の無線リソースプールは、車両用移動端末の実際の位置の隣の位置に関連付けられているものとすることができ、あるいは、他の無線リソースプールは、車両用移動端末の実際の位置から離れているか、または最も遠く離れている位置に関連付けられているものとすることができる。代替的に、または上記に加えて、小区画の、車両用移動端末が位置する小区画からの距離に基づいて、異なった相対的優先度を、さまざまな小区画および関連付けられた無線リソースに与えることができる。例えば、車両用移動端末が、最も高い（残っている）優先度の小区画（すなわち、移動端末が位置する小区画の隣の小区画）と関連付けられた別の無線リソースプールから無線リソースを選択するように、距離の増加とともに優先度が減少する。

【0141】

車両用移動端末が無線リソース候補を実際に使用する前にそれらのセンシングを行う、この追加の改善は、こうした無線リソースのコリジョンが起こる可能性が高いシナリオにおいて特に有利である。例えば、道路は区画および／または小区画に分割でき、各小区画は、（関連付けられた場所に位置する）車両用移動端末がそこから適切な無線リソースを選択できる、特定の一式のリソース（例えばリソースプール）と関連付けられていることを上記で論じた。区画および／または小区画が実際にどのようにしてセットアップされるかに応じて、小区画は、その中に、１つのみの、または２つ以上の車両用移動端末が同時に位置することができ、したがって同じ関連付けられた無線リソースを使用し得る、エリアをカバーし得る。第１の態様の改善された実施態様について上記に説明したセンシングは、無線リソースが既にブロックされているかどうかを、別の移動端末との通信にこれらの無線リソースを実際に使用する前にまず判断することによって、こうした無線リソースのコリジョンを回避することができる。

【0142】

第２の態様は、上記で論じた第１の態様と異なっているが、それによれば、同様に、車両用移動端末による無線リソースの決定が改善される。第２の態様も、２つの異なった無線リソース決定を区別するが、ただし、この場合には、１つの無線リソース割当ては、無線リソースが別の移動端末によって使用されているかどうか、または使用されるかどうかをセンシングする追加の過程を含み、一方で、他方の無線リソース割当ては、追加のセンシング手順を含まない。

【0143】

センシングは、第１の態様の位置支援による無線リソース決定に対するさらなる改善として上記で既に論じているが、第２の態様に係る、独立した改善と見なされる。上記で説明したように、センシングは、車両用移動端末が、無線リソース候補が別の移動端末によって使用されているかどうか、または使用されるかどうかを判断する能力として理解されるものとする。これらの無線リソース候補が別の（車両用）移動端末によってブロックされる場合には、車両用移動端末は、コリジョンを回避するために、それらを使用しないと決定し得、むしろ異なった無線リソースの決定に進み得る。

【0144】

センシングは、無線リソースがブロックされているか否かを判定する方法に関して少なくとも２つの異なった方法を伴い得る。第１の方法によれば、受信信号強度が閾値よりも大きい場合には、無線リソースがブロックされることを最終的に考慮するために、対応する無線リソース（例えば、候補のＰＲＢペアのリソースエレメント）上の受信信号強度が、車両用移動端末によって測定され、閾値と比べられる。その結果、車両用移動端末は、無線リソース候補がこの特定の瞬間に別の移動端末によって使用されているか否かを判断することができる。

【0145】

上記に加えて、または代替として、車両用移動端末は、Ｄ２Ｄ送信手順の一環として別の移動端末によって送信されるＳＡ（スケジューリング割当て：Ｓｃｈｅｄｕｌｉｎｇ ａｓｓｉｇｎｍｅｎｔ）メッセージをモニタし得る。ＳＡメッセージは、関連付けられたデータメッセージを（同じかまたは後のサブフレームにおいて）送信するために使用される特定の無線リソースを示す。その結果として、車両用移動端末は、このように、これらの移動端末によって将来どの無線リソースが使用される可能性が高いのか、ひいては、使用をブロックされる可能性が高いのかをＳＡメッセージから学習することができる。

【0146】

センシングは、モード１（ｅＮＢによってスケジューリングされる）またはモード２（ＵＥ自律的）に従って、無線リソースを決定するとき、車両用移動端末によって行うことができる。具体的には、モード２のＵＥ自律的リソース割当てを想定して、車両用移動端末は、適切な無線リソースプールから無線リソースを実際に使用する前に、センシングを行うものとする。例えば、車両用移動端末は、無線リソースプールから潜在的な一式のリソースをまず選択し得、次いで、これらの選択されたリソースが別の移動端末によってブロックされているか否かをセンシングし得、その後、車両用移動端末が、無線リソースプール内でフリーの、すなわち、別の移動端末によってブロックされていない無線リソースを見つけるまで、この手順を繰り返し得る。一方、潜在的な一式のリソースを選択する前からでも、車両用移動端末は、無線リソースプールの、可能性のあるすべての無線リソースについてセンシングを行い得、次いで、ブロックされている無線リソースを無線リソースプールから無視する。続いて、車両用移動端末は、無線リソースプール内に残っているフリーの無線リソースのうちから無線リソースを選択し得る。

【0147】

第２の態様に対するさらなる改善として、無線リソース割当ては、第１の態様について詳細に説明したように、車両用移動端末の位置を追加で考慮することによって改善することができる。繰り返しを避けるため、車両用移動端末がどのようにして自身の位置を決定し、無線リソースを決定するときに同位置を考慮するのか、車両用移動端末の位置をモード１およびモード２無線リソース割当てにおいてどのようにして使用することができるのか、どのようにして、位置を、地理的座標、または道路が分割される区画および／または小区間を示す識別子とすることができるのかなどを論じている第１の態様の上記一節を参照する。

【0148】

それに応じて、１つの一般的な第１の態様では、本明細書で開示される技術は、通信システム内の少なくとも第２の移動端末と通信するために無線リソースを決定するための車両用移動端末を特徴としている。車両用移動端末のプロセッサは、車両用移動端末の位置に基づいて無線リソースを決定するべきか否かを決定し、決定は、通信システムのエンティティから受信した情報に基づく。無線リソースが、車両用移動端末の位置に基づいて選択されるべき場合、プロセッサは、車両用移動端末の位置を決定し、車両用移動端末の決定された位置に基づいて、少なくとも第２の移動端末との通信のための無線リソースを決定する。

【0149】

それに応じて、１つの一般的な第１の態様では、本明細書で開示される技術は、通信システムにおいて少なくとも第２の移動端末と通信するために無線リソースを車両用移動端末が決定することを支援するための、通信システム内の無線基地局を特徴としている。無線基地局のプロセッサは、無線リソースが車両用移動端末の位置に基づいて決定されるべきか否かを決定する。決定は、少なくとも、無線基地局のセル内の車両用移動端末に関する情報に基づく。無線基地局の送信部は、車両用移動端末が車両用移動端末の位置に基づいて無線リソースを決定するべきか否かを判断する際に準拠する情報を、車両用移動端末に送信する。

【0150】

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

【0151】

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

【0152】

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

【図面の簡単な説明】

【0153】

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

【図2】３ＧＰＰ ＬＴＥ（リリース８／９）において定義されているサブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドを示している。

【図3】ＰｒｏＳｅ通信のためにＰＣ５を通じたレイヤ２リンクを確立する方法を模式的に示している。

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

【図5】２つのＵＥのためのスケジューリング割当ておよびＤ２Ｄデータの送信を示している。

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

【図7】ｅＮＢによってスケジューリングされるスケジューリングモード１のためのＤ２Ｄ通信タイミングを示している。

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

【図9】実施形態に係る、道路の、小区画および区画への異なった分割を例示的に示している。

【図10】第１の実施形態に係る、車両用ＵＥの動作についてのシーケンス図を例示的に示している。

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

【0154】

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

【0155】

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

【0156】

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

【0157】

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

【0158】

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

【0159】

本願を通して使用されている用語「道路」は、幹線道路、自動車道路、小道、街道、ストリート、アベニュを含んで、車両が走行できるいかなる区画の土地もカバーするものとして広義に理解されるべきである。

【0160】

背景技術のセクションで説明したように、３ＧＰＰは、ＬＴＥ支援（ＬＴＥ−ａｓｓｉｓｔｅｄ）の車両用通信のための新たな検討項目を導入しており、それは、モード１およびモード２に係るリソース割当てを含む、ＰｒｏＳｅ手順に基づくものとしている。ただし、ＰｒｏＳｅに基づくリソース割当ては、Ｖ２Ｘ通信のためのすべての要件を満たすために十分ではないかもしれず、したがって、適合される必要があり得る。

【0161】

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

【0162】

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

【0163】

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

【0164】

さらには、上述のとおり、以下の実施形態は、３ＧＰＰ ＬＴＥ−Ａ（リリース１２／１３）の環境において実施され得るが、場合によっては将来のリリースの環境においても実施され得る。さまざまな実施形態は、車両用移動端末のための改善されたリソース割当てを主に提供する。そのため、他の機能性（すなわち、さまざまな実施形態によって変化しない機能性）は、技術背景のセクションで説明したのとまったく同じままであり得るか、またはさまざまな実施形態に対していかなる結果ももたらさずに変更され得る。これは、例えば、決定された（サイドリンク）無線リソースの実際の使用すなわち、無線リソースが選択された後、および車両用ＵＥがデータの送信（場合によっては、スケジューリング割当ての送信も含む）を行うためにそれらを使用することに関する他の手順を含む。

【0165】

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

【0166】

例示的に、車両に実装され、本願の背景技術のセクションで説明したＤ２Ｄの枠組みに基づいて車両用通信を実行することができる車両用ＵＥが想定されている。車両用ＵＥは、他のＵＥと通信するものとし、したがって、前記目的のために使用されるべき適切なサイドリンク無線リソースをまず決定する必要があるということがさらに想定されている。第１の実施形態は、決定された無線リソースを使用してその後に通常の方法で他の（車両用）ＵＥと通信することができるように、どのようにして、車両用ＵＥによってこのようなサイドリンク無線リソースを効率よく決定することができるかに重点を置いている。

【0167】

第１の実施形態に係る無線リソース割当ては、Ｄ２Ｄ通信のために既に定義されたような無線リソース割当てに基づいており、したがって一般に、背景技術のセクションで詳細に説明したように、モード１リソース割当てとモード２リソース割当てとを区別する。ただし、モード１およびモード２リソース割当てとは独立して、第１の実施形態は、以下に説明するように互いに異なる、２つの異なった無線リソース割当てを追加的に区別する。２つの無線リソース割当てのうちの１つは、Ｄ２Ｄ通信について背景技術のセクションで詳細に説明した共通無線リソース割当てであるとし、それから明らかなように、車両用（ＵＥ）の位置は、モード１またはモード２リソース割当て手順においてどの無線リソースが決定されるかに影響しない。一方、第１の実施形態に係る第２の無線リソース割当ても、Ｄ２Ｄ通信のための無線リソース割当てに基づくが、以下でより詳細に説明するように、無線リソースを決定するときに車両用ＵＥの位置を追加で考慮する。

【0168】

車両用ＵＥは、上述の２つの無線リソースの方法のうちの１つに従って無線リソースを決定するものとし、したがって、自身がどのリソース割当てを使用するかを通知／命令されなければならない。どのリソース割当ての方法を使用するべきかについて車両用ＵＥに通知するこのステップは、コアネットワーク内のｅＮｏｄｅＢ、ＭＭＥ，またはＰｒｏＳｅ関連のエンティティなどの、モバイル通信システム内の適切なエンティティによって実行され得る。このエンティティは、どのリソース割当て方法を使用するべきかを決定する役割も担い得、また、ＵＥに、自身がどのリソース割当て方法を使用するかを知らせる役割も担い得る。説明を簡単にするため、以下では、決定し、および車両用ＵＥに通知する役割を担うエンティティはｅＮｏｄｅＢであると例示的に想定されている。

【0169】

車両用ＵＥが、この第１の実施形態によって導入される改善されたリソース割当て方法を使用するべきであると想定すると、車両用ＵＥは、自身の位置を決定し、次いで、車両用ＵＥの決定された位置に基づいて無線リソースを決定するものとする。

【0170】

一方、車両用ＵＥが、改善された位置支援によるリソース割当て方法を使用するべきではなく、Ｄ２Ｄについて上記で説明した、通常のリソース割当て方法を使用するべきであると想定すると、無線リソース決定のために車両用ＵＥが自身の位置を決定する必要はない。むしろ、車両用ＵＥは、別のＵＥとの通信のための適切な無線リソースを、通常の方法でモード１またはモード２に従って決定する。

【0171】

上記で広く示したように、この第１の実施形態で導入された改善された位置支援によるリソース割当て方法は、ｅＮｏｄｅＢなどの、モバイル通信システム内のエンティティの制御下で選択的に使用されるものとする。それに応じて、車両位置も考慮するリソース割当ては、すべての状況で適用されるわけではなく、十分な利益をもたらすときに適用できるのみである。

【0172】

一般に、リソース割当て過程において車両用ＵＥの位置を追加で考慮することには、以下の利益があることに留意すべきである。リソース割当てのベースとして位置を使用することによって、ネットワークが、トラフィック統計に基づいてＶ２Ｘ通信のために異なった量のリソースを、例えば、よりトラフィック密度が高い位置でのＶ２Ｘ通信のためにはより多いリソースを、およびトラフィックがまばらなエリアでのＶ２Ｘ通信のためにはより少ないリソースを、割り当てることができるようにする。さらには、後に論じる、第１の実施形態の特別な実施態様については、位置、および対応するリソースを有することは、車両用ＵＥが、利用可能なリソースプールの限られた部分のみをセンシングすることを要求する。例えば、最大３２個のリソースプールが設定されており、それらのうちの２つのみが車両用ＵＥの位置に属している場合、これら２つのリソースプール内でセンシングを行う必要があるのみである。これは、時間だけでなくバッテリも節約する。

【0173】

一方、車両用ＵＥの位置を決定すること、および場合によってはそれに関する情報を無線リソース割当てのためにｅＮＢに送信することには、車両用ＵＥに自身の位置を繰り返し追跡することを要求する不利益、およびリソース割当てを支援するためにこの位置に関してｅＮＢに知らせるために無線リソースを消費する不利益がある。位置支援によるリソース割当てによってもたらされる利益と不利益とは、バランスを取る必要がある。その結果として、第１の実施形態は、特定の状況に対して、改善された位置支援によるリソース割当て方法を選択的に使用するが、他の方法には使用しない。

【0174】

図１０は、第１の実施形態について上記に説明した、車両用ＵＥの動作を例示的に示す、車両用ＵＥについてのシーケンス図である。

【0175】

以下に、さらなる利点を提供し得る、第１の実施形態のより具体的な実施態様を説明する。

【0176】

第１の実施形態の上記の広範な説明は、一方のリソース割当て方法を使用するべきかそれとも他方を使用するべきか、すなわち、車両用ＵＥの位置を追加で考慮するべきか否か、に関して選択的に決定するエンティティ（例えばｅＮＢ）に関与する。上記に説明したように、リソース割当てのために車両位置を追加で考慮することによって、特に特定のシナリオにおいて利益をもたらすことができる。それに応じて、ｅＮＢは、その決定の基礎を、これらの異なった状況を区別することができるようにする適切な情報に置くことができる。この情報は、例えば、次のうち、すなわち、特定のエリア内の車両数、車両の速度および／または方向、特定のエリア内のトラフィック状況（例えば、トラフィック密度が高いかまたはトラフィックがスムーズに流れているか、トラフィックが渋滞しているかどうか）、特定のエリアのセルトポロジ（例えば、幹線道路、都心、または地方）、トラフィック状況は日内で変化し得るため１日のうちの時間、に関する情報のうちの少なくとも１つを含み得る。第１の実施形態の特定の実施態様については、この決定のために重要であり得る他の情報は、後に詳細に説明するように、どのようにして道路が区画および／または小区画に分割されるかに関する情報を含み得る。それに応じて、ｅＮＢは、無線リソースを決定するときに特定の車両用ＵＥが自身の車両位置を使用することとするのか否かに関して決定するとき、道路の、小区画および区画への特定の分割も考慮し得る。

【0177】

どのようにして、こうした決定を行うことができるのかを理解するために、以下の２つの例を提供する。例えば、車両が並んで位置しており、その結果、これらすぐ近くの車両用ＵＥのさまざまな位置を区別することが困難であり得る、密集してゆっくり移動しているトラフィック状況が想定される。前記の場合、リソース割当てのために位置情報を追加で使用することから得ることができる利益は、最小限となり得、したがって、ｅＮＢは、特定の領域内の車両用ＵＥが、改善された位置支援によるリソース割当て方法を使用せずに通常のＤ２Ｄリソース割当てを使用するものとすると決定し得る。

【0178】

別の例では、車両が中高速で走行し得、車両運転手によって間に距離が維持されていることからさまざまな車両の位置を区別することが容易にできる、スムーズに流れているトラフィック状況が想定される。それに応じて、こうした状況では、さまざまな車両の位置も考慮することによって無線リソース割当てを支援することは有益であり得る。

【0179】

その結果として、ｅＮＢは、いずれかの方法でこうした決定をし、次いで、車両用ＵＥがそれに従ってリソース割当てを行うように命令されることを確実にする。

【0180】

一方のリソース割当て方法を使用するべきかそれとも他方を使用するべきかに関する適切な情報をどのようにして車両用ＵＥが提供されるかについて多くの方法を想定することができる。これは、ｅＮｏｄｅＢによって制御されるセルエリアにも依存する。具体的には、セルエリアは、大きなものまたは小さなものとすることができるため、それらが、位置支援によるリソース割当てを使用するべきか否かに関してｅＮｏｄｅＢが同じ決定にいたる類似したトラフィック状況の特定のホモジーニアスなエリアをカバーするということにおいても異なり得る。前記の場合、ｅＮｏｄｅＢによって自身のセル内において到達可能なすべての車両用ＵＥは、位置支援によるリソース割当てを使用するように、または使用しないように、同じように設定され、一般に、ｅＮｏｄｅＢは、対応する情報を、自身のセル内におけるブロードキャスト内で提供することができる。

【0181】

一方、ｅＮｏｄｅＢのセルは、位置支援によるリソース割当てを使用するべきか否かに関して、ｅＮｏｄｅＢを、自身のセルの異なったエリアを区別するように導く異なった特性を有するいくつかの異なった道路をカバーし得る。それに応じて、ｅＮｏｄｅＢによって自身のセル内で到達可能な車両用ＵＥの一部のみが、同じように設定され、一方、他は、異なったように設定される。この場合、セルのブロードキャストは適用可能ではあり得ないが、異なった車両用ＵＥは、専用のメッセージによって設定／通知されることができる。

【0182】

第１の実施形態の、可能性のある一実施態様によれば、車両用ＵＥは、２つのリソース割当て方法のいずれかを実施するように明示的に命令され、それは、上記に説明したように、次いで、ｅＮｏｄｅＢによって自身のセル内でブロードキャストされるシステム情報内で、または特定の車両用ＵＥ宛の対応する専用メッセージ内でのいずれかで送信され得る対応するフラグによって行うことができる。フラグは１ビット長とすることができ、２つのビット値のそれぞれは、第１の実施形態で区別される２つのリソース割当て方法のうちのいずれか１つを使用するように車両用ＵＥに明確に命令する。

【0183】

代替的に、または上記に加えて、車両用ＵＥに明示的な命令を提供する代わりに、第１の実施形態の第２の実施態様は、車両用ＵＥが、改善された位置支援によるリソース割当て方法を使用するべきか否かを自身の内部の設定から推定するということに基づく。具体的には、位置支援によるリソース割当て方法を適用するために、車両用ＵＥは、通常、この改善された位置支援によるリソース割当てに関する追加のパラメータを設定される。例えば、以下で詳細に説明するように、車両用ＵＥの位置は、道路が分割される区画および／または小区画に基づいて決定することができる。その場合、車両用ＵＥが特定の区画および／または小区画を特定できるように、車両用ＵＥは道路の区画および／または小区画に関する適切な情報が提供され得る。その結果、車両用ＵＥが、位置の決定に使用するためのこうしたパラメータを設定された場合、車両用ＵＥはこれらのパラメータも活用するものとすること、および、位置支援によるリソース割当て方法を使用するものとすることを決定する。反対に、それまでにこうしたパラメータが設定されていないことを車両用ＵＥが分かる場合、車両用ＵＥは、改善された位置支援によるリソース割当て方法は使用されないものとすると決定し、実際に、車両用ＵＥは、パラメータが欠けているため、区画／小区画の関数として位置を決定することができない。ただしこれは単なる一例であり、２つのリソース割当て方法に関連して、他のパラメータも車両用移動端末に設定され得る。例えば、通常のＤ２Ｄリソース割当て方法が使用されるものとする場合、第１の実施形態の実施態様は、車両用通信専用に、特定の、より大きな、無線リソースプールを提供する。その場合、車両用ＵＥが、こうしたより大きな無線リソースプールが設定されていると判断した場合、位置支援によるリソース割当て方法の代わりに通常のＤ２Ｄリソース割当て方法を使用することを推定する。これらの無線リソースプールは、レガシーの、例えば、ＳＩＢ１９の共通リソースプール内でのようにシグナリングされ得るか、ＲＲＣ専用メッセージを使用してＲＲＣコネクテッドＵＥに専用リソースプールを送信し得る。

【0184】

いずれの場合にも、第１の実施形態のさまざまな実施態様によれば、車両用ＵＥのそれぞれは、いかなるときも、一方のリソース割当て方法を使用するべきかそれとも他方を使用するべきかを知る。

【0185】

第１の実施形態の上記の広範な説明では、車両用ＵＥが、自身の位置に基づいて無線リソースを決定することを、無線リソースがどのようにして実際に決定されるかに関して詳細にすることなく、大まかに説明した。上記に説明したように、第１の実施形態によって区別される両方の無線リソース割当て方法は、例示的に、背景技術のセクションで詳細に説明した共通Ｄ２Ｄリソース割当てに基づき得る。それに応じて、第１の実施形態の実施態様によれば、モード１およびモード２リソース割当ても分化させられ、車両用ＵＥの位置も考慮するように、それぞれに拡張される。

【0186】

モード１リソース割当てによれば、ｅＮＢは、自身のセル内でどの無線リソースが（車両用）ＵＥによって使用されるものとするかを制御する。それに応じて、無線リソースを決定する必要があるとき、車両用ＵＥは、（車両用ＵＥが位置している無線セルを制御する）ｅＮｏｄｅＢに、こうした無線リソースを要求する。詳細には、これは、背景技術のセクションでＤ２Ｄ通信についての現在の３ＧＰＰリリースについて例示的に説明するように、後にバッファ状態通知が続くスケジューリング要求をｅＮｏｄｅＢに送信する車両用ＵＥによって行われ得る。

【0187】

ｅＮｏｄｅＢは、この特定の車両用ＵＥには送信すべきデータがあることを、受信したスケジューリング要求およびバッファ状態通知に基づいて学習し、次いで、この車両用ＵＥが他のＵＥと通信できるようにするために、この車両用ＵＥのためにスケジューリングされるべき特定の無線リソースを決定することができる。第１の実施形態の改善された位置支援によるリソース割当て方法によれば、ｅＮｏｄｅＢは、（例えば、バッファ状態通知およびスケジューリング要求と一緒に）車両用ＵＥから位置情報を追加で受信し、無線リソースを決定するときに、この車両位置情報も考慮に入れる。具体的には、ｅＮｏｄｅＢは、自身のエリア内のさまざまな車両用ＵＥおよび通常のＵＥの位置を知るようになるので、トポロジ、車両の密集度、トラフィック需要、帯域外発射、干渉状況などについての自身の情報を、近くの車両用ＵＥ間の干渉が軽減されるようにそれらにリソースをスケジューリングするために、活用することができる。

【0188】

次いで、ＮｏｄｅＢから車両用ＵＥへの対応する応答は、車両用ＵＥが他の移動端末との通信のために使用するものとする無線リソースの適切なインジケーションを含む。車両用ＵＥは、対応する応答をｅＮｏｄｅＢから受信し、次いで、例えばスケジューリング割当てメッセージおよびデータの送信を含む、車両用通信を、ｅＮｏｄｅＢによってスケジューリングされたように無線リソース上で通常の方法で行うことができる。

【0189】

ちょうど記載したようにモード１リソース割当て方法については、ｅＮｏｄｅＢは、車両用ＵＥの位置を提供されると想定されている。これは、さまざまな方法で行われ得、ｅＮｏｄｅＢに送信される車両用ＵＥの位置の実際の内容にも依存し得る。後により詳細に説明するように、車両用ＵＥの位置は、一般に、地理的座標（例えばＧＰＳ）として、または道路を分割できる区画／小区画として表され得る。それに応じて、送信されるデータ量に関しても違いがあり、地理的座標はより多くのデータを必要とし、区画／小区画のＩＤはおそらくより少ないデータを必要とする。いずれの場合にも、車両用ＵＥの位置は、スケジューリング要求およびバッファ状態通知と一緒にｅＮｏｄｅＢに送信され得る。車両用ＵＥの位置に関する情報は、スケジューリング要求およびバッファ状態通知とは別に伝えられ得るか、またはスケジューリング要求が、車両用ＵＥの位置に関する前記情報を伝えるフィールドで拡張され得る。それを行うための可能性のある別の方法は、例えば１００ｍｓ毎などのように、位置情報が実質的に変化するたびに最新の位置を含む、ＲＲＣのＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎメッセージを使用することである。

【0190】

それに応じて、車両用ＵＥは、モード１に従って、追加で自身の位置に基づいて、無線リソースを決定することができる。このモード１要求は、要求されるＶ２Ｘ／Ｖ２Ｖメッセージ送信のサイズおよび周期性の詳細を含んだＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎメッセージ、および引き続き、バッファ占有量（Ｂｕｆｆｅｒ Ｏｃｃｕｐａｎｃｙ）の一切の変化を示すＢＳＲ通知などを含む。

【0191】

モード２リソース割当ては、ＵＥ自律的リソース選択とも称され、これによれば、ＵＥは、直接サイドリンクコネクションを介して制御情報（ＳＡメッセージ）およびユーザデータを送信することができるように、例えば、利用可能な無線リソースプールから、無線リソースを自力で選択するように適合される。上述のとおり、第１の実施形態は、車両用ＵＥの位置を考慮に入れることができるリソース割当て方法を追加で提供する。これは、車両用ＵＥの可能性のある異なった位置のために異なった無線リソースプールを提供することによって、第１の実施形態において例示的に実施することができる。具体的には、そのとき、複数の無線リソースプールを車両用ＵＥに設定しなければならず、そのそれぞれ１つずつが、車両用ＵＥが位置することができる異なった位置に関連付けられる。それに応じて、車両用ＵＥが無線リソースを決定する必要がある時点において、および自身の位置を決定した後において、車両用ＵＥは、どの無線リソースプールを使用すべきか、すなわち、決定された車両用ＵＥの位置に関連付けられている無線リソースプールをまず決定し、次いで、スケジューリング割当ておよびデータを送信するために、当該の関連付けられた無線リソースプールから適切な無線リソースを選択する。

【0192】

上述の、車両用ＵＥ内の複数の無線リソースプールの設定は、ｅＮｏｄｅＢの制御下にあり得る。それに応じて、ｅＮｏｄｅＢは、複数の無線リソースプールおよびそれらのそれぞれの、潜在的な車両用ＵＥ位置との関連付けに関する必要な情報を車両用ＵＥに提供しなければならない。第１の実施形態の一実施態様によれば、無線リソースプールは、例えば、無線リソースおよび関連付けられた位置を特定する表として、車両用ＵＥに明示的に通知され得る。以下の例示的な表は、前記の点において提示されており、ｘ個の異なった無線リソースプールが定義されていると仮定している。もちろん、パラメータｘは、ｅＮｏｄｅＢの制御下の無線セルのサイズ、ｅＮｏｄｅＢが自身の無線セルにおいて車両用ＵＥに利用可能にしようとする利用可能な無線リソース、および場合によってはトラフィックのタイプ／速度などを含む他の条件にも応じて変化し得る。

【表1】

【0193】

それに応じて、こうした表は、例えばシステム情報の一部として（ｅＮｏｄｅＢが自身のセル内のすべての車両用ＵＥを同じように設定したい場合）、または、代替的に／追加的に、特定の車両用ＵＥ専用のメッセージ内で、ｅＮｏｄｅＢによって自身の無線セル内のさまざまな車両用ＵＥに提供され得る。

【0194】

さらなる改善として、ＰＲＢ数などの共通の値を、各リソースプール毎に同じものを送信する代わりに一度だけ送信することができ得、それによって、ｅＮｏｄｅＢが車両用ＵＥに送信しなければならないデータの量を削減し得る。

【0195】

ｅＮｏｄｅＢから車両用ＵＥに、無線リソースプールに関するそれほど多くの情報を提供する代替手段として、第１の実施形態の代替的な実施態様は、車両用ＵＥ自体が、無線リソースプールおよび関連付けられた位置を決定することができるものとすることを提供する。これは、リソースの大きなプールを、異なった位置と関連付けられたいくつかの無線リソースプールに分割し得る一式の規則の使用によって行われ得る。例えば、車両用ＵＥは、固定量の無線リソースを、無線リソースのより大きなプールから特定の位置へ順番に割り当て得、それによって、異なった位置のための異なった無線リソースプールを生成し得る。これは、格子の隣の部分が、利用可能なリソースのプール全体からの次の部分を表し、同じように続くように、最もシンプルな形で、グリッドの各部分が、利用可能なリソースのプール全体からの一部分を表す、リソースの物理的な格子のように見えるものとすることができる。

【0196】

第１の実施形態のさらなる実施態様によれば、リソース割当ては、車両用ＵＥに、以下で説明するように、無線リソースのセンシング能力を提供することによってさらに改善される。例示的な用語「センシング能力」は、候補の無線リソース（すなわち、車両用通信のために使用され得る無線リソース）が、他の（車両用）ＵＥによって使用されているか否か、または使用されるか否かを、その後、伴って起きる他の（車両用）ＵＥとのコリジョンを避けるために、可能であれば、これらの「ブロックされた」無線リソースを使用しないために、判断する、車両用ＵＥの能力として広く理解されるものとする。それどころか、車両用ＵＥは、可能であれば、別の（車両用）ＵＥによって既に使用中ではないと決定されている他の無線リソースを使用するものとする。このセンシング能力は、上記で詳細に説明したように、無線リソースを決定するときに、車両用ＵＥによって、モード１およびモード２リソース割当ての両方に、そして車両位置の追加的な考慮に加えて適用することができる。

【0197】

一般に、センシングはさまざまな利益をもたらす。例えば、センシングベースのコリジョン回避メカニズムは、例えば、ＵＥが、自身の送信のために同じリソースを使用することを回避するために、他のＵＥの制御情報をリードするときに、リソースのコリジョンを低減するのに役立つ。さらには、センシングベースのリソース割当ておよび位置ベースのリソースプール分割には大きな性能向上があり、すなわち、センシングを伴ったリソース選択／割当て方法についてＰＲＲ（パケット受信率：Ｐａｃｋｅｔ Ｒｅｃｅｐｔｉｏｎ Ｒａｔｉｏ）が大幅に向上する。ＰＲＲは基本的に、所与の範囲（例えば１００ｍ）内の何パーセントの車両が、所与の車両用ＵＥからの送信されたパケットを受信するかを表す。また、センシングによって、低い帯域内放射につながる、ＵＥによる送信数を低減する。これは、はるかというに近いより良好な性能をもたらし、リソースを節約する。

【0198】

車両用ＵＥがモード２リソース割当て用に設定され、第１の実施形態に従って無線リソース決定のために車両位置を追加で考慮し、したがって、車両用ＵＥは、決定された、車両用ＵＥの位置と関連付けられている無線リソースプールから無線リソースを自律的に選択するものとすると、例示的に想定される。また、車両用ＵＥは、別の（車両用）ＵＥによって使用されているか、または使用される無線リソースを使用しないように、センシングを行うものとする。これは、さまざまな方法で実施され得る。例えば、車両用ＵＥは、自身の位置と関連付けられている適切な無線リソースプールから、候補の一式の無線リソースを選択する。ただし、候補の一式の無線リソースを実際に使用する前に、車両用ＵＥは、これらの無線リソースが別の移動端末によって実際にブロックされているか否かをまず判断するものとする。次いで、無線リソースが別の移動端末によって既に使用されているかまたは使用される場合、車両用ＵＥは、その過程を繰り返し、無線リソースプールから異なった無線リソースを選択し、次いで、その無線リソースは、それらがブロックされているか否かについて再度チェックされる。この過程は、車両用ＵＥが、無線リソースプールから、別の移動端末によってブロックされていない無線リソースを決定するまで継続され得る。一方、車両用ＵＥは、無線リソースプールから候補の一式の無線リソースを実際に選択する前に、無線リソースプールのすべての無線リソースについてセンシングを行い得、次いで、別のＵＥによって使用されていると決定されているか、または使用される無線リソースを、無線リソースプールから除外／無視し得る。それに応じて、次いで、車両用ＵＥは、無線リソースプールの残ったフリーの無線リソースの中から、通信に使用されるべき無線リソースを選択する。

【0199】

このセンシング能力のさらなる改善は、無線リソースプールのすべての無線リソースが、別の移動端末によって使用されているか、または使用され、その結果、車両用ＵＥが特定の時間、車両用通信の実行をブロックされるという状況を考慮する。これを回避するため、第１の実施形態の一実施態様は、車両用ＵＥが、別の無線リソースプール、すなわち、車両用ＵＥ自体の位置に実際に関連付けられているのではなく別の位置に関連付けられている無線リソースプールから無線リソースを選択できることを可能にする。これによって、この、他の無線リソースプールからの無線リソースはブロックされず、車両用ＵＥが前記無線リソースを使用して車両用通信を行うことを可能にするという可能性を高める。上述のとおり、車両用ＵＥは、複数の異なった無線リソースプールを設定され得、また、一実施態様によれば、ＵＥは、無線リソースを選択する別の無線リソースプールをランダムに決定し得る。あるいは、別の無線リソースプールをランダムに選択する代わりに、車両用ＵＥは、車両用ＵＥの実際の位置のすぐ隣の位置と関連付けられている無線リソースプールを使用し得る。一方、車両用ＵＥは、車両用ＵＥの実際の位置から、より遠くにあるか、または遠く離れていさえする位置と関連付けられている別の無線リソースプールを使用し得る。さらに別の代替手段によれば、車両用ＵＥは、あらかじめ決定された優先度割当て方式に基づいて、利用可能な無線リソースプールのそれぞれに、相対的優先度を割り当て得る。次いで、車両用ＵＥは、残った無線リソースプールから、最も高い優先度の無線リソースプールを選択し得る。例えば、相対的優先度は、近くの位置か、または遠く離れた位置と関連付けられた無線リソースプールが高い優先度を割り当てられるように、車両用ＵＥの実際の位置からの距離に基づいて、複数の無線リソースプールに割り当てられ得る。

【0200】

一方、モード１リソース割当てを想定すると、車両用ＵＥは、通信のために車両用ＵＥによって使用されるものとする無線リソースを示すメッセージをｅＮｏｄｅＢから受信した後、受信しおよび命令されたこれらの無線リソースに対して、それらを通信のために実際に使用する前に、センシングも行うものとする。同じようにして、車両用ＵＥは、命令された無線リソースが別の（車両用）ＵＥによって使用されているかまたは使用され、したがって、コリジョンを避けるためにそれらを使用しないという結論に到達し得る。それどころか、車両用ＵＥは、次いで、ｅＮｏｄｅＢからリソースを再度要求し得るか、またはｅＮｏｄｅＢから無線リソースを再度要求しなければならないことにより被る遅延を避けるために、（例えば、自身の位置に関連付けられた）適切な無線リソースプールから、無線リソースを自律的に選択することに進み得る。

【0201】

車両用ＵＥは、無線リソースが使用されているかまたは使用されることを、少なくとも２つの異なった方法で判断することができる。第１の実施態様によれば、車両用ＵＥは、候補のリソースの、対応するリソースエレメント（ＲＥ）、例えばＰＲＢ上の受信信号強度（例えば、ＲＳＳＩ、すなわち受信信号強度表示）を測定する。受信信号強度は、これらの無線リソースが別の移動端末によって既に使用されているかどうかに関するインジケーションである。それに応じて、測定された受信信号強度を適切な閾値に対して比較することによって、車両用ＵＥは、別のＵＥによって既に使用されており、したがって車両用ＵＥにとってはブロックされていると見なさなければならない無線リソースを特定し得る。さらには、車両用ＵＥは、候補のリソースについて受信信号強度を測定し続け得、その結果、他のＵＥが候補のリソースの使用をやめる時を判断し得るか、または、それらの無線リソースについて受信信号強度を実際に測定し続ける必要無しに、これらの無線リソースが（例えば、以前から無線リソースをモニタリングすることから統計的に判断されるか、または対応するＲＲＣシグナリングを介してネットワークによって命令された）特定期間ブロックされることを単純に想定する。

【0202】

第２の実施態様によれば、車両用ＵＥは、どの無線リソースがデータを送信するために使用されるかを示す、他の（車両用）ＵＥによって送信されるスケジューリング割当てメッセージをモニタし得る。それに応じて、このように、車両用ＵＥは、どの無線リソースが他の移動端末によって使用されるかを学習する。さらには、ＳＡメッセージも、無線リソースが繰り返して使用される期間を示し得、したがって、車両用ＵＥが、将来においてブロックされる無線リソースを判断することができるようにし得る。

【0203】

無線リソースがブロックされているか否かを車両用ＵＥがどのようにして判断するのかに関するこれらの２つの異なった実施態様は、同時にまたは互いに別々に、またはそれらの１つのみを、車両用ＵＥによって使用し得る。

【0204】

一般に、無線リソースを実際に使用する前に車両用ＵＥによってセンシングする過程を追加で含めることは、無線リソースのコリジョンが起こる可能性が高いシナリオにおいて特に有利である。ここまでには論じなかったが、可能性のある車両位置が、どれほど正確に互いに区別されるかに依存して、特定の位置に、１つの車両用ＵＥのみが存在し得るか、または１つよりも大幅に多くの車両用ＵＥが存在し得る。例えば、無線リソースプールが、いくつかの車両用ＵＥが同時に位置することができる特定の位置（エリア）に関連付けられており、その結果、いくつかの車両用ＵＥが同時に、または同時期に、この無線リソースプールから無線リソースを選択することができ、それによって同じ無線リソースを選択する可能性、および、コリジョンをもたらす可能性を高めることを想定する。車両用ＵＥにおいてこのセンシング能力を実施することによって、これらのコリジョンの一部は回避され、それによって、車両用通信における性能を高め、再送信を回避する。

【0205】

前に説明した広範な実施形態によれば、車両用ＵＥが自身の位置を決定し、（モード１またはモード２無線リソース割当てのいずれかを使用して）無線リソースを決定するためにそれを使用するということが想定されていた。以下に説明するように、第１の実施形態のいくつかの実施態様では、どのようにして車両用ＵＥの位置を効率的に表すことができるかに重点を置いている。

【0206】

可能性のある１つの方法によれば、車両用ＵＥの位置は、地理的座標として表現され得、これは例えばＧＰＳ衛星に基づく既知の方法で得ることができる。地理的座標は、例えば１０進形式の度で、または度分秒形式での経緯度の値を、少なくとも含む。この場合、車両用ＵＥは、自身の地理的座標を決定し、次いで、必要な無線リソースを決定するときに、これらの地理的座標を考慮に入れる。例えば、モード１リソース割当てについては、車両用ＵＥは、これらの地理的座標をｅＮｏｄｅＢに送信し、次いで、ｅＮｏｄｅＢは、適切な無線リソースを選択するため、およびスケジューリングされた無線リソースを伴った対応するメッセージを車両用ＵＥに返信するためにそれらを使用する。モード２リソース割当てについては、ＵＥは、決定された自身の位置を、異なった無線リソースプールと関連付けられた地理的座標と比較し、次いで、車両の地理的座標に最も近い地理的座標と関連付けられている無線リソースプールを選択する。

【0207】

第１の実施形態の別の実施態様によれば、車両位置は、完全に異なって、すなわち、道路が分割される区画／小区画の関数として表される。これは、道路の区画および小区画への例示的な分割を示す、図９を参照しつつ説明する。これらの図のそれぞれは、例示的に４車線道路に基づいており、４車線はすべて同じ方向に向かうトラフィックを運ぶことになっている。これらの図に示すように、どのようにして道路の一部を異なる区画および小区画に分割できるかに関して多くの可能性がある。図９については、各区画は、道路の車線のすべてをカバーすると例示的に想定されているが、そうでなくてもよい。さらには、同じ一続きの道路を異なった数の区画に分割することができ、そのとき、異なった区画はそれらの長さが異なる。次いで、これらの区画の小区画への細分化も、多くの異なった方法で行うことができる。例えば、図９（Ａ）および図９（Ｂ）では、図で示されているように１６個の異なった小区画が提供されることが例示的に想定されている。一方、図９（Ｃ）によれば、小区画は１車線のみをカバーすることになっているが、区画と同じ長さであり、結果としてこのようにより少ない小区画になる。

【0208】

区画および小区画がどのようにしてセットアップされるかは、それもまたどの無線リソース割当て方法を使用するべきかを決定する役割を担うエンティティ（例えば、ｅＮｏｄｅＢ、ＭＭＥ，またはＰｒｏＳｅ関連エンティティ）などの、移動通信システム内の適切なエンティティによって決定され得る。区画および小区画の長さおよび幅は、このエンティティによって決定され得、このエンティティは、前記の点において異なったパラメータを考慮し得る。例示的に想定される図９のシナリオでは、区画の幅は、道路の幅と等しく、一方、小区画の幅は、車線の幅（例えば４ｍ）と等しい。小区画の長さは、道路上を走行している車両の速度、結果としての、車両速度の関数としての車両間距離、および小区画当たり１つの車両のみか、それとも小区画当たりいくつかの車両が想定されることになるのかにも依存し得る。例えば、小区画当たり乗用車１台だけがあるべき場合には、同じ小区画内に１台の車両だけが位置していることを確実にするために、同じ車線内の車両間の距離約９７ｍ（２．５秒×１４０ｋｍ／ｈ、幹線道路のシナリオについてＴＳ ３６．８８５の表Ａ．１．２−１を参照）を、小区画の長さとして使用することができる。これらは、フリーウェイのケースにおける車両の絶対速度についてのデータ例である。最も速く移動するトラフィックシナリオを表しており、明らかに、この場合に（例えば車両の運転手にとっての）応答時間が最小であるため、フリーウェイのケースが選択されている。したがって、フリーウェイのケースにおいてクリティカルなメッセージを他の車両に送信するために、フリーウェイのケースにおいて、要求される最も速いレイテンシを満たすことができれば、別のケースでもおそらく可能であり得る。

【0209】

一方、区画の長さは、ＴＳ ２２．８８５の表Ａ．１で与えられる、要求される車両用通信の有効距離に基づいて決定され得る。例えば、幹線道路（アウトバーン）の場合、要求される有効距離は３２０ｍである。さらには、隣接する２つの区画の間で干渉が軽減されることを確実にするために、要求される有効距離の２倍、すなわち６４０ｍが、区画の長さとして使用されるものとすることが例示的に想定される。こうした場合、６４０ｍの区画長を想定すると、および小区画の長さが約９７ｍであると想定すると、例示的な分割は、区画の長さを、それぞれが９１ｍの長さの７つの小区画に分割し得る。

【0210】

あるいは、ＵＥが、例えば１００ｍｓに１つの送信のみを行うことになっているということを考慮して、残りの９９ｍｓの間もＵＥのために小区画の全リソースを占有することは効率的ではないかもしれないというように、より長い小区画を提供することも実現可能である。前述の場合、小区画の長さを増やすことによって、１つの小区画内に２つ以上の車両用ＵＥを有することが可能である。これを図９（Ｃ）に例示的に示しており、区画と同じ長さの小区画がある。それに応じて、モード２リソース割当てを例示的に想定すると、小区画は、依然として無線リソースプールに関連付けられ、当該の小区画内に位置する車両用ＵＥは、車両用通信を行うために、当該の小区画に関連付けられた同じ無線リソースプールから無線リソースをランダムに選択する。いくつかのＵＥが、同じ無線リソースプールから無線リソースを選択しようとしており、そのためコリジョンを引き起こし得ることから、これもまた、上述の、追加のセンシングも適用することが特に有利なシナリオであり、コリジョンは、無線リソースがフリーであるかまたはフリーになるかを、それらを実際に使用する前に車両用ＵＥにまず判断させることによって回避することができる。

【0211】

上記で例示的に説明したように、このようにして、道路は、特定の長さおよび幅の区画および小区画に分割され得る。さらには、各区画は、少なくとも特定のエリアについて、図９の（Ａ）、（Ｂ）および（Ｃ）のそれぞれに示すように、同じように小区画に分割されるべきである。別の言い方をすれば、道路は、このようにして、次いで小区画に同じように細分化される、引き続くさまざまな区画に分割される。

【0212】

次いで、小区画のそれぞれは、特定の車両用ＵＥの無線リソースを、車両用ＵＥの位置（すなわち区画／小区画）も考慮に入れることによって決定することができるように、（異なった）無線リソースと関連付けられ得る。例えば、モード２リソース割当てを想定するとき、各小区画は、異なった無線リソースプールと関連付けることができる。例示的な関連付けを以下の表に示しており、無線リソースプールが車両位置とより一般的に関連付けられている、前に論じた表と類似している。

【表2】

【0213】

上記の表から明らかなように、各区画が、その後同じ無線リソースプールに等しく関連付けられる小区画に同じように分割されることを考慮すると、車両用ＵＥが、自身がいる小区画を決定することで十分である。このように、車両用ＵＥは、（例えば、場合によっては、異なった無線リソースプールをさらに区別するために）、区画も使用するが、これは、実際に、上記の想定に必ずしも必要ではない。

【0214】

各区画の小区画に分配されるべき、複数の無線リソースプール内の無線リソースは、それらの間の干渉が軽減されるように選択され得る。それに応じて、隣接する小区画に位置し、したがって、当該の小区画に関連付けられたそれぞれのリソースを使用する車両用ＵＥは、同時に通信するとき、干渉を引き起こさないはずである。

【0215】

上述の、各道路を覆う区画および小区画の格子に基づいて、車両用ＵＥは、自身がどの区画／小区画にいるのかを、次いで無線リソースプールから無線リソースを自律的に選択するときに、自身に関するこの情報を使用するため（すなわちモード２）か、またはこの情報を、次いで、その後この情報に基づいて無線リソースを決定することができるｅＮｏｄｅＢに提供する（モード１）ためかの、いずれかのために決定する。

【0216】

それに応じて、車両用ＵＥは、自身の地理的位置を、次いで当該の地理的位置に対応する区画／小区画を特定するために、決定することから開始する。そのため、車両用ＵＥは、どのようにして道路が区画および小区画に厳密に分割されるのかについて知る必要があり、例えば、区画のサイズ、および、各区画が分割されるさまざまな小区画の数およびサイズを知る必要がある。さらには、車両用ＵＥは、自身が走行している特定の道路について格子（すなわち区画／小区画）が正確にどこで始まるのかも知る必要があり得る。この情報は、例えば、道路の始点および／または終点を特定する特定の地理的座標によって与えられる境界の形で提供することができる。その結果、道路は、すべての車両用ＵＥおよびｅＮｏｄｅＢもが、区画および小区画がどこに位置し、どこで始まってどこで終わるかについて同じ理解を持つように、区画および小区画に明確に分割されるものとする。

【0217】

また、車両用ＵＥは、格子ならびに対応する区画および小区画を、道路がカーブしているときでもなお、区画および小区画が道路に一致するように適合させるものとする。

【0218】

車両用ＵＥは、車両のナビゲーションシステムに接続され得、したがって、道路の境界、およびどのようにして道路が区画および／または小区画に分割されているかを判断するのに車両用ＵＥを支援する、地図データにアクセスすることができ得るということに、さらに留意するべきである。

【0219】

さらなる例示的な実施態様によれば、車両のナビゲーションシステムから入手可能な地図情報に基づいて、車両用ＵＥは、道路の始点／終点、道路の端の座標、各方向の車線数などについて少なくともアクセスでき／知識を有しているべきである。これに加えて、車両用ＵＥは、自身の区画／小区画を計算するために以下の機能を適用することができる。以下について、ＵＥは、１０進形式の度（ＤＤ：Ｄｅｃｉｍａｌ Ｄｅｇｒｅｅ）、またはＤＭＳ値のいずれかを使用することができる（ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｄｅｃｉｍａｌ＿ｄｅｇｒｅｅｓ）。

【0220】

区画／小区画の長さおよび幅についての各「単位」は、ブロードキャストメッセージ内で、シグナリングすることができ、例えば、１．１１３２ｍを表す０°００’０．０３６”である。ネットワークは、追加的に道路の境界情報に基づいて、ｘ’単位の緯度／ｙ’単位の経度が１つの区画／小区画を構成することをシグナリングすることができる。

【0221】

第１の実施形態の上記の実施態様は、車両用ＵＥがｅＮｏｄｅＢのカバレッジ内であることを暗示的に想定している。ただし、車両用ＵＥは、ｅＮｏｄｅＢのカバレッジ外であるとすることもでき、なおも車両用通信を行うことができるものとする。それに応じて、第１の実施形態のさらなる実施態様は、このことを、カバレッジ外の車両用ＵＥは、無線リソースを決定するときに自身の車両位置を追加で考慮せずに通常のＤ２Ｄリソース割当て方法を使用するものと規定することによって考慮に入れている。例えば、特定の車両用ＵＥがカバレッジ外であるエリアには、そもそも多くの車両がないはずであり、コリジョンの可能性を減少させるので、車両位置を追加で考慮することからの利益を最小限にすることを特に考慮に入れると、ランダムな無線リソース選択は、十分信頼できるべきである。

【0222】

（第２の実施形態）
以下に、第１の実施形態によって解決されるもの、すなわち、車両用通信のための無線リソース割当てを改善するための詳細な記載の初めで説明したものと同じ問題に対処する第２の実施形態を表す。第２の実施形態は、多くの点で第１の実施形態と類似しており、第１の実施形態への参照が頻繁に用いられる。

【0223】

第１の実施形態について上記に説明したように、中心的な特徴は、第１の実施形態が、車両用ＵＥの位置を、追加で考慮に入れることができる、追加的な、改善された、リソース割当て方法を提供するとうことであった。さらには、この位置支援によるリソース割当てに対する、さらなる、任意の、改善として、第１の実施形態は、別のＵＥによって使用されているかまたは使用される無線リソース上でのコリジョンを回避するために、車両用ＵＥが、割り当てられた無線リソースを実際に使用する前に、それらについてセンシングを行うことができるようにした。

【0224】

第２の実施形態によれば、追加的な、改善された、リソース割当て方法の中心的な特徴は、車両用ＵＥの位置によってリソース割当てを支援する特徴は任意のままではあるものの、車両用ＵＥの追加的なセンシング能力である。

【0225】

より詳細には、第２の実施形態に係る無線リソース割当ても、Ｄ２Ｄ通信のために既に定義されている無線リソース割当てに基づき、したがって、背景技術のセクションで説明した、モード１およびモード２リソース割当てを許容している。第１の実施形態と同様に、第２の実施形態は、車両用ＵＥが、決定された無線リソースに対して、それらを実際に使用する前にセンシングを行う点で異なっている、２つの異なったリソース割当てを追加で区別する。

【0226】

第１の実施形態について詳細に説明したように、センシング能力という用語は、候補の無線リソースが、他のＵＥによって使用されているか否か、または使用されるか否かを、判断する、車両用ＵＥの能力として広く理解されるものとする。次いで、これらのブロックされた無線リソースは、伴って起きるこれらの他のＵＥとのコリジョンを回避するために、可能であれば、使用されないものとする。このセンシング能力は、車両用ＵＥによってモード１およびモード２リソース割当ての両方に適用することができる。

【0227】

具体的には、車両用ＵＥはモード２リソース割当て用に設定され、ＵＥは、適切な無線リソースプールから無線リソースを自律的に選択することが、例示的に想定される。また、車両用ＵＥは、別のＵＥによって使用されているかまたは使用される無線リソースを使用しないように、センシングを行うものとする。第１の実施形態において説明したように、車両用ＵＥは、適切な無線リソースプールから候補の一式の無線リソースをまず選択し得、次いで、これらの選択された候補の一式の無線リソースが別の移動端末によって実際に使用されているか否かを判断し得る。無線リソースがブロックされている場合には、車両用ＵＥは、無線リソースプールから他のリソースを選択するものとし、これらの無線リソースが使用するのにフリーであることを確実にするために、センシング手順を再度行うものとする。一方、車両用ＵＥは、無線リソースプールから候補の一式の無線リソースを実際に選択する前に、別の移動端末によって使用されているかまたは使用される無線リソースを除外／無視するために、無線リソースプールのすべての無線リソースに対してセンシングを行い得る。結果として、次いで、車両用ＵＥは、無線リソースプールの残っているフリーの無線リソースの中から無線リソースを選択する。

【0228】

無線リソースプールのすべての無線リソースが別の移動端末によって使用されているかまたは使用される状況のために、センシング手順に対するさらなる改善を、以下に表している。第１の実施形態について既に説明したのと同じように、車両用ＵＥは、フリーの無線リソースがない場合、別の無線リソースプールから無線リソースを選択することができるものとする。他のこの無線リソースプールは依然として、ネットワークによってＶ２Ｘ通信の使用のために設定された多くのリソースプールの中にあり得る。１つのリソースプールのみが設定されている場合、または設定された最後のリソースも完全にブロックされていることが判明した場合、この車両用ＵＥは、単にウエイトして、ある特定時間後に再試行しなければならない。

【0229】

一方、第２の実施形態は、モード１リソース割当てにも適用することができ、車両用ＵＥは、スケジューリング要求、および場合によってはバッファ状態通知をｅＮｏｄｅＢに送信することによって、ｅＮｏｄｅＢから無線リソースを要求しなければならない。それに応えて、ｅＮｏｄｅＢは、適切な無線リソースを決定し、車両用ＵＥに、使用すべき無線リソースについての対応するインジケーションを提供する。第２の実施形態によれば、車両用ＵＥは、ｅＮｏｄｅＢによって割り当てられた無線リソースが、別の（車両用）ＵＥによって使用されているかどうか、または使用されるかどうかを判断し、ブロックが存在している場合には、コリジョンを回避するために、それらを使用しない。それどころか、次いで、車両用ＵＥは、ｅＮｏｄｅＢからさらなる無線リソースをを再度要求し得るか、またはｅＮｏｄｅＢから無線リソースを再度要求しなければならないことにより被る遅延を回避するために、適切な無線リソースプールから無線リソースを自律的に選択することに進み得る（すなわちモード２）。

【0230】

第１の実施形態について詳細に説明したように、無線リソースが別のＵＥによってブロックされるかどうかを車両用ＵＥが判断できる、可能性のある方法が少なくとも２つあり、第１の実施形態の対応する一節を参照する。手短に述べると、車両用ＵＥが、受信信号強度を測定し得、それを閾値と比較し得、それによって、次いで、受信信号強度が閾値よりも大きい場合には、無線リソースが既に使用されていると判断する。代替的に、または上記に加えて、車両用ＵＥが、他の車両用ＵＥによって送信されるスケジューリング割当てメッセージをモニタし得、それよって、どの無線リソースが他のＵＥによって使用され、したがって、車両用ＵＥによって使用されることをブロックされるのかに関する情報を収集する。

【0231】

無線リソース割当てのためにセンシング手順を追加で含めることは、無線リソースのコリジョンが起こる可能性が高いシナリオにおいて特に有利である。これは、例えば、交通渋滞においてなど、多くの車両用ＵＥが並んで位置している状況において、無線リソースプールは比較的小さいが、多くの車両用ＵＥによって使用されている場合であり得る。

【0232】

車両用ＵＥのセンシング能力を詳細に説明した上で、第２の実施形態は、選択的方法でセンシング能力を活用するものとする。第１の実施形態においてと同じように、コアネットワーク内のｅＮｏｄｅＢ、ＭＭＥ、またはＰｒｏＳｅ関連のエンティティなどの、移動通信システムのエンティティは、通常のＤ２Ｄリソース割当て方法を使用するべきかどうか、または第２の実施形態で導入された、改善されたセンシング支援によるリソース割当て方法を使用するべきかどうかを決定することができる。役割を担うエンティティは、説明を容易にするためｅＮｏｄｅＢと想定されているが、さまざまな情報に基づいて決定を行うことができる。例えば、ｅＮｏｄｅＢは、自身のセルの特定のエリアのトポロジ（例えば幹線道路か、都心か、地方か、など）、およびその特定のエリアにおける車両の数および速度を考慮に入れることができる。さらには、センシング支援によるリソース割当てを使用するべきか、それともセンシング支援無しを使用するべきかは、時間にも依存し得、例えば、ピーク時には通常はトラフィックが密集する一方で、別の時間にはトラフィック状況が異なる。

【0233】

その結果、ｅＮｏｄｅＢは、一方のリソース割当て方法を使用するべきかそれとも他方を使用するべきかを、すなわち、コリジョンを回避するために追加のセンシングの能力を使用するべきかそれとも使用しないべきかを、選択的に決定する。それに従って、車両用ＵＥは、どのリソース割当て方法を使用するべきかを自身が推定し得る情報を提供されるべきである。第１の実施形態について既に説明したように、これは、ｅＮｏｄｅＢが、自身のセル内のすべての車両用ＵＥについて同じ決定をするか否かにも依存して、さまざまな方法で行われ得る。前記の点において、明示的な情報（例えばフラグ）を使用することができ、ｅＮｏｄｅＢの無線セル内でブロードキャストされるか、または専用のメッセージ内で特定の車両用ＵＥに送信される。代替的に、または上記に加えて、車両用ＵＥに明示的な命令を提供する代わりに、車両用ＵＥが、どのリソース割当て方法を使用するべきかを内部パラメータから得ることも可能であり得る。具体的には、センシングを行うために、ＵＥが、受信信号強度の比較のための閾値、またはＵＥがＳＡメッセージをモニタするもとする周期性などの、特定のパラメータを供給されることが必要であり得る。

【0234】

任意に、ＳＡメッセージ自体は、リソースの、意図された使用の期間、例えば、本明細書において「ｂｕｓｙ−ｎｅｓｓ」期間と称される、その後の数ＴＴＩまたは制御／データサイクル、などについての情報を含み得る。この点において、個々の候補のＳＡメッセージ（ＰＳＣＣＨ）が受信され、および復号化され、車両用移動端末は、来る制御／データサイクルにおける何らかの将来の「ｂｕｓｙ−ｎｅｓｓ」をこれらが示しているかどうかをチェックすることができる。個々の候補のＳＡが現在送信されていない場合、車両用ＵＥは、制御（ＳＡ）および対応するデータリソースを「フリー」であると想定することができる。ＳＡメッセージ内の「ｂｕｓｙ−ｎｅｓｓ」は、車両用ＵＥが、対応する制御／データリソース上で送信し続けようとする、対応するｂｕｓｙ−ｎｅｓｓの期間も示し得る。最も単純な形では、それは「ｂｕｓｙ−ｎｅｓｓ」期間を１サイクルまたは何か他の「固定」数のサイクルとして示すブール値となる。

【0235】

いずれの場合にも、第２の実施形態のさまざまな実施態様によれば、車両用ＵＥのそれぞれは、２つのリソース割当て方法の一方を使用するべきかそれとも他方を使用するべきか、すなわち、追加でセンシングを適用するべきか否かをいつでも知ることができるものとする。

【0236】

さらには、第２の実施形態は、センシング能力に加えて、車両用ＵＥの位置で無線リソース割当てを支援することによって強化もし得る。第１の実施形態について詳細に説明したように、車両用ＵＥは、自身の位置を決定し得、他の移動端末との通信のために無線リソースを決定する過程において前記位置を使用し得る。それに応じて、第２の実施形態の特定の実施態様では、センシング能力および第１の実施形態について説明した位置支援によるリソース割当てを結合している。繰り返しを避けるため、どのようにして車両用ＵＥの位置をＵＥによって（単なる地理的座標として、または道路の小区画の関数としてのいずれかで）決定することができるのか、モード１またはモード２のいずれかにおいて無線リソースを決定するときにどのようにして車両用ＵＥの位置を使用することができるのか、どのようにして車両用ＵＥの位置を地理的座標として、または道路の区画／小区画の関数として表すことができるのか、どのようにして道路を区画／小区画に分割することができるのか、モード１リソース割当てについてどのようにして車両用ＵＥの位置をｅＮｏｄｅＢに送信することができるのかなどに関する第１の実施形態のさまざまな異なった実施態様を詳細に扱う第１の実施形態の特定の一節を参照する。

【0237】

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

【0238】

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

【0239】

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

【0240】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】