(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-09-11
(45)【発行日】2023-09-20
(54)【発明の名称】ノード管理装置、ノード管理方法及びプログラム
(51)【国際特許分類】
H04L 12/66 20060101AFI20230912BHJP
H04N 21/237 20110101ALI20230912BHJP
H04L 45/74 20220101ALI20230912BHJP
H04H 60/04 20080101ALI20230912BHJP
H04L 43/00 20220101ALI20230912BHJP
H04H 60/35 20080101ALI20230912BHJP
【FI】
H04L12/66
H04N21/237
H04L45/74
H04H60/04
H04L43/00
H04H60/35
(21)【出願番号】P 2019014597
(22)【出願日】2019-01-30
【審査請求日】2021-12-14
(73)【特許権者】
【識別番号】000227205
【氏名又は名称】NECプラットフォームズ株式会社
(74)【代理人】
【識別番号】100141519
【氏名又は名称】梶田 邦之
(72)【発明者】
【氏名】篠原 隆
(72)【発明者】
【氏名】奥野 義幸
(72)【発明者】
【氏名】鹿島 敏満
【審査官】中川 幸洋
(56)【参考文献】
【文献】特開2009-147900(JP,A)
【文献】特開2008-017122(JP,A)
【文献】国際公開第2014/142278(WO,A1)
【文献】小山 智史 Tomofumi KOYAMA,AMWA IS-04を利用した番組制作設備共有機能の実装,映像情報メディア学会 2017年年次大会講演予稿集 [CD-ROM] 映像情報メディア学会2017年年次大会講演予稿集 PROCEEDINGS OF THE 2017 ITE ANNUAL CONVENTION PROCEEDINGS OF THE 2017 ITE ANNUAL CONVENTION,2017年09月01日
【文献】Robert Porter and Gareth Sylvester-Bradley,Scalability and Performance of the AMWA IS-04 and IS-05 NMOS Specifications for Networked Media,SMPTE 2018,2018年10月22日
(58)【調査した分野】(Int.Cl.,DB名)
H04L 12/66
H04N 21/237
H04L 45/74
H04H 60/04
H04L 43/00
H04H 60/35
(57)【特許請求の範囲】
【請求項1】
放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理装置であって、
前記放送信号処理ノードを識別するノード識別情報に代えて、前記ノード管理装置を識別する代替識別情報を、前記放送信号処理ノードの識別情報として外部装置へ通知しており、
前記ノード管理装置は、
前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージを前記外部装置から受信した場合に、
前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換し、
変換後の制御メッセージを前記放送信号処理ノードへ送信する制御部、を備え
、
前記ノード管理装置及び前記外部装置は、前記制御メッセージの宛て先部分で制御対象ノードを識別することを要するアプリケーションプロトコルインタフェースをサポートし、
前記制御部は、
前記アプリケーションプロトコルインタフェースを用いて、前記制御メッセージを前記外部装置から受信し、
前記制御対象ノードが、前記アプリケーションプロトコルインタフェースをサポートする第1の放送信号処理ノードであるか、前記アプリケーションプロトコルインタフェースをサポートしない第2の放送信号処理ノードであるかを判断し、
前記アプリケーションプロトコルインタフェースをサポートする第1の放送信号処理ノードを前記制御対象ノードとして識別する第1制御メッセージを前記外部装置から受信した場合に、前記第1制御メッセージの宛て先を前記第1の放送信号処理ノードを識別するノード識別情報へ置換することにより前記第1制御メッセージを変換して、変換後の第1制御メッセージを前記第1の放送信号処理ノードへ送信し、
前記アプリケーションプロトコルインタフェースをサポートしない第2の放送信号処理ノードを前記制御対象ノードとして識別する第2制御メッセージを前記外部装置から受信した場合に、前記第2制御メッセージを前記第2の放送信号処理ノードによりサポートされる形式のメッセージへ変換して、変換後の第2制御メッセージを前記第2の放送信号処理ノードへ送信する、
ノード管理装置。
【請求項2】
前記外部装置から受信する前記制御メッセージは、制御対象のセンダ又はレシーバを識別する制御対象情報を含み、
前記制御部は、データベースに登録されている、各前記放送信号処理ノードに属するセンダ又はレシーバを識別する登録情報に基づいて、前記制御メッセージの前記宛て先部分に含まれる前記代替識別情報を前記ノード識別情報へ置換する、
請求項
1に記載のノード管理装置。
【請求項3】
前記制御メッセージは、HTTP(Hypertext Transfer Protocol)メッセージである、請求項
1又は2に記載のノード管理装置。
【請求項4】
前記制御部は、データベースに登録されている、各前記放送信号処理ノードが前記アプリケーションプロトコルインタフェースをサポートするか否かを示すノード種別情報に基づいて、前記制御メッセージをどのように変換すべきか判定する、請求項
1乃至3のいずれか1項に記載のノード管理装置。
【請求項5】
前記アプリケーションプロトコルインタフェースは、NMOS(Networked Media Open Specifications)インタフェースである、請求項
1乃至4のいずれか1項に記載のノード管理装置。
【請求項6】
放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理方法であって、
前記放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置を識別する代替識別情報を前記放送信号処理ノードの識別情報として外部装置へ通知することと、
前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージを前記外部装置から受信することと、
前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを前記放送信号処理ノードへ送信することと、
を含
み、
前記ノード管理装置及び前記外部装置により、前記制御メッセージの宛て先部分で制御対象ノードを識別することを要するアプリケーションプロトコルインタフェースがサポートされ、
前記送信することは、
前記アプリケーションプロトコルインタフェースを用いて、前記制御メッセージを前記外部装置から受信することと、
前記制御対象ノードが、前記アプリケーションプロトコルインタフェースをサポートする第1の放送信号処理ノードであるか、前記アプリケーションプロトコルインタフェースをサポートしない第2の放送信号処理ノードであるかを判断することと、
前記アプリケーションプロトコルインタフェースをサポートする第1の放送信号処理ノードを前記制御対象ノードとして識別する第1制御メッセージを前記外部装置から受信した場合に、前記第1制御メッセージの宛て先を前記第1の放送信号処理ノードを識別するノード識別情報へ置換することにより前記第1制御メッセージを変換して、変換後の第1制御メッセージを前記第1の放送信号処理ノードへ送信することと、
前記アプリケーションプロトコルインタフェースをサポートしない第2の放送信号処理ノードを前記制御対象ノードとして識別する第2制御メッセージを前記外部装置から受信した場合に、前記第2制御メッセージを前記第2の放送信号処理ノードによりサポートされる形式のメッセージへ変換して、変換後の第2制御メッセージを前記第2の放送信号処理ノードへ送信することとを含むノード管理方法。
【請求項7】
ノード管理装置のプロセッサに、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するための処理を実行させるコンピュータプログラムであって、
前記放送信号処理ノードを識別するノード識別情報に代えて、前記ノード管理装置を識別する代替識別情報を、前記放送信号処理ノードの識別情報として外部装置へ通知しており、
前記処理は、
前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージを前記外部装置から受信した場合に、
前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換し、
変換後の制御メッセージを前記放送信号処理ノードへ送信すること、を含
み、
前記ノード管理装置及び前記外部装置により、前記制御メッセージの宛て先部分で制御対象ノードを識別することを要するアプリケーションプロトコルインタフェースがサポートされ、
前記送信することは、
前記アプリケーションプロトコルインタフェースを用いて、前記制御メッセージを前記外部装置から受信することと、
前記制御対象ノードが、前記アプリケーションプロトコルインタフェースをサポートする第1の放送信号処理ノードであるか、前記アプリケーションプロトコルインタフェースをサポートしない第2の放送信号処理ノードであるかを判断することと、
前記アプリケーションプロトコルインタフェースをサポートする第1の放送信号処理ノードを前記制御対象ノードとして識別する第1制御メッセージを前記外部装置から受信した場合に、前記第1制御メッセージの宛て先を前記第1の放送信号処理ノードを識別するノード識別情報へ置換することにより前記第1制御メッセージを変換して、変換後の第1制御メッセージを前記第1の放送信号処理ノードへ送信することと、
前記アプリケーションプロトコルインタフェースをサポートしない第2の放送信号処理ノードを前記制御対象ノードとして識別する第2制御メッセージを前記外部装置から受信した場合に、前記第2制御メッセージを前記第2の放送信号処理ノードによりサポートされる形式のメッセージへ変換して、変換後の第2制御メッセージを前記第2の放送信号処理ノードへ送信することとを含む、
コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ノード管理装置、ノード管理方法及びプログラムに関する。
【背景技術】
【0002】
既存の放送局の多くは、放送信号のストリームを局内で伝送するための専用ネットワークを有している。放送信号は、例えば、映像、音声及び補助(ancillary)データといった放送素材を搬送する。専用ネットワークには、例えば、カメラ及びマイクロフォンといったキャプチャデバイス、コンテンツデータを蓄積するストレージサーバ、コンテンツを再生する再生デバイス、及び伝送される信号の形式を変換するゲートウェイデバイスといった、様々な装置が接続される。専用ネットワーク上での放送信号ストリームの伝送のための信号形式として、SDI(Serial Digital Interface)がこれまで広く利用されている。
【0003】
しかし、近年のIP(Internet Protocol)技術の目覚ましい性能の向上の結果、放送事業者は、より汎用性の高いIP技術を活用することにメリットを見出し、局内のネットワークをIPネットワークへ更新する取り組みを開始した。IPベースのネットワークアーキテクチャを採用すれば、例えば、汎用のルータ及びスイッチといったネットワーク装置を用いて高速かつ大容量のネットワークを低コストで構築することが可能となる。
【0004】
IP化が進展すれば、放送局システムのネットワークに多様な装置が接続されることが予期される。そうした多様な装置の間の相互運用性を確保するために、AMWA(Advanced Media Workflow Association)は、装置間のストリームの伝送を管理し及び制御するための制御インタフェース規格の集合であるNMOS(Networked Media Open Specifications)規格の策定を進めている。例えば、NMOS IS-04は、ネットワークリソースの発見及び登録(Discovery and Registration)のための制御インタフェース規格である(非特許文献1参照)。NMOS IS-05は、デバイスの接続管理(Device Connection Management)のための制御インタフェース規格である(非特許文献2参照)。NMI(Network Media Interface)及びMessagePack-RPCは、ストリーム伝送制御のための、NMOSとは異なる制御インタフェース規格の例である。ネットワーク装置を製造する製造者が独自の制御インタフェースを開発することもある。
【先行技術文献】
【非特許文献】
【0005】
【文献】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/>
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、これまでになされてきたストリーム伝送制御用の制御インタフェースに関する提案は、放送信号を処理する多様なノードを制御する制御側の装置の実装を適切に考慮したものではなかった。例えば、放送局内に種類の異なる制御インタフェースをサポートする複数の放送信号処理ノードが存在する場合、種類の異なる制御インタフェースの全てを実装した制御装置が無ければ、そうした多様なノードを一元的に管理し又は制御することができない。また、NMOS IS-05によれば、伝送制御のための制御メッセージは、制御端末と放送信号処理ノードとの間で直接的に交換される。しかし、放送局システム内には通常、複数の制御端末が存在するため、NMOS IS-05のような分散的なやり方は、やはり多様なノードの一元的な管理又は制御には適さない。
【0007】
上述した課題のうちの少なくとも1つに対処するために、本開示は、放送局内の多様な放送信号処理ノードの管理又は制御を効率化するための仕組みを提供することを目的とする。
【課題を解決するための手段】
【0008】
ある観点によれば、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理装置が提供される。上記放送信号処理ノードを識別するノード識別情報に代えて、上記ノード管理装置を識別する代替識別情報が上記放送信号処理ノードの識別情報として外部装置へ通知される。上記ノード管理装置は、上記放送信号処理ノードを制御するための制御メッセージであって、上記代替識別情報を宛て先として有する当該制御メッセージが上記外部装置から受信された場合に、上記制御メッセージを、少なくとも宛て先を上記代替識別情報から上記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを上記放送信号処理ノードへ送信する制御部、を備える。
【0009】
また別の観点によれば、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理方法が提供される。当該ノード管理方法は、上記放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置を識別する代替識別情報を上記放送信号処理ノードの識別情報として外部装置へ通知することと、上記放送信号処理ノードを制御するための制御メッセージであって、上記代替識別情報を宛て先として有する当該制御メッセージを上記外部装置から受信することと、上記制御メッセージを、少なくとも宛て先を上記代替識別情報から上記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを上記放送信号処理ノードへ送信することと、を含む。
【0010】
また別の観点によれば、上記ノード管理装置の処理をプロセッサに実行させるコンピュータプログラムが提供されてもよい。上記コンピュータプログラムを記憶した非一時的なコンピュータ読取可能な記憶媒体が提供されてもよい。
【発明の効果】
【0011】
本開示に係る技術によれば、放送局内の多様な放送信号処理ノードの管理又は制御を効率化することが可能となる。なお、本開示に係る技術により、当該効果の代わりに、又は当該効果とともに、他の効果が奏されてもよい。
【図面の簡単な説明】
【0012】
【
図1】本開示の実施形態に係る放送局システムの構成の一例を示す概略図である。
【
図2】本開示の実施形態に係る放送局システムのIPドメインの論理的な構成の一例について説明するための説明図である。
【
図3】HTTPを用いて送信される既存のノード登録メッセージの一例について説明するための説明図である。
【
図4】HTTPを用いて送信される既存のセンダ登録メッセージの一例について説明するための説明図である。
【
図5】HTTPを用いて送信される既存のレシーバ登録メッセージの一例について説明するための説明図である。
【
図6】HTTPを用いて送信される既存のストリーム制御メッセージの一例について説明するための説明図である。
【
図7】異なる種類の制御インタフェースをサポートする複数の放送信号処理ノードが存在する状況について説明するための第1の説明図である。
【
図8】異なる種類の制御インタフェースをサポートする複数の放送信号処理ノードが存在する状況について説明するための第2の説明図である。
【
図9】単一の種類の制御インタフェースをサポートする放送信号処理ノードしか存在しないものの、システム内に複数の制御端末が存在する状況について説明するための説明図である。
【
図10】本開示の実施形態の基本的な原理について説明するための説明図である。
【
図11】第1の実施形態に係るノード管理装置の構成の一例を示すブロック図である。
【
図12】第1の実施形態に係るノード管理装置により管理される情報の構成の一例について説明するための説明図である。
【
図13】ノード登録メッセージにおけるノード識別情報の置換について説明するための説明図である。
【
図14】外部装置から放送信号処理ノードへ送信される制御メッセージにおける宛て先の置換について説明するための説明図である。
【
図15】第1の実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。
【
図16】第1の実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。
【
図17】第1の実施形態における管理及び制御の一元化について説明するための説明図である。
【
図18】第2の実施形態に係るノード管理装置の構成の一例を示すブロック図である。
【
図19】第2の実施形態に係るノード管理装置により管理される情報の構成の一例について説明するための説明図である。
【
図20】ノード登録メッセージにおけるノード識別情報の置換及びメッセージ形式の変換について説明するための説明図である。
【
図21】外部装置から放送信号処理ノードへ送信される制御メッセージのメッセージ変換について説明するための説明図である。
【
図22】第2の実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。
【
図23】第2の実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。
【
図24】第2の実施形態における管理及び制御の一元化について説明するための説明図である。
【
図25】第3の実施形態に係るノード管理装置の構成の一例を示すブロック図である。
【
図26】第3の実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。
【
図27】第3の実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。
【
図28】第3の実施形態における管理及び制御の一元化について説明するための説明図である。
【
図29】第4の実施形態に係るノード管理装置の構成の一例を示すブロック図である。
【発明を実施するための形態】
【0013】
以下、添付の図面を参照して本開示に係る技術の実施形態を詳細に説明する。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。
【0014】
説明は、以下の順序で行われる。
1.概要
1-1.システム構成例
1-2.HTTPベースの制御メッセージの例
1-3.課題の説明
1-4.基本的な原理
2.第1の実施形態
2-1.ノード管理装置の構成例
2-2.処理の流れ
2-3.利点
3.第2の実施形態
3-1.ノード管理装置の構成例
3-2.処理の流れ
3-3.利点
4.第3の実施形態
4-1.ノード管理装置の構成例
4-2.処理の流れ
4-3.利点
5.第4の実施形態
6.まとめ
【0015】
<<1.概要>>
<1-1.システム構成例>
まず、
図1を用いて、本開示のいくつかの実施形態が適用され得る放送局システムの概要について説明する。
図1は、本開示の実施形態に係る放送局システム1の構成の一例を示す概略図である。
図1を参照すると、放送局システム1は、1つ以上のネットワーク装置12、カメラ14、モニタ16、IPゲートウェイ20a、IPゲートウェイ20b、カメラ22、マイクロフォン24、データサーバ26、統合プレイアウト(Integrated Playout)32、モニタ34、APS(Automatic Program control System)40及び制御端末50を含む。ネットワーク装置12、カメラ14、モニタ16、IPゲートウェイ20a、IPゲートウェイ20b、APS40、及び制御端末50は、IPドメイン10に属する。
【0016】
(1)様々な装置の説明
ネットワーク装置12は、IPネットワークにおけるストリームの転送を担当する装置である。ネットワーク装置12の各々は、例えばルータ、スイッチ、ブリッジ又はリピータなど、いかなる種類のネットワーク装置であってもよい。ネットワーク装置12の各々は、低コストで導入可能な汎用品(COTS(Commercial Off-The-Shelf)ともいう)であってもよい。
図1には6つのネットワーク装置12が示されているが、かかる例に限定されず、放送局システム1はいくつのネットワーク装置12を含んでもよい。IPドメイン10は、単一のネットワークで構成されてもよく、又は複数のサブネットワークを含んでもよい。
【0017】
カメラ14は、放送素材を生成するキャプチャデバイスの一種である。例えば、カメラ14は、何らかの対象を撮影して、映像データを生成する。カメラ14は、内蔵されるマイクロフォンを通じて音声を取得して、音声データを生成してもよい。カメラ14は、IPドメイン10に属し、映像データ及び音声データのデータストリームを一連のIPパケットへパケット化してIPネットワークへ送信することができる。
【0018】
モニタ16は、放送素材を受信してコンテンツを再生する再生デバイスの一種である。例えば、モニタ16は、映像データを受信して映像を再生する。モニタ16は、音声データを受信して音声を再生してもよい。モニタ16は、追加的に伝送される補助データを受信して、補助データを処理(例えば、字幕を再生)してもよい。モニタ16は、コンテンツを編集するための編集機能をユーザへ提供してもよい。モニタ16は、IPドメイン10へ属し、IPネットワーク上で転送されて来る一連のIPパケットを受信することができる。
【0019】
IPゲートウェイ20aは、IPドメイン10と他の信号ドメインとの境界に位置するゲートウェイデバイスである。IPゲートウェイ20aは、1つ又は複数のネットワーク装置12へ接続する。
図1の例において、IPゲートウェイ20aには、カメラ22、マイクロフォン24及びデータサーバ26がさらに接続されている。例えば、IPゲートウェイ20aは、映像データを搬送するSDI信号をカメラ22から受信し得る。また、IPゲートウェイ20aは、音声データを搬送するSDI信号をマイクロフォン24から受信し得る。また、IPゲートウェイ20aは、映像データ、音声データ及び補助データのうちの1つ以上を搬送するSDI信号をデータサーバ26から受信し得る。なお、IPドメイン10の外部で伝送される信号の信号形式は、例えばSD-SDI、HD-SDI、3G-SDI、6G-SDI若しくは12G-SDIといったSDIの任意の派生であってもよく、又は、SDI以外の信号形式であってもよい。IPゲートウェイ20aは、上述したようにカメラ22、マイクロフォン24及びデータサーバ26から受信される放送素材を搬送する信号を、必要に応じて多重化し又は逆多重化した後、一連のIPパケットへパケット化してIPネットワークへ送信することができる。
【0020】
IPゲートウェイ20bもまた、IPドメイン10と他の信号ドメインとの境界に位置するゲートウェイデバイスである。IPゲートウェイ20bは、1つ又は複数のネットワーク装置12へ接続する。
図1の例では、IPゲートウェイ20bには、統合プレイアウト32及びモニタ34がさらに接続されている。例えば、IPゲートウェイ20bは、IPネットワーク上で転送されて来るIPパケットを受信し、それらIPパケットをSDI信号(又は他の信号形式の信号)へ変換して、統合プレイアウト32及びモニタ34の一方又は双方へ送信することができる。なお、当然ながら、IPゲートウェイ20aがIPゲートウェイ20bと同様にIPパケットをSDI信号へ変換する機能を有していてもよい。また、IPゲートウェイ20bがIPゲートウェイ20aと同様にSDI信号をIPパケットへ変換する機能を有していてもよい。
【0021】
APS40は、予め決定されるスケジュールに従って、テレビジョン番組の放送を進行させるシステムである。例えば、APS40は、IPネットワークへ制御メッセージを送信して、所定の時刻に所与の送信元(例えば、カメラ及びマイクロフォン、又はデータサーバ)から出力されるデータストリームを統合プレイアウト32へ伝送させる。データストリームを受信した統合プレイアウト32は、放送局の回線を通じてアンテナへテレビジョン番組の放送信号を送出する。データストリームは、例えばモニタ16又はモニタ34にも配信され、放送局内でも放送コンテンツが再生され得る。
【0022】
制御端末50は、放送局システム1に含まれるノードの管理及び制御に関連するユーザインタフェースをユーザへ提供する端末装置である。制御端末50は、放送局システム1に専用のユーザ端末であってもよく、又はPC(Personal Computer)若しくはスマートフォンといった汎用的な端末であってもよい。制御端末50は、例えば、放送局内のネットワーク上でのストリームの送信又は受信に関与するノードに関連する情報のうちユーザにより設定可能な情報を、ユーザインタフェースを介して取得する。そして、制御端末50は、取得した情報をシステム内のデータベースへ登録する。また、制御端末50は、例えば、ユーザインタフェースを介して所与のノード間のストリームの伝送を求めるリクエストを受け付ける。
【0023】
本明細書において、放送信号を何らかの形で処理するノードを、放送信号処理ノードという。上述したネットワーク装置12、カメラ14、モニタ16、IPゲートウェイ20a、IPゲートウェイ20b、カメラ22、マイクロフォン24、データサーバ26、統合プレイアウト32、モニタ34及びAPS40は、放送信号処理ノードの例である。放送信号の処理とは、例えば、放送信号を送信し、転送し、受信し、符号化し、復号し、キャプチャし、再生し又は変換することを含む。
【0024】
(2)IPマルチキャスト
放送局システム1のIPドメイン10内の放送信号ストリームの伝送は、典型的には、マルチキャストで行われる。マルチキャストされるパケットの送信元IPアドレスは送信ノードのIPアドレスであり、宛て先IPアドレスは特定のアドレス範囲に属するマルチキャストアドレスである。個々のマルチキャストアドレスを宛て先とするマルチキャストパケットを受信するノードの集合をマルチキャストグループといい、マルチキャストアドレスをグループアドレスともいう。あるストリームを受信することを意図する受信ノードは、そのストリームに対応するマルチキャストグループへの加入(join)を通知するメッセージ(例えば、IGMP(Internet Group Management Protocol) JOIN)を近傍のルータへ送信する。すると、ルータ間でマルチキャストツリーを更新するためのメッセージ交換が行われ、特定の送信ノードから送信されるストリームがIPネットワークを介して受信ノードへ配信されるようになる。受信ノードは、マルチキャストストリームの受信を終了する際には、マルチキャストグループからの離脱(leave)を通知するメッセージを近傍のルータへ送信する。なお、上述した例に限定されず、本開示に係る技術は、ストリームがユニキャストで伝送されるケースにも適用可能である。
【0025】
(3)エッセンスとストリーム
上述したように、テレビジョン番組のコンテンツは、概して、映像データ、音声データ及び補助データという3種類の放送素材のデータから構成される。本明細書では、放送素材の種類を区別してこれらコンテンツの構成要素へ言及するために、「エッセンス」との語を用いる。言い換えると、エッセンスは、データとして表現された放送素材である。エッセンスをIPネットワーク上で伝送しようとする場合、エッセンスは、あるIPベースのプロトコルに従って、デジタル信号へ変換されパケット化される。エッセンスを搬送する一連のIPパケットには、ストリーム単位で共通するポート番号が付与される。即ち、ストリームは、IPアドレス及びポート番号が共通するIPパケットのシーケンスであり得る。
【0026】
(4)プロトコルごとのストリームタイプ
ストリーム伝送のためのプロトコルとしてSMPTE ST2022-6が利用される場合、このプロトコルはSDI信号をそのままIPパケットへマッピングすることから、単一のストリームに異なる種類のエッセンスが混在する。SMPTE ST2110シリーズが利用される場合、異なる種類のエッセンスは異なるストリームにより搬送され、したがって単一のストリームは単一の種類のエッセンスのみを含む。ARIB STD-B73が利用される場合、単一のストリームに異なる種類のエッセンスが混在するが、SDIイメージとは異なりブランキング期間は含まれない。いずれのプロトコルにおいても、パケットは、アプリケーションレイヤではRTP(Real-time Transport Protocol)、トランスポートレイヤではUDP(User Datagram Protocol)に従って伝送される。
【0027】
(5)IPドメインの論理的構成例
図2は、
図1に示した放送局システム1のIPドメイン10の論理的な構成の一例を示している(簡明さのために、ここではAPS40及び制御端末50は省略されている)。
図2を参照すると、カメラ14に相当する第1ノードは、センダ(sender)60aを含む。「センダ」とは、ストリームを送信する能力を有する機能エンティティである。IPゲートウェイ20aに相当する第2ノードは、センダ60b、60c及び60dを含む。センダ60b、60c及び60dは、IPゲートウェイ20aにより収容される個々のストリームの送信元の装置に相当し得る。モニタ16に相当する第3ノードは、レシーバ70aを含む。「レシーバ」とは、ストリームを受信する能力を有する機能エンティティである。IPゲートウェイ20bに相当する第4ノードは、レシーバ70b及び70cを含む。レシーバ70b及び70cは、IPゲートウェイ20bにより収容される個々のストリームの受信先の装置に相当し得る。
【0028】
上の説明から理解されるように、1つのノード(「カード」と呼ばれてもよい)は、1つの物理エンティティを表現する。
図1の例に限定されず、1つのノードは、機能エンティティとして、任意の数のセンダ及び/又は任意の数のレシーバを含んでよい。また、1つのノード内で複数の機能エンティティを包含する論理的な単位(例えば、図中の破線枠参照)が定義されてもよい(例えば、1つのIPゲートウェイに収容される1つのデバイスが複数のストリームを送信し又は受信するケース)。例えば、AMWAにより検討されているNMOSは、こうした論理的なシステムモデルを前提として、IPドメインでのストリームの伝送を管理し及び制御するための、HTTPベースのアプリケーションプロトコルインタフェース(API)の仕様を規定している。
【0029】
なお、本明細書において、センダ60a、60b、60c及び60dを互いに区別する必要が無い場合には、符号の末尾のアルファベットを省略することによりこれらをセンダ60と総称する。同様に、レシーバ70a、70b及び70cを互いに区別する必要が無い場合には、符号の末尾のアルファベットを省略することによりこれらをレシーバ70と総称する。
【0030】
<1-2.HTTPベースの制御メッセージの例>
次に、
図3~
図6を用いて、IPドメインでのストリームの伝送を管理し及び制御するための、既存のHTTPベースのAPIの制御メッセージのいくつかの例について説明する。
【0031】
(1)ノード登録メッセージ
図3は、HTTPを用いて送信される既存のノード登録メッセージの一例について説明するための説明図である。
図3に示したノード登録メッセージ51は、リクエストライン52、ヘッダ53及びメッセージボディ54を含む。
【0032】
リクエストライン52は、ホスト部分56及びパス部分57を含むURL(Uniform Resource Locator)を含む。ホスト部分56は、ノード登録メッセージ51の宛て先を識別する。したがって、ホスト部分56は、「宛て先部分」として言及されてもよい。
図3の例では、ノード登録メッセージ51の宛て先はホスト部分56においてIPアドレス「xxx.xxx.xxx.X」で識別されている。他の例では、メッセージの宛て先はホスト名で識別されてもよい。パス部分57は、ノード登録メッセージ51が準拠するAPIの規格及びそのバージョンを識別する。
図3の例では、ノード登録メッセージ51のパス部分57から、ノード登録メッセージ51がNMOS IS-04のバージョン1.2に準拠したリソース登録メッセージの一種であることが理解される。なお、
図3には示していないものの、リクエストライン52は、HTTPメソッド名(例えば、POST)及びHTTPバージョン番号といった他の情報をも含み得る。
【0033】
メッセージボディ54は、ノード登録メッセージ51の宛て先であるノードが実行すべき制御内容を記述するデータを含む。一例として、制御内容は、JSON(JavaScript Object Notation)形式で記述されてもよい。
図3の例において、ノード登録メッセージ51のメッセージボディ54は、登録されるべき放送信号処理ノードを一意に識別するノードID、及び当該放送信号処理ノードのIPアドレス「xxx.xxx.xxx.Y」を含む。限定ではないものの、ノードIDは、例えばUUID(Universally Unique Identifier)であってもよい。一例として、NMOS IS-04によれば、ノード登録メッセージ51を受信したNMOS登録サービスは、メッセージボディ54に記述されたノードIDに関連付けて、当該ノードIDにより識別される放送信号処理ノードのIPアドレスとして、同じくメッセージボディ54に記述されたIPアドレス「xxx.xxx.xxx.Y」をデータベースに登録する。
【0034】
(2)センダ登録メッセージ
図4は、HTTPを用いて送信される既存のセンダ登録メッセージの一例について説明するための説明図である。
図4に示したセンダ登録メッセージ61は、リクエストライン62、ヘッダ63及びメッセージボディ64を含む。
【0035】
リクエストライン62は、ホスト部分66及びパス部分67を含むURLを含む。ホスト部分66は、センダ登録メッセージ61の宛て先を識別する。したがって、ホスト部分66は、「宛て先部分」として言及されてもよい。
図4の例では、センダ登録メッセージ61の宛て先はホスト部分66においてIPアドレス「xxx.xxx.xxx.X」で識別されている。他の例では、メッセージの宛て先はホスト名で識別されてもよい。パス部分67は、
図3のノード登録メッセージ51のパス部分57と同様に、センダ登録メッセージ61が準拠するAPIの規格及びそのバージョンを識別する。
図3の例と同様に、リクエストライン62は、HTTPメソッド名及びHTTPバージョン番号といった他の情報をも含み得る。
【0036】
メッセージボディ64は、センダ登録メッセージ61の宛て先であるノードが実行すべき制御内容を記述するデータを含む。
図4の例において、センダ登録メッセージ61のメッセージボディ64は、登録されるべきセンダを一意に識別するセンダID、及び当該センダが属するエンティティ(例えば、ノード又はデバイス)を識別する親IDを含む。限定ではないものの、センダIDもまた、例えばUUIDであってよい。一例として、NMOS IS-04によれば、センダ登録メッセージ61を受信したNMOS登録サービスは、メッセージボディ64に記述されたセンダIDを、同じくメッセージボディ64に記述された親ID(
図4の例では、ノードID)に関連付けてデータベースに登録する。
【0037】
(3)レシーバ登録メッセージ
図5は、HTTPを用いて送信される既存のレシーバ登録メッセージの一例について説明するための説明図である。
図5に示したレシーバ登録メッセージ71は、リクエストライン72、ヘッダ73及びメッセージボディ74を含む。
【0038】
リクエストライン72は、ホスト部分76及びパス部分77を含むURLを含む。ホスト部分76は、レシーバ登録メッセージ71の宛て先を識別する。したがって、ホスト部分76は、「宛て先部分」として言及されてもよい。
図5の例では、レシーバ登録メッセージ71の宛て先はホスト部分76においてIPアドレス「xxx.xxx.xxx.X」で識別されている。他の例では、メッセージの宛て先はホスト名で識別されてもよい。パス部分77は、
図3のノード登録メッセージ51のパス部分57と同様に、レシーバ登録メッセージ71が準拠するAPIの規格及びそのバージョンを識別する。
図3の例と同様に、リクエストライン72は、HTTPメソッド名及びHTTPバージョン番号といった他の情報をも含み得る。
【0039】
メッセージボディ74は、レシーバ登録メッセージ71の宛て先であるノードが実行すべき制御内容を記述するデータを含む。
図5の例において、レシーバ登録メッセージ71のメッセージボディ74は、登録されるべきレシーバを一意に識別するレシーバID、及び当該レシーバが属するエンティティ(例えば、ノード又はデバイス)を識別する親IDを含む。限定ではないものの、レシーバIDもまた、例えばUUIDであってよい。一例として、NMOS IS-04によれば、レシーバ登録メッセージ71を受信したNMOS登録サービスは、メッセージボディ74に記述されたレシーバIDを、同じくメッセージボディ74に記述された親ID(
図5の例では、ノードID)に関連付けてデータベースに登録する。
【0040】
(4)ストリーム制御メッセージ
図6は、HTTPを用いて送信される既存のストリーム制御メッセージの一例について説明するための説明図である。
図6に示したストリーム制御メッセージ81は、リクエストライン82、ヘッダ83及びメッセージボディ84を含む。
【0041】
リクエストライン82は、ホスト部分86及びパス部分87を含むURLを含む。ホスト部分86は、ストリーム制御メッセージ81の宛て先を識別する。したがって、ホスト部分86は、「宛て先部分」として言及されてもよい。
図6の例では、ストリーム制御メッセージ81の宛て先はホスト部分86においてIPアドレス「xxx.xxx.xxx.Y」で識別されている。他の例では、メッセージの宛て先はホスト名で識別されてもよい。パス部分87は、ストリーム制御メッセージ81が準拠するAPIの規格及びそのバージョンを識別する。
図6の例では、ストリーム制御メッセージ81のパス部分87から、ストリーム制御メッセージ81がNMOS IS-05のバージョン1.0に準拠した制御メッセージの一種であることが理解される。リクエストライン82は、HTTPメソッド名(例えば、PATCH)及びHTTPバージョン番号といった他の情報をも含み得る。
【0042】
メッセージボディ84は、ストリーム制御メッセージ81の宛て先であるノードが実行すべき制御内容を記述するデータを含む。
図6の例において、ストリーム制御メッセージ81のメッセージボディ84は、制御対象のストリームの伝送に関与するセンダを識別するセンダID、並びに当該ストリームの伝送のために使用されるべきマルチキャストID及びポート番号を含む。一例として、ストリーム制御メッセージ81を受信した放送信号処理ノードは、メッセージボディ84に記述された制御内容に従って、自身に属するセンダ(メッセージボディ84に記述されたセンダIDにより識別されるセンダ)によるストリームの伝送を設定し、又は開始する。
【0043】
<1-3.課題の説明>
将来的にIP化が進展すると、放送局システムのネットワークに多様なノードが接続されることが予期される。その場合に、多様なノードを一元的に管理し又は制御する仕組みが無ければ、システムの計画的な運用、ネットワークリソースの効率的な利用、又はセキュリティリスクの最小化といったタスクの遂行が阻害されかねない。しかし、多様なノードの一元的な管理又は制御を困難にするいくつかのシナリオが考えられる。
【0044】
(1)異なる種類の制御インタフェースの存在
図7及び
図8は、異なる種類の制御インタフェースをサポートする複数の放送信号処理ノードが存在する状況について説明するための説明図である。これら図には、IPネットワークを介して相互に接続された4つの放送信号処理ノード30a、30b、30c及び30dが示されている。放送信号処理ノード30a及び30bは、第1のタイプ(タイプA)の制御インタフェースをサポートする。放送信号処理ノード30cは、第2のタイプ(タイプB)の制御インタフェースをサポートする。放送信号処理ノード30dは、第3のタイプ(タイプC)の制御インタフェースをサポートする。こうした状況において、放送信号処理ノード30aのセンダ及び放送信号処理ノード30dのレシーバが共通的なストリーム伝送プロトコル(例えば、SMPTE ST2022-6、SMPTE ST2110又はARIB STD-B73)をサポートしていれば、それらセンダ及びレシーバの間で当該ストリーム伝送プロトコルに従ってストリームを伝送することが可能である(例えば、
図7のストリームST1)。同様に、放送信号処理ノード30cのセンダ及び放送信号処理ノード30bのレシーバが共通的なストリーム伝送プロトコルをサポートしていれば、それらセンダ及びレシーバの間で当該ストリーム伝送プロトコルに従ってストリームを伝送することが可能である(例えば、
図7のストリームST2)。
【0045】
しかし、例えばストリームST1の伝送をセットアップするためには、システム内に第1のタイプの制御インタフェースを通じて放送信号処理ノード30aへ制御メッセージを送信する機能と、第3のタイプの制御インタフェースを通じて放送信号処理ノード30dへ制御メッセージを送信する機能とが必要とされる。同様に、例えばストリームST2の伝送をセットアップするためには、システム内に第2のタイプの制御インタフェースを通じて放送信号処理ノード30cへ制御メッセージを送信する機能と、第1のタイプの制御インタフェースを通じて放送信号処理ノード30bへ制御メッセージを送信する機能とが必要とされる。仮にそれぞれのタイプの制御インタフェースのために別個の制御端末が導入されるとすると、
図8に例示したように、システム内に、第1のタイプの制御インタフェースをサポートする制御端末50a、第2のタイプの制御インタフェースをサポートする制御端末50b、及び第3のタイプの制御インタフェースをサポートする制御端末50cが存在することになる。このシナリオでは、放送信号処理ノード30a、30b、30c及び30dの管理及び制御がばらばらとなるばかりか、ノードの追加及び制御端末の増加に対する拡張可能性も損なわれる。
【0046】
(2)分散的なストリーム制御
図9は、単一の種類の制御インタフェースをサポートする放送信号処理ノードしか存在しないものの、システム内に複数の制御端末が存在する状況について説明するための説明図である。
図9には、IPネットワークを介して相互に接続された4つの放送信号処理ノード30a、30b、30e及び30fが示されている。放送信号処理ノード30a、30b、30e及び30fは、共通して第1のタイプの制御インタフェースをサポートする。
図9には、3つの制御端末50aがさらに示されている。これら制御端末50aもまた、第1のタイプの制御インタフェースをサポートする。ここで、第1のタイプの制御インタフェースは、NMOS IS-05のように、制御端末と放送信号処理ノードとの間で直接的に制御メッセージを交換することを規定しているものとする。このシナリオでは、3つの制御端末50aからの制御は分散的に行われるに過ぎず、複数の制御端末をまたいでストリーム制御に関与する装置は存在しない。これでは、やはりシステム全体を考慮することを要する上で例示したようなタスクの遂行は容易ではない。
【0047】
<1-4.基本的な原理>
本開示に係る技術は、上述した課題のうちの少なくとも1つに対処するために、放送信号処理ノードを一元的に管理するためのノード管理機能を、放送局システム1に導入する。本明細書では、当該ノード管理機能が実装される装置をノード管理装置という。ノード管理装置は、例えば、IPコントローラ又はIPマネージャなどと呼ばれてもよい。
図10には、一例としてのノード管理装置100が示されている。ノード管理装置100は、放送信号処理ノードとは別個の装置であってもよく、又はいずれかの放送信号処理ノードと物理的に同一の装置であってもよい。
【0048】
典型的には、ノード管理装置100は、放送局内のネットワーク上でのストリームの送信又は受信に関与する1つ以上の放送信号処理ノードを管理する。これら放送信号処理ノードは、IPドメインにおけるストリームのいわゆるエンドポイントに位置するノードであり、
図2のシステムモデルの例におけるセンダ又はレシーバを有する。ストリームを単に転送するネットワーク装置12は、ノード管理装置100による管理の対象外であってよい。
【0049】
さらに、
図10に示したように、ノード管理装置100は、少なくとも1つの外部装置と通信可能である。
図10では、外部装置の例として制御端末50が示されているものの、外部装置は、かかる例に限定されず、他のいかなる装置(例えば、上述したAPS40)であってもよい。ノード管理装置100及び外部装置50は、共通的な制御APIをサポートする。典型的には、そのAPIは、制御メッセージの宛て先部分で制御対象ノードを識別することを要するAPIである。次節より詳しく説明するように、ノード管理装置100は、管理下の放送信号処理ノードのセンダ及びレシーバの実際のロケーションに関わらず、外部装置50に対して、それらセンダ及びレシーバが単一の装置(典型的には、ノード管理装置100自身)に属しているかのように見せる。それにより、外部装置50は、単一の装置との間の制御インタフェースのみをサポートして、当該単一の装置へ向けて制御メッセージを送信するようになる。
【0050】
<<2.第1の実施形態>>
<2-1.ノード管理装置の構成例>
図11は、第1の実施形態に係るノード管理装置100の構成の一例を示すブロック図である。
図11を参照すると、ノード管理装置100は、処理部110、記憶部120及び通信インタフェース150を備える。
【0051】
(1)処理部
処理部110は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)又はマイクロコントローラといった1つ以上のプロセッサを含む。処理部110は、記憶部120により記憶されるコンピュータプログラムを実行することにより、ノード管理装置100の機能性を実現する。本実施形態において、処理部110は、例えば、ノード情報管理部160及びストリーム制御部170として機能する。言い換えると、ノード情報管理部160及びストリーム制御部170は、処理部110により実現される機能モジュールである。ストリーム制御部170は、宛て先置換機能171を含む。ノード管理装置100の機能性について、後にさらに説明する。
【0052】
(2)記憶部
記憶部120は、一時的な及び非一時的なコンピュータ読取可能なメモリを含む。一時的なメモリは、例えばRAM(Random Access Memory)を含み得る。非一時的なメモリは、例えばROM(Read Only Memory)、HDD(Hard Disk Drive)又はSSD(Solid State Drive)のうちの1つ以上を含み得る。記憶部120は、ノード管理装置100の機能性を実現するためのコンピュータプログラムを記憶する。記憶部120は、さらに、ノード管理装置100の動作において使用されるデータベースとして機能する。データベースは、レジストリ、リポジトリ又は単にテーブルなどと呼ばれてもよい。本実施形態において、記憶部120により記憶されるデータは、例えば、登録ノード情報130、登録センダ情報140及び登録レシーバ情報145を含む。こうしたデータの構成について、後にさらに説明する。
【0053】
(3)通信インタフェース
通信インタフェース150は、ノード管理装置100による他の装置との通信を仲介するインタフェースである。通信インタフェース150は、有線通信のための接続端子及び接続回路を含んでもよく、又は無線通信のためのアンテナ、RF(Radio Frequency)回路及びベースバンド回路を含んでもよい。本実施形態において、通信インタフェース150は、例えば、LAN(Local Area Network)通信のためのネットワークアダプタ又はネットワークカードであってよい。ノード管理装置100は、IPドメイン10に属する任意のノードと通信インタフェース150を介して通信する。
【0054】
(4)ノード情報管理部
ノード情報管理部160は、放送局内のネットワーク上でのストリームの送信又は受信に関与する1つ以上の放送信号処理ノードに関する情報の、データベースへの登録及び管理を行う。
【0055】
より具体的には、ノード情報管理部160は、放送局システム1のIPネットワークへの放送信号処理ノードの接続を監視し、放送信号処理ノードの接続を検出する。例えば、IPネットワークへ接続した放送信号処理ノードは、mDNS(multicast Domain Name System)クエリを発行して、ノード管理装置100により提供される情報登録サービスを発見し、発見したサービスへ向けて情報登録のための登録メッセージを送信する。例えば、1つ以上のセンダを有する放送信号処理ノードは、
図3に例示したようなノード登録メッセージと、
図4に例示したような1つ以上のセンダ登録メッセージとを送信する。1つ以上のレシーバを有する放送信号処理ノードは、
図3に例示したようなノード登録メッセージと、
図5に例示したような1つ以上のレシーバ登録メッセージとを送信する。ノード情報管理部160は、通信インタフェース150を介してこれら登録メッセージを受信し、受信したメッセージの内容に基づいて情報をデータベースへ登録する。
【0056】
図12は、ノード情報管理部160により管理される情報の構成の一例について説明するための説明図である。
図12には、登録ノード情報130、登録センダ情報140及び登録レシーバ情報145が示されている。登録ノード情報130は、情報項目として、ノード名称131、ノードID133及びIPアドレス135を含む。ノード名称131は、各放送信号処理ノードに付与される名称を表す。ノードID133は、各放送信号処理ノードを一意に識別する識別子である。識別子の一意性を担保するために、ノードIDとしてUUIDを用いることが有利である。但し、
図12では、説明の便宜上、より長さの短いノードIDを例示している。IPアドレス135は、システム内で各放送信号処理ノードに割り当てられたIPアドレスである。少なくともノードID133及びIPアドレス135の値は、
図3を用いて説明したように、各放送信号処理ノードから受信されるノード登録メッセージ内に記述され得る。
【0057】
登録センダ情報140は、情報項目として、センダID141及び親ID143を含む。センダID141は、各センダを一意に識別する識別子である。識別子の一意性を担保するために、センダIDとしてUUIDを用いることが有利である。但し、
図12では、説明の便宜上、より長さの短いセンダIDを例示している。親ID143は、各センダが属するノードを識別するノードIDを表す。
図12の例では、センダID「SNA11」を有するセンダ及びセンダID「SNA12」を有するセンダは、共にノードID「NDA1」により識別される放送信号処理ノードに属する。
【0058】
登録レシーバ情報145は、情報項目として、レシーバID146及び親ID148を含む。レシーバID146は、各レシーバを一意に識別する識別子である。識別子の一意性を担保するために、レシーバIDとしてUUIDを用いることが有利である。但し、
図12では、説明の便宜上、より長さの短いレシーバIDを例示している。親ID148は、各レシーバが属するノードを識別するノードIDを表す。
図12の例では、レシーバID「RCA21」を有するレシーバ及びレシーバID「RCA22」を有するレシーバは、共にノードID「NDA2」により識別される放送信号処理ノードに属する。
【0059】
なお、
図12に示した登録情報は一例に過ぎない。ノード情報管理部160は、図示した情報項目以外の情報項目を管理してもよい。例えば、登録ノード情報130は、各放送信号処理ノードに属するセンダの個数を表すセンダ個数情報、及び各放送信号処理ノードに属するレシーバの個数を表すレシーバ個数情報をさらに含んでもよい。また、登録センダ情報140は、各センダのセンダ名称、各センダによりサポートされるストリーム及びエッセンスのタイプを表すタイプ情報、並びに、送信マルチキャストアドレス及び送信ポート番号といったその他のセンダ属性情報を含んでもよい。登録レシーバ情報145は、各レシーバのレシーバ名称、各レシーバによりサポートされるストリーム及びエッセンスのタイプを表すタイプ情報、並びに、加入マルチキャストアドレス及び受信ポート番号といったその他のレシーバ属性情報を含んでもよい。後に
図19を用いて説明する登録情報の構成の例についても同様である。
【0060】
ノード情報管理部160は、接続を検出した放送信号処理ノードに関する情報を外部装置へ通知する。放送信号処理ノードに関する情報の外部装置への通知は、例えば、放送信号処理ノードからの登録メッセージ(又は登録情報変更メッセージ)の受信をトリガとして行われてもよい。その代わりに、外部装置への上記通知は、外部装置からの問合せに応じて行われてもよい。ノード情報管理部160は、外部装置への上記通知において、放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置100を識別する代替識別情報を、当該放送信号処理ノードの識別情報として外部装置へ通知する。外部装置への通知は、例えば、
図13に例示するようなノード登録メッセージ51bを外部装置へ送信することにより行われ得る。
【0061】
図13は、ノード登録メッセージにおけるノード識別情報の置換について説明するための説明図である。
図13の例において、放送信号処理ノード30a、ノード管理装置100及び外部装置50は、共通的なHTTPベースのAPIをサポートするものとする。したがって、放送信号処理ノード30aは、IPネットワークへの接続後に、HTTPメッセージであるノード登録メッセージ51aをノード管理装置100へ送信する。ノード登録メッセージ51aの宛て先部分には、ノード管理装置100のIPアドレス「xxx.xxx.xxx.X」が記述される。ノード情報管理部160は、ノード登録メッセージ51aの受信に応じて、メッセージボディ54aに記述されている放送信号処理ノード30aのノードID及びIPアドレスをデータベースに登録する。
図13には示していないものの、放送信号処理ノード30aがセンダ又はレシーバを有する場合には、ノード情報管理部160は、続いて、対応するセンダ登録メッセージ又はレシーバ登録メッセージをも受信し、センダ情報又はレシーバ情報をデータベースに登録する。
【0062】
その後、ノード情報管理部160は、ノード登録メッセージ51bを外部装置50へ送信する。その際、ノード情報管理部160は、ノード登録メッセージ51bのメッセージボディ54bに、放送信号処理ノード30aを識別するIPアドレス「xxx.xxx.xxx.Y」に代えて、ノード管理装置100を識別する代替的なIPアドレス「xxx.xxx.xxx.X」を記述する。即ち、ノード情報管理部160は、ノード管理装置100を識別する代替識別情報を、放送信号処理ノード30aの識別情報として外部装置50へ通知する。
図13には示していないものの、放送信号処理ノード30aがセンダ又はレシーバを有する場合には、ノード情報管理部160は、続いて、センダ登録メッセージ又はレシーバ登録メッセージを外部装置50へ転送する。結果的に、外部装置50は、放送信号処理ノード30aに属するセンダ又はレシーバが、メッセージボディ54bに記述されたIPアドレス「xxx.xxx.xxx.X」により識別されるノードに属しているものと認識する。
【0063】
ノード情報管理部160は、接続済みの放送信号処理ノードの各々の接続ステータスをさらに管理してもよい。各放送信号処理ノードの接続ステータスは、ノード単位で管理されてもよく、又はセンダ及びレシーバの単位で管理されてもよい。例えば、ノード情報管理部160は、放送信号処理ノードの各々から周期的に送信されるメッセージ(例えば、ハートビート又はステータスメッセージ)を受信することにより、各ノードの接続ステータスを管理し得る。ノード情報管理部160は、外部装置(例えば、制御端末)50から受信されるメッセージに応じて、データベースへ情報を追加的に登録し、情報を変更し、又は情報を削除してもよい。
【0064】
(5)ストリーム制御部
ストリーム制御部170は、放送局システム1内のセンダからレシーバへのストリームの伝送を制御する。本実施形態において、ストリーム制御部170もまた、ノード情報管理部160と同様に、外部装置50と共通的なHTTPベースのAPIをサポートする。サポートされるAPIは、制御メッセージの宛て先部分で制御対象ノードを識別することを要するAPIである。上述したNMOSインタフェースは、そうしたAPIの一例である。この場合、制御メッセージの宛て先部分とは、HTTPメッセージのホスト部分に相当し、ホスト部分にノード識別情報として制御対象ノードのIPアドレス又はホスト名が記述され得る。
【0065】
本実施形態において、ストリーム制御部170は、放送信号処理ノードを制御するための制御メッセージであって、上述した代替識別情報を宛て先として有する当該制御メッセージを、外部装置50から通信インタフェース150を介して受信する。これは、上述したように、ノード情報管理部160が外部装置50への通知において放送信号処理ノードを識別するノード識別情報に代えてノード管理装置100を識別する代替識別情報を当該放送信号処理ノードの識別情報として外部装置50へ通知したためである。外部装置50から受信される制御メッセージは、制御対象のセンダ又はレシーバを識別する制御対象情報を含む。制御対象情報は、
図6の例のように、制御メッセージのメッセージボディに含まれるセンダID又はレシーバIDであり得る。
【0066】
ストリーム制御部170は、受信した制御メッセージを、少なくとも宛て先を代替識別情報からもとのノード識別情報へ置換することにより変換して、変換後の制御メッセージを放送信号処理ノードへ送信する。例えば、ストリーム制御部170は、受信した制御メッセージ内に記述されている制御対象のセンダID又はレシーバIDをデータベース内でルックアップし、そのセンダID又はレシーバIDに関連付けられている所属先のノードの識別情報をデータベースから取得することができる。
図12に示したデータ構成によれば、制御対象のセンダIDに対応する親IDを登録センダ情報140から取得し、さらに取得した親ID(ノードID)に対応するIPアドレスを登録ノード情報130から取得することができる。同様に、制御対象のレシーバIDに対応する親IDを登録レシーバ情報145から取得し、さらに取得した親ID(ノードID)に対応するIPアドレスを登録ノード情報130から取得することができる。このように取得されるIPアドレスが、置換後のもとのノード識別情報の一例である。上述したように、IPアドレスの代わりにホスト名が使用されてもよい。また、センダID及びレシーバIDは、所属先のノードのノードID(親ID)に直接的に関連付けられる代わりに、デバイスIDを介して間接的にノードIDに関連付けられてもよい。
【0067】
図14は、外部装置から放送信号処理ノードへ送信される制御メッセージにおける宛て先の置換について説明するための説明図である。
図14の例においても、放送信号処理ノード30a、ノード管理装置100及び外部装置50は、共通的なHTTPベースのAPIをサポートするものとする。外部装置50は、ユーザからのリクエストの受け付け、又は予め決定される切替え(ストリーム伝送の開始)時刻の到来といったトリガに応じて、HTTPメッセージであるストリーム制御メッセージ81bをノード管理装置100へ送信する。ストリーム制御メッセージ81bの宛て先部分には、ノード管理装置100のIPアドレス「xxx.xxx.xxx.X」が記述される。また、ストリーム制御メッセージ81bは、制御対象のセンダを識別するセンダID「SNA11」をメッセージボディ84bに含む。
【0068】
ストリーム制御部170は、ストリーム制御メッセージ81bの受信に応じて、センダID「SNA11」に関連付けられている所属先の放送信号処理ノード30aのIPアドレス「xxx.xxx.xxx.Y」をデータベースから取得する。次いで、ストリーム制御部170は、ストリーム制御メッセージ81bの宛て先部分(例えば、リクエストライン内のホスト部分)に記述されているノード管理装置100のIPアドレス(即ち、代替識別情報)「xxx.xxx.xxx.X」を、放送信号処理ノード30aを識別するIPアドレス(即ち、ノード識別情報)「xxx.xxx.xxx.Y」へ置換する。こうした置換の結果として、ストリーム制御メッセージ81bはストリーム制御メッセージ81aへ変換される。そして、ストリーム制御部170は、変換後のストリーム制御メッセージ81aを放送信号処理ノード30aへ送信する。ストリーム制御メッセージ81aにおいて、制御対象のセンダを識別するセンダID「SNA11」はそのままであってよい。
【0069】
図13及び
図14を用いて説明したような、ノード識別情報に代わる代替識別情報の外部装置への通知、及び外部装置から送信される制御メッセージにおける代替識別情報からもとのノード識別情報への置換によって、放送局システム1内で交換される制御メッセージは必ずノード管理装置100を通過するようになる。図には示していないものの、ノード管理装置100は、例えば、制御メッセージを中継する際に、認証、リソース制限、ログの記録、又はセンダとレシーバとの間の属性の適合性の検証といった追加的な制御を行ってもよい。上述した仕組みによれば、制御メッセージは必ずノード管理装置100を通過することから、システムの要件又はユーザのニーズに応じて、上述した様々な管理及び制御をノード管理装置100が一元的に行うことができる。
【0070】
<2-2.処理の流れ>
次に、
図15及び
図16を用いて、本実施形態においてノード管理装置100により実行される処理の流れについて説明する。
【0071】
(1)ノード情報通知処理
図15は、本実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。
【0072】
まず、ノード情報管理部160は、放送信号処理ノードからノード登録メッセージを受信する(ステップS110)。ノード情報管理部160は、受信したノード登録メッセージに記述されているノード情報をデータベースへ登録する(ステップS112)。また、ノード情報管理部160は、受信したノード登録メッセージ内のノード識別情報(ノード登録メッセージの送信元のノードの識別情報。例えば、IPアドレス又はホスト名)を、ノード管理装置100を識別する代替識別情報へ置換する(ステップS114)。そして、ノード情報管理部160は、置換後のノード登録メッセージを外部装置50へ送信する(ステップS116)。
【0073】
続けて、ノード情報管理部160は、上記放送信号処理ノードから1つ以上のセンダ登録メッセージ及び/又は1つ以上のレシーバ登録メッセージを受信する(ステップS120)。ノード情報管理部160は、受信したメッセージに記述されているセンダ情報及び/又はレシーバ情報をデータベースへ登録する(ステップS122)。そして、ノード情報管理部160は、受信したセンダ登録メッセージ及び/又はレシーバ登録メッセージを外部装置50へ送信する(ステップS124)。
【0074】
(2)メッセージ変換処理
図16は、本実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。
【0075】
まず、ストリーム制御部170は、放送信号処理ノードを制御するための制御メッセージであって、ノード管理装置100を識別する代替識別情報を宛て先として有する当該制御メッセージを、外部装置50から受信する(ステップS140)。次いで、ストリーム制御部170は、データベースに登録されている、各放送信号処理ノードに属するセンダを識別する登録センダ情報、又は各放送信号処理ノードに属するレシーバを識別する登録レシーバ情報に基づいて、制御対象の放送信号処理ノードのノード識別情報を取得する(ステップS142)。次いで、ストリーム制御部170は、受信した制御メッセージの宛て先部分に含まれる代替識別情報を、データベースから取得した制御対象の放送信号処理ノードのノード識別情報へ置換する(ステップS144)。そして、ストリーム制御部170は、置換後の制御メッセージを制御対象ノードへ送信する(ステップS146)。
【0076】
<2-3.利点>
上述した第1の実施形態によれば、ノード管理装置100及び外部装置50は、制御メッセージの宛て先部分で制御対象ノードを識別することを要するAPIをサポートする。制御対象の放送信号処理ノードもまた、上記APIをサポートする。ノード管理装置100は、上記APIを用いて制御メッセージを外部装置50から受信し、受信した制御メッセージの宛て先をノード管理装置100を識別する代替識別情報から制御対象の放送信号処理ノードを識別するノード識別情報へ置換して、置換後の制御メッセージを制御対象の放送信号処理ノードへ送信する。こうした仕組みによれば、
図17に示したように、放送局システム1内で交換される制御メッセージを、必ずノード管理装置100を通過するようにすることができる。
【0077】
図17の例では、4つの放送信号処理ノード30a、30b、30e及び30f、並びに3つの制御端末50a、50b及び50cがシステム内に存在する。これら放送信号処理ノード及び制御端末は、同一のタイプの制御APIをサポートする。当該制御APIは、制御端末と放送信号処理ノードとの間で直接的に制御メッセージを交換することを規定しているものとする。それにも関わらず、第1の実施形態では、上述したように制御メッセージが必ずノード管理装置100を通過することから、一元的なストリームの管理及び制御を実現することが容易である。これは、
図9を用いて説明したシナリオにおいて、制御が分散的に行われる結果として一元的なストリームの管理及び制御が困難であったのとは対照的である。
【0078】
<<3.第2の実施形態>>
<3-1.ノード管理装置の構成例>
図18は、第2の実施形態に係るノード管理装置200の構成の一例を示すブロック図である。
図18を参照すると、ノード管理装置200は、処理部210、記憶部220及び通信インタフェース150を備える。
【0079】
(1)処理部
処理部210は、例えば、CPU、MPU又はマイクロコントローラといった1つ以上のプロセッサを含む。処理部210は、記憶部220により記憶されるコンピュータプログラムを実行することにより、ノード管理装置200の機能性を実現する。本実施形態において、処理部210は、例えば、ノード情報管理部260及びストリーム制御部270として機能する。言い換えると、ノード情報管理部260及びストリーム制御部270は、処理部210により実現される機能モジュールである。ストリーム制御部270は、メッセージ変換機能273を含む。ノード管理装置200の機能性について、後にさらに説明する。
【0080】
(2)記憶部
記憶部220は、一時的な及び非一時的なコンピュータ読取可能なメモリを含む。一時的なメモリは、例えばRAMを含み得る。非一時的なメモリは、例えばROM、HDD又はSSDのうちの1つ以上を含み得る。記憶部220は、ノード管理装置200の機能性を実現するためのコンピュータプログラムを記憶する。記憶部220は、さらに、ノード管理装置200の動作において使用されるデータベースとして機能する。本実施形態において、記憶部220により記憶されるデータは、例えば、登録ノード情報230、登録センダ情報140及び登録レシーバ情報145を含む。こうしたデータの構成について、後にさらに説明する。
【0081】
(3)ノード情報管理部
ノード情報管理部260は、放送局内のネットワーク上でのストリームの送信又は受信に関与する1つ以上の放送信号処理ノードに関する情報の、データベースへの登録及び管理を行う。
【0082】
より具体的には、ノード情報管理部260は、第1の実施形態に係るノード管理装置100のノード情報管理部160と同様に、放送局システム1のIPネットワークへの放送信号処理ノードの接続を監視し、放送信号処理ノードの接続を検出する。例えば、IPネットワークへ接続した放送信号処理ノードは、mDNSクエリを発行して、ノード管理装置200により提供される情報登録サービスを発見し、発見したサービスへ向けて情報登録のための一群の登録メッセージ(例えば、ノード登録メッセージ、並びに1つ以上のセンダ登録メッセージ及び/又は1つ以上のレシーバ登録メッセージ)を送信する。ノード情報管理部260は、通信インタフェース150を介してこれら登録メッセージを受信し、受信したメッセージの内容に基づいて情報をデータベースへ登録する。
【0083】
図19は、ノード情報管理部260により管理される情報の構成の一例について説明するための説明図である。
図19には、登録ノード情報230、登録センダ情報140及び登録レシーバ情報145が示されている。登録ノード情報230は、情報項目として、ノード名称131、ノードID133、種別234及びIPアドレス135を含む。種別234は、各放送信号処理ノード(ノードID133により識別されるノード)によりサポートされる制御APIの種別を表す。
図19の例では、ノードID「NDA1」により識別されるノード及びノードID「NDA2」により識別されるノードは制御APIとしてNMOSをサポートし、ノードID「NDC1」により識別されるノードは制御APIとしてNMIをサポートする。一例として、NMOSは、ノード管理装置200及び外部装置により共通的にサポートされる制御APIである。したがって、種別234は、各放送信号処理ノードがノード管理装置200及び外部装置により共通的にサポートされる制御APIをサポートするか否かを示すノード種別情報であるということができる。本明細書では、ノード管理装置及び外部装置により共通的にサポートされる制御APIを、共通APIともいう。
【0084】
ノード情報管理部260は、接続を検出した放送信号処理ノードに関する情報を外部装置へ通知する。放送信号処理ノードに関する情報の外部装置への通知は、例えば、放送信号処理ノードからの登録メッセージ(又は登録情報変更メッセージ)の受信をトリガとして行われてもよい。その代わりに、外部装置への上記通知は、外部装置からの問合せに応じて行われてもよい。ノード情報管理部260は、外部装置への上記通知において、共通APIをサポートする放送信号処理ノードについては、ノード識別情報を置換することなく登録メッセージをそのまま外部装置へ送信する。一方、ノード情報管理部260は、共通APIをサポートしない放送信号処理ノードについては、当該放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置200を識別する代替識別情報を、当該放送信号処理ノードの識別情報として外部装置へ通知する。ノード情報管理部260は、登録メッセージの形式をも当該放送信号処理ノードによりサポートされる形式から共通APIの形式へ変換する。
【0085】
図20は、ノード登録メッセージにおけるノード識別情報の置換及びメッセージ形式の変換について説明するための説明図である。
図20の例において、ノード管理装置200及び外部装置50は、HTTPベースの制御APIである共通APIをサポートするものとする。放送信号処理ノード30cは、共通APIとは異なるAPIをサポートする。ノード管理装置200は、放送信号処理ノード30cによりサポートされる当該APIをもサポートする。
【0086】
放送信号処理ノード30cは、IPネットワークへの接続後に、ノード登録メッセージ51cをノード管理装置200へ送信する。ノード情報管理部260は、ノード登録メッセージ51cの受信に応じて、メッセージ内に記述されている放送信号処理ノード30cのノードID及びIPアドレスをデータベースに登録する。
図20には示していないものの、放送信号処理ノード30cがセンダ又はレシーバを有する場合には、ノード情報管理部260は、続いて、対応するセンダ登録メッセージ又はレシーバ登録メッセージをも受信し、センダ情報又はレシーバ情報をデータベースに登録する。
【0087】
その後、ノード情報管理部260は、共通APIに準拠する形式のノード登録メッセージ51dを生成し、生成したノード登録メッセージ51dを外部装置50へ送信する。その際、ノード情報管理部260は、ノード登録メッセージ51dのメッセージボディ54dに、放送信号処理ノード30cを識別するIPアドレス「xxx.xxx.xxx.K」に代えて、ノード管理装置200を識別する代替的なIPアドレス「xxx.xxx.xxx.X」を記述する。即ち、ノード情報管理部260は、ノード管理装置200を識別する代替識別情報を、放送信号処理ノード30cの識別情報として外部装置50へ通知する。
図20には示していないものの、放送信号処理ノード30cがセンダ又はレシーバを有する場合には、ノード情報管理部260は、続いて、共通APIに準拠する形式のセンダ登録メッセージ又はレシーバ登録メッセージを生成して、生成したメッセージを外部装置50へ送信する。結果的に、外部装置50は、放送信号処理ノード30cに属するセンダ又はレシーバが、メッセージボディ54dに記述されたIPアドレス「xxx.xxx.xxx.X」により識別されるノードに属しているものと認識する。
【0088】
ノード情報管理部260は、第1の実施形態に係るノード管理装置100のノード情報管理部160と同様に、接続済みの放送信号処理ノードの各々の接続ステータスをさらに管理してもよい。ノード情報管理部260は、外部装置(例えば、制御端末)50から受信されるメッセージに応じて、データベースへ情報を追加的に登録し、情報を変更し、又は情報を削除してもよい。
【0089】
(4)ストリーム制御部
ストリーム制御部270は、放送局システム1内のセンダからレシーバへのストリームの伝送を制御する。本実施形態において、ストリーム制御部270もまた、ノード情報管理部260と同様に、共通API及び共通APIとは異なる1つ以上の制御APIをサポートする。共通APIは、制御メッセージの宛て先部分で制御対象ノードを識別することを要するAPIである。上述したNMOSインタフェースは、そうしたAPIの一例である。
【0090】
本実施形態において、ストリーム制御部270は、放送信号処理ノードを制御するための制御メッセージであって、上述した代替識別情報を宛て先として有する当該制御メッセージを、外部装置50から通信インタフェース150を介して受信する。代替識別情報を宛て先として有する制御メッセージの制御対象の放送信号処理ノードは、共通APIとは異なる制御APIをサポートする。なぜなら、本実施形態において、ノード情報管理部260は、共通APIとは異なる制御APIをサポートする放送信号処理ノードについてのみ、外部装置50への通知において当該放送信号処理ノードを識別するノード識別情報に代えてノード管理装置200を識別する代替識別情報を外部装置50へ通知するためである。共通APIをサポートする放送信号処理ノードを制御するための制御メッセージは、外部装置50から当該放送信号処理ノードへ直接的に送信されてよい。
【0091】
ストリーム制御部270は、受信した制御メッセージの宛て先を、代替識別情報からもとのノード識別情報へ置換する。さらに、ストリーム制御部270は、受信した制御メッセージを、制御対象の放送信号処理ノードによりサポートされる形式のメッセージへ変換する。そして、ストリーム制御部270は、変換後の制御メッセージを制御対象の放送信号処理ノードへ送信する。例えば、ストリーム制御部270は、受信した制御メッセージ内に記述されている制御対象のセンダID又はレシーバIDをデータベース内でルックアップし、そのセンダID又はレシーバIDに関連付けられている所属先のノードの識別情報とサポートされる制御APIの種別とを、データベースから取得することができる。
【0092】
図21は、外部装置から放送信号処理ノードへ送信される制御メッセージのメッセージ変換について説明するための説明図である。
図21の例においても、ノード管理装置200及び外部装置50は共通APIをサポートし、一方で放送信号処理ノード30cは共通APIとは異なるAPIをサポートする。ノード管理装置200は、放送信号処理ノード30cによりサポートされる当該APIをもサポートする。
【0093】
外部装置50は、ユーザからのリクエストの受け付け、又は予め決定される切替え時刻の到来といったトリガに応じて、HTTPメッセージであるストリーム制御メッセージ81dをノード管理装置200へ送信する。ストリーム制御メッセージ81dの宛て先部分には、ノード管理装置200のIPアドレス「xxx.xxx.xxx.X」が記述される。また、ストリーム制御メッセージ81dは、制御対象のレシーバを識別するレシーバID「RCC11」をメッセージボディ84dに含む。
【0094】
ストリーム制御部270は、ストリーム制御メッセージ81dの受信に応じて、レシーバID「RCC11」に関連付けられている所属先の放送信号処理ノード30cのIPアドレス「xxx.xxx.xxx.K」をデータベースから取得する。次いで、ストリーム制御部270は、ストリーム制御メッセージ81dの宛て先部分(例えば、リクエストライン内のホスト部分)に記述されているノード管理装置200のIPアドレス(即ち、代替識別情報)「xxx.xxx.xxx.X」を、放送信号処理ノード30cを識別するIPアドレス(即ち、ノード識別情報)「xxx.xxx.xxx.K」へ置換する。さらに、ストリーム制御部270は、ストリーム制御メッセージ81dのメッセージ形式(例えば、タイプA)を、放送信号処理ノード30cによりサポートされる形式(例えば、タイプB)へ変換する。そして、ストリーム制御部270は、変換後のストリーム制御メッセージ81cを放送信号処理ノード30cへ送信する。ストリーム制御メッセージ81cにおいて、制御対象のレシーバを識別するレシーバID「RCC11」はそのままであってよい。
【0095】
図20及び
図21を用いて説明したような、ノード識別情報に代わる代替識別情報の外部装置への通知と、識別情報の置換を含む制御メッセージの変換とによって、放送局システム1内に共通APIをサポートしない放送信号処理ノードが存在するとしても、外部装置50は共通APIのみをサポートすればよいことになる。
【0096】
<3-2.処理の流れ>
次に、
図22及び
図23を用いて、本実施形態においてノード管理装置200により実行される処理の流れについて説明する。
【0097】
(1)ノード情報通知処理
図22は、本実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。
【0098】
まず、ノード情報管理部260は、放送信号処理ノードからノード登録メッセージを受信する(ステップS210)。ノード情報管理部260は、受信したノード登録メッセージに記述されているノード情報をデータベースへ登録する(ステップS212)。また、ノード情報管理部260は、ノード登録メッセージの送信元の放送信号処理ノードが所定のAPIをサポートしているかを判定する(ステップS213)。ここでの所定のAPIは、上述した共通APIに相当し、例えばNMOS、NMI、MessagePack-RPC又は他の任意の制御APIであってよい。その後の処理は、ステップS213における判定結果に依存して分岐する。
【0099】
放送信号処理ノードが所定のAPIをサポートしている場合、ノード情報管理部260は、受信したメッセージと同一の内容を含むノード登録メッセージを外部装置50へ送信する(ステップS214)。続けて、ノード情報管理部260は、上記放送信号処理ノードから1つ以上のセンダ登録メッセージ及び/又は1つ以上のレシーバ登録メッセージを受信する(ステップS220)。ノード情報管理部260は、受信したメッセージに記述されているセンダ情報及び/又はレシーバ情報をデータベースへ登録する(ステップS222)。そして、ノード情報管理部260は、受信したメッセージと同一の内容を含むセンダ登録メッセージ及び/又はレシーバ登録メッセージを外部装置50へ送信する(ステップS224)。
【0100】
放送信号処理ノードが所定のAPIをサポートしていない場合、ノード情報管理部260は、ノード識別情報の代替識別情報への置換を含むメッセージ変換を実行して、所定のAPIに準拠したノード登録メッセージを生成する(ステップS215)。そして、ノード情報管理部260は、生成したノード登録メッセージを外部装置50へ送信する(ステップS217)。続けて、ノード情報管理部260は、上記放送信号処理ノードから1つ以上のセンダ登録メッセージ及び/又は1つ以上のレシーバ登録メッセージを受信する(ステップS221)。ノード情報管理部260は、受信したメッセージに記述されているセンダ情報及び/又はレシーバ情報をデータベースへ登録する(ステップS223)。次いで、ノード情報管理部260は、メッセージ変換を実行して、所定のAPIに準拠したセンダ登録メッセージ及び/又はレシーバ登録メッセージを生成する(ステップS225)。そして、ノード情報管理部260は、生成したセンダ登録メッセージ及び/又はレシーバ登録メッセージを外部装置50へ送信する(ステップS227)。
【0101】
(2)メッセージ変換処理
図23は、本実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。
【0102】
まず、ストリーム制御部270は、放送信号処理ノードを制御するための制御メッセージであって、ノード管理装置200を識別する代替識別情報を宛て先として有する当該制御メッセージを、外部装置50から受信する(ステップS240)。次いで、ストリーム制御部270は、データベースに登録されている、各放送信号処理ノードに属するセンダを識別する登録センダ情報、又は各放送信号処理ノードに属するレシーバを識別する登録レシーバ情報に基づいて、制御対象の放送信号処理ノードのノード識別情報を取得する(ステップS242)。次いで、ストリーム制御部270は、受信した制御メッセージの宛て先部分に含まれる識別情報の置換(代替識別情報からステップS242で取得したノード識別情報への置換)を含むメッセージ変換を実行する(ステップS246)。そして、ストリーム制御部270は、変換後の制御メッセージを制御対象ノードへ送信する(ステップS248)。
【0103】
<3-3.利点>
上述した第2の実施形態によれば、外部装置50は、共通APIをサポートする放送信号処理ノードに属するセンダ及びレシーバが(実際の配備の通りに)当該放送信号処理ノード自体に位置していると認識する一方、共通APIをサポートしない放送信号処理ノードに属するセンダ及びレシーバは(実際の配備とは異なり)ノード管理装置100に位置していると認識する。言い換えると、外部装置50は、どのセンダ及びレシーバも、共通APIをサポートするノードに属していると認識する。こうした仕組みによれば、
図24に示したように、放送局システム1内に異なる種類の制御APIをサポートする複数の放送信号処理ノードが存在する状況においても、外部装置50は単一の共通的なAPIのみをサポートすればよいことになる。
【0104】
図24の例では、4つの放送信号処理ノード30a、30b、30c及び30d、並びに制御端末50aがシステム内に存在する。放送信号処理ノード30a及び30bは第1のタイプの制御APIをサポートするが、放送信号処理ノード30cは第2のタイプの制御APIを、放送信号処理ノード30dは第3のタイプの制御APIをサポートする。しかし、第2の実施形態では、上述したようにノード管理装置200が外部装置50aと放送信号処理ノード30c及び30dとの間でメッセージの宛て先の置換及びメッセージ形式の変換を実行するため、外部装置50aは第1のタイプの制御APIのみをサポートすればよい。これは、
図8を用いて説明したシナリオにおいて、システム内で利用される制御APIの種類の数だけ制御端末(あるいは制御機能)を実装することを要していたのとは対照的である。第2の実施形態では、ノードの追加及び制御端末の増加に対する拡張可能性が強化され、かつ少なくともノード情報の一元的な管理もまた可能である。
【0105】
<<4.第3の実施形態>>
<4-1.ノード管理装置の構成例>
図25は、第3の実施形態に係るノード管理装置300の構成の一例を示すブロック図である。
図25を参照すると、ノード管理装置300は、処理部310、記憶部320及び通信インタフェース150を備える。
【0106】
(1)処理部
処理部310は、例えば、CPU、MPU又はマイクロコントローラといった1つ以上のプロセッサを含む。処理部310は、記憶部320により記憶されるコンピュータプログラムを実行することにより、ノード管理装置300の機能性を実現する。本実施形態において、処理部310は、例えば、ノード情報管理部360及びストリーム制御部370として機能する。言い換えると、ノード情報管理部360及びストリーム制御部370は、処理部310により実現される機能モジュールである。ストリーム制御部370は、宛て先置換機能371及びメッセージ変換機能373を含む。ノード管理装置300の機能性について、後にさらに説明する。
【0107】
(2)記憶部
記憶部320は、一時的な及び非一時的なコンピュータ読取可能なメモリを含む。一時的なメモリは、例えばRAMを含み得る。非一時的なメモリは、例えばROM、HDD又はSSDのうちの1つ以上を含み得る。記憶部320は、ノード管理装置300の機能性を実現するためのコンピュータプログラムを記憶する。記憶部320は、さらに、ノード管理装置300の動作において使用されるデータベースとして機能する。本実施形態において、記憶部320により記憶されるデータは、例えば、登録ノード情報230、登録センダ情報140及び登録レシーバ情報145を含む。
【0108】
(3)ノード情報管理部
ノード情報管理部360は、放送局内のネットワーク上でのストリームの送信又は受信に関与する1つ以上の放送信号処理ノードに関する情報の、データベースへの登録及び管理を行う。
【0109】
より具体的には、ノード情報管理部360は、第1の実施形態におけるノード情報管理部160及び第2の実施形態におけるノード情報管理部260と同様に、放送局システム1のIPネットワークへの放送信号処理ノードの接続を監視し、放送信号処理ノードの接続を検出する。例えば、IPネットワークへ接続した放送信号処理ノードは、mDNSクエリを発行して、ノード管理装置300により提供される情報登録サービスを発見し、発見したサービスへ向けて情報登録のための一群の登録メッセージ(例えば、ノード登録メッセージ、並びに1つ以上のセンダ登録メッセージ及び/又は1つ以上のレシーバ登録メッセージ)を送信する。ノード情報管理部360は、通信インタフェース150を介してこれら登録メッセージを受信し、受信したメッセージの内容に基づいて情報をデータベースへ登録する。ノード情報管理部360により管理される情報の構成は、例えば、
図19を用いて説明した構成と同様であってもよく、又は当該構成とは異なってもよい。
【0110】
ノード情報管理部360は、接続を検出した放送信号処理ノードに関する情報を外部装置へ通知する。放送信号処理ノードに関する情報の外部装置への通知は、例えば、放送信号処理ノードからの登録メッセージ(又は登録情報変更メッセージ)の受信をトリガとして行われてもよい。その代わりに、外部装置への上記通知は、外部装置からの問合せに応じて行われてもよい。とりわけ、本実施形態において、ノード情報管理部360は、外部装置への上記通知において、放送信号処理ノードが共通APIをサポートするか否かに関わらず、当該放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置300を識別する代替識別情報を、当該放送信号処理ノードの識別情報として外部装置へ通知する。ノード情報管理部360は、共通APIとは異なるAPIの形式の登録メッセージを受信した場合には、登録メッセージの形式の共通API形式への変換も行う。共通APIをサポートする放送信号処理ノードのためのノード識別情報の置換は、例えば
図13に示したように行われてよい。共通APIをサポートしない放送信号処理ノードのためのノード識別情報の置換を含むメッセージ変換は、例えば
図20に示したように行われてよい。
【0111】
ノード情報管理部360は、第1の実施形態におけるノード情報管理部160及び第2の実施形態におけるノード情報管理部260と同様に、接続済みの放送信号処理ノードの各々の接続ステータスをさらに管理してもよい。ノード情報管理部360は、外部装置(例えば、制御端末)50から受信されるメッセージに応じて、データベースへ情報を追加的に登録し、情報を変更し、又は情報を削除してもよい。
【0112】
(4)ストリーム制御部
ストリーム制御部370は、放送局システム1内のセンダからレシーバへのストリームの伝送を制御する。本実施形態において、ストリーム制御部370もまた、ノード情報管理部360と同様に、共通API及び共通APIとは異なる1つ以上の制御APIをサポートする。共通APIは、制御メッセージの宛て先部分で制御対象ノードを識別することを要するAPIである。上述したNMOSインタフェースは、そうしたAPIの一例である。
【0113】
本実施形態において、ストリーム制御部370は、放送信号処理ノードを制御するための制御メッセージであって、上述した代替識別情報を宛て先として有する当該制御メッセージを、外部装置50から通信インタフェース150を介して受信する。代替識別情報を宛て先として有する制御メッセージの制御対象の放送信号処理ノードは、共通APIをサポートする放送信号処理ノード(以下、第1の放送信号処理ノードという)、又は共通APIとは異なる制御APIをサポートする放送信号処理ノード(以下、第2の放送信号処理ノードという)のいずれかである。
【0114】
ストリーム制御部370は、データベースに登録されている、各放送信号処理ノードが共通APIをサポートするか否かを示すノード種別情報に基づいて、受信した制御メッセージをどのように変換すべきか判定する。例えば、
図19を用いて説明した例において、NMOSが共通APIである場合には、ノードID「NDA1」又は「NDA2」により識別されるノードは、種別234により示されるように制御APIとしてNMOSをサポートするため、共通APIをサポートすると判定され得る。一方、ノードID「NDC1」により識別されるノードは、種別234により示されるように制御APIとしてNMOSをサポートしないため、共通APIをサポートしないと判定され得る。
【0115】
ストリーム制御部370は、共通APIをサポートする第1の放送信号処理ノードを制御対象ノードとして識別する第1制御メッセージが外部装置から受信された場合には、第1制御メッセージの宛て先を当該第1の放送信号処理ノードを識別するノード識別情報へ置換することにより第1制御メッセージを変換して、変換後の第1制御メッセージを当該第1の放送信号処理ノードへ送信する。一方、ストリーム制御部370は、共通APIをサポートしない第2の放送信号処理ノードを制御対象ノードとして識別する第2制御メッセージが外部装置から受信された場合には、第2制御メッセージを当該第2の放送信号処理ノードによりサポートされる形式のメッセージへ変換して、変換後の第2制御メッセージを当該第2の放送信号処理ノードへ送信する。ここでのメッセージ変換は、代替識別情報からノード識別情報への、宛て先の置換を含む。第1の放送信号処理ノードのための宛て先の置換は、例えば
図14に示したように行われてよい。第2の放送信号処理ノードのための宛て先の置換を含むメッセージ変換は、例えば
図21に示したように行われてよい。
【0116】
上述した仕組みによれば、制御メッセージが必ずノード管理装置300を通過することから、様々な管理及び制御をノード管理装置300が一元的に行うことができる。加えて、システム内に共通APIをサポートしない放送信号処理ノードが存在するとしても、外部装置50は共通APIのみをサポートすればよいことになる。
【0117】
<4-2.処理の流れ>
次に、
図26及び
図27を用いて、本実施形態においてノード管理装置300により実行される処理の流れについて説明する。
【0118】
(1)ノード情報通知処理
図26は、本実施形態におけるノード情報通知処理の流れの一例を示すフローチャートである。
【0119】
まず、ノード情報管理部360は、放送信号処理ノードからノード登録メッセージを受信する(ステップS310)。ノード情報管理部360は、受信したノード登録メッセージに記述されているノード情報をデータベースへ登録する(ステップS312)。また、ノード情報管理部360は、ノード登録メッセージの送信元の放送信号処理ノードが所定のAPIをサポートしているかを判定する(ステップS313)。ここでの所定のAPIは、上述した共通APIに相当し、例えばNMOS、NMI又は他の任意の制御APIであってよい。その後の処理は、ステップS313における判定結果に依存して分岐する。
【0120】
放送信号処理ノードが所定のAPIをサポートしている場合、ノード情報管理部360は、受信したノード登録メッセージ内のノード識別情報を、ノード管理装置300を識別する代替識別情報へ置換する(ステップS314)。そして、ノード情報管理部360は、置換後のノード登録メッセージを外部装置50へ送信する(ステップS315)。続けて、ノード情報管理部360は、上記放送信号処理ノードから1つ以上のセンダ登録メッセージ及び/又は1つ以上のレシーバ登録メッセージを受信する(ステップS320)。ノード情報管理部360は、受信したメッセージに記述されているセンダ情報及び/又はレシーバ情報をデータベースへ登録する(ステップS322)。そして、ノード情報管理部360は、受信したセンダ登録メッセージ及び/又はレシーバ登録メッセージを外部装置50へ送信する(ステップS324)。
【0121】
放送信号処理ノードが所定のAPIをサポートしていない場合、ノード情報管理部360は、ノード識別情報の代替識別情報への置換を含むメッセージ変換を実行して、所定のAPIに準拠したノード登録メッセージを生成する(ステップS316)。そして、ノード情報管理部360は、生成したノード登録メッセージを外部装置50へ送信する(ステップS317)。続けて、ノード情報管理部360は、上記放送信号処理ノードから1つ以上のセンダ登録メッセージ及び/又は1つ以上のレシーバ登録メッセージを受信する(ステップS321)。ノード情報管理部360は、受信したメッセージに記述されているセンダ情報及び/又はレシーバ情報をデータベースへ登録する(ステップS323)。次いで、ノード情報管理部360は、メッセージ変換を実行して、所定のAPIに準拠したセンダ登録メッセージ及び/又はレシーバ登録メッセージを生成する(ステップS325)。そして、ノード情報管理部360は、生成したセンダ登録メッセージ及び/又はレシーバ登録メッセージを外部装置50へ送信する(ステップS327)。
【0122】
(2)メッセージ変換処理
図27は、本実施形態におけるメッセージ変換処理の流れの一例を示すフローチャートである。
【0123】
まず、ストリーム制御部370は、放送信号処理ノードを制御するための制御メッセージであって、ノード管理装置300を識別する代替識別情報を宛て先として有する当該制御メッセージを、外部装置50から受信する(ステップS340)。次いで、ストリーム制御部370は、データベースに登録されている、各放送信号処理ノードに属するセンダを識別する登録センダ情報、又は各放送信号処理ノードに属するレシーバを識別する登録レシーバ情報に基づいて、制御対象の放送信号処理ノードの識別情報及び種別情報を取得する(ステップS342)。次いで、ストリーム制御部370は、取得した種別情報に基づいて、制御対象の放送信号処理ノードが所定のAPIをサポートしているかを判定する(ステップS343)。その後の処理は、ステップS343における判定結果に依存して分岐する。
【0124】
放送信号処理ノードが所定のAPIをサポートしている場合、ストリーム制御部370は、受信した制御メッセージの宛て先部分に含まれる代替識別情報を、データベースから取得した制御対象の放送信号処理ノードのノード識別情報へ置換する(ステップS344)。そして、ストリーム制御部370は、置換後の制御メッセージを制御対象ノードへ送信する(ステップS345)。
【0125】
放送信号処理ノードが所定のAPIをサポートしていない場合、ストリーム制御部370は、受信した制御メッセージの宛て先部分に含まれる識別情報の置換(代替識別情報からステップS342で取得したノード識別情報への置換)を含むメッセージ変換を実行する(ステップS346)。メッセージ変換は、ステップS342で取得したノード種別情報により示される制御APIの種別に基づいて行われ得る。そして、ストリーム制御部370は、変換後の制御メッセージを制御対象ノードへ送信する(ステップS347)。
【0126】
<4-3.利点>
上述した第3の実施形態によれば、外部装置50は、所定のAPI(あるいは共通API)をサポートする放送信号処理ノードに属するセンダ及びレシーバも、当該所定のAPIをサポートしない放送信号処理ノードに属するセンダ及びレシーバも、(実際の配備とは異なり)ノード管理装置300に位置していると認識する。こうした仕組みによれば、
図28に示したように、放送局システム1内で交換される制御メッセージを、必ずノード管理装置300を通過するようにすることができる。加えて、放送局システム1内に異なる種類の制御APIをサポートする複数の放送信号処理ノードが存在する状況においても、外部装置50は単一の共通的なAPIのみをサポートすればよいことになる。
【0127】
図28の例では、4つの放送信号処理ノード30a、30b、30c及び30d、並びに3つの制御端末50a、50b及び50cがシステム内に存在する。放送信号処理ノード30a及び30bは第1のタイプの制御APIをサポートするが、放送信号処理ノード30cは第2のタイプの制御APIを、放送信号処理ノード30dは第3のタイプの制御APIをサポートする。一方、制御端末50a、50b及び50cは、同一のタイプの制御APIをサポートする。当該制御APIは制御端末と放送信号処理ノードとの間で直接的に制御メッセージを交換することを規定しているにも関わらず、上述したように、制御メッセージは必ずノード管理装置300を通過する。よって、一元的なストリームの管理及び制御を実現することが容易である。さらに、第3の実施形態では、上述したようにノード管理装置300が外部装置と放送信号処理ノード30c及び30dとの間でメッセージの宛て先の置換及びメッセージ形式の変換を実行するため、外部装置は共通APIのみをサポートすればよい。よって、第3の実施形態では、ノードの追加及び制御端末の増加に対する拡張可能性が強化され、かつノード情報の一元的な管理及びストリームの一元的な制御が可能である。
【0128】
<<5.第4の実施形態>>
次いで、
図29を用いて、第4の実施形態について説明する。上述した第1~第3の実施形態は具体的な実施形態であり、一方で第4の実施形態はより一般化された実施形態である。
【0129】
図29は、第4の実施形態に係るノード管理装置400の構成、及びノード管理装置400と連携するデータベース装置405の構成の一例を示している。ノード管理装置400は、放送局内のネットワーク上でのストリームの送信又は受信に関与する1つ以上の放送信号処理ノードを管理するための情報処理装置である。ノード管理装置400は、データベース装置405へアクセス可能である。また、ノード管理装置400は、ストリーム制御部470を備える。データベース装置405は、記憶部420及び情報管理部460を備える。
【0130】
データベース装置405の記憶部420は、上記1つ以上の放送信号処理ノードに関する登録情報を記憶する。情報管理部460は、放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置400を識別する代替識別情報を当該放送信号処理ノードの識別情報として外部装置へ通知する。ノード管理装置400のストリーム制御部470は、ある放送信号処理ノードを制御するための制御メッセージであって、上記代替識別情報を宛て先として有する当該制御メッセージが外部装置から受信された場合に、当該制御メッセージを、少なくとも宛て先を上記代替識別情報からもとのノード識別情報へ置換することにより変換して、変換後の制御メッセージを上記放送信号処理ノードへ送信する。
【0131】
上記1つ以上の放送信号処理ノードを管理するためのノード管理方法が、上述したノード管理装置400の動作ステップを含んでもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムが提供されてもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムを記憶した非一時的なコンピュータ読取可能な記憶媒体が提供されてもよい。加えて、第1、第2及び第3の実施形態において説明した任意の機能又は処理が本実施形態に適用されてよい。
【0132】
<<6.まとめ>>
ここまで、
図1~
図29を用いて本開示のいくつかの実施形態について詳細に説明した。上述した実施形態では、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理装置を識別する代替識別情報が、放送信号処理ノードを識別するノード識別情報に代えて、当該放送信号処理ノードの識別情報として外部装置へ通知される。そして、上記ノード管理装置は、放送信号処理ノードを制御するための制御メッセージであって、上記代替識別情報を宛て先として有する当該制御メッセージが外部装置から受信された場合に、当該制御メッセージを、少なくとも宛て先を上記代替識別情報から上記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを当該放送信号処理ノードへ送信する。それにより、放送局システムのネットワークに放送信号を処理する多様なノードが存在する状況においても、それらノードの一元的な管理又は制御を効率的に行うことが可能となる。
【0133】
ある実施形態では、上記ノード管理装置及び外部装置は、制御メッセージの宛て先部分で制御対象ノードを識別することを要する共通APIをサポートし、上記制御メッセージは、当該APIを用いて外部装置から受信され得る。したがって、外部装置はこの共通APIのみをサポートすればよく、異なる種類の制御APIをサポートする放送信号処理ノードがシステムに追加されたとしても外部装置の改変は不要である。また、共通APIをサポートする放送信号処理ノードが制御対象である場合、上記ノード管理装置は、宛て先部分に含まれる識別情報(例えば、IPアドレス又はホスト名)を変換するのみで、制御メッセージを当該放送信号処理ノードへ中継することができる。
【0134】
ある実施形態では、外部装置から受信される上記制御メッセージは、制御対象のセンダ又はレシーバを識別する制御対象情報を含み得る。そして、データベースに登録されている、各放送信号処理ノードに属するセンダ又はレシーバを識別する登録情報に基づいて、制御メッセージの宛て先部分に含まれる上記代替識別情報がもとのノード識別情報へ置換され得る。かかる構成によれば、上述したように放送信号処理ノードを識別するノード識別情報に代えて代替識別情報が外部装置へ通知されるとしても、制御メッセージの内容からもとのノード識別情報を容易に特定することができる。
【0135】
なお、本開示に係る技術は、上述した実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、並びに、本開示のスコープ及び精神から逸脱することなく様々な変形が可能であるということが、当業者に理解されるであろう。
【0136】
例えば、フローチャートに示した処理ステップは、必ずしも図示した順序通りに実行されなくてもよい。例えば、処理ステップは図示した順序とは異なる順序で実行されてもよく、2つ以上の処理ステップが並列的に実行されてもよい。また、一部の処理ステップが削除されてもよく、さらなる処理ステップが追加されてもよい。
【0137】
また、本明細書において説明した装置の機能は、ソフトウェア、ハードウェア、及びソフトウェアとハードウェアとの組み合わせのいずれで実現されてもよい。ソフトウェアを構成するコンピュータプログラムのプログラム命令は、例えば、各装置の内部又は外部のコンピュータ読取可能な記憶媒体において記憶され、実行時にメモリへ読み込まれてプロセッサにより実行される。
【0138】
上記実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【0139】
(付記1)
放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理装置であって、
前記放送信号処理ノードを識別するノード識別情報に代えて、前記ノード管理装置を識別する代替識別情報が前記放送信号処理ノードの識別情報として外部装置へ通知され、
前記ノード管理装置は、前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージが前記外部装置から受信された場合に、前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを前記放送信号処理ノードへ送信する制御部、を備える、
ノード管理装置。
【0140】
(付記2)
前記ノード管理装置及び前記外部装置は、制御メッセージの宛て先部分で制御対象ノードを識別することを要するアプリケーションプロトコルインタフェースをサポートし、
前記制御部は、前記アプリケーションプロトコルインタフェースを用いて、前記制御メッセージを前記外部装置から受信する、
付記1に記載のノード管理装置。
【0141】
(付記3)
前記制御部は、前記アプリケーションプロトコルインタフェースをサポートする第1の放送信号処理ノードを前記制御対象ノードとして識別する第1制御メッセージが前記外部装置から受信された場合に、前記第1制御メッセージの宛て先を前記第1の放送信号処理ノードを識別するノード識別情報へ置換することにより前記第1制御メッセージを変換して、変換後の第1制御メッセージを前記第1の放送信号処理ノードへ送信する、付記2に記載のノード管理装置。
【0142】
(付記4)
前記制御部は、前記アプリケーションプロトコルインタフェースをサポートしない第2の放送信号処理ノードを前記制御対象ノードとして識別する第2制御メッセージが前記外部装置から受信された場合に、前記第2制御メッセージを前記第2の放送信号処理ノードによりサポートされる形式のメッセージへ変換して、変換後の第2制御メッセージを前記第2の放送信号処理ノードへ送信する、付記2又は付記3に記載のノード管理装置。
【0143】
(付記5)
前記外部装置から受信される前記制御メッセージは、制御対象のセンダ又はレシーバを識別する制御対象情報を含み、
前記制御部は、データベースに登録されている、各放送信号処理ノードに属するセンダ又はレシーバを識別する登録情報に基づいて、前記制御メッセージの前記宛て先部分に含まれる前記代替識別情報を前記ノード識別情報へ置換する、
付記2~4のいずれか1項に記載のノード管理装置。
【0144】
(付記6)
前記登録情報は、各放送信号処理ノードに属するセンダ又はレシーバを識別するUUID(Universally Unique Identifier)を含む、付記5に記載のノード管理装置。
【0145】
(付記7)
前記制御メッセージは、HTTP(Hypertext Transfer Protocol)メッセージである、付記2~6のいずれか1項に記載のノード管理装置。
【0146】
(付記8)
前記宛て先部分は、前記HTTPメッセージのホスト部分であり、前記ノード識別情報は、前記放送信号処理ノードのIPアドレス又はホスト名であり、前記代替識別情報は、前記ノード管理装置のIPアドレス又はホスト名である、付記7に記載のノード管理装置。
【0147】
(付記9)
前記制御部は、データベースに登録されている、各放送信号処理ノードが前記アプリケーションプロトコルインタフェースをサポートするか否かを示すノード種別情報に基づいて、前記制御メッセージをどのように変換すべきか判定する、付記2~8のいずれか1項に記載のノード管理装置。
【0148】
(付記10)
前記アプリケーションプロトコルインタフェースは、NMOS(Networked Media Open Specifications)インタフェースである、付記2~9のいずれか1項に記載のノード管理装置。
【0149】
(付記11)
放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するためのノード管理方法であって、
前記放送信号処理ノードを識別するノード識別情報に代えて、ノード管理装置を識別する代替識別情報を前記放送信号処理ノードの識別情報として外部装置へ通知することと、
前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージを前記外部装置から受信することと、
前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを前記放送信号処理ノードへ送信することと、
を含むノード管理方法。
【0150】
(付記12)
ノード管理装置のプロセッサに、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するための処理を実行させるコンピュータプログラムであって、
前記放送信号処理ノードを識別するノード識別情報に代えて、前記ノード管理装置を識別する代替識別情報が前記放送信号処理ノードの識別情報として外部装置へ通知され、
前記処理は、前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージが前記外部装置から受信された場合に、前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを前記放送信号処理ノードへ送信すること、を含む、
コンピュータプログラム。
【0151】
(付記13)
ノード管理装置のプロセッサに、放送局内のネットワーク上でのストリームの送信又は受信に関与する放送信号処理ノードを管理するための処理を実行させるコンピュータプログラム、を記憶した非一時的なコンピュータ読取可能な記憶媒体であって、
前記放送信号処理ノードを識別するノード識別情報に代えて、前記ノード管理装置を識別する代替識別情報が前記放送信号処理ノードの識別情報として外部装置へ通知され、
前記処理は、前記放送信号処理ノードを制御するための制御メッセージであって、前記代替識別情報を宛て先として有する当該制御メッセージが前記外部装置から受信された場合に、前記制御メッセージを、少なくとも宛て先を前記代替識別情報から前記ノード識別情報へ置換することにより変換して、変換後の制御メッセージを前記放送信号処理ノードへ送信すること、を含む、
非一時的なコンピュータ読取可能な記憶媒体。
【産業上の利用可能性】
【0152】
本開示に係る技術は、限定ではないものの、IPネットワークを含む放送局システムにおいて利用可能である。
【符号の説明】
【0153】
1 放送局システム
10 IPドメイン
12 ネットワーク装置
14,22 カメラ
16,34 モニタ
20a,20b IPゲートウェイ
24 マイクロフォン
26 データサーバ
30(30a~f) 放送信号処理ノード
32 統合プレイアウト
60(60a~d) センダ
62 デバイス
70(70a~c) レシーバ
81(81a~d) ストリーム制御メッセージ
86 宛て先部分(ホスト部分)
100,200,300,400 ノード管理装置
405 データベース装置
110,210,310 処理部
120,220,320,420 記憶部
130,230 登録ノード情報
140 登録センダ情報
145 登録レシーバ情報
150 通信インタフェース
160,260,360,460 ノード情報管理部
170,270,370,470 ストリーム制御部