JP2009105749A - 移動体通信装置及び移動体通信方法 - Google Patents

Abstract

【課題】車両と通信対象との間における通信を全てＴＣＰによって行なう場合及び全てＵＤＰによって行なう場合のいずれについても問題が生じていた。
【解決手段】本発明の移動体通信方法は、移動体が特定の通信ゲートウェイに要求データを含むＵＤＰパケットを送信し、通信ゲートウェイが、ＵＤＰパケットを受信し、受信した前記ＵＤＰパケットを、要求データを含むＴＣＰパケットに変換してセンタに転送し、センタが受信した要求データを含むＴＣＰパケットを通信対象に送信し、通信対象が応答データを含むＴＣＰパケットをセンタに送信し、センタが受信した応答データを含むＴＣＰパケットを通信ゲートウェイに送信し、通信ゲートウェイが受信したＴＣＰパケットを、応答データを含むＵＤＰパケットに変換して移動体に転送し、移動体が、応答データを含むＵＤＰパケットを受信する。
【選択図】図２

Description

本発明は、移動体と、インターネットに接続されたセンタを介して、通信対象との間でデータを送受信する移動体通信装置及び移動体通信方法に関し、特に移動体とセンタとの間に転送端末を介する移動体通信装置及び移動体通信方法に関する。

移動体においてインターネットや楽曲ダウンロード等といった通信は、継続した通信を可能にするローミング技術、携帯電話や無線ＬＡＮ端末といった複数の端末を用いる技術、移動情報や走行情報を用いて次の通信網を割り出すことで、安定した切り替えを行なう技術といった、安定した通信を行なう技術が開発されている。

従来技術の場合、高速移動だが移動先は一定である電車や、予測不可能な移動を行なうが速度が遅い人間には対応可能である。しかし、車両においては、高速で移動し、なおかつ必ず移動先を指定しているとは限らないために、移動先の予測ができないことがある。このため、車両においては十分な通信が行なえる保証はない。これは、現在用いられている通信端末の有効範囲の狭さによるものである。
また、車両が通信を行なう方式として、ＴＣＰ（Transmission Control Protocol)プロトコル方式あるいはＵＤＰ（User Datagram Protocol）プロトコル方式が知られている（例えば特許文献１）。

特開２００２−３２２７６号公報

図１を用いて、ＴＣＰプロトコル方式による通信方法について簡単に説明すると、まず接続する側(例えば車両)から接続要求を意味するSYNパケット１０１を送る。次に、接続される側(例えば通信対象)は接続許可を意味するACKパケットと接続要求のSYNパケットを組み合わせたSYN-ACKパケット１０２を送る。最後に、車両側からもACKパケット１０３を送り、コネクションが確立される。その後、データ１０４が送受信される。このように接続を確立する手順は一般的にはネゴシエーションと呼ばれるが、ＴＣＰプロトコル方式においてはパケットを３回送受信することから３ウェイハンドシェークと呼ばれる。

次に、移動体である車両がアクセスポイント（ＡＰ）を介して通信を行なう場合の問題点について図２を用いて説明する。ここで、車両とＡＰとの間、ＡＰとセンタとの間、センタと通信対象との間の全ての通信がＴＣＰプロトコル方式により行なわれると仮定し、車両とＡＰとの間の通信に焦点を絞って検討する。

まず、ＡＰ網圏内１００にある車両が、ＡＰ２に対してSYNパケットを送信する。次に、SYNパケットを受信したＡＰは、移動中の車両１に対してSYN-ACKパケットを送信する。車両１が移動中であってもＡＰ網圏内１００にある場合は、このSYN-ACKパケットを受信することができる。ところが、車両１がさらに移動し、ＡＰ２の圏外に出てしまった場合、車両１がACKパケットを送信しても、ＡＰ２は受信することができず、ＴＣＰプロトコル方式による接続を確立することができないという問題が生じていた。

次に、ＴＣＰプロトコル方式に代えてＵＤＰプロトコル方式による通信を行なった場合の問題点について説明する。図３は、ＵＤＰプロトコル方式の概要を示している。ここでは、車両と通信ＧＷとの間、通信ＧＷとセンタとの間、センタと通信対象との間の全ての通信がＵＤＰプロトコル方式により行なわれる場合について考える。ＵＤＰプロトコル方式は、ＴＣＰプロトコル方式とは異なり、接続を確立せず（ネゴシエーション無し）に通信を行なう。従って、車両が通信対象へのデータ送信を要求した場合、通信対象に接続されたサーバがダウンしていたとしても、車両はそれを確認できず、どこで通信が途絶えているかを知ることができない。

