JP2018513628A - 車両アドホックネットワークにおける分散リソース管理方法および分散リソース管理システム - Google Patents

Abstract

車車間アドホックネットワークにおいて、車両などのモバイルノードのための、分散通信リソースの共有およびアクセスに関する方法およびシステムが提供される。方法は、第1のノードにおいて、ネットワーク内の第2のノードの位置を示す情報を受信するステップを含む。第1のノードは、第2のノードの位置に対する第1のノードの位置に基づいてネットワーク内の通信チャネルを要求し得る。ノードの相対的位置は、基準位置に対する各ノードの距離に基づき得る。ノードは、ネットワーク内の仮想グリッド内の第1のゾーン内にあり得、要求された通信チャネルは、第1のゾーンのチャネルであり得る。他のゾーンからのチャネルも、第1のゾーン内のノードによって2次チャネルとして要求され得る。

Description

関連出願の相互参照
本出願は、「車両アドホックネットワークにおける分散リソース管理方法および分散リソース管理システム」と題する2015年4月1日に出願された米国特許出願番号14．676，434の利益の優先性を主張し、この出願は、参照によりその内容が本明細書に援用される。

本開示は、一般に、アドホックネットワークに関し、より具体的には、車両アドホックネットワークにおける通信リソース多重アクセスに関する。

車車間通信は、例えば、専用狭域通信用の高度道路交通システム（ITS）、および無線アドホックネットワークなど、特定エリアでの開発の結果もあって、最近より大きな注目を集めている。

車車間（V2V）通信ネットワークにより、車両が相互にやりとりすることを可能にしている。関連するタイプのネットワークは、車両インフラ間（V2I）通信ネットワークであり、これにより、車両が、路側器などの路側インフラとやりとりすることを可能にしている。車両および路側器は、これらV2VおよびV2Iネットワークにおける通信ノードである。ノードは、安全警告（例えば、実際の車両衝突またはその可能性警告）、協調型運転情報、交通情報、交通規制、運転補助、または取締まり機能を含むがこれには限らない、1つまたは複数の目的のために情報を交換し得る。

V2Vアドホックネットワークは、VANETと称されることもある。これらアドホックネットワークは、通常、分散型ネットワークアーキテクチャを有しており、中央制御装置がない。これらのタイプのネットワークでは、通常、リソース管理は、考慮すべき重要な点である。重複した形で同じリソースを使用しようとしている2つのノードによって引き起こされるリソースコリジョン、および制御不可能な遅延は、特に、高速かつ信頼できる送信を必要とし得る、安全関連の通信またはその他優先順位の高い通信に関連して、これらのタイプのネットワークにおいて、ちょっとした懸念事項である。

本発明の第1の態様では、車両ネットワーク内のノードによって実行する方法を提供している。方法は、ネットワーク内の第1のノードにおいて実行することができ、ネットワーク内の第2のノードの位置を示す情報を受信するステップと、第1のノードにおいて、第2のノードの位置に対する第1のノードの位置に基づいて、ネットワーク内の第1の通信チャネルを要求するステップとを含む。

本発明の第2の態様では、車車間アドホックネットワーク内で動作するための第1のノードを提供している。ノードは、プロセッサと、通信サブシステムと、命令を記憶するコンピュータ可読の記憶媒体とを備える。記憶された命令をプロセッサが実行したとき、その命令は、第1のノードに、通信サブシステムをとおして受信した情報から、ネットワーク内の第2のノードの位置をデコードさせ、第1のノードのためにネットワーク内の第1の通信チャネルの要求を示すメッセージを送信させ、第1の通信チャネルは、第2のノードの位置に対する第1のノードの位置に基づいて選択される。

第1の態様および第2の態様のうちの少なくとも1つについての実施形態では、第1のノードによって要求された第1のチャネルは、Sparse Code Multiple Access（SCMA）レイヤを含む。さらなる一実施形態では、第1のノードは、仮想グリッド内の第1のゾーン内に位置しており、要求された第1のチャネルは、第1のゾーン用に構成される。第1のゾーンの複数のチャネルの中の各チャネルは、単一のサブフレームの間、第1のゾーンのチャネルを要求してしまっているノードが、第1のゾーンのチャネルを要求してしまっている他のすべてのノードの送信をリッスンすることができ、かつ、第1のゾーンのチャネルを要求してしまっている他のすべてのノードに第1のノードの送信をリッスンさせることができるように、サブフレーム内の少なくとも2つの異なる時間スロットのそれぞれにわたって定義されたSCMAレイヤを含むことができ、少なくとも2つの異なる時間スロットの間に同じペイロードが送信され、各チャネルの、少なくとも2つの時間スロットとその時間スロットそれぞれのSCMAレイヤとの組合せが、第1のゾーン内でユニークである。

さらなる一実施形態では、第1のノードは、仮想グリッド内の第1のゾーン内に位置し、要求された第1のチャネルは、第1のゾーンに属し、要求された第1のチャネルは、第1のノードの1次チャネルとしての役割を果たし、方法は、2次チャネルとして第2のチャネルを要求するステップであって、第2のチャネルは、第1のゾーン以外の、仮想グリッド内の第2のゾーンの利用可能なチャネルである、ステップをさらに含む。 第2のゾーンは、第1のゾーンと隣接していてもよく、または第1のゾーンと重なり合っている可能性がある。第1および第2のノードの相対的位置は、第1のゾーンの端などの基準位置に対する、第1および第2のノードそれぞれの距離に基づいて決定することができる。

さらなる一実施形態では、方法は、第1のノードにおいて、第2のノードによる要求に利用可能な、ネットワーク内のチャネルを特定するステップであって、特定するステップは、第2のノードの位置に対する第1のノードの位置に基づく、ステップをさらに含むことができる。別の実施形態では、方法は、第1のノードにおいて、ネットワーク内の第3のノードの位置を示す情報を受信するステップであって、第1のノードにおいて第1のチャネルを要求するステップは、第2および第3のノードの位置に対する第1のノードの位置に基づく、ステップを含み得る。別の実施形態では、情報を受信するステップは、第1の時刻に発生し、第1のノードにおいて要求された第1のチャネルは、第1の時刻に続いて、第2の時刻に第1のノードによる送信のために使用される。さらなる一実施形態では、方法は、第1のノードの位置を示す情報をブロードキャストするステップを含む。別の実施形態では、第1のノードは、ネットワークの仮想グリッド内の第2のゾーン内にある。第1のゾーンから第2のゾーンに入ってしまっている第1のノードは、チャネルを要求するステップの前に、第1のノードが第2のゾーンの通信チャネルの可用性について不十分な情報を有していることを示すブラインドネスインディケーションを送信する。さらなる一実施形態では、チャネルを要求した後、第1のノードは、第1のノードが仮想グリッドにおいて第1のゾーンから第2のゾーンへ移動してしまっていると判定することができる。第1のノードが第2のゾーンの通信チャネルを2次チャネルとして要求してしまっている場合には、第1のノードは、チャネルのステータスを第1のノードの2次チャネルから1次チャネルへ変更することができる。第1のノードが第2のゾーンの通信チャネルを2次チャネルとして要求してしまっていない場合には、第1のノードは、第2のゾーンの利用可能なチャネルを第1のノードの1次チャネルとして要求することができる。

本発明の第3の態様では、車車間アドホックネットワークにおいて実行される方法があり、仮想グリッドの第1のゾーン内の新たなノードにおいて、第1のゾーンの通信チャネルの可用性を示す情報を受信するステップであって、新たなノードは、要求済のチャネルを有していない、ステップと、新たなノードにおいて、新たなノードための1次チャネルのリクエストを示すネットワーク・エントリ・リクエストを送信するステップとを含む。

本発明の第4の態様では、車車間アドホックネットワーク内で動作するためのノードを提供している。ノードは、プロセッサと、通信サブシステムと、プロセッサによって実行されたときに、第1のノードに、本発明の第3の態様に係る方法を実行させる命令を記憶する、コンピュータ可読の記憶媒体とを備える。

本発明の第3および第4の態様のうちの少なくとも1つの一実施形態では、送信するステップは、ネットワーク・エントリ・リクエストを第1のゾーンに関連付けられたマスタノードへ送信するステップを含む。さらなる一実施形態では、可用性を示す情報は、第1のゾーン内の第2のノードからのビーコン送信と第1のゾーンのブロードキャストチャネルのうちの少なくとも1つをとおして新たなノードにおいて受信される。別の実施形態では、方法は、ネットワーク・エントリ・リクエストに応答して、新たなノードによる要求のための1次チャネルのインディケーションを新たなノードにおいて受信するステップをさらに含む。さらなる一実施形態では、ネットワーク・エントリ・リクエストは、新たなノードの位置を示す情報を含む。

本発明の第5の態様では、車車間アドホックネットワークにおける方法を提供している。方法は、アドホックネットワークの仮想グリッドの第1のゾーン内に位置している第1のノードにおいて実行される。方法は、第2のゾーンの第1の通信チャネルの可用性を示す情報を受信するステップと、第1のチャネルを第1のノードの2次チャネルとして要求するステップとを含む。

第5の態様の一実施形態では、受信するステップの前に、第1のノードは、第1のノードが第1のチャネルを2次チャネルとして要求することができないような、第1のチャネルの可用性について不十分な情報を有し得る。別の実施形態では、受信された情報の少なくとも一部は、ブロードキャストチャネルをとおして、第1のゾーン以外のゾーン内に位置している第2のノードから受信される。

別の実施形態では、チャネルを要求するステップは、第2のノードの位置に対する第1のノードの位置に従って実行される。第1および第2のノードの相対的位置は、基準位置に対する第1および第2のノードそれぞれの距離に基づいて決定することができる。さらなる一実施形態では、基準位置は、仮想グリッド内のゾーンの端を含む。別の実施形態では、チャネルを要求するステップは、後続の時刻における2次チャネル上での第1のノードによる送信のために、第1の時刻に発生する。別の実施形態では、第1のチャネルは、Sparse Code Multiple Access（SCMA）レイヤを含む。

本発明の第6の態様では、車車間アドホックネットワークにおいて動作するための第1のノードを提供している。第1のノードは、プロセッサと、通信サブシステムと、コンピュータ可読の記憶媒体とを備える。プロセッサが、メモリに記憶された命令を実行したとき、その命令は、第1のノードに、第1のノードがネットワーク内の仮想グリッドの第1のゾーン内に位置しているときに第1のノードにおいて、通信サブシステムをとおして受信した情報から、第2のゾーンの第1の通信チャネルの可用性のインディケーションをデコードさせ、第1のチャネルを第1のノードの2次チャネルとして要求すること示すメッセージを送信させる。

本発明の第7の態様では、車車間アドホックネットワーク内の第1のノードによって実行する方法を提供している。方法は、ブラインドネスインディケーションを送信する第1のノードを含み、第1のノードは、第1のゾーンから第2のゾーンに入ってしまっており、ブラインドネスインディケーションは、ネットワーク内の第2のゾーンにいるとき、第1のノードが第2のゾーンの通信チャネルの可用性について不完全な情報を有していることを示す。

第8の態様では、車車間アドホックネットワーク内で動作するための第1のノードを提供している。ノードは、プロセッサと、通信サブシステムと、コンピュータ可読の記憶媒体とを備える。プロセッサが、記憶媒体に記憶された命令を実行したとき、その命令は、第1のノードに、第7の態様の方法を実行させる。

第7および第8の態様のうちの1つの一実施形態では、方法は、第1のノードにおいて、送信するステップに応答して、第2のゾーンの1つまたは複数の利用可能なチャネルを示す情報を受信するステップを含む。方法は、第2のゾーンの1つまたは複数の利用可能なチャネルのうちの少なくとも1つを第1のノードの1次チャネルとして要求するステップをさらに含むことができる。さらなる一実施形態では、要求するステップは、第2のノードの位置に対する第1のノードの位置に基づく。さらに別のさらなる実施形態では、第1のノードと第2のノードの相対的位置は、基準位置に対する第1および第2のノードそれぞれの距離に基づいて決定される。

本発明の第9の態様では、アドホックネットワークの第1のゾーン範囲内に位置しているノードにおいて実行する方法を提供している。第1のゾーンは、アドホックネットワーク内で定義された仮想グリッド内のゾーンであり得る。 方法は、第1のゾーンの通信チャネルの可用性を示す情報をブロードキャストするステップを含む。

本発明の第10の態様では、第9の態様の方法を実行するためのノードを提供している。ノードは、プロセッサと、メモリと、通信サブシステムとを備える。プロセッサが、メモリに記憶された命令を実行したとき、ノードは、第9の態様の方法を実行する。

実施形態では、ノードは、ブロードキャストするステップを実行する責任を負う、第1のゾーンのマスタノードである。他の実施形態では、ブロードキャストするステップは、専用のブロードキャストチャネル上で発生する。

本発明の第11の態様では、車車間アドホックネットワーク内の第1のノードによって実行する方法を提供している。方法は、第1のノードが仮想グリッドにおいて第1のゾーンから第2のゾーンへ移動してしまっていると判定するステップと、第1のノードが第2のゾーンの通信チャネルを2次チャネルとして要求してしまっている場合には、チャネルのステータスを第1のノードの2次チャネルから1次チャネルへ変更するステップと、第1のノードが第2のゾーンの通信チャネルを2次チャネルとして要求してしまっていない場合には、第1のノードにおいて、第2のゾーンの利用可能なチャネルを第1のノードの1次チャネルとして要求するステップとを含む。

本発明の第12の態様では、本発明の第11の態様の方法を実行するためのノードを提供している。ノードは、メモリと、プロセッサと、通信サブシステムとを備える。プロセッサが、メモリに記憶された命令を実行したとき、その命令は、ノードに、第11の態様の方法を実行させる。

第11および第12の態様の実施形態では、第1のノードが第2のゾーンへ移動するときに第1のノードが第1のゾーンのチャネルを1次チャネルとして要求してしまっている場合には、方法は、第1のノードにおいて、第1のゾーンのこのチャネルを開放するステップを含む。別の実施形態では、第2のゾーンのチャネルを1次チャネルとして要求するステップは、第2のノードの位置に対する第1のノードの位置に基づく。さらなる一実施形態では、第1および第2のノードの相対的位置は、基準位置に対する第1および第2のノードそれぞれの距離に基づいて決定される。別の実施形態では、第1のノードために1次チャネルを要求するステップは、後続の時刻における第1のノードによる送信のために、第1の時刻に発生する。

本開示は、以下の図面を考慮して、さらによく理解されるであろう。

本開示の少なくとも1つの実施形態に係る、道路にそって反対方向に走行している車両を表している。 少なくとも1つの実施形態における、一例の処理システムのブロック図である。 仮想グリッドを使用して小さなゾーンに細分されている道路にそって走行している車両を表している。 複数のフレームおよび関連する時間スロットを示す送信図である。 仮想グリッドを使用してより大きなゾーンに細分されている道路にそって走行している車両を表している。 1つのフレームおよびそのフレームの関連する時間スロットを示す送信図である。 本開示の少なくとも1つの実施形態に係る、仮想グリッドを使用してゾーンに細分されている道路にそって走行している車両を表している。 少なくとも1つの実施形態に係る、1つのフレームおよびそのフレームの関連する時間スロットを示す送信図である。 少なくとも1つの実施形態における、車両において、情報を交換し、リソースを要求するためのプロセスのフロー図である。 少なくとも1つの実施形態における、送信およびリソース要求の間隔を表すタイミング図である。 少なくとも1つの実施形態に係る、ハンドオーバ状態において、ゾーンに細分されている道路にそって走行している車両を表している。 少なくとも1つの実施形態に係る、ハンドオーバ状態において、ゾーンに細分されている道路にそって走行している車両を表している。 少なくとも1つの実施形態に係る、ハンドオーバ状態において、ゾーンに細分されている道路にそって走行している車両を表している。 少なくとも1つの実施形態に係る、ハンドオーバ状態を処理するためのプロセスのフロー図である。 少なくとも1つの実施形態に係る、車両における位置順のリソース要求のためのプロセスのフロー図である。 少なくとも1つの実施形態に係る、ブラインドノード回復状態における、フレームおよび関連する時間スロットを示す送信図である。 少なくとも1つの実施形態に係る、車両ネットワークエントリ状態における、フレームおよび関連する時間スロットを示す送信図である。 少なくとも1つの実施形態に係る、ネットワークエントリ状態における、車両間の可能な送信を示すデータフロー図である。 少なくとも1つの実施形態に係る、1つのフレーム、スロットおよびSCMAレイヤを示す送信図である。 少なくとも1つの実施形態に係る、SCMAリソース定義を示すリソース定義図である。 図13に示すリソース定義のサブセットを示すリソース定義図である。

本明細書に記載の実施形態は、車両、車車間通信および車両アドホックネットワークを含む、車両通信に関する。ただし、本開示の範囲は、車両または車両通信に限定されることを意図するものではない。本開示の教示は、他のタイプのモバイルノードを含んで、他のアプリケーションおよび他の分野において、他のタイプのノードに使用または適用され得る。

本開示の少なくとも1つの態様によれば、車両アドホックネットワーク内の車両によるリソースの要求のために1つまたは複数のアプローチが提供される。要求という用語は、アドホックネットワーク内の車両による共有通信リソースの使用または予約をいうために使用され得る。複数の車両にリソースを割り当てる責任を負ったセントラルオーソリティなど、別のエンティティによってチャネルを割り当てられている車両の代わりに、車両がその車両自身のためにリソースを要求し得る。他の車両に関連付けられた情報を含んで、車両は、特定のリソースを要求および使用するために、それらの車両の環境についての情報を使用し得る。車両は、リソースコリジョンの可能性を最小限にするかまたは取り除くために、アルゴリズム、一連の規則などに基づいてそれらの車両のリソース要求を行い得る。

本開示の少なくとも1つの別の態様によれば、1つまたは複数の車両がネットワーク、例えば車両アドホックネットワークに入ることを可能にするために、1つまたは複数のアプローチが提供される。

本開示の少なくとも1つの別の態様によれば、例えば車両アドホックネットワークにおいて、ブラインド車両の回復を可能にするために、1つまたは複数のアプローチが提供される。やってくる時間フレームのためにリソースを要求するなどの必要な機能を車両が実行することを可能にするための十分な情報を、車両が受信できないとき、車両は「ブラインド」である。

本開示の少なくとも1つの別の態様によれば、アドホックネットワーク内のリソースは、Sparse Code Multiple Access（SCMA）に基づいて定義され得る。

本開示の少なくとも1つの別の態様によれば、アドホックネットワーク内の車両のための仮想全二重通信モードを実現するために、1つまたは複数のアプローチが提供される。

車車間通信は、安全関連アプリケーション用の通信および非安全アプリケーション用の通信に大まかに分類され得る。安全関連の通信は、例えば、非常ブレーキまたは死角警告などを例とする協調型前方車両衝突警告、および、この先路面凍結の警告などの危険箇所車車間通知、に関連する情報を含み得る。これらはほんの一例である。

非安全アプリケーションは、車両および交通システムに関連する別の機能またはサービスを提供するために使用され得る。非安全アプリケーションは、例えば、交通情報、交通渋滞回避、交通経路決定、インターネットまたはその他の車両用データ通信の提供に関連し得る。さまざまな他のタイプの非安全アプリケーションが存在しており、可能である。

安全関連アプリケーションにおける情報の交換は、非安全アプリケーションにおける交換とは別のサービス品質（QoS）要求事項の対象となり得る。例えば、一定のタイプの安全関連情報が素早く、すなわち低レイテンシでかつ確実に、すなわち高い成功度合いで配信されることが重要であり得る。車両衝突警告アプリケーションがタイムリーなインディケーションまたは応答を提供し得るように、協調型車両衝突警告情報が迅速かつ確実に通信されることが一般に望ましいことであり得る。

車両ネットワークにおいて、安全関連の通信は、多くの場合ブロードキャストの性質を備えている。安全アプリケーションは、特定のV2Vプロトコルをも含めて、ネットワークプロトコルまたはトランスポートプロトコルなどのプロトコルによってサポートされ得る。例えば、専用狭域通信（DSRC）である1つのV2Vプロトコルは、IEEE 802．11p規格に基づいており、この規格はIEEE 802．11の拡張であり、車両通信システムである車両環境での無線アクセス（WAVE）を追加している。拡張は、高度道路交通システム（ITS）アプリケーションをサポートすることを意図するものである。IEEE 802．11pによれば、5．9GHz周辺の専用の75MHzスペクトル帯（5．850〜5．925GHz）で通信が行われる。通信は、最大距離約1000mである。

VANET）の媒体アクセス制御（MAC）プロトコルは、一般に、チャネルアクセスのための車両間のコンテンションを解決する。既存のV2Vネットワークの実施態様では、DSRCにおけるランダムアクセスメカニズムは、キャリア検知多重アクセス／衝突回避（CSMA／CA）に依存している。既存のV2Vネットワークにおいて、車両間のコンテンションを解決するために使用されるMACプロトコルは、定義されたエリア内において同じ無線リソースへアクセスしようとしている車両が少ないときは、十分なレイテンシを提供し得る。ただし、これらのプロトコルは、エリアにおいて同じリソースへアクセスしようとしている車両がもっと多いときは、より高い、許容できないレイテンシをもたらし得る。より高いレイテンシは、少なくとも部分的には、一部の車両に対するより長いコンテンション期間が原因であり得る。

また、他の要因が、車車間アドホックネットワークにおけるチャネルアクセスまたは他の無線リソース管理を複雑にし得る。これには、ネットワーク内で絶えず変化する、ノード（例えば、車両など）の物理的位置、および、変化する、車両の互いに対する位置が含まれる。

車両ネットワークにおける安全関連の通信は、さまざまなタイプの道路安全メッセージ、例えば、協調認識メッセージ（CAM）と分散型環境通知メッセージ（DENM）のいずれかまたは両方、を含み得る。CAMおよびDENMメッセージは、ブロードキャストの性質を備え得る。協調認識メッセージ（CAM）は、送信している車両に関する情報を、その車両の近隣の車両へ提供する。このタイプのメッセージは、車両に関する情報、例えばその車両の存在、位置、キネマティクスおよび他のステータス情報を含み得る。CAMは、ビーコンまたはハートビートメッセージの形式の定期的なショートメッセージであり得る。したがってその意味では、CAMはタイムドリブン型のメッセージである。例えば、CAMメッセージは、1〜10Hzの範囲の周波数でブロードキャストされ得、約100msの最大レイテンシ、800バイトまでの長さを有し得る。ただし、これらの値は、例に過ぎない。さらには、CAMメッセージは、送信している車両のすぐ近隣の範囲内にブロードキャストされ得る。

一方、分散型環境通知メッセージ（DENM）は、1つまたは複数の他の車両に注意を喚起するために、事故などの事象もしくは状態、または他のいかなるタイプの事象もしくは情報までもがブロードキャストされる、イベントドリブン型のメッセージであり得る。そのため、CAMメッセージとは異なり、DENMメッセージは、一般に、定期的メッセージではない。一例としてのみ、DENMメッセージは、100msの最大レイテンシと、CAMメッセージよりも短い長さ（800バイト未満など）を有している。また、DENMメッセージは、事象の位置に基づくエリア範囲内でブロードキャストされ得る。エリアは、事象の関連エリアと称され得る。

ここで図1を参照すると、道路2上の複数の乗用車またはその他の車両を表している。なお、本開示の図における対象の相対的サイズおよびそれらの対象の間隔は、説明目的のためだけに使用されており、必ずしも寸法どおりではないことに留意されたい。

車両10から15は、一方向に走行して示されており、一方他の車両20から23は、反対方向に走行している。少なくとも一部の車両は、車車間通信の機能を有し得る。

例えば、車両11は、円形線30によって示された最小認識範囲を有し得る。通常、認識範囲とは、車両11が、別の車両からとることができて、なお通信範囲内に留まることができる、最大の距離をいう。そのため、車両11は、この範囲で他の車両、この例では車両10、21および22からメッセージを受信することが可能であり得るので、これらの車両を認識し得、これらの車両からこれらの車両に関して情報を受信し得る。車両11は、車両10、21および22などすぐ近くの他の車両へ情報を提供するために、メッセージをブロードキャストもし得る。ブロードキャストされて受信されたこれらのメッセージは、存在、位置、キネマティクス、およびまたは他のステータスもしくはその他の情報を提供するCAMメッセージ、DENMメッセージ、または他の一切のタイプのメッセージもしくは通信であり得る。

同様に、車両22は、円形線32によって示された最小認識範囲を有し得る。したがって、車両22は、車両11および21を認識し得、それらの車両から情報を受信し得る。車両22は、情報を送信もし得、送信された情報は、車両11および21によって受信され得る。車両22は、ブロードキャスト送信、ポイントツーポイント送信またはポイントツーマルチポイント送信を使用し得る。一実施形態では、すべてのメッセージがブロードキャスト送信であり、以下の記述ではこの言葉を使用するが、当業者は、他の送信タイプを使用することができることを理解するだろう。

また、DENMメッセージなど、事象ベースのメッセージは、車両によってブロードキャストまたは中継され得る。例えば、図1の例では、車両14は、車両15との車両衝突に巻き込まれるかもしれず、そのため、他の車両にハザードを警告するために、DENMまたは類似のタイプのメッセージをブロードキャストし得る。例では、車両14からのDENMメッセージは、車両13によって受信され得、今度は車両13が、別のメッセージで情報を再度ブロードキャストし得、そのメッセージは、車両12によって受信され得る。車両12は、DENMメッセージの送信時点においては、車両14の範囲の外にいるかもしれず、そのため、車両14からのオリジナルのブロードキャストを受信しないかもしれない。DENMメッセージをブロードキャストすることおよび中継することは、特定の地理的エリア、例えば関連エリア34に限定され得る。

図1は、いくつかの状態におけるいくつかのタイプの車車間メッセージ交換を図示している一例に過ぎない。限定を意味するものではない。

ここで図2を参照すると、処理または通信機能、例えば車車間通信を提供するために車両と共に使用され得る一例のシステムを示している。

図2は、本明細書で開示されるノード、デバイスおよび方法の少なくともいくつかを実施するために使用され得る、一例の処理システム200のブロック図である。処理システム200は、中央処理装置（CPU）202、メモリ204、大容量記憶装置206、ビデオアダプタ208、I／Oインタフェース210、および通信サブシステム212のうちの、1つまたは複数を含み得る。処理システム200のコンポーネントまたはサブシステムのうちの1つまたは複数は、1つまたは複数のバス214または他の接続によって相互に接続され得る。

バス214は、メモリバスまたはメモリコントローラ、ペリフェラルバス、ビデオバスなどを含む、任意のタイプのいくつかのバスアーキテクチャのうちの1つまたは複数であり得る。CPU202は、任意のタイプの電子データプロセッサを備え得る。メモリ204は、スタティック・ランダム・アクセス・メモリ（SRAM）、ダイナミック・ランダム・アクセス・メモリ（DRAM）、シンクロナスDRAM（SDRAM）、リード・オンリ・メモリ（ROM）、これらの組合せなどの、任意のタイプのシステムメモリを備え得る。一実施形態では、メモリは、起動時に使用するためのROM、ならびにプログラムを実行している間に使用するためのプログラムおよびデータ記憶のためのDRAMを含み得る。

大容量記憶装置206は、データ、プログラム、および他の情報を記憶し、データ、プログラム、および他の情報をバス214経由でアクセス可能にするように構成された任意のタイプの記憶装置を備え得る。大容量記憶装置は、例えば、ソリッドステートドライブ、ハードディスクドライブ、磁気ディスクドライブ、光学ディスクドライブなどのうちの1つまたは複数を備え得る。

ビデオアダプタ208およびI／Oインタフェース210は、随意に含まれ得る。これらは、外部入力デバイスおよび外部出力デバイスを処理システムに連結するためのインタフェースを提供するために使用することができる。図示するように、入力デバイスおよび出力デバイスの例には、インダッシュ型ディスプレイなど、ビデオアダプタ208に連結されるディスプレイ216、およびI／Oインタフェース210に連結されるオンスクリーンキーボード／会話インタフェース218が含まれる。ただし、これらのペリフェラルおよび他のデバイスは、あくまでも例であることを理解されたい。示され、記載されているデバイスに加えて、またはそれらの代わりに、他のデバイスが、処理システムに連結または接続されてもよい。さらに、追加またはさらに少ないインタフェースが利用されてもよい。例えば、オンボード診断（ODB）インタフェース（図示しない）など1つまたは複数のシリアルインタフェースを提供し得る。

通信サブシステム212は、送信信号および受信信号の、いずれかまたは両方について提供され得る。通信サブシステムは、1つまたは複数の有線もしくは無線のインタフェースをとおして通信を可能にするための任意のコンポーネントもしくはコンポーネント群を含み得る。これらのインタフェースには、GPRS、UMTS、LTE、LTE−A、専用狭域通信（DSRC）、IEEE 802．11p、WiFi、WiMax、またはBluetooth（登録商標）、およびV2V直接通信についてIEEEの高度道路交通システム（ITS）ソサイエティによって定義されたインタフェースが含まれるが、これには限定されない。

通信サブシステムは、トランスミッタ220、レシーバ222、およびアンテナエレメント224のうちの、1つまたは複数を含み得る。少なくともいくつかの実施形態では、処理システムは、例えば、処理システムの地理的位置を決定するため、または他のシステムとシステムの時刻同期用のタイミング信号を受信するために、地理的位置決め機能を有し得る。地理的位置決めを決定する能力は、車両の位置、速度、方向または他のキネマティク情報を決定するために望ましいかまたはむしろ必要である。少なくともいくつかの実施形態では、処理システムは、全地球測位システム（GPS）信号を受信することができ得る。そのため、少なくとも1つの実施形態では、図2に示すように、処理システムは、GPS無線またはレシーバ226を備え得る。ただし、他の実施形態は、例えば、処理システムの地理的位置を決定するため、または時刻同期用のタイミング信号を受信するために、別のサブシステムまたはコンポーネントを備え、使用し得る。

図2の処理システム200は、一例に過ぎず、限定を意味するものではない。さまざまな実施形態は、示されるか記載されているコンポーネントの一部またはすべてを利用し得る。いくつかの実施形態は、示されも記載もされていないが当業者に知られている他のコンポーネントを使用し得る。さらに、デバイスは、複数の、処理システム、プロセッサ、メモリ、トランスミッタ、レシーバなど、コンポーネントの複数の実体を含み得る。処理システムは、スピーカ、マイク、タッチスクリーン、キーパッド、キーボード、ディスプレイなど、1つまたは複数の入力／出力デバイスを備え得る。さまざまな他のオプションおよび構成が想定される。

前述のとおり、車車間アドホックネットワーク（VANET）における無線リソースの共有および要求は、いくつかの課題を抱えている。リソース要求のための1つのタイプのアプローチは、車両の地理的位置を使用する。これは、位置ベースのリソース共有と称され得る。

位置ベースのリソース共有では、道路または道路のセグメントは、グリッドまたは仮想グリッドを使用してマッピングされ得、これによって道路を詳細な地理的エリアに分割し得、そのエリアはゾーンと称され得る。無線リソースは、次いで、車両が占有する特定のゾーンに基づいて車両間で割り当てられるか、または車両によって要求され得る。

車両は、道路にそって走行するにつれて、ゾーン間を移動する。車両は、その車両の地理的位置を知り得るかまたは取得することができ得、その位置から、その車両の地理的位置決め機能を使用して、例えば、GPS信号を受信および処理することによって、その車両がどのゾーンを占有しているのかを判定し得る。車両は、ゾーン間を移動しており、リソースは、ゾーン毎に構成され得るので、各ゾーンのリソースは、例えば定期的に、時折利用可能にされる必要があり得る。例えば、車両が第1のゾーンから第2のゾーンへ移動するとき、車両は第1のゾーンに属するリソースを放棄し、次いで、第2のゾーンに属するリソースを取得する必要があり得る。車両は、第2のゾーンのリソースが要求に再び利用可能になったときに、第2のゾーン内でリソースを要求し得る。

第1の既存の、位置に基づくリソース共有のアプローチを図3Aおよび図3Bに示す。このアプローチでは、道路300は、道路をゾーン304に分割するために仮想グリッド302を使用してマッピングされる。簡単にするために、道路の1つのレーンだけを示している。この例では、ゾーンは比較的短い長さd306を有しており、平均的な車両の長さよりもわずかに長いかもしれない（一例としてのみ、例えば4m）。したがって、このゾーンの長さに基づいて、任意の与えられた時刻に1つのゾーン内に最大1つの車両が存在するだろうと仮定される。

共有無線リソースは、ゾーン毎で構成される。リソースは、図3Aにおいてゾーンz₁、z₂、・・・、z_nで示される、隣接するn個のゾーンにわたって共有され得る。例えば、図3Bを参照して、時分割多重アクセス（TDMA）スキームにおいて、長さnT_sのフレーム350の範囲内の長さT_sの1つの時間スロット352は、ゾーン毎に予め割り当てられ得、ここでフレームはn個のスロットを有している。したがって、ゾーンz₁は、予め割り当てられた時間スロット1であり得、ゾーンz₂は、予め割り当てられた時間スロット2であり得る、などである。このリソース割当ての構成はほんの一例である。ゾーンの相対的順序付けおよび時間スロットのインデックスは異なり得る。例えば、ゾーンz₁は、予め割り当てられた時間スロット2であり得、ゾーンz₂は、予め割り当てられた時間スロット10であり得、ゾーンz₃は、予め割り当てられた時間スロット1であり得る、などである。与えられた時刻に1つのゾーン内に最大1つの車両が存在し得ると仮定されるので、無線リソースにアクセスしたい他の車両はゾーン内にない（例えば、ゾーンに予め割り当てられた時間スロットにおいて）。したがって、理論上は、1つのゾーンに予め割り当てられた単一のリソースについて、車両間でのコンテンションはないことになる。

