JP6303452B2 - 通信ノード - Google Patents

通信ノード Download PDF

Info

Publication number
JP6303452B2
JP6303452B2 JP2013249286A JP2013249286A JP6303452B2 JP 6303452 B2 JP6303452 B2 JP 6303452B2 JP 2013249286 A JP2013249286 A JP 2013249286A JP 2013249286 A JP2013249286 A JP 2013249286A JP 6303452 B2 JP6303452 B2 JP 6303452B2
Authority
JP
Japan
Prior art keywords
packet
link
queue
packets
tcp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013249286A
Other languages
English (en)
Other versions
JP2015106880A (ja
Inventor
哲明 鶴岡
哲明 鶴岡
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2013249286A priority Critical patent/JP6303452B2/ja
Priority to US14/557,486 priority patent/US9674095B2/en
Publication of JP2015106880A publication Critical patent/JP2015106880A/ja
Application granted granted Critical
Publication of JP6303452B2 publication Critical patent/JP6303452B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H04L47/323—Discarding or blocking control packets, e.g. ACK packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames

Description

本開示は、通信ノードに関する。
インターネットに代表されるように、近年におけるネットワークでは、ネットワーク層以下の層（レイヤ）は、パケット化されたデータをデータグラムとして宛先まで転送する機能をサポートするが、データが宛先に到着したことを保証しない。エンド・トゥ・エンド（End-to-End）の転送保証は、ネットワーク層の上位層、例えばTransport Control Protocol（ＴＣＰ）に代表されるトランスポート層のサービスを用いて実現される。以下、エンド・トゥ・エンドのトランスポート層サービスを用いた個々の通信を“コネクション”と称する。
上記したＴＣＰのような、トランスポート層サービスを用いてエンド・トゥ・エンドの転送保証を行うネットワーク構成では、多くの場合ベストエフォート型でネットワークが利用される。このため、例えば、ネットワークを流れるトラフィック量に応じて、送信可能なデータ量，すなわち通信可能な容量が変化する。
通信可能な容量の変化に対応するために、ＴＣＰは、輻輳検出アルゴリズムを具備し、通信量を制御する。輻輳検出アルゴリズムの例として、tahoeおよびその改良版reno/new renoと呼ばれる輻輳制御アルゴリズムが知られている。
特表２００８−５１１２０５号公報 特表２００１−５１０９５７号公報 特開２０１０−１８７１２９号公報
しかしながら、上記した輻輳検出アルゴリズムにおける通信量の制御は、以下のような単純なものであった。すなわち、パケットの廃棄（バッファのオーバーフロー）が検出されるまで、ラウンドトリップタイム（ＲＴＴ）あたりの送信パケット数（輻輳ウィンドウと呼ばれる）が１つずつ増やされる。一方、パケットの廃棄が検出されたときには、ＲＴＴあたりの送信パケット数が半分或いは最小値に低減される。このため、ＲＴＴが大きい場合には、十分な空き帯域があってもスループットが空き帯域を有効利用できるように上昇するまでに時間がかかり、実行通信速度が得られない、という問題があった。
特に、近年では、Long Term Evolution（ＬＴＥ）やWorldwide Interoperability for Microwave Access （WiMAX）のような、様々な無線通信規格に準拠する端末が、ネットワークと無線接続される形態が増えてきている。このような形態では、ＴＣＰコネクションは、無線区間に跨がって確立される。無線区間の帯域幅は、無線環境（端末の電波の受信状況）に応じて変動する。
良好なスループットを得るには、無線環境の変動に伴う帯域幅の増減に追従するように、データの送信レートが制御されることが好ましい。しかしながら、上記した輻輳検出アルゴリズムでは、無線環境の好転により帯域幅が増加しても、増加した帯域幅を利用できるように送信レートが上昇するまでに時間がかかる。一方、送信レートの低下は、バッフ
ァのオーバーフロー（パケットの廃棄）によって起こるため、再送手順がスループット向上の妨げとなる。上記問題は、無線リンクに限られず、環境の変化に応じて帯域変動が起こり得る有線リンクについても当てはまる。
本発明の態様の一つは、上述した事情に鑑みなされたものであり、エンド間にあるリンクの帯域に合わせたスループット調整を輻輳制御よりも短時間で実行可能とする技術を提供することを課題とする。
本発明の態様（aspect）の一つは、ウィンドウサイズを用いたフロー制御及び輻輳制御を行う特定のプロトコルに従って送信側のエンドと受信側のエンドとの間をパケットが流れるパケット転送路上に配置される通信ノードであって、
前記転送路上にあるリンクからパケットを受信する処理と、前記リンクへパケットを送信する処理とを行う通信インタフェースと、
前記リンクから受信される前記特定のプロトコルのパケット又は前記リンクへ送信される前記特定のプロトコルのパケットを一時的に蓄積するキューを記憶する記憶装置と、
前記リンクの受信側の現在の帯域に基づき、前記キューに蓄積されたパケットの滞留時間を調整する制御装置と、を含む。
本発明の態様の一つによれば、エンド間にあるリンクの帯域に合わせたスループット調整を輻輳制御よりも短時間で実行可能となる。
図１は、実施形態に係るネットワークシステムの構成例を示す。 図２は、実施形態１に係るトラフィック制御装置を含む通信ノードが適用されたネットワークシステムの例を示す。 図３は、ＴＣＰ（トランスポート層サービス）を用いたデータの転送例を示すシーケンス図である。 図４は、リンク帯域（ＢＷ）の変化に対する挿入遅延Ｄの変化の例を示す。 図５は、トラフィック制御装置の構成例を示す図である。 図６は、ＲＴＴ測定方法の一例を示す。 図７は、アップリンク転送における滞留時間調整の例を示す。 図８は、実施形態２に係るトラフィック制御装置の構成例を示す。 図９は、実施形態３に係るトラフィック制御装置の構成例を示す図である。 図１０は、実施形態４に係るトラフィック制御装置の構成例を示す。 図１１は、実施形態５に係る通信アダプタのハードウェア構成例を示す。 図１２は、ＣＰＵがトラフィック制御用のプログラムを実行することによって生じる機能を模式的に示す。 図１３は、コネクション管理テーブルのデータ構造例を示す。 図１４は、制御対象のパケットをキューに格納するまでの処理例を示すフローチャートである。 図１５は、ＴＣＰヘッダのフォーマットを示す。 図１６Ａは、ＴＣＰヘッダのオプションフィールドにセット可能なタイムスタンプオプションのフォーマット例を示す。 図１６Ｂは、タイムスタンプオプションの他のフォーマット例を示す。 図１７は、制御対象のキューに格納されたパケットの読み出し処理の例を示すフローチャートである。 図１８は、遅延量の付与方法の一例を示す。 図１９は、通信ノードの一例であるモバイルルータのハードウェア構成例を示す。 図２０は、通信ノードの一例である基地局のハードウェア構成例を示す。
以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
〔ネットワークシステムの例〕
図１は、本発明の実施形態に係るトラフィック制御装置を適用可能なネットワーク構成例を示す図である。図１において、ネットワークサービスのプロバイダによって管理及び運用されるプロバイダ網１がある。プロバイダ網１はインターネット２に接続されている。プロバイダ網１は、ルータのような中継装置や、ユーザ（端末）に対してアプリケーション（ＡＰＬ）に基づくサービスを提供するアプリケーションサーバ（ＡＰＬサーバ）１Ａなどを含む。
プロバイダ網１は、ブロードバンド・リモート・アクセス・サーバ (ＢＲＡＳ)３やゲ
ートウェイ（ＧＷ）４を介してアクセス網５と接続されている。アクセス網５は、例えば、E-UTRA（Evolved Universal Terrestrial Radio Access）/E-UTRAN（Evolved Universal Terrestrial Radio Access Network）や、無線ＬＡＮ（Local Area Network）に適用される様々な無線網である。但し、アクセス網５は、無線網に限られず、ＬＡＮも含み得る。プロバイダ網１，インターネット２，アクセス網５のそれぞれは、「ネットワーク」の一例である。
アクセス網５は、基地局（ＢＳ），フェムトＢＳ，アクセスポイントのような、端末と無線通信を行う無線機を備えている。図１には、アクセス網５に接続されたＢＳ６及びＢＳ７が示されている。プロバイダ網１も、端末と通信する無線機を有することができ、例として、フェムトＢＳ８が示されている。
端末は、アクセス網５の無線機（ＢＳ６，ＢＳ７，フェムトＢＳ８）と直接に無線通信を行う。或いは、端末は、無線アダプタ，Customer Premises Equipment（ＣＰＥ），テ
ザリング機能を有する通信機器（例えば、スマートフォン）を介して無線機と通信を行うことができる。ＣＰＥは、モバイルルータ，ブロードバンドルータ，セットトップボックス等を含む。
図１には、フェムトＢＳ８と無線通信を行う端末９と、ＢＳ７と無線通信を行う端末１０と、ＢＳ７と無線アダプタ（ＡＤ）１１を介して通信を行う端末１２と、ＣＰＥ１３を介して通信を行う端末１４とが図示されている。
端末は、例えば、スマートフォン，フィーチャーフォン，セルラーフォン，Personal Digital Assistant (ＰＤＡ)，パーソナルコンピュータ（ＰＣ），ワークステーションの
ような、ＴＣＰ／ＩＰ通信機能を有する様々なコンピュータである。ＰＣのタイプは、ラップトップ型，タブレット型，デスクトップ型のいずれでも良い。各端末は、ネットワーク（アクセス網５，プロバイダ網１）を介して、通信相手（Correspondent Node(ＣＮ)）と、ＴＣＰコネクションを確立し、ＴＣＰ／ＩＰ通信を行うことができる。
図１に示す例では、例えば、端末１２は、通信アダプタ１１，ＢＳ７，アクセス網５，ＧＷ４，プロバイダ網１，及びインターネット２を介してＣＮ１５と接続され、ＴＣＰ通信（ＴＣＰ／ＩＰ通信）を行う。ＴＣＰ通信にあたり、端末１２とＣＮ１５との間に、ＴＣＰコネクションが確立され、双方向のパケットフローが生じる。端末１２及びＣＮ１５は、それぞれの「エンド」に相当する。端末１２及びＣＮ１５は、双方向通信を行う。端
末１０及びＣＮ１５のそれぞれは、「送信側のエンド」及び「受信側のエンド」の一例である。
実施形態に係るトラフィック制御装置は、エンド間のＴＣＰコネクション上に位置する機器に実装される。例えば、帯域幅が変動するリンク（代表的には無線リンク）に対して直接的なパケットの送受信を行う通信機器（通信ノード）にトラフィック制御装置は実装される。
図１に示す例では、トラフィック制御装置は、ＢＳ６，ＢＳ７，フェムトＢＳ８のような網の無線機として機能する中継装置に実装可能である。また、トラフィック制御装置は、網の無線機との直接の通信機能を持つ端末（無線端末：図１では、端末９及び端末１０）に実装可能である。或いは、トラフィック制御装置は、無線アダプタ１１や、ＣＰＥ１３，及びテザリング機能を有する通信機器（中継装置）のそれぞれに実装可能である。
〔実施形態１〕
図２は、実施形態１に係るトラフィック制御装置を含む通信ノードが適用されたネットワークシステムの例を示す。図２に示すネットワークシステムは、クライアント２１が、ネットワーク２２を介して接続されたサーバ（ＣＮ）２３と双方向のＴＣＰ通信を行うクライアントサーバシステムである。クライアント２１は、トラフィック制御装置を含む通信ノード２０を介してネットワーク２２に接続される。
クライアント２１は、図１を用いて説明した端末に相当し、ネットワーク２２は、図１に示したアクセス網５，プロバイダ網１，インターネット２の少なくとも１つに相当する。サーバ２３は、図１を用いて説明したＣＮ１５に相当する。通信ノード２０は、図１に示したＣＰＥ１３に相当し、例えば、モバイルルータである。
通信ノード２０は、ネットワーク２２側のリンク２４と接続される通信インタフェース（図示せず）と、クライアント２１側のリンク２５と接続される通信インタフェース（図示せず）とを含む。クライアント２１とサーバ２３とは、ＴＣＰ通信の開始に当たって、リンク２５，通信ノード２０，リンク２４，ネットワーク２２を介してＴＣＰコネクションを確立する。
そして、ＴＣＰコネクション（ＴＣＰ回線）を用いて、パケット（ＴＣＰ／ＩＰパケット）がクライアント２１とサーバ２３との間で送受信される。通信ノードは、リンク２４から受信されるダウンリンク方向のパケットをリンク２５に送信（中継）する一方で、リンク２５から受信されるアップリンク方向のパケットをリンク２４に送信（中継）する。なお、ダウンリンク方向は、「第１方向」の一例であり、アップリンク方向は、「第２方向」の一例である。また、リンク２４は、「第１リンク」の一例であり、リンク２５は、「第２リンク」の一例である。
ＴＣＰパケットの送受信によって、サーバ２３からクライアント２１へ向かう方向（ダウンリンク方向とする）のパケットのフローと、クライアント２１からサーバ２３へ向かう方向（アップリンク方向とする）のパケットのフローとが生じる。これらのフローは、ＴＣＰコネクションに基づくパケットフローとして管理される。パケットフローは、プロトコル種別（例えば、ポート番号）や、ＴＣＰコネクションの識別子（例えば、送信元及び宛先ポート番号並びに送信元及び宛先ＩＰアドレスの組み合わせ）によって識別される。
ＴＣＰによって、サーバ２３が、クライアント２１に提供すべきデータブロック（ＴＣＰでは「セグメント」と呼ばれる）を含んだＴＣＰ／ＩＰパケット（データパケットと呼
ぶ）Ｐ１をクライアント２１へ送信する。データパケットＰ１は、データパケットＰ１を識別するためのシーケンス番号を含んでいる。クライアント２１は、データパケットＰ１が正常に受信されたとき、正常に受信されたパケットのシーケンス番号に対応する確認応答番号を含む肯定応答（Acknowledgement：ＡＣＫ（確認応答））を含んだパケット（Ａ
ＣＫパケット）Ｐ２をサーバ２３へ送信する。サーバ２３は、ＡＣＫパケットを受信することで、データパケットＰ１が正常に受信されたことを認識する。ＡＣＫパケットの受信を契機にサーバ２３は、次のデータパケットＰ１を送信する。クライアント２１がサーバ２３へデータパケットＰ１を送信する場合には、上記と逆の動作が行われる。
図３は、ＴＣＰ（トランスポート層サービス）を用いたデータの転送例を示すシーケンス図である。送信側エンド（以下単に「送信側」と記載することもある。図２ではサーバ２３）は、ウィンドウサイズ（Win）に応じて、それぞれ異なるシーケンス番号を有する
１以上のデータパケットＰ１（実線矢印）を送信する。ウィンドウサイズは、受信側エンド（以下単に「受信側」と記載することもある。図２ではクライアント２１）の確認応答を待つ（受信する）ことなく送信可能なデータ量（ＲＴＴ当たりの送信データパケット数）を示す。受信側では、受信されたデータパケットに対するＡＣＫパケットＰ２（破線矢印）を送信する。ＡＣＫパケットＰ２には、受信された複数のシーケンス番号を含めることができる。図３の例では、４つのデータパケットＰ１に対して、２つ分のデータパケットに対するＡＣＫパケットＰ２が送信されている。
ウィンドウサイズは、受信側からのＡＣＫパケットＰ２にて示され、送信側は、ウィンドウサイズの範囲で、ＡＣＫパケットＰ２を待つことなくデータパケットＰ１を送信することができる。送信データ量がウィンドウサイズに達すると、送信側は、データパケットＰ１の送信を停止し、ＡＣＫパケットＰ２の受信を待つ。そして、送信側は、ＡＣＫパケットＰ２を受信したとき、当該ＡＣＫパケットＰ２で示されるウィンドウサイズがデータパケットＰ１の送信を許容する場合には、次のデータパケットＰ１の送信を行う。これに対し、送信側は、或る期間内にＡＣＫパケットＰ２を受信できない場合、対応するデータパケットＰ１の再送を行う。これによって、クライアント２１に対するデータパケットＰ１の転送が保証される。上記制御は、一般に、フロー制御と呼ばれている。
送信側では、或るシーケンス番号のデータパケットＰ１が送信されてから、当該シーケンス番号に対応する確認応答番号を含むＡＣＫパケットＰ２が受信されるまでの時間が、ラウンドトリップタイム（ＲＴＴ）として観測される。或るデータパケットＰ１に対するＡＣＫパケットＰ２の受信を送信側が待つ時間（待ち時間）は、ＲＴＴに基づいて決定される。待ち時間が満了してもＡＣＫパケットＰ２が受信されないとき、送信側は、データパケットＰ１の再送を行う。
また、ＴＣＰでは、上記したフロー制御と並列に以下のような輻輳制御が行われる。すなわち、ＴＣＰでは、コネクション確立時に受信側から通知されたウィンドウサイズに拘らず、ウィンドウサイズの初期値を所定値（例えば最小値）に設定し、データパケットＰ１を受信側に送る。送信側は、受信側からデータパケットＰ１のＡＣＫパケットＰ２を受信する毎に、ウィンドウサイズを徐々に（例えば、ＲＴＴ当たりパケット１個分）増加させる。データパケットＰ１又はＡＣＫパケットＰ２のロストが起きなければ、ウィンドウサイズは、最終的に、コネクション確立時に通知されたウィンドウサイズ（最大ウィンドウサイズ）となる。このようなウィンドウサイズの制御はスロースタート制御と呼ばれる。一方で、例えば、データパケットＰ１の転送路上のバッファ溢れによって或るデータパケットＰ１がロストし、当該或るデータパケットＰ１に対するＡＣＫパケットＰ２が送信側で受信されない場合（待ち時間が満了した場合）がある。このとき、送信側は、輻輳検出アルゴリズムによって、ウィンドウサイズを所定値（例えば、最大ウィンドウサイズの半分の値、或いは最小値）に低下させる。その後、スロースタート制御によって、再びＡ
ＣＫパケットの受信状況に応じてウィンドウサイズを徐々に増加させる処理が行われる。
本実施形態では、通信ノード２０がリンク２４からデータパケットＰ１を受信する方向（受信側）におけるリンク２４の帯域の変動に応じて、リンク２４へ送信するＡＣＫパケットＰ２のキューにおける滞留時間を制御する例について説明する。
図２に戻って、通信ノード２０は、トラフィック制御装置２６を含む。通信ノード２０は、リンク２４及び２５に対して、上記したパケットフローのパケット（データパケットＰ１，ＡＣＫパケットＰ２）についての直接な送受信を行う。
トラフィック制御装置２６は、パケットフローのパケット（データパケット、ＡＣＫパケット）を一時的に滞留させるキュー（バッファ）を有する。図２に示す例では、トラフィック制御装置２６は、ダウンリンク方向のパケット（データパケットＰ１）を一時的に蓄積可能なキュー２７と、アップリンク方向のパケット（ＡＣＫパケットＰ２）を一時的に蓄積可能なキュー２８とを含む。トラフィック制御装置２６は、キュー２７及びキュー２８におけるパケットの滞留時間を調整（制御）することができる。図２の例では、キュー２８における滞留時間が調整（制御）される。これら滞留時間が調整（制御）可能なキューは、双方向に設けても良いが、一方向のみに設けることもできる。
リンク２４は、例えば、無線リンクであり、環境の変化に伴ってリンク２４の帯域幅（以下単に帯域と表記）が変動する特性を有する。トラフィック制御装置２６は、例えば、リンク２４を監視対象のリンクとし、リンク２４の受信側の帯域を監視する。以下の説明は、リンク２４の受信側が監視対象である場合について説明するが、リンク２４とリンク２５との双方の受信側の帯域が監視対象であっても、リンク２５の受信側のみが監視対象であっても良い。リンク２５が監視される場合の動作は、制御対象のパケット及びキューが異なる点を除き、以下に説明するリンク２４に関する動作及び処理と同じである。なお、監視対象のリンクは、無線リンクに限定されず、有線リンクであっても、環境の変化に応じて帯域が変動するリンクは、監視対象のリンクとなり得る。
トラフィック制御装置２６は、通信ノード２０を通過するＴＣＰコネクションに関して、データパケットＰ１に含まれたシーケンス番号，ＡＣＫパケットＰ２に含まれたシーケンス番号（応答番号）を含むヘッダ情報を観測する。また、トラフィック制御装置２６は、パケットのＲＴＴの観測を行う。
トラフィック制御装置２６は、リンク２４の帯域に応じてＡＣＫパケットＰ２の遅延時間（遅延量）を調整する。遅延量の調整は、キュー２８におけるＡＣＫパケットＰ２の滞留時間の調整によって行われる。リンク２４の受信側の帯域が大きいときに滞留時間が短く、リンク２４の受信側の帯域が小さいときに滞留時間が長くなるように調整される。
ここに、ウィンドウサイズ（Win[bit]）をＲＴＴ[sec]で除した時のデータ帯域値[bit
／sec]は、実効スループットを表す（Win／RTT＝実効スループット）。ウィンドウサイズとＲＴＴとを掛けたもの（Win×RTT）は、帯域幅遅延積（ＢＤＰ）と呼ばれる。実効スループットがリンク帯域（ＢＷ）に達していれば（実効スループット＝リンク帯域（ＢＷ））となる。したがって、ウィンドウサイズがＢＤＰに達することは、リンク帯域を使い切ることを意味する。
上記に鑑み、トラフィック制御装置２６は、例えば、リンク２４の受信側の帯域が最大であるときに、ＡＣＫパケットＰ２に与える遅延量（滞留時間）が０となることを基準として、遅延量（滞留時間）を調整する。具体的には、トラフィック制御装置２６は、リンク２４の帯域が最大帯域から低下している量に合わせて、キュー２８におけるパケット（
ＡＣＫパケットＰ２）の滞留時間を調整する。最大帯域は、リンク２４の物理的な帯域を上限として、適宜設定可能である。
すなわち、帯域遅延積(ＢＤＰ＝Win×RTT)における“帯域”の増減を“遅延（滞留時間）”の増減で吸収し、パスのＢＤＰが結果的に維持されるように、トラフィック制御装置２６は、最大帯域からの低下量に応じた遅延（以下、「挿入遅延」、「挿入遅延Ｄ」と表記）を追加する。すなわち、トラフィック制御装置２６は、キュー２８に蓄積されたＡＣＫパケットＰ２の滞留時間を制御する。これによって、ＴＣＰコネクションにおける輻輳ウィンドウサイズの変更なく、送信レートを維持可能となる。
換言すれば、以下の式（１）を満たす挿入遅延Ｄが、リンク２４（帯域変動リンク）の通信可能帯域（ＢＷ）に合わせて挿入される。
（ＲＴＴ+Ｄ）×ＢＷnow ＝ ＲＴＴ×ＢＷmax ・・・（１）
但し、ＢＷnowは、帯域変動リンクにおける現在の通信可能帯域であり、ＢＷmaxは、帯域変動リンクにおける最大通信可能帯域である。上記式（１）の変形によって、挿入遅延Ｄは、以下の式（２）で求めることができる。
Ｄ ＝ ＲＴＴ ×（ＢＷmax − ＢＷnow ／ ＢＷnow） ・・・（２）
挿入遅延Ｄの算出に伴い、キュー２８におけるパケットの滞留時間が変更される。このとき、現在の滞留時間を、いきなり挿入遅延Ｄに応じた滞留時間に変更することは好ましいことではない。例えば、スループットが最大値３０Mbpsから５Mbpsに低下した場合を考える。このとき、本来のＲＴＴが１０msであったと仮定すると、５Mbpsのときの挿入遅延Ｄは５０msとなる。しかしながら、このような５０msの遅延が一時に加えられると、遅延（滞留時間）が増加したタイミングでＡＣＫパケットＰ２の間隔が５０ms空いてしまう。一方、ＲＴＴが５msに戻されるときに、状況次第ではＡＣＫパケットＰ２の順序の入れ替えが必要となる。
このため、遅延量の増減が発生した場合は、トラフィック制御装置２６は、徐々に遅延量を増減させて、最終的に挿入遅延Ｄの値に応じた滞留時間に到達するように、滞留時間を制御する。このように、遅延量を連続的に変化させることで、不要なパケット間隔の発生や追い越しを回避することができる。
過渡期においては、遅延が印加（挿入）される前の経過時間ΔＴは、変化前の帯域ＢＷprevに従っており、経過時間ΔＴを変化後の帯域ＢＷnewに相当するものに換算する。遅
延印加後に見える時間経過ΔＴ’は、以下の式（３）で表される。
ΔＴ’＝ΔＴ×ＢＷprev／ＢＷnew ・・・（３）
式（３）より、遅延の付加量の変化ΔＤは、下記の式（４）となり、遅延量の変化の勾配Ｋは、以下の式（５）で求められる。
ΔD = ΔT'−ΔT = ((BWprev/BWnew)−1)ΔT ・・・（４）
となり、遅延量の変化の勾配Ｋは以下の式（５）で求められる。
K = (BWprev/BWnew)−1 ・・・（５）
この結果、遅延を挿入する時刻ｔにおける遅延量Ｄ（ｔ）は、以下の式（６）で表すことができ、過渡期において、ＢＷprev相当のＡＣＫパケットの送信ペースをＢＷnew相当の
ＡＣＫパケットの送信ペースに換算することができる。
D(t)=D(t0)+K(t−t0) ・・・（６）
図４は、リンク帯域（ＢＷ）の変化に対する挿入遅延Ｄの変化の例を示す。図４に示すグラフの横軸は時間であり、縦軸は、リンク帯域（ＢＷ）及び遅延量を示す。リンク帯域ＢＷは、０から所定の最大値ＢＷmaxまでの間を変動し得る。グラフ中の塗りつぶされた
範囲は、時間経過に伴うリンク帯域ＢＷの変動を示す。実線の折れ線グラフは、リンク帯域ＢＷに応じた挿入遅延Ｄの変化を示す。破線の折れ線グラフは、挿入遅延Ｄと伝送路遅延等の本来生じる遅延とを合算した遅延を示す。このように、リンク帯域ＢＷと、挿入遅延Ｄとは反比例するように変化する。但し、挿入遅延Ｄは、勾配Ｋで目的の遅延量まで徐々に連続的に変動する。
このように、個々のＴＣＰコネクション毎に、監視対象のリンク帯域の変動に合わせてＲＴＴが変動し、帯域遅延積（ＢＰＤ）を維持されれば、ＴＣＰにおいて輻輳ウィンドウサイズが変化しない（輻輳制御によるウィンドウサイズの低下を回避し得る）状態で、適正なスループットで送信がなされる。複数のＴＣＰコネクションが同一のリンクを共用する場合においても、各ＴＣＰコネクションに関して同じ比率で送信レートが増減する。このため、全体の比率が維持される。
図５は、トラフィック制御装置の構成例を示す図である。図５に示すトラフィック制御装置は、環境の変化に伴ってダウンリンク方向の帯域変動が生じるリンク２４を監視する。トラフィック制御装置は、監視対象のリンクにおける帯域変動に応じて、当該リンクを通過する、ＴＣＰ又はＴＣＰ相当のプロトコル（上記したフロー制御及び輻輳制御が行われるプロトコル）に従って生成されたパケットフローに関して、確認応答パケット（ＡＣＫパケットＰ２）の遅延量（滞留時間）を調整する。
図５の例では、ダウンリンク方向のリンクの帯域変動に対応する構成を例示する。但し、アップリンク方向の帯域変動にも対応するように、遅延挿入をダウンリンク方向のキュー（キュー２７）にも適用することができる。
図５には、端末２１Ａと通信相手（Correspondent Node: CN）２３Ａとが図示されている。端末２１Ａは、図２に示したクライアント２１に相当し、ＣＮ２３Ａは、図２に示したサーバ２３に相当する。通信ノード２０は、端末２１Ａとリンク（図示略）を介して接続される一方、リンク２４を介してネットワーク（ＮＷ）２２に接続されたＬ２対向装置２２Ａと接続される。Ｌ２対向装置２２Ａは、例えば基地局であり、リンク２４は、無線リンクであり、環境の変化に伴って帯域幅が変動する。
端末２１Ａは、複数のアプリケーション（ＡＰＬ）４１と、ＴＣＰをサポートするＴＣＰ機能４２とを有している。ＣＮ２３Ａも、端末２１Ａと同様に、複数のアプリケーション（ＡＰＬ）５１と、ＴＣＰ機能５２とを有している。
端末２１Ａの或るＡＰＬ４１は、ＣＮ２３Ａの或るＡＰＬ５１とのＴＣＰ通信によって、データの授受を行う。ＡＰＬ４１とＡＰＬ５１とのＴＣＰ通信開始に当たり、ＴＣＰ４２とＴＣＰ５２との間でＴＣＰコネクションが確立される。ＴＣＰコネクション上で、双方向のパケットフローが生成される。パケットフローは、端末２１Ａから通信ノード２０，リンク２４，Ｌ２対向装置２２Ａ，ＮＷ２２を通ってＣＮ２３Ａに到達するアップリンク方向のフローと、ＣＮ２３ＡからＮＷ２２，Ｌ２対向装置２２Ａ，リンク２４，通信ノード２０を通って端末２１Ａに到達するダウンリンク方向のフローとからなる。
ＣＮ２３Ａの或るＡＰＬ５１は、端末２１Ａへ送信すべきデータをＴＣＰ機能５２に送る。ＴＣＰ機能５２は、データにＴＣＰヘッダを付与する。さらに、ＣＮ２３Ａでは、ＩＰヘッダの付与、レイヤ２，レイヤ１の処理が行われ、パケットが端末２１Ａへ向けて送信される。
通信ノード２０は、トラフィック制御装置２６を有している。トラフィック制御装置２６は、ダウンリンク方向のパケットを一時的に蓄積するキュー（バッファ）２７と、アップリンク方向のパケットを一時的に蓄積するキュー（バッファ）２８とを有している。さらに、トラフィック制御装置２６は、受信処理部３１と、リンク帯域検出部３２と、ＲＴＴ測定部３３と、滞留時間制御部３４と、送信処理部３５とを有している。キュー２７は、ＣＮ２３Ａから送信されるデータパケットを蓄積し、キュー２８は、端末２１Ａから送信されるＡＣＫパケットを蓄積する。
受信処理部３１は、ＣＮ２３Ａから送信された、或るＴＣＰコネクションに係るパケットの受信処理を行い、パケットをキュー２７に送る。キュー２７に蓄積されたパケットは、所定の滞留時間が経過した後に読み出され、端末２１Ａへ送られる。端末２１Ａでは、ＴＣＰ機能４２を経て、パケット中のデータが宛先に相当するＡＰＬ４１に与えられる。ＴＣＰ機能４２は、パケット（データパケット）に対するＡＣＫパケットを生成し、通信ノード２０へ送信する。
リンク帯域検出部３２は、リンク２４のダウンリンク方向の帯域（通信速度）を検出する。リンク帯域は、例えば、リンク２４に対する物理層制御に関する情報に基づき検出することができる。リンク帯域の計測方法は、既存のあらゆる手法を適用可能である。
ＲＴＴ測定部３３は、或るＴＣＰコネクションに係るＲＴＴを測定する。図６は、ＲＴＴ測定方法の一例を示す。ＲＴＴは、所定の区間始点（例えばキュー２７）からクライアント２１（端末２１Ａ）を経由して所定の区間終点（例えばキュー２８）に達するまでの区間（図６の矢印出示す区間（１））と、所定の区間始点（例えばキュー２８）からサーバ２３（ＣＮ２３Ａ）を経由して所定の区間終点（例えばキュー２７）に達するまでの区間（図６の矢印で示す区間（２））における遅延時間を合算して計測する。
＜＜手法１＞＞
手法１として、以下の手順で測定が可能である。区間（１）に関しては、ＲＴＴ測定部３３は、区間（１）の始点を通過する（キュー２７から読み出される）データパケットのシーケンス番号と、その通過時刻（読み出し時刻）を記憶する。その後、ＲＴＴ測定部３３は、記憶したシーケンス番号に対応する確認応答番号を含むＡＣＫパケットが区間（１）の終点（キュー２８）に達したときの到着時刻を検出し、読み出し時刻と到着時刻との差分から区間（１）の遅延時間を算出する。
一方、区間（２）に関しては、ＲＴＴ測定部３３は、ＴＣＰコネクションの確立時に送受信される、端末２１ＡからＣＮ２３ＡへのＳＹＮパケット又はＳＹＮ+ＡＣＫパケット
の区間（２）の始点の通過時刻を記憶する。その後、ＲＴＴ測定部３３は、上記ＳＹＮパケット又はＳＹＮ＋ＡＣＫパケットに対応するＳＹＮ＋ＡＣＫパケット又はＡＣＫパケットの区間（２）の終点の通過時刻（例えば、キュー２７へ達したときの時刻）を得る。ＲＴＴ測定部３３は、通過時刻の差分から、区間（２）の遅延時間を得る。そして、ＲＴＴ測定部３３は、区間（１）の遅延時間と区間（２）の遅延時間とを合算することによって、ＲＴＴを得ることができる。
＜＜手法２＞＞
或いは、区間（１）及び区間（２）の双方に適用可能な測定方法として、タイムスタンプ情報を含むパケットを利用する方法（手法２）がある。すなわち、Request For Comments（ＲＦＣ）１３２３には、タイムスタンプ情報を含むタイプスタンプオプションが規定されており、オプションヘッダには、ＴＣＰパケットのタイムスタンプ値（ＴＳ値）と、その応答値（TS Echo Reply：タイムスタンプエコー値）とを格納することができる（図
１６Ａ，図１６Ｂ参照）。
この場合、ＲＴＴ測定部３３は、区間（１）の始点を通過するパケットに含まれたタイムスタンプ値と、その通過時刻とを記憶する。その後、記憶されたタイプスタンプ値がタイムスタンプエコー値として設定されたパケットが区間（１）の終点に達したときの時刻を検出し、通過時刻と到達時刻との差分から、区間（１）の遅延時間を得る。ＲＴＴ測定部３３は、区間（２）についても同様の処理を行い、区間（２）の遅延時間を得る。そして、区間（１）及び区間（２）の遅延時間の合計値をＲＴＴとして算出する。
図５に戻って、滞留時間制御部３４は、リンク帯域検出部３２からリンク帯域の情報（ＢＷnow）を受け取るとともに、ＲＴＴ測定部３３からＲＴＴを受け取る。滞留時間制御
部３４は、リンク帯域の情報及びＲＴＴを用いて、上記した式（２）を用いて挿入遅延Ｄを算出するとともに、式（５）を用いて勾配Ｋを算出する。さらに、滞留時間制御部３４は、遅延量Ｄ（ｔ）を式（６）を用いて算出し、遅延量Ｄ（ｔ）に応じた滞留時間で、キュー２８からＡＣＫパケットを読み出す。送信処理部３５は、キュー２８から読み出されたＡＣＫパケットに対する送信処理を行う。これによって、ＡＣＫパケットがリンク２４へ送出される。
ＣＮ２３Ａは、送信データ量がウィンドウサイズに達していれば、ＡＣＫパケットの到着を待って次のデータパケットの送信を行う。このため、ＡＣＫパケットの送信タイミングの調整で、ＣＮ２３Ａからのデータパケットのスループット（送信レート）が制御される。図３に示したように、リンク２４の帯域が低下した場合には、遅延量（滞留時間）を増加し、リンク２４の帯域が増加した場合には、遅延量（滞留時間）を低下させて、理想的には帯域と遅延量とが反比例するような制御を行う。
＜実施形態１の作用効果＞
実施形態１によれば、或るＴＣＰコネクションに係るパケットフローに関して、監視対象のリンク２４（帯域可変リンク）の受信側のリンク帯域とＲＴＴとに基づき、ＡＣＫパケットに対するキュー２８での滞留時間が調整される。すなわち、フロー制御では、送信側でのデータ送信量がウィンドウサイズに達している場合、ＡＣＫパケットを受信するまで送信側からのデータパケットの送信は停止される。このとき、ＡＣＫパケットがキュー２８で滞留すると、送信側へのＡＣＫパケットの到着が遅延し、送信側からのデータパケットの送信タイミングが遅れる。すなわち、送信側における単位時間当たりのデータ送信量が減る。これは、データパケットの転送路上でのバッファ溢れが回避される方向に作用する。上記のように、キュー２８での滞留時間は、リンク２４の受信側の最大帯域からの低下量に応じて決定される。従って、キュー２８から読み出されるＡＣＫパケットがパケット転送路上でロストせず、待ち時間内に送信側へ到着する限り、輻輳制御によるウィンドウサイズの大幅な低下は起こらない。すなわち、ウィンドウサイズが維持された状態で、データパケットの送信レート（スループット）がリンク２４の受信側の帯域低下に応じて低下する状態となる。一方、リンク２４の受信側の帯域が、或る値から最大帯域へ向けて上昇する場合には、ＡＣＫパケットのキュー２８での滞留時間が短くなる。このため、ＡＣＫパケットの到着タイミング及び送信側からのデータパケットの送信タイミングが早まる。従って、単位時間当たりのデータ送信量がリンク２４の受信側の上昇に伴って増える。このように、実施形態１によれば、ウィンドウサイズが維持されることで、ＴＣＰの輻輳制御による送信レート制御（すなわち、ＡＣＫパケットの受信不可（例えばデータパケットのロスト）に伴うウィンドウサイズの大幅な低下及びスロースタート制御によるウィンドウサイズの増加）に比べて、リンク２４の受信側の帯域変動（低下及び上昇）に短時間で追従可能な送信レート（スループット）の調整を行うことができる。
換言すれば、実施形態１に係るトラフィック制御装置は、無線リンクのように帯域幅が
環境条件で変動するようなリンクに対し送受信を行う通信ノード（通信アダプタ，或いは中継装置など）に設けられる。トラフィック制御装置は、当該リンクを流れるトラフィックがＴＣＰ又はＴＣＰ相当のスループット（トラフィック）制御機構を有しているときに、リンクの帯域に応じて付加的に与える遅延量を調整することによって、リンク帯域に応じたスループットに調整することが可能となる。
＜変形例＞
実施形態１の構成は、次のような変形が可能である。例えば、上記したリンク帯域ＢＷの変動に応じた挿入遅延Ｄの変動を行うトラフィック制御が適用されるプロトコルは、ＴＣＰに限られず、ＴＣＰと同等のスループットの制御方法（フロー制御及び輻輳制御）を用いるプロトコルについても適用が可能である。また、上記した例では、１つのＴＣＰコネクション（パケットフロー）に対する挿入遅延Ｄの増減について説明したが、複数のＴＣＰコネクションや、或いはＴＣＰと非ＴＣＰのプロトコルとをひとまとめにしたトラフィックに対し本制御を実行することも可能である。
また、図２及び図５の例では、ダウンリンク転送におけるＡＣＫパケットの滞留時間調整について説明した。これに対し、トラフィック制御装置２６は、アップリンク転送において、ＡＣＫパケットの滞留時間調整を行うこともできる。
図７は、アップリンク転送における滞留時間調整の例を示す。アップリンク転送では、クライアント２１からサーバ２３へデータパケットＰ１が転送され、サーバ２３がクライアント２１へＡＣＫパケットを転送する。この場合、キュー２８の代わりに、キュー２７におけるＡＣＫパケットＰ２に対する挿入遅延Ｄがリンク２４のアップリンク方向の帯域の増減に怖じて増減する制御（滞留時間調整）が行われる。詳細は、実施形態１におけるキュー２８に対する制御と同様であるので説明は省略する。トラフィック制御装置２６は、ダウンリンク転送の代わりに、或いは、ダウンリンク転送及びアップリンク転送の双方に関して、ＡＣＫパケットの滞留時間調整を実行することができる。
また、図２及び図７に示した例では、キュー２８（図２），キュー２７（図５）におけるＡＣＫパケットＰ２の遅延量（滞留時間）を調整する例について説明した。但し、ＡＣＫパケットの滞留時間調整に加えて、或いはＡＣＫパケットの滞留時間調整の代わりに、キュー２７及びキュー２８の少なくとも一方におけるデータパケットＰ１に対する遅延量の増減（滞留時間調整）が行われても良い。
〔実施形態２〕
次に、本発明の実施形態２について説明する。実施形態２は、実施形態１と同様の構成を有するため、共通の構成についての説明は省略し、主として相違点について説明する。
実施形態１では、ＴＣＰ又はＴＣＰ相当のプロトコル、すなわち、ＲＴＴ及びウィンドウサイズ制御（フロー制御及び輻輳制御）でスループット（送信レート）が制御されるプロトコルに係るパケットフローに関するトラフィック制御について説明した。
もっとも、通常、端末と通信相手（ＣＮ）とは、例えばUser Datagram Protocol（ＵＤＰ）のような、ＴＣＰ以外のプロトコル（「非ＴＣＰプロトコル」と称する）に基づく通信も行う。実施形態２では、パケットのプロトコル種別によって、付加的な遅延（挿入遅延Ｄ）を与えるかどうかを選択可能とするトラフィック制御装置について説明する。
図８は、実施形態２に係るトラフィック制御装置の構成例を示す。実施形態２は、実施形態１の構成（図５）において、トラフィック制御装置２６の代わりにトラフィック制御装置２６Ａが適用される点において、実施形態１と異なる。但し、トラフィック制御装置
２６Ａ以外の構成については実施形態１（図５）と同じであるので説明を省略する。
図８において、トラフィック制御装置２６Ａは、以下の点でトラフィック制御装置２６（図５）と異なる。すなわち、トラフィック制御装置２６Ａは、トラフィック制御装置２６が備える構成に加えて、端末２１Ａからのパケットを受信するプロトコル振分部３８と、制御対象キュー２８Ａと、非制御対象キュー２８Ｂと、スケジューラ３９とさらに含む。
プロトコル振分部３８は、プロトコルの判別部の一例であり、例えば、受信されたパケットのヘッダに付与されたプロトコルの識別子を元に、パケットのプロトコル種別を判別する。プロトコル振分部３８は、パケットのプロトコル種別がＴＣＰ（ＴＣＰと同様のフロー制御及び輻輳制御を行うプロトコルを含む）である場合に、パケットを制御対象キュー２８Ａに振り分ける。これに対し、プロトコル振分部３８は、プロトコル種別が非ＴＣＰであれば、パケットを非制御対象キュー２８Ｂに振り分ける。
制御対象キュー２８Ａ（キュー２８Ａ）は、実施形態１におけるキュー２８に相当し、ＴＣＰのパケットを一時的に蓄積する。キュー２８Ａにおけるパケットの滞留時間は、実施形態１で説明した手法で、滞留時間制御部３４によって調整される。非制御対象キュー２８Ｂ（キュー２８Ｂ）は、非ＴＣＰのパケットを一時的に蓄積する。
スケジューラ３９は、滞留時間制御部３４によって算出された挿入遅延Ｄ（遅延量Ｄ（ｔ））に基づく読み出しタイミングが反映されたパケットの読み出しスケジュールに従って、キュー２８ＡからのＴＣＰのパケットとキュー２８Ｂからの非ＴＣＰのパケットの読み出しを行い、読み出したパケットを送信処理部３５に与える。
また、実施形態１で示したように、１つのコネクションについてダウンリンク方向（往路）とアップリンク方向（復路）の一方に遅延を挿入すれば、スループットの調整が可能である。このため、ＴＣＰのパケットフローに関して、復路のパケットに該当するＡＣＫパケットのみがキュー２８Ａに振り分けられ、ＡＣＫパケット以外のパケットは、キュー２８Ｂに振り分けられるようにしても良い。この場合、プロトコル振分部３８は、ＴＣＰのパケットのヘッダを参照し、ＡＣＫパケットである場合にのみ、キュー２８Ａへの振分を行い、ＡＣＫパケット以外のパケットは、キュー２８Ｂに振り分ける。
実施形態２によれば、プロトコル振分部３８が、パケットのプロトコル種別を判別し、付加的な遅延を与える（滞留時間制御の）必要がない非ＴＣＰのパケットについては、ＴＣＰ用のキューであるキュー２８Ａと異なるキュー２８Ｂに格納する。これによって、パケットのプロトコル種別によって、付加的な遅延（挿入遅延Ｄ）を与えるかどうかが選択可能となる。
〔実施形態３〕
次に、本発明の実施形態３について説明する。実施形態３は、実施形態１と同様の構成を有するため、共通の構成についての説明は省略し、主として相違点について説明する。
実施形態３では、ＴＣＰコネクション（パケットフロー）毎に、ＲＴＴの算出を行う。ＴＣＰコネクションは、例えば、ＡＰＬ４１（図５）毎に確立することができる。換言すれば、端末２１ＡとＣＮ２３Ａとの間に、複数のＴＣＰコネクションが並列に確立されることがある。或いは、エンド間が異なる複数のＴＣＰコネクションが通信ノード２０を通過する場合が起こり得る。
ここで、ＲＴＴ値は、実施形態１で説明したように、エンド・トゥ・エンドにおけるパ
ス（パケットフロー）全体の遅延の合計値である。このため、ＲＴＴ値は、コネクション毎に異なる。実施形態３では、コネクション毎にパケットの遅延量（滞留時間）を調整する構成について説明する。
図９は、実施形態３に係るトラフィック制御装置の構成例を示す図である。実施形態１（図５）との相違点は、以下の通りである。すなわち、受信処理部３１から出力されるパケットのフローを判別する、ダウンリンク側のフロー振分部３６Ａと、端末２１Ａから受信されるパケットのフローを判別する、アップリンク側のフロー振分部３６Ｂとが設けられている。
フロー振分部３６Ａ及びフロー振分部３６Ｂは、キュー２７に入力されるパケットのヘッダに格納されたパケットフロー（ＴＣＰコネクション）の識別子（例えば、送信元及び宛先ポート番号，並びに送信元及び宛先ＩＰアドレス）に基づいて、ＴＣＰコネクションを判別する。ＲＴＴ測定部３３は、フロー（コネクション）毎に用意され、コネクション単位毎のＲＴＴを測定する。
フロー振分部３６Ｂの後段には、複数のキューが設けられる。図２８に示す例では、制御対象のフロー（コネクション）毎に設けられたキュー２８ａ及び２８ｂと、非制御対象のフロー用のキュー２８ｃとが図示されている。制御対象のキューの数（２個）は例示であり、コネクションの数に応じたキューが用意される。
滞留時間制御部３４は、フロー毎の挿入遅延Ｄ，勾配Ｋ及び遅延量Ｄ（ｔ）を算出し、対応するキューにおけるパケット（ＡＣＫパケット）の滞留時間を調整する。スケジューラは、各キューからの読み出しが競合しないように、各キューからのパケットの読み出しタイミング（送信時刻）をスケジューリングする。
このように、実施形態３では、ＲＴＴ値がコネクション毎に異なる点に鑑み、コネクション毎に遅延量が算出され、コネクション毎にＡＣＫパケットの滞留時間を調整するためのキュー（キュー２８ａ及び２８ｂ）が用意される。これによって、コネクションのＲＴＴに応じた遅延量をパケットフローに対して付与することができ、より精度の高いトラフィック（スループット）の制御を行うことができる。
〔実施形態４〕
次に、本発明の実施形態４について説明する。実施形態４は、実施形態２及び実施形態３の変形例に相当する。実施形態４は、実施形態２及び実施形態３と同様の構成を有するため、共通の構成についての説明は省略し、主として相違点について説明する。
図１０は、実施形態４に係るトラフィック制御装置２６Ｃの構成例を示す。実施形態４は、トラフィック制御装置２６Ｃの構成を除き、図９に示した実施形態３における構成と同様の構成を有する。このため、トラフィック制御装置２６Ｃ以外の構成に関しては、図９に示した構成要素について適宜言及する。
図１０に示すトラフィック制御装置２６Ｃは、実施形態３におけるトラフィック制御装置２６Ｂ（図９）と以下の点で異なっている。すなわち、トラフィック制御装置２６Ｃは、実施形態２で説明したプロトコル振分部３８を有する。プロトコル振分部３８は、端末２１から送信されるパケットを受け取り、パケットのプロトコル種別を判別する。プロトコル種別がＴＣＰであれば、プロトコル振分部３８は、パケットをフロー振分部３６Ｂに渡す。一方、プロトコル種別が非ＴＣＰであれば、プロトコル振分部３８は、非ＴＣＰのパケット用のキュー（バッファ）２８Ｂに、パケットを格納する。
スケジューラ３９は、キュー２８ａ,２８ｂ,２８ｃ、並びにキュー２８Ｂからの読み出しタイミング（送信時刻）のスケジューリングを行い、各キューからの送信時刻に応じて、パケットを対応するキューから読み出して送信処理部３５に送る。
実施形態４におけるトラフィック制御装置２６Ｃによれば、実施形態２の作用効果と実施形態３の作用効果の双方を得ることができる。
〔実施形態５〕
次に、本発明の実施形態５について説明する。実施形態５は実施形態１〜４との共通点を含むので、主として相違点について説明し、共通点については説明を省略する。
図１１は、実施形態５に係る通信アダプタのハードウェア構成例を示す。図１１において、通信アダプタ１００は、Universal Serial Bus（USB）やイーサネット（登録商標）
のようなＰＣ１１０との通信インタフェース（Ｉ／Ｆ）を有し、ＬＴＥやWiMAXのような
無線機（基地局，ＡＰ）との無線接続機能を有する。通信アダプタ１００は、「通信ノード」の一例である。
通信アダプタ１００は、図１に示したアダプタ１１に適用可能であり、図１１に示すＰＣ１１０は、図１に示した端末１２に適用可能である。また、図１に示した端末９や端末１０は、ＰＣ１１０が通信アダプタ１００を内蔵したハードウェア構成を有する。
このように、端末１１０と通信アダプタ１１０との接続形態として、端末と通信アダプタとがケーブルを介して接続される第１の形態と、通信アダプタが端末に着脱自在な状態でコネクタ接続される第２の形態と、通信アダプタが端末に内蔵される第３の形態とがある。しかし、第１，第２及び第３の形態のいずれが採用されても良い。
通信アダプタ１００は、バスＢを介して接続されたCentral Processing Unit（ＣＰＵ
）１０１，Random Access Memory（ＲＡＭ）１０２，Flash Read Only Memory（フラッシュＲＯＭ）１０３，リンクインタフェース（リンクＩ／Ｆ）１０４，及びリンクインタフェース（リンクＩ／Ｆ）１０５を含んでいる。リンクＩ／Ｆ１０５には、ＰＨＹ／ＲＦ部１０６が接続されており、ＰＨＹ／ＲＦ部１０６には、アンテナ１０７が接続されている。リンクＩ／Ｆは、「通信インタフェース」の一例である。
ＲＡＭ１０２は、ＣＰＵ１０１の作業領域として使用される。フラッシュＲＯＭ１０３は、不揮発性記憶媒体の一例であり、ＣＰＵ１０１によって実行される各種のプログラムや、各プログラムの実行に際して使用されるデータを記憶する。ＲＡＭ１０２，フラッシュＲＯＭ１０３のそれぞれは、「記憶装置」、或いは「コンピュータ読み取り可能な記録媒体」の一例である。
リンクＩ／Ｆ１０４は、端末の一例であるＰＣ１１０と接続される通信インタフェース回路であり、例えばイーサネット（登録商標）をサポートし、パケットに対するレイヤ２以下の処理を行う。リンクＩ／Ｆ１０５は、無線接続用の通信インタフェース回路であり、パケットに係るレイヤ２以下の処理を行う。ＰＨＹ／ＲＦ部１０６は、物理層に係る処理と無線信号に係る処理とを司る回路である。リンクＩ／Ｆ１０５，ＰＨＹ／ＲＦ部１０６及びアンテナ１０７を用いて、アクセスネットワーク５（基地局）と無線通信を行うことができる。リンクＩ／Ｆ１０４及びリンクＩ／Ｆ１０５のそれぞれは、「通信インタフェース」の一例である。
ＰＣ１１０は、例えば、汎用のパーソナルコンピュータであり、１以上のアプリケーション（ＡＰＬ）を搭載している。ＰＣ１１０は、ＴＣＰ／ＩＰをサポートしており、通信
相手（ＣＮ）とＴＣＰコネクションを確立してＴＣＰ通信を行うことができる。
ＰＣ１１０は、ディスク記憶媒体（ＣＤ-ＲＯＭ，ＤＶＤ-ＲＯＭなど）、或いはフラッシュメモリのような、可搬性を有する記憶媒体１１１のドライブ装置又は読み取り装置（図示せず）を有している。ＰＣ１１０は、記憶媒体１１０に記憶されたトラフィック制御用のプログラムを、通信アダプタ１００のフラッシュＲＯＭ１０３にインストールすることができる。
ＣＰＵ１０１は、フラッシュＲＯＭ１０３にインストールされたトラフィック制御用のプログラムをＲＡＭ１０２にロードして実行する。これによって、通信アダプタ１００がトラフィック制御装置を含む通信ノードとして機能するための処理を行う。
ＰＣ１１０は、通信アダプタ１００を介してＬＴＥの基地局，或いはWiMAXの基地局（
ＡＰ）と無線接続を行い、基地局が接続されたネットワークを介して通信相手（ＣＮ）と接続される。そして、ＰＣ１１０は、ＣＮと通信を行うことができる。
図１２は、ＣＰＵ１０１がトラフィック制御用のプログラムを実行することによって生じる機能を模式的に示す。図１２において、ローカルリンクは、ＰＣ１１０と接続されるインタフェース（「リンクレイヤ１」或いは「第１リンクＬ１」と称する）であり、リンクＩ／Ｆ１０４によって生成される。リンクＩ／Ｆ１０４は、リンクレイヤ１の送信部２０１と、リンクレイヤ１の受信部２０２として機能する。
一方、“ネットワーク”側のリンク（「リンクレイヤ２」或いは「第２リンクＬ２」と称する）は、基地局（ＮＷ）と接続される無線リンクであり、時間経過に伴い帯域（通信速度）が変動する。リンクレイヤ２（第２リンクＬ２）が監視対象のリンクである。リンクＩ／Ｆ１０５及びＰＨＹ／ＲＦ部１０６は、リンクレイヤ２の受信部２０３及びリンクレイヤ２の送信部２０４として機能する。受信部２０３は、受信処理部３１（図９）に相当し、送信部２０４は、送信処理部３５（図９）に相当する。
受信部２０３と送信部２０１とのダウンリンク方向（ＮＷ→ＰＣ）のパケット転送路上には、コネクション識別処理部２３８Ａと、キュー１２８ａ，１２８ｂ，１２８ｃと、スケジューラ３９とが配置される。
コネクション識別処理部２３８Ａ（識別処理部２３８Ａ）は、フロー振分部３６Ａ及びプロトコル振分部３８（図１０）と同等の機能を有する。識別処理部２３８Ａは、受信部２０３で受信されたパケットのプロトコル種別及びパケットフロー（ＴＣＰコネクション）を識別し、パケットをキュー１２８ａ，１２８ｂ，１２８ｃのいずれかに格納する（振り分けを行う）。
キュー１２８ａ，１２８ｂ，１２８ｃは、識別処理部２３８Ａの後段に配置されている。キュー１２８ａ及び１２８ｂのそれぞれは、制御対象（滞留時間調整を行う）のパケットが格納されるキュー（バッファ）であり、キュー２８ａ，２８ｂ（図９）に相当する。キュー１２８ｃは、非制御対象（滞留時間調整を行わない）のパケットが格納されるキューであり、キュー２８ｃ（図９）に相当する。
制御対象のパケットが格納されるキューは、ＴＣＰコネクション毎に生成される。キュー１２８ａ及び１２８ｂは例示である。キュー１２８ｃは、非制御対象のプロトコル種別のパケットや、非制御対象のＴＣＰコネクションのパケットを必要に応じて一時的に蓄積する。
キュー１２８ａ，１２８ｂ，１２８ｃ、並びに後述するキュー２２８ａ，２２８ｂ，２２８ｃは、例えばＲＡＭ１０２の記憶領域を用いて形成される。但し、リンクＩ／Ｆ１０４又はリンクＩ／Ｆ１０５がメモリを有する場合には、当該メモリを用いて生成することもできる。
スケジューラ３９Ａは、キュー１２８ａ，１２８ｂ，１２８ｃの後段に配置されている。スケジューラ３９Ａは、キュー１２８ａ，１２８ｂ，１２８ｃからのパケットの読み出しタイミングを制御し、読み出されたパケットを送信部２０１へ送る。スケジューラ３９Ａは、スケジューラ３９（図１０）に相当する。
受信部２０２と送信部２０４とのアップリンク方向（ＰＣ→ＮＷ）のパケット転送路上には、コネクション識別処理部２３８Ｂ（識別処理部２３８Ｂ）と、キュー２２８ａ，２２８ｂ，２２８ｃと、スケジューラ３９Ｂとが配置される。
識別処理部２３８Ｂは、識別処理部２３８Ａと同等のプロトコル種別及びＴＣＰコネクションの判別機能と、判別結果に応じたパケットの振分機能とを有する。
キュー２２８ａ，２２８ｂ，２２８ｃは、識別処理部２３８Ｂの後段に配置されている。キュー２２８ａ及び２２８ｂは、制御対象の１以上のキューの例示であり、制御対象のＴＣＰコネクション毎に生成される。キュー２２８ｃは、非制御対象のパケットの蓄積に使用される。
スケジューラ３９Ｂは、キュー２２８ａ，２２８ｂ，２２８ｃの後段に配置されている。スケジューラ３９Ｂは、キュー２２８ａ，２２８ｂ，２２８ｃからのパケットの読み出しタイミングを制御し、読み出されたパケットを送信部２０４へ送る。スケジューラ３９Ｂは、スケジューラ３９（図１０）に相当する。
識別処理部２３８Ａと識別処理部２３８Ｂのそれぞれはコネクション管理部２０６に接続されている。コネクション管理部２０６は、コネクション管理テーブル２０７を管理している。
図１３は、コネクション管理テーブル２０７（テーブル２０７）のデータ構造例を示す。図１３において、テーブル２０７は、ソース（送信元）ＩＰアドレス，ソースポート番号，宛先ＩＰアドレス，宛先ポート番号，状態，開始時刻，エージングタイマ，転送方向，及び計測ＲＴＴ値が格納される１以上のエントリが格納される。エントリは、ＴＣＰコネクション毎に生成される。
図１２に戻って、コネクション管理部２０６は、ＲＴＴ測定部２０８に接続されている。ＲＴＴ測定部２０８は、ＴＣＰコネクション毎のＲＴＴを測定する。ＲＴＴ測定部２０８は、遅延量決定部２０９に接続されている。遅延量決定部２０９は、滞留時間制御部３４（図９）に相当する。
遅延量決定部２０９は、制御対象のＴＣＰコネクションに関して、受信部２０３から入力されるリンクレイヤ２（第２リンク）のダウンリンク方向の回線速度情報（現在の帯域ＢＷnowを示す）と、ＲＴＴ測定部３３から通知される当該ＴＣＰコネクションのＲＴＴ
とを用いて、実施形態１で説明した手法を用いて挿入遅延Ｄ，勾配Ｋ及び遅延量Ｄ（ｔ）を求め、スケジューラ３９Ｂに通知する。スケジューラ３９Ｂは、遅延量Ｄ（ｔ）を用いて、対応するパケットのキュー（キュー２２８ａ又は２２８ｂ）からの読み出しタイミングを決定する。
また、遅延量決定部２０９は、制御対象のＴＣＰコネクションに関して、送信部２０４から入力されるリンクレイヤ２のアップリンク方向の回線速度情報（現在の帯域ＢＷnow
を示す）と、ＲＴＴ測定部３３から通知される当該ＴＣＰコネクションのＲＴＴとを用いて、実施形態１で説明した手法を用いて挿入遅延Ｄ，勾配Ｋ及び遅延量Ｄ（ｔ）を求め、スケジューラ３９Ａに通知する。スケジューラ３９Ｂは、遅延量Ｄ（ｔ）を用いて、対応するパケットのキュー（キュー１２８ａ又は１２８ｂ）からの読み出しタイミングを決定する。
上記した識別処理部２３８Ａ及び２３８Ｂ，スケジューラ３９Ａ及び３９Ｂ，コネクション管理部２０６，ＲＴＴ測定部３３，遅延量決定部２０９は、ＣＰＵ１０１がトラフィック制御用のプログラムを実行することによって実現する機能である。テーブル２０７は、例えばＲＡＭ１０２、又はフラッシュＲＯＭ１０３に記憶される。
なお、識別処理部２３８Ａ及び２３８Ｂ，スケジューラ３９Ａ及び３９Ｂ，コネクション管理部２０６，ＲＴＴ測定部３３，遅延量決定部２０９としての機能は、上記したＣＰＵ１０１や、Digital Signal Processor（ＤＳＰ）のようなプロセッサの機能として実装可能である。プロセッサは、「制御装置」の一例である。制御装置は、Field Programmable Gate Array（ＦＰＧＡ）のようなプログラマブルロジックデバイス（ＰＬＤ）を含む
。
また、識別処理部２３８Ａ及び２３８Ｂ，スケジューラ３９Ａ及び３９Ｂ，コネクション管理部２０６，ＲＴＴ測定部３３，遅延量決定部２０９としての機能は、Large Scale Integrated circuit（ＬＳＩ）やApplication Specific Integrated Circuit（ＡＳＩＣ
）のような集積回路（ＩＣ）を用いたハードウェアロジック（ワイヤードロジック）によって実装されても良い。すなわち、上記した各機能は、プロセッサ，ＰＬＤ，ＩＣの少なくとも１つ、或いは２以上の組み合わせによって形成される「制御装置」によって実装可能である。
上記した実装方法は、実施形態１〜４において説明したリンク帯域検出部３２，ＲＴＴ測定部３３，滞留時間制御部３４，フロー振分部３６Ａ及び３６Ｂ，プロトコル振分部３８，スケジューラ３９についても当てはまる。
＜ＣＰＵによる処理＞
図１４は、制御対象のパケットをキューに格納するまでの処理例を示すフローチャートである。図１４に示す処理は、ダウンリンク転送の場合とアップリンク転送の場合とで共通な処理である。以下の説明では、例として、ダウンリンク転送の場合について説明する。
図１４に示す処理は、例えば、リンクＩ／Ｆ１０４（受信部２０２）で受信されたパケットをＣＰＵ１０１がバスＢを介して受信した場合に開始される。 最初の０１では、ＣＰＵ１０１は、識別処理部２３８Ｂとして機能し、パケットのプロトコル種別が制御対象プロトコル（ＴＣＰ）か否かを判定する。例えば、ＣＰＵ１０１は、パケットのＩＰヘッダに含まれるプロトコル番号がＴＣＰを示す番号が否かで、ＴＣＰかＴＣＰ以外のプロトコルかを判定することができる。プロトコル種別がＴＣＰでなければ（０１，ＮＯ）、処理が０７に進む。これに対し、プロトコル種別がＴＣＰであれば（０１，ＹＥＳ）、処理が０２に進む。
０２では、ＣＰＵ１０１は、コネクション管理部２０６として機能し、ＴＣＰパケットがＴＣＰコネクションの確立開始を示すＳＹＮパケットか否かを判定する。すなわち、ＣＰＵ１０１は、パケットのＴＣＰヘッダを参照し、ＳＹＮフラグがセットされているか否
かを判定する。
図１５は、ＲＦＣ７８３で規定されるＴＣＰヘッダのフォーマットを示し、図１６Ａ及び図１６Ｂは、ＲＦＣ１３２３で規定されるＴＣＰヘッダのオプションフィールドにセット可能なタイムスタンプオプションのフォーマットを示す。ＴＣＰでは、コネクションを確立するために３ウェイハンドシェイクと呼ばれる３手順を行う。
第１の手順では、通信の要求者が通信相手に対してＳＹＮパケット、すなわち、ＳＹＮフラグがＴＣＰヘッダにセットされたパケットを送る。第２の手順では、ＳＹＮパケットを受信した通信相手が、要求者の接続を許可するＳＹＮ-ＡＣＫパケット（ＳＹＮ＋ＡＣ
Ｋ）を送信する。ＳＹＮ-ＡＣＫパケットは、ＳＹＮフラグとＡＣＫフラグ（図１５参照
）がセットされたＴＣＰヘッダを有するパケットである。第３にＳＹＮ-ＡＣＫパケット
を受け取った要求者は、接続開始を表すＡＣＫパケット（ＳＹＮフラグがオフでＡＣＫフラグがセットされたＴＣＰパケット）を要求者に送信し、通信相手との通信を開始する。
なお、ＳＹＮパケットには、無作為の値Ａがシーケンス番号として設定される。ＳＹＮ-ＡＣＫパケットでは、（Ａ＋１）の値が確認応答番号としてセットされるとともに、無
作為の値Ｂがシーケンス番号としてセットされる。さらに、ＡＣＫパケットでは、（Ｂ＋１）の値が確認応答番号としてセットされる。
ＣＰＵ１０１は、パケットがＳＹＮパケットであれば（０２，ＹＥＳ）、処理を０４に進める。一方、ＣＰＵ１０１は、パケットがＳＹＮパケットでなければ（０２，ＮＯ）、処理を０３に進める。
０３では、ＣＰＵ１０１は、コネクション管理部２０６として機能し、テーブル２０７（図１３）に、新たなＴＣＰコネクションに係るエントリを登録する。エントリには、コネクションの識別子として使用されるソースＩＰアドレス，ソースポート番号，宛先ＩＰアドレス，及び宛先ポート番号が設定される。さらに、状態“ＳＹＮ”（確立手順中を示す）が格納される。
なお、状態“ＥＳＴＢ”はコネクション確立済みを示し、状態“ＩＤＬＥ”はアイドル状態を示す。状態“ＦＩＮ”はコネクション終了を要求するＦＩＮフラグがセットされたパケット（ＦＩＮパケット）の送信状態を示し、状態“ＦＩＮ-Ｗ”は、ＦＩＮパケット
の応答パケットを待っている状態を示す。
開始時刻として、図１６Ａ又は図１６Ｂに示すタイムスタンプのオプションフィールドにおけるタイムスタンプ値（TS Value）が格納される。また、エージングタイマは、コネクションの異常終了に備えて、強制的なコネクションの終了手順を開始するまでの猶予期間を示す。転送方向は、監視対象リンクからの送信又は受信を示す。動作例では、リンクレイヤ２の受信側が監視対象であるので、アップリンク方向が“送信”に、ダウンリンク方向が“受信”に当たる。計測ＲＴＴ値として、ＲＴＴ測定部３３により測定されたＲＴＴ値が格納される。０３の終了後、処理が０５に進む。
０４では、ＣＰＵ１０１は、コネクション管理部２０６として機能し、テーブル２０７から、受信されたＴＣＰパケットに対応するエントリを検索する、ＣＰＵ１０１は、ＴＣＰパケットのＴＣＰヘッダに含まれた情報で、エントリを更新する。その後、処理が０５に進む。
０５では、ＣＰＵ１０１は、ＲＴＴ測定部３３として機能し、０３で登録、０４で更新されたエントリで特定されるＴＣＰコネクションについてのＲＴＴを測定する。測定方法
は、実施形態１で説明した手法１又は手法２を用いる。例えば、ＣＰＵ１０１は、オプションヘッダのタイムスタンプ値（図１６Ａ又は図１６Ｂ）を用いる手法２で、ＲＴＴを計測する。ＲＴＴの計測が終了すると、ＣＰＵ１０１は、新たなＲＴＴ値で、テーブル２０７の該当エントリにおけるＲＴＴ値を更新する。
０６以降の処理は、ＲＴＴ値が更新されてから実行される。０６では、ＣＰＵ１０１は、識別処理部２３８Ｂとして機能し、パケットがＡＣＫパケットか否かを判定する。パケットがＡＣＫパケットであれば（０６，ＹＥＳ）、処理が０８に進む、パケットがＡＣＫパケットでなければ、処理が０７に進む。
０７では、ＣＰＵ１０１は、識別処理部２３８Ｂとして機能し、非制御対象のキュー（例えば、キュー２２８ｃ）にパケットを格納する。
０８では、ＣＰＵ１０１は、遅延量の算出処理を行う。すなわち、ＣＰＵ１０１は、コネクション管理部２０６として、テーブル２０７を参照し、ＡＣＫパケットに対応するコネクションのエントリに格納されたＲＴＴ値を読み出す。続いて、ＣＰＵ１０１は、遅延量決定部２０９として機能し、送信部２０４から回線速度情報（現在の帯域を示す情報）を得て、ＲＴＴ値と回線速度情報とを用いて挿入遅延Ｄ，勾配Ｋ，遅延量Ｄ（ｔ）を算出する。挿入遅延Ｄ等の算出方法は、実施形態１で説明した式（１）〜（６）を用いて行う。
０９では、ＣＰＵ１０１は、遅延量決定部２０９として機能し、勾配Ｋ及び遅延量Ｄ（ｔ）を求めて、ＡＣＫパケットの送信予定時刻ｔout（ｔout＝ｔnow＋D(t)）を算出する
。送信予定時刻は、ＡＣＫパケットを格納するキューの識別情報とともに、スケジューラ３９Ｂに通知される（ＲＡＭ１０２の所定アドレスに記憶される）。
１０では、ＣＰＵ１０１は、識別処理部２３８Ｂとして機能し、ＡＣＫパケットを、コネクション毎に用意された制御対象のキュー（例えばキュー２２８ａ）に格納する。ここまでが、制御対象のパケットが、滞留時間調整可能なキューに格納されるまでの処理である。
図１７は、制御対象のキューに格納されたパケットの読み出し処理の例を示すフローチャートである。図１７に示す処理は、ダウンリンク転送の場合とアップリンク転送の場合とで共通な処理である。以下の説明はダウンリンク転送の場合を例として説明する。すなわち、図１７に示す処理が、スケジューラ３９Ｂとして機能するＣＰＵ１０１によって実行される場合について説明する。
最初の１０１では、ＣＰＵ１０１は、非制御対象のキュー（キュー２２８ｃ）にパケットが格納（蓄積）されているか否かを判定する。パケットが蓄積されている場合（１０１，ＹＥＳ）には、処理が１０６に進む。パケットが蓄積されていない場合（１０１，ＮＯ）には、処理が１０２に進む。
１０２では、ＣＰＵ１０１は、制御対象キュー（キュー２２８ａ及び２２８ｂ）のうち、先頭パケットの送信予定時刻（送信時刻）が最も早い（最先の）キューを検索する。
１０３では、ＣＰＵ１０１は、該当のキューが検索されたか否かを判定する。このとき、全ての制御対象キューが空である場合（１０３，ＮＯ）には、処理が１０１に戻る。これに対し、該当のキューがある場合（１０３，ＹＥＳ）には、処理が１０４へ進む。
１０４では、ＣＰＵ１０１は、現時刻が送信時刻に達したか否かを判定する。現時刻が
送信時刻に達していない場合（１０４，ＮＯ）には、処理が１０１に戻る。これに対し、現時刻が送信時刻に達した場合（１０４，ＹＥＳ）には、処理が１０５に進む。
１０５では、ＣＰＵ１０１は、該当のキューにおける先頭パケットを読み出し、当該パケットの送信処理を行う。１０６では、ＣＰＵ１０１は、非制御対象のキューの先頭パケットを送信する。パケットは、送信部２０４（リンクＩ／Ｆ１０５）からネットワークへ送信され、ＣＮへ送られる。なお、１０５又は１０６が終了すると、処理が１０１に戻り、１０１以降の処理が繰り返し実行される。
なお、図１４及び図１７の処理がアップリンク転送に適用される場合には、ＣＰＵ１０１が、識別処理部２３８Ａ，スケジューラ３９Ａとして機能する一方、キュー１２８ａ，１２８ｂ，１２８ｃが使用される。ＣＰＵ１０１による、コネクション管理部２０６，ＲＴＴ測定部３３，遅延量決定部２０９としての処理は、ダウンリンク転送の場合における処理と同じである。
＜動作例＞
次に、通信アダプタ１００の動作例として、ＰＣ１１０が或る通信相手（ＣＮ）と或るＴＣＰコネクションを確立し、ＰＣ１１０とＣＮとの間でＴＣＰ通信（ＴＣＰ／ＩＰ通信）が実行される場合の動作例について説明する。
ＰＣ１００からネットワーク（ＣＮ）へＴＣＰコネクションに係るデータパケットが送信される（アップリンク転送が行われる）とき、データパケットは、リンクレイヤ１の受信部２０２（リンクＩ／Ｆ１０４）で受信される。そして、データパケットは、リンクレイヤ２の送信部２０４（リンクＩ／Ｆ１０５，ＰＨＹ／ＲＦ部１０６）から第２リンクへ送信される。
データパケットは、基地局及びネットワークを介して通信相手（ＣＮ）へ到達する。一方、ＣＮから送信される、データパケットに対するＡＣＫパケットは、リンクレイヤ２（第２リンク）の受信部２０３に到着し、リンクレイヤ１（第１リンク）の送信部２０１から送出されてＰＣ１１０に届く。
受信部２０１で受信されたデータパケットは、識別処理部２３８Ｂにおけるプロトコル種別及びＴＣＰコネクションの識別処理を経て、識別結果に応じたキューに格納される（振り分けられる）。例えば、識別処理部２３８Ｂには、ＴＣＰコネクションのＡＣＫパケットを制御対象のキューに格納し、当該ＡＣＫパケット以外のパケットは、非制御対象のキューに格納する設定が施されている。
このため、データパケットは、非制御対象のキューであるキュー２２８ｃに格納される。スケジューラ３９Ｂは、他のキューからのパケット読み出しとの調整を行った上で、キュー２２８ａからデータパケットを読み出し、送信部２０４に送る。
データパケットを受信したＣＮは、データパケットに対応するＡＣＫパケットを返送する。ＡＣＫパケットは、ネットワーク，基地局，及びリンクレイヤ２を通過して通信アダプタ１００の受信部２０３（リンクＩ／Ｆ１０５）に届く。
すると、識別処理部２３８ＡがＡＣＫパケットの属するＴＣＰコネクションを識別し、遅延量決定部２０９が、識別されたＴＣＰコネクションに対応付けられた遅延時間調整キュー（制御対象のキュー：例えばキュー１２８ａ）に付与する遅延量（遅延時間）を算出する。その後、ＡＣＫパケットがキュー１２８ａにエンキューされる。
その後、遅延時間が経過した時点以降において、スケジューラ３９Ａにより、他のキューとの送出の調整が図られた上で、ＡＣＫパケットがキュー１２８ａから読み出され、送信部２０１からローカルリンク側（ＰＣ１１０）に送出される。
付与される遅延時間は、リンクレイヤ２の送出インタフェース（すなわち、アップリンク）の帯域（通信速度）と、当該ＴＣＰコネクションのＲＴＴとを用いて決定される。ＲＴＴの測定（計測）は、上述したように、ＴＣＰコネクションに係るデータパケットの識別処理部の通過時刻，及びデータパケットに対応するＡＣＫパケットの識別処理部の通過時刻を用いて測定され、テーブル２０７に記憶されるＲＴＴ値は、随時更新される。
また、ＴＣＰコネクションに係るデータパケットがＣＮからＰＣ１１０へ送信される（ダウンリンク転送が行われる）とき、データパケットは、受信部２０３で受信され、送信部２０１から送出される。データパケットを受信したＰＣ１１０は、データパケットに対応するＡＣＫパケットを送信する。ＡＣＫパケットは、第１リンクを介して受信部２０２で受信され、送信部２０４から第２リンクへ送信され、最終的にＣＮに届く。
受信部２０３でデータパケットが受信されたとき、識別処理部２３８Ａは、データパケットを非制御対象のキューであるキュー１２８ｃに振り分ける。スケジューラ３９Ａは、他のキューとの読み出しタイミングの調整を行った後、データパケットをキュー１２８ｃから読み出す。読み出されたデータパケットは、送信部２０１から第１リンクを介してＰＣ１１０へ送信される。
ＰＣ１１０がデータパケットに対するＡＣＫパケットを送信すると、ＡＣＫパケットは、受信部２０２で受信される。このとき、識別処理部２３８Ｂ及びコネクション管理部２０６により、ＡＣＫパケットのＴＣＰコネクションが特定され、当該ＴＣＰコネクションのＲＴＴ値及び受信部２０３から得られるリンクレイヤ２の受信インタフェース（ダウンリンク）の帯域（回線速度情報）からＡＣＫパケットに与える遅延量（挿入遅延：遅延時間）が算出される。そして、ＡＣＫパケットは、対応する制御対象のキュー（例えば、キュー２２８ａ）に格納される。
その後、遅延時間が経過した時点以降で、スケジューラ３９ＢがＡＣＫパケットをキュー２２８ａから読み出す。ＡＣＫパケットは、送信部２０４からリンクレイヤ２へ送出される。遅延時間は、リンクレイヤ２（第２リンク）の受信インタフェース(=ダウンリンク)の帯域(通信速度)とＴＣＰコネクションのＲＴＴとを用いて決定する。ＲＴＴの測定は
、ＴＣＰコネクションに係るパケットフローのパケット（データパケット，ＡＣＫパケット）の通過時刻を用いて、随時行われ、テーブル２０７のＲＴＴ値は随時更新される。
コネクション識別を適切に行うために、パケットが通過するＴＣＰコネクションの発生と終了を監視し、アクティブなコネクションと当該コネクションを識別するための情報が、テーブル２０７に記憶される。
ＴＣＰの場合、上記したように、コネクションの確立（発生）はＳＹＮパケットが送信されることから始まる３ウェイハンドシェイクの流れを監視することによって行われる。一方、コネクションの終了は、ＦＩＮフラグがセットされたＴＣＰパケット（ＦＩＮパケット）の送信から始まる切断シーケンスを監視することによって行われる。
ＴＣＰコネクションは、図１３に示したようなテーブル２０７にて管理される。テーブル２０７を用いてＴＣＰコネクションの特定や、ＲＴＴ値の管理が行われる。また、コネクションの異常終了への対応を考慮し、テーブル２０７の各エントリは、エージングタイマを備える。このような、ＴＣＰの状態遷移及び状態遷移に基づくコネクションの判別技
術は、ステートインスペクション技術として知られている。ステートインスペクション技術自体は公知であるので説明を省略する。
以上のように、通信アダプタ１００は、或るＴＣＰコネクションに関して、ダウンリンク方向及びアップリンク方向のそれぞれのＡＣＫパケットに、第２リンクの帯域に応じた遅延を付与（追加）する。これによって、ダウンリンク方向及びアップリンク方向の双方において、データパケットの送信レート（スループット）を帯域の変動に応じて効率的に制御することが可能となる。
実施形態５は、上述した実施形態１〜４における作用効果を得ることができる。すなわち、実施形態５では、ＴＣＰコネクションのパケットフローの一方にリンク帯域に応じた挿入遅延を与えることで、パケットのフローの他方のスループットを、リンク帯域に応じた値に制御することができる。
また、実施形態５では、制御対象のプロトコル（ＴＣＰ）以外のパケットが常に遅延非挿入キュー（キュー１２８ｃ、或いはキュー２２８ｃ）に格納されるように制御することができる。
また、実施形態５では、実施形態１〜４と同様に、ＲＴＴの計測結果と、第１リンクの帯域（通信速度）に応じて挿入遅延量を決定する。なお、実施形態５において、プロトコル種別やコネクションの識別を行うことは必須ではない。例えば、該制御対象のリンク区間のレイテンシが、当該リンクを流れるコネクションのＲＴＴの支配要素であるような場合は、１つのコネクションのＲＴＴを代表値として使ったり、典型値を固定値として運用したりすることが可能である。
この場合、制御対象プロトコル（例えばＴＣＰ）について共通の付加遅延時間（挿入遅延Ｄ）を与えればよいため、キューは、制御対象プロトコル用のキューは、複数のコネクション間でひとまとめにすることができる。また、実施形態５の構成に代えて、アップリンク方向とダウンリンク方向との一方のみに挿入遅延を付加する構成を採用することができる。
また、実施形態５では、遅延量Ｄ（ｔ）を連続的に変化させて最終的に挿入遅延Ｄに至るように制御することが可能である。これによって、不要なパケット間隔の発生やパケットの追い越しを回避することができる。
また、実施形態５では、コネクション毎にＲＴＴが測定され、コネクション毎に異なる挿入遅延が算出される。これによって、コネクションのＲＴＴに応じたスループット（トラフィック）制御を行うことが可能となる。
また、実施形態５では、挿入遅延Ｄの算出に当たり、上記した式（２）を用いる。これによって、遅延が挿入されるコネクションからの観点では、帯域遅延積（ＢＤＰ）の変化が打ち消されるので、ウィンドウサイズを好適な値に維持することができる。
また、実施形態５では、上記した式（５）及び式（６）を用いて算出される勾配Ｋ及び遅延量Ｄ（ｔ）が適用される。これによって、遅延量を連続的に変化させることができる。
また、実施形態５は、ＡＣＫパケットに対して遅延が付与される構成を採用する。遅延量を与えるパケット列が密に詰まっていると、印加遅延量を短くする方向に制御することができない。実施形態で説明した遅延量制御は、帯域が変動する監視対象リンクの帯域に
応じて行われる。このため、監視対象リンクがボトルネックリンクとなっている場合に効果が得られる。
しかしながら、監視対象リンクがボトルネックになっている場合、データパケットは隙間なく流れている状態になっているのが通例である。この場合、遅延量を減らす方向の制御を加えることができない場合が起こり得る。一方、ＡＣＫパケットの送信レートは、ＡＣＫパケットの発生要因となるデータパケットの送信レートに準じたものになるけれども、通常、ＡＣＫパケットはデータ部を持たないため、ＡＣＫパケット間は空いた状態となる。また、ＡＣＫパケットは、複数のデータパケットに関してまとめたものを送信可能であるため、ＡＣＫパケットの送信間隔はデータパケットの間隔に比べて大きくなる傾向にある。
従って、上記したような帯域に応じた遅延量の挿入がデータパケットに対する挿入に比べて容易である。また、遅延の付与のために、パケットを一時的に蓄えるキュー（バッファ）が用意される。ＡＣＫパケットのサイズは、データパケットのサイズより小さいので、キューのサイズ（容量）を小さくすることができる。見かけ上の（ＴＣＰで認識される）ＲＴＴを増加する目的で挿入される遅延は、パケットフローの往路と復路とは関係なく、パケットフローのどこに挿入しても同様の効果を得ることができる。従って、ＡＣＫパケットが流れる側のトラフィックに対し遅延を印加するのが好ましい。
また、実施形態５における通信アダプタでは、以下のような制御を行うことができる。すなわち、新規に確立されたＴＣＰコネクションが検出された時点では、付加すべき遅延量を最小値に設定する。例えば、最小値は、０であり、０のとき、遅延は付加されない。但し、０より大きい最小値を予め定めることもできる。その後、遅延量が時間経過に応じて徐々に増加し、最終的に挿入遅延Ｄの値となるようにする。遅延量は、経過時間に比例して増加するように制御されても良く、指数的に収束させるような増加方法も考えられる。
また、本来の付加遅延量(あるいはその近傍値、例えば挿入遅延Ｄの値)に達するまでに要する時間は、当該コネクションがスロースタートに要する時間見合いで適宜決定することができる。或いは、例えば１秒のような固定値を使用することもできる。これによって、遅延の付与によって、スロースタート開始時のスループット増加のペースが低下する弊害を抑えることができる。
具体的に説明すると、第２リンクを利用する新たなＴＣＰコネクションの確立（発生）に伴う通信の開始時点において、第２リンクのリンク帯域（ＢＷnow）がリンクの最大帯
域（ＢＷmax）より下がっていると仮定する。このとき、コネクション上に見える（エン
ド間に現れる）ＲＴＴとして、リンク帯域の低下に応じた長さのＲＴＴで通信が開始されるべきである。
しかしながら、ＴＣＰは、通信開始時には、最低又は小さいウィンドウサイズを用い、パケットのオーバーフローが生じるまで、徐々にウィンドウサイズを増加する制御（スロースタート制御）を行う。ウィンドウサイズの上昇（増加）速度は、ＲＴＴが大きい程遅くなる傾向にある。
このため、通信開始時における挿入遅延Ｄが大きいと、当該コネクションにおけるウィンドウサイズが現在のリンク帯域に応じたサイズに至るまでに時間を要する。また、当該コネクションを流れるデータ量が少ない場合には、スロースタート中に通信が終了する可能性がある。このように、コネクション確立に伴う通信開始時点で挿入遅延Ｄが挿入されることで、リンク帯域を有効利用可能なスループットになるまでに時間がかかる、或いは
、良好なスループットに至る前に通信が終了する虞があった。
このため、図１８に示すような遅延量の付与に係る制御を行うことが可能である。すなわち、コネクション開始時点（通信アダプタ１００で新たなコネクションが検出された時点）における挿入遅延の量は最小値（例えば０）とし、そこから適宜の時間内で式（２）を用いて算出される挿入遅延Ｄの値に収斂するように、遅延量を徐々に増加させることで、上記した弊害を緩和又は抑止することができる。
また、実施形態５では、遅延挿入によるトラフィック制御が、通信アダプタ１００におけるプロセッサ（ＣＰＵ１０１）によるソフトウェア（プログラム）の実行によって行われる形態について説明した。上記した例では、ＰＣ１１０によって、通信アダプタ１００にプログラムがインストールされる例について説明したが、トラフィック制御用のプログラムは、ファームウェアとして、予めフラッシュＲＯＭ１０３に記憶される構成を採用しても良い。或いは、通信アダプタ１００が、ＰＣ１１０又は記録媒体１１１に記憶されているトラフィック制御用のプログラムを必要に応じてＲＡＭ１０２にダウンロードする構成を適用することも可能である。
なお、通信ノードの他の例のハードウェア構成について説明する。図１９は、モバイルルータ１００Ａのハードウェア構成の一例を示す。例えば、モバイルルータ１００Ａは、図１に示したＣＰＥ１３として適用可能である。モバイルルータ１００Ａは、無線インタフェースとして、アンテナ１０７とＲＦ部１０６Ａを有している。モバイルルータ１００Ａは、無線インタフェースを用いて端末と無線接続することができる。
さらに、モバイルルータ１００Ａは、ＬＡＮ側のインタフェースを提供するレイヤ２スイッチ及びＰＨＹチップ１０５Ａ（チップ１０５Ａ）を有している。チップ１０５Ａは、複数のＬＡＮ回線を収容するためのポートを有し、ポートの一つがＲＦ部１０６Ａと接続されている。リンクＩ／Ｆ１０４Ａは、ＷＡＮ側のインタフェースを提供し、ネットワーク（ＮＷ）と接続されている。
チップ１０５Ａは、キューとして使用可能なメモリを有するとともに、スケジューラとして機能するハードウェア（電子回路，集積回路）を備えている。実施形態１〜５で説明したトラフィック制御は、主にレイヤ２（Ｌ２）での処理であるため、チップ１０５Ａが備えるレイヤ２スイッチ（Ｌ２ＳＷ）に、キュー及びスケジューラとしての機能を実装することができる。
プロトコル種別の識別，コネクションの識別，ＲＴＴ測定は、レイヤ３以上に対する処理であるため、例えば、ＣＰＵ１０１のプログラム実行に基づく処理として実装する。また、キューイング制御や、スケジューラの制御もＣＰＵ１０１が行う。ＣＰＵ１０１によって実行されるプログラムは、フラッシュＲＯＭ１０３に記憶される。これらのＣＰＵ１０１が行う処理は、専用のハードウェア（集積回路）で実装することも可能である。
図２０は、通信ノードの一例として、基地局１００Ｂのハードウェア構成例を示す。基地局１００Ｂは、例えば、図１に示した基地局（ＢＳ）６，基地局７，フェムト基地局８のそれぞれに適用可能である。
基地局１００Ｂは、チップ１０５Ａの代わりに、ベースバンド信号に係る処理を司るＢＢ処理部１０５Ｂを備える点で、モバイルルータ１００Ａと異なる。端末がネットワーク（ＮＷ）と接続するとき、端末とネットワークとの間に、ベアラと呼ばれる論理回線が確立される。ベアラは、ＲＦ部１０６Ａ，ＢＢ処理部１０５Ａ，リンクＩ／Ｆ（回線インタフェース）１０４を通過するＵプレーンのベアラを含み、ＴＣＰコネクションは、当該ベ
アラ内に設けられた状態となる。
基地局１００ＢのＣＰＵ１０１は、フラッシュＲＯＭ１０３に記憶されたプログラムのＲＡＭ１０２にロードして実行することにより、リンクＩ／Ｆで送受信されるＴＣＰパケットの覗き見を行い、実施形態１〜５で説明したようなリンク帯域に応じた遅延挿入によるトラフィック制御を実行することができる。なお、モバイルルータ１００Ａ，基地局１００Ｂでの監視対象リンクは、例えば、モバイルルータ１００Ａ及び基地局１００Ｂのそれぞれにおけるダウンリンク側の無線リンクである。
以上説明したように、実施形態１〜５で説明したトラフィック制御が実行されることによって、ＴＣＰコネクションのスループットを、ＴＣＰに基づくスループット調整と異なる方法で調整することができる。
すなわち、監視対象のリンク帯域が低下した場合には、挿入遅延量が増加する。これによって、ＴＣＰの下でのスループット調整で生じる、リンク帯域の低下により発生するキューのオーバーフローによるパケットロスを回避することができる。
また、監視対象のリンク帯域が増加（上昇）した場合には、挿入遅延量の減少を図る。これによって、ＴＣＰでのスループット調整に比べ、リンク帯域の増加に対し、効率的にスループットを追従させる（増加させる）ことができる。従って、リンク帯域の増加に効率的に追随できないことによる帯域の無駄を解消することができる。よって、実施形態１〜５によれば、回線帯域の利用効率を高めるとともに結果的に高いスループットを得ることができる。
Ｐ１・・・データパケット
Ｐ２・・・ＡＣＫパケット
１・・・プロバイダ網
２・・・インターネット
４・・・ゲートウェイ
５・・・アクセス網
６，７・・・基地局
８・・・フェムト基地局
９，１０，１２，１４・・・端末
１１，１００・・・通信アダプタ
１３・・・ＣＰＥ
１５・・・通信相手（ＣＮ）
２１・・・クライアント
２２・・・ネットワーク
２２Ａ・・・Ｌ２対向装置
２３・・・サーバ
２４，２５・・・リンク
２６，２６Ａ，２６Ｂ，２６Ｃ・・・トラフィック制御装置
２７，２８，１２８ａ，１２８ｂ，１２８ｃ，２２８ａ，２２８ｂ，２２８ｃ・・・キュー
３１・・・受信処理部
３２・・・リンク帯域検出部
３３・・・ＲＴＴ測定部
３４・・・滞留時間制御部
３５・・・送信処理部
３６Ａ，３６Ｂ・・・フロー振分部
３８・・・プロトコル振分部
３９，３９Ａ，３９Ｂ・・・スケジューラ
４１，５１・・・アプリケーション
４２，５２・・・ＴＣＰ機能
１００・・・通信アダプタ
１００Ａ・・・モバイルルータ
１００Ｂ・・・基地局
１０１・・・ＣＰＵ
１０２・・・ＲＡＭ
１０３・・・フラッシュＲＯＭ
１０４，１０５・・・リンクインタフェース
１０６・・・ＰＨＹ／ＲＦ部
１０７・・・アンテナ
１１０・・・パーソナルコンピュータ
１１１・・・記録媒体
２０１，２０４・・・送信部
２０２，２０３・・・受信部
２０６・・・コネクション管理部
２０７・・・コネクション管理テーブル
２０９・・・遅延量決定部
２３８Ａ，２３８Ｂ・・・コネクション識別処理部

Claims (11)

  1. ウィンドウサイズを用いたフロー制御及び輻輳制御を行う特定のプロトコルに従って送信側のエンドと受信側のエンドとの間をパケットが流れるパケット転送路上に配置される通信ノードであって、
    前記転送路上にあるリンクからパケットを受信する処理と、前記リンクへパケットを送信する処理とを行う通信インタフェースと、
    前記リンクから受信される前記特定のプロトコルのパケット又は前記リンクへ送信される前記特定のプロトコルのパケットを一時的に蓄積するキューを記憶する記憶装置と、
    前記リンクの受信側の現在の帯域に基づき、前記キューに蓄積されたパケットの滞留時間を調整する制御装置と、を含み、
    前記制御装置は、前記リンクの受信側の帯域が所定値から低下した量が大きくなるほどパケットの滞留時間を長くする
    通信ノード。
  2. 前記制御装置は、前記リンクから受信されるパケット又は前記リンクへ送信されるパケットのプロトコル種別を判別し、プロトコル種別が前記特定のプロトコルを示すときに、当該パケットを前記キューに蓄積する
    請求項１に記載の通信ノード。
  3. 前記制御装置は、前記特定のプロトコルのパケットの観測によって得られるラウンドトリップタイムと、前記リンクの受信側の現在の帯域とを用いて前記キューに蓄積されたパケットの滞留時間を算出する
    請求項１又は２に記載の通信ノード。
  4. 前記制御装置は、前記キューに蓄積されるパケットの滞留時間が変化して所定の滞留時間に至るように、前記キューに蓄積されるパケットの滞留時間を調整する
    請求項１から３のいずれか１項に記載の通信ノード。
  5. 前記特定のプロトコルは、エンド間の通信開始に当たってエンド間のコネクションを確立し、
    前記記憶装置は、コネクションに関連づけられた１以上のキューを記憶し、
    前記制御装置は、前記リンクから受信される前記特定のプロトコルのパケット又は前記リンクへ送信される前記特定のプロトコルのパケットのコネクションを判別し、コネクションの判別結果に対応する前記１以上のキューの何れかに当該パケットを蓄積する処理と、各キューに蓄積されるパケットのラウンドトリップタイムを求めて、各キューに蓄積されるパケットの滞留時間を算出する処理とを行う
    請求項１から４のいずれか１項に記載の通信ノード。
  6. 前記制御装置は、前記キューに蓄積されるパケットの滞留時間の調整に用いる遅延量Ｄを、ラウンドトリップタイムの値ＲＴＴと、前記リンクの受信側の最大帯域ＢＷmaxと、
    前記リンクの受信側の現在の帯域ＢＷnowとを用いて、以下の式、
    Ｄ ＝ ＲＴＴ ×（ＢＷmax − ＢＷnow ／ ＢＷnow）
    により求める
    請求項１から５のいずれか１項に記載の通信ノード。
  7. 前記制御装置は、前記キューに蓄積されるパケットの滞留時間を変化させて前記遅延量Ｄに対応する滞留時間にするときに、変化の勾配Ｋを、今までの帯域ＢＷprevと新たな帯域ＢＷnewとを用いて以下の式、
    Ｋ＝（ＢＷprev／ＢＷnew）−１
    で求めるとともに、単位時間当たりの遅延量Ｄ（ｔ）を、以下の式、
    Ｄ（ｔ）＝Ｄ（ｔ０）＋Ｋ（ｔ−ｔ０）
    で求める請求項６に記載の通信ノード。
  8. 前記制御装置は、新たなコネクションの確立が検出されたときに、当該コネクションに付与する遅延量を求めるとともに、当該コネクションに付与される初回の遅延量が０又は最小値で、その後、当該コネクションに関して定められた期間で前記求めた遅延量に達するように、当該コネクションに対応するキューに蓄積されるパケットの滞留時間を調整する
    請求項４に記載の通信ノード。
  9. 前記キューは、前記確認応答を含むパケットを蓄積する
    請求項１から８のいずれか１項に記載の通信ノード。
  10. ウィンドウサイズを用いたフロー制御及び輻輳制御を行う特定のプロトコルに従って送信側のエンドと受信側のエンドとの間をパケットが流れるパケット転送路上に配置されるコンピュータに、
    前記転送路上にあるリンクからパケットを受信する処理と、
    前記リンクへパケットを送信する処理と、
    前記リンクから受信される前記特定のプロトコルのパケット又は前記リンクへ送信される前記特定のプロトコルのパケットをキューに蓄積する処理と、
    前記リンクの受信側の現在の帯域に基づき、前記キューに蓄積されたパケットの滞留時間を調整する処理とを実行させ、
    前記滞留時間を調整する処理において、前記リンクの受信側の帯域が所定値から低下した量が大きくなるほどパケットの滞留時間を長くする
    プログラム。
  11. ウィンドウサイズを用いたフロー制御及び輻輳制御を行う特定のプロトコルに従って送信側のエンドと受信側のエンドとの間をパケットが流れるパケット転送路上に配置される通信ノードが、
    前記転送路上にあるリンクからパケットを受信する処理と、
    前記リンクへパケットを送信する処理と、
    前記リンクから受信される前記特定のプロトコルのパケット又は前記リンクへ送信される前記特定のプロトコルのパケットをキューに蓄積する処理と、
    前記リンクの受信側の現在の帯域に基づき、前記キューに蓄積されたパケットの滞留時間を調整する処理とを行い、
    前記滞留時間を調整する処理において、前記リンクの受信側の帯域が所定値から低下した量が大きくなるほどパケットの滞留時間を長くする
    通信ノードのトラフィック制御方法。
JP2013249286A 2013-12-02 2013-12-02 通信ノード Active JP6303452B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013249286A JP6303452B2 (ja) 2013-12-02 2013-12-02 通信ノード
US14/557,486 US9674095B2 (en) 2013-12-02 2014-12-02 Communication node

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013249286A JP6303452B2 (ja) 2013-12-02 2013-12-02 通信ノード

Publications (2)

Publication Number Publication Date
JP2015106880A JP2015106880A (ja) 2015-06-08
JP6303452B2 true JP6303452B2 (ja) 2018-04-04

Family

ID=53266257

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013249286A Active JP6303452B2 (ja) 2013-12-02 2013-12-02 通信ノード

Country Status (2)

Country Link
US (1) US9674095B2 (ja)
JP (1) JP6303452B2 (ja)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10368255B2 (en) 2017-07-25 2019-07-30 Time Warner Cable Enterprises Llc Methods and apparatus for client-based dynamic control of connections to co-existing radio access networks
US9066153B2 (en) 2013-03-15 2015-06-23 Time Warner Cable Enterprises Llc Apparatus and methods for multicast delivery of content in a content delivery network
US11540148B2 (en) 2014-06-11 2022-12-27 Time Warner Cable Enterprises Llc Methods and apparatus for access point location
US10303626B2 (en) * 2015-03-31 2019-05-28 Cavium, Llc. Approach for chip-level flop insertion and verification based on logic interface definition
KR102350504B1 (ko) * 2015-04-27 2022-01-14 삼성전자주식회사 통신 시스템에서 하향링크 전송률 제어를 위한 장치 및 방법
JP6464911B2 (ja) * 2015-05-01 2019-02-06 富士通株式会社 情報処理システム、情報処理システムの制御方法及び受信装置
US10284484B1 (en) * 2015-07-15 2019-05-07 Cisco Technology, Inc. Accelerated ramp up for delay-based rate adaptation
WO2017094235A1 (ja) * 2015-11-30 2017-06-08 日本電気株式会社 冗長化処理装置、情報処理装置、冗長化システム、方法および記憶媒体
US9986578B2 (en) 2015-12-04 2018-05-29 Time Warner Cable Enterprises Llc Apparatus and methods for selective data network access
US10327187B2 (en) 2015-12-04 2019-06-18 Time Warner Cable Enterprises Llc Apparatus and method for wireless network extensibility and enhancement
JP6528691B2 (ja) * 2016-01-20 2019-06-12 富士通コネクテッドテクノロジーズ株式会社 通信装置及び通信制御プログラム
US9918345B2 (en) 2016-01-20 2018-03-13 Time Warner Cable Enterprises Llc Apparatus and method for wireless network services in moving vehicles
US10554572B1 (en) * 2016-02-19 2020-02-04 Innovium, Inc. Scalable ingress arbitration for merging control and payload
US10492034B2 (en) 2016-03-07 2019-11-26 Time Warner Cable Enterprises Llc Apparatus and methods for dynamic open-access networks
CN105871744A (zh) * 2016-03-31 2016-08-17 北京小米移动软件有限公司 动态控制流量的方法及装置
US10164858B2 (en) 2016-06-15 2018-12-25 Time Warner Cable Enterprises Llc Apparatus and methods for monitoring and diagnosing a wireless network
CN107800642A (zh) * 2016-08-31 2018-03-13 北京金山云网络技术有限公司 一种拥塞控制方法及装置
JP6805713B2 (ja) * 2016-10-19 2020-12-23 日本電気株式会社 受信トラヒックの高速化装置、高速化方法、および高速化プログラム
US10050884B1 (en) * 2017-03-21 2018-08-14 Citrix Systems, Inc. Method to remap high priority connection with large congestion window to high latency link to achieve better performance
US10645547B2 (en) 2017-06-02 2020-05-05 Charter Communications Operating, Llc Apparatus and methods for providing wireless service in a venue
US10638361B2 (en) 2017-06-06 2020-04-28 Charter Communications Operating, Llc Methods and apparatus for dynamic control of connections to co-existing radio access networks
CN111917656B (zh) * 2017-07-27 2023-11-07 超聚变数字技术有限公司 传输数据的方法和设备
JP7172126B2 (ja) * 2018-05-14 2022-11-16 オムロン株式会社 モータ制御装置
US10581759B1 (en) 2018-07-12 2020-03-03 Innovium, Inc. Sharing packet processing resources
US10834020B1 (en) 2019-05-09 2020-11-10 L3Harris Technologies, Inc. Scalable network overhead for contested environments

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999004536A2 (en) 1997-07-14 1999-01-28 Nokia Networks Oy Flow control in a telecommunications network
US6570876B1 (en) * 1998-04-01 2003-05-27 Hitachi, Ltd. Packet switch and switching method for switching variable length packets
TW527804B (en) * 2001-05-25 2003-04-11 Accton Technology Corp Method and apparatus for bandwidth management of TCP traffic employing post-acknowledgement control
KR20050085742A (ko) * 2002-12-19 2005-08-29 코닌클리케 필립스 일렉트로닉스 엔.브이. 무선 네트워크에서의 실시간 데이터 보호
JP4128198B2 (ja) * 2003-07-15 2008-07-30 富士通株式会社 帯域制御装置
EP1762052A1 (en) * 2004-06-22 2007-03-14 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Network feedback method and device
EP1779347A4 (en) 2004-08-17 2009-06-17 California Inst Of Techn METHOD AND DEVICE FOR NETWORK EXTENSION CONTROL USING A QUEEN CONTROL AND DISTANCE DELAY MEASUREMENTS
EP1758418A1 (en) * 2005-08-25 2007-02-28 NTT DoCoMo INC. Method for flow control during handover
WO2010032370A1 (ja) * 2008-09-19 2010-03-25 パナソニック株式会社 伝送レート制御装置及び伝送レート制御方法
JP5033150B2 (ja) 2009-02-10 2012-09-26 日本電信電話株式会社 データ送信制御装置、データ送信制御方法およびデータ送信制御プログラム
JP2011151738A (ja) * 2010-01-25 2011-08-04 Kyocera Corp 端末装置、制御プログラム及び制御方法
JP2011176693A (ja) * 2010-02-25 2011-09-08 Mitsubishi Electric Corp 移動体無線通信装置、ｔｃｐフロー制御装置及びその方法

Also Published As

Publication number Publication date
US20150156129A1 (en) 2015-06-04
US9674095B2 (en) 2017-06-06
JP2015106880A (ja) 2015-06-08

Similar Documents

Publication Publication Date Title
JP6303452B2 (ja) 通信ノード
US9641650B2 (en) TCP proxy server
JP6553196B2 (ja) トラフィックフローの監視
JP2020502948A (ja) パケット伝送システムおよび方法
CN108540380B (zh) 多子流网络传输方法及装置
US9635148B2 (en) Partitioning data sets for transmission on multiple physical links
EP3281380B1 (en) Method and system for the scheduling of packets in a bundling scenario based on tcp tunnels and native tcp information
EP2760182A1 (en) Data communication apparatus, data transmission method, and computer system
KR102111029B1 (ko) 다중망 병합 전송 장치, 그리고 이의 패킷 스케줄링 방법
JP5169338B2 (ja) 無線通信システム及びその方法と、それらに用いられる装置及びプログラム
WO2018157819A1 (zh) 多子流网络传输方法及装置
JP2009141565A (ja) 受信端末装置
JP2010130329A (ja) 通信装置および中継装置
JP2015149560A (ja) 制御装置及び制御方法
US9544235B2 (en) Scaling WiFi performance for large-audience environments via access points
JP6973511B2 (ja) 通信装置、通信システム、通信方法及びプログラム
Seyedzadegan et al. The TCP fairness in WLAN: a review
Kim et al. TCP acknowledgement compression for fairness among uplink TCP flows in IEEE 802.11 n WLANs
Cheng et al. Improving the ramping up behavior of TCP slow start
EP3386166A1 (en) Technique for managing communications at a router
Mishra et al. Effective impact of ECN with RED to control heavy congestion
Hamsa The Traffic-Aware Scatter Net Scheduling (TAAS) for Multicast Wireless Protocols
TW202335470A (zh) 網路流壅塞管理裝置及其方法
Shaii et al. Congestion avoidance: Network based schemes solution
JP4977677B2 (ja) エッジノードおよび帯域制御方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160804

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170602

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170718

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170911

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180206

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180219

R150 Certificate of patent or registration of utility model

Ref document number: 6303452

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150