マルチキャストの現状(ユーザ環境)ドラフト版

マルチキャストのユーザ環境(プレイヤー、ブラウザ、宅内ネットワーク、プロトコル)について、現状をまとめます。

ブラウザ

基本的に、ブラウザ単体ではマルチキャストパケットを受信できないため、プラグインによるマルチキャストパケットの処理が必要となります。そして、現状では、PPAPI経由でNaCL等を実行することにより、マルチキャストの送受信が可能です(検証済み)。しかし、PPAPI、NaCLともに2021年には廃止になり、それ以降はWebAssemblyによるネイティブコードの実行に移行します。

しかし、WebAssemblyはWebSocket(TCP)での通信しかサポートしていないようです(未検証)。そのためUDPが使えず、結果としてマルチキャストは不可となります。また、ブラウザによるUDP・TCPの生ソケット通信(TCP and UDP Socket API)については、ドラフト案は出ましたが2016年にリタイヤ(提案の撤回)になっています。

最後の望みはWebRTCです。これはメディア転送用にRTP over UDPが使用可能なのですが、素のRTPではなくSRTP(Secure RTP、暗号化されたRTP)のみをサポートしているようで、マルチキャストのような1：多の受信が可能なのかは不明です（SRTPもマルチキャストをサポートしていますがWebRTCで実装されているかは不明です。未検証）。

またTVにおける動画視聴サービスは、TVの内臓ブラウザを使用しているものが多いのですが、これらのマルチキャスト対応についてははっきりしていません。W3CやCTA WAVE projectにおいてもマルチキャストに関する明確な記述は無く、HTTPベース(つまりはユニキャストTCP)の動画配信を継続して使用するというようにしか読み取れません。

• NPAPI (Netsape Plugin API)
  • 外部プログラムの呼び出しAPI
  • Netscape 2.0 (1995年)からサポート
  • 大抵のメディア系プラグイン(Flash、Silverlight、RealPlayer、QuickTime等)が使用していた
    • 大抵のプラグインはマルチキャストの利用も可能
  • 廃止
    • Chrome 45 (2015年9月)
    • Firefox 52 (2017年3月)
• ActiveX
  • Internet Explore用の外部プログラム呼び出しAPI
  • 現状
    • Internet ExploreはIE 11(2013年)を最後に開発がストップしている
    • 後継であるMicrosoft EdgeはActiveXをサポートしない
• PPAPI (Pepper Plugin API)
  • 外部プログラムの呼び出し(新版)API
  • Windows Chrome 21(2012年)からサポート
  • 対応するメディア系プラグインはAdobe Flash Playerのみ
    • Flashプラグインは、マルチキャスト受信をサポートしているかもしれない（未検証）
  • 廃止予定
    • Chrome 2021年6月
• NaCL (Google Native CLient)
  • 外部プログラムの仕様
    • https://developer.chrome.com/native-client
  • 通信：一般的なSocket通信
    • マルチキャストのサンプル(2019年12月に動作確認済)
      • https://github.com/intel/nacl-multicast-streaming
  • 廃止予定
    • Chrome 2021年6月
• WebAssembly
  • 外部プログラムの仕様
    • https://developer.mozilla.org/ja/docs/WebAssembly/Concepts
  • asm.jsとPNaCLがベース
  • 主要ブラウザによるサポート：2017年
  • 通信：WebSocket通信(TCP)のみ？
• WebSocket
  • HTTPからのプロトコルアップグレードで様々な通信プロトコル(ただしTCPのみ)を実行する機能
    • https://developer.mozilla.org/ja/docs/Web/API/WebSockets_API
• W3C TCP and UDP Socket API
  • 2013-05-14: First Public Draft
  • 2015-07-23: Retired
  • https://www.w3.org/standards/history/tcp-udp-sockets
• WebRTC
  • https://developer.mozilla.org/ja/docs/Web/API/WebRTC_API
• SRTP
  • https://tools.ietf.org/html/rfc3711
• Samsung Smart TV NaCL (Tizen OS)
  • https://developer.samsung.com/smarttv/develop/extension-libraries/nacl/getting-started.html
• Multicast QUIC for video content delivery
  • https://www.slideshare.net/JISC/multicast-quic-for-video-content-delivery
  • 研究レベルの提案、BBC研究所
• CTA WAVE (Web Application Video Ecosystem) Project
  • https://cta.tech/Resources/Standards/WAVE-Project

アプリケーション

大きな問題なくマルチキャストを受信できるプレイヤーの開発が可能です。オープンソースのものとしては、以下のようなものがあります。

• VLC Player
• mplay (ffmpeg付属プレイヤー)

OSおよびハードウェア

大抵のOSとハードウェアでは問題ないのですが、Androidについては一部の機種でパケットドロップ率が高く、絵が崩れます。

