JP2011250223A - ゲートウェイ装置およびゲートウェイ装置におけるパケットバッファ管理方法 - Google Patents

Abstract

【課題】コネクション単位のパケット転送の最適化を可能にすることで、スループットを高めた無線ネットワークとコアネットワークに相互接続するゲートウェイ装置を提供する。
【解決手段】ゲートウェイ装置のパケット処理装置において、パケットバッファ管理部が、コネクション単位のパケット転送を一元管理する。コネクション単位のトラフィック状態およびパケットバッファ残量に基づいて、コネクション単位の最大ウィンドウサイズおよび広告ウィンドウサイズをダイナミックに増減することにより、パケット転送のスループットを向上させる。
【選択図】図１

Description

本発明は、ゲートウェイ装置に関する。特に、アプリケーションゲートウェイ装置におけるパケット処理装置のパケットバッファ管理方法に関する。

近年、携帯端末から、ネットワークを介して、動画や音声などのコンテンツを送受信することが盛んに行われている。図２に、ユーザが携帯端末を用いて、コンテンツサーバから、種々のサービスを受ける通信システムの構成例を示す。ここで、携帯端末とコンテンツサーバとの間に、アプリケーションゲートウェイ装置が入り、パケットデータの送受信を中継している。アプリケーションゲートウェイ装置とは、通信を中継するプロキシプログラムを使用することで、セキュリティを確保することを目的とした中継装置である。例えば、社内の端末からインターネット接続する場合、社内の端末は外部と直接接続せず、アプリケーションゲートウェイ装置を中継することにより、セキュリティ的に安全にＷｅｂサービスを利用することが可能である。携帯端末とコンテンツサーバとの接続においても、コンテンツ課金処理などの必要性からセキュリティの確保は重要であり、アプリケーションゲートウェイ装置を中継することにより、セキュリティを確保した通信が行われている。

図２に示すように、携帯端末４は、無線ネットワーク３を介して、アプリケーションゲートウェイ装置１３と接続される。一方、アプリケーションゲートウェイ装置１３は、コアネットワーク１４側で有線接続され、コンテンツサーバ２は、コアネットワーク１４に接続されている。このような構成は、モバイルコアネットワークと呼ばれている。送受信されるデータには、コンテンツサーバ２から携帯端末４へ向かって送信される下り方向のパケットデータの流れと、携帯端末からコンテンツサーバへ向かって送信される上り方向のパケットデータの流れがあるが、特に、下り方向のパケットデータのスループットが高いことが、求められる。例えば、コンテンツサーバ２のストリームデータは、下り方向のパケットデータとして流れ、アプリケーションゲートウェイ装置１３を中継し、無線ネットワーク３を介して、携帯端末４に送信され、携帯端末４において、動画や音声が再生される。

アプリケーションゲートウェイ装置１３のパケット処理装置１では、一端、パケットデータをパケットバッファに蓄積した後、処理が行われるが、パケットバッファのサイズは限られているので、コンテンツサーバ２から下り方向のパケットが大量に送られてきた場合、パケット処理装置１のバッファがオーバーフローしてしまう。そこで、受信側で、受信可能なパケットの量をウィンドウサイズとして送信側に知らせ、送信側は、受信可能な量のパケットのみを送るようにすることにより、バッファオーバーフローが起きないようにしている。このような方法を一般に、フロー制御という。

また、アプリケーションゲートウェイ装置１３は、複数の携帯端末４との通信を行うため、多くのＴＣＰコネクションが発生するが、従来は、全てのＴＣＰコネクションに対し、コネクション確立から切断まで、固定長の最大ウィンドウサイズを設定し、コネクション接続中は一定のサイズを保ったままウィンドウ制御を行っていた。図７に、パケットバッファのコネクション単位の最大ウィンドウサイズを示す。ここで、最大ウィンドウサイズとは、そのコネクションにおいて最大で使用することが可能なバッファサイズである。

ところで、複数のユーザが、携帯端末で、アプリケーションゲートウェイ装置を中継してコンテンツサーバと送受信する場合、ユーザによって、使用状況は様々である。例えば、あるユーザが、携帯端末で、動画閲覧を行う場合には、そのコネクションのパケット量は非常に多く、バッファサイズが少ないと動画が途切れる虞がある。一方、他のユーザが、データ量の少ないテキストデータのみを受信する場合には、そのコネクションのパケット量は少なく、バッファサイズも小さくて済む。

