IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハーの特許一覧

特許7536887接近する緊急車両について道路車両に警告する方法およびシステム
<>
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図1
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図2
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図3
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図4
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図5
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図6
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図7
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図8
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図9
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図10
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図11
  • 特許-接近する緊急車両について道路車両に警告する方法およびシステム 図12
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-09
(45)【発行日】2024-08-20
(54)【発明の名称】接近する緊急車両について道路車両に警告する方法およびシステム
(51)【国際特許分類】
   G08G 1/09 20060101AFI20240813BHJP
【FI】
G08G1/09 F
【請求項の数】 15
(21)【出願番号】P 2022565665
(86)(22)【出願日】2020-04-27
(65)【公表番号】
(43)【公表日】2023-06-02
(86)【国際出願番号】 EP2020061652
(87)【国際公開番号】W WO2021219196
(87)【国際公開日】2021-11-04
【審査請求日】2023-02-08
(73)【特許権者】
【識別番号】517451940
【氏名又は名称】エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】ギルマ・マムイェ・イルマ
(72)【発明者】
【氏名】ファキアー・ザラール・ユーサフ
【審査官】佐藤 吉信
(56)【参考文献】
【文献】米国特許出願公開第2004/0246144(US,A1)
【文献】特開2017-195556(JP,A)
【文献】特開2017-162359(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G08G 1/00-99/00
(57)【特許請求の範囲】
【請求項1】
目標オブジェクト(TO)接近する基準オブジェクト(RO)ついて警告する方法であって、
後方状況認識機能(BSAF)アプリケーション(1)によって、RO関連状況情報を含む前記ROからのRO通知(RON)メッセージを受信するステップと、
前記BSAFアプリケーション(1)によって、前記ROの現在位置と前記ROの目的地を指定する目的地オブジェクト(DO)との間のいくつかの地理セクタ(GS)セグメントを含むGSエリアを生成するステップと、
前記BSAFアプリケーション(1)によって、前記GSエリアの前記GSセグメントの各々について、前記GSセグメントのうちのそれぞれ1つにおける前記ROの到着予定時刻(ETA)を計算するステップであって、前記GSセグメントの計算された入口ETA値と出口ETA値との間の差が事前定義されたしきい値を超える場合、前記GSセグメントのサイズが設定可能な関数に従って変更される、ステップと、
前記計算されたGSセグメント固有のETA値を前記TOに伝達するステップと
を含む、方法。
【請求項2】
前記GSエリアがGSチェーンであり、
前記BSAFアプリケーション(1)によって、前記ROと前記DOとの間の前記GSチェーンをオンデマンドで生成するステップをさらに含み、前記GSチェーンのGSセグメントが、前記DOに向かう前記ROの移動に関連して連続的に削除される、
請求項1に記載の方法。
【請求項3】
前記GSエリアのGSセグメントの数、ならびにそれらのそれぞれの形状およびサイズが、実際のもしくは予測される交通状況、道路の状態および/もしくは形状、ならびに/または他の外部要因に基づいて動的に調整される、請求項1または2に記載の方法。
【請求項4】
前記BSAFアプリケーション(1)によって、外部データベースから取得した前記GSセグメントの場所に関する過去の交通データに基づいて、前記GSセグメントの入口に向かう前記GSエリアのGSセグメントの前記ETA値と、前記GSセグメントの出口に向かう前記GSエリアのGSセグメントの前記ETA値とを計算するステップをさらに含む、請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記GSエリアの異なるGSセグメントの前記サイズを変更するために異なる関数が使用される、請求項1に記載の方法。
【請求項6】
前記RONメッセージが、前記ROのセンサユニットから受信した前記情報に基づいて前記ROのオンボードユニット(OBU)によって生成され、前記RONメッセージが、協調認識メッセージ(CAM)として、または分散型環境通知メッセージ(DENM)として実現され、請求項1~5のいずれか一項に記載の方法。
【請求項7】
前記RONメッセージの周期性が、前記ROの速度に関連して動的に調整され、前記ROの前記速度が速いほど前記RONメッセージの送信頻度が高くなる、請求項1から6のいずれか一項に記載の方法。
【請求項8】
前記GSセグメント固有のETA値が、分散型環境通知メッセージ(DENM)として実現されたTO通知(TON)メッセージ内に符号化される、請求項1から7のいずれか一項に記載の方法。
【請求項9】
前記GSエリアの前記異なるGSセグメントに関する前記計算されたETA値および通知が、少なくとも2つのキーを含むマルチキーマップとして実現されたベクトルとして符号化され、前記少なくとも2つのキーのうちの第1のキーが前記ROの移動方向を表し、前記少なくとも2つのキーのうちの第2のキーが前記GSエリアの前記GSセグメントを識別する、請求項5に記載の方法。
【請求項10】
前記TOが道路車両であり、前記ROが緊急車両である、請求項1~9のいずれか一項に記載の方法。
【請求項11】
請求項1から10のいずれか一項に記載の方法の実行のための、前記TO接近する前記ROについて警告するシステムであって、
RO関連状況情報を含む前記ROからのRO通知(RON)メッセージを受信することと
前記ROの現在位置と前記ROの目的地を指定する目的地オブジェクト(DO)との間のいくつかの地理セクタ(GS)セグメントを含むGSエリアを生成することと
前記GSエリアの前記GSセグメントの各々について、前記GSセグメントのうちのそれぞれ1つにおける前記ROの到着予定時刻(ETA)を計算することであって、前記GSセグメントの計算された入口ETA値と出口ETA値との間の差が事前定義されたしきい値を超える場合、前記GSセグメントのサイズが設定可能な関数に従って変更される、ことと
前記計算されたGSセグメント固有のETA値の前記TOへの伝達を提供することと
を行うように構成される後方状況認識機能(BSAF)アプリケーション(1)を備える、システム。
【請求項12】
前記BSAFアプリケーション(1)が、物理的または仮想計算インフラストラクチャ上でホストされる、コンテナまたはVMベースのマルチアクセスエッジコンピューティング(MEC)アプリケーションとして実装される、請求項11に記載のシステム。
【請求項13】
前記MECサーバ(2)が、道路状況および/または交通状況に関する更新された情報を前記BSAFアプリケーション(1)に提供するように構成される外部交通情報および管理システム(4)に接続された状況認識機能(3)を備える、請求項12に記載のシステム。
【請求項14】
前記MECサーバ(2)が、モバイルネットワーク通信インフラストラクチャのRAN(6)から道路状況および/または交通状況に関する更新された情報を受信し、前記情報を前記BSAFアプリケーション(1)に提供するように構成される無線ネットワーク情報システム(RNIS)サービス(5)を備える、請求項12また13に記載のシステム。
【請求項15】
前記BSAFアプリケーション(1)が前記ROまたは個々のTO上でホストされる、請求項11に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本出願につながるプロジェクトは、贈与契約第825012号の下で欧州連合のHorizon 2020研究およびイノベーションプログラムから資金を受けている。
【0002】
本発明は、接近する基準オブジェクトRO、特に緊急車両について、目標オブジェクトT0、特に道路車両に警告する方法およびシステムに関する。
【背景技術】
【0003】
緊急事態の場合には、緊急対応車両(例えば、救急車、消防車、パトカーなど)は、しばしば、イベントスポットに向かう途中で遭遇する交通によって妨げられる。既存の緊急車両(EmV)は、前方の交通に事前警告するために、点滅灯と大音量のサイレンとを備えているので、道路上の車両は、運転者の可聴範囲および視覚範囲内にいる場合にのみ、緊急対応者の存在に気づくようになる。しかしながら、これは、特に交通量の多い状況の場合、操縦スペースが限られているか、および/または運転者が大音量の音楽もしくは聴覚障害のためにサイレンを聞くことができない場合、EmVが通過するための明確な通路を作成するために協調的かつ効果的に操縦するのに十分な時間を運転者に与えない場合がある。逆に、これは、車両の運転者の間でパニックを引き起こし、EmVのせいでさらなる渋滞や事故さえ引き起こす可能性がある。そのような状況は、緊急事態に対処する際の緊急対応者の有効性を大きく損なう貴重な時間の損失を結果として生じる予測不可能な遅延を引き起こす可能性がある。
【0004】
接近する車両が前方の車両にその到着/存在を知らせるために、例えばPC5リンクを使用する直接の車両間(V2V)通信に依存することによって上記の問題に対処する解決策がすでに存在する。しかしながら、この解決策は、数百メートルの範囲内にある直接のV2V通信の限られた範囲により、緊急事態には適しておらず、したがって、接近する高速のEmVについて車両に十分な警告時間を与えない。さらに、この解決策は、EmVのルート上にない場合がある車両に対しても、EmVの到着予定時刻(ETA)の不正確な伝達を結果として生じる。この方法は、緊急事態における展開に適さないようにするセキュリティの脆弱性も有する。
【先行技術文献】
【特許文献】
【0005】
【文献】US 8,941,489 B2
【発明の概要】
【発明が解決しようとする課題】
【0006】
したがって、本発明の目的は、T0が、ROがその場所に実際に到着するよりも十分に前の特定の時点において、信頼できる方法で警告されるように、T0、特に道路車両に、接近するRO、特に緊急車両について警告する方法およびシステムを改善し、さらに開発することである。
【課題を解決するための手段】
【0007】
本発明によれば、前述の目的は、目標オブジェクトTO、特に道路車両に、接近する基準オブジェクトRO、特に緊急車両について警告する方法であって、後方状況認識機能BSAF(back-situation awareness function)アプリケーションによって、RO関連状況情報を含むROからのRO通知RONメッセージを受信するステップと、BSAFアプリケーションによって、ROの現在位置と目的地オブジェクトDOとの間のいくつかのGSセグメントを含む地理セクタGSエリアを生成し、ROの目的地を指定するステップと、BSAFアプリケーションによって、GSエリアのGSセグメントの各々について、GSセグメントのうちのそれぞれ1つにおけるROの到着予定時刻ETAを計算するステップと、計算されたGSセグメント固有のETA値をTOに伝達するステップとを含む、方法によって達成される。
【0008】
さらに、前述の目的は、目標オブジェクトTO、特に道路車両に、接近する基準オブジェクトRO、特に緊急車両について警告するシステムであって、RO関連状況情報を含むROからのRO通知RONメッセージを受信し、ROの現在位置と目的地オブジェクトDOとの間のいくつかのGSセグメントを含む地理セクタGSエリアを生成し、ROの目的地を指定し、GSエリアのGSセグメントの各々について、GSセグメントのうちのそれぞれ1つにおけるROの到着予定時刻ETAを計算し、計算されたGSセグメント固有のETA値のTOへの伝達を提供するように構成される後方状況認識機能BSAFアプリケーションを備える、システムによって達成される。
【0009】
本発明の実施形態によれば、緊急車両のルート経路上の車両を十分に前もって選択し、緊急車両のための明確な通路を協調的に作成するのに十分な時間を車両に与えるために、緊急車両の到着予定時刻(ETA)の正確な決定のための視覚可聴範囲外(BVAR(beyond-visual-audible-range))方法/システムが提供される。本発明の実施形態による重要な態様は、緊急車両のルート経路に沿った地理セクタGSの連続チェーンの動的な作成および管理である。GSセグメントのチェーンは、地理セクタGSチェーンとみなされてもよい。本発明の実施形態によれば、各地理セクタのサイズ、形状、および構成は、変化する交通/道路状況に応じて動的に調整される。それぞれの地理セクタGSについてETAが計算され、BVAR車両に早期の警告を提供するためにインフラストラクチャによってブロードキャストされる。
【0010】
本発明の実施形態は、地理セクタGSごとの正確な到着予定時刻ETA情報の導出および伝達のための、チェーン化された地理セクタGSのオンデマンドの弾力的な構成、管理、およびスライディングのための方法に関する。GSチェーンの作成は、イベントドリブンであるので、計算リソースを節約する。
【0011】
本発明の実施形態によれば、GSエリアは、ROの現在位置と目的地オブジェクトDOとの間の連続的にリンクされたいくつかのGSセグメントを含むGSチェーンの形態において構成されてもよい。
【0012】
本発明の実施形態によれば、計算されたGSセグメント固有のETA値は、TOによって受信されるべきGSチェーンのすべてのGSセグメント内のモバイルネットワークインフラストラクチャを介して伝達されてもよい。
【0013】
本発明の実施形態によれば、BSAFアプリケーションによる計算は、それぞれのGSセグメントのためのETA値を含んでもよいだけでなく、ETA値とともに伝達されてもよい他の関連する通知(例えば、適切な警告通知メッセージ)も含んでもよい。
【0014】
本発明のさらなる実施形態は、ETA値が選択された/関連する車両にどのように通知されるかのメカニズムに関する。本発明の実施形態によるシステム/方法は、地理セクタ化技法と結合された、一般に普及した通信インフラストラクチャ、特にエッジネットワークインフラストラクチャを活用する。現在の技術水準は、静的な地理フェンスに依存しており、そのカバレッジは、せいぜい拡大/縮小する場合があるが、本発明の実施形態は、地理セクタの連続的なチェーンがオンデマンドで展開されるメカニズムを提供し、チェーン内の地理セクタのサイズは、非線形であり、外部要因(時刻、交通状況、道路状況など)によって決定される。チェーン内の地理セクタセグメントは、互いに対して拡大および縮小してもよいだけでなく、時間とともにスライドもしてもよい。
【0015】
本発明の教示を有利な方法で設計し、さらに発展させるいくつかの方法が存在する。この目的のため、一方では従属請求項が参照されるべきであり、他方では例として図によって示される本発明の好ましい実施形態の以下の説明が参照されるべきである。図の助けによる本発明の好ましい実施形態の説明に関連して、本教示の一般的に好ましい実施形態およびさらなる展開について説明する。
【図面の簡単な説明】
【0016】
図1】本発明の実施形態による、先行するTOに関してROのETA値を決定する一般的な概念を示す概略図である。
図2】本発明の実施形態による、到着予定時刻、ETA、情報の導出、および伝達のための視覚可聴範囲外システムを示す概略図である。
図3】本発明の実施形態による、システムおよび方法において用いられる地理セクタGSの概念を示す図である。
図4】本発明の実施形態による、地理セクタを決定するBSAFアプリケーションのプロセスを示すフロー図である。
図5】本発明の実施形態による、システムにおいて適用される分解能係数の概念を示す概略図である。
図6】本発明の実施形態による、RONメッセージを処理するためのBSAFアプリケーションロジックを示すフロー図である。
図7】本発明の実施形態による、ETAベクトルの例を示す概略図である。
図8】本発明の実施形態による、TONメッセージを処理するためのTOにおける処理を示すフロー図である。
図9】本発明の実施形態による、GSチェーン内の弾力的な個々のGSを用いるシナリオを示す概略図である。
図10】本発明の実施形態による、GSゾーンの弾力的な変動のための関数を示す図である。
図11】本発明の実施形態による、ROのルートの交差点において警告ゾーンを有するシナリオを示す概略図である。
図12】本発明の実施形態による、到着予定時刻、ETA、情報の導出、および伝達のための視覚可聴範囲外システムを示す概略図である。
【発明を実施するための形態】
【0017】
本開示の文脈において、以下の用語が使用される。
【0018】
基準オブジェクト(RO)は、たとえば地理セクタチェーン(GSC)の形態における地理セクタエリアが展開および管理される、現在位置と目的地とを参照するオブジェクトを示す。本発明の実施形態によれば、ROは、EMVであってもよい。
【0019】
目標オブジェクト(TO)は、その場所、速度、到着予定時刻(ETA)などの、ROに関する情報を受信するオブジェクトを示す。本発明の実施形態によれば、TOは、EmVのETA情報を受信する(または提供される)ことが想定されるEmVに先行する任意の車両であってもよい。本開示において、TOおよび車両という用語は、別段の指示がない限り、互換的に使用される。
【0020】
目的地オブジェクト(DO)は、ROが到着することが想定される目的地を示す。目的地オブジェクトは、たとえばイベントの場所であってもよい静的オブジェクトであってもよく、またはROが追いつこうとしている別の車両などの移動オブジェクトであってもよい。DOが静的である場合、静的DO(SDO)と呼ばれ、DOが移動性である場合、移動DO(MDO)と呼ばれる。単純化および明確化のために、SDOおよびMDOは、特に指定または言及されない限り、単にDOと呼ばれる。
【0021】
実施形態によれば、本発明は、EmVのルート上の進行車両に警告し、EmVが妨げられずに通過するための明確な通路を作成するために運転者が適切な協調的かつ安全な行動をとるのに十分な時間を与えるために、接近するEmVのETAの安全かつ正確な通知と伝達とを十分に前もって提供する視覚可聴範囲外(BVAR)システム/方法に関する。
【0022】
本発明の実施形態によれば、後方状況認識機能(BSAF)アプリケーションと呼ばれる計算機能/アプリケーションは、正確なETAおよび/またはROに関連する他の情報(操縦推奨など)を導出するように構成され、次いでこの情報は、同じルート経路上にあるTOに向かうROのETAについてそれらのTOに通知するために、場合によっては他の情報とともにそれらのTOに伝達される。この趣旨で、以下の主な課題は、検討を必要とする。
【0023】
1.ETAの値は、変化する可能性が最も高く、一定のままではない。これは、ルート上の予想外の交通状況のためである。例えば、ROが予期しない/予想外の渋滞した区間に遭遇した場合、先に計算されたETA値は、もはや関連がない場合がある。そのような状況において、ETA値は、修正され、更新されたTOを保つために再通知されなければならない。
【0024】
2.ETAの値は、ROからの距離に応じて、前のTOごとに異なる。すなわち、ETA値は、ROからより遠い車両と比較して、ROにより近い先行するTOに対してより小さくなる。これは、図1に示すシナリオから取得されてもよく、ここで車両1(V1)、車両2(V2)、および車両3(V3)(すなわち、TO110)からのEmV(すなわち、RO100)の距離により、ETA1<ETA2<ETA3である。
【0025】
3.システム/方法の複雑さは、ルート経路上のそれぞれの先行するTOについてETAを計算し、次いで通知するために必要な場合、増加する。これは、システムがルート経路上の個々のTOを追跡し、個別の(ユニキャスト)通知を送信しなければならないことを意味する。具体的には、システムの複雑さは、
a.ルート経路上のTO(例えば、車両)の数が増加するにつれて、
b.ルート経路に入る/から出るTOの頻度が高い場合、および/または
c.先行するTOの速度/速度の大きい変動がある場合、
増加する。
【0026】
4.ルート経路上のすべてのTOがETA情報を受信する必要があるわけではない。これは、2本の道路を分離する物理的なレーンバリアを有する両面通行の高速道路の反対車線にある車両に当てはまる。システム/方法が、ETA通知メッセージを受信することに関連するTO間を区別できない場合、ETA通知メッセージを受信する関連しないTOであっても、影響を受けないレーンにおける交通を不必要に減速度せ、それによって、交通のさらなる減速および/または渋滞を引き起こす。関連しないTOの例は、DOからROに向かう方向に移動しているが、固いバリアによって分割された道路の反対側にあり、ROが使用することができない車両である。
【0027】
上記の課題を考慮して、本発明の実施形態は、それぞれのROの状態について連続的に、例えば定期的に通知されるBSAFアプリケーション構成要素を提供する。すなわち、ROは、RO通知(RON)メッセージと呼ばれる通知メッセージをBSAFエンティティに向けて定期的に送信するように構成されてもよい。RONメッセージの周期性は、一定値として設定されてもよく、または特にROの速度に関連して動的に調整されてもよい。すなわち、ROの速度が早いほど、RONメッセージの送信頻度が高くなる。
【0028】
本発明の実施形態によれば、RONメッセージは、ROに関連する状態情報を符号化する。Table 1(表1)は、RONメッセージ内に符号化されてもよい状態情報の例示的な非網羅的なリストを提供する。
【0029】
【表1】
【0030】
実施形態によれば、RONメッセージは、RO内のオンボードユニット(OBU)によって構成されてもよい。OBUは、速度計、GPSシステム、ナビゲーションアプリケーションなどの、ROの他のオンボードセンサユニットにリンクされてもよい。OBUは、オンボードセンサユニットのそれぞれの出力を入力として受信するように構成されてもよく、センサユニットは、指定された周期で定期的にOBUにそれぞれの出力を送信することができ、または例えば定期的にまたはオンデマンドでOBUによって要求される。RONメッセージは、各RONメッセージがROの最新の状態情報を含むように、センサユニットから受信された情報に基づいてOBUによって生成されてもよい。
【0031】
実施形態において、RONメッセージは、特に、ETSI-Intelligent Transport Systems-EN 302637-2-V1.4.1において指定されている車両通信用のアプリケーションの基本セットに従って、協調認識メッセージ(CAM(Cooperative Awareness Message))において、または、特に、ETSI-Intelligent Transport Systems-EN302637-3-V1.3.0において指定されているDEN基本サービスの仕様に従って、分散型環境通知メッセージ(DENM(Decentralized Environmental Notification Message))において符号化されてもよい。
【0032】
本発明の実施形態によるシステムの高レベルの概観が図2に示される。これらの実施形態によれば、BSAFアプリケーション1は、MECサーバ2などの物理的または仮想計算インフラストラクチャ上でホストされるコンテナベースのMEC(Multi-Access Computing)(マルチアクセスコンピューティング)アプリケーションとして実現される。ROは、BSAFアプリケーション1をホストする計算サーバの識別情報(アドレス)を認識していなければならないことが留意されるべきである。ROがそのようなサーバの識別情報を発見し、サーバに接続することを可能にするための様々なオプションが存在する。本発明の実施形態によれば、ROは、無線アクセスネットワークRAN6に向けて、すなわちROが現在関連付けられているRAN基地局BSにRONメッセージをブロードキャストするように構成されてもよい。次いで、RONメッセージは、それぞれのRANノード、すなわちBSが関連付けられているMECサーバ2に中継されてもよい。すなわち、RAN6は、RONメッセージを正しいMECサーバ2インスタンスにルーティングする役割を果たす。
【0033】
MECサーバ2は、受信したブロードキャストメッセージをRONメッセージとして識別すると、RONメッセージをBSAFアプリケーションインスタンス1に転送し、または仮想アプリケーション機能インスタンスとしてまだ利用可能ではない場合はBSAFアプリケーションインスタンス1をインスタンス化するように構成されてもよい。次いで、BSAFアプリケーションインスタンス1は、ETAおよび/またはROに関連する他の情報を計算するために、RONメッセージ内の情報を処理する役割を果たす。
【0034】
本発明の実施形態によれば、次いでRONメッセージ内の関連するパラメータから導出/計算された情報は、TO通知(TON(TO Notification))メッセージと呼ばれる、TOへの通知メッセージとして符号化されてもよい。実施形態として、このメッセージは、DENMメッセージとして実現され、次いでRAN6BS(例えば、eNB)に向けて中継されてもよく、次いでRAN6BSは、そのそれぞれのカバレッジエリア内でTONメッセージをブロードキャストする。
【0035】
TOへのTONメッセージの配信に関して、基本的には、BSAF1は、ルート経路上のすべてのTOのIDを追跡し、それぞれのTOについてETAを計算し、次いでそれらにユニキャストすることができる。しかしながら、上記ですでに述べたように、これは、かなり高いシステムの複雑さを伴う。したがって、複雑さを低減するために、本発明の実施形態は、ルート経路上の特定の論理セクタについてのETAを計算し、次いでブロードキャスト時にそのセクタ内に存在するすべての車両によって受信されるETAをそのセクタ内でブロードキャストするようにBSAF1を構成することによってこの問題に対処する。
【0036】
本発明の実施形態によれば、ルート経路上のそのようなセクタは、eNBなどの移動BSのカバレッジエリアによって定義されてもよい。したがって、ルート経路に沿って位置するeNBのカバレッジエリアは、図1に例示的に示すように、1つのセクタとみなされてもよい。したがって、ROとイベント位置(すなわち、目的地)との間にeNBが存在するのと同じ数のセクタが存在してもよい。BSAF1は、RONメッセージ内のROの現在位置情報および目的地に基づいて、ルート経路上にあるeNBを選択するように構成されてもよい。次いで、BSAFアプリケーション1は、限定はしないが、選択されたeNBのカバレッジエリアおよび地理位置などの、eNBに関連する補足情報を供給されてもよい。この情報に基づいて、BSAF1は、任意の公知の方法に基づいて各セクタに関連してROのETAを計算する。例えば、ROのETAは、ROの速度と、それぞれのセクタからのその距離とから、たとえば速度-距離の式、
ETAn=Sn/V (1)
に基づいて計算されてもよく、ここで
ETAn=セクタn(すなわち、eNBn)に関するETAであり、ここでn=1、2、3、...であり、
Sn=eNBnからのEmVの相対距離であり、
V=EmVの(平均)速度である。
【0037】
したがって、定期的な繰り返しごとに、BSAF1は、ROの現在の状態を反映する更新された値(Table 1(表1)を参照)を有するROからのRON通知メッセージを受信し、式1に基づいて、2つのセクタ(すなわち、セクタ1およびセクタ2)および3つのTO(すなわち、車両V1、V2、およびV3)について図1に例示的に示すように、すべてのnセクタについてETAを計算する。
【0038】
しかしながら、セルラーBSをセクタとして特徴付ける際の問題は、セルラーBSの大きいカバレッジエリア(約20km以上)のため、セクタごとに単一のETA値を計算することが、EmVに関連するセクタ内のTOのそれぞれの位置に起因して、TOへのかなり不正確なETA通知を結果として生じることである。すなわち、EmVに関連して、セクタの遠い方の端(すなわち、セル境界)にあるTO(すなわち、車両)は、その背後にあり、EmVに比較的近いものよりも高い実際のETAを有する。これは、図1から明らかであり、ここでV3は、V2と比較してEmVから離れているので、ETA2<ETA3である。
【0039】
本発明の実施形態において、ETAの精度を高めるために、セクタは、サブセクタにさらに分割されてもよい。例えば、サブセクタの数は、1つまたは複数の外部要因、たとえば交通状況、交通密度などに依存してもよい。サブセクタは、地理座標によって特徴付けられてもよく、そのようなサブセクタは、本開示では地理セクタ(GS)と呼ばれる。
【0040】
しかしながら、(例えば、US8,941,489 B2に記載されているように)地理フェンスが特定の中心点の周囲の特定の場所において静的に展開されおよび/または拡張/収縮する最先端の地理フェンシング方法とは対照的に、実施形態によれば、本発明は、地理セクタ(GS)がオンデマンドで展開される方法を提供する。特に、GSの数ならびにそれらのそれぞれの形状およびサイズ(すなわち、カバレッジエリア)は、実際のまたは予測される交通密度、道路の形状、および/または他の状態などの外部要因に基づいて動的に調整されてもよい。いくつかの実施形態において、GSは、同様に機械学習ML技法に基づいて予測的に決定および展開されてもよい。したがって、GS決定のプロセスを学習し、継続的に改善することによって、RO(例えば、EmV)のきめ細かいETA計算およびTOのための操縦推奨のための動的な地理セクタを動的に作成することが可能になる。
【0041】
以下、記述/説明の目的のため、いかなる限定も意味することなく、GSの形状は、図3に例示的に示すように、正方形であると仮定される。しかしながら、GSは、多角形から円形、さらには楕円形などまでの任意の形状のものであってもよい。形状はまた、カバレッジエリアの形状を特徴付けるように採用されてもよい。
【0042】
より具体的には、図3は、破線の正方形として構成されるGSの概念図を示し、ここで破線の正方形の4つの(x,y)座標は、GSの地理的座標を表す。オブジェクト、例えば車両は、その地理座標がGSの座標内にある限り、GSの境界内にあると言われ、そうでない場合、GSの外側にあるとみなされる。例えば、図3において、V1で示される車両は、その地理座標(x',y')が規定されたGS境界内にあるので、GS内とみなされる。V1と対照的に、車両V2は、その座標(x",y")が規定されたGSの座標の外側にあるので、GSの外側にある。
【0043】
本発明の実施形態によれば、BSAF機能1は、例としてRO関連の状態情報の非網羅的なリストを提供するTable 1(表1)に関連して上記で説明したように、RONメッセージ内に符号化されたROの状態に関する定期的な通知を取得する。特定のROの第1のRONメッセージは、BSAFアプリケーション機能をアクティブにするためのトリガとしても機能してもよい。
【0044】
図4は、地理セクタを決定するBSAFアプリケーション1のプロセスの実施形態を示す。プロセスは、BSAFアプリケーション1がそれぞれのトリガメッセージを受信すると、S400において開始する。実施形態によれば、このトリガメッセージは、特定のRO、たとえばEmVによって送信される第1のRONメッセージであってもよい。
【0045】
S410に示すように、BSAFアプリケーション1は、最初に、RONメッセージ内に符号化されたそれぞれのROのルート経路の座標を取得する。
【0046】
次に、S420に示すように、ローカルマップに基づいて、または外部マップアプリケーションから、BSAFアプリケーション機能は、たとえば道路のタイプ(高速道路、市街道路、住宅地、一方通行、両面通行)、総車線、速度制限などのルート経路の特性を決定する。
【0047】
次いで、S430において、BSAFアプリケーション機能1は、ルート経路上の、すなわち、ROの現在位置と影響を受ける可能性のあるTOとの間の一次セクタを論理的に決定する。上記で説明したように、一次セクタは、ルート経路をカバーするセルラー基地局BSのカバレッジエリアによって特徴付けられてもよい。この場合、BSAFアプリケーション1は、限定はしないが、BSのID、BSの地理位置、BSのカバレッジエリア/範囲などを含むBS特性を必要とする。そのような情報は、外部ソースから、たとえばセルラサービスプロバイダからアクセスおよび取得されてもよい。
【0048】
S440において、BSAFアプリケーション1は、S430において生成されたそれぞれの一次セクタをサブセクタに分割する必要があるかどうかを決定する。本発明の実施形態によれば、この決定は、ROに関連する分解能係数(resolution factor)(Δr)に基づいてもよく、ここで分解能係数(Δr)は、ROのETAの時間的分解能を決定する。例えば、Δr=300の値は、ROに関連する一次セクタの入口点と出口点との間のETAの差ξを5分(300秒)として意味してもよく、ここでξは、セクタ内のROの滞留時間である。
【0049】
S450に示すように、ξの値に応じて、BSAF1は、一次セクタが分割されるべきサブセクタの数を決定してもよい。最初のサブセクタ化の間、それぞれのサブセクタのサイズが等しいこと、すなわち、一次セクタがサブセクタ間で均等に分割されることが条件であってもよい。
【0050】
BSAFアプリケーション機能1は、明確な経路を想定したROの平均速度と現在位置とに基づいて、セクタ入口(ETAi)およびセクタ出口(ETAe)に向かうETAを計算してもよいことが留意されるべきである。しかしながら、サブセクタの数のより正確な決定のために、BSAFアプリケーション機能1は、この特定の時間におけるその特定の場所におけるいくつかの過去の交通データに基づいてETAeを計算してもよい。BSAFアプリケーション機能1は、高度道路交通システム(ITS(Intelligent Transportation System))内の外部データベースからそのようなデータを取得してもよい。BSAFアプリケーション機能に生の過去のデータが提供される場合、ETAiとETAeの両方を予測するために、高度な統計的技法またはMLベースの方法を使用することができる。
【0051】
次に、S460に示すように、BSAFアプリケーション機能1は、一次セクタを特徴付けるGSの座標を導出する。ステップS450において一次セクタがさらにセクタ化されている場合、BSAFアプリケーション機能1は、それぞれのサブセクタについてGS座標を導出する。図5に示す例に関連して、一次セクタは、2つのGS、すなわちGS-1aおよびGS-1bに分割される。各サブセクタを境界付けるGSは、図3に関連して上記で説明したように特徴付けられる。説明のために、図5は、2つの等しいGSに分割された一次セクタを示す。しかしながら、以下でより詳細に説明するように、セクタ内のGSのサイズは、同じでない場合がある。すなわち、一次セクタは、各GSのサイズが互いに異なる場合がある複数のGSに細分されてもよい。いずれにせよ、地理セクタ化は、ROとDOとの間の領域において行われる。
【0052】
本発明の実施形態によれば、ROとDOとの間のルート経路がセクタ化され、GSが確立されると、BSAFアプリケーション1は、それぞれのGSについてROのETAを決定するために、RONメッセージ内の情報を処理してもよい。図6は、ETAおよびGSならびに他の関連情報を(再)計算および/または(再)評価するためにRONメッセージを処理するときのBSAFアプリケーションの例示的なロジックを提供する。
【0053】
図示の実施形態によれば、BSAFアプリケーション1は、S600においてプロセスを開始した後、S602に示すように、任意の受信したRONメッセージを事前定義されたポートにおいてリッスンしている。
【0054】
受信されると、BSAFアプリケーション1は、(上記のTable 1(表1)における指示に従って、RONメッセージ内に符号化されてもよい)RONメッセージから現在の地理位置を抽出し、RONメッセージを発信したROの位置(すなわち、地理位置)を決定する。このステップは、S604に示される。
【0055】
次に、S606に示すように、RONメッセージにおいて受信されるROの現在の地理位置および現在/平均速度情報と、GSの座標における情報(本明細書では、時にはGSマップ7と呼ばれる)とに基づいて、BSAFアプリケーション1は、各GSの侵入に関連してROのETAiを計算/予測することができる。ここでは詳細な説明が省略されてもよいように、当業者に明らかになるETAを決定するための公知の方法が存在する。
【0056】
実施形態によれば、ROに先行する第1のGSのETAの計算は、ROの現在のGPS座標および現在/平均速度を考慮に入れる。後続のGSのETAiは、ROの現在の地理位置および現在/平均速度に加えて、前のGSのETAならびにその距離のサイズも考慮に入れてもよい。実施形態として、ETAiの計算は、過去の交通情報、現在の交通情報、ルートの距離、その日の時刻、および/または他の関連要因に基づいて、異なるGSにおける予測される交通状況を考慮に入れることもできる。
【0057】
本発明の実施形態によれば、それぞれのGSのETAi値が計算された後、計算されたETAi値は、ベクトルとして符号化されてもよい。本開示では、そのようなベクトルは、ETAベクトルと呼ばれる。
【0058】
図7は、本発明の実施形態によるETAベクトルの例示的な情報モデルを示す。図示のように、ETAベクトルの情報モデルは、2つのキー(キー1およびキー2)と値とを含むマルチキーマップとして実現されてもよい。この実施形態において、キー1(RO方向)は、RO(例えば、EmV)の移動方向を表す。キー1は、enumデータ型によって表されてもよい。キー2(GS Id)は、GSを識別する。キー2は、GSの境界を特徴付ける座標のセットによって表されてもよい。キー2は、BSAFアプリケーション1がROとTOとの間のGSのチェーンの情報を計算することを考慮して、リスト型データ構造であってもよい。値(ETA)は、それぞれのGS Idについて計算されたROのETA値である。その他の値であるGSタイプおよび通知について、図11を参照して説明する。
【0059】
図6中のS608に示すように、BSAFアプリケーション1は、ROがGSチェーン内の次のGSに移動したかどうかを判断するために、ROの現在の地理位置についての知識とGSマップ7とを使用する。この文脈において、地理セクタがチェーン構成であるので、あるセクタの出口は、前のセクタの入口であることが留意されるべきである。
【0060】
ステップS608において、ROが特定のGSから移動したとBSAFアプリケーション1が判断した場合、BSAFアプリケーションは、S610に示すように、ROがすでにDOに到着したかどうかを判断する。そうである場合、BSAFアプリケーション1は、S612に示すように、そのGSマップ7からそれぞれのGSをクリア/削除し、S614において待機状態に戻る。ROがDOに到着していない場合、ROがチェーン内の次のGSに入ったことが暗示されてもよい。したがって、BSAFアプリケーション1は、S616に示すように、GSマップから前のGSエントリをクリア/削除し、次いでS618に示すように、受信したRONメッセージ内のタイムスタンプ情報からROの実際の到着時間(ATA)を導出する。
【0061】
次に、S620に示すように、BSAFアプリケーション1は、ATAを現在のGSについて計算されたETAと比較する。両方の値が同じである場合、または差がなんらかの事前定義された制限内にある場合、BSAFアプリケーションは、S622に示すように、TOによって受信されるように、GSチェーン内のすべてのGSにおけるモバイルネットワークインフラストラクチャを介してETAベクトルを伝達する。
【0062】
そのようなETAベクトルをTOに向けて伝達するには様々なオプションが存在する。一実施形態において、ETAベクトルは、TONメッセージ内に埋め込まれ、TONメッセージは、TOに向けた通知メッセージとして伝達されるように、CAMまたはDENMメッセージ内に符号化される。TONメッセージは、それぞれの一次セクタ内にあるすべてのTO(例えば、車両)によって受信されるように、そのカバレッジエリア内の各BSによってブロードキャストされてもよい。伝達されると、BSAFアプリケーションは、プロセスステップ602に戻り、ROからの次のRONメッセージをリッスンする。
【0063】
そうでない場合、すなわち、S620において、ATAおよびETAが等しくないと判断された場合、BSAFアプリケーションは、S624に示すように、GSチェーン(すなわち、GSマップ7)のGSの数およびサイズ、ならびに再評価されたGSごとのETA値を再評価する。
【0064】
GS寸法およびGSマップ7に関して、S626に示すように、BSAFアプリケーション1がGSチェーン内の異なるGSセグメントのサイズを再調整し、ある比率によっていくつかのGSセグメントをより大きくし、他のGSセグメントをより小さくし、および/または新しいGSセグメントをGSチェーン内に追加することが規定される。前述のように、GSチェーン内の異なるGSセグメントのカバレッジサイズは、必ずしも同じではなく、渋滞、特定のGS内のROの滞留時間などの様々な要因に応じて異なる可能性がある。
【0065】
ETA値に関して、S628に示すように、ROのETAは、後続の各GSごとに再評価される。この文脈において、あるGSのETA値における変化、および/またはGSマップ7における変化は、その後のGSセグメントについて計算されるすべてのETAの値に影響を与えることに注意することが重要である。これは、あるGSのETAが、GSチェーン内の前のGSについて計算されたETA値を考慮に入れることによって計算されるからである。
【0066】
再評価の後、ステップS622に関連して上記で説明したように、ETAベクトルは、更新され、伝達される。
【0067】
プロセスステップS618~S628は、ROが同じGSセグメント内にある場合であっても、RONメッセージが受信されるたびに繰り返される。プロセスステップS622において、ETAベクトルを搬送するTONメッセージがその一次セクタ内でブロードキャストまたはエニーキャストされると、TONメッセージを受信するすべてのTOは、図8に示す例示的なロジックに従ってメッセージを処理する。
【0068】
図示の実施形態によれば、TOは、S802に示すように、ブロードキャストされたTONメッセージを受信し、受信したTONメッセージからETAベクトルを抽出することによって、S800における処理を開始する。
【0069】
次に、S804に示すように、TOは、TOがいる道路/経路のタイプを決定する。例として、2つの異なるタイプの道路(道路タイプ1および道路タイプ2)が想定され、道路タイプ1の道路は、2方向における交通のための道路を分割する硬い物理的なバリアを有するのに対し、道路タイプ2の道路は、2方向の交通のための道路を分割する柔らかい/論理的な仕切り(実線の白く塗られた帯)を有する。したがって、道路タイプ2について、ROが柔らかい/論理的な仕切りを横切って移動することができるので、ETA値は、両方向の車両に関連する。道路タイプ1について、ROが固いバリアのために道路の反対側に移動することができないので、ETA値は、ROの方向において移動するTOにのみ関連する。
【0070】
したがって、TOがS806において道路タイプが1であると判断した場合、S808に示すように、ナビゲーションシステムデータに基づいて、TOは現在の移動方向をETAベクトルにおいて指定されたRO方向の移動方向と比較する。ETAベクトルは、図7に示す実施形態に従って構成されてもよいことが留意されるべきである。
【0071】
S810において、方向が一致しない、すなわち、TOがROと反対方向に移動しており、道路が固いバリアによって分割されている道路の反対側にTOがいることを意味するとTOが判断した場合、その場合、S812に示すように、TOは、TONメッセージを無視する。
【0072】
一方、S810において、RO方向がTO自体の移動方向と一致するとTOが判断した場合、またはS806において、TOが道路をタイプ2と識別した場合、TOは、S814に示すように、現在移動しているGS Idを識別する。これは、ETAベクトルにおいて提供される最も関連性の高いGS idに対してTOがその現在位置を識別することによって達成されてもよい。
【0073】
TOは、ドメイン内にその現在位置が位置するGS idを発見/識別すると、S816に示すように、一致するGS idに対応するETA値をETAベクトルから取得し、たとえば視覚的におよび/またはオーディオメッセージを介してETAの運転者に通知する。
【0074】
上記で説明したように、本発明の実施形態は、ROとDOとの間のGSチェーンのオンデマンドの作成、およびROの移動に関連するその連続的な削除のための方法に関する。さらなる実施形態によれば、GSチェーン内の個々のGSは、図9を参照して以下でより詳細に説明するように、弾力的な方法において構成されてもよい。
【0075】
図9は、2つの一次地理セクタ、すなわち、一次地理セクタ1および一次地理セクタ2にわたって展開された合計7個のGSセグメントを有するGSチェーンを示す。GS1.1およびGS1.2は、主に一次地理セクタ1内で展開され、GS2.1~2.5は、一次地理セクタ2にわたって展開される。GSチェーンは、ROとDOとの間でインスタンス化されるが、DOは、最後のGS2.5のすぐ外側にあることが留意されるべきである。GSチェーンにわたって分散された多くのTOが存在し、矢印の方向およびサイズは、TOの移動方向および速度を示す。矢印のサイズは、TOの速度に比例する。
【0076】
GSのサイズは、個々のGSセグメントの長さおよび幅を示すパラメータ(δ、Δ)によって特徴付けられる。GSは、任意の形状のものであってもよいが、説明の簡略化および明確化のために、本明細書では、GSが正方形の形状によって特徴付られると仮定されることが留意されるべきである。図9に示すように、それぞれのGSセグメントのサイズは、同じではなく、互いに異なる。本発明の実施形態によれば、GSの長さδは、入口ETAと出口ETAとの間の差に依存してもよく、ここで線形、非線形(例えば、指数など)であってもよいなんらかの関数fによって規定される。これは、以下
δmax≧δ≧δmin
ξ=ETAe-ETAi
ξ<|T|の場合、δ=δmax
ξ≧Tの場合、δ=f(ξ)
ξ≧|T'|の場合、δ=δmin
のように表されてもよく、ここでTおよびT'は、設定可能なETAのしきい値である。
【0077】
図10は、本発明の実施形態による、GSチェーン内の個々のGSの弾力的な態様を示す。より具体的には、図10は、GSの長さδの変動が、ETAしきい値TとT'との間の線形関数に基づいて指示される図を示す。特にこの例では、勾配mは、システムが特定のGSゾーン内で一般的な環境要因に基づいて個々のGSセクタのサイズをどれだけ迅速にまたはゆっくりと変化させるかを決定する「弾力剛性」要因とみなされてもよい。システムは、GSチェーン内の1つまたはすべてのGSゾーンのサイズを変化させるために同じ関数を使用してもよく、またはGSチェーン内の異なるGSゾーンに対して異なる関数を使用してもよいことが留意されるべきである。
【0078】
GSチェーン内の連続した一連のGSゾーンを維持することが必要であるので、したがって、特定のGSゾーンの任意の縮小は、特定のGSゾーンの縮小によって生成されるギャップをカバーするために新しいGSゾーンの作成を結果として生じる場合がある。例えば、図10に示すシナリオを考慮すると、GS2.4の縮小によって現れたGS2.2とGS2.4との間のギャップをカバーするためにGS2.3が実現された可能性がある。
【0079】
上記で示したように、GSゾーンのサイズは、GSゾーンにおいて一般的な環境要因によって規定されてもよく、これは、長さδを特定の最大および最小制限δmaxおよびδmin内で縮小または拡大させる。実施形態によれば、要因のうちの1つは、たとえば特定のGSゾーンおよび/または隣接するゾーン内の交通渋滞であり、これは、ξを特定のしきい値Tを超えて増加させる場合がある。これは、同じGSゾーン内のすべてのTOによって経験されるROの到着時間(ATA)がそのGSについて計算されたETAの値とほぼ等しくなるように、ETAの精度を高めるために行われる。したがって、GSの長さδは、ROの速度を遅くする交通量が多い場合はより小さくなり、ROが最小の障害でより速く移動する交通量が少ない場合はより大きくなる。
【0080】
システム、またはより正確にはBSAFアプリケーション機能1は、外部の交通管理システムから交通状況に関する情報を取得してもよく、および/または無線ネットワークインフラストラクチャから受信した情報に基づいてそのような交通状況を推測することができる。RAN6からのそのような情報は、たとえば一次セクタ内の渋滞のレベルを推測するために、TOの数を示す取り付けられたUEの数、および/または特定の一次セクタ内のハンドオーバの頻度を含んでもよい。さらなる実施形態によれば、TOが最小限の情報としてそれらの地理位置を示すCAMまたはDENMメッセージなどの定期的な通知メッセージを明示的に送信する場合、交通状態に関するGSゾーンの粒度でのより正確な推論が行われてもよい。
【0081】
本発明の実施形態によれば、無線ネットワークインフラストラクチャに基づくTOに関する情報は、MECサービスの一部である無線ネットワーク情報システム(RNIS(Radio Network Information System))サービスを活用することによって推測されてもよい。
【0082】
図11は、本発明の別の実施形態を示し、この実施形態に従って、ROのルート経路上にいないが、ルート経路の交差点に接近しているTOに対して警告通知が送信される。そのようなTOは、ETAを提供される必要はないが、特定の時間まで交差点を横断しないように警告される必要がある。例えば、図11のシナリオに関連して、GS2.6およびGS2.7におけるTOは、ROのルート経路と交差している。そのようなTOは、明確な通路を作成するように操縦する必要はないが、ROの横断が差し迫っているとき、交差点でROのルート経路を横断してはならない。そのようなTOについて、BSAFアプリケーション機能は、ROのETAに加えて、「DO NOT CROSS(横断しないで)」、「CLEAR TO CROSS(横断するのに空いている)」などの適切な警告通知メッセージを含む特別な通知を生成してもよい。
【0083】
そのようなメッセージを提供するために、BSAFアプリケーション機能1は、GSのタイプ間を区別するように構成されてもよい。図7を再び参照すると、GSタイプは、enumタイプのパラメータであってもよい。これに基づいて、異なるGSタイプが表記されてもよい。例えば、ROのルート経路上にあるGSセグメントは、「アクティブ通知GS」と表記されてもよいト経路上にはないが、ROのルート経路の交差点などのROのスムーズな通過を阻害する可能性があるGSセグメントは、「アクティブ警告GS」と表記されてもよい。
【0084】
「アクティブ通知GS」について、関連する通知メッセージとともにETA値が送信されることが規定されてもよい。実施形態によれば、通知メッセージ(図7に示す)は、「駐車禁止道路」、「減速して」、「横に停止して」、「前方のTOからの距離を増やして」などのメッセージを含んでもよい。一方、「アクティブ警告GS」におけるTOに対する通知メッセージは、「交差点で停止して」、「横断しないで」などのメッセージを含んでもよい。したがって、ETAベクトルメッセージ(図7に示す)は、多くのタイプのGSセグメントタイプと、特定のGSタイプに関連する様々な通知メッセージとを符号化することができる。
【0085】
本発明の実施形態によれば、交差点における早すぎる交通渋滞を防止するために、警告通知は、ETAが指定されたしきい値未満になった場合にのみ生成されてもよい。例えば、2分のしきい値について、ETA値が2分未満になった場合にのみ、警告メッセージは、「アクティブ警告GS」内のTOにブロードキャストされる。
【0086】
図12は、本発明の実施形態による、正確なRO ETA情報および伝達を可能にするためのシステムを概略的に示す。システムは、図12に示す実施形態では、MECサーバ2などのエッジコンピューティングデバイスにおいて展開されるBSAFアプリケーション機能1を備える。MECサーバ2は、3G/4G/5G以上などのモバイルネットワークコア/RANインフラストラクチャ6と相互接続される。MECサーバ2はまた、オプションで、道路/交通状況に関する更新された情報を取得することを可能にするために、状況認識機能を介して外部交通管理システム4に接続されてもよい。
【0087】
取得された情報は、ROとDOとの間のGSチェーンを計算/構成/管理するために、BSAFアプリケーション機能1によって使用される。それに加えて、情報は、ROの現在位置と交通/道路状況とに基づいて、TOに向かうROのETAなどの、GSセグメントに固有の情報を(再)計算するために使用されてもよい。交通/道路情報はまた、モバイルネットワーク通信インフラストラクチャのRAN6から情報を受信しているRNISサービスから推測されてもよい。BSAF機能1は、BSAFアプリケーションの外部または内部のいずれかであってもよい状態テーブル8内に最新の/更新された状態情報を維持する。BSAFアプリケーション機能1はまた、GSマップ7内のGSチェーンマップを管理および維持する。BSAFアプリケーション機能1は、BSAFアプリケーション1が定期的に受信するRONメッセージ内に含まれる情報に関して、ETA情報を計算するように構成されてもよい。BSAFアプリケーション機能1は、GSタイプを決定し、GSタイプに適切な通知メッセージを選択するようにさらに構成される。それぞれのプロセスロジックの実施形態については、上記ですでに説明している。計算された情報は、MECサーバ2内の通信プロトコルスタックを使用して通信されるTONメッセージをブロードキャストし、MECのネットワークインターフェースカードNIC10を介してそれらをRAN6に向けて送信することによって、セクタ内で伝達される。実施形態として、MECサーバ内の図12に示すシステム構成要素は、1つまたは複数の仮想マシン(VM(Virtual Machine))内またはコンテナ内のいずれかの仮想化機能として実現されてもよい。当業者によって理解されるように、他の実装方策も同様に実現されてもよい。
【0088】
実施形態によれば、TOに向かうROの受信ETAの精度は、PC5リンクなどのV2V通信プロトコルを使用して、ROと範囲内のTOとの間の直接通信を活用することと組み合わされた場合、さらに向上されてもよい。しかしながら、そのようなシナリオにおいて、TOは、TO自体およびROの現在位置に関するETAを導出するためにRONメッセージを処理する能力を有するべきである。次いで、TOは、受信したRONメッセージを、前方の範囲内のTOなどにさらに中継することができる。欠点は、TOが直接通信範囲外に出ると、そのような連続する中継が切断され、したがって、サービスを中断/切断することである。
【0089】
いずれにせよ、TOのOBUは、ETAなどのRO固有の情報を受信すると、特に、TOマルチメディアシステムを使用してETA値を視覚的および/または聴覚的に運転者に表示することによって、運転者に適宜知らせるように構成されてもよい。そのような事前通知は、ROがDOに向かって妨げられずに通過するための明確な通路を作成するために操縦することなどの先制の処理を行う方策を冷静に評価するのに十分な時間を運転者に与える。図11を参照して説明したように、特定の通知メッセージと結合されたETAは、BSAFアプリケーション1による操縦推奨をTOに提供するのに役立つことができる。
【0090】
これまで、DOは、静的であると仮定されていたが、本明細書で説明した同じメカニズムは、DOが移動性である場合にも活用されてもよい。そのような場合、ROがDOに追いつくまで、ROとDOとの間の距離が減少、増加し続けながら、GSチェーンは、縮小し、拡大し、したがってスライドして、ROとDOとの間で維持されたままであってもよい。
【0091】
前述のように、TOは、ブロードキャストされたTONメッセージ内に符号化されたETAベクトル全体を受信し、すべてのGSセグメントに対応するETA値のみを抽出し、他の情報を拒否/無視してもよい。しかしながら、ETAベクトル情報は、その先のルート経路の状態の補強された情報を作成するために、TOによって活用されてもよい。例えば、TOは、たとえば色付きの表示を使用することによってTOのディスプレイ上に表示されてもよい前方の道路/交通状況などの、ETAベクトルからの情報を導出することができる。例えば、図9に関して、GS1.1内のTOにおけるディスプレイは、GS1.1の下のルート経路を渋滞がないことを示す緑色として示し、GS2.1の黄色は、軽い渋滞を示し、GS2.3およびGS2.4について、激しい渋滞を示す赤色として示してもよい。これは、TOが地平線の向こうの情報を導出および視覚化することを可能にし、それによって、TOが前方のルート経路におけるそのような状況を回避するための適切な判断を十分な時間で行うことを可能にする。
【0092】
別の実施形態として、BSAFアプリケーション1はまた、個々のTO上でホストされてもよく、モバイルネットワークインフラストラクチャは、ROから受信したDENMまたはCAMメッセージをTOにブロードキャストすることによって中継する。次いで、各TOは、その現在位置に関してROのETAを評価することができる。しかしながら、TOは、ROとDOとの間の環境状況(例えば、交通状況)を認識していないので、ETA値は、TOにおいて計算された場合、正確ではない場合がある。
【0093】
さらに別の実施形態として、BSAFアプリケーション機能1は、RO自体においてホストされてもよく、モバイルネットワークインフラストラクチャは、RO上で計算されたETAベクトルをそれぞれのGSゾーンに向けて中継および伝達するためにのみ使用される。そのような場合、ETAベクトルは、RONメッセージとTONメッセージの両方において符号化されてもよい。
【0094】
別のユースケースとして、BSAFアプリケーション1の出力はまた、安全な方法でDOに向かうROの妨げられない移動を提供するのに役立つように交通信号を制御するために、交通管理システムに提供されてもよい。
【0095】
要約すると、本発明の実施形態は、移動するROと静的/移動性DOとの間のTOの位置に関連する操縦推奨とともに、ROのETAの正確かつ微細な決定および視覚可聴範囲外(BVAR)通知を可能にする方法およびシステムに関し、ここでETAは、連続したGSチェーン内のリンクされた各地理セクタ(GS)セグメントを参照して決定され、これによって、GSチェーン内のGSセグメントは、一般的な経路状況に応答して動的に管理される。本発明の実施形態は、以下の特徴/態様のうちの1つまたは複数を含んでもよい。
1.ROとDOとの間のエリア内の特定のイベントに反応して弾力的に変化する個々の地理セクタセグメントの寸法であり、指定された関数パラメータが、弾力の剛性を決定する。
2.DOの方向においてROによって横切られた地理セクタセグメントの自動削除。
3.DOがROから離れているときの、GSチェーン内の新しい地理セクタセグメントの自動現実化。
4.GSチェーン内のGSセグメント寸法の弾力的変化に応答して変化するGSチェーン内のGSセグメントの数。
5.同じGSセグメントゾーン内のオブジェクトによる通知の選択的選択。
6.通信範囲内のオブジェクト間の直接通信を活用することによってさらに改善される情報の精度。
7.TOに後方状況の認識と地平線の向こうの状況の認識とを可能にする。
8.異なるタイプのGSセグメント間を区別し、GSのタイプに関連する操縦推奨および/または警告通知を提供する。
【0096】
同じまたは他の実施形態によれば、本発明は、以下のステップのうちのいずれかを含む、ROのETAを正確に計算するためにスマート地理セクタを作成するための方法に関する。
【0097】
1.RO関連の状態情報を含むRO通知メッセージをシステム(MECおよび/もしくはコアネットワークまたは任意のオペレータネットワークなどのネットワークインフラストラクチャ)に定期的に送信するRO。
2.DOの場所に関する定期的な情報を受信する方法/システムおよびRO。
3.ROとDOとの間のGSチェーンの初期実現化のためのいくつかの過去のデータに基づいてGSチェーン内の連続的にリンクされた地理セクタセグメントの構成を計算するための方法/システム。
4.ROがDOに到達するまで、GSチェーンの存続期間を通じてGSチェーンを動的かつ弾力的に管理する方法/システム。
5.GSセグメントゾーンに固有の情報を伝達するシステム/方法であり、それによって、それぞれのGSセグメントゾーン内の各TOが、そのTOが現在いるGSセグメントに関連する情報を無視または抽出する。
6.情報の精度は、通信範囲内のROとTOとの間の直接通信を活用することによってさらに改善されてもよい。
【0098】
本明細書に記載の本発明の多くの修正および他の実施形態は、前述の説明および関連する図面において提示される教示の利益を有する本発明が関係する当業者には想起されるであろう。したがって、本発明は、開示された特定の実施形態に限定されるべきではなく、修正および他の実施形態が添付の特許請求の範囲内に含まれることが意図されていることが理解されるべきである。本明細書では特定の用語が用いられているが、それらは、一般的かつ説明的な意味でのみ使用されており、限定の目的のためには使用されていない。
【符号の説明】
【0099】
1 BSAFアプリケーション、BSAFアプリケーションインスタンス、BSAF、BSAF機能、BSAFアプリケーション機能
2 MECサーバ
4 外部交通管理システム
6 無線アクセスネットワークRAN、RAN、モバイルネットワークコア/RANインフラストラクチャ
7 GSマップ
8 状態テーブル
10 ネットワークインターフェースカードNIC
100 RO
110 TO
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12