• Windows＋一般PC：問題なし
• Android系：実装によってはマルチキャストパケットのドロップ率が高い
  • Motorola系がダメ：調査機種 Moto G4 Plus, Moto G6 Plus (他の機種で良好に受信できるWi-Fiマルチキャストを受信しても10%程度パケットロスする）
  • Galaxy、Xperia、Huaweiは、それぞれ数機種をためしたが問題なし
  • WifiManager.MulticastLock
    • https://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock
    • マルチキャストアドレス宛てパケットの受信可否（バッテリ消費の視点でマルチキャスト当て通信をフィルタアウトする機能）
    • デフォルトON？
• iOS系：問題なし

家庭内スイッチ

安い家庭用ネットワークスイッチでは、マルチキャストをブロードキャストとして処理し、接続している全ポートに対してパケットを流すようです（要リスト化）。これにより、スイッチに接続している全機器に対し強制的にマルチキャストパケットが流れ込むようになります(パケット強制送信問題)。今どきのPCであれば、4K動画(20Mbps程度)であってもそれほど問題とはならない(消費電力が若干増えるだけ)と思われますが、有線でつながっているIoT機器等が存在する場合は、フルHD動画(5Mbps)程度であってもそれらに対する通信に問題が出る可能性があります。ただし最近のものでは、安い(数千円ぐらい)家庭用スイッチでも、IGMP Snooping (Wi-Fiマルチキャストの選択的送信)機能を持っものも出てきています。

家庭内Wi-Fi

まず、Wi-Fiの問題点として、「無線区間においてパケットが正常にクライアントに届かない（パケットロス）」があります。しかし、ユニキャスト通信であればパケットロスが発生しても、Wi-Fiのレイヤー2が自動的にパケットを再送してくれるため、アプリケーションには影響が出にくくなっています。

一方、マルチキャストはWi-Fiにおいてブロードキャストと同様に処理され、パケットの再送処理はレイヤー2で行いません。そのため、マルチキャスト通信は無線区間の影響を強く受け、パケットロスが出やすくなります。

そのため、マルチキャスト通信であっても、それをユニキャストとして配信する機能(Cisco MC2UC (MultiCast to UniCast)、Aruba DMO (Dynamic Multicast Optimization)、IOデータ・バッファロー　マルチキャスト変換)が開発されています。これにより受信するクライアントの台数分だけパケットが複製され、伝送帯域を消費しますが、Layer２の再送信によりクライアントは安定してパケットを受信できるようになります。この機能は、Aruba等の商用Wi-Fi APなら、ほぼすべてのプロダクトで実装されており、家庭内用のものでも、上位のものでは実装されています。

そして(家庭内スイッチにもあった)マルチキャストのブロードキャスト変換によるパケット強制送信問題は、Wi-Fiではもっとシビアな問題なります。そのため、マルチキャスト変換を持つぐらいの機器は、IGMP Snooping (Wi-Fiマルチキャストの選択的送信)機能を持っています。

配信プロトコル

公衆Wi-Fiホットスポット等まで範囲を広げると、マルチキャストのユニキャスト変換だけではなく、きちんとマルチキャストを行う環境が欲しくなります。しかし、前述のようにWi-Fi環境のパケットロスは避けることはできず、何らかのリカバリー手段が必要になります。

IPTVなどの固定系マルチキャストでは、FECを使ったエラーリカバリが主流です。しかし、それらのFECは主にロス率の低い伝送路用であり、無線網のようなロス率の高い環境では使い物になりません。例えばIPTV等でよく使われるPro-MPEGと呼ばれるFECは、基本的にランダムなパケットロスに対しては強いが連続パケットロスには弱いという特性を持ちます(連続パケットロスに対応させるためにブロックサイズを大きくすると冗長化率が低くなり高パケットロスに耐えない。逆に、高パケットロスに対応させるために冗長率を上げるとブロックサイズが小さくなり連続パケットロスに耐えない）。そのため、AL-FECという新しい(Pro-MPEGよりは複雑な計算を行う）FECが注目されています。そして、AL-FECをサポートしているシステムは、旧来のMPEG-TS等でなく、MMTというプロトコルが前提となっていることが多いです(正確には、MMTプロトコルではAL-FECが規定されており、MMTをフルセットで実装するとAL-FECも実装することになる)。

また、マルチキャストに対するARQ(自動再送要求、パケットロスに対する再送)を実装したシステムも存在します(SK Telecomと韓国Hecas社の共同開発)。このシステムは、SK Telecomの商用サイマル配信(Oksusu)で使用されており、UDP MMT配信+独自ARQという構成となっています(システム自体はマルチキャスト＋ARQという構成が可能ですが、実網でマルチキャストが使用されているかどうかは未確認です)。また、SK Telecomは、このような技術を持つからこそ、北米でのビジネス(SinclairとATSC3.0についてのジョイントベンチャーを設立)に熱心なのだと思われます。

一方、国内においてはFLUTE(File Delivery over Unidirectional Transport, RFC 6726)ベースのWi-Fiマルチキャスト配信が幾つかのスタジアム(Nack5スタジアム等)で行われました。FLUTEはファイル転送をマルチキャスト上で行うためのプロトコルであり、パケットロスにはデータの繰り返し配信(カルーセル) もしくはFECにより対応します。また、FLUTEは、ATSC3.0におけるROUTE/DASHのROUTE部分のベースとなっています。

まとめ

• アプリによるマルチキャスト受信は問題なし（ただしAndroid系にはダメな機種もある)
• ブラウザによるマルチキャスト受信は、今後困難になる
  • NPAPIは既に廃止、PAPI、NaCLも廃止予定
  • WebAssemblyはWebSocketベースなのでダメ
  • WebRTCは実装しだいだが、想定外利用となりそう
  • TVの内臓ブラウザを使用してる動画サービスへの影響は不明
• 古いネットワークスイッチではIGMP Snoopingしてくれないものもあるが、いまどき有線接続の機器は少ないと思われる
• 家庭内Wi-FiではIGMP Snooping＋マルチキャストのユニキャスト変換がトラブルが少ない
• 配信プロトコルとしては、キチンとマルチキャストを使う場合、Wi-Fi等におけるパケットロスを考慮に入れ、AL-FECかARQが使えるものが望ましい