JP2018170628A

JP2018170628A - 車載クラウドレット

Info

Publication number: JP2018170628A
Application number: JP2017066475A
Authority: JP
Inventors: 柴田　義孝; Yoshitaka Shibata; 義孝柴田
Original assignee: Iwate Prefectural University
Current assignee: Iwate Prefectural University
Priority date: 2017-03-29
Filing date: 2017-03-29
Publication date: 2018-11-01
Anticipated expiration: 2037-03-29
Also published as: JP6846037B2

Abstract

【課題】効率的なデータ転送を実現することが可能な車載クラウドレットを提供する。【解決手段】車載クラウドレット４ａは、無線方式Ｒ０を使って周辺の通信ノードにブロードキャストを行い、応答があるか否かの確認として接続要求を行い（ステップＳ３）、応答がある場合（ステップＳ５のＹｅｓ）、自らのＵＵＩＤと無線方式Ｒ１〜Ｒｎの接続情報を送信し（ステップＳ１１、Ｓ３１、Ｓ５１）、通知ノードのＵＵＩＤと無線方式Ｒ１〜Ｒｎの接続情報を受信する（ステップＳ１２、Ｓ３２、Ｓ５２）。次に、車載クラウドレット４ａは、通知ノードの無線方式Ｒｉ（ｉ＝１〜ｎ）に通信可能か否かの確認として接続要求を行い（ステップＳ１３、Ｓ３３、Ｓ５３）、接続候補の無線方式の中から最適な無線方式Ｒｏｐｔを決定し（ステップＳ１７、Ｓ３７、Ｓ５７）、通知ノードとの間で無線方式Ｒｏｐｔによる通信を確立する（ステップＳ１８、Ｓ３８、Ｓ５８）。【選択図】図７

Description

本発明は、車両等に搭載され、クラウドサーバが行う処理の一部又は全部を実行する車載クラウドレットに関するものである。

大規模災害時に通信環境を確保する技術として、ＤＴＮ（Delay, Disruption, Disconnection Tolerant Networking：遅延耐性ネットワーク）が注目されている。ＤＴＮは、通信不可の環境では中継ノードにデータを蓄積しておき、中継ノードの移動等によって通信可能の環境になると、データ転送を行う仕組みである。ＤＴＮによって、劣悪な通信環境であってもデータ転送を実現することができる。例えば、特許文献１には、蓄積転送型通信により他の通信装置を介して宛先の通信装置との間でメッセージの送受信を行う通信装置が開示されている。

特開２０１５−１９２３４７号公報

ところで、車載クラウドレットにＤＴＮの技術を応用する場合、データ転送の効率化が課題となる。

本発明は、前述した問題点に鑑みてなされたものであり、その目的とすることは、効率的なデータ転送を実現することが可能な車載クラウドレットを提供することである。

前述した目的を達成するための本発明は、複数の無線方式によって通信ノードとの間で無線通信を行う車載クラウドレットであって、前記無線方式の１つを使って周辺の前記通信ノードにブロードキャストを行い、応答があるか否かを確認する初期応答確認手段と、前記通信ノードから応答があると、前記通信ノードに自らの識別子及び複数の前記無線方式の接続情報を送信する接続情報送信手段と、前記通信ノードの識別子及び複数の前記無線方式の接続情報を受信する接続情報受信手段と、複数の前記無線方式について、前記通信ノードとの間で通信が可能か否かを確認する通信可否確認手段と、前記通信ノードとの間で通信が可能な前記無線方式の中で最適な前記無線方式を決定する無線方式決定手段と、最適な前記無線方式を使ってデータの送受信を行うデータ送受信手段と、所定の情報を記憶する車載データベースと、を備え、前記通信ノードは、少なくとも、前記車載データベースと同一の情報を格納可能なローカルデータベースを備えるローカルサーバと、規格が異なるネットワーク間の通信を中継するゲートウェイサーバとを含み、前記データ送受信手段は、前記通信ノードが前記ローカルサーバの場合、前記ローカルデータベースと前記車載データベースとのデータを同期し、前記通信ノードが前記ゲートウェイサーバの場合、前記ゲートウェイサーバを介してクラウドサーバと通信を行い、前記クラウドサーバが備える前記車載データベースと同一の情報を格納可能なグローバルデータベースと前記車載データベースとのデータを同期することを特徴とする車載クラウドレットである。本発明によって、効率的なデータ転送を実現することが可能となる。

本発明における前記無線方式決定手段は、前記無線方式ごとにスループット、遅延時間及びパケットロス率を測定し、前記スループット、前記遅延時間及び前記パケットロス率に基づく値を変数に含む評価関数の値を算出し、前記評価関数の値が最大の前記無線方式を最適な前記無線方式として決定するようにしても良い。これによって、ネットワークの状況に応じた最適な無線方式を用いて通信ノードと通信を行うことができる。

本発明における前記無線方式決定手段は、前記スループット、前記遅延時間及び前記パケットロス率を各々複数個測定し、前記スループットの加重移動平均、前記遅延時間の加重移動平均及び前記パケットロス率の加重移動平均を算出し、前記スループットの加重移動平均、前記遅延時間の加重移動平均及び前記パケットロス率の加重移動平均を各々正規化した値を前記評価関数に代入することによって、前記評価関数の値を算出するようにしても良い。これによって、災害状況下等においてネットワーク性能が常に不安定な状態であっても、適切な無線方式を決定することができる。

