JP3596736B2 - マルチキャストデータ配信方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、送信者と複数の受信者との間でマルチキャストデータ配信を行う通信方法に関し、特に帯域を予約して受信端末をグループ化することで、再送処理の発生頻度を減少させることにより、配信処理全体の速度を向上できるマルチキャストデータ配信方法に関する。
【０００２】
【従来の技術】
図８は、従来のマルチキャストデータ配信システムの構成例を示す図である。
図８において、送信端末７１は、配信データを各受信端末７７〜８１に発信する端末装置であり、中継ネットワーク７２〜７６に接続されている。受信端末７７〜８１は、送信端末７１から配信されてきたデータを受信する端末装置であり、送信端末７１と同様に中継ネットワーク７２〜７６に接続されている。
中継ネットワーク７２〜７６は、送信端末７１と各受信端末７７〜８１との間を接続して相互に通信を行うためのネットワークであり、データの中継配信を行う中継ネットワークノード７２〜７６と、中継ネットワークノード７２〜７６および送受信端末７１−７７〜８１間を相互に結ぶ複数の伝送路８３から構成されている。
また、中継ネットワーク７２〜７６は、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）網やＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網等のマルチキャスト配信機能（一斉同報機能）、すなわちある端末が発信したデータを特定多数の端末に複製配送する機能を持つ。すなわち、送信端末上の同一のデータを同時に複数の受信端末へ配信するために、中継ネットワークノードは送信データを複製して複数のリンクに転送する。
【０００３】
図８のシステムにおいて、送信端末７１が発信したデータは、中継ネットワーク７２〜７６を介して各受信端末７７〜８１にマルチキャスト配信される。
もしも、配信中に中継ネットワーク７２〜７６あるいは受信端末７７〜８１自身が受信に失敗したデータのうち、修復不可能なものが発見された場合には、従来の方法では、損失したデータを再送して、それを受信することによりデータの信頼性を確保していた。
ところで、マルチキャスト配信中に発生するデータ損失の原因としては、伝送路８３での伝送誤り等の種々の要因があるが、特に問題となるのは受信端末７７〜８１あるいは伝送経路途中の中継ネットワークノード７２〜７６の過負荷によるデータ損失である。過負荷によるデータ損失は、送信端末７１から各受信端末７７〜８１までの経路上の中継ネットワークノード７２〜７６や伝送路８３の使用状況、および各受信端末７７〜８１のデータ処理性能が受信端末によりそれぞれ異なっているような場合に、処理性能を越えている状態で発生する。
【０００４】
例えば、図８において、送信端末７１が３０Ｍｂｉｔ／ｓｅｃで受信端末７７〜７９にデータ配信を行った場合を考える。このとき、中継ネットワークノード７２、７３および受信端末７７が３０Ｍｂｉｔ／ｓｅｃの配信速度に対して十分な処理性能を持っているのに対して、受信端末７８および中継ネットワークノード７４の処理性能が２９Ｍｂｉｔ／ｓｅｃしかない状態を仮定する。
この仮定の下では、伝送誤りがない限り受信端末７７ではデータ損失は発生しない。これに対して、受信端末７８では、受信時にデータ損失が発生し、受信端末７９，８０では中継ネットワークノード７４でのデータ転送時にデータ損失が発生してしまうため、データの再送処理が必要となる。
一方、送信端末７１が２９Ｍｂｉｔ／ｓｅｃでデータ配信を行う場合を仮定すると、伝送誤りがない限り送信対象の受信端末７７〜８０の全てにおいてデータ損失が発生しないので、データ再送処理は不要である。
以上の例からも明らかなように、信頼性のあるマルチキャストデータ配信で効率のよい通信を行うためには、各受信端末７７〜８１の各々の環境において、転送時のデータ損失が発生しないようなデータ配信速度を用いることにより、再送の発生数を最小限に留めることが重要となる。
【０００５】
従来の方法における具体例として、例えば文献１（ＲＭＴＰ（Ｌｕｃｅｎｔ）Ｊ．Ｃ．Ｌｉｎ ａｎｄ Ｓ．Ｐａｕｌ，“ＲＭＴＰ：Ａ Ｒｅｌｉａｂｌｅ Ｍｕｌｔｉｃａｓｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ”，ＩＥＥＥ Ｉｎｆｏｃｏｍ ’９６．ｐｐ１４１４−１４２４）では、データ損失の検出のために、受信端末からのＡＣＫ返送を使用している。また、フロー制御には、転送速度制御とウィンドウ制御を併用したＴＣＰと類似する方法（Ｓｌｏｗ Ｓｔａｒｔ）を用いているが、これではフロー制御中に配送されたデータに損失が生じ、データ再送処理が生じてしまう。また、この方法では、最も遅い受信者に合わせて送信速度が決定されてしまうため、帯域予約と連係した場合には、予約可能な帯域が十分にあってもそれを活用できない受信者が生じるという問題が生じる。
【０００６】
また、他の文献２（ＲＭＴＰ（ＩＢＭ／ＮＴＴ）Ｓｈｉｒｏｓｈｉｔａ，Ｓａｎｏ，Ｔａｋａｈａｓｈｉ，Ｙａｍａｓｈｉｔａ，Ｙａｍａｎｏｕｃｈｉ，ａｎｄ Ｋｕｓｈｉｄａ，“Ｐｅｒｆｏｒｍａｎｃｅ Ｅｖａｌｕａｔｉｏｎ ｏｆｒｅｌｉａｂｌｅ ｍｕｌｔｉｃａｓｔ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ ｆｏｒ ｌａｒｇｅ−ｓｃａｌｅ ｄｅｌｉｖｅｒｙ”Ｐｒｏｃ．ＩＦＩＰ ＰｆＨＳＮ．Ｏｃｔ．１９９６．）では、データ損失の検出のために、受信端末からのＡＣＫ／ＮＡＣＫ返送を併用している。また、フロー制御には、代表受信者からのＡｃｋ／Ｎａｃｋに基づいた転送速度制御を用いているが、代表の受信者による転送速度変更要求を行った場合には、調整段階中に配送されたデータに損失が発生するため、データ再送処理が生じてしまうという問題がある。また、送信速度に対して十分な帯域が確保できない受信者が発生するという問題に対する部分的解決策として、再送要求の多い受信者を隔離して個別再送する機能を有している。しかし、上記文献２に記載の方法は、帯域予約機能との連係は特にない。
【０００７】
【発明が解決しようとする課題】
従来の信頼性のあるデータ配送を行うマルチキャスト方式では、ある定められた速度で全ての受信端末に対してデータの配送を開始した後、配送後に検出されたデータ損失の状況に応じて配送速度調整や個別再送処理への切り替え等の処理を行うことにより、できるだけデータ配信処理時間のかからない最適なマルチキャスト配送形態を模索している。
しかしながら、このような方式では、最適状態に安定するまでの調整段階中に配送されたデータに損失が発生するため、データ再送処理が生じてしまうという第１の問題点が生じる。
また、従来の方式では、送信者と各受信者の一部あるいは全てがＡＴＭ等の帯域予約機能を持つネットワークにより相互に接続されている場合においても、前述のような方式で最適なマルチキャスト配送形態を模索している。このため、予約可能な帯域が十分にあっても、それを活用できない受信者が存在したり、送信速度に対して十分な帯域が確保できない受信者が発生するという第２の問題点が生じる。
【０００８】
そこで、本発明の目的は、これら従来の課題を解決し、マルチキャスト配信における再送処理の発生頻度を減少させ、配信処理全体の速度を向上させることにより、最適状態に安定するまでの調整段階中に配送されたデータに損失が生じて、データ再送処理が発生してしまう第１の問題点や、予約可能な帯域が十分にあってもそれを活用できない受信者、および送信速度に対して十分な帯域が確保できない受信者が存在する第２の問題点を解消することが可能なマルチキャストデータ配信方法を提供することにある。
【０００９】
【課題を解決するための手段】
本発明のマルチキャストデータ配信方法では、上記の問題点を解消するために、先ず、データ送信前に各受信者の利用可能な速度を問い合わせ、次に、互いにほぼ等しい配信（受信）可能速度を持つ受信者の集合を１つの受信グループ単位とみて各グループ毎に信頼性のあるマルチキャスト配送処理を適用することにより、データ転送中の再送処理手順を最小限に留める。このために、本発明の方法では、マルチキャスト配送の開始前に、各受信端末および中継ネットワークノードで利用可能な資源について情報収集を行い、発信者はこの情報に基づいてほぼ等しい転送速度を持つグループ毎に受信者を分類して、グループ別に信頼性のあるマルチキャスト配送処理を行うとともに、帯域予約機能を持つネットワークと持たないネットワークが混在する環境においては、前記の受信者グループ分類の判断材料として帯域予約機能の有無を利用する。
【００１０】
その結果、本発明では、以下の手順で処理することになる。
（１）上述の方法を用いて受信者を帯域予約／受信可能な速度別に分類する。受信者および中継ネットワークノードへの問い合わせは、資源予約機能の問い合わせを流用することができる。
（２）マルチキャスト配送開始前に各受信グループ毎に資源予約を行う。帯域予約ができない受信者グループに関しては資源予約は行わない。
（３）各受信グループ別に信頼性のあるマルチキャスト配送処理を適用する。すなわち、各受信端末に到着していないデータが存在する場合には、該送信端末から当該データが正しく届くまで再送を繰り返す。
（４）また、送信端末から各受信端末までのネットワークに、資源予約機能があるものとないものとが混在する場合には、該資源予約機能が利用可能なグループと利用不可能なグループとに受信端末を分類し、該送信端末から各グループに対して別々にデータを送信する。
これにより、データ転送中の再送処理は従来の方式よりも減少するため、再生処理により速度低下を起こすことがなく、信頼性のあるマルチキャスト配送処理を実現できる。
【００１１】
【発明の実施の形態】
以下、本発明の実施例を、図面により詳細に説明する。
図１は、本発明の一実施例を示すマルチキャストデータ配信システムの構成図であり、図６は図１における送信端末の構成図、図７は図１における受信端末の構成図である。
送信端末１１は、データを各受信端末１３〜１５に発信する端末装置であり、中継ネットワーク１２に接続されている。また、受信端末１３〜１５は、送信端末１１から配送されてきたデータを受信する端末装置であり、送信端末１１と同じように中継ネットワーク１２に接続されている。
このうち、送信端末１１は、図６に示すように、送信するデータを記録したデータ蓄積装置３１と、データのマルチキャスト配送処理を制御する配送エンジン３０と、送信端末１１と中継ネットワーク１２との間でデータのやりとりを行うネットワークＩ／Ｆ３６と、データ配送時の資源管理を行う資源管理機構３２とからなる。
【００１２】
図６において、配送エンジン３０は、配送すべきデータを用意して各受信端末１３〜１５に対してデータ配信を行う際の制御を行うモジュールであり、データ送信部３４とグループ管理部３５の２つのプロトコル処理部で構成される。
グループ管理部３５は、各受信端末１３〜１５と資源管理機構３２との間で調停を行い、受信端末の配送グループの制御を行うモジュールである。すなわち、ネットワークＩ／Ｆ３６を介して中継ネットワーク１２に対して行うマルチキャスト配送グループとその予約帯域の制御を行う。
また、資源管理機構３２は、グループ管理部３５に対して資源確保／開放要求を行い、ネットワークＩ／Ｆ３６を介して中継ネットワーク１２に対して資源予約処理を行う。
また、データ送信部３４は、グループ管理部３５のグループ分けに基づいてデータ蓄積装置３１から読み出したデータを各受信端末１３〜１５に配送する処理を行う。すなわち、ネットワークＩ／Ｆ３６を介して中継ネットワーク１２にデータ転送／フロー制御を行う。
データ蓄積装置３１は、送信端末１１が配送するデータを蓄積し、必要に応じてその読み書きを処理するモジュールであって、一般には磁気記憶装置、半導体メモリ等の記録装置とその読み書きを行うインタフェースから構成される。
【００１３】
受信端末１３〜１５は、図７に示すように、受信データを記録するデータ蓄積装置４１と、配送されたデータを受信してデータ蓄積装置４１にデータを蓄積し、データに誤り、抜けがあった場合には再送要求を行う受信エンジン４３と、受信端末１３〜１５と中継ネットワーク１２との間でデータのやりとりを行うネットワークＩ／Ｆ４４と、受信エンジン４３からの資源獲得要求に応じて資源管理を行う資源管理機構４２とからなる。
受信エンジン４３は、ネットワークＩ／Ｆ４４を介して中継ネットワーク１２に対してデータ受信／フロー制御を行い、資源管理機構４２は、ネットワークＩ／Ｆ４４を介して中継ネットワーク１２に対して資源予約処理を行い、また受信エンジン４３に対して資源確保／開放要求を行う。
【００１４】
図１に戻って、中継ネットワーク１２は、送信端末１１と各受信端末１３〜１５との間を接続して相互に通信可能とするネットワークである。また、この中継ネットワーク１２は、送信端末１１から各受信端末１３〜１５の全てまたは部分集合に対するマルチキャスト配信を行うためのデータ複製機能と経路制御と配信に必要となる帯域を予約するための資源予約機構を備えたネットワークである。
このような機能を備えたネットワークの例としては、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）−ＶＣ（Ｖｉｒｔｕａｌ Ｃｉｒｃｉｔ）網、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網＋資源予約プロトコル（ＲＳＶＰ：Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の組み合わせ等を挙げることができる（ＲＳＶＰの参考文献としては、例えば、“Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＲＳＶＰ）”Ｖｅｒｓｉｏｎ１ Ｆｕｎｃｔｉｏｎ， ＲＦＣ ２２０５参照）。以下の説明では、資源予約プロトコルとしてＲＳＶＰを使用した場合の実施例を併記した。
【００１５】
図２は、本発明の一実施例を示す受信端末分類手順のシーケンスチャートであり、図３は、送信端末の送信グループ分類テーブル例を示す図である。
図１に示すマルチキャスト配信システムにおいて、データ配信を行う前に予約可能帯域別に受信端末を分類する処理を、図２に従って行う。また、図２に示す手順を実行する際の送信端末１１の処理を図４のフローに従って端末内で行い、各受信端末における処理を図５のフローに従って端末内で行う。
図３は、送信端末１１のグループ管理部３５が受信端末１３〜１５を送信グループ毎に分類処理するために用いるテーブル（ＳｅｎｄＴＢＬ）である。送信端末１１は、各受信端末１３〜１５を必要帯域に応じたグループＧｒｐＡ０〜Ａｍに分類して、このテーブルに登録して管理する。これらの配送グループは、送信端末１１が配送グループ分類評価関数Ｌ（Ｂｗ（ｘ））により定めたものである。なお、グループＧｒｐＡ０は、帯域予約が不可能または不能な受信端末が属するグループである。図３では、グループＡ０にはＲＡ（３）のみが属し、グループＡ１には、ＲＡ（２）１４のみが属し、グループＡ２にはＲＡ（１）１３、ＲＡ（３）、・・・ＲＡ（ｎ）１５が属し、グループＡｍには、ＲＡ（４），・・・ＲＡ（ｎ１），・・・ＲＡ（ｎ２）が属している。
【００１６】
図２および図４に示すように、本発明のマルチキャスト方式では、先ず送信端末（ＳＡ）１１のグループ管理部３５が各受信端末ＲＡ（１）１３〜ＲＡ（ｎ）１５に対して接続要求（ＣＯＮＮ．Ｒｅｑ（Ｂｗ（ｓ））をネットワークＩ／Ｆ３６より送信する（シーケンス〔Ａ１〕およびステップ１０２）。ここで、Ｂｗ（ｓ）は、送信者が各受信端末１３〜１５および中継ネットワーク１２に対して要求する帯域幅である。回線に対する帯域の要求は、送信端末１１の資源管理機構３２により行われる。なお、ネットワークの資源予約にＲＳＶＰを用いる場合、図２の〔Ａ１〕の段階で送信端末１１の資源管理機構３２は、ＲＳＶＰ Ｐａｔｈ Ｍｅｓｓａｇｅの送信を開始して予約の受付を開始する。ＲＳＶＰ Ｐａｔｈ Ｍｅｓｓａｇｅは、グループ管理部３５が定める図３のテーブルに従って各グループ毎に生成される。
送信端末１１が送信した接続要求ＣＯＮＮ．Ｒｅｑ（Ｂｗ（ｓ））は、中継ネットワーク１２により各受信端末１３〜１５まで配信される。このとき、中継ネットワーク１２は、中継ネットワーク１２内の予約利用可能な資源に応じて、接続要求ＣＯＮＮ．Ｒｅｑの要求帯域幅Ｂｗ（ｓ）を変更してもよい。
（注）Ｂｗ（ｓ）の変更結果は、データ送信前の各受信端末のグループ分けに反映される（図４のステップ１０６）。
【００１７】
各受信端末１３〜１５は、ネットワークＩ／Ｆ４４によりマルチキャスト配送に関するデータを受信すると、そのデータを受信エンジン４３に渡してデータ処理を実行する。図５に示すように、受信端末１３〜１５が接続要求ＣＯＮＮ．Ｒｅｑを受信すると（ステップ２０２）、受信エンジン４３は、受信の可否判断を行い（ステップ２０３）、その結果を送信端末１１に対して受信了承Ｃｏｎｎ．ｏｋ（Ｂｗ（ｘ））（ステップ２０５）、あるいは受信拒否Ｃｏｎｎ．ＮＧ（Ｂｗ（ｘ））（ステップ２０４）として送信する。
図２では、受信了承は〔Ａ２ａ〕で示され、受信拒否は〔Ａ２ｂ〕で示される。ここで、受信了承Ｃｏｎｎ．ｏｋ（Ｂｗ（ｘ））または、受信拒否Ｃｏｎｎ．ＮＧ（Ｂｗ（ｘ））には、接続要求に含まれた帯域情報Ｂｗ（ｘ）が含まれている。また、受信了承Ｃｏｎｎ．ｏｋ（Ｂｗ（ｘ））を送信した受信端末は、送信端末１１からのマルチキャストデータの配信開始まで待機する（ステップ２０６）。
【００１８】
受信了承（図２の〔Ａ２ａ〕）の段階で、受信端末の資源管理機構４２は、中継ネットワーク１２および送信端末１１に対して資源予約要求を行う。例えば、資源予約にＲＳＶＰを使用する場合には、送信端末１１からのＲＳＶＰ Ｐａｔｈ Ｍｅｓｓａｇｅと受信可能な帯域に応じたＲＳＶＰ ｒｅｓｅｒｖａｔｉｏｎ ｒｅｑｕｅｓｔ（Ｒｅｓｖ） Ｍｅｓｓａｇｅを送信する。
受信端末が送信した受信了承Ｃｏｎｎ．ｏｋ（Ｂｗ（ｘ））または受信拒否Ｃｏｎｎ．ＮＧ（Ｂｗ（ｘ））は、中継ネットワーク１２により送信端末１２まで配信される。このとき、中継ネットワーク１２は、中継ネットワーク１２内の予約利用可能な資源に応じて、受信了承Ｃｏｎｎ．ｏｋ（Ｂｗ（ｘ））および受信拒否Ｃｏｎｎ．ＮＧ（Ｂｗ（ｘ））の利用可能帯域情報Ｂｗ（ｘ）を下方修正してもよい。
（注）Ｂｗ（ｓ）の変更結果は、データ送信前の各受信端末のグループ分けに反映される。
【００１９】
図４に示すように、送信端末１１のグループ管理部３５は、各受信端末から受け取った受信了承Ｃｏｎｎ．ｏｋ（Ｂｗ（ｘ））または受信拒否Ｃｏｎｎ．ＮＧ（Ｂｗ（ｘ））に基づいて、各受信端末について以下のような分類を行う（ステップ１０４〜１０７）。
（１）受信拒否Ｃｏｎｎ．ＮＧ（Ｂｗ（ｘ））を発信した受信端末に関しては、マルチキャスト配信不可能とみなしてデータ配信対象から除外する（ステップ１０５）。
（２）受信了承Ｃｏｎｎ．ｏｋ（Ｂｗ（ｘ））を発信した受信端末に関しては、配送グループ分類評価関数Ｌ（Ｂｗ（ｘ））に基づいて分類する（ステップ１０６）。ここで、配送グループ分類評価関数Ｌ（Ｂｗ（ｘ））は、送信端末１１の分類ポリシーに基づいて受信端末１３〜１５の利用可能帯域に対応する送信グループを定める関数であり、利用可能帯域情報Ｂｗ（ｘ）を入力すると、送信グループ番号を出力する。
【００２０】
グループ管理部３５は、分類結果に基づいて図３に示す送信グループ分類テーブルＳｅｎｄＴＢＬに各受信端末を登録する（ステップ１０７）。配送グループ分類評価関数Ｌ（Ｂｗ（ｘ））の実体は、送信者の方針に基づいて定められた帯域幅と各グループの対応テーブル、もしくはＢｗ（ｘ）の各要素を係数に持つ関数である。
送信端末１１は、接続要求ＣＯＮＮ．Ｒｅｑを送信した全受信端末１３〜１５から受信了承Ｃｏｎｎ．ｏｋ（Ｂｗ（ｘ））または受信拒否Ｃｏｎｎ．ＮＧ（Ｂｗ（ｘ））の回答が得られたか（ステップ１０８）、を判定し、一定時間経過しても全受信端末１３〜１５からの回答が得られなかった（タイムアウト）時点で（ステップ１０３）、回答待ちの処理を終了する。このとき、回答が得られなかった端末は、受信拒否＝マルチキャスト配信不能とみなしてデータ配信対象から除外する（ステップ１０９）。
【００２１】
回答待ちを終了した送信端末１１は、送信グループ分類テーブルＳｅｎｄＴＢＬを参照して（ステップ１１０）、送信グループ別にマルチキャストデータ配送を実行する（ステップ１１１，１１２）。帯域予約にＲＳＶＰを使用している場合には、送信端末１１に各受信端末１３〜１５からのＲＳＶＰ Ｒｅｓｖ Ｍｅｓｓａｇｅが届いた時点で帯域予約が完了する。
図２においては、〔Ａ３〕で各グループ毎に（Ｇｒｐ．Ａ１，Ａ２，・・・Ａｍ，（注）ｍ個のグループ）マルチキャストデータ配信を行っている。なお、各受信端末に到着していないデータが存在する場合には、該送信端末から当該データが正しく届くまで再送を繰り返すことにより、信頼性のあるデータ配信を実現することができる。
また、各受信端末１３〜１５までのネットワークに資源予約機能があるもの（例えば、ＲＳＶＰを有するもの）と、ないものとが混在しているネットワークにおいては、受信端末を上記資源予約機能が利用可能なグループと利用不可能なグループとに分けて、各グループに対して送信端末から別々にデータを送信する。
【００２２】
【発明の効果】
以上説明したように、本発明によれば、マルチキャスト配信における再送処理の発生頻度を減少させ、配信処理全体の速度を向上させることが可能になるため、最適状態に安定するまでの調整段階中に配送されたデータに損失が生じて、データ再送処理が発生することがなくなり、また予約可能な帯域が十分にあってもそれを活用できない受信者、および送信速度に対して十分な帯域が確保できない受信者の存在をなくすることができる。
【図面の簡単な説明】
【図１】本発明の一実施例を示すマルチキャストデータ配信システムの構成図である。
【図２】本発明の一実施例を示す受信端末分類手順のシーケンスチャートである。
【図３】本発明の送信端末による送信グループ分類テーブルの構造図である。
【図４】本発明の送信端末における受信端末分類手順のフローチャートである。
【図５】本発明の受信端末における受信端末分類手順のフローチャートである。
【図６】図１における送信端末の構成例を示す図である。
【図７】図１における受信端末の構成例を示す図である。
【図８】従来におけるマルチキャストデータ配信システムの構成例を示す図である。
【符号の説明】
１１…送信端末、１２…中継ネットワーク、１３〜１５…受信端末、
３１…データ蓄積装置、３２…資源管理機構、３０…配送エンジン、
３４…データ送信部、３５…グループ管理部、３６…ネットワークＩ／Ｆ、
４１…データ蓄積装置、４２…資源管理機構、４３…受信エンジン、
４４…ネットワークＩ／Ｆ。

Claims (1)

1. 中継ネットワークノードにより送信データを複製して複数の受信端末に配信するマルチキャストデータ配信方法において、
   送信端末は、データ送信に先立って、全ての受信端末への全ての経路上で予約可能な帯域の大きさを調べ、該予約可能な同一の帯域を予約し、
   該送信端末は予約した帯域に合わせた速度で中継ネットワークにデータを送信し、
   各受信端末に到着していないデータが存在する場合には、該送信端末から当該データが正しく届くまで再送を繰り返すとともに、
   前記送信端末から各受信端末までのネットワークに、資源予約機能があるものとないものとが混在する場合には、該資源予約機能が利用可能なグループと利用不可能なグループとに受信端末を分類し、該送信端末から各グループに対して別々にデータを送信することを特徴とするマルチキャストデータ配信方法。

Images