ホワイトスペースにおける

IPDC フォーラム 1

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

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

IPDC 技術仕様指針書

第 1.0 版

2013 年 4 月 17 日

IPDC フォーラム

IPDC フォーラム 2

目 次

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

IPDC フォーラム 3 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

IPDC フォーラム 4

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

IPDC フォーラム 5

2 目的

本指針書は、地上デジタル放送の放送網を有効に活用して多様なサービスを実現するため、 地上デジタル放送にIPDC を実装するための技術的課題抽出とその解決方策について検討する ことを目的とする。

IPDC フォーラム 6

3 適用範囲

本指針書はIPDC フォーラムの会員有志による技術検討の成果をまとめたものであり、パテント 等の処理は行っていない。したがって、今後更なる検討を経て規格化や標準化等への段階に進 む場合には、それらの処理を行う必要がある。 また本指針書の著作権は IPDC フォーラムに帰するものとし、他の著作物において参照（部分 参照含む）される場合には、当フォーラム（ office@ipdcforum.org ）までご連絡いただきたい。

IPDC フォーラム 7

4 引用文献

ARIB STD-B10 デジタル放送に使用する番組配列情報 ARIB STD-B32 デジタル放送における映像符号化、音声符号化及び多重化方式 ARIB STD-B45 デジタル放送におけるダウンロード方式 ARIB TR-B14 地上デジタルテレビジョン放送運用規定 ARIB TR-B33 セグメント連結伝送方式による地上マルチメディア放送運用規定

IPDC フォーラム 8

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 つ

IPDC フォーラム 9 のテーブルからなる。

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)を配置す

IPDC フォーラム 10 る。

TCP プロキシ接続 IPDC 受信機と外部デバイスの間の接続方式。IPDC 受信機で抽 出された IP パケットをそのまま外部デバイスに配信するために用 いる。

SSDP Simple Service Discovery Protocol

外部デバイスからIPDC 受信機の存在と IP アドレス解決のた めに用いる。

IPDC フォーラム 11

6 概要・前提条件

1. 検討対象は地上デジタル放送とする 2. 固定受信を前提とする 3. すでに広く普及するデジタル放送受信機（テレビ等）に悪影響を与えないこと 4. IP の長所を最大限活用し、特定のサービスに偏らず多様なサービスに対応できること 5. テレビサービスとの関連性に留意すること

IPDC フォーラム 12

7 サービスモデル

放送用電波に IP を乗せて一斉配信する IPDC でのサービスは、IPDC で送られた IP データ を受信するIPDC 受信機、スマートフォンやタブレットなどのセカンドデバイス、ルーター、テレビな どを組み合わせて、様々ものが想定される。 各機器は単独で有るだけでなく、テレビと IPDC 受信機の一体型、IPDC 受信機とルーターの 一体型、IPDC 受信機とセカンドデバイスの一体型、テレビとルーターの一体型など、各機能を組 み合わせた機器も考えられる。 図7-1 想定する IPDC サービスの受信形態 なお、この章ではわかりやすくするために、機器は単独であるとして表記する。 IPDC でのサービスは、次の 2 つに大別される。 ① 独立データキャスト 独立データキャストは、放送から独立した情報を配信する。独立データキャストではテレビは 必須でなく、外部デバイスだけでも良い。 ② 連動データキャスト 放送（テレビ番組）と連携した情報を外部デバイス向けに配信する。テレビ視聴を前提とし、テ レビとセカンドデバイスが連携する。

IPDC フォーラム 13 独立データキャスト IPDC 受信機のみのサービス 図7-2 独立データキャストにおける IPDC 受信機のみのサービスモデル IPDC 受信機で IP データの受信と表示処理を行い、映像と音声のみ外部出力する。 デジタルサイネージへのコンテンツ配信、3D や 4K の番組蓄積の配信などが想定される。 独立データキャスト 外部デバイスを用いるサービス 図7-3 独立データキャストにおける外部デバイスを用いるサービスモデル IPDC 受信機で受信した IP データを外部デバイスに送る。IP データの表示処理は、外部デバ イスに搭載されているアプリケーションで行う。 IPDC 受信機と外部デバイスは、1 対 1、もしくは 1 対複数で接続される。各外部デバイスでは、 送られたデータからデバイスに登録されている属性にあわせて情報を取り出し表示することがで きる。

