(57)【要約】      （修正有）【課題】データ接続またはデータフローの動作改善のため、データトラフィックシェーピング方法、装置、および、ワイヤレス機器を提供する。【解決手段】データトラフィックシェーピング方法は、転送されるデータパケットを受信する工程と、バッファメモリが、上記データパケットのうちの少なくとも１つのデータパケットを収容するためのスペースを有しているならば、上記少なくとも１つのデータパケットを上記バッファメモリ内に格納する工程と、上記バッファメモリが、上記データパケットのうちの少なくとも１つの他のデータパケットを収容するためのスペースを有していないならば、上記少なくとも１つの他のデータパケットを廃棄する工程とを含む。装置は、上記方法を実行するように構成されている。ワイヤレス機器は、上記装置を備えていてよい。【選択図】図１
2010148110.tif 000002
【特許請求の範囲】
【請求項１】
転送されるデータパケットを受信する工程と、
バッファメモリが、上記データパケットのうちの少なくとも１つのデータパケットを収容するためのスペースを有しているならば、上記少なくとも１つのデータパケットを上記バッファメモリ内に格納する工程と、
上記バッファメモリが、上記データパケットのうちの少なくとも１つの他のデータパケットを収容するためのスペースを有していないならば、上記少なくとも１つの他のデータパケットを廃棄する工程とを含む、データトラフィックシェーピング方法。
【請求項２】
格納された上記少なくとも１つのデータパケットを転送する工程をさらに含む、請求項１に記載の方法。
【請求項３】
廃棄された上記少なくとも１つの他のデータパケットを転送しない工程をさらに含む、請求項１に記載の方法。
【請求項４】
上記廃棄する工程は、上記データパケットのうちの１つの他のデータパケットだけを廃棄する工程を含む、請求項１に記載の方法。
【請求項５】
上記データパケットは、ペイロードデータパケットである、請求項１に記載の方法。
【請求項６】
上記データパケットは、通信制御プロトコル（ＴＣＰ）データパケットである、請求項１に記載の方法。
【請求項７】
上記受信する工程は、上記データパケットと、転送される受信確認とを、多重化されたデータストリームにおいて受信する工程を含む、請求項１に記載の方法。
【請求項８】
多重化された上記データストリームから、上記受信確認をフィルタで取り除く工程をさらに含む、請求項７に記載の方法。
【請求項９】
格納された上記少なくとも１つのデータパケットよりも後に受信され、格納された上記少なくとも１つのデータパケットよりも高い優先順位を有している、１つまたは複数の上記受信確認を転送する工程をさらに含む、請求項７に記載の方法。
【請求項１０】
上記受信確認を、受信確認バッファ内に格納する工程をさらに含む、請求項７に記載の方法。
【請求項１１】
格納された全ての上記受信確認を、格納された上記少なくとも１つのデータパケットよりも高い優先順位で転送する工程をさらに含む、請求項１０に記載の方法。
【請求項１２】
上記バッファメモリは、上記少なくとも１つのデータパケットを収容するために割り当てられる総スペースを有し、上記割り当てられる総スペースは、ＢＷ×ＲＴＴよりも大きく、且つ、ＢＷ×ＲＴＴの２倍よりも小さく、ここでＢＷは、上記少なくとも１つのデータパケットを転送するための最大伝送帯域幅であり、ＲＴＴは、上記少なくとも１つのデータパケットの伝送と受信確認との最小往復時間である、請求項１に記載の方法。
【請求項１３】
上記バッファメモリは、上記少なくとも１つのデータパケットを収容するために割り当てられる総スペースを有し、上記割り当てられる総スペースは、データ転送が進行している間に動的に調整される、請求項１に記載の方法。
【請求項１４】
双方向データ接続の第１の方向に転送されるペイロードデータパケットを受信する工程と、
バッファメモリが、次に受信される各ペイロードデータパケットに利用可能なように割り当てられた空き領域を有しているならば、受信した上記ペイロードデータパケットを上記バッファメモリ内に格納する工程と、
上記バッファメモリが、次に受信される各ペイロードデータパケットに利用可能なように割り当てられた空き領域を有していないならば、受信した上記ペイロードデータパケットを廃棄する工程とを含む、データトラフィックシェーピング方法。
【請求項１５】
上記双方向データ接続の第２の方向に伝送されたデータの、上記双方向データ接続の上記第１の方向に転送される受信確認を受信する工程をさらに含む、請求項１４に記載の方法。
【請求項１６】
格納された上記ペイロードデータパケットを転送する工程と、
受信した上記受信確認を、格納された上記ペイロードデータパケットよりも高い優先順位で転送する工程とをさらに含む、請求項１５に記載の方法。
【請求項１７】
双方向データ接続の一方向に伝送されるデータストリームを受信する工程であって、上記データストリームは、ペイロードデータパケットと、上記双方向データ接続の他方向に伝送されたデータの受信を確認する受信確認とを有する工程と、
上記双方向データ接続の一方向のさらに後段において生じることになっている、上記データストリーム内に受信されたペイロードデータパケットの喪失をシミュレートする工程とを含む、データトラフィックシェーピング方法。
【請求項１８】
上記シミュレートする工程は、受信したデータパケットを、上記双方向データ接続の一方向に転送する代わりに、ドロップさせる工程を含む、請求項１７に記載の方法。
【請求項１９】
上記シミュレートする工程は、受信した上記データパケットを操作して、受信した上記データパケットが上記データパケットの受取先において適切に受信されたデータパケットとして認識されないようにする工程を含む、請求項１７に記載の方法。
【請求項２０】
上記シミュレートする工程は、受信された上記ペイロードデータパケットよりも前に上記データストリーム内に受信され、上記双方向データ接続の一方向にはまだ転送されていない他のペイロードデータパケットが、所定の最大データ量を超過した場合のみ、受信された上記ペイロードデータパケットの喪失をシミュレートする工程を含む、請求項１７に記載の方法。
【請求項２１】
上記データストリーム内に受信された他のペイロードデータパケットを転送する工程と、
上記データストリーム内に受信された受信確認を、上記他のペイロードデータパケットよりも高い優先順位で転送する工程とをさらに含む、請求項１７に記載の方法。
【請求項２２】
転送されるデータパケットを受信するための入力ポートと、
上記データパケットのうちの少なくとも１つのデータパケットを収容するために利用可能なスペースを有している場合に、上記少なくとも１つのデータパケットを格納するバッファメモリと、
上記バッファメモリが、上記データパケットのうちの少なくとも１つの他のデータパケットを収容するために利用可能なスペースを有していないならば、上記少なくとも１つの他のデータパケットを廃棄するための制御ユニットとを備える装置。
【請求項２３】
上記廃棄することは、上記データパケットのうちの他の１つのデータパケットだけを廃棄することを含む、請求項２２に記載の装置。
【請求項２４】
上記バッファメモリは、上記少なくとも１つのデータパケットを収容するために割り当てられる総スペースを有し、上記割り当てられる総スペースは、ＢＷ×ＲＴＴよりも大きく、且つ、ＢＷ×ＲＴＴの２倍よりも小さく、ここでＢＷは、上記少なくとも１つのデータパケットを転送するための最大伝送帯域幅であり、ＲＴＴは、上記少なくとも１つのデータパケットの伝送と受信確認との最小往復時間である、請求項２２に記載の装置。
【請求項２５】
上記バッファメモリは、上記少なくとも１つのデータパケットを収容するために割り当てられる総スペースを有し、上記割り当てられる総スペースは、データ転送が進行している間に動的に調整される、請求項２２に記載の装置。
【請求項２６】
上記入力ポートは、さらに、転送される受信確認を受信する、請求項２２に記載の装置。
【請求項２７】
格納された上記少なくとも１つのデータパケットを転送すると共に、格納された上記少なくとも１つのデータパケットよりも後に受信した受信確認を、格納された上記少なくとも１つのデータパケットよりも高い優先順位で転送するための転送ユニットをさらに備える、請求項２６に記載の装置。
【請求項２８】
請求項２２に記載の装置を備えるワイヤレス機器。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
[技術分野]
本発明は、概して、データトラフィックシェーピング方法、装置、およびワイヤレス機器に関する。
【図面の簡単な説明】
【０００２】
【図１】本発明の一実施形態に係るデータトラフィックシェーピング方法を示す図である。
【図２】本発明の他の一実施形態に係るデータトラフィックシェーピング方法を示す図である。
【図３】本発明のさらに他の一実施形態に係るデータトラフィックシェーピング方法を示す図である。
【図４】本発明の一実施形態に係る装置を示すブロック図である。
【発明を実施するための形態】
【０００３】
以下の発明の詳細な説明は、本発明の典型的な実施形態を説明するものである。当てはまる場合は、方法の一実施形態の説明は、対応する装置の実施形態の機能をも説明するものであると見なされる。および、その逆も当てはまる。本説明は、決して限定的に理解されるものではなく、単に、本発明の一般的な原理を説明するためのものである。しかしながら、本発明の範囲は、特許請求の範囲によってのみ規定されるものであり、以下に記載する典型的な実施形態によっては限定されない。
【０００４】
図１には、本発明の一実施形態に係るデータトラフィックシェーピング方法が示されている。
【０００５】
データトラフィックシェーピングとは、一般的には、データ接続上のデータフロー（トラフィック）に意図的に影響を与えることを意味している。これによって、データ接続またはデータフロー自体の動作が改善され得る。
【０００６】
１１０において、データパケットを受信する。これらのデータパケットは転送される。
【０００７】
１２０では、バッファメモリが、上記データパケットのうちの少なくとも１つのデータパケットを収容するためのスペースを有しているならば、上記少なくとも１つのデータパケットを上記バッファメモリ内に格納する。
【０００８】
１３０では、バッファメモリが、上記データパケットのうちの少なくとも１つの他のデータパケットを収容するためのスペースを有していないならば、上記少なくとも１つの他のデータパケットを廃棄する。
【０００９】
図２には、本発明の他の一実施形態に係るデータトラフィックシェーピング方法が示されている。
【００１０】
２１０において、ペイロードデータパケットを受信する。これらのペイロードデータパケットは、双方向データ接続の第１の方向に転送される。
【００１１】
２２０では、バッファメモリが、次に受信される各ペイロードデータパケットに利用可能なように割り当てられた空き領域を有しているならば、受信したペイロードデータパケットを上記バッファメモリ内に格納する。
【００１２】
２３０では、バッファメモリが、次に受信される各ペイロードデータパケットに利用可能なように割り当てられた空き領域を有していないならば、受信したペイロードデータパケットを廃棄する。
【００１３】
図３には、本発明のさらに他の実施形態に係るデータトラフィックシェーピング方法が示されている。
【００１４】
３１０において、データストリームを受信する。このデータストリームは、双方向データ接続の一方向に伝送される。データストリームは、ペイロードデータパケットを含むと共に、双方向データ接続の他方向に伝送されたデータの受信を確認する受信確認を含む。
【００１５】
３２０において、双方向データ接続の一方向のさらに後段において生じることになっている、データストリームにおいて受信されたペイロードデータパケットの喪失をシミュレートする。
【００１６】
データを伝送するために用いられるデータ接続を、同時に、データを逆方向にも伝送するために用いてよい。データは、各方向に、別々の伝送路を介して伝送されてもよいし、または、単一の伝送路を用いて、時分割式に伝送されてもよい。いずれの場合にも、一般に、一方向におけるデータ転送が、他の方向における同時のデータ転送を妨げないことが望ましい。
【００１７】
双方向データ接続は、高速方向と低速方向とを有していてよい。双方向データ接続は高速経路と低速経路とを有しているとも言える。このようなデータ接続は、非対称データ接続と呼ばれる。例えば、有線データ接続であるＡＤＳＬ（非対称型デジタル加入者回線）、および、無線データ接続であるＨＳＤＰＡ（ハイスピード・ダウンリンク・パケット・アクセス）は、非対称性の強い非対称データ接続である。非対称データ接続は、通常、ダウンリンクにおいて高速通信速度を提供し、アップリンクにおいて低速通信速度を提供する。ダウンリンクは通常、ネットワークまたはサーバから端末またはユーザへの方向である。アップリンクは通常、端末またはユーザからネットワークまたはサーバへの方向である。
【００１８】
非対称データ接続では、高速方向（例えばダウンリンク）におけるデータ転送は、低速方向（例えばアップリンク）におけるあらゆるデータ転送によって強い障害を受け得る。これは、データ接続が通信制御プロトコルＴＣＰに基づいて動作される場合に、特に当てはまる。
【００１９】
低速方向におけるデータ伝送によって、利用可能な送信能力が容易に過負荷になり得る。非対称性の強い非対称データ接続では、低速方向の送信能力は、高速方向の送信能力よりも大幅に低い。換言すると、低速方向において伝送帯域幅の飽和が生じ得る。
【００２０】
同時にデータは、データ接続の高速方向において、高速データ速度で伝送される。この高速データ速度は、高速方向の高速送信能力によって可能にされるものである。これらの高速データを受信すると、該データの受信を確認する受信確認が生成される。受信確認は、高速データの送信元に、低速方向を用いて返送される。
【００２１】
低速方向における伝送帯域幅が飽和した結果、データ接続の高速方向において伝送されたデータの受信を確認する受信確認が適切に伝送されることが不可能になる。例えば、これらの受信確認は、低速方向において伝送される他の全てのデータの長い待ち行列に入り込んで動きが取れなくなる。高速データの送信元は、高速データの受信確認を、時間的に十分に間に合って受信せず、高速方向におけるデータ転送の速度を落とすか、または、データ転送を中断してしまうことさえある。
【００２２】
上述の内容から明らかなように、低速方向における伝送帯域幅の飽和によって、他の方向における高速データ転送の速度が低下し、このため高速方向において利用可能な大部分の伝送帯域幅が使用されないままになる。
【００２３】
高速方向における帯域幅（ＢＷ）をより良好に利用するために、トラフィックシェーピング法を用いることが可能である。
【００２４】
非対称性が弱い双方向データ接続、または、対称性が強い双方向データ接続でも、一方向におけるデータ転送は、他方向におけるデータ転送によって悪影響を受ける。例えば、一方向に伝送されるデータの受信を確認して他方向に移動する受信確認は、同じく当該他方向に移動するペイロードデータによって遅延され得る。
【００２５】
任意の双方向データ接続において、および、当該双方向データ接続の任意の方向において、帯域幅をより良好に利用するために、トラフィックシェーピング法を用いることが可能である。
【００２６】
以下に、トラフィックシェーピングについてさらに説明する。本発明の一実施形態は、クライアントデータ処理装置、例えばクライアントコンピュータ、例えばパーソナルコンピュータ（ＰＣ）が、サーバデータ処理装置、例えばコンピュータ、例えばインターネット内のサーバに、通信制御プロトコル（ＴＣＰ）に基づいて、非対称データ接続を介して接続されている場合を想定している。非対称データ接続は、サーバからクライアントまでのダウンリンク（ＤＬ）において高速通信速度を提供し、クライアントからサーバまでのアップリンク（ＵＬ）において低速通信速度を提供する。データ接続またはデータ接続の一部は、例えば、無線モデムといったモデムによって実現され得る。このモデムは、スタンドアロン型モデムであってもよいし、または、クライアントコンピュータ、例えばノートブックＰＣまたは携帯情報端末（ＰＤＡ）に内蔵されていてもよいし、または、サーバコンピュータと共に使用される別個の携帯電話内に組み込まれていてもよい。
【００２７】
クライアントコンピュータ上、または、データ接続に関連付けられたルータ上で動作するコンピュータプログラムを、トラフィックシェーパーとして用いてよい。トラフィックシェーパーは、クライアントコンピュータ上のアプリケーションを監視し、ＵＬにおいて送信が許可されるデータを制限し、ＵＬにおいて利用可能な帯域幅（ＢＷ）の飽和を回避する。その後すぐに、ＴＣＰ受信確認（ＡＣＫ）がＵＬに伝送され得る。トラフィックシェーパーは、ＤＬデータパケットのＡＣＫにフィルタをかけ、これらに、他のＵＬデータパケットよりも高い優先順位を与える。従って、このＡＣＫは、ＵＬ内のＢＷが飽和されている場合であっても、待ち行列において待つ必要はなく、ＵＬにすぐに伝送可能である。
【００２８】
これまでの段落に記載した方法は、良好に作用するが、全ての場合において適切であるわけではない。このような不適切な場合とは、クライアントコンピュータが、ネットワーク（サーバコンピュータ）に、携帯電話または無線モデムなどを用いて接続されている場合である。この携帯電話または無線モデムを、以下では、一般にワイヤレス機器と呼ぶ。
【００２９】
クライアントコンピュータ上のアプリケーションによる使用が許可されているＵＬ内のＢＷの部分を制御するということは、ユーザが、特殊なソフトウェアをインストールする必要があるということを意味しており、これは、さらにコストがかかることと、潜在的に設定作業が必要になることとを意味している。さらに、クライアントコンピュータ上で実施されるトラフィックシェーパーと、ネットワークに接続させる通信媒体とのアナログインターフェースとの間のさらなるバッファが、ＡＣＫ遅延を増大させる一因となる。
【００３０】
ＴＣＰ  ＡＣＫがより高い優先順位を与えられ、ワイヤレス機器の待ち行列において待つ必要がない、ワイヤレス機器において実施される解決策を探しても、これらの待ち行列は、パーソナルコンピュータ（ＰＣ）などのクライアントコンピュータ内のバッファと比べて小さいため、メリットはわずかである。ワイヤレス機器内のデータバッファは、クライアントコンピュータ上のアプリケーションがＵＬにおいて送信しようとしているデータだけで急速に充填され得る。従って、ワイヤレス機器のデータバッファ（待ち行列）内には、フィルタで取り除かれて他のデータの前に置かれるＡＣＫは存在しない。このため、ＴＣＰ  ＡＣＫに、ワイヤレス機器の待ち行列に関してより高い優先順位を与える試みは、良好には動作しない。
【００３１】
本発明の実施形態によれば、少なくとも１つのデータパケットを、転送する代わりに廃棄する。これは、このデータパケットが受取先に届かず、受取先が該データパケットのＡＣＫをデータパケットの送信元に返送しないという効果を有している。これはまた、データパケットが受取先に届く途中にどこかで喪失してしまったということを送信元に知らせる効果を有している。受信したＡＣＫに基づいて発信データフローを制御するデータ伝送プロトコルを用いる送信元は、データ速度を低下することによって、つまり、その時以降、時間につきより少ないデータを送信することによって、反応する。なぜなら、データパケットの喪失は、以前に用いられていたデータ速度は速すぎるということ、つまり、データ接続が提供可能であったよりも多くのＢＷが必要だということを示す表示だからである。換言すると、ここに記載するようにデータパケットを廃棄することは、送信元が高すぎるＢＷの使用を試みており、送信元はより低いＢＷを使用すべきであることを、送信元、例えばクライアントコンピュータのＴＣＰ／ＩＰプロトコルスタックに知らせる１つの方法である。
【００３２】
この操作の目的は、データ（例えばペイロードデータパケット）によって使用される、データ接続の一方向（例えばＵＬ）におけるＢＷを、データ接続の他方向に移動するデータ（例えばＤＬデータパケットのデータ）の受信を確認してデータ接続の当該一方向に移動するＡＣＫに対しても当該ＢＷのうちの必要な部分を与えられるような値に、制限することである。従って、一方向、例えばＵＬにおけるＢＷは、一方向に移動するデータによって連続的に飽和されることはなく、システム内の一方向におけるデータ待ち行列は、満杯になることはない。このため、データ接続の他方向において移動するデータのＡＣＫ、例えばＤＬデータパケットのＡＣＫに与える遅延を最小化する。
【００３３】
本発明の実施形態によれば、１つのデータパケットだけを廃棄する。後のデータパケットは、通常、受取先に転送され得る。これは、ここでも、送信元が高すぎるＢＷの使用を試みており、送信元はより低いＢＷを使用すべきであることを、送信元に知らせる効果を有している。また、これは、データ伝送が、１つより多いデータパケットを廃棄する場合ほどには妨げられないという効果を有している。受取先は、１つのデータパケットが到着していないという通知を送信してよく、尚、後のデータパケットのＡＣＫを送信してもよい。なお、データ接続の一方向におけるデータによって使用されるＢＷを制限しているが、これは、さらに後段において１つまたは１つより多くの廃棄されるデータパケットの分が欠けること自体に基づいているのではない。上述の知らせる効果に基づくとともに、データパケットが受取先に届く途中のどこかで喪失したことを送信元が認識すると送信元がより低いＢＷを用いるという反応に基づいている。このことに留意されたい。
【００３４】
本発明の一実施形態によれば、廃棄する代わりに、データパケットを操作して、その後、受取先に転送する。例えば、データパケット内のチェックサムを意図的に変更する。この操作の結果、操作されたデータパケットは、受取先に適切に受信されたデータパケットとしては認識されない。受取先は、この操作されたデータパケットのＡＣＫをデータパケットの送信元に返送しない。これは、ここでも、送信元が高すぎるＢＷの使用を試みており、送信元はより低いＢＷを使用すべきであることを、送信元に知らせる効果を有している。
【００３５】
ここに提案する、一実施形態に係る解決策は、ＤＬデータパケットのために生成されるＡＣＫの、システム内の遅延を低減することを試みるものである。これらのＡＣＫは、ＵＬ方向に伝送される。これを実現するために、ＵＬに関連するＰＣ内のバッファは、ほとんど常に、空にされている必要があり、モデムにおいては、ＡＣＫは、データパケットを追い越すことを許可され、より高い優先順位で送信される必要がある。これによって、ＡＣＫが、ＰＣバッファおよびモデムバッファの両方においてＵＬデータパケットを待つ必要はないことが、保証される。
【００３６】
一実施形態によれば、モデムは、前の段落において言及した２つの必須条件を実現するために、ＰＣが送信可能な全てのデータを読み出し、各パケットに次のことを行う。パケットがＡＣＫである場合、これをＡＣＫバッファ（受信確認バッファ）内に格納する。ＡＣＫバッファが満杯の場合、使用者端末（ＵＥ）とＰＣとの間のフロー制御を用いる。パケットがＴＣＰデータパケットである場合、これを、輻輳バッファと呼ばれる他のバッファメモリ内に格納する。このバッファメモリが満杯であるか、または、所定の充填レベルに達している場合、残りのデータパケットのうちの少なくとも１つのデータパケットを廃棄する。残りのデータパケットのうちの１つより多いデータパケットを廃棄してもよいし、または、全てのデータパケットを廃棄してもよい。廃棄することは、各データパケットが完全に廃棄され、転送されないことを意味している。ＵＤＰ（ユーザ・データグラム・プロトコル）のような他のデータパケットは、輻輳バッファまたは他のバッファにも格納される必要がある。格納する場所が空いていない場合は、モデムとＰＣとの間のフロー制御機構を用いてもよい。
【００３７】
一実施形態によれば、バッファメモリ（輻輳バッファ）が所定の充填レベル、例えば、規定の充填レベル閾値に達した場合に、残りのデータパケットのうちの１つのデータパケットだけを廃棄する。他に残っているデータパケットをバッファメモリ内に格納する。上述の知らせる効果を与えて、データパケットが受取先に届く途中のどこかで喪失したことを送信元が認識することによって、送信元により低いＢＷを使用するように反応させるには、１つのデータパケットだけを廃棄することだけで十分である。他に残っているデータパケットのうちより多くのデータパケットを格納するための場所がバッファメモリ内にない場合、モデムとＰＣとの間のフロー制御機構を用いてよい。あるいは、これらのデータパケットを格納するために、バッファメモリの拡張部として、他のメモリを用いてもよい。
【００３８】
一実施形態では、バッファメモリ（輻輳バッファ）が所定の充填レベル、例えば規定の充填レベル閾値に達した場合に、残りのデータパケットのうちの１つのデータパケットだけを廃棄し、バッファメモリの充填レベルが所定の充填レベル、例えば規定の充填レベル閾値に達していない限り、および、この未到達のレベルから所定の充填レベルに再び接近してこれに到達しない限り、これ以上データパケットは廃棄しない。例えば、送信元は、まず、廃棄されたデータパケットの喪失の反応として、オンザフライのデータパケットの数を低減し、これによって、バッファメモリの充填レベルを大幅に低減する。その後、送信元は、再び、オンザフライのデータパケットの数をゆっくりと増大させるように試みる。暫くして、充填レベルは、再び、所定の充填レベル、例えば規定の充填レベル閾値に達する。その後、再び、残りのデータパケットのうちの１つのデータパケットだけを廃棄する。
【００３９】
データパケットを廃棄することは、ＵＬ内の一般的なデータ速度にはほとんど影響しない。ＰＣ内のＴＣＰ／ＩＰスタックは、ネットワークの混雑時にドロップされたデータパケットを保留し、これらの再送信を試みる。ＰＣ内のＴＣＰ／ＩＰスタックはまた、これに応じていわゆる輻輳ウィンドウを適用し、つまり、これを極めて小さいサイズにする。従ってＴＣＰ／ＩＰスタックは、これ以上、オンザフライでデータを、受信確認無しには送信しないため、輻輳バッファは保留可能である。結果的にすぐに、モデムは、これ以上のデータパケットをドロップさせることを要することなく、ＰＣバッファの中身を内部バッファ例えばＡＣＫバッファや輻輳バッファに移してＰＣバッファを空にすることが可能である。
【００４０】
各パケットがドロップされた後、輻輳ウィンドウが再びゆっくりと増大するにつれて、パケットが全く廃棄されない期間が存在する。空のＰＣバッファは、ＡＣＫを遅延させずにモデムに到達させることを可能にする。
【００４１】
一実施形態では、モデムにおいて、ＡＣＫは、データパケットよりも高い優先順位を与えられる。従って、ここでは、どのＡＣＫも遅延しない。
【００４２】
この方法を行った結果、ＵＬデータ速度は、開始時に少々低下するが、最終的には、良好な平均データ速度になる。ＤＬデータ速度は、ＵＬ接続によっては影響されない。
【００４３】
本発明の実施形態は次の利点を有している。複数の実施形態に係るデータシェーピング法を、モデムにおいて、完全且つ透過的に実施可能である。この場合、透過的に実施するという表現は、クライアントコンピュータ、サーバコンピュータ、および残りのデータ接続が、この実施に依存しないということを意味している。クライアントコンピュータおよびサーバコンピュータおよび残りのデータ接続（データ経路）は、変更される必要はない。データフローは、動的な調整を必要とすることなく、自己調整される。データフローの動作は、ＵＬ内のデータを受信するコンピュータの設定に全く無関係である。両方向（ＵＬ、ＤＬ）における最適なデータ速度を、同時に実現可能である。
【００４４】
本発明の実施形態によれば、トラフィックシェーピングは、モデム内のネットワークの混雑のシミュレーションに基づいている。複数の実施形態によれば、ネットワークの混雑のシミュレーションには、内部（輻輳）バッファが満杯の時に、ＵＬデータパケットをドロップすることが含まれる。フロー制御機構および輻輳回避機構が、データの適切な受信を裏付けるために受信確認を用いるデータ伝送プロトコル（例えばＴＣＰ）において規定されていると仮定すると、この方法は、通信を調整することを助長する。従って、ＵＬデータパケットによって用いられるＵＬ内のＢＷの部分は制限され、ＵＬ内のＢＷがデータによって連続的に飽和されることは、回避される。このＵＬ内のＢＷのデータによる連続的な飽和は、データに並列に移動するＡＣＫを遅延させるものである。モデム内のＵＬ方向におけるＡＣＫにより高い優先順位を与えることによって、通信の調整はさらに改善される。
【００４５】
図４には、本発明の一実施形態に係る装置のブロック図が示されている。この装置は、ワイヤレス機器４００内に包含されている。ワイヤレス機器４００は、例えば、データ転送用の専用無線モデム、または、携帯電話またはＰＤＡ（携帯情報端末）に組み込まれた無線モデムである。
【００４６】
例えばパーソナルコンピュータ（ＰＣ）であるクライアントコンピュータ（ユーザコンピュータ）４０５は、サーバコンピュータ４１０、例えばインターネット４１５内のサーバに、通信制御プロトコル（ＴＣＰ）に基づいて、非対称データ接続４２０、４２５、４３０、４３５を介して接続されている。非対称データ接続は、クライアント／ユーザ４０５とワイヤレス機器４００との間に、ローカル接続４２０、４２５、例えばＵＳＢ（ユニバーサルシリアルバス）接続を含み、ワイヤレス機器４００とサーバ４１０との間に、オーバーザエアー接続４３０、４３５を含む。非対称データ接続は、サーバ４１０からクライアント４０５への方向であるダウンリンク（ＤＬ）方向４２０、４３０を有していると共に、クライアント４０５からサーバ４１０への方向であるアップリンク（ＵＬ）方向４２５、４３５を有している。ワイヤレス機器４００内のＤＬ経路は、データライン４４０として示されており、ワイヤレス機器４００内のＵＬ経路は、データライン４４５として示されている。非対称データ接続は、ＤＬ内のオーバーザエアー接続４３０に高速通信速度を提供し、ＵＬ内のオーバーザエアー接続４３５に低速通信速度を提供する。
【００４７】
ＰＣによって実行されるいくつかのアプリケーションプログラム４５０に、１、２、…、ｎと番号を付して示している。これらのアプリケーションプログラム４５０は、ワイヤレス機器４００を介して、インターネット４１５内の１つまたは複数のサーバ４１０と、データを同時に交換することが可能である。データ交換は、ＰＣ４０５の側で、通信制御プロトコル（ＴＣＰ）に基づいて、ＰＣ  ＴＣＰ／ＩＰスタック４５５によって行われる。ＰＣ  ＴＣＰ／ＩＰスタック４５５は、アプリケーションプログラム４５０から送信されるデータを収集し、受信したデータをアプリケーションプログラム４５０に配布する。
【００４８】
インターネット４１５から来るダウンリンク（ＤＬ）データ（ダウンロードデータとも呼ばれる）は、オーバーザエアー接続４３０を介して、ワイヤレス機器（モデム）４００に到達し、プロトコルスタック４６０において処理される。プロトコルスタック４６０は、例えば３Ｇまたは４Ｇ（ＵＭＴＳ）（ユニバーサル・モバイル・テレコミュニケーションズ・システム）の無線プロトコルスタックであるか、または、ＵＭＴＳ−ＬＴＥ（ロング・ターム・エボリューション）またはＵＭＴＳ−ＬＴＥ−アドバンスド無線プロトコルスタックである。ＤＬデータは、ＤＬ発信バッファ４６５およびローカル接続４２０を介して、ＰＣ４０５に送信される。ＤＬデータはここで、ＰＣ  ＤＬバッファ４７０において受信され、ＰＣ  ＴＣＰ／ＩＰスタック４５５に転送される。
【００４９】
アプリケーションプログラム４５０から来るアップリンク（ＵＬ）データ（アップロードデータとも呼ばれる）は、ＰＣ  ＴＣＰ／ＩＰスタック４５５およびＰＣ  ＵＬバッファ４７５を通過する。ＵＬデータは、ローカル接続４２５を介してワイヤレス機器（モデム）４００に到達し、ここで、入力ポート４８０によって受信される。さらに、ＰＣ  ＴＣＰ／ＩＰスタック４５５は、受信確認（ＡＣＫ）を生成して、ＤＬデータの受信を確認する。これらのＡＣＫは、ＵＬデータに並行してインターネット４１５に送信される。ＡＣＫは、ＰＣ  ＵＬバッファ４７５を通過した後、ローカル接続４２５を介して、ワイヤレス機器（モデム）４００に到達し、ここで、入力ポート４８０によって受信される。
【００５０】
本発明の実施形態によれば、その後、ＵＬデータおよびＡＣＫは、データトラフィックシェーピングを実現するために、さらに処理される。これについては以下の段落において説明する。その後、このような、データライン４４５を介して転送されるＵＬデータおよびＡＣＫだけが、プロトコルスタック４６０において処理されると共に、オーバーザエアー接続４３５を介して、インターネット４１５に送信される。
【００５１】
入力ポート４８０によって受信されたＵＬデータパケットおよびＡＣＫは、ＵＬ受信バッファ４８５の中に供給される。ＵＬ受信バッファ４８５のサイズは、主に、性能的側面によって決定される。
【００５２】
一実施形態では、ＵＬ受信バッファ４８５内に存在する全てのＡＣＫを、ＡＣＫバッファ４９０に移動させる。ＡＣＫバッファ４９０内にＡＣＫがこれ以上収まらないならば、ＰＣ４０５によるフロー制御を用いる必要がある。ＡＣＫバッファ４９０内のＡＣＫは、その後、プロトコルスタック４６０に転送される。
【００５３】
一実施形態では、ＵＬ受信バッファ４８５内のＵＬデータパケットを、次のように処理する。輻輳バッファ４９５が、ＵＬ受信バッファ４８５からＵＬ方向用のデータパケットを受信する。ＵＬ受信バッファ４８５からのＴＣＰデータパケットが、輻輳バッファ４９５のうちで最初に充填される部分であって閾値の充填レベルによって規定される部分内に収まらないならば、このデータパケットは廃棄される。後のＵＬ受信バッファ４８５からのＴＣＰデータパケットは、廃棄されない。制御ユニット５００は、どのＴＣＰデータパケットを廃棄するかを制御する。ＴＣＰデータパケットの廃棄は、図４では、制御ユニット５００からの破線の矢印５０５によって表されている。例えばＵＤＰデータパケットといった非ＴＣＰデータパケットも廃棄されない。廃棄されないデータパケットが輻輳バッファ４９５に全く収まらない、つまり閾値充填レベルよりも上の部分も満杯である場合、ＰＣ４０５によるフロー制御を用いてよい。あるいは、廃棄されないデータパケットを収容するための、他のバッファを用いてもよい。
【００５４】
マルチプレクサ（ＭＵＸ）５１０は、ＡＣＫバッファ４９０からのＡＣＫと、輻輳バッファ４９５からのＵＬデータパケットとを多重化し、これらを、プロトコルスタック４６０に送信する。
【００５５】
一実施形態では、ＡＣＫは、常に、ＵＬデータパケットよりも高い優先順位を有している。これは、ＡＣＫバッファ４９０が空の場合のみ、ＵＬデータパケットがプロトコルスタック４６０に送信されることを意味している。
【００５６】
通常、プロトコルスタック４６０は複数のバッファを含んでいるため、これらのバッファを可能な限り小さく保持するか、または、プロトコルスタック４６０内のバッファが空になる恐れがある場合のみＡＣＫとＵＬデータパケットとをプロトコルスタック４６０に送信することが、有効である。そうでなければ、これらのバッファはＵＬデータで一杯になり、ＡＣＫは、場合によっては極めて長時間待たなければならないかもしれない。このため、ＴＣＰのフローを妨げ、ＤＬデータを遅延させることもあり得る。
【００５７】
輻輳バッファ４９５のサイズは、パケットの喪失後、例えばＴＣＰ  ＵＬデータパケットを廃棄した後でも、または、ＴＣＰ  ＵＬデータパケットがさらにサーバ４１０に到達する途中に喪失してしまった後でも、輻輳バッファ４９５が空にならないように選択されていることが可能である。適切なサイズは、主に、「ＢＷ×ＲＴＴ」の積によって決定される。ここでＢＷは、ＵＬデータパケットを転送するための最大伝送帯域幅であり、ＲＴＴは、ＵＬデータパケットの伝送と受信確認との最小往復時間である。ＲＴＴは、空の輻輳バッファ４９５と完全利用されているＤＬデータ接続とによって測定可能である。
【００５８】
輻輳バッファ４９５のサイズ、より詳細に言うと、輻輳バッファ４９５の最大限に用いられる充填レベルが、「ＢＷ×ＲＴＴ」の積よりも少なくともわずかに大きいならば、ＰＣ  ＴＣＰ／ＩＰスタック４５５によって用いられるＵＬデータ用のＴＣＰ輻輳ウィンドウが、ＢＷ×ＲＴＴの２倍よりも少なくともわずかに大きな最大値まで拡張し、オンザフライのさらなるＵＬデータパケットは、輻輳バッファ４９５の中には収まらなくなって、廃棄される。ＰＣ  ＴＣＰ／ＩＰスタック４５５がパケット喪失を検出すると、ＰＣ  ＴＣＰ／ＩＰスタック４５５によって用いられるＴＣＰ輻輳ウィンドウは半分になるので、新たなＴＣＰ輻輳ウィンドウは、依然として、「ＢＷ×ＲＴＴ」の積よりも少なくともわずかに大きい。従って輻輳バッファ４９５は、完全に空にはならず、このため、ＵＬ内の利用可能な全てのＢＷを有効に使うことを助長する。他方、輻輳バッファ４９５は、データパケットの、クライアントからサーバまでの移動時間を短縮するために、比較的小さく保持されている必要がある。
【００５９】
一実施形態では、輻輳バッファ４９５のサイズは、ＢＷ×ＲＴＴよりも大きく、且つ、ＢＷ×ＲＴＴの２倍よりも小さい。例えば、ＢＷ＝４０ｋＢ／ｓであり、ＲＴＴ＝１ｓであるならば、輻輳バッファ４９５は、４０ｋＢと８０ｋＢとの間のデータ量を有するような大きさであってよい。
【００６０】
他の一実施形態では、輻輳バッファ４９５のサイズは、ＢＷ×ＲＴＴよりも大きく、且つ、ＢＷ×ＲＴＴの３倍よりも小さい。例えば、ＢＷ＝４０ｋＢ／ｓであり、ＲＴＴ＝１ｓであるならば、輻輳バッファ４９５は、４０ｋＢと１２０ｋＢとの間のデータ量を有するような大きさであってよい。
【００６１】
一実施形態では、輻輳バッファ４９５のサイズ、より詳細に言うと、輻輳バッファ４９５の最大限に用いられる充填レベルまたは閾値充填レベルは、データ転送が進行している間に動的に調整される。用いられるサイズは、このバッファが空にならない程度に可能な限り低くなるように調整される。ＰＣ  ＴＣＰ／ＩＰスタック４５５によって用いられるＴＣＰ輻輳ウィンドウが低減された後でも、上記バッファ内には常に、数個より多いデータパケット、例えば２または３よりも多いデータパケットが残っているのならば、用いられるサイズ（閾値）は低下する。ＰＣ  ＴＣＰ／ＩＰスタック４５５によって用いられるＴＣＰ輻輳ウィンドウが低減された後、上記バッファ内には数個より少ない、例えば２または３よりも少ないデータパケットしか残っていないならば、または、このような場合に上記バッファが空になるならば、用いられるサイズ（閾値）は上昇する。
【００６２】
本発明の実施形態によれば、輻輳バッファ４９５および／またはＡＣＫバッファ４９０は、それぞれ、別々の物理バッファメモリによっても実現可能であり、一つの物理バッファメモリの一部分によっても実現可能であり、論理バッファメモリによっても実現可能であり、また、任意のメモリに格納されたデータに「輻輳バッファに格納された」または「ＡＣＫバッファに格納された」といった属性を割り当てることによっても実現可能であり、また、これらの任意の組み合わせによっても実現可能である。
【００６３】
一実施形態では、輻輳バッファ４９５およびＡＣＫバッファ４９０を組み合わせて、１つの統一バッファを形成する。ＵＬデータパケットおよびＡＣＫに対し、これらの到着順に用いられる統一バッファの部分が、統一バッファのトリガー充填レベルによって規定される。一旦このトリガー充填レベルに達すると、ＴＣＰデータパケットは統一バッファに供給されることはない。この時以降、新たに到達した全てのＴＣＰデータパケットは、実際の充填レベルがトリガー充填レベルよりも低くなるまで廃棄または削除される。反対に、ＡＣＫは、実際の充填レベルがトリガー充填レベルよりも高くても、統一バッファに入ることが依然として許可されている。
【００６４】
一実施形態では、ＡＣＫバッファ４９０および／または輻輳バッファ４９５を、別々のバッファとして実施しない。その代わり、ＵＬ受信バッファ４８５が、本明細書に記載したＡＣＫバッファ４９０および輻輳バッファ４９５の各機能を実行するように構成する。従って、この場合は、全てのＡＣＫおよびＵＬデータパケットを、ＵＬ受信バッファ４８５から他のバッファまで移動させる必要はない。これらは、単に読み出されて処理され、つまり、ＡＣＫまたはＵＬデータパケットとして特徴付けられて、転送用の優先順位を与えられるか、あるいは、ＵＬデータパケットの場合、ＵＬ受信バッファ４８５内のＵＬデータの所定の最大データ量を超えた場合には、廃棄する代わりに削除される。
【００６５】
本発明の一実施形態によれば、本明細書に記載のデータシェーピング法または装置を、データ接続のダウンリンク方向において用いる。
【００６６】
本発明の一実施形態によれば、本明細書に記載のデータシェーピング法または装置を、非対称データ接続の高速方向において用いる。
【００６７】
本発明の一実施形態によれば、本明細書に記載のデータシェーピング法または装置を、非対称データ接続の低速方向および高速方向において用いる。
【００６８】
本発明の一実施形態によれば、本明細書に記載のデータシェーピング法または装置を、対称データ接続において用いる。
【００６９】
本発明の一実施形態によれば、本明細書に記載のデータシェーピング法または装置を、対称データ接続の両方向において用いる。
【００７０】
本発明の一実施形態によれば、請求項のうちのいずれか１項によって規定される任意の実施形態を、他の１つまたは複数の各請求項によって規定される他の１つまたは複数の実施形態と組み合わせてよい。
【産業上の利用可能性】
【００７１】
本発明は、データトラフィックシェーピング方法、装置、およびワイヤレス機器に利用することができる。
【符号の説明】
【００７２】
４００  モデム
４１５  インターネット
４５０  Ａｐｐ１、Ａｐｐ２、…、Ａｐｐｎ
４５５  ＰＣ  ＴＣＰ／ＩＰスタック
４６０  プロトコルスタック
４６５  ＤＬ発信バッファ
４７０  ＰＣ  ＤＬバッファ
４７５  ＰＣ  ＵＬバッファ
４８５  ＵＬ受信バッファ
４９０  ＡＣＫバッファ
４９５  輻輳バッファ
５１０  マルチプレクサ
【図１】
2010148110.tif 000003
【図２】
2010148110.tif 000004
【図３】
2010148110.tif 000005
【図４】
2010148110.tif 000006