ipdc 技術仕様指針書 · また本指針書の著作権はipdc...

IPDC フォーラム 1

デジタル放送における IPDCの具体的

利活用事例の検証に関する作業班

IPDC技術仕様指針書

第 1.0版

2013年 4月 17日

IPDC フォーラム


目次

1 はじめに ........................................................................................................................... 4

2 目的 ................................................................................................................................. 5

3 適用範囲 .......................................................................................................................... 6

4 引用文献 .......................................................................................................................... 7

5 用語 ................................................................................................................................. 8

6 概要・前提条件 ................................................................................................................ 11

7 サービスモデル ............................................................................................................... 12

8 システムモデル ............................................................................................................... 17

8.1 システムモデル ........................................................................................................ 17

8.2 送信設備モデル ...................................................................................................... 20

8.3 IP受信部 ................................................................................................................ 22

8.3.1 想定サービスの IP 受信モデル ........................................................................ 22

8.4 IP入出力部 ............................................................................................................ 24

8.4.1 IP入出力部の機能構成 .................................................................................. 25

8.4.2 IPDC 受信機と外部デバイスのペアリング ....................................................... 26

8.4.3 IPDC 受信機と外部デバイス間の IPパケット転送方法 ................................... 27

8.4.4 IP入出力部で転送される情報 ......................................................................... 29

8.5 ファイル処理部 ........................................................................................................ 30

8.5.1 ファイル処理部の機能構成 .............................................................................. 30

8.5.2 利用する FLUTEプロトコルの規定と FEC...................................................... 32

8.5.3 ファイル受信動作 ............................................................................................. 33

8.5.4 受信したファイルの管理と外部デバイスからのアクセス .................................... 34

9 伝送プロトコル ................................................................................................................ 35

9.1 プロトコルスタック .................................................................................................... 35

9.2 ＰＳＩ／ＳＩ規定 .......................................................................................................... 36

9.2.1 はじめに .......................................................................................................... 36

9.2.1 サービス伝送方式 ............................................................................................ 36

9.2.1 受信機からホームネットワーク等への展開に関する伝送制御方式 .................... 48

9.2.1 スタートアップ情報 ........................................................................................... 68

9.3 ULE規定 ............................................................................................................... 69

9.4 IP／UDP 規定 ....................................................................................................... 72

10 アクセス制御とコンテンツ保護 ..................................................................................... 75

10.1 IPパケット .............................................................................................................. 75

10.2 TSパケット .............................................................................................................. 75


10.2.1 送出側 ............................................................................................................. 76

10.2.1 受信側 ............................................................................................................. 76

11 想定するアプリケーションとコンテンツ .......................................................................... 77

11.1 想定するアプリケーションとコンテンツ ...................................................................... 77

11.1.1 想定するアプリケーション要件 .......................................................................... 77

11.1.2 アプリケーションのアーキテクチャ ..................................................................... 78

11.2 想定するアプリケーション ......................................................................................... 79

11.2.1 機能構成と各機能の概要 ................................................................................. 79

11.2.2 動作シーケンス ................................................................................................ 81

11.3 制御コマンドおよびコンテンツ構造情報 .................................................................... 82

11.3.1 制御コマンド ..................................................................................................... 82

11.3.2 コンテンツ構造情報 .......................................................................................... 82

11.4 制御コマンドおよびコンテンツ構造情報 .................................................................... 83

11.4.1 IPパケットとして伝送されるコンテンツ .............................................................. 83

11.4.2 IPパケットとして伝送されるコンテンツ .............................................................. 83

12 想定する受信機構成 ................................................................................................... 84

12.1 外部デバイスがファイル処理部を持たない場合 ........................................................ 84

12.2 外部デバイスがファイル処理部を持つ場合 .............................................................. 85


1 はじめに

IPDCフォーラムはこれまで、IP Data Cast技術(以下：IPDC)を基盤とする新サービスや新産

業の創出を目的として活動してきた。

こうした中、昨年4月にサービスを開始したV-highマルチメディア放送では、その特徴である蓄

積型放送の実現に IPDC が実装される等、IPDC はすでに技術的に確立され、実用化段階に入

っているといっていい。

一方この 10 年余り、国内のあまねく地上放送局が地上デジタル放送網の充実に努めた結果、

地上デジタル放送波の世帯カバー率は 100％に迫り (※1)、放送局から各家庭のテレビコンセン

トに至る地上デジタル放送網は国内で最も普及するデジタル伝送網となった。さらに 2011年 6月

に「放送法等の一部を改正する法律」が施行され、通信・放送両用免許制度が整備されたことに

より、地上デジタル放送はいよいよ技術、普及、法制等多方面から、これまでにない新たなサービ

スを提供できる体制が整いつつある。

2012年 3月末にデジタル化を完遂した地上デジタル放送は、いよいよデジタルならではの新し

いサービスが求められている。中でも昨今盛り上がりを見せるスマートテレビに象徴されるように、

放送と通信が相互に連携するサービスへの期待度は高く、当フォーラムとリエゾン関係にあるマ

ルチスクリーン型放送研究会は、地上放送局が放送番組に関連するコンテンツをスマートフォン

やタブレットデバイス向けに提供するマルチスクリーン型放送サービスを、IPDC の活用を視野に

入れながら検討を進めている。

こうした情勢を踏まえ、本指針書は地上デジタル放送において、IPDC を利用してマルチスクリ

ーン型放送サービスを実現することを念頭に、現在の地上デジタル放送の技術規格に IPDC を

追加する場合に必要となる技術規格の改定等について検討したものである。

※1：平成 23年版情報通信白書

http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h23/index.html


2 目的

本指針書は、地上デジタル放送の放送網を有効に活用して多様なサービスを実現するため、

地上デジタル放送に IPDC を実装するための技術的課題抽出とその解決方策について検討する

ことを目的とする。


3 適用範囲

本指針書は IPDCフォーラムの会員有志による技術検討の成果をまとめたものであり、パテント

等の処理は行っていない。したがって、今後更なる検討を経て規格化や標準化等への段階に進

む場合には、それらの処理を行う必要がある。

また本指針書の著作権は IPDC フォーラムに帰するものとし、他の著作物において参照（部分

参照含む）される場合には、当フォーラム（ [email protected] ）までご連絡いただきたい。


4 引用文献

ARIB STD-B10 デジタル放送に使用する番組配列情報

ARIB STD-B32 デジタル放送における映像符号化、音声符号化及び多重化方式

ARIB STD-B45 デジタル放送におけるダウンロード方式

ARIB TR-B14 地上デジタルテレビジョン放送運用規定

ARIB TR-B33 セグメント連結伝送方式による地上マルチメディア放送運用規定


5 用語

本指針書で用いている用語について以下に記載する。

AL-FEC Application Layer Forward Error Correction.：アプリケーション

層でのFEC（前方誤り訂正）。携帯端末での移動受信時等でのデ

ータ消失耐性を高めるための方法。

CAS Conditional Access System：限定受信方式。サービス（編成チ

ャンネル）やイベント（番組）の視聴を制御するシステム。有料番

組及びコンテンツ保護を伴う無料番組の放送に不可欠。

EPG Electronic Program Guide:：リアルタイム型放送サービスに関し

て、番組表などの番組情報の提示、番組の選択を可能にしたり

する手段。電子番組ガイド。

FDT File Delivery Table： IETF RFC 3926で規定されるFLUTE で

配信するファイルについての属性を記述するテーブル。

FEC Forward Error Correction.：前方誤り訂正。データ転送にお

ける誤り制御システムの一種。データの再送を防ぐことで高ス

ループットを平均的に達成するメリットがある。

FLUTE File Delivery over Unidirectional Transport.：ファイルデリバリー

のプロトコル。片方向の伝送路（例えば、下り方向のみの伝送

路）を用いてデータ配信を行うことが可能であり、任意ファイルの

送信が可能であるという特徴がある。IETF RFC 3926。

ISDB-Tmmや DVB-H で採用。

IPDC Internet Protocol Data Cast：通信の世界で一般的であった IP

パケット（IPデータグラム）を放送用電波に乗せて一斉配信す

るサービス。

MPE Multi-Protocol Encapsulation： IPパケットを TSパケットにカプセ

ル化する方式の一つ。DVB-Hや ATSC-DTV(Digital Television)

で採用。

NTP Network Time Protocol：ネットワークに接続される機器におい

て、機器が持つ時計を正しい時刻へ同期するための通信プロ

トコル。

PID Packet Identifier：パケット ID（識別子）。TS パケットヘッダ部の

13 ビットのストリーム識別情報で、当該パケットの個別ストリー

ムの属性を示す。

PSI Program Specific Information：番組特定情報。所要の番組を選

択するために必要な情報で、PAT、PMT、NIT、CAT、INT の 5つ


のテーブルからなる。

PSI/SI PSIの情報に加えて SI（Service Information）を加えた情報の総

称。

SI Service Information：番組配列情報。番組選択の利便性のた

めに規定された各種情報。総務省令で定義され、内容は

ARIB 規格として規定。ARIB 規格独自の拡張部分に加え

て、MPEG-2 のPSI情報も含まれる。

TOT Time Offset Table：現在の日付時刻を指示、および、サマータ

イム制度実施時に実際の時刻と人間系への表示時刻の差分時

間を指定する。

ULE Unidirectional Lightweight Encapsulation： IP パケットを TS

パケットにカプセル化する方式の一つ。ISDB-Tmmで採用。IETF

RFC4326 にて規定。

ROHC RObust Header Compression：スウェーデンの携帯電話システ

ムメーカーであるエリクソン社が開発したヘッダー圧縮アルゴリ

ズム。

IPDC受信機 IPDCを含むデジタル放送電波のRFを受信し、選局された TS

の中の特定 ESから IPパケットを抽出することを想定した受信

機能を持つ。

外部デバイス IPDC受信機の外部にあり、ネットワークを経由して接続する

端末を意味する。ここでは主にタブレットやスマートフォンを想

定する。

ホームネットワーク IPDC受信機と外部デバイスの間のネットワークを意味する。

家庭内の無線 LAN環境においての使用を想定した名称とし

ているが、ネットワークとしてはこれに限るものではない。

IPDCサービス IPDCを含む放送サービスを意味する。「テレビサービス」、「デ

ータ放送サービス」と同レベルの用語として使用する。

IPデータキャスト IPDC サービスに属し、IPDC 形式の ESを意味する。IPDC として

使用する PMTの中に属する ES（コンポーネント)そのものを意味

する。複数の IPデータキャストは物理的に PID値、論理的にコン

ポーネントタグ値で区別される。

スタートアップ情報 IPデータキャストの中のデータの一つ。アプリケーションにてデフ

ォルト動作を行うときに必要とし、PMTに記載されたES情報の IP

アドレス単位でスタートアップ情報の有無を指定し、「有」の場

合にデフォルトポート番号(T.B.D)に特定情報(T.B.D)を配置す


る。

TCPプロキシ接続 IPDC 受信機と外部デバイスの間の接続方式。IPDC受信機で抽

出された IPパケットをそのまま外部デバイスに配信するために用

いる。

SSDP Simple Service Discovery Protocol

外部デバイスから IPDC受信機の存在と IPアドレス解決のた

めに用いる。


6 概要・前提条件

1. 検討対象は地上デジタル放送とする

2. 固定受信を前提とする

3. すでに広く普及するデジタル放送受信機（テレビ等）に悪影響を与えないこと

4. IPの長所を最大限活用し、特定のサービスに偏らず多様なサービスに対応できること

5. テレビサービスとの関連性に留意すること


7 サービスモデル

放送用電波に IP を乗せて一斉配信する IPDC でのサービスは、IPDC で送られた IP データ

を受信する IPDC受信機、スマートフォンやタブレットなどのセカンドデバイス、ルーター、テレビな

どを組み合わせて、様々ものが想定される。

各機器は単独で有るだけでなく、テレビと IPDC 受信機の一体型、IPDC 受信機とルーターの

一体型、IPDC 受信機とセカンドデバイスの一体型、テレビとルーターの一体型など、各機能を組

み合わせた機器も考えられる。

図 7-1 想定する IPDCサービスの受信形態

なお、この章ではわかりやすくするために、機器は単独であるとして表記する。

IPDC でのサービスは、次の 2つに大別される。

① 独立データキャスト

独立データキャストは、放送から独立した情報を配信する。独立データキャストではテレビは

必須でなく、外部デバイスだけでも良い。

② 連動データキャスト

放送（テレビ番組）と連携した情報を外部デバイス向けに配信する。テレビ視聴を前提とし、テ

レビとセカンドデバイスが連携する。


独立データキャスト IPDC受信機のみのサービス

図 7-2 独立データキャストにおける IPDC 受信機のみのサービスモデル

IPDC受信機で IPデータの受信と表示処理を行い、映像と音声のみ外部出力する。

デジタルサイネージへのコンテンツ配信、3Dや 4Kの番組蓄積の配信などが想定される。

独立データキャスト外部デバイスを用いるサービス

図 7-3 独立データキャストにおける外部デバイスを用いるサービスモデル

IPDC 受信機で受信した IP データを外部デバイスに送る。IP データの表示処理は、外部デバ

イスに搭載されているアプリケーションで行う。

IPDC受信機と外部デバイスは、1対 1、もしくは 1対複数で接続される。各外部デバイスでは、

送られたデータからデバイスに登録されている属性にあわせて情報を取り出し表示することがで

きる。


これにインターネットを組み合わせたものが次の図になる。

図 7-4 独立データキャストにおける外部デバイスとインターネットを用いるサービスモデル

インターネットへの接続は、ルーター経由で行う。

インターネットを併用することで、IPDC で欠落したデータの補完や、インターネットを利用してコ

ンテンツを取得することもできる。また、外部デバイス側からデータ送信が可能になるので、双方

向を前提としたコンテンツ制作が可能になる。

独立データ配信サービスや、放送と連動しない独立放送（動画・音声）、電子新聞や電子書籍

などの配信が想定される。


連動データキャストによるサービス

図 7-5連動データキャストにおけるサービスモデル

テレビの表示（放送番組）に連携して、外部デバイスの表示内容が変化する。

IPDC受信機と外部デバイスは、1対 1、もしくは１対複数で接続される。各外部デバイスでは、

送られたデータからデバイスに登録されている属性にあわせて情報を取り出し表示することもでき

る。

これにインターネットを組み合わせたものが次の図になる。

図 7-6 連動データキャストにおいてインターネットを用いるサービスモデル


インターネットへの接続は、ルーター経由で行う。

インターネットを併用することで、IPDC で欠落したデータの補完や、インターネットを利用してコ

ンテンツを取得することもできる。また、外部デバイス側からデータ送信が可能になるので、双方

向を前提としたコンテンツ制作が可能になる。

マルチスクリーン型放送がこれにあたる。


8 システムモデル

8.1 システムモデル

地上デジタル放送において IPDC サービスを実現する場合、図 8-1 のようなシステムモデルを

想定する。IPDC サービスは現在ほとんどの地上波局が 12 セグメントを使用して運用している固

定サービスでのみ実施することを想定する。IPDCサービスには、テレビ番組連動サービスと独立

サービスがある。放送局側のシステムには、新たな IPDC 送出システムを導入するほか、既設の

デジタル放送送出・送信システムに変更を加えることが必要である。受信側システムとしては新た

な IPDC 対応デジタル放送受信機の導入に並行して、既設のデジタル放送受信機に外付けの

IPDC 対応受信機が付加される形で普及していくと考えられる。IPDC 受信機は図のような無線

ルータタイプだけでなく、テレビタイプ、ディスクレコーダタイプ、タブレットタイプ、パーソナルコンピ

ュータなどが考えられる。一台の IPDC 受信機に複数の地上デジタル放送受信機や外部デバイ

スが同時に接続される場合がある。反対に１台の外部デバイスが複数の IPDC 受信機が存在す

る環境に置かれる場合も想定する。ホームネットワークは IPV4の場合も IPv6 の場合もある。受

信機は、当該地域で IPDC 実施局・非実施局が混在することを想定する必要がある。同時に、同

一地域で複数の地上デジタル放送局が IPDCサービスを実施することも想定する。

図 8-1 IPDC システムモデル

IPDC受信機

地上デジタル放送受信機

インターネット

WAN

（FTTH/ADSL

/CATV等）

RF（同軸）

RF（同軸）／HDMI等 IPDC

送出システム

通信系システム

デジタル放送

送出・送信システム

IPDC制作・送出シ

ステム

外部デバイス


システムモデルの機能ブロックについて図 8-2に示す。

TS

RF

ホームネットワーク

TS処理

外部デバイスIPDC受信機

IP処理

ULE処理

フロントエンド制御

マルチキャスト管理

フロントエンド

IP

入出力部

FLUTE処理

IP受信

一体型受信機

FLUTE処理

IP受信

内部ストレージ

内部ストレージ

アプリケーションＩＰ受信部

ファイル処理部1

送信処理ブロック

IPIPIP

IP

FILE

FILE

IP処理

FILE処理

ファイル処理部2

TS

IPIP

ＩＰ送信部

PMT処理

RF

IP TS処理

IP処理

TSULE処理送信機マスターシステム

TS TS RF

※ファイル処理部は1又は2どちらか

アプリ処理

TCPプロキシ接続

受信処理ブロック

IP

入出力部

図 8-2 IPDC システムの機能ブロック

□送信処理ブロック

１）IP 送信部

送信処理として IPパケットを放送プロトコルに重畳するしくみ全体を「IP送信部」として定義する。

通常の映像・音声の放送に加え、IPDC サービスを実施するためにこの IP 送信部を定義する。

PMT 処理機能、IP 処理機能、ULE 処理機能、TS処理機能を備え、TS としてマスターシステム

と接続し、送信される。

□受信処理ブロック

１）IP 受信部

受信処理としてRF受信から IPパケットを抽出して配信するまでを「ＩＰ受信部」として定義する。

PSI/SI情報からの IPDCサービスの有無、IPDCサービスから IPデータキャスト認識によるES

選択、該当ESからの IP抽出を行う。フロントエンド受信機能、TS処理機能、ULE処理機能、IP

処理機能を備える。


２）ファイル処理部

FLUTE プロトコルを持つ IP パケットを受信し、ファイルとして再構成するための「ファイル処理

部」として定義する。ここではファイルを一時的に保持し、外部からは HTTP としてアクセスできる

ように Web サーバ機能を有することを想定する。IP 処理機能、FLUTE 処理機能、内部ストレー

ジ機能を備える。

３）IP 入出力部

抽出された IP パケットを外部デバイスに対して配信するためのインタフェースとして「IP 入出力

部」を定義する。ホームネットワークにおいて、外部ネットワークへ影響を与えないことと、外部ネッ

トワークに影響されないことを想定し、ローカルネットワーク環境を構築する。TCP プロキシ接続

機能を備える。

４）アプリケーション部

IP パケットと Web サーバ経由のコンテンツを使用してデータ処理や表示処理を行うものとして

「アプリケーション部」を定義する。アプリケーション機能は本指針書では規定しない。尚、アプリケ

ーションとしてファイル処理部を持つような実装も可能である。

□受信装置の想定

受信側の装置として、以下の装置を想定する。

１）IPDC受信機

IP受信部にファイル処理部と IP 入出力部を加えたものを IPDC受信機として想定する。

２）外部デバイス

IPDC受信機の外にあり、ホームネットワーク内に存在するデバイス(タブレットやスマートフォン)

を想定する。外部デバイスから IPDC受信機に接続して IPパケットの受信とWebアクセスによる

ファイル取得を行う。データ処理についてはアプリケーションレイヤとして処理する。

３）一体型受信機

IPDC 受信機と外部デバイスを組み合わせた装置を想定する。


8.2 送信設備モデル

地上デジタル放送によって IPDCサービスを行うためには、既存のデジタル放送送出・送信シ

ステムに対して、IPDCサービスを行うための送出システムを追加する必要がある。IPDCの送出

システムは、図 8-3 に示すように、音声映像、データ放送、字幕・文字スーパーを送出、伝送する

システムとは独立に構築され、多重化装置で MPEG-2 TS レベルで多重化されるようなシステム

構成を想定している。図 8-3 における ULE 伝送方式は、9.3ULE 規定、FLUTE 伝送方式は、

9.5FLUTE 規定に従う。

現行の地上デジタル放送設備に IPDCシステムを導入するには、図 8-3のPSI生成、番組配列

情報に対して 9.2 PSI/SI 規定への対応が必要である。また、IPDC 送出システムからの出力

(MPEG-2 TS)を地上デジタル放送に多重するために、多重化装置への多重設定等を行うことが

必要となる。その他の対応は、IPDC サービスで実施するサービスの内容に依存する。データ放

送の番組連動において実施例があるような番組進行と厳密に連動した IPDC サービスを実現す

る場合、番組スケジュールから連動タイミングを IPDC送出システムに通知するような機能追加が

必要となる。IPDC コンテンツのデータ符号化方式は規定せず、IPDC サービスの外部デバイス

には、IPDCコンテンツに対応したアプリケーションが予めダウンロード等によりプリインストールさ

れているような利用想定となっている。

多重化・スクランブル・変調

データ放送コンテンツ制作

ＡＶ／字幕制作

ＩＰＤＣコンテンツ制作

番組スケジュール

ＥＰＧ情報生成

ＰＳＩ生成

番組配列情報（セクション伝送方式）

ＡＶ伝送方式（PES伝送方式）

字幕・文字ｽｰﾊﾟｰ伝送方式（独立PES伝送方式）

データ放送伝送方式(カルーセル伝送方式)

マルチメディア符号化モノメディア符号化

字幕、文字ｽｰﾊﾟｰ符号化

データ放送コンテンツ送出系

ＡＶエンコーダ

ベースバンド制御系

字幕・文字スーパー挿入

ＩＰＤＣコンテンツ送出系

ＩＰＤＣ伝送方式(ＵＬＥ伝送方式)

ＦＬＵＴＥ伝送方式

制作系送出系伝送系

ＩＰＤＣ送出システム

MPEG

2-TS

図 8-3 地上デジタル放送送出システム構成


送信設備における通信系システムは、地上デジタル放送で配信したコンテンツの補助的な役割

を行う。IPDC コンテンツは、放送波のみですべての配信するようなコンテンツのほかに、放送波

で配信するコンテンツと通信で取得するコンテンツから構成されるコンテンツも想定している。通信

システムは、一般的な HTTP サーバのほかに、アプリケーションとの双方向通信を前提としたも

のなど、IPDCサービスの内容に依存する。

制作系送出系伝送系

MPEG

2-TS

多重化・スクランブル・変調

ＩＰＤＣコンテンツ制作

ＩＰＤＣ送出設備 IPDC

受信機

表示端末

地上波デジタル放送送出システム

・PSI情報、番組配列情報送出・ＡＶ送出・字幕・文字スーパー・データ放送送出

公衆網等

通信系システム

httpサーバ

双方向サーバその他各種サーバ

図 8-4 送信設備における通信系システム構成


8.3 IP受信部

IPDC受信機に、放送波から IPパケットを受信・出力する機能までを IP受信部として定義する。

8.3.1 想定サービスの IP受信モデル

7 章【サービスモデル】でサービスの全体像を想定しているが、ホームネットワーク等での IPDC

受信機の存在は以下の図 8-5のようになると考えられる。

インターネット

ＩＰパケット

アプリケーション

ＩＰパケット

ＩＰＤＣ受信機

ホームネットワーク等

ＩＰパケット

図 8-5 IPDC 受信機とホームネットワーク等の構成

IPDC 受信機の IP 受信部は、TS に多重されている IP データキャストの IP パケットの構成が

記載されている伝送制御信号(PMT)をファイル処理部および外部デバイスへ配信する機能と、放

送波から IPパケットを抽出・出力する機能を想定している。

以下に、既存テレビサービスの受信機の中に IP受信部を含むモデル、IPDC専用受信機として

IP受信部だけの構成のモデル、の２つの機能モデルを図 8-6 と図 8-7に示す。


フロントエンド受信部

フロントエンド制御部

TSパケット

TS処理部（DEMUX・DSCR）

伝送制御信号

チューニング

地上デジタル放送処理部

マルチキャスト管理部

IPパケットTS

パケット

TSパケット

IPパケット

RF

IPパケット処理部

既存受信機に存在する機能

ULE処理

UDP/IP処理

図 8-6 地上波・IPDC 共用受信機が備える IP受信部までの機能ブロック概念図

フロントエンド受信部

フロントエンド制御部

TSパケット

TS処理部（DEMUX・DSCR）

伝送制御信号

チューニングマルチキャスト管理部

IPパケット

TSパケット

RF

IPパケット処理部

ULE処理

UDP/IP処理

図 8-7 IPDC 専用受信機が備える IP 受信部の機能ブロック概念図

受信機は TS内の PSI/SIの情報の中から、IPDCサービスを発見し受信処理を行う。

IPDC 受信機の IP 受信部(ULE の出口)はマルチキャストネットワークにおけるソースとしてふ

るまい、ファイル処理部や外部デバイスはマルチキャストにおけるリスナーとしてふるまうことを想

定する。IP 受信部は、チャンネル変更で PMT が変化するタイミングやファイル処理部や外部デ

バイスから初期アクセス情報の配信要求を受けたタイミングに、IPDCサービスの PMT テーブル

（セクション形式）をマルチキャストで配信する。そのマルチキャストアドレスには限定スコープアド

レスを想定する。PMT の内容から、IPDC ストリームの構成を認識したファイル処理部と外部デ

バイスは IP受信部に対して、IPデータキャスト配信要求を行い、IP受信部はその要求に対して、

IPパケットを配信する。


8.4 IP入出力部

この節では、IP 入出力部について記載する。

IP入出力部は、8.3節【IP受信部】に記載した IP受信部から出力される IP パケットを、ホーム

ネットワークに接続された外部デバイスに転送したり、逆に、外部デバイスからのマルチキャスト

JOIN要求パケット等を IP受信部に転送する役割を持つ。

IPDC 受信機と外部デバイスのそれぞれに IP 入出力部があり、それらが連携して動作する。

外部デバイスのアプリケーションは、IP入出力部を経由して、PMT情報を受け取って IPDC受信

機の受信している IPDCサービスやデータキャストを特定し、さらに、目的のデータキャストを指定

して受信要求を出してそれを受信することができる。

上記の動作フローを以下の図 8-8に示す。

図 8-8 IP入出力部の動作フロー


8.4.1 IP入出力部の機能構成

IP入出力部は、以下の 3つの機能で構成される。

（１） IPDC 受信機と外部デバイスをペアリングする機能

ここで、ペアリングとは、IPDC 受信機と外部デバイスが、互いに、ホームネットワーク等

での相手の IPアドレスを知り、相互に IPパケットを転送可能な状態にすることを指す。

（２） IP 受信部から出力された IPパケットを、外部デバイスに転送する機能。

ここで転送する IPパケットには、

・IPDC受信機が受信している IPDC サービスを特定するための

PMT 情報のパケット

・IPDCサービスを構成する IPDCデータキャストのパケット

の 2つがある。

（３）外部デバイスから IPDC 受信部に向けたパケットを転送する機能。

ここで転送する IPパケットは、

・アプリケーションが利用する IPDCデータキャスト（マルチキャスト）への

受信要求（マルチキャストアドレスとポート番号を指定した JOIN要求）パケット

などである。

上記の機能概要を以下の図 8-9に示す。

図 8-9 IP入出力部の機能概要


8.4.2 IPDC受信機と外部デバイスのペアリング

IPDC 受信機と外部デバイスのペアリングは、以下のような手順を想定する。

（１）外部デバイスが IPDC 受信機を探す問い合わせをブロードキャストする

外部デバイスは、ホームネットワーク等に、IPDC受信機への問い合わせとして、あて先 IPア

ドレス 239.255.255.255、あて先ポート番号 1900 のUDPパケットをブロードキャストする。

（２）IPDC 受信機の応答

IPDC 受信機は、上記の問い合わせに UDP で応答し、IPDC 受信機のホームネットワーク

内での IPアドレスを外部デバイスに通知する。

（３）IP アドレスの格納

上記２つの手順により、IPDC 受信機と外部デバイスは、ホームネットワーク等におけるお互

いの IP アドレスを知り、それを適切に格納することにより、ペアを形成する。

上記の手順は、SSDP(Simple Service Discovery Protocol)として規定されている一連のプロト

コルの一部と同様の動作であるが、本指針書としての技術仕様をSSDP準拠とするかはT.B.D.。


8.4.3 IPDC受信機と外部デバイス間の IPパケット転送方法

IP 受信部から出力される IP パケットは、UDP のマルチキャストパケットである。それを外部デバ

イスに転送する方法として、ホームネットワーク等にマルチキャスト配信して外部デバイスがそれ

に JOINして受信する方法も考えられるが、その場合、無線LANの特性によるパケットの欠落や、

ホームネットワーク等に多量のマルチキャストパケットが流れることによる通信障害の懸念、ホー

ムネットワークを流れる他のサービスとのマルチキャストアドレス重複の可能性、といった課題が

想定される。

それらの課題を解決するためには、各種の TCP 通信によるトンネリング手法等が考えられるが、

本指針書では、放送局から送出された UDP パケットをそのままペイロードとして扱えることと、タ

ブレット等のルーター機能の改変に制限がある外部デバイスを考慮し、IP 受信部から出力された

UDP パケットを、IP 入出力部ではペイロードとして扱い、ホームネットワーク内での TCP 通信に

より転送する方式とする。

この方式を、「TCPプロキシ接続」と呼ぶ。

ただし、将来は、別の仕組みを採用することを妨げるものではない。

TCPプロキシ接続フォーマットを図 8-10に示す。

図 8-10 TCP プロキシ接続フォーマット


TCPプロキシ接続において、IPDC受信機側、外部デバイス側、それぞれの IP入出力部の機能

は以下の通り。

（１） IPDC 受信機の IP入出力部の機能

・IP受信部から出力されるマルチキャストに JOINする

・外部デバイスの IP入出力部との間で TCP セッションを確立する

・IP受信部から、UDPパケットをマルチキャストで受け取り、受け取った UDPパケットを、

TCP通信のペイロードとして外部デバイス側の IP 入出力部に転送する

・外部デバイス側の IP入出力部から TCP通信のペイロードとしてUDPパケットを受け取

り、それを IP 受信部に転送する。

（２）外部デバイスの IP入出力部の機能

・IPDC受信機の IP入出力部との間で TCP セッションを確立する

・外部デバイスのループバックインターフェース(127.0.0.1)に対して、マルチキャストサーバ

として動作する。

・外部デバイスのアプリケーションからのマルチキャスト JOIN要求を、TCP 通信のペイロ

ードとして IPDC受信機の IP入出力部に転送する。

・IPDC受信機の IP入出力部から TCP通信で転送されたペイロード（UDPパケット）を、

外部デバイスのアプリケーションにマルチキャストで転送する。

※このように、IP 入出力部の動作は、マルチキャストで受け取った UDP パケットを、単にデー

タ(ペイロード)として TCP通信で転送したり、その逆を行うものである。

（３） TCPプロキシ接続数

外部デバイス上のアプリケーションから接続するプロキシ数は PMT で定義されるコンポーネ

ント毎(IPデータキャスト毎)に１本とする。

（４）切断、および途中切断時の動作

・外部デバイスのアプリケーションが起動している間は接続を継続する。

・アプリケーションが終了した時点で TCP のコネクション終了フェーズにて接続は切断す

る。

・何らかの障害等である一定時間接続応答がない場合は、接続が切断されるが、その場

合は、外部デバイスのアプリケーションから改めて接続する。


8.4.4 IP入出力部で転送される情報

IP 入出力部の目的は、IPDC 受信機が受信した情報を外部デバイスに適切に転送することであ

る。転送される情報には、以下のようなものがある。

（１） PMT 情報

IPDC サービスが含まれる、選局中の放送 TSに関する PMT情報。

PMT 情報は、バイナリデータのまま、あらかじめ決められたマルチキャストアドレスとポート

番号を用いて、UDPパケットとしてマルチキャスト配信される。

PMT情報のマルチキャストに対する外部デバイスのアプリケーションからの JOIN要求は、

IP入出力部を経由して IPDC 受信機の IP受信部に通知する。

（２） IPデータキャスト

IPDCサービスに含まれる、ファイル配信用の FLUTEや、および任意の IPパケットからな

る IPデータキャストのUDP パケット。

外部デバイスのアプリケーションが該当するマルチキャストに対する JOIN 要求を行い、IP

入出力部を経由して JOIN要求が IP 受信部に転送され、マルチキャスト配信が行われる。

FLUTE以外の任意の IPパケットとしては、アプリケーションの動作を制御するコマンドとし

ての利用や、RTP を用いたリアルタイムストリーム等が想定されるが、用途は特に規定しな

い。

スタートアップ情報

IP データキャストを使ってアプリケーションが受信処理に必要な情報をスタートアップ情報と

して伝送することが出来る。スタートアップ情報は、IP データキャストのポート番号の使い方

などを外部デバイスのアプリケーションに指示するためのもので、UDPパケットのペイロード

に記載することを想定しているが、記載内容については規定しない。

スタートアップ情報は、デフォルト値のポート番号で伝送することができる。（PMT の

IPv4_addr*/IPv6_addr*_control_data_flag と連動）

スタートアップ情報が伝送されていない場合、FLUTE はデフォルトポート番号での処理動作

となる。


8.5 ファイル処理部

この節では、IPDC で配信されたファイルを受信して蓄積し、外部デバイスの WEB ブラウザやア

プリケーションから利用可能とする役割を持つファイル処理部について記載する。

ファイル処理部は、IP 受信部から出力される IP パケットのうち、ファイル配信に用いられる

FLUTE パケットを受信してファイル化処理を行い、適切なディレクトリに格納する。

また、ホームネットワーク等においてWEBサーバとして動作する機能を持つ。

8.5.1 ファイル処理部の機能構成

ファイル処理部は、以下の 3つの機能で構成される。

（１）ファイル蓄積機能

IP 受信部の出力するマルチキャストのうち、ファイル配信のデータキャストであるものに

JOIN し、FLUTE プロトコルで受信とファイル化の処理を行い、ファイルを適切なディレク

トリに格納する。

（２）Webサーバ機能

IPDCで配信されたファイルをホームネットワーク内の外部デバイスからHTTPでアクセス

可能にする。

（３）ファイル消去機能

ファイル処理部のファイル保存容量超過の防止や、チャンネル変更時に蓄積されたファイ

ルを消去する。

上記の機能概要を以下の図 8-11に示す。


図 8-11 ファイル処理部の機能概要


8.5.2 利用する FLUTEプロトコルの規定と FEC

ファイル処理部で利用する FLUTE プロトコル、および、それと組み合わせる FEC、および、送出

側で設定する FLUTE パラメータは以下の通りとする。

（１）FLUTEプロトコル

Internet Engineering Task Force (IETF) でインターネット標準として規定されている、

FLUTE に準拠する。

（２）FEC

FLUTE と組み合わせて利用する FECについては、

・FEC なし

・Reed-Solomon 符号

・LDPC符号

・Raptor符号

から、運用時に選択して利用可能とする。

（３）送出側パラメータ

送出側では、FLUTEサーバが送出側 ULE 処理装置に対してマルチキャストパケットを

出力し、ULE処理装置が IPパケット(FLUTEのUDPパケット)を TSにカプセル化して、

放送 TS として伝送する。

その際の FLUTEサーバの送出のパラメータとして、

・マルチキャストアドレス

・ポート番号

・TSI（FLUTE のセッション ID）

・FEC の種別

・配信ビットレート

を指定可能とする。

このうち、

マルチキャストアドレスは PMT情報として送出される。

ポート番号と TSI はスタートアップ情報として送出することができるが、

スタートアップ情報を用いない場合には、

・ポート番号はデフォルト値（T.B.D)

・TSIは固定値（T.B.D)

として運用する。

FECの種別は、FLUTEプロトコルにより受信側に通知される。


8.5.3 ファイル受信動作

ファイル処理部は、以下の手順でファイル化と蓄積を行う。

（１） PMT の受信とファイル配信データキャストの選択

ファイル処理管理部は、PMT のマルチキャストアドレスを指定して JOIN要求を行い、

PMT を取得する。

スタートアップ情報を利用しない場合(IPv4(6)_addr2_control_data_ flag =0)、PMTにフ

ァイル保存可能(IPv4(6)_addr2_file_storable_flag=1 )と記載されたマルチキャストアドレ

スに JOIN し、デフォルトのポート番号と、固定の TSI値を指定して FLUTE受信処理モジ

ュールを起動する。この場合、受信すべきポート数(IPv4_addr2_num_of_port)は PMTに

記載されている。

スタートアップ情報を利用する場合(IPv4(6)_addr2_control_data_ flag =1)、ファイル処理

管理部は、スタートアップ情報のマルチキャストアドレスを指定して JOIN要求を行ってスタ

ートアップ情報を取得し、そこに記載されたマルチキャストアドレス、ポート番号、TSI 値を指

定して FLUTE受信処理モジュールを起動する。

（２） FLUTE 処理

FLUTE 受信処理モジュールは、ファイル処理管理部によって、適切なパラメータで起動さ

れ、IP 受信部に対してマルチキャストへ JOIN要求を行い、FLUTEパケットをマルチキャ

ストで受信してファイル化処理を行い、WEBサーバ機能でアクセス可能なディレクトリにファ

イルを保存する。


8.5.4 受信したファイルの管理と外部デバイスからのアクセス

FLUTE処理によって蓄積されるファイルは、以下のように管理し、また、外部デバイスからアクセ

ス可能とする。

（１）保存ディレクトリ

下記の例のように、コンポーネント ID等で区分したパスで管理する。 [詳細は T.B.D.]

例）

保存ディレクトリの階層を、

ARIB

/コンポーネント ID（放送局内でユニーク）

/( FDT インスタンスの Content-Location で指定)

とする。

ここで、コンポーネント IDは PMT情報から取得する。

（２）外部デバイスからのアクセス URL

外部デバイスからファイルにアクセスする際には、ファイル処理部のWEBサーバ機能のホー

ムネットワークでの IP アドレスを「ホームネットワークでの IP アドレス」とし、

http://(ホームネットワークでの IP アドレス)/(コンポーネント ID)/ ( FDT インスタンスの

Content-Location で指定)

という URL でアクセスする。

上記のURLを、外部デバイスのアプリケーションやブラウザに通知する方法については規定

しない。

（３）ファイルの消去

ファイル処理部で保存したファイルは、以下の 3 つのルールのうち、どれかひとつが発生した

タイミングで、該当するものを消去する。（T.B.D）

・PMTにより、放送の選局チャンネルが切り替わったことを検知したとき

→ すべてのファイルを消去する

・ファイル保存領域の空き容量が一定の割合を下回ったとき

→ 空き容量が一定の割合になるまで、古いファイルから順に消去する。

ファイル保存領域については、最低容量を規定する。

・放送局で指定した、すべてのファイルの最低保存時間（期間）を過ぎたとき

→ 一定の時間ごとにバッチ処理を行い、ファイルのタイムスタンプが一定時間以上

古いものは消す。バッチ処理のサイクルについては規定しない。


9 伝送プロトコル

9.1 プロトコルスタック

基本的には TR-B14 のプロトコルスタックをベースにし、IPDC としてマルチスクリーンサービス

の提供に必要なプロトコルを拡張する。データ放送を主とする従来のマルチメディアサービスはテ

レビ上でのモノスクリーン（単一表示画面）サービスと定義し、新たに IPDC を使用したマルチスク

リーンサービス（複数表示画面）を定義する。

１） IP パケットの伝送方式は「ARIB STD-B32 第 3部 2.2 TSパケットによる IP パケット伝送」

を採用する

２） PSI/SI は地上デジタル放送の運用規格を基本として以下の想定で拡張する。

①IPDC を使用したサービス拡張方法（番組連動も含む）の確立

②伝送する IPDC 用 ES（PID）の特定方法の確立

③受信すべき IP アドレスの特定と処理方法の確立

３） ULE、IP、FLUTEはマルチメディア放送方式（ARIB STD-B45 第 2部第 8 章データ伝

送方式）に基本的に準拠し、放送した IP パケットを（家庭内の）LAN 環境にルーティングして

利用することも想定する。

４）表示端末は今後も継続的な進化が予想される。最新の表示端末への追随、ネット上のサービ

スとの連動を行うために、伝送部より上位レイヤ（図の青色部分）は未定義とする。

図 9-1 プロトコルスタック

MPEG2-TS（TSパケット）

セクション PES

映

像

・

音

声

ｽﾄﾘーﾑ

ﾊ゚ｹｯﾄ

字幕

文字

ｽーﾊ゚ー

カルーセル

伝送方式拡

張

ﾓﾉﾒﾃ゙ｨｱ符号化

セクション

各種通信

プロトコル

双方向網

（固定,携帯網）

マルチメディア符号化

テレビ・音声サービスマルチスクリーンサービス

（IPDC型放送サービス）

FLUTE

ULE (ｶﾌﾟｾﾙ化)

マルチメディアサービス

PSI/SI

（番組インデックス）

（データ放送サービス）

IP/UDP

未定義部分拡張部分

インターネットコンテンツを流用可能な

ように、符号化方式はオープンとする

規格拡張部分地上デジタル放送運用規格


9.2 ＰＳＩ／ＳＩ規定

9.2.1 はじめに

PSI/SI は地上デジタル放送規格の根幹を形成している部分であり、この改編を検討するにあた

り、

・現在普及している受信機が影響を受ける可能性がある。

・対応受信機の普及を考えると、IPDCサービスの考え方が考慮されており、すでにサービスが運

用されている ISDB-Tmm 方式や、現在検討が行われている V-Low など他の規格とどう整合を

取るか。

・リスクやコストに見合ったサービスが構築できるか。

等、大きな課題がある。検討を進めていくにあたっては、複数の選択肢を視野に入れ、慎重に議

論を重ねる必要がある。

ここでは、それらの課題を意識しながら、本書第 7 章サービスイメージモデル、第 8 章システ

ムモデルで記載しているサービスを想定し、IPDC受信機でサービスをどう受信するかということ、

IP 受信部以降に存在するファイル処理部、外部デバイスがサービスへ到達できるようにすること、

を目的とした地上デジタル放送における伝送制御信号の拡張を検討する。

9.2.1 サービス伝送方式

IPDC サービスを放送波に重畳する際の伝送方式を、

・テレビサービス連動方式

・独立サービス方式

・完全独立方式

・テレビサービスにリンクした独立方式

・独立 PMT方式

・未参照方式（直接受信方式）

で分類し検討を進めるが、最初に方式によらず全般的に適用される項目を検討し、それ以降で、

それぞれの方式で IPDCサービスを運用する場合に適用される項目の特徴・問題点をまとめる。


9.2.2.1 全般的に適用される項目

最初に、地上デジタル放送に IPDC サービスを定義する際に必要となる項目について検討す

る。

A) 【Media_type】・【Service_type】

地上波の規格では、【media_type】という考え方が取り入れられており、新しい【service_type】

を検討する場合、テレビ型サービスか、データ型サービスという２つの【media_type】のどちらか

に割り当てる必要がある。

表 9-1 メディアタイプと service_typeの指定

(ARIB-TRB14 第 4編 9－2 表 9－1引用〉

【service_type】として新しく【IPDCサービス】を定義し、【media_type】の概念に割り当てることを

検討する。

（このメディアタイプは、受信機の番組情報の提示や選局における動作を強く意識したものである。

従って受信機は、メディア(テレビ／データ)別の処理を行う場合に上記メディアタイプを利用するこ

とが可能である。逆に新しい service_type を定義する場合には、メディアを意識した上でメディア

タイプに割り当てられなければならない。：ARIB TR-B14 第 4編 9-2）

【media_type】

地上波で運用されている 2つのタイプで、IPDC サービスを運用することを検討する。

・テレビ型

テレビ型として現在の連動データ放送が運用されている。連動 IPDC サービスで使用

する。


・データ型

独立型の IPDCデータサービスで使用する。

【service_type】

NIT におけるサービスリスト記述子のサービス定義として必須で、SI（EIT）の伝送を

【service_type】毎に異なる運用が可能となる。

デジタルテレビサービス、データサービス、臨時サービス、エンジニアリングサービス、ブックマー

ク一覧データサービスが現在定義されているが、新たに“IPDC データサービス”を定義する。値

は T.B.D。

B) 【service_id】

【media_type】をテレビ型としテレビ連動サービスとして運用する場合は、テレビサービスの

【Service_id】配下での運用となるが、【media_type】をデータ型として独立型のデータサービスと

して運用する場合、【Service_id】の割り当てに IPDCサービスを運用する場合の考慮を入れる必

要がある。

最初に、地上デジタル放送におけるサービス IDのビット規定を以下に示す。

表 9-2 地上デジタル放送におけるサービス ID体系

（参照 ARIB TRB-14 第 7編 9）

上記ビット規定に基づく広域放送局のサービス IDを以下に示す。


表 9-3 地上デジタル放送におけるサービス IDの割り当て

（参照 ARIB TR-B14 第 7編 9）

地上波での規定の中で、【media_type】をデータ型として IPDC サービスを運用する場合に使用

するサービス IDを以下に検討し、列挙する。

【サービス番号利用案】

IPDC サービスを「サービス番号」で識別する方法が考えられる。

・サービス番号の共用案

独立データサービス用のデータ型 1 とデータ型 2 と部分受信をデータ放送サービスまたは IPDC

サービスとして共用利用できれば各放送局のサービス ID は確保される。その場合、従来のデー

タ放送か IPDCかは上記【service_type】で認識する。

・サービス番号の割当案

データ放送 2を IPDCサービスに割り当てる。部分受信については 8サービスの割り振りを 4サ

ービス単位で分離し、後半 4個を IPDCサービスに割り当てる。

・サービス番号を従来通り使用する案

必ずデータ放送 ESを 1ES存在させ、従来のデータ放送の拡張として IPDC用 ESを付加する。

※ワンセグサービスの概念に近いが、送出機で 1ES 分のデータ放送(透明コンテンツなどの簡易


的なもの)を出力する必要がある。

【地域識別を使用する案】

現在、地上波では地域識別は 1～62 が運用されてる。0 と 63 は使用していないのでそれを利用

する。

※本来の地域を識別する意味としては適さないが地域またぐサービスなどの概念も可能。

【地域事業者識別を使用する案】

現在、0～8 が運用されているが、9～15は使用されていない。参考までに 0が NHK 総合、1が

NHK教育、2～6が民放、7が独立U 局、8が放送大学となっている。

※本来の地域事業者を識別する意味としては適さないが、事業者をまたぐサービスなどの概念も

可能。

C）【stream_type】

IPDC サービスを行う ES の分類。 ISDB-Tmm（ARIB TRB-33）で使用されている、

Unidirectional Lightweight Encapsulation(ULE:IETF RFC 4326) の”0x91”が望ましい

か。ULEプロトコルの利用方法を検討し、同等であれば同じ値とし、差異があれば0x92などの値

が必要。

D)【component_tag】

現在地上波で使用されていない〝0x90～9F″を検討。

複数の IPDC-ES を運用する場合を考慮して、タグ値 0x90 で送出される ES をデフォルト ES と

して定義し、タグ値としては 0x90～0x9F の範囲で運用することを検討する。

ファイル伝送用など、アプリケーションによって、ESの用途を使い分けることも可能とする。

E）【コンテンツ保護の観点】

コンテンツ保護の観点から少し話を進める。地上デジタル放送では、1 サービス同時処理最大

16ES(マルチビューを考慮して 1サービス当たりのESの最大送信数は 32)、スクランブル運用す

る最大が 12ES である。現状でも放送局は上限に近いスクランブル ES 数で運用しているが、

IPDCを独立したサービスで扱う場合と IPDCのESをテレビと同一サービスの中で扱う場合を主

に検討するが、IPDC の ES を含め、基本的に 12ES 以内であればスクランブルをかけて運用す

ることも問題ないと考えられる。それ以上の ESとなる場合、いずれかの ESはノンスクランブルで

運用する必要があり、IPDC の ES についてノンスクランブルでコンテンツ保護を意識する場合に

は、個別 DRM で対応するなど考慮する必要がある。また、別の観点となるが、配置する記述子

に記載する情報が多くなると、コンポーネント単位でかなりのデータ量になる。PMT が 1 セクショ

ン内におさまるよう、ES数を制限する必要がある。


アクセス制御・コンテンツ保護に関わる、限定受信方式記述子、アクセス制御記述子、コンテント

利用記述子、デジタルコピー制御記述子等の運用について、地上デジタル放送の運用に基づい

て記述子を配置する必要がある。IPDCのESに関して、受信機から出力する場合、DHCP-IPな

どによるコンテンツ保護の扱いを考慮せず、伝送される IP パケットとして出力できることが望まし

いと考えられる。IP 伝送路の暗号化や配信されるコンテンツの保護については、別章にて検討す

る。

F) 【全体として】

【media_type】は【service_id】の決定に作用していて、３桁番号の決定、各サービス事業者のリ

モコン番号の決定に作用する。IPDC サービス非対応の受信機は、各項目で非対応の判断をし、

処理をしないという動作が望ましいが、既存のテレビサービスを享受している視聴者に直接的な

影響を与える可能性がある部分であり、慎重に調査する必要がある。


9.2.2.2 テレビサービス連動型

テレビサービスの一環として IPDC をサービスするモデル。番組(event)に連動して IPDC ストリ

ームを多重。PMTから ESを関連付ける情報としての値を定義する。

【Service_type】：デジタルテレビサービス

【Media_type】：テレビ型

NIT(記載変更なし)

SDT(記載変更なし)

映像ES

音声ES

字幕ES

データ放送ES

IPDC-ES

PAT(記載変更なし)

PMT(テレビサービス)・ESループ追記

ＥＩＴ(内容追記)

図 9-2 テレビサービス連動型の PSI/SI モデル

現状使用されているテレビサービスの service_id での運用となり、テレビ番組に連動して送出

が可能である。サービスの中で IPDC サービスが行われているかどうかについて、PMT に

【stream_type】が IPDCの ESが存在することで認識する。

IPDC サービスをデータ型として、data_component_id に IPDC サービス用の新しい値を定義

する。データ符号化方式記述子の additional_data_component_info() は、

data_component_id 毎に規定されるためデータ放送とは異なる内容で定義する。この

additional_data_component_info()の中で当該ESに含まれる IPアドレスのマップを規定する。

(データ符号化記述子・IPアドレスの考え方について詳細は9.2.3に記載)このようなデータ符号化

方式記述子の運用は、現在でも字幕やデータ放送等で異なるdata_component_idが割り当てら

れ、異なる内容を定義し使用していることから、問題は少ないと推測される。また IPDC に対応し

ていない受信機は、【stream_type】で処理対象外として判断することが望ましい動作になる。


9.2.2.3 独立サービス型

ネットワーク内にサービスをマッピングし、各テーブルに記載が必要な値について定義する。

【Service_type】：IPDCサービス(新設)

【Media_type】：データ型（IPDC サービスをデータ型と定義）

PAT、NIT、SDT にサービス追記し、前記したが、Service_id は ARIB TRB-14 で規定され、各

局で割り当てられている範囲の値の使用を検討。(9.2.2.1参照)

IPDCサービスのPMTを送出し、EITの送出はオプションとする。サービスにより、必要であれば

送出が出来るようにしておく。必要でなければ送出しない。

A) 【完全独立サービス型】

現在地上波で運用されている独立データ放送と同様のサービス形式。

NIT・サービス追記

SDT・サービス追記

IPDC-ESPAT

・サービス追記PMT

ＥＩＴ(サービス追加)

図 9-3 独立サービス型の PSI/SI モデル

一体型受信機の場合、テレビサービスが選局されていれば、同じ電波で放送されている IPDCサ

ービスを、自動的に受信して IP処理を行わせるなど、仕組みが必要となる。

また【Service_type】は新設する IPDC サービスになるため、IPDC に対応していない受信機は、

この内容で処理対象外として判断することが望ましい動作になる。


B) 【テレビサービスにリンクした独立方式】

独立サービスとして存在するが、テレビサービスへのリンクを記述子の記載で確立する。記述子

(例えば、リンク記述子（PMT 等への配置可能）、サービスリンク記述子（NIT に配置可能）、ハ

イパーリンク記述子（EIT 等に配置可能)）あるいは、IPDC を伝送するデータ符号化記述子の内

容にリンクするテレビサービスを記載するなどで、テレビサービスにリンク・連動する。

映像ES音声ES字幕ES

データ放送ES

PMT(テレビサービス)

IPDC-ES

PAT・サービス追記

PMT(ＩＰＤＣサービス)

NIT・サービス追記・テレビサービスＩＰＤCサービスを

リンク

SDT・サービス追記？

ＥＩＴ(サービス追加？)

ＮＩＴ記載

ＰＭＴ記載

図 9-4 テレビサービスにリンクした独立方式の PSI/SI モデル

独立サービス(IPDC サービス)の PMT にリンクに関連した記述子を配置することにより、テレビ

一体型の場合はテレビを受信しながら IPDC サービスを受信することが可能となり、IPDC 専用

受信機の場合は、テレビとの連携(選局連携)を検討することが可能となる。

A）・B)両方式とも、NITへの記載や PMTへの記述子追記について、IPDC対応していない既存

受信機への影響が懸念される。

“TR-B14の 4編 8サービス・イベントの定義の記載：

「NIT 上でサービスが定義されないプログラムを伝送することは可能である。この場合、NIT で定

義されていないプログラムがPAT上にエントリーされていることになる。このプログラムに関しては

選局対象とはみなされない。」“

“TR-B15記載：

「NIT 上でサービスが定義されないプログラムを伝送することは可能である。この場合、NIT で

定義されていないプログラムが PAT 上にエントリーされていることになる。このプログラムに関し

ては選局対象とはみなされない。NIT 上でサービスが定義されないプログラムとは、例えばテス


ト放送や、選局したサービスからのリンクによってのみ選局されるサービス等であり、チャンネル

番号入力等で直接選局動作をさせないことを意味する。」“

など、現在の規格でプログラム選択処理に関する各テーブルの例外運用記載がある。これらの記

載の適用が可能であれば、テレビサービスに連動して自動起動するサービスとして、NIT・SDT

には定義せず、個別サービスとしては選局対象としないということも検討の対象としたい。この検

討が妥当であれば、EIT も送出の必要がなくなる。（テレビサービスのチャンネル選局と連動する

仕組みは別途考慮する必要がある。）

PMTについても影響は懸念される。PMTの内容について、【Service_type】は新設する IPDC

サービスで検討しているが、対応していない受信機は、この【Service_type】で処理対象外として

判断することが望ましい動作になる。


9.2.2.4 【独立 PMT 方式】

PAT、NIT、SDT、EIT などネットワーク内にサービスが存在することを意味づけるテーブル類

に関連した記載を行わない。ただし、サービスと ES を関連付ける PMT は配置する。PMT 内に

配置の必要な値について、定義を行う。ワンセグ放送と同様な概念(A 階層では PAT が無いため

固定の PMT_PID=0x1F80で運用)となり、IPDCサービス用の PMT_PIDを 8個程度規定し運

用することを想定する。

【Service_type】：IPDCサービス（新設）

【Media_type】：データ型（IPDC サービスをデータ型と定義）

IPDC-ESPMT

図 9-5 独立 PMT 方式の PSI/SI モデル

受信処理にMPEG-2の運用から外れた例外的な独自処理の取り決めが必要となる。

・IPDC受信機は、各局の選択が行われたときに、PMTのサーチを行い、IPDCサービスが送出

されていた場合、その ESのデコード処理を行う。

・携帯放送と同様に、PMT の PID 値を規定しておき、IPDC 受信機は決められた PID 値のデコ

ードを行う。

・既存受信機では PATに存在しない PMT_PIDの認識が明確に出来ない為、安全に無視される

と想定する。”

などの手法が考えられる。

PMT内 program_number値は 9.2.2.1で検討している service_idを使用することを検討する。


9.2.2.5 未参照方式(直接受信方式)

PAT、NIT、SDT、EIT などネットワーク内にサービスが存在することを意味づけるテーブル類

に関連した記載を行わない、かつサービスと ES を関連付ける PMT など関連テーブル配置しな

い。

【Service_type】：規定なし

【Media_type】：規定なし

IPDC-ES

図 9-6 未参照方式のモデル

受信処理にMPEG-2の運用から外れた例外的な独自処理の取り決めが必要となる。

受信機が選局された CH で IPDC サービスが行われていることをど認識する手法、受信機が

IPDC-ES PID値を認識する手法などを取り決める必要がある。

・予めシステム設定で PID値を IPDC 受信機に設定する。

・IPDC受信機では想定する PIDのみ受信処理を行う。

などの手法が考えられる。

また、コンポーネントに対応した IP アドレスなどの情報やその情報を取得する手順なども検討必

要がある。

9.2.2.6 運用想定

基本的に地上波テレビのサービスとして定義することを考え、独立サービス型でテレビサービスと

リンク付けが可能となる方式で検討する。1 サービスでスクランブル ES が 12、最大 16ES、また

PMT の記載が 1 セクションを超えてはいけないといった縛りや、独立サービスの場合 NIT・PAT

へ新サービスを記載することによる受信機への影響、テレビサービス内に配置すると NIT・PAT

への新サービスの記載は必要ないがテレビサービスと同一 PMT へ配置することになるためその

テレビサービスへ影響する可能性も考えられるなど、どの方式にも一長一短がある。既存受信機

への影響を考慮しながら段階的に検討する必要がある。


9.2.1 受信機からホームネットワーク等への展開に関する伝送制御方式

8 章で定義しているシステムモデルでは、外部デバイスでのコンテンツ受信は、IPDC 受信機の

IP受信部で受信処理を行い、

①ファイル処理部へ受け渡しを行い、外部デバイスからそのファイル処理部で蓄積されたコンテン

ツへアクセス

②IP 受信部からホームネットワーク等へ IP パケットのまま伝送コンテンツを配信するという方法

をイメージしている。この節では、デジタル放送波に存在する IPDC サービスと IP 受信部の外側

へ出力するパケットの IP アドレスの関連付けに関する伝送制御信号に関して検討する。

主に、セクションテーブルを用いた方式と PMTに配置するデータ符号化方式記述子を用いた方

式で検討を行うが、9.2.2.5 で記載した未参照方式では、IPDC サービスに関して、TS ネットワー

ク内に存在するサービスとしての service_id の規定が明確ではない、PMT を配置しないためデ

ータ符号化方式記述子を配置できないなど、ここで検討される方式の対象にはならない。未参照

方式で運用を考える場合には別途何らかの取り決めを検討する必要がある。

ARIB で規定されている、IP データキャストコンポーネントと IP アドレスとの関連付けを行う

PSI/SI テーブルには、ISDB-Tmm で規定されている INT と高度広帯域ＢＳ放送で検討された

AMT がある。項目 9.2.3.1、9.2.3.2 で記載するが、AMT は TLV パケットでの定義となっている

ため、考え方や内容は参照するが、深く検討はしていない。また INTに関しても検討は行ったが、

現状では地上波には存在しない考え方などを取り入れる必要があり、全体のシステムが複雑化

すると判断した。

フォーラム作業班では、受信機の簡略化などを考慮し、後述する 9.2.3.3 の、PMTES ループに

配置するデータ符号化方式記述子に記載する情報による関連付けを第一候補として検討してい

る。しかし、互換性の考慮、国際規格への整合性なども配慮の必要があると考え、この方式に限

定するということではない。

9.2.3.1 INT 方式

INT(IP/MAC通知テーブル)V-Highマルチメディア放送で運用されているテーブルで、DVBの

規格で規定されているものをベースに、V-High マルチメディア放送で運用されている。

IP/MAC 通知テーブル(INT)は、放送番組とそれを構成する IP/MAC ストリームを関連付ける

情報を提供するテーブルである。INT には IP アドレス、TS 識別、サービス識別等の情報が記

載され、関連付けられている。INT に記載された TS 識別、サービス識別の MPEG-2 TS を選

択することで、目的の IP アドレスのストリームを抽出することが可能となる。MPEG-2 Systems

のプライベートセクション(stream_type=0x05)で伝送される。


図 9-7 INT を用いたサービス選択の例 ( ARIB STD-B10 図引用)

作業班での検討は、

・INT の PIDの抽出に PAT からの流れで service_id（ program_number）を使用している。地

上デジタル放送では、service_idの運用は厳格に規定されており、INT用の service_idをどう規

定するか

・PAT、PMT、NIT を INT抽出に使用していることなど、既存受信機への影響が懸念される。

・データブロードキャスト識別記述子、【data_broadcast_id】の定義、IP プラットフォーム

【platform_id】の定義など、現在の地上デジタル放送に存在しない概念を定義する必要がある。

など、検討すべき項目が多く存在し、地上デジタル放送の規格拡張が複雑化すると考えた。ただ、

V-Highで運用している、国際規格がベースになっていることなど考慮すべき点も多い。


9.2.3.2 AMT方式

AMT（アドレスマップテーブル）は高度広帯域衛星放送の検討で、TLVパケットに載せる伝送制

御信号として規定されている。

サービス識別子と IP パケットとを関連付ける情報を伝送、IP パケットを、通信回線で伝送され

る IP パケットと可能な限り区別なく受信するため、IP パケットのマルチキャストグループの一覧

を提供する。

テーブルの構成はセクションとしてTSに載せることをベースで規定されているテーブルと同様の

構成をしている。以下に TSでテーブル多重した場合の考え方について示す。

IPDC-ESPMT ULE

AMT・service_id-IPadress 関連付け

図 9-8 AMT 方式の PSI/SI モデル

この方式を検討するには、TLV パケットで規定されている AMT テーブルを TS パケットで使用す

ることを規定する必要がある。


9.2.3.3 PMT・データ符号化方式記述子による方式

PMT の stream_type で IPDC サービスを判断し、ES 定義の記述子(PMT の第２ループ記述

子)にデータ放送 ES や字幕 ES などと同様にデータ符号化記述子を使用した方式を検討する。

IPDC 用の data_component_id を取得した上で新たにその id に対して

additional_data_component_info()を定義する。ここで IP アドレスマップを表現すると同時に、

運用から必要と考えられる記載項目も検討し、additional_data_component_info()を定義する。

A) 【運用方式の検討】

【この方式の意図】

・各種受信機、外部デバイスの処理（連携）の簡素化

・従来の地デジ運用からの変更点の軽減化

【運用方針】

・IPデータキャストを伝送する ESは、独立した IPDCサービスで伝送する。

・「IPDCサービス」のサービス識別（service_type）が新規に割り当てる。

・1TSに 1つ(あるいは 0)の IPDCサービスが配置された PMT が存在する。

・1PMT内に複数の IPデータキャストが存在できる。（１つの TSに含まれる IPデータキャストは

全て、IPDCサービスのコンポーネントとして伝送する。）

・IPデータキャストは ES単位とする。IPDC サービスは最大 10ES とする。

・PMT の 2nd ループ（ES ループ）に、IPDC に関するデータ符号化方式記述子を新規に配置す

る。

・IPDC ストリームのコンポーネントタグ値は、0x90-0x9F とする。

・IPDC ストリームの stream_typeは、カプセル化をULE で行うため、0x91 とする。

・IPDC ストリームの IP マルチキャストアドレスを識別するために、PMT データ符号化方式記述

子 additional_data_component_info()内に IP マルチキャストアドレスを記載する。

・1ES 内で最大２つの IP アドレスを使用できる。また、PMT データ符号化方式記述子

additional_data_component_info()内に、IP アドレス単位で”IPパケット出力フラグ”（外部出力

可・不可）、”スタートアップ情報伝送フラグ”、”ファイル蓄積可否フラグ”を指定可能とする。

・PMT データ符号化方式記述子 additional_data_component_info()内に、テレビ型サービスと

連動する IPDCストリームでは、連動するテレビ型サービスのサービスＩＤを記載する。NITへリン

ク記述子は配置しない。連動するサービスは複数指定できるようにする。

・ファイル処理部の蓄積プロトコルは FLUTE、ファイル処理部は、PMT データ符号化方式記述

子 additional_data_component_info()内で指定されるフラグで”ファイル蓄積可”と指定されてい

る IP アドレスに対して、IP 受信部に対して配信要求を行い、デフォルトポート番号(ポート番号は

T.B.D、MAX３)、TSI=0 固定で FLUTE 処理を行う。また記述子に FLUTE 配信で使用するポ


ート数を記載する。

・PMTデータ符号化方式記述子 additional_data_component_info()にある”スタートアップ情報

伝送フラグ”が”１”の場合、“スタートアップ情報”を専用ポート番号(T.B.D)で送出する。その内容

はサービス仕様とする。

・IPDC受信機にて Ch選択後、IP受信部はファイル処理部や外部デバイスに一定周期にて、初

期アクセス情報として IPDC サービスの PMT テーブル（セクション形式）をマルチキャスト配信す

る。そのマルチキャストアドレスには限定スコープアドレスを想定する。

・ファイル処理部や外部デバイスは配信を受ける PMT を解析し、サービス ID（放送局毎で違う）

で受信チャンネル（放送局）を判断する。

・受信機でチャンネル変更を行った際のファイル処理部や外部デバイスでのサービス変化の認識

は、マルチキャストで配信される PMT セクションの変更で判断する。

ファイル処理部や外部デバイスに搭載されるアプリケーションは必要に応じて、マルチキャストで

配信される PMT を常時監視対象とする。

・ファイル処理部や外部デバイスは配信を受ける PMT データ符号化方式記述子

additional_data_component_info()を解析し、サービス内で配信される IPアドレスを判断する。

・ファイル処理部や外部デバイスは PMT に記載された IP アドレスに対して JOIN 要求（ES・IP

アドレス単位）を行い、IPデータキャスト受信を開始する。

・IP受信部は受信機外部からの JOIN要求に対して、 ”IPパケット出力フラグ”が”外部出力不可

“に指定されている IPアドレスの配信は行わない。

・外部出力される IP アドレスの UDP ポート番号の管理はサービスを行うアプリケーションのレベ

ルでの管理とする。

【基本運用概念図】

独立サービス型での運用概念を記載する。

TS

TVサービス1データサービス

（携帯）IPDCサービス

IPDCコンポーネント1

（IPデータキャスト1：マル研型データキャスト）

…

IPDCコンポーネント2

（IPデータキャスト2：A配信型データキャスト）

…

ポート番号3…

ポート番号2（IP）

ポート番号1（スタートアップ情報）

IPアドレス1（P直接出力用途のイメージ）

ポート番号3…

ポート番号2（FLUTE2）


IPアドレス2（蓄積用途のイメージ）

ポート番号3ポート番号2ポート番号1（スタートアップ情報）

IPアドレス1

ポート番号3…



IPアドレス2

図 9-9 TS運用概念図


【運用】

【PSI/SI 運用例】

表 9-4 PSI/SI 運用例

NIT ┣ network_id = 0xXXXX ┣ network_descriptor_info ┃ ┗ … （リンク記述子は配置しない） ┗ transport_stream_loop ┗ …

PAT ┣ ts_id = 0xXXXX ┗ loop ┣ …

PMT(テレビサービス) ┣ program_number = 0xAAAA ┣ program_info ┃ … ┗ ES_loop ┣ stream_type = 0x02(MPEG2-VIDEO) ┃ ┗ ES_info ┃ … ┣ stream_type = 0x0F(AAC) ┃ ┗ ES_info ┃ … ┣ stream_type = 0x06(字幕・文字スーパー) ┃ ┗ ES_info ┃ … ┣ stream_type = 0x0D(ISO/IEC13818-6 TYPE_D) ┃ ┗ ES_info ┃ … ┣ stream_type = 0x0D(ISO/IEC13818-6 TYPE_D) ┃ ┗ ES_info …

PMT(IPDC) ┣ program_number = 0xBBB0 ┣ program_info ┃ … ┗ ES_loop ┣ stream_type = 0x91(ULE) ┃ ┗ ES_info ←IPDC-0 ┃ ┣ stream_identifier_descriptor（ストリーム識別記述子） ┃ ┃ (component_tag=0x90←仮定) ┃ ┗ data_component_descriptor（データ符号化方式記述子） ┃ (data_componet_id=0x****) ┃ (IPv4_addr=239.255.***.0 ←例) ┣ stream_type = 0x91(ULE) ┃ ┗ ES_info ←IPDC-1


┃ ┣ stream_identifier_descriptor（ストリーム識別記述子） ┃ ┃ (component_tag=0x91←仮定) ┃ ┗ data_component_descriptor（データ符号化方式記述子） ┃ (data_componet_id=0x****) ┃ (IPv4_addr=239.255.***.1 ←例) ┣ stream_type = 0x91(ULE) ┃ ┗ ES_info ←IPDC-2 ┃ ┣ stream_identifier_descriptor（ストリーム識別記述子） ┃ ┃ (component_tag=0x92←仮定) ┃ ┗ data_component_descriptor（データ符号化方式記述子） ┃ (data_componet_id=0x****) ┃ (IPv4_addr=239.255.***.2 ←例) ┣ … ┃

SDT ┗ loop ┃ … ┣ service_id = 0xBBBB ┗ desc_loop ┗ service_descriptor（サービス記述子） (service_type=0x**, name≒IPDC)

【データ符号化方式記述子の additional_data_component_info のデータ構造】

表 9-5 データ符号化記述子

データ構造ビット数ビット列表記

data_component_descriptor()

{

descriptor_tag

descriptor_length

data_compoent_id

for (i=0; i<N; i++) {

additional_data_component_info

}

}

8

8

16

8

uimsbf

uimsbf

uimsbf

uimsbf

data_component_id=***** (****は新規割り当てを受けた値)


表 9-6 additional_arib_IPDC_info

additional_data_component_infoの案 (additional_arib_IPDC_info)

データ構造ビット数ビット列表記

transmission_format 2 bslbf

entry_point_flag 1 bslbf

reserved_future_flag 5 bslbf

if(entry_point_flag== 1){

auto_start_flag 1 bslbf

independent_flag 1 bslbf

style_for_tv_flag 1 bslbf

reserved_future_use 5 bslbf

} else {


}

ip_version 2 bslbf


if(ip_version == '00'){

IPv4_addr1 32 uimsbf


IPv4_addr1_mask 32 uimsbf


IPv4_addr1_control_data_flag 1 bslbf

IPv4_addr1_packet_forwarding_flag 1 bslbf

IPv4_addr1_file_storable_flag 1 bslbf

IPv4_addr1_num_of_port 2 bslbf











}else if(ip_version == '01')















}

num_of_linked_service_id 8 uimsbf

for(i=0; i<num_of_service_id ; i++)｛ uimsbf

service_id 16 uimsbf

}

if(transmission_format == '10'){

ondemand_retrieval_flag 1 bslbf

bxml_start_priority 1 bslbf


}else{


}


transmission_format(伝送フォーマット):（既存）

この２ビットの領域は当該コンテンツで伝送される IPDC 方式の伝送方式を指定する。

表 9-7 transmission_format

値意味

10 IPDC 伝送方式

00-01, 11 将来の拡張のための予約

entry_point_flag(エントリーポイントフラグ)：（既存）

１つの主となるテレビ型サービスが複数の IPDCストリームと連動している場合、コンポーネントス

トリームが最初に取得すべき IPDC コンテンツを伝送しているか否かを示す。

表 9-8 entry_point_flag

値意味

0 最初に処理すべき IPDC コンテンツを伝送しない。

1 最初の処理すべき IPDC コンテンツを伝送する。

auto_start_flag（自動スタートフラグ）：（既存）

IPDC受信処理を直ちに行うかを示す。受信した IPDCコンテンツを表示するためアプリケーシ

ョンの自動起動は規定しない。

表 9-9 auto_start_flag

値意味

0 IPDC の受信を直ちに行わない。

1 IPDC 受信を直ちに行う。

independent_flag（単独視聴可否フラグ）：（既存）

IPDC で伝送するコンテンツのみで視聴することを前提とするかを示す。

表 9-10 independent_flag

値意味

0 単独視聴不可

1 単独視聴可能

style_for_tv_flag（TV 向けスタイルフラグ）：（既存）


IPDC で伝送するコンテンツがスタイルとして tvの指定を有するか否かを示す。

表 9-11 style_for_tv_flag

値意味

0 スタイルとして tv は有せず、テレビ受信機では表示できないコンテンツ

を含む

1 スタイルとして tvを有し、全てのコンテンツがテレビ受信機に実装された

アプリケーションにてレイアウトできる。

ip_version（IP バージョン）：（新規）

IPパケットのバージョンを指定する。

表 9-12 ip_version

値意味

00 IpV4

01 IpV6

10,11 将来拡張用

IPv4_addr1(宛先 IpV4アドレス１)：（新規）

この 32 ビットのフィールドは、ユニキャスト／マルチキャスト／ブロードキャストの１つ目の IPv4

アドレスを記述する。

IPv4_addr1_mask（宛先 IPv4 アドレス１マスク）：（新規）

この 32 ビットのフィールドは、IPv4_addr1の IPv4 のマスクを表す。

IPv4_addr1_control_data_flag(スタートアップ情報伝送)：（新規）

当該ＥＳで伝送されるコンテンツの受信において、IPv4_addr1 で最初に取得すべきスタートアッ

プ情報伝送をしているか否かを示す。

スタートアップ情報の内容については、T.B.D.

表 9-14 IPv4_addr1_control_data_flag

値意味

0 スタートアップ情報を伝送しない。

1 IPv4_addr1を宛先とする IPパケットでスタートアップ情報を伝送する。

IPv4_addr1_packet_forwarding_flag（IPパケット出力）：（新規）


当該 ES で伝送されるコンテンツの受信において、IPv4_addr1 の IP パケットの出力の可否を示

す。

表 9-15 IPv4_addr1_packet_forwarding_flag

値意味

0 ＩＰパケットの外部出力不可

1 IPv4_addr1 を宛先とするＩＰパケットの外部出力可

IPv4_addr1_file_storable_flag（ファイル蓄積可否指定）：（既存(file_storabel_flag)の拡張）

当該ＥＳで伝送されるコンテンツの受信において、IPv4_addr1 のＩＰパケットをパケットデータで指

定されているプロトコルに従って、ファイル蓄積可能か否かを示す。(#は IPのバージョンを示す。)

表 9-16 IPv4_addr1_file_storable_flag

値意味

0 IPDC 受信機におけるファイル蓄積不可

1 IPv4_addr1 を宛先とする IP パケットで送信されているデータの IPDC

受信機におけるファイル蓄積可

IPv4_addr1_num_of_port（デフォルトポート利用数）：（新規）

IPv4_addr1_file_storable_flag に１が指定されている場合、デフォルトの UDP ヘッダーの宛

先ポート番号からの利用ポート数(最大３)を記述する。デフォルトの開始ポート番号は、運用にて

規定する。

IPv4_addr2(宛先 IpV4アドレス２)：（新規）

この 32 ビットのフィールドは、ユニキャスト／マルチキャスト／ブロードキャストの２つ目の IPv4


IPv4_addr2_mask（宛先 IPv4 アドレス２マスク）：（新規）

この 32 ビットのフィールドは、IPv4_addr2の IPv4 のマスクを表す。

IPv4_addr2_control_data_ flag(スタートアップ情報伝送)：（新規）


プ情報を伝送をしているか否かを示す。

スタートアップ情報の内容については、T.B.D

表 9-17 IPv4_addr2_control_data_ flag


値意味




当該 ES で伝送されるコンテンツの受信において、IPv4_addr2 のＩＰパケットの出力の可否を示

す。


値意味





定されているプロトコルに従って、ファイル蓄積可能か否かを示す。(#はＩＰのバージョンを示す。)


値意味







規定する。

IPv6_addr1(宛先 IpV6アドレス)：（新規）

この 128 ビットのフィールドは、ユニキャスト／マルチキャスト／ブロードキャストの１つ目の IPv6


IPv6_addr1_mask（宛先 IPv6 アドレスマスク）：（新規）

この 128ビットのフィールドは、IPv6_addr1の IPv6 のマスクを表す。


IPv6_addr1_control_data_ flag(スタートアップ情報伝送)：（新規）




表 9-20 IPv6_addr1_control_data_ flag

値意味





す。


値意味







値意味







規定する。

IPv6_addr2(宛先 IpV6アドレス)：（新規）

この 128 ビットのフィールドは、ユニキャスト／マルチキャスト／ブロードキャストの２つ目の IPv6



IPv6_addr2_mask（宛先 IPv6 アドレスマスク）：（新規）

この 128ビットのフィールドは、IPv6_addr2の IPv6 のマスクを表す。

IPv6_addr2_control_data_flag(スタートアップ情報伝送)：（新規）




表 9-24 IPv6_addr2_control_data_flag

値意味





す。


値意味







値意味




IPv6_addr2_num_of_port（デフォルトポート利用数）（新規）



先ポート番号からの利用ポート数(最大 3)を記述する。デフォルトの開始ポート番号は、運用にて

規定する。

num_of_linked_service_id（IPDC 連携サービス数）：（新規）

当該 IPDC_ES と連携するサービスの数を指定する。

entry_point_flagが１と指定されている場合、サービス数は１とする。

連動する主となるテレビ型サービスと同じサービスで伝送する場合は、0 とする。

service_id(サービス識別)：（新規）

IPDS コンテンツと連携するサービスのサービス識別を指定する。

ondemand_retrieval_flag（オンデマンド受信視聴可否フラグ）：（既存）

当該ESで伝送されるコンテンツの受信において視聴者からの操作に従って、都度コンテンツを保

存することを前提とするか否かを示す。

表 9-27 ondemand_retrieval_flag

値意味

0 オンデマンド受信視聴不可

1 オンデマンド受信視聴可

bxml_start_priority（起動優先度フラグ）：（IPTV-F 既存）

BML/B-XML コンテンツによるデータ放送と外部デバイスのアプリケーションの起動優先度を示

す。

表 9-28 bxml_start_priority

値意味

0 優先度は指定しない。

1 無条件にデータ放送を優先する。


【additional_arib_IPDC_info (仮)の送出運用（案）】

表 9-29 additional_arib_IPDC_info (仮)の送出運用（案）

データ構造運用

transmission_format 10：固定

entry_point_flag 規定通り、運用する

reserved_future_flag

if(entry_point_flag== 1){

auto_start_flag １：固定

independent_flag 規定通り、運用する

style_for_tv_flag 0:固定

reserved_future_use

} else {

reserved_future_use

ip_version 規定通り、運用する

reserved_future_use

if(ip_version == '00'){

IPv4_addr1 規定通り、運用する

reserved_future_use

IPv4_addr1_mask 規定通り、運用する

reserved_future_use

IPv4_addr1_control_data_flag 規定通り、運用する

IPv4_addr1_packet_forwarding_flag 規定通り、運用する

IPv4_addr1_file_storable_flag 規定通り、運用する

IPv4_addr1_num_of_port 規定通り、運用する

reserved_future_use

IPv4_addr2 運用しない

reserved_future_use

IPv4_addr2_mask 運用しない

reserved_future_use

IPv4_addr2_control_data_flag 0：固定




reserved_future_use

}else if(ip_version == '01')



IPv6_addr1_control_data_flag 規定通り、運用する




reserved_future_use



IPv6_addr2_control_data_flag 0：固定




reserved_future_use

}

num_of_linked_service_id 規定通り、運用する

for(i=0; i<num_of_service_id ; i++)｛

service_id 規定通り、運用する

}

if(transmission_format == '10'){

ondemand_retrieval_flag １：固定

bxml_start_priority ０：固定

reserved_future_use

}else{

reserved_future_use

}


・1つの TSに含まれる IPDC ストリームは全て、IPDC サービスの ES コンポーネントとして伝送

する。1つの TSに IPDCサービスは１つ（もしくはゼロ）だけ含まれる。

・1 つの IPDC サービスで運用可能な ES 数は、10 までとする。リンクするサービス数によって、

セクション長は可変であるが、PMTは１セクションでの送付する必要があるため、1024バイトを

超えない範囲での配置とする。

・IPDCサービスの 1つの ES_PIDは、２つの宛先 IP アドレスを指定することが可能である。

・IPv4_addr1_control_data_flag、 IPv4_addr2_control_data_flag、

IPv6_addr1_control_data_flag、 IPv6_addr2_control_data_flagの運用について

上記値が、1となっている IPアドレスでは、“スタートアップ情報”を専用ポート番号(T.B.D)で送

出する。その内容はサービス仕様とする。

entry_point_flagが１に設定されている場合には以下のように運用する。

－IPv4_addr1, IPv4_addr2 の両方を運用する場合は、IPv4_addr1_control_data_

flagのみに１を指定する運用とする。

－同様に、 IPv6_addr1, IPv6_addr2 の両方を運用する場合は、

IPv6_addr1_control_data_

flagのみに１を指定する運用とする。

entry_point_flagが 0の設定の場合は、すべての値は 0固定とする。

・IPv4_addr1_packet_forwarding_flag、IPv4_addr2_packet_forwarding_flag 、

IPv6_addr1_packet_forwarding_flag、IPv6_addr2_packet_forwarding_flagの

運用について

-IP パケットの外部出力を行う場合、暗号化することが望ましいが、暗号化する場合の方

式については、IPDC受信機の外部デバイスで動作するアプリケーションに依存する。

-出力された IPパケットの IPDC受信機の外部デバイスでの処理は規定せず、外部デバイ

ス側で動作するアプリケーションに依存する。

・IPv4_addr1_file_storable_flag、IPv4_addr1_file_storable_flag、

IPv6_addr1_file_storable_flag、IPv6_addr1_file_storable_flag の運用について

- ファイル保存可と指定されている場合、チャンネルを切り替えた際に、IPDC 受信機内で保

存されているファイルは削除。

- IP パケットの外部出力が許可されている場合、IPDC 受信機の外部デバイスでのファイル


蓄積については、IPDC 受信機の外部デバイスで動作するアプリケーションに依存する。

・IPv*_addr#_packet_forwarding_flag、IPv*_addr#_file_storable_flag の組み合わせの運

用は表１の通りとする。(#は 1もしくは 2で、同じ番号が入る。*は 4もしくは 6で、同じ番号が入る)

表 9-30 IPv*_addr#_packet_forwarding_flag、IPv*_addr#_file_storable_flag の運用

IPv*_addr#_packe

t_ forwarding_flag

IPv*_addr#_file_

storable_flag

運用説明

１

0

0

×

IPDC 受信機内でのファイル保存は行わない。セカンドデ

バイス等の IPDC受信機外へのＩＰ出力は行わない。

運用しない。

２

0

1

○ IPDC 受信機内で、IPv4_addr#もしくは、IPv6_addr#の

IP パケットを FLUTE処理して、ファイルを保存する。

セカンドデバイス等の IPDC 受信機外へのＩＰ出力は行わ

ない。

３

1

0

○

IPDC受信機内でファイルの保存は行わない。セカンドデ

バイス等の IPDC受信機外へ IPv4_addr#もしくは、

IPv6_addr#のＩＰ出力を許可する。セカンドデバイスでのＩ

Ｐパケットの処理については規定しない。ファイル保存につ

いても規定しない。

４

1

1

○

IPDC受信機内で、IPv4_addr#もしくは IPv6_addr#の

IP パケットを FLUTE処理して、ファイルを保存する。セカ

ンドデバイス等の IPDC受信機外へIPv4_addr#もしくは、

IPv6_addr#の IP出力を許可する。セカンドデバイスでの

IP パケットの処理については規定しない。ファイル保存に

ついても規定しない。

・IPv4_addr1_num_of_port、IPv4_addr2_num_of_port、IPv6_addr1_num_of_port、

IPv6_addr2_num_of_portの運用について

IPv*_addr#_file_storable_flag（ファイル蓄積可否指定）が 1 に指定されている場合、デフォ

ルトの UDP ヘッダーの宛先ポート番号からの利用ポート数(最大 3)を記述する。ポート番号は、

デフォルトポート番号（T.B.D）から、IPv*_addr#_num_of_portで指定されている数までのポート

番号までを指定可能とする。

IPv*_addr#_num_of_portが 0で、ファイル蓄積可と指定されている場合は、IPDC受信機の初

期設定もしくは、スタートアップ情報として別途指示されることを想定している。スタートアップ情報


として別途指定する場合は、IPv*_addr#_control_data_flag には 1 を記述する。(#は 1 もしくは

2、*は 4 もしくは 6が入り、同じ番号が入る。)

【IPDC ストリームを伝送するサービスにおけるＰＭＴの記述子の運用】

連動する主となるテレビ型サービスと同じサービスで IPDC コンテンツは伝送しないため、記述子

の運用は、テレビ型サービスの運用とは異なる運用とすることも可能。

・ PMT の 1stループに記載可能な記述子

表 9-31 PMTの 1stループに記載可能な記述子

1stループに配置用途配置数配置 IPDCにおける運用

限定受信方式

記述子

サービス全体が限定受信対象の場合、CA システ

ム（限定受信方式）の ECM伝送ストリーム

の PID を指定する。

当面 1 任意運用通りとする

アクセス制御

記述子



の PID とその伝送経路を指定する。

コンテンツ保護を

伴う無料番組の場

合、1つ配置

任意運用通りとする

デジタルコピー制御

記述子

当該サービス全体に対して、デジタルコピー及びア

ナログコピーに関する制御情報を示す場

合か、あるいは最大伝送レートを記述する場合に

配置する。

NIT のサービスリスト記述子中に記載される

service_typによって値が規定されている。

デフォルトと異なる

場合に PMT に配

置する。

任意配置しない

緊急情報

記述子

当該サービスが緊急警報放送または、緊急警報信

号テスト中であることを示す。

任意配置しない。

コンテント利用

記述子

当該番組に対して、蓄積や出力に関する制御情報

を記述する場合に配置する。また、当該番組また

はコンポーネントに対して、「個数制限コピー可」を

運用するかどうかの指定を行う場合に配置する。

任意配置しない。


・ PMT の 2ndループに記載可能な記述子（データ符号化方式記述子を除く）

表 9-32 PMTの 2nd ループに記載可能な記述子

2nd ループに配置用途配置数配置 IPDC における運

用

限定受信方式

記述子



の PID を指定する。

1st ループと異な

るときに配置（１

つ）

任意運用通りとする。

アクセス制御

記述子



の PID とその伝送経路を指定する。

1st ループと異な

るときに配置

（１つ）

任意運用通りとする。

ストリーム識別記述子当該 ESにラベルをつけるために使用される。１つ必須運用通りとする。

stream_type は、カプ

セル化を ULE で行う

ため、0x91 とする。

デジタルコピー制御

記述子

当該サービス全体に対して、デジタルコピー及びア

ナログコピーに関する制御情報を示す場

合か、あるいは最大伝送レートを記述する場合に

配置する。サービス全体に指定されているのと異

なるデジタルコピー制御、及びア

ナログコピー制御を指定する場合に、必ず配置す

る。と異なるコピー制御を指定できるコンポーネント

は、component tag

の値が 0x40～0x7F を取るコンポーネントのみと

する。

１つ任意配置しない

ビデオデコードコントロー

ル記述子

同一 service_id 内での映像符号化方式の変わり

目においてビデオデコードをコントロールす

る場合に使用する。また、当該ESがMPEG-Iフレ

ーム静止画であるかどうかを示す。

１つ任意配置しない。


9.2.1 スタートアップ情報

デフォルトで規定された内容とは違うサービスを行う場合、IP データキャストの受信を開始する

ための情報を外部デバイスへ受け渡すために、 PMT データ符号化方式記述子

additional_data_component_info()にある”スタートアップ情報フラグ”に”１”を指定し、規定され

た専用のポート番号で“スタートアップ情報”を送出する。（内容は T.B.D）


9.3 ULE規定

IP パケットをカプセル化するためのプロトコルとして ULE を採用する。ULE は IP パケットを伝

送するプロトコルであり、世界標準規格としてRFC4326に制定された。DVB-IPDCで採用された

このプロトコルを既に ARIB 標準規格でも採用しており、本指針書においてもこれに準拠する。

１） ARIB STD-B32 「デジタル放送における映像符号化、音声符号化及び多重化方式」

第 3部「2.2 TSパケットによる IPパケット伝送」を採用する

２） ARIB STD-B45 「デジタル放送におけるダウンロード方式」第 2部「8.5 ULE パケット」

に準拠する。

３） IPv4、IPv6共に伝送可能とする。

４） NPA Addressは当面運用しないが、必要に応じて運用規定として検討する。

< ----------------------------- SNDU ----------------------------- >

+-+-------------------------------------------------------+--------+

|D| Length | Type | Dest Address* | PDU | CRC-32 |

+-+-------------------------------------------------------+--------+

※SNDU：SubNetwork Data Unit

※PDU：Protocol Data Unit

図 9-10 RFC4326における ULE 構造（全体)


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0| Length (15b) | Type = 0x0800 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Receiver Destination NPA Address (6B) |

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +

| |

= IPv4 datagram =

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| (CRC-32) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

図 9-11 RFC4326における ULE 構造（IPv4,D=0)

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1| Length (15b) | Type = 0x0800 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

= IPv4 datagram =

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| (CRC-32) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0| Length (15b) | Type = 0x86DD |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Receiver Destination NPA Address (6B) |

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +

| |

= IPv6 datagram =

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| (CRC-32) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1| Length (15b) | Type = 0x86DD |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

= IPv6 datagram =

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| (CRC-32) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



9.4 IP／UDP規定

この節では、IPDC サービスでのデータ転送に関し、ULE 後に利用する IP/UDP プロトコルの規

定、および、想定している IPDC受信機、セカンドデバイス間のデータ送受について述べる。

IP アドレスおよびポート番号をアプリケーションに割り当てることにより、様々なサービスを提供す

る。詳細は T.B.D。

9.4.1 利用する IP／UDP

IPプロトコル

RFC791（IPv4）あるいは RFC2460（IPv6）に規定する IP を使用する。

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|バーション|データ長| サービスタイプ | 全データ長 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 識別子 |フラグ| フラグメントオフセット |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Time to Live | プロトコル | ヘッダチェックサム |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 送出元 IPアドレス |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 宛先 IPアドレス |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

図 9-14 IPv4 ヘッダ構成


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|バージョン|トラフィッククラス | フローラベル |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ペイロード長 | 次ヘッダ | Hop Limit |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

+ +

| |

+ 送信元 IPアドレス +

| |

+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

+ +

| |

+ 宛先 IPアドレス +

| |

+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

図 9-15 IPv6 ヘッダ構成


UDPプロトコル

RFC768に規定するUDP を使用する。

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 送信元ポート番号 | 宛先ポート番号 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| データ長 | チェックサム |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| UDPデータ |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

・・・

図 9-16 UDP ヘッダ構成


10 アクセス制御とコンテンツ保護

本章では、IPDC方式を用いた伝送におけるアクセス制御技術とコンテンツ保護に関しての考え

方の方針を記載する。

IPDC 方式では、コンテンツ（静止画・動画・音声等）が、ULE 処理を通過することで、TS パケッ

ト化されて、デジタル放送波の一部として多重され送信される。また、受信に際し、IPDC 方式対

応のチューナー内部で、放送波内の TSストリームから、IP パケットに変換される。

そのため、アクセス制御技術とコンテンツ保護に関しても、IP パケットと TS パケットでそれぞれ

説明することとする。

　IPDC設備

映像音声

データ放送多重変調部

IPDCサーバIP-TS変換器

PSI/SI

放送IPDC対応受信機

図 10-1 IPDCの送受信概略図

10.1 IPパケット

IPDC 方式において配信されるコンテンツ（静止画・動画・音声等）のアクセス制御は、配信事

業者やコンテンツの種類によってそのポリシーが異なるため、商品企画とする。

配信事業者がコンテンツに対して何らかのアクセス制御を掛けたい場合は、IPDC サーバに格

納する手前で、各放送事業が暗号化した上で IPDC サーバに格納し、受信側で TS ストリームか

ら IP パケットに変換された後、暗号化されている IPパケットを復号化する運用を想定している。

また、アクセス制御に利用する暗号化技術は、静止画・動画・音声等の各メディアにおいて、既

存の技術が数多く存在するため、それらを活用することを想定している。

10.2 TSパケット

TS レイヤーでのアクセス制御技術は、既存送出設備への影響を鑑みデジタル放送のそれに準

ずるものとする。そのため、送出側と受信側の双方で以下の規定を満たすものとする。なお、ここ

で参照する規格は主に、コンテンツ保護を伴う無料番組の放送を行う場合の地上デジタルテレビ

ジョン放送運用規定（以下、TR-B14 とする）を参照しているが、有料番組を行う場合や、BS/高帯

域 CSデジタル放送で運用する場合は、適宜、参照先を読み替えること。

また、本章で規定するのは、IPDC方式の TSだけで、他の TSについては、規定しない。


10.2.1 送出側

アクセス制御とコンテンツ保護はデジタル放送のそれに準ずるため、IPDC 方式の TS は他の

TS と同様の扱いとする。詳細は、「TR-B14 第七編 5 多重化」、「同 8 運用」、「TR-B14 第八

編第一部 4 送出運用規定」を参照のこと。

ただし、送出システムの都合により、スクランブルを実施できない場合は、該当 TS をノンスクラ

ンブルで送出することも可能とする。

また、スクランブル化されている可能性のある ES の最大数については、限定受信方式の条件

から 12 となる事に留意すること。

10.2.1 受信側

送信側が従来のアクセス制御技術を利用するため、受信機内での処理も従来の処理と同様の

ものとする。つまり、受信機内には従来の放送 TS を復元するための機能と IPDC 方式の TS を

IPに変換する機能を実装する必要がある。

10.2.1.1 限定受信サービス

限定受信サービスの対応については「TR-B14 第五編第一部 5 受信機への要求仕様」および

「TR-B14第五編第二部 5 受信機への要求仕様」を参照のこと。

10.2.1.2 コンテンツ保護機能

コンテンツ保護機能への対応については、「TR-B14第八編第 1部 5 受信機に対する機能要

件」および「TR-B14第八編第 2部 5 1セグメント受信機に対する機能要件」を参照のこと。

10.2.1.3 コピー制御

受信機内部でTSストリームから IPパケットへ変換（復元）する際に、コピー制御は施さない事。

つまり、元の IPパケットが出力されること。


11 想定するアプリケーションとコンテンツ

本指針書では、アプリケーションとコンテンツについては規定しないが、参考のため想定例を記載

する。

11.1 想定するアプリケーションとコンテンツ

11.1.1 想定するアプリケーション要件

外部デバイス上で動作するアプリケーションは、以下の５つの要件を満たすものと想定する。

（１）放送による IPDCサービスでデータキャストするコンテンツの

表示再生を主として行う。

（２）表示再生するコンテンツは、ファイルとパケットストリームの両方を取り扱うことができ、それ