IPDC フォーラム 14 これにインターネットを組み合わせたものが次の図になる。 図7-4 独立データキャストにおける外部デバイスとインターネットを用いるサービスモデル インターネットへの接続は、ルーター経由で行う。 インターネットを併用することで、IPDC で欠落したデータの補完や、インターネットを利用してコ ンテンツを取得することもできる。また、外部デバイス側からデータ送信が可能になるので、双方 向を前提としたコンテンツ制作が可能になる。 独立データ配信サービスや、放送と連動しない独立放送（動画・音声）、電子新聞や電子書籍 などの配信が想定される。

IPDC フォーラム 15 連動データキャストによるサービス 図 7-5 連動データキャストにおけるサービスモデル テレビの表示（放送番組）に連携して、外部デバイスの表示内容が変化する。 IPDC 受信機と外部デバイスは、1 対 1、もしくは１対複数で接続される。各外部デバイスでは、 送られたデータからデバイスに登録されている属性にあわせて情報を取り出し表示することもでき る。 これにインターネットを組み合わせたものが次の図になる。 図 7-6 連動データキャストにおいてインターネットを用いるサービスモデル

IPDC フォーラム 16 インターネットへの接続は、ルーター経由で行う。 インターネットを併用することで、IPDC で欠落したデータの補完や、インターネットを利用してコ ンテンツを取得することもできる。また、外部デバイス側からデータ送信が可能になるので、双方 向を前提としたコンテンツ制作が可能になる。 マルチスクリーン型放送がこれにあたる。

IPDC フォーラム 17

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 制作・ 送出シ ステム 外部デバイス

IPDC フォーラム 18 システムモデルの機能ブロックについて図8-2 に示す。 TS RF ホームネットワーク TS 処理 外部デバイス IPDC受信機 IP 処理 ULE 処理 フロント エンド 制御 マルチキャスト 管理 フ ロ ン ト エ ン ド IP 入出力 部 FLUTE 処理 IP 受信 一体型受信機 FLUTE 処理 IP 受信 内部 ストレージ 内部ス トレージ アプリケーション ＩＰ受信部 ファイル処理部1 送信処理ブロック IP IP IP IP FILE FILE IP 処理 FILE 処理 ファイル処理部2 TS IP IP ＩＰ送信部 PMT 処理 RF IP TS 処理 IP 処理 TS ULE 処理 マスターシステム 送信機 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 処理機能を備える。

IPDC フォーラム 19 ２）ファイル処理部

FLUTE プロトコルを持つ IP パケットを受信し、ファイルとして再構成するための「ファイル処理 部」として定義する。ここではファイルを一時的に保持し、外部からはHTTP としてアクセスできる ようにWeb サーバ機能を有することを想定する。IP 処理機能、FLUTE 処理機能、内部ストレー ジ機能を備える。 ３）IP 入出力部 抽出されたIP パケットを外部デバイスに対して配信するためのインタフェースとして「IP 入出力 部」を定義する。ホームネットワークにおいて、外部ネットワークへ影響を与えないことと、外部ネッ トワークに影響されないことを想定し、ローカルネットワーク環境を構築する。TCP プロキシ接続 機能を備える。 ４）アプリケーション部 IP パケットと Web サーバ経由のコンテンツを使用してデータ処理や表示処理を行うものとして 「アプリケーション部」を定義する。アプリケーション機能は本指針書では規定しない。尚、アプリケ ーションとしてファイル処理部を持つような実装も可能である。 □受信装置の想定 受信側の装置として、以下の装置を想定する。 １）IPDC 受信機 IP 受信部にファイル処理部と IP 入出力部を加えたものを IPDC 受信機として想定する。 ２）外部デバイス IPDC 受信機の外にあり、ホームネットワーク内に存在するデバイス(タブレットやスマートフォン) を想定する。外部デバイスからIPDC 受信機に接続して IP パケットの受信と Web アクセスによる ファイル取得を行う。データ処理についてはアプリケーションレイヤとして処理する。 ３）一体型受信機 IPDC 受信機と外部デバイスを組み合わせた装置を想定する。

