JP5652388B2 - 通信レート制御方法、送信装置および通信システム - Google Patents

Description

本発明は、通信時の通信レートを決定する通信レート制御方法、送信装置および通信システムに関する。

インターネットで用いられるＴＣＰ／ＩＰ（Transport Control Protocol／Internet Protocol ）通信では、それぞれの送信装置が、回線速度や回線の輻輳状況に応じて通信レートを決定しつつ通信を行う。最も一般的に利用されているＴＣＰであるTCP Renoでは、送信側は、通信を開始すると徐々に通信レートを上げ、パケットが消失（ロス）するまで通信レートを上げる。

一般に、送信側は、パケットの往復時間に比例して通信レートを増加させ、パケットが送信側と受信側とを一往復する度に１パケット分だけ通信レートを増加させる。ネットワーク内でパケットがロスした場合には、送信側は、受信側からの確認応答（ＡＣＫパケット）を観察することによって、パケットのロスを知ることができる。送信側は、パケットがロスした場合には、通信レートを半分にするように制御する。

ＴＣＰを利用した通信で高い通信レートを実現するために、ＲＴＴ（Round Trip Time ）に対して十分に長い時間、パケットロスが発生しないことが要求される。例えば、１００ｍｓのＲＴＴがある回線において、ＴＣＰを利用した通信で１０Ｇｂｐｓまでスループットを上げるには、約２時間パケットロスが生じないことが条件になる。しかし、現実には、そのように低いパケットロスを実現することができないことが多い。

パケットロスが発生するような場合においてもＴＣＰを利用した通信で高いスループットを発揮させるために、ＴＣＰを改良したり、ネットワークを改良したりする努力が続けられている。

改良されたＴＣＰであるＴＣＰ Westwood では、パケットロスが発生したときにネットワークの往復遅延（ＲＴＴ）が通常の往復遅延よりも増加していたか否か判定し、ＲＴＴが増加していない場合には、リンクにおける通信エラーが発生したと捉えて通信レートを低下させない（例えば、非特許文献１参照）。

しかし、高速な回線ではネットワーク装置におけるバッファが満杯になるまでの時間が短いので、ＲＴＴの変化も高速になる。ＲＴＴが高速に変化するので、ＲＴＴの増加を検出することが困難になる。また、長距離通信では、多くのネットワーク装置を経由するので、ＲＴＴは常に変動している。よって、ボトルネックになる箇所における遅延の増加を正しく検出することができない。このように、改良されたＴＣＰを用いても、高い性能を発揮することができない。

また、特許文献１では、ＴＣＰの通信レート制御方法は実施されていないものの、ネットワークの状態を正確に把握するために、無線区間を挟むようにゲートウェイ装置を配置し、無線区間で発生した通信エラーを計測し、計測された通信エラーをもとに前方誤り訂正符号（ＦＥＣ）の誤り耐性強度を設定する方法が提案されている。その方法を利用すると、無線区間でのビットエラーが原因になるパケットロスを隠蔽することができる。しかし、上記の高速な長距離通信におけるパケットロスの課題を解決することはできない。

特許文献２では、無線リンクにおけるエラー率が増加した場合に、パケットがロスすることを防ぐための装置が提案されている。その装置では、無線リンクにおけるエラーを監視し、エラーが増加した場合には、端末間のＴＣＰ通信を停止させる。ＴＣＰ通信を停止させるために、ＴＣＰの確認応答に記載された広告ウィンドウ（受信端末が受信可能なデータサイズを示す。）を０に変えてパケットを送信する。しかし、その方法では、無線リンクのエラー率が増加している間はパケットを送信することができない。また、端末間でやり取りされている広告ウィンドウにおいて、一度広告された値を減らすことができない。すると、通信を急に完全停止することはできない。その結果、結局パケットがロスしてしまう課題がある。

特開２００３−１５２７５２号公報 特許第３７９７５３８号公報

S. Mascolo, C. Casetti, M. Gerla, S. S. Lee, and M. Sanadidi, "ＴＣＰ Westwood ：congestion control with faster recovery "，UCLA CSD Technical Report ＃200017，２０００年

上記のように、高速な長距離回線を利用した場合に、ＴＣＰやＳＣＴＰ（Stream Control Transmission Protocol）等の通信レート制御を含む端末間通信プロトコルの通信性能が発揮されないという課題がある。具体的には、パケットロスまたは遅延が増大した原因がわからないために、ＴＣＰを利用した通信の通信レートを適切に設定できない。また、高速通信では、パケットロスの予兆を端末で検出することができないので、ＴＣＰの通信レートを適切に設定できず、パケットがロスしてしまう。さらに、ＴＣＰ通信ではＲＴＴが大きい場合に適切な通信レートに設定することに長い時間を要する。

そこで、本発明は、データ消失の発生を判定し、かつ、ネットワークにおける通信機器から通信エラーの情報を収集し、判定結果および収集結果を参照して輻輳以外の原因によるデータ消失を把握することによって、データ消失の原因および遅延が増大した原因を適切に把握して、輻輳状況に適応した通信レート制御を行うことができる通信レート制御方法、送信装置および通信システムを提供することを目的とする。

本発明による通信レート制御方法は、通信ネットワークを介して受信装置にデータを送信する送信装置が通信レートを制御する通信レート制御方法であって、通信ネットワークにおける輻輳に起因してデータの消失が生ずることを、通信ネットワークの一の区間における中継装置のデータバッファの利用率にもとづいて検知し、通信ネットワークにおけるデータエラーに起因してデータの消失が生じたことを検知し、一の区間よりも受信装置の側の区間である他の区間におけるデータエラーの発生状況を検知し、輻輳に起因してデータの消失が生ずる場合とデータエラーに起因してデータの消失が生じた場合とで、別系統の通信レート制御を適用し、データバッファの利用率に応じて通信レートを変化させ、データエラーの発生状況に応じて通信レートを制御し、中継装置から送信される通信を一時停止させるためのリンク層のポーズ信号またはバックプレッシャ信号を輻輳通知として使用して、輻輳に起因してデータの消失が生ずることを検知し、データエラーの発生状況を検知する際に、ＴＣＰの確認応答信号によってパケットロスを検知した場合にデータエラーが発生しているとみなすことを特徴とする。