しかしながら、従来のアプリケーションゲートウェイ装置では、図７に示すように、コネクション毎に、共通のバッファサイズを割り当てていたので、パケット処理装置のスループットを上げようとした場合に、限界があった。

一方、ＴＣＰにおける輻輳制御方式の一つに、ＴＣＰ Ｖｅｇａｓという方式がある。これは、ラウンドトリップタイムの増加を輻輳検出に利用して、ネットワークのトラフィック状況に応じて、輻輳ウィンドウサイズを変更して、輻輳を防止するものである。特許文献１において、ＴＣＰ Ｖｅｇａｓの方式を改良し、急激なトラフィックの変化に対して追随できるように、輻輳ウィンドウサイズを変更する方法が開示されている。この方法によれば、トラフィック状況に応じて、輻輳ウィンドウサイズを変更することにより、輻輳がなく、且つ、有効な送受信が可能になる。

特開２００５−２１８０６９号公報

以下の分析は、本発明により与えられる。

しかしながら、特許文献１の方法では、輻輳ウィンドウサイズをトラフィック状況に応じて変更することにより、輻輳を防止し、有効な送受信が可能にはなるものの、コネクション単位で、最大ウィンドウサイズを制御していないため、複数のコネクションに対して、コネクション毎に、最適なパケットバッファを割り当てることはできず、パケット処理装置のスループットを向上するには限界があった。

ここで、従来のアプリケーションゲートウェイ装置の問題点は、コネクション単位で最大ウィンドウサイズを制御していないため、トラフィック量の多いコネクションに対しパケット転送のスループットを十分に向上させることができず、パケット処理装置のパケット転送処理能力を高めることができないということである。

そこで、本発明の目的は、パケット転送処理能力を高めたパケット処理装置を有するゲートウェイ装置を提供することである。

本発明の第１の側面によるゲートウェイ装置は、端末装置が接続される無線ネットワークと、サーバ装置が接続されるコアネットワークを相互接続するためのゲートウェイ装置であって、前記ゲートウェイ装置は、パケットデータを送受信するパケット処理装置を有し、前記パケット処理装置は、前記パケットデータを蓄積するパケットバッファと、前記パケットバッファを一元管理するパケットバッファ管理部を含み、前記パケットバッファ管理部は、コネクション単位のトラフィック状態および前記パケットバッファの残量に基づいて、前記コネクション単位の最大ウィンドウサイズおよび広告ウィンドウサイズを増減することを特徴とする。

本発明の第２の側面による通信システムは、端末装置と、前記端末装置と接続される無線ネットワークと、前記無線ネットワークと送受信するゲートウェイ装置と、前記ゲートウェイ装置と接続されるコアネットワークと、前記コアネットワークと接続されるサーバ装置とを含み、前記ゲートウェイ装置は、パケットデータを送受信するパケット処理装置を有し、前記パケット処理装置は、前記パケットデータを蓄積しておくパケットバッファと、コネクション単位のトラフィック状態および前記パケットバッファの残量に基づいて、前記コネクション単位の最大ウィンドウサイズおよび広告ウィンドウサイズを増減するパケットバッファ管理部を有することを特徴とする。

本発明の第３の側面によるパケット処理装置におけるパケットバッファ管理方法は、コネクション単位のトラフィック量を取得するステップと、前記パケットバッファの残量および前記コネクション単位のトラフィック量に基づいて、コネクション単位の最大ウィンドウサイズおよび広告ウィンドウサイズを増減するステップと、を含むことを特徴とする。

本発明によれば、以下の効果が得られる。
第１の効果は、パケット転送処理能力を高めたゲートウェイ装置を提供することができることである。その理由は、ゲートウェイ装置におけるパケットバッファ管理部で、コネクション単位のトラフィック状態、パケットバッファの残量に基づいて、コネクション単位の最大ウィンドウサイズをダイナミックに制御することで、トラフィック量の多いコネクションに対し、パケット転送のスループットを上げることができ、パケット処理装置あたりのパケット転送の処理能力を増やすことができるためである。

