(57)【特許請求の範囲】
【請求項１】
移動体側フレーム制御装置を有する移動体が、第一の地上側フレーム制御装置を備える第一の無線エリアから、第二の地上側フレーム制御装置を備える第二の無線エリアへ移動する場合の移動体の通信方法において、
前記移動体が、上りフレームにその順番である通信番号を付与した拡張通信フレームを一定数記憶し、前記拡張通信フレームを前記第一の無線エリアに送出するステップと、
前記第一の地上側フレーム制御装置が、前記拡張通信フレームを前記移動体から受信するたびに、前記拡張通信フレームを前記第二の地上側フレーム制御装置に送出するステップと、
前記第二の地上側フレーム制御装置が、前記第二の無線エリアに到達した前記移動体の前記移動体側フレーム制御装置から拡張通信フレームを受信し、前記拡張通信フレームから通信番号を抽出して、前記通信番号を前記第一の地上側フレーム制御装置から受信した拡張通信フレームに含まれる通信番号と比較するステップと、
前記比較の結果、前記移動体側フレーム制御装置から受信した拡張通信フレームに含まれる通信番号と、前記第一の地上側フレーム制御装置から受信した拡張通信フレームに含まれる通信番号とが連続していない場合は、前記第二の地上側フレーム制御装置が、損失した通信フレームの再送信を前記移動体の移動体側フレーム制御装置に要求するステップと、
を含むことを特徴とする移動体の通信方法。
【請求項２】
移動体側フレーム制御装置を有する移動体が、第一の地上側フレーム制御装置を備える第一の無線エリアから、第二の地上側フレーム制御装置を備える第二の無線エリアへ移動する場合の移動体の通信方法において、
前記第一の地上側フレーム制御装置が、下りフレームにその順番である通信番号を付与した拡張通信フレームを前記移動体に送信するたびに、前記拡張通信フレームを前記第二の地上側フレーム制御装置に送出するステップと、
前記第二の地上側フレーム制御装置が、前記第一の地上側フレーム制御装置から受信した拡張通信フレームを一定数記憶するステップと、
前記移動体が前記第二の無線エリアに到達した際、前記第二の地上側フレーム制御装置が、前記移動体の前記移動体側フレーム制御装置に拡張通信フレームを送信し、前記移動体の前記移動体側フレーム制御装置が、前記拡張通信フレームに含まれる通信番号を抽出して、前記通信番号を、前記第一の地上側フレーム制御装置から受信した拡張通信フレームに含まれる通信番号と比較するステップと、
前記比較の結果、前記第二の地上側フレーム制御装置から受信した拡張通信フレームに含まれる通信番号と、前記第一の地上側フレーム制御装置から受信した拡張通信フレームに含まれる通信番号とが連続していない場合は、前記移動体が、損失した拡張通信フレームの再送信を前記第二の地上側フレーム制御装置に要求するステップと、
を含むことを特徴とする移動体の通信方法。
【請求項３】
前記第二の地上側フレーム制御装置は、前記拡張通信フレームを受け取り、前記拡張通信フレームの通信番号を削除して基幹ネットワークに送出することを特徴とする、請求項１に記載の移動体の通信方法。
【請求項４】
前記第二の地上側フレーム制御装置は、前記拡張通信フレームを受け取って保持することを特徴とする、請求項１に記載の移動体の通信方法。
【請求項５】
第二の無線エリアにおいて、前記移動体側フレーム制御装置は、前記拡張通信フレームを受け取って保持することを特徴とする、請求項２に記載の移動体の通信方法。
【請求項６】
前記損失した拡張通信フレームを特定した移動体は、前記損失した拡張通信フレームの再送を要求し、第一の無線エリアから第二の無線エリアに向けて送出された拡張通信フレームの複製を受け取ることを特徴とする、請求項２に記載の移動体の通信方法。
【請求項７】
前記移動体は、前記拡張通信フレームが分割されないように前記拡張通信フレームに通信番号を付与することを特徴とする、請求項１に記載の移動体の通信方法。
【請求項８】
前記第二の地上側制御装置は、前記拡張通信フレームが分割されないように前記拡張通信フレームに通信番号を付与することを特徴とする、請求項２に記載の移動体の通信方法。
【請求項９】
前記移動体は、上りフレームに通信番号を付与した拡張通信フレームを、前記第二の無線エリアに向けて送出する前に分割することを特徴とする、請求項１に記載の移動体の通信方法。
【請求項１０】
前記第二の地上側制御装置は、下りフレームに通信番号を付与した拡張通信フレームを、前記移動体に向けて送出する前に分割することを特徴とする、請求項２に記載の移動体の通信方法。
【請求項１１】
前記第二の無線エリアは、前記第一の無線エリアに隣接する無線エリアであることを特徴とする、請求項１または２に記載の移動体の通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、高速で移動する移動体に対して、安定した通信環境を提供する通信方法に関する。
【背景技術】
【０００２】
ＩＰネットワークにおいて、移動しつづける通信装置（移動ホスト）が、無線エリア等のネットワークを変更して、所属するサブネットが変更になった場合においても、連続したＩＰ通信を提供する技術として、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）より  モバイルＩＰ（ＲＦＣ２００２）方式が提案されている。
【０００３】
図１を用いて、モバイルＩＰ方式について概説する。
【０００４】
モバイルＩＰ方式とは、複数の無線ネットワーク間で端末を移動させても、ＩＰアドレスを変更せずに、連続的なＩＰ通信を可能とする業界標準プロトコルであり、モバイルＩＰを用いることで、車両移動中に無線エリアを移動した場合においても、原則としてＩＰ通信を使ったサービスは中断されなくなる。
【０００５】
モバイルＩＰ方式では、列車等に搭載されるモバイルルータ（以後ＭＲと称す）から、無線エリアに進入した旨の連絡を受けたフォーリンエージェントルータ（以後ＦＡと称す）が、その情報をホームエージェントルータ（以後ＨＡと称す）に通知し、ＨＡはＦＡに対して、ＦＡはＭＲに対してＩＰパケットを運ぶ為のトンネル（ＩＰトンネル）を生成することで、移動中の車上のＩＰ通信機器（ＰＣ、サーバ等）に対してＩＰパケットを転送することを可能とするものであり、ＭＲを搭載した車両が異なる無線エリアに進入する度に、このＩＰトンネルが新たに作成される、あるいはすでに作成されたＩＰトンネルを再利用されることになる。
【０００６】
ＨＡは、ＭＲに属するネットワークまたはホストのＩＰアドレスを、ルーティングプロトコルを使って常にアドバタイズ（広告）している為、ＭＲに属するネットワークまたはホスト宛てのＩＰパケットは、先ずＨＡに到着することになる。ＨＡは前記に説明したＩＰトンネルを使って、当該ＩＰパケットをＦＡ経由でＭＲに転送する。ＭＲでトンネルから開放されたＩＰパケットは、車両等の目的のネットワークまたはホストに配送される。
【０００７】
また、ＭＲに属するネットワークまたはホストから送信されるＩＰパケットは、ＭＲを経由して、地上のＩＰネットワークに届けられ、その後は、通常のＩＰルーティングによって、目的のホストに転送される。
【０００８】
モバイルＩＰ方式の問題点としては、移動ホストがネットワークを移動する度にホームエージェントとの間で所定の手続きを実行する必要があるため、ホームエージェントから論理的または物理的な距離が遠い場合には、ＩＰパケットの転送先の切替（以後、ハンドオーバと称す）の所要時間が増大する点が挙げられる。
【０００９】
従って、ネットワークを移動した際に必要な手順が完了するまでは、移動ホストはＩＰフレームを受信することができず、リアルタイムな通信の連続性、例えばＶｏＩＰ等における通話の連続性が保障されないという問題が発生する。
【００１０】
特許文献１記載の発明によれば、上記問題を解決するために、移動ホストにマルチキャストアドレスを割り当て、マルチキャストフレームをデータ送信に利用することで、当該ハンドオーバに対応する方法に関して開示されている。マルチキャスト通信とは、特定多数のホストに同一のデータを同報送信するものであり、マルチキャストアドレスは、多数のホストが共通に利用できるアドレスである。多数のホストが共通にアドレス利用できるということは、移動ホストのサブネットの変更を伴う移動が生じた場合でも、マルチキャストＩＰアドレスは、移動の前後のサブネット間で共通に使用できるということになり、移動ホストは移動中に連続したデータ受信を行なうことができることになる。
【００１１】
また、前述のハンドオーバーの問題は、特に移動ホストの速度が高速になるに応じて、移動ホストがすでにある無線エリアをすでに移動してしまっているのにもかかわらず、移動前の無線エリアに届いてしまう通信フレームが増大する問題や、無線エリアの通過時間が早くなるため、前記のような状況が顕著に発生するという問題点が発生する。
【００１２】
この問題点を回避する為に、非特許文献１によれば、移動ホストは、移動前に移動先アドレスを予め設定し、移動直前のリンクのアクセスルータに自ら登録することによって、移動ホストが移動してからホームエージェントに登録が行われるまでの間、移動前のアクセスルータは、移動先のアクセスルータにフレームを転送し、これによってハンドオーバー時のフレームロストを回避するという方式が開示されている。
【００１３】
また、特許文献１の上記方式を用いることで、モバイルＩＰのハンドオーバー時のパケットロストを減らすことはできるるものの、完全に回避することはできないことから、非特許文献２では、複数インターフェースを具備することによって、２つ以上の無線エリアの通信を常に維持することで、フレーム落ちが発生しないモバイルＩＰを実現する方式について開示されている。
【００１４】
【特許文献１】特開２００３−３７６２６号
【特許文献２】米国特許公報５,９０１,００９号
【非特許文献１】Ｆａｓｔ  Ｈａｎｄｏｖｅｒｓ  ｆｏｒ  Ｍｏｂｉｌｅ  ＩＰ（ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅＩＰｆａｓｔ−ｍＩＰｖ６−０８．ｔｘｔ）
【非特許文献２】「Ｍｏｂｉｌｅ  ＩＰｖ６ハンドオーバにおいてフレーム欠落をさせない機構の設計と実装」学術刊行物情処研報Ｖｏｌ．２００３，  Ｎｏ．６７  ＩＳＳＮ  ０９１９−６０７２
【発明の開示】
【発明が解決しようとする課題】
【００１５】
しかしながら、特許文献１が開示するマルチキャストを使った方法は、マルチキャストＩＰを使うアプリケーションに対しては有効であるが、それ以外のアプリケーションで使用することは不可能である。
【００１６】
特に、ＩＰプロトコルの使用を前提とする上位のコネクション型プロトコルであるＴＣＰを使用することは困難である。例えば、セルが重複するエリアにおいては、同一のＩＰパケットを２つ受ける可能性があるが、このような場合、二つ目以降のフレームの廃棄処理を行なわない場合、ＴＣＰでは通信異常が発生したものとして閉塞処理を行い、サービスが停止してしまう。
【００１７】
次に、中継ホストに対して、セル内で有効な移動ホストのアドレスを通知し、その登録情報を変更することによって、中継ホストからの転送を行う旨の手段が開示されているが、この方法によれば、登録情報が変更されるまでの間、ＩＰパケットが必要なセルに配送されず、結果として移動ホストはＩＰパケットを受信できない状態が発生することになる。
【００１８】
さらに、非特許文献１が開示する方式によれば、移動先のリンクに接続してから移動登録を行うまでの間に、ハンドオーバーの高速化を実現しているが、無線リンクから一旦切断して移動先のリンクに接続するので、依然としてネットワークから切断されている状態が存在するため、ＩＰパケットのロストが発生する。
【００１９】
通常、このようなＩＰパケットのロストに関しては、ＴＣＰなどの上位プロトコルがＩＰフレームの再送要求を行うことによって通信停止を回避するが、この場合再送フレームがネットワークの帯域等の資源を消費するという問題が発生する。また、ＴＣＰには、スロースタートというＩＰパケット転送アルゴリズムが実装されており、これは、ＩＰパケットロストを検知すると、ネットワークで輻輳が発生したと考え、通信速度を最低速度まで落して、その後徐々に通信速度を上げていく通信アルゴリズムである。非特許文献１の方式においても、ＩＰパケットのロストは、ハンドオーバー時ごとに発生するため、その度に通信速度の低下を招き、結果としてモバイルＩＰ環境では、効率のよい通信ができなくなる。
【００２０】
さらに、非特許文献２が開示する方法によれば、複数のネットワークインタフェースカードを用いることで、ＩＰパケットロストを回避することが可能ではあるが、当該方式を実施するためには、複数のインターフェースを必要とすることから、コストが高価になるという問題がある。また、通信環境においても、複数のネットワークインタフェースカードが有効に機能する為に、隣接する無線エリア間で、異なるネットワーク媒体、または異なる無線周波数などを使用する必要が生じ、そのコストも高価なものになるという問題がある。
【００２１】
また、非特許文献２は、異なる２つの無線エリアの無線リンクを同時に維持することで、通信の連続性について開示しているものの、２つ以上の無線エリアが重なっていることを前提とするものであるが、実際の環境では、無線エリア同士の干渉による混信によって、あるいは電波の状況等によって、事実上無線エリア間が不感帯となることがあり、このような環境では、非特許文献２の方式を用いたとしても、モバイルＩＰはＩＰ通信の連続性を保証することは困難である。
【００２２】
また、特許文献１、非特許文献１または２においては、それぞれの無線エリアが隣接関係となっているが、ある既存の無線エリアの中に、新たに別の無線エリアが追加されることによって、無線エリアの中に別の無線エリアが完全に包含されてしまうような事例には対応できない。
【００２３】
例えば、帯域が２Ｍｂｐｓでありその有効範囲が２０ｋｍ長に及ぶような第一の無線通信手段に対して、帯域が１００Ｍｂｐｓの広帯域ではあるがその有効範囲が１００ｍ足らずのような別の第二の無線通信手段が追加されたような場合である。
【００２４】
さらに、前記の例においては、第一の無線通信手段と、第二の無線通信手段が、異なるの無線通信手段である場合においては、通信フレームがどちらの経路から転送されているかを管理する必要あり、また連続するフレームが別の通信手段を介して転送された場合、そのフレームの着順制御を行うことは困難となる。
【００２５】
さらに、前記の例においては、第一の無線通信手段と、第二の無線通信手段が、同種類の無線通信手段である場合において、上記の問題に加えて、ある既存の無線エリアの中に追加された新たに別の無線エリアを、移動体通信手段側で認識できた場合においても、その無線エリアを離脱したことを認識するまでの期間に、フレームロスが発生するという問題がある。
【００２６】
また、無線エリアが離れていて、その離れている部分を補完する目的で、新しい無線通信手段を追加したという場合においても、問題が発生する場合がある。例えば、気温や湿度、晴天、雨天のような外的要因や、経年劣化、当該無線通信手段を利用している移動体の速度などによって、無線通信手段の有効範囲は変動し続けるからである。このような場合、当初予定していた補完が目的を果たさず、隣接ゾーンの間に不感帯が発生したり、前述したような包含関係の場合になってしまう場合もありえる。
【課題を解決するための手段】
【００２７】
本発明においては、無線エリアが重なっていないケースの態様として、（１）実際に無線ゾーンが物理的に離れているケース、（２）無線通信方式の性質上、新しい無線エリアに入った時に、古い無線エリアの無線リンクを廃棄し、新しい無線リンクを構築するケース、（３）無線エリア同士の干渉による混信によって、あるいは電波の状況等によって、事実上無線エリア間が不感帯となる場所が生じるケースを含むものとする。
【００２８】
また、便宜上、移動ホストから、当該移動ホストと通信を行うホストに向って転送されるフレームを「上りフレーム」、その逆向きに転送されるフレームを「下りフレーム」と呼ぶこととする。また、無線エリアを構成する無線通信用の基地局基地局を、「基地局」と呼ぶこととする。本発明においては、移動中のホスト、または１つ以上のホストを伴って移動するネットワークから送受信される第一の無線エリアで取得された通信フレームを、当該ホストまたはネットワークの移動している方向に存在する第二の無線エリアに転送する手段を提供し、当該第二の無線エリアに転送された通信フレームを、当該ホストまたはネットワークが当該第二の無線エリアに入った時に、当該ホストまたはネットワークに当該通信フレームの転送を行う手段を提供する。
【００２９】
また、本発明においては、当該第二の無線エリアに転送された通信フレームを、当該ホストまたはネットワークが当該第二の無線エリアに入った場合に、当該ホストまたはネットワークに当該通信フレームを転送する際に、当該通信フレームを当該第二の無線エリアを経由して転送されたように当該通信フレームの内容を書き換える手段を提供し、さらに、当該第二の無線エリアに転送された通信フレームを、当該ホストまたはネットワークが当該第二の無線エリアに入っていない場合に、当該通信フレームを格納または廃棄する手段を提供する。
【００３０】
さらに、本発明においては、当該無線ネットワークを含むネットワークの範囲に通信パケットを入れる前に、当該通信フレーム長を変更し、または拡張し、またはフレームを２つ以上に分割し、当該通信フレームを制御するための情報を付与する領域を確保し、当該領域に当該制御情報を付与した新たなフレームを作成し、当該無線ネットワークを含むネットワークの範囲から通信フレームを出す前に、当該領域に付与した当該情報を取得し、当該通信フレームを制御するための情報を付与した領域を解放し、当該通信フレーム長を当該無線ネットワークを含むネットワークの範囲に通信フレームを入れる前の状態に変更する手段を提供する。
【００３１】
具体的には、当該無線ネットワークを含むネットワークの範囲に通信フレームを入れる前に通信フレームを送出する順番である通し番号を付与し、当該無線ネットワークを含むネットワークの範囲から通信フレームを出す前に当該通番情報を廃棄する手段を提供する。
【００３２】
さらに、本発明においては、第一の無線エリアから、第二の無線エリアに移動を行った際に、第一の無線エリアにおいて当該通番情報を廃棄する前に取得した第一の通番の値と、第二の無線エリアにおいて当該通番情報を廃棄する前に取得した第二の通番の値とを比較することによって、第一の無線エリアから、第二の無線エリアに移動を行った際に損失した通信フレームを特定し、具体的には、当該第一の無線エリアに到達した通信フレームを、当該第二の無線エリアに転送することで実現する。
【００３３】
さらに本発明においては、第一の無線エリアから、第二の無線エリアに移動を行った際に、第一の無線エリアにおいて当該無線ネットワークを含むネットワークの範囲に通信パケットを入れる前に通信フレームに付与した通番の番号を、第二の無線エリアにおいて当該無線ネットワークを含むネットワークの範囲に通信フレームを入れる前に当該通信パケットに付与する通番の番号として引継ぐ手段を提供し、当該無線ネットワークを含むネットワークの範囲に通信フレームを入れる前に、常に当該通信フレームのうち、最新の通信フレームの複製を一定数確保しておき、特定された損失した通信フレームの通番の通知を受けて、当該損失した通信フレームを再送する手段を提供するものである。
【００３４】
さらに本発明においては、第一の無線エリアから、当該第一の無線エリアに包含されている第二の無線エリアに移動を行った際に、第二の無線エリアが提供する通信品質等の情報を勘案して、当該第二の無線エリアに通信手段を切り替える手段を提供する、または、当該第一の通信手段と、当該第二の通信手段の両方を用いて通信を継続する手段を提供するものである。
【００３５】
さらに本発明においては、第一の無線エリアと第二の無線エリアに、第三の無線エリアを追加する場合に、当該第一、第二および第三の無線基地局の位置情報、または移動体の位置情報と進行方向を用いて、第一の無線エリアで取得された通信フレームを転送する無線エリアを決定する手段を提供するものである。
【発明の効果】
【００３６】
本発明によれば、ハンドオーバ時の上りフレームと下りフレームのロストを共に回避し、さらにハンドオーバ時に発生するフレーム到着遅延を無くすことが可能となる。特に、移動ホストが高速に移動している場合においても、安定したＩＰ通信の連続性を保証することが可能となる。
【００３７】
また、本発明によれば、複数のネットワークインタフェースカードを用いないで、１つのネットワークインタフェースカードによる、モバイルＩＰの連続通信を実現する手段を提供することが可能となる。
【００３８】
また、本発明によれば、無線エリアの中に無線エリアを包含するような通信環境、または無線エリアを段階的に追加していくような場合においても、前記の安定したＩＰ通信の連続性を保証するモバイルＩＰ通信を提供することが可能となる。
【発明を実施するための最良の形態】
【００３９】
以下に、本発明の実施の形態を説明する。
【実施例１】
【００４０】
本実施例では、列車内のネットワーク（以後、これを車上ネットワークと称す）に接続されたホストと、地上側の基地局、サブネットワーク、基幹ネットワーク、およびインターネット上のホストとの間において、当該列車が高速移動中においても、安定したＩＰ連続通信を提供する通信方式の実施の態様について説明する。
【００４１】
先ず本実施例の説明を行う前に、本システムが前提とするモバイルＩＰ方式の概要を、図１を用いて説明する。
【００４２】
モバイルＩＰ方式とは、複数の無線ネットワーク間で端末を移動させても、ＩＰアドレスを変更せずに、連続的なＩＰ通信を可能とする業界標準プロトコルである。
【００４３】
モバイルＩＰ方式では、モバイルルータ（以後、ＭＲと称す）から、無線エリアに進入した旨の連絡を受けたフォーリンエージェントルータ（以後、ＦＡと称す）が、その情報をホームエージェントルータ（以後、ＨＡと称す）に連絡し、ＨＡはＦＡに対して、ＦＡはＭＲに対してＩＰパケットを運ぶ為のトンネル（ＩＰトンネル）を生成することで、車両内のＩＰ通信機器（ＰＣ、サーバ等）に対してＩＰパケットを転送するものであり、ＭＲが異なる無線エリアに進入する度に、このＩＰトンネルが新たに作成、あるいは再利用される。
【００４４】
ＨＡは、ＭＲに属するネットワークまたはホストのＩＰアドレスを、ルーティングプロトコルを使って常にアドバタイズ（広告）している為、移動中の列車の中に配備されているＭＲに属するネットワークまたはホスト宛てのＩＰパケット（下りフレーム）は、先ずＨＡに到着することになる。ＨＡは前記に説明したＩＰトンネルを使って、当該ＩＰパケットをＦＡ経由でＭＲに転送する。ＭＲでトンネルから開放されたＩＰパケットは、目的の車上ネットワーク上に展開され、車上ネットワークのホストに配送される。
【００４５】
また、ＭＲに属するネットワークまたはホストから送信されるＩＰパケットは、ＭＲを経由して、地上側のＩＰネットワークに転送され、その後は、通常のＩＰルーティングによって、目的のホストに転送されることになる。
【００４６】
図２に、本実施例におけるシステムの全体図を示す。
【００４７】
列車３は、車上ネットワーク３０を具備し、ネットワーク３０は、モバイルルータ（以下ＭＲと称す）３１、車上サーバ３５、旅客用パーソナルコンピュータ（以下単に旅客ＰＣと称す）３６が接続されている。なお、車上ネットワーク３０は、有線ＬＡＮ、無線ＬＡＮなど、どのようなネットワークであってもよい。またＰＣ３６は車上ネットワークに固定的に具備されていても、あるいは旅客が列車内に持ち込まれたものであったもよい。
【００４８】
ＭＲ３１には、車上側フレーム制御装置（なお、図中には略称として”ＡＩＲ＿Ｔ”と記載する）３２、ディジタル漏えい同軸ケーブル（ディジタルリーケージコアキシャルケーブルのことで、以後DLCXと称す）からの漏曳電波の送受信を行う車上側送受信機（以後、「車上側ＤＬＣＸ送受信機」と称し、図中においては「ＤＬＣＸ＿Ｔ」と記載する）３３、地上側ＤＬＣＸアンテナ３４が直列に接続されている。なお、ＤＬＣＸとは、同軸ケーブルのシールドに、わずかなスリット（すき間）を設けることで、電波を漏洩させ、ＤＬＣＸ周辺のわずかな領域（数十ｍ）にだけ無線感帯を確保するものであり、首都高トンネル内の携帯・自動車電話中継用や、同トンネル内の業務無線などにも使用されている。
【００４９】
基幹ネットワーク１０には、フォーリンエージェントルータ（以下「ＦＡ」と称す）１１が接続されており、さらに、地上側フレーム制御装置（なお、図中には略称として「ＡＩＲ＿Ｇ」と記載する）１２、地上側ＤＬＣＸ送受信機（なお、図中には略称として「ＤＬＣＸ＿Ｇ」と記載する）１３、ＤＬＣＸ１４が直列に接続されている。地上側フレーム制御装置１２同士は、ＶＬＡＮスイッチ１５（なお、図中には略称として「ＳＷ」と記載する）と地域ネットワーク２０を介して、隣接する別の地上側フレーム制御装置とＶＬＡＮ接続されている。
【００５０】
さらに、基幹ネットワーク１０には、ホームエージェントルータ（以下「ＨＡ」と称す）１９が接続されており、業務用ネットワーク４０とインターネット５０のゲートウェイとなっている。業務用ネットワーク４０には、業務用サーバ４１が接続され、インターネット５０には、インターネットサーバ５１が接続されている。なお、当該業務用サーバ４１、またはインターネットサーバ５１が提供するサービスは、Ｗｅｂサービス、メールサービス、ネットワーク管理サーバ等を含み、サーバのサービスの内容に関して特別な限定はない。
【００５１】
図３に、車上側フレーム制御装置３２のハードウェア構成を示す。
【００５２】
ＭＲ３１と接続するためのネットワークインタフェースカード３２２、車上側ＤＬＣＸ送受信機３３と接続するためのネットワークインタフェースカード３２３、ＣＰＵ３２５、メモリ３２４、ハードディスク３２８を接続したハードディスクコントローラ３２７、ディスプレイ、マウス、キーボード、またはＲＳ２３２Ｃ等のインタフェースを介して、本装置をローカルに制御する為の外部インターフェース群３２９が、バスなどの内部通信線（以下、バスという）３２１によって接続されている。
【００５３】
図４に、地上側フレーム制御装置１２のハードウェア構成を示す。
【００５４】
車上側ＤＬＣＸ送受信機３３と接続するためのネットワークインタフェースカード１２２、ＦＡ１１と接続するためのネットワークインタフェースカード１２３、隣接する地上側フレーム制御装置と地域ネットワーク２０を介して接続する為のネットワークインタフェースカード１２４または１２５、ＣＰＵ１２６、メモリ１２７、ハードディスク１２９と接続したハードディスクコントローラ１２８、ディスプレイ、マウス、キーボード、またはＲＳ２３２Ｃ等のインタフェースを介して、本装置をローカルに制御する為の外部インターフェース群１３０がバス１２１によって接続されている。
【００５５】
図５に、車上側フレーム制御装置３２のソフトウェア構成を示す。
【００５６】
ネットワークインタフェースカード３２２，３２３を制御するためのネットワークインタフェースカード制御ドライバ３２４−２、図２のＭＲ３１または車上側ＤＬＣＸ送受信機３３との間で通信を実施する通信管理モジュール３２４−４、送信キュー３２４−６、受信キュー３２４−４、ハードディスク３２８とのデータの入出力を制御する入出力装置制御ドライバ３２４−８が格納されている。
【００５７】
ＭＲ３１のＭＴＵ（「ＭＴＵ」とは「Ｍａｘ  Ｔｒａｎｓｆｅｒ  Ｕｎｉｔ」の略で、一度に送信できるフレームサイズを決めるパラメータのこと）長を制御する為のＭＴＵ制御モジュール３２４−１０、上りフレームに通番を付与し、または下りフレームの通番の削除を行う通番給付・削除モジュール３２４−１２、下りフレームのロストを検知し当該ロストフレームの再送を要求する下りフレームロスト検知・再送要求モジュール３２４−１４、上りフレームがロストした場合に、再送処理を行う再送処理モジュール３２４−２６、車上側ＤＬＣＸ送受信機３３から無線エリアの移動検知した旨の情報を受信する無線ゾーン移動検知モジュール３２４−１６、リモートからネットワーク経由で車上側パケット制御装置３２にログインして、各種の設定およびメンテナンスを行う機能を提供するリモートサーバモジュール３２４−１８、本装置にローカルでアクセスする為の外部インターフェース群３２９のドライバ群３２４−２２、当該装置の各種設定を行う設定モジュール３２４−２０、最新の上りフレームをある一定個数格納する処理を行う上りフレーム一時記憶モジュール３２４−２４が格納されている。
【００５８】
図６に、地上側フレーム制御装置１２のソフトウェア構成を示す。
【００５９】
ネットワークインタフェースカード１２２，１２３，１２４，１２５を制御するためのネットワークインタフェースカード制御ドライバ１２７−２、地上側ＤＬＣＸ送受信機１３、ＦＡ１１、または地域ネットワーク２０との間で通信を実施する通信管理モジュール１２７−４、送信キュー１２７−６、受信キュー１２７−４、ハードディスク１２９とのデータの入出力を制御する入出力装置制御ドライバ１２７−８が格納されている。  
ＭＲ１１のＭＴＵ長を制御する為のＭＴＵ制御モジュール１２７−１０、下りＩＰパケットに通番を付与し、または上りフレームの通番の削除を行う通番給付・削除モジュール１２７−１２、上りフレームのロストを検知し、当該ロストフレームの再送を要求する上りフレームロスト検知・再送要求モジュール１２７−１４、下りフレームがロストした場合に、再送処理を行う再送処理モジュール１２７−３０、地上側ＤＬＣＸ送受信機１３から無線エリアの移動検知した旨の情報を受信する無線エリア移動検知モジュール１２７−１６、リモートからネットワーク経由で地上側フレーム制御装置１２にログインして、各種の設定およびメンテナンスを行う機能を提供するリモートサーバモジュール１２７−１８、本装置をローカルからアクセスするための外部インターフェース群３２９のドライバ群１２７−２２、当該装置の各種設定を行う設定モジュール１２７−２０、モバイルＩＰのエージェント要請メッセージ、エージェント広告メッセージ等の内容を調べる為に、本装置を通過するＩＰパケットをモニタするフレームモニタモジュール１２７−２４、前記モジュールからモニタしたフレームのＭＡＣまたはＩＰアドレス等を入手して、当該情報を使ってフレームの内容を書き換えるフレーム書き換えモジュール１２７−２６、列車の進行方向にある無線エリアの地上側フレーム制御装置１２にフレームを転送する、パケットフォワードモジュール１２７−３２、最新の下りフレームをある一定個数格納する処理を行う上りフレーム一時記憶モジュール３２４−２４が格納されている。
【００６０】
次に、車上側フレーム制御装置３２の動作を、起動から順を追って説明する。
【００６１】
なお、本実施例においては、説明の内容を理解しやすくするため、通信用の物理ネットワーク媒体としてイーサネット（登録商標）（広域イーサネットを含む）を用いて記載し、車上側フレーム制御装置３２または地上側フレーム制御装置１２も、イーサネットを扱うものとして記載しているが、本発明においてイーサネットの使用は発明の本質ではなく、ＩＰパケットを搬送するＩＰネットワークを提供可能なネットワーク媒体であれば、どのようなものでも使用可能である。
【００６２】
車上側フレーム制御装置３２は、ディスプレイ、マウス、キーボード、またはＲＳ２３２Ｃ等のインタフェースから、外部インターフェース群３２９を経由して、ローカルから設定モジュール３２４−２０を起動することで、ネットワークインタフェースカード３２２または３２３のＩＰアドレス、サブネットマスク、デフォルトゲートウェイ、ブロードキャストアドレス、もしくはＤＨＣＰ機能などによって動的に提供されるＩＰアドレスを使用する旨の設定を行う。このようにＩＰアドレスが設定された後は、ネットワークの利用が可能となるので、リモートサーバモジュール３２４−１８を経由して、リモートから設定することも可能となる。
【００６３】
次に、リモートあるいはローカルから、設定モジュール３２４−２０を起動して、ネットワークインタフェースカード３２２に接続しているＭＲ３１のＭＡＣアドレスと、ＭＲ３１に対して設定するフレームイーサネットフレームのＭＴＵ値の値を入力する。イーサネットの場合ＭＴＵ値は最大１５００（バイト）であるので、１５００バイトよりも小さい値（例えば、１４００（バイト））を設定する。
【００６４】
また、列車の進行する方向も設定する。例えば、東京方面に向かう列車であれば０を、東京方面から離れる列車であれば１を設定する。
【００６５】
また、上りフレームがロストした場合に、再送処理を行えるように、記憶領域に常に最新のフレームを一定数保存する為のフレーム数（例えば、３０万フレーム）を設定する。一定数を越えた場合には、古いフレームが記録された領域に最新のフレームを上書きしていくことで、古いフレームを破棄する。
【００６６】
地上側フレーム制御装置１２は、ディスプレイ、マウス、キーボード、またはＲＳ２３２Ｃ等のインタフェースから、外部インターフェース群１３０を経由して、ローカルから設定モジュール１２７−２０を起動することで、ネットワークインタフェースカード１２２，１２３，１２４または１２５のＩＰアドレス、サブネットマスク、デフォルトゲートウェイ、ブロードキャストアドレス、ＶＬＡＮ  ＩＤ、もしくはＤＨＣＰ機能などによって動的に提供されるＩＰアドレスを使用する旨の設定を行う。このようにＩＰアドレスが設定された後は、ネットワークの利用が可能となるので、リモートサーバモジュール１２７−１８を経由して、リモートから設定することも可能となる。
【００６７】
次に、リモートあるいはローカルから、設定モジュール１２７−２０を起動して、ネットワークインタフェースカード１２３に接続しているＦＡ１１のＭＡＣアドレスと、ＦＡ１１に対して設定するフレームイーサネットフレームのＭＴＵ値の値を入力する。このＭＴＵ値は、車上側フレーム制御装置３２で設定した値と同じ値とする。
【００６８】
また、下りフレームがロストした場合に、再送処理を行えるように、列車単位で、記憶領域に常に最新のフレームを一定数（例えば、３０万フレーム）保存する為のフレーム数を設定する。一定数を越えた場合には、古いフレームが記録された領域に最新のフレームを上書きしていくことによって、古いフレームを破棄する。
【００６９】
図７に、地上側フレーム制御装置３２によって生成されるフレームを示す、なお、ＭＡＣ用ＣＲＣ（４オクテット）の記載は省略している。
【００７０】
車上ネットワーク３０から上りフレームとしてＭＲに到着したフレームイーサネットフレームは、前述したＭＴＵ値の設定値の変更により、ＭＴＵが１４００バイト以下の上りメッセージ１−１に変換されて、ＭＲ３１から車上側フレーム制御装置３２のネットワークインタフェースカード３２２に到着する。
【００７１】
上りメッセージ１−１は、図５の通番給付・削除モジュール３２４−１２に転送されて、メモリ上に一時的に転写された後、当該メモリ上の１４００バイト目以降に、上りＩＤを付与される。
【００７２】
上りＩＤは、進行方向フラグ、列車認識番号、上りフレーム通番から構成される。進行方向フラグは、設定モジュール３２４−２０を介して入力された列車の進行する方向が搭載される。例えば、東京方面に向かう列車であれば０が、東京方面から離れる列車であれば１が設定される。また、列車認識番号としては、全列車に対してユニークな値が付与されるものであればどのようなものでもよいが、本実施例においては、ＭＡＣアドレス（１２バイト）を使用する。MACアドレスはイーサネットカード製造時にユニークな値が付与されているものでありMACアドレスの衝突は発生しないからである。
【００７３】
さらに、上りフレーム通番には整数値を用いる。通番は、列車の運行開始時に０リセットされ、フレーム１つを送信する度に値が一つ上っていき、最大値に達したら再び０にリセットされる。十分に大きい桁数の通番を使うことで、リセットに対する対処を省略することが可能となる。本実施例では、通番として４バイトの整数値（０〜４２９４９６７２９５）を用い、一秒間に５万フレームの転送を実施しても２３時間ほどの使用が可能ととしている。
【００７４】
なお、前記の例においては、合計１６バイトの上りＩＤを付与しているだけであるが、この他にも、１−３に示すように暗号化したＩＰデータに、その暗号に関する制御情報であるセキュアヘッダやＨＭＡＣ等を付与することで、車上側フレーム制御装置３２と地上側フレーム制御装置１２の間においてフレームの暗号化を施すことも可能となる。
【００７５】
このように上りＩＤが付与されたフレーム情報は、通常のＭＴＵのイーサネットパケットに転写されて、フレームイーサネットフレーム１−２として、図３のネットワークインタフェースカード３２３から、車上側ＤＬＣＸ送受信機３３に送付され、地上側ＤＬＣＸアンテナ３４、地上側のＤＬＣＸ１４、地上側ＤＬＣＸ送受信機１３を経由して、地上側フレーム制御装置１２に到着する。
【００７６】
下りメッセージも、図６の通番給付・削除モジュール１２７−１２に転送されて、メモリ上に一時的に転写された後、当該メモリ上の１４００バイト目以降に、下りＩＤを付与される。
【００７７】
上記のような方法以外の方法としては、上りフレームとして、ＭＲ３１が旅客ＰＣ３６に対して、ＭＴＵを変更する要求（例えば、ＭＴＵを１４００にする要求）を出し、ＡＩＲ＿Ｔ３２が、１００バイトの制御情報を付与することによって、上記と同目的の処理を実施することが可能となる。なお、下りフレームについても、これに準じる処理を行う。
【００７８】
また、イーサネットフレームの最大ＭＴＵ値は１５００となっているが、ネットワークカードのドライバに改造を行うなどの処理を施すことによって、１６００バイト以上の情報を付与できるという性質を利用して、上りフレームとして、旅客ＰＣ３６からＭＲ３１を経由してＡＩＲ＿Ｔ３２に送付されてきた最大１５００バイトのイーサネットフレームに、さらに１００バイトの制御情報を付与して、ＡＩＲ＿Ｇ１２に送付し、ＡＩＲ＿Ｇ１２において制御情報を除去することによっても、上記と同目的の処理を実施することが可能となる。なお、下りフレームについても、これに準じる処理を行う。
【００７９】
なお、イーサネットフレームは最大ＭＴＵ値が１５００であるので、この値を超えるようなメッセージに対してはフレームの分割が発生するが、上記に記載した方法は、ＡＩＲ＿Ｔ３２またはＡＩＲ＿Ｇ１２で、フレームに対してＩＤを付与することによるフレーム分割の発生を回避することを目的としている。
【００８０】
もしＡＩＲ＿Ｔ３２またはＡＩＲ＿Ｇ１２でフレーム分割が発生してしまうと、前半のフレームには制御情報が付与されないまま転送されてしまい、ＡＩＲ＿Ｔ３２またはＡＩＲ＿Ｇ１２で通番廃棄を含むフレーム処理が実施できなくなる。
【００８１】
しかし、ＡＩＲ＿Ｔ３２またはＡＩＲ＿Ｇ１２でＩＤを付与することによって、ＭＴＵ値が１５００を超えるようなフレーム（例えば１６００バイト）となった場合でも、最終的にＡＩＲ＿Ｔ３２またはＡＩＲ＿Ｇ１２で、送信した時点でのフレームに組み立て直すことができれば（すなわち１６００バイトのイーサネットフレームとして組み立てることができれば）問題はない。なぜなら、ＡＩＲ＿Ｔ３２、ＡＩＲ＿Ｇ１２間以外では、ＩＤが除去されて、結果としてＭＴＵ値が１５００バイト以下となって転送されるからである。
【００８２】
図１８にこの方法について説明する。
【００８３】
フレーム（ａ）は、全長１４６０バイトのフレームに１００バイトのＩＤを付与することによって、全長１５６０のフレームとなっており、通常の処理ではフレーム分割が発生する。そこで、ＡＩＲ＿Ｔ３２またはＡＩＲ＿Ｇ１２において、このフレーム（ａ）を、フレーム（ｂ）とフレーム（ｃ）に意図的に分割して扱うようにする。
【００８４】
すなわち、１５６０バイトを、前半１４８０バイトと後半８０バイトのフレームに分割した後に、前半フレームの最後２０バイトに、自己のフレームを表示する番号と、このフレームに連結するフレームの番号を記載しておく。同じく後半フレームにも、自己のフレーム番号を記載するが、このフレームに連結するフレームはないので、ここではＮＵＬＬが記載される。
【００８５】
このフレーム（ｂ）（ｃ）を受け取ったＡＩＲ＿Ｔ３２またはＡＩＲ＿Ｇ１２で、再度組み立てることによって、元の長さのフレームに復元する。このように、最大ＭＴＵ値によるフレーム制御による制約を受けることなく、実際上、最大ＭＴＵ値以上のフレームを転送することが可能となる。
【００８６】
図８は、図６に示す地上系フレーム制御装置１２のモジュール群が共通で使用する通番管理テーブル１２７−５０である。
【００８７】
方向のエントリは、当該列車が東京方面に向かう列車であるか、東京方面から離れる列車であるかが記載される。これによって、地上側フレーム制御装置１２は、隣接する地上側フレーム制御装置１２のどちらにフレームを転送すればよいのかを判断することが可能となる。
【００８８】
列車認識番号のエントリは、その時点において地上系フレーム制御装置１２がフレーム制御管理を行っている列車を示し、上りフレーム通番のエントリ、下りフレーム通番のエントリには、それぞれ地上系フレーム制御装置１２が取り扱った上りおよび下りフレームの最新の通番が記載される。
【００８９】
下りＩＤの通番は、地上系フレーム制御装置１２の通番給付・削除モジュール１２７−１２が、列車の進行と連動して、列車認識番号とともに、列車の進行方向の地上系パケット制御装置１２の当該モジュールに通知することで、通番の一貫性を保証する。この下りＩＤの管理制御方法に関しては、後述する。
【００９０】
なお、無線エリア移動検知モジュール１２７−１６が、無線エリアへの列車の進入を検知したときに、列車認識番号と一致する列車認識番号のエントリがなかった場合には、列車の運行開始時と認識し、当該エントリを追加し、下りフレーム通番に０をセットする。
【００９１】
このように下りＩＤが付与されたフレーム情報は、通常のＭＴＵのイーサネットパケットに転写され、図４のネットワークインタフェースカード１２２から、地上側ＤＬＣＸ送受信機１３に送付され、ＤＬＣＸ１４、地上側ＤＬＣＸアンテナ３４、車上側ＤＬＣＸ送受信機３３を経由して、車上側フレーム制御装置３２に到着する。
【００９２】
上りフレームの処理の概要を図９または図１０に示す。図９においては、ＤＬＣＸ関連の装置、その他ネットワークについては記載を省略する。また、図中の”ｅｔｈ０”，”ｅｔｈ１”なる表示は、各装置における、イーサネットのネットワークインタフェースカードを示すものである。なお、列車は図中右方向に進行しているものとする。
【００９３】
ＭＲ３１からＭＴＵ値１４００で送信されたフレームイーサネットフレームは、上記で述べた通り、通番給付・削除モジュール３２４−１２で通番ＩＤが付与された後、ＭＴＵ値１５００のフレームイーサネットフレームとなった後、上りフレーム一時記憶モジュール３２４−２４によって一時記憶領域（一時格納領域は、図３に示すメモリ３２４、ハードディスク３２８のどちらに作成されても良い）にコピーされた後、ｅｔｈ１のインターフェースを介して、無線エリア１の地上側フレーム制御装置１２−１のｅｔｈ０のインターフェースに転送され、そのままｅｔｈ３のインターフェースから、地域ネットワーク２０のＶＬＡＮを経由して、列車の進行方向にある無線エリア２の地上側フレーム制御装置１２−２に届けられる。
【００９４】
ここで、地上側フレーム制御装置１２−２の上りフレームロスト検知・再送要求モジュール１２７−１４によって、送付されてきたフレームイーサネットフレームの上りＩＤがチェックされ、下り通番管理テーブル１２７−５０の、列車認識番号に応じた上りフレーム通番エントリに、最新の通番が記録される。列車認識番号に応じたエントリが存在しない場合には、新規にエントリが作成される。通番記録が終った後、当該フレームイーサネットフレームは、通番給付・削除モジュール１２７−１２に渡されて、上りＩＤを削除し、ＣＲＣの再計算等を行った後、イーサネットインターフェースカードｅｔｈ２から送出され、ＦＡ１１−２を経由して基幹ネットワークに送出される（Ｓｔｅｐ．１）。
【００９５】
列車３がちょうど、無線エリア１と無線エリア２の間の通信ができない不感帯等に入った時も、車上側フレーム制御装置３２はフレームを送出し続け、この間のフレームはロストする（Ｓｔｅｐ．２）。
【００９６】
列車３が無線エリア２に進入した段階で、車上側ＤＬＣＸ送受信機３３と、無線エリア２の地上系ＤＬＣＸ送受信機１３−２は、それぞれ列車３の存在を認識し、それを車上系フレーム制御装置３２と、地上側フレーム制御装置１２−２に通知し、それぞれの無線エリア移動検知モジュール３２４−１６と１２７−１６で確認される。この時点で、すぐに無線エリア渡り時のロストフレームの再送要求が行なわれることに対して、車上系フレーム制御装置３２と、地上側フレーム制御装置１２−２が待機状態に入る（Ｓｔｅｐ．３）。
【００９７】
列車３が無線エリア２に進入した後、車上系フレーム制御装置３２から地上側フレーム制御装置１２−２に対して送信された最初のフレームを上りフレームロスト検知・再送要求モジュール１２７−１４が受信すると、通番管理テーブル１２７−５０の列車認識番号に応じたエントリの上りフレーム通番を確認する。この通番が連続値でなければ、無線ゾーン１と無線エリア２の間でフレームロストが発生したことになるため、上りフレームロスト検知・再送要求モジュール１２７−１４は、ロストしたと思われる通番の情報を付与してフレームの再送要求を車上系フレーム制御装置３２の再送処理モジュール３２４−２６に通知する。
【００９８】
当該要求を受けた再送処理モジュール３２４−２６は、上りフレーム一時記憶モジュール３２４−２４によって一時記憶領域に記載されているフレームのコピーから、当該要求に対応したフレームを見つけて、地上側フレーム制御装置１２−２に転送する。このパケットも、上記と同様に無線エリア２の地上側フレーム制御装置１２−２から、無線エリア３の地上側フレーム制御装置１２−３に転送される（Ｓｔｅｐ．４）。
【００９９】
上記処理に遅れて、あるいは先んじて、モバイルＩＰのエージェント要請メッセージ、エージェント広告メッセージ等の処理をきっかけとして、エージェント登録要求が行なわれた場合も、上記の処理に影響を与えることはなく（Ｓｔｅｐ．５）、上りフレームは、無線エリア３の地上側フレーム制御装置１２−３に転送される。
【０１００】
なお、無線エリアを通過してしまった列車に関しては、通番管理テーブル１２７−５０のエントリは不要となるので、無線エリア移動検知モジュール１２７−１６は、一定時間(例えば６０秒)の間、上りフレーム通番エントリ、下りフレーム通番エントリの両方の値に変動がなかった場合、列車認識番号エントリを含めて削除する。
【０１０１】
下りフレームの処理の概要を図１１または図１２に示す。本図においては、ＤＬＣＸ関連の装置、  その他ネットワークについては記載を省略している。なお、図中の”ｅｔｈ０”，”ｅｔｈ１”なる表示は、各装置における、イーサネットのネットワークインタフェースカードを示すものである。なお、列車は図中右方向に進行しているものとする。
【０１０２】
ＭＲ３１、無線エリア１のＦＡ１１−１の間で、モバイルＩＰのエージェント要請メッセージ、エージェント広告メッセージを交換することによって、ＭＲ３１からＨＡ１９に対してエージェント登録要求が行われ、その応答としてエージェント登録応答が返信されると、地上系フレーム制御装置１２−１のフレームモニタモジュール１２７ー２４が、当該エージェント登録応答の内容を検知し、ＭＲ３１のネットワークインタフェースカードのＭＡＣアドレスを取得する。
【０１０３】
次に、無線エリア１の地上系フレーム制御装置１２−１は、無線エリア２の地上系パケット制御装置１２−２の下りフレーム一時記憶モジュール１２７ー３４に対して地上系パケット制御装置１２−１を通過する下りフレームを記録する為の一時記憶領域（一時格納領域は、図４に示すメモリ１２７、ハードディスク１２９のどちらに作成されても良い）の作成依頼を、下りフレーム一時記憶モジュール３２４−３４に対して行う。
【０１０４】
下りフレーム一時記憶モジュール１２７ー３４は、ＭＲ３１のネットワークインタフェースカードのＭＡＣアドレスを使って一時記憶ファイルを作成する。例えば、その列車のＭＲ３１のＭＡＣアドレスが、００−５０−５６−Ｃ０−００−０８であれば、”００−５０−５６−Ｃ０−００−０８．ｂｕｆ”というファイル名にしてもよい（Ｓｔｅｐ．１）。
【０１０５】
この後、ＦＡ１１−１から送られる下りフレームは、地上側ＤＬＣＸ送受信機１３−１に送られる直前に、地上系フレーム制御装置１２−１で複製され、地上系フレーム制御装置１２−２に送信され、当該ＭＡＣアドレスのファイル名を付与された一時記憶領域に格納される（Ｓｔｅｐ．２）。
【０１０６】
列車３が、無線エリア１と無線エリア２の不感帯に入った時も、上記Ｓｔｅｐ．２と同じ処理が行われるが、地上側ＤＬＣＸ送受信機１３−１が送信するフレームは受信されない（Ｓｔｅｐ．２）。
【０１０７】
列車３が、無線エリア２に進入すると、車上側ＤＬＣＸ送受信機３３と地上側ＤＬＣＸ送受信機１３−２のそれぞれが検知し、無線エリア移動検知モジュール３２４ー１４と１２７ー１６に通知され、無線エリア移動検知モジュール１２７ー１６は、下りフレーム一時記憶モジュール１２７ー３２に対して、一時記憶領域への格納を中止し、そのまま地上側ＤＬＣＸ送受信機１３−２に転送するように指示を出す（転送開始指示）。もはやこの時点においては、無線エリア渡り時におけるフレームロストが発生する余地がなく、一時記憶領域の新しく到着したフレームによる不要な上書きを回避する為である。またこの時点において、通番給付・削除モジュール１２７ー１２は、通番の引き継ぎを行う為に、後述するＳｔｅｐ．５またはＳｔｅｐ．７によって、送信される下りフレームの通番の最大値を記録しておく（Ｓｔｅｐ．４）。
【０１０８】
不感帯への突入または登録処理遅延の為に、ＭＲ３１が無線エリア１で受信できなかったフレームは、無線エリア２の地上側フレーム制御装置１２−２に格納されており、再送可能な状態となっている。転送開始指示によって、無線エリア２に最初に送られてきたパケットを、車上側フレーム制御装置３２が受信して、その下り通番を調べることによって、ロストしたフレームが具体的に特定可能となり、車上側フレーム制御装置３２は、地上側フレーム制御装置１２−２に対して、そのロストフレームの再送要求を行い（Ｓｔｅｐ．６）、地上側フレーム制御装置１２−２は、当該フレームの再送処理を行う（Ｓｔｅｐ．７）。
【０１０９】
その後、Ｓｔｅｐ．８または９の処理の後、前述した通りの手順で、無線エリア２の地上側フレーム制御装置１２−２は、無線エリア３の地上側フレーム制御装置１２−３に対して一時記憶領域の作成要求が行うと共に、通番給付・削除モジュール１２７ー１２は、この時点をもってＳｔｅｐ．５またはＳｔｅｐ．７によって、送信された下りフレームの通番の最大値を、通番給付・削除モジュール１２７ー１２が管理する通番の初期値としてセットする。
【０１１０】
もっとも、エージェント登録が行われた後に、無線エリア１からの無線エリア２に対してフレームの転送が行われる可能性は絶無ではない。なぜなら基幹ネットワーク１０または地域ネットワーク２０の転送遅延等が発生する可能性があるからである。
【０１１１】
そこで、Ｓｔｅｐ．９の処理の後に、無線エリア１からの無線エリア２に対して転送されてきたフレームに関しては、フレーム書き換えモジュール１２７ー２６によって、当該フレームがＦＡ１１−２から送信されてきたようにフレームのヘッダ部の書き換えを実施する。具体的には、送信元ＭＡＣアドレスを無線エリア２のＦＡ１１−２のものに、送信先ＩＰアドレスを、エージェント登録応答で取得したＭＲ３１の新たなＩＰアドレスに書き換える。さらに下りＩＤの通番を地上側フレーム制御装置１２−１の通番給付・削除モジュール１２７ー１２が付与した番号から、地上側フレーム制御装置１２−２の通番給付・削除モジュール１２７ー１２が管理する通番に書き換える（Ｓｔｅｐ．１０）。
【０１１２】
エージェント登録要求後に行なわれる下りフレームに関しては、上記Ｓｔｅｐ．２以後の処理に同じである。
【実施例２】
【０１１３】
本実施例では、実施例１の図２のシステム構成において、ＶＬＡＮスイッチ１５および地域ネットワーク２０が存在しない場合での、本発明の実施態様について説明する。
【０１１４】
図１３に本実施例における上りフレームの処理を示すシステムの概要図を示す。
【０１１５】
実施例１においては、フレームを列車３の移動方向にある無線エリアの地上側フレーム転送装置にフォワードすることによって、モバイルＩＰのフレームロストを解決する方式について説明したが、実際のシステム構築においては、当該フレームを地上側フレーム制御装置１２−１から、別の地上側フレーム制御装置１２−１に転送する為にネットワークを新たに用意することはコスト的に困難であることが多いことが予想される。そこで、本実施例においては、このような地域ネットワークを使わずに、基幹ネットワーク１０を使うことで、実施例１と同様な発明の効果を亨受できる例について説明する。
【０１１６】
本実施例においては、図６記載のフレームフォワードモジュール１２７ー３４に、ＩＰトンネリングの機能を具備することで実現する。
【０１１７】
先ず、リモートまたはローカルから、設定モジュール１２７ー２０を起動して、全ての地上側フレーム制御装置１２のそれぞれのｅｔｈ１およびｅｔｈ３に、適当なＩＰアドレスを付与し、基幹ネットーワーク２０を介して、相互にＩＰ通信が可能となるようにしておく。
【０１１８】
次に、地上側フレーム制御装置１２−１のｅｔｈ３から送出されるフレーム全体をＩＰフレームが運ぶデータとしてカプセル化し、これを地上側フレーム制御装置１２−２のｅｔｈ１のＩＰアドレス宛に送信する。ＦＡ１１は、通常のルータとしても機能するので、送信先アドレスが記載されたＩＰアドレスであれば、目的のＩＰアドレスのネットワークカードに届けることが可能である。カプセル化されたＩＰパケットは、地上側フレーム制御装置１２−２のフレームフォワードモジュール１２７−３４で受信されて、ここで元のフレームイーサネットフレームとして展開され、以後は実施例１と同様の処理が行われる。
【０１１９】
図１３は、上りフレームについてのみ説明したが、下りフレームにおいても、前記と同様の処理を行うことで、フレームの前方無線エリアへのフォワードを行うことが可能となる。
【実施例３】
【０１２０】
本実施例では、実施例１の図２のシステム構成において、新しい同種のあるいは異種の無線通信手段が追加された場合における、本発明の実施態様について説明する。
【０１２１】
図１４は、図２にＡＩＲ＿Ｇ１２に、無線ＬＡＮ基地局（なお、図中には略称として「ＳＳ＿Ｇ」と記載する）１６、２つめの地上側ＤＬＣＸ送受信機（なお、図中には略称として「ＤＬＣＸ＿ＧＳ」と記載する）１７、無線ＬＡＮアダプタ３７が追加されたものである。
【０１２２】
ＳＳ＿Ｇ１６またはＤＬＣＸ＿ＧＳ１７の無線エリアは、ＤＬＣＸ＿Ｇ１３の無線エリアに包含されており、これらの無線エリア間では混信が発生しないように事前に設定されているものとする。
【０１２３】
列車３の車上側ＤＬＣＸ送受信機３３は、パッシブスキャンまたはアクティブスキャンを行い、地上側ＤＬＣＸ送受信機を探しつづける。なお、パッシブスキャン、アクティブスキャンに関しては、”８０２．１１  Ｗｉｒｅｌｅｓｓ  Ｎｅｔｗｏｒｋｓ  Ｔｈｅ  Ｄｅｆｉｎｉｔｉｖｅ  Ｇｕｉｄｅ”  Ｍａｔｔｅｗ  Ｓ．  Ｇａｓｔ著  Ｏ’ＲＥＩＬＬＹ社に詳しい記載がある。
【０１２４】
ＤＬＣＸ＿ＧＳ１７は、現状利用可能な通信帯域、ＤＬＣＸ＿ＧＳが提供する無線エリアの全長等の情報を含めたビーコン信号を発信しつづけ、これをＤＬＣＸ＿Ｔ３３が受信すると、この信号をＡＩＲ＿Ｔ３２に転送する。
【０１２５】
ＡＩＲ＿Ｔ３２は、ＤＬＣＸ＿Ｇ１３との通信コネクションを開放してＤＬＣＸ＿ＧＳ１７との通信コネクションを再確立するか否かの判断を行い、行わないと判断した場合は、そのままＤＬＣＸ＿Ｇ１３との通信コネクションを維持する。行うと判断した場合、ＡＩＲ＿Ｔ３２は、ＡＩＲ＿Ｇ１２に対して、通信を切り替える旨のメッセージを送信して、上りフレームをＤＬＣＸ＿Ｔ３３に転送する処理を中断し、車上ネットワーク３０から送られてくるメッセージをバッファに格納し続ける。
【０１２６】
通信を切り替える旨のメッセージを受信したＡＩＲ＿Ｇ１２も、下りフレームをＤＬＣＸ＿Ｇ１３に転送する処理を中断し、ＦＡ１１またはＳＷ１５から転送されていくるメッセージをバッファに格納し続ける。
【０１２７】
次にＡＩＲ＿Ｔ３２は、ＤＬＣＸ＿Ｔ３３に対して、ＤＬＣＸ＿Ｇ１３とのコネクション開放の処理と、ＤＬＣＸ＿ＧＳ１７とのコネクション確立処理を命じ、ＤＬＣＸ＿Ｔ３３より当該コネクション処理の確立が完了した旨のシグナルを受信した後、ＡＩＲ＿Ｔ３２はバッファに格納されたフレームから順番にフレームの送出を再開する。
【０１２８】
同じく、ＡＩＲ＿Ｇ１２も、ＤＬＣＸ＿ＧＳ１７より当該コネクション処理の確立が完了した旨のシグナルを受信した後、バッファに格納されたフレームから順番にフレームの送出を再開する。
【０１２９】
さらに、列車３の車上側ＤＬＣＸ送受信機３３は、パッシブスキャンまたはアクティブスキャンを行い、ＤＬＣＸ＿ＧＳ１７が提供する無線エリアから離脱したことを検知した場合には、ＡＩＲ＿Ｔ３２に通知し、ＡＩＲ＿Ｔ３２はＤＬＣＸ＿Ｔ３３にＤＬＣＸ＿ＧＳ１７のコネクションを開放する旨の命令を行った後、ＤＬＣＸ＿Ｇ１３のコネクションを再確立する処理と、前記に順ずるフレームのバッファ格納と送出処理を行う。ＡＩＲ＿Ｇ１２もこれに順ずる処理を行う。
【０１３０】
ところが、ＤＬＣＸ＿ＧＳ１７が提供する無線エリアから離脱したことを検知した段階においてはすでに通信不能状態となっており、ＤＬＣＸ＿ＧＳ１７またはＤＬＣＸ＿Ｔ３２から送出されたフレームはロストしている可能性が高い。
【０１３１】
そこで、本実施例においても、実施例１で用いている方法によるロストフレームの救済を行う。すなわち、上りフレームまたは下りフレームがロストした場合に、再送処理を行えるように、記憶領域に最新のフレームを一定数保存する為のフレーム数（例えば、３０万フレーム）を設定しておく。なお、一定数を越えた場合には、古いフレームが記録された領域に最新のフレームを上書きしていくことで、古いフレームを破棄するようにしておく。
【０１３２】
実施例１において、列車３が無線エリア２に進入した段階で行う処理と同様の処理を、ＤＬＣＸ＿ＧＳ１７が提供する無線エリアから離脱したことを検知した段階においても行うことで、当該ロストフレームの再送を実現することが可能となる。
【０１３３】
ＤＬＣＸ＿Ｔ３３が、２以上の通信コネクションを同時に維持できる場合には、ＤＬＣＸ＿Ｇ１３との通信コネクションを開放する処理を省略して、上記の処理を行うことも可能である。この場合、通信コネクションの開放処理、通信コネクションの確立処理時間を短縮することができ、メッセージをバッファに蓄える量が低減するので、通信連続性が向上するという効果が期待できる。
【０１３４】
この他、ＤＬＣＸ＿Ｔ３３が、２以上の通信コネクションを同時に維持する場合には、ＤＬＣＸ＿Ｇ１３との通信コネクションを維持したまま、ＤＬＣＸ＿ＧＳ１７との通信も並列して行うという方法もある。このような場合、ＤＬＣＸ＿Ｇ１３とＤＬＣＸ＿ＧＳ１７の通信帯域による転送速度の違いなどによって、下りフレームが逆順となってＡＩＲ＿Ｔ３２に到着する恐れがある。この場合、図５の車上側フレーム制御装置３２の下りフレームの通番の削除を行う通番給付・削除モジュール３２４−１２で通番を参照してフレーム昇順に並びかえる機能を具備して、フレームの順番を並び換えた後に、車上ネットワーク３０に送出する。
【０１３５】
上りフレームの場合も、同様の理屈で、図６の地上側フレーム制御装置１２の上りフレームの通番の削除を行う通番給付・削除モジュール１２７−１２で通番を参照してフレーム昇順に並びかえる機能を具備して、フレームの順番を並び換えた後に、ＦＡ１１、またはＳＷ１５に送出する。
【０１３６】
また、列車３の車上側ＤＬＣＸ送受信機３３は、パッシブスキャンまたはアクティブスキャンを行い、地上側ＤＬＣＸ送受信機だけでなく、無線ＬＡＮ基地局も探しつづける。ＤＬＣＸと無線ＬＡＮは、そもそも無線通信手段が異なるので、コネクションの開放、確立、再確立等の処理が不要となる以外は、上記の２つのＤＬＣＸを用いる方法に準ずる方法となる。
【０１３７】
ＤＬＣＸ＿Ｔ３３が、２以上の通信コネクションを同時に維持する場合において、ＡＩＲ＿Ｇ１２またはＡＩＲ＿Ｔ３２は、それぞれの通信コネクションごとに異なる種類のフレームを転送するように制御する。ＡＩＲ＿Ｇ１２またはＡＩＲ＿Ｔ３２において、受け取ったＩＰパケットのポート番号を調べて、そのポート番号に応じてフレームを転送する通信コネクションに切り替える処理を行なう。
【０１３８】
例えば、ＤＬＣＸ＿Ｇ１３、ＤＬＣＸ＿ＧＳ１７とＤＬＣＸ＿Ｔ３３がそれぞれ通信コネクションを維持している場合、または、ＤＬＣＸ＿Ｇ１３とＤＬＣＸ＿Ｔ３３、ＳＳ＿Ｇ１６とＳＳ＿Ｔ３７がそれぞれ通信コネクションを維持している場合において、ＤＬＣＸ＿ＧＳ１７とＤＬＣＸ＿Ｔ３３、または、ＳＳ＿Ｇ１６とＳＳ＿Ｔ３７の通信コネクションにおいては、特定のＴＣＰ、またはＵＤＰのポート番号を有するパケットを含むフレームだけの転送を行う。
【０１３９】
これによって、ファイル転送（ＦＴＰ）用のパケットは間欠的に転送を行い、ネットワーク管理用（ＳＮＭＰ等）のパケットは常時に転送を行う、というような処理を行うことが可能となる。
【実施例４】
【０１４０】
本実施例では、上記の実施例のようにある一方向にのみ進行する列車のような車両だけでなく、進行方向に制約がない自動車のような車両に適用可能で、かつ、同種または異種の無線通信手段が、地上側フレーム制御装置で終端されているような実施例３のような場合とは異なり、段階的に新たな無線通信手段が追加された場合に、無線エリア同士が包含、重畳、離散のどの状態になっているのか確定できないようなシステム構成となってしまった場合や、天候等の要因により、前記状態が揺らぐような場合においても、上記実施例１ないし３で示した安定した通信環境を提供する実施の態様について説明する。
【０１４１】
図１５は、本実施例のシステムの態様を示しているが、内容を明確に示すため、ＦＡ１、ＦＡ２，ＦＡ３の上位に接続されるＨＡ、ＡＩＲ−Ｇの下位に接続される無線ＬＡＮ基地局基地局は記載を省略している。また、車両４の内部には、図１９に示す車両３が具備する、無線ＬＡＮアダプタ、ＡＩＲ＿Ｔ、ＭＲ、および車上ネットワークによるシステムが構成されているものとする。
なお、本実施例では無線通信手段として、無線ＬＡＮを用いて説明しているが、これがＤＬＣＸやその他の無線通信手段であっても構わず、それらが混在していたとしてもなんら問題はない。
【０１４２】
図１５の上図においては、無線エリア１と無線エリア２の間のエリアにおいて、ＦＡ３，ＡＩＲ＿Ｇ３および無線ＬＡＮ基地局基地局によって、新たに無線エリア３がシステムに追加される様子を示している。車両４の方向が無線エリア１から無線エリア２に向かって進行するような場合には、これまでＡＩＲ＿Ｇ１からＡＩＲ＿Ｇ２へ行っていたフレームの前方無線エリアへのフォワードを、ＡＩＲ＿Ｇ１からＡＩＲ＿Ｇ３に、ＡＩＲ＿Ｇ３からＡＩＲ＿Ｇ２にフレーム転送を行うように変更する。
【０１４３】
ところが、図１５の下図において、前述したような各種の条件によって、稀に無線エリア３が無線エリア１に包含されてしまうようなケースが発生した場合、車両４は無線エリア１、無線エリア３の順番で進入した後、無線エリア１に再度進入することになる。このような場合、前方無線エリアへのフォワードが行えなくなるため、本発明の実施例１ないし３によって実現される、移動体連続通信が実施できなくなるという問題が発生する。この問題を解決する為には、ＡＩＲ＿Ｇ３からＡＩＲ＿Ｇ１へのフォワードも必要となることになる。
【０１４４】
図１６は、無線エリア１ないし４からなるシステムに、無線エリア５が追加された状況を示す図である。まず、ＡＩＲ＿Ｇ５は、図４の外部インターフェース群１３０を解してＧＰＳレシーバ１３０１、あるいはコンソール画面等を介してマニュアル操作による入力によって位置情報を取得すると、ＡＩＲ＿Ｇ５の位置情報を含むメッセージをＩＰブロードキャストを用いて、ＦＡ５、基幹ネットワーク１０、および各ＦＡを介して各ＡＩＲ＿Ｇに送信する。次に、各ＡＩＲ＿Ｇは、ＩＰブロードキャストのソースＩＰアドレスを参照して、自己の位置情報をＡＩＲ＿Ｇ５に返送する。このようにして、全てのＡＩＲ＿Ｇは相互に自己の位置情報の交換を行うことで、他のＡＩＲ＿Ｇの位置とＩＰアドレスを取得し、各無線エリア間で隣接する無線エリアの関係が各ＡＩＲ＿Ｇで把握されることになる。
【０１４５】
図１７に、ＡＩＲ＿Ｇ５が有する、周辺ＡＩＲ＿Ｇの情報を、地図情報とマッピングさせて表示した図を示す。なお、ＡＩＲ＿Ｇ５は必ずしも地図情報を必要とするわけではない。なお、「ＡＩＲ−Ｇ５：  ”１９２．１６８．２１．３５””１３９．３１．２９．２５７／３５．３５．００．５９２”」なる記載は、それぞれ、ＡＩＲ＿Ｇの識別名称、ＩＰアドレス、緯度・軽度情報を示す。ＡＩＲ＿Ｇ５は、他のＡＩＲ＿Ｇの位置情報から、隣接する無線エリアを把握することが可能となる。
【０１４６】
実施例１ないし３においては、車両の進行方向の無線エリアにフレームのフォワードを行うが、本実施例においては、隣接する無線エリアにフレームのフォワードを行う。
【０１４７】
車両４が進入しなかった無線エリアにフォワードされたフレームは使用されずに、所定の時間の経過後、廃棄される。
【０１４８】
このようなフレームフォワードを行うことで、進行方向が不確定であるような自動車のような対象にも適用可能であり、また、図１５の下図のように、ある無線エリアが、他の無線エリアに含まれるような事態になったとしても、少なくとも隣接していないゾーン間で包含の関係になるということまで考慮する必要はないので車両４は無線エリア１、無線エリア３の順番で進入した後、無線エリア１に再度進入することになった場合でも、無線エリア３から無線エリア１へフレームのフォワードが行われることで、連続通信方式は維持されることになる。
【０１４９】
しかし、このように隣接するＡＩＲ＿Ｇの全てにフレームのフォワードを行うことは、基幹ネットワーク１０の帯域を無駄に使用し、またＡＩＲ＿Ｇにフレームを格納する為に大量リソースを消費することを強いることになる。
【０１５０】
従って、移動体が、列車のように一方向のみに進行する場合には、進行方向と逆進行方向のＡＩＲ＿Ｇにフレームをフォワードしておけば十分であり、また、自動車のような場合であったとしても、高速道路などのように方向が一方向である場合も同様である。道路が分岐しているような場合は、その分岐している方向のみに転送を行えば足りる。
【０１５１】
また図１７の破線の円で示すように、自己のＡＩＲ＿Ｇの位置からある一定の距離にあるＡＩＲ＿Ｇのみに前方転送を行うことも可能である。
【産業上の利用可能性】
【０１５２】
移動体に対して連続した通信環境を提供するシステム全般において利用可能である。
【図面の簡単な説明】
【０１５３】
【図１】モバイルＩＰ方式の概要を示す図である。
【図２】第一の実施例におけるシステムの全体図を示す図である。
【図３】車上側フレーム制御装置３２のハードウェア構成を示す図である。
【図４】地上側フレーム制御装置３２のハードウェア構成を示す図である。
【図５】車上側フレーム制御装置３２のソフトウェア構成を示す図である。
【図６】図６に、地上側フレーム制御装置１２のソフトウェア構成を示す図である。
【図７】地上側フレーム制御装置３２によって生成されるフレームを示す図である。
【図８】地上系フレーム制御装置１２の通番管理テーブルを示す図である。
【図９】上りフレームの処理の概要を示す図である。
【図１０】上りフレームの処理の概要を示すシーケンス図である。
【図１１】下りフレームの処理の概要を示す図である。
【図１２】下りフレームの処理の概要を示すシーケンス図である。
【図１３】第二の実施例における上りフレームの処理を示すシステムの概要図である。
【図１４】一つのＦＡドメインに複数の無線通信手段を包含するシステム構成を示す図である。
【図１５】第四の実施例の実施のイメージを示す図である。
【図１６】第四の実施例のシステムの態様を示す図である。
【図１７】地上側フレーム制御装置が有する他の地上側フレーム制御装置の各種の情報の内容を説明する図である。
【図１８】最大ＭＴＵ値によるフレーム制御による制約を受けることなく、この値以上のフレームを転送することが可能とする方法を説明するための図である。
【符号の説明】
【０１５４】
業務用サーバ４１、業務用ネットワーク４０、
インターネットサーバ５１、インターネット５０、
ホームエージェントルータ１９、基幹ネットワーク１０、
地域ネットワーク２０、フォーリンエージェントルータ１１、
ＶＬＡＮスイッチ１５、地上側フレーム制御装置１２、
地上側ＤＬＣＸ送受信機１３、ＤＬＣＸ１４、
車上側フレーム制御装置３４、車上側ＤＬＣＸ送受信機３３、
車上側フレーム制御装置３２、モバイルルータ３１、車上サーバ３５、
旅客用パーソナルコンピュータ３６、車上ネットワーク３０、
ネットワークインタフェースカード３２２、
ネットワークインタフェースカード３２３、ＣＰＵ３２５、
メモリ３２４、ハードディスク３２８、
ハードディスクコントローラ３２７、外部インターフェース群３２９、
バス３２１、
ネットワークインタフェースカード１２２，１２３，１２４，１２５、
外部インターフェース群１３０、ハードディスク１２９、
ハードディスクコントローラ１２８、CPU１２６、メモリ１２７、
バス１２１、入出力装置制御ドライバ３２４−８、
上りフレーム一時記憶モジュール３２４−２４、
外部インターフェースドライバ群３２４−２２、
設定モジュール３２４−２０、
リモートサーバモジュール３２４−１８、
MTU制御モジュール３２４−１０、
通番給付・削除モジュール３２４−１２、
下りフレームロス検知・再送要求モジュール３２４−１４、
無線エリア移動検知モジュール３２４−１６、
再送処理モジュール３２４−２６、送信キュー３２４−６、
受信キュー３２４−４、通信管理モジュール３２４−４、
ネットワークインタフェースカード制御ドライバ３２４−２、
入出力装置制御ドライバ１２７−８、
フレーム書き換えモジュール１２７−２６、
再送処理モジュール１２７−３０、
フレームフォワードモジュール１２７−３２、
下りフレーム一時記憶モジュール１２７−３４、
フレームモニタモジュール１２７−２４、
外部インターフェースドライバ群１２７−２２、
設定モジュール１２７−２０、
リモートサーバモジュール１２７−１８、
ＭＴＵ制御モジュール１２７−１０、
通番給付・削除モジュール１２７−１２、
上りフレームロス検知・再送要求モジュール１２７−１４、
無線エリア移動検知モジュール１２７−１６、
通信管理モジュール１２７−４、
ネットワークインタフェースカード制御ドライバ１２７−２、
送信キュー１２７−６、上りメッセージ１−１、
フレームイーサネットフレーム１−２、車両４、GPSレシーバ１３０１。
【図１】
0004692021.tif 000002
【図２】
0004692021.tif 000003
【図３】
0004692021.tif 000004
【図４】
0004692021.tif 000005
【図５】
0004692021.tif 000006
【図６】
0004692021.tif 000007
【図７】
0004692021.tif 000008
【図８】
0004692021.tif 000009
【図９】
0004692021.tif 000010
【図１０】
0004692021.tif 000011
【図１１】
0004692021.tif 000012
【図１２】
0004692021.tif 000013
【図１３】
0004692021.tif 000014
【図１４】
0004692021.tif 000015
【図１５】
0004692021.tif 000016
【図１６】
0004692021.tif 000017
【図１７】
0004692021.tif 000018
【図１８】
0004692021.tif 000019