本発明における前記評価関数は、前記スループット、前記遅延時間及び前記パケットロス率に基づく値の加重平均であっても良い。これによって、ネットワーク性能に関する要求を重みとして与えることができ、要求に沿った無線方式を用いて通信ノードと通信を行うことができる。

本発明における複数の前記無線方式は、互いに通信可能距離が異なり、前記初期応答確認手段において用いる前記無線方式は、最も通信可能距離が大きいものであっても良い。これによって、通信ノードが遠方にいる間に通信確立処理を実行し、通信ノードに接近した状態では、最適な無線方式を用いて実データの転送から開始できるので、効率的なデータ転送が可能となる。

本発明により、効率的なデータ転送を実現することが可能な車載クラウドレットを提供することができる。

遅延耐性ネットワーク分散システムの概要を示す図車載クラウドレットの構成を示す図道路状況監視ＶＭの構成を示す図災害情報データベースの管理方法を説明する図路側クラウドレットの構成を示す図車載クラウドレットの処理の流れを示すフローチャート（１）車載クラウドレットの処理の流れを示すフローチャート（２）車載クラウドレットの処理の流れを示すフローチャート（３）車載クラウドレットの処理の流れを示すフローチャート（４）最適な無線方式の決定処理の流れを示すフローチャート

以下図面に基づいて、本発明の実施形態を詳細に説明する。図１は遅延耐性分散システムの概要を示す図である。図１に示すように、遅延耐性ネットワーク（＝ＤＴＮ：Delay, Disruption, Disconnection Tolerant Networking）分散システム１は、車両３ａに搭載される車載クラウドレット４ａと、車両３ｂに搭載され、車載クラウドレット４ａと無線通信を介して接続される車載クラウドレット４ｂと、車載クラウドレット４（車載クラウドレット４ａ、４ｂを区別しない場合、「車載クラウドレット４」と表記する。）と無線通信を介して接続される路側クラウドレット５と、車載クラウドレット４と無線通信を介して接続されるローカルサーバ６と、車載クラウドレット４とゲートウェイサーバ７及びネットワーク８を介して接続されるクラウドサーバ２と、によって構成される。ネットワーク８は、例えばインターネットである。

クラウドサーバ２は、例えば、データセンターに配置されるサーバ用コンピュータであり、１台の筐体で実現されても良いし、複数台の筐体で実現されても良い。

車載クラウドレット４ａは、周辺の他の車載クラウドレット４ｂ、路側クラウドレット５、ローカルサーバ６及びゲートウェイサーバ７と無線通信を行い、クラウドサーバ２が行う処理の一部又は全部を実行する。クラウドレットは、エッジコンピューティング又はフォグコンピューティングといった技術において、クラウドサービスを受ける端末側に近い位置に分散して配置される小規模なサーバを意味する。本発明の実施の形態では、車載クラウドレット４ａは、自らのセンサによって周辺の環境情報を取得するとともに、周辺の他の車載クラウドレット４ｂ等から環境情報を受信し、管理する。環境情報は、例えば、周囲温度、路面温度、湿度、濃霧レベル、気圧、路面凍結状態、周囲画像、紫外線量、CO2量、PM2.5量、降水量、降雪量、ホワイトアウト状態量、交通量、避難所設置情報、通行止め情報、災害情報、観光情報等である。

以下、車載クラウドレット４ａと直接通信を行う装置を総称し、「通信ノード」と表記する。すなわち、周辺の他の車載クラウドレット４ｂ、路側クラウドレット５、ローカルサーバ６及びゲートウェイサーバ７は、車載クラウドレット４ａに対する通信ノードである。

路側クラウドレット５は、車両３が走行する道路の脇や交差点等に複数設置され、周辺の車載クラウドレット４と無線通信を行い、クラウドサーバ２が行う処理の一部又は全部を実行する。本発明の実施の形態では、路側クラウドレット５は、センサによって周辺の環境情報を取得し、車載クラウドレット４に送信する。

ローカルサーバ６は、例えば、遅延耐性ネットワークを構成する地域内に配置されるサーバ用コンピュータであり、１台の筐体で実現されても良いし、複数台の筐体で実現されても良い。

ゲートウェイサーバ７は、遅延耐性ネットワークを構成する地域内に配置され、無線通信とネットワーク８とのゲートウェイ機能を果たすサーバ用コンピュータであり、１台の筐体で実現されても良いし、複数台の筐体で実現されても良い。

クラウドサーバ２、ローカルサーバ６及びゲートウェイサーバ７は、制御部としてのＣＰＵ（「Central Processing Unit」の略）、主記憶部としてのメモリ、補助記憶部としてのＨＤＤ（「Hard Disk Drive」の略）やフラッシュメモリ、通信機器等を有する。補助記憶部には、ＯＳ（「Operating System」の略）、アプリケーションプログラム、処理に必要なデータ等が記憶されている。制御部は、補助記憶部からＯＳやアプリケーションプログラムを読み出して主記憶部に格納し、主記憶部にアクセスしながら、その他の機器を制御し、所定の処理を実行する。

