特許 7482098 複数のストリームを使用してデータを送受信する通信装置及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-05-01

(45)【発行日】2024-05-13

(54)【発明の名称】複数のストリームを使用してデータを送受信する通信装置及びプログラム

(51)【国際特許分類】

   H04L 69/14 20220101AFI20240502BHJP

   H04L 45/243 20220101ALI20240502BHJP

【ＦＩ】

H04L69/14

H04L45/243

【請求項の数】 9

(21)【出願番号】P 2021161496

(22)【出願日】2021-09-30

(65)【公開番号】P2023051054

(43)【公開日】2023-04-11

【審査請求日】2023-07-26

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】110003281

【氏名又は名称】弁理士法人大塚国際特許事務所

(72)【発明者】

【氏名】鈴木 陽登

【審査官】岩田 玲彦

(56)【参考文献】

【文献】特表２０１０－５３５４３５（ＪＰ，Ａ）

【文献】国際公開第２０１０／１３１４１９（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ６９／１４

Ｈ０４Ｌ ４５／２４３

(57)【特許請求の範囲】

【請求項1】

データを含むパケットを、ネットワークを介して受信装置に送信する通信装置であって、
複数のストリームと、前記複数のストリームそれぞれについて、１つ以上のサブストリームを設定する設定手段と、
前記パケットを前記複数のストリームの内のいずれかのストリームに割り当てる割当手段と、
前記ストリームに割り当てた前記パケットを、当該ストリームの前記１つ以上のサブストリームそれぞれで送信する送信手段と、
を備えていることを特徴とする通信装置。

【請求項2】

前記送信手段は、ストリームを単位としてウィンドウサイズを管理することを特徴とする請求項１に記載の通信装置。

【請求項3】

前記送信手段は、前記複数のストリームの前記１つ以上のサブストリームそれぞれについて、前記受信装置が正常に受信できなかった第１損失パケットの数を示す受信状況情報を前記受信装置から取得し、前記受信状況情報が示す前記第１損失パケットの数に基づき、前記複数のストリームそれぞれについて、前記１つ以上のサブストリームの数を変更するか否かを判定することを特徴とする請求項１又は２に記載の通信装置。

【請求項4】

前記送信手段は、前記受信装置から正常に受信できなかった第２損失パケットが通知された場合、当該第２損失パケットを、当該第２損失パケットを送信した前記１つ以上のサブストリームそれぞれで再送することを特徴とする請求項３に記載の通信装置。

【請求項5】

前記第２損失パケットは、前記ストリームの前記１つ以上のサブストリームの総てにおいて前記第１損失パケットとなったパケットであることを特徴とする請求項４に記載の通信装置。

【請求項6】

前記送信手段は、前記複数のストリームそれぞれについて、前記第２損失パケットの発生率の目標値を保持しており、前記受信状況情報が示す前記１つ以上のサブストリームそれぞれの前記第１損失パケットの数に基づき、前記複数のストリームそれぞれについて、前記第２損失パケットの発生率を前記目標値以下とするのに必要なサブストリームの数を求めることで、前記複数のストリームそれぞれについて、前記１つ以上のサブストリームの数を変更するか否かを判定することを特徴とする請求項４又は５に記載の通信装置。

【請求項7】

データを含むパケットを、ネットワークを介して送信装置から受信する通信装置であって、
複数のストリームと、前記複数のストリームそれぞれについて、１つ以上のサブストリームを設定する設定手段と、
前記複数のストリームの前記１つ以上のサブストリームそれぞれについて、正常に受信しなかった第１損失パケットを判定する第１判定手段と、
前記複数のストリームそれぞれについて、ストリームの前記１つ以上のサブストリームの総てにおいて前記第１損失パケットとなった第２損失パケットを判定する第２判定手段と、
前記第２損失パケットの再送のため、前記第２損失パケットを示す情報を前記送信装置に通知する通知手段と、
を備えていることを特徴とする通信装置。

【請求項8】

前記通知手段は、前記複数のストリームの前記１つ以上のサブストリームそれぞれについて、前記第１損失パケットの数を示す受信状況情報を前記送信装置に通知することを特徴とする請求項７に記載の通信装置。

【請求項9】

１つ以上のプロセッサを有する装置の前記１つ以上のプロセッサで実行されると、前記装置を、請求項１から８のいずれか１項に記載の通信装置として機能させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、複数のストリームを使用してデータを送受信する技術に関する。