同じチャネルまたは時間スロットが、グリッド内の異なるゾーングループのために再利用され得る。例えば、同じチャネルが、次のn個のゾーンにおいて、例えばゾーンn＋1からゾーン2nに対して、およびその次のn個のゾーン、ゾーン2n＋1からゾーン3nに対して再利用され得る、などである。

図3Bは、フレーム350の下に、例の車両303（図3A）が時間の経過とともに位置している特定のゾーンを示している。車両303が位置している特定のゾーンに予め割り当てられている時間スロット（チャネルなど）は、図3Bにおいて斜線が施されている。したがってこのアプローチでは、各ゾーンは、各フレーム350内に、対応する時間スロットを有している。

また、前述のとおり、車両は認識エリアを有している。車両は、このエリアの範囲で他の車両からメッセージを受信し得るので、これらの他の車両を認識し得、これらの車両からこれらの車両に関して情報を受信し得る。例えば、図3Aを参照すると、車両310は、車両の周辺で認識エリア範囲rメートルを有しており、符号308で示される。dはゾーンの長さであるので、認識範囲は、車両310が位置しているゾーン312の両側にr／dゾーンの長さを有する。したがって、この例では、合計の認識エリアは2d／r＋1ゾーンである。

さらに、車両は、その車両の認識エリア308の前に、gメートルのガード領域を有し得、符号314で示されている。ガード領域は、g／dゾーンの長さを有し得、認識エリア308の外側領域またはその近くにおける支障に対処するために使用され得る。例えば、ガード領域は、グリッドにわたる定期的なチャネルの再利用に起因する支障を低減するために使用され得る。ガード領域は、車両に対して、その車両が次の時間フレームをリッスンし始める前に、関連する受信した情報を処理するために、余裕時間を提供もし得る。図3Aの例では、車両310は、ゾーン1から2r／d＋1までをリッスンする必要があり得る。車両310は、ゾーン2r／d＋2からnまでを無視してもよい。

グリッド内の異なるゾーングループのために同じチャネルが再利用される場合、車両の認識範囲は、結果として、車両の前後でn／2＊dメートル（またはn／2ゾーン）以下であり得る。図3Aに示すように、車両の片側の認識範囲はrであり、ガード範囲はgであり、したがって同じチャネルを再利用するゾーングループ内のゾーンの数nは、n＝（2r＋g）／d＋1であり得る。

この第1のアプローチは、いくらかの利益を提供し得、例えば、無線チャネルへのアクセスのために車両間でいかなるコンテンションも通常はない。ただし、このアプローチは、欠点も有している。例えば、ゾーンの長さ、ひいてはサイズが小さいので、車両は、その車両の地理的位置を高精度で着実に決定することができなければならない。この決定において一定量の誤差がある場合、車両は、その車両が実際にいるゾーンとは異なるゾーンにその車両が位置しているものと、間違って判定し得るので、この異なるゾーンに予め割り当てられたかまたはそれに属しているチャネルへアクセスしようとすることになる。結果として、1つを超える車両が同時に、ゾーンの同じリソース（チャネルなど）を使用しようとしている場合があり得る。

さらに、各ゾーンのサイズが小さく、場合によっては車両の長さよりもわずかに長いので、任意の与えられた時刻において、ゾーンの大部分が空いていることになる可能性が高いかもしれない。無線リソースは、各ゾーンに予め割り当てられているので、多くのゾーンが空いているとき、かなりの量の無駄なリソースがあることになる。

また、ある一定の速度以上で車両が走行しているとき、このアプローチには問題もあり得る。短いゾーン長は、車両がある一定の閾値速度を超えて走行しているとき、処理を実行し、無線リソースをとおして送信するために十分な時間を有し得ないことを意味する。例えば、ゾーン内で送信を開始する前の最大遅延時間は、（n＋1）T_s＜d／V_maxであり得、図3Bにおいて符号354で示されており、ここで、nはフレーム毎のスロット数、T_sはスロットの時間幅、そしてV_maxは車両の最大速度である。

第2の既存の、位置に基づくリソース共有のアプローチを図4Aおよび図4Bに示す。このアプローチは図3Aおよび図3Bに示したものに類似しており、道路400、仮想グリッド402、および多数のゾーン404を有している。図4Aではゾーンはz₁、z₂、z₃などと番号が付けられる。ただし、このアプローチでは、各ゾーンは、より大きな地理的サイズ、例えばより長いゾーン長406を有し得る。そのため、1つのゾーンは、同時に2つ以上の車両を含むのに十分なほど大きいものであり得る。また、このアプローチでは、リソースの複数のチャネルが、単一のゾーンに予め割り当てられ得る。そのため、単一のゾーン内の車両は、複数のチャネルを使用し得る。ゾーン範囲内に1つの車両しかないとき、その1つの車両は、その車両のゾーン範囲内のチャネルのいくつかまたはすべてを、検知および使用し得る。ゾーン内に2つ以上の車両があるとき、チャネルへのアクセスのためにその2つ以上の車両の間でコンテンションが存在し得る。

例えば、図4Bを参照すると、時分割多重アクセス（TDMA）の実施態様において、フレーム450の各サブフレーム454は、異なるゾーンに予め割り当てられ得る。フレーム450は、I個のサブフレームを有し得る。例えば、サブフレーム1は、ゾーンz₁に予め割り当てられ得、サブフレーム2はゾーンz₂に予め割り当てられる、などである。また、サブフレーム454の範囲内の1つまたは複数の時間スロット452は、与えられたゾーンのためのチャネルとして予め割り当てられ得る。例えば、サブフレーム2内の時間スロット1からmは、ゾーンz₂のためのチャネル1からmとして予め割り当てられ得る。

この第2のアプローチは、前述の第1のアプローチとは異なり、より大きなゾーンサイズのおかげで、その車両の地理的位置を決定する車両において、こうした高精度の必要性がなくなり得る。ゾーンサイズがより大きいので、低精度で十分であり得る。つまり、車両は実際には第1のゾーンにいるが、第2のゾーンにいるものと間違って判定する（例えば、GPSなどを使用して）、という可能性が、ゾーンがより小さいときと比較して低い。さらに、この第2のアプローチでは、任意の与えられた時刻において空いているゾーンがより少ないことが十分に考えられるので、無駄なリソースがより少なくなり得る。また、車両が閾値速度を超えるときに生じる、第1のアプローチにおける問題は、より長いゾーン長のおかげで、第2のアプローチでは低減または取り除かれ得る。

ただし、単一のゾーンにおいて車両間でチャネルが共有されるので、第2のアプローチにおいてチャネルコンテンションの問題が生じる。そのため、同じチャネルにアクセスしようとする車両による多重アクセスのリソースコリジョンの可能性がある。リソースコリジョンは、いくつかの車両について長いコンテンション期間という結果になり得、これが、他の車両との、安全関連情報などの情報交換における高レイテンシにつながり得る。いくつかの状態およびシステムでは、例えば、安全関連情報の送信に関与して、高レイテンシは望ましくないかまたは許容されないものでさえあり得る。

そのため、本開示の一態様によれば、車両アドホックネットワーク内のリソースアクセスのために1つまたは複数のアプローチが提供される。

本開示の少なくとも1つの態様によれば、リソースは、与えられたエリア（ゾーンなど）範囲内の車両によって、そのエリア範囲内の車両の順序付けに基づいて要求され得る。順序付けは、エリア内の1つまたは複数の車両についての情報を含む、任意の適切な基準または複数の基準に基づき得る。少なくとも1つの実施形態では、順序付けは、基準点または基準位置に対する各車両の距離に基づき得る。そのため、リソースの要求は、車両の実際の地理的位置ではなく、ゾーン内の車両の相対的位置（すなわち順序）に基づき得る。これは、位置順のリソース要求と称され得る。その結果、リソースは、車両が送信のためにリソースをランダムに選択して1つまたは複数の他の車両とのリソースコリジョンの危険を冒す代わりに、順序付けに基づいてゾーン範囲内の車両によって要求され得る。位置順のリソース要求は、車両アドホックネットワーク内での既存のリソース割り当てアプローチにおいて生じるリソースコリジョンの可能性を低減または取り除き得る。

本開示の実施形態は、チャネルの形式のリソースと共に記載されている。しかしながら、「チャネル」という記述は、限定を意味するものではない。本教示は、他のタイプのリソースにも適用される。

アドホックネットワーク内に、リソース割当てを制御するために、セントラルエンティティが存在しない場合があるので、各車両は、その車両自身のためにリソースを要求し、他の車両、例えばその車両の認識範囲内の他の車両によるリソースの要求または使用を特定または追跡する責任を負い得る。このように、アドホックネットワーク内の車両は協調して、セントラルリソース割り当てエンティティなしに通信リソースを共有および管理する。車両は、2つの車両が同じリソースを要求または使用しようとすることを低減または取り除く目的で、リソースの共有および要求を管理するためのアルゴリズム、規則、またはプロセスを使用し得る。記述を簡単にするため、アルゴリズム、一連の規則などは、単に、チャネル共有アルゴリズムと称され得る。つまり、チャネル共有アルゴリズムは、各車両が、リソースコリジョンのリスクが少ないかまたはない状態でその車両がリソースをいつ要求および使用し得るかを決定することを可能にし得る。

少なくとも1つの実施形態では、車両の順序付けは、ゾーン内の車両の地理的位置に基づき得る。図5Aは、図に示すように左から右方向へ向かう、道路500上の複数の車両520を表している。この特定の走行方向は、説明目的のためだけに使用されており、限定を意味するものではない。複数のゾーン504を定義するために、仮想グリッド502が道路500にマッピングされている。ここでは、簡単にするために、ゾーンi−1、i、i＋1、およびゾーンi＋2だけを示している。

図5Bは、複数のサブフレーム554を有する送信フレーム550を示しており、サブフレームはスロット552に細分され得る。フレーム550の異なるサブフレーム554は、異なるゾーンに対して構成または予め割り当てられ得る。例えば、サブフレーム1はゾーンi−1に予め割り当てられ得、サブフレーム2はゾーンiに予め割り当てられ得、サブフレーム3はゾーンi＋1に予め割り当てられ得る、などである。さらに、サブフレーム554の範囲内の1つまたは複数の時間スロット552は、与えられたゾーン内のチャネルとして予め割り当てられ得る。例えば、サブフレーム2内の時間スロット1からmは、ゾーンiのためのチャネル1からmとして予め割り当てられ得る。

再度、少なくとも1つの実施形態では、車両がゾーン間を移動しており、チャネルがゾーン毎に構成され得るので、チャネルは、時折、例えば定期的に、車両による要求のために利用可能にされ得る。例えば、リソース要求は、時刻0、t、2t、3tなどに実行され得、ここで、tはリソース要求サイクルの幅である。アドホックネットワークでは集中型のリソース管理がないので、各車両はその車両自身のためにリソースを要求し得る。リソース要求のためのプロセスおよび規則は、ほとんどまたはすべての車両について同じであり得るので、車両は、リソースコリジョンのリスクが少ないかまたはない状態で、リソースを要求し得る。少なくとも1つの実施形態では、車両は、時刻2tにおいてリソースを要求するために、時刻tにおいて既知の情報を使用し得る。そのため、車両は、その車両自身についての情報、例えばその車両の現在の位置（その車両がどのゾーンにいるのかを含む）、および他の車両から受信してしまっている類似した情報を、その車両が使用するためのリソースを要求するために使用し得る。車両は、受信した情報、およびすべての車両に共通のチャネル共有アルゴリズムに基づいて、いつ特定のリソースが他の車両によって要求および使用され得るかを特定することができ得る。

図6Aは、少なくとも1つの実施形態における車両において、情報を交換し、リソースを要求するためのプロセスを示すフロー図である。この実施形態では、プロセスは、ネットワーク内のすべての車両において定期的に実行され得る。プロセスは、ブロック600から始まって、車両が、その車両の位置を含んでその車両自身についての情報およびデータを、計測または収集し得るブロック602へ進む。一実施形態では、これは受信したGPS信号を使用して行われる。プロセスは、車両が時刻tにおいて、ビーコンメッセージなどの情報を、その車両の要求済のリソース（例えばチャネルなど）上で送信するブロック604へ進む。時刻tは、送信フレームfの中にある。送信は、協調認識メッセージ（CAM）または他のメッセージを含み得、そのメッセージは、ブロードキャストしている車両の存在、位置、キネマティクス、および他のステータス情報など、ブロードキャストしている車両に関する情報を含み得る。プロセスは、フレームfで他の車両からの送信またはブロードキャストについてリッスンする、ブロック606へ進む。

プロセスは、ブロック606から、車両が1つまたは複数の、タスク、計算、または他の処理、例えば、ブロック606において他の車両から受信した情報を含んで、位置および他の情報の処理を、実行し得るブロック608へ進む。プロセスは、車両が、時間フレームf＋1において使用するためにチャネルを要求するブロック610へ進む。したがって、フレームfでは、車両は、後続の時間フレーム、例えばフレームf＋1において使用されるべき1つまたは複数のチャネルを要求し得る。

プロセスは、次いで、ブロック602に戻り、フレームf＋1でもう一度やり直し得る。したがって、フレームf＋1におけるブロック604での、車両による送信は、フレームfで要求されたチャネル（例えば、チャネルなど）上であり得る。

少なくとも1つの実施形態では、図6Aのプロセスと同じかまたは類似したプロセスは、車両アドホックネットワーク内の車両の一部またはすべてにおいて実行され得る。車両は、任意の適切な方法で時間同期され得る。例えば、一実施形態では、車両は受信したGPS信号を使用して同期され得る。ただし、車両は、他の方法で同期されてもよい。

さらに、図6Aの例では、車両は、プロセスのすべてのループで、すなわちすべてのフレームについて（例えば、ブロック610）、リソースを要求するが、これは限定を意味するものではない。他の実施形態では、リソースは、2フレーム毎、または3フレーム毎、または4フレーム毎などに、要求され、これは図6Aのプロセスまたは類似のプロセスの、2、3、または4ループ毎などに対応し得る。つまり、いくつかの実施形態では、車両は、それらの車両がビーコンメッセージをブロードキャストし、他の車両のブロードキャストをリッスンするすべてのサイクルでリソースを要求する必要は必ずしもない。車両は、より少ない頻度でリソース要求を実行することで十分であり得る。これは、図6Bを参照して記載している。

図6Bは、少なくとも1つの実施形態における、送信およびリソース要求の間隔を表すタイミング図である。隣接する短い矢印652の間隔650それぞれは、送信期間 、例えば時間フレームを表している。車両は、いくつかまたはすべての送信期間で、他の車両に情報を送信またはブロードキャストし得る。隣接する長い矢印662の間隔660それぞれは、リソース要求間隔を表している。リソース要求間隔660は、フレーム幅650の整数倍であり得る。例えば、車両は、1つまたは複数の送信期間650、すなわち符号680で示された1つまたは複数の期間の間、チャネルおよび他の車両についての情報を収集し得る。この情報は、車両によって、1つまたは複数の後続フレームのために、次のリソース要求時刻682において使用され得る。

再度、図5Aを参照して、以下の例では、ゾーンi内の車両A、B、CおよびDに着目する。例では、各ゾーンは5つのチャネルで構成される。その結果、ゾーンiは、チャネルc_i，1、c_i，2、c_i，3、c_i，4、およびc_i，5を有している。車両Dは、ゾーンiにおいてすでにチャネル、例えばチャネル1、すなわちc_i，1を要求していることも仮定する。車両Dは、例えば前にチャネルが要求されたとき（例えば、フレームf−1）にその車両がゾーンiにいたことから、すでにチャネルを要求してしまっている場合があり、その結果、その車両のチャネル、c_i，1を保持してしまっている場合がある。ただし、車両がゾーンを変更してはいないにもかかわらず、車両がその車両のチャネルを保持していない他の実施形態では、この車両は、チャネルを必要とする車両グループに含まれ得る。

一方で、車両A、BおよびCは、ゾーンi内でチャネルを有していないので、チャネルを必要としている。車両A、BおよびCは、1つまたは複数の理由によって、ゾーンi内でチャネルを有していない場合がある。例えば、車両A、BおよびCのうちの、1つまたは複数は、前にチャネルが要求されてから後に、ゾーンi−1からゾーンiに移動してしまっている場合がある。

前述の例では、車両A、BおよびCのうちの、1つまたは複数は、ゾーンi−1からゾーンiに到着したばかりであり得る。そのため、これらの車両のそれぞれは現在、ゾーンi−1からのチャネルを使用してその上でブロードキャストしている場合がある。ただし、これらの車両はゾーンi−1を離れてしまっているので、次にチャネルが要求されるとき（例えば、フレームf）には、これらの車両はもはやゾーンi−1内のチャネルを使用する資格を満たし得ない。したがって、これらの車両は、次のリソース要求サイクルにおいてゾーンiのチャネルを要求しようとし得る。

そのため、本開示の一態様によれば、ゾーンi内の空いているかまたは利用可能なチャネルは、車両A、BおよびCのうちの、1つまたは複数よって、そのゾーン範囲内の車両の相対的位置決めまたは順序付けに基づいて要求され得る。少なくとも1つの実施形態では、順序付けは、少なくとも1つの基準点または基準位置に対する各車両の距離に基づき得る。少なくとも1つの基準点は、任意の適切な基準点でもよい。少なくとも1つの実施形態では、基準点または基準位置は、ゾーンの端であり得る。例えば、グリッド502内のゾーン504は、一般に形状が四角形をしているが、別の形状のゾーンも可能である。ゾーンiは、第1および第2のゾーン側端530および532、ならびに第1のゾーン末端534および第2のゾーン末端536を有し得る。記述を簡単にするため、第1および第2のゾーン末端534、536は、それぞれ左ゾーン端および右ゾーン端と称され得る。

少なくとも1つの実施形態では、車両は、ゾーン範囲内で、ゾーンの端に対するそれらの車両の距離に基づいて順序付けられ得る。例えば図5Aでは、チャネルを有していない、ゾーンi内の車両は、右ゾーン端536に対するそれらの車両の距離に基づいて順序付けられ得る。昇順に順序付けられ、車両は、C、AそしてBのように順序付けられることになる。車両Cは、3つの車両のうちで右ゾーン端536に最も近い。車両A、BおよびCの中で、車両Aは次に近く、車両Bは3番目に近い。車両がゾーン範囲内で左から右へ走行していると仮定すると、こうした順序付けは、より早い時刻にそのゾーンに入った車両を優先し得る。ただし、車両は他の方法で順序付けられてもよいことを理解されたい。例えば、一実施形態では、車両は、左ゾーン端534に対するそれらの距離に基づいて順序付けられ得る。別の実施形態では、車両は、ゾーンの内側または外側の、他の何らかの基準点に対するそれらの車両の距離に基づいて順序付けられ得る。

本例では、ゾーンi内で1つのチャネルだけが現在要求されており、つまり車両Dによってチャネルc_i，1が要求されている。そのため、ゾーンi内で4つの空きチャネルが、つまりc_i，2、c_i，3、c_i，4およびc_i，5が利用可能である。空きチャネルは、前述のように、車両A、BおよびCによって、右ゾーン端536に対するそれらの車両の相対的位置に基づいて要求され得る。車両の相対的位置は、右ゾーン端536に対する各車両の距離によって決定され得る。少なくとも1つの実施形態における、この順序付けに基づいて要求するチャネルの一例を、以下の表1に示す。

車両Cは、チャネルを必要とする車両の順序付けされたリスト内の1番目の車両なので、チャネル要求処理において優先される。ここでは、順序付けに基づくチャネル要求アルゴリズムによって、車両Cに、その車両が空きチャネルc_i，2を要求し得る、と判定することを可能にしている。同じアルゴリズムを使用して、車両Aは、その車両の相対的位置を決定する時点で、その車両が順序付けリスト内の次の車両であり、したがって空きチャネルc_i，3を要求し得ると判定することができる。車両Bは、その次の車両であり、空きチャネルc_i，4を要求し得る。こうした実施形態では、車両は、現在のゾーンの端にそれらの車両がどれぐらい近いかに基づいて、特定のチャネルを要求する。例えば、車両Cは、右ゾーン端536に近いので、車両Cは、番号が最も小さいチャネルを要求する能力が提供される。当業者は、車両がゾーン内の中間点に対するそれらの車両の距離に基づいて順序付けられる、または、車両の位置および速度の両方を考慮する規則などを含んで、他の順序付け規則を適用することができることを理解するだろう。

特定の車両によって特定のチャネルが要求される順序付けまたは方法は、任意の適切な方法で行われ得る。前述の例では、空きチャネルは、それらの空きチャネルのチャネルインデックスの昇順に基づいて要求され、すなわちc_i，2は一番低いチャネルインデックス（例えば2）を有しており、したがって順序付けリスト内の1番目の車両である車両Cによって要求され得る。チャネルc_i，3（チャネル3）は、次に低いインデックスを有しており、したがってリスト内の次の車両によって要求され得る、などである。ただし、他の実施形態では、空きチャネルは、チャネルインデックスの降順に基づいて、または任意の他の方法で要求され得る。

さらに、右ゾーン端536を、チャネルを必要としている車両を順序付けするための基準点として使用することは、ほんの一例である。1つまたは複数の他の基準点が、ゾーン範囲内の車両の順序付けを見いだすために使用され得る。例えば、一実施形態では、車両は、左ゾーン端534に対するそれらの車両の距離に基づいて、昇順で順序付けられ得る。

また、例では、車両は、右ゾーン端536に対するそれらの車両の距離に基づいて、昇順で順序付けられているが、これは限定を意味するものではない。車両は、ゾーン端または他の基準点に対するそれらの車両の距離に基づく降順を含んで、任意の適切な方法で順序付けられ得る。

本開示の別の態様によれば、与えられたゾーン範囲内の1つまたは複数の車両は、1つまたは複数の他のゾーンからチャネルを要求し得る。それらのチャネルは、車両の2次チャネルと称され得、一方、そのゾーンの範囲内の車両によって要求される、ゾーンのチャネルは、1次チャネルと称され得る。いくつかの実施形態では、2次チャネル、別のゾーンに属しているが、これは、車両が、別のゾーンにいる車両から情報を取得および交換するために使用することができる。これにより、より多量の情報を車両に提供することを可能にする。与えられた車両の観点からすると、チャネルは1次、2次などと見なすことができるが、他の車両の観点からすると、それらのチャネルは、単に予約されてしまっているチャネルと見なされ得る。

少なくともいくつかの実施形態では、2次チャネルの要求は、ゾーン範囲内の車両の相対的位置または順序付けに基づき得る。いくつかの実施形態では、2次チャネルの要求は、本明細書に記載の、1次チャネルの要求と類似し得る。

ここで、2次チャネル要求の一例を、図5Aを参照しつつ記載する。

ゾーン内の車両は、1つまたは複数の1次チャネルを要求し得るが、その車両は、1つまたは複数の2次チャネルも要求し得る。例では、ゾーンi＋1内の車両E、FおよびGは、1次シャネルc_i＋1，1、c_i＋1，3およびc_i＋1，4を要求してしまってい得る。例では、各ゾーンは、合計5つのチャネルを有しているので、その結果、ゾーンi＋1は、2つの空きチャネル、つまりc_i＋1，2およびc_i＋1，5を有している。少なくとも1つの実施形態では、ゾーン、ここではゾーンi＋1内の1つまたは複数のこうした空きチャネルは、異なるゾーン、ここではゾーンi内の車両によって要求され得る。

車両は、任意の適切な方法で、他のゾーンの1つまたは複数の空きチャネルを認識することになり得る。少なくとも1つの実施形態では、この情報は、他の車両の定期的なブロードキャストメッセージに含まれ得る。例えば、車両は、例えばフレームfにおいて、こうした情報を受信し得、次いで、フレームf＋1または任意の将来のフレームなどの将来のフレームのためにリソースを要求するときにその情報を使用し得る。いくつかの実施形態では、車両は、他のゾーンの1つまたは複数の空きチャネル、およびおそらくこれらのチャネルのステータスさえも、一切ブロードキャストさえなしに認識し得る。例えば、フレームf＋1のための要求に対して空いているであろうチャネルは、フレームfおよび車両の一切のハンドオーバにおいて車両で受信した情報に基づいて抽出され得る。したがって、空きチャネルを示すブロードキャストメッセージは、それらの車両がすでに有している情報からこの情報を抽出することができる車両にとっては冗長であり得る。ただし、こうしたブロードキャストは、1つまたは複数の車両がこの情報を抽出できないとき、例えばブラインド車両の場合には有用であり得る。

他のゾーンからの空きチャネルの要求は、任意の適切な方法で行われ得る。少なくとも1つの実施形態では、空きチャネルは、1次チャネルと類似した方法で要求され得る。例では、ゾーンi＋1の空きチャネルc_i＋1，2およびc_i＋1，5は、車両A、B、CおよびDによって、そのゾーン範囲内の車両の相対的位置に基づいて要求され得る。例えば、要求は、車両の昇順の順序付けに基づき得、順序付けは、右ゾーン端536に対するそれら車両それぞれの距離に基づき得る。したがって、車両のリストは、D、C、A、そしてBと順序付けられるだろう。なお、一実施形態において前述したように1次チャネルを必要としていた車両だけとは対照的に、ここでは、ゾーンi内のすべての車両が順序付け済のリストに含まれ得る。

少なくとも1つの実施形態において前述した順序付けに基づく、2次チャネルの要求の一例示的説明を以下の表2に示す。

車両Dは、車両の順序付け済リスト内の1番目の車両なので、2次チャネルのための要求プロセスにおいて優先され得る。ここでは、車両において実施された共通のチャネル共有アルゴリズムは、車両Dが空きチャネルc_i＋1，2を要求し得ると判定する。車両Cは、順序付け済リスト内でその次の車両であり、したがって空きチャネルc_i＋1，5を要求し得る。ゾーンi＋1からのこれ以上空きチャネルはなく、その結果、車両AおよびBは、このゾーンから2次チャネルを一切要求し得ない。

この実施形態では、車両は、その車両がその車両の現在のゾーンの端に対してどれほど近いかに基づいて、2次チャネルを要求し得る。ゾーン内での車両の順序は、それらの車両が、道路にそって走行しながらそのゾーンを離れる可能性が高い順序を表し得る。例えば、車両Dは、右ゾーン端536に最も近いので、車両Dは、車両A、BおよびCより前にゾーンiを離れるだろうという可能性が高い。そのため、車両Dは、ゾーンi＋1の空きチャネルを2次チャネルとして要求するために、ゾーンiにおいて優先される。車両Cは、右ゾーン端536に対してその次に近い車両なので、同様に2次チャネルを要求する。この方法による2次チャネルの要求は、その車両の現在のゾーンに存在する次の車両になる可能性が高く、したがってゾーン間の遷移状態にいることになるであろう車両を優先する。多くの場合、第1のゾーンにいる間に車両によって要求された2次チャネルは、次いでその車両が新たなゾーンに移動したときに、その車両のための1次チャネルとして使用することができる。このことを、ハンドオーバとの関連で以下に説明する。

そのためこの例では、2次チャネルは、最も高い優先順位の車両から開始して、残っている空きチャネルがなくなるまで、車両によって要求され得る。いくつかの実施形態では、車両は、2つ以上の2次チャネルを要求し得る。ただし、少なくとも1つの実施形態では、車両は、2次チャネルを1つだけ要求し得る。そのため、ゾーン内にいる車両よりも多くの空き2次チャネルがある場合、あらゆる車両は、2次チャネルを1つだけ要求し得る。残っている空き2次チャネルは、要求されないままになるか、または、いくつかの実施形態では、別のゾーン内の車両に対して利用可能になり得る。後者の状態を、以下の例によって記載する。

図5Aを参照すると、ゾーンi＋2内の車両Hは、1次チャネルc_i＋2，1を要求し得るか、または前に要求してしまっている。そのため、ゾーンi＋2は、4つの空きチャネルを有している。車両が2次チャネルを1つだけ要求し得る実施形態では、車両において実施されたチャネル共有アルゴリズムは、車両G、F、およびEが、チャネルc_i＋2，2、チャネルc_i＋2，3、およびチャネルc_i＋2，4を2次チャネルとして要求し得ると判定し得る。チャネルc_i＋2，5は、要求されない状態であり得る。

少なくとも1つの実施形態では、これら要求されなかった2次チャネルのうちの1つまたは複数は、別のゾーン内の車両に対して利用可能になり得る。例えば、チャネルc_i＋2，5は、ゾーンi内の車両に対して利用可能になり得る。こうした1つまたは複数の空きチャネルは、任意の適切な方法で、ゾーンi内の車両によって要求され得る。車両が2次チャネルを1つだけ要求し得る一実施形態では、空きチャネルc_i＋2，5は、ゾーンについての順序付け済リスト内で2次チャネルをまだ割り当てられていない、最も高い優先順位の（例えば、順序付けをされた）車両によって要求され得る。本例では、以下の表3に示すように、チャネルc_i＋2，5は、車両Aによって要求され得る。

車両が2つ以上の2次チャネルを要求し得る別の実施形態では、前述の例の空きチャネルc_i＋2，5は、ゾーン内の最も高い優先順位、例えば、ゾーン内のすべての車両の順序付け済リスト内の最も高い優先順位の車両によって要求され得る。その結果、例では、チャネルc_i＋2，5は、車両Aではなく車両Dによって要求され得る。

ただし、別の実施形態では、チャネルc_i＋2，5などの1つまたは複数のチャネルは、ゾーンi内の車両に対するのとは異なる方法で要求され得るか、または異なるゾーンの車両によって要求される場合さえある。例えば、ゾーンi内のすべての車両がすでに2次チャネルを要求してしまっている異なる状態においては、チャネルc_i＋2，5は、ゾーンi−1内の車両に対して利用可能になり得る。一実施形態では、車両は、その車両の認識範囲内の任意のゾーンから2次チャネルを要求することができ得る。他のオプションが可能である。

少なくともいくつかの実施形態では、車両は、その車両の認識範囲内の一部またはすべての他のゾーン内の他の車両によって要求された2次チャネルを特定し、知り得る。一例によって、一実施形態でこれがどのようにして実現されるのかを説明している。車両は、ゾーンi内にいて、ゾーンi＋2から空きチャネルを要求し得る。そうするためには、車両は、ゾーンi＋2内の空きチャネルの現在のリストを知る必要があり得る。前述のように、ゾーンi＋2内の1つまたは複数の空きチャネルについての優先権は、ゾーンi内のいかなる車両よりも先に、ゾーンi＋1内の車両に対して与えられ得る。そのため、ゾーンi内の車両は、ゾーンi＋1内の一切の車両によってゾーンi＋2の空きチャネルが要求されてしまった後に残っている、ゾーンi＋2の空きチャネルがもしあれば、そのリストを知ることに関心がある。残っているゾーンi＋2の空きチャネルがある場合、それらのチャネルはゾーンi内の車両によって要求され得る。そのため、少なくとも1つの実施形態では、ゾーンi内の車両は、ここでは例えば、ゾーンi内で2次チャネルを要求するための空きチャネルの正しいリストを得るためにゾーンi＋1について、他のゾーン内の他の車両によって要求された2次チャネルを特定するかまたは知る。

前述の実施形態例では、与えられたゾーン（例えば、ゾーンi）内の車両は、それらの車両のゾーンの「前方の」ゾーン（例えば、ゾーンi＋1、i＋2など）から2次チャネルを要求するとして記載されている。ただし、これは限定を意味するものではない。車両は、他の任意のゾーンから、例えば車両のゾーンの「後方の」ゾーン（例えば、ゾーンi−1、i−2など）から2次チャネルを要求し得る。

与えられたゾーン内の車両による、ゾーン範囲内の車両の順序付け、またはゾーン境界に関する車両の相対的位置に基づくリソースの要求は、他のリソース共有またはアクセススキームを上回る利点を提供し得る。再度、少なくともいくつかの実施形態では、リソースの要求は、車両の実際の地理的位置ではなく、ゾーン範囲内の車両の相対的位置（例えば、順序付け）に基づく。車両の順序付けを使用することで、いくつかの実施形態の、車両の位置計測誤差に対する敏感さを軽減または取り除き得る。位置計測誤差の一例は、地理的位置を決定するGPSにおける誤差である。そのため、本開示の少なくともいくつかの実施形態では、たとえ大きな位置計測誤差でも、リソース要求パフォーマンスに顕著な、または些細な影響さえも与え得ない。例えば、車両が、その車両の位置をその車両の実際の位置から20メートル離れていると、間違って決定した場合、車両はこの間違った情報を近隣の車両にブロードキャストする。近隣は、本明細書では、別の車両の範囲、例えば認識範囲内にいる車両を意味するために使用する。車両は、その車両の位置を間違って決定してしまっているが、近隣にいるすべての車両は、同じ間違った位置を使用し、車両の同じ順序付けに到達することになる。そのため、間違った位置情報は、リソースコリジョンの可能性を必ずしも高めないことになる。

本開示の別の態様によれば、車両アドホックネットワーク内でリソースハンドオーバ状態を処理するために、1つまたは複数のアプローチが提供される。リソースハンドオーバという用語は、車両がゾーン間を移動するときに、車両によってどのようにしてリソースが要求されるのかに関する。

車両は、いくつかのリソース要求サイクルの間、同じゾーン内に留まり得る。いくつかの実施形態では、車両は、その車両が同じゾーン内に留まっている間、その車両の1次チャネルを保持し得、その車両の2次チャネルさえも保持し得る。ただし、いくつかの実施形態では、車両がたとえ同じゾーン内に留まっていたとしても、2次チャネルは開放され、いくつかの、または各リソース要求サイクルにおける要求のために利用可能にされ得る。

ただし、車両がゾーンを変更するとき、車両の1次チャネルは放棄され得、新たなゾーン内の新たな1次チャネルが取得され得る。ここで、少なくともいくつかの実施形態のいくつかの異なる可能性および状態を記載する。