図２は、車載クラウドレットの構成を示す図である。図２に示すように、本発明の実施形態における車載クラウドレット４は、各装置を制御する制御装置４０と、複数の無線方式によって通信ノードと通信を行う通信機器群４１と、周辺の環境情報を取得するセンサ群４２と、によって構成される。

制御装置４０は、制御部としてのＣＰＵ、主記憶部としてのメモリ、補助記憶部としてのＨＤＤやフラッシュメモリ等を有する。補助記憶部には、ＯＳ、アプリケーションプログラム、処理に必要なデータ等が記憶されている。制御部は、補助記憶部からＯＳやアプリケーションプログラムを読み出して主記憶部に格納し、主記憶部にアクセスしながら、その他の機器を制御し、後述する処理を実行する。

また、制御装置４０は、ＳＤＮ（Software Defined Network）技術によって通信機器群４１を制御するソフトウェアであるＳＤＮモジュール４０１と、通信ノード間を蓄積転送型通信でルーティングし、非同期にデータをやり取りするＤＴＮモジュール４０２と、負荷や処理量に応じてＶＭ（Virtual Machine：仮想マシン）の数を制御するＶＭ制御モジュール４０３と、車載クラウドレット４全体のリソース（資源）を管理するリソース管理モジュール４０４と、ＶＭの負荷量や稼働率を監視する負荷監視モジュール４０５と、道路状況を監視する仮想マシンである道路状況監視ＶＭ４０６と、災害情報データベースを管理する仮想マシンである災害情報データベース管理ＶＭ４０７と、所定の情報（＝本発明の実施の形態では、センサによって取得される環境情報）を記憶する車載データベース４０８がインストールされている。

ＳＤＮ技術は、通信機器群４１をソフトウェアで動的に制御する技術であり、経路制御とデータ転送の機能を分離したアーキテクチャを採用していることが特徴である。また、ＳＤＮ技術は、クロスレイヤ情報をネットワーク定義に取り扱うことを可能とする。例えば、ＭＡＣアドレスやＩＰアドレス、ＴＣＰ／ＵＤＰポート番号をネットワーク定義に利用したり、ブラウザ上に実装されるユーザインタフェースから経路情報を直接編集したり、外部データベース内に蓄積される情報から最適なネットワーク定義を導き出したりすることが可能である。

本発明の実施の形態では、ＳＤＮモジュール４０１は、複数の無線方式について、通信ノードとの間で通信が可能か否かを確認する通信可否確認手段と、通信ノードとの間で通信が可能な無線方式の中で最適な無線方式を決定する無線方式決定手段と、最適な無線方式を使ってデータの送受信を行うデータ送受信手段として制御装置４０を機能させるためのプログラムが含まれている。

ＤＴＮ技術は、オーバーレイ・ネットワークとして運用され、ソフトウェア上でオブジェクトを一意に識別するための識別子であるＵＵＩＤ（Universally Unique Identifier）を用いる。

本発明の実施の形態では、ＤＴＮモジュール４０２は、複数の無線方式の１つを使って周辺の通信ノードにブロードキャストを行い、応答があるか否かを確認する初期応答確認手段と、通信ノードから応答があると、通信ノードに自らの識別子（＝ＵＵＩＤ）及び複数の無線方式の接続情報を送信する接続情報送信手段と、通信ノーの識別子（＝ＵＵＩＤ）及び複数の無線方式の接続情報を受信する接続情報受信手段として制御装置４０を機能させるためのプログラムが含まれている。接続情報は、ＳＳＩＤ（Service Set Identifier）（＝ネットワーク名）、暗号化キー（＝パスワード）等を含む。

ＶＭ制御モジュール４０３は、ＶＭ（仮想マシン）の生成を行う。リソース管理モジュール４０４は、リソース（資源）を各ＶＭに割り当てる。負荷監視モジュール４０５は、制御部（ＣＰＵ）、主記憶部（メモリ）等の使用率や、補助記憶部（ＨＤＤやフラッシュメモリ）のデータの読み書き速度等を監視する。

ＶＭ（仮想マシン）は、制御部（ＣＰＵ）、主記憶部（メモリ）、補助記憶部（ＨＤＤやフラッシュメモリ）から成り、車載クラウドレット４上に生成される仮想的なコンピュータである。本発明の実施の形態では、道路状況監視ＶＭ４０６及び災害情報データベース管理ＶＭ４０７を例にして説明する。

車載データベース４０８は、センサ種別、時刻、送信元識別番号、場所、センサの計測値等の情報を格納する。車載データベース４０８は、例えば、特開２０１５−１７０３１１号公報に記載のプラグ・アンド・プレイ（Plug and Play）を応用した技術を用いて、未知のセンサデータであっても格納可能な柔軟性を有する。車載データベース４０８によって、いつ、だれが、どこで収集した何のデータかを統一的に管理することができる。

通信機器群４１は、複数の無線方式に対応する複数の通信機器の集合体である。無線方式としては、例えば、９２０ＭＨｚ帯無線、ＩＥＥＥ８０２．１１シリーズの規格に準拠したＷｉＦｉ（無線ＬＡＮ）、衛星回線、携帯電話回線（３Ｇ／ＬＴＥ）等が挙げられる。

