(57)【要約】ワイヤレスネットワークのどちらかのサイドに配置され、ワイヤレスネットワークにおける衝突の量を低減するシステムであって、システムは、クライアント確認応答を用いるＴＣＰプロトコルを用いてＴＣＰクライアントと通信しているＴＣＰサーバと、ＴＣＰプロトコルからの少なくとも１つのクライアント確認応答を要約確認応答に要約し、要約確認応答をワイヤレスネットワークに伝送するように構成された確認応答要約デバイスとを備える。確認応答要約デバイスは、ワイヤレスネットワークのどちらかのサイドに配置され、ＴＣＰプロトコルからの１又は複数のクライアント確認応答を符号化されたパケットに統合し、符号化されたパケットをワイヤレスネットワークに伝送するように構成された確認応答統合デバイスで、代替すること又はこれと組み合わせることができる。ＴＣＰサーバとＴＣＰクライアント間に配置されたデバイスは、ＴＣＰサーバとＴＣＰクライアント間を流れる１つの確認応答から１又は複数のクライアント確認応答を抽出し、抽出されたクライアント確認応答を全てネットワークへ伝送するように構成される。
2014509483.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークのどちらかのサイドに配置され、該ネットワークの帯域幅使用を低減するためのシステムであって、該システムは、
クライアント確認応答を用いるＴＣＰプロトコルを用いてＴＣＰクライアントと通信するＴＣＰサーバと、
前記ＴＣＰプロトコルからの少なくとも１つのクライアント確認応答を１つの要約確認応答に要約して、前記要約確認応答を前記ネットワークに伝送するように構成された確認応答要約デバイスと
を備えたシステム。
【請求項２】
請求項１記載のシステムであって、前記確認応答要約デバイスは、要約確認応答に要約することができるクライアント確認応答の数を制限するように構成された、システム。
【請求項３】
請求項１記載のシステムであって、前記ネットワークは、半二重ネットワークであり、確認応答の前記要約は前記半二重ネットワークにおいて衝突の数を低減する、システム。
【請求項４】
請求項３記載のシステムであって、前記半二重ネットワークは、パワーラインネットワークである、システム。
【請求項５】
請求項３記載のシステムであって、前記半二重ネットワークはワイヤレスネットワークである、システム。
【請求項６】
請求項１記載のシステムであって、前記確認応答要約デバイスは、前記ＴＣＰプロトコルからの複数のクライアント確認応答を要約するように構成された、システム。
【請求項７】
請求項１記載のシステムであって、前記確認応答要約デバイスは、前記要約確認応答を生成する前に、クライアント確認応答を特定の量の時間待つように構成された、システム。
【請求項８】
請求項２記載のシステムであって、前記確認応答要約デバイスは、前記要約確認応答を生成する前に、クライアント確認応答を特定の量の時間待つように構成された、システム。
【請求項９】
請求項２記載のシステムであって、前記確認応答要約デバイスは、前記制限を前記ワイヤレスネットワークのタイプ又は性能に基づいて調整できるように構成された、システム。
【請求項１０】
請求項７記載のシステムであって、前記確認応答要約デバイスは、前記特定の量の時間を、前記ワイヤレスネットワークのタイプ又性能に基づいて調整できるように構成された、システム。
【請求項１１】
請求項１記載のシステムであって、各クライアント確認応答はＩＰヘッダを含み、前記確認応答要約デバイスはＩＥＥＥ８０１．１１ｅを用いるＷｉ‐Ｆｉネットワークでどのように前記要約確認応答が搬送されるかに影響を及ぼすＴＯＳ／ＤＳＣＰを、確認応答の前記ＩＰヘッダに設定するように構成された、システム。
【請求項１２】
ネットワークにおいて衝突の量を低減するシステムであって、該システムは、
クライアント確認応答を含むＴＣＰプロトコルを用いてＴＣＰクライアントと通信するＴＣＰサーバと、
ワイヤレスネットワークのどちらかのサイドに配置されて、前記ＴＣＰプロトコルからの１又は複数のクライアント確認応答を符号化されたパケットに統合し、前記符号化されたパケットを前記ワイヤレスネットワークに伝送するように構成された確認応答統合デバイスと
を備えたシステム。
【請求項１３】
請求項１２記載のシステムであって、前記確認応答統合デバイスは、前記符号化されたパケットに統合できるクライアント確認応答の数を制限するように構成された、システム。
【請求項１４】
請求項１２記載のシステムであって、前記確認応答統合デバイスは、前記符号化されたパケットを生成する前に、クライアント確認応答を特定の量の時間待つように構成された、システム。
【請求項１５】
請求項１３記載のシステムであって、前記確認応答統合デバイスは、前記符号化されたパケットを生成する前に、クライアント確認応答を特定の量の時間待つように構成された、システム。
【請求項１６】
請求項１２記載のシステムであって、前記確認応答統合デバイスは、前記符号化されたパケットのＭＴＵがより下層のトランスポート技術の能力を超えないことを保証するように構成された、システム。
【請求項１７】
請求項１３記載のシステムであって、前記確認応答統合デバイスは、前記制限を、ネットワークタイプ、ネットワーク性能、又は信号伝達に基づいて調整できるように構成された、システム。
【請求項１８】
請求項１４記載のシステムであって、前記確認応答統合デバイスは、前記特定の量の時間を、ネットワークタイプ、ネットワーク性能、又は信号伝達に基づいて調整できるように構成された、システム。
【請求項１９】
請求項１２記載のシステムであって、各クライアント確認応答はＩＰヘッダを含み、前記確認応答統合デバイスは、ＩＥＥＥ８０１．１１ｅを用いるＷｉ‐Ｆｉネットワークでどのように前記符号化されたパケットが搬送されるかに影響を及ぼすＴＯＳ／ＤＳＣＰを、確認応答のＩＰヘッダに設定するように構成された、システム。
【請求項２０】
請求項７記載のデバイスであって、前記確認応答統合デバイスは、複数のＴＣＰサーバ及びＴＣＰクライアントからのワイヤレスネットワーク上を移動するＴＣＰ確認応答を統合するように構成された、システム。
【請求項２１】
ネットワークでＴＣＰ輻輳ウィンドウが開くレートを増大させるシステムであって、該システムは、
クライアント確認応答を用いるＴＣＰプロトコルを用いてＴＣＰクライアントと通信するＴＣＰサーバと、
前記ＴＣＰサーバと前記ＴＣＰクライアントとの間に配置され、前記ＴＣＰサーバと前記ＴＣＰクライアントとの間を伝わる１つの確認応答から１又は複数のクライアント確認応答を抽出し、抽出された前記クライアント確認応答全てを、前記ネットワークに伝送するように構成されたデバイスと
を備えたシステム。
【請求項２２】
請求項２１記載のシステムであって、前記デバイスは、クライアント確認応答の抽出を有効化及び無効化するためのデューティサイクルを定める、システム。
【請求項２３】
請求項２１記載のシステムであって、前記デバイスは、抽出することができる前記クライアント確認応答の数を制限する、システム。
【請求項２４】
請求項２１記載のシステムであって、前記デバイスは、抽出された各クライアント確認応答の最小セグメントサイズを保証する、システム。
【請求項２５】
請求項２１記載のシステムであって、前記デバイスは、ワイヤレスＬＡＮの性能を最適化し、なおかつＴＣＰ輻輳ウィンドウが開かれるレートを増大するようにワイヤレスネットワークで動作することができる、システム。
【請求項２６】
請求項２３記載のシステムであって、前記デバイスは、前記制限をネットワークタイプ、ネットワーク性能、又は信号伝達に基づいて調整できるように構成された、システム。
【請求項２７】
請求項２１記載のシステムであって、各クライアント確認応答はＩＰヘッダを含み、前記デバイスは、ＩＥＥＥ８０１．１１ｅを用いるＷｉ‐Ｆｉネットワークでどのように前記要約確認応答が搬送されるかに影響を及ぼすＴＯＳ／ＤＳＣＰを、確認応答のＩＰヘッダに設定するように構成された、システム。
【請求項２８】
ネットワークの帯域幅使用を低減するための方法であって、該方法は、
クライアント確認応答を用いるＴＣＰプロトコルを用いてＴＣＰサーバとＴＣＰクライアントとの間のトラフィックをインターセプトするステップと、
前記ＴＣＰプロトコルからのクライアント確認応答を識別するステップと、
少なくとも１つのＴＣＰ確認応答を１つの要約確認応答に要約するステップと、
前記要約確認応答を前記ネットワークに伝送するステップと
を含む、方法。
【請求項２９】
請求項２８記載の方法であって、要約確認応答に要約できるクライアント確認応答の数を制限するステップを含む、方法。
【請求項３０】
請求項２８記載の方法であって、前記要約確認応答を生成する前にクライアント確認応答を特定の量の時間待つステップを含む、方法。
【請求項３１】
ネットワークの帯域幅使用を低減する方法であって、該方法は、
通信しているＴＣＰサーバとＴＣＰクライアントとの間のトラフィックをインターセプトするステップと、
前記ＴＣＰプロトコルからの確認応答を識別するステップと、
前記ＴＣＰプロトコルからの１又は複数の確認応答を１つの符号化されたパケットに統合するステップと、
前記符号化されたパケットを前記ネットワークに伝送するステップと
を含む、方法。
【請求項３２】
請求項３１記載の方法であって、前記符号化されたパケットに統合できるＴＣＰ確認応答の数を制限するステップを含む、方法。
【請求項３３】
請求項３１記載の方法であって、前記符号化されたパケットを生成する前に、ＴＣＰ確認応答を特定の量の時間待つステップを含む、方法。
【請求項３４】
請求項３１記載の方法であって、前記ネットワーク上を移動する、複数のＴＣＰサーバとＴＣＰクライアントからのＴＣＰ確認応答を統合するステップを含む、方法。
【請求項３５】
ネットワークでＴＣＰ輻輳ウィンドウが開くレートを増大する方法であって、該方法は、
クライアント確認応答を用いるＴＣＰプロトコルを用いて通信しているＴＣＰサーバとＴＣＰクライアントの間のトラフィックをインターセプトするステップと、
前記ＴＣＰプロトコルからのクライアント確認応答を識別するステップと、
前記ＩＰサーバと前記ＩＰクライアントとの間を伝わる１つの確認応答からＴＣＰプロトコルからの１又は複数のクライアント確認応答を抽出するステップと、
抽出された前記クライアント確認応答全てを、前記ネットワークに伝送するステップと
を含む方法。
【請求項３６】
請求項３５記載の方法であって、クライアント確認応答の前記抽出を有効化及び無効化するためのデューティサイクルを定めるステップを含む方法。
【請求項３７】
請求項３５記載の方法であって、抽出することができるクライアント確認応答の数を制限するステップを含む方法。
【請求項３８】
請求項３５記載の方法であって、抽出された各クライアント確認応答の最小セグメントサイズを保証するステップを含む方法。
【請求項３９】
請求項３５記載の方法であって、ワイヤレスＬＡＮの性能を最適化し、なおかつＴＣＰ輻輳ウィンドウが開かれるレートを増大するようにワイヤレスネットワークで動作することを可能にするステップを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
[0001]本発明は通信データネットワークに関する。より詳細には、本発明はネットワークの末端部から見たネットワークを介するデータ伝送のスループットを増大させるためのシステム及び方法に関する。
【背景技術】
【０００２】
[0002]トランスミッション・コントロール・プロトコル（ＴＣＰ）は、インターネットプロトコル群のコアプロトコルの１つである。ＴＣＰは、あるコンピュータアプリケーションから別のコンピュータアプリケーションへ、高い信頼性及び正しい順序でバイトのストリームを配信することを提供し、ウェブトラフィック、メール、及びファイル転送等の多くの基本的なインターネットアプリケーションにトランスポート層を提供する。ＴＣＰは有線伝送に最適化されていた。したがって、パケット損失はネットワークが輻輳した結果であるという前提で、ＴＣＰはパケット損失によりトリガされる輻輳に対処できるようにした多数の機構を持っている。これら機構が、誤ってワイヤレスネットワーキングのシナリオに適用される場合がある。パケット損失は、干渉やシェーディング等なんらかの散発的なイベントにより生じた可能性が高い。トランスポートにＴＣＰを活用しているコンピュータアプリケーションがワイヤレスネットワークにおいてパケット損失を受ける場合、実は輻輳制御機構がネットワークの不十分な利用を招いている。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
[0003]上述した基本的な問題に加え、いくつかのネットワークにはさらなる課題がある。いくつかのネットワークは帯域幅に制約がある場合があり、帯域幅の使用を最小限にする必要がある。いくつかのネットワーク、例えばパワーライン、ワイヤレス、又はＷＩＦＩ、は半二重であり、各端が同じ周波数を用いて伝送及び受信をおこなう。この場合、半二重ネットワークの各メンバが別の端局と衝突することなく伝送できることを保証するためには、ハンドシェイク又は他のバックオフ／コンテンション機構が必要である。これらの衝突回避機構は大きなパケットサイズに最適化されるのが通常であり、大きなパケットサイズが機構のリトライタイマ及びバックオフタイマの設定に影響を及ぼす。これがＴＣＰ確認応答（ＡＣＫ）パケットには特に問題であり、そしてＡＣＫパケットは、あるコンピュータアプリケーションによって、別のコンピュータアプリケーションからデータを受けているときに頻繁に送出される。制約のあるネットワークがこのデータストリームの経路にあると、衝突回避のハンドシェイクは頻繁にデータが確認応答されるときに起動する。ＴＣＰ  ＡＣＫは小さいので、衝突回避プロトコルの前提に反し、不十分な利用をさらに招いている。
【課題を解決するための手段】
【０００４】
[0004]一実施形態では、制約のあるネットワークのどちらかのサイドに配置されてこのネットワークの帯域幅及び衝突の一方又は双方の量を低減するためのシステムは、クライアント確認応答を用いるＴＣＰプロトコルを用いてＴＣＰクライアントと通信しているＴＣＰサーバと、ＴＣＰプロトコルからの少なくとも１つのクライアント確認応答を要約確認応答に要約して、要約確認応答をワイヤレスネットワークに伝送するように構成された確認応答要約デバイスとを備えている。
【０００５】
[0005]一実装では、確認応答要約デバイスサーバは、要約確認応答に要約することができるクライアント確認応答の数を制限すること、及び要約確認応答を生成する前にクライアント確認応答を特定の量の時間待つことの一方又は双方を行うように構成される。確認応答要約デバイスは、この制限及び特定の量の時間の一方又は双方を、ワイヤレスネットワークのタイプ又は性能に基づいて調整できるように構成することができる。確認応答要約デバイスは、ＩＥＥＥ８０１．１１ｅを用いるＷｉ‐Ｆｉネットワークでどのように要約確認応答が搬送されるかに影響を及ぼすＴＯＳ／ＤＳＣＰを、確認応答のＩＰヘッダに設定するように構成されてもよい。
【０００６】
[0006]第２の実施形態では、ワイヤレスネットワークにおいて衝突の量を低減するシステムは、クライアント確認応答を含むＴＣＰプロトコルを用いてＴＣＰクライアントと通信しているＴＣＰサーバと、ワイヤレスネットワークのどちらかのサイドに配置されて、ＴＣＰプロトコルからの１又は複数のクライアント確認応答を符号化されたパケットに統合し、符号化されたパケットをワイヤレスネットワークに伝送するように構成された確認応答統合デバイスとを備える。
【０００７】
[0007]第２の実施形態の一実装では、確認応答統合デバイスは、符号化されたパケットに統合することができるクライアント確認応答の数を制限すること、及び符号化されたパケットを生成する前にクライアント確認応答を特定の量の時間待つことの一方又は双方を行うように構成される。確認応答統合デバイスは、符号化されたパケットを生成する前に、クライアント確認応答を特定の量の時間待つこと、及び符号化されたパケットのＭＴＵがより下層のトランスポート技術の能力を超えないよう保証することの一方又は双方を行うように構成することができる。確認応答統合デバイスはさらに、この制限をワイヤレスネットワークタイプ、ネットワーク性能、又は信号伝達に基づいて調整すること、及びこの特定の量の時間をワイヤレスネットワークタイプ、ネットワーク性能、又は信号伝達に基づいて調整することの一方又は双方ができるように構成されてもよい。
【０００８】
[0008]第２の実施形態の変形では、確認応答統合デバイスは、ＩＥＥＥ８０１．１１ｅを用いるＷｉ‐Ｆｉネットワークでどのように符号化されたパケットが搬送されるかに影響を及ぼすＴＯＳ／ＤＳＣＰを、確認応答のＩＰヘッダに設定するように構成されてもよい。確認応答統合デバイスはさらに、複数のＴＣＰサーバ及びＴＣＰクライアントからのワイヤレスネットワーク上を移動するＴＣＰ確認応答を統合するように構成されてもよい。
【０００９】
[0009]第３の実施形態では、ネットワークでＴＣＰ輻輳ウィンドウが開くレートを増大させるシステムは、クライアント確認応答を用いるＴＣＰプロトコルを用いてＴＣＰクライアントと通信しているＴＣＰサーバと、ＴＣＰサーバとＴＣＰクライアントとの間に配置され、ＴＣＰサーバとＴＣＰクライアントとの間を流れる１つの確認応答から１又は複数のクライアント確認応答を抽出し、抽出された前記クライアント確認応答全てをネットワークに伝送するように構成されたデバイスを備えている。
【００１０】
[0010]別の実施では、デバイスはクライアント確認応答の抽出を有効化及び無効化するためのデューティサイクルを定めること、抽出することができるクライアント確認応答の数を制限すること、抽出された各クライアント確認応答の最小セグメントサイズを保証すること、及びワイヤレスＬＡＮの性能を最適化してなおかつＴＣＰ輻輳ウィンドウが開かれるレートを増大するようにワイヤレスネットワークで動作することの１つ以上を行うことができる。デバイスはさらに、この制限をワイヤレスネットワークのタイプ、ネットワーク性能、又は信号伝達に基づいて調整すること、及びＩＥＥＥ８０１．１１ｅを用いるＷｉ‐Ｆｉネットワークでどのように要約確認応答が搬送されるかに影響を及ぼすＴＯＳ／ＤＳＣＰを、確認応答のＩＰヘッダに設定することの一方又は双方ができるように構成されてもよい。
【００１１】
[0011]本発明の実施形態を添付の図面を参照してここに説明するが、これは例示にすぎない。
【図面の簡単な説明】
【００１２】
【図１】クライアントとサーバとがＴＣＰを用いたネットワークを介して通信するシステムの概略図である。
【図２】図１のシステムのクライアント及びサーバ間のＴＣＰセグメント及びＴＣＰ  ＡＣＫの交換を示す図である。
【図３】図１のシステムの修正であってワイヤレスネットワーク要素を含むものの概略図である。
【図４】図３のシステムで伝送されたワイヤレス衝突回避メッセージの図である。
【図５】図３のシステムの修正であって、インターセプティングネットワークデバイスを含むものの概略図である。
【図６】図５のシステムで用いられるインターセプティングネットワークデバイスの構成要素を示すブロック図である。
【図７】ＴＣＰ接続からのＡＣＫを１つのＡＣＫパケットに統合しているインターセプティングネットワークデバイスの概略図である。
【図８】ＴＣＰ  ＡＣＫを１つのＡＣＫパケットに統合することを実施するステートマシンの図である。
【図９】図８に示したアイドル状態の状態エントリロジックのフロー図である。
【図１０】図８に示したアイドル状態のイベント処理コードのフロー図である。
【図１１】図８に示したＡＣＫペンディング状態の状態エントリロジックのフロー図である。
【図１２】図８に示したＡＣＫペンディング状態のイベント処理コードのフロー図である。
【図１３】図８に示したＡＣＫ送信状態の状態エントリロジックのフロー図である。
【図１４】インターセプティングネットワークデバイスエンコーダによる選択的なＡＣＫパケットの処理を示す図である。
【図１５】インターセプティングネットワークデバイスによる、ＴＣＰ接続からの複数のＡＣＫの１つのパケットへの符号化を示す図である。
【図１６】インターセプティングネットワークデバイスによる、ＴＣＰ接続からの複数のＡＣＫの１つのパケットへの復号化を示す図である。
【図１７】ＴＣＰ接続からの複数のＴＣＰ  ＡＣＫを１つのパケットに符号化するステートマシンを示す図である。
【図１８】図１７に示したＡＣＫペンディング状態の状態エントリロジックのフロー図である。
【図１９】図１７に示したＡＣＫペンディング状態のイベント処理ロジックのフロー図である。
【図２０】図１７に示したＡＣＫ送信状態の状態エントリロジックのフロー図である。
【図２１】図５のシステムの修正であって、ＩＮＤ７０を使用する複数のクライアントを含むものの図である。
【図２２】複数のＴＣＰ接続の符号化アルゴリズムであって、１つの接続からのＴＣＰ  ＡＣＫの統合と組み合されたものを示す図である。
【図２３】１つのＴＣＰ  ＡＣＫを複数のＡＣＫに分割するためのＩＮＤエンコーダのアルゴリズムを示すフロー図である。
【図２４】ＴＣＰ  ＡＣＫを複数のＴＣＰ  ＡＣＫに分割するための機構のフロー図である。
【図２５】図２４のフロー図の続きである。
【図２６】図５のネットワークを用いて１つのＴＣＰ  ＡＣＫを複数のＡＣＫへ分割するための符号化アルゴリズムを示す図である。
【発明を実施するための形態】
【００１３】
[0038]本発明は好適な特定の実施形態に関連して説明するが、本発明がこれらの特定の実施形態に限定されるわけではない。それどころか、本発明は添付の請求項によって規定される発明の精神及び範囲内に含まれ得る代替形態、修正形態、及び同等の構成をすべて包含するものである。本発明はワイヤレスネットワークに即して説明するが、任意の帯域幅制限ネットワーク又は半二重ネットワークに適用されることがわかるであろう。
【００１４】
[0039]トランスミッション・コントロール・プロトコル（ＴＣＰ）はコアインターネットプロトコルの１つであり、あるコンピュータアプリケーションから別のコンピュータアプリケーションへ、高い信頼性及び正しい順序でバイトのストリームを配信することを提供する。図１は、ＴＣＰ動作に係るネットワーク要素を示す。第１の要素はＴＣＰサーバ１０であり、これは部分的に開いたＴＣＰポートをリッスンするデバイスであることを特徴とする。サーバは、ＴＣＰクライアント等の他のネットワーク要素がこの開いているＴＣＰポートを使用してサーバとやりとりするまで、このポートで待機する。ＴＣＰクライアントはデバイスと定められ、このデバイスは、サーバ１０による信頼性が高く順序の正しいバイトのストリームの配信を必要とする。クライアント３０はサーバ１０との接続を開始し、この接続はサーバ１０のＩＰアドレス及びＴＣＰポート番号とクライアント３０のＩＰアドレス及びＴＣＰポート番号との組み合わせにより一意に識別される。接続が確立されると、信頼性の高いデータフローが両方向に提供される。実際に用いられる方向は、サーバ１０及びクライアント３０上のコンピュータアプリケーションにより決められる。ウェブトラフィックの場合は、フローはサーバからクライアントへ向かうことが通常である。ファイル転送プロトコル（ＦＴＰ）では、いずれの方向の転送も可能である。クライアント３０は、サーバ１０からファイルを受けること、又はファイルをサーバ１０に置くことができる。
【００１５】
[0040]ネットワーク２０の属性は意図的に曖昧になっている。唯一の要件は、サーバ１０とクライアント３０との間でＴＣＰが機能できるよう保証することである。これは、クライアント３０がサーバ１０のＩＰアドレスを求めることができること、及びクライアント３０がサーバ１０のどのＴＣＰポートがクライアントのアプリケーションに対して開いているかを知っているということを意味する。そうであるならば、ネットワーク２０はサーバ１０とクライアント３０との間にＩＰ接続を提供する必要がある。
【００１６】
[0041]図２では、サーバ１０のアプリケーションがクライアント１０のアプリケーションにバイトのフローを送出している。このフローは、サーバにメッセージ２００でレシーブウィンドウサイズ３５００バイトをアドバタイズするクライアントから始まる。このメッセージは、ＴＣＰにより提供されるフロー制御機構の一部であり、クライアント３０がサーバ１０からのデータで溢れかえっていないことを保証するものである。メッセージ２００がサーバ１０に到着するとき、３つのＴＣＰセグメント（メッセージ２１０から２１２）がクライアント３０に送られて、クライアント３０の開いているレシーブウィンドウを埋める。サーバ１０からの信頼性の高いデータ転送を提供するために、クライアント３０は、ＴＣＰ  ＡＣＫメッセージを用いてデータの到着を確認応答する。サーバからのバイトの全てがナンバリングされて、これら追加のバイトがＡＣＫメッセージでシーケンス番号を用いて確認応答される。この場合、クライアント３０は３つのＴＣＰ  ＡＣＫメッセージ２２０から２２２を作成する。これらのメッセージが、この特許書類に述べる機構の焦点である。
【００１７】
[0042]ＴＣＰ  ＡＣＫメッセージが問題になるのは、信頼性の高いデータ転送を保証するために衝突回避機構を必要とする半二重ワイヤレスネットワークにおいてである。図３及び４は、これらの機構がどのようにＴＣＰ接続に影響するかを示す。図３のシステムは、サーバ１０とクライアント３０との間の経路にワイヤレスＬＡＮを追加している。ワイヤレスクライアント５０は、その有線側にあってクライアント３０を含むネットワークデバイスの代わりに、ワイヤレスＬＡＮへのアクセスを提供する。ワイヤレスアクセスポイント（ＡＰ）４０は多数のワイヤレスクライアント（ワイヤレスクライアント５０を含む）をネットワーク２０へ接続する。多数のワイヤレスクライアントが存在するならば、各ワイヤレスクライアントがワイヤレスＬＡＮ上で公平なサービスを提供されることを保証するために、衝突回避プロトコルが必要である。図４は、このプロトコルがどのように動作できるかの例を示すものであり、Ｗｉ‐Ｆｉ，ＩＥＥＥ８０２．１１の例示的実装を活用している。この図では、図２のメッセージ２２０がクライアント３０からサーバ１０へ移動しており、ワイヤレスＬＡＮでワイヤレスＡＰ４０とワイヤレスクライアント５０との間を横断している。ワイヤレスクライアント５０は、メッセージ２２０でＴＣＰ  ＡＣＫを受けるとき、「送信要求（Ｒｅａｄｙ  ｔｏ  Ｓｅｎｄ）」の状態にあることを、メッセージ４００を用いて知らせる。この要求が有効であるという前提であれば、ワイヤレスＡＰ４０は「送信可（Ｃｌｅａｒ  ｔｏ  Ｓｅｎｄ）」の表示を、メッセージ４０１を用いてワイヤレスクライアント５０に送り、このメッセージ４０１により、ワイヤレスクライアント５０はメッセージ４０２でＴＣＰ  ＡＣＫの送信を開始できる。ワイヤレスＡＰ４０は、ＴＣＰ  ＡＣＫを受けるとき、メッセージ４０３でワイヤレス確認応答フレームを送る。この時点で、ＴＣＰ  ＡＣＫは、ネットワーク２０を介してサーバ１０へ進む。
【００１８】
[0043]図４ではワイヤレスクライアントはすぐにＴＣＰ  ＡＣＫメッセージ４０２を送ることができており、上手くいったやりとりを示している。多くの場合、ワイヤレスクライアント５０はメッセージ４０２を送るのを待たねばならない。例えば、メッセージ２２０がワイヤレスクライアント５０に到着したとき、別のワイヤレスクライアントがすでに送っていた可能性がある。ワイヤレスクライアント５０は、この別のワイヤレスクライアントによって最大転送単位（ＭＴＵ）長が送られるまで待つ必要があるが、この別のワイヤレスクライアントは、ＭＴＵよりも小さなパケットを送っている場合や、ワイヤレスクライアント５０がＴＣＰ  ＡＣＫメッセージ２２０を受けたときにはすでに送り始めていた場合がある。いずれの場合でも、ワイヤレスＬＡＮへのアクセスがワイヤレスクライアントによりネゴシエーションされている間、ネットワークの利用は悪くなる。ワイヤレスクライアント５０とワイヤレスＡＰ４０との間のワイヤレスＬＡＮが、クライアント３０とサーバ１０との間の経路にある唯一のワイヤレスリンク上にあるとは限らない。この経路に複数の半二重ワイヤレスリンクがあれば、ネットワークの利用はさらに悪化することになる。
【００１９】
[0044]この状況において、ネットワークの利用を改善するために、ワイヤレスＬＡＮを挟んでいる経路にインターセプティングネットワークデバイス（ＩＮＤ）を追加することができる。図５のシステムは、クライアント３０とサーバ１０との間の経路上にＩＮＤを含んでいる。ＩＮＤ７０は、クライアント３０とワイヤレスクライアント５０との間に配置されて、ワイヤレスＡＰ４０へ向かうパケットのネットワークの利用を改善する機能を提供する。ネットワーク２０とワイヤレスＡＰ４０との間にある第２のＩＮＤ６０は、ワイヤレスクライアント５０等のワイヤレスクライアントへ向かうネットワークの利用を改善する機能を提供する。
【００２０】
[0045]図６はＩＮＤの図５に示した例示的な実施形態を示す。図６では、ＩＮＤ７０を、ワイヤレスネットワークの性能を改善するための符号化プロトコルを実施するのに必要なモジュールに分解している。これらモジュールは、１つのデバイスに常駐すること、又はいくつかのデバイスに分散することができる。図６から分かるように、ＩＮＤ７０はネイティブインターフェース６００、エンコーデッドインターフェース６２０、デコーダ６３０及びエンコーダ６１０を有する。ネイティブインターフェース６００は、標準的なパケットをクライアント３０に対して送受信する。エンコーデッドインターフェース６２０は、符号化されたパケットをワイヤレスクライアント５０に対して送受信する。
【００２１】
[0046]デコーダ６３０は、符号化されたパケットをエンコーデッドインターフェース６２０から受けて標準的なパケットを作り、ネイティブインターフェース６００を経由してクライアント３０へ伝送できるようにする。一方でエンコーダ６１０は、標準的なパケットをネイティブインターフェース６００から受けて符号化されたパケットを作り、エンコーデッドインターフェース６２０を経由してワイヤレスクライアント５０へ伝送できるようにする。エンコーダ及びデコーダにより用いられる特定のアルゴリズムはオプションでありプログラム可能である。いくつかの実施形態を以下に述べる。
【００２２】
[0047]一実施形態では、ＩＮＤ６０及びＩＮＤ７０は、ＴＣＰ接続からのＡＣＫをバッファし、その情報を、接続のための１つのＡＣＫメッセージに要約する。ＴＣＰメッセージ内のＡＣＫ情報は累積的であるため、アルゴリズムは非常に単純になり得る。図７は、この動作が、図２に示したパケットシーケンスではどのように達成されるかを明示すものである。この例では、クライアント３０から送られた３つのＡＣＫ（メッセージ２２０から２２２）はＩＮＤ７０でバッファされる。３つのＡＣＫの中の情報が１つのＡＣＫに要約され、それは次にメッセージ７０１でワイヤレスクライアント５０に送られる。それから、ワイヤレスクライアント５０が、このＡＣＫをワイヤレスＬＡＮで伝送するためにワイヤレスアクセスポイント４０とネゴシエーションを行う。メッセージ７１０から７１３に含まれているこのネゴシエーションは、図４に示したフローと同じである。次に、メッセージ７１４を用いて、ＴＣＰ  ＡＣＫがネットワーク２０に転送される。このフローは、このアルゴリズムによって提供される重要な最適化を明示している。衝突回避のネゴシエーションの回数は３から１に減り、それによりオーバーヘッドメッセージングが減り、結果としてスループットがより高くなる。
【００２３】
[0048]図７は、クライアント３０がファイルをサーバ１０からダウンロードしていることを前提としており、これはウェブトラフィック等多くのコンピュータアプリケーションにとって有効な前提である。しかし、クライアントはＴＣＰを用いてデータをサーバにアップロードする場合もある。例えば、クライアント１０は、写真をバックアップ又は共有するために、ＦＴＰを用いてウェブサーバへアップロードすることがある。この場合、図５に示したＩＮＤ６０は、ＩＮＤ７０と同じ機能を行うことができるが、反対方向に行う。ＩＮＤ６０のためのエンコーデッドインターフェースはワイヤレスＡＰ４０へ接続され、そのネイティブインターフェースはネットワーク２０へ接続される。そうするとＩＮＤ６０は、ワイヤレスＡＰ４０とワイヤレスクライアント５０との間のワイヤレスＬＡＮの利用を改善するために、サーバ１０からクライアント３０へ流れるＴＣＰ  ＡＣＫを要約することができる。
【００２４】
[0049]接続のＴＣＰ  ＡＣＫを要約するために、ＩＮＤ（６０及び７０）のエンコーダは各ＴＣＰ接続のためのステートマシンを実装する。このステートマシンの実施形態が図８に示されており、これは３つの状態を含んでいる。アイドル状態８００は、ＩＮＤにこのＴＣＰ接続について処理すべきＡＣＫがない時間を処理するために用いられる。ＡＣＫペンディング状態では、ＩＮＤは１つ（イベント８１０）又は２つ以上（イベント８１１）のＡＣＫを受けたが、伝送のＡＣＫを要約する条件が達成されていない。十分な時間が過ぎるか、又はＡＣＫが閾値の数に達する（これをＭＡＸ  ＡＣＫと定める）と、ステートマシンはＡＣＫ送信状態８０２に遷移してＡＣＫを送る。これは一時的な状態であり、ＡＣＫの伝送が完了すると、ステートマシンはアイドル状態８００へ遷移する。
【００２５】
[0050]図９及び１０にアイドル状態８００の詳細な処理を示す。図９は、アイドル状態８００の状態エントリ機能を提供している。単純にステートマシンの現在の状態をアイドル状態と設定する（９０１）。図１０は、アイドル状態８００で処理するイベントのためのアルゴリズムのフロー図である。アルゴリズムは、ステップ１００１において、どのタイプのイベントを受けたかを判定することで開始する。イベントがこの接続のために受けたＡＣＫであれば、ステップ１００２でステートマシンはＡＣＫペンディング状態８０１へ遷移する。そうでなければ、予期せぬイベントを受けてステップ１００３でエラーイベントが生成される。
【００２６】
[0051]図１１及び図１２にＡＣＫペンディング状態８０１の詳細な処理を示す。図１１は、ＡＣＫペンディング状態８０１の状態エントリ機能を提供している。ステップ１１０１で現在の状態をＡＣＫペンディング状態８０１に設定し、ステップ１１０２で、受けたＡＣＫの現在のカウントを１に設定し、ステップ１１０３でＡＣＫタイマを開始する。図１２は、ＡＣＫペンディング状態８０１で処理するイベントのためのアルゴリズムのフロー図である。アルゴリズムは、ステップ１２０１において、どのタイプのイベントを受けたかを判定することで開始する。イベントがこの接続のために受けたＡＣＫであれば、ステップ１２０２で受けたＡＣＫの現在のカウントが１つ増やされてステップ１２０３でＭＡＸ  ＡＣＫと比較される。ＭＡＸ  ＡＣＫに到達していれば、ステートマシンはステップ１２０４でＡＣＫ送信状態８０２へ遷移する。タイマ終了イベントを受けた場合、ステートマシンはステップ１２０４でＡＣＫ送信状態８０２へ遷移する。そうでなければ、予期せぬイベントを受けてステップ１２０４でエラーイベントが生成される。
【００２７】
[0052]図１３は、ＡＣＫ送信状態８０２で行われる機能を示す。ステートマシンがこの状態に到達すると、受けた全てのＡＣＫが１つのＡＣＫに要約される。パケット損失が１つもなければ、受けた最後のシーケンス番号が要約されたＡＣＫに置かれる。次にステップ１３０３で、要約されたＡＣＫが伝送のために待ち行列に入れられ、ステートマシンはアイドル状態８００へ遷移する。
【００２８】
[0053]ＡＣＫが要約されるとき、ＩＮＤ（６０又は７０）は、選択的なＡＣＫ（又はＳＡＣＫ）を処理する必要がある場合がある。このオプションはＲＦＣ２０１８に定められており、レシーバが、基本的なＴＣＰ確認応答と同じく最後に首尾よく受けた連続するバイトのシーケンス番号について確認応答をすることに加え、正しく受けたパケットの不連続ブロックについても確認応答できるようにするものである。確認応答は、ＳＡＣＫブロックの数を特定することができ、各ＳＡＣＫブロックは、レシーバが正しく受けた連続する範囲の開始及び終了シーケンス番号によって伝えられる。図１４は、エンコーダがどのようにＳＡＣＫを処理することができるかを明示するものである。第１のＡＣＫ１４００は、シーケンス番号４０００及びＳＡＣＫブロック８５００から１００００を持ってクライアント３０から到着する。これは前方へ転送されるＡＣＫの基準として記憶される。第２のＡＣＫ１４１０は、５５００から７０００の選択的なＡＣＫブロックを持って到着する。第３のＡＣＫ１４２０はＳＡＣＫブロックのシーケンス番号７０００を持って到着し、これが４０００と５５００の間の穴を埋める。この時点で、エンコーダ６１０は、シーケンス番号７０００及びＳＡＣＫブロック８５００から１００００を有する要約されたＴＣＰ  ＡＣＫを送る準備が整う。
【００２９】
[0054]結果として得られるＩＮＤ６０及びＩＮＤ７０により作成された符号化されたパケットは、標準的なＴＣＰ/ＩＰパケットである。したがって、パケットを復号する必要がなく、ＩＮＤ（６０及び７０）のデコーダ機能はヌル（ＮＵＬＬ）である。ＩＮＤ６０又はＩＮＤ７０のエンコーデッドインターフェースに到着した要約されたＴＣＰ  ＡＣＫはそのまま通過することができる。その上、ＩＮＤ間に接続を形成するために明示的な信号伝達を行う必要もない。ＩＮＤは独立してワイヤレスＬＡＮ上のネットワーク性能の改善を進める。
【００３０】
[0055]このアルゴリズムの実装は、図５に似た配置を活用したネットワーク利用の改善を測定するために用いられた。違いは、サーバ１０がＩＮＤ６０に直接的に有線接続されていたことだけである。すなわち、ネットワーク２０は物理的なワイヤとして実装された。それからサーバ３０を用いてＴＣＰフローが生成され、ワイヤレスＬＡＮ上で性能が測定された。フローはまず無効状態のＩＮＤでテストされ、それから有効状態であってＭＡＸ  ＡＣＫが２と等しいＩＮＤでテストされた。結果として得られたネットワーク利用の改善を以下の表に示す。
【００３１】
【表１】
2014509483.tif 000003
【００３２】
[0056]ＩＮＤの代替的な実装は、ＴＣＰ  ＡＣＫパケットを上述したように要約する代わりに統合する方法を用いる。図１５は、これら統合パケットがどのようにして１つのＴＣＰ接続における複数のＴＣＰ  ＡＣＫから集められるのかを示す。ステップ１５００は、次に生成される統合ＴＣＰパケットのヘッダ１５０１‐Ｈを保持する初期バッファを示している。このヘッダは、パケットをＩＮＤ６０とＩＮＤ７０との間でルーティングするためのアドレス指定を含む。ヘッダはさらに、このペアリングに関連付けされたＴＣＰ接続についての情報も含む。これにより、デコーダは中にあるものが何かを知ることができ、統合パケットを元の構成要素に分解することができる。ステップ１５１０で、ＴＣＰ  ＡＣＫ全体が統合パケットヘッダの直後のパケットにコピーされる。これは２つのパートで完了する。第１に、ヘッダ１５１１‐Ｈを追加して、ＴＣＰ  ＡＣＫの始まりとして識別できるようにするにする。このヘッダは、パケットのコンテンツ及び長さを識別するマーカを含むことができる。第２に、ＴＣＰ  ＡＣＫパケット（１５１１‐Ｐ）がコピーされる。このプロセスは、ステップ１５２０で、ＡＣＫ及びパケット１５２１‐Ｐを識別する別のヘッダ１５２１‐Ｈを追加することにより繰り返される。パケットは、送ってもよい状態になると、ＩＮＤを同期状態に保つための関連情報、又は統合パケット自体に含まれたＴＣＰ  ＡＣＫについて直接関係のある情報を搬送するために、オプションのトレーラ１５３１‐Ｔを含むことができる。このスキームは、複数のＴＣＰ  ＡＣＫを１つのパケットにパッケージ化するのに用いることができる多数のスキームのうちの１つである。別のオプションは、全てのＡＣＫを、マーカを含む統合パケットヘッダと連続させて置いて、パケットを分割できるようにするものである。鍵はＴＣＰ  ＡＣＫの統合である。
【００３３】
[0057]図１６は、ワイヤレスＬＡＮの他端でどのようにしてデコーダによって統合パケットが分解されるかを明示している。ステップ１６００で元のパケットを受けて、それからステップ１６１０でヘッダ及びトレーラが除去される。次にステップ１６２０で、個々のＡＣＫヘッダ１１０１‐Ｈ及び１１２１‐Ｈを用いて個々のＴＣＰ  ＡＣＫが識別される。これが完了すると、ステップ１６３０で、パケットは退出の待ち行列に入れられる。
【００３４】
[0058]接続の１つの端のエンコーダ及び接続の他端のデコーダには機能性が必要とされるので、ＩＮＤ５０及びＩＮＤ６０は、統合機能を提供するためには互いの関連性を生み出さねばならない。この関連性は、２０１０年３月５日に出願された同時係属出願である米国出願番号第１２／７１８，６５０号に記載されたような信号伝達機構を用いて生み出すことができ、参照によって本出願に援用される。唯一の違いは、信号伝達されている機構である。ネットワークの信頼性を改善するためにセッションを信号伝達するのではなく、ＴＣＰ  ＡＣＫの統合セッションを信号伝達している。
【００３５】
[0059]図１７に示すようなステートマシンは、パケットを統合するためのエンコーダ機能を実装している。このステートマシンは、図８で定めたものと同じ状態を活用するが、処理する状態及び遷移は異なる。アイドル状態１７００のプロセスは図８と同一であり、図９及び図１０に示されている。ＡＣＫペンディング状態１７０１の処理は異なっており、そのエントリ機能が図１８に示されている。ＴＣＰ  ＡＣＫを受けるとき、ステップ１８０１で、エンコーダは関連するＴＣＰ接続についてＡＣＫペンディング状態をエントリする。ステップ１８０２で、ＡＣＫ  ＣＯＵＮＴは１に設定され、ステップ１８０３で、エンコーダはヘッダを追加することにより、ＡＣＫのための統合されたＡＣＫバッファを準備する。次にステップ１８０４で、ＡＣＫがバッファに追加される。図１５で説明したようにして、ヘッダがＴＣＰ  ＡＣＫパケットの前に追加され、ＴＣＰ  ＡＣＫがフレームに追加される。この具体的なステップは、アルゴリズムのパッケージ化によって変わる。この時点で、ステップ１８０５で最終的なパケットサイズが算出され、ステップ１８０６でＡＣＫタイマが開始される。
【００３６】
[0060]後続のＡＣＫがＡＣＫペンディング状態１７０２にあるステートマシンによってどのように処理されるかを図１９に示す。状態処理機能は、ステップ１９０１で、どのイベントが扱われているかを判定することから開始する。ＡＣＫを受けると、ステートマシンはステップ１９０２でＡＣＫ  ＣＯＵＮＴを１つ増やし、ステップ１９０３でＡＣＫをバッファへ追加する。これは図１５のところで述べたものと同じ手順に従う。次にステップ１９０４で、現在の統合パケットの最終サイズが求められて、ステップ１９０５で、このＩＮＤ間のＴＣＰ関連性について、許容されるＭＴＵ（ＭＡＸ）との比較が行われる。このＭＴＵは、統合パケットの伝送に用いられた特定のインターフェースのためのＭＴＵとともにＴＣＰ接続のポリシの一部として提供されること、信号伝達の一部としてネゴシエーションされること、又は経路ＭＴＵ発見プロセスの一部として発見されることができる。統合されたパケットが許容されるＭＴＵを超えると、ステートマシンはＡＣＫ送信状態１７０１へ進み、そうでなければ、ステートマシンはスリープに戻って次のイベントを待つ。別の有効なイベントはタイマの終了である。このタイマの長さは、ＩＮＤエンコーダが後続のＡＣＫを十分な時間待ったこと及びパケットを送らねばならないことを意味している。このタイマの持続時間は、この接続からスヌープした全てのパケットの往復時間から推定すること、又はＩＮＤのＴＣＰ関連性の構築の一部として信号伝達することで、提供されることができる。このイベントを受けた場合、ステートマシンはステップ１９０７でＡＣＫ送信状態１７０２へ遷移する。なんらかの他のイベントを受けた場合、予期せぬものであるのでステップ１９０８でエラーメッセージがプリントされる。
【００３７】
[0061]ＡＣＫ送信状態１７０２のエントリがすむと、ステートマシンは統合されたパケットをどのように完成させるかを判定する必要がある。図２０に示すように、これはステップ２００２で最終的なＭＴＵサイズを算出することにより求められ、次にステップ２００３でそのサイズがＭＡＸを超えるかを判定する。パケットが許容されるＭＴＵを超える場合、ステップ２００７でＡＣＫがパケットから１つ除去され、次にステップ２００８でパケットは図１５に従って完成され、ステップ２００９で送られる。次いで、追加のＡＣＫを受けたため、ＡＣＫペンディング状態１７０１へ戻って新しいＡＣＫバッファが作成される。このＴＣＰ関連性においてパケットが許容されるＭＴＵを超えていない場合は、ステップ２００４で、ステートマシンは図１５に従って統合パケットを完成させるステップへ直ちに進むことができ、次にステップ２００５でパケットを送る。次いでステップ２００６で、ステートマシンはアイドル状態１７００へ遷移する。
【００３８】
[0062]これはＴＣＰ  ＡＣＫの統合の一実施形態である。このアルゴリズムの変形は、１クライアントからではなく複数のクライアントからのＴＣＰ  ＡＣＫを統合するものである。このシナリオが図２１に示されており、ここでは複数のクライアント３０‐１から３０‐Ｃが複数のサーバ１０‐１から１０‐Ｓと話している。ＩＮＤ７０は、ＩＮＤ６０を介してワイヤレスＬＡＮでトラフィックを送っているクライアント３０の全てからのＡＣＫを統合する。図１５に示した統合方法は、ＴＣＰパケット自体にはなんら変更を加えないものなので、１つのＴＣＰ接続の統合パケットを作成するために記述されたアルゴリズムは、複数のＴＣＰ接続のための統合パケットの作成にも適用される。したがって、この変形のエンコーダについては図１７〜２０に十分明確に記載されている。唯一の違いは、この統合チャネルに関連するＴＣＰ接続が繋がっては切断されることである。関連性を制御する信号は、ＴＣＰ接続の追加及び削除も処理しなければならない。
【００３９】
[0063]他の変形は、複数のＴＣＰ接続について、ＴＣＰ  ＡＣＫの要約とＴＣＰ  ＡＣＫの統合との組み合わせを可能にするものである。図２２は、このエンコーダがどのように動作するかを示す。この場合、エンコーダは、複数の接続についてクライアント３０‐１から３０‐Ｃと関係するＴＣＰ  ＡＣＫをバッファする。各接続から１つのＴＣＰ  ＡＣＫ（２２０１）が抽出され、これらのＡＣＫが２２０１‐１から２２０１‐Ｃにラベリングされる。次に各アクティブな接続のためのＡＣＫが１つのパケットに統合されてピアＩＮＤに送られる。これらパケットの符号化は、図１７〜２０のところで述べたステートマシンの変形である。違いは、図１９のステップ１８０３のパケットをバッファに追加する手順がどのように処理されるかのみである。ＡＣＫをパケットにただ付加するだけでなく、ステートマシンは、同じ接続から別のＡＣＫを探さなければならない。すでに１つ存在していれば一緒に要約されてパケットに置かれる。この特定の接続からのＴＣＰ  ＡＣＫがそのパケットになければ、ＴＣＰ  ＡＣＫが付加される。それ以外は、アルゴリズムは同じである。パケットの復号化は図１６に示したものと同じである。
【００４０】
[0064]上述した方法は、フロー制御アルゴリズムを操作することによりクライアント及びサーバの振る舞いに影響を与えることでワイヤレスＬＡＮネットワークの利用を改善するものである。代替的な方法は、ＴＣＰにより提供される輻輳制御機構に影響を与えるものである。オプションの１つは、クライアント３０より伝送されたＡＣＫをいくつかのＡＣＫに分解することである。これはサーバの輻輳ウィンドウをその加法的増加／乗法的減少アルゴリズムによって活性化して、輻輳ウィンドウを増加させる。ＴＣＰの実装は、受けた全てのＡＣＫについて、ＴＣＰ最大セグメントサイズのごく一部の分だけ輻輳ウィンドウを増加させる。ＡＣＫの数を増加することにより、輻輳ウィンドウはより速く開いて、より多くのＴＣＰセグメントを飛ばす。
【００４１】
[0065]この符号化アルゴリズムは、クライアント３０からサーバ１０への帯域幅の利用を増やすことができる。符号化アルゴリズムにより用いられる帯域幅を制御するために、いくつかのパラメータが定められる。第１のパラメータは、最大ＡＣＫ（ＭＡＸＩＭＵＭ  ＡＣＫ）である。これは１つのＡＣＫから生成することができるＡＣＫの最大数を定めるものである。最小セグメントサイズ（ＭＩＮＩＭＵＭ  ＳＥＧＭＥＮＴ  ＳＩＺＥ）は、連続するＡＣＫのシーケンス番号の最小差を求めるものである。例えば、最大ＡＣＫを３、最小セグメントサイズを５００と定めることができる。エンコーダから見た現在のＡＣＫとその前のＡＣＫとの間のシーケンス差が２１００バイトであるところにパケットが到着する場合、エンコーダはそれぞれが７００バイトずつのシーケンス差をもつ３つのＴＣＰ  ＡＣＫを生成することになる。この符号化は、最大ＡＣＫパラメータにより制限される。あるＴＣＰ  ＡＣＫが４００バイトのシーケンス差で到着した場合、このＡＣＫは最小セグメントサイズより小さいため変更されないまま伝送される。帯域幅を制御する他の方法は、アルゴリズムのデューティサイクルを定めることである。つまり符号化アルゴリズムが有効である期間と無効である期間が定められる。１つの方法が、これらの期間を、総期間を定める時間及びデューティファクタによってパーセントで定めるものである。デューティファクタが、符号化アルゴリズムが動作している期間のパーセンテージを定める。別のオプションは、これらの期間をパケットによって定めるものである。総期間はＰＡＣＫＥＴ＿ＰＥＲＩＯＤと定められる。ＰＡＣＫＥＴ＿ＰＥＲＩＯＤ内で、ＥＮＣＯＤＥ＿ＬＩＭＩＴが符号化されるパケットの数を定める。
【００４２】
[0066]この機能を実装するのに必要な基本的アルゴリズムを図２３〜図２５に示す。図２３は、ＴＣＰ  ＡＣＫを分割するための一般的アルゴリズムを示す。これはステップ２３０１でＬＡＳＴ＿ＶＡＬＩＤ＿ＡＣＫパラメータを調べることから始まる。このパラメータはＡＣＫが伝送される前にＡＣＫを分割するための基準として用いられ、各ＡＣＫが有効な情報を搬送していることを保証する。したがって、このパラメータが有効でない場合、ステップ２３０６で現在のシーケンス番号に初期化され、ステップ２３０９でパケット期間カウンタすなわちＡＣＫ  ＣＯＵＮＴがゼロに初期化され、ステップ２３０７でＡＣＫが伝送される。ＬＡＳＴ＿ＶＡＬＩＤ＿ＡＣＫパラメータが有効であれば、ステップ２３０２で現在のＡＣＫシーケンス番号がＬＡＳＴ＿ＶＡＬＩＤ＿ＡＣＫと比較される。現在のＡＣＫシーケンスがＬＡＳＴ＿ＶＡＬＩＤ＿ＡＣＫパラメータと等しい場合は、関連するＴＣＰ接続は損失を経験し、このことがサーバ１０に信号返送される。こういう状況なので、ＡＣＫはサーバに戻って高速リカバリアルゴリズムを初期化する必要がある。したがって、ステップ２３０７でこのＡＣＫが直ちに送られる。現在のシーケンスがＬＡＳＴ＿ＶＡＬＩＤ＿ＡＣＫと等しくない場合、ステップ２３０３でＡＣＫ  ＣＯＵＮＴがインクリメントされ、ステップ２３０４でＥＮＣＯＤＥ＿ＬＩＭＩＴと比較される。ＡＣＫ  ＣＯＵＮＴがＥＮＣＯＤＥ＿ＬＩＭＩＴ以下である場合は、ステップ２３０５でＡＣＫが分割され、ステップ２３０６でＬＡＳＴ＿ＶＡＬＩＤ＿ＡＣＫが現在のシーケンス番号に設定され、ステップ２３０７でＡＣＫが送られる。ステップ２３０４でＡＣＫ  ＣＯＵＮＴがＥＮＣＯＤＥ＿ＬＩＭＩＴよりも大きいと判定されると、ＡＣＫ  ＣＯＵＮＴはステップ２３０８でＰＡＣＫＥＴ＿ＰＥＲＩＯＤと比較される。ＡＣＫ  ＣＯＵＮＴがＰＡＣＫＥＴ＿ＰＥＲＩＯＤより小さいと判定されると、ステップ２３０６でＬＡＳＴ＿ＶＡＬＩＤ＿ＡＣＫは現在のシーケンス番号に設定され、ステップ２３０７でＡＣＫが送られる。それ以外の場合は、パケット期間はステップ２３０９でＡＣＫ  ＣＯＵＮＴを０に設定することによりリセットされる。
【００４３】
[0067]ステップ２３０７でＡＣＫを送る方法が手順として表されているのは、どのようにこれを処理するかはオプションだからである。有線の環境ではパケットは伝送のためのイターフェースで単に直接待ち行列に入れられることができる。ＡＣＫの分割による帯域幅の増大は、有線ＬＡＮにより提供される帯域幅によって簡単に処理することができる可能性がある。任意の損失をＴＣＰ動作の当然の前提により処理することができる。この動作モードでは符号化されたパケットが標準的なＴＣＰ/ＩＰパケットのままなので復号化する必要はない。しかし、この方法をそのまま半二重ワイヤレス環境で用いる場合、パケット数の増加によりワイヤレスＬＡＮの利用が減少する可能性がある。これは衝突回避アルゴリズムがワイヤレスＬＡＮで実行されているためである。この問題を回避するために、ＴＣＰ  ＡＣＫの分割を、ワイヤレスＬＡＮで送られる１つのパケットへのＴＣＰ  ＡＣＫの統合と組み合わせることができる。このように、追加のパケットが追加のワイヤレス伝送オーバーヘッドを招くことなく目的を達することができる。したがって、図２３のステップ２３０７の手順は、図１７のステートマシンを用いて実装することができる。図１６に示したように、このモードは２つのＩＮＤ間の関連性を必要とするので、これらパケットは復号化することができる。この関連性は、ＩＮＤがクライアントとサーバとの間のＴＣＰ関連性を見出すと、動的に信号伝達されることができる。
【００４４】
[0068]ＴＣＰ  ＡＣＫを分割する方法を図２４及び２５に示す。手順はステップ２４０１で現在のシーケンス番号とＬＡＳＴ＿ＶＡＬＩＤ＿ＡＣＫとの差を算出することから始まる。ステップ２４０２で差がＭＩＮＩＭＵＭ＿ＳＥＧＭＥＮＴ＿ＳＩＺＥより小さいと判定された場合、ステップ２４０３でＡＣＫを１に設定し、シーケンス間隔（Ｓｅｑｕｅｎｃｅ  Ｉｎｔｅｒｖａｌ）をＤｉｆｆｅｒｅｎｃｅに設定することにより、１つのＡＣＫのみが生成される。ステップ２４０２で差がＭＩＮＩＭＵＭ＿ＳＥＧＭＥＮＴ＿ＳＩＺＥよりも大きいと判定された場合、ＡＣＫの数はステップ２４０４でその差をＭＩＮＩＭＵＭ＿ＳＥＧＭＥＮＴ＿ＳＩＺＥで割ることで求められる。ステップ２４０５でＡＣＫの数がＭＡＸＩＭＵＭ＿ＡＣＫを超えると判定された場合、ステップ２４０６でＡＣＫはＭＡＸＩＭＵＭ＿ＡＣＫに設定され、シーケンス間隔はＭＡＸＩＭＵＭ＿ＡＣＫで割られた差に設定される。それ以外の場合は、ステップ２４０７でシーケンス間隔はＭＩＮＩＭＵＭ＿ＳＥＧＭＥＮＴ＿ＳＩＺＥに設定される。
【００４５】
[0069]ＴＣＰ  ＡＣＫの数及びＡＣＫ間のシーケンス間隔が求められたので、ＴＣＰ  ＡＣＫをセグメント化することができる。このアルゴリズムを図２５に示す。ＡＣＫを複数のＡＣＫに分離するために、ループカウンタの現在のＡＣＫ（Ｃｕｒｒｅｎｔ  ＡＣＫ）が１に初期化され、ステップ２５０１で最後のシーケンス（Ｌａｓｔ  ｓｅｑｕｅｎｃｅ）がＬＡＳＴ＿ＶＡＬＩＤ＿ＡＣＫに設定される。次いでステップ２５０２で、現在のＡＣＫをＡＣＫ、すなわち生成されるＴＣＰ  ＡＣＫの総数、と比較することによりループ条件がチェックされる。現在のＡＣＫがＡＣＫと等しくない場合、第１のＡＣＫのシーケンス番号が最後のシーケンス番号とシーケンス間隔とを用いてステップ２５０３で算出され、ステップ２５０４でこのＡＣＫパケットが生成される。次にステップ２５０５で、このＡＣＫは送られるＡＣＫのリストに追加され、ステップ２５０６でＡＣＫカウンタがインクリメントされる。この手順が、ステップ２５０２で現在のＡＣＫがＡＣＫと等しくなるまで繰り返される。この時点で、ループが存在し、ステップ２５０７で最終的なＡＣＫシーケンス番号を現在のシーケンス番号に設定することにより、最終的なＡＣＫが生成され、ステップ２５０８でこのＡＣＫが伝送されるＡＣＫのリストに追加される。
【００４６】
[0070]図２６は、図５のネットワークでクライアント２０からサーバ１０に移動する図２のメッセージ２２０を用いた機能性の例を示す。図２６は、生成されたＡＣＫを統合するために図１７のアルゴリズムを用いた、図２３〜図２５のアルゴリズムを示す。この例では、ＥＮＣＯＤＥ＿ＬＩＭＩＴ及びＰＡＣＫＥＴ＿ＰＥＲＩＯＤは１に設定されており、全てのＴＣＰ  ＡＣＫを複数のＡＣＫに分解させている。ＭＩＮＩＭＵＭ＿ＳＥＧＭＥＮＴ＿ＳＩＺＥは５００バイトに設定され、ＭＡＸＩＭＵＭ＿ＡＣＫは４に設定される。ＬＡＳＴ＿ＶＡＬＩＤ＿ＡＣＫは１である。結果として、メッセージ２２０がＩＮＤ７０に到達すると、このメッセージは、シーケンス番号５０１、１００１、及び１５０１をもつ３つのＡＣＫに分解される。これらメッセージは、一つの符号化されたメッセージ２６０１に統合され、ワイヤレスクライアント５０へ送られる。ワイヤレスクライアント５０及びワイヤレスＡＰ４０は、ステップ２６０２で、衝突回避アルゴリズムを用いて符号化されたパケットの伝送のネゴシエーションを行い、これがメッセージ２６０３でＩＮＤ６０に伝えられる。ＩＮＤ６０は、図１６に示したアルゴリズムに従い符号化されたパケットの中のＴＣＰ  ＡＣＫをアンパックする。デコーダが作業を終えたとき、この３つのＡＣＫはサーバ３０へ転送され、次にサーバ３０が自身の輻輳ウィンドウを増大する。
【００４７】
[0071]ワイヤレスＬＡＮ技術によっては、ＬＡＮ上の伝送レートが制限される場合がある。例えば、８０２．１ｂネットワークの伝送レートは１１‐Ｍｂｐｓしかないのに対し、８０２．１ｇネットワークの伝送レートは５４‐Ｍｂｐｓである。ＬＡＮタイプの検出は、関連するＩＮＤ間で推定して共有することができ、これは特定の関連性のためにＩＮＤにより選択される符号化レベルに影響を及ぼすことができる。リンクが伝送レート又はパケット毎秒のいずれかにおいて制限されていることが認められると、符号化レートが増大される場合がある。ＩＮＤがＴＣＰ  ＡＣＫを要約又は統合している場合、符号化は、ＭＡＸ＿ＡＣＫを大きくすること又はＡＣＫペンディングタイマのタイムアウト期間を長くすることにより増大することができる。
【００４８】
[0072]ＴＣＰ  ＡＣＫが適時に送られることを保証するために、全てのエンコーダは、用いられているアルゴリズムに関係なく、出ていくパケットのＴＯＳ／ＤＳＣＰビットを確実に適時に配信されるように設定することができる。符号化されたパケットがワイヤレスＬＡＮに到着するとき、８０２．１１ｅを使用して確実にＴＣＰ  ＡＣＫが適時に配信されるようにすることができる。８０２．１１ｅは、ワイヤレスＬＡＮでＴＣＰ  ＡＣＫのオーバーヘッドを低減するためにも活用することができる。
【００４９】
[0073]本発明の実施形態は、サーバ又は他のコンピュータデバイス等のエンドポイント及び関連する符号化構成要素を有するネットワークで実施される。符号化構成要素及び上述した方法は、ハードウェア、ソフトウェア、又はその組み合わせに実装することができる。ソフトウェアに実装される部分は、機械可読媒体（コンピュータ可読媒体、プロセッサ可読媒体、又はコンピュータ可読プログラムコードが組み込まれているコンピュータ使用可能媒体）に記憶されたソフトウェア製品として表される。機械可読媒体は、任意の適切な有形的媒体であることができ、これには、ディスケット、コンパクトディスク読み取り専用メモリ（ＣＤ‐ＲＯＭ）、メモリデバイス（揮発性又は不揮発性）、又は類似の記憶機構等の磁気、光、又は電気的な記憶媒体が含まれる。機械可読媒体は、さまざまな命令集合、コードシーケンス、構成情報、又は他のデータを含んでおり、これらが実行されると、プロセッサは本発明の実施形態による方法を行う。当業者であれば、記載した発明の実施に必要な他の命令及び動作も機械可読媒体に記憶することができることが明らかであろう。機械可読媒体により動作するソフトウェアは回路と連動して上述したタスクを行う。
【００５０】
[0074]本発明の特定の実施形態及びアプリケーションを図示して説明してきたが、本発明は本明細書に開示した構造及び構成そのものに限定されるのではないこと、並びに、添付の請求項に規定した発明の精神及び範囲から逸脱しない範囲のさまざまな修正、変更、及び変形が上記の記載により明らかであることが理解されるはずである。
【図１】
2014509483.tif 000004
【図２】
2014509483.tif 000005
【図３】
2014509483.tif 000006
【図４】
2014509483.tif 000007
【図５】
2014509483.tif 000008
【図６】
2014509483.tif 000009
【図７】
2014509483.tif 000010
【図８】
2014509483.tif 000011
【図９】
2014509483.tif 000012
【図１０】
2014509483.tif 000013
【図１１】
2014509483.tif 000014
【図１２】
2014509483.tif 000015
【図１３】
2014509483.tif 000016
【図１４】
2014509483.tif 000017
【図１５】
2014509483.tif 000018
【図１６】
2014509483.tif 000019
【図１７】
2014509483.tif 000020
【図１８】
2014509483.tif 000021
【図１９】
2014509483.tif 000022
【図２０】
2014509483.tif 000023
【図２１】
2014509483.tif 000024
【図２２】
2014509483.tif 000025
【図２３】
2014509483.tif 000026
【図２４】
2014509483.tif 000027
【図２５】
2014509483.tif 000028
【図２６】
2014509483.tif 000029
【国際調査報告】
2014509483.tif 000030
2014509483.tif 000031
2014509483.tif 000032