第２の効果は、端末装置と接続される無線ネットワークと、コアネットワークと接続されるサーバと、両者を中継するゲートウェイ装置とから構成される通信システムにおいて、パケットデータの転送処理能力を高めた通信システムを提供することができるということである。その理由は、ゲートウェイ装置におけるパケットバッファ管理部で、コネクション単位のトラフィック状態、パケットバッファの残量に基づいて、コネクション単位の最大ウィンドウサイズをダイナミックに制御することで、トラフィック量の多いコネクションに対し、パケット転送のスループットを上げることができ、パケット処理装置あたりのパケット転送の処理能力を増やすことができるためである。

第３の効果は、パケット転送処理能力を高めたパケット処理装置におけるパケットバッファの管理方法を提供することができるということである。その理由は、パケット処理装置において、コネクション単位のトラフィック状態、パケットバッファの残量に基づいて、コネクション単位の最大ウィンドウサイズをダイナミックに制御することで、トラフィック量の多いコネクションに対し、パケット転送のスループットを上げるように、パケットバッファの管理を行うことにより、パケット転送の処理能力を増やすことができるためである。

本発明の第１の実施形態のパケット処理装置の構成を示すブロック図である。 本発明のモバイルコアネットワークの構成装置を示すブロック図である。 本発明の第２の実施形態のパケットバッファ管理方法の動作を示すフローチャートである。 本発明の実施例１を説明するためのパケットバッファを表す図である。 本発明の実施例１を説明するためのコネクション管理テーブルを表す図である。 本発明の実施例１を説明するためのトラフィックテーブルを表す図である。 従来のパケットバッファを表す図である。 本発明の実施例１の動作を示すフローチャートである。 本発明の実施例１を説明するための図である。 本発明の実施例１を説明するための図である。 本発明の実施例１を説明するための図である。 本発明の実施例１を説明するための図である。

本発明の実施形態について、必要に応じて図面を参照して説明する。なお、実施形態の説明において引用する図面及び図面の符号は実施形態の一例として示すものであり、それにより本発明による実施形態のバリエーションを制限するものではない。

本発明の第１の側面によるゲートウェイ装置は、図１、図２に示すように、端末装置が接続される無線ネットワーク３と、サーバ装置が接続されるコアネットワーク１４を相互接続するためのゲートウェイ装置であって、ゲートウェイ装置は、パケットデータを送受信するパケット処理装置１を有し、パケット処理装置１は、パケットデータを蓄積するパケットバッファ６と、パケットバッファ６を一元管理するパケットバッファ管理部９を含み、パケットバッファ管理部９は、コネクション単位のトラフィック状態およびパケットバッファの残量１０に基づいて、コネクション単位の最大ウィンドウサイズおよび広告ウィンドウサイズを増減することを特徴とする。

本発明の第２の側面による通信システムは、図１、図２に示すように、端末装置と、端末装置と接続される無線ネットワーク３と、無線ネットワーク３と送受信するゲートウェイ装置と、ゲートウェイ装置と接続されるコアネットワーク１４と、コアネットワーク１４と接続されるサーバ装置とを含み、ゲートウェイ装置は、パケットデータを送受信するパケット処理装置１を有し、パケット処理装置１は、パケットデータを蓄積しておくパケットバッファ６と、コネクション単位のトラフィック状態およびパケットバッファの残量１０に基づいて、コネクション単位の最大ウィンドウサイズおよび広告ウィンドウサイズを増減するパケットバッファ管理部９を有することを特徴とする。

本発明の第３の側面によるパケット処理装置１におけるパケットバッファ管理方法は、図３に示すように、コネクション単位のトラフィック量を取得するステップＳ１と、パケットバッファの残量１０およびコネクション単位のトラフィック量に基づいて、コネクション単位の最大ウィンドウサイズおよび広告ウィンドウサイズを増減するステップＳ２と、を含むことを特徴とする。

以下、実施例について、図面を参照して詳しく説明する。

［実施例１の構成］
図２は、本発明の実施例１における通信システムのブロック図である。図２において、モバイルコアネットワークの構成装置であるアプリケーションゲートウェイ装置１３が示されている。図２において、アプリケーションゲートウェイ装置１３は、パケット処理装置１と呼処理装置５で構成される。パケット処理装置１はユーザプレーン処理を行う。また、呼処理装置５は制御プレーン処理を行う。アプリケーションゲートウェイ装置１３は有線インタフェースを具備し、対向装置（例えば、コンテンツサーバ２）と接続される。また、アプリケーションゲートウェイ装置１３は無線ネットワーク３との接続を制御し、対向装置（例えば、携帯端末４）と接続される。アプリケーションゲートウェイ装置１３は、コンテンツサーバ２と携帯端末４間のパケットデータの転送を行う。コンテンツサーバ２から送信される下り方向のＴＣＰパケットを受信し、携帯端末４へ転送し、携帯端末４から送信される上り方向のＴＣＰパケットを受信し、コンテンツサーバ２へ転送する。

