JP7347776B2 - ノード管理装置、ノード管理方法及びプログラム - Google Patents

Description

本開示は、ノード管理装置、ノード管理方法及びプログラムに関する。

既存の放送局の多くは、放送信号のストリームを局内で伝送するための専用ネットワークを有している。放送信号は、例えば、映像、音声及び補助（ancillary）データといった放送素材を搬送する。専用ネットワークには、例えば、カメラ及びマイクロフォンといったキャプチャデバイス、コンテンツデータを蓄積するストレージサーバ、コンテンツを再生する再生デバイス、及び伝送される信号の形式を変換するゲートウェイデバイスといった、様々な装置が接続される。専用ネットワーク上での放送信号ストリームの伝送のための信号形式として、ＳＤＩ（Serial Digital Interface）がこれまで広く利用されている。

しかし、近年のＩＰ（Internet Protocol）技術の目覚ましい性能の向上の結果、放送事業者は、より汎用性の高いＩＰ技術を活用することにメリットを見出し、局内のネットワークをＩＰネットワークへ更新する取り組みを開始した。ＩＰベースのネットワークアーキテクチャを採用すれば、例えば、汎用のルータ及びスイッチといったネットワーク装置を用いて高速かつ大容量のネットワークを低コストで構築することが可能となる。

ＩＰ化が進展すれば、放送局システムのネットワークに多様な装置が接続されることが予期される。そうした多様な装置の間の相互運用性を確保するために、ＡＭＷＡ（Advanced Media Workflow Association）は、装置間のストリームの伝送を管理し及び制御するための制御インタフェース規格の集合であるＮＭＯＳ（Networked Media Open Specifications）規格の策定を進めている。例えば、ＮＭＯＳ ＩＳ－０４は、ネットワークリソースの発見及び登録（Discovery and Registration）のための制御インタフェース規格である（非特許文献１参照）。ＮＭＯＳ ＩＳ－０５は、デバイスの接続管理（Device Connection Management）のための制御インタフェース規格である（非特許文献２参照）。ＮＭＩ（Network Media Interface）及びＭｅｓｓａｇｅＰａｃｋ－ＲＰＣは、ストリーム伝送制御のための、ＮＭＯＳとは異なる制御インタフェース規格の例である。ネットワーク装置を製造する製造者が独自の制御インタフェースを開発することもある。

AMWA， "AMWA IS-04 NMOS Discovery and Registration Specification (Stable)"， ［online］， ［平成31年1月8日検索］， インターネット＜URL：https://amwa-tv.github.io/nmos-discovery-registration/＞ AMWA， "AMWA IS-05 NMOS Device Connection Management Specification"， ［online］， ［平成31年1月8日検索］， インターネット＜URL：https://amwa-tv.github.io/nmos-device-connection-management/＞

しかしながら、これまでになされてきたストリーム伝送制御用の制御インタフェースに関する提案は、放送信号を処理する多様なノードを制御する制御側の装置の実装を適切に考慮したものではなかった。例えば、放送局内に種類の異なる制御インタフェースをサポートする複数の放送信号処理ノードが存在する場合、種類の異なる制御インタフェースの全てを実装した制御装置が無ければ、そうした多様なノードを一元的に管理し又は制御することができない。また、ＮＭＯＳ ＩＳ－０５によれば、伝送制御のための制御メッセージは、制御端末と放送信号処理ノードとの間で直接的に交換される。しかし、放送局システム内には通常、複数の制御端末が存在するため、ＮＭＯＳ ＩＳ－０５のような分散的なやり方は、やはり多様なノードの一元的な管理又は制御には適さない。

上述した課題のうちの少なくとも１つに対処するために、本開示は、放送局内の多様な放送信号処理ノードの管理又は制御を効率化するための仕組みを提供することを目的とする。

ある観点によれば、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理装置が提供される。上記放送信号処理ノードを識別するノード識別情報に代えて、上記ノード管理装置を識別する代替識別情報が上記放送信号処理ノードの識別情報として外部装置へ通知される。上記ノード管理装置は、上記放送信号処理ノードを制御するための制御メッセージであって、上記代替識別情報を宛て先として有する当該制御メッセージが上記外部装置から受信された場合に、上記制御メッセージを、少なくとも宛て先を上記代替識別情報から上記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを上記放送信号処理ノードへ送信する制御部、を備える。

また別の観点によれば、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理方法が提供される。当該ノード管理方法は、上記放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置を識別する代替識別情報を上記放送信号処理ノードの識別情報として外部装置へ通知することと、上記放送信号処理ノードを制御するための制御メッセージであって、上記代替識別情報を宛て先として有する当該制御メッセージを上記外部装置から受信することと、上記制御メッセージを、少なくとも宛て先を上記代替識別情報から上記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを上記放送信号処理ノードへ送信することと、を含む。

また別の観点によれば、上記ノード管理装置の処理をプロセッサに実行させるコンピュータプログラムが提供されてもよい。上記コンピュータプログラムを記憶した非一時的なコンピュータ読取可能な記憶媒体が提供されてもよい。

本開示に係る技術によれば、放送局内の多様な放送信号処理ノードの管理又は制御を効率化することが可能となる。なお、本開示に係る技術により、当該効果の代わりに、又は当該効果とともに、他の効果が奏されてもよい。

本開示の実施形態に係る放送局システムの構成の一例を示す概略図である。 本開示の実施形態に係る放送局システムのＩＰドメインの論理的な構成の一例について説明するための説明図である。 ＨＴＴＰを用いて送信される既存のノード登録メッセージの一例について説明するための説明図である。 ＨＴＴＰを用いて送信される既存のセンダ登録メッセージの一例について説明するための説明図である。 ＨＴＴＰを用いて送信される既存のレシーバ登録メッセージの一例について説明するための説明図である。 ＨＴＴＰを用いて送信される既存のストリーム制御メッセージの一例について説明するための説明図である。 異なる種類の制御インタフェースをサポートする複数の放送信号処理ノードが存在する状況について説明するための第１の説明図である。 異なる種類の制御インタフェースをサポートする複数の放送信号処理ノードが存在する状況について説明するための第２の説明図である。 単一の種類の制御インタフェースをサポートする放送信号処理ノードしか存在しないものの、システム内に複数の制御端末が存在する状況について説明するための説明図である。 本開示の実施形態の基本的な原理について説明するための説明図である。 第１の実施形態に係るノード管理装置の構成の一例を示すブロック図である。 第１の実施形態に係るノード管理装置により管理される情報の構成の一例について説明するための説明図である。 ノード登録メッセージにおけるノード識別情報の置換について説明するための説明図である。 外部装置から放送信号処理ノードへ送信される制御メッセージにおける宛て先の置換について説明するための説明図である。 第１の実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。 第１の実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。 第１の実施形態における管理及び制御の一元化について説明するための説明図である。 第２の実施形態に係るノード管理装置の構成の一例を示すブロック図である。 第２の実施形態に係るノード管理装置により管理される情報の構成の一例について説明するための説明図である。 ノード登録メッセージにおけるノード識別情報の置換及びメッセージ形式の変換について説明するための説明図である。 外部装置から放送信号処理ノードへ送信される制御メッセージのメッセージ変換について説明するための説明図である。 第２の実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。 第２の実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。 第２の実施形態における管理及び制御の一元化について説明するための説明図である。 第３の実施形態に係るノード管理装置の構成の一例を示すブロック図である。 第３の実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。 第３の実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。 第３の実施形態における管理及び制御の一元化について説明するための説明図である。 第４の実施形態に係るノード管理装置の構成の一例を示すブロック図である。

以下、添付の図面を参照して本開示に係る技術の実施形態を詳細に説明する。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。

説明は、以下の順序で行われる。
１．概要
１－１．システム構成例
１－２．ＨＴＴＰベースの制御メッセージの例
１－３．課題の説明
１－４．基本的な原理
２．第１の実施形態
２－１．ノード管理装置の構成例
２－２．処理の流れ
２－３．利点
３．第２の実施形態
３－１．ノード管理装置の構成例
３－２．処理の流れ
３－３．利点
４．第３の実施形態
４－１．ノード管理装置の構成例
４－２．処理の流れ
４－３．利点
５．第４の実施形態
６．まとめ

＜＜１．概要＞＞
＜１－１．システム構成例＞
まず、図１を用いて、本開示のいくつかの実施形態が適用され得る放送局システムの概要について説明する。図１は、本開示の実施形態に係る放送局システム１の構成の一例を示す概略図である。図１を参照すると、放送局システム１は、１つ以上のネットワーク装置１２、カメラ１４、モニタ１６、ＩＰゲートウェイ２０ａ、ＩＰゲートウェイ２０ｂ、カメラ２２、マイクロフォン２４、データサーバ２６、統合プレイアウト（Integrated Playout）３２、モニタ３４、ＡＰＳ（Automatic Program control System）４０及び制御端末５０を含む。ネットワーク装置１２、カメラ１４、モニタ１６、ＩＰゲートウェイ２０ａ、ＩＰゲートウェイ２０ｂ、ＡＰＳ４０、及び制御端末５０は、ＩＰドメイン１０に属する。

（１）様々な装置の説明
ネットワーク装置１２は、ＩＰネットワークにおけるストリームの転送を担当する装置である。ネットワーク装置１２の各々は、例えばルータ、スイッチ、ブリッジ又はリピータなど、いかなる種類のネットワーク装置であってもよい。ネットワーク装置１２の各々は、低コストで導入可能な汎用品（ＣＯＴＳ（Commercial Off-The-Shelf）ともいう）であってもよい。図１には６つのネットワーク装置１２が示されているが、かかる例に限定されず、放送局システム１はいくつのネットワーク装置１２を含んでもよい。ＩＰドメイン１０は、単一のネットワークで構成されてもよく、又は複数のサブネットワークを含んでもよい。

カメラ１４は、放送素材を生成するキャプチャデバイスの一種である。例えば、カメラ１４は、何らかの対象を撮影して、映像データを生成する。カメラ１４は、内蔵されるマイクロフォンを通じて音声を取得して、音声データを生成してもよい。カメラ１４は、ＩＰドメイン１０に属し、映像データ及び音声データのデータストリームを一連のＩＰパケットへパケット化してＩＰネットワークへ送信することができる。

モニタ１６は、放送素材を受信してコンテンツを再生する再生デバイスの一種である。例えば、モニタ１６は、映像データを受信して映像を再生する。モニタ１６は、音声データを受信して音声を再生してもよい。モニタ１６は、追加的に伝送される補助データを受信して、補助データを処理（例えば、字幕を再生）してもよい。モニタ１６は、コンテンツを編集するための編集機能をユーザへ提供してもよい。モニタ１６は、ＩＰドメイン１０へ属し、ＩＰネットワーク上で転送されて来る一連のＩＰパケットを受信することができる。

ＩＰゲートウェイ２０ａは、ＩＰドメイン１０と他の信号ドメインとの境界に位置するゲートウェイデバイスである。ＩＰゲートウェイ２０ａは、１つ又は複数のネットワーク装置１２へ接続する。図１の例において、ＩＰゲートウェイ２０ａには、カメラ２２、マイクロフォン２４及びデータサーバ２６がさらに接続されている。例えば、ＩＰゲートウェイ２０ａは、映像データを搬送するＳＤＩ信号をカメラ２２から受信し得る。また、ＩＰゲートウェイ２０ａは、音声データを搬送するＳＤＩ信号をマイクロフォン２４から受信し得る。また、ＩＰゲートウェイ２０ａは、映像データ、音声データ及び補助データのうちの１つ以上を搬送するＳＤＩ信号をデータサーバ２６から受信し得る。なお、ＩＰドメイン１０の外部で伝送される信号の信号形式は、例えばＳＤ－ＳＤＩ、ＨＤ－ＳＤＩ、３Ｇ－ＳＤＩ、６Ｇ－ＳＤＩ若しくは１２Ｇ－ＳＤＩといったＳＤＩの任意の派生であってもよく、又は、ＳＤＩ以外の信号形式であってもよい。ＩＰゲートウェイ２０ａは、上述したようにカメラ２２、マイクロフォン２４及びデータサーバ２６から受信される放送素材を搬送する信号を、必要に応じて多重化し又は逆多重化した後、一連のＩＰパケットへパケット化してＩＰネットワークへ送信することができる。

ＩＰゲートウェイ２０ｂもまた、ＩＰドメイン１０と他の信号ドメインとの境界に位置するゲートウェイデバイスである。ＩＰゲートウェイ２０ｂは、１つ又は複数のネットワーク装置１２へ接続する。図１の例では、ＩＰゲートウェイ２０ｂには、統合プレイアウト３２及びモニタ３４がさらに接続されている。例えば、ＩＰゲートウェイ２０ｂは、ＩＰネットワーク上で転送されて来るＩＰパケットを受信し、それらＩＰパケットをＳＤＩ信号（又は他の信号形式の信号）へ変換して、統合プレイアウト３２及びモニタ３４の一方又は双方へ送信することができる。なお、当然ながら、ＩＰゲートウェイ２０ａがＩＰゲートウェイ２０ｂと同様にＩＰパケットをＳＤＩ信号へ変換する機能を有していてもよい。また、ＩＰゲートウェイ２０ｂがＩＰゲートウェイ２０ａと同様にＳＤＩ信号をＩＰパケットへ変換する機能を有していてもよい。

