WO2018008587A1 - 移動体通信装置、移動体通信方法、及び移動体通信プログラム - Google Patents

Abstract

移動体通信装置は、第１の通信方式を用いて第１の移動体通信装置を経由してインターネットに接続する第１の通信経路と、第２の通信方式を用いて第２の移動体通信装置を経由してインターネットに接続する第２の通信経路とを検出する処理を動的に行う通信経路検出部３２と、検出された第１の通信経路及び第２の通信経路のうちのいずれかの通信経路を選択する通信経路管理部３４と、選択された通信経路を経由してインターネットに接続する処理を動的に行う通信部３５と、を有する。

Description

移動体通信装置、移動体通信方法、及び移動体通信プログラム

　本発明は、移動体通信装置、移動体通信方法、及び移動体通信プログラムに関する。

　特許文献１には、移動体端末とデータ通信装置とのデータ通信が通信障害の発生等によって通信不能となった際、移動体端末は該データ通信装置の送信データの送信要求を別のデータ通信装置に送信し、送信要求を受信した別のデータ通信装置は、データ通信装置の送信データの送信要求を所定のデータ管理装置に転送する。これを受信したデータ管理装置は、データ通信装置の送信データを別のデータ通信装置に送信し、別のデータ通信装置は、受信したデータ通信装置の送信データを移動体通信端末に転送するデータ通信装置が記載されている。

特開２００８－２８５６０号公報

　しかしながら、特許文献１に記載の従来技術では、移動体端末が通信を行うデータ通信装置は、必ずしも常に通信が継続できるように配置されているとは限らず、種々の要因によって通信が途切れてしまうことがあった。また、通信コスト（通信速度）を考慮して通信経路を選択することができなかった。

　本発明は、上記従来技術の課題を解決するためになされたものであり、通信可能な通信経路を把握し、通信コスト（通信速度）を動的に考慮して通信経路を選択して通信を継続することのできる移動体通信装置、移動体通信方法、及び移動体通信プログラムを提供することを目的とする。

　本発明に係る移動体通信装置は、インターネットに接続する移動体通信装置であって、
　第１の通信方式を用いて第１の移動体通信装置を経由して前記インターネットに接続する第１の通信経路と、第２の通信方式を用いて第２の移動体通信装置を経由して前記インターネットに接続する第２の通信経路とを検出する処理を行う通信経路検出部と、前記インターネットに接続する処理を行う通信部と、検出された前記第１の通信経路及び前記第２の通信経路のうちのいずれかの通信経路を選択し、前記通信部に、選択された前記通信経路を経由して前記インターネットに接続させる通信経路管理部と、を有する。

　本発明に係る移動体通信方法は、インターネットに接続するための移動体通信方法であって、第１の通信方式を用いて第１の移動体通信装置を経由してインターネットに接続する第１の通信経路と、第２の通信方式を用いて第２の移動体通信装置を経由してインターネットに接続する第２の通信経路とを検出する処理を行う通信経路検出ステップと、インターネットに接続する処理を行う通信ステップと、検出された前記第１の通信経路及び前記第２の通信経路のうちのいずれかの通信経路を選択し、前記通信ステップに、選択された前記通信経路を経由してインターネットに接続させる通信経路管理ステップと、を有する。

　本発明に係る移動体通信プログラムは、コンピュータをインターネットに接続させるための移動体通信プログラムであって、第１の通信方式を用いて第１の移動体通信装置を経由してインターネットに接続する第１の通信経路と、第２の通信方式を用いて第２の移動体通信装置を経由してインターネットに接続する第２の通信経路とを検出する処理を行う通信経路検出処理と、インターネットに接続する処理を行う通信処理と、検出された前記第１の通信経路及び前記第２の通信経路のうちのいずれかの通信経路を選択し、前記通信処理に、選択された前記通信経路を経由してインターネットに接続させる通信経路管理処理と、を前記コンピュータに実行させる。

　本発明によれば、通信可能な通信経路を把握し、通信コスト（通信速度）を動的に考慮して通信経路を選択して通信を継続することのできる移動体通信装置、移動体通信方法、及び移動体通信プログラムを提供することができる。

実施の形態１に係る移動体通信装置を搭載した複数車両がＩＰネットワーク通信及びＶ２Ｖ通信を行って互いに接続されている状態の一例を示す図である。 実施の形態１に係る移動体通信装置を搭載した特定の車両が他の車両との通信が可能かを調べるため、ブロードキャスト送信した結果他の車両との通信状態を把握した状態の一例を示す図である。 実施の形態１に係る移動体通信装置の車載通信機器の処理構成の一例を示すブロック図である。 実施の形態１に係る移動体通信装置を搭載した特定の車両が他の車両とＩＰネットワーク及びＶ２Ｖ通信を行って車車間通信を行っている一例を示すユースケース図である。 実施の形態２に係る移動体通信装置の車載通信機器の処理構成の一例を示すブロック図である。 実施の形態２に係る移動体通信装置を搭載した複数車両がＩＰネットワーク通信及びＶ２Ｖ通信を行って互いに接続されている状態の一例を示す図である。 実施の形態２に係る移動体通信装置を搭載した特定の車両が他の車両との通信が可能かを調べるため、ブロードキャスト送信した結果他の車両との通信状態を把握した状態の一例を示す図である。 実施の形態２に係る移動体通信装置を搭載した複数車両がＩＰネットワーク通信及びＶ２Ｖ通信を行って互いに接続されている状態の一例（時間経過後特定の車車間通信が不通になった場合）を示す図である。 実施の形態２に係る移動体通信装置を搭載した特定の車両が他の車両とＩＰネットワーク及びＶ２Ｖ通信を行って車車間通信を行っている一例を示すユースケース図である。 図９における車両Ｄの車両内アプリケーションの詳細な構成を示すユースケース図である。 図９における車両Ｃの車両内アプリケーションの詳細な構成を示すユースケース図である。 実施の形態１及び２における車載通信機器の変形例の構成を示すハードウェア構成図である。 実施の形態３における自動車通信システム装置を搭載した複数車両がＩＰネットワーク通信及びＶ２Ｖ通信を行って互いに接続されている状態の一例を示す図である。 実施の形態３における自動車通信システム装置を搭載した特定の車両が他の車両との通信が可能かを調べる為、ブロードキャストした結果他の車両との通信状態を把握した状態の一例を示す図である。 実施の形態３における自動車通信システム装置を搭載した各車両が具する通信コスト計算部において保有する重み付けテーブルの一例を示す図である。 実施の形態３における自動車通信システム装置を搭載した各車両が送信するデータのデータフォーマットの一例を示す図である。 実施の形態３における自動車通信システム装置を搭載した複数車両がＩＰネットワーク通信及びＶ２Ｖ通信を行って互いに接続されている状態の一例（通信コスト計算部により通信コストを計算し適切な接続経路を選択した場合）を示す図である。

　以下、図面を参照しながら本発明の実施の形態に係る移動体通信装置について説明する。なお、以下に記載する実施の形態は、本発明を具体化した一例であって、本発明の技術的範囲を限定する性格のものではない。また、以下に記載する各実施の形態の内容は適宜組み合わせることが可能である。さらに、以下で説明する本発明の実施の形態は、移動体通信方法、及び移動体通信プログラムの実施の形態として捉えることも可能である。

