ライブモバイルカメラシステム
【課題】 リアルタイムのデジタルマルチメディアデータをより少ない伝送遅延と低い誤り率で送信し、異なるネットワークの複数のサーバ間で通信負荷を均衡化する。
【解決手段】 可変セグメントサイズの通信プロトコルと２層のサーバクラスタを備えたライブモバイルカメラシステムを提供する。可変セグメントサイズ通信プロトコルは、アプリケーション層においてデジタルデータをセグメントに区分し、インターネットプロトコル層においてこれらのセグメントをパケット化する。一態様において、この通信プロトコルは無線リンクで用いられ、ＵＤＰ（UserDatagram Protocol）と呼ばれるインターネットのプロトコルを使用する。２層のサーバクラスタは第１層に属する複数のサーバを含み、この第１層サーバの各々は１以上の第２層サーバを管理し、これら第２層サーバは他の第１層サーバの配下に再割り当てしても良い。
【解決手段】 可変セグメントサイズの通信プロトコルと２層のサーバクラスタを備えたライブモバイルカメラシステムを提供する。可変セグメントサイズ通信プロトコルは、アプリケーション層においてデジタルデータをセグメントに区分し、インターネットプロトコル層においてこれらのセグメントをパケット化する。一態様において、この通信プロトコルは無線リンクで用いられ、ＵＤＰ（UserDatagram Protocol）と呼ばれるインターネットのプロトコルを使用する。２層のサーバクラスタは第１層に属する複数のサーバを含み、この第１層サーバの各々は１以上の第２層サーバを管理し、これら第２層サーバは他の第１層サーバの配下に再割り当てしても良い。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、概して電子ネットワークに関し、特にクライアントとサーバ間の通信に関する。
【０００２】
【従来の技術】クライアント−サーバ間のネットワーク化技術の発達により、数多くの通信アプリケーションが利用可能になったが、現在のネットワーキングアプリケーションの殆どは限られた機能しか具備していない。典型的なアプリケーションは、１以上の独立したサーバと通信する数個のクライアントから成る。サーバはアクセス可能なデータをクライアントからのリクエストにより記憶するので、一般にアプリケーションサーバまたはデータベースサーバと呼ばれている。
【０００３】有用性のより大きいネットワーキングアプリケーションとしては、ライブモバイルカメラシステムがある。通常、ライブモバイルカメラシステムにはネットワークに接続されたモバイルクライアントが含まれている。このモバイルクライアントは通常無線リンクを介してネットワークに接続されているため、ネットワークとの有線接続を行わなくても場所から場所へ自由に移動できるようになっている。このモバイルクライアントは自機周辺の領域の視覚画像を取得するためのカメラに加え、自機の地理的位置を検索するためのＧＰＳ受信機をさらに備えている。つまり、モバイルクライアントは、視覚画像および地理情報をアプリケーションサーバに返送することが可能である。一方、ブラウザクライアントは、サーバシステムを介してモバイルクライアントに対してコマンドを送信することにより、モバイルクライアントの一定の機能を制御することが可能である。また、ブラウザクライアントは、特定のモバイルクライアントまたは複数のモバイルクライアントのグループをある領域の指定された地域において監視することもできる。ライブモバイルカメラシステムは、自動車交通量のライブレポート、店舗や銀行の監視、タクシーの追跡や警察活動の記録など多種の用途に適用し得る。
【０００４】一般に、ライブモバイルカメラシステムに用いられるネットワークはインターネットプロトコルを用いたインターネット網である。サーバシステムとモバイルクライアント間の通信にインターネットを用いる利点としては、現存のネットワークアプリケーションとの互換性が維持できる点である。また、標準化されたネットワーキングの装置を使うことができるので、インターネットを利用することにより、ライブモバイルカメラシステムをより容易に、安価に、そして迅速に実行することができる。
【０００５】しかしながら、ライブモバイルカメラシステムにインターネットを用いるにあたっての問題点として、現行のインターネットプロトコルはリアルタイムのデジタルマルチメディアデータを低誤り率で送信するには適していない点が挙げられる。周知のインターネットプロトコルには、ＴＣＰ（Transmission Control Protocol）と呼ばれるものがあり、このＴＣＰはデータを低い誤り率で確実に送信することができる。しかしながら、リアルタイムのデジタルマルチメディアデータを送信する際に無線リンクに依存するライブモバイルカメラシステムにこのＴＣＰを用いた場合、大きな伝送遅延が頻繁に発生する。この遅延の原因は、ＴＣＰが、有線の送信リンクと比較して伝送品質が不良である場合が多い無線システムで利用するように設計されたものではないことに拠る。むしろＴＣＰは、伝送誤りはすべてネットワークの輻輳が原因で発生すると仮定しており、送信リンクの低品質が原因で発生するデータ損失を想定していない。結果として、ＴＣＰは伝送の過程において損失または破損したデータパケットを繰り返し再送信するため著しい伝送遅延を招くことになる。
【０００６】別のインターネットプロトコルで既知のものとしては、ＵＤＰ（User Datagram Protocol）と呼ばれるものがある。ＵＤＰは、そのデフォルト設定の処理手順において、損失または破損したパケットをすべて無視するようになっているためＴＣＰに比べ速くデータを伝送することができる。しかしながら、ＵＤＰは信頼性の低いプロトコルであるため、高い誤り率が許容されないライブモバイルカメラシステムのようなアプリケーションには通常適していない。このように、リアルタイムのデジタルマルチメディアデータをより少ない伝送遅延と低い誤り率で送信する方法が求められている。
【０００７】また、ライブモバイルカメラシステムは、送信されたリアルタイムのマルチメディアデータを受信するデータサーバ側にも重い負荷をかけてしまう。従来からのクライアント−サーバ間のネットワークにおいては、多数のクライアントと通信するために単数のサーバが用いられる。大量の通信負荷が予測される場合には、バックアップサーバを備えることにより、メインサーバの混雑時やメインサーバ全体がオフラインになった際に通信の一部または全部をバックアップサーバが処理できるようにしている場合もある。
【０００８】しかしながら、従来型のサーバネットワークは、異なるネットワークにおいて数個のサーバ間で通信負荷を均衡化することができない。複数のサーバ間での負荷の均衡化は多くのネットワーキングアプリケーションにおいて有用であるが、特にライブモバイルカメラシステムでは大きな通信負荷が予測され且つ高い信頼性が必要とされるのでこのようなアプリケーションにおいては特に重要である。つまり、異なるネットワークの複数のサーバ間で通信負荷を均衡化するサーバクラスタが必要とされている。
【０００９】
【発明が解決しようとする課題】この発明は、以上説明した従来技術の問題点に鑑みてなされたものであり、リアルタイムのデジタルマルチメディアデータをより少ない伝送遅延と低い誤り率で送信する方法および異なるネットワークの複数のサーバ間で通信負荷を均衡化するサーバクラスタを提供することを目的とする。
【００１０】
【課題を解決するための手段】上記課題を解決するため、本発明に係るライブモバイルカメラシステムは、無線リンクに特に好適な通信プロトコル、および異なるネットワークにおける１以上のサーバ間の通信負荷を均衡化するためのサーバクラスタを提供する。
【００１１】本発明に係る通信プロトコルは、アプリケーション層においてリアルタイムのデジタルマルチメディアデータをセグメントに区分し、インターネットプロトコル層においてパケット化する。このセグメントのサイズは、セグメントの伝送中に発生するパケット誤りに応じて可変である。また、インターネットプロトコル層としてはＵＤＰ(User Datagram Protocol)を用いるのが好ましい。
【００１２】本発明の実施の一態様において、上記通信プロトコルは、第１のアプリケーション層においてデジタルデータをセグメントに区分し、第１のインターネットプロトコル層において前記セグメントをパケット化し、第２のインターネットプロトコル層において前記パケットを再組み立てし、第２のアプリケーション層において前記セグメントを再組み立てることを特徴としている。好ましくは、パケット化と前記パケットの再組み立ての過程の間に、無線リンクを介して前記パケットを送受信する過程を有する。
【００１３】別の好ましい態様において、前記パケットに誤りがあるか否か検査し、前記パケット検査の結果に応じて前記セグメントサイズを変更する。この場合、前記パケット検査により前記デジタルデータにパケット誤りが検出されなかった場合、前記セグメントサイズを拡大し、前記パケット検査により前記デジタルデータにパケット誤りが検出された場合、前記セグメントサイズを縮小させる。このセグメントサイズは、下限と上限の間で変更されるようにしても良い。さらに、前記パケット検査によりデジタルデータにパケット誤りが検出されず且つ前記セグメントサイズが前記上限である場合、前記セグメントサイズは変更されず、前記パケット検査によりデジタルデータにパケット誤りが検出されず且つ前記セグメントサイズが前記上限ではない場合、前記セグメントサイズを拡大し、前記パケット検査によりデジタルデータにパケット誤りが検出され且つ前記セグメントサイズが下限の場合、前記セグメントサイズは変更されず、前記パケット検査によりデジタルデータにパケット誤りが検出され且つ前記セグメントサイズが下限ではない場合、前記セグメントサイズを縮小する。
【００１４】さらに別の好ましい態様において、本発明に係る通信プロトコルは、前記パケットに誤りがあるか否かを検査し、パケット誤りを有しないセグメントは再送信せず、パケット誤りを有するセグメントのみを再送信することを特徴としている。好ましくは、前記パケット検査の結果に応じて前記セグメントの少なくとも１を、前記第１のインターネットプロトコル層からではなく前記第１のアプリケーション層から再送信する。また、モバイルクライアント周辺の視覚環境のデジタル化画像である前記デジタルデータはライブモバイルカメラシステムにおいて生成するのが好ましい。さらに、前記パケット化と前記パケットの再組み立てとの過程の間に、無線リンクを介して前記パケットを送受信する過程を有するようにしてもよい。
【００１５】本発明に係るサーバクラスタは、第１層サーバおよび第２層サーバを有する。第１層サーバの各々は、１以上の第２層サーバを管理する。第２層サーバに対する通信負荷は、他の第２層サーバより負荷が少ない第２層サーバに通信接続を転送することにより均衡化される。また、第１層サーバは、第２層サーバを他の第１層サーバの配下に再割り当てすることにより第１層サーバのダウンタイムや他の負荷不均衡の問題に対応してもよい。
【００１６】本発明の実施の一態様において、上記サーバクラスタは、第１層および第２層を有するサーバクラスタであって、前記第１層および前記第２層の各々は少なくとも１のサーバを有し、前記第１層は前記第２層を管理し、前記第１層は通信接続を求める要求を受信し、前記第２層に前記要求を送信することにより、前記第２層が前記要求に応答することを特徴としている。好ましくは、前記第２層は、少なくとも２のサーバを有することを特徴とする。各第２層サーバは前記要求に応答し、最初の第２層サーバが応答すると通信接続が設定される。
【００１７】さらに別の好ましい態様において、前記第１層は少なくとも２のサーバから成り、前記第１層サーバの各々は少なくとも２の第２層サーバを管理するようにしてもよい。この場合、前記複数の第１層サーバの１のサーバは自身が管理する前記複数の第２層サーバの１のサーバを前記複数の第１層サーバの他の１のサーバの配下に再割り当てしてもよい。この再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定することができる。
【００１８】好ましくは、前記第１層サーバの少なくとも２のサーバが、インターネットプロトコルを用いて互いに通信し、前記少なくとも２のサーバは異なるサーバネットワークである。
【００１９】さらに別の好ましい態様におけるサーバクラスタでは、要求者が前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶するようにしてもよい。この場合、前記要求者は記憶した前記複数の第１層サーバの識別情報を更新し、前記要求者は前記要求の送信先として前記複数の第１層サーバのいずれかを選択することができる。好ましくは、前記第１層は、インターネットプロトコルを用いて前記第２層と通信し、前記第１層と前記第２層は異なるサーバネットワークである。この場合、前記第２層の少なくとも２のサーバは、異なるサーバネットワークとしてもよい。
【００２０】さらに別の態様において、無線リンクが前記要求された通信接続に連結されてもよい。また、ライブモバイルカメラシステムはカメラ付のモバイルクライアントを有し、前記カメラにより前記モバイルクライアント周辺の視覚画像を撮影し、前記画像は前記通信接続を介して送信されるようにしてもよい。
【００２１】なお、本発明に係るライブモバイルカメラシステムは、上記諸態様を挙げた通信プロトコルおよびサーバクラスタを様々な組み合わせにおいて含む種々の態様を取り得ることは、本願明細書に開示された本発明の実施方法とを検討することにより、当業者にとって明らかであろう。
【００２２】
【発明の実施の形態】添付図のうち特に図１を参照しながら、ライブモバイルカメラシステム１０について説明する。ライブモバイルカメラシステム１０により、ユーザは、モバイルクライアント１６周辺の視覚環境およびモバイルクライアント１６の地理的位置を監視することが可能になる。一般的に、ユーザはデータサーバクラスタ２０、データベースサーバ２２、地図サーバ２４、ウェブサーバ２６を含むサーバシステムおよびブラウザクライアント２８を介してモバイルクライアント１６と通信する。
【００２３】ライブモバイルカメラシステム１０は、本願明細書で説明されている構成要素をすべて含む形態であっても、一部のみを含む形態であっても良い。また、本願明細書に説明されていない他の構成要素を含む形態も取り得る。一般に、ライブモバイルカメラシステム１０はモバイルクライアント１６を含む。このモバイルクライアント１６は標準のラップトップ型ＰＣでも良いが、自動車に実装されるかモニター局に収容された特化型コンピュータが好ましい。モバイルクライアント１６は自機周辺の視覚環境のリアルタイムのデジタルマルチメディアデータを受け取るためのカメラ１２に接続されている。また、モバイルクライアント１６は、自機の地理的位置のデータを取得するためのＧＰＳ（Global Positioning System）受信機に接続されている。
【００２４】ブラウザクライアント２８は、ＨＴＴＰ（Hypertext Transfer Protocol）を用いるデータサーバクラスタ２０、データベースサーバ２２、地図サーバ２４、ウェブサーバ２６を含むサーバシステムを介してモバイルクライアント１６を監視する。モバイルクライアント１６は、地上電話線などの各種通信接続を介してこのサーバシステムに接続されてもよい。しかしながら、無線リンクを用いた方がモバイルクライアント１６の自由度が向上するのでより好ましい。また、以下に説明するが、無線リンクによるリアルタイムのデジタルマルチメディアデータ通信の信頼性と効率的なスループットを向上させるために、可変セグメントサイズ通信プロトコル７０が用いられる。
【００２５】データサーバクラスタ２０は、モバイルクライアント１６からデータを受信する他、ブラウザクライアント２８からモバイルクライアント１６にデータを送信する。後に説明するが、信頼性およびデータサーバクラスタ２０の設備能力を向上させる目的で、データサーバクラスタ２０を２層に構成して設けている。また、データサーバクラスタ２０は、モバイルクライアント１６が位置し得る地理的位置の典型例として複数の地図を格納する地図サーバ２４に接続されている。
【００２６】データベースサーバ２２および地図サーバ２４は、ブラウザクライアント２８からコマンドを受け取るウェブサーバ２６に接続されており、要求されたデータをブラウザクライアント２８に送信する。ブラウザクライアント２８は、データサーバクラスタ２０、データベースサーバ２２、地図サーバ２４、ウェブサーバ２６を含むサーバシステムとの通信が可能で、ユーザからの入力の受付ができ、要求されたデータの表示が可能であればいずれの種類のコンピュータでもよい。
【００２７】上記から明らかなように、ライブモバイルカメラシステム１０は、ユーザが、離れた位置から、ある場所を視覚的に監視したい場合、各種適用例において有用である。また、ライブモバイルカメラシステム１０により、ユーザはモバイルクライアント１６が収集した視覚画像の地理的な位置を監視することが可能になる。さらに、モバイルクライアント１６とサーバシステム（データサーバクラスタ２０、データベースサーバ２２、地図サーバ２４、ウェブサーバ２６を含む）間で無線リンクを用いると、更なる自由度が可能となり、モバイルクライアント１６が複数の場所間を移動できようになり、ユーザがこれらの複数の場所を監視するのが容易になる。
【００２８】次に図２を参照して、可変セグメントサイズ通信プロトコル７０について説明する。一般的に、通信プロトコル７０は、リアルタイムのデジタルマルチメディアデータがインターネットプロトコル層においてパケット化される前にこのデジタルデータを小部分にセグメント化する。このセグメントの大きさは、無線リンクの品質に応じて後のステップで変更可能である。可変セグメントサイズ通信プロトコル７０は、ＵＤＰ（User Datagram Protocol）という標準インターネットプロトコル層と共に用いる。一般に、ＵＤＰはＴＣＰ（Transmission Control Protocol）に比べ伝送速度が速い。何故なら、ＵＤＰにおいては、デジタルデータフレームからデータパケットが損失または損傷した場合に自動的にデータを再送信する構成になっていないからである。従って、アプリケーション層は、損失または損傷パケットを含むセグメントのみを再送信することにより、無線リンクにおける送信効率が向上するようになっている。
【００２９】可変セグメントサイズ通信プロトコル７０はまず、リアルタイムのデジタルマルチメディアデータフレームの生成手順から開始される（Ｓ４０）。各種のリアルタイムのデジタルマルチメディアデータを可変セグメントサイズ通信プロトコル７０に用いることができるが、モバイルクライアント１６がライブモバイルカメラシステム１０において生成したリアルタイムのデジタルマルチメディアデータは可変セグメントサイズ通信プロトコル７０に特に適している。例えば、典型的なデジタルマルチメディアデータフレームのサイズは約１０キロバイトである。このデジタルマルチメディアデータフレームは、アプリケーション層によって小部分つまりセグメントにセグメント化される（Ｓ４２）。すなわち、デフォルトのセグメントサイズが例えば５００バイトの場合、１０キロバイトのデジタルデータフレームが２０セグメント生成されることになる。尚、好ましくは、デフォルトのセグメントサイズは、アプリケーションシステムを設計する際に設定するのが良い。
【００３０】次に、ＵＤＰ層において、各セグメントは、ネットワーク上を送信可能な数個の離散的データパケットに分割される（Ｓ４４）。リアルタイムのデジタルマルチメディアデータパケットを無線リンクを介して送信する場合はＵＤＰ層を用いるのが好ましい。何故なら、ＵＤＰはＴＣＰに比べ、送信リンクの品質が劣悪な場合において伝送速度がかなり高速だからである。無線リンクを本発明に用いた場合、次に、データパケットがモバイルクライアントから送信される（Ｓ４６）。
【００３１】次に、無線データパケットは第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃのいずれか、または適当な受信機によって受信される（Ｓ４８）。そして、データパケットは、元のセグメントに再組み立てされる（Ｓ５０）。すなわち、前述の例において、データパケットは元の２０セグメントに別個に再組み立てされる。次に、各セグメントを検査してセグメント内のデータパケットで損傷または損失しているものがあるか否かを判定する（Ｓ５２）。セグメントに損傷または損失データパケットがあると判定された場合、モバイルクライアントに対してメッセージを返送し、損傷また損失データパケットを含む特定のデータセグメントを再送信するよう要求する（Ｓ４７）。すべてのセグメントがデータパケットの損傷または損失なしに送信された場合、セグメントは原データフレームに再組み立てされる（Ｓ５４）。
【００３２】次に、セグメントサイズを検査して、次のリアルタイムのデジタルマルチメディアデータフレーム送信のためのセグメントサイズを最適化する。送信リンクの品質が劣悪な場合には、パケット誤りの可能性を最小化し且つ再送信が必要になった場合のセグメントのサイズを小さくするために、セグメントサイズは小さい方がよい。一方、ネットワークが目的地にセグメントをルーティングする際に用いられるヘッダを各セグメントに個々に付加する必要があるので、セグメントを小さくすると伝送効率が低下することになる。従って、送信リンクの品質が良い場合には、大きめのセグメントサイズが良い。
【００３３】従って、最初のリアルタイムのデジタルマルチメディアデータフレームのデータパケットで送信中に損傷または損失したものがない場合、セグメントサイズは許容可能と判断されるか、あるいは小さすぎると判断される。そして、送信システムに適していると考えられているセグメントサイズの最大値を示す限界値と、現在のセグメントサイズの値が比較される（Ｓ５６）。現在のセグメントサイズがすでに上限に達しているのであれば、セグメントサイズは変更されず、許容最大値のまま据え置かれる（Ｓ５８）。一方、現在のセグメントサイズが上限に達していない場合、セグメントサイズを１０％拡大する。
【００３４】同様に、最初のリアルタイムのデジタルマルチメディアデータフレームのデータパケットで送信中に損傷または損失したものが存在した場合、セグメントサイズが大きすぎると判断される。そして、現在のセグメントサイズの値が、送信システムに適していると考えられるセグメントサイズの最小値を示す限界値と比較される（Ｓ６２）。現在のセグメントサイズがすでに下限に達している場合、セグメントサイズは許容最小値のまま設定される（Ｓ６４）。しかしながら、現在のセグメントサイズが下限に達していない場合、セグメントサイズは１０％縮小される（Ｓ６６）。
【００３５】次に、新セグメントサイズはモバイルクライアント１６に返送されて次のリアルタイムのデジタルマルチメディアデータフレームで使用される（Ｓ６８）。このように、セグメントサイズはデジタルデータフレームの送信の度に検査され、上限と下限の範囲内でセグメントの最適なサイズを判定する。すなわち、可変セグメントサイズ通信プロトコル７０により、無線リンクに特に好適な迅速かつ信頼性の高い送信が可能となることは明白である。
【００３６】図１、３、４を参照しながら、２層データサーバクラスタ２０について説明する。２層データサーバクラスタ２０は、第１層サーバＴ１ａ、Ｔ１ｂと、この第１層サーバに管理される第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃ、Ｔ２ｄ、Ｔ２ｅ、Ｔ２ｆとを有する。２層のサーバ間の関係、および２層データサーバクラスタ２０とライブモバイルカメラシステム１０との関係の概要は図１に示すとおりである。従って、通信接続の要求は第１層サーバであるＴ１ａに受信される。通常、１以上の第１層サーバＴ１ａ、Ｔ１ｂが設けられ、各第１層サーバＴ１ａ、Ｔ１ｂは多くの第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃ、Ｔ２ｄ、Ｔ２ｅ、Ｔ２ｆを管理している。
【００３７】第１層サーバであるＴ１ａのアドレスは通常モバイルクライアント１６において通信相手のデフォルト第１層サーバＴ１ａとして記憶される。また、モバイルクライアント１６の設定は、バックアップの第１層サーバＴ１ｂのアドレスに変更してもよいし、あるいは、デフォルトの第１層サーバＴ１ａを代替第１層サーバＴ１ｂに変更して主要第１層サーバＴ１ａのダウンタイムを吸収したり、他の負荷不均衡の問題に対処するようにしてもよい。
【００３８】第１層サーバＴ１ａが通信接続の要求を受信すると、第１層サーバＴ１ａは該要求と要求者の識別情報を第１層サーバＴ１ａが管理する第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃの各々に送信する。図３に示すとおり、第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃの各々はモバイルクライアント１６に応答することにより、通信接続のための各サーバの可用性を示し、第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃ各々の各アドレスを提供する。第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃ各々の通信負荷とその他可用性状況の結果、第２層サーバＴ２ｃが他の第２層サーバＴ２ａ、Ｔ２ｂより前に該通信接続要求に応答する。そして、モバイルクライアント１６は、最初に応答した第２層サーバＴ２ｃとの通信接続を設定し、後で応答した第２層サーバＴ２ａ、Ｔ２ｂとの通信を終了する。次に、通信接続を設定した第２層サーバＴ２ｃは、受信したデータをデータベースサーバ２２、地図サーバ２４、ウェブサーバ２６に送信することにより、モバイルクライアント１６とブラウザクライアント２８間のリンクを提供する。
【００３９】図４は、第１層サーバＴ１ａ、Ｔ１ｂと第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃ、Ｔ２ｄ、Ｔ２ｅ、Ｔ２ｆ間の管理／被管理の関係が、第１層サーバのダウンタイム吸収やその他負荷均衡化などの目的で変化した場合を示している。第１層サーバＴ１ａが今にも停止しそうな場合、サーバＴ１ａは配下にある第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃを他の第１層サーバＴ１ｂの配下に再配置する。つまり、停止を間近に控えた第１層サーバＴ１ａは、第１層サーバＴ１ｂに対して、第２層サーバＴ２ａを配下に置いて管理するようにとの要求を送信する。停止予定の第１層サーバＴ１ａと再配置された第２層サーバＴ２ａの管理／被管理関係はここで終了する。停止予定の第１層サーバＴ１ａは、配下の第２層サーバの残りのＴ２ｂ、Ｔ２ｃが再配置されるまで、他の第１層サーバに要求を送信することにより、再配置処理を繰り返す。
【００４０】以上の点より、２層データサーバクラスタ２０において、より負荷の少ない他のサーバに通信接続を転嫁することにより、多数のサーバ間の負荷均衡を保つことが可能になることは明らかである。データサーバクラスタ２０が通信負荷を均衡させることが可能なので、従来型のサーバシステムに比べより高い負荷の総トラフィックを処理することが可能になる。従って、処理速度のより速い高価なサーバが現在処理しているトラフィック許容荷重と同じ処理量を、より小型で安価なサーバを使って達成することができる。また、この２層データサーバクラスタ２０では、第１層サーバと第２層サーバ間の通信および第１層サーバ間の通信に標準のインターネット通信プロトコルを用いることができる。つまり、第１層サーバと第２層サーバは互いに異なる離散的ネットワークであっても良いことになる。同様に、第１層サーバの各々の配下に配置されるグループ内の第２層サーバの各々も、別個の離散的サーバネットワークであってもよい。
【００４１】本発明の好ましい実施形態を説明してきたが、本発明はこの実施形態に限定されず、発明から逸脱しない範囲内で修正が可能である。発明の範囲は付記された請求項に定義され、請求項の意味の範囲内に該当する装置はすべて、文字通りであるか均等物であるかにかかわらず、該請求項に包含される。
【００４２】
【発明の効果】以上説明したように、本発明に係るライブモバイルカメラシステムによれば、リアルタイムのデジタルマルチメディアデータをより少ない伝送遅延と低い誤り率で送信することができ、また、異なるネットワークの複数のサーバ間で通信負荷を均衡化することが可能になる。
【図面の簡単な説明】
本発明は、その構成と動作方法を含み、添付図中において大方にして図示されている。
【図１】 ライブモバイルカメラシステムのブロック図である。
【図２】 通信プロトコルのフローチャートである。
【図３】 ライブモバイルカメラシステムのブロック図であり、移動局が第２層サーバと通信接続を設定する場合を示している。
【図４】 サーバクラスタのブロック図であり、第１層サーバが第２層サーバを他の第１層サーバの配下に再割り当てする場合を示している。
【０００１】
【発明の属する技術分野】本発明は、概して電子ネットワークに関し、特にクライアントとサーバ間の通信に関する。
【０００２】
【従来の技術】クライアント−サーバ間のネットワーク化技術の発達により、数多くの通信アプリケーションが利用可能になったが、現在のネットワーキングアプリケーションの殆どは限られた機能しか具備していない。典型的なアプリケーションは、１以上の独立したサーバと通信する数個のクライアントから成る。サーバはアクセス可能なデータをクライアントからのリクエストにより記憶するので、一般にアプリケーションサーバまたはデータベースサーバと呼ばれている。
【０００３】有用性のより大きいネットワーキングアプリケーションとしては、ライブモバイルカメラシステムがある。通常、ライブモバイルカメラシステムにはネットワークに接続されたモバイルクライアントが含まれている。このモバイルクライアントは通常無線リンクを介してネットワークに接続されているため、ネットワークとの有線接続を行わなくても場所から場所へ自由に移動できるようになっている。このモバイルクライアントは自機周辺の領域の視覚画像を取得するためのカメラに加え、自機の地理的位置を検索するためのＧＰＳ受信機をさらに備えている。つまり、モバイルクライアントは、視覚画像および地理情報をアプリケーションサーバに返送することが可能である。一方、ブラウザクライアントは、サーバシステムを介してモバイルクライアントに対してコマンドを送信することにより、モバイルクライアントの一定の機能を制御することが可能である。また、ブラウザクライアントは、特定のモバイルクライアントまたは複数のモバイルクライアントのグループをある領域の指定された地域において監視することもできる。ライブモバイルカメラシステムは、自動車交通量のライブレポート、店舗や銀行の監視、タクシーの追跡や警察活動の記録など多種の用途に適用し得る。
【０００４】一般に、ライブモバイルカメラシステムに用いられるネットワークはインターネットプロトコルを用いたインターネット網である。サーバシステムとモバイルクライアント間の通信にインターネットを用いる利点としては、現存のネットワークアプリケーションとの互換性が維持できる点である。また、標準化されたネットワーキングの装置を使うことができるので、インターネットを利用することにより、ライブモバイルカメラシステムをより容易に、安価に、そして迅速に実行することができる。
【０００５】しかしながら、ライブモバイルカメラシステムにインターネットを用いるにあたっての問題点として、現行のインターネットプロトコルはリアルタイムのデジタルマルチメディアデータを低誤り率で送信するには適していない点が挙げられる。周知のインターネットプロトコルには、ＴＣＰ（Transmission Control Protocol）と呼ばれるものがあり、このＴＣＰはデータを低い誤り率で確実に送信することができる。しかしながら、リアルタイムのデジタルマルチメディアデータを送信する際に無線リンクに依存するライブモバイルカメラシステムにこのＴＣＰを用いた場合、大きな伝送遅延が頻繁に発生する。この遅延の原因は、ＴＣＰが、有線の送信リンクと比較して伝送品質が不良である場合が多い無線システムで利用するように設計されたものではないことに拠る。むしろＴＣＰは、伝送誤りはすべてネットワークの輻輳が原因で発生すると仮定しており、送信リンクの低品質が原因で発生するデータ損失を想定していない。結果として、ＴＣＰは伝送の過程において損失または破損したデータパケットを繰り返し再送信するため著しい伝送遅延を招くことになる。
【０００６】別のインターネットプロトコルで既知のものとしては、ＵＤＰ（User Datagram Protocol）と呼ばれるものがある。ＵＤＰは、そのデフォルト設定の処理手順において、損失または破損したパケットをすべて無視するようになっているためＴＣＰに比べ速くデータを伝送することができる。しかしながら、ＵＤＰは信頼性の低いプロトコルであるため、高い誤り率が許容されないライブモバイルカメラシステムのようなアプリケーションには通常適していない。このように、リアルタイムのデジタルマルチメディアデータをより少ない伝送遅延と低い誤り率で送信する方法が求められている。
【０００７】また、ライブモバイルカメラシステムは、送信されたリアルタイムのマルチメディアデータを受信するデータサーバ側にも重い負荷をかけてしまう。従来からのクライアント−サーバ間のネットワークにおいては、多数のクライアントと通信するために単数のサーバが用いられる。大量の通信負荷が予測される場合には、バックアップサーバを備えることにより、メインサーバの混雑時やメインサーバ全体がオフラインになった際に通信の一部または全部をバックアップサーバが処理できるようにしている場合もある。
【０００８】しかしながら、従来型のサーバネットワークは、異なるネットワークにおいて数個のサーバ間で通信負荷を均衡化することができない。複数のサーバ間での負荷の均衡化は多くのネットワーキングアプリケーションにおいて有用であるが、特にライブモバイルカメラシステムでは大きな通信負荷が予測され且つ高い信頼性が必要とされるのでこのようなアプリケーションにおいては特に重要である。つまり、異なるネットワークの複数のサーバ間で通信負荷を均衡化するサーバクラスタが必要とされている。
【０００９】
【発明が解決しようとする課題】この発明は、以上説明した従来技術の問題点に鑑みてなされたものであり、リアルタイムのデジタルマルチメディアデータをより少ない伝送遅延と低い誤り率で送信する方法および異なるネットワークの複数のサーバ間で通信負荷を均衡化するサーバクラスタを提供することを目的とする。
【００１０】
【課題を解決するための手段】上記課題を解決するため、本発明に係るライブモバイルカメラシステムは、無線リンクに特に好適な通信プロトコル、および異なるネットワークにおける１以上のサーバ間の通信負荷を均衡化するためのサーバクラスタを提供する。
【００１１】本発明に係る通信プロトコルは、アプリケーション層においてリアルタイムのデジタルマルチメディアデータをセグメントに区分し、インターネットプロトコル層においてパケット化する。このセグメントのサイズは、セグメントの伝送中に発生するパケット誤りに応じて可変である。また、インターネットプロトコル層としてはＵＤＰ(User Datagram Protocol)を用いるのが好ましい。
【００１２】本発明の実施の一態様において、上記通信プロトコルは、第１のアプリケーション層においてデジタルデータをセグメントに区分し、第１のインターネットプロトコル層において前記セグメントをパケット化し、第２のインターネットプロトコル層において前記パケットを再組み立てし、第２のアプリケーション層において前記セグメントを再組み立てることを特徴としている。好ましくは、パケット化と前記パケットの再組み立ての過程の間に、無線リンクを介して前記パケットを送受信する過程を有する。
【００１３】別の好ましい態様において、前記パケットに誤りがあるか否か検査し、前記パケット検査の結果に応じて前記セグメントサイズを変更する。この場合、前記パケット検査により前記デジタルデータにパケット誤りが検出されなかった場合、前記セグメントサイズを拡大し、前記パケット検査により前記デジタルデータにパケット誤りが検出された場合、前記セグメントサイズを縮小させる。このセグメントサイズは、下限と上限の間で変更されるようにしても良い。さらに、前記パケット検査によりデジタルデータにパケット誤りが検出されず且つ前記セグメントサイズが前記上限である場合、前記セグメントサイズは変更されず、前記パケット検査によりデジタルデータにパケット誤りが検出されず且つ前記セグメントサイズが前記上限ではない場合、前記セグメントサイズを拡大し、前記パケット検査によりデジタルデータにパケット誤りが検出され且つ前記セグメントサイズが下限の場合、前記セグメントサイズは変更されず、前記パケット検査によりデジタルデータにパケット誤りが検出され且つ前記セグメントサイズが下限ではない場合、前記セグメントサイズを縮小する。
【００１４】さらに別の好ましい態様において、本発明に係る通信プロトコルは、前記パケットに誤りがあるか否かを検査し、パケット誤りを有しないセグメントは再送信せず、パケット誤りを有するセグメントのみを再送信することを特徴としている。好ましくは、前記パケット検査の結果に応じて前記セグメントの少なくとも１を、前記第１のインターネットプロトコル層からではなく前記第１のアプリケーション層から再送信する。また、モバイルクライアント周辺の視覚環境のデジタル化画像である前記デジタルデータはライブモバイルカメラシステムにおいて生成するのが好ましい。さらに、前記パケット化と前記パケットの再組み立てとの過程の間に、無線リンクを介して前記パケットを送受信する過程を有するようにしてもよい。
【００１５】本発明に係るサーバクラスタは、第１層サーバおよび第２層サーバを有する。第１層サーバの各々は、１以上の第２層サーバを管理する。第２層サーバに対する通信負荷は、他の第２層サーバより負荷が少ない第２層サーバに通信接続を転送することにより均衡化される。また、第１層サーバは、第２層サーバを他の第１層サーバの配下に再割り当てすることにより第１層サーバのダウンタイムや他の負荷不均衡の問題に対応してもよい。
【００１６】本発明の実施の一態様において、上記サーバクラスタは、第１層および第２層を有するサーバクラスタであって、前記第１層および前記第２層の各々は少なくとも１のサーバを有し、前記第１層は前記第２層を管理し、前記第１層は通信接続を求める要求を受信し、前記第２層に前記要求を送信することにより、前記第２層が前記要求に応答することを特徴としている。好ましくは、前記第２層は、少なくとも２のサーバを有することを特徴とする。各第２層サーバは前記要求に応答し、最初の第２層サーバが応答すると通信接続が設定される。
【００１７】さらに別の好ましい態様において、前記第１層は少なくとも２のサーバから成り、前記第１層サーバの各々は少なくとも２の第２層サーバを管理するようにしてもよい。この場合、前記複数の第１層サーバの１のサーバは自身が管理する前記複数の第２層サーバの１のサーバを前記複数の第１層サーバの他の１のサーバの配下に再割り当てしてもよい。この再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定することができる。
【００１８】好ましくは、前記第１層サーバの少なくとも２のサーバが、インターネットプロトコルを用いて互いに通信し、前記少なくとも２のサーバは異なるサーバネットワークである。
【００１９】さらに別の好ましい態様におけるサーバクラスタでは、要求者が前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶するようにしてもよい。この場合、前記要求者は記憶した前記複数の第１層サーバの識別情報を更新し、前記要求者は前記要求の送信先として前記複数の第１層サーバのいずれかを選択することができる。好ましくは、前記第１層は、インターネットプロトコルを用いて前記第２層と通信し、前記第１層と前記第２層は異なるサーバネットワークである。この場合、前記第２層の少なくとも２のサーバは、異なるサーバネットワークとしてもよい。
【００２０】さらに別の態様において、無線リンクが前記要求された通信接続に連結されてもよい。また、ライブモバイルカメラシステムはカメラ付のモバイルクライアントを有し、前記カメラにより前記モバイルクライアント周辺の視覚画像を撮影し、前記画像は前記通信接続を介して送信されるようにしてもよい。
【００２１】なお、本発明に係るライブモバイルカメラシステムは、上記諸態様を挙げた通信プロトコルおよびサーバクラスタを様々な組み合わせにおいて含む種々の態様を取り得ることは、本願明細書に開示された本発明の実施方法とを検討することにより、当業者にとって明らかであろう。
【００２２】
【発明の実施の形態】添付図のうち特に図１を参照しながら、ライブモバイルカメラシステム１０について説明する。ライブモバイルカメラシステム１０により、ユーザは、モバイルクライアント１６周辺の視覚環境およびモバイルクライアント１６の地理的位置を監視することが可能になる。一般的に、ユーザはデータサーバクラスタ２０、データベースサーバ２２、地図サーバ２４、ウェブサーバ２６を含むサーバシステムおよびブラウザクライアント２８を介してモバイルクライアント１６と通信する。
【００２３】ライブモバイルカメラシステム１０は、本願明細書で説明されている構成要素をすべて含む形態であっても、一部のみを含む形態であっても良い。また、本願明細書に説明されていない他の構成要素を含む形態も取り得る。一般に、ライブモバイルカメラシステム１０はモバイルクライアント１６を含む。このモバイルクライアント１６は標準のラップトップ型ＰＣでも良いが、自動車に実装されるかモニター局に収容された特化型コンピュータが好ましい。モバイルクライアント１６は自機周辺の視覚環境のリアルタイムのデジタルマルチメディアデータを受け取るためのカメラ１２に接続されている。また、モバイルクライアント１６は、自機の地理的位置のデータを取得するためのＧＰＳ（Global Positioning System）受信機に接続されている。
【００２４】ブラウザクライアント２８は、ＨＴＴＰ（Hypertext Transfer Protocol）を用いるデータサーバクラスタ２０、データベースサーバ２２、地図サーバ２４、ウェブサーバ２６を含むサーバシステムを介してモバイルクライアント１６を監視する。モバイルクライアント１６は、地上電話線などの各種通信接続を介してこのサーバシステムに接続されてもよい。しかしながら、無線リンクを用いた方がモバイルクライアント１６の自由度が向上するのでより好ましい。また、以下に説明するが、無線リンクによるリアルタイムのデジタルマルチメディアデータ通信の信頼性と効率的なスループットを向上させるために、可変セグメントサイズ通信プロトコル７０が用いられる。
【００２５】データサーバクラスタ２０は、モバイルクライアント１６からデータを受信する他、ブラウザクライアント２８からモバイルクライアント１６にデータを送信する。後に説明するが、信頼性およびデータサーバクラスタ２０の設備能力を向上させる目的で、データサーバクラスタ２０を２層に構成して設けている。また、データサーバクラスタ２０は、モバイルクライアント１６が位置し得る地理的位置の典型例として複数の地図を格納する地図サーバ２４に接続されている。
【００２６】データベースサーバ２２および地図サーバ２４は、ブラウザクライアント２８からコマンドを受け取るウェブサーバ２６に接続されており、要求されたデータをブラウザクライアント２８に送信する。ブラウザクライアント２８は、データサーバクラスタ２０、データベースサーバ２２、地図サーバ２４、ウェブサーバ２６を含むサーバシステムとの通信が可能で、ユーザからの入力の受付ができ、要求されたデータの表示が可能であればいずれの種類のコンピュータでもよい。
【００２７】上記から明らかなように、ライブモバイルカメラシステム１０は、ユーザが、離れた位置から、ある場所を視覚的に監視したい場合、各種適用例において有用である。また、ライブモバイルカメラシステム１０により、ユーザはモバイルクライアント１６が収集した視覚画像の地理的な位置を監視することが可能になる。さらに、モバイルクライアント１６とサーバシステム（データサーバクラスタ２０、データベースサーバ２２、地図サーバ２４、ウェブサーバ２６を含む）間で無線リンクを用いると、更なる自由度が可能となり、モバイルクライアント１６が複数の場所間を移動できようになり、ユーザがこれらの複数の場所を監視するのが容易になる。
【００２８】次に図２を参照して、可変セグメントサイズ通信プロトコル７０について説明する。一般的に、通信プロトコル７０は、リアルタイムのデジタルマルチメディアデータがインターネットプロトコル層においてパケット化される前にこのデジタルデータを小部分にセグメント化する。このセグメントの大きさは、無線リンクの品質に応じて後のステップで変更可能である。可変セグメントサイズ通信プロトコル７０は、ＵＤＰ（User Datagram Protocol）という標準インターネットプロトコル層と共に用いる。一般に、ＵＤＰはＴＣＰ（Transmission Control Protocol）に比べ伝送速度が速い。何故なら、ＵＤＰにおいては、デジタルデータフレームからデータパケットが損失または損傷した場合に自動的にデータを再送信する構成になっていないからである。従って、アプリケーション層は、損失または損傷パケットを含むセグメントのみを再送信することにより、無線リンクにおける送信効率が向上するようになっている。
【００２９】可変セグメントサイズ通信プロトコル７０はまず、リアルタイムのデジタルマルチメディアデータフレームの生成手順から開始される（Ｓ４０）。各種のリアルタイムのデジタルマルチメディアデータを可変セグメントサイズ通信プロトコル７０に用いることができるが、モバイルクライアント１６がライブモバイルカメラシステム１０において生成したリアルタイムのデジタルマルチメディアデータは可変セグメントサイズ通信プロトコル７０に特に適している。例えば、典型的なデジタルマルチメディアデータフレームのサイズは約１０キロバイトである。このデジタルマルチメディアデータフレームは、アプリケーション層によって小部分つまりセグメントにセグメント化される（Ｓ４２）。すなわち、デフォルトのセグメントサイズが例えば５００バイトの場合、１０キロバイトのデジタルデータフレームが２０セグメント生成されることになる。尚、好ましくは、デフォルトのセグメントサイズは、アプリケーションシステムを設計する際に設定するのが良い。
【００３０】次に、ＵＤＰ層において、各セグメントは、ネットワーク上を送信可能な数個の離散的データパケットに分割される（Ｓ４４）。リアルタイムのデジタルマルチメディアデータパケットを無線リンクを介して送信する場合はＵＤＰ層を用いるのが好ましい。何故なら、ＵＤＰはＴＣＰに比べ、送信リンクの品質が劣悪な場合において伝送速度がかなり高速だからである。無線リンクを本発明に用いた場合、次に、データパケットがモバイルクライアントから送信される（Ｓ４６）。
【００３１】次に、無線データパケットは第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃのいずれか、または適当な受信機によって受信される（Ｓ４８）。そして、データパケットは、元のセグメントに再組み立てされる（Ｓ５０）。すなわち、前述の例において、データパケットは元の２０セグメントに別個に再組み立てされる。次に、各セグメントを検査してセグメント内のデータパケットで損傷または損失しているものがあるか否かを判定する（Ｓ５２）。セグメントに損傷または損失データパケットがあると判定された場合、モバイルクライアントに対してメッセージを返送し、損傷また損失データパケットを含む特定のデータセグメントを再送信するよう要求する（Ｓ４７）。すべてのセグメントがデータパケットの損傷または損失なしに送信された場合、セグメントは原データフレームに再組み立てされる（Ｓ５４）。
【００３２】次に、セグメントサイズを検査して、次のリアルタイムのデジタルマルチメディアデータフレーム送信のためのセグメントサイズを最適化する。送信リンクの品質が劣悪な場合には、パケット誤りの可能性を最小化し且つ再送信が必要になった場合のセグメントのサイズを小さくするために、セグメントサイズは小さい方がよい。一方、ネットワークが目的地にセグメントをルーティングする際に用いられるヘッダを各セグメントに個々に付加する必要があるので、セグメントを小さくすると伝送効率が低下することになる。従って、送信リンクの品質が良い場合には、大きめのセグメントサイズが良い。
【００３３】従って、最初のリアルタイムのデジタルマルチメディアデータフレームのデータパケットで送信中に損傷または損失したものがない場合、セグメントサイズは許容可能と判断されるか、あるいは小さすぎると判断される。そして、送信システムに適していると考えられているセグメントサイズの最大値を示す限界値と、現在のセグメントサイズの値が比較される（Ｓ５６）。現在のセグメントサイズがすでに上限に達しているのであれば、セグメントサイズは変更されず、許容最大値のまま据え置かれる（Ｓ５８）。一方、現在のセグメントサイズが上限に達していない場合、セグメントサイズを１０％拡大する。
【００３４】同様に、最初のリアルタイムのデジタルマルチメディアデータフレームのデータパケットで送信中に損傷または損失したものが存在した場合、セグメントサイズが大きすぎると判断される。そして、現在のセグメントサイズの値が、送信システムに適していると考えられるセグメントサイズの最小値を示す限界値と比較される（Ｓ６２）。現在のセグメントサイズがすでに下限に達している場合、セグメントサイズは許容最小値のまま設定される（Ｓ６４）。しかしながら、現在のセグメントサイズが下限に達していない場合、セグメントサイズは１０％縮小される（Ｓ６６）。
【００３５】次に、新セグメントサイズはモバイルクライアント１６に返送されて次のリアルタイムのデジタルマルチメディアデータフレームで使用される（Ｓ６８）。このように、セグメントサイズはデジタルデータフレームの送信の度に検査され、上限と下限の範囲内でセグメントの最適なサイズを判定する。すなわち、可変セグメントサイズ通信プロトコル７０により、無線リンクに特に好適な迅速かつ信頼性の高い送信が可能となることは明白である。
【００３６】図１、３、４を参照しながら、２層データサーバクラスタ２０について説明する。２層データサーバクラスタ２０は、第１層サーバＴ１ａ、Ｔ１ｂと、この第１層サーバに管理される第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃ、Ｔ２ｄ、Ｔ２ｅ、Ｔ２ｆとを有する。２層のサーバ間の関係、および２層データサーバクラスタ２０とライブモバイルカメラシステム１０との関係の概要は図１に示すとおりである。従って、通信接続の要求は第１層サーバであるＴ１ａに受信される。通常、１以上の第１層サーバＴ１ａ、Ｔ１ｂが設けられ、各第１層サーバＴ１ａ、Ｔ１ｂは多くの第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃ、Ｔ２ｄ、Ｔ２ｅ、Ｔ２ｆを管理している。
【００３７】第１層サーバであるＴ１ａのアドレスは通常モバイルクライアント１６において通信相手のデフォルト第１層サーバＴ１ａとして記憶される。また、モバイルクライアント１６の設定は、バックアップの第１層サーバＴ１ｂのアドレスに変更してもよいし、あるいは、デフォルトの第１層サーバＴ１ａを代替第１層サーバＴ１ｂに変更して主要第１層サーバＴ１ａのダウンタイムを吸収したり、他の負荷不均衡の問題に対処するようにしてもよい。
【００３８】第１層サーバＴ１ａが通信接続の要求を受信すると、第１層サーバＴ１ａは該要求と要求者の識別情報を第１層サーバＴ１ａが管理する第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃの各々に送信する。図３に示すとおり、第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃの各々はモバイルクライアント１６に応答することにより、通信接続のための各サーバの可用性を示し、第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃ各々の各アドレスを提供する。第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃ各々の通信負荷とその他可用性状況の結果、第２層サーバＴ２ｃが他の第２層サーバＴ２ａ、Ｔ２ｂより前に該通信接続要求に応答する。そして、モバイルクライアント１６は、最初に応答した第２層サーバＴ２ｃとの通信接続を設定し、後で応答した第２層サーバＴ２ａ、Ｔ２ｂとの通信を終了する。次に、通信接続を設定した第２層サーバＴ２ｃは、受信したデータをデータベースサーバ２２、地図サーバ２４、ウェブサーバ２６に送信することにより、モバイルクライアント１６とブラウザクライアント２８間のリンクを提供する。
【００３９】図４は、第１層サーバＴ１ａ、Ｔ１ｂと第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃ、Ｔ２ｄ、Ｔ２ｅ、Ｔ２ｆ間の管理／被管理の関係が、第１層サーバのダウンタイム吸収やその他負荷均衡化などの目的で変化した場合を示している。第１層サーバＴ１ａが今にも停止しそうな場合、サーバＴ１ａは配下にある第２層サーバＴ２ａ、Ｔ２ｂ、Ｔ２ｃを他の第１層サーバＴ１ｂの配下に再配置する。つまり、停止を間近に控えた第１層サーバＴ１ａは、第１層サーバＴ１ｂに対して、第２層サーバＴ２ａを配下に置いて管理するようにとの要求を送信する。停止予定の第１層サーバＴ１ａと再配置された第２層サーバＴ２ａの管理／被管理関係はここで終了する。停止予定の第１層サーバＴ１ａは、配下の第２層サーバの残りのＴ２ｂ、Ｔ２ｃが再配置されるまで、他の第１層サーバに要求を送信することにより、再配置処理を繰り返す。
【００４０】以上の点より、２層データサーバクラスタ２０において、より負荷の少ない他のサーバに通信接続を転嫁することにより、多数のサーバ間の負荷均衡を保つことが可能になることは明らかである。データサーバクラスタ２０が通信負荷を均衡させることが可能なので、従来型のサーバシステムに比べより高い負荷の総トラフィックを処理することが可能になる。従って、処理速度のより速い高価なサーバが現在処理しているトラフィック許容荷重と同じ処理量を、より小型で安価なサーバを使って達成することができる。また、この２層データサーバクラスタ２０では、第１層サーバと第２層サーバ間の通信および第１層サーバ間の通信に標準のインターネット通信プロトコルを用いることができる。つまり、第１層サーバと第２層サーバは互いに異なる離散的ネットワークであっても良いことになる。同様に、第１層サーバの各々の配下に配置されるグループ内の第２層サーバの各々も、別個の離散的サーバネットワークであってもよい。
【００４１】本発明の好ましい実施形態を説明してきたが、本発明はこの実施形態に限定されず、発明から逸脱しない範囲内で修正が可能である。発明の範囲は付記された請求項に定義され、請求項の意味の範囲内に該当する装置はすべて、文字通りであるか均等物であるかにかかわらず、該請求項に包含される。
【００４２】
【発明の効果】以上説明したように、本発明に係るライブモバイルカメラシステムによれば、リアルタイムのデジタルマルチメディアデータをより少ない伝送遅延と低い誤り率で送信することができ、また、異なるネットワークの複数のサーバ間で通信負荷を均衡化することが可能になる。
【図面の簡単な説明】
本発明は、その構成と動作方法を含み、添付図中において大方にして図示されている。
【図１】 ライブモバイルカメラシステムのブロック図である。
【図２】 通信プロトコルのフローチャートである。
【図３】 ライブモバイルカメラシステムのブロック図であり、移動局が第２層サーバと通信接続を設定する場合を示している。
【図４】 サーバクラスタのブロック図であり、第１層サーバが第２層サーバを他の第１層サーバの配下に再割り当てする場合を示している。
【特許請求の範囲】
【請求項１】 第１のアプリケーション層においてデジタルデータをセグメントに区分し、第１のインターネットプロトコル層において前記セグメントをパケット化し、第２のインターネットプロトコル層において前記パケットを再組み立てし、第２のアプリケーション層において前記セグメントを再組み立てすることを特徴とする通信プロトコル。
【請求項２】 前記パケットに誤りがあるか否か検査し、前記パケット検査の結果に応じて前記セグメントサイズを変更することを特徴とする請求項１に記載の通信プロトコル。
【請求項３】 前記パケット検査により前記デジタルデータにパケット誤りが検出されなかった場合、前記セグメントサイズを拡大し、前記パケット検査により前記デジタルデータにパケット誤りが検出された場合、前記セグメントサイズを縮小させることを特徴とする請求項２に記載の通信プロトコル。
【請求項４】 前記セグメントサイズは、下限と上限の間で変更されることを特徴とする請求項２に記載の通信プロトコル。
【請求項５】 前記パケット検査によりデジタルデータにパケット誤りが検出されず且つ前記セグメントサイズが前記上限である場合、前記セグメントサイズは変更されず、前記パケット検査によりデジタルデータにパケット誤りが検出されず且つ前記セグメントサイズが前記上限ではない場合、前記セグメントサイズを拡大し、前記パケット検査によりデジタルデータにパケット誤りが検出され且つ前記セグメントサイズが下限の場合、前記セグメントサイズは変更されず、前記パケット検査によりデジタルデータにパケット誤りが検出され且つ前記セグメントサイズが下限ではない場合、前記セグメントサイズを縮小することを特徴とする請求項４に記載の通信プロトコル。
【請求項６】 前記パケット化と前記パケットの再組み立ての過程の間に、無線リンクを介して前記パケットを送受信する過程を有することを特徴とする請求項１に記載の通信プロトコル。
【請求項７】 前記パケットに誤りがあるか否かを検査し、パケット誤りを有しないセグメントは再送信せず、パケット誤りを有するセグメントのみを再送信することを特徴とする請求項１に記載の通信プロトコル。
【請求項８】 前記パケットに誤りがあるか否かを検査し、前記パケット検査の結果に応じて前記セグメントの少なくとも１を、前記第１のインターネットプロトコル層からではなく前記第１のアプリケーション層から再送信することを特徴とする請求項１に記載の通信プロトコル。
【請求項９】 前記パケットに誤りがあるか否かを検査し、前記パケット検査の結果に応じて前記セグメントのサイズを変更し、前記パケット検査の結果に応じて前記セグメントの少なくとも１を、前記第１のインターネットプロトコル層からではなく、前記第１のアプリケーション層から再送信することを特徴とする請求項１に記載の通信プロトコル。
【請求項１０】 前記パケット検査により前記デジタルデータにパケット誤りが検出されなかった場合は前記セグメントサイズを拡大し、前記パケット検査により前記デジタルデータに誤りが検出された場合は前記セグメントサイズを縮小し、前記セグメントサイズは下限と上限の範囲で変更され、パケット誤りを有する前記セグメントのみが再送信され、パケット誤りを有しない前記セグメントは再送信されないことを特徴とする請求項９に記載の通信プロトコル。
【請求項１１】 前記パケット化と前記パケットの再組み立てとの過程の間に、無線リンクを介して前記パケットを送受信する過程を有し、前記インターネットプロトコル層はユーザデータグラムプロトコルであることを特徴とする請求項１０に記載の通信プロトコル。
【請求項１２】 モバイルクライアント周辺の視覚環境のデジタル化画像である前記デジタルデータをライブモバイルカメラシステムにおいて生成することを特徴とする請求項１または１１に記載の通信プロトコル。
【請求項１３】 前記パケットに誤りがあるか否か検査し、前記パケット検査の結果に応じて前記セグメントのサイズを変更し、前記パケット化と前記パケットの再組み立てとの過程の間に、無線リンクを介して前記パケットを送受信する過程を有することを特徴とする請求項１に記載の通信プロトコル。
【請求項１４】 前記インターネットプロトコル層はユーザデータグラムプロトコルであることを特徴とする請求項１または１３に記載の通信プロトコル。
【請求項１５】 第１層および第２層を有するサーバクラスタであって、前記第１層および前記第２層の各々は少なくとも１のサーバを有し、前記第１層は前記第２層を管理し、前記第１層は通信接続を求める要求を受信し、前記第２層に前記要求を送信することにより、前記第２層が前記要求に応答することを特徴とするサーバクラスタ。
【請求項１６】 前記第２層は、少なくとも２のサーバを有することを特徴とする請求項１５に記載のサーバクラスタ。
【請求項１７】 各第２層サーバは前記要求に応答し、最初の第２層サーバが応答すると通信接続が設定されることを特徴とする請求項１６に記載のサーバクラスタ。
【請求項１８】 前記第１層は少なくとも２のサーバから成り、前記第１層サーバの各々は少なくとも２の第２層サーバを管理することを特徴とする請求項１５に記載のサーバクラスタ。
【請求項１９】 前記複数の第１層サーバの１のサーバは自身が管理する前記複数の第２層サーバの１のサーバを前記複数の第１層サーバの他の１のサーバの配下に再割り当てすることを特徴とする請求項１８に記載のサーバクラスタ。
【請求項２０】 前記再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定することを特徴とする請求項１９に記載のサーバクラスタ。
【請求項２１】 前記第１層サーバの少なくとも２のサーバが、インターネットプロトコルを用いて互いに通信し、前記少なくとも２のサーバは異なるサーバネットワークであることを特徴とする請求項１８に記載のサーバクラスタ。
【請求項２２】 要求者が前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶することを特徴とする請求項１８に記載のサーバクラスタ。
【請求項２３】 前記要求者は記憶した前記複数の第１層サーバの識別情報を更新し、前記要求者は前記要求の送信先として前記複数の第１層サーバのいずれかを選択することを特徴とする請求項２２に記載のサーバクラスタ。
【請求項２４】 前記第１層は、インターネットプロトコルを用いて前記第２層と通信し、前記第１層と前記第２層は異なるサーバネットワークであることを特徴とする請求項１５に記載のサーバクラスタ。
【請求項２５】 前記第２層の少なくとも２のサーバは、異なるサーバネットワークであることを特徴とする請求項２４に記載のサーバクラスタ。
【請求項２６】 無線リンクが、前記要求された通信接続に連結されることを特徴とする請求項１５に記載のサーバクラスタ。
【請求項２７】 ライブモバイルカメラシステムはカメラ付のモバイルクライアントを有し、前記カメラにより前記モバイルクライアント周辺の視覚画像を撮影し、前記画像は前記通信接続を介して送信されることを特徴とする請求項１５に記載のサーバクラスタ。
【請求項２８】 各第２層サーバは前記要求に応答し、最初の第２層サーバが応答すると通信接続が設定され、前記第１層は少なくとも２のサーバから成り、これにより前記複数の第１層サーバの各々は、少なくとも２の第２層サーバを管理し、前記複数の第１層サーバの１のサーバは、自身が管理する前記第２層サーバの１のサーバを、前記複数の第１層サーバの他の１のサーバの配下に再割り当てし、前記少なくとも２の第１層サーバは、インターネットプロトコルを用いて互いに通信し、前記少なくとも２の第１層サーバは異なるサーバネットワークであり、前記第１層はインターネットプロトコルを用いて前記第２層と通信し、前記第１層サーバと前記第２層サーバは異なるサーバネットワークであることを特徴とする請求項１６に記載のサーバクラスタ。
【請求項２９】 前記再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定し、要求者が前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶し、前記要求者は記憶した前記複数の第１層サーバの識別情報を更新し、前記要求者は前記要求の送信先として前記複数の第１層サーバのいずれかを選択し、無線リンクが前記要求された通信接続に連結され、ライブモバイルカメラシステムはカメラ付のモバイルクライアントを有し、前記カメラにより前記モバイルクライアント周辺の視覚画像を撮影し、前記画像は前記通信接続を介して送信されることを特徴とする請求項２８に記載のサーバクラスタ。
【請求項３０】 前記第１層は少なくとも２のサーバから成り、前記第１層サーバの各々は少なくとも２の第２層サーバを管理し、要求者は前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶し、前記要求者は記憶した前記複数の第１層サーバの識別情報を更新し、前記要求者は前記要求の送信先として前記第１層サーバのいずれかを選択し、無線リンクが前記要求された通信接続に連結され、ライブモバイルカメラシステムはカメラ付のモバイルクライアントを有し、前記カメラにより前記モバイルクライアント周辺の視覚画像を撮影し、前記画像は前記通信接続を介して送信されることを特徴とする請求項１６に記載のサーバクラスタ。
【請求項３１】 前記複数の第１層サーバの１のサーバは自身が管理する前記複数の第２層サーバの１のサーバを前記複数の第１層サーバの他の１のサーバの配下に再割り当てし、前記再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定し、前記第１層サーバの少なくとも２のサーバが、インターネットプロトコルを用いて互いに通信し、前記少なくとも２のサーバは異なるサーバネットワークであり、要求者は前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶し、前記要求者は記憶した前記複数の第１層サーバの識別情報を更新し、前記要求者は前記要求の送信先として前記複数の第１層サーバのいずれかを選択し、前記第１層は、インターネットプロトコルを用いて前記第２層と通信し、前記第１層と前記第２層は異なるサーバネットワークであることを特徴とする請求項３０に記載のサーバクラスタ。
【請求項３２】 リアルタイムな周囲の視覚画像を生成するカメラ付のモバイルクライアントと、前記画像を送信する無線リンクと、前記無線リンクを受信するサーバクラスタとを具備し、前記無線リンクにおいて、第１のアプリケーション層においてデジタルデータをセグメントに区分し、第１のインターネットプロトコル層において前記セグメントをパケット化し、第２のインターネットプロトコル層において前記パケットを再組み立てし、第２のアプリケーション層において前記セグメントを再組み立てする通信プロトコルに従って、前記画像が前記無線リンクを介して送信され、前記サーバクラスタは第１層および第２層を有し、前記第１層は少なくとも１のサーバ、前記第２層は少なくとも２のサーバを有し、前記第１層は第２層を管理し、前記第１層は通信接続を求める要求を受信し前記第２層に前記要求を送信することにより前記第２層が前記要求に応答することを特徴とするライブモバイルカメラシステム。
【請求項３３】 前記通信プロトコルは前記パケットに誤りがあるか否か検査し、前記パケット検査の結果に応じて前記セグメントのサイズを変更し、前記インターネットプロトコル層はユーザデータグラムプロトコルであることを特徴とする請求項３２に記載のライブモバイルカメラシステム。
【請求項３４】 前記パケット検査により前記デジタルデータにパケット誤りが検出されなかった場合は前記セグメントサイズを拡大し、前記パケット検査により前記デジタルデータに誤りが検出された場合は前記セグメントサイズを縮小し、前記セグメントサイズは下限と上限の範囲で変更され、前記通信プロトコルは、パケット誤りを有しない前記セグメントは再送信せずパケット誤りを有する前記セグメントのみを再送信し、前記パケット検査の結果に応じて少なくとも１の前記セグメントを前記第１のインターネットプロトコル層からは再送信せず前記第１のアプリケーション層から再送信することを特徴とする請求項３３に記載のライブモバイルカメラシステム。
【請求項３５】 各第２層サーバは前記要求に応答し、最初の第２層サーバが応答すると通信接続が設定され、前記第１層は少なくとも２のサーバから成り、これにより前記複数の第１層サーバの各々は、少なくとも２の第２層サーバを管理し、前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶することを特徴とする請求項３２に記載のライブモバイルカメラシステム。
【請求項３６】 前記複数の第１層サーバの１のサーバは自身が管理する前記複数の第２層サーバの１のサーバを前記複数の第１層サーバの他の１のサーバの配下に再割り当てし、前記再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定し、前記複数の第１層サーバの少なくとも２のサーバが、インターネットプロトコルを用いて互いに通信し、前記少なくとも２のサーバは異なるサーバネットワークであり、要求者は前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶し、前記モバイルクライアントは記憶した前記複数の第１層サーバの識別情報を更新し、前記モバイルクライアントは前記要求の送信先として前記複数の第１層サーバのいずれかを選択し、前記第１層は、インターネットプロトコルを用いて前記第２層と通信し、前記第１層と前記第２層は異なるサーバネットワークであることを特徴とする請求項３５に記載のライブモバイルカメラシステム。
【請求項３７】 前記通信プロトコルは、前記パケットに誤りがあるか否かを検査し、前記パケット検査の結果に応じて前記セグメントサイズを変更し、前記インターネットプロトコル層は、ユーザデータグラムプロトコルであり、各第２層サーバは前記要求に応答し、最初の第２層サーバが応答すると前記通信接続が設定され、前記第１層は少なくとも２のサーバから成り、これにより前記第１層サーバの各々は少なくとも２の第２層サーバを管理し、前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶することを特徴とする請求項３２に記載のライブモバイルカメラシステム。
【請求項３８】 前記パケット検査により前記デジタルデータにパケット誤りが検出されなかった場合は前記セグメントサイズを拡大し、前記パケット検査により前記デジタルデータに誤りが検出された場合は前記セグメントサイズを縮小し、前記セグメントサイズは下限と上限の範囲で変更され、前記通信プロトコルは、パケット誤りを有しない前記セグメントは再送信せずパケット誤りを有する前記セグメントのみを再送信し、前記パケット検査の結果に応じて前記セグメントの少なくとも１を前記第１のインターネットプロトコル層からはではなく前記第１のアプリケーション層から再送信し、前記複数の第１層サーバの１のサーバは自身が管理する前記複数の第２層サーバの１のサーバを前記複数の第１層サーバの他の１のサーバの配下に再割り当てし、前記再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定し、前記第１層サーバの少なくとも２のサーバが、インターネットプロトコルを用いて互いに通信し、前記少なくとも２のサーバは異なるサーバネットワークであり、要求者は前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶し、前記モバイルクライアントは記憶した前記複数の第１層サーバの識別情報を更新し、前記モバイルクライアントは前記要求の送信先として前記第１層サーバのいずれかを選択し、前記第１層は、インターネットプロトコルを用いて前記第２層と通信し、前記第１層と前記第２層は異なるサーバネットワークであることを特徴とする請求項３７に記載のライブモバイルカメラシステム。
【請求項１】 第１のアプリケーション層においてデジタルデータをセグメントに区分し、第１のインターネットプロトコル層において前記セグメントをパケット化し、第２のインターネットプロトコル層において前記パケットを再組み立てし、第２のアプリケーション層において前記セグメントを再組み立てすることを特徴とする通信プロトコル。
【請求項２】 前記パケットに誤りがあるか否か検査し、前記パケット検査の結果に応じて前記セグメントサイズを変更することを特徴とする請求項１に記載の通信プロトコル。
【請求項３】 前記パケット検査により前記デジタルデータにパケット誤りが検出されなかった場合、前記セグメントサイズを拡大し、前記パケット検査により前記デジタルデータにパケット誤りが検出された場合、前記セグメントサイズを縮小させることを特徴とする請求項２に記載の通信プロトコル。
【請求項４】 前記セグメントサイズは、下限と上限の間で変更されることを特徴とする請求項２に記載の通信プロトコル。
【請求項５】 前記パケット検査によりデジタルデータにパケット誤りが検出されず且つ前記セグメントサイズが前記上限である場合、前記セグメントサイズは変更されず、前記パケット検査によりデジタルデータにパケット誤りが検出されず且つ前記セグメントサイズが前記上限ではない場合、前記セグメントサイズを拡大し、前記パケット検査によりデジタルデータにパケット誤りが検出され且つ前記セグメントサイズが下限の場合、前記セグメントサイズは変更されず、前記パケット検査によりデジタルデータにパケット誤りが検出され且つ前記セグメントサイズが下限ではない場合、前記セグメントサイズを縮小することを特徴とする請求項４に記載の通信プロトコル。
【請求項６】 前記パケット化と前記パケットの再組み立ての過程の間に、無線リンクを介して前記パケットを送受信する過程を有することを特徴とする請求項１に記載の通信プロトコル。
【請求項７】 前記パケットに誤りがあるか否かを検査し、パケット誤りを有しないセグメントは再送信せず、パケット誤りを有するセグメントのみを再送信することを特徴とする請求項１に記載の通信プロトコル。
【請求項８】 前記パケットに誤りがあるか否かを検査し、前記パケット検査の結果に応じて前記セグメントの少なくとも１を、前記第１のインターネットプロトコル層からではなく前記第１のアプリケーション層から再送信することを特徴とする請求項１に記載の通信プロトコル。
【請求項９】 前記パケットに誤りがあるか否かを検査し、前記パケット検査の結果に応じて前記セグメントのサイズを変更し、前記パケット検査の結果に応じて前記セグメントの少なくとも１を、前記第１のインターネットプロトコル層からではなく、前記第１のアプリケーション層から再送信することを特徴とする請求項１に記載の通信プロトコル。
【請求項１０】 前記パケット検査により前記デジタルデータにパケット誤りが検出されなかった場合は前記セグメントサイズを拡大し、前記パケット検査により前記デジタルデータに誤りが検出された場合は前記セグメントサイズを縮小し、前記セグメントサイズは下限と上限の範囲で変更され、パケット誤りを有する前記セグメントのみが再送信され、パケット誤りを有しない前記セグメントは再送信されないことを特徴とする請求項９に記載の通信プロトコル。
【請求項１１】 前記パケット化と前記パケットの再組み立てとの過程の間に、無線リンクを介して前記パケットを送受信する過程を有し、前記インターネットプロトコル層はユーザデータグラムプロトコルであることを特徴とする請求項１０に記載の通信プロトコル。
【請求項１２】 モバイルクライアント周辺の視覚環境のデジタル化画像である前記デジタルデータをライブモバイルカメラシステムにおいて生成することを特徴とする請求項１または１１に記載の通信プロトコル。
【請求項１３】 前記パケットに誤りがあるか否か検査し、前記パケット検査の結果に応じて前記セグメントのサイズを変更し、前記パケット化と前記パケットの再組み立てとの過程の間に、無線リンクを介して前記パケットを送受信する過程を有することを特徴とする請求項１に記載の通信プロトコル。
【請求項１４】 前記インターネットプロトコル層はユーザデータグラムプロトコルであることを特徴とする請求項１または１３に記載の通信プロトコル。
【請求項１５】 第１層および第２層を有するサーバクラスタであって、前記第１層および前記第２層の各々は少なくとも１のサーバを有し、前記第１層は前記第２層を管理し、前記第１層は通信接続を求める要求を受信し、前記第２層に前記要求を送信することにより、前記第２層が前記要求に応答することを特徴とするサーバクラスタ。
【請求項１６】 前記第２層は、少なくとも２のサーバを有することを特徴とする請求項１５に記載のサーバクラスタ。
【請求項１７】 各第２層サーバは前記要求に応答し、最初の第２層サーバが応答すると通信接続が設定されることを特徴とする請求項１６に記載のサーバクラスタ。
【請求項１８】 前記第１層は少なくとも２のサーバから成り、前記第１層サーバの各々は少なくとも２の第２層サーバを管理することを特徴とする請求項１５に記載のサーバクラスタ。
【請求項１９】 前記複数の第１層サーバの１のサーバは自身が管理する前記複数の第２層サーバの１のサーバを前記複数の第１層サーバの他の１のサーバの配下に再割り当てすることを特徴とする請求項１８に記載のサーバクラスタ。
【請求項２０】 前記再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定することを特徴とする請求項１９に記載のサーバクラスタ。
【請求項２１】 前記第１層サーバの少なくとも２のサーバが、インターネットプロトコルを用いて互いに通信し、前記少なくとも２のサーバは異なるサーバネットワークであることを特徴とする請求項１８に記載のサーバクラスタ。
【請求項２２】 要求者が前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶することを特徴とする請求項１８に記載のサーバクラスタ。
【請求項２３】 前記要求者は記憶した前記複数の第１層サーバの識別情報を更新し、前記要求者は前記要求の送信先として前記複数の第１層サーバのいずれかを選択することを特徴とする請求項２２に記載のサーバクラスタ。
【請求項２４】 前記第１層は、インターネットプロトコルを用いて前記第２層と通信し、前記第１層と前記第２層は異なるサーバネットワークであることを特徴とする請求項１５に記載のサーバクラスタ。
【請求項２５】 前記第２層の少なくとも２のサーバは、異なるサーバネットワークであることを特徴とする請求項２４に記載のサーバクラスタ。
【請求項２６】 無線リンクが、前記要求された通信接続に連結されることを特徴とする請求項１５に記載のサーバクラスタ。
【請求項２７】 ライブモバイルカメラシステムはカメラ付のモバイルクライアントを有し、前記カメラにより前記モバイルクライアント周辺の視覚画像を撮影し、前記画像は前記通信接続を介して送信されることを特徴とする請求項１５に記載のサーバクラスタ。
【請求項２８】 各第２層サーバは前記要求に応答し、最初の第２層サーバが応答すると通信接続が設定され、前記第１層は少なくとも２のサーバから成り、これにより前記複数の第１層サーバの各々は、少なくとも２の第２層サーバを管理し、前記複数の第１層サーバの１のサーバは、自身が管理する前記第２層サーバの１のサーバを、前記複数の第１層サーバの他の１のサーバの配下に再割り当てし、前記少なくとも２の第１層サーバは、インターネットプロトコルを用いて互いに通信し、前記少なくとも２の第１層サーバは異なるサーバネットワークであり、前記第１層はインターネットプロトコルを用いて前記第２層と通信し、前記第１層サーバと前記第２層サーバは異なるサーバネットワークであることを特徴とする請求項１６に記載のサーバクラスタ。
【請求項２９】 前記再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定し、要求者が前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶し、前記要求者は記憶した前記複数の第１層サーバの識別情報を更新し、前記要求者は前記要求の送信先として前記複数の第１層サーバのいずれかを選択し、無線リンクが前記要求された通信接続に連結され、ライブモバイルカメラシステムはカメラ付のモバイルクライアントを有し、前記カメラにより前記モバイルクライアント周辺の視覚画像を撮影し、前記画像は前記通信接続を介して送信されることを特徴とする請求項２８に記載のサーバクラスタ。
【請求項３０】 前記第１層は少なくとも２のサーバから成り、前記第１層サーバの各々は少なくとも２の第２層サーバを管理し、要求者は前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶し、前記要求者は記憶した前記複数の第１層サーバの識別情報を更新し、前記要求者は前記要求の送信先として前記第１層サーバのいずれかを選択し、無線リンクが前記要求された通信接続に連結され、ライブモバイルカメラシステムはカメラ付のモバイルクライアントを有し、前記カメラにより前記モバイルクライアント周辺の視覚画像を撮影し、前記画像は前記通信接続を介して送信されることを特徴とする請求項１６に記載のサーバクラスタ。
【請求項３１】 前記複数の第１層サーバの１のサーバは自身が管理する前記複数の第２層サーバの１のサーバを前記複数の第１層サーバの他の１のサーバの配下に再割り当てし、前記再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定し、前記第１層サーバの少なくとも２のサーバが、インターネットプロトコルを用いて互いに通信し、前記少なくとも２のサーバは異なるサーバネットワークであり、要求者は前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶し、前記要求者は記憶した前記複数の第１層サーバの識別情報を更新し、前記要求者は前記要求の送信先として前記複数の第１層サーバのいずれかを選択し、前記第１層は、インターネットプロトコルを用いて前記第２層と通信し、前記第１層と前記第２層は異なるサーバネットワークであることを特徴とする請求項３０に記載のサーバクラスタ。
【請求項３２】 リアルタイムな周囲の視覚画像を生成するカメラ付のモバイルクライアントと、前記画像を送信する無線リンクと、前記無線リンクを受信するサーバクラスタとを具備し、前記無線リンクにおいて、第１のアプリケーション層においてデジタルデータをセグメントに区分し、第１のインターネットプロトコル層において前記セグメントをパケット化し、第２のインターネットプロトコル層において前記パケットを再組み立てし、第２のアプリケーション層において前記セグメントを再組み立てする通信プロトコルに従って、前記画像が前記無線リンクを介して送信され、前記サーバクラスタは第１層および第２層を有し、前記第１層は少なくとも１のサーバ、前記第２層は少なくとも２のサーバを有し、前記第１層は第２層を管理し、前記第１層は通信接続を求める要求を受信し前記第２層に前記要求を送信することにより前記第２層が前記要求に応答することを特徴とするライブモバイルカメラシステム。
【請求項３３】 前記通信プロトコルは前記パケットに誤りがあるか否か検査し、前記パケット検査の結果に応じて前記セグメントのサイズを変更し、前記インターネットプロトコル層はユーザデータグラムプロトコルであることを特徴とする請求項３２に記載のライブモバイルカメラシステム。
【請求項３４】 前記パケット検査により前記デジタルデータにパケット誤りが検出されなかった場合は前記セグメントサイズを拡大し、前記パケット検査により前記デジタルデータに誤りが検出された場合は前記セグメントサイズを縮小し、前記セグメントサイズは下限と上限の範囲で変更され、前記通信プロトコルは、パケット誤りを有しない前記セグメントは再送信せずパケット誤りを有する前記セグメントのみを再送信し、前記パケット検査の結果に応じて少なくとも１の前記セグメントを前記第１のインターネットプロトコル層からは再送信せず前記第１のアプリケーション層から再送信することを特徴とする請求項３３に記載のライブモバイルカメラシステム。
【請求項３５】 各第２層サーバは前記要求に応答し、最初の第２層サーバが応答すると通信接続が設定され、前記第１層は少なくとも２のサーバから成り、これにより前記複数の第１層サーバの各々は、少なくとも２の第２層サーバを管理し、前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶することを特徴とする請求項３２に記載のライブモバイルカメラシステム。
【請求項３６】 前記複数の第１層サーバの１のサーバは自身が管理する前記複数の第２層サーバの１のサーバを前記複数の第１層サーバの他の１のサーバの配下に再割り当てし、前記再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定し、前記複数の第１層サーバの少なくとも２のサーバが、インターネットプロトコルを用いて互いに通信し、前記少なくとも２のサーバは異なるサーバネットワークであり、要求者は前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶し、前記モバイルクライアントは記憶した前記複数の第１層サーバの識別情報を更新し、前記モバイルクライアントは前記要求の送信先として前記複数の第１層サーバのいずれかを選択し、前記第１層は、インターネットプロトコルを用いて前記第２層と通信し、前記第１層と前記第２層は異なるサーバネットワークであることを特徴とする請求項３５に記載のライブモバイルカメラシステム。
【請求項３７】 前記通信プロトコルは、前記パケットに誤りがあるか否かを検査し、前記パケット検査の結果に応じて前記セグメントサイズを変更し、前記インターネットプロトコル層は、ユーザデータグラムプロトコルであり、各第２層サーバは前記要求に応答し、最初の第２層サーバが応答すると前記通信接続が設定され、前記第１層は少なくとも２のサーバから成り、これにより前記第１層サーバの各々は少なくとも２の第２層サーバを管理し、前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶することを特徴とする請求項３２に記載のライブモバイルカメラシステム。
【請求項３８】 前記パケット検査により前記デジタルデータにパケット誤りが検出されなかった場合は前記セグメントサイズを拡大し、前記パケット検査により前記デジタルデータに誤りが検出された場合は前記セグメントサイズを縮小し、前記セグメントサイズは下限と上限の範囲で変更され、前記通信プロトコルは、パケット誤りを有しない前記セグメントは再送信せずパケット誤りを有する前記セグメントのみを再送信し、前記パケット検査の結果に応じて前記セグメントの少なくとも１を前記第１のインターネットプロトコル層からはではなく前記第１のアプリケーション層から再送信し、前記複数の第１層サーバの１のサーバは自身が管理する前記複数の第２層サーバの１のサーバを前記複数の第１層サーバの他の１のサーバの配下に再割り当てし、前記再割り当てにおいて、前記再割り当てを行う第１層サーバは、前記複数の第２層サーバの前記１のサーバの受け入れを求めるメッセージを前記複数の第１層サーバの前記他の１のサーバに送信し、前記複数の第１層サーバの前記他の１のサーバは、前記要求メッセージを受け付けると、前記複数の第２層サーバの前記１のサーバの管理を行うように設定し、前記第１層サーバの少なくとも２のサーバが、インターネットプロトコルを用いて互いに通信し、前記少なくとも２のサーバは異なるサーバネットワークであり、要求者は前記通信接続を求める要求を送信し、前記要求者は前記要求の送信先のデフォルトサーバとして前記複数の第１層サーバのいずれかの識別情報を記憶し、前記モバイルクライアントは記憶した前記複数の第１層サーバの識別情報を更新し、前記モバイルクライアントは前記要求の送信先として前記第１層サーバのいずれかを選択し、前記第１層は、インターネットプロトコルを用いて前記第２層と通信し、前記第１層と前記第２層は異なるサーバネットワークであることを特徴とする請求項３７に記載のライブモバイルカメラシステム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００３−１０１５１８（Ｐ２００３−１０１５１８Ａ）
【公開日】平成１５年４月４日（２００３．４．４）
【国際特許分類】
【出願番号】特願２００２−１５６３２１（Ｐ２００２−１５６３２１）
【出願日】平成１４年５月２９日（２００２．５．２９）
【出願人】（３０１０７７０９１）ドコモ コミュニケーションズ ラボラトリーズ ユー・エス・エー インコーポレーティッド (4)
【Ｆターム（参考）】
【公開日】平成１５年４月４日（２００３．４．４）
【国際特許分類】
【出願日】平成１４年５月２９日（２００２．５．２９）
【出願人】（３０１０７７０９１）ドコモ コミュニケーションズ ラボラトリーズ ユー・エス・エー インコーポレーティッド (4)
【Ｆターム（参考）】
[ Back to top ]