本発明による送信装置は、通信ネットワークを介して受信装置にデータを送信する送信装置であって、通信レートを制御する通信レート制御手段と、通信ネットワークにおける輻輳に起因してデータの消失が生ずることを、通信ネットワークの一の区間における中継装置のデータバッファの利用率にもとづいて検知する第１の通信エラー検知手段と、通信ネットワークにおけるデータエラーに起因してデータの消失が生じたことを検知するとともに、一の区間よりも受信装置の側の区間である他の区間におけるデータエラーの発生状況を検知する第２の通信エラー検知手段とを備え、通信レート制御手段が、データの消失が生ずることを第１の通信エラー検知手段が検知した場合と、データエラーに起因してデータの消失が生じたことを第２の通信エラー検知手段が場合とで、独立して通信レートを制御し、データバッファの利用率に応じて通信レートを変化させ、データエラーの発生状況に応じて通信レートを制御し、第１の通信エラー検知手段は、通信を一時停止させるためのリンク層のポーズ信号またはバックプレッシャ信号を輻輳通知として使用して、輻輳に起因してデータの消失が生ずることを検知し、第２の通信エラー検知手段は、データエラーの発生状況を検知する際に、ＴＣＰの確認応答信号によってパケットロスを検知した場合にデータエラーが発生しているとみなすことを特徴とする。

本発明による通信システムは、データを中継する中継装置および通信ネットワークを介して送信装置が受信装置にデータを送信する通信システムであって、中継装置が、送信装置と伝送路との間に設けられ、データバッファの利用率にもとづいて通信ネットワークにおける輻輳に起因してデータの消失が生ずることを検出した場合に、送信装置にその旨を通知し、送信装置が、通信レートを制御する通信レート制御手段と、通信ネットワークにおける輻輳に起因してデータの消失が生ずることを中継装置からの通知によって検知する第１の通信エラー検知手段と、通信ネットワークにおけるデータエラーに起因してデータの消失が生じたことを検知するとともに、中継装置よりも受信装置の側の区間である他の区間におけるデータエラーの発生状況を検知する第２の通信エラー検知手段とを含み、通信レート制御手段が、データの消失が生ずることを第１の通信エラー検知手段が検知した場合と、データエラーに起因してデータの消失が生じたことを第２の通信エラー検知手段が場合とで、独立して通信レートを制御し、データバッファの利用率に応じて通信レートを変化させ、データエラーの発生状況に応じて通信レートを制御し、第１の通信エラー検知手段は、通信を一時停止させるためのリンク層のポーズ信号またはバックプレッシャ信号を輻輳通知として使用して、輻輳に起因してデータの消失が生ずることを検知し、第２の通信エラー検知手段は、データエラーの発生状況を検知する際に、ＴＣＰの確認応答信号によってパケットロスを検知した場合にデータエラーが発生しているとみなすことを特徴とする。

本発明によれば、データ消失の原因および遅延が増大した原因を適切に把握して、輻輳状況に適応した通信レート制御を行うことができる。

本発明による通信システムの第１の実施形態を示すブロック図である。 送信端末の構成例を示すブロック図である。 ＴＣＰ処理部の動作を示すフローチャートである。 ＴＣＰ処理部のＡＣＫ受信時の動作を示すフローチャートである。 スイッチの構成例を示すブロック図である。 回線終端装置の構成例を示すブロック図である。 本発明による通信システムの第２の実施形態を示すブロック図である。 第２の実施の形態におけるＴＣＰ処理部のＡＣＫ受信時の動作を示すフローチャートである。 本発明の主要部を示すブロック図である。

実施形態１．
図１は、本発明による通信システムの第１の実施形態を示すブロック図である。

本実施形態では、通信プロトコルとして、通信レート制御を含む端末間プロトコルにおいて最も一般的に利用されるＴＣＰを例にして説明を行う。ＴＣＰ等では、通信レートを制御するために、輻輳ウィンドウと呼ばれる値を用いる。輻輳ウィンドウとは、送信端末がネットワーク（通信ネットワーク）中に一度に送信できるパケット数である。送信端末は、受信端末から確認応答（ＡＣＫ）が返信されたパケット番号から、そのパケット番号に輻輳ウィンドウ分を加算したパケット番号までのパケットを送信できる。つまり、輻輳ウィンドウとは、パケットが送信端末と受信端末との間のネットワークを往復する時間（ＲＴＴ）毎に、送信端末がネットワークに送信するパケット数である。従って、端末間の通信レートは、（輻輳ウィンドウ／ＲＴＴ）になる。なお、本実施形態では通信レートを主に輻輳ウィンドウを用いて表現するが、通信レートを他の方法（例えば、ｂｐｓ）で表現する場合にも、本実施形態を適用することができる。

図１に示された通信システムにおいて、送信装置としての送信端末１１が受信端末２１にＴＣＰを利用してデータを送信する場合を想定する。送信端末１１は、受信端末２１を宛先としたパケット群をスイッチ（第１のスイッチ）３１に送信する。パケットは、スイッチ３１、回線終端装置（第１の回線終端装置）４１、回線終端装置（第２の回線終端装置）４２、スイッチ（第２のスイッチ）３２の順に転送され、受信端末２１がパケット群を受信する。また、同時に、送信端末１２は、受信端末２２にパケット群を送信しているとする。

送信端末１１からのパケット群と送信端末１２からのパケット群とはスイッチ３１を介して１つの回線に合流するので、スイッチ３１において、送信端末１１からのパケット群および送信端末１２からのパケット群による２つのトラヒックが輻輳してパケットがロスする可能性がある。また、回線終端装置４１と回線終端装置４２との間の通信ネットワークでは、伝送中に信号劣化などの原因でビットエラーが発生し、パケットがロスする可能性がある。

本実施形態では、スイッチ３１は、送信端末１１からパケットを受信した際に、この後もパケットを受信すると輻輳によってパケットがロスしてしまうと判定した場合には、輻輳通知を送信端末１１に向けて送信する。実際にパケットがロスしてしまった場合には、パケットのシリアル番号を輻輳通知に含めるように構成してもよい。具体的には、例えば、スイッチ３１が通信回線を介してパケットを受信した際に、スイッチ３１内のバッファが満杯でパケットを記憶できない場合に、パケットヘッダを参照して、パケットの送信元に輻輳通知を送信する。

