こんにちは、樋口です。

Media over IP検証はじめました、25Gのリンクが上がらない！FECについて調べてみたから続いて3本目のMoIPの検証関連の記事となります。
検証チームのメンバーが揃って丸一日行う検証は、月に1,2度ほどのペースで行っています。様々な学びやつまづきがありますが、NMOSの検証も行っているので今回はそれをまとめます。

NMOSとは

NMOS(Networked Media Open Specifications)は、カメラやスイッチャー、IPゲートウェイなどの異なるメーカーの機器を連携して動作させるためのオープンな仕様です。情報工学や電子工学を専攻していた人は真っ先に、n型MOSFETが思い浮かぶと思います。私もそうでした。

NMOSは、IPネットワーク上でSMPTE ST 2110規格が動作するために必要なネットワークプロトコルを開発するAMWA(Advanced Media Workflow Association)によって開発されました 。AMWAは、放送業界のIPへの移行に焦点を当てた業界団体であり 、NMOSの開発はその中心的な活動の一つです。

With worldwide representation from both media companies and their suppliers, the AMWA currently focuses on the industry move to IP based architectures. To enable software based systems to recognize and exploit devices, the AMWA has developed the Networked Media Open Specifications (NMOS). These have been created in practical workshops by the Networked Media Incubator project.

(参考: ABOUT THE AMWA | AMWA)

NMOSの目的の一つは、特定のメーカーに縛られることなく、システム構築に必要な最適な機器を自由に選択できる環境を提供することです。このようにしてベンダーロックインを回避することができれば、放送局は自社の放送システムにおいて多様なメーカーの機器を導入することができ、優れた機能の製品やコストパフォーマンスに優れた製品を、自由に選択できるようになります。

NMOSの構成要素と仕様

NMOSはInterface Specifications(IS), Best Common Practices(BCP), Data Model Specifications(MS), Informative Documents(INFO)などで構成されています。
特にインターフェース仕様であるISは、上述した機器の制御を行う上で非常に重要となる要素です。
(参考: NMOS Interface Specifications (IS) | specs.amwa.tv)

IS-04 Discovery & Registration

IS-04は、ネットワーク上のリソース（ノード、デバイス、送信機、受信機など）を検出および登録するためのAPIを提供します。これによって、ネットワークシステムの展開の自動化が可能になり、手動での設定の手間から解消されます。

IS-04では以下の3つのAPIが定義されています。

• Registration API: ノードが自身のリソースをレジストリに登録するために使用される
• Query API: 登録されたリソースを制御システムや監視アプリケーションが照会するために使用される
• Node API: 映像ソースなどのソースである各ノードによって公開され、レジストリに入力するために使用される

IS-05 Device Connection Management

IS-05は機器の接続の制御に関する仕様です。IS-05は、送信側と受信側に関する情報を提供するIS-04に基づいており 、制御アプリケーションがメディアノードに指示を送信することで機能します。
NMOSのコントローラはIS-04のレジストリから各ノードに関する情報を取得します。送信機器からSDP(Session Description Protocol)を取得し、それをもとに受信側の機器をコントロールすることができます。

これらの理解にはこちらのドキュメント(AMWA IS-04 NMOS Discovery and Registration Specification: Overview | specs.amwa.tv)が大変役立ちました。一方で、これらは実際に構築して触ってみるまではよくわからなかったのも事実です。今回の記事で後述する方法で実際の各APIの挙動を確認することが可能です。ISには他にも以下のような仕様があります。IS-10くらいまでは社外の方との会話の中でもときどき耳にすることがある、という印象です。実際には機器が対応する必要はありますが、このようなオープンな仕様について勉強することはできますので調べておくと良いかもしれません。

Id	Name	概要
IS-04	Discovery & Registration
IS-05	Device Connection Management
IS-06	Network Control	管理されたネットワークにおけるトポロジー制御や帯域制御など
IS-07	Event & Tally	各機器ににイベント・タリー情報を提供
IS-08	Audio Channel Mapping	各機器の音声チャンネルマッピングを変更
IS-09	System Parameters	グローバルな構成パラメータを取得
IS-10	Authorization	APIサーバーが認証に応じて要求を受け入れるか拒否するかを決定
IS-11	Stream Compatibility Management	送信機、フロー、送信機の構成
IS-12	Control Protocol	デバイスのセットアップと制御
IS-13(策定中)	Annotation	制御アプリケーションによるのラベル、説明、タグの付与
IS-14(策定中)	Device Configuration	NMOSデバイスの設定

検証環境におけるNMOSサーバの構築