《１》実施の形態１
《１－１》構成
　図１は、本発明の実施の形態１に係る移動体通信装置を搭載した複数車両がＩＰネットワーク通信及びＶ２Ｖ通信を行って互いに接続されている状態の一例を示す図である。図１に示されるように、実施の形態１に係る移動体通信装置を搭載した複数車両（ＡからＤ）は通信を行って互いに接続されており、クラウド上に有るクラウドサーバ１０が提供するサービスを利用することができる。図１に示されるように、車両Ａ及び車両ＤはＩＰネットワーク通信を利用して直接クラウドサーバ１０と接続可能であるが、車両Ｂ及び車両Ｃはクラウドサーバ１０と直接接続可能ではない。車両Ｂ及び車両Ｃは、車両Ａ又は車両Ｄを経由してクラウドサーバ１０と接続する。この例ではクラウドサーバ１０はサービスＩＤとしてＣｓｒｖ１が割り当てられた提供サービス１、サービスＩＤとしてＣｓｒｖ２が割り当てられた提供サービス２、サービスＩＤとしてＣｓｒｖ３が割り当てられた提供サービス３を提供できることを示す。また、クラウドサーバ１０と車両Ａまたは車両Ｄとの通信はＩＰネットワーク２０で接続され、ＩＰネットワーク通信の通信コストは１であることを示している。車両Ａと車両Ｂとの通信及び車両Ｃと車両Ｄとの通信はそれぞれＶ２Ｖ通信ネットワーク２１で接続され、Ｖ２Ｖ通信の通信コストはそれぞれ３であることを示している。

　図２は、実施の形態１に係る移動体通信装置を搭載した特定の車両が他の車両（他車両）との通信が可能かを調べるため、ブロードキャスト送信した結果他の車両との通信状態を把握した状態の一例を示す図である。図２は片側２車線の左側通行を示す図であって、図２に示されるように、車両は、車両Ａから車両Ｈまでの８体であり、このうち、自車（自車両）は車両Ｂであるとする。車両Ａ、車両Ｃ、車両Ｄは車両Ｂにとって同じ方向へ進む並走車であり、車両Ｅ、車両Ｆ、車両Ｇ、車両Ｈは車両Ｂにとって逆方向へ進む対向車である。

　図２に示されるように、並走車と対向車はその車線を中央分離帯で仕切られており、車両Ａから車両Ｈは例えば高速道路を走行しているものとする。車両Ａから車両ＨはＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）ネットワーク通信又はＶ２Ｖ（Ｖｅｈｉｃｌｅ－ｔｏ－Ｖｅｈｉｃｌｅ）通信（以下、車車間通信ともいう）を行ってクラウドサーバ１０との通信が可能であり、今車両Ｂは他の車両との通信が可能か否か調べるために時間間隔をあけてブロードキャスト送信を繰り返し行う。

　図２に示される例では、車両Ａ、車両Ｄ、車両Ｅ、車両Ｆ、車両ＨがＩＰネットワーク通信でクラウドサーバ１０が提供するサービスを直接利用しているのに対し、車両Ｂは車両Ａ、車両Ｅ、車両ＨからＶ２Ｖ通信経由で通信を行い、車両Ｃ及び車両ＧはＶ２Ｖ通信ができない状態にあることを示している。また、この例では車両Ｅから車両Ｈまでの４体は、自車（車両Ｂ）の対向車であり、車車間通信（Ｖ２Ｖ通信）は各車両の動きに合わせ時々刻々と変化するため、このブロードキャスト送信はポーリング（ｐｏｌｌｉｎｇ）の様にある一定間隔で行われ、その度ごとに通信可能である車車間通信（Ｖ２Ｖ通信）を把握している。車両Ｂと、車両Ｅから車両Ｈまでの４体（第２の移動体通信装置）との間の通信（第２の通信経路）は、対向車同士の通信であり、一時的なもので安定した通信ではないため、車両Ｂは車両Ａ（第１の移動体通信装置）経由での通信（第１の通信経路）を確保し、車両Ｃは車両Ｄ経由での通信を確保している。

　この図２の車車間通信（Ｖ２Ｖ通信）の結果を踏まえて図１の説明に戻る。図１に示されるように、車両Ａの移動体通信装置のミドルウェア（以下、Ｍ／Ｗともいう）のＩＤはＭａ１であり、搭載されているアプリケーションはＡｐｐｌｉｃａｔｉｏｎ　ＩＤ（以下、ＡｐｐＩＤともいう）がＡａ１であるアプリ１とＡｐｐＩＤがＡａ２であるアプリ２である。自車である車両Ｂの移動体通信装置のミドルウェアのＩＤはＭｂ１であり、搭載されているアプリケーションはＡｐｐＩＤがＢｂ１であるアプリ３とＡｐｐＩＤがＢｂ２であるアプリ４である。車両Ｃの移動体通信装置のミドルウェアのＩＤはＭｃ１であり、搭載されているアプリケーションはＡｐｐＩＤがＢｂ２であるアプリ４とＡｐｐＩＤがＣｃ２であるアプリ５である。車両Ｄの移動体通信装置のミドルウェアのＩＤはＭｄ１であり、搭載されているアプリケーションはＡｐｐＩＤがＡａ１であるアプリ１とＡｐｐＩＤがＢｂ１であるアプリ３である。

　この時、自車は車両Ｂであり車両Ｂ内のＡｐｐｌｉｃａｔｉｏｎＩＤがＢｂ１であるアプリ３がクラウドサーバ１０の提供サービス２（以下、サービス２ともいう）を利用する場合を考える。ここで言う提供サービスとは、例えば、グーグル（Ｇｏｏｇｌｅ）（登録商標）による検索サービスであり、車両Ｂが車両Ａ経由（第１の通信経路）で検索ワードをサーバに転送し、サーバ側で検索を行い検索結果を車両Ｂに返信する。また、他の例としては、個々の車における運転操作情報（その車両の位置とその時の速度、加速度、エンジン回転数等）を収集して前を走る車両との衝突を防ぐための車間距離管理アプリなどが考えられる。

　図２に示されるように、車両ＡはＩＰネットワーク通信でクラウドサーバ１０にアクセスでき、この時の通信コストは１である。ここで言う通信コストとは通信時の通信速度を意味するものであり、通信コストの値が小さい方がリッチな通信（通信速度が速い）であり、通信コストの値が大きい方がプアな通信（通信速度が遅い）である。自車である車両Ｂは直接ＩＰネットワーク通信をしているのではなく、車両Ａと車両Ｂとの間のＶ２Ｖ通信により車両Ａ経由でクラウドサーバ１０にアクセスしており、Ｖ２Ｖ通信の通信コストが３であることから車両Ｂの通信コストは４（１＋３＝４）となる。車両ＤはＩＰネットワーク通信でクラウドサーバ１０にアクセスでき、この時の通信コストは１である。車両Ｃは直接ＩＰネットワーク通信をしているのではなく、車両Ｄと車両Ｃとの間のＶ２Ｖ通信（通信コスト３）により車両Ｄ経由でクラウドサーバ１０にアクセスしており、車両Ｃの通信コストは４（１＋３＝４）となる。また、車両Ｂと車両Ｃとの間ではＶ２Ｖ通信を行っていない。

　今は車両Ｂのアプリ３が提供サービス２を利用するので、車両Ｂは車両Ａ経由でサービス２への送信データをクラウドサーバ１０に転送し、クラウドサーバ１０は転送された送信データを元にサービス２からの返信データを車両Ｂのアプリ３に返信する。この時の送信データ及び返信データは車両Ａを経由しているので通信コストは４となる。又、例えば車両Ｃのアプリ４がサービス２を利用する場合は、車両Ｃは車両Ｄ経由でサービス２への送信データをクラウドサーバ１０に転送し、クラウドサーバ１０は転送された送信データを元にサービス２からの返信データを車両Ｃのアプリ４に返信する。この時の送信データ及び返信データは車両Ｄを経由しているので通信コストは４となる。