また、バッファが満杯で記憶できないことに代えて、バッファの利用率が設定値（例えば、９０％）を越えた場合に、前もって輻輳通知を送信するように構成してもよい。また、例えば、バッファが増減する変動速度を通信履歴から推定し、バッファの利用率が上昇した場合に、所定時間後にバッファが満杯になる可能性があると判定したときには、輻輳通知を送信するように構成してもよい。

例えば、バッファの容量がＱMbyte（Ｍバイト）である場合を考える。通信履歴から、１秒（単位時間）あたりのバッファの平均増加速度がＱ／１０であったとする。平均増加速度を計算するには、例えば、単位時間においてバッファの利用率がもっとも低かった量Ｈと最も大きかった量Ｓを比較した値（例えば、Ｈ−Ｓ）を利用する。一例として、平均増加速度がＱ／１０であった場合に、バッファの空き容量が（９Ｑ／１０）になったら、輻輳通知を送信することが考えられる。なお、例えば、スイッチ３１から送信端末１１まで輻輳通知が到達するまでの時間Ｔにもとづいて、平均増加速度を計算するために用いる単位時間を決定することができる。

送信端末１１は、スイッチ３１から輻輳通知を受信すると、輻輳が発生したとして、ＴＣＰの通信レートを調整する。例えば、通信レートを、２／３等のあらかじめ設定された割合で低下させる。このような制御によって、パケットロスを未然に防止することができる。

上記の説明では、スイッチ３１が送信端末１１からパケットを受信する際の輻輳を例にしたが、スイッチ３１が送信端末１２からパケットを受信する際の輻輳についても同様に制御される。

なお、既知のＴＣＰ通信技術として、ルータでの輻輳を示すフラグをパケット内に記すＥＣＮ（Explicit Congestion Notification）技術があるが、ＥＣＮでは、パケット内にＥＣＮフラグを立てるのみである。ＥＣＮフラグによって送信端末が輻輳を知ることができる時点は、受信端末が、受信したパケット内に記されたＥＣＮフラグを認識した後、送信端末にパケットを送信し、そのパケットが送信端末に到着したときである。従って、送信端末がＥＣＮフラグを受信するまでにパケットが往復する時間が必要になる。すると、送信端末が輻輳を検出する前に、輻輳によってパケットがロスしてしまう可能性がある。また、輻輳の予兆が検出できた場合にはＥＣＮを利用できるが、ビットエラーによってパケットがロスした場合には利用することはできない。

また、本実施形態において、スイッチからの輻輳通知に代えて、リンクプロトコルで定義されているポーズシグナル機能（または、バックプレッシャ機能等）を利用して、送信端末が輻輳の発生を認識することもできる。ポーズシグナル機能は、ある通信回線の先に存在するスイッチにおいて輻輳が発生する場合に、その通信回線にパケットを送信する送信者（スイッチや端末）にパケットの送信を一時停止させるための信号（ポーズ信号やバックプレッシャ信号）を送信する機能である。ただし、ポーズシグナル機能はリンクレイヤのプロトコルであるから、一般的な送信端末におけるＴＣＰ処理部は、ポーズ信号を観察することはできない。そこで、ポーズシグナル機能を利用して輻輳の発生を認識する場合には、本実施形態における送信端末を、ポーズ信号を受信し、端末内でポーズ信号を輻輳通知に変えるように構成する。また、送信端末におけるＴＣＰ処理部が、ポーズ信号を直接観察することに代えて、ＩＰ層の送信キューを観察し、ＩＰ層の送信キューが増加した場合に輻輳が発生したと判定することもできる。

回線終端装置４２は、回線終端装置４１を介して送信端末１１からのパケットを受信する。そして、パケットにビットエラーが含まれていて、そのパケットを廃棄することになった場合には、送信端末１１と回線終端装置４１とにビットエラー通知を送信する。送信端末１１に送信されるビットエラー通知には、廃棄されたパケットのシリアル番号等が格納されている。送信端末１１は、いずれのパケットがロスしたのかを知ることができる。送信端末１１は、回線終端装置４２からビットエラー通知を受信した場合には、パケットの通信レートを下げない。

送信端末１１は、回線終端装置４２からのビットエラー通知を受信した場合に、直ちに、廃棄されたパケットの再送を行う。すなわち、ネットワークの輻輳の状況に関係なく、パケットの再送を行う。また、受信端末２１からパケットロスを示すパケットが到着した場合にも、輻輳によるパケットロスではないと判定してパケットの通信レートを下げない。

なお、送信端末１１は、ビットエラー通知や輻輳通知を受け取らない場合にも、一般的なＴＣＰによる通信レート制御よりも、迅速に通信レートを増加させることができる。例えば、TCP Renoでは、パケットロスが発生した後、ＲＴＴ毎に１パケット分通信レートを増加させるのに対して、本実施形態では、α倍の速度で通信レートを増加させたり、ＲＴＴ毎、（ＲＴＴ／２）などＲＴＴにもとづく時間毎、または設定時間毎に通信レートを倍増させる。また、ＲＴＴによらず、設定時間Ｋが経過したときに所望の通信レートＲに到達するよう、（Ｒ／Ｋ）の割合で通信レートを増加させるように構成してもよい。

また、送信端末１１は、ビットエラー通知や輻輳通知を受け取らない場合に、一般的なＴＣＰ（例えば、TCP Reno）による通信レート制御と比較して、パケットロスがあったときにも通信レートを低下させにくくするように構成してもよい。例えば、一般的なＴＣＰでは、パケットロスが発生する度に通信レートを半減させるように輻輳ウィンドウを半減させる。しかし、本実施形態において、通信レートを安定させるためにう、通信レートを例えばパケットロス時の８０％にするなど、設定された割合で低下させるように構成してもよい。また、例えば、パケットロスが発生せず、安定して通信できた履歴を保管し、その履歴を参照して、通信レートを決定するように構成してもよい。

また、回線終端装置４１，４２、スイッチ３１，３２が、送信端末１１からのパケットを受信した際に、パケットの転送方向のリンクの利用可能な回線容量等を送信端末１１に通知するように構成してもよい。例えば、スイッチ３１，３２で利用可能な帯域の最大値は回線容量であるが、期待されるスループットは、回線容量をＴＣＰコネクションで分け合った値になる。また、例えば、回線終端装置４１，４２において利用可能な最大帯域幅は、エラー訂正符号を付加することのオーバヘッドを回線容量から差し引いた値になる。ただし、回線終端装置４１，４２間でエラー訂正符号が利用されない場合には、実際に利用可能な帯域（実効帯域）は回線におけるエラー率ρとすると（１−ρ）を回線容量Ｂにかけた値（Ｂ（１−ρ））になる。この場合には、利用可能な回線容量等を送信端末１１に通知することによって、間接的に、エラー率ρが送信端末１１に通知される。