【背景技術】

【0002】

ネットワークを介したデータの送受信のためにＴＣＰ（伝送制御プロトコル）が使用されている。ＴＣＰによるデータの送受信においては輻輳制御が行われる。具体的には、データを受信する通信装置（以下、受信装置）は、データを送信する通信装置（以下、送信装置）からのパケットの受信状況をＡＣＫ又はＮＡＣＫで送信装置に通知する。なお、ＡＣＫはパケットを正常に受信していることを示し、ＮＡＣＫは損失パケットが生じたことを示す。なお、損失パケットとは、受信装置が正常に受信しなかったパケット、つまり、受信装置に到達しなかったパケットと、受信装置に到達したが誤りが発生していたパケットと、を含む。

【0003】

輻輳制御において、送信装置はウィンドウサイズを管理する。ウィンドウサイズは、送信装置が、受信装置からのＡＣＫを受信することなく送信できるパケット数を規定する。送信装置は、受信装置から報告される受信状況、つまり、ＡＣＫ又はＮＡＣＫに基づきウィンドウサイズを増減させる。一般的に、送信装置は、ＮＡＣＫを受信するとウィンドウサイズを減少させ、ＡＣＫのみを受信している間、所定のアルゴリズムに従いウィンドウサイズを増加させる。ウィンドウサイズに応じて送信装置が送信するパケット数がネットワークの状態に応じて調整され、輻輳制御が実現される。非特許文献１は、ＣＵＢＩＣと呼ばれる輻輳制御方法を開示している。非特許文献１によると、送信装置は、ＡＣＫのみを受信している間、３次元関数に従いウィンドウサイズを増加させている。

【0004】

また、非特許文献２は、送信装置から受信装置へのデータ送信速度を増加させるため、複数のストリームを使用してデータを送受信するＭＰＴＣＰ（Ｍｕｌｔｉ－Ｐａｔｈ ＴＣＰ）を開示している。ＭＰＴＣＰにおいては、ストリーム毎に輻輳制御が行われる。なお、ストリームは、コネクション又はパスとも呼ばれ得る。

【先行技術文献】

【非特許文献】

【0005】

【文献】"ＣＵＢＩＣ：Ａ Ｎｅｗ ＴＣＰ－Ｆｒｉｅｎｄｌｙ Ｈｉｇｈ－Ｓｐｅｅｄ ＴＣＰ Ｖａｒｉａｎｔ"，ＡＣＭ ＳＩＧＯＰＳ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｒｅｖｉｅｗ，Ｖｏｌｕｍｅ４２ Ｉｓｓｕｅ５，２００８年７月

【文献】ＩＥＥＥ／ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｎｅｔｗｏｒｋｉｎｇ（Ｖｏｌｕｍｅ：１４，Ｉｓｓｕｅ：６，Ｄｅｃ．２００６），"Ｍｕｌｔｉ－Ｐａｔｈ ＴＣＰ： Ａ Ｊｏｉｎｔ Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ ａｎｄ Ｒｏｕｔｉｎｇ Ｓｃｈｅｍｅ ｔｏ Ｅｘｐｌｏｉｔ Ｐａｔｈ Ｄｉｖｅｒｓｉｔｙ ｉｎ ｔｈｅ Ｉｎｔｅｒｎｅｔ"

【発明の概要】

【発明が解決しようとする課題】

【0006】

非特許文献２に記載の様に、複数のストリームを使用することで、単一のストリームを使用してデータを送信することと比較して、より高いデータ送信速度（スループット）を達成することができる。しかしながら、各ストリームにおいて損失パケットが発生することを考慮すると、さらに高いスループットを達成するためには膨大な量のストリームを設定する必要があり、通信装置の処理負荷が増大する。

【0007】

本発明は、通信装置の処理負荷を抑える技術を提供するものである。

【課題を解決するための手段】

【0008】

本発明の一態様によると、データを含むパケットを、ネットワークを介して受信装置に送信する通信装置は、複数のストリームと、前記複数のストリームそれぞれについて、１つ以上のサブストリームを設定する設定手段と、前記パケットを前記複数のストリームの内のいずれかのストリームに割り当てる割当手段と、前記ストリームに割り当てた前記パケットを、当該ストリームの前記１つ以上のサブストリームそれぞれで送信する送信手段と、を備えていることを特徴とする。

