JP5025655B2 - 流量制御方法、ならびにそれに使用する送信端末およびパケット転送システム - Google Patents

Description

本発明は、映像や音声といったデータのパケットによる配送を複数の端末に対して行う流量制御方法、ならびにそれに使用する送信端末およびパケット転送システムに関する。

ネットワークを介し、複数の端末に対してデータのパケットによる配送を行う場合、ネットワークの状況や受信端末の状況に応じて、送信するデータの流量を制御する必要がある。

特に、インターネットを介してデータの配送を行う場合、インターネット上の映像や音声以外の他のトラフィックと、帯域を公平に分け合うことが必要となる。インターネット上の他のトラフィックは、大半がＴＣＰ（Transport Control Protocol）を用いたトラフィックである。このことから、インターネット上で他のトラフィックと公平に帯域を分け合うには、ＴＣＰを用いたトラフィックと公平に帯域を分け合うように流量制御を行えばよいことが知られている。すなわち、インターネットを介してデータの配送を行う場合には、ＴＣＰとの親和性の良い流量制御を行えばよいということが知られている。

一方、複数の端末に対してデータの配送を行う場合に、それぞれの端末の能力がばらつくことが考えられる。具体的には、ＡＤＳＬ（Asymmetric Digital Subscriber Line）でインターネットに接続された端末は、数Ｍｂｐｓ（メガビット毎秒）の速度しか許容できないのに対し、光ファイバでインターネットに接続された端末は、１００Ｍｂｐｓの速度でデータを配送できる。これらのＡＤＳＬでインターネットに接続された端末と光ファイバでインターネットに接続された端末に対して同時にデータの配送を行う場合、最も遅い端末、つまりＡＤＳＬで接続された端末が、許容された速度以下でデータの配送を行うように流量制御を行う方式が知られている。具体的には、例えばＴＦＭＣＣ（TCP Friendly
Multicast Congestion Control）による流量制御の方式が知られている。

しかし、このような方式では、いろいろな速度の受信端末が存在した場合、高い能力の受信端末が十分なデータの配送を受けることができない。先の例で述べれば、光ファイバで接続された端末は、１００Ｍｂｐｓの受信能力があるにもかかわらず、数Ｍｂｐｓでしかデータの配送を受けることができない。このような状態は、同じセッション（データの配送）の中で不公平さを生じ、セッション内の不公平性と呼ばれている。従って、複数の端末にデータの配送を行う流量制御方式は、すべての受信端末がそれぞれの最大の能力で受信できている状態を実現できること、つまりセッション内の公平性が保たれるようにしてセッション内の不公平性を改善できることが望まれている。

ＴＣＰとの親和性を保ちながらセッション内の不公平性を改善する流量制御方式として、ＳＩＣＣ（Sender Initiated Congestion Control）方式が知られている（例えば非特許文献１参照）。

また、データの送信可能なレートを推定する方式として、ＴＦＲＣ（TCP Friendly Rate Control）方式が知られている（例えば非特許文献２参照）。

ＳＩＣＣ方式は、ＸＣＡＳＴ（eXplicit Multicast）方式のような、送信端末が受信端末の宛先アドレスのリストを明示的に指定するタイプのマルチキャスト方式の通信におい
て、このＴＦＲＣ方式を利用した流量制御を実現する伝送方式である。

ここで、ＳＩＣＣ方式について具体的に説明する。

ＳＩＣＣ方式の送信端末は、異なるレートでパケットを送出する複数のクラスを持つ。送信端末は、受信端末への送信可能なレートをＴＦＲＣ方式に基づいて推定し、この推定値を用いて各受信端末を適切な上記複数のクラスに分類する。送信端末は、それぞれのクラスに分類された受信端末のアドレスを指定したＸＣＡＳＴパケットを配送する。

送信可能なレートの推定は、送信端末と受信端末間のパケットの往復時間であるラウンドトリップタイム（ＲＴＴ：Round Trip Time）の、受信端末からのフィードバックに基づいて行われる。この送信可能なレートの推定は、ＴＣＰとの親和性を満たす方式であるＴＦＲＣ方式に基づいて行われる。したがって、ＳＩＣＣ方式が行う流量制御は、ＴＣＰとの親和性を満たす。

このように、ＳＩＣＣ方式では、ＴＦＲＣ方式に基づいて送信可能なレートを推定し、それぞれの受信端末は、推定した送信可能なレートに基づいて適切なクラスに分類される。したがって、ＳＩＣＣ方式では、パケットの配送時、送信可能レートが最も遅い受信端末に律速されることはなく、ＴＣＰとの親和性を満たしながらセッション内の公平性を大幅に向上させることができる。

ところで、ＴＦＲＣ方式による送信可能なレート推定では、上記のようにＲＴＴの計測が不可欠である。ＴＦＲＣ方式では、以下の式（１）に基づき、送信可能レートＸｃａｌの推定を行う。

式（１）において、ＲはＲＴＴ、ｐは損失イベント率、ｓはパケットサイズ、ｔ＿ＲＴＯはＴＣＰが用いるタイムアウト値である。ｔ＿ＲＴＯは、一般的に４Ｒが用いられている。式（１）において、Ｒが分母であることから、送信可能レートＸｃａｌはＲＴＴに反比例し、ＲＴＴが大きくなれば送信可能レートＸｃａｌが小さくなることがわかる。

ＳＩＣＣ方式では、上記したように複数の端末に対してパケットを届ける方式として、例えば非特許文献３に開示されたＸＣＡＳＴ方式を利用する。

非特許文献３に開示されたＸＣＡＳＴ方式は、送信者が、所定のグループに属する全受信端末の宛先アドレスを、パケット内のオプションヘッダまたはペイロードに格納することによって、送信者側でパケットを配信する全受信端末を明示的に指定する方式である。このＸＣＡＳＴ方式では、送信ノードと受信ノードとの間に配置される中継ルータがＸＣＡＳＴ方式に対応していない場合、その中継ルータに配送されてきたパケットは宛先アドレスから判断されて、未配送の１台の受信端末に届けられる。これを受け取った受信端末は、パケット中にさらに未配送の相手先が残っている場合、パケットを未配送の相手先に対して送信し直す。受信端末がこのような中継動作を繰り返すことで、すべての受信端末にパケットが配送される。

すなわち、ＸＣＡＳＴ方式では、中継ルータがＸＣＡＳＴ方式に対応していない場合で
も、受信端末が数珠繋ぎ転送を行うことで、複数の受信端末にパケットの配送を行うことができる。
E. Muramoto, et al., "Proposal for Congestion Control Method on Sender Initiated Multicast," Internet Conference 2003 M. Handley, et al., "TCP Friendly Rate Control(TFRC): Protocol Specification", RFC 3448, Jan. 2003 Y. Imai, et al., "XCAST6: eXplicitMulticast on IPv6," IEEE/IPSJ SAINT2003 Workshop 4, IPv6 and Applications, Orland, Jan. 2003

しかしながら、ＸＣＡＳＴにＳＩＣＣ方式を適用し、レートを推定する方式としてＴＦＲＣ方式を用いた流量制御方法では、中継ルータがＸＣＡＳＴ方式に対応しておらずに数珠繋ぎ転送が行われた場合に、不必要に低いレートで流量制御を行うという問題があった。これは、数珠繋ぎ転送が行われる場合にはＲＴＴが大きくなるということに起因している。ここで、この問題について説明する。

図１は、従来のパケット転送システムの構成を示す構成図である。

図１に示すパケット配送システム１６００は、送信端末１６０１、受信端末１６０５〜１６０８、インターネット１６１２から構成されている。図１において、送信端末１６０１が有するＳＩＣＣ方式で分類されるクラスは、送信レートが１ＭｂｐｓのクラスＡ１６０２、送信レートが５１２ＫｂｐｓのクラスＢ１６０３、送信レートが２５６ＫｂｐｓのクラスＣ１６０４である。

送信端末１６０１は、クラスＡ１６０２、クラスＢ１６０３、クラスＣ１６０４を用いて、受信端末１６０５〜１６０８に対してインターネット１６１２を経由してＳＩＣＣ方式でパケット配送を行う。図１は、クラスＡ１６０２に１台の受信端末１６０５が、クラスＢ１６０３に３台の受信端末１６０６〜１６０８が、クラスＣ１６０４に０台の受信端末が、それぞれ属しており、ＸＣＡＳＴ方式を用いてパケットの配送が行われている様子を示している。送信経路１６１０は、送信端末１６０１からクラスＡ１６０２に対応する受信端末１６０５へのデータ配送経路である。送信経路１６１１は、送信端末１６０１からクラスＢ１６０３に対応する受信端末１６０６〜１６０８へのデータ配送経路である。このとき、送信端末１６０１と受信端末１６０８の間のＲＴＴを計測する際のＲＴＴ計測経路１６０９は、送信端末１６０１から受信端末１６０６、１６０７を経由して、受信端末１６０８に数珠繋ぎで到達する経路となり、この数珠繋ぎ経路のＲＴＴが送信端末１６０１にフィードバックされることになる。

すなわち、従来では、ＲＴＴ計測経路１６０９で示すように、データを含むパケットを数珠繋ぎで配送する場合であっても、全区間のＲＴＴを用いてＴＦＲＣ方式による流量制御を行っていた。

しかしながら、ＲＴＴ計測経路の区間中で他トラフィックとの競合状況が最も激しい区間（ボトルネック区間）においてＴＣＰとの親和性が保たれていれば、他の区間でもＴＣＰとの親和性が保たれると考えられる。にもかかわらず、従来の方法では、送信端末１６０１から受信端末１６０８までの全経路を計測しており、不必要に低いレートにて流量制御をしていたことになる。

すなわち、従来の技術ではＳＩＣＣ方式をＸＣＡＳＴ方式に適用した場合、数珠繋ぎ転送が行われることによって、ＲＴＴが大きく算出されてしまうため、送信可能なレートが
小さく算出され、結果としてデータ伝送の性能が劣化する問題があった。

本発明の目的は、数珠繋ぎ転送時であっても、ＲＴＴが大きく算出されることなく、パケット伝送の性能を大きく向上させることのできる流量制御方法を提供することである。