また、送信端末１１は、ＴＣＰの通信レートを実効帯域に合わせるようにしてもよい。すなわち、通信レートを、エラー率にもとづいて算出された通信レートの最大値に適合させるようにしてもよい。例えば、ＴＣＰの輻輳ウィンドウを（Ｂ（１−ρ）／ＲＴＴ）にする。また、例えば、実効帯域を複数のＴＣＰコネクションで分け合うようにしてもよい。すなわち、ＴＣＰの通信レートがそれぞれ（Ｂ（１−ρ）／Ｃ）になるように、輻輳ウィンドウを制御するようにしてもよい。ＣはＴＣＰコネクション数を示す。この場合、各ＴＣＰコネクションの輻輳ウィンドウは、（Ｂ（１−ρ）／（Ｃ・ＲＴＴ））になる。よって、送信端末１１は、データエラーの発生状況に応じて通信レートを変化させることになる。

なお、上記の説明では、送信端末１１がパケットを送信する場合を例にしたが、送信端末１２がパケットを送信する場合も同様に制御される。

以上に説明したように、本実施形態における送信端末１１，１２は、ネットワークにおける輻輳の発生を迅速に察知すること、および、ビットエラーによるパケットロスの発生を把握することができるので、高い通信性能を発揮することができる。

次に、送信端末１１，１２の具体的な構成例を説明する。図２は、送信端末１１の構成例を示すブロック図である。なお、送信端末１２の構成も、送信端末１１の構成と同じである。

図２に示すように、送信端末１１は、送信されるデータを格納するデータ記憶部１１１と、データ記憶部１１１からデータを取り出してＴＣＰ処理部１１３に出力するアプリケーション１１２と、アプリケーション１１２から入力したデータをセグメント化し、輻輳通知とエラー通知も参照して通信レートを制御しつつＩＰ処理部１１４に出力するＴＣＰ処理部１１３と、ＴＣＰ処理部１１３からパケットを入力して、入出力処理部１１５に出力するＩＰ処理部１１４と、ＩＰ処理部１１４から受け取ったパケットを通信回線に送出する入出力処理部１１５と、ＩＰ処理部がパケットを一時保管するパケット記憶部１１６とを含む。

ＴＣＰ処理部１１３は、アプリケーション１１２から受け取ったデータをセグメント化し、輻輳ウィンドウを参照しつつデータの送信を決定し、セグメントをパケット化してＩＰ処理部１１４に渡すデータ送信部１１３２と、データ送信部１１３２がセグメントの処理時に用いる輻輳ウィンドウ等の情報を格納するためのセグメント記憶部１１３３と、スイッチ３１から受信した輻輳通知を輻輳ウィンドウ決定部１１３１に通知する輻輳通知受信部１１３４と、回線終端装置４２から受信したエラー通知を輻輳ウィンドウ決定部１１３１に通知するエラー通知受信部１１３５とを含む。

次に、図３および図４のフローチャートを参照してＴＣＰ処理部１１３の動作を説明する。

ＴＣＰ処理部１１３は、アプリケーション１１２からデータを入力した場合、およびＩＰ処理部１１４からＡＣＫパケットを入力した場合に処理を開始する。なお、送信を待つセグメントがある限りタイマがセットされ、タイマが起動する度に、アプリケーション１１２からデータを入力した場合と同様に送信処理が行われる。

図３に示すように、ＴＣＰ処理部１１３がアプリケーション１１２からデータを入力した場合には（ステップＳ３０１）、ＴＣＰ送信部１１３におけるデータ送信部１１３２は、データを設定されたサイズごとに分割してセグメントとし、セグメントにシリアル番号をつけた後、セグメント記憶部１１３３にセグメントを格納する（ステップＳ３０２）。

次いで、輻輳ウィンドウ決定部１１３１は、前回輻輳通知を受け取った時刻と現在時刻とを比較し、設定時間以内に（現在時刻から設定時間を越えない過去に）輻輳通知を受信していた場合には、ステップＳ３０４に移行する。設定時間以内に受信していなかった場合にはステップＳ３０５に移行する。

ステップＳ３０４では、輻輳ウィンドウ決定部１１３１は、輻輳ウィンドウを減らす（「Cwnd＝Cwnd÷Ａ」にする。）。本実施形態では、Ａを２にする。ただし、A＜２にしたり、任意の計算式によって決定してもよい。そして、ステップＳ３０５に移行する。

ステップＳ３０５では、輻輳ウィンドウ決定部１１３１は、輻輳ウィンドウ（Cwnd）、送信済みシリアル番号（UnAcked ）および受信確認済みシリアル番号（Acked ）を参照し、送信済みで受信確認されていないパケット数が輻輳ウィンドウよりも大きい場合（Cwnd＞UnAcked −Acked の場合）には、パケットを送信することができる判定し、ステップＳ３０６に移行する。そうでない場合（Cwnd≦UnAcked −Acked の場合）には、処理を終了する。

ステップＳ３０６では、データ送信部１１３２は、セグメント記憶部１１３３から次に送信するべき番号（UnAcked ＋１からCwndまで）のセグメントを取り出し、パケットを作成して、作成したパケットをＩＰ処理部１１４に出力する。そして、処理を終了する。ただし、ＩＰ処理部１１４からパケット記憶部１１６が満杯のために受け取れないとのエラー通知が返送された場合には、パケットの出力を一時停止し、その後、再度パケットの出力を試みる。

図４に示すように、ＴＣＰ処理部１１３がＩＰ処理部１１４からＴＣＰのＡＣＫパケットを入力した場合には（ステップＳ４０１）、データ送信部１１３２は、パケットロスが発生したか否か判定し、パケットロスがあったと判定した場合には、ロスしたパケット番号（Lost）を記憶する。そして、データ送信部１１３２は、ロスしたパケットを受信端末に向けて再送する。その後、ステップＳ４０３に移行する。パケットロスがなかったと判定した場合には、ステップＳ４０４に移行する。なお、パケットロスの有無を判定する方法として、ＳＡＣＫオプションを用いる方法や、同じ番号のＡＣＫパケットを連続して受信したことを検出する方法等がある。