本発明の実施の形態では、複数の無線方式を動的に切り替えて通信を行うために、コグニティブ無線技術を用いる。コグニティブ無線技術とは、端末や基地局等が周囲の電波状況をチェックし、その状況に応じて利用者に意識させることなく、無線方式を変えて通信する技術である。本発明の実施の形態では、特に、利用可能な既存の無線方式の利用環境をセンシングし、自動的に切り替えるヘテロジニアス型コグニティブ無線技術を用いる。

本発明の実施の形態では、車載クラウドレット４と通信ノードとの間の通信における無線方式として、例えば、周波数帯や規格が異なる９２０ＭＨｚ帯無線、５ＧＨｚ（ＩＥＥＥ８０２．１１ａ）、２．４ＧＨｚ（ＩＥＥＥ８０２．１１ｂ／ｇ／ｎ）の３種類の周波数帯の無線方式を用いることができる。また、クラウドサーバ２とゲートウェイサーバ７との間の通信として、例えば、有線通信である光ファイバ、衛星回線、携帯電話回線（３Ｇ／ＬＴＥ）等を用いることができる。

センサ群４２は、周辺の環境情報を取得するセンサの集合体である。センサとしては、例えば、赤外線温度センサ、雨量センサ、気圧センサ、湿度センサ、イメージセンサ、ＧＰＳセンサ、路面状況監視センサ等が挙げられる。

図３は、道路状況監視ＶＭの構成を示す図である。道路状況監視ＶＭ４０６は、センサ群４２によって取得されるセンサデータに基づいて道路状況を監視し、渋滞情報、通行止め、路面状況等を車両３に提示する。センサ群４２は、例えば、赤外線温度センサ４２１、気圧センサ４２２、雨量センサ４２３、湿度センサ４２４、画像センサ４２５、ＧＰＳセンサ４２６等である。道路状況監視ＶＭ４０６は、車載データベース４０８にアクセスし、各処理過程を制御するコントローラ４０６１と、センサ群４２からの信号の時間同期処理とノイズ除去処理を実行するプレフィルタ４０６２と、各センサ間の自己相関、相互相関、スペクトル解析を実行するアナライザ４０６３と、ビッグデータであるセンサデータを入力として人工知能技術によって路面状況（凍結、圧雪、乾燥、湿面、ホワイトアウト）等を決定するディシジョンメーカー４０６４と、車両３の表示端末に対して路面状況及び注意喚起を表示させるアラームインディケータ４０６５と、を含む。

図４は、災害情報データベースの管理方法を説明する図である。災害情報データベース管理ＶＭ４０７は、災害状況を監視し、災害情報の収集や伝達を行う。クラウドサーバ２は、全地域の災害情報を管理するグローバルデータベース２０を有する。グローバルデータベース２０は、車載データベース４０８と同一の情報を格納可能である。例えば、災害対策本部Ｈには、ネットワーク８を介してクラウドサーバ２と通信可能なゲートウェイサーバ７が設置されている。

ローカルサーバ６ａ〜６ｃは、主に局所地域の災害情報を管理するローカルデータベース６０ａ〜６０ｃを有する。ローカルデータベース６０ａ〜６０ｃは、車載データベース４０８と同一の情報を格納可能である。例えば、ローカルサーバ６ａ〜６ｃは、各避難所Ａ〜Ｃに設置されている。

車載クラウドレット４が搭載される車両３は、各避難所Ａ〜Ｃや災害対策本部Ｈを周回し、災害情報を収集したり、伝達したりする。車載クラウドレット４は、車両３が避難所Ａ〜Ｃに到着すると、ローカルサーバ６ａ〜６ｃと通信を行い、自らが備える車載データベース４０８とローカルデータベース６０ａ〜６０ｃとのデータを同期する。また、車載クラウドレット４は、車両３が災害対策本部Ｈに到着すると、ゲートウェイサーバ７及びネットワーク８を介してクラウドサーバ２と通信を行い、車載データベース４０８とグローバルデータベース２０とのデータを同期する。

図５は、路側クラウドレットの構成を示す図である。図５に示すように、本発明の実施形態における路側クラウドレット５は、各装置を制御する制御装置５０と、各装置に電力を供給する電源部５１と、複数の無線方式によって車載クラウドレット４と路車間通信を行う通信機器群５２と、周辺の環境情報を取得するセンサ群５３と、によって構成される。

制御装置５０、ＳＤＮモジュール５０１、ＤＴＮモジュール５０２、ＶＭ制御モジュール５０３、リソース管理モジュール５０４、負荷監視モジュール５０５、道路状況監視ＶＭ５０６、災害情報データベース管理ＶＭ５０７、通信機器群５２及びセンサ群５３は、車載クラウドレット４の制御装置４０、ＳＤＮモジュール４０１、ＤＴＮモジュール４０２、ＶＭ制御モジュール４０３、リソース管理モジュール４０４、負荷監視モジュール４０５、道路状況監視ＶＭ４０６、災害情報データベース管理ＶＭ４０７、通信機器群４１及びセンサ群４２と同様である。また、路側データベース５０８は、車載データベース４０８と同一の情報を格納可能である。

