(57)【要約】本発明は、アクセス可能な帯域が限られている無線TCP/IPネットワークで、リアルタイムトラヒックにより多くの帯域を割り当てるトラヒックシェーパーモジュールを提供する。これはIEEE802.11bネットワークに特に関連する。ダウンストリームデータについて、トラヒックシェーパーモジュールは、全てのクライアントへの伝送を制御し、それによりリアルタイムデータを運ぶポートに優先度を与えるように設定され得る。アップストリームの場合は、全ての形式の標準的な装置からのデータ伝送が低減又は遅延される。従って、他のクライアントからのデータ伝送はアクセスポイントからリモートで制御される必要がある。他のクライアントへのTCP肯定応答のようなパケットを遅延又は破棄することにより、トラヒックシェーパーモジュールはそのラウンドトリップタイムを人為的に増加する。これらのクライアントのプロトコルは、より低いレートでデータを送信することにより、更なるRTTに対応し、それによってリアルタイムデータポートにより多くの帯域を残す。
2006511140.tif 000002
【特許請求の範囲】
【請求項１】
無線ネットワークにおいてアクセスポイントと１つ以上の第１のクライアントとの間でリアルタイムデータを伝送するシステムであって、
−ユーザデータグラムプロトコルを有する伝送制御プロトコル／インターネットプロトコル群で動作するアクセスポイントと、
−前記アクセスポイントに関連し、無線ネットワークを形成する２つ以上のクライアントと、
−前記アクセスポイントにより保持され、少なくともリアルタイムデータが前記アクセスポイントと第１のクライアントとの間で伝送されたときに、前記アクセスポイントから前記１つ以上の第１のクライアント以外のクライアントへの少なくともいくつかのパケットの伝送を遅延させるトラヒックシェーパーモジュールと
を有するシステム。
【請求項２】
請求項１に記載のシステムであって、
前記トラヒックシェーパーモジュールは、TCP/IPプロトコルスタックのネットワークインタフェースレイヤの一部を形成するシステム。
【請求項３】
請求項１に記載のシステムであって、
前記トラヒックシェーパーモジュールは、前記アクセスポイントから送信されるパケットのヘッダを調査し、前記パケットが前記１つ以上の第１のクライアントのリアルタイムデータのものとして認識された場合に、前記リアルタイムデータの伝送を遅延させないように適合された要素を有するシステム。
【請求項４】
請求項１に記載のシステムであって、
前記アクセスポイントから送信されるパケットのヘッダを調査し、前記パケットが前記１つ以上の第１のクライアント以外のクライアントへのTCP肯定応答として認識された場合に、前記TCP肯定応答の伝送を遅延又は破棄するように適合された要素を有するシステム。
【請求項５】
無線ネットワークにおいて、ユーザデータグラムプロトコルを有する伝送制御プロトコル／インターネットプロトコル群で動作するアクセスポイントと、１つ以上の第１のクライアントとの間でリアルタイムデータを伝送する方法であって、
−前記無線ネットワークにおける他のクライアントと前記アクセスポイントとの間でデータ伝送を制御し、前記１つ以上の第１のクライアントに更に大きい帯域を割り当て、前記トラヒックを制御するステップは、前記アクセスポイントから他のクライアントへの少なくともいくつかのTCP肯定応答の伝送を遅延又は破棄するステップを有するステップと、
−前記アクセスポイントと第１のクライアントとの間でリアルタイムデータを伝送するステップと
を有する方法。
【請求項６】
無線ネットワークのクライアントから前記無線ネットワークのアクセスポイントへのデータ伝送を制御する方法であって、
前記アクセスポイントと前記クライアントはユーザデータグラムプロトコルを有する伝送制御プロトコル／インターネットプロトコル群で動作し、
−前記アクセスポイントでダウンストリームデータパケットを受信するステップと、
−前記パケットのヘッダを調査し、データパケットが前記無線ネットワークのクライアントへのTCP肯定応答であるか否かを決定するステップと、
−前記クライアントに利用可能な帯域が前記クライアントからのアップストリームデータパケットにより超過したか否かを決定し、そうである場合には、前記アクセスポイントから前記クライアントへの前記TCP肯定応答の伝送を遅延させるステップと
を有する方法。
【請求項７】
コンピュータにロードされ又はコンピュータにより実行されると、請求項５又は６に記載の１つ以上のステップを実行する情報を有する記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ネットワークにおけるオーディオ／ビデオ(A/V)ストリーム伝送のようなリアルタイムストリーミングデータに関するものである。特に、本発明は、データトラヒックの干渉に対してそのようなリアルタイムデータを保護し、中断のないストリーミングを確保することに関するものである。
【背景技術】
【０００２】
一般的に、現在の無線ネットワークアクセスシステムは、アクセスポイントとクライアントとの間の無線リンクに限られた帯域を有する。単一のクライアントはブロードバンド接続を受けることができるが、同じアクセスポイントの他のユーザからのデータバーストはその接続と一時的に干渉する。このことは、ブロードバンド接続が通常のデータトラヒックに使用されている場合には、一般的に問題を引き起こさない。しかし、ブロードバンド接続がA/Vストリーミングのようなリアルタイムデータを伝送している場合、他のユーザからのバーストによるデータ欠落はストリーミングと干渉し、回避されるべきである。無線ネットワークに多数の異なる標準が存在し、IEEE802.11bが現在では最も一般的である。更に、無線ネットワークで使用され得る多数の通信プロトコルが存在し、異なる標準を利用している。
【０００３】
US2002/0075806A1は、システムを通じてサービス品質(QoS)を保つデータ通信システム及び方法を開示する。そのシステムは、インターネットやファイル転送等のような他のデータを犠牲にして、音声会議やテレビ会議のような遅延時間に敏感なサービスが保証帯域を受けることを確保することを必要とする。帯域は、システムでカスケード・ネットワーク(cascading  network)を通じて、連続的なリンクにタイムスロットを確保することにより保証される。第１のタイムスロットが次のタイムスロットの前の短い時間に開始し、カスケード・ネットワークを通じて流動的なストリーミングの準備を行うように、タイムスロットが調節される。
【０００４】
従来技術は、アクセス可能な帯域が限られている無線ネットワークで、リアルタイムデータにより多くの帯域を割り当てる問題を実現する。しかし、従来技術は、帯域が実際に割り当てられる方法に対して詳細な解決策を指摘していない。
【０００５】
IEEE802.11b無線ネットワークにおけるA/Vメディアコンテンツのストリーミングは、問題が生じることがある。802.11b標準は等時性チャネルの適切なサポートなしに単に無線イーサーネットを定めているため、他のネットワークトラヒックがリアルタイムデータと容易に干渉することがあるからである。802.11bはチャネル予約モード(channel  reservation  mode)(RTS/CTS)を有するが、このモードは前述の問題を解決せず、また、それはオプションであるためほとんどの製品がそれを実装していない。新たなQoS機能が802.11eに実装されているが、802.11bにはない。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
無線ネットワークプロトコルにおけるリアルタイムデータ伝送に帯域を割り当てるシステム及び方法を提供することが、本発明の目的である。
【課題を解決するための手段】
【０００７】
第１の態様において、本発明は、無線ネットワークにおいてアクセスポイントと１つ以上の第１のクライアントとの間でリアルタイムデータを伝送するシステムを提供し、そのシステムは、
−ユーザデータグラムプロトコル(UDP:User  Datagram  Protocol)を有する伝送制御プロトコル／インターネットプロトコル(TCP/IP)群で動作するアクセスポイントと、
−アクセスポイントに関連し、無線ネットワークを形成する２つ以上のクライアントと、
−アクセスポイントにより保持され、少なくともリアルタイムデータがアクセスポイントと第１のクライアントとの間で伝送されたときに、アクセスポイントから１つ以上の第１のクライアント以外のクライアントへの少なくともいくつかのパケットの伝送を遅延させるトラヒックシェーパーモジュールと
を有する。
【０００８】
トラヒックシェーパーモジュールは、アクセスポイントから送信されるパケットのヘッダを調査し、パケットがTCP肯定応答として認識された場合に、TCP肯定応答(TCP  ACK:TCP  Acknowledgement)の伝送を遅延させるように適合された要素を有することが好ましい。
【０００９】
好ましい実施例では、非リアルタイムデータ伝送がアップストリームである場合(すなわち、干渉するクライアント(第１のクライアント以外)からアクセスポイントに対しての場合)、トラヒックシェーパーモジュールはダウンストリームTCP  ACKに適切な遅延を取り込む。この技術は、自己クロックのTCPフロー制御機構を利用しており、そのTCPフロー制御機構はTCP  ACKパケットに基づく。
【００１０】
その他の好ましい実施例では、トラヒックシェーパーモジュールは、リアルタイムトラヒックパケットでない全てのダウンストリームIPパケット(TCP  ACK及びデータペイロードパケット)に遅延を取り込む。場合によっては、遅延はペイロードパケットのような帯域を要求するダウンストリームIPパケットのみに取り込まれる。
【００１１】
トラヒックシェーパーモジュールは、アクセスポイントのような住宅用ゲートウェイのネットワークドライバに実装されるソフトウェアであることが好ましい。それはプロトコルレイヤのリンクレイヤで動作する。トラヒックシェーパーは既存のプロトコルを変更しないことが好ましく、それは更なる機能のみを提供する。
【００１２】
そのシステムは、遅延パケットを一時的に格納するように適合されたメモリバッファを有することが好ましい。メモリバッファは、住宅用ゲートウェイに利用可能であり、トラヒックシェーパーモジュールによりメモリバッファとして備えられ得る如何なるメモリでもよい。
【００１３】
第２の態様において、本発明は、以下の処理ステップ：
−無線ネットワークにおける他のクライアントとアクセスポイントとの間でデータ伝送を制御し、１つ以上の第１のクライアントに更に大きい帯域を割り当て、そのトラヒックを制御するステップは、アクセスポイントからクライアントへの少なくともいくつかのTCP肯定応答(TCP  Acknowledgement)の伝送を遅延させるステップを有し、
−アクセスポイントと第１のクライアントとの間でリアルタイムデータを伝送すること
を使用することで利用可能にされた帯域を利用することにより、無線ネットワークにおいて、UDPを有するTCP/IP群で動作するアクセスポイントと、１つ以上の第１のクライアントとの間でリアルタイムデータを伝送する方法を提供する。
【００１４】
任意選択で、アクセスポイントから全てのクライアントへの非リアルタイムのダウンストリームトラヒックもまた遅延してもよい。
【００１５】
第３の態様において、本発明は、無線ネットワークのクライアントからその無線ネットワークのアクセスポイントへのデータ伝送を制御する方法を提供し、アクセスポイントとクライアントはUDPを有するTCP/IP群で動作し、その方法は、
−外部ネットワーク又は住宅用ゲートウェイ自体のアプリケーションからアクセスポイントでダウンストリームデータパケットを受信するステップと、
−そのパケットのヘッダを調査し、データパケットが無線ネットワークのクライアントへのTCP肯定応答であるか否かを決定するステップと、
−そのクライアントに利用可能な帯域がクライアントからのアップストリームデータパケットにより超過したか否かを決定し、そうである場合には、アクセスポイントからクライアントへのそのTCP肯定応答の伝送を遅延させるステップと
を有する。
【００１６】
第４の態様において、本発明は、コンピュータにロードされ又はコンピュータにより実行されると、第２又は第３の態様による１つ以上のステップを実行する情報を有する記録媒体を提供する。
【００１７】
この出願において、リアルタイムデータという用語は、情報がシステムに入力して格納されて後で動作するバッチ処理に対して、コンピュータに入力した時点で処理されるデータを示す。リアルタイムデータはまた、ストリーミングデータとも呼ばれる。一般的に、リアルタイムデータは生の映像又は生の音声伝送のようなストリームである。しかし、大量の外部データ(他のPCに格納された映画クリップ等)がクライアントにより視聴される必要がある場合にも、リアルタイムストリーミングが使用される。全てのデータがダウンロードされるのを待つのではなく、データが到達すると逐次、クライアントはデータを視聴し始める。このように、データ自体はリアルタイムである必要はなく、過去に記録されていてもよい。伝送の中断は、データの実行における中断(中断がバッファサイズを超過した場合)を意味し、望ましくない。一般的に、ストリーミングは、動作の実行を可能にするその厳格な順序のため、オーディオ／ビデオコンテンツを備えたデータに使用されるが、ストリーミングは同様に他の種類のデータにも使用可能である。
【００１８】
アクセスポイントは、有線ネットワークに無線ネットワークを相互接続するネットワーク装置である。アクセスポイントが２つの無線ネットワークを相互接続する役割をするように、有線ネットワークは他の無線ネットワークと相互接続されてもよい。一般的に、アクセスポイントは、無線IEEE802.11標準を使用したTCP/IPのような通信プロトコルを備えたPC又は住宅用ゲートウェイ(RG:Residential  Gateway)のような専用ネットワークアクセス装置又はサーバである。
【００１９】
この出願において、クライアントは、アクセスポイントとの無線通信を要求する装置(又はソフトウェア)である。クライアントは、その他のサーバ、PC、携帯電話、携帯情報端末(PDA)、又は無線通信プロトコルを使用してデータを無線で送受信する手段を有するその他の装置でもよい。
【００２０】
既存の無線ネットワーク通信プロトコルの知識を利用し、MACレイヤとトランスポートレイヤの双方においてプロトコルの通常の動作モードに変更を取り込まない(すなわち、IEEE802.11b及びTCP/IPプロトコルの実装が不変である)ことが、本発明の利点である。
【００２１】
新たな構成要素をクライアントに設置する必要が全くないように、リアルタイムストリーミングの配信を改善することが、本発明の好ましい実施例の利点であり、本発明は適切な標準の応答を有するプロトコルを備えた如何なる無線クライアントでも使用可能である。
【００２２】
リアルタイムストリーミングコンテンツを認識しているクライアントでのアプリケーションなしに、リアルタイムストリーミングコンテンツの配信を改善し、そのクライアントが更なるラウンドトリップタイムを単に受けることが、本発明の好ましい実施例の利点である。
【００２３】
ほとんどの製品が実装していないチャネル予約モードを利用することなく、また、MAC動作に変更することなく、IEEE802.11bのような無線イーサーネット媒体ネットワークでリアルタイムストリーミングコンテンツの配信を改善することが、本発明の好ましい実施例の利点である。
【００２４】
アクセス可能な帯域が限られている無線ネットワークにおいてリアルタイムデータにより多くの帯域を割り当てる問題は、ダウンストリームの場合とアップストリームの場合とに分けられてもよい。ダウンストリームの非リアルタイムストリーミングの場合、他のクライアントへのダウンストリームデータ伝送は遅延するべきである。トラヒックシェーパーモジュールは、全てのクライアントへのデータの伝送を制御し、それによって特定の帯域が特定のクライアントに必要になったときに特定のクライアントへのデータを遅延させるように設定されてもよい。しかし、アップストリームの場合は更に複雑になる。その場合、リアルタイムストリーミング以外の全ての他のクライアントからのデータ伝送は中央で制御されなければならない。しかし、これらのクライアントは、トラヒックシェーパーモジュールが設置されていないことがある全ての種類の標準的な装置でもよい。従って、他のクライアントからのデータ伝送は、アクセスポイントからリモートで制御されなければならない。
【００２５】
TCP/IPのような既存のネットワーク通信プロトコルの知識を利用することが、本発明の基本概念である。リアルタイムストリーミングに使用されていないポート(クライアント)へのTCP  ACKのようなパケットを遅延させることにより、アクセスポイントのトラヒックシェーパーは、
１．より長いラウンドトリップタイム(RTT:Round  Trip  Time)をシミュレートする。クライアントのTCPプロトコルは、遅延したTCP  ACKを受信するまで次に送信されるパケットを保持することにより、更なるRTTに対応する。このことは以下のパケットにも同様に当てはまる。スライディングウィンドウ(sliding  window)フロー制御機構では、ACKを受信するまでウィンドウが次のセグメントに移動しないことを意味する。これは、クライアントからの伝送レートを減少させ、それによってリアルタイムデータポートに更なる帯域を残す。
２．そのポートの平均RTT及びRTT変化を人為的に増加させる。クライアントのプロトコルは、伝送タイムアウトを増加させることにより、更なるRTT平均及び変化に対応し、それによってTCP  ACKが更に遅延したときに伝送が送信されない。このことは、クライアントが再伝送で無線媒体をあふれさせないように、タイムアウトが次第に増加することを確保する。
【００２６】
非ストリーミングクライアントのプロトコルは標準的なTCPプロトコルであり、トラヒックシェーパーにより作られた遅延に標準的な方法で対応する。同様に、パケットの遅延と、その後の非ストリーミングクライアントのアプリケーションからの伝送レートの減少は、それを認識しているアプリケーションなしに生じる。従って、クライアントに構成要素を設置する必要がない。
【００２７】
本発明の前記及び他の態様は、以下に説明する実施例を参照して明らかになる。
【発明を実施するための最良の形態】
【００２８】
図１に示す本発明の好ましい実施例では、アクセスポイント103と、複数のクライアント104、105、106とを有するネットワークアクセスサーバ102は、インターネット101に接続されている無線ネットワーク100を構成する。アクセスサーバとアクセスポイントは１つの統合装置でもよく、そのため同義的に呼ばれる。無線ネットワークはTCP/IPのもとで動作し、IEEE802.11b標準を使用し、インフラモード又はアドホックモードで構成されている。リアルタイムデータ107は、アクセスポイント103とクライアント104との間で(アクセスポイントからクライアントに、又はその逆方向に)伝送される。以下のセクションでは、本発明をこの好ましい実施例に関して説明する。このことは、この好ましい実施例の特定の要素が本発明に必須であることを示すのではなく、また、本発明の範囲を限定するものとして解釈されるべきではない。
【００２９】
本発明は、アップストリームリアルタイムデータを有するポートにアップストリーム帯域を予約するように、クライアント105、106からアクセスポイント103にアップストリームデータ伝送を制御する方法を提供する。従って、本発明は、ダウンストリームデータ伝送と干渉することにより、アップストリームデータ伝送を制御する。
【００３０】
本発明はまた、緊急のストリーミングコンテンツのないダウンストリームデータパケットに遅延を提供し、ダウンストリームリアルタイムデータを有するポートにダウンストリーム帯域を予約することができる。本発明によるトラヒックシェーパーは、利用可能な帯域(=全帯域からストリーミングポートに必要な帯域とMACオーバーヘッド帯域とを引いたもの)と、入力ダウンストリームデータパケットのサイズとを調べることにより、この機能を実行することができる。ダウンストリームデータパケットのレートが利用可能な帯域を一時的に超過すると、パケットは遅延又は破棄されるべきである。ダウンストリーム帯域を予約するようにダウンストリームデータを制御することは簡単なタスクであり、専用のシグナリングプロトコルの必要なく、トラヒックシェーパーにより実行される。
【００３１】
この説明において、データパケットが遅延しないと考えられる場合、クライアント105、106からアクセスポイント103へのアップストリームデータ伝送を制御する目的で遅延しないことを意味する。しかし、同じデータパケットはアクセスポイント103からクライアント105、106へのダウンストリームデータ伝送を制御する目的で遅延することがある。
【００３２】
トラヒックシェーパーモジュールは、IEEE802.11bカードのネットワークドライバとTCP/IPプロトコルとを有するネットワークアクセスサーバ102に格納されたソフトウェアのパックである。図２は、プロトコルスタックにおけるトラヒックシェーパーモジュールの位置を示している。トラヒックシェーパーは仮想デバイスドライバとして実装されてもよい。仮想デバイスドライバは、TCP/UDP/IPスタックと既存の無線ネットワークドライバとの間でデータパケットを交換する。従って、トラヒックシェーパーモジュールは、リンクレイヤで動作し、TCPフロー制御アルゴリズムの知識を利用する。そのため、トラヒックが暗号化されていない場合には、(アップストリーム及びダウンストリームで)受信した全てのパケットを調査し、ヘッダフィールドを調べる必要がある。アップストリームパケットは下位レイヤの無線ネットワークドライバにより受信され、特定の無線クライアントが進行中のデータ伝送を有しているか新しいものを開始しているかを決定するために使用され得る。ダウンストリームパケットは上位レイヤ(IPスタック又はブリッジモジュール)からトラヒックシェーパーで受信され、即座に若しくは指定の遅延の後に送信され、又は他のブロードキャストトラヒックのARPのような冗長のネットワークプロトコルの場合には破棄される。最も簡単な場合、パケットは平文で送信され、トラヒックシェーパーは例えばTCP  ACKを認識するためにヘッダフィールドを直接調査することができる。暗号化パケットの場合、トラヒックシェーパーは、フレームサイズとヘッダの非暗号化部分とを調べることにより、TCP  ACKを認識しようとしてもよい。
【００３３】
トラヒックシェーパーモジュールのパケット処理アルゴリズムのフローチャート300を図３に示す。送信されるダウンストリームパケットは、パケットが属するフロー(リアルタイムストリーミングパケット、他のデータパケット又はTCP  ACK)に応じて、異なる優先度で別々のキュー301、302、303に分類及びバッファされる。
【００３４】
パケットを分類するために、IPパケットのプロトコル形式が最初に検査される。プロトコル形式がUDPである場合、リアルタイムトラヒックパケットである可能性が十分に存在する。既知のリアルタイムストリーミングポートに対するソースUDPポートの更なる検査は、“緊急”のパケットを処理しているか否かを明らかにする。パケットが緊急のリアルタイムデータと認識されると、トラヒックシェーパーにより他の動作が実行される必要があり、現在使用中のストリーミングアプリケーションにより必要な帯域をトラッキングして格納する必要がある。この情報は、どの程度の帯域が非リアルタイムTCPアプリケーションに利用可能であるかを知り、リソースを効率的に管理するために使用される。IPパケットがUDP形式でない場合、TCP  ACKであるか否かを検査する。ACKは一般的にペイロードを全く運ばず、“ACK”フィールドセットを有しているため、容易に認識される。TCP  ACKパケットを処理している場合、パケットに適用しようとする遅延を計算するために、(UDPトラヒックで行ったものと同様に)それが属するTCP接続を特定する必要がある。遅延は、有している利用可能な帯域(すなわち、リンクの帯域からリアルタイムデータアプリケーションにより費やされる帯域とMACオーバーヘッドとを引いたもの)に従って計算され、当然のことながらアップストリームIPパケットのサイズに依存する。アップストリームパケットサイズはMACレイヤで認識され、無線ネットワークドライバにより利用可能にされる。
【００３５】
トラヒックが暗号化されている場合、分類動作は更に複雑になる可能性がある。安全なインターネットトランザクションでは一般的なセキュアソケットレイヤ(SSL:Secure  Socket  Layer)機構が使用される場合、TCP/IPパケットヘッダは平文で送信され、トラヒックシェーパーは容易にTCP  ACKを認識することができる。ネットワークレイヤのセキュリティがその代わりに適用されている場合(例えば、仮想プライベートネットワークが使用されている場合)、TCPヘッダは暗号化されている。この場合、トラヒックシェーパーはIPヘッダのみを検査し、特定のスレーブを対象とするパケットをフィルタリングする。トラヒックシェーパーは、A/Vストリームに属するものを除いて、全てのパケットを期間Δ(B)だけ遅延させるように選択してもよい。期間Δ(B)はストリーミングに予約された帯域Bに依存する。
【００３６】
キューは、リアルタイムデータ用の高優先度キュー301と、ダウンストリームデータパケット用の通常優先度キュー302と、TCP  ACK用の低優先度キュー303である。当然ながら、本発明の原理を動作させながら、他のキューが作られてもよい。スケジューラ304は、キューの優先度を考慮に入れた方策に従ってキューを空にする。このような方策の例には重み付きラウンドロビン(WRR::Weighted  Round  Robin)があるが、他の多数のスケジュールアルゴリズムが文献に見出すことができる。WRRを用いて、各キューはキューの優先度に比例した頻度でスケジューラ304によりポーリングされ、少なくとも１つのパケットがバッファされると、伝送用に待機解除される。WRRに対する可能な代替方法は、いわゆるEarliest  Deadline  First(EDF)スケジュール方策である。EDFを使用して、送信される各パケットは、キューされたときにタイムスタンプでタグ付けされる。どのパケットを送信するかを決定するときに、スケジューラ304は最も緊急なタイムスタンプの印のあるパケットについて各キューを検索する。この場合、トラヒックフローを区別するトラヒックシェーパーモジュールの分類機能は、このようなタイムスタンプ特性を割り当てる必要がある。
【００３７】
図４Ａ及びＢは、本発明の動作原理を詳細に示している。図４Ａは、本発明によるトラヒックシェーパーのない場合のTCPを使用した信号フローを示している。図４Ａにおいて、クライアント401がデータセグメント402をサーバ403に送信すると、宛先サーバ403がセグメント402をうまく受信すると常に宛先サーバ403がTCP  ACK404で応答することが予想される。クライアントがセグメントを送信する毎に、タイマを起動し、TCP  ACKを待つ。対応するTCP  ACKの前にタイマが終了(タイムアウト)すると、パケットが損失又は欠落したとTCPが仮定し、それを再送信する。再送信タイムアウトは、そのパス(又はACKパス)で遅延を受ける毎にパケットが再送信されないように設定されることが好ましい。他方、タイムアウトが長すぎる場合、損失データの復旧が遅すぎることになる。TCP/IPでは、タイムアウトの継続的な計算は、RTTの変化と平均との双方を適用したアルゴリズムに基づく。
【００３８】
図４Ｂは、本発明によるトラヒックシェーパーモジュールのある場合のTCPを使用した信号フローを示している。モジュールは、TCP/IPのTCP  ACKタイミング手順を利用し、クライアントからの送信を間接的に制御する。TCP  ACKタイミングは、J.Border他のPerformance  Enhancing  Proxies  Intended  to  Mitigate  Link-Related  Degradations,  RFC3135,  IETF  PILC  WGに記載されている。図４Ｂにおいて、クライアント401がデータセグメント402をサーバ403に送信すると、それはアクセスポイント103により遅延されない。他のクライアントがリアルタイムデータを送信している場合、サーバ403からクライアント401へのACK404は、図３に関して説明した手順に従ってトラヒックシェーパーモジュールによりTCP  ACKとして認識される。アップストリーム帯域を安全にするためにACKの遅延が必要な場合、ACKは指定の時間(ACK遅延)だけ遅延される。RTTはそれに応じて延長される。遅延の間、ACKフレームはアクセスポイントのバッファに格納される。ACKを遅延させる場合、制御不能なアップストリームデータを生じるため、RTTがタイムアウトを超過するほど長くACK遅延を行わないようにすることが重要である。従って、ACK遅延はクライアントのTCPでのタイムアウトの計算に注意して決定されるべきである。RTT及び再送信タイムアウトの計算に関する問題は、例えばDouglas  E.ComerのInternetworking  with  TCP/IP,  vol.I,  3rd  edition,  Prentice-Hall,  1995,  ISBN0-13-216987-8にある。
【００３９】
TCP  ACKに適用される時間遅延は複数のアルゴリズムに従って計算されてもよい。以下に、本発明の目的に使用可能な簡単なアルゴリズムの例を挙げる。単一の干渉するTCP接続を有し、一定のパケットサイズ、飽和したTCPウィンドウ及びACKパケットの一定のフローの場合に、リアルタイムデータをダウンストリームする無線ネットワークを仮定する。また、以下のことを定義する。
−TACKはTCK  ACKパケットの到達間隔時間である
−ΔACKは適用される遅延である
−BTCPはTCP接続により費やされる測定した平均帯域である
−B’TCPはTCP接続の所望の目標帯域である(=Btotal-Breal-time-stream)
−T’ACK=TACK+ΔACKは新たなTCP  ACKの到達時間間隔である。
以下のことが容易にわかる
TACKBTCP=(TACK+ΔACK)B’TCP            (1)
以下のことが導かれる。
【００４０】
ΔACK=(BTCP/B’TCP-1)TACK              (2)
しかし、新たなTCP  ACKの到達時間間隔は、TCP再送信タイムアウトのタイマ(一般的な値は200-250ms)を超過しない点に留意すべきである。そのTCP再送信タイムアウトのタイマは、通常はパケット再送信を起動し、無線帯域を浪費する。
【００４１】
TACKは、連続的なACKパケットの間の実行中の平均到達時間間隔を計算することで、アクセスポイントにより測定され得る。BTCPは、クライアントが生成しているトラヒック(このような統計は常にWLANハードウェアにより集められ、無線ネットワークドライバにより利用可能にされる)を測定することで、アクセスポイントにより容易に導き出され得る。目標TCP帯域B’TCPは、リアルタイムストリーミング接続に十分な帯域を開放するように計算されるべきである。この帯域は“goodput”に対応し、無線通信チャネル状態が考慮される必要があることを意味する点にも留意すべきである。実際に、送信パケットのエラーは再送信を生じ、そのためより多くの帯域が浪費され、このことが考慮されるべきである。アクセスポイントは接続クライアント毎に信号対雑音比を測定することができるため、無線チャネル状態についての情報を十分に認識している。
【００４２】
TCP  ACKパケットは最初にのみアクセスポイントのバッファに蓄積するため、提案のアルゴリズムは安定している。ラウンドトリップタイムに等しい期間の後に、TCPは自動的にその伝送レートを低くし、バッファが最終的にオーバーフローすることなく、TCP  ACKがより緩やかに生成される。
【００４３】
前述の方策は、無線ネットワークのクライアントにより生成されるトラヒックを低減する目的で、TCP  ACK遅延を計算する複数の可能性のある技術のうちの１つにしか過ぎない。例えば、複数の干渉するTCP接続の場合、TCP接続に専用の全体帯域が低減されるように、前述のアルゴリズムが適合され得る。接続毎に前述のアルゴリズムのインスタンスを動作してもよく(リソース消費になることがある)、単一の接続として全てのTCPフローを集めてもよい。
【００４４】
バーストのTCPトラヒックの場合、ACP  ACK到達頻度が所定の閾値を超えたときに常に、アルゴリズムを自動的に起動してもよい。換言すると、(2)で計算された遅延は、TCP  ACKがT’ACKより小さい間隔で到達したときのみ適用される。
【００４５】
同じ無線ネットワークのクライアントが相互に通信しようとするときに、アルゴリズムが有効になってもよい。例えば図１において、インフラモードで構成されたIEEE802.11bで、クライアント104がクライアント106とリアルタイムデータを交換しようとする場合、それはフレームをアクセスポイント103に送信し、そのフレームはブリッジによりクライアント106に転送される。このことは、トラヒックシェーパーがクライアントと間のトラヒックを傍受し、必要に応じて自由にそれを遅延させることができることを意味する。
【００４６】
この出願において、“有する”という用語は、他の要素又はステップを除外するものではない。また、先行詞は複数を除外するものでもない。
【図面の簡単な説明】
【００４７】
【図１】アクセスポイントと複数のクライアントとを備えた無線ネットワーク
【図２】サーバプロトコルスタックに本発明によるトラヒックシェーパーを配置した図
【図３】どのパケットを遅延するかを決定する手順を示したフローチャート
【図４Ａ】従来技術のシステムでのパケットフローの図
【図４Ｂ】本発明によるTCP  ACK信号の取り込まれた遅延の図
【図１】
2006511140.tif 000003
【図２】
2006511140.tif 000004
【図３】
2006511140.tif 000005
2006511140.tif 000006
【図４Ｂ】
2006511140.tif 000007
【国際調査報告】
2006511140.tif 000008
2006511140.tif 000009
2006511140.tif 000010