ステップＳ４０３では、輻輳ウィンドウ決定部１１３１は、ロスしたパケット番号（Lost）が、エラー通知を受信しているパケット番号集合（Errored ）に含まれているか否か調べる。ロスしたパケット番号（Lost）がパケット番号集合に含まれている場合には、パケットは、輻輳以外の原因でロスしたと判定し、ステップＳ４０４に移行する。

ステップＳ４０４では、輻輳ウィンドウ決定部１１３１は、輻輳ウィンドウを増加させる。例えば、（Cwnd＝Cwnd＋１／ＲＴＴ）とする。ただし、Cwnd＝Cwnd＋β（βは任意の設定値）としてもよい。そして、ステップＳ４０６に移行する。

ロスしたパケット番号（Lost）がパケット番号集合に含まれていない場合には、輻輳ウィンドウ決定部１１３１は、輻輳ウィンドウを減少させる（ステップＳ４０５）。例えば、（Cnwd＝Cwnd／２）とする。そして、ステップＳ４０６に移行する。

ステップＳ４０６では、輻輳ウィンドウ決定部１１３１は、前回輻輳通知を受け取った時刻と現在時刻とを比較し、設定時間以内に（現在時刻から設定時間を越えない過去に）輻輳通知を受信していた場合には、ネットワーク内で輻輳が発生していると判定しステップＳ４０７に移行する。設定時間以内に受信していなかった場合にはステップＳ４０８に移行する。

ステップＳ４０７では、輻輳ウィンドウ決定部１１３１は、輻輳ウィンドウを減少させる。例えば、（Cwnd＝Cwnd−１）とする。そして、ステップＳ４０８に移行する。

ステップＳ４０８では、データ送信部１１３２は、輻輳ウィンドウを参照し、パケットを受信端末にさらに送信できるか否か判定する。例えば、Cwnd＞Unacked であれば、（Cwnd−Unacked ）だけパケットを送信できるとする。受信端末にパケットをさらに送信できると判定した場合には、ステップＳ４０９に移行する。パケットを送信できないと判定した場合には、処理を終了する。

ステップＳ４０９では、データ送信部１１３２は、セグメント記憶部１１３３からセグメントを取り出し、パケットを作成して、ＩＰ処理部１１４にパケットを出力する。そして、処理を終了する。ただし、ＩＰ処理部１１４からパケット記憶部１１６が満杯のために受け取れないとのエラー通知が返送された場合には、データ送信部１１３２は、パケットの出力を一時停止し、その後、再度パケットの出力を試みる。

なお、上記の例以外にもＴＣＰには各種オプションなどがある。また、本実施形態の通信レート制御方法は、ＴＣＰのようなウィンドウ制御を利用するプロトコルに適用できるが、さらに、端末間で通信レートを適応させる一般的な通信にも適用可能である。

本実施形態では、受信端末は、一般的なＴＣＰによる受信動作を実現できる端末であればよい。受信端末は、送信端末からのセグメントを受信すると、確認応答であるＡＣＫパケットを送信端末に返送する。パケットがロスした場合には、重複ＡＣＫまたはＳＡＣＫで送信端末にパケットがロスしたことを通知する。

図５は、図１に示されたスイッチ３１の構成例を示すブロック図である。図５に示す例では、入出力処理部３１１は、送信端末１１からのパケットを受信する。入出力処理部３１２は、送信端末１２からのパケットを受信する。入出力処理部３１３は、送信端末１１，１２へのパケットを送信する。なお、図５には、１つの入出力処理部３１３が代表して示されている。パケット転送部３１４は、入出力処理部３１１，３１２のそれぞれが受信したパケットをパケット記憶部３１６に格納し、パケットヘッダを参照して出力先になる入出力処理部３１３を決定し、入出力処理部３１３にパケットを出力する。ただし、パケット転送部３１４は、入出力処理部３１３がパケット送信中である場合は、所定の設定時間後に再度パケット出力を試みる。

また、パケット転送部３１４は、輻輳判定部３１５から輻輳通知を入力した場合に、入出力処理部３１１，３１２から新たにパケットを受信したときには、受信したパケットの送信元に輻輳通知を送信する。輻輳判定部３１５は、パケット記憶部３１６の利用率を監視し、パケット記憶部３１６が満杯、または満杯付近（例えば、９０％）である場合、すなわち設定値以上である場合には、輻輳通知をパケット転送部３１４に出力し続ける。パケット記憶部３１６の利用率が設定値以下になった場合には、パケット転送部３１４への輻輳通知の出力を停止する。

図６は、図１に示された回線終端装置４２の構成例を示すブロック図である。図６に示す例では、入出力処理部４２１，４２２は、回線終端装置４１においてエラー訂正符号を付されたパケットを入力する。パケット転送部４２３は、受信したパケットをパケット記憶部４２４に格納する。パケット記憶部４２４に格納されたパケットは、エラー訂正符号処理部４２５によってデコードされ、軽度のビットエラーがあった場合には回復される。重度のビットエラーがあったパケットを一部しか復元できなかった場合には、エラー訂正符号処理部４２５は、そのパケットの一部をエラー判定部４２６に出力する。

エラー判定部４２６は、パケットの送信元アドレスとパケットのシリアル番号とを読み取れた場合には、送信元アドレスに、パケットのシリアル番号を格納したエラー通知を送信する。デコードが完了したパケットがパケット記憶部４２４にある場合には、パケット転送部４２３は、そのパケットを出力方向の入出力処理部に出力する。

なお、図１に示された回線終端装置４１の構成は、図５に示された回線終端装置４２の構成と同様であるが、回線終端装置４１では、エラー訂正符号処理部は、入出力処理部で受信されたパケットにエラー訂正符号を付加する。

以上のような処理によって、通信回線における輻輳とビットエラーとを送信端末１１，１２が迅速に検知することができ、輻輳とビットエラーに対して通信レートを適切に対応させることが可能になる。