電源部５１は、風力発電装置５１１、太陽光発電装置５１２、電力制御装置５１３、バッテリ５１４等を備え、商用電源とは独立して電力を供給可能な自立電源として機能する。

図６〜図９は、車載クラウドレットの処理の流れを示すフローチャートである。車載クラウドレット４ａは、各通信ノードと通信を行いながら、所定の場所を周回する。車車間通信については、車載クラウドレット４ａがマスタ端末として機能し、車載クラウドレット４ｂがスレーブ端末として機能する。車載クラウドレット４ａは、例えば、路上を走行中の状態であり、車載クラウドレット４ｂは、例えば、駐車場等に停車中の状態である。路側クラウドレット５、ローカルサーバ６及びゲートウェイサーバ７は、所定の場所に載置されている。

以下では、説明の便宜上、プログラムとしての各モジュールを処理の主体として記述するが、実際には、これらのプログラムがインストールされたハードウエアである車載クラウドレット４が処理を実行する。

車載クラウドレット４ａのＶＭ制御モジュール４０３はＶＭを生成し、車載クラウドレット４ａのリソース管理モジュール４０４は、各ＶＭにリソース（資源）を割り当てる（ステップＳ１）。各ＶＭ（道路状況監視ＶＭ４０６、災害情報データベース管理ＶＭ４０７）は、各センサからデータを周期的にサンプリングし、車載データベース４０８に格納する（ステップＳ２）。

次に、車載クラウドレット４ａのＤＴＮモジュール４０２は、無線方式Ｒ０、例えば９２０ＭＨｚ帯無線を使って周辺の通信ノードにブロードキャストを行い、応答があるか否かの確認として接続要求を行う（ステップＳ３）。

ここで、通信機器群４１による複数の無線方式をＲ０〜Ｒｎとする。Ｒ０〜Ｒｎは互いに波長や通信可能距離が異なる。波長や通信可能距離の関係はＲ０＞Ｒ１＞Ｒ２・・・＞Ｒｎとする。従って、無線方式Ｒ０は最も波長が大きく、送電電力が同一とすると、通信可能距離が最も大きい。これによって、通信ノードが遠方にいる間に通信確立処理（ステップＳ１１〜ステップＳ１８、ステップＳ３１〜Ｓ４０、ステップＳ５１〜ステップＳ５８）を実行し、通信ノードに接近した状態では、最適な無線方式を用いて実データ（＝本発明の実施の形態ではセンサデータ）の転送から開始できるので、効率的なデータ転送が可能となる。尚、無線方式Ｒ０は、ＳＳＩＤを公開し、暗号化キーを使わずにブロードキャスト通信を行うものとする。

通信ノードから応答がない場合（ステップＳ３のＮｏ）、車両３ａは次の場所に移動し（ステップＳ４）、車載クラウドレット４ａはステップＳ３２の処理から繰り返す。応答がある場合（ステップＳ３のＹｅｓ）、車載クラウドレット４ａのＤＴＮモジュール４０２は、応答があった通信ノードが、ローカルサーバ６、ゲートウェイサーバ７、路側クラウドレット５及び他の車載クラウドレット４ｂのいずれであるかを確認する（ステップＳ５）。

ステップＳ５において、応答があった通信ノードがローカルサーバ６の場合（ステップＳ５の「ローカルサーバ」）、車載クラウドレット４ａのＤＴＮモジュール４０２は、自らのＵＵＩＤと無線方式Ｒ１〜Ｒｎの接続情報をローカルサーバ６に送信し（ステップＳ１１）、ローカルサーバ６のＵＵＩＤと無線方式Ｒ１〜Ｒｎの接続情報を受信する（ステップＳ１２）。無線方式Ｒ１〜Ｒｎの接続情報は、それぞれのＳＳＩＤや暗号化キー等である。

車載クラウドレット４ａのＳＤＮモジュール４０１は、ローカルサーバ６の無線方式Ｒｉ（ｉ＝１〜ｎ）に通信可能か否かの確認として接続要求を行う（ステップＳ１３）。応答がある場合（ステップＳ１３のＹｅｓ）、車載クラウドレット４ａのＳＤＮモジュール４０１は、無線方式Ｒｉを接続候補に設定し（ステップＳ１４）、ステップＳ１５に進む。応答がない場合（ステップＳ１３のＮｏ）、車載クラウドレット４ａのＳＤＮモジュール４０１は、何もせずにステップＳ１５に進む。

ステップＳ１５では、車載クラウドレット４ａのＳＤＮモジュール４０１は、ｉ＝ｎか否か、すなわち全ての無線方式ＲｉについてステップＳ１３〜Ｓ１４の処理を終えたか否か確認する。ｉ＝ｎではない場合（ステップＳ１５のＮｏ）、車載クラウドレット４ａのＳＤＮモジュール４０１は、ｉに１を加算し（ステップＳ１６）、ステップＳ１３から繰り返す。ｉ＝ｎの場合（ステップＳ１５のＹｅｓ）、車載クラウドレット４ａのＳＤＮモジュール４０１は、ステップＳ１７に進む。

ステップＳ１７では、車載クラウドレット４ａのＳＤＮモジュール４０１は、接続候補の無線方式の中から最適な無線方式Ｒｏｐｔを決定する。最適な無線方式の決定処理については図１０を参照しながら後述する。

