(57)【要約】【課題】  モバイルアドホックネットワーク環境で最適の転送率を探すための調節方法を提供する。【解決手段】  現在転送率（ｃｕｒ＿ｂｗ）と以前転送率（ｂａｓｅ＿ｂｗ）との差値（Ｄｉｆｆ）を計算する第１段階と、以前転送率の標準偏差（ｂａｓｅｂｗ＿ｖａｒ）を計算して上限臨界値および下限臨界値を設定する第２段階と、差値と上下限臨界値との大きさを比較した結果によって以前転送率を現在転送率にアップデートする第３段階と、を含むことを特徴とするモバイルアドホックネットワーク環境で最適の転送率を探すための調節方法。【選択図】  図５
2005124154.tif 000002
【特許請求の範囲】
【請求項１】
転送制御プロトコルで転送率を調節する方法において、
現在転送率（ｃｕｒ＿ｂｗ）と以前転送率（ｂａｓｅ＿ｂｗ）との差値（Ｄｉｆｆ）を計算する第１段階と、
前記以前転送率の標準偏差（ｂａｓｅｂｗ＿ｖａｒ）を計算して上限臨界値および下限臨界値を設定する第２段階と、
前記差値と前記上下限臨界値との大きさを比較した結果によって前記以前転送率を前記現在転送率にアップデートする第３段階と、を含むことを特徴とするモバイルアドホックネットワーク環境で最適の転送率を探すための調節方法。
【請求項２】
前記以前転送率は数式(1)によって算出され、
【数１】
2005124154.tif 000008
前記現在転送率は数式(2)により算出され、
【数２】
2005124154.tif 000009
前記差値は数式(3)により算出され、
【数３】
2005124154.tif 000010
前記ｃｗｎｄは混雑ウィンドウ値、前記ｂａｓｅＲＴＴは以前時間に測定されたデータ往復転送にかかる時間値、そして、前記ｃｕｒＲＴＴは現在のデータ往復転送にかかる時間値であることを特徴とする請求項１に記載のモバイルアドホックネットワーク環境で最適の転送率を探すための調節方法。
【請求項３】
前記以前転送率の標準偏差は、
数式(4)により算出され、
【数４】
2005124154.tif 000011
前記αは加重値平均のパラメータであり、
【数５】
2005124154.tif 000012
数式(5)は以前時間値での標準偏差であることを特徴とする請求項１に記載のモバイルアドホックネットワーク環境で最適の転送率を探すための調節方法。
【請求項４】
前記第３段階は、差値が正数である場合には前記差値を前記上限臨界値とその大きさを比較し、差値が負数である場合には前記差値を前記下限臨界値とその大きさを比較した後、前記以前転送率を前記現在転送率にアップデートする段階であることを特徴とする請求項１ないし３のうちいずれか１項に記載のモバイルアドホックネットワーク環境で最適の転送率を探すための調節方法。
【請求項５】
前記第３段階は、前記差値が正数でありかつ前記上限臨界値より大きい場合には混雑ウィンドウ値を増加させた後に前記以前転送率を前記現在転送率にアップデートし、前記差値が負数でありつつ前記下限臨界値より大きい場合には混雑ウィンドウ値を変動させずに前記以前転送率を前記現在転送率にアップデートする段階であることを特徴とする請求項４に記載のモバイルアドホックネットワーク環境で最適の転送率を探すための調節方法。
【請求項６】
前記第２段階は、前記上限臨界値及び下限臨界値を数式(6)に設定する段階であり、
【数６】
2005124154.tif 000013
前記第３段階は、前記差値が正数でありかつ前記上限臨界値より大きい場合には混雑ウィンドウ値を増加させた後に前記以前転送率を前記現在転送率にアップデートし、前記差値が負数でありつつ前記下限臨界値より小さな場合には混雑ウィンドウ値を減少させた後に前記以前転送率を前記現在転送率にアップデートする段階であることを特徴とする請求項１に記載のモバイルアドホックネットワーク環境で最適の転送率を探すための調節方法。
【請求項７】
前記第３段階は、前記混雑ウィンドウ値が遅い開始臨界値より小さい場合には前記混雑ウィンドウ値を前記遅い開始臨界値に調節する段階を含むことを特徴とする請求項６に記載のモバイルアドホックネットワーク環境で最適の転送率を探すための調節方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はモバイルアドホックネットワーク環境で最適の転送率を探すための調節方法に係り、より詳細には現在転送率（ｃｕｒ＿ｂｗ）と以前転送率（ｂａｓｅ＿ｂｗ）との差値（Ｄｉｆｆ）を計算し、以前転送率の標準偏差（ｂａｓｅｂｗ＿ｖａｒ）を計算して上限臨界値および下限臨界値を設定した後、その差値とその上下限臨界値との大きさを比較した結果によって混雑ウィンドウ値（ｃｏｎｇｅｓｔｉｏｎ ｗｉｎｄｏｗ；以下、ｃｗｎｄ）を増加または減少させた後、以前転送率を現在転送率にアップデートすることによってアドホックネットワーク環境に最適の転送率調節技法を提供する。
【背景技術】
【０００２】
従来の公開特許としては特許文献１があるが、これは混雑ウィンドウｃｗｎｄの線形的な増減とともに指数的増減を共に考慮することによって転送制御プロトコルベガス（ＴＣＰ−ｖｅｇａｓ）の収斂速度を改善してＴＣＰの性能を向上させたＴＣＰ−Ｖｅｇａｓの混雑制御方法に関する。
【０００３】
また、特許文献２はχ１、χ２をαおよびβに追加することによってネットワークの急激な混雑を減らしてネットワークを効率的に使用可能にしたＴＣＰ−Ｖｅｇａｓを利用した転送制御プロトコルの混雑制御方法に関する。
そして、さらに特許文献３および４などがある。
【０００４】
モバイルアドホックネットワーク（Ｍｏｂｉｌｅ ａｄ ｈｏｃ ｎｅｔｗｏｒｋ、以下、ＭＡＮＥＴ）環境とは、固定されたインフラ構造なしに必要により動的に形成されるネットワークが移動端末を中心に形成されるネットワーク環境をいうが、図１はアドホックネットワークシステムを示す概念図である。ＩＥＥＥ ８０２．１１を使用するＭＡＮＥＴでは通信チャンネルをあらゆるノードが共有するようになる。
【０００５】
したがって、同じ通信領域内にあるあらゆるノードは同じチャンネルを通じて通信するため、転送されたデータが互いに衝突したり遺失されやすくなり、無線ネットワークの特性上リンク階層の転送信頼度が大きく落ちてしまう。送信者は受信者にパケットを転送し、受信者は前記転送されたパケットに対するＡＣＫ−応答パケットを送信者に転送する。この時、ＡＣＫ−応答パケットには受信者が現在まで受信した連続的なパケットのシーケンス番号の最大値に関する情報が含まれているので一部のＡＣＫ−応答パケットが遺失されても送信者が転送する量は減少しない。
【０００６】
ＴＣＰは、ＴＣＰ／ＩＰアーキテクチャのうち転送層に属するプロトコルであって、主にデータのフローおよびエラーの制御を担当している。特に、ＴＣＰはアプリケーションにより転送されるデータがバッファに保存されればウィンドウのサイズほどのみ転送される。この時、ウィンドウのサイズは宛先ホストまたはネットワーク混雑度により決定されて増加または減少する。特にＴＣＰではスライディングウィンドウ方式を利用するが、このようなウィンドウ概念を利用することによって無線リンクの使用性を極大化できる。
【０００７】
従来技術としてＴＣＰ混雑制御アルゴリズムは、初期に転送率を単純に指数的に増加させることによって混雑状態が急激に発生し、その混雑状態で転送率を無条件半分に減らすことによってネットワークを効率的に使用できなかった。
【０００８】
一方、図２Ａは従来技術によるＴＣＰ−Ｒｅｎｏバージョンでの転送率変化を示す図面であり、図２Ｂは従来技術によるＴＣＰ−Ｖｅｇａｓバージョンでの転送率変化を示す図面である。既存のＴＣＰは転送量を調節する段階を２段階に大別する。
【０００９】
第１の段階は使用可能な帯域幅を探す段階であって遅い開始段階と呼ぶ（図２Ａ参照）。使用可能な帯域幅を探すまで速い速度で転送量を増やしつつネットワーク状態を確認する。転送量を増やすうちにあらかじめ定義された遅い開始臨界値を超えれば、ネットワークの状態によって転送量を調節する段階に入る。この段階を混雑回避段階と呼ぶが、この段階では転送量を徐々に増加させる。
【００１０】
遅い開始段階ではデータ往復転送にかかる時間値（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ、以下、ＲＴＴ）当り以前のｃｗｎｄを２倍ずつ増加させる。一方、混雑回避段階ではＲＴＴ当り１パケットをさらに送るようにｃｗｎｄを増加させる。これを示す図面が図２Ａである。
【００１１】
ＴＣＰ−ＶｅｇａｓバージョンではＲＴＴを基準に可用帯域幅および現在使用中の帯域幅を計算する。現在使用中の帯域幅が可用帯域幅より非常に小さな場合には転送率を高めて可用帯域幅を最大にし、現在使用中の帯域幅が最大帯域幅に近接な場合には転送率を減らしてネットワークになるべく少ないパケットが保持されるように努力する。これを示す図面が図２Ｂである。
【００１２】
しかし、このような従来の転送方式は、ネットワークに転送可能な量以上のデータを転送して損失を発生させて初めて転送率を調節できるため、大きい負担がある。特に、アドホックネットワークの特性上、転送可能なデータの量は有線ネットワークとは違って状況により大きく変わる。リンク階層では衝突を回避するための技法だけでなく再転送メカニズムも持っているために、パケット損失が発生するまで転送率を持続的に増加させることは全体ネットワークに大きい負荷を与え、かつＴＣＰの連続するタイムアウトを引き起こす。このような動作は結局ネットワーク資源の使用効率を大きく落とす結果を招く。
【００１３】
一方、図３は従来技術によるＴＣＰ−ＲｅｎｏバージョンおよびＴＣＰ−Ｖｅｇａｓバージョンでの転送失敗パケットの数を比較した図表である。ＴＣＰ−Ｖｅｇａｓバージョンのような転送率調節方式はアドホックネットワークで大きい長所を持つが、与えられた統計資料からみれば（図３参照）、ＴＣＰ−Ｖｅｇａｓもネットワークで捨てられるパケットの数においてはあまり差がないことが確認できる。
【００１４】
パケット転送の失敗回数が多くなるほどネットワーク資源は効率的に使用されなくなり、パケット転送の失敗は他のセッションの転送までも妨害する問題をもたらす。アドホックネットワークでバックグラウンドトラフィックが存在する場合に前記の問題はさらに深刻になる。また、Ｖｅｇａｓバージョンの場合、ＡＣＫパケットが到着するまでの時間をＲＴＴで測定するが、ＡＣＫパケットの発生は既存の有線網での水準を維持するために無線ネットワークの資源使用（リンク使用）が必要以上に過度になる問題があった。さらにそれを基づいて転送量調節をするためにそれを直すことは合理的でない。
【特許文献１】大韓民国特許公開第２００１−０５８１１９号公報
【特許文献２】大韓民国特許公開第２００３−０４４４６５号公報
【特許文献３】米国特許公開第２００２−０１５４６０２号公報
【特許文献４】日本特開平１１−１７７６１８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１５】
本発明は前記問題点を解決するためになされたものであり、本発明の目的は、従来のＴＣＰ転送量調節技法を修正してＴＣＰのネットワーク資源使用量を最大化し、かつ衝突を減らす技法を受け入れることによってＭＡＮＥＴ環境で最適の転送率を探すための調節方法を提供するところにある。
【課題を解決するための手段】
【００１６】
前述した目的を達成するための本発明の一実施例によるＭＡＮＥＴ環境で最適の転送率を探すための調節方法は、ｃｕｒ＿ｂｗとｂａｓｅ＿ｂｗとのＤｉｆｆを計算する第１段階と、前記ｂａｓｅｂｗ＿ｖａｒを計算して上限臨界値および下限臨界値を設定する第２段階と、前記差値と前記上下限臨界値との大きさを比較した結果によって前記以前転送率を現在転送率にアップデートする第３段階と、を含むことを特徴とする。
【００１７】
また、前記以前転送率は数式(7)によって算出され、前記現在転送率は数式(8)により算出され、前記差値は数式(9)により算出され、前記ｃｗｎｄは混雑ウィンドウ値、前記ｂａｓｅＲＴＴは以前時間に測定されたデータ往復転送にかかる時間値、そして、前記ｃｕｒＲＴＴは現在のデータ往復転送にかかる時間値であることを特徴とする。
【００１８】
【数１】
2005124154.tif 000003
【００１９】
また、前記以前転送率の標準偏差は、数式(10)により算出され、前記αは加重値平均のパラメータであり、数式(11)は以前時間値での標準偏差であることを特徴とする。
【００２０】
【数２】
2005124154.tif 000004
【００２１】
また、前記第３段階は、差値が正数である場合には前記差値を上限臨界値とその大きさを比較し、差値が負数である場合には前記差値を下限臨界値とその大きさを比較した後、前記以前転送率を前記現在転送率にアップデートする段階であることを特徴とする。
【００２２】
また、前記第３段階は、前記差値が正数でありかつ前記上限臨界値より大きい場合にはｃｗｎｄを増加させた後に前記以前転送率を前記現在転送率にアップデートし、前記差値が負数でありつつ前記下限臨界値より大きい場合にはｃｗｎｄを変動させずに前記以前転送率を前記現在転送率にアップデートする段階であることを特徴とする。
【００２３】
また、前記第２段階は、前記上限臨界値及び下限臨界値を数式(12)に設定する段階であり、前記第３段階は、前記差値が正数でありかつ前記上限臨界値より大きい場合にはｃｗｎｄを増加させた後に前記以前転送率を前記現在転送率にアップデートし、前記差値が負数でありつつ前記下限臨界値より小さな場合にはｃｗｎｄを減少させた後に前記以前転送率を前記現在転送率にアップデートする段階である。
【００２４】
【数３】
2005124154.tif 000005
【００２５】
この場合、前記第３段階は、前記ｃｗｎｄが遅い開始臨界値より小さい場合には前記ｃｗｎｄを遅い開始臨界値に調節する段階を含むことが望ましい。
【発明の効果】
【００２６】
本発明によれば、現在状態での最適の転送量を探すための方式を提案して図４のようにネットワーク状態による最適の転送量を追跡できるネットワーク転送量予測をし、これに基づいて転送率を調節してアドホックネットワークの転送量を増加させ、無線ＬＡＮを利用することによるアドホックネットワークの性能低下現象を防止する効果がある。
また、ネットワークのパケット遺失はさらに少なくなり、スループットは高い状態を維持するため、既存の方法よりネットワークの資源使用がさらに効率的であり、特にバックグラウンドトラフィックが増加する時も同じ効果を奏する。
【発明を実施するための最良の形態】
【００２７】
以下、本発明によるＭＡＮＥＴ環境で最適の転送率を探すための調節方法に対して図面を参照して詳細に説明する。
図４は、現在スループットと最大スループットとを比較したグラフである。図４に図示されたように、アドホックネットワークでは経時的に最大スループット４０が大きく変化することが分かり、現在スループット４２との比較を通じてネットワーク状態変化を予測することによってＴＣＰ送信側で転送率を調節できる。したがって、現在スループット４２を調節する技法が非常に重要であることが分かる。
【００２８】
図５は、本発明の一実施例によるＭＡＮＥＴ環境で最適の転送率を探すための調節方法を示すフローチャートであり、図６は本発明のまた他の一実施例によるＭＡＮＥＴ環境で最適の転送率を探すための調節方法を示すフローチャートである。
ＴＣＰの送信者はデータを１回に１パケットずつ転送せずにネットワークが耐えられるほどの量だけ転送するが、これはｃｗｎｄによって調節される。
【００２９】
転送は２段階に分けられて実行される。転送初期には遅い開始段階が始まる。この時には適切なネットワークの帯域幅を探すことを目的とする。ＲＴＴ当り転送量があらかじめ定義された値（ｓｓｔｈｒｅｓｈ）以上になれば、ネットワークの状態によって混雑を少なく発生させうる状態を探すために混雑ウィンドウを調節する混雑回避段階に入る。初期の遅い開始段階の過程を説明するものが図５であり、混雑回避段階の過程を説明するものが図６である。
【００３０】
新しいＡＣＫを受けたＴＣＰ送信者は現在転送率を数式(14)に決定する（ｃｕｒＲＴＴは現在のデータ往復転送にかかる時間値である）。最初のパケット交換時期には使用可能な帯域幅の初期値である以前転送率を数式(15)（ｂａｓｅＲＴＴは以前時間に測定されたデータ往復転送にかかる時間値）に計算し、初期ｂａｓｅ＿ｂｗ値が設定された以後にはｃｕｒ＿ｂｗは持続的にアップデートされ、ｂａｓｅ＿ｂｗの値はｂａｓｅ＿ｂｗのアップデートが必要な場合に限ってｃｕｒ＿ｂｗ値により定める。その後、ｃｕｒ＿ｂｗとｂａｓｅ＿ｂｗとの差であるＤｉｆｆ値を計算する（Ｓ５００、Ｓ６００）。Ｄｉｆｆ値はｃｕｒ＿ｂｗからｂａｓｅ＿ｂｗを引いた値であって、現在ネットワークの状態を把握するために使用する。Ｄｉｆｆ値の計算は毎パケットの交換時になされるが、実際ＲＴＴ値が変化しない場合が多く、Ｄｉｆｆ値が実際変化する時点はＲＴＴがアップデートされる時点である。
【００３１】
【数４】
2005124154.tif 000006
【００３２】
現在ネットワークの状態に関する情報を得てその資料に基づいて遅い開始段階および混雑回避段階でそれぞれ次のような行動をとることによってネットワークの負荷を減らしつつも最大の帯域幅を使用できる構造を得る。遅い開始段階および混雑回避段階での状態変化を判断するための２つの臨界値を設定するが、ｂａｓｅ＿ｂｗの標準偏差を計算して正の標準偏差値を上限臨界値として設定し、負の標準偏差値を下限臨界値として設定する（Ｓ５０２、Ｓ６０２）。
【００３３】
もともと標準偏差を求めるには資料が多く要求される。また資料となる現在転送率が持続的に変化する場合には毎パケットに対して新しく標準偏差を計算せねばならないが、このために標準偏差を計算するに当ってオーバーヘッドがあまりにも大きくなる。したがって標準偏差を実際に求めるよりは数式(16)のような近似値をとる。ここではαは加重値平均のパラメータであり、数式(17)は以前時間値での標準偏差に該当する。これは、既存のＴＣＰ−Ｖｅｇａｓバージョンでのαおよびβ値が状況により調節する必要がある基準の曖昧な値であるという問題点を乗り越えるためである。
【００３４】
【数５】
2005124154.tif 000007
【００３５】
一方、遅い開始段階に関する過程をまず説明すれば、上下限臨界値を設定した後でＤｉｆｆ値が正数であるかどうかを判断する（Ｓ５０４）。もし、正数である場合には（Ｓ５０４で「はい」）、上限臨界値とその大きさを比較する（Ｓ５０６）。Ｄｉｆｆ値が上限臨界値より大きい場合には（Ｓ５０６で「はい」）、現在の転送状態が良好であるということを意味するため、ｃｗｎｄを増加させた後（Ｓ５０８）、ｂａｓｅ＿ｂｗをｃｕｒ＿ｂｗにアップデートする（Ｓ５１０）。Ｄｉｆｆ値が上限臨界値より大きくない場合には（Ｓ５０６で「いいえ」）、ｃｗｎｄを変化させずに直ちにｂａｓｅ＿ｂｗをｃｕｒ＿ｂｗにアップデートする（Ｓ５１０）。
【００３６】
そして、Ｄｉｆｆ値が正数ではない場合には（Ｓ５０４で「いいえ」）、負数であるかを判断して（Ｓ５１２）、負数である場合には（Ｓ５１２で「はい」）、現在の転送状態が直前の転送状態に比べて良好でないということを意味するため、下限臨界値とその大きさを比較する（Ｓ５１４）。Ｄｉｆｆ値が下限臨界値より大きい場合には（Ｓ５１４で「はい」）、ｃｗｎｄを変化させずに直ちにｂａｓｅ＿ｂｗをｃｕｒ＿ｂｗにアップデートする（Ｓ５１０）。Ｄｉｆｆ値が下限臨界値より大きくないか、またはＤｉｆｆ値がゼロである時は（Ｓ５１４で「いいえ」）、転送率をアップデートせずに転送を終了するかどうかを判断する（Ｓ５１６）。転送し続ける必要があれば（Ｓ５１８で「いいえ」）、一応現在の転送率を維持する（Ｓ５１８）。その後、再び最初のＳ５００段階に戻ってＤｉｆｆ値を計算する（Ｓ５００）。
【００３７】
ｂａｓｅ＿ｂｗをｃｕｒ＿ｂｗにアップデートすることが重要な理由は、遅い開始段階は適切なｂａｓｅ＿ｂｗを探す過程であるため、遅い開始段階で設定したｂａｓｅ＿ｂｗ値が混雑回避段階ではネットワークの混雑状態を判断する基準となるからである。
【００３８】
すなわち、遅い開始段階では現在のＤｉｆｆ値が上下限臨界値内の範囲で動けばｃｗｎｄを変化させずにｂａｓｅ＿ｂｗ値をアップデートする。特にＤｉｆｆが正数でありかつ上限臨界値を超える場合のみネットワーク資源の可用性を高めるためにｃｗｎｄを増加させた後、ｂａｓｅ＿ｂｗ値をアップデートすることである。
【００３９】
遅い開始段階では上限臨界値を＋ｂａｓｅｂｗ＿ｖａｒ、下限臨界値を−ｂａｓｅｂｗ＿ｖａｒと定めたが、混雑回避段階である時はｋ倍の値、すなわち、±ｋ＊ｂａｓｅｂｗ＿ｖａｒ（ｋは１以上の定数）を上下限臨界値とすることによって転送量の増減幅を減らす。図６の実施例ではｋ値が１である場合を示している。
【００４０】
次に、混雑回避段階の場合を説明すれば、遅い開始段階と同様にＤｉｆｆ値を計算した後（Ｓ６００）、上下限臨界値を設定する（Ｓ６０２）。
そして、Ｄｉｆｆ値が正数であるかどうかを判断した後（Ｓ６０４）、正数である場合は（Ｓ６０４で「はい」）、上限臨界値とその大きさを比較する（Ｓ６０６）。上限臨界値より大きい場合は（Ｓ６０６で「はい」）、現在の転送状態が良好であるということを意味するため、ｃｗｎｄを増加させた後（Ｓ６０８）、ｂａｓｅ＿ｂｗをｃｕｒ＿ｂｗにアップデートする（Ｓ６１０）。Ｄｉｆｆ値が上限臨界値より大きくない場合には（Ｓ６０６で「いいえ」）、ｃｗｎｄを変化させずに直ちにｂａｓｅ＿ｂｗをｃｕｒ＿ｂｗにアップデートする（Ｓ６１０）。
【００４１】
そして、Ｄｉｆｆ値が正数ではない場合には（Ｓ６０４で「いいえ」）、負数であるかを判断して（Ｓ６１２）、負数である場合には（Ｓ６１２で「はい」）、現在の転送状態が直前の転送状態に比べて良好でないということを意味するため、下限臨界値とその大きさを比較する（Ｓ６１４）。Ｄｉｆｆ値が下限臨界値より小さな場合は（Ｓ６１４で「はい」）、現在の転送状態が非常に不良な状態であるため、ｃｗｎｄを減少させた後（Ｓ６１６）、転送率をアップデートする（Ｓ６１０）。しかし、下限臨界値より小さくない場合には（Ｓ６１４で「いいえ」）、ｃｗｎｄを変化させずに直ちにアップデートする（Ｓ６１０）。
【００４２】
アップデート段階を経た後にはｃｗｎｄが遅い開始臨界値以下に落ちるかどうかを判断する（Ｓ６１８）。また、Ｄｉｆｆ値が正数でも負数でもないゼロとなる場合にも（Ｓ６１２で「いいえ」）、ｃｗｎｄが遅い開始臨界値以下に落ちるかどうかを判断する（Ｓ６１８）。
【００４３】
もし、ｃｗｎｄが遅い開始臨界値より小さな場合は（Ｓ６１８で「はい」）、パケットを送る空間が多く残っていることを意味するため、ｃｗｎｄを遅い開始臨界値に合わせた後（Ｓ６２０）、転送終了如何を判断する（Ｓ６２２）。ｃｗｎｄが遅い開始臨界値より小さくない場合にも（Ｓ６１８で「いいえ」）、転送終了如何を判断した後（Ｓ６２２）、転送し続ける必要がある場合は（Ｓ６２２で「いいえ」）、再びＳ６００段階から始める。
【００４４】
すなわち、混雑回避段階では上限ないし下限の臨界値範囲を超過する場合にのみｃｗｎｄ大きさを調節して転送量を調節することによって、ネットワークに過負荷を与えないように調節することである。
【００４５】
図７Ａおよび図７Ｂは、本発明の一実施例によるスループット結果を従来のＴＣＰ−ＲｅｎｏバージョンおよびＴＣＰ−Ｖｅｇａｓバージョンによるスループット結果と比較した図面である。図７Ａは、バックグラウンドトラフィックがない場合の、図７Ｂはバックグラウンドトラフィックが存在する場合の比較結果である。本発明によるシミュレーション結果を見れば、バックグラウンドトラフィックの存否に関係なく従来のＴＣＰ−ＲｅｎｏやＶｅｇａｓよりスループットがさらに高く現れるということが分かる。
【００４６】
図８Ａおよび図８Ｂは、本発明の一実施例による遺失されたパケットの数を従来のＴＣＰ−ＲｅｎｏバージョンおよびＴＣＰ−Ｖｅｇａｓバージョンによる遺失されたパケットの数と比較した図面である。同様に、図８Ａはバックグラウンドトラフィックが存在しない場合の、図８Ｂはバックグラウンドトラフィックが存在する場合の比較結果である。本発明によるシミュレーション結果を見れば、バックグラウンドトラフィックの存否に関係なく従来のＴＣＰ−ＲｅｎｏやＶｅｇａｓより遺失されたパケットの数がさらに少ないことが分かる。
【００４７】
本発明では転送率の増加または減少があったとして直ちにｃｗｎｄを変化させることではなく、一般的に発生する偏差値の範囲内にＤｉｆｆ値が存在するならば、ｃｗｎｄを変化させずにｂａｓｅ＿ｂｗをｃｕｒ＿ｂｗにアップデートしつつ転送状態を改善させる。
【産業上の利用可能性】
【００４８】
本発明は、従来のＴＣＰ転送量調節技法を修正してＴＣＰのネットワーク資源使用量を最大化し、かつ衝突を減らす技法を受け入れたものであって、モバイルアドホックネットワーク環境に望ましく適用できる。
【図面の簡単な説明】
【００４９】
【図１】ＭＡＮＥＴシステムを示す概念図である。
【図２Ａ】従来技術によるＴＣＰ−Ｒｅｎｏバージョンでの転送率変化を示す図面である。
【図２Ｂ】Ｂは、従来技術によるＴＣＰ−Ｖｅｇａｓバージョンでの転送率変化を示す図面である。
【図３】従来技術によるＴＣＰ−ＲｅｎｏバージョンおよびＴＣＰ−Ｖｅｇａｓバージョンでの転送失敗パケットの数を比較した図表である。
【図４】現在スループットと最大スループットとを比較したグラフである。
【図５】本発明の一実施例によるＭＡＮＥＴ環境で最適の転送率を探すための調節方法を示すフローチャートである。
【図６】本発明のまた他の一実施例によるＭＡＮＥＴ環境で最適の転送率を探すための調節方法を示すフローチャートである。
【図７Ａ】本発明の一実施例によるスループットの結果を従来のＴＣＰ−ＲｅｎｏバージョンおよびＴＣＰ−Ｖｅｇａｓバージョンによるスループット結果と比較した図面である。
【図７Ｂ】本発明の一実施例によるスループットの結果を従来のＴＣＰ−ＲｅｎｏバージョンおよびＴＣＰ−Ｖｅｇａｓバージョンによるスループット結果と比較した図面である。
【図８Ａ】本発明の一実施例による遺失されたパケットの数を従来のＴＣＰ−ＲｅｎｏバージョンおよびＴＣＰ−Ｖｅｇａｓバージョンによる遺失されたパケットの数と比較した図面である。
【図８Ｂ】本発明の一実施例による遺失されたパケットの数を従来のＴＣＰ−ＲｅｎｏバージョンおよびＴＣＰ−Ｖｅｇａｓバージョンによる遺失されたパケットの数と比較した図面である。
【符号の説明】
【００５０】
４０    最大スループット
４２    現在スループット
【図１】
2005124154.tif 000014
【図２Ａ】
2005124154.tif 000015
【図２Ｂ】
2005124154.tif 000016
【図３】
2005124154.tif 000017
【図４】
2005124154.tif 000018
【図５】
2005124154.tif 000019
【図６】
2005124154.tif 000020
【図７Ａ】
2005124154.tif 000021
【図７Ｂ】
2005124154.tif 000022
【図８Ａ】
2005124154.tif 000023
【図８Ｂ】
2005124154.tif 000024