車両通行環境における信頼可能な放送送信
【課題】車両が通行する環境においてブロードキャスト伝送を行う方法を提供する。
【解決手段】 本発明の方法は、（ａ）ダイナミック・ローカルマップを提供するステップと、（ｂ）前記ダイナミック・ローカルマップとＲＴＳ／ＣＴＳハンドシェイクを用いるステップと、前記（ｂ）ステップにより、他の車両へデータをブロードキャストする、（ｃ）無線カバレッジ・リミットを決定するステップと、（ｄ）前記無線カバレッジ・リミットを、前記ダイナミック・ローカルマップと前記ＲＴＳ／ＣＴＳハンドシェイク信号と共に用いるステップとを有する。前記（ｄ）ステップにより、データをブロードキャストする。
【解決手段】 本発明の方法は、（ａ）ダイナミック・ローカルマップを提供するステップと、（ｂ）前記ダイナミック・ローカルマップとＲＴＳ／ＣＴＳハンドシェイクを用いるステップと、前記（ｂ）ステップにより、他の車両へデータをブロードキャストする、（ｃ）無線カバレッジ・リミットを決定するステップと、（ｄ）前記無線カバレッジ・リミットを、前記ダイナミック・ローカルマップと前記ＲＴＳ／ＣＴＳハンドシェイク信号と共に用いるステップとを有する。前記（ｄ）ステップにより、データをブロードキャストする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークに関し、特に、リアルタイムで、車両間及び車両とインフラ設備との間のアド・フォックの通信ネットワークに関する。
【背景技術】
【０００２】
リアルタイムで行う車両間及び車両とインフラ設備との間のアド・フォックの通信ネットワークは公知である。車両は、無線周波数（ＲＦ）送受信機能を具備している。ＲＦ信号を送受信する車両は「ステーション」とも称する。ＩＥＥＥ８０２．１１ｐ標準は、この様なネットワークにおける通信の共通のプラットホームを提供している。車両間の通信を行う機器を具備した全ての車両は、パケットの形態で彼らのロケーション情報（位置情報）を周期的に送信している。これは「ビーコン」とも称する。ＩＥＥＥ８０２．１１ｐ標準は、渋滞環境において通信を実行できることを保障をしていない。その理由は、ビーコンの確実な到着が保障されていないからである。これにより様々問題が起こる。例えば安全に関するメッセージが失われると、セーフティ・メッセージ（安全に関するメッセージ）の「ブラインド・タイム（無通信期間）」を増加させることになる。これにより、車両間の通信と車両とインフラ設備との間の通信の安全に関する利点が失われる。
【０００３】
座標軸パケット送信へのアクセスポイントを具備しないと、ＩＥＥＥ８０２．１１ｐのステーションは、送信用にＣＳＭＡ／ＣＡ（Communication Sense Muitiple Access with Collision Avoidance）を用いる。高速道路あるいは交差点に周りに多くの車両があると、隠れたノード問題が、ネットワークの制限的ファクタとなる。この問題を図１で説明する。同図においては、道路１１０上での出来事を示す。車両の周りの円は信号の伝送範囲を示す。道路１１０と車両１０２との間に完全なパスが存在する。車両１００は、車両１０４にから隠れている。そのため車両１０４は、車両１００が通信の進行中にも関わらず、送信を開始してしまう。車両１０４と車両１００による同時送信により、車両１０２は、車両１００の通信を受領（聞き取ることが）できない。
【０００４】
図２に示す道路２２２と道路２２４とのの交差点２２０では更に問題である。隠れたノード問題は、異なる車両の対の間で見通すことができないために、更に大きくなる。図２に示すように、最悪の場合、車両２００から車両２１０への送信は、４台の車両２０２，２０４，２０６，２０８により悪影響を受け、更には中断されてしまうことがある。
【０００５】
隠れたノード問題に対する現在の解決方法は、ＲＴＳ／ＣＴＳ（Unicast networks endowed with a Request to Send/Clear to Send）スキームを用いることである。「ソース」ステーションは、宛先ステーションから許可得るために、リクエストを送信するのに、ＲＴＳメッセージをそのステーションに送ることにより行う。この宛先ステーションは、ＣＴＳメッセージで応答する。この交換はＲＴＳ／ＣＴＳ「ハンドシェイク」を構成する。許可がＣＴＳメッセージの応答により得られると、ソース・ステーションは、宛先ステーションに向けて、宛先ステーションの周りの他のステーションがサイアレントである（送信状態にない）ことの保障状態で、送信する。従来、ＲＴＳ／ＣＴＳスキームは、ブロードキャストパケットを用いることは許されていないが、現在では改正版の標準８０２．１１ｅは、方法は特定していないが、この様な使用法を許可している。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ブロードキャスト（「放送」とも称する）伝送（「通信」とも称する）を目的として、ＲＴＳ／ＣＴＳハンドシェイク用に任意の車両を選択する方法は、十分機能しない。その理由は、任意の車両選択は、特定のエリアをクリアできないからである。このことは図１からも明らかである。車両１０６が、ＲＴＳメッセージを送信する車両１００によりハンドシェークのために選択される場合を考えてみる。車両１０６は車両１００の近傍にある。しかし戻ってきたＣＴＳメッセージは、元のＲＴＳメッセージよりも長距離を伝搬することはなく、そのためクリアランスの範囲は拡張しない。この問題は、図２の場合更に明らかである。そのため任意のＲＴＳ／ＣＴＳは、放送用に適用することができない。
【０００７】
産業界で推進されている別の方法は、ＴＤＭＡ（time division multiple access）方式である。全てのステーションを同期させることにより、各ステーションには既知のタイムスロットが割り当てられる。このタイムスロットの間は、近傍にいる他のステーションは送信することができない。複数のＴＤＭＡの概念は、関連する分野で研究されているが、ＩＥＥＥ８０２．１１ｐは、ＴＤＭＡを含まず、又ＴＤＭＡを含むように変更することも計画されていない。
【課題を解決するための手段】
【０００８】
車両の環境で放送伝送を可能にする本発明は、走行車両（driven vehicle）とのＲＴＳ／ＣＴＳハンドシェイクで使用される基軸車両（pivot vehicle）を指定して、走行車両による他の車両への送信をクリアする。基軸車両は、ローカルマップの知識に基づいて選択（指定）される。一実施例においては、ローカルマップは、他の車両からのビーコンによる無線送信された地理的データに基づいて、走行車両でダイナミックに創設される。他の実施例においては、ローカルマップはナビゲーション・システムにより与えられる。走行車両による放送伝送は、走行車両からのＲＴＳメッセージに応答して、基軸車両がＣＴＳメッセージを受領した後、可能となる。
【０００９】
本発明によれば、車両が通行する環境においてブロードキャスト伝送を行う方法は、
（ａ）ダイナミック・ローカルマップを提供するステップと、
（ｂ）前記ダイナミック・ローカルマップとＲＴＳ／ＣＴＳハンドシェイクを用いるステップと、を有する。
前記（ｂ）ステップにより、他の車両へデータをブロードキャストする。
【００１０】
本発明によれば、車両が通行する環境においてブロードキャスト伝送を行う方法は、 （ａ）走行車両にダイナミック・ローカルマップを提供するステップと、
（ｂ）基軸車両を選択するステップと、
（ｃ）前記走行車両と基軸車両との間で、ＲＴＳ／ＣＴＳハンドシェイクを実行するステップと、を有する。
前記ＲＴＳ／ＣＴＳハンドシェイクにより、前記走行車両が他の車両にデータをブロードキャストできるようになる。
【００１１】
本発明によれば、車両が通行する環境においてブロードキャスト伝送を行うシステムは、
（ａ）走行車両と、
（ｂ）基軸車両と、
（ｃ）前記走行車両と基軸車両との間で、ＲＴＳ／ＣＴＳハンドシェイク実行する手段と、を有する。
前記ＲＴＳ／ＣＴＳハンドシェイクにより、前記走行車両がデータをブロードキャストできるようになる。
【図面の簡単な説明】
【００１２】
【図１】道路上での隠れたノード問題を表す図。
【図２】交差点での隠れたノード問題を表す図。
【図３】本発明の方法の主要ステップのフローチャート図。
【図４】図３の方法を実行するより詳細なフローチャート図。
【図５】ＲＦカバレッジ・リミットを学習する道路上の車の配置状態を表す図。
【図６】ローカルマップの形成プロセスのフローチャート図。
【図７】バックワードＲＴＳ／ＣＴＳハンドシェイクのエリア選択を行うフローチャート図。
【図８】フォワードＲＴＳ／ＣＴＳハンドシェイクのエリア選択を行うフローチャート図。
【図９】ＲＴＳ／ＣＴＳハンドシェイクの送信機能のフローチャート図。
【図１０】ＲＴＳ／ＣＴＳハンドシェイクの受信機能のフローチャート図。
【図１１】１本の道路上にある車両に本発明を適用する例を表す図。
【図１２】交差点上にある車両に本発明を適用する例を表す図。
【発明を実施するための形態】
【００１３】
本発明の方法は、車両通信スキームにおける隠れたノード問題あるいは他の問題を解決するものである。本発明は、地理的情報（「ダイナミック・ローカル・マップ」）を、走行車両と基軸車両の間のＲＴＳ／ＣＴＳハンドシェイクと組み合わせて、上記問題の解決方法を提供する。本発明を道路上にある車両である走行車両の観点から説明する。ロケーション情報は、ビーコン内に含まれ、走行車両により地理学上のデータベース内に、収集される。特定のエリア内において、どの車両が、道路事情（緊急ブレーキあるいは交差点における道路交通法違反）を解析するために、情報を必要としているかを知ることにより、本発明は、基軸車両をして機能する車両を選択する。この基軸車両は、その近傍における干渉伝送をクリアするものである。この基軸車両は、ＣＴＳメッセージを、走行車両により送信されたＲＴＳメッセージに戻す。
【００１４】
車両通行環境において、放送（ブロードキャスト）ＲＴＳ／ＣＴＳの解決方法は、公知ではない。地理的情報を用いて、最適なステーションをＲＴＳ／ＣＴＳハンドシェイクを実行するピボットステーションとして選択することも公知ではない。
【００１５】
本発明の方法は、分散システムで適用される。分散システムにおいては、各車両は周りの全ての車両の情報を処理することができる。言い換えると、各車両は、他の車両によりビーコンの形態で送信された情報を処理することができる。各車両内の情報処理は、他の車両内で行われる情報処理とは独立して、行われる。本発明の方法は、ダイナミック・ローカルマップ情報を用いる、更に無線（ＲＦ）カバレッジ・リミットも用いる。
【００１６】
図３において、ダイナミック・ローカル・マップは、走行車両内で提供（即ち創設）される（ステップ３００）。用語「ダイナミック」とは、増分的（徐々）にマップを構築する技術であり、これは、車両の通信の導入の前に必要とされるものでもなく、また構築されるものでもない。ローカル・マップは、走行車両内で、別の車両から受領したビーコンに基づいて、構築される、又はナビゲーション・システムから提供される。ローカル・マップは、走行車両が道路上移動するに連れて、変化する。ローカル・マップを用いて基軸車両を見出し選択する。ステップ３０２において信頼性のある放送通信が、走行車両と基軸車両の間のＲＴＳ／ＣＴＳハンドシェイクを用いて、行われる。これにより、走行車両近傍の他の送信機からの干渉を減らす。
【００１７】
図４において、ダイナミック・ローカル・マップが形成される（ステップ４００）。選択的事項としてあるいはそれと並列に、ＲＦカバレッジ・リミット（ＲＦ範囲）が、走行車両により学習される（ステップ４０２）。無線システムの範囲は、殆どの場合一定であるが、車両（移動）通信は、ＲＦ範囲に大幅な変動を及ぼす。このＲＦ範囲は環境に依存する。例えば通信を遮る建物、トンネル、カーブ及び他の車両（例えばトラック等）からの障害物により、影響を受ける。無線リンクは対称であると仮定する、即ちある車両の通信を走行車両が聞く（受領する）ことができると、その車両は走行車両からの通信も聞くことができると仮定する。ＲＦカバレッジ・リミット知識を用いて、隠れたノードの影響を排除する。
【００１８】
ＲＴＳ／ＣＴＳエリアは、ステップ４０４で選択される。これは、ダイナミック・ローカル・マップとＲＦカバレッジ・リミットの組み合わせを用いて、行われる。一実施例においては、ＲＴＳ／ＣＴＳエリアの選択は、ダイナミック・ローカル・マップのみに基づいて行うこともできる。選択されたＲＴＳ／ＣＴＳエリア内で基軸車両を選択しようとする試みは、ステップ４０６で行われる。ステップ４０８は、このような基軸車両が選択されたＲＴＳ／ＣＴＳエリア内に存在するか否かをチェックする。存在する（Ｙｅｓの）場合には、ＲＴＳ／ＣＴＳハンドシェイクが、走行車両と基軸車両との間で行われる。その後、走行車両によりデータ放送伝送が行われる（ステップ４１０）。基軸車両が選択されたＲＴＳ／ＣＴＳエリア内で見出されない場合（ステップ４０８）、ＲＴＳ／ＣＴＳ用の目標エリアは拡張され、ステップ４０６に戻り、更に拡張したＲＴＳ／ＣＴＳエリア内で基軸車両を選択しようと更なる試みが行われる。
【００１９】
ＲＦカバレッジ・リミットの概念と学習プロセスを次に詳述する。
【００２０】
ＲＦカバレッジ・リミット学習（ステップ４０２）。
一般的に、ＲＦカバレッジ・リミットは様々な方法で学習できる。一例として、ＲＦカバレッジ・リミットは、１台車両の読み取り情報に基づいて行われるものではなく、走行車両の近傍にある全ての車両の読み取り情報を組み合わせて行われる。ＲＦカバレッジ・リミットを学習するためには、走行道路と他の道路とを区別する必要がある。その理由は、走行道路上のトラフィックのみを考慮するからである。走行車両に対するフォワードとバックワードの方向の間の分離も必要である。その理由は、様々な調整が各方向に対し行われるからである。
【００２１】
計算する必要がある４つのカバレッジ・リミットがあるが、これは道路に依存する。 それらは、以下である。
走行道路の前方の距離に基づくカバレッジ・リミット、
走行道路の後方の距離に基づくカバレッジ・リミット、
ある道路の前方の距離に基づくカバレッジ・リミット、
ある道路の後方の距離に基づくカバレッジ・リミット
図５は、走行道路５３０上にある走行車両５００によるＲＦカバレッジ・リミットの学習の例を示す。トラック５０２が走行車両５００の後を走っており、後方のＲＦリンクをブロックする。その結果、トラック５０２の後を走っている車両５０４は、車両５００との間の通信が不可能となる。走行車両の後方を走る車両のカバレッジ・リミットは、トラック５０２の位置の周囲に設定される。
【００２２】
道路５３０の先がカーブしていると仮定する。このカーブはＲＦリンクをブロックする。その結果、車両５０８と走行車両５００との間で通信はできない。走行車両５００の前を走る車両のカバレッジ・リミット５２４は、車両５０６と車両５０８の間に設定される。同様に、車両５１０と車両５１２は、右折して別の道路５３２上を走行しており、低品質のＲＦリンクしか有さない。道路５３０以外の他の道路上で、車両５００の前方を走る車両に対するカバレッジ・リミットは、車両５１０と車両５１２との間に設定される（走行車両５００により）。その理由は、車両５１０は走行車両５００と通信できるが、車両５１２は走行車両５００とは通信できないからである。
【００２３】
４個の平均カバレッジ・リミットを得る手順は、次の通りである。特定の基軸車両に対し、４個のリミットの内の１個のみが関連する。その理由は、基軸車両は、同じ道路上にある走行車両の前方あるいは後方のいずれかにあるか、あるいは別の道路上の走行車両の前方あるいは後方にあるからである。走行車両が２個のＲＴＳ／ＣＴＳエリアと、２個の基軸車両を有するとすると、一方は前方に他方は後方にあり、２つの異なるリミットがフォワード・エリアとバックワード・エリアの両方に対しチェックされる。カバレッジ・リミットのチェックは次のように行われる。
（ａ）４個全てのカバレッジ・リミットを最初は０に設定する。
（ｂ）車両からの送信を受領すると、４個のカバレッジ・リミットの内の１個のみを更新する。
この更新値は、走行車両（後方又は前方）に対する受信車両（即ち、走行車両がそのビーコンを受領する車両）のロケーションに基づき、かつ走行車両に関連する道路と受信車両に関連する道路の間の類似性（同一又は別々）に基づき分類される。更新されたカバレッジ・リミットのインデックスは、「updated」として記述される。関連するカバレッジ・リミットは、次のようにして更新する。
（ｃ）カバレッジ・リミット＝カバレッジ・リミット×α＋車間距離×（１−α）
ここで「車間距離」は、走行車両と受信車両の間の距離である。
αは次のように決められる。
（ｉ）カバレッジ・リミットが車間距離よりも大きな場合：
ＢＥＲ情報が得られた場合には、α＝ｍｉｎ（１，１６×ＢＥＲ＋０．２５）、それ以外は０．９を用いる。この目的は、ＢＥＲが低い時にはカバレッジ・リミットを増加させ、ＢＥＲが高い時には同一の場所でカバレッジ・リミットをキープする。
（ｉｉ）カバレッジ・リミットが車間距離よりも小さい場合：
ＢＥＲ情報が得られた場合には、α＝ｍａｘ（０，１−４×ＢＥＲ）、それ以外は０．１を用いる。この目的は、上記の場合とは逆であり、ＢＥＲが高い時にはカバレッジ・リミットを減少させ、ＢＥＲが低い時には同一の場所でカバレッジ・リミットをキープする。
【００２４】
カバレッジ・リミットの計算は、走行車両の位置（即ち、新たなＧＰＳ読み取り値の到着時）と、時間（即ち、全ての車両からのビーコンを受領する１００ミリ秒サイクルの完了時）の変化に対し、連続性を維持しなければならない。最終的に実際のカバレッジ・リミットは、前のリミットの割合に設定される。例えば１００ミリ秒毎に９５％である。これは、主な目的が高速の反応を提供するためである。例えば通信をブロックするトラックは、カバレッジ・リミットに直ちに影響するようにしなければならない。
【００２５】
ローカル・マップ創設（形成）（ステップ４００）
マップの創設において、道路は、単純化するために、直線状のチェーンに変換される。これはマップのデータベースでは一般的である。この場合、チェーンは「ポリライン（polyline）」又は「ポリノバル・チェーン（polynobal chain）」と称する。交差点は、３本以上の道路の接続点として定義される。従来の（一台の走行車両による）マップ形成技術は、一台の車両からのローカルＧＰＳの読み取り情報を用い、マップのデータベースをシーケンシャルに構築する。しかし複数の車両からの送信によるダイナミック・ローカルマップの形成は、それとは異なりより複雑である。一台の車両のローカルＧＰＳの読み取り情報を用いる代わりに、複数台の車両（最大で２００台の車両）からの同時の位置情報を用い、従来のマップ形成とは対称的に、無線で受領したロケーションデータはシーケンシャルではない。これはローカルマップの形成に影響を及ぼす。例えば車両が前方に走行中には、この車両は、走行道路で以前には検知しなかった車両からのシーケンシャルな情報を受信する。このシーケンシャルな情報は、走行道路の連続性を記述する。しかし、対向する道を反対方向に走る車両から受領した情報は、走行車両により非シーケンシャルに発見される。ある道路は、ＲＦ受信が限られているために、完全には記述できない。例えば、交差する道路は一部しか検知できない。車両は、時々意外な動きをするため、このような事象（車両の動き）は、ローカルマップの形成に混乱を及ぼす。様々な車両から受領したビーコンのＧＰＳエラーは、互いに相関関係がない。このことを考慮に入れなければならない。しかしこのことは、一台の車両を用いた標準のマッピングの場合には当てはまらない。これらの全ては、マップ形成の革新的なアルゴリズムを必要とする。
【００２６】
図６に、ダイナミック・ローカルマップの形成のステップの詳細を示す。各車両に対する現在のＧＰＳ座標軸と速度ベクトルがそれぞれの車両のビーコンで送信される（ステップ６００）。この情報はＲＦカバレッジ・リミット内いる全ての車両が受領できる。ステップ６０４において、走行車両で解析されたビーコン情報を有する車両は、いずれか既知の道路にマッピングされているかのチェックが行われる。既知の道路が見い出せない場合には、ステップ６０６で、車両の方向が一定か否かあるいは最後に分かっていた前の方向から新たな方向に変更したかのチェックが行われる。例えば、前の道路上でマッピングされた最後の位置までの距離がある値（例、１２ｍ）を越えてるか否かのチェックが行われる。新たな道路がローカルマップデータベース内で形成される（ステップ６０８）。新たな交差点がローカルマップデータベース内に形成される（ステップ６１８）。
【００２７】
既知の道路がステップ６０４で見出されると、ステップ６１０で、解析されたビーコン情報を有する車両に関連する道路は、前の道路マッピングから変化したか否かのチェックが行われる。道路が変化している場合には、操作はステップ６１６に更に進み、元の道路と新たな道路を含む交差点が規定されているかのチェックが行われる。規定されている場合には、操作は終了する。規定されていない場合には、交差点がステップ６１８で形成される。ステップ６１０で道路が変わっていない場合には、道路の長さがステップ６１２で更新される。道路の延長境界に関するのチェックがステップ６１４で行われる。道路の延長が、同一長さ同一高さの交差する道路を越える場合には、交差点がステップ６１８で規定される。
【００２８】
ステップ６１２，６１４で説明したように、道路の特性が、受信した送信情報に基づいてダイナミックに調整される。これに対し、従来のマップ形成のアルゴリズムは、全ての特性が既知になった後、オフラインで計算される。
【００２９】
ＲＴＳ／ＣＴＳハンドシェイクに対する最適エリアの選択（ステップ４０４）。
次の表は、周囲の環境を考慮しながら、ＲＴＳ／ＣＴＳハンドシェイク用の最適のエリアの概要を示す。用語「アヘッド」「フォワード」「ビハインド」「バックワード」は、走行車両に対する地理的な方向或いは位置を示す。より詳細なシナリオは、交通規則、自動車メーカーからの要件に基づいて、付加することもできる。
【００３０】
ローカルマップ上の走行車両のロケーション 最適ＲＴＳ／ＣＴＳエリア
高速道路又は一方通行の道路上の走行 道路前方の走行状態を通知するために 走行車両のバックワード
交差点内 左折補助のために反対側の道路上にあ る走行車両のフォワードエリアと走行 車両のバックワード
交差点へ近づく 交差点の中央点の中心にあるフォワー ドエリアと走行車両のバックワード
環状交差点へ近づく 環状交差点に接続される第１道路の中 心のフォワードエリアと走行車両のバ ックワード
合流又は高速道路のインターチェンジに近づく 並列道路の合流点の中心にあるフォワ ードエリアと走行車両のバックワード
立体交差を通過する 走行車両、好ましくは立体交差に近い 車両のバックワード
カバレッジのないポイントへ近づく カバレッジ・リミットの直前のフォワ ードエリア
カバレッジのないポイントから離れる カバレッジ・リミットの直前のバック ワードエリア
【００３１】
バックワードＲＴＳ／ＣＴＳハンドシェイクエリア選択
図７を参照して、バックワードＲＴＳ／ＣＴＳハンドシェイクエリア選択を説明する。ステップ７００は、最適ＲＴＳ／ＣＴＳエリアを速度に基づいて決定する。高速時においては、ビーコンの受領領範囲は後方に伸びる。ハンドシェイクエリアは、走行車両の背後で選択され、所定の期間（例、４秒）で道路上の最高速の車両が通過する距離に等しい。ステップ７０２は、ステップ７００で計算された最適エリアと、道路上を通る最近距離の陸橋までの距離との間の最小化計算を実行する。即ち、走行車両に最も近いエリアを選択する。例えば、最適エリアが走行車両の後方１００ｍであるが、車両は現在の位置の前５０ｍにある橋を通過しているとすると、最適エリアは、ブリッジの周りの車両の後方５０ｍに設定される。ステップ７０４は、ステップ７０２で計算されたエリアと、カバレッジ・リミットの間の更なる最小化計算を実行する。
【００３２】
フォワードＲＴＳ／ＣＴＳハンドシェイクエリア選択
図８を参照して、フォワードエリアの選択を説明する。第１ステップ８００は、道路が中央分離帯のない双方向通行道路であるか否かをチェックする。反対方向の道路は、双方向通行道路として分類するために特定される必要がある。反対側の道路までの距離を測定し、それがしきい値よりも大きい場合には、中央分離帯があると見なされる。中央分離帯のない双方向通行道路が規定されない場合（ステップ８００でのＮｏの場合）、チェックがステップ８０２で行われる。このチェックは、交わる点（crossing point）が前方にあるかを見る。交わる点が見出せない場合には、ステップ８０６はフォワードへの送信の必要性がないと決定する。交わる点が前方に見出される場合には、ステップ８０４は、ＲＴＳ／ＣＴＳエリアを前方の交わる点に設定する。
【００３３】
中央分離帯のある双方向通行道路が定義されると（ステップ８００でＹｅｓの場合）、ステップ８０８は、ＲＴＳ／ＣＴＳのエリアを設定（決定）する。この設定は、速度に依存するが一定値でもよい。ステップ８１０において、交差点が存在するか否かがチェックされる。交差点が存在する場合には、最適エリアは、交差点に応じて設定される。これはステップ８１２で説明する。ステップ８１２においては、カバレッジ・リミットが計算されたエリアと比較され、カバレッジ・リミットが短い場合はそれが選択される。
【００３４】
交差点は３つのタイプに分類される。即ち合流と、環状交差点と、通常の交差点である。
合流点：合流点は走行車両が４５度以下の角度で別の道路と交わるものに定義される。合流点は３つの道路部分を接続する。しかしより多くの数の道路があってもよい。この場合全ての角度は４５度以下である、即ち１３５（１８０−４５）度以上である。
環状交差点：環状交差点は、複数本の交差点が互いに近接している場合に定義される。一般的に、一方向の道路が交差点の間を回る。
通常の交差点：上記２つの定義に入らない全ての交差点を言う。
【００３５】
交差点のタイプに依存して、ＲＴＳ／ＣＴＳを選択する。
交差点においては、交差点の中にある車両が、基軸車両として選択される。交差点内に車両がない場合には、交差する道路上の交差点近傍の車両、あるいは最後の手段として、同一の道路上にある交差点近傍の車両が基軸車両として好ましい。
合流点においては、両方の道路が同一の速度（即ち、道路上を走る車両の平均速度）を有する場合は、並行する道路の交差点から合流する道路の距離に等しい距離にあるエリアが選択される。
環状交差点においては、第１出口と第２出口の間のエリアが、ＲＴＳ／ＣＴＳエリアとして、好ましい。車両がこの好ましいエリアにない場合、環状交差点内の車両が、機軸車両として、選択される。
【００３６】
ＲＴＳ／ＣＴＳハンドシェイク実行
以下の説明は、ステップ５０６の詳細である。
【００３７】
送信機能
図９を参照して、ＲＴＳ／ＣＴＳハンドシェイクの送信機能について説明する。ある車両を基軸車両としてステップ９００で選択する。ステップ５０４で決定された最適のＲＴＳ／ＣＴＳエリアの中心にある第１の基軸車両が、選択される。ＲＴＳメッセージが、ステップ９０２で走行車両により送信される。ハンドシェークは、最大パワー制御を用いて行われ、これによりＲＦ範囲を最大にする。別の構成として、パワー制御スキームを適用してブロードキャスト送信のパワーを制限する。最低の変調インデックスが通常用いられる。但し、これは、同一道路上の車両へのバックワード送信と、道路が一方通行の時と、高い変調は受信機能を損なうことなく用いられる場合を除く。
【００３８】
ＣＴＳメッセージが、選択された第１の基軸車両からステップ９０４でうまく受領されると、データは、走行車両によりステップ９０６で放送され、そこで操作は終了する。ＣＴＳメッセージをステップ９０４でうまく受領できない場合には、ステップ９０８は、ランダムな時間遅延を選択する。この選択は、走行車両に近い複数の車両に基づいて行われる。標準では、ビーコン送信は１００ミリ秒以内に終了しなければならないと規定する。ランダムな時間遅延の選択を高くすると、次の試みの際更なる衝突の可能性を減らすことができる。その理由は、様々なステーションでの試みがより均一に分布するからである。実験例では、ランダムな時間遅延の値は、５ミリ秒から２０ミリ秒が、最適の性能を発揮できる。送信の回数はステップ９１０でチェックされる。ある数（例えば３回）の送信が行われると、データは、ステップ９１２でＲＴＳ／ＣＴＳハンドシェイクを実行することなく送信される。３回の送信が行われない場合には、別の車両が次の試みのために基軸車両としてステップ９１４で選択され、ステップ９０２に戻り、操作は終了する。
【００３９】
ＲＴＳ／ＣＴＳハンドシェイクは、次の２つの理由で失敗する。第１の理由は、選択された機軸車両近傍の送信を、ＲＴＳを実行するステーションが受領することである。第２の理由は、無線リンクの性質に依存する。両方の理由とも、ハンドシェークの失敗後、別の基軸車両を選択すると利点があるが、これは、複数個の車両が、最適のＲＴＳ／ＣＴＳエリア内にある場合である。
【００４０】
受信機能
図１０を参照して、ＲＴＳメッセージを受領するステーションの受信機能を説明する。この操作は、ステップ１０００で、ある長さのＲＴＳメッセージを持つパケットを各車両が受領した時に、始まる。特にそこに向けられたＲＴＳメッセージを受領した車両が、機軸車両となる。各パケットは、ステップ１００２でチェックされる。パケットが無効な場合（これは、ＦＣＳ（Frame Check Sequence）値にマッチしないことにより示される）、あるいはパケットが基軸車両以外のステーションに帰属する場合には、本発明のプロセスは、ステップ１００４にジャンプする。ステップ１００４において、基軸車両を除く車両は送信しないままである（remain silent）。ある場合には、車両は、受領したＲＴＳメッセージが無効の場合でさえ、送信しない（サイレントである）。標準８０２．１１は、有効なパケットのみを対象にしている。ここに記載したメカニズムを除いて、標準８０２．１１機構は、パケットのコンテンツをポジティブにパーディングせずに（without psoitive parsing of packet content）動作する。この伝送を回避することにより、他の送信を遮断するリスクが排除される。
【００４１】
無線信号は２つのしきい値を有する。干渉のしきい値と受信のしきい値（パワー受信しきい値）である。ＲＴＳパケットが基軸車両に向けられたものの場合には、本発明のプロセスはステップ１００６から継続する。リンクがビジーでない場合には、ＣＴＳメッセージはステップ１００８に戻される。データは戻るものとする。このデータの有効性はステップ１０１６でチェックされる。チェックが失敗するかあるいはＢＥＲが構築可能レベル（例えば０．０５）以下の場合には、データは無効と宣言される。ＢＥＲの条件付けは革新的である。各パケットはViterbi符号で保護される。多くのエラーを有するパケットは、Viterbi符号化の修正機能を経た後受け入れられるが、走行車両から相当距離離れた位置にあるステーションでは殆ど拒絶される。この場合再送信を強化することにより、データを受領する他のステーションの確率が増加する。選択的事項として、再送信は、未請求のＣＴＳメッセージをステップ１００８で送信することにより、強制的に行われる。このステップは革新的であるが、その理由は、ＲＴＳ／ＣＴＳハンドシェイクを用いて、ブロードキャストパケットを受領確認する方法を確立するからである。しかしこれは、標準８０２．１１ベースのネットワークでは、今のところ存在していない。
【００４２】
リンクが、ステップ１００６でビジーな場合には、操作はステップ１０１０から再開する。機軸ステーションは、リンクがフリーになるまで待機する。この時間の間、ステーションがＲＴＳメッセージを別のステーションに送信したことが、検知されると（ステップ１０１２）、この操作終了する。それ以外には未請求のＣＴＳメッセージは、ステップ１０１４で送信される。この革新的なステップにより、チャネル資源の最適な割り当てが提供できる。、これは、リンクが利用できるようになった時に、再送信をする前の失敗したリクエストをスケジューリングすることにより、行われる。
【００４３】
使用例
図１を参照して、ローカルマップとＲＴＳ／ＣＴＳハンドシェイクを用いて車両のブロードキャストの実施例を説明する。車両１１００は、ＲＴＳメッセージを基軸車両１１０２の方向に送信する。この基軸車両１１０２は、ＣＴＳメッセージで応答する。これにより、車両１１００，１１０２の間のＲＴＳ／ＣＴＳハンドシェイクを確立する。このメッセージ交換を受信している近傍にある他の全ての車両は、ＲＴＳ／ＣＴＳメッセージで示された時間の間、サイレント状態でいる（送信しない）ことが要求される。これにより、「クリアされた領域」１１１０が形成される。これはオーバーラップしたエリアを含む２つの円からなる組み合わされたエリアで示されている。車両１１０４は干渉しないがその理由は、車両１１０４は車両１１０２からのＣＴＳメッセージを受領しているからである。車両１１０６も干渉しない。
【００４４】
交差点におけるより重大な問題が、交差点内の車両をＲＴＳ／ＣＴＳハンドシェイクのレスポンダーとして選択することにより、解決できる。この車両は、ハンドシェーク内のこの送信のためにアクセスポイントとして動作し、複数の車両の間をコーディネートする。図１２は図２に類似する。同図において、基軸車両１２１０は、ＲＴＳメッセージを受領し、ＣＴＳメッセージで応答する。車両１２１０は、交差点内にある全ての車両（１２００，１２０２，１２０４，１２０６，１２０８）に対する最適の無線パスを有する。この送信信号を受領する全ての車両（即ち１２００，１２０２，１２０４，１２０６，１２０８）は、サイレントを保つ。
【００４５】
本発明は、あらゆる放送送信（伝送）に適用可能である。例えば、ビーコン送信、ジェオキャスト放送送信、ＩＥＥＥ１６０９サービス・創設メッセージにも適用可能である。
【００４６】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。
【符号の説明】
【００４７】
１１０ 道路
１００，１０２，１０４，１０６ 車両
２００，２０２，２０４，２０６，２０８，２１０ 車両
２２０ 交差点
２２２，２２４ 道路
５００，５１０，５１２ 走行車両
５０２ トラック
５２０ カバレッジ・リミット
５３０ 道路
図３
３００：ローカル・マップを創設する
３０２：ＣＴＳ／ＲＴＳハンドシェイクの後に放送パケットを送信する
図４
４００：ダイナミック・ローカル・マップを創設する
４０２：ＲＦカバレッジ・リミットを学習する
４０４：ＲＴＳ／ＣＴＳ用のエリアを選択する
４０６：そのエリアから基軸車両を選択する
４０８：車両が見出されたか？
４１０：選択された基軸車両とのＲＴＳ／ＣＴＳハンドシェイクの実行後、放送データを送信する
４１２：ＲＴＳ／ＣＴＳ用の目標エリアを拡張する
終了
図５
５００ 走行車両
５０２ 通信をブロックする車両
５０４，５０８，５１２ 通信不可車両
５０６、５１０ 通信可車両
５２４ 走行車両の前のカバレッジ・リミット
５２２ 別の道路上の走行車両の前のカバレッジ・リミット
５２０ 走行車両の後ろのカバレッジ・リミット
５３２ 別の道路
図６
６００：ＧＰＳ座標軸と速度ベクトルを受領する
６０４：車両は既知の道路にマップされているか？
６０６：車両の走行方向は維持され、前位置までの距離は１２ｍを越えるか？
６０８：新たな道路を創設する
６１０：道路は変わったか？
６１２：道路長さを更新する
６１４：延長した道路はクロスポイントを越えたか？
６１６：交差点が定義されたか？
６１８：新たな交差点を創設する
終了
図７
７００：速度に応じてエリアを設定する
７０２：前のエリアの最小値と最近交差したブリッジを選択する
７０４：前のエリアの最小値とカバレッジ・リミットを選択する
図８
８００：双方通行の道で分離体があるか？
８０２：交差点が前にあるか？
８０４：エリアを渋滞ポイントに設定する
８０６：前向への送信はない
８０８：速度に応じてエリアを設定する
８１０：交差点が前にあるか？
８１２：エリアを渋滞ポイントに設定する
８１４：前のエリアの最小値とカバレッジ・リミットを選択する
図９
９００：エリア内で車両を選択する
９０２：ＲＴＳを送信する
９０４：ＣＴＳを受領したか・
９０６：データを送信する
９０８：ランダムな遅延時間を選択する
９１０：試みが３回成されたか？
９１２：データを送信する
９１４：エリア内で他の車両を選択する
終了
図１０
１０００：ＲＴＳ長さでパケットを受領したか？
１００２：ＲＴＳに応答すべきか？
１００４：沈黙を守る
１００６：リンクはビジーか？
１００８：ＣＴＳに応答する
１０１０：リンクが空くまで待つ
１０１２：他のステーションへのＲＴＳは、待機中に受領したか？
１０１４：未申請のＣＴＳを送る
１０１６：悪いＦＣＳ又はしきい値以下のＢＥＲでデータを受領したか？
１０１８：未申請のＣＴＳを送る
終了
【技術分野】
【０００１】
本発明は、通信ネットワークに関し、特に、リアルタイムで、車両間及び車両とインフラ設備との間のアド・フォックの通信ネットワークに関する。
【背景技術】
【０００２】
リアルタイムで行う車両間及び車両とインフラ設備との間のアド・フォックの通信ネットワークは公知である。車両は、無線周波数（ＲＦ）送受信機能を具備している。ＲＦ信号を送受信する車両は「ステーション」とも称する。ＩＥＥＥ８０２．１１ｐ標準は、この様なネットワークにおける通信の共通のプラットホームを提供している。車両間の通信を行う機器を具備した全ての車両は、パケットの形態で彼らのロケーション情報（位置情報）を周期的に送信している。これは「ビーコン」とも称する。ＩＥＥＥ８０２．１１ｐ標準は、渋滞環境において通信を実行できることを保障をしていない。その理由は、ビーコンの確実な到着が保障されていないからである。これにより様々問題が起こる。例えば安全に関するメッセージが失われると、セーフティ・メッセージ（安全に関するメッセージ）の「ブラインド・タイム（無通信期間）」を増加させることになる。これにより、車両間の通信と車両とインフラ設備との間の通信の安全に関する利点が失われる。
【０００３】
座標軸パケット送信へのアクセスポイントを具備しないと、ＩＥＥＥ８０２．１１ｐのステーションは、送信用にＣＳＭＡ／ＣＡ（Communication Sense Muitiple Access with Collision Avoidance）を用いる。高速道路あるいは交差点に周りに多くの車両があると、隠れたノード問題が、ネットワークの制限的ファクタとなる。この問題を図１で説明する。同図においては、道路１１０上での出来事を示す。車両の周りの円は信号の伝送範囲を示す。道路１１０と車両１０２との間に完全なパスが存在する。車両１００は、車両１０４にから隠れている。そのため車両１０４は、車両１００が通信の進行中にも関わらず、送信を開始してしまう。車両１０４と車両１００による同時送信により、車両１０２は、車両１００の通信を受領（聞き取ることが）できない。
【０００４】
図２に示す道路２２２と道路２２４とのの交差点２２０では更に問題である。隠れたノード問題は、異なる車両の対の間で見通すことができないために、更に大きくなる。図２に示すように、最悪の場合、車両２００から車両２１０への送信は、４台の車両２０２，２０４，２０６，２０８により悪影響を受け、更には中断されてしまうことがある。
【０００５】
隠れたノード問題に対する現在の解決方法は、ＲＴＳ／ＣＴＳ（Unicast networks endowed with a Request to Send/Clear to Send）スキームを用いることである。「ソース」ステーションは、宛先ステーションから許可得るために、リクエストを送信するのに、ＲＴＳメッセージをそのステーションに送ることにより行う。この宛先ステーションは、ＣＴＳメッセージで応答する。この交換はＲＴＳ／ＣＴＳ「ハンドシェイク」を構成する。許可がＣＴＳメッセージの応答により得られると、ソース・ステーションは、宛先ステーションに向けて、宛先ステーションの周りの他のステーションがサイアレントである（送信状態にない）ことの保障状態で、送信する。従来、ＲＴＳ／ＣＴＳスキームは、ブロードキャストパケットを用いることは許されていないが、現在では改正版の標準８０２．１１ｅは、方法は特定していないが、この様な使用法を許可している。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ブロードキャスト（「放送」とも称する）伝送（「通信」とも称する）を目的として、ＲＴＳ／ＣＴＳハンドシェイク用に任意の車両を選択する方法は、十分機能しない。その理由は、任意の車両選択は、特定のエリアをクリアできないからである。このことは図１からも明らかである。車両１０６が、ＲＴＳメッセージを送信する車両１００によりハンドシェークのために選択される場合を考えてみる。車両１０６は車両１００の近傍にある。しかし戻ってきたＣＴＳメッセージは、元のＲＴＳメッセージよりも長距離を伝搬することはなく、そのためクリアランスの範囲は拡張しない。この問題は、図２の場合更に明らかである。そのため任意のＲＴＳ／ＣＴＳは、放送用に適用することができない。
【０００７】
産業界で推進されている別の方法は、ＴＤＭＡ（time division multiple access）方式である。全てのステーションを同期させることにより、各ステーションには既知のタイムスロットが割り当てられる。このタイムスロットの間は、近傍にいる他のステーションは送信することができない。複数のＴＤＭＡの概念は、関連する分野で研究されているが、ＩＥＥＥ８０２．１１ｐは、ＴＤＭＡを含まず、又ＴＤＭＡを含むように変更することも計画されていない。
【課題を解決するための手段】
【０００８】
車両の環境で放送伝送を可能にする本発明は、走行車両（driven vehicle）とのＲＴＳ／ＣＴＳハンドシェイクで使用される基軸車両（pivot vehicle）を指定して、走行車両による他の車両への送信をクリアする。基軸車両は、ローカルマップの知識に基づいて選択（指定）される。一実施例においては、ローカルマップは、他の車両からのビーコンによる無線送信された地理的データに基づいて、走行車両でダイナミックに創設される。他の実施例においては、ローカルマップはナビゲーション・システムにより与えられる。走行車両による放送伝送は、走行車両からのＲＴＳメッセージに応答して、基軸車両がＣＴＳメッセージを受領した後、可能となる。
【０００９】
本発明によれば、車両が通行する環境においてブロードキャスト伝送を行う方法は、
（ａ）ダイナミック・ローカルマップを提供するステップと、
（ｂ）前記ダイナミック・ローカルマップとＲＴＳ／ＣＴＳハンドシェイクを用いるステップと、を有する。
前記（ｂ）ステップにより、他の車両へデータをブロードキャストする。
【００１０】
本発明によれば、車両が通行する環境においてブロードキャスト伝送を行う方法は、 （ａ）走行車両にダイナミック・ローカルマップを提供するステップと、
（ｂ）基軸車両を選択するステップと、
（ｃ）前記走行車両と基軸車両との間で、ＲＴＳ／ＣＴＳハンドシェイクを実行するステップと、を有する。
前記ＲＴＳ／ＣＴＳハンドシェイクにより、前記走行車両が他の車両にデータをブロードキャストできるようになる。
【００１１】
本発明によれば、車両が通行する環境においてブロードキャスト伝送を行うシステムは、
（ａ）走行車両と、
（ｂ）基軸車両と、
（ｃ）前記走行車両と基軸車両との間で、ＲＴＳ／ＣＴＳハンドシェイク実行する手段と、を有する。
前記ＲＴＳ／ＣＴＳハンドシェイクにより、前記走行車両がデータをブロードキャストできるようになる。
【図面の簡単な説明】
【００１２】
【図１】道路上での隠れたノード問題を表す図。
【図２】交差点での隠れたノード問題を表す図。
【図３】本発明の方法の主要ステップのフローチャート図。
【図４】図３の方法を実行するより詳細なフローチャート図。
【図５】ＲＦカバレッジ・リミットを学習する道路上の車の配置状態を表す図。
【図６】ローカルマップの形成プロセスのフローチャート図。
【図７】バックワードＲＴＳ／ＣＴＳハンドシェイクのエリア選択を行うフローチャート図。
【図８】フォワードＲＴＳ／ＣＴＳハンドシェイクのエリア選択を行うフローチャート図。
【図９】ＲＴＳ／ＣＴＳハンドシェイクの送信機能のフローチャート図。
【図１０】ＲＴＳ／ＣＴＳハンドシェイクの受信機能のフローチャート図。
【図１１】１本の道路上にある車両に本発明を適用する例を表す図。
【図１２】交差点上にある車両に本発明を適用する例を表す図。
【発明を実施するための形態】
【００１３】
本発明の方法は、車両通信スキームにおける隠れたノード問題あるいは他の問題を解決するものである。本発明は、地理的情報（「ダイナミック・ローカル・マップ」）を、走行車両と基軸車両の間のＲＴＳ／ＣＴＳハンドシェイクと組み合わせて、上記問題の解決方法を提供する。本発明を道路上にある車両である走行車両の観点から説明する。ロケーション情報は、ビーコン内に含まれ、走行車両により地理学上のデータベース内に、収集される。特定のエリア内において、どの車両が、道路事情（緊急ブレーキあるいは交差点における道路交通法違反）を解析するために、情報を必要としているかを知ることにより、本発明は、基軸車両をして機能する車両を選択する。この基軸車両は、その近傍における干渉伝送をクリアするものである。この基軸車両は、ＣＴＳメッセージを、走行車両により送信されたＲＴＳメッセージに戻す。
【００１４】
車両通行環境において、放送（ブロードキャスト）ＲＴＳ／ＣＴＳの解決方法は、公知ではない。地理的情報を用いて、最適なステーションをＲＴＳ／ＣＴＳハンドシェイクを実行するピボットステーションとして選択することも公知ではない。
【００１５】
本発明の方法は、分散システムで適用される。分散システムにおいては、各車両は周りの全ての車両の情報を処理することができる。言い換えると、各車両は、他の車両によりビーコンの形態で送信された情報を処理することができる。各車両内の情報処理は、他の車両内で行われる情報処理とは独立して、行われる。本発明の方法は、ダイナミック・ローカルマップ情報を用いる、更に無線（ＲＦ）カバレッジ・リミットも用いる。
【００１６】
図３において、ダイナミック・ローカル・マップは、走行車両内で提供（即ち創設）される（ステップ３００）。用語「ダイナミック」とは、増分的（徐々）にマップを構築する技術であり、これは、車両の通信の導入の前に必要とされるものでもなく、また構築されるものでもない。ローカル・マップは、走行車両内で、別の車両から受領したビーコンに基づいて、構築される、又はナビゲーション・システムから提供される。ローカル・マップは、走行車両が道路上移動するに連れて、変化する。ローカル・マップを用いて基軸車両を見出し選択する。ステップ３０２において信頼性のある放送通信が、走行車両と基軸車両の間のＲＴＳ／ＣＴＳハンドシェイクを用いて、行われる。これにより、走行車両近傍の他の送信機からの干渉を減らす。
【００１７】
図４において、ダイナミック・ローカル・マップが形成される（ステップ４００）。選択的事項としてあるいはそれと並列に、ＲＦカバレッジ・リミット（ＲＦ範囲）が、走行車両により学習される（ステップ４０２）。無線システムの範囲は、殆どの場合一定であるが、車両（移動）通信は、ＲＦ範囲に大幅な変動を及ぼす。このＲＦ範囲は環境に依存する。例えば通信を遮る建物、トンネル、カーブ及び他の車両（例えばトラック等）からの障害物により、影響を受ける。無線リンクは対称であると仮定する、即ちある車両の通信を走行車両が聞く（受領する）ことができると、その車両は走行車両からの通信も聞くことができると仮定する。ＲＦカバレッジ・リミット知識を用いて、隠れたノードの影響を排除する。
【００１８】
ＲＴＳ／ＣＴＳエリアは、ステップ４０４で選択される。これは、ダイナミック・ローカル・マップとＲＦカバレッジ・リミットの組み合わせを用いて、行われる。一実施例においては、ＲＴＳ／ＣＴＳエリアの選択は、ダイナミック・ローカル・マップのみに基づいて行うこともできる。選択されたＲＴＳ／ＣＴＳエリア内で基軸車両を選択しようとする試みは、ステップ４０６で行われる。ステップ４０８は、このような基軸車両が選択されたＲＴＳ／ＣＴＳエリア内に存在するか否かをチェックする。存在する（Ｙｅｓの）場合には、ＲＴＳ／ＣＴＳハンドシェイクが、走行車両と基軸車両との間で行われる。その後、走行車両によりデータ放送伝送が行われる（ステップ４１０）。基軸車両が選択されたＲＴＳ／ＣＴＳエリア内で見出されない場合（ステップ４０８）、ＲＴＳ／ＣＴＳ用の目標エリアは拡張され、ステップ４０６に戻り、更に拡張したＲＴＳ／ＣＴＳエリア内で基軸車両を選択しようと更なる試みが行われる。
【００１９】
ＲＦカバレッジ・リミットの概念と学習プロセスを次に詳述する。
【００２０】
ＲＦカバレッジ・リミット学習（ステップ４０２）。
一般的に、ＲＦカバレッジ・リミットは様々な方法で学習できる。一例として、ＲＦカバレッジ・リミットは、１台車両の読み取り情報に基づいて行われるものではなく、走行車両の近傍にある全ての車両の読み取り情報を組み合わせて行われる。ＲＦカバレッジ・リミットを学習するためには、走行道路と他の道路とを区別する必要がある。その理由は、走行道路上のトラフィックのみを考慮するからである。走行車両に対するフォワードとバックワードの方向の間の分離も必要である。その理由は、様々な調整が各方向に対し行われるからである。
【００２１】
計算する必要がある４つのカバレッジ・リミットがあるが、これは道路に依存する。 それらは、以下である。
走行道路の前方の距離に基づくカバレッジ・リミット、
走行道路の後方の距離に基づくカバレッジ・リミット、
ある道路の前方の距離に基づくカバレッジ・リミット、
ある道路の後方の距離に基づくカバレッジ・リミット
図５は、走行道路５３０上にある走行車両５００によるＲＦカバレッジ・リミットの学習の例を示す。トラック５０２が走行車両５００の後を走っており、後方のＲＦリンクをブロックする。その結果、トラック５０２の後を走っている車両５０４は、車両５００との間の通信が不可能となる。走行車両の後方を走る車両のカバレッジ・リミットは、トラック５０２の位置の周囲に設定される。
【００２２】
道路５３０の先がカーブしていると仮定する。このカーブはＲＦリンクをブロックする。その結果、車両５０８と走行車両５００との間で通信はできない。走行車両５００の前を走る車両のカバレッジ・リミット５２４は、車両５０６と車両５０８の間に設定される。同様に、車両５１０と車両５１２は、右折して別の道路５３２上を走行しており、低品質のＲＦリンクしか有さない。道路５３０以外の他の道路上で、車両５００の前方を走る車両に対するカバレッジ・リミットは、車両５１０と車両５１２との間に設定される（走行車両５００により）。その理由は、車両５１０は走行車両５００と通信できるが、車両５１２は走行車両５００とは通信できないからである。
【００２３】
４個の平均カバレッジ・リミットを得る手順は、次の通りである。特定の基軸車両に対し、４個のリミットの内の１個のみが関連する。その理由は、基軸車両は、同じ道路上にある走行車両の前方あるいは後方のいずれかにあるか、あるいは別の道路上の走行車両の前方あるいは後方にあるからである。走行車両が２個のＲＴＳ／ＣＴＳエリアと、２個の基軸車両を有するとすると、一方は前方に他方は後方にあり、２つの異なるリミットがフォワード・エリアとバックワード・エリアの両方に対しチェックされる。カバレッジ・リミットのチェックは次のように行われる。
（ａ）４個全てのカバレッジ・リミットを最初は０に設定する。
（ｂ）車両からの送信を受領すると、４個のカバレッジ・リミットの内の１個のみを更新する。
この更新値は、走行車両（後方又は前方）に対する受信車両（即ち、走行車両がそのビーコンを受領する車両）のロケーションに基づき、かつ走行車両に関連する道路と受信車両に関連する道路の間の類似性（同一又は別々）に基づき分類される。更新されたカバレッジ・リミットのインデックスは、「updated」として記述される。関連するカバレッジ・リミットは、次のようにして更新する。
（ｃ）カバレッジ・リミット＝カバレッジ・リミット×α＋車間距離×（１−α）
ここで「車間距離」は、走行車両と受信車両の間の距離である。
αは次のように決められる。
（ｉ）カバレッジ・リミットが車間距離よりも大きな場合：
ＢＥＲ情報が得られた場合には、α＝ｍｉｎ（１，１６×ＢＥＲ＋０．２５）、それ以外は０．９を用いる。この目的は、ＢＥＲが低い時にはカバレッジ・リミットを増加させ、ＢＥＲが高い時には同一の場所でカバレッジ・リミットをキープする。
（ｉｉ）カバレッジ・リミットが車間距離よりも小さい場合：
ＢＥＲ情報が得られた場合には、α＝ｍａｘ（０，１−４×ＢＥＲ）、それ以外は０．１を用いる。この目的は、上記の場合とは逆であり、ＢＥＲが高い時にはカバレッジ・リミットを減少させ、ＢＥＲが低い時には同一の場所でカバレッジ・リミットをキープする。
【００２４】
カバレッジ・リミットの計算は、走行車両の位置（即ち、新たなＧＰＳ読み取り値の到着時）と、時間（即ち、全ての車両からのビーコンを受領する１００ミリ秒サイクルの完了時）の変化に対し、連続性を維持しなければならない。最終的に実際のカバレッジ・リミットは、前のリミットの割合に設定される。例えば１００ミリ秒毎に９５％である。これは、主な目的が高速の反応を提供するためである。例えば通信をブロックするトラックは、カバレッジ・リミットに直ちに影響するようにしなければならない。
【００２５】
ローカル・マップ創設（形成）（ステップ４００）
マップの創設において、道路は、単純化するために、直線状のチェーンに変換される。これはマップのデータベースでは一般的である。この場合、チェーンは「ポリライン（polyline）」又は「ポリノバル・チェーン（polynobal chain）」と称する。交差点は、３本以上の道路の接続点として定義される。従来の（一台の走行車両による）マップ形成技術は、一台の車両からのローカルＧＰＳの読み取り情報を用い、マップのデータベースをシーケンシャルに構築する。しかし複数の車両からの送信によるダイナミック・ローカルマップの形成は、それとは異なりより複雑である。一台の車両のローカルＧＰＳの読み取り情報を用いる代わりに、複数台の車両（最大で２００台の車両）からの同時の位置情報を用い、従来のマップ形成とは対称的に、無線で受領したロケーションデータはシーケンシャルではない。これはローカルマップの形成に影響を及ぼす。例えば車両が前方に走行中には、この車両は、走行道路で以前には検知しなかった車両からのシーケンシャルな情報を受信する。このシーケンシャルな情報は、走行道路の連続性を記述する。しかし、対向する道を反対方向に走る車両から受領した情報は、走行車両により非シーケンシャルに発見される。ある道路は、ＲＦ受信が限られているために、完全には記述できない。例えば、交差する道路は一部しか検知できない。車両は、時々意外な動きをするため、このような事象（車両の動き）は、ローカルマップの形成に混乱を及ぼす。様々な車両から受領したビーコンのＧＰＳエラーは、互いに相関関係がない。このことを考慮に入れなければならない。しかしこのことは、一台の車両を用いた標準のマッピングの場合には当てはまらない。これらの全ては、マップ形成の革新的なアルゴリズムを必要とする。
【００２６】
図６に、ダイナミック・ローカルマップの形成のステップの詳細を示す。各車両に対する現在のＧＰＳ座標軸と速度ベクトルがそれぞれの車両のビーコンで送信される（ステップ６００）。この情報はＲＦカバレッジ・リミット内いる全ての車両が受領できる。ステップ６０４において、走行車両で解析されたビーコン情報を有する車両は、いずれか既知の道路にマッピングされているかのチェックが行われる。既知の道路が見い出せない場合には、ステップ６０６で、車両の方向が一定か否かあるいは最後に分かっていた前の方向から新たな方向に変更したかのチェックが行われる。例えば、前の道路上でマッピングされた最後の位置までの距離がある値（例、１２ｍ）を越えてるか否かのチェックが行われる。新たな道路がローカルマップデータベース内で形成される（ステップ６０８）。新たな交差点がローカルマップデータベース内に形成される（ステップ６１８）。
【００２７】
既知の道路がステップ６０４で見出されると、ステップ６１０で、解析されたビーコン情報を有する車両に関連する道路は、前の道路マッピングから変化したか否かのチェックが行われる。道路が変化している場合には、操作はステップ６１６に更に進み、元の道路と新たな道路を含む交差点が規定されているかのチェックが行われる。規定されている場合には、操作は終了する。規定されていない場合には、交差点がステップ６１８で形成される。ステップ６１０で道路が変わっていない場合には、道路の長さがステップ６１２で更新される。道路の延長境界に関するのチェックがステップ６１４で行われる。道路の延長が、同一長さ同一高さの交差する道路を越える場合には、交差点がステップ６１８で規定される。
【００２８】
ステップ６１２，６１４で説明したように、道路の特性が、受信した送信情報に基づいてダイナミックに調整される。これに対し、従来のマップ形成のアルゴリズムは、全ての特性が既知になった後、オフラインで計算される。
【００２９】
ＲＴＳ／ＣＴＳハンドシェイクに対する最適エリアの選択（ステップ４０４）。
次の表は、周囲の環境を考慮しながら、ＲＴＳ／ＣＴＳハンドシェイク用の最適のエリアの概要を示す。用語「アヘッド」「フォワード」「ビハインド」「バックワード」は、走行車両に対する地理的な方向或いは位置を示す。より詳細なシナリオは、交通規則、自動車メーカーからの要件に基づいて、付加することもできる。
【００３０】
ローカルマップ上の走行車両のロケーション 最適ＲＴＳ／ＣＴＳエリア
高速道路又は一方通行の道路上の走行 道路前方の走行状態を通知するために 走行車両のバックワード
交差点内 左折補助のために反対側の道路上にあ る走行車両のフォワードエリアと走行 車両のバックワード
交差点へ近づく 交差点の中央点の中心にあるフォワー ドエリアと走行車両のバックワード
環状交差点へ近づく 環状交差点に接続される第１道路の中 心のフォワードエリアと走行車両のバ ックワード
合流又は高速道路のインターチェンジに近づく 並列道路の合流点の中心にあるフォワ ードエリアと走行車両のバックワード
立体交差を通過する 走行車両、好ましくは立体交差に近い 車両のバックワード
カバレッジのないポイントへ近づく カバレッジ・リミットの直前のフォワ ードエリア
カバレッジのないポイントから離れる カバレッジ・リミットの直前のバック ワードエリア
【００３１】
バックワードＲＴＳ／ＣＴＳハンドシェイクエリア選択
図７を参照して、バックワードＲＴＳ／ＣＴＳハンドシェイクエリア選択を説明する。ステップ７００は、最適ＲＴＳ／ＣＴＳエリアを速度に基づいて決定する。高速時においては、ビーコンの受領領範囲は後方に伸びる。ハンドシェイクエリアは、走行車両の背後で選択され、所定の期間（例、４秒）で道路上の最高速の車両が通過する距離に等しい。ステップ７０２は、ステップ７００で計算された最適エリアと、道路上を通る最近距離の陸橋までの距離との間の最小化計算を実行する。即ち、走行車両に最も近いエリアを選択する。例えば、最適エリアが走行車両の後方１００ｍであるが、車両は現在の位置の前５０ｍにある橋を通過しているとすると、最適エリアは、ブリッジの周りの車両の後方５０ｍに設定される。ステップ７０４は、ステップ７０２で計算されたエリアと、カバレッジ・リミットの間の更なる最小化計算を実行する。
【００３２】
フォワードＲＴＳ／ＣＴＳハンドシェイクエリア選択
図８を参照して、フォワードエリアの選択を説明する。第１ステップ８００は、道路が中央分離帯のない双方向通行道路であるか否かをチェックする。反対方向の道路は、双方向通行道路として分類するために特定される必要がある。反対側の道路までの距離を測定し、それがしきい値よりも大きい場合には、中央分離帯があると見なされる。中央分離帯のない双方向通行道路が規定されない場合（ステップ８００でのＮｏの場合）、チェックがステップ８０２で行われる。このチェックは、交わる点（crossing point）が前方にあるかを見る。交わる点が見出せない場合には、ステップ８０６はフォワードへの送信の必要性がないと決定する。交わる点が前方に見出される場合には、ステップ８０４は、ＲＴＳ／ＣＴＳエリアを前方の交わる点に設定する。
【００３３】
中央分離帯のある双方向通行道路が定義されると（ステップ８００でＹｅｓの場合）、ステップ８０８は、ＲＴＳ／ＣＴＳのエリアを設定（決定）する。この設定は、速度に依存するが一定値でもよい。ステップ８１０において、交差点が存在するか否かがチェックされる。交差点が存在する場合には、最適エリアは、交差点に応じて設定される。これはステップ８１２で説明する。ステップ８１２においては、カバレッジ・リミットが計算されたエリアと比較され、カバレッジ・リミットが短い場合はそれが選択される。
【００３４】
交差点は３つのタイプに分類される。即ち合流と、環状交差点と、通常の交差点である。
合流点：合流点は走行車両が４５度以下の角度で別の道路と交わるものに定義される。合流点は３つの道路部分を接続する。しかしより多くの数の道路があってもよい。この場合全ての角度は４５度以下である、即ち１３５（１８０−４５）度以上である。
環状交差点：環状交差点は、複数本の交差点が互いに近接している場合に定義される。一般的に、一方向の道路が交差点の間を回る。
通常の交差点：上記２つの定義に入らない全ての交差点を言う。
【００３５】
交差点のタイプに依存して、ＲＴＳ／ＣＴＳを選択する。
交差点においては、交差点の中にある車両が、基軸車両として選択される。交差点内に車両がない場合には、交差する道路上の交差点近傍の車両、あるいは最後の手段として、同一の道路上にある交差点近傍の車両が基軸車両として好ましい。
合流点においては、両方の道路が同一の速度（即ち、道路上を走る車両の平均速度）を有する場合は、並行する道路の交差点から合流する道路の距離に等しい距離にあるエリアが選択される。
環状交差点においては、第１出口と第２出口の間のエリアが、ＲＴＳ／ＣＴＳエリアとして、好ましい。車両がこの好ましいエリアにない場合、環状交差点内の車両が、機軸車両として、選択される。
【００３６】
ＲＴＳ／ＣＴＳハンドシェイク実行
以下の説明は、ステップ５０６の詳細である。
【００３７】
送信機能
図９を参照して、ＲＴＳ／ＣＴＳハンドシェイクの送信機能について説明する。ある車両を基軸車両としてステップ９００で選択する。ステップ５０４で決定された最適のＲＴＳ／ＣＴＳエリアの中心にある第１の基軸車両が、選択される。ＲＴＳメッセージが、ステップ９０２で走行車両により送信される。ハンドシェークは、最大パワー制御を用いて行われ、これによりＲＦ範囲を最大にする。別の構成として、パワー制御スキームを適用してブロードキャスト送信のパワーを制限する。最低の変調インデックスが通常用いられる。但し、これは、同一道路上の車両へのバックワード送信と、道路が一方通行の時と、高い変調は受信機能を損なうことなく用いられる場合を除く。
【００３８】
ＣＴＳメッセージが、選択された第１の基軸車両からステップ９０４でうまく受領されると、データは、走行車両によりステップ９０６で放送され、そこで操作は終了する。ＣＴＳメッセージをステップ９０４でうまく受領できない場合には、ステップ９０８は、ランダムな時間遅延を選択する。この選択は、走行車両に近い複数の車両に基づいて行われる。標準では、ビーコン送信は１００ミリ秒以内に終了しなければならないと規定する。ランダムな時間遅延の選択を高くすると、次の試みの際更なる衝突の可能性を減らすことができる。その理由は、様々なステーションでの試みがより均一に分布するからである。実験例では、ランダムな時間遅延の値は、５ミリ秒から２０ミリ秒が、最適の性能を発揮できる。送信の回数はステップ９１０でチェックされる。ある数（例えば３回）の送信が行われると、データは、ステップ９１２でＲＴＳ／ＣＴＳハンドシェイクを実行することなく送信される。３回の送信が行われない場合には、別の車両が次の試みのために基軸車両としてステップ９１４で選択され、ステップ９０２に戻り、操作は終了する。
【００３９】
ＲＴＳ／ＣＴＳハンドシェイクは、次の２つの理由で失敗する。第１の理由は、選択された機軸車両近傍の送信を、ＲＴＳを実行するステーションが受領することである。第２の理由は、無線リンクの性質に依存する。両方の理由とも、ハンドシェークの失敗後、別の基軸車両を選択すると利点があるが、これは、複数個の車両が、最適のＲＴＳ／ＣＴＳエリア内にある場合である。
【００４０】
受信機能
図１０を参照して、ＲＴＳメッセージを受領するステーションの受信機能を説明する。この操作は、ステップ１０００で、ある長さのＲＴＳメッセージを持つパケットを各車両が受領した時に、始まる。特にそこに向けられたＲＴＳメッセージを受領した車両が、機軸車両となる。各パケットは、ステップ１００２でチェックされる。パケットが無効な場合（これは、ＦＣＳ（Frame Check Sequence）値にマッチしないことにより示される）、あるいはパケットが基軸車両以外のステーションに帰属する場合には、本発明のプロセスは、ステップ１００４にジャンプする。ステップ１００４において、基軸車両を除く車両は送信しないままである（remain silent）。ある場合には、車両は、受領したＲＴＳメッセージが無効の場合でさえ、送信しない（サイレントである）。標準８０２．１１は、有効なパケットのみを対象にしている。ここに記載したメカニズムを除いて、標準８０２．１１機構は、パケットのコンテンツをポジティブにパーディングせずに（without psoitive parsing of packet content）動作する。この伝送を回避することにより、他の送信を遮断するリスクが排除される。
【００４１】
無線信号は２つのしきい値を有する。干渉のしきい値と受信のしきい値（パワー受信しきい値）である。ＲＴＳパケットが基軸車両に向けられたものの場合には、本発明のプロセスはステップ１００６から継続する。リンクがビジーでない場合には、ＣＴＳメッセージはステップ１００８に戻される。データは戻るものとする。このデータの有効性はステップ１０１６でチェックされる。チェックが失敗するかあるいはＢＥＲが構築可能レベル（例えば０．０５）以下の場合には、データは無効と宣言される。ＢＥＲの条件付けは革新的である。各パケットはViterbi符号で保護される。多くのエラーを有するパケットは、Viterbi符号化の修正機能を経た後受け入れられるが、走行車両から相当距離離れた位置にあるステーションでは殆ど拒絶される。この場合再送信を強化することにより、データを受領する他のステーションの確率が増加する。選択的事項として、再送信は、未請求のＣＴＳメッセージをステップ１００８で送信することにより、強制的に行われる。このステップは革新的であるが、その理由は、ＲＴＳ／ＣＴＳハンドシェイクを用いて、ブロードキャストパケットを受領確認する方法を確立するからである。しかしこれは、標準８０２．１１ベースのネットワークでは、今のところ存在していない。
【００４２】
リンクが、ステップ１００６でビジーな場合には、操作はステップ１０１０から再開する。機軸ステーションは、リンクがフリーになるまで待機する。この時間の間、ステーションがＲＴＳメッセージを別のステーションに送信したことが、検知されると（ステップ１０１２）、この操作終了する。それ以外には未請求のＣＴＳメッセージは、ステップ１０１４で送信される。この革新的なステップにより、チャネル資源の最適な割り当てが提供できる。、これは、リンクが利用できるようになった時に、再送信をする前の失敗したリクエストをスケジューリングすることにより、行われる。
【００４３】
使用例
図１を参照して、ローカルマップとＲＴＳ／ＣＴＳハンドシェイクを用いて車両のブロードキャストの実施例を説明する。車両１１００は、ＲＴＳメッセージを基軸車両１１０２の方向に送信する。この基軸車両１１０２は、ＣＴＳメッセージで応答する。これにより、車両１１００，１１０２の間のＲＴＳ／ＣＴＳハンドシェイクを確立する。このメッセージ交換を受信している近傍にある他の全ての車両は、ＲＴＳ／ＣＴＳメッセージで示された時間の間、サイレント状態でいる（送信しない）ことが要求される。これにより、「クリアされた領域」１１１０が形成される。これはオーバーラップしたエリアを含む２つの円からなる組み合わされたエリアで示されている。車両１１０４は干渉しないがその理由は、車両１１０４は車両１１０２からのＣＴＳメッセージを受領しているからである。車両１１０６も干渉しない。
【００４４】
交差点におけるより重大な問題が、交差点内の車両をＲＴＳ／ＣＴＳハンドシェイクのレスポンダーとして選択することにより、解決できる。この車両は、ハンドシェーク内のこの送信のためにアクセスポイントとして動作し、複数の車両の間をコーディネートする。図１２は図２に類似する。同図において、基軸車両１２１０は、ＲＴＳメッセージを受領し、ＣＴＳメッセージで応答する。車両１２１０は、交差点内にある全ての車両（１２００，１２０２，１２０４，１２０６，１２０８）に対する最適の無線パスを有する。この送信信号を受領する全ての車両（即ち１２００，１２０２，１２０４，１２０６，１２０８）は、サイレントを保つ。
【００４５】
本発明は、あらゆる放送送信（伝送）に適用可能である。例えば、ビーコン送信、ジェオキャスト放送送信、ＩＥＥＥ１６０９サービス・創設メッセージにも適用可能である。
【００４６】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。
【符号の説明】
【００４７】
１１０ 道路
１００，１０２，１０４，１０６ 車両
２００，２０２，２０４，２０６，２０８，２１０ 車両
２２０ 交差点
２２２，２２４ 道路
５００，５１０，５１２ 走行車両
５０２ トラック
５２０ カバレッジ・リミット
５３０ 道路
図３
３００：ローカル・マップを創設する
３０２：ＣＴＳ／ＲＴＳハンドシェイクの後に放送パケットを送信する
図４
４００：ダイナミック・ローカル・マップを創設する
４０２：ＲＦカバレッジ・リミットを学習する
４０４：ＲＴＳ／ＣＴＳ用のエリアを選択する
４０６：そのエリアから基軸車両を選択する
４０８：車両が見出されたか？
４１０：選択された基軸車両とのＲＴＳ／ＣＴＳハンドシェイクの実行後、放送データを送信する
４１２：ＲＴＳ／ＣＴＳ用の目標エリアを拡張する
終了
図５
５００ 走行車両
５０２ 通信をブロックする車両
５０４，５０８，５１２ 通信不可車両
５０６、５１０ 通信可車両
５２４ 走行車両の前のカバレッジ・リミット
５２２ 別の道路上の走行車両の前のカバレッジ・リミット
５２０ 走行車両の後ろのカバレッジ・リミット
５３２ 別の道路
図６
６００：ＧＰＳ座標軸と速度ベクトルを受領する
６０４：車両は既知の道路にマップされているか？
６０６：車両の走行方向は維持され、前位置までの距離は１２ｍを越えるか？
６０８：新たな道路を創設する
６１０：道路は変わったか？
６１２：道路長さを更新する
６１４：延長した道路はクロスポイントを越えたか？
６１６：交差点が定義されたか？
６１８：新たな交差点を創設する
終了
図７
７００：速度に応じてエリアを設定する
７０２：前のエリアの最小値と最近交差したブリッジを選択する
７０４：前のエリアの最小値とカバレッジ・リミットを選択する
図８
８００：双方通行の道で分離体があるか？
８０２：交差点が前にあるか？
８０４：エリアを渋滞ポイントに設定する
８０６：前向への送信はない
８０８：速度に応じてエリアを設定する
８１０：交差点が前にあるか？
８１２：エリアを渋滞ポイントに設定する
８１４：前のエリアの最小値とカバレッジ・リミットを選択する
図９
９００：エリア内で車両を選択する
９０２：ＲＴＳを送信する
９０４：ＣＴＳを受領したか・
９０６：データを送信する
９０８：ランダムな遅延時間を選択する
９１０：試みが３回成されたか？
９１２：データを送信する
９１４：エリア内で他の車両を選択する
終了
図１０
１０００：ＲＴＳ長さでパケットを受領したか？
１００２：ＲＴＳに応答すべきか？
１００４：沈黙を守る
１００６：リンクはビジーか？
１００８：ＣＴＳに応答する
１０１０：リンクが空くまで待つ
１０１２：他のステーションへのＲＴＳは、待機中に受領したか？
１０１４：未申請のＣＴＳを送る
１０１６：悪いＦＣＳ又はしきい値以下のＢＥＲでデータを受領したか？
１０１８：未申請のＣＴＳを送る
終了
【特許請求の範囲】
【請求項１】
車両が通行する環境においてブロードキャスト伝送を行う方法において、
（ａ）ダイナミック・ローカルマップを提供するステップと、
（ｂ）前記ダイナミック・ローカルマップとＲＴＳ／ＣＴＳハンドシェイクを用いるステップと、
前記（ｂ）ステップにより、他の車両へデータをブロードキャストする
を有する
ことを特徴とする車両が通行する環境においてブロードキャスト伝送を行う方法。
【請求項２】
前記（ａ）ステップは、（ａ１）走行車両でダイナミック・ローカルマップを徐々に生成するステップを含む
ことを特徴とする請求項１記載の方法。
【請求項３】
前記（ａ）ステップは、（ａ２）ナビゲーション・システムから前記ダイナミック・ローカルマップを獲得するステップを含む
ことを特徴とする請求項１記載の方法。
【請求項４】
（ｃ）無線カバレッジ・リミットを決定するステップと、
（ｄ）前記無線カバレッジ・リミットを、前記ダイナミック・ローカルマップと前記ＲＴＳ／ＣＴＳハンドシェイク信号と共に用いるステップと、
前記（ｄ）ステップにより、データをブロードキャストする
を更に有する
ことを特徴とする請求項１記載の方法。
【請求項５】
前記（ａ１）ステップは、（ａ１１）ＧＰＳ情報を用いて前記ダイナミック・ローカルマップを形成するステップを含む、
前記ＧＰＳ情報は、複数の各車両から送信された複数のビーコンで受領され、
前記各ビーコンは、特定の車両に関連する
ことを特徴とする請求項２記載の方法。
【請求項６】
前記（ｃ）ステップは、（ｃ１）前記ＲＦカバレッジ・リミットを繰り返し学習するステップを含む
ことを特徴とする請求項４記載の方法。
【請求項７】
前記（ｂ）ステップは、
（ｂ１）ＲＴＳ／ＣＴＳエリアを決定するステップと、
（ｂ２）前記ＲＴＳ／ＣＴＳエリア内の基軸車両との前記ＲＴＳ／ＣＴＳハンドシェイクを実行するステップと
を有する
ことを特徴とする請求項１記載の方法。
【請求項８】
車両が通行する環境においてブロードキャスト伝送を行う方法において、
（ａ）走行車両にダイナミック・ローカルマップを提供するステップと、
（ｂ）基軸車両を選択するステップと、
（ｃ）前記走行車両と基軸車両との間で、ＲＴＳ／ＣＴＳハンドシェイクを実行するステップと、
前記ＲＴＳ／ＣＴＳハンドシェイクにより、前記走行車両が他の車両にデータをブロードキャストできるようになる
を有する
ことを特徴とする車両が通行する環境においてブロードキャスト伝送。
【請求項９】
前記（ｂ）ステップは、（ｂ１）前記基軸車両を前記ダイナミック・ローカルマップに基づいて選択するステップを含む
ことを特徴とする請求項８記載の方法。
【請求項１０】
前記（ｂ）ステップは、（ｂ１）前記基軸車両を前記ダイナミック・ローカルマップと無線カバレッジ・リミットに基づいて選択するステップを含む
ことを特徴とする請求項８記載の方法。
【請求項１１】
前記（ａ）ステップは、（ａ１）走行車両でダイナミック・ローカルマップを徐々に生成するステップを含む
ことを特徴とする請求項８記載の方法。
【請求項１２】
前記（ａ）ステップは、（ａ２）ナビゲーション・システムから前記ダイナミック・ローカルマップを獲得するステップを含む
ことを特徴とする請求項８記載の方法。
【請求項１３】
前記（ａ１）ステップは、（ａ１１）ＧＰＳ情報を用いて前記ダイナミック・ローカルマップを形成するステップを含む、
前記ＧＰＳ情報は、複数の各車両から送信された複数のビーコンで受領され、
前記各ビーコンは、特定の車両に関連する
ことを特徴とする請求項１１記載の方法。
【請求項１４】
前記（ｃ）ステップは、（ｃ１）前記無線カバレッジ・リミットを繰り返し学習するステップを含む
ことを特徴とする請求項１０記載の方法。
【請求項１５】
車両が通行する環境においてブロードキャスト伝送を行うシステムにおいて、
（ａ）走行車両と、
（ｂ）基軸車両と、
（ｃ）前記走行車両と基軸車両との間で、ＲＴＳ／ＣＴＳハンドシェイク実行する手段と、
前記ＲＴＳ／ＣＴＳハンドシェイクにより、前記走行車両がデータをブロードキャストできるようになる
を有する
ことを特徴とする車両が通行する環境においてブロードキャスト伝送を行うシステム。
【請求項１】
車両が通行する環境においてブロードキャスト伝送を行う方法において、
（ａ）ダイナミック・ローカルマップを提供するステップと、
（ｂ）前記ダイナミック・ローカルマップとＲＴＳ／ＣＴＳハンドシェイクを用いるステップと、
前記（ｂ）ステップにより、他の車両へデータをブロードキャストする
を有する
ことを特徴とする車両が通行する環境においてブロードキャスト伝送を行う方法。
【請求項２】
前記（ａ）ステップは、（ａ１）走行車両でダイナミック・ローカルマップを徐々に生成するステップを含む
ことを特徴とする請求項１記載の方法。
【請求項３】
前記（ａ）ステップは、（ａ２）ナビゲーション・システムから前記ダイナミック・ローカルマップを獲得するステップを含む
ことを特徴とする請求項１記載の方法。
【請求項４】
（ｃ）無線カバレッジ・リミットを決定するステップと、
（ｄ）前記無線カバレッジ・リミットを、前記ダイナミック・ローカルマップと前記ＲＴＳ／ＣＴＳハンドシェイク信号と共に用いるステップと、
前記（ｄ）ステップにより、データをブロードキャストする
を更に有する
ことを特徴とする請求項１記載の方法。
【請求項５】
前記（ａ１）ステップは、（ａ１１）ＧＰＳ情報を用いて前記ダイナミック・ローカルマップを形成するステップを含む、
前記ＧＰＳ情報は、複数の各車両から送信された複数のビーコンで受領され、
前記各ビーコンは、特定の車両に関連する
ことを特徴とする請求項２記載の方法。
【請求項６】
前記（ｃ）ステップは、（ｃ１）前記ＲＦカバレッジ・リミットを繰り返し学習するステップを含む
ことを特徴とする請求項４記載の方法。
【請求項７】
前記（ｂ）ステップは、
（ｂ１）ＲＴＳ／ＣＴＳエリアを決定するステップと、
（ｂ２）前記ＲＴＳ／ＣＴＳエリア内の基軸車両との前記ＲＴＳ／ＣＴＳハンドシェイクを実行するステップと
を有する
ことを特徴とする請求項１記載の方法。
【請求項８】
車両が通行する環境においてブロードキャスト伝送を行う方法において、
（ａ）走行車両にダイナミック・ローカルマップを提供するステップと、
（ｂ）基軸車両を選択するステップと、
（ｃ）前記走行車両と基軸車両との間で、ＲＴＳ／ＣＴＳハンドシェイクを実行するステップと、
前記ＲＴＳ／ＣＴＳハンドシェイクにより、前記走行車両が他の車両にデータをブロードキャストできるようになる
を有する
ことを特徴とする車両が通行する環境においてブロードキャスト伝送。
【請求項９】
前記（ｂ）ステップは、（ｂ１）前記基軸車両を前記ダイナミック・ローカルマップに基づいて選択するステップを含む
ことを特徴とする請求項８記載の方法。
【請求項１０】
前記（ｂ）ステップは、（ｂ１）前記基軸車両を前記ダイナミック・ローカルマップと無線カバレッジ・リミットに基づいて選択するステップを含む
ことを特徴とする請求項８記載の方法。
【請求項１１】
前記（ａ）ステップは、（ａ１）走行車両でダイナミック・ローカルマップを徐々に生成するステップを含む
ことを特徴とする請求項８記載の方法。
【請求項１２】
前記（ａ）ステップは、（ａ２）ナビゲーション・システムから前記ダイナミック・ローカルマップを獲得するステップを含む
ことを特徴とする請求項８記載の方法。
【請求項１３】
前記（ａ１）ステップは、（ａ１１）ＧＰＳ情報を用いて前記ダイナミック・ローカルマップを形成するステップを含む、
前記ＧＰＳ情報は、複数の各車両から送信された複数のビーコンで受領され、
前記各ビーコンは、特定の車両に関連する
ことを特徴とする請求項１１記載の方法。
【請求項１４】
前記（ｃ）ステップは、（ｃ１）前記無線カバレッジ・リミットを繰り返し学習するステップを含む
ことを特徴とする請求項１０記載の方法。
【請求項１５】
車両が通行する環境においてブロードキャスト伝送を行うシステムにおいて、
（ａ）走行車両と、
（ｂ）基軸車両と、
（ｃ）前記走行車両と基軸車両との間で、ＲＴＳ／ＣＴＳハンドシェイク実行する手段と、
前記ＲＴＳ／ＣＴＳハンドシェイクにより、前記走行車両がデータをブロードキャストできるようになる
を有する
ことを特徴とする車両が通行する環境においてブロードキャスト伝送を行うシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公表番号】特表２０１１−５２７８４７（Ｐ２０１１−５２７８４７Ａ）
【公表日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願番号】特願２０１１−５１７２７３（Ｐ２０１１−５１７２７３）
【出願日】平成２１年３月１７日（２００９．３．１７）
【国際出願番号】ＰＣＴ／ＩＢ２００９／０５１１１１
【国際公開番号】ＷＯ２０１０／００４４４３
【国際公開日】平成２２年１月１４日（２０１０．１．１４）
【出願人】（５１１００４５９７）オートトークス エルティディ (2)
【Ｆターム（参考）】
【公表日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願日】平成２１年３月１７日（２００９．３．１７）
【国際出願番号】ＰＣＴ／ＩＢ２００９／０５１１１１
【国際公開番号】ＷＯ２０１０／００４４４３
【国際公開日】平成２２年１月１４日（２０１０．１．１４）
【出願人】（５１１００４５９７）オートトークス エルティディ (2)
【Ｆターム（参考）】
[ Back to top ]