図7A、図7B、および図7Cを参照し、それぞれは、仮想グリッド内の隣接している3つのゾーンi−1、i、i＋1を示している。図7Aは、車両AからEのためにフレームfにおいて行われるべき送信のための、フレームfー1におけるリソース要求を示している。図7Bは、フレームfで送信が起こるときの、さまざまなチャネルのステータスを示している。車両AおよびBは、ゾーンi−1からゾーンiへ移動していまい、車両Eは、ゾーンiからゾーンi＋1へ移動してしまっている。図7Cは、フレームf＋1において車両によって行われるべき送信のための、フレームfにおけるリソース要求を示している。

図7Aにおいて最も太い曲線の矢印で示されるように、フレームfにおいて、車両AからEのそれぞれは、1次チャネル、すなわち700、702、704、706および708を有している。また、車両Aは、ゾーンiから2次チャネル710を有しており、車両Dは、ゾーンi＋1から2次チャネル712を有している。

図7Bに示すように、車両A、BおよびEは、ゾーン間を移動し、それらの車両の1次チャネル700、702および708は、ステータスを変更して一時的チャネルとなり、破線の矢印で示されている。車両A、BおよびEは、フレームfの間、ブロードキャストするためにそれらの車両の1次チャネルをまだ使用し得る。また、車両Aの2次チャネル710のステータスは、図7Bにおいて太い矢印線710で示されるように、2次チャネルから1次チャネルへ変化する。このチャネルはゾーンiに属しているので、そのチャネルは車両Aの1次チャネルになり得る。

図7Cは、フレームf＋1において行われるべき送信のための、フレームfにおける車両のためのリソース要求を示している。図7Bに示す、車両A、BおよびEそれぞれの一時的チャネル700、702および708は、車両が別のゾーンにいたときに、それらのチャネルが1次チャネルとして以前に要求されたため、放棄される。車両A、CおよびDは、それらの車両の1次チャネル、それぞれ710、704および706を保持し得る。新たなゾーンへ移動した後、図7Bに示すように、車両BおよびEは、1次チャネルを有していない。そのため、図7Cに示すように、車両BおよびEは、フレームf＋1のために1次チャネル714および716をそれぞれ要求し得る。チャネル714および716は、車両BおよびEのそれぞれのゾーン、すなわちゾーンiおよびi＋1に属している。1次チャネル714は、前述したように車両の相対的位置に基づくゾーンi内の車両の順序付けに基づくことを含んで、任意の適切な方法で要求され得る。1次チャネル716は、ゾーンi＋1のチャネルの中から類似の方法で要求され得る。

さらに、車両は、1つまたは複数の2次チャネルも要求し得る。例えば、図7Cに示すように、車両CおよびBは、フレームf＋1のために2次チャネル718および720をそれぞれ要求し得る。これらの2次チャネルも、例えば車両の相対的位置に基づいた、ゾーンi内の車両の順序付けに基づくことを含んで、任意の適切な方法で要求され得る。例えば、車両BおよびCは、ゾーンiの右ゾーン端750に対する近さに基づいて順序付けされ得る。こうした場合、その順序付けは、Cその次にBということになるだろう。結果的に、少なくとも1つの実施形態では、車両Cは、ゾーンi＋1から空きチャネルを2次チャネルとして要求することにおいて、車両Bに優先することになるだろう。

図8は、本開示の少なくとも1つの実施形態に係る、ハンドオーバ状態を処理するためのプロセスを示すフロー図である。ハンドオーバ処理は、車両アドホックネットワーク内のすべての車両において実行され得る。このように、車両のそれぞれは、車両が1つのゾーンから別のゾーンへ移動する結果としての、1つまたは複数のチャネルの、開放および要求を追跡することができ得る。

プロセスは、ブロック800から始まって、ゾーンi内に位置している車両がフレームfにおいてアクティブなチャネルをリッスンするブロック802へ進む。これらのチャネルは、異なるK個のゾーン、例えば車両の認識範囲内のゾーンに属し得る。車両は、ゾーン上のチャネルをゾーン毎に分類し得、ここで、考慮されているゾーンは、「j番目」のゾーンと称される。一実施形態では、車両は、フレームf＋1における通信のためにフレームfにおいてK個のゾーンのj番目のゾーンのチャネルを、以下の表4に従って分類し得る。

表4では、PCHは1次チャネルであり、同じゾーン内の車両によって使用されるチャネルを意味している。SCHは2次チャネルであり、別の（例えば、前の）ゾーン内の車両によって使用される第1のゾーンのチャネルを意味する。この例では、あらゆる2次チャネル（SCH）は開放され（例えば、空きチャネルになる）、次のリソース要求サイクルのために利用可能にされる。ただし、前述したように、他の実施形態では、2次チャネル（SCH）は、1つを超えるリソース要求サイクルの間車両によって要求されたままであり得る。ゾーンi＋1からi＋Uは、ゾーンiの前方のゾーンであり、車両の認識範囲内にあるものと仮定される。そのため、ゾーンqはゾーンi＋1からi＋Uの範囲内のゾーンである。ゾーンi内の車両は、ゾーンi＋1からゾーンi＋Uの1つまたは複数から、1つまたは複数のチャネルを2次チャネルとして要求する可能性があり得ることも仮定される。

TCHは、一時的チャネルである。I−TCHは、入ってくる一時的チャネルをいい、O−TCHは出て行く一時的チャネルをいう。一時的チャネルは、車両が出発したばかりのゾーン（例えば、前のゾーン）にチャネルが属している、新たなゾーンに到着する車両によって使用されるチャネルである。そのため、新たなゾーンの観点からすると、一時的チャネルは、入ってくる一時的チャネル（I−TCH）である。前のゾーンの観点からすると、そのチャネルは、出て行く一時的チャネル（O−TCH）である。TCHは、次のリソース要求サイクルにおける要求のために即座に開放され得る。ただし、別の実施形態では、TCHは一定の状態において、例えば、車両が新たな1次チャネル（PCH）を見つけることができない場合には、車両によって保持され得る。これは、車両が、異なるゾーンへ移動したときに、車両がブラインドかまたはハンドオーバ状態にある場合など、何らかの理由で起こりえる。f−CHは、空きチャネルであり、次のフレーム（例えば、フレームf＝f＋1）における要求のために空いていると仮定されるチャネルを意味する。

同様に、車両は、ゾーン上の別の車両をゾーン毎に分類し得、ここで再度、考慮されているゾーンは、「j番目」のゾーンと称される。したがって、少なくとも1つの実施形態では、フレームfにおいてアクティブなチャネルをリッスンしている、ゾーンj内に位置している車両は、以下の表5に従って車両を分類し得る。

表5では、L−車両はローカルな車両であり、その車両が聴取されるときに1次チャネル（PCH）を有する車両を意味する。I−車両は入ってくる車両であり、直近にゾーンに到着したハンドオーバ車両で、その車両がPCHチャネルをまだ有していないことを意味する。O−車両は出て行く車両であり、出て行く一時的チャネル（O−TCH）を有しながら、直近にゾーンを離れてしまっているハンドオーバ車両を意味する。h−車両は、ハンドオーバ車両である。ゾーンの観点からすると、ハンドオーバ車両は、I−車両か、またはO−車両である。

再度、図8を参照して、プロセスは、ブロック802から、ゾーンjの1つまたは複数の車両が分類され得るブロック806へ進む。少なくとも1つの実施形態では、ゾーンjの車両は、一度に1つ考慮され得る。詳細には、分類されている車両は、ゾーンjのx番目の車両と称され得る。そのため、ブロック806では、ゾーンjのx番目の車両がローカルな車両（L−車両）かどうかを判定し得る。x番目の車両がゾーンjのL−車両である場合、プロセスは808へ進み、そこでは、x番目の車両は、フレームf＋1における送信のためにその車両の現在の1次チャネル（PCH）を保持するものと仮定される。ただし、x番目の車両がゾーンjのL−車両でない場合、プロセスは810へ進み、そこでは、x番目の車両は、ゾーンjのハンドオーバ車両群（h−車両−Set）に加えられる。

ブロック808および810の両方から、プロセスは、ゾーンj内に他の車両（例えば、まだ分類されていない他の車両）があるかどうかを判定するブロック812へ進む。ゾーンj内に少なくとも1つの他のアクティブな車両がある場合、プロセスは、ブロック806へ戻り、次の車両（x＋1番目の車両）が考慮される。ただし、他にアクティブな車両がない場合は、プロセスは、ブロック814へ進み、そこでは、ゾーンjについてのh−車両−Setの中の車両が、任意の適切な方法で順序付けられ得る。車両は、互いに対するそれらの車両の相対的位置に基づいて順序付けられ得る。例えば、前述のように、車両は、ゾーンjの右ゾーン端に対するそれらの車両の距離に基づいて、昇順で順序付けられ得る。ここでは、説明目的のために、車両がゾーン内を左から右へ走行していると仮定している。ただし、h−車両−Setの中の車両は、任意の他の適切な方法で順序付けられてもよい。

プロセスは、ブロック814からブロック816へ進み、そこでは、ゾーンjのy番目のチャネルがゾーンjの1次チャネル（PCH）かどうかが判定される。y番目のチャネルが1次チャネルである場合、プロセスは、ブロック820へ進む。y番目のチャネルが1次チャネルではない場合、プロセスは、818へ進み、そこでは、そのチャネルはゾーンjの空きチャネル群（f−CH−Set）に加えられる。

プロセスは、次いで、ブロック818からブロック820へ進み、そこでは、分類されるべき他のチャネルがゾーンj内にあるかどうかが判定される。少なくともあと1つのチャネルがゾーン内にある（例えば、いずれかのチャネルがまだ分類されていない）場合、プロセスは、ブロック816へ戻り、次のチャネル（y＋1番目の車両）が考慮される。さらなるチャネルがないとき、プロセスは、ブロック820からブロック822へ進み、そこでは、f−CH−Set内のチャネルが順序付けられ得る。前述のように、チャネルは、それらのチャネルのチャネルインデックスに基づいて、昇順または降順で順序付けられ得る。ただし、h−CH−Setの中のチャネルは、任意の他の適切な方法で順序付けられてもよい。

プロセスは、ブロック822からブロック824へ進み、そこでは、図8のプロセスを実行する車両は、ゾーンjのh−車両−Set内の車両によって1次チャネルとして要求される、ゾーンjのf−CH−Set内の空きチャネルを特定し得る。再度、他の車両によって空きチャネルがどのようにして要求されるかを特定する車両は、他の車両に関連する情報および共通のチャネル共有アルゴリズムを使用してそうし得る。そのため、車両は、他の車両によるチャネルの要求を、他の車両からの要求に関するインディケーションを一切受信することなく推定することができ得る。いくつかの例では、ゾーンjの空きチャネル群f−CH−Set内の必ずしもすべてのチャネルが、ゾーンj内の車両によって1次チャネルとして要求され得る訳ではないが、これらのチャネルは他のゾーン内の車両によって2次チャネルとして要求され得、空きチャネルの特定は、リソースコリジョンの回避において重要である。

車両によってチャネルが要求される方法は、ゾーン範囲内のそれらの車両の相対的位置に基づいて順序付けられた、ゾーン内の車両のリストに基づいて1次チャネルを要求する、本明細書に記載の方法を含んで、任意の適切な方法で行われ得る。例えば、順序付け済の車両のリスト内の一番上にある車両が優先されて、順序付け済のf−CH−Setから第1のチャネルを要求し得る。その車両およびチャネルは、それぞれh−車両−Setおよびf−CH−Setから削除される。チャネル要求は、次いで、同じ方法で継続し、順序付け済の車両のリストの一番上にある1番目の車両が優先されて、順序付け済のf−CH−Setの一番上にあるチャネルを要求する。少なくとも1つの実施形態では、このチャネル要求プロセスは、繰り返して行われ得、そこでは、h−車両−Set内の車両は、f−CH−Setからチャネルを要求し、次いで、車両およびチャネルの両方が、その車両およびチャネルそれぞれのh−車両−Setおよびf−CH−Setから削除される。次いで、h−車両−Set内の次の車両が、f−CH−Set内に残っているチャネルの中からチャネルを要求する。ただし、他の実施形態では、チャネル要求は、繰り返して実行される必要はない。

ブロック824における、他の車両によって要求されるチャネルを特定する手順は、例えば、h−車両−Set内のすべての車両がチャネルを要求してしまうか、またはf−CH−Set内のすべての空きチャネルが要求されてしまうかまで継続し得る。プロセスは、次いでブロック826へ進み得、そこでは、K個のゾーン群内に分類されるべき他のゾーンがあるかどうかが判定される。少なくともあと1つのゾーンがある場合、プロセスはブロック806へ戻り得る。ただし、分類すべきさらなるゾーンがない場合は、プロセスはブロック828へ進み、終了し得る。

図8の実施形態は、プロセス内に特定の数および順序のステップを示しているが、これは限定を意味するものではない。例えば、ステップの順序は、別の実施形態では異なり得る。また、いくつかの実施形態では、いくつかのステップが、シーケンシャルではなくパラレルに実行され得る。例えば、与えられたゾーンの車両のすべておよびチャネルのすべてを分類することが、パラレルに行われ得る。他のオプションが可能である。

図9は、本開示の少なくとも1つの実施形態に係る、車両アドホックネットワーク内の車両における位置順のリソース要求のための一般的なプロセスを示すフロー図である。プロセスは、1次および2次チャネル要求ならびにハンドオーバ処理を含む。車両は、その車両自身のために1つまたは複数のチャネルを要求し得る。また、車両は、その車両の認識範囲内の他の車両によって要求され得る空きチャネルを、他の車両の位置に基づいて特定し得る。そのため、車両は、おそらくその車両自身のためのチャネルを要求するため、および他の車両によって要求された他のチャネルを特定するために、その車両自身の位置、ならびに他の車両から受信した位置およびおそらく他の情報を使用し得る。各車両は、他の車両についての同じかまたは類似した情報を取得することから、および、各車両は、共通のチャネル共有アルゴリズムを実施することから、車両は、リソースコリジョンの可能性が低い状態でチャネルを共有するために協調し得る。

少なくともいくつかの実施形態では、図9のプロセスにおけるいくつかのステップは、ステップを実行する車両の認識範囲内の1つまたは複数のゾーン内の、車両およびチャネルの、特定および分類を含めて、図8のプロセスにおける1つまたは複数のステップと関係があり得る。

プロセスは、ブロック900から始まって、そこでは、車両はゾーンiに位置しており、時刻は時間フレームfである。当業者は、時間フレームfへの参照は、特定のデータフレームが送信される時間ウィンドウへの参照であると理解することができることを理解するだろう。ウィンドウは、単一のフレームの送信時間よりも長くすることができるが、一般に、より短くはない。プロセスは、ブロック902へ進み、そこでは、車両は、その車両の1つまたは複数の要求済のチャネル上で送信し得、ゾーンiの他のチャネル上および他のゾーンの1つまたは複数のチャネル上でリッスンもし得る。

プロセスは、ブロック902からブロック904へ進み、そこでは、ゾーンiおよび他の近隣のゾーンのアクティブなチャネルが特定され得る。これらのアクティブなチャネル上で送信する車両の位置も決定され得る。いくつかの実施形態では、車両は、現在の送信期間においてどのチャネルがアクティブかを、以前の送信期間において得た情報に基づいてすでに知り得る。ノードは、他のノードがどこにあるのか、およびそれらの他のノードが使用するチャネルを知り得ることから、非常に高い可能性で、どのチャネルが予約されてしまっているのかを判定することが可能であり得る。こうした判定は、アクティブなチャネルを明示的に特定することを避けるために使用することができる。ただし、別の状態では、車両は、一部またはすべてのチャネルのアクティブなステータスを知るための十分な情報を有していない場合がある。こうした場合、車両は、少なくとも部分的には「ブラインド」である。こうした状態、または車両が別の状態でネットワークに入る必要がある場合は、車両は、アクティビティ検出プロセスをとおしてアクティブなチャネルを独自に特定し得る。

プロセスは、次いで、ブロック906へ進み、そこでは、車両の認識範囲内の一部またはすべてのゾーンについて、1次チャネルを有していない車両および空きチャネルの両方が特定される。詳細には、与えられたゾーンの範囲内にいて1次チャネルを有していない、V2Vネットワークに関与しているすべての車両は、そのゾーンのh−車両−Setに加えられ得る。h−車両−Set内の車両は、次いで、任意の適切な方法で、例えば、前述のように、ゾーン範囲内のそれらの車両の相対的位置に基づいて、順序付けられ得る。また、認識範囲内のゾーンの各ゾーンの範囲内のアクティブなチャネルの中の1次および2次チャネルが特定され得る。空きチャネル群（f−CH−Set）は、認識範囲内のゾーンの各ゾーンについて、特定のゾーンの非アクティブおよび2次的にアクティブなチャネルの集合として決定される。少なくとも1つの実施形態では、f−CH−Set内のチャネルは、任意の適切な方法で、例えば、チャネルインデックスに基づく昇順で、順序付けられ得る。 方法のいくつかの実施形態では、V2Vネットワークの一部ではないレガシー車両は、h−車両−Setへの指定から除外される。

プロセスは、ブロック906からブロック908へ進み、そこでは、1次チャネルが要求される。図9のブロック908では、認識範囲内の各ゾーンについて、ゾーンのh−車両−Set内にない、特定のゾーンの車両は、フレームf＋1における送信のためにそれらの車両の1次チャネル（PCH）を保持し得る。一方、ゾーンのh−車両−Set内の車両は、そのゾーンのチャネルを1次チャネルとして要求し得る。h−車両−Set内の車両の順序付けは、前述のように、1次チャネルの要求の優先順位を付けるために使用され得る。例えば、順序付け済のh−車両−Set内の1番目の車両は、優先してf−CH−Setから空きチャネルを要求し得る。順序付け済のh−車両−Set内の2番目の車両は、2番目に優先してf−CH−Setから空きチャネルを要求し得る、などとなる。車両は、他の車両によって1次チャネルとして要求された空きチャネルを、他の車両についての情報（例えば、それらの車両の位置など）およびチャネル共有アルゴリズム（例えば、ゾーン内の相対的な車両位置など）を使用して特定し得る。いくつかの実施形態では、このチャネル要求プロセスは、前述の、図8のブロック824の1次要求プロセスに類似し得る。そのため、ブロック824の記述は、ここでは完全には繰り返されない。

プロセスは、908から910へ進み、そこでは、利用可能な場合、車両によって2次チャネルが要求され得る。車両は、他の車両によって2次チャネルとして要求された空きチャネルを、他の車両についての情報（例えば、それらの車両の位置など）およびチャネル共有アルゴリズム（例えば、ゾーン内の相対的な車両位置など）を使用して特定することができ得る。2次チャネルは、本明細書に記載の方法を含んで、任意の適切な方法で要求され得る。例えば、ゾーン内の車両が順序付けられ得、次いで、2次チャネルが順序付けに基づいて1つまたは複数の車両によって要求され得る。少なくとも1つの実施形態では、車両は、一度に最大1つの2次チャネルを要求し得る。ただし、別の実施形態では、車両は、複数の2次チャネルを要求し得る。複数の2次チャネルは、同じゾーンまたは2つ以上の異なるゾーンに属し得る。

プロセスは、ブロック910から912へ進み、そこでは、フレームfはインクリメントされ、例えばf＝f＋1となる。

プロセスは、ブロック912からブロック902へ進み、そこでは、プロセスが再スタートし得る。

本開示の別の態様によれば、ブラインド車両の回復を可能にするために、1つまたは複数のアプローチが提供される。

車両が、必要な機能、例えば、やってくるフレーム（例えば、フレームf＋1など）のためのリソース要求を、その車両が実行することを可能にするための十分な情報を受信できないとき、その車両は、情報が不足しているので、少なくとも部分的に「ブラインド」である。そのため、車両は、その車両の環境を完全に把握していない。車両は、車両が1つまたは複数の他の車両からの情報の受信またはデコードに成功しなかったことを含む、1つまたは複数の理由により十分な情報を有していない場合がある。その結果として、車両は、やってくるフレームにおいて、どのチャネル上でブロードキャストするべきかについて知らない場合がある。車両は、いくつかの車両の位置またはいくつかの車両によるチャネルの要求を知らない場合もある。

ブラインド車両は、1次チャネルを有しているかもしれないが、2次チャネルとしての使用に利用可能な、ゾーンi＋1（または、ゾーンi＋2、i＋3などの、1つまたは複数の別のゾーン）内の1つまたは複数の空きチャネルがあるかどうかを判定するための十分な情報を有していない場合がある。車両回復とは、ブラインド車両に、1つまたは複数の他のゾーン内のチャネル使用についての情報を提供するプロセスをいう。例えば、ゾーンi内のブラインド車両は、ゾーンi＋1、i＋2、i＋3などのうちの1つまたは複数についてのチャネル使用情報を認識させられ得る。

一方、1次チャネルを有していない車両は、「新た」であると見なされるので、少なくともいくつかの実施形態では、1次チャネルを要求または割り当てられるために、ネットワークエントリ手順を踏む必要があり得る。

ブラインド車両回復は、いくつかの異なる状態において提供され得る。例えば、ブラインド車両回復は、非ハンドオーバのブラインド車両に対して提供され得る。非ハンドオーバの車両は、現在のフレームにおいて新たなゾーンに移動してしまっていない車両である。ブラインド車両回復を処理するための少なくとも1つの実施形態では、1つまたは複数の時間フレームは、ブロードキャストチャネルを含み得る。図10は、1つまたは複数のフレーム1000の第1のサブフレーム1002内にこうしたブロードキャストチャネル1004を有する一実施形態における、いくつかのフレーム1000を示している。ブロードキャストチャネル1004は、与えられたゾーン（例えば、ゾーンi＋1）内の1つまたは複数の空きチャネルを、近隣のゾーン（例えば、ゾーンi）内のブラインド車両などの車両に対して示す情報を含み得る。ブロードキャストチャネル1004は、図10に示すように、フレーム1000の始まりまたはその近くに、またはフレーム範囲内の他のいかなる位置にも位置し得る。

ブロードキャストチャネル1004は、特定の無線リソースを予め定義することによって構成され得、例えば、SCMAレイヤなどの予め定義されたSparse Code Multiple Access（SCMA）リソースを含むがこれには限定されない。

ゾーン（例えば、ゾーンi＋1）のブロードキャストチャネル1004上でのブロードキャストは、そのゾーン内の車両によって実行され得る。少なくとも1つの実施形態では、ゾーン内の車両は、ゾーンのチャネル1004上にブロードキャストするマスタ車両としての役割を果たし得る。車両は、任意の適切な方法でマスタ車両になり得る。例えば、一実施形態では、1つまたは複数の車両は、ゾーン内におけるそれらの車両の相対的位置に基づいて自律的にマスタ車両になり得る。例えば、少なくともいくつかの実施形態では、ゾーン端など、ゾーン内の基準位置に物理的に最も近い1つまたは複数の車両が、マスタの役割を担い得る。いくつかの実施形態では、例えば、ゾーンi＋1の左ゾーン端に最も近い、ゾーンi＋1内の車両が、ゾーンi内のブラインド車両に対して最も近い車両であることになるように、1つまたは複数の車両が、この方法でマスタとなり得る。ただし、1つまたは複数の車両がマスタ車両になり得る他の方法が想定される。

そのため、ゾーンi内の1つまたは複数のブラインド車両は、ゾーンi内のブラインドノードによって2次チャネルとして使用され得る、1つまたは複数の他のゾーン（例えば、ゾーンi＋1）の一切の空きチャネルを特定するために、1つまたは複数の他のゾーン（例えば、ゾーンi＋1）のブロードキャストチャネルをリッスンし得る。このように、ブラインド車両は、以前は欠けていた、他のゾーン内の空きチャネルについての情報（例えば、チャネル、位置など）を受信する。新たな情報は、次いで、車両が1つまたは複数の2次チャネルをおそらく要求することを可能にし得る。

また、少なくとも1つの実施形態では、ブロードキャストチャネル1004上でのブロードキャスト情報の結合送信が、複数のマスタ車両を有することによって可能にされ得る。結合送信は、ゾーン内のマスタ車両間の協調を使用して実施され得る。通常は、マスタ車両は非ブラインドノードである。

さらに、与えられた範囲内の異なるゾーンのブロードキャストチャネルは、無線リソース間の支障を低減するために異なる無線リソースを占有し得る。

別の例では、ブラインド車両回復は、1つまたは複数のハンドオーバのブラインド車両に対して提供され得る。ハンドオーバの車両は、その車両の出て行くゾーンから要求された1次チャネルを有し得るが、入ってくるゾーン内のすべての空きチャネルの情報を有していない場合がある。少なくとも2つの状態が可能であり得る。第1の状態では、車両は、その車両の入ってくるゾーンに属する空きチャネルから2次チャネルを決定することができない場合がある。そのため、ハンドオーバの際に、車両は、次のリソース要求サイクルにおいて、入ってくるゾーン内でその車両の1次チャネルになることができる2次チャネルを有していない。第2の状態では、車両が、入ってくるゾーン内の空きチャネルの完全な情報を有していないので、その車両が、入って来るゾーン内で新たな1次チャネルを決定できない場合がある。非ブラインドハンドオーバでは、車両は入ってくるゾーン内の空きチャネルの完全な情報を有し得ることから、これは、非ブラインドハンドオーバ状態とは異なり得る。これは、車両が、次のリソース要求サイクルにおいて新たな1次チャネルを要求することを可能にし得る。どちらの状態においても、車両は、次のリソース要求サイクルまでその車両の1次チャネルを保持し得るが、前述のように、1次チャネルのステータスは、その車両が、その車両の出て行くゾーンを離れるときに、一時的チャネルのステータスに変化し得る。

少なくとも1つの実施形態では、ハンドオーバのブラインド車両の回復は、ハンドオーバの際に、ネットワークへのその車両の迅速な再エントリを提供することによって可能にされ得る。迅速な再エントリは、ゾーンiからゾーンi＋1へのハンドオーバの際に、ブラインド車両に、その車両の1次（一時的な）チャネルをとおした送信で、その車両の「ブラインドであること」を示させることによって可能にされ得る。ゾーンi＋1の1つまたは複数のマスタ車両は、次いで、1つまたは複数のハンドオーバのブラインド車両に対して、ゾーンi＋1の1つまたは複数の空きチャネルを示し得る。このインディケーションは、ブロードキャストチャネルなど専用の時間―周波数リソースをとおすことを含んで、任意の方法で提供され得る。

別の実施形態では、ゾーンi＋1が空で、ゾーンi＋1に、ゾーンi＋1のブロードキャストチャネル上で情報を送信するマスタの役割を果たす車両がないことを意味するときに、ゾーンi内の1つまたは複数のブラインド車両のためにブラインド車両回復が提供され得る。結果的に、ゾーンi内のブラインド車両は、ゾーンi＋1のチャネルを単に使用し得るだけである。ブラインド車両は、2つ以上のブラインド車両が同じチャネル上で送信しようとしたときにリソースコリジョンを引き起こす可能性を低減または取り除くために、いくつかの予め存在する基準、例えば予め定義された規則、予め定義されたマッピングなどに基づいて、ゾーンi＋1の特定のチャネルを使用し得る。少なくとも1つの実施形態では、ブラインド車両は、特定のチャネルインデックスに基づいてチャネルを使用しようとし得る。別の実施形態では、ブラインド車両は、1つまたは複数の予め定義されたチャネルローテーションパターンに基づいてチャネルを使用しようとし得る。他のチャネル選択のオプションが使用されてもよい。

本開示の別の態様によれば、1つまたは複数の車両が車両アドホックネットワークに入ることを可能にするために、1つまたは複数のアプローチが提供される。車両は、いくつかの異なる状態において、例えば、その車両が他の車両の通信範囲内に到着したとき、その車両がその車両の通信サブシステムを有効にしたとき、などに、ネットワークに入り得る。ネットワークに入ろうとする車両は、新たな車両と称され得る。

少なくとも1つの実施形態では、マスタ車両など、1つまたは複数の他の車両は、新たな車両の位置、およびその新たな車両のための1つまたは複数のチャネルの特定のいずれかまたは両方を、ブロードキャストまたは別の方法でアナウンスするために使用され得る。他の車両が新しい車両の存在または位置を認識していない間、新たな車両は送信を開始できない場合があるので、これらの1つまたは複数の他の車両が、新たな車両についての情報をブロードキャストするために使用され得る。これにより、すでにネットワーク内にいる他の車両が、新たな車両についての情報、例えばその新たな車両の存在、位置、チャネルなどを知ることを可能にし得る。

新たな車両がネットワークにアクセスしようとしているとき、新たな車両は、例えばマシンIDまたは媒体アクセス制御アドレス（MACアドレス）の代わりに、その車両の地理的位置をユニークなネットワーク識別子として使用し得る。車両の位置を表すx−y座標などの地理的座標は、車両についてのユニークな識別子としての役割を果たし得る。一時的な識別子が使用される短い期間に、2つの車両が同一のx−y座標を有するであろう可能性は非常に低い。ただし、他のいかなるタイプの識別子も使用され得ることが理解されるべきである。

一例の実施形態を図11Aを参照しつつ記載しており、いくつかのフレーム1100 f、f＋1、f＋2を示しており、それぞれがサブフレーム1102を有しており、フレーム1100の少なくともいくつかは、前述のようにブロードキャストチャネル1104を有している。ネットワークに入ろうとしている、ゾーンi内の車両は、時間フレームfにおいて到着し、ブロードキャストチャネル1104をリッスンする。車両は、いくつかの目的のため、例えば、ネットワークエントリのための候補ゾーンを決定するため、ネットワークとタイミング同期を達成するため、または特定のブロードキャストチャネルと関連付けられたゾーンの1つまたは複数の空きチャネルを特定するために、ブロードキャストチャネルをとおして送信された情報を使用し得る。ノードが、複数の異なるブロードキャストチャネルをリッスンすることが可能であり、各チャネルは異なるゾーンに関連付けられている。

新しい車両は、後続のフレーム、例えばフレームf＋1の間に、ゾーンi内の他のいかなる車両の送信（例えば、ブロードキャスト、ビーコン送信など）もリッスンし得る。これにより、車両が、ゾーンiについての情報、例えばそのゾーン内の他の一切の車両の位置を決定することを可能にし得る。

新たな車両は、次いで、後続のフレーム、例えばフレームf＋2の間に、ネットワークに入ろうとし得る。車両は、ネットワーク・エントリ・リクエストをゾーンi内の1つまたは複数のマスタ車両へ送信し得る。エントリ・リクエストは、車両の位置および他のいかなる情報も含み得る。1つまたは複数のマスタ車両は、この情報を受信し得、次いで今度は、1つまたは複数の新たな車両の位置、および1つまたは複数の新たな車両のそれぞれについての1次チャネルの特定をブロードキャストし得る。

マスタ車両によってブロードキャストされた情報は、1つまたは複数の新たな車両、およびゾーンi内の他の車両によって受信され得る。新たな車両は、1つまたは複数のマスタ車両からのブロードキャストに基づいて、その新たな車両がネットワークへ入るのに成功したかどうかを判定し得る。例えば、新たな車両は、マスタ車両のブロードキャストがその車両のための1次チャネルの特定を示す場合に、エントリの試みが成功していることを判定し得る。一方、エントリの試みが成功でなかった場合、車両ネットワークに入ろうと再度試みる。少なくとも1つの実施形態では、リトライメカニズム、例えばランダムバックオフまたは任意の他の適切な方法が使用され得る。

新たな車両と1つまたは複数のマスタノードとに間の初期交換は、任意の適切な方法で実行され得る。例えば、特定の時間―周波数無線リソースが、この目的のために定義されるかまたは専用であり得る。少なくとも1つの実施形態では、初期交換は、ランダム・アクセス・チャネル（RACH）手順に類似した方法で実行され得る。したがって、いくつかの実施形態では、1つまたは複数のランダム・アクセス・チャネルが、この目的のために定義され得、1つまたは複数の時間スロットにおいて構成され得る。少なくとも1つの実施形態では、図11Aに示すように、1つまたは複数のスロット1106は、この目的のために、例えば、フレームfなど、時間ウィンドウの始まりまたはその近くにおいて構成される。他の実施形態では、初期アクセス送信は、初期交換専用のチャネルとは対照的に、1つまたは複数の他の共有チャネルをとおして実行され得る。ブロードキャストチャネルを有する実施形態では、ブロードキャストチャネルおよびネットワーク・エントリ・ランダム・アクセス・チャネルは、異なる時間スロット内に構成されるか、または他の異なる時間―周波数リソースを使用している場合がある。ただし、無線リソースは、任意の他の適切な方法で、初期交換のために定義または構成され得る。

図11Bは、ネットワークエントリ状態における、ゾーン内の新たな車両と他の車両との間の、少なくとも1つの実施形態における、いくつかの可能な送信を示すデータフロー図である。送信のいくつかは前述されている。

この例では、車両1152、1154および1156は、時間フレームfにおいて新たな車両1150が到着したとき、ゾーン内にいる。車両1152は、ゾーン内でマスタ車両の役割を果たしている。フレームfにおいて、新たな車両1150は、1つまたは複数のゾーンのブロードキャストチャネル（ブロードキャストCH）、ここではブロードキャスト1160をリッスンする。ブロードキャスト1160の性質に起因して、そのブロードキャストはすべてのノードへ送られるが、新たな車両1150に関して、以下の議論がプロセスに関わってくるであろう。新たな車両1150は、次いで、ゾーン内の他の車両の送信（例えば、ブロードキャストなど）をリッスンし得、フレームf＋1において、車両1156、1154および1152からそれぞれビーコン送信1162、1164、および1166を受信することになる。この図では、ビーコン送信は通常はブロードキャスト信号であるため、ビーコン送信はすべてのノードへ送られているように示している。ただし、ビーコンがブロードキャストされない実施形態では、フローは図示されているのとは異なることになる。当業者には、ビーコン送信の受信の順序が、図11Bに示されるものと異なることができることは明らかなはずである。