以上のように、車両と通信対象との間における通信を全てＴＣＰプロトコル方式によって行なう場合及び全てＵＤＰプロトコル方式によって行なう場合のいずれについても問題が生じていた。
本発明は、これらの問題を解決した移動体の通信方法の実現を目的とする。

本発明の移動体通信方法は、移動体と通信ゲートウェイとの間で通信を行なうとともに、前記通信ゲートウェイと、前記移動体の通信対象と接続されたセンタとの間で通信を行なう移動体通信方法であって、前記移動体が特定の通信ゲートウェイに、接続を確立しない方式にて要求データを送信するステップと、前記通信ゲートウェイが、前記要求データを受信し、受信した前記要求データを、接続を確立する方式にて前記センタに送信するステップと、前記センタが、受信した前記要求データを前記通信対象に送信するステップと、前記通信対象が応答データを前記センタに送信するステップと、前記センタが、受信した前記応答データを前記通信ゲートウェイに送信するステップと、前記通信ゲートウェイが、受信した前記応答データを、接続を確立しない方式にて前記移動体に送信するステップと、前記移動体が、前記応答データを受信するステップとを有することを特徴とする。

また、本発明の移動体通信装置は、通信ゲートウェイと通信を行なう移動体通信装置であって、接続を確立しない方式で要求データを送信するデータ送信手段と、送信した要求データに応答した応答データを、接続を確立しない方式で受信する応答データ受信手段と、前記応答データに対する完了通知データを、接続を確立しない方式で送信する完了通知データ送信手段とを有することを特徴とする。

本発明の移動体通信方法によれば、移動体と通信ゲートウェイとの間を接続を確立しないＵＤＰプロトコル方式で通信し、それ以外を接続を確立するＴＣＰプロトコル方式で通信することにより、移動体が高速で移動している場合であっても、確実に通信することが可能となり、その結果、より効率的な通信を行なうことができる。

また、独自のパケットを用いることで、異なったネットワーク網での通信を行なうことができる。

さらに、通信ゲートウェイとセンタ間で予め通信ラインを形成しておくため、車両からの要求をより速く転送することができる。

以下図面を参照して、本発明に係る移動体通信装置及び移動体通信方法について説明する。ただし、本発明の技術的範囲はそれらの実施の形態には限定されず、特許請求の範囲に記載された発明とその均等物に及ぶ点に留意されたい。

本発明の移動体通信方法においては、図４に示すように、まず、車両１が通信ゲートウェイ（以下、「通信ＧＷ」と呼ぶ）２およびインターネット網２０と接続されたセンタ３を介してサーバ４にある通信対象にデータを送信する。ここで、車両１は１個の通信ＧＷの通信圏内に存在していると仮定する。車両１は、特定の通信ＧＷに対してＵＤＰプロトコル方式にてＵＤＰパケットデータ（以下、「ＵＤＰパケット」という）を用いてデータ送信を行なう。通信ＧＷ２はセンタ３にデータを送信し、センタは、車両が本来送信したい送信先である通信対象へデータを送信する。このように、通信対象への送信を要求するデータ（要求データ）を車両１から通信対象に送信する一連の処理を「要求送信処理」と呼ぶ。

また、通信対象がデータを受信したことを通知するため、あるいは通信対象がデータを送信した車両１に対して返信するための応答データは、まずサーバ４を介してセンタ３に伝えられ、次にセンタ３から通信ＧＷ２に伝えられ、通信ＧＷ２から車両１に伝えられる。この一連の処理を「応答受信処理」と呼ぶ。

さらに、車両１が応答データを受信したことを通信ＧＷ２に知らせる必要がある。車両と通信ＧＷとの間の通信はＵＤＰプロトコル方式を利用しており、ネゴシエーションを行なっていないからである。車両１が応答データを受信したことを知らせるために、受信完了通知のためのデータを送信する。この一連の手順を、「受信完了通知」と呼ぶ。