ＡＰＳ４０は、予め決定されるスケジュールに従って、テレビジョン番組の放送を進行させるシステムである。例えば、ＡＰＳ４０は、ＩＰネットワークへ制御メッセージを送信して、所定の時刻に所与の送信元（例えば、カメラ及びマイクロフォン、又はデータサーバ）から出力されるデータストリームを統合プレイアウト３２へ伝送させる。データストリームを受信した統合プレイアウト３２は、放送局の回線を通じてアンテナへテレビジョン番組の放送信号を送出する。データストリームは、例えばモニタ１６又はモニタ３４にも配信され、放送局内でも放送コンテンツが再生され得る。

制御端末５０は、放送局システム１に含まれるノードの管理及び制御に関連するユーザインタフェースをユーザへ提供する端末装置である。制御端末５０は、放送局システム１に専用のユーザ端末であってもよく、又はＰＣ（Personal Computer）若しくはスマートフォンといった汎用的な端末であってもよい。制御端末５０は、例えば、放送局内のネットワーク上でのストリームの送信又は受信に関与するノードに関連する情報のうちユーザにより設定可能な情報を、ユーザインタフェースを介して取得する。そして、制御端末５０は、取得した情報をシステム内のデータベースへ登録する。また、制御端末５０は、例えば、ユーザインタフェースを介して所与のノード間のストリームの伝送を求めるリクエストを受け付ける。

本明細書において、放送信号を何らかの形で処理するノードを、放送信号処理ノードという。上述したネットワーク装置１２、カメラ１４、モニタ１６、ＩＰゲートウェイ２０ａ、ＩＰゲートウェイ２０ｂ、カメラ２２、マイクロフォン２４、データサーバ２６、統合プレイアウト３２、モニタ３４及びＡＰＳ４０は、放送信号処理ノードの例である。放送信号の処理とは、例えば、放送信号を送信し、転送し、受信し、符号化し、復号し、キャプチャし、再生し又は変換することを含む。

（２）ＩＰマルチキャスト
放送局システム１のＩＰドメイン１０内の放送信号ストリームの伝送は、典型的には、マルチキャストで行われる。マルチキャストされるパケットの送信元ＩＰアドレスは送信ノードのＩＰアドレスであり、宛て先ＩＰアドレスは特定のアドレス範囲に属するマルチキャストアドレスである。個々のマルチキャストアドレスを宛て先とするマルチキャストパケットを受信するノードの集合をマルチキャストグループといい、マルチキャストアドレスをグループアドレスともいう。あるストリームを受信することを意図する受信ノードは、そのストリームに対応するマルチキャストグループへの加入（join）を通知するメッセージ（例えば、ＩＧＭＰ（Internet Group Management Protocol） ＪＯＩＮ）を近傍のルータへ送信する。すると、ルータ間でマルチキャストツリーを更新するためのメッセージ交換が行われ、特定の送信ノードから送信されるストリームがＩＰネットワークを介して受信ノードへ配信されるようになる。受信ノードは、マルチキャストストリームの受信を終了する際には、マルチキャストグループからの離脱（leave）を通知するメッセージを近傍のルータへ送信する。なお、上述した例に限定されず、本開示に係る技術は、ストリームがユニキャストで伝送されるケースにも適用可能である。

（３）エッセンスとストリーム
上述したように、テレビジョン番組のコンテンツは、概して、映像データ、音声データ及び補助データという３種類の放送素材のデータから構成される。本明細書では、放送素材の種類を区別してこれらコンテンツの構成要素へ言及するために、「エッセンス」との語を用いる。言い換えると、エッセンスは、データとして表現された放送素材である。エッセンスをＩＰネットワーク上で伝送しようとする場合、エッセンスは、あるＩＰベースのプロトコルに従って、デジタル信号へ変換されパケット化される。エッセンスを搬送する一連のＩＰパケットには、ストリーム単位で共通するポート番号が付与される。即ち、ストリームは、ＩＰアドレス及びポート番号が共通するＩＰパケットのシーケンスであり得る。

（４）プロトコルごとのストリームタイプ
ストリーム伝送のためのプロトコルとしてＳＭＰＴＥ ＳＴ２０２２－６が利用される場合、このプロトコルはＳＤＩ信号をそのままＩＰパケットへマッピングすることから、単一のストリームに異なる種類のエッセンスが混在する。ＳＭＰＴＥ ＳＴ２１１０シリーズが利用される場合、異なる種類のエッセンスは異なるストリームにより搬送され、したがって単一のストリームは単一の種類のエッセンスのみを含む。ＡＲＩＢ ＳＴＤ－Ｂ７３が利用される場合、単一のストリームに異なる種類のエッセンスが混在するが、ＳＤＩイメージとは異なりブランキング期間は含まれない。いずれのプロトコルにおいても、パケットは、アプリケーションレイヤではＲＴＰ（Real-time Transport Protocol）、トランスポートレイヤではＵＤＰ（User Datagram Protocol）に従って伝送される。

（５）ＩＰドメインの論理的構成例
図２は、図１に示した放送局システム１のＩＰドメイン１０の論理的な構成の一例を示している（簡明さのために、ここではＡＰＳ４０及び制御端末５０は省略されている）。図２を参照すると、カメラ１４に相当する第１ノードは、センダ（sender）６０ａを含む。「センダ」とは、ストリームを送信する能力を有する機能エンティティである。ＩＰゲートウェイ２０ａに相当する第２ノードは、センダ６０ｂ、６０ｃ及び６０ｄを含む。センダ６０ｂ、６０ｃ及び６０ｄは、ＩＰゲートウェイ２０ａにより収容される個々のストリームの送信元の装置に相当し得る。モニタ１６に相当する第３ノードは、レシーバ７０ａを含む。「レシーバ」とは、ストリームを受信する能力を有する機能エンティティである。ＩＰゲートウェイ２０ｂに相当する第４ノードは、レシーバ７０ｂ及び７０ｃを含む。レシーバ７０ｂ及び７０ｃは、ＩＰゲートウェイ２０ｂにより収容される個々のストリームの受信先の装置に相当し得る。

上の説明から理解されるように、１つのノード（「カード」と呼ばれてもよい）は、１つの物理エンティティを表現する。図１の例に限定されず、１つのノードは、機能エンティティとして、任意の数のセンダ及び／又は任意の数のレシーバを含んでよい。また、１つのノード内で複数の機能エンティティを包含する論理的な単位（例えば、図中の破線枠参照）が定義されてもよい（例えば、１つのＩＰゲートウェイに収容される１つのデバイスが複数のストリームを送信し又は受信するケース）。例えば、ＡＭＷＡにより検討されているＮＭＯＳは、こうした論理的なシステムモデルを前提として、ＩＰドメインでのストリームの伝送を管理し及び制御するための、ＨＴＴＰベースのアプリケーションプロトコルインタフェース（ＡＰＩ）の仕様を規定している。

なお、本明細書において、センダ６０ａ、６０ｂ、６０ｃ及び６０ｄを互いに区別する必要が無い場合には、符号の末尾のアルファベットを省略することによりこれらをセンダ６０と総称する。同様に、レシーバ７０ａ、７０ｂ及び７０ｃを互いに区別する必要が無い場合には、符号の末尾のアルファベットを省略することによりこれらをレシーバ７０と総称する。

＜１－２．ＨＴＴＰベースの制御メッセージの例＞
次に、図３～図６を用いて、ＩＰドメインでのストリームの伝送を管理し及び制御するための、既存のＨＴＴＰベースのＡＰＩの制御メッセージのいくつかの例について説明する。

（１）ノード登録メッセージ
図３は、ＨＴＴＰを用いて送信される既存のノード登録メッセージの一例について説明するための説明図である。図３に示したノード登録メッセージ５１は、リクエストライン５２、ヘッダ５３及びメッセージボディ５４を含む。

リクエストライン５２は、ホスト部分５６及びパス部分５７を含むＵＲＬ（Uniform Resource Locator）を含む。ホスト部分５６は、ノード登録メッセージ５１の宛て先を識別する。したがって、ホスト部分５６は、「宛て先部分」として言及されてもよい。図３の例では、ノード登録メッセージ５１の宛て先はホスト部分５６においてＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」で識別されている。他の例では、メッセージの宛て先はホスト名で識別されてもよい。パス部分５７は、ノード登録メッセージ５１が準拠するＡＰＩの規格及びそのバージョンを識別する。図３の例では、ノード登録メッセージ５１のパス部分５７から、ノード登録メッセージ５１がＮＭＯＳ ＩＳ－０４のバージョン１．２に準拠したリソース登録メッセージの一種であることが理解される。なお、図３には示していないものの、リクエストライン５２は、ＨＴＴＰメソッド名（例えば、ＰＯＳＴ）及びＨＴＴＰバージョン番号といった他の情報をも含み得る。

メッセージボディ５４は、ノード登録メッセージ５１の宛て先であるノードが実行すべき制御内容を記述するデータを含む。一例として、制御内容は、ＪＳＯＮ（JavaScript Object Notation）形式で記述されてもよい。図３の例において、ノード登録メッセージ５１のメッセージボディ５４は、登録されるべき放送信号処理ノードを一意に識別するノードＩＤ、及び当該放送信号処理ノードのＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｙ」を含む。限定ではないものの、ノードＩＤは、例えばＵＵＩＤ（Universally Unique Identifier）であってもよい。一例として、ＮＭＯＳ ＩＳ－０４によれば、ノード登録メッセージ５１を受信したＮＭＯＳ登録サービスは、メッセージボディ５４に記述されたノードＩＤに関連付けて、当該ノードＩＤにより識別される放送信号処理ノードのＩＰアドレスとして、同じくメッセージボディ５４に記述されたＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｙ」をデータベースに登録する。

（２）センダ登録メッセージ
図４は、ＨＴＴＰを用いて送信される既存のセンダ登録メッセージの一例について説明するための説明図である。図４に示したセンダ登録メッセージ６１は、リクエストライン６２、ヘッダ６３及びメッセージボディ６４を含む。

リクエストライン６２は、ホスト部分６６及びパス部分６７を含むＵＲＬを含む。ホスト部分６６は、センダ登録メッセージ６１の宛て先を識別する。したがって、ホスト部分６６は、「宛て先部分」として言及されてもよい。図４の例では、センダ登録メッセージ６１の宛て先はホスト部分６６においてＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」で識別されている。他の例では、メッセージの宛て先はホスト名で識別されてもよい。パス部分６７は、図３のノード登録メッセージ５１のパス部分５７と同様に、センダ登録メッセージ６１が準拠するＡＰＩの規格及びそのバージョンを識別する。図３の例と同様に、リクエストライン６２は、ＨＴＴＰメソッド名及びＨＴＴＰバージョン番号といった他の情報をも含み得る。

メッセージボディ６４は、センダ登録メッセージ６１の宛て先であるノードが実行すべき制御内容を記述するデータを含む。図４の例において、センダ登録メッセージ６１のメッセージボディ６４は、登録されるべきセンダを一意に識別するセンダＩＤ、及び当該センダが属するエンティティ（例えば、ノード又はデバイス）を識別する親ＩＤを含む。限定ではないものの、センダＩＤもまた、例えばＵＵＩＤであってよい。一例として、ＮＭＯＳ ＩＳ－０４によれば、センダ登録メッセージ６１を受信したＮＭＯＳ登録サービスは、メッセージボディ６４に記述されたセンダＩＤを、同じくメッセージボディ６４に記述された親ＩＤ（図４の例では、ノードＩＤ）に関連付けてデータベースに登録する。

（３）レシーバ登録メッセージ
図５は、ＨＴＴＰを用いて送信される既存のレシーバ登録メッセージの一例について説明するための説明図である。図５に示したレシーバ登録メッセージ７１は、リクエストライン７２、ヘッダ７３及びメッセージボディ７４を含む。

リクエストライン７２は、ホスト部分７６及びパス部分７７を含むＵＲＬを含む。ホスト部分７６は、レシーバ登録メッセージ７１の宛て先を識別する。したがって、ホスト部分７６は、「宛て先部分」として言及されてもよい。図５の例では、レシーバ登録メッセージ７１の宛て先はホスト部分７６においてＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」で識別されている。他の例では、メッセージの宛て先はホスト名で識別されてもよい。パス部分７７は、図３のノード登録メッセージ５１のパス部分５７と同様に、レシーバ登録メッセージ７１が準拠するＡＰＩの規格及びそのバージョンを識別する。図３の例と同様に、リクエストライン７２は、ＨＴＴＰメソッド名及びＨＴＴＰバージョン番号といった他の情報をも含み得る。