次に、車載クラウドレット４ａのＳＤＮモジュール４０１は、ローカルサーバ６との間で無線方式Ｒｏｐｔによる通信を確立する（ステップＳ１８）。ここまでが通信確立処理であり、以降は、データ転送の処理となる。

車載クラウドレット４ａのＳＤＮモジュール４０１は、通信機器群４１のうち最適な無線方式Ｒｏｐｔに関する通信機器を用いて、ローカルサーバ６のローカルデータベース６０にアクセス要求を行い、お互いにデータベースレベル間の接続を確立する（ステップＳ１９）。

次に、車載クラウドレット４ａのＶＭは、前回転送時からの車載データベース４０８の差分のデータを送信するとともに（ステップＳ２０）、前回転送時からのローカルデータベース６０の差分のデータを受信し、お互いのデータベースのデータを同期し、受信完了を示すＡｃｋを送信する（ステップＳ２１）。

次に、車載クラウドレット４ａのＳＤＮモジュール４０１は、データベースレベル間の接続を開放し（ステップＳ２２）、通信レベルの接続を開放し（ステップＳ２３）、ステップＳ２から処理を繰り返す。

ステップＳ５の条件分岐の説明に戻る。応答があった通信ノードがゲートウェイサーバ７の場合（ステップＳ５の「ゲートウェイサーバ」）、車載クラウドレット４ａのＤＴＮモジュール４０２は、自らのＵＵＩＤと無線方式Ｒ１〜Ｒｎの接続情報をゲートウェイサーバ７に送信し（ステップＳ３１）、ゲートウェイサーバ７のＵＵＩＤと無線方式Ｒ１〜Ｒｎの接続情報を受信する（ステップＳ３２）。

ステップＳ３３〜ステップＳ３８の処理は、ステップＳ１３〜Ｓ１８の処理と同様であるため、説明を省略する。

車載クラウドレット４ａのＳＤＮモジュール４０１は、クラウドサーバ２に接続要求し、応答があるか否か確認する（ステップＳ３９）。応答がない場合（ステップＳ３９のＮｏ）、車載クラウドレット４ａのＳＤＮモジュール４０１は、所定の回数までステップＳ３９の処理を繰り返す。応答がある場合（ステップＳ３９のＹｅｓ）、車載クラウドレット４ａのＳＤＮモジュール４０１は、通信機器群４１のうち最適な無線方式Ｒｏｐｔに関する通信機器を用いて、クラウドサーバ２のグローバルデータベース２０にアクセス要求を行い、お互いにデータベースレベル間の接続を確立する（ステップＳ４０）。

次に、車載クラウドレット４ａのＶＭは、前回転送時からの車載データベース４０８の差分のデータを送信するとともに（ステップＳ４１）、前回転送時からのグローバルデータベース２０の差分のデータを受信し、お互いのデータベースのデータを同期し、受信完了を示すＡｃｋを送信する（ステップＳ４２）。

次に、車載クラウドレット４ａのＳＤＮモジュール４０１は、データベースレベル間の接続を開放し（ステップＳ４３）、通信レベルの接続を開放し（ステップＳ４４）、ステップＳ２から処理を繰り返す。

ステップＳ５の条件分岐の説明に戻る。応答があった通信ノードが路側クラウドレット５又は他の車載クラウドレット４ｂの場合（ステップＳ５の「路側クラウドレット又は他の車載クラウドレット」）、車載クラウドレット４ａのＤＴＮモジュール４０２は、自らのＵＵＩＤと無線方式Ｒ１〜Ｒｎの接続情報を路側クラウドレット５又は他の車載クラウドレット４ｂに送信し（ステップＳ５１）、路側クラウドレット５又は他の車載クラウドレット４ｂのＵＵＩＤと無線方式Ｒ１〜Ｒｎの接続情報を受信する（ステップＳ５２）。

ステップＳ５３〜ステップＳ５８の処理は、ステップＳ１３〜Ｓ１８の処理と同様であるため、説明を省略する。

車載クラウドレット４ａのＳＤＮモジュール４０１は、路側クラウドレット５又は他の車載クラウドレット４ｂのリクエストを受信し、リクエストに応じてセンサデータを路側クラウドレット５又は他の車載クラウドレット４ｂに送信する（ステップＳ５９）。

次に、車載クラウドレット４ａのＳＤＮモジュール４０１は、受信完了を示すＡｃｋを受信し、自らのリクエストを路側クラウドレット５又は他の車載クラウドレット４ｂに送信する（ステップＳ６０）。

次に、車載クラウドレット４ａのＳＤＮモジュール４０１は、リクエストに応じたセンサデータを路側クラウドレット５又は他の車載クラウドレット４ｂから受信し、受信したセンサデータを車載データベース４０８に記憶し（ステップＳ６１）、受信完了を示すＡｃｋを送信し（ステップＳ６２）、通信レベルの接続を開放し（ステップＳ６３）、ステップＳ３から処理を繰り返す。