図１を参照すると、図２に示すアプリケーションゲートウェイ装置１３におけるパケット処理装置１の詳細な構成が示されている。図１において、パケット転送部７はコンテンツサーバ２から下り方向のＴＣＰパケットを順次転送する。パケットバッファ管理部９はパケット処理装置１におけるパケットバッファの残量１０、接続している全てのＴＣＰコネクションの最大ウィンドウサイズと広告ウィンドウサイズをコネクション管理テーブル１１により一元管理する。パケットバッファ管理部９はパケット処理装置１におけるトラフィックを監視し、通過する全てのＴＣＰコネクションに対する送受信パケットデータの統計データをトラフィック情報として収集し、トラフィックテーブル１２により一元管理する。また、アプリケーションレイヤ処理部８はパケット転送部７と通信し、パケットデータのアプリケーションレイヤのプロトコル処理を行う。

以上、詳細に実施例の構成を述べたが、図２の呼処理装置５は、広く知られており、また本発明と直接関係しないので、その詳細な構成は省略する。

［実施例１の動作］
まず、図１のパケット処理装置の動作を説明する前に、ＴＣＰパケットの送受信におけるフロー制御について、以下に説明する。ＴＣＰの基本は、図９に示すように「ＴＣＰパケットを１つ送信し、ＡＣＫパケットを１つ受け取る」を繰り返すことである。この方法は、通信の信頼性は高いが、送信側は１つＴＣＰパケットを送るたびに、ＡＣＫが帰ってくるのを待たねばならず、通信効率が悪い。そこで、ＴＣＰでは、通信効率を上げるために、図１０に示すように、送信側は、ＴＣＰパケットをある数だけ連続して送り、受信側はまとめてＡＣＫを返すという方法が行われている。但し、受信側では、パケットバッファに空きがないと、まとめて送られてきたＴＣＰパケットを受信することができず、バッファオーバーフローが発生してしまう。

そこで、受信側が一度に連続して受信可能なデータサイズを、送信に知らせることで、送信側は一度に送るパケットの量を、受信側から知らされた量までに制限している。この受信側が一度に連続して受信可能なデータサイズのことを広告ウィンドウサイズという。ＴＣＰでは、図１１に示すように、スリーウェイハンドシェイクにより、コネクション確立を行うが、受信側はＳＹＮ＋ＡＣＫを送信側に返すときに、ＴＣＰヘッダのウィンドウサイズ領域に、広告ウィンドウサイズを書き込んで、送信側に送ることで、送信側に広告ウィンドウサイズを知らせている。

上述のＴＣＰの基本的なフロー制御に基づいて、実施例１のパケット処理装置１においけるＴＣＰコネクション確立時の動作について説明する。下り方向のパケットデータの流れにおいて、アプリケーションゲートウェイ装置１３は、コンテンツサーバ２からパケットデータ受信する。受信側では、受信したパケットデータをパケットバッファ６に蓄積する。コネクション接続が１つの場合、受信側の広告ウィンドウサイズは、パケットバッファの残量１０とすればよく、ＴＣＰコネクション確立時に、受信側が、ＳＹＮ＋ＡＣＫを送信側に返すときに、ＴＣＰヘッダのウィンドウサイズ領域に、パケットバッファの残量１０を書き込んで、送信側に知らせればよい。また、コネクションの途中で、パケットバッファの残量１０が少なくなった場合には、追随して、広告ウィンドウサイズを小さくし、送信側に更新した広告ウィンドウサイズを知らせればよい。

一方、ｎ個のＴＣＰコネクション接続がなされている場合には、式（１）に示すように、全てのコネクションの広告ウィンドウサイズの総和が、パケットバッファの残量１０以下になるようにする。

図４に、ｎ個のコネクション接続がある場合のパケットバッファ６の状態を示す。ここで、ｎ個のコネクションの広告ウィンドウサイズの合計が、パケットバッファの残量１０より小さくなるように、パケットバッファ管理部９が一元管理する。