メッセージボディ７４は、レシーバ登録メッセージ７１の宛て先であるノードが実行すべき制御内容を記述するデータを含む。図５の例において、レシーバ登録メッセージ７１のメッセージボディ７４は、登録されるべきレシーバを一意に識別するレシーバＩＤ、及び当該レシーバが属するエンティティ（例えば、ノード又はデバイス）を識別する親ＩＤを含む。限定ではないものの、レシーバＩＤもまた、例えばＵＵＩＤであってよい。一例として、ＮＭＯＳ ＩＳ－０４によれば、レシーバ登録メッセージ７１を受信したＮＭＯＳ登録サービスは、メッセージボディ７４に記述されたレシーバＩＤを、同じくメッセージボディ７４に記述された親ＩＤ（図５の例では、ノードＩＤ）に関連付けてデータベースに登録する。

（４）ストリーム制御メッセージ
図６は、ＨＴＴＰを用いて送信される既存のストリーム制御メッセージの一例について説明するための説明図である。図６に示したストリーム制御メッセージ８１は、リクエストライン８２、ヘッダ８３及びメッセージボディ８４を含む。

リクエストライン８２は、ホスト部分８６及びパス部分８７を含むＵＲＬを含む。ホスト部分８６は、ストリーム制御メッセージ８１の宛て先を識別する。したがって、ホスト部分８６は、「宛て先部分」として言及されてもよい。図６の例では、ストリーム制御メッセージ８１の宛て先はホスト部分８６においてＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｙ」で識別されている。他の例では、メッセージの宛て先はホスト名で識別されてもよい。パス部分８７は、ストリーム制御メッセージ８１が準拠するＡＰＩの規格及びそのバージョンを識別する。図６の例では、ストリーム制御メッセージ８１のパス部分８７から、ストリーム制御メッセージ８１がＮＭＯＳ ＩＳ－０５のバージョン１．０に準拠した制御メッセージの一種であることが理解される。リクエストライン８２は、ＨＴＴＰメソッド名（例えば、ＰＡＴＣＨ）及びＨＴＴＰバージョン番号といった他の情報をも含み得る。

メッセージボディ８４は、ストリーム制御メッセージ８１の宛て先であるノードが実行すべき制御内容を記述するデータを含む。図６の例において、ストリーム制御メッセージ８１のメッセージボディ８４は、制御対象のストリームの伝送に関与するセンダを識別するセンダＩＤ、並びに当該ストリームの伝送のために使用されるべきマルチキャストＩＤ及びポート番号を含む。一例として、ストリーム制御メッセージ８１を受信した放送信号処理ノードは、メッセージボディ８４に記述された制御内容に従って、自身に属するセンダ（メッセージボディ８４に記述されたセンダＩＤにより識別されるセンダ）によるストリームの伝送を設定し、又は開始する。

＜１－３．課題の説明＞
将来的にＩＰ化が進展すると、放送局システムのネットワークに多様なノードが接続されることが予期される。その場合に、多様なノードを一元的に管理し又は制御する仕組みが無ければ、システムの計画的な運用、ネットワークリソースの効率的な利用、又はセキュリティリスクの最小化といったタスクの遂行が阻害されかねない。しかし、多様なノードの一元的な管理又は制御を困難にするいくつかのシナリオが考えられる。

（１）異なる種類の制御インタフェースの存在
図７及び図８は、異なる種類の制御インタフェースをサポートする複数の放送信号処理ノードが存在する状況について説明するための説明図である。これら図には、ＩＰネットワークを介して相互に接続された４つの放送信号処理ノード３０ａ、３０ｂ、３０ｃ及び３０ｄが示されている。放送信号処理ノード３０ａ及び３０ｂは、第１のタイプ（タイプＡ）の制御インタフェースをサポートする。放送信号処理ノード３０ｃは、第２のタイプ（タイプＢ）の制御インタフェースをサポートする。放送信号処理ノード３０ｄは、第３のタイプ（タイプＣ）の制御インタフェースをサポートする。こうした状況において、放送信号処理ノード３０ａのセンダ及び放送信号処理ノード３０ｄのレシーバが共通的なストリーム伝送プロトコル（例えば、ＳＭＰＴＥ ＳＴ２０２２－６、ＳＭＰＴＥ ＳＴ２１１０又はＡＲＩＢ ＳＴＤ－Ｂ７３）をサポートしていれば、それらセンダ及びレシーバの間で当該ストリーム伝送プロトコルに従ってストリームを伝送することが可能である（例えば、図７のストリームＳＴ１）。同様に、放送信号処理ノード３０ｃのセンダ及び放送信号処理ノード３０ｂのレシーバが共通的なストリーム伝送プロトコルをサポートしていれば、それらセンダ及びレシーバの間で当該ストリーム伝送プロトコルに従ってストリームを伝送することが可能である（例えば、図７のストリームＳＴ２）。

しかし、例えばストリームＳＴ１の伝送をセットアップするためには、システム内に第１のタイプの制御インタフェースを通じて放送信号処理ノード３０ａへ制御メッセージを送信する機能と、第３のタイプの制御インタフェースを通じて放送信号処理ノード３０ｄへ制御メッセージを送信する機能とが必要とされる。同様に、例えばストリームＳＴ２の伝送をセットアップするためには、システム内に第２のタイプの制御インタフェースを通じて放送信号処理ノード３０ｃへ制御メッセージを送信する機能と、第１のタイプの制御インタフェースを通じて放送信号処理ノード３０ｂへ制御メッセージを送信する機能とが必要とされる。仮にそれぞれのタイプの制御インタフェースのために別個の制御端末が導入されるとすると、図８に例示したように、システム内に、第１のタイプの制御インタフェースをサポートする制御端末５０ａ、第２のタイプの制御インタフェースをサポートする制御端末５０ｂ、及び第３のタイプの制御インタフェースをサポートする制御端末５０ｃが存在することになる。このシナリオでは、放送信号処理ノード３０ａ、３０ｂ、３０ｃ及び３０ｄの管理及び制御がばらばらとなるばかりか、ノードの追加及び制御端末の増加に対する拡張可能性も損なわれる。

（２）分散的なストリーム制御
図９は、単一の種類の制御インタフェースをサポートする放送信号処理ノードしか存在しないものの、システム内に複数の制御端末が存在する状況について説明するための説明図である。図９には、ＩＰネットワークを介して相互に接続された４つの放送信号処理ノード３０ａ、３０ｂ、３０ｅ及び３０ｆが示されている。放送信号処理ノード３０ａ、３０ｂ、３０ｅ及び３０ｆは、共通して第１のタイプの制御インタフェースをサポートする。図９には、３つの制御端末５０ａがさらに示されている。これら制御端末５０ａもまた、第１のタイプの制御インタフェースをサポートする。ここで、第１のタイプの制御インタフェースは、ＮＭＯＳ ＩＳ－０５のように、制御端末と放送信号処理ノードとの間で直接的に制御メッセージを交換することを規定しているものとする。このシナリオでは、３つの制御端末５０ａからの制御は分散的に行われるに過ぎず、複数の制御端末をまたいでストリーム制御に関与する装置は存在しない。これでは、やはりシステム全体を考慮することを要する上で例示したようなタスクの遂行は容易ではない。

＜１－４．基本的な原理＞
本開示に係る技術は、上述した課題のうちの少なくとも１つに対処するために、放送信号処理ノードを一元的に管理するためのノード管理機能を、放送局システム１に導入する。本明細書では、当該ノード管理機能が実装される装置をノード管理装置という。ノード管理装置は、例えば、ＩＰコントローラ又はＩＰマネージャなどと呼ばれてもよい。図１０には、一例としてのノード管理装置１００が示されている。ノード管理装置１００は、放送信号処理ノードとは別個の装置であってもよく、又はいずれかの放送信号処理ノードと物理的に同一の装置であってもよい。

典型的には、ノード管理装置１００は、放送局内のネットワーク上でのストリームの送信又は受信に関与する１つ以上の放送信号処理ノードを管理する。これら放送信号処理ノードは、ＩＰドメインにおけるストリームのいわゆるエンドポイントに位置するノードであり、図２のシステムモデルの例におけるセンダ又はレシーバを有する。ストリームを単に転送するネットワーク装置１２は、ノード管理装置１００による管理の対象外であってよい。

さらに、図１０に示したように、ノード管理装置１００は、少なくとも１つの外部装置と通信可能である。図１０では、外部装置の例として制御端末５０が示されているものの、外部装置は、かかる例に限定されず、他のいかなる装置（例えば、上述したＡＰＳ４０）であってもよい。ノード管理装置１００及び外部装置５０は、共通的な制御ＡＰＩをサポートする。典型的には、そのＡＰＩは、制御メッセージの宛て先部分で制御対象ノードを識別することを要するＡＰＩである。次節より詳しく説明するように、ノード管理装置１００は、管理下の放送信号処理ノードのセンダ及びレシーバの実際のロケーションに関わらず、外部装置５０に対して、それらセンダ及びレシーバが単一の装置（典型的には、ノード管理装置１００自身）に属しているかのように見せる。それにより、外部装置５０は、単一の装置との間の制御インタフェースのみをサポートして、当該単一の装置へ向けて制御メッセージを送信するようになる。

＜＜２．第１の実施形態＞＞
＜２－１．ノード管理装置の構成例＞
図１１は、第１の実施形態に係るノード管理装置１００の構成の一例を示すブロック図である。図１１を参照すると、ノード管理装置１００は、処理部１１０、記憶部１２０及び通信インタフェース１５０を備える。

（１）処理部
処理部１１０は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）又はマイクロコントローラといった１つ以上のプロセッサを含む。処理部１１０は、記憶部１２０により記憶されるコンピュータプログラムを実行することにより、ノード管理装置１００の機能性を実現する。本実施形態において、処理部１１０は、例えば、ノード情報管理部１６０及びストリーム制御部１７０として機能する。言い換えると、ノード情報管理部１６０及びストリーム制御部１７０は、処理部１１０により実現される機能モジュールである。ストリーム制御部１７０は、宛て先置換機能１７１を含む。ノード管理装置１００の機能性について、後にさらに説明する。

（２）記憶部
記憶部１２０は、一時的な及び非一時的なコンピュータ読取可能なメモリを含む。一時的なメモリは、例えばＲＡＭ（Random Access Memory）を含み得る。非一時的なメモリは、例えばＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）のうちの１つ以上を含み得る。記憶部１２０は、ノード管理装置１００の機能性を実現するためのコンピュータプログラムを記憶する。記憶部１２０は、さらに、ノード管理装置１００の動作において使用されるデータベースとして機能する。データベースは、レジストリ、リポジトリ又は単にテーブルなどと呼ばれてもよい。本実施形態において、記憶部１２０により記憶されるデータは、例えば、登録ノード情報１３０、登録センダ情報１４０及び登録レシーバ情報１４５を含む。こうしたデータの構成について、後にさらに説明する。

（３）通信インタフェース
通信インタフェース１５０は、ノード管理装置１００による他の装置との通信を仲介するインタフェースである。通信インタフェース１５０は、有線通信のための接続端子及び接続回路を含んでもよく、又は無線通信のためのアンテナ、ＲＦ（Radio Frequency）回路及びベースバンド回路を含んでもよい。本実施形態において、通信インタフェース１５０は、例えば、ＬＡＮ（Local Area Network）通信のためのネットワークアダプタ又はネットワークカードであってよい。ノード管理装置１００は、ＩＰドメイン１０に属する任意のノードと通信インタフェース１５０を介して通信する。

（４）ノード情報管理部
ノード情報管理部１６０は、放送局内のネットワーク上でのストリームの送信又は受信に関与する１つ以上の放送信号処理ノードに関する情報の、データベースへの登録及び管理を行う。

より具体的には、ノード情報管理部１６０は、放送局システム１のＩＰネットワークへの放送信号処理ノードの接続を監視し、放送信号処理ノードの接続を検出する。例えば、ＩＰネットワークへ接続した放送信号処理ノードは、ｍＤＮＳ（multicast Domain Name System）クエリを発行して、ノード管理装置１００により提供される情報登録サービスを発見し、発見したサービスへ向けて情報登録のための登録メッセージを送信する。例えば、１つ以上のセンダを有する放送信号処理ノードは、図３に例示したようなノード登録メッセージと、図４に例示したような１つ以上のセンダ登録メッセージとを送信する。１つ以上のレシーバを有する放送信号処理ノードは、図３に例示したようなノード登録メッセージと、図５に例示したような１つ以上のレシーバ登録メッセージとを送信する。ノード情報管理部１６０は、通信インタフェース１５０を介してこれら登録メッセージを受信し、受信したメッセージの内容に基づいて情報をデータベースへ登録する。

図１２は、ノード情報管理部１６０により管理される情報の構成の一例について説明するための説明図である。図１２には、登録ノード情報１３０、登録センダ情報１４０及び登録レシーバ情報１４５が示されている。登録ノード情報１３０は、情報項目として、ノード名称１３１、ノードＩＤ１３３及びＩＰアドレス１３５を含む。ノード名称１３１は、各放送信号処理ノードに付与される名称を表す。ノードＩＤ１３３は、各放送信号処理ノードを一意に識別する識別子である。識別子の一意性を担保するために、ノードＩＤとしてＵＵＩＤを用いることが有利である。但し、図１２では、説明の便宜上、より長さの短いノードＩＤを例示している。ＩＰアドレス１３５は、システム内で各放送信号処理ノードに割り当てられたＩＰアドレスである。少なくともノードＩＤ１３３及びＩＰアドレス１３５の値は、図３を用いて説明したように、各放送信号処理ノードから受信されるノード登録メッセージ内に記述され得る。