ここで、図１０を参照しながら、ステップＳ１７における最適な無線方式の決定処理について説明する。図１０は、最適な無線方式の決定処理の流れを示すフローチャートである。車載クラウドレット４ａのＳＤＮモジュール４０１は、無線方式ごとのネットワーク性能を計測し、計測結果に基づいて最適な無線方式を決定する。具体的には、車載クラウドレット４ａのＳＤＮモジュール４０１は、無線方式ごとにスループット、遅延時間及びパケットロス率を測定し、スループット、遅延時間及びパケットロス率に基づく値を変数に含む評価関数の値を算出し、評価関数の値が最大の無線方式を最適な無線方式として決定する。これによって、ネットワークの状況に応じた最適な無線方式を用いて通信ノードと通信を行うことができる。

車載クラウドレット４ａのＳＤＮモジュール４０１に対しては、予め、スループット、遅延時間及びパケットロス率の３つの指標に対する重要性の重み（スループット、遅延時間、パケットロス率）＝（Ｘ、Ｙ、Ｚ）を設定しておく。例えば、スループット重視の場合、（Ｘ、Ｙ、Ｚ）＝（０．５、０．２、０．３）、遅延時間重視の場合、（Ｘ、Ｙ、Ｚ）＝（０．２、０．５、０．３）のように設定する。これによって、ネットワーク性能に関する要求を重みとして与えることができ、要求に沿った無線方式を用いて通信ノードと通信を行うことができる。

図１０に示すように、車載クラウドレット４ａのＳＤＮモジュール４０１は、ｉ＝１にセットし（ステップＳ７１）、無線方式Ｒｉによって複数個のプローブパケットを他の車載クラウドレット４ｂに送信する（ステップＳ７２）。

次に、車載クラウドレット４ａのＳＤＮモジュール４０１は、他の車載クラウドレット４ｂからＡｃｋを受けた際の送信データ量、往復時間、パケット到着数を測定し、スループットの加重移動平均Ｔｉ、遅延時間の加重移動平均Ｄｉ、パケットロス率の加重移動平均Ｌｉを算出する（ステップＳ７３）。

災害状況下においてはネットワーク性能が常に不安定であることが想定されるため、ある無線方式における瞬間的なネットワーク性能の増減の発生により、他の無線方式よりも局所的にネットワーク性能が低下した状態が発生し、切り替え処理が断続的に起きる恐れがある。断続的な切り替え処理は、通信セッションの頻繁な切断やパケットロスの増大を引き起こすため、回避すべきものである。この問題を解決するために、車載クラウドレット４ａのＳＤＮモジュール４０１は、スループット、遅延時間及びパケットロス率を各々複数個算出し、スループットの加重移動平均、遅延時間の加重移動平均及びパケットロス率の加重移動平均を算出し、これらの値に基づいて最適な無線方式を決定する。

スループットの測定値をＴｉ（ｔ）とすると、スループットの加重移動平均Ｔｉは、Ｔｉ＝ａＴｉ（ｔ）＋ｂＴｉ（ｔ−１）＋ｃＴｉ（ｔ−２）となる。ここで、Ｔｉ（ｔ）が最新の測定値、Ｔｉ（ｔ−１）、Ｔｉ（ｔ−２）が過去の測定値を示す。また、（ａ、ｂ、ｃ）はそれぞれ測定時間ごとの重みを表す。例えば、最新の測定値の重みを６、１つ過去の測定値の重みを３、２つ過去の測定値の重みを１とする場合、（ａ、ｂ、ｃ）＝（０．６、０．３、０．１）となる。

同様に、遅延時間の測定値をＤｉ（ｔ）とすると、遅延時間の加重移動平均Ｄｉは、Ｄｉ＝ａＤｉ（ｔ）＋ｂＤｉ（ｔ−１）＋ｃＤｉ（ｔ−２）となる。また、パケットロス率の測定値をＬｉ（ｔ）とすると、パケットロス率の加重移動平均Ｌｉは、Ｌｉ＝ａＬｉ（ｔ）＋ｂＬｉ（ｔ−１）＋ｃＬｉ（ｔ−２）となる。

次に、車載クラウドレット４ａのＳＤＮモジュール４０１は、スループットの加重移動平均Ｔｉ、遅延時間の加重移動平均Ｄｉ、パケットロス率の加重移動平均Ｌｉを正規化し、正規化スループットＳＴｉ、正規化遅延時間ＳＤｉ、正規化パケットロス率ＳＬｉを算出する（ステップＳ７４）。正規化によって、異なる無線方式であっても定量的な比較が可能となる。正規化スループットＳＴｉ、正規化遅延時間ＳＤｉ、正規化パケットロス率ＳＬｉは、次式に従って算出され、１〜１０の値を取り得る。

ここで、Ｔｍｉｎはスループットの最小値、Ｔｍａｘはスループットの最大値、Ｄｍｉｎは遅延時間の最小値、Ｄｍａｘは遅延時間の最大値、Ｌｍｉｎはパケットロス率の最小値、Ｌｍａｘはパケットロス率の最大値である。

次に、車載クラウドレット４ａのＳＤＮモジュール４０１は、評価関数Ｐｉの値を算出する（ステップＳ７５）。評価関数Ｐｉは、スループット、遅延時間及びパケットロス率に基づく値の加重平均である。具体的には、評価関数Ｐｉは、Ｐｉ＝Ｘ・ＳＴｉ＋Ｙ・ＳＤｉ＋Ｚ・ＳＤｉである。そして、車載クラウドレット４ａのＳＤＮモジュール４０１は、正規化スループットＳＴｉ、正規化遅延時間ＳＤｉ、正規化パケットロス率ＳＬｉを評価関数Ｐｉに代入することによって、評価関数Ｐｉの値を算出する。