　図３は、実施の形態１に係る移動体通信装置の制御系の一例を示すブロック図である。図３に示されるように、実施の形態１に係る移動体通信装置の制御系は、車載通信機器３０を有し、車載通信機器３０は通信管理部３１、通信経路検出部３２、通信コスト計算部３３、通信経路管理部３４、及び通信部３５を有する。通信部３５は、Ｖ２Ｖ通信部３８、４ｔｈ　Ｇｅｎｅｒａｔｉｏｎ通信部３６、Ｗｉ－Ｆｉ通信部３７を有する。Ｖ２Ｖ通信部３８、４ｔｈ　Ｇｅｎｅｒａｔｉｏｎ通信部３６、Ｗｉ－Ｆｉ通信部３７はマルチプロトコルで通信を行うものである（但し１つのプロトコルが１対１で例えばＶ２Ｖ通信部に対応するというものでは必ずしもない）。通信経路検出部３２は、１又は複数の通信経路を検出する。通信コスト計算部３３は、通信経路検出部３２により検出された通信経路の通信コストを計算する。通信管理部３１は、通信経路検出部３２と通信コスト計算部３３を管理することにより、全体の通信コストの管理を行う。通信経路管理部３４は、通信経路検出部３２により検出された通信経路のうちのいずれかの通信経路を選択し、通信部３５に対して、選択された通信経路を経由してインターネットに接続させる処理を行う。通信部３５は、通信経路管理部３４により選択された通信経路に対して、Ｖ２Ｖ通信部３８、４ｔｈ　Ｇｅｎｅｒａｔｉｏｎ通信部３６、Ｗｉ－Ｆｉ通信部３７のいずれかの通信部により通信を行う。

《１－２》動作
　図４は、実施の形態１に係る移動体通信装置を搭載した特定の車両が他の車両とＩＰネットワーク通信及びＶ２Ｖ通信を行って車車間通信を行っているユースケースの一例を示す図である。今、自車は車両Ｂであり車両Ａを経由してクラウドアプリケーションを利用するため、車両Ｂ内のアプリケーションがクラウドアプリケーションへデータを送受信する様子を示している。まず車両Ｂ内のアプリケーションは、種々のデータを収集して所望のサービスへの送信データを作成する（ステップＳ１００）。

　次に所望のサービスへの、通信経路検出部３２が認識した通信経路のコスト計算を、通信コスト計算部３３が行う（ステップＳ１０１）。そして所望のサービスへの送信データを送信する（Ｓ１０２）。

　車両Ｂは車両Ａ経由で送信データを送信するため、送信データをＶ２Ｖ通信で送信する（ステップＳ１０３）。次に、車両Ｂの内部において「送信データの送信を行う」と言う（ステップＳ１０４）。この処理は、マルチプロトコルライブラリ（マルチプロトコルを扱うＡＰＩの様なもの）をコールすることにより行われる。

　車両Ｂが車両ＡにＶ２Ｖ通信で送信データを送信したことにより、車両ＡのマルチプロトコルＭ／Ｗは車両Ｂからの送信データをＶ２Ｖ通信で受信する（ステップＳ１０５）。次に、車両Ｂの内部において「送信データの送信を行う」と言う（ステップＳ１０６）。この処理は、マルチプロトコルライブラリ（マルチプロトコルを扱うＡＰＩの様なもの）をコールすることにより行われる。ステップＳ１０６の処理が終わると、車両ＡのマルチプロトコルＭ／Ｗは、サービスへ送信データを送信する（ステップＳ１０７）。

　車両ＡはＩＰネットワーク２０でクラウドサーバ１０と接続されているため、クラウドサーバ１０のサービスへ送信データを送信する場合には、送信データをＩＰネットワーク２０経由でクラウドアプリケーションへ送信する（ステップＳ１０８）。次に、車両Ｂの内部において「送信データの送信を行う」と言う（ステップＳ１０９）。この処理は、マルチプロトコルライブラリ（マルチプロトコルを扱うＡＰＩの様なもの）をコールすることにより行われる。

　車両Ａからクラウドサーバ１０内のクラウドアプリケーションへ送信データを送信することにより、クラウドアプリケーションは、車両アプリケーションからの送信データをＩＰネットワーク２０経由で受信する（ステップＳ１１０）。そして送信データを元にクラウドアプリケーションは車両アプリケーションが利用できる受信データを作成する（ステップＳ１１１）。こうして作成されたクラウドアプリケーションからの返信データ（車両アプリケーションの受信データ）は受信データを車両ＡにＩＰネットワーク２０経由で送信され、Ｖ２Ｖ通信により車両Ａから車両Ｂに送信される（ステップＳ１１２）。

　車両ＡにＩＰネットワーク２０で送信された受信データは、車両ＡによってＩＰネットワーク２０で受信される（ステップＳ１１３）。次に、車両Ａの内部において「受信データの受信を行う」と言う（ステップＳ１１４）。こうして車両Ａの車内アプリケーションはクラウドサーバ１０のサービスからの受信データをマルチプロトコルライブラリから受信することができ（ステップＳ１１５）、車両Ａの車内アプリケーションもクラウドサーバ１０のサービスからの受信データを利用できる（ステップＳ１１６）。

　更に車両Ａは受信したデータをＶ２Ｖ通信により車両Ｂに送信する（ステップＳ１１７）。次に、車両Ａの内部において「受信データの送信を行う」と言う（ステップＳ１１８）。この時の処理はマルチプロトコルライブラリをコールして行われる。

　車両Ｂは車両Ａ経由で所望のサービスからのデータを受信するので、車両Ａから送信されてきた受信データをＶ２Ｖ通信で受信する（ステップＳ１１９）。次に、車両Ｂの内部において「受信データの受信を行う」と言う（ステップＳ１２０）。この時の処理は、マルチプロトコルライブラリをコールして行われる。こうして車両Ｂの車両内アプリケーションは所望のサービスからの受信データを受信することができ（ステップＳ１２１）、車両Ｂの車内アプリケーションは所望のサービスからの受信データを利用できる（ステップＳ１２２）。

《１－３》効果
　以上説明した本実施の形態１に係る移動体通信装置によれば、下記（１）の効果が得られる。
（１）本実施の形態１に係る移動体通信装置によれば、クラウドサーバ１０は特定のサービスを幾つか提供しており、各車両は車載ミドルウェアや車載アプリケーションを搭載し、ＩＰネットワーク通信やＶ２Ｖ通信を使って、クラウドサーバ１０の特定の提供サービスを利用することができる。自車である車両Ｂは、ＩＰネットワーク２０で直接クラウドサーバ１０と接続されている車両Ａ及び車両Ｄ経由でクラウドサーバ１０と接続することができ、クラウドアプリケーションの所望のサービスを利用することができる。

《２》実施の形態２
《２－１》構成
　以下、実施の形態２に係る移動体通信装置について説明する。実施の形態２に係る移動体通信装置は、通信経路管理部３４がデータ圧縮部３９を有する点について実施の形態１に係る移動体通信装置と異なる。実施の形態２に係る移動体通信装置について、通信経路管理部３４以外の車載通信機器３０の構成は実施の形態１のものと同じであるため、実施の形態１と同様の部分については、同一の符号を用い、説明を省略または簡略化する。

　図５は、実施の形態２に係る移動体通信装置の制御系の一例を示すブロック図である。図５に示されるように、実施の形態２に係る移動体通信装置の制御系は、車載通信機器３０を有し、車載通信機器３０は通信管理部３１、通信経路検出部３２、通信コスト計算部３３、通信経路管理部３４、通信部３５を有する。通信部３５は、Ｖ２Ｖ通信部３８、４ｔｈ　Ｇｅｎｅｒａｔｉｏｎ通信部３６、Ｗｉ－Ｆｉ通信部３７を有する。また、通信経路管理部３４は、データ圧縮部３９を有する。データ圧縮部３９は、選択された通信経路において通信コスト計算部３３により計算された通信コストが通信コスト閾値を上回っている場合に、フォーマットに従い送信データを圧縮する作業を行う。