まず、データの送受信を行なう移動体の一例としての車両の構成及び、本発明に係る移動体通信方法について、図５を用いて説明する。車両１は、無線通信を行なうことが可能な通信装置１１とナビゲーション装置１２とを有する。通信装置１１は、ナビゲーション装置１２と接続された制御部１３と、データ（例えば車両固有ＩＤ１８）を記憶する記憶部１４と、無線通信を行なうためのアンテナ１０と接続された無線通信端末１７とを有する。さらに通信装置１１は、データ入力を行うための入力部１５を備える。制御部１３は、後述する要求パケットデータを生成するための要求パケットデータ生成手段１９と、完了通知用パケットデータを生成するための完了通知用パケットデータ生成手段２０とを備える。ナビゲーション装置１２は、表示データ等を出力するための出力装置（例えばディスプレイ）１６を備え、出力装置１６は通信装置１１の制御部１３からの出力データに基づいて画像データや音声データ等の表示等を行う。出力装置１６は、図６に示すようにナビゲーション装置１２と一体化していてもよいし、ナビゲーション装置と分離していてもよい。さらに、本実施例では、通信装置１１とナビゲーション装置１２とが分離した構成を例示しているが、通信装置１１とナビゲーション装置１２とが一体化していてもよい。さらに、ナビゲーション装置の代わりに通信が可能なカーステレオ等を用いることもできる。さらに、本発明に係る移動体通信方法を実現する移動体通信システムは、車両１とインターネット網２００を中継し繋げる機能を持った車両独自のアクセスポイントとして機能する通信ＧＷ２と、インターネット網２００に設置されたセンタ施設３によって構成され、車両に特化した通信を可能としている。

ここで、車両がインターネット網の特定の対象（通信対象）と通信を行なう場合、車両１が通信ＧＷ２へとデータを送信し、通信ＧＷ２がセンタ３へ転送し、センタ３が通信対象からデータを取得して通信ＧＷ２に応答を返し、通信ＧＷ２は応答を車両１に返すことで通信を行なう。
本発明では、図６に示すように、車両１と通信ＧＷ２との間は、ＵＤＰプロトコル方式によりＵＤＰパケットを用いて通信を行ない、通信ＧＷ２とセンタ３との間及びセンタ３と通信対象４との間は、ＴＣＰプロトコル方式によりＴＣＰパケットを用いて通信を行なうことを特徴としている。

＜要求送信処理＞
次に、要求送信処理について、図を用いて説明する。図７Ａ〜７Ｃは、データを車両→通信ＧＷ→センタ→通信対象へと転送する一連のデータ通信実施例の概略を図示したものであり、図７Ａは、車両１から通信ＧＷ２への要求データ送信の概要を示し、図７Ｂは、通信ＧＷ２からセンタ３への要求データ送信の概要を示し、図７Ｃは、センタ３から通信対象４への要求データ送信の概要を示す。表１には要求送信処理における要求データの通信経路、送信先、送信元、ヘッダ、データ部の内容を示す。

（車両の通信処理フロー）
まず、車両の通信処理フローについて、図８のフローチャートを用いて説明する。通信処理フローは図８のＳ１０１で開始され、Ｓ１０２で車両の通信装置１１（図５参照）を起動する。次に、Ｓ１０３において車両の要求パケットデータ生成手段１９（図５参照）において要求パケットデータを生成する。図７Ａに示すように、要求パケットデータ３１は、ＵＤＰプロトコル方式によるＵＤＰパケットを利用しており、送信先ＩＰ、送信元ＩＰ、ＵＤＰヘッダ、データ部からなる。ここで、送信元ＩＰは移動体ＩＰ、即ち車両ＩＰであり、送信先ＩＰは特定の通信ＧＷＩＰである。さらに上記のデータ部には、移動体固有ＩＤ、即ち車両固有ＩＤ、本来送信したい送信先ＩＰ（通信対象のＩＰ）、要求データが含まれる。ここで、図５に示すように、車両固有ＩＤ１８は、記憶部１４に格納されている。

次に、Ｓ１０４において車両が通信ＧＷの圏内に存在するかどうかが判断され、通信圏内である場合には、Ｓ１０５において、車両１の通信装置１１に搭載した無線通信端末１７（図５参照）により要求データを含むＵＤＰパケットデータが送信され、要求パケットＵＤＰ送信が行なわれる。車両は、通信対象がデータを受信したことを確認するための応答データを、無線通信端末１７（図５参照）により受信するため、Ｓ１０６において応答待ちの状態となる。

（通信ＧＷ処理フロー）
次に、上記のようにして車両からデータを受け取った通信ＧＷの処理フローについて説明する。通信ＧＷでは、車両からデータを受信する処理と、受信したデータをセンタに送信する処理が行なわれる。通信ＧＷの処理フローのフローチャートを図９Ａ、９Ｂに示す。まず、Ｓ２０１において通信ＧＷが起動され、Ｓ２０２においてセンタへのネゴシエーション処理（３Ｗａｙハンドシェーク）を行なう。