IPDC フォーラム 20 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伝送方式） データ放送伝送方式 (カルーセル伝送方式) マルチメディア符号化 モノメディア符号化 字幕、文字ｽｰﾊﾟｰ 符号化 データ放送コンテンツ 送出系 ＡＶ エンコーダ ベース バンド 制御系 字幕・文字スーパー 挿入 ＩＰＤＣコンテンツ 送出系 ＩＰＤＣ伝送方式 (ＵＬＥ伝送方式) ＦＬＵＴＥ伝送方式 制作系 送出系 伝送系 ＩＰＤＣ送出システム M P EG 2 -TS 図8-3 地上デジタル放送 送出システム構成

IPDC フォーラム 21 送信設備における通信系システムは、地上デジタル放送で配信したコンテンツの補助的な役割 を行う。IPDC コンテンツは、放送波のみですべての配信するようなコンテンツのほかに、放送波 で配信するコンテンツと通信で取得するコンテンツから構成されるコンテンツも想定している。通信 システムは、一般的な HTTP サーバのほかに、アプリケーションとの双方向通信を前提としたも のなど、IPDC サービスの内容に依存する。 制作系 送出系 伝送系 MPE G 2 -TS 多 重 化 ・ ス ク ラ ン ブ ル ・ 変 調 ＩＰＤＣ コンテンツ 制作 ＩＰＤＣ送出設備 IPDC 受信機 表示端末 地上波デジタル放送 送出システム ・PSI情報、番組配列情報送出 ・ＡＶ送出 ・字幕・文字スーパー ・データ放送送出 公衆網等 通信系システム httpサーバ 双方向サーバ その他 各種サーバ 図8-4 送信設備における通信系システム構成

IPDC フォーラム 22 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 に示す。

IPDC フォーラム 23 フロントエンド 受信部 フロントエンド制 御部 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 パケットを配信する。

IPDC フォーラム 24 8.4 IP 入出力部 この節では、IP 入出力部について記載する。 IP 入出力部は、8.3 節【IP 受信部】に記載した IP 受信部から出力される IP パケットを、 ホーム ネットワークに接続された外部デバイスに転送したり、逆に、外部デバイスからのマルチキャスト JOIN 要求パケット等を IP 受信部に転送する役割を持つ。 IPDC 受信機と外部デバイスのそれぞれに IP 入出力部があり、それらが連携して動作する。 外部デバイスのアプリケーションは、IP 入出力部を経由して、PMT 情報を受け取って IPDC 受信 機の受信しているIPDC サービスやデータキャストを特定し、さらに、目的のデータキャストを指定 して受信要求を出してそれを受信することができる。 上記の動作フローを以下の図8-8 に示す。 図8-8 IP 入出力部の動作フロー

IPDC フォーラム 25 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 入出力部の機能概要

IPDC フォーラム 26 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.。

IPDC フォーラム 27 8.4.3 IPDC 受信機と外部デバイス間の IP パケット転送方法 IP 受信部から出力される IP パケットは、UDP のマルチキャストパケットである。それを外部デバ イスに転送する方法として、ホームネットワーク等にマルチキャスト配信して外部デバイスがそれ にJOIN して受信する方法も考えられるが、その場合、無線 LAN の特性によるパケットの欠落や、 ホームネットワーク等に多量のマルチキャストパケットが流れることによる通信障害の懸念、ホー ムネットワークを流れる他のサービスとのマルチキャストアドレス重複の可能性、といった課題が 想定される。 それらの課題を解決するためには、各種のTCP 通信によるトンネリング手法等が考えられるが、 本指針書では、放送局から送出された UDP パケットをそのままペイロードとして扱えることと、タ ブレット等のルーター機能の改変に制限がある外部デバイスを考慮し、IP 受信部から出力された UDP パケットを、IP 入出力部ではペイロードとして扱い、ホームネットワーク内での TCP 通信に より転送する方式とする。 この方式を、「TCP プロキシ接続」と呼ぶ。 ただし、将来は、別の仕組みを採用することを妨げるものではない。 TCP プロキシ接続フォーマットを図 8-10 に示す。 図8-10 TCP プロキシ接続フォーマット