　図６は、本発明の実施の形態２に係る移動体通信装置を搭載した複数車両がＩＰネットワーク通信及びＶ２Ｖ通信を行って互いに接続されている状態の一例を示す図である。この移動体通信装置を搭載した複数車両は実施の形態１と同様に通信を行って互いに接続されており、クラウド上にあるクラウドサーバ１０が提供するサービスを利用することができる。図６に示されるように、車両Ａ及び車両ＤはＩＰネットワーク通信を利用して直接クラウドサーバ１０と接続可能であるが、車両Ｂ及び車両Ｃはクラウドサーバ１０と直接接続可能ではない。車両Ｂ及び車両Ｃは、車両Ａ又は車両Ｄを経由してクラウドサーバ１０と接続する。この例ではクラウドサーバ１０はサービスＩＤとしてＣｓｒｖ１が割り当てられた提供サービス１、サービスＩＤとしてＣｓｒｖ２が割り当てられた提供サービス２、サービスＩＤとしてＣｓｒｖ３が割り当てられた提供サービス３を提供できることを示す。また、クラウドサーバ１０と車両Ａまたは車両Ｄとの通信はＩＰネットワーク２０で接続され、ＩＰネットワーク通信の通信コストは１であることを示している。車両Ａと車両Ｂとの通信、車両Ｂと車両Ｃとの通信、及び車両Ｃと車両Ｄとの通信はそれぞれＶ２Ｖ通信ネットワーク２１で接続され、Ｖ２Ｖ通信の通信コストはそれぞれ３であることを示している。通信コスト閾値は５であるものとして示す。

　図７は、実施の形態２に係る移動体通信装置を搭載した特定の車両が他の車両との通信が可能かを調べるため、ブロードキャスト送信した結果他の車両との通信状態を把握した状態の一例を示す図である。図６は片側２車線の左側通行を示す図であって、図６に示されるように、車両は、車両Ａから車両Ｈまでの８体であり、このうち自車は車両Ｂであるとする。この時、車両Ａ、車両Ｃ、車両Ｄは車両Ｂにとって同じ方向へ進む並走車であり、車両Ｅ、車両Ｆ、車両Ｇ、車両Ｈは車両Ｂにとって逆方向へ進む対向車である。この例では並走車と対向車はその車線を中央分離帯で仕切られており、車両Ａから車両Ｈは例えば高速道路を走行しているものとする。

　車両Ａから車両ＨはＩＰネットワーク通信又はＶ２Ｖ通信を行ってクラウドサーバ１０との通信が可能であり、今車両Ｂは他の車両との通信が可能か否か調べるためブロードキャスト送信を行う。この例では車両Ａ、車両Ｄ、車両Ｅ、車両ＦがＩＰネットワーク通信でクラウドサーバ１０が提供するサービスを直接利用しているのに対し、車両Ｂは車両Ａ、車両Ｃ、車両ＥからＶ２Ｖ通信を行い、車両Ｃも車両ＤからＶ２Ｖ通信経由で車両Ｂと通信を行い、又車両Ｇも車両ＦからＶ２Ｖ通信経由で車両Ｂと通信を行い、又車両Ｈは車両ＢとＩＰネットワーク通信及びＶ２Ｖ通信ができない状態にあることを示している。また、この例では車両Ｅから車両Ｈまでの４体は車両Ｂにとって対向車であり、車車間通信は各車両の動きに合わせ時々刻々と変化するため、このブロードキャスト送信はポーリングの様にある一定間隔で行われその度毎に通信可能である車車間通信を把握する必要がある。このため、車両Ｂと車両Ｅから車両Ｈまでの４体との通信は一時的なもので安定した通信は行えない状況であることから、車両Ｂは車両Ａ（第１の移動体通信装置）経由での通信（第１の通信経路）、並びに、車両Ｄ及び車両Ｃ（第２の移動体通信装置）経由での通信（第２の通信経路）を確保している。

　この図７の車車間通信の結果を踏まえて図６の説明に戻る。図６に示されるように、車両Ａの移動体通信装置のミドルウェア（以下、Ｍ／Ｗ）のＩＤはＭａ１であり、搭載されているアプリケーションはＡｐｐＩＤがＡａ１であるアプリ１とＡｐｐＩＤがＡａ２であるアプリ２である。自車である車両Ｂの移動体通信装置のミドルウェアのＩＤはＭｂ１であり、搭載されているアプリケーションはＡｐｐＩＤがＢｂ１であるアプリ３とＡｐｐＩＤがＢｂ２であるアプリ４である。車両Ｃの移動体通信装置のミドルウェアのＩＤはＭｃ１であり、搭載されているアプリケーションはＡｐｐＩＤがＢｂ２であるアプリ４とＡｐｐＩＤがＣｃ２であるアプリ５である。車両Ｄの移動体通信装置のミドルウェアのＩＤはＭｄ１であり、搭載されているアプリケーションはＡｐｐＩＤがＡａ１であるアプリ１とＡｐｐＩＤがＢｂ１であるアプリ３である。

　この時、自車は車両Ｂであり車両Ｂ内のＡｐｐｌｉｃａｔｉｏｎＩＤがＢｂ１であるアプリ３がクラウドサーバ１０の提供サービス２を利用する場合を考える。ここで言う提供サービスとは例えば、Ｇｏｏｇｌｅによる検索サービスでありこの時は車両Ｂが車両Ａ経由で検索ワードをサーバに転送し、サーバ側で検索を行い検索結果を車両Ｂに返信することであったり、他の例では、個々の車における運転操作情報（その車両の位置とその時の速度、加速度、エンジン回転数等）を収集して前を走る車両との衝突を防ぐための車間距離管理アプリであったりする。

　車両ＡはＩＰネットワーク通信でクラウドサーバ１０にアクセスでき、この時の通信コストは１である。自車である車両Ｂは直接ＩＰネットワーク通信をしているのではなく、車両Ａと車両Ｂとの間のＶ２Ｖ通信により車両Ａ経由でクラウドサーバ１０にアクセスしており、Ｖ２Ｖ通信の通信コストが３であるため車両Ａ経由での車両Ｂの通信コストは４（１＋３＝４）となる。また、車両ＤはＩＰネットワーク通信でクラウドサーバ１０にアクセスでき、この時の通信コストは１である。車両Ｃは直接ＩＰネットワーク通信をしているのではなく、車両Ｄと車両Ｃとの間のＶ２Ｖ通信（通信コスト３）により車両Ｄ経由でクラウドサーバ１０にアクセスしており、車両Ｃの通信コストは４となる。車両Ｂは車両Ｃとの間のＶ２Ｖ通信により車両Ｃと接続し、更に車両Ｃは車両Ｄとの間のＶ２Ｖ通信で車両Ｄ経由でクラウドサーバ１０にアクセスしており、車両Ｃ及び車両Ｄを経由した通信の通信コストは７（１＋３＋３＝７）となる。この様に本例では車両Ａ経由での通信経路、車両Ｃ及び車両Ｄ経由での通信経路の２つの通信経路を確保しているが、車両Ｂは通信速度のできるだけ早い方、即ち通信コストの小さい方の通信経路（車両Ａ経由での通信経路）を選択して通信する。

　今は車両Ｂのアプリ３がクラウドサーバ１０の提供サービス２を利用するので、車両Ｂは通信コストの小さい経路である車両Ａ経由の通信経路によりサービス２への送信データをクラウドサーバ１０に転送し、クラウドサーバ１０は転送された送信データを元にサービス２からの返信データを車両Ｂのアプリ３に返信する。この時の送信データ及び返信データは車両Ａを経由しているので通信コストは４（１＋３＝４）となる。

　この時の通信経路は車両Ａ経由であるため、その時のユースケース図は図４の通りであり実施の形態１にて説明済みのため、ここでは詳細な説明は割愛する。

　図８は、実施の形態２に係る移動体通信装置を搭載した複数車両がＩＰネットワーク通信及びＶ２Ｖ通信を行って互いに接続されている状態の一例（時間経過後特定の車車間通信が不通になった場合）を示す図である。実施の形態２において車車間通信は一旦確立されたが、車車間通信は各車両の動きに合わせ時々刻々と変化するため、自車である車両Ｂが再度ブロードキャスト送信を行った。この結果再度ブロードキャスト送信を行う前は、車両Ａ経由での通信、並びに、車両Ｃ及び車両Ｄ経由での通信を確保していたが、ここで車両Ａ経由でのＶ２Ｖ通信が途絶えてしまったため（図８において×印の箇所）、車両Ｃ及び車両Ｄ経由での通信を選択することとなったことを示す。