【発明の効果】

【0009】

本発明によると、通信装置の処理負荷を抑えることができる。

【図面の簡単な説明】

【0010】

【図1】実施形態の説明に使用する通信システムの構成図。

【図2】一実施形態によるデータ送受信方法の説明図。

【図3】一実施形態によるデータ送受信方法の説明図。

【図4】一実施形態によるデータ送受信の開始時に行う処理のシーケンス図。

【図5】一実施形態によるデータ送受信中に行う処理のシーケンス図。

【図6】一実施形態による通信装置の送信側構成図。

【図7】一実施形態による通信装置の受信側構成図。

【発明を実施するための形態】

【0011】

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものでなく、また実施形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。実施形態で説明されている複数の特徴うち二つ以上の特徴が任意に組み合わされてもよい。また、同一若しくは同様の構成には同一の参照番号を付し、重複した説明は省略する。

【0012】

図１は、本実施形態の説明に使用する通信システムの構成図である。ネットワーク３０には、複数の通信装置が接続される。通信装置のそれぞれは、データの送信及び受信が可能なものであるが、以下では、データを送信する通信装置を送信装置１０と表記し、送信装置１０が送信したデータを受信する通信装置を受信装置２０と表記する。送信装置１０、受信装置２０は、それぞれ、１つ以上のインタフェースによりネットワークに接続され得る。１つ以上のインタフェースは、例えば、無線ローカルエリアネットワーク（ＬＡＮ）に接続するためのインタフェース、有線ＬＡＮに接続するためのインタフェース、３ＧＰＰ（第３世代パートナシッププロジェクト）で標準化される無線インタフェース等であり得る。図１のネットワーク３０は、移動通信網、インターネット等の様々な種別のネットワークを含む。

【0013】

図２は、送信装置１０による受信装置２０へのデータ送信の説明図である。本実施形態においては、非特許文献１に記載されている様に、データを含むパケットを、複数のストリームのいずれか１つによりに送信する。図２においては、ストリーム５０及びストリーム６０の２つのストリームが使用されているが、例示であり、ストリームの数は、３以上の数とすることができる。

【0014】

各ストリームは、１つ以上のサブストリームで構成される。図２において、ストリーム５０は、サブストリーム５０－１、サブストリーム５０－２及び５０－３で構成され、ストリーム６０は、サブストリーム６０－１、サブストリーム６０－２及び６０－３で構成されている。なお、各ストリームを構成するサブストリームの数は、ストリーム毎に異なり得る。

【0015】

送信装置１０は、アプリケーションプログラムから送信するパケット（データ）を受け取る度に、当該パケットをどのストリームで送信するかを決定、つまり、パケットをどのストリームに割り当てるかを決定する。この割り当てには、任意の方法を使用することができる。例えば、送信装置１０は、新たなパケットを、ラウンドロビン形式で各ストリームに割り当てることができる。また、送信装置１０は、各ストリームの送信待ちパケット数を判定し、送信待ちパケット数の少ないストリームに新たなパケットを割り当てることができる。一方、本実施形態において、送信装置１０は、ストリームに割り当てられたパケットを、当該ストリームを構成する総てのサブストリームで送信する。

【0016】

図３は、上述した送信装置１０によるパケットの送信方法を示している。図３において、送信装置１０は、データ（パケット）の送信のため、２つのストリーム＃１及び＃２を使用している。なお、ストリーム＃１は、２つのサブストリーム＃１－１及び＃１－２を有し、ストリーム＃２は、２つのサブストリーム＃２－１及び＃２－２を有している。図３において、送信装置１０は、パケット＃１～＃６を、ラウンドロビン形式で各ストリームに割り当てている。したがって、パケット＃１、＃３及び＃５は、ストリーム＃１で送信され、パケット＃２、＃４及び＃６は、ストリーム＃２で送信される。ストリームに割り当てられたパケットは、当該ストリームの総てのサブストリームで送信されるため、パケット＃１、＃３及び＃５は、サブストリーム＃１－１及び＃１－２で送信され、パケット＃２、＃４及び＃６は、サブストリーム＃２－１及び＃２－２で送信される。なお、実際にネットワーク３０に送信されるのはサブストリームであり、ネットワーク３０は、ストリームを認識しない。

