JP2000324155A - マルチキャスト通信システム - Google Patents

Abstract

(57)【要約】 【課題】多数のユーザに誤りなく確実にデータをマルチ
キャスト送信する場合、送達確認或は再送制御にかかる
送信ホストへの負荷が、軽減できなくなり配信に多大な
時間を要する。またネットワーク回線の部分的な不具合
やトラヒック輻輳が発生して、DVMRPやMOSPFによって作
成されたマルチキャストツリーの一部が不通になること
により、データ配送が不可能になる、あるいは伝送時間
が長大化する等システム全体に悪影響が及ぶ。 【解決手段】マルチキャストデータを送信するホストが
ネットワークの状況に応じて、正常受信のホストを指名
し該指名のホストを含むホストグループを新たに１つ以
上生成あるいは既存のホストグループの構成を変更し、
該指名のホストに該指名のホストが所属する新たな或は
変更した該ホストグループに対する通信処理の一部を行
わせる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークを用
いてデータの配信を行うためのマルチキャスト通信シス
テムの大規模化、高信頼化技術に関する。

【０００２】

【従来の技術】現在特定の複数宛先にデータを配信でき
るマルチキャスト通信に関係する技術として、IETF(Int
ernet Engineering Task Force）にてIGMP（Internet G
roup Management Protocol：RFC2236)がＩＰレベルの標
準として成立している。またマルチキャスト用のアドレ
スの使い方はRFC2356で開示されている。IGMPはマルチ
キャストルータが、マルチキャストデータを効率よく転
送できるように所属するローカルネットワークに該当す
るマルチキャストグループのメンバが存在するか否かを
把握するためのプロトコルである。またIETFのドラフト
レベルではルーティングプロトコルとして、世界規模の
マルチキャスト仮想実験ネットワークのMBONE向けにDVM
RP(Distance Vector Multicast Routing Protocol)及び
MOSPF(Multicast Open Shortest First)がある。どちら
もマルチキャストデータ転送に関するツリーを作成する
ものである。上記技術は、マルチキャストデータの転送
を効率よく行わせるためのものである。

【０００３】マルチキャストの大規模化に関しては、近
年のインタネットのインフラ整備と共に爆発的に利用者
が増加している現状においては、マルチキャストサービ
スに大規模化にも対処できるスケーラビリティを有する
ことが非常に重要となっている。このような状況におい
て、マルチキャスト伝送媒体として親和性が非常に高い
無線回線が着目されつつある。地上波デジタル通信網、
移動体通信網、衛星通信網が次第に整いつつある。特に
広域・高速性を有する衛星回線は大規模マルチキャスト
通信に対処する有力な基盤として注目されている。この
特徴を利用して、本社から広域分散する支社に対しての
社内放送、教育TV放送、画像のダウンロードシステムな
ど、放送型のサービスとして実用化されている。また放
送波の隙間を利用したデータ配信サービスが家庭にまで
浸透しつつある。

