• 検索結果がありません。

サービス伝送方式

ドキュメント内 ホワイトスペースにおける (ページ 36-48)

9 伝送プロトコル

9.2 PSI/SI規定

9.2.1 サービス伝送方式

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

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

・独立サービス方式

・完全独立方式

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

・独立PMT方式

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

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

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

IPDCフォーラム 37 9.2.2.1 全般的に適用される項目

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

A) 【Media_type】・【Service_type】

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

を検討する場合、テレビ型サービスか、データ型サービスという2つの【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】の決定に作用していて、3桁番号の決定、各サービス事業者のリ モコン番号の決定に作用する。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ループ追記 EIT (内容追記)

図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

EIT (サービス追加)

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

一体型受信機の場合、テレビサービスが選局されていれば、同じ電波で放送されているIPDCサ ービスを、自動的に受信してIP処理を行わせるなど、仕組みが必要となる。

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

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

ドキュメント内 ホワイトスペースにおける (ページ 36-48)

関連したドキュメント