【0017】

本実施形態において、送信装置１０及び受信装置２０は、ストリームを単位として輻輳制御を行う。図３において、網掛けのパケットは、損失パケット、つまり、受信装置２０において誤りが検出されたパケット、或いは、受信装置２０に届かなかったパケットを示している。ストリーム＃１－１においては、パケット＃１が損失パケットとなり、ストリーム＃１－２においては、パケット＃３が損失パケットとなっている。しかしながら、パケット＃１はストリーム＃１―２で正常に受信され、パケット＃３はストリーム＃１―１で正常に受信されている。したがって、受信装置２０は、ストリーム＃１では、損失パケットが無いこと、つまり、ＡＣＫを送信装置１０に通知する。

【0018】

一方、パケット＃６は、ストリーム＃２－１及び＃２－２の両方において損失パケットとなっている。したがって、受信装置２０は、ストリーム＃２においては、パケット＃６の損失を示すＮＡＣＫを送信装置１０に通知する。なお、ストリームのＡＣＫ／ＮＡＣＫは、当該ストリームの総てのサブストリームで送信される。

【0019】

図４は、送信装置１０が受信装置２０へのデータ送信を開始する際の処理を示すシーケンス図である。送信装置１０は、Ｓ１において、目標速度Ｓに基づきストリーム数Ｎを決定する。目標速度Ｓは、データ送信を行うアプリケーションプログラムから通知される。例えば、送信装置１０は、目標速度Ｓを、各ストリームの平均速度又はピーク速度で除した値の少数点以下を切り上げることで、ストリーム数Ｎを決定することができる。この場合、目標速度Ｓが１０Ｇｂｐｓであり、各ストリームの平均速度が２Ｇｂｐｓであると、ストリーム数Ｎは５になる。また、マージンを見込むため、この値に所定数を乗ずることができる。例えば、所定数を２とすると、ストリーム数Ｎは１０になる。なお、各ストリームの平均速度又はピーク速度は、過去の通信において測定された値を使用することができる。過去の通信において測定された値が無い場合、所定の初期値を使用することができる。また、送信装置１０は、インタフェース数をストリーム数とすることができる。例えば、ネットワーク３０にアクセスするためのインタフェース数が３である場合、送信装置１０は、ストリーム数を３に決定することができる。

【0020】

Ｓ２において、送信装置１０は、ストリームの目標損失率Ｌに基づき、各ストリームのサブストリーム数Ｍを決定する。ストリームの目標損失率Ｌは、当該ストリームで送信するパケット数に対する、当該ストリームの損失パケット数の比率の目標値である。ストリームの目標損失率Ｌは予め送信装置１０に設定されている。例えば、送信装置１０は、あるストリームのサブストリーム数Ｍを、
Ｍ＝ｃｅｉｌ（ｌоｇｘＬ） （１）
で求める。ここで、ｘは、サブストリームの損失率であり、ｃｅｉｌ（）は、天井関数である。通信の開始時において、ｘには所定の初期値を使用する。例えばｘ＝０．００１、かつ、Ｌ＝０．０００００１の場合、サブストリーム数Ｍは２となる。

【0021】

送信装置１０は、各ストリームの識別子と、各サブストリームの送信側識別子を決定する。例えば、サブストリームの送信側識別子は、当該サブストリームで送信するパケットの送信側のＩＰアドレスと、ＴＣＰパケットの送信側ポート番号の組み合わせである。ストリームの識別子は、ストリームを識別するものであり、任意の値を使用することができる。送信装置１０は、Ｓ３で、各サブトトリ―ムそれぞれについて、サブストリームの送信側識別子と、当該サブストリームが属するストリームの識別子と、を受信装置２０に通知する。なお、１つのストリームに属する複数のサブストリームの送信のためのインタフェースは、同じであっても異なるものであっても良い。

【0022】

受信装置２０は、Ｓ３において、送信装置１０からサブストリームの送信側識別子と、当該サブストリームが属するストリームの識別子と、を受け取ることで、ストリーム数と、各ストリームのサブストリーム数を認識する。受信装置２０は、続いて、各サブストリームの送信側識別子に対応する受信側識別子を決定する。サブストリームの受信側識別子は、当該サブストリームで受信するパケットの宛先ＩＰアドレスと、ＴＣＰパケットの受信側ポート番号の組み合わせである。なお、１つのストリームに属する複数のサブストリームの受信のためのインタフェースは、同じであっても異なるものであっても良い。受信装置２０は、Ｓ４において、サブストリームの送信側識別子と受信側識別子との対応関係を送信装置１０に通知する。送信装置１０は、この通知により、各サブストリームにおいて使用する宛先ＩＰアドレスと宛先ポート番号とを認識する。