フレームf＋2において、新たな車両1150は、ネットワークへ入ろうとする。車両1150は、その車両の位置を含んだネットワーク・エントリ・メッセージ1168を、例えばランダム・アクセス・チャネル（RACH）、または初期交換のための他のチャネルをとおしてマスタ車両1152へ送信する。いくつかの実施形態では、ネットワーク・エントリ・メッセージ1168は、ノードの位置だけよりも多くの情報を含むことができる。ネットワークエントリが成功であった場合、マスタ車両1152は、応答送信1170の中で、新たな車両1150の位置、およびその新たな車両の新たなチャネルの特定を他の車両へブロードキャストすることにより応答することができる。送信1170は、ブロードキャストメッセージとして示されている。メッセージ1170をブロードキャストすることによって、車両1154および1156は、新たな車両1150およびその新たな車両が使用することになるチャネルについての情報を提供される。エントリの試みが成功でなかった場合、車両1150はネットワークに入ろうと再度試みることができる（図示せず）。

本開示の別の態様によれば、アドホックネットワーク内のリソースは、Sparse Code Multiple Access（SCMA）変調および波形に基づいて定義され得る。

少なくともいくつかの実施形態では、SCMAベースのリソース定義および他の特徴を使用することにより、例えば符号分割多重アクセス（CDMA）に基づくものを含む既存のアプローチを超える1つまたは複数の利益を提供し得る。1つの利益は、接続性の向上であり得、SCMAリソース定義（例えば、SCMAレイヤなど）の結果として、より多くのチャネルが定義され得、使用可能にされ得ることを意味する。SCMAを用いて、車両または他のノードは、キャリア検知とは対照的にコードブック／パイロット検知を実行するので、別の利益は、通信に関する信頼性の向上およびより低い遅延のいずれかまたは両方であり得る。別の利益は、SCMAが、競合ベースの多重アクセスを可能にするためにブラインド検出をサポートしていることであり得る。このことは、ネットワークエントリにおいて、アクティブなチャネルおよびそれらのチャネルのデータを特定するのに役立ち得る。それは、回復プロセスにおいてブラインドノードがアクティブなチャネルを特定するのにも役立ち得る。それは、システム内でランダムアクセスを実行するブラインドノードまたは新たなノードに起因するチャネルコリジョンに対するロバスト性をさらに向上させ得る。

Sparse Code Multiple Access （SCMA）は、バイナリ・データ・ストリームを多次元のコードワードに直接符号化する符号化技術である。バイナリデータを多次元のコードワードに直接符号化することにより、SCMA符号化は、直交振幅変調（QAM）シンボルマッピングを回避し、従来のCDMAを超える符号化利得を提供することができる。SCMAは、QAMシンボルではなくて多次元のコードワードを使用してバイナリデータを搬送し得る。また、SCMAは、多重化されたレイヤの異なるコードブックを異なるユーザに割り当てることをとおして多重アクセスを提供し得る。さらに、SCMAコードブックは、レシーバが、多重化されたコードワードの中からそれらのレシーバそれぞれのコードワードを検出するために低複雑度のメッセージ受渡しアルゴリズム（MPA）を使用し得るように、わずかなコードワードを含み得る。これにより、レシーバ側でのベースバンド処理の複雑度を低減することができる。

SCMAベースのリソース定義を使用している一例の実施形態を図12に示す。いくつかのサブフレーム1202を有する、一例のフレーム1200を示しており、各サブフレームはいくつかのスロット1204を有し得る。スロットは、1つまたは複数のSCMAレイヤ1206に細分され得る。図12では、スロットがJ個のレイヤを有することを示している。再度、SCMAでは、多重化された異なるレイヤを異なるユーザに割り当てることをとおして多重アクセスを提供し得る。

少なくとも1つの実施形態では、チャネルは、1つのスロットと1つのレイヤの少なくとも1つの組合せとして定義され得る。例えば、図12では、1つのチャネルは、スロット2、レイヤ3として定義され得る。別のチャネルは、スロット2、レイヤ4として定義され得る、などである。結果的に、m個のスロット1204を有するサブフレーム1202、およびJ個のレイヤ1206を有するスロット1204は、m×J個の異なるチャネルを定義し得る。

さらに、2つ以上の車両が、同じSCMAレイヤおよびスロット、例えばスロット2、レイヤ6を使用するチャネルを要求し得ることが可能であり得る。少なくともいくつかの実施形態では、これらの車両は、リソースコリジョンを回避するために、例えば分散環境において異なるパイロット1208を使用することができ得る。これにより、たとえSCMAコードブックのコリジョンが発生した場合にでも、パイロットコリジョンの可能性を低減し得る。特に、SCMAシステムは、パイロットコリジョンが回避される限り、コードブックのコリジョンに対してロバスト性がある。つまり、コードブック再利用は、SCMA実施において許容可能であり得る。

前述したものなどのSCMAのリソース定義は、全二重モードで動作することができる車両でのみ機能し得る。例えば、同じ時間スロットの間に送信する2つの車両は、SCMAレイヤにおいて分けられ得るが、両方の車両が全二重モードで動作しない限り、この時間スロットの間、その2つの車両は互いにリッスンすることができないかもしれない。

本開示の別の態様によれば、アドホックネットワーク内の車両のための仮想全二重モードを実現するために、1つまたは複数のアプローチが、図13を参照しつつ以下に提供される。

いくつかの車両アドホックネットワークでは、少なくともいくつかの車両は半二重であり、それらの車両は送信およびリッスンを同時に行うことができないことを意味する。結果的に、2つ以上の車両がそれぞれ、おそらくは異なるレイヤではあるものの、同じスロット内でチャネルを要求するとき、これらの車両は同時に送信するので、お互いをリッスンすることができない場合がある。

少なくともいくつかの実施形態では、半二重の車両は、単一のサブフレームの間、送信および他の車両のリッスンの両方を行うことができ得る。半二重のノードが、サブフレーム内の2つの異なるスロットにおいて送信することを確実にすることによって、チャネルインデックスと、サブフレームのどのスロットでノードが送信することになるのかとの間のマッピングを生成することが可能である。十分な数の時間スロットおよびインデックス・ツー・スロットのマッピングの多様性を確実にすることによって、送信する能力を各ノードに提供し、同時に、そのノードに対して、そのノードがリッスンしているときに、他のすべてのノードが、送信する機会を少なくとも1回提供されることを保証することができる。この点で、車両は、サブフレーム全体にわたって仮想全二重ノードとして動作するものと見なされる。

ここで、図13を参照すると、仮想全二重モードを可能にする一例の実施形態において、1つまたは複数のゾーンについてチャネルがどのように定義され得るかを示している。この特定のチャネル定義は、Sparse Code Multiple Access （SCMA）符号化に基づく。ただし、これは限定を意味するものではない。他の符号化スキームまたはリソース定義が使用されてもよい。

図13の例では、サブフレーム1300は、7個の時間スロット1302（例えば、スロット1〜7）を有しており、各スロットは6個のSCMAレイヤを有し得る。チャネルは、2つのスロット／レイヤリソースを含むものとして定義され得る。これは、図12を参照して記載している例に類似している。

本例では、チャネルは、2つの異なるスロットが割り当てられる。ただし、他の仮想全二重の実施形態では、チャネルは、より多くのスロットを有し得る。車両は、2つのスロットの両方において送信し、両スロット内のペイロードは本質的に同じであり得る。同じペイロードを異なるスロットで送信することによって、他の車両がリッスンする複数の機会を提供し得る。7個のスロットがあり、各チャネルは2つの異なるスロットを割り当てられるので、

個の異なる組合せがある。したがって、この例では、21個までのチャネルがサポートされる。チャネルインデックス1304（例えば、1から21）は、図13の一番左の列に示されている。スロットインデックス1から7は、中央の7つの列に示されている。レイヤインデックス1306は、一番右の列に示されており、チャネルの2つのスロットのそれぞれと関連付けられたレイヤを示している。例えば、チャネル1は、スロット1および2を含んでおり、レイヤインデックス1，1を有している。これは、チャネル1のリソースがスロット1，レイヤ1、およびスロット2，レイヤ1を含んでいることを示す。つまり、レイヤインデックス1，1は、与えられたチャネルの1番目および2番目のスロットのレイヤを示す。別の例を提供すると、チャネル8は、スロットインデックス2，4およびレイヤインデックス3，2を有している。したがって、チャネル8のリソースは、スロット2，レイヤ3、およびスロット4，レイヤ2である。

仮想全二重モードを、図13を参照しつつ別の例を使用して記載する。この例では、チャネル1から6が、ゾーン内の6つの異なる車両によって使用される。図13に示すように、これらの車両のすべては、スロット1の間に送信し得る。そのため、これらの車両のうちで、スロット1の間、お互いをリッスンすることができ得る車両はない。ただし、各チャネル1から6のそれぞれの中の2番目のスロットは、異なる時間スロット（スロット2から7）において現れる。そのため、6つの車両のうちの1つだけが、スロット2から7のそれぞれにおいて送信する。したがって、他の5つの車両は、スロット2から7のそれぞれにおいて、送信している車両をリッスンすることができる。そのため、6つの車両すべてが、1つのサブフレーム範囲内でお互いに送信およびリッスンの両方を行うことができる。図13の例の21チャネルすべてについて同じことがいえる。

与えられたスロット内で定義された異なるSCMAレイヤの結果として、1つまたは複数のリッスンしている車両は、同じスロット内の異なるチャネルをとおして送信を受信することができ得る。例えば、チャネル7を要求してしまっている車両は、2つの異なる車両がチャネル1およびチャネル2のスロット1において送信しているかもしれないときに、スロット1でリッスン（すなわち、送信ではない）している。スロット1におけるチャネル1上の送信はレイヤ1を使用し、スロット1におけるチャネル2上の送信はスロット2を使用する。そのため、リッスンしている車両は、異なるSCMAレイヤを使用して、スロット1上のこれらの送信の両方を受信および処理することができ得る。

図13で示す実施形態で使用されているスロット、レイヤおよびチャネル定義の数は、例としてのみ提供されており、限定を意味するものではない。1つまたは複数の他の実施形態では、異なる構成が使用され得る。例えば、チャネルは、3つ以上のスロットを含むように定義され得る。他の構成およびオプションが可能である。

前述のように、いくつかの実施形態では、単一の車両が、与えられたゾーンの1つを超えるチャネルを要求および使用し得る。このことは、前述の仮想全二重モードのいくつかの実施形態を含め、いくつかの問題につながり得る。可能性のある1つの問題を図14を参照しつつ記載しており、それは図13の例で提供されたリソース定義例に基づいている。

図14の例では、第1の車両は、チャネル1、2および12を要求する。そのため、第1の車両は、スロット1、2、3、および4上で送信し得るので、これらのスロットのいずれにおいてもリッスンすることができない場合がある。チャネル3、7、および8も示されており、スロット1から4内で割り当てられたスロットだけを有している。そのため、ゾーン内の第2の車両が、チャネル3、7、および8のうちの、1つまたは複数だけを要求した場合、破線1400で示されるように、スロット1から4のすべての間に第1の車両が送信しているとき、第1の車両は第2の車両を決してリッスンできない場合がある。例えば、第2の車両がチャネル3を要求してしまっている場合、第2の車両はスロット1およびスロット4上で送信する。ただし、チャネル1、2および12を要求してしまっている第1の車両は、スロット1から4のすべての上で送信している場合があるので、第1の車両は、第2の車両を聴取することができな場合がある。

本開示は、このタイプの問題に対する1つまたは複数のソリューションを提供しており、前述されている。こうしたソリューションの1つは、1つまたは複数の他のゾーン内の空きチャネルの中から1つまたは複数のチャネル（例えば、2次チャネルなど）を要求する、特定のゾーンにいる車両に関与する。少なくともいくつかの実施形態では、異なるゾーンのチャネルは、異なるサブフレーム内のスロットまたは他の時間―周波数リソースで構成され得、それによって、図14に関連して記載された、問題を含む状態の可能性を取り除く。

本開示は、分散型の方法による通信リソースの共有および管理を提供するために、アドホックネットワークの車両において実施され得るチャネル共有アルゴリズムに言及している。チャネル共有アルゴリズムは、各車両が、他の車両によって要求されたリソースを認識できるようにし得るだけでなく、リソースコリジョンのリスクが少ないかまたはない状態でその車両がリソースをいつ要求および使用し得るかを決定し得る。また、チャネル共有アルゴリズムは、車両が、2次チャネルを要求すること、新たな車両のネットワークエントリ、および車両ハンドオーバを含んで、本発明に係る1つまたは複数の他のプロセスを実行することを可能にし得る。

前述の実施形態は、ゾーンをグリッド上で互いに隣接しているものとして参照しているが、これは単なる一実施形態であることを、当業者は理解するだろう。別の実施形態では、ゾーンは開始点を有するが、終了点を有しない。これにより、ゾーンの重複という結果になる。予め定義された方向に走行する各車両は、その車両の1次チャネルとして、その車両がゾーンのスタートに最も近いゾーン内の利用可能なチャネルを要求しようとすることになる。2次チャネルとして、車両は、次に近い開始点を有するゾーン内のチャネルを要求しようとすることになる。予め定義された方向と反対方向に走行する車両は（それらの車両が同じゾーンを共有する場合）、次の開始点の後のゾーン内で1次チャネルを要求することになる。図5Aを参照すると、ゾーンiは、端536でスタートするが、終了しない。ゾーンi＋1は図示されている次の境界でスタートするが、終了しない。その結果、ゾーンi内のすべての車両は、ゾーンi＋1内にもいる。

こうした一実施形態では、チャネルを要求する方法は変わらない。車両が、2次チャネルを要求したいと決定した場合、その車両は単に次のゾーンからチャネルを要求することによってそうすることができる。

車両は、その車両がゾーン内で責任を負っておらず、異なるゾーンへまさに入ろうとしていると判定すると、その車両がまさに入ろうとしているゾーン内のチャネルを要求することだけを選択し得ることが、さらに理解されるべきである。このことは、ゾーンの開始点の動的な変化として見ることもでき、車両が元のゾーン境界を通過したときに元に戻ることになる。

重複しているゾーン（スタートによって指定されているが終了によっては指定されていないゾーンがある場合、軽負荷の道路上の車両はすべて、それらの車両が今後さらに情報を交換できるように、最も大きな番号が付けられたゾーン内のチャネルを要求することが可能である。車両の通信到達距離は、より大きなサイズのゾーンが動的に生成されるとき、道路上の次の車両に中継としての役割を果たさせることによって、拡張することができる。

いくつかの図によって、単一レーンの交通に対するゾーンの適用を示してきたが、実施において、ゾーンは、1レーンを超える交通を含むように実施されることができ、また、1つを超える方向の交通も含む ことができるということも、当業者によって理解されるだろう。同様に、複数レーンの道路は、道路に重ね合わせるようにグリッドを生成して、各レーン内に一連の連続するゾーンを有し得る。異なる方向の交通は、ゾーンについて異なる開始点および終了点を有することができ、その結果、ゾーン内のチャネルは、各走行方向について、ゾーンを離れるのに最も近い車両に基づいて割り当てられる。複数レーンの道路が、異なるレーンをカバーするゾーンのグリッドを有している場合、ゾーンにそれらのゾーンの開始および終了点を整列させる必要はないことが理解されるべきである。

後続の実施形態の記述をとおして、本開示の教示は、ハードウェアだけを使用して、またはソフトウェアとハードウェアの組合せを使用して実施され得る。1つまたは複数の実施形態を実施するソフトウェアまたは他のコンピュータ実行可能命令、またはそれらの1つまたは複数の部分は、任意の適切なコンピュータ可読の記憶媒体に記憶され得る。コンピュータ可読の記憶媒体は、例えば、光学（例えば、CD、DVD、ブルーレイなど）、磁気、ハードディスク、揮発性もしくは不揮発性、ソリッドステート、または当該技術分野で知られている他の一切のタイプの記憶媒体などの、有形の、または一時的／非一時的な媒体であり得る。

さらに、実施形態は、車両通信との関連で記載されているが、本開示の範囲は、車両または車両通信に限定されることを意図するものではない。本開示の教示は、他のアプリケーションおよび他の分野において使用または適用され得る。そのため、車両および車両通信に関連する本明細書の教示は、他のタイプのノード、モバイルノード、ユーザ装置（UE）、送信ポイント、ネットワークエレメント、センサ、マシン、ならびに他のタイプのデバイス、ならびに他のタイプの通信およびネットワークに対して、一般に適用される。本教示は、車両アドホックネットワーク以外のネットワーク、例えば他のモバイルノードアドホックネットワークに適用されることも意図している。

本開示のさらなる特徴および利点が、当業者に理解されるだろう。

本明細書に記載の、および図示されている、特定の実施形態の構造、特徴、付属物、および代替は、互換性がある限り、本明細書に記載および図示されている実施形態のすべてに対することを含んで、本開示の教示のすべてに対して一般に適用されることを意図されている。つまり、ある特定の実施形態の構造、特徴、付属物、および代替は、そのように示されない限り、その特定の実施形態だけに限定されることを意図されていない。

さらには、前述の詳細な記述は、いかなる当業者も、本開示に係る1つまたは複数の実施形態を作成または使用することを可能にするために提供されている。これらの実施形態に対するさまざまな変形は、当業者には容易に明白になり、本明細書で定義された包括的な原理は、本明細書に提供された教示の趣旨または範囲から逸脱することなく、他の実施形態に適用され得る。したがって、本方法、システム、およびまたはデバイスは、本明細書に開示された実施形態に限定されることを意図していない。特許請求の範囲は、これらの実施形態によって限定されるべきではなく、全体として、記載に一致する最も広い解釈が与えられるべきである。冠詞「a」または「an」の使用によってなど、単数によるエレメントへの言及は、特にそのように述べられていない限り、「1つおよび1つだけ」を意味することを意図するものではなく、むしろ「1つまたは複数」を意味することを意図している。当業者に知られているかまたは後に知られることになる、開示全体にわたって記載されたさまざまな実施形態のエレメントのすべての構造的および機能的な同等物は、特許請求の範囲のエレメントによって包含されることを意図している。

さらに、本明細書に、先行技術または共通の一般知識の容認を意図するものはない。また、本願におけるいかなる文書の引用または特定も、こうした文書が先行技術として利用可能であること、または何らかの参照が、当技術分野における共通の一般知識の一部を形成することを容認するものではない。さらに、本明細書に開示されたものは、そのような開示が特許請求の範囲において明示的に記載されているかどうかにかかわらず、公共にささげるようには意図されていない。

10 車両
11 車両
12 車両
13 車両
14 車両
15 車両
20 車両
21 車両
22 車両
23 車両
30 円形線
32 円形線
34 関連エリア
200 処理システム
202 中央処理装置（CPU）
204 メモリ
206 大容量記憶装置
208 ビデオアダプタ
210 I／Oインタフェース
212 通信サブシステム
214 バス
216 ディスプレイ
218 オンスクリーンキーボード／会話インタフェース
220 トランスミッタ
222 レシーバ
224 アンテナエレメント
226 GPS無線またはレシーバ
300 道路
302 仮想グリッド
303 車両
304 ゾーン
306 ゾーンの長さ
308 認識エリア
310 車両
312 ゾーン
314 ガード領域
350 フレーム
352 時間スロット
400 道路
402 仮想グリッド
404 ゾーン
406 ゾーン長
450 フレーム
452 時間スロット
454 サブフレーム
500 道路
502 仮想グリッド
504 ゾーン
520 車両
530 第1のゾーン側端
532 第2のゾーン側端
534 第1のゾーン末端
536 第2のゾーン末端
550 送信フレーム
552 スロット
554 サブフレーム
650 フレーム幅、送信期間、間隔
652 短い矢印
660 リソース要求間隔
662 長い矢印
680 1つまたは複数の間隔
682 リソース要求時刻
700 1次チャネル
702 1次チャネル
704 1次チャネル
706 1次チャネル
708 1次チャネル
710 2次チャネル
712 2次チャネル
714 1次チャネル
716 1次チャネル
718 2次チャネル
720 2次チャネル
750 右ゾーン端
1000 フレーム
1002 サブフレーム
1004 ブロードキャストチャネル
1100 フレーム
1102 サブフレーム
1104 ブロードキャストチャネル
1106 スロット
1150 車両
1152 車両
1154 車両
1156 車両
1160 ブロードキャスト
1162 ビーコン送信
1164 ビーコン送信
1166 ビーコン送信
1168 ネットワーク・エントリ・メッセージ
1170 応答送信
1200 フレーム
1202 サブフレーム
1204 スロット
1206 SCMAレイヤ
1208 パイロット
1300 サブフレーム
1302 時間スロット
1304 チャネルインデックス
1306 レイヤインデックス
1400 破線

関連出願の相互参照
本出願は、「車両アドホックネットワークにおける分散リソース管理方法および分散リソース管理システム」と題する2015年4月1日に出願された米国特許出願番号14．676，434の利益の優先性を主張し、この出願は、参照によりその内容が本明細書に援用される。

本開示は、一般に、アドホックネットワークに関し、より具体的には、車両アドホックネットワークにおける通信リソース多重アクセスに関する。

車車間通信は、例えば、専用狭域通信用の高度道路交通システム（ITS）、および無線アドホックネットワークなど、特定エリアでの開発の結果もあって、最近より大きな注目を集めている。

車車間（V2V）通信ネットワークにより、車両が相互にやりとりすることを可能にしている。関連するタイプのネットワークは、車両インフラ間（V2I）通信ネットワークであり、これにより、車両が、路側器などの路側インフラとやりとりすることを可能にしている。車両および路側器は、これらV2VおよびV2Iネットワークにおける通信ノードである。ノードは、安全警告（例えば、実際の車両衝突またはその可能性警告）、協調型運転情報、交通情報、交通規制、運転補助、または取締まり機能を含むがこれには限らない、1つまたは複数の目的のために情報を交換し得る。

V2Vアドホックネットワークは、VANETと称されることもある。これらアドホックネットワークは、通常、分散型ネットワークアーキテクチャを有しており、中央制御装置がない。これらのタイプのネットワークでは、通常、リソース管理は、考慮すべき重要な点である。重複した形で同じリソースを使用しようとしている2つのノードによって引き起こされるリソースコリジョン、および制御不可能な遅延は、特に、高速かつ信頼できる送信を必要とし得る、安全関連の通信またはその他優先順位の高い通信に関連して、これらのタイプのネットワークにおいて、ちょっとした懸念事項である。

本発明の第1の態様では、車両ネットワーク内のノードによって実行する方法を提供している。方法は、ネットワーク内の第1のノードにおいて実行することができ、ネットワーク内の第2のノードの位置を示す情報を受信するステップと、第1のノードにおいて、第2のノードの位置に対する第1のノードの位置に基づいて、ネットワーク内の第1の通信チャネルを要求するステップとを含む。

本発明の第2の態様では、車車間アドホックネットワーク内で動作するための第1のノードを提供している。ノードは、プロセッサと、通信サブシステムと、命令を記憶するコンピュータ可読の記憶媒体とを備える。記憶された命令をプロセッサが実行したとき、その命令は、第1のノードに、通信サブシステムをとおして受信した情報から、ネットワーク内の第2のノードの位置をデコードさせ、第1のノードのためにネットワーク内の第1の通信チャネルの要求を示すメッセージを送信させ、第1の通信チャネルは、第2のノードの位置に対する第1のノードの位置に基づいて選択される。

第1の態様および第2の態様のうちの少なくとも1つについての実施形態では、第1のノードによって要求された第1のチャネルは、Sparse Code Multiple Access（SCMA）レイヤを含む。さらなる一実施形態では、第1のノードは、仮想グリッド内の第1のゾーン内に位置しており、要求された第1のチャネルは、第1のゾーン用に構成される。第1のゾーンの複数のチャネルの中の各チャネルは、単一のサブフレームの間、第1のゾーンのチャネルを要求してしまっているノードが、第1のゾーンのチャネルを要求してしまっている他のすべてのノードの送信をリッスンすることができ、かつ、第1のゾーンのチャネルを要求してしまっている他のすべてのノードに第1のノードの送信をリッスンさせることができるように、サブフレーム内の少なくとも2つの異なる時間スロットのそれぞれにわたって定義されたSCMAレイヤを含むことができ、少なくとも2つの異なる時間スロットの間に同じペイロードが送信され、各チャネルの、少なくとも2つの時間スロットとその時間スロットそれぞれのSCMAレイヤとの組合せが、第1のゾーン内でユニークである。

さらなる一実施形態では、第1のノードは、仮想グリッド内の第1のゾーン内に位置し、要求された第1のチャネルは、第1のゾーンに属し、要求された第1のチャネルは、第1のノードの1次チャネルとしての役割を果たし、方法は、2次チャネルとして第2のチャネルを要求するステップであって、第2のチャネルは、第1のゾーン以外の、仮想グリッド内の第2のゾーンの利用可能なチャネルである、ステップをさらに含む。 第2のゾーンは、第1のゾーンと隣接していてもよく、または第1のゾーンと重なり合っている可能性がある。第1および第2のノードの相対的位置は、第1のゾーンの端などの基準位置に対する、第1および第2のノードそれぞれの距離に基づいて決定することができる。

さらなる一実施形態では、方法は、第1のノードにおいて、第2のノードによる要求に利用可能な、ネットワーク内のチャネルを特定するステップであって、特定するステップは、第2のノードの位置に対する第1のノードの位置に基づく、ステップをさらに含むことができる。別の実施形態では、方法は、第1のノードにおいて、ネットワーク内の第3のノードの位置を示す情報を受信するステップであって、第1のノードにおいて第1のチャネルを要求するステップは、第2および第3のノードの位置に対する第1のノードの位置に基づく、ステップを含み得る。別の実施形態では、情報を受信するステップは、第1の時刻に発生し、第1のノードにおいて要求された第1のチャネルは、第1の時刻に続いて、第2の時刻に第1のノードによる送信のために使用される。さらなる一実施形態では、方法は、第1のノードの位置を示す情報をブロードキャストするステップを含む。別の実施形態では、第1のノードは、ネットワークの仮想グリッド内の第2のゾーン内にある。第1のゾーンから第2のゾーンに入ってしまっている第1のノードは、チャネルを要求するステップの前に、第1のノードが第2のゾーンの通信チャネルの可用性について不十分な情報を有していることを示すブラインドネスインディケーションを送信する。さらなる一実施形態では、チャネルを要求した後、第1のノードは、第1のノードが仮想グリッドにおいて第1のゾーンから第2のゾーンへ移動してしまっていると判定することができる。第1のノードが第2のゾーンの通信チャネルを2次チャネルとして要求してしまっている場合には、第1のノードは、チャネルのステータスを第1のノードの2次チャネルから1次チャネルへ変更することができる。第1のノードが第2のゾーンの通信チャネルを2次チャネルとして要求してしまっていない場合には、第1のノードは、第2のゾーンの利用可能なチャネルを第1のノードの1次チャネルとして要求することができる。

本発明の第3の態様では、車車間アドホックネットワークにおいて実行される方法があり、仮想グリッドの第1のゾーン内の新たなノードにおいて、第1のゾーンの通信チャネルの可用性を示す情報を受信するステップであって、新たなノードは、要求済のチャネルを有していない、ステップと、新たなノードにおいて、新たなノードための1次チャネルのリクエストを示すネットワーク・エントリ・リクエストを送信するステップとを含む。

本発明の第4の態様では、車車間アドホックネットワーク内で動作するためのノードを提供している。ノードは、プロセッサと、通信サブシステムと、プロセッサによって実行されたときに、第1のノードに、本発明の第3の態様に係る方法を実行させる命令を記憶する、コンピュータ可読の記憶媒体とを備える。

本発明の第3および第4の態様のうちの少なくとも1つの一実施形態では、送信するステップは、ネットワーク・エントリ・リクエストを第1のゾーンに関連付けられたマスタノードへ送信するステップを含む。さらなる一実施形態では、可用性を示す情報は、第1のゾーン内の第2のノードからのビーコン送信と第1のゾーンのブロードキャストチャネルのうちの少なくとも1つをとおして新たなノードにおいて受信される。別の実施形態では、方法は、ネットワーク・エントリ・リクエストに応答して、新たなノードによる要求のための1次チャネルのインディケーションを新たなノードにおいて受信するステップをさらに含む。さらなる一実施形態では、ネットワーク・エントリ・リクエストは、新たなノードの位置を示す情報を含む。

本発明の第5の態様では、車車間アドホックネットワークにおける方法を提供している。方法は、アドホックネットワークの仮想グリッドの第1のゾーン内に位置している第1のノードにおいて実行される。方法は、第2のゾーンの第1の通信チャネルの可用性を示す情報を受信するステップと、第1のチャネルを第1のノードの2次チャネルとして要求するステップとを含む。

第5の態様の一実施形態では、受信するステップの前に、第1のノードは、第1のノードが第1のチャネルを2次チャネルとして要求することができないような、第1のチャネルの可用性について不十分な情報を有し得る。別の実施形態では、受信された情報の少なくとも一部は、ブロードキャストチャネルをとおして、第1のゾーン以外のゾーン内に位置している第2のノードから受信される。

別の実施形態では、チャネルを要求するステップは、第2のノードの位置に対する第1のノードの位置に従って実行される。第1および第2のノードの相対的位置は、基準位置に対する第1および第2のノードそれぞれの距離に基づいて決定することができる。さらなる一実施形態では、基準位置は、仮想グリッド内のゾーンの端を含む。別の実施形態では、チャネルを要求するステップは、後続の時刻における2次チャネル上での第1のノードによる送信のために、第1の時刻に発生する。別の実施形態では、第1のチャネルは、Sparse Code Multiple Access（SCMA）レイヤを含む。

本発明の第6の態様では、車車間アドホックネットワークにおいて動作するための第1のノードを提供している。第1のノードは、プロセッサと、通信サブシステムと、コンピュータ可読の記憶媒体とを備える。プロセッサが、メモリに記憶された命令を実行したとき、その命令は、第1のノードに、第1のノードがネットワーク内の仮想グリッドの第1のゾーン内に位置しているときに第1のノードにおいて、通信サブシステムをとおして受信した情報から、第2のゾーンの第1の通信チャネルの可用性のインディケーションをデコードさせ、第1のチャネルを第1のノードの2次チャネルとして要求すること示すメッセージを送信させる。

本発明の第7の態様では、車車間アドホックネットワーク内の第1のノードによって実行する方法を提供している。方法は、ブラインドネスインディケーションを送信する第1のノードを含み、第1のノードは、第1のゾーンから第2のゾーンに入ってしまっており、ブラインドネスインディケーションは、ネットワーク内の第2のゾーンにいるとき、第1のノードが第2のゾーンの通信チャネルの可用性について不完全な情報を有していることを示す。

第8の態様では、車車間アドホックネットワーク内で動作するための第1のノードを提供している。ノードは、プロセッサと、通信サブシステムと、コンピュータ可読の記憶媒体とを備える。プロセッサが、記憶媒体に記憶された命令を実行したとき、その命令は、第1のノードに、第7の態様の方法を実行させる。

第7および第8の態様のうちの1つの一実施形態では、方法は、第1のノードにおいて、送信するステップに応答して、第2のゾーンの1つまたは複数の利用可能なチャネルを示す情報を受信するステップを含む。方法は、第2のゾーンの1つまたは複数の利用可能なチャネルのうちの少なくとも1つを第1のノードの1次チャネルとして要求するステップをさらに含むことができる。さらなる一実施形態では、要求するステップは、第2のノードの位置に対する第1のノードの位置に基づく。さらに別のさらなる実施形態では、第1のノードと第2のノードの相対的位置は、基準位置に対する第1および第2のノードそれぞれの距離に基づいて決定される。

本発明の第9の態様では、アドホックネットワークの第1のゾーン範囲内に位置しているノードにおいて実行する方法を提供している。第1のゾーンは、アドホックネットワーク内で定義された仮想グリッド内のゾーンであり得る。 方法は、第1のゾーンの通信チャネルの可用性を示す情報をブロードキャストするステップを含む。

本発明の第10の態様では、第9の態様の方法を実行するためのノードを提供している。ノードは、プロセッサと、メモリと、通信サブシステムとを備える。プロセッサが、メモリに記憶された命令を実行したとき、ノードは、第9の態様の方法を実行する。

実施形態では、ノードは、ブロードキャストするステップを実行する責任を負う、第1のゾーンのマスタノードである。他の実施形態では、ブロードキャストするステップは、専用のブロードキャストチャネル上で発生する。

本発明の第11の態様では、車車間アドホックネットワーク内の第1のノードによって実行する方法を提供している。方法は、第1のノードが仮想グリッドにおいて第1のゾーンから第2のゾーンへ移動してしまっていると判定するステップと、第1のノードが第2のゾーンの通信チャネルを2次チャネルとして要求してしまっている場合には、チャネルのステータスを第1のノードの2次チャネルから1次チャネルへ変更するステップと、第1のノードが第2のゾーンの通信チャネルを2次チャネルとして要求してしまっていない場合には、第1のノードにおいて、第2のゾーンの利用可能なチャネルを第1のノードの1次チャネルとして要求するステップとを含む。

本発明の第12の態様では、本発明の第11の態様の方法を実行するためのノードを提供している。ノードは、メモリと、プロセッサと、通信サブシステムとを備える。プロセッサが、メモリに記憶された命令を実行したとき、その命令は、ノードに、第11の態様の方法を実行させる。