本発明の一態様に係る流量制御方法は、受信端末の中継によってパケットの配送を行う際の流量制御方法であって、前記配送の経路において隣接する端末の組ごとに、その組の端末間をパケットが往復する際の往復時間を取得するステップと、前記取得した往復時間の中から予め定められた基準に基づいていずれかを選択するステップと、前記選択した往復時間をもとにパケットの送信レートを算出するステップとを有する構成を有している。

本発明の一態様に係る受信端末は、送信端末から送られてきたパケットを他の受信端末へ中継する受信端末であって、前記他の受信端末との間をパケットが往復する際の往復時間を計測するための計測情報を含むパケットを、前記他の受信端末へ送信する計測パケット送信部と、前記他の受信端末から前記計測情報を含むパケットに対する返信のパケットを受信する受信部と、前記受信部で受信された前記返信のパケットを基にパケットの往復時間に関する時間情報を取得する往復時間情報取得部と、前記往復時間情報取得部で取得された前記時間情報を含むパケットを、前記送信端末へ送信する往復時間情報送信部とを有する構成を有している。

本発明の一態様に係る送信端末は、パケットを中継する受信端末を介してパケットの配送を行う送信端末であって、前記配送の経路において隣接する端末の組ごとに、その組の端末間をパケットが往復する際の往復時間に関する情報を含むパケットを受信する受信部と、前記受信部で受信されたパケットから前記往復時間を取得する往復時間取得部と、前記往復時間取得部で取得された往復時間の中から予め定められた基準に基づいていずれかを選択する選択部と、前記選択部で選択された往復時間を基にパケットの送信レートを算出する算出部とを有する構成を有している。

また、本発明の一態様に係るパケット転送システムは、送信端末から送られてきたパケットを受信端末の中継によって配送するパケット転送システムであって、前記受信端末は、前記送信端末から送られてきたパケットを中継すべき他の受信端末との間をパケットが往復する際の往復時間を計測するための計測情報を含むパケットを前記他の受信端末へ送信する計測パケット送信部と、前記他の受信端末から前記計測情報を含むパケットに対する返信のパケットを受信する受信端末受信部と、前記受信端末受信部で受信された前記返信のパケットを基に前記往復時間に関する時間情報を取得する往復時間情報取得部と、前記往復時間情報取得部で取得された前記時間情報を含むパケットを前記送信端末へ送信する往復時間情報送信部と、を有し、前記送信端末は、前記受信端末から前記時間情報を含むパケットを受信する送信端末受信部と、前記送信端末受信部で受信されたパケットから前記往復時間を取得する往復時間取得部と、前記往復時間取得部で取得された往復時間の中から予め定められた基準に基づいていずれかを選択する選択部と、前記選択部で選択された往復時間を基にパケットの送信レートを算出する算出部とを有する構成を備えている。

本発明によれば、数珠繋ぎ転送時であっても、ＲＴＴが大きく算出されることなく、パケット伝送の性能を大きく向上させることができる。

以下、本発明の実施の形態について、図面を参照しつつ説明する。

図２は、本発明の一実施の形態におけるパケット転送システムの構成図である。図２を用いて、本実施の形態におけるパケットの往復時間であるＲＴＴを計測する方法の概要を説明する。

ＲＴＴ計測経路のボトルネック区間においてＴＣＰとの親和性が保たれていれば、他の区間でもＴＣＰとの親和性が保たれると考えられる。従って、ＲＴＴ計測経路のボトルネック区間における送信可能レートＸｃａｌ（以下「Ｘｃａｌ−Ｎ」という）を算出することができれば、不必要に低いレートで流量制御を行うことを回避することができる。

上記した式（１）の説明から、Ｘｃａｌ−Ｎを算出するに当たって区間毎に変動するパラメータは、ＲＴＴのＲと、損失イベント率のｐである。損失イベント率ｐについて、パケットの損失は大部分がボトルネック区間で発生することから、全区間の損失イベント率ｐは、ボトルネック区間の損失イベント率ｐに近い可能性が高いと考えられる。一方、Ｒは各区間のＲＴＴの単純な加算であるので、数珠繋ぎが長くなるほどボトルネック区間のＲＴＴ（以下「ＲＴＴ−Ｎ」という）より不必要に大きくなることが予想される。

したがって、ボトルネック区間のＲＴＴ−Ｎを算出し、これをＲとしてＸｃａｌ−Ｎを算出すれば、損失イベント率ｐなど他のパラメータは数珠繋ぎ時と同じ計測値を流用しても、実用上、大きな効果が期待できると考えられる。そこで、本実施の形態では、ＲＴＴの計測を、中継する受信端末毎に終端して行うＲＴＴ計測方法（以下「ＲＴＴ分割計測」という）を採用する。

図２に示すパケット転送システム１００は、送信端末１０１と受信端末１０５〜１０８とインターネット１１５とから構成されている。

図２における送信端末１０１は、図１の従来技術で説明したのと同様に、ＳＩＣＣ方式のクラスである送信レートが１ＭｂｐｓのクラスＡ１０２と、送信レートが５１２ｋｂｐｓのクラスＢ１０３と、送信レートが２５６ｋｂｐｓクラスＣ１０４とを有している。受信端末１０５は、クラスＡ１０２に属し、受信端末１０６〜１０８はクラスＢ１０３に属
しており、クラスＣ１０４に属する受信端末はないものとする。

本実施の形態では、送信端末１０１が、クラスＢ１０３に属する受信端末１０６〜１０８にデータを配送する場合について説明する。送信端末１０１が、他のクラスに属する受信端末にデータを配信する場合も同様に実施できる。

ＲＴＴ計測経路１０９は、送信端末１０１と受信端末１０６の間のＲＴＴを計測する際の経路を示している。ＲＴＴ計測経路１１０は、受信端末１０６と受信端末１０７の間のＲＴＴを計測する際の経路を示している。ＲＴＴ計測経路１１１は、受信端末１０７と受信端末１０８の間のＲＴＴを計測する際の経路を示している。

データ配送経路１１２は、送信端末１０１から３つの受信端末１０６〜１０８宛に配送されたＸＣＡＳＴパケットが配送に際して、送信端末１０１に隣接する最初の受信端末１０６に到達するまでの経路である。データ配送経路１１３は、上記受信端末１０６に配送された３つの受信端末１０６〜１０８宛のＸＣＡＳＴパケットが、受信端末１０６に数珠繋ぎ的に隣接する受信端末１０７に配送されるときの経路である。同様にデータ配送経路１１４は、受信端末１０７に配送されたＸＣＡＳＴパケットが受信端末１０７に数珠繋ぎ的に隣接する受信端末１０８に配送されるときの経路である。すなわち、本実施の形態では、送信端末１０１、受信端末１０６〜１０８は、物理的に隣接しているのではなく、パケットの配送の経路において隣接している。具体的には、パケットの配送に際して、受信端末１０６は送信端末１０１に隣接し、受信端末１０７は受信端末１０６に隣接し、受信端末１０８は受信端末１０７に隣接している。

本実施の形態では、図２に示すように、ＳＩＣＣ方式をＸＣＡＳＴ方式に適用した場合の一例を説明しているが、ＲＴＴの計測を、パケットの配送を中継する個々の受信端末１０６〜１０７で終端していることが従来の構成とは異なる。すなわち、図２において、送信端末１０１は、クラスＢ１０３に属している受信端末１０６〜１０８に対して、それぞれのデータ配送経路１１２〜１１４に沿って、ＸＣＡＳＴ方式でパケットの配送を行っている。すなわち、送信端末１０１から配送されたパケットは、配送に際して隣接する受信端末１０６、１０７を経由して数珠繋ぎ的に中継されて受信端末１０８に配送される。本実施の形態によれば、このときＲＴＴの計測を、ＲＴＴ計測経路１０９〜１１１のそれぞれに沿って行っており、パケットの配送を中継する受信端末１０６と受信端末１０７で終端させている。

返信経路２０１は、タイムスタンプなどのＲＴＴを計測するためのＲＴＴ計測情報を、受信端末１０７から受信端末１０６へ返信する経路である。返信経路２０２は、同様にＲＴＴ計測情報を受信端末１０８から受信端末１０７へ返信する経路である。報告経路２０３は、受信端末１０６と受信端末１０７との間を計測したＲＴＴなどのＲＴＴに関するＲＴＴ情報を、受信端末１０６から送信端末１０１へ報告する経路である。報告経路２０４は、同様に、受信端末１０７と受信端末１０８との間を計測したＲＴＴ情報を、受信端末１０７から送信端末１０１へ報告する経路である。

そして、報告経路２０３、２０４に沿って送られた、計測されたＲＴＴのうち最大のものを、送信可能なレート推定に用いるＲＴＴとして、送信端末１０１が選択して採用する。

このように、本実施の形態は、ＲＴＴ分割計測を採用する。以下、ＲＴＴ分割計測について説明する。

最初に、本実施の形態における受信端末と送信端末間のＲＴＴ分割計測のシーケンスを
説明する。

図３は、本実施の形態におけるＲＴＴ分割計測処理のシーケンスを示す図である。

まず、送信端末１０１は、配信するデータと、配信先のリスト（本実施の形態では受信端末１０６〜１０８）を含んだヘッダを有する多地点向けパケット（以下「ＸＣＡＳＴパケット」という）を生成する（Ｓ５０１）。ＸＣＡＳＴパケットには、後述するように、２つの方式があり、本実施の形態では、それぞれの方式のＸＣＡＳＴパケットを、「ＸＣＡＳＴパケットＡ」，「ＸＣＡＳＴパケットＢ」という。このステップＳ５０１では、ＸＣＡＳＴパケットＡを生成する。

送信端末１０１は、ＸＣＡＳＴパケットＡを生成後、受信端末１０６〜１０８を配信先とするＸＣＡＳＴパケットＡを、図２のデータ配送経路１１２を介して受信端末１０６に配送する（Ｓ５０２）。

ここで、送信端末１０１で生成されるＸＣＡＳＴパケットＡの構造を説明する。