IPDC フォーラム 28 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 のコネクション終了フェーズにて接続は切断す る。 ・何らかの障害等である一定時間接続応答がない場合は、接続が切断されるが、その場 合は、外部デバイスのアプリケーションから改めて接続する。

IPDC フォーラム 29 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 はデフォルトポート番号での処理動作 となる。

IPDC フォーラム 30 8.5 ファイル処理部 この節では、IPDC で配信されたファイルを受信して蓄積し、外部デバイスの WEB ブラウザやア プリケーションから利用可能とする役割を持つファイル処理部について記載する。 ファイル処理部は、IP 受信部から出力される IP パケットのうち、ファイル配信に用いられる FLUTE パケットを受信してファイル化処理を行い、適切なディレクトリに格納する。 また、ホームネットワーク等においてWEB サーバとして動作する機能を持つ。 8.5.1 ファイル処理部の機能構成 ファイル処理部は、以下の3 つの機能で構成される。 （１）ファイル蓄積機能 IP 受信部の出力するマルチキャストのうち、ファイル配信のデータキャストであるものに JOIN し、FLUTE プロトコルで受信とファイル化の処理を行い、ファイルを適切なディレク トリに格納する。 （２）Web サーバ機能 IPDC で配信されたファイルをホームネットワーク内の外部デバイスから HTTP でアクセス 可能にする。 （３）ファイル消去機能 ファイル処理部のファイル保存容量超過の防止や、チャンネル変更時に蓄積されたファイ ルを消去する。 上記の機能概要を以下の図8-11 に示す。

IPDC フォーラム 31 図8-11 ファイル処理部の機能概要

IPDC フォーラム 32 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 プロトコルにより受信側に通知される。

IPDC フォーラム 33 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 サーバ機能でアクセス可能なディレクトリにファ イルを保存する。

IPDC フォーラム 34 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 により、放送の選局チャンネルが切り替わったことを検知したとき → すべてのファイルを消去する ・ファイル保存領域の空き容量が一定の割合を下回ったとき → 空き容量が一定の割合になるまで、古いファイルから順に消去する。 ファイル保存領域については、最低容量を規定する。 ・放送局で指定した、すべてのファイルの最低保存時間（期間）を過ぎたとき → 一定の時間ごとにバッチ処理を行い、ファイルのタイムスタンプが一定時間以上 古いものは消す。バッチ処理のサイクルについては規定しない。

IPDC フォーラム 35

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 未定義部分 拡張部分 インターネットコンテンツを流用可能な ように、符号化方式はオープンとする 規格拡張部分 地上デジタル放送 運用規格

IPDC フォーラム 36 9.2 ＰＳＩ／ＳＩ規定 9.2.1 はじめに PSI/SI は地上デジタル放送規格の根幹を形成している部分であり、この改編を検討するにあた り、 ・現在普及している受信機が影響を受ける可能性がある。 ・対応受信機の普及を考えると、IPDC サービスの考え方が考慮されており、すでにサービスが運 用されている ISDB-Tmm 方式や、現在検討が行われている V-Low など他の規格とどう整合を 取るか。 ・リスクやコストに見合ったサービスが構築できるか。 等、大きな課題がある。検討を進めていくにあたっては、複数の選択肢を視野に入れ、慎重に議 論を重ねる必要がある。 ここでは、それらの課題を意識しながら、本書第7 章 サービスイメージモデル、第 8 章 システ ムモデルで記載しているサービスを想定し、IPDC 受信機でサービスをどう受信するかということ、 IP 受信部以降に存在するファイル処理部、外部デバイスがサービスへ到達できるようにすること、 を目的とした地上デジタル放送における伝送制御信号の拡張を検討する。 9.2.1 サービス伝送方式 IPDC サービスを放送波に重畳する際の伝送方式を、 ・テレビサービス連動方式 ・独立サービス方式 ・完全独立方式 ・テレビサービスにリンクした独立方式 ・独立PMT 方式 ・未参照方式（直接受信方式） で分類し検討を進めるが、最初に方式によらず全般的に適用される項目を検討し、それ以降で、 それぞれの方式でIPDC サービスを運用する場合に適用される項目の特徴・問題点をまとめる。

