(57)【要約】【課題】放送局システムのＩＰネットワークにおいて適切かつ効率的なストリームの伝送を実現する仕組みを提供すること。【解決手段】放送局システムを制御するための制御装置であって、センダからレシーバへのストリームの伝送を求めるリクエストを取得する取得部と、上記センダ及び上記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、上記センダの送信エッセンスタイプが上記レシーバの受信エッセンスタイプに適合するかを判定する判定部と、上記センダの上記送信エッセンスタイプが上記レシーバの上記受信エッセンスタイプに適合すると判定される場合に、上記センダから上記レシーバへの上記ストリームの伝送をセットアップする制御部と、を備える制御装置が提供される。【選択図】図５
2020102695.tif 000002
【特許請求の範囲】
【請求項１】
放送局システムを制御するための制御装置であって、
センダからレシーバへのストリームの伝送を求めるリクエストを取得する取得部と、
前記センダ及び前記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、前記センダの送信エッセンスタイプが前記レシーバの受信エッセンスタイプに適合するかを判定する判定部と、
前記センダの前記送信エッセンスタイプが前記レシーバの前記受信エッセンスタイプに適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする制御部と、
を備える制御装置。
【請求項２】
前記判定部は、前記センダの前記送信エッセンスタイプが前記レシーバの前記受信エッセンスタイプに適合する場合に、前記センダの送信メディアタイプが前記レシーバの受信メディアタイプに適合するかをさらに判定し、
前記制御部は、前記センダの前記送信メディアタイプが前記レシーバの前記受信メディアタイプに適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする、
請求項１に記載の制御装置。
【請求項３】
前記判定部は、前記センダの前方誤り訂正（ＦＥＣ）設定が前記レシーバのＦＥＣ設定に適合するかをさらに判定し、
前記制御部は、前記センダの前記ＦＥＣ設定が前記レシーバの前記ＦＥＣ設定に適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする、
請求項１又は請求項２に記載の制御装置。
【請求項４】
前記判定部は、前記センダのＲＴＣＰ（RTP  Control  Protocol）設定が前記レシーバのＲＴＣＰ設定に適合するかをさらに判定し、
前記制御部は、前記センダの前記ＲＴＣＰ設定が前記レシーバの前記ＲＴＣＰ設定に適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする、
請求項１〜３のいずれか１項に記載の制御装置。
【請求項５】
前記制御部は、前記センダと前記レシーバとの間で、エッセンスタイプ、メディアタイプ、ＦＥＣ設定及びＲＴＣＰ設定のうちの少なくとも１つが適合しないと判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップすることを拒否する、請求項１〜４のいずれか１項に記載の制御装置。
【請求項６】
前記制御部は、前記センダの前記送信メディアタイプが前記レシーバの前記受信メディアタイプに適合しないと判定される場合に、前記送信メディアタイプと前記受信メディアタイプとの不適合が解消されるように前記センダ又は前記レシーバと交渉する、請求項２に記載の制御装置。
【請求項７】
前記判定部は、前記センダによりサポートされるストリームタイプが前記レシーバによりサポートされるストリームタイプに適合するかをさらに判定し、
前記ストリームタイプの候補は、エッセンス混在型ストリーム及び前記エッセンス分離型ストリームを含む、
請求項１〜６のいずれか１項に記載の制御装置。
【請求項８】
前記制御装置は、前記センダから前記レシーバへの前記ストリームの伝送を求めるリクエストメッセージを受信する通信部、をさらに備える、請求項１〜７のいずれか１項に記載の制御装置。
【請求項９】
前記制御装置は、前記センダから前記レシーバへの前記ストリームの伝送を求める前記リクエストを受け付けるユーザインタフェース、をさらに備える、請求項１〜７のいずれか１項に記載の制御装置。
【請求項１０】
放送局システムにおいて実行される制御方法であって、
センダからレシーバへのストリームの伝送を求めるリクエストを取得することと、
前記センダ及び前記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、前記センダの送信エッセンスタイプが前記レシーバの受信エッセンスタイプに適合するかを判定することと、
前記センダの前記送信エッセンスタイプが前記レシーバの前記受信エッセンスタイプに適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップすることと、
を含む制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、放送局システムを制御するための制御装置及び制御方法に関する。
【背景技術】
【０００２】
既存の放送局の多くは、映像、音声及び補助（ancillary）データといった放送素材を局内で伝送するための専用ネットワークを有している。専用ネットワークには、例えば、カメラ及びマイクロフォンといったキャプチャデバイス、コンテンツデータを蓄積するストレージサーバ、コンテンツを再生する再生デバイス、及び伝送される信号の形式を変換するゲートウェイデバイスといった、様々な装置が接続される。専用ネットワーク上での放送素材の伝送ための信号形式として、ＳＤＩ（Serial  Digital  Interface）がこれまで広く利用されている。
【０００３】
しかし、近年のＩＰ（Internet  Protocol）技術の目覚ましい性能の向上の結果、放送事業者は、より汎用性の高いＩＰ技術を活用することにメリットを見出し、局内のネットワークをＩＰネットワークへ更新する取り組みを開始した。ＩＰベースのネットワークアーキテクチャを採用すれば、例えば、汎用のルータ及びスイッチといったネットワーク装置を用いて高速かつ大容量のネットワークを低コストで構築することが可能となる。ＩＰベースのネットワークアーキテクチャにおいては、業務のニーズに応じてネットワーク構成を変更することも比較的容易である。
【０００４】
放送素材をＩＰ技術を活用して伝送するためのプロトコルの標準化も、現在進められている。例えば、ＳＭＰＴＥ（Society  of  Motion  Picture  and  Television  Engineers）は、映像、音声及び補助データの混成であるＳＤＩイメージをＩＰパケットで搬送するためのプロトコルであるＳＭＰＴＥ  ＳＴ２０２２−６を規格化済みである（非特許文献１参照）。さらに、ＳＭＰＴＥは、映像、音声及び補助データを別々のストリームで搬送するためのプロトコル群であるＳＭＰＴＥ  ＳＴ２１１０シリーズの規格化も進めている（非特許文献２参照）。ＡＭＷＡ（Advanced  Media  Workflow  Association）により検討されているＮＭＯＳ（Networked  Media  Open  Specifications）は、これらＩＰベースのプロトコルに従ったストリームの伝送を管理し及び制御するための制御インタフェースの規格である（非特許文献３参照）。日本国内の標準化団体であるＡＲＩＢ（Association  of  Radio  Industries  and  Businesses）は、映像、音声及び補助データを別々のストリームで搬送するためのプロトコルであるＡＲＩＢ  ＳＴＤ−Ｂ７３の規格化を進めている（非特許文献４参照）。
【０００５】
なお、特許文献１は、ＩＰネットワークにおいて映像パケットの送信元を互いに非同期の送信機の間で切替える際に、伝送経路上の切替装置において切替え前後のパケットに付されるタイムスタンプのズレを補償する技術を開示している。特許文献２は、移動体通信ネットワークにおいてパケットの転送経路を左右するフィルタルールを、関係するネットワーク装置へ選択的に通知する技術を開示している。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Thomas  Edwards，  “SMPTE  ST  2022:  Moving  Serial  Interfaces  (ASI  &  SDI)  to  IP”，  ［online］，  2017年8月17日，  SMPTE  Standards  Webcast  Series，  ［平成30年11月19日検索］，  インターネット＜URL：https://www.smpte.org/sites/default/files/2017-08-17-ST-2022-Edwards-V4-Handout.pdf＞
【非特許文献２】SMPTE，  “SMPTE  ST  2110  FAQ”，  ［online］，  ［平成30年11月19日検索］，  インターネット＜URL：https://www.smpte.org/st-2110＞
【非特許文献３】AMWA，  “NMOS  Technical  Overview”，  ［online］，  ［平成30年11月19日検索］，  インターネット＜URL：https://amwa-tv.github.io/nmos/branches/master/NMOS_Technical_Overview.html＞
【非特許文献４】ARIB，  “制作用ＩＰインタフェースにおけるエッセンス独立単一ストリームのＲＴＰデータグラムのデータ構造  標準規格（ARIB  STD-B73  1.0版）”，  ［online］，  2018年7月26日，  ［平成30年11月19日検索］，  インターネット＜URL：https://www.arib.or.jp/kikaku/kikaku_hoso/desc/std-b73.html＞
【特許文献】
【０００７】
【特許文献１】特開２０１８−０２９２３６号公報
【特許文献２】国際公開第２００８／１０５１５８号
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＩＰ化が進展すれば、放送局システムのネットワークに多様な装置が接続されることが予期される。しかし、そうした多様な装置が送信し又は受信しようとするストリームの特性が送信側と受信側との間で相互に適合することは、必ずしも保証されない。特性の適合しないストリームが送信側から受信側へ送信されるとすれば、ネットワークリソースが無駄に消費され、受信側での予期しない動作不良もまた引き起こされかねない。
【０００９】
本開示は、上述した課題に鑑み、放送局システムのＩＰネットワークにおいて適切かつ効率的なストリームの伝送を実現する仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１０】
ある観点によれば、放送局システムを制御するための制御装置が提供される。当該制御装置は、センダからレシーバへのストリームの伝送を求めるリクエストを取得する取得部と、上記センダ及び上記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、上記センダの送信エッセンスタイプが上記レシーバの受信エッセンスタイプに適合するかを判定する判定部と、上記センダの上記送信エッセンスタイプが上記レシーバの上記受信エッセンスタイプに適合すると判定される場合に、上記センダから上記レシーバへの上記ストリームの伝送をセットアップする制御部と、を備える。
【００１１】
また別の観点によれば、放送局システムにおいて実行される制御方法が提供される。当該制御方法は、センダからレシーバへのストリームの伝送を求めるリクエストを取得することと、上記センダ及び上記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、上記センダの送信エッセンスタイプが上記レシーバの受信エッセンスタイプに適合するかを判定することと、上記センダの上記送信エッセンスタイプが上記レシーバの上記受信エッセンスタイプに適合すると判定される場合に、上記センダから上記レシーバへの上記ストリームの伝送をセットアップすることと、を含む。
【００１２】
また別の観点によれば、センダを備える送信ノードと、レシーバを備える受信ノードと、上記制御装置と、を含む放送局システムが提供されてもよい。上記制御方法をプロセッサに実行させるコンピュータプログラムが提供されてもよい。上記コンピュータプログラムを記憶した非一時的なコンピュータ読取可能な記憶媒体が提供されてもよい。
【発明の効果】
【００１３】
本開示に係る技術によれば、放送局システムのＩＰネットワークにおいて適切かつ効率的なストリームの伝送を実現することが可能となる。なお、本開示に係る技術により、当該効果の代わりに、又は当該効果とともに、他の効果が奏されてもよい。
【図面の簡単な説明】
【００１４】
【図１】本開示の実施形態に係る放送局システムの構成の一例を示す概略図である。
【図２】本開示の実施形態に係る放送局システムのＩＰドメインの論理的な構成の一例について説明するための説明図である。
【図３】センダからレシーバへのストリームの伝送のセットアップに関連する課題について説明するための説明図である。
【図４】第１の実施形態に係る管理ノードの構成の一例を示すブロック図である。
【図５】ストリームを送信し又は受信するノードに関連する情報の構成の一例について説明するための説明図である。
【図６Ａ】適合性判定の第１の例における判定結果について説明するための第１の説明図である。
【図６Ｂ】適合性判定の第１の例における判定結果について説明するための第２の説明図である。
【図６Ｃ】適合性判定の第１の例における判定結果について説明するための第３の説明図である。
【図７Ａ】適合性判定の第２の例における判定結果について説明するための第１の説明図である。
【図７Ｂ】適合性判定の第２の例における判定結果について説明するための第２の説明図である。
【図８Ａ】適合性判定の第３の例における判定結果について説明するための第１の説明図である。
【図８Ｂ】適合性判定の第３の例における判定結果について説明するための第２の説明図である。
【図８Ｃ】適合性判定の第３の例における判定結果について説明するための第３の説明図である。
【図９】第１の実施形態に係る設定端末の構成の一例を示すブロック図である。
【図１０】第１の実施形態において管理ノードがノード情報を収集する処理の流れの一例を示すシーケンス図である。
【図１１】第１の実施形態におけるストリーム伝送のリクエストからストリームのセットアップまでの処理の流れの一例を示すシーケンス図である。
【図１２Ａ】図１１に示した適合性判定処理の流れの第１の例を示すフローチャートである。
【図１２Ｂ】図１１に示した適合性判定処理の流れの第２の例を示すフローチャートである。
【図１２Ｃ】図１１に示した適合性判定処理の流れの第３の例を示すフローチャートである。
【図１２Ｄ】図１１に示した適合性判定処理の流れの第４の例を示すフローチャートである。
【図１２Ｅ】図１１に示した適合性判定処理の流れの第５の例を示すフローチャートである。
【図１３】第２の実施形態に係る放送局システムの構成の一例を示す概略図である。
【図１４】第２の実施形態に係る設定端末の構成の一例を示すブロック図である。
【図１５】第２の実施形態に係る管理ノードの構成の一例を示すブロック図である。
【図１６】第２の実施形態におけるストリーム伝送のリクエストからストリームのセットアップまでの処理の流れの一例を示すシーケンス図である。
【図１７】第３の実施形態に係る制御装置の構成の一例を示すブロック図である。
【発明を実施するための形態】
【００１５】
以下、添付の図面を参照して本開示に係る技術の実施形態を詳細に説明する。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。
【００１６】
説明は、以下の順序で行われる。
１．概要
１−１．システム構成例
１−２．ＩＰドメインの論理的構成例
１−３．課題の説明
２．第１の実施形態
２−１．管理ノードの構成例
２−２．設定端末の構成例
２−３．処理の流れ
３．第２の実施形態
３−１．システム構成例
３−２．管理ノードの構成例
３−３．設定端末の構成例
３−４．処理の流れ
４．第３の実施形態
５．変形例
６．まとめ
【００１７】
＜＜１．概要＞＞
＜１−１．システム構成例＞
まず、図１を用いて、本開示のいくつかの実施形態が適用され得る放送局システムの概要について説明する。図１は、本開示の実施形態に係る放送局システム１の構成の一例を示す概略図である。図１を参照すると、放送局システム１は、１つ以上のネットワーク装置１２、カメラ１４、モニタ１６、ＩＰゲートウェイ２０ａ、ＩＰゲートウェイ２０ｂ、カメラ２２、マイクロフォン２４、データサーバ２６、統合プレイアウト（Integrated  Playout）３２、モニタ３４、ＡＰＳ（Automatic  Program  control  System）４０、管理ノード１００及び設定端末２００を含む。ネットワーク装置１２、カメラ１４、モニタ１６、ＩＰゲートウェイ２０ａ、ＩＰゲートウェイ２０ｂ、ＡＰＳ４０、管理ノード１００及び設定端末２００は、ＩＰドメイン１０に属する。
【００１８】
（１）様々な装置の説明
ネットワーク装置１２は、ＩＰネットワークにおけるストリームの転送を担当する装置である。ネットワーク装置１２の各々は、例えばルータ、スイッチ、ブリッジ又はリピータなど、いかなる種類のネットワーク装置であってもよい。ネットワーク装置１２の各々は、低コストで導入可能な汎用品（ＣＯＴＳ（Commercial  Off-The-Shelf）ともいう）であってもよい。図１には４つのネットワーク装置１２が示されているが、かかる例に限定されず、放送局システム１はいくつのネットワーク装置１２を含んでもよい。ＩＰドメイン１０は、単一のネットワークで構成されてもよく、又は複数のサブネットワークを含んでもよい。
【００１９】
カメラ１４は、放送素材を生成するキャプチャデバイスの一種である。例えば、カメラ１４は、何らかの対象を撮影して、映像データを生成する。カメラ１４は、内蔵されるマイクロフォンを通じて音声を取得して、音声データを生成してもよい。カメラ１４は、ＩＰドメイン１０に属し、映像データ及び音声データのデータストリームを一連のＩＰパケットへパケット化してＩＰネットワークへ送信することができる。
【００２０】
モニタ１６は、放送素材を受信してコンテンツを再生する再生デバイスの一種である。例えば、モニタ１６は、映像データを受信して映像を再生する。モニタ１６は、音声データを受信して音声を再生してもよい。モニタ１６は、追加的に伝送される補助データを受信して、補助データを処理（例えば、字幕を再生）してもよい。モニタ１６は、コンテンツを編集するための編集機能をユーザへ提供してもよい。モニタ１６は、ＩＰドメイン１０へ属し、ＩＰネットワーク上で転送されて来る一連のＩＰパケットを受信することができる。
【００２１】
ＩＰゲートウェイ２０ａは、ＩＰドメイン１０と他の信号ドメインとの境界に位置するゲートウェイデバイスである。ＩＰゲートウェイ２０ａは、１つ又は複数のネットワーク装置１２へ接続する。図１の例において、ＩＰゲートウェイ２０ａには、カメラ２２、マイクロフォン２４及びデータサーバ２６がさらに接続されている。例えば、ＩＰゲートウェイ２０ａは、映像データを搬送するＳＤＩ信号をカメラ２２から受信し得る。また、ＩＰゲートウェイ２０ａは、音声データを搬送するＳＤＩ信号をマイクロフォン２４から受信し得る。また、ＩＰゲートウェイ２０ａは、映像データ、音声データ及び補助データのうちの１つ以上を搬送するＳＤＩ信号をデータサーバ２６から受信し得る。なお、ＩＰドメイン１０の外部で伝送される信号の信号形式は、例えばＳＤ−ＳＤＩ、ＨＤ−ＳＤＩ、３Ｇ−ＳＤＩ、６Ｇ−ＳＤＩ若しくは１２Ｇ−ＳＤＩといったＳＤＩの任意の派生であってもよく、又は、ＳＤＩ以外の信号形式であってもよい。ＩＰゲートウェイ２０ａは、上述したようにカメラ２２、マイクロフォン２４及びデータサーバ２６から受信される放送素材を搬送する信号を、必要に応じて多重化し又は逆多重化した後、一連のＩＰパケットへパケット化してＩＰネットワークへ送信することができる。
【００２２】
ＩＰゲートウェイ２０ｂもまた、ＩＰドメイン１０と他の信号ドメインとの境界に位置するゲートウェイデバイスである。ＩＰゲートウェイ２０ｂは、１つ又は複数のネットワーク装置１２へ接続する。図１の例では、ＩＰゲートウェイ２０ｂには、統合プレイアウト３２及びモニタ３４がさらに接続されている。例えば、ＩＰゲートウェイ２０ｂは、ＩＰネットワーク上で転送されて来るＩＰパケットを受信し、それらＩＰパケットをＳＤＩ信号（又は他の信号形式の信号）へ変換して、統合プレイアウト３２及びモニタ３４の一方又は双方へ送信することができる。なお、当然ながら、ＩＰゲートウェイ２０ａがＩＰゲートウェイ２０ｂと同様にＩＰパケットをＳＤＩ信号へ変換する機能を有していてもよい。また、ＩＰゲートウェイ２０ｂがＩＰゲートウェイ２０ａと同様にＳＤＩ信号をＩＰパケットへ変換する機能を有していてもよい。
【００２３】
ＡＰＳ４０は、予め決定されるスケジュールに従って、テレビジョン番組の放送を進行させるシステムである。例えば、ＡＰＳ４０は、後述する管理ノード１００へ制御メッセージを送信して、所定の時刻に所与の送信元（例えば、カメラ及びマイクロフォン、又はデータサーバ）から出力されるデータストリームを統合プレイアウト３２へ伝送させる。データストリームを受信した統合プレイアウト３２は、放送局の回線を通じてアンテナへテレビジョン番組の放送信号を送出する。データストリームは、例えばモニタ１６又はモニタ３４にも配信され、放送局内でも放送コンテンツが再生され得る。
【００２４】
管理ノード１００は、ＩＰドメイン１０に属するノードに関連する情報と、ノード間のストリームの伝送とを管理する情報処理装置である。管理ノード１００は、例えば、ＩＰネットワークへ何らかの装置が接続されたことを検出すると、当該装置の識別情報、アドレス情報及びその他の属性情報を取得し、取得した情報を（管理ノード１００の内部の又は外部の）データベースへ登録する。また、管理ノード１００は、ＩＰドメイン１０に属する登録済みの装置の各々から周期的に送信されるメッセージ（例えば、ハートビート又はステータスメッセージ）を受信することにより、各装置のステータス（例えば、接続済み、切断又は障害中など）を管理する。また、管理ノード１００は、後述する設定端末２００から受信されるメッセージに応じて、データベースへ情報を追加的に登録し、情報を変更し、又は情報を削除する。また、管理ノード１００は、ＡＰＳ４０又は設定端末２００（これらを上位装置ともいう）からストリームの伝送を求めるメッセージが受信されると、リクエストされたストリームの伝送をセットアップする。追加的に、管理ノード１００は、アラーム出力、ログ管理及び性能監視といったさらなる機能性を提供してもよい。
【００２５】
設定端末２００は、放送局システム１の運用に関連するユーザインタフェースをユーザへ提供する端末装置である。設定端末２００は、放送局システム１に専用のユーザ端末であってもよく、又はＰＣ（Personal  Computer）若しくはスマートフォンといった汎用的な端末であってもよい。設定端末２００は、例えば、ＩＰドメイン１０に属するノードに関連する情報のうちユーザにより設定可能な情報をユーザインタフェースを介して取得し、取得した情報を管理ノード１００へ送信する。また、設定端末２００は、例えば、ユーザインタフェースを介して所与の装置間のストリームの伝送を求めるリクエストを受け付け、リクエストメッセージを管理ノード１００へ送信する。
【００２６】
（２）ＩＰマルチキャスト
放送局システム１のＩＰドメイン１０内の制御メッセージの交換はユニキャストで行われ得るのに対し、放送素材を搬送するストリームの伝送は、典型的には、マルチキャストで行われる。マルチキャストされるパケットの送信元ＩＰアドレスは送信ノードのＩＰアドレスであり、宛先ＩＰアドレスは特定のアドレス範囲に属するマルチキャストアドレスである。個々のマルチキャストアドレスを宛先とするマルチキャストパケットを受信するノードの集合をマルチキャストグループといい、マルチキャストアドレスをグループアドレスともいう。あるストリームを受信することを意図する受信ノードは、そのストリームに対応するマルチキャストグループへの加入（join）を通知するメッセージ（例えば、ＩＧＭＰ（Internet  Group  Management  Protocol）  ＪＯＩＮ）を近傍のルータへ送信する。すると、ルータ間でマルチキャストツリーを更新するためのメッセージ交換が行われ、特定の送信ノードから送信されるストリームがＩＰネットワークを介して受信ノードへ配信されるようになる。受信ノードは、マルチキャストストリームの受信を終了する際には、マルチキャストグループからの離脱（leave）を通知するメッセージを近傍のルータへ送信する。なお、上述した例に限定されず、本開示に係る技術は、ストリームがユニキャストで伝送されるケースにも適用可能である。
【００２７】
（３）時刻同期
テレビジョン番組を正確なスケジュールに従って放送するためには、放送局システム１内の装置が正確な時刻を認識していることを要する。また、異なる複数のノードから受信されるストリームを多重化し、複数の映像を合成し、又は映像と音声とを同時に再生する場合にも、ノード間で時刻の精細な同期が確立されていることを要する。こうした時刻同期の目的のために、放送局システム１は、さらに１つ以上の時刻サーバ（図示せず）を含んでもよい。例えば、時刻サーバのうちの１つは、外部の時刻源（例えば、ＧＰＳ衛星又はＧＮＳＳ衛星）に同期するグランドマスタであり、残りの時刻サーバは、スレーブサーバであってもよい。時刻サーバ間及び時刻サーバと他のノードとの間の同期は、例えばＰＴＰ（Precision  Time  Protocol）に従って行われ得る。
【００２８】
（４）エッセンスとストリーム
上述したように、テレビジョン番組のコンテンツは、概して、映像データ、音声データ及び補助データという３種類の放送素材のデータから構成される。本明細書では、放送素材の種類を区別してこれらコンテンツの構成要素へ言及するために、「エッセンス」との語を用いる。言い換えると、エッセンスは、データとして表現された放送素材である。エッセンスをＩＰネットワーク上で伝送しようとする場合、エッセンスは、あるＩＰベースのプロトコルに従って、デジタル信号へ変換されパケット化される。エッセンスを搬送する一連のＩＰパケットには、ストリーム単位で共通するポート番号が付与される。即ち、ストリームは、ＩＰアドレス及びポート番号が共通するＩＰパケットのシーケンスであり得る。
【００２９】
（５）プロトコルごとのストリームタイプ
ストリーム伝送のためのプロトコルとしてＳＭＰＴＥ  ＳＴ２０２２−６が利用される場合、このプロトコルはＳＤＩ信号をそのままＩＰパケットへマッピングすることから、単一のストリームに異なる種類のエッセンスが混在する。ＳＭＰＴＥ  ＳＴ２１１０シリーズが利用される場合、異なる種類のエッセンスは異なるストリームにより搬送され、したがって単一のストリームは単一の種類のエッセンスのみを含む。ＡＲＩＢ  ＳＴＤ−Ｂ７３が利用される場合、単一のストリームに異なる種類のエッセンスが混在するが、ＳＤＩイメージとは異なりブランキング期間は含まれない。いずれのプロトコルにおいても、パケットは、アプリケーションレイヤではＲＴＰ（Real-time  Transport  Protocol）、トランスポートレイヤではＵＤＰ（User  Datagram  Protocol）に従って伝送される。
【００３０】
＜１−２．ＩＰドメインの論理的構成例＞
図２は、図１に示した放送局システム１のＩＰドメイン１０の論理的な構成の一例を示している（簡明さのために、ここではＡＰＳ４０は省略されている）。図２を参照すると、カメラ１４に相当する第１ノードは、センダ（sender）６０ａを含む。「センダ」とは、ストリームを送信する能力を有する機能エンティティである。ＩＰゲートウェイ２０ａに相当する第２ノードは、センダ６０ｂ、６０ｃ及び６０ｄを含む。センダ６０ｂ、６０ｃ及び６０ｄは、ＩＰゲートウェイ２０ａにより収容される個々のストリームの送信元の装置に相当し得る。モニタ１６に相当する第３ノードは、レシーバ７０ａを含む。「レシーバ」とは、ストリームを受信する能力を有する機能エンティティである。ＩＰゲートウェイ２０ｂに相当する第４ノードは、レシーバ７０ｂ及び７０ｃを含む。レシーバ７０ｂ及び７０ｃは、ＩＰゲートウェイ２０ｂにより収容される個々のストリームの受信先の装置に相当し得る。
【００３１】
上の説明から理解されるように、１つのノード（「カード」と呼ばれてもよい）は、１つの物理エンティティを表現する。図１の例に限定されず、１つのノードは、機能エンティティとして、任意の数のセンダ及び／又は任意の数のレシーバを含んでよい。また、１つのノード内で複数の機能エンティティを包含する論理的な単位（例えば、デバイス６２）が定義されてもよい（例えば、１つのＩＰゲートウェイに収容されるデバイスが複数のストリームを送信し又は受信するケース）。
【００３２】
例えば、ＡＭＷＡにより検討されているＮＭＯＳは、こうした論理的なシステムモデルを前提として、ＩＰドメインでのストリームの伝送を管理し及び制御するための制御インタフェースの仕様を規定する。管理ノード１００、設定端末２００及びその他のノードは、例えばこのＮＭＯＳに従って、放送局システム１を制御するためのメッセージを交換してもよい。例えば、ＮＭＯＳ  ＩＳ−０４は、ネットワークリソースの発見及び登録（Discovery  and  Registration）のためのＨＴＴＰ（Hypertext  Transfer  Protocol）ベースの制御インタフェースを提供する。ＮＭＯＳ  ＩＳ−０５は、デバイスの接続管理（Device  Connection  Management）のためのＨＴＴＰベースの制御インタフェースを提供する。なお、かかる例に限定されず、本開示に係る技術は、ＮＭＯＳ以外のいかなる標準化された又は非標準の制御インタフェース仕様を用いて実現されてもよい。
【００３３】
＜１−３．課題の説明＞
図１及び図２に例示したようなＩＰベースのネットワークアーキテクチャにおいては、これまでの放送事業者独自のアーキテクチャとは異なり、ＩＰ技術を利用する多様な装置がシステムへ参加し得る。これは、例えば、ＣＯＴＳのような汎用のネットワーク装置を用いてネットワークを低コストで構築することを可能にし、加えて、業務のニーズに応じてネットワーク構成を変更することも容易にする。例えば、利用可能ないくつかの装置を互いに接続して一時的なリモート制作環境を構築すること、及びＩＰネットワーク基盤上で仮想化される複数の論理的な制作環境を構築することも将来的に可能になると見込まれる。そうしたメリットの反面、システムへ参加するそれら多様な装置が送信し又は受信しようとするストリームの特性が送信側と受信側との間で相互に適合することは、必ずしも保証されない。例えば、ある装置はＳＭＰＴＥ  ＳＴ２０２２−６に従ってエッセンス混在型ストリームを送信する一方で、他の装置はＳＭＰＴＥ  ＳＴ２１１０に従って複数のエッセンス分離型ストリームを送信するかもしれない。
【００３４】
図３を用いて、この課題についてより詳しく説明する。図３には、図２に示した放送局システム１のＩＰドメイン１０の論理的な構成の一例が再び示されている。図３のシナリオにおいて、設定端末２００は、例えば、センダ６０ａからレシーバ７０ａへのストリームＳＴＲ１の伝送を求めるリクエストを受け付けたものとする。設定端末２００は、管理ノード１００へ制御メッセージＭ１を送信して、リクエストされたストリームＳＴＲ１のセットアップを管理ノード１００へ依頼する。管理ノード１００は、リクエストに応じて、制御メッセージＭ２をレシーバ７０ａへ送信して、ストリームＳＴＲ１のマルチキャストグループへの加入をレシーバ７０ａへ指示する。すると、レシーバ７０ａは、マルチキャストグループへの加入を通知するメッセージＭ３（例えば、ＩＧＭＰ  ＪＯＩＮ）をネットワークへ送信してマルチキャストグループへ加入する。その結果、ＩＰネットワークは、センダ６０ａからのストリームＳＴＲ１を（もしあれば他の既存の宛先と共に）レシーバ７０ａへ伝送するようになる。
【００３５】
しかしながら、センダ６０ａとレシーバ７０ａとの間でストリームタイプが適合しない（例えば、一方がエッセンス混在型ストリームを想定し、他方がエッセンス分離型ストリームを想定している）場合には、レシーバ７０ａは、ストリームＳＴＲ１を受信することはできても、ストリームＳＴＲ１により搬送されるエッセンスを適切に抽出してコンテンツを再生することができない。加えて、ストリームＳＴＲ１がエッセンス分離型ストリームである場合、ストリームＳＴＲ１は、映像データを搬送するかもしれず、音声データを搬送するかもしれず、又は補助データを搬送するかもしれない。そして、ストリームＳＴＲ１により搬送されるエッセンスのタイプがレシーバ７０ａにより期待されるエッセンスタイプに適合しない場合には、やはりストリームＳＴＲ１の伝送はネットワークリソースの無駄につながる。エッセンスタイプのみならず、例えば圧縮／非圧縮、適用される圧縮方式、及び適用される誤り訂正方式などといった他のストリームの属性が適合しない場合も同様である。また、こうしたストリームの特性（ストリームタイプ及び属性）の不適合は、受信側での予期しない動作不良をも引き起こしかねない。
【００３６】
そこで、本開示に係る技術は、上述した課題のうちの少なくとも１つを解消するために、ストリームのセットアップの際にセンダとレシーバとの間で特性が相互に適合するかを判定し、適合性が確保される場合にセットアップ手続を進める制御機能を、放送局システムに導入する。一例として、次節で説明する第１の実施形態では、当該制御機能は、管理ノードに実装される。後続する第２の実施形態では、当該制御機能は、設定端末に実装される。なお、これら例に限定されず、当該制御機能は、放送局システムのＩＰドメインに属するどのノードに実装されてもよい。
【００３７】
本明細書において、センダ６０ａ、６０ｂ、６０ｃ及び６０ｄを互いに区別する必要が無い場合には、符号の末尾のアルファベットを省略することによりこれらをセンダ６０と総称する。同様に、レシーバ７０ａ、７０ｂ及び７０ｃを互いに区別する必要が無い場合には、符号の末尾のアルファベットを省略することによりこれらをレシーバ７０と総称する。
【００３８】
＜＜２．第１の実施形態＞＞
第１の実施形態においては、管理ノード１００が放送局システム１を制御するための制御装置としての役割を有する。
【００３９】
＜２−１．管理ノードの構成例＞
図４は、第１の実施形態に係る管理ノード１００の構成の一例を示すブロック図である。図４を参照すると、管理ノード１００は、処理部１１０、記憶部１２０及び通信インタフェース１３０を備える。
【００４０】
（１）処理部
処理部１１０は、例えば、ＣＰＵ（Central  Processing  Unit）、ＭＰＵ（Micro  Processing  Unit）又はマイクロコントローラといった１つ以上のプロセッサを含む。処理部１１０は、記憶部１２０により記憶されるコンピュータプログラムを実行することにより、管理ノード１００の機能性を実現する。本実施形態において、処理部１１０は、例えば、情報管理部１５０、リクエスト処理部１６０、適合性判定部１７０及びストリーム制御部１８０として機能する。言い換えると、情報管理部１５０、リクエスト処理部１６０、適合性判定部１７０及びストリーム制御部１８０は、処理部１１０により実現される機能モジュールである。管理ノード１００の機能性について、後にさらに説明する。
【００４１】
（２）記憶部
記憶部１２０は、一時的な及び非一時的なコンピュータ読取可能なメモリを含む。一時的なメモリは、例えばＲＡＭ（Random  Access  Memory）を含み得る。非一時的なメモリは、例えばＲＯＭ（Read  Only  Memory）、ＨＤＤ（Hard  Disk  Drive）又はＳＳＤ（Solid  State  Drive）のうちの１つ以上を含み得る。記憶部１２０は、管理ノード１００の機能性を実現するためのコンピュータプログラムを記憶する。記憶部１２０は、さらに、管理ノード１００の動作において使用される様々なデータを記憶する。本実施形態において、記憶部１２０は、例えば、後に詳しく説明するノード情報データベース１２１を含む。
【００４２】
（３）通信インタフェース
通信インタフェース１３０は、管理ノード１００による他の装置との通信を仲介するインタフェースである。通信インタフェース１３０は、有線通信のための接続端子及び接続回路を含んでもよく、又は無線通信のためのアンテナ、ＲＦ（Radio  Frequency）回路及びベースバンド回路を含んでもよい。本実施形態において、通信インタフェース１３０は、例えば、ＬＡＮ（Local  Area  Network）通信のためのネットワークアダプタ又はネットワークカードであってよい。管理ノード１００は、ＩＰドメイン１０に属する任意のノードと通信インタフェース１３０を介して通信する。
【００４３】
（４）情報管理部
情報管理部１５０は、放送局システム１においてストリームを送信し又は受信するノードに関連する情報を、記憶部１２０のノード情報データベース１２１を用いて管理する。情報管理部１５０は、例えば、ＩＰネットワークへのノードの接続を監視し、ノードの接続が検出されると、接続されたノードから当該ノードの情報を取得する。ノードの接続の検出及びノード情報の取得は、何らかの標準化されたノード発見手続（例えば、ＮＭＯＳ  ＩＳ−０４）を通じて行われてもよい。
【００４４】
図５は、ノード情報データベース１２１により記憶される情報の構成の一例を示している。図５を参照すると、ノード情報データベース１２１は、１つ以上のノードの各々についてのノード情報１２２と、各ノード情報１２２に関連付けられるセンダの各々についてのセンダ情報１２４と、各ノード情報１２２に関連付けられるレシーバの各々についてのレシーバ情報１２６とを含む。
【００４５】
（４−１）ノード情報
ノード情報１２２は、例えば、情報項目として「ノード名」及び「ＩＰアドレス」を含む。「ノード名」は、当該ノードの名称を示す。「ＩＰアドレス」は、当該ノードに静的に又は動的に割り当てられるＩＰアドレスを示す。これら情報項目のうち、「ノード名」及び（静的に割り当てられる場合の）「ＩＰアドレス」は、ユーザにより設定され得る。
【００４６】
（４−２）センダ情報
上で説明したように、各ノードは、センダを含まなくてもよく、又は１つ以上のセンダを含んでもよい。各センダのセンダ情報１２４は、例えば、情報項目として「センダ名」、「ストリームタイプ」、「エッセンスタイプ」、「メディアタイプ」、「送信マルチキャストアドレス」、「送信ポート番号」、「ＦＥＣ有効」及び「ＲＴＣＰ有効」を含む。「センダ名」は、当該センダの名称を示す。
【００４７】
「ストリームタイプ」は、当該センダによりサポートされるストリームのタイプを示す。一例として、「ストリームタイプ」の候補は、エッセンス混在型ストリーム（単に「混在型」ともいう）及びエッセンス分離型ストリーム（単に「分離型」ともいう）であってよい。例えば、エッセンス混在型ストリームは、ＳＭＰＴＥ  ＳＴ２０２２−６又はＡＲＩＢ  ＳＴＤ−Ｂ７３に準拠するストリームであってもよく、エッセンス分離型ストリームはＳＭＰＴＥ  ＳＴ２１１０に準拠するストリームであってもよい。
【００４８】
「エッセンスタイプ」は、「ストリームタイプ」が「分離型」を示す場合、即ちセンダがエッセンス分離型ストリームの送信をサポートする場合にセンダ情報１２４に含められ得る。「エッセンスタイプ」は、当該センダにより送信されるストリームに含まれるエッセンスのタイプを示す。一例として、「エッセンスタイプ」の候補は、次のうちの１つ以上を含み得る：
−映像
−音声
−補助データ
なお、「ストリームタイプ」及び「エッセンスタイプ」が次のような候補を有する１つの情報項目へ統合されてもよい：
−混在
−映像
−音声
−補助データ
この場合、「混在」は、サポートされるストリームタイプがエッセンス混在型ストリームであることを表す。「映像」は、サポートされるストリームタイプがエッセンス分離型ストリームであって、エッセンスタイプが映像であることを表す。「音声」は、サポートされるストリームタイプがエッセンス分離型ストリームであって、エッセンスタイプが音声であることを表す。「補助データ」は、サポートされるストリームタイプがエッセンス分離型ストリームであって、エッセンスタイプが補助データであることを表す。
【００４９】
「メディアタイプ」は、「ストリームタイプ」が「分離型」を示す場合にセンダ情報１２４に含められ得る。「メディアタイプ」は、「エッセンスタイプ」により示されるタイプのエッセンスを解釈する際に要するサブタイプ情報又はフォーマット情報として理解されてよい。例えば、映像及び音声についての「メディアタイプ」は、圧縮／非圧縮、及び（圧縮される場合の）適用される圧縮方式を示し得る。補助データについての「メディアタイプ」は、例えばフォーマット名称（ＳＭＰＴＥ  ＳＴ２９１など）を示し得る。
【００５０】
「送信マルチキャストアドレス」は、当該センダにより送信されるストリームの宛先ＩＰアドレスとして使用されるマルチキャストアドレスを示す。「送信ポート番号」は、当該センダにより送信されるストリームの送信側ＵＤＰポート番号を示す。エッセンス混在型ストリームの場合には、映像、音声及び補助データを含み得る単一のストリームに１つのポート番号が付与され、そのポート番号が単一のセンダに関連付けられる。エッセンス分離型ストリームの場合には、映像を含むストリーム、音声を含むストリーム、及び補助データを含むストリームにそれぞれ異なるポート番号が付与され、それらは別個のセンダに関連付けられる。
【００５１】
「ＦＥＣ有効」は、当該センダにより送信されるストリームに前方誤り訂正（ＦＥＣ）が適用されるか否かを示すフラグである。「ＲＴＣＰ有効」は、当該センダにより送信されるストリームについてＲＴＣＰ（Real-time  Transport  Control  Protocol）が有効化されるか否かを示すフラグである。ＲＴＣＰは、サービス品質に関する統計情報の収集及びレポーティングのためのプロトコルである。
【００５２】
これら情報項目のうち、「センダ名」、「送信マルチキャストアドレス」、「送信ポート番号」、「ＦＥＣ有効」及び「ＲＴＣＰ有効」は、ユーザにより設定され得る。「ストリームタイプ」、「エッセンスタイプ」及び「メディアタイプ」は、典型的には、当該センダに対応する装置において予め設定され、接続検出時に情報管理部１５０により取得される。
【００５３】
（４−３）レシーバ情報
上で説明したように、各ノードは、レシーバを含まなくてもよく、又は１つ以上のレシーバを含んでもよい。各レシーバのレシーバ情報１２６は、例えば、情報項目として「レシーバ名」、「ストリームタイプ」、「エッセンスタイプ」、「メディアタイプ」、「加入マルチキャストアドレス」、「受信ポート番号」、「ＦＥＣ有効」及び「ＲＴＣＰ有効」を含む。「レシーバ名」は、当該レシーバの名称を示す。
【００５４】
「ストリームタイプ」は、当該レシーバによりサポートされるストリームのタイプを示す。一例として、「ストリームタイプ」の候補は、エッセンス混在型ストリーム及びエッセンス分離型ストリームであってよい。例えば、エッセンス混在型ストリームは、ＳＭＰＴＥ  ＳＴ２０２２−６又はＡＲＩＢ  ＳＴＤ−Ｂ７３に準拠するストリームであってもよく、エッセンス分離型ストリームはＳＭＰＴＥ  ＳＴ２１１０に準拠するストリームであってもよい。
【００５５】
「エッセンスタイプ」は、「ストリームタイプ」が「分離型」を示す場合、即ちレシーバがエッセンス分離型ストリームの受信をサポートする場合にレシーバ情報１２４に含められ得る。「エッセンスタイプ」は、当該レシーバにより受信可能なエッセンスのタイプを示す。一例として、「エッセンスタイプ」の候補は、次のうちの１つ以上を含み得る：
−映像
−音声
−補助データ
なお、「ストリームタイプ」及び「エッセンスタイプ」が次のような候補を有する１つの情報項目へ統合されてもよい：
−混在
−映像
−音声
−補助データ
これら候補値の意味は、センダ情報１２４のケースと同様である。
【００５６】
「メディアタイプ」は、「ストリームタイプ」が「分離型」を示す場合にレシーバ情報１２４に含められ得る。「メディアタイプ」は、「エッセンスタイプ」により示されるタイプのエッセンスを解釈する際に当該レシーバが想定するサブタイプ情報又はフォーマット情報として理解されてよい。例えば、映像及び音声についての「メディアタイプ」は、圧縮／非圧縮、及び（圧縮される場合の）適用される圧縮方式を示し得る。補助データについての「メディアタイプ」は、例えばフォーマット名称を示し得る。
【００５７】
「加入マルチキャストアドレス」は、当該レシーバが特定のストリームを受信するようにセットアップ済みである場合に、そのストリームのマルチキャストアドレスを示す。「受信ポート番号」は、当該レシーバにより受信されるストリームの受信側ＵＤＰポート番号を示す。
【００５８】
「ＦＥＣ有効」は、当該レシーバがストリームを受信する際にＦＥＣを適用するか否かを示すフラグである。「ＲＴＣＰ有効」は、当該レシーバにより受信されるストリームについてＲＴＣＰが有効化されるか否かを示すフラグである。
【００５９】
これら情報項目のうち、「レシーバ名」、「ＦＥＣ有効」及び「ＲＴＣＰ有効」は、ユーザにより設定され得る。「ストリームタイプ」、「エッセンスタイプ」及び「メディアタイプ」は、典型的には、当該レシーバに対応する装置において予め設定され、接続検出時に情報管理部１５０により取得される。「加入マルチキャストアドレス」及び「受信ポート番号」は、ストリームのセットアップ時に情報管理部１５０により取得される。
【００６０】
なお、図５に示したデータ構成は、説明のための一例に過ぎない。ノード情報データベース１２１は、追加的な情報項目を含んでもよく、又は図示した項目のうちの一部が省略されてもよい。例えば、センダ又はレシーバが複数の属性値の候補をサポートする場合に、それら候補を示す情報（即ち、ケイパビリティ情報）と、現在設定され又は利用されている属性値を示す情報（即ち、設定情報）とが別々に記憶されてもよい。
【００６１】
（５）リクエスト処理部
リクエスト処理部１６０は、センダ６０からレシーバ７０へのストリームの伝送を求めるリクエストを取得する。したがって、リクエスト処理部１６０は、「リクエスト取得部」として言及されてもよい。リクエスト処理部１６０は、例えば、センダ６０からレシーバ７０へのストリームの伝送についてのユーザリクエストを受け付けた設定端末２００から、当該ストリームの伝送を求めるリクエストメッセージを通信インタフェース（通信部ともいう）１３０を介して受信する。リクエスト処理部１６０は、リクエストメッセージの受信に応じて、指定されたセンダ６０とレシーバ７０との間のストリームの特性についての適合性を適合性判定部１７０に判定させる。後述するように、特性が適合する場合には、リクエストされたストリームの伝送がストリーム制御部１８０によりセットアップされる。特性が適合しない場合には、リクエストされたストリームの伝送はストリーム制御部１８０により拒否され得る。リクエスト処理部１６０は、こうした処理の結果を示すレスポンスメッセージを通信インタフェース１３０を介して設定端末２００へ返送する。なお、上の例に限定されず、リクエスト処理部１６０は、設定端末２００以外の装置から、ストリームの伝送を求めるリクエストメッセージを受信してもよい。
【００６２】
（６）適合性判定部
適合性判定部１７０は、リクエスト処理部１６０による上述したリクエストメッセージの受信に応じて、指定されたセンダ６０のセンダ情報１２４及び指定されたレシーバ７０のレシーバ情報１２６をノード情報データベース１２１から読み出す。そして、適合性判定部１７０は、それらセンダ６０及びレシーバ７０の間で特性が適合するかを判定する。
【００６３】
（６−１）適合性判定の第１の例
適合性判定部１７０における適合性判定の第１の例において、判定の対象は、ストリームタイプ及びエッセンスタイプである。例えば、適合性判定部１７０は、まず、センダ６０によりサポートされるストリームタイプがレシーバ７０によりサポートされるストリームタイプに適合するかを判定する。例えば、ストリームタイプの候補は、エッセンス混在型ストリーム及びエッセンス分離型ストリームを含む。センダ６０のストリームタイプがレシーバ７０のストリームタイプとは異なる場合、適合性は否定される。一方、それらストリームタイプが等しく、センダ６０及びレシーバ７０が共にエッセンス混在型ストリームの送信又は受信をサポートする場合、エッセンスタイプの適合性が判定されることなく、適合性は肯定される。センダ６０及びレシーバ７０が共にエッセンス分離型ストリームの送信又は受信をサポートする場合、適合性判定部１７０は、センダ６０の送信エッセンスタイプがレシーバ７０の受信エッセンスタイプに適合するかをさらに判定する。センダ６０の送信エッセンスタイプがレシーバ７０の受信エッセンスタイプとは異なる場合、適合性は否定される。一方、センダ６０の送信エッセンスタイプがレシーバ７０の受信エッセンスタイプに等しい場合、適合性は肯定される。
【００６４】
図６Ａ〜図６Ｃは、上述した適合性判定の第１の例におけるいくつかの判定結果の例を示している。図６Ａの例では、センダ情報１２４ａのストリームタイプがレシーバ情報１２６ａのストリームタイプとは異なる結果として、ストリームの特性は適合しないと判定される（図中のＸ印参照）。図６Ｂの例では、センダ情報１２４ａのストリームタイプはレシーバ情報１２６ｂのストリームタイプに適合するものの、センダ情報１２４ａのエッセンスタイプがレシーバ情報１２６ｂのエッセンスタイプとは異なる結果として、ストリームの特性は適合しないと判定される（図中のＸ印参照）。図６Ｃの例では、センダ情報１２４ａのストリームタイプがレシーバ情報１２６ｃのストリームタイプに適合し、かつセンダ情報１２４ａのエッセンスタイプがレシーバ情報１２６ｃのエッセンスタイプに適合する結果として、ストリームの特性は適合すると判定される。
【００６５】
（６−２）適合性判定の第２の例
適合性判定部１７０における適合性判定の第２の例において、判定の対象は、ストリームタイプ、エッセンスタイプ及びメディアタイプである。例えば、適合性判定部１７０は、第１の例におけるストリームタイプ及びエッセンスタイプの適合性の判定に加えて、メディアタイプの適合性を判定する。より具体的には、適合性判定部１７０は、センダ６０の送信エッセンスタイプがレシーバ７０の受信エッセンスタイプに適合する場合に、センダ６０の送信メディアタイプがレシーバ７０の受信メディアタイプに適合するかをさらに判定する。送信メディアタイプが受信メディアタイプとは異なる場合、適合性は否定される。一方、送信メディアタイプが受信メディアタイプに等しい場合、適合性は肯定される。
【００６６】
図７Ａ及び図７Ｂは、上述した適合性判定の第２の例におけるいくつかの判定結果の例を示している。図７Ａの例では、センダ情報１２４ｄのメディアタイプがレシーバ情報１２６ｄのメディアタイプとは異なる結果として、ストリームの特性は適合しないと判定される（図中のＸ印参照）。図７Ｂの例では、センダ情報１２４ｄのメディアタイプがレシーバ情報１２６ｅのメディアタイプに適合する（かつ、ストリームタイプ及びエッセンスタイプも適合する）結果として、ストリームの特性は適合すると判定される。
【００６７】
（６−３）適合性判定の第３の例
適合性判定部１７０における適合性判定の第３の例において、判定の対象は、ストリームタイプ、エッセンスタイプ及びメディアタイプに加えて、他の属性を含む。他の属性とは、例えばＦＥＣ設定及びＲＴＣＰ設定のうちの一方又は双方を含む。例えば、適合性判定部１７０は、第２の例におけるストリームタイプ、エッセンスタイプ及びメディアタイプの適合性の判定に加えて、センダ６０のＦＥＣ設定がレシーバ７０のＦＥＣ設定に適合するかを判定してもよい。追加的に又は代替的に、適合性判定部１７０は、センダ６０のＲＴＣＰ設定がレシーバ７０のＲＴＣＰ設定に適合するかを判定してもよい。判定対象の属性のうちの１つ以上がセンダ６０とレシーバ７０との間で異なる場合、適合性は否定される。一方、判定対象の属性がセンダ６０とレシーバ７０との間で全て等しい場合、適合性は肯定される。
【００６８】
図８Ａ〜図８Ｃは、上述した適合性判定の第３の例におけるいくつかの判定結果の例を示している。図８Ａの例では、センダ情報１２４ｆがＦＥＣが有効であることを示すのに対しレシーバ情報１２６ｆはＦＥＣが有効でないことを示す結果として、ストリームの特性は適合しないと判定される（図中のＸ印参照）。図８Ｂの例では、センダ情報１２４ｆがＲＴＣＰが有効であることを示すのに対しレシーバ情報１２６ｇはＲＴＣＰが有効でないことを示す結果として、ストリームの特性は適合しないと判定される（図中のＸ印参照）。
図８Ｃの例では、センダ情報１２４ｆがＦＥＣ及びＲＴＣＰが共に有効であることを示すのに対しレシーバ情報１２６ｈもまたＦＥＣ及びＲＴＣＰが共に有効であることを示す結果として、ストリームの特性は適合すると判定される。
【００６９】
なお、放送局システム１においてサポートされ得るストリームタイプが１タイプしか存在しない（例えば、エッセンス分離型ストリームのみがサポートされる）場合には、第１の例、第２の例又は第３の例のいずれにおいても、ストリームタイプの適合性の判定が省略されてもよい。
【００７０】
適合性判定部１７０は、リクエストメッセージにおいて指定されたセンダ６０及びレシーバ７０の間でストリームの特性についてこのように適合性を判定した判定結果を、ストリーム制御部１８０へ出力する。
【００７１】
（７）ストリーム制御部
ストリーム制御部１８０は、適合性判定部１７０から入力される適合性判定の結果に基づいてストリーム制御を実行する。より具体的には、ストリーム制御部１８０は、指定されたセンダ６０とレシーバ７０との間で特性が適合すると判定された場合には、リクエストされたストリームの伝送をセットアップする。一方、ストリーム制御部１８０は、指定されたセンダ６０とレシーバ７０との間で特性が適合しないと判定された場合には、センダ６０からレシーバ７０へのストリームの伝送をセットアップすることを拒否し得る。
【００７２】
より具体的には、ストリーム制御部１８０は、図６Ａ〜図６Ｃに関連して説明した第１の例において、センダ６０及びレシーバ７０のストリームタイプが共にエッセンス混在型ストリームであると判定される場合に、センダ６０からレシーバ７０へのエッセンス混在型ストリームの伝送をセットアップする。また、ストリーム制御部１８０は、センダ６０及びレシーバ７０のストリームタイプが共にエッセンス分離型ストリームであって、かつセンダ６０の送信エッセンスタイプがレシーバ７０の受信エッセンスタイプに適合すると判定される場合に、センダ６０からレシーバ７０へのエッセンス分離型ストリームの伝送をセットアップする。一方、ストリーム制御部１８０は、センダ６０及びレシーバ７０のストリームタイプが異なると判定される場合、又は、センダ６０及びレシーバ７０のストリームタイプが共にエッセンス分離型ストリームであって、かつセンダ６０の送信エッセンスタイプがレシーバ７０の受信エッセンスタイプに適合しないと判定される場合に、リクエストされたストリームの伝送をセットアップすることを拒否し得る。
【００７３】
図７Ａ及び図７Ｂに関連して説明した第２の例において、ストリーム制御部１８０は、センダ６０及びレシーバ７０のストリームタイプが共にエッセンス分離型ストリームであって、送信エッセンスタイプが受信エッセンスタイプに適合し、かつセンダ６０の送信メディアタイプがレシーバ７０の受信メディアタイプに適合すると判定される場合に、センダ６０からレシーバ７０へのエッセンス分離型ストリームの伝送をセットアップする。一方、ストリーム制御部１８０は、センダ６０及びレシーバ７０のストリームタイプが共にエッセンス分離型ストリームであって送信エッセンスタイプが受信エッセンスタイプに適合するものの、センダ６０の送信メディアタイプがレシーバ７０の受信メディアタイプに適合しないと判定される場合に、リクエストされたストリームの伝送をセットアップすることを拒否し得る。
【００７４】
図８Ａ〜図８Ｃに関連して説明した第３の例において、ストリーム制御部１８０は、上述した第１の例又は第２の例における条件に加えて、センダ６０の追加的な設定がレシーバ７０の追加的な設定に適合すると判定される場合に、センダ６０からレシーバ７０へのストリームの伝送をセットアップする。追加的な設定とは、上述したＦＥＣ設定及びＲＴＣＰ設定のうちの一方又は双方を含み得る。一方、ストリーム制御部１８０は、そうした追加的な設定が適合しないと判定される場合に、リクエストされたストリームの伝送をセットアップすることを拒否し得る。
【００７５】
概して、ストリーム制御部１８０は、センダ６０とレシーバ７０との間で、エッセンスタイプ、メディアタイプ、ＦＥＣ設定及びＲＴＣＰ設定のうちの少なくとも１つが適合しないと判定される場合には、センダ６０からレシーバ７０へのリクエストされたストリームの伝送をセットアップすることを拒否してよい。ストリーム制御部１８０は、セットアップを拒否する場合に、リクエスト処理部１６０に、リクエスト元の装置（例えば、設定端末２００）へセットアップの拒否を示すレスポンスメッセージを送信することを指示し得る。セットアップの拒否を示すレスポンスメッセージは、セットアップが拒否された原因（例えば、エッセンスタイプ、メディアタイプ又はその他の属性の不適合）を示す原因コードを含んでもよい。
【００７６】
代替的に、ストリーム制御部１８０は、適合しないと判定された属性について、センダ６０又はレシーバ７０の一方が属性を変更できる可能性がある場合に、ストリームの属性の変更についてセンダ６０又はレシーバ７０の当該一方と交渉してもよい。一例として、ストリーム制御部１８０は、センダ６０の送信メディアタイプがレシーバ７０の受信メディアタイプに適合しないと判定される場合に、送信メディアタイプと受信メディアタイプとの不適合が解消されるようにセンダ６０又はレシーバ７０と交渉し得る。より具体的には、例えば、ストリーム制御部１８０は、未圧縮の映像ストリーム、Ｈ．２６４で圧縮された映像ストリーム及びＨ．２６５で圧縮された映像ストリームを受信し及び再生する能力を有するレシーバに、所望のストリームの圧縮方式に合わせてメディアタイプを変更するように交渉してもよい。また、ストリーム制御部１８０は、レシーバ側の要件に合わせてメディアタイプを変更するようにセンダとの交渉を行ってもよい。交渉は、例えば、変更を提案する制御メッセージの送信と、提案の受入れ又は拒否を示すレスポンスメッセージの受信とを含み得る。それにより、リクエストの試行及び失敗の繰り返しに起因するリソースの無駄を回避して効率的にストリームをセットアップすることができる。交渉が最終的に不成功に終わる場合には、ストリーム制御部１８０は、リクエスト処理部１６０に、リクエスト元の装置へセットアップの拒否を示すレスポンスメッセージを送信することを指示し得る。
【００７７】
ストリーム制御部１８０は、指定されたセンダ６０からレシーバ７０への上記ストリームの伝送をセットアップする際、ノード情報データベース１２１を参照して、センダ６０のセンダ情報１２４に含まれる送信マルチキャストアドレス及び送信ポート番号を取得する。そして、ストリーム制御部１８０は、取得した情報により特定されるマルチキャストグループへの加入をレシーバ７０へ指示する。マルチキャストグループへの加入の指示は、何らかの標準化された制御手続（例えば、ＮＭＯＳ  ＩＳ−０５）を通じて行われてもよい。上述した指示を受信したレシーバ７０は、指定されたマルチキャストグループへの加入を通知するメッセージ（例えば、ＩＧＭＰ  ＪＯＩＮ）を近傍のネットワーク装置１２へ送信する。すると、ネットワーク装置１２間でマルチキャストツリーを更新するためのメッセージ交換が行われ、指定されたマルチキャストグループのマルチキャストアドレスを宛先とするストリームがＩＰネットワークを介してレシーバ７０へ配信されるようになる。
【００７８】
レシーバ７０は、マルチキャストグループへの加入に応じて、加入したマルチキャストグループの識別情報をタイムスタンプと共に管理ノード１００へ報告する。例えば、情報管理部１５０は、レシーバ７０からの報告に応じて、ノード情報データベース１２１のレシーバ情報１２６の「加入マルチキャストアドレス」及び「受信ポート番号」を更新し得る。ストリーム制御部１８０は、レシーバ７０が加入したマルチキャストグループに関連する識別情報をレシーバ７０及び／又は伝送経路上のネットワーク装置１２へ問合せ、返送される識別情報を検証することにより、上記ストリームの伝送が成功裏にセットアップされたか否かを追加的に判定してもよい。例えば、ノード情報データベース１２１内の最新の「加入マルチキャストアドレス」（及び「受信ポート番号」）が返送されるマルチキャストアドレス（及びポート番号）と等しい場合には、ストリームの伝送は成功裏にセットアップされたと判定され得る。それにより、マルチキャストストリームの確立を保証すること、あるいは何らかの原因（例えば、ネットワーク装置の障害又はマルチキャストツリーの更新の遅延など）によるセットアップの不成功を検出することができる。
【００７９】
ストリーム制御部１８０は、ストリーム制御の結果を、上位装置へ通知してもよい。例えば、ストリーム制御部１８０は、リクエスト処理部１６０に、セットアップが成功したことを示すレスポンスメッセージをリクエスト元の装置へ送信することを指示し得る。リクエスト処理部１６０は、リクエスト元の装置以外の他の装置（例えば、ＡＰＳ４０など）にもストリーム制御の結果を通知してもよい。こうした制御結果の通知は、例えば「タリー」と呼ばれてもよい。
【００８０】
＜２−２．設定端末の構成例＞
図９は、第１の実施形態に係る設定端末２００の構成の一例を示すブロック図である。図９を参照すると、設定端末２００は、処理部２１０、記憶部２２０、通信インタフェース２３０及びユーザインタフェース２４０を備える。
【００８１】
（１）処理部
処理部２１０は、例えば、ＣＰＵ、ＭＰＵ又はマイクロコントローラといった１つ以上のプロセッサを含む。処理部２１０は、記憶部２２０により記憶されるコンピュータプログラムを実行することにより、設定端末２００の機能性を実現する。本実施形態において、処理部２１０は、例えば、リクエスト受付部２５０及び情報表示部２９０として機能する。言い換えると、リクエスト受付部２５０及び情報表示部２９０は、処理部２１０により実現される機能モジュールである。設定端末２００の機能性について、後にさらに説明する。
【００８２】
（２）記憶部
記憶部２２０は、一時的な及び非一時的なコンピュータ読取可能なメモリを含む。一時的なメモリは、例えばＲＡＭを含み得る。非一時的なメモリは、例えばＲＯＭ、ＨＤＤ又はＳＳＤのうちの１つ以上を含み得る。記憶部２２０は、設定端末２００の機能性を実現するためのコンピュータプログラムを記憶する。記憶部２２０は、さらに、設定端末２００の動作において使用される様々なデータを記憶する。
【００８３】
（３）通信インタフェース
通信インタフェース２３０は、設定端末２００による他の装置との通信を仲介するインタフェースである。通信インタフェース２３０は、有線通信のための接続端子及び接続回路を含んでもよく、又は無線通信のためのアンテナ、ＲＦ回路及びベースバンド回路を含んでもよい。本実施形態において、通信インタフェース１３０は、例えば、ＬＡＮ通信のためのネットワークアダプタ又はネットワークカードであってよい。設定端末２００は、例えば、管理ノード１００及びその他のノードと通信インタフェース２３０を介して通信する。
【００８４】
（４）ユーザインタフェース
ユーザインタフェース２４０は、ユーザからの指示又は情報入力を受け付けるための入力デバイスと、情報を出力するための出力デバイスとを含み得る。入力デバイスは、例えば、キーボード、キーパッド、タッチパネル及びポインティングデバイスのうちの１つ以上を含んでよい。出力デバイスは、例えば、ディスプレイ、プリンタ及びスピーカのうちの１つ以上を含んでよい。
【００８５】
（５）リクエスト受付部
リクエスト受付部２５０は、センダ６０からレシーバ７０へのストリームの伝送を求めるリクエストであって、ユーザインタフェース２４０がユーザから受け付ける当該リクエストを取得する。例えば、リクエスト受付部２５０は、ディスプレイの画面上に表示されるＧＵＩ（Graphical  User  Interface）を介してリクエストを取得してもよい。その代わりに、リクエスト受付部２５０は、ＣＬＩ（Command  Line  Interface）などの他の手段を介してリクエストを取得してもよい。リクエスト受付部２５０は、リクエストの受け付けに応じて、センダ６０からレシーバ７０へのストリームの伝送を求めるリクエストメッセージを通信インタフェース２３０を介して管理ノード１００へ送信する。
【００８６】
（６）情報表示部
情報表示部２９０は、放送局システム１内の各ノードに関連する情報を管理ノード１００から取得し、ユーザインタフェース２４０を介してユーザに表示する。情報は、ＧＵＩ又はＣＬＩなどのいかなる形式で表示されてもよい。情報表示部２９０は、ユーザにより設定可能な設定情報をユーザが新たに入力し、変更し又は削除するための入力手段（例えば、ＧＵＩの設定ウィンドウなど）を提供してもよい。
【００８７】
＜２−３．処理の流れ＞
次に、図１０〜図１２Ｅを用いて、上述した放送局システム１において実行され得る主な処理の流れについて説明する。
【００８８】
（１）ノード情報の収集
図１０は、本実施形態において管理ノード１００がノード情報を収集する処理の流れの一例を示すシーケンス図である。図１０に示した処理には、センダ６０、レシーバ７０、管理ノード１００及び設定端末２００が関与する。
【００８９】
まず、管理ノード１００（例えば、情報管理部１５０）は、所定のノード発見手続を通じて、ＩＰネットワークへ接続したセンダ６０を発見する（ステップＳ１０１）。センダ６０は、例えば問合せに応じて、ノード情報及びセンダ情報を管理ノード１００へ送信する（ステップＳ１０３）。一例として、ノード情報及びセンダ情報は、ＳＤＰ（Session  Description  Protocol）形式で予めセンダ６０において記述されている。管理ノード１００（例えば、情報管理部１５０）は、センダ６０から取得されるノード情報及びセンダ情報をノード情報データベース１２１に登録する（ステップＳ１０５）。
【００９０】
次いで、管理ノード１００（例えば、情報管理部１５０）は、所定のノード発見手続を通じて、ＩＰネットワークへ接続したレシーバ７０を発見する（ステップＳ１１１）。レシーバ７０は、例えば問合せに応じて、ノード情報及びレシーバ情報を管理ノード１００へ送信する（ステップＳ１１３）。一例として、ノード情報及びレシーバ情報は、ＳＤＰ形式で予めレシーバ７０において記述されている。管理ノード１００（例えば、情報管理部１５０）は、レシーバ７０から取得されるノード情報及びレシーバ情報をノード情報データベース１２１に登録する（ステップＳ１１５）。
【００９１】
なお、図１０の例に関わらず、ノード、センダ及びレシーバの発見は、どのようなタイミングで行われてもよい。また、１つよりも多くのセンダ又はレシーバが発見されてもよい。
【００９２】
次いで、設定端末２００（例えば、リクエスト受付部２５０）は、ユーザにより追加的に入力される設定情報の登録を求めるメッセージを管理ノード１００へ送信する（ステップＳ１２１）。管理ノード１００（例えば、リクエスト処理部１６０）は、当該メッセージを通信インタフェース１３０を介して受信する。管理ノード１００（例えば、情報管理部１５０）は、当該メッセージの受信に応じて、ユーザにより入力された設定情報をノード情報データベース１２１に追加的に登録する（ステップＳ１２３）。管理ノード１００（例えば、情報管理部１５０）は、データベースの更新の結果を設定端末２００へ通知する（ステップＳ１２５）。設定端末２００（例えば、情報表示部２９０）は、更新された情報をユーザインタフェース２４０を介してユーザに表示する（ステップＳ１２７）。
【００９３】
（２）ストリームのセットアップ
図１１は、本実施形態におけるストリーム伝送のリクエストからストリームのセットアップまでの処理の流れの一例を示すシーケンス図である。図１１に示した処理には、ネットワーク装置１２、センダ６０、レシーバ７０、管理ノード１００及び設定端末２００が関与する。
【００９４】
まず、設定端末２００（例えば、リクエスト受付部２５０）は、ユーザにより入力され得るリクエストの受け付けに応じて、センダ６０からレシーバ７０へのストリームの伝送を求めるリクエストメッセージを管理ノード１００へ送信する（ステップＳ１３１）。管理ノード１００（例えば、リクエスト処理部１６０）は、当該リクエストメッセージを通信インタフェース１３０を介して受信する。
【００９５】
次いで、管理ノード１００（例えば、適合性判定部１７０）は、センダ−レシーバ適合性判定処理を実行して、指定されたセンダ６０及びレシーバ７０の間で特性が適合するかを判定する（ステップＳ１４０）。センダ−レシーバ適合性判定処理のより詳細な流れについて後に説明する。ここでは、適合性判定処理の結果として、適合性が肯定されたものとする。
【００９６】
管理ノード１００（例えば、ストリーム制御部１８０）は、適合性が肯定されたという判定結果に基づいて、ノード情報データベース１２１から取得される識別情報（例えば、センダ６０の送信マルチキャストアドレス及び送信ポート番号）により識別されるマルチキャストグループへの加入をレシーバ７０へ指示する（ステップＳ１６１）。レシーバ７０は、マルチキャストグループへの加入を通知するメッセージを近傍のネットワーク装置１２へ送信することにより、指定された当該マルチキャストグループへ加入する（ステップＳ１６３）。また、レシーバ７０は、管理ノード１００から受信したマルチキャスト加入指示に対するレスポンスを送信する（ステップＳ１６５）。管理ノード１００（例えば、情報管理部１５０）は、レシーバ７０からのレスポンスの受信に応じて、ノード情報データベース１２１を更新する（ステップＳ１６７）。
【００９７】
次いで、管理ノード１００（例えば、ストリーム制御部１８０）は、レシーバ７０が加入したマルチキャストグループに関連する識別情報をレシーバ７０へ問合せ、返送される識別情報を検証する（ステップＳ１６９）。それにより、管理ノード１００（例えば、ストリーム制御部１８０）は、リクエストされたストリームの伝送が成功裏にセットアップされたか否かを判定し得る。次いで、管理ノード１００（例えば、リクエスト処理部１６０）は、リクエストされたストリームのセットアップが成功したことを設定端末２００へ通知する（ステップＳ１７１）。
【００９８】
一方、ステップＳ１６３におけるレシーバ７０によるマルチキャストグループへの加入の結果として、センダ６０から送信されるストリームのネットワーク装置１２を介するレシーバ７０への伝送が開始される（ステップＳ１８０）。
【００９９】
（３）センダ−レシーバ適合性判定処理
（３−１）第１の例
図１２Ａは、図１１のステップＳ１４０において管理ノード１００により実行されるセンダ−レシーバ適合性判定処理の流れの第１の例を示すフローチャートである。ここでの第１の例では、エッセンスタイプの適合性のみが判定され、ストリームタイプの適合性の判定は省略される。センダ６０及びレシーバ７０は、共にエッセンス分離型ストリームの送信又は受信をサポートするものとする。
【０１００】
図１２Ａを参照すると、まず、センダ６０からレシーバ７０へのストリームの伝送を求めるリクエストが取得される（ステップＳ１４１）。当該リクエストは、典型的には、放送局システム１内のあるセンダ６０と少なくとも１つのレシーバ７０とを指定する。
【０１０１】
適合性判定部１７０は、リクエストの取得に応じて、指定されたセンダ６０のセンダ情報１２４及び指定されたレシーバ７０のレシーバ情報１２６をノード情報データベース１２１から取得する（ステップＳ１４２）。
【０１０２】
次いで、適合性判定部１７０は、センダ６０のエッセンスタイプ（即ち、送信エッセンスタイプ）がレシーバ７０のエッセンスタイプ（即ち、受信エッセンスタイプ）に適合するかを判定する（ステップＳ１４４）。
【０１０３】
送信エッセンスタイプが受信エッセンスタイプに適合すると判定される場合、適合性判定部１７０は、リクエストされたストリームの伝送をセットアップすることを決定し得る（ステップＳ１４８）。一方、送信エッセンスタイプが受信エッセンスタイプに適合しないと判定される場合、適合性判定部１７０は、リクエストを拒否することを決定し得る（ステップＳ１４９）。
【０１０４】
（３−２）第２の例
図１２Ｂは、図１１のステップＳ１４０において管理ノード１００により実行されるセンダ−レシーバ適合性判定処理の流れの第２の例を示すフローチャートである。ここでの第２の例では、エッセンスタイプ及びメディアタイプ（並びに、オプションとして他の属性）の適合性が判定され、ストリームタイプの適合性の判定は省略される。センダ６０及びレシーバ７０は、共にエッセンス分離型ストリームの送信又は受信をサポートするものとする。
【０１０５】
図１２Ｂを参照すると、まず、センダ６０からレシーバ７０へのストリームの伝送を求めるリクエストが取得される（ステップＳ１４１）。当該リクエストは、典型的には、放送局システム１内のあるセンダ６０と少なくとも１つのレシーバ７０とを指定する。
【０１０６】
適合性判定部１７０は、リクエストの取得に応じて、指定されたセンダ６０のセンダ情報１２４及び指定されたレシーバ７０のレシーバ情報１２６をノード情報データベース１２１から取得する（ステップＳ１４２）。
【０１０７】
次いで、適合性判定部１７０は、センダ６０のエッセンスタイプ（即ち、送信エッセンスタイプ）がレシーバ７０のエッセンスタイプ（即ち、受信エッセンスタイプ）に適合するかを判定する（ステップＳ１４４）。
【０１０８】
送信エッセンスタイプが受信エッセンスタイプに適合すると判定される場合、適合性判定部１７０は、送信メディアタイプ（及び他の属性）が受信メディタイプ（及び他の属性）に適合するかをさらに判定する（ステップＳ１４５）。
【０１０９】
送信エッセンスタイプが受信エッセンスタイプに適合し、かつ送信メディアタイプ（及び他の属性）が受信メディタイプ（及び他の属性）に適合する場合、適合性判定部１７０は、リクエストされたストリームの伝送をセットアップすることを決定し得る（ステップＳ１４８）。一方、エッセンスタイプ及びメディアタイプ（並びに他の属性）のうちの少なくとも１つが適合しないと判定される場合、適合性判定部１７０は、リクエストを拒否することを決定し得る（ステップＳ１４９）。
【０１１０】
（３−３）第３の例
図１２Ｃは、図１１のステップＳ１４０において管理ノード１００により実行されるセンダ−レシーバ適合性判定処理の流れの第３の例を示すフローチャートである。第２の例と同様、ここでの第３の例では、エッセンスタイプ及びメディアタイプ（並びに、オプションとして他の属性）の適合性が判定され、ストリームタイプの適合性の判定は省略される。センダ６０及びレシーバ７０は、共にエッセンス分離型ストリームの送信又は受信をサポートするものとする。
【０１１１】
図１２ＣのステップＳ１４１からステップＳ１４５までの処理は、図１２Ｂに示した第２の例と同様である。
【０１１２】
第３の例において、送信エッセンスタイプが受信エッセンスタイプに適合し、かつ送信メディアタイプ（及び他の属性）が受信メディタイプ（及び他の属性）に適合する場合、適合性判定部１７０は、リクエストされたストリームの伝送をセットアップすることを決定し得る（ステップＳ１４８）。また、送信エッセンスタイプが受信エッセンスタイプに適合しない場合、適合性判定部１７０は、リクエストを拒否することを決定し得る（ステップＳ１４９）。
【０１１３】
メディアタイプ（又は他の属性）が適合しないと判定される場合、適合性判定部１７０は、属性の変更についてセンダ６０又はレシーバ７０と交渉する（ステップＳ１４６）。そして、適合性判定部１７０は、交渉が成立し、メディアタイプ（又は他の属性）の不適合が解消された場合には、リクエストされたストリームの伝送をセットアップすることを決定し得る（ステップＳ１４８）。一方、交渉が成立せず、メディアタイプ（又は他の属性）の不適合が解消されない場合には、適合性判定部１７０は、リクエストを拒否することを決定し得る（ステップＳ１４９）。
【０１１４】
（３−４）第４の例
図１２Ｄは、図１１のステップＳ１４０において管理ノード１００により実行されるセンダ−レシーバ適合性判定処理の流れの第４の例を示すフローチャートである。ここでの第４の例では、ストリームタイプ及びエッセンスタイプの適合性が判定される。
【０１１５】
図１２Ｄを参照すると、まず、センダ６０からレシーバ７０へのストリームの伝送を求めるリクエストが取得される（ステップＳ１４１）。当該リクエストは、典型的には、放送局システム１内のあるセンダ６０と少なくとも１つのレシーバ７０とを指定する。
【０１１６】
適合性判定部１７０は、リクエストの取得に応じて、指定されたセンダ６０のセンダ情報１２４及び指定されたレシーバ７０のレシーバ情報１２６をノード情報データベース１２１から取得する（ステップＳ１４２）。
【０１１７】
次いで、適合性判定部１７０は、センダ６０のストリームタイプ（即ち、送信ストリームタイプ）がレシーバ７０のストリームタイプ（即ち、受信ストリームタイプ）に適合するかを判定する（ステップＳ１４３ａ）。ここで、送信ストリームタイプが受信ストリームタイプに適合しない場合には、処理はステップＳ１４９へ進む。
【０１１８】
一方、送信ストリームタイプが受信ストリームタイプに適合する場合には、処理は、送信ストリームタイプ及び受信ストリームタイプが共に分離型であるかに依存して分岐する（ステップＳ１４３ｂ）。送信ストリームタイプ及び受信ストリームタイプが共に分離型である場合、処理はステップＳ１４４へ進む。送信ストリームタイプ及び受信ストリームタイプが共に分離型ではなく混在型である場合、ステップＳ１４４はスキップされ、処理はステップＳ１４８へ進む。
【０１１９】
送信ストリームタイプ及び受信ストリームタイプが共に分離型である場合、適合性判定部１７０は、センダ６０のエッセンスタイプ（即ち、送信エッセンスタイプ）がレシーバ７０のエッセンスタイプ（即ち、受信エッセンスタイプ）に適合するかを判定する（ステップＳ１４４）。送信エッセンスタイプが受信エッセンスタイプに適合すると判定される場合、処理はステップＳ１４８へ進む。一方、送信エッセンスタイプが受信エッセンスタイプに適合しないと判定される場合、処理はステップＳ１４９へ進む。
【０１２０】
ステップＳ１４８において、適合性判定部１７０は、リクエストされたストリームの伝送をセットアップすることを決定し得る。一方、ステップＳ１４９において、適合性判定部１７０は、リクエストを拒否することを決定し得る。
【０１２１】
（３−５）第５の例
図１２Ｅは、図１１のステップＳ１４０において管理ノード１００により実行されるセンダ−レシーバ適合性判定処理の流れの第５の例を示すフローチャートである。ここでの第５の例では、ストリームタイプ、エッセンスタイプ及びメディアタイプ（並びに、オプションとして他の属性）の適合性が判定される。
【０１２２】
図１２ＥのステップＳ１４１からステップＳ１４４までの処理は、図１２Ｄに示した第４の例と同様である。
【０１２３】
ステップＳ１４４において送信エッセンスタイプが受信エッセンスタイプに適合すると判定される場合、適合性判定部１７０は、送信メディアタイプ（及び他の属性）が受信メディタイプ（及び他の属性）に適合するかをさらに判定する（ステップＳ１４５）。
【０１２４】
ステップＳ１４５において送信メディアタイプ（及び他の属性）が受信メディタイプ（及び他の属性）に適合すると判定される場合、処理はステップＳ１４８へ進む。一方、メディアタイプを含む属性のうちの少なくとも１つが適合しないと判定される場合、処理はステップＳ１４９へ進む。
【０１２５】
ステップＳ１４８において、適合性判定部１７０は、リクエストされたストリームの伝送をセットアップすることを決定し得る。一方、ステップＳ１４９において、適合性判定部１７０は、リクエストを拒否することを決定し得る。
【０１２６】
なお、当然ながら、第５の例においても、第３の例と同様に属性の変更についてのセンダ６０又はレシーバ７０との交渉が行われてもよい。
【０１２７】
＜＜３．第２の実施形態＞＞
第２の実施形態においては、設定端末が、管理ノードと連携して放送局システムを制御するための制御装置としての役割を有する。
【０１２８】
＜３−１．システム構成例＞
図１３は、第２の実施形態に係る放送局システム２の構成の一例を示す概略図である。図１３を参照すると、放送局システム２は、１つ以上のネットワーク装置１２、カメラ１４、モニタ１６、ＩＰゲートウェイ２０ａ、ＩＰゲートウェイ２０ｂ、カメラ２２、マイクロフォン２４、データサーバ２６、統合プレイアウト３２、モニタ３４、ＡＰＳ４０、管理ノード３００及び設定端末４００を含む。ネットワーク装置１２、カメラ１４、モニタ１６、ＩＰゲートウェイ２０ａ、ＩＰゲートウェイ２０ｂ、ＡＰＳ４０、管理ノード３００及び設定端末４００は、ＩＰドメイン１０に属する。放送局システム２において、ＩＰドメイン１０の論理的な構成は、図２を用いて説明した第１の実施形態における構成例と同様であってよい。放送局システム２は、時刻同期の目的のために、さらに１つ以上の時刻サーバ（図示せず）を含んでもよい。
【０１２９】
管理ノード３００は、ＩＰドメイン１０に属するノードに関連する情報と、ノード間のストリームの伝送とを管理する情報処理装置である。とりわけ、本実施形態において、管理ノード３００は、センダ及びレシーバの設定を管理する。管理ノード３００のより具体的な構成の一例について後にさらに説明する。
【０１３０】
設定端末４００は、放送局システム２の運用に関連するユーザインタフェースをユーザへ提供する端末装置である。本実施形態において、設定端末４００は、ストリームのセットアップの際にセンダとレシーバとの間で特性が相互に適合するかを判定する機能をも提供する。設定端末４００は、放送局システム２に専用のユーザ端末であってもよく、又はＰＣ若しくはスマートフォンといった汎用的な端末であってもよい。設定端末４００のより具体的な構成の一例について後にさらに説明する。
【０１３１】
放送局システム２においても、放送局システム１と同様、放送素材を搬送するストリームの伝送はマルチキャストで行われる。あるストリームを受信することを意図する受信ノードは、そのストリームに対応するマルチキャストグループへの加入を通知するメッセージを近傍のルータへ送信する。受信ノードは、マルチキャストストリームの受信を終了する際には、マルチキャストグループからの離脱を通知するメッセージを近傍のルータへ送信する。
【０１３２】
＜３−２．管理ノードの構成例＞
図１４は、第２の実施形態に係る管理ノード３００の構成の一例を示すブロック図である。図１４を参照すると、管理ノード３００は、処理部３１０、記憶部１２０及び通信インタフェース１３０を備える。
【０１３３】
（１）処理部
処理部３１０は、例えば、ＣＰＵ、ＭＰＵ又はマイクロコントローラといった１つ以上のプロセッサを含む。処理部３１０は、記憶部１２０により記憶されるコンピュータプログラムを実行することにより、管理ノード３００の機能性を実現する。本実施形態において、処理部３１０は、例えば、後述する情報管理部３５０、リクエスト処理部３６０、及びストリーム制御部３８０として機能する。言い換えると、情報管理部３５０、リクエスト処理部３６０、及びストリーム制御部３８０は、処理部３１０により実現される機能モジュールである。
【０１３４】
（２）情報管理部
情報管理部３５０は、放送局システム２においてストリームを送信し又は受信するノードに関連する情報を、記憶部１２０のノード情報データベース１２１を用いて管理する。ノード情報データベース１２１は、図５を用いて説明したように構成され得る。情報管理部３５０は、例えば、ＩＰネットワークへのノードの接続を監視し、ノードの接続が検出されると、接続されたノードから当該ノードの情報を取得する。ノードの接続の検出及びノード情報の取得は、何らかの標準化されたノード発見手続を通じて行われてもよい。
【０１３５】
（３）リクエスト処理部
リクエスト処理部３６０は、センダ６０からレシーバ７０へのストリームの伝送をセットアップすることを求めるリクエストを処理する。リクエスト処理部３６０は、例えば、ユーザにより指定されたセンダ６０とレシーバ７０との間で特性が適合することを判定した設定端末２００から、ストリームの伝送をセットアップすることを求めるリクエストメッセージを通信インタフェース１３０を介して受信する。また、リクエスト処理部３６０は、リクエストされたストリームの伝送がストリーム制御部３８０によりセットアップされると、そのセットアップの結果を設定端末２００へ通知する。リクエスト処理部３６０は、ストリーム制御部３８０からの指示に応じて、設定端末２００以外の他の装置にもストリーム制御の結果を通知してもよい。
【０１３６】
（４）ストリーム制御部
ストリーム制御部３８０は、リクエスト処理部３６０から入力されるストリーム制御に関するリクエストに基づいてストリーム制御を実行する。ストリーム制御部３８０は、例えば、リクエストにおいて指定されたセンダ６０とレシーバ７０との間のストリームの伝送をセットアップする。より具体的には、ストリーム制御部３８０は、センダ６０からレシーバ７０へのストリームの伝送をセットアップする際、ノード情報データベース１２１を参照して、センダ６０のセンダ情報１２４に含まれる送信マルチキャストアドレス及び送信ポート番号を取得する。そして、ストリーム制御部３８０は、取得した情報により特定されるマルチキャストグループへの加入をレシーバ７０へ指示する。マルチキャストグループへの加入の指示は、何らかの標準化された制御手続を通じて行われてもよい。当該指示を受信したレシーバ７０は、指定されたマルチキャストグループへの加入を通知するメッセージを近傍のネットワーク装置１２へ送信する。すると、ネットワーク装置１２間でマルチキャストツリーを更新するためのメッセージ交換が行われ、指定されたマルチキャストグループのマルチキャストアドレスを宛先とするストリームがＩＰネットワークを介してレシーバ７０へ配信されるようになる。
【０１３７】
レシーバ７０は、マルチキャストグループへの加入に応じて、加入したマルチキャストグループの識別情報をタイムスタンプと共に管理ノード３００へ報告する。例えば、情報管理部３５０は、レシーバ７０からの報告に応じて、ノード情報データベース１２１のレシーバ情報１２６を更新し得る。ストリーム制御部３８０は、第１の実施形態に係る管理ノード１００のストリーム制御部１８０と同様に、レシーバ７０が加入したマルチキャストグループに関連する識別情報をレシーバ７０及び／又は伝送経路上のネットワーク装置１２へ問合せ、返送される識別情報を検証することにより、上記ストリームの伝送が成功裏にセットアップされたか否かを追加的に判定してもよい。
【０１３８】
＜３−３．設定端末の構成例＞
図１５は、第２の実施形態に係る設定端末４００の構成の一例を示すブロック図である。図１５を参照すると、設定端末４００は、処理部４１０、記憶部２２０、通信インタフェース２３０及びユーザインタフェース２４０を備える。
【０１３９】
（１）処理部
処理部４１０は、例えば、ＣＰＵ、ＭＰＵ又はマイクロコントローラといった１つ以上のプロセッサを含む。処理部４１０は、記憶部２２０により記憶されるコンピュータプログラムを実行することにより、設定端末４００の機能性を実現する。本実施形態において、処理部４１０は、例えば、後述するリクエスト受付部４５０、適合性判定部４７０、ストリーム制御部４８０及び情報表示部２９０として機能する。言い換えると、リクエスト受付部４５０、適合性判定部４７０、ストリーム制御部４８０及び情報表示部２９０は、処理部４１０により実現される機能モジュールである。
【０１４０】
（２）リクエスト受付部
リクエスト受付部４５０は、センダ６０からレシーバ７０へのストリームの伝送を求めるリクエストであって、ユーザインタフェース２４０がユーザから受け付ける当該リクエストを取得する。したがって、リクエスト受付部４５０は、「リクエスト取得部」として言及されてもよい。例えば、リクエスト受付部４５０は、ディスプレイの画面上に表示されるＧＵＩを介してリクエストを取得してもよい。その代わりに、リクエスト受付部４５０は、ＣＬＩなどの他の手段を介してリクエストを取得してもよい。リクエスト受付部４５０は、受け付けたリクエストを適合性判定部４７０へ出力して、指定されたセンダ６０及びレシーバ７０の間で特性が適合するかを適合性判定部４７０に判定させる。
【０１４１】
（３）適合性判定部
適合性判定部４７０は、リクエスト受付部４５０による上述したリクエストの受け付けに応じて、指定されたセンダ６０のセンダ情報１２４及び指定されたレシーバ７０のレシーバ情報１２６を通信インタフェース２３０を介して管理ノード３００へ問合せ、それら情報を管理ノード３００から取得する。代替的に、設定端末４００は、放送局システム２内のノード、センダ及びレシーバに関連する情報を予め管理ノード３００から取得し、記憶部２２０に記憶させていてもよい。その場合には、適合性判定部４７０は、記憶部２２０内のデータベースからセンダ情報１２４及びレシーバ情報１２６を取得し得る。そして、適合性判定部４７０は、それらセンダ６０及びレシーバ７０の間で特性が適合するかを判定する。
【０１４２】
適合性判定部４７０は、図６Ａ〜図６Ｃを用いて説明した第１の例のように、センダ６０及びレシーバ７０の間でストリームタイプ及びエッセンスタイプが適合するかを判定してもよい。例えば、センダ６０のストリームタイプがレシーバ７０のストリームタイプとは異なる場合、適合性は否定される。一方、それらストリームタイプが等しく、センダ６０及びレシーバ７０が共にエッセンス混在型ストリームの送信又は受信をサポートする場合、適合性は肯定される。センダ６０及びレシーバ７０が共にエッセンス分離型ストリームの送信又は受信をサポートする場合において、センダ６０の送信エッセンスタイプがレシーバ７０の受信エッセンスタイプとは異なる場合、適合性は否定される。一方、センダ６０の送信エッセンスタイプがレシーバ７０の受信エッセンスタイプに等しい場合、適合性は肯定される。
【０１４３】
適合性判定部４７０は、図７Ａ及び図７Ｂを用いて説明した第２の例のように、センダ６０及びレシーバ７０の間でストリームタイプ、エッセンスタイプ及びメディアタイプが適合するかを判定してもよい。例えば、送信メディアタイプが受信メディアタイプとは異なる場合、適合性は否定される。一方、センダ６０及びレシーバ７０の間でストリームタイプ及びエッセンスタイプが等しく、かつ送信メディアタイプが受信メディアタイプに等しい場合、適合性は肯定される。
【０１４４】
適合性判定部４７０は、図８Ａ〜図８Ｃを用いて説明した第３の例のように、センダ６０及びレシーバ７０の間で、ストリームタイプ、エッセンスタイプ及びメディアタイプに加えて、他の属性が適合するかを判定してもよい。他の属性とは、例えばＦＥＣ設定及びＲＴＣＰ設定のうちの一方又は双方を含む。例えば、センダ６０及びレシーバ７０の間でそれら属性のうちの一方又は双方が異なる場合、適合性は否定される。一方、センダ６０及びレシーバ７０の間でストリームタイプ、エッセンスタイプ及びメディアタイプが等しく、かつ他の属性もまた等しい場合、適合性は肯定される。
【０１４５】
なお、放送局システム２においてサポートされ得るストリームタイプが１タイプしか存在しない（例えば、エッセンス分離型ストリームのみがサポートされる）場合には、ストリームタイプの適合性の判定は省略されてもよい。
【０１４６】
適合性判定部４７０は、指定されたセンダ６０及びレシーバ７０の間でストリームの特性についてこのように適合性を判定した判定結果を、ストリーム制御部４８０へ出力する。
【０１４７】
（４）ストリーム制御部
ストリーム制御部４８０は、適合性判定部４７０から入力される適合性判定の結果に基づいてストリーム制御を実行する。より具体的には、ストリーム制御部４８０は、指定されたセンダ６０とレシーバ７０との間で特性が適合すると判定された場合には、リクエストされたストリームの伝送をセットアップする。ストリーム制御部４８０は、例えば、センダ６０に関連付けられるマルチキャストグループへの加入をレシーバ７０へ指示することを通信インタフェース２３０を介して管理ノード３００へ依頼することにより、センダ６０からレシーバ７０への上記ストリームの伝送をセットアップし得る。一方、ストリーム制御部４８０は、指定されたセンダ６０とレシーバ７０との間で特性が適合しないと判定された場合には、センダ６０からレシーバ７０へのストリームの伝送をセットアップすることを拒否し得る。
【０１４８】
ストリーム制御部４８０は、セットアップを拒否する場合に、特性の不適合に起因してセットアップが拒否されることを示すメッセージをユーザインタフェース２４０の画面上に表示させてもよい。表示される当該メッセージは、セットアップが拒否される原因（例えば、エッセンスタイプ、メディアタイプ又はその他の属性の不適合）を示してもよい。
【０１４９】
代替的に、ストリーム制御部４８０は、適合しないと判定された属性について、センダ６０又はレシーバ７０の一方が属性を変更できる可能性がある場合に、ストリームの属性の変更についてセンダ６０又はレシーバ７０の当該一方と交渉してもよい。交渉は、管理ノード３００を介して行われてもよい。また、ストリーム制御部４８０は、属性の変更についてユーザインタフェース２４０を介してユーザに承認を求め、変更をユーザが承認した場合にのみ変更（又は変更についての交渉）を行ってもよい。
【０１５０】
＜３−４．処理の流れ＞
次に、図１６を用いて、上述した放送局システム２において実行され得る処理の流れについて説明する。なお、管理ノード３００によるノード情報の収集の流れは、図１０を用いて説明した例と同様であってよい。
【０１５１】
図１６は、本実施形態におけるストリーム伝送のリクエストからストリームのセットアップまでの処理の流れの一例を示すシーケンス図である。図１６に示した処理には、ネットワーク装置１２、センダ６０、レシーバ７０、管理ノード３００及び設定端末４００が関与する。
【０１５２】
まず、設定端末４００（例えば、ユーザインタフェース２４０又はリクエスト受付部４５０）は、センダ６０からレシーバ７０へのストリームの伝送を求めるユーザリクエストを受け付ける（ステップＳ１３０）。次いで、設定端末４００（例えば、適合性判定部４７０）は、センダ−レシーバ適合性判定処理を実行して、指定されたセンダ６０及びレシーバ７０の間で特性が適合するかを判定する（ステップＳ１４０）。センダ−レシーバ適合性判定処理のより詳細な流れは、図１２Ａ〜図１２Ｅを用いて説明した例のいずれかと同様であってよい。ここでは、適合性判定処理の結果として、適合性が肯定されたものとする。
【０１５３】
設定端末４００（例えば、ストリーム制御部４８０）は、管理ノード３００へ制御メッセージを送信して、センダ６０に関連付けられるマルチキャストグループへの加入をレシーバ７０へ指示することを管理ノード３００に依頼する（ステップＳ１５０）。管理ノード３００（例えば、リクエスト処理部３６０）は、当該制御メッセージを通信インタフェース１３０を介して受信する。
【０１５４】
次いで、管理ノード３００（例えば、ストリーム制御部３８０）は、ノード情報データベース１２１から取得される識別情報（例えば、センダ６０の送信マルチキャストアドレス及び送信ポート番号）により識別されるマルチキャストグループへの加入をレシーバ７０へ指示する（ステップＳ１６１）。レシーバ７０は、マルチキャストグループへの加入を通知するメッセージを近傍のネットワーク装置１２へ送信することにより、指定された当該マルチキャストグループへ加入する（ステップＳ１６３）。また、レシーバ７０は、管理ノード３００から受信したマルチキャスト加入指示に対するレスポンスを送信する（ステップＳ１６５）。管理ノード３００（例えば、情報管理部３５０）は、レシーバ７０からのレスポンスの受信に応じて、ノード情報データベース１２１を更新する（ステップＳ１６７）。
【０１５５】
次いで、管理ノード３００（例えば、ストリーム制御部３８０）は、レシーバ７０が加入したマルチキャストグループに関連する識別情報をレシーバ７０へ問合せ、返送される識別情報を検証する（ステップＳ１６９）。次いで、管理ノード３００（例えば、リクエスト処理部３６０）は、リクエストされたストリームのセットアップが成功したことを設定端末４００へ通知する（ステップＳ１７１）。
【０１５６】
一方、ステップＳ１６３におけるレシーバ７０によるマルチキャストグループへの加入の結果として、センダ６０から送信されるストリームのネットワーク装置１２を介するレシーバ７０への伝送が開始される（ステップＳ１８０）。
【０１５７】
＜＜４．第３の実施形態＞＞
次いで、図１７を用いて、第３の実施形態について説明する。上述した第１の実施形態及び第２の実施形態は具体的な実施形態であり、一方で第３の実施形態はより一般化された実施形態である。
【０１５８】
図１７は、第３の実施形態に係る制御装置５００の構成の一例を示すブロック図である。制御装置５００は、放送局システムを制御するための装置である。図１７を参照すると、制御装置５００は、リクエスト取得部５６０、適合性判定部５７０及びストリーム制御部５８０を備える。
【０１５９】
リクエスト取得部５６０は、センダからレシーバへのストリームの伝送を求めるリクエストを取得する。適合性判定部５７０は、上記センダ及び上記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、上記センダの送信エッセンスタイプが上記レシーバの受信エッセンスタイプに適合するかを判定する。ストリーム制御部５８０は、上記センダの上記送信エッセンスタイプが上記レシーバの上記受信エッセンスタイプに適合すると判定される場合に、上記センダから上記レシーバへの上記ストリームの伝送をセットアップする。
【０１６０】
放送局システムを制御するための制御方法が、上述した制御装置５００のそれぞれの動作ステップを含んでもよい。それら動作ステップは、単一の装置において実行されてもよく、又は別個の装置においてそれぞれ実行されてもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムが提供されてもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムを記憶した非一時的なコンピュータ読取可能な記憶媒体が提供されてもよい。
【０１６１】
＜＜５．変形例＞＞
本開示に係る技術は、上述した実施形態には限定されない。例えば、本明細書では、制御装置（管理ノード及び／又は設定端末）とシステム内のノードとの間の制御通信のために、ＮＭＯＳ  ＩＳ−０４及びＮＭＯＳ  ＩＳ−０５で規定された制御インタフェースを用いる例を説明した。しかしながら、本開示に係る技術は、ＮＭＯＳ以外の標準化された制御インタフェース、又は非標準の制御インタフェースを用いるケースにも適用可能である。また、放送局システムのＩＰドメイン内に、標準化された制御インタフェースをサポートする第１グループのノードと、非標準の制御インタフェースのみをサポートする第２グループのノードとが存在してもよく、制御装置は、そうした複数の種類の制御インタフェースをサポートしてもよい。その場合に、上述したセンダとレシーバとの間の適合性の判定は、第１グループのノード（標準対応ノード）間のストリームの伝送のセットアップの際にのみ行われてもよい。追加的に又は代替的に、上述したセンダとレシーバとの間の適合性の判定は、第２グループのノード（標準非対応ノード）間のストリームの伝送のセットアップの際に行われてもよく、又はグループに関わらず行われてもよい。
【０１６２】
＜＜６．まとめ＞＞
ここまで、図１〜図１７を用いて本開示のいくつかの実施形態について詳細に説明した。上述した実施形態では、放送局システムにおけるセンダからレシーバへのストリームの伝送を求めるリクエストの取得に応じて、（エッセンス分離型ストリームの送信をサポートする）上記センダの送信エッセンスタイプが（エッセンス分離型ストリームの受信をサポートする）上記レシーバの受信エッセンスタイプに適合すると判定される場合に、上記センダから上記レシーバへの上記ストリームの伝送がセットアップされる。かかる構成によれば、放送局内のＩＰネットワークに多様な装置が接続される状況において、送信側及び受信側で利用され又は想定されるストリームの特性が相互に適合することを保証することができる。例えば、映像（音声）エッセンスのみを期待するレシーバが接続されているネットワークセグメントには、ストリームタイプが同一であっても音声（映像）エッセンスのストリームは配信されない。それにより、ネットワークリソースの無駄が回避され、受信側での予期しない動作不良もまた防止され得る。
【０１６３】
ある実施形態では、上記センダの上記送信エッセンスタイプが上記レシーバの上記受信エッセンスタイプに適合する場合に、上記センダの送信メディアタイプが上記レシーバの受信メディアタイプに適合するかがさらに判定され、それらメディアタイプが適合すると判定される場合に上記センダから上記レシーバへの上記ストリームの伝送がセットアップされ得る。かかる構成によれば、エッセンスタイプが同一であってもエッセンスデータの解釈が成功しない結果としてストリーム伝送用のネットワークリソースが無駄になる可能性を回避することができる。
【０１６４】
ある実施形態では、上記センダのＦＥＣ設定が上記レシーバのＦＥＣ設定に適合するかがさらに判定され、それら設定が適合すると判定される場合に上記センダから上記レシーバへの上記ストリームの伝送がセットアップされ得る。追加的に又は代替的に、上記センダのＲＴＣＰ設定が上記レシーバのＲＴＣＰ設定に適合するかがさらに判定され、それら設定が適合すると判定される場合に上記センダから上記レシーバへの上記ストリームの伝送がセットアップされ得る。かかる構成によれば、センダ及びレシーバ間の設定の不適合に起因してストリーム伝送用のネットワークリソースが無駄になる可能性を回避することができる。
【０１６５】
ある実施形態では、上記センダと上記レシーバとの間で、エッセンスタイプ、メディアタイプ、ＦＥＣ設定及びＲＴＣＰ設定のうちの少なくとも１つが適合しないと判定される場合に、上記センダから上記レシーバへの上記ストリームの伝送をセットアップすることが拒否され得る。かかる構成によれば、不適切なリクエストに応じてストリームの伝送のセットアップは開始されないため、システム内のストリーム制御のオーバヘッドを低減することができる。
【０１６６】
ある実施形態では、上記センダによりサポートされるストリームタイプが上記レシーバによりサポートされるストリームタイプに適合するかの判定も行われ得る。上記ストリームタイプの候補は、エッセンス混在型ストリーム及びエッセンス分離型ストリームを含み得る。かかる構成によれば、エッセンス混在型ストリーム及びエッセンス分離型ストリームの双方が伝送される可能性のあるＩＰネットワークにおいて、適切なストリームの伝送を保証することができる。
【０１６７】
ある例において、上記センダから上記レシーバへのストリームの伝送を求めるリクエストメッセージを受信する通信インタフェースを有するノードにおいて、上記適合性の判定が行われ得る。この場合、１つのノード（例えば、システム内の多様な装置の設定を管理する管理ノード）において、他のノードからのリクエストに応じて一元的に判定処理を実行することができる。他の例において、上記センダから上記レシーバへのストリームの伝送を求める上記リクエストはユーザインタフェースを介して受け付けられ、そのユーザインタフェースを有する端末において上記適合性の判定が行われ得る。この場合、不適切なストリームの伝送を求めるリクエストを当該端末において拒否することで、そのリクエストに起因してＩＰネットワーク内にシグナリングオーバヘッドが発生することを回避することができる。
【０１６８】
なお、本開示に係る技術は、上述した実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、並びに、本開示のスコープ及び精神から逸脱することなく様々な変形が可能であるということが、当業者に理解されるであろう。
【０１６９】
例えば、フローチャートに示した処理ステップは、必ずしも図示した順序通りに実行されなくてもよい。例えば、処理ステップは図示した順序とは異なる順序で実行されてもよく、２つ以上の処理ステップが並列的に実行されてもよい。また、一部の処理ステップが削除されてもよく、さらなる処理ステップが追加されてもよい。
【０１７０】
また、本明細書において説明した装置の機能は、ソフトウェア、ハードウェア、及びソフトウェアとハードウェアとの組み合わせのいずれで実現されてもよい。ソフトウェアを構成するコンピュータプログラムのプログラム命令は、例えば、各装置の内部又は外部のコンピュータ読取可能な記憶媒体において記憶され、実行時にメモリへ読み込まれてプロセッサにより実行される。
【０１７１】
上記実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【０１７２】
（付記１）
放送局システムを制御するための制御装置であって、
センダからレシーバへのストリームの伝送を求めるリクエストを取得する取得部と、
前記センダ及び前記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、前記センダの送信エッセンスタイプが前記レシーバの受信エッセンスタイプに適合するかを判定する判定部と、
前記センダの前記送信エッセンスタイプが前記レシーバの前記受信エッセンスタイプに適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする制御部と、
を備える制御装置。
【０１７３】
（付記２）
前記判定部は、前記センダの前記送信エッセンスタイプが前記レシーバの前記受信エッセンスタイプに適合する場合に、前記センダの送信メディアタイプが前記レシーバの受信メディアタイプに適合するかをさらに判定し、
前記制御部は、前記センダの前記送信メディアタイプが前記レシーバの前記受信メディアタイプに適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする、
付記１に記載の制御装置。
【０１７４】
（付記３）
前記判定部は、前記センダの前方誤り訂正（ＦＥＣ）設定が前記レシーバのＦＥＣ設定に適合するかをさらに判定し、
前記制御部は、前記センダの前記ＦＥＣ設定が前記レシーバの前記ＦＥＣ設定に適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする、
付記１又は付記２に記載の制御装置。
【０１７５】
（付記４）
前記判定部は、前記センダのＲＴＣＰ（RTP  Control  Protocol）設定が前記レシーバのＲＴＣＰ設定に適合するかをさらに判定し、
前記制御部は、前記センダの前記ＲＴＣＰ設定が前記レシーバの前記ＲＴＣＰ設定に適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする、
付記１〜３のいずれか１項に記載の制御装置。
【０１７６】
（付記５）
前記制御部は、前記センダと前記レシーバとの間で、エッセンスタイプ、メディアタイプ、ＦＥＣ設定及びＲＴＣＰ設定のうちの少なくとも１つが適合しないと判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップすることを拒否する、付記１〜４のいずれか１項に記載の制御装置。
【０１７７】
（付記６）
前記制御部は、前記センダの前記送信メディアタイプが前記レシーバの前記受信メディアタイプに適合しないと判定される場合に、前記送信メディアタイプと前記受信メディアタイプとの不適合が解消されるように前記センダ又は前記レシーバと交渉する、付記２に記載の制御装置。
【０１７８】
（付記７）
前記判定部は、前記センダによりサポートされるストリームタイプが前記レシーバによりサポートされるストリームタイプに適合するかをさらに判定し、
前記ストリームタイプの候補は、エッセンス混在型ストリーム及び前記エッセンス分離型ストリームを含む、
付記１〜６のいずれか１項に記載の制御装置。
【０１７９】
（付記８）
前記制御装置は、前記センダから前記レシーバへの前記ストリームの伝送を求めるリクエストメッセージを受信する通信部、をさらに備える、付記１〜７のいずれか１項に記載の制御装置。
【０１８０】
（付記９）
前記制御部は、前記センダに関連付けられるマルチキャストグループへの加入を前記レシーバへ指示することにより、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする、付記８に記載の制御装置。
【０１８１】
（付記１０）
前記制御部は、前記レシーバが加入したマルチキャストグループに関連する識別情報を検証することにより、前記センダから前記レシーバへの前記ストリームの伝送が成功裏にセットアップされたか否かを判定する、付記９に記載の制御装置。
【０１８２】
（付記１１）
前記制御装置は、前記センダから前記レシーバへの前記ストリームの伝送を求める前記リクエストを受け付けるユーザインタフェース、をさらに備える、付記１〜７のいずれか１項に記載の制御装置。
【０１８３】
（付記１２）
前記制御装置は、前記センダ及び前記レシーバの設定を管理する管理ノードと通信する通信部、をさらに備え、
前記制御部は、前記センダに関連付けられるマルチキャストグループへの加入を前記レシーバへ指示することを前記通信部を介して前記管理ノードへ依頼することにより、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする、
付記１１に記載の制御装置。
【０１８４】
（付記１３）
前記エッセンス分離型ストリームは、ＳＭＰＴＥ（Society  of  Motion  Picture  and  Television  Engineers）  ＳＴ２１１０に準拠するストリームである、付記１〜１２のいずれか１項に記載の制御装置。
【０１８５】
（付記１４）
前記エッセンス混在型ストリームは、ＳＭＰＴＥ  ＳＴ２０２２−６に準拠するストリームである、付記７に記載の制御装置。
【０１８６】
（付記１５）
前記エッセンス混在型ストリームは、ＡＲＩＢ（Association  of  Radio  Industries  and  Businesses）  ＳＴＤ−Ｂ７３に準拠するストリームである、付記７に記載の制御装置。
【０１８７】
（付記１６）
放送局システムにおいて実行される制御方法であって、
センダからレシーバへのストリームの伝送を求めるリクエストを取得することと、
前記センダ及び前記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、前記センダの送信エッセンスタイプが前記レシーバの受信エッセンスタイプに適合するかを判定することと、
前記センダの前記送信エッセンスタイプが前記レシーバの前記受信エッセンスタイプに適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップすることと、
を含む制御方法。
【０１８８】
（付記１７）
放送局システムであって、
センダを備える送信ノードと、
レシーバを備える受信ノードと、
制御装置と、
を含み、
前記制御装置は、
前記センダから前記レシーバへのストリームの伝送を求めるリクエストを取得する取得部と、
前記センダ及び前記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、前記センダの送信エッセンスタイプが前記レシーバの受信エッセンスタイプに適合するかを判定する判定部と、
前記センダの前記送信エッセンスタイプが前記レシーバの前記受信エッセンスタイプに適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップする制御部と
を備える、放送局システム。
【０１８９】
（付記１８）
放送局システムを制御するための制御装置のプロセッサに、
センダからレシーバへのストリームの伝送を求めるリクエストを取得することと、
前記センダ及び前記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、前記センダの送信エッセンスタイプが前記レシーバの受信エッセンスタイプに適合するかを判定することと、
前記センダの前記送信エッセンスタイプが前記レシーバの前記受信エッセンスタイプに適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップすることと、
を実行させるコンピュータプログラム。
【０１９０】
（付記１９）
放送局システムを制御するための制御装置のプロセッサに、
センダからレシーバへのストリームの伝送を求めるリクエストを取得することと、
前記センダ及び前記レシーバがエッセンス分離型ストリームの送信又は受信をサポートする場合に、前記センダの送信エッセンスタイプが前記レシーバの受信エッセンスタイプに適合するかを判定することと、
前記センダの前記送信エッセンスタイプが前記レシーバの前記受信エッセンスタイプに適合すると判定される場合に、前記センダから前記レシーバへの前記ストリームの伝送をセットアップすることと、
を実行させるコンピュータプログラム、を記憶した非一時的なコンピュータ読取可能な記憶媒体。
【産業上の利用可能性】
【０１９１】
本開示に係る技術は、限定ではないものの、ＩＰネットワークを含む放送局システムにおいて利用可能である。
【符号の説明】
【０１９２】
１，２              放送局システム
１０                ＩＰドメイン
１２                ネットワーク装置
１４，２２          カメラ
１６，３４          モニタ
２０ａ，２０ｂ      ＩＰゲートウェイ
２４                マイクロフォン
２６                データサーバ
３２                統合プレイアウト
６０（６０ａ〜ｄ）  センダ
６２                デバイス
７０（７０ａ〜ｄ）  レシーバ
１００，３００      管理ノード（制御装置）
１１０，３１０      処理部
１２０              記憶部
１２１              ノード情報データベース
１２２              ノード情報
１２４              センダ情報
１２６              レシーバ情報
１３０              通信インタフェース
１５０，３５０      情報管理部
１６０，３６０      リクエスト処理部
１７０              適合性判定部
１８０，３８０      ストリーム制御部
２００，４００      設定端末（制御装置）
２１０，４１０      処理部
２２０              記憶部
２３０              通信インタフェース
２４０              ユーザインタフェース
２５０，４５０      リクエスト受付部
４７０              適合性判定部
４８０              ストリーム制御部
２９０              情報表示部
５００              制御装置
５６０              リクエスト取得部
５７０              適合性判定部
５８０              ストリーム制御部
【図１】
2020102695.tif 000003
【図２】
2020102695.tif 000004
【図３】
2020102695.tif 000005
【図４】
2020102695.tif 000006
【図５】
2020102695.tif 000007
【図６Ａ】
2020102695.tif 000008
【図６Ｂ】
2020102695.tif 000009
【図６Ｃ】
2020102695.tif 000010
【図７Ａ】
2020102695.tif 000011
【図７Ｂ】
2020102695.tif 000012
【図８Ａ】
2020102695.tif 000013
【図８Ｂ】
2020102695.tif 000014
【図８Ｃ】
2020102695.tif 000015
【図９】
2020102695.tif 000016
【図１０】
2020102695.tif 000017
【図１１】
2020102695.tif 000018
【図１２Ａ】
2020102695.tif 000019
【図１２Ｂ】
2020102695.tif 000020
【図１２Ｃ】
2020102695.tif 000021
【図１２Ｄ】
2020102695.tif 000022
【図１２Ｅ】
2020102695.tif 000023
【図１３】
2020102695.tif 000024
【図１４】
2020102695.tif 000025
【図１５】
2020102695.tif 000026
【図１６】
2020102695.tif 000027
【図１７】
2020102695.tif 000028