次に、車載クラウドレット４ａのＳＤＮモジュール４０１は、ｉ＝ｍ（ｍは接続候補の数）か否か、すなわち全ての接続候補の無線方式Ｒｉについて処理を終えたか否か確認する。ｉ＝ｍではない場合（ステップＳ７６のＮｏ）、車載クラウドレット４ａのＳＤＮモジュール４０１は、ｉに１を加算し（ステップＳ７７）、ステップＳ７２から繰り返す。ｉ＝ｍの場合（ステップＳ７６のＹｅｓ）、車載クラウドレット４ａのＳＤＮモジュール４０１は、ステップＳ７８に進む。

ステップＳ７８において、車載クラウドレット４ａのＳＤＮモジュール４０１は、評価関数Ｐｉの値が最大となる無線方式Ｒｉを、最適な無線方式Ｒｏｐｔに決定する。

以上の通り、本発明の実施の形態における車載クラウドレット４ａによれば、通信ノードが遠方にいる間に最適な無線方式によって通信を確立し、通信ノードが接近した状態では実データの転送処理に集中することができるので、効率的なデータ転送を実現することが可能となる。

以上、添付図面を参照しながら、本発明に係る車載クラウドレット等の好適な実施形態について説明したが、本発明はかかる例に限定されない。当業者であれば、本願で開示した技術的思想の範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

１………遅延耐性ネットワーク分散システム
２………クラウドサーバ
３………車両
４………車載クラウドレット
５………路側クラウドレット
６………ローカルサーバ
７………ゲートウェイサーバ
８………ネットワーク
２０………グローバルデータベース
４０………制御装置
４０１………ＳＤＮモジュール
４０２………ＤＴＮモジュール
４０３………ＶＭ制御モジュール
４０４………リソース管理モジュール
４０５………負荷監視モジュール
４０６………道路状況監視ＶＭ
４０７………災害情報ＤＢ管理ＶＭ
４０８………車載データベース
４１………通信機器群
４２………センサ群
６０………ローカルデータベース

Claims

複数の無線方式によって通信ノードとの間で無線通信を行う車載クラウドレットであって、
前記無線方式の１つを使って周辺の前記通信ノードにブロードキャストを行い、応答があるか否かを確認する初期応答確認手段と、
前記通信ノードから応答があると、前記通信ノードに自らの識別子及び複数の前記無線方式の接続情報を送信する接続情報送信手段と、
前記通信ノードの識別子及び複数の前記無線方式の接続情報を受信する接続情報受信手段と、
複数の前記無線方式について、前記通信ノードとの間で通信が可能か否かを確認する通信可否確認手段と、
前記通信ノードとの間で通信が可能な前記無線方式の中で最適な前記無線方式を決定する無線方式決定手段と、
最適な前記無線方式を使ってデータの送受信を行うデータ送受信手段と、
所定の情報を記憶する車載データベースと、
を備え、
前記通信ノードは、少なくとも、前記車載データベースと同一の情報を格納可能なローカルデータベースを備えるローカルサーバと、規格が異なるネットワーク間の通信を中継するゲートウェイサーバとを含み、
前記データ送受信手段は、前記通信ノードが前記ローカルサーバの場合、前記ローカルデータベースと前記車載データベースとのデータを同期し、前記通信ノードが前記ゲートウェイサーバの場合、前記ゲートウェイサーバを介してクラウドサーバと通信を行い、前記クラウドサーバが備える前記車載データベースと同一の情報を格納可能なグローバルデータベースと前記車載データベースとのデータを同期する
ことを特徴とする車載クラウドレット。
前記無線方式決定手段は、前記無線方式ごとにスループット、遅延時間及びパケットロス率を測定し、前記スループット、前記遅延時間及び前記パケットロス率に基づく値を変数に含む評価関数の値を算出し、前記評価関数の値が最大の前記無線方式を最適な前記無線方式として決定する
ことを特徴とする請求項１に記載の車載クラウドレット。
前記無線方式決定手段は、前記スループット、前記遅延時間及び前記パケットロス率を各々複数個測定し、前記スループットの加重移動平均、前記遅延時間の加重移動平均及び前記パケットロス率の加重移動平均を算出し、前記スループットの加重移動平均、前記遅延時間の加重移動平均及び前記パケットロス率の加重移動平均を各々正規化した値を前記評価関数に代入することによって、前記評価関数の値を算出する
ことを特徴とする請求項２に記載の車載クラウドレット。
前記評価関数は、前記スループット、前記遅延時間及び前記パケットロス率に基づく値の加重平均である
ことを特徴とする請求項２又は請求項３に記載の車載クラウドレット。
複数の前記無線方式は、互いに通信可能距離が異なり、
前記初期応答確認手段において用いる前記無線方式は、最も通信可能距離が大きいものである
ことを特徴とする請求項１乃至請求項４のいずれかに記載の車載クラウドレット。