IPDC フォーラム 37 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 フォーラム 38 ・データ型 独立型の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 を以下に示す。

IPDC フォーラム 39 表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 分のデータ放送(透明コンテンツなどの簡易

IPDC フォーラム 40 的なもの)を出力する必要がある。 【 地域識別を使用する案】 現在、地上波では地域識別は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 フォーラム 41 アクセス制御・コンテンツ保護に関わる、限定受信方式記述子、アクセス制御記述子、コンテント 利用記述子、デジタルコピー制御記述子等の運用について、地上デジタル放送の運用に基づい て記述子を配置する必要がある。IPDC の ES に関して、受信機から出力する場合、DHCP-IP な どによるコンテンツ保護の扱いを考慮せず、伝送される IP パケットとして出力できることが望まし いと考えられる。IP 伝送路の暗号化や配信されるコンテンツの保護については、別章にて検討す る。 F) 【全体として】 【media_type】は【service_id】の決定に作用していて、３桁番号の決定、各サービス事業者のリ モコン番号の決定に作用する。IPDC サービス非対応の受信機は、各項目で非対応の判断をし、 処理をしないという動作が望ましいが、既存のテレビサービスを享受している視聴者に直接的な 影響を与える可能性がある部分であり、慎重に調査する必要がある。

IPDC フォーラム 42 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】で処理対象外として判断することが望ましい動作になる。

IPDC フォーラム 43 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-ES PAT ・サービス追記 PMT ＥＩＴ (サービス追加) 図9-3 独立サービス型の PSI/SI モデル 一体型受信機の場合、テレビサービスが選局されていれば、同じ電波で放送されているIPDC サ ービスを、自動的に受信してIP 処理を行わせるなど、仕組みが必要となる。

また【Service_type】は新設する IPDC サービスになるため、IPDC に対応していない受信機は、 この内容で処理対象外として判断することが望ましい動作になる。

IPDC フォーラム 44 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 上でサービスが定義されないプログラムとは、例えばテス

IPDC フォーラム 45 ト放送や、選局したサービスからのリンクによってのみ選局されるサービス等であり、チャンネル 番号入力等で直接選局動作をさせないことを意味する。」“ など、現在の規格でプログラム選択処理に関する各テーブルの例外運用記載がある。これらの記 載の適用が可能であれば、テレビサービスに連動して自動起動するサービスとして、NIT・SDT には定義せず、個別サービスとしては選局対象としないということも検討の対象としたい。この検 討が妥当であれば、EIT も送出の必要がなくなる。（テレビサービスのチャンネル選局と連動する 仕組みは別途考慮する必要がある。） PMT についても影響は懸念される。PMT の内容について、【Service_type】は新設する IPDC サービスで検討しているが、対応していない受信機は、この【Service_type】で処理対象外として 判断することが望ましい動作になる。

IPDC フォーラム 46 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-ES PMT 図9-5 独立 PMT 方式の PSI/SI モデル 受信処理にMPEG-2 の運用から外れた例外的な独自処理の取り決めが必要となる。 ・IPDC 受信機は、各局の選択が行われたときに、PMT のサーチを行い、IPDC サービスが送出 されていた場合、そのES のデコード処理を行う。

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

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

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

IPDC フォーラム 47 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 へ配置することになるためその テレビサービスへ影響する可能性も考えられるなど、どの方式にも一長一短がある。既存受信機 への影響を考慮しながら段階的に検討する必要がある。

IPDC フォーラム 48 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)で伝送される。

IPDC フォーラム 49 図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 で運用している、国際規格がベースになっていることなど考慮すべき点も多い。