狭帯域ネットワークの大容量データ配信システム
【課題】複数の大容量データを広帯域ネットワークから狭帯域ネットワークに配信する大容量データ配信システムに関ルータに流入制御を設定することなく、狭帯域ネットワーク全体の使用可能帯域をもとに、流入箇所毎に使用可能帯域を割り当て、大容量データをトランスコードして流入可能とする。
【解決手段】映像ストリームのトランスコードを行うトランスコーダ１０２を搭載しそれを制御するオートトランスコーダ１０１を多段接続して、広帯域ネットワークからの映像ストリームの流入を引き受けるグループが形成される。オートトランスコーダ１０１では、自装置で映像ストリームをトランスコードできない場合に、同一のグループ内の他のオートトランスコーダ１０１でその映像ストリームをレート変換させるために、その映像ストリームを透過させる制御が実施される。
【解決手段】映像ストリームのトランスコードを行うトランスコーダ１０２を搭載しそれを制御するオートトランスコーダ１０１を多段接続して、広帯域ネットワークからの映像ストリームの流入を引き受けるグループが形成される。オートトランスコーダ１０１では、自装置で映像ストリームをトランスコードできない場合に、同一のグループ内の他のオートトランスコーダ１０１でその映像ストリームをレート変換させるために、その映像ストリームを透過させる制御が実施される。
【発明の詳細な説明】
【技術分野】
【０００１】
複数の映像ストリームのような大容量データを例えば光ファイバネットワークのような広帯域ネットワークから例えばマイクロ網のような狭帯域ネットワークに配信する大容量データの配信技術に関する。本発明は例えば、広帯域ネットワークと狭帯域ネットワークが複数箇所で接続された構成において、広帯域ネットワークから映像ストリームのような高レートメディア情報が一度に流れ込む映像配信システムに適用することができる。
【背景技術】
【０００２】
国土交通省等が管理する河川映像管理ネットワークなどにおいては、多数の地点のカメラ映像等を広帯域ネットワークを通じて収集する映像配信システムが構築されている。このようなネットワークは、災害時などにおいて重要なカメラ映像等を収集する必要がある。このため、広帯域ネットワークに障害が発生した場合等におけるバックアップ回線としての意味を持つ最終冗長経路としての、マイクロ波網等によって構成される狭帯域ネットワークが必要となる。
【０００３】
現状の利用状況としては、広帯域ネットワークから狭帯域ネットワークへは、データ系、音声系のみが疎通可能であり、狭帯域のため映像は規制されている。このため、狭帯域ネットワーク上の帯域が余ってしまっており有効利用がなされていない。しかし本来は、有事の時等にこそ映像情報が必要なはずであり、広帯域ネットワークから狭帯域ネットワークへ映像情報を流し込む技術が必要とされる。この場合に、光網等の広帯域ネットワークと同一の使用方法（同一レートの映像）では、帯域的に狭帯域ネットワークを利用することは不可能である。このため、狭帯域ネットワーク全体で映像シェーピングを実現する機能が必要とされる。
【０００４】
狭帯域ネットワークへの流入制御に関する従来技術
以上の背景を前提として、まず広帯域ネットワークから狭帯域ネットワークへの流入制御を行う従来技術としては、以下の技術がある。
【０００５】
１つの広帯域ネットワークから接続する狭帯域ネットワークに送信する映像ストリームの総容量は、狭帯域ネットワークの帯域容量を超えないで流す必要がある。そこで、レイヤ３スイッチ（以降「Ｌ３スイッチ」と呼ぶ）又はレイヤ２スイッチ（以降「Ｌ２スイッチ」と呼ぶ）等のルータ装置で、映像情報が狭帯域ネットワークに流入する前に固定的に特定ストリームに制限(破棄)される。これにより、狭帯域ネットワークに送信される映像ストリーム数を減らす従来技術が知られている。
【０００６】
また、ネットワークを流れる映像ストリーム(マルチキャスト)を自動でトランスコード(デコード/エンコード)して映像ストリームの転送レートを下げる、オートトランスコーダと呼ばれる装置の従来技術が知られている。
【０００７】
狭帯域ネットワーク全体の制御に関する従来技術
次に、狭帯域ネットワーク全体の制御を行う従来技術としては、以下の技術がある。
狭帯域ネットワークはバックアップ回線に使用されるので、映像配信システムはネットワークの冗長切替を意識する必要があり、バックアップ回線に切り替わった場合は配信ストリーム数を少なくする必要がある。そこで、Ｌ３スイッチやＬ２スイッチにおいて、映像ストリームのフィルタリングを設定し、固定的に狭帯域ネットワークへ流入数を制限する従来技術が知られている。
【０００８】
また、マルチキャストアドレスを特定の許可されたアドレスに変換する事により任意の映像ストリームを狭帯域ネットワークに流入させる従来技術が知られている。
更に、広帯域ネットワークから狭帯域ネットワークへの１流入箇所での映像ストリームにつき、複数台からなる１グループのオートトランスコーダ群を使って、流入量を一定に制限し、順番(先着順)に低レートの映像ストリームへ変換する従来技術が知られている。
【０００９】
ストリーム選択に関する従来技術
次に、広帯域ネットワークから狭帯域ネットワークへ流入するストリームを選択するための従来技術としては、以下の技術がある。
Ｌ２スイッチやＬ３スイッチにおいて、フィルタリング機能によって、特定の映像ストリームを固定的に又は手動で選択する従来技術が知られている。
【００１０】
また、Ｌ２スイッチやＬ３スイッチでの特定の映像ストリームの選択を、サーバからの定義データの設定により行う従来技術が知られている。
更に、オートトランスコーダにおける優先制御設定により、特定の映像ストリームのトランスコードを予約する従来技術が知られている。
【００１１】
信頼性を確保する従来技術
広帯域ネットワークと狭帯域ネットワークの接続において信頼性を確保するための従来技術としては、以下の技術がある。
【００１２】
広帯域ネットワークから狭帯域ネットワークに送信される映像ストリーム(マルチキャスト)は、経路変化の状況により狭帯域ネットワークへの流入箇所が変わり、各映像ストリームの流入ポイントが不定となる可能性がある。このような場合を考慮して、複数箇所のＬ２スイッチやＬ３スイッチで冗長的にストリームをフィルタリングする従来技術が知られている。
【００１３】
また、Ｌ２スイッチやＬ３スイッチの故障を考慮して、複数箇所のＬ２スイッチやＬ３スイッチで冗長的にストリームをフィルタリングする従来技術が知られている。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２００５−１８４３８７号公報
【特許文献２】特開２００２−８４５２５号公報
【特許文献３】特開平１１−２２５１６８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１５】
狭帯域ネットワークへの流入制御に関する課題
広帯域ネットワークから狭帯域ネットワークへの流入制御を行う従来技術に関する問題点としては、以下の点があげられる。
【００１６】
広帯域ネットワークと狭帯域ネットワークの間のＬ２／Ｌ３スイッチでフィルタリングを行った場合、狭帯域ネットワークに流せる映像ストリームの本数が極端に少なくなってしまうという問題点を有していた。例えば、２．４Ｇｂｐｓ（ギガビット／秒）の光ネットワークに６Ｍｂｐｓ（メガビット／秒）の映像ストリームは４００本流せるが、５２Ｍｂｐｓのマイクロネットワーク(狭帯域ネットワーク)では６Ｍｂｐｓの映像ストリームは８本しか流せなくなる。
【００１７】
また、従来のオートトランスコーダは６ＭｂｐｓのＭＰＥＧ２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ２）のストリームを１グループで４本しかトランスコードしないので、狭帯域ネットワークの使用効率が悪いという問題点を有していた。
【００１８】
流入させる映像ストリームの本数を増やすために、単純にトランスコーダで映像のレートを下げると、
更に、映像ストリームの転送レートを下げる従来のオートトランスコーダでは、マルチキャストアドレスの変換が行われる。このため、映像配信(切替え)システムの管理情報と矛盾が起こり(映像切替サーバのデータベースの登録内容と異なってしまう)、映像配信システムの障害が発生するおそれがあるという問題点を有していた。
【００１９】
狭帯域ネットワーク全体の制御に関する課題
狭帯域ネットワーク全体の制御を行う従来技術に関する問題点としては、以下の点があげられる。
【００２０】
多数の映像データが複数箇所で広帯域ネットワークから狭帯域ネットワークに流入する場合、複数箇所での流入量管理が必要になる。ダイナミックに流入させる映像を制御する場合、現状流れている映像ストリームをリアルタイムに管理する必要があり、映像選択状況を映像管理サーバから入手する手間が発生するという問題点を有していた。
【００２１】
また、広帯域ネットワーク側で冗長構成を組んでいると、どのグループから映像ストリーム流入してくるかわからないので、全てのグループの手前でＬ２／Ｌ３スイッチにフィルタ設定を行う必要があり、管理が複雑になるという問題点を有していた。
【００２２】
また、固定的に狭帯域ネットワークの帯域内でしか映像が流れないように特定の映像ストリームのみを流すようなフィルタ設定を行うと、設定許可された映像ストリームが流れていない場合に狭帯域ネットワークを有効に活用できないという問題点を有していた。
【００２３】
更に、オートトランスコーダのように映像ストリームのレート変換装置を狭帯域ネットワークの入口に設置して無条件でレート変換する構成が採用された場合を考える。この場合には、各オートトランスコーダはお互いに独立してトランスコードするので、複数グループでの流入量制御ができないという問題点を有していた。
【００２４】
ストリーム選択に関する課題
広帯域ネットワークから狭帯域ネットワークへ流入するストリームを選択するための従来技術の問題点としては、以下の点があげられる。
【００２５】
広帯域ネットワーク側で冗長構成を採用しているときには、狭帯域ネットワークのどのポイントから映像ストリームが流入するか分からない。このため、Ｌ２／Ｌ３スイッチでのフィルタリング設定を行う場合に、狭帯域ネットワークへの複数の入口のＬ２／Ｌ３スイッチの全てに同じ設定をしなくてはならないという問題点を有していた。
【００２６】
同様の理由で、他の接続装置についても冗長構成が採用されているときには、冗長を構成する装置全てに同じ設定をする必要があるという問題点を有していた。
また、現状のオートトランスコーダは、映像ストリームの転送レートの変換は可能であるが、重要映像を高画質のまま狭帯域ネットワークに流入させる事はできない。従って、低レート映像を見て重要な映像を選択して高画質映像のままモニタするような、レート切替(画質切替)ができないという問題点を有していた。
【００２７】
更に、オートトランスコーダを使用した場合、トランスコードしている映像ストリーム以外のＭＰＥＧ２マルチキャストは破棄されてしまうため、高画質な映像を受信することはできないという問題点を有していた。
【００２８】
信頼性の確保に関する課題
広帯域ネットワークと狭帯域ネットワークの接続において信頼性を確保するための従来技術の問題点としては、以下の点があげられる。
【００２９】
複数箇所からの映像ストリームの流入や故障を考慮してＬ３スイッチで冗長構成がとられる場合は、コストが高くなるという問題点を有していた。
また、オートトランスコーダを用いた構成において、オートトランスコーダで障害が発生すると、高トラフィックのＭＰＥＧ２映像ストリームがそのまま狭帯域ネットワークに流れてしまい、狭帯域ネットワークの帯域オーバフローを起こす可能性がある。このような事態がもし発生した場合、狭帯域ネットワークを流れる全映像ストリームでパケット抜けを起こす場合があるという問題点を有していた。
【００３０】
更に、狭帯域ネットワークに映像ストリームが迂回している場合、狭帯域ネットワークが分断され、その中でＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ：帯域保証）制御が各々行われている場合を考える。この場合、狭帯域ネットワークが分断から復旧した瞬間に帯域オーバしてしまい全映像ストリームが影響を受けてしまう可能性があるという問題点を有していた。
【００３１】
以上説明したように、広帯域ネットワークから狭帯域ネットワークへの映像ストリームのような大容量データの流入制御の問題点は、次のようになる。即ち、流入箇所に割り当てた使用可能帯域を固定的にて単純に複数ストリームのトランスコードを行うような制御では、流入箇所に偏りが生じうる環境では、割当て帯域に不足・無駄が生じる可能性が否めないという問題点を有していた。
【００３２】
また、Ｌ２／Ｌ３スイッチ等のルータ装置で流入制御を行うためには、全てのルータに設定を行う必要があるという問題点を有していた。
そこで、本発明の１つの側面では、ルータに流入制御を設定することなく、狭帯域ネットワーク全体の使用可能帯域をもとに、流入箇所毎に使用可能帯域を割り当て、大容量データをトランスコードして流入可能とすることを目的とする。また、好ましくは、指定された映像データについては高レートのまま流入可能とすることを目的とする。
【課題を解決するための手段】
【００３３】
態様の一例では、複数の大容量データを広帯域ネットワークから狭帯域ネットワークに配信する大容量データ配信システムとして実現され、以下の構成を有する。
まず、大容量データのレート変換を行うレート変換装置を搭載しレート変換装置を制御するレート変換制御装置を多段接続して広帯域ネットワークからの大容量データの流入を引き受けるグループが形成される。
【００３４】
そして、レート変換制御装置が、以下の各部を備える。
まず、トランスコード制御部は、自レート変換制御装置で大容量データをレート変換できない場合に、同一のグループ内の他のレート変換制御装置でその大容量データをレート変換させるために、その大容量データを透過させる制御を行う。
【００３５】
透過情報管理部は、指定された大容量データを、グループ内の全レート変換制御装置でレート変換を行わずに透過させる制御を行う。
グループ内情報管理部は、トランスコード制御部及び透過情報管理部の制御状態を、グループ内の他のレート変換制御装置との間で、自グループトランスコード状況情報として交換し設定する。
【発明の効果】
【００３６】
レート変換制御装置の多段接続構成により、狭帯域ネットワークに流入する映像ストリーム等の大容量データが帯域を超えないように制御することが可能となる。
また、指定の大容量データを、元のレートのまま狭帯域を通し、高品質の映像を提供することが可能となる。
【００３７】
更に、レート変換状況と大容量データの狭帯域ネットワークへの流入量に関する情報が、各グループ内及び複数のグループ間で共有されることにより、グループ内及びグループ間の各レート変換制御装置が協同的に、狭帯域への流入制御を実施することが可能となる。
【００３８】
更に、レート変換制御装置の冗長構成により、１システムがダウンしても予備のトランスコーダが状態を引き継いでトランスコードすることが可能となる。
【図面の簡単な説明】
【００３９】
【図１】実施形態の全体システム構成図である。
【図２】オートトランスコーダの接続形態を示す図である。
【図３】オートトランスコーダの機能構成図である。
【図４】全ノード共通の、起動時におけるマスタ選出処理を示す動作フローチャートである。
【図５】全ノード共通の、運用時におけるマスタ選出情報応答処理を示す動作フローチャートである。
【図６】全ノード共通の、運用時におけるMCデータ受信処理を示す動作フローチャートである。
【図７】サブメインマスタノードの制御動作を示す動作フローチャート（その１）である。
【図８】サブメインマスタノードの制御動作を示す動作フローチャート（その２）である。
【図９】サブメインマスタノードの制御動作を示す動作フローチャート（その３）である。
【図１０】サブメインマスタノードの制御動作を示す動作フローチャート（その４）である。
【図１１】サブメインマスタノードの制御動作を示す動作フローチャート（その５）である。
【図１２】サブメインマスタノードの制御動作を示す動作フローチャート（その６）である。
【図１３】サブメインマスタノードの制御動作を示す動作フローチャート（その７）である。
【図１４】スレーブノードの制御動作を示す動作フローチャート（その１）である。
【図１５】スレーブノードの制御動作を示す動作フローチャート（その２）である。
【図１６】スレーブノードの制御動作を示す動作フローチャート（その３）である。
【図１７】スレーブノードの制御動作を示す動作フローチャート（その４）である。
【図１８】スレーブノードの制御動作を示す動作フローチャート（その５）である。
【図１９】メインマスタノードの制御動作を示す動作フローチャート（その１）である。
【図２０】メインマスタノードの制御動作を示す動作フローチャート（その２）である。
【図２１】メインマスタノードの制御動作を示す動作フローチャート（その３）である。
【図２２】グループ共通定義ファイルのデータ構成例を示す図である。
【図２３】グループ共通定義ファイルの各パラメタの説明図である。
【図２４】自グループトランスコード状況情報と自グループトラフィック流入情報のデータ構成例を示す図である。
【図２５】自グループ管理テーブルのデータ構成例を示す図である。
【図２６】優先（緊急）テーブルのデータ構成例を示す図である。
【図２７】遮断(破棄)テーブルのデータ構成例を示す図である。
【図２８】透過テーブルのデータ構成例を示す図である。
【図２９】グループ間トランスコード状況情報のデータ構成例を示す図である。
【発明を実施するための形態】
【００４０】
以下、本発明を実施するための形態について図面を参照しながら詳細に説明する。
図１は、実施形態の全体システム構成図である。
広帯域ネットワーク１０６に接続される広帯域側Ｌ３（レイヤ３）スイッチ（図中「Ｌ３ＳＷ」と表記）１０３には、＃１から＃５までの５台の通常はスレーブ装置兼現用系として動作するレート変換制御装置であるオートトランスコーダ１０１が縦属に接続される。また、＃５のオートトランスコーダ１０１には、通常はマスタ装置兼予備系として動作する１台のオートトランスコーダ１０１が接続される。このオートトランスコーダ１０１は、狭帯域ネットワーク１０７に接続される狭帯域側Ｌ３スイッチ（図中「μＬ３ＳＷ」と表記）１０４に接続される。各オートトランスコーダ１０１には、４台までのレート変換装置であるトランスコーダ１０２を接続可能である。各トランスコーダ１０２は、広帯域ネットワーク１０６側のカメラ１０５から広帯域側Ｌ３スイッチ１０３を介して流入する、１本の映像ストリームをＭＰＥＧ２からＭＰＥＧ４の転送レートに変換する。ＭＰＥＧ２の転送レートは例えば６Ｍｂｐｓ、ＭＰＧＥ４の転送レートは例えば２６ｋｂｐｓ（キロビット／秒）〜５１９ｋｂｐｓである。従って、１台のオートトランスコーダ１０１は、最大で４本の映像ストリームのレート変換が可能である。上述の＃１から＃５までの５台のスレーブ装置と１台のマスタ装置からなる６台のオートトランスコーダ１０１と、それぞれに接続されるトランスコーダ１０２群とが、狭帯域ネットワーク接続の１グループを形成する。１つの狭帯域ネットワーク接続グループでは、現用系として動作する５台のオートトランスコーダ１０１によって、最大で２０本までの映像ストリームのレート変換が可能となる。
【００４１】
図１では、４つの狭帯域ネットワーク接続グループが、それぞれ広帯域ネットワーク１０６内の１台の広帯域側Ｌ３スイッチ１０３と狭帯域ネットワーク１０７内の１台の狭帯域側Ｌ３スイッチ１０４と接続される。従って、図１の場合、広帯域ネットワーク１０６側の各カメラ１０５から流入する最大で２０本×４グループ＝８０本までの映像ストリームについて、レート変換を行って狭帯域ネットワーク１０７に流入させることが可能となる。狭帯域ネットワーク１０７の帯域幅は、例えば４８Ｍｂｐｓである。
【００４２】
図１において、Ｗｅｂ保守端末１０８は、広帯域側Ｌ３スイッチ１０３又は狭帯域側Ｌ３スイッチ１０４を介して、各オートトランスコーダ１０１を、Ｗｅｂインターフェースにより制御可能である。
【００４３】
グループ内の各オートトランスコーダ１０１は、図２に示されるように、１台の広帯域側Ｌ３スイッチ１０３と１台の狭帯域側Ｌ３スイッチ１０４の間を結ぶ主回線２０２に、スイッチボックス２０１を介して接続される。スイッチボックス２０１は、正常動作時には、通常時パス２０３として示されるように、主回線２０２から流入する映像ストリームをオートトランスコーダ１０１に取り込んで、その配下のトランスコーダ１０２でレート変換処理を実行させる。一方、スイッチボックス２０１は、オートトランスコーダ１０１で障害が発生したときには、障害時パス２０４として示されるように、オートトランスコーダ１０１への接続を切って、主回線２０２上の信号を後続のオートトランスコーダ１０１に透過させる。
【００４４】
以上の構成を有する実施形態の概略動作について、以下に説明する。
まず、グループ内の制御の概略について説明する。
【００４５】
グループ内トランスコード制御
上述したように１つの狭帯域ネットワーク接続グループでは、６台のオートトランスコーダ１０１がスイッチボックス２０１（図２）によって縦属（直列）に接続される。
【００４６】
システムの起動時には、グループ内での情報共有のために、グループ内で１台のマスタ装置と５台のスレーブ装置が決定される。また、５台の現用系装置と１台の予備系装置が決定される。図１の例では、＃１から＃５のオートトランスコーダ１０１が、スレーブ装置兼現用系装置に割り当てられ、残りの１台のオートトランスコーダ１０１が、マスタ装置兼予備系装置として割り当てられる。これらの割当ては、運用状態によって、マスタ装置／スレーブ装置、及び現用系／予備系を、それぞれ独立して動的に変更可能である。
【００４７】
なお、以下の説明では、オートトランスコーダ１０１をノードと呼ぶ場合があり、マスタ装置をマスタノード、スレーブ装置をスレーブノードと呼ぶ場合がある。
グループ内の各オートトランスコーダ１０１は、グループ内の他のオートトランスコーダ１０１とプライオリティ（ノードプライオリティ）の交換を行い、マスタ装置を選出する。
【００４８】
マスタ装置は、スレーブ装置のトランスコード処理数を管理する。マスタ装置は、スレーブ装置に、変換レート（映像ストリーム数）を通知する。スレーブ装置は、マスタ装置に、トランスコード状況を自グループトランスコード状況情報（後述する図３、図２４参照）として、定期的に通知する。マスタ装置とスレーブ装置間で実行される通知処理をヘルスチェックと呼ぶ。マスタ装置は、広帯域ネットワーク１０６から流入するＭＰＥＧ４のトラフィック流入量を監視し、狭帯域ネットワーク１０７への流入量にカウントする。
【００４９】
マスタ装置は、スレーブ装置に例えば２秒間隔でヘルスチェック処理を実行する。ヘルスチェックにより、後述する自グループ管理テーブル（トランスコード情報）（図３、図２５参照）の情報が、マスタ装置とスレーブ装置間で共有される。
【００５０】
マスタ装置から送信されるヘルスチェックでは、グループ内の全てのオートトランスコーダ１０１のトランスコード管理テーブル３１２の情報が通知され、スレーブ装置から応答されるヘルスチェックでは、自装置（そのスレーブ装置自身）のトランスコード管理テーブル３１２の情報が通知される。
【００５１】
グループ内での映像ストリームのトランスコードは、ノード１（図１では＃１のオートトランスコーダ１０１）から順番に実行され、１つのノードでトランスコードできなくなった映像ストリームは次のノードへ転送される。
マスタ装置がダウンした場合には、別のスレーブ装置がマスタ装置に遷移する。
【００５２】
グループ内優先制御
本実施形態では、広帯域ネットワーク１０６から狭帯域ネットワーク１０７に優先的に転送する映像ストリームを指定することができる。このための制御が、優先制御である。この制御は、グループ毎に設定され実行される。
【００５３】
優先制御は、グループ共通定義ファイル３１０（図３、図２２、図２３参照）とＷｅｂ保守端末１０８から設定することができる。グループ共通定義ファイル３１０での設定は固定的であり、Ｗｅｂ保守端末１０８からの設定は動的な設定が可能である。
【００５４】
Ｗｅｂ保守端末１０８によって優先制御の設定を行う場合、Ｗｅｂ保守端末１０８→マスタ装置→グループ内オートトランスコーダ１０１という流れで制御が実行される。
優先制御では、マスタ装置が、優先制御をかけるオートトランスコーダ１０１を選び、選択したオートトランスコーダ１０１に優先設定コマンドを発行する。このとき、ノードプライオリティの低いオートトランスコーダ１０１から順番に、トランスコーダ１０２に空きがあれば優先設定が行われてゆく。
【００５５】
優先制御が行われているオートトランスコーダ１０１がダウンした場合、マスタ装置が、ダウンしたオートトランスコーダ１０１で設定されていた優先設定を他のオートトランスコーダ１０１へ設定する。
【００５６】
各オートトランスコーダ１０１は、優先テーブルを０．５秒毎にチェックし、自装置よりも上流（広帯域ネットワーク１０６側）に位置するオートトランスコーダ１０１の優先ストリームは破棄し、自装置の優先ストリームはトランスコードし、下流のオートトランスコーダ１０１の優先ストリームは転送（透過）する。
【００５７】
グループ内特定ＭＰＥＧ２透過制御
本実施形態では、広帯域ネットワーク１０６から流入する特定のＭＰＥＧ２広帯域映像ストリーム、例えばヘリコプターテレビ映像等のストリームを、レート変換せずに狭帯域ネットワーク１０７側に透過させることができる。そのための制御が、特定ＭＰＥＧ２透過制御である。この制御は、グループ毎に設定され実行される。
【００５８】
特定ＭＰＥＧ２透過制御は、グループ共通定義ファイル３１０により固定的に設定することができる（図３、図２２、図２３参照）。
透過指定された例えば６Ｍｂｐｓの映像ストリーム帯域は、実際に流れていなくてもスタティックに確保される。
【００５９】
グループ内特定ＭＰＥＧ２／４遮断制御
本実施形態では、広帯域ネットワーク１０６から流入する特定のＭＰＥＧ２又はＭＰＥＧ４の映像ストリームを、遮断することができる。そのための制御が、特定ＭＰＥＧ２／４遮断制御である。この制御は、グループ毎に設定され実行される。
【００６０】
特定ＭＰＥＧ２／４遮断制御は、グループ共通定義ファイル３１０（図３、図２２、図２３参照）とＷｅｂ保守端末１０８から設定することができる。グループ共通定義ファイル３１０での設定は固定的であり、Ｗｅｂ保守端末１０８からの設定は動的な設定が可能である。
【００６１】
グループ内トラフィック流入量制御
本実施形態では、グループを通過するＭＰＥＧ２／４の映像ストリームのトラフィック流入量を把握する制御が実行される。
【００６２】
グループ毎に、流入量の閾値を設定することができる。流入量の閾値は、グループ共通定義ファイル３１０（図３、図２２、図２３参照）で設定できるようにする。流入量の閾値は、デフォルト値がグループ共通定義ファイル３１０定義ファイルの設定値とされ、その後、グループ間で調整された新しい閾値が動的に設定される。
トラフィック流入量が閾値を超過した場合、超過したトラフィックが遮断される。
【００６３】
グループ間のトランスコード情報共有
以上がグループ内の制御の概略である。次に、グループ間の制御の概略について説明する。
【００６４】
グループ間の制御においては、まず、トランスコード情報が共有される。
複数のグループの各マスタ装置のうちの１つが、メインマスタ装置として動作する。
メインマスタ装置は、各グループの代表ノード（サブメインマスタ装置）から、トランスコード状態、流入量情報等を、グループ間トランスコード状況情報３１７（図３、図２９参照）の一部として収集する。メインマスタ装置は、各グループのサブメインマスタ装置に、ヘルスチェック機能(グループ間状態情報通知／応答昨日)によって、全グループに関するグループ間トランスコード状況情報３１７を配布する。これにより、各グループでは、システム全体のトランスコード情報等を共有することができる。
【００６５】
また、メインマスタ装置は、オートトランスコーダ１０１を６Ｍｂｐｓのまま透過又は遮断させるＭＣアドレスの設定情報を、グループ間トランスコード状況情報３１７（図３、図２９参照）の一部として各グループから収集し、グループ間で情報共有させる。
【００６６】
グループ間の狭帯域ネットワーク１０７への流入量制御
メインマスタ装置は、狭帯域ネットワーク１０７に流入する流量を制御するために、各グループのサブメインマスタ装置から流入量情報を収集する。
【００６７】
メインマスタ装置は、各グループの流入量情報を参照し、閾値を超えそうなグループに対し、余裕あるグループの予約帯域をシフト(再分配)することにより、全体の流入量を調整し狭帯域ネットワーク１０７を効率良く使用する。再配分は、ヘルスチェック処理により情報収集して、ヘルスチェック処理により情報通知して行う。情報通知の時間は、例えば１０秒程度である。
【００６８】
メインマスタ装置は、グループ共通定義ファイル３１０（図３、図２２、図２３参照）に記載されているグループのサブメインマスタ装置が検出できない場合は、そのグループとの間で予約帯域の調整はせずに帯域を確保しておく。これにより、狭帯域ネットワーク１０７におけるリング分断等からの復旧時も、狭帯域ネットワーク１０７の帯域オーバを防ぐことができる。
【００６９】
以上の概略動作を実現する実施形態の具体的な処理機能について、以下に詳細に説明する。
【００７０】
図２は、図１のオートトランスコーダ１０１の機能構成図である。オートトランスコーダ１０１の機能は、ＭＣデータ受信管理部３０１、トランスコード制御部３０２、トランスコード部３０３、グループ内情報管理部３０４、グループ内通信部３０５、グループ間情報管理部３０６、グループ間通信部３０７、透過・破棄ＭＣ情報管理部３０８、及びＷｅｂ画面制御部３０９によって実現される。また、オートトランスコーダ１０１は、グループ共通定義ファイル３１０、受信ＭＣデータ管理情報３１１、トランスコード管理テーブル３１２、グループ内管理情報３１３、優先（緊急）テーブル３１４、透過テーブル３１５、遮断（破棄）テーブル３１６、グループ間管理情報３１７、自グループトランスコード状況情報３１８、及び自グループトラフィック流入情報３１９の各情報を管理する。
【００７１】
上記各機能部３０１から３０９を実現する制御動作は、図４から図２１の動作フローチャートの処理として示される。これらの処理は、特には図示しない中央演算処理装置が、特には図示しないメモリに記憶された制御プログラムを実行する動作として実現される。
【００７２】
図４は、全ノード（オートトランスコーダ１０１）に共通の、起動時におけるマスタ選出処理を示す動作フローチャートである。この動作フローチャートは、図３のグループ内情報管理部３０４の機能の一部を実現する。
【００７３】
まず、自装置内のＭＣデータ受信管理部３０１（図３）のフィルタ機能に対して、受信された全てのマルチキャストパケット（以下「ＭＣ」と呼ぶ）を透過（スルー）する設定がなされる（ステップＳ４０１）。
【００７４】
次に、図３、図２２及び図２３に示されるデータ構成例を有するグループ共通定義ファイル３１０に定義されている自グループ内のノード宛てに、図３のグループ内通信部３０５を介して、マスタ選出情報要求（起動モード）が送信される（ステップＳ４０２）。具体的には、グループ共通定義ファイル３１０内のCTL_NODE1からCTL_NODE6（図２２、図２３参照）で示される各ノードのＩＰアドレスを宛先アドレスとして、所定のパケットフォーマットを有するマスタ選出情報要求（起動モード）が送信される。
【００７５】
次に、マスタ選出情報応答待ちタイマ（起動モード）が開始される（ステップＳ４０３）。このタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。
【００７６】
次に、グループ内通信部３０５を介して新たな情報受信の事象が発生したか否かの待ち状態となる（ステップＳ４０４）。この間、何れかのノードからマスタ選出情報応答が受信された場合には、その応答に対応するパケットのソースアドレスとして、応答を送信したノードの識別情報が特には図示しないメモリに記録される。
【００７７】
一定時間の事象発生待機（ステップＳ４０４）の後、上記ノードの識別情報がチェックされることにより、全ノードからマスタ選出情報応答が受信されたか否かが判定される（ステップＳ４０５）。
【００７８】
ステップＳ４０５の判定がＮＯならば、ステップＳ４０３で開始されたマスタ選出情報応答待ちタイマ（起動モード）がタイムアウトしたか否かが判定される（ステップＳ４０６）
ステップＳ４０６の判定がＮＯならば、ステップＳ４０４に戻って新たな事象待ち状態が繰り返される。
【００７９】
全ノードからマスタ選出情報応答が受信されてステップＳ４０５の判定がＹＥＳ、又はマスタ選出情報応答待ちタイマ（起動モード）がタイムアウトしてステップＳ４０６の判定がＹＥＳになると、以下の処理が実行される。
【００８０】
まず、マスタ選出情報応答待ちタイマ（起動モード）が終了させられる（ステップＳ４０７）。
次に、ステップＳ４０４でメモリ上に記録されている各ノードの識別情報に基づいて、グループ共通定義ファイル３１０から応答を受信したノードのプライオリティ情報が取得され、各ノードのプライオリティが自ノードのプライオリティと比較される（ステップＳ４０８）。具体的には、グループ共通定義ファイル３１０内の各ノードアドレス毎のPRIORITY値（図２２、図２３参照）が比較される。
【００８１】
そして、自ノードのプライオリティが最高であるか否かが判定される（ステップＳ４０９）。
自ノードのプライオリティが最高であってステップＳ４０９の判定がＹＥＳならば、自ノードがマスタ装置の運用状態に遷移される（ステップＳ４１０）。その後、図４の動作フローチャートの処理が終了する。マスタ装置の運用状態に遷移したオートトランスコーダ１０１は、後述する図５、図６、図７から図１３（サブメインマスタ装置及びメインマスタ装置の両方）、及び図１９から図２１（メインマスタ装置のみ）の動作フローチャートの処理を実行する。
【００８２】
自ノードのプライオリティが最高ではなくてステップＳ４０９の判定がＮＯならば、自ノードがスレーブ装置の運用状態に遷移される（ステップＳ４１１）。その後、図４の動作フローチャートの処理が終了する。スレーブ装置の運用状態に遷移したオートトランスコーダ１０１は、後述する図５、図６、及び図１４から図１８の動作フローチャートの処理を実行する。
【００８３】
図５は、全ノード（オートトランスコーダ１０１）に共通の、運用時におけるマスタ選出情報応答処理を示す動作フローチャートである。この動作フローチャートは、図３のグループ内情報管理部３０４の機能の一部を実現する。
【００８４】
まず、図３のグループ内通信部３０５を介してマスタ選出情報要求が受信されたか否かが判定される（ステップＳ５０１）。
ステップＳ５０１の判定がＮＯならば、一定時間後に再度ステップＳ５０１の判定が実行される動作が繰り返される。
【００８５】
ステップＳ５０１の判定がＹＥＳならば、マスタ選出情報応答のパケットが、受信されたマスタ選出情報要求のパケットのソースＩＰアドレスに対して返信される（ステップＳ５０２）。その後、ステップＳ５０１の判定処理に戻る。
【００８６】
図５の動作フローチャートの処理によって、前述した図４のステップＳ４０２でマスタ選出情報要求を送信したノードは、図４のステップＳ４０４で、各ノードからその要求に対応するマスタ選出情報応答を受信することができる。
【００８７】
図６は、全ノード（オートトランスコーダ１０１）に共通の、運用時における映像ストリームのマルチキャストデータの受信処理を示す動作フローチャートである。この動作フローチャートは、図３のＭＣデータ受信管理部３０１の機能の一部を実現する。
【００８８】
まず、マルチキャストデータ（ＭＣ）が受信されたか否かが判定される（ステップＳ６０１）。
ステップＳ６０１の判定がＮＯならば、再度ステップＳ６０１の判定が実行される動作が繰り返される。
【００８９】
ステップＳ６０１の判定がＹＥＳならば、受信したＭＰＥＧ２データのｉ−ｐｉｃｔｕｒｅ部の先頭６４バイトが特には図示しないメモリ内の受信キューにコピーされる（ステップＳ６０２）。その後、ステップＳ６０１の判定処理に戻る。
【００９０】
図６の動作フローチャートの処理によって、オートトランスコーダ１０１は、映像ストリームのＭＰＥＧ２データを受信することができる。
図７から図１３は、サブメインマスタ装置（ノード）として動作するオートトランスコーダ１０１の制御動作を示す動作フローチャートである。
【００９１】
まず、グループ内ヘルスチェックタイマ、グループ間ヘルスチェックタイマ、メイン選出情報要求送信タイマ、及びＭＣデータ受信チェックタイマがそれぞれ開始される（ステップＳ７０１）。これらのタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。
【００９２】
次に、新たな情報受信の事象が発生したか否かの待ち状態となる（ステップＳ７０２）。
続いて、ステップＳ７０３からＳ７０９の処理は、自ノードよりもプライオリティが高く設定されたノードが起動されてマスタ装置に遷移し、ヘルスチェックを送信したとき（図８のステップＳ８０２参照）の受信動作を示す処理である。この処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
【００９３】
まず、ヘルスチェックが受信されたか否かが判定される（ステップＳ７０３）。
ステップＳ７０３の判定がＹＥＳとなると、受信されたパケットに含まれる自グループトランスコード状況情報３１８によって、自装置内の自グループトランスコード状況情報３１８が更新される（ステップＳ７０４）
次に、更新された自グループトランスコード状況情報３１８と、グループ共通定義ファイル３１０が参照されることにより、自ノードと新たに起動したノードのプライオリティが比較される（ステップＳ７０５）。
【００９４】
そして、自ノードのプライオリティが最高であるか否かが判定される（ステップＳ７０６）。
ステップＳ７０６の判定がＹＥＳならば、マスタ装置の状態が維持される（ステップＳ７０７）。その後、ステップＳ７０２の事象待機処理に戻る。
【００９５】
一方、ステップＳ７０６の判定がＮＯならば、ヘルスチェック応答が送信される（ステップＳ７０８）。このとき、自ノードの自グループトランスコード状況情報３１８が通知される。
【００９６】
その後、スレーブ装置の運用状態へ遷移し（ステップＳ７０９）、図７の動作フローチャートの処理を終了する。
前述したステップＳ７０３の判定がＮＯの場合には、次に、トランスコード設定要求が受信されたか否かが判定される（ステップＳ７１０）。
【００９７】
ステップＳ７１０の判定がＹＥＳの場合、以下のステップＳ７１１とＳ７１２の処理が実行される。これらの処理は、図３のトランスコード制御部３０２の機能の一部を実現する。
【００９８】
まず、受信されたトランスコード設定要求によって指定されたマルチキャストデータ（ＭＣ）について以下の設定が実行される（ステップＳ７１１）。
（Ａ）自ノードよりも上流ノード（広帯域ネットワーク１０６側のノード）でのトランスコードが指定されている場合は、以下の設定がなされる。即ち、ＭＣデータ受信管理部３０１のフィルタ機能に対し、マルチキャストアドレスが一致するＭＰＥＧ２データを破棄し、マルチキャストアドレスが一致するＭＰＥＧ４データを透過する設定がなされる。
【００９９】
（Ｂ）自ノードよりも下流ノード（狭帯域ネットワーク１０７側のノード）でのトランスコードが指定されている場合は、以下の設定がなされる。即ち、ＭＣデータ受信管理部３０１のフィルタ機能に対し、マルチキャストアドレスが一致するＭＰＥＧ２データ及びＭＰＥＧ４データの双方とも透過する設定がなされる。
【０１００】
（Ｃ）自ノードでのトランスコードが指定されている場合は、以下の設定がなされる。即ち、ＭＣデータ受信管理部３０１のフィルタ機能に対し、マルチキャストアドレスが一致するＭＰＥＧ２データを、＃１から＃４のうち指定されたポートのトランスコーダ１０２部（図３参照）に転送する設定がなされる。
【０１０１】
その後、トランスコード設定要求を送信したノード（自分自身）へトランスコード設定応答が送信される（ステップＳ７１２）。その後、ステップＳ７０２の事象待機処理に戻る。
【０１０２】
次に、前述したステップＳ７１０の判定がＮＯとなった場合には、図８の動作フローチャートになり、図７のステップＳ７０１で設定されたグループ内ヘルスチェックタイマがタイムアウトしたか否かが判定される（ステップＳ８０１）。
【０１０３】
ステップＳ８０１の判定がＹＥＳならば、以下のステップＳ８０２からＳ８０４の一連の処理が実行される。この処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
【０１０４】
まず、全スレーブへヘルスチェックが送信される（ステップＳ８０２）。このとき、グループ内の全ノードの自グループトランスコード状況情報３１８（図２４参照）が通知される。
【０１０５】
次に、グループ内ヘルスチェックタイマがリセットされる（ステップＳ８０３）。
その後、ヘルスチェック応答タイマが開始される（ステップＳ８０４）。このタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１０６】
前述したステップＳ８０１の判定がＮＯとなった場合には、ステップＳ８０２にて送信されたヘルスチェックに対する応答が返信されたか否かが判定される（ステップＳ８０５）。
【０１０７】
ステップＳ８０５の判定がＹＥＳならば、以下のステップＳ８０６からＳ８０８の一連の処理が実行される。この処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
【０１０８】
まず、受信された応答パケットに含まれる自グループトランスコード状況情報３１８によって、自装置内の自グループトランスコード状況情報３１８が更新される（ステップＳ８０６）
次に、全スレーブノードからヘルスチェック応答が受信済みとなったか否かが判定される（ステップＳ８０７）。
【０１０９】
ステップＳ８０７の判定がＮＯならば、図７のステップＳ７０２の事象待機処理に戻る。
ステップＳ８０７の判定がＹＥＳになると、ヘルスチェック応答タイマが終了させられる（ステップＳ８０８）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１１０】
前述したステップＳ８０６の判定がＮＯとなった場合には、ステップＳ８０４で設定されたグループ内ヘルスチェック応答タイマがタイムアウトしたか否かが判定される（ステップＳ８０９）。
【０１１１】
ステップＳ８０９の判定がＹＥＳならば、以下のステップＳ８１０からＳ８１４の一連の処理が実行される。この処理は、図３のトランスコード制御部３０２の一部の機能を実現する。
【０１１２】
まず、ヘルスチェック応答がタイムアウトしたノードはトランスコードしているマルチキャストデータ（ＭＣ）が有るか否かが判定される（ステップＳ８１０）。
ステップＳ８１０の判定がＮＯならば、図７のステップＳ７０２の事象待機処理に戻る。
【０１１３】
ステップＳ８１０の判定がＹＥＳならば、トランスコード管理テーブル３１２（図３、図２５参照）が参照されることにより、新たにステップＳ８１０で判定されたマルチキャストデータをトランスコードできる空き状態のノード（オートトランスコーダ１０１）（Ｘ）及びその配下のトランスコーダ１０２（Ｙ）が検索される（ステップＳ８１１）。
【０１１４】
次に、ステップＳ８１０で判定されたマルチキャストデータ（以下、指定ＭＣと呼ぶ）について、以下の設定内容を有するトランスコード設定要求が作成される（ステップＳ８１２）。
【０１１５】
（Ａ）ノード（Ｘ）よりも上流ノード（広帯域ネットワーク１０６側のノード）に対しては、指定ＭＣのＭＰＥＧ２データ及びＭＰＥＧ４データの双方とも透過する設定を要求する。
【０１１６】
（Ｂ）ノード（Ｘ）よりも下流ノード（狭帯域ネットワーク１０７側のノード）に対しては、指定ＭＣのＭＰＥＧ２データを破棄し、指定ＭＣのＭＰＥＧ４データを透過する設定を要求する。
【０１１７】
（Ｃ）ノード（Ｘ）に対しては、指定ＭＣのＭＰＥＧ２データを、＃１から＃４のうちトランスコーダ（Ｙ）に対応するポートのトランスコーダ１０２部（図３参照）への転送を要求する。
【０１１８】
次に、他にステップＳ８１０で判定されたマルチキャストデータ（ＭＣ）が有るか否かが判定される（ステップＳ８１３）。
ステップＳ８１３の判定がＹＥＳならば、更にステップＳ８１１とＳ８１２が実行されて、そのマルチキャストデータに対応するトランスコード設定要求が作成される。
【０１１９】
ステップＳ８１３の判定がＮＯになると、作成された１つ以上のトランスコード設定要求が、各スレーブ装置に向けて送信される（ステップＳ８１４）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１２０】
次に、前述したステップＳ８０９の判定がＮＯとなった場合には、図９の動作フローチャートになり、図２のＷｅｂ保守端末１０８から所定のマルチキャストデータ（ＭＣ）に対するトランスコード開始要求が受信されたか否かが判定される（ステップＳ９０１）。
【０１２１】
ステップＳ９０１の判定がＹＥＳならば、以下のステップＳ９０２からＳ９０４の一連の処理が実行される。この処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
【０１２２】
まず、図８のステップＳ８１１の場合と同様に、トランスコード管理テーブル３１２（図３、図２５参照）が参照されることにより、指定されたマルチキャストデータをトランスコードできる空き状態のノード（オートトランスコーダ１０１）（Ｘ）及びその配下のトランスコーダ１０２（Ｙ）が検索される（ステップＳ９０２）。
【０１２３】
次に、ステップＳ９０２で判定されたマルチキャストデータ（以下、指定ＭＣと呼ぶ）について、図８のステップＳ８１２の場合と同様の設定内容を有するトランスコード設定要求が作成される（ステップＳ９０３）。
【０１２４】
そして、作成されたトランスコード設定要求が、各スレーブ装置に向けて送信される（ステップＳ９０４）。その後、図７のステップＳ７０２の事象待機処理に戻る。
次に、前述したステップＳ９０１の判定がＮＯとなった場合には、図１０の動作フローチャートになり、図７のステップＳ７０１で開始されたＭＣデータ受信チェックタイマがタイムアウトしたか否かが判定される（ステップＳ１００１）。
【０１２５】
ステップＳ１００１の判定がＹＥＳならば、以下のステップＳ１００２からＳ１０１７及び図１１のステップＳ１１０１からＳ１１１１の一連の処理が実行される。この処理は、図３のＭＣデータ受信管理部３０１、トランスコード制御部３０２、グループ内情報管理部３０４、透過・破棄ＭＣ情報管理部３０８の一部の機能を実現する。
【０１２６】
まず、図６のステップＳ６０２で更新されているメモリ上の受信キューがポーリングされる（ステップＳ１００２）。
次に、その受信キューにパケットが蓄積されているか否かが判定される（ステップＳ１００３）。
【０１２７】
ステップＳ１００３の判定がＮＯならば、図７のステップＳ７０２の事象待機処理に戻る。
ステップＳ１００３の判定がＹＥＳならば、受信キューからパケットが取り込まれる（ステップＳ１００４）。
【０１２８】
次に、図３の優先（緊急）テーブル３１４に、優先マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１００５）。優先（緊急）テーブル３１４のデータ構成例は図２６に示される。このテーブル内の「PrMCAdd」フィールドがチェックされる。
【０１２９】
ステップＳ１００５の判定がＮＯなら、ステップＳ１０１４の処理に移る。
ステップＳ１００５の判定がＹＥＳならば、優先ＭＣアドレスは自グループ管理テーブルにエントリされているか否かが判定される（ステップＳ１００６）。自グループ管理テーブルは、図２４に示されるように、自グループトランスコード状況情報３１８の一部として管理されている。自グループ管理テーブルは、図２５に示されるデータ構成例を有し、トランスコード管理テーブル３１２、グループ内管理情報３１３、及び受信ＭＣデータ管理情報３１１とから構成される。
【０１３０】
ステップＳ１００６の判定がＹＥＳならば、自グループ管理テーブル設定がそのまま保持される（ステップＳ１００７）。
ステップＳ１００６の判定がＮＯならば、自グループ管理テーブルに優先ＭＣアドレスのエントリを追加可能であるか否か、即ち、エントリの空きがあるか否かが判定される（ステップＳ１００８）。
【０１３１】
ステップＳ１００８の判定がＮＯならば、自グループ管理テーブルに有る最も若いポートのエントリが削除される（ステップＳ１００９）。
ステップＳ１００８の判定がＹＥＳの場合又はステップＳ１００９の処理の後、
まず、図８のステップＳ８１１の場合と同様に、トランスコード管理テーブル３１２（図３、図２５参照）が参照されることにより、優先ＭＣをトランスコードできる空き状態のノード（オートトランスコーダ１０１）（Ｘ）及びその配下のトランスコーダ１０２（Ｙ）が検索される（ステップＳ１０１０）。
【０１３２】
次に、優先ＭＣに対応するマルチキャストデータ（以下、指定ＭＣと呼ぶ）について、図８のステップＳ８１２の場合と同様の設定内容を有するトランスコード設定要求が作成される（ステップＳ１０１１）。
【０１３３】
その後、トランスコードされる優先ＭＣのエントリが、トランスコード管理テーブル３１２（図２５参照）に追加される（ステップＳ１０１２）。
そして、作成されたトランスコード設定要求が、各スレーブ装置に向けて送信される（ステップＳ１０１３）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１３４】
ステップＳ１００５の判定がＮＯの場合又はステップＳ１００７の処理の後、図３の遮断（破棄）テーブル３１６に、遮断マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１０１４）。遮断（破棄）テーブル３１６のデータ構成例は図２７に示される。このテーブル内の「BlockMCAdd」フィールドがチェックされる。
【０１３５】
ステップＳ１０１４の判定がＮＯなら、ステップＳ１０１６の処理に移る。
ステップＳ１０１４の判定がＹＥＳならば、遮断ＭＣのエントリが自グループ管理テーブル（図２５参照）に追加される。そして、スレーブ装置に対して破棄登録通知が送信される。また、自ノードのＭＣデータ受信管理部３０１のフィルタ機能に、遮断ＭＣのパケットを破棄する設定がなされる（ステップＳ１０１５）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１３６】
ステップＳ１０１４の判定がＮＯならば、図３の透過テーブル３１５に、透過マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１０１６）。透過テーブル３１５のデータ構成例は図２７に示される。このテーブル内の「ThroughMCAdd」フィールドがチェックされる。
【０１３７】
ステップＳ１０１６の判定がＹＥＳならば、透過ＭＣのエントリが自グループ管理テーブル（図２５参照）に追加される。そして、スレーブ装置に対して透過登録通知が送信される。また、自ノードのＭＣデータ受信管理部３０１のフィルタ機能に、透過ＭＣのパケットを透過する設定がなされる（ステップＳ１０１７）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１３８】
次に、ステップＳ１０１６の判定がＮＯとなった場合、即ち、受信されたマルチキャストデータ（ＭＣ）が優先ＭＣでも遮断ＭＣでも透過ＭＣでもない場合には、図１１の動作フローチャートに移る。
【０１３９】
まず、図１０のステップＳ１００４で取得されたＭＣアドレスを検索キーにして、自グループ管理テーブル（図２５参照）が検索される（ステップＳ１１０１）。
この検索の結果、取得されたＭＣアドレスが自グループ管理テーブルにあるか否かが判定される（ステップＳ１１０２）。
【０１４０】
ステップＳ１１０２の判定がＹＥＳならば、自グループ管理テーブル内のトランスコード管理テーブル３１２のタイムスタンプフィールド「TimeStamp」が更新される（ステップＳ１１０３）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１４１】
ステップＳ１１０２の判定がＮＯならば、自装置のトランスコード状態に空きがあるか否かが判定される（ステップＳ１１０４）。
ステップＳ１１０４の判定がＹＥＳならば、空きが検出されたトランスコード部３０３に、トランスコード開始指示のシグナルが出力される（ステップＳ１１０５）。
【０１４２】
続いて、トランスコード部３０３からＭＣデータ受信管理部３０１へ指示が出され、そのトランスコード部３０３に対応するトランスコーダ接続ポートへのマルチキャストデータ（ＭＣ）の転送設定がなされる（ステップＳ１１０６）。
【０１４３】
更に、トランスコード部３０３からトランスコーダ１０２へ、トランスコード開始/停止コマンドが発行される（ステップＳ１１０７）。
そして、トランスコード部３０３が、トランスコーダ１０２から取得したコマンドレスポンス結果やトランスコード状態を、自グループ管理テーブル（図２５）に更新して反映させる（ステップＳ１１０８）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１４４】
前述のステップＳ１１０４の判定がＮＯならば、処理されたＭＣに対応するマルチキャストデータ（以下、指定ＭＣと呼ぶ）について、図８のステップＳ８１２の場合と同様の設定内容を有するトランスコード設定要求が作成される（ステップＳ１１０９）。
【０１４５】
その後、トランスコードされるＭＣのエントリが、トランスコード管理テーブル３１２（図２５参照）に追加される（ステップＳ１１１０）。
そして、作成されたトランスコード設定要求が、各スレーブ装置に向けて送信される（ステップＳ１１１１）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１４６】
次に、前述したステップＳ１０１８の判定がＮＯとなった場合には、図１２の動作フローチャートになり、図７のステップＳ７０１で開始されたメイン選出情報要求タイマがタイムアウトしたか否かが判定される（ステップＳ１２０１）。
【０１４７】
ステップＳ１２０１の判定がＹＥＳならば、以下のステップＳ１２０２とＳ１２０３の処理が実行される。この処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１４８】
まず、グループ共通定義ファイル３１０（図２２、図２３参照）に定義されている各グループの一番プライオリティが高いノード宛に、メイン選出情報要求が送信される（ステップＳ１２０２）。
【０１４９】
次に、メイン選出情報応答タイマが開始される（ステップＳ１２０３）。このタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１５０】
前述のステップＳ１２０１の判定がＮＯならば、メイン選出情報要求が受信されたか否かが判定される（ステップＳ１２０４）。
ステップＳ１２０４の判定がＹＥＳならば、以下のステップＳ１２０５の処理が実行される。この処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１５１】
即ち、グループ間通信部３０７を介して、自ノードのプライオリティが返される（ステップＳ１２０５）。なお、自グループトランスコード状況情報３１８も通知される。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１５２】
前述のステップＳ１２０４の判定がＮＯならば、メイン選出情報応答が受信されたか否かが判定される（ステップＳ１２０６）。
ステップＳ１２０６の判定がＹＥＳならば、以下のステップＳ１２０７からＳ１２１３の処理が実行される。これらの処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１５３】
まず、グループ間通信部３０７を介して受信されたメイン選出情報応答から、送信元のノードのプライオリティと、送信元のノードが属するグループの自グループトランスコード状況情報３１８が取得され、グループ間トランスコード状況情報３１７に設定される（ステップＳ１２０７）。
【０１５４】
その後、全ノードから応答が有ったか否かが判定される（ステップＳ１２０８）。
ステップＳ１２０８の判定がＮＯならば、図７のステップＳ７０２の事象待機処理に戻る。
【０１５５】
ステップＳ１２０８の判定がＹＥＳならば、メイン選出情報応答タイマが終了させられる（ステップＳ１２０９）。
次に、メイン選出情報応答を送信したノードのプライオリティと自ノードのプライオリティが比較される（ステップＳ１２１０）。
【０１５６】
そして、自ノードのプライオリティが一番高いか否かが判定される（ステップＳ１２１１）。
ステップＳ１２１１の判定がＹＥＳならば、メイン装置の運用状態へ遷移し（ステップＳ１２１２）、図７〜図１３の動作フローチャートの処理を終了する。
【０１５７】
一方、ステップＳ１２１１の判定がＮＯならば、サブメイン装置の運用状態へ遷移し（現在の状態を維持し）（ステップＳ１２１３）、その後、その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１５８】
前述したステップＳ１２０６の判定がＮＯならば、ステップＳ１２０３で開始されたメイン選出情報応答タイマがタイムアウトしたか否かが判定される（ステップＳ１２１４）。
【０１５９】
ステップＳ１２１４の判定がＹＥＳならば、前述のステップＳ１２０９からＳ１２１３と同様の処理が実行される。これらの処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１６０】
この場合には、全てのノードからメイン選出情報応答が得られていなくても、現在までに得られているノードのプライオリティを使って、メインマスタ装置又はサブメインマスタ装置への遷移が実行される（ステップＳ１２１４→Ｓ１２０９からＳ１２１３）。
【０１６１】
次に、前述した図１２のステップＳ１２１４の判定がＮＯとなった場合には、図１３の動作フローチャートになり、グループ間通信部３０７を介してグループ間ヘルスチェックが受信されたか否かが判定される（ステップＳ１３０１）。
【０１６２】
ステップＳ１３０１の判定がＹＥＳならば、以下のステップＳ１３０２からＳ１３０５の一連の処理が実行される。この処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１６３】
まず、メインマスタ装置のプライオリティと自ノードのプライオリティとが比較される（ステップＳ１３０２）。
そして、自ノードの方がプライオリティが高いか否かが判定される（ステップＳ１３０３）。
【０１６４】
ステップＳ１３０３の判定がＹＥＳならば、メインマスタ装置の運用状態へ遷移される（ステップＳ１３０４）。その後、図７〜図１３の動作フローチャートの処理を終了する。
【０１６５】
ステップＳ１３０３の判定がＮＯならば、ヘルスチェック応答がメインマスタ装置に送信される（ステップＳ１３０５）。
その後、グループ間ヘルスチェックタイマがリセットされ（ステップＳ１３０６）、図７のステップＳ７０２の事象待機処理に戻る。
【０１６６】
前述のステップＳ１３０１の判定がＮＯならば、図７のステップＳ７０１で開始されたグループ間ヘルスチェックタイマがタイムアウトしたか否かが判定される（ステップＳ１３０７）。
【０１６７】
メインマスタ装置が故障してグループ間ヘルスチェックが受信されずステップＳ１３０７の判定がＹＥＳとなると、以下のステップＳ１３０８からＳ１３１４の一連の処理が実行される。これらの処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１６８】
まず、自グループのＱｏＳ最大値（許容量）がデフォルト値のままであるか否かが判定される（ステップＳ１３０８）。
ステップＳ１３０８の判定がＹＥＳならば、ステップＳ１３１２に移行する。
【０１６９】
ステップＳ１３０８の判定がＮＯならば、ＱｏＳ最大値がデフォルト値に戻される（ステップＳ１３０９）。
次に、優先マルチキャストデータ及び透過設定マルチキャストデータ以外のマルチキャストデータのエントリが選択されて、トランスコード管理テーブル３１２から削除される（ステップＳ１３１０）。
【０１７０】
次に、自グループの狭帯域流入量がＱｏＳ最大値以内であるか否かが判定される（ステップＳ１３１１）。
ステップＳ１３１１の判定がＮＯならば、ステップＳ１３１０の処理に戻って、更にマルチキャストデータのエントリが削除される。
【０１７１】
ステップＳ１３１１の判定がＹＥＳになると、削除したマルチキャストデータについて、トランスコード要求によって他ノードへ停止指示が出される（ステップＳ１３１２）。
そして、メイン選出情報要求が各グループのマスタ装置へ送信される（ステップＳ１３１３）。
その後、グループ間ヘルスチェックタイマがリセットされ（ステップＳ１３０６）、図７のステップＳ７０２の事象待機処理に戻る。
【０１７２】
図１４から図１８は、スレーブ装置（ノード）として動作するオートトランスコーダ１０１の制御動作を示す動作フローチャートである。
【０１７３】
まず、ヘルスチェック受信タイマが開始される（ステップＳ１４０１）。このタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。
次に、新たな情報受信の事象が発生したか否かの待ち状態となる（ステップＳ１４０２）。
【０１７４】
続いて、ステップＳ１４０３からＳ１４０９の処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
まず、ヘルスチェックが受信されたか否かが判定される（ステップＳ１４０３）。
【０１７５】
ステップＳ１４０３の判定がＹＥＳとなると、ヘルスチェック受信タイマが終了させられる（ステップＳ１４０４）。
次に、受信されたパケットに含まれる自グループトランスコード状況情報３１８によって、自装置内の自グループトランスコード状況情報３１８が更新される（ステップＳ１４０５）
次に、更新された自グループトランスコード状況情報３１８と、グループ共通定義ファイル３１０が参照されることにより、自ノードと新たに起動したノードのプライオリティが比較される（ステップＳ１４０６）。
【０１７６】
そして、自ノードのプライオリティが最高であるか否かが判定される（ステップＳ１４０７）。
ステップＳ１４０７の判定がＹＥＳならば、マスタ装置の運用状態へ遷移される（ステップＳ１４０８）。図１４の動作フローチャートの処理が終了する。
【０１７７】
一方、ステップＳ１４０７の判定がＮＯならば、ヘルスチェック応答が送信される（ステップＳ１４０９）。このとき、自ノードの自グループトランスコード状況情報３１８が通知される。
【０１７８】
その後、現在のスレーブ装置の運用状態が維持され、ステップＳ１４０１の処理に戻る。
前述したステップＳ１４０３の判定がＮＯの場合には、図１５の動作フローチャートに移り、ヘルスチェック受信タイマがタイムアウトしたか否かが判定される（ステップＳ１５０１）。
【０１７９】
ステップＳ１５０１の判定がＹＥＳならば、以下のステップＳ１５０２からＳ１５０５の処理が実行される。これらの処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
【０１８０】
まず、自グループトランスコード状況情報３１８とグループ共通定義ファイル３１０が参照されて、自ノードのプライオリティと起動中のノードのプライオリティが比較される（ステップＳ１５０２）。
【０１８１】
この結果、自ノードのプライオリティが最高であるか否かが判定される（ステップＳ１５０３）。
ステップＳ１５０３の判定がＹＥＳならば、マスタ装置の運用状態に遷移される（ステップＳ１５０４）。
【０１８２】
ステップＳ１５０３の判定がＮＯならば、スレーブ装置の運用状態維持される（ステップＳ１５０５）。その後、その後、図１４のステップＳ１４０１の処理に戻る。
前述したステップＳ１５０１の判定がＮＯの場合には、図１６の動作フローチャートに移り、トランスコード設定要求が受信されたか否かが判定される（ステップＳ１６０１）。
【０１８３】
ステップＳ１６０１の判定がＹＥＳならば、以下のステップＳ１６０２とＳ１６０３の処理が実行される。これらの処理は、図３のトランスコード制御部３０２の一部の機能を実現する。
【０１８４】
まず、トランスコード設定要求に基づき、ＭＣデータ受信管理部３０１のフィルタ機能に対して、遮断・透過などの設定が行われる。また、自グループトランスコード状況情報３１８が更新される（ステップＳ１６０２）。
【０１８５】
次に、トランスコード設定要求によって指定されたトランスコード部３０３に対して、ＭＰＥＧ２からＭＰＥＧ４へのトランスコードの実行が指示される（ステップＳ１６０３）。その後、図１４のステップＳ１４０２の事象待機処理に戻る。
【０１８６】
次に、前述したステップＳ１６０１の判定がＮＯとなった場合には、図１７の動作フローチャートになり、図１４のステップＳ１４０１で開始されたＭＣデータ受信チェックタイマがタイムアウトしたか否かが判定される（ステップＳ１７０１）。
【０１８７】
ステップＳ１７０１の判定がＹＥＳならば、以下のステップＳ１７０２からＳ１７１１及び図１８のステップＳ１８０１からＳ１８０８の一連の処理が実行される。この処理は、図３のＭＣデータ受信管理部３０１、トランスコード制御部３０２、グループ内情報管理部３０４、透過・破棄ＭＣ情報管理部３０８の一部の機能を実現する。
【０１８８】
まず、図６のステップＳ６０２で更新されているメモリ上の受信キューがポーリングされる（ステップＳ１７０２）。
次に、その受信キューにパケットが蓄積されているか否かが判定される（ステップＳ１７０３）。
【０１８９】
ステップＳ１７０３の判定がＮＯならば、図１４のステップＳ１４０１の処理に戻る。
ステップＳ１７０３の判定がＹＥＳならば、受信キューからパケットが取り込まれる（ステップＳ１７０４）。
【０１９０】
次に、図３の優先（緊急）テーブル３１４に、優先マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１７０５）。優先（緊急）テーブル３１４のデータ構成例は図２６に示される。このテーブル内の「PrMCAdd」フィールドがチェックされる。
【０１９１】
ステップＳ１７０５の判定がＮＯなら、ステップＳ１７０８の処理に移る。
ステップＳ１７０５の判定がＹＥＳならば、優先ＭＣアドレスは自グループ管理テーブル（図２５参照）にエントリされているか否かが判定される（ステップＳ１７０６）。
【０１９２】
ステップＳ１７０６の判定がＮＯならば、ステップＳ１７０８の処理に移る。
ステップＳ１７０６の判定がＹＥＳならば、自グループ管理テーブル設定がそのまま保持される（ステップＳ１７０７）。
【０１９３】
ステップＳ１７０５、Ｓ１７０６の判定がＮＯの場合又はステップＳ１７０７の処理の後、図３の遮断（破棄）テーブル３１６に、遮断マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１７０８）。遮断（破棄）テーブル３１６のデータ構成例は図２７に示される。このテーブル内の「BlockMCAdd」フィールドがチェックされる。
【０１９４】
ステップＳ１７０８の判定がＮＯなら、ステップＳ１７１０の処理に移る。
ステップＳ１７０８の判定がＹＥＳならば、遮断ＭＣのエントリが自グループ管理テーブル（図２５参照）に追加される。そして、自ノードのＭＣデータ受信管理部３０１のフィルタ機能に、遮断ＭＣのパケットを破棄する設定がなされる（ステップＳ１７１１）。その後、図１４のステップＳ１４０２の事象待機処理に戻る。
【０１９５】
ステップＳ１７０８の判定がＮＯならば、図３の透過テーブル３１５に、透過マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１７１０）。透過テーブル３１５のデータ構成例は図２７に示される。このテーブル内の「ThroughMCAdd」フィールドがチェックされる。
【０１９６】
ステップＳ１７１０の判定がＹＥＳならば、透過ＭＣのエントリが自グループ管理テーブル（図２５参照）に追加される。そして、自ノードのＭＣデータ受信管理部３０１のフィルタ機能に、透過ＭＣのパケットを透過する設定がなされる（ステップＳ１７１１）。その後、図１４のステップＳ１４０２の事象待機処理に戻る。
【０１９７】
次に、ステップＳ１７１０の判定がＮＯとなった場合、即ち、受信されたマルチキャストデータ（ＭＣ）が優先ＭＣでも遮断ＭＣでも透過ＭＣでもない場合には、図１８の動作フローチャートに移る。
【０１９８】
まず、図１７のステップＳ１７０４で取得されたＭＣアドレスを検索キーにして、自グループ管理テーブル（図２５参照）が検索される（ステップＳ１８０１）。
この検索の結果、取得されたＭＣアドレスが自グループ管理テーブルにあるか否かが判定される（ステップＳ１７０２）。
【０１９９】
ステップＳ１１０２の判定がＮＯならば、マスタ装置に対して、トランスコード設定要求が送信される（ステップＳ１８０９）。その後、図１４のステップＳ１４０２の事象待機処理に戻る。
【０２００】
ステップＳ１１０２の判定がＹＥＳならば、自グループ管理テーブル内のトランスコード管理テーブル３１２のタイムスタンプフィールド「TimeStamp」が更新される（ステップＳ１８０３）。
【０２０１】
次に、自ノードにトランスコードが設定されているか否かが判定される（ステップＳ１８０４）。
ステップＳ１８０４の判定がＹＥＳならば、トランスコードの処理が継続されて、図１４のステップＳ１４０２の事象待機処理に戻る。
【０２０２】
ステップＳ１８０４の判定がＮＯならば、空きが検出されたトランスコード部３０３に、トランスコード開始指示のシグナルが出力される（ステップＳ１８０５）。
続いて、トランスコード部３０３からＭＣデータ受信管理部３０１へ指示が出され、そのトランスコード部３０３に対応するトランスコーダ接続ポートへのマルチキャストデータ（ＭＣ）の転送設定がなされる（ステップＳ１８０６）。
【０２０３】
更に、トランスコード部３０３からトランスコーダ１０２へ、トランスコード開始/停止コマンドが発行される（ステップＳ１８０７）。
そして、トランスコード部３０３が、トランスコーダ１０２から取得したコマンドレスポンス結果やトランスコード状態を、自グループ管理テーブル（図２５）に更新して反映させる（ステップＳ１８０８）。その後、図１４のステップＳ１４０２の事象待機処理に戻る。
【０２０４】
図１９から図２１は、メインマスタ装置（ノード）として動作するオートトランスコーダ１０１の制御動作を示す動作フローチャートである。
まず、グループ間ヘルスチェック送信タイマが開始される（ステップＳ１９０１）。
【０２０５】
次に、新たな情報受信の事象が発生したか否かの待ち状態となる（ステップＳ１９０２）。
続いて、ステップＳ１９０３からＳ１９０５の処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０２０６】
まず、グループ間ヘルスチェック送信タイマが満了したか否かが判定される（ステップＳ１９０３）。
【０２０７】
ステップＳ１９０３の判定がＹＥＳになると、各グループのマスタに対しグループ間ヘルスチェックが送信される（ステップＳ１９０４）。このとき、グループ間トランスコード状況情報３１７が送信される。グループ間トランスコード状況情報３１７は、図２９に示されるように、全グループの各自グループトランスコード状況情報３１８を合わせた情報である。
【０２０８】
次に、ヘルスチェック応答タイマが開始される（ステップＳ１９０５）。このタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。その後、図１９のステップＳ１９０２の事象待機処理に戻る。
【０２０９】
ステップＳ１９０３の判定がＮＯならば、図２０の動作フローチャートの処理に移り、ヘルスチェック応答が受信されたか否かが判定される（ステップＳ２００１）。
ステップＳ２００１の判定がＹＥＳならば、以下のステップＳ２００２からＳ２０１１の一連の処理が実行される。これらの処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０２１０】
まず、自ノードのプライオリティは最高であるか否かが判定される（ステップＳ２００２）。
次に、受信されたヘルスチェック応答の内容によって、グループ間トランスコード状況情報３１７が更新される（ステップＳ２００３）。
【０２１１】
次に、受信されたヘルスチェック応答の応答内容は、所定の閾値（％）を超える流入量であるか否かが判定される（ステップＳ２００４）。グループ毎の閾値は、図２９に例示されるグループ間トランスコード状況情報３１７中のカレントＱｏＳ閾値（流入量閾値）が用いられる。
【０２１２】
ステップＳ２００４の判定がＹＥＳならば、流入量が「閾値−調整レート」以下のグループ有るか否かが判定される（ステップＳ２００５）。
ステップＳ２００５の判定がＮＯならば、図１９のステップＳ１９０２の事象待機処理に戻る。
【０２１３】
ステップＳ２００５の判定がＹＥＳならば、一番流入量の少ないグループが抽出される（ステップＳ２００６）。
次に、抽出されたグループの閾値を下げる指示のヘルスチェックが生成される（ステップＳ２００７）。
【０２１４】
一方、ステップＳ２００４の判定がＮＯならば、閾値を下げる指示を含むヘルスチェックに対する応答があったか否かが判定される（ステップＳ２００８）。
ステップＳ２００８の判定がＮＯならば、ステップＳ２０１０が実行される。
【０２１５】
ステップＳ２００８の判定がＹＥＳならば、閾値を下げた分だけ、ひとつのグループ（Ａ）に閾値を上げる指示のヘルスチェックが生成される（ステップＳ２００９）。
ステップＳ２００７又はＳ２００９の処理の後、全マスタから応答が有ったか否かが判定される（ステップＳ２０１０）。
【０２１６】
ステップＳ２０１０の判定がＮＯならば、図１９のステップＳ１９０２の事象待機処理に戻る。
ステップＳ２０１０の判定がＹＥＳならば、ヘルスチェック応答タイマが終了させられ（ステップＳ２０１１）、その後、図１９のステップＳ１９０２の事象待機処理に戻る。
【０２１７】
前述したステップＳ２００１の判定がＮＯならば、図２１の動作フローチャートの処理に移り、図１９のステップＳ１９０５で開始されたヘルスチェック応答タイマがタイムアウトしたか否かが判定される（ステップＳ２１０１）。
【０２１８】
ステップＳ２１０１の判定がＹＥＳならば、以下のステップＳ２１０２からＳ２１１２の一連の処理が実行される。これらの処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０２１９】
まず、タイムアウトしたグループはＱｏＳ最大値を変更しているか否かが判定さえる（ステップＳ２１０２）。
ステップＳ２１０２の判定がＮＯならば、図１９のステップＳ１９０２の事象待機処理に戻る。
【０２２０】
ステップＳ２１０２の判定がＹＥＳならば、タイムアウトしたグループはＱｏＳ最大値を減らしているか否かが判定される（ステップＳ２１０３）。
ステップＳ２１０３の判定がＹＥＳならば、自グループのＱｏＳ最大値（許容量）がデフォルト値のままであるか否かが判定される（ステップＳ２１０４）。
【０２２１】
ステップＳ２１０４の判定がＹＥＳならば、ステップＳ２１０９に移行する。
ステップＳ２１０４の判定がＮＯならば、ＱｏＳ最大値がデフォルト値に戻される（ステップＳ２１０５）。
【０２２２】
次に、優先マルチキャストデータ及び透過設定マルチキャストデータ以外のマルチキャストデータのエントリが選択されて、トランスコード管理テーブル３１２から削除される（ステップＳ２１０６）。
【０２２３】
次に、自グループの狭帯域流入量がＱｏＳ最大値以内であるか否かが判定される（ステップＳ２１０７）。
ステップＳ２１０７の判定がＮＯならば、ステップＳ２１０６の処理に戻って、更にマルチキャストデータのエントリが削除される。
【０２２４】
ステップＳ２１０７の判定がＹＥＳになると、削除したマルチキャストデータについて、トランスコード要求によって自グループ内ノードへ停止指示が出される（ステップＳ２１０８）。
【０２２５】
その後、トランスコード応答タイマが開始され、図１９のステップＳ１９０２の事象待機処理に戻る。
前述したステップＳ２１０３の判定がＮＯの場合には、タイムアウトしたグループがＱｏＳ最大値を増やしていた分、多の減らしているグループのＱｏＳ最大値を増やす（デフォルト値に戻す）処理が実行される（ステップＳ２１１０）。
【０２２６】
次に、ＱｏＳ最大値を再設定したグループ間トランスコード状況情報３１７が送信される（ステップＳ２１１１）。
その後、ヘルスチェック応答タイマが開始され（ステップＳ２１１２）、図１９のステップＳ１９０２の事象待機処理に戻る。
【０２２７】
以上説明した実施形態により、オートトランスコーダの多段接続構成により、狭帯域ネットワークに流入する映像ストリーム等の大容量データが帯域を超えないように制御することが可能となる。
【０２２８】
また、指定の映像ストリーム等を、元のレートのまま狭帯域を通し、高品質の映像を提供することが可能となる。
更に、トランスコード状況と映像ストリーム等の狭帯域ネットワークへの流入量に関する情報が、各グループ内及び複数のグループ間で共有されることにより、グループ内及びグループ間の各オートトランスコーダが協同的に、狭帯域への流入制御を実施することが可能となる。
【０２２９】
更に、オートトランスコーダの冗長構成により、１システムがダウンしても予備のオートトランスコーダが状態を引き継いでトランスコードすることが可能となる。
また、モニタ映像を見た結果、鮮明な映像が必要になった場合に、トランスコードのレートを上げ優先して狭帯域ネットワークを通すような制御が可能となる。
【０２３０】
加えて、不必要な映像が狭帯域ネットワークを使用しないように制御することが可能となる。
【符号の説明】
【０２３１】
１０１ オートトランスコーダ
１０２ トランスコーダ
１０３ 広帯域側Ｌ３スイッチ
１０４ 狭帯域側Ｌ３スイッチ
１０５ カメラ
１０６ 広帯域ネットワーク
１０７ 狭帯域ネットワーク
１０８ Ｗｅｂ保守端末
２０１ スイッチボックス
３０１ ＭＣデータ受信管理部
３０２ トランスコード制御部
３０３ トランスコード部
３０４ グループ内情報管理部
３０５ グループ内通信部
３０６ グループ間情報管理部
３０７ グループ間通信部
３０８ 透過・破棄ＭＣ情報管理部
３０９ Ｗｅｂ画面制御部
３１０ グループ共通定義ファイル
３１１ 受信ＭＣデータ管理情報
３１２ トランスコード管理テーブル
３１３ グループ内管理情報
３１４ 優先（緊急）テーブル
３１５ 透過テーブル
３１６ 遮断（破棄）テーブル
３１７ グループ間トランスコード状況情報３１７
３１８ 自グループトランスコード状況情報
３１９ 自グループトラフィック流入情報
【技術分野】
【０００１】
複数の映像ストリームのような大容量データを例えば光ファイバネットワークのような広帯域ネットワークから例えばマイクロ網のような狭帯域ネットワークに配信する大容量データの配信技術に関する。本発明は例えば、広帯域ネットワークと狭帯域ネットワークが複数箇所で接続された構成において、広帯域ネットワークから映像ストリームのような高レートメディア情報が一度に流れ込む映像配信システムに適用することができる。
【背景技術】
【０００２】
国土交通省等が管理する河川映像管理ネットワークなどにおいては、多数の地点のカメラ映像等を広帯域ネットワークを通じて収集する映像配信システムが構築されている。このようなネットワークは、災害時などにおいて重要なカメラ映像等を収集する必要がある。このため、広帯域ネットワークに障害が発生した場合等におけるバックアップ回線としての意味を持つ最終冗長経路としての、マイクロ波網等によって構成される狭帯域ネットワークが必要となる。
【０００３】
現状の利用状況としては、広帯域ネットワークから狭帯域ネットワークへは、データ系、音声系のみが疎通可能であり、狭帯域のため映像は規制されている。このため、狭帯域ネットワーク上の帯域が余ってしまっており有効利用がなされていない。しかし本来は、有事の時等にこそ映像情報が必要なはずであり、広帯域ネットワークから狭帯域ネットワークへ映像情報を流し込む技術が必要とされる。この場合に、光網等の広帯域ネットワークと同一の使用方法（同一レートの映像）では、帯域的に狭帯域ネットワークを利用することは不可能である。このため、狭帯域ネットワーク全体で映像シェーピングを実現する機能が必要とされる。
【０００４】
狭帯域ネットワークへの流入制御に関する従来技術
以上の背景を前提として、まず広帯域ネットワークから狭帯域ネットワークへの流入制御を行う従来技術としては、以下の技術がある。
【０００５】
１つの広帯域ネットワークから接続する狭帯域ネットワークに送信する映像ストリームの総容量は、狭帯域ネットワークの帯域容量を超えないで流す必要がある。そこで、レイヤ３スイッチ（以降「Ｌ３スイッチ」と呼ぶ）又はレイヤ２スイッチ（以降「Ｌ２スイッチ」と呼ぶ）等のルータ装置で、映像情報が狭帯域ネットワークに流入する前に固定的に特定ストリームに制限(破棄)される。これにより、狭帯域ネットワークに送信される映像ストリーム数を減らす従来技術が知られている。
【０００６】
また、ネットワークを流れる映像ストリーム(マルチキャスト)を自動でトランスコード(デコード/エンコード)して映像ストリームの転送レートを下げる、オートトランスコーダと呼ばれる装置の従来技術が知られている。
【０００７】
狭帯域ネットワーク全体の制御に関する従来技術
次に、狭帯域ネットワーク全体の制御を行う従来技術としては、以下の技術がある。
狭帯域ネットワークはバックアップ回線に使用されるので、映像配信システムはネットワークの冗長切替を意識する必要があり、バックアップ回線に切り替わった場合は配信ストリーム数を少なくする必要がある。そこで、Ｌ３スイッチやＬ２スイッチにおいて、映像ストリームのフィルタリングを設定し、固定的に狭帯域ネットワークへ流入数を制限する従来技術が知られている。
【０００８】
また、マルチキャストアドレスを特定の許可されたアドレスに変換する事により任意の映像ストリームを狭帯域ネットワークに流入させる従来技術が知られている。
更に、広帯域ネットワークから狭帯域ネットワークへの１流入箇所での映像ストリームにつき、複数台からなる１グループのオートトランスコーダ群を使って、流入量を一定に制限し、順番(先着順)に低レートの映像ストリームへ変換する従来技術が知られている。
【０００９】
ストリーム選択に関する従来技術
次に、広帯域ネットワークから狭帯域ネットワークへ流入するストリームを選択するための従来技術としては、以下の技術がある。
Ｌ２スイッチやＬ３スイッチにおいて、フィルタリング機能によって、特定の映像ストリームを固定的に又は手動で選択する従来技術が知られている。
【００１０】
また、Ｌ２スイッチやＬ３スイッチでの特定の映像ストリームの選択を、サーバからの定義データの設定により行う従来技術が知られている。
更に、オートトランスコーダにおける優先制御設定により、特定の映像ストリームのトランスコードを予約する従来技術が知られている。
【００１１】
信頼性を確保する従来技術
広帯域ネットワークと狭帯域ネットワークの接続において信頼性を確保するための従来技術としては、以下の技術がある。
【００１２】
広帯域ネットワークから狭帯域ネットワークに送信される映像ストリーム(マルチキャスト)は、経路変化の状況により狭帯域ネットワークへの流入箇所が変わり、各映像ストリームの流入ポイントが不定となる可能性がある。このような場合を考慮して、複数箇所のＬ２スイッチやＬ３スイッチで冗長的にストリームをフィルタリングする従来技術が知られている。
【００１３】
また、Ｌ２スイッチやＬ３スイッチの故障を考慮して、複数箇所のＬ２スイッチやＬ３スイッチで冗長的にストリームをフィルタリングする従来技術が知られている。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２００５−１８４３８７号公報
【特許文献２】特開２００２−８４５２５号公報
【特許文献３】特開平１１−２２５１６８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１５】
狭帯域ネットワークへの流入制御に関する課題
広帯域ネットワークから狭帯域ネットワークへの流入制御を行う従来技術に関する問題点としては、以下の点があげられる。
【００１６】
広帯域ネットワークと狭帯域ネットワークの間のＬ２／Ｌ３スイッチでフィルタリングを行った場合、狭帯域ネットワークに流せる映像ストリームの本数が極端に少なくなってしまうという問題点を有していた。例えば、２．４Ｇｂｐｓ（ギガビット／秒）の光ネットワークに６Ｍｂｐｓ（メガビット／秒）の映像ストリームは４００本流せるが、５２Ｍｂｐｓのマイクロネットワーク(狭帯域ネットワーク)では６Ｍｂｐｓの映像ストリームは８本しか流せなくなる。
【００１７】
また、従来のオートトランスコーダは６ＭｂｐｓのＭＰＥＧ２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ２）のストリームを１グループで４本しかトランスコードしないので、狭帯域ネットワークの使用効率が悪いという問題点を有していた。
【００１８】
流入させる映像ストリームの本数を増やすために、単純にトランスコーダで映像のレートを下げると、
更に、映像ストリームの転送レートを下げる従来のオートトランスコーダでは、マルチキャストアドレスの変換が行われる。このため、映像配信(切替え)システムの管理情報と矛盾が起こり(映像切替サーバのデータベースの登録内容と異なってしまう)、映像配信システムの障害が発生するおそれがあるという問題点を有していた。
【００１９】
狭帯域ネットワーク全体の制御に関する課題
狭帯域ネットワーク全体の制御を行う従来技術に関する問題点としては、以下の点があげられる。
【００２０】
多数の映像データが複数箇所で広帯域ネットワークから狭帯域ネットワークに流入する場合、複数箇所での流入量管理が必要になる。ダイナミックに流入させる映像を制御する場合、現状流れている映像ストリームをリアルタイムに管理する必要があり、映像選択状況を映像管理サーバから入手する手間が発生するという問題点を有していた。
【００２１】
また、広帯域ネットワーク側で冗長構成を組んでいると、どのグループから映像ストリーム流入してくるかわからないので、全てのグループの手前でＬ２／Ｌ３スイッチにフィルタ設定を行う必要があり、管理が複雑になるという問題点を有していた。
【００２２】
また、固定的に狭帯域ネットワークの帯域内でしか映像が流れないように特定の映像ストリームのみを流すようなフィルタ設定を行うと、設定許可された映像ストリームが流れていない場合に狭帯域ネットワークを有効に活用できないという問題点を有していた。
【００２３】
更に、オートトランスコーダのように映像ストリームのレート変換装置を狭帯域ネットワークの入口に設置して無条件でレート変換する構成が採用された場合を考える。この場合には、各オートトランスコーダはお互いに独立してトランスコードするので、複数グループでの流入量制御ができないという問題点を有していた。
【００２４】
ストリーム選択に関する課題
広帯域ネットワークから狭帯域ネットワークへ流入するストリームを選択するための従来技術の問題点としては、以下の点があげられる。
【００２５】
広帯域ネットワーク側で冗長構成を採用しているときには、狭帯域ネットワークのどのポイントから映像ストリームが流入するか分からない。このため、Ｌ２／Ｌ３スイッチでのフィルタリング設定を行う場合に、狭帯域ネットワークへの複数の入口のＬ２／Ｌ３スイッチの全てに同じ設定をしなくてはならないという問題点を有していた。
【００２６】
同様の理由で、他の接続装置についても冗長構成が採用されているときには、冗長を構成する装置全てに同じ設定をする必要があるという問題点を有していた。
また、現状のオートトランスコーダは、映像ストリームの転送レートの変換は可能であるが、重要映像を高画質のまま狭帯域ネットワークに流入させる事はできない。従って、低レート映像を見て重要な映像を選択して高画質映像のままモニタするような、レート切替(画質切替)ができないという問題点を有していた。
【００２７】
更に、オートトランスコーダを使用した場合、トランスコードしている映像ストリーム以外のＭＰＥＧ２マルチキャストは破棄されてしまうため、高画質な映像を受信することはできないという問題点を有していた。
【００２８】
信頼性の確保に関する課題
広帯域ネットワークと狭帯域ネットワークの接続において信頼性を確保するための従来技術の問題点としては、以下の点があげられる。
【００２９】
複数箇所からの映像ストリームの流入や故障を考慮してＬ３スイッチで冗長構成がとられる場合は、コストが高くなるという問題点を有していた。
また、オートトランスコーダを用いた構成において、オートトランスコーダで障害が発生すると、高トラフィックのＭＰＥＧ２映像ストリームがそのまま狭帯域ネットワークに流れてしまい、狭帯域ネットワークの帯域オーバフローを起こす可能性がある。このような事態がもし発生した場合、狭帯域ネットワークを流れる全映像ストリームでパケット抜けを起こす場合があるという問題点を有していた。
【００３０】
更に、狭帯域ネットワークに映像ストリームが迂回している場合、狭帯域ネットワークが分断され、その中でＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ：帯域保証）制御が各々行われている場合を考える。この場合、狭帯域ネットワークが分断から復旧した瞬間に帯域オーバしてしまい全映像ストリームが影響を受けてしまう可能性があるという問題点を有していた。
【００３１】
以上説明したように、広帯域ネットワークから狭帯域ネットワークへの映像ストリームのような大容量データの流入制御の問題点は、次のようになる。即ち、流入箇所に割り当てた使用可能帯域を固定的にて単純に複数ストリームのトランスコードを行うような制御では、流入箇所に偏りが生じうる環境では、割当て帯域に不足・無駄が生じる可能性が否めないという問題点を有していた。
【００３２】
また、Ｌ２／Ｌ３スイッチ等のルータ装置で流入制御を行うためには、全てのルータに設定を行う必要があるという問題点を有していた。
そこで、本発明の１つの側面では、ルータに流入制御を設定することなく、狭帯域ネットワーク全体の使用可能帯域をもとに、流入箇所毎に使用可能帯域を割り当て、大容量データをトランスコードして流入可能とすることを目的とする。また、好ましくは、指定された映像データについては高レートのまま流入可能とすることを目的とする。
【課題を解決するための手段】
【００３３】
態様の一例では、複数の大容量データを広帯域ネットワークから狭帯域ネットワークに配信する大容量データ配信システムとして実現され、以下の構成を有する。
まず、大容量データのレート変換を行うレート変換装置を搭載しレート変換装置を制御するレート変換制御装置を多段接続して広帯域ネットワークからの大容量データの流入を引き受けるグループが形成される。
【００３４】
そして、レート変換制御装置が、以下の各部を備える。
まず、トランスコード制御部は、自レート変換制御装置で大容量データをレート変換できない場合に、同一のグループ内の他のレート変換制御装置でその大容量データをレート変換させるために、その大容量データを透過させる制御を行う。
【００３５】
透過情報管理部は、指定された大容量データを、グループ内の全レート変換制御装置でレート変換を行わずに透過させる制御を行う。
グループ内情報管理部は、トランスコード制御部及び透過情報管理部の制御状態を、グループ内の他のレート変換制御装置との間で、自グループトランスコード状況情報として交換し設定する。
【発明の効果】
【００３６】
レート変換制御装置の多段接続構成により、狭帯域ネットワークに流入する映像ストリーム等の大容量データが帯域を超えないように制御することが可能となる。
また、指定の大容量データを、元のレートのまま狭帯域を通し、高品質の映像を提供することが可能となる。
【００３７】
更に、レート変換状況と大容量データの狭帯域ネットワークへの流入量に関する情報が、各グループ内及び複数のグループ間で共有されることにより、グループ内及びグループ間の各レート変換制御装置が協同的に、狭帯域への流入制御を実施することが可能となる。
【００３８】
更に、レート変換制御装置の冗長構成により、１システムがダウンしても予備のトランスコーダが状態を引き継いでトランスコードすることが可能となる。
【図面の簡単な説明】
【００３９】
【図１】実施形態の全体システム構成図である。
【図２】オートトランスコーダの接続形態を示す図である。
【図３】オートトランスコーダの機能構成図である。
【図４】全ノード共通の、起動時におけるマスタ選出処理を示す動作フローチャートである。
【図５】全ノード共通の、運用時におけるマスタ選出情報応答処理を示す動作フローチャートである。
【図６】全ノード共通の、運用時におけるMCデータ受信処理を示す動作フローチャートである。
【図７】サブメインマスタノードの制御動作を示す動作フローチャート（その１）である。
【図８】サブメインマスタノードの制御動作を示す動作フローチャート（その２）である。
【図９】サブメインマスタノードの制御動作を示す動作フローチャート（その３）である。
【図１０】サブメインマスタノードの制御動作を示す動作フローチャート（その４）である。
【図１１】サブメインマスタノードの制御動作を示す動作フローチャート（その５）である。
【図１２】サブメインマスタノードの制御動作を示す動作フローチャート（その６）である。
【図１３】サブメインマスタノードの制御動作を示す動作フローチャート（その７）である。
【図１４】スレーブノードの制御動作を示す動作フローチャート（その１）である。
【図１５】スレーブノードの制御動作を示す動作フローチャート（その２）である。
【図１６】スレーブノードの制御動作を示す動作フローチャート（その３）である。
【図１７】スレーブノードの制御動作を示す動作フローチャート（その４）である。
【図１８】スレーブノードの制御動作を示す動作フローチャート（その５）である。
【図１９】メインマスタノードの制御動作を示す動作フローチャート（その１）である。
【図２０】メインマスタノードの制御動作を示す動作フローチャート（その２）である。
【図２１】メインマスタノードの制御動作を示す動作フローチャート（その３）である。
【図２２】グループ共通定義ファイルのデータ構成例を示す図である。
【図２３】グループ共通定義ファイルの各パラメタの説明図である。
【図２４】自グループトランスコード状況情報と自グループトラフィック流入情報のデータ構成例を示す図である。
【図２５】自グループ管理テーブルのデータ構成例を示す図である。
【図２６】優先（緊急）テーブルのデータ構成例を示す図である。
【図２７】遮断(破棄)テーブルのデータ構成例を示す図である。
【図２８】透過テーブルのデータ構成例を示す図である。
【図２９】グループ間トランスコード状況情報のデータ構成例を示す図である。
【発明を実施するための形態】
【００４０】
以下、本発明を実施するための形態について図面を参照しながら詳細に説明する。
図１は、実施形態の全体システム構成図である。
広帯域ネットワーク１０６に接続される広帯域側Ｌ３（レイヤ３）スイッチ（図中「Ｌ３ＳＷ」と表記）１０３には、＃１から＃５までの５台の通常はスレーブ装置兼現用系として動作するレート変換制御装置であるオートトランスコーダ１０１が縦属に接続される。また、＃５のオートトランスコーダ１０１には、通常はマスタ装置兼予備系として動作する１台のオートトランスコーダ１０１が接続される。このオートトランスコーダ１０１は、狭帯域ネットワーク１０７に接続される狭帯域側Ｌ３スイッチ（図中「μＬ３ＳＷ」と表記）１０４に接続される。各オートトランスコーダ１０１には、４台までのレート変換装置であるトランスコーダ１０２を接続可能である。各トランスコーダ１０２は、広帯域ネットワーク１０６側のカメラ１０５から広帯域側Ｌ３スイッチ１０３を介して流入する、１本の映像ストリームをＭＰＥＧ２からＭＰＥＧ４の転送レートに変換する。ＭＰＥＧ２の転送レートは例えば６Ｍｂｐｓ、ＭＰＧＥ４の転送レートは例えば２６ｋｂｐｓ（キロビット／秒）〜５１９ｋｂｐｓである。従って、１台のオートトランスコーダ１０１は、最大で４本の映像ストリームのレート変換が可能である。上述の＃１から＃５までの５台のスレーブ装置と１台のマスタ装置からなる６台のオートトランスコーダ１０１と、それぞれに接続されるトランスコーダ１０２群とが、狭帯域ネットワーク接続の１グループを形成する。１つの狭帯域ネットワーク接続グループでは、現用系として動作する５台のオートトランスコーダ１０１によって、最大で２０本までの映像ストリームのレート変換が可能となる。
【００４１】
図１では、４つの狭帯域ネットワーク接続グループが、それぞれ広帯域ネットワーク１０６内の１台の広帯域側Ｌ３スイッチ１０３と狭帯域ネットワーク１０７内の１台の狭帯域側Ｌ３スイッチ１０４と接続される。従って、図１の場合、広帯域ネットワーク１０６側の各カメラ１０５から流入する最大で２０本×４グループ＝８０本までの映像ストリームについて、レート変換を行って狭帯域ネットワーク１０７に流入させることが可能となる。狭帯域ネットワーク１０７の帯域幅は、例えば４８Ｍｂｐｓである。
【００４２】
図１において、Ｗｅｂ保守端末１０８は、広帯域側Ｌ３スイッチ１０３又は狭帯域側Ｌ３スイッチ１０４を介して、各オートトランスコーダ１０１を、Ｗｅｂインターフェースにより制御可能である。
【００４３】
グループ内の各オートトランスコーダ１０１は、図２に示されるように、１台の広帯域側Ｌ３スイッチ１０３と１台の狭帯域側Ｌ３スイッチ１０４の間を結ぶ主回線２０２に、スイッチボックス２０１を介して接続される。スイッチボックス２０１は、正常動作時には、通常時パス２０３として示されるように、主回線２０２から流入する映像ストリームをオートトランスコーダ１０１に取り込んで、その配下のトランスコーダ１０２でレート変換処理を実行させる。一方、スイッチボックス２０１は、オートトランスコーダ１０１で障害が発生したときには、障害時パス２０４として示されるように、オートトランスコーダ１０１への接続を切って、主回線２０２上の信号を後続のオートトランスコーダ１０１に透過させる。
【００４４】
以上の構成を有する実施形態の概略動作について、以下に説明する。
まず、グループ内の制御の概略について説明する。
【００４５】
グループ内トランスコード制御
上述したように１つの狭帯域ネットワーク接続グループでは、６台のオートトランスコーダ１０１がスイッチボックス２０１（図２）によって縦属（直列）に接続される。
【００４６】
システムの起動時には、グループ内での情報共有のために、グループ内で１台のマスタ装置と５台のスレーブ装置が決定される。また、５台の現用系装置と１台の予備系装置が決定される。図１の例では、＃１から＃５のオートトランスコーダ１０１が、スレーブ装置兼現用系装置に割り当てられ、残りの１台のオートトランスコーダ１０１が、マスタ装置兼予備系装置として割り当てられる。これらの割当ては、運用状態によって、マスタ装置／スレーブ装置、及び現用系／予備系を、それぞれ独立して動的に変更可能である。
【００４７】
なお、以下の説明では、オートトランスコーダ１０１をノードと呼ぶ場合があり、マスタ装置をマスタノード、スレーブ装置をスレーブノードと呼ぶ場合がある。
グループ内の各オートトランスコーダ１０１は、グループ内の他のオートトランスコーダ１０１とプライオリティ（ノードプライオリティ）の交換を行い、マスタ装置を選出する。
【００４８】
マスタ装置は、スレーブ装置のトランスコード処理数を管理する。マスタ装置は、スレーブ装置に、変換レート（映像ストリーム数）を通知する。スレーブ装置は、マスタ装置に、トランスコード状況を自グループトランスコード状況情報（後述する図３、図２４参照）として、定期的に通知する。マスタ装置とスレーブ装置間で実行される通知処理をヘルスチェックと呼ぶ。マスタ装置は、広帯域ネットワーク１０６から流入するＭＰＥＧ４のトラフィック流入量を監視し、狭帯域ネットワーク１０７への流入量にカウントする。
【００４９】
マスタ装置は、スレーブ装置に例えば２秒間隔でヘルスチェック処理を実行する。ヘルスチェックにより、後述する自グループ管理テーブル（トランスコード情報）（図３、図２５参照）の情報が、マスタ装置とスレーブ装置間で共有される。
【００５０】
マスタ装置から送信されるヘルスチェックでは、グループ内の全てのオートトランスコーダ１０１のトランスコード管理テーブル３１２の情報が通知され、スレーブ装置から応答されるヘルスチェックでは、自装置（そのスレーブ装置自身）のトランスコード管理テーブル３１２の情報が通知される。
【００５１】
グループ内での映像ストリームのトランスコードは、ノード１（図１では＃１のオートトランスコーダ１０１）から順番に実行され、１つのノードでトランスコードできなくなった映像ストリームは次のノードへ転送される。
マスタ装置がダウンした場合には、別のスレーブ装置がマスタ装置に遷移する。
【００５２】
グループ内優先制御
本実施形態では、広帯域ネットワーク１０６から狭帯域ネットワーク１０７に優先的に転送する映像ストリームを指定することができる。このための制御が、優先制御である。この制御は、グループ毎に設定され実行される。
【００５３】
優先制御は、グループ共通定義ファイル３１０（図３、図２２、図２３参照）とＷｅｂ保守端末１０８から設定することができる。グループ共通定義ファイル３１０での設定は固定的であり、Ｗｅｂ保守端末１０８からの設定は動的な設定が可能である。
【００５４】
Ｗｅｂ保守端末１０８によって優先制御の設定を行う場合、Ｗｅｂ保守端末１０８→マスタ装置→グループ内オートトランスコーダ１０１という流れで制御が実行される。
優先制御では、マスタ装置が、優先制御をかけるオートトランスコーダ１０１を選び、選択したオートトランスコーダ１０１に優先設定コマンドを発行する。このとき、ノードプライオリティの低いオートトランスコーダ１０１から順番に、トランスコーダ１０２に空きがあれば優先設定が行われてゆく。
【００５５】
優先制御が行われているオートトランスコーダ１０１がダウンした場合、マスタ装置が、ダウンしたオートトランスコーダ１０１で設定されていた優先設定を他のオートトランスコーダ１０１へ設定する。
【００５６】
各オートトランスコーダ１０１は、優先テーブルを０．５秒毎にチェックし、自装置よりも上流（広帯域ネットワーク１０６側）に位置するオートトランスコーダ１０１の優先ストリームは破棄し、自装置の優先ストリームはトランスコードし、下流のオートトランスコーダ１０１の優先ストリームは転送（透過）する。
【００５７】
グループ内特定ＭＰＥＧ２透過制御
本実施形態では、広帯域ネットワーク１０６から流入する特定のＭＰＥＧ２広帯域映像ストリーム、例えばヘリコプターテレビ映像等のストリームを、レート変換せずに狭帯域ネットワーク１０７側に透過させることができる。そのための制御が、特定ＭＰＥＧ２透過制御である。この制御は、グループ毎に設定され実行される。
【００５８】
特定ＭＰＥＧ２透過制御は、グループ共通定義ファイル３１０により固定的に設定することができる（図３、図２２、図２３参照）。
透過指定された例えば６Ｍｂｐｓの映像ストリーム帯域は、実際に流れていなくてもスタティックに確保される。
【００５９】
グループ内特定ＭＰＥＧ２／４遮断制御
本実施形態では、広帯域ネットワーク１０６から流入する特定のＭＰＥＧ２又はＭＰＥＧ４の映像ストリームを、遮断することができる。そのための制御が、特定ＭＰＥＧ２／４遮断制御である。この制御は、グループ毎に設定され実行される。
【００６０】
特定ＭＰＥＧ２／４遮断制御は、グループ共通定義ファイル３１０（図３、図２２、図２３参照）とＷｅｂ保守端末１０８から設定することができる。グループ共通定義ファイル３１０での設定は固定的であり、Ｗｅｂ保守端末１０８からの設定は動的な設定が可能である。
【００６１】
グループ内トラフィック流入量制御
本実施形態では、グループを通過するＭＰＥＧ２／４の映像ストリームのトラフィック流入量を把握する制御が実行される。
【００６２】
グループ毎に、流入量の閾値を設定することができる。流入量の閾値は、グループ共通定義ファイル３１０（図３、図２２、図２３参照）で設定できるようにする。流入量の閾値は、デフォルト値がグループ共通定義ファイル３１０定義ファイルの設定値とされ、その後、グループ間で調整された新しい閾値が動的に設定される。
トラフィック流入量が閾値を超過した場合、超過したトラフィックが遮断される。
【００６３】
グループ間のトランスコード情報共有
以上がグループ内の制御の概略である。次に、グループ間の制御の概略について説明する。
【００６４】
グループ間の制御においては、まず、トランスコード情報が共有される。
複数のグループの各マスタ装置のうちの１つが、メインマスタ装置として動作する。
メインマスタ装置は、各グループの代表ノード（サブメインマスタ装置）から、トランスコード状態、流入量情報等を、グループ間トランスコード状況情報３１７（図３、図２９参照）の一部として収集する。メインマスタ装置は、各グループのサブメインマスタ装置に、ヘルスチェック機能(グループ間状態情報通知／応答昨日)によって、全グループに関するグループ間トランスコード状況情報３１７を配布する。これにより、各グループでは、システム全体のトランスコード情報等を共有することができる。
【００６５】
また、メインマスタ装置は、オートトランスコーダ１０１を６Ｍｂｐｓのまま透過又は遮断させるＭＣアドレスの設定情報を、グループ間トランスコード状況情報３１７（図３、図２９参照）の一部として各グループから収集し、グループ間で情報共有させる。
【００６６】
グループ間の狭帯域ネットワーク１０７への流入量制御
メインマスタ装置は、狭帯域ネットワーク１０７に流入する流量を制御するために、各グループのサブメインマスタ装置から流入量情報を収集する。
【００６７】
メインマスタ装置は、各グループの流入量情報を参照し、閾値を超えそうなグループに対し、余裕あるグループの予約帯域をシフト(再分配)することにより、全体の流入量を調整し狭帯域ネットワーク１０７を効率良く使用する。再配分は、ヘルスチェック処理により情報収集して、ヘルスチェック処理により情報通知して行う。情報通知の時間は、例えば１０秒程度である。
【００６８】
メインマスタ装置は、グループ共通定義ファイル３１０（図３、図２２、図２３参照）に記載されているグループのサブメインマスタ装置が検出できない場合は、そのグループとの間で予約帯域の調整はせずに帯域を確保しておく。これにより、狭帯域ネットワーク１０７におけるリング分断等からの復旧時も、狭帯域ネットワーク１０７の帯域オーバを防ぐことができる。
【００６９】
以上の概略動作を実現する実施形態の具体的な処理機能について、以下に詳細に説明する。
【００７０】
図２は、図１のオートトランスコーダ１０１の機能構成図である。オートトランスコーダ１０１の機能は、ＭＣデータ受信管理部３０１、トランスコード制御部３０２、トランスコード部３０３、グループ内情報管理部３０４、グループ内通信部３０５、グループ間情報管理部３０６、グループ間通信部３０７、透過・破棄ＭＣ情報管理部３０８、及びＷｅｂ画面制御部３０９によって実現される。また、オートトランスコーダ１０１は、グループ共通定義ファイル３１０、受信ＭＣデータ管理情報３１１、トランスコード管理テーブル３１２、グループ内管理情報３１３、優先（緊急）テーブル３１４、透過テーブル３１５、遮断（破棄）テーブル３１６、グループ間管理情報３１７、自グループトランスコード状況情報３１８、及び自グループトラフィック流入情報３１９の各情報を管理する。
【００７１】
上記各機能部３０１から３０９を実現する制御動作は、図４から図２１の動作フローチャートの処理として示される。これらの処理は、特には図示しない中央演算処理装置が、特には図示しないメモリに記憶された制御プログラムを実行する動作として実現される。
【００７２】
図４は、全ノード（オートトランスコーダ１０１）に共通の、起動時におけるマスタ選出処理を示す動作フローチャートである。この動作フローチャートは、図３のグループ内情報管理部３０４の機能の一部を実現する。
【００７３】
まず、自装置内のＭＣデータ受信管理部３０１（図３）のフィルタ機能に対して、受信された全てのマルチキャストパケット（以下「ＭＣ」と呼ぶ）を透過（スルー）する設定がなされる（ステップＳ４０１）。
【００７４】
次に、図３、図２２及び図２３に示されるデータ構成例を有するグループ共通定義ファイル３１０に定義されている自グループ内のノード宛てに、図３のグループ内通信部３０５を介して、マスタ選出情報要求（起動モード）が送信される（ステップＳ４０２）。具体的には、グループ共通定義ファイル３１０内のCTL_NODE1からCTL_NODE6（図２２、図２３参照）で示される各ノードのＩＰアドレスを宛先アドレスとして、所定のパケットフォーマットを有するマスタ選出情報要求（起動モード）が送信される。
【００７５】
次に、マスタ選出情報応答待ちタイマ（起動モード）が開始される（ステップＳ４０３）。このタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。
【００７６】
次に、グループ内通信部３０５を介して新たな情報受信の事象が発生したか否かの待ち状態となる（ステップＳ４０４）。この間、何れかのノードからマスタ選出情報応答が受信された場合には、その応答に対応するパケットのソースアドレスとして、応答を送信したノードの識別情報が特には図示しないメモリに記録される。
【００７７】
一定時間の事象発生待機（ステップＳ４０４）の後、上記ノードの識別情報がチェックされることにより、全ノードからマスタ選出情報応答が受信されたか否かが判定される（ステップＳ４０５）。
【００７８】
ステップＳ４０５の判定がＮＯならば、ステップＳ４０３で開始されたマスタ選出情報応答待ちタイマ（起動モード）がタイムアウトしたか否かが判定される（ステップＳ４０６）
ステップＳ４０６の判定がＮＯならば、ステップＳ４０４に戻って新たな事象待ち状態が繰り返される。
【００７９】
全ノードからマスタ選出情報応答が受信されてステップＳ４０５の判定がＹＥＳ、又はマスタ選出情報応答待ちタイマ（起動モード）がタイムアウトしてステップＳ４０６の判定がＹＥＳになると、以下の処理が実行される。
【００８０】
まず、マスタ選出情報応答待ちタイマ（起動モード）が終了させられる（ステップＳ４０７）。
次に、ステップＳ４０４でメモリ上に記録されている各ノードの識別情報に基づいて、グループ共通定義ファイル３１０から応答を受信したノードのプライオリティ情報が取得され、各ノードのプライオリティが自ノードのプライオリティと比較される（ステップＳ４０８）。具体的には、グループ共通定義ファイル３１０内の各ノードアドレス毎のPRIORITY値（図２２、図２３参照）が比較される。
【００８１】
そして、自ノードのプライオリティが最高であるか否かが判定される（ステップＳ４０９）。
自ノードのプライオリティが最高であってステップＳ４０９の判定がＹＥＳならば、自ノードがマスタ装置の運用状態に遷移される（ステップＳ４１０）。その後、図４の動作フローチャートの処理が終了する。マスタ装置の運用状態に遷移したオートトランスコーダ１０１は、後述する図５、図６、図７から図１３（サブメインマスタ装置及びメインマスタ装置の両方）、及び図１９から図２１（メインマスタ装置のみ）の動作フローチャートの処理を実行する。
【００８２】
自ノードのプライオリティが最高ではなくてステップＳ４０９の判定がＮＯならば、自ノードがスレーブ装置の運用状態に遷移される（ステップＳ４１１）。その後、図４の動作フローチャートの処理が終了する。スレーブ装置の運用状態に遷移したオートトランスコーダ１０１は、後述する図５、図６、及び図１４から図１８の動作フローチャートの処理を実行する。
【００８３】
図５は、全ノード（オートトランスコーダ１０１）に共通の、運用時におけるマスタ選出情報応答処理を示す動作フローチャートである。この動作フローチャートは、図３のグループ内情報管理部３０４の機能の一部を実現する。
【００８４】
まず、図３のグループ内通信部３０５を介してマスタ選出情報要求が受信されたか否かが判定される（ステップＳ５０１）。
ステップＳ５０１の判定がＮＯならば、一定時間後に再度ステップＳ５０１の判定が実行される動作が繰り返される。
【００８５】
ステップＳ５０１の判定がＹＥＳならば、マスタ選出情報応答のパケットが、受信されたマスタ選出情報要求のパケットのソースＩＰアドレスに対して返信される（ステップＳ５０２）。その後、ステップＳ５０１の判定処理に戻る。
【００８６】
図５の動作フローチャートの処理によって、前述した図４のステップＳ４０２でマスタ選出情報要求を送信したノードは、図４のステップＳ４０４で、各ノードからその要求に対応するマスタ選出情報応答を受信することができる。
【００８７】
図６は、全ノード（オートトランスコーダ１０１）に共通の、運用時における映像ストリームのマルチキャストデータの受信処理を示す動作フローチャートである。この動作フローチャートは、図３のＭＣデータ受信管理部３０１の機能の一部を実現する。
【００８８】
まず、マルチキャストデータ（ＭＣ）が受信されたか否かが判定される（ステップＳ６０１）。
ステップＳ６０１の判定がＮＯならば、再度ステップＳ６０１の判定が実行される動作が繰り返される。
【００８９】
ステップＳ６０１の判定がＹＥＳならば、受信したＭＰＥＧ２データのｉ−ｐｉｃｔｕｒｅ部の先頭６４バイトが特には図示しないメモリ内の受信キューにコピーされる（ステップＳ６０２）。その後、ステップＳ６０１の判定処理に戻る。
【００９０】
図６の動作フローチャートの処理によって、オートトランスコーダ１０１は、映像ストリームのＭＰＥＧ２データを受信することができる。
図７から図１３は、サブメインマスタ装置（ノード）として動作するオートトランスコーダ１０１の制御動作を示す動作フローチャートである。
【００９１】
まず、グループ内ヘルスチェックタイマ、グループ間ヘルスチェックタイマ、メイン選出情報要求送信タイマ、及びＭＣデータ受信チェックタイマがそれぞれ開始される（ステップＳ７０１）。これらのタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。
【００９２】
次に、新たな情報受信の事象が発生したか否かの待ち状態となる（ステップＳ７０２）。
続いて、ステップＳ７０３からＳ７０９の処理は、自ノードよりもプライオリティが高く設定されたノードが起動されてマスタ装置に遷移し、ヘルスチェックを送信したとき（図８のステップＳ８０２参照）の受信動作を示す処理である。この処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
【００９３】
まず、ヘルスチェックが受信されたか否かが判定される（ステップＳ７０３）。
ステップＳ７０３の判定がＹＥＳとなると、受信されたパケットに含まれる自グループトランスコード状況情報３１８によって、自装置内の自グループトランスコード状況情報３１８が更新される（ステップＳ７０４）
次に、更新された自グループトランスコード状況情報３１８と、グループ共通定義ファイル３１０が参照されることにより、自ノードと新たに起動したノードのプライオリティが比較される（ステップＳ７０５）。
【００９４】
そして、自ノードのプライオリティが最高であるか否かが判定される（ステップＳ７０６）。
ステップＳ７０６の判定がＹＥＳならば、マスタ装置の状態が維持される（ステップＳ７０７）。その後、ステップＳ７０２の事象待機処理に戻る。
【００９５】
一方、ステップＳ７０６の判定がＮＯならば、ヘルスチェック応答が送信される（ステップＳ７０８）。このとき、自ノードの自グループトランスコード状況情報３１８が通知される。
【００９６】
その後、スレーブ装置の運用状態へ遷移し（ステップＳ７０９）、図７の動作フローチャートの処理を終了する。
前述したステップＳ７０３の判定がＮＯの場合には、次に、トランスコード設定要求が受信されたか否かが判定される（ステップＳ７１０）。
【００９７】
ステップＳ７１０の判定がＹＥＳの場合、以下のステップＳ７１１とＳ７１２の処理が実行される。これらの処理は、図３のトランスコード制御部３０２の機能の一部を実現する。
【００９８】
まず、受信されたトランスコード設定要求によって指定されたマルチキャストデータ（ＭＣ）について以下の設定が実行される（ステップＳ７１１）。
（Ａ）自ノードよりも上流ノード（広帯域ネットワーク１０６側のノード）でのトランスコードが指定されている場合は、以下の設定がなされる。即ち、ＭＣデータ受信管理部３０１のフィルタ機能に対し、マルチキャストアドレスが一致するＭＰＥＧ２データを破棄し、マルチキャストアドレスが一致するＭＰＥＧ４データを透過する設定がなされる。
【００９９】
（Ｂ）自ノードよりも下流ノード（狭帯域ネットワーク１０７側のノード）でのトランスコードが指定されている場合は、以下の設定がなされる。即ち、ＭＣデータ受信管理部３０１のフィルタ機能に対し、マルチキャストアドレスが一致するＭＰＥＧ２データ及びＭＰＥＧ４データの双方とも透過する設定がなされる。
【０１００】
（Ｃ）自ノードでのトランスコードが指定されている場合は、以下の設定がなされる。即ち、ＭＣデータ受信管理部３０１のフィルタ機能に対し、マルチキャストアドレスが一致するＭＰＥＧ２データを、＃１から＃４のうち指定されたポートのトランスコーダ１０２部（図３参照）に転送する設定がなされる。
【０１０１】
その後、トランスコード設定要求を送信したノード（自分自身）へトランスコード設定応答が送信される（ステップＳ７１２）。その後、ステップＳ７０２の事象待機処理に戻る。
【０１０２】
次に、前述したステップＳ７１０の判定がＮＯとなった場合には、図８の動作フローチャートになり、図７のステップＳ７０１で設定されたグループ内ヘルスチェックタイマがタイムアウトしたか否かが判定される（ステップＳ８０１）。
【０１０３】
ステップＳ８０１の判定がＹＥＳならば、以下のステップＳ８０２からＳ８０４の一連の処理が実行される。この処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
【０１０４】
まず、全スレーブへヘルスチェックが送信される（ステップＳ８０２）。このとき、グループ内の全ノードの自グループトランスコード状況情報３１８（図２４参照）が通知される。
【０１０５】
次に、グループ内ヘルスチェックタイマがリセットされる（ステップＳ８０３）。
その後、ヘルスチェック応答タイマが開始される（ステップＳ８０４）。このタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１０６】
前述したステップＳ８０１の判定がＮＯとなった場合には、ステップＳ８０２にて送信されたヘルスチェックに対する応答が返信されたか否かが判定される（ステップＳ８０５）。
【０１０７】
ステップＳ８０５の判定がＹＥＳならば、以下のステップＳ８０６からＳ８０８の一連の処理が実行される。この処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
【０１０８】
まず、受信された応答パケットに含まれる自グループトランスコード状況情報３１８によって、自装置内の自グループトランスコード状況情報３１８が更新される（ステップＳ８０６）
次に、全スレーブノードからヘルスチェック応答が受信済みとなったか否かが判定される（ステップＳ８０７）。
【０１０９】
ステップＳ８０７の判定がＮＯならば、図７のステップＳ７０２の事象待機処理に戻る。
ステップＳ８０７の判定がＹＥＳになると、ヘルスチェック応答タイマが終了させられる（ステップＳ８０８）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１１０】
前述したステップＳ８０６の判定がＮＯとなった場合には、ステップＳ８０４で設定されたグループ内ヘルスチェック応答タイマがタイムアウトしたか否かが判定される（ステップＳ８０９）。
【０１１１】
ステップＳ８０９の判定がＹＥＳならば、以下のステップＳ８１０からＳ８１４の一連の処理が実行される。この処理は、図３のトランスコード制御部３０２の一部の機能を実現する。
【０１１２】
まず、ヘルスチェック応答がタイムアウトしたノードはトランスコードしているマルチキャストデータ（ＭＣ）が有るか否かが判定される（ステップＳ８１０）。
ステップＳ８１０の判定がＮＯならば、図７のステップＳ７０２の事象待機処理に戻る。
【０１１３】
ステップＳ８１０の判定がＹＥＳならば、トランスコード管理テーブル３１２（図３、図２５参照）が参照されることにより、新たにステップＳ８１０で判定されたマルチキャストデータをトランスコードできる空き状態のノード（オートトランスコーダ１０１）（Ｘ）及びその配下のトランスコーダ１０２（Ｙ）が検索される（ステップＳ８１１）。
【０１１４】
次に、ステップＳ８１０で判定されたマルチキャストデータ（以下、指定ＭＣと呼ぶ）について、以下の設定内容を有するトランスコード設定要求が作成される（ステップＳ８１２）。
【０１１５】
（Ａ）ノード（Ｘ）よりも上流ノード（広帯域ネットワーク１０６側のノード）に対しては、指定ＭＣのＭＰＥＧ２データ及びＭＰＥＧ４データの双方とも透過する設定を要求する。
【０１１６】
（Ｂ）ノード（Ｘ）よりも下流ノード（狭帯域ネットワーク１０７側のノード）に対しては、指定ＭＣのＭＰＥＧ２データを破棄し、指定ＭＣのＭＰＥＧ４データを透過する設定を要求する。
【０１１７】
（Ｃ）ノード（Ｘ）に対しては、指定ＭＣのＭＰＥＧ２データを、＃１から＃４のうちトランスコーダ（Ｙ）に対応するポートのトランスコーダ１０２部（図３参照）への転送を要求する。
【０１１８】
次に、他にステップＳ８１０で判定されたマルチキャストデータ（ＭＣ）が有るか否かが判定される（ステップＳ８１３）。
ステップＳ８１３の判定がＹＥＳならば、更にステップＳ８１１とＳ８１２が実行されて、そのマルチキャストデータに対応するトランスコード設定要求が作成される。
【０１１９】
ステップＳ８１３の判定がＮＯになると、作成された１つ以上のトランスコード設定要求が、各スレーブ装置に向けて送信される（ステップＳ８１４）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１２０】
次に、前述したステップＳ８０９の判定がＮＯとなった場合には、図９の動作フローチャートになり、図２のＷｅｂ保守端末１０８から所定のマルチキャストデータ（ＭＣ）に対するトランスコード開始要求が受信されたか否かが判定される（ステップＳ９０１）。
【０１２１】
ステップＳ９０１の判定がＹＥＳならば、以下のステップＳ９０２からＳ９０４の一連の処理が実行される。この処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
【０１２２】
まず、図８のステップＳ８１１の場合と同様に、トランスコード管理テーブル３１２（図３、図２５参照）が参照されることにより、指定されたマルチキャストデータをトランスコードできる空き状態のノード（オートトランスコーダ１０１）（Ｘ）及びその配下のトランスコーダ１０２（Ｙ）が検索される（ステップＳ９０２）。
【０１２３】
次に、ステップＳ９０２で判定されたマルチキャストデータ（以下、指定ＭＣと呼ぶ）について、図８のステップＳ８１２の場合と同様の設定内容を有するトランスコード設定要求が作成される（ステップＳ９０３）。
【０１２４】
そして、作成されたトランスコード設定要求が、各スレーブ装置に向けて送信される（ステップＳ９０４）。その後、図７のステップＳ７０２の事象待機処理に戻る。
次に、前述したステップＳ９０１の判定がＮＯとなった場合には、図１０の動作フローチャートになり、図７のステップＳ７０１で開始されたＭＣデータ受信チェックタイマがタイムアウトしたか否かが判定される（ステップＳ１００１）。
【０１２５】
ステップＳ１００１の判定がＹＥＳならば、以下のステップＳ１００２からＳ１０１７及び図１１のステップＳ１１０１からＳ１１１１の一連の処理が実行される。この処理は、図３のＭＣデータ受信管理部３０１、トランスコード制御部３０２、グループ内情報管理部３０４、透過・破棄ＭＣ情報管理部３０８の一部の機能を実現する。
【０１２６】
まず、図６のステップＳ６０２で更新されているメモリ上の受信キューがポーリングされる（ステップＳ１００２）。
次に、その受信キューにパケットが蓄積されているか否かが判定される（ステップＳ１００３）。
【０１２７】
ステップＳ１００３の判定がＮＯならば、図７のステップＳ７０２の事象待機処理に戻る。
ステップＳ１００３の判定がＹＥＳならば、受信キューからパケットが取り込まれる（ステップＳ１００４）。
【０１２８】
次に、図３の優先（緊急）テーブル３１４に、優先マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１００５）。優先（緊急）テーブル３１４のデータ構成例は図２６に示される。このテーブル内の「PrMCAdd」フィールドがチェックされる。
【０１２９】
ステップＳ１００５の判定がＮＯなら、ステップＳ１０１４の処理に移る。
ステップＳ１００５の判定がＹＥＳならば、優先ＭＣアドレスは自グループ管理テーブルにエントリされているか否かが判定される（ステップＳ１００６）。自グループ管理テーブルは、図２４に示されるように、自グループトランスコード状況情報３１８の一部として管理されている。自グループ管理テーブルは、図２５に示されるデータ構成例を有し、トランスコード管理テーブル３１２、グループ内管理情報３１３、及び受信ＭＣデータ管理情報３１１とから構成される。
【０１３０】
ステップＳ１００６の判定がＹＥＳならば、自グループ管理テーブル設定がそのまま保持される（ステップＳ１００７）。
ステップＳ１００６の判定がＮＯならば、自グループ管理テーブルに優先ＭＣアドレスのエントリを追加可能であるか否か、即ち、エントリの空きがあるか否かが判定される（ステップＳ１００８）。
【０１３１】
ステップＳ１００８の判定がＮＯならば、自グループ管理テーブルに有る最も若いポートのエントリが削除される（ステップＳ１００９）。
ステップＳ１００８の判定がＹＥＳの場合又はステップＳ１００９の処理の後、
まず、図８のステップＳ８１１の場合と同様に、トランスコード管理テーブル３１２（図３、図２５参照）が参照されることにより、優先ＭＣをトランスコードできる空き状態のノード（オートトランスコーダ１０１）（Ｘ）及びその配下のトランスコーダ１０２（Ｙ）が検索される（ステップＳ１０１０）。
【０１３２】
次に、優先ＭＣに対応するマルチキャストデータ（以下、指定ＭＣと呼ぶ）について、図８のステップＳ８１２の場合と同様の設定内容を有するトランスコード設定要求が作成される（ステップＳ１０１１）。
【０１３３】
その後、トランスコードされる優先ＭＣのエントリが、トランスコード管理テーブル３１２（図２５参照）に追加される（ステップＳ１０１２）。
そして、作成されたトランスコード設定要求が、各スレーブ装置に向けて送信される（ステップＳ１０１３）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１３４】
ステップＳ１００５の判定がＮＯの場合又はステップＳ１００７の処理の後、図３の遮断（破棄）テーブル３１６に、遮断マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１０１４）。遮断（破棄）テーブル３１６のデータ構成例は図２７に示される。このテーブル内の「BlockMCAdd」フィールドがチェックされる。
【０１３５】
ステップＳ１０１４の判定がＮＯなら、ステップＳ１０１６の処理に移る。
ステップＳ１０１４の判定がＹＥＳならば、遮断ＭＣのエントリが自グループ管理テーブル（図２５参照）に追加される。そして、スレーブ装置に対して破棄登録通知が送信される。また、自ノードのＭＣデータ受信管理部３０１のフィルタ機能に、遮断ＭＣのパケットを破棄する設定がなされる（ステップＳ１０１５）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１３６】
ステップＳ１０１４の判定がＮＯならば、図３の透過テーブル３１５に、透過マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１０１６）。透過テーブル３１５のデータ構成例は図２７に示される。このテーブル内の「ThroughMCAdd」フィールドがチェックされる。
【０１３７】
ステップＳ１０１６の判定がＹＥＳならば、透過ＭＣのエントリが自グループ管理テーブル（図２５参照）に追加される。そして、スレーブ装置に対して透過登録通知が送信される。また、自ノードのＭＣデータ受信管理部３０１のフィルタ機能に、透過ＭＣのパケットを透過する設定がなされる（ステップＳ１０１７）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１３８】
次に、ステップＳ１０１６の判定がＮＯとなった場合、即ち、受信されたマルチキャストデータ（ＭＣ）が優先ＭＣでも遮断ＭＣでも透過ＭＣでもない場合には、図１１の動作フローチャートに移る。
【０１３９】
まず、図１０のステップＳ１００４で取得されたＭＣアドレスを検索キーにして、自グループ管理テーブル（図２５参照）が検索される（ステップＳ１１０１）。
この検索の結果、取得されたＭＣアドレスが自グループ管理テーブルにあるか否かが判定される（ステップＳ１１０２）。
【０１４０】
ステップＳ１１０２の判定がＹＥＳならば、自グループ管理テーブル内のトランスコード管理テーブル３１２のタイムスタンプフィールド「TimeStamp」が更新される（ステップＳ１１０３）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１４１】
ステップＳ１１０２の判定がＮＯならば、自装置のトランスコード状態に空きがあるか否かが判定される（ステップＳ１１０４）。
ステップＳ１１０４の判定がＹＥＳならば、空きが検出されたトランスコード部３０３に、トランスコード開始指示のシグナルが出力される（ステップＳ１１０５）。
【０１４２】
続いて、トランスコード部３０３からＭＣデータ受信管理部３０１へ指示が出され、そのトランスコード部３０３に対応するトランスコーダ接続ポートへのマルチキャストデータ（ＭＣ）の転送設定がなされる（ステップＳ１１０６）。
【０１４３】
更に、トランスコード部３０３からトランスコーダ１０２へ、トランスコード開始/停止コマンドが発行される（ステップＳ１１０７）。
そして、トランスコード部３０３が、トランスコーダ１０２から取得したコマンドレスポンス結果やトランスコード状態を、自グループ管理テーブル（図２５）に更新して反映させる（ステップＳ１１０８）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１４４】
前述のステップＳ１１０４の判定がＮＯならば、処理されたＭＣに対応するマルチキャストデータ（以下、指定ＭＣと呼ぶ）について、図８のステップＳ８１２の場合と同様の設定内容を有するトランスコード設定要求が作成される（ステップＳ１１０９）。
【０１４５】
その後、トランスコードされるＭＣのエントリが、トランスコード管理テーブル３１２（図２５参照）に追加される（ステップＳ１１１０）。
そして、作成されたトランスコード設定要求が、各スレーブ装置に向けて送信される（ステップＳ１１１１）。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１４６】
次に、前述したステップＳ１０１８の判定がＮＯとなった場合には、図１２の動作フローチャートになり、図７のステップＳ７０１で開始されたメイン選出情報要求タイマがタイムアウトしたか否かが判定される（ステップＳ１２０１）。
【０１４７】
ステップＳ１２０１の判定がＹＥＳならば、以下のステップＳ１２０２とＳ１２０３の処理が実行される。この処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１４８】
まず、グループ共通定義ファイル３１０（図２２、図２３参照）に定義されている各グループの一番プライオリティが高いノード宛に、メイン選出情報要求が送信される（ステップＳ１２０２）。
【０１４９】
次に、メイン選出情報応答タイマが開始される（ステップＳ１２０３）。このタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１５０】
前述のステップＳ１２０１の判定がＮＯならば、メイン選出情報要求が受信されたか否かが判定される（ステップＳ１２０４）。
ステップＳ１２０４の判定がＹＥＳならば、以下のステップＳ１２０５の処理が実行される。この処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１５１】
即ち、グループ間通信部３０７を介して、自ノードのプライオリティが返される（ステップＳ１２０５）。なお、自グループトランスコード状況情報３１８も通知される。その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１５２】
前述のステップＳ１２０４の判定がＮＯならば、メイン選出情報応答が受信されたか否かが判定される（ステップＳ１２０６）。
ステップＳ１２０６の判定がＹＥＳならば、以下のステップＳ１２０７からＳ１２１３の処理が実行される。これらの処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１５３】
まず、グループ間通信部３０７を介して受信されたメイン選出情報応答から、送信元のノードのプライオリティと、送信元のノードが属するグループの自グループトランスコード状況情報３１８が取得され、グループ間トランスコード状況情報３１７に設定される（ステップＳ１２０７）。
【０１５４】
その後、全ノードから応答が有ったか否かが判定される（ステップＳ１２０８）。
ステップＳ１２０８の判定がＮＯならば、図７のステップＳ７０２の事象待機処理に戻る。
【０１５５】
ステップＳ１２０８の判定がＹＥＳならば、メイン選出情報応答タイマが終了させられる（ステップＳ１２０９）。
次に、メイン選出情報応答を送信したノードのプライオリティと自ノードのプライオリティが比較される（ステップＳ１２１０）。
【０１５６】
そして、自ノードのプライオリティが一番高いか否かが判定される（ステップＳ１２１１）。
ステップＳ１２１１の判定がＹＥＳならば、メイン装置の運用状態へ遷移し（ステップＳ１２１２）、図７〜図１３の動作フローチャートの処理を終了する。
【０１５７】
一方、ステップＳ１２１１の判定がＮＯならば、サブメイン装置の運用状態へ遷移し（現在の状態を維持し）（ステップＳ１２１３）、その後、その後、図７のステップＳ７０２の事象待機処理に戻る。
【０１５８】
前述したステップＳ１２０６の判定がＮＯならば、ステップＳ１２０３で開始されたメイン選出情報応答タイマがタイムアウトしたか否かが判定される（ステップＳ１２１４）。
【０１５９】
ステップＳ１２１４の判定がＹＥＳならば、前述のステップＳ１２０９からＳ１２１３と同様の処理が実行される。これらの処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１６０】
この場合には、全てのノードからメイン選出情報応答が得られていなくても、現在までに得られているノードのプライオリティを使って、メインマスタ装置又はサブメインマスタ装置への遷移が実行される（ステップＳ１２１４→Ｓ１２０９からＳ１２１３）。
【０１６１】
次に、前述した図１２のステップＳ１２１４の判定がＮＯとなった場合には、図１３の動作フローチャートになり、グループ間通信部３０７を介してグループ間ヘルスチェックが受信されたか否かが判定される（ステップＳ１３０１）。
【０１６２】
ステップＳ１３０１の判定がＹＥＳならば、以下のステップＳ１３０２からＳ１３０５の一連の処理が実行される。この処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１６３】
まず、メインマスタ装置のプライオリティと自ノードのプライオリティとが比較される（ステップＳ１３０２）。
そして、自ノードの方がプライオリティが高いか否かが判定される（ステップＳ１３０３）。
【０１６４】
ステップＳ１３０３の判定がＹＥＳならば、メインマスタ装置の運用状態へ遷移される（ステップＳ１３０４）。その後、図７〜図１３の動作フローチャートの処理を終了する。
【０１６５】
ステップＳ１３０３の判定がＮＯならば、ヘルスチェック応答がメインマスタ装置に送信される（ステップＳ１３０５）。
その後、グループ間ヘルスチェックタイマがリセットされ（ステップＳ１３０６）、図７のステップＳ７０２の事象待機処理に戻る。
【０１６６】
前述のステップＳ１３０１の判定がＮＯならば、図７のステップＳ７０１で開始されたグループ間ヘルスチェックタイマがタイムアウトしたか否かが判定される（ステップＳ１３０７）。
【０１６７】
メインマスタ装置が故障してグループ間ヘルスチェックが受信されずステップＳ１３０７の判定がＹＥＳとなると、以下のステップＳ１３０８からＳ１３１４の一連の処理が実行される。これらの処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０１６８】
まず、自グループのＱｏＳ最大値（許容量）がデフォルト値のままであるか否かが判定される（ステップＳ１３０８）。
ステップＳ１３０８の判定がＹＥＳならば、ステップＳ１３１２に移行する。
【０１６９】
ステップＳ１３０８の判定がＮＯならば、ＱｏＳ最大値がデフォルト値に戻される（ステップＳ１３０９）。
次に、優先マルチキャストデータ及び透過設定マルチキャストデータ以外のマルチキャストデータのエントリが選択されて、トランスコード管理テーブル３１２から削除される（ステップＳ１３１０）。
【０１７０】
次に、自グループの狭帯域流入量がＱｏＳ最大値以内であるか否かが判定される（ステップＳ１３１１）。
ステップＳ１３１１の判定がＮＯならば、ステップＳ１３１０の処理に戻って、更にマルチキャストデータのエントリが削除される。
【０１７１】
ステップＳ１３１１の判定がＹＥＳになると、削除したマルチキャストデータについて、トランスコード要求によって他ノードへ停止指示が出される（ステップＳ１３１２）。
そして、メイン選出情報要求が各グループのマスタ装置へ送信される（ステップＳ１３１３）。
その後、グループ間ヘルスチェックタイマがリセットされ（ステップＳ１３０６）、図７のステップＳ７０２の事象待機処理に戻る。
【０１７２】
図１４から図１８は、スレーブ装置（ノード）として動作するオートトランスコーダ１０１の制御動作を示す動作フローチャートである。
【０１７３】
まず、ヘルスチェック受信タイマが開始される（ステップＳ１４０１）。このタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。
次に、新たな情報受信の事象が発生したか否かの待ち状態となる（ステップＳ１４０２）。
【０１７４】
続いて、ステップＳ１４０３からＳ１４０９の処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
まず、ヘルスチェックが受信されたか否かが判定される（ステップＳ１４０３）。
【０１７５】
ステップＳ１４０３の判定がＹＥＳとなると、ヘルスチェック受信タイマが終了させられる（ステップＳ１４０４）。
次に、受信されたパケットに含まれる自グループトランスコード状況情報３１８によって、自装置内の自グループトランスコード状況情報３１８が更新される（ステップＳ１４０５）
次に、更新された自グループトランスコード状況情報３１８と、グループ共通定義ファイル３１０が参照されることにより、自ノードと新たに起動したノードのプライオリティが比較される（ステップＳ１４０６）。
【０１７６】
そして、自ノードのプライオリティが最高であるか否かが判定される（ステップＳ１４０７）。
ステップＳ１４０７の判定がＹＥＳならば、マスタ装置の運用状態へ遷移される（ステップＳ１４０８）。図１４の動作フローチャートの処理が終了する。
【０１７７】
一方、ステップＳ１４０７の判定がＮＯならば、ヘルスチェック応答が送信される（ステップＳ１４０９）。このとき、自ノードの自グループトランスコード状況情報３１８が通知される。
【０１７８】
その後、現在のスレーブ装置の運用状態が維持され、ステップＳ１４０１の処理に戻る。
前述したステップＳ１４０３の判定がＮＯの場合には、図１５の動作フローチャートに移り、ヘルスチェック受信タイマがタイムアウトしたか否かが判定される（ステップＳ１５０１）。
【０１７９】
ステップＳ１５０１の判定がＹＥＳならば、以下のステップＳ１５０２からＳ１５０５の処理が実行される。これらの処理は、図３のグループ内情報管理部３０４の一部の機能を実現する。
【０１８０】
まず、自グループトランスコード状況情報３１８とグループ共通定義ファイル３１０が参照されて、自ノードのプライオリティと起動中のノードのプライオリティが比較される（ステップＳ１５０２）。
【０１８１】
この結果、自ノードのプライオリティが最高であるか否かが判定される（ステップＳ１５０３）。
ステップＳ１５０３の判定がＹＥＳならば、マスタ装置の運用状態に遷移される（ステップＳ１５０４）。
【０１８２】
ステップＳ１５０３の判定がＮＯならば、スレーブ装置の運用状態維持される（ステップＳ１５０５）。その後、その後、図１４のステップＳ１４０１の処理に戻る。
前述したステップＳ１５０１の判定がＮＯの場合には、図１６の動作フローチャートに移り、トランスコード設定要求が受信されたか否かが判定される（ステップＳ１６０１）。
【０１８３】
ステップＳ１６０１の判定がＹＥＳならば、以下のステップＳ１６０２とＳ１６０３の処理が実行される。これらの処理は、図３のトランスコード制御部３０２の一部の機能を実現する。
【０１８４】
まず、トランスコード設定要求に基づき、ＭＣデータ受信管理部３０１のフィルタ機能に対して、遮断・透過などの設定が行われる。また、自グループトランスコード状況情報３１８が更新される（ステップＳ１６０２）。
【０１８５】
次に、トランスコード設定要求によって指定されたトランスコード部３０３に対して、ＭＰＥＧ２からＭＰＥＧ４へのトランスコードの実行が指示される（ステップＳ１６０３）。その後、図１４のステップＳ１４０２の事象待機処理に戻る。
【０１８６】
次に、前述したステップＳ１６０１の判定がＮＯとなった場合には、図１７の動作フローチャートになり、図１４のステップＳ１４０１で開始されたＭＣデータ受信チェックタイマがタイムアウトしたか否かが判定される（ステップＳ１７０１）。
【０１８７】
ステップＳ１７０１の判定がＹＥＳならば、以下のステップＳ１７０２からＳ１７１１及び図１８のステップＳ１８０１からＳ１８０８の一連の処理が実行される。この処理は、図３のＭＣデータ受信管理部３０１、トランスコード制御部３０２、グループ内情報管理部３０４、透過・破棄ＭＣ情報管理部３０８の一部の機能を実現する。
【０１８８】
まず、図６のステップＳ６０２で更新されているメモリ上の受信キューがポーリングされる（ステップＳ１７０２）。
次に、その受信キューにパケットが蓄積されているか否かが判定される（ステップＳ１７０３）。
【０１８９】
ステップＳ１７０３の判定がＮＯならば、図１４のステップＳ１４０１の処理に戻る。
ステップＳ１７０３の判定がＹＥＳならば、受信キューからパケットが取り込まれる（ステップＳ１７０４）。
【０１９０】
次に、図３の優先（緊急）テーブル３１４に、優先マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１７０５）。優先（緊急）テーブル３１４のデータ構成例は図２６に示される。このテーブル内の「PrMCAdd」フィールドがチェックされる。
【０１９１】
ステップＳ１７０５の判定がＮＯなら、ステップＳ１７０８の処理に移る。
ステップＳ１７０５の判定がＹＥＳならば、優先ＭＣアドレスは自グループ管理テーブル（図２５参照）にエントリされているか否かが判定される（ステップＳ１７０６）。
【０１９２】
ステップＳ１７０６の判定がＮＯならば、ステップＳ１７０８の処理に移る。
ステップＳ１７０６の判定がＹＥＳならば、自グループ管理テーブル設定がそのまま保持される（ステップＳ１７０７）。
【０１９３】
ステップＳ１７０５、Ｓ１７０６の判定がＮＯの場合又はステップＳ１７０７の処理の後、図３の遮断（破棄）テーブル３１６に、遮断マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１７０８）。遮断（破棄）テーブル３１６のデータ構成例は図２７に示される。このテーブル内の「BlockMCAdd」フィールドがチェックされる。
【０１９４】
ステップＳ１７０８の判定がＮＯなら、ステップＳ１７１０の処理に移る。
ステップＳ１７０８の判定がＹＥＳならば、遮断ＭＣのエントリが自グループ管理テーブル（図２５参照）に追加される。そして、自ノードのＭＣデータ受信管理部３０１のフィルタ機能に、遮断ＭＣのパケットを破棄する設定がなされる（ステップＳ１７１１）。その後、図１４のステップＳ１４０２の事象待機処理に戻る。
【０１９５】
ステップＳ１７０８の判定がＮＯならば、図３の透過テーブル３１５に、透過マルチキャストデータ（ＭＣ）のアドレスの設定が有るかか否かが判定されるか（ステップＳ１７１０）。透過テーブル３１５のデータ構成例は図２７に示される。このテーブル内の「ThroughMCAdd」フィールドがチェックされる。
【０１９６】
ステップＳ１７１０の判定がＹＥＳならば、透過ＭＣのエントリが自グループ管理テーブル（図２５参照）に追加される。そして、自ノードのＭＣデータ受信管理部３０１のフィルタ機能に、透過ＭＣのパケットを透過する設定がなされる（ステップＳ１７１１）。その後、図１４のステップＳ１４０２の事象待機処理に戻る。
【０１９７】
次に、ステップＳ１７１０の判定がＮＯとなった場合、即ち、受信されたマルチキャストデータ（ＭＣ）が優先ＭＣでも遮断ＭＣでも透過ＭＣでもない場合には、図１８の動作フローチャートに移る。
【０１９８】
まず、図１７のステップＳ１７０４で取得されたＭＣアドレスを検索キーにして、自グループ管理テーブル（図２５参照）が検索される（ステップＳ１８０１）。
この検索の結果、取得されたＭＣアドレスが自グループ管理テーブルにあるか否かが判定される（ステップＳ１７０２）。
【０１９９】
ステップＳ１１０２の判定がＮＯならば、マスタ装置に対して、トランスコード設定要求が送信される（ステップＳ１８０９）。その後、図１４のステップＳ１４０２の事象待機処理に戻る。
【０２００】
ステップＳ１１０２の判定がＹＥＳならば、自グループ管理テーブル内のトランスコード管理テーブル３１２のタイムスタンプフィールド「TimeStamp」が更新される（ステップＳ１８０３）。
【０２０１】
次に、自ノードにトランスコードが設定されているか否かが判定される（ステップＳ１８０４）。
ステップＳ１８０４の判定がＹＥＳならば、トランスコードの処理が継続されて、図１４のステップＳ１４０２の事象待機処理に戻る。
【０２０２】
ステップＳ１８０４の判定がＮＯならば、空きが検出されたトランスコード部３０３に、トランスコード開始指示のシグナルが出力される（ステップＳ１８０５）。
続いて、トランスコード部３０３からＭＣデータ受信管理部３０１へ指示が出され、そのトランスコード部３０３に対応するトランスコーダ接続ポートへのマルチキャストデータ（ＭＣ）の転送設定がなされる（ステップＳ１８０６）。
【０２０３】
更に、トランスコード部３０３からトランスコーダ１０２へ、トランスコード開始/停止コマンドが発行される（ステップＳ１８０７）。
そして、トランスコード部３０３が、トランスコーダ１０２から取得したコマンドレスポンス結果やトランスコード状態を、自グループ管理テーブル（図２５）に更新して反映させる（ステップＳ１８０８）。その後、図１４のステップＳ１４０２の事象待機処理に戻る。
【０２０４】
図１９から図２１は、メインマスタ装置（ノード）として動作するオートトランスコーダ１０１の制御動作を示す動作フローチャートである。
まず、グループ間ヘルスチェック送信タイマが開始される（ステップＳ１９０１）。
【０２０５】
次に、新たな情報受信の事象が発生したか否かの待ち状態となる（ステップＳ１９０２）。
続いて、ステップＳ１９０３からＳ１９０５の処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０２０６】
まず、グループ間ヘルスチェック送信タイマが満了したか否かが判定される（ステップＳ１９０３）。
【０２０７】
ステップＳ１９０３の判定がＹＥＳになると、各グループのマスタに対しグループ間ヘルスチェックが送信される（ステップＳ１９０４）。このとき、グループ間トランスコード状況情報３１７が送信される。グループ間トランスコード状況情報３１７は、図２９に示されるように、全グループの各自グループトランスコード状況情報３１８を合わせた情報である。
【０２０８】
次に、ヘルスチェック応答タイマが開始される（ステップＳ１９０５）。このタイマは、特には図示しないハードウェアタイマ又はソフトウェアタイマとして実現される。その後、図１９のステップＳ１９０２の事象待機処理に戻る。
【０２０９】
ステップＳ１９０３の判定がＮＯならば、図２０の動作フローチャートの処理に移り、ヘルスチェック応答が受信されたか否かが判定される（ステップＳ２００１）。
ステップＳ２００１の判定がＹＥＳならば、以下のステップＳ２００２からＳ２０１１の一連の処理が実行される。これらの処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０２１０】
まず、自ノードのプライオリティは最高であるか否かが判定される（ステップＳ２００２）。
次に、受信されたヘルスチェック応答の内容によって、グループ間トランスコード状況情報３１７が更新される（ステップＳ２００３）。
【０２１１】
次に、受信されたヘルスチェック応答の応答内容は、所定の閾値（％）を超える流入量であるか否かが判定される（ステップＳ２００４）。グループ毎の閾値は、図２９に例示されるグループ間トランスコード状況情報３１７中のカレントＱｏＳ閾値（流入量閾値）が用いられる。
【０２１２】
ステップＳ２００４の判定がＹＥＳならば、流入量が「閾値−調整レート」以下のグループ有るか否かが判定される（ステップＳ２００５）。
ステップＳ２００５の判定がＮＯならば、図１９のステップＳ１９０２の事象待機処理に戻る。
【０２１３】
ステップＳ２００５の判定がＹＥＳならば、一番流入量の少ないグループが抽出される（ステップＳ２００６）。
次に、抽出されたグループの閾値を下げる指示のヘルスチェックが生成される（ステップＳ２００７）。
【０２１４】
一方、ステップＳ２００４の判定がＮＯならば、閾値を下げる指示を含むヘルスチェックに対する応答があったか否かが判定される（ステップＳ２００８）。
ステップＳ２００８の判定がＮＯならば、ステップＳ２０１０が実行される。
【０２１５】
ステップＳ２００８の判定がＹＥＳならば、閾値を下げた分だけ、ひとつのグループ（Ａ）に閾値を上げる指示のヘルスチェックが生成される（ステップＳ２００９）。
ステップＳ２００７又はＳ２００９の処理の後、全マスタから応答が有ったか否かが判定される（ステップＳ２０１０）。
【０２１６】
ステップＳ２０１０の判定がＮＯならば、図１９のステップＳ１９０２の事象待機処理に戻る。
ステップＳ２０１０の判定がＹＥＳならば、ヘルスチェック応答タイマが終了させられ（ステップＳ２０１１）、その後、図１９のステップＳ１９０２の事象待機処理に戻る。
【０２１７】
前述したステップＳ２００１の判定がＮＯならば、図２１の動作フローチャートの処理に移り、図１９のステップＳ１９０５で開始されたヘルスチェック応答タイマがタイムアウトしたか否かが判定される（ステップＳ２１０１）。
【０２１８】
ステップＳ２１０１の判定がＹＥＳならば、以下のステップＳ２１０２からＳ２１１２の一連の処理が実行される。これらの処理は、図３のグループ間情報管理部３０６の一部の機能を実現する。
【０２１９】
まず、タイムアウトしたグループはＱｏＳ最大値を変更しているか否かが判定さえる（ステップＳ２１０２）。
ステップＳ２１０２の判定がＮＯならば、図１９のステップＳ１９０２の事象待機処理に戻る。
【０２２０】
ステップＳ２１０２の判定がＹＥＳならば、タイムアウトしたグループはＱｏＳ最大値を減らしているか否かが判定される（ステップＳ２１０３）。
ステップＳ２１０３の判定がＹＥＳならば、自グループのＱｏＳ最大値（許容量）がデフォルト値のままであるか否かが判定される（ステップＳ２１０４）。
【０２２１】
ステップＳ２１０４の判定がＹＥＳならば、ステップＳ２１０９に移行する。
ステップＳ２１０４の判定がＮＯならば、ＱｏＳ最大値がデフォルト値に戻される（ステップＳ２１０５）。
【０２２２】
次に、優先マルチキャストデータ及び透過設定マルチキャストデータ以外のマルチキャストデータのエントリが選択されて、トランスコード管理テーブル３１２から削除される（ステップＳ２１０６）。
【０２２３】
次に、自グループの狭帯域流入量がＱｏＳ最大値以内であるか否かが判定される（ステップＳ２１０７）。
ステップＳ２１０７の判定がＮＯならば、ステップＳ２１０６の処理に戻って、更にマルチキャストデータのエントリが削除される。
【０２２４】
ステップＳ２１０７の判定がＹＥＳになると、削除したマルチキャストデータについて、トランスコード要求によって自グループ内ノードへ停止指示が出される（ステップＳ２１０８）。
【０２２５】
その後、トランスコード応答タイマが開始され、図１９のステップＳ１９０２の事象待機処理に戻る。
前述したステップＳ２１０３の判定がＮＯの場合には、タイムアウトしたグループがＱｏＳ最大値を増やしていた分、多の減らしているグループのＱｏＳ最大値を増やす（デフォルト値に戻す）処理が実行される（ステップＳ２１１０）。
【０２２６】
次に、ＱｏＳ最大値を再設定したグループ間トランスコード状況情報３１７が送信される（ステップＳ２１１１）。
その後、ヘルスチェック応答タイマが開始され（ステップＳ２１１２）、図１９のステップＳ１９０２の事象待機処理に戻る。
【０２２７】
以上説明した実施形態により、オートトランスコーダの多段接続構成により、狭帯域ネットワークに流入する映像ストリーム等の大容量データが帯域を超えないように制御することが可能となる。
【０２２８】
また、指定の映像ストリーム等を、元のレートのまま狭帯域を通し、高品質の映像を提供することが可能となる。
更に、トランスコード状況と映像ストリーム等の狭帯域ネットワークへの流入量に関する情報が、各グループ内及び複数のグループ間で共有されることにより、グループ内及びグループ間の各オートトランスコーダが協同的に、狭帯域への流入制御を実施することが可能となる。
【０２２９】
更に、オートトランスコーダの冗長構成により、１システムがダウンしても予備のオートトランスコーダが状態を引き継いでトランスコードすることが可能となる。
また、モニタ映像を見た結果、鮮明な映像が必要になった場合に、トランスコードのレートを上げ優先して狭帯域ネットワークを通すような制御が可能となる。
【０２３０】
加えて、不必要な映像が狭帯域ネットワークを使用しないように制御することが可能となる。
【符号の説明】
【０２３１】
１０１ オートトランスコーダ
１０２ トランスコーダ
１０３ 広帯域側Ｌ３スイッチ
１０４ 狭帯域側Ｌ３スイッチ
１０５ カメラ
１０６ 広帯域ネットワーク
１０７ 狭帯域ネットワーク
１０８ Ｗｅｂ保守端末
２０１ スイッチボックス
３０１ ＭＣデータ受信管理部
３０２ トランスコード制御部
３０３ トランスコード部
３０４ グループ内情報管理部
３０５ グループ内通信部
３０６ グループ間情報管理部
３０７ グループ間通信部
３０８ 透過・破棄ＭＣ情報管理部
３０９ Ｗｅｂ画面制御部
３１０ グループ共通定義ファイル
３１１ 受信ＭＣデータ管理情報
３１２ トランスコード管理テーブル
３１３ グループ内管理情報
３１４ 優先（緊急）テーブル
３１５ 透過テーブル
３１６ 遮断（破棄）テーブル
３１７ グループ間トランスコード状況情報３１７
３１８ 自グループトランスコード状況情報
３１９ 自グループトラフィック流入情報
【特許請求の範囲】
【請求項１】
複数の大容量データを広帯域ネットワークから狭帯域ネットワークに配信する大容量データ配信システムであって、
前記大容量データのレート変換を行うレート変換装置を搭載し該レート変換装置を制御するレート変換制御装置を多段接続して前記広帯域ネットワークからの前記大容量データの流入を引き受けるグループを形成し、
前記レート変換制御装置が、
自レート変換制御装置で前記大容量データをレート変換できない場合に、同一の前記グループ内の他のレート変換制御装置で該大容量データをレート変換させるために、該大容量データを透過させる制御を行うトランスコード制御部と、
指定された大容量データを、前記グループ内の全レート変換制御装置でレート変換を行わずに透過させる制御を行う透過情報管理部と、
前記トランスコード制御部及び前記透過情報管理部の制御状態を、前記グループ内の他のレート変換制御装置との間で、自グループトランスコード状況情報として交換し設定するグループ内情報管理部と、
を含む、
ことを特徴とする狭帯域ネットワークの大容量データ配信システム。
【請求項２】
前記グループ内の各レート変換装置は、該グループから前記狭帯域ネットワークへ流入する大容量データの流入状態を示す自グループトラフィック流入情報を前記グループ内情報管理部を介して相互に交換することにより、該グループにおける前記狭帯域ネットワークへの前記大容量データの流入量が該グループに対して指定されている許容値を超えないように制御する、
ことを特徴とする請求項１に記載の狭帯域ネットワークの大容量データ配信システム。
【請求項３】
前記多段接続されたレート変換装置によって形成されるグループが、前記広帯域ネットワークと前記狭帯域ネットワークの間に複数形成され、
前記各グループの複数のレート変換制御装置のうちの各ひとつずつがマスタ装置として動作し、
前記レート変換制御装置は、自装置が前記マスタ装置として動作するときに、自装置が属するグループに対応する前記自グループトランスコード状況情報を、他の各グループで各マスタ装置として動作する各レート変換制御装置との間でグループ間トランスコード状況情報として交換することにより、該各グループ間で前記大容量データの流入量の許容値を増減調整するグループ間情報管理部を更に含む、
ことを特徴とする請求項１又は２に記載の狭帯域ネットワークの大容量データ配信システム。
【請求項４】
前記各グループにおいて多段接続されたレート変換制御装置のうちの所定のものを予備系装置とし、その他のレート変換制御装置を現用系装置とし、該現用系のレート変換制御装置が故障した場合に、該故障したレート変換制御装置のレート変換状況を前記予備系のレート変換制御装置が引き継ぐ制御を、前記グループ内情報管理部が実行する、
ことを特徴とする請求項１乃至３に記載の狭帯域ネットワークの大容量データ配信システム。
【請求項５】
前記予備系のレート変換制御装置を、前記多段接続されたレート変換制御装置群中の最下流に接続することにより、前記現用系のトランスコード装置が故障した時点で、前記レート変換されなくなった高レートのままの大容量データが前記狭帯域ネットワークへ流入することを、前記予備系のレート変換制御装置が防止する、
ことを特徴とする請求項４に記載の狭帯域ネットワークの大容量データ配信システム。
【請求項１】
複数の大容量データを広帯域ネットワークから狭帯域ネットワークに配信する大容量データ配信システムであって、
前記大容量データのレート変換を行うレート変換装置を搭載し該レート変換装置を制御するレート変換制御装置を多段接続して前記広帯域ネットワークからの前記大容量データの流入を引き受けるグループを形成し、
前記レート変換制御装置が、
自レート変換制御装置で前記大容量データをレート変換できない場合に、同一の前記グループ内の他のレート変換制御装置で該大容量データをレート変換させるために、該大容量データを透過させる制御を行うトランスコード制御部と、
指定された大容量データを、前記グループ内の全レート変換制御装置でレート変換を行わずに透過させる制御を行う透過情報管理部と、
前記トランスコード制御部及び前記透過情報管理部の制御状態を、前記グループ内の他のレート変換制御装置との間で、自グループトランスコード状況情報として交換し設定するグループ内情報管理部と、
を含む、
ことを特徴とする狭帯域ネットワークの大容量データ配信システム。
【請求項２】
前記グループ内の各レート変換装置は、該グループから前記狭帯域ネットワークへ流入する大容量データの流入状態を示す自グループトラフィック流入情報を前記グループ内情報管理部を介して相互に交換することにより、該グループにおける前記狭帯域ネットワークへの前記大容量データの流入量が該グループに対して指定されている許容値を超えないように制御する、
ことを特徴とする請求項１に記載の狭帯域ネットワークの大容量データ配信システム。
【請求項３】
前記多段接続されたレート変換装置によって形成されるグループが、前記広帯域ネットワークと前記狭帯域ネットワークの間に複数形成され、
前記各グループの複数のレート変換制御装置のうちの各ひとつずつがマスタ装置として動作し、
前記レート変換制御装置は、自装置が前記マスタ装置として動作するときに、自装置が属するグループに対応する前記自グループトランスコード状況情報を、他の各グループで各マスタ装置として動作する各レート変換制御装置との間でグループ間トランスコード状況情報として交換することにより、該各グループ間で前記大容量データの流入量の許容値を増減調整するグループ間情報管理部を更に含む、
ことを特徴とする請求項１又は２に記載の狭帯域ネットワークの大容量データ配信システム。
【請求項４】
前記各グループにおいて多段接続されたレート変換制御装置のうちの所定のものを予備系装置とし、その他のレート変換制御装置を現用系装置とし、該現用系のレート変換制御装置が故障した場合に、該故障したレート変換制御装置のレート変換状況を前記予備系のレート変換制御装置が引き継ぐ制御を、前記グループ内情報管理部が実行する、
ことを特徴とする請求項１乃至３に記載の狭帯域ネットワークの大容量データ配信システム。
【請求項５】
前記予備系のレート変換制御装置を、前記多段接続されたレート変換制御装置群中の最下流に接続することにより、前記現用系のトランスコード装置が故障した時点で、前記レート変換されなくなった高レートのままの大容量データが前記狭帯域ネットワークへ流入することを、前記予備系のレート変換制御装置が防止する、
ことを特徴とする請求項４に記載の狭帯域ネットワークの大容量データ配信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【公開番号】特開２０１１−１０９３３９（Ｐ２０１１−１０９３３９Ａ）
【公開日】平成２３年６月２日（２０１１．６．２）
【国際特許分類】
【出願番号】特願２００９−２６１２２０（Ｐ２００９−２６１２２０）
【出願日】平成２１年１１月１６日（２００９．１１．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年６月２日（２０１１．６．２）
【国際特許分類】
【出願日】平成２１年１１月１６日（２００９．１１．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]