登録センダ情報１４０は、情報項目として、センダＩＤ１４１及び親ＩＤ１４３を含む。センダＩＤ１４１は、各センダを一意に識別する識別子である。識別子の一意性を担保するために、センダＩＤとしてＵＵＩＤを用いることが有利である。但し、図１２では、説明の便宜上、より長さの短いセンダＩＤを例示している。親ＩＤ１４３は、各センダが属するノードを識別するノードＩＤを表す。図１２の例では、センダＩＤ「ＳＮＡ１１」を有するセンダ及びセンダＩＤ「ＳＮＡ１２」を有するセンダは、共にノードＩＤ「ＮＤＡ１」により識別される放送信号処理ノードに属する。

登録レシーバ情報１４５は、情報項目として、レシーバＩＤ１４６及び親ＩＤ１４８を含む。レシーバＩＤ１４６は、各レシーバを一意に識別する識別子である。識別子の一意性を担保するために、レシーバＩＤとしてＵＵＩＤを用いることが有利である。但し、図１２では、説明の便宜上、より長さの短いレシーバＩＤを例示している。親ＩＤ１４８は、各レシーバが属するノードを識別するノードＩＤを表す。図１２の例では、レシーバＩＤ「ＲＣＡ２１」を有するレシーバ及びレシーバＩＤ「ＲＣＡ２２」を有するレシーバは、共にノードＩＤ「ＮＤＡ２」により識別される放送信号処理ノードに属する。

なお、図１２に示した登録情報は一例に過ぎない。ノード情報管理部１６０は、図示した情報項目以外の情報項目を管理してもよい。例えば、登録ノード情報１３０は、各放送信号処理ノードに属するセンダの個数を表すセンダ個数情報、及び各放送信号処理ノードに属するレシーバの個数を表すレシーバ個数情報をさらに含んでもよい。また、登録センダ情報１４０は、各センダのセンダ名称、各センダによりサポートされるストリーム及びエッセンスのタイプを表すタイプ情報、並びに、送信マルチキャストアドレス及び送信ポート番号といったその他のセンダ属性情報を含んでもよい。登録レシーバ情報１４５は、各レシーバのレシーバ名称、各レシーバによりサポートされるストリーム及びエッセンスのタイプを表すタイプ情報、並びに、加入マルチキャストアドレス及び受信ポート番号といったその他のレシーバ属性情報を含んでもよい。後に図１９を用いて説明する登録情報の構成の例についても同様である。

ノード情報管理部１６０は、接続を検出した放送信号処理ノードに関する情報を外部装置へ通知する。放送信号処理ノードに関する情報の外部装置への通知は、例えば、放送信号処理ノードからの登録メッセージ（又は登録情報変更メッセージ）の受信をトリガとして行われてもよい。その代わりに、外部装置への上記通知は、外部装置からの問合せに応じて行われてもよい。ノード情報管理部１６０は、外部装置への上記通知において、放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置１００を識別する代替識別情報を、当該放送信号処理ノードの識別情報として外部装置へ通知する。外部装置への通知は、例えば、図１３に例示するようなノード登録メッセージ５１ｂを外部装置へ送信することにより行われ得る。

図１３は、ノード登録メッセージにおけるノード識別情報の置換について説明するための説明図である。図１３の例において、放送信号処理ノード３０ａ、ノード管理装置１００及び外部装置５０は、共通的なＨＴＴＰベースのＡＰＩをサポートするものとする。したがって、放送信号処理ノード３０ａは、ＩＰネットワークへの接続後に、ＨＴＴＰメッセージであるノード登録メッセージ５１ａをノード管理装置１００へ送信する。ノード登録メッセージ５１ａの宛て先部分には、ノード管理装置１００のＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」が記述される。ノード情報管理部１６０は、ノード登録メッセージ５１ａの受信に応じて、メッセージボディ５４ａに記述されている放送信号処理ノード３０ａのノードＩＤ及びＩＰアドレスをデータベースに登録する。図１３には示していないものの、放送信号処理ノード３０ａがセンダ又はレシーバを有する場合には、ノード情報管理部１６０は、続いて、対応するセンダ登録メッセージ又はレシーバ登録メッセージをも受信し、センダ情報又はレシーバ情報をデータベースに登録する。

その後、ノード情報管理部１６０は、ノード登録メッセージ５１ｂを外部装置５０へ送信する。その際、ノード情報管理部１６０は、ノード登録メッセージ５１ｂのメッセージボディ５４ｂに、放送信号処理ノード３０ａを識別するＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｙ」に代えて、ノード管理装置１００を識別する代替的なＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」を記述する。即ち、ノード情報管理部１６０は、ノード管理装置１００を識別する代替識別情報を、放送信号処理ノード３０ａの識別情報として外部装置５０へ通知する。図１３には示していないものの、放送信号処理ノード３０ａがセンダ又はレシーバを有する場合には、ノード情報管理部１６０は、続いて、センダ登録メッセージ又はレシーバ登録メッセージを外部装置５０へ転送する。結果的に、外部装置５０は、放送信号処理ノード３０ａに属するセンダ又はレシーバが、メッセージボディ５４ｂに記述されたＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」により識別されるノードに属しているものと認識する。

ノード情報管理部１６０は、接続済みの放送信号処理ノードの各々の接続ステータスをさらに管理してもよい。各放送信号処理ノードの接続ステータスは、ノード単位で管理されてもよく、又はセンダ及びレシーバの単位で管理されてもよい。例えば、ノード情報管理部１６０は、放送信号処理ノードの各々から周期的に送信されるメッセージ（例えば、ハートビート又はステータスメッセージ）を受信することにより、各ノードの接続ステータスを管理し得る。ノード情報管理部１６０は、外部装置（例えば、制御端末）５０から受信されるメッセージに応じて、データベースへ情報を追加的に登録し、情報を変更し、又は情報を削除してもよい。

（５）ストリーム制御部
ストリーム制御部１７０は、放送局システム１内のセンダからレシーバへのストリームの伝送を制御する。本実施形態において、ストリーム制御部１７０もまた、ノード情報管理部１６０と同様に、外部装置５０と共通的なＨＴＴＰベースのＡＰＩをサポートする。サポートされるＡＰＩは、制御メッセージの宛て先部分で制御対象ノードを識別することを要するＡＰＩである。上述したＮＭＯＳインタフェースは、そうしたＡＰＩの一例である。この場合、制御メッセージの宛て先部分とは、ＨＴＴＰメッセージのホスト部分に相当し、ホスト部分にノード識別情報として制御対象ノードのＩＰアドレス又はホスト名が記述され得る。

本実施形態において、ストリーム制御部１７０は、放送信号処理ノードを制御するための制御メッセージであって、上述した代替識別情報を宛て先として有する当該制御メッセージを、外部装置５０から通信インタフェース１５０を介して受信する。これは、上述したように、ノード情報管理部１６０が外部装置５０への通知において放送信号処理ノードを識別するノード識別情報に代えてノード管理装置１００を識別する代替識別情報を当該放送信号処理ノードの識別情報として外部装置５０へ通知したためである。外部装置５０から受信される制御メッセージは、制御対象のセンダ又はレシーバを識別する制御対象情報を含む。制御対象情報は、図６の例のように、制御メッセージのメッセージボディに含まれるセンダＩＤ又はレシーバＩＤであり得る。

ストリーム制御部１７０は、受信した制御メッセージを、少なくとも宛て先を代替識別情報からもとのノード識別情報へ置換することにより変換して、変換後の制御メッセージを放送信号処理ノードへ送信する。例えば、ストリーム制御部１７０は、受信した制御メッセージ内に記述されている制御対象のセンダＩＤ又はレシーバＩＤをデータベース内でルックアップし、そのセンダＩＤ又はレシーバＩＤに関連付けられている所属先のノードの識別情報をデータベースから取得することができる。図１２に示したデータ構成によれば、制御対象のセンダＩＤに対応する親ＩＤを登録センダ情報１４０から取得し、さらに取得した親ＩＤ（ノードＩＤ）に対応するＩＰアドレスを登録ノード情報１３０から取得することができる。同様に、制御対象のレシーバＩＤに対応する親ＩＤを登録レシーバ情報１４５から取得し、さらに取得した親ＩＤ（ノードＩＤ）に対応するＩＰアドレスを登録ノード情報１３０から取得することができる。このように取得されるＩＰアドレスが、置換後のもとのノード識別情報の一例である。上述したように、ＩＰアドレスの代わりにホスト名が使用されてもよい。また、センダＩＤ及びレシーバＩＤは、所属先のノードのノードＩＤ（親ＩＤ）に直接的に関連付けられる代わりに、デバイスＩＤを介して間接的にノードＩＤに関連付けられてもよい。

図１４は、外部装置から放送信号処理ノードへ送信される制御メッセージにおける宛て先の置換について説明するための説明図である。図１４の例においても、放送信号処理ノード３０ａ、ノード管理装置１００及び外部装置５０は、共通的なＨＴＴＰベースのＡＰＩをサポートするものとする。外部装置５０は、ユーザからのリクエストの受け付け、又は予め決定される切替え（ストリーム伝送の開始）時刻の到来といったトリガに応じて、ＨＴＴＰメッセージであるストリーム制御メッセージ８１ｂをノード管理装置１００へ送信する。ストリーム制御メッセージ８１ｂの宛て先部分には、ノード管理装置１００のＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」が記述される。また、ストリーム制御メッセージ８１ｂは、制御対象のセンダを識別するセンダＩＤ「ＳＮＡ１１」をメッセージボディ８４ｂに含む。

ストリーム制御部１７０は、ストリーム制御メッセージ８１ｂの受信に応じて、センダＩＤ「ＳＮＡ１１」に関連付けられている所属先の放送信号処理ノード３０ａのＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｙ」をデータベースから取得する。次いで、ストリーム制御部１７０は、ストリーム制御メッセージ８１ｂの宛て先部分（例えば、リクエストライン内のホスト部分）に記述されているノード管理装置１００のＩＰアドレス（即ち、代替識別情報）「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」を、放送信号処理ノード３０ａを識別するＩＰアドレス（即ち、ノード識別情報）「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｙ」へ置換する。こうした置換の結果として、ストリーム制御メッセージ８１ｂはストリーム制御メッセージ８１ａへ変換される。そして、ストリーム制御部１７０は、変換後のストリーム制御メッセージ８１ａを放送信号処理ノード３０ａへ送信する。ストリーム制御メッセージ８１ａにおいて、制御対象のセンダを識別するセンダＩＤ「ＳＮＡ１１」はそのままであってよい。

図１３及び図１４を用いて説明したような、ノード識別情報に代わる代替識別情報の外部装置への通知、及び外部装置から送信される制御メッセージにおける代替識別情報からもとのノード識別情報への置換によって、放送局システム１内で交換される制御メッセージは必ずノード管理装置１００を通過するようになる。図には示していないものの、ノード管理装置１００は、例えば、制御メッセージを中継する際に、認証、リソース制限、ログの記録、又はセンダとレシーバとの間の属性の適合性の検証といった追加的な制御を行ってもよい。上述した仕組みによれば、制御メッセージは必ずノード管理装置１００を通過することから、システムの要件又はユーザのニーズに応じて、上述した様々な管理及び制御をノード管理装置１００が一元的に行うことができる。

＜２－２．処理の流れ＞
次に、図１５及び図１６を用いて、本実施形態においてノード管理装置１００により実行される処理の流れについて説明する。

（１）ノード情報通知処理
図１５は、本実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。

まず、ノード情報管理部１６０は、放送信号処理ノードからノード登録メッセージを受信する（ステップＳ１１０）。ノード情報管理部１６０は、受信したノード登録メッセージに記述されているノード情報をデータベースへ登録する（ステップＳ１１２）。また、ノード情報管理部１６０は、受信したノード登録メッセージ内のノード識別情報（ノード登録メッセージの送信元のノードの識別情報。例えば、ＩＰアドレス又はホスト名）を、ノード管理装置１００を識別する代替識別情報へ置換する（ステップＳ１１４）。そして、ノード情報管理部１６０は、置換後のノード登録メッセージを外部装置５０へ送信する（ステップＳ１１６）。

続けて、ノード情報管理部１６０は、上記放送信号処理ノードから１つ以上のセンダ登録メッセージ及び／又は１つ以上のレシーバ登録メッセージを受信する（ステップＳ１２０）。ノード情報管理部１６０は、受信したメッセージに記述されているセンダ情報及び／又はレシーバ情報をデータベースへ登録する（ステップＳ１２２）。そして、ノード情報管理部１６０は、受信したセンダ登録メッセージ及び／又はレシーバ登録メッセージを外部装置５０へ送信する（ステップＳ１２４）。

（２）メッセージ変換処理
図１６は、本実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。