すなわち、本実施形態では、送信端末は、ネットワークの通信機器（上記の例では、スイッチ３１）から輻輳状況を示す情報を発信させ、輻輳状況を示す情報を参照してパケットロスが発生したか否か判定する。また、ネットワークの通信機器（上記の例では、回線終端装置４２）から通信エラーの情報を収集し、通信エラーの情報を参照して輻輳以外の原因によるパケットロスを把握する。よって、パケットロスが発生した原因と遅延が増大した原因とを正しく把握することができる。その結果、輻輳状況に適切に適応させた通信レート制御を行うことができる。

また、ネットワークの通信機器（上記の例では、スイッチ３１）から輻輳の予兆を示す情報を発信させる場合には、送信端末は、輻輳の予兆を示す情報を参照してパケットロスが発生するか否か判定する。また、ネットワークの通信機器（上記の例では、回線終端装置４２）から通信エラーの情報を収集し、通信エラーの情報を参照して輻輳以外の原因によるパケットロスを把握する。よって、パケットロスが発生する原因と遅延が増大した原因とを正しく把握することができる。その結果、輻輳状況に適切に適応させた通信レート制御を行うことができる。

また、ネットワークにおける通信エラーの状況もしくは輻輳状況、またはその両方を把握することによって、ＴＣＰのレートを迅速に上昇させることができる。

実施形態２．
図７は、本発明による通信システムの第２の実施形態を示すブロック図である。第２の実施形態では、第１の実施形態の通信システムに対して、スイッチ（第３のスイッチ）３３、ＴＣＰプロキシ５１，５２およびスイッチ（第４のスイッチ）３４が追加されている。そして、第２の実施形態では、通信レート制御方法が、送信装置としてのＴＣＰプロキシ５１とＴＣＰプロキシ５２と間のＴＣＰ通信で利用されることを想定する。

ＴＣＰプロキシは、送信端末から受信したデータを、新たなＴＣＰコネクションを利用して転送する装置である。図７に示す例では、送信端末１１とＴＣＰプロキシ５１との間でＴＣＰコネクション＃１を利用してデータが転送され、ＴＣＰコネクション＃１を介してデータを受信したＴＣＰプロキシ５１は、本発明による通信レート制御方法を用いたＴＣＰコネクション＃２を利用してＴＣＰプロキシ５２にデータを転送する。ＴＣＰプロキシ５２が受信したデータは、ＴＣＰコネクション＃３を介して受信端末２１に転送される。

第２の実施形態では、本発明による通信レート制御方法を用いた通信は、ＴＣＰプロキシ間で実現される。端末とＴＣＰプロキシとの間の通信には、一般的なＴＣＰが利用される。そのように構成する場合には、様々な端末が本発明による通信レート制御方法を通信路の一部に利用することができる。なお、スイッチと端末との間の通信経路として、インターネットなどの回線を用いてもよい。

例えば、第２の実施形態を、回線終端装置間の回線遅延が大きく、かつビットエラーが発生する可能性がある海洋通信に適用することが考えられる。そのような遅延が大きな回線では、ＴＣＰ通信の性能が発揮されない現象が顕著である。本実施形態では、このような回線の両端にある回線終端装置の近く（例えば、スイッチを介したＬＡＮ内）にＴＣＰプロキシ５１，５２を配置して利用することによって、以下のように、回線の利用効率を向上させることができる。ただし、以下の説明において、ビットエラーによるパケットロスが発生するのは、回線終端装置４１，４２の間の通信ネットワークのみであるとし、他の通信経路においてビットエラーによるパケットロスはないものとする。

図７に示す通信システムにおいて、スイッチ３１とＴＣＰプロキシ５１と間の通信に、リンクレイヤのフローコントロールによるポーズ信号、またはバックプレッシャ信号を利用して、スイッチ３１とＴＣＰプロキシ５１と間でのパケットロスを防止する。ＴＣＰプロキシ５１のＩＰ層の送信バッファにはパケットが溜まることになるが、本実施形態では、ＴＣＰ処理部１１３は、ＩＰ層のバッファが満杯になった場合には、ＩＰ層のバッファに空きができるまでＴＣＰの送信を一時停止する。同様に、回線終端装置４１とスイッチ３１の間の回線にもリンクレイヤのフローコントロールによるポーズ信号、またはバックプレッシャ信号を利用して、スイッチ３１からのパケットロスを防止する。

また、ＴＣＰプロキシ５１から回線終端装置４１までを結ぶ全ての回線でリンクレイヤのフローコントロールが利用できない場合は、次のように、回線終端装置４１，４２間で利用可能な回線帯域を計算する。

すなわち、回線終端装置４１，４２間では、エラー訂正符号を付加することによって元のパケットに対してデータ量が増加するので、実際に回線終端装置４１，４２間で利用できる帯域は、増加したデータ量によるオーバーヘッドを除いた分になる。エラー訂正符号を用いる方法には、エラー率に応じて動的に符号の強度を変える方法がある。このため、利用可能な実効帯域は変動することになる。そこで、回線終端装置４１が実効帯域をエラー通知に含め、ＴＣＰプロキシ５１に通知する。ＴＣＰプロキシ５１は、通知された実効帯域を最大の通信レートとして、通信レートを制御する。なお、実効帯域を、エラー通知とは別に通知してもよい。

以上のようにして、ＴＣＰプロキシ５１は、回線終端装置４１，４２間で利用可能な実効帯域を越えて通信レートを上げることはなく、スイッチ３３からスイッチ３１への回線を利用しなければ回線終端装置４１内のパケットバッファが溢れることもない。また、回線終端装置４１内に、優先度付きキュー制御を導入し、ＴＣＰプロキシ５１経由のパケットを高い優先度に設定して、パケットロスを起こさないようにしてもよい。

以上のような制御によって、ＴＣＰプロキシ５１が送信したパケットが回線終端装置４２までの間でロスすることがなくなる。

また、図７に示す構成を利用すると、回線終端装置４２からスイッチ３２への回線に対して、スイッチ３２からＴＣＰプロキシ５２までの間の回線を高速または同じ速度の回線にすれば、同一方向の通信トラヒックが合流することもないので、輻輳が発生せず、パケットがロスしない。また、リンクレイヤのフローコントロールなどを利用することも可能である。ただし、回線終端装置４１，４２間ではリンクレイヤのフローコントロールを伝播させない。