さて、本題ですが、今回はMBSにある検証機器のNMOSでの制御を試してみました。
実際にはNMOS registryやコントローラなどは、メーカーのブロードキャストコントローラなどに実装されているものを使うことになると思います。一方で今回はあくまで勉強と挙動の検証が目的ですので、Githubで公開されているeasy-nmosを活用してみました。

このeasy-nmosはAMWAのウェブサイトからも紹介されているツールになります。

AMWA members have invested thousands of hours in developing the open specifications that are in use today. But we also encourage non-members to benefit from this development time by including the code, free of charge, in their product range.

(参考: Join the family of NMOS users and suppliers | specs.amwa.tv)

とあるように、無料でこのAMWAの恩恵にあずかることができるようです。

Dockerが動く環境を用意する必要があるので、今回の検証ではAlmaLinuxのサーバを用意しました。具体的にはLinux KVMの1つの仮想マシンとして作成しています。今回のこの仮想マシンは、検証環境の各機器の制御系セグメントと同セグメントに配置しました。

IPの放送機器にはインバウンド制御とアウトバウンド制御の機器があります。インバウンド制御の機器は映像データと制御データが流れるインターフェースが同じです。一方でアウトバウンド制御の機器は別で用意されているものとなります。アウトバウンド制御の機器は、制御系のネットワークを別で準備できるため、管理しやすいというメリットがある一方で、接続するケーブルの数は多くなってしまいます。

今回の検証では下図のように、制御対象の機器はすべてアウトバウンド制御のものを利用し、NMOSの環境はその制御系ネットワーク(Management Switchに接続されている側)と同じネットワーク上に構築しました。インバウンド制御の機器も含む環境になると、2022-7で冗長化されている機器も多く、また少し複雑な構成が必要になります。

easy-nmos

easy-nmosはdocker-compose.ymlを見るとわかるように、3つのコンテナで構成されています。

• nmos-registry: NMOSレジストリとNMOSコントローラのインスタンス
• nmos-virtnode: テスト用の仮想ノードを作るインスタンス
• nmos-testing: AMWAのNMOSテストツール

まずNMOSの挙動を確認したいだけなら、最初のnmos-registryだけで良いでしょう。今回はあえてそれだけを立ち上げてみました。
docker-compose.ymlのネットワーク設計だけは、検証環境に合うように変更してやります。具体的には

• 各サービスのnetworks: → external: → ipv4_address:の値
• networksのdriver_optsの値
• networksのipamのsubnetの値
• (nmos-registryサービスのみ立ち上げる場合)各サービスのdepends_onの値

くらいでしょうか。編集が完了すると以下のコマンドで起動します。

$ docker compose up -d

そうすると、制御系NWに指定したIPアドレスのコンテナが立ち上がります。もし、各機器で静的にNMOSレジストリを指定する必要のあるものがあれば、このIPアドレスを指定します。一方で各メーカーはmDNSを使ってNMOSレジストリを探すものが多いです。今回の検証で制御系ネットワークをL2で構築しているのもこのためで、もしmDNSをL3を越えて使おうとするとネットワーク側の設定が必要になります。この点については引き続き我々も検証をしていくポイントになります。

以下は準備されているNMOSコントローラの画面です。GithubのREADMEにもあるようにhttp://nmos-registry.local/adminでアクセス可能です。(画像は別の検証時の写真のため、本記事の構成図にはない、IPゲートウェイも映っております。)

Riedel NMOS Explorer

検証では他にもRiedel社のNMOS Explorerも試してみました。展示会等でも複数の企業がデモ用に使っているのを見たことがあります。これはノートPCでも良いのでインストールしてしまえば、すぐに使える便利なツールです。

コントローラはNMOSレジストリは上述のeasy-nmosのものを、コントローラはRiedelのNMOS Explorerでという構成も試してみました。下図のようにModeをStaticにし、Query APIにNMOSレジストリのコンテナのIPアドレスを指定すると、すぐに登録済みのノードが見えるようになりました。

このNMOS ExplorerはSerndersからRecieversにドラッグ&ドロップで直感的に切り替えを行うことができます。また、映像ソースは映像のRecieversに、音声ソースは音声のRecieversに移せるよう、対象ではないソースを動かそうとするとエラー表示がされるなどの工夫がされており、個人的にはこちらのコントローラの方が使いやすいという印象でした。

まとめ

NMOSレジストリを仮想サーバに作り、コントローラから制御するという一連の動きの確認を行いました。今回は制御対象の機器は多くはありませんでしたが、集積度の高いゲートウェイなど、手動での設定項目が多くなると、多くの機器をまとめて直感的に操作ができるNMOSの必要性を感じるようになってきます。引き続きこのような制御系も様々な検証を行っていきます！