(57)【要約】  本発明は、送信器端末２と、受信器端末４と、送信器及び受信器端末間に配列された１つのトラフィック・レギュレータ６と、を備え、送信器及び受信器端末は、受取り通知でトランスポート・プロトコルを用いた接続配向リンクを介してデータ・パケット・セグメントを交換する、パケット遠隔通信ネットワークにおけるトラフィックの制御を最適化する方法に関する。送信器及び受信器端末間に接続が行われたとき、送信器端末から受信器端末に送られたパケット・セグメントは、レギュレータ６のレベルにおいて妨害され、予想された受取り通知ＡＣＫａは、レギュレータ６が妨害されたパケットを受信器端末に送信するときに受信器端末によって前記パケット・セグメントの受信を模擬するために発生され、ＡＣＫａは、レギュレータ６によって固定されたレートで送信器端末によるパケット・セグメントの送信レートを従動させるように送信器端末に送信される。
2010504672.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つの送信器端末（２）と、少なくとも１つの受信器端末（４）と、送信器端末（２）及び受信器端末（４）間に配列されたトラフィック・レギュレータ（６）と、を備え、前記送信器端末（２）及び受信器端末（４）は、受信の受取り通知でトランスポート・プロトコルを用いた接続配向リンクを介してデータ・パケット・セグメントを交換する、パケット遠隔通信ネットワークにおけるトラフィックの制御を最適化する方法であって、送信器端末（２）及び受信器端末（４）間に接続が行われたとき、
送信器端末（２）から受信器端末（４）に送られたパケット・セグメントは、トラフィック・レギュレータ（６）のレベルにおいて妨害され、予想された受信の受取り通知ＡＣＫａは、トラフィック・レギュレータ（６）が妨害されたパケットを前記受信器端末（４）に送信するときに受信器端末（４）によって前記パケット・セグメントの受信を模擬するために発生され、次に、
−  前記予想された受信の受取り通知ＡＣＫａは、前記トラフィック・レギュレータ（６）によって固定されたレートに送信器端末（２）によるパケット・セグメントの送信レートを従動させるように送信器端末（２）に送信され、当該方法は、さらに、
−  トラフィック・レギュレータ（６）及び受信器端末（４）間のパケット・セグメントの転送期間（ＲＴＴ：ラウンドトリップ時間）による利用可能な帯域幅の積（プロダクト）を表す値ＢＤＰを評価するステップと、
−  送信器端末（２）により送られたパケット・セグメントの受信器端末（４）による最適な受信ウィンドウを表す値ａｄｖ_ｗｎｄを、以下の式により計算するステップと、
ａｄｖ_ｗｎｄ＝ｍｉｎ（ｒｃｖ_ｗｎｄ−ｐｉｐｅ_ｓｉｚｅ、ｂｄｐ_ｅｓｔｉｍ）
ここに、
・  ｒｃｖ_ｗｎｄは、受信器端末（４）により課される受信ウィンドウを示し、
・  ｐｉｐｅ_ｓｉｚｅは、受信器端末（４）によってまだ受取り通知されていないオクテットの数、またはこの数の評価を示し、
・  ｂｄｐ_ｅｓｔｉｍは、積ＢＤＰの評価された値を示し、
−  前記送信器端末（２）によって送られたバーストの長さを制御するよう、計算された値ａｄｖ_ｗｎｄを送信器端末（２）に送信するステップと、
を含むことをさらに特徴とする方法。
【請求項２】
前記予想された受信の受取り通知ＡＣＫａは、前記送信器端末（２）及び受信器端末（４）間で用いられるトランスポート・プロトコルに一致するデータ・フォーマットを提起し、そして前記トラフィック・レギュレータ（６）に接続された処理ユニット（１４）によって発生される請求項１に記載の方法。
【請求項３】
パケットの少なくとも１つのセグメントが、前記トランスポート・プロトコルにおいて用いられるパケットの順番付けに一致するデータフローにおけるその位置において受信されないならば、以前に送られた受取り通知と同一の重複された受取り通知ＡＣＫｄを送信器端末（２）に送信することから成るステップをさらに含む請求項２に記載の方法。
【請求項４】
−  受信器端末（４）から送信器端末（２）に送られた受取り通知ＡＣＫｒを妨害するステップと、
−  処理ユニット（１４）によって以前に送られたＡＣＫａの重複した受取り通知として送信器端末（２）に現れるであろう受取り通知を削除するように受取り通知ＡＣＫｒをフィルタリングするステップと、
−  前記受取り通知ＡＣＫｒから非配達のセグメントを推測するステップと、
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項５】
値ａｄｖ_ｗｎｄを送信器端末（２）に送信するために削除されない受取り通知ＡＣＫｒのヘッダを処理ユニット（１４）によって変更することから成るステップをさらに含む請求項３または４に記載の方法。
【請求項６】
再送信は、所定の臨界閾値より大きい重複された受取り通知の数の受信後にか、または所定の再送信期間の満了に続いてかのいずれかで行われる請求項５に記載の方法。
【請求項７】
パケットの再送信は、トラフィック・レギュレータ（６）の制御下で行われ、受信器端末（４）への再送信されたパケットの送信は、前記トラフィック・レギュレータ（６）によって固定された送信レートに従って行われる請求項６に記載の方法。
【請求項８】
送信器端末（２）及び受信器端末（４）は、トランスポートＴＣＰプロトコルに従って通信する請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
送信器端末（２）及び受信器端末（４）は、プロトコルＳＣＴＰ（ストリーム制御トランスポート・プロトコル）に従って通信する請求項１乃至７のいずれか１項に記載の方法。
【請求項１０】
少なくとも１つの送信器端末（２）と、少なくとも１つの受信器端末（４）と、送信器端末（２）及び受信器端末（４）間に配列されたトラフィック・レギュレータ（６）とを備え、前記送信器端末（２）及び受信器端末（４）は、受信の受取り通知でトランスポート・プロトコルを用いる接続配向リンクを介してデータ・パケット・セグメントを交換し、
トラフィック・レギュレータ（６）が前記パケット・セグメントを受信器端末（４）に送信するときに、送信器端末（２）によって送られるパケット・セグメントの受信器端末（４）による受信を模擬した予想された受信の受取り通知ＡＣＫａを発生するための手段（３２）を備えた処理ユニット（１４）に前記トラフィック・レギュレータ（６）が結合される装置と、
をさらに備えたパケット遠隔通信ネットワークにおけるトラフィックの制御の最適化装置であって、
−  トラフィック・レギュレータ（６）と受信器端末（４）との間のパケット・セグメントの転送期間（ＲＴＴ：ラウンドトリップ・タイム）による、利用可能な帯域幅との積を表す値ＢＤＰを評価する為の手段と、
−  送信器端末（２）によって送られるパケット・セグメントの受信器端末（４）により最適な受信ウィンドウを表す値ａｄｖ_ｗｎｄを以下の式
ａｄｖ_ｗｎｄ＝ｍｉｎ（ｒｃｖ_ｗｎｄ−ｐｉｐｅ_ｓｉｚｅ、ｂｄｐ_ｅｓｔｉｍ）
ここに、
・  ｒｃｖ_ｗｎｄは、受信器端末（４）によって課される受信ウィンドウを示し、
・  ｐｉｐｅ_ｓｉｚｅは、受信器端末（４）によって未だ受取り通知されていないオクテットの数、またはこの数の評価を示し、
・  ｂｄｐ_ｅｓｔｉｍは、積ＢＤＰの評価された値を示す、
により計算するための手段と、
−  前記送信器端末（２）により送られたバーストの長さを制御するよう、計算された値ａｄｖ_ｗｎｄを送信器端末（２）に送信するための手段と、
を備えたことを特徴とする最適化装置。
【請求項１１】
前記処理ユニット（１４）は、接続による制御構造、接続の状態、前記接続のパラメータ、及び受信器端末（４）によって未だ受取り通知されていないパケット・セグメントの再送信待ち行列を記憶するための手段（２４）を備えた状態を有するユニットである請求項１０に記載の装置。
【請求項１２】
送信器端末（２）及び受信器端末（４）は、トランスポートＴＣＰプロトコルに従って通信し、前記処理ユニット（１４）は、エラー検出及びＴＣＰプロトコルの再送信を支援するモジュール（２８）を備える請求項１１に記載の装置。
【請求項１３】
前記処理ユニット（１４）は、さらに、
−  受信器端末から送信器端末（２）に送られる受取り通知ＡＣＫｒを妨害するための手段（２０）と、
−  前記受取り通知ＡＣＫｒから非配達のセグメントを推測するための手段と、
−  処理ユニット（１４）によって以前に送られたＡＣＫａの重複された受取り通知として送信器端末（２）に現れるであろう受取り通知を削除するように受取り通知ＡＣＫｒをフィルタリングするための手段（３０）と、
を含む請求項１２に記載の装置。
【請求項１４】
前記処理ユニット（１４）は、さらに、送信器端末（２）によって送られたバーストのサイズ及び送信レートを制御するように削除されない受取り通知ＡＣＫｒのヘッダを変更するための手段を備える請求項１３に記載の装置。
【請求項１５】
少なくとも１つの送信器端末（２）、少なくとも１つの受信器端末（４）、送信器端末（２）及び受信器端末（４）間に配列されたトラフィック・レギュレータ（６）を備えたパケット遠隔通信ネットワークにおけるトラフィック・レギュレータ（６）と関連した処理ユニット（１４）であって、前記送信器端末（２）及び受信器端末（４）は、受信の受取り通知を有するトランスポート・プロトコルを用いた接続配向されたリンクを介してデータ・パケット・セグメントを交換し、前記処理ユニット（１４）は、通信インターフェース（１２）を介してトラフィック・レギュレータ（６）に結合されると共に、トラフィック・レギュレータ（６）によって前記パケット・セグメントを送る際に受信器端末（４）によって前記パケット・セグメントの受信を模擬する予想された受信の受取り通知ＡＣＫａを発生するための手段（３２）を備えている前記処理ユニット（１４）であって、
前記処理ユニット（１４）は、さらに、
−  トラフィック・レギュレータ（６）と受信器端末（４）との間のパケット・セグメントの転送期間（ＲＴＴ：ラウンドトリップ・タイム）による利用可能な帯域幅との積を表す値ＢＤＰを評価するための手段と、
−  送信器端末（２）によって送られるパケット・セグメントの受信器端末（４）により最適な受信ウィンドウを表す値ａｄｖ_ｗｎｄを以下の式
ａｄｖ_ｗｎｄ＝ｍｉｎ（ｒｃｖ_ｗｎｄ−ｐｉｐｅ_ｓｉｚｅ、ｂｄｐ_ｅｓｔｉｍ）
ここに、
・  ｒｃｖ_ｗｎｄは、受信器端末（４）によって課される受信ウィンドウを示し、
・  ｐｉｐｅ_ｓｉｚｅは、受信器端末（４）によって未だ受取り通知されていないオクテットの数、またはこの数の評価を示し、
・  ｂｄｐ_ｅｓｔｉｍは、積ＢＤＰの評価された値を示す、
により計算するための手段と、
−  前記送信器端末（２）により送られたバーストの長さを制御するよう、計算された値ａｄｖ_ｗｎｄを送信器端末（２）に送信するための手段と、
を備えた処理ユニット（１４）。
【請求項１６】
−  受信器端末（４）から送信器端末（２）に送られる受取り通知ＡＣＫｒを妨害するための手段（２０）と、
−  前記受取り通知ＡＣＫｒから非配達のセグメントを推測するための手段と、
−  処理ユニット（１４）によって以前に送られたＡＣＫａの重複された受取り通知として送信器端末（２）に現れるであろう受取り通知を削除するよう受取り通知ＡＣＫｒをフィルタリングするための手段（３０）と、
をさらに備えた請求項１５に記載の処理ユニット。
【請求項１７】
送信器端末（２）によって送られるバーストのサイズ及び送信レートを制御するよう送信器端末（２）によって送られるパケット・セグメントのトラフィック・レギュレータ（６）による最適な受信ウィンドウを表わす値ａｄｖ_ｗｎｄを送信器端末（２）に送信するために削除されない受取り通知ＡＣＫｒのヘッダを変更するための手段をさらに備えたことを特徴とする請求項１６に記載の処理ユニット。
【請求項１８】
少なくとも１つの送信器端末（２）、少なくとも１つの受信器端末（４）、送信器端末（２）及び受信器端末（４）間に配列されたトラフィック・レギュレータ（６）を備えたパケット遠隔通信ネットワークにおけるトラフィック・レギュレータ（６）と関連した処理ユニット（１４）上にロードされるソフトウェアであって、前記送信器端末（２）及び受信器端末（４）は、受信の受取り通知を有するトランスポート・プロトコルを用いた接続配向されたリンクを介してデータ・パケット・セグメントを交換し、前記ソフトウェアは、トラフィック・レギュレータ（６）によって前記パケット・セグメントを送る際に受信器端末（４）によって前記パケット・セグメントの受信を模擬する予想された受信の受取り通知ＡＣＫａを発生するための命令を含み、
そして、ソフトウェアは、さらに、
−  送信器端末と受信器端末との間のパケット・セグメントの転送期間（ＲＴＴ：ラウンドトリップ・タイム）による利用可能な帯域幅との積を表す値ＢＤＰを評価するためのモジュールと、
−  送信器端末（２）によって送られるパケット・セグメントの受信器端末（４）により最適な受信ウィンドウを表わす値ａｄｖ_ｗｎｄを以下の式
ａｄｖ_ｗｎｄ＝ｍｉｎ（ｒｃｖ_ｗｎｄ−ｐｉｐｅ_ｓｉｚｅ、ｂｄｐ_ｅｓｔｉｍ）
ここに、
・  ｒｃｖ_ｗｎｄは、受信器端末（４）によって課される受信ウィンドウを示し、
・  ｐｉｐｅ_ｓｉｚｅは、受信器端末（４）によって未だ受取り通知されていないオクテットの数、またはこの数の評価を示し、
・  ｂｄｐ_ｅｓｔｉｍは、積ＢＤＰの評価された値を示す、
により計算するためのモジュールと、
−  前記送信器端末（２）により送られたバーストの長さを制御するよう、計算された値ａｄｖ_ｗｎｄを送信器端末（２）に送信するためのモジュールと、
を含むソフトウェア。
【請求項１９】
−  受信器端末（４）から送信器端末（２）に送られる受取り通知ＡＣＫｒを妨害するためのモジュールと、
−  前記受取り通知ＡＣＫｒから非配達のセグメントを推測するためのモジュールと、
−  処理ユニット（１４）によって以前に送られたＡＣＫａの重複された受取り通知として送信器端末（２）に現れるであろう受取り通知を削除するよう受取り通知ＡＣＫｒをフィルタリングするためのモジュールと、
をさらに含む請求項１８に記載のソフトウェア。
【請求項２０】
送信器端末（２）によって送られるバーストのサイズ及び送信レートを制御するよう送信器端末（２）によって送られるパケット・セグメントの受信器端末（４）による最適な受信ウィンドウを表わす値ａｄｖ_ｗｎｄを送信器端末（２）に送信するために削除されない受取り通知ＡＣＫｒのヘッダを変更するためのモジュールをさらに含むことを特徴とする請求項１９に記載のソフトウェア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、遠隔通信の領域に関し、一層詳細には、少なくとも１つの送信器端末、少なくとも１つの受信器端末、並びに送信器端末及び受信器端末間に配列されたトラフィック・レギュレータ（調整器）を備えたパケット遠隔通信ネットワークにおけるトラフィックの制御を最適化するためのプロセスに関し、ここに、前記送信器及び受信器端末は、受信の受取り通知でトランスポート・プロトコルを用いた接続配向リンクを介してデータ・パケット・セグメントを交換する。
【０００２】
本発明は、同様に、かかる遠隔通信ネットワークにおけるトラフィックの制御を最適化するための装置、及び該装置のトラフィック・レギュレータ（調整器）に接続される処理ユニットに関する。
【０００３】
本発明は、同様に、本発明によるプロセスを履行するための命令を含む前記処理ユニット上にロードされたソフトウェアに関する。
【背景技術】
【０００４】
例えばＴＣＰ（送信制御プロトコル）及びＳＣＴＰ（ストリーム制御トランスポート・プロトコル）のような既知の接続配向プロトコルは、２つの機械または端末間でデータの保証されたポイントツーポイント交換を可能とする。これらのプロトコルは、オクテット（octets：８ビット・バイト）を順次番号でマーキングすることにより、かつ標準ヘッダにおいて特定される受信番号の受取り通知を提供することによって、データの喪失なしで、順番付けられた転送を確実にする。
【０００５】
一般的に、セグメントの喪失の検出は以下の２つの方法で行われる：送信器によって受信されている受信の何等の受取り通知なしで所定の期間の満了によって、または所定の臨界閾値より大きい受信の連続する重複された受取り通知の数を受信することによって、のいずれかによって行われる。喪失を検出した場合、想定される１つまたは複数の喪失セグメントが再送信される。再送信期間は、受信器から送信器への受信の対応の受取り通知の転送時間に追加されるべきセグメントのＲＴＴ（ラウンドトリップ時間：往復時間）として示される転送時間の評価に基づいて計算される。
【０００６】
また、これらのトランスポート・プロトコルは、動的スライディング・ウィンドウ上に設立されるフロー及び輻輳制御機構を供給する。
【０００７】
フロー制御の目的は、迅速な送信機械が、一層ゆっくりした受信器機械のバッファ・メモリをオーバーフローさせるのを阻止することである。この目的で、受信器は、この明細書では以下、ｒｃｖ_ｗｎｄ（受信器ウィンドウ）として示される、プロトコル・ヘッダにおけるオクテットの受信ウィンドウ・サイズを明確に供給する。このサイズは、転送を吸収するために接続に割り当てられた受信器のバッファ・メモリの容量を反映する。用いられるトランスポート・プロトコルは、送信器が、受信器によるデータの喪失を回避するように、受取り通知されないより多くのｒｃｖ_ｗｎｄオクテットを送信しないということが必要である。
【０００８】
さらに、送信器は、受信器のメモリをオーバーフローさせ得るだけでなく、例えばＩＰルータ（インターネット・プロトコル）のようなネットワークにおける中間のノードのバッファ・メモリの容量をも飽和させ得る。この場合、データは、これらの中間のノードによって削除される。輻輳制御の目的は、データの相当の喪失（そして多くの再送信）に帰結するネットワークのリソースの過度に酷使した使用と、プロトコル転送性能の不利益となるまで喪失がないことを保証するこれらリソースの不充分の使用との間のバランスを見つけることである。
【０００９】
ＴＣＰ／ＩＰネットワークの特別な場合において、これらのネットワークのアーキテクチャは、端末にネットワークのリソースの状況について明確に知らせることを支援せず、また、これらの端末に常駐するＴＣＰプロトコルは、これらのリソースの評価アルゴリズムを使用する。
【００１０】
現在の標準において、ＴＣＰは、喪失の検出を、ネットワークにおける輻輳を暗に意味する信号として用いる。ＴＣＰ送信器は、送信器がネットワークに注入し得る受取り通知されないオクテットの数を評価する、ｃｗｎｄとして伝統的に示されるオクテットでの輻輳ウィンドウを維持する。最適な量は、帯域幅の周期による積ＢＤＰ「帯域幅遅延積」である。
【００１１】
ＴＣＰ輻輳制御アルゴリズムは、以下の２つの段階で行われる：最初に送信器は、セグメントが喪失されるまで、受信された受信の各受取り通知に対しセグメントのサイズだけその輻輳ウィンドウを拡大することによりネットワークを探査する。この最初の段階は、ウィンドウの拡大が指数的であるけれども、「ゆっくりしたスタート」として限定される。次に、輻輳回避と呼ばれる第２の段階は、穏やかな成長（線形的）及び乗算的減少によってバランス値の回りに振動されるウィンドウを見る（ウィンドウは、セグメントの喪失の場合に２で割られる）。
【００１２】
輻輳ウィンドウの動的展開は、受信の受取り通知の到着レートによって完全に決定され、従って、接続のＲＴＴに対して大いに敏感であるということが留意されるべきである。送信器の送信ウィンドウは、ｃｗｎｄ及びｒｃｖ_ｗｎｄの値の最小として計算される。
【００１３】
このウィンドウに基づいて、送信器は、そのＩＰ層にセグメントを送信する：もしデータが利用可能であるならば、そしてもしウィンドウが充分に大きいならば、幾つかのセグメントは、同時に、すなわち次々に送られる。これらは、ＴＣＰ転送の放出「バースト」特性として知られている。
【００１４】
ＴＣＰ輻輳制御は、インターネットの安定性のかなめとして考慮されるとしても、その効率は、例えば相当のＲＴＴに起因して、或る数の環境においては、特に高いＢＤＰを呈示するこれらのネットワークにおいては、最善の水準に次ぐものであるとして再考慮される。また、喪失を、輻輳を暗に意味する信号として用いることは、ワイヤレス・ネットワークのような高いエラー・レートを有するネットワークに対して問題を提起する。
【００１５】
最後に、幾つかの応用は、ＴＣＰと不充分に相互作用する特性を有する：これは、送信されるべきパケットの欠乏によって輻輳ウィンドウの定常状態に達することに成功しない、かつ「ゆっくりしたスタート」段階に起因して必要であるよりも高い待ち時間を被る、非常に短いトランザクションの場合である。相当なＢＤＰでネットワークを介して移送されるこのような応用は、非常に低い性能を被るが、しかしＴＣＰ／ＩＰネットワークの遍在がそれらを必要なものとする。
【００１６】
トラフィック・レギュレータを備える従来技術のアーキテクチャにおいては、後者は、概して、非常に異なった特性の２つのネットワーク間のフロンティアにおいて配置された、例えば、局部的な高レート・ネットワークと、フレーム・リレー・ネットワーク、ＡＴＭまたはＭＰＬＳ（マルチプロトコル・ラベル・スイッチング）ネットワークのようなワイドエリア・ネットワーク（ＷＡＮ）へのアクセスとの間の境界線において配置された、もしくはワイヤレス・ネットワーク（ＷｉｆｉまたはＷｉｍａｘ）と配線されたネットワークとを相互接続するベース・ステーションまたはアクセス・ポイントのレベルにおいてさえ配置された、１つまたは２つ以上の物理的ユニットによって構成される。トラフィック・レギュレーションの目的は、ネットワークに特有のアクセス特性の関数として、またはネットワークのユーザとのサービス品質契約（ＳＱ）を尊重するネットワークの構成の関数として、トラフィックを等しくさせることである。トラフィック・レギュレーションは、例えば、トラフィックの異なったクラス間で利用可能な帯域幅の部分の割付けを確実にすることができ、そしてこれらトラフィックのクラスの流れ間での同時パケット送信を調停することができる。円滑化は、このように、１秒当りのパケットの数で測定された、または１秒当りに送信されたオクテットまたはビットの数で測定された、構成されたレートに流れを制限する：パケットは、連続するパケット・バーストの放出を著しく減少することができる、構成されたレートの関数として多かれ少なかれ厳密に送信される。トラフィックを等しくさせるプロセスは、代表的には、トークン・バケット・アルゴリズムに基礎を置いており、パケットの順番付けは、パケット待ち行列の特有のサービスの規範によって行われる。
【００１７】
ＴＣＰプロトコルを用いるネットワークにおいて、トラフィック・レギュレーションは、ＴＣＰ基準の送信機構に固有である連続パケット・バーストを相当に減少する。パケットは、スライディング・ウィンドウを介するそのトラフィック制御機構に続いて、ＴＣＰによって次々と連続的に送信される。トラフィックを等しくすることは、送られる各パケット間のセット期間を導入し、従って、レギュレータによって割付けられる送信レートの関数として、パケットに互いに密接すぎるほどに間を持たせる。
【００１８】
このことは、中間のノードにおける、特にＩＰルータにおける、パケットの喪失の可能性を減少し、その理由は、ルータのバッファ・メモリが、吸収するには一層少ない連続パケット・バーストを有し、従って、これらのメモリ・バッファのオーバーフローの可能性を減少するからである。
【００１９】
また、ＴＣＰ接続からの送信データ・セグメントがトラフィック・レギュレータによって割付けられたレートを超えるならば、これらのパケットは、このレギュレータによって遅延される。この遅延は、接続ごとに計算されるＲＴＴをブーストし、このことは、ＴＣＰ送信器によるセグメントの送信をスロー・ダウンさせ、その理由は後者が一層大きい遅延でもって受信の受取り通知を受信するであろうからである。
【００２０】
しかしながら、トラフィック・レギュレーションだけでは、ＴＣＰ送信器の輻輳ウィンドウのサイズにおける増加を制御しない。トラフィックを等しくすることは、レギュレータの下流のネットワークにおける喪失の可能性を減少するので、送信器の輻輳ウィンドウのサイズは、レギュレータの無い場合よりも一層大きい。結果として、送信器は、一層大きいサイズのバーストを送信し、レギュレータにおける待ち行列のサイズの増加を引き起し、もしくはレギュレータの上流の中間ノードにおけるメモリのオーバーフローをさえ引き起す。結果として、トラフィックを等しくすることは、レギュレータの下流のネットワークの性能を改善するとしても、それは、レギュレータの上流でのもしくはレギュレータそれ自体での喪失に起因して、ＴＣＰ性能の劣化に導き得、このことは、データ・パケットを遅らせることにより、ＴＣＰ源からの放出間の時間間隔を制御することができるが、しかしこのようなものとして、ＴＣＰ源によって送られたバーストの（オクテットの数における）サイズを制御しない、という事実に基づいている。
【００２１】
最後に、トラフィック・レギュレータは、その「ゆっくりした起動」段階におけるＴＣＰの非効率を解決しない。結果として、レギュレータが、接続の送信レートを制御するとしても、それは、パケットの喪失を導入することなく、輻輳制御機構を暗に管理することができない。
【発明の概要】
【発明が解決しようとする課題】
【００２２】
本発明の目的は、上述した従来技術の欠点を克服することである。
【００２３】
一層詳細には、本発明の目的は、遠隔通信ネットワークにおける２つの端末間のトラフィックを最適に等しくさせるために、データ・リンク層のレベル（レベル２）またはネットワーク層のレベル（レベル３）、すなわちＩＰ、のいずれかにおいて、トラフィック・レギュレーションを供給するインフラストラクチャ・ネットワークを有する接続配向のトランスポート・プロトコルのアルゴリズムの相互作用を最適化することである。
【課題を解決するための手段】
【００２４】
このため、本発明は、少なくとも１つの送信器端末と、少なくとも１つの受信器端末と、送信器端末及び受信器端末間に配列されたトラフィック・レギュレータと、を備え、前記送信器端末及び受信器端末は、受信の受取り通知でトランスポート・プロトコルを用いた接続配向リンクを介してデータ・パケット・セグメントを交換する、パケット遠隔通信ネットワークにおけるトラフィックの制御を最適化する方法を提唱する。
【００２５】
本発明によれば、この方法は、以下のステップ：
送信器端末及び受信器端末間に接続が行われたとき、
−  送信器端末から受信器端末に送られたパケット・セグメントを、トラフィック・レギュレータのレベルにおいて妨害するステップと、
−  トラフィック・レギュレータが、妨害されたパケットを前記受信器端末に送信するときに、受信器端末によって前記パケット・セグメントの受信を模擬する予想された受信の受取り通知ＡＣＫａを発生するステップと、
−  前記トラフィック・レギュレータによって固定されたレートに送信器端末によるパケット・セグメントの送信レートを従動させるように前記予想された受信の受取り通知ＡＣＫａを送信器端末に送信するステップと、を含む。
【００２６】
受信の受取り通知ＡＣＫａの予想された特性は、パケット・セグメントが受信器端末によって受信される前にそれが発生されるという事実から来る。
【００２７】
本発明によれば、前記予想された受信の受取り通知ＡＣＫａは、前記トラフック・レギュレータに接続された処理ユニットによって発生され、送信器端末及び受信器端末間のデータの送信のために用いられるトランスポート・プロトコルに従うデータ・フォーマットを提起する。
【００２８】
本発明による方法は、好ましくは以下のステップ：
−  トラフィック・レギュレータ及び受信器端末間のパケット・セグメントのＲＴＴ転送期間による利用可能な帯域幅の積（プロダクト）を表すＢＤＰ値を評価するステップと、
−  送信器端末により送られたパケット・セグメントの受信器端末による最適な受信ウィンドウを表す値ａｄｖ_ｗｎｄを、以下の式により計算するステップと、
ａｄｖ_ｗｎｄ＝ｍｉｎ（ｒｃｖ_ｗｎｄ−ｐｉｐｅ_ｓｉｚｅ、ｂｄｐ_ｅｓｔｉｍ）
ここに、
・  ｒｃｖ_ｗｎｄは、受信器端末により課される受信ウィンドウを示し、
・  ｐｉｐｅ_ｓｉｚｅは、受信器端末によってまだ受取り通知されていないオクテットの数、またはこの数の評価を示し、
・  ｂｄｐ_ｅｓｔｉｍは、積ＢＤＰの評価された値を示し、
−  前記送信器端末によって送られたバーストの長さを制御するよう、計算された値ａｄｖ_ｗｎｄを送信器端末に送信するステップと、
を含む。
【００２９】
当該方法は、このように、送信器端末によって送られるバーストのサイズを制御する。
【００３０】
本発明による方法は、さらに、少なくとも１つのパケット・セグメントが、送信器端末及び受信器端末間で用いられる送信プロトコルにおいて用いられるパケットの順番付けに一致するデータフローにおけるその位置において受信されないならば、以前に送られた受取り通知と同一の重複された受取り通知ＡＣＫｄを送信器端末に送信することから成るステップを含む。
【００３１】
好適な実施形態において、本発明による方法は、さらに、以下のステップ：
−  受信器端末から送信器端末に送られた受取り通知ＡＣＫｒを妨害するステップと、
−  処理ユニットによって以前に送られたＡＣＫａの重複した受取り通知として送信器端末に現れるであろう受取り通知を削除するように受取り通知ＡＣＫｒをフィルタリングするステップと、
−  前記受取り通知ＡＣＫｒから非配達のセグメントを推測するステップと、
を含む。
【００３２】
本発明のもう１つの特徴によれば、送信器端末によって送られるパケット・セグメントの受信器端末により最適の受信ウィンドウを表す値ａｄｖ_ｗｎｄを送信器端末に送信するために削除されない受取り通知ＡＣＫｒのヘッダを処理ユニットによって変更する。
【００３３】
このことは、送信器端末によって送られるバーストのサイズ及び送信レートを制御するのを許容する。
【００３４】
配達されないパケット・セグメントの再送信は、所定の臨界閾値より大きい重複された受取り通知の数の受信後にか、または所定の再送信期間の満了に続いてかのいずれかで行われる。
【００３５】
本発明によれば、この再送信は、トラフィック・レギュレータの制御下で行われ、受信器端末に再送信されるパケットは、このトラフィック・レギュレータによって固定された送信レートに従って送られる。
【００３６】
本発明による方法は、少なくとも１つの送信器端末と、少なくとも１つの受信器端末と、送信器端末及び受信器端末間に配列されたトラフィック・レギュレータとを備え、前記送信器端末及び受信器端末は、受信の受取り通知でトランスポート・プロトコルを用いる接続配向リンクを介してデータ・パケット・セグメントを交換する装置によって実行される。
【００３７】
本発明によれば、前記トラフィック・レギュレータによるパケットの送信時に、端末によりパケット・セグメントの受信を模擬するよう構成された予想された受信の受取り通知ＡＣＫａを発生するための手段を備えた処理ユニットにレギュレータが結合される。
【００３８】
処理ユニットは、接続による制御構造、接続の状態、前記接続のパラメータ、及び受信器端末によって未だ受取り通知されていないパケット・セグメントの再送信待ち行列を記憶するためのメモリを備えた状態を有するユニットである。
【００３９】
特定の応用においては、送信器端末及び受信器端末は、ＴＣＰ送信プロトコルに従って通信し、前記処理ユニットは、ＴＣＰプロトコルのエラー及び再送信検出機構を支援するモジュールを備える。
【００４０】
また、前記処理ユニットは、
−  受信器端末から送信器端末に送られる受取り通知ＡＣＫｒを妨害するための手段と、
−  前記受取り通知ＡＣＫｒから非配達のセグメントを推測するための手段と、
−  処理ユニットによって以前に送られたＡＣＫａの重複された受取り通知として送信器端末に現れるであろう受取り通知を削除するように受取り通知ＡＣＫｒをフィルタリングするための手段と、
を含む。
【００４１】
処理ユニットは、同様に、送信器端末によって送られたバーストのサイズ及び送信レートを制御するように削除されない受取り通知ＡＣＫｒのヘッダを変更するための手段を備える。
【００４２】
本発明による方法は、少なくとも１つの送信器端末、少なくとも１つの受信器端末、送信器端末及び受信器端末間に配列されたトラフィック・レギュレータを備えたパケット遠隔通信ネットワークにおけるトラフィック・レギュレータと関連した処理ユニット上にロードされるソフトウェアによって実行され、前記送信器端末及び受信器端末は、受信の受取り通知を有するトランスポート・プロトコルを用いた接続配向されたリンクを介してデータ・パケット・セグメントを交換する。
【００４３】
前記ソフトウェアは、トラフィック・レギュレータによって前記パケット・セグメントを送る際に受信器端末によって前記パケット・セグメントの受信を模擬する予想された受信の受取り通知ＡＣＫａを発生するための命令を含む。
【００４４】
本発明によるソフトウェアは、さらに、
−  受信器端末から送信器端末に送られる受取り通知ＡＣＫｒを妨害するための命令と、
−  妨害された受取り通知ＡＣＫｒから非配達のセグメントを推測するための命令と、
−  処理ユニットによって以前に送られたＡＣＫａの重複された受取り通知として送信器端末に現れるであろう受取り通知を削除するよう受取り通知ＡＣＫｒをフィルタリングするための命令と、
を含む。
【００４５】
好ましくは、このソフトウェアは、さらに、前記送信器端末によって送られるバーストのサイズ及び送信レートを制御するよう送信器端末によって送られるパケット・セグメントの受信器端末による最適な受信ウィンドウを表わす値ａｄｖ_ｗｎｄを送信器端末に送信するために削除されない受取り通知ＡＣＫｒのヘッダを変更するための命令を含む。
【００４６】
本発明の他の特徴及び長所は、添付図面を参照して非制限的な例によって為される以下の説明から明瞭となるであろう。
【図面の簡単な説明】
【００４７】
【図１】本発明による方法が履行される装置を概略的に示す図である。
【図２】本発明による受信の受取り通知の管理ユニットの詳細を示す図である。
【図３】図１の装置を介して送信器端末及び受信器端末間で交換されるフロー経路を概略的に示す図である。
【図４】図１の装置を介して送信器端末及び受信器端末間で交換されるフロー経路を概略的に示す図である。
【図５】図１の装置を介して送信器端末及び受信器端末間で交換されるフロー経路を概略的に示す図である。
【図６】本発明の方法によるトラフィック・レギュレーションを示すフローチャート（organigram）である。
【図７】本発明の方法による上流フロー（処理ユニット及び送信器間）の処理を示すフローチャートである。
【図８】本発明の方法による下流フロー（受信器及び処理ユニット間）の処理を示すフローチャートである。
【図９】本発明の方法によるフローの再送信の管理を示すフローチャートである。
【発明を実施するための形態】
【００４８】
遠隔通信ネットワークにおける送信器２及び受信器４間のＴＣＰリンク（制御送信プロトコルに対して）へのプロセスの適用において例として本発明を説明する。本発明の範囲から逸脱することなく、送信器２及び受信器４間で用いられる送信プロトコルのタイプがどんなものであろうとプロセスを適用し得ることに注意されるべきである。一層明瞭にするために、送信器は、データのセグメントを送信する遠隔的な機械を示し、受信器は、前記送信器に受信の受取り通知、すなわち“ＡＣＫ”、のセグメントだけを返礼として送信する送信器に接続されるもう１つの機械を示す。
【００４９】
同じ機械が同じ接続に対して同時に送信器及び受信器であり得ることに注意すべきである。
【００５０】
図１は、トラフィック制御最適化装置５を介する送信器２及び受信器４間のリンクを示す。
【００５１】
「上流ネットワーク」は、送信器２及び装置５間のネットワークの部分を示し得、「下流ネットワーク」は、装置５及び受信器４間の部分を示し得る。同様に、上流セグメント（ｒｅｓｐ．パケット）は、ネットワークの上流部分から、従って送信器２から、「下流」部分に、従って受信器４に、トランスポートされる（移送される）セグメント（ｒｅｓｐ．パケット）であり、「下流」セグメント（ｒｅｓｐ．パケット）は、ネットワークの「上流」部分から、従って受信器４から、「上流」部分に、従って送信器２に、トランスポートされるセグメント（ｒｅｓｐ．パケット）である。
【００５２】
装置５は、「上流及び下流」の入力／出力インターフェース上のパケットの受信及び送信フォーマットに拘わらず、端末２及び４と相互作用（対話）することができる。それは、本発明の範囲を逸脱することなく、層２（ＭＡＣ：媒体アクセス制御）のまたは／及び層３（ＩＰ：インターネット・プロトコル）のレベルにおいて及びそれを超えて動作することができる。このような装置は、中央化されることができる、すなわち、ネットワーク・アダプタ、フィルタリング・ブリッジ、スイッチ、ルータ、アクセス・ポイントまたはワイヤレス・ベース・ステーションのような単一の物理的要素によって構成され、またはＴＣＰホスト上で動作する装置ドライバのようなソフトウェア要素によって構成され得る。
【００５３】
代替的には、装置は、幾つかの物理的ネットワーク要素上に配分され得る。
【００５４】
図１を参照して、装置５は、パケット・オーダラ（orderer）８及び制御モジュール１０を含むトラフィック・レギュレータ６を備える。トラフィック・レギュレータ６は、通信インターフェース１２を介して処理ユニット１４に接続される。処理ユニット１４は、トラフィック・レギュレータ６が受信器端末４にパケット・セグメントを送信するとき、送信器端末２によって送信されるパケット・セグメントの受信器端末４による受信を模擬する予想される受信の受取り通知ＡＣＫａを発生するための手段を備える。
【００５５】
制御モジュール１０の機能は、外部ネットワーク・ユニットまたはネットワークの知覚された状態における準備されたトラフィック・アドミニストレーション・ポリシ（管理方針）の関数として、トラフィック・レギュレータ６のパラメータを動的に適合させることである。
【００５６】
図２は、処理ユニット１４を詳細に示す。
【００５７】
好ましくは、後者は、以下のものを含む：
−  レベル・スクリーン２（データ・リンク層）またはＩＰレベル・データグラム３、及び選択的に、すべてのＴＣＰセグメントを有するよう、分解されたＩＰパケットを再結合するかを、受信されたパケットのＴＣＰ及びＩＰヘッダからの必要な情報を抽出するためのセグメント・デマルチプレクサ２０、
−  制御ステップ２２のためのマネージャ。
【００５８】
各接続に対し、現在の状況が、受取り通知されないセグメントの待ち行列で、制御ステップとして知られている構造の形態で、メモリ２４にロードされ、そして喪失及び再送信の検出を完了するために必要な任意の他の情報がＴＣＰ基準と一致する。
【００５９】
制御ステップ２２のマネージャは、このメモリ２４における制御ステップを、創成するために、回復するために及び破壊するためにある。対応の制御のメモリ・アドレス及び接続間の関連は、バランス・ツリーまたはハッシング・テーブルのような適切なデータ構造により作られ得る。制御ステップの識別子は、ＴＣＰ及びＩＰヘッダから抽出された４つ組＜ＩＰ送信元アドレス、ＩＰ送信先アドレス、ＴＣＰ送信元ポート、ＴＣＰ送信先ポート＞またはレベル“タグ”２のいずれかであり得る。
【００６０】
ユニット１４は、さらに、上流セグメントをフィルタリングするための第１のフィルタ２６を備える。この構成要素は、送信器端末によって受信器端末に送られるセグメントを処理する際にのみ用いられる。それは、デマルチプレクサ２０によって抽出されたヘッダ及びＴＣＰセグメントに関する種々の確認を供給する。特に、このフィルタは、ＴＣＰセグメントがデータを移送する（トランスポートする）かまたはしないかを確認する。もししないならば、セグメントは、次に受取り通知されてはならない純粋な受取り通知であり、このセグメントは、処理ユニット１４によって無視され得、次に、受信器端末４に送信され得る。このフィルタ２６は、同様に、ＴＣＰセグメントのチェックサムが有効であるか否かを確認する。もし有効でないならば、セグメントは、削除される。それは、また、セグメントが重複されているか否か、すなわち、セグメントが送信器端末２の再送信であるか否かをも確認する。もし再送信ならば、セグメントは削除される。
【００６１】
すべての他の場合において、セグメントは、上流の処理の残りのために再送信マネージャの待ち行列２８に通される。
【００６２】
ユニット１４は、さらに、再送信マネージャ待ち行列２８に接続されたバッファ・メモリ２９を備える。この構成要素は、任意のＴＣＰ制御輻輳機構を考慮しないことによって、ＴＣＰエラーのコア及び再送信検出機構を供給する。実際、処理ユニット１４が送信器２に予想された受取り通知を送信するので、受取り通知されたセグメントの正しくかつ順番付けられた配達のための責任は、再送信マネージャ待ち行列２８と共にある。
【００６３】
上流セグメントに対して、この構成要素は、セグメント・オクテットのシーケンス番号に従って順番付けられたセグメントの待ち行列に送信された各セグメントのコピーを保つ。
【００６４】
下流のセグメントに対して、累積受信番号の受取り通知は、受信器端末によって正しく受信されたセグメントを示し：  再送信待ち行列に保たれたこれらのセグメントのコピーは、危険無しで削除され得る。エラー検出アルゴリズムは、受信器端末上のＴＣＰインプランテーションと互換性を有するよう、処理ユニット１４のためのＴＣＰ基準と一致しなければならない。１つまたは２つ以上のセグメントが、ＴＣＰ“Ｒｅｎｏ”変数に対して特定される、すなわち連続する重複された受取り通知の数が所定の臨界閾値、概して３、に達したとき、高速回復として知られる手順を介して、または、ＴＣＰ“ＳＡＣＫ”変数に対して特定される選択的受取り通知回復手順を介して、または、再送信タイムスイッチの満了手順を介して、のいずれかを介して再送信される。この最後の手順に対しては、マネージャ２８は、例えば標準のＴＣＰサンプリング・アルゴリズムと一致する、短かすぎもせず長すぎもしないタイムスイッチのための期間を評価するために、各接続のＲＴＴを評価しなければならない。
【００６５】
セグメントが再送信されなければならないとき、それらは、トラフィック・レギュレータ６の制御下に置かれる。隠された再送信の何等かのエッジ効果（例えば、受信器端末にルーティングするトラフィックのかなりの過小評価）を回避するために、再送信待ち行列マネージャ２８は、トラフィック・レギュレータ６とのインターフェースを有する。例えば、もしトラフィック・レギュレータ６がトラフィック・クラスによる待ち行列を備えるならば、再送信マネージャ２８は、待ち行列の最後に置かれる送信されるべき新しいパケットとは反対に、再送信されたセグメントを対応の待ち行列のヘッドに置く。
【００６６】
ユニット１４は、さらに、下流のセグメントに対して専用の第２のフィルタ３０を備える。この構成要素は、送信器端末２に受信器端末４によって送られるセグメントを処理する際にのみ用いられる。それは、デマルチプレクサ２０によって抽出されたＴＣＰセグメント及びヘッダに関する種々の確認を提供する。特に、このフィルタは、受取り通知ビット（ＡＣＫ）が位置付けられるか否かを確認する。もし位置付けられないならば、セグメントは無視される。それは、同様に、ＴＣＰセグメントのチェックサムが有効か否かを確認する。もし、有効でないならば、セグメントは、削除される。
【００６７】
他のすべての場合において、セグメントは、残りの下流の処理のために再送信待ち行列マネージャに通される。
【００６８】
ユニット１４は、同様に、上流パケットの処理に続いて、送信器端末２に受信の受取り通知だけを含むセグメントを発生する予想された受取り通知発生器３２を含む。もし、妨害されたパケットが、順次番号の順番で予想されるものでないＴＣＰセグメントを含むならば、予想された受取り通知発生器３２は、重複された受取り通知、すなわち以前と同じ受取り通知を送信する。この発生器３２は、従って、接続ステップの制御における受取り通知、並びに、次に予想されるセグメントの順次番号を記憶しなければならない。もし、妨害されたパケットが予想されたものであるならば、予想された受取り通知発生器３２は、それが受信器端末４によって送信器端末２に送られたかのように見えるように受取り通知を構成する。特に、ＩＰアドレス及びＴＣＰポートは、妨害されたパケットに対して逆でなければならない。受取り通知の順次番号は、妨害されたパケットの受信番号の受取り通知の値に位置付けられる。受信番号の受取り通知は、パケットのデータＴＣＰの長さ（すなわち、その有用なロードのサイズ）だけ増分される妨害されたパケットの順次番号に位置付けられる。最後に、受信ウィンドウは、以下の式に従って位置付けられる。
ａｄｂ_ｗｎｄ＝ｍｉｎ（ｒｃｖ_ｗｎｄ−ｐｉｐｅ_ｓｉｚｅ、ｂｄｐ_ｅｓｔｉｍ）
ここに、
・  ｒｃｖ_ｗｎｄは、受信器端末によって課される受信ウィンドウを示す、
・  ｐｉｐｅ_ｓｉｚｅは、受信器端末によって未だ受取り通知されていないオクテットの数、またはこの数の評価を示す。
・  ｂｄｐ_ｅｓｔｉｍは、プロダクトＢＤＰの評価された値を示す。
【００６９】
下流のパケットに対して、予想された受取り通知発生器３２は、純粋な受取り通知をフィルタリングし：  もし、受信器端末への送信器端末２の純粋な受取り通知が、ウィンドウ・サイズにおける無変化に帰結し、そしてそのヘッダに位置付けられるＳＹＮ、ＲＳＴまたはＦＩＮビットのいずれも有さないならば、該パケットは、黙って削除され得る。もし、反対が適用されるならば、そして受信器端末４への送信器端末２のセグメントがデータを含むならば、構成要素は、以下によってセグメントのＴＣＰヘッダを変更する：
・  送信器端末２に予想された受取り通知において送られる最後の番号を置くために受信番号の受取り通知を変更することによって。この変更がない場合、セグメントは、送信器端末２によって「古すぎる」として無視され得、すなわち、受信番号の受取り通知が、そのウィンドウのレフト（左）・エッジの前にあるか、もしくはセグメントが、不必要な再送信を引き起す重複された受取り通知としてさえ考慮され得る。
・  上述の式に応じて受信ウィンドウを変更することによって。
・  ２つの先行する変更を考慮するために、セグメントのチェックサムを固定することによって。
【００７０】
計算アルゴリズムが与えられると、合計は、全ＴＣＰセグメントに渡ってそれを再計算することなく、増分的に固定され得る。
【００７１】
ユニット１４は、また、ＢＤＰ３４のサンプラをも含む。この構成要素は、再送信機構のために必要なＲＴＴのサンプリングから各接続のＢＤＰを評価する。もし、レギュレータ６が、ＴＣＰ接続を介して待ち行列管理を供給し、かつ各待ち行列のために構成されたレートを認識するためのインターフェースを提供するならば、ＢＤＰは、接続の待ち行列のレートを接続のＲＴＴで直接乗算することによってサンプリングされ得る。ネットワークの「下流の」部分におけるレートは、レギュレータのレートによって全体的に制限される、と仮定される。もし、このような計算が可能でないならば、ＢＤＰは、オクテットで、再送信の待ち行列の長さを測定することにより、サンプリングされ得る。専用の順次番号は、制御ステップにおいて保持され、再送信待ち行列の最大のサイズは、この順次番号が送信器端末２の受信の受取り通知によって受取り通知されるまで測定される。ＢＤＰは、次に、これらのサンプルの平均として評価され得る。このような手順は、“Ｔｉｍｅｓｔａｍｐ”オプションのないＲＴＴのサンプリング基準と同様である。
【００７２】
ユニット１４は、また、ＴＣＰセグメント３６の細分化モジュールをも備え、その作用を以下に説明する。
【００７３】
ＩＰネットワークにおける本発明によるプロセスの適用の場合における特別な問題は、ＭＴＵ（最大送信ユニットの略、これは、一度だけ送信されるべきパケットの（オクテットにおける）最大サイズを表す）の発見の支援である。
【００７４】
現在の標準によれば、ＴＣＰプロトコルをインプラントする２つの機械間の中間ルータは、サイズがインターフェース（ＭＴＵ）上の最大の認可されたサイズを超え、かつＩＰヘッダの「フラグメントを含む」フラグが存在する、ＩＰパケットを削除する。また、ルータは、考慮されるインターフェース上にＭＴＵの値を含むＩＣＭＰメッセージ（インターネット・コントロール・メッセージ・プロトコルの略）をソース（送信元）に送信する。
【００７５】
もしこのようなルータが処理ユニット１４の下流に配置されるならば、送信器２は、後でルータによって削除されるであろうセグメントのための１つまたは２つ以上の予想される受取り通知を受信するであろう。
【００７６】
実際、もしユニットがＩＰレベルにおいて作用し、そしてＭＴＵがネットワークにおいて動的に固定されるならば、処理ユニット１４は、下流のルータによって削除されるであろうセグメントのための受取り通知を予想することができ、ＩＣＭＰパケット（インターネット・コントロール・メッセージ・プロトコルの略）の放出が、考慮される経路上のＭＴＵの値を特定する。このＩＣＭＰパケットは、適合されたサイズでパケットを後方に送信するであろう送信器端末２に達しなければならない。
【００７７】
しかしながら、もし処置ユニット１４がこのＩＣＭＰパケットを妨害することにも失敗したならば、再送信手順は、ＭＴＵを考慮することなくルータによって削除されるパケットの再送信に導く：再送信は、従って、ルータによって再度削除され、そして受信器端末４に決して達しないであろう。ＴＣＰセグメント３６の細分化モジュールは、従って、ダイナミックＭＴＵを示すＩＣＭＰパケットの妨害に対し、かつ下流のルータによって送られるＭＴＵに従う受取り通知されたセグメントの細分化に対し、責任がある。これらのセグメントは、次に、再送信マネージャ２８によって受信器端末４に直ちに再送信される。
【００７８】
本発明の特徴によれば、処理ユニット１４は、（たとえＩＰパケットが、位置付けられたフラグ“フラグメントを含む”を有するとしても）供給されるＭＴＵのサイズにこれらのセグメントを細分化することにより、衝突された接続の喪失されたセグメントを再送信するために、タイプ“経路ｍｔｕ発見”のＩＣＭＰメッセージを妨害する。次に、送信器２がＩＣＭＰメッセージによって知らされなかったちょうどそのときに、処理ユニット１４は、受取り通知されたセグメントを局部的に細分化する（フラグメント化する）。
【００７９】
ＴＣＰプロトコルを支援するために、処理ユニット１４は、以下の論理的インターフェースを備える：
・  ＴＳ_ｒｅｑｕｅｕｅ（ＴＳ_ｑｕｅｕｅ  ｑ、ＴＳ_ｐａｃｋｅｔ  ｐ）：受信器端末４に送信されるべきパケットの待ち行列の開始時にパケットのパラメータを挿入するよう意図される。
・  ＴＳ_ｒａｔｅ（ＴＳ_ｑｕｅｕｅ  ｑ）：このインターフェースは任意選択的であり、待ち行列パラメータの現在の送信レートを戻すよう意図されている。
・  ＴＳ_ａｖａｉｌｓｐａｃｅ（ＴＳ_ｑｕｅｕｅ  ｑ）：このインターフェースは任意選択的であり、待ち行列のバッファ・メモリの利用可能な量を戻すよう意図されている。このインターフェースは、システムが異なった物理的装置間に配分される場合には、特に、トラフィック・レギュレータ６及び処理ユニット１４が異なったネットワーク装置に一体化されている場合には、必要でないことが明らかである。
【００８０】
さて、本発明によるプロセスの異なった段階を図３、４及び５を参照して説明する。
【００８１】
図３は、送信器端末２によって送られる上流の流れのパケット・セグメントを処理するのを図式的に示す。
【００８２】
これらのセグメントは、それらを分類しそれらを適切なバッファ・メモリに配列する（矢印３０）、トラフィック・レギュレータ６によって最初に妨害される。
【００８３】
トラフィック・レギュレータ６は、次に、受信器４に送信されるべきセグメントを選択し、そしてそれを処理ユニット１４に出力する（矢印３２）。該セグメントは、次に、遅延なしでかつ変更なしで下流のネットワークを介して受信器端末４に送信される。
【００８４】
もしＴＣＰセグメントが有用なデータを移送するならば、処理ユニット１４は、それが送信器端末２に送信する（矢印３６）受信の受取り通知ＡＣＫを発生する。
【００８５】
図４は、受信器端末４によって送られる下流の流れのパケット・セグメントを処理するのを図式的に示す。
【００８６】
後者は、処理ユニット１４によって妨害され（矢印４０）、処理ユニット１４は、それらをフィルタリングし、検出されないパケットのヘッダを変更し、次に、それらのパケットを値ａｄｖ_ｗｎｄで送信器端末２に送信する。
【００８７】
図５は、受信器端末４へのパケットの再送信を図式的に示す。
【００８８】
再送信は、予め限定された臨界閾値よりも大きい重複された受取り通知の数を処理ユニット１４によって受信した後にか、または予め限定された再送信期間の満了に続いてかのいずれかで行われることに注意されたし。
【００８９】
処理ユニット１４が、臨界閾値よりも大きい重複された受信の受取り通知を受信したとき（矢印５０）、または予め限定された再送信期間の満了に続いて、ユニット１４の再送信管理モジュール２８は、再送信されなければならない１つまたは２つ以上のセグメントを選択する。この手順を以下の記載で詳細に説明する。
【００９０】
再送信されなければならないセグメントは、再送信バッファ・メモリのヘッドにそれを位置付けるトラフィック・レギュレータ６の入力に送り戻される（矢印５２）。セグメントがトラフィック・レギュレータ６のパケット・オーダラ（orderer）８によって選択されるとき、それは、処理ユニット１４における追加の処理なしで下流のネットワークのインターフェースに直接供給される（矢印５４）。
【００９１】
さて、本発明のプロセスの適用において行われる上流及び下流のセグメントの異なった処理ステップを、図６乃至９を参照して説明する。
【００９２】
上流パケットの処理
上流パケットを処理するためのステップを、図６を参照して以下に説明する。
【００９３】
ステップ１００において、トラフィック・レギュレータは、送信器端末２から受信されたフローの分類を行う。この分類は、予め限定されたトラフィック・フローにパケットを仕分けし、各フローに特定の処理を適用することから成る。従って、例えば、利用可能な帯域幅の部分がフローのために保存されていることができ、また他には、フローは、時間またはジッタ（jitter）制約を受けることができる。分類のために用いられるパラメータは、トラフィック・レギュレータ６の処理のレベルに依存する。実際、もしレギュレータ６がデータ・リンク層に拘束される（レベル２）ならば、単純な仮想回路またはチャンネル識別子が充分であり得るが、しかし反対にもしこのレギュレータ６がＩＰレベルで動作するならば、分類は、ＩＰヘッダの、またはＴＣＰまたはＵＤＰヘッダでさえの、もしくはパケットの関連内容（レベル７）でさえのフィールドの組合せを用いることができる。
【００９４】
一般に、分類の効果は、選択されたフローに専用の待ち行列にパケットを置くこと（ステップ１１０）であり、適合されたサービス規則が、待ち行列に適用される。ステップ１１１において、待ち行列が一層多くのメモリ空間を有しているか否かに関する確認が行われる。
【００９５】
もし有しているならば、適切な処理が、１つまたは２つ以上のパケットを検出するためにステップ１２０において実行される。
【００９６】
もし有していないならば、パケットは、待ち行列の最後に置かれ、分類器は、パケット・オーダラ（orderer）に知らせる（ステップ１３０）。
【００９７】
パケット・オーダラ８は、次に、適格のフローの中から送信されるべき次のパケットを選択する。選択されたパケットは、次に、処理ユニットＴＣＰ１４に送信される。
【００９８】
ユニット１４による受信の受取り通知の発生
処理ユニットＴＣＰ１４の役目は、受信の受取り通知（ＡＣＫ）を発生すること、並びに、ネットワークの下流の部分におけるパケットの送信期間とは無関係に送信器端末２にこの受信の受取り通知を送信して、トラフィック・レギュレータ６における対応のフロー・レートにこの端末２の送信レートを従動させる（スレーブさせる）ことである。
【００９９】
図７は、上流フローに適用される残りの処理を示すフローチャートである。
【０１００】
ステップ２００は、そこからセグメントを、特に受信されたパケットのＴＣＰヘッダを抽出するための上流フローの逆多重化である。このステップは、無効のパケットもしくはＴＣＰでないパケットをフィルタリングし、そしてトラフィック・レギュレータ６の処理のレベルに依存する。実際、もしレギュレータ６がレベル２で動作するならば、ステップは、最初に、有効なＩＰヘッダを抽出して確認しなければならない。
【０１０１】
ステップ２１０は、メモリ２４における処理中のＴＣＰセグメントに接続される接続ＴＣＰの制御構造を探索することから成る。このステップは、４つ組（ＩＰアドレス送信元、ＩＰアドレス送信先、ＴＣＰポート送信元、ＴＣＰポート送信先）の機能として正確な探索を行うための任意の適切なデータ構造を用いることができる。
【０１０２】
もしこの構造が存在しないもしくは「準備」状態にないならば、接続の準備完了段階がまだ完了しておらず、セグメントは、ＴＣＰ  ３ＷＨＳ手順（三方向ハンドシェークの略）に従ってステップ２２０において処理される。この手順は、準備完了手順の有効性、特に、ＳＹＮ及びＡＣＫシーケンス番号を確認することから成り、そして再送信機構、特に受信器４によって提供されるウィンドウを正しく計算するためのウィンドウ・スケール・ファクタ及びＳＡＣＫ支援（選択性受取り通知）に影響するこの段階中で交渉されるＴＣＰのオプションを記憶する。もし手順もしくは接続の状態が有効と見なされないならば、この接続は無視され、その制御構造は解放される。特に、もし処理ユニット１４が、例えば非対称ルートを用いて接続の２つの方向を妨害することに失敗したならば、この接続のセグメントは無視されるであろう。どんな予想される受信の受取り通知もＳＹＮセグメントに対して発生されず、それ故、遠隔機械における接続の状態を非同期化しない。
【０１０３】
接続が「準備」状態にあるとき、ステップ２３０は、ＴＣＰヘッダにおけるＦＩＮ及びＲＳＴフラグの存在を確認することから成り、これらは接続の閉鎖をマーキングし、そして制御構造は、再送信待ち行列が空になるや否や自由にされ得る（ステップ２４０）。接続のための上流のパケットは、次のオンから無視されるであろう。特に、該方法は、遠隔機械における接続の状態を非同期としないように、ＦＩＮセグメントのためのどんな局部ＡＣＫも（ＲＳＴも）発生しない。
【０１０４】
以下で説明するステップは、無視されるべきＴＣＰセグメントをフィルタリングする：
【０１０５】
・  ステップ２５０は、ＴＣＰセグメントの有用なロードがゼロであるか否かを確認することから成る。
【０１０６】
・  もしゼロであるならば、セグメントは、次に確認される必要のない純粋なＡＣＫであり、セグメントは無視される。
【０１０７】
・  ステップ２６０は、セグメントのチェックサムを確認することから成る。もし合計が無効であるならば、遠隔機械は、ＴＣＰスタックにおけるセグメントを無視するであろう。
【０１０８】
・  セグメントは、この確認の関数として無視されるまたは削除され得る。
【０１０９】
・  ステップ２７０は、最後のオクテットの順次番号を例えば次の予想される順次番号と比較する際にセグメントが送信器端末２によって再送信されるか否かを確認することから成る。
【０１１０】
送信器端末２によって再送信されるセグメントは、削除されなければならない。
【０１１１】
このレベルにおいて、ＴＣＰセグメントは、処理ユニット１４によってまだ妨害されていないオクテットを移送する（トランスポートする）：セグメントは、従って、受信器４に送信されることができる。
【０１１２】
ステップ２８０は、再送信待ち行列にセグメントのコピーを挿入することから成る。この待ち行列は、セグメントのオクテットの順次番号によって順番付けられる。
【０１１３】
もしセグメントの順次番号が、予想されたものではない、すなわち、受信されたセグメントが順番にないならば（ステップ２９０）、１つまたは２つ以上のセグメントが、ネットワークの上流部分において喪失されてしまっていることができる。処理ユニット１４は、次に、送信器端末２に重複された受取り通知、すなわち、以前に送ったのと正確に同じ受取り通知を送信する（ステップ２９５）。
【０１１４】
もしＳＡＣＫオプションが送信器及び受信器端末間で交渉されたならば、この受取り通知は、ＴＣＰ基準に従って、受信された最後のセグメントを示すＳＡＣＫステップを含むことができる。
【０１１５】
送信器２にインプラントされたＴＣＰスタックは、交渉された再送信機構（ＳＡＣＫまたはＲｅｎｏ）の関数として、必要ならば、この紛失したセグメントを再送信するであろう。
【０１１６】
もしセグメントの順次番号が予想されたものであるならば、処理ユニット１４は、送信器２に予想された受信の受取り通知を送信する。この受取り通知は、それが受信器４によって送られていたかのように、送信器２によって受信されかつ処理されるよう変造される。特に、受取り通知の順次番号は、上流セグメントの受信の受取り通知の順次番号であり、そして受信の受取り通知の順次番号は、再送信待ち行列にコピーされた最後のオクテットをカバーする。
【０１１７】
従って、問題は、ＴＣＰフロー制御のために用いられる受信ウィンドウを残す。これは、本発明によるプロセスが、接続の期間によって帯域幅の値のＢＤＰ（帯域幅−遅延プロダクト、ＢＤＰ）プロダクトを評価することから成るステップを備える理由である。
【０１１８】
（予想される受取り通知を含む）送信器２に送られるセグメントの受信ウィンドウにおける、ｂｄｐ_ｅｓｔｉｍとして示される、ＢＤＰの評価を示すことにより、送信器２によって送られるバースト（bursts）の長さを制御することが可能である。しかしながら、同様に、接続に割付けられたそのバッファ・メモリをオーバーフローさせることを避けるために、ｒｃｖ_ｗｎｄとして示される、受信器４のウィンドウ制限を尊重することも重要である。示されたウィンドウは、最後に、ｉｎ_ｆｌｉｇｈｔとして示される、未だ受取り通知されていない、かつ下流のネットワーク内を循環するかもしくは受信器４のバッファ・メモリにロードされる、オクテットの数を考慮しなければならない。
【０１１９】
第１の変形例において、たとえエラーの検出及びＴＣＰ  ＲＴＴの評価に基づいてこの評価を正確にすることが可能であるとしても、値ｉｎ_ｆｌｉｇｈｔは、再送信待ち行列の長さに等しいものとして考慮される。ＴＣＰソースにおいて示されるウィンドウは、従って、以下の式によりステップ３００において計算される：
ａｄｖ_ｗｎｄ＝ｍｉｎ（ｒｃｖ_ｗｎｄ−ｉｎ_ｆｌｉｇｈｔ、ｂｄｐ_ｅｓｔｉｍ）
【０１２０】
最後に、問題のウィンドウは、システム内におけるどんな喪失も避けるために、トラフィック・レギュレータ６におけるフローの待ち行列のオーバーフローを引き起すべきではない。
【０１２１】
好ましくは、レギュレータ６の待ち行列のメモリサイズは小型ではなく、ＴＣＰ接続のＢＤＰが与えられる。
【０１２２】
ステップ３１０は、ＲＴＯの受取り通知の待ち時間を計数することのトリガリングを管理すること、並びに受取り通知セグメント及び受信送信段階（ＡＣＫ）におけるＲＴＴ及びＢＤＰを評価すること、から成る。このステップ３１０を以下に一層詳細に説明する。
【０１２３】
ステップ３２０において、処理ユニット１４は、受取り通知されたセグメントのサイズをＭＴＵのサイズと比較する。
【０１２４】
ステップ３３０において、処理ユニット１４は、予想における受取り通知されたセグメントを細分化し、そのサイズは、ＭＴＵよりも大きい（ステップ３２０）。この細分化は、ＩＰ層のレベルにおいて行われる。
【０１２５】
分割されたパケット以外は、送信された上流パケットは、ＩＰヘッダへの変更を受けない、ということに注意されたし。ＴＣＰヘッダは、いずれの場合においても変更されない。
【０１２６】
下流パケットを処理
下流パケットのユニット１４による処理は、出力されないセグメントを検出してＴＣＰ基準の手順に従ってこれらのセグメントを再送信するよう送信器２に受信器４によって送られるＴＣＰ受取り通知を走査すること、並びに送信器２のレートを制御するようセグメントのＴＣＰヘッダを変更すること、の双方から成る。
【０１２７】
これらの処理ステップを図８及び図９を参照して詳細に説明する。
【０１２８】
下流処理は、ＴＣＰセグメントと、創設されたモードに関連されたその制御構造と、を抽出することに焦点を当てられた上流処理において説明された同じステップ２００、２１０、２２０及び２６０を備える。
【０１２９】
下流処理において、ステップ２６は、チェックサムを確認すること並びにその合計が無効であるセグメントを削除することから成る。もし合計が有効ならば、ＡＣＫフラグの確認は、ステップ４００において行われる。ＡＣＫフラグが位置付けられていないならば、セグメントは、無視される（一般に、これは、ＳＹＮ接続再開放セグメントである）。
【０１３０】
ステップ４１０から、当該方法は、輻輳の管理はないがエラーに関する回復だけを有する、受信モードにおけるＴＣＰプロトコルの申し立てるバージョンである。
【０１３１】
ステップ４１０は、受信の受取り通知ＡＣＫが重複されたか否か、すなわち、受信器４がその受信ウィンドウをオフセットしたか否かを確認することから成る。
【０１３２】
ステップ４２０は、１つまたは２つ以上のＴＣＰセグメントの再送信を生じることができる、ＴＣＰ  Ｎｅｗ  Ｒｅｎｏ及びＳＡＣＫ基準に従って、重複された受信の受取り通知ＡＣＫを管理することから成る。
【０１３３】
この手順を以下に詳細に説明する。
【０１３４】
Ｎｅｗ  Ｒｅｎｏ及びＳＡＣＫの再送信基準との厳密な互換性は、受信器４の及び送信器２のＴＣＰスタックを有するシステムの相互運用を保障する。
【０１３５】
もしＡＣＫ受信が重複されないならば、受信ＡＣＫの累積受取り通知によって受取り通知されたオクテットのメモリは、受信された受信番号の受取り通知よりも厳密に小さい順次番号のすべてのオクテットから自由にされる。
【０１３６】
ステップ４２５は、ＲＴＯ（及びＲＴＴ）並びにＢＤＰの期間を評価しかつ管理することから成る。
【０１３７】
ＲＴＴの評価は、ＴＣＰ基準に従うことができるかまたは任意の新しいアルゴリズムに適合することができる。当該方法のインプランテーションは、ＲＴＴの評価を正確にするために“タイムスタンプ”オプションを支援することができる。ＲＴＯ待ち時間の受取り通知は、ＴＣＰ基準に従って管理される。
【０１３８】
積（プロダクト）ＢＤＰの評価は、以下の２つの方法によって行われる：
【０１３９】
・  もしトラフィック・レギュレータ６が、接続に対応するフロー・レートにアクセスするためのインターフェースを有するならば、処理ユニット１４は、このインターフェースを用いて、このフローに統合されたＴＣＰ接続の数によって重み付けされるフロー・レートを、平均ＲＴＴで乗算することにより、ＢＤＰを評価する。
【０１４０】
・  もし有さないならば、ＢＤＰは、再送信待ち行列のサイズを監視することによってサンプリングされ得る。順次番号が、接続の制御構造に保持され、並びに、再送信されたセグメントを除いて、下流に送信されたオクテットの数が、下流のセグメントの受信の受取り通知の累積された数が特定の順次番号をカバーするまで、保持される。ＢＤＰは、重み付けされた平均として、または、送信されたオクテットのこれらの番号の最大として評価される。これは、“タイムスタンプ”オプションがない場合のＲＴＴのサンプリングに非常に類似した手順である。
【０１４１】
ＢＤＰの初期値は、送信器２が転送のすべての第１のセグメントを送信するのを阻止しなければならない。例えば、もし第１の予想された受信の受取り通知ＡＣＫがセグメントにウィンドウを位置付けるならば、値ｂｄｐ_ｅｓｔｉｍに起因して、送信器２は、その初期輻輳ウィンドウが、ＴＣＰ基準により推奨されるように１セグメントよりも大きい場合、完全なバーストを送信することができない。
【０１４２】
本発明の特徴によれば、ＢＤＰの評価は、従って、サンプリングされた値にセグメントの固定数、例えば、４〜８セグメントを加える。
【０１４３】
ステップ４３０は、受信器４のウィンドウの値ｒｃｖ_ｗｎｄを更新することから成る。
【０１４４】
上流処理におけるステップ２３０及び２４０に関して、ステップ４３２は、接続の閉鎖をマーキングするＴＣＰヘッダにおけるフラグＦＩＮ及びＲＳＴの存在を確認することから成る。制御構造は、再送信待ち行列が空になるや否やステップ４３５において自由にされる。
【０１４５】
ステップ４３８は、下流のセグメントの有用なロードのサイズを計算することから成る。
【０１４６】
もしこのサイズが、純粋な受取り通知セグメントに対応する、ゼロであるならば、プロセスは、受信の受取り通知の数またはウィンドウが、送られた最後のＡＣＫに対して展開したか否かを確認することから成るステップ４４０を介して続く。
【０１４７】
もし展開しなかったならば、セグメントは削除される。
【０１４８】
もし展開したならば、送信器２は、セグメントが、その再送信手順をゆがめるであろう重複の受取り通知であると考慮するであろう。すべての他の場合において、セグメントは、送信器２に送信されなければならない。
【０１４９】
しかしながら、送信器２のＴＣＰスタックによって有効化されるために、ＴＣＰヘッダの幾つかのフィールドがステップ４５０において変更される。この観点において：
・  受信の受取り通知の数は、発生された予想されたＡＣＫの最後の受信の受取り通知の数、すなわちこの数以上の数に対応しなければならない。この変更がない場合には、送信器２のＴＣＰスタックは、該セグメントを古すぎるもの（そのウィンドウの左エッジよりも小さい受信の受取り通知の数）として無視するか、または該セグメントを重複された受取り通知として考慮するかのいずれかを行うであろう。
【０１５０】
・  受信ウィンドウは、ｂｄｐ_ｅｓｔｉｍ、ｒｃｖ_ｗｎｄ及びｉｎ_ｆｌｉｇｈｔの新しい値を考慮するために再計算され得る。
【０１５１】
・  チェックサムは、ヘッダの２つの先行する変更を考慮するために固定されなければならない。
【０１５２】
ＴＣＰ再送信を処理
再送信されたセグメントは、トラフィック・レギュレータ６の制御機構への隠された再送信エッジ効果（例えば、「下流の」ネットワークに注入されるトラフィックのかなりの過小評価）を避けるために、トラフィック・レギュレータ６に従属しなければならない。
【０１５３】
再送信の処理を図９を参照して詳細に説明する。
【０１５４】
セグメント再送信は、「高速再送信」手順（ステップ５１０）をトリガするＴＣＰ  Ｎｅｗ  ＲｅｎｏまたはＳＡＣＫ（ステップ５００）に従って臨界値（概して３）よりも大きい重複された受取り通知の数の受信後に、または累積された受信の受取り通知が、規定された期間中に送信されたセグメントを包摂して受信されなかったということを示す、再送信タイムスイッチの満了（ステップ５２０）に続いて、のいずれかにおいて、ＴＣＰ手順に従って行われ得る。
【０１５５】
ステップ５３０は、再送信されなければならない再送信待ち行列の次のセグメントを送ることから成る。一般に、受信の受取り通知の数は、（特に２つの機械間の本当の双方向転送の場合において）送信器によって送られる最後の受信の受取り通知を反映するよう元のセグメントに対して変更されなければならない。この値は、従って、上流処理中に制御構造にロードされる。
【０１５６】
本発明によるプロセスの変形的な実施形態において、“タイムスタンプ”オプションを支持する接続の場合、タイムスタンプの値は、再送信の場合においてさえＲＴＴを測定するために、もしくは間違った再送信を検出するために、変更される。
【０１５７】
最後に、チェックサムが、ＴＣＰヘッダにおけるこれらの変更を考慮するために固定される（ステップ５４０）。
【０１５８】
図９は、幾つかのセグメントが失われてしまったということを決定することができる、ＴＣＰ  ＳＡＣＫ支持の場合におけるセグメント再送信ループを示す。セグメントの再送信は、何等の輻輳制御機構を用いないが、下流のネットワークを保護するためにトラフィック・レギュレーション（調整）段だけに依存するということに留意すべきである。
【０１５９】
特に、レギュレータ６が、再送信されたセグメントを送ってしまうと、これらの再送信されたセグメントの後の任意の新たな保留中のセグメントが次に送られるであろう。
【０１６０】
トラフィック・レギュレータ６は、オーバーフローの場合におけるこのパケットを削除する（ステップ５５０）ことなしに、任意の他の保留中のパケットの前に、待ち行列の頭にパケットを挿入するために通信インターフェースを介して処理ユニット１４に結合される、ということを思い起こすべきである。
【符号の説明】
【０１６１】
２      送信器
４      受信器
５      トラフィック制御最適化装置
６      トラフィック・レギュレータ
８      パケット・オーダラ
１０      制御モジュール
１２      通信インターフェース
１４      処理ユニット
２０      セグメント・デマルチプレクサ
２２      制御ステップのためのマネージャ
２４      メモリ
２６      第１のフィルタ
２８      再送信マネージャ待ち行列
２９      バッファ・メモリ
３０      第２のフィルタ
３２      予想された受取り通知発生器
３４      ＢＤＰのサンプラ
３６      ＴＣＰセグメントの細分化モジュール
【図１】
2010504672.tif 000003
【図２】
2010504672.tif 000004
【図３】
2010504672.tif 000005
【図４】
2010504672.tif 000006
【図５】
2010504672.tif 000007
【図６】
2010504672.tif 000008
【図７】
2010504672.tif 000009
【図８】
2010504672.tif 000010
【図９】
2010504672.tif 000011
【国際調査報告】
2010504672.tif 000012
2010504672.tif 000013
2010504672.tif 000014
2010504672.tif 000015
2010504672.tif 000016
2010504672.tif 000017