JP4072031B2 - 移動体パケット通信システム - Google Patents
移動体パケット通信システム Download PDFInfo
- Publication number
- JP4072031B2 JP4072031B2 JP2002272571A JP2002272571A JP4072031B2 JP 4072031 B2 JP4072031 B2 JP 4072031B2 JP 2002272571 A JP2002272571 A JP 2002272571A JP 2002272571 A JP2002272571 A JP 2002272571A JP 4072031 B2 JP4072031 B2 JP 4072031B2
- Authority
- JP
- Japan
- Prior art keywords
- vehicle
- communication
- communication means
- server device
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、移動体パケット通信システムに関し、特に、列車や自動車など、高速移動中の車両内に存在する端末装置と外部のサーバ装置との間でパケット通信を行うためのシステムに関する。
【０００２】
【従来の技術】
近年、携帯電話、ＰＤＡ装置、ノート型パソコンなど、移動体通信の端末装置として機能する様々な電子機器が普及し始めており、インターネットの普及と相まって、外部のサーバ装置との間でパケット通信が盛んに行われている。また、街頭では、様々な施設に無線ＬＡＮの設置が試みられており、移動体通信用の端末装置をＴＣＰ／ＩＰのプロトコルでインターネットへ接続する環境も構築されつつある。
【０００３】
【発明が解決しようとする課題】
現在普及している携帯電話は、列車や自動車などに乗車して移動中の状態であっても、ローミングなどの技術を用いることにより通信が可能である。したがって、移動中の車両においても、携帯電話などの端末装置によって会話を行ったり、外部のサーバ装置などに接続してデータパケットをやりとりしたりすることは可能である。しかしながら、現在、高速移動中の端末装置に対するパケット通信の通信速度は著しく低く制限されており、大量のデータのやりとりを行うには不適当である。これは、高速移動中の端末装置に対する無線による通信速度を向上させることが、現時点では、技術的に非常に困難であることに起因している。このため、車両に乗車している間に、画像データなどの大容量データが添付された電子メールを受信したり、外部のサーバ装置から大容量のデータをダウンロードしたりするには、極めて長い時間が必要になり、実用上、大容量データパケットの通信は、高速移動中の車両からはできなかった。
【０００４】
そこで本発明は、高速移動中の車両に搭乗していながら、大容量のデータパケット通信が可能になる移動体パケット通信システムを提供することを目的とする。
【０００５】
【課題を解決するための手段】
【０００６】
(1) 本発明の第１の態様は、車両とともに移動中の端末装置と外部のサーバ装置との間でパケット通信を行うための移動体パケット通信システムにおいて、
車両内に設置された車両内通信手段と、
車両が停車するか、または、通常の運行速度よりも低い速度で通過することが予定されている運行経路上の複数の通信ポイントにそれぞれ設置された複数の経路上通信手段と、
これら経路上通信手段に対して接続され、外部のサーバ装置との間でネットワークを介してデータパケットのやりとりを行う機能をもった代理サーバ装置と、
を設け、
車両内通信手段は、車両内に存在する端末装置との間で無線によりデータパケットの送受信を行う車内通信機能と、車両が通信ポイント付近に停車している状態、もしくは、車両が通信ポイント付近を通常の運行速度よりも低い速度で通過している状態において、当該通信ポイントに設置された経路上通信手段との間で無線によりデータパケットの送受信を行う車外通信機能と、を有し、車内通信機能により端末装置からデータパケットを受信した場合に、このデータパケットを車外通信機能が実行可能になるまで一時的に保管し、車外通信機能が実行可能になったときに、一時的に保管していたデータパケットを経路上通信手段へと送信する処理を実行し、経路上通信手段からデータパケットを受信した場合に、このデータパケットを車内通信機能により宛先となる端末装置へ送信する処理を実行するようにし、
経路上通信手段は、車両内通信手段からデータパケットを受信した場合に、このデータパケットを代理サーバ装置へと送信する処理を実行し、代理サーバ装置から所定の端末装置宛のデータパケットを受信した場合に、このデータパケットを、自己が設置された通信ポイント付近に到来した車両内に設置された車両内通信手段へと送信する処理を実行するようにし、
代理サーバ装置は、経路上通信手段から受信したデータパケットをネットワークを介して外部のサーバ装置へと送信する処理を実行するとともに、外部のサーバ装置からネットワークを介して受信したデータパケットを、複数の通信ポイントにそれぞれ設置された複数の経路上通信手段へと送信する処理を実行するようにし、
車両内通信手段に、車両内に存在する端末装置から受信したデータパケットに対してデータ圧縮を行う機能をもたせ、代理サーバ装置に、圧縮されたデータパケットを伸張する機能をもたせ、車両内通信手段から代理サーバ装置へと転送されるデータパケットが圧縮された状態になるようにし、
代理サーバ装置に、外部のサーバ装置から受信したデータパケットに対してデータ圧縮を行う機能をもたせ、車両内通信手段に、圧縮されたデータパケットを伸張する機能をもたせ、代理サーバ装置から車両内通信手段へと転送されるデータパケットが圧縮された状態になるようにし、
車両内通信手段に、更に、端末装置から外部のサーバ装置に対して、所定時間内の返信を要求するデータパケットの送信が行われたときには、外部のサーバ装置に代わって返信を行う代理返信機能をもたせるようにしたものである。
【０００７】
(2) 本発明の第２の態様は、上述の第１の態様に係る移動体パケット通信システムにおいて、
所定の路線に沿って走行する列車の車両内に車両内通信手段を設置し、この路線上の駅に通信ポイントを定義して経路上通信手段を設置するようにしたものである。
【０００８】
(3) 本発明の第３の態様は、上述の第１の態様に係る移動体パケット通信システムにおいて、
所定の道路上を走行する自動車の車両内に車両内通信手段を設置し、この道路上の交差点、料金所、もしくはパーキングエリアに通信ポイントを定義して経路上通信手段を設置するようにしたものである。
【０００９】
(4) 本発明の第４の態様は、上述の第１〜第３の態様に係る移動体パケット通信システムにおいて、
車両内通信手段にＤＨＣＰの機能をもたせ、この機能により車両内に存在する端末装置に対してプライベートＩＰアドレスを付与し、代理サーバ装置にＮＡＴの機能をもたせ、この機能によりプライベートＩＰアドレスとグローバルＩＰアドレスとの変換を行わせ、システム内部ではプライベートＩＰアドレスを用いたパケット通信が行われ、外部のサーバ装置との間ではグローバルＩＰアドレスを用いたパケット通信が行われるようにしたものである。
【００１１】
(5) 本発明の第５の態様は、上述の第１〜第４の態様に係る移動体パケット通信システムにおいて、
代理サーバ装置が、外部のサーバ装置からネットワークを介して受信したデータパケットを、当該データパケットの宛先となる端末装置が存在する車両が所定時間内に到来する可能性のある所定の地理的範囲内の複数の通信ポイントにそれぞれ設置された経路上通信手段へと送信する処理を実行するようにしたものである。
【００１２】
(6) 本発明の第６の態様は、上述の第１〜第５の態様に係る移動体パケット通信システムにおいて、
代理サーバ装置が、個々の車両宛のデータパケットごとに、それぞれ別個のパケット群を構成し、構成した各パケット群のそれぞれを複数の経路上通信手段へと送信する処理を行い、
車両内通信手段が、所定の経路上通信手段から自己車両宛のパケット群を受信したときに、当該パケット群の受領を確認する受領確認情報を、パケット群を受信した所定の経路上通信手段に対して送信する処理を行い、
各経路上通信手段が、代理サーバ装置から受信したデータパケットを、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両内に設置された車両内通信手段へと繰り返し送信する処理を実行し、かつ、いずれか１つの経路上通信手段が特定のパケット群についての受領確認情報を受信した場合に、この特定のパケット群と同一のパケット群を廃棄する処理を実行するようにしたものである。
【００１３】
(7) 本発明の第７の態様は、上述の第１〜第５の態様に係る移動体パケット通信システムにおいて、
各経路上通信手段が、代理サーバ装置から受信したデータパケットを、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両内に設置された車両内通信手段へと繰り返し送信する処理を実行し、かつ、代理サーバ装置から受信した後に所定の時間が経過したデータパケットについては、これを廃棄する処理を実行するようにしたものである。
【００１４】
(8) 本発明の第８の態様は、上述の第１〜第５の態様に係る移動体パケット通信システムにおいて、
各経路上通信手段が、代理サーバ装置から受信したデータパケットを、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両内に設置された車両内通信手段へと繰り返し送信する処理を実行し、かつ、送信繰り返し回数が所定回数に達したデータパケットについては、これを廃棄する処理を実行するようにしたものである。
【００１５】
(9) 本発明の第９の態様は、上述の第１〜第５の態様に係る移動体パケット通信システムにおいて、
各経路上通信手段が、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両を特定する処理を実行し、代理サーバ装置から受信したデータパケットのうち、特定された車両宛のデータパケットのみを選択し、この選択したデータパケットを到来した車両内に設置された車両内通信手段へと送信した後にこれを廃棄する処理を実行し、かつ、他の経路上通信手段によって車両への送信が完了したパケットと同一のパケットについては、これを廃棄する処理を実行するようにしたものである。
【００１６】
(10) 本発明の第１０の態様は、上述の第１〜第９の態様に係る移動体パケット通信システムにおいて、
車両内通信手段が、
端末装置から外部のメールサーバ装置に対して、電子メールの第１の受信命令が送信された場合に、車外通信機能が実行可能になるまで第１の受信命令を一時的に保管するとともに、メールサーバ装置に代わって、端末装置に対して受信すべき電子メールがないことを示す疑似的な返信を行い、
車外通信機能が実行可能になったときに、保管していた第１の受信命令をメールサーバ装置へと送信する処理を実行し、メールサーバ装置から第１の受信命令に応じて正規の返信が戻ってきた場合に、この正規の返信を一時的に保管し、
端末装置からメールサーバ装置に対して、電子メールの第２の受信命令が送信された場合に、第１の受信命令に応じて戻ってきた正規の返信が保管されていたら、第２の受信命令をメールサーバ装置へと送信することなしに、端末装置に対して、保管されていた正規の返信を第２の受信命令に対するメールサーバ装置からの返信であるかのように送信する代理返信機能を有するようにしたものである。
【００１７】
【発明の実施の形態】
以下、本発明を図示する実施形態に基づいて説明する。
【００１８】
＜＜＜ §１． 基本的な実施形態 ＞＞＞
図１は、本発明の一実施形態に係る移動体パケット通信システム１００の基本構成を示すブロック図である。この移動体パケット通信システム１００は、図に一点鎖線で囲って示した各構成要素によって構成され、図示のとおり、車両内通信手段１０と、経路上通信手段２１，２２，２３と、代理サーバ装置３０と、によって構成されている。この移動体パケット通信システム１００の役割は、所定の運行経路Ｌに沿って車両Ａとともに移動中の端末装置Ｔと、インターネット４０を介して接続されている外部のサーバ装置５１〜５５との間でパケット通信を行うことである。なお、図１において、運行経路Ｌ、車両Ａ、端末装置Ｔ自身は、この移動体パケット通信システム１００の構成要素ではないが、説明の便宜上、一点鎖線で囲った内部の構成要素として図示してある。
【００１９】
ここで車両Ａは、所定の運行経路Ｌに沿って移動するものであれば、どのようなものであってもかまわないが、実用上は、所定の路線に沿って走行する列車の車両か、あるいは、所定の道路上を走行する自動車の車両ということになろう。また、端末装置Ｔは、このような列車の車両や自動車の車両に搭乗した者が所持している携帯電話、ＰＤＡ装置、ノート型パソコンなどの移動式端末装置ということになる。なお、図１では、１両の車両Ａ内に１台の端末装置Ｔが描かれているだけであるが、列車の場合、車両Ａは複数両が連結されているのが一般的であり、また、多数の乗客がそれぞれ端末装置Ｔを所持しながら搭乗していることになる。
【００２０】
車両Ａ内には、車両内通信手段１０が設置されている。また、運行経路Ｌ上の所定箇所には、複数の通信ポイントＰ１，Ｐ２，Ｐ３が定義され、各通信ポイントＰ１，Ｐ２，Ｐ３には、それぞれ経路上通信手段２１，２２，２３が設置されている。ここで、各通信ポイントＰ１，Ｐ２，Ｐ３は、車両Ａが停車するか、または、通常の運行速度よりも低い速度で通過することが予定されている運行経路Ｌ上の所定箇所に定義される。これは、車両Ａに設置された車両内通信手段１０と、各経路上通信手段２１，２２，２３との間で、十分な通信速度をもってパケット通信が可能になるようにするための配慮である。
【００２１】
既に述べたとおり、現在、高速移動中の端末装置に対するパケット通信の通信速度は、技術的に著しく低く制限されており、大量のデータのやりとりを行うには不適当である。すなわち、列車や自動車が通常の運行速度で運行経路Ｌ上を走行している状態では、車両内通信手段１０と経路上通信手段２１，２２，２３との両者間において、十分な通信速度を確保することができない。そこで、本発明では、両者間のパケット通信を、車両Ａが停車している状態か、あるいは、通常の運行速度よりも低い速度（技術的に必要な通信速度が確保できる速度）で走行している状態で行うこととした。
【００２２】
車両Ａが所定の路線に沿って走行する列車の車両である場合には、運行経路Ｌは、この列車の路線ということになるので、通信ポイントＰ１，Ｐ２，Ｐ３は、この路線上の所定の駅（すべての駅でもよいし、一部の駅でもよい）に定義し、経路上通信手段２１，２２，２３は、これらの駅に設置すればよい。そうすれば、列車がこれらの駅に停車した時点で、車両内通信手段１０と経路上通信手段２１，２２，２３との間で、十分な通信速度をもった通信が可能になる。もちろん、普通列車、急行列車、特急列車など、列車ごとに停車駅が異なる場合には、普通列車については、すべての通信ポイントＰ１，Ｐ２，Ｐ３が本来の通信ポイントとして機能するが、急行列車については、通信ポイントＰ２だけが本来の通信ポイントとして機能する、というような運用になってもかまわない。また、運行経路Ｌ上で列車が必ず徐行することになっている地点があり、この徐行速度であれば、十分な通信速度を確保できるのであれば、そのような徐行地点を通信ポイントとして定義して、経路上通信手段の設置を行うようにしてもよい。
【００２３】
一方、車両Ａが所定の道路上を走行する自動車の車両である場合には、運行経路Ｌは、この自動車が走行予定の道路ということになるので、通信ポイントＰ１，Ｐ２，Ｐ３は、この道路上の交差点、料金所、もしくはパーキングエリアに定義し、経路上通信手段２１，２２，２３は、これらいずれかの通信ポイントに設置すればよい。これらの通信ポイントでは、車両Ａが停車するか、あるいは、通常の運行速度よりも低い速度で走行することが予定されており、十分な通信速度をもった通信が可能になる。もちろん、交差点の場合は、赤信号であれば停車するが、青信号であれば通常の運行速度で通過する、というような運行が行われることになるが、本発明では、通信ポイントは、車両が必ず停車するか通信可能な低い速度で通過する地点に設定する必要はなく、ある条件の下で、車両が停車するか通信可能な低い速度で通過することが予定されている地点に設定すればよい。別言すれば、本発明において設定された複数の通信ポイントでは、車両内通信手段１０と経路上通信手段２１，２２，２３との間の通信が可能であることが必ずしも保証されている必要はない。
【００２４】
道路上を走行する自動車の車両について本発明を適用する場合の最も実用的なケースは、高速道路上を運行する長距離路線バスである。このようなバスでは、運行路線や停車予定となる料金所やパーキングエリアなどが予め定まっているので、確実に通信可能となる通信ポイントを設定することが容易である。ただ、本発明の適用は、必ずしもこのような路線バスに限定されるものではない。たとえば、いわゆるマイカーのような一般自動車に適用するのであれば、主要な幹線道路などを運行路線Ｌとして定義し、この幹線道路上の交差点などに通信ポイントを設定すればよい。本発明における運行路線Ｌは、必ずしも１本の一次元的な路線である必要はなく、二次元的な広がりをもった道路網であってもよく、車両の運行経路は、この道路網内の任意の経路であってかまわない。
【００２５】
このように、本発明は、自動車を車両とした場合にも適用可能であるが、ここでは、説明の便宜上、列車の車両に適用し、各通信ポイントＰ１，Ｐ２，Ｐ３を、この列車の運行路線上の駅に設定した具体的な実施形態を述べることにする。したがって、図１に示す各経路上通信手段２１，２２，２３は、それぞれ各駅の構内に設けられている。また、ここに示す実施形態では、便宜上、運行路線Ｌ上の３ケ所に通信ポイントＰ１，Ｐ２，Ｐ３が設定された例を述べるが、もちろん、実際には、より多数の通信ポイントが設定され、より多数の経路上通信手段がそれぞれ設置されることになる。
【００２６】
代理サーバ装置３０は、各経路上通信手段２１，２２，２３に対して接続され、また、インターネット４０を介して、外部のサーバ装置５１〜５５との間でデータパケットのやりとりを行う機能をもった装置である。代理サーバ装置３０と経路上通信手段２１，２２，２３との間の接続は、この例では、すべて有線によって行っているが、どのような方法で接続してもかまわない。また、代理サーバ装置３０をインターネット４０へ接続する具体的な手段も任意のものでかまわない。代理サーバ装置３０は、要するに、インターネット４０に対して、種々のプロトコルでアクセス可能ないわゆる「プロキシサーバ」として機能する。また、図１に示す外部のサーバ装置５１〜５５（実際には、インターネット４０には、膨大な数のサーバ装置が接続されているが、ここでは説明の便宜上、５台のみを示す）は、インターネット４０に接続された一般的なメールサーバやファイルサーバなどのサーバ装置であり、ここに示す移動体パケット通信システムの目的は、車両Ａ内の端末装置Ｔとこれら外部のサーバ装置５１〜５５との間でパケット通信を行うことにある。
【００２７】
結局、この移動体パケット通信システムを構築するには、各車両Ａ内に設置した車両内通信手段１０と、個々の通信ポイントＰ１，Ｐ２，Ｐ３に設置した経路上通信手段２１，２２，２３と、これらに接続された代理サーバ装置３０と、を用意すればよい。なお、代理サーバ装置３０は、必ずしも１台のサーバ装置にする必要はなく、たとえば、関東地区、関西地区など、個々の地区を担当する複数の代理サーバ装置を設けるようにしてもかまわない。
【００２８】
続いて、上述した各構成要素の具体的な機能について説明する。まず、車両内通信手段１０は、上述したように、各車両Ａに設置される通信手段であるが、２つの通信機能を有している。第１の通信機能は、車両内に存在する端末装置Ｔとの間で無線によりデータパケットの送受信を行う車内通信機能である。このような機能をもった通信手段は、既に、無線ＬＡＮ装置として広く利用されている。この車内通信機能により、車両Ａの乗客が所持する携帯電話などの端末装置Ｔと、無線によりデータパケットの交換が行われる。両者間の無線通信のプロトコルは、パケット通信が可能なプロトコルであればどのようなものでもかまわないが、実用上は、ＩＰアドレスを用いた汎用プロトコルを用いるのが好ましい。乗客は、このような汎用プロトコルに対応した一般的な端末装置Ｔを用意すれば、このシステムの利用が可能になる。
【００２９】
この車内通信機能は、後述する車外通信機能とは異なり、常に実行可能な状態となっている。これは、端末装置Ｔが車両Ａとともに移動するので、常に車両内通信手段１０と通信可能な環境におかれているためである。なお、複数車両編成の列車の場合、１台の車両に車両内通信手段１０を設けただけでは、全車両の乗客が保持する端末装置Ｔと無線通信することが困難な場合もあるが、その場合には、たとえば、１両おきに別個独立した車両内通信手段１０を設けるなどの措置を講じればよい。
【００３０】
車両内通信手段１０の第２の通信機能は、各通信ポイントＰ１，Ｐ２，Ｐ３に設置された経路上通信手段２１，２２，２３との間で、無線によりデータパケットの送受信を行う車外通信機能である。もっとも、この車外通信機能は、常に実行可能な状態となっているわけではなく、前述したとおり、車両Ａが特定の通信ポイント付近に停車している状態、もしくは、車両Ａが特定の通信ポイント付近を通常の運行速度よりも低い速度で通過している状態において、当該特定の通信ポイントに設置された経路上通信手段との間でのみ実行可能になる。たとえば、図示の状態では、車両Ａは、通信ポイントＰ１とＰ２の間を通常の運行速度で走行中であるので、現時点では車外通信機能は実行できないが、通信ポイントＰ２が設定された駅に到着し、この駅で停車している間は、通信ポイントＰ２に設置されている経路上通信手段２２との間で車外通信機能が実行可能となり、データパケットの送受を行うことができる。
【００３１】
このように、車内通信機能は、常に実行可能な状態となっているにもかかわらず、車外通信機能は、いずれかの通信ポイントの近傍でなければ実行可能にならない。したがって、車内と車外との通信を仲介する役割を果たす車両内通信手段１０および経路上通信手段２１，２２，２３には、いわゆるバッファ機能をもたせておく必要がある。
【００３２】
たとえば、車両Ａの乗客が、端末装置Ｔから外部のサーバ装置５１に対してデータパケットを送信する操作を行ったとすると、このデータパケットは、図示の例の場合、端末装置Ｔ→車両内通信手段１０→経路上通信手段２２→代理サーバ装置３０→インターネット４０→外部のサーバ装置５１という伝送経路で送信されることになるが、ここで、車両内通信手段１０→経路上通信手段２２なる部分は、車両Ａが通信ポイントＰ２（駅）に到着した時点で初めて実行可能になる。したがって、通信ポイントＰ２に到着するまでの間に、端末装置Ｔから受信したデータパケットは、車両内通信手段１０内に一時的に保管しておく必要がある。このため、車両内通信手段１０は、車内通信機能により端末装置Ｔからデータパケットを受信した場合に、このデータパケットを車外通信機能が実行可能になるまで一時的に保管し、車外通信機能が実行可能になったときに、一時的に保管していたデータパケットを経路上通信手段へと送信する処理を実行する。
【００３３】
一方、上述のようにして、端末装置Ｔから外部のサーバ装置５１に対して送信されたデータパケットに対する応答として、外部のサーバ装置５１から端末装置Ｔ宛に所定のデータパケットが送信された場合、このデータパケットは、外部のサーバ装置５１→インターネット４０→代理サーバ装置３０→経路上通信手段２３（たとえば、この時点で、車両Ａが通信ポイントＰ２からＰ３へと向かっている場合）→車両内通信手段１０→端末装置Ｔという伝送経路で送信されることになるが、ここで、経路上通信手段２３→車両内通信手段１０なる部分は、車両Ａが通信ポイントＰ３（駅）に到着した時点で初めて実行可能になる。したがって、通信ポイントＰ３に到着するまでの間に、経路上通信手段２３は、端末装置Ｔ宛のデータパケットを、一時的に保管しておく必要がある。経路上通信手段２３は、車両Ａが通信ポイントＰ３に到着したら、保管していたデータパケットを車両内通信手段１０へと送信する。車両内通信手段１０は、車外通信機能により、このデータパケットを受信し、このデータパケットを車内通信機能により宛先となる端末装置Ｔへ送信する処理を実行する。
【００３４】
経路上通信手段２１，２２，２３の役割は、車両内通信手段１０と代理サーバ装置３０とを仲介することにある。すなわち、経路上通信手段２１，２２，２３は、それぞれ通信ポイントＰ１，Ｐ２，Ｐ３（駅）に停車中の車両Ａ内の車両内通信手段１０からデータパケットを受信した場合、このデータパケットを代理サーバ装置３０へと送信する処理を実行し、逆に、代理サーバ装置３０から所定の端末装置宛のデータパケットを受信した場合に、このデータパケットを、それぞれ通信ポイントＰ１，Ｐ２，Ｐ３付近に到来した車両Ａ内に設置された車両内通信手段１０へと送信する処理を実行する。車両Ａが通信ポイントに到来するまでは、データパケットを保管することになる。
【００３５】
一方、代理サーバ装置３０は、インターネット４０に対して、個々の端末装置Ｔの代理としてアクセスを行う役割を果たす。具体的には、経路上通信手段２１，２２，２３からデータパケットを受信した場合には、これをインターネット４０を介して外部のサーバ装置５１〜５５へと送信する処理を実行し、逆に、外部のサーバ装置５１〜５５からインターネット４０を介してデータパケットを受信した場合には、これを経路上通信手段２１，２２，２３へと送信する処理を実行する。
【００３６】
ここで留意すべき点は、経路上通信手段２１，２２，２３側から送られてきたデータパケットをインターネット４０へと流す場合には、１つのデータパケットをそのまま１つのデータパケットとして流す処理を行うが、逆に、インターネット４０側から送られてきたデータパケットを経路上通信手段２１，２２，２３側へと流す場合には、データパケットの複製を作成し、１つのデータパケットを複数のデータパケットとして、複数の通信ポイントＰ１，Ｐ２，Ｐ３にそれぞれ設置された複数の経路上通信手段２１，２２，２３へと送信する処理を実行する点である。別言すれば、代理サーバ装置３０は、インターネット４０側から送信されてきたデータパケットを、すべての経路上通信手段２１，２２，２３に対してマルチキャストすることになる。
【００３７】
このようなマルチキャストが必要になる理由は、インターネット４０側から特定の端末装置Ｔ宛のデータパケットが代理サーバ装置３０へと送信されてきた時点では、宛先となる端末装置Ｔを載せている車両Ａが現在どこを走行中であり、次にどの通信ポイントでこのデータパケットを受信可能であるか、を正確に認識することが困難であるためである。もちろん、車両Ａが列車の場合、時刻表などを参照することにより、ある程度の精度で、どの経路上通信手段経由でデータパケットを引き渡せばよいかを予想することは可能であるが、現実的には、列車が必ずしも時刻表どおりの運行を行う保証はない。また、車両Ａが自動車の場合は、運行状況は著しく変動するため、車両の位置を認識することは極めて困難である。そこで、本発明では、位置が不確定である車両Ａ内の端末装置Ｔ宛にデータパケットを送信する際に、マルチキャストを行い、いずれの経路上通信手段２１，２２，２３からでもデータパケットの引き渡しを行えるようにしている。
【００３８】
なお、ここに示す実施形態では、運行経路Ｌ上のすべての経路上通信手段２１，２２，２３に対してマルチキャストを行う例を示すが、本発明を実施する上では、必ずしもすべての経路上通信手段に対してマルチキャストを行う必要はなく、インターネット４０を介して代理サーバ装置３０が受信したデータパケットは、当該データパケットの宛先となる端末装置が存在する車両が所定時間内に到来する可能性のある所定の地理的範囲内の複数の通信ポイントにそれぞれ設置された経路上通信手段へと送信する処理を実行するようにしてもかまわない。たとえば、列車の場合、上述したように、時刻表によって個々の車両の運行状況がある程度把握できるのであれば、特定の列車内の端末装置宛のデータパケットについては、当該列車が、たとえば３０分以内に到来する可能性のある所定の地理的範囲に存在する通信ポイントを調べ、このような一部の通信ポイントに設置された経路上通信手段に限って、データパケットのマルチキャストを行うようにしてもよい。また、自動車の場合であっても、たとえば、１時間前に東京の通信ポイントからデータパケットの送信があった車両であれば、現時点でも関東地区に存在することは物理的に明らかなので、マルチキャストの対象を関東地区の通信ポイントに限定してもかまわない。
【００３９】
＜＜＜ §２． 通信形態に関する工夫 ＞＞＞
以上、§１では、本発明の基本的な実施形態を述べたが、ここでは、本発明を実施する上で有用な通信形態に関するいくつかの工夫を述べておく。
【００４０】
図１に示す移動体パケット通信システム１００の目的は、車両Ａ内の端末装置Ｔと、外部のサーバ装置５１〜５５との間でパケット通信を行うことにある。ここで、端末装置Ｔは、車両Ａの乗客が所持する携帯電話などの汎用端末装置であるため、端末装置Ｔと車両内通信手段１０との間の通信は、ＩＰアドレスを利用した汎用プロトコルで行うのが好ましい。また、代理サーバ装置３０がインターネット４０を介して外部のサーバ装置５１〜５５と通信を行う場合にも、ＩＰアドレスを利用した汎用プロトコルが必要になる。ただ、車両内通信手段１０と経路上通信手段２１，２２，２３との間の通信や、経路上通信手段２１，２２，２３と代理サーバ装置３０との間の通信は、必ずしも汎用プロトコルで行う必要はなく、この移動体パケット通信システムによるサービスを提供する業者に固有の特殊プロトコルであってもかまわず、むしろ固有の特殊プロトコルを利用した方が効率的になる場合も少なくない。
【００４１】
このような観点から、ここで述べる実施形態では、次のような工夫を施している。まず、車両内通信手段１０には、ＤＨＣＰ（Dynamic Host Configuration Protocol）の機能をもたせ、この機能により車両Ａ内に存在する各端末装置Ｔに対してプライベートＩＰアドレスを付与できるようにしてある。一方、代理サーバ装置３０には、ＮＡＴ（Network Address Translator）の機能をもたせ、この機能によりプライベートＩＰアドレスとグローバルＩＰアドレスとの変換を行わせ、システム１００の内部ではプライベートＩＰアドレスを用いたパケット通信が行われ、外部のサーバ装置５１〜５５との間ではグローバルＩＰアドレスを用いたパケット通信が行われるようにしている。
【００４２】
また、上述したように、車両内通信手段１０、経路上通信手段２１，２２，２３、代理サーバ装置３０の範囲内の通信プロトコルは、固有の特殊プロトコルを採用することが可能であるので、ここに述べる実施形態では、この範囲内の通信については、データ圧縮を行う運用を行っている。すなわち、車両内通信手段１０には、車両Ａ内に存在する端末装置Ｔから受信したデータパケットに対してデータ圧縮を行う機能をもたせ、代理サーバ装置３０には、圧縮されたデータパケットを伸張する機能をもたせており、車両内通信手段１０から代理サーバ装置３０へと転送されるデータパケットが圧縮された状態になるようにしている。同様に、代理サーバ装置３０には、外部のサーバ装置５１〜５５から受信したデータパケットに対してデータ圧縮を行う機能をもたせ、車両内通信手段１０には、圧縮されたデータパケットを伸張する機能をもたせており、代理サーバ装置３０から車両内通信手段１０へと転送されるデータパケットが圧縮された状態になるようにしている。
【００４３】
車両内通信手段１０と経路上通信手段２１，２２，２３との間の通信は、常に実行可能となっているわけではなく、既に述べたとおり、車両Ａが通信ポイントＰ１，Ｐ２，Ｐ３において車外通信機能を実行可能になっている状態（たとえば、駅に停車している状態や、交差点に信号待ちで停車している状態など）に限定される。このため、車両内通信手段１０と経路上通信手段２１，２２，２３との間でのデータパケットの送受処理は、比較的短時間に完了する必要がある。データパケットに対してデータ圧縮を行っておくことは、この送受処理時間を短縮する上で効果的である。
【００４４】
図２は、上述したプライベートＩＰアドレスとグローバルＩＰアドレスとの変換処理と、データパケットの圧縮／伸張処理と、を組み込んだ実施形態を説明するブロック図である。ここでは、同一の車両Ａに乗車している５人の乗客が、それぞれ端末装置Ｔ１〜Ｔ５を用いて、本発明に係る移動体パケット通信システムを利用している状態が示されている。この場合、まず、車両内通信手段１０のＤＨＣＰ機能により、端末装置Ｔ１〜Ｔ５のそれぞれに対して、所定のプライベートＩＰアドレスが付与される。図示の例では、各端末装置Ｔ１〜Ｔ５に対して、それぞれ「10.0.1.1」〜「10.0.1.5」なるプライベートＩＰアドレスが付与されている。一方、外部のサーバ装置５１〜５５に対しては、それぞれ「1.1.1.1」〜「5.5.5.5」なるグローバルＩＰアドレスが付与されている。また、代理サーバ装置３０には、「1.0.0.99」なるグローバルＩＰアドレスが付与されている。
【００４５】
この例では、移動体パケット通信システム１００の内部の通信は、プライベートＩＰアドレスを用いて行うことができるが、インターネット４０に対するアクセスを行う際には、グローバルＩＰアドレスを用いる必要がある。そこで、代理サーバ装置３０のＮＡＴ機能により、プライベートＩＰアドレスとグローバルＩＰアドレスとの変換を行い、各端末装置Ｔ１〜Ｔ５から、外部のサーバ装置５１〜５５宛に送られるデータパケットの送信元アドレスは、代理サーバ装置３０において、すべて「1.0.0.99」なる共通のグローバルＩＰアドレスに変換される。したがって、外部のサーバ装置５１〜５５は、各端末装置Ｔ１〜Ｔ５から送信されてきたデータパケットに対する応答を、すべて「1.0.0.99」なるグローバルＩＰアドレスをもった代理サーバ装置３０宛に送ることになる。代理サーバ装置３０は、こうして送られてきたデータパケットが、どのプライベートＩＰアドレス宛のものであるかをポート番号を利用して認識することになる。このような認識方法も含めたＮＡＴ処理機能は既に公知の技術であるため、ここでは詳しい説明は省略する。
【００４６】
また、移動体パケット通信システム１００の内部では、データパケットは圧縮された状態で伝送される。たとえば、端末装置Ｔ１から外部のサーバ装置５１宛にデータパケットが送信された場合を考えよう。この場合、まず、車両内通信手段１０がこのデータパケットを受け取るが、この時点で、車両Ａが通信ポイントに到達していなかったとすると、前述したように、このデータパケットは車両内通信手段１０内に一時的に保管されることになる。もちろん、他の端末装置Ｔ２〜Ｔ５からもデータパケットが送信されていれば、これらのデータパケットがまとめて一時保管されることになる。このとき、車両内通信手段１０は、一時保管したデータパケットに対して所定のアルゴリズムに基づくデータ圧縮を行う。後に§３で述べる具体例のように、このデータ圧縮は、複数のデータパケットに対してまとめて行うようにするのが効率的である。車両Ａが通信ポイントに到着し、車外通信機能が実行可能になった時点で、圧縮されたデータパケットは、経路上通信手段２ｘ（２１，２２，２３のいずれか）へと送信される。前述したように、圧縮された状態でのデータパケットの送信は、通信時間の短縮に役立つことになる。経路上通信手段２ｘは、受信したデータパケットを圧縮状態のまま代理サーバ装置３０へと伝送する。この圧縮されたデータパケットは、代理サーバ装置３０において伸張された後、ＮＡＴ機能によるアドレス変換を受け、インターネット４０を介して外部のサーバ装置５１へと送信されることになる。
【００４７】
こうして送信されたデータパケットに応答して、外部のサーバ装置５１から端末装置Ｔ１宛にデータパケットが送信されると、まず、代理サーバ装置３０がこれを受信し、ＮＡＴ機能により、端末装置Ｔ１のプライベートＩＰアドレス宛のデータパケットにアドレス変換される。そして、この代理サーバ装置３０において、当該データパケットは所定のアルゴリズムに基づいてデータ圧縮された後、複数の経路上通信手段２１，２２，２３宛にマルチキャストされる。各経路上通信手段２１，２２，２３は、こうしてマルチキャストされたデータパケットを、圧縮された状態のまま保持し、通信ポイントＰ１，Ｐ２，Ｐ３に車両Ａが到来したら、車両内通信手段１０に対して圧縮状態のまま送信する。車両内通信手段１０は、受信したデータパケットを伸張した後、これを宛先となる端末装置Ｔ１へと送信する。
【００４８】
なお、代理サーバ装置３０における圧縮処理をより効率化するためには、代理サーバ装置３０にバッチ処理を実行させるようにすればよい。たとえば、インターネット４０側から代理サーバ装置３０にデータパケットが届いたら、しばらくの間、これらデータパケットを蓄積しておくようにし、個々の車両宛のデータパケットごとに、それぞれ別個のパケット群を構成し、構成した各パケット群ごとにそれぞれまとめてデータ圧縮し、経路上通信手段２１，２２，２３へとマルチキャストすればよい。たとえば、図２に示す例において、同一の車両Ａ内に存在する５つの端末装置Ｔ１〜Ｔ５宛のデータパケットが代理サーバ装置３０に届いた場合、この５つのデータパケットを、車両Ａ宛のデータパケット群としてひとまとめにし、このひとまとめのデータパケット群全体に対してデータ圧縮を行うようにする。そうすれば、このデータパケット群は、圧縮状態のまま車両Ａ内の車両内通信手段１０へと届けられた上で伸張が行われ、各端末装置Ｔ１〜Ｔ５宛のデータパケットに復元されることになる。
【００４９】
続いて、各経路上通信手段２１，２２，２３にマルチキャストされたデータパケットの取り扱いについて検討してみよう。たとえば、図１に示す例において、車両Ａ内の端末装置Ｔ宛のデータパケットは、前述したように、各経路上通信手段２１，２２，２３のそれぞれに送信（マルチキャスト）されることになる。ここで、実用上は、上述したように、代理サーバ装置３０において、個々の車両宛のデータパケットごとに、それぞれ別個のパケット群を構成して圧縮するのが好ましく、その場合は、各経路上通信手段２１，２２，２３のそれぞれには、たとえば車両Ａ宛のデータパケットをひとまとめにしたデータパケット群が送信されることになる。もちろん、運行経路Ｌ上を運行している車両は、車両Ａだけではなく、たとえば、車両Ｂ、車両Ｃといった他の車両も多数運行している。したがって、各経路上通信手段２１，２２，２３には、車両Ａ宛のデータパケット群、車両Ｂ宛のデータパケット群、車両Ｃ宛のデータパケット群、というように、多数のデータパケット群が集まることになる。
【００５０】
ここで、どの車両が、どの通信ポイントを通過するか、という事項は、必ずしも正確に予測できる事項ではないので、本実施形態では、各経路上通信手段２１，２２，２３は、何らかの車両が通信ポイントＰ１，Ｐ２，Ｐ３に到来した場合に、保管しているすべてのデータパケット群を到来した車両内の車両内通信手段１０に対して送信する処理を行うようにしている。また、１回の送信で確実に目的の車両にデータパケットが引き渡せる保証はないので、各経路上通信手段２１，２２，２３は、それぞれ各通信ポイントＰ１，Ｐ２，Ｐ３に車両が到来するたびに、代理サーバ装置３０から受信したデータパケットを、到来した車両に向けて（車両内に設置された車両内通信手段１０へ向けて）繰り返し送信する処理を実行するようにしている。
【００５１】
たとえば、図１に示す例において、通信ポイントＰ１からＰ２に向かって、車両ＡおよびＢが走行中の場合に、各経路上通信手段２１，２２，２３に車両Ｂ宛のデータパケット群と車両Ｃ宛のデータパケット群とが保管されていたとしよう。この場合、先行する車両Ａが通信ポイントＰ２（駅）に到着した時点で、経路上通信手段２２から車両Ａに対して、車両Ｂ宛のデータパケット群と車両Ｃ宛のデータパケット群とが送信されることになるが、これを受信した車両Ａの車両内通信手段１０は、いずれのデータパケット群も自己宛のものではないので、そのまま廃棄する処理を行う。続いて、後続の車両Ｂが通信ポイントＰ２（駅）に到着した時点で、同様に、経路上通信手段２２から車両Ｂに対して、車両Ｂ宛のデータパケット群と車両Ｃ宛のデータパケット群とが送信されることになる。これを受信した車両Ｂの車両内通信手段１０は、車両Ｂ宛のデータパケット群は自己宛のものであるため、そこに含まれている各データパケットを車両Ｂ内の各端末装置へと送信し、車両Ｃ宛のデータパケット群を廃棄する処理を行う。
【００５２】
このように、各経路上通信手段２１，２２，２３は、新たな車両がそれぞれ通信ポイントＰ１，Ｐ２，Ｐ３に到来するたびに、保管しているデータパケット群を繰り返し送信する処理を行うことになるが、代理サーバ装置３０からは順次新しいデータパケット群が送られてくるため、各経路上通信手段２１，２２，２３に保管されるデータパケット群は増加の一途を辿ることになる。そこで、実用上は、正しい宛先となる車両に引き渡しが完了したデータパケット群については、これを廃棄してゆく処理を行う必要がある。このような経路上通信手段２１，２２，２３におけるデータパケットの廃棄処理は、たとえば、次のようないくつかの方法により実施可能である。
【００５３】
まず、第１の方法は、車両内通信手段１０に、所定の経路上通信手段から自己車両宛のパケット群を受信したときに、当該パケット群の受領を確認する受領確認情報を当該所定の経路上通信手段に対して送信する処理を行う機能をもたせておき、各経路上通信手段には、いずれか１つの経路上通信手段が特定のパケット群についての受領確認情報を受信した場合に、この特定のパケット群と同一のパケット群を廃棄する処理を実行する機能をもたせておく方法である。この方法では、たとえば、図１に示す車両Ａ宛のデータパケット群は、３つの経路上通信手段２１，２２，２３にそれぞれブロードキャストされることになるが、車両Ａが通信ポイントＰ２に到来し、この車両Ａ宛のデータパケット群が車両Ａ内の車両内通信手段１０によって受信されると、この車両Ａ内の車両内通信手段１０から経路上通信手段２２に対して、受領確認情報が送信されることになる。経路上通信手段２２は、この受領確認情報の送信を受けて、車両Ａ宛の当該データパケット群の引き渡しが完了した旨を認識し、保管していた当該データパケット群を廃棄する処理を行う。同時に、経路上通信手段２２から、他の経路上通信手段２１，２３に対して、同一のデータパケット群を廃棄すべき旨の指示が送信されるようにし、経路上通信手段２１，２３においても、同一のデータパケット群の廃棄が行われる。かくして、目的の車両への送信が完了したデータパケットは、各経路上通信手段２１，２２，２３から順次廃棄されてゆくことになる。
【００５４】
第２の方法は、個々の車両からの受領確認情報の送信を省略することができる方法である。この方法では、各経路上通信手段２１，２２，２３が、それぞれの通信ポイントＰ１，Ｐ２，Ｐ３付近に車両が到来するたびに、保管しているデータパケットを、到来した車両内に設置された車両内通信手段１０へと毎回送信する処理を実行する点に変わりはないが、保管しているデータパケットのうち、代理サーバ装置３０から受信した後に所定の時間が経過したデータパケットについては、これを廃棄する処理を実行するようにする。ここで、所定の時間としては、各車両の運行状況を考慮した上で、いずれの車両に対しても、いずれかの経路上通信手段から、目的のデータパケットの送信が完了するであろうと予測される所定の時間を設定すればよい。
【００５５】
第３の方法も、個々の車両からの受領確認情報の送信を省略することができる方法である。この方法においても、各経路上通信手段２１，２２，２３が、それぞれの通信ポイントＰ１，Ｐ２，Ｐ３付近に車両が到来するたびに、保管しているデータパケットを、到来した車両内に設置された車両内通信手段１０へと毎回送信する処理を実行する点に変わりはないが、保管しているデータパケットのうち、送信繰り返し回数が所定回数に達したデータパケットについては、これを廃棄する処理を実行するようにする。たとえば、到来した車両に対する送信を３回繰り返したデータパケットについては廃棄するような設定を行っておけば、代理サーバ装置３０からの受信後に、到来した３台の車両に対する送信が行われると廃棄されることになる。廃棄までの送信繰り返し回数は、やはり各車両の運行状況を考慮した上で、いずれの車両に対しても、いずれかの経路上通信手段から、目的のデータパケットの送信が完了するであろうと予測される回数を設定すればよい。
【００５６】
以上述べた方法は、いずれも経路上通信手段２１，２２，２３にその時点で保管されているすべてのデータパケットを、到来した車両に対して無条件で送信する方法であるが、各経路上通信手段２１，２２，２３に、それぞれの通信ポイントＰ１，Ｐ２，Ｐ３付近に車両が到来するたびに、到来した車両を特定する処理を実行し、代理サーバ装置３０から受信したデータパケットのうち、特定された車両宛のデータパケットのみを選択し、この選択したデータパケットを到来した車両内に設置された車両内通信手段へと送信した後にこれを廃棄する処理を実行し、かつ、他の経路上通信手段によって車両への送信が完了したパケットと同一のパケットについては、これを廃棄する処理を実行する方法を採れば、より効率的な送信が可能になる。この方法によれば、各経路上通信手段２１，２２，２３に保管されているデータパケット群のうち、たとえば、車両Ａ宛のデータパケット群は、車両Ａに対してのみ送信され、車両Ｂ宛のデータパケット群は、車両Ｂに対してのみ送信されることになる。この方法を採る場合には、通信ポイントに車両が到来したら、まず、経路上通信手段と車両内通信手段との間で交信を行い、到来した車両を特定する処理を行い、更に、特定された車両宛のデータパケットのみを選択する処理が必要になるが、無駄なデータパケットの送信を抑制するメリットが得られる。
【００５７】
なお、本発明に係る移動体パケット通信システムを利用して、高速移動中の車両内から、端末装置Ｔを用いて外部のサーバ装置へとデータパケットを送信し、当該外部のサーバ装置からの応答をデータパケットとして受信するようなアクセスを行う場合、通常のアクセスに比べて長時間を要することも少なくない。
【００５８】
たとえば、外部のサーバ装置５１がメールサーバであり、端末装置Ｔから、このメールサーバにアクセスして、自己宛の電子メールを受信するような場合を考えてみよう。この場合、一般的なメール受信プロトコル「ＰＯＰ３」によれば、端末装置Ｔからメールサーバ５１宛に、「POPGET」なる命令をアカウント名やパスワードとともに送信することになる。メールサーバ５１は、これを受けて、当該アカウント宛のメールの内容を返信する処理を行う。ここで、端末装置Ｔから「POPGET」命令を送信した後、メールサーバ５１からメールの内容が返信されてくるまでの時間は、通常、数秒程度であり、端末装置Ｔに組み込まれている一般的な電子メールアプリケーションは、メール内容の返信が長時間得られなかった場合には、いわゆる「タイムアウト」と判断し、「メールの受信に失敗しました」などのメッセージを表示してエラー処理を行うようにプログラムされている。
【００５９】
また、外部のサーバ装置５３がファイルサーバであり、端末装置Ｔから、このファイルサーバにアクセスして、何らかのファイルをダウンロードする場合は、「ＦＴＰ」なるプロトコルを用いて、端末装置Ｔからファイルサーバ５３に対して所定のファイルのダウンロード命令を与え、目的のファイルを送信してもらうことになる。この場合も、端末装置Ｔからダウンロード命令を送信した後、ファイルサーバ５３からの返信が長時間得られなかった場合には、一般的なファイル転送用アプリケーションは、いわゆる「タイムアウト」と判断し、「ファイルのダウンロードに失敗しました」などのメッセージを表示してエラー処理を行うようにプログラムされている。
【００６０】
ところが、本発明に係る移動体パケット通信システムでは、車内の端末装置Ｔから外部のサーバ装置５１〜５５へ向けたデータパケットや、逆に、外部のサーバ装置５１〜５５から車内の端末装置Ｔに向けたデータパケットは、直ちに伝送されるわけではなく、車両が所定の通信ポイントへ到達するまで、車両内通信手段１０側や、経路上通信手段２１，２２，２３側に保管された状態になる。このため、端末装置Ｔに組み込まれている一般的な汎用アプリケーションソフトウエアを用いてデータパケットの送受信を行った場合、いわゆる「タイムアウト」との判断がなされてエラーが生じる可能性が高い。そこで、実用上は、本発明に係るシステムを利用した通信を行う際には、「タイムアウト」と判断すべき時間を長めに設定した専用のアプリケーションソフトウエアを用いるようにするのが好ましい。
【００６１】
あるいは、端末装置Ｔから外部のサーバ装置５１〜５５に対して、所定時間内の返信を要求するデータパケットの送信（別言すれば、「タイムアウト」との判断により、エラー処理が実行されるようなアプリケーションを用いたデータパケットの送信）が行われたときに、車両内通信手段１０が、外部のサーバ装置５１〜５５に代わって返信を行う代理返信機能を実行するような構成にしておくこともできる。このような代理返信機能を設けておけば、端末装置Ｔから外部のサーバ装置５１〜５５に対して、汎用のアプリケーションを用いたアクセスが行われた場合でも、「タイムアウト」によるエラー発生を防ぐことができる。
【００６２】
たとえば、端末装置Ｔからメールサーバ５１宛に「POPGET」なる電子メールの受信命令が送信された場合、とりあえず、車両内通信手段１０の代理返信機能によって、この命令に対する疑似的な返信を端末装置Ｔ宛に返すようにする。具体的には、たとえば、「No Mail」なる擬似的な返信を返せばよい。端末装置Ｔ内の電子メールアプリケーションは、このような返信を、メールサーバ５１からの返信であるものとして取り扱い、たとえば、「現在、受信すべき電子メールは１つもありません。」のようなメッセージを表示するような処理を実行することになる。もちろん、この時点では、「POPGET」なる電子メールの受信命令は、まだ、同じ車両内の車両内通信手段１０に一時的に保管された状態となっており、メールサーバ５１には届いていない。
【００６３】
やがて、この車両がいずれかの通信ポイント（駅）へ到着すると、「POPGET」なる電子メールの受信命令は、経路上通信手段を介してメールサーバ５１へと送信され、やがて、これに対するメールサーバ５１からの正規の返信が戻ってくることになる。この返信は、早ければ、この車両が同じ駅に停車している最中に、車両内通信手段１０まで戻ってくるかもしれない。この車両がこの駅を発車した後に返信が戻ってきた場合には、当該返信は、その次の駅において、車両内通信手段１０まで届くことになる。いずれにせよ、メールサーバ５１からの正規の返信が、車両内通信手段１０へと届くことになる。こうして、車両内通信手段１０に正規の返信が届いた場合、車両内通信手段１０はその時点では、まだ端末装置Ｔに対して、当該正規の返信を送信せずに保管したままにする。これは、端末装置Ｔからの電子メールの受信命令に対しては、既に、「No Mail」なる擬似的な返信を送信してしまっており、端末装置Ｔ側の電子メールアプリケーションによる処理が完了してしまっているからである。ただし、後に、同じ端末装置Ｔの同じ電子メールアプリケーションから、再び、メールサーバ５１宛の「POPGET」なる電子メールの受信命令が送信された場合には、車両内通信手段１０は、当該命令を外部へと送信することなしに、既にメールサーバ５１からの正規の返信として得られているメールの内容を、そのまま端末装置Ｔへと送信する処理を実施するようにすればよい。
【００６４】
このように、端末装置Ｔから返信要求をともなう何らかの命令が送信された場合に、車両内通信手段１０側に、あたかも外部のサーバ装置からの返信であるかのように、所定の返信内容を端末装置Ｔへと送信する代理返信機能を設けておけば、端末装置Ｔ側のアプリケーションに「タイムアウト」のエラーを発生させることなしに、適切な処理を実行させることが可能になる。
【００６５】
＜＜＜ §３． 具体的な通信手順 ＞＞＞
最後に本発明に係る移動体パケット通信システムを用いたデータパケットの具体的な通信手順の一例を示しておく。いま、車両Ａ内に乗車している５人の乗客が、図２に示すようにそれぞれ端末装置Ｔ１〜Ｔ５を用いて、外部のサーバ装置５１〜５５へ、電子メールの受信命令もしくはファイルのダウンロード命令を送信したいと考えたとしよう。前述したように、各端末装置Ｔ１〜Ｔ５には、車両内通信手段１０のＤＨＣＰ機能により、それぞれ図２に示すようなプライベートＩＰアドレスが付与される。ここでは、各端末装置Ｔ１〜Ｔ５のアプリケーションソフトウエアによって、それぞれ図３に示すような５つのデータパケットＤＰ１０〜ＤＰ５０が作成されたものとしよう。この図３において、一重枠で示すデータパケットＤＰ１０，ＤＰ２０，ＤＰ５０は、いずれも電子メールの受信命令を含むデータパケットであり、二重枠で示すデータパケットＤＰ３０，ＤＰ４０は、いずれもファイルのダウンロード命令を含むデータパケットである。
【００６６】
たとえば、図３に示すデータパケットＤＰ１０の１行目の「Dst Addr: 1.1.1.1」なるデータは、送信先のＩＰアドレスが「1.1.1.1」（図２に示すように、メールサーバ５１のグローバルＩＰアドレス）であることを示し、２行目の「Src Addr: 10.0.1.1」なるデータは、送信元のＩＰアドレスが「10.0.1.1」（図２に示すように、端末装置Ｔ１のプライベートＩＰアドレス）であることを示し、３行目の「Dst Port#: 110」なるデータは、送信先となる外部のサーバ装置５１のポート番号が「110」（電子メール用アプリケーションを特定する番号）であることを示し、４〜５行目の「データ：POPGET ACC1/PASS1」は、送信対象となるデータの内容が、「POPGET」なる命令（電子メール用アプリケーションに対して、電子メールの受信を要求する命令）と、アカウント名「ACC1」およびパスワード「PASS1」であることを示す。データパケットＤＰ２０（メールサーバ５２宛）やデータパケットＤＰ５０（メールサーバ５５宛）の内容もほぼ同様である。
【００６７】
一方、図３に示すデータパケットＤＰ３０の１行目の「Dst Addr: 3.3.3.3」なるデータは、送信先のＩＰアドレスが「3.3.3.3」（図２に示すように、ファイルサーバ５３のグローバルＩＰアドレス）であることを示し、２行目の「Src Addr: 10.0.1.3」なるデータは、送信元のＩＰアドレスが「10.0.1.3」（図２に示すように、端末装置Ｔ３のプライベートＩＰアドレス）であることを示し、３行目の「Dst Port#: 23」なるデータは、送信先となる外部のサーバ装置５３のポート番号が「23」（ファイルのダウンロード用アプリケーションを特定する番号）であることを示し、４〜５行目の「データ：ACC3/PASS3 FTP_Command」は、送信対象となるデータの内容が、「FTP_Command」なる命令（ファイルのダウンロード用アプリケーションに対して、ダウンロードを要求する命令）と、アカウント名「ACC3」およびパスワード「PASS3」であることを示す。データパケットＤＰ４０（メールサーバ５４宛）の内容もほぼ同様である。なお、この図３は、便宜上、本発明に係るシステムの通信手順の説明に必要なデータを示すものであり、実際に送信されるデータパケットの内容をそのまま示すものではない。
【００６８】
さて、各端末装置Ｔ１〜Ｔ５から、図３に示すようなデータパケットＤＰ１０〜ＤＰ５０が送信されると、車両内通信手段１０は、これらのデータパケットを一時的に保管することになる。このとき、車両内通信手段１０内では、これら各データパケットの内容に基づいて、図４に示すような対応表ＴＢ１を作成するとともに、図５に示すような圧縮データDATA1およびDATA2を作成する処理が実行される。ここで、図４に示す対応表ＴＢ１は、後にデータの伸張処理を行うときに必要なデータをテーブルにしたものであり、図３に示す各データパケットＤＰ１０〜ＤＰ５０にそれぞれシリアル番号（図示の例では、Seq#:12345〜Seq#:12349）を付与し、送信先のグローバルＩＰアドレス「Dst:」と、送信元のプライベートＩＰアドレス「Src:」と、送信先のポート番号「Dst Port#」とを抜き出し、更に、返信が得られるまでのタイムアウト時間「TTL:」を設定したものである。
【００６９】
一方、図５に一重枠で示す圧縮データDATA1は、電子メールの受信命令を含むデータパケットＤＰ１０，ＤＰ２０，ＤＰ５０の内容をまとめたものであり、二重枠で示す圧縮データDATA2は、ファイルのダウンロード命令を含むデータパケットＤＰ３０，ＤＰ４０の内容をまとめたものである。DATA1の上欄１行目の「車両ID:A」なるデータは、この圧縮データが車両Ａから送信されるデータパケット群であることを示し、２行目の「Sequence#:0001」なるデータは、この圧縮データのシリアル番号が「0001」であることを示し、３行目の「Dst Port#: 110」なるデータは、この圧縮データの送信先のポート番号が「110」であることを示している。また、DATA1の下欄１行目の「Seq#: 12345」なるデータは、以下のデータが対応表ＴＢ１における「Seq#: 12345」に対応したデータ、すなわち、データパケットＤＰ１０内のデータであることを示す指標であり、２行目および３行目の「Dst: 1.1.1.1」および「ACC1/PASS1」なるデータは、このデータパケットＤＰ１０内の「Dst Addr: 1.1.1.1」および「ACC1/PASS1」を抜き出したものである。
【００７０】
なお、ここに示す例では、データパケットＤＰ１０内の「POPGET」なる命令は、圧縮データDATA1内では省略している。これは、「Dst Port#: 110」なるポート番号に関連したデータ（電子メール用アプリケーションに対する命令であることを示すデータ）には、必ず「POPGET」なる命令が伴うことになっているため、圧縮データDATA1内にわざわざ「POPGET」なる命令を入れておく必要がないためである。同様に、DATA1の下欄４〜６行目には、データパケットＤＰ２０内の必要なデータが抜き出され、下欄７〜９行目には、データパケットＤＰ５０内の必要なデータが抜き出されている。
【００７１】
また、図５に二重枠で示す圧縮データDATA2の上欄１行目の「車両ID:A」なるデータは、この圧縮データが車両Ａから送信されるデータパケット群であることを示し、２行目の「Sequence#:0002」なるデータは、この圧縮データのシリアル番号が「0002」であることを示し、３行目の「Dst Port#: 23」なるデータは、この圧縮データの送信先のポート番号が「23」であることを示している。また、DATA2の下欄１行目の「Seq#: 12347」なるデータは、以下のデータが対応表ＴＢ１における「Seq#: 12347」に対応したデータ、すなわち、データパケットＤＰ３０内のデータであることを示す指標であり、２行目〜４行目の「Dst: 3.3.3.3」，「ACC3/PASS3」，「FTP_Command」なるデータは、このデータパケットＤＰ３０内の「Dst Addr: 3.3.3.3」，「ACC3/PASS3」，「FTP_Command」を抜き出したものである。同様に、DATA2の下欄５〜８行目には、データパケットＤＰ４０内の必要なデータが抜き出されている。
【００７２】
結局、図５に示す圧縮データDATA1，DATA2は、図３に示すデータパケットＤＰ１０〜ＤＰ５０内の必要なデータのみを抜き出したものになっており、データパケットＤＰ１０〜ＤＰ５０をそのまま送信する代わりに、圧縮データDATA1，DATA2を送信すれば、送信容量を低減させることができる。
【００７３】
この図５に示す圧縮データDATA1，DATA2は、車両が通信ポイントＰ１、Ｐ２またはＰ３に到着した時点で経路上通信手段２１、２２または２３へと送信され、代理サーバ装置３０へと伝送される。このような圧縮データDATA1，DATA2を受信した代理サーバ装置３０内では、これら各圧縮データDATA1，DATA2の内容に基づいて、図６に示すような対応表ＴＢ２を作成するとともに、伸張処理により、図７に示すようなデータパケットＤＰ１１〜ＤＰ５１を作成する処理が実行される。ここで、図６に示す対応表ＴＢ２は、ＮＡＴ処理に必要なデータをテーブルにしたものであり、図５に示す各情報に、送信元のポート番号を付加することにより得られるものである。たとえば、この図６の対応表ＴＢ２の左欄１行目の「Src Port#: xx1」は、以下のデータが、「xx1」なる送信元ポート番号に関連するデータであることを示しており、２行目の「車両ID: A」なるデータは、車両Ａから送信されるデータパケットに関するデータであることを示し、３〜４行目の「Sequence#:0001」および「Seq#: 12345」なるデータは、関連するシリアル番号を示し、５行目の「Dst: 1.1.1.1」なるデータは、送信先のグローバルＩＰアドレスが「1.1.1.1」であることを示している。以下、同様である。
【００７４】
一方、図７に示すデータパケットＤＰ１１〜ＤＰ５１は、図５に示す圧縮データDATA1，DATA2および図６に示す対応表ＴＢ２のポート番号に基づいて作成することができる。この図７に示す伸張処理後のデータパケットＤＰ１１〜ＤＰ５１の内容は、図３に示す圧縮処理前のデータパケットＤＰ１０〜ＤＰ５０の内容とほぼ同様であるが、送信元のアドレスが、プライベートＩＰアドレスからグローバルＩＰアドレスに変更されている点と、送信元のポート番号が付加されている点が異なっている。これは、代理サーバ装置３０におけるＮＡＴ処理の結果である。たとえば、図３のデータパケットＤＰ１０では、送信元のアドレスとして「Src Addr: 10.0.1.1」なるプライベートＩＰアドレスが記載されていたが、図７のデータパケットＤＰ１１では、送信元のアドレスとして「Src Addr: 1.0.0.99」なるグローバルＩＰアドレス（代理サーバ装置３０自身のアドレス）が記載されている。このように、代理サーバ装置３０のＮＡＴ機能により、データパケットＤＰ１１〜ＤＰ５１の送信元のアドレスは、すべて「Addr: 1.0.0.99」なる代理サーバ装置３０自身のグローバルＩＰアドレスに変更されることになる。なお、この図７においても、一重枠のデータパケットＤＰ１１，ＤＰ２１，ＤＰ５１は、メールサーバに宛てた電子メールの受信命令を含むデータパケットであり、二重枠のデータパケットＤＰ３１，ＤＰ４１は、ファイルサーバに宛てたダウンロード命令を含むデータパケットである。
【００７５】
このように、代理サーバ装置３０のＮＡＴ機能により、端末装置Ｔ１〜Ｔ５のアドレスはすべて「Addr: 1.0.0.99」なる代理サーバ装置３０自身のアドレスに変更されてしまう。そこで、送信元のポート番号を利用して、送信元の端末装置Ｔ１〜Ｔ５を識別する必要がある。図７に示すデータパケットＤＰ１１〜ＤＰ５１の４行目に記載された「Src Port#:xx1〜xx5」は、このようなポート番号を示すものである。
【００７６】
かくして、外部のサーバ装置５１〜５５には、それぞれ図７に示すようなデータパケットＤＰ１１〜ＤＰ５１が届けられることになる。これに応じて、外部のサーバ装置５１〜５５からは、図８に示すようなデータパケットＤＰ１２〜ＤＰ５２が返信される。ここで、一重枠のデータパケットＤＰ１２，ＤＰ２２，ＤＰ５２は、各メールサーバからのメールの内容を示すデータを含んだ返信であり、二重枠のデータパケットＤＰ３２，ＤＰ４２は、ファイルサーバからのダウンロード対象ファイルの内容を示すデータを含んだ返信である。たとえば、データパケットＤＰ１２の１行目の「Dst Addr: 1.0.0.99」なるデータは、送信先のＩＰアドレスが「1.0.0.99」（代理サーバ装置３０のグローバルＩＰアドレス）であることを示し、２行目の「Src Addr: 1.1.1.1」なるデータは、送信元のＩＰアドレスが「1.1.1.1」（外部のサーバ装置５１のグローバルＩＰアドレス）であることを示している。これは、図７に示すデータパケットＤＰ１１の送信先と送信元のアドレスを入れ替えたものに他ならない。また、３行目の「Dst Port#: xx1」なるデータは、送信先となる代理サーバ装置３０のポート番号が「xx1」であることを示し、４行目の「Src Port#: 110」なるデータは、送信元となる外部のサーバ装置５１のポート番号が「110」であることを示している。これは、図７に示すデータパケットＤＰ１１の送信先と送信元のポート番号を入れ替えたものに他ならない。更に、５行目の「データ：（メールの内容１）」なるデータは、返信対象となる電子メールの内容を示すデータである。他のデータパケットＤＰ２２〜ＤＰ５２の構成もほぼ同様である。
【００７７】
さて、図８に示すデータパケットＤＰ１２〜ＤＰ５２を受け取った代理サーバ装置３０は、その中の「Dst Port#:」の部分と、図６に示す対応表ＴＢ２中の「Src Port#:」の部分とを対応させることにより、これらが同一の車両Ａ宛のデータパケットであることを認識することができる。もちろん、データパケットＤＰ１２〜ＤＰ５２は、通常、代理サーバ装置３０に対して互いに時間差をもって到着することになるので、代理サーバ装置３０は、到着するデータパケットを一時的に蓄積しておき、ある程度集まった時点で、同一車両宛のデータパケットを集めたデータパケット群を作成し、このデータパケット群をまとめて圧縮する処理を行う。たとえば、図８に示すデータパケットＤＰ１２〜ＤＰ５２がすべて集まったとすると、代理サーバ装置３０は、図６の対応表ＴＢ２を参照しながら、図９に示すような圧縮データDATA3およびDATA4を作成する。
【００７８】
図９に一重枠で示す圧縮データDATA3は、電子メールの受信命令に対する返信情報を含むデータパケットＤＰ１２，ＤＰ２２，ＤＰ５２の内容をまとめたものであり、二重枠で示す圧縮データDATA4は、ファイルのダウンロード命令に対する返信情報を含むデータパケットＤＰ３２，ＤＰ４２の内容をまとめたものである。DATA3の上欄１行目の「車両ID:A」なるデータは、この圧縮データが車両Ａ宛のデータパケット群であることを示し、２行目の「Sequence#:0001」なるデータは、この圧縮データのシリアル番号が「0001」であることを示している。これらのデータは、図６の対応表ＴＢ２を参照することにより得ることができる。また、３行目の「Src Port#: 110」なるデータは、この圧縮データの送信元のポート番号が「110」であることを示しており、データパケットＤＰ１２，ＤＰ２２，ＤＰ５２内の「Src Port#」の情報から得ることができる。DATA3の下欄１行目の「Seq#: 12345」なるデータおよび２行目の「（メールの内容１）」なるデータは、シリアル番号「12345」の返信データが「（メールの内容１）」であることを示す情報であり、以下、シリアル番号「12346」、「12349」についての同様の情報が続くことになる。これらの情報は、図６の対応表ＴＢ２の内容とデータパケットＤＰ１２，ＤＰ２２，ＤＰ５２の内容に基づいて得ることができる。一方、図９に二重枠で示す圧縮データDATA4の構造もほぼ同様である。
【００７９】
こうして、代理サーバ装置３０において作成された圧縮データDATA3、DATA4は、マルチキャストにより、経路上通信手段２１，２２，２３へと送信され、通信ポイントＰ１，Ｐ２，Ｐ３に到来した車両に圧縮状態のまま送信されることになる。これら圧縮データDATA3、DATA4を受信した車両内の車両内通信手段１０は、「車両ＩＤ」の部分を確認し、それが自己宛のデータパケットであるかを認識する。自己宛でなかった場合には、これをそのまま廃棄することになる。自己宛であった場合、すなわち、図９に示す圧縮データDATA3、DATA4を車両Ａが受信した場合は、データパケットの送信時に作成しておいた図４に示す対応表ＴＢ１を参照することにより、これらを伸張する処理を行う。
【００８０】
たとえば、圧縮データDATA3には、シリアル番号「12345」の返信データが「（メールの内容１）」であることを示す情報が含まれているが、対応表ＴＢ１には、シリアル番号「12345」について、送信先アドレス「Dst: 1.1.1.1」、送信元アドレス「Src: 10.0.1.1」が記載されているので、これらのアドレスの送受信を入れ替えることにより、図１０に示すようなデータパケットＤＰ１３を生成することができる。同様の伸張処理により、結局、図１０に示すデータパケットＤＰ１３〜ＤＰ５３が生成され、これらが端末装置Ｔ１〜Ｔ５へと送信されることになる。かくして、各端末装置Ｔ１〜Ｔ５から外部のサーバ装置５１〜５５へと送信されたデータパケットに対して、それぞれ返信となるデータパケットが届くことになる。
【００８１】
以上、本発明を図示する実施形態に基づいて説明したが、本発明はこれらの実施形態に限定されるものではなく、この他にも種々の形態で実施可能である。特に、図３〜図１０に示した実施形態は、あくまでも具体的な実施例の一形態を示すものであり、実際の圧縮方法やデータフォーマットなどは、任意のものを採用してかまわない。
【００８２】
【発明の効果】
以上のとおり、本発明に係る移動体パケット通信システムによれば、高速移動中の車両に搭乗していながら、大容量のデータパケット通信が可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る移動体パケット通信システム１００の基本構成を示すブロック図である。
【図２】プライベートＩＰアドレスとグローバルＩＰアドレスとの変換処理およびデータパケットの圧縮／伸張処理を組み込んだ本発明の実施形態を説明するブロック図である。
【図３】図２に示す端末装置Ｔ１〜Ｔ５で作成されたデータパケットＤＰ１０〜ＤＰ５０の一例を示す図である。
【図４】車両内通信手段１０において、図３に示すデータパケットＤＰ１０〜ＤＰ５０に基づいて作成された対応表ＴＢ１を示す図である。
【図５】車両内通信手段１０において、図３に示すデータパケットＤＰ１０〜ＤＰ５０の情報をデータ圧縮することにより作成された圧縮データDATA1およびDATA2の内容を示す図である。
【図６】代理サーバ装置３０において、図５に示す圧縮データDATA1およびDATA2に基づいて作成された対応表ＴＢ２を示す図である。
【図７】代理サーバ装置３０において、図５に示す圧縮データDATA1およびDATA2を伸張することにより得られるデータパケットＤＰ１１〜ＤＰ５１を示す図である。
【図８】図７に示すデータパケットＤＰ１１〜ＤＰ５１を受信した外部のサーバ装置５１〜５５が、それぞれ返信情報として送信するデータパケットＤＰ１２〜ＤＰ５２を示す図である。
【図９】代理サーバ装置３０において、図８に示すデータパケットＤＰ１２〜ＤＰ５２の情報をデータ圧縮することにより作成された圧縮データDATA3およびDATA4の内容を示す図である。
【図１０】車両内通信手段１０において、図９に示す圧縮データDATA3およびDATA4を伸張することにより得られるデータパケットＤＰ１３〜ＤＰ５３を示す図である。
【符号の説明】
１０…車両内通信手段
２１，２２，２３，２ｘ…経路上通信手段
３０…代理サーバ装置
４０…インターネット
５１〜５５…外部のサーバ装置
１００…移動体パケット通信システム
Ａ…車両
DATA1〜DATA4…圧縮データ
ＤＰ１０〜ＤＰ５０，ＤＰ１１〜ＤＰ５１，ＤＰ１２〜ＤＰ５２，ＤＰ１３〜ＤＰ５３…データパケット
Ｌ…運行経路
Ｐ１〜Ｐ３…通信ポイント
Ｔ，Ｔ１〜Ｔ５…端末装置
ＴＢ１，ＴＢ２…対応表
【発明の属する技術分野】
本発明は、移動体パケット通信システムに関し、特に、列車や自動車など、高速移動中の車両内に存在する端末装置と外部のサーバ装置との間でパケット通信を行うためのシステムに関する。
【０００２】
【従来の技術】
近年、携帯電話、ＰＤＡ装置、ノート型パソコンなど、移動体通信の端末装置として機能する様々な電子機器が普及し始めており、インターネットの普及と相まって、外部のサーバ装置との間でパケット通信が盛んに行われている。また、街頭では、様々な施設に無線ＬＡＮの設置が試みられており、移動体通信用の端末装置をＴＣＰ／ＩＰのプロトコルでインターネットへ接続する環境も構築されつつある。
【０００３】
【発明が解決しようとする課題】
現在普及している携帯電話は、列車や自動車などに乗車して移動中の状態であっても、ローミングなどの技術を用いることにより通信が可能である。したがって、移動中の車両においても、携帯電話などの端末装置によって会話を行ったり、外部のサーバ装置などに接続してデータパケットをやりとりしたりすることは可能である。しかしながら、現在、高速移動中の端末装置に対するパケット通信の通信速度は著しく低く制限されており、大量のデータのやりとりを行うには不適当である。これは、高速移動中の端末装置に対する無線による通信速度を向上させることが、現時点では、技術的に非常に困難であることに起因している。このため、車両に乗車している間に、画像データなどの大容量データが添付された電子メールを受信したり、外部のサーバ装置から大容量のデータをダウンロードしたりするには、極めて長い時間が必要になり、実用上、大容量データパケットの通信は、高速移動中の車両からはできなかった。
【０００４】
そこで本発明は、高速移動中の車両に搭乗していながら、大容量のデータパケット通信が可能になる移動体パケット通信システムを提供することを目的とする。
【０００５】
【課題を解決するための手段】
【０００６】
(1) 本発明の第１の態様は、車両とともに移動中の端末装置と外部のサーバ装置との間でパケット通信を行うための移動体パケット通信システムにおいて、
車両内に設置された車両内通信手段と、
車両が停車するか、または、通常の運行速度よりも低い速度で通過することが予定されている運行経路上の複数の通信ポイントにそれぞれ設置された複数の経路上通信手段と、
これら経路上通信手段に対して接続され、外部のサーバ装置との間でネットワークを介してデータパケットのやりとりを行う機能をもった代理サーバ装置と、
を設け、
車両内通信手段は、車両内に存在する端末装置との間で無線によりデータパケットの送受信を行う車内通信機能と、車両が通信ポイント付近に停車している状態、もしくは、車両が通信ポイント付近を通常の運行速度よりも低い速度で通過している状態において、当該通信ポイントに設置された経路上通信手段との間で無線によりデータパケットの送受信を行う車外通信機能と、を有し、車内通信機能により端末装置からデータパケットを受信した場合に、このデータパケットを車外通信機能が実行可能になるまで一時的に保管し、車外通信機能が実行可能になったときに、一時的に保管していたデータパケットを経路上通信手段へと送信する処理を実行し、経路上通信手段からデータパケットを受信した場合に、このデータパケットを車内通信機能により宛先となる端末装置へ送信する処理を実行するようにし、
経路上通信手段は、車両内通信手段からデータパケットを受信した場合に、このデータパケットを代理サーバ装置へと送信する処理を実行し、代理サーバ装置から所定の端末装置宛のデータパケットを受信した場合に、このデータパケットを、自己が設置された通信ポイント付近に到来した車両内に設置された車両内通信手段へと送信する処理を実行するようにし、
代理サーバ装置は、経路上通信手段から受信したデータパケットをネットワークを介して外部のサーバ装置へと送信する処理を実行するとともに、外部のサーバ装置からネットワークを介して受信したデータパケットを、複数の通信ポイントにそれぞれ設置された複数の経路上通信手段へと送信する処理を実行するようにし、
車両内通信手段に、車両内に存在する端末装置から受信したデータパケットに対してデータ圧縮を行う機能をもたせ、代理サーバ装置に、圧縮されたデータパケットを伸張する機能をもたせ、車両内通信手段から代理サーバ装置へと転送されるデータパケットが圧縮された状態になるようにし、
代理サーバ装置に、外部のサーバ装置から受信したデータパケットに対してデータ圧縮を行う機能をもたせ、車両内通信手段に、圧縮されたデータパケットを伸張する機能をもたせ、代理サーバ装置から車両内通信手段へと転送されるデータパケットが圧縮された状態になるようにし、
車両内通信手段に、更に、端末装置から外部のサーバ装置に対して、所定時間内の返信を要求するデータパケットの送信が行われたときには、外部のサーバ装置に代わって返信を行う代理返信機能をもたせるようにしたものである。
【０００７】
(2) 本発明の第２の態様は、上述の第１の態様に係る移動体パケット通信システムにおいて、
所定の路線に沿って走行する列車の車両内に車両内通信手段を設置し、この路線上の駅に通信ポイントを定義して経路上通信手段を設置するようにしたものである。
【０００８】
(3) 本発明の第３の態様は、上述の第１の態様に係る移動体パケット通信システムにおいて、
所定の道路上を走行する自動車の車両内に車両内通信手段を設置し、この道路上の交差点、料金所、もしくはパーキングエリアに通信ポイントを定義して経路上通信手段を設置するようにしたものである。
【０００９】
(4) 本発明の第４の態様は、上述の第１〜第３の態様に係る移動体パケット通信システムにおいて、
車両内通信手段にＤＨＣＰの機能をもたせ、この機能により車両内に存在する端末装置に対してプライベートＩＰアドレスを付与し、代理サーバ装置にＮＡＴの機能をもたせ、この機能によりプライベートＩＰアドレスとグローバルＩＰアドレスとの変換を行わせ、システム内部ではプライベートＩＰアドレスを用いたパケット通信が行われ、外部のサーバ装置との間ではグローバルＩＰアドレスを用いたパケット通信が行われるようにしたものである。
【００１１】
(5) 本発明の第５の態様は、上述の第１〜第４の態様に係る移動体パケット通信システムにおいて、
代理サーバ装置が、外部のサーバ装置からネットワークを介して受信したデータパケットを、当該データパケットの宛先となる端末装置が存在する車両が所定時間内に到来する可能性のある所定の地理的範囲内の複数の通信ポイントにそれぞれ設置された経路上通信手段へと送信する処理を実行するようにしたものである。
【００１２】
(6) 本発明の第６の態様は、上述の第１〜第５の態様に係る移動体パケット通信システムにおいて、
代理サーバ装置が、個々の車両宛のデータパケットごとに、それぞれ別個のパケット群を構成し、構成した各パケット群のそれぞれを複数の経路上通信手段へと送信する処理を行い、
車両内通信手段が、所定の経路上通信手段から自己車両宛のパケット群を受信したときに、当該パケット群の受領を確認する受領確認情報を、パケット群を受信した所定の経路上通信手段に対して送信する処理を行い、
各経路上通信手段が、代理サーバ装置から受信したデータパケットを、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両内に設置された車両内通信手段へと繰り返し送信する処理を実行し、かつ、いずれか１つの経路上通信手段が特定のパケット群についての受領確認情報を受信した場合に、この特定のパケット群と同一のパケット群を廃棄する処理を実行するようにしたものである。
【００１３】
(7) 本発明の第７の態様は、上述の第１〜第５の態様に係る移動体パケット通信システムにおいて、
各経路上通信手段が、代理サーバ装置から受信したデータパケットを、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両内に設置された車両内通信手段へと繰り返し送信する処理を実行し、かつ、代理サーバ装置から受信した後に所定の時間が経過したデータパケットについては、これを廃棄する処理を実行するようにしたものである。
【００１４】
(8) 本発明の第８の態様は、上述の第１〜第５の態様に係る移動体パケット通信システムにおいて、
各経路上通信手段が、代理サーバ装置から受信したデータパケットを、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両内に設置された車両内通信手段へと繰り返し送信する処理を実行し、かつ、送信繰り返し回数が所定回数に達したデータパケットについては、これを廃棄する処理を実行するようにしたものである。
【００１５】
(9) 本発明の第９の態様は、上述の第１〜第５の態様に係る移動体パケット通信システムにおいて、
各経路上通信手段が、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両を特定する処理を実行し、代理サーバ装置から受信したデータパケットのうち、特定された車両宛のデータパケットのみを選択し、この選択したデータパケットを到来した車両内に設置された車両内通信手段へと送信した後にこれを廃棄する処理を実行し、かつ、他の経路上通信手段によって車両への送信が完了したパケットと同一のパケットについては、これを廃棄する処理を実行するようにしたものである。
【００１６】
(10) 本発明の第１０の態様は、上述の第１〜第９の態様に係る移動体パケット通信システムにおいて、
車両内通信手段が、
端末装置から外部のメールサーバ装置に対して、電子メールの第１の受信命令が送信された場合に、車外通信機能が実行可能になるまで第１の受信命令を一時的に保管するとともに、メールサーバ装置に代わって、端末装置に対して受信すべき電子メールがないことを示す疑似的な返信を行い、
車外通信機能が実行可能になったときに、保管していた第１の受信命令をメールサーバ装置へと送信する処理を実行し、メールサーバ装置から第１の受信命令に応じて正規の返信が戻ってきた場合に、この正規の返信を一時的に保管し、
端末装置からメールサーバ装置に対して、電子メールの第２の受信命令が送信された場合に、第１の受信命令に応じて戻ってきた正規の返信が保管されていたら、第２の受信命令をメールサーバ装置へと送信することなしに、端末装置に対して、保管されていた正規の返信を第２の受信命令に対するメールサーバ装置からの返信であるかのように送信する代理返信機能を有するようにしたものである。
【００１７】
【発明の実施の形態】
以下、本発明を図示する実施形態に基づいて説明する。
【００１８】
＜＜＜ §１． 基本的な実施形態 ＞＞＞
図１は、本発明の一実施形態に係る移動体パケット通信システム１００の基本構成を示すブロック図である。この移動体パケット通信システム１００は、図に一点鎖線で囲って示した各構成要素によって構成され、図示のとおり、車両内通信手段１０と、経路上通信手段２１，２２，２３と、代理サーバ装置３０と、によって構成されている。この移動体パケット通信システム１００の役割は、所定の運行経路Ｌに沿って車両Ａとともに移動中の端末装置Ｔと、インターネット４０を介して接続されている外部のサーバ装置５１〜５５との間でパケット通信を行うことである。なお、図１において、運行経路Ｌ、車両Ａ、端末装置Ｔ自身は、この移動体パケット通信システム１００の構成要素ではないが、説明の便宜上、一点鎖線で囲った内部の構成要素として図示してある。
【００１９】
ここで車両Ａは、所定の運行経路Ｌに沿って移動するものであれば、どのようなものであってもかまわないが、実用上は、所定の路線に沿って走行する列車の車両か、あるいは、所定の道路上を走行する自動車の車両ということになろう。また、端末装置Ｔは、このような列車の車両や自動車の車両に搭乗した者が所持している携帯電話、ＰＤＡ装置、ノート型パソコンなどの移動式端末装置ということになる。なお、図１では、１両の車両Ａ内に１台の端末装置Ｔが描かれているだけであるが、列車の場合、車両Ａは複数両が連結されているのが一般的であり、また、多数の乗客がそれぞれ端末装置Ｔを所持しながら搭乗していることになる。
【００２０】
車両Ａ内には、車両内通信手段１０が設置されている。また、運行経路Ｌ上の所定箇所には、複数の通信ポイントＰ１，Ｐ２，Ｐ３が定義され、各通信ポイントＰ１，Ｐ２，Ｐ３には、それぞれ経路上通信手段２１，２２，２３が設置されている。ここで、各通信ポイントＰ１，Ｐ２，Ｐ３は、車両Ａが停車するか、または、通常の運行速度よりも低い速度で通過することが予定されている運行経路Ｌ上の所定箇所に定義される。これは、車両Ａに設置された車両内通信手段１０と、各経路上通信手段２１，２２，２３との間で、十分な通信速度をもってパケット通信が可能になるようにするための配慮である。
【００２１】
既に述べたとおり、現在、高速移動中の端末装置に対するパケット通信の通信速度は、技術的に著しく低く制限されており、大量のデータのやりとりを行うには不適当である。すなわち、列車や自動車が通常の運行速度で運行経路Ｌ上を走行している状態では、車両内通信手段１０と経路上通信手段２１，２２，２３との両者間において、十分な通信速度を確保することができない。そこで、本発明では、両者間のパケット通信を、車両Ａが停車している状態か、あるいは、通常の運行速度よりも低い速度（技術的に必要な通信速度が確保できる速度）で走行している状態で行うこととした。
【００２２】
車両Ａが所定の路線に沿って走行する列車の車両である場合には、運行経路Ｌは、この列車の路線ということになるので、通信ポイントＰ１，Ｐ２，Ｐ３は、この路線上の所定の駅（すべての駅でもよいし、一部の駅でもよい）に定義し、経路上通信手段２１，２２，２３は、これらの駅に設置すればよい。そうすれば、列車がこれらの駅に停車した時点で、車両内通信手段１０と経路上通信手段２１，２２，２３との間で、十分な通信速度をもった通信が可能になる。もちろん、普通列車、急行列車、特急列車など、列車ごとに停車駅が異なる場合には、普通列車については、すべての通信ポイントＰ１，Ｐ２，Ｐ３が本来の通信ポイントとして機能するが、急行列車については、通信ポイントＰ２だけが本来の通信ポイントとして機能する、というような運用になってもかまわない。また、運行経路Ｌ上で列車が必ず徐行することになっている地点があり、この徐行速度であれば、十分な通信速度を確保できるのであれば、そのような徐行地点を通信ポイントとして定義して、経路上通信手段の設置を行うようにしてもよい。
【００２３】
一方、車両Ａが所定の道路上を走行する自動車の車両である場合には、運行経路Ｌは、この自動車が走行予定の道路ということになるので、通信ポイントＰ１，Ｐ２，Ｐ３は、この道路上の交差点、料金所、もしくはパーキングエリアに定義し、経路上通信手段２１，２２，２３は、これらいずれかの通信ポイントに設置すればよい。これらの通信ポイントでは、車両Ａが停車するか、あるいは、通常の運行速度よりも低い速度で走行することが予定されており、十分な通信速度をもった通信が可能になる。もちろん、交差点の場合は、赤信号であれば停車するが、青信号であれば通常の運行速度で通過する、というような運行が行われることになるが、本発明では、通信ポイントは、車両が必ず停車するか通信可能な低い速度で通過する地点に設定する必要はなく、ある条件の下で、車両が停車するか通信可能な低い速度で通過することが予定されている地点に設定すればよい。別言すれば、本発明において設定された複数の通信ポイントでは、車両内通信手段１０と経路上通信手段２１，２２，２３との間の通信が可能であることが必ずしも保証されている必要はない。
【００２４】
道路上を走行する自動車の車両について本発明を適用する場合の最も実用的なケースは、高速道路上を運行する長距離路線バスである。このようなバスでは、運行路線や停車予定となる料金所やパーキングエリアなどが予め定まっているので、確実に通信可能となる通信ポイントを設定することが容易である。ただ、本発明の適用は、必ずしもこのような路線バスに限定されるものではない。たとえば、いわゆるマイカーのような一般自動車に適用するのであれば、主要な幹線道路などを運行路線Ｌとして定義し、この幹線道路上の交差点などに通信ポイントを設定すればよい。本発明における運行路線Ｌは、必ずしも１本の一次元的な路線である必要はなく、二次元的な広がりをもった道路網であってもよく、車両の運行経路は、この道路網内の任意の経路であってかまわない。
【００２５】
このように、本発明は、自動車を車両とした場合にも適用可能であるが、ここでは、説明の便宜上、列車の車両に適用し、各通信ポイントＰ１，Ｐ２，Ｐ３を、この列車の運行路線上の駅に設定した具体的な実施形態を述べることにする。したがって、図１に示す各経路上通信手段２１，２２，２３は、それぞれ各駅の構内に設けられている。また、ここに示す実施形態では、便宜上、運行路線Ｌ上の３ケ所に通信ポイントＰ１，Ｐ２，Ｐ３が設定された例を述べるが、もちろん、実際には、より多数の通信ポイントが設定され、より多数の経路上通信手段がそれぞれ設置されることになる。
【００２６】
代理サーバ装置３０は、各経路上通信手段２１，２２，２３に対して接続され、また、インターネット４０を介して、外部のサーバ装置５１〜５５との間でデータパケットのやりとりを行う機能をもった装置である。代理サーバ装置３０と経路上通信手段２１，２２，２３との間の接続は、この例では、すべて有線によって行っているが、どのような方法で接続してもかまわない。また、代理サーバ装置３０をインターネット４０へ接続する具体的な手段も任意のものでかまわない。代理サーバ装置３０は、要するに、インターネット４０に対して、種々のプロトコルでアクセス可能ないわゆる「プロキシサーバ」として機能する。また、図１に示す外部のサーバ装置５１〜５５（実際には、インターネット４０には、膨大な数のサーバ装置が接続されているが、ここでは説明の便宜上、５台のみを示す）は、インターネット４０に接続された一般的なメールサーバやファイルサーバなどのサーバ装置であり、ここに示す移動体パケット通信システムの目的は、車両Ａ内の端末装置Ｔとこれら外部のサーバ装置５１〜５５との間でパケット通信を行うことにある。
【００２７】
結局、この移動体パケット通信システムを構築するには、各車両Ａ内に設置した車両内通信手段１０と、個々の通信ポイントＰ１，Ｐ２，Ｐ３に設置した経路上通信手段２１，２２，２３と、これらに接続された代理サーバ装置３０と、を用意すればよい。なお、代理サーバ装置３０は、必ずしも１台のサーバ装置にする必要はなく、たとえば、関東地区、関西地区など、個々の地区を担当する複数の代理サーバ装置を設けるようにしてもかまわない。
【００２８】
続いて、上述した各構成要素の具体的な機能について説明する。まず、車両内通信手段１０は、上述したように、各車両Ａに設置される通信手段であるが、２つの通信機能を有している。第１の通信機能は、車両内に存在する端末装置Ｔとの間で無線によりデータパケットの送受信を行う車内通信機能である。このような機能をもった通信手段は、既に、無線ＬＡＮ装置として広く利用されている。この車内通信機能により、車両Ａの乗客が所持する携帯電話などの端末装置Ｔと、無線によりデータパケットの交換が行われる。両者間の無線通信のプロトコルは、パケット通信が可能なプロトコルであればどのようなものでもかまわないが、実用上は、ＩＰアドレスを用いた汎用プロトコルを用いるのが好ましい。乗客は、このような汎用プロトコルに対応した一般的な端末装置Ｔを用意すれば、このシステムの利用が可能になる。
【００２９】
この車内通信機能は、後述する車外通信機能とは異なり、常に実行可能な状態となっている。これは、端末装置Ｔが車両Ａとともに移動するので、常に車両内通信手段１０と通信可能な環境におかれているためである。なお、複数車両編成の列車の場合、１台の車両に車両内通信手段１０を設けただけでは、全車両の乗客が保持する端末装置Ｔと無線通信することが困難な場合もあるが、その場合には、たとえば、１両おきに別個独立した車両内通信手段１０を設けるなどの措置を講じればよい。
【００３０】
車両内通信手段１０の第２の通信機能は、各通信ポイントＰ１，Ｐ２，Ｐ３に設置された経路上通信手段２１，２２，２３との間で、無線によりデータパケットの送受信を行う車外通信機能である。もっとも、この車外通信機能は、常に実行可能な状態となっているわけではなく、前述したとおり、車両Ａが特定の通信ポイント付近に停車している状態、もしくは、車両Ａが特定の通信ポイント付近を通常の運行速度よりも低い速度で通過している状態において、当該特定の通信ポイントに設置された経路上通信手段との間でのみ実行可能になる。たとえば、図示の状態では、車両Ａは、通信ポイントＰ１とＰ２の間を通常の運行速度で走行中であるので、現時点では車外通信機能は実行できないが、通信ポイントＰ２が設定された駅に到着し、この駅で停車している間は、通信ポイントＰ２に設置されている経路上通信手段２２との間で車外通信機能が実行可能となり、データパケットの送受を行うことができる。
【００３１】
このように、車内通信機能は、常に実行可能な状態となっているにもかかわらず、車外通信機能は、いずれかの通信ポイントの近傍でなければ実行可能にならない。したがって、車内と車外との通信を仲介する役割を果たす車両内通信手段１０および経路上通信手段２１，２２，２３には、いわゆるバッファ機能をもたせておく必要がある。
【００３２】
たとえば、車両Ａの乗客が、端末装置Ｔから外部のサーバ装置５１に対してデータパケットを送信する操作を行ったとすると、このデータパケットは、図示の例の場合、端末装置Ｔ→車両内通信手段１０→経路上通信手段２２→代理サーバ装置３０→インターネット４０→外部のサーバ装置５１という伝送経路で送信されることになるが、ここで、車両内通信手段１０→経路上通信手段２２なる部分は、車両Ａが通信ポイントＰ２（駅）に到着した時点で初めて実行可能になる。したがって、通信ポイントＰ２に到着するまでの間に、端末装置Ｔから受信したデータパケットは、車両内通信手段１０内に一時的に保管しておく必要がある。このため、車両内通信手段１０は、車内通信機能により端末装置Ｔからデータパケットを受信した場合に、このデータパケットを車外通信機能が実行可能になるまで一時的に保管し、車外通信機能が実行可能になったときに、一時的に保管していたデータパケットを経路上通信手段へと送信する処理を実行する。
【００３３】
一方、上述のようにして、端末装置Ｔから外部のサーバ装置５１に対して送信されたデータパケットに対する応答として、外部のサーバ装置５１から端末装置Ｔ宛に所定のデータパケットが送信された場合、このデータパケットは、外部のサーバ装置５１→インターネット４０→代理サーバ装置３０→経路上通信手段２３（たとえば、この時点で、車両Ａが通信ポイントＰ２からＰ３へと向かっている場合）→車両内通信手段１０→端末装置Ｔという伝送経路で送信されることになるが、ここで、経路上通信手段２３→車両内通信手段１０なる部分は、車両Ａが通信ポイントＰ３（駅）に到着した時点で初めて実行可能になる。したがって、通信ポイントＰ３に到着するまでの間に、経路上通信手段２３は、端末装置Ｔ宛のデータパケットを、一時的に保管しておく必要がある。経路上通信手段２３は、車両Ａが通信ポイントＰ３に到着したら、保管していたデータパケットを車両内通信手段１０へと送信する。車両内通信手段１０は、車外通信機能により、このデータパケットを受信し、このデータパケットを車内通信機能により宛先となる端末装置Ｔへ送信する処理を実行する。
【００３４】
経路上通信手段２１，２２，２３の役割は、車両内通信手段１０と代理サーバ装置３０とを仲介することにある。すなわち、経路上通信手段２１，２２，２３は、それぞれ通信ポイントＰ１，Ｐ２，Ｐ３（駅）に停車中の車両Ａ内の車両内通信手段１０からデータパケットを受信した場合、このデータパケットを代理サーバ装置３０へと送信する処理を実行し、逆に、代理サーバ装置３０から所定の端末装置宛のデータパケットを受信した場合に、このデータパケットを、それぞれ通信ポイントＰ１，Ｐ２，Ｐ３付近に到来した車両Ａ内に設置された車両内通信手段１０へと送信する処理を実行する。車両Ａが通信ポイントに到来するまでは、データパケットを保管することになる。
【００３５】
一方、代理サーバ装置３０は、インターネット４０に対して、個々の端末装置Ｔの代理としてアクセスを行う役割を果たす。具体的には、経路上通信手段２１，２２，２３からデータパケットを受信した場合には、これをインターネット４０を介して外部のサーバ装置５１〜５５へと送信する処理を実行し、逆に、外部のサーバ装置５１〜５５からインターネット４０を介してデータパケットを受信した場合には、これを経路上通信手段２１，２２，２３へと送信する処理を実行する。
【００３６】
ここで留意すべき点は、経路上通信手段２１，２２，２３側から送られてきたデータパケットをインターネット４０へと流す場合には、１つのデータパケットをそのまま１つのデータパケットとして流す処理を行うが、逆に、インターネット４０側から送られてきたデータパケットを経路上通信手段２１，２２，２３側へと流す場合には、データパケットの複製を作成し、１つのデータパケットを複数のデータパケットとして、複数の通信ポイントＰ１，Ｐ２，Ｐ３にそれぞれ設置された複数の経路上通信手段２１，２２，２３へと送信する処理を実行する点である。別言すれば、代理サーバ装置３０は、インターネット４０側から送信されてきたデータパケットを、すべての経路上通信手段２１，２２，２３に対してマルチキャストすることになる。
【００３７】
このようなマルチキャストが必要になる理由は、インターネット４０側から特定の端末装置Ｔ宛のデータパケットが代理サーバ装置３０へと送信されてきた時点では、宛先となる端末装置Ｔを載せている車両Ａが現在どこを走行中であり、次にどの通信ポイントでこのデータパケットを受信可能であるか、を正確に認識することが困難であるためである。もちろん、車両Ａが列車の場合、時刻表などを参照することにより、ある程度の精度で、どの経路上通信手段経由でデータパケットを引き渡せばよいかを予想することは可能であるが、現実的には、列車が必ずしも時刻表どおりの運行を行う保証はない。また、車両Ａが自動車の場合は、運行状況は著しく変動するため、車両の位置を認識することは極めて困難である。そこで、本発明では、位置が不確定である車両Ａ内の端末装置Ｔ宛にデータパケットを送信する際に、マルチキャストを行い、いずれの経路上通信手段２１，２２，２３からでもデータパケットの引き渡しを行えるようにしている。
【００３８】
なお、ここに示す実施形態では、運行経路Ｌ上のすべての経路上通信手段２１，２２，２３に対してマルチキャストを行う例を示すが、本発明を実施する上では、必ずしもすべての経路上通信手段に対してマルチキャストを行う必要はなく、インターネット４０を介して代理サーバ装置３０が受信したデータパケットは、当該データパケットの宛先となる端末装置が存在する車両が所定時間内に到来する可能性のある所定の地理的範囲内の複数の通信ポイントにそれぞれ設置された経路上通信手段へと送信する処理を実行するようにしてもかまわない。たとえば、列車の場合、上述したように、時刻表によって個々の車両の運行状況がある程度把握できるのであれば、特定の列車内の端末装置宛のデータパケットについては、当該列車が、たとえば３０分以内に到来する可能性のある所定の地理的範囲に存在する通信ポイントを調べ、このような一部の通信ポイントに設置された経路上通信手段に限って、データパケットのマルチキャストを行うようにしてもよい。また、自動車の場合であっても、たとえば、１時間前に東京の通信ポイントからデータパケットの送信があった車両であれば、現時点でも関東地区に存在することは物理的に明らかなので、マルチキャストの対象を関東地区の通信ポイントに限定してもかまわない。
【００３９】
＜＜＜ §２． 通信形態に関する工夫 ＞＞＞
以上、§１では、本発明の基本的な実施形態を述べたが、ここでは、本発明を実施する上で有用な通信形態に関するいくつかの工夫を述べておく。
【００４０】
図１に示す移動体パケット通信システム１００の目的は、車両Ａ内の端末装置Ｔと、外部のサーバ装置５１〜５５との間でパケット通信を行うことにある。ここで、端末装置Ｔは、車両Ａの乗客が所持する携帯電話などの汎用端末装置であるため、端末装置Ｔと車両内通信手段１０との間の通信は、ＩＰアドレスを利用した汎用プロトコルで行うのが好ましい。また、代理サーバ装置３０がインターネット４０を介して外部のサーバ装置５１〜５５と通信を行う場合にも、ＩＰアドレスを利用した汎用プロトコルが必要になる。ただ、車両内通信手段１０と経路上通信手段２１，２２，２３との間の通信や、経路上通信手段２１，２２，２３と代理サーバ装置３０との間の通信は、必ずしも汎用プロトコルで行う必要はなく、この移動体パケット通信システムによるサービスを提供する業者に固有の特殊プロトコルであってもかまわず、むしろ固有の特殊プロトコルを利用した方が効率的になる場合も少なくない。
【００４１】
このような観点から、ここで述べる実施形態では、次のような工夫を施している。まず、車両内通信手段１０には、ＤＨＣＰ（Dynamic Host Configuration Protocol）の機能をもたせ、この機能により車両Ａ内に存在する各端末装置Ｔに対してプライベートＩＰアドレスを付与できるようにしてある。一方、代理サーバ装置３０には、ＮＡＴ（Network Address Translator）の機能をもたせ、この機能によりプライベートＩＰアドレスとグローバルＩＰアドレスとの変換を行わせ、システム１００の内部ではプライベートＩＰアドレスを用いたパケット通信が行われ、外部のサーバ装置５１〜５５との間ではグローバルＩＰアドレスを用いたパケット通信が行われるようにしている。
【００４２】
また、上述したように、車両内通信手段１０、経路上通信手段２１，２２，２３、代理サーバ装置３０の範囲内の通信プロトコルは、固有の特殊プロトコルを採用することが可能であるので、ここに述べる実施形態では、この範囲内の通信については、データ圧縮を行う運用を行っている。すなわち、車両内通信手段１０には、車両Ａ内に存在する端末装置Ｔから受信したデータパケットに対してデータ圧縮を行う機能をもたせ、代理サーバ装置３０には、圧縮されたデータパケットを伸張する機能をもたせており、車両内通信手段１０から代理サーバ装置３０へと転送されるデータパケットが圧縮された状態になるようにしている。同様に、代理サーバ装置３０には、外部のサーバ装置５１〜５５から受信したデータパケットに対してデータ圧縮を行う機能をもたせ、車両内通信手段１０には、圧縮されたデータパケットを伸張する機能をもたせており、代理サーバ装置３０から車両内通信手段１０へと転送されるデータパケットが圧縮された状態になるようにしている。
【００４３】
車両内通信手段１０と経路上通信手段２１，２２，２３との間の通信は、常に実行可能となっているわけではなく、既に述べたとおり、車両Ａが通信ポイントＰ１，Ｐ２，Ｐ３において車外通信機能を実行可能になっている状態（たとえば、駅に停車している状態や、交差点に信号待ちで停車している状態など）に限定される。このため、車両内通信手段１０と経路上通信手段２１，２２，２３との間でのデータパケットの送受処理は、比較的短時間に完了する必要がある。データパケットに対してデータ圧縮を行っておくことは、この送受処理時間を短縮する上で効果的である。
【００４４】
図２は、上述したプライベートＩＰアドレスとグローバルＩＰアドレスとの変換処理と、データパケットの圧縮／伸張処理と、を組み込んだ実施形態を説明するブロック図である。ここでは、同一の車両Ａに乗車している５人の乗客が、それぞれ端末装置Ｔ１〜Ｔ５を用いて、本発明に係る移動体パケット通信システムを利用している状態が示されている。この場合、まず、車両内通信手段１０のＤＨＣＰ機能により、端末装置Ｔ１〜Ｔ５のそれぞれに対して、所定のプライベートＩＰアドレスが付与される。図示の例では、各端末装置Ｔ１〜Ｔ５に対して、それぞれ「10.0.1.1」〜「10.0.1.5」なるプライベートＩＰアドレスが付与されている。一方、外部のサーバ装置５１〜５５に対しては、それぞれ「1.1.1.1」〜「5.5.5.5」なるグローバルＩＰアドレスが付与されている。また、代理サーバ装置３０には、「1.0.0.99」なるグローバルＩＰアドレスが付与されている。
【００４５】
この例では、移動体パケット通信システム１００の内部の通信は、プライベートＩＰアドレスを用いて行うことができるが、インターネット４０に対するアクセスを行う際には、グローバルＩＰアドレスを用いる必要がある。そこで、代理サーバ装置３０のＮＡＴ機能により、プライベートＩＰアドレスとグローバルＩＰアドレスとの変換を行い、各端末装置Ｔ１〜Ｔ５から、外部のサーバ装置５１〜５５宛に送られるデータパケットの送信元アドレスは、代理サーバ装置３０において、すべて「1.0.0.99」なる共通のグローバルＩＰアドレスに変換される。したがって、外部のサーバ装置５１〜５５は、各端末装置Ｔ１〜Ｔ５から送信されてきたデータパケットに対する応答を、すべて「1.0.0.99」なるグローバルＩＰアドレスをもった代理サーバ装置３０宛に送ることになる。代理サーバ装置３０は、こうして送られてきたデータパケットが、どのプライベートＩＰアドレス宛のものであるかをポート番号を利用して認識することになる。このような認識方法も含めたＮＡＴ処理機能は既に公知の技術であるため、ここでは詳しい説明は省略する。
【００４６】
また、移動体パケット通信システム１００の内部では、データパケットは圧縮された状態で伝送される。たとえば、端末装置Ｔ１から外部のサーバ装置５１宛にデータパケットが送信された場合を考えよう。この場合、まず、車両内通信手段１０がこのデータパケットを受け取るが、この時点で、車両Ａが通信ポイントに到達していなかったとすると、前述したように、このデータパケットは車両内通信手段１０内に一時的に保管されることになる。もちろん、他の端末装置Ｔ２〜Ｔ５からもデータパケットが送信されていれば、これらのデータパケットがまとめて一時保管されることになる。このとき、車両内通信手段１０は、一時保管したデータパケットに対して所定のアルゴリズムに基づくデータ圧縮を行う。後に§３で述べる具体例のように、このデータ圧縮は、複数のデータパケットに対してまとめて行うようにするのが効率的である。車両Ａが通信ポイントに到着し、車外通信機能が実行可能になった時点で、圧縮されたデータパケットは、経路上通信手段２ｘ（２１，２２，２３のいずれか）へと送信される。前述したように、圧縮された状態でのデータパケットの送信は、通信時間の短縮に役立つことになる。経路上通信手段２ｘは、受信したデータパケットを圧縮状態のまま代理サーバ装置３０へと伝送する。この圧縮されたデータパケットは、代理サーバ装置３０において伸張された後、ＮＡＴ機能によるアドレス変換を受け、インターネット４０を介して外部のサーバ装置５１へと送信されることになる。
【００４７】
こうして送信されたデータパケットに応答して、外部のサーバ装置５１から端末装置Ｔ１宛にデータパケットが送信されると、まず、代理サーバ装置３０がこれを受信し、ＮＡＴ機能により、端末装置Ｔ１のプライベートＩＰアドレス宛のデータパケットにアドレス変換される。そして、この代理サーバ装置３０において、当該データパケットは所定のアルゴリズムに基づいてデータ圧縮された後、複数の経路上通信手段２１，２２，２３宛にマルチキャストされる。各経路上通信手段２１，２２，２３は、こうしてマルチキャストされたデータパケットを、圧縮された状態のまま保持し、通信ポイントＰ１，Ｐ２，Ｐ３に車両Ａが到来したら、車両内通信手段１０に対して圧縮状態のまま送信する。車両内通信手段１０は、受信したデータパケットを伸張した後、これを宛先となる端末装置Ｔ１へと送信する。
【００４８】
なお、代理サーバ装置３０における圧縮処理をより効率化するためには、代理サーバ装置３０にバッチ処理を実行させるようにすればよい。たとえば、インターネット４０側から代理サーバ装置３０にデータパケットが届いたら、しばらくの間、これらデータパケットを蓄積しておくようにし、個々の車両宛のデータパケットごとに、それぞれ別個のパケット群を構成し、構成した各パケット群ごとにそれぞれまとめてデータ圧縮し、経路上通信手段２１，２２，２３へとマルチキャストすればよい。たとえば、図２に示す例において、同一の車両Ａ内に存在する５つの端末装置Ｔ１〜Ｔ５宛のデータパケットが代理サーバ装置３０に届いた場合、この５つのデータパケットを、車両Ａ宛のデータパケット群としてひとまとめにし、このひとまとめのデータパケット群全体に対してデータ圧縮を行うようにする。そうすれば、このデータパケット群は、圧縮状態のまま車両Ａ内の車両内通信手段１０へと届けられた上で伸張が行われ、各端末装置Ｔ１〜Ｔ５宛のデータパケットに復元されることになる。
【００４９】
続いて、各経路上通信手段２１，２２，２３にマルチキャストされたデータパケットの取り扱いについて検討してみよう。たとえば、図１に示す例において、車両Ａ内の端末装置Ｔ宛のデータパケットは、前述したように、各経路上通信手段２１，２２，２３のそれぞれに送信（マルチキャスト）されることになる。ここで、実用上は、上述したように、代理サーバ装置３０において、個々の車両宛のデータパケットごとに、それぞれ別個のパケット群を構成して圧縮するのが好ましく、その場合は、各経路上通信手段２１，２２，２３のそれぞれには、たとえば車両Ａ宛のデータパケットをひとまとめにしたデータパケット群が送信されることになる。もちろん、運行経路Ｌ上を運行している車両は、車両Ａだけではなく、たとえば、車両Ｂ、車両Ｃといった他の車両も多数運行している。したがって、各経路上通信手段２１，２２，２３には、車両Ａ宛のデータパケット群、車両Ｂ宛のデータパケット群、車両Ｃ宛のデータパケット群、というように、多数のデータパケット群が集まることになる。
【００５０】
ここで、どの車両が、どの通信ポイントを通過するか、という事項は、必ずしも正確に予測できる事項ではないので、本実施形態では、各経路上通信手段２１，２２，２３は、何らかの車両が通信ポイントＰ１，Ｐ２，Ｐ３に到来した場合に、保管しているすべてのデータパケット群を到来した車両内の車両内通信手段１０に対して送信する処理を行うようにしている。また、１回の送信で確実に目的の車両にデータパケットが引き渡せる保証はないので、各経路上通信手段２１，２２，２３は、それぞれ各通信ポイントＰ１，Ｐ２，Ｐ３に車両が到来するたびに、代理サーバ装置３０から受信したデータパケットを、到来した車両に向けて（車両内に設置された車両内通信手段１０へ向けて）繰り返し送信する処理を実行するようにしている。
【００５１】
たとえば、図１に示す例において、通信ポイントＰ１からＰ２に向かって、車両ＡおよびＢが走行中の場合に、各経路上通信手段２１，２２，２３に車両Ｂ宛のデータパケット群と車両Ｃ宛のデータパケット群とが保管されていたとしよう。この場合、先行する車両Ａが通信ポイントＰ２（駅）に到着した時点で、経路上通信手段２２から車両Ａに対して、車両Ｂ宛のデータパケット群と車両Ｃ宛のデータパケット群とが送信されることになるが、これを受信した車両Ａの車両内通信手段１０は、いずれのデータパケット群も自己宛のものではないので、そのまま廃棄する処理を行う。続いて、後続の車両Ｂが通信ポイントＰ２（駅）に到着した時点で、同様に、経路上通信手段２２から車両Ｂに対して、車両Ｂ宛のデータパケット群と車両Ｃ宛のデータパケット群とが送信されることになる。これを受信した車両Ｂの車両内通信手段１０は、車両Ｂ宛のデータパケット群は自己宛のものであるため、そこに含まれている各データパケットを車両Ｂ内の各端末装置へと送信し、車両Ｃ宛のデータパケット群を廃棄する処理を行う。
【００５２】
このように、各経路上通信手段２１，２２，２３は、新たな車両がそれぞれ通信ポイントＰ１，Ｐ２，Ｐ３に到来するたびに、保管しているデータパケット群を繰り返し送信する処理を行うことになるが、代理サーバ装置３０からは順次新しいデータパケット群が送られてくるため、各経路上通信手段２１，２２，２３に保管されるデータパケット群は増加の一途を辿ることになる。そこで、実用上は、正しい宛先となる車両に引き渡しが完了したデータパケット群については、これを廃棄してゆく処理を行う必要がある。このような経路上通信手段２１，２２，２３におけるデータパケットの廃棄処理は、たとえば、次のようないくつかの方法により実施可能である。
【００５３】
まず、第１の方法は、車両内通信手段１０に、所定の経路上通信手段から自己車両宛のパケット群を受信したときに、当該パケット群の受領を確認する受領確認情報を当該所定の経路上通信手段に対して送信する処理を行う機能をもたせておき、各経路上通信手段には、いずれか１つの経路上通信手段が特定のパケット群についての受領確認情報を受信した場合に、この特定のパケット群と同一のパケット群を廃棄する処理を実行する機能をもたせておく方法である。この方法では、たとえば、図１に示す車両Ａ宛のデータパケット群は、３つの経路上通信手段２１，２２，２３にそれぞれブロードキャストされることになるが、車両Ａが通信ポイントＰ２に到来し、この車両Ａ宛のデータパケット群が車両Ａ内の車両内通信手段１０によって受信されると、この車両Ａ内の車両内通信手段１０から経路上通信手段２２に対して、受領確認情報が送信されることになる。経路上通信手段２２は、この受領確認情報の送信を受けて、車両Ａ宛の当該データパケット群の引き渡しが完了した旨を認識し、保管していた当該データパケット群を廃棄する処理を行う。同時に、経路上通信手段２２から、他の経路上通信手段２１，２３に対して、同一のデータパケット群を廃棄すべき旨の指示が送信されるようにし、経路上通信手段２１，２３においても、同一のデータパケット群の廃棄が行われる。かくして、目的の車両への送信が完了したデータパケットは、各経路上通信手段２１，２２，２３から順次廃棄されてゆくことになる。
【００５４】
第２の方法は、個々の車両からの受領確認情報の送信を省略することができる方法である。この方法では、各経路上通信手段２１，２２，２３が、それぞれの通信ポイントＰ１，Ｐ２，Ｐ３付近に車両が到来するたびに、保管しているデータパケットを、到来した車両内に設置された車両内通信手段１０へと毎回送信する処理を実行する点に変わりはないが、保管しているデータパケットのうち、代理サーバ装置３０から受信した後に所定の時間が経過したデータパケットについては、これを廃棄する処理を実行するようにする。ここで、所定の時間としては、各車両の運行状況を考慮した上で、いずれの車両に対しても、いずれかの経路上通信手段から、目的のデータパケットの送信が完了するであろうと予測される所定の時間を設定すればよい。
【００５５】
第３の方法も、個々の車両からの受領確認情報の送信を省略することができる方法である。この方法においても、各経路上通信手段２１，２２，２３が、それぞれの通信ポイントＰ１，Ｐ２，Ｐ３付近に車両が到来するたびに、保管しているデータパケットを、到来した車両内に設置された車両内通信手段１０へと毎回送信する処理を実行する点に変わりはないが、保管しているデータパケットのうち、送信繰り返し回数が所定回数に達したデータパケットについては、これを廃棄する処理を実行するようにする。たとえば、到来した車両に対する送信を３回繰り返したデータパケットについては廃棄するような設定を行っておけば、代理サーバ装置３０からの受信後に、到来した３台の車両に対する送信が行われると廃棄されることになる。廃棄までの送信繰り返し回数は、やはり各車両の運行状況を考慮した上で、いずれの車両に対しても、いずれかの経路上通信手段から、目的のデータパケットの送信が完了するであろうと予測される回数を設定すればよい。
【００５６】
以上述べた方法は、いずれも経路上通信手段２１，２２，２３にその時点で保管されているすべてのデータパケットを、到来した車両に対して無条件で送信する方法であるが、各経路上通信手段２１，２２，２３に、それぞれの通信ポイントＰ１，Ｐ２，Ｐ３付近に車両が到来するたびに、到来した車両を特定する処理を実行し、代理サーバ装置３０から受信したデータパケットのうち、特定された車両宛のデータパケットのみを選択し、この選択したデータパケットを到来した車両内に設置された車両内通信手段へと送信した後にこれを廃棄する処理を実行し、かつ、他の経路上通信手段によって車両への送信が完了したパケットと同一のパケットについては、これを廃棄する処理を実行する方法を採れば、より効率的な送信が可能になる。この方法によれば、各経路上通信手段２１，２２，２３に保管されているデータパケット群のうち、たとえば、車両Ａ宛のデータパケット群は、車両Ａに対してのみ送信され、車両Ｂ宛のデータパケット群は、車両Ｂに対してのみ送信されることになる。この方法を採る場合には、通信ポイントに車両が到来したら、まず、経路上通信手段と車両内通信手段との間で交信を行い、到来した車両を特定する処理を行い、更に、特定された車両宛のデータパケットのみを選択する処理が必要になるが、無駄なデータパケットの送信を抑制するメリットが得られる。
【００５７】
なお、本発明に係る移動体パケット通信システムを利用して、高速移動中の車両内から、端末装置Ｔを用いて外部のサーバ装置へとデータパケットを送信し、当該外部のサーバ装置からの応答をデータパケットとして受信するようなアクセスを行う場合、通常のアクセスに比べて長時間を要することも少なくない。
【００５８】
たとえば、外部のサーバ装置５１がメールサーバであり、端末装置Ｔから、このメールサーバにアクセスして、自己宛の電子メールを受信するような場合を考えてみよう。この場合、一般的なメール受信プロトコル「ＰＯＰ３」によれば、端末装置Ｔからメールサーバ５１宛に、「POPGET」なる命令をアカウント名やパスワードとともに送信することになる。メールサーバ５１は、これを受けて、当該アカウント宛のメールの内容を返信する処理を行う。ここで、端末装置Ｔから「POPGET」命令を送信した後、メールサーバ５１からメールの内容が返信されてくるまでの時間は、通常、数秒程度であり、端末装置Ｔに組み込まれている一般的な電子メールアプリケーションは、メール内容の返信が長時間得られなかった場合には、いわゆる「タイムアウト」と判断し、「メールの受信に失敗しました」などのメッセージを表示してエラー処理を行うようにプログラムされている。
【００５９】
また、外部のサーバ装置５３がファイルサーバであり、端末装置Ｔから、このファイルサーバにアクセスして、何らかのファイルをダウンロードする場合は、「ＦＴＰ」なるプロトコルを用いて、端末装置Ｔからファイルサーバ５３に対して所定のファイルのダウンロード命令を与え、目的のファイルを送信してもらうことになる。この場合も、端末装置Ｔからダウンロード命令を送信した後、ファイルサーバ５３からの返信が長時間得られなかった場合には、一般的なファイル転送用アプリケーションは、いわゆる「タイムアウト」と判断し、「ファイルのダウンロードに失敗しました」などのメッセージを表示してエラー処理を行うようにプログラムされている。
【００６０】
ところが、本発明に係る移動体パケット通信システムでは、車内の端末装置Ｔから外部のサーバ装置５１〜５５へ向けたデータパケットや、逆に、外部のサーバ装置５１〜５５から車内の端末装置Ｔに向けたデータパケットは、直ちに伝送されるわけではなく、車両が所定の通信ポイントへ到達するまで、車両内通信手段１０側や、経路上通信手段２１，２２，２３側に保管された状態になる。このため、端末装置Ｔに組み込まれている一般的な汎用アプリケーションソフトウエアを用いてデータパケットの送受信を行った場合、いわゆる「タイムアウト」との判断がなされてエラーが生じる可能性が高い。そこで、実用上は、本発明に係るシステムを利用した通信を行う際には、「タイムアウト」と判断すべき時間を長めに設定した専用のアプリケーションソフトウエアを用いるようにするのが好ましい。
【００６１】
あるいは、端末装置Ｔから外部のサーバ装置５１〜５５に対して、所定時間内の返信を要求するデータパケットの送信（別言すれば、「タイムアウト」との判断により、エラー処理が実行されるようなアプリケーションを用いたデータパケットの送信）が行われたときに、車両内通信手段１０が、外部のサーバ装置５１〜５５に代わって返信を行う代理返信機能を実行するような構成にしておくこともできる。このような代理返信機能を設けておけば、端末装置Ｔから外部のサーバ装置５１〜５５に対して、汎用のアプリケーションを用いたアクセスが行われた場合でも、「タイムアウト」によるエラー発生を防ぐことができる。
【００６２】
たとえば、端末装置Ｔからメールサーバ５１宛に「POPGET」なる電子メールの受信命令が送信された場合、とりあえず、車両内通信手段１０の代理返信機能によって、この命令に対する疑似的な返信を端末装置Ｔ宛に返すようにする。具体的には、たとえば、「No Mail」なる擬似的な返信を返せばよい。端末装置Ｔ内の電子メールアプリケーションは、このような返信を、メールサーバ５１からの返信であるものとして取り扱い、たとえば、「現在、受信すべき電子メールは１つもありません。」のようなメッセージを表示するような処理を実行することになる。もちろん、この時点では、「POPGET」なる電子メールの受信命令は、まだ、同じ車両内の車両内通信手段１０に一時的に保管された状態となっており、メールサーバ５１には届いていない。
【００６３】
やがて、この車両がいずれかの通信ポイント（駅）へ到着すると、「POPGET」なる電子メールの受信命令は、経路上通信手段を介してメールサーバ５１へと送信され、やがて、これに対するメールサーバ５１からの正規の返信が戻ってくることになる。この返信は、早ければ、この車両が同じ駅に停車している最中に、車両内通信手段１０まで戻ってくるかもしれない。この車両がこの駅を発車した後に返信が戻ってきた場合には、当該返信は、その次の駅において、車両内通信手段１０まで届くことになる。いずれにせよ、メールサーバ５１からの正規の返信が、車両内通信手段１０へと届くことになる。こうして、車両内通信手段１０に正規の返信が届いた場合、車両内通信手段１０はその時点では、まだ端末装置Ｔに対して、当該正規の返信を送信せずに保管したままにする。これは、端末装置Ｔからの電子メールの受信命令に対しては、既に、「No Mail」なる擬似的な返信を送信してしまっており、端末装置Ｔ側の電子メールアプリケーションによる処理が完了してしまっているからである。ただし、後に、同じ端末装置Ｔの同じ電子メールアプリケーションから、再び、メールサーバ５１宛の「POPGET」なる電子メールの受信命令が送信された場合には、車両内通信手段１０は、当該命令を外部へと送信することなしに、既にメールサーバ５１からの正規の返信として得られているメールの内容を、そのまま端末装置Ｔへと送信する処理を実施するようにすればよい。
【００６４】
このように、端末装置Ｔから返信要求をともなう何らかの命令が送信された場合に、車両内通信手段１０側に、あたかも外部のサーバ装置からの返信であるかのように、所定の返信内容を端末装置Ｔへと送信する代理返信機能を設けておけば、端末装置Ｔ側のアプリケーションに「タイムアウト」のエラーを発生させることなしに、適切な処理を実行させることが可能になる。
【００６５】
＜＜＜ §３． 具体的な通信手順 ＞＞＞
最後に本発明に係る移動体パケット通信システムを用いたデータパケットの具体的な通信手順の一例を示しておく。いま、車両Ａ内に乗車している５人の乗客が、図２に示すようにそれぞれ端末装置Ｔ１〜Ｔ５を用いて、外部のサーバ装置５１〜５５へ、電子メールの受信命令もしくはファイルのダウンロード命令を送信したいと考えたとしよう。前述したように、各端末装置Ｔ１〜Ｔ５には、車両内通信手段１０のＤＨＣＰ機能により、それぞれ図２に示すようなプライベートＩＰアドレスが付与される。ここでは、各端末装置Ｔ１〜Ｔ５のアプリケーションソフトウエアによって、それぞれ図３に示すような５つのデータパケットＤＰ１０〜ＤＰ５０が作成されたものとしよう。この図３において、一重枠で示すデータパケットＤＰ１０，ＤＰ２０，ＤＰ５０は、いずれも電子メールの受信命令を含むデータパケットであり、二重枠で示すデータパケットＤＰ３０，ＤＰ４０は、いずれもファイルのダウンロード命令を含むデータパケットである。
【００６６】
たとえば、図３に示すデータパケットＤＰ１０の１行目の「Dst Addr: 1.1.1.1」なるデータは、送信先のＩＰアドレスが「1.1.1.1」（図２に示すように、メールサーバ５１のグローバルＩＰアドレス）であることを示し、２行目の「Src Addr: 10.0.1.1」なるデータは、送信元のＩＰアドレスが「10.0.1.1」（図２に示すように、端末装置Ｔ１のプライベートＩＰアドレス）であることを示し、３行目の「Dst Port#: 110」なるデータは、送信先となる外部のサーバ装置５１のポート番号が「110」（電子メール用アプリケーションを特定する番号）であることを示し、４〜５行目の「データ：POPGET ACC1/PASS1」は、送信対象となるデータの内容が、「POPGET」なる命令（電子メール用アプリケーションに対して、電子メールの受信を要求する命令）と、アカウント名「ACC1」およびパスワード「PASS1」であることを示す。データパケットＤＰ２０（メールサーバ５２宛）やデータパケットＤＰ５０（メールサーバ５５宛）の内容もほぼ同様である。
【００６７】
一方、図３に示すデータパケットＤＰ３０の１行目の「Dst Addr: 3.3.3.3」なるデータは、送信先のＩＰアドレスが「3.3.3.3」（図２に示すように、ファイルサーバ５３のグローバルＩＰアドレス）であることを示し、２行目の「Src Addr: 10.0.1.3」なるデータは、送信元のＩＰアドレスが「10.0.1.3」（図２に示すように、端末装置Ｔ３のプライベートＩＰアドレス）であることを示し、３行目の「Dst Port#: 23」なるデータは、送信先となる外部のサーバ装置５３のポート番号が「23」（ファイルのダウンロード用アプリケーションを特定する番号）であることを示し、４〜５行目の「データ：ACC3/PASS3 FTP_Command」は、送信対象となるデータの内容が、「FTP_Command」なる命令（ファイルのダウンロード用アプリケーションに対して、ダウンロードを要求する命令）と、アカウント名「ACC3」およびパスワード「PASS3」であることを示す。データパケットＤＰ４０（メールサーバ５４宛）の内容もほぼ同様である。なお、この図３は、便宜上、本発明に係るシステムの通信手順の説明に必要なデータを示すものであり、実際に送信されるデータパケットの内容をそのまま示すものではない。
【００６８】
さて、各端末装置Ｔ１〜Ｔ５から、図３に示すようなデータパケットＤＰ１０〜ＤＰ５０が送信されると、車両内通信手段１０は、これらのデータパケットを一時的に保管することになる。このとき、車両内通信手段１０内では、これら各データパケットの内容に基づいて、図４に示すような対応表ＴＢ１を作成するとともに、図５に示すような圧縮データDATA1およびDATA2を作成する処理が実行される。ここで、図４に示す対応表ＴＢ１は、後にデータの伸張処理を行うときに必要なデータをテーブルにしたものであり、図３に示す各データパケットＤＰ１０〜ＤＰ５０にそれぞれシリアル番号（図示の例では、Seq#:12345〜Seq#:12349）を付与し、送信先のグローバルＩＰアドレス「Dst:」と、送信元のプライベートＩＰアドレス「Src:」と、送信先のポート番号「Dst Port#」とを抜き出し、更に、返信が得られるまでのタイムアウト時間「TTL:」を設定したものである。
【００６９】
一方、図５に一重枠で示す圧縮データDATA1は、電子メールの受信命令を含むデータパケットＤＰ１０，ＤＰ２０，ＤＰ５０の内容をまとめたものであり、二重枠で示す圧縮データDATA2は、ファイルのダウンロード命令を含むデータパケットＤＰ３０，ＤＰ４０の内容をまとめたものである。DATA1の上欄１行目の「車両ID:A」なるデータは、この圧縮データが車両Ａから送信されるデータパケット群であることを示し、２行目の「Sequence#:0001」なるデータは、この圧縮データのシリアル番号が「0001」であることを示し、３行目の「Dst Port#: 110」なるデータは、この圧縮データの送信先のポート番号が「110」であることを示している。また、DATA1の下欄１行目の「Seq#: 12345」なるデータは、以下のデータが対応表ＴＢ１における「Seq#: 12345」に対応したデータ、すなわち、データパケットＤＰ１０内のデータであることを示す指標であり、２行目および３行目の「Dst: 1.1.1.1」および「ACC1/PASS1」なるデータは、このデータパケットＤＰ１０内の「Dst Addr: 1.1.1.1」および「ACC1/PASS1」を抜き出したものである。
【００７０】
なお、ここに示す例では、データパケットＤＰ１０内の「POPGET」なる命令は、圧縮データDATA1内では省略している。これは、「Dst Port#: 110」なるポート番号に関連したデータ（電子メール用アプリケーションに対する命令であることを示すデータ）には、必ず「POPGET」なる命令が伴うことになっているため、圧縮データDATA1内にわざわざ「POPGET」なる命令を入れておく必要がないためである。同様に、DATA1の下欄４〜６行目には、データパケットＤＰ２０内の必要なデータが抜き出され、下欄７〜９行目には、データパケットＤＰ５０内の必要なデータが抜き出されている。
【００７１】
また、図５に二重枠で示す圧縮データDATA2の上欄１行目の「車両ID:A」なるデータは、この圧縮データが車両Ａから送信されるデータパケット群であることを示し、２行目の「Sequence#:0002」なるデータは、この圧縮データのシリアル番号が「0002」であることを示し、３行目の「Dst Port#: 23」なるデータは、この圧縮データの送信先のポート番号が「23」であることを示している。また、DATA2の下欄１行目の「Seq#: 12347」なるデータは、以下のデータが対応表ＴＢ１における「Seq#: 12347」に対応したデータ、すなわち、データパケットＤＰ３０内のデータであることを示す指標であり、２行目〜４行目の「Dst: 3.3.3.3」，「ACC3/PASS3」，「FTP_Command」なるデータは、このデータパケットＤＰ３０内の「Dst Addr: 3.3.3.3」，「ACC3/PASS3」，「FTP_Command」を抜き出したものである。同様に、DATA2の下欄５〜８行目には、データパケットＤＰ４０内の必要なデータが抜き出されている。
【００７２】
結局、図５に示す圧縮データDATA1，DATA2は、図３に示すデータパケットＤＰ１０〜ＤＰ５０内の必要なデータのみを抜き出したものになっており、データパケットＤＰ１０〜ＤＰ５０をそのまま送信する代わりに、圧縮データDATA1，DATA2を送信すれば、送信容量を低減させることができる。
【００７３】
この図５に示す圧縮データDATA1，DATA2は、車両が通信ポイントＰ１、Ｐ２またはＰ３に到着した時点で経路上通信手段２１、２２または２３へと送信され、代理サーバ装置３０へと伝送される。このような圧縮データDATA1，DATA2を受信した代理サーバ装置３０内では、これら各圧縮データDATA1，DATA2の内容に基づいて、図６に示すような対応表ＴＢ２を作成するとともに、伸張処理により、図７に示すようなデータパケットＤＰ１１〜ＤＰ５１を作成する処理が実行される。ここで、図６に示す対応表ＴＢ２は、ＮＡＴ処理に必要なデータをテーブルにしたものであり、図５に示す各情報に、送信元のポート番号を付加することにより得られるものである。たとえば、この図６の対応表ＴＢ２の左欄１行目の「Src Port#: xx1」は、以下のデータが、「xx1」なる送信元ポート番号に関連するデータであることを示しており、２行目の「車両ID: A」なるデータは、車両Ａから送信されるデータパケットに関するデータであることを示し、３〜４行目の「Sequence#:0001」および「Seq#: 12345」なるデータは、関連するシリアル番号を示し、５行目の「Dst: 1.1.1.1」なるデータは、送信先のグローバルＩＰアドレスが「1.1.1.1」であることを示している。以下、同様である。
【００７４】
一方、図７に示すデータパケットＤＰ１１〜ＤＰ５１は、図５に示す圧縮データDATA1，DATA2および図６に示す対応表ＴＢ２のポート番号に基づいて作成することができる。この図７に示す伸張処理後のデータパケットＤＰ１１〜ＤＰ５１の内容は、図３に示す圧縮処理前のデータパケットＤＰ１０〜ＤＰ５０の内容とほぼ同様であるが、送信元のアドレスが、プライベートＩＰアドレスからグローバルＩＰアドレスに変更されている点と、送信元のポート番号が付加されている点が異なっている。これは、代理サーバ装置３０におけるＮＡＴ処理の結果である。たとえば、図３のデータパケットＤＰ１０では、送信元のアドレスとして「Src Addr: 10.0.1.1」なるプライベートＩＰアドレスが記載されていたが、図７のデータパケットＤＰ１１では、送信元のアドレスとして「Src Addr: 1.0.0.99」なるグローバルＩＰアドレス（代理サーバ装置３０自身のアドレス）が記載されている。このように、代理サーバ装置３０のＮＡＴ機能により、データパケットＤＰ１１〜ＤＰ５１の送信元のアドレスは、すべて「Addr: 1.0.0.99」なる代理サーバ装置３０自身のグローバルＩＰアドレスに変更されることになる。なお、この図７においても、一重枠のデータパケットＤＰ１１，ＤＰ２１，ＤＰ５１は、メールサーバに宛てた電子メールの受信命令を含むデータパケットであり、二重枠のデータパケットＤＰ３１，ＤＰ４１は、ファイルサーバに宛てたダウンロード命令を含むデータパケットである。
【００７５】
このように、代理サーバ装置３０のＮＡＴ機能により、端末装置Ｔ１〜Ｔ５のアドレスはすべて「Addr: 1.0.0.99」なる代理サーバ装置３０自身のアドレスに変更されてしまう。そこで、送信元のポート番号を利用して、送信元の端末装置Ｔ１〜Ｔ５を識別する必要がある。図７に示すデータパケットＤＰ１１〜ＤＰ５１の４行目に記載された「Src Port#:xx1〜xx5」は、このようなポート番号を示すものである。
【００７６】
かくして、外部のサーバ装置５１〜５５には、それぞれ図７に示すようなデータパケットＤＰ１１〜ＤＰ５１が届けられることになる。これに応じて、外部のサーバ装置５１〜５５からは、図８に示すようなデータパケットＤＰ１２〜ＤＰ５２が返信される。ここで、一重枠のデータパケットＤＰ１２，ＤＰ２２，ＤＰ５２は、各メールサーバからのメールの内容を示すデータを含んだ返信であり、二重枠のデータパケットＤＰ３２，ＤＰ４２は、ファイルサーバからのダウンロード対象ファイルの内容を示すデータを含んだ返信である。たとえば、データパケットＤＰ１２の１行目の「Dst Addr: 1.0.0.99」なるデータは、送信先のＩＰアドレスが「1.0.0.99」（代理サーバ装置３０のグローバルＩＰアドレス）であることを示し、２行目の「Src Addr: 1.1.1.1」なるデータは、送信元のＩＰアドレスが「1.1.1.1」（外部のサーバ装置５１のグローバルＩＰアドレス）であることを示している。これは、図７に示すデータパケットＤＰ１１の送信先と送信元のアドレスを入れ替えたものに他ならない。また、３行目の「Dst Port#: xx1」なるデータは、送信先となる代理サーバ装置３０のポート番号が「xx1」であることを示し、４行目の「Src Port#: 110」なるデータは、送信元となる外部のサーバ装置５１のポート番号が「110」であることを示している。これは、図７に示すデータパケットＤＰ１１の送信先と送信元のポート番号を入れ替えたものに他ならない。更に、５行目の「データ：（メールの内容１）」なるデータは、返信対象となる電子メールの内容を示すデータである。他のデータパケットＤＰ２２〜ＤＰ５２の構成もほぼ同様である。
【００７７】
さて、図８に示すデータパケットＤＰ１２〜ＤＰ５２を受け取った代理サーバ装置３０は、その中の「Dst Port#:」の部分と、図６に示す対応表ＴＢ２中の「Src Port#:」の部分とを対応させることにより、これらが同一の車両Ａ宛のデータパケットであることを認識することができる。もちろん、データパケットＤＰ１２〜ＤＰ５２は、通常、代理サーバ装置３０に対して互いに時間差をもって到着することになるので、代理サーバ装置３０は、到着するデータパケットを一時的に蓄積しておき、ある程度集まった時点で、同一車両宛のデータパケットを集めたデータパケット群を作成し、このデータパケット群をまとめて圧縮する処理を行う。たとえば、図８に示すデータパケットＤＰ１２〜ＤＰ５２がすべて集まったとすると、代理サーバ装置３０は、図６の対応表ＴＢ２を参照しながら、図９に示すような圧縮データDATA3およびDATA4を作成する。
【００７８】
図９に一重枠で示す圧縮データDATA3は、電子メールの受信命令に対する返信情報を含むデータパケットＤＰ１２，ＤＰ２２，ＤＰ５２の内容をまとめたものであり、二重枠で示す圧縮データDATA4は、ファイルのダウンロード命令に対する返信情報を含むデータパケットＤＰ３２，ＤＰ４２の内容をまとめたものである。DATA3の上欄１行目の「車両ID:A」なるデータは、この圧縮データが車両Ａ宛のデータパケット群であることを示し、２行目の「Sequence#:0001」なるデータは、この圧縮データのシリアル番号が「0001」であることを示している。これらのデータは、図６の対応表ＴＢ２を参照することにより得ることができる。また、３行目の「Src Port#: 110」なるデータは、この圧縮データの送信元のポート番号が「110」であることを示しており、データパケットＤＰ１２，ＤＰ２２，ＤＰ５２内の「Src Port#」の情報から得ることができる。DATA3の下欄１行目の「Seq#: 12345」なるデータおよび２行目の「（メールの内容１）」なるデータは、シリアル番号「12345」の返信データが「（メールの内容１）」であることを示す情報であり、以下、シリアル番号「12346」、「12349」についての同様の情報が続くことになる。これらの情報は、図６の対応表ＴＢ２の内容とデータパケットＤＰ１２，ＤＰ２２，ＤＰ５２の内容に基づいて得ることができる。一方、図９に二重枠で示す圧縮データDATA4の構造もほぼ同様である。
【００７９】
こうして、代理サーバ装置３０において作成された圧縮データDATA3、DATA4は、マルチキャストにより、経路上通信手段２１，２２，２３へと送信され、通信ポイントＰ１，Ｐ２，Ｐ３に到来した車両に圧縮状態のまま送信されることになる。これら圧縮データDATA3、DATA4を受信した車両内の車両内通信手段１０は、「車両ＩＤ」の部分を確認し、それが自己宛のデータパケットであるかを認識する。自己宛でなかった場合には、これをそのまま廃棄することになる。自己宛であった場合、すなわち、図９に示す圧縮データDATA3、DATA4を車両Ａが受信した場合は、データパケットの送信時に作成しておいた図４に示す対応表ＴＢ１を参照することにより、これらを伸張する処理を行う。
【００８０】
たとえば、圧縮データDATA3には、シリアル番号「12345」の返信データが「（メールの内容１）」であることを示す情報が含まれているが、対応表ＴＢ１には、シリアル番号「12345」について、送信先アドレス「Dst: 1.1.1.1」、送信元アドレス「Src: 10.0.1.1」が記載されているので、これらのアドレスの送受信を入れ替えることにより、図１０に示すようなデータパケットＤＰ１３を生成することができる。同様の伸張処理により、結局、図１０に示すデータパケットＤＰ１３〜ＤＰ５３が生成され、これらが端末装置Ｔ１〜Ｔ５へと送信されることになる。かくして、各端末装置Ｔ１〜Ｔ５から外部のサーバ装置５１〜５５へと送信されたデータパケットに対して、それぞれ返信となるデータパケットが届くことになる。
【００８１】
以上、本発明を図示する実施形態に基づいて説明したが、本発明はこれらの実施形態に限定されるものではなく、この他にも種々の形態で実施可能である。特に、図３〜図１０に示した実施形態は、あくまでも具体的な実施例の一形態を示すものであり、実際の圧縮方法やデータフォーマットなどは、任意のものを採用してかまわない。
【００８２】
【発明の効果】
以上のとおり、本発明に係る移動体パケット通信システムによれば、高速移動中の車両に搭乗していながら、大容量のデータパケット通信が可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る移動体パケット通信システム１００の基本構成を示すブロック図である。
【図２】プライベートＩＰアドレスとグローバルＩＰアドレスとの変換処理およびデータパケットの圧縮／伸張処理を組み込んだ本発明の実施形態を説明するブロック図である。
【図３】図２に示す端末装置Ｔ１〜Ｔ５で作成されたデータパケットＤＰ１０〜ＤＰ５０の一例を示す図である。
【図４】車両内通信手段１０において、図３に示すデータパケットＤＰ１０〜ＤＰ５０に基づいて作成された対応表ＴＢ１を示す図である。
【図５】車両内通信手段１０において、図３に示すデータパケットＤＰ１０〜ＤＰ５０の情報をデータ圧縮することにより作成された圧縮データDATA1およびDATA2の内容を示す図である。
【図６】代理サーバ装置３０において、図５に示す圧縮データDATA1およびDATA2に基づいて作成された対応表ＴＢ２を示す図である。
【図７】代理サーバ装置３０において、図５に示す圧縮データDATA1およびDATA2を伸張することにより得られるデータパケットＤＰ１１〜ＤＰ５１を示す図である。
【図８】図７に示すデータパケットＤＰ１１〜ＤＰ５１を受信した外部のサーバ装置５１〜５５が、それぞれ返信情報として送信するデータパケットＤＰ１２〜ＤＰ５２を示す図である。
【図９】代理サーバ装置３０において、図８に示すデータパケットＤＰ１２〜ＤＰ５２の情報をデータ圧縮することにより作成された圧縮データDATA3およびDATA4の内容を示す図である。
【図１０】車両内通信手段１０において、図９に示す圧縮データDATA3およびDATA4を伸張することにより得られるデータパケットＤＰ１３〜ＤＰ５３を示す図である。
【符号の説明】
１０…車両内通信手段
２１，２２，２３，２ｘ…経路上通信手段
３０…代理サーバ装置
４０…インターネット
５１〜５５…外部のサーバ装置
１００…移動体パケット通信システム
Ａ…車両
DATA1〜DATA4…圧縮データ
ＤＰ１０〜ＤＰ５０，ＤＰ１１〜ＤＰ５１，ＤＰ１２〜ＤＰ５２，ＤＰ１３〜ＤＰ５３…データパケット
Ｌ…運行経路
Ｐ１〜Ｐ３…通信ポイント
Ｔ，Ｔ１〜Ｔ５…端末装置
ＴＢ１，ＴＢ２…対応表
Claims (10)
- 車両とともに移動中の端末装置と外部のサーバ装置との間でパケット通信を行うためのシステムであって、
車両内に設置された車両内通信手段と、
車両が停車するか、または、通常の運行速度よりも低い速度で通過することが予定されている運行経路上の複数の通信ポイントにそれぞれ設置された複数の経路上通信手段と、
前記経路上通信手段に対して接続され、外部のサーバ装置との間でネットワークを介してデータパケットのやりとりを行う機能をもった代理サーバ装置と、
を備え、
前記車両内通信手段は、車両内に存在する端末装置との間で無線によりデータパケットの送受信を行う車内通信機能と、車両が通信ポイント付近に停車している状態、もしくは、車両が通信ポイント付近を通常の運行速度よりも低い速度で通過している状態において、当該通信ポイントに設置された経路上通信手段との間で無線によりデータパケットの送受信を行う車外通信機能と、を有し、前記車内通信機能により端末装置からデータパケットを受信した場合に、このデータパケットを前記車外通信機能が実行可能になるまで一時的に保管し、前記車外通信機能が実行可能になったときに、一時的に保管していたデータパケットを経路上通信手段へと送信する処理を実行し、経路上通信手段からデータパケットを受信した場合に、このデータパケットを前記車内通信機能により宛先となる端末装置へ送信する処理を実行し、
前記経路上通信手段は、前記車両内通信手段からデータパケットを受信した場合に、このデータパケットを前記代理サーバ装置へと送信する処理を実行し、前記代理サーバ装置から所定の端末装置宛のデータパケットを受信した場合に、このデータパケットを、自己が設置された通信ポイント付近に到来した車両内に設置された車両内通信手段へと送信する処理を実行し、
前記代理サーバ装置は、前記経路上通信手段から受信したデータパケットをネットワークを介して外部のサーバ装置へと送信する処理を実行するとともに、外部のサーバ装置からネットワークを介して受信したデータパケットを、複数の通信ポイントにそれぞれ設置された複数の経路上通信手段へと送信する処理を実行し、
前記車両内通信手段は、車両内に存在する端末装置から受信したデータパケットに対してデータ圧縮を行い、前記代理サーバ装置は、圧縮されたデータパケットを伸張する処理を行い、前記車両内通信手段から前記代理サーバ装置へと転送されるデータパケットが圧縮された状態になるようにし、
前記代理サーバ装置は、外部のサーバ装置から受信したデータパケットに対してデータ圧縮を行い、前記車両内通信手段は、圧縮されたデータパケットを伸張する処理を行い、前記代理サーバ装置から前記車両内通信手段へと転送されるデータパケットが圧縮された状態になるようにし、
前記車両内通信手段は、更に、前記端末装置から外部のサーバ装置に対して、所定時間内の返信を要求するデータパケットの送信が行われたときには、外部のサーバ装置に代わって返信を行う代理返信機能を有することを特徴とする移動体パケット通信システム。 - 請求項１に記載の移動体パケット通信システムにおいて、
所定の路線に沿って走行する列車の車両内に車両内通信手段を設置し、この路線上の駅に通信ポイントを定義して経路上通信手段を設置したことを特徴とする移動体パケット通信システム。 - 請求項１に記載の移動体パケット通信システムにおいて、
所定の道路上を走行する自動車の車両内に車両内通信手段を設置し、この道路上の交差点、料金所、もしくはパーキングエリアに通信ポイントを定義して経路上通信手段を設置したことを特徴とする移動体パケット通信システム。 - 請求項１〜３のいずれかに記載の移動体パケット通信システムにおいて、
車両内通信手段にＤＨＣＰの機能をもたせ、この機能により車両内に存在する端末装置に対してプライベートＩＰアドレスを付与し、代理サーバ装置にＮＡＴの機能をもたせ、この機能によりプライベートＩＰアドレスとグローバルＩＰアドレスとの変換を行わせ、システム内部ではプライベートＩＰアドレスを用いたパケット通信が行われ、外部のサーバ装置との間ではグローバルＩＰアドレスを用いたパケット通信が行われるようにしたことを特徴とする移動体パケット通信システム。 - 請求項１〜４のいずれかに記載の移動体パケット通信システムにおいて、
代理サーバ装置が、外部のサーバ装置からネットワークを介して受信したデータパケットを、当該データパケットの宛先となる端末装置が存在する車両が所定時間内に到来する可能性のある所定の地理的範囲内の複数の通信ポイントにそれぞれ設置された経路上通信手段へと送信する処理を実行することを特徴とする移動体パケット通信システム。 - 請求項１〜５のいずれかに記載の移動体パケット通信システムにおいて、
代理サーバ装置が、個々の車両宛のデータパケットごとに、それぞれ別個のパケット群を構成し、構成した各パケット群のそれぞれを複数の経路上通信手段へと送信する処理を行い、
車両内通信手段が、所定の経路上通信手段から自己車両宛のパケット群を受信したときに、当該パケット群の受領を確認する受領確認情報を前記所定の経路上通信手段に対して送信する処理を行い、
各経路上通信手段が、代理サーバ装置から受信したデータパケットを、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両内に設置された車両内通信手段へと繰り返し送信する処理を実行し、かつ、いずれか１つの経路上通信手段が特定のパケット群についての受領確認情報を受信した場合に、この特定のパケット群と同一のパケット群を廃棄する処理を実行することを特徴とする移動体パケット通信システム。 - 請求項１〜５のいずれかに記載の移動体パケット通信システムにおいて、
各経路上通信手段が、代理サーバ装置から受信したデータパケットを、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両内に設置された車両内通信手段へと繰り返し送信する処理を実行し、かつ、代理サーバ装置から受信した後に所定の時間が経過したデータパケットについては、これを廃棄する処理を実行することを特徴とする移動体パケット通信システム。 - 請求項１〜５のいずれかに記載の移動体パケット通信システムにおいて、
各経路上通信手段が、代理サーバ装置から受信したデータパケットを、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両内に設置された車両内通信手段へと繰り返し送信する処理を実行し、かつ、送信繰り返し回数が所定回数に達したデータパケットについては、これを廃棄する処理を実行することを特徴とする移動体パケット通信システム。 - 請求項１〜５のいずれかに記載の移動体パケット通信システムにおいて、
各経路上通信手段が、それぞれの通信ポイント付近に車両が到来するたびに、到来した車両を特定する処理を実行し、代理サーバ装置から受信したデータパケットのうち、特定された車両宛のデータパケットのみを選択し、この選択したデータパケットを到来した車両内に設置された車両内通信手段へと送信した後にこれを廃棄する処理を実行し、かつ、他の経路上通信手段によって車両への送信が完了したパケットと同一のパケットについては、これを廃棄する処理を実行することを特徴とする移動体パケット通信システム。 - 請求項１〜９のいずれかに記載の移動体パケット通信システムにおいて、
車両内通信手段が、
端末装置から外部のメールサーバ装置に対して、電子メールの第１の受信命令が送信さ れた場合に、車外通信機能が実行可能になるまで前記第１の受信命令を一時的に保管するとともに、前記メールサーバ装置に代わって、前記端末装置に対して受信すべき電子メールがないことを示す疑似的な返信を行い、
前記車外通信機能が実行可能になったときに、保管していた前記第１の受信命令を前記メールサーバ装置へと送信する処理を実行し、前記メールサーバ装置から前記第１の受信命令に応じて正規の返信が戻ってきた場合に、前記正規の返信を一時的に保管し、
前記端末装置から前記メールサーバ装置に対して、電子メールの第２の受信命令が送信された場合に、前記第１の受信命令に応じて戻ってきた前記正規の返信が保管されていたら、前記第２の受信命令を前記メールサーバ装置へと送信することなしに、前記端末装置に対して、前記正規の返信を前記第２の受信命令に対する前記メールサーバ装置からの返信であるかのように送信する代理返信機能を有することを特徴とする移動体パケット通信システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002272571A JP4072031B2 (ja) | 2002-09-19 | 2002-09-19 | 移動体パケット通信システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002272571A JP4072031B2 (ja) | 2002-09-19 | 2002-09-19 | 移動体パケット通信システム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004112380A JP2004112380A (ja) | 2004-04-08 |
| JP2004112380A5 JP2004112380A5 (ja) | 2005-11-10 |
| JP4072031B2 true JP4072031B2 (ja) | 2008-04-02 |
Family
ID=32269557
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002272571A Expired - Fee Related JP4072031B2 (ja) | 2002-09-19 | 2002-09-19 | 移動体パケット通信システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4072031B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101124750B (zh) * | 2005-03-18 | 2012-03-21 | 富士通株式会社 | 运送旅客以及货物的手段中的通信系统 |
| JP4943286B2 (ja) * | 2007-09-28 | 2012-05-30 | ジェイアール東日本メカトロニクス株式会社 | 座席確保システム、車上サーバ装置、車掌端末装置及び読み出し装置 |
| GB2463009B (en) * | 2008-08-26 | 2010-12-08 | Nomad Spectrum Ltd | Mobile data communication |
| JP2010067280A (ja) * | 2009-12-21 | 2010-03-25 | Fuji Xerox Co Ltd | ドキュメント配信装置 |
| WO2012110771A2 (en) * | 2011-02-19 | 2012-08-23 | Nomad Spectrum Limited | Mobile data communication |
| KR101544564B1 (ko) | 2013-07-30 | 2015-08-17 | 주식회사 제노보 | 디지털 운행기록장치 관리 서버의 ip주소 할당방법 및 차량 운행정보 전송방법 |
| GB2523394B (en) | 2014-02-25 | 2020-10-28 | Mclaren Applied Tech Ltd | Vehicle data communication |
| US20150289148A1 (en) * | 2014-04-02 | 2015-10-08 | Nomad Spectrum Limited | Content delivery architecture |
| JP6489865B2 (ja) * | 2015-02-23 | 2019-03-27 | 学校法人早稲田大学 | データ送信システム及び方法 |
-
2002
- 2002-09-19 JP JP2002272571A patent/JP4072031B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004112380A (ja) | 2004-04-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5327864B2 (ja) | 通信ネットワークシステム及びネットワーク通信方法 | |
| Ott et al. | The" Drive-thru" architecture: WLAN-based internet access on the road | |
| EP2335395B1 (en) | Method of providing data communication to a vehicle | |
| US20050169206A1 (en) | Relay apparatus, communication system and relay method | |
| US8000338B2 (en) | Methods and apparatus for continuous connectivity between mobile device and network using dynamic connection spreading | |
| WO2005110006A2 (en) | Method and arrangement device relating to communication network | |
| JP4072031B2 (ja) | 移動体パケット通信システム | |
| JP4692021B2 (ja) | 移動体の通信方法 | |
| Yamamura et al. | Virtual segment: Store–carry–forward relay-based support for wide-area non-real-time data exchange | |
| Pareit et al. | A novel network architecture for train-to-wayside communication with quality of service over heterogeneous wireless networks | |
| JP2004038242A (ja) | 電車内ダウンロードサービスシステム | |
| CN100433717C (zh) | 一种切换过程中数据传输的方法 | |
| JP2007533272A (ja) | グローバルインターネットプロトコルプレフィックス番号モビリティ | |
| US20100014445A1 (en) | Address updating method, corresponding mobile terminal and node | |
| CN103582009B (zh) | 数据传输方法及宿主基站及数据网络系统 | |
| Ernst et al. | CVIS: CALM proof of concept preliminary results | |
| JP4232500B2 (ja) | 通信端末 | |
| Gass et al. | Eliminating backhaul bottlenecks for opportunistically encountered Wi-Fi hotspots | |
| KR20030088730A (ko) | 무선 중계기를 이용한 지하철에서의 공중 무선랜 서비스제공 장치 및 방법 | |
| JP4867756B2 (ja) | 電子メール転送システム、中継局、及び、移動体通信網 | |
| KR100455136B1 (ko) | 무선 인터넷 서비스 방법 | |
| Sen et al. | Design and evaluation of low-cost network architecture for persistent wifi connectivity in trains | |
| Yu et al. | Deep reinforcement learning-based fountain coding for concurrent multipath transfer in high-speed railway networks | |
| CN113055820B (zh) | 数据存储方法、装置、系统和存储介质 | |
| Jeong et al. | Toms: Tcp context migration scheme for efficient data services in vehicular networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050914 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050914 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070710 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070807 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071009 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20071120 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080108 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080118 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110125 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |