【オールIPに向けたラボの取り組み】

IP配信、IP放送を支える要素技術
2022/7/29
一般社団法人 日本ケーブルラボ
技術部 清水１．IP放送とIP配信の課題

２．IP放送とIP配信の要素技術
2-1. 映像の低遅延伝送
2-2. 同時視聴ユニキャスト増による帯域増加対策

2-3. 片方向伝送における伝送品質
3．今後の取り組み2１．IP放送とIP配信の課題

２．IP放送とIP配信の要素技術
2-1. 映像の低遅延伝送
2-2. 同時視聴ユニキャスト増による帯域増加対策

2-3. 片方向伝送における伝送品質
3．今後の取り組み3

１．IP放送とIP配信の課題

映像の低遅延伝送✓ 映像伝送において低遅延のニーズは高い●TV放送と低遅延映像伝送
スポーツ中継などにおいて主映像を放送波で伝送し、アングルの異なる映像を低遅延で伝送
TV放送

低遅延映像伝送●観戦と低遅延映像伝送
スポーツ観戦などにおいて視聴アングルと異なる映像をスマホなどへ低遅延で伝送●インタラクティブサービスと低遅延映像伝送
ライブネットオークションやeスポーツ等のインタラクティブなサービスのために、映像を低遅延で伝送１．IP放送とIP配信の課題
２.IP放送の特徴

同時視聴ユニキャスト増による帯域増加
同時視聴者が多い時はマルチキャストが有利

IP放送（マルチキャスト）の場合
番組供給者

ch1

番組供給者

ch2

配信サーバ

・・・

番組供給者

収容局

配信事業者
ルータ

ルータ

ONU/CM

BBルータ

STB

TV

ONU/CM

BBルータ

STB

TV

STB

TV

・・・

ch50

50ch分

500人

必要帯域
IP配信（ユニキャスト）の場合
番組供給者

ch1

番組供給者

ch2

配信事業者
ルータ

ONU/CM

BBルータ

同時視聴者500人

500ch分

配信サーバ

・・・

番組供給者

同時視聴者500人

収容局
ルータ

500人

ONU/CM

BBルータ

STB

TV

ONU/CM

BBルータ

STB

TV

STB

TV

・・・

ch50

ONU/CM

BBルータ

5

１．IP放送とIP配信の課題

片方向伝送における伝送品質✓ マルチキャストの片方向の伝送では、伝送品質の劣化によりでエラーが発生した場合の対策が必要✓ 片方向伝送における品質確保のために誤り訂正機能が必要映像配信
サーバ

エラー発生

視聴端末

データセグメント

片方向伝送のためデータ再送要求ができない

誤り訂正機能が必要

エラーが発生した
データセグメント再送要求

１．IP放送とIP配信の課題

２．IP放送とIP配信の要素技術
2-1. 映像の低遅延伝送
2-2. 同時視聴ユニキャスト増による帯域増加対策

2-3. 片方向伝送における伝送品質
3．今後の取り組み
7

２．IP放送とIP配信の要素技術

IP放送とIP配信の要素技術✓ IP放送、IP配信における3つの課題に対する、ラボが検討を行った4つの要素技術を概説

映像の低遅延伝送

同時視聴ユニキャスト増による帯域増加対策

片方向伝送における伝送品質

要素技術

低遅延の映像伝送を実現するCMAF (Common Media
Application Format)

大容量のデジタルコンテンツを効率的かつ迅速に、ユーザーに配信するCDN (Content Delivery Network)
マルチキャストによるネットワークの帯域削減を実現するM-ABR(Multicast Adaptive Bit Rate)
片方向の伝送路において、誤り訂正符号を付加することにより品質を確保するFLUTE (File Delivery over Unidirectional
Transport)
8

１．IP放送とIP配信の課題

２．IP放送とIP配信の要素技術
2-1. 映像の低遅延伝送
2-2. 同時視聴ユニキャスト増による帯域増加対策

2-3. 片方向伝送における伝送品質
3．今後の取り組み9

２.１映像の低遅延伝送

遅延の要因✓ 遅延が発生するポイント●素材取込（①）●サーバへの映像配信（②,③）●クライアントへの映像配信（④～⑥）①④

ライブ配信例②③⑤⑥

Encoding

Ingest

ネットワーク

Player(Last Mile)
CaptureDelivery
サーバへの映像配信

クライアントへの映像配信
10

遅延の内訳✓ プレイヤーでの遅延が支配的(約50%)✓ プレイヤーでのバッファ処理に起因 (映像配信単位であるセグメントの長さにより再生開始時間が遅延)①②③

LATENCY TYPESECONDSIMPACT

Capture

0.39

7.58%

Encoding

1.48

28.79%

Ingest

0.27

5.25%

Repackaging

N/A

N/A

0.17

3.33%

0.28

5.44%

2.55

49.61%

5.14

100%④ Delivery⑤ Last Mile
⑥ PlayerEnd-to-End Latency

出典 https://aws.amazon.com/jp/blogs/media/how-to-compete-withbroadcast-latency-using-current-adaptive-bitrate-technologies-part-1/

11

２.１映像の低遅延伝送

CMAF Chunk✓ CMAFは共通のメディアコンテナフォーマットとしてISO BMFF(Base Media File Format)として定義✓ HTTP/1.1*を利用して、セグメントを分割した”chunk”単位で配信*コンテンツを短く分割して送信し、受信側では受信した分から再生するプロトコル

通常のセグメント
ファイル

moof

mdat
5秒（例）
分割

エンコーダ出力chunkCMAF
Chunk

moof

mdat

moof

エンコーダ出力mdat・・・

エンコーダ出力moof

エンコーダ出力mdat

エンコーダ出力

Moof: メタデータ
Mdat: データ12

２.１映像の低遅延伝送

CMAF Chunkによる効果の例✓ 5secのセグメントを作って配信するより、500msecの Chunks を作って配信して再生した方が遅延低減
視聴操作
←5sec

5sec→←

5sec→←

5sec→←

5sec→←→CMAF未使用
生成再生

SEGMENT 1← 4sec遅延 →SEGMENT 2

SEGMENT 3

SEGMENT 4

SEGMENT 1

SEGMENT 2

SEGMENT 3

SEGMENT 4

CMAF使用生成再生

SEGMENT 1
1 2 3 4 5 6 7 8 910

SEGMENT 2
1 2 3 4 5 6 7 8 9SEGMENT 1
1 2 3 4 5 6 7 8 91010

SEGMENT 3
1 2 3 4 5 6 7 8 9SEGMENT 2
1 2 3 4 5 6 7 8 91010

SEGMENT 4
1 2 3 4 5 6 7 8 9SEGMENT 3
1 2 3 4 5 6 7 8 91010

SEGMENT 4
1 2 3 4 5 6 7 8 910

チャンク
500 msec

13

CMAF Chunk利用に必要な機能✓ エンコーダ側は、CMAF Chunk対応が必要✓ プレーヤー側にはCMAF Chunk を次々に再生処理部へ渡してゆくには Fetch API への対応が必要

出典：エンジニアのなんでもメモ帳「Adobe Flashの終了とCMAFによるHLS/DASH超低遅延配信」

14

日本ケーブルラボの取り組み✓ 低遅延映像配信に関する技術調査を実施●「低遅延映像コンテンツ配信手法調査報告書」 JLabs DOC-083 2.0版 (2021/5)✓ ケーブルテレビにおける統一的運用を目的としJLabs運用仕様を策定●「IP-VODサービス運用仕様」 JLabs SPEC-030 2.0版 (2021/11)
コンテンツ符号化仕様のコンテナ形式としてCMAF形式を規定●「M-ABR運用仕様」 JLabs SPEC-043 1.0版 (2022/1)
コンテンツ制作と蓄積の仕様に、JLabs SPEC-030 2.0版に基づくCMAF形式を規定

15

１．IP放送とIP配信の課題

２．IP放送とIP配信の要素技術
2-1. 映像の低遅延伝送
2-2. 同時視聴ユニキャスト増による帯域増加対策

2-3. 片方向伝送における伝送品質
3．今後の取り組み16

２.２同時視聴ユニキャスト
３．ＣＤＮ
増による帯域増加対策

増加するトラヒック✓ 総ダウンロードトラヒックは、2021年11月では、約23.7Tbps。対前年同月比で19.3%増

出典:我が国のインターネットにおけるトラヒックの集計結果(２０２１年１１月分) ２
０２２年２月４日
総務省 総合通信基盤局電気通信事業部 データ通信課

17トラヒック増加への対策✓ トラヒック増加対策の内、キャッシュサーバの導入(CDN)とマルチキャスト利用(M-ABR)を検討
インフラ対策ネットワークの高速化(基幹系、アクセス系FTTH化)