【0023】

その後、送信装置１０は、図２及び図３を用いて説明した様にデータを送信する。また、受信装置２０は、ストリームを単位として損失パケットを判定し、損失パケットが生じた場合には、送信装置１０に通知を行う。

【0024】

図５は、データ送信中に実行されるサブストリーム変更処理のシーケンス図である。受信装置２０は、サブストリームそれぞれについて、損失パケット数をカウントする。例えば、受信装置２０が図３の様にパケットを受信した場合、各サブストリームの損失パケット数は、いずれも１である。受信装置２０は、Ｓ１０において所定周期毎に各サブストリームの損失パケット数を送信装置１０に通知する。送信装置１０は、各サブストリームの損失パケット数を受信すると、各サブストリームで送信したパケット数に基づき各サブストリームにおいて損失パケットが生じている比率である損失率を判定する。続いて、送信装置１０は、同じストリーム内の各サブストリームの損失率の平均値を求める、送信装置１０は、Ｓ１１で、この平均値を式（１）のｘとしてストリームのサブストリーム数を求める。

【0025】

Ｓ１１で求めたサブストリーム数が、現在のサブストリーム数と同じであると、送信装置１０は、現在のサブストリーム数を維持する。一方、Ｓ１１で求めたサブストリーム数が、現在のサブストリーム数より多い場合、送信装置１０は、サブストリーム数がＳ１１で求めたサブストリーム数となる様に、サブストリームの追加を行う。このため、送信装置１０は、Ｓ１２で、追加するサブストリームの送信側識別子を受信装置２０に通知する。なお、当該通知は、同じストリームの現在のサブストリームを使用して行われるため、ストリームの識別子を通知する必要はない。受信装置２０は、追加するサブストリームの受信側識別子を決定し、追加するサブストリームの送信側識別子と受信側識別子の対応関係をＳ１３で送信装置１０に通知する。これにより、ストリームには新たなサブストリームが追加される。また、Ｓ１１で求めたサブストリーム数が、現在のサブストリーム数より少ない場合、送信装置１０は、サブストリーム数がＳ１１で求めたサブストリーム数となる様に、サブストリームの削除を行う。このため、送信装置１０は、Ｓ１２で、削除するサブストリームの送信側識別子を受信装置２０に通知する。なお、Ｓ１１で求めたサブストリーム数が、現在のサブストリーム数より少ない場合には、サブストリームの削除を行わず、現在のサブストリーム数を維持する構成とすることもできる。

【0026】

図６は、本実施形態による送信装置１０の構成図である。ストリーム決定部１０１は、上述した様に、目標速度Ｓに基づき設定するストリーム数を決定し、決定したストリーム数をサブストリーム決定部１０２及び通信部１０３に通知する。サブストリーム決定部１０２は、上述した様に、目標損失率Ｌに基づき、各ストリームのサブストリーム数を決定し、各ストリームのサブストリーム数を通信部１０３に通知する。

【0027】

通信部１０３の輻輳制御部１０５は、各ストリームの識別子と、各サブストリームの送信側識別子を決定して、各サブストリームの送信側識別子と、各サブストリームがどの識別子のストリームに属するかを受信装置２０に通知する。また、輻輳制御部１０５は、受信装置２０からサブストリームの送信側識別子と受信側識別子の対応関係を受信すると、各サブストリームでパケットの送信を開始する。なお、割当部１０４は、アプリケーションプログラムから受信するデータをパケット化し、各パケットを複数のストリームのいずれかに割り当てる。

【0028】

