JP2004228968A

JP2004228968A - ストリーミング制御装置

Info

Publication number: JP2004228968A
Application number: JP2003014884A
Authority: JP
Inventors: Shuji Inoue; 修二井上; Jun Haneda; 潤羽根田; Hong Chen; ホングチェン; Peku Yau Tan; ペクヤウタン
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2003-01-23
Filing date: 2003-01-23
Publication date: 2004-08-12

Abstract

【課題】サブネット上のトラヒックを効率化して小さくすることのできるストリーミング制御装置を提供すること。
【解決手段】ストリーミング制御装置は、ＩＧＭＰプロトコルに係るＩＧＭＰメッセージを扱うエンジンに係り、ＩＧＭＰプロトコルで動作するルータサイドでのプロセスで活用される。当該エンジンは、受信機の情報を含むマルチキャストトラヒック転送情報データベースを管理する。より具体的には、受信機がＩＧＭＰメッセージである「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」をストリーミング制御装置に送信するたびに、このエンジンは受信機を記録する。記録された受信機の情報によって、エンジンは同じトラヒックを希望する受信機が他に存在するかを直ちに知ることができるため、「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を受信してトラヒックを希望する受信機が存在しない場合には転送をすぐに停止する。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上のトラヒックを効率化して小さくすることのできるストリーミング制御装置に関する。
【０００２】
【従来の技術】
マルチキャスト技術は、ＩＰネットワーク上にある複数の受信機にオーディオビジュアルコンテンツをリアルタイムで配信するための重要な技術である。当該マルチキャスト技術は、従来のユニキャスト技術とは異なり、新しい受信機からコンテンツが要求されても新しい複製を作る必要がないため、貴重なネットワーク資源を節約することができる。この効果は、特に広帯域を必要とするコンテンツ、例えば単一ストリームで有効ネットワーク帯域幅の大部分を必要とするＭＰＥＧコンテンツ等の配信に有用であるため、このようなコンテンツをインターネットで配信する方法としてマルチキャスト技術が利用されている。
【０００３】
マルチキャスト技術を利用したコンテンツ配信源（以下「マルチキャスト配信源」という。）は、クラスＤのＩＰアドレス空間（２２４．０．０．０〜２３９．２５５．２５５．２５５）において、任意のユニキャストＩＰアドレスの代わりに当該グループアドレス中のＩＰアドレスを用いて所定のデータパケットを送信する。コンテンツの配信を要請する受信機が「ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）Ｍｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」をマルチキャストルータ（以下、単に「ルータ」という。）に送信すると、当該ルータは宛先アドレスとしてグループアドレス付きパケットを受信機に送信する。また、コンテンツの配信を要請しないとき、受信機は「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」をルータに送信する。当該メッセージを受信したルータは、「ＩＧＭＰＧｒｏｕｐ＿Ｑｕｅｒｙメッセージ」を送出して、このグループのトラヒックに関係している受信機が同一サブネット中に存在するかを調べる。そして、当該ルータは、所定時間内に応答がなければグループのトラヒックをサブネットに転送するのを停止する。
【０００４】
ＩＧＭＰプロトコルはマルチキャスト技術の基礎である。現在のところ、当該ＩＧＭＰプロトコルに対して、受信機がルータにグループのみでなく受信を望むトラヒックのマルチキャスト配信源をも知らせることのできるマルチキャスト技術に主に的を絞った改善が行われている。このような改善が施されたＩＧＭＰプロトコルによって、マルチキャスト配信源からトラヒックを望む受信機のないサブネットに転送される不要なトラヒックを減らすことができる。これは、マルチキャスト技術の活用とグループアドレス空間の制限の観点から鑑みて、マルチキャスト技術の発展にとって重要である。
【０００５】
【発明が解決しようとする課題】
上述したように、ＩＧＭＰプロトコルによる「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を利用したプロセスにはいくらかのディレイがある。すなわち、最終メンバー照会カウントに最終メンバー照会間隔を掛け合わせた時間後でなければ、マルチキャストルータはサブネットへのグループのトラヒックの転送を中止しない。このディレイは、受信機がサブネットに要請していない余分なトラヒックをもたらすこととなる。
【０００６】
このため、所定のグループを残し別のグループを接合するといった受信機による高速グループ走査が行われる際に、重大な問題を引起す可能性がある。すなわち、上記ディレイ中に、ルータは古いグループのトラヒックをサブネットになお転送し、同時に、ルータが新しいグループに対する「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」を受信した直後に新しいグループのトラヒックをサブネットに転送するため、このサブネット上のトラヒックは２倍になってしまうという問題があった。また、スイッチンググループ数が大きいと、余分のトラヒックはサブネットを渋滞させ、同じサブネット内の他のホストへのサービスを犠牲にしてしまうという問題があった。
【０００７】
これらの問題はＩＧＭＰプロトコルの「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を利用したプロセスに起因するため、ＩＧＭＰプロトコルに基づく任意のマルチキャスト方式はその問題を受継ぐことになる。
【０００８】
本発明は、上記従来の問題に鑑みてなされたものであって、サブネット上のトラヒックを効率化して小さくすることのできるストリーミング制御装置を提供することを目的としている。
【０００９】
【課題を解決するための手段】
上記課題を解決するために、上記目的を達成するために、本発明に係るストリーミング制御装置は、受信機からの要求に応じてマルチキャストでコンテンツを配信するストリーミング制御装置であって、データ配信源から入力されたユニキャストトラヒックをマルチキャストトラヒックに変換するトラヒック変換手段と、前記コンテンツの転送状況および前記コンテンツの配信を要求した前記受信機を記憶したマルチキャストトラヒック転送情報データベースに記憶されている情報と、所定の規則とに基づいて、前記トラヒック変換手段によって変換されたマルチキャストトラヒックを配信するトラヒック配信手段と、を備えている。
【００１０】
したがって、マルチキャストトラヒック転送情報データベースに記録されている受信機の情報によって、同じトラヒックを要請する受信機が他に存在するかを直ちに知ることができるため、受信機が存在しない場合にはトラヒックの配信をすぐに停止できる。この結果、トラヒックを効率化して小さくすることができる。
【００１１】
また、本発明に係るストリーミング制御装置は、所定の間隔でＩＧＭＰメッセージを作成し送信するメッセージ送信手段と、前記メッセージ送信手段から送信された前記ＩＧＭＰメッセージと前記ＩＧＭＰメッセージの送信に対する応答に基づいて、マルチキャストトラヒック転送用の情報を更新する情報更新手段と、前記ＩＧＭＰメッセージを送信する間隔を構成する間隔設定手段と、を備えている。
【００１２】
また、本発明に係るストリーミング制御装置は、前記トラヒック変換手段は、前記データ配信源から入力されたユニキャストトラヒックのデータパケットを選択するデータパケット選択手段と、前記データパケット選択手段によって選択されたユニキャストトラヒックのデータパケットをマルチキャストトラヒックのデータパケットに変換するデータ変換手段と、を有する。
【００１３】
また、本発明に係るストリーミング制御装置は、前記マルチキャストポートで前記ＩＧＭＰメッセージを受信する際に、前記ＩＧＭＰメッセージがインターネットグループ用の「Ｍｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」であれば、そのメッセージに対応するマルチキャストグループ用のトラヒックの転送を可能にして、対応するマルチキャストグループ用のデータベースに受信機を登録し、前記ＩＧＭＰメッセージが「Ｌｅａｖｅ＿Ｇｒｏｕｐメッセージ」であれば、対応するマルチキャストグループ用のデータベースに登録されている受信機を除去し、その受信機がグループに連動しない場合に対応するマルチキャストグループ用のトラヒックの転送を無効にするようにして前記マルチキャストトラヒック転送情報データベースを更新するデータベース更新手段を備えている。
【００１４】
また、本発明に係るストリーミング制御装置は、前記トラヒック配信手段および前記データベース更新手段が、前記マルチキャストトラヒック転送情報データベースを共有する。
【００１５】
また、本発明に係るストリーミング制御装置は、マルチキャストトラヒックのデータパケットを出力する複数の出力リンクと、ユニキャストトラヒックのデータパケットを入力する複数の入力リンクと、を備えている。
【００１６】
また、本発明に係るストリーミング制御装置は、前記入力リンクが前記出力リンクの機能を備え、前記出力リンクが前記入力リンクの機能を備え、前記入力リンクを複数のデータ配信源に接続し、前記出力リンクを複数の受信機に接続している。
【００１７】
また、本発明に係るネットワークシステムは、本発明のストリーミング制御装置を備えたネットワークシステムであって、前記受信機が任意クラスタの任意のデータ配信源からデータストリームを受信可能であり、前記データ配信源に接続されたスイッチに前記ストリーミング制御装置が接続され、前記スイッチ経由で前記受信機に前記ストリーミング制御装置の各出力を接続することにより、前記データ配信源と前記受信機の複数のクラスタを支援するようネットワークが構成されている。
【００１８】
このように、ハードウェアによる制限によらずに任意の数のデータ配信源と受信機を有することのできるフレームワークが形成されるよう、複数のストリーミング制御装置が相互接続されたネットワーク構造を可能としている。
【００１９】
さらに、本発明に係るネットワークシステムは、前記ストリーミング制御装置は、高周波で前記データ配信源間を切り換えるために用いられる。
【００２０】
【発明の実施の形態】
本発明に係るストリーミング制御装置は、ＩＧＭＰプロトコルに係るＩＧＭＰメッセージを扱い、ＩＧＭＰプロトコルで動作するルータサイドでのプロセスで活用される。また、ストリーミング制御装置は、受信機の情報を含むマルチキャストトラヒック転送情報データベースを管理する。より具体的には、受信機がＩＧＭＰメッセージである「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」および「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」をストリーミング制御装置に送信するたびに、ストリーミング制御装置はそれぞれのメッセージを送信した受信機を記録又は記録の削除を行う。記録された受信機の情報によって、ストリーミング制御装置は同じトラヒックを要請する受信機が他に存在するかを直ちに知ることができるため、受信機が存在しない場合には転送をすぐに停止できるといった利点がある。
【００２１】
さらに、ストリーミング制御装置は、ユニキャストトラヒックをマルチキャストトラヒックに変換するエンジンを有する。これは、「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」による遅延の影響が最小となるように、マルチキャストトラヒックのスターティングポイントをより受信機側にするためのものである。また、ハードウェアによる制限によらずに任意の数のデータ配信源と受信機を有することのできるフレームワークが形成されるよう、複数のストリーミング制御装置が相互接続されたネットワーク構造を可能としている。
【００２２】
以下、本発明に係るストリーミング制御装置の実施の形態について、図面を参照して詳細に説明する。本実施形態のストリーミング制御装置は、例えばＩＰをベースとしたデジタルセキュリティシステムにおける高速グループスイッチングを支援する装置を提供する。
【００２３】
本実施形態のストリーミング制御装置はＩＰネットワーク上に配置される。当該ストリーミング制御装置が適切に機能するために、受信機はＩＧＭＰホストサイドのスタックを有する必要がある。すなわち、この受信機はマルチキャストトラヒックをストリーミング制御装置に要請したり、所定のマルチキャストグループをストリーミング制御装置に残すためにＩＧＭＰメッセージを利用する。
【００２４】
また、本実施形態のストリーミング制御装置は、ＲＦＣ２２３６に対応したＩＧＭＰメッセージを処理するエンジンを有するため、ネットワーク内の他のネットワークノードはスタックへの修正なくマルチキャスト信号化にＩＧＭＰを使用できる。本実施形態のストリーミング制御装置がネットワーク内に設けられると、データ配信源は、ユニキャストトラヒックを宛先アドレス（Ｕ２Ｍアドレス）を有する当該ストリーミング制御装置に送信し、ストリーミング制御装置がトラヒックを受信すると当該トラヒックをマルチキャストに変換する。
【００２５】
また、受信機が所定グループのトラヒックの受信を要請する場合、受信機はそのグループの「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ＿ｒｅｐｏｒｔメッセージ」を本実施形態のストリーミング制御装置に送信する。ストリーミング制御装置がこのメッセージを受信すると、前記所定のグループのトラヒックを受信機が接続されたポートに転送し、同時に受信機の情報をマルチキャストトラヒック転送情報データベースに記録する。一方、受信機が所定グループのトラヒックの受信の停止を要請する場合、受信機はそのグループの「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を本実施形態のストリーミング制御装置に送信する。ストリーミング制御装置がこのメッセージを受信するとマルチキャストトラヒック転送情報データベースを調べ、他の受信機が同じポート上で同じグループのトラヒックを要請していないなら、そのポートにグループのトラヒックを転送するのを停止する。
【００２６】
実際は、１つのストリーミング制御装置では、ハードウェアの限界のため所定数のデータ配信源しかサポートできない。このため、より多くのデータ配信源をサポートするために、いくつかのストリーミング制御装置がネットワークアーキテクチャにより運用可能となる。したがって、相互接続装置はデータ配信源と受信機の任意のクラスタをサポートできる。
【００２７】
本実施形態のストリーミング制御装置は、手動またはあるソフトウェアによって設定および制御される。このソフトウェアは本実施形態のストリーミング制御装置内または遠隔ホスト上で実行される。本実施形態のストリーミング制御装置がこのソフトウェアからのメッセージを受け取ることにより、当該ソフトウェアはリアルタイムに当該ストリーミング制御装置を制御することができる。
【００２８】
ストリーミング制御装置は自らを通るトラヒックに関する統計情報を記録して、当該情報は外部記憶装置に保存される。したがって、本実施形態のストリーミング制御装置または遠隔ホストで動作するソフトウェアは、特定の種類のメッセージによってリアルタイムにこの情報を検索することができる。
【００２９】
また、本実施形態のストリーミング制御装置内に設けられたエンジンは、設定ツールによって動作時に利用可能または利用不可能にすることが出来る。ストリーミング制御装置は、エンジンのいくつかが利用不可能となっている場合、一般のネットワークの役割を果たす。例えば、ユニキャスト／マルチキャスト変換エンジンが無効の場合、当該装置は高速グループスイッチングによってマルチキャストルータとして動作する。
【００３０】
以下、ＩＰベースのデジタルセキュリティシステムにおいて、オーディオビジュアルコンテンツを配信するストリーミング制御装置を使用した例について説明する。本実施形態のストリーミング制御装置は、ユニキャストからマルチキャストへの変換およびパケット転送を行う装置であり、ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）プロトコルによる「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ−Ｒｅｐｏｒｔメッセージ」、「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」および「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」を送出する。なお、以下の説明において、これらの用語は以下の意味として用いられる。
【００３１】
まず、「パケット」は、ネットワーク上で配信されるデータの構成単位である。また、「ストリーム」は、共通の属性を持つネットワークに転送されるパケットの集結である。また、「トラヒック」は、ネットワーク上を転送するストリームの集結である。また、「フロー」は、ストリームを配信するのに用いられるデータパスのことである。また、「ＱｏＳ」は、データストリームやトラヒックの「サービス品質」という用語である。また、「ＱｏＳプローブ」は、ネットワーク構成要素の１つでのフローのＱｏＳを測り、知らせる装置のことである。また、「ＮＥ」は、ネットワークルータやゲートウエイ、インテリジェントネットワークハブとして機能するように用いられるネットワーク構成要素のことである。また、「上位層」は、本実施形態のストリーミング制御装置から送信されたパケットを処理する装置の上部の任意のエンティティ（ｅｎｔｉｔｙ）のことである。
【００３２】
図１は、ユニキャストデータパケットトラヒックをマルチキャストデータパケットトラヒックに変換し、受信機からの要請に基づいて受信機に転送するストリーミング制御装置を示すブロック図である。同図に示す本実施形態のストリーミング制御装置は、４つの主要な構成要素、すなわち、Ｕ２Ｍ変換転送エンジン１０１と、照会および状態更新エンジン１０２と、サブＩＧＭＰ処理エンジン１０３と、転送および受信機登録テーブル１０４とを備えて構成されている。
【００３３】
なお、同図に示したストリーミング制御装置の構造は説明用に簡略化されており、実際の物理的アーキテクチャを反映しているとは限らない。また、実際には、当該装置はより複雑なアーキテクチャと特別のエンジンを有することができる。さらに、図１では主要なデータパスのみを示す。
【００３４】
図１に示すデータパスとは、照会および状態更新エンジン１０２からＵ２Ｍ変換転送エンジン１０１へのデータパスＡ、照会および状態更新エンジン１０２と転送および受信機登録テーブル１０４の間のデータパスＢ、Ｕ２Ｍ変換転送エンジン１０１と転送および受信機登録テーブル１０４の間のデータパスＣ、サブＩＧＭＰ処理エンジン１０３と転送および受信機登録テーブル１０４の間のデータパスＤ、およびＵ２Ｍ変換転送エンジン１０１とサブＩＧＭＰ処理エンジン１０３の間のデータパスＥ、サブＩＧＭＰ処理エンジン１０３から照会および状態更新エンジン１０２へのデータパスＦである。図１に示すように、データパスＡ，Ｆは一方向性であり、他のデータパスＢ，Ｃ，Ｄ，Ｅは双方向性である。データパスの方向はデータパス上での情報の流れの方向を示す。
【００３５】
実際には、より多くのデータパスが存在しており、特別の制御パスやシグナリングパスがある。図１に示すＵ２Ｍ変換転送エンジン１０１やサブＩＧＭＰ処理エンジン１０３は、例えばＦＰＧＡ等のハードウェア法により、あるいはソフトウェアモジュールとして実施される。これらのエンジンがハードウェア内で実施される場合に、データパスはこれらのエンジン間を物理的に接続する役割を果たす。これらのエンジンがソフトウェアモジュールとして実施されるなら、図１に示したデータパスはこれらのモジュール間のインターフェイスを示すことになる。
【００３６】
図１に示すように、データ配信源からのユニキャストトラヒックはユニキャストポートからＵ２Ｍ変換転送エンジン１０１に入力される。Ｕ２Ｍ変換転送エンジン１０１は所定の規則に基づいてトラヒックを処理し、得られたトラヒックを転送および受信機登録テーブル１０４に記憶した情報と所定の規則とに基づいて出力ポートに転送する。
【００３７】
図２は、Ｕ２Ｍ変換転送エンジン１０１の状態遷移図である。同図に示すように、Ｕ２Ｍ変換転送エンジン１０１は６つの状態、初期化を行う初期化状態２０１、各種条件に応じて他の状態に遷移するアイドル状態２０２、パケットのユニキャスト／マルチキャスト変換を行うＵ２Ｍ変換状態２０３、パケットの転送を行う転送状態２０４、ユニキャストパケットを転送するフォワードユニキャスト状態２０５およびパケットを上位層に転送して処理する上位層状態２０６のいずれかをとり得る。
【００３８】
Ｕ２Ｍ変換転送エンジン１０１は初期化状態２０１から始まる。図３は、初期化状態２０１のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。図３に示すように、Ｕ２Ｍ変換転送エンジン１０１はハードウェア構成を読み取る（Ｓ２１０１）。当該ステップＳ２１０１では、ポート、ユニキャストポートアドレスおよびマルチキャストポートアドレスの数の読み取りが可能であるが、より多くの属性を読み取ることができる。次に、Ｕ２Ｍ変換転送エンジン１０１はユーザ構成を読み取る（Ｓ２１０２）。当該ステップＳ２１０２は、ユニキャスト・マルチキャスト方式、Ｕ２Ｍ変換用のユニキャストアドレス、装置のＩＰアドレス、変換用のマルチキャストグループおよび同一カメラを同時に見るようにサポートした受信機数等の読み取りを含むが、これらに限定されない。
【００３９】
次に、Ｕ２Ｍ変換転送エンジン１０１は、上記ステップＳ２１０１，Ｓ２１０２で読み取った構成に対応して「ｆｏｒｗａｒｄ＿ｃｏｎｄｉｔｉｏｎ＿ｔｂｌテーブル」および「ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌテーブル」を作成し初期化する（Ｓ２１０３）。これらのテーブルは図１に示した転送および受信機登録テーブル１０４であり、ＲＯＭやメモリブロックとしてハードウェア内に記録されることが可能である。２つのテーブルの初期値は任意の値をとる。例えば、「ｆｏｒｗａｒｄ＿ｃｏｎｄｉｔｉｏｎ＿ｔｂｌテーブル」の値を−１に設定し、「ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌテーブル」の値を０に設定する。
【００４０】
初期化状態２０１の後はアイドル状態２０２となる。図４は、アイドル状態２０２のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。なお、以下に説明するステップは、Ｕ２Ｍ変換転送エンジン１０１がアイドル状態２０２から別の状態に遷移するときに実行される。また、当該遷移を誘発する事象はパケットの到来であると仮定する。また、その他の点では、アイドル状態２０２に戻るデフォルト遷移が発生する。
【００４１】
図４に示すように、Ｕ２Ｍ変換転送エンジン１０１は、前記事象を引き起こすパケットを得る（Ｓ２２０１）。次に、Ｕ２Ｍ変換転送エンジン１０１は、ステップＳ２２０１で得られたパケットがユニキャストポートからのものかを判断し（Ｓ２２０２）、ユニキャストポートからのものであればステップＳ２２０３に進み、そうでなければステップＳ２２０４に進む。ステップＳ２２０３では、ステップＳ２２０１で得られたパケットの宛先アドレスを得る。次に、この宛先アドレスを配列済みＵ２Ｍアドレスと比較して両アドレスが等しいかを判断し（Ｓ２２０５）、等しい場合はステップＳ２２１０に進み、等しくない場合はステップＳ２２０８に進む。ステップＳ２２１０では、「ｕｎｉｃａｓｔ＿ｐｋｔ＿ｄｅｓｔｉｎｅｄ＿ｕ２ｍ＿ａｄｄｒｅｓｓ条件」（変換するパケットの変換後のユニキャストアドレス）を設定し、Ｕ２Ｍ変換転送エンジン１０１はＵ２Ｍ変換状態２０３に遷移する。
【００４２】
一方、ステップＳ２２０８（宛先アドレスがＵ２Ｍアドレスに等しくない場合）では、ステップＳ２２０２で取得された宛先アドレスが装置自身のＩＰアドレスに等しいかを判断し、等しい場合はステップＳ２２０９に進み、等しくない場合はステップＳ２２１１に進む。ステップＳ２２０９では、「Ｏｔｈｅｒ＿ｐａｃｋｅｔ＿ｄｅｓｔｉｎｅｄ＿ｆｏｒ＿Ｕ２Ｍｂｏｘ条件」を設定し、上位層状態２０６に遷移する。一方、ステップＳ２２１１では、「Ｕｎｉｃａｓｔ＿ｎｏｔ＿ｆｏｒ＿Ｕ２Ｍ条件」を設定し、Ｕ２Ｍ変換転送エンジン１０１はフォワードユニキャスト状態２０５に遷移する。
【００４３】
ステップＳ２２０２による判断の結果、ステップＳ２２０１で得られたパケットがユニキャストポートからのものでない場合はステップＳ２２０４に進む。ステップＳ２２０４では、前記パケットがサブＩＧＭＰ処理エンジン１０３からのものかを判断し（Ｓ２２０４）、サブＩＧＭＰ処理エンジン１０３からのものであればステップＳ２２０６に進み、そうでなければステップＳ２２０７に進む。ステップＳ２２０６では、「Ｐｋｔ＿ｆｒｏｍ＿Ｓｕｂ−ＩＧＭＰ＿ｅｎｇｉｎｅ条件」を設定し、Ｕ２Ｍ変換転送エンジン１０１はフォワードユニキャスト状態２０５に遷移する。一方、ステップＳ２２０７では、「Ｑｕｅｒｙ＿ｐｋｔ＿ｆｒｏｍ＿Ｑｕｅｒｙ＿ｅｎｇｉｎｅ条件」を設定し、Ｕ２Ｍ変換転送エンジン１０１は転送状態２０４に遷移する。
【００４４】
上述したように、「ｕｎｉｃａｓｔ＿ｐｋｔ＿ｄｅｓｔｉｎｅｄ＿ｕ２ｍ＿ａｄｄｒｅｓｓ条件」がアイドル状態２０２からの遷移条件として設定されると、Ｕ２Ｍ変換転送エンジン１０１はＵ２Ｍ変換状態２０３に遷移する。図５は、Ｕ２Ｍ変換状態２０３のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。同図に示すように、Ｕ２Ｍ変換転送エンジン１０１は、まず、遷移を誘発するパケットの配信源アドレスを得る（Ｓ２３０１）。次に、ユニキャスト／マルチキャスト変換（Ｕ２Ｍ変換）を構成方式に基づくパケットに適用する。
【００４５】
変換方式はいくつか考えられ、当該Ｕ２Ｍ変換転送エンジン１０１は、現ワーキング方式として構成されるもののいずれか１つに従うことになる。例えば、Ｕ２Ｍ変換転送エンジン１０１は、全パケットの宛先アドレスフィールドを同じマルチキャストグループアドレスに変更することにより、全トラヒックを１つの構成済みマルチキャストグループに変換できる。また、Ｕ２Ｍ変換転送エンジン１０１は、トラヒックの配信源アドレスに基づくトラヒックを変換できる。１つの方法では、最初の宛先アドレスの低８ビットを貯え、かつ、宛先アドレスの高２４ビットをマルチキャストグループアドレスプレフィックスに設定することにより可能であるが、非常に多くの方式が考えられる。
【００４６】
次に、Ｕ２Ｍ変換転送エンジン１０１は、ステップＳ２３０２における変換後に、新しい宛先アドレスをパケット宛先アドレスフィールドに設定する（Ｓ２３０３）。そして、Ｕ２Ｍ変換転送エンジン１０１は、Ｕ２Ｍ変換状態２０３の処理を終えた後、転送状態２０４に遷移する。但し、この遷移は保護されない。
【００４７】
上述したように、「Ｑｕｅｒｙ＿ｐｋｔ＿ｆｒｏｍ＿Ｑｕｅｒｙ＿ｅｎｇｉｎｅ条件」がアイドル状態２０２からの遷移条件として設定されると、Ｕ２Ｍ変換転送エンジン１０１は転送状態２０４に遷移する。図６は、転送状態２０４のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。同図に示すように、Ｕ２Ｍ変換転送エンジン１０１は、まず、パケットの宛先アドレスから、「ｇｒｐ＿ｉｎｄｅｘ」、「テーブルの指数」を計算する（Ｓ２４０１）。なお、宛先アドレスから「ｇｒｐ＿ｉｎｄｅｘ」への写像方法は構成可能である。簡単な一事例は、指数として宛先アドレスの低８ビットを用いることであるが、非常に多くの写像方式が考えられ、上記説明は唯一の方法ではない。
【００４８】
「ｇｒｍ＿ｉｎｄｅｘ」を得た後に「ｆｏｒｗａｒｄ＿ｃｏｎｄｉｔｉｏｎ＿ｔｂｌ」テーブルを調べて、このグループのパケットに対する要請を持つポートがあるかを検討すると共に、宛先アドレスがａｌｌ＿ＤＲＰアドレス：２２４．０．０．１であるかを調べる（Ｓ２４０２）。このグループのトラヒックに対する要請を持つポートがあるか、宛先アドレスが「２２４．０．０．１」であれば、パケットは複製され、そのポートに転送される。これらのプロセスは、Ｕ２Ｍ変換転送エンジン１０１がハードウェア内で実施される場合に並列に行われる。このグループのトラヒックに対する要請を持つポートがない場合、このパケットは廃棄され、関連する配信源は開放される。転送状態２０４の後、Ｕ２Ｍ変換転送エンジン１０１はアイドル状態２０２に逆遷移する。
【００４９】
上述したように、「Ｐｋｔ＿ｆｒｏｍ＿Ｓｕｂ−ＩＧＭＰ＿ｅｎｇｉｎｅ条件」、「ｕｎｉｃａｓｔ＿ｎｏｔ＿ｆｏｒ＿Ｕ２Ｍ条件」または「ｂｒｏａｄｃａｓｔ＿ｐｋｔ条件」がアイドル状態２０２からの遷移条件として設定されるとすると、Ｕ２Ｍ変換転送エンジン１０１はフォワードユニキャスト状態２０５に遷移する。図７は、フォワードユニキャスト状態２０５のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。同図に示すように、Ｕ２Ｍ変換転送エンジン１０１は、まず、パケットを得て出力ポート指数を転送して計算する（Ｓ２５０１）。この出力ポート指数はボックスに設定した規則に基づいて計算される。なお、当該規則は構成可能であり、後述する。次に、Ｕ２Ｍ変換転送エンジン１０１は、ユニキャストパケットを出力ポートに転送する（Ｓ２５０２）。但し、前記規則がこのパケットを必要とするポートがないことを示すのであれば、このパケットはドロップされ、関連する配信源は開放される。
【００５０】
上述したように、「Ｏｔｈｅｒ＿ｐａｃｋｅｔ＿ｄｅｓｔｉｎｅｄ＿ｆｏｒ＿Ｕ２Ｍｂｏｘ条件」がアイドル状態２０２からの遷移条件として設定されると、Ｕ２Ｍ変換転送エンジン１０１は上位層状態２０６に遷移する。図８は、上位層状態２０６のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。同図に示すように、Ｕ２Ｍ変換転送エンジン１０１は、パケットを上位層状態２０６に送信して処理する（Ｓ２６０１）。なお、上位層状態２０６はパケットのコンテンツを読み取り、それに従って動作する任意のハードウェアやソフトウェアモジュールである。
【００５１】
図９は、図１に示した照会および状態更新エンジン１０２の状態遷移図である。当該照会および状態更新エンジン１０２は、「ＩＧＭＰｇｅｎｅｒａｌ＿ｑｕｅｒｙメッセージ」を周期的に発生する機能および転送および受信機登録テーブル１０４を維持する機能を有する。
【００５２】
照会および状態更新エンジン１０２は初期化状態３０１から始まる。図１０は、初期化状態３０１の照会および状態更新エンジン１０２が行う動作について説明するフローチャートである。図１０に示すように、照会および状態更新エンジン１０２は、本実施形態のストリーミング制御装置に「Ｅｎａｂｌｅ＿Ｑｕｅｒｙ」を設定する（Ｓ３１０１）。同一ネットワーク内に複数の装置がある場合、唯一の装置は照会器（ｑｕｅｒｉｅｒ）であり、「ＩＧＭＰｇｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」を送信する。どの装置を照会器にするかについての決定は、後述するが、手動または所定の特定プロトコルによって行われる。
【００５３】
次に、照会および状態更新エンジン１０２は、照会（Ｑｕｅｒｙ）が有効かを判断し（Ｓ３１０２）、有効である（装置が照会器として構成されている）場合はステップＳ３１０３に進み、有効でない（照会器として構成されていない）場合は一連の処理を終了する。ステップＳ３１０３では、照会および状態更新エンジン１０２は、本実施形態のストリーミング制御装置から照会間隔の構成を得る（Ｓ３１０３）。なお、所定のデフォルト値は装置内に送信され、任意に手動または特定のプトロコルを通じて修正される。基本的に、間隔が短くなればなるほど、バースト性になり、より多くのＩＧＭＰメッセージは同一周期内にサブＩＧＭＰ処理エンジン１０３により処理される必要がある。一方、間隔が長くなればなるほど、「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」がリンク上で失われた場合に、本実施形態のストリーミング制御装置がマルチキャストトラヒックの転送を停止する前に長い時間を要する。
【００５４】
次に、照会および状態更新エンジン１０２は、「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」を形成する（Ｓ３１０４）。当該メッセージは上記照会間隔に合わせた最大応答時間を持つＲＦＣ２２３６に基づいて形成される必要がある。「ＩＧＭＰＧｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」は常に同じ状態のままであるので、この形成された「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」は後で再利用される。次に、照会および状態更新エンジン１０２は、照会タイマーを始動する（Ｓ３１０５）。照会タイマーの長さは上述のように照会間隔に設定される。そして、照会および状態更新エンジン１０２は、アイドル状態３０２に遷移する。但し、この遷移は保護されない。この遷移に伴う行動は、照会タイマー（Ｑｕｅｒｙ＿Ｔｉｍｅｒ）を設定することである。
【００５５】
照会および状態更新エンジン１０２は、本実施形態のストリーミング制御装置が照会器として構成されているときに「Ｑｕｅｒｙ＿ｔｉｍｅｒ＿ｅｘｐｉｒｅ条件」が設定されると、アイドル状態３０２から更新状況テーブル状態３０３に遷移する。但し、この場合以外は、サブＩＧＭＰ処理エンジン１０３が信号を送信する。図１１は、更新状況ステーブル状態３０３の照会および状態更新エンジン１０２が行う動作について説明するフローチャートを示す。図１１に示すように、ステップＳ３３０１では、各グループに対するマルチキャストポートのカウンタ値の各々が０（ゼロ）でなければＦｏｗａｒｄ＿ｓｔａｔｕｓ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］の値を減じ、０に達するとｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］をリセットする。当該ステップは全ポートと全グループに対して行われ、ハードウェアと並列に実行されるように実施される。
【００５６】
照会および状態更新エンジン１０２は、本実施形態のストリーミング制御装置が照会器として構成されているときに更新状況テーブル状態３０３から照会状態３０４に遷移する。但し、この場合以外は、アイドル状態３０２に遷移する。図１２は、照会状態３０４の照会および状態更新エンジン１０２の動作について説明するフローチャートを示す。図１２に示すように、ステップＳ３２０１では、データパス１を通じて「ＦｏｒｍｅｄＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」をＵ２Ｍ変換転送エンジン１０１に送信する。そして、照会および状態更新エンジン１０２は照会状態３０４からアイドル状態３０２に遷移する。この遷移時には、照会タイマー（Ｑｕｅｒｙ＿Ｔｉｍｅｒ）に予め与えられた値を設定する。
【００５７】
図１３は、図１に示したサブＩＧＭＰ処理エンジン１０３の状態遷移図である。当該サブＩＧＭＰ処理エンジン１０３は、マルチキャストポートで受信したＩＧＭＰメッセージを処理し、それに応じて転送および受信機登録テーブル１０４の更新を行う。サブＩＧＭＰ処理エンジン１０３は、ユニキャストポートで受信したユニキャストパケットを転送する。または、Ｕ２Ｍ変換転送エンジン１０１は、本実施形態のストリーミング制御装置に予め設定された規則に従った動作を行う。
【００５８】
サブＩＧＭＰ処理エンジン１０３は初期化エンジン４０１状態から始まる。図１４は、初期化エンジン４０１状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。図１４に示すように、サブＩＧＭＰ処理エンジン１０３は、本実施形態のストリーミング制御装置にハードウェア設定を行う（Ｓ４１０１）。当該設定は、ユニキャストポートのアドレス、マルチキャストポートのアドレスおよびマルチキャストポート数等を含む。
【００５９】
次に、サブＩＧＭＰ処理エンジン１０３は、本実施形態のストリーミング制御装置からソフトウェア設定を得る（Ｓ４１０２）。可能な設定項目は、装置のＩＰアドレス、ネットワークロバスト設定、当該装置が照会器であるかどうか、およびコントローラポートのアドレス等である。次に、サブＩＧＭＰ処理エンジン１０３は、上記ステップで得た設定により必要とされる場合に、ユニキャスト転送テーブルを初期化する（Ｓ４１０３）。
【００６０】
次に、サブＩＧＭＰ処理エンジン１０３は、初期化エンジン４０１からアイドル４０２状態に遷移する。本実施形態では、アイドル４０２状態からの遷移はパケットの到来により行われ、他の事象はアイドル４０２状態自身への遷移を行う「ｄｅｆａｕｌｔ」のカテゴリーに入るものと仮定する。なお、事象には多くの種類があり、当該仮定は説明の便宜性のためにのみ行われる。
【００６１】
図１５は、アイドル４０２状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。なお、以下に説明するプロセスは、サブＩＧＭＰ処理エンジン１０３がアイドル４０２状態から他の状態に遷移するときに実行される。図１５に示すように、サブＩＧＭＰ処理エンジン１０３は、イベントを誘発するパケットを得る（Ｓ４２０１）。次に、サブＩＧＭＰ処理エンジン１０３は、ステップＳ４２０１で取得されたパケットがＩＰパケットであるかを判断し（Ｓ４２０２）、ＩＰパケットである場合はステップＳ４２０３に進み、ＩＰパケットでない場合はステップＳ４２０７に進む。
【００６２】
ステップＳ４２０７（ＩＰパケットでない場合）では、「Ｏｔｈｅｒ＿ｐａｃｋｅｔ条件」を設定し、サブＩＧＭＰ処理エンジン１０３はドロップパケット４０６状態に遷移する。一方、ステップＳ４２０３（ＩＰパケットである場合）では、ステップＳ４２０１で取得されたパケットがＩＧＭＰパケットであるかをパケットのヘッダ情報を調べることにより判断し（Ｓ４２０３）、ＩＧＭＰパケットでない場合はステップＳ４２０４に進み、ＩＧＭＰである場合はステップＳ４２０５に進む。なお、ヘッダ情報において、ＩＧＭＰパケットはクラスＤのＩＰアドレスでタイプ２である。
【００６３】
ステップＳ４２０４（ＩＧＭＰパケットでない場合）では、当該パケットがユニキャストパケットであるかを判断し（Ｓ４２０４）、ユニキャストパケットであればステップＳ４２０６に進み、ユニキャストパケットでなければ上記説明したステップＳ４２０７に進んでドロップパケット４０６状態に遷移する。ステップＳ４２０６（ユニキャストパケットである場合）では、「ｕｎｉｃａｓｔ＿ｐｋｔ＿ｒｅｃｅｉｖｅｄ条件」を設定し（Ｓ４２０６）、サブＩＧＭＰ処理エンジン１０３はユニキャストフォワード４０５状態に遷移する。
【００６４】
ステップＳ４２０３でＩＧＭＰパケットであると判断された場合はステップＳ４２０５に進むが、当該ステップＳ４２０５では、当該パケットのＩＧＭＰタイプおよびグループフィールドを得る。次に、ステップＳ４２０８では、本実施形態のストリーミング制御装置における設定を基準としてグループアドレスを調べ、タイプフィールドが「ｍｅｍｂｅｒｓｈｉｐ＿ｒｅｐｏｒｔ」または「Ｌｅａｖｅ＿Ｇｒｏｕｐ」に等しいか、すなわち、ＩＧＭＰグループがマルチキャストグループプレフィックスと一致し、「ｍｅｍｂｅｒｓｈｉｐ＿ｒｅｐｏｒｔメッセージ」または「Ｌｅａｖｅ＿Ｇｒｏｕｐメッセージ」であるかを判断する（Ｓ４２０８）。当該ステップＳ４２０８において、等しければステップＳ４２０９に進み、等しくなければステップＳ４２１０に進む。
【００６５】
ステップ４２０９（等しい場合）では、「Ｒｅｃｅｉｖｅｄ＿ＩＧＭＰ＿ｍｅｍｂｅｒｓｈｉｐ＿ｒｅｐｏｒｔ＿ｐｋｔ条件」または「Ｒｅｃｅｉｖｅ＿ＩＧＭＰ＿Ｌｅａｖｅ＿ｇｒｏｕｐ＿ｐｋｔ条件」をタイプフィールドに基づいて設定し、サブＩＧＭＰ処理エンジン１０３は結合報告４０３状態またはリーブ報告４０４状態に遷移する。一方、ステップＳ４２１０（等しくない場合）では、メッセージが「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」であるか、本実施形態のストリーミング制御装置が非照会器であるかを判断する。当該ステップＳ４２１０において、上記２つの条件を満たせばステップＳ４２１１に進み、満たさなければステップＳ４２０７に進んで、サブＩＧＭＰ処理エンジン１０３はドロップパケット４０６状態に遷移する。ステップＳ４２１１では、「ｎｏｎ−Ｑｕｅｒｉｅｒ＆＆ＩＧＭＰ＿ｇｅｎｅｒａｌ＿ｑｕｅｒｙ条件」を設定し、サブＩＧＭＰ処理エンジン１０３はトリガ照会エンジン４０７状態に遷移する。
【００６６】
次に、サブＩＧＭＰ処理エンジン１０３は、「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」を受信するとアイドル４０２状態から結合報告４０３状態に遷移する。図１６は、結合報告４０３状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。図１６に示すように、サブＩＧＭＰ処理エンジン１０３は、パケットを受信するポート番号「ｐｏｒｔ＿Ｎｏ」を得る（Ｓ４３０１）。次に、パケット内のグループアドレスは、Ｕ２Ｍ変換転送エンジン１０１の転送状態で使用される同じハッシュ関数により、グループ指数「ｇｒｐ＿ｉｎｄｅｘ」に写像される（Ｓ４２０２）。次に、サブＩＧＭＰ処理エンジン１０３は、「Ｆｏｒｗａｒｄ＿ｓｔａｔｕｓ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］テーブル」の対応セルをマルチキャストトラヒックの転送（フォワード）を可能にする値に設定する（Ｓ４３０３）。
【００６７】
次に、サブＩＧＭＰ処理エンジン１０３は、ＩＧＭＰメッセージの配信源アドレスを得て、受信機登録テーブル「ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌ」の対応セルの対応ビットをセットする（Ｓ４３０４）。次に、当該セルのビットを「Ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］テーブル」に設定する（Ｓ４３０５）。なお、この操作はビットマップである必要はなく、任意形態で記録することも可能であり、受信機登録テーブルも多次元であり得る。以上のステップが行われるとメッセージパケットは破壊され、関連する配信源が開放される（Ｓ４３０６）。そして、サブＩＧＭＰ処理エンジン１０３は結合報告４０３状態からアイドル４０２状態に逆遷移する。
【００６８】
同じく、サブＩＧＭＰ処理エンジン１０３は、「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を受信すると、アイドル４０２状態からリーブ報告４０４状態に遷移する。図１７は、リーブ報告４０４状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。ステップＳ４４０１，Ｓ４４０２，Ｓ４４０３は、図１６に示した結合報告４０３状態のサブＩＧＭＰ処理エンジン１０３が行うステップＳ４３０１，Ｓ４３０２，Ｓ４３０４と同様であり、ハッシング関数と写像法は両者にとって同じである。当該３つのステップの後に、サブＩＧＭＰ処理エンジン１０３は受信機登録テーブル「Ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］テーブル」の対応ビットを得る（Ｓ４４０４）。次に、対応ビットを設定するかを判断する（Ｓ４４０５）。これは、ソースがこのグループの「Ｍｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」を前に送信したかを調べる。配信源が当該グループを要請してない場合、サブＩＧＭＰ処理エンジン１０３は「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を処理しない。
【００６９】
ステップＳ４４０５において対応ビットを設定した場合、すなわち、配信源が「Ｍｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」を送信した場合、ステップＳ４４０６に進んで、対応ビットの設定を解除して未設定とする（Ｓ４４０６）。次に、サブＩＧＭＰ処理エンジン１０３は、それがこのポート上のグループを離れる最後の受信機であるかどうかを判断し（Ｓ４４０７）、最後の受信機であればステップＳ４４０８に進む。当該ステップＳ４４０８では、転送状況テーブル内の対応セルＦｏｒｗａｒｄ＿ｓｔａｔｕｓ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］にＵ２Ｍ変換転送エンジン１０１のグループのトラヒックに転送できる値を設定する。以上のステップが行われるとメッセージパケットは破壊され、関連する配信源が開放される（Ｓ４４０９）。そして、サブＩＧＭＰ処理エンジン１０３はリーブ報告４０４状態からアイドル４０２状態に逆遷移する。但し、この遷移は保護されない。
【００７０】
また、サブＩＧＭＰ処理エンジン１０３は、ユニキャストパケットを受信し、これを転送する場合に、アイドル４０２状態からユニキャストフォワード４０５状態に遷移する。図１８は、ユニキャストフォワード４０５状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。図１８に示すように、サブＩＧＭＰ処理エンジン１０３は、ユニキャストパケットを得る（Ｓ４５０１）。次に、転送規則と装置状況を調べて、当該パケットを転送すべきマルチキャストポートを決定する（Ｓ４５０２）。次に、当該パケットをユニキャストポートとステップＳ４５０２で決定したマルチキャストポートに転送する（Ｓ４５０３）。そして、サブＩＧＭＰ処理エンジン１０３は、ユニキャストフォワード４０５状態からアイドル４０２状態に遷移する。
【００７１】
また、サブＩＧＭＰ処理エンジン１０３は、アイドル４０２状態において「Ｏｔｈｅｒ＿ｐａｃｋｅｔ条件」が設定されると、アイドル４０２状態からドロップパケット４０６状態に遷移する。図１９は、ドロップパケット４０６状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。図１９に示すように、サブＩＧＭＰ処理エンジン１０３はパケットをドロップし、関連する配信源を開放する（Ｓ４６０１）。そして、サブＩＧＭＰ処理エンジン１０３はドロップパケット４０６状態からアイドル４０２状態に遷移する。
【００７２】
また、サブＩＧＭＰ処理エンジン１０３は、アイドル４０２状態において「ｎｏｎ＿Ｑｕｅｒｉｅｒ＆＆ＩＧＭＰ＿ｇｅｎｅｒａｌ＿ｑｕｅｒｙ条件」が設定されると、アイドル４０２状態からトリガ照会エンジン４０７状態に遷移する。図２０は、トリガ照会エンジン４０７状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。図２０に示すように、サブＩＧＭＰ処理エンジン１０３は照会および状況更新エンジン１０２に信号を送信し、「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」の到来を示す（Ｓ４７０１）。なお、種々のポートにより受信される同一の「Ｇｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」の複製が複数あり得るので、ＩＰパケットの組合せ番号を用い、これが新しい照会メッセージかどうかを決定する。新しい照会メッセージのみが信号を誘発する。そして、サブＩＧＭＰ処理エンジン１０３は、トリガ照会エンジン４０７状態からアイドル４０２状態に遷移する。
【００７３】
転送および受信機登録テーブル１０４である「Ｆｏｒｗａｒｄ＿ｓｔａｔｕｓ＿ｔｂｌテーブル」および「Ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌテーブル」は、ハードウェアとソフトウェアによって実現される。ソフトウェアで実現される場合、前記テーブルは装置の設定により作成され、動的に修正される。図１に示すように、これらのテーブルは３つのエンジン全てからアクセス（Ｂ、Ｃ、Ｄ）可能であり、照会および状況更新エンジン１０２とサブＩＧＭＰ処理エンジン１０３のみがテーブルのコンテンツへと変化する。したがって、テーブルの同時アクセスを調整する制御が必要であり、当該制御は、ハードウェアで実行される場合はロック信号を利用し、ソフトウェアで実行される場合は例えば「ｍｕｔｅｘ」により行われる。
【００７４】
上述のように、本実施形態のストリーミング制御装置のアーキテクチャはユニキャストポートやマルチキャストポートの数に制限を設けるものでない。このため、本実施形態のストリーミング制御装置は同一エンジンを用いて複数のマルチキャストポートおよびユニキャストポートを伴って容易に実行される。ポート数はむしろ、上記アルゴリズムの代りにハードウェアの限界により決定される。このアーキテクチャはユニキャストポートをマルチキャストポートにでき、この逆も、Ｕ２Ｍ変換転送エンジン１０１とサブＩＧＭＰ処理エンジン１０３を単に組合せるだけで可能になる。
【００７５】
本実施形態のストリーミング制御装置が有するエンジンの機能性が有効や無効になることがある。このエンジンが有効である場合、当該装置は上記のように正常に動作する。一方、エンジンが無効になると、当該装置はトラヒックに対して存在しないこととなり、ブリッジやスイッチのように働く。なお、これらの有効および無効な動作とすることは容易である。例えば、装置のエンジンがハードウェアで実行される場合にはロック信号を使い、装置のエンジンがソフトウェアで実行される場合にはフラグを用いる方法も可能である。これらの動作は遠隔操作で実行できる。
【００７６】
図２１は、本実施形態のストリーミング制御装置を用いて監視システムにサービスを提供する事例のシナリオを示す説明図である。図２１に示すように、特許請求の範囲のスイッチに該当するレイヤー２スイッチにより本装置に接続するカメラ（データ源）の複数のクラスタがある。本装置は同じネットワーク内に存在する。このネットワーク構造は、ネットワークの任意数のカメラへの拡張を促す。ハードウェアの限界、例えばリンク容量のために、一台の装置は所定量までしかカメラ（データ源）を接続することができない。当該構造によれば、この課題を本実施形態のストリーミング制御装置を複数設けることで解決できる。本装置に接続された監視装置はカメラクラスタ内の任意カメラからトラヒックを監視することができる。この監視装置は、カメラの高速スイッチングを行うこともできる。なお、スイッチングの速度はサブＩＧＭＰ処理エンジン１０３の処理速度のみによって決定される。
【００７７】
図２１に示すように、１つ以上の本実施形態のストリーミング制御装置がネットワーク内にあると、レイヤー２スイッチと本装置がループを形成する。取扱いに注意しないと、パケットルーピングの電位問題を引き起すことになる。この問題を解決するために、いくつかの技術が必要とされるが解決策を与える。
【００７８】
上述したように、同じネットワーク内に本実施形態のストリーミング制御装置が複数ある場合、それらの内の１つを照会器とし、それが周期的に「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」を送出する。この照会器の選択は手動または所定プロトコルにより行われる。ネットワークアーキテクチャは対称性なので、複数の装置のうちの任意の１台はネットワークの性能に影響を及ぼさないで照会器として配置される。この選択も配置メッセージにより行われる。例えば、任意の装置は自らを初めに照会器であると認識し、「ＩＧＭＰ＿Ｑｕｅｒｙメッセージ」を送信し始める。１台の装置が他の装置から「Ｇｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」を受信すると、当該装置は送信機のアドレスを調べる。送信機のアドレスがそれ自身のアドレスより小さい場合に非照会器となり、非照会器ルーチンを行う。また、ある既存の良く明示された配置メッセージが同じ目的に使用される。
【００７９】
本実施形態のストリーミング制御装置の動作を行う際、複数のマルチキャストポートが存在する場合は、ポートの１つが別々にパケットを転送する「ｃｏｎｔｒｏｌ＿ｐｏｒｔ」として構成される。「ｃｏｎｔｒｏｌ＿ｐｏｒｔ」の選択は配置時に手動または特定のプロトコルにより行われる。手動の場合、オペレータはモニタに接続されたどのレイヤー２スイッチも選ぶことができ、このスイッチに接続されたマルチキャストポートを装置の「ｃｏｎｔｒｏｌ＿ｐｏｒｔ」であるように配置できる。これは簡単なルーチンで、以下に説明するように容易に達成できる。照会器を識別した後、所定の配列に基づいて「ｃｏｎｔｒｏｌ＿ｐｏｒｔ」としてどんなマルチキャストポートでも選ぶことができる。照会器は制御ポートから送出された「ｃｏｎｔｒｏｌ＿ｐｏｒｔ＿ｍｓｇ」を送信する。非照会器の場合には、非照会器がこのメッセージを受信したポートを「ｃｏｎｔｒｏｌ＿ｐｏｒｔ」として配置する。
【００８０】
ネットワーク内のパケットルーピングを防ぐために用いる規則の例を以下に示す。
Ｕ２Ｍ変換転送エンジン１０１に対しては、（１）パケットがユニキャストポートからであれば、本実施形態のストリーミング制御装置が照会器の場合はマルチキャストポートへの転送、非照会器の場合は「ｃｏｎｔｏｒｏｌ＿ｐｏｒｔ」への転送を行い、（２）パケットがサブＩＧＭＰ処理エンジン１０３からであれば、照会器の場合は受信ポート以外の全ポートへの転送、非照会器の場合はパケットをドロップする。一方、サブＩＧＭＰ処理エンジン１０３に対しては、全マルチキャストパケット（非ＩＧＭＰメッセージ）をドロップする、ユニキャストポートにパケットを転送する、パケットをＵ２Ｍ変換転送エンジン１０１に転送する。
【００８１】
＜規則１＞複数の装置が同一ネットワーク内に存在する場合にパケットを転送する規則
これらの規則は、配置時に設定されるか、あるいは実行時にプロトコルにより遠隔設定されるものである。可能なプロトコルの事例は、ＴＣＰプロトコル上で受信する装置で１つのプロトコルを運用させることであり、以下に明示するように、それに送信された制御メッセージを受け入れる。
ｓｔｒｕｃｔＲｕｌｅ＿ｍｓｇ｛
ｉｎｔｅｎａｂｌｅ＿ｕ２ｍ；
ｉｎｔｅｎａｂｌｅ＿ｉｇｍｐ；
ｉｎｔｑｕｅｒｉｅｒ＿ｆｌａｇ；
ｉｎｔｃｏｎｔｒｏｌ＿ｐｏｒｔ＿ｉｎｄｅｘ；
ｉｎｔｕ２ｍ＿ｕｎｉｃａｓｔ＿ｑｕｅｒｉｅｒ＿ｐｔ；
ｉｎｔｕ２ｍ＿ｕｎｉｃａｓｔ＿ｎｏｎ−ｑｕｅｒｉｅｒ＿ｐｔ；
ｉｎｔｕ２ｍ＿ｉｇｍｐ＿ｑｕｅｒｉｅｒ＿ｐｔ；
ｉｎｔｕ２ｍ＿ｉｇｍｐ＿ｎｏｎ−ｑｕｅｒｉｅｒ＿ｐｔ；
ｉｎｔｉｇｍｐ＿ｍｕｌｔｉｃａｓｔ＿ｐｔ；
ｉｎｔｉｇｍｐ＿ｕｎｉｃａｓｔ＿ｐｔ：
ｉｎｔｉｇｍｐ＿ｏｔｈｅｒ＿ｐｔ；
｝；
【００８２】
＜データ構造１＞パケットを転送するための規則を伝えるメッセージ
データ構造内のフィールドを下記のように定義する。
・「ｅｎａｂｌｅ＿ｕ２ｍ」 − このフィールドは、装置のＵ２Ｍ変換および転送エンジン１０１が有効であるかを示す。事例値：１，イネーブル； −１，ディスエーブル
・「ｅｎａｂｌｅ＿ｉｇｍｐ」 − このフィールドは、装置のサブＩＧＭＰ処理エンジン１０３が有効であるかを示す。事例値：１，イネーブル； −１，ディスエーブル
・「ｑｕｅｒｉｅｒ＿ｆｌａｇ」 − このフィールドは、この装置が照会器として設定されるかどうかを示す。事例値：１，照会器に設定； −１，非照会器に設定
・「ｃｏｎｔｒｏｌ＿ｐｏｒｔ＿ｉｎｄｅｘ」 − このフィールドは、制御ポートとしてどのポートを設定すべきかを示す。
・「ｕ２ｍ＿ｕｎｉｃａｓｔ＿ｑｕｅｒｉｅｒ＿ｐｔ」 − このフィールドは、装置が照会器である場合にパケットがＵ２Ｍ変換転送エンジン１０１のユニキャストから到来したならばパケットを転送すべきポートに関するビットマップを伝える。
・「ｕ２ｍ＿ｕｎｉｃａｓｔ＿ｎｏｎ−ｑｕｅｒｉｅｒ＿ｐｔ」 − このフィールドは、装置が非照会器である場合にパケッドがＵ２Ｍ変換転送エンジン１０１のユニキャストポートから到来したならばパケットを転送すべきポートに関するビットマップを伝える。
・「ｕ２ｍ＿ｉｇｍｐ＿ｑｕｅｒｉｅｒ＿ｐｔ」 − このフィールドは、装置が照会器である場合にＵ２Ｍ変換転送エンジン１０１のサブＩＧＭＰ処理エンジン１０３からパケットが到来したならばパケットを転送すべきポートに関するビットマップを伝える。
・「ｕ２ｍ＿ｉｇｍｐ＿ｎｏｎ＿ｑｕｅｒｉｅｒ＿ｐｔ」 − このフィールドは、装置が非照会器である場合にＵ２Ｍ変換転送エンジン１０１のサブＩＧＭＰ処理エンジン１０３からパケットが到来したならばパケットを転送すべきポートに関するビットマップを伝える。
・「ｉｇｍｐ＿ｍｕｌｔｉｃａｓｔ＿ｐｔ」 − このフィールドは、マルチキャストパケットがサブＩＧＭＰ処理エンジン１０３上に到来したならばパケットを転送すべきポートに関するビットマップを伝える。なお、全て零とはパケットをドロップすべきことである。
・「ｉｇｍｐ＿ｕｎｉｃａｓｔ＿ｐｔ」 − このフィールドは、サブＩＧＭＰ処理エンジン１０３上で受信したユニキャストパケットを転送するかどうかの情報を伝える。事例値：１は転送を意味し、−１はパケットをドロップすることである。
・「ｉｇｍ＿ｏｔｈｅｒ＿ｐｋｔ」 − このフィールドは、他のパケット（ユニキャスト、ＩＧＭＰメッセージパケッド以外の）を転送するかどうかの情報を伝える。
【００８３】
上記の規則メッセージデータタイプは説明用の事例である。実際にはメッセージは種々の形態があり、多少のフィールドを持つことができ、信号化や承認化用の特別なメッセージタイプがある。
【００８４】
本実施形態のストリーミング制御装置は通過するトラヒックに関する実時間統計値を記録（ｌｏｇ）でき、それを局所あるいは遠隔に利用できるようにする。これは、ＴＣＰポート上で動作する装置に、要請がある場合に以下のようなログ情報報告メッセージを送信するプロセスを運用することにより行われる。
【００８５】
ｓｔｒｕｃｔｌｏｇ＿ｒｅｐｏｒｔ｛
ｉｎｔｔｉｍｅ；
ｉｎｔｄｅｖｉｃｅ＿ｉｄｅｎｔｉｔｙ；
ｉｎｔｐｏｒｔ＿ｎｕｍ；
ｉｎｔｇｒｐ＿ｎｕｍ；
ｓｔｒｕｃｔｇｒｐ＿ｌｏｇｇｒｐ＿ｒｅｐｏｒｔ［ｐｏｒｔ＿ｎｕｍ］［ｇｒｐ＿ｎｕｍ］；
｝；
ｓｔｒｕｃｔｇｒｐ＿ｌｏｇ｛
ｉｎｔｐｏｒｔ＿ｉｎｄｅｘ；
ｉｎｔｇｒｐ＿ｉｎｄｅｘ；
ｉｎｔｐｋｔ＿ｆｏｒｗａｒｄｅｄ；
ｉｎｔｇｉｇａ＿ｐｋｔ＿ｆｏｒｗａｒｄｅｄ；
ｉｎｔｐｋｔ＿ｄｒｏｐｐｅｄ；
ｉｎｔｇｉｇａ＿ｐｋｔ＿ｄｒｏｐｐｅｄ；
ｉｎｔｂｉｔｓ＿ｆｏｒｗａｒｄｅｄ；
ｉｎｔｇｉｇａ＿ｂｉｔｓ＿ｆｏｒｗａｒｄｅｄ；
ｉｎｔｂｉｔｓ＿ｄｒｏｐｐｅｄ；
ｉｎｔｇｉｇａ＿ｂｉｔｓ＿ｄｒｏｐｐｅｄ；
ｉｎｔａｖｇ＿ｂａｎｄｗｉｄｔｈ；
ｉｎｔｒｅｃｅｉｖｅｒ＿ｒｕｍ；
ｓｔｒｕｃｔｒｅｃｅｉｖｅｒ＿ｌｏｇｒｅｃｅｉｖｅｒ＿ｒｅｐｏｒｔ［ｒｅｃｅｉｖｅｒ＿ｒｕｍ］；
｝；
ｓｔｒｕｃｔｒｅｃｅｉｖｅｒ＿ｌｏｇ｛
ｉｎｔｒｅｃｅｉｖｅｒ＿ｉｄｅｎｔｉｙ；
ｉｎｔｊｏｉｎ＿ｔｉｍｅ；
ｉｎｔｌｅａｖｅ＿ｔｉｍｅ；
ｉｎｔａｖｇ＿ｂａｎｄｗｉｄｔｈ；
｝；
【００８６】
＜データ構造２＞ログレポートメッセージ用のデータ構造
データ構造のフィールドを下記の様に定義する。
・「ｔｉｍｅ」 − このフィールドは、このレポートを何時作成するかの時期について情報を伝える。その値の意味は実処理系依存である。
・「ｄｅｖｉｃｅ＿ｉｄｅｎｔｉｔｙ」 − このフィールドは、このレポートを注目する装置の実体についての情報を伝える。その値の意味は処理系依存である。
・「ｐｏｒｔ＿ｎｕｍ」 − このフィールドは、このレポートに含まれるポート数を示す。
・「ｇｒｐ＿ｎｕｍ」 − このフィールドは、このレポートに含まれるグループの数を示す。
・「ｇｒｐ＿ｒｅｐｏｒｔ」 − これは所定ポート上のあるグループに関する情報を含む可変サイズアレーである。それはｔｙｐｅｓｔｒｕｃｔｇｒｐ＿ｌｏｇである。
・「ｐｏｒｔ＿ｉｎｄｅｘ」 − これは、このグループログレポートに関するポート指標を示す。
・「ｇｒｐ＿ｉｎｄｅｘ」 − これは、このグループログレポートに関するグループ指標を示す。
・「ｐｋｔ＿ｆｏｒｗａｒｄ」，「ｇｉｇａ＿ｐｋｔ＿ｆｏｒｗａｒｄ」 − これらの２つのフィールドは、このポート上のこのグループのトラヒックに対して転送されたパケット数を示す。
・「ｐｋｔ＿ｄｒｏｐｐｅｄ」，「ｇｉｇａ＿ｐｋｔ＿ｄｒｏｐｐｅｄ」 − これらの二つのフィールドは、このポート上のこのグループのトラヒックに対してドロップされたパケット数を示す。
・「ｂｉｔｓ＿ｆｏｒｗａｒｄ」，「ｇｉｇａ＿ｂｉｔｓ＿ｆｏｒｗａｒｄ」 − これらの二つのフィールドは、このポート上のこのグループのトラヒックに対して転送状態になるビット数を示す。
・「ｂｉｔｓ＿ｄｒｏｐｐｅｄ」，「ｇｉｇａ＿ｂｉｔｓ＿ｄｒｏｐｐｅｄ」 − これらの二つのフィールドは、このポート上のこのグループのトラヒックに対してドロップ状態になるビット数を示す。
・「ａｖｇ＿ｂａｎｄｗｉｄｔｈ」 − このフィールドは、このポート上のこのグループのトラヒックの平均帯域幅である。
・「ｒｅｃｅｉｖｅｒ＿ｎｕｍ」 − このフィールドは、レポートに含まれる受信機記録の数を示す。
・「ｒｅｃｅｉｖｅｒ＿ｒｅｐｏｒｔ」 − これは、受信機記録情報のｒｅｃｅｉｖｅｒ＿ｎｕｍ数を含む可変サイズアレーである。それはデータタイプｓｔｒｕｃｔｒｅｃｅｉｖｅｒ＿ｌｏｇである。
・「ｒｅｃｅｉｖｅｒ＿ｉｄｅｎｔｉｔｙ」 − これは、この受信機記録情報に関する受信機の実体を示す。
・「ｊｏｉｎ＿ｔｉｍｅ」 − このフィールドは、受信機の接合グループ時間を示す。・「ｌｅａｖｅ＿ｔｉｍｅ」 − このフィールドは、受信機がグループを離れる時間を示す。
・「ａｖｇ＿ｂａｎｄｗｉｄｔｈ」 − このフィールドは、受信機の平均帯域幅を示す。
【００８７】
これらのメッセージタイプは説明用のみの事例であり、装置に用いる唯一のものとして考えるものではない。記録情報が他の処理形態においても実行される。上記の情報は３つのエンジン全てに集められ、後の検索用のデータベースとして装置、すなわち外部記憶装置に記憶される。
【００８８】
以上説明したように、本実施形態のストリーミング制御装置によれば、当該装置を通るトラヒックにサービス品質を提供できる。例えば、所定の受信機では、スループットパラメータを設定できるので、パケットを装置のポートに転送する場合にトラヒックを形成できる。また、本装置をネットワークに配置しても他のネットワークノードに特別な変更を必要としないため、配置の影響やコストを最小にできる。それゆえ、本装置を既存システムに容易に適用できる。
【００８９】
また、本装置は遠隔構成およびレポーティングが可能である、つまり、遠隔／集中制御器を用いて分散装置を管理できる。また、フレームワークを形成するようにいくつかの装置を相互接続することにより大規模ネットワークを支援することができる。また、本装置は、遠隔アクセスの局所用のトラヒックに関する実時間統計値情報を提供するため、遠隔／集中モニタの実現を促進する。さらに、ＱｏＳ情報を記録するフレームワークと特別のＱｏＳフレームワークを組み込む方法を提供する。
【００９０】
なお、ある特別ポートを前述のカメラや監視装置上に割当て、これらのデバイスが複数ある場合に所定デバイスに所定属性を割当て、所定の構成規則に基づいて出力ポートにトラヒック、特に所定パケットを転送することによって、ネットワーク内のルーピングを阻止しても良い。また、このリンクまたはネットワークサービスポートのデバイスとデバイス属性を自己構成することができる。
【００９１】
【発明の効果】
以上説明したように、本発明に係るストリーミング制御装置によれば、マルチキャストトラヒック転送情報データベースに記録されている受信機の情報によって、同じトラヒックを要請する受信機が他に存在するかを直ちに知ることができるため、受信機が存在しない場合にはトラヒックの配信をすぐに停止できる。この結果、トラヒックを効率化して小さくすることのできる。
【図面の簡単な説明】
【図１】ユニキャストデータパケットトラヒックをマルチキャストデータパケットトラヒックに変換し、受信機からの要請に基づいて受信機に転送するストリーミング制御装置を示すブロック図
【図２】Ｕ２Ｍ変換転送エンジン１０１の状態遷移図
【図３】初期化状態２０１のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図４】アイドル状態２０２のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図５】Ｕ２Ｍ変換状態２０３のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図６】転送状態２０４のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図７】フォワードユニキャスト状態２０５のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図８】上位層状態２０６のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図９】示した照会および状態更新エンジン１０２の状態遷移図
【図１０】初期化状態３０１の照会および状態更新エンジン１０２が行う動作について説明するフローチャート
【図１１】更新状況ステーブル状態３０３の照会および状態更新エンジン１０２が行う動作について説明するフローチャート
【図１２】照会状態３０４の照会および状態更新エンジン１０２の動作について説明するフローチャート
【図１３】サブＩＧＭＰ処理エンジン１０３の状態遷移図
【図１４】初期化エンジン４０１状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図１５】アイドル４０２状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図１６】結合報告４０３状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図１７】リーブ報告４０４状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図１８】ユニキャストフォワード４０５状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図１９】ドロップパケット４０６状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図２０】トリガ照会エンジン４０７状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図２１】本実施形態のストリーミング制御装置を用いて監視システムにサービスを提供する事例のシナリオを示す説明図
【符号の説明】
１０１Ｕ２Ｍ変換転送エンジン
１０２照会および状態更新エンジン
１０３サブＩＧＭＰ処理エンジン
１０４転送および受信機登録テーブル

