(57)【要約】【課題】車両等の移動体の走行状態から将来の移動予測を行って通信品質の変化を推定し、その推定された通信品質に基づいて最適な通信が行えるようにスケジューリングする。【解決手段】移動体の移動に伴う通信状態の変化に応じて通信のスケジューリングを行う移動体通信システムにおいて、移動体の走行状態を取得する走行状態取得手段と、移動体の走行に影響を及ぼす環境情報を取得する環境情報取得手段と、走行状態と環境情報から移動体の移動を予測する移動予測手段と、移動予測から無線通信品質の変化を推定する推定手段と、推定手段によって推定された通信品質に従って通信をスケジューリングするスケジューリング手段とを有する。【選択図】図２
2008199381.tif 000002
【特許請求の範囲】
【請求項１】
移動体の移動に伴う通信状態の変化に応じて通信のスケジューリングを行う移動体通信システムにおいて、
移動体の走行状態を取得する走行状態取得手段と、該移動体の走行に影響を及ぼす環境情報を取得する環境情報取得手段と、走行状態と該環境情報から該移動体の移動を予測する移動予測手段と、該移動予測から無線通信品質の変化を推定する推定手段と、該推定手段によって推定された通信品質に従って通信をスケジューリングするスケジューリング手段とを有することを特徴とする移動体通信システム。
【請求項２】
前記各手段は、移動体に搭載された車載端末内に備えられ、該スケジューリング手段によって決められたスケジュールに従って、該車載端末に接続されるセンタサーバとの間で通信することを特徴とする請求項１の移動体通信システム。
【請求項３】
前記各手段は、移動体に搭載された車載端末とネットワークを介して接続されるセンタサーバに備えられ、該スケジューリング手段によって決められたスケジュールに従って、該車載端末との間で通信することを特徴とする請求項１の移動体通信システム。
【請求項４】
前記走行状態取得手段は、該走行状態の情報として、経路、位置、平均車速、移動方向、電波強度の少なくとも１つの情報を該移動体の内部の機器から取得することを特徴とする請求項１乃至３のいずれかの移動体通信システム。
【請求項５】
前記走行状態取得手段は移動体の移動に関連する経路情報を取得し、前記環境情報取得手段は、取得された該経路情報が示す経路の渋滞情報と、該経路における通信の品質を示す通信品質情報を、前記環境情報として取得することを特徴とする請求項１乃至３のいずれかの移動体通信システム。
【請求項６】
前記移動体は、取得された該環境情報を記憶する記憶装置を備え、前記移動予測手段及び前記推定手段は、該記憶装置に記憶された該環境情報を用いて、該移動体の移動予測及び無線通信品質の変化を推定し、該移動体が非通信の状態にある時も前記スケジューリング手段は、該推定手段の推定結果に従ってスケジューリングを行うことを特徴とする請求項１乃至５のいずれかの移動体通信システム。
【請求項７】
ネットワークを介して外部から取得したリアルタイムの渋滞情報と通信品質情報を用いて、前記移動予測手段及び前記推定手段は、該移動体の移動予測及び無線通信品質の変化推定を行うことを特徴とする請求項５の移動体通信システム。
【請求項８】
経路上の信号機の位置と、該信号機で停止する確率の情報を取得し、該停止確率を用いて前記移動予測手段は移動予測を行うことを特徴とする請求項４の移動体通信システム。
【請求項９】
信号機で停止する確率情報を、複数の自動車の走行履歴から、曜日や時間帯毎によって統計的に処理して推定することを特徴とする請求項８の移動体通信システム。
【請求項１０】
前記スケジューリング手段は、通信品質に応じて１回に送信するデータサイズと送信間隔を変更するように通信をスケジューリングすることを特徴とする請求項１又は２の移動体通信システム。
【請求項１１】
複数データを送信する場合に、複数データを順次送信するように通信をスケジューリングすることを特徴とする請求項１０の移動体通信システム。
【請求項１２】
複数データを送信する場合に、複数データを並列送信するように通信をスケジューリングすることを特徴とする請求項１０の移動体通信システム。
【請求項１３】
送信するデータの優先度に応じて、優先度が高いデータを優先度が低いデータに比べて、送信するデータサイズが大きくなるように通信をスケジューリングすることを特徴とする請求項１２の移動体通信システム。
【請求項１４】
データが取得されてからの時間に比例して優先度が低くなることを特徴とする請求項１３の移動体通信システム。
【請求項１５】
一定時間毎に該環境情報を取得してスケジューリングし直して、リアルタイムに変化する渋滞に適応できるようにすることを特徴とする請求項１乃至３のいずれかの移動体通信システム。
【請求項１６】
サービスを提供するセンタサーバと接続され、移動体の移動に伴う通信状態の変化に応じて通信のスケジューリングを行う、移動体に搭載された車載端末において、
移動体の走行状態を取得する走行状態取得手段と、該移動体の走行に影響を及ぼす環境情報を取得する環境情報取得手段と、走行状態と該環境情報から該移動体の移動を予測する移動予測手段と、該移動予測から無線通信品質の変化を推定する推定手段と、該推定手段によって推定された通信品質に従って通信をスケジューリングするスケジューリング手段と、を有し、
該スケジューリング手段によって決められたスケジュールに従って、該車載端末に接続されるセンタサーバとの間で通信することを特徴とする車載端末。
【請求項１７】
請求項１６に記載の前記車載端末を搭載し、かつ取得された該環境情報を記憶する記憶装置を備えることを特徴とする車両。
【請求項１８】
移動体に搭載された車載端末にサービスを提供すると共に、該移動体の移動に伴う通信状態の変化に応じて通信のスケジューリングを行うセンタサーバにおいて、
移動体の走行状態を取得する走行状態取得手段と、該移動体の走行に影響を及ぼす環境情報を取得する環境情報取得手段と、走行状態と該環境情報から該移動体の移動を予測する移動予測手段と、該移動予測から無線通信品質の変化を推定する推定手段と、該推定手段によって推定された通信品質に従って通信をスケジューリングするスケジューリング手段と、を有し、
該スケジューリング手段によって決められたスケジュールに従って、該車載端末との間で通信することを特徴とするセンタサーバ。
【請求項１９】
移動体に搭載された車載端末に対して、ネットワークを介してセンタサーバよりサービスを提供し、該移動体の移動に伴う通信状態の変化に応じて通信のスケジューリングを行うスケジューリング方法であって、
移動体の走行状態を取得する走行状態取得ステップと、該移動体の走行に影響を及ぼす環境情報を取得する環境情報取得ステップと、走行状態と該環境情報から該移動体の移動を予測する移動予測ステップと、該移動予測から無線通信品質の変化を推定する推定ステップと、該推定によって推定された通信品質に従って通信をスケジューリングするスケジューリングステップと、を有し、該スケジューリングによって決められたスケジュールに従って、該車載端末とセンタサーバとの間で通信することを特徴とするスケジューリング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動体とセンタサーバとを無線で接続して通信する移動体通信システムに係り、特に、自動車などの移動体へ音楽などのコンテンツを配信したり、経路やエンジン状態などの車両情報をセンタサーバへアップロードするシステムに関する。更に詳しくは、移動体の移動に従って変化する通信状態を予測し、予測した通信状態に基づいて最適な通信を行うスケジューリング技術に関する。
【背景技術】
【０００２】
自動車に搭載した車載端末とセンタサーバとを無線ネットワークで接続し、渋滞情報や音楽コンテンツなどの配信を行うテレマティクスサービスが注目されている。現在、車載端末とセンタサーバとの接続には携帯電話が用いられている。自動車は高速で移動するため通信品質が変化しやすく、ネットワークが切断されやすい。また、自動車がトンネルなどの電波環境が悪い場所を走行する場合にもネットワークが切断されやすい。
【０００３】
ところで、ＴＣＰ／ＩＰ通信では、通信が途中で途切れた場合や通信品質が悪い場合に、必要以上に多くのデータを送信しようとすると、かえって送信可能なデータ量が低減してしまうという特性がある。また一般には、通信途中でエラーが発生すると、例外処理や再転送のための追加処理が必要となる。そのため、自動車などの移動体通信システムでは、通信を最適化するためにスケジューリングを行わなければならない。
【０００４】
移動体とセンタサーバとの間で効率的な通信を行うための技術として、無線の電波強度に応じてデータ転送速度を制御する方法が知られている。例えば、特許文献１（特開平８−３４０３０８号公報）に開示されているように、無線通信回線を用いた通信方式において、回線の電波強度を監視して通信可能か否かを判断し、通信不可能のときには、通信開始依頼があっても、通信可能な電波状態になるまで待ってから自動的に通信を開始する。また、回線の電波強度に応じて適切なデータ転送速度を選択する。このように制御することで、電波状態の変化に即応できるため、効率的な通信が可能となる。
【０００５】
また、特許文献２（特開２００１−２３０７３５号公報）には、移動局に積載された車載カメラにより進路上の電波遮蔽物を、相対的に移動する障害物を画像情報として捉え、その障害物の座標と通信相手の局の座標とを表現できる仮想空間において、障害物の座標と通信相手の局の座標とを結ぶ予測線を設定し、その予測線上の相対的な移動をもとに、その障害物が通信相手の局の座標に達する時間をあるいは通信相手の局の座標を過ぎ去る時間を予測することによって、通信障害の発生時期をあるいは通信障害の終了時期を予測し、さらに、この情報を元に通信網の通信回線や通信方式の一時的変更を行なって通信障害を回避する技術が開示されている。
【０００６】
【特許文献１】特開平８−３４０３０８号公報
【特許文献２】特開２００１−２３０７３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
然るに、上記特許文献１のように、無線の電波強度に応じてデータ転送速度を制御する方法では、急激に通信品質が変化する場合に対応できない。無線の電波強度は、ビルやトンネルなど遮蔽物の有無、基地局との距離、気温など、様々な要因によって変化する。自動車は高速で移動するため、電波強度が急激に変化しやすい。高速に移動するため、急にトンネルやビルの陰に入ったり、基地局が隣に移ったりする。電波強度が急激に変化すると、電波強度を計測した時の予想通信品質と比べて、実際に通信を開始した時の通信品質が劣化する可能性がある。そうすると、転送エラーなどが発生し、最適な通信を行うことができなくなる。
【０００８】
また、上記特許文献２のように、上述した車載カメラを用いた通信障害を回避する方法では、カメラで撮影可能な範囲だけしか通信品質を予測できない。道路は直線とは限らず、自動車は右左折する。そのため、車載カメラだけでの通信品質の予測には限界がある。また、カメラで撮影可能な範囲などの直近情報だけでは通信制御に限界がある。さらに、通信品質の変化は自動車の移動速度に依存するが、上述した車載カメラを用いた通信傷害を回避する方法では、移動速度の変化は予測していない。自動車の移動速度は、道路の混み具合、信号機の変わり具合などの要因に影響する。
【０００９】
本発明の目的は、車両等の移動体の走行状態から将来の移動予測を行って通信品質の変化を推定し、その推定された通信品質に基づいて最適な通信が行えるようにスケジューリングすることができる移動体通信システム、及びその方法、それに用いられる車載端末、車両、センタサーバを提供することにある。
【課題を解決するための手段】
【００１０】
本発明に係る移動体通信システムは、移動体の移動に伴う通信状態の変化に応じて通信のスケジューリングを行う移動体通信システムにおいて、移動体の走行状態を取得する走行状態取得手段と、移動体の走行に影響を及ぼす環境情報を取得する環境情報取得手段と、走行状態と環境情報から移動体の移動を予測する移動予測手段と、移動予測から無線通信品質の変化を推定する推定手段と、推定手段によって推定された通信品質に従って通信をスケジューリングするスケジューリング手段とを有することを特徴とする移動体通信システムとして構成される。
【００１１】
好ましい例では、前記各手段は、移動体に搭載された車載端末内に備えられ、スケジューリング手段によって決められたスケジュールに従って、車載端末に接続されるセンタサーバとの間で通信する移動体通信システムとして構成される。すなわち、車載端末として構成される。
また、他の好ましい例としては、前記各手段は、移動体に搭載された車載端末とネットワークを介して接続されるセンタサーバに備えられ、スケジューリング手段によって決められたスケジュールに従って、車載端末との間で通信する移動体通信システムとして構成される。すなわち、センタサーバとして構成される。
好ましくは、前記走行状態取得手段は、走行状態の情報として、経路、位置、平均車速、移動方向、電波強度の少なくとも１つの情報を移動体の内部の機器から取得する。
また、好ましくは、前記走行状態取得手段は移動体の移動に関連する経路情報を取得し、前記環境情報取得手段は、取得された経路情報が示す経路の渋滞情報と、経路における通信の品質を示す通信品質情報を、前記環境情報として取得する。
【００１２】
また、前記移動体は、取得された環境情報を記憶する記憶装置を備え、前記移動予測手段及び前記推定手段は、記憶装置に記憶された環境情報を用いて、移動体の移動予測及び無線通信品質の変化を推定し、移動体が非通信の状態にある時も前記スケジューリング手段は、推定手段の推定結果に従ってスケジューリングを行う。
また、好ましくは、ネットワークを介して外部から取得したリアルタイムの渋滞情報と通信品質情報を用いて、前記移動予測手段及び前記推定手段は、移動体の移動予測及び無線通信品質の変化推定を行う。
また、経路上の信号機の位置と、信号機で停止する確率の情報を取得し、停止確率を用いて前記移動予測手段は移動予測を行う。
また、信号機で停止する確率情報を、複数の自動車の走行履歴から、曜日や時間帯毎によって統計的に処理して推定する。
また、前記スケジューリング手段は、通信品質に応じて１回に送信するデータサイズと送信間隔を変更するように通信をスケジューリングする。
また、複数データを送信する場合に、複数データを順次送信するように通信をスケジューリングする。
また、複数データを送信する場合に、複数データを並列送信するように通信をスケジューリングする。
また、送信するデータの優先度に応じて、優先度が高いデータを優先度が低いデータに比べて、送信するデータサイズが大きくなるように通信をスケジューリングする。
また、データが取得されてからの時間に比例して優先度が低くなる。また、一定時間毎に環境情報を取得してスケジューリングし直して、リアルタイムに変化する渋滞に適応できるようにする。
【００１３】
本発明に係るスケジューリング方法は、好ましくは、移動体に搭載された車載端末に対して、ネットワークを介してセンタサーバよりサービスを提供し、移動体の移動に伴う通信状態の変化に応じて通信のスケジューリングを行うスケジューリング方法であって、移動体の走行状態を取得する走行状態取得ステップと、移動体の走行に影響を及ぼす環境情報を取得する環境情報取得ステップと、走行状態と環境情報から移動体の移動を予測する移動予測ステップと、移動予測から無線通信品質の変化を推定する推定ステップと、推定によって推定された通信品質に従って通信をスケジューリングするスケジューリングステップと、を有し、スケジューリングによって決められたスケジュールに従って、車載端末とセンタサーバとの間で通信することを特徴とするスケジューリング方法として構成される。
【発明の効果】
【００１４】
本発明によれば、平均車速や経路といった車両の走行状態を用いて将来の通信品質を推定することで、変化する通信品質を踏まえて通信をスケジューリングし、これにより最適な通信を実現することができる。また、エラーなどによる通信時間の増加を防ぐことができ、無駄な通信コスト増加を抑えたり、運転手へのコンテンツ提供のレスポンス悪化を抑えたりすることができる。
【００１５】
また、渋滞情報や信号機情報を用いて移動速度を推定することで、道の混み具合や信号機の変わり具合など、状況に最適な通信スケジューリングをすることができる。また、経路上を右左折する自動車に対して、最適な通信をスケジューリングすることができる。
【発明を実施するための最良の形態】
【００１６】
以下に、本発明の実施形態について、図を用いて以下で詳細に説明する。
[実施例１]
図１は、車両からセンタサーバにデータをアップロードする移動体通信システムの構成を示す。
このシステムは、車両１０１、センタサーバ１１１、渋滞情報管理サーバ１１３、通信品質管理サーバ１１４から構成される。ここで、センタサーバ１１１は車両１０１へコンテンツの提供サービスを行う会社が持つコンピュータであり、渋滞情報管理サーバ１１３は交通情報等の提供サービスを行う会社のコンピュータ、通信品質管理サーバ１１４は通信サービスを行うキャリアが持つコンピュータである。
【００１７】
車両１０１には、通信機器１０２、車載端末１０３、ハードディスク１０４、ＥＣＵ１０５が搭載される。ＥＣＵはElectric Control Unit（電子制御装置）で、車のエンジンや足回りなどの制御を行う。車載端末１０３とＥＣＵ１０５は車内ネットワーク１０７で接続されており、車載端末１０３は、エンジン回転数やアクセル開度といったＥＣＵ１０５が持っている情報を取得することができる。ハードディスク１０４は、ＥＣＵ１０５から収集した車両情報や、車載端末１０３が計算した経路情報、ドライバの車載端末の操作履歴などを記憶する。なおハードディスク以外にフラッシュメモリを用いても良い。また、車載端末１０３に内蔵されている記憶手段でも、ＵＳＢなどのケーブルで接続された外部記憶装置でも良い。
ハードディスク１０４に蓄積された情報は通信機器１０２を用いて携帯網１１０を介してセンタサーバ１１１にアップロードされる。通信機器１０２は、車両に組込みの通信モジュールでも良いし、外付けで接続された携帯電話などでも良い。
【００１８】
センタサーバ１１１はデータベース１１２を有し、そのデータベース１１２には、車両との接続に必要な認証情報や、車両からアップロードされた情報が格納される。センタサーバ１１１と渋滞管理サーバ１１３、通信品質管理サーバ１１４とはネットワークを介して接続される。このネットワークは優先接続でも良いし、無線接続でも良い。センタサーバ１１１は渋滞管理サーバ１１３から渋滞情報を取得し、通信品質管理サーバ１１４からは通信品質情報を取得することができる。
【００１９】
渋滞管理サーバ１１３は、リアルタイムの渋滞情報を提供するサーバである。例えば、プローブ交通情報サービスでは、複数の車両から、リアルタイムの位置や車速を吸い上げて渋滞情報を計算する。通信品質管理サーバ１１４は、リアルタイムの通信品質を提供するサーバである。ここで、通信品質とは、地図上の位置（車両の場所）における通信レートのことを言うものとする。詳しくは、図８を参照して後述する。
【００２０】
図２は、プログラムの実行によって実現される機能構成を示す。
以下に説明する諸機能は、車載端末１０３が有するＣＰＵ、及びサーバ１１１，１１３，１１４のＣＰＵでアプリケーションプログラムが実行されることで実現される。
車載端末１０３は、走行状態取得２０１、環境情報取得２０２、移動予測２０３、通信品質変化推定２０４、送信制御２０５、データ通信２０６を有する。
走行状態取得２０１は、車内ネットワーク１０７を介してＥＣＵ１０５から車速などの車両情報を取得する機能を備えている。もちろん、既にハードディスク１０４に蓄積済みの車両情報を取得することもできる。走行状態取得２０１は、またハードディスク１０４からドライバによって設定された経路情報などを取得する機能も備えている。経路情報などは、ハードディスク１０４からではなく、車載端末１０３がメモリに持っている情報を取得しても良い。
【００２１】
環境情報取得２０２は、通信品質情報や、通信品質に影響を与える渋滞情報などを取得する。環境情報は、データ通信２０６を介してセンタサーバ１１１から遂次取得しても良いし、或いは車両１０１のハードディスク１０４に既に格納された情報から取得しても良い。
移動予測２０３は、走行状態取得２０１で取得した経路や車速などの情報と、環境情報取得２０２で取得した渋滞情報から、経路上の移動に要する時間を予測する。渋滞がなく理想的に移動した場合の移動時間は、経路、制限速度などから予測することが可能である。また、渋滞情報に、どの地点でどの程度渋滞していてどのくらいのタイムロスが発生するかという情報を付け加えることで、渋滞を考慮した移動時間の予測が可能となる。さらに、地図情報に入っている信号機の位置情報を活用し、車が赤信号で停止することで発生するロスタイムを確率的に求めて利用することもできる。この赤信号で停止する確率は、地域などによって静的に設定しても良いし、時間帯や曜日毎に、実際の車が走行した履歴情報を統計的に処理して推定しても良い。
【００２２】
通信品質変化推定２０４は、環境情報取得２０２で取得した通信品質の情報と、移動予測２０３で予測した結果を基にして、時間による通信品質の変化を推定する。ここで、通信品質は、エラーが発生せずに、ネットワークに流せるデータの最大サイズで表す。送信制御２０５は、通信品質変化推定２０４で得られた結果に基づいて、どのくらいのデータ量をどの程度の間隔でネットワークに送信するのかスケジューリングし、データ通信２０６を介してスケジュールに基づいて送信する。
【００２３】
センタサーバ１１１は、データ通信２０７、環境情報提供２０８、受信制御２０９、受信データ統合２１０を有する。データ通信２０７は、車載端末１０３のデータ通信２０６と通信するための機能である。環境情報提供２０８は、環境情報取得２０２からの要求に基づいて、渋滞情報管理サーバ１１３に問い合わせて渋滞情報を取得し、通信品質管理サーバ１１４に問い合わせて通信品質情報を取得し、取得した渋滞情報と通信品質情報を含む環境情報として応答する。
【００２４】
渋滞情報管理サーバ１１３は、渋滞情報管理２１１、渋滞情報２１２を有し、渋滞情報管理２１１が環境情報提供２０８からの要求に基づいて渋滞情報を応答する。また、通信品質管理サーバ１１４は、通信品質管理２１３、通信品質２１４を有し、通信品質管理２１３が環境情報提供２０８からの要求に基づいて通信品質情報を応答する。
センタサーバ１１１において、受信制御２０９は、車載端末１０３から分割して送られてきたデータを受信する。受信制御２０９は、どのデータを受信したのかを管理しており、通信エラーなどにより受信が完了しなかった場合には、再接続時に途中から再開することができるレジューム機能を備えている。なお、レジュームしないで、最初から送りなおすことも可能である。受信データ統合２１０は、受信制御２０９で受信した分割データ群を統合して元のデータに戻し、データベース１１２に蓄積する。データベース１１２に蓄積する場合に、世代管理をしても良い。新たに格納しようとしているデータと同じ名前のデータが既に格納されている場合には、既に格納されているデータを、名前を変更して別領域にバックアップしておく。この世代管理は、システムの設定値として設定できるようにしても良いし、車載端末１０３からデータを送信する際に指定できるようにしても良い。
【００２５】
ここで、図１１を参照して、車両１０１のハードディスク１０４に記憶されるデータの記憶形式について説明する。ハードディスク１０４は、センタサーバ１１１へ送信するデータに関する、ＩＤ１１０１、データ種別１１０２、取得時刻１１０３、データ値１１０４を記憶する。ここで、ＩＤ１１０１は送信データ（例えばファイルのレコード）を一意に識別する。データ種別１１０２は優先度などを決めるためのデータ種別を表す。データ値１１０４はデータの中身を表し、取得時刻１１０３はデータを取得した時間を表す。
【００２６】
図３は、車載端末１０３における通信品質に応じた最適通信処理のフローを示す。
まず、走行状態や渋滞状況、通信品質といった車両の移動を予測するうえで必要となる情報を取得する（ステップ３０１）。次に、取得した関連情報に基づいて、ある時間に車両がどの位置にいるのかの移動予測を行う（ステップ３０２）。次に、得られた移動予測に基づいて車両が移動した場合に、通信品質がどのように変化しているかの推定を行う（ステップ３０３）。最後に、得られた通信品質の変化に基づいて、どのデータを、どのぐらいのサイズに分割し、どのタイミングで送信するかのスケジューリング処理することで、時間で変化する通信品質に応じた最適な通信を可能にする（ステップ３０４）。なお、各ステップの処理について、以下詳細に説明する。
【００２７】
次に、図７及び図８を参照して、通信品質の変化の推定について説明する。
通信品質は、データの通信レートで表わされ、それは車両の場所（位置）に依存する。
（Ａ）は、メッシュに区切られた場所と、その場所の道路の様子を示す。また、（Ｂ）は、（Ａ）の場所における各メッシュの通信品質を示す。メッシュ毎に通信品質が決まっており、メッシュ内部は同じ通信品質を得ることができる。例えば、Ａ１にいる期間は、１秒間に１０ＫＢｙｔｅのデータを送信可能であること示す。
【００２８】
ここで、（Ａ）において、車両がＸ地点からＹ地点へ移動する時、Ｄ１→Ｄ２→Ｃ２→Ｃ３→Ｃ４→Ｂ４とメッシュを移動することになる。この期間に通信品質は、５ＫＢｙｔｅ（Ｄ１）→１５ＫＢｙｔｅ（Ｄ２）→５ＫＢｙｔｅ（Ｃ２）→１０ＫＢｙｔｅ（Ｃ３）→５ＫＢｙｔｅ（Ｃ４）→１５ＫＢｙｔｅ（Ｂ４）の順で変化する。この品質で通信できる時間は、移動速度などによって変化する。この例では、４×４のメッシュに区切られおり、一つのメッシュのサイズが十分大きくなっているが、実際にはメッシュは限りなく小さくなるため、通信品質はなめらかな曲線で変化することになる。通信品質の情報は、過去の統計から平均的な通信品質を算出することで得ることができ、通常、通信キャリア会社が有している。通信品質は電波を遮る遮蔽物によっても変化するため、通信品質情報の精度をあげるために、定期的に車を走らせて通信品質を計測する方法や各地点を走行中の多数の車両と通信することにより計測する方法もある。通信品質は天気や温度、時間帯などによっても左右されるため、より細かい条件化での測定が必要となる。
【００２９】
図８は、通信品質に応じたデータ分割サイズや送信間隔の求め方を示す概念図である。
（Ａ）は、時間によって送信可能なデータサイズの上限（通信品質）を示す。通信品質は、なめらかな曲線を描きながら変化する。また、トンネルなどに入った場合には、全く通信できない状況となる場合もある。（Ｂ）は、時間で変化する通信品質に対して、データの分割サイズや送信間隔の決め方を示す。棒グラフの部分が実際の送信データを表している。あるサイズのデータをネットワークに流すためには一定以上の時間が必要となる。また、サイズによって必要となる時間が変わってくる。そのため、処理にかかる時間内での通信品質の変化を考慮しなければならない。
【００３０】
例えば、時刻Ｔ１における分割サイズを考える。Ｔ１における上限サイズはＳ１であるが、送信が終了するＴ２には通信品質が悪くなり上限サイズがＳ２まで下がってしまっている。そのため、上限ギリギリのＳ１を送ろうとすると許容量以上のデータとなり通信エラーが発生し、その結果、送信時間が延びてしまう。そこで、開始時刻から終了時刻までの間で最も通信品質が悪い時に合わせてデータを送るようにする。Ｔ１からＴ２までの間では、Ｔ２の時のＳ２が最も低いので、Ｔ１の時点で予めＳ２のサイズでデータを分割して送信するようにする。Ｔ３からＴ４の間はトンネルに入っていて通信ができない状況であるため、Ｔ４−Ｔ３の時間分だけ送信間隔を空けることで調整する。
【００３１】
図４は、上記の関連情報取得処理（ステップ３０１）の詳細を示す。
まず、車両１０１の走行状態を取得する（ステップ４０１）。走行状態として、少なくとも経路、位置、平均車速、移動方向、電波状態を取得する。車速は、車内ネットワーク１０７を介してＥＣＵ１０５から取得することができる。これを一定時間バッファリングすることで平均車速を取得することができる。なお直接ＥＣＵ１０５から取得するのではなく、定期的にハードディスク１０４に蓄積し、その蓄積した車両情報を活用しても良い。位置、移動方向は、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）で得ることができ、これを定期的にハードディスク１０４に蓄積して活用する。電波状態は、車載端末１０３に直結された通信機器１０２の電波状態を定期的に取得し、ハードディスク１０４に蓄積して活用する。また、経路に関しても同様に、ドライバが車載端末１０３を介して設定した情報がハードディスク１０４に格納される。
【００３２】
次に、環境情報をセンタサーバ１１１から取得するか、車両１０１内のハードディスク１０４から取得するかを選択する（ステップ４０２）。センタサーバ１１１から取得するかハードディスク１０４から取得するかの選択方法は、あらかじめ車両毎に設定値として設定しておく。この設定を、あらかじめ、車両の所有者がテレマティクスサービスを契約して決めておく。なお、この設定は車種毎に決めても良いし、地域で決めても良いし、所有者の年齢などで決めても良い。また、通信頻度に応じて動的に変わるようにしても良い。例えば、平均通信間隔が１時間未満の場合にはセンタサーバ１１１から取得するようにし、平均通信時間が１時間以上の場合にはハードディスク１０４から取得するようにする。また、常にハードディスク１０４から取得するようにし、センタサーバ１１１と通信した時に、ハードディスク１０４の情報を更新するようにしても良い。また、ハードディスク１０４の情報の鮮度に応じて動的に変わるようにしても良い。例えば、ハードディスク１０４の情報を更新してから１日以上たったら、センタサーバ１１１から最新情報を取得し、ハードディスク１０４の情報を更新するようにしても良い。
【００３３】
センタサーバ１１１から取得する場合（Ｙｅｓ）にはステップ４０３に移り、ハードディスク１０４から取得する場合（Ｎｏ）にはステップ４０５に移る。ステップ４０４では、通信機器１０２を介してセンタサーバ１１１とネットワークを接続して（ステップ４０３）、センタサーバ１１１に要求を出してリアルタイムの環境情報を取得する（ステップ４０４）。一方、ステップ４０５では、ハードディスク１０４にアクセスして事前に蓄積した環境情報を取得する。
【００３４】
図５は、最適通信のスケジューリング処理（ステップ３０４）の詳細を示す。
センタサーバ１１１へ送信するデータは１つだけではなく複数ある場合がある。例えば、交通情報サービスのための車両情報、燃費診断のための車両情報など、センタでの各サービスのために、複数の車両情報を送信することがある。この単一または複数データをさらに分割して送信するよう最適通信をスケジューリングする。また、複数データ間での優先制御も含めて最適通信をスケジューリングする。
【００３５】
まず、送信するデータが複数か否かを確認する（ステップ５０１）。確認の結果、送信データが複数の場合にはステップ５０２へ移り、それが単一の場合にはステップ５０３へ移る。
ステップ５０２では、複数のデータを送信する際の送信方法を選択する。複数データの送信方法としては、ここでは順次送信、並列送信、優先度送信の３つがある。例えば、データＡ、データＢ、データＣを送信する場合で、それぞれが、データＡ１、データＡ２、データＢ１、データＢ２、データＣ１、データＣ２に分割されて送信される場合を考える。
順次送信は、データＡを送信完了してからデータＢを送信し、データＢを送信完了してからデータＣを送信するというように、データを一つずつ送信する。この例ではデータＡ１→データＡ２→データＢ１→データＢ２→データＣ１→データＣ２の順に送信される。
並列送信は、データＡ、データＢ、データＣを並列に送信する。データＡ１→データＢ１→データＣ１→データＡ２→データＢ２→データＣ２の順に送信される。また、優先度送信は、優先度の高いデータを優先的に送信する。例えば、データＡの優先度が高、データＢとデータＣの優先度が低とすると、データＡ１→データＡ２→データＢ１→データＣ１→データＢ２→データＣ２の順に送信される。
【００３６】
この例では、優先度は高と低の２種類しかないが、３種類以上に設定しても良い。また、この例では、優先度が低のデータＢ・データＣを１つ送る間に、優先度が高のデータＡを２つ（２倍）送信しているが、この倍率は事前に定義しておいても良いし、優先度によって倍率を変え、優先度が高くなるほど倍率が高くなるようにしても良い。例えば、優先度が高・中・低の３種類の場合に、優先度が低のデータを１つ送る間に、優先度が中のデータを２つ（２倍）送り、優先度が高のデータを３つ（３倍）送るようにしても良い。
【００３７】
次に、送信方法に基づいて通信をスケジューリングする（ステップ５０３）。ステップ３０３で得られた、通信品質の変化の推定結果に基づいて、データを分割するサイズと、データを送信する間隔を決定する。分割サイズは、通信エラーが発生しないように最適なサイズを選択する。送信間隔は、トンネル内など通信が行えない場合の待ち時間として設定する。分割サイズ、送信間隔、複数または単一のデータの送信方法に基づいて通信をスケジューリングする。
【００３８】
次に、ステップ５０３でスケジューリングした結果に基づいて、送信するデータから分割サイズ分のデータを切り出す（ステップ５０４）。例えば、１０ＫＢｙｔｅのデータＡがあり、６ＫＢｙｔｅに分割して送信する場合には、まず先頭６ＫＢｙｔｅのデータＡ１を切り出して送信し、次に残りの４ＫＢｙｔｅのデータＡ２を送信する。１０ＫＢｙｔｅのデータＡと２ＫＢｙｔｅのデータＢがある場合には、「先頭６ＫＢｙｔｅデータＡ１」→「残り４ＢｙｔｅデータＡ２」→「２ＫＢｙｔｅデータＢ」というようにデータの切れ目で分割するのが好ましい。なお、分割サイズや送信間隔は通信品質に依存するものであり、送信するデータ自体には依存しない。
【００３９】
次に、ステップ５０４で切り出したデータをセンタサーバ１１１に対して送信する（ステップ５０５）。なお、送信するデータには、受信側のセンタサーバ１１１でデータを復元するための情報を付加する。そして、全てのデータが送信完了したか否かを判断する（ステップ５０６）。その結果、送信完了した場合には処理を終了し、送信完了していない場合にはステップ５０７に進み、ステップ５０３でスケジューリングした送信間隔の時間だけ処理を休止して、ステップ５０４に戻る。このステップ５０４〜ステップ５０７を、全てのデータを送信し終わるまで繰り返す。
【００４０】
図６は、車載端末１０３からセンタサーバ１１１へデータをアップロードする処理フローを示す。
車載端末１０３とセンタサーバ１１１は常時接続しているわけではなく、ドライバのアクションなどによって必要な時に接続される。
まず、車載端末１０３からセンタサーバ１１１に対してネットワークを接続し、データ分割送信の開始要求を送る（ステップ６０１）。センタサーバア１１１は、サーバ処理負荷などを確認し、受信準備が完了したら応答する（ステップ６１１）。そして、車載端末１０３からセンタサーバ１１１に対してデータを分割送信し（ステップ６０２、６０３）、センタサーバ１１１はその分割されたデータを受信する（ステップ６１２、６１３）。
【００４１】
そして全てのデータを送信し終えたら、送信終了の応答を返す（ステップ６１４）。センタサーバ１１１は応答を返すと、車載端末１０３との接続を切断する。そして、受信した分割データ群を統合してデータを復元して（ステップ６１５）、その復元したデータをデータベース１１２に蓄積する（ステップ６１６）。なお、復元データの蓄積場所はデータベース１１２ではなく、メモリ上でも良いし、内蔵ハードディスクでも良いし、外部接続したフラッシュメモリやハードディスクなどでも良い。
【００４２】
図９は、複数データを送信する場合のデータ種別によるデータの優先度のテーブル構成を示す。
このテーブルは、データ種別９０１毎に対して優先度９０２が定義され、車載端末１０３のハードディスク１０４に登録されている。データ種別９０１は、個々の送信するデータの中身ではなく、いかなる種類のデータであるのかを表す。そのため、同じＥＣＵのデータであったとしても、種別が異なれば優先度が異なる。例えば、車両情報（プローブ）として車速を送信する場合には優先度は２'であるが、車両情報（Ｓ＆Ｓ）として車速を送信する場合には優先度は１'となる。
【００４３】
センタサーバ１１１では、プローブの場合には渋滞情報の生成のために活用することができ、Ｓ＆Ｓの場合には盗難車追跡に活用できる。優先度は事前に定義しておくものであり、この定義情報は車載端末１０３に持たせておく。なお、この定義情報をセンタサーバ１１１から更新するようにしても良いし、車載端末１０３がセンタサーバ１１１と接続した時に更新されているかどうかを確認するようにしても良い。また、車両毎によって定義を変えても良いし、車種や地域など特定のグループで定義を統一しても良い。この優先度を用いて送信することで、より重要なデータを優先的に送信することが可能となる。
【００４４】
図１０は、時間によるデータの優先度の変化に関するテーブル構成を示す。
このテーブルは、データ種別１００１毎に時間による変化のルール１００２が定義され、同じくハードディスク１０４に登録されている。ルール１００２は、データが作成されてからの経過時間による優先度の変化を規定する。優先度の下がり方、つまり、データが重要であるか否かはデータ種別によって異なるため、データ種別１００１毎にルール１００２を定義する必要がある。
例えば、車両情報（Ｓ＆Ｓ）としての車速を活用する盗難車追跡の場合、どんなに時間が経過したとしても盗難車を追跡する上では重要な情報となるため、経過時間による優先度の低下はない。一方、車両情報（プローブ）としての車速を活用する渋滞予測の場合、リアルタイムの渋滞予測を行う上では現在の車速が重要なのであり、時間が経過するほど重要度が下がり、統計的な活用しかできなくなってしまう。そのため、３０分毎に優先度が１'下がるというルールになる。このルールは事前に車載端末１０３に定義しておく方法でも良いし、センタサーバ１１１から定義情報を配信する方法でも良い。また、車両毎によって定義を変えても良いし、車種や地域など特定のグループで定義を統一しても良い。
【００４５】
[実施例２]
次に、図１２及び図１３を参照して実施例２について説明する。
この例は、図２に示した例に対比して、車載端末１０３における主な処理機能をセンタサーバ１１１で行うものである。すなわち、図３の各処理をセンタサーバ１１１で実行して、その処理結果である最適通信のスケジューリングをセンタサーバ１１１から車載端末１０３へダウンロードする。
【００４６】
以下、具体的に説明する。
なお、渋滞情報管理サーバ１１３及び通信品質管理サーバ１１４の機能は、図２による例と同様であるので、その説明は省略する。
車載端末１０３は、走行状態提供１２０１、データ通信１２０２、受信制御１２０３、受信データ統合１２０４を有する。走行状態提供１２０１は、車内ネットワーク１０７を介してＥＣＵ１０５から車速などの車両情報を取得する機能を備えている。走行状態提供２０１は、ハードディスク１０４からドライバによって設定された経路情報などを取得する機能も備えている。経路情報などは、ハードディスク１０４からではなく、車載端末１０３がメモリに持っている情報を取得しても良い。このように取得された情報は、データ通信１２０２を介してセンタサーバ１１１へアップロードされる。受信制御１２０３は、センタサーバ１１１から分割して送られてきたデータを受信する。受信制御１２０３は、どのデータを受信したのかを管理しており、通信エラーなどにより受信が完了しなかった場合には、再接続時に途中から再開することができるレジューム機能を備えている。もちろん、レジュームしないで、最初から送りなおすことも可能である。受信データ統合１２０４は、受信制御１２０３で受信した分割データ群を統合して元のデータに戻し、ハードディスク１０４に蓄積する。
【００４７】
センタサーバ１１１は、データ通信１２０５、走行状態取得１２０６、環境情報取得１２０７、送信制御１２０８、通信品質変化推定１２０９、移動予測１２１０を有する。データ通信１２０５は、車載端末１０３のデータ通信１２０２と通信するための機能である。走行状態取得１２０６は、車載端末１０３から送られてきた走行状態に関する情報を取得する機能である。環境情報取得１２０７は、通信品質情報や、通信品質に影響を与える渋滞情報などを取得する。渋滞情報管理サーバ１１３に問い合わせて渋滞情報を取得し、通信品質管理サーバ１１４に問い合わせて通信品質情報を取得する。
【００４８】
移動予測１２１０では、走行状態取得１２０６で取得した経路や車速などの情報と、環境情報取得１２０７で取得した渋滞情報から、経路上を移動するにかかる時間を予測する。通信品質変化推定１２０９は、環境情報取得１２０７で取得した通信品質の情報と、移動予測１２１０で予測した結果を基にして、時間による通信品質の変化を推定する。送信制御１２０８は、通信品質変化推定１２０９で得られた結果に基づいて、どのくらいのデータ量をどの程度の間隔でネットワークに送信するのかスケジューリングし、データ通信１２０５を介してスケジュールに基づいて送信する。
【００４９】
図１３は、センタサーバ１１１から車載端末１０３へのデータダウンロードする処理フローを示す。
車載端末１０３とセンタサーバ１１１は常時接続しているわけではなく、ドライバのアクションなどによって必要な時に接続される。
まず、車載端末１０３からセンタサーバ１１１に対してネットワークの接続要求を送り（ステップ１３０１）、センタサーバ１１１は接続応答を返す（ステップ１３１１）。すると、車載端末１０３は、走行状態に関する情報をアップロードすると（ステップ１３０２）、センタサーバ１１１はデータ分割送信の開始要求を送る（ステップ１３１２）。そして、車載端末１０３は処理負荷などを確認し、受信準備が完了したら応答する（ステップ１３０３）。センタサーバ１１１は車載端末１０３に対してデータを分割して送信し（ステップ１３１３、１３１４）、車載端末１０３はその分割されたデータを受信する（ステップ１３０４、１３０５）。全てのデータを送信し終えたら、送信終了の応答を返す（ステップ１３１５）。
【００５０】
車載端末１０３は、センタサーバ１１１は応答を返すと、センタサーバ１１１との接続を切断して終了する（ステップ１３０６）。その後、車載端末１０３は、受信した分割データ群を統合してデータを復元して（ステップ１３０７）、その復元したデータを例えばハードディスク１０４に蓄積する（ステップ１３０８）。
【００５１】
センタサーバ１１１と車載端末１０３間の分割送信に関しては、車両単体の通信品質だけではなく、複数車両の車両群全体として、優先度の高いデータに帯域を割り当てても良い。例えば、車両Ａからの盗難車追跡用の車両情報収集と、車両Ｂへのニュース配信が同時に発生した場合、優先度の高い車両Ａからの盗難車追跡用の車両情報収集にネットワーク帯域を割り当て、その後で車両Ｂへニュースを配信する。
【図面の簡単な説明】
【００５２】
【図１】一実施例（第１の実施例）による移動体通信システムの全体構成を示す図。
【図２】第１の実施例における移動体通信システムの機能構成を示す図。
【図３】第１の実施例における車載端末における最適通信処理を示すフロー図。
【図４】第１の実施例における関連情報取得処理３０１の詳細に示すフロー図。
【図５】第１の実施例における通信スケジューリング処理３０４の詳細を示すフロー図。
【図６】第１の実施例におけるデータのアップロード処理を示すフロー図。
【図７】第１の実施例における位置による通信品質の違いを示す図。
【図８】第１の実施例におけるデータ分割サイズや送信間隔の求め方を示す図。
【図９】第１の実施例におけるデータ種別による優先度に関するテーブル構成を示す図。
【図１０】第１の実施例における時間によるデータの優先度の変化に関するテーブル構成を示す図。
【図１１】第１の実施例におけるハードディスク１０４に蓄積されるデータの形式を示す図。
【図１２】第２の実施例における移動体通信システムの機能構成を示す図。
【図１３】第２の実施例におけるデータのダウンロード処理を示すフロー図。
【符号の説明】
【００５３】
１０１：車両、  １０３：車載端末、  １１１：センタサーバ、  １１２：データベース、  １１３：渋滞情報管理サーバ、  １１４：通信品質管理サーバ、  ２０１：走行状態取得、  ２０２：環境情報取得、  ２０３：移動予測２０３  ２０４：通信品質変化推定、  ２０５：送信制御、  ２０６：データ通信、  ２０７：データ通信、  ２０８：環境情報取得、  ２０９：受信制御、  ２１０：受信データ統合、  ２１１：渋滞情報管理、  ２１２：渋滞情報、  ２１３：通信品質管理、  ２１４：通信品質
【図１】
2008199381.tif 000003
【図２】
2008199381.tif 000004
【図３】
2008199381.tif 000005
【図４】
2008199381.tif 000006
【図５】
2008199381.tif 000007
【図６】
2008199381.tif 000008
【図７】
2008199381.tif 000009
【図８】
2008199381.tif 000010
【図９】
2008199381.tif 000011
【図１０】
2008199381.tif 000012
【図１１】
2008199381.tif 000013
【図１２】
2008199381.tif 000014
【図１３】
2008199381.tif 000015