ネットワークの高機能化(仮想化、ソフトウェ化)

ネットワーク側の増強

回線調達対策トランジット/IX導入
キャッシュサーバの導入

流れるトラ
フィックの効率化

トラフィック適正化対策
速度規制(帯域制御)
利用状況別対策(映像配信にマルチキャスト利用)
オフロード対策18

CDNの概要✓ 視聴者に近い箇所にキャッシュサーバを設置し、上位回線のトラヒックを削減✓ 種類はプル型とプッシュ型✓ 低遅延化も実現

トラヒックを削減

低遅延化

19

CDNの導入モデル✓ 導入モデルは3つに大別
導入モデル

内容

管理主体

例

パブリックCDN（Buyモデル)ベンダのCDNを活用

CDN
ベンダ

AkamaiAmazon

事業者

J-Stream

事業者

COMCAST
JOCDN

プライベートCDN（Buildモル）

事業者が自社でCDNを構築

BOT（BuildOperateTransfer）

ベンタがCDN CDN
を構築および ベンダ
管理その後、 ↓事業者に移 事業者
管Velocix社が構築後、TWCが管理

・地域IX例(tochigix)
ケーブルテレビ(㈱)に設置したCDNキャッシュサー
バを近隣事業者と共用

20

日本ケーブルラボの取り組み✓ CDNに関する技術調査を実施●「CDN調査報告書」 JLabs DOC-050 1.0版 (2018/6)
CDNの基本技術調査を実施●「映像配信ネットワーク効率化技術調査報告書」 JLabs DOC-075 1.0版 (2020/12)
映像配信におけるCDN活用方法の技術調査を実施●「ケーブルにおけるローカル5Gの技術調査報告書」 JLabs DOC-084 1.0版 (2021/5)
5G関連技術としてMECの技術調査を実施

21

M-ABRの概要✓ NHKプラスのような放送型VOD(IP同時配信)コンテンツを効率的に配信✓ マルチキャストとユニキャストのハイブリッド、ABR採用によるマルチデバイス対応
通常の配信
ユニキャスト

配信
サーバ

ライブ映像

コネクション毎にアクセス網の帯域を使用
アクセス網

HGW/STB

マルチデバイス対応（スマホ可）
宅内網

M-ABR
Multicast-assisted
Adaptive Bit Rate

マルチキャスト
マルチキャストサーバ

アクセス網の帯域利用を効率化

ユニキャストマルチ⇒
ユニ変換

マルチデバイス対応（スマホ可）22

M-ABR技術の標準化動向
CableLabs⚫ 技術報告書を2016年10月に発行➢ OC-TR-IP-MULTI-ARCH-V01-141112: Multicast Adaptive Bit Rate
Architecture Technical Report

欧州DVB*⚫ 2018年3月に暫定文書として発行➢ DVB Document A176: Adaptive media streaming over IP multicast➢ 参照機能アーキテクチャおよび展開モデルを規定⚫ 2020年3月：DVB Document A176 (second edition)➢ 詳細化した第2版➢ マルチキャスト配信プロトコルとしてFLUTEとROUTEを規定➢ 配信網として双方向IP網と放送等の片方向ネットワークを想定*DVB(Digital Video Broadcasting):欧州の放送方式等を定める組織
23

４．M-ABR

M-ABR システム構成図(DVB A176)*④マルチキャストGWをアクセス網のエッジに配置するモデルも想定

サービス提供事業者

①
コンテンツ
製作

番組情報をカルーセルで通知

Push(HTTP, RTP)

②Pin’

マルチキャスト・エンコード・暗号化・パッケージング

Pull(HTTP)
Oin

コンテンツサーバ

加入者宅内

アクセス網*

プロビ・システム

サーバ

マルチキャスト

FLUTE/ROUTE

M④
マルチキャスト

GW

L
ユニキャスト

HTTP

⑤
コンテンツ
再生

HTTP/1.1

・アンパッ
⑥
エラー修復

修復要求
修復パケット

エラー
修復機能

ケージ
・復号
・デコード

ユニキャスト③マルチキャスト
通知サービス(Rendezvous)

番組情報提供ユニキャストRidirect24４．M-ABR

コンテンツフォーマット等

マルチキャストサーバへのIngest 方式

主なフォーマット