らのコンテンツフォーマットは、インターネットで汎用的に用いられているものを改変せずにその

まま利用できる。

（３）番組に連動してコンテンツの表示再生を行う連動データキャストと、番組に連動しない独

立データキャストの両方に対応する。

（４）アプリケーションの表示再生を、放送による IPDC サービスでデータキャストとして配信する

なんらかの表示制御用コマンドによって制御できる。

（５）データキャストで配信するコンテンツや、インターネット通信で取得するコンテンツなど、複数

のコンテンツ間の関連性や階層構造を記述し、それを放送による IPDCサービスでデータキャス

トとして配信し、それにもとづく表示再生を行うことで、複数のコンテンツを組み合わせた表示再

生や、番組と連動した表示再生ができる。


11.1.2 アプリケーションのアーキテクチャ

前項で記載した想定されるアプリケーション要件を満たし、また、10章までに記載した IPDC

受信機と外部デバイスとの連携仕様を満たすために、外部デバイスのアプリケーションは以下の

ようなアーキテクチャで動作することを想定する。

図 11-1 アプリケーションのアーキテクチャ想定図

上図のアーキテクチャにおいて、以下の 3つの用語を定義する。

・「制御コマンド」

コンテンツの表示再生などアプリケーションの動作を制御するためのコマンド(文字列)で、デー

タキャストにより UDPパケットとして配信される。

・「WebSocketプロキシ機能」

UDPパケットとして届いた制御コマンドを受信し、そのコマンドボディ(文字列)をWebSocketプ

ロトコルでWEB ブラウザ機能に通知する機能。これにより、WEB ブラウザ機能の内部で動作す

る JavaScript等の動作を、放送により制御可能とする。

・「コンテンツ構造情報」

データキャストで配信するコンテンツや、インターネット通信で取得するコンテンツなど、複数のコ

ンテンツ間の関連性や階層構造を記述したテキストファイル。


11.2 想定するアプリケーション

この節では、前節に記載した外部デバイスで動作するアプリケーションのアーキテクチャを前提

に、アプリケーションの機能構成と各機能の概要、および動作シーケンスを記載する。

11.2.1 機能構成と各機能の概要

（１）データキャスト選択機能

IP 入出力部に対して PMT 情報およびスタートアップ情報の取得要求を行い、要求への応答

として IP 入出力部から PMT情報およびスタートアップ情報を受信し、それらに記載されたデ

ータキャストのリストから、アプリケーションが利用するデータキャストを選択する。

選択したデータキャストのマルチキャストアドレスおよびポート番号を、アプリケーション内の

データキャストを受信する各機能(制御コマンド受信機能、および、ストリーム再生機能)に通

知する。

（２）制御コマンド受信機能

IP 入出力部に対して制御コマンドが配信されているデータキャストの取得要求を行い、要求

への応答として IP 入出力部から制御コマンドを受信し、制御コマンドをコンテンツ構造情報処

理/制御機能および WebSocketプロキシ機能に通知する。

制御コマンドを配信するデータキャストの取得要求の際に必要となるマルチキャストアドレス

およびポート番号は、データキャスト選択機能から通知される。

（３）ストリーム再生機能

IP 入出力部に対してストリームコンテンツが配信されているデータキャストの取得要求を行い、

要求への応答として IP入出力部からストリームコンテンツを受信して再生する。

ストリームコンテンツが配信されているデータキャストの取得要求の際に必要となるマルチキ

ャストアドレスおよびポート番号は、データキャスト選択機能から通知される。

（４）コンテンツ構造情報処理/制御機能

HTTP プロキシ機能およびファイルキャッシュからコンテンツ構造情報ファイルを読み出し、ま

た、制御コマンド受信機能から制御コマンドを受信し、それらに基づいて、ファイル表示再生機

能やWEBブラウザ機能やストリーム表示再生機能を制御する。

（５） WebSocketプロキシ機能

制御コマンド受信機能から制御コマンドを UDP パケットとして受信し、そのコマンドボディ（テ

キスト）をWebSocketプロトコルでWEBブラウザ機能に通知する。


（６）ファイル表示再生機能

コンテンツ構造情報処理/制御機能の制御に基づき、HTTP プロキシ機能およびファイルキャ

ッシュからコンテンツファイルを読み出して再生する。

再生するコンテンツのフォーマットは、インターネットで汎用的に用いられている各種の

MIME形式に対応する。

（７） WEBブラウザ機能

コンテンツ構造情報処理/制御機能の制御に基づき、HTTP プロキシ機能およびファイルキャ

ッシュからコンテンツファイルを読み出して再生する。

再生するコンテンツのフォーマットは、インターネットで汎用的に用いられている HTML 形式

およびそこで動作する JavaScript等に対応する。

（８） HTTP プロキシ機能

アプリケーションの機能のうち、ファイル処理部で蓄積されたファイルにアクセスする各機能

(コンテンツ構造情報処理/制御機能、ファイル表示再生機能、WEB ブラウザ機能)からの

HTTPリクエストを受付け、ファイル処理部のWEBサーバ機能に中継し、その応答を返す。

ファイル処理部のWEBサーバ機能にアクセスする際のURLのホスト名部分は、ホームネッ

トワーク等で割り当てられたファイル処理部の IP アドレスであり、コンテンツ制作の時点でコ

ンテンツ構造情報や HTML に URL を記載する際にはそれを知ることができないが、アプリ

ケーションの機能のうち、ファイル処理部で蓄積されたファイルにアクセスする各機能(コンテ

ンツ構造情報処理/制御機能、ファイル表示再生機能、WEB ブラウザ機能)が、ファイル処理

部のWEB サーバ機能に直接アクセスするのではなく、このHTTPプロキシ機能を経由して

アクセスするアーキテクチャとすることにより、コンテンツ制作の時点でコンテンツ構造情報や

HTMLに記載するURLのホスト名部分を固定値として記載することを可能にする。

（９）ファイルキャッシュ

HTTP プロキシ機能と連携して動作し、ファイル処理部から取得したファイルをアプリケーショ

ン内に一時的にキャッシュする機能。

ファイル処理部から直接ファイルを読み出すのではなく、このファイルキャッシュから読み出す

ことにより、ファイルの表示再生の高速化や、ファイル処理部に接続ができない状況でのファ

イル読み出しを可能とする。

（１０）インターネット接続部

外部デバイスのアプリケーションから、ホームネットワーク等あるいはモバイル通信機能等を

経由して、インターネット通信を行う機能。


11.2.2 動作シーケンス

外部デバイスのアプリケーションは、IP 入出力部やファイル処理部と連携して、以下のような

手順で動作する。

なお、この手順の前に、IP入出力部は IPDC受信機と外部デバイスとのペアリングを完了し、

ファイル処理部はデータキャストを受信してファイル化処理を行っていることを前提とする。

（１）制御コマンドのデータキャストを選択

データキャスト選択機能が、PMT 情報およびスタートアップ情報を要求して、取得し、

PMT 情報およびスタートアップ情報に記載された内容から、制御コマンドのデータキャ

ストを選択する。

（２）制御コマンド受信開始

制御コマンド受信機能が、制御コマンドのデータキャストを取得する。

（３）コンテンツ構造情報ファイルの取得

制御コマンド受信機能が、コンテンツ構造情報ファイルを取得するコマンドを受信してコ

ンテンツ構造情報処理 /制御機能に通知し、コンテンツ構造情報処理 /制御機能が

HTTP プロキシおよびファイルキャッシュ機能からコンテンツ構造情報ファイルを取得す

る。

（４）コンテンツの取得と再生

コンテンツ構造情報処理/制御機能が、コンテンツ構造情報および制御コマンドにしたが

って以下の動作を制御する。

・ファイルコンテンツの取得と再生

・ストリームコンテンツの取得と再生

・WEBブラウザ機能の制御

（５） HTML コンテンツをWebSocketで制御

WEB ブラウザ機能は、HTML コンテンツ中に記載された JavaScript を起動して

WebSocketプロキシとWebSocketセッションを確立し、WebSocketプロキシから通知さ

れる制御コマンドによって JavaScript を制御し、HTML コンテンツ内の各種の表示再

生動作をする。

（６）インターネット通信によるサーバ等との接続

コンテンツ構造情報処理/制御機能や WEB ブラウザ機能は、コンテンツ構造情報や

HTML コンテンツ中に記載された URL により、インターネット通信でサーバ等と接続し

て、コンテンツの取得や表示再生、サーバへの情報通知を行う。


11.3 制御コマンドおよびコンテンツ構造情報

11.2 節に記載した想定アプリケーションのアーキテクチャおよびその動作を前提に、制御コマン

ドおよびコンテンツ構造情報の概要を記載する。

11.3.1 制御コマンド

（１）コンテンツ構造情報処理/制御機能を制御するコマンド

JSON等のテキスト形式で、UDPパケットとして通知する。

重複受信した際に不要なコマンドを処理しないための、一意の識別子を持つ。

主なコマンドとして、以下のものを想定する。

・コンテンツ構造情報ファイルの取得

・コンテンツ構造情報ファイルのオープン

・コンテンツファイルの取得

・コンテンツファイルの表示と再生

・HTML ファイルを指定したWEBブラウザ機能の呼び出し

・コンテンツ構造情報ファイルのクローズ

（２） HTML コンテンツを制御するコマンド

JSON等のテキスト形式でUDPパケットとして受信したものをWebSocketで通知する。


コマンドの種類やパラメータについては規定せず、HTML コンテンツや JavaScript の

制作者が決定する。

想定しないコマンドを受信した際にそれを無視するために、コマンドが対象としている

HTML コンテンツの識別子を、コマンド内に記載する。

11.3.2 コンテンツ構造情報

XML 等のテキストファイルとしてデータキャストで配信する。

コンテンツ構造情報ファイルをアプリケーションから取得要求する際のURL は、

http://(HTTPプロキシ機能固定名) /コンテンツ構造情報ファイル固定名.xml

という固定値として、外部デバイスのアプリケーションが固定値として保持する。


コンテンツ構造情報に記載する項目として、以下のものを想定する。

・コンテンツ名

・コンテンツ識別子

・コンテンツの階層構造と各階層の識別子

・データキャストで受信したコンテンツの URL

・インターネット通信で取得するコンテンツのURL

http://(http/


11.4 制御コマンドおよびコンテンツ構造情報

11.2 節に記載した想定アプリケーションのアーキテクチャおよびその動作を前提に、IP パケット

あるいはファイルとして伝送されるコンテンツの種類を記載する。

11.4.1 IPパケットとして伝送されるコンテンツ

ファイル配信として用いられる FLUTEパケットを除く、IPパケットとして伝送されるコンテンツ

として、以下のものを想定する。

※PMT 情報、スタートアップ情報、および 11.3 節に記載した制御コマンドは、ファイルではなく

IP パケットとして伝送されるが、コンテンツではなく制御情報と考えられるため、ここには含まな

い。

（１）動画や音声のストリーム

RTPプロトコルなどに準拠した UDP パケットとしてデータキャストで配信する。

（２）短い文字列の通知

短時間で一斉配信したい文字列をUDP パケットとしてデータキャストで配信する。

（３）機器制御のためのデータ

機器を制御する文字列やバイナリデータをUDP パケットとしてデータキャストで配信す

る。

上記、いずれの場合も、マルチキャストの受信再生に対応した表示再生機能で再生するほか、

受信アプリケーション内でユニキャストに変換してから表示再生することも想定する。

11.4.2 IPパケットとして伝送されるコンテンツ

FLUTE パケットとして配信され、ファイル処理部によってファイル化されるコンテンツとして、

以下のものを想定する。

※11.3 節に記載したコンテンツ構造情報ファイルは、ファイルとして伝送されるが、コンテンツで

はなくコンテンツ管理情報と考えられるため、ここには含まない。

（１）動画、音声、画像、テキストなどの単体ファイル

インターネットで汎用的に用いられる、MIME形式に準拠したファイル

（２） HTML、JavaScript、CSS ファイル

WEBブラウザで表示再生可能な、HTML 仕様に準拠したファイル

上記、いずれの場合も、個々のファイルを個別に伝送するほか、複数のファイルを zip などでま

とめてひとつのファイルとして配信し、受信後に zipを展開して個々のファイルを取り出して利用

することも想定する。


12 想定する受信機構成

本章では、想定する受信機構成について、外部デバイスがファイル受信部を持つ場合と持たない

場合の特徴を記載する。

なお、いずれの場合でも、IPDC 受信機のファイル処理部（IPDC 受信機と常時連携する固定型

のファイル受信部）は存在することを前提とし、固定型の受信部は、IPDC 受信機に内蔵されてい

るか、または、ホームネットワーク等で有線接続され、常時稼働していることを想定する。

12.1 外部デバイスがファイル処理部を持たない場合

外部デバイスがファイル受信部を持たない場合の受信機構成を下の図に示す。

図 12-1 外部デバイスがファイル処理部を持たない場合

この場合、アプリケーションは、IPDC受信機のファイル処理部からファイルを取得する。

ファイルの蓄積可能容量やファイル化処理能力は、IPDC 受信機のファイル処理部の性能で決ま

る。


12.2 外部デバイスがファイル処理部を持つ場合

外部デバイスがファイル受信部を持つ場合の受信機構成を下の図に示す。

図 12-2 外部デバイスがファイル処理部を持つ場合

この場合、アプリケーションは、IPDC 受信機のファイル処理部に加えて、外部デバイスに内蔵さ

れたファイル受信部からもファイルを取得することができる。

ファイルの蓄積可能容量やファイル化処理能力は、IPDC 受信機のファイル処理部の性能と、外

部デバイスのファイル処理部の性能を合計した値となる。

ipdc 技術仕様指針書 · また本指針書の著作権はipdc...

Documents