ここで、通信ＧＷにおけるセンタへのネゴシエーション処理について詳細に説明する。図１０は、通信ＧＷとセンタとの間におけるネゴシエーション処理（３ウェイハンドシェーク）の概要を説明するものである。通信ＧＷ２は、移動体である車両からＵＤＰパケットを受信するが、これをセンタ３へ転送する際にはＴＣＰパケットに変換し、ＴＣＰプロトコル方式により送信を行なう。そのために、通信ＧＷ２はセンタ３との間で常にネゴシエーション処理を行なう。具体的には、図１０に示すように、まず通信ＧＷ２から接続要求を意味するSYNパケット７１をセンタに送る。次に、センタは接続許可を意味するACKパケットと接続要求のSYNパケットを組み合わせたSYN-ACKパケット７２を通信ＧＷに送る。最後に、通信ＧＷ側からもACKパケット７３を送り、コネクションが確立される。その後要求データ７４を送信する。本発明では、通信ＧＷ２とセンタ３との間で、SYN/SYN-ACK/ACKパケット７５を送受信することにより、通信ＧＷは常に通信接続状態を確立しておくことにより、移動体である車両からの要求データ７６をより速く転送することができる。

次に、図９Ａに示すように、Ｓ２０３において車両からデータを受信したか否かを判断し、車両からデータを受信した場合には、Ｓ２０４において、データ内から”車両固有ＩＤ”と"送信元ＩＰ”を取得する。ここで、送信元ＩＰは図７Ａに示すように、車両ＩＰである。この車両固有ＩＤと送信元ＩＰである車両ＩＰは、後述する応答データ送信処理において利用される。

次に、図９Ａに示すように、Ｓ２０５において、保有データの中に同じ固有ＩＤがあるか否かを判断する。ここでは、特定の固有ＩＤを有する同一の車両が発信したデータを複数回受信することを想定し、最初に受信したものか、２回目以降に受信したものかを判断するものである。最初に受信した場合は、保有データの中に同じ固有ＩＤはないため、Ｓ２０８に進む。Ｓ２０８では、”カウンタ”を１とし”固有ＩＤ”と”送信元ＩＰ”とともに保有する。カウンタは、後述するように、要求データの数と完了通知データの数とが一致しているか否かを確認するために利用される。

同一の車両が２回目以降に発信したデータを受信した場合には、Ｓ２０５において、保有データの中に同じ固有ＩＤがあることになり、Ｓ２０６に進む。Ｓ２０６では、同じ固有ＩＤ、送信元ＩＰを保有するとともに、保有している”カウンタ”に１を加算する。これによって、複数の要求データを同一の車両から受信した場合でも、応答すべき要求データの数を把握することができる。

次に、図９Ａに示すように、Ｓ２０７において、センタに受信した”データ”（固有ＩＤ、通信対象ＩＰ、要求データ）を転送する。転送するデータは、図９Ｂに示すように、ＴＣＰパケット３２が用いられる。ＴＣＰパケット３２は、送信先ＩＰ、送信元ＩＰ、ＴＣＰヘッダ、データ部からなる。ここで、送信先は、センタＩＰで固定されている。送信元ＩＰは、通信ＧＷである。データ部は、通信ＧＷ２が車両１から受信したＵＤＰパケットと同じであり、図７Ｂに示すように、車両固有ＩＤ、本来送信したい送信先ＩＰ、要求データからなる。

（センタ処理フロー）
次に、通信ＧＷからデータを受信するセンタの処理フローについて説明する。センタは、通信ＧＷから要求データを受信する処理と、通信対象へ受信した要求データを通信対象へ送信する処理を行なう。

図１１にセンタ処理フローのフローチャートを示す。まず、Ｓ３０１において、センタを起動し、Ｓ３０２において、通信ＧＷよりデータを受信したか否かが判断され、ここではデータを通信ＧＷから受信しているので、Ｓ３０３に進む。Ｓ３０３では、受信したデータ内から”車両固有ＩＤ”と”送信元ＩＰ”を取得し、保有する。送信元ＩＰは通信ＧＷのＩＰであり、応答時に利用する。
次に、Ｓ３０４において、受信データ内の”通信対象”のＩＰを送信先ＩＰとして設定し、要求データを送信する。データは、図７Ｃに示すようにＴＣＰパケットデータ３３であり、本来送信したい送信先（通信対象）ＩＰ、送信元ＩＰ（センタＩＰ）、ＴＣＰヘッダ、要求データからなる。これにより、車両がデータ送信を要求したデータが、所望の通信対象に送信されることとなる。

