(57)【要約】【課題】  従来無線ＬＡＮで多く利用されるＣＳＭＡ／ＣＡ方式の無線ネットワークにおいて、１台のサーバと、複数のクライアントが相互接続されて通信する場合の通信異常の発生検出、および通信の異常状態から安定状態への回復制御を可能とするデータ通信方法を提供する。【解決手段】  クライアントからサーバに通知されるＴＣＰ／ＩＰのウインドウフロー制御用のウインドウ情報を解析するウインドウ情報解析ステップＳ１２と、ウインドウ情報解析ステップＳ１２で得られる解析値を用いて、伝送路の異常発生の判定を行う異常検出ステップＳ１３と、異常を検出した場合に、サーバからクライアントへのデータパケットの送信の制御を、ネットワークの伝送状態に応じて行うデータパケット送信制御ステップＳ１４とを有する。【選択図】  図２
2008288740.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからのデータ送信要求に応答して、前記クライアントに対してデータパケットを連続的に発信可能なサーバと、前記サーバと接続して通信を行う複数のクライアントとを有し、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ／Ｃｏｌｌｉｓｉｏｎ  Ａｖｏｉｄａｎｃｅ）方式の無線ＬＡＮを用いてＴＣＰ／ＩＰによる通信を行う通信システムにおいて、前記サーバから前記クライアントへのデータパケット送信を、前記サーバによって制御するデータ通信方法であって、
前記クライアントから前記サーバに通知されるＴＣＰ／ＩＰのウインドウフロー制御用のウインドウサイズ情報を解析するウインドウサイズ情報解析ステップと、
前記ウインドウサイズ情報解析ステップで得られる解析値を用いて、伝送路における異常の発生の判定を行う異常検出ステップと、
前記異常検出ステップにおいて前記伝送路における異常の発生が検出されたときには、前記サーバから前記クライアントへのデータパケットの送信の制御を、ネットワークの伝送状態に応じて行うデータパケット送信制御ステップとを有する、
ことを特徴とするデータ通信方法。
【請求項２】
請求項１に記載のデータ通信方法において、
前記ウインドウサイズ情報解析ステップは、前記サーバが前記クライアントより最大ウインドウサイズの通知を連続して受けたときは、最大ウインドウサイズの値が連続して通知される時間である最大ウインドウ連続通知時間を、その解析値として出力する、
ことを特徴とするデータ通信方法。
【請求項３】
請求項２に記載のデータ通信方法において、
前記異常検出ステップは、前記クライアントの受信バッファサイズを、Ｍバイト、前記クライアントの一秒間当たりのデータ消費量を、Ｄバイト、前記ウインドウサイズ情報解析ステップが出力する前記最大ウインドウ連続通知時間を、Ｔｎ秒とすると、ＭがＤ×Ｔｎ以下となったとき、前記伝送路に異常が発生したと判定する、
ことを特徴とするデータ通信方法。
【請求項４】
請求項１に記載のデータ通信方法において、
前記ウインドウサイズ情報解析ステップは、前記サーバが前記クライアントより最大ウインドウサイズの通知を受けたときは、その直前のウインドウサイズ通知時刻と、該最大ウインドウサイズ通知時刻との間の時間である最大ウインドウ通知間隔時間を、その解析値として出力する、
ことを特徴とするデータ通信方法。
【請求項５】
請求項４に記載のデータ通信方法において、
前記異常検出ステップは、前記クライアントの受信バッファサイズを、Ｍバイト、前記クライアントの一秒間当たりのデータ消費量を、Ｄバイト、前記ウインドウサイズ情報解析ステップが出力する前記最大ウインドウ通知間隔時間を、Ｔｄ秒とすると、ＭがＤ×Ｔｄ以下となったとき、前記伝送路に異常が発生したと判定する、
ことを特徴とするデータ通信方法。
【請求項６】
請求項１ないし請求項５のいずれかに記載のデータ通信方法において、
前記データパケット送信制御ステップにおける前記伝送路上の異常検出時の送信制御は、前記サーバから前記クライアントへ発信されるデータパケット長を変化させる、
ことを特徴とするデータ通信方法。
【請求項７】
請求項１ないし請求項５のいずれかに記載のデータ通信方法において、
前記データパケット送信制御ステップにおける前記伝送路上の異常検出時の送信制御は、前記サーバから前記クライアントへ発信されるデータパケット発信間隔を変化させる、
ことを特徴とするデータ通信方法。
【請求項８】
請求項１ないし請求項５のいずれかに記載のデータ通信方法において、
前記データパケット送信制御ステップにおける前記伝送路上の異常検出時の送信制御は、前記サーバから前記クライアントへ発信されるデータパケット長と、データパケット発信間隔とを変化させる、
ことを特徴とするデータ通信方法。
【請求項９】
請求項１ないし請求項５のいずれかに記載のデータ通信方法において、
前記データパケット送信制御ステップにおける前記伝送路上の異常検出時の送信制御は、前記サーバから前記クライアントへＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）によりデータパケットを送信する、
ことを特徴とするデータ通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ通信方法に関し、特にＣＳＭＡ／ＣＡ方式の無線ネットワークにおいて、１台のサーバに１台以上のクライアントが接続して通信する場合の、伝送路における通信異常の発生の検出、および通信の異常状態から安定状態への回復制御を行う方法に関するものである。
【背景技術】
【０００２】
従来のＣＳＭＡ／ＣＡ方式（搬送波感知多重アクセス／衝突回避方式）の無線ＬＡＮ通信では、通常、パケットを送信している以外は電波を送信しないので、伝送路上の搬送波が検出されたかどうかによって、伝送経路の使用状況を判断し、伝送路が空いていればパケットを送信し、空いていなければ送信を見合わせるという方法で通信を行っている。
【０００３】
ＣＳＭＡ／ＣＡ、およびＴＣＰ／ＩＰプロトコルは、帯域共有型のネットワークであり、データの種別に依らず、常に最大の帯域を使用して通信が行われるベストエフォート（最大努力）のネットワークである。
【０００４】
従って、どのような機器によるどのような通信であっても、区別なく対等なものとして扱われ、同一のネットワーク上の帯域を共有することになる。
【０００５】
したがって、このようなネットワークにおいては、重要度の高いコネクションのデータ通信に何らかの問題が発生した場合に、他の重要度の低いコネクションとの間で伝送リソースの最適化を行い、重要度の高いコネクションの安定通信のために伝送リソースを確保するといった制御は行われない。
【０００６】
これは、ＩＰネットワークがアプリケーションや通信のデータ種別によらず、１つの共有帯域をベストエフォートで使用することに因る。
【０００７】
この点に鑑み、上記のようにコネクションの重要度に応じた伝送リソースの最適化、および伝送リソースの確保を可能とする制御方法として、ローカルネットワーク内の各クライアントが、自端末の帯域情報を採取して保持するとともに、それを他のクライアントすべてに送信し、各クライアントは、受信した他のクライアントの帯域情報を、自端末の帯域情報に併せて保持するようにする方法がある。
【０００８】
これにより、ネットワーク内の発生帯域情報を把握し、各クライアントが、他のクライアントの帯域情報と自クライアントの帯域情報とを用いて、その時点でのネットワークの帯域量がどのような数値になっているか、帯域量の内訳（例えば、通信品質を保証すべき通信と、品質を保証せず帯域の空きを使ってする通信との割合）がどうなっているかを、把握することができる。
【０００９】
各ネットワークは、把握したネットワークの帯域量に基づいて、送信するデータの帯域量を制御することが可能となる。（特許文献１参照）
【００１０】
また、その他の制御方法として、コネクション時分割多重アクセス方式がある。このコネクション時分割多重アクセス方式は、１つの伝送路をタイムスロットと呼ばれる単位に時分割して、各タイムスロットヘの送信権を制御するものである。
【００１１】
この制御方式には、各コネクション毎に周期的にタイムスロットを割り当てる方式（ＴＤＭＡ）、各コネクション毎にランダムにタイムスロットへの送信を行う方式（スロットアロハ）、各コネクション毎にデータの送信に必要なタイムスロットを予約し、割り当てられたタイムスロット送信を行う方式、およびこれら３方式を複合した方式等がある。
【００１２】
特許第３００３５８０号公報では、上記の時分割多重アクセス方式を拡張した通信方式を開示している。データ同士の衝突が発生するアクセス方式の場合、トラフィックの増大を避けるには、論理リンク制御でのウィンドウサイズによる送信規制が重要であり、スロット予約方式のように、衝突が発生しないアクセス方式を使用する場合は、大きなウィンドウサイズを用いるほうが効率が良くなる。
【００１３】
これを考慮し、回線アクセス制御部の特性に応じて、論理リンク制御部のウィンドウサイズを可変にすることにより、トラフィックの変動に柔軟に適応しつつ、伝送効率の向上を可能としたデータ通信システムを提供しているものである。（特許文献２参照）
【特許文献１】特開２００５−５１８１１号公報
【特許文献２】特許第３００３５８０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかしながら、上記従来の方法では、接続される全てのクライアントに対して同じ制御方法を導入する必要があり、また、サーバとクライアントの双方に、同期を取り通信タイミングの割り当てを行うための、サーバとクライアントで同一の制御方法を導入する必要があった。
【００１５】
これは、無線アドホック型通信のようなＣＳＭＡ／ＣＡ方式の、送受信端末の他にコントロールポイントを有さないネットワーク構成で、不特定多数の多種のクライアントと通信を行う場合には、従来技術の構成で実現することは出来ないという課題を有していた。
【００１６】
本発明は、前記従来の課題を解決するためになされたもので、従来無線ＬＡＮで多く利用されるＣＳＭＡ／ＣＡ方式を用いる場合においても、通信異常の発生の検出、および通信の異常状態から安定状態への回復制御が可能なデータ通信方法を提供することを目的とする。
【課題を解決するための手段】
【００１７】
従来の課題を解決するために、本発明の請求項１にかかるデータ通信方法は、クライアントからのデータ送信要求に応答して、前記クライアントに対してデータパケットを連続的に発信可能なサーバと、前記サーバと接続して通信を行う複数のクライアントとを有し、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ／Ｃｏｌｌｉｓｉｏｎ  Ａｖｏｉｄａｎｃｅ）方式の無線ＬＡＮを用いてＴＣＰ／ＩＰによる通信を行う通信システムにおいて、前記サーバから前記クライアントへのデータパケット送信を、前記サーバによって制御するデータ通信方法であって、前記クライアントから前記サーバに通知されるＴＣＰ／ＩＰのウインドウフロー制御用のウインドウサイズ情報を解析するウインドウサイズ情報解析ステップと、前記ウインドウサイズ情報解析ステップで得られる解析値を用いて、伝送路における異常の発生の判定を行う異常検出ステップと、前記異常検出ステップにおいて前記伝送路における異常の発生が検出されたときには、前記サーバから前記クライアントへのデータパケットの送信の制御を、ネットワークの伝送状態に応じて行うデータパケット送信制御ステップとを有する、ことを特徴とする。
【００１８】
本発明の請求項２にかかるデータ通信方法は、前記データ通信方法において、前記ウインドウサイズ情報解析ステップは、前記サーバが前記クライアントより最大ウインドウサイズの通知を連続して受けたときは、最大ウインドウサイズの値が連続して通知される時間である最大ウインドウ連続通知時間を、その解析値として出力する、ことを特徴とする。
【００１９】
本発明の請求項３にかかるデータ通信方法は、前記データ通信方法において、前記異常検出ステップは、前記クライアントの受信バッファサイズを、Ｍバイト、前記クライアントの一秒間当たりのデータ消費量を、Ｄバイト、前記ウインドウサイズ情報解析ステップが出力する前記最大ウインドウ連続通知時間を、Ｔｎ秒とすると、ＭがＤ×Ｔｎ以下となったとき、前記伝送路に異常が発生したと判定する、ことを特徴とする。
【００２０】
本発明の請求項４にかかるデータ通信方法は、前記データ通信方法において、前記ウインドウサイズ情報解析ステップは、前記サーバが前記クライアントより最大ウインドウサイズの通知を受けたときは、その直前のウインドウサイズ通知時刻と、該最大ウインドウサイズ通知時刻との間の時間である最大ウインドウ通知間隔時間を、その解析値として出力する、ことを特徴とする。
【００２１】
本発明の請求項５にかかるデータ通信方法は、前記データ通信方法において、前記異常検出ステップは、前記クライアントの受信バッファサイズを、Ｍバイト、前記クライアントの一秒間当たりのデータ消費量を、Ｄバイト、前記ウインドウサイズ情報解析ステップが出力する前記最大ウインドウ通知間隔時間を、Ｔｄ秒とすると、ＭがＤ×Ｔｄ以下となったとき、前記伝送路に異常が発生したと判定する、ことを特徴とする。
【００２２】
本発明の請求項６にかかるデータ通信方法は、前記データ通信方法において、前記データパケット送信制御ステップにおける前記伝送路上の異常検出時の送信制御は、前記サーバから前記クライアントへ発信されるデータパケット長を変化させる、ことを特徴とする。
【００２３】
本発明の請求項７にかかるデータ通信方法は、前記データ通信方法において、前記データパケット送信制御ステップにおける前記伝送路上の異常検出時の送信制御は、前記サーバから前記クライアントへ発信されるデータパケット発信間隔を変化させる、ことを特徴とする。
【００２４】
本発明の請求項８にかかるデータ通信方法は、前記データ通信方法において、前記データパケット送信制御ステップにおける前記伝送路上の異常検出時の送信制御は、前記サーバから前記クライアントへ発信されるデータパケット長と、データパケット発信間隔とを変化させる、ことを特徴とする。
【００２５】
本発明の請求項９にかかるデータ通信方法は、前記データ通信方法において、前記データパケット送信制御ステップにおける前記伝送路上の異常検出時の送信制御は、前記サーバから前記クライアントへＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）によりデータパケットを送信する、ことを特徴とする。
【発明の効果】
【００２６】
本発明のデータ通信方法によれば、クライアントからサーバに通知されるＴＣＰ／ＩＰのウインドウフロー制御用のウインドウサイズ情報を解析するウインドウサイズ情報解析ステップと、前記ウインドウサイズ情報解析ステップで得られる解析値を用いて、伝送路における異常の発生の判定を行う異常検出ステップと、前記異常検出ステップにおいて前記伝送路における異常の発生が検出されたときには、前記サーバから前記クライアントへのデータパケットの送信の制御を、ネットワークの伝送状態に応じて行うデータパケット送信制御ステップとを有するので、クライアント側に特別な仕組みを実装することなく、サーバ側はクライアントから通知されるＴＣＰ／ＩＰのウインドウサイズを利用してネットワーク上の通信異常を検出し、通信異常が検出されたクライアントへのデータパケットの送信方法を変化させることによって、同一伝送路内の特定のコネクションのみに対してデータパケットの送信を制御して、通信の異常状態から安定状態への回復を行うことができる。
【発明を実施するための最良の形態】
【００２７】
以下に、本発明のデータ通信方法の実施の形態を、図面とともに詳細に説明する。
（実施の形態１）
図１は、本発明の実施の形態１による無線通信システムの構成を示す。
【００２８】
図１に示される本実施の形態１における無線通信システムは、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ／Ｃｏｌｌｉｓｉｏｎ  Ａｖｏｉｄａｎｃｅ）方式の無線ＬＡＮで構築されており、ＴＣＰ／ＩＰの通信プロトコルを利用し、ＡＶ動画のストリーミング再生用データパケットの通信を行う。
【００２９】
サーバ１は、クライアント２、クライアント３、クライアント４からデータ送信要求を受けて、クライアント２、３、４に対してそれぞれデータパケットを連続的に発信可能である機能を有し、クライアント２、３、４は、自身の通信バッファの空き状態によってウインドウサイズ情報を決定し、サーバ１に通知する機能を有している。
【００３０】
前記ウインドウサイズ情報のウインドウサイズは、各受信側が現在どれだけのデータを受信可能かを表しており、各受信側の受信バッファ内の空き容量によって決定される。各受信側が、送信側に該ウインドウサイズを通知することにより、送信側は、受信側それぞれの受信可能なデータ容量を知ることができ、通知されたウインドウサイズを基に、各クライアントへの送信データ量を決定し送信を行う。
【００３１】
クライアントの受信バッファが空いていれば、ウインドウサイズ情報は大きく、逆に受信バッファが一杯であれば、ウインドウサイズ情報は小さく通知され、サーバ１はクライアント２、３、４から通知された、それぞれのウインドウサイズ情報に見合った量のデータを、クライアント２、３、４に対して送信するようにしたデータ通信のフロー制御が行われる。
【００３２】
図２は、本発明の実施の形態１における、ＴＣＰ／ＩＰのウインドウサイズを利用して、ネットワーク上の通信異常を検出し、データパケットの送信を制御する方法のフロー図を示す。以下に、図２のフロー図について説明する。
【００３３】
先ず、ステップＳ１１で、サーバがクライアントからウインドウサイズ情報を受信する。
【００３４】
次のステップＳ１２では、クライアントから受け取ったウインドウサイズ情報をモニタしその解析を行う。
【００３５】
次のステップＳ１３では、ステップＳ１２で得たウインドウサイズ情報の解析値を基に、通信に異常が発生しているかどうかの判定を行う。
【００３６】
ステップＳ１３で異常が発生していた場合、次のステップＳ１４で、ネットワークの伝送状態に応じて、サーバからクライアントへのデータパケットの送信制御を行う。
【００３７】
ステップＳ１４でデータパケットの送信制御を行って送信されたデータパケットを、次のステップＳ１５でサーバからクライアントに対して送信し、通信異常の状態から安定な通信状態への復帰を試みる。
【００３８】
以下、上記各ステップの詳細について説明する。
ステップＳ１１では、クライアントから通知されるデータ送信要求を受信し、受信したデータからウインドウサイズ情報の取得を行う。ウインドウサイズ情報は、ＴＣＰ／ＩＰのプロトコルを利用した通信では、パケット中のＴＣＰヘッダ内に記述されているので、この値を利用する。クライアント側においては、ウインドウサイズを取得するために特別な実装を行うことは必要でなく、ウインドウサイズの取得は、従来の通信プロトコルを利用して実現可能である。
【００３９】
ステップＳ１２では、ウインドウサイズ情報をモニタし、その情報の解析を行う。図３に、クライアントからサーバに対して通知されるウインドウサイズの時間変化を示す。
【００４０】
図３において、Ｗ−１は、ＡＶ動画のストリーミング再生が正常に行われている状態のウインドウサイズの時間変化の例を示す、正常状態のウインドウサイズ推移線（Ｗ−１）である。
【００４１】
データ通信が正常に行われている場合であれば、ウインドウサイズは、時間経過とともに増減を繰り返し、推移して行く。
【００４２】
これは、サーバからの供給データ量が、クライアントでの再生による消費データ量を上回れば、バッファ内のデータ容量は増加するため、クライアントがサーバに通知するウインドウサイズの大きさを小さくし、サーバからの供給データ量を減少させる方向に働かせ、逆に、消費データ量が供給データ量を上回れば、クライアントはウインドウサイズを大きくして、サーバからの供給データ量を増加させる方向に働かせるためである。
【００４３】
一方、Ｗ−２は、通信に問題が発生した場合のウインドウサイズの推移の例を示す、異常状態のウインドウサイズ推移線（Ｗ−２）である。
【００４４】
異常状態のウインドウサイズ推移線（Ｗ−２）においては、途中で、ウインドウサイズの値が、最大値のまま推移している。該最大ウインドウサイズの値は、ＴＣＰ／ＩＰの規格によって定義されている値であるため、受信バッファサイズに等しいというわけではなく、受信バッファよりも小さな値となっているのが通常である。
【００４５】
伝送路上に、遅延や障害によるパケット消失等の問題が発生し、サーバからのデータパケットがクライアントに到達しにくい状態が続く場合、クライアントの受信バッファ内のデータ消費量がデータ供給量を大きく上回る状態が続き、バッファ内のデータ容量は、減少し続けることとなる。
【００４６】
この場合、設定可能な最大のウインドウサイズ以上の空きがバッファ内に存在することになり、バッファ内のデータ量が増加して、バッファ内の空き容量が最大ウインドウサイズ以下になるまで、クライアントは、サーバに対して最大ウインドウサイズを通知し続けることになる。最大ウインドウサイズが続くことは、受信バッファが枯渇状態にあることを意味する。
【００４７】
ステップＳ１２では、クライアントから通知される最大ウインドウサイズが連続する時間の長さのモニタを行う。すなわち、ステップＳ１２においては、最大ウインドウサイズの通知を受けると、その時刻から最大ウインドウサイズの通知が続く時間Ｔｎ秒を計測し、このＴｎの値を解析値として、ステップＳ１３の判定に利用する。
【００４８】
次のステップＳ１３では、ステップＳ１２で得た最大ウインドウサイズの通知が続く時間の解析値Ｔｎを用いて、伝送路の異常発生の判定を行う。
【００４９】
クライアントの受信バッファサイズを、Ｍバイト、クライアントの１秒間当たりのデータ消費量を、Ｄバイトとし、最大ウインドウサイズの通知が続く間は、通信バッファ内のデータ量は減少し続けていると考えると、「Ｄ×Ｔｎ  ≧  Ｍ」となることで、バッファ内のデータが枯渇状態に近づいているものと推測でき、伝送路に異常が発生したとの判定を行うことができる。この際、Ｄの値は、送信するＡＶ動画データのビットレートを用いても良いし、事前に正常通信時のデータ転送レートを測定しておいてその値を用いても良い。
【００５０】
また、Ｍの値については、クライアント側のバッファサイズが不明の場合は、一般に用いられるＴＣＰの通信バッファサイズ、例えば２４Ｋバイトを用いても良いし、事前にサーバからクライアントへクライアントが要求するデータ量よりも多いデータパケットを過剰に送信するようにし、クライアントから返答されるウインドウサイズが０になるまで、累積の過剰送信パケット量から概算した値を用いるようにしてもよい。
【００５１】
また、ステップＳ１３において、以下のように異常発生の検出を行ってもよい。
まず、ステップＳ１２において、クライアントから最大ウインドウサイズの通知を受信したときの、該通知時刻と、その直前のウインドウサイズ情報通知時刻との間の時間Ｔｄ秒を、計測し、このＴｄ秒を解析値として算出する。
【００５２】
次のステップＳ１３では、ステップＳ１２で得た解析値Ｔｄを用いて、伝送路の異常発生の判定を行う。Ｔｄ秒の間は、クライアントの受信バッファ内のデータは、消費され続けており、「Ｄ×Ｔｄ  ≧  Ｍ」となることで、バッファ内のデータが枯渇状態に近づいていると推測でき、伝送路に異常が発生したとの判定を行うことが可能である。
【００５３】
ステップＳ１４では、ステップＳ１３で異常発生と判定された場合に、クライアントが要求するデータを安定的に送信できるように、データパケットの送信制御を行う。このデータパケットの送信制御の方法を、図４のフローチャートに示す。
【００５４】
図４において、前記ステップＳ１３で異常発生を検出すると、ステップＳ２１で、通信の安定化を促すために、サーバはクライアントへ送信するデータパケットのパケット長を増加させる。ここで、パケットの増加量は、通信するデータ量や通信内容によって適当な値を選択するようにすればよい。例えば、最大ウインドウサイズの１０％ずつパケット長を増加させ、クライアントへ送信するという方法を取ることができる。
【００５５】
ステップＳ２２で、サーバはデータパケットをクライアントへ送信し、データパケットを受け取ったクライアントは、データパケットの受信によって変化したウインドウサイズ情報を、サーバに通知する。
【００５６】
ウインドウサイズ情報の返答を受信したサーバは、ステップＳ２３で、ウインドウサイズの値の判定を行う。ウインドウサイズが最大ウインドウサイズよりも小さくなっていなければ、ステップＳ２１に戻り、データパケット長をさらに増加させ、パケット送信を行う。
【００５７】
ステップＳ２３で、ウインドウサイズが最大ウインドウサイズから減少していれば、ステップＳ２４で、ウインドウサイズが０になっているかどうかの判定を行い、０でなければ、データパケット長はそのままでステップＳ２２に戻り、クライアントに対してデータパケットを送信する。
【００５８】
ステップＳ２４で、ウインドウサイズが０である場合は、クライアントで過剰なデータパケットを受信しているということを意味するので、ステップＳ２５に移行し、データパケットの送信方法を通常方法へ戻す。
【００５９】
ここで、ＣＳＭＡ／ＣＡ方式の無線ＬＡＮ通信では、伝送路が空いていればパケットを送信し、空いていなければ送信を見合わせるという方法で通信を行うため、データパケットの送信は早い者勝ちである。
【００６０】
しかし、上記ステップＳ２１でデータパケット長を増加させて送信することにより、伝送路の確保の確率は同じでも、１パケット当たりのデータ量を増加させることができ、伝送路上の遅延による通信異常の場合には、クライアントの安定動作に必要な帯域を確保することが可能となるものである。
【００６１】
また、その他の好適なデータパケット送信制御方法としては、ステップＳ２１で、パケット長を短くし、パケットの送信間隔を短くするようにしてもよく、このような方法によっても、同様に通信を異常状態から回復させることができる。
【００６２】
例えば、パケット長を半分にした場合は、パケット送信間隔を半分にして２パケットを送信するという方法を取ることができる。
【００６３】
このようにパケット送信間隔を短くすることにより、パケット送信のための伝送路の確保の確率を上げることができ、パケット消失などの通信異常の場合には、クライアントに対してより多くのデータを到達させる確率を上げることが可能となるものである。
【００６４】
また、パケット長はそのままで、パケット送信間隔のみを短くすることによっても、同様に、パケット送信における伝送路の確保の確率を上げ、通信を異常状態から回復させることができる。
【００６５】
さらに、その他の好適なデータパケット送信制御方法としては、上記ステップＳ２１における、パケットの送信方法を、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）方式による送信に変更してもよく、上記と同様に通信を異常状態から回復させることができ、以下にその説明をする。
【００６６】
上記ＵＤＰ方式の通信は、コネクションレス型の通信方式であり、サーバがクライアントにデータを送信しても、クライアント側からのデータ受け取り確認を行わないため、信頼性の無い通信方式である。
【００６７】
しかし、このＵＤＰ方式の通信は、クライアント側からの応答を待たずにサーバからクライアントにデータを送信するため、高速のデータ転送が可能であり、サーバ側の制御を行うのみで、サーバとクライアントとの間のデータ送信方法の制御を行うことが可能である。
【００６８】
そして、このＵＤＰ方式の通信は、信頼性は無いが高速の通信が可能であるため、ＡＶ動画データのストリーミング通信等、多少の通信エラーが問題にならない通信においては、有効な方法であると言えるものである。
【００６９】
また、このＵＤＰ方式の通信を行う際にも、データパケット長、およびデータパケット発信間隔を変化させることができる。
【００７０】
以上のような本実施の形態１によるデータ通信方法によれば、クライアントからのデータ送信要求に応答して、前記クライアントに対してデータパケットを連続的に発信可能なサーバと、前記サーバと接続して通信を行う複数のクライアントとを有し、ＣＳＭＡ／ＣＡ方式の無線ＬＡＮを用いてＴＣＰ／ＩＰによる通信を行う通信システムにおいて、前記サーバから前記クライアントへのデータパケット送信を、前記サーバによって制御するデータ通信方法であって、前記クライアントから前記サーバに通知されるＴＣＰ／ＩＰのウインドウフロー制御用のウインドウ情報を解析するウインドウ情報解析ステップと、前記ウインドウ情報解析ステップで得られる解析値を用いて、伝送路における異常の発生の判定を行う異常検出ステップと、前記異常検出ステップにおいて前記伝送路における異常の発生が検出された場合、前記サーバから前記クライアントへのデータパケットの送信の制御を、ネットワークの伝送状態に応じて行うデータパケット送信制御ステップとを有するものとしたので、クライアント側に特別な仕組みを実装することなく、サーバ側はクライアントから通知されるＴＣＰ／ＩＰのウインドウサイズを利用してネットワーク上の通信異常を検出し、通信異常が検出されたクライアントへのデータパケットの送信方法を変化させることによって、同一伝送路内の特定のコネクションのみに対してデータパケットの送信を制御して、通信の異常状態から安定状態への回復を行うことができる。
【産業上の利用可能性】
【００７１】
本発明にかかるデータ通信方法は、クライアントからサーバに通知されるＴＣＰ／ＩＰのウインドウサイズを利用して、ネットワーク上の通信異常を検出し、サーバ側からのデータパケットの送信を制御することによって、クライアント側に特別な仕組みを実装することなく、同一伝送路内の特定のコネクションのみに対して送信制御を行うことが可能となるものであり、特に、ＣＳＭＡ／ＣＡ方式の無線ネットワークにおいて、１台のサーバに１台以上のクライアントが接続する場合の伝送路の通信異常の発生検出、および通信の異常状態から安定状態への回復制御を行う方法として有用である。
【図面の簡単な説明】
【００７２】
【図１】本発明の実施の形態１によるデータ通信方法を実施する無線通信システムの構成図
【図２】本発明の実施の形態１における、データパケット送信制御方法のフロー図
【図３】本発明の実施の形態１における、ウインドウサイズの時間変化を示すグラフ
【図４】本発明の実施の形態１における、データパケット送信制御方法の一部のフロー図
【符号の説明】
【００７３】
１  サーバ
２、３、４  クライアント
Ｓ１１  ウインドウサイズ情報を受信するステップ
Ｓ１２  ウインドウサイズ情報を解析するステップ
Ｓ１３  通信に異常が発生しているか否かを判定するステップ
Ｓ１４  データパケットの送信制御を行うステップ
Ｓ１５  データパケットを送信するステップ
Ｓ２１  パケット長を増加させるステップ
Ｓ２２  データパケットを送信するステップ
Ｓ２３  ウインドウサイズ情報の受信と、ウインドウサイズが減少しているか否かを確認するステップ
Ｓ２４  ウインドウサイズが０か否かを確認するステップ
Ｓ２５  通常のパケット送信制御を行うステップ
Ｗ−１  正常状態のウインドウサイズ推移線
Ｗ−２  異常状態のウインドウサイズ推移線
【図１】
2008288740.tif 000003
【図２】
2008288740.tif 000004
【図３】
2008288740.tif 000005
【図４】
2008288740.tif 000006