もし、パケットバッファの残量１０が少なくなり、全コネクションの広告ウィンドウサイズの合計より小さくなってしまった場合は、パケットバッファ管理部９は、コネクション単位の広告ウィンドウサイズを減少する対応を行い、バッファオーバーフローが生じないようにする。

また、もし、パケットバッファの残量１０が、０になった場合は、パケットバッファ管理部９は、全てのコネクションの広告ウィンドウサイズを０にして、送信側に知らせ、パケットバッファの送信を待ってもらうと共に、新規のＴＣＰコネクションの生成を禁止する。そして、ある時間の経過後に、パケットバッファの残量１０が増加してきたところで、それに応じて、広告ウィンドウを増やしていき、パケットデータの送信、あるいは新規コネクションの生成を再開する。

また、コネクション確立時には、各コネクションが、使用可能なパケットバッファの上限値である最大ウィンドウサイズを設定する。コネクション確立時に、送信側からのデータ量が多いと判断される場合には、パケットバッファ管理部９は、最大ウィンドウサイズを大きな値に設定し、一方、データ量が少ないと判断される場合には、小さな値に設定する。例えば、動画閲覧を含むコネクションの場合には、最大ウィンドウサイズを大きな値に設定し、データ量の少ないテキストデータの受信のみのコネクションの場合には、最大ウィンドウサイズを小さな値に設定する。

パケットバッファ管理部９は、前述のコネクション単位の最大ウィンドウサイズと広告ウィンドウサイズの関係が、以下の式（２）の条件を満たすようにしなければならない。

広告ウィンドウサイズ≦最大ウィンドウサイズ 式（２）

このようにして、パケットバッファ管理部９が決定したコネクション確立時の最大ウィンドウサイズおよび広告ウィンドウサイズは、パケットバッファ管理部９のコネクション管理テーブル１１に保存される。また、コネクション確立後に、最大ウィンドウサイズまたは広告ウィンドウサイズが変更される度に、コネクション管理テーブル１１は更新される。また、パケットバッファの残量１０も、コネクション管理テーブル１１に同時に保存される。

また、コネクション単位のメモリ管理は、あるコネクションに、最大ウィンドウサイズが設定された場合、パケットバッファ９のメモリマップ上に最大ウィンドウサイズの領域を固定で割り当てるのではなく、使用するメモリサイズをパケットバッファサイズに占める一部として管理する。それにより、コネクション途中において最大ウィンドウサイズを動的に増減することが可能になる。

次に、コネクション確立後に、コンテンツサーバ２よりアプリケーションゲートウェイ装置１３に対し、下り方向のデータが流れている場合について、それらの動作を説明する。

パケットバッファ６はパケット処理装置１を通過する全てのＴＣＰコネクションのパケットデータが単一のバッファプールに蓄積される。パケットバッファの残量１０はパケット転送部７からのパケットデータの受信またはアプリケーションレイヤ処理部８へのパケットデータの送信によって、増減し、算出される。算出されたパケットバッファの残量１０はパケットバッファ管理部９のコネクション管理テーブル１１に設定される。パケット処理装置１にてコンテンツサーバ２から下り方向のＴＣＰパケットを受信すると、パケット転送部７は広告ウィンドウサイズ以内のパケットデータを受信し、パケットバッファ６にパケットデータを書き込む。書き込まれたパケットデータはパケットバッファ６を使用するため、パケットバッファの残量１０は減算される。書き込まれたパケットデータはソケット経由でアプリケーションレイヤ処理部８へ送信される。パケットデータがパケットバッファ６からアプリケーションレイヤ処理部８に送信された段階で、パケットバッファの残量１０は増加する。アプリケーションレイヤ処理部８では、例えば、キャリアで必要なコンテンツ課金処理のため、加入者を識別する番号（端末ＩＤ）の付加／削除や、コンテンツの内容に応じた金額の付与／削除などを行っている。アプリケーションレイヤ処理部８での処理が終わった後、処理済みのデータを受けてパケットデータとし、パケットバッファ６に入れる。この段階で、パケットバッファの残量は減少する。次に、このパケットバッファは、アプリケーションゲートウェイ装置１３と携帯端末４で確立されたコネクションにより、無線ネットワーク３を介し、携帯端末４に送信される。