以上のようにして、ＴＣＰプロキシ５１からＴＣＰプロキシ５２までの通信におけるパケットロスの原因を回線終端装置４１，４２間のエラーのみに限定することができる。よって、ＴＣＰプロキシ５２においてＴＣＰレベルでパケットロスが検出された場合には、回線終端装置４１，４２間のエラーによるパケットロスであると特定することができる。

また、本実施形態において、図８に示すように、ＴＣＰ送信側でのＡＣＫ受信時の動作を、第１の実施形態の場合と変える。すなわち、図８に示すように、ステップＳ８０３において、パケットロスを検知した場合にビットエラーによるものとみなす。なお、ステップＳ８０７において、ＴＣＰプロキシが送信するトラヒックは優先度の高いものであると想定し、輻輳ウィンドウを減らさないようにしてもよい。その他の処理は、図４に示された処理と同じである。

以上のように、本実施形態では、パケットロスが発生する原因を回線終端装置４１，４２間のビットエラーに限定できるので、通信レートは、ＴＣＰ通信を行うＴＣＰプロキシ５１から見て、回線終端装置４１または回線終端装置４１の手前に配置されたスイッチ３１が送信するリンクレイヤのフローコントロールで制御される。

よって、ＴＣＰプロキシ５１からのＴＣＰ送信処理では、輻輳の予兆を迅速に検知でき、迅速に通信レートを上昇させることができる。例えば、輻輳ウィンドウの初期値を十分大きく、例えば、一般に１〜４パケット分であるのに対して、１０００パケット等に設定することも可能になり、高い通信性能を発揮できる。

また、例えば、ＴＣＰプロキシ５１，５２間でビットエラー通知で特定できないパケットロスが発生しない限り、送信端末１１からＴＣＰプロキシ５１への通信レートと等しいレートで、ＴＣＰプロキシ５１からＴＣＰプロキシ５２にデータを送信するよう通信レート制御することもできる。

輻輳通知を受けたときに通信を一時停止してしまうと、遅延がある回線を経由してＴＣＰを利用する通信を行うと通信効率が著しく低下してしまう。現実的に、フローコントロールなどリンクレイヤの制御の利用は、遅延が十分に小さいネットワーク内に限られている。よって、遅延が大きい回線でＴＣＰ／ＩＰ通信等に利用することは困難である。しかし、第２の実施形態の構成では、送信端末からのデータを転送したＴＣＰをＴＣＰプロキシで一度終端し、異なるＴＣＰコネクションを利用して他のＴＣＰプロキシにデータを転送してＴＣＰを終端し、再び新たなＴＣＰコネクションを利用して受信端末にデータを転送する。

そのような構成によって、ビットエラーが発生する回線や、通信帯域が変動する回線など、ＴＣＰ／ＩＰ通信において性能低下の原因になる回線を含む通信において、ＴＣＰの通信レートを制御するＴＣＰプロキシから回線終端装置にネットワークで輻輳に起因するパケットロスをなくすことができる。さらに、回線終端装置を越えて受信側のＴＣＰプロキシに至るネットワークで輻輳に起因するパケットロスをなくすことができる。その結果、ＴＣＰの通信レート制御について、回線終端装置間で生ずるエラーのみを考慮するだけでよい。よって、従来の通信システムに比べて、高い通信性能を発揮することができる。

図９は、本発明による通信レート制御方法が実施される通信システムの主要部を示すブロック図である。図９に示すように、通信システムは、中継装置３ａ，３ｂおよび通信ネットワーク４を介して送信装置１が受信装置２にデータを送信する通信システムであって、送信装置１が、通信レートを制御する通信レート制御手段５と、通信ネットワークにおける輻輳に起因してデータの消失が生ずることを検知する第１の通信エラー検知手段６と、通信ネットワークにおけるデータエラーに起因してデータの消失（例えば、パケットロス）が生じたことを検知する第２の通信エラー検知手段７とを含み、通信レート制御手段５が、データの消失が生ずることを第１の通信エラー検知手段６が検知した場合と、データエラーに起因してデータの消失が生じたことを第２の通信エラー検知手段７が場合とで、独立して通信レートを制御する。

また、上記の実施形態には、以下のような通信レート制御方法も開示されている。

（１）輻輳に起因してデータの消失が生ずることを検知するために、データを中継する中継装置（例えば、スイッチ３１）におけるデータバッファ（例えば、パケット記憶部３１６）の利用率を使用する通信レート制御方法。

（２）データバッファの利用率に応じて通信レートを変化させ（例えば、パケット記憶部３１６が満杯、または満杯付近（例えば、９０％）である場合に通信レートを低下させる）、データエラーの発生状況に応じて通信レートを変化させる（例えば、パケットロスの有無の判定結果に応じて通信レートを変える。）通信レート制御方法。

（３）データバッファの利用率に応じて通信レートを変化させ、データエラーの発生状況によらず通信レートを維持する（例えば、パケットロスの発生を検知しても通信レートを変更しない。）通信レート制御方法。

（４）データエラーに起因してデータの消失が生じたことを検知した場合に、直ちにデータを再送する通信レート制御方法。

（５）データエラーに起因してデータの消失が生じたことを検知した場合に、輻輳の程度に関わらずデータを再送する通信レート制御方法。

（６）輻輳に起因してデータの消失が生ずることを通信経路における一の区間（例えば、送信端末１１とスイッチ３１との間の通信リンク）におけるデータバッファの利用率にもとづいて検知し、他の区間（例えば、スイッチ３１と回線終端装置４２との間の通信リンク）におけるデータエラーの発生状況を検知する通信レート制御方法。

（７）輻輳に起因してデータの消失が生ずることを検知する際に、一の区間における中継装置（例えば、スイッチ３１）から送信される輻輳通知を使用する通信レート制御方法。

（８）輻輳に起因してデータの消失が生ずることを検知する際に、一の区間における中継装置（例えば、スイッチ３１）から送信される通信を一時停止させるためのポーズ信号またはバックプレッシャ信号を使用する通信レート制御方法。

（９）データエラーの発生状況を検知する際に、トランスポート層における確認応答信号（例えば、ＴＣＰまたはＴＣＰに類するプロトコルにおけるＡＣＫ）を使用する通信レート制御方法。

（１０）データエラーの発生状況を検知する際に、通信経路に存在する伝送装置（例えば、回線終端装置４２）から送信されるエラー通知を使用する通信レート制御方法。