第11および第12の態様の実施形態では、第1のノードが第2のゾーンへ移動するときに第1のノードが第1のゾーンのチャネルを1次チャネルとして要求してしまっている場合には、方法は、第1のノードにおいて、第1のゾーンのこのチャネルを開放するステップを含む。別の実施形態では、第2のゾーンのチャネルを1次チャネルとして要求するステップは、第2のノードの位置に対する第1のノードの位置に基づく。さらなる一実施形態では、第1および第2のノードの相対的位置は、基準位置に対する第1および第2のノードそれぞれの距離に基づいて決定される。別の実施形態では、第1のノードために1次チャネルを要求するステップは、後続の時刻における第1のノードによる送信のために、第1の時刻に発生する。

本開示は、以下の図面を考慮して、さらによく理解されるであろう。

本開示の少なくとも1つの実施形態に係る、道路にそって反対方向に走行している車両を表している。 少なくとも1つの実施形態における、一例の処理システムのブロック図である。 仮想グリッドを使用して小さなゾーンに細分されている道路にそって走行している車両を表している。 複数のフレームおよび関連する時間スロットを示す送信図である。 仮想グリッドを使用してより大きなゾーンに細分されている道路にそって走行している車両を表している。 1つのフレームおよびそのフレームの関連する時間スロットを示す送信図である。 本開示の少なくとも1つの実施形態に係る、仮想グリッドを使用してゾーンに細分されている道路にそって走行している車両を表している。 少なくとも1つの実施形態に係る、1つのフレームおよびそのフレームの関連する時間スロットを示す送信図である。 少なくとも1つの実施形態における、車両において、情報を交換し、リソースを要求するためのプロセスのフロー図である。 少なくとも1つの実施形態における、送信およびリソース要求の間隔を表すタイミング図である。 少なくとも1つの実施形態に係る、ハンドオーバ状態において、ゾーンに細分されている道路にそって走行している車両を表している。 少なくとも1つの実施形態に係る、ハンドオーバ状態において、ゾーンに細分されている道路にそって走行している車両を表している。 少なくとも1つの実施形態に係る、ハンドオーバ状態において、ゾーンに細分されている道路にそって走行している車両を表している。 少なくとも1つの実施形態に係る、ハンドオーバ状態を処理するためのプロセスのフロー図である。 少なくとも1つの実施形態に係る、車両における位置順のリソース要求のためのプロセスのフロー図である。 少なくとも1つの実施形態に係る、ブラインドノード回復状態における、フレームおよび関連する時間スロットを示す送信図である。 少なくとも1つの実施形態に係る、車両ネットワークエントリ状態における、フレームおよび関連する時間スロットを示す送信図である。 少なくとも1つの実施形態に係る、ネットワークエントリ状態における、車両間の可能な送信を示すデータフロー図である。 少なくとも1つの実施形態に係る、1つのフレーム、スロットおよびSCMAレイヤを示す送信図である。 少なくとも1つの実施形態に係る、SCMAリソース定義を示すリソース定義図である。 図13に示すリソース定義のサブセットを示すリソース定義図である。

本明細書に記載の実施形態は、車両、車車間通信および車両アドホックネットワークを含む、車両通信に関する。ただし、本開示の範囲は、車両または車両通信に限定されることを意図するものではない。本開示の教示は、他のタイプのモバイルノードを含んで、他のアプリケーションおよび他の分野において、他のタイプのノードに使用または適用され得る。

本開示の少なくとも1つの態様によれば、車両アドホックネットワーク内の車両によるリソースの要求のために1つまたは複数のアプローチが提供される。要求という用語は、アドホックネットワーク内の車両による共有通信リソースの使用または予約をいうために使用され得る。複数の車両にリソースを割り当てる責任を負ったセントラルオーソリティなど、別のエンティティによってチャネルを割り当てられている車両の代わりに、車両がその車両自身のためにリソースを要求し得る。他の車両に関連付けられた情報を含んで、車両は、特定のリソースを要求および使用するために、それらの車両の環境についての情報を使用し得る。車両は、リソースコリジョンの可能性を最小限にするかまたは取り除くために、アルゴリズム、一連の規則などに基づいてそれらの車両のリソース要求を行い得る。

本開示の少なくとも1つの別の態様によれば、1つまたは複数の車両がネットワーク、例えば車両アドホックネットワークに入ることを可能にするために、1つまたは複数のアプローチが提供される。

本開示の少なくとも1つの別の態様によれば、例えば車両アドホックネットワークにおいて、ブラインド車両の回復を可能にするために、1つまたは複数のアプローチが提供される。やってくる時間フレームのためにリソースを要求するなどの必要な機能を車両が実行することを可能にするための十分な情報を、車両が受信できないとき、車両は「ブラインド」である。

本開示の少なくとも1つの別の態様によれば、アドホックネットワーク内のリソースは、Sparse Code Multiple Access（SCMA）に基づいて定義され得る。

本開示の少なくとも1つの別の態様によれば、アドホックネットワーク内の車両のための仮想全二重通信モードを実現するために、1つまたは複数のアプローチが提供される。

車車間通信は、安全関連アプリケーション用の通信および非安全アプリケーション用の通信に大まかに分類され得る。安全関連の通信は、例えば、非常ブレーキまたは死角警告などを例とする協調型前方車両衝突警告、および、この先路面凍結の警告などの危険箇所車車間通知、に関連する情報を含み得る。これらはほんの一例である。

非安全アプリケーションは、車両および交通システムに関連する別の機能またはサービスを提供するために使用され得る。非安全アプリケーションは、例えば、交通情報、交通渋滞回避、交通経路決定、インターネットまたはその他の車両用データ通信の提供に関連し得る。さまざまな他のタイプの非安全アプリケーションが存在しており、可能である。

安全関連アプリケーションにおける情報の交換は、非安全アプリケーションにおける交換とは別のサービス品質（QoS）要求事項の対象となり得る。例えば、一定のタイプの安全関連情報が素早く、すなわち低レイテンシでかつ確実に、すなわち高い成功度合いで配信されることが重要であり得る。車両衝突警告アプリケーションがタイムリーなインディケーションまたは応答を提供し得るように、協調型車両衝突警告情報が迅速かつ確実に通信されることが一般に望ましいことであり得る。

車両ネットワークにおいて、安全関連の通信は、多くの場合ブロードキャストの性質を備えている。安全アプリケーションは、特定のV2Vプロトコルをも含めて、ネットワークプロトコルまたはトランスポートプロトコルなどのプロトコルによってサポートされ得る。例えば、専用狭域通信（DSRC）である1つのV2Vプロトコルは、IEEE 802．11p規格に基づいており、この規格はIEEE 802．11の拡張であり、車両通信システムである車両環境での無線アクセス（WAVE）を追加している。拡張は、高度道路交通システム（ITS）アプリケーションをサポートすることを意図するものである。IEEE 802．11pによれば、5．9GHz周辺の専用の75MHzスペクトル帯（5．850〜5．925GHz）で通信が行われる。通信は、最大距離約1000mである。

VANET）の媒体アクセス制御（MAC）プロトコルは、一般に、チャネルアクセスのための車両間のコンテンションを解決する。既存のV2Vネットワークの実施態様では、DSRCにおけるランダムアクセスメカニズムは、キャリア検知多重アクセス／衝突回避（CSMA／CA）に依存している。既存のV2Vネットワークにおいて、車両間のコンテンションを解決するために使用されるMACプロトコルは、定義されたエリア内において同じ無線リソースへアクセスしようとしている車両が少ないときは、十分なレイテンシを提供し得る。ただし、これらのプロトコルは、エリアにおいて同じリソースへアクセスしようとしている車両がもっと多いときは、より高い、許容できないレイテンシをもたらし得る。より高いレイテンシは、少なくとも部分的には、一部の車両に対するより長いコンテンション期間が原因であり得る。

また、他の要因が、車車間アドホックネットワークにおけるチャネルアクセスまたは他の無線リソース管理を複雑にし得る。これには、ネットワーク内で絶えず変化する、ノード（例えば、車両など）の物理的位置、および、変化する、車両の互いに対する位置が含まれる。

車両ネットワークにおける安全関連の通信は、さまざまなタイプの道路安全メッセージ、例えば、協調認識メッセージ（CAM）と分散型環境通知メッセージ（DENM）のいずれかまたは両方、を含み得る。CAMおよびDENMメッセージは、ブロードキャストの性質を備え得る。協調認識メッセージ（CAM）は、送信している車両に関する情報を、その車両の近隣の車両へ提供する。このタイプのメッセージは、車両に関する情報、例えばその車両の存在、位置、キネマティクスおよび他のステータス情報を含み得る。CAMは、ビーコンまたはハートビートメッセージの形式の定期的なショートメッセージであり得る。したがってその意味では、CAMはタイムドリブン型のメッセージである。例えば、CAMメッセージは、1〜10Hzの範囲の周波数でブロードキャストされ得、約100msの最大レイテンシ、800バイトまでの長さを有し得る。ただし、これらの値は、例に過ぎない。さらには、CAMメッセージは、送信している車両のすぐ近隣の範囲内にブロードキャストされ得る。

一方、分散型環境通知メッセージ（DENM）は、1つまたは複数の他の車両に注意を喚起するために、事故などの事象もしくは状態、または他のいかなるタイプの事象もしくは情報までもがブロードキャストされる、イベントドリブン型のメッセージであり得る。そのため、CAMメッセージとは異なり、DENMメッセージは、一般に、定期的メッセージではない。一例としてのみ、DENMメッセージは、100msの最大レイテンシと、CAMメッセージよりも短い長さ（800バイト未満など）を有している。また、DENMメッセージは、事象の位置に基づくエリア範囲内でブロードキャストされ得る。エリアは、事象の関連エリアと称され得る。

ここで図1を参照すると、道路2上の複数の乗用車またはその他の車両を表している。なお、本開示の図における対象の相対的サイズおよびそれらの対象の間隔は、説明目的のためだけに使用されており、必ずしも寸法どおりではないことに留意されたい。

車両10から15は、一方向に走行して示されており、一方他の車両20から23は、反対方向に走行している。少なくとも一部の車両は、車車間通信の機能を有し得る。

例えば、車両11は、円形線30によって示された最小認識範囲を有し得る。通常、認識範囲とは、車両11が、別の車両からとることができて、なお通信範囲内に留まることができる、最大の距離をいう。そのため、車両11は、この範囲で他の車両、この例では車両10、21および22からメッセージを受信することが可能であり得るので、これらの車両を認識し得、これらの車両からこれらの車両に関して情報を受信し得る。車両11は、車両10、21および22などすぐ近くの他の車両へ情報を提供するために、メッセージをブロードキャストもし得る。ブロードキャストされて受信されたこれらのメッセージは、存在、位置、キネマティクス、およびまたは他のステータスもしくはその他の情報を提供するCAMメッセージ、DENMメッセージ、または他の一切のタイプのメッセージもしくは通信であり得る。

同様に、車両22は、円形線32によって示された最小認識範囲を有し得る。したがって、車両22は、車両11および21を認識し得、それらの車両から情報を受信し得る。車両22は、情報を送信もし得、送信された情報は、車両11および21によって受信され得る。車両22は、ブロードキャスト送信、ポイントツーポイント送信またはポイントツーマルチポイント送信を使用し得る。一実施形態では、すべてのメッセージがブロードキャスト送信であり、以下の記述ではこの言葉を使用するが、当業者は、他の送信タイプを使用することができることを理解するだろう。

また、DENMメッセージなど、事象ベースのメッセージは、車両によってブロードキャストまたは中継され得る。例えば、図1の例では、車両14は、車両15との車両衝突に巻き込まれるかもしれず、そのため、他の車両にハザードを警告するために、DENMまたは類似のタイプのメッセージをブロードキャストし得る。例では、車両14からのDENMメッセージは、車両13によって受信され得、今度は車両13が、別のメッセージで情報を再度ブロードキャストし得、そのメッセージは、車両12によって受信され得る。車両12は、DENMメッセージの送信時点においては、車両14の範囲の外にいるかもしれず、そのため、車両14からのオリジナルのブロードキャストを受信しないかもしれない。DENMメッセージをブロードキャストすることおよび中継することは、特定の地理的エリア、例えば関連エリア34に限定され得る。

図1は、いくつかの状態におけるいくつかのタイプの車車間メッセージ交換を図示している一例に過ぎない。限定を意味するものではない。

ここで図2を参照すると、処理または通信機能、例えば車車間通信を提供するために車両と共に使用され得る一例のシステムを示している。

図2は、本明細書で開示されるノード、デバイスおよび方法の少なくともいくつかを実施するために使用され得る、一例の処理システム200のブロック図である。処理システム200は、中央処理装置（CPU）202、メモリ204、大容量記憶装置206、ビデオアダプタ208、I／Oインタフェース210、および通信サブシステム212のうちの、1つまたは複数を含み得る。処理システム200のコンポーネントまたはサブシステムのうちの1つまたは複数は、1つまたは複数のバス214または他の接続によって相互に接続され得る。

バス214は、メモリバスまたはメモリコントローラ、ペリフェラルバス、ビデオバスなどを含む、任意のタイプのいくつかのバスアーキテクチャのうちの1つまたは複数であり得る。CPU202は、任意のタイプの電子データプロセッサを備え得る。メモリ204は、スタティック・ランダム・アクセス・メモリ（SRAM）、ダイナミック・ランダム・アクセス・メモリ（DRAM）、シンクロナスDRAM（SDRAM）、リード・オンリ・メモリ（ROM）、これらの組合せなどの、任意のタイプのシステムメモリを備え得る。一実施形態では、メモリは、起動時に使用するためのROM、ならびにプログラムを実行している間に使用するためのプログラムおよびデータ記憶のためのDRAMを含み得る。

大容量記憶装置206は、データ、プログラム、および他の情報を記憶し、データ、プログラム、および他の情報をバス214経由でアクセス可能にするように構成された任意のタイプの記憶装置を備え得る。大容量記憶装置は、例えば、ソリッドステートドライブ、ハードディスクドライブ、磁気ディスクドライブ、光学ディスクドライブなどのうちの1つまたは複数を備え得る。

ビデオアダプタ208およびI／Oインタフェース210は、随意に含まれ得る。これらは、外部入力デバイスおよび外部出力デバイスを処理システムに連結するためのインタフェースを提供するために使用することができる。図示するように、入力デバイスおよび出力デバイスの例には、インダッシュ型ディスプレイなど、ビデオアダプタ208に連結されるディスプレイ216、およびI／Oインタフェース210に連結されるオンスクリーンキーボード／会話インタフェース218が含まれる。ただし、これらのペリフェラルおよび他のデバイスは、あくまでも例であることを理解されたい。示され、記載されているデバイスに加えて、またはそれらの代わりに、他のデバイスが、処理システムに連結または接続されてもよい。さらに、追加またはさらに少ないインタフェースが利用されてもよい。例えば、オンボード診断（ODB）インタフェース（図示しない）など1つまたは複数のシリアルインタフェースを提供し得る。

通信サブシステム212は、送信信号および受信信号の、いずれかまたは両方について提供され得る。通信サブシステムは、1つまたは複数の有線もしくは無線のインタフェースをとおして通信を可能にするための任意のコンポーネントもしくはコンポーネント群を含み得る。これらのインタフェースには、GPRS、UMTS、LTE、LTE−A、専用狭域通信（DSRC）、IEEE 802．11p、WiFi、WiMax、またはBluetooth（登録商標）、およびV2V直接通信についてIEEEの高度道路交通システム（ITS）ソサイエティによって定義されたインタフェースが含まれるが、これには限定されない。

通信サブシステムは、トランスミッタ220、レシーバ222、およびアンテナエレメント224のうちの、1つまたは複数を含み得る。少なくともいくつかの実施形態では、処理システムは、例えば、処理システムの地理的位置を決定するため、または他のシステムとシステムの時刻同期用のタイミング信号を受信するために、地理的位置決め機能を有し得る。地理的位置決めを決定する能力は、車両の位置、速度、方向または他のキネマティク情報を決定するために望ましいかまたはむしろ必要である。少なくともいくつかの実施形態では、処理システムは、全地球測位システム（GPS）信号を受信することができ得る。そのため、少なくとも1つの実施形態では、図2に示すように、処理システムは、GPS無線またはレシーバ226を備え得る。ただし、他の実施形態は、例えば、処理システムの地理的位置を決定するため、または時刻同期用のタイミング信号を受信するために、別のサブシステムまたはコンポーネントを備え、使用し得る。

図2の処理システム200は、一例に過ぎず、限定を意味するものではない。さまざまな実施形態は、示されるか記載されているコンポーネントの一部またはすべてを利用し得る。いくつかの実施形態は、示されも記載もされていないが当業者に知られている他のコンポーネントを使用し得る。さらに、デバイスは、複数の、処理システム、プロセッサ、メモリ、トランスミッタ、レシーバなど、コンポーネントの複数の実体を含み得る。処理システムは、スピーカ、マイク、タッチスクリーン、キーパッド、キーボード、ディスプレイなど、1つまたは複数の入力／出力デバイスを備え得る。さまざまな他のオプションおよび構成が想定される。

前述のとおり、車車間アドホックネットワーク（VANET）における無線リソースの共有および要求は、いくつかの課題を抱えている。リソース要求のための1つのタイプのアプローチは、車両の地理的位置を使用する。これは、位置ベースのリソース共有と称され得る。

位置ベースのリソース共有では、道路または道路のセグメントは、グリッドまたは仮想グリッドを使用してマッピングされ得、これによって道路を詳細な地理的エリアに分割し得、そのエリアはゾーンと称され得る。無線リソースは、次いで、車両が占有する特定のゾーンに基づいて車両間で割り当てられるか、または車両によって要求され得る。

車両は、道路にそって走行するにつれて、ゾーン間を移動する。車両は、その車両の地理的位置を知り得るかまたは取得することができ得、その位置から、その車両の地理的位置決め機能を使用して、例えば、GPS信号を受信および処理することによって、その車両がどのゾーンを占有しているのかを判定し得る。車両は、ゾーン間を移動しており、リソースは、ゾーン毎に構成され得るので、各ゾーンのリソースは、例えば定期的に、時折利用可能にされる必要があり得る。例えば、車両が第1のゾーンから第2のゾーンへ移動するとき、車両は第1のゾーンに属するリソースを放棄し、次いで、第2のゾーンに属するリソースを取得する必要があり得る。車両は、第2のゾーンのリソースが要求に再び利用可能になったときに、第2のゾーン内でリソースを要求し得る。

第1の既存の、位置に基づくリソース共有のアプローチを図3Aおよび図3Bに示す。このアプローチでは、道路300は、道路をゾーン304に分割するために仮想グリッド302を使用してマッピングされる。簡単にするために、道路の1つのレーンだけを示している。この例では、ゾーンは比較的短い長さd306を有しており、平均的な車両の長さよりもわずかに長いかもしれない（一例としてのみ、例えば4m）。したがって、このゾーンの長さに基づいて、任意の与えられた時刻に1つのゾーン内に最大1つの車両が存在するだろうと仮定される。

共有無線リソースは、ゾーン毎で構成される。リソースは、図3Aにおいてゾーンz₁、z₂、・・・、z_nで示される、隣接するn個のゾーンにわたって共有され得る。例えば、図3Bを参照して、時分割多重アクセス（TDMA）スキームにおいて、長さnT_sのフレーム350の範囲内の長さT_sの1つの時間スロット352は、ゾーン毎に予め割り当てられ得、ここでフレームはn個のスロットを有している。したがって、ゾーンz₁は、予め割り当てられた時間スロット1であり得、ゾーンz₂は、予め割り当てられた時間スロット2であり得る、などである。このリソース割当ての構成はほんの一例である。ゾーンの相対的順序付けおよび時間スロットのインデックスは異なり得る。例えば、ゾーンz₁は、予め割り当てられた時間スロット2であり得、ゾーンz₂は、予め割り当てられた時間スロット10であり得、ゾーンz₃は、予め割り当てられた時間スロット1であり得る、などである。与えられた時刻に1つのゾーン内に最大1つの車両が存在し得ると仮定されるので、無線リソースにアクセスしたい他の車両はゾーン内にない（例えば、ゾーンに予め割り当てられた時間スロットにおいて）。したがって、理論上は、1つのゾーンに予め割り当てられた単一のリソースについて、車両間でのコンテンションはないことになる。

同じチャネルまたは時間スロットが、グリッド内の異なるゾーングループのために再利用され得る。例えば、同じチャネルが、次のn個のゾーンにおいて、例えばゾーンn＋1からゾーン2nに対して、およびその次のn個のゾーン、ゾーン2n＋1からゾーン3nに対して再利用され得る、などである。

図3Bは、フレーム350の下に、例の車両303（図3A）が時間の経過とともに位置している特定のゾーンを示している。車両303が位置している特定のゾーンに予め割り当てられている時間スロット（チャネルなど）は、図3Bにおいて斜線が施されている。したがってこのアプローチでは、各ゾーンは、各フレーム350内に、対応する時間スロットを有している。

また、前述のとおり、車両は認識エリアを有している。車両は、このエリアの範囲で他の車両からメッセージを受信し得るので、これらの他の車両を認識し得、これらの車両からこれらの車両に関して情報を受信し得る。例えば、図3Aを参照すると、車両310は、車両の周辺で認識エリア範囲rメートルを有しており、符号308で示される。dはゾーンの長さであるので、認識範囲は、車両310が位置しているゾーン312の両側にr／dゾーンの長さを有する。したがって、この例では、合計の認識エリアは2d／r＋1ゾーンである。

さらに、車両は、その車両の認識エリア308の前に、gメートルのガード領域を有し得、符号314で示されている。ガード領域は、g／dゾーンの長さを有し得、認識エリア308の外側領域またはその近くにおける支障に対処するために使用され得る。例えば、ガード領域は、グリッドにわたる定期的なチャネルの再利用に起因する支障を低減するために使用され得る。ガード領域は、車両に対して、その車両が次の時間フレームをリッスンし始める前に、関連する受信した情報を処理するために、余裕時間を提供もし得る。図3Aの例では、車両310は、ゾーン1から2r／d＋1までをリッスンする必要があり得る。車両310は、ゾーン2r／d＋2からnまでを無視してもよい。

グリッド内の異なるゾーングループのために同じチャネルが再利用される場合、車両の認識範囲は、結果として、車両の前後でn／2＊dメートル（またはn／2ゾーン）以下であり得る。図3Aに示すように、車両の片側の認識範囲はrであり、ガード範囲はgであり、したがって同じチャネルを再利用するゾーングループ内のゾーンの数nは、n＝（2r＋g）／d＋1であり得る。

この第1のアプローチは、いくらかの利益を提供し得、例えば、無線チャネルへのアクセスのために車両間でいかなるコンテンションも通常はない。ただし、このアプローチは、欠点も有している。例えば、ゾーンの長さ、ひいてはサイズが小さいので、車両は、その車両の地理的位置を高精度で着実に決定することができなければならない。この決定において一定量の誤差がある場合、車両は、その車両が実際にいるゾーンとは異なるゾーンにその車両が位置しているものと、間違って判定し得るので、この異なるゾーンに予め割り当てられたかまたはそれに属しているチャネルへアクセスしようとすることになる。結果として、1つを超える車両が同時に、ゾーンの同じリソース（チャネルなど）を使用しようとしている場合があり得る。

さらに、各ゾーンのサイズが小さく、場合によっては車両の長さよりもわずかに長いので、任意の与えられた時刻において、ゾーンの大部分が空いていることになる可能性が高いかもしれない。無線リソースは、各ゾーンに予め割り当てられているので、多くのゾーンが空いているとき、かなりの量の無駄なリソースがあることになる。

また、ある一定の速度以上で車両が走行しているとき、このアプローチには問題もあり得る。短いゾーン長は、車両がある一定の閾値速度を超えて走行しているとき、処理を実行し、無線リソースをとおして送信するために十分な時間を有し得ないことを意味する。例えば、ゾーン内で送信を開始する前の最大遅延時間は、（n＋1）T_s＜d／V_maxであり得、図3Bにおいて符号354で示されており、ここで、nはフレーム毎のスロット数、T_sはスロットの時間幅、そしてV_maxは車両の最大速度である。

第2の既存の、位置に基づくリソース共有のアプローチを図4Aおよび図4Bに示す。このアプローチは図3Aおよび図3Bに示したものに類似しており、道路400、仮想グリッド402、および多数のゾーン404を有している。図4Aではゾーンはz₁、z₂、z₃などと番号が付けられる。ただし、このアプローチでは、各ゾーンは、より大きな地理的サイズ、例えばより長いゾーン長406を有し得る。そのため、1つのゾーンは、同時に2つ以上の車両を含むのに十分なほど大きいものであり得る。また、このアプローチでは、リソースの複数のチャネルが、単一のゾーンに予め割り当てられ得る。そのため、単一のゾーン内の車両は、複数のチャネルを使用し得る。ゾーン範囲内に1つの車両しかないとき、その1つの車両は、その車両のゾーン範囲内のチャネルのいくつかまたはすべてを、検知および使用し得る。ゾーン内に2つ以上の車両があるとき、チャネルへのアクセスのためにその2つ以上の車両の間でコンテンションが存在し得る。

例えば、図4Bを参照すると、時分割多重アクセス（TDMA）の実施態様において、フレーム450の各サブフレーム454は、異なるゾーンに予め割り当てられ得る。フレーム450は、I個のサブフレームを有し得る。例えば、サブフレーム1は、ゾーンz₁に予め割り当てられ得、サブフレーム2はゾーンz₂に予め割り当てられる、などである。また、サブフレーム454の範囲内の1つまたは複数の時間スロット452は、与えられたゾーンのためのチャネルとして予め割り当てられ得る。例えば、サブフレーム2内の時間スロット1からmは、ゾーンz₂のためのチャネル1からmとして予め割り当てられ得る。

この第2のアプローチは、前述の第1のアプローチとは異なり、より大きなゾーンサイズのおかげで、その車両の地理的位置を決定する車両において、こうした高精度の必要性がなくなり得る。ゾーンサイズがより大きいので、低精度で十分であり得る。つまり、車両は実際には第1のゾーンにいるが、第2のゾーンにいるものと間違って判定する（例えば、GPSなどを使用して）、という可能性が、ゾーンがより小さいときと比較して低い。さらに、この第2のアプローチでは、任意の与えられた時刻において空いているゾーンがより少ないことが十分に考えられるので、無駄なリソースがより少なくなり得る。また、車両が閾値速度を超えるときに生じる、第1のアプローチにおける問題は、より長いゾーン長のおかげで、第2のアプローチでは低減または取り除かれ得る。

ただし、単一のゾーンにおいて車両間でチャネルが共有されるので、第2のアプローチにおいてチャネルコンテンションの問題が生じる。そのため、同じチャネルにアクセスしようとする車両による多重アクセスのリソースコリジョンの可能性がある。リソースコリジョンは、いくつかの車両について長いコンテンション期間という結果になり得、これが、他の車両との、安全関連情報などの情報交換における高レイテンシにつながり得る。いくつかの状態およびシステムでは、例えば、安全関連情報の送信に関与して、高レイテンシは望ましくないかまたは許容されないものでさえあり得る。

そのため、本開示の一態様によれば、車両アドホックネットワーク内のリソースアクセスのために1つまたは複数のアプローチが提供される。

本開示の少なくとも1つの態様によれば、リソースは、与えられたエリア（ゾーンなど）範囲内の車両によって、そのエリア範囲内の車両の順序付けに基づいて要求され得る。順序付けは、エリア内の1つまたは複数の車両についての情報を含む、任意の適切な基準または複数の基準に基づき得る。少なくとも1つの実施形態では、順序付けは、基準点または基準位置に対する各車両の距離に基づき得る。そのため、リソースの要求は、車両の実際の地理的位置ではなく、ゾーン内の車両の相対的位置（すなわち順序）に基づき得る。これは、位置順のリソース要求と称され得る。その結果、リソースは、車両が送信のためにリソースをランダムに選択して1つまたは複数の他の車両とのリソースコリジョンの危険を冒す代わりに、順序付けに基づいてゾーン範囲内の車両によって要求され得る。位置順のリソース要求は、車両アドホックネットワーク内での既存のリソース割り当てアプローチにおいて生じるリソースコリジョンの可能性を低減または取り除き得る。

本開示の実施形態は、チャネルの形式のリソースと共に記載されている。しかしながら、「チャネル」という記述は、限定を意味するものではない。本教示は、他のタイプのリソースにも適用される。

アドホックネットワーク内に、リソース割当てを制御するために、セントラルエンティティが存在しない場合があるので、各車両は、その車両自身のためにリソースを要求し、他の車両、例えばその車両の認識範囲内の他の車両によるリソースの要求または使用を特定または追跡する責任を負い得る。このように、アドホックネットワーク内の車両は協調して、セントラルリソース割り当てエンティティなしに通信リソースを共有および管理する。車両は、2つの車両が同じリソースを要求または使用しようとすることを低減または取り除く目的で、リソースの共有および要求を管理するためのアルゴリズム、規則、またはプロセスを使用し得る。記述を簡単にするため、アルゴリズム、一連の規則などは、単に、チャネル共有アルゴリズムと称され得る。つまり、チャネル共有アルゴリズムは、各車両が、リソースコリジョンのリスクが少ないかまたはない状態でその車両がリソースをいつ要求および使用し得るかを決定することを可能にし得る。

少なくとも1つの実施形態では、車両の順序付けは、ゾーン内の車両の地理的位置に基づき得る。図5Aは、図に示すように左から右方向へ向かう、道路500上の複数の車両520を表している。この特定の走行方向は、説明目的のためだけに使用されており、限定を意味するものではない。複数のゾーン504を定義するために、仮想グリッド502が道路500にマッピングされている。ここでは、簡単にするために、ゾーンi−1、i、i＋1、およびゾーンi＋2だけを示している。

図5Bは、複数のサブフレーム554を有する送信フレーム550を示しており、サブフレームはスロット552に細分され得る。フレーム550の異なるサブフレーム554は、異なるゾーンに対して構成または予め割り当てられ得る。例えば、サブフレーム1はゾーンi−1に予め割り当てられ得、サブフレーム2はゾーンiに予め割り当てられ得、サブフレーム3はゾーンi＋1に予め割り当てられ得る、などである。さらに、サブフレーム554の範囲内の1つまたは複数の時間スロット552は、与えられたゾーン内のチャネルとして予め割り当てられ得る。例えば、サブフレーム2内の時間スロット1からmは、ゾーンiのためのチャネル1からmとして予め割り当てられ得る。

再度、少なくとも1つの実施形態では、車両がゾーン間を移動しており、チャネルがゾーン毎に構成され得るので、チャネルは、時折、例えば定期的に、車両による要求のために利用可能にされ得る。例えば、リソース要求は、時刻0、t、2t、3tなどに実行され得、ここで、tはリソース要求サイクルの幅である。アドホックネットワークでは集中型のリソース管理がないので、各車両はその車両自身のためにリソースを要求し得る。リソース要求のためのプロセスおよび規則は、ほとんどまたはすべての車両について同じであり得るので、車両は、リソースコリジョンのリスクが少ないかまたはない状態で、リソースを要求し得る。少なくとも1つの実施形態では、車両は、時刻2tにおいてリソースを要求するために、時刻tにおいて既知の情報を使用し得る。そのため、車両は、その車両自身についての情報、例えばその車両の現在の位置（その車両がどのゾーンにいるのかを含む）、および他の車両から受信してしまっている類似した情報を、その車両が使用するためのリソースを要求するために使用し得る。車両は、受信した情報、およびすべての車両に共通のチャネル共有アルゴリズムに基づいて、いつ特定のリソースが他の車両によって要求および使用され得るかを特定することができ得る。

図6Aは、少なくとも1つの実施形態における車両において、情報を交換し、リソースを要求するためのプロセスを示すフロー図である。この実施形態では、プロセスは、ネットワーク内のすべての車両において定期的に実行され得る。プロセスは、ブロック600から始まって、車両が、その車両の位置を含んでその車両自身についての情報およびデータを、計測または収集し得るブロック602へ進む。一実施形態では、これは受信したGPS信号を使用して行われる。プロセスは、車両が時刻tにおいて、ビーコンメッセージなどの情報を、その車両の要求済のリソース（例えばチャネルなど）上で送信するブロック604へ進む。時刻tは、送信フレームfの中にある。送信は、協調認識メッセージ（CAM）または他のメッセージを含み得、そのメッセージは、ブロードキャストしている車両の存在、位置、キネマティクス、および他のステータス情報など、ブロードキャストしている車両に関する情報を含み得る。プロセスは、フレームfで他の車両からの送信またはブロードキャストについてリッスンする、ブロック606へ進む。

プロセスは、ブロック606から、車両が1つまたは複数の、タスク、計算、または他の処理、例えば、ブロック606において他の車両から受信した情報を含んで、位置および他の情報の処理を、実行し得るブロック608へ進む。プロセスは、車両が、時間フレームf＋1において使用するためにチャネルを要求するブロック610へ進む。したがって、フレームfでは、車両は、後続の時間フレーム、例えばフレームf＋1において使用されるべき1つまたは複数のチャネルを要求し得る。

プロセスは、次いで、ブロック602に戻り、フレームf＋1でもう一度やり直し得る。したがって、フレームf＋1におけるブロック604での、車両による送信は、フレームfで要求されたチャネル（例えば、チャネルなど）上であり得る。

少なくとも1つの実施形態では、図6Aのプロセスと同じかまたは類似したプロセスは、車両アドホックネットワーク内の車両の一部またはすべてにおいて実行され得る。車両は、任意の適切な方法で時間同期され得る。例えば、一実施形態では、車両は受信したGPS信号を使用して同期され得る。ただし、車両は、他の方法で同期されてもよい。