以上の要求送信処理において各端末間で送受信する要求データを表１に示す。

表１において、＊を付した車両ＩＰと車両固有ＩＤは通信ＧＷにて保有し、＊＊を付した通信ＧＷＩＰと車両固有ＩＤはセンタにて保有し、それぞれ後述する応答データ送信時に利用される。

＜応答受信処理＞
次に、応答受信処理を行なう際のデータ処理について説明する。図１２Ａ〜Ｃにデータを受け取った通信対象が、通信対象→センタ→通信ＧＷ→車両へと応答データを送信する一連の処理を示し、図１２Ａは通信対象４からセンタ３への応答データ送信の概要を示し、図１２Ｂはセンタ３から通信ＧＷ２への応答データ送信の概要を示し、図１２Ｃは車両１と通信ＧＷ２との間の応答データ及び完了通知データの送受信の概要を示す。表２には応答受信処理における応答データの通信経路、送信先、送信元、ヘッダ、データ部の内容を示す。また、センタ、通信ＧＷにおけるデータ処理手順については、フローチャートを用いて説明する。

（センタにおける応答処理）
図１１にセンタにおける処理フローのフローチャートを示す。Ｓ３０５において、通信対象より応答データを受信したか否かが判断され、応答データを受信した場合には、Ｓ３０６に進む。Ｓ３０６では、保有している送信元ＩＰ（通信ＧＷのＩＰ）を送信先とし、"車両固有ＩＤ”と”応答データ”を付与して送信する。

この送信先ＩＰを検索する手順について、表２を用いて説明する。

即ち、表１に示すように、センタは上述したように通信ＧＷから要求データを受信した際に、車両固有ＩＤと通信ＧＷＩＰとを保有しており、表２の１行目に示すように、センタが通信対象から受信した車両固有ＩＤから通信ＧＷＩＰを検索し、これを送信先ＩＰとする。
なお、応答データは、図１２Ａに示すように、ＴＣＰパケットデータ４１であり、送信先ＩＰ（センタＩＰ）、送信元ＩＰ、ＴＣＰヘッダ、応答データからなる。

（通信ＧＷにおける応答受信処理）
通信ＧＷは応答データをセンタから受信するため、処理フローは図９ＡのＳ２０９から開始する。通信ＧＷがセンタから応答データを受信した場合、Ｓ２１０に進み、データから”車両固有ＩＤ”を取得し、保有しているデータと比較する。次に、図９Ｂに示すように、Ｓ２１１において、受信した固有ＩＤと同一の固有ＩＤを保有しているか否かを判断する。保有している場合には、Ｓ２１２において、対応した送信元ＩＰ（車両のＩＰ）を送信先とし、受信データ内の応答データを車両に送信する。保有していない場合は、Ｓ２１３において、受信データを破棄する。

即ち、図１２Ｃに示すように、通信ＧＷ２は受信した車両固有ＩＤから、既に通信ＧＷが保有している、車両固有ＩＤと送信元ＩＰの対応表を検索し、固有ＩＤから応答先車両を検索する。
即ち、表１に示すように、通信ＧＷは上述したように車両から要求データを受信した際に、車両固有ＩＤと車両ＩＰとを保有しており、表２の２行目に示すように、通信ＧＷがセンタから受信した車両固有ＩＤから通信ＧＷＩＰを検索し、これを送信先ＩＰとする。
図１２Ｃに示すように、検索で見つかった車両ＩＰを送信先ＩＰとし、送信元ＩＰ、ＵＤＰヘッダ、応答データを付加してＵＤＰパケットデータ４３を構成し、通信ＧＷは車両にデータを送信する。受信した固有ＩＤを保有していない場合は、車両は既に当該通信ＧＷの圏外に移動済みであると判断されるため、上述のように、Ｓ２１３において受信データを破棄する。

（車両における応答受信処理フロー）
次に、車両における応答データの受信処理について説明する。図１３は、車両における通信処理フローを示すフローチャートである。車両は、通常はＳ４０１で応答待ちの状態にあり、車両が応答受信をしたか否かは、Ｓ４０２において判断され、車両１の通信装置１１に搭載した無線通信端末１７（図５参照）により応答を受信した場合は、Ｓ４０７において、完了通知用パケットデータ生成手段２０（図５参照）により作成した完了通知パケットデータを送信し、応答データの受信が完了する。