コンテンツ制作後、一旦コンテンツサーバに蓄積し、マルチキャストサーバがHTTPで取得

MPEG-DASH*

Pull

HLS

利用プロトコル

HTTP(S)**

MPEG-DASH*
コンテンツ制作機能からマルチキャスト
Push
サーバに直接入力（ライブ配信等）

HLS
MPEG-2 TS

RTP* LC: Layered Coding（マルチレート）を含む** HE内(インタフェースOin、Pin’)および宅内(L)25

４．M-ABR

エラー修復(Error Repair)
マルチ→ユニ変換

マルチキャスト
サーバ

エラー発生
視聴端末
セグメント

コンテンツ エラー修復
サーバ
サーバ

エラーセグメントの補完

HGW/STB• マルチキャストでのエラーセグメントを受信側(HGW/STB)で検知• ユニキャストでエラーセグメントを補完して送信

26

４．M-ABR

エラー修復の手順
コンテンツ
サーバ

HGW/STB

マルチキャストサーバ

視聴端末

マルチキャスト
FLUTE/ROUTE

バッファ

マルチキャスト
ストリームをキャッシュし、修復に利用

エラー
発生

キャッシュが利用できない場合はコンテンツサーバよりエラー部分を取得

HTTP

エラー
検知

修復ファイル要求
修復ファイル取得

エラー修復
サーバ

エラー修復

27

４．M-ABR

M-ABR検証結果：トラヒック削減効果(Mbps)

1台目再生※M-ABR不使用時※STBのネットワーク側で観測

3台目再生

2台目再生

140120

ユニキャストトラフィック

100
80
60
40
20
0
1101

201

301

401

501

601

701

801901

1001

1101

1201

1301

1401

1501

1601

1701

1801

1901

2001
(s)

(Mbps)

140

1台目再生

120

M-ABR
トラヒック

3台目再生

2台目再生

100

マルチキャストによる配信で、宅内のデバイスを増やしても、トラヒックは増加しない

80
60
40
2001（視聴端末3台）

101

201

301

401

501

601

701

801

901

系列11001

1101

1201

系列21301

1401

1501

1601

1701

1801

1901

2001
(s)

28

日本ケーブルラボの取り組み✓ M-ABRに関する技術調査を実施●「M-ABR調査報告書」 JLabs DOC-063 1.0版 (2019/11)
M-ABRの技術調査および実証試験を実施✓ ケーブルテレビにおける統一的運用を目的としJLabs運用仕様を策定●「M-ABR運用仕様」 JLabs SPEC-043 1.0版 (2022/1)

29

１．IP放送とIP配信の課題

２．IP放送とIP配信の要素技術
2-1. 映像の低遅延伝送
2-2. 同時視聴ユニキャスト増による帯域増加対策

2-3. 片方向伝送における伝送品質
3．今後の取り組み30

２.３片方向伝送における伝送品質

マルチキャストプロトコル⚫ ２つのマルチキャストプロトコル➢ FLUTE (File Delivery over Unidirectional Transport: RFC-3926)‐ FLUTE最新版RFC-6726➢ ROUTE (Real-time Object Delivery over Unidirectional Transport)‐ FLUTEの改良版‐ アメリカの次世代地デジ規格ATSC 3.0で採用‐ 映像・音声等のメディア毎に最適なファイル分割等が特徴

31

２.３片方向伝送における５．FLUTE
伝送品質

FLUTEプロトコルスタック✓ FLUTE は放送等における片方向伝送路でIPパケットを伝送するためのプロトコル✓ BC配信時には再送によるエラー修復ができないため、FEC（AL-FEC*）によるエラー修復機能を・・・

コンテンツファイル
ソースシンボル

ファイル分割・・・
FECシンボル

・・・

AL-FEC生成FLUTE・・・

・・・IP/UDP
UDPヘッダ
IPヘッダ

FLUTEヘッダ*AL-FEC : Application Layer Forward Error Correction• 符号化アルゴリズムとして、ARIB TRではCompact No-Code FEC、LDPC
符号Staircase、Reed-Solomon Code over GF を規定
ARIB資料を基に作成

32

２.３片方向伝送における５．FLUTE
伝送品質

FLUTE FECの効率✓ FLUTE FECの効率を実機を用いて評価を実施

33

２.３片方向伝送における５．FLUTE
伝送品質