さらに、図6Aの例では、車両は、プロセスのすべてのループで、すなわちすべてのフレームについて（例えば、ブロック610）、リソースを要求するが、これは限定を意味するものではない。他の実施形態では、リソースは、2フレーム毎、または3フレーム毎、または4フレーム毎などに、要求され、これは図6Aのプロセスまたは類似のプロセスの、2、3、または4ループ毎などに対応し得る。つまり、いくつかの実施形態では、車両は、それらの車両がビーコンメッセージをブロードキャストし、他の車両のブロードキャストをリッスンするすべてのサイクルでリソースを要求する必要は必ずしもない。車両は、より少ない頻度でリソース要求を実行することで十分であり得る。これは、図6Bを参照して記載している。

図6Bは、少なくとも1つの実施形態における、送信およびリソース要求の間隔を表すタイミング図である。隣接する短い矢印652の間隔650それぞれは、送信期間 、例えば時間フレームを表している。車両は、いくつかまたはすべての送信期間で、他の車両に情報を送信またはブロードキャストし得る。隣接する長い矢印662の間隔660それぞれは、リソース要求間隔を表している。リソース要求間隔660は、フレーム幅650の整数倍であり得る。例えば、車両は、1つまたは複数の送信期間650、すなわち符号680で示された1つまたは複数の期間の間、チャネルおよび他の車両についての情報を収集し得る。この情報は、車両によって、1つまたは複数の後続フレームのために、次のリソース要求時刻682において使用され得る。

再度、図5Aを参照して、以下の例では、ゾーンi内の車両A、B、CおよびDに着目する。例では、各ゾーンは5つのチャネルで構成される。その結果、ゾーンiは、チャネルc_i，1、c_i，2、c_i，3、c_i，4、およびc_i，5を有している。車両Dは、ゾーンiにおいてすでにチャネル、例えばチャネル1、すなわちc_i，1を要求していることも仮定する。車両Dは、例えば前にチャネルが要求されたとき（例えば、フレームf−1）にその車両がゾーンiにいたことから、すでにチャネルを要求してしまっている場合があり、その結果、その車両のチャネル、c_i，1を保持してしまっている場合がある。ただし、車両がゾーンを変更してはいないにもかかわらず、車両がその車両のチャネルを保持していない他の実施形態では、この車両は、チャネルを必要とする車両グループに含まれ得る。

一方で、車両A、BおよびCは、ゾーンi内でチャネルを有していないので、チャネルを必要としている。車両A、BおよびCは、1つまたは複数の理由によって、ゾーンi内でチャネルを有していない場合がある。例えば、車両A、BおよびCのうちの、1つまたは複数は、前にチャネルが要求されてから後に、ゾーンi−1からゾーンiに移動してしまっている場合がある。

前述の例では、車両A、BおよびCのうちの、1つまたは複数は、ゾーンi−1からゾーンiに到着したばかりであり得る。そのため、これらの車両のそれぞれは現在、ゾーンi−1からのチャネルを使用してその上でブロードキャストしている場合がある。ただし、これらの車両はゾーンi−1を離れてしまっているので、次にチャネルが要求されるとき（例えば、フレームf）には、これらの車両はもはやゾーンi−1内のチャネルを使用する資格を満たし得ない。したがって、これらの車両は、次のリソース要求サイクルにおいてゾーンiのチャネルを要求しようとし得る。

そのため、本開示の一態様によれば、ゾーンi内の空いているかまたは利用可能なチャネルは、車両A、BおよびCのうちの、1つまたは複数よって、そのゾーン範囲内の車両の相対的位置決めまたは順序付けに基づいて要求され得る。少なくとも1つの実施形態では、順序付けは、少なくとも1つの基準点または基準位置に対する各車両の距離に基づき得る。少なくとも1つの基準点は、任意の適切な基準点でもよい。少なくとも1つの実施形態では、基準点または基準位置は、ゾーンの端であり得る。例えば、グリッド502内のゾーン504は、一般に形状が四角形をしているが、別の形状のゾーンも可能である。ゾーンiは、第1および第2のゾーン側端530および532、ならびに第1のゾーン末端534および第2のゾーン末端536を有し得る。記述を簡単にするため、第1および第2のゾーン末端534、536は、それぞれ左ゾーン端および右ゾーン端と称され得る。

少なくとも1つの実施形態では、車両は、ゾーン範囲内で、ゾーンの端に対するそれらの車両の距離に基づいて順序付けられ得る。例えば図5Aでは、チャネルを有していない、ゾーンi内の車両は、右ゾーン端536に対するそれらの車両の距離に基づいて順序付けられ得る。昇順に順序付けられ、車両は、C、AそしてBのように順序付けられることになる。車両Cは、3つの車両のうちで右ゾーン端536に最も近い。車両A、BおよびCの中で、車両Aは次に近く、車両Bは3番目に近い。車両がゾーン範囲内で左から右へ走行していると仮定すると、こうした順序付けは、より早い時刻にそのゾーンに入った車両を優先し得る。ただし、車両は他の方法で順序付けられてもよいことを理解されたい。例えば、一実施形態では、車両は、左ゾーン端534に対するそれらの距離に基づいて順序付けられ得る。別の実施形態では、車両は、ゾーンの内側または外側の、他の何らかの基準点に対するそれらの車両の距離に基づいて順序付けられ得る。

本例では、ゾーンi内で1つのチャネルだけが現在要求されており、つまり車両Dによってチャネルc_i，1が要求されている。そのため、ゾーンi内で4つの空きチャネルが、つまりc_i，2、c_i，3、c_i，4およびc_i，5が利用可能である。空きチャネルは、前述のように、車両A、BおよびCによって、右ゾーン端536に対するそれらの車両の相対的位置に基づいて要求され得る。車両の相対的位置は、右ゾーン端536に対する各車両の距離によって決定され得る。少なくとも1つの実施形態における、この順序付けに基づいて要求するチャネルの一例を、以下の表1に示す。

車両Cは、チャネルを必要とする車両の順序付けされたリスト内の1番目の車両なので、チャネル要求処理において優先される。ここでは、順序付けに基づくチャネル要求アルゴリズムによって、車両Cに、その車両が空きチャネルc_i，2を要求し得る、と判定することを可能にしている。同じアルゴリズムを使用して、車両Aは、その車両の相対的位置を決定する時点で、その車両が順序付けリスト内の次の車両であり、したがって空きチャネルc_i，3を要求し得ると判定することができる。車両Bは、その次の車両であり、空きチャネルc_i，4を要求し得る。こうした実施形態では、車両は、現在のゾーンの端にそれらの車両がどれぐらい近いかに基づいて、特定のチャネルを要求する。例えば、車両Cは、右ゾーン端536に近いので、車両Cは、番号が最も小さいチャネルを要求する能力が提供される。当業者は、車両がゾーン内の中間点に対するそれらの車両の距離に基づいて順序付けられる、または、車両の位置および速度の両方を考慮する規則などを含んで、他の順序付け規則を適用することができることを理解するだろう。

特定の車両によって特定のチャネルが要求される順序付けまたは方法は、任意の適切な方法で行われ得る。前述の例では、空きチャネルは、それらの空きチャネルのチャネルインデックスの昇順に基づいて要求され、すなわちc_i，2は一番低いチャネルインデックス（例えば2）を有しており、したがって順序付けリスト内の1番目の車両である車両Cによって要求され得る。チャネルc_i，3（チャネル3）は、次に低いインデックスを有しており、したがってリスト内の次の車両によって要求され得る、などである。ただし、他の実施形態では、空きチャネルは、チャネルインデックスの降順に基づいて、または任意の他の方法で要求され得る。

さらに、右ゾーン端536を、チャネルを必要としている車両を順序付けするための基準点として使用することは、ほんの一例である。1つまたは複数の他の基準点が、ゾーン範囲内の車両の順序付けを見いだすために使用され得る。例えば、一実施形態では、車両は、左ゾーン端534に対するそれらの車両の距離に基づいて、昇順で順序付けられ得る。

また、例では、車両は、右ゾーン端536に対するそれらの車両の距離に基づいて、昇順で順序付けられているが、これは限定を意味するものではない。車両は、ゾーン端または他の基準点に対するそれらの車両の距離に基づく降順を含んで、任意の適切な方法で順序付けられ得る。

本開示の別の態様によれば、与えられたゾーン範囲内の1つまたは複数の車両は、1つまたは複数の他のゾーンからチャネルを要求し得る。それらのチャネルは、車両の2次チャネルと称され得、一方、そのゾーンの範囲内の車両によって要求される、ゾーンのチャネルは、1次チャネルと称され得る。いくつかの実施形態では、2次チャネル、別のゾーンに属しているが、これは、車両が、別のゾーンにいる車両から情報を取得および交換するために使用することができる。これにより、より多量の情報を車両に提供することを可能にする。与えられた車両の観点からすると、チャネルは1次、2次などと見なすことができるが、他の車両の観点からすると、それらのチャネルは、単に予約されてしまっているチャネルと見なされ得る。

少なくともいくつかの実施形態では、2次チャネルの要求は、ゾーン範囲内の車両の相対的位置または順序付けに基づき得る。いくつかの実施形態では、2次チャネルの要求は、本明細書に記載の、1次チャネルの要求と類似し得る。

ここで、2次チャネル要求の一例を、図5Aを参照しつつ記載する。

ゾーン内の車両は、1つまたは複数の1次チャネルを要求し得るが、その車両は、1つまたは複数の2次チャネルも要求し得る。例では、ゾーンi＋1内の車両E、FおよびGは、1次シャネルc_i＋1，1、c_i＋1，3およびc_i＋1，4を要求してしまってい得る。例では、各ゾーンは、合計5つのチャネルを有しているので、その結果、ゾーンi＋1は、2つの空きチャネル、つまりc_i＋1，2およびc_i＋1，5を有している。少なくとも1つの実施形態では、ゾーン、ここではゾーンi＋1内の1つまたは複数のこうした空きチャネルは、異なるゾーン、ここではゾーンi内の車両によって要求され得る。

車両は、任意の適切な方法で、他のゾーンの1つまたは複数の空きチャネルを認識することになり得る。少なくとも1つの実施形態では、この情報は、他の車両の定期的なブロードキャストメッセージに含まれ得る。例えば、車両は、例えばフレームfにおいて、こうした情報を受信し得、次いで、フレームf＋1または任意の将来のフレームなどの将来のフレームのためにリソースを要求するときにその情報を使用し得る。いくつかの実施形態では、車両は、他のゾーンの1つまたは複数の空きチャネル、およびおそらくこれらのチャネルのステータスさえも、一切ブロードキャストさえなしに認識し得る。例えば、フレームf＋1のための要求に対して空いているであろうチャネルは、フレームfおよび車両の一切のハンドオーバにおいて車両で受信した情報に基づいて抽出され得る。したがって、空きチャネルを示すブロードキャストメッセージは、それらの車両がすでに有している情報からこの情報を抽出することができる車両にとっては冗長であり得る。ただし、こうしたブロードキャストは、1つまたは複数の車両がこの情報を抽出できないとき、例えばブラインド車両の場合には有用であり得る。

他のゾーンからの空きチャネルの要求は、任意の適切な方法で行われ得る。少なくとも1つの実施形態では、空きチャネルは、1次チャネルと類似した方法で要求され得る。例では、ゾーンi＋1の空きチャネルc_i＋1，2およびc_i＋1，5は、車両A、B、CおよびDによって、そのゾーン範囲内の車両の相対的位置に基づいて要求され得る。例えば、要求は、車両の昇順の順序付けに基づき得、順序付けは、右ゾーン端536に対するそれら車両それぞれの距離に基づき得る。したがって、車両のリストは、D、C、A、そしてBと順序付けられるだろう。なお、一実施形態において前述したように1次チャネルを必要としていた車両だけとは対照的に、ここでは、ゾーンi内のすべての車両が順序付け済のリストに含まれ得る。

少なくとも1つの実施形態において前述した順序付けに基づく、2次チャネルの要求の一例示的説明を以下の表2に示す。

車両Dは、車両の順序付け済リスト内の1番目の車両なので、2次チャネルのための要求プロセスにおいて優先され得る。ここでは、車両において実施された共通のチャネル共有アルゴリズムは、車両Dが空きチャネルc_i＋1，2を要求し得ると判定する。車両Cは、順序付け済リスト内でその次の車両であり、したがって空きチャネルc_i＋1，5を要求し得る。ゾーンi＋1からのこれ以上空きチャネルはなく、その結果、車両AおよびBは、このゾーンから2次チャネルを一切要求し得ない。

この実施形態では、車両は、その車両がその車両の現在のゾーンの端に対してどれほど近いかに基づいて、2次チャネルを要求し得る。ゾーン内での車両の順序は、それらの車両が、道路にそって走行しながらそのゾーンを離れる可能性が高い順序を表し得る。例えば、車両Dは、右ゾーン端536に最も近いので、車両Dは、車両A、BおよびCより前にゾーンiを離れるだろうという可能性が高い。そのため、車両Dは、ゾーンi＋1の空きチャネルを2次チャネルとして要求するために、ゾーンiにおいて優先される。車両Cは、右ゾーン端536に対してその次に近い車両なので、同様に2次チャネルを要求する。この方法による2次チャネルの要求は、その車両の現在のゾーンに存在する次の車両になる可能性が高く、したがってゾーン間の遷移状態にいることになるであろう車両を優先する。多くの場合、第1のゾーンにいる間に車両によって要求された2次チャネルは、次いでその車両が新たなゾーンに移動したときに、その車両のための1次チャネルとして使用することができる。このことを、ハンドオーバとの関連で以下に説明する。

そのためこの例では、2次チャネルは、最も高い優先順位の車両から開始して、残っている空きチャネルがなくなるまで、車両によって要求され得る。いくつかの実施形態では、車両は、2つ以上の2次チャネルを要求し得る。ただし、少なくとも1つの実施形態では、車両は、2次チャネルを1つだけ要求し得る。そのため、ゾーン内にいる車両よりも多くの空き2次チャネルがある場合、あらゆる車両は、2次チャネルを1つだけ要求し得る。残っている空き2次チャネルは、要求されないままになるか、または、いくつかの実施形態では、別のゾーン内の車両に対して利用可能になり得る。後者の状態を、以下の例によって記載する。

図5Aを参照すると、ゾーンi＋2内の車両Hは、1次チャネルc_i＋2，1を要求し得るか、または前に要求してしまっている。そのため、ゾーンi＋2は、4つの空きチャネルを有している。車両が2次チャネルを1つだけ要求し得る実施形態では、車両において実施されたチャネル共有アルゴリズムは、車両G、F、およびEが、チャネルc_i＋2，2、チャネルc_i＋2，3、およびチャネルc_i＋2，4を2次チャネルとして要求し得ると判定し得る。チャネルc_i＋2，5は、要求されない状態であり得る。

少なくとも1つの実施形態では、これら要求されなかった2次チャネルのうちの1つまたは複数は、別のゾーン内の車両に対して利用可能になり得る。例えば、チャネルc_i＋2，5は、ゾーンi内の車両に対して利用可能になり得る。こうした1つまたは複数の空きチャネルは、任意の適切な方法で、ゾーンi内の車両によって要求され得る。車両が2次チャネルを1つだけ要求し得る一実施形態では、空きチャネルc_i＋2，5は、ゾーンについての順序付け済リスト内で2次チャネルをまだ割り当てられていない、最も高い優先順位の（例えば、順序付けをされた）車両によって要求され得る。本例では、以下の表3に示すように、チャネルc_i＋2，5は、車両Aによって要求され得る。

車両が2つ以上の2次チャネルを要求し得る別の実施形態では、前述の例の空きチャネルc_i＋2，5は、ゾーン内の最も高い優先順位、例えば、ゾーン内のすべての車両の順序付け済リスト内の最も高い優先順位の車両によって要求され得る。その結果、例では、チャネルc_i＋2，5は、車両Aではなく車両Dによって要求され得る。

ただし、別の実施形態では、チャネルc_i＋2，5などの1つまたは複数のチャネルは、ゾーンi内の車両に対するのとは異なる方法で要求され得るか、または異なるゾーンの車両によって要求される場合さえある。例えば、ゾーンi内のすべての車両がすでに2次チャネルを要求してしまっている異なる状態においては、チャネルc_i＋2，5は、ゾーンi−1内の車両に対して利用可能になり得る。一実施形態では、車両は、その車両の認識範囲内の任意のゾーンから2次チャネルを要求することができ得る。他のオプションが可能である。

少なくともいくつかの実施形態では、車両は、その車両の認識範囲内の一部またはすべての他のゾーン内の他の車両によって要求された2次チャネルを特定し、知り得る。一例によって、一実施形態でこれがどのようにして実現されるのかを説明している。車両は、ゾーンi内にいて、ゾーンi＋2から空きチャネルを要求し得る。そうするためには、車両は、ゾーンi＋2内の空きチャネルの現在のリストを知る必要があり得る。前述のように、ゾーンi＋2内の1つまたは複数の空きチャネルについての優先権は、ゾーンi内のいかなる車両よりも先に、ゾーンi＋1内の車両に対して与えられ得る。そのため、ゾーンi内の車両は、ゾーンi＋1内の一切の車両によってゾーンi＋2の空きチャネルが要求されてしまった後に残っている、ゾーンi＋2の空きチャネルがもしあれば、そのリストを知ることに関心がある。残っているゾーンi＋2の空きチャネルがある場合、それらのチャネルはゾーンi内の車両によって要求され得る。そのため、少なくとも1つの実施形態では、ゾーンi内の車両は、ここでは例えば、ゾーンi内で2次チャネルを要求するための空きチャネルの正しいリストを得るためにゾーンi＋1について、他のゾーン内の他の車両によって要求された2次チャネルを特定するかまたは知る。

前述の実施形態例では、与えられたゾーン（例えば、ゾーンi）内の車両は、それらの車両のゾーンの「前方の」ゾーン（例えば、ゾーンi＋1、i＋2など）から2次チャネルを要求するとして記載されている。ただし、これは限定を意味するものではない。車両は、他の任意のゾーンから、例えば車両のゾーンの「後方の」ゾーン（例えば、ゾーンi−1、i−2など）から2次チャネルを要求し得る。

与えられたゾーン内の車両による、ゾーン範囲内の車両の順序付け、またはゾーン境界に関する車両の相対的位置に基づくリソースの要求は、他のリソース共有またはアクセススキームを上回る利点を提供し得る。再度、少なくともいくつかの実施形態では、リソースの要求は、車両の実際の地理的位置ではなく、ゾーン範囲内の車両の相対的位置（例えば、順序付け）に基づく。車両の順序付けを使用することで、いくつかの実施形態の、車両の位置計測誤差に対する敏感さを軽減または取り除き得る。位置計測誤差の一例は、地理的位置を決定するGPSにおける誤差である。そのため、本開示の少なくともいくつかの実施形態では、たとえ大きな位置計測誤差でも、リソース要求パフォーマンスに顕著な、または些細な影響さえも与え得ない。例えば、車両が、その車両の位置をその車両の実際の位置から20メートル離れていると、間違って決定した場合、車両はこの間違った情報を近隣の車両にブロードキャストする。近隣は、本明細書では、別の車両の範囲、例えば認識範囲内にいる車両を意味するために使用する。車両は、その車両の位置を間違って決定してしまっているが、近隣にいるすべての車両は、同じ間違った位置を使用し、車両の同じ順序付けに到達することになる。そのため、間違った位置情報は、リソースコリジョンの可能性を必ずしも高めないことになる。

本開示の別の態様によれば、車両アドホックネットワーク内でリソースハンドオーバ状態を処理するために、1つまたは複数のアプローチが提供される。リソースハンドオーバという用語は、車両がゾーン間を移動するときに、車両によってどのようにしてリソースが要求されるのかに関する。

車両は、いくつかのリソース要求サイクルの間、同じゾーン内に留まり得る。いくつかの実施形態では、車両は、その車両が同じゾーン内に留まっている間、その車両の1次チャネルを保持し得、その車両の2次チャネルさえも保持し得る。ただし、いくつかの実施形態では、車両がたとえ同じゾーン内に留まっていたとしても、2次チャネルは開放され、いくつかの、または各リソース要求サイクルにおける要求のために利用可能にされ得る。

ただし、車両がゾーンを変更するとき、車両の1次チャネルは放棄され得、新たなゾーン内の新たな1次チャネルが取得され得る。ここで、少なくともいくつかの実施形態のいくつかの異なる可能性および状態を記載する。

図7A、図7B、および図7Cを参照し、それぞれは、仮想グリッド内の隣接している3つのゾーンi−1、i、i＋1を示している。図7Aは、車両AからEのためにフレームfにおいて行われるべき送信のための、フレームfー1におけるリソース要求を示している。図7Bは、フレームfで送信が起こるときの、さまざまなチャネルのステータスを示している。車両AおよびBは、ゾーンi−1からゾーンiへ移動していまい、車両Eは、ゾーンiからゾーンi＋1へ移動してしまっている。図7Cは、フレームf＋1において車両によって行われるべき送信のための、フレームfにおけるリソース要求を示している。

図7Aにおいて最も太い曲線の矢印で示されるように、フレームfにおいて、車両AからEのそれぞれは、1次チャネル、すなわち700、702、704、706および708を有している。また、車両Aは、ゾーンiから2次チャネル710を有しており、車両Dは、ゾーンi＋1から2次チャネル712を有している。

図7Bに示すように、車両A、BおよびEは、ゾーン間を移動し、それらの車両の1次チャネル700、702および708は、ステータスを変更して一時的チャネルとなり、破線の矢印で示されている。車両A、BおよびEは、フレームfの間、ブロードキャストするためにそれらの車両の1次チャネルをまだ使用し得る。また、車両Aの2次チャネル710のステータスは、図7Bにおいて太い矢印線710で示されるように、2次チャネルから1次チャネルへ変化する。このチャネルはゾーンiに属しているので、そのチャネルは車両Aの1次チャネルになり得る。

図7Cは、フレームf＋1において行われるべき送信のための、フレームfにおける車両のためのリソース要求を示している。図7Bに示す、車両A、BおよびEそれぞれの一時的チャネル700、702および708は、車両が別のゾーンにいたときに、それらのチャネルが1次チャネルとして以前に要求されたため、放棄される。車両A、CおよびDは、それらの車両の1次チャネル、それぞれ710、704および706を保持し得る。新たなゾーンへ移動した後、図7Bに示すように、車両BおよびEは、1次チャネルを有していない。そのため、図7Cに示すように、車両BおよびEは、フレームf＋1のために1次チャネル714および716をそれぞれ要求し得る。チャネル714および716は、車両BおよびEのそれぞれのゾーン、すなわちゾーンiおよびi＋1に属している。1次チャネル714は、前述したように車両の相対的位置に基づくゾーンi内の車両の順序付けに基づくことを含んで、任意の適切な方法で要求され得る。1次チャネル716は、ゾーンi＋1のチャネルの中から類似の方法で要求され得る。

さらに、車両は、1つまたは複数の2次チャネルも要求し得る。例えば、図7Cに示すように、車両CおよびBは、フレームf＋1のために2次チャネル718および720をそれぞれ要求し得る。これらの2次チャネルも、例えば車両の相対的位置に基づいた、ゾーンi内の車両の順序付けに基づくことを含んで、任意の適切な方法で要求され得る。例えば、車両BおよびCは、ゾーンiの右ゾーン端750に対する近さに基づいて順序付けされ得る。こうした場合、その順序付けは、Cその次にBということになるだろう。結果的に、少なくとも1つの実施形態では、車両Cは、ゾーンi＋1から空きチャネルを2次チャネルとして要求することにおいて、車両Bに優先することになるだろう。

図8は、本開示の少なくとも1つの実施形態に係る、ハンドオーバ状態を処理するためのプロセスを示すフロー図である。ハンドオーバ処理は、車両アドホックネットワーク内のすべての車両において実行され得る。このように、車両のそれぞれは、車両が1つのゾーンから別のゾーンへ移動する結果としての、1つまたは複数のチャネルの、開放および要求を追跡することができ得る。

プロセスは、ブロック800から始まって、ゾーンi内に位置している車両がフレームfにおいてアクティブなチャネルをリッスンするブロック802へ進む。これらのチャネルは、異なるK個のゾーン、例えば車両の認識範囲内のゾーンに属し得る。車両は、ゾーン上のチャネルをゾーン毎に分類し得、ここで、考慮されているゾーンは、「j番目」のゾーンと称される。一実施形態では、車両は、フレームf＋1における通信のためにフレームfにおいてK個のゾーンのj番目のゾーンのチャネルを、以下の表4に従って分類し得る。

表4では、PCHは1次チャネルであり、同じゾーン内の車両によって使用されるチャネルを意味している。SCHは2次チャネルであり、別の（例えば、前の）ゾーン内の車両によって使用される第1のゾーンのチャネルを意味する。この例では、あらゆる2次チャネル（SCH）は開放され（例えば、空きチャネルになる）、次のリソース要求サイクルのために利用可能にされる。ただし、前述したように、他の実施形態では、2次チャネル（SCH）は、1つを超えるリソース要求サイクルの間車両によって要求されたままであり得る。ゾーンi＋1からi＋Uは、ゾーンiの前方のゾーンであり、車両の認識範囲内にあるものと仮定される。そのため、ゾーンqはゾーンi＋1からi＋Uの範囲内のゾーンである。ゾーンi内の車両は、ゾーンi＋1からゾーンi＋Uの1つまたは複数から、1つまたは複数のチャネルを2次チャネルとして要求する可能性があり得ることも仮定される。

TCHは、一時的チャネルである。I−TCHは、入ってくる一時的チャネルをいい、O−TCHは出て行く一時的チャネルをいう。一時的チャネルは、車両が出発したばかりのゾーン（例えば、前のゾーン）にチャネルが属している、新たなゾーンに到着する車両によって使用されるチャネルである。そのため、新たなゾーンの観点からすると、一時的チャネルは、入ってくる一時的チャネル（I−TCH）である。前のゾーンの観点からすると、そのチャネルは、出て行く一時的チャネル（O−TCH）である。TCHは、次のリソース要求サイクルにおける要求のために即座に開放され得る。ただし、別の実施形態では、TCHは一定の状態において、例えば、車両が新たな1次チャネル（PCH）を見つけることができない場合には、車両によって保持され得る。これは、車両が、異なるゾーンへ移動したときに、車両がブラインドかまたはハンドオーバ状態にある場合など、何らかの理由で起こりえる。f−CHは、空きチャネルであり、次のフレーム（例えば、フレームf＝f＋1）における要求のために空いていると仮定されるチャネルを意味する。

同様に、車両は、ゾーン上の別の車両をゾーン毎に分類し得、ここで再度、考慮されているゾーンは、「j番目」のゾーンと称される。したがって、少なくとも1つの実施形態では、フレームfにおいてアクティブなチャネルをリッスンしている、ゾーンj内に位置している車両は、以下の表5に従って車両を分類し得る。

表5では、L−車両はローカルな車両であり、その車両が聴取されるときに1次チャネル（PCH）を有する車両を意味する。I−車両は入ってくる車両であり、直近にゾーンに到着したハンドオーバ車両で、その車両がPCHチャネルをまだ有していないことを意味する。O−車両は出て行く車両であり、出て行く一時的チャネル（O−TCH）を有しながら、直近にゾーンを離れてしまっているハンドオーバ車両を意味する。h−車両は、ハンドオーバ車両である。ゾーンの観点からすると、ハンドオーバ車両は、I−車両か、またはO−車両である。

再度、図8を参照して、プロセスは、ブロック802から、ゾーンjの1つまたは複数の車両が分類され得るブロック806へ進む。少なくとも1つの実施形態では、ゾーンjの車両は、一度に1つ考慮され得る。詳細には、分類されている車両は、ゾーンjのx番目の車両と称され得る。そのため、ブロック806では、ゾーンjのx番目の車両がローカルな車両（L−車両）かどうかを判定し得る。x番目の車両がゾーンjのL−車両である場合、プロセスは808へ進み、そこでは、x番目の車両は、フレームf＋1における送信のためにその車両の現在の1次チャネル（PCH）を保持するものと仮定される。ただし、x番目の車両がゾーンjのL−車両でない場合、プロセスは810へ進み、そこでは、x番目の車両は、ゾーンjのハンドオーバ車両群（h−車両−Set）に加えられる。

ブロック808および810の両方から、プロセスは、ゾーンj内に他の車両（例えば、まだ分類されていない他の車両）があるかどうかを判定するブロック812へ進む。ゾーンj内に少なくとも1つの他のアクティブな車両がある場合、プロセスは、ブロック806へ戻り、次の車両（x＋1番目の車両）が考慮される。ただし、他にアクティブな車両がない場合は、プロセスは、ブロック814へ進み、そこでは、ゾーンjについてのh−車両−Setの中の車両が、任意の適切な方法で順序付けられ得る。車両は、互いに対するそれらの車両の相対的位置に基づいて順序付けられ得る。例えば、前述のように、車両は、ゾーンjの右ゾーン端に対するそれらの車両の距離に基づいて、昇順で順序付けられ得る。ここでは、説明目的のために、車両がゾーン内を左から右へ走行していると仮定している。ただし、h−車両−Setの中の車両は、任意の他の適切な方法で順序付けられてもよい。

プロセスは、ブロック814からブロック816へ進み、そこでは、ゾーンjのy番目のチャネルがゾーンjの1次チャネル（PCH）かどうかが判定される。y番目のチャネルが1次チャネルである場合、プロセスは、ブロック820へ進む。y番目のチャネルが1次チャネルではない場合、プロセスは、818へ進み、そこでは、そのチャネルはゾーンjの空きチャネル群（f−CH−Set）に加えられる。

プロセスは、次いで、ブロック818からブロック820へ進み、そこでは、分類されるべき他のチャネルがゾーンj内にあるかどうかが判定される。少なくともあと1つのチャネルがゾーン内にある（例えば、いずれかのチャネルがまだ分類されていない）場合、プロセスは、ブロック816へ戻り、次のチャネル（y＋1番目の車両）が考慮される。さらなるチャネルがないとき、プロセスは、ブロック820からブロック822へ進み、そこでは、f−CH−Set内のチャネルが順序付けられ得る。前述のように、チャネルは、それらのチャネルのチャネルインデックスに基づいて、昇順または降順で順序付けられ得る。ただし、h−CH−Setの中のチャネルは、任意の他の適切な方法で順序付けられてもよい。

プロセスは、ブロック822からブロック824へ進み、そこでは、図8のプロセスを実行する車両は、ゾーンjのh−車両−Set内の車両によって1次チャネルとして要求される、ゾーンjのf−CH−Set内の空きチャネルを特定し得る。再度、他の車両によって空きチャネルがどのようにして要求されるかを特定する車両は、他の車両に関連する情報および共通のチャネル共有アルゴリズムを使用してそうし得る。そのため、車両は、他の車両によるチャネルの要求を、他の車両からの要求に関するインディケーションを一切受信することなく推定することができ得る。いくつかの例では、ゾーンjの空きチャネル群f−CH−Set内の必ずしもすべてのチャネルが、ゾーンj内の車両によって1次チャネルとして要求され得る訳ではないが、これらのチャネルは他のゾーン内の車両によって2次チャネルとして要求され得、空きチャネルの特定は、リソースコリジョンの回避において重要である。

車両によってチャネルが要求される方法は、ゾーン範囲内のそれらの車両の相対的位置に基づいて順序付けられた、ゾーン内の車両のリストに基づいて1次チャネルを要求する、本明細書に記載の方法を含んで、任意の適切な方法で行われ得る。例えば、順序付け済の車両のリスト内の一番上にある車両が優先されて、順序付け済のf−CH−Setから第1のチャネルを要求し得る。その車両およびチャネルは、それぞれh−車両−Setおよびf−CH−Setから削除される。チャネル要求は、次いで、同じ方法で継続し、順序付け済の車両のリストの一番上にある1番目の車両が優先されて、順序付け済のf−CH−Setの一番上にあるチャネルを要求する。少なくとも1つの実施形態では、このチャネル要求プロセスは、繰り返して行われ得、そこでは、h−車両−Set内の車両は、f−CH−Setからチャネルを要求し、次いで、車両およびチャネルの両方が、その車両およびチャネルそれぞれのh−車両−Setおよびf−CH−Setから削除される。次いで、h−車両−Set内の次の車両が、f−CH−Set内に残っているチャネルの中からチャネルを要求する。ただし、他の実施形態では、チャネル要求は、繰り返して実行される必要はない。

ブロック824における、他の車両によって要求されるチャネルを特定する手順は、例えば、h−車両−Set内のすべての車両がチャネルを要求してしまうか、またはf−CH−Set内のすべての空きチャネルが要求されてしまうかまで継続し得る。プロセスは、次いでブロック826へ進み得、そこでは、K個のゾーン群内に分類されるべき他のゾーンがあるかどうかが判定される。少なくともあと1つのゾーンがある場合、プロセスはブロック806へ戻り得る。ただし、分類すべきさらなるゾーンがない場合は、プロセスはブロック828へ進み、終了し得る。

図8の実施形態は、プロセス内に特定の数および順序のステップを示しているが、これは限定を意味するものではない。例えば、ステップの順序は、別の実施形態では異なり得る。また、いくつかの実施形態では、いくつかのステップが、シーケンシャルではなくパラレルに実行され得る。例えば、与えられたゾーンの車両のすべておよびチャネルのすべてを分類することが、パラレルに行われ得る。他のオプションが可能である。

図9は、本開示の少なくとも1つの実施形態に係る、車両アドホックネットワーク内の車両における位置順のリソース要求のための一般的なプロセスを示すフロー図である。プロセスは、1次および2次チャネル要求ならびにハンドオーバ処理を含む。車両は、その車両自身のために1つまたは複数のチャネルを要求し得る。また、車両は、その車両の認識範囲内の他の車両によって要求され得る空きチャネルを、他の車両の位置に基づいて特定し得る。そのため、車両は、おそらくその車両自身のためのチャネルを要求するため、および他の車両によって要求された他のチャネルを特定するために、その車両自身の位置、ならびに他の車両から受信した位置およびおそらく他の情報を使用し得る。各車両は、他の車両についての同じかまたは類似した情報を取得することから、および、各車両は、共通のチャネル共有アルゴリズムを実施することから、車両は、リソースコリジョンの可能性が低い状態でチャネルを共有するために協調し得る。