パケットバッファ管理部９はコネクション管理テーブル１１により、全てのＴＣＰコネクションのパケットバッファの使用を一元管理する。パケットバッファ管理部９はパケット転送部７と双方向の制御インタフェースで通信を行い、接続する全てのＴＣＰコネクションに対する最大ウィンドウサイズおよび広告ウィンドウサイズをコネクション管理テーブル１１に設定する。図５にパケットバッファ管理部９で管理するコネクション管理テーブル１１の一例を示す。

パケットバッファ管理部９はパケット処理装置１のトラフィック情報を基に、パケット処理装置１の負荷状況を管理するトラフィックテーブル１２を作成し、一元管理する。作成されたトラフィックテーブル１２はパケット処理装置１のメモリに登録する。パケットバッファ管理部９はパケット転送部７と双方向の制御インタフェースで通信を行い、通過する全てのＴＣＰコネクションに対する送受信パケットデータのパケット長、パケット数、通信データ量を統計データとして、制御インタフェース経由でパケットバッファ管理部９に定期的（例えば、１秒ごと）に送信する。図６にパケットバッファ管理部９で管理するトラフィックテーブル１２の一例を示す。パケットバッファ管理部９はパケット処理装置１におけるトラフィックを監視し、統計データを収集し、トラフィックテーブル１２を作成する。

次に、コネクション確立後の最大ウィンドウサイズと広告ウィンドウサイズの増減に関し、図８のフローチャートを参照し説明する。まず、パケット処理装置１にてパケットデータを受信すると、パケット転送部から制御インタフェース経由でパケットバッファ管理部９へアクセスし、図８のステップＳ１１のトラフィックテーブル１２の読み出しと、全トラフィック量の算出を行う。次に、ステップ１２で、全トラフィック量を所定の値Ｔ１と比較する。参照したトラフィックテーブル１２の統計データをもとに、パケット処理装置１における全トラフィック量が所定の値Ｔ１よりも少ないと判断すると、ステップＳ１３で、トラフィックテーブル１２を基にトラフィックの多いコネクションに対し、優先的に、設定している最大ウィンドウサイズを増加する。ここで、トラフィックは、コンテンツサーバとアプリケーションゲートウェイ間の伝送帯域をフルに使用したときを１００％とし、それに対する現状の使用比率で計算する。例えば、トラフィックが３０％以下の場合、トラフィックが少ないと判断する。

また、ステップＳ１３における最大ウィンドウサイズの増加量の算出方法は、例えば、全コネクションの最大ウィンドウサイズの合計が、パケットバッファサイズを超えない範囲で、全体として増加する全増加量を決定し、その後、図１２に示すテーブルにより規定されるトラフィックに応じた増分比率を得て、その増分比率に基づいて、最大ウィンドウサイズの全増加量を各コネクションに対し配分することにより、各コネクションの最大ウィンドウサイズの増加量を得る。そうすることにより、トラフィックの多いコネクションに対して優先的に最大ウィンドウサイズを増加させることができるので、効率的にパケット処理装置１のパケット転送処理能力を向上させることができる。そして、現在の最大ウィンドウサイズを増加量だけ増加して、新たな最大ウィンドウサイズとして設定し、コネクション管理テーブル１１における最大ウィンドウサイズを更新する。

一方、ステップＳ１２における比較において、全トラフィック量が、所定の値Ｔ１より小さくない場合には、ステップＳ１４において、各コネクションにおける最大ウィンドウサイズをコネクション確立時に設定した最大ウィンドウサイズに戻し、コネクション管理テーブル１１における最大ウィンドウサイズを更新し、上記動作を繰り返す。ここで、図５に示すように、コネクション確立時の最大ウィンドウサイズは、更新されていく最大ウィンドウサイズとは別に、コネクション管理テーブル１１に記憶しておき、そこから読み出して参照する。