まず、ストリーム制御部１７０は、放送信号処理ノードを制御するための制御メッセージであって、ノード管理装置１００を識別する代替識別情報を宛て先として有する当該制御メッセージを、外部装置５０から受信する（ステップＳ１４０）。次いで、ストリーム制御部１７０は、データベースに登録されている、各放送信号処理ノードに属するセンダを識別する登録センダ情報、又は各放送信号処理ノードに属するレシーバを識別する登録レシーバ情報に基づいて、制御対象の放送信号処理ノードのノード識別情報を取得する（ステップＳ１４２）。次いで、ストリーム制御部１７０は、受信した制御メッセージの宛て先部分に含まれる代替識別情報を、データベースから取得した制御対象の放送信号処理ノードのノード識別情報へ置換する（ステップＳ１４４）。そして、ストリーム制御部１７０は、置換後の制御メッセージを制御対象ノードへ送信する（ステップＳ１４６）。

＜２－３．利点＞
上述した第１の実施形態によれば、ノード管理装置１００及び外部装置５０は、制御メッセージの宛て先部分で制御対象ノードを識別することを要するＡＰＩをサポートする。制御対象の放送信号処理ノードもまた、上記ＡＰＩをサポートする。ノード管理装置１００は、上記ＡＰＩを用いて制御メッセージを外部装置５０から受信し、受信した制御メッセージの宛て先をノード管理装置１００を識別する代替識別情報から制御対象の放送信号処理ノードを識別するノード識別情報へ置換して、置換後の制御メッセージを制御対象の放送信号処理ノードへ送信する。こうした仕組みによれば、図１７に示したように、放送局システム１内で交換される制御メッセージを、必ずノード管理装置１００を通過するようにすることができる。

図１７の例では、４つの放送信号処理ノード３０ａ、３０ｂ、３０ｅ及び３０ｆ、並びに３つの制御端末５０ａ、５０ｂ及び５０ｃがシステム内に存在する。これら放送信号処理ノード及び制御端末は、同一のタイプの制御ＡＰＩをサポートする。当該制御ＡＰＩは、制御端末と放送信号処理ノードとの間で直接的に制御メッセージを交換することを規定しているものとする。それにも関わらず、第１の実施形態では、上述したように制御メッセージが必ずノード管理装置１００を通過することから、一元的なストリームの管理及び制御を実現することが容易である。これは、図９を用いて説明したシナリオにおいて、制御が分散的に行われる結果として一元的なストリームの管理及び制御が困難であったのとは対照的である。

＜＜３．第２の実施形態＞＞
＜３－１．ノード管理装置の構成例＞
図１８は、第２の実施形態に係るノード管理装置２００の構成の一例を示すブロック図である。図１８を参照すると、ノード管理装置２００は、処理部２１０、記憶部２２０及び通信インタフェース１５０を備える。

（１）処理部
処理部２１０は、例えば、ＣＰＵ、ＭＰＵ又はマイクロコントローラといった１つ以上のプロセッサを含む。処理部２１０は、記憶部２２０により記憶されるコンピュータプログラムを実行することにより、ノード管理装置２００の機能性を実現する。本実施形態において、処理部２１０は、例えば、ノード情報管理部２６０及びストリーム制御部２７０として機能する。言い換えると、ノード情報管理部２６０及びストリーム制御部２７０は、処理部２１０により実現される機能モジュールである。ストリーム制御部２７０は、メッセージ変換機能２７３を含む。ノード管理装置２００の機能性について、後にさらに説明する。

（２）記憶部
記憶部２２０は、一時的な及び非一時的なコンピュータ読取可能なメモリを含む。一時的なメモリは、例えばＲＡＭを含み得る。非一時的なメモリは、例えばＲＯＭ、ＨＤＤ又はＳＳＤのうちの１つ以上を含み得る。記憶部２２０は、ノード管理装置２００の機能性を実現するためのコンピュータプログラムを記憶する。記憶部２２０は、さらに、ノード管理装置２００の動作において使用されるデータベースとして機能する。本実施形態において、記憶部２２０により記憶されるデータは、例えば、登録ノード情報２３０、登録センダ情報１４０及び登録レシーバ情報１４５を含む。こうしたデータの構成について、後にさらに説明する。

（３）ノード情報管理部
ノード情報管理部２６０は、放送局内のネットワーク上でのストリームの送信又は受信に関与する１つ以上の放送信号処理ノードに関する情報の、データベースへの登録及び管理を行う。

より具体的には、ノード情報管理部２６０は、第１の実施形態に係るノード管理装置１００のノード情報管理部１６０と同様に、放送局システム１のＩＰネットワークへの放送信号処理ノードの接続を監視し、放送信号処理ノードの接続を検出する。例えば、ＩＰネットワークへ接続した放送信号処理ノードは、ｍＤＮＳクエリを発行して、ノード管理装置２００により提供される情報登録サービスを発見し、発見したサービスへ向けて情報登録のための一群の登録メッセージ（例えば、ノード登録メッセージ、並びに１つ以上のセンダ登録メッセージ及び／又は１つ以上のレシーバ登録メッセージ）を送信する。ノード情報管理部２６０は、通信インタフェース１５０を介してこれら登録メッセージを受信し、受信したメッセージの内容に基づいて情報をデータベースへ登録する。

図１９は、ノード情報管理部２６０により管理される情報の構成の一例について説明するための説明図である。図１９には、登録ノード情報２３０、登録センダ情報１４０及び登録レシーバ情報１４５が示されている。登録ノード情報２３０は、情報項目として、ノード名称１３１、ノードＩＤ１３３、種別２３４及びＩＰアドレス１３５を含む。種別２３４は、各放送信号処理ノード（ノードＩＤ１３３により識別されるノード）によりサポートされる制御ＡＰＩの種別を表す。図１９の例では、ノードＩＤ「ＮＤＡ１」により識別されるノード及びノードＩＤ「ＮＤＡ２」により識別されるノードは制御ＡＰＩとしてＮＭＯＳをサポートし、ノードＩＤ「ＮＤＣ１」により識別されるノードは制御ＡＰＩとしてＮＭＩをサポートする。一例として、ＮＭＯＳは、ノード管理装置２００及び外部装置により共通的にサポートされる制御ＡＰＩである。したがって、種別２３４は、各放送信号処理ノードがノード管理装置２００及び外部装置により共通的にサポートされる制御ＡＰＩをサポートするか否かを示すノード種別情報であるということができる。本明細書では、ノード管理装置及び外部装置により共通的にサポートされる制御ＡＰＩを、共通ＡＰＩともいう。

ノード情報管理部２６０は、接続を検出した放送信号処理ノードに関する情報を外部装置へ通知する。放送信号処理ノードに関する情報の外部装置への通知は、例えば、放送信号処理ノードからの登録メッセージ（又は登録情報変更メッセージ）の受信をトリガとして行われてもよい。その代わりに、外部装置への上記通知は、外部装置からの問合せに応じて行われてもよい。ノード情報管理部２６０は、外部装置への上記通知において、共通ＡＰＩをサポートする放送信号処理ノードについては、ノード識別情報を置換することなく登録メッセージをそのまま外部装置へ送信する。一方、ノード情報管理部２６０は、共通ＡＰＩをサポートしない放送信号処理ノードについては、当該放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置２００を識別する代替識別情報を、当該放送信号処理ノードの識別情報として外部装置へ通知する。ノード情報管理部２６０は、登録メッセージの形式をも当該放送信号処理ノードによりサポートされる形式から共通ＡＰＩの形式へ変換する。

図２０は、ノード登録メッセージにおけるノード識別情報の置換及びメッセージ形式の変換について説明するための説明図である。図２０の例において、ノード管理装置２００及び外部装置５０は、ＨＴＴＰベースの制御ＡＰＩである共通ＡＰＩをサポートするものとする。放送信号処理ノード３０ｃは、共通ＡＰＩとは異なるＡＰＩをサポートする。ノード管理装置２００は、放送信号処理ノード３０ｃによりサポートされる当該ＡＰＩをもサポートする。

放送信号処理ノード３０ｃは、ＩＰネットワークへの接続後に、ノード登録メッセージ５１ｃをノード管理装置２００へ送信する。ノード情報管理部２６０は、ノード登録メッセージ５１ｃの受信に応じて、メッセージ内に記述されている放送信号処理ノード３０ｃのノードＩＤ及びＩＰアドレスをデータベースに登録する。図２０には示していないものの、放送信号処理ノード３０ｃがセンダ又はレシーバを有する場合には、ノード情報管理部２６０は、続いて、対応するセンダ登録メッセージ又はレシーバ登録メッセージをも受信し、センダ情報又はレシーバ情報をデータベースに登録する。

その後、ノード情報管理部２６０は、共通ＡＰＩに準拠する形式のノード登録メッセージ５１ｄを生成し、生成したノード登録メッセージ５１ｄを外部装置５０へ送信する。その際、ノード情報管理部２６０は、ノード登録メッセージ５１ｄのメッセージボディ５４ｄに、放送信号処理ノード３０ｃを識別するＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｋ」に代えて、ノード管理装置２００を識別する代替的なＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」を記述する。即ち、ノード情報管理部２６０は、ノード管理装置２００を識別する代替識別情報を、放送信号処理ノード３０ｃの識別情報として外部装置５０へ通知する。図２０には示していないものの、放送信号処理ノード３０ｃがセンダ又はレシーバを有する場合には、ノード情報管理部２６０は、続いて、共通ＡＰＩに準拠する形式のセンダ登録メッセージ又はレシーバ登録メッセージを生成して、生成したメッセージを外部装置５０へ送信する。結果的に、外部装置５０は、放送信号処理ノード３０ｃに属するセンダ又はレシーバが、メッセージボディ５４ｄに記述されたＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」により識別されるノードに属しているものと認識する。

ノード情報管理部２６０は、第１の実施形態に係るノード管理装置１００のノード情報管理部１６０と同様に、接続済みの放送信号処理ノードの各々の接続ステータスをさらに管理してもよい。ノード情報管理部２６０は、外部装置（例えば、制御端末）５０から受信されるメッセージに応じて、データベースへ情報を追加的に登録し、情報を変更し、又は情報を削除してもよい。

（４）ストリーム制御部
ストリーム制御部２７０は、放送局システム１内のセンダからレシーバへのストリームの伝送を制御する。本実施形態において、ストリーム制御部２７０もまた、ノード情報管理部２６０と同様に、共通ＡＰＩ及び共通ＡＰＩとは異なる１つ以上の制御ＡＰＩをサポートする。共通ＡＰＩは、制御メッセージの宛て先部分で制御対象ノードを識別することを要するＡＰＩである。上述したＮＭＯＳインタフェースは、そうしたＡＰＩの一例である。

本実施形態において、ストリーム制御部２７０は、放送信号処理ノードを制御するための制御メッセージであって、上述した代替識別情報を宛て先として有する当該制御メッセージを、外部装置５０から通信インタフェース１５０を介して受信する。代替識別情報を宛て先として有する制御メッセージの制御対象の放送信号処理ノードは、共通ＡＰＩとは異なる制御ＡＰＩをサポートする。なぜなら、本実施形態において、ノード情報管理部２６０は、共通ＡＰＩとは異なる制御ＡＰＩをサポートする放送信号処理ノードについてのみ、外部装置５０への通知において当該放送信号処理ノードを識別するノード識別情報に代えてノード管理装置２００を識別する代替識別情報を外部装置５０へ通知するためである。共通ＡＰＩをサポートする放送信号処理ノードを制御するための制御メッセージは、外部装置５０から当該放送信号処理ノードへ直接的に送信されてよい。

ストリーム制御部２７０は、受信した制御メッセージの宛て先を、代替識別情報からもとのノード識別情報へ置換する。さらに、ストリーム制御部２７０は、受信した制御メッセージを、制御対象の放送信号処理ノードによりサポートされる形式のメッセージへ変換する。そして、ストリーム制御部２７０は、変換後の制御メッセージを制御対象の放送信号処理ノードへ送信する。例えば、ストリーム制御部２７０は、受信した制御メッセージ内に記述されている制御対象のセンダＩＤ又はレシーバＩＤをデータベース内でルックアップし、そのセンダＩＤ又はレシーバＩＤに関連付けられている所属先のノードの識別情報とサポートされる制御ＡＰＩの種別とを、データベースから取得することができる。

図２１は、外部装置から放送信号処理ノードへ送信される制御メッセージのメッセージ変換について説明するための説明図である。図２１の例においても、ノード管理装置２００及び外部装置５０は共通ＡＰＩをサポートし、一方で放送信号処理ノード３０ｃは共通ＡＰＩとは異なるＡＰＩをサポートする。ノード管理装置２００は、放送信号処理ノード３０ｃによりサポートされる当該ＡＰＩをもサポートする。

外部装置５０は、ユーザからのリクエストの受け付け、又は予め決定される切替え時刻の到来といったトリガに応じて、ＨＴＴＰメッセージであるストリーム制御メッセージ８１ｄをノード管理装置２００へ送信する。ストリーム制御メッセージ８１ｄの宛て先部分には、ノード管理装置２００のＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」が記述される。また、ストリーム制御メッセージ８１ｄは、制御対象のレシーバを識別するレシーバＩＤ「ＲＣＣ１１」をメッセージボディ８４ｄに含む。