少なくともいくつかの実施形態では、図9のプロセスにおけるいくつかのステップは、ステップを実行する車両の認識範囲内の1つまたは複数のゾーン内の、車両およびチャネルの、特定および分類を含めて、図8のプロセスにおける1つまたは複数のステップと関係があり得る。

プロセスは、ブロック900から始まって、そこでは、車両はゾーンiに位置しており、時刻は時間フレームfである。当業者は、時間フレームfへの参照は、特定のデータフレームが送信される時間ウィンドウへの参照であると理解することができることを理解するだろう。ウィンドウは、単一のフレームの送信時間よりも長くすることができるが、一般に、より短くはない。プロセスは、ブロック902へ進み、そこでは、車両は、その車両の1つまたは複数の要求済のチャネル上で送信し得、ゾーンiの他のチャネル上および他のゾーンの1つまたは複数のチャネル上でリッスンもし得る。

プロセスは、ブロック902からブロック904へ進み、そこでは、ゾーンiおよび他の近隣のゾーンのアクティブなチャネルが特定され得る。これらのアクティブなチャネル上で送信する車両の位置も決定され得る。いくつかの実施形態では、車両は、現在の送信期間においてどのチャネルがアクティブかを、以前の送信期間において得た情報に基づいてすでに知り得る。ノードは、他のノードがどこにあるのか、およびそれらの他のノードが使用するチャネルを知り得ることから、非常に高い可能性で、どのチャネルが予約されてしまっているのかを判定することが可能であり得る。こうした判定は、アクティブなチャネルを明示的に特定することを避けるために使用することができる。ただし、別の状態では、車両は、一部またはすべてのチャネルのアクティブなステータスを知るための十分な情報を有していない場合がある。こうした場合、車両は、少なくとも部分的には「ブラインド」である。こうした状態、または車両が別の状態でネットワークに入る必要がある場合は、車両は、アクティビティ検出プロセスをとおしてアクティブなチャネルを独自に特定し得る。

プロセスは、次いで、ブロック906へ進み、そこでは、車両の認識範囲内の一部またはすべてのゾーンについて、1次チャネルを有していない車両および空きチャネルの両方が特定される。詳細には、与えられたゾーンの範囲内にいて1次チャネルを有していない、V2Vネットワークに関与しているすべての車両は、そのゾーンのh−車両−Setに加えられ得る。h−車両−Set内の車両は、次いで、任意の適切な方法で、例えば、前述のように、ゾーン範囲内のそれらの車両の相対的位置に基づいて、順序付けられ得る。また、認識範囲内のゾーンの各ゾーンの範囲内のアクティブなチャネルの中の1次および2次チャネルが特定され得る。空きチャネル群（f−CH−Set）は、認識範囲内のゾーンの各ゾーンについて、特定のゾーンの非アクティブおよび2次的にアクティブなチャネルの集合として決定される。少なくとも1つの実施形態では、f−CH−Set内のチャネルは、任意の適切な方法で、例えば、チャネルインデックスに基づく昇順で、順序付けられ得る。 方法のいくつかの実施形態では、V2Vネットワークの一部ではないレガシー車両は、h−車両−Setへの指定から除外される。

プロセスは、ブロック906からブロック908へ進み、そこでは、1次チャネルが要求される。図9のブロック908では、認識範囲内の各ゾーンについて、ゾーンのh−車両−Set内にない、特定のゾーンの車両は、フレームf＋1における送信のためにそれらの車両の1次チャネル（PCH）を保持し得る。一方、ゾーンのh−車両−Set内の車両は、そのゾーンのチャネルを1次チャネルとして要求し得る。h−車両−Set内の車両の順序付けは、前述のように、1次チャネルの要求の優先順位を付けるために使用され得る。例えば、順序付け済のh−車両−Set内の1番目の車両は、優先してf−CH−Setから空きチャネルを要求し得る。順序付け済のh−車両−Set内の2番目の車両は、2番目に優先してf−CH−Setから空きチャネルを要求し得る、などとなる。車両は、他の車両によって1次チャネルとして要求された空きチャネルを、他の車両についての情報（例えば、それらの車両の位置など）およびチャネル共有アルゴリズム（例えば、ゾーン内の相対的な車両位置など）を使用して特定し得る。いくつかの実施形態では、このチャネル要求プロセスは、前述の、図8のブロック824の1次要求プロセスに類似し得る。そのため、ブロック824の記述は、ここでは完全には繰り返されない。

プロセスは、908から910へ進み、そこでは、利用可能な場合、車両によって2次チャネルが要求され得る。車両は、他の車両によって2次チャネルとして要求された空きチャネルを、他の車両についての情報（例えば、それらの車両の位置など）およびチャネル共有アルゴリズム（例えば、ゾーン内の相対的な車両位置など）を使用して特定することができ得る。2次チャネルは、本明細書に記載の方法を含んで、任意の適切な方法で要求され得る。例えば、ゾーン内の車両が順序付けられ得、次いで、2次チャネルが順序付けに基づいて1つまたは複数の車両によって要求され得る。少なくとも1つの実施形態では、車両は、一度に最大1つの2次チャネルを要求し得る。ただし、別の実施形態では、車両は、複数の2次チャネルを要求し得る。複数の2次チャネルは、同じゾーンまたは2つ以上の異なるゾーンに属し得る。

プロセスは、ブロック910から912へ進み、そこでは、フレームfはインクリメントされ、例えばf＝f＋1となる。

プロセスは、ブロック912からブロック902へ進み、そこでは、プロセスが再スタートし得る。

本開示の別の態様によれば、ブラインド車両の回復を可能にするために、1つまたは複数のアプローチが提供される。

車両が、必要な機能、例えば、やってくるフレーム（例えば、フレームf＋1など）のためのリソース要求を、その車両が実行することを可能にするための十分な情報を受信できないとき、その車両は、情報が不足しているので、少なくとも部分的に「ブラインド」である。そのため、車両は、その車両の環境を完全に把握していない。車両は、車両が1つまたは複数の他の車両からの情報の受信またはデコードに成功しなかったことを含む、1つまたは複数の理由により十分な情報を有していない場合がある。その結果として、車両は、やってくるフレームにおいて、どのチャネル上でブロードキャストするべきかについて知らない場合がある。車両は、いくつかの車両の位置またはいくつかの車両によるチャネルの要求を知らない場合もある。

ブラインド車両は、1次チャネルを有しているかもしれないが、2次チャネルとしての使用に利用可能な、ゾーンi＋1（または、ゾーンi＋2、i＋3などの、1つまたは複数の別のゾーン）内の1つまたは複数の空きチャネルがあるかどうかを判定するための十分な情報を有していない場合がある。車両回復とは、ブラインド車両に、1つまたは複数の他のゾーン内のチャネル使用についての情報を提供するプロセスをいう。例えば、ゾーンi内のブラインド車両は、ゾーンi＋1、i＋2、i＋3などのうちの1つまたは複数についてのチャネル使用情報を認識させられ得る。

一方、1次チャネルを有していない車両は、「新た」であると見なされるので、少なくともいくつかの実施形態では、1次チャネルを要求または割り当てられるために、ネットワークエントリ手順を踏む必要があり得る。

ブラインド車両回復は、いくつかの異なる状態において提供され得る。例えば、ブラインド車両回復は、非ハンドオーバのブラインド車両に対して提供され得る。非ハンドオーバの車両は、現在のフレームにおいて新たなゾーンに移動してしまっていない車両である。ブラインド車両回復を処理するための少なくとも1つの実施形態では、1つまたは複数の時間フレームは、ブロードキャストチャネルを含み得る。図10は、1つまたは複数のフレーム1000の第1のサブフレーム1002内にこうしたブロードキャストチャネル1004を有する一実施形態における、いくつかのフレーム1000を示している。ブロードキャストチャネル1004は、与えられたゾーン（例えば、ゾーンi＋1）内の1つまたは複数の空きチャネルを、近隣のゾーン（例えば、ゾーンi）内のブラインド車両などの車両に対して示す情報を含み得る。ブロードキャストチャネル1004は、図10に示すように、フレーム1000の始まりまたはその近くに、またはフレーム範囲内の他のいかなる位置にも位置し得る。

ブロードキャストチャネル1004は、特定の無線リソースを予め定義することによって構成され得、例えば、SCMAレイヤなどの予め定義されたSparse Code Multiple Access（SCMA）リソースを含むがこれには限定されない。

ゾーン（例えば、ゾーンi＋1）のブロードキャストチャネル1004上でのブロードキャストは、そのゾーン内の車両によって実行され得る。少なくとも1つの実施形態では、ゾーン内の車両は、ゾーンのチャネル1004上にブロードキャストするマスタ車両としての役割を果たし得る。車両は、任意の適切な方法でマスタ車両になり得る。例えば、一実施形態では、1つまたは複数の車両は、ゾーン内におけるそれらの車両の相対的位置に基づいて自律的にマスタ車両になり得る。例えば、少なくともいくつかの実施形態では、ゾーン端など、ゾーン内の基準位置に物理的に最も近い1つまたは複数の車両が、マスタの役割を担い得る。いくつかの実施形態では、例えば、ゾーンi＋1の左ゾーン端に最も近い、ゾーンi＋1内の車両が、ゾーンi内のブラインド車両に対して最も近い車両であることになるように、1つまたは複数の車両が、この方法でマスタとなり得る。ただし、1つまたは複数の車両がマスタ車両になり得る他の方法が想定される。

そのため、ゾーンi内の1つまたは複数のブラインド車両は、ゾーンi内のブラインドノードによって2次チャネルとして使用され得る、1つまたは複数の他のゾーン（例えば、ゾーンi＋1）の一切の空きチャネルを特定するために、1つまたは複数の他のゾーン（例えば、ゾーンi＋1）のブロードキャストチャネルをリッスンし得る。このように、ブラインド車両は、以前は欠けていた、他のゾーン内の空きチャネルについての情報（例えば、チャネル、位置など）を受信する。新たな情報は、次いで、車両が1つまたは複数の2次チャネルをおそらく要求することを可能にし得る。

また、少なくとも1つの実施形態では、ブロードキャストチャネル1004上でのブロードキャスト情報の結合送信が、複数のマスタ車両を有することによって可能にされ得る。結合送信は、ゾーン内のマスタ車両間の協調を使用して実施され得る。通常は、マスタ車両は非ブラインドノードである。

さらに、与えられた範囲内の異なるゾーンのブロードキャストチャネルは、無線リソース間の支障を低減するために異なる無線リソースを占有し得る。

別の例では、ブラインド車両回復は、1つまたは複数のハンドオーバのブラインド車両に対して提供され得る。ハンドオーバの車両は、その車両の出て行くゾーンから要求された1次チャネルを有し得るが、入ってくるゾーン内のすべての空きチャネルの情報を有していない場合がある。少なくとも2つの状態が可能であり得る。第1の状態では、車両は、その車両の入ってくるゾーンに属する空きチャネルから2次チャネルを決定することができない場合がある。そのため、ハンドオーバの際に、車両は、次のリソース要求サイクルにおいて、入ってくるゾーン内でその車両の1次チャネルになることができる2次チャネルを有していない。第2の状態では、車両が、入ってくるゾーン内の空きチャネルの完全な情報を有していないので、その車両が、入って来るゾーン内で新たな1次チャネルを決定できない場合がある。非ブラインドハンドオーバでは、車両は入ってくるゾーン内の空きチャネルの完全な情報を有し得ることから、これは、非ブラインドハンドオーバ状態とは異なり得る。これは、車両が、次のリソース要求サイクルにおいて新たな1次チャネルを要求することを可能にし得る。どちらの状態においても、車両は、次のリソース要求サイクルまでその車両の1次チャネルを保持し得るが、前述のように、1次チャネルのステータスは、その車両が、その車両の出て行くゾーンを離れるときに、一時的チャネルのステータスに変化し得る。

少なくとも1つの実施形態では、ハンドオーバのブラインド車両の回復は、ハンドオーバの際に、ネットワークへのその車両の迅速な再エントリを提供することによって可能にされ得る。迅速な再エントリは、ゾーンiからゾーンi＋1へのハンドオーバの際に、ブラインド車両に、その車両の1次（一時的な）チャネルをとおした送信で、その車両の「ブラインドであること」を示させることによって可能にされ得る。ゾーンi＋1の1つまたは複数のマスタ車両は、次いで、1つまたは複数のハンドオーバのブラインド車両に対して、ゾーンi＋1の1つまたは複数の空きチャネルを示し得る。このインディケーションは、ブロードキャストチャネルなど専用の時間―周波数リソースをとおすことを含んで、任意の方法で提供され得る。

別の実施形態では、ゾーンi＋1が空で、ゾーンi＋1に、ゾーンi＋1のブロードキャストチャネル上で情報を送信するマスタの役割を果たす車両がないことを意味するときに、ゾーンi内の1つまたは複数のブラインド車両のためにブラインド車両回復が提供され得る。結果的に、ゾーンi内のブラインド車両は、ゾーンi＋1のチャネルを単に使用し得るだけである。ブラインド車両は、2つ以上のブラインド車両が同じチャネル上で送信しようとしたときにリソースコリジョンを引き起こす可能性を低減または取り除くために、いくつかの予め存在する基準、例えば予め定義された規則、予め定義されたマッピングなどに基づいて、ゾーンi＋1の特定のチャネルを使用し得る。少なくとも1つの実施形態では、ブラインド車両は、特定のチャネルインデックスに基づいてチャネルを使用しようとし得る。別の実施形態では、ブラインド車両は、1つまたは複数の予め定義されたチャネルローテーションパターンに基づいてチャネルを使用しようとし得る。他のチャネル選択のオプションが使用されてもよい。

本開示の別の態様によれば、1つまたは複数の車両が車両アドホックネットワークに入ることを可能にするために、1つまたは複数のアプローチが提供される。車両は、いくつかの異なる状態において、例えば、その車両が他の車両の通信範囲内に到着したとき、その車両がその車両の通信サブシステムを有効にしたとき、などに、ネットワークに入り得る。ネットワークに入ろうとする車両は、新たな車両と称され得る。

少なくとも1つの実施形態では、マスタ車両など、1つまたは複数の他の車両は、新たな車両の位置、およびその新たな車両のための1つまたは複数のチャネルの特定のいずれかまたは両方を、ブロードキャストまたは別の方法でアナウンスするために使用され得る。他の車両が新しい車両の存在または位置を認識していない間、新たな車両は送信を開始できない場合があるので、これらの1つまたは複数の他の車両が、新たな車両についての情報をブロードキャストするために使用され得る。これにより、すでにネットワーク内にいる他の車両が、新たな車両についての情報、例えばその新たな車両の存在、位置、チャネルなどを知ることを可能にし得る。

新たな車両がネットワークにアクセスしようとしているとき、新たな車両は、例えばマシンIDまたは媒体アクセス制御アドレス（MACアドレス）の代わりに、その車両の地理的位置をユニークなネットワーク識別子として使用し得る。車両の位置を表すx−y座標などの地理的座標は、車両についてのユニークな識別子としての役割を果たし得る。一時的な識別子が使用される短い期間に、2つの車両が同一のx−y座標を有するであろう可能性は非常に低い。ただし、他のいかなるタイプの識別子も使用され得ることが理解されるべきである。

一例の実施形態を図11Aを参照しつつ記載しており、いくつかのフレーム1100 f、f＋1、f＋2を示しており、それぞれがサブフレーム1102を有しており、フレーム1100の少なくともいくつかは、前述のようにブロードキャストチャネル1104を有している。ネットワークに入ろうとしている、ゾーンi内の車両は、時間フレームfにおいて到着し、ブロードキャストチャネル1104をリッスンする。車両は、いくつかの目的のため、例えば、ネットワークエントリのための候補ゾーンを決定するため、ネットワークとタイミング同期を達成するため、または特定のブロードキャストチャネルと関連付けられたゾーンの1つまたは複数の空きチャネルを特定するために、ブロードキャストチャネルをとおして送信された情報を使用し得る。ノードが、複数の異なるブロードキャストチャネルをリッスンすることが可能であり、各チャネルは異なるゾーンに関連付けられている。

新しい車両は、後続のフレーム、例えばフレームf＋1の間に、ゾーンi内の他のいかなる車両の送信（例えば、ブロードキャスト、ビーコン送信など）もリッスンし得る。これにより、車両が、ゾーンiについての情報、例えばそのゾーン内の他の一切の車両の位置を決定することを可能にし得る。

新たな車両は、次いで、後続のフレーム、例えばフレームf＋2の間に、ネットワークに入ろうとし得る。車両は、ネットワーク・エントリ・リクエストをゾーンi内の1つまたは複数のマスタ車両へ送信し得る。エントリ・リクエストは、車両の位置および他のいかなる情報も含み得る。1つまたは複数のマスタ車両は、この情報を受信し得、次いで今度は、1つまたは複数の新たな車両の位置、および1つまたは複数の新たな車両のそれぞれについての1次チャネルの特定をブロードキャストし得る。

マスタ車両によってブロードキャストされた情報は、1つまたは複数の新たな車両、およびゾーンi内の他の車両によって受信され得る。新たな車両は、1つまたは複数のマスタ車両からのブロードキャストに基づいて、その新たな車両がネットワークへ入るのに成功したかどうかを判定し得る。例えば、新たな車両は、マスタ車両のブロードキャストがその車両のための1次チャネルの特定を示す場合に、エントリの試みが成功していることを判定し得る。一方、エントリの試みが成功でなかった場合、車両ネットワークに入ろうと再度試みる。少なくとも1つの実施形態では、リトライメカニズム、例えばランダムバックオフまたは任意の他の適切な方法が使用され得る。

新たな車両と1つまたは複数のマスタノードとに間の初期交換は、任意の適切な方法で実行され得る。例えば、特定の時間―周波数無線リソースが、この目的のために定義されるかまたは専用であり得る。少なくとも1つの実施形態では、初期交換は、ランダム・アクセス・チャネル（RACH）手順に類似した方法で実行され得る。したがって、いくつかの実施形態では、1つまたは複数のランダム・アクセス・チャネルが、この目的のために定義され得、1つまたは複数の時間スロットにおいて構成され得る。少なくとも1つの実施形態では、図11Aに示すように、1つまたは複数のスロット1106は、この目的のために、例えば、フレームfなど、時間ウィンドウの始まりまたはその近くにおいて構成される。他の実施形態では、初期アクセス送信は、初期交換専用のチャネルとは対照的に、1つまたは複数の他の共有チャネルをとおして実行され得る。ブロードキャストチャネルを有する実施形態では、ブロードキャストチャネルおよびネットワーク・エントリ・ランダム・アクセス・チャネルは、異なる時間スロット内に構成されるか、または他の異なる時間―周波数リソースを使用している場合がある。ただし、無線リソースは、任意の他の適切な方法で、初期交換のために定義または構成され得る。

図11Bは、ネットワークエントリ状態における、ゾーン内の新たな車両と他の車両との間の、少なくとも1つの実施形態における、いくつかの可能な送信を示すデータフロー図である。送信のいくつかは前述されている。

この例では、車両1152、1154および1156は、時間フレームfにおいて新たな車両1150が到着したとき、ゾーン内にいる。車両1152は、ゾーン内でマスタ車両の役割を果たしている。フレームfにおいて、新たな車両1150は、1つまたは複数のゾーンのブロードキャストチャネル（ブロードキャストCH）、ここではブロードキャスト1160をリッスンする。ブロードキャスト1160の性質に起因して、そのブロードキャストはすべてのノードへ送られるが、新たな車両1150に関して、以下の議論がプロセスに関わってくるであろう。新たな車両1150は、次いで、ゾーン内の他の車両の送信（例えば、ブロードキャストなど）をリッスンし得、フレームf＋1において、車両1156、1154および1152からそれぞれビーコン送信1162、1164、および1166を受信することになる。この図では、ビーコン送信は通常はブロードキャスト信号であるため、ビーコン送信はすべてのノードへ送られているように示している。ただし、ビーコンがブロードキャストされない実施形態では、フローは図示されているのとは異なることになる。当業者には、ビーコン送信の受信の順序が、図11Bに示されるものと異なることができることは明らかなはずである。

フレームf＋2において、新たな車両1150は、ネットワークへ入ろうとする。車両1150は、その車両の位置を含んだネットワーク・エントリ・メッセージ1168を、例えばランダム・アクセス・チャネル（RACH）、または初期交換のための他のチャネルをとおしてマスタ車両1152へ送信する。いくつかの実施形態では、ネットワーク・エントリ・メッセージ1168は、ノードの位置だけよりも多くの情報を含むことができる。ネットワークエントリが成功であった場合、マスタ車両1152は、応答送信1170の中で、新たな車両1150の位置、およびその新たな車両の新たなチャネルの特定を他の車両へブロードキャストすることにより応答することができる。送信1170は、ブロードキャストメッセージとして示されている。メッセージ1170をブロードキャストすることによって、車両1154および1156は、新たな車両1150およびその新たな車両が使用することになるチャネルについての情報を提供される。エントリの試みが成功でなかった場合、車両1150はネットワークに入ろうと再度試みることができる（図示せず）。

本開示の別の態様によれば、アドホックネットワーク内のリソースは、Sparse Code Multiple Access（SCMA）変調および波形に基づいて定義され得る。

少なくともいくつかの実施形態では、SCMAベースのリソース定義および他の特徴を使用することにより、例えば符号分割多重アクセス（CDMA）に基づくものを含む既存のアプローチを超える1つまたは複数の利益を提供し得る。1つの利益は、接続性の向上であり得、SCMAリソース定義（例えば、SCMAレイヤなど）の結果として、より多くのチャネルが定義され得、使用可能にされ得ることを意味する。SCMAを用いて、車両または他のノードは、キャリア検知とは対照的にコードブック／パイロット検知を実行するので、別の利益は、通信に関する信頼性の向上およびより低い遅延のいずれかまたは両方であり得る。別の利益は、SCMAが、競合ベースの多重アクセスを可能にするためにブラインド検出をサポートしていることであり得る。このことは、ネットワークエントリにおいて、アクティブなチャネルおよびそれらのチャネルのデータを特定するのに役立ち得る。それは、回復プロセスにおいてブラインドノードがアクティブなチャネルを特定するのにも役立ち得る。それは、システム内でランダムアクセスを実行するブラインドノードまたは新たなノードに起因するチャネルコリジョンに対するロバスト性をさらに向上させ得る。

Sparse Code Multiple Access （SCMA）は、バイナリ・データ・ストリームを多次元のコードワードに直接符号化する符号化技術である。バイナリデータを多次元のコードワードに直接符号化することにより、SCMA符号化は、直交振幅変調（QAM）シンボルマッピングを回避し、従来のCDMAを超える符号化利得を提供することができる。SCMAは、QAMシンボルではなくて多次元のコードワードを使用してバイナリデータを搬送し得る。また、SCMAは、多重化されたレイヤの異なるコードブックを異なるユーザに割り当てることをとおして多重アクセスを提供し得る。さらに、SCMAコードブックは、レシーバが、多重化されたコードワードの中からそれらのレシーバそれぞれのコードワードを検出するために低複雑度のメッセージ受渡しアルゴリズム（MPA）を使用し得るように、わずかなコードワードを含み得る。これにより、レシーバ側でのベースバンド処理の複雑度を低減することができる。

SCMAベースのリソース定義を使用している一例の実施形態を図12に示す。いくつかのサブフレーム1202を有する、一例のフレーム1200を示しており、各サブフレームはいくつかのスロット1204を有し得る。スロットは、1つまたは複数のSCMAレイヤ1206に細分され得る。図12では、スロットがJ個のレイヤを有することを示している。再度、SCMAでは、多重化された異なるレイヤを異なるユーザに割り当てることをとおして多重アクセスを提供し得る。

少なくとも1つの実施形態では、チャネルは、1つのスロットと1つのレイヤの少なくとも1つの組合せとして定義され得る。例えば、図12では、1つのチャネルは、スロット2、レイヤ3として定義され得る。別のチャネルは、スロット2、レイヤ4として定義され得る、などである。結果的に、m個のスロット1204を有するサブフレーム1202、およびJ個のレイヤ1206を有するスロット1204は、m×J個の異なるチャネルを定義し得る。

さらに、2つ以上の車両が、同じSCMAレイヤおよびスロット、例えばスロット2、レイヤ6を使用するチャネルを要求し得ることが可能であり得る。少なくともいくつかの実施形態では、これらの車両は、リソースコリジョンを回避するために、例えば分散環境において異なるパイロット1208を使用することができ得る。これにより、たとえSCMAコードブックのコリジョンが発生した場合にでも、パイロットコリジョンの可能性を低減し得る。特に、SCMAシステムは、パイロットコリジョンが回避される限り、コードブックのコリジョンに対してロバスト性がある。つまり、コードブック再利用は、SCMA実施において許容可能であり得る。

前述したものなどのSCMAのリソース定義は、全二重モードで動作することができる車両でのみ機能し得る。例えば、同じ時間スロットの間に送信する2つの車両は、SCMAレイヤにおいて分けられ得るが、両方の車両が全二重モードで動作しない限り、この時間スロットの間、その2つの車両は互いにリッスンすることができないかもしれない。

本開示の別の態様によれば、アドホックネットワーク内の車両のための仮想全二重モードを実現するために、1つまたは複数のアプローチが、図13を参照しつつ以下に提供される。

いくつかの車両アドホックネットワークでは、少なくともいくつかの車両は半二重であり、それらの車両は送信およびリッスンを同時に行うことができないことを意味する。結果的に、2つ以上の車両がそれぞれ、おそらくは異なるレイヤではあるものの、同じスロット内でチャネルを要求するとき、これらの車両は同時に送信するので、お互いをリッスンすることができない場合がある。

少なくともいくつかの実施形態では、半二重の車両は、単一のサブフレームの間、送信および他の車両のリッスンの両方を行うことができ得る。半二重のノードが、サブフレーム内の2つの異なるスロットにおいて送信することを確実にすることによって、チャネルインデックスと、サブフレームのどのスロットでノードが送信することになるのかとの間のマッピングを生成することが可能である。十分な数の時間スロットおよびインデックス・ツー・スロットのマッピングの多様性を確実にすることによって、送信する能力を各ノードに提供し、同時に、そのノードに対して、そのノードがリッスンしているときに、他のすべてのノードが、送信する機会を少なくとも1回提供されることを保証することができる。この点で、車両は、サブフレーム全体にわたって仮想全二重ノードとして動作するものと見なされる。

ここで、図13を参照すると、仮想全二重モードを可能にする一例の実施形態において、1つまたは複数のゾーンについてチャネルがどのように定義され得るかを示している。この特定のチャネル定義は、Sparse Code Multiple Access （SCMA）符号化に基づく。ただし、これは限定を意味するものではない。他の符号化スキームまたはリソース定義が使用されてもよい。

図13の例では、サブフレーム1300は、7個の時間スロット1302（例えば、スロット1〜7）を有しており、各スロットは6個のSCMAレイヤを有し得る。チャネルは、2つのスロット／レイヤリソースを含むものとして定義され得る。これは、図12を参照して記載している例に類似している。

本例では、チャネルは、2つの異なるスロットが割り当てられる。ただし、他の仮想全二重の実施形態では、チャネルは、より多くのスロットを有し得る。車両は、2つのスロットの両方において送信し、両スロット内のペイロードは本質的に同じであり得る。同じペイロードを異なるスロットで送信することによって、他の車両がリッスンする複数の機会を提供し得る。7個のスロットがあり、各チャネルは2つの異なるスロットを割り当てられるので、

個の異なる組合せがある。したがって、この例では、21個までのチャネルがサポートされる。チャネルインデックス1304（例えば、1から21）は、図13の一番左の列に示されている。スロットインデックス1から7は、中央の7つの列に示されている。レイヤインデックス1306は、一番右の列に示されており、チャネルの2つのスロットのそれぞれと関連付けられたレイヤを示している。例えば、チャネル1は、スロット1および2を含んでおり、レイヤインデックス1，1を有している。これは、チャネル1のリソースがスロット1，レイヤ1、およびスロット2，レイヤ1を含んでいることを示す。つまり、レイヤインデックス1，1は、与えられたチャネルの1番目および2番目のスロットのレイヤを示す。別の例を提供すると、チャネル8は、スロットインデックス2，4およびレイヤインデックス3，2を有している。したがって、チャネル8のリソースは、スロット2，レイヤ3、およびスロット4，レイヤ2である。

仮想全二重モードを、図13を参照しつつ別の例を使用して記載する。この例では、チャネル1から6が、ゾーン内の6つの異なる車両によって使用される。図13に示すように、これらの車両のすべては、スロット1の間に送信し得る。そのため、これらの車両のうちで、スロット1の間、お互いをリッスンすることができ得る車両はない。ただし、各チャネル1から6のそれぞれの中の2番目のスロットは、異なる時間スロット（スロット2から7）において現れる。そのため、6つの車両のうちの1つだけが、スロット2から7のそれぞれにおいて送信する。したがって、他の5つの車両は、スロット2から7のそれぞれにおいて、送信している車両をリッスンすることができる。そのため、6つの車両すべてが、1つのサブフレーム範囲内でお互いに送信およびリッスンの両方を行うことができる。図13の例の21チャネルすべてについて同じことがいえる。

与えられたスロット内で定義された異なるSCMAレイヤの結果として、1つまたは複数のリッスンしている車両は、同じスロット内の異なるチャネルをとおして送信を受信することができ得る。例えば、チャネル7を要求してしまっている車両は、2つの異なる車両がチャネル1およびチャネル2のスロット1において送信しているかもしれないときに、スロット1でリッスン（すなわち、送信ではない）している。スロット1におけるチャネル1上の送信はレイヤ1を使用し、スロット1におけるチャネル2上の送信はスロット2を使用する。そのため、リッスンしている車両は、異なるSCMAレイヤを使用して、スロット1上のこれらの送信の両方を受信および処理することができ得る。

図13で示す実施形態で使用されているスロット、レイヤおよびチャネル定義の数は、例としてのみ提供されており、限定を意味するものではない。1つまたは複数の他の実施形態では、異なる構成が使用され得る。例えば、チャネルは、3つ以上のスロットを含むように定義され得る。他の構成およびオプションが可能である。

前述のように、いくつかの実施形態では、単一の車両が、与えられたゾーンの1つを超えるチャネルを要求および使用し得る。このことは、前述の仮想全二重モードのいくつかの実施形態を含め、いくつかの問題につながり得る。可能性のある1つの問題を図14を参照しつつ記載しており、それは図13の例で提供されたリソース定義例に基づいている。

図14の例では、第1の車両は、チャネル1、2および12を要求する。そのため、第1の車両は、スロット1、2、3、および4上で送信し得るので、これらのスロットのいずれにおいてもリッスンすることができない場合がある。チャネル3、7、および8も示されており、スロット1から4内で割り当てられたスロットだけを有している。そのため、ゾーン内の第2の車両が、チャネル3、7、および8のうちの、1つまたは複数だけを要求した場合、破線1400で示されるように、スロット1から4のすべての間に第1の車両が送信しているとき、第1の車両は第2の車両を決してリッスンできない場合がある。例えば、第2の車両がチャネル3を要求してしまっている場合、第2の車両はスロット1およびスロット4上で送信する。ただし、チャネル1、2および12を要求してしまっている第1の車両は、スロット1から4のすべての上で送信している場合があるので、第1の車両は、第2の車両を聴取することができな場合がある。

本開示は、このタイプの問題に対する1つまたは複数のソリューションを提供しており、前述されている。こうしたソリューションの1つは、1つまたは複数の他のゾーン内の空きチャネルの中から1つまたは複数のチャネル（例えば、2次チャネルなど）を要求する、特定のゾーンにいる車両に関与する。少なくともいくつかの実施形態では、異なるゾーンのチャネルは、異なるサブフレーム内のスロットまたは他の時間―周波数リソースで構成され得、それによって、図14に関連して記載された、問題を含む状態の可能性を取り除く。

本開示は、分散型の方法による通信リソースの共有および管理を提供するために、アドホックネットワークの車両において実施され得るチャネル共有アルゴリズムに言及している。チャネル共有アルゴリズムは、各車両が、他の車両によって要求されたリソースを認識できるようにし得るだけでなく、リソースコリジョンのリスクが少ないかまたはない状態でその車両がリソースをいつ要求および使用し得るかを決定し得る。また、チャネル共有アルゴリズムは、車両が、2次チャネルを要求すること、新たな車両のネットワークエントリ、および車両ハンドオーバを含んで、本発明に係る1つまたは複数の他のプロセスを実行することを可能にし得る。

前述の実施形態は、ゾーンをグリッド上で互いに隣接しているものとして参照しているが、これは単なる一実施形態であることを、当業者は理解するだろう。別の実施形態では、ゾーンは開始点を有するが、終了点を有しない。これにより、ゾーンの重複という結果になる。予め定義された方向に走行する各車両は、その車両の1次チャネルとして、その車両がゾーンのスタートに最も近いゾーン内の利用可能なチャネルを要求しようとすることになる。2次チャネルとして、車両は、次に近い開始点を有するゾーン内のチャネルを要求しようとすることになる。予め定義された方向と反対方向に走行する車両は（それらの車両が同じゾーンを共有する場合）、次の開始点の後のゾーン内で1次チャネルを要求することになる。図5Aを参照すると、ゾーンiは、端536でスタートするが、終了しない。ゾーンi＋1は図示されている次の境界でスタートするが、終了しない。その結果、ゾーンi内のすべての車両は、ゾーンi＋1内にもいる。