次に、ステップＳ１５およびＳ１６で、コネクション管理テーブル１１を参照し、パケットデータのセグメント受信時点での接続している全てのＴＣＰコネクションで設定されている広告ウィンドウサイズの総和とパケットバッファの残量１０と比較する。具体的には、ステップＳ１５に示すように、パケットバッファの残量１０から広告ウィンドウの総和を引いた値ｅｖａｌを算出し、ｅｖａｌが、０〜εの間にある場合は、広告ウィンドウサイズの総和が適正であると判断する。εは、正の数で、広告ウィンドウサイズの総和をパケットバッファの残量に近づける際の許容値である。また、ｅｖａｌがεより大きい場合には、広告ウィンドウサイズの総和を増やすと判断し、ステップＳ１７で、広告ウィンドウサイズを増加する。ここで、コネクション毎の広告ウィンドウサイズの増加は、ステップＳ１３と同様に、図１２のトラフィック量に対する増分比率を用いて、トラフィックの多いコネクションに対して、優先的に広告ウィンドウサイズを増加することが望ましい。また、ｅｖａｌが、０より小さい場合には、式（１）の条件が満たされておらず、バッファオーバーフローが発生する虞があるため、ステップＳ１８で、コネクション毎の広告ウィンドウサイズを減少する。ステップＳ１６、Ｓ１７、Ｓ１８の後、ステップＳ１９でタイマ処理により、一定時間おいた後、ステップＳ１１に戻って、処理を繰り返す。

ここで、ステップＳ１３、Ｓ１４、Ｓ１７、Ｓ１８において、最大ウィンドウサイズ、または、広告ウィンドウサイズを変更した場合には、コネクション管理テーブルを更新する。また、同時にパケットバッファの残量１０もコネクション管理テーブルに保存する。

以上のように、ステップＳ１１〜Ｓ１９の上記動作を繰り返し、パケットバッファの残量１０とコネクション管理テーブル１１とトラフィックテーブル１２を一元管理し、パケット処理装置１におけるトラフィックを監視し、ＴＣＰコネクションごとの最大ウィンドウサイズをダイナミックに制御すると共に、広告ウィンドウサイズをパケットバッファの残量との関係から最適な量になるように調整する。

図８のフローチャートにおいて、全トラフィック量が所定の値Ｔ１より小さいときのみ、最大ウィンドウサイズの増加、あるいは、広告ウィンドウサイズの増減を行っているが、例えば、ステップＳ１２、Ｓ１４を削除し、常に、ステップＳ１３を実行させるようにしてもよい。また、ステップＳ１３を、増加処理だけでなく、コンテンツ単位のトラフィック量に基づいて、増加、または、減少するようにしてもよい。その他、トラフィック量に応じて、最大ウィンドウサイズおよび広告ウィンドウサイズを増減する様々なバリエーションの構成が可能である。

以上のように、本発明によれば、例えば、トラフィックの少ない時間帯に、一時的に、大量のパケットデータ通信を必要とするコネクションに対して、コネクション確立時にＴＣＰコネクション単位で設定した最大ウィンドウサイズを優先的に拡張することができ、パケット処理装置を通過するトラフィックモデルの変動に応じて、パケット処理装置あたりのパケット転送のスループットを増やすことができ、パケット処理装置のパケット処理能力を最大化することができる。

また、通信するパケットデータの量に応じて、ユーザのコネクションのパケット転送のスループットを増やすことができ、携帯端末を利用するユーザに対して、最適なスループットを確保した通信を提供することができる。

また、パケット処理装置としてパケットバッファに割り当てていたメモリの使用量を少なくすることができ、パケット処理装置を小型化することができる。

本発明は、複数のＴＣＰコネクションに対してパケット転送を最適化するネットワーク伝送に広く適用できる。具体的には、ネットワーク接続された複数の携帯端末におけるデータ通信などに有用である。

なお、本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

１ パケット処理装置
２ コンテンツサーバ
３ 無線ネットワーク
４ 携帯端末
５ 呼処理装置
６ パケットバッファ
７ パケット転送部
８ アプリケーションレイヤ処理部
９ パケットバッファ管理部
１０ パケットバッファの残量
１１ コネクション管理テーブル
１２ トラフィックテーブル
１３ アプリケーションゲートウェイ装置
１４ コアネットワーク

Claims (10)

1. 端末装置が接続される無線ネットワークと、サーバ装置が接続されるコアネットワークを相互接続するためのゲートウェイ装置であって、
   前記ゲートウェイ装置は、パケットデータを送受信するパケット処理装置を有し、
   前記パケット処理装置は、前記パケットデータを蓄積するパケットバッファと、前記パケットバッファを一元管理するパケットバッファ管理部を含み、
   前記パケットバッファ管理部は、コネクション単位のトラフィック状態および前記パケットバッファの残量に基づいて、前記コネクション単位の最大ウィンドウサイズおよび広告ウィンドウサイズを増減することを特徴とするゲートウェイ装置。
