(57)【要約】【課題】車両が通信を行なう際はＴＣＰプロトコル方式を用いるが、この方式が各アクセスポイントと相性が悪いため、安定した通信を行なうことが難しい状況にある。【解決手段】本発明の移動体通信方法は、移動体と複数の通信ゲートウェイとの間で通信を行なうとともに、前記通信ゲートウェイと、前記移動体の通信対象と接続されたセンタとの間で通信を行なう移動体通信方法であって、前記移動体と前記通信ゲートウェイとの間ではＵＤＰパケットデータを送受信し、前記通信ゲートウェイと前記センタとの間ではＴＣＰパケットデータを送受信することを特徴とする。【選択図】図７
2009100047.tif 000002
【特許請求の範囲】
【請求項１】
移動体と複数の通信ゲートウェイとの間で通信を行なうとともに、
前記通信ゲートウェイと、前記移動体の通信対象と接続されたセンタとの間で通信を行なう移動体通信方法であって、
前記移動体と前記通信ゲートウェイとの間ではＵＤＰパケットデータを送受信し、
前記通信ゲートウェイと前記センタとの間ではＴＣＰパケットデータを送受信することを特徴とする移動体通信方法。
【請求項２】
前記ＵＤＰパケットデータは、送信先インターネット・プロトコル（ＩＰ）として複数の前記通信ゲートウェイに共通のＩＰを有し、
前記ＴＣＰパケットデータは、送信元ＩＰとして複数の前記通信ゲートウェイに固有のＩＰを有することを特徴とする請求項１に記載の移動体通信方法。
【請求項３】
前記移動体が、前記センタに、前記通信ゲートウェイを介して、前記移動体に固有の移動体固有ＩＤと前記通信対象宛の要求データとを送信するステップと、
前記移動体固有ＩＤを含んだ定期位置送信データを定期的に送信するステップと、
前記センタが、前記定期位置送信データを前記定期位置送信データの送信時に介された当該通信ゲートウェイのＩＰとともに保有するステップとを有し、
前記センタは、所定時間内に同一の移動体固有ＩＤ及び同一の通信ゲートウェイＩＰを含んだ定期位置送信データを受信しなかった場合は、当該定期位置送信データを削除することを特徴とする請求項１または２に記載の移動体通信方法。
【請求項４】
前記センタは、前記移動体の通信対象から前記要求データに対する応答データを受信するステップと、
前記センタが保有している定期位置送信データ内の前記通信ゲートウェイＩＰを送信先ＩＰとして、前記移動体固有ＩＤと、前記応答データとを送信するステップと、
前記応答データを受信した前記通信ゲートウェイは、前記移動体固有ＩＤに対応する移動体ＩＰを送信先として、前記応答データを送信するステップとを有し、
前記移動体は、前記要求データに対する、最初の応答データを受信して保有し、
前記要求データに対する２番目以降の応答データを廃棄することを特徴とする請求項３に記載の移動体通信方法。
【請求項５】
移動体に搭載され、少なくとも通信機能を有する移動体通信装置であって、
ＵＤＰパケットデータを生成するデータ生成手段と、
前記移動体と、前記移動体の通信対象に接続可能なセンタとの間でデータを送受信する複数の通信ゲートウェイに対して、前記ＵＤＰパケットデータを送受信するデータ送受信手段を有することを特徴とする移動体通信装置。
【請求項６】
前記移動体通信装置は、前記通信対象宛の要求データを生成するデータ生成手段と、
前記要求データを送信するデータ送信手段と、
前記移動体に固有の移動体固有ＩＤを含んだ定期位置送信データを生成するデータ生成手段と、
前記センタに対して、前記通信ゲートウェイを介して、前記定期位置送信データを定期的に送信するデータ送信手段を有することを特徴とする請求項５に記載の移動体通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動体と、インターネットに接続されたセンタを介して、通信対象との間でデータを送受信する移動体通信装置及びデータ送受信システムに関し、特に移動体とセンタとの間に転送端末を介する移動体通信装置及び移動体通信方法に関する。
【背景技術】
【０００２】
近年、移動体におけるインターネットや楽曲ダウンロード等といった通信に関して、継続した通信を可能にするローミング技術、携帯電話や無線ＬＡＮ端末といった複数の端末を用いる技術、移動情報や走行情報を用いて次の通信網を割り出すことで、安定した切り替えを行なう技術といったように、安定した通信を行なう技術が種々開発されている。
【０００３】
従来技術の場合、高速移動だが移動先は一定である電車や、予測不可能な移動を行なうが速度が遅い人間には対応可能である。しかし、車両においては、高速で移動しており、なおかつ必ずナビゲーション装置を用いて移動先を指定しているとは限らないために、移動先の予測ができないことがある。このため、車両においては十分な通信が行なえる保証はない。これは、現在用いられている通信端末の有効範囲の狭さによるものである。
さらに、車両が通信を行なう際はＴＣＰ（Transmission Control Protocol)プロトコル方式を用いる（例えば特許文献１）が、この方式が各アクセスポイント（以下、「ＡＰ」という）と相性が悪いため、安定した通信を行なうことが難しい状況にある。
ＴＣＰは、セッションという形で１対１の通信を実現し、パケットシーケンスチェックによる欠損パケット再送などのエラー訂正機能などを持ち、データ転送などの信頼性の必要な場面でよく使用される。ここで、図１を用いて、ＴＣＰプロトコル方式について簡単に説明すると、まず接続する側(例えば車両)から接続要求を意味するSYNパケット１０１を送る。次に、接続される側(例えば通信対象)は接続許可を意味するACKパケットと接続要求のSYNパケットを組み合わせたSYN-ACKパケット１０２を送る。最後に、車両側からもACKパケット１０３を送り、コネクションが確立される。その後、データ１０４が送受信される。
【０００４】
【特許文献１】特開２００２−３２２７６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、各ＡＰは個別のインターネット・プロトコル・アドレス（以下、「ＩＰアドレス」という）を所有している。ＩＰとは、ネットワークに参加している機器の住所付けや、相互接続された複数のネットワーク内での通信経路の選定をするための方法を定義するものであり、ＩＰアドレスは、パケットを送受信する機器を判別するための番号である。
従来技術の場合は複数のＡＰの通信圏内を走行していたとしても、各ＡＰが異なったＩＰアドレスを所有しているため、複数のＡＰへ一度に送信できないといった難点や、ＡＰのＩＰを知らないと通信できないといった難点があった。
上記の問題を、図２を用いて説明する。車両１００がＡＰを介して、センタ１３０を経由してサーバ１２０にデータを送信する場合について検討する。車両１００が移動している場合に、図に示すように、車両１００が、３つのＡＰ、即ち第１ＡＰ１１１、第２ＡＰ１１２、第３ＡＰ１１３の通信圏内にあったとする。ここで、第１ＡＰ１１１のＩＰがＡであり、第２ＡＰ１１２のＩＰがＢであり、第３ＡＰ１１３のＩＰがＣであったとすると、３つのＡＰは、それぞれ異なるＩＰを有しているため、一度に全てのＡＰにデータを送信することができない。また、各ＡＰのＩＰをデータ送信前に知らないとデータを送信することができないという問題が生じる。この問題は、車両が移動している場合には、移動している最中に特定のＡＰの通信圏内から外れる可能性があり、データ送信を行なうために特定のＡＰのＩＰを事前に知った場合でも、データ送信を行うことができない恐れもある。さらには、時々刻々変化する通信圏に入るＡＰを事前に調べる煩わしさが生じる。
【０００６】
さらに、応答データが、要求データを送信した通信ゲートウェイ（以下、「通信ＧＷ」という）に帰ってくるよりも先に車両が圏外に出てしまい、次の通信ＧＷの圏内に移動していた場合、応答データを取得できないという問題が生じる。
この問題について図３を用いて説明する。車両１００が、転送端末である第１通信ＧＷ１２１の圏内にあるときにデータを要求し、要求データが、図の実線に示すように、車メーカセンタ１４０を介して各コンテンツサーバ１５０に送られ、応答データが、図の点線に示すように、各コンテンツサーバ１５０から、車メーカセンタ１４０を介して、第１通信ＧＷ１２１に戻された場合について検討する。このとき、車両１００は移動により、応答データが第１通信ＧＷ１２１に送られてきたときには、第１通信ＧＷ１２１の圏内から外れている場合が考えられる。このようなときには、車両１００が第２通信ＧＷ１２２の圏内に入っているとしても、応答データを受け取った第１通信ＧＷ１２１から車両１００へは応答データが届かなくなるという問題が生じる。
本発明は、これらの問題を解決した車両に特化した転送システムの実現を目的とする。
【課題を解決するための手段】
【０００７】
本発明の移動体通信方法は、移動体と複数の通信ゲートウェイとの間で通信を行なうとともに、前記通信ゲートウェイと、前記移動体の通信対象と接続されたセンタとの間で通信を行なう移動体通信方法であって、前記移動体と前記通信ゲートウェイとの間ではＵＤＰパケットデータを送受信し、前記通信ゲートウェイと前記センタとの間ではＴＣＰパケットデータを送受信することを特徴とする。
【０００８】
また、本発明の移動体通信装置は、移動体に搭載され、少なくとも通信機能を有する移動体通信装置であって、ＵＤＰパケットデータを生成するデータ生成手段と、前記移動体と、前記移動体の通信対象に接続可能なセンタとの間でデータを送受信する複数の通信ゲートウェイに対して、前記ＵＤＰパケットデータを送受信するデータ送受信手段を有することを特徴とする。
【発明の効果】
【０００９】
本発明の構成により、通信ＧＷの無線側は固定の共通ＩＰを使用するため、一度の送信で圏内の通信ＧＷ全てへ送信することが可能となるとともに、通信ＧＷのＩＰを知る（調べる）必要がなく、通信に要する時間を短縮できる。また、これにより、圏内でのデータ送信失敗という可能性が減り、移動体通信の成功確率を上げることが可能となる。
【００１０】
さらに、本発明では要求データを送信した車両は応答データを取得するまで、定期的に特定のデータを送信することでセンタ側の応答先を追加更新する。センタ側は受信したデータより常に最新の送信元ＩＰを保有する。これは、通信ＧＷとセンタを用いた２段転送システムにつき可能となる。
【００１１】
また、応答データを車両に送る際は、最新の（最後に登録された）送信元に返すだけではなく、その周囲にある通信ＧＷにも送ることでより確実な応答通信を行うことができる。
【発明を実施するための最良の形態】
【００１２】
以下図面を参照して、本発明に係る移動体通信装置及び移動体通信方法について説明する。ただし、本発明の技術的範囲はそれらの実施の形態には限定されず、特許請求の範囲に記載された発明とその均等物に及ぶ点に留意されたい。
【００１３】
本発明の移動体通信方法においては、図４に示すように、まず、車両１が通信ＧＷおよびセンタ３を介してサーバ４にある通信対象にデータを送信する。この際に、図４に示すように、例えば３基の通信ＧＷである第１通信ＧＷ２１、第２通信ＧＷ２２、第３通信ＧＷ２３に一斉に要求データを送信する点を特徴とする。ここで、３基の通信ＧＷは全て同じＩＰ、例えばＱを有し、車両はＵＤＰ（User Datagram Protocol）パケットによりデータ送信を行なう。ここで、ＵＤＰ方式は、インターネットで利用される標準プロトコルであり、ＴＣＰと異なり送達確認などを行わないため、信頼性は低いが転送効率が高いという特徴を有する。
通信ＧＷはセンタにデータを送信し、センタは、車両が本来送信したい送信先である通信対象へデータを送信する。このようにデータを車両１から通信対象に送信する一連の処理を「要求送信処理」と呼ぶ。
【００１４】
次に、車両１は通信対象がデータを受け取ったことを確認する必要があるが、その応答は通信ＧＷから受信することとなる。ここで、車両１は移動しているために、この応答受信段階では、要求送信処理段階とは異なった通信圏内に移動している可能性があり、車両１がどの通信ＧＷの通信圏内にあるかを知らせる必要がある。そのために、車両１は定期的に情報を発信することにより、通信ＧＷに位置を知らせる。この処理を「定期位置送信処理」と呼ぶ。
【００１５】
また、通信対象がデータを受信したことを通知するため、あるいは通信対象がデータを送信した車両１に対して返信するための応答データは、まずサーバ４を介してセンタ３に伝えられ、次にセンタ３から通信ＧＷに伝えられ、通信ＧＷから車両１に伝えられる。この一連の処理を「応答受信処理」と呼ぶ。
次に、上記の、要求送信処理、定期位置送信処理、応答受信処理について詳細に説明する。
【実施例１】
【００１６】
まず、データの送受信を行なう移動体の一例としての車両の構成及び、本発明に係る移動体通信方法について、図５を用いて説明する。
本発明に係る移動体通信方法においては、車両１とインターネット網を中継し繋げる機能を持った車両独自のアクセスポイントとして機能する車両通信ゲートウェイ・アクセスポイント（以下、「通信ＧＷ」と呼ぶ）２と、インターネット網に設置されたセンタ施設３およびサーバ４によって構成され、車両に特化した通信を可能としている。
本発明の車両構成を図６に示す。車両１は、無線通信を行なうことが可能な通信装置１１とナビゲーション装置１２とを有する。通信装置１１は、ナビゲーション装置１２と接続された制御部１３と、データ（例えば車両固有ＩＤ１８）を記憶する記憶部１４と、無線通信を行なうためのアンテナ１０と接続された無線通信端末１７とを有する。さらに通信装置１１は、データ入力を行うための入力部１５を備える。制御部１３は、後述する要求パケットデータを生成するための要求パケットデータ生成手段１９と、位置通知用パケットデータを生成するための位置通知用パケットデータ生成手段２０とを備える。ナビゲーション装置１２は、表示データ等を出力するための出力装置（例えばディスプレイ）１６を備え、出力装置１６は通信装置１１の制御部１３からの出力データに基づいて画像データや音声データ等の表示等を行う。出力装置１６は、図６に示すようにナビゲーション装置１２と一体化していてもよいし、ナビゲーション装置と分離していてもよい。さらに、本実施例では、通信装置１１とナビゲーション装置１２とが分離した構成を例示しているが、通信装置１１とナビゲーション装置１２とが一体化していてもよい。さらに、ナビゲーション装置の代わりに通信が可能なカーステレオ等を用いることもできる。
【００１７】
ここで、車両がインターネット網の特定の対象（通信対象）と通信を行なう場合、車両が通信ＧＷへとデータを送信し、通信ＧＷがセンタへ転送し、センタが対象からデータを取得して通信ＧＷに応答を返し、通信ＧＷは応答を車両に返すことで通信を行ない、車両と通信ＧＷとの間の通信はＵＤＰパケットデータを用いて行ない、通信ＧＷとセンタとの間の通信は、ＴＣＰパケットデータを用いて行なうことを特徴としている。
さらに、通信ＧＷは、車両と繋がる側とインターネット側において異なる各通信ＧＷに固有のＩＰを有し、車両側のＩＰは全ての通信ＧＷに共通のＩＰを有することを特徴としている。
【００１８】
＜要求送信処理＞
次に、要求送信処理について、図を用いて説明する。図７及び８は、データを車両→通信ＧＷ→センタ→通信対象へと転送する一連のデータ処理の概略を図示したものである。
【００１９】
（車両の通信処理フロー）
まず、車両の通信処理フローについて、図９のフローチャートを用いて説明する。通信処理フローは図９のＳ１０１で開始され、Ｓ１０２で車両の通信装置１１（図６参照）を起動する。次に、Ｓ１０３において、車両の通信装置１１は、入力部１５からの入力データに基づき、制御部１３内の要求パケットデータ生成手段１９（図６参照）によって要求パケットデータを生成する。図７に示すように、要求パケットデータ３１は、ＵＤＰを利用しており、送信先ＩＰ、送信元ＩＰ、ＵＤＰヘッダ、データ部からなる。ここで、送信先ＩＰは複数の通信ＧＷに共通である。さらに上記のデータ部には、車両固有ＩＤ、本来送信したい送信先ＩＰ（通信対象のＩＰ）、要求データが含まれる。ここで、図６に示すように、車両固有ＩＤ１８は、通信装置１１内の記憶部１４に保持され、制御部１３へ送られる。
次に、Ｓ１０４において車両が通信ＧＷの圏内に存在するかどうかが判断され、通信圏内である場合には、Ｓ１０５において、データ送信手段である無線通信端末１７により要求ＵＤＰパケットデータが送信される。ここで、図８に示すように、車両の通信圏内にある複数の通信ＧＷは全て同一の共通ＩＰを有しており、車両の通信装置１１から要求ＵＤＰパケットデータが、複数の通信ＧＷに一斉送信される。
車両は、通信対象がデータを受信したことを確認するための応答データを受信するため、Ｓ１０６において応答待ちの状態となる。
【００２０】
（通信ＧＷ処理フロー）
次に、上記のようにして車両からデータを受け取った通信ＧＷの処理フローについて説明する。通信ＧＷでは、車両からデータを受信する処理と、受信したデータをセンタに送信する処理が行なわれる。通信ＧＷの処理フローのフローチャートを図１１に示す。まず、Ｓ２０１において通信ＧＷが起動され、Ｓ２０２において後述する保有データの削除処理を行なう。次に、Ｓ２０３において車両からデータを受信したか否かを判断し、車両からデータを受信した場合にはＳ２０４において車両データ受信処理が行なわれる。
通信ＧＷの車両データ受信処理フローについて、図１２を用いて説明する。まず、Ｓ３０１において、車両データ受信が行なわれると、Ｓ３０２においてデータ内容の確認が行なわれる。これは、受信したデータが、通信対象へ要求データを送るためのデータであるか、後述する定期位置確認のためのデータ（定期送信）であるかを判断するために行なうものである。次に、Ｓ３０３において、受信したデータが定期送信のためのデータか否かを判断し、ここでは定期送信ではないので、Ｓ３１４に進む。Ｓ３１４において、後述する完了通知か否かが判断され、ここでは、完了通知ではないのでＳ３０８に進む。Ｓ３０８において、データ内から”車両固有ＩＤ”と"送信元ＩＰ”を取得する。ここで、送信元ＩＰは図７に示すように、車両ＩＰである。
【００２１】
次に、Ｓ３０９において、保有データの中に同じ固有ＩＤがあるか否かを判断する。ここでは、特定の固有ＩＤを有する同一の車両が発信したデータを複数回受信することを想定し、最初に受信したものか、２回目以降に受信したものかを判断するものである。最初に受信した場合は、保有データの中に同じ固有ＩＤはないため、Ｓ３１１に進む。Ｓ３１１では、”固有ＩＤ”と”送信元ＩＰ”を”タイマ”とともに保有する。タイマは、図７に示すように、時刻を記録するものであってもよいし、例えば設定時間を６０秒としたカウントダウン式のものでもよい。同一の車両が２回目以降に発信したデータを受信した場合には、Ｓ３０９において、保有データの中に同じ固有ＩＤがあることになり、Ｓ３１０に進む。Ｓ３１０では、車両固有ＩＤに対応して保有している”タイマ”を更新する。即ち、タイマの設定時間が０になる前に再度データを受信した場合には、タイマの設定時間を初期値に戻す。これによって、車両が通信ＧＷの通信圏内に存在しているか否かが確認できる。この処理は、車両からデータを受け取った全ての通信ＧＷにおいて行なわれる。そのため、車両がどの通信ＧＷの通信圏内に存在しているかも確認できる。
【００２２】
次に、Ｓ３１２において、センタに受信した”データ”（固有ＩＤ、通信対象ＩＰ、要求データ）を転送する。転送するデータは、図７に示すように、ＴＣＰパケットデータ３２が用いられる。これは、送信元、送信先が共に固定されているため、送信の安定化のためには望ましいからである。ＴＣＰパケットデータ３２は、送信先ＩＰ、送信元ＩＰ、ＴＣＰヘッダ、データ部からなる。ここで、送信先は、センタＩＰで固定されている。送信元ＩＰは、通信ＧＷであるが、個々の通信ＧＷではインターネット側ＩＰとして個別のＩＰを用いる。例えば、図８に示すように、各通信ＧＷはXXX.Y.ZZ.B、XXX.Y.Z.D、XXX.YY.VV.C・・・のように異なっている。これは、応答データを返すときに、送信先の通信ＧＷを特定するためである。データ部は、通信ＧＷが車両から受信したＵＤＰパケットデータと同じであり、図７に示すように、車両固有ＩＤ、本来送信したい送信先ＩＰ、要求データからなる。データをセンタに送信すると、Ｓ３１３に進み、受信車両データ転送完了となる。
【００２３】
（センタ処理フロー）
次に、通信ＧＷからデータを受信するセンタの処理フローについて説明する。センタは、通信ＧＷから要求データを受信する処理と、通信対象へ受信した要求データを通信対象へ送信する処理を行なう。
【００２４】
図１３Ａ及びＢにセンタ処理フローのフローチャートを示す。まず、Ｓ４０１において、センタを起動し、Ｓ４０２で初期設定を行なう。初期設定がすでに完了している場合で、データ受信待ちの場合はＳ４０３から開始される。Ｓ４０４において、通信ＧＷよりデータを受信したか否かが判断され、ここではデータを通信ＧＷから受信しているので、Ｓ４０５に進む。Ｓ４０５では、受信したデータが定期送信データか否かが判断され、ここでは定期送信ではないのでＳ４２２に進む。Ｓ４２２では、通信対象を特定するために、データ内から”通信対象”のＩＰ、即ち、本来送信したい送信先ＩＰを取得する。次に、Ｓ４２３において、完了通知か否かが判断され、ここでは完了通知ではないのでＳ４０９に進む。Ｓ４０９において、受信したデータ内から”車両固有ＩＤ”と”送信元ＩＰ”を取得する。
【００２５】
次に、Ｓ４１０において、保有データの中に同じ固有ＩＤが有るか否かが判断される。即ち、ここでは、同じ車両から要求データを複数回受信することを想定している。最初にデータを受信したときには、保有データの中に同じ固有ＩＤがないため、Ｓ４１９に進み、図７に示すように、”カウンタ”を１とし、”固有ＩＤ”と”送信元ＩＰ”、”タイマ”と共に保有する。カウンタは、後述するように、複数の異なる要求データを受信した際、その全てに対して応答したかどうかを判定するために用いるものである。
【００２６】
このステップにおける情報の保持について図８を用いて説明する。ある時刻に車両１（車両固有ＩＤ：vaj2ora5b）から第１通信ＧＷ２１（ＩＰ：XXX.Y.ZZ.B）にルート４１を経由して１番目のデータ（要求パケット）が送信されたとする。この１番目のデータは第１通信ＧＷ２１からセンタに転送され、センタでは表４０１に示すようにタイマの初期設定値を６０秒として車両固有ＩＤ、送信元ＩＰ（通信ＧＷ）、タイマ、カウントを保持する。
【００２７】
次に、１７秒後に、同一の車両１（車両固有ＩＤ：vaj2ora5b）から、第２通信ＧＷ２２（ＩＰ：XXX.Y.ZZ.D）にルート４２を経由して２番目のデータ（要求パケット）が送信されたとする。このデータは第２通信ＧＷ２２からセンタに転送される。センタでは２番目のデータについて車両固有ＩＤを一覧表から検索する。ここでは車両ＩＤがvaj2ora5bで一致している。さらに、１７秒後に受信しており、タイマの設定時間以内に受信している。その結果、同一の車両からの同一の要求と判断する。送信元ＩＰを比較すると、１番目のデータのＩＰは、XXX.Y.ZZ.Bであるのに対し、２番目のデータのＩＰはXXX.Y.ZZ.Dと異なっているので、表４０２に示すように、一覧表に送信元ＩＰとタイマの情報を追加する。
【００２８】
さらに２１秒経過後に、車両１は、第３通信ＧＷ２３（ＩＰ：XXX.YY.V.C）にルート４３を経由して３番目のデータ（要求パケット）が送信されたとする。このデータは第３通信ＧＷ２３からセンタに転送される。センタでは３番目のデータについて、車両固有ＩＤを一覧表から検索する。ここでは車両ＩＤがvaj2ora5bで一致している。さらに、２１秒後に受信しており、タイマの設定時間以内に受信している。その結果、同一の車両からの同一の要求と判断する。送信元ＩＰを比較すると、１番目のデータのＩＰは、XXX.Y.ZZ.B、２番目のデータのＩＰはXXX.Y.ZZ.Dであり、３番目のデータのＩＰはXXX.YY.V.Cと異なっているので、表４０３に示すように、一覧表に送信元ＩＰとタイマの情報を追加する。
【００２９】
次に、Ｓ４２０において、通信対象に受信した”データ”を転送する。データは、図７に示すようにＴＣＰパケットデータ３３であり、本来送信したい送信先（通信対象）ＩＰ、送信元ＩＰ（センタＩＰ）、ＴＣＰヘッダ、要求データからなる。その後、Ｓ４２１において、データ受信待ち状態となる。
【００３０】
Ｓ４１０において、保有データの中に同じ固有ＩＤがある場合には、Ｓ４１１において固有ＩＤに対応した”タイマ”の中で最新の値を取得する。このタイマの値から、Ｓ４１２において、ある一定時間が経過しているか否かを判断する。一定時間経過していない場合、同一の車両からの要求と判断できる。そこで、Ｓ４１５において、送信元ＩＰを保有しているか否かを判断する。送信元ＩＰを保有している場合は、同じ通信ＧＷからの受信と判断され、Ｓ４１６において送信元に対応した”タイマ”を更新する。送信元ＩＰを保有していない場合は、異なる通信ＧＷからの受信と判断され、Ｓ４１７において、”送信元ＩＰ”を”タイマ”と共に保有する。その後、Ｓ４１８において、データ受信待ち状態となる。
【００３１】
Ｓ４１２において、ある一定時間が経過している場合、Ｓ４１３において固有ＩＤと共に保有している”カウンタ”に＋１し、Ｓ４１４において、固有ＩＤの送信元ＩＰに対応した”タイマ”を更新する。次に、Ｓ４２０において、図８に示すように、通信対象に受信した”データ”（要求パケット）を転送する。その後、Ｓ４２１において、データ受信待ち状態となる。
【実施例２】
【００３２】
＜定期位置送信処理＞
定期位置送信処理は、従来、応答データが要求を送信した通信ＧＷに帰ってくるよりも先に車両が圏外に出てしまい、次の通信ＧＷの圏内に移動していた場合に、応答データを取得できないという問題が生じていたが、これを解決するものである。即ち、要求データを送信した車両は、応答データを取得するまで、定期的に特定のデータを送信することで、センタ側の応答先を追加更新する。センタ側は、受信したデータより常に最新の送信先ＩＰを保有する。このシステムは、通信ＧＷとセンタとを用いた２段転送システムにより可能となるものである。
次に、定期位置送信システムについて、図１４Ａ〜Ｃを用いて説明する。図１４Ａ〜Ｃは、車両→通信ＧＷ→センタへの位置通知用定期送信のデータの流れを示している。
【００３３】
（車両の通信処理フロー）
まず、車両の通信処理フローについて、フローチャートを用いて説明する。図１０は、車両における通信処理フローを示す。位置通知用定期送信は、図１４Ａに示すように、車両１内の通信装置１１が、通信ＧＷ２に対して位置通知用パケットデータ生成手段２０（図６参照）を用いて生成した位置通知用定期送信パケットを送信することにより行なわれる。車両１は、図１０に示すように、Ｓ７０１において、既に要求データを送信し、応答待ち状態にあるときに、Ｓ７０２において応答受信したか否かを判断し、応答受信していないときに、Ｓ７０５において、一定時間経過したか否かが判断される。一定時間経過していないときは、Ｓ７０８において、車両１内の通信装置１１が、位置通知用パケットデータ生成手段２０（図６参照）を用いて位置通知用定期送信パケットを生成する。次に、Ｓ７０９において、定期送信パケットを送信する。送信後、Ｓ７１０において、応答待ち状態となる。位置通知用データは、要求データと同様に、ＵＤＰパケットを用いて、全ての通信ＧＷに対して送信される。また、図１４Ａに示すように、定期送信パケット４１は、送信先ＩＰ、送信元ＩＰ、ＵＤＰヘッダ、車両固有ＩＤから構成される。ここで、図６に示すように、車両固有ＩＤ１８は、通信装置１１内の記憶部１４に保持され、制御部１３へ送られる。
【００３４】
（通信ＧＷ処理フロー）
次に、定期位置通知用ＵＤＰパケットを車両から受信した通信ＧＷにおける処理フローを図１２のフローチャートを用いて説明する。車両からデータを受信した場合は、Ｓ３０１から始まり、Ｓ３０２において、受信したデータ内容を確認する。Ｓ３０３において、定期送信かどうかを判断する。図７及び図１４Ａを比較すると明らかなように、要求データと定期送信データとはデータ部の構成が異なることで判別が可能である。即ち、定期送信データには、本来送信したい送信先ＩＰと要求データが存在しない。Ｓ３０３において、定期送信であると判断した場合には、Ｓ３０４において、保有データの中に同じ固有ＩＤがあるかどうかを判断する。定期位置送信データを最初に受信した場合には、保有データがないために、Ｓ３０７に進み、”固有ＩＤ”と”送信元ＩＰ”を”タイマ”と共に保有する。既に定期位置送信データを受信しており、同じ車両から２回目の定期位置送信データを受信した場合には、保有データの中に同じ固有ＩＤがあるために、Ｓ３０５に進み、車両固有ＩＤに対応して保有している”タイマ”を更新する。次に、Ｓ３０６において、センタに、受信した”データ（車両固有ＩＤのみ）”を転送する。具体的には、通信ＧＷがセンタに送信するデータは、図１４Ｂに示すように定期送信パケット４２であり、送信先ＩＰ、送信元ＩＰ、ＴＣＰヘッダ、車両固有ＩＤからなる。
【００３５】
（センタ処理フロー）
次に、通信ＧＷから定期位置通信データを受け取ったセンタの処理フローについて説明する。図１５にセンタ処理フローのフローチャートを示す。まず、Ｓ５０１において、定期送信受信処理を開始する。Ｓ５０２において、受信したデータ内から”車両固有ＩＤ”と”送信元ＩＰ”を取得する。次に、Ｓ５０３において、保有データの中に同じ固有ＩＤに対応した送信元ＩＰがあるかどうかを判断する。即ち、同一の車両から、送信元である通信ＧＷが異なる複数の定期位置送信データを受信しているかどうかを判断する。保有データの中に同じ固有ＩＤに対応した送信元ＩＰがある場合には、Ｓ５０４に進み、送信元ＩＰに対応した”タイマ”を更新し、無い場合には、Ｓ５０５において、”送信元ＩＰ”を”タイマ”と共に追加保有する。その後、Ｓ５０６において、データ受信待ち状態となる。
【００３６】
このステップにおけるデータの更新、追加について図１４Ｃを用いてさらに説明する。まず、一番目の応答用保持データ参照表５０１は、タイマを更新する処理を示している。即ち、同一の車両固有ＩＤを有する定期位置送信データを、３箇所の通信ＧＷから受信し、送信元ＩＰを３個保有している状態において、３個目の通信ＧＷ（ＩＰ：XXX.YY.V.C）から、タイマの時間が５２秒のときに、新たに定期位置通知データを受信した場合、タイマを、初期設定時間である６０秒に更新するものである。
次に、所定時間内に新たな定期位置通知データを受信しない場合には、応答用保持データ参照表から送信先ＩＰを削除する処理について説明する。つまり、設定したタイマの時間以内に新たに定期位置通知データを受信しない場合、当該通信ＧＷの通信圏内から外れたことがわかり、応答データを返す必要がなくなる。図１４Ｃにおける応答用保持データ参照表５０１から３２秒経過したとすると、表５０２において、送信元ＩＰがXXX.Y.ZZ.Dである２番目のデータについて、タイマの時間が０になっている。このようにタイマの時間が０になった通信ＧＷに関しては、データを削除し、応答データの送信先から除外する。このようにして、応答データを送信する際に、通信圏外となった通信ＧＷを削除することができ、無駄な送信処理をなくすことができ、応答データの送信処理を効率化することができる。
【００３７】
次に、新たに定期位置通知データを受信した通信ＧＷに関して、応答用保持データ参照表に追加を行なう処理について説明する。図１４Ｃにおいて、車両が移動することにより、ある通信ＧＷの圏外に移動した後、別の通信ＧＷ（ＩＰ：XXD.Y.V.A）の圏内に入った場合について検討する。新たに通信圏内となった通信ＧＷでは送信元ＩＰ、車両固有ＩＤをタイマと共に保有する（図１２、Ｓ３０７参照）。通信ＧＷはこれをセンタに送信し、センタでは応答用保持データ参照表５０３に送信元ＩＰをXXD.Y.V.Aとするデータを追加し、タイマの設定時間を６０秒とする。このようにして、既に保有していた通信ＧＷの送信元ＩＰとは異なる送信元ＩＰを有する通信ＧＷからの定期送信があった場合に、応答用保持データ参照表に、車両が新たに圏内に入った通信ＧＷを記録することにより、車両が通信圏内入っている最新の通信ＧＷを把握することができ、移動する車両に対して確実に応答データを返信することが可能となる。さらに、タイマが０になっていない通信ＧＷは複数存在することとなるが、応答データを送信する通信ＧＷを複数保有することにより、車両に最も近い通信ＧＷだけでなく、その周辺の複数の通信ＧＷからも応答データを送信することができ、移動中の車両が応答データを受信する確率を高めることができる。
【実施例３】
【００３８】
＜応答受信処理＞
次に、応答受信処理を行なう際のデータ処理について説明する。図１６Ａ及びＢは、データを受け取った通信対象が、通信対象→センタ→通信ＧＷ→車両へと応答データを送信する一連の処理の概要を示すものである。また、センタ、通信ＧＷにおけるデータ処理手順については、フローチャートを用いて説明する。
【００３９】
（センタにおける応答処理）
図１８にセンタにおける応答処理フローのフローチャートを示す。Ｓ６０１において、センタ応答処理を開始し、Ｓ６０２において、車両からデータを受信した通信対象より応答データを受信したことを確認する。応答データは、図１６Ｂに示すように、ＴＣＰパケットデータ５１であり、送信先ＩＰ（センタＩＰ）、送信元ＩＰ、ＴＣＰヘッダ、応答データからなり、データは車両固有ＩＤ及び応答データからなる。
【００４０】
次に、Ｓ６０３において、応答を返す車両の固有ＩＤに対応した全ての送信元ＩＰを取得する。例えば、図１７に示すように、応答用保持データ参照表６０１を参照すると、車両固有ＩＤ：vaj2ora5bであって、送信元ＩＰがXXX.Y.ZZ.B、XXX.YY.V.C、XXD.Y.V.A・・・である３基以上の通信ＧＷに関して、タイマが０ではなくデータが保存されている。
次に、Ｓ６０４において、取得した送信元ＩＰ（通信ＧＷのＩＰ）を送信先とし、”車両固有ＩＤ”と”応答データ”を付与して送信する。即ち、図１７に示すように、保持している３基の通信ＧＷの全てに対して応答送信を行なう。センタが通信ＧＷに送信するデータは、ＴＣＰパケットデータ５２であり、送信先ＩＰ（通信ＧＷのＩＰ）、送信元ＩＰ、ＴＣＰヘッダおよびデータ部からなり、データ部には車両固有ＩＤと応答データが含まれる。その後、センタはデータ受信待ち状態となる。
【００４１】
（通信ＧＷにおける応答受信処理）
通信ＧＷは応答データをセンタから受信するため、処理フローは図１１のＳ２０５から開始する。通信ＧＷがセンタから応答データを受信した場合、データから”車両固有ＩＤ”を取得し、保有しているデータと比較する。Ｓ２０７において、受信した固有ＩＤを保有しているか否かを判断する。保有している場合には、Ｓ２０８において、対応した送信元ＩＰ（車両のＩＰ）を送信先とし、受信データ内の応答データを車両に送信する。保有していない場合は、Ｓ２０９において、受信データを破棄する。
即ち、図１６Ａに示すように、通信ＧＷは受信した固有ＩＤから、既に通信ＧＷが保有している、車両固有ＩＤと送信先ＩＰの対応表を検索し、固有ＩＤから応答先車両を検索する。図１６Ａに示すように、検索で見つかった車両ＩＰを送信先ＩＰとし、送信元ＩＰ、ＵＤＰヘッダ、応答データを付加してＵＤＰパケットデータ５３を構成し、各通信ＧＷは図１７に示すように、車両にデータを送信する。受信した固有ＩＤを保有していない場合は、車両は既に当該通信ＧＷの圏外に移動済みであると判断されるため、Ｓ２０９において受信データを破棄する。
【００４２】
（車両における応答受信処理フロー）
車両が応答受信をしたか否かは、図１０のＳ７０２において判断され、応答を受信した場合は、Ｓ７０３において完了通知パケット送信を行う。
【００４３】
＜完了通知処理＞
車両が応答データを受信した場合、その結果をセンタに通知し、応答処理が完了したことを知らせる必要がある。そこで、車両は、応答データを受信した場合、完了通知を通信ＧＷを介してセンタに送信する。ここでは、この完了通知処理について説明する。
【００４４】
（車両における完了通知処理）
車両が通信ＧＷを介してセンタに向けて送信する完了通知データは、図１６Ａの下段に示すように、ＵＤＰパケットデータ６１であって、送信先ＩＰ（通信ＧＷ共通ＩＰ）、送信元ＩＰ、ＵＤＰヘッダ、完了通知データからなる。完了通知データは、車両固有ＩＤ、本来送信したい送信先ＩＰ（センタのＩＰ）、判断ＩＤからなる。ここで、判断ＩＤは、応答データの上位数ビットなどの、応答データを識別するためのＩＤ（応答データ判断ＩＤ）である。完了通知データをＵＤＰパケット形式で送ることにより、全ての通信ＧＷに一斉に、短時間で送信することができる。
【００４５】
（通信ＧＷにおける完了通知処理）
車両から完了通知データを受信した通信ＧＷは、これをセンタに転送する。このとき、ＵＤＰパケット方式をＴＣＰパケット方式に変更して送信する。ＴＣＰパケット方式で送信することにより、確実にセンタに送信することができる。
通信ＧＷがセンタに送信する完了通知データは、図１６Ｂに示すように、ＴＣＰパケットデータ６２であり、送信先ＩＰ（センタＩＰ）、送信元ＩＰ、ＴＣＰヘッダ、完了通知データからなる。完了通知データは、車両が通信ＧＷに送信するデータ部と同じである。
【００４６】
（センタにおける完了通知処理）
センタは、図１３Ａの処理フローにおいて、Ｓ４０３の受信待ちの状態にあるときに、通信ＧＷからデータを受信すると、Ｓ４０４からＳ４０５に進み、定期送信か否かを判断する。ここでは、定期送信ではないのでＳ４２２へ進む。Ｓ４２２では、データ内から”通信対象”のＩＰを取得する。通信対象は、本来送信したい送信先であり、完了通知処理において、通信対象はセンタである。次に、図１３Ｂに示すように、Ｓ４２３において、受信したデータが完了通知か否かを判断する。この判断は、図１６Ｂに示すように、データ内の本来送信先がセンタＩＰとなっていれば完了通知と判断する。完了通知である場合にはＳ４２４へ進み、完了通知処理が行なわれる。
【００４７】
センタにおいて、引き続いて行なわれる完了通知処理について、図１９の処理フローを用いて説明する。完了通知受信処理はＳ８０１から始まり、Ｓ８０２において、データ内から”判断ＩＤ”を取得する。判断ＩＤは、上述したように、図１２Ｂに示すように、完了通知データ内に含まれ、応答データを判断するために利用される。この応答データ判断ＩＤは、応答データ上位数ビットなど、複数の応答データが存在する場合に、識別できるものであればよい。次に、Ｓ８０３において、一定時間内に受信した”判断ＩＤ”か否かを判断する。即ち、車両から複数の通信ＧＷに対して完了通知データが送信されることが想定され、その場合、最初に完了通知データを受信した時点を基点として、そこから一定の時間内に受信した完了通知データは、同一の車両が、同一の応答データについての完了通知データを送信したものと考えることができる。
【００４８】
一定時間内である場合には、Ｓ８０４に進み、２番目以降の完了通知データは破棄される。破棄することにより、一つの応答データに対して複数の完了通知データを受信した場合であっても、１回だけカウントすることができ、ある応答データとそれに対応する完了通知データを対応付けることにより、重複してカウントしないようにすることができる。
【００４９】
Ｓ８０３において、一定時間内でない場合は、Ｓ８０５に進み、データ内から”車両固有ＩＤ”を取得する。取得した車両固有ＩＤにより、どの車両からの完了通知かを識別することができ、複数台の車両から同時に完了通知がされた場合でも、適切に完了処理を行うことができる。次に、Ｓ８０６において、固有ＩＤと共に保有している”カウンタ”の値を−１する。即ち、応答完了データを１つ受信した場合、保有しているデータのカウントを１つ減らすことにより、完了通知待ちの状態にある全てのデータに対して完了通知がなされたことを確認できる。例えば、車両がｎ個の要求データを送信し、センタがｎ個の応答データを送信した場合、カウントは”ｎ”となっており、完了通知データを１個受信する度に１ずつカウントを減算することにより、カウント数から完了通知の受信状況を把握することができる。
【００５０】
次に、Ｓ８０７において、”カウンタ”の値が０か否かが判断される。０である場合には、Ｓ８０８において、０のカウンタと共に保有しているデータ全てを削除する。即ち、カウンタの値が０であるということは、全ての応答データに対して完了通知処理がなされたことを意味する。その後、Ｓ８１０において、データ受信待ちとなる。
Ｓ８０７において、”カウンタ”の値が０でない場合には、Ｓ８０９において、判断ＩＤを保存する。その後、Ｓ８１０において、データ受信待ちとなる。
【００５１】
以上の実施例において、移動体として車両を例にとって説明したが、これには限定されず、飛行機や、ヘリコプタ等、移動先が決まっておらず、高速に移動する他の移動体においても適用可能である。
【００５２】
本実施例においては、１台の車両からのデータ処理について説明したが、複数台の車両が同時にデータを送受信する場合にも適用可能である。
【図面の簡単な説明】
【００５３】
【図１】ＴＣＰによる通信方法の概要を示す。
【図２】従来の車両通信における要求送信を示す。
【図３】従来の車両通信の問題点の概略図である。
【図４】本発明の車両特化型転送システムにおける要求送信の概要を示す。
【図５】本発明の通信システムの構成を示す。
【図６】本発明の車両構成の説明図である。
【図７】本発明の要求送信処理におけるデータ通信実施例を示す。
【図８】本発明の要求送信処理におけるデータ通信実施例を示す。
【図９】本発明の車両における通信処理フローを示す。
【図１０】本発明の車両における通信処理フローを示す。
【図１１】本発明の通信ＧＷにおける処理フローを示す。
【図１２】本発明の通信ＧＷにおける車両データ受信処理フローを示す。
【図１３Ａ】本発明のセンタにおける処理フローを示す。
【図１３Ｂ】本発明のセンタにおける処理フローを示す。
【図１４Ａ】本発明の定期位置送信処理におけるデータ通信実施例を示す。
【図１４Ｂ】本発明の定期位置送信処理におけるデータ通信実施例を示す。
【図１４Ｃ】本発明の定期位置送信処理におけるデータ通信実施例を示す。
【図１５】本発明のセンタにおける定期送信受信処理フローを示す。
【図１６Ａ】本発明の応答受信処理におけるデータ通信実施例を示す。
【図１６Ｂ】本発明の応答受信処理におけるデータ通信実施例を示す。
【図１７】本発明の応答受信処理におけるデータ通信実施例を示す。
【図１８】本発明のセンタにおけるセンタ応答処理フローを示す。
【図１９】本発明の完了通信受信フローを示す。
【符号の説明】
【００５４】
１    車両
３    センタ
４    サーバ
１０    アンテナ
１１    通信装置
１２    ナビゲーション装置
１３    制御部
１４    記憶部
１５    入力部
１６    出力装置
１７    無線通信端末
１８    車両固有ＩＤ
１９    要求パケットデータ生成手段
２０    位置通知用パケットデータ生成手段
２１    第１通信ＧＷ
２２    第２通信ＧＷ
２３    第３通信ＧＷ
３１    車両が通信ＧＷに送信する要求データを含んだUDPパケットデータ
３２    通信ＧＷがセンタに送信する要求データを含んだTCPパケットデータ
３３    センタが通信対象に送信する要求データを含んだTCPパケットデータ
４１    車両が通信ＧＷに送信する定期送信データを含んだUDPパケットデータ
４２    通信ＧＷがセンタに送信する定期送信データを含んだTCPパケットデータ
５１    通信対象がセンタに送信する応答データを含んだTCPパケットデータ
５２    センタが通信ＧＷに送信する応答データを含んだTCPパケットデータ
５３    通信ＧＷが車両に送信する応答データを含んだUDPパケットデータ
６１    車両が通信ＧＷに送信する完了通知データを含んだUDPパケットデータ
６２    通信ＧＷがセンタに送信する完了通知データを含んだTCPパケットデータ
１００    車両
１１１    第１ＡＰ
１１２    第２ＡＰ
１１３    第３ＡＰ
１２０    サーバ
１２１    第１通信ＧＷ
１２２    第２通信ＧＷ
１３０    センタ
１４０    車メーカセンタ
１５０    各コンテンツサーバ
５０１    応答用保持データ参照表
５０２    応答用保持データ参照表
５０３    応答用保持データ参照表
６０１    応答用保持データ参照表
【図１】
2009100047.tif 000003
【図２】
2009100047.tif 000004
【図３】
2009100047.tif 000005
【図４】
2009100047.tif 000006
【図５】
2009100047.tif 000007
【図６】
2009100047.tif 000008
【図７】
2009100047.tif 000009
【図８】
2009100047.tif 000010
【図９】
2009100047.tif 000011
【図１０】
2009100047.tif 000012
【図１１】
2009100047.tif 000013
【図１２】
2009100047.tif 000014
【図１３Ａ】
2009100047.tif 000015
【図１３Ｂ】
2009100047.tif 000016
【図１４Ａ】
2009100047.tif 000017
【図１４Ｂ】
2009100047.tif 000018
【図１４Ｃ】
2009100047.tif 000019
【図１５】
2009100047.tif 000020
【図１６Ａ】
2009100047.tif 000021
【図１６Ｂ】
2009100047.tif 000022
【図１７】
2009100047.tif 000023
【図１８】
2009100047.tif 000024
【図１９】
2009100047.tif 000025