【０００４】マルチキャストデータの高信頼化技術とし
て、データの中に誤り訂正符号を加えるものと、再送制
御を行うものがある。再送制御は最も高い信頼性を得る
ことができるため、ファイル配信、プログラムダウンロ
ード、バージョンアップ、企業データの配信には送達確
認による再送制御が採用されている。再送制御技術には
基本となるGO-Back-N方式とSelective Repeat方式があ
る。文献１（藤部、小林、中山著「マルチメディア衛星
通信における高信頼マルチキャスト通信方式の課題と提
案」(信学技報SAT９6−１２７、１９９７−０１）に
は、これらを組合せたり修正した方式も開示されてい
る。さらに再送制御を加えたマルチキャストシステムの
システムスループットの向上を図る方式にも以下に示す
ように、送信制御、送達確認制御及び再送制御のタイミ
ングにより分離される、様々なものがある。

【０００５】送信制御の終了後に送達確認及び再送制
御を行う方法、例えば、文献２（城下、高橋、他３名著
「高信頼マルチキャスト通信プロトコル(RMTP)の各種ネ
ットワークへの適用性」(信学技報ＳＳＥ９５−１９
６，１９９６−０３)で開示されているRMTP）参照。

【０００６】送信制御と送達確認を並行に行い、一通
りデータを送信したあとに再送制御を行う方法、例えば
文献３（米StarBurst社の ＭＦＴＰ；White Paper「An
Efficient，Scalable Method for Distributing Inform
ation Using ＩＰ Ｍｕｌｔｉｃａｓｔ」）、や文献４
（米Ｍｅｎｔａｔ社のXTP4.0；江口著「TCP／IPから見
たXTPプロトコル」雑誌Bit Vol.２８No４，１９９６−
０４）参照。

【０００７】送信制御、送達確認及び再送制御を並行
に行う方法(文献２参照）がある。いずれもIPあるいはU
DPのをベースに行っている。また、送達確認及び再送制
御の送信ホストへの負荷を軽減するために、文献５（
B.N.Levine他１名著「A comparison of known Classes
of Reliable Multicast Protocols」ICNP1996−Oct，Co
lumbus Ohio）には、送達確認或は再送制御タイミング
を時間的に分散させること、正常受信していない送達確
認のみ通知する方法が開示されている。

【０００８】

【発明が解決しようとする課題】例えばインタネットを
利用している数万を越える契約ユーザにゲームソフトな
どのソフトウエアを配信するサービスのように、おびた
だしい数のユーザに誤りなく確実にデータをマルチキャ
スト送信する場合、上記送達確認と再送制御を採用する
ことが重要となる。特に回線品質が高くない無線回線を
利用する際には必須の手段である。このような場合ユー
ザ数が莫大になると、送達確認或は再送制御にかかる送
信ホストへの負荷が、時間的分散などの工夫にかかわら
ず軽減できなくなり配信に多大な時間を要することにな
る。またネットワークの一部の回線の不具合やトラヒッ
ク輻輳が発生する等で、DVMRPやMOSPFによって作成され
たマルチキャストツリーの一部が不通になりデータ配送
が不可能あるいは伝送時間の長大化等システム全体に悪
影響を及ぼすおそれがある。

【０００９】本発明の目的は、上記課題を解決し多数の
ユーザに確実にデータを送信することができる、大規模
なマルチキャスト通信システムを提供することである。
具体的には、（１）送達確認と再送制御にかかる送信ホ
ストの負荷を分散すること、（２）トラヒック輻輳やデ
ータ伝送の滞りを回避すること、（３）ルータ等のネッ
トワーク資源の消費を抑えること、が可能なマルチキャ
スト通信方法とそれを用いたマルチキャスト通信システ
ムと、当該システムを構築するために必要な、個々の通
信装置や、計算機上にこれらの通信装置を実現するプロ
グラムを提供することである。

【００１０】

【課題を解決するための手段】上記目的を達成するため
に、本発明では、マルチキャストデータを送信するホス
トが、ネットワークの状況に応じて、ホストグループ
(マルチキャストグループともいう)の構成を動的に制御
することを特徴とする。他の観点では、送信ホストから
マルチキャストグループを構成するホストまでの経路、
つまりマルチキャストツリーを動的に再構成することを
特徴とする。一般的にツリーを構成するのは、経路制御
機能をもったネットワークノードです。具体的には、ル
ータであったり、gatewayでも、通常のPCでも経路制御
機能があれば構わない。

【００１１】制御の方法として、正常に受信したホスト
を含むように、ホストグループを構成する(例えば、新
たに１つ以上生成するかまたは既存のホストグループの
構成を変更する)ことを特徴とする。さらに、該正常に
受信したホストに、該ホストが所属する新たに生成した
または変更したホストグループ内に対する通信処理の一
部を行わせることを特徴とする。他の観点として、正常
に受信したホストを新たな送信ホストとして、マルチキ
ャストツリーを再構築することを特徴とする。さらに、
本発明のマルチキャスト通信システムにおける、前記指
名されたホストは、受信したデータ送達確認を送信ホス
トに送る手段と、正常に受信できなかったデータの再送
を要求する手段とを備えることを特徴とする。

【００１２】本発明のマルチキャスト通信システムによ
れば、送信ホストの負荷を分散でき大規模なマルチキャ
ストシステムを実現することが可能になる。また一部の
不具合状況にしたがって、ホストグループを再構成し、
前記指名ホストに処理を移すことでトラヒック輻輳、デ
ータ伝送の滞りを回避することが可能になる。すなわ
ち、高信頼化を担う再送制御処理を効率化することがで
き、システム効率の低下を防ぐことが可能になる。ま
た、本発明は、複数のホスト間の経路に無線回線、特に
衛星回線を利用することを特徴とするものである。再構
成したホストグループをルータ等のネットワークノード
を介さずに無線(衛星）回線で直接接続で構成させるこ
とにより、送達確認或は再送制御等の通信処理による影
響を他のネットワークへ及ぼさないこと、他のネットワ
ークからも影響受けないことが可能になり、通信処理の
効率化とシステム効率の低下防止が可能になる。

【００１３】また、本発明は、送信正常に受信できなか
ったデータの再送を要求するシステムにおいて、指名ホ
ストが新たに生成した或は変更した該ホストグループに
マルチキャストで再送を行わせることを特徴とする。ま
た、本発明に用いる通信処理装置は、ネットワークを構
成するノード間で、再構成したホストグループの定義情
報を通知する手段を備え、前記再構成したホストグルー
プに閉じた通信処理を行うことを特徴とする。また、本
発明に用いる通信処理装置は、新たにあるいは変更した
ホストグループを構成するホストとのネットワークコス
トが最小となるような正常受信ホストを選択する手段を
備えることを特徴とする。

【００１４】

【発明の実施の形態】以下、図にしたがって本発明を用
いた実施例を説明する。図１は本発明の概要を説明する
システム構成図である。システムは複数のネットワーク
１２０〜１２７、これらネットワーク間を接続する複数
のルータ１３０〜１３４及びネットワーク１２０〜１２
７とルータ１３０〜１３４からなるネットワークに接続
するホスト１００及び１５０〜１６３からなる。同図で
はホスト１００が配信するマルチキャストデータを有す
る送信ホストを示し、ホスト１５０〜１６３は、該マル
チキャストデータを受け取るマルチキャストグループを
構成していることを示している。グループ１７０及びグ
ループ１７１は本発明にて新たに生成されるホストグル
ープを示す。ここでは、ホスト１００がマルチキャスト
データ１０１を複数のフレームに分割しこのマルチキャ
ストグループのマルチキャストグループアドレスを宛先
アドレスとして、マルチキャストグループに所属するホ
スト１５０〜１６３に送達確認と再送制御をもちいて高
信頼に配信する場合を例として説明する。

【００１５】この場合、ホスト１００は送信したフレー
ムに対してホスト１５０〜１６３から送達確認通知を受
け取り、ホスト１５０〜１６３おのおのに対してフレー
ム単位で未受信と正常受信の状態管理を行う。ここでは
ホスト１５２、１５３、１５４、１６０、１６２、１６
３を、未受信フレームが有り再送を要求する旨の通知を
行ったホスト(以降、未受信ホストと呼ぶ)と仮定し、そ
の他のホストはすべてのフレームを正常受信したホスト
(以降、正常ホストと呼ぶ)と仮定する。この送達確認通
知結果を基に、ホスト１００は正常受信ホストを含め未
受信通知を行ったホスト１５２、１５３、１５４、１６
０、１６２、１６３から新たにホストグループを定義す
る。

【００１６】この図では未受信ホストまでのトータルネ
ットワークコストが小さくなるような方針で、正常ホス
トとしてホスト１５９及び１５１を指名し、それぞれを
含む２つの新たなホストグループ１７０と１７１を定義
している。ホストグループ１７０は指名されたホスト
(以降、指名ホストと呼ぶ)１５９、未受信ホスト１６
０、１６２、１６３で構成し、ホストグループ１７１は
指名ホスト１５１、未受信ホスト１５２、１５３、１５
４で構成する。

【００１７】ホスト１００は、定義した新たなホストグ
ループにそれぞれ新たなマルチキャストアドレスを付与
しグループの定義情報と共に制御データとして、再送開
始までにマルチキャストデータのフレーム送信と並行し
て送信し、ホスト１５０〜１６３に通知する。

【００１８】前記定義情報に関わるホスト１５１、１５
２、１５３、１５４、１５９、１６０、１６２、１６３
はそれぞれ通知された定義情報を受信する。ホスト１５
１はホストグループ１７１、ホスト１５９はホストグル
ープ１７０の指名ホストであることを認識する。

【００１９】指名ホスト１５１、１５９は、それぞれホ
ストグループ１７１、ホストグループ１７０の再送制御
のマスタとなり、ホストグループ１７１及び１７０それ
ぞれ付与されたマルチキャストアドレスを付けて必要な
フレーム１８０及び１８１を再送する。再送制御が終了
するとその旨をホスト１００へ通知する。

【００２０】このように受信状況及びトラヒック状況に
応じて、再送のために必要なホストグループを指名ホス
トともに一時的に定義して再送制御をローカルで行うこ
とで再送処理を分散し、大規模な高信頼マルチキャスト
サービスへ対処が可能となる。またローカルに閉じた通
信処理を行うことで、ホスト１００から再送する場合に
比べ、未受信ホストから遠いネットワーク或はルータ等
のネットワーク資源の消費を抑えること、すなわち、再
送フレームのトラヒック増加による悪影響を抑えること
ができる。

【００２１】次に図２を用いて、広域・同報性を有し大
規模なマルチキャスト通信に非常に有効な伝送媒体であ
る衛星回線を利用する場合の実施例を説明する。図２に
おいて、２００は通信衛星、２１０、２２０〜２３４は
衛星回線にデータを変換し送受信を行う地球局装置、２
１１、２４０〜２４７及び２９０〜２９５はそれぞれ地
球局装置２２０〜２３４に接続しデータの処理を行うホ
ストを示す。ここでは、マルチキャストデータを有する
ホスト２１１が、地球局装置２１０、通信衛星２００を
介して衛星回線２１２にてマルチキャストグループ２５
０を構成するホスト２４０〜２４７及び２９０〜２９５
にマルチキャストデータを配信する場合を説明する。

【００２２】上記と同様にデータをフレームに分割して
マルチキャストグループ２５０のグループアドレスを付
して同報する。マルチキャストグループ２５０の構成ホ
ストは送達確認をホスト２１１にユニキャストで返信す
る。この送達確認を基にホスト２４０〜２４７及び２９
０〜２９５の受信状態を把握して、新たなホストグルー
プ２７０と２８０を定義する。ここでは、未受信ホスト
がホスト２９０〜２９５であり、これら以外のホストは
正常ホストである。指名ホストは正常ホスト２４６及び
２４７である。ホストグループの定義は、受信状況をみ
て以下の基準で行うことが考えられる。

【００２３】（１）フレーム未受信率が同一（定義は後
述する）のホストを同一グループとする （２）フレーム未受信パターンが同一（定義は後述す
る）のホストを同一グループとする （３）同一の地域のホストを同一グループとする 指名ホストの選択は、出来るだけ上記生成したホストグ
ループに物理的に近いことを基準とする等が考えられ
る。

【００２４】指名ホスト２４６はホストグループ２７０
を、指名ホスト２４７はホストグループ２８０の再送制
御を担う。指名ホスト２４６は再送フレーム２７１を、
指名ホスト２４７は再送フレーム２８１を、通信衛星２
００を介してそれぞれのホストグループ２７０及び２８
０の未受信ホストへ送信する。以下では上記従来の技術
にて示している、送信制御と送達確認を並行に行い一通
りデータを送信したあとに再送制御を行う方法での実施
例を説明する。

【００２５】図３に本実施例でのシーケンスを示す。図
３（１）は送信制御と送達確認を並行に行うシーケンス
を、図３（２）は再送制御のシーケンス例を示す。図３
（１）ではホスト２４０、２９０、２９５がマルチキャ
ストでデータを受信しているところを示している。３０
１〜３０９はマルチキャストデータのフレームを、６フ
レームで１つのブロックを定義している。ブロック毎に
受信したホストが未受信のみの送達確認を行っている。
受信したホストがそれぞれブロック終了毎にタイマーを
作動させランダム時間経過後に送達確認を送信してい
る。

【００２６】なお、並行に行うとは、マルチキャストデ
ータを、例えばフレーム単位で受信しながら同時にこれ
まで受信したデータフレームに対する受信状況(送達確
認)を送ることを意味している。受信状況を送るタイミ
ングは採用する送達確認方法に従って任意に選択できる
ものである。例えば、ウインドウサイズ分ごとに送達確
認するとか、ある受信データ量ごとに送達確認する等の
方法が可能である。また、送信制御とは、再送も含めて
マルチキャストデータを送信することである。送達確認
とは、マルチキャストデータに対する受信状況を送信側
に通達することで、マルチキャストデータに対する正常
受信かエラー受信かを送信側が認識することである。

【００２７】未受信フレームがあることを通知するＮＡ
ＣＫ(Ｘ，Ｙ）フレームにおけるＸはホストの識別子
を、Ｙは未受信フレーム番号で未受信フレームを通知す
る。図ではホスト２９０はフレーム番号２のフレームが
未受信であることを、ホスト２９５はフレーム番号６と
７が未受信であることを通知している。図３（２）で
は、（１）のシーケンスが一通り終了し、ホスト２１１
が受信状況から新たにホストグループ２７０及び２８０
を生成し、そのうちホストグループ２８０における指名
ホスト２４７からホスト２９５へマルチキャストでフレ
ーム６及び７の再送を実施している様子を示している。

【００２８】図４は、図３のシーケンスを実行する主要
な装置の構成例を示したものである。この図において、
通信衛星と送受信を行う地球局装置２１０、２３５、２
２７には、それぞれ本発明を実行する通信処理装置４０
０が接続されている。さらに前記通信処理装置にはそれ
ぞれ、ホスト２１１、２９５、２４７が接続されてい
る。もちろん通信処理装置はホストの中で実現すること
も可能であるが、発明説明を明確にするために分離し
た。ホスト２４７はこの例では指名ホストとなるもので
ある。

【００２９】図５は図３のマルチキャスト手順を実行す
る通信処理装置４００の構成を示すブロック図である。
ＣＰＵ５００は、マルチキャスト通信制御等の各種の通
信処理プログラムをＲＯＭ５１０から呼び出して実行す
る。ＲＡＭ５２０は、受信状態管理表など本発明実施の
上で参照される情報を一時保存する制御情報記憶手段で
ある。Ｉ／Ｆ回路５３０は地球局装置との接続を行い入
出力バッファ５６０に一時的に入出力データを記憶す
る。Ｉ／Ｆ回路５４０はホストとの接続を行い入出力バ
ッファ５７０で一時的に入出力データを記憶する。

【００３０】Ｉ／Ｆ回路５５０は他のネットワークとの
接続を行い入出力バッファ５８０で一時的に入出力デー
タを記憶する。ＣＰＵ５００は入出力バッファを監視し
ている。これにより、接続するホストあるいはネットワ
ークからのデータを入出力バッファを介して通信する。
ここでは一般的なインタネットプロトコルであるＴＣＰ
／ＩＰ(Transmission Control Protocol ／Internet Pr
otocol）でホスト或はネットワークと通信する場合で説
明する。また地球局装置とはＩＰベースの上に、マルチ
キャスト用の下記に説明するプロトコルを実施する。

【００３１】図６はＩＥＴＦで標準化されておりインタ
ネット等で利用されているＩＰパケット６００を示す。
ＩＰパケット６００は通常２０バイトのＩＰヘッダ部と
ＩＰデータ部６２０からなる。マルチキャストデータは
このＩＰデータ部６２０で運ばれる。通信処理装置４０
０はホスト或はネットワークで図６のフォーマットでや
り取りするデータを入出力バッファに蓄え、ＩＰデータ
６２０を取り出し、フレームサイズに分割し、新たに制
御情報を加え再度ＩＰパケット化を行いＩ／Ｆ回路５３
０へ出力する。

【００３２】図７は上記Ｉ／Ｆ回路５３０を介して衛星
回線へ送信するために再度組み立てられたＩＰパケット
７００のフォーマットを示す。ＩＰパケット７００は標
準の２０バイトのＩＰヘッダ部７１０とＩＰデータ部７
２０からなり、ＩＰデータ部７２０には通信処理装置４
００で作成したフレームセグメント７７０が格納され
る。ＩＰデータ部７２０はフレームヘッダ部７３０とフ
レームデータ部７５０からなる。フレームデータ部７５
０にはユーザデータ或は制御情報が格納される。

【００３３】フレームヘッダ部７３０はユーザデータ／
制御データの識別を行うデータフレームと制御フレーム
を示すフレームタイプ７３１、送信元ポート番号７３
２、宛先ポート番号７３３、フレームシーケンス番号７
３４、ブロックの開始と終了のためブロック識別子７３
５、マルチキャストアプリケーションを識別するＩＰマ
ルチキャストアドレス７３６、フレームが正常に到着し
たことを確認するチェックサム７３７からなる。制御フ
レームには、例えば、後述するようにマルチキャストデ
ータを送信する側から送るホストグループ定義のための
フレームや受信する側の送達確認通知等、今回の発明に
関わる制御情報を伝達するフレームである。データフレ
ームは、マルチキャストデータを送信するためのフレー
ムである。

【００３４】まず、マルチキャストデータの送信元とな
るホスト２１１に接続する通信処理装置４００のデータ
送信処理手順を図５〜図７を利用して図８のフローチャ
ートで説明する。ステップ８０１で入出力バッファ５７
０のＩＰパケット６００をチェックして、ステップ８０
２でＩＰマルチキャストデータであるかをＩＰヘッダの
宛先ＩＰアドレスで判断する。インタネット標準の仕様
では、クラスＤのＩＰアドレスをマルチキャスト用に定
義しており、先頭４ビットが「１１１０」(１０進法で
は２２４）となっている。

【００３５】図２では、マルチキャストグループ２５０
用にマルチキャストアドレスが割当てられている。この
マルチキャストアドレスは、標準ではクラスＤのうちパ
ブリックに割り当てられている２２４.０.１.０〜２３
８.２５５.２５５.２５５のいづれかである。或は１つ
の団体で閉じている場合だと、ローカルに割り当てられ
ている２３９.０.０.０〜２３９.２５５.２５５.２５５
が利用できる。ステップ８０２で通常のユニキャストＩ
Ｐアドレスであると入出力バッファ５７０のＩＰパケッ
トをステップ８０９で取り出してそのままステップ８０
８で入出力バッファ５６０へ送信する。

【００３６】ステップ８０２でマルチキャストデータで
あると判断すると、ステップ８０３でＩＰパケット６０
０を取り出してデカプセルする。ステップ８０４でデカ
プセル後のＩＰデータ６２０をフレームに分割する。必
ずしも１つのＩＰデータからフレームを作成するわけで
はなく、複数ＩＰデータで１つのフレームを構成するこ
ともある。ステップ８０５でフレームヘッダの作成を行
う。フレームヘッダは図７で示したが、フレームタイプ
７３１をユーザデータタイプとし、ホスト２１１から受
け継いだ送信元ポート番号７３２、宛先ポート番号７３
３、そしてシーケンス番号７３４は分割したフレーム番
号を付する。ブロック番号７３５は先頭及び終わりのフ
レームに付する。

【００３７】ＩＰマルチキャストアドレス７３６は、今
回のマルチキャストアプリケーションを識別するため、
前記ＩＰマルチキャストアドレスを付ける。ステップ８
０６でステップ８０４でのフレームデータにステップ８
０５のフレームヘッダからをフレームを組み立て、ステ
ップ８０７でステップ８０３でデカプセル化後のＩＰヘ
ッダ６１０でステップ８０６のフレームをカプセル化し
て、ステップ８０８で入出力バッファ５６０へ送信す
る。以上がデータ送信処理の動作である。なおここで
は、通信制御装置４００がホストのＩＰマルチキャスト
及びＩＰアドレスを管理しているものとして説明してい
る。

【００３８】次に送信するホスト２１１に接続する通信
処理装置４００の受信処理手順を説明するがその前に使
用する制御フレームについて示しておく。図９はマルチ
キャストデータを受信するマルチキャストグループ２５
０を構成するホスト２４０〜２４７及び２９０〜２９５
の通信処理装置４００が衛星回線を介して返す未受信送
達確認のフレーム（ＮＡＣＫフレームと呼ぶ）の制御情
報９００である。ＮＡＣＫフレームは図７で説明したフ
レームヘッダ７３０のフレームタイプが制御データのＮ
ＡＣＫ通知であることの識別子を付けた制御フレームで
あり、フレームデータ部７５０には図９で示す未受信の
フレームシーケンス番号の先頭と末尾をペアにしたもの
である。

【００３９】図１０は送信側通信処理装置４００が受信
側の通信処理装置４００へ送る制御フレームであるホス
トグループ通知フレームのフレームデータ部７５０の制
御情報１０００を示す。制御情報１０００は１つのホス
トグループ毎にホストグループのＩＰマルチキャストア
ドレス１００１、指名ホストのＩＰアドレス１００２、
構成するホストのＩＰアドレス１００３、１００４、及
びこのホストグループ１０１０の構成において未受信フ
レームのシーケンス番号の先頭１００５及び末尾１００
６からなる。ここで新たに割当てるＩＰマルチキャスト
アドレスはプライベートに割当てるローカルなものであ
る。従ってローカルに割り当てられている２３９.１９
２.０.０〜２３９.２５１.２５５.２５５の中から割当
てる。

【００４０】上記制御情報１０００は、定義されたホス
トグループ構成に基づくものであり、送信ホストがこの
ホストグループ構成定義情報を保存する。また、指名ホ
ストにおいても、任された新たなホストグループに係わ
る構成定義情報たとえばホストIPアドレスを同様の情報
として保存する。さらに各構成ホストにおいても、指名
ホストIPアドレスを保存する。

【００４１】図１１は、マルチキャスト送信側の通信処
理装置４００がＲＡＭ５２０で管理する受信状態管理表
１１００を示す。受信状態管理表１１００は受信のホス
トＩＤ１１０１と未受信フレーム番号１１０２からな
り、通信処理装置毎で未受信フレーム番号が管理されて
いる。以上のフレームを利用して、図１２で送信側の通
信処理装置４００の受信処理手順を説明する。

【００４２】ここで、前述のフレーム未受信率、フレー
ム未受信パターンについて本発明における定義を例示す
る。

【００４３】各受信ホストのフレームの未受信率は、例
えば、データの全フレーム数を dtとすると、 フレーム未受信率＝ホストの未受信フレーム数／dt で定義される。未受信フレーム数は、図１１の表を基に
受信ホスト毎にカウントする。ホスト２９０であれば、
A-F-1からA-F-Nの数を累計したものになる。フレーム未
受信率があらかじめ設定した誤差の範囲内に収まる場合
に「フレーム未受信率が等しい」と定義する。

【００４４】フレーム未受信のパターンは、図１１でま
とめてある各受信ホストの未受信フレームのうち、他の
ホストと比較してフレーム番号が一致する率を算出した
もので以下のように定義する。以下の式は、ホスト290
をホスト291と比較した一致率を示す。この一致率があ
らかじめ設定した範囲内に収まる場合を「フレーム未受
信パターンが同じ」とみなす。

【００４５】一致率(ホスト290→ホスト291)＝ホスト29
1とフレーム番号が一致した数／ホスト290のフレーム未
受信数 図１２のステップ１２０１でＮＡＣＫフレームを格納す
るＩＰパケットを受信すると、ＩＰヘッダ６１０の送信
ＩＰアドレス７１１と図９で示す未受信フレーム番号を
読み取り、ステップ１２０２で受信状態管理表１１００
を更新する。図３のシーケンスでは、ホスト２９０から
未受信フレーム先頭番号＝未受信フレーム末尾番号＝２
のＮＡＣＫフレームが、ホスト２９５からは未受信フレ
ーム先頭番号＝６、未受信フレーム末尾番号＝７のＮＡ
ＣＫフレームを受信していることを示す。

【００４６】ステップ１２０３で新たなホストグループ
定義通知を行うタイミングか否かを判断する。判断の方
法としてはいろいろな場合が想定されるが、例えばマ
ルチキャストデータの送信が全て完了する数ブロック前
をタイミングとして定期的に通知する、マルチキャス
トデータ送信完了後タイミングで数回通知する等があ
る。未受信フレーム数が規定以上に多いホストグループ
の場合には天候等による回線品質の低下の可能性がある
ため一定の時間後に再送するように指示する。指名ホス
トへのホストグループ定義通知を行うタイミングでなけ
ればステップ１２０１へ戻る。

【００４７】ステップ１２０４で、受信状態管理表１１
００から、前記で示したホストグループ定義基準に従っ
てグループ構成ホスト及び指名ホストを決定する。

【００４８】図２では新たなホストグループ２７０が指
名ホスト２４６、未受信ホスト２９０〜２９２で、ホス
トグループ２８０が指名ホスト２４７、未受信ホスト２
９３〜２９５で構成定義したものである。ステップ１２
０５ではこの定義をもとに、ホストグループ通知フレー
ムのフレームデータ部７５０の制御情報１０００を作成
しマルチキャストグループ２５０のＩＰマルチキャスト
アドレスを宛先ＩＰアドレスとしたＩＰヘッダでカプセ
ル化する。ステップ１２０６でこのＩＰカプセル化した
制御フレームを入出力バッファ５６０へ送信する。

【００４９】図１３は通信処理装置４００のＲＡＭ５２
０で管理しているアプリケーション毎のＩＰマルチキャ
スト対応表を示したものである。これによりアプリケー
ション毎のホストグループを管理している。ここでは３
つのマルチキャストを利用するアプリケーション毎のＩ
Ｐマルチキャスト対応表１３００、１３１０、１３２０
である。

【００５０】図１４はプライベートＩＰマルチキャスト
管理表１４００を示したものである。この表は例えば企
業が利用する場合であれば、企業内に１つこの表を管理
するマスタサーバを立ち上げて管理していくものであ
る。プライベートＩＰマルチキャスト管理表１４００へ
必要なホストは登録してプライベートＩＰマルチキャス
トを取得する。利用できるプライベートＩＰマルチキャ
ストは、ＩＥＴＦでローカルに割り当てられている２３
９.１９２.０.０〜２３９.２５１.２５５.２５５を利用
する。プライベートＩＰマルチキャスト管理表１４００
は取得元のホストＩＰアドレスが記載されている。未使
用だと０.０.０.０となっている。

【００５１】図１５でマルチキャストグループ２５０を
構成するホストのうち、指名ホストとなるホスト２４６
及びホスト２４７に接続する通信処理装置４００の処理
手順を説明する。ここでは特に指名ホストとして特有の
手順のみについて記す。

【００５２】ステップ１５００でを入出力バッファ５６
０からホストグループ通知フレームを格納するＩＰパケ
ットを受信すると、ステップ１５０１で自ホストのＩＰ
アドレスが指名ホストとして記されているかを判断す
る。記されてなければ終了。ステップ１５０２で指名ホ
ストであることを認識すると再送タイミングであるかを
判断する。再送タイミングにもマルチキャストシステム
によって決定される。図３のシーケンスでは再送タイミ
ングは送信のホストから与えられる。再送タイミングで
なければステップ１５００へ戻る。

【００５３】ステップ１５０３でホストグループ通知フ
レームで指示された再送のフレームを自ホストが新たに
担当するホストグループのプライベートＩＰマルチキャ
ストアドレスをＩＰヘッダ６１０の宛先ＩＰアドレス７
１２に、自ホストＩＰアドレスを送信元ＩＰアドレス７
１１にして、ＩＰ化して再送する。図３のホストグルー
プ２８０の指名ホスト２４７だとフレーム６及び７を再
送する。

【００５４】ステップ１５０４で所属するホストグルー
プの未受信ホストからのＮＡＣＫフレームを受信したか
否かを判断する。受信しなければステップ１５０５でマ
ルチキャストデータの送信ホストに向けて再送完了フレ
ーム１６００を作成し、ＩＰヘッダ６１０の送信元ＩＰ
アドレスに自ホストＩＰアドレスを、宛先ＩＰアドレス
には送信ホスト２１１のＩＰアドレスにしてＩＰ化して
入出力バッファ５６０へ送信する。ここで再送完了フレ
ーム１６００は図１６に示すとおりである。フレームタ
イプ７３１を再送完了フレームタイプに、フレームデー
タ部７５０の制御情報として所属するプライベートＩＰ
マルチキャストアドレス１６１０を、それ以降に完了し
た再送フレームのシーケンス番号の先頭１６２０と末尾
１６２１を格納したものある。

【００５５】図１７に未受信ホストの通信処理装置４０
０の処理手順を示す。ここでは特にＮＡＣＫフレームを
送信した以降の手順について記す。ステップ１７０１で
ホストグループ通知フレームを受信すると、ステップ１
７０２で該ホストグループ通知フレームの制御情報１０
００をチェックして、受信ホストＩＰアドレス１００２
に自ホストのＩＰアドレスを探して、指定された所属の
プライベートＩＰマルチキャストアドレス１００１及び
指名ホストのＩＰアドレスをＲＡＭ５２０に記憶する。

【００５６】ステップ１７０３で受信した再送フレーム
が自ホストの未受信マルチキャストフレームであるかを
判断し、未受信マルチキャストフレームでなければ待ち
状態となる。ステップ１７０４で正常に再送フレームを
受信していれば終了となるが、正常受信してなければス
テップ１７０５でＮＡＣＫフレームの制御情報９００に
未受信フレームシーケンス番号の先頭９１０と末尾９２
０をセットしてＩＰパケット化する。ＩＰヘッダの宛先
ＩＰアドレスには再送元の指名ホストＩＰアドレスをセ
ットして入出力バッファ５６０に送信する。

【００５７】他の実施例として、送信制御の終了後に送
達確認及び再送制御を行う方法でマルチキャストを行う
方法も考えられる。この方法では、送達確認通知をマル
チキャストデータの送信後に行うことから、マルチキャ
ストデータを受信するホストの通信処理装置４００の送
達確認通知のタイミングを変更することで実現され、本
発明に関わる処理としては同じである。

【００５８】第３の実施例として、図１８で示すように
送信制御、送達確認及び再送制御を並行に行う方法につ
いて説明する。この場合は、一通りのマルチキャストデ
ータの送信を完了しなくてもＮＡＣＫフレームに対する
再送を行うことから、通信処理装置４００の処理手順が
次のように異なる。

【００５９】まずマルチキャストデータを送信するホス
ト２１１の通信処理装置４００のホストグループ通知フ
レームの送信がより頻繁に行われる。さらに該ホストグ
ループ通知フレームタイミング毎にホストグループが異
なることがある。このため該ホストグループ通知フレー
ムにてホストグループの動的変更が行われる。つまり、
前回の該ホストグループ通知フレームの通知から今回の
該ホストグループ通知フレーム通知のあいだに受信する
ＮＡＣＫの状況が大きく変化する際にホストグループの
構成変更が発生し、図１２で示したステップ１２０３の
判断が前記と異なる。これに伴い指名ホストとなる受信
ホストにおいても所属するホストグループ変更が図１５
で説明した処理で頻繁に行われる。受信ホストにおいて
も所属するホストグループ及び指名ホストの変更が図１
７で示した処理で頻繁に行われるようになる。受信ホス
ト側の本発明に関わる通信処理装置４００の基本処理手
順に変更はない。

【００６０】次に指名ホストが予め決められ、送達確認
及び再送制御を指名ホストに実施させる場合のマルチキ
ャストシステムの実施例について説明する。図１９にシ
ステム構成を示す。この図において、送信ホスト１９０
０は衛星通信用の地球局装置１９０１９０７を介してマ
ルチキャストグループ１９０２を構成するホスト１９１
０、１９２０、１９３０、１９４０、１９５０、１９６
０、１９７０、１９９０へマルチキャストデータを送信
する。予めホストグループ１９０３、１９０４、１９０
５が定義されている。ホストグループ１９０３は、ホス
ト１９２０、１９４０、１９５０からなりホスト１９４
０が指名ホストである。ホストグループ１９０４は、ホ
スト１９１０、１９３０、１９６０からなりホスト１９
１０が指名ホストである。ホストグループ１９０５は、
ホスト１９７０、１９８０、１９９０からなりホスト１
９９０が指名ホストである。

【００６１】各指名ホストは、所属するホストグループ
の他のホストからの送達確認通知を集計して、送信ホス
ト１９００へ各ホストグループの受信状態を通知する。
例えば指名ホスト１９４０はホストグループ１９０３の
ホスト１９２０、１９５０の送達確認通知を受取り集計
して、受信集計フレームとしてホスト１９００へ送る。

【００６２】図２０に受信集計フレームの制御情報２０
００のフォーマットを示す。制御情報はホストグループ
ＩＤ２０１０、受信ホストＩＰアドレス２０２０及び該
受信ホストの未受信フレームシーケンス番号の先頭２０
３０及び末尾２０４０からなる。送信ホスト１９００は
マルチキャストデータの送信を完了し各指名ホストから
送られた受信集計フレームから受信状態管理表１１００
を作成する。この後システムは再送制御動作に移行す
る。

【００６３】つぎに、未受信ホストとしてホスト１９２
０とホスト１９３０を想定して、受信状態管理表１１０
０に基づいて現状のホストグループの構成を変更して再
送制御を指名ホストに実施させる例を説明する。図１９
で、送信ホストはホスト１９１０を指名ホストに選び、
未受信ホスト１９２０及び１９３０でホストグループ１
９０６を定義し、ホストグループ通知フレーム１０００
で通知する。指名ホストに選ばれたホスト１９１０は、
新たなホストグループ１９０６用のプライベートＩＰマ
ルチキャストアドレスで再送制御を行い完了すると図１
６で示した制御情報の再送完了フレームを送信ホスト１
９００へ送信する。

【００６４】本実施例のように再送制御時に動的にホス
トグループを変更することで、受信正常ホストは未受信
ホストの影響を受けずにマルチキャストデータの受信が
可能となる。必要なホストのみで新たにホストグループ
を構成することで再送処理を効率化が図れる。

【００６５】次に本発明を地上回線に適用する場合の実
現構成について説明する。図１で説明したように地上で
は衛星回線と異なりマルチキャストデータを配信するた
めにはマルチキャストツリー上の複数のネットワークを
通過しなくてはならない。ツリーの構成要素であるネッ
トワークノードは具体的には、ルータ、gateway、また
は経路制御機能をもった計算機などが相当し、通常ネッ
トワークノードとしてルータが用いられている。これら
のルータから構成されるネットワークにおいて、マルチ
キャストを実施する場合インタネットでは従来の技術で
説明したようにＩＧＭＰ、ＤＶＭＲＰやＭＯＳＰＦが利
用されている。

【００６６】これらの技術をもとに本発明の動的なマル
チキャストを実現するために、図２１で示すようなＩＧ
ＭＰメッセージを拡張したフォーマットの制御情報をマ
ルチキャスト対応のルータ間でやり取りさせる。図２１
にＩＧＭＰメッセージの未使用領域にサブタイプ２１３
０を設けホストグループ通知メッセージの識別子を入れ
た例を示す。チェックサム２１４０の後にパブリックな
ＩＰマルチキャストアドレス２１５０と該ＩＰマルチキ
ャストアドレス２１５０のなかで一時的に動的に定義す
るプライベートＩＰマルチキャストアドレス２１６０と
指名ホストＩＰアドレス２１７０及びプライベートＩＰ
マルチキャストアドレス２１６０で構成するホストのＩ
Ｐアドレス２１８０、２１９０で構成される。

【００６７】図２２にルータ２２００の構成を示す。Ｃ
ＰＵ２２１０は、ＲＯＭ２２２０のルーティング処理ソ
フトを実行し、ＲＡＭ２２３０のルーティングテーブル
を参照しながら、受信したＩＰパケットを、インタフェ
ース回路２２４０、２２５０、２２６０のうち、ＩＰパ
ケットを受信したインタフェース以外に送出する。

【００６８】図２３で本発明に係わるルータの処理手順
を説明する。ステップ２３０１でホストグループ通知メ
ッセージ２１００の受信を行うと、ステップ２３０２で
プライベートＩＰマルチキャストグループを構成する指
名ホストＩＰアドレス２１７０、ホストＩＰアドレス２
１８０、２１９０をチェックする。ステップ２３０３
で、自ルータのルーティングテーブルを参照して配下に
ある１つのインタフェースのネットワークに、プライベ
ートＩＰマルチキャストグループを構成するホストが全
て接続されているか否かを判断する。全て接続されてい
ればステップ２３０４にて、受信したホストグループ通
知メッセージ２１００を接続されているネットワークへ
のインタフェースへ送出する。そうでなければステップ
２３０５で、自ルータのルーティングテーブルヘプライ
ベートＩＰマルチキャストアドレス及び構成ホストを登
録して、ステップ２３０６で指名ルータ及び構成ホスト
へのインタフェースに該受信したホストグループ通知メ
ッセージ２１００を送出する。図２３の動作により、指
名ホストの担当のプライベートＩＰマルチキャストグル
ープの中だけでプライベートＩＰマルチキャストアドレ
スによる通信処理が行われる。

【００６９】次に受信ホストが移動しても動的にホスト
グループを変更させることで容易にマルチキャストデー
タを受信させる実施例について説明する。このようにホ
スト移動が伴う場合には衛星回線のような広域をカバー
する無線回線が非常に有利となるが、図１の地上回線で
も対応可能である。ここでは図２４にて衛星回線を利用
するマルチキャストシステムの受信ホストが他の地球局
装置の配下に移動したときの動作を説明する。

【００７０】この図では、送信ホスト２４０２が、通信
処理装置２４００、地球局装置２４０１、衛星回線２４
８０を経て、マルチキャストグループ２４７０を構成す
る受信ホスト２４１２、２４１３、２４２２、２４２
３、２４２４、２４３２、２４３３にマルチキャストデ
ータを送信する例を示す。受信ホスト２４１２、２４１
３は通信処理装置４００に、受信ホスト２４２２、２４
２３、２４２４は通信処理装置４００に、受信ホスト２
４３２、２４３３は通信処理装置４００に、それぞれLA
N(Local Area Network)２４１９によって接続されてい
る。地球局装置２４２０配下の受信ホスト２４２３が地
球局装置２４４０配下のＬＡＮ２４４１へ移動する場
合、通信処理装置２４００は以下のように動的にマルチ
キャストグループ構成を変更する。

【００７１】すなわち、移動するホスト２４２３は、通
信処理装置２４４０の配下に移動すると、図７で説明し
た制御フレームの一つである移動通知フレームをLAN２
４４９から通信処理装置４００と衛星回線２４９０を介
した送信ホスト２４０２の通信処理装置４００へ通知す
る。移動通知フレームのフレームデータ部７５０には制
御情報としてユニークな自ホストID(MAC［Media Access
Control］アドレスでも可能)、新たに割付けられたホ
ストIPアドレスが格納されている。ホストIPアドレスが
パブリックなものであれば、ユニークな自ホストIDとし
て利用することもできる。この該移動通知フレームを受
信した受信ホスト２４２３の通信処理装置４００は新た
にルーティングテーブルのネットワーク構成テーブルに
受信ホスト２４２３のIPアドレスを追加する。

【００７２】また送信ホスト２４０２側の通信処理装置
４００は該移動通知フレームを受信すると、これまでの
マルチキャストグループ２４７０の構成ホストへのデー
タ配信を持続させるため、これまでのマルチキャストグ
ループ２４６０を変更して、地球局２４４１への衛星回
線２４９０の接続を含むようにマルチキャストグループ
２４６０を定義する。この新たな定義は図１３で示した
IPマルチキャスト対応表の受信ホストIPアドレスを更新
することでなされる。このように衛星回線のような無線
回線を利用すると、受信ホストが移動しても移動先まで
のネットワークコストを増加させないで新たなマルチキ
ャストグループを定義できるため、移動体に容易に対応
できる。

【００７３】上記実施例は、衛星通信網を前提に説明し
たが、その他のマルチキャスト伝送媒体である地上波デ
ジタル通信網、移動体通信網にも適用可能である。

【００７４】以上のように、本発明によれば、送信ホス
トの負荷を分散でき大規模なマルチキャストシステムの
実現が可能になる。また一部の不具合状況にしたがっ
て、ホストグループを再構成し、前記ホストグループに
属する指名ホストに任すことでトラヒック輻輳、データ
伝送の滞りを回避することが可能になる。

【００７５】また、再構成したホストグループをルータ
等のネットワークノードを介さずに無線(衛星）回線で
直接接続で構成させることが可能になる。また、送達確
認或は再送制御等の通信処理による影響を他のネットワ
ークへ及ぼさないこと、他のネットワークからも影響受
けないことが可能になり、通信処理の効率化とシステム
効率の低下防止が可能になる。

【００７６】

【発明の効果】以上のように、本発明によれば、（１）
送信ホストの負荷を分散して大規模なマルチキャストシ
ステムを実現できる、（２）トラヒック輻輳やデータ伝
送の滞りを回避することができる、（３）ルータ等のネ
ットワーク資源の消費を抑えることができる、（４）通
信処理の効率向上とシステム効率の低下防止を防ぐこと
ができる、という効果がある

【図面の簡単な説明】

【図１】本発明の概要を説明するシステム構成図であ
る。

【図２】本発明を衛星回線を利用したネットワークに適
用した実施例の概要を説明する図である。

【図３】本発明の衛星回線利用による具体的実施例を示
すシーケンス図である。

【図４】図３のシーケンスを実行するシステム構成例を
示す図である。

【図５】本発明を実行する通信処理装置の構成図であ
る。

【図６】ＩＥＴＦで標準化されているＩＰパケットのフ
ォーマット図である。

【図７】本発明の実施例で用いるフレームのフォーマッ
ト図である。

【図８】実施例のマルチキャストデータを送信するホス
トの通信処理装置の送信処理手順を説明するフロー図で
ある。

【図９】未受信フレームを通知するＮＡＣＫフレームの
制御情報フォーマット図である。

【図１０】新たなホストグループの通知を行うホストグ
ループ通知フレームの制御情報フォーマット図である。

【図１１】送信ホストに接続する通信処理装置が管理す
る受信状態管理表である。

【図１２】送信ホストに接続する通信処理装置のホスト
グループ定義及び通知の処理手順を説明するフロー図で
ある。

【図１３】送信ホストが管理するＩＰマルチキャスト対
応表である。

【図１４】プライベートＩＰマルチキャストアドレス管
理表である。

【図１５】指名ホストに接続する通信処理装置の本発明
に係わる処理手順を説明する図である。

【図１６】図３の実施例で利用する再送完了フレームの
制御情報フォーマット図である。

【図１７】未受信ホストに接続する通信処理装置の再送
制御に係わる処理手順を説明する図である。

【図１８】衛星回線利用する具体的実施例を示すシーケ
ンス図である。

【図１９】本発明のホストグループを変更する実施例を
説明する図である。

【図２０】図１９の実施例で使用する受信集計フレーム
の制御情報フォーマット図である。

【図２１】ルータ間で本発明を実現するためのやり取り
するホストグループメッセージフォーマット図である。

【図２２】ルータの構成図である。

【図２３】本発明に係わるルータの処理手順を説明する
図である。

【図２４】本発明を移動ホストに適用したときの実施例
を説明する図である。

【符号の説明】

１００…送信ホスト、 １５１，１５９…指名ホスト、 １３０，１３１，１３２，１３３，１３４…ルータ、 １５２，１５３，１５４，１６０，１６２，１６３…未
受信ホスト、 ２００…通信衛星、 １７０，１７１，２７０，２８０…プライベートＩＰマ
ルチキャストグループ、 ２１０，２２７，２３５…地球局装置、 ４００…通信処理装置。

フロントページの続き (72)発明者 松井 進 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 Ｆターム(参考） 5K030 GA08 GA13 HC01 HC09 HD03 JL02 KA01 LA01 LD06 LE03 5K033 AA02 AA03 AA09 BA04 CB03 CB13 DA05 DA18 DA19 DB14 9A001 CC02 CC03 CC06 JJ12 JJ25 KK56 KZ60

Claims (5)

【特許請求の範囲】
1. 【請求項１】ネットワークに接続する複数のホストから
   なり、１つのホストから、複数の他のホストからなるホ
   ストグループへデータを送信するマルチキャスト通信シ
   ステムにおいて、 ネットワークの状況及び受信ホストの移動状況に応じて
   前記ホストグループの構成を動的に制御する手段を備え
   たことを特徴とするマルチキャスト通信システム。
2. 【請求項２】上記請求項１のマルチキャスト通信システ
   ムにおいて、 前記データを送信するホストは、前記ホストグループ内
   の正常受信したホストのなかから一部を指名して、通信
   処理の一部を該指名したホストに行わせる手段を備える
   ことを特徴とするマルチキャスト通信システム。
3. 【請求項３】ネットワークに接続する複数のホストから
   なり、１つのホストから、複数の他のホストからなるホ
   ストグループへデータを送信するマルチキャスト通信シ
   ステムにおいて、 前記データを送信するホストは、ネットワークの状況及
   び受信ホストの移動状況に応じて前記ホストグループ内
   の正常受信したホストを指名する手段と、 該指名のホストを含むホストグループを新たに生成ある
   いは既存のホストグループの構成を変更する手段と、該
   指名のホストに該指名のホストが所属する新たな或は変
   更した該ホストグループに対する通信処理の一部を行わ
   せる手段とを備えることを特徴とするマルチキャスト通
   信システム。
4. 【請求項４】上記請求項３のマルチキャスト通信システ
   ムにおいて、前記指名されたホストは、 受信したデータ送達確認を送信ホストに送る手段と、 正常に受信できなかったデータの再送を要求する手段と
   を備えることを特徴とするマルチキャスト通信システ
   ム。
5. 【請求項５】上記請求項４のマルチキャスト通信システ
   ムにおいて、前記ネットワークに無線回線を用いること
   を特徴とするマルチキャスト通信システム。