　車両ＤはＩＰネットワーク通信でクラウドサーバ１０にアクセスでき、この時の通信コストは１である。車両Ｃは直接ＩＰネットワーク通信をしているのではなく、車両Ｄと車両Ｃとの間のＶ２Ｖ通信により車両Ｄ経由でクラウドサーバ１０にアクセスしており、Ｖ２Ｖ通信の通信コストが３であることから車両Ｃの通信コストは４（１＋３＝４）となる。自車である車両Ｂは直接ＩＰネットワーク通信をしているのではなく、車両Ｃと車両Ｂとの間のＶ２Ｖ通信で車両Ｃ経由で車両Ｄに接続し、車両Ｄ経由でクラウドサーバ１０にアクセスしており、Ｖ２Ｖ通信の通信コストが３であることから車両Ｃ及び車両Ｄを経由した通信の通信コストは７（１＋３＋３＝７）となる。この場合は車両Ａ経由の通信よりも通信コストがかかる（即ち通信速度が遅くなる）ため、よりプアな通信経路（速度の遅い通信経路）を選択することとなっている。

　ここで車両Ｂは車両Ｃ及び車両Ｄを経由する通信経路を選択したことを把握している。本実施の形態に係る移動体通信装置は通信コストに閾値を設けておりその値は、例えば、５であるとする。この閾値を超えた通信経路で通信を行う場合は端末側（この場合は車両Ｂ）から送信するデータをメタデータ化（メタデータとは、データについてのデータという意味で、あるデータが付随して持つそのデータ自身についての付加的なデータを指す）して送信し通信負荷を下げることとする。この時図７には図示していないが、車両Ｂが現在通信している通信経路の通信コストが通信コスト閾値を上回っている場合はまず車両Ｂの車内アプリケーションが利用しようとしているクラウドサーバ１０の提供サービスに、通信コスト閾値を上回っている旨を送信する。車内アプリケーションから通信コスト閾値を上回っている旨を受信したクラウドサーバ１０の提供サービスは車内アプリケーションに対し、送信データをメタデータ化する際の要綱を記載した送信メタデータ化フォーマット（送信フォーマット）を送信する。この送信メタデータ化フォーマットを受信した車内アプリケーションはフォーマットに従い送信データをメタデータ化して所望のサービス（この場合はサービス２）を送信する。メタデータ化された送信データを受信した提供サービスはこのデータに基づいて返信データを車両Ｂに返信する。この様に送信データをメタデータ化することにより通信負荷を下げながらもある一定の通信品質を担保することが可能となる。

《２－２》動作
　図９は、実施の形態２に係る移動体通信装置を搭載した特定の車両が他の車両とＩＰネットワーク通信及びＶ２Ｖ通信を行って車車間通信を行っている一例を示すユースケース図である。図１０は、図９における車両Ｄの車両内アプリケーションの詳細な構成を示すユースケース図である。図１１は、図９における車両Ｃの車両内アプリケーションの詳細な構成を示すユースケース図である。図９において、車両Ｃ及び車両Ｄの車両内アプリケーションの構成は簡略化して示されており、図１０及び図１１にその詳細が記載されている。本ケースは送信データをメタデータ化して送ることを想定しているが、メタデータ化する前に車両アプリケーションが所望のサービスに通信コスト閾値を上回っている旨を送信しその返信として送信データをメタデータ化する際の送信メタデータ化フォーマットを返信する処理は記載していない。

　まず車両Ｂ内のアプリケーションは、種々のデータを収集して所望のサービスへの送信データを作成する（ステップＳ２００）。次に所望のサービスへの、通信経路検出部３２が認識した通信経路のコスト計算を、通信コスト計算部３３が行う（ステップＳ２０１）。この場合通信コスト閾値を上回っているため、当該サービスから提示された送信メタデータ化フォーマットに従い送信データをメタデータに圧縮する（ステップＳ２０２）。そして所望のサービスへ送信メタデータを送信する（ステップＳ２０３）。

　車両Ｂは車両Ｃ経由で送信メタデータを送信するため、送信メタデータをＶ２Ｖ通信で送信する（ステップＳ２０４）。次に、車両Ｂの内部において「送信メタデータの送信を行う」と言う（ステップＳ２０５）。この処理はマルチプロトコルライブラリ（マルチプロトコルを扱うＡＰＩの様なもの）をコールすることにより行われる。

　車両Ｂが車両ＣにＶ２Ｖ通信で送信メタデータを送信したため、車両ＣのマルチプロトコルＭ／Ｗは車両Ｂからの送信データをＶ２Ｖ通信で受信する（ステップＳ２０６）。次に、車両Ｃの内部において「送信データの受信を行う」と言う（ステップＳ２０７）。この処理はマルチプロトコルライブラリをコールすることにより行われる。

　車両Ｃは車両Ｄ経由で、車両Ｂから送信された送信データをＶ２Ｖ通信で送信する（ステップＳ２０８）。次に、車両Ｃの内部において「送信データの送信を行う」と言う（ステップＳ２０９）。この処理はマルチプロトコルライブラリをコールすることにより行われる。

　車両Ｃが車両ＤにＶ２Ｖ通信で送信データを送信したため、車両ＤのマルチプロトコルＭ／Ｗは車両Ｃからの送信データをＶ２Ｖ通信で受信する（ステップＳ２１０）。次に、車両Ｄの内部において「送信データの受信を行う」と言う（ステップＳ２１１）。この処理はマルチプロトコルライブラリをコールすることにより行われる。続けて、サービスへの送信データを送信する（ステップＳ２１２）。

　車両ＤはＩＰネットワーク２０で接続されているためサービスへの送信データを送信する場合には、送信データをＩＰネットワーク２０でクラウドアプリケーションへ送信する（ステップＳ２１３）。次に、車両Ｄの内部において「送信データの送信を行う」と言う（ステップＳ２１４）。

　車両Ｄからクラウドサーバ１０内のクラウドアプリケーションへ送信データを送信したためクラウドアプリケーションは、車両アプリケーションからの送信データをＩＰネットワーク２０で受信する（ステップＳ２１５）。そして送信データを元にクラウドアプリケーションは車両アプリケーションが利用できる受信データを作成する（ステップＳ２１６）。こうして作成されたクラウドアプリケーションからの返信データ（車両アプリケーションの受信データ）は車両Ｄを経由して車両Ｃに送信されるため、受信データを車両ＤにＩＰネットワーク２０で送信する（ステップＳ２１７）。

　車両ＤにＩＰネットワーク２０で送信された受信データは、車両ＤによってＩＰネットワーク２０で受信される（ステップＳ２１８）。次に、車両Ｄの内部において「受信データの受信を行う」と言う（ステップＳ２１９）。こうして車両Ｄの車内アプリケーションはサービスからの受信データをマルチプロトコルライブラリをコールして受信することができ（ステップＳ２２０）、車両Ｄの車内アプリケーションもサービスからの受信データを利用できる（ステップＳ２２１）。

　続いて車両Ｄから車両Ｃへ車両Ｄが受信したデータをＶ２Ｖ通信で送信する（ステップＳ２２２）。次に、車両Ｃの内部において「受信データの送信を行う」と言う（ステップＳ２２３）。車両Ｃの車両アプリケーションは、車両Ｄから送信された受信データをＶ２Ｖ通信で受信する（ステップＳ２２４）。次に、車両Ｃの内部において「受信データの受信を行う」と言う（ステップＳ２２５）。この処理はマルチプロトコルライブラリをコールすることにより行われる。こうして車両Ｃの車内アプリケーションはサービスから車両Ｄ経由で送信された受信データをマルチプロトコルライブラリから受信することができ（ステップＳ２２６）、車両Ｃの車内アプリケーションもサービスからの受信データを利用できる（ステップＳ２２７）。

　更に車両Ｃは受信したデータをＶ２Ｖ通信で車両Ｂに送信する（ステップＳ２２８）。次に、車両Ｃの内部において「受信データの送信を行う」と言う（ステップＳ２２９）。この処理はマルチプロトコルライブラリをコールして行われる。