（１１）データエラーの発生状況を検知する際に、通信経路に存在する伝送装置（例えば、回線終端装置４２）から送信されるエラー率の通知を使用する通信レート制御方法。

（１２）通信レートを、エラー率にもとづいて算出された通信レートの最大値（例えば、実効帯域（Ｂ（１−ρ））に対応する通信レート）に適合させる通信レート制御方法。

以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

この出願は、２００９年３月６日に出願された日本特許出願２００９−５４００４を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１ 送信装置
２ 受信装置
３ａ，３ｂ 中継装置
４ 通信ネットワーク
５ 通信レート制御手段
６ 第１の通信エラー検知手段
７ 第２の通信エラー検知手段
１１，１２ 送信端末
２１，２２ 受信端末
３１，３２，３３，３４ スイッチ
４１，４２ 回線終端装置
５１，５２ ＴＣＰプロキシ
１１１ データ記憶部
１１２ アプリケーション
１１３ ＴＣＰ処理部
１１４ ＩＰ処理部
１１５ 入出力処理部
１１６ パケット記憶部
３１１〜３１３ 入出力処理部
３１４ パケット転送部
３１５ 輻輳判定部
３１６ パケット記憶部
４２１，４２２ 入出力処理部
４２３ パケット転送部
４２４ パケット記憶部
４２５ エラー訂正符号処理部
４２６ エラー判定部
１１３１ 輻輳ウィンドウ決定部
１１３２ データ送信部
１１３３ セグメント記憶部
１１３４ 輻輳通知受信部
１１３５ エラー通知受信部

Claims (6)

1. 通信ネットワークを介して受信装置にデータを送信する送信装置が通信レートを制御する通信レート制御方法であって、
   前記通信ネットワークにおける輻輳に起因してデータの消失が生ずることを、前記通信ネットワークの一の区間における中継装置のデータバッファの利用率にもとづいて検知し、
   前記通信ネットワークにおけるデータエラーに起因してデータの消失が生じたことを検知し、
   前記一の区間よりも前記受信装置の側の区間である他の区間におけるデータエラーの発生状況を検知し、
   輻輳に起因してデータの消失が生ずる場合とデータエラーに起因してデータの消失が生じた場合とで、別系統の通信レート制御を適用し、
   前記データバッファの利用率に応じて通信レートを変化させ、
   データエラーの発生状況に応じて通信レートを制御し、
   前記中継装置から送信される通信を一時停止させるためのリンク層のポーズ信号またはバックプレッシャ信号を輻輳通知として使用して、輻輳に起因してデータの消失が生ずることを検知し、
   データエラーの発生状況を検知する際に、ＴＣＰの確認応答信号によってパケットロスを検知した場合にデータエラーが発生しているとみなす
   ことを特徴とする通信レート制御方法。
2. データエラーに起因してデータの消失が生じたことを検知した場合に、直ちにデータを再送する
   請求項１記載の通信レート制御方法。
3. データエラーに起因してデータの消失が生じたことを検知した場合に、輻輳の程度に関わらずデータを再送する
   請求項１記載の通信レート制御方法。
4. 通信ネットワークを介して受信装置にデータを送信する送信装置であって、
   通信レートを制御する通信レート制御手段と、
   前記通信ネットワークにおける輻輳に起因してデータの消失が生ずることを、前記通信ネットワークの一の区間における中継装置のデータバッファの利用率にもとづいて検知する第１の通信エラー検知手段と、
   前記通信ネットワークにおけるデータエラーに起因してデータの消失が生じたことを検知するとともに、前記一の区間よりも前記受信装置の側の区間である他の区間におけるデータエラーの発生状況を検知する第２の通信エラー検知手段とを備え、
   前記通信レート制御手段は、
   データの消失が生ずることを前記第１の通信エラー検知手段が検知した場合と、データエラーに起因してデータの消失が生じたことを前記第２の通信エラー検知手段が場合とで、独立して通信レートを制御し、
   前記データバッファの利用率に応じて通信レートを変化させ、
   データエラーの発生状況に応じて通信レートを制御し、
   前記第１の通信エラー検知手段は、通信を一時停止させるためのリンク層のポーズ信号またはバックプレッシャ信号を輻輳通知として使用して、輻輳に起因してデータの消失が生ずることを検知し、
   前記第２の通信エラー検知手段は、データエラーの発生状況を検知する際に、ＴＣＰの確認応答信号によってパケットロスを検知した場合にデータエラーが発生しているとみなす
   ことを特徴とする送信装置。
5. データを中継する中継装置および通信ネットワークを介して送信装置が受信装置にデータを送信する通信システムであって、
   前記中継装置は、前記送信装置と伝送路との間に設けられ、データバッファの利用率にもとづいて前記通信ネットワークにおける輻輳に起因してデータの消失が生ずることを検出した場合に、前記送信装置にその旨を通知し、
   前記送信装置は、
   通信レートを制御する通信レート制御手段と、
   前記通信ネットワークにおける輻輳に起因してデータの消失が生ずることを前記中継装置からの通知によって検知する第１の通信エラー検知手段と、
   前記通信ネットワークにおけるデータエラーに起因してデータの消失が生じたことを検知するとともに、前記中継装置よりも前記受信装置の側の区間である他の区間におけるデータエラーの発生状況を検知する第２の通信エラー検知手段とを含み、
   前記通信レート制御手段は、
   データの消失が生ずることを前記第１の通信エラー検知手段が検知した場合と、データエラーに起因してデータの消失が生じたことを前記第２の通信エラー検知手段が場合とで、独立して通信レートを制御し、
   前記データバッファの利用率に応じて通信レートを変化させ、
   データエラーの発生状況に応じて通信レートを制御し、
   前記第１の通信エラー検知手段は、通信を一時停止させるためのリンク層のポーズ信号またはバックプレッシャ信号を輻輳通知として使用して、輻輳に起因してデータの消失が生ずることを検知し、
   前記第２の通信エラー検知手段は、データエラーの発生状況を検知する際に、ＴＣＰの確認応答信号によってパケットロスを検知した場合にデータエラーが発生しているとみなす
   ことを特徴とする通信システム。
6. 中継装置は、データバッファが満杯であるとき、または利用率が所定値を越えたときに送信装置に輻輳通知を行う
   請求項５記載の通信システム。

Images