2. 前記コネクション単位のトラフィック量の合計である全トラフィック量が、所定の値よりも少ない場合に、前記パケットバッファ管理部は、コネクション単位の最大ウィンドウサイズを増加し、
   さらに、前記パケットバッファの残量が、前記広告ウィンドウサイズの総和より大きい場合には、前記パケットバッファ管理部は、前記コネクション単位の広告ウィンドウサイズを増加し、
   前記パケットバッファの残量が、前記広告ウィンドウサイズの総和より小さい場合には、前記パケットバッファ管理部が、前記広告ウィンドウサイズを減少することを特徴とする請求項１に記載のゲートウェイ装置。
3. 前記コネクション単位の最大ウィンドウサイズ、または、広告ウィンドウサイズを増加する場合、前記コネクション単位のトラフィック量の多いコネクションに対して、優先的に増加させることを特徴とする請求項１または２に記載のゲートウェイ装置。
4. 前記パケットバッファ管理部において、前記最大ウィンドウ、前記広告ウィンドウを、コネクション管理テーブルで管理し、
   前記トラフィック量を、トラフィックテーブルで管理することを特徴とする請求項１乃至３のいずれか１項に記載のゲートウェイ装置。
5. 端末装置と、
   前記端末装置と接続される無線ネットワークと、
   前記無線ネットワークと送受信するゲートウェイ装置と、
   前記ゲートウェイ装置と接続されるコアネットワークと、
   前記コアネットワークと接続されるサーバ装置とを含み、
   前記ゲートウェイ装置は、パケットデータを送受信するパケット処理装置を有し、
   前記パケット処理装置は、前記パケットデータを蓄積しておくパケットバッファと、
   コネクション単位のトラフィック状態および前記パケットバッファの残量に基づいて、前記コネクション単位の最大ウィンドウサイズおよび広告ウィンドウサイズを増減するパケットバッファ管理部を有することを特徴とする通信システム。
6. 前記コネクション単位のトラフィック量の合計である全トラフィック量が、所定の値よりも少ない場合に、
   前記パケットバッファ管理部は、コネクション単位の最大ウィンドウサイズを増加し、
   さらに、前記パケットバッファの残量が、前記広告ウィンドウサイズの総和より大きい場合には、前記パケットバッファ管理部が、前記コネクション単位の広告ウィンドウサイズを増加し、
   前記パケットバッファの残量が、前記広告ウィンドウサイズの総和より小さい場合には、前記パケットバッファ管理部が、前記広告ウィンドウサイズを減少することを特徴とする請求項５に記載の通信システム。
7. 前記コネクション単位の最大ウィンドウサイズ、または、広告ウィンドウサイズを増加する場合、前記コネクション単位のトラフィック量の多いコネクションに対して、優先的に増加させることを特徴とする請求項５または６に記載の通信システム。
8. コネクション単位のトラフィック量を取得するステップと、
   前記パケットバッファの残量および前記コネクション単位のトラフィック量に基づいて、コネクション単位の最大ウィンドウサイズおよび広告ウィンドウサイズを増減するステップと、を含むことを特徴とするパケット処理装置におけるパケットバッファ管理方法。
9. 前記コネクション単位のトラフィック量の合計である全トラフィック量を所定の値と比較する第１の比較ステップと、
   前記第１の比較ステップにおいて、全トラフィック量が所定の値より小さい場合に、最大ウィンドウサイズを増加するステップと、
   前記パケットバッファ残量と、前記コネクション単位の広告ウィンドウサイズの総和を比較する第２の比較ステップと、
   前記第２の比較ステップにおいて、前記パケットバッファ残量が、前記コネクション単位の広告ウィンドウサイズの総和より大きい場合に、広告ウィンドウサイズを増加するステップと、
   前記第２の比較ステップにおいて、前記パケットバッファ残量が、前記コネクション単位の広告ウィンドウサイズの総和より小さい場合に、広告ウィンドウサイズを減少するステップと、を含むことを特徴とする請求項８に記載のパケット処理装置におけるパケットバッファ管理方法。
10. 前記コネクション単位の最大ウィンドウサイズ、または、広告ウィンドウサイズを増加する場合、前記コネクション単位のトラフィック量の多いコネクションに対して、優先的に増加させることを特徴とする請求項８または９に記載のパケット処理装置におけるパケットバッファ管理方法。

Images