ストリーム制御部２７０は、ストリーム制御メッセージ８１ｄの受信に応じて、レシーバＩＤ「ＲＣＣ１１」に関連付けられている所属先の放送信号処理ノード３０ｃのＩＰアドレス「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｋ」をデータベースから取得する。次いで、ストリーム制御部２７０は、ストリーム制御メッセージ８１ｄの宛て先部分（例えば、リクエストライン内のホスト部分）に記述されているノード管理装置２００のＩＰアドレス（即ち、代替識別情報）「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｘ」を、放送信号処理ノード３０ｃを識別するＩＰアドレス（即ち、ノード識別情報）「ｘｘｘ．ｘｘｘ．ｘｘｘ．Ｋ」へ置換する。さらに、ストリーム制御部２７０は、ストリーム制御メッセージ８１ｄのメッセージ形式（例えば、タイプＡ）を、放送信号処理ノード３０ｃによりサポートされる形式（例えば、タイプＢ）へ変換する。そして、ストリーム制御部２７０は、変換後のストリーム制御メッセージ８１ｃを放送信号処理ノード３０ｃへ送信する。ストリーム制御メッセージ８１ｃにおいて、制御対象のレシーバを識別するレシーバＩＤ「ＲＣＣ１１」はそのままであってよい。

図２０及び図２１を用いて説明したような、ノード識別情報に代わる代替識別情報の外部装置への通知と、識別情報の置換を含む制御メッセージの変換とによって、放送局システム１内に共通ＡＰＩをサポートしない放送信号処理ノードが存在するとしても、外部装置５０は共通ＡＰＩのみをサポートすればよいことになる。

＜３－２．処理の流れ＞
次に、図２２及び図２３を用いて、本実施形態においてノード管理装置２００により実行される処理の流れについて説明する。

（１）ノード情報通知処理
図２２は、本実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。

まず、ノード情報管理部２６０は、放送信号処理ノードからノード登録メッセージを受信する（ステップＳ２１０）。ノード情報管理部２６０は、受信したノード登録メッセージに記述されているノード情報をデータベースへ登録する（ステップＳ２１２）。また、ノード情報管理部２６０は、ノード登録メッセージの送信元の放送信号処理ノードが所定のＡＰＩをサポートしているかを判定する（ステップＳ２１３）。ここでの所定のＡＰＩは、上述した共通ＡＰＩに相当し、例えばＮＭＯＳ、ＮＭＩ、ＭｅｓｓａｇｅＰａｃｋ－ＲＰＣ又は他の任意の制御ＡＰＩであってよい。その後の処理は、ステップＳ２１３における判定結果に依存して分岐する。

放送信号処理ノードが所定のＡＰＩをサポートしている場合、ノード情報管理部２６０は、受信したメッセージと同一の内容を含むノード登録メッセージを外部装置５０へ送信する（ステップＳ２１４）。続けて、ノード情報管理部２６０は、上記放送信号処理ノードから１つ以上のセンダ登録メッセージ及び／又は１つ以上のレシーバ登録メッセージを受信する（ステップＳ２２０）。ノード情報管理部２６０は、受信したメッセージに記述されているセンダ情報及び／又はレシーバ情報をデータベースへ登録する（ステップＳ２２２）。そして、ノード情報管理部２６０は、受信したメッセージと同一の内容を含むセンダ登録メッセージ及び／又はレシーバ登録メッセージを外部装置５０へ送信する（ステップＳ２２４）。

放送信号処理ノードが所定のＡＰＩをサポートしていない場合、ノード情報管理部２６０は、ノード識別情報の代替識別情報への置換を含むメッセージ変換を実行して、所定のＡＰＩに準拠したノード登録メッセージを生成する（ステップＳ２１５）。そして、ノード情報管理部２６０は、生成したノード登録メッセージを外部装置５０へ送信する（ステップＳ２１７）。続けて、ノード情報管理部２６０は、上記放送信号処理ノードから１つ以上のセンダ登録メッセージ及び／又は１つ以上のレシーバ登録メッセージを受信する（ステップＳ２２１）。ノード情報管理部２６０は、受信したメッセージに記述されているセンダ情報及び／又はレシーバ情報をデータベースへ登録する（ステップＳ２２３）。次いで、ノード情報管理部２６０は、メッセージ変換を実行して、所定のＡＰＩに準拠したセンダ登録メッセージ及び／又はレシーバ登録メッセージを生成する（ステップＳ２２５）。そして、ノード情報管理部２６０は、生成したセンダ登録メッセージ及び／又はレシーバ登録メッセージを外部装置５０へ送信する（ステップＳ２２７）。

（２）メッセージ変換処理
図２３は、本実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。

まず、ストリーム制御部２７０は、放送信号処理ノードを制御するための制御メッセージであって、ノード管理装置２００を識別する代替識別情報を宛て先として有する当該制御メッセージを、外部装置５０から受信する（ステップＳ２４０）。次いで、ストリーム制御部２７０は、データベースに登録されている、各放送信号処理ノードに属するセンダを識別する登録センダ情報、又は各放送信号処理ノードに属するレシーバを識別する登録レシーバ情報に基づいて、制御対象の放送信号処理ノードのノード識別情報を取得する（ステップＳ２４２）。次いで、ストリーム制御部２７０は、受信した制御メッセージの宛て先部分に含まれる識別情報の置換（代替識別情報からステップＳ２４２で取得したノード識別情報への置換）を含むメッセージ変換を実行する（ステップＳ２４６）。そして、ストリーム制御部２７０は、変換後の制御メッセージを制御対象ノードへ送信する（ステップＳ２４８）。

＜３－３．利点＞
上述した第２の実施形態によれば、外部装置５０は、共通ＡＰＩをサポートする放送信号処理ノードに属するセンダ及びレシーバが（実際の配備の通りに）当該放送信号処理ノード自体に位置していると認識する一方、共通ＡＰＩをサポートしない放送信号処理ノードに属するセンダ及びレシーバは（実際の配備とは異なり）ノード管理装置１００に位置していると認識する。言い換えると、外部装置５０は、どのセンダ及びレシーバも、共通ＡＰＩをサポートするノードに属していると認識する。こうした仕組みによれば、図２４に示したように、放送局システム１内に異なる種類の制御ＡＰＩをサポートする複数の放送信号処理ノードが存在する状況においても、外部装置５０は単一の共通的なＡＰＩのみをサポートすればよいことになる。

図２４の例では、４つの放送信号処理ノード３０ａ、３０ｂ、３０ｃ及び３０ｄ、並びに制御端末５０ａがシステム内に存在する。放送信号処理ノード３０ａ及び３０ｂは第１のタイプの制御ＡＰＩをサポートするが、放送信号処理ノード３０ｃは第２のタイプの制御ＡＰＩを、放送信号処理ノード３０ｄは第３のタイプの制御ＡＰＩをサポートする。しかし、第２の実施形態では、上述したようにノード管理装置２００が外部装置５０ａと放送信号処理ノード３０ｃ及び３０ｄとの間でメッセージの宛て先の置換及びメッセージ形式の変換を実行するため、外部装置５０ａは第１のタイプの制御ＡＰＩのみをサポートすればよい。これは、図８を用いて説明したシナリオにおいて、システム内で利用される制御ＡＰＩの種類の数だけ制御端末（あるいは制御機能）を実装することを要していたのとは対照的である。第２の実施形態では、ノードの追加及び制御端末の増加に対する拡張可能性が強化され、かつ少なくともノード情報の一元的な管理もまた可能である。

＜＜４．第３の実施形態＞＞
＜４－１．ノード管理装置の構成例＞
図２５は、第３の実施形態に係るノード管理装置３００の構成の一例を示すブロック図である。図２５を参照すると、ノード管理装置３００は、処理部３１０、記憶部３２０及び通信インタフェース１５０を備える。

（１）処理部
処理部３１０は、例えば、ＣＰＵ、ＭＰＵ又はマイクロコントローラといった１つ以上のプロセッサを含む。処理部３１０は、記憶部３２０により記憶されるコンピュータプログラムを実行することにより、ノード管理装置３００の機能性を実現する。本実施形態において、処理部３１０は、例えば、ノード情報管理部３６０及びストリーム制御部３７０として機能する。言い換えると、ノード情報管理部３６０及びストリーム制御部３７０は、処理部３１０により実現される機能モジュールである。ストリーム制御部３７０は、宛て先置換機能３７１及びメッセージ変換機能３７３を含む。ノード管理装置３００の機能性について、後にさらに説明する。

（２）記憶部
記憶部３２０は、一時的な及び非一時的なコンピュータ読取可能なメモリを含む。一時的なメモリは、例えばＲＡＭを含み得る。非一時的なメモリは、例えばＲＯＭ、ＨＤＤ又はＳＳＤのうちの１つ以上を含み得る。記憶部３２０は、ノード管理装置３００の機能性を実現するためのコンピュータプログラムを記憶する。記憶部３２０は、さらに、ノード管理装置３００の動作において使用されるデータベースとして機能する。本実施形態において、記憶部３２０により記憶されるデータは、例えば、登録ノード情報２３０、登録センダ情報１４０及び登録レシーバ情報１４５を含む。

（３）ノード情報管理部
ノード情報管理部３６０は、放送局内のネットワーク上でのストリームの送信又は受信に関与する１つ以上の放送信号処理ノードに関する情報の、データベースへの登録及び管理を行う。

より具体的には、ノード情報管理部３６０は、第１の実施形態におけるノード情報管理部１６０及び第２の実施形態におけるノード情報管理部２６０と同様に、放送局システム１のＩＰネットワークへの放送信号処理ノードの接続を監視し、放送信号処理ノードの接続を検出する。例えば、ＩＰネットワークへ接続した放送信号処理ノードは、ｍＤＮＳクエリを発行して、ノード管理装置３００により提供される情報登録サービスを発見し、発見したサービスへ向けて情報登録のための一群の登録メッセージ（例えば、ノード登録メッセージ、並びに１つ以上のセンダ登録メッセージ及び／又は１つ以上のレシーバ登録メッセージ）を送信する。ノード情報管理部３６０は、通信インタフェース１５０を介してこれら登録メッセージを受信し、受信したメッセージの内容に基づいて情報をデータベースへ登録する。ノード情報管理部３６０により管理される情報の構成は、例えば、図１９を用いて説明した構成と同様であってもよく、又は当該構成とは異なってもよい。

ノード情報管理部３６０は、接続を検出した放送信号処理ノードに関する情報を外部装置へ通知する。放送信号処理ノードに関する情報の外部装置への通知は、例えば、放送信号処理ノードからの登録メッセージ（又は登録情報変更メッセージ）の受信をトリガとして行われてもよい。その代わりに、外部装置への上記通知は、外部装置からの問合せに応じて行われてもよい。とりわけ、本実施形態において、ノード情報管理部３６０は、外部装置への上記通知において、放送信号処理ノードが共通ＡＰＩをサポートするか否かに関わらず、当該放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置３００を識別する代替識別情報を、当該放送信号処理ノードの識別情報として外部装置へ通知する。ノード情報管理部３６０は、共通ＡＰＩとは異なるＡＰＩの形式の登録メッセージを受信した場合には、登録メッセージの形式の共通ＡＰＩ形式への変換も行う。共通ＡＰＩをサポートする放送信号処理ノードのためのノード識別情報の置換は、例えば図１３に示したように行われてよい。共通ＡＰＩをサポートしない放送信号処理ノードのためのノード識別情報の置換を含むメッセージ変換は、例えば図２０に示したように行われてよい。

ノード情報管理部３６０は、第１の実施形態におけるノード情報管理部１６０及び第２の実施形態におけるノード情報管理部２６０と同様に、接続済みの放送信号処理ノードの各々の接続ステータスをさらに管理してもよい。ノード情報管理部３６０は、外部装置（例えば、制御端末）５０から受信されるメッセージに応じて、データベースへ情報を追加的に登録し、情報を変更し、又は情報を削除してもよい。

（４）ストリーム制御部
ストリーム制御部３７０は、放送局システム１内のセンダからレシーバへのストリームの伝送を制御する。本実施形態において、ストリーム制御部３７０もまた、ノード情報管理部３６０と同様に、共通ＡＰＩ及び共通ＡＰＩとは異なる１つ以上の制御ＡＰＩをサポートする。共通ＡＰＩは、制御メッセージの宛て先部分で制御対象ノードを識別することを要するＡＰＩである。上述したＮＭＯＳインタフェースは、そうしたＡＰＩの一例である。

本実施形態において、ストリーム制御部３７０は、放送信号処理ノードを制御するための制御メッセージであって、上述した代替識別情報を宛て先として有する当該制御メッセージを、外部装置５０から通信インタフェース１５０を介して受信する。代替識別情報を宛て先として有する制御メッセージの制御対象の放送信号処理ノードは、共通ＡＰＩをサポートする放送信号処理ノード（以下、第１の放送信号処理ノードという）、又は共通ＡＰＩとは異なる制御ＡＰＩをサポートする放送信号処理ノード（以下、第２の放送信号処理ノードという）のいずれかである。