日本ケーブルラボの取り組み✓ FLUTEに関する技術調査を実施●「FLUTE/ROUTE技術概要報告書」 JLabs DOC-091 1.0版 (2022/6)
FLUTEとROUTEの技術概要を整理し、体系立ての検討を実施

34

１．IP放送とIP配信の課題

２．IP放送とIP配信の要素技術
2-1. 映像の低遅延伝送
2-2. 同時視聴ユニキャスト増による帯域増加対策

2-3. 片方向伝送における伝送品質
3．今後の取り組み35

３．今後の取り組み

2022年度の取り組み
項目

取組概要

STBアプリ開発のオープン化

スマートシティ実現のために実装が求められるデータ連携PFについて調査を行い、将来的なサービスモデルも視野に入れ、ケーブル事業者としての貢献方
法、今後の技術課題をまとめる。

放送コンテンツ差し替え関連技術

ケーブル事業者の放送コンテンツにおいて、コンテンツ差し替えなどのサービスを実施する際の課題を明確にする。

SPEC-035 字幕・文字スーパー運用仕様

高度ケーブル自主放送（SPEC-035)の4K字幕・文字スーパーに関する運用仕様の実証実験を行い、正式仕様化を行う。

分配光タップを用いたFTTH構築手法

既存のFTTHと光分配タップを用いたFTTHとの比較調査(ファイバ長、接続端末数、適用エリアなど)を行う。また、実機による分配光タップの光ロスを確認する。

IPサービス向け宅内ワイヤレス

Wi-FiIPマルチキャスト伝送品質を評価する。また、Wi-Fiの新技術(WiFi6E/7)の技術調査を行う。

運用高度化の概念検証

設備の運用保守の自動化の調査結果をもとに、実機による自動化の実証評価を行う。(自動化対象設備については検討中)。
36

３．今後の取り組み

ケーブルテレビネットワークの構築におけるローカル5G活用技術に関する調査研究⚫ 集合住宅における新4K8K衛星放送視聴環境の整備のために、棟内設備の広帯域化に関する改修が必要であること、過疎地域における共聴施設の老朽化対策⚫ 情報通信審議会答申において、ケーブルテレビにおける活用、特に住宅・マンションの引込線の無線化⚫ ローカル５Gによる効率 的 な IP 放 送 を ３
GPP の 規 範 に 沿 っ て実現するため適応型
MBMS 技 術 の 新 規
研究開発を総務省から 2021 年 に 受 託（2022年は実証）
37

３．今後の取り組み

現行MBMS方式と適応型MBMS方式の比較⚫ MBMS方式
・ 3GPPにて規格化された移動体用映像配信方式
MBMSコア
コンテンツ
サーバ

Dash by UC①全番組配信FLUTEUnicast⚫ 適応型MBMS方式（ラボ提案）

チャネル選択情報、BC受信状態情報

FLUTE by MC

基地局

BC
受信端末(BC/UC)

Dash by UC

UC②BC/UC独立配信③無線変調非同期コンテンツビットレート

・ 現行MBMS方式に、ラボ独自開発のMBMS適応制御部を導入（MBMSコア+Unicast＋適応制御部）

コンテンツサーバ

Dash by UC①視聴番組限定配信

MBMS
適応制御部
FLUTE
Unicast④BC/UC非連動

BC：ブロードキャスト
UC：ユニキャスト
MC：マルチキャスト

チャネル選択情報、BC受信状態情報

FLUTE by MC

基地局

BCUC

受信端末
(BC/UC)

Dash by UC②視聴状況に基づくBC/UC適応配信③無線変調適応型アダプティプビットレート導入④BC/UCシームレス再生
38

３．今後の取り組み
６．今後の取り組み

まとめ：技術シンクタンクとして✓計画している取り組みの他、集合住宅内通信高速化やネットワー
クの仮想化などの最新技術動向などを幅広く調査✓検討した成果は、ワークショップ、学会、国際標準化会議にて積極的に発信✓JQE講習会のテキスト更新や講義により、ケーブル業界の技術人材育成に貢献

39

ご清聴ありがとうございました

一般社団法人 日本ケーブルラボ【住所】〒103-0025 東京都中央区日本橋茅場町3-4-2 KDX茅場町ビル3F【電話】03-5614-6100【交通】東京メトロ東西線、日比谷線「茅場町」駅より徒歩2分（日比谷線2番出口）
Japan Cable Laboratories All rights reserved40