しかし、応答受信をしないときは、Ｓ４０５に進み、一定時間が経過しているかどうかが判断される。一定時間が経過してもなお、応答受信をしていない場合には、Ｓ４０６に進み、要求パケットを再送信する。これは、一定時間が経過しても応答データを受信していないことから、車両が通信対象に送信した要求データを通信対象が受信していないと考えられるからである。要求パケットを再送信した後は、再びＳ４０７で応答待ちの状態になる。

＜完了通知処理＞
車両が応答データを受信した場合、その結果を通信ＧＷに通知し、応答処理が完了したことを知らせる必要がある。車両と通信ＧＷ間の通信はＵＤＰプロトコル方式で行なっているため、接続は確立されていないからである。そこで、車両は、応答データを受信した場合、完了通知を通信ＧＷに送信する。ここでは、この完了通知処理について説明する。表３には完了通知通信における完了通知データの通信経路、送信先、送信元、ヘッダ、データ部の内容を示す。

（車両における完了通知処理）
図１３に示す車両における通信処理フローを示すフローチャートにおいて、車両が応答を受信した場合は、Ｓ４０７において車両は通信ＧＷに向けて、車両１の通信装置１１内の完了通知用パケットデータ生成手段２０により完了通知データを生成し、無線通信端末１７（図５参照）により完了通知パケット送信を行う。完了通知データは、図１２Ｃの下段に示すように、ＵＤＰパケット５１であって、送信先ＩＰ、送信元ＩＰ、ＵＤＰヘッダ、車両固有ＩＤからなる。図５に示すように、車両固有ＩＤ１８は、車両の通信装置１１内の記憶部１４に保持されている。完了通知データをＵＤＰプロトコル方式で送ることにより、ＴＣＰプロトコル方式のようにコネクションを確立する必要が無いので、車両が移動している場合であっても通信ＧＷに短時間で送信することができる。

（通信ＧＷにおける完了通知処理）
通信ＧＷが、車両から完了通知データを受信した場合の処理について説明する。通信ＧＷが完了通知を受信したか否かは、図９Ｂに示した通信ＧＷ処理フローにおける、Ｓ２１４において判断される。通信ＧＷが完了通知を受信した場合、Ｓ２１５に進み、送信した固有ＩＤと共に保有している”カウンタ”の値を−１し、値が０であれば保有を破棄する。
即ち、表１に示すように、通信ＧＷは上述したように車両から要求データを受信した際に、車両固有ＩＤと車両ＩＰとを保有しており、表３に示すように、通信ＧＷが車両から受信した車両固有ＩＤの数をカウントする。

ここでカウンタは、車両から通信対象に向けて送信された要求データの数を通信ＧＷがカウントするものであり、例えばｎ個の要求データが送信されていれば、カウンタの値はｎとなっている。車両が応答データを受信し、通信ＧＷに対して完了通知がなされた場合、完了通知のたびにカウンタを１ずつ減算することにより、車両が通信対象に対して送信した要求データに対して、完了通知がなされたか否かが確認できる。例えば、上記の例で、ｎ個の完了通知データを受信した場合、カウンタの値は０となり、全ての要求データに対して、完了通知がなされたこととなる。この場合、車両固有ＩＤと送信元ＩＰ（車両ＩＰ）を保有しておく必要が無くなるため、図１２Ｃに示すようにデータを破棄する。

ここで、例えば２台の車両（車両固有ＩＤ：Ｘ、Ｙ）から、要求データまたは完了通知データが送信された場合について表４を用いて説明する。

表４に示すように、時刻：ｔ１、ｔ２、ｔ３、・・・に、各車両が要求データまたは完了通知データを送信したとする。時刻ｔ１において、通信ＧＷは車両Ｘから要求データを受信するため、Ｘ用カウンタは１となる。時刻ｔ３において完了通知を受信した場合には、カウンタの数を１だけ減算して、その結果、Ｘ用カウンタは０となる。同様に、車両Ｙから時刻ｔ２とｔ４に要求データを受信したとすると、カウンタの数は２となる。さらに、時刻ｔ６とｔ８において完了通知を受信すると、それぞれ１ずつ減算するため、カウンタの数は０となる。このようにして、カウンタにより、通信ＧＷが受信した要求データの数と、完了通知データの数を一致させることができ、車両と通信ＧＷとの間の通信をＵＤＰプロトコル方式により行なっても確実にデータの送受信を行うことができる。

