(57)【特許請求の範囲】
【請求項１】
ネットワークに接続する複数のホストからなり，送信ホストとなる１つの前記ホストから複数の他のホストへ，マルチキャストによる通信処理を行い，データを送信するマルチキャスト通信システムにおいて，
前記他のホストのうち，送信された前記データを受信した受信ホストは，前記送信ホストへ，送達確認を送信する手段を備え，
前記送信ホストは，
前記複数の他のホストから，前記送信データに対する送達確認を受信する手段と，
受信した前記送達確認に基づき，前記受信ホストの中から，前記他のホストのうち前記データの送達を確認できなかった未受信ホストに対する前記通信処理を行わせる指名ホストを選択する手段と，を備え，
選択された前記指名ホストは，前記未受信ホストに対する前記通信処理を行う手段を備える
ことを特徴とするマルチキャスト通信システム。
【請求項２】
上記請求項１に記載のマルチキャスト通信システムにおいて，
前記送信ホストは，受信した前記送達確認に基づき，前記受信ホストと，前記未受信ホストと，からなるホストグループを構成する手段と，
前記構成したホストグループ内の前記受信ホストの中から，指名ホストを選択する手段と，を備え，
選択された前記指名ホストは，当該指名ホストが属する前記ホストグループに含まれる他の前記未受信ホストに対する前記通信処理を行う手段を備える
ことを特徴とするマルチキャスト通信システム。
【請求項３】
上記請求項１または２に記載のマルチキャスト通信システムにおいて，
前記通信処理は，前記未受信ホストへの再送処理であり，
選択された前記指名ホストは，前記未受信ホストに対し，当該指名ホストが受信済みの前記データを再送する手段を備える
ことを特徴とするマルチキャスト通信システム。
【請求項４】
ネットワークに接続する複数のホストからなり，送信ホストとなる１つの前記ホストから，複数の他のホストへマルチキャストによりデータを送信するマルチキャスト通信システムにおいて，
前記複数の他のホストは，指名ホストと，その他のホストと，からなるホストグループを，予め一つ以上構成し，
前記指名ホストは，前記送信ホストから当該ホストグループ内の他のホストへ送信されたデータの送達確認を集計し，前記送信ホストへ送信する手段と，
前記送信ホストは，前記指名ホストから送信された送達確認に基づき，送信された前記データを受信した受信ホストと，前記データの送達を確認できなかった未受信ホストからなる新たなホストグループを構成し，
前記新たなホストグループ内の前記受信ホストの中から，新たな指名ホストを選択する手段と，を備え，
前記新たな指名ホストは，当該新たな指名ホストが属する前記新たなホストグループに含まれる他の前記ホストに対し，受信済みの前記データを再送する手段を備える
ことを特徴とするマルチキャスト通信システム。
【請求項５】
上記請求項１ないし４いずれか一に記載のマルチキャスト通信システムにおいて，
前記複数のホストは，
受信したデータ送達確認を送信ホストに送る手段と，
正常に受信できなかったデータの再送を要求する手段とを備える
ことを特徴とするマルチキャスト通信システム。
【請求項６】
上記請求項１ないし５いずれか一に記載のマルチキャスト通信システムにおいて，
前記ネットワークに無線回線を用いる
ことを特徴とするマルチキャスト通信システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークを用いてデータの配信を行うためのマルチキャスト通信システムの大規模化、高信頼化技術に関する。
【０００２】
【従来の技術】
現在特定の複数宛先にデータを配信できるマルチキャスト通信に関係する技術として、IETF(Internet Engineering Task Force）にてIGMP（Internet Group Management Protocol：RFC2236)がＩＰレベルの標準として成立している。またマルチキャスト用のアドレスの使い方はRFC2356で開示されている。IGMPはマルチキャストルータが、マルチキャストデータを効率よく転送できるように所属するローカルネットワークに該当するマルチキャストグループのメンバが存在するか否かを把握するためのプロトコルである。またIETFのドラフトレベルではルーティングプロトコルとして、世界規模のマルチキャスト仮想実験ネットワークのMBONE向けにDVMRP(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 Information Using ＩＰ Multicast」）、や文献４（米Mentat社のXTP4.0；江口著「TCP／IPから見たXTPプロトコル」雑誌Bit Vol.２８No４，１９９６−０４）参照。
【０００７】
▲３▼送信制御、送達確認及び再送制御を並行に行う方法(文献２参照）
がある。いずれもIPあるいはUDPのをベースに行っている。また、送達確認及び再送制御の送信ホストへの負荷を軽減するために、文献５（ B.N.Levine他１名著「A comparison of known Classes of Reliable Multicast Protocols」ICNP1996−Oct，Columbus Ohio）には、送達確認或は再送制御タイミングを時間的に分散させること、正常受信していない送達確認のみ通知する方法が開示されている。
【０００８】
【発明が解決しようとする課題】
例えばインタネットを利用している数万を越える契約ユーザにゲームソフトなどのソフトウエアを配信するサービスのように、おびただしい数のユーザに誤りなく確実にデータをマルチキャスト送信する場合、上記送達確認と再送制御を採用することが重要となる。特に回線品質が高くない無線回線を利用する際には必須の手段である。このような場合ユーザ数が莫大になると、送達確認或は再送制御にかかる送信ホストへの負荷が、時間的分散などの工夫にかかわらず軽減できなくなり配信に多大な時間を要することになる。またネットワークの一部の回線の不具合やトラヒック輻輳が発生する等で、DVMRPやMOSPFによって作成されたマルチキャストツリーの一部が不通になりデータ配送が不可能あるいは伝送時間の長大化等システム全体に悪影響を及ぼすおそれがある。
【０００９】
本発明の目的は、上記課題を解決し多数のユーザに確実にデータを送信することができる、大規模なマルチキャスト通信システムを提供することである。
具体的には、
（１）送達確認と再送制御にかかる送信ホストの負荷を分散すること、
（２）トラヒック輻輳やデータ伝送の滞りを回避すること、
（３）ルータ等のネットワーク資源の消費を抑えること、
が可能なマルチキャスト通信方法とそれを用いたマルチキャスト通信システムと、当該システムを構築するために必要な、個々の通信装置や、計算機上にこれらの通信装置を実現するプログラムを提供することである。
【００１０】
【課題を解決するための手段】
上記目的を達成するために、本発明では、マルチキャストデータを送信するホストが、ネットワークの状況に応じて、ホストグループ(マルチキャストグループともいう)の構成を動的に制御することを特徴とする。
他の観点では、送信ホストからマルチキャストグループを構成するホストまでの経路、つまりマルチキャストツリーを動的に再構成することを特徴とする。
一般的にツリーを構成するのは、経路制御機能をもったネットワークノードです。具体的には、ルータであったり、gatewayでも、通常のPCでも経路制御機能があれば構わない。
【００１１】
制御の方法として、正常に受信したホストを含むように、ホストグループを構成する(例えば、新たに１つ以上生成するかまたは既存のホストグループの構成を変更する)ことを特徴とする。
さらに、該正常に受信したホストに、該ホストが所属する新たに生成したまたは変更したホストグループ内に対する通信処理の一部を行わせることを特徴とする。
他の観点として、正常に受信したホストを新たな送信ホストとして、マルチキャストツリーを再構築することを特徴とする。
さらに、本発明のマルチキャスト通信システムにおける、前記指名されたホストは、受信したデータ送達確認を送信ホストに送る手段と、正常に受信できなかったデータの再送を要求する手段とを備えることを特徴とする。
【００１２】
本発明のマルチキャスト通信システムによれば、送信ホストの負荷を分散でき大規模なマルチキャストシステムを実現することが可能になる。また一部の不具合状況にしたがって、ホストグループを再構成し、前記指名ホストに処理を移すことでトラヒック輻輳、データ伝送の滞りを回避することが可能になる。すなわち、高信頼化を担う再送制御処理を効率化することができ、システム効率の低下を防ぐことが可能になる。
また、本発明は、複数のホスト間の経路に無線回線、特に衛星回線を利用することを特徴とするものである。再構成したホストグループをルータ等のネットワークノードを介さずに無線(衛星）回線で直接接続で構成させることにより、送達確認或は再送制御等の通信処理による影響を他のネットワークへ及ぼさないこと、他のネットワークからも影響受けないことが可能になり、通信処理の効率化とシステム効率の低下防止が可能になる。
【００１３】
また、本発明は、送信正常に受信できなかったデータの再送を要求するシステムにおいて、指名ホストが新たに生成した或は変更した該ホストグループにマルチキャストで再送を行わせることを特徴とする。
また、本発明に用いる通信処理装置は、ネットワークを構成するノード間で、再構成したホストグループの定義情報を通知する手段を備え、前記再構成したホストグループに閉じた通信処理を行うことを特徴とする。
また、本発明に用いる通信処理装置は、新たにあるいは変更したホストグループを構成するホストとのネットワークコストが最小となるような正常受信ホストを選択する手段を備えることを特徴とする。
【００１４】
【発明の実施の形態】
以下、図にしたがって本発明を用いた実施例を説明する。
図１は本発明の概要を説明するシステム構成図である。システムは複数のネットワーク１２０〜１２７、これらネットワーク間を接続する複数のルータ１３０〜１３４及びネットワーク１２０〜１２７とルータ１３０〜１３４からなるネットワークに接続するホスト１００及び１５０〜１６３からなる。同図ではホスト１００が配信するマルチキャストデータを有する送信ホストを示し、ホスト１５０〜１６３は、該マルチキャストデータを受け取るマルチキャストグループを構成していることを示している。グループ１７０及びグループ１７１は本発明にて新たに生成されるホストグループを示す。ここでは、ホスト１００がマルチキャストデータ１０１を複数のフレームに分割しこのマルチキャストグループのマルチキャストグループアドレスを宛先アドレスとして、マルチキャストグループに所属するホスト１５０〜１６３に送達確認と再送制御をもちいて高信頼に配信する場合を例として説明する。
【００１５】
この場合、ホスト１００は送信したフレームに対してホスト１５０〜１６３から送達確認通知を受け取り、ホスト１５０〜１６３おのおのに対してフレーム単位で未受信と正常受信の状態管理を行う。ここではホスト１５２、１５３、１５４、１６０、１６２、１６３を、未受信フレームが有り再送を要求する旨の通知を行ったホスト(以降、未受信ホストと呼ぶ)と仮定し、その他のホストはすべてのフレームを正常受信したホスト(以降、正常ホストと呼ぶ)と仮定する。この送達確認通知結果を基に、ホスト１００は正常受信ホストを含め未受信通知を行ったホスト１５２、１５３、１５４、１６０、１６２、１６３から新たにホストグループを定義する。
【００１６】
この図では未受信ホストまでのトータルネットワークコストが小さくなるような方針で、正常ホストとしてホスト１５９及び１５１を指名し、それぞれを含む２つの新たなホストグループ１７０と１７１を定義している。ホストグループ１７０は指名されたホスト(以降、指名ホストと呼ぶ)１５９、未受信ホスト１６０、１６２、１６３で構成し、ホストグループ１７１は指名ホスト１５１、未受信ホスト１５２、１５３、１５４で構成する。
【００１７】
ホスト１００は、定義した新たなホストグループにそれぞれ新たなマルチキャストアドレスを付与しグループの定義情報と共に制御データとして、再送開始までにマルチキャストデータのフレーム送信と並行して送信し、ホスト１５０〜１６３に通知する。
【００１８】
前記定義情報に関わるホスト１５１、１５２、１５３、１５４、１５９、１６０、１６２、１６３はそれぞれ通知された定義情報を受信する。ホスト１５１はホストグループ１７１、ホスト１５９はホストグループ１７０の指名ホストであることを認識する。
【００１９】
指名ホスト１５１、１５９は、それぞれホストグループ１７１、ホストグループ１７０の再送制御のマスタとなり、ホストグループ１７１及び１７０それぞれ付与されたマルチキャストアドレスを付けて必要なフレーム１８０及び１８１を再送する。再送制御が終了するとその旨をホスト１００へ通知する。
【００２０】
このように受信状況及びトラヒック状況に応じて、再送のために必要なホストグループを指名ホストともに一時的に定義して再送制御をローカルで行うことで再送処理を分散し、大規模な高信頼マルチキャストサービスへ対処が可能となる。またローカルに閉じた通信処理を行うことで、ホスト１００から再送する場合に比べ、未受信ホストから遠いネットワーク或はルータ等のネットワーク資源の消費を抑えること、すなわち、再送フレームのトラヒック増加による悪影響を抑えることができる。
【００２１】
次に図２を用いて、広域・同報性を有し大規模なマルチキャスト通信に非常に有効な伝送媒体である衛星回線を利用する場合の実施例を説明する。図２において、２００は通信衛星、２１０、２２０〜２３４は衛星回線にデータを変換し送受信を行う地球局装置、２１１、２４０〜２４７及び２９０〜２９５はそれぞれ地球局装置２２０〜２３４に接続しデータの処理を行うホストを示す。ここでは、マルチキャストデータを有するホスト２１１が、地球局装置２１０、通信衛星２００を介して衛星回線２１２にてマルチキャストグループ２５０を構成するホスト２４０〜２４７及び２９０〜２９５にマルチキャストデータを配信する場合を説明する。
【００２２】
上記と同様にデータをフレームに分割してマルチキャストグループ２５０のグループアドレスを付して同報する。マルチキャストグループ２５０の構成ホストは送達確認をホスト２１１にユニキャストで返信する。この送達確認を基にホスト２４０〜２４７及び２９０〜２９５の受信状態を把握して、新たなホストグループ２７０と２８０を定義する。ここでは、未受信ホストがホスト２９０〜２９５であり、これら以外のホストは正常ホストである。指名ホストは正常ホスト２４６及び２４７である。ホストグループの定義は、受信状況をみて以下の基準で行うことが考えられる。
【００２３】
（１）フレーム未受信率が同一（定義は後述する）のホストを同一グループとする
（２）フレーム未受信パターンが同一（定義は後述する）のホストを同一グループとする
（３）同一の地域のホストを同一グループとする
指名ホストの選択は、出来るだけ上記生成したホストグループに物理的に近いことを基準とする等が考えられる。
【００２４】
指名ホスト２４６はホストグループ２７０を、指名ホスト２４７はホストグループ２８０の再送制御を担う。指名ホスト２４６は再送フレーム２７１を、指名ホスト２４７は再送フレーム２８１を、通信衛星２００を介してそれぞれのホストグループ２７０及び２８０の未受信ホストへ送信する。
以下では上記従来の技術にて示している、送信制御と送達確認を並行に行い一通りデータを送信したあとに再送制御を行う方法での実施例を説明する。
【００２５】
図３に本実施例でのシーケンスを示す。図３（１）は送信制御と送達確認を並行に行うシーケンスを、図３（２）は再送制御のシーケンス例を示す。図３（１）ではホスト２４０、２９０、２９５がマルチキャストでデータを受信しているところを示している。３０１〜３０９はマルチキャストデータのフレームを、６フレームで１つのブロックを定義している。ブロック毎に受信したホストが未受信のみの送達確認を行っている。受信したホストがそれぞれブロック終了毎にタイマーを作動させランダム時間経過後に送達確認を送信している。
【００２６】
なお、並行に行うとは、マルチキャストデータを、例えばフレーム単位で受信しながら同時にこれまで受信したデータフレームに対する受信状況(送達確認)を送ることを意味している。受信状況を送るタイミングは採用する送達確認方法に従って任意に選択できるものである。例えば、ウインドウサイズ分ごとに送達確認するとか、ある受信データ量ごとに送達確認する等の方法が可能である。また、送信制御とは、再送も含めてマルチキャストデータを送信することである。送達確認とは、マルチキャストデータに対する受信状況を送信側に通達することで、マルチキャストデータに対する正常受信かエラー受信かを送信側が認識することである。
【００２７】
未受信フレームがあることを通知するＮＡＣＫ(Ｘ，Ｙ）フレームにおけるＸはホストの識別子を、Ｙは未受信フレーム番号で未受信フレームを通知する。図ではホスト２９０はフレーム番号２のフレームが未受信であることを、ホスト２９５はフレーム番号６と７が未受信であることを通知している。図３（２）では、（１）のシーケンスが一通り終了し、ホスト２１１が受信状況から新たにホストグループ２７０及び２８０を生成し、そのうちホストグループ２８０における指名ホスト２４７からホスト２９５へマルチキャストでフレーム６及び７の再送を実施している様子を示している。
【００２８】
図４は、図３のシーケンスを実行する主要な装置の構成例を示したものである。この図において、通信衛星と送受信を行う地球局装置２１０、２３５、２２７には、それぞれ本発明を実行する通信処理装置４００が接続されている。さらに前記通信処理装置にはそれぞれ、ホスト２１１、２９５、２４７が接続されている。もちろん通信処理装置はホストの中で実現することも可能であるが、発明説明を明確にするために分離した。ホスト２４７はこの例では指名ホストとなるものである。
【００２９】
図５は図３のマルチキャスト手順を実行する通信処理装置４００の構成を示すブロック図である。ＣＰＵ５００は、マルチキャスト通信制御等の各種の通信処理プログラムをＲＯＭ５１０から呼び出して実行する。ＲＡＭ５２０は、受信状態管理表など本発明実施の上で参照される情報を一時保存する制御情報記憶手段である。Ｉ／Ｆ回路５３０は地球局装置との接続を行い入出力バッファ５６０に一時的に入出力データを記憶する。Ｉ／Ｆ回路５４０はホストとの接続を行い入出力バッファ５７０で一時的に入出力データを記憶する。
【００３０】
Ｉ／Ｆ回路５５０は他のネットワークとの接続を行い入出力バッファ５８０で一時的に入出力データを記憶する。ＣＰＵ５００は入出力バッファを監視している。これにより、接続するホストあるいはネットワークからのデータを入出力バッファを介して通信する。ここでは一般的なインタネットプロトコルであるＴＣＰ／ＩＰ(Transmission Control Protocol ／Internet Protocol）でホスト或はネットワークと通信する場合で説明する。また地球局装置とはＩＰベースの上に、マルチキャスト用の下記に説明するプロトコルを実施する。
【００３１】
図６はＩＥＴＦで標準化されておりインタネット等で利用されているＩＰパケット６００を示す。ＩＰパケット６００は通常２０バイトのＩＰヘッダ部とＩＰデータ部６２０からなる。マルチキャストデータはこのＩＰデータ部６２０で運ばれる。通信処理装置４００はホスト或はネットワークで図６のフォーマットでやり取りするデータを入出力バッファに蓄え、ＩＰデータ６２０を取り出し、フレームサイズに分割し、新たに制御情報を加え再度ＩＰパケット化を行いＩ／Ｆ回路５３０へ出力する。
【００３２】
図７は上記Ｉ／Ｆ回路５３０を介して衛星回線へ送信するために再度組み立てられたＩＰパケット７００のフォーマットを示す。ＩＰパケット７００は標準の２０バイトのＩＰヘッダ部７１０とＩＰデータ部７２０からなり、ＩＰデータ部７２０には通信処理装置４００で作成したフレームセグメント７７０が格納される。ＩＰデータ部７２０はフレームヘッダ部７３０とフレームデータ部７５０からなる。フレームデータ部７５０にはユーザデータ或は制御情報が格納される。
【００３３】
フレームヘッダ部７３０はユーザデータ／制御データの識別を行うデータフレームと制御フレームを示すフレームタイプ７３１、送信元ポート番号７３２、宛先ポート番号７３３、フレームシーケンス番号７３４、ブロックの開始と終了のためブロック識別子７３５、マルチキャストアプリケーションを識別するＩＰマルチキャストアドレス７３６、フレームが正常に到着したことを確認するチェックサム７３７からなる。制御フレームには、例えば、後述するようにマルチキャストデータを送信する側から送るホストグループ定義のためのフレームや受信する側の送達確認通知等、今回の発明に関わる制御情報を伝達するフレームである。データフレームは、マルチキャストデータを送信するためのフレームである。
【００３４】
まず、マルチキャストデータの送信元となるホスト２１１に接続する通信処理装置４００のデータ送信処理手順を図５〜図７を利用して図８のフローチャートで説明する。ステップ８０１で入出力バッファ５７０のＩＰパケット６００をチェックして、ステップ８０２でＩＰマルチキャストデータであるかをＩＰヘッダの宛先ＩＰアドレスで判断する。インタネット標準の仕様では、クラスＤのＩＰアドレスをマルチキャスト用に定義しており、先頭４ビットが「１１１０」(１０進法では２２４）となっている。
【００３５】
図２では、マルチキャストグループ２５０用にマルチキャストアドレスが割当てられている。このマルチキャストアドレスは、標準ではクラスＤのうちパブリックに割り当てられている２２４.０.１.０〜２３８.２５５.２５５.２５５のいづれかである。或は１つの団体で閉じている場合だと、ローカルに割り当てられている２３９.０.０.０〜２３９.２５５.２５５.２５５が利用できる。ステップ８０２で通常のユニキャストＩＰアドレスであると入出力バッファ５７０のＩＰパケットをステップ８０９で取り出してそのままステップ８０８で入出力バッファ５６０へ送信する。
【００３６】
ステップ８０２でマルチキャストデータであると判断すると、ステップ８０３でＩＰパケット６００を取り出してデカプセルする。ステップ８０４でデカプセル後のＩＰデータ６２０をフレームに分割する。必ずしも１つのＩＰデータからフレームを作成するわけではなく、複数ＩＰデータで１つのフレームを構成することもある。ステップ８０５でフレームヘッダの作成を行う。フレームヘッダは図７で示したが、フレームタイプ７３１をユーザデータタイプとし、ホスト２１１から受け継いだ送信元ポート番号７３２、宛先ポート番号７３３、そしてシーケンス番号７３４は分割したフレーム番号を付する。ブロック番号７３５は先頭及び終わりのフレームに付する。
【００３７】
ＩＰマルチキャストアドレス７３６は、今回のマルチキャストアプリケーションを識別するため、前記ＩＰマルチキャストアドレスを付ける。ステップ８０６でステップ８０４でのフレームデータにステップ８０５のフレームヘッダからをフレームを組み立て、ステップ８０７でステップ８０３でデカプセル化後のＩＰヘッダ６１０でステップ８０６のフレームをカプセル化して、ステップ８０８で入出力バッファ５６０へ送信する。以上がデータ送信処理の動作である。なおここでは、通信制御装置４００がホストのＩＰマルチキャスト及びＩＰアドレスを管理しているものとして説明している。
【００３８】
次に送信するホスト２１１に接続する通信処理装置４００の受信処理手順を説明するがその前に使用する制御フレームについて示しておく。図９はマルチキャストデータを受信するマルチキャストグループ２５０を構成するホスト２４０〜２４７及び２９０〜２９５の通信処理装置４００が衛星回線を介して返す未受信送達確認のフレーム（ＮＡＣＫフレームと呼ぶ）の制御情報９００である。ＮＡＣＫフレームは図７で説明したフレームヘッダ７３０のフレームタイプが制御データのＮＡＣＫ通知であることの識別子を付けた制御フレームであり、フレームデータ部７５０には図９で示す未受信のフレームシーケンス番号の先頭と末尾をペアにしたものである。
【００３９】
図１０は送信側通信処理装置４００が受信側の通信処理装置４００へ送る制御フレームであるホストグループ通知フレームのフレームデータ部７５０の制御情報１０００を示す。制御情報１０００は１つのホストグループ毎にホストグループのＩＰマルチキャストアドレス１００１、指名ホストのＩＰアドレス１００２、構成するホストのＩＰアドレス１００３、１００４、及びこのホストグループ１０１０の構成において未受信フレームのシーケンス番号の先頭１００５及び末尾１００６からなる。ここで新たに割当てるＩＰマルチキャストアドレスはプライベートに割当てるローカルなものである。従ってローカルに割り当てられている２３９.１９２.０.０〜２３９.２５１.２５５.２５５の中から割当てる。
【００４０】
上記制御情報１０００は、定義されたホストグループ構成に基づくものであり、送信ホストがこのホストグループ構成定義情報を保存する。また、指名ホストにおいても、任された新たなホストグループに係わる構成定義情報たとえばホストIPアドレスを同様の情報として保存する。さらに各構成ホストにおいても、指名ホストIPアドレスを保存する。
【００４１】
図１１は、マルチキャスト送信側の通信処理装置４００がＲＡＭ５２０で管理する受信状態管理表１１００を示す。受信状態管理表１１００は受信のホストＩＤ１１０１と未受信フレーム番号１１０２からなり、通信処理装置毎で未受信フレーム番号が管理されている。以上のフレームを利用して、図１２で送信側の通信処理装置４００の受信処理手順を説明する。
【００４２】
ここで、前述のフレーム未受信率、フレーム未受信パターンについて本発明における定義を例示する。
【００４３】
各受信ホストのフレームの未受信率は、例えば、データの全フレーム数を dtとすると、
フレーム未受信率＝ホストの未受信フレーム数／dt
で定義される。未受信フレーム数は、図１１の表を基に受信ホスト毎にカウントする。ホスト２９０であれば、A-F-1からA-F-Nの数を累計したものになる。フレーム未受信率があらかじめ設定した誤差の範囲内に収まる場合に「フレーム未受信率が等しい」と定義する。
【００４４】
フレーム未受信のパターンは、図１１でまとめてある各受信ホストの未受信フレームのうち、他のホストと比較してフレーム番号が一致する率を算出したもので以下のように定義する。以下の式は、ホスト290をホスト291と比較した一致率を示す。この一致率があらかじめ設定した範囲内に収まる場合を「フレーム未受信パターンが同じ」とみなす。
【００４５】
一致率(ホスト290→ホスト291)＝
ホスト291とフレーム番号が一致した数／ホスト290のフレーム未受信数
図１２のステップ１２０１でＮＡＣＫフレームを格納するＩＰパケットを受信すると、ＩＰヘッダ６１０の送信ＩＰアドレス７１１と図９で示す未受信フレーム番号を読み取り、ステップ１２０２で受信状態管理表１１００を更新する。図３のシーケンスでは、ホスト２９０から未受信フレーム先頭番号＝未受信フレーム末尾番号＝２のＮＡＣＫフレームが、ホスト２９５からは未受信フレーム先頭番号＝６、未受信フレーム末尾番号＝７のＮＡＣＫフレームを受信していることを示す。
【００４６】
ステップ１２０３で新たなホストグループ定義通知を行うタイミングか否かを判断する。判断の方法としてはいろいろな場合が想定されるが、例えば▲１▼マルチキャストデータの送信が全て完了する数ブロック前をタイミングとして定期的に通知する、▲２▼マルチキャストデータ送信完了後タイミングで数回通知する等がある。未受信フレーム数が規定以上に多いホストグループの場合には天候等による回線品質の低下の可能性があるため一定の時間後に再送するように指示する。指名ホストへのホストグループ定義通知を行うタイミングでなければステップ１２０１へ戻る。
【００４７】
ステップ１２０４で、受信状態管理表１１００から、前記で示したホストグループ定義基準に従ってグループ構成ホスト及び指名ホストを決定する。
【００４８】
図２では新たなホストグループ２７０が指名ホスト２４６、未受信ホスト２９０〜２９２で、ホストグループ２８０が指名ホスト２４７、未受信ホスト２９３〜２９５で構成定義したものである。ステップ１２０５ではこの定義をもとに、ホストグループ通知フレームのフレームデータ部７５０の制御情報１０００を作成しマルチキャストグループ２５０のＩＰマルチキャストアドレスを宛先ＩＰアドレスとしたＩＰヘッダでカプセル化する。ステップ１２０６でこのＩＰカプセル化した制御フレームを入出力バッファ５６０へ送信する。
【００４９】
図１３は通信処理装置４００のＲＡＭ５２０で管理しているアプリケーション毎のＩＰマルチキャスト対応表を示したものである。これによりアプリケーション毎のホストグループを管理している。ここでは３つのマルチキャストを利用するアプリケーション毎のＩＰマルチキャスト対応表１３００、１３１０、１３２０である。
【００５０】
図１４はプライベートＩＰマルチキャスト管理表１４００を示したものである。この表は例えば企業が利用する場合であれば、企業内に１つこの表を管理するマスタサーバを立ち上げて管理していくものである。プライベートＩＰマルチキャスト管理表１４００へ必要なホストは登録してプライベートＩＰマルチキャストを取得する。利用できるプライベートＩＰマルチキャストは、ＩＥＴＦでローカルに割り当てられている２３９.１９２.０.０〜２３９.２５１.２５５.２５５を利用する。プライベートＩＰマルチキャスト管理表１４００は取得元のホストＩＰアドレスが記載されている。未使用だと０.０.０.０となっている。
【００５１】
図１５でマルチキャストグループ２５０を構成するホストのうち、指名ホストとなるホスト２４６及びホスト２４７に接続する通信処理装置４００の処理手順を説明する。ここでは特に指名ホストとして特有の手順のみについて記す。
【００５２】
ステップ１５００でを入出力バッファ５６０からホストグループ通知フレームを格納するＩＰパケットを受信すると、ステップ１５０１で自ホストのＩＰアドレスが指名ホストとして記されているかを判断する。記されてなければ終了。ステップ１５０２で指名ホストであることを認識すると再送タイミングであるかを判断する。再送タイミングにもマルチキャストシステムによって決定される。図３のシーケンスでは再送タイミングは送信のホストから与えられる。再送タイミングでなければステップ１５００へ戻る。
【００５３】
ステップ１５０３でホストグループ通知フレームで指示された再送のフレームを自ホストが新たに担当するホストグループのプライベートＩＰマルチキャストアドレスをＩＰヘッダ６１０の宛先ＩＰアドレス７１２に、自ホストＩＰアドレスを送信元ＩＰアドレス７１１にして、ＩＰ化して再送する。図３のホストグループ２８０の指名ホスト２４７だとフレーム６及び７を再送する。
【００５４】
ステップ１５０４で所属するホストグループの未受信ホストからのＮＡＣＫフレームを受信したか否かを判断する。受信しなければステップ１５０５でマルチキャストデータの送信ホストに向けて再送完了フレーム１６００を作成し、ＩＰヘッダ６１０の送信元ＩＰアドレスに自ホストＩＰアドレスを、宛先ＩＰアドレスには送信ホスト２１１のＩＰアドレスにしてＩＰ化して入出力バッファ５６０へ送信する。ここで再送完了フレーム１６００は図１６に示すとおりである。フレームタイプ７３１を再送完了フレームタイプに、フレームデータ部７５０の制御情報として所属するプライベートＩＰマルチキャストアドレス１６１０を、それ以降に完了した再送フレームのシーケンス番号の先頭１６２０と末尾１６２１を格納したものある。
【００５５】
図１７に未受信ホストの通信処理装置４００の処理手順を示す。ここでは特にＮＡＣＫフレームを送信した以降の手順について記す。ステップ１７０１でホストグループ通知フレームを受信すると、ステップ１７０２で該ホストグループ通知フレームの制御情報１０００をチェックして、受信ホストＩＰアドレス１００２に自ホストのＩＰアドレスを探して、指定された所属のプライベートＩＰマルチキャストアドレス１００１及び指名ホストのＩＰアドレスをＲＡＭ５２０に記憶する。
【００５６】
ステップ１７０３で受信した再送フレームが自ホストの未受信マルチキャストフレームであるかを判断し、未受信マルチキャストフレームでなければ待ち状態となる。ステップ１７０４で正常に再送フレームを受信していれば終了となるが、正常受信してなければステップ１７０５でＮＡＣＫフレームの制御情報９００に未受信フレームシーケンス番号の先頭９１０と末尾９２０をセットしてＩＰパケット化する。ＩＰヘッダの宛先ＩＰアドレスには再送元の指名ホストＩＰアドレスをセットして入出力バッファ５６０に送信する。
【００５７】
他の実施例として、送信制御の終了後に送達確認及び再送制御を行う方法でマルチキャストを行う方法も考えられる。この方法では、送達確認通知をマルチキャストデータの送信後に行うことから、マルチキャストデータを受信するホストの通信処理装置４００の送達確認通知のタイミングを変更することで実現され、本発明に関わる処理としては同じである。
【００５８】
第３の実施例として、図１８で示すように送信制御、送達確認及び再送制御を並行に行う方法について説明する。この場合は、一通りのマルチキャストデータの送信を完了しなくてもＮＡＣＫフレームに対する再送を行うことから、通信処理装置４００の処理手順が次のように異なる。
【００５９】
まずマルチキャストデータを送信するホスト２１１の通信処理装置４００のホストグループ通知フレームの送信がより頻繁に行われる。さらに該ホストグループ通知フレームタイミング毎にホストグループが異なることがある。このため該ホストグループ通知フレームにてホストグループの動的変更が行われる。つまり、前回の該ホストグループ通知フレームの通知から今回の該ホストグループ通知フレーム通知のあいだに受信するＮＡＣＫの状況が大きく変化する際にホストグループの構成変更が発生し、図１２で示したステップ１２０３の判断が前記と異なる。これに伴い指名ホストとなる受信ホストにおいても所属するホストグループ変更が図１５で説明した処理で頻繁に行われる。受信ホストにおいても所属するホストグループ及び指名ホストの変更が図１７で示した処理で頻繁に行われるようになる。受信ホスト側の本発明に関わる通信処理装置４００の基本処理手順に変更はない。
【００６０】
次に指名ホストが予め決められ、送達確認及び再送制御を指名ホストに実施させる場合のマルチキャストシステムの実施例について説明する。図１９にシステム構成を示す。この図において、送信ホスト１９００は衛星通信用の地球局装置１９０１９０７を介してマルチキャストグループ１９０２を構成するホスト１９１０、１９２０、１９３０、１９４０、１９５０、１９６０、１９７０、１９９０へマルチキャストデータを送信する。予めホストグループ１９０３、１９０４、１９０５が定義されている。ホストグループ１９０３は、ホスト１９２０、１９４０、１９５０からなりホスト１９４０が指名ホストである。ホストグループ１９０４は、ホスト１９１０、１９３０、１９６０からなりホスト１９１０が指名ホストである。ホストグループ１９０５は、ホスト１９７０、１９８０、１９９０からなりホスト１９９０が指名ホストである。
【００６１】
各指名ホストは、所属するホストグループの他のホストからの送達確認通知を集計して、送信ホスト１９００へ各ホストグループの受信状態を通知する。例えば指名ホスト１９４０はホストグループ１９０３のホスト１９２０、１９５０の送達確認通知を受取り集計して、受信集計フレームとしてホスト１９００へ送る。
【００６２】
図２０に受信集計フレームの制御情報２０００のフォーマットを示す。制御情報はホストグループＩＤ２０１０、受信ホストＩＰアドレス２０２０及び該受信ホストの未受信フレームシーケンス番号の先頭２０３０及び末尾２０４０からなる。送信ホスト１９００はマルチキャストデータの送信を完了し各指名ホストから送られた受信集計フレームから受信状態管理表１１００を作成する。この後システムは再送制御動作に移行する。
【００６３】
つぎに、未受信ホストとしてホスト１９２０とホスト１９３０を想定して、受信状態管理表１１００に基づいて現状のホストグループの構成を変更して再送制御を指名ホストに実施させる例を説明する。
図１９で、送信ホストはホスト１９１０を指名ホストに選び、未受信ホスト１９２０及び１９３０でホストグループ１９０６を定義し、ホストグループ通知フレーム１０００で通知する。指名ホストに選ばれたホスト１９１０は、新たなホストグループ１９０６用のプライベートＩＰマルチキャストアドレスで再送制御を行い完了すると図１６で示した制御情報の再送完了フレームを送信ホスト１９００へ送信する。
【００６４】
本実施例のように再送制御時に動的にホストグループを変更することで、受信正常ホストは未受信ホストの影響を受けずにマルチキャストデータの受信が可能となる。必要なホストのみで新たにホストグループを構成することで再送処理を効率化が図れる。
【００６５】
次に本発明を地上回線に適用する場合の実現構成について説明する。
図１で説明したように地上では衛星回線と異なりマルチキャストデータを配信するためにはマルチキャストツリー上の複数のネットワークを通過しなくてはならない。ツリーの構成要素であるネットワークノードは具体的には、ルータ、gateway、または経路制御機能をもった計算機などが相当し、通常ネットワークノードとしてルータが用いられている。これらのルータから構成されるネットワークにおいて、マルチキャストを実施する場合インタネットでは従来の技術で説明したようにＩＧＭＰ、ＤＶＭＲＰやＭＯＳＰＦが利用されている。
【００６６】
これらの技術をもとに本発明の動的なマルチキャストを実現するために、図２１で示すようなＩＧＭＰメッセージを拡張したフォーマットの制御情報をマルチキャスト対応のルータ間でやり取りさせる。
図２１にＩＧＭＰメッセージの未使用領域にサブタイプ２１３０を設けホストグループ通知メッセージの識別子を入れた例を示す。チェックサム２１４０の後にパブリックなＩＰマルチキャストアドレス２１５０と該ＩＰマルチキャストアドレス２１５０のなかで一時的に動的に定義するプライベートＩＰマルチキャストアドレス２１６０と指名ホストＩＰアドレス２１７０及びプライベートＩＰマルチキャストアドレス２１６０で構成するホストのＩＰアドレス２１８０、２１９０で構成される。
【００６７】
図２２にルータ２２００の構成を示す。ＣＰＵ２２１０は、ＲＯＭ２２２０のルーティング処理ソフトを実行し、ＲＡＭ２２３０のルーティングテーブルを参照しながら、受信したＩＰパケットを、インタフェース回路２２４０、２２５０、２２６０のうち、ＩＰパケットを受信したインタフェース以外に送出する。
【００６８】
図２３で本発明に係わるルータの処理手順を説明する。ステップ２３０１でホストグループ通知メッセージ２１００の受信を行うと、ステップ２３０２でプライベートＩＰマルチキャストグループを構成する指名ホストＩＰアドレス２１７０、ホストＩＰアドレス２１８０、２１９０をチェックする。ステップ２３０３で、自ルータのルーティングテーブルを参照して配下にある１つのインタフェースのネットワークに、プライベートＩＰマルチキャストグループを構成するホストが全て接続されているか否かを判断する。全て接続されていればステップ２３０４にて、受信したホストグループ通知メッセージ２１００を接続されているネットワークへのインタフェースへ送出する。そうでなければステップ２３０５で、自ルータのルーティングテーブルヘプライベートＩＰマルチキャストアドレス及び構成ホストを登録して、ステップ２３０６で指名ルータ及び構成ホストへのインタフェースに該受信したホストグループ通知メッセージ２１００を送出する。
図２３の動作により、指名ホストの担当のプライベートＩＰマルチキャストグループの中だけでプライベートＩＰマルチキャストアドレスによる通信処理が行われる。
【００６９】
次に受信ホストが移動しても動的にホストグループを変更させることで容易にマルチキャストデータを受信させる実施例について説明する。このようにホスト移動が伴う場合には衛星回線のような広域をカバーする無線回線が非常に有利となるが、図１の地上回線でも対応可能である。ここでは図２４にて衛星回線を利用するマルチキャストシステムの受信ホストが他の地球局装置の配下に移動したときの動作を説明する。
【００７０】
この図では、送信ホスト２４０２が、通信処理装置２４００、地球局装置２４０１、衛星回線２４８０を経て、マルチキャストグループ２４７０を構成する受信ホスト２４１２、２４１３、２４２２、２４２３、２４２４、２４３２、２４３３にマルチキャストデータを送信する例を示す。受信ホスト２４１２、２４１３は通信処理装置４００に、受信ホスト２４２２、２４２３、２４２４は通信処理装置４００に、受信ホスト２４３２、２４３３は通信処理装置４００に、それぞれLAN(Local Area Network)２４１９によって接続されている。地球局装置２４２０配下の受信ホスト２４２３が地球局装置２４４０配下のＬＡＮ２４４１へ移動する場合、通信処理装置２４００は以下のように動的にマルチキャストグループ構成を変更する。
【００７１】
すなわち、移動するホスト２４２３は、通信処理装置２４４０の配下に移動すると、図７で説明した制御フレームの一つである移動通知フレームをLAN２４４９から通信処理装置４００と衛星回線２４９０を介した送信ホスト２４０２の通信処理装置４００へ通知する。移動通知フレームのフレームデータ部７５０には制御情報としてユニークな自ホストID(MAC［Media Access Control］アドレスでも可能)、新たに割付けられたホストIPアドレスが格納されている。ホストIPアドレスがパブリックなものであれば、ユニークな自ホストIDとして利用することもできる。この該移動通知フレームを受信した受信ホスト２４２３の通信処理装置４００は新たにルーティングテーブルのネットワーク構成テーブルに受信ホスト２４２３のIPアドレスを追加する。
【００７２】
また送信ホスト２４０２側の通信処理装置４００は該移動通知フレームを受信すると、これまでのマルチキャストグループ２４７０の構成ホストへのデータ配信を持続させるため、これまでのマルチキャストグループ２４６０を変更して、地球局２４４１への衛星回線２４９０の接続を含むようにマルチキャストグループ２４６０を定義する。この新たな定義は図１３で示したIPマルチキャスト対応表の受信ホストIPアドレスを更新することでなされる。このように衛星回線のような無線回線を利用すると、受信ホストが移動しても移動先までのネットワークコストを増加させないで新たなマルチキャストグループを定義できるため、移動体に容易に対応できる。
【００７３】
上記実施例は、衛星通信網を前提に説明したが、その他のマルチキャスト伝送媒体である地上波デジタル通信網、移動体通信網にも適用可能である。
【００７４】
以上のように、本発明によれば、送信ホストの負荷を分散でき大規模なマルチキャストシステムの実現が可能になる。また一部の不具合状況にしたがって、ホストグループを再構成し、前記ホストグループに属する指名ホストに任すことでトラヒック輻輳、データ伝送の滞りを回避することが可能になる。
【００７５】
また、再構成したホストグループをルータ等のネットワークノードを介さずに無線(衛星）回線で直接接続で構成させることが可能になる。また、送達確認或は再送制御等の通信処理による影響を他のネットワークへ及ぼさないこと、他のネットワークからも影響受けないことが可能になり、通信処理の効率化とシステム効率の低下防止が可能になる。
【００７６】
【発明の効果】
以上のように、本発明によれば、
（１）送信ホストの負荷を分散して大規模なマルチキャストシステムを実現できる、
（２）トラヒック輻輳やデータ伝送の滞りを回避することができる、
（３）ルータ等のネットワーク資源の消費を抑えることができる、
（４）通信処理の効率向上とシステム効率の低下防止を防ぐことができる、
という効果がある
【図面の簡単な説明】
【図１】本発明の概要を説明するシステム構成図である。
【図２】本発明を衛星回線を利用したネットワークに適用した実施例の概要を説明する図である。
【図３】本発明の衛星回線利用による具体的実施例を示すシーケンス図である。
【図４】図３のシーケンスを実行するシステム構成例を示す図である。
【図５】本発明を実行する通信処理装置の構成図である。
【図６】ＩＥＴＦで標準化されているＩＰパケットのフォーマット図である。
【図７】本発明の実施例で用いるフレームのフォーマット図である。
【図８】実施例のマルチキャストデータを送信するホストの通信処理装置の送信処理手順を説明するフロー図である。
【図９】未受信フレームを通知するＮＡＣＫフレームの制御情報フォーマット図である。
【図１０】新たなホストグループの通知を行うホストグループ通知フレームの制御情報フォーマット図である。
【図１１】送信ホストに接続する通信処理装置が管理する受信状態管理表である。
【図１２】送信ホストに接続する通信処理装置のホストグループ定義及び通知の処理手順を説明するフロー図である。
【図１３】送信ホストが管理するＩＰマルチキャスト対応表である。
【図１４】プライベートＩＰマルチキャストアドレス管理表である。
【図１５】指名ホストに接続する通信処理装置の本発明に係わる処理手順を説明する図である。
【図１６】図３の実施例で利用する再送完了フレームの制御情報フォーマット図である。
【図１７】未受信ホストに接続する通信処理装置の再送制御に係わる処理手順を説明する図である。
【図１８】衛星回線利用する具体的実施例を示すシーケンス図である。
【図１９】本発明のホストグループを変更する実施例を説明する図である。
【図２０】図１９の実施例で使用する受信集計フレームの制御情報フォーマット図である。
【図２１】ルータ間で本発明を実現するためのやり取りするホストグループメッセージフォーマット図である。
【図２２】ルータの構成図である。
【図２３】本発明に係わるルータの処理手順を説明する図である。
【図２４】本発明を移動ホストに適用したときの実施例を説明する図である。
【符号の説明】
１００…送信ホスト、
１５１，１５９…指名ホスト、
１３０，１３１，１３２，１３３，１３４…ルータ、
１５２，１５３，１５４，１６０，１６２，１６３…未受信ホスト、
２００…通信衛星、
１７０，１７１，２７０，２８０…プライベートＩＰマルチキャストグループ、
２１０，２２７，２３５…地球局装置、
４００…通信処理装置。
【図１】
0003692830.tif 000002
【図２】
0003692830.tif 000003
【図３】
0003692830.tif 000004
【図４】
0003692830.tif 000005
【図５】
0003692830.tif 000006
【図６】
0003692830.tif 000007
【図７】
0003692830.tif 000008
【図８】
0003692830.tif 000009
【図９】
0003692830.tif 000010
【図１０】
0003692830.tif 000011
【図１１】
0003692830.tif 000012
【図１２】
0003692830.tif 000013
【図１３】
0003692830.tif 000014
【図１４】
0003692830.tif 000015
【図１５】
0003692830.tif 000016
【図１６】
0003692830.tif 000017
【図１７】
0003692830.tif 000018
【図１８】
0003692830.tif 000019
【図１９】
0003692830.tif 000020
【図２０】
0003692830.tif 000021
【図２１】
0003692830.tif 000022
【図２２】
0003692830.tif 000023
【図２３】
0003692830.tif 000024
【図２４】
0003692830.tif 000025