こうした一実施形態では、チャネルを要求する方法は変わらない。車両が、2次チャネルを要求したいと決定した場合、その車両は単に次のゾーンからチャネルを要求することによってそうすることができる。

車両は、その車両がゾーン内で責任を負っておらず、異なるゾーンへまさに入ろうとしていると判定すると、その車両がまさに入ろうとしているゾーン内のチャネルを要求することだけを選択し得ることが、さらに理解されるべきである。このことは、ゾーンの開始点の動的な変化として見ることもでき、車両が元のゾーン境界を通過したときに元に戻ることになる。

重複しているゾーン（スタートによって指定されているが終了によっては指定されていないゾーンがある場合、軽負荷の道路上の車両はすべて、それらの車両が今後さらに情報を交換できるように、最も大きな番号が付けられたゾーン内のチャネルを要求することが可能である。車両の通信到達距離は、より大きなサイズのゾーンが動的に生成されるとき、道路上の次の車両に中継としての役割を果たさせることによって、拡張することができる。

いくつかの図によって、単一レーンの交通に対するゾーンの適用を示してきたが、実施において、ゾーンは、1レーンを超える交通を含むように実施されることができ、また、1つを超える方向の交通も含む ことができるということも、当業者によって理解されるだろう。同様に、複数レーンの道路は、道路に重ね合わせるようにグリッドを生成して、各レーン内に一連の連続するゾーンを有し得る。異なる方向の交通は、ゾーンについて異なる開始点および終了点を有することができ、その結果、ゾーン内のチャネルは、各走行方向について、ゾーンを離れるのに最も近い車両に基づいて割り当てられる。複数レーンの道路が、異なるレーンをカバーするゾーンのグリッドを有している場合、ゾーンにそれらのゾーンの開始および終了点を整列させる必要はないことが理解されるべきである。

第1の実施例は、車車間アドホックネットワークにおける方法であって、
仮想グリッドの第1のゾーン内の新たなノードにおいて、前記第1のゾーンの通信チャネルの可用性を示す情報を受信するステップであって、前記新たなノードは、要求済のチャネルを有していない、ステップと、
前記新たなノードにおいて、前記新たなノードための1次チャネルのリクエストを示すネットワーク・エントリ・リクエストを送信するステップと
を含む方法である。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記送信するステップは、前記ネットワーク・エントリ・リクエストを、前記第1のゾーンと関連付けられたマスタノードへ送信するステップを含む。

更なる任意の実施例は、先の実施例のいずれかにおいて、可用性を示す前記情報は、前記第1のゾーン内の第2のノードからのビーコン送信と、前記第1のゾーンのブロードキャストチャネルのうちの少なくとも1つをとおして前記新たなノードにおいて受信される。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記方法は、前記ネットワーク・エントリ・リクエストに応答して、前記新たなノードによる要求のための1次チャネルのインディケーションを前記新たなノードにおいて受信するステップをさらに含む。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記ネットワーク・エントリ・リクエストは、前記新たなノードの位置を示す情報を含む。

第2の実施例は、車車間アドホックネットワーク内で動作するためのノードであって、
プロセッサと、
通信サブシステムと、
前記プロセッサによって実行されたときに、第1のノードに
前記通信サブシステムをとおして受信した情報から、仮想グリッドの第1のゾーンの通信チャネルの可用性のインディケーションをデコードさせ、前記ノードは前記第1のゾーン内にあり、要求済のチャネルを有しておらず、
前記ノードにおいて、前記新たなノードのための1次チャネルのリクエストを示すネットワーク・エントリ・リクエストを示すメッセージを送信させる、命令を記憶する、コンピュータ可読の記憶媒体と
を備えるノードである。

第3の実施例は、車車間アドホックネットワークにおける方法であって、
前記アドホックネットワーク内の仮想グリッドの第1のゾーン内に位置している第1のノードにおいて、第2のゾーンの第1の通信チャネルの可用性を示す情報を受信するステップと、
前記第1のノードにおいて、前記第1のチャネルを前記第1のノードの2次チャネルとして要求するステップと
を含む方法である。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記受信するステップの前に、前記第1のノードは、前記第1のノードが前記第1のチャネルを2次チャネルとして要求することができないような、前記第1のチャネルの前記可用性について不十分な情報を有している。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記受信された情報の少なくとも一部は、ブロードキャストチャネルをとおして、前記第1のゾーン以外のゾーン内に位置している第2のノードから受信される。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記要求するステップは、第2のノードの位置に対する前記第1のノードの位置に基づく。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記第1および第2のノードの前記相対的位置は、基準位置に対する前記第1および第2のノードそれぞれの距離に基づいて決定される。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記基準位置は、前記仮想グリッド内のゾーンの端を含む。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記要求するステップは、後続の時刻における前記2次チャネル上での前記第1のノードによる送信のために、第1の時刻に発生する。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記第1のチャネルは、Sparse Code Multiple Access（SCMA）レイヤを含む。

第4の実施例は、車車間アドホックネットワーク内で動作するための第1のノードであって、前記第1のノードは、
プロセッサと、
通信サブシステムと、
前記プロセッサによって実行されたときに、前記第1のノードに、
前記第1のノードが前記ネットワーク内の仮想グリッドの第1のゾーン内に位置しているときに前記第1のノードにおいて、前記通信サブシステムをとおして受信した情報から、第2のゾーンの第1の通信チャネルの可用性のインディケーションをデコードさせ、
前記第1のチャネルを前記第1のノードの2次チャネルとして要求すること示すメッセージを送信させる、命令を記憶する、コンピュータ可読の記憶媒体と
を備える第1のノードである。

第5の実施例は、車車間アドホックネットワークにおける方法であって、
前記ネットワークの仮想グリッド内の第2のゾーン内の第1のノードにおいて、ブラインドネスインディケーションを送信するステップであって、前記第1のノードは、第1のゾーンから前記第2のゾーンに入ってしまっており、前記ブラインドネスインディケーションは、前記第1のノードが前記第2のゾーンの通信チャネルの可用性について不完全な情報を有していることを示す、ステップ
を含む方法である。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記方法は、前記第1のノードにおいて、前記送信するステップに応答して、前記第2のゾーンの1つまたは複数の利用可能なチャネルを示す情報を受信するステップをさらに含む。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記方法は、前記第1のノードにおいて、前記第2のゾーンの前記1つまたは複数の利用可能なチャネルのうちの少なくとも1つを前記第1のノードの1次チャネルとして要求するステップをさらに含む。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記要求するステップは、第2のノードの位置に対する前記第1のノードの位置に基づく。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記第1および第2のノードの前記相対的位置は、基準位置に対する前記第1および第2のノードそれぞれの距離に基づいて決定される。

第6の実施例は、車車間アドホックネットワーク内で動作するための第1のノードであって、
プロセッサと、
通信サブシステムと、
前記プロセッサによって実行されたときに、前記第1のノードに、
前記ネットワークの仮想グリッド内の第2のゾーン内の前記第1のノードにおいて、ブラインドネスインディケーションを送信させ、前記第1のノードは、第1のゾーンから前記第2のゾーンに入ってしまっており、前記ブラインドネスインディケーションは、前記第1のノードが前記第2のゾーンの通信チャネルの可用性について不完全な情報を有していることを示す、命令を記憶する、コンピュータ可読の記憶媒体と
を備える第1のノードである。

第7の実施例は、車車間アドホックネットワークにおける方法であって、
前記アドホックネットワーク内の仮想グリッドの第1のゾーン内に位置しているノードにおいて、前記第1のゾーンの通信チャネルの可用性を示す情報をブロードキャストするステップ
を含む方法である。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記ノードは、前記ブロードキャストするステップを実行する責任を負う、前記第1のゾーンのマスタノードである。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記ブロードキャストするステップは、専用のブロードキャストチャネルにおいて発生する。

第8の実施例は、車車間アドホックネットワーク内で動作するためのノードであって、
プロセッサと、
通信サブシステムと、
前記プロセッサによって実行されたときに、前記ノードに、
前記ノードが前記アドホックネットワーク内の仮想グリッドの第1のゾーン内に位置しているときに前記ノードにおいて、前記第1のゾーンの通信チャネルの可用性を示す情報を送信させる、命令を記憶する、コンピュータ可読の記憶媒体と
を備えるノードである。

第9の実施例は、車車間アドホックネットワークにおける方法であって、
前記ネットワーク内の第1のノードにおいて、前記第1のノードが仮想グリッド内において第1のゾーンから第2のゾーンへ移動してしまっていると判定するステップと、
前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっている場合には、前記チャネルのステータスを前記第1のノードの2次チャネルから1次チャネルへ変更するステップと、
前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっていない場合には、前記第1のノードにおいて、前記第2のゾーンの利用可能なチャネルを前記第1のノードの1次チャネルとして要求するステップと
を含む方法である。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記第1のノードが前記第2のゾーンへ移動するときに前記第1のノードが前記第1のゾーンのチャネルを1次チャネルとして要求してしまっている場合には、前記第1のノードにおいて、前記第1のゾーンのこのチャネルを開放するステップを含む。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記第2のゾーンの前記チャネルを1次チャネルとして前記要求するステップは、第2のノードの位置に対する前記第1のノードの位置に基づく。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記第1および第2のノードの前記相対的位置は、基準位置に対する前記第1および第2のノードそれぞれの距離に基づいて決定される。

更なる任意の実施例は、先の実施例のいずれかにおいて、前記第1のノードために前記1次チャネルを前記要求するステップは、後続の時刻における前記第1のノードによる送信のために、第1の時刻に発生する。

第10の実施例は、車車間アドホックネットワーク内で動作するための第1のノードであって、
プロセッサと、
通信サブシステムと、
前記プロセッサによって実行されたときに、前記第1のノードに、
前記第1のノードが、仮想グリッドにおいて第1のゾーンから第2のゾーンへ移動してしまっていると判定させ、
前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっている場合には、前記チャネルのステータスを前記第1のノードの2次チャネルから1次チャネルへ変更させ、
前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっていない場合には、前記第1のノードにおいて、前記第2のゾーンの利用可能なチャネルを前記第1のノードの1次チャネルとして要求させる、命令を記憶する、コンピュータ可読の記憶媒体と
を備える第1のノードである。

後続の実施形態の記述をとおして、本開示の教示は、ハードウェアだけを使用して、またはソフトウェアとハードウェアの組合せを使用して実施され得る。1つまたは複数の実施形態を実施するソフトウェアまたは他のコンピュータ実行可能命令、またはそれらの1つまたは複数の部分は、任意の適切なコンピュータ可読の記憶媒体に記憶され得る。コンピュータ可読の記憶媒体は、例えば、光学（例えば、CD、DVD、ブルーレイなど）、磁気、ハードディスク、揮発性もしくは不揮発性、ソリッドステート、または当該技術分野で知られている他の一切のタイプの記憶媒体などの、有形の、または一時的／非一時的な媒体であり得る。

さらに、実施形態は、車両通信との関連で記載されているが、本開示の範囲は、車両または車両通信に限定されることを意図するものではない。本開示の教示は、他のアプリケーションおよび他の分野において使用または適用され得る。そのため、車両および車両通信に関連する本明細書の教示は、他のタイプのノード、モバイルノード、ユーザ装置（UE）、送信ポイント、ネットワークエレメント、センサ、マシン、ならびに他のタイプのデバイス、ならびに他のタイプの通信およびネットワークに対して、一般に適用される。本教示は、車両アドホックネットワーク以外のネットワーク、例えば他のモバイルノードアドホックネットワークに適用されることも意図している。

本開示のさらなる特徴および利点が、当業者に理解されるだろう。

本明細書に記載の、および図示されている、特定の実施形態の構造、特徴、付属物、および代替は、互換性がある限り、本明細書に記載および図示されている実施形態のすべてに対することを含んで、本開示の教示のすべてに対して一般に適用されることを意図されている。つまり、ある特定の実施形態の構造、特徴、付属物、および代替は、そのように示されない限り、その特定の実施形態だけに限定されることを意図されていない。

さらには、前述の詳細な記述は、いかなる当業者も、本開示に係る1つまたは複数の実施形態を作成または使用することを可能にするために提供されている。これらの実施形態に対するさまざまな変形は、当業者には容易に明白になり、本明細書で定義された包括的な原理は、本明細書に提供された教示の趣旨または範囲から逸脱することなく、他の実施形態に適用され得る。したがって、本方法、システム、およびまたはデバイスは、本明細書に開示された実施形態に限定されることを意図していない。特許請求の範囲は、これらの実施形態によって限定されるべきではなく、全体として、記載に一致する最も広い解釈が与えられるべきである。冠詞「a」または「an」の使用によってなど、単数によるエレメントへの言及は、特にそのように述べられていない限り、「1つおよび1つだけ」を意味することを意図するものではなく、むしろ「1つまたは複数」を意味することを意図している。当業者に知られているかまたは後に知られることになる、開示全体にわたって記載されたさまざまな実施形態のエレメントのすべての構造的および機能的な同等物は、特許請求の範囲のエレメントによって包含されることを意図している。

さらに、本明細書に、先行技術または共通の一般知識の容認を意図するものはない。また、本願におけるいかなる文書の引用または特定も、こうした文書が先行技術として利用可能であること、または何らかの参照が、当技術分野における共通の一般知識の一部を形成することを容認するものではない。さらに、本明細書に開示されたものは、そのような開示が特許請求の範囲において明示的に記載されているかどうかにかかわらず、公共にささげるようには意図されていない。

10 車両
11 車両
12 車両
13 車両
14 車両
15 車両
20 車両
21 車両
22 車両
23 車両
30 円形線
32 円形線
34 関連エリア
200 処理システム
202 中央処理装置（CPU）
204 メモリ
206 大容量記憶装置
208 ビデオアダプタ
210 I／Oインタフェース
212 通信サブシステム
214 バス
216 ディスプレイ
218 オンスクリーンキーボード／会話インタフェース
220 トランスミッタ
222 レシーバ
224 アンテナエレメント
226 GPS無線またはレシーバ
300 道路
302 仮想グリッド
303 車両
304 ゾーン
306 ゾーンの長さ
308 認識エリア
310 車両
312 ゾーン
314 ガード領域
350 フレーム
352 時間スロット
400 道路
402 仮想グリッド
404 ゾーン
406 ゾーン長
450 フレーム
452 時間スロット
454 サブフレーム
500 道路
502 仮想グリッド
504 ゾーン
520 車両
530 第1のゾーン側端
532 第2のゾーン側端
534 第1のゾーン末端
536 第2のゾーン末端
550 送信フレーム
552 スロット
554 サブフレーム
650 フレーム幅、送信期間、間隔
652 短い矢印
660 リソース要求間隔
662 長い矢印
680 1つまたは複数の間隔
682 リソース要求時刻
700 1次チャネル
702 1次チャネル
704 1次チャネル
706 1次チャネル
708 1次チャネル
710 2次チャネル
712 2次チャネル
714 1次チャネル
716 1次チャネル
718 2次チャネル
720 2次チャネル
750 右ゾーン端
1000 フレーム
1002 サブフレーム
1004 ブロードキャストチャネル
1100 フレーム
1102 サブフレーム
1104 ブロードキャストチャネル
1106 スロット
1150 車両
1152 車両
1154 車両
1156 車両
1160 ブロードキャスト
1162 ビーコン送信
1164 ビーコン送信
1166 ビーコン送信
1168 ネットワーク・エントリ・メッセージ
1170 応答送信
1200 フレーム
1202 サブフレーム
1204 スロット
1206 SCMAレイヤ
1208 パイロット
1300 サブフレーム
1302 時間スロット
1304 チャネルインデックス
1306 レイヤインデックス
1400 破線

Claims (59)

1. 車車間アドホックネットワークにおける方法であって、
   ネットワーク内の第1のノードにおいて、前記ネットワーク内の第2のノードの位置を示す情報を受信するステップと、
   前記第1のノードにおいて、前記第2のノードの前記位置に対する前記第1のノードの位置に基づいて、前記ネットワーク内の第1の通信チャネルを要求するステップと
   を含む方法。
2. 前記第1のノードによって要求された前記第1のチャネルは、Sparse Code Multiple Access（SCMA）レイヤを含む、請求項1に記載の方法。
3. 前記第1のノードは、仮想グリッド内の第1のゾーン内に位置し、前記要求された第1のチャネルは、前記第1のゾーン用に構成され、
   前記第1のゾーンの複数のチャネルはそれぞれ、単一のサブフレームの間、前記第1のゾーンのチャネルを要求してしまっているノードが、前記第1のゾーンのチャネルを要求してしまっている他のすべてのノードの送信をリッスンすることができ、かつ、前記第1のゾーンのチャネルを要求してしまっている他のすべてのノードに前記第1のノードの送信をリッスンさせることができるように、サブフレーム内の少なくとも2つの異なる時間スロットのそれぞれにわたって定義されたSCMAレイヤを含み、前記少なくとも2つの異なる時間スロットの間に同じペイロードが送信され、各チャネルの、少なくとも2つの時間スロットとそれらの2つの時間スロットそれぞれのSCMAレイヤとの組合せが、前記第1のゾーン内でユニークな、請求項2に記載の方法。
4. 前記第1のノードは、仮想グリッド内の第1のゾーン内に位置し、前記要求された第1のチャネルは、前記第1のゾーンに属し、前記要求された第1のチャネルは、前記第1のノードの1次チャネルとしての役割を果たし、前記方法は、2次チャネルとして第2のチャネルを要求するステップであって、前記第2のチャネルは、前記第1のゾーン以外の、前記仮想グリッド内の第2のゾーンの利用可能なチャネルである、ステップををさらに含む、請求項1に記載の方法。
5. 前記第2のゾーンは、前記第1のゾーンと隣接している、請求項4に記載の方法。
6. 前記第2のゾーンは、前記第1のゾーンに重なる、請求項4に記載の方法。
7. 前記第1および第2のノードの前記相対的位置は、基準位置に対する前記第1および第2のノードそれぞれの距離に基づいて決定される、請求項1に記載の方法。
8. 前記基準位置は、前記第1のゾーンの端を含む、請求項7に記載の方法。
9. 前記第1のノードにおいて、前記第2のノードによる要求に利用可能な、前記ネットワーク内のチャネルを特定するステップであって、前記特定するステップは、前記第2のノードの前記位置に対する前記第1のノードの前記位置に基づく、ステップをさらに含む、請求項1に記載の方法。
10. 前記第1のノードにおいて、前記ネットワーク内の第3のノードの位置を示す情報を受信するステップをさらに含み、
    前記第1のノードにおいて前記第1のチャネルを要求するステップは、前記第2および第3のノードの前記位置に対する前記第1のノードの前記位置に基づく、
    請求項1に記載の方法。
11. 前記情報を受信するステップは、第1の時刻に発生し、前記第1のノードにおいて要求された前記第1のチャネルは、前記第1の時刻に続いて、第2の時刻に前記第1のノードによる送信のために使用される、請求項1に記載の方法。
12. 前記第1のノードにおいて、前記第1のノードの前記位置を示す情報をブロードキャストするステップをさらに含む、請求項1に記載の方法。
13. 前記第1のノードは、前記ネットワークの仮想グリッド内の第2のゾーンにあり、前記第1のノードは、第1のゾーンから前記第2のゾーンに入ってしまっており、前記方法は、前記要求するステップの前に、
    前記第1のノードにおいて、前記第1のノードが前記第2のゾーンの通信チャネルの可用性について不完全な情報を有していることを示す、ブラインドネスインディケーションを送信するステップをさらに含む、請求項1に記載の方法。
14. 前記要求するステップの後に、
    前記第1のノードにおいて、前記第1のノードが仮想グリッドにおいて第1のゾーンから第2のゾーンへ移動してしまっていると判定するステップと、
    前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっている場合には、前記チャネルのステータスを前記第1のノードの2次チャネルから1次チャネルへ変更するステップと、
    前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっていない場合には、前記第1のノードにおいて、前記第2のゾーンの利用可能なチャネルを前記第1のノードの1次チャネルとして要求するステップと
    をさらに含む、請求項1に記載の方法。
15. 車車間アドホックネットワーク内で動作するための第1のノードであって、前記第1のノードは、
    プロセッサと、
    通信サブシステムと、
    前記プロセッサによって実行されたときに、前記第1のノードに、
    前記通信サブシステムをとおして受信した情報から、前記ネットワーク内の第2のノードの位置をデコードさせ、
    前記第1のノードのために前記ネットワーク内の第1の通信チャネルを要求するステップを示すメッセージを送信させ、前記第1の通信チャネルは、前記第2のノードの前記位置に対する前記第1のノードの位置に基づいて選択される、命令を記憶する、コンピュータ可読の記憶媒体と
    を備える第1のノード。
16. 前記第1のノードによって要求された前記第1のチャネルは、Sparse Code Multiple Access（SCMA）レイヤを含む、請求項15に記載の第1のノード。
17. 前記第1のノードは、仮想グリッド内の第1のゾーン内に位置し、前記要求された第1のチャネルは、前記第1のゾーン用に構成され、
    前記第1のゾーンの複数のチャネルはそれぞれ、単一のサブフレームの間、前記第1のゾーンのチャネルを要求してしまっているノードが、前記第1のゾーンのチャネルを要求してしまっている他のすべてのノードの送信をリッスンすることができ、かつ、前記第1のゾーンのチャネルを要求してしまっている他のすべてのノードに前記第1のノードの送信をリッスンさせることができるように、サブフレーム内の少なくとも2つの異なる時間スロットのそれぞれにわたって定義されたSCMAレイヤを含み、前記少なくとも2つの異なる時間スロットの間に同じペイロードが送信され、各チャネルの、少なくとも2つの時間スロットとそれらの2つの時間スロットそれぞれのSCMAレイヤとの組合せが、前記第1のゾーン内でユニークな、請求項16に記載の第1のノード。
18. 前記第1のノードは、仮想グリッド内の第1のゾーン内に位置し、前記要求された第1のチャネルは、前記第1のゾーンに属し、前記要求された第1のチャネルは、前記第1のノードの1次チャネルとしての役割を果たし、前記命令は、さらに、前記第1のノードに、第2のチャネルを2次チャネルとして前記要求することを前記メッセージまたは送信される別のメッセージ中に示させ、前記第2のチャネルは、前記第1のゾーン以外の、前記仮想グリッド内の第2のゾーンの利用可能なチャネルである、請求項15に記載の第1のノード。
19. 前記第2のゾーンは、前記第1のゾーンと隣接している、請求項18に記載の第1のノード。
20. 前記第2のゾーンは、前記第1のゾーンに重なる、請求項18に記載の第1のノード。
21. 前記第1および第2のノードの前記相対的位置は、基準位置に対する前記第1および第2のノードそれぞれの距離に基づいて判定される、請求項15に記載の第1のノード。
22. 前記基準位置は、前記第1のゾーンの端を含む、請求項21に記載の第1のノード。
23. 前記プログラムすることは、前記第1のノードにおいて、前記第2のノードによる要求に利用可能な、前記ネットワーク内のチャネルを特定する命令をさらに含み、前記特定することは、前記第2のノードの前記位置に対する前記第1のノードの前記位置に基づく、請求項15に記載の第1のノード。
24. 前記プログラムすることは、前記第1のノードに、
    前記通信サブシステムをとおして受信した情報から前記ネットワーク内の第3のノードの位置をデコードさる命令をさらに含み、
    前記第1のノードにおいて前記第1のチャネルを要求することは、前記第2および第3のノードの前記位置に対する前記第1のノードの前記位置に基づく
    請求項15に記載の第1のノード。
25. 前記情報を受信することは、第1の時刻に発生し、前記第1のノードにおいて要求された前記第1のチャネルは、前記第1の時刻に続いて、第2の時刻に前記第1のノードによる送信のために使用される、請求項15に記載の第1のノード。
26. 前記プログラムすることは、前記第1のノードにおいて、前記第1のノードの前記位置を示す情報をブロードキャストする命令をさらに含む、請求項15に記載の第1のノード。
27. 前記第1のノードが前記ネットワークの仮想グリッド内の第2のゾーンにあり、前記第1のノードが第1のゾーンから前記第2のゾーンに入ってしまっているとき、前記命令は、送信することに先だって、前記第1のノードに、さらに、
    前記第1のノードにおいて、前記第1のノードが前記第2のゾーンの通信チャネルの可用性について不完全な情報を有していることを示す、ブラインドネスインディケーションを送信させる、請求項15に記載の第1のノード。
28. 前記命令は、前記第1のノードに、前記要求することの後に、さらに、
    前記第1のノードが仮想グリッドにおいて第1のゾーンから第2のゾーンへ移動してしまっていると判定させ、
    前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっている場合には、前記チャネルのステータスを前記第1のノードの2次チャネルから1次チャネルへ変更させ、
    前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっていない場合には、前記第1のノードにおいて、前記第2のゾーンの利用可能なチャネルを前記第1のノードの1次チャネルとして要求させる、請求項15に記載の第1のノード。
29. 車車間アドホックネットワークにおける方法であって、
    仮想グリッドの第1のゾーン内の新たなノードにおいて、前記第1のゾーンの通信チャネルの可用性を示す情報を受信するステップであって、前記新たなノードは、要求済のチャネルを有していない、ステップと、
    前記新たなノードにおいて、前記新たなノードための1次チャネルのリクエストを示すネットワーク・エントリ・リクエストを送信するステップと
    を含む方法。
30. 前記送信するステップは、前記ネットワーク・エントリ・リクエストを、前記第1のゾーンと関連付けられたマスタノードへ送信するステップを含む、請求項29に記載の方法。
31. 可用性を示す前記情報は、前記第1のゾーン内の第2のノードからのビーコン送信と、前記第1のゾーンのブロードキャストチャネルのうちの少なくとも1つをとおして前記新たなノードにおいて受信される、請求項29に記載の方法。
32. 前記ネットワーク・エントリ・リクエストに応答して、前記新たなノードによる要求のための1次チャネルのインディケーションを前記新たなノードにおいて受信するステップをさらに含む、請求項29に記載の方法。
33. 前記ネットワーク・エントリ・リクエストは、前記新たなノードの位置を示す情報を含む、請求項29に記載の方法。
34. 車車間アドホックネットワーク内で動作するためのノードであって、前記ノードは、
    プロセッサと、
    通信サブシステムと、
    前記プロセッサによって実行されたときに、第1のノードに
    前記通信サブシステムをとおして受信した情報から、仮想グリッドの第1のゾーンの通信チャネルの可用性のインディケーションをデコードさせ、前記ノードは前記第1のゾーン内にあり、要求済のチャネルを有しておらず、
    前記ノードにおいて、前記新たなノードのための1次チャネルのリクエストを示すネットワーク・エントリ・リクエストを示すメッセージを送信させる、命令を記憶する、コンピュータ可読の記憶媒体と
    を備えるノード。
35. 車車間アドホックネットワークにおける方法であって、
    前記アドホックネットワーク内の仮想グリッドの第1のゾーン内に位置している第1のノードにおいて、第2のゾーンの第1の通信チャネルの可用性を示す情報を受信するステップと、
    前記第1のノードにおいて、前記第1のチャネルを前記第1のノードの2次チャネルとして要求するステップと
    を含む方法。
36. 前記受信するステップの前に、前記第1のノードは、前記第1のノードが前記第1のチャネルを2次チャネルとして要求することができないような、前記第1のチャネルの前記可用性について不十分な情報を有している、請求項35に記載の方法。
37. 前記受信された情報の少なくとも一部は、ブロードキャストチャネルをとおして、前記第1のゾーン以外のゾーン内に位置している第2のノードから受信される、請求項35に記載の方法。
38. 前記要求するステップは、第2のノードの位置に対する前記第1のノードの位置に基づく、請求項35に記載の方法。
39. 前記第1および第2のノードの前記相対的位置は、基準位置に対する前記第1および第2のノードそれぞれの距離に基づいて決定される、請求項38に記載の方法。
40. 前記基準位置は、前記仮想グリッド内のゾーンの端を含む、請求項39に記載の方法。
41. 前記要求するステップは、後続の時刻における前記2次チャネル上での前記第1のノードによる送信のために、第1の時刻に発生する、請求項35に記載の方法。
42. 前記第1のチャネルは、Sparse Code Multiple Access（SCMA）レイヤを含む、請求項35に記載の方法。
43. 車車間アドホックネットワーク内で動作するための第1のノードであって、前記第1のノードは、
    プロセッサと、
    通信サブシステムと、
    前記プロセッサによって実行されたときに、前記第1のノードに、
    前記第1のノードが前記ネットワーク内の仮想グリッドの第1のゾーン内に位置しているときに前記第1のノードにおいて、前記通信サブシステムをとおして受信した情報から、第2のゾーンの第1の通信チャネルの可用性のインディケーションをデコードさせ、
    前記第1のチャネルを前記第1のノードの2次チャネルとして要求すること示すメッセージを送信させる、命令を記憶する、コンピュータ可読の記憶媒体と
    を備える第1のノード。
44. 車車間アドホックネットワークにおける方法であって、
    前記ネットワークの仮想グリッド内の第2のゾーン内の第1のノードにおいて、ブラインドネスインディケーションを送信するステップであって、前記第1のノードは、第1のゾーンから前記第2のゾーンに入ってしまっており、前記ブラインドネスインディケーションは、前記第1のノードが前記第2のゾーンの通信チャネルの可用性について不完全な情報を有していることを示す、ステップ
    を含む方法。
45. 前記第1のノードにおいて、前記送信するステップに応答して、前記第2のゾーンの1つまたは複数の利用可能なチャネルを示す情報を受信するステップをさらに含む、請求項44に記載の方法。
46. 前記第1のノードにおいて、前記第2のゾーンの前記1つまたは複数の利用可能なチャネルのうちの少なくとも1つを前記第1のノードの1次チャネルとして要求するステップをさらに含む、請求項45に記載の方法。
47. 前記要求するステップは、第2のノードの位置に対する前記第1のノードの位置に基づく、請求項46に記載の方法。
48. 前記第1および第2のノードの前記相対的位置は、基準位置に対する前記第1および第2のノードそれぞれの距離に基づいて決定される、請求項47に記載の方法。
49. 車車間アドホックネットワーク内で動作するための第1のノードであって、前記第1のノードは、
    プロセッサと、
    通信サブシステムと、
    前記プロセッサによって実行されたときに、前記第1のノードに、
    前記ネットワークの仮想グリッド内の第2のゾーン内の前記第1のノードにおいて、ブラインドネスインディケーションを送信させ、前記第1のノードは、第1のゾーンから前記第2のゾーンに入ってしまっており、前記ブラインドネスインディケーションは、前記第1のノードが前記第2のゾーンの通信チャネルの可用性について不完全な情報を有していることを示す、命令を記憶する、コンピュータ可読の記憶媒体と
    を備える第1のノード。
50. 車車間アドホックネットワークにおける方法であって、
    前記アドホックネットワーク内の仮想グリッドの第1のゾーン内に位置しているノードにおいて、前記第1のゾーンの通信チャネルの可用性を示す情報をブロードキャストするステップ
    を含む方法。
51. 前記ノードは、前記ブロードキャストするステップを実行する責任を負う、前記第1のゾーンのマスタノードである、請求項50に記載の方法。
52. 前記ブロードキャストするステップは、専用のブロードキャストチャネルにおいて発生する、請求項50に記載の方法。
53. 車車間アドホックネットワーク内で動作するためのノードであって、前記ノードは、
    プロセッサと、
    通信サブシステムと、
    前記プロセッサによって実行されたときに、前記ノードに、
    前記ノードが前記アドホックネットワーク内の仮想グリッドの第1のゾーン内に位置しているときに前記ノードにおいて、前記第1のゾーンの通信チャネルの可用性を示す情報を送信させる、命令を記憶する、コンピュータ可読の記憶媒体と
    を備えるノード。
54. 車車間アドホックネットワークにおける方法であって、
    前記ネットワーク内の第1のノードにおいて、前記第1のノードが仮想グリッド内において第1のゾーンから第2のゾーンへ移動してしまっていると判定するステップと、
    前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっている場合には、前記チャネルのステータスを前記第1のノードの2次チャネルから1次チャネルへ変更するステップと、
    前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっていない場合には、前記第1のノードにおいて、前記第2のゾーンの利用可能なチャネルを前記第1のノードの1次チャネルとして要求するステップと
    を含む方法。
55. 前記第1のノードが前記第2のゾーンへ移動するときに前記第1のノードが前記第1のゾーンのチャネルを1次チャネルとして要求してしまっている場合には、前記第1のノードにおいて、前記第1のゾーンのこのチャネルを開放するステップを含む、請求項54に記載の方法。
56. 前記第2のゾーンの前記チャネルを1次チャネルとして前記要求するステップは、第2のノードの位置に対する前記第1のノードの位置に基づく、請求項54に記載の方法。
57. 前記第1および第2のノードの前記相対的位置は、基準位置に対する前記第1および第2のノードそれぞれの距離に基づいて決定される、請求項56に記載の方法。
58. 前記第1のノードために前記1次チャネルを前記要求するステップは、後続の時刻における前記第1のノードによる送信のために、第1の時刻に発生する、請求項54に記載の方法。
59. 車車間アドホックネットワーク内で動作するための第1のノードであって、前記第1のノードは、
    プロセッサと、
    通信サブシステムと、
    前記プロセッサによって実行されたときに、前記第1のノードに、
    前記第1のノードが、仮想グリッドにおいて第1のゾーンから第2のゾーンへ移動してしまっていると判定させ、
    前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっている場合には、前記チャネルのステータスを前記第1のノードの2次チャネルから1次チャネルへ変更させ、
    前記第1のノードが前記第2のゾーンの通信チャネルを2次チャネルとして要求してしまっていない場合には、前記第1のノードにおいて、前記第2のゾーンの利用可能なチャネルを前記第1のノードの1次チャネルとして要求させる、命令を記憶する、コンピュータ可読の記憶媒体と
    を備える第1のノード。

Images