以上のようにして、移動体である車両と通信ＧＷとの間をＵＤＰプロトコル方式によって送受信しても、完了通知データを送受信し、要求データ数と完了通知データ数とをカウントすることで確実にデータの送受信を行うことができる。さらに、車両と通信ＧＷとの間のデータの送受信をＵＤＰプロトコル方式により行なっているため、データの送受信を速く行うことができ、車両が移動している場合であっても確実に通信することが可能となり、より効率的な通信を行なうことができる。

本実施例においては、接続を確立しない通信方式として、ＵＤＰプロトコル方式の例を示し、接続を確立する通信方式として、ＴＣＰプロトコル方式の例を示したが、これらには限定されない。

以上の実施例において、移動体として車両を例にとって説明したが、これには限定されず、飛行機や、ヘリコプタ等、移動先が決まっておらず、高速に移動する他の移動体においても適用可能である。また、本実施例においては、１台の車両からのデータ処理について説明したが、複数台の車両が同時にデータを送受信する場合にも適用可能である。

さらに、本実施例においては、通信装置１１はナビゲーション装置１２とは独立したものとして説明したが、ナビゲーション装置内に組み込まれていてもよい。

ＴＣＰプロトコル方式による通信方法の概要を示す。 従来の車両通信の問題点の概略を示す。 ＵＤＰプロトコル方式による通信方法における問題点を示す。 本発明の移動体通信方法のシステム構成を示す。 本発明の移動体通信装置を搭載した車両構成を示す。 本発明の各端末間の通信方式を示す。 本発明の移動体通信方法における車両から通信ＧＷへの要求データ送信の概要を示す。 本発明の移動体通信方法における通信ＧＷからセンタへの要求データ送信の概要を示す。 本発明の移動体通信方法におけるセンタから通信対象への要求データ送信の概要を示す。 本発明の移動体通信方法に係る車両における通信処理フローを示す。 本発明の移動体通信方法に係る通信ＧＷにおける処理フローを示す。 本発明の移動体通信方法に係る通信ＧＷにおける処理フローを示す。 本発明の移動体通信方法における通信ＧＷとセンタとの間の３ウェイハンドシェークの手順を示す。 本発明の移動体通信方法に係るセンタにおける処理フローを示す。 本発明の移動体通信方法における通信対象からセンタへの応答データ送信の概要を示す。 本発明の移動体通信方法におけるセンタから通信ＧＷへの応答データ送信の概要を示す。 本発明の移動体通信方法における車両と通信ＧＷとの間の応答データ及び完了通知データの送受信の概要を示す。 本発明の移動体通信方法に係る車両における通信処理フローを示す。

符号の説明

１ 車両
２ 通信ＧＷ
３ センタ
４ サーバ
１０ アンテナ
１１ 通信装置
１２ ナビゲーション装置
１３ 制御部
１４ 記憶部
１５ 入力部
１６ 出力装置
１７ 無線通信端末
１８ 車両固有ＩＤ
１９ 要求パケットデータ生成手段
２０ 完了通知用パケットデータ生成手段
２００ インターネット網
３１ 車両が通信ＧＷに送信する要求データを含んだＵＤＰパケットデータ
３２ 通信ＧＷがセンタに送信する要求データを含んだＴＣＰパケットデータ
３３ センタが通信対象に送信する要求データを含んだＴＣＰパケットデータ
４１ 通信対象がセンタに送信する応答データを含んだＴＣＰパケットデータ
４２ センタが通信ＧＷに送信する応答データを含んだＴＣＰパケットデータ
４３ 通信ＧＷが車両に送信する応答データを含んだＵＤＰパケットデータ
５１ 車両が通信ＧＷに送信する完了通知データを含んだＵＤＰパケットデータ

Claims (11)

1. 移動体と通信ゲートウェイとの間で通信を行なうとともに、
   前記通信ゲートウェイと、前記移動体の通信対象と接続されたセンタとの間で通信を行なう移動体通信方法であって、
   前記移動体が特定の通信ゲートウェイに、接続を確立しない方式にて要求データを送信するステップと、
   前記通信ゲートウェイが、前記要求データを受信し、受信した前記要求データを、接続を確立する方式にて前記センタに送信するステップと、
   前記センタが、受信した前記要求データを前記通信対象に送信するステップと、
   前記通信対象が応答データを前記センタに送信するステップと、
   前記センタが、受信した前記応答データを前記通信ゲートウェイに送信するステップと、
   前記通信ゲートウェイが、受信した前記応答データを、接続を確立しない方式にて前記移動体に送信するステップと、
   前記移動体が、前記応答データを受信するステップとを有する移動体通信方法。