Claims

受信機からの要求に応じてマルチキャストでコンテンツを配信するストリーミング制御装置であって、
データ配信源から入力されたユニキャストトラヒックをマルチキャストトラヒックに変換するトラヒック変換手段と、
前記コンテンツの転送状況および前記コンテンツの配信を要求した前記受信機を記憶したマルチキャストトラヒック転送情報データベースに記憶されている情報と、所定の規則とに基づいて、前記トラヒック変換手段によって変換されたマルチキャストトラヒックを配信するトラヒック配信手段と、
を備えたことを特徴とするストリーミング制御装置。
所定の間隔でＩＧＭＰメッセージを作成し送信するメッセージ送信手段と、
前記メッセージ送信手段から送信された前記ＩＧＭＰメッセージと前記ＩＧＭＰメッセージの送信に対する応答に基づいて、マルチキャストトラヒック転送用の情報を更新する情報更新手段と、
前記ＩＧＭＰメッセージを送信する間隔を設定する間隔設定手段と、
を備えたことを特徴とする請求項１記載のストリーミング制御装置。
前記トラヒック変換手段は、
前記データ配信源から入力されたユニキャストトラヒックのデータパケットを選択するデータパケット選択手段と、
前記データパケット選択手段によって選択されたユニキャストトラヒックのデータパケットをマルチキャストトラヒックのデータパケットに変換するデータ変換手段と、
を有することを特徴とする請求項１記載のストリーミング制御装置。
前記マルチキャストポートで前記ＩＧＭＰメッセージを受信する際に、
前記ＩＧＭＰメッセージがインターネットグループ用の「Ｍｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」であれば、そのメッセージに対応するマルチキャストグループ用のトラヒックの転送を可能にして、対応するマルチキャストグループ用のデータベースに受信機を登録し、
前記ＩＧＭＰメッセージが「Ｌｅａｖｅ＿Ｇｒｏｕｐメッセージ」であれば、対応するマルチキャストグループ用のデータベースに登録されている受信機を除去し、その受信機がグループに連動しない場合に対応するマルチキャストグループ用のトラヒックの転送を無効にするようにして前記マルチキャストトラヒック転送情報データベースを更新するデータベース更新手段を備えたことを特徴とする請求項２記載のストリーミング制御装置。
前記トラヒック配信手段および前記データベース更新手段が、前記マルチキャストトラヒック転送情報データベースを共有することを特徴とする請求項４記載のストリーミング制御装置。
マルチキャストトラヒックのデータパケットを出力する複数の出力リンクと、
ユニキャストトラヒックのデータパケットを入力する複数の入力リンクと、
を備えたことを特徴とする請求項１ないし５のいずれかに記載のストリーミング制御装置。
前記入力リンクが前記出力リンクの機能を備え、
前記出力リンクが前記入力リンクの機能を備え、
前記入力リンクを複数のデータ配信源に接続し、前記出力リンクを複数の受信機に接続したことを特徴とする請求項６記載のストリーミング制御装置。
請求項１ないし７のいずれかに記載のストリーミング制御装置を備えたネットワークシステムであって、
前記受信機が任意クラスタの任意のデータ配信源からデータストリームを受信可能であり、
前記データ配信源に接続されたスイッチに前記ストリーミング制御装置が接続され、
前記スイッチ経由で前記受信機に前記ストリーミング制御装置の各出力を接続することにより、前記データ配信源と前記受信機の複数のクラスタを支援するようネットワークが構成されたことを特徴とするネットワークシステム。
前記ストリーミング制御装置は、高周波で前記データ配信源間を切り換えるために用いられることを特徴とする請求項８記載のネットワークシステム。