　車両Ｂは車両Ｃ及び車両Ｄ経由で所望のサービスからのデータを受信するので、車両Ｃから送信されてきた受信データをＶ２Ｖ通信で受信する（ステップＳ２３０）。次に、車両Ｂの内部において「受信データの受信を行う」と言う（ステップＳ２３１）。この処理はマルチプロトコルライブラリをコールして行われる。こうして車両Ｂの車両内アプリケーションは所望のサービスからの受信データを受信することができ（ステップＳ２３２）、車両Ｂの車内アプリケーションは所望のサービスからの受信データを利用できる（ステップＳ２３３）。

《２－３》効果
　以上説明した本実施の形態２によれば、上記（１）の効果の他に、下記（２）及び（３）の効果が得られる。
（２）実施の形態２に係る移動体通信装置によれば、Ｖ２Ｖ通信やＩＰネットワーク通信を通じて自車の車内アプリケーションが複数の通信経路を保有する場合、それぞれの通信コストを考慮しながら動的にリッチな通信経路（速度の速い通信経路）を選択できることができる。
（３）実施の形態２に係る移動体通信装置によれば、通信障害等により現在使用している通信経路が使用不可となった場合でも別の通信経路を選択することが可能である。この際の通信経路がある通信コスト閾値以上の通信コストを持つ場合、送信データをメタデータ化して通信を継続することにより、通信負荷を下げながらも通信品質をある一定のレベルに担保することができる。

《変形例》
　図１２は、上記実施の形態１及び２に係る移動体通信装置の車載通信機器３０の変形例の構成を示すハードウェア構成図である。実施の形態１及び２に係る移動体通信装置の車載通信機器３０は、ソフトウェアとしてのプログラムを格納する記憶装置としてのメモリ９１と、メモリ９１に格納されたプログラムを実行する情報処理部としてのプロセッサ９２とを用いて（例えば、コンピュータにより）実現することができる。なお、図３及び図５に示される車載通信機器３０の一部を、図１２におけるメモリ９１とプロセッサ９２とによって実現してもよい。なお、本発明は、本発明の趣旨を逸脱しない範囲で、変更することが可能である。

《３》実施の形態３
《３－１》構成
　以下、実施の形態３における自動車通信システム装置を示す。本実施の形態３における自動車通信システム装置の中で、車載通信機器３０の構成は実施の形態１のものと同じである為、実施の形態１と同様の部分については、同一の符号を用い、説明を省略または簡略化する事とする。

　図１３は、実施の形態３における自動車通信システム装置を搭載した複数車両がＩＰネットワーク通信及びＶ２Ｖ通信を行って互いに接続されている状態の一例を示す図である。この自動車通信システム装置を搭載した複数車両は前述の様に通信を行って互いに接続されており、クラウド上に有るクラウドサーバ１０が提供するサービスを利用する事ができる。この例ではクラウドサーバ１０の提供するサービスは提供サービス１～３となっており、夫々サービスＩＤとしてＣｓｒｖ１～Ｃｓｒｖ３が割り当てられている。

　図１４は、実施の形態３における自動車通信システム装置を搭載した特定の車両が他の車両（他車両）との通信が可能かを調べる為、ブロードキャストした結果他の車両との通信状態を把握した状態の一例を示す図である。図１４は片側２車線の左側通行を示す図であって、図１４に示されるように、車両は、車両Ａから車両Ｈまでの８体であり、このうち自車（自車両）は車両Ｂであるとする。この時、車両Ａ、車両Ｃ、車両Ｄは車両Ｂにとって同じ方向へ進む並走車であり、車両Ｅ、車両Ｆ、車両Ｇ、車両Ｈは車両Ｂにとって逆方向へ進む対向車である。

　この例では並走車と対向車はその車線を中央分離帯で仕切られており、車両Ａ～車両Ｈは例えば高速道路を走行しているものとする。車両Ａ～車両ＨはＩＰネットワーク通信又はＶ２Ｖ通信を行ってクラウドサーバ１０との通信が可能である。車両Ｂは他の車両との通信が可能か否か調べる為ブロードキャストを行う。この例では車両Ａ、車両Ｄ、車両Ｅ、車両ＦがＩＰネットワーク通信でクラウドサーバ１０が提供するサービスを直接利用している。これに対し、車両Ｂは車両Ａ、車両Ｃ、車両Ｅから、車両Ｃも車両Ｄから、又車両Ｇも車両ＦからＶ２Ｖ通信経由で通信を行う。又、車両ＨはＩＰネットワーク通信及びＶ２Ｖ通信ができない状態にある事を示している。

　又この例では車両Ｅ～車両Ｈは対向車であり、車車間通信は各車両の動きに合わせ時々刻々と変化する為、このブロードキャストはポーリングの様にある一定間隔で行われその度毎に通信可能である車車間通信を把握する必要がある。この為、車両Ｂと車両Ｅ～車両Ｈの通信は一時的なもので安定した通信は行えない状況である事から、車両Ｂは車両Ａ→車両Ｂの形態で且つ車両Ｄ→車両Ｃ→車両Ｂの形態での通信を確保している。

　車両Ｄ→車両Ｃ→車両Ｂの形態での通信及び車両Ａ→車両Ｂの形態での通信について説明する。今、車両Ｄ及び車両Ｃは８０ｋｍ／ｈの速度で、車両Ｂは９０ｋｍ／ｈの速度で、車両Ａは１１０～１３０ｋｍ／ｈの速度で移動しているものとする。又、図示してはいないが車両Ｄ～車両Ｃ間の距離は２０ｍ、車両Ｃ～車両Ｂ間の距離は７０ｍ、車両Ｂ～車両Ａ間の距離は凡そ１２０ｍであるとする。即ち車両Ｄ、Ｃ、Ｂは纏まったグループとして走行しているのに対し、車両Ａは当該車両グループから離れた距離においてより離れようとしている。更に車両Ａは通信環境が悪くなるトンネルに差し掛かろうとしている。

　図１５は、実施の形態３における自動車通信システム装置を搭載した各車両が具する通信コスト計算部において保有する重み付けテーブルの一例を示す図である。重み付けとは次の様にある特定の路車間通信又は車車間通信において、重み付けテーブル３３ａに従った重みを付けて通信コスト計算部において通信コストを計算するものである。

　重み付けテーブル３３ａにおいて、例えば「通信種別：路車間通信」、「考慮すべきデータ：速度」の場合、路車間通信する車両が８０ｋｍ／ｈより小さい速度で走行しているのであれば上記の通信コストを計算する際の重みは１である。しかしながら、例えば１４０ｋｍ／ｈで走行している車両であれば通信コスト計算において重みは１．３となる。又、例えば「通信種別：車車間通信」、「考慮すべきデータ：相対速度」の場合、車車間通信する車両同士が相対速度１５ｋｍ／ｈで遠ざかっている（又は近づいている）のであれば通信コスト計算において重みは２となる。しかしながら、例えば４５ｋｍ／ｈで走行している車両であれば通信コスト計算において重みは５となる。

　又、重み付けテーブル３３ａにおいて、通信電力はＩＰネットワーク通信（路車間）及びＶ２Ｖ通信（車車間）の通信コスト計算に適用できるものである。例えば通信電力が－１５ｄＢならば重みは３、例えば２４ｄＢならば重みは１となる。又、更に、車車間通信する車両の位置情報とは自車に対して相手の車両が例えば通信環境が悪くなる”地下”に入った場合、重みは４となり、通信環境が若干悪くなる”ビルに囲まれた場所”に入った場合重みは２となる。

　図１６は、実施の形態３における自動車通信システム装置を搭載した各車両が送信するデータのデータフォーマットの一例を示す図である。特にこの場合は車両Ｃが車両Ｂに送信するデータ（車両Ｃの車両Ｂへの送信データ４０及び、車両Ｃの車両Ｂへの送信データの重畳ヘッダ４０ａ）を扱っている。車両Ｃの車両Ｂへの送信データ４０のうち、ＳＴＸは車両Ｃの送信データが開始する事を示す目印であり、ＥＴＸは車両Ｃの送信データが終了する事を示す目印であり、このＳＴＸとＥＴＸとの間に送信データ内容がある。