2. 前記移動体が特定の通信ゲートウェイに接続を確立しない方式にて要求データを送信するステップにおいて、
   前記移動体が特定の通信ゲートウェイに送信するデータは、送信先インターネット・プロトコル（ＩＰ）を通信ゲートウェイＩＰとし、送信元ＩＰを移動体ＩＰとし、移動体固有ＩＤと通信対象ＩＰと要求データとをデータ部としていることを特徴とする請求項１に記載の移動体通信方法。
3. 前記通信ゲートウェイが、前記要求データを受信し、接続を確立する方式にて受信した前記要求データを前記センタに送信するステップにおいて、
   前記通信ゲートウェイは、受信したデータ内の移動体固有ＩＤと、送信元ＩＰである移動体ＩＰとを保有し、
   前記通信ゲートウェイが前記センタに送信するデータは、送信先をセンタＩＰとし、送信元ＩＰを通信ゲートウェイＩＰとして、移動体から受信したデータ部と同一のデータ部を有することを特徴とする請求項２に記載の移動体通信方法。
4. 前記センタが受信した前記要求データを前記通信対象に送信するステップにおいて、
   前記センタは、移動体固有ＩＤと送信元ＩＰである通信ゲートウェイのＩＰを保有し、
   前記センタが前記通信対象に送信するデータは、送信先ＩＰをデータ部内の通信対象ＩＰとし、送信元ＩＰをセンタＩＰとして、要求データをデータ部としていることを特徴とする請求項３に記載の移動体通信方法。
5. 前記センタが、受信した前記応答データを前記通信ゲートウェイに送信するステップにおいて、
   前記センタが前記通信ゲートウェイに送信するデータは、送信先ＩＰを保有していた通信ゲートウェイＩＰとし、送信元ＩＰをセンタＩＰをとし、移動体固有ＩＤと応答データとをデータ部としていることを特徴とする請求項４に記載の移動体通信方法。
6. 前記通信ゲートウェイが、接続を確立しない方式にて、受信した前記応答データを前記移動体に送信するステップにおいて、
   受信したデータ内の移動体固有ＩＤを元に移動体ＩＰを検索し、
   前記通信ゲートウェイが前記移動体に送信するデータは、送信先ＩＰを移動体ＩＰとし、送信元ＩＰを通信ゲートウェイＩＰとして、応答データをデータ部としていることを特徴とする請求項５に記載の移動体通信方法。
7. 前記移動体が、応答データを受信するステップに続いて、
   前記移動体が、送信先ＩＰを通信ゲートウェイＩＰとし、送信元ＩＰを移動体ＩＰとして、移動体固有ＩＤのみをデータ部としたデータを受信完了通知として前記通信ゲートウェイに送信するステップをさらに有することを特徴とする請求項６に記載の移動体通信方法。
8. 前記通信ゲートウェイが受信したデータを、応答データを含むデータに変換して前記移動体に送信した後、所定の時間が経過しても前記移動体から受信完了通知を受信しない場合には、応答データを含むデータを再度送信することを特徴とする請求項７に記載の移動体通信方法。
9. 前記通信ゲートウェイが移動体固有ＩＤと移動体ＩＰを保有する場合、通信カウンタを初期値を１として一緒に保有し、
   前記通信ゲートウェイが移動体からデータを受信した際、受信したデータの移動体固有ＩＤが保有している移動体固有ＩＤと同じであればカウンタで１を加算し、完了通知を受信した際にはカウンタで１を減算し、
   カウンタが０になった場合、０になったカウンタと一緒に保有していた移動体固有ＩＤと移動体ＩＰを破棄することを特徴とする請求項８に記載の移動体通信方法。
10. 前記接続を確立しない方式は、ＵＤＰパケットを送受信するＵＤＰプロトコル方式であり、
    前記接続を確立する方式は、ＴＣＰパケットを送受信するＴＣＰプロトコル方式である請求項１乃至９のいずれか一項に記載の移動体通信方法。
11. 通信ゲートウェイと通信を行なう移動体通信装置であって、
    接続を確立しない方式で要求データを送信するデータ送信手段と、
    送信した要求データに応答した応答データを、接続を確立しない方式で受信する応答データ受信手段と、
    前記応答データに対する完了通知データを、接続を確立しない方式で送信する完了通知データ送信手段とを有することを特徴とする移動体通信装置。

Images