図４は、本実施の形態におけるＸＣＡＳＴパケットＡの構成を示す図である。

図４に示すように、ＸＣＡＳＴパケットＡ１００５は、ＩＰヘッダ１００１、ＸＣＡＳＴヘッダ１００２、ＳＩＣＣ−ＤＡＴＡヘッダ１００３、および配信データ１００４から構成されている。

ここで、ＩＰヘッダ１００１は、例えばＲＦＣ２４６０で規定されるＩＰｖ６のＩＰヘッダが格納される領域である。ＸＣＡＳＴヘッダ１００２は、インターネット草案「ｄｒａｆｔ‐ｏｏｍｓ‐ｘｃａｓｔ‐ｂａｓｉｃ‐ｓｐｅｃ‐０９．ｔｘｔ」で規定されるＸＣＡＳＴのヘッダが格納される領域である。本実施の形態において、ＸＣＡＳＴヘッダ１００２には、受信端末１０６〜１０８のそれぞれのＩＰアドレスが図４の宛先リスト１００６のように格納される。ＳＩＣＣ−ＤＡＴＡヘッダ１００３は、ＳＩＣＣ方式でデータの配送を行う場合に必要と規定された項目が格納される領域である。例えば、ＳＩＣＣ−ＤＡＴＡヘッダ１００３には、データの形式を表すデータタイプやＲＴＴ分割計測要求の有無や送信時刻などが格納される。配信データ１００４は、送信端末１０１に蓄積されていた配信データが格納される領域である。

次に、受信端末１０６は、ＸＣＡＳＴパケットＡを受信すると、ＲＴＴ分割計測の前処理として分割計測ＲＴＴ用時刻設定処理を行う（図３のステップＳ５０３）。すなわち、ステップＳ５０３において、受信端末１０６は、まず、ＸＣＡＳＴパケットＡ１００５の宛先リスト１００６から、自分が中継すべき次の転送先である受信端末１０７の識別子を取得する。さらに、受信端末１０６は、ＸＣＡＳＴパケットＡ１００５のＳＩＣＣ−ＤＡＴＡヘッダ１００３の所定領域に設定された値から、送信端末１０１へ分割計測の報告を行う必要があるかの指示を取得する。例えば、後述するように、ＸＣＡＳＴパケットＡ１００５のＳＩＣＣ−ＤＡＴＡヘッダ１００３は、分割計測の報告を行う必要があるかの指示を示す報告要求フラグを有している。そして、例えば、この報告要求フラグにビットが立っていれば、受信端末１０６は、分割計測をしてその結果を送信端末１０１に報告する必要があると判断する。分割計測の必要があるとの指示を取得した場合、受信端末１０６は、受信端末１０６自身のＩＰアドレスとＸＣＡＳＴパケットＡを受信した現在時刻の中継タイムスタンプとを、ＸＣＡＳＴパケットＡ１００５に追記して、ＸＣＡＳＴパケットＢを生成する。

図５は、本実施の形態におけるＸＣＡＳＴパケットＢの構成を示したものであり、ＸＣ
ＡＳＴパケットＡ１００５と並べて示している。ＸＣＡＳＴパケットＡ１００５の構成は図４と同じであるので説明は省略する。

図５において、ＸＣＡＳＴパケットＢ１１０４は、上述のようにＸＣＡＳＴパケットＡ１００５にＲＴＴ用時刻設定処理を行ったもので、ＸＣＡＳＴパケットＡ１００５のＳＩＣＣ−ＤＡＴＡヘッダ１００３がＳＩＣＣ−ＤＡＴＡ−Ｒヘッダ１１０１に変更された構成となっている。ここで、ＳＩＣＣ−ＤＡＴＡ−Ｒヘッダ１１０１は、ＳＩＣＣ−ＤＡＴＡヘッダ１００３に格納されたデータに加えて、中継ＩＰアドレス１１０２および中継タイムスタンプ１１０３を追記したものである。

次に、受信端末１０６は、受信端末１０７に対して、上記生成したＸＣＡＳＴパケットＢを、図２に示すデータ配送経路１１３を介して転送する（図３のステップＳ５０４）。

次に、受信端末１０６は、送信端末１０１が受信端末１０６との間のＲＴＴを取得するために利用されるレシーブレポート（Receive Report）パケット（以下「ＲＲパケット」という）を送信端末１０１へ送信する（Ｓ５０５）。ＲＲパケットには、後述するように、送信端末１０１がパケットを送信した時刻であるタイムスタンプの他に、受信端末１０６で計測された実績帯域、損失イベント率などが格納される。これにより、送信端末１０１は、ＲＲパケットを受信した時刻とタイムスタンプが表す時刻との差分から、送信端末１０１と受信端末１０６との間のＲＴＴを取得することができる。

次に、ＸＣＡＳＴパケットＢを受信した受信端末１０７は、報告要求パケットを生成するＲＴＴ情報報告要求処理を行う（図３のステップＳ５０６）。ここで生成される報告要求パケットは、受信端末１０６にＲＴＴを計測させてその計測結果を送信端末１０１に報告させるためのものである。報告要求パケットは、報告先を示す送信端末１０１のＩＰアドレスと、受信端末１０７が受信端末１０６から受信したＸＣＡＳＴパケットＢに含まれていた中継タイムスタンプを含む。

次に、受信端末１０７は、データの転送元である上流の受信端末１０６のＩＰアドレス宛てに、ステップＳ５０６で生成した報告要求パケットを送信する（Ｓ５０７）。

次に、受信端末１０６は、ＲＴＴを計測しその結果を送信端末１０１に報告するためのＲＴＴ情報報告処理を行う（Ｓ５０８）。すなわち、受信端末１０６は、下流の受信端末１０７から報告要求パケットを受信すると、受信した報告要求パケットに格納された中継タイムスタンプと自端末の現在の時刻との差分から、受信端末１０６と受信端末１０７の往復時間であるＲＴＴを計測する。そして、受信端末１０６は、このようにして計測したＲＴＴを、その構造を後述する報告パケットに格納する。

次に、受信端末１０６は、計測したＲＴＴなどのＲＴＴ情報を格納した報告パケットを送信端末１０１に対して送信する（Ｓ５０９）。

このようにして、送信端末１０１は、報告パケットを受信端末１０６から受信することにより、ＸＣＡＳＴパケットの配送経路を分割した、受信端末１０６と受信端末１０７の間のデータ配送経路１１３のＲＴＴを取得することができる。

次に、ステップＳ５０６でＲＴＴ情報報告要求処理を行った受信端末１０７は、ＸＣＡＳＴパケットＢに対して、受信端末１０６の場合のステップＳ５０３と同様に、ＲＴＴ用時刻設定処理を行う（Ｓ５１０）。そして、受信端末１０７は、次のデータ転送先の受信端末１０８に内容を書き換えたＸＣＡＳＴパケットＢを転送する（Ｓ５１１）。

また、受信端末１０７は、受信端末１０６によるステップＳ５０５の処理と同様に、ＲＲパケットを送信端末１０１へ送信する（Ｓ５１３）。

次に、受信端末１０７からのＸＣＡＳＴパケットＢを受信した受信端末１０８は、受信端末１０７によるステップＳ５０６の処理と同様に、ＲＴＴ情報報告要求処理を行う（Ｓ５１２）。すなわち、受信端末１０８は、受信端末１０７と同様に、送信端末１０１のＩＰアドレスと、受信端末１０８が受信端末１０７より受信したＸＣＡＳＴパケットＢの中継タイムスタンプとを報告要求パケットに格納する。

その後、受信端末１０８は、受信端末１０７に対して、報告要求パケットを送信する（Ｓ５１５）。

報告要求パケットを受信した受信端末１０７は、受信端末１０６によるステップＳ５０８の処理と同様に、受信端末１０７と受信端末１０８の間のデータ配送経路１１４のＲＴＴを算出してＲＴＴ情報報告処理を行う（Ｓ５１６）。そして、受信端末１０７は、報告パケットにＲＴＴ計測結果を格納して送信端末１０１に送信する（Ｓ５１７）。

また、受信端末１０８も、ステップＳ５１２でＲＴＴ計測情報報告要求処理を行った後、後述するＲＲパケットを送信端末１０１に送信する（Ｓ５１４）。

このようにして、送信端末１０１は、報告パケットを受信端末１０７、および受信端末１０８から受信することにより、ＸＣＡＳＴパケットの配送経路を分割した、受信端末１０７と受信端末１０８の間のデータ配送経路１１４のＲＴＴを取得することができる。

以上のようにして、送信端末１０１は、受信端末１０６、１０７の各々から報告パケットを受信する。これにより、送信端末１０１は、送信端末１０１と受信端末１０６との間のデータ配送経路１１２のＲＴＴ、受信端末１０６と受信端末１０７の間のデータ配送経路１１３のＲＴＴ、および受信端末１０７と受信端末１０８との間のデータ配送経路１１４のＲＴＴを得ることができる。送信端末１０１は、このようにして得られた複数のＲＴＴのうちの最大のＲＴＴを、送信可能なレート推定を行う場合に採用するＲＴＴの値として推定する処理を行う（Ｓ５１８）。

送信端末１０１は、上記ステップＳ５１８で推定したＲＴＴと、受信端末１０６〜１０８毎に計測したＲＲパケットに含まれる実績帯域および損失イベント率にそれぞれ格納された値とを用いて、ＴＦＲＣ方式に基づき送信レートを算出し、流量制御を行う。

すなわち、本実施の形態によれば、ＴＦＲＣ方式に基づき送信レートを算出するに際し、式（１）におけるＲとして、従来の方式により計測したＲＴＴを分割し、分割したＲＴＴのうち最大のものを採用している。したがって、本実施の形態によるＲは従来の方式のものより小さくなり、その結果、送信可能レートＸｃａｌは従来の値より大きくなり、
データ伝送の性能を大きく向上させることができる。

以上説明した、本実施の形態における、ＲＴＴ分割計測処理のシーケンスにおける送信端末１０１および受信端末１０６の詳細な構成および動作を、各端末間でやり取りされるＸＣＡＳＴパケットの具体的構造を用いて詳細に説明する。