　そのうち、ペイロードは車両Ｃの送信データの本体部分であり、ヘッダはペイロードや車両Ｃの送信データ全体の管理情報等を格納するものである。本例ではこのヘッダの先頭部分に車両Ｄが車両Ｃに送信データを送信した際の車両Ｄの速度情報や位置情報、車両ＤがＩＰネットワーク通信でデータを受信した際のＨｏｐ数（ホップ数）、通信速度及び通信電力の各情報が重畳されている。更に車両Ｂは車両ＣからＶ２Ｖ通信でデータを受信する為先の重畳データに続けて、車両Ｃが車両Ｂに送信データを送信した際の車両Ｃの速度情報や位置情報、車両Ｃが車両Ｄから送信データを受信した際のＨｏｐ数、通信速度及び通信電力の各情報が重畳されている。

　以降の重畳データはＲｅｓｅｒｖｅｄとなっているが、Ｖ２Ｖ通信にて更なるコネクションが発生している場合はＨｏｐ３の重畳データ、Ｈｏｐ４の重畳データ、・・・と言う様にＲｅｓｅｒｖｅｄが埋められて行く（ＲｅｓｅｒｖｅｄはＨｏｐ数１つに対して３つの領域を消費するのであればＨｏｐ数の上限例えば１０（即ちＲｅｓｅｒｖｅｄ領域は上限３０）迄予め取っておく）。

　図１４～１６に関する上記説明を踏まえて図１３の説明に戻る。車両Ａにおいて、自動車通信システム装置のミドルウェア（以下、Ｍ／Ｗ）のＭ／Ｗ　ＩＤはＭａ１であり、搭載されているアプリケーションはアプリ１とアプリ２（夫々、Ａｐｐｌｉｃａｔｉｏｎ　ＩＤはＡａ１、Ａｓ２）である。自車である車両Ｂにおいて、自動車通信システム装置のミドルウェアのＭ／Ｗ　ＩＤはＭｂ１であり、搭載されているアプリケーションはアプリ３とアプリ４（夫々、Ａｐｐｌｉｃａｔｉｏｎ　ＩＤはＢｂ１、Ｂｂ２）である。車両Ｃにおいて、自動車通信システム装置のミドルウェアのＭ／Ｗ　ＩＤはＭｃ１であり、搭載されているアプリケーションはアプリ４とアプリ５（夫々、Ａｐｐｌｉｃａｔｉｏｎ　ＩＤはＢｂ２、Ｃｃ２）である。車両Ｄにおいて、自動車通信システム装置のミドルウェアのＭ／Ｗ　ＩＤはＭｄ１であり、搭載されているアプリケーションはアプリ１とアプリ３（夫々、Ａｐｐｌｉｃａｔｉｏｎ　ＩＤはＡａ１、Ｂｂ１）である。

　この時、自車は車両Ｂであり車両Ｂ内のＡｐｐｌｉｃａｔｉｏｎＩＤがＢｂ１であるアプリ３がクラウドサーバの提供サービス２を利用する場合を考える。ここで言う提供サービスとは例えば、Ｇｏｏｇｌｅによる検索サービスでありこの時は車両Ｂが車両Ａ経由で検索ワードをサーバに転送し、サーバ側で検索を行い、検索結果を車両Ｂに返信する事であったり、又他の例では個々の車における運転操作情報（その車両の位置とその時の速度、加速度、エンジン回転数等）を収集して前を走る車両との衝突を防ぐ為の車間距離管理アプリであったりする。

　車両ＡはＩＰネットワーク通信でクラウドサーバに直接アクセスできる。自車である車両Ｂは直接ＩＰネットワーク通信をしているのでは無く、車両Ａと車両Ｂとの間のＶ２Ｖ通信で車両Ａ経由でクラウドサーバにアクセスでき、車両Ａ→車両Ｂの通信コストは上記通信コスト計算式を基にすれば下記の通りとなる。

　これは主に図１３の説明の際に説明しているが、今車両Ａが１１０ｋｍ／ｈ～１３０ｋｍ／ｈであるので路車間通信（通信速度７Ｍｂｐｓ）の速度重みは１．２５、この時の路車間通信の通信電力が１２ｄＢとすれば電力重みは１、又、Ａ→Ｂの車車間通信（通信速度３Ｍｂｐｓ）の通信電力が９ｄＢであれば電力重みは１．５、車両Ａと車両Ｂの相対距離は１２０ｍなので相対距離重みは３、相対速度は２０～４０ｋｍ／ｈ（自車（車両Ｂ）が速度９０ｋｍ／ｈに対して車両Ａは速度１１０～１３０ｋｍ／ｈ）なので相対速度重みは４、相対速度変動率は１３０／１１０＝１．１８２（１８％）である為変動率重みは１．５、更に位置情報として車両Ａはトンネルに差し掛かっているので位置情報重みは３、である為である。

　又一方、車両ＤはＩＰネットワーク通信で直接クラウドサーバにアクセスできる。車両Ｃは直接ＩＰネットワーク通信をしているのでは無く、車両Ｄと車両Ｃとの間のＶ２Ｖ通信によって車両Ｄ経由でクラウドサーバにアクセスできる。車両Ｂは車両Ｃとの間のＶ２Ｖ通信によって、更に車両Ｃは車両Ｄとの間のＶ２Ｖ通信によって車両Ｄ経由でクラウドサーバにアクセスできる。車両Ｄ→車両Ｃ→車両Ｂの通信コストは上記通信コスト計算式を基にすれば下記の通りとなる。

　これは主に図１３の説明の際に説明しているが、今車両Ｄが８０ｋｍ／ｈであるので路車間通信（通信速度７Ｍｂｐｓ）の速度重みは１である。この時の路車間通信の通信電力が図１６の車両Ｄデータから２４ｄＢとすれば電力重みは１である。又、車両Ｄ→車両Ｃの車車間通信（通信速度３Ｍｂｐｓ）の通信電力が図１６の車両Ｃデータから１５ｄＢであれば電力重みは１であり、車両Ｄと車両Ｃの相対距離は２０ｍなので相対距離重みは１である。相対速度は０ｋｍ／ｈ（車両Ｄも車両Ｃも速度８０ｋｍ／ｈ）なので相対速度重みは１である。相対速度変動率は０％である為変動率重みは１である。更に位置情報は車両Ｄは通常の高速道路を走行しており電波環境に悪影響はない為位置情報重みは１である。

　更に、車両Ｃ→車両Ｂの車車間通信（通信速度３Ｍｂｐｓ）の通信電力が同じく１５ｄＢならば電力重みは１である。車両Ｃと車両Ｂの相対距離は７０ｍなので相対距離重みは２である。相対速度は１０ｋｍ／ｈ（車両Ｃが速度８０ｋｍ／ｈに対して自車（車両Ｂ）は速度９０ｋｍ／ｈ）なので相対速度重みは１である。相対速度変動率は０％である為変動率重みは１である。更に位置情報として車両Ｃは通常の高速道路を走行しており電波環境に悪影響はない為位置情報重みは１である。

　この様に本例では車両Ａ→車両Ｂ、車両Ｄ→車両Ｃ→車両Ｂの２つの通信経路を確保できるが、前車の通信コストは４．６５４８、後者の通信コストは３．９５２４であり、車両Ｂは通信ができるだけ安定的に供給される方、即ち通信コストの小さい方の通信経路を採択して通信する事となる。今は車両Ｂのアプリ３が提供サービス２を利用するので、車両Ｂは通信コストの小さい経路である車両Ｄ→車両Ｃ→車両Ｂでサービス２への送信データを該クラウドサーバ１０に転送し、クラウドサーバ１０は転送された該送信データを元にサービス２からの返信データを車両Ｂのアプリ３に返信する。

　この時の通信経路は車両Ｄ→車両Ｃ→車両Ｂである為、その時のユースケース図は図９～図１１の通りであり実施の形態２にて説明済みの為、ここでは詳細な説明は割愛する。