ストリーム制御部３７０は、データベースに登録されている、各放送信号処理ノードが共通ＡＰＩをサポートするか否かを示すノード種別情報に基づいて、受信した制御メッセージをどのように変換すべきか判定する。例えば、図１９を用いて説明した例において、ＮＭＯＳが共通ＡＰＩである場合には、ノードＩＤ「ＮＤＡ１」又は「ＮＤＡ２」により識別されるノードは、種別２３４により示されるように制御ＡＰＩとしてＮＭＯＳをサポートするため、共通ＡＰＩをサポートすると判定され得る。一方、ノードＩＤ「ＮＤＣ１」により識別されるノードは、種別２３４により示されるように制御ＡＰＩとしてＮＭＯＳをサポートしないため、共通ＡＰＩをサポートしないと判定され得る。

ストリーム制御部３７０は、共通ＡＰＩをサポートする第１の放送信号処理ノードを制御対象ノードとして識別する第１制御メッセージが外部装置から受信された場合には、第１制御メッセージの宛て先を当該第１の放送信号処理ノードを識別するノード識別情報へ置換することにより第１制御メッセージを変換して、変換後の第１制御メッセージを当該第１の放送信号処理ノードへ送信する。一方、ストリーム制御部３７０は、共通ＡＰＩをサポートしない第２の放送信号処理ノードを制御対象ノードとして識別する第２制御メッセージが外部装置から受信された場合には、第２制御メッセージを当該第２の放送信号処理ノードによりサポートされる形式のメッセージへ変換して、変換後の第２制御メッセージを当該第２の放送信号処理ノードへ送信する。ここでのメッセージ変換は、代替識別情報からノード識別情報への、宛て先の置換を含む。第１の放送信号処理ノードのための宛て先の置換は、例えば図１４に示したように行われてよい。第２の放送信号処理ノードのための宛て先の置換を含むメッセージ変換は、例えば図２１に示したように行われてよい。

上述した仕組みによれば、制御メッセージが必ずノード管理装置３００を通過することから、様々な管理及び制御をノード管理装置３００が一元的に行うことができる。加えて、システム内に共通ＡＰＩをサポートしない放送信号処理ノードが存在するとしても、外部装置５０は共通ＡＰＩのみをサポートすればよいことになる。

＜４－２．処理の流れ＞
次に、図２６及び図２７を用いて、本実施形態においてノード管理装置３００により実行される処理の流れについて説明する。

（１）ノード情報通知処理
図２６は、本実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。

まず、ノード情報管理部３６０は、放送信号処理ノードからノード登録メッセージを受信する（ステップＳ３１０）。ノード情報管理部３６０は、受信したノード登録メッセージに記述されているノード情報をデータベースへ登録する（ステップＳ３１２）。また、ノード情報管理部３６０は、ノード登録メッセージの送信元の放送信号処理ノードが所定のＡＰＩをサポートしているかを判定する（ステップＳ３１３）。ここでの所定のＡＰＩは、上述した共通ＡＰＩに相当し、例えばＮＭＯＳ、ＮＭＩ又は他の任意の制御ＡＰＩであってよい。その後の処理は、ステップＳ３１３における判定結果に依存して分岐する。

放送信号処理ノードが所定のＡＰＩをサポートしている場合、ノード情報管理部３６０は、受信したノード登録メッセージ内のノード識別情報を、ノード管理装置３００を識別する代替識別情報へ置換する（ステップＳ３１４）。そして、ノード情報管理部３６０は、置換後のノード登録メッセージを外部装置５０へ送信する（ステップＳ３１５）。続けて、ノード情報管理部３６０は、上記放送信号処理ノードから１つ以上のセンダ登録メッセージ及び／又は１つ以上のレシーバ登録メッセージを受信する（ステップＳ３２０）。ノード情報管理部３６０は、受信したメッセージに記述されているセンダ情報及び／又はレシーバ情報をデータベースへ登録する（ステップＳ３２２）。そして、ノード情報管理部３６０は、受信したセンダ登録メッセージ及び／又はレシーバ登録メッセージを外部装置５０へ送信する（ステップＳ３２４）。

放送信号処理ノードが所定のＡＰＩをサポートしていない場合、ノード情報管理部３６０は、ノード識別情報の代替識別情報への置換を含むメッセージ変換を実行して、所定のＡＰＩに準拠したノード登録メッセージを生成する（ステップＳ３１６）。そして、ノード情報管理部３６０は、生成したノード登録メッセージを外部装置５０へ送信する（ステップＳ３１７）。続けて、ノード情報管理部３６０は、上記放送信号処理ノードから１つ以上のセンダ登録メッセージ及び／又は１つ以上のレシーバ登録メッセージを受信する（ステップＳ３２１）。ノード情報管理部３６０は、受信したメッセージに記述されているセンダ情報及び／又はレシーバ情報をデータベースへ登録する（ステップＳ３２３）。次いで、ノード情報管理部３６０は、メッセージ変換を実行して、所定のＡＰＩに準拠したセンダ登録メッセージ及び／又はレシーバ登録メッセージを生成する（ステップＳ３２５）。そして、ノード情報管理部３６０は、生成したセンダ登録メッセージ及び／又はレシーバ登録メッセージを外部装置５０へ送信する（ステップＳ３２７）。

（２）メッセージ変換処理
図２７は、本実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。

まず、ストリーム制御部３７０は、放送信号処理ノードを制御するための制御メッセージであって、ノード管理装置３００を識別する代替識別情報を宛て先として有する当該制御メッセージを、外部装置５０から受信する（ステップＳ３４０）。次いで、ストリーム制御部３７０は、データベースに登録されている、各放送信号処理ノードに属するセンダを識別する登録センダ情報、又は各放送信号処理ノードに属するレシーバを識別する登録レシーバ情報に基づいて、制御対象の放送信号処理ノードの識別情報及び種別情報を取得する（ステップＳ３４２）。次いで、ストリーム制御部３７０は、取得した種別情報に基づいて、制御対象の放送信号処理ノードが所定のＡＰＩをサポートしているかを判定する（ステップＳ３４３）。その後の処理は、ステップＳ３４３における判定結果に依存して分岐する。

放送信号処理ノードが所定のＡＰＩをサポートしている場合、ストリーム制御部３７０は、受信した制御メッセージの宛て先部分に含まれる代替識別情報を、データベースから取得した制御対象の放送信号処理ノードのノード識別情報へ置換する（ステップＳ３４４）。そして、ストリーム制御部３７０は、置換後の制御メッセージを制御対象ノードへ送信する（ステップＳ３４５）。

放送信号処理ノードが所定のＡＰＩをサポートしていない場合、ストリーム制御部３７０は、受信した制御メッセージの宛て先部分に含まれる識別情報の置換（代替識別情報からステップＳ３４２で取得したノード識別情報への置換）を含むメッセージ変換を実行する（ステップＳ３４６）。メッセージ変換は、ステップＳ３４２で取得したノード種別情報により示される制御ＡＰＩの種別に基づいて行われ得る。そして、ストリーム制御部３７０は、変換後の制御メッセージを制御対象ノードへ送信する（ステップＳ３４７）。

＜４－３．利点＞
上述した第３の実施形態によれば、外部装置５０は、所定のＡＰＩ（あるいは共通ＡＰＩ）をサポートする放送信号処理ノードに属するセンダ及びレシーバも、当該所定のＡＰＩをサポートしない放送信号処理ノードに属するセンダ及びレシーバも、（実際の配備とは異なり）ノード管理装置３００に位置していると認識する。こうした仕組みによれば、図２８に示したように、放送局システム１内で交換される制御メッセージを、必ずノード管理装置３００を通過するようにすることができる。加えて、放送局システム１内に異なる種類の制御ＡＰＩをサポートする複数の放送信号処理ノードが存在する状況においても、外部装置５０は単一の共通的なＡＰＩのみをサポートすればよいことになる。

図２８の例では、４つの放送信号処理ノード３０ａ、３０ｂ、３０ｃ及び３０ｄ、並びに３つの制御端末５０ａ、５０ｂ及び５０ｃがシステム内に存在する。放送信号処理ノード３０ａ及び３０ｂは第１のタイプの制御ＡＰＩをサポートするが、放送信号処理ノード３０ｃは第２のタイプの制御ＡＰＩを、放送信号処理ノード３０ｄは第３のタイプの制御ＡＰＩをサポートする。一方、制御端末５０ａ、５０ｂ及び５０ｃは、同一のタイプの制御ＡＰＩをサポートする。当該制御ＡＰＩは制御端末と放送信号処理ノードとの間で直接的に制御メッセージを交換することを規定しているにも関わらず、上述したように、制御メッセージは必ずノード管理装置３００を通過する。よって、一元的なストリームの管理及び制御を実現することが容易である。さらに、第３の実施形態では、上述したようにノード管理装置３００が外部装置と放送信号処理ノード３０ｃ及び３０ｄとの間でメッセージの宛て先の置換及びメッセージ形式の変換を実行するため、外部装置は共通ＡＰＩのみをサポートすればよい。よって、第３の実施形態では、ノードの追加及び制御端末の増加に対する拡張可能性が強化され、かつノード情報の一元的な管理及びストリームの一元的な制御が可能である。

＜＜５．第４の実施形態＞＞
次いで、図２９を用いて、第４の実施形態について説明する。上述した第１～第３の実施形態は具体的な実施形態であり、一方で第４の実施形態はより一般化された実施形態である。

図２９は、第４の実施形態に係るノード管理装置４００の構成、及びノード管理装置４００と連携するデータベース装置４０５の構成の一例を示している。ノード管理装置４００は、放送局内のネットワーク上でのストリームの送信又は受信に関与する１つ以上の放送信号処理ノードを管理するための情報処理装置である。ノード管理装置４００は、データベース装置４０５へアクセス可能である。また、ノード管理装置４００は、ストリーム制御部４７０を備える。データベース装置４０５は、記憶部４２０及び情報管理部４６０を備える。

データベース装置４０５の記憶部４２０は、上記１つ以上の放送信号処理ノードに関する登録情報を記憶する。情報管理部４６０は、放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置４００を識別する代替識別情報を当該放送信号処理ノードの識別情報として外部装置へ通知する。ノード管理装置４００のストリーム制御部４７０は、ある放送信号処理ノードを制御するための制御メッセージであって、上記代替識別情報を宛て先として有する当該制御メッセージが外部装置から受信された場合に、当該制御メッセージを、少なくとも宛て先を上記代替識別情報からもとのノード識別情報へ置換することにより変換して、変換後の制御メッセージを上記放送信号処理ノードへ送信する。

上記１つ以上の放送信号処理ノードを管理するためのノード管理方法が、上述したノード管理装置４００の動作ステップを含んでもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムが提供されてもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムを記憶した非一時的なコンピュータ読取可能な記憶媒体が提供されてもよい。加えて、第１、第２及び第３の実施形態において説明した任意の機能又は処理が本実施形態に適用されてよい。

＜＜６．まとめ＞＞
ここまで、図１～図２９を用いて本開示のいくつかの実施形態について詳細に説明した。上述した実施形態では、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理装置を識別する代替識別情報が、放送信号処理ノードを識別するノード識別情報に代えて、当該放送信号処理ノードの識別情報として外部装置へ通知される。そして、上記ノード管理装置は、放送信号処理ノードを制御するための制御メッセージであって、上記代替識別情報を宛て先として有する当該制御メッセージが外部装置から受信された場合に、当該制御メッセージを、少なくとも宛て先を上記代替識別情報から上記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを当該放送信号処理ノードへ送信する。それにより、放送局システムのネットワークに放送信号を処理する多様なノードが存在する状況においても、それらノードの一元的な管理又は制御を効率的に行うことが可能となる。

ある実施形態では、上記ノード管理装置及び外部装置は、制御メッセージの宛て先部分で制御対象ノードを識別することを要する共通ＡＰＩをサポートし、上記制御メッセージは、当該ＡＰＩを用いて外部装置から受信され得る。したがって、外部装置はこの共通ＡＰＩのみをサポートすればよく、異なる種類の制御ＡＰＩをサポートする放送信号処理ノードがシステムに追加されたとしても外部装置の改変は不要である。また、共通ＡＰＩをサポートする放送信号処理ノードが制御対象である場合、上記ノード管理装置は、宛て先部分に含まれる識別情報（例えば、ＩＰアドレス又はホスト名）を変換するのみで、制御メッセージを当該放送信号処理ノードへ中継することができる。

ある実施形態では、外部装置から受信される上記制御メッセージは、制御対象のセンダ又はレシーバを識別する制御対象情報を含み得る。そして、データベースに登録されている、各放送信号処理ノードに属するセンダ又はレシーバを識別する登録情報に基づいて、制御メッセージの宛て先部分に含まれる上記代替識別情報がもとのノード識別情報へ置換され得る。かかる構成によれば、上述したように放送信号処理ノードを識別するノード識別情報に代えて代替識別情報が外部装置へ通知されるとしても、制御メッセージの内容からもとのノード識別情報を容易に特定することができる。