まず、本実施の形態における送信端末１０１と受信端末１０６の構成について詳細に説明する。

図６は本実施の形態に係る送信端末１０１の構成を示す構成図である。

送信端末１０１は、配信データ蓄積部４０１、受信部４０２、制御部４０３、受信端末識別子情報作成部４０４、多地点向けパケット生成部４０５、往復時間情報取得部４０６、選択部４０７、算出部４０８、送信部４０９、受信端末クラス分類部４１０、およびクラス保持部４１１から構成されている。

配信データ蓄積部４０１は、受信端末１０６〜１０８へ配送する、映像コンテンツなどの配信データを蓄積する。受信部４０２は、受信端末１０６〜１０８からのＲＴＴ情報が格納された報告パケット、および後述するＲＲパケットを受信するとともに、例えば、ＩＰアドレスのような配信先情報やコンテンツ情報などを受信する。受信端末識別子情報作成部４０４は、配信データ蓄積部４０１に蓄積された配信データを配信する受信端末１０６〜１０８の識別子である配信先情報を作成する。この配信先情報は、例えば、受信端末１０６〜１０８のＩＰアドレスである。多地点向けパケット生成部４０５は、配信データ蓄積部４０１に蓄積された配信データに、受信端末識別子情報作成部４０４で作成された配信先情報を追加して、多地点へ配送する多地点向けパケットを生成する。

往復時間情報取得部４０６は、受信部４０２で受信された受信端末１０６〜１０８からのＲＴＴ情報が格納された報告パケットから、ＲＴＴをそれぞれ取得する。選択部４０７は、往復時間情報取得部４０６で取得されたＲＴＴの中から、予め定められた基準に基づいて所定のＲＴＴを選択する。予め定められた基準に関しては、例えば、本実施の形態では、選択部４０７は、得られた複数のＲＴＴのうちの最大のＲＴＴを選択する。しかし、これ以外に、２番目に大きいＲＴＴ、あるいは３番目に大きいＲＴＴを、これらを用いて式（１）のＸｃａｌを小さくするのに効果的であれば、選んでもよい。Ｘｃａｌを小さくするのに効果的か否かの判断は、例えば、式（１）を用いて算出されたＸｃａｌを、予め定めた値と比較することにより判断することができる。これにより、ネットワークの状況によりＲＴＴが一時的に極端な値に増大したような場合に、このＲＴＴを選択するのを防ぐことができる。または、複数のＲＴＴをいくつかにグループ分けして、最大グループに属するＲＴＴから任意の一つを採用するようにしてもよい。これらの条件は、その時々のデータ配送の状況に応じて変えることもできる。算出部４０８は、選択部４０７で選択されたＲＴＴを基に、各受信端末に対する送信レートを算出する。送信部４０９は、多地点向けパケット生成部４０５で生成された多地点向けパケットを最初の受信端末１０６へ送信する。

受信端末クラス分類部４１０は、算出部４０８が算出した各受信端末に対する送信レートを基に、各受信端末１０５〜１０８を適切な送信レートのクラス、本実施の形態ではクラスＡ１０２〜クラスＣ１０４、に分類する。クラス保持部４１１は、受信端末クラス分類部４１０に分類された結果を、各クラスＡ１０２〜クラスＣ１０４とそれぞれに属する受信端末１０５〜１０８とを対応付けて記憶する。本実施の形態では、受信端末クラス分類部４１０でクラスの分類が行われ、クラス保持部４１１で各クラスＡ１０２〜Ｃ１０４と受信端末１０５〜１０８の対応関係が記憶された後の動作を説明している。

また、受信端末識別子情報作成部４０４は、クラス保持部４１１に記録された受信端末のクラス分類に基づき、配信先情報を作成して、多地点向けパケット生成部４０５へ渡す。送信部４０９は、受信端末識別子情報作成部４０４で作成された配信先情報に基づいて、多地点向けパケット生成部４０５が生成した多地点向けパケットを送信する。なお、制御部４０３は、データの配送や報告パケットの受信などを契機として、以上に説明した各部の動作を制御する。

図７は、本実施の形態に係る受信端末の構成を示す構成図である。

受信端末１０６は、受信部３０１、制御部３０２、受信端末識別子情報取得部３０３、多地点向けパケット生成部３０４、計測パケット送信部３０５、往復時間情報取得部３０６、および往復時間情報送信部３０７から構成されている。

受信部３０１は、送信端末１０１または次の転送先である受信端末１０７からの報告要求パケットを受信する。受信端末識別子情報取得部３０３は、受信部３０１で受信されたＸＣＡＳＴパケットから次に転送すべき受信端末の識別子を取得する。ここでは、受信端末識別子情報取得部３０３は、受信端末の識別子として、その受信端末のＩＰアドレスを取得するものとする。多地点向けパケット生成部３０４は、受信部３０１で受信されたＸＣＡＳＴパケットに対し、そのパケットを次に転送すべき受信端末１０７へ中継するための処理を行う。具体的には、多地点向けパケット生成部３０４は、ＸＣＡＳＴパケットのヘッダに対して、自アドレスについては配信済みであることを記録するなどの、必要な処理を行う。計測パケット送信部３０５は、多地点向けパケット生成部３０４で必要な処理が行われたＸＣＡＳＴパケットに対して、次に転送すべき受信端末１０７との間のＲＴＴを計測するために必要なＲＴＴ計測情報を追加して、受信端末１０７に送信する。往復時間情報取得部３０６は、計測パケット送信部３０５から送信した、ＲＴＴを計測するために必要なＲＴＴ計測情報を追加したパケットに対する返信を、受信端末１０７から受信部３０１で受けて、ＲＴＴ情報を算出する。ＲＲＴ情報は、例えば、受信端末１０７との間のＲＴＴを含む。往復時間情報送信部３０７は、往復時間情報取得部３０６で算出されたＲＴＴ情報を格納したパケットを、報告パケットとして送信端末１０１へ送信する。制御部３０２は、送信端末１０１などからのパケットの受信等を契機として、以上に説明した各部の動作を制御する。なお、本実施の形態における受信端末１０５、受信端末１０７、受信端末１０８は、受信端末１０６と同じ構成を有している。

以下に、図３に示す本実施のシーケンス図の要部の処理について、図６および図７を参照しつつ、図８〜１６を用いて詳細に説明する。

図８は、図３に示すシーケンス図の送信端末１０１のＸＣＡＳＴパケット生成処理（Ｓ５０１）の詳細を示すフローチャートである。なお、ここでは、説明の簡便化のため、図３のステップＳ５０２をＸＣＡＳＴパケット生成処理に含めて取り扱うものとする。

送信端末１０１は、配信するデータを配信データ蓄積部４０１から制御部４０３を介して取得する（Ｓ２０１）。制御部４０３には、あらかじめ、この配信するデータの取得を要望する受信端末のＩＰアドレスなどが登録されている。例えば、配信データ蓄積部４０１にＩＰテレビのコンテンツ情報が蓄積されている場合、制御部４０３は、ＩＰ番組表を提供するＷｅｂサーバなどから、配信を要望する受信端末のＩＰアドレスを入手して登録することができる。

次に、受信端末識別子情報作成部４０４は、データを配信する宛先のリスト（配信先リスト）を作成する（Ｓ２０２）。例えば、受信端末識別子情報作成部４０４は、上記登録された受信端末のＩＰアドレスを用いて宛先リストを作成する。本実施の形態では、受信端末識別子情報作成部４０４は、受信端末１０６〜１０８のＩＰアドレスを記述した宛先リストを作成する。次に、多地点向けパケット生成部４０５は、配信データ蓄積部４０１に蓄積された配信データに、受信端末識別子情報作成部４０４で生成された配信先情報を追加して、図４に示す構造の配信パケットであるＸＣＡＳＴパケットＡ１００５を作成する（Ｓ２０３）。

次に、送信部４０９は、多地点向けパケット生成部４０５で作成されたＸＣＡＳＴパケットＡ１００５を、図２のデータ配送経路１１２に沿って配送する（Ｓ２０４）。

次に、図３のＲＴＴ用時刻設定処理（Ｓ５０３）について説明する。

なお、ＲＴＴ用時刻設定処理は、受信端末１０７においても図３のステップＳ５１０で行われている。ステップＳ５０３の処理とステップＳ５１０の処理との違いは、扱うＸＣＡＳＴパケットがＸＣＡＳＴパケットＡ１００５かＸＣＡＳＴパケットＢ１１０４かの違いであるため、ここでは両処理を併せて説明する。

図９は、ＲＴＴ用時刻追記処理の流れを示すフローチャートである。なお、ここでは、説明の簡便化のため、図３のステップＳ５０４、Ｓ５０５、Ｓ５１１、Ｓ５１３をＲＴＴ用時刻追記処理に含めて取り扱うものとする。

受信部３０１は、受信端末１０６の場合には送信端末１０１からＸＣＡＳＴパケットＡ１００５を受信し、受信端末１０７の場合には受信端末１０６からＸＣＡＳＴパケットＢ１１０４を受信する（Ｓ６０１）。次に、受信端末識別子情報取得部３０３は、受信端末１０６の場合には受信したＸＣＡＳＴパケットＡ１００５のＸＣＡＳＴヘッダ１００２の宛先リスト１００６から、受信端末１０７の場合にはＸＣＡＳＴパケットＢ１１０４のＸＣＡＳＴヘッダ１００２の宛先リスト１００６から、自分が中継すべき次の転送先の受信端末識別子を取得する（Ｓ６０２）。本実施の形態では、受信端末１０６の場合は受信端末１０７のＩＰアドレスが取得され、受信端末１０７の場合は受信端末１０８のＩＰアドレスが取得される。

次に、制御部３０２は、受信端末１０６の場合には受信したＸＣＡＳＴパケットＡ１００５に、受信端末１０７の場合にはＸＣＡＳＴパケットＢ１１０４に、図１０に示すＳＩＣＣ−ＤＡＴＡヘッダ１００３の報告要求フラグ１２１２のビットが立っているかどうかを判断する（Ｓ６０３）。報告要求フラグ１２１２は、先に説明した、分割計測の報告を行う必要があるかの指示を示すフラグであり、このフラグにビットが立っていれば、受信端末１０６、１０７は分割計測をして、その結果を送信端末１０１に報告する。本実施の形態では、報告要求フラグ１２１２に、図１０に示すようにビットが立っているものとする。ＳＩＣＣ−ＤＡＴＡヘッダ１００３の構成については、後に図１０を用いて説明する。

ステップＳ６０３で報告要求フラグ１２１２が立っていない場合（Ｓ６０３：ＮＯ）、多地点向けパケット生成部３０４は、受信端末１０６の場合にはＸＣＡＳＴパケットＡ１００５を、受信端末１０７の場合にはＸＣＡＳＴパケットＢ１１０４を、ＸＣＡＳＴ方式に従って書き換える。これにより、多地点向けパケット生成部３０４は、受信端末１０６の場合には次の転送先の受信端末１０７に転送するパケットを生成し、受信端末１０７の場合には次の転送先の受信端末１０８に転送するためのパケットを生成して、数珠繋ぎ転送する（Ｓ６０４）。

ステップＳ６０３で報告要求フラグ１２１２が立っている場合（Ｓ６０３：ＹＥＳ）、配信状況のフィードバックを行うため、制御部３０２は、ＲＲパケットを送信端末１０１に返送する（Ｓ６０５）。ＲＲパケットの構造の詳細については後述する。

次に、多地点向けパケット生成部３０４は、受信したパケットがＸＣＡＳＴパケットＡ１００５かＸＣＡＳＴパケットＢ１１０４かを判断する（Ｓ６０６）。この判断は、図１０に示すＳＩＣＣ−ＤＡＴＡヘッダ１００３またはＳＩＣＣ−ＤＡＴＡ−Ｒヘッダ１１０１に格納されたパケット中のデータタイプ１２０６の領域で判断できる。本実施の形態では、多地点向けパケット生成部３０４は、データタイプ１２０６の値が“１”の場合はＸＣＡＳＴパケットＡ１００５と判断し、図１０に示すように“２”の場合はＸＣＡＳＴパケットＢ１１０４と判断する。図１０に示すＳＩＣＣ−ＤＡＴＡヘッダ１００３について
は後述する。

ステップＳ６０６での判断の結果がＸＣＡＳＴパケットＡ１００５の場合（Ｓ６０６:ＹＥＳ）、多地点向けパケット生成部３０４は、ＸＣＡＳＴパケットＡ１００５をＸＣＡＳＴパケットＢ１１０４の形式に加工する。すなわち、多地点向けパケット生成部３０４は、中継ＩＰアドレス１１０２と中継タイムスタンプ１１０３の領域を確保し、さらにデータタイプを示す領域１２０６をＸＣＡＳＴパケットＢ１１０４であることを示すタイプ、本実施の形態では“２”、に書き直し（Ｓ６０９）、次のステップＳ６０７に進む。

ステップＳ６０６で受信したパケットが、既にＸＣＡＳＴパケットＢ１１０４の場合（Ｓ６０６：ＮＯ）、多地点向けパケット生成部３０４は、ＸＣＡＳＴパケットＢ１１０４の形式に書き直す処理は行わず、次のステップＳ６０７に進む。

次に、計測パケット送信部３０５は、ＸＣＡＳＴパケットＢ１１０４形式のパケットに対して、中継ＩＰアドレス１１０２に自ら（受信端末）をインターネット上で特定する識別子を設定し、中継タイムスタンプ１１０３に現在時刻を設定する（Ｓ６０７）。ここでは、計測パケット送信部３０５は、自らのＩＰアドレスを、上記識別子としてＸＣＡＳＴパケットＢ１１０４形式のパケットに設定する。

最後に、計測パケット送信部３０５は、このように加工した後のＸＣＡＳＴパケットＢ１１０４を、ＸＣＡＳＴ方式にしたがって、計測パケット送信部３０５は次の転送先へ数珠繋ぎ転送する（Ｓ６０８）。すなわち、計測パケット送信部３０５は、受信端末１０６の場合には受信端末１０７へＸＣＡＳＴパケットＢ１１０４を転送し、受信端末１０７の場合には受信端末１０８へＸＣＡＳＴパケットＢ１１０４を転送する。

図１０は、上記加工された後のＸＣＡＳＴパケットＢ１１０４のＳＩＣＣ−ＤＡＴＡ−Ｒヘッダ１１０１の具体的な構成を示す図である。図１０を用いて、ＸＣＡＳＴパケットＡがＸＣＡＳＴパケットＢに加工される処理を具体的なデータ構成により詳述する。

ＳＩＣＣ−ＤＡＴＡ−Ｒヘッダ１１０１は、送信ポート番号１２０３〜パケット通番１２１８、中継ＩＰアドレス１１０２、および中継タイムスタンプ１１０３を有する。中継ＩＰアドレス１１０２および中継タイムスタンプ１１０３は、図９に示すステップＳ６０９でＸＣＡＳＴパケットＡ１００５に追記されたものである。このように、図４および図５に示すＸＣＡＳＴパケットＡ１００５のＳＩＣＣ−ＤＡＴＡヘッダ１００３は、図５および図１０に示すＳＩＣＣ−ＤＡＴＡ−Ｒヘッダ１１０１から中継ＩＰアドレス１１０２と中継タイムスタンプ１１０３とを除いたものである。

送信元ポート１２０３と宛先ポート１２０４は、アプリケーションに対してＳＩＣＣプロトコルのスタックがデータを引き渡す相手先のアプリケーションを決定するために用いられる領域である。また、バージョン番号１２０５は、ＳＩＣＣプロトコルの版数を示すバージョン番号である。データタイプ１２０６は、ＳＩＣＣプロトコル中のパケット形式を規定するデータタイプを示す領域である。例えば、このデータタイプ１２０６に“１”が記述されているＸＣＡＳＴパケットＢ１１０４をＳＩＣＣプロトコルでデータの配送を行うものとして規定することができる。この場合、先に説明したように、データタイプ１２０６が“１”のものをＸＣＡＳＴパケットＡと判断することができる。他方、図１０に示すように、データタイプ１２０６が“２”のものをＸＣＡＳＴパケットＢと判断することができる。また、ヘッダ長１２０７は、ＳＩＣＣ−ＤＡＴＡヘッダ１００３の長さを格納する。シーケンス番号１２０８は、送信したパケットの通し番号を格納する。タイムスタンプ１２０９は、送信端末１０１が配信データを送信した時刻を格納する。最大ＲＴＴ１２１０は、送信端末と受信端末間のＲＴＴのうち最大のものが送信端末により設定され
る領域である。ただし、本実施の形態では、送信端末１０１は、最大ＲＴＴ１２１０の領域は利用しておらず、図３のステップＳ５１８で最大ＲＴＴを求め、ＲＴＴを推定しているに留めている。

また、ｃｌａｓｓ１２１１は、図２で説明した送信レート別のクラスを示す領域である。報告要求フラグ１２１２がＲＴＴの分割計測の報告要求の有無を示すフラグである。例えば、本実施の形態では、先に述べたように、報告要求フラグ１２１２のビットが立っていることは、分割計測の報告要求をしていることを示し、報告要求フラグ１２１２のビットが立っていないことは、分割計測の報告要求をしていないことを示す。最大ＲＴＴ１２１０、予備領域１２１３、トータルシーケンス１２１４、ＡＤＵ通番１２１５、パケット長１２１６、パケット数１２１７、パケット通番１２１８は、ＳＩＣＣ方式がデータの配送においてパケットを分割したり再構成したりする際に利用する領域である。パケット通番１２１８は、このように分割されたパケット内での通し番号として使用されるが、これらについての詳細な説明は省く。

送信ポート番号１２０３〜パケット通番１２１８のように、ＳＩＣＣ−ＤＡＴＡ−Ｒヘッダが構成されている場合に、どのようにＸＣＡＳＴパケットＡ１００５およびＸＣＡＳＴパケットＢ１１０４が生成されるか、ならびに受信端末１０６で数珠繋ぎ転送を行う場合にどのように書き換え処理が行われるかについて述べる。

本実施の形態のＸＣＡＳＴパケットＡ１００５は、例えば、データタイプ欄１２０６を“１”、ヘッダ長１２０７を“２８”（バイト）と設定する。ＸＣＡＳＴパケットＢ１１０４は、例えば、データタイプ欄１２０６を“０×１０”（１０進表記で１６）、ヘッダ長１２０７を“４８”（バイト）と設定する。ＸＣＡＳＴパケットＡ１００５とＸＣＡＳＴパケットＢ１１０４のヘッダ長の差分２０バイトは、中継ＩＰアドレス１１０２の長さを１６バイト、中継タイムスタンプ１１０３を４バイトとしてこれを加えたものである。なお、ＩＰｖ４で配送を行う場合は、中継ＩＰアドレス１１０２の長さは４バイトで記述可能である。この場合、例えば、データタイプ欄１２０６を“０×１１”（１０進表記で１７）、１２０７ヘッダ長を“３６”（バイト）と設定する。

したがって、受信端末１０６の多地点向けパケット生成部３０４は、ＸＣＡＳＴパケットＡ１００５のデータタイプ１２０６とヘッダ長１２０７を書き換えて、先に述べたように、中継ＩＰアドレス１１０２に受信端末１０６自身をインターネット上で特定する識別子としてのＩＰアドレスを設定し、中継タイムスタンプ１１０３に受信端末１０６の現在時刻を追記して、ＸＣＡＳＴパケットＢ１１０４に加工することができる。

ところで、図３で説明したように、ＸＣＡＳＴパケットＡ１００５を受信した受信端末１０６は、ＳＩＣＣ−ＤＡＴＡヘッダ１００３に報告要求フラグ１２１２が立っている場合、ステップＳ５０４で、タイムスタンプ１２０９の情報を含むＲＲパケットを直ちに送信端末１０１に送信する。このようにすることで、送信端末１０１は、送信端末１０１と受信端末１０６との間のＲＴＴを計測できる。

ここで、受信端末１０６から送信端末１０１へ送信するＲＲパケットについて説明する。

図１１は、本実施の形態におけるＲＲパケットの具体的な構成を示す図である。

図１１において、ＲＲパケット１３０１は、送信ポート番号１２０３〜バージョン１２０５、データタイプ１３０４〜損失イベント率１３１２を有する。送信ポート番号１２０３〜バージョン１２０５は、図１０に示すＸＣＡＳＴパケットＢと同様である。データタ
イプ１３０４は、パケットの形式を示す領域である。例えば、“７”をＲＲパケット形式とあらかじめ定義しておくことにより、受信端末１０５〜１０８や送信端末１０１は、データタイプ１３０４からＲＲパケット１０３１を識別することが可能となる。また、ヘッダ長１３０５には、ＲＲパケットの長さである“２８”（バイト）を設定する。送信元識別子１３０７には、自端末である受信端末１０６のＩＰアドレスを格納する。タイムスタンプ１３０８は、受信端末１０６がＸＣＡＳＴパケットＡ１００５に記載されているタイムスタンプ１２０９を転記する領域である。ここでタイムスタンプ１２０９は、送信端末１０１がパケットの送信時にその時の時刻を記録したものである。受信端末１０６が送信時刻を返送することで、送信端末１０１は、受信端末１０６と送信端末１０１との間のＲＴＴを計測することが可能となる。実績帯域１３１１は、受信端末で観測できた実績帯域を報告する領域であり、ＴＦＲＣ方式に基づき、送信端末１０１と受信端末の間の送信可能なレートを算出する場合に上限値を制限する形で利用される。損失イベント率１３１２は、ＴＦＲＣ方式で規定されている観測方式に基づき、受信端末で観測した損失イベント率を記載して報告するために使用される。ＲＲパケット１３０１は、上記各領域の他に、パケット通番１３０６、リプライシーケンス１３０９、予備領域１３１０を有する。

次に、図３に示すＲＴＴ情報報告要求処理（Ｓ５０６、Ｓ５１２）について、報告要求パケットの構成を用いて説明する。なお、ここでは、ステップＳ５０６を例にして説明する。また、説明の簡便化のため、図３のステップＳ５０７をＲＴＴ情報報告要求処理に含めて取り扱うものとする。

ＸＣＡＳＴパケットＢ１１０４を受信した受信端末１０７は、制御部３０２で報告要求パケットを生成して、ＲＴＴ情報報告要求処理を行う。受信端末１０７の制御部３０２で生成された報告要求パケットについて説明する。

図１２は、報告要求パケットの具体的な構成の例を示す図である。

図１２において、報告要求パケット１４０１は、送信ポート番号１２０３〜バージョン１２０５、データタイプ１４０４〜返送先ＩＰアドレス１４０９を有する。送信ポート番号１２０３〜バージョン１２０５は、図１０に示すＸＣＡＳＴパケットＢと同様である。データタイプ１４０４は、パケットの形式を示す領域である。例えば、“８”を報告要求パケット形式とあらかじめ定義しておくことで、受信端末１０５〜１０８や送信端末１０１は、データタイプ１４０４から報告要求パケット１４０１を識別することが可能となる。ヘッダ長１４０５には、報告要求パケットの長さである“３２”（バイト）を設定する。送信元識別子１４０７は、本パケットの送信元を特定するＩＰアドレスなどの情報を示す領域である。中継タイムスタンプ１４０８は、受信端末１０７がタイムスタンプを上流の受信端末１０６に返送するための領域である。この中継タイムスタンプ１４０８は、データ配送を受ける上流の受信端末１０６から受け取ったＸＣＡＳＴパケットＢ１１０４の中継タイムスタンプ１１０３であり、例えば、受信端末１０６のタイムスタンプ（Ｓ５０６の場合）や受信端末１０７のタイムスタンプ（Ｓ５１２の場合）が転記される。送信先１４０９は、報告を送信する宛先を格納する領域であり、送信端末１０１を特定する識別子としてのＩＰアドレスが記載される。報告要求パケット１４０１は、上記各領域の他に、パケット通番１４０６を有する。

受信端末１０７は、報告要求パケット１４０１の送信先１４０９に、報告先を示す送信端末１０１のＩＰアドレスを格納する。また、受信端末１０７は、中継タイムスタンプ１４０８に、受信端末１０７が受信端末１０６より受信したＸＣＡＳＴパケットＢ１１０４の中継タイムスタンプ１１０３の値を転記して格納する。

その後、受信端末１０７は、図３のステップＳ５０７に示すように、上流の受信端末１
０６のＩＰアドレス宛てに、報告要求パケット１４０１を返信する。報告要求パケット１４０１を受信した受信端末１０６は、タイムスタンプ１４０８に記載された情報と現在時刻でＲＴＴを計算し、送信先識別子１４０９に記載された宛先、つまり送信端末１０１にその計算したＲＴＴを報告パケットとして報告する。

次に、図３のＲＴＴ情報報告処理（Ｓ５０８、Ｓ５１６）について説明する。なお、ここでは、ステップＳ５０８を例にして説明する。また、説明の簡便化のため、図３のステップＳ５０９をＲＴＴ情報報告処理に含めて取り扱うものとする。

図１３は、ＲＴＴ情報報告処理の流れを示すフローチャートである。

受信端末１０６は、ＸＣＡＳＴパケットＢ１１０４をデータ転送すべき下流の受信端末１０７へ転送した（図３のステップＳ５０４）後は、受信部３０１で、返信である報告要求パケット１４０１を待ち受ける（Ｓ７０１）。

受信端末１０６では、受信部３０１が報告要求パケット１４０１を受信した場合（Ｓ７０２：ＹＥＳ）、制御部３０２は、受信部３０１で受信された報告要求パケット１４０１を往復時間情報取得部３０６に渡す。往復時間情報取得部３０６は、報告要求パケット１４０１の中継タイムスタンプ１４０８に格納された情報を取得し、また、自端末の現在の時刻を参照することで、その差分から受信端末１０６と受信端末１０７との往復時間であるＲＴＴを計測する（Ｓ７０３）。

最後に、受信端末１０６は、上記のようにして計測したＲＴＴを、送信端末１０１に対し、報告パケットに格納して送信する（Ｓ７０４）。

ここで、報告パケットについて説明する。

図１４は、報告パケットの具体的な構成を示す図である。

図１４において、報告パケット１５０１は、送信ポート番号１２０３〜バージョン１２０５、データタイプ１５０４〜計測先１５０９を有する。送信ポート番号１２０３〜バージョン１２０５は、図１０に示すＸＣＡＳＴパケットＢと同様である。データタイプ１５０４は、パケットの形式を示す領域である。例えば、“９”を報告パケット形式とあらかじめ定義しておくことで、受信端末１０５〜１０８や送信端末１０１は、データタイプ１５０４から報告パケット１５０１を識別することが可能となる。また、ヘッダ長１５０５は、報告パケットの長さである“３２”（バイト）を設定する。送信元識別子１５０７は、送信元を特定するＩＰアドレスなどの識別子を示す領域である。計測ＲＴＴ１５０８は、計測したＲＴＴを格納する領域である。この計測ＲＴＴ１５０８には、例えば、受信端末１０６と受信端末１０７の間のＲＴＴや、受信端末１０７と受信端末１０８の間のＲＴＴが記載される。また、計測先１５０９は、計測相手先を特定するためのＩＰアドレスなどの識別子を格納する領域である。この計測先１５０９には、例えば、受信端末１０７や受信端末１０８のＩＰアドレスなどの識別子が格納される。すなわち、計測先１５０９には、計測ＲＴＴ１５０８のＲＴＴを計測した受信端末を特定することができるＩＰアドレスなどの識別子が格納される。報告要求パケット１４０１は、上記各領域の他に、パケット通番１５０６を有する。

以上により、この報告パケット１５０１を受信した送信端末１０１は、ＸＣＡＳＴパケットの配送経路上を分割したデータ配送経路の一部のＲＴＴを取得することができる。

次に、図３に示す送信端末１０１が行うＲＴＴ推定処理（Ｓ５１８）について説明する
。

図１５は、ＲＴＴ推定処理の流れを示すフローチャートである。

送信端末１０１は、前述したようにして得られた複数のＲＴＴから最大のＲＴＴを選択し、そのＲＴＴを用いてＴＦＲＣ方式の送信レートを計算可能な値としてＲＴＴ推定処理を行う。送信端末１０１の受信部４０２は、複数の受信端末１０６〜１０８のうち一部の受信端末からの報告パケットが返送されなかった場合に備えて、タイマーでタイムアウト値を設定する（Ｓ８０１）。このタイムアウト値は、例えば、送信端末１０１から、すべての受信端末１０６〜１０８を経由して最後の受信端末まで到達する場合のＲＴＴより大きい値を採用する。

次に、受信部４０２は、受信端末１０６、１０７からの報告パケットを待ち受ける（Ｓ８０２）。受信部４０２が、ＲＴＴ推定に必要な全ての受信端末１０６，１０７から報告パケットを受け取った場合は（Ｓ８０３：ＹＥＳ）、往復時間情報取得部４０６は、ＲＴＴ計測経路１１０、１１１のＲＴＴを各報告パケット１５０１の計測ＲＴＴ１５０８より取得する。ＲＴＴ計測経路１０９については、受信端末１０６からのＲＲパケットに基いて算出されたＲＴＴとして取得される。選択部４０７は、これらのＲＴＴ計測経路１０９〜１１１のＲＴＴの中から最大のＲＴＴを選択し、これをＴＦＲＣ方式で計算する際に用いるＲＴＴ（これを、Ｒとする）として採用する（Ｓ８０５）。

このとき、算出部４０８は、分割計測したＲＴＴのうち、各受信端末１０５〜１０８の上流のＲＴＴから最大のものを選択して算出する。例えば、本実施の形態では、図２のＲＴＴ計測経路１０９〜１１１を用いて説明すると、算出部４０８は、受信端末１０６の送信レートは、ＲＴＴ計測経路１０９のＲＴＴ、受信端末１０７の送信レートは、ＲＴＴ計測経路１０９、１１０のうち大きい方のＲＴＴ、受信端末１０８の送信レートは、ＲＴＴ計測経路１０９、１１０、１１１から最大のＲＴＴを用いて送信レートを算出する。

次に、受信部４０２にＲＲパケット１３０１を送信していない受信端末が存在する場合（Ｓ８０６：ＮＯ）、受信部４０２は、該当する受信端末のＲＲパケットを待ち受ける（Ｓ８０７）。

受信部４０２が全ての受信端末１０５〜１０８からＲＲパケット１３０１を受信した場合（Ｓ８０６：ＹＥＳ）、算出部４０８は、選択部４０７で取得したＲと、ＲＲパケット１３０１の実績帯域１３１１および損失イベント率１３１２に格納された内容とを用いて、ＴＦＲＣ方式に基づき送信レートを算出する（Ｓ８０８）。

一方、ステップＳ８０３において、受信部４０２に報告パケット１５０１を送信していない受信端末が存在する場合（Ｓ８０３：ＮＯ）、制御部４０３は、タイムアウトが発生しているかを判断し、発生していない場合は報告パケット待ちに戻る（Ｓ８０４：ＮＯ）。

制御部４０３は、タイムアウトが発生している場合（Ｓ８０４：ＹＥＳ）、報告パケットタイムアウト発生時の処理に移る。すなわち、タイムアウトが発生した場合、受信部４０２がすべての受信端末１０５〜１０８の報告パケット１５０１が受信できなかったことを意味するので、選択部４０７は、通常通り、数珠繋ぎ経路で計測したＲＴＴを採用する。

図１６は、報告パケットタイムアウト発生時の処理を示すフローチャートである。

制御部４０３は、受信端末からのＲＲパケット１３０１が到着しているかを判断し（Ｓ９０１）、到着していないと判断した場合（Ｓ９０１：ＮＯ）、ＲＲパケットの到着を待つ（Ｓ９０２）。制御部４０３がＲＲパケット１３０１が到着していると判断した場合（９０１：ＹＥＳ）、往復時間情報取得部４０６は、ＲＲパケット１３０１のタイムスタンプ１３０８に格納されているタイムスタンプと、ＲＲパケット受信時の送信端末１０１の現在時刻とから、ＲＴＴを計算する（Ｓ９０３）。このＲＴＴは、ＸＣＡＳＴパケットが各受信端末で終端されることなく複数の受信端末を数珠繋ぎ転送された場合のＲＴＴとなる。選択部４０７は、このＲＴＴをＲとし（Ｓ９０４）、ＴＦＲＣ方式で送信レートを算出する場合のＲＴＴとして算出部４０８に渡す。算出部４０８は、ＲＲパケット１３０１に記載された実績帯域１３１１、損失イベント率１３１２を用いて、ＴＦＲＣ方式で送信レートを算出する（Ｓ９０５）。すなわち、タイムアウトが発生した場合は、送信端末１０１は、ＲＴＴ分割計測を行わず、通常のＳＩＣＣ方式で規定されている動作を行う。

以上説明したように、タイムアウトが発生しない場合においては、受信端末１０８の送信可能なレート推定に適用するＲＴＴは、送信端末１０１から受信端末１０６および受信端末１０７を経由して受信端末１０８に到達する経路で計測されたＲＴＴよりも小さくなるので、結果として算出される送信可能なレートは大きくなる。すなわち、データの伝送の性能が不必要に劣化する問題がなくなる。

次に送信レートを算出した後の送信端末１０１の動作を、図６に示す送信端末１０１の構成図を用いて説明する。

受信端末クラス分類部４１０は、算出部４０８が算出した各受信端末１０５〜１０８の送信レートを基に、各受信端末１０５〜１０８を適切な送信レートのクラスに割り当てる。クラス保持部４１１は、上記受信端末クラス分類部４１０で分類した結果であるアドレスと分類されたクラスの対応を記憶する。受信端末識別子情報作成部４０４は、クラス保持部４１１に記録された受信端末のクラス分類が更新されていれば、配信先情報を再度作成して、多地点向けパケット生成部４０５へ渡す。送信部４０９は、多地点向けパケット生成部４０５で作成されたパケットを、最初の受信端末に向けて送信する。

ここで、具体的な数値の例をもって本実施の形態における送信レートの算出の例を説明する。

送信端末１０１から受信端末１０６および受信端末１０７を経由して受信端末１０８に到達する経路で計測されたＲＴＴが５０ｍｓ（マイクロ秒）、送信端末１０１から受信端末１０６の間のＲＴＴが１０ｍｓ、受信端末１０６と受信端末１０７の間のＲＴＴが１５ｍｓ、受信端末１０７と受信端末１０８の間のＲＴＴが１５ｍｓであったとする。このとき、送信端末１０１から受信端末１０６および受信端末１０７を経由して受信端末１０８に到達する経路で計測されたＲＴＴである５０ｍｓは、従来方式による計測結果である。したがって、従来方式では、式（１）における分母のＲが５０ｍｓとなり、他のｐ、ｓ、ｔ＿ＲＴＯは固定の値であるから、（１／５０）×５０と算出されるので、送信可能レートＸｃａｌ＝１Ｍｐｓとなる。

一方、本実施の形態では、上記の計測結果である１０ｍｓと１５ｍｓのうちの最大の方である１５ｍｓを、式（１）における分母のＲとして採用する。その算出の結果、ｐ、ｓ、ｔ＿ＲＴＯを従来と同様の固定の値として、（１／１５）×５０となるので、送信可能レートＸｃａｌ＝約３．３３Ｍｂｐｓと算出される。すなわち、本発明の方式を採用すれば、従来方式に比べて、３倍以上の速度で伝送することが可能となる。

次に、このように算出して計算した送信可能なレートで送信した場合にＴＣＰとの親和
性を満たすことができることを示す。

本実施の形態では、送信端末１０１から受信端末１０６と受信端末１０７を経由して受信端末１０８に到達する経路で配送する場合に、ＴＣＰとの親和性を満たすには、次の３つの経路でＴＣＰとの親和性を満たせばよい。
（ｉ）送信端末１０１から受信端末１０６への経路
（ii）受信端末１０６から受信端末１０７への経路
（iii）受信端末１０７から受信端末１０８への経路

先に述べたとおり、送信可能なレートを算出する際に必要な情報は、ＲＴＴと損失イベント率である。損失イベント率は、受信端末１０８で計測される損失を元にＴＦＲＣ方式（ＲＦＣ３４４８）で規定される方式に基づき算出される。今、ＲＴＴは、経路（ｉ）、（ii）、（iii）で観測されるＲＴＴの最大値である。先に述べたとおり、ＲＴＴは、式（ｉ）の分母の要素であるため、算出される送信可能なレートは、経路（ｉ）、（ii）、（iii）のＲＴＴを同じ式に適用した場合よりも等しいか小さくなる。この値を、「Ｘｃａｌｍｉｎ」という。ゆえに、送信端末１０１がＸｃａｌｍｉｎでデータの配送を行えば、経路（ｉ）（ii）（iii）のいずれの経路上でもＴＣＰとの親和性を満たすレートと等しいか小さい値でデータの配送を行うことができる。すなわちＴＣＰとの親和性を保つことができる。

以上説明したように、本実施の形態によれば、ＳＩＣＣ方式、または、ＳＩＣＣ方式と同様にＴＦＲＣ方式を用いて複数の端末にデータの配送を行う流量制御方式に対して、上述したＲＴＴ分割計測を適用することで、ＳＩＣＣ方式の送信端末で受信端末との間のＲＴＴを計測する際に、不必要に大きくＲＴＴを算出する必要がなくなり、結果として、データの伝送の性能が不必要に悪化する問題がなくなる。具体的には、複数の国をまたがった複数の端末に対して、インターネットを経由して会議の映像を送信するようなシーンにＳＩＣＣ方式を適用した場合や、複数のＩＳＰやキャリヤにまたがった状態で配置された複数の端末に対してＳＩＣＣ方式で複数の端末にストリーミングを行うような場合に、本発明の方式を適用することで、より高品質、高精細な画像を受信端末で受信することが可能となる。

また、ＴＣＰとの親和性が保たれるので、上記のような適用を行った場合でも、インターネットや複数のＩＳＰキャリヤのネットワークを輻輳状態に陥れることはない。すなわち、同様な映像配信が同じインターネットや複数のＩＳＰキャリヤのネットワーク上で多数同時に行われても、結果として、最善の画像配信を行い続けることが可能となる。

なお、本実施の形態では、往復時間情報を有するパケットを受信端末から送信端末へ送信したが、本発明は、往復時間情報を有するパケットを他の端末で中継して送信端末に送信しても、同様の効果が奏されることは言うまでもない。

また、本実施の形態では、受信端末で往復時間の具体的な計算を行ったが、受信端末の報告するタイムスタンプなどの往復時間を取得可能な情報をもとにして、送信端末やその他の中継する受信端末で往復時間を計算しても、同様の効果が奏されることは言うまでもない。

本発明の一態様に係る流量制御方法は、複数の受信端末の中継によってパケットの配送を行う際の流量制御方法であって、パケットの配送をすべき隣接する受信端末との間の、パケットの往復時間を取得するステップと、取得した隣接する受信端末との間の複数のパケットの往復時間の中から予め定められた基準に基づいて所定の往復時間を選択するステップと、選択した往復時間をもとにパケットの送信レートを算出するステップとを有する
構成を有している。

この構成により、パケットの送信可能なレートを推定するためのパケット往復時間の計測を、パケットの配送に際して隣接する受信端末の間で分割して行うことができる。

また、本発明の一態様に係る流量制御方法は、送信レートを算出するステップが、ＴＦＲＣを用いて算出するステップである構成を有している。

この構成により、ＴＣＰとの親和性を満たす流量制御が行える。

また、本発明の一態様に係る流量制御方法は、所定の往復時間を選択するステップが、複数のパケットの往復時間の中から最大の往復時間を選択する構成を有している。

この構成により、ボトルネック区間におけるＲＴＴを用いて、送信可能なレートを推定することができる。

さらに、本発明の一態様に係る受信端末は、中継によって他の受信端末へパケットの配送を行う受信端末であって、パケットの配送をすべき隣接する他の受信端末との間のパケットの往復時間を、計測するための計測情報を含むパケットを送信する計測パケット送信部と、隣接する他の受信端末から計測情報を含むパケットに対する返信のパケットを受信する受信部と、受信部で受信した返信のパケットを基にパケットの往復時間に関する時間情報を取得する往復時間情報取得部と、往復時間情報取得部で取得したパケットの往復時間に関する時間情報を含むパケットを送信端末へ送信する往復時間情報送信部とを有する構成を有している。

この構成により、パケットの送信可能なレートを推定するための往復時間の計測を、パケットの配送に際して、隣接する受信端末との間で分割して行い、結果を送信端末へ送信することができる。

また、本発明の一態様に係る受信端末は、外部から送信された、パケットを配送すべき他の受信端末のリストから、配送すべき他の受信端末の受信端末識別子を取得する受信端末識別子情報取得部をさらに有し、計測パケット送信部が、受信端末識別子情報取得部で取得した受信端末識別子で特定される隣接する他の受信端末に、往復時間を計測するための計測情報を含むパケットを送信する構成を有している。

この構成により、外部から送信された、パケットを配送すべき隣接する他の受信端末のリストで特定された受信端末間のＲＴＴを計測できる。

さらに、本発明の一態様に係る送信端末は、中継によってパケットの配送を行う受信端末へパケットの配送する送信端末であって、パケットを配送すべき隣接する受信端末間のパケットの往復時間に関する情報を含むパケットを受信する受信部と、受信部で受信したパケットから往復時間を取得する往復時間情報取得部と、往復時間情報取得部で取得した複数の往復時間の中から予め定められた基準に基づいて所定の往復時間を選択する選択部と、選択部で選択した所定の往復時間を基にデータ配送の送信レートを算出する算出部とを有する構成を有している。

この構成により、パケットの送信可能なレートを推定するための往復時間の計測の際に、パケットの配送に際して隣接する受信端末との間で分割して計測した結果に基づき、パケット配送の送信レートを算出することができる。

また、本発明の一態様に係るパケット転送システムは、送信端末から、複数の受信端末へ受信端末の中継によってパケットの配送を行うパケット転送システムであって、受信端末は、パケットの配送をすべき隣接する他の受信端末との間のパケットの往復時間を、計測するための計測情報を含むパケットを送信する計測パケット送信部と、隣接する他の受信端末から計測情報を含むパケットに対する返信のパケットを受信する受信端末受信部と、受信端末受信部で受信した返信のパケットを基にパケットの往復時間に関する時間情報を得る往復時間情報取得部と、往復時間情報取得部で取得したパケットの往復時間に関する時間情報を含むパケットを送信端末へ送信する往復時間情報送信部とを有し、送信端末は、往復時間情報送信部から送信された、パケットの往復時間に関する時間情報を含むパケットを受信する送信端末受信部と、送信端末受信部で受信したパケットから往復時間を取得する往復時間取得部と、往復時間取得部で取得した複数の往復時間の中から予め定められた基準に基づいて所定の往復時間を選択する選択部と、選択部で選択した所定の往復時間を基にデータ配送の送信レートを算出する算出部とを有する構成を備えている。

この構成により、パケットの送信可能なレートを推定するための往復時間の計測を、パケットの配送に際して隣接する受信端末の間で分割して行うことができる。

すなわち、送信端末で、隣接する受信端末間のＲＴＴを計測する際に、パケットの配送をすべき隣接する受信端末との間の、パケットの往復時間を分割して取得することにより、送信可能レートが小さく算出されることはなく、ＴＣＰとの親和性を崩さないでデータ伝送の性能を向上させることができる。

２００６年１０月２日出願の特願２００６−２７０４１０の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。

本発明にかかる流量制御方法によれば、ＳＩＣＣ方式の送信端末で受信端末との間の往復時間を計測する際に、不必要に大きく算出することがなくなり、結果として、ＴＣＰとの親和性を崩さないでデータの伝送の性能を向上させることが可能になる。従って、映像や音声といったデータの配送を複数の端末に対して行う場合において、受信端末の能力やネットワークの状況に適応しながら流量制御する際に有用である。

従来のＳＩＣＣ方式を説明するための図 本発明の実施の形態におけるパケット転送システムのＲＴＴ分割計測の方式を説明するための構成図 本発明の一実施の形態におけるパケット転送システムのＲＴＴ分割計測処理の流れを示すシーケンスチャート 本実施の形態におけるＸＣＡＳＴパケットＡの構成を示す説明図 本実施の形態におけるＸＣＡＳＴパケットＢの構成を示す説明図 本実施の形態に係る送信端末の構成を示す構成図 本実施の形態に係る受信端末の構成を示す構成図 本実施の形態におけるＸＣＡＳＴパケット生成処理の流れを示すフローチャート 本実施の形態におけるＲＴＴ用時刻追記処理の流れを示すフローチャート 本実施の形態におけるＳＩＣＣ−ＤＡＴＡ−Ｒヘッダの構成を示す説明図 本実施の形態におけるＲＲパケットの構成を示す説明図 本実施の形態における報告要求パケットの構成を示す説明図 本実施の形態におけるＲＴＴ情報報告処理の流れを示すフローチャート 本実施の形態における報告パケットの構成を示す説明図 本実施の形態におけるＲＴＴ推定処理の流れを示すフローチャート 本実施の形態における報告パケットタイムアウト発生時の処理を示すフローチャート

Claims (6)

1. 送信端末から送出されたパケットの配送を受信端末の中継によって行う際の流量制御方法であって、
   前記送信端末および複数の受信端末のうち前記配送の経路において隣接する前記端末の組ごとに、前記端末の間のラウンドトリップタイムを取得するステップと、
   前記複数の受信端末のそれぞれについて、上流の前記端末の間のラウンドトリップタイムの中から予め定められた基準に基づいていずれかを選択するステップと、
   前記複数の受信端末のそれぞれについて、前記送信端末と前記複数の受信端末のそれぞれとの間の損失イベント率を取得するステップと、
   前記複数の受信端末のそれぞれについて、前記選択したラウンドトリップタイムと前記損失イベント率とに基づいて前記送信端末からのパケットの送信レートを算出するステップと、
   を有する流量制御方法。
2. 前記ラウンドトリップタイムを選択するステップは、
   前記取得したラウンドトリップタイムの中から最大のラウンドトリップタイムを選択する、
   請求項１記載の流量制御方法。
3. 前記ラウンドトリップタイムを取得するステップは、前記送信端末が前記複数の受信端末へ前記端末の間のラウンドトリップタイムの計測を要求することにより前記端末の間のラウンドトリップタイムを取得し、
   前記送信端末が前記複数の受信端末へ前記端末の間のラウンドトリップタイムの計測を要求してからの時間が所定のタイムアウト値を超えたときタイムアウトするステップを更に有し、
   前記所定のタイムアウト値は、前記送信端末と、前記複数の受信端末のうち前記配送の経路における最後の受信端末との間のランドトリップタイムより大きい、
   請求項１に記載の流量制御方法。
4. 前記タイムアウトするステップにおいてタイムアウトが発生した場合、
   前記複数の受信端末のそれぞれの前記パケットの送信レートは、前記送信端末と前記複数の受信端末のそれぞれとの区間のラウンドトリップタイムと、前記損失イベント率とに基づいて算出される、
   請求項３に記載の流量制御方法。
5. 複数の受信端末に対するパケットの配送を前記受信端末の中継によって行う送信端末であって、
   自端末および前記複数の受信端末のうち前記配送の経路において隣接する前記端末の組ごとに、前記端末の間のラウンドトリップタイムに関する情報を含むパケットと、前記複数の受信端末のそれぞれについて、自端末と前記複数の受信端末のそれぞれとの間の損失イベント率とを受信する受信部と、
   前記受信部で受信されたパケットから前記ラウンドトリップタイムを取得する往復時間取得部と、
   前記複数の受信端末のそれぞれについて、上流の前記端末の間のラウンドトリップタイムの中から予め定められた基準に基づいていずれかを選択する選択部と、
   前記複数の受信端末のそれぞれについて、前記選択部で選択されたラウンドトリップタイムと前記損失イベント率とに基づいて前記送信端末からのパケットの送信レートを算出する算出部と、
   を有する送信端末。
6. 送信端末から送出された第１のパケットの配送を受信端末の中継によって行うパケット転送システムであって、
   前記受信端末は、
   前記配送の経路において下流側に隣接する第１の受信端末との間のラウンドトリップタイムを計測するための計測情報を含む第２のパケットを、前記第１の受信端末へ送信する計測パケット送信部と、
   前記第１の受信端末から、前記第２のパケットに対する返信である第３のパケットが送られてきたとき、前記第３のパケットを受信する受信端末受信部と、
   前記受信端末受信部で受信された前記第３のパケットを基に、前記ラウンドトリップタイムに関する時間情報を取得する往復時間情報取得部と、
   前記往復時間情報取得部で取得された第４のパケットを、前記送信端末へ送信する往復時間情報送信部と、
   を有し、
   前記送信端末は、
   前記受信端末から前記第４のパケットを受信する送信端末受信部と、
   前記送信端末および前記複数の受信端末のうち前記配送経路において隣接する前記端末の組ごとに前記端末の間のラウンドトリップタイム、および、前記複数の受信端末のそれぞれについて、自端末と前記複数の受信端末のそれぞれとの間の損失イベント率を、前記送信端末受信部で受信された前記第４のパケットから、取得する往復時間取得部と、
   前記複数の受信端末のそれぞれについて、上流の前記端末の間のラウンドトリップタイムの中から予め定められた基準に基づいていずれかを選択する選択部と、
   前記複数の受信端末のそれぞれについて、前記選択されたラウンドトリップタイムと前記損失イベント率とに基づいて前記送信端末からのパケットの送信レートを算出する算出部と、を有する、
   パケット転送システム。

Images