　図１７は、実施の形態３における自動車通信システム装置を搭載した複数車両がＩＰネットワーク通信及びＶ２Ｖ通信を行って互いに接続されている状態の一例（通信コスト計算部により通信コストを計算し適切な接続経路を選択した場合）を示す図である。本実施の形態３において安定供給要因を反映した通信コスト計算において、車両Ａ→車両Ｂの通信と車両Ｄ→車両Ｃ→車両Ｂの通信を比較した際、後者の通信コストの小さい方の安定的な通信経路即ち車両Ｄ→車両Ｃ→車両Ｂの形態での通信経路を採択する事となった。

《３－２》効果
　以上説明した本実施の形態３によれば、上記（１）、（２）の効果の他に、下記（３）の効果が得られる。
（３）本実施の形態では、自動車通信システム装置は実施の形態１、２とほぼ同じであるが、Ｖ２Ｖ通信やＩＰネットワークを通じて自車の車内アプリケーションが複数の通信経路を保有する場合、夫々の通信コストを考慮しながら動的に安定的な通信経路を選択できるものでありより確かな通信品質を担保する。ここで、通信コストとは安定的に通信を供給できる指標を指し、その値が小さい方が通信を安定的に供給でき、その値が大きい方が通信を安定的に供給できない。又、通信障害等により現在使用している通信経路が安定的に供給できなくなった場合でも別の安定的な通信経路を選択する事が可能である。ここでは自車が受信した通信データのヘッダ部にＨｏｐ数やデータを送信した車両の速度、位置情報、通信電力等の情報が重畳しており、ここで定義する通信コストの計算にこれら情報と、通信コスト計算部にて保有している通信コスト計算重み付けテーブルの重み情報とを参照して通信コストを計算する様になっており、より安定的な通信経路選択を選択できる。

　尚本発明は、上記実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の態様で実施する事ができる。

　Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ，Ｈ　車両、　１０　クラウドサーバ、　２０　ＩＰネットワーク、　３０　車載通信機器、　３１　通信管理部、　３２　通信経路検出部、　３３　通信コスト計算部、　３３ａ　重み付けテーブル、　３４　通信経路管理部、　３５　通信部、　３６　４ｔｈ　Ｇｅｎｅｒａｔｉｏｎ通信部、　３７　Ｗｉ－Ｆｉ通信部、　３８　Ｖ２Ｖ通信部、　３９　データ圧縮部、　４０　車両Ｃの送信データ、　４０ａ　車両Ｃの送信データの重畳ヘッダ、　９１　メモリ、　９２　プロセッサ。

Claims (18)

1. 　インターネットに接続する移動体通信装置であって、
   　第１の通信方式を用いて第１の移動体通信装置を経由して前記インターネットに接続する第１の通信経路と、第２の通信方式を用いて第２の移動体通信装置を経由して前記インターネットに接続する第２の通信経路とを検出する処理を行う通信経路検出部と、
   　前記インターネットに接続する処理を行う通信部と、
   　検出された前記第１の通信経路及び前記第２の通信経路のうちのいずれかの通信経路を選択し、前記通信部に、選択された前記通信経路を経由して前記インターネットに接続させる通信経路管理部と、
   　を有する移動体通信装置。
2. 　前記通信経路検出部は、前記第１の通信経路及び前記第２の通信経路を検出するためのブロードキャスト送信を時間間隔をあけて繰り返し行う
   　請求項１に記載の移動体通信装置。
3. 　検出された前記通信経路の通信速度を示す通信コストを計算する通信コスト計算部を更に有する
   　請求項１又は２に記載の移動体通信装置。
4. 　前記通信経路管理部は、前記通信コスト計算部により計算された前記通信コストのうちの、前記通信コストの値が最も小さい通信経路を選択する
   　請求項３に記載の移動体通信装置。
5. 　前記通信経路管理部は、選択された前記通信経路の通信が切断されたときに、前記通信経路検出部により検出された前記通信経路のうちの他の通信経路に切り替える処理を行う
   　請求項４に記載の移動体通信装置。
6. 　前記インターネットに送信する送信データを圧縮するデータ圧縮部を更に有し、
   　前記通信経路管理部は、選択された前記通信経路の前記通信コストが、ある通信コスト閾値以上である場合、前記データ圧縮部に前記送信データを圧縮させる
   　請求項３から５のいずれか１項に記載の移動体通信装置。
7. 　前記データ圧縮部は、前記送信データをメタデータ化することによって前記送信データを圧縮する
   　請求項６に記載の移動体通信装置。
8. 　前記通信経路管理部は、前記インターネット上のクラウドサーバから提供されたサービスが指定した送信フォーマットに従い前記送信データを前記データ圧縮部に圧縮させ、前記送信フォーマットに従い圧縮された前記送信データを前記通信部から前記クラウドサーバに送信させる
   　請求項６又は７に記載の移動体通信装置。
9. 　前記通信コスト計算部は、路車間通信を行っている車両の速度を考慮して前記通信コストの前記計算を行う
   　請求項３から８のいずれか１項に記載の移動体通信装置。
10. 　前記通信コスト計算部は、自車両と直接通信を行う他車両との相対距離及び相対速度を考慮して前記通信コストの前記計算を行う
    　請求項３から９のいずれか１項に記載の移動体通信装置。
11. 　前記通信コスト計算部は、自車両と直接通信を行う他車両との通信電力を考慮して前記通信コストの前記計算を行う
    　請求項３から１０のいずれか１項に記載の移動体通信装置。
12. 　前記通信コスト計算部は、自車両と直接通信を行う他車両との相対速度変動率を考慮して前記通信コストの前記計算を行う
    　請求項３から１１のいずれか１項に記載の移動体通信装置。
13. 　前記通信コスト計算部は、自車両と直接通信を行う他車両の位置情報を考慮して前記通信コストの前記計算を行う
    　請求項３から１２のいずれか１項に記載の移動体通信装置。
14. 　前記通信コスト計算部は、自車両と直接通信を行う他車両から受け取った通信コストに前記自車両と前記他車両との通信における通信コストを加算して前記通信コストの前記計算を行う
    　請求項３から１３のいずれか１項に記載の移動体通信装置。
15. 　前記通信部は、前記インターネット上のクラウドサーバから受信した受信データに対し、更に該受信データを受信した際の自車両の位置情報又は前記自車両の速度又は通信電力を重畳して次に伝送する
    　請求項１から１４のいずれか１項に記載の移動体通信装置。
16. 　前記通信部は、前記インターネット上のクラウドサーバから受信した受信データに対し、前記受信データを受信した際のホップ数及び通信速度を重畳して次に伝送する
    　請求項１から１５のいずれか１項に記載の移動体通信装置。
17. 　インターネットに接続するための移動体通信方法であって、
    　第１の通信方式を用いて第１の移動体通信装置を経由してインターネットに接続する第１の通信経路と、第２の通信方式を用いて第２の移動体通信装置を経由してインターネットに接続する第２の通信経路とを検出する処理を行う通信経路検出ステップと、
    　インターネットに接続する処理を行う通信ステップと、
    　検出された前記第１の通信経路及び前記第２の通信経路のうちのいずれかの通信経路を選択し、前記通信ステップに、選択された前記通信経路を経由してインターネットに接続させる通信経路管理ステップと、
    　を有する移動体通信方法。
18. 　コンピュータをインターネットに接続させるための移動体通信プログラムであって、
    　第１の通信方式を用いて第１の移動体通信装置を経由してインターネットに接続する第１の通信経路と、第２の通信方式を用いて第２の移動体通信装置を経由してインターネットに接続する第２の通信経路とを検出する処理を行う通信経路検出処理と、
    　インターネットに接続する処理を行う通信処理と、
    　検出された前記第１の通信経路及び前記第２の通信経路のうちのいずれかの通信経路を選択し、前記通信処理に、選択された前記通信経路を経由してインターネットに接続させる通信経路管理処理と、
    　を前記コンピュータに実行させる移動体通信プログラム。

Images