なお、本開示に係る技術は、上述した実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、並びに、本開示のスコープ及び精神から逸脱することなく様々な変形が可能であるということが、当業者に理解されるであろう。

例えば、フローチャートに示した処理ステップは、必ずしも図示した順序通りに実行されなくてもよい。例えば、処理ステップは図示した順序とは異なる順序で実行されてもよく、２つ以上の処理ステップが並列的に実行されてもよい。また、一部の処理ステップが削除されてもよく、さらなる処理ステップが追加されてもよい。

また、本明細書において説明した装置の機能は、ソフトウェア、ハードウェア、及びソフトウェアとハードウェアとの組み合わせのいずれで実現されてもよい。ソフトウェアを構成するコンピュータプログラムのプログラム命令は、例えば、各装置の内部又は外部のコンピュータ読取可能な記憶媒体において記憶され、実行時にメモリへ読み込まれてプロセッサにより実行される。

上記実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

（付記１）
放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理装置であって、
前記放送信号処理ノードを識別するノード識別情報に代えて、前記ノード管理装置を識別する代替識別情報が前記放送信号処理ノードの識別情報として外部装置へ通知され、
前記ノード管理装置は、前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージが前記外部装置から受信された場合に、前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを前記放送信号処理ノードへ送信する制御部、を備える、
ノード管理装置。

（付記２）
前記ノード管理装置及び前記外部装置は、制御メッセージの宛て先部分で制御対象ノードを識別することを要するアプリケーションプロトコルインタフェースをサポートし、
前記制御部は、前記アプリケーションプロトコルインタフェースを用いて、前記制御メッセージを前記外部装置から受信する、
付記１に記載のノード管理装置。

（付記３）
前記制御部は、前記アプリケーションプロトコルインタフェースをサポートする第１の放送信号処理ノードを前記制御対象ノードとして識別する第１制御メッセージが前記外部装置から受信された場合に、前記第１制御メッセージの宛て先を前記第１の放送信号処理ノードを識別するノード識別情報へ置換することにより前記第１制御メッセージを変換して、変換後の第１制御メッセージを前記第１の放送信号処理ノードへ送信する、付記２に記載のノード管理装置。

（付記４）
前記制御部は、前記アプリケーションプロトコルインタフェースをサポートしない第２の放送信号処理ノードを前記制御対象ノードとして識別する第２制御メッセージが前記外部装置から受信された場合に、前記第２制御メッセージを前記第２の放送信号処理ノードによりサポートされる形式のメッセージへ変換して、変換後の第２制御メッセージを前記第２の放送信号処理ノードへ送信する、付記２又は付記３に記載のノード管理装置。

（付記５）
前記外部装置から受信される前記制御メッセージは、制御対象のセンダ又はレシーバを識別する制御対象情報を含み、
前記制御部は、データベースに登録されている、各放送信号処理ノードに属するセンダ又はレシーバを識別する登録情報に基づいて、前記制御メッセージの前記宛て先部分に含まれる前記代替識別情報を前記ノード識別情報へ置換する、
付記２～４のいずれか１項に記載のノード管理装置。

（付記６）
前記登録情報は、各放送信号処理ノードに属するセンダ又はレシーバを識別するＵＵＩＤ（Universally Unique Identifier）を含む、付記５に記載のノード管理装置。

（付記７）
前記制御メッセージは、ＨＴＴＰ（Hypertext Transfer Protocol）メッセージである、付記２～６のいずれか１項に記載のノード管理装置。

（付記８）
前記宛て先部分は、前記ＨＴＴＰメッセージのホスト部分であり、前記ノード識別情報は、前記放送信号処理ノードのＩＰアドレス又はホスト名であり、前記代替識別情報は、前記ノード管理装置のＩＰアドレス又はホスト名である、付記７に記載のノード管理装置。

（付記９）
前記制御部は、データベースに登録されている、各放送信号処理ノードが前記アプリケーションプロトコルインタフェースをサポートするか否かを示すノード種別情報に基づいて、前記制御メッセージをどのように変換すべきか判定する、付記２～８のいずれか１項に記載のノード管理装置。

（付記１０）
前記アプリケーションプロトコルインタフェースは、ＮＭＯＳ（Networked Media Open Specifications）インタフェースである、付記２～９のいずれか１項に記載のノード管理装置。

（付記１１）
放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理方法であって、
前記放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置を識別する代替識別情報を前記放送信号処理ノードの識別情報として外部装置へ通知することと、
前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージを前記外部装置から受信することと、
前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを前記放送信号処理ノードへ送信することと、
を含むノード管理方法。

（付記１２）
ノード管理装置のプロセッサに、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するための処理を実行させるコンピュータプログラムであって、
前記放送信号処理ノードを識別するノード識別情報に代えて、前記ノード管理装置を識別する代替識別情報が前記放送信号処理ノードの識別情報として外部装置へ通知され、
前記処理は、前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージが前記外部装置から受信された場合に、前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを前記放送信号処理ノードへ送信すること、を含む、
コンピュータプログラム。

（付記１３）
ノード管理装置のプロセッサに、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するための処理を実行させるコンピュータプログラム、を記憶した非一時的なコンピュータ読取可能な記憶媒体であって、
前記放送信号処理ノードを識別するノード識別情報に代えて、前記ノード管理装置を識別する代替識別情報が前記放送信号処理ノードの識別情報として外部装置へ通知され、
前記処理は、前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージが前記外部装置から受信された場合に、前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを前記放送信号処理ノードへ送信すること、を含む、
非一時的なコンピュータ読取可能な記憶媒体。

本開示に係る技術は、限定ではないものの、ＩＰネットワークを含む放送局システムにおいて利用可能である。

１ 放送局システム
１０ ＩＰドメイン
１２ ネットワーク装置
１４，２２ カメラ
１６，３４ モニタ
２０ａ，２０ｂ ＩＰゲートウェイ
２４ マイクロフォン
２６ データサーバ
３０（３０ａ～ｆ） 放送信号処理ノード
３２ 統合プレイアウト
６０（６０ａ～ｄ） センダ
６２ デバイス
７０（７０ａ～ｃ） レシーバ
８１（８１ａ～ｄ） ストリーム制御メッセージ
８６ 宛て先部分（ホスト部分）
１００，２００，３００，４００ ノード管理装置
４０５ データベース装置
１１０，２１０，３１０ 処理部
１２０，２２０，３２０，４２０ 記憶部
１３０，２３０ 登録ノード情報
１４０ 登録センダ情報
１４５ 登録レシーバ情報
１５０ 通信インタフェース
１６０，２６０，３６０，４６０ ノード情報管理部
１７０，２７０，３７０，４７０ ストリーム制御部

Claims (7)

1. 放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理装置であって、
   前記放送信号処理ノードを識別するノード識別情報に代えて、前記ノード管理装置を識別する代替識別情報を、前記放送信号処理ノードの識別情報として外部装置へ通知しており、
   前記ノード管理装置は、
   前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージを前記外部装置から受信した場合に、
   前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換し、
   変換後の制御メッセージを前記放送信号処理ノードへ送信する制御部、を備え、
   前記ノード管理装置及び前記外部装置は、前記制御メッセージの宛て先部分で制御対象ノードを識別することを要するアプリケーションプロトコルインタフェースをサポートし、
   前記制御部は、
   前記アプリケーションプロトコルインタフェースを用いて、前記制御メッセージを前記外部装置から受信し、
   前記制御対象ノードが、前記アプリケーションプロトコルインタフェースをサポートする第１の放送信号処理ノードであるか、前記アプリケーションプロトコルインタフェースをサポートしない第２の放送信号処理ノードであるかを判断し、
   前記アプリケーションプロトコルインタフェースをサポートする第１の放送信号処理ノードを前記制御対象ノードとして識別する第１制御メッセージを前記外部装置から受信した場合に、前記第１制御メッセージの宛て先を前記第１の放送信号処理ノードを識別するノード識別情報へ置換することにより前記第１制御メッセージを変換して、変換後の第１制御メッセージを前記第１の放送信号処理ノードへ送信し、
   前記アプリケーションプロトコルインタフェースをサポートしない第２の放送信号処理ノードを前記制御対象ノードとして識別する第２制御メッセージを前記外部装置から受信した場合に、前記第２制御メッセージを前記第２の放送信号処理ノードによりサポートされる形式のメッセージへ変換して、変換後の第２制御メッセージを前記第２の放送信号処理ノードへ送信する、
   ノード管理装置。
2. 前記外部装置から受信する前記制御メッセージは、制御対象のセンダ又はレシーバを識別する制御対象情報を含み、
   前記制御部は、データベースに登録されている、各前記放送信号処理ノードに属するセンダ又はレシーバを識別する登録情報に基づいて、前記制御メッセージの前記宛て先部分に含まれる前記代替識別情報を前記ノード識別情報へ置換する、
   請求項１に記載のノード管理装置。
3. 前記制御メッセージは、ＨＴＴＰ（Hypertext Transfer Protocol）メッセージである、請求項１又は２に記載のノード管理装置。
4. 前記制御部は、データベースに登録されている、各前記放送信号処理ノードが前記アプリケーションプロトコルインタフェースをサポートするか否かを示すノード種別情報に基づいて、前記制御メッセージをどのように変換すべきか判定する、請求項１乃至３のいずれか１項に記載のノード管理装置。
5. 前記アプリケーションプロトコルインタフェースは、ＮＭＯＳ（Networked Media Open Specifications）インタフェースである、請求項１乃至４のいずれか１項に記載のノード管理装置。
6. 放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理方法であって、
   前記放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置を識別する代替識別情報を前記放送信号処理ノードの識別情報として外部装置へ通知することと、
   前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージを前記外部装置から受信することと、
   前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを前記放送信号処理ノードへ送信することと、
   を含み、
   前記ノード管理装置及び前記外部装置により、前記制御メッセージの宛て先部分で制御対象ノードを識別することを要するアプリケーションプロトコルインタフェースがサポートされ、
   前記送信することは、
   前記アプリケーションプロトコルインタフェースを用いて、前記制御メッセージを前記外部装置から受信することと、
   前記制御対象ノードが、前記アプリケーションプロトコルインタフェースをサポートする第１の放送信号処理ノードであるか、前記アプリケーションプロトコルインタフェースをサポートしない第２の放送信号処理ノードであるかを判断することと、
   前記アプリケーションプロトコルインタフェースをサポートする第１の放送信号処理ノードを前記制御対象ノードとして識別する第１制御メッセージを前記外部装置から受信した場合に、前記第１制御メッセージの宛て先を前記第１の放送信号処理ノードを識別するノード識別情報へ置換することにより前記第１制御メッセージを変換して、変換後の第１制御メッセージを前記第１の放送信号処理ノードへ送信することと、
   前記アプリケーションプロトコルインタフェースをサポートしない第２の放送信号処理ノードを前記制御対象ノードとして識別する第２制御メッセージを前記外部装置から受信した場合に、前記第２制御メッセージを前記第２の放送信号処理ノードによりサポートされる形式のメッセージへ変換して、変換後の第２制御メッセージを前記第２の放送信号処理ノードへ送信することとを含むノード管理方法。
7. ノード管理装置のプロセッサに、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するための処理を実行させるコンピュータプログラムであって、
   前記放送信号処理ノードを識別するノード識別情報に代えて、前記ノード管理装置を識別する代替識別情報を、前記放送信号処理ノードの識別情報として外部装置へ通知しており、
   前記処理は、
   前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージを前記外部装置から受信した場合に、
   前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換し、
   変換後の制御メッセージを前記放送信号処理ノードへ送信すること、を含み、
   前記ノード管理装置及び前記外部装置により、前記制御メッセージの宛て先部分で制御対象ノードを識別することを要するアプリケーションプロトコルインタフェースがサポートされ、
   前記送信することは、
   前記アプリケーションプロトコルインタフェースを用いて、前記制御メッセージを前記外部装置から受信することと、
   前記制御対象ノードが、前記アプリケーションプロトコルインタフェースをサポートする第１の放送信号処理ノードであるか、前記アプリケーションプロトコルインタフェースをサポートしない第２の放送信号処理ノードであるかを判断することと、
   前記アプリケーションプロトコルインタフェースをサポートする第１の放送信号処理ノードを前記制御対象ノードとして識別する第１制御メッセージを前記外部装置から受信した場合に、前記第１制御メッセージの宛て先を前記第１の放送信号処理ノードを識別するノード識別情報へ置換することにより前記第１制御メッセージを変換して、変換後の第１制御メッセージを前記第１の放送信号処理ノードへ送信することと、
   前記アプリケーションプロトコルインタフェースをサポートしない第２の放送信号処理ノードを前記制御対象ノードとして識別する第２制御メッセージを前記外部装置から受信した場合に、前記第２制御メッセージを前記第２の放送信号処理ノードによりサポートされる形式のメッセージへ変換して、変換後の第２制御メッセージを前記第２の放送信号処理ノードへ送信することとを含む、
   コンピュータプログラム。

Images