データの送信中、輻輳制御部１０５は、ストリーム毎にウィンドウサイズを管理する。また、輻輳制御部１０５は、受信装置２０からパケットの受信状況を示す受信状況情報を受信する。受信状況情報は、サブストリームレベルの受信状況を示す情報と、ストリームレベルの受信状況を示す情報と、を含む。サブストリームレベルの受信状況は、各サブストリームで生じた損失パケット（第１損失パケット）の数を示す。輻輳制御部１０５は、受信装置２０から通知された各サブストリームの第１損失パケット数に基づき、各サブストリームの損失率を求めてサブストリーム決定部１０２に通知する。サブストリーム決定部１０２は、各サブストリームの損失率に基づき、上述した様に、各ストリームのサブストリーム数を決定して輻輳制御部１０５に通知する。輻輳制御部１０５は、サブストリーム決定部１０２から通知された各ストリームのサブストリーム数に基づき、サブストリームの追加／削除が必要かを判定し、必要な場合には、上述した様に、サブストリームの追加／削除のための処理を行う。

【0029】

一方、ストリームレベルの受信状況は、各ストリームで生じた損失パケット（第２損失パケット）を示す。第２損失パケットは、ストリームの総てのサブストリームにおいて第１損失パケットとなったパケットである。輻輳制御部１０５は、第２損失パケットが通知された場合、当該第２損失パケットを、当該第２損失パケットを送信した総てのサブストリームで再送する。なお、上記式（１）における目標損失率Ｌは、第２損失パケットの発生率の目標値である。目標損失率Ｌは、ストリーム毎に異なり得る。

【0030】

図７は、受信装置２０の構成図である。通信部２０１の輻輳制御部２０２は、送信装置１０から各ストリームの識別子と、各ストリームに属する各サブストリームの送信側識別子を受信すると、各サブストリームの送信側識別子と対になる受信側識別子を決定し、各サブストリームの送信側識別子と受信側識別子の対応関係を送信装置１０に通知する。

【0031】

データの受信中、輻輳制御部２０２は、ストリームを単位として輻輳制御を行う。つまり、ストリーム内のいずれかのサブストリームでパケットを受信すると、他のサブストリームでは損失パケットとなっていても、当該パケットについては正常に受信できたものとしてＡＣＫを送信する。一方、総てのサブストリームで正常に受信できなかったパケット（第２損失パケット）についてはＮＡＣＫを送信して送信装置１０に再送を促す。輻輳制御部２０２は、この様に、ストリームを単位として輻輳制御を行い、受信したパケットのデータをアプリケーションプログラムに出力する。

【0032】

さらに、輻輳制御部２０２は、サブストリーム毎の第１損失パケット数を所定期間毎に集計し、受信状況情報として送信装置１０に通知する。通知した受信状況情報に従い送信装置１０からサブストリームの追加／削除が通知されると、輻輳制御部２０２は、サブストリームの追加／削除を行う。

【0033】

以上、本実施形態では、ストリームを１つ以上のサブストリームで構成し、同じストリームの１つ以上のサブストリームで同じパケットを冗長的に送信する。この構成により、１つのストリームの損失率を実質的に低減させることができる。したがって、必要なストリームの数は、同じ損失率の場合に従来のＭＰＴＣＰで必要なストリーム数より小さくでき、よって、通信装置の処理負荷を抑えることができる。

【0034】

なお、本実施形態では、式（１）により各ストリームのサブストリーム数を求めるものとしたが、本発明は式（１）により各ストリームのサブストリーム数を求めることに限定されない。具体的には、ストリームにおける第２損失パケットの発生率（損失率）を、当該ストリームの目標値（式（１）におけるＬ）以下とするために必要なサブストリーム数を求めるものであれば、他の方法を使用することができる。

【0035】

なお、本発明による通信装置、つまり、上述した送信装置１０及び受信装置２０は、デバイスの１つ以上のプロセッサで実行されると、当該デバイスを送信装置１０及び／又は受信装置２０として動作させるプログラムにより実現することができる。これらプログラムは、デバイス可読記憶媒体に格納されて、又は、ネットワーク経由で配布が可能なものである。

【0036】

上記構成により、処理負荷を抑えつつ高速なデータ転送を実現することができる。よって、国連が主導する持続可能な開発目標（ＳＤＧｓ）の目標９「レジリエントなインフラを整備し、持続可能な産業化を推進するとともに、イノベーションの拡大を図る」に貢献することが可能となる。

【0037】

発明は上記の実施形態に制限されるものではなく、発明の要旨の範囲内で、種々の変形・変更が可能である。

【符号の説明】

【0038】

１０４：割当部、１０５：輻輳制御部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】