JP2017509199A

JP2017509199A - １つ以上のネットワークを介して放送コンテンツを送信又は受信するための方法及び装置

Info

Publication number: JP2017509199A
Application number: JP2016546500A
Authority: JP
Inventors: セチンオ; チャンウォンリ; ウソクコ; ソンリョンホン; ウソククォン; キョンソムン
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2014-01-13
Filing date: 2015-01-12
Publication date: 2017-03-30
Anticipated expiration: 2035-01-12
Also published as: EP3095245A4; EP3095245A1; CN105917655B; KR20160091422A; US11477259B2; CN105917655A; US11095703B2; US20190268397A1; WO2015105391A1; US10326816B2; KR101789641B1; US20160315991A1; JP6309639B2; US20210344734A1

Abstract

【課題】本発明は、一つの網を介して放送コンテンツを受信する装置を提供する。【解決手段】装置は、放送網を介して、前記放送コンテンツの第１部分を含む第１プロトコルパケットを含む放送ストリームを受信する放送網インターフェース、異種網を介して、放送コンテンツの第２部分を含む第２プロトコルパケットを受信する異種網インターフェース、及び第３プロトコルパケットに含まれる情報に基づいて第１プロトコルパケット及び第２プロトコルパケットを用いて放送コンテンツを構成するプロセッサを含む。【選択図】図７４

Description

本発明は、デジタル放送システムにおいてハイブリッド放送をサポートする方法及び装置に関する。より詳細には、本発明は、デジタル放送システムにおいて１つ以上の伝送網から送信／受信される伝送ストリームを結合して使用するための送信／受信処理方法及び装置に関する。また、本発明は、デジタル放送システムにおいて互いに異なるプロトコルを用いてパケットを結合して使用するための送信／受信処理方法及び装置に関する。

デジタル放送システムは、地上波放送、衛星放送又はケーブル放送網を介してコンテンツを提供する。しかし、このような放送網は、制限された帯域幅を有し、視聴者が放送コンテンツに活発に参加するのに困難がある。

特に、放送コンテンツが伝送される放送網の帯域幅は、コンテンツの多様化及び高品質化のため限界に到達している。これを解決するために、放送網及びインターネットを介してデータを受信し、データを同時に使用するハイブリッド放送システムが開発されている。

しかし、ハイブリッド放送システムにおいて、伝送ストリームが結合されるとき、放送網及びインターネットを介してそれぞれ伝送された伝送ストリームを同期化する方法が提案されていない。また、ハイブリッド放送システムは、放送網及びインターネットを介してそれぞれ伝送された伝送ストリームを同期化するために複雑な計算を必要とする。

現在のハイブリッド放送システムは、放送網及びインターネットのそれぞれを介して伝送された伝送ストリームが、同期化を必要としない形態を有する個別コンテンツと結合されて提供される問題点を有する。

また、ハイブリッド放送システムは、放送網及びインターネットのそれぞれを介して伝送された伝送ストリームを同期化するために、受信機の過度な計算性能を必要とするという問題点を有する。

現在のハイブリッド放送システムは、パケットが結合されて放送コンテンツを提示しなければならない場合、互いに異なるプロトコルを用いてパケット間の同期化を行うのに問題を有する。

本発明の目的は、上述した問題点を解決するために考案された。

上記目的及び他の利点を達成するために及び本発明の目的によって、本発明は、一つの網を介して放送コンテンツを受信する装置を提供する。装置は、放送網を介して、前記放送コンテンツの第１部分を含む第１プロトコルパケットを含む放送ストリームを受信する放送網インターフェース、異種網を介して、前記放送コンテンツの第２部分を含む第２プロトコルパケットを受信する異種網インターフェースであって、前記放送ストリームは、１つ以上の網を介して伝送される異なるプロトコルパケット間の同期化のためのメタデータを含む第３プロトコルパケットをさらに含み、前記第３プロトコルパケットは、第２プロトコルパケットが取得される位置を特定する位置情報を含み、前記第３プロトコルパケットは、前記第１プロトコルパケットが使用される第１タイミングを特定する第１タイミング情報、及び第２プロトコルパケットが使用される第２タイミングを特定する第２タイミング情報をさらに含む、異種網インターフェース、及び前記第３プロトコルパケットに含まれる情報に基づいて前記第１プロトコルパケット及び前記第２プロトコルパケットを用いて前記放送コンテンツを構成するプロセッサを含む。

好ましくは、前記放送ストリームは、前記第１プロトコルパケットと異なるプロトコルを用いる第４プロトコルパケットをさらに含み、前記第３プロトコルパケットは、前記第４プロトコルパケットが使用される第４タイミングを特定する第４タイミング情報をさらに含む。

好ましくは、前記第１プロトコルパケットは、リアルタイムプロトコル（ＲＴＰ）パケットに対応し、前記第２プロトコルパケットは、ＭＰＥＧＤＡＳＨ（ＤｙｎａｍｉｃＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇｏｖｅｒＨＴＴＰ）セグメントを伝達し、前記第３プロトコルパケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットに対応する。

好ましくは、前記プロセッサは、前記第１タイミング情報によって特定された第１タイミングをＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）タイムラインにマッピングし、前記位置情報に基づいて取得された第２プロトコルパケットに適用される前記第２タイミング情報によって特定された第２タイミングを前記ＮＴＰタイムラインにマッピングし、前記ＮＴＰタイムラインを用いて前記第１プロトコルパケット及び前記第２プロトコルパケットを同期化することによって前記放送コンテンツを構成する。

好ましくは、前記第１タイミング情報は、前記第１プロトコルパケットのＮＴＰタイムスタンプ及びＲＴＰタイムスタンプに対応し、前記第２タイミング情報は、ＤＡＳＨメディアプレゼンテーション時間情報に対応する。

好ましくは、前記第３プロトコルパケットは、前記第２タイミング情報のフォーマットを特定するフォーマット情報をさらに含む。

好ましくは、前記プロセッサはまた、前記第１プロトコルパケットが受信される時点で前記ＮＴＰタイムスタンプと受信機壁時計時間との間のオフセットを算出し、前記算出されたオフセットに基づいて前記第１タイミング及び前記第２タイミングを調節し、前記調節された第１タイミング及び第２タイミングを用いて前記第１プロトコルパケット及び前記第２プロトコルパケットを同期化することによって前記放送コンテンツを構成する。

本発明は、受信機で一つの網を介して放送コンテンツを受信する方法を提供する。方法は、放送網を介して、前記放送コンテンツの第１部分を含む第１プロトコルパケットを含む放送ストリームを受信するステップ、異種網を介して、前記放送コンテンツの第２部分を含む第２プロトコルパケットを受信するステップであって、前記放送ストリームは、１つ以上の網を介して伝送される異なるプロトコルパケット間の同期化のためのメタデータを含む第３プロトコルパケットをさらに含み、前記第３プロトコルパケットは、第２プロトコルパケットが取得される位置を特定する位置情報を含み、前記第３プロトコルパケットは、前記第１プロトコルパケットが使用される第１タイミングを特定する第１タイミング情報、及び第２プロトコルパケットが使用される第２タイミングを特定する第２タイミング情報をさらに含む、ステップ、及び前記第３プロトコルパケットに含まれる情報に基づいて前記第１プロトコルパケット及び前記第２プロトコルパケットを用いて前記放送コンテンツを構成するステップを含む。

好ましくは、方法は、前記第１タイミング情報によって特定された第１タイミングをＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）タイムラインにマッピングするステップ、前記位置情報に基づいて取得された第２プロトコルパケットに適用される前記第２タイミング情報によって特定された第２タイミングを前記ＮＴＰタイムラインにマッピングするステップ、及び前記ＮＴＰタイムラインを用いて前記第１プロトコルパケット及び前記第２プロトコルパケットを同期化することによって前記放送コンテンツを構成するステップをさらに含む。

好ましくは、方法は、前記第１プロトコルパケットが受信される時点で前記ＮＴＰタイムスタンプと受信機壁時計時間との間のオフセットを算出するステップ、前記算出されたオフセットに基づいて前記第１タイミング及び前記第２タイミングを調節するステップ、及び前記調節された第１タイミング及び第２タイミングを用いて前記第１プロトコルパケット及び前記第２プロトコルパケットを同期化することによって前記放送コンテンツを構成するステップをさらに含む。

本発明は、異種網のそれぞれを介して伝送される伝送ストリームを異なるプロトコルを用いて容易に同期化するのに効果的である。

本発明は、異種網又はプロトコルの特性に関係なく多くの用途に適用可能な異種網のそれぞれを介して伝送される伝送ストリームの同期化に効果的である。

本発明は、異種網又は互いに異なるプロトコルを介して同一のコンテンツと結合可能な様々な放送データを提供できるので、ユーザの便宜を向上させるのに効果的である。

本発明に関する理解を助けるために詳細な説明の一部として含まれる添付の図面は、本発明に関する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。

本発明の実施例によって未来の放送サービスのための放送信号を送信する装置の構造を示す図である。本発明の一実施例に係る入力フォーマッティングブロックを示す図である。本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。本発明の実施例に係るＢＩＣＭブロックを示す図である。本発明の他の実施例に係るＢＩＣＭブロックを示す図である。本発明の一実施例に係るフレームビルディングブロックを示す図である。本発明の実施例に係るＯＦＤＭ生成ブロックを示す図である。本発明の実施例によって将来の放送サービスのための放送信号を受信する装置の構造を示す図である。本発明の実施例に係るフレーム構造を示す図である。本発明の実施例に係るフレームのシグナリング階層構造を示す図である。本発明の実施例に係るプリアンブルシグナリングデータを示す図である。本発明の実施例に係るＰＬＳ１データを示す図である。本発明の実施例に係るＰＬＳ２データを示す図である。本発明の他の実施例に係るＰＬＳ２データを示す図である。本発明の実施例に係るフレームの論理構造を示す図である。本発明の実施例に係るＰＬＳマッピングを示す図である。本発明の実施例に係るＥＡＣマッピングを示す図である。本発明の実施例に係るＦＩＣマッピングを示す図である。本発明の実施例に係るＤＰのタイプを示す図である。本発明の実施例に係るＤＰマッピングを示す図である。本発明の実施例に係るＦＥＣ構造を示す図である。本発明の実施例に係るビットインターリービングを示す図である。本発明の実施例に係るセル−ワードデマルチプレクシングを示す図である。本発明の実施例に係る時間インターリービングを示す図である。本発明の実施例に係るツイスト行−列ブロックインターリーバの基本動作を示す図である。本発明の他の実施例に係るツイスト行−列ブロックインターリーバの動作を示す図である。本発明の実施例に係るツイスト行−列ブロックインターリーバの対角線方向読み取りパターンを示す図である。本発明の実施例に係る各インターリービングアレイからのインターリーブされたＸＦＥＣＢＬＯＣＫを示す図である。本発明の実施例に係る次世代放送システム用プロトコルスタックを示す図である。本発明の一実施例に係る放送伝送フレームを示す図である。本発明の他の実施例に係る放送伝送フレームを示す図である。本発明の一実施例に係る放送サービスを伝送する伝送パケットの構造を示す図である。本発明の一実施例に係るＮｅｔｗｏｒｋＰｒｏｔｏｃｏｌフィールドの意味を示す図である。本発明の一実施例に係る放送受信装置の構成を示す図である。本発明の他の実施例に係る放送受信装置の構成を示す図である。本発明の一実施例に係る、次世代放送システムにおいてサービス及び／又はコンテンツを取得する構造を示す図である。本発明の一実施例に係る放送サービスシグナリングテーブルを示す図である。本発明の一実施例に係るｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールドの意味を示す図である。本発明の他の実施例に係る放送サービスシグナリングテーブルを示す図である。本発明の他の実施例に係るストリーム識別子ディスクリプタを示す図である。本発明の一実施例に係る放送送信装置が放送サービスシグナリングテーブルを伝送する動作を示す図である。本発明の一実施例に係る放送受信装置がパケット化された放送パケットを受信する動作を示す図である。本発明の実施例に係るパケットの構成を示す図である。本発明の実施例に係るリアルタイムコンテンツ伝送のためのＲＴＰ（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）パケットの構造を示す図である。本発明の一実施例に係るＩＳＯｂａｓｅｍｅｄｉａｆｉｌｅｆｏｒｍａｔ（以下、「ＩＳＯＢＭＦＦ」という）をベースとするメディアファイルフォーマットを示す図である。本発明の一実施例に係るパケットペイロードのペイロードヘッダーの構成を示す図である。一つのパケットに一つのメディアデータがパケット化された伝送パケットのペイロードの構成を示す図である。一つのパケットに一つのメディアデータがパケット化された伝送パケットのペイロードの構成を示す図である。一つのパケットに複数の互いに異なるメディアデータがパケット化された伝送パケットの構成を示す図である。アグリゲーションユニットの構成を示す他の実施例を示す図である。フラグメント化されたパケット（ｆｒａｇｍｅｎｔｅｄｐａｃｋｅｔ）のペイロードの構成の一実施例を示す図である。フラグメント化されたパケットのペイロードの構成の他の実施例を示す図である。本発明の一実施例において、放送送信装置がＩＳＯＢＭＦＦベースのメディアファイルをフラグメンテーションして複数個のパケットに分けることを示す図である。放送送信装置がパケット化した第１フラグメンテーションユニットデータの具体的な実施例を示す図である。フラグメンテーションユニットデータのうち開始データを除いた残りのデータを含むフラグメンテーションユニットの一実施例を示す図である。ペイロードデータが、開始データを含むフラグメンテーションユニットデータ及び終了データを含むフラグメンテーションユニットデータを含まない場合のペイロードの構成を示す図である。分けられた全メディアデータのうち終了データを含むフラグメンテーションユニットを含むペイロードの構成を示す図である。本発明の一実施例に係るメタデータのタイムラインシグナリングテーブルを示す図である。伝送パケットのペイロードデータに一つのメタデータがパケット化されたペイロードデータの構成を示す図である。伝送パケットのペイロードデータがタイムラインに関するメタデータを含む場合の一実施例を示す図である。一つの伝送パケットに多数のメタデータがパケット化された場合を示す図である。一つの伝送パケットが複数個のタイムライン情報を含む場合を示す図である。一つのメタデータを複数個の伝送パケットに分けてパケット化したパケットペイロードを示す図である。メタデータフラグメントヘッダーの更に他の実施例を示す図である。本発明の一実施例に係る放送受信装置が放送パケットを受信する動作を示す図である。放送網を介してはＲＴＰプロトコルを用いてビデオストリームを伝送し、インターネット網を介してはファイルフォーマットベースのメディアデータを用いてビデオストリームを伝送する場合を示す図である。本発明の他の実施例による、タイムラインコンポーネントアクセスユニット（ｔｉｍｅｌｉｎｅｃｏｍｐｏｎｅｎｔａｃｃｅｓｓｕｎｉｔ）のシンタックス（ｓｙｎｔａｘ）を示す図である。本発明の一実施例に係る、リアルタイムコンテンツ伝送プロトコル上でメディアの同期化をサポートするための伝送パケットフォーマットを示す図である。本発明の一実施例に係る、プロファイル特定拡張（ｐｒｏｆｉｌｅ−ｓｐｅｃｉｆｉｃｅｘｔｅｎｓｉｏｎ）を示す図である。本発明の一実施例に係る、アプリケーション定義ＲＴＣＰパケット（Ａｐｐｌｉｃａｔｉｏｎ−ＤｅｆｉｎｅｄＲＴＣＰＰａｃｋｅｔ）であるＲＴＣＰアプリケーションパケットを示す図である。本発明の一実施例に係る、アプリケーション従属データ（ａｐｐｌｉｃａｔｉｏｎ−ｄｅｐｅｎｄｅｎｔｄａｔａ）を示す図である。本発明の実施例として、放送システムに適用可能なプロトコルスタックを示す図である。本発明の実施例として、ＲＴＰプレゼンテーション時間から受信機壁時計時間への変換を示す図である。一つのビデオトラック、一つのオーディオトラック及び一つのクローズドキャプショントラックがＲＴＰで放送を介して伝達される場合のプロトコルスタックを示す図である。一つのビデオトラック、一つのオーディオトラック及び一つのクローズドキャプショントラックがＡＬＣ／ＬＣＴ＋を通じてＩＳＯＢＭＦＦで放送を介して伝達される場合のプロトコルスタックを示す図である。本発明の実施例として、放送チャネルでＲＴＰを介して伝達される連続メディアコンポーネントと、ブロードバンドを介してＤＡＳＨを介して伝達される連続メディアコンポーネントとの間の同期化の動作例を示す図である。本発明の実施例として、放送チャネルでＲＴＰを介して伝達される連続メディアコンポーネントと、ブロードバンドを介してＤＡＳＨを介して伝達される連続メディアコンポーネントとの間の同期化方法を示す図である。本発明の実施例として、アプリケーション定義ＲＴＣＰパケットの例を示す図である。本発明の実施例として、ＲＴＣＰ送信者報告パケットヘッダーの例を示す図である。本発明の実施例として、ＲＴＰによるハイブリッド伝達のためのプロトコルスタックを示す図である。本発明の実施例として、受信機壁時計タイムラインへのＤＡＳＨプレゼンテーション時間の変換を示す図である。本発明の実施例として、ＡＬＣ／ＬＣＴ＋を介して伝達されたコンテンツと、ＤＡＳＨ（ユニキャスト）を介して伝達されたコンテンツとの同期化を示す図である。本発明の実施例として、ＡＬＣ／ＬＣＴ＋を介して伝達されたコンテンツと、ＤＡＳＨ（ユニキャスト）を介して伝達されたコンテンツとの同期化方式を示す図である。本発明の実施例として、ＡＬＣ／ＬＣＴ＋を通じてＩＳＯＢＭＦＦのハイブリッド伝達のためのプロトコルスタックを示す図である。

以下、添付の図面を参照して本発明の好適な実施例を説明する。添付の図面を参照して以下に説明する詳細な説明は、本発明によって具現し得る実施例だけを示すよりは、本発明の例示的な実施例を説明するためのものである。

本発明で使われる大部分の用語は、本明細書でその機能を考慮し、当該分野で広く使われているものから選択されたが、一部の用語は出願人によって任意に選択されたものもあり、その意味は、必要によって次の説明で詳細に説明する。したがって、本発明は、単なる名称又は意味よりは、用語の意図した意味に基づいて理解されなければならない。

本発明は、次世代放送サービスに対する放送信号送信及び受信装置及び方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。

本発明でいう「シグナリング」とは、サービス情報（ＳＩ）が、放送システム、インターネットシステム、及び／又は放送／インターネットコンバージェンス（ｃｏｎｖｅｒｇｅｎｃｅ）システムから送受信されることを意味することができる。サービス情報（ＳＩ）は、既存の放送システムから受信された放送サービス情報（例えば、ＡＴＳＣ−ＳＩ及び／又はＤＶＢ−ＳＩ）を含むことができる。

「放送信号」という用語は、地上波放送、ケーブル放送、衛星放送及び／又はモバイル放送から受信された信号及び／又はデータだけでなくインターネット放送、ブロードバンド放送、通信放送、データ放送及び／又はＶＯＤ（ＶｉｄｅｏＯｎＤｅｍａｎｄ）などの両方向放送システムから受信された信号及び／又はデータを概念的に含むことができる。

「ＰＬＰ」という用語は、物理層に含まれるデータを送信する所定の単位を示すことができる。したがって、「ＰＬＰ」という用語は、必要によって、「データユニット」又は「データパイプ」という用語に代えてもよい。

放送ネットワーク及び／又はインターネットネットワークと連動するように構成されるハイブリッド放送サービスは、デジタルテレビ（ＤＴＶ）サービスで使われる代表アプリケーションとして用いられてもよい。ハイブリッド放送サービスは、インターネットで地上波放送ネットワークを介して送信される放送Ａ／Ｖ（オーディオ／ビデオ）コンテンツに関連したエンハンスメントデータを実時間で送信し、インターネットで放送Ａ／Ｖコンテンツの一部を実時間で送信し、ユーザが様々なコンテンツを経験できるようにすることができる。

本発明は、ＩＰパケット、ＭＰＥＧ−２ＴＳパケット及び次世代デジタル放送システムで他の放送システムに適用可能なパケットをカプセル化し、ＩＰパケット、ＭＰＥＧ−２ＴＳパケット及びパケットが物理層に送信されるようにする方法を提供することを目標とする。また、本発明は、同じヘッダーフォーマットを用いてレイヤ２シグナリングを送信する方法を提案する。

次に説明するコンテンツは、装置によって具現することができる。例えば、次のプロセスを、シグナリングプロセッサ、プロトコルプロセッサ、プロセッサ及び／又はパケット生成器で行うことができる。

本発明で使用する用語のうち、リアルタイムサービス（ｒｅａｌｔｉｍｅ（ＲＴ）ｓｅｒｖｉｃｅ）は、言葉のとおり、実時間サービスを意味する。すなわち、時間に拘束されるサービスである。これに対し、ノンリアルタイムサービス（ｎｏｎ−ｒｅａｌｔｉｍｅ（ＮＲＴ）ｓｅｒｖｉｃｅ）は、ＲＴサービス以外の非実時間サービスを意味する。すなわち、非実時間サービスは、時間に拘束されないサービスである。そして、ＮＲＴサービスのためのデータをＮＲＴサービスデータと呼ぶものとする。

本発明に係る放送受信機は、地上波、ケーブル、インターネットなどのような媒体を介して非実時間（ＮＲＴ）サービスを受信することができる。ＮＲＴサービスは、放送受信機の保存媒体に保存された後、既に設定された時間又はユーザの要求によってディスプレイ装置に表示される。ＮＲＴサービスは、ファイル形態で受信されて保存媒体に保存されることを一実施例とする。保存媒体は、放送受信機の内部に装着された内蔵ＨＤＤであることを一実施例とする。他の例として、保存媒体は、放送受信システムの外部に連結されたＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）メモリ、外付けＨＤＤなどとしてもよい。ＮＲＴサービスを構成するファイルを受信して保存媒体に保存し、ユーザにサービスするためには、シグナリング情報が必要である。本発明は、これをＮＲＴサービスシグナリング情報又はＮＲＴサービスシグナリングデータと呼ぶものとする。本発明に係るＮＲＴサービスは、ＩＰデータグラムを得る方式によって、ＦｉｘｅｄＮＲＴサービスとＭｏｂｉｌｅＮＲＴサービスとに区別することができる。特にＦｉｘｅｄＮＲＴサービスは、固定型放送受信機に提供され、ＭｏｂｉｌｅＮＲＴサービスは、移動型放送受信機に提供される。本発明は、ＦｉｘｅｄＮＲＴサービスを一実施例として説明するものとする。しかし、本発明がＭｏｂｉｌｅＮＲＴサービスに適用されてもよいことは当然である。

本発明で使う用語のうち、アプリケーション（又は、同期化されたアプリケーション）は、視聴経験（ｖｉｅｗｉｎｇｅｘｐｅｒｉｅｎｃｅ）の向上のために、視聴者に両方向経験を提供するデータサービスである。アプリケーションは、ＴＤＯ（ＴｒｉｇｇｅｒｅｄＤｅｃｌａｒａｔｉｖｅＯｂｊｅｃｔ）、ＤＯ（ＤｅｃｌａｒａｔｉｖｅＯｂｊｅｃｔ）、又はＮＤＯ（ＮＲＴＤｅｃｌａｒａｔｉｖｅＯｂｊｅｃｔ）と命名することができる。

本発明で使う用語のうち、トリガー（Ｔｒｉｇｇｅｒ）は、シグナリングを識別し、アプリケーション又はアプリケーション内のイベントの提供時点を設定するシグナリングエレメント（ｓｉｇｎａｌｉｎｇｅｌｅｍｅｎｔ）である。トリガーは、ＴＰＴ（ＴＤＯｐａｒａｍｅｔｅｒｔａｂｌｅ）（又は、ＴＤＯｐａｒａｍｅｔｅｒｅｌｅｍｅｎｔとも呼ぶ。）の位置情報を含むことができる。ＴＰＴは、特定範囲内で、アプリケーションの動作のためのメタデータを含むシグナリングエレメントである。

トリガーは、タイムベーストリガー（ｔｉｍｅｂａｓｅｔｒｉｇｇｅｒ）及び／又はアクチベーショントリガー（ａｃｔｉｖａｔｉｏｎｔｒｉｇｇｅｒ）の役割を担うことができる。タイムベーストリガーは、イベントの再生時刻の基準を提示するタイムベースを設定するために用いられる。アクチベーショントリガーは、アプリケーション又はアプリケーション内に含まれたイベントの動作時刻を設定するために用いられる。ここで、動作は、アプリケーション又はアプリケーション内のイベントの開始、終了、中止（ｐａｕｓｅ）、ｋｉｌｌ及び／又はｒｅｓｕｍｅに該当し得る。タイムベースメッセージ（ｔｉｍｅｂａｓｅｍｅｓｓａｇｅｓ）がタイムベーストリガーとして用いられてもよく、タイムベーストリガーがタイムベースメッセージとして用いられてもよい。後述されるアクチベーションメッセージ（ａｃｔｉｖａｔｉｏｎｍｅｓｓａｇｅｓ）がアクチベーショントリガーとして用いられてもよく、アクチベーショントリガーがアクチベーションメッセージとして用いられてもよい。

メディアタイム（ＭｅｄｉａＴｉｍｅ）は、コンデンツ再生時に、特定の時点を参照するためのパラメータ（ｐａｒａｍｅｔｅｒ）である。

ＴＤＯ（ＴｒｉｇｇｅｒｅｄＤｅｃｌａｒａｔｉｖｅＯｂｊｅｃｔ）は、放送コンデンツ内の付加情報を示すものである。ＴＤＯは、付加情報を放送コンデンツ内でタイミングに合わせてトリガーする概念である。例えば、オーディションプログラムが放送される場合、視聴者が好むオーディション参加者の現在順位などを当該放送コンデンツと共に示すことができ、このオーディション参加者の現在順位などに関する付加情報がＴＤＯに当たる。このようなＴＤＯは、視聴者との両方向交信によって変更されてもよく、視聴者の意図を反映して提供されてもよい。

本発明の一実施例に係る送信装置及び方法は、地上波放送サービスのためのベースプロファイル、モバイル放送サービスのためのハンドヘルドプロファイル、及びＵＨＤＴＶサービスのためのアドバンスドプロファイルに分類される。この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方のためのプロファイルとして用いることができる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロフィルの概念を定義するために用いることができる。これは設計者の意図によって変更されてもよい。

本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−ＭｕｌｔｉｐｌｅＩｎｐｕｔＭｕｌｔｉｐｌｅＯｕｔｐｕｔ）又はＭＩＭＯ方式を用いて次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（ＭｕｌｔｉｐｌｅＩｎｐｕｔＳｉｎｇｌｅＯｕｔｐｕｔ）方式、ＳＩＳＯ（ＳｉｎｇｌｅＩｎｐｕｔＳｉｎｇｌｅＯｕｔｐｕｔ）方式などを含むことができる。

以下では、説明の便宜のために、ＭＩＳＯ又はＭＩＭＯ方式が２つのアンテナを用いるとするが、本発明は、２つ以上のアンテナを用いるシステムに適用されてもよい。

本発明は、特定の用途に要求される性能を達成しながら、受信機の複雑度を最小化するために、最適化された３つのフィジカルプロファイル（ＰＨＹｐｒｏｆｉｌｅ）（ベース（ｂａｓｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）、アドバンスド（ａｄｖａｎｃｅｄ）プロファイル）を定義することができる。フィジカルプロファイルは、該当する受信機が具現しなければならない全ての構造のサブセットである。

３つのフィジカルプロファイルは、大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータではやや異なる。後でフィジカルプロファイルがさらに定義されてもよい。システムの発展のために、ヒューチャプロファイルは、ＦＥＦ（ｆｕｔｕｒｅｅｘｔｅｎｓｉｏｎｆｒａｍｅ）を通じて単一ＲＦ（ｒａｄｉｏｆｒｅｑｕｅｎｃｙ）チャネルに存在するプロファイルとマルチプレクスされてもよい。各フィジカルプロファイルに関する詳細な内容は後述する。

１．ベースプロファイル
ベースプロファイルは主にループトップ（ｒｏｏｆ−ｔｏｐ）アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルはある場所に移動してもよいが、比較的停止した受信範ちゅうに属する携帯用装置も含むことができる。ベースプロファイルの用途は、若干の改善された実行によってハンドヘルド装置又は車両用に拡張されてもよいが、このような使用用途はベースプロファイル受信機動作では期待されない。

受信のターゲット信号対雑音比の範囲は略１０乃至２０ｄＢであるが、これは、既存放送システム（例えば、ＡＴＳＣＡ／５３）の１５ｄＢ信号対雑音比の受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを使用する、バッテリーで駆動するハンドヘルド装置におけるよりは重要でない。ベースプロファイルに対する重要システムパラメータが、下記の表１に記載されている。

２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリー電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。当該装置は歩行者又は車両の速度で移動することができる。受信機複雑度も消費電力も、共にハンドヘルドプロファイルの装置の具現のために非常に重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は、略０乃至１０ｄＢであるが、より低い室内受信のために意図された場合、０ｄＢ未満となるように設定されてもよい。

低い信号対雑音比能力だけでなく、受信機移動性によって現れたドップラー効果に対する復原力は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要システムパラメータが下記の表２に記載されている。

３．アドバンスドプロファイル
アドバンスドプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。当該プロファイルはＭＩＭＯ送信及び受信を用いることを要求し、ＵＨＤＴＶサービスはターゲット用途であり、そのために、当該プロファイルが特別に設計される。向上した能力は、与えられた帯域幅でサービス数の増加、例えば、複数のＳＤＴＶ又はＨＤＴＶサービスを許容するために用いることができる。

アドバンスドプロファイルのターゲット信号対雑音比の範囲は、略２０乃至３０ｄＢである。ＭＩＭＯ伝送は、初期には既存の楕円分極伝送装備を使用し、将来には全出力交差分極伝送へと拡張されてもよい。アドバンスドプロファイルに対する重要システムパラメータが下記の表３に記載されている。

この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方に対するプロファイルとして用いられてもよい。すなわち、ベースプロファイルを、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルに対するアドバンスドプロファイルとＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスドプロファイルとに区別することができる。そして、該当の３つのプロファイルは設計者の意図によって変更されてもよい。

次の用語及び定義を本発明に適用することができる。次の用語及び定義は、設計によって変更されてもよい。

補助ストリーム：ヒューチャエクステンション（ｆｕｔｕｒｅｅｘｔｅｎｓｉｏｎ、将来拡張）又は放送会社やネットワーク運営者によって要求されることによって用いられ得る、まだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス

ベースデータパイプ（ｂａｓｅｄａｔａｐｉｐｅ）：サービスシグナリングデータを伝達するデータパイプ

ベースバンドフレーム（又は、ＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合

セル（ｃｅｌｌ）：ＯＦＤＭ伝送の一つのキャリアによって伝達される変調値

コーディングブロック（ｃｏｄｅｄｂｌｏｃｋ）：ＰＬＳ１データのＬＤＰＣエンコードされたブロック又はＰＬＳ２データのＬＤＰＣエンコードされたブロックの一つ

データパイプ（ｄａｔａｐｉｐｅ）：一つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連したメタデータを伝達する物理層（ｐｈｙｓｉｃａｌｌａｙｅｒ）におけるロジカルチャネル

データパイプユニット（ＤＰＵ，ｄａｔａｐｉｐｅｕｎｉｔ）：データセルをフレームにおけるデータパイプに割り当て得る基本ユニット

データシンボル（ｄａｔａｓｙｍｂｏｌ）：プリアンブルシンボル以外のフレームにおけるＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（ｅｄｇｅ）シンボルはデータシンボルに含まれる。）

ＤＰ_ＩＤ：当該８ビットフィールドは、ＳＹＳＴＥＭ_ＩＤによって識別されたシステム内でデータパイプを唯一に識別する。

ダミーセル（ｄｕｍｍｙｃｅｌｌ）：ＰＬＳ（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｌｉｎｇ）シグナリング、データパイプ、又は補助ストリームのために用いられないで残っている容量を満たすために用いられる擬似ランダム値を伝達するセル

ＦＡＣ（ｅｍｅｒｇｅｎｃｙａｌｅｒｔｃｈａｎｎｅｌ、非常警報チャネル）：ＥＡＳ情報データを伝達するフレームの一部

フレーム（ｆｒａｍｅ）：プリアンブルによって始まってフレームエッジシンボルによって終了される物理層（ｐｈｙｓｉｃａｌｌａｙｅｒ）タイムスロット

フレームレピティションユニット（ｆｒａｍｅｒｅｐｅｔｉｔｉｏｎｕｎｉｔ；フレーム反復単位）：スーパーフレーム（ｓｕｐｅｒ−ｆｒａｍｅ）で８回反復されるＦＥＦを含む同一又は別個のフィジカルプロファイルに属するフレームの集合

ＦＩＣ（ｆａｓｔｉｎｆｏｒｍａｔｉｏｎｃｈａｎｎｅｌ；高速情報チャネル）：サービスと該当のベースデータパイプとのマッピング情報を伝達するフレームにおいてロジカルチャネル

ＦＥＣＢＬＯＣＫ：データパイプデータのＬＤＰＣエンコードされたビットの集合

ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同一である特定モードに用いられる名目上のＦＦＴサイズ

フレームシグナリングシンボル（ｆｒａｍｅｓｉｇｎａｌｉｎｇｓｙｍｂｏｌ）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、保護区間（ｇｕａｒｄｉｎｔｅｒｖａｌ）、及びスキャッタ（ｓｃａｔｔｅｒｅｄ）パイロットパターンの特定組合せにおいてフレームの先頭で用いられるより高いパイロット密度を有するＯＦＤＭシンボル

フレームエッジシンボル（ｆｒａｍｅｅｄｇｅｓｙｍｂｏｌ）：ＦＦＴサイズ、保護区間、及びスキャッタパイロットパターンの特定組合せにおいてフレームの終わりで用いられるより高いパイロット密度を有するＯＦＤＭシンボル

フレームグループ（ｆｒａｍｅ−ｇｒｏｕｐ）：スーパーフレームで同じフィジカルプロファイルタイプを有する全フレームの集合

ヒューチャエクステンションフレーム（ｆｕｔｕｒｅｅｘｔｅｎｔｉｏｎｆｒａｍｅ；将来拡張フレーム）：プリアンブルによって始まる、将来拡張に用いられ得るスーパーフレームにおける物理層（ｐｈｙｓｉｃａｌｌａｙｅｒ）タイムスロット

ヒューチャキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳ、ＩＰ（Ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ）、又は一般ストリームであり、出力がＲＦシグナルである、提案された物理層（ｐｈｙｓｉｃａｌｌａｙｅｒ）放送システム

インプットストリーム（ｉｎｐｕｔｓｔｒｅａｍ；入力ストリーム）：システムによって最終ユーザに伝達されるサービスの調和（ｅｎｓｅｍｂｌｅ）のためのデータのストリーム

ノーマル（ｎｏｒｍａｌ）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボル以外のデータシンボル

フィジカルプロファイル（ＰＨＹｐｒｏｆｉｌｅ）：該当する受信機が具現すべき全ての構造のサブセット

ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理層シグナリングデータ

ＰＬＳ１：ＰＬＳ２をデコードするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（ｆｒａｍｅｓｉｇｎａｌｌｉｎｇｓｙｍｂｏｌ）で伝達されるＰＬＳデータの一番目の集合

ＮＯＴＥ：ＰＬＳ１データがフレームグループのデューレーション（ｄｕｒａｔｉｏｎ）で一定である。

ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合

ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ；動的）データ：フレームごとにダイナミック（動的）に変化するＰＬＳ２データ

ＰＬＳ２スタティック（ｓｔａｔｉｃ；静的）データ：フレームグループのデューレーションでスタティック（静的）であるＰＬＳ２データ

プリアンブルシグナリングデータ（ｐｒｅａｍｂｌｅｓｉｇｎａｌｉｎｇｄａｔａ）：プリアンブルシンボルによって伝達され、システムの基本モードを確認するために用いられるシグナリングデータ

プリアンブルシンボル（ｐｒｅａｍｂｌｅｓｙｍｂｏｌ）：基本ＰＬＳデータを伝達し、フレームの先頭に位置する固定された長さのパイロットシンボル

ＮＯＴＥ：プリアンブルシンボルがシステム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に用いられる。

将来使用（ｆｕｔｕｒｅｕｓｅ）のためにリザーブド（ｒｅｓｅｒｖｅｄ）：現在文書で定義されないが、将来に定義されてもよい。

スーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）：８個のフレーム反復単位の集合

タイムインターリービングブロック（ｔｉｍｅｉｎｔｅｒｌｅａｖｉｎｇｂｌｏｃｋ；ＴＩｂｌｏｃｋ）：タイムインターリーバメモリの一つの用途に該当する、タイムインターリービングが実行されるセルの集合

タイムインターリービンググループ（ｔｉｍｅｉｎｔｅｒｌｅａｖｉｎｇｇｒｏｕｐ；ＴＩｇｒｏｕｐ）：整数、ダイナミック（動的）に変化するＸＦＥＣＢＬＯＣＫの数からなる、特定データパイプに対するダイナミック（動的）容量割り当てが実行される単位

ＮＯＴＥ：タイムインターリービンググループが一つのフレームに直接マップされたり、複数のフレームにマップされてもよい。これは一つ以上のタイムインターリービングブロックを含むことができる。

タイプ１データパイプ（Ｔｙｐｅ１ＤＰ）：全データパイプがフレームにＴＤＭ（ｔｉｍｅｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅｘｉｎｇ）方式でマップされるフレームのデータパイプ

タイプ２データパイプ（Ｔｙｐｅ２ＤＰ）：全データパイプがフレームにＦＤＭ方式でマップされるフレームのデータパイプ

ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣＦＥＣＢＬＯＣＫの全ビットを伝達するＮｃｅｌｌｓセルの集合

図１は、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す。

本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、入力フォーマットブロック１０００、ＢＩＣＭ（ｂｉｔｉｎｔｅｒｌｅａｖｅｄｃｏｄｉｎｇ＆ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレーム生成ブロック１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅｘｉｎｇ）生成ブロック１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各モジュールの動作について説明する。

ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳは、主要入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。それらのデータ入力に加えて、管理情報が入力され、各入力ストリームに対する該当の帯域幅のスケジューリング及び割り当てを制御する。一つ又は複数のＴＳストリーム、ＩＰストリーム及び／又は一般ストリーム入力が同時に許容される。

入力フォーマットブロック１０００は、それぞれの入力ストリームを、独立したコーディング及び変調が適用される一つ又は複数のデータパイプにデマルチプレクスすることができる。データパイプは、堅固性（ｒｏｂｕｓｔｎｅｓｓ）制御のための基本単位であり、これはＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）に影響を及ぼす。一つ又は複数のサービス又はサービスコンポーネントが一つのデータパイプによって伝達されてもよい。入力フォーマットブロック１０００の詳細な動作は後述する。

データパイプは、一つ又は複数のサービス又はサービスコンポーネントを伝達できるサービスデータ又は関連メタデータを伝達する物理層におけるロジカルチャネルである。

また、データパイプユニットは、一つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。

入力フォーマットブロック１０００で、パリティ（ｐａｒｉｔｙ）データは誤り訂正のために追加され、エンコードされたビットストリームは複素数値コンステレーションシンボルにマップされる。当該シンボルは該当のデータパイプに用いられる特定インターリービング深さにわたってインターリーブされる。アドバンスドプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ伝送のために出力に追加される。ＢＩＣＭブロック１０１０の詳細な動作は後述する。

フレーム生成ブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマップすることができる。マッピング後、周波数領域ダイバーシチのために、特に、周波数選択的フェージングチャネルを防止するために周波数インターリービングが用いられる。フレーム生成ブロック１０２０の詳細な動作は後述する。

プリアンブルを各フレームの先頭に挿入した後、ＯＦＤＭ生成ブロック１０３０は、サイクリックプレフィクス（ｃｙｃｌｉｃｐｒｅｆｉｘ）を保護区間として有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシチのために、分散された（ｄｉｓｔｒｉｂｕｔｅｄ）ＭＩＳＯ方式が送信機にわたって適用される。また、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅｐｏｗｅｒｒａｔｉｏ）方式が時間領域で実行される。柔軟なネットワーク方式のために、当該提案は様々なＦＦＴサイズ、保護区間の長さ、該当のパイロットパターンの集合を提供する。ＯＦＤＭ生成ブロック１０３０の詳細な動作は後述する。

シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層シグナリング情報を生成することができる。当該シグナリング情報はまた、関心のあるサービスが受信機側で適切に復旧されるように送信される。シグナリング生成ブロック１０４０の詳細な動作は後述する。

図２、図３、図４は、本発明の実施例に係る入力フォーマットブロック１０００を示す。各図について説明する。

図２は、本発明の一実施例に係る入力フォーマットブロックを示す。図２は、入力信号が単一入力ストリーム（ｓｉｎｇｌｅｉｎｐｕｔｓｔｒｅａｍ）であるときの入力フォーマットモジュールを示す。

図２に示す入力フォーマットブロックは、図１を参照して説明した入力フォーマットブロック１０００の一実施例に該当する。

物理層への入力は、一つ又は複数のデータストリームで構成される。それぞれのデータストリームは一つのデータパイプによって伝達される。モードアダプテーション（ｍｏｄｅａｄａｐｔａｉｏｎ；モード適応）モジュールは、入力されるデータストリームをＢＢＦ（ｂａｓｅｂａｎｄｆｒａｍｅ）のデータフィールドにスライスする。当該システムは３種類の入力データストリーム、すなわち、ＭＰＥＧ２−ＴＳ、ＩＰ、ＧＳ（ｇｅｎｅｒｉｃｓｔｒｅａｍ）を支援する。ＭＰＥＧ２−ＴＳは、最初のバイトが同期バイト（０ｘ４７）である固定された長さ（１８８バイト）のパケットを特徴とする。ＩＰストリームは、ＩＰパケットヘッダー内でシグナルされる可変長ＩＰデータグラムパケットで構成される。当該システムは、ＩＰストリームに対してＩＰｖ４、ＩＰｖ６の両方を支援する。ＧＳは、カプセル化パケットヘッダー内でシグナルされる可変長のパケット又は一定の長さのパケットで構成されてもよい。

（ａ）は、信号データパイプに対するモードアダプテーション（モード適応）ブロック２０００、及びストリームアダプテーション（ｓｔｒｅａｍａｄａｐｔａｔｉｏｎ；ストリーム適応）２０１０を示し、（ｂ）は、ＰＬＳデータを生成及び処理するためのＰＬＳ生成ブロック２０２０、及びＰＬＳスクランブラ２０３０を示す。各ブロックの動作について説明する。

入力ストリームスプリッタは、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。モードアダプテーション（モード適応）モジュール２０１０は、ＣＲＣエンコーダ、ＢＢ（ｂａｓｅｂａｎｄ）フレームスライサ、及びＢＢフレームヘッダー挿入ブロックで構成される。

ＣＲＣエンコーダは、ユーザパケットレベルでの誤り検出のための３種類のＣＲＣエンコーディング、すなわち、ＣＲＣ−８、ＣＲＣ−１６、ＣＲＣ−３２を提供する。算出されたＣＲＣバイトは、ユーザパケット後に付加される。ＣＲＣ−８はＴＳストリームに用いられ、ＣＲＣ−３２はＩＰストリームに用いられる。ＧＳストリームがＣＲＣエンコーディングを提供しない場合には、提案されたＣＲＣエンコーディングが適用されなければならない。

ＢＢフレームスライサは、入力を内部ロジカルビットフォーマットにマップする。最初の受信ビットはＭＳＢと定義する。ＢＢフレームスライサは、可用データフィールド容量と同数の入力ビットを割り当てる。ＢＢＦペイロードと同数の入力ビットを割り当てるために、ユーザパケットストリームがＢＢＦのデータフィールドに見合うようにスライスされる。

ＢＢフレームヘッダー挿入ブロックは、２バイトの固定された長さのＢＢＦヘッダーを、ＢＢフレームの前に挿入することができる。ＢＢＦヘッダーは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）、及びＲＦＵ（２ビット）で構成される。固定された２バイトＢＢＦヘッダーだけでなく、ＢＢＦは、２バイトＢＢＦヘッダーの終わりに拡張フィールド（１又は３バイト）を有することができる。

ストリームアダプテーション（ストリーム適応）２０１０は、スタッフィング（ｓｔｕｆｆｉｎｇ）挿入ブロック及びＢＢスクランブラで構成される。

スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリームアダプテーション（ストリーム適応）に対する入力データがＢＢフレームを満たすのに十分であれば、ＳＴＵＦＦＩは０に設定され、ＢＢＦはスタッフィングフィールドを有しない。そうでないと、ＳＴＵＦＦＩは１に設定され、スタッフィングフィールドはＢＢＦヘッダーの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダー及び可変サイズのスタッフィングデータを含む。

ＢＢスクランブラは、エネルギー分散のために完全なＢＢＦをスクランブルする。スクランブリングシーケンスはＢＢＦと同期化される。スクランブリングシーケンスはフィードバックシフトレジスターによって生成される。

ＰＬＳ生成ブロック２０２０は、ＰＬＳデータを生成することができる。ＰＬＳは、受信機にフィジカルレイヤ（ｐｈｙｓｉｃａｌｌａｙｅｒ）データパイプに接続できる手段を提供する。ＰＬＳデータはＰＬＳ１データ及びＰＬＳ２データで構成される。

ＰＬＳ１データは、ＰＬＳ２データをデコードするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームでＦＳＳで伝達されるＰＬＳデータの一番目の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするために要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグループのデューレーションにおいて一定である。

ＰＬＳ２データは、データパイプ及びシステムに関するさらに詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコードする上で十分な情報を提供するパラメータを含む。ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（静的）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２ダイナミック（動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータでさらに構成される。ＰＬＳ２スタティック（静的）データは、フレームグループのデューレーションでスタティック（静的）であるＰＬＳ２データであり、ＰＬＳ２ダイナミック（動的）データは、フレームごとにダイナミック（動的）に変化するＰＬＳ２データである。

ＰＬＳデータに関する詳細な内容は後述する。

ＰＬＳスクランブラ２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブルすることができる。

前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。

図３は、本発明の他の実施例に係る入力フォーマットブロックを示す。

図３に示す入力フォーマットブロックは、図１を参照して説明した入力フォーマットブロック１０００の一実施例に該当する。

図３は、入力信号がマルチインプットストリーム（ｍｕｌｔｉｉｎｐｕｔｓｔｒｅａｍ；複数の入力ストリーム）に該当する場合、入力フォーマットブロックのモードアダプテーション（モード適応）ブロックを示す。

マルチインプットストリーム（複数の入力ストリーム）を処理するための入力フォーマットブロックのモードアダプテーション（モード適応）ブロックは、複数の入力ストリームを独立して処理することができる。

図３を参照すると、マルチインプットストリーム（複数の入力ストリーム）をそれぞれ処理するためのモードアダプテーション（モード適応）ブロックは、入力ストリームスプリッタ３０００、入力ストリームシンクロナイザ３０１０、コンペンセーティングディレイ（ｃｏｍｐｅｎｓａｔｉｎｇｄｅｌａｙ；補償遅延）ブロック３０２０、ヌルパケット削除ブロック３０３０、ヘッダー圧縮ブロック３０４０、ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０、及びＢＢヘッダー挿入ブロック３０７０を含むことができる。モードアダプテーション（モード適応）ブロックの各ブロックについて説明する。

ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０、及びＢＢヘッダー挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサ、及びＢＢヘッダー挿入ブロックの動作に該当するので、その説明は省略する。

入力ストリームスプリッタ３０００は、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。

入力ストリームシンクロナイザ３０１０は、ＩＳＳＹと呼ぶことができる。ＩＳＳＹは、いかなる入力データフォーマットに対しても、ＣＢＲ（ｃｏｎｓｔａｎｔｂｉｔｒａｔｅ）及び一定の終端間伝送（ｅｎｄ−ｔｏ−ｅｎｄｔｒａｎｓｍｉｓｓｉｏｎ）遅延を保障するに適した手段を提供することができる。ＩＳＳＹは、ＴＳを伝達する複数のデータパイプの場合に常に用いられ、ＧＳストリームを伝達する複数のデータパイプに選択的に用いられる。

コンペンセーティングディレイ（補償遅延）ブロック３０２０は、受信機でさらにメモリを必要とせずにＴＳパケット再結合メカニズムを許容するために、ＩＳＳＹ情報の挿入に続く分割されたＴＳパケットストリームを遅延させることができる。

ヌルパケット削除ブロック３０３０は、ＴＳ入力ストリームの場合にのみ用いられる。一部のＴＳ入力ストリーム又は分割されたＴＳストリームは、ＶＢＲ（ｖａｒｉａｂｌｅｂｉｔ−ｒａｔｅ）サービスをＣＢＲＴＳストリームに収容するために、存在する多数のヌルパケットを有することができる。この場合、不要な伝送オーバーヘッドを避けるために、ヌルパケットは確認されて伝送されなくてもよい。受信機で、除去されたヌルパケットは、伝送に挿入されたＤＮＰ（ｄｅｌｅｔｅｄｎｕｌｌ−ｐａｃｋｅｔ；削除されたヌルパケット）カウンタを参照して元の正確な場所に再挿入可能であるため、ＣＢＲが保障され、タイムスタンプ（ＰＣＲ）更新が不要になる。

ヘッダー圧縮ブロック３０４０は、ＴＳ又はＩＰ入力ストリームに対する伝送効率を増加させるために、パケットヘッダー圧縮を提供することができる。受信機は、ヘッダーの特定部分に対する先験的な（ａｐｒｉｏｒｉ）情報を有することができるため、この知られた情報は送信機で削除されてもよい。

ＴＳに対して、受信機は同期バイト構成（０ｘ４７）及びパケット長（１８８バイト）に関する先験的な情報を有することができる。入力されたＴＳが一つのＰＩＤだけを有するコンデンツを伝達すると、すなわち、一つのサービスコンポーネント（ビデオ、オーディオなど）又はサービスサブコンポーネント（ＳＶＣベースレイヤ、ＳＶＣエンハンスメントレイヤ、ＭＶＣベースビュー、又はＭＶＣ依存ビュー）に対してのみ、ＴＳパケットヘッダー圧縮がＴＳに（選択的に）適用されてもよい。ＴＳパケットヘッダー圧縮は、入力ストリームがＩＰストリームである場合に選択的に用いられる。

上記のブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。

図４は本発明の他の実施例に係る入力フォーマットブロックを示す。

図４に示す入力フォーマットブロックは、図１を参照して説明した入力フォーマットブロック１０００の一実施例に該当する。

図４は、入力信号がマルチインプットストリーム（複数の入力ストリーム）に該当する場合、入力フォーマットモジュールのストリームアダプテーション（ストリーム適応）ブロックを示す。

図４を参照すると、マルチインプットストリーム（複数の入力ストリーム）をそれぞれ処理するためのモードアダプテーション（モード適応）ブロックは、スケジューラ４０００、１−フレームディレイ（ｄｅｌａｙ）ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンド（Ｉｎ−ｂａｎｄ）シグナリングブロック４０３０、ＢＢフレームスクランブラ４０４０、ＰＬＳ生成ブロック４０５０、ＰＬＳスクランブラ４０６０を含むことができる。ストリームアダプテーション（ストリーム適応）ブロックの各ブロックについて説明する。

スタッフィング挿入ブロック４０２０、ＢＢフレームスクランブラ４０４０、ＰＬＳ生成ブロック４０５０、ＰＬＳスクランブラ４０６０の動作は、図２を参照して説明したスタッフィング挿入ブロック、ＢＢスクランブラ、ＰＬＳ生成ブロック、ＰＬＳスクランブラ４０６０の動作に該当するので、その説明は省略する。

スケジューラ４０００は、各データパイプのＦＥＣＢＬＯＣＫの量から全体フレームにわたって全体のセル割り当てを決定することができる。ＰＬＳ、ＥＡＣ及びＦＩＣに対する割り当てを含めて、スケジューラは、フレームのＦＳＳのＰＬＳセル又はインバンド（Ｉｎ−ｂａｎｄ）シグナリングで伝送されるＰＬＳ２−ＤＹＮデータの値を生成する。ＦＥＣＢＬＯＣＫ、ＥＡＣ、ＦＩＣに関する詳細な内容は後述する。

１−フレームディレイブロック４０１０は、次のフレームに関するスケジューリング情報が、データパイプに挿入されるインバンド（Ｉｎ−ｂａｎｄ）シグナリング情報に関する現フレームを介して伝送され得るように、入力データを一つの伝送フレームだけ遅延させることができる。

インバンド（Ｉｎ−ｂａｎｄ）シグナリングブロック４０３０は、ＰＬＳ２データの遅延されない部分をフレームのデータパイプに挿入することができる。

図５は、本発明の一実施例に係るＢＩＣＭブロックを示す。

図５に示すＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。

前述したように、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。

ＱｏＳが本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するので、それぞれのサービスに該当するデータは別個の方式で処理されなければならない。したがって、本発明の一実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式をそれぞれのデータ経路に該当するデータパイプに独立して適用することによって、そこに入力されるデータパイプを独立して処理することができる。結果的に、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、それぞれのデータパイプを通じて伝送される各サービス又はサービスコンポーネントに対するＱｏＳを調節することができる。

（ａ）は、ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロックを示し、（ｂ）は、アドバンスドプロファイルのＢＩＣＭブロックを示す。

ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロック及びアドバンスドプロファイルのＢＩＣＭブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。

ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロック及びアドバンスドプロファイルに対するＢＩＣＭブロックのそれぞれの処理ブロックについて説明する。

ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー（ｍａｐｐｅｒ）５０３０、ＳＳＤ（ｓｉｇｎａｌｓｐａｃｅｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、タイムインターリーバ５０５０を含むことができる。

データＦＥＣエンコーダ５０１０は、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の具体的な動作については後述する。

ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながら、データＦＥＣエンコーダ５０１０の出力をインターリーブし、ＬＤＰＣコード及び変調方式の組合せによって最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作については後述する。

コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）又は不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いてベース及びハンドヘルドプロファイルでビットインターリーバ５０２０からのそれぞれのセルワードを変調したり、アドバンスドプロファイルでセルワードデマルチプレクサ５０１０−１からのセルワードを変調し、電力の正規化されたコンステレーションポイントｅ_lを提供することができる。当該コンステレーションマッピングは、データパイプに対してのみ適用される。ＮＵＱが任意の形態を有するのに対し、ＱＡＭ−１６及びＮＵＱは正方形を有することが観察される。それぞれのコンステレーションが９０度の倍数だけ回転されると、回転されたコンステレーションは元のものと正確に重なる。回転対称特性によって失敗及び虚数コンポーネントの容量及び平均電力が互いに同一となる。ＮＵＱ及びＮＵＣはいずれも各コードレート（ｃｏｄｅｒａｔｅ）に対して特別に定義され、用いられる特定の一つは、ＰＬＳ２データに保管されたパラメータＤＰ_ＭＯＤによってシグナルされる。

ＳＳＤエンコーディングブロック５０４０は、２次元、３次元、４次元でセルをプリコードし、劣悪なフェージング条件で受信堅固性（ｒｏｂｕｓｔｎｅｓｓ）を増加させることができる。

タイムインターリーバ５０５０はデータパイプレベルで動作することができる。タイムインターリービングのパラメータはそれぞれのデータパイプに対して別々に設定されてもよい。タイムインターリーバ５０５０の具体的な動作に関しては後述する。

アドバンスドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、及びタイムインターリーバを含むことができる。ただし、処理ブロック５０００−１は、セルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含むという点で処理ブロック５０００と区別される。

また、処理ブロック５０００−１におけるデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、タイムインターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。

セルワードデマルチプレクサ５０１０−１は、アドバンスドプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離するために用いられる。セルワードデマルチプレクサ５０１０−１の具体的な動作に関しては後述する。

ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号の送信のために最適化されている。ＭＩＭＯ技術は容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に放送に対して、別個の信号伝播特性による両アンテナ間の受信信号電力差又はチャネルの強いＬＯＳコンポーネントは、ＭＩＭＯから容量利得を得ることを困難にさせる。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの一つの位相ランダム化及び回転ベースプリコーディングを用いてこの問題を克服する。

ＭＩＭＯエンコーディングは、送信機及び受信機の両方で少なくとも２つのアンテナを必要とする２ｘ２ＭＩＭＯシステムのために意図される。２つのＭＩＭＯエンコーディングモードは、本提案であるＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅｓｐａｔｉａｌｍｕｌｔｉｐｌｅｘｉｎｇ）及びＦＲＦＤ−ＳＭ（ｆｕｌｌ−ｒａｔｅｆｕｌｌ−ｄｉｖｅｒｓｉｔｙｓｐａｔｉａｌｍｕｌｔｉｐｌｅｘｉｎｇ）で定義される。ＦＲ−ＳＭエンコーディングは、受信機側での比較的小さい複雑度の増加から容量増加を提供するが、ＦＲＦＤ−ＳＭエンコーディングは、受信機側での大きい複雑度の増加から容量増加及び追加的なダイバーシチ利得を提供する。提案されたＭＩＭＯエンコーディング方式は、アンテナ極性配置を制限しない。

ＭＩＭＯ処理はアドバンスドプロファイルフレームに要求されるが、これは、アドバンスドプロファイルフレームにおける全てのデータパイプがＭＩＭＯエンコーダによって処理されるということを意味する。ＭＩＭＯ処理はデータパイプレベルで適用される。コンステレーションマッパー出力のペア（ｐａｉｒ；対）であるＮＵＱ（ｅ_1,i及びｅ_2,i）は、ＭＩＭＯエンコーダの入力として供給される。ＭＩＭＯエンコーダ出力ペア（対）（ｇ_1,i及びｇ_2,i）は、それぞれの送信アンテナの同一キャリアｋ及びＯＦＤＭシンボルｌによって送信される。

図６は、本発明の他の実施例に係るＢＩＣＭブロックを示す。

図６に示すＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。

図６は、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報データを伝達するフレームの一部であり、ＦＩＣは、サービスと該当するベースデータパイプとの間でマッピング情報を伝達するフレームにおけるロジカルチャネルである。ＥＡＣ及びＦＩＣに関する詳細な説明は後述する。

図６を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパー６０２０を含むことができる。

また、ＰＬＳＦＥＣエンコーダ６０００は、スクランブラ、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）ブロックを含むことができる。ＢＩＣＭブロックの各ブロックについて説明する。

ＰＬＳＦＥＣエンコーダ６０００は、スクランブルされたＰＬＳ１／２データ、ＥＡＣ及びＦＩＣセクションをエンコードすることができる。

スクランブラは、ＢＣＨエンコーディング及びショートニング（ｓｈｏｒｔｅｎｉｎｇ）及びパンクチャされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブルすることができる。

ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いて、スクランブルされたＰＬＳ１／２データに外部エンコーディングを行い、ＢＣＨエンコーディングの後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ゼロ挿入の出力ビットをＬＤＰＣエンコーディングの前にパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）することができる。

ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコードすることができる。完全なコーディングブロックを生成するために、Ｃ_ldpc及びパリティビットＰ_ldpcは、それぞれのゼロが挿入されたＰＬＳ情報ブロックＩ_ldpcから組織的にエンコードされ、その後に付加される。

ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の表４のとおりである。

ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。

ショートニングがＰＬＳ１データ保護に適用されると、一部のＬＤＰＣパリティビットはＬＤＰＣエンコーディング後にパンクチャされる。また、ＰＬＳ２データ保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディング後にパンクチャされる。それらのパンクチャされたビットは伝送されない。

ビットインターリーバ６０１０は、それぞれのショートニング及びパンクチャされたＰＬＳ１データ及びＰＬＳ２データをインターリーブすることができる。

コンステレーションマッパー６０２０は、ビットインターリーブされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマップすることができる。

図７は、本発明の一実施例に係るフレーム生成ブロックを示す。

図７に示すフレーム生成ブロックは、図１を参照して説明したフレーム生成ブロック１０２０の一実施例に該当する。

図７を参照すると、フレーム生成ブロックは、ディレイコンペセーション（ｄｅｌａｙｃｏｍｐｅｎｓａｔｉｏｎ；遅延補償）ブロック７０００、セルマッパー７０１０、及び周波数インターリーバ７０２０を含むことができる。フレーム生成ブロックの各ブロックに関し説明する。

ディレイコンペセーション（遅延補償）ブロック７０００は、データパイプと該当するＰＬＳデータとの間のタイミングを調節し、送信機側でそれらの同時性を保障することができる。入力フォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことによって、ＰＬＳデータはデータパイプだけ遅延される。ＢＩＣＭブロックの遅延は主にタイムインターリーバ５０５０に起因する。インバンド（Ｉｎ−ｂａｎｄ）シグナリングデータは、次のタイムインターリービンググループの情報を、シグナルされるデータパイプよりも１フレーム先に伝達されるようにすることができる。ディレイコンペセーション（遅延補償）ブロックは、それに応じてインバンド（Ｉｎ−ｂａｎｄ）シグナリングデータを遅延させる。

セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルを、フレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップすることができる。セルマッパー７０１０の基本機能は、それぞれのデータパイプ、ＰＬＳセル、及びＥＡＣ／ＦＩＣセルに対するタイムインターリービングによって生成されたデータセルを、存在するなら、一つのフレーム内でそれぞれのＯＦＤＭシンボルに該当するアクティブ（ａｃｔｉｖｅ）ＯＦＤＭセルのアレイにマップすることである。（ＰＳＩ（ｐｒｏｇｒａｍｓｐｅｃｉｆｉｃｉｎｆｏｒｍａｔｉｏｎ）／ＳＩのような）サービスシグナリングデータは個別的に収集され、データパイプによって送られてもよい。セルマッパーは、フレーム構造の構成及びスケジューラによって生成されたダイナミックインフォメーション（ｄｙｎａｍｉｃｉｎｆｏｒｍａｔｉｏｎ；動的情報）によって動作する。フレームに関する詳細な内容は後述する。

周波数インターリーバ７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリーブして周波数ダイバーシチを提供することができる。また、周波数インターリーバ７０２０は、単一フレームで最大のインターリービング利得を得るために、他のインターリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（対）で動作することができる。

図８は、本発明の一実施例に係るＯＦＤＭ生成ブロックを示す。

図８に示すＯＦＤＭ生成ブロックは、図１を参照して説明したＯＦＤＭ生成ブロック１０３０の一実施例に該当する。

ＯＦＤＭ生成ブロックは、フレーム生成ブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは、順次に保護区間を挿入し、ＰＡＰＲ減少処理を適用して最終ＲＦ信号を生成する。

図８を参照すると、フレーム生成ブロックは、パイロット及びリザーブドトーン（ｒｅｓｅｒｖｅｄｔｏｎｅ）挿入ブロック８０００、２Ｄ−ｅＳＦＮ（ｓｉｎｇｌｅｆｒｅｑｕｅｎｃｙｎｅｔｗｏｒｋ）エンコーディングブロック８０１０、ＩＦＦＴ（ｉｎｖｅｒｓｅｆａｓｔＦｏｕｒｉｅｒｔｒａｎｓｆｏｒｍ）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、保護区間挿入ブロック８０４０、プリアンブル挿入ブロック８０５０、その他システム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。フレーム生成ブロックの各ブロックについて説明する。

パイロット及びリザーブドトーン挿入ブロック８０００は、パイロット及びリザーブドトーンを挿入することができる。

ＯＦＤＭシンボル内の様々なセルは、受信機で先験的に知られた送信された値を有するパイロットとして知られた参照情報に変調される。パイロットセルの情報は、分散パイロット、連続パイロット、エッジパイロット、ＦＳＳ（ｆｒａｍｅｓｉｇｎａｌｌｉｎｇｓｙｍｂｏｌ）パイロット、及びＦＥＳ（ｆｒａｍｅｅｄｇｅｓｙｍｂｏｌ）パイロットで構成される。各パイロットは、パイロットタイプ及びパイロットパターンによって特定の増加電力レベルで送信される。パイロット情報の値は、与えられたシンボルで一つがそれぞれの伝送キャリアに対するものである一連の値に該当する参照シーケンスから誘導される。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャネル推定、伝送モード識別のために用いられてもよく、さらに、位相雑音を追跡するために用いられてもよい。

参照シーケンスから取った参照情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳ以外の全シンボルにおいて分散パイロットセルで送信される。連続パイロットは、フレームの全シンボルに挿入される。連続パイロットの数及び位置はＦＦＴサイズ及び分散パイロットパターンにいずれも依存する。エッジキャリアは、プリアンブルシンボル以外の全シンボルでエッジパイロットである。これらは、スペクトルのエッジまで周波数インターポレーション（ｉｎｔｅｒｐｏｌａｔｉｏｎ；補間）を許容するために挿入される。ＦＳＳパイロットはＦＳＳに挿入され、ＦＥＳパイロットはＦＥＳに挿入される。それらはフレームのエッジまで時間インターポレーション（補間）を許容するために挿入される。

本発明の一実施例に係るシステムは、非常に堅固な伝送モードを支援するために、分散ＭＩＳＯ方式が選択的に用いられるＳＦＮを支援する。２Ｄ−ｅＳＦＮは、それぞれがＳＦＮで他の送信機位置にある複数の送信アンテナを用いる分散ＭＩＳＯ方式である。

２Ｄ−ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシチを生成するために２Ｄ−ｅＳＦＮ処理をし、複数の送信機から送信された信号の位相を歪ませることができる。したがって、長時間の低い平面フェージング又は深いフェージングによるバースト誤りが軽減する。

ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ−ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロット（又は、リザーブドトーン）として指定されていないデータシンボルにおける全セルは、周波数インターリーバからのデータセルのうち一つを伝達する。これらのセルはＯＦＤＭキャリアにマップされる。

ＰＡＰＲ減少ブロック８０３０は、時間領域で様々なＰＡＰＲ減少アルゴリズムを用いて入力信号にＰＡＰＲ減少を実行する。

保護区間挿入ブロック８０４０は保護区間を挿入することができ、プリアンブル挿入ブロック８０５０は、信号の前にプリアンブルを挿入することができる。プリアンブルの構造に関する詳細な内容は後述する。その他、システム挿入ブロック８０６０は、放送サービスを提供する２つ以上の別個の放送送信／受信システムのデータが同一のＲＦ信号帯域で同時に伝送され得るように、時間領域で複数の放送送信／受信システムの信号をマルチプレクスすることができる。ここで、２つ以上の別個の放送送信／受信システムとは、別個の放送サービスを提供するシステムのことをいう。別個の放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。それぞれの放送サービスに関連したデータは別個のフレームで伝送されてもよい。

ＤＡＣブロック８０７０は、入力されたデジタル信号をアナログ信号に変換して出力することができる。ＤＡＣブロック８０７０から出力された信号は、物理層プロファイルによって複数の出力アンテナから伝送されてもよい。本発明の一実施例に係る送信アンテナは、垂直又は水平の極性を有することができる。

前述したブロックは、設計によって省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。

図９は、本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す。

本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応し得る。

本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール９０００、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０、及びシグナリングデコーディングモジュール９０４０を含むことができる。放送信号受信装置の各モジュールの動作について説明する。

同期及び復調モジュール９０００は、ｍ個の受信アンテナを通じて入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置によって実行される手順の逆手順に該当する復調を実行することができる。

フレームパーシングモジュール９０１０は、入力信号フレームをパースし、ユーザによって選択されたサービスが伝送されるデータを抽出することができる。放送信号送信装置がインターリービングを実行すると、フレームパーシングモジュール９０１０は、インターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されるべき信号及びデータの位置がシグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって取得され、放送信号送信装置によって生成されたスケジューリング情報を復元することができる。

デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によって、それをデインターリーブすることができる。デマッピング及びデコーディングモジュール９０２０は、伝送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングを通じて伝送チャネルで発生した誤りを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって、デマッピング及びデコーディングのために必要な伝送パラメータを取得することができる。

出力プロセッサ９０３０は、伝送効率を向上させるために、放送信号送信装置によって適用される様々な圧縮／信号処理手順の逆手順を実行することができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータで必要な制御情報を取得することができる。出力プロセッサ９０３０の出力は、放送信号送信装置に入力される信号に該当し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４又はｖ６）及びＧＳであってもよい。

シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００によって復調された信号からＰＬＳ情報を取得することができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。

図１０は、本発明の一実施例に係るフレーム構造を示す。

図１０は、フレームタイムの構成例及びスーパーフレームにおけるＦＲＵ（ｆｒａｍｅｒｅｐｅｔｉｔｉｏｎｕｎｉｔ；フレーム反復単位）を示す。（ａ）は、本発明の一実施例に係るスーパーフレームを示し、（ｂ）は、本発明の一実施例に係るＦＲＵを示し、（ｃ）は、ＦＲＵにおける様々なフィジカルプロファイル（ＰＨＹｐｒｏｆｉｌｅ）のフレームを示し、（ｄ）は、フレームの構造を示す。

スーパーフレームは８個のＦＲＵを含むことができる。ＦＲＵは、フレームのＴＤＭに対する基本マルチプレクシング単位であり、スーパーフレームで８回反復される。

ＦＲＵにおいて各フレームはフィジカルプロファイル（ベース、ハンドヘルド、アドバンスドプロファイル）のいずれか一つ又はＦＥＦに属する。ＦＲＵにおいてフレームの最大許容数は４であり、与えられたフィジカルプロファイルは、ＦＲＵにおいて０回乃至４回の回数を有することができる（例えば、ベース、ベース、ハンドヘルド、アドバンスド）。フィジカルプロファイル定義は、必要時には、プリアンブルにおけるＰＨＹ_ＰＲＯＦＩＬＥのリザーブド値を用いて拡張されてもよい。

ＦＥＦ部分は、含まれるなら、ＦＲＵの終わりに挿入される。ＦＥＦがＦＲＵに含まれる場合、ＦＥＦの最大数はスーパーフレームにおいて８である。ＦＥＦ部分が互いに隣接することは推奨されない。

一つのフレームは、複数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に示すように、フレームは、プリアンブル、一つ以上のＦＳＳ、ノーマルデータシンボル、ＦＥＳを含む。

プリアンブルは、高速ヒューチャキャストＵＴＢシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルに関する詳細な内容は後述する。

ＦＳＳの主な目的は、ＰＬＳデータを伝達することである。高速同期化及びチャネル推定のために、これによるＰＬＳデータの高速デコーディングのために、ＦＳＳは、ノーマルデータシンボルに比べてより高密度のパイロットパターンを有する。ＦＥＳはＦＳＳと全く同じパイロットを有するが、これは、ＦＥＳ直前のシンボルに対して外挿（ｅｘｔｒａｐｏｌａｔｉｏｎ）無しで、ＦＥＳ内における周波数だけのインターポレーション（補間）及び時間的補間（ｔｅｍｐｏｒａｌｉｎｔｅｒｐｏｌａｔｉｏｎ）を可能にする。

図１１は、本発明の一実施例に係るフレームのシグナリング階層構造を示す。

図１１は、シグナリング階層構造を示すが、これは、３個の主要部分であるプリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０、及びＰＬＳ２データ１１０２０に分割される。毎フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータ及び伝送タイプを示すことである。ＰＬＳ１は、受信機が関心のあるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコーティング可能にさせる。ＰＬＳ２は毎フレームごとに伝達され、２つの主要部分であるＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータとに分割される。ＰＬＳ２データのスタティック（静的）及びダイナミック（動的）部分には必要時にパディングが続く。

図１２は、本発明の一実施例に係るプリアンブルシグナリングデータを示す。

プリアンブルシグナリングデータは、受信機がフレーム構造内でＰＬＳデータに接続し、データパイプを追跡できるようにするために必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータに関する詳細な内容は、次のとおりである。

ＰＨＹ_ＰＲＯＦＩＬＥ：当該３ビットフィールドは、現フレームのフィジカルプロファイルタイプを示す。各フィジカルプロファイルタイプのマッピングは、下記の表５のように与えられる。

ＦＦＴ_ＳＩＺＥ：当該２ビットフィールドは、下記の表６で説明したとおり、フレームグループ内で現フレームのＦＦＴサイズを示す。

ＧＩ_ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、下記の表７で説明したとおり、現スーパーフレームにおける保護区間一部（ｆｒａｃｔｉｏｎ）値を示す。

ＥＡＣ_ＦＬＡＧ：当該１ビットフィールドは、ＥＡＣが現フレームで提供されるか否かを示す。当該フィールドが１に設定されると、ＥＡＳが現フレームで提供される。当該フィールドが０に設定されると、ＥＡＳが現フレームで伝達されない。当該フィールドはスーパーフレーム内でダイナミック（動的）に転換されてもよい。

ＰＩＬＯＴ_ＭＯＤＥ：当該１ビットフィールドは、現フレームグループで現フレームに対してパイロットモードがモバイルモードなのか又は固定モードなのかを示す。当該フィールドが０に設定されると、モバイルパイロットモードが用いられる。当該フィールドが１に設定されると、固定パイロットモードが用いられる。

ＰＡＰＲ_ＦＬＡＧ：当該１ビットフィールドは、現フレームグループで現フレームに対してＰＡＰＲ減少が用いられるか否かを示す。当該フィールドが１に設定されると、トーン予約（ｔｏｎｅｒｅｓｅｒｖａｔｉｏｎ）がＰＡＰＲ減少のために用いられる。当該フィールドが０に設定されると、ＰＡＰＲ減少が用いられない。

ＦＲＵ_ＣＯＮＦＩＧＵＲＥ：当該３ビットフィールドは、現スーパーフレームで存在するＦＲＵのフィジカルプロファイルタイプ構成を示す。現スーパーフレームで全プリアンブルにおける当該フィールドにおいて、現スーパーフレームで伝達される全プロファイルタイプが識別される。当該３ビットフィールドは、下記の表８に示すように、それぞれのプロファイルに対して別々に定義される。

ＲＥＳＥＲＶＥＤ：当該７ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。

図１３は、本発明の一実施例に係るＰＬＳ１データを示す。

ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするために必要なパラメータを含む基本伝送パラメータを提供する。前述したように、ＰＬＳ１データは、一つのフレームグループの全デューレーションで変化しない。ＰＬＳ１データのシグナリングフィールドの具体的な定義は次のとおりである。

ＰＲＥＡＭＢＬＥ_ＤＡＴＡ：当該２０ビットフィールドは、ＥＡＣ_ＦＬＡＧ以外のプリアンブルシグナリングデータのコピーである。

ＮＵＭ_ＦＲＡＭＥ_ＦＲＵ：当該２ビットフィールドは、ＦＲＵ当たりのフレーム数を示す。

ＰＡＹＬＯＡＤ_ＴＹＰＥ：当該３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ_ＴＹＰＥは、表９に示すようにシグナルされる。

ＮＵＭ_ＦＳＳ：当該２ビットフィールドは、現フレームでＦＳＳの数を示す。

ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮ：当該８ビットフィールドは、伝送される信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮは、主バージョン及び副バージョンの２つの４ビットフィールドに分離される。

主バージョン：ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮフィールドのＭＳＢである４ビットは、主バージョン情報を示す。主バージョンフィールドにおける変化は、互換が不可能な変化を示す。デフォルト値は００００である。当該標準で述べているバージョンに対して、値が００００に設定される。

副バージョン：ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮフィールドのＬＳＢである４ビットは、副バージョン情報を示す。副バージョンフィールドにおける変化は、互換が可能である。

ＣＥＬＬ_ＩＤ：これは、ＡＴＳＣネットワークで地理的セルを唯一に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジは、ヒューチャキャストＵＴＢシステム当たりに用いられる周波数の数によって一つ以上の周波数で構成されてもよい。ＣＥＬＬ_ＩＤの値が知られないか又は特定されないと、当該フィールドは０に設定される。

ＮＥＴＷＯＲＫ_ＩＤ：これは、現ＡＴＳＣネットワークを唯一に識別する１６ビットフィールドである。

ＳＹＳＴＥＭ_ＩＤ：該当１６ビットフィールドは、ＡＴＳＣネットワーク内でヒューチャキャストＵＴＢシステムを唯一に識別する。ヒューチャキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。ヒューチャキャストＵＴＢシステムは、存在するなら、ＦＥＦ及び一つ以上のフィジカルプロファイルを伝達する。同じヒューチャキャストＵＴＢシステムは、別個の入力ストリームを伝達し、別個の地理的領域で別個のＲＦを用いることができ、ローカルサービス挿入を許容する。フレーム構造及びスケジューリングは一つの場所で制御され、ヒューチャキャストＵＴＢシステム内で全ての伝送に対して同一である。一つ以上のヒューチャキャストＵＴＢシステムはいずれも同一のフィジカル構造及び構成を有するという同一のＳＹＳＴＥＭ_ＩＤ意味を有することができる。

次のループ（ｌｏｏｐ）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ_ＰＨＹ_ＰＲＯＦＩＬＥ、ＦＲＵ_ＦＲＡＭＥ_ＬＥＮＧＴＨ、ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮ、ＲＥＳＥＲＶＥＤで構成される。ループ（ｌｏｏｐ）サイズは、ＦＲＵ内で４個のフィジカルプロファイル（ＦＥＦを含む）がシグナルされるように固定される。ＮＵＭ_ＦＲＡＭＥ_ＦＲＵが４よりも小さいと、用いられないフィールドはゼロで埋められる。

ＦＲＵ_ＰＨＹ_ＰＲＯＦＩＬＥ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレーム（ｉはループ（ｌｏｏｐ）インデックス）のフィジカルプロファイルタイプを示す。当該フィールドは表８に示すものと同じシグナリングフォーマットを用いる。

ＦＲＵ_ＦＲＡＭＥ_ＬＥＮＧＴＨ：当該２ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮと共にＦＲＵ_ＦＲＡＭＥ_ＬＥＮＧＴＨを用いると、フレームデューレーションの正確な値が得られる。

ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの保護区間の一部の値を示す。ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮは、表７に従ってシグナルされる。

ＲＥＳＥＲＶＥＤ：当該４ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。

次のフィールドは、ＰＬＳ２データをデコードするためのパラメータを提供する。

ＰＬＳ２_ＦＥＣ_ＴＹＰＥ：当該２ビットフィールドは、ＰＬＳ２保護によって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、表１０に従ってシグナルされる。ＬＤＰＣコードに関する詳細な内容は後述する。

ＰＬＳ２_ＭＯＤ：当該３ビットフィールドは、ＰＬＳ２によって用いられる変調タイプを示す。変調タイプは表１１に従ってシグナルされる。

ＰＬＳ２_ＳＩＺＥ_ＣＥＬＬ：当該１５ビットフィールドは、現フレームグループで伝達されるＰＬＳ２に対する全コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣ_{total_partial_block}を示す。当該値は、現フレームグループの全デューレーションにおいて一定である。

ＰＬＳ２_ＳＴＡＴ_ＳＩＺＥ_ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループの全デューレーションにおいて一定である。

ＰＬＳ２_ＤＹＮ_ＳＩＺＥ_ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループの全デューレーションにおいて一定である。

ＰＬＳ２_ＲＥＰ_ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。

ＰＬＳ２_ＲＥＰ_ＳＩＺＥ_ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、現フレームグループの毎フレームごとに伝達されるＰＬＳ２に対する部分コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣ_{total_partial_block}を示す。反復が用いられない場合、当該フィールドの値は０と同一である。当該値は、現フレームグループの全デューレーションにおいて一定である。

ＰＬＳ２_ＮＥＸＴ_ＦＥＣ_ＴＹＰＥ：当該２ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられるＦＥＣタイプを示す。ＦＥＣタイプは表１０に従ってシグナルされる。

ＰＬＳ２_ＮＥＸＴ_ＭＯＤ：当該３ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられる変調タイプを示す。変調タイプは表１１に従ってシグナルされる。

ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが次のフレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。

ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＳＩＺＥ_ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、次のフレームグループの毎フレームごとに伝達されるＰＬＳ２に対する全コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣ_{total_full_block}を示す。次のフレームグループで反復が用いられない場合、当該フィールドの値は０と同一である。当該値は現フレームグループの全デューレーションにおいて一定である。

ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＳＴＡＴ_ＳＩＺＥ_ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループで一定である。

ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＤＹＮ_ＳＩＺＥ_ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループで一定である。

ＰＬＳ２_ＡＰ_ＭＯＤＥ：当該２ビットフィールドは、現フレームグループでＰＬＳ２に対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全デューレーションにおいて一定である。下記の表１２は当該フィールドの値を提供する。当該フィールドの値が００に設定されると、現フレームグループで追加パリティがＰＬＳ２に対して用いられない。

ＰＬＳ２_ＡＰ_ＳＩＺＥ_ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全デューレーションにおいて一定である。

ＰＬＳ２_ＮＥＸＴ_ＡＰ_ＭＯＤＥ：当該２ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２シグナリングに対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全デューレーションにおいて一定である。表１２は、当該フィールドの値を定義する。

ＰＬＳ２_ＮＥＸＴ_ＡＰ_ＳＩＺＥ_ＣＥＬＬ：当該１５ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全デューレーションにおいて一定である。

ＲＥＳＥＲＶＥＤ：該当３２ビットフィールドは将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。

ＣＲＣ_３２：全ＰＬＳ１シグナリングに適用される３２ビット誤り検出コード

図１４は、本発明の一実施例に係るＰＬＳ２データを示す。

図１４は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２−ＤＹＮデータは現フレームに対して特定の情報を提供する。

ＰＬＳ２−ＳＴＡＴデータのフィールドに対して次に具体的に説明する。

ＦＩＣ_ＦＬＡＧ：当該１ビットフィールドは、ＦＩＣが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＦＩＣは現フレームで提供される。当該フィールドの値が０に設定されると、ＦＩＣは現フレームで伝達されない。当該値は、現フレームグループの全デューレーションにおいて一定である。

ＡＵＸ_ＦＬＡＧ：当該１ビットフィールドは、補助ストリームが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、補助ストリームは現フレームで提供される。当該フィールドの値が０に設定されると、補助フレームは現フレームで伝達されない。当該値は、現フレームグループの全デューレーションにおいて一定である。

ＮＵＭ_ＤＰ：該当６ビットフィールドは、現フレーム内で伝達されるデータパイプの数を示す。当該フィールドの値は１〜６４であり、データパイプの数はＮＵＭ_ＤＰ＋１である。

ＤＰ_ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内でＤＰを唯一に識別する。

ＤＰ_ＴＹＰＥ：当該３ビットフィールドはデータパイプのタイプを示す。これは、下記の表１３に従ってシグナルされる。

ＤＰ_ＧＲＯＵＰ_ＩＤ：当該８ビットフィールドは、現データパイプが関連しているデータパイプグループを識別する。これは、受信機が同じＤＰ_ＧＲＯＵＰ_ＩＤを有する特定サービスと関連しているサービスコンポーネントのデータパイプに接続するために用いられてもよい。

ＢＡＳＥ_ＤＰ_ＩＤ：当該６ビットフィールドは、管理階層で用いられる（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ_ＤＰ_ＩＤで示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達するノーマルデータパイプであってもよく、サービスシグナリングデータだけを伝達する専用データパイプであってもよい。

ＤＰ_ＦＥＣ_ＴＹＰＥ：当該２ビットフィールドは、関連したデータパイプによって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、下記の表１４に従ってシグナルされる。

ＤＰ_ＣＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられるコードレート（ｃｏｄｅｒａｔｅ）を示す。コードレート（ｃｏｄｅｒａｔｅ）は、下記の表１５に従ってシグナルされる。

ＤＰ_ＭＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられる変調を示す。変調は、下記の表１６に従ってシグナルされる。

ＤＰ_ＳＳＤ_ＦＬＡＧ：当該１ビットフィールドは、ＳＳＤモードが関連したデータパイプで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＳＳＤが用いられる。当該フィールドの値が０に設定されると、ＳＳＤは用いられない。

次のフィールドは、ＰＨＹ_ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す０１０と同一である場合にのみ表される。

ＤＰ_ＭＩＭＯ：当該３ビットフィールドは、どのタイプのＭＩＭＯエンコーディング処理が関連したデータパイプに適用されるかを示す。ＭＩＭＯエンコーディング処理のタイプは、下記の表１７に従ってシグナルされる。

ＤＰ_ＴＩ_ＴＹＰＥ：当該１ビットフィールドは、タイムインターリービングのタイプを示す。０の値は、一つのタイムインターリービンググループが一つのフレームに該当し、一つ以上のタイムインターリービングブロックを含むことを示す。１の値は、一つのタイムインターリービンググループが一つよりも多いフレームで伝達され、一つのタイムインターリービングブロックのみを含むことを示す。

ＤＰ_ＴＩ_ＬＥＮＧＴＨ：当該２ビットフィールド（許容された値は、１、２、４、８のみである。）の使用は、次のようなＤＰ_ＴＩ_ＴＹＰＥフィールド内で設定される値によって決定される。

ＤＰ_ＴＩ_ＴＹＰＥの値が１に設定されると、当該フィールドは、それぞれのタイムインターリービンググループがマップされるフレームの数であるＰ_Iを示し、タイムインターリービンググループ当たりに一つのタイムインターリービングブロックが存在する（Ｎ_TI＝１）。当該２ビットフィールドで許容されるＰＩの値は、下記の表１８に定義される。

ＤＰ_ＴＩ_ＴＹＰＥの値が０に設定されると、当該フィールドは、タイムインターリービンググループ当たりのタイムインターリービングブロックの数Ｎ_TIを示し、フレーム当たりに一つのタイムインターリービンググループが存在する（Ｐ_I＝１）。当該２ビットフィールドで許容されるＰ_Iの値は、下記の表１８に定義される。

ＤＰ_ＦＲＡＭＥ_ＩＮＴＥＲＶＡＬ：当該２ビットフィールドは、関連したデータパイプに対するフレームグループ内でフレーム間隔（Ｉ_JUMP）を示し、許容された値は１，２，４，８（該当する２ビットフィールドはそれぞれ００，０１，１０，１１）である。フレームグループの全フレームに現れないデータパイプに対して、当該フィールドの値は、順次的なフレーム間の間隔と同一である。例えば、データパイプが１，５，９，１３などのフレームで現れると、当該フィールドの値は４に設定される。全フレームに現れるデータパイプに対して、当該フィールドの値は１に設定される。

ＤＰ_ＴＩ_ＢＹＰＡＳＳ：当該１ビットフィールドは、タイムインターリーバ５０５０の可用性を決定する。データパイプに対してタイムインターリービングが用いられないと、それは１に設定される。一方、タイムインターリービングが用いられると、それは０に設定される。

ＤＰ_ＦＩＲＳＴ_ＦＲＡＭＥ_ＩＤＸ：当該５ビットフィールドは、現データパイプが発生するスーパーフレームの最初のフレームのインデックスを示す。ＤＰ_ＦＩＲＳＴ_ＦＲＡＭＥ_ＩＤＸの値は、０〜３１である。

ＤＰ_ＮＵＭ_ＢＬＯＣＫ_ＭＡＸ：当該１０ビットフィールドは、当該データパイプに対するＤＰ_ＮＵＭ_ＢＬＯＣＫＳの最大値を示す。当該フィールドの値はＤＰ_ＮＵＭ_ＢＬＯＣＫＳと同じ範囲を有する。

ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードデータのタイプを示す。ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥは、下記の表１９に従ってシグナルされる。

ＤＰ_ＩＮＢＡＮＤ_ＭＯＤＥ：当該２ビットフィールドは、現データパイプがインバンド（Ｉｎ−ｂａｎｄ）シグナリング情報を伝達するか否かを示す。インバンド（Ｉｎ−ｂａｎｄ）シグナリングタイプは、下記の表２０に従ってシグナルされる。

ＤＰ_ＰＲＯＴＯＣＯＬ_ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。それは、入力ペイロードタイプが選択されると、下記の表２１に従ってシグナルされる。

ＤＰ_ＣＲＣ_ＭＯＤＥ：当該２ビットフィールドは、ＣＲＣエンコーディングが入力フォーマットブロックで用いられるか否かを示す。ＣＲＣモードは、下記の表２２に従ってシグナルされる。

ＤＮＰ_ＭＯＤＥ：当該２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるヌルパケット削除モードを示す。ＤＮＰ_ＭＯＤＥは、下記の表２３に従ってシグナルされる。ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（‘００’）でなければ、ＤＮＰ_ＭＯＤＥは００の値に設定される。

ＩＳＳＹ_ＭＯＤＥ：当該２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるＩＳＳＹモードを示す。ＩＳＳＹ_ＭＯＤＥは、下記の表２４に従ってシグナルされる。ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（‘００’）でなければ、ＩＳＳＹ_ＭＯＤＥは００の値に設定される。

ＨＣ_ＭＯＤＥ_ＴＳ：当該２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるＴＳヘッダー圧縮モードを示す。ＨＣ_ＭＯＤＥ_ＴＳは、下記の表２５に従ってシグナルされる。

ＨＣ_ＭＯＤＥ_ＩＰ：当該２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＩＰ（‘０１’）に設定される場合に、ＩＰヘッダー圧縮モードを示す。ＨＣ_ＭＯＤＥ_ＩＰは、下記の表２６に従ってシグナルされる。

ＰＩＤ：当該１３ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（‘００’）に設定され、ＨＣ_ＭＯＤＥ_ＴＳが０１又は１０に設定される場合に、ＴＳヘッダー圧縮のためのＰＩＤ数を示す。

ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。

次のフィールドは、ＦＩＣ_ＦＬＡＧが１と同一である場合にのみ現れる。

ＦＩＣ_ＶＥＲＳＩＯＮ：当該８ビットフィールドは、ＦＩＣのバージョンナンバーを示す。

ＦＩＣ_ＬＥＮＧＴＨ_ＢＹＴＥ：当該１３ビットフィールドは、ＦＩＣの長さをバイト単位で示す。

次のフィールドは、ＡＵＸ_ＦＬＡＧが１と同一である場合にのみ現れる。

ＮＵＭ_ＡＵＸ：当該４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが用いられないことを示す。

ＡＵＸ_ＣＯＮＦＩＧ_ＲＦＵ：当該８ビットフィールドは将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。

ＡＵＸ_ＳＴＲＥＡＭ_ＴＹＰＥ：当該４ビットは、現補助ストリームのタイプを示すための将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。

ＡＵＸ_ＰＲＩＶＡＴＥ_ＣＯＮＦＩＧ：該当２８ビットフィールドは、補助ストリームをシグナリングするための将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。

図１５は、本発明の他の実施例に係るＰＬＳ２データを示す。

図１５は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は一つのフレームグループのデューレーションで変化してもよいが、フィールドのサイズは一定である。

ＰＬＳ２−ＤＹＮデータのフィールドの具体的な内容は、次のとおりである。

ＦＲＡＭＥ_ＩＮＤＥＸ：当該５ビットフィールドは、スーパーフレーム内で現フレームのフレームインデックスを示す。スーパーフレームの最初のフレームのインデックスは０に設定される。

ＰＬＳ_ＣＨＡＮＧＥ_ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナルされる値で示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、１の値は、次のスーパーフレームに変化があることを示す。

ＦＩＣ_ＣＨＡＮＧＥ_ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成（すなわち、ＦＩＣのコンテンツ）が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナルされる値で示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、０００１の値は、次のスーパーフレームに変化があるということを示す。

ＲＥＳＥＲＶＥＤ：当該１６ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。

次のフィールドは、現フレームで伝達されるデータパイプと関連したパラメータを説明するＮＵＭ_ＤＰにおけるループ（ｌｏｏｐ）に現れる。

ＤＰ_ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内でデータパイプを唯一に示す。

ＤＰ_ＳＴＡＲＴ：当該１５ビット（又は、１３ビット）フィールドは、ＤＰＵアドレシング（ａｄｄｒｅｓｓｉｎｇ）技法を用いてデータパイプの最初の開始位置を示す。ＤＰ_ＳＴＡＲＴフィールドは、下記の表２７に示すように、フィジカルプロファイル及びＦＦＴサイズによって異なる長さを有する。

ＤＰ_ＮＵＭ_ＢＬＯＣＫ：当該１０ビットフィールドは、現データパイプに対する現タイムインターリービンググループでＦＥＣブロックの数を示す。ＤＰ_ＮＵＭ_ＢＬＯＣＫの値は、０〜１０２３である。

次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。

ＥＡＣ_ＦＬＡＧ：当該１ビットフィールドは、現フレームでＥＡＣの存在を示す。該当ビットはプリアンブルでＥＡＣ_ＦＬＡＧと同じ値である。

ＥＡＳ_ＷＡＫＥ_ＵＰ_ＶＥＲＳＩＯＮ_ＮＵＭ：当該８ビットフィールドは、自動活性化指示のバージョンナンバーを示す。

ＥＡＣ_ＦＬＡＧフィールドが１に等しいと、次の１２ビットがＥＡＣ_ＬＥＮＧＴＨ_ＢＹＴＥフィールドに割り当てられる。ＥＡＣ_ＦＬＡＧフィールドが０に等しいと、次の１２ビットがＥＡＣ_ＣＯＵＮＴＥＲに割り当てられる。

ＥＡＣ_ＬＥＮＧＴＨ_ＢＹＴＥ：当該１２ビットフィールドは、ＥＡＣの長さをバイトで示す。

ＥＡＣ_ＣＯＵＮＴＥＲ：当該１２ビットフィールドは、ＥＡＣが到達するフレーム以前のフレームの数を示す。

次のフィールドは、ＡＵＸ_ＦＬＡＧフィールドが１と同一である場合にのみ現れる。

ＡＵＸ_ＰＲＩＶＡＴＥ_ＤＹＮ：当該４８ビットフィールドは、補助ストリームをシグナリングするための将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。当該フィールドの意味は、設定可能なＰＬＳ２−ＳＴＡＴでＡＵＸ_ＳＴＲＥＡＭ_ＴＹＰＥの値に依存する。

ＣＲＣ_３２：全ＰＬＳ２に適用される３２ビット誤り検出コード。

図１６は、本発明の一実施例に係るフレームのロジカル（ｌｏｇｉｃａｌ）構造を示す。

前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、ダミーセルは、フレームでＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳ１及びＰＬＳ２は、初めには一つ以上のＦＳＳにマップされる。その後、存在するなら、ＥＡＣセルは直後のＰＬＳフィールドにマップされ、次に存在すると、ＦＩＣセルが続く。データパイプは、存在すると、ＰＬＳ又はＥＡＣ、ＦＩＣ後にマップされる。タイプ１データパイプが初めて続き、その次にタイプ２データパイプが続く。データパイプのタイプの具体的な内容は後述する。一部の場合に、データパイプは、ＥＡＳに対する一部の特殊データ又はサービスシグナリングデータを伝達することができる。補助ストリーム又はストリームは、存在するなら、データパイプに続き、ここには順にダミーセルが続く。前述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルの順でそれらを全て共にマップすると、フレームでセル容量を正確に満たす。

図１７は、本発明の一実施例に係るＰＬＳマッピングを示す。

ＰＬＳセルは、ＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳが占めるセルの数によって、一つ以上のシンボルがＦＳＳとして指定され、ＦＳＳの数Ｎ_FSSは、ＰＬＳ１におけるＮＵＭ_ＦＳＳでシグナルされる。ＦＳＳは、ＰＬＳセルを伝達する特殊なシンボルである。警告性及び遅延時間（ｌａｔｅｎｃｙ）はＰＬＳで重大な事案であるため、ＦＳＳは高いパイロット密度を有し、高速同期化及びＦＳＳ内における周波数のみのインターポレーション（補間）を可能にする。

ＰＬＳセルは、図１７の例に示すように、下向き方式でＦＳＳのアクティブキャリアにマップされる。ＰＬＳ１セルははじめには、最初のＦＳＳの最初のセルからセルインデックスの昇順でマップされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後に続き、マッピングは、最初のＦＳＳの最後のセルインデックスまで下向き方式で続く。必要なＰＬＳセルの全数が一つのＦＳＳのアクティブキャリアの数を超えると、マッピングは次のＦＳＳに進行され、最初のＦＳＳと全く同じ方式で続けて行われる。

ＰＬＳマッピングが完了した後、データパイプが次に伝達される。ＥＡＣ、ＦＩＣ、又は両方が現フレームに存在すると、これらはＰＬＳとノーマルデータパイプとの間に配置される。

図１８は、本発明の一実施例に係るＥＡＣマッピングを示す。

ＥＡＣは、ＥＡＳメッセージを伝達する専用チャネルであり、ＥＡＳに対するデータパイプに連結される。ＥＡＳ支援は提供されるが、ＥＡＣ自体は全てのフレームに存在してもよく、存在しなくてもよい。存在するなら、ＥＡＣは、ＰＬＳ２セルの直後にマップされる。ＰＬＳセルを除けば、ＦＩＣ、データパイプ、補助ストリーム又はダミーセルのいずれもＥＡＣの前に位置しない。ＥＡＣセルのマッピング手順はＰＬＳと全く同一である。

ＥＡＣセルは、図１８の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順でマップされる。ＥＡＳメッセージの大きさによって、図１８に示すように、ＥＡＣセルは、少ないシンボルを占めることができる。

ＥＡＣセルは、ＰＬＳ２の最後のセルの直後に続き、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向き方式で続けて行われる。必要なＥＡＣセルの全数が最後のＦＳＳの残っているアクティブキャリアの数を超えると、マッピングは次のシンボルに進行され、ＦＳＳと全く同じ方式で続けて行われる。この場合のマッピングに対する次のシンボルはノーマルデータシンボルであり、これは、ＦＳＳに比べてより多いアクティブキャリアを有する。

ＥＡＣマッピングが完了した後、存在するなら、ＦＩＣが次に伝達される。ＦＩＣが伝送されないと（ＰＬＳ２フィールドでシグナリングによって）、データパイプがＥＡＣの最後のセルの直後に続く。

図１９は、本発明の一実施例に係るＦＩＣマッピングを示す。

（ａ）は、ＥＡＣ無しのＦＩＣセルのマッピングの例を示し、（ｂ）は、ＥＡＣと共にＦＩＣセルのマッピングの例を示す。

ＦＩＣは、高速サービス取得及びチャネルスキャンを可能にするために階層間情報を伝達する専用チャネルである。当該情報は主に、データパイプ間のチャネルバインディング情報及び各放送会社のサービスを含む。高速スキャンのために、受信機はＦＩＣをデコードし、放送会社ＩＤ、サービス数、ＢＡＳＥ_ＤＰ_ＩＤのような情報を取得することができる。高速サービスの取得のために、ＦＩＣだけでなくベースデータパイプもＢＡＳＥ_ＤＰ_ＩＤを用いてデコードすることができる。それが伝達するコンデンツを除いて、ベースデータパイプは、ノーマルデータパイプと全く同じ方式でエンコードされてフレームにマップされる。したがって、ベースデータパイプに関する追加説明は不要である。ＦＩＣデータが生成されて管理階層で消費される。ＦＩＣデータのコンデンツは、管理階層仕様に説明されたとおりである。

ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２のスタティック（静的）である部分でＦＩＣ_ＦＬＡＧパラメータによってシグナルされる。ＦＩＣが用いられると、ＦＩＣ_ＦＬＡＧは１に設定され、ＦＩＣに対するシグナリングフィールドは、ＰＬＳ２のスタティック（静的）である部分で定義される。当該フィールドでシグナルされるものはＦＩＣ_ＶＥＲＳＩＯＮであり、ＦＩＣ_ＬＥＮＧＴＨ_ＢＹＴＥ．ＦＩＣは、ＰＬＳ２と同じ変調、コーディング、タイムインターリービングパラメータを用いる。ＦＩＣは、ＰＬＳ２_ＭＯＤ及びＰＬＳ２_ＦＥＣのような同一のシグナリングパラメータを共有する。ＦＩＣデータは、存在するなら、ＰＬＳ２又はＥＡＣの直後にマップされる。ノーマルデータパイプ、補助ストリーム、又はダミーセルのいずれもＦＩＣの前に位置しない。ＦＩＣセルをマップする方法は、ＥＡＣと全く同一であり、これはさらにＰＬＳと同一である。

ＰＬＳ後のＥＡＣ無しで、ＦＩＣセルは、（ａ）の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順でマップされる。ＦＩＣデータサイズによって、（ｂ）に示すように、ＦＩＣセルは数個のシンボルに対してマップされる。

ＦＩＣセルは、ＰＬＳ２の最後のセルの直後に続き、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向き方式で続けて行われる。必要なＦＩＣセルの全数が最後のＦＳＳの残っているアクティブキャリアの数を超えると、マッピングは次のシンボルに進行され、ＦＳＳと全く同じ方式で続けて行われる。この場合のマッピングに対する次のシンボルはノーマルデータシンボルであり、これはＦＳＳに比べてより多いアクティブキャリアを有する。

ＥＡＳメッセージが現フレームで伝送されると、ＥＡＣがＦＩＣに先行し、ＦＩＣセルが（ｂ）に示すように、ＥＡＣの次のセルからセルインデックスの昇順でマップされる。

ＦＩＣマッピングが完了した後、一つ以上のデータパイプがマップされ、ここには、存在するなら、補助ストリーム、ダミーセルが続く。

図２０は、本発明の一実施例に係るデータパイプのタイプを示す。

（ａ）はタイプ１データパイプを示し、（ｂ）はタイプ２データパイプを示す。

先行するチャネル、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣがマップされた後、データパイプのセルがマップされる。データパイプは、マッピング方法によって２タイプのいずれかに分類される。

タイプ１データパイプ：データパイプがＴＤＭによってマップされる。

タイプ２データパイプ：データパイプがＦＤＭによってマップされる。

データパイプのタイプは、ＰＬＳ２のスタティック（静的）である部分でＤＰ_ＴＹＰＥフィールドで示す。図２０は、タイプ１データパイプ及びタイプ２データパイプのマッピング順序を示す。タイプ１データパイプはまずセルインデックスの昇順でマップされた後、最後のセルインデックスに到達すると、シンボルインデックスが１ずつ増加する。次のシンボル内で、データパイプはｐ＝０から始まって、セルインデックスの昇順で続けてマップされる。一つのフレームで共にマップされる複数のデータパイプと共に、それぞれのタイプ１データパイプは、データパイプのＴＤＭと類似に、時間でグルーピングされる。

タイプ２データパイプはまずシンボルインデックスの昇順でマップされ、フレームの最後のＯＦＤＭシンボルに到達すると、セルインデックスは１ずつ増加し、シンボルインデックスは最初の可用シンボルに戻った後、そのシンボルインデックスから始まって増加する。一つのフレームで複数のデータパイプをマップした後、それぞれのタイプ２データパイプはデータパイプのＦＤＭと類似に、周波数でグルーピングされる。

タイプ１データパイプ及びタイプ２データパイプは必要時にはフレームで共存してもよいが、タイプ１データパイプが常にタイプ２データパイプに先行するという制限がある。タイプ１及びタイプ２データパイプを伝達するＯＦＤＭセルの全数は、データパイプの伝送に利用可能なＯＦＤＭセルの全数を超えてはならない。

ここで、Ｄ_DP1は、タイプ１データパイプが占めるＯＦＤＭセルの数に該当し、Ｄ_DP2は、タイプ２データパイプが占めるセルの数に該当する。ＰＬＳ、ＥＡＣ、ＦＩＣがいずれもタイプ１データパイプと同じ方式でマップされるため、これらはいずれも、「タイプ１マッピング規則」にしたがう。したがって、一般に、タイプ１マッピングがタイプ２マッピングに先行する。

図２１は、本発明の一実施例に係るデータパイプマッピングを示す。

（ａ）は、タイプ１データパイプをマップするためのＯＦＤＭセルのアドレシングを示し、（ｂ）は、タイプ２データパイプをマップするためのＯＦＤＭセルのアドレシングを示す。

タイプ１データパイプ（０，…，ＤＤＰ１−１）をマップするためのＯＦＤＭセルのアドレシングは、タイプ１データパイプのアクティブデータセルに対して定義される。アドレシング方式は、それぞれのタイプ１データパイプに対するタイムインターリービングからのセルがアクティブデータセルに割り当てられる順序を定義する。それはまた、ＰＬＳ２のダイナミック（動的）部分でデータパイプの位置をシグナルするために用いられる。

ＥＡＣ及びＦＩＣ無しで、アドレス０は、最後のＦＳＳでＰＬＳを伝達する最後のセルの直後にくるセルのことをいう。ＥＡＣが伝送され、ＦＩＣが該当のフレームにないと、アドレス０は、ＥＡＣを伝達する最後のセルの直後にくるセルのことをいう。ＦＩＣが該当のフレームで伝送されると、アドレス０は、ＦＩＣを伝達する最後のセルの直後にくるセルのことをいう。タイプ１データパイプに対するアドレス０は、（ａ）に示すような２種類の異なる場合を考慮して算出することができる。（ａ）の例で、ＰＬＳ、ＥＡＣ、ＦＩＣは全て送信されると仮定する。ＥＡＣとＦＩＣのいずれか一つ又は両方が省略される場合への拡張は自明である。（ａ）の左図に示すように、ＦＩＣまで全てのセルをマップした後にＦＳＳに残っているセルがあると、

タイプ２データパイプ（０，…，ＤＤＰ２−１）をマップするためのＯＦＤＭセルのアドレシングは、タイプ２データパイプのアクティブデータセルに対して定義される。アドレシング方式は、それぞれのタイプ２データパイプに対するタイムインターリービングからのセルがアクティブデータセルに割り当てられる順序を定義する。それはまた、ＰＬＳ２のダイナミック（動的）部分でデータパイプの位置をシグナルするために用いられる。

（ｂ）に示すように、３種類のやや異なる場合が可能である。（ｂ）の最も左図に示す一番目の場合に、最後のＦＳＳにあるセルは、タイプ２データパイプマッピングに用いられてもよい。中央の図に示す二番目の場合に、ＦＩＣはノーマルシンボルのセルを占めるが、当該シンボルにおけるＦＩＣセルの数はＣ_FSSよりも大きくない。（ｂ）の右図に示す三番目の場合は、当該シンボルにマップされたＦＩＣセルの数がＣＦＳＳを超えるという点を除けば、二番目の場合と同一である。

ＰＬＳ、ＥＡＣ、ＦＩＣがタイプ１データパイプと同じ「タイプ１マッピング規則」にしたがうので、タイプ１データパイプがタイプ２データパイプに先行する場合への拡張は自明である。

データパイプユニット（ＤＰＵ）は、フレームでデータセルをデータパイプに割り当てる基本単位である。

ＤＰＵは、フレームでデータパイプの位置を発見するためのシグナリング単位と定義される。セルマッパー７０１０は、それぞれのデータパイプに対してタイムインターリービングによって生成されたセルをマップすることができる。タイムインターリーバ５０５０は、一連のタイムインターリービングブロックを出力し、それぞれのタイムインターリービングブロックはＸＦＥＣＢＬＯＣＫの可変数を含み、これは結局、セルの集合で構成される。ＸＦＥＣＢＬＯＣＫにおけるセルの数Ｎ_cellsは、ＦＥＣＢＬＯＣＫサイズ、Ｎ_ldpc、コンステレーションシンボル当たりに伝送されるビット数に依存する。ＤＰＵは、与えられたフィジカルプロファイルで支援されるＸＦＥＣＢＬＯＣＫにおけるセルの数Ｎ_cellsの全ての可能な値の最大公約数と定義される。セルにおけるＤＰＵの長さは、Ｌ_DPUと定義される。それぞれのフィジカルプロファイルは、ＦＥＣＢＬＯＣＫサイズの別個の組合せ及びコンステレーションシンボル当たりに異なるビット数を支援するので、Ｌ_DPUは、フィジカルプロファイルに基づいて定義される。

図２２は、本発明の一実施例に係るＦＥＣ構造を示す。

図２２は、ビットインターリービング前の本発明の一実施例に係るＦＥＣ構造を示す。前述したように、データＦＥＣエンコーダは外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行することができる。図示されたＦＥＣ構造は、ＦＥＣＢＬＯＣＫに該当する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに該当する同一の値を有する。

図２２に示すように、ＢＣＨエンコーディングがそれぞれのＢＢＦ（Ｋ_bchビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコードされたＢＢＦ（Ｋ_ldpcビット＝Ｎ_bchビット）に適用される。

Ｎ_ldpcの値は、６４８００ビット（ロングＦＥＣＢＬＯＣＫ）又は１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。

下記の表２８及び表２９は、ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫのそれぞれに対するＦＥＣエンコーディングパラメータを示す。

ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの具体的な動作は、次のとおりである。

１２−誤り訂正ＢＣＨコードがＢＢＦの外部エンコーディングに用いられる。ショートＦＥＣＢＬＯＣＫ及びロングＦＥＣＢＬＯＣＫに対するＢＢＦ生成多項式は、全ての多項式を乗算することによって得られる。

ＬＤＰＣコードは、外部ＢＣＨエンコーディングの出力をエンコードするために用いられる。完成されたＢ_ldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐ_ldpc（パリティビット）がそれぞれのＩ_ldpc（ＢＣＨ−エンコードされたＢＢＦ）から組織的にエンコードされ、Ｉ_ldpcに付加される。完成されたＢ_ldpc（ＦＥＣＢＬＯＣＫ）は、次の式で表現される。

ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは、上記の表２８及び表２９にそれぞれ与えられる。

ロングＦＥＣＢＬＯＣＫに対してＮ_ldpc−Ｋ_ldpcパリティビットを計算する具体的な手順は次のとおりである。

１）パリティビット初期化

２）パリティーチェックマトリクスのアドレスの一番目の行で特定されたパリティビットアドレスで一番目の情報ビットｉ₀を累算する（ａｃｃｕｍｕｌａｔｅ）。パリティーチェックマトリクスのアドレスの詳細な内容は後述する。例えば、比率１３／１５に対して、

３）次の３５９個の情報ビットｉ_s、ｓ＝１，２，…，３５９に対して、次の式を用いてパリティビットアドレスでｉ_sを累算する。

ここで、ｘは、最初のビットｉ₀に該当するパリティビット累算器のアドレスを示し、Ｑ_ldpcは、パリティーチェックマトリクスのアドレスで特定されたコードレート（ｃｏｄｅｒａｔｅ）依存定数である。上記の例である、比率１３／１５に対する、したがって情報ビットｉ₁に対するＱ_ldpc＝２４に続いて、次の動作が実行される。

４）３６１番目の情報ビットｉ₃₆₀に対して、パリティビット累算器のアドレスは、パリティーチェックマトリクスのアドレスの２番目の行に与えられる。同様の方式で、次の３５９個の情報ビットｉ_s、ｓ＝３６１，３６２，…，７１９に対するパリティビット累算器のアドレスは、式６を用いて得られる。ここで、ｘは情報ビットｉ₃₆₀に該当するパリティビット累算器のアドレス、すなわち、パリティーチェックマトリクスの２番目の行のエントリを示す。

５）同様の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティーチェックマトリクスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めるために用いられる。

全情報ビットが利用された後、最終パリティビットが次のように得られる。

６）ｉ＝１から始まって次の動作を順次に実行する

ここで、ｐ_i、ｉ＝０，１，．．．Ｎ_ldpc−Ｋ_ldpc−１の最終コンデンツは、パリティビットｐ_iと同一である。

表３０を表３１に代え、ロングＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスをショートＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスに代えることを除けば、ショートＦＥＣＢＬＯＣＫに対する当該ＬＤＰＣエンコーディング手順は、ロングＦＥＣＢＬＯＣＫに対するｔＬＤＰＣエンコーディング手順にしたがう。

図２３は、本発明の一実施例に係るビットインターリービングを示す。

ＬＤＰＣエンコーダの出力はビットインターリーブされるが、これは、ＱＣＢ（ｑｕａｓｉ−ｃｙｃｌｉｃｂｌｏｃｋ）インターリービング及び内部グループインターリービングが続くパリティインターリービングで構成される。

（ａ）はＱＣＢインターリービングを示し、（ｂ）は内部グループインターリービングを示す。

ＦＥＣＢＬＯＣＫは、パリティインターリーブすることができる。パリティインターリービングの出力において、ＬＤＰＣコードワードは、ロングＦＥＣＢＬＯＣＫで１８０個の隣接するＱＣＢで構成され、ショートＦＥＣＢＬＯＣＫで４５個の隣接するＱＣＢで構成される。ロング又はショートＦＥＣＢＬＯＣＫにおけるそれぞれのＱＣＢは、３６０ビットで構成される。パリティインターリービングされたＬＤＰＣコードワードは、ＱＣＢインターリービングによってインターリーブされる。ＱＣＢインターリービングの単位はＱＣＢである。パリティインターリービングの出力におけるＱＣＢは、図２３に示すように、ＱＣＢインターリービングによってパーミュテーションされるが、ここでＦＥＣＢＬＯＣＫの長さによってＮ_cells＝６４８００／ηｍｏｄ又は１６２００／ηｍｏｄである。ＱＣＢインターリービングパターンは、変調タイプ及びＬＤＰＣコードレート（ｃｏｄｅｒａｔｅ）の各組合せに固有である。

ＱＣＢインターリービング後に、内部グループインターリービングが、下記の表３２に定義された変調タイプ及び次数（ηｍｏｄ）によって実行される。一つの内部グループに対するＱＣＢの数Ｎ_{QCB_IG}も定義される。

内部グループインターリービング過程は、ＱＣＢインターリービング出力のＮ_{QCB_IG}個のＱＣＢで実行される。内部グループインターリービングは、３６０個の列及びＮ_{QCB_IG}個の行を用いて内部グループのビットを書き込み・読み取りする過程を含む。書き込み動作で、ＱＣＢインターリービング出力からのビットが行方向に書き込まれる。読み取り動作は、列方向に実行されて、各行からｍ個のビットを読み取る。ここで、ｍはＮＵＣの場合に１に等しく、ＮＵＱの場合に２に等しい。

図２４は、本発明の一実施例に係るセル−ワードマルチプレクシングを示す。

図２４で、（ａ）は、８及び１２ｂｐｃｕＭＩＭＯに対するセル−ワードマルチプレクシングを示し、（ｂ）は、１０ｂｐｃｕＭＩＭＯに対するセル−ワードマルチプレクシングを示す。

ビットインターリービング出力のそれぞれのセルワード（ｃ_0,l，ｃ_1,l，…，ｃ_ηmod-1,l）は、一つのＸＦＥＣＢＬＯＣＫに対するセル−ワードマルチプレクシング過程を説明する（ａ）に示すように、（ｄ_1,0,m，ｄ_1,1,m…，ｄ_1,ηmod-1,m）及び（ｄ_2,0,m，ｄ_2,1,m…，ｄ_2,ηmod-1,m）にマルチプレクスされる。

ＭＩＭＯエンコーディングのために異なるタイプのＮＵＱを利用する１０ｂｐｃｕＭＩＭＯの場合に、ＮＵＱ−１０２４に対するビットインターリーバが再使用される。ビットインターリーバ出力のそれぞれのセルワード（ｃ_0,l，ｃ_1,l，…，ｃ_9,l）は、（ｂ）に示すように、（ｄ_1,0,m，ｄ_1,1,m…，ｄ_1,3,m）及び（ｄ_2,0,m，ｄ_2,1,m…，ｄ_2,5,m）にマルチプレクスされる。

図２５は、本発明の一実施例に係るタイムインターリービングを示す。

（ａ）乃至（ｃ）は、タイムインターリービングモードの例を示す。

タイムインターリーバは、データパイプレベルで動作する。タイムインターリービングのパラメータはそれぞれのデータパイプに対して別々に設定されてもよい。

ＰＬＳ２−ＳＴＡＴデータの一部に現れる次のパラメータは、タイムインターリービングを構成する。

ＤＰ_ＴＩ_ＴＹＰＥ（許容された値：０又は１）：タイムインターリービングモードを示す。０は、タイムインターリービンググループ当たりに複数のタイムインターリービングブロック（一つ以上のタイムインターリービングブロック）を有するモードを示す。この場合、一つのタイムインターリービンググループは一つのフレームに（フレーム間インターリービング無しで）直接マップされる。１は、タイムインターリービンググループ当たりに一つのタイムインターリービングブロックだけを有するモードを示す。この場合、タイムインターリービングブロックは、一つ以上のフレームにわたって拡散される（フレーム間インターリービング）。

ＤＰ_ＴＩ_ＬＥＮＧＴＨ：ＤＰ_ＴＩ_ＴＹＰＥ＝‘０’であれば、当該パラメータは、タイムインターリービンググループ当たりのタイムインターリービングブロックの数Ｎ_TIである。ＤＰ_ＴＩ_ＴＹＰＥ＝‘１’である場合、当該パラメータは、一つのタイムインターリービンググループから拡散されるフレームの数Ｐ_Iである。

ＤＰ_ＮＵＭ_ＢＬＯＣＫ_ＭＡＸ（許容された値：０乃至１０２３）：タイムインターリービンググループ当たりのＸＦＥＣＢＬＯＣＫの最大数を示す。

ＤＰ_ＦＲＡＭＥ_ＩＮＴＥＲＶＡＬ（許容された値：１，２，４，８）：与えられたフィジカルプロファイルの同一のデータパイプを伝達する２つの順次的なフレーム間のフレームの数Ｉ_JUMPを示す。

ＤＰ_ＴＩ_ＢＹＰＡＳＳ（許容された値：０又は１）：タイムインターリービングがデータフレームに用いられないと、当該パラメータは１に設定される。タイムインターリービングが用いられると、０に設定される。

さらに、ＰＬＳ２−ＤＹＮデータからのパラメータＤＰ_ＮＵＭ_ＢＬＯＣＫは、データグループの一つのタイムインターリービンググループによって伝達されるＸＦＥＣＢＬＯＣＫの数を示す。

タイムインターリービングがデータフレームに用いられないと、次のタイムインターリービンググループ、タイムインターリービング動作、タイムインターリービングモードは考慮されない。しかし、スケジューラからのダイナミック（動的）構成情報のためのディレイコンペセーション（遅延補償）ブロックは依然として必要である。それぞれのデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫは、タイムインターリービンググループにグルーピングされる。すなわち、それぞれのタイムインターリービンググループは整数個のＸＦＥＣＢＬＯＣＫの集合であり、ダイナミック（動的）に変化する数のＸＦＥＣＢＬＯＣＫを含むはずである。インデックスｎのタイムインターリービンググループにあるＸＦＥＣＢＬＯＣＫの数は、Ｎ_{xBLOCK_Group}（ｎ）で示し、ＰＬＳ２−ＤＹＮデータでＤＰ_ＮＵＭ_ＢＬＯＣＫとしてシグナルされる。このとき、Ｎ_{xBLOCK_Group}（ｎ）は、最小値０から、最大の値が１０２３である最大値Ｎ_{xBLOCK_Group_MAX}（ＤＰ_ＮＵＭ_ＢＬＯＣＫ_ＭＡＸに該当）まで変化してもよい。

それぞれのタイムインターリービンググループは、一つのフレームに直接マップされたり、Ｐ_I個のフレームにわたって拡散される。また、それぞれのタイムインターリービンググループは、一つ以上（Ｎ_TI個）のタイムインターリービングブロックに分離される。ここでそれぞれのタイムインターリービングブロックは、タイムインターリーバメモリの一つの使用に該当する。タイムインターリービンググループ内のタイムインターリービングブロックは、やや異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。タイムインターリービンググループが複数のタイムインターリービンググループに分離されると、それは一つのフレームにのみ直接マップされる。下記の表３３に示すように、タイムインターリービングには３つのオプションがある（タイムインターリービングを省略する追加オプションを除く）。

それぞれのデータパイプで、タイムインターリービングメモリは、入力されたＸＦＥＣＢＬＯＣＫ（ＳＳＤ／ＭＩＭＯエンコーディングブロックから出力されたＸＦＥＣＢＬＯＣＫ）を保存する。入力されたＸＦＥＣＢＬＯＣＫは、

また、タイムインターリーバ５０５０から出力されたＸＦＥＣＢＬＯＣＫは、

と定義されると仮定する。

一般に、タイムインターリーバは、フレーム生成手順の前にデータパイプデータに対するバッファーとしても働くはずである。これは、それぞれのデータパイプに対して２個のメモリバンクによって達成される。最初のタイムインターリービングブロックは一番目のバンクに書き込まれる。一番目のバンクから読み取られる間に、２番目のタイムインターリービングブロックが２番目のバンクに書き込まれる。

タイムインターリービングはツイストされた行−列ブロックインターリーバである。

図２６は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す。

図２６（ａ）は、タイムインターリーバで書き込み動作を示し、図２６（ｂ）は、タイムインターリーバで読み取り動作を示す。（ａ）に示すように、一番目のＸＦＥＣＢＬＯＣＫはタイムインターリービングメモリの一番目の列に列方向に書き込まれ、二番目のＸＦＥＣＢＬＯＣＫは次の列に書き込まれ、このような動作が続けて行われる。

結果的に、読み取られるセル位置は、座標

によって算出される。

図２７は、本発明の他の実施例に係るツイストされた行−列ブロックインターリーバの動作を示す。

図２８は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの対角線方向読み取りパターンを示す。

図２９は、本発明の一実施例に係るそれぞれのインターリービングアレイからのインターリービングされたＸＦＥＣＢＬＯＣＫを示す。

図２９は、パラメータ

図３０は、本発明の一実施例に係る、次世代放送システムのためのプロトコルスタック（ＰｒｏｔｏｃｏｌＳｔａｃｋ）を示す図である。

本発明に係る放送システムは、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）中心ブロードキャストネットワーク（ＩＰｃｅｎｔｒｉｃｂｒｏａｄｃａｓｔｎｅｔｗｏｒｋ）とブロードバンド（ｂｒｏａｄｂａｎｄ）とが結合されたハイブリッド放送システムに該当し得る。

本発明に係る放送システムは、既存のＭＰＥＧ−２ベースの放送システムとの互換性が維持されるように設計することができる。

本発明に係る放送システムは、ＩＰ中心ブロードキャストネットワーク（ＩＰｃｅｎｔｒｉｃｂｒｏａｄｃａｓｔｎｅｔｗｏｒｋ）、ブロードバンド（ｂｒｏａｄｂａｎｄ）ネットワーク、及び／又は移動通信ネットワーク（ｍｏｂｉｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｎｅｔｗｏｒｋ又はｃｅｌｌｕｌａｒｎｅｔｗｏｒｋ）の結合に基づくハイブリッド放送システムに該当してもよい。

同図を参照すると、物理層（Ｐｈｙｓｉｃａｌｌａｙｅｒ）は、ＡＴＳＣシステム及び／又はＤＶＢシステムのような放送システムで採用する物理的プロトコルを用いることができる。例えば、本発明に係る物理層では、送／受信機は地上波放送信号を送信／受信し、放送データを含む伝送フレーム（ｔｒａｎｓｐｏｒｔｆｒａｍｅ）を適切な形態に変換することができる。

暗号化（Ｅｎｃａｐｓｕｌａｔｉｏｎ）層では、物理層から取得した情報から、ＩＰデータグラム（ｄａｔａｇｒａｍ）を取得したり、取得したＩＰデータグラムを特定フレーム（例えば、ＲＳフレーム、ＧＳＥ−ｌｉｔｅ、ＧＳＥ或いは信号フレームなど）に変換する。ここで、フレームは、ＩＰデータグラムの集合を含むことができる。例えば、暗号化層で送信機は、物理層で処理されたデータを伝送フレームに含めたり、受信機は、物理層から取得した伝送フレームからＭＰＥＧ−２ＴＳ、ＩＰデータグラムを抽出する。

ＦＩＣ（ｆａｓｔｉｎｆｏｒｍａｔｉｏｎｃｈａｎｎｅｌ）は、サービス及び／又はコンテンツに接近可能にさせるための情報（例、サービスＩＤとフレームとのマッピング情報など）を含む。ＦＩＣはＦＡＣ（ＦａｓｔＡｃｃｅｓｓＣｈａｎｎｅｌ）と命名されてもよい。

本発明の放送システムは、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）、ＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）、ＡＬＣ／ＬＣＴ（ＡｓｙｎｃｈｒｏｎｏｕｓＬａｙｅｒｅｄＣｏｄｉｎｇ／ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）、ＲＣＰ／ＲＴＣＰ（ＲａｔｅＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ／ＲＴＰＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）、ＨＴＴＰ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）、ＦＬＵＴＥ（ＦｉｌｅＤｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ）などのプロトコルを用いることができる。これらのプロトコル間のスタック（ｓｔａｃｋ）については同図に示す構造を参照すればよい。

本発明の放送システムにおいてデータは、ＩＳＯＢＭＦＦ（ＩＳＯｂａｓｅｍｅｄｉａｆｉｌｅｆｏｒｍａｔ）の形態で伝送することができる。ＥＳＧ（ＥｌｅｃｔｒｉｃａｌＳｅｒｖｉｃｅＧｕｉｄｅ）、ＮＲＴ（ＮｏｎＲｅａｌＴｉｍｅ）、Ａ／Ｖ（Ａｕｄｉｏ／Ｖｉｄｅｏ）及び／又は一般データをＩＳＯＢＭＦＦの形態で伝送することができる。

ブロードキャストネットワークによるデータの伝送は、線形コンテンツ（ｌｉｎｅａｒｃｏｎｔｅｎｔ）の伝送及び／又は非線形コンテンツ（ｎｏｎ−ｌｉｎｅａｒｃｏｎｔｅｎｔ）の伝送を含むことができる。

ＲＴＰ／ＲＴＣＰベースのＡ／Ｖ、データ（ｃｌｏｓｅｄｃａｐｔｉｏｎ、ｅｍｅｒｇｅｎｃｙａｌｅｒｔｍｅｓｓａｇｅなど）の伝送は、線形コンテンツの伝送に該当し得る。

ＲＴＰペイロードは、ＮＡＬ（ＮｅｔｗｏｒｋＡｂｓｔｒａｃｔｉｏｎＬａｙｅｒ）が含まれたＲＴＰ／ＡＶストリーム形態及び／又はＩＳＯｂａｓｅｄｍｅｄｉａｆｉｌｅｆｏｒｍａｔで暗号化（ｅｎｃａｐｓｕｌａｔｉｏｎ）された形態で伝送されてもよい。ＲＴＰペイロードの伝送は線形コンテンツの伝送に該当し得る。ＩＳＯｂａｓｅｄｍｅｄｉａｆｉｌｅｆｏｒｍａｔで暗号化された形態の伝送は、Ａ／Ｖなどに対するＭＰＥＧＤＡＳＨｍｅｄｉａｓｅｇｍｅｎｔを含むことができる。

ＦＬＵＴＥベースＥＳＧの伝送、ｎｏｎ−ｔｉｍｅｄｄａｔａの伝送、ＮＲＴｃｏｎｔｅｎｔの伝送は、非線形コンテンツの伝送に該当し得る。それらは、ＭＩＭＥｔｙｐｅのファイル形態及び／又はＩＳＯｂａｓｅｄｍｅｄｉａｆｉｌｅｆｏｒｍａｔで暗号化された形態で伝送されてもよい。ＩＳＯｂａｓｅｄｍｅｄｉａｆｉｌｅｆｏｒｍａｔで暗号化された形態の伝送はＡ／Ｖなどに対するＭＰＥＧＤＡＳＨｍｅｄｉａｓｅｇｍｅｎｔを含むことができる。

ブロードバンドネットワークによる伝送は、コンテンツに対する伝送とシグナリングデータに対する伝送とに区分して考えることができる。

コンテンツの伝送は、線形コンテンツ（Ａ／Ｖ、データ（ｃｌｏｓｅｄｃａｐｔｉｏｎ、ｅｍｅｒｇｅｎｃｙａｌｅｒｔｍｅｓｓａｇｅなど）の伝送と非線形コンテンツ（ＥＳＧ、ｎｏｎ−ｔｉｍｅｄｄａｔａなど）の伝送、ＭＰＥＧＤＡＳＨベースのＭｅｄｉａｓｅｇｍｅｎｔ（Ａ／Ｖ、ｄａｔａ）伝送を含む。

シグナリングデータの伝送は、放送網で伝送されるシグナリングテーブル（ｓｉｇｎａｌｉｎｇｔａｂｌｅ）（ＭＰＥＧＤＡＳＨのＭＰＤを含む）を含む伝送が可能である。

本発明の放送システムでは、放送網を介して送信された線形／非線形コンテンツ間の同期化、或いは放送網を介して伝送されるコンテンツとブロードバンドで送信されたコンテンツ間の同期化を支援することができる。例えば、一つのＵＤコンテンツが放送網とブロードバンドで分離されて同時に伝送される場合、受信機は、伝送プロトコルに依存したタイムライン（ｔｉｍｅｌｉｎｅ）を調整し、放送網のコンテンツとブロードバンドのコンテンツとを同期化した後、一つのＵＤコンテンツとして再構成することができる。

本発明の放送システムのアプリケーション層は、両方向性（Ｉｎｔｅｒａｃｔｉｖｉｔｙ）、個人化（Ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）、第２スクリーン（ＳｅｃｏｎｄＳｃｒｅｅｎ）、ＡＣＲ（ａｕｔｏｍａｔｉｃｃｏｎｔｅｎｔｒｅｃｏｇｎｉｔｉｏｎ）などの技術的特徴を具現することができる。このような特徴は、例えば、北−米放送標準であるＡＴＳＣ２．０からＡＴＳＣ３．０への拡張において重要な特徴である。例えば、両方向性の特徴のために、ＨＴＭＬ５が用いられてもよい。

本発明の放送システムのプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）層では、コンポーネント間又は両方向アプリケーション間の空間的、時間的関係を識別するためにＨＴＭＬ及び／又はＨＴＭＬ５が用いられてもよい。

本発明でシグナリング（Ｓｉｇｎａｌｉｎｇ）は、コンテンツ及び／又はサービスの効果的な取得を支援するためのシグナリング情報を含む。シグナリングデータは、バイナリ或いはＸＭＬ形態などで表現することができ、地上波放送網或いはブロードバンドを介して伝達することができる。

実時間放送Ａ／Ｖコンテンツ及び／又はデータの場合、ＩＳＯＢａｓｅＭｅｄｉａＦｉｌｅＦｏｒｍａｔなどで表現することができる。この場合、放送Ａ／Ｖコンテンツ及び／又はデータは、地上波放送網を介して実時間で伝達されてもよく、ＩＰ／ＵＤＰ／ＦＬＵＴＥに基づいて非実時間で伝達されてもよい。又は、放送Ａ／Ｖコンテンツ及び／又はデータに対して、インターネット網を介してＤＡＳＨ（ＤｙｎａｍｉｃＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇｏｖｅｒＨＴＴＰ）などを用いて実時間でコンテンツのストリーミングを受けたり、要請して受けることができる。本発明の一実施例に係る放送システムは、このようにして受けた放送Ａ／Ｖコンテンツ及び／又はデータを組み合わせ、両方向性サービス、第２スクリーンサービスなどの様々なエンハンスドサービスを視聴者に提供することができる。

図３１は、本発明の一実施例に係る放送伝送フレームを示す。

図３１の実施例において、放送伝送フレームは、Ｐ１パート、Ｌ１パート、共通ＰＬＰ（ＣｏｍｍｏｎＰＬＰ）パート、インターリーブされたＰＬＰ（Ｓｃｈｅｄｕｌｅｄ＆ＩｎｔｅｒｌｅａｖｅｄＰＬＰ’ｓ）パート及び補助データ（Ａｕｘｉｌｉａｒｙｄａｔａ）パートを含む。

図３１の実施例において、放送送信装置は、放送伝送フレーム（ｔｒａｎｓｐｏｒｔｆｒａｍｅ）のＰ１パートを介して伝送シグナル探知（ｔｒａｎｓｐｏｒｔｓｉｇｎａｌｄｅｔｅｃｔｉｏｎ）のための情報を伝送する。また、放送送信装置は、Ｐ１パートを介して放送信号のチューニングのためのチューニング情報を伝送することができる。

図３１の実施例において、放送送信装置は、Ｌ１パートを介して、放送伝送フレームの構成及び各ＰＬＰの特性を伝送する。このとき、放送受信装置１００は、Ｐ１に基づいてＬ１パートをデコードして放送伝送フレームの構成及び各ＰＬＰの特性を取得することができる。

図３１の実施例において、放送送信装置は、共通ＰＬＰパートを介して、ＰＬＰ間に共通に適用される情報を伝送することができる。具体的な実施例によって、放送伝送フレームは共通ＰＬＰパートを含まなくてもよい。

図３１の実施例において、放送送信装置は、放送サービスに含まれた複数のコンポーネントをインターリーブされた（ｉｎｔｅｒｌｅａｖｅｄ）ＰＬＰパートを介して伝送する。このとき、インターリーブされたＰＬＰパートは複数のＰＬＰを含む。

図３１の実施例において、放送送信装置は、それぞれの放送サービスを構成するコンポーネントがそれぞれどのＰＬＰで伝送されるかをＬ１パート又は共通ＰＬＰパートを介してシグナリングすることができる。ただし、放送受信装置１００が、放送サービススキャンなどのために具体的な放送サービス情報を取得するためには、インターリーブされたＰＬＰパートの複数のＰＬＰを全てデコードしなければならない。

図３１の実施例とは異なり、放送送信装置は、放送伝送フレームを介して伝送される放送サービス及び放送サービスに含まれたコンポーネントに関する情報を含む別途のパートを含む、放送伝送フレームを伝送することができる。このとき、放送受信装置１００は、別途のパートを介して迅速に放送サービス及び放送サービスに含まれたコンポーネントに関する情報を取得することができる。これについては、図３２を参照して説明する。

図３２は、本発明の他の実施例に係る放送伝送フレームを示す。

図３２の実施例において、放送伝送フレームは、Ｐ１パート、Ｌ１パート、高速情報チャネル（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ、ＦＩＣ）パート、インターリーブされたＰＬＰ（Ｓｃｈｅｄｕｌｅｄ＆ＩｎｔｅｒｌｅａｖｅｄＰＬＰ’ｓ）パート及び補助データ（Ａｕｘｉｌｉａｒｙｄａｔａ）パートを含む。

ＦＩＣパートを除いた他のパートは、図３１の実施例と同一である。

放送送信装置は、ＦＩＣパートを介して高速情報（ｆａｓｔｉｎｆｏｒｍａｔｉｏｎ）を伝送する。高速情報は、伝送フレームを介して伝送される放送ストリームの構成情報（ｃｏｎｆｉｇｕｒａｔｉｏｎｉｎｆｏｒｍａｔｉｏｎ）、簡略な放送サービス情報、及び当該サービス／コンポーネントと関連するサービスシグナリングを含むことができる。放送受信装置１００は、ＦＩＣパートに基づいて放送サービスをスキャンすることができる。具体的に、放送受信装置１００は、ＦＩＣパートから放送サービスに関する情報を抽出することができる。

図３３は、本発明の一実施例に係る放送サービスを伝送する伝送パケットの構造を示す。

図３３の実施例において、放送サービスを伝送する伝送パケットは、ＮｅｔｗｏｒｋＰｒｏｔｏｃｏｌフィールド、ＥｒｒｏｒＩｎｄｉｃａｔｏｒフィールド、ＳｔｕｆｆｉｎｇＩｎｄｉｃａｔｏｒフィールド、Ｐｏｉｎｔｅｒｆｉｅｌｄフィールド、Ｓｔｕｆｆｉｎｇｂｙｔｅｓフィールド及びペイロード（ｐａｙｌｏａｄ）データを含む。

ＮｅｔｗｏｒｋＰｒｏｔｏｃｏｌフィールドは、ネットワークプロトコルがどのタイプであるかを示す。

ＥｒｒｏｒＩｎｄｉｃａｔｏｒフィールドは、当該伝送パケットに誤りが検出されたか否かを表示する。具体的に、ＥｒｒｏｒＩｎｄｉｃａｔｏｒフィールドの値が０であれば、当該パケットから誤りが検出されていないことを示し、ＥｒｒｏｒＩｎｄｉｃａｔｏｒフィールドの値が１であれば、当該パケットから誤りが検出されたことを示すことができる。具体的な実施例において、ＥｒｒｏｒＩｎｄｉｃａｔｏｒフィールドは１ビットフィールドであってもよい。

ＳｔｕｆｆｉｎｇＩｎｄｉｃａｔｏｒフィールドは、当該伝送パケットにスタッフィングバイト（ｓｔｕｆｆｉｎｇｂｙｔｅｓ）が含まれているか否かを表示する。このとき、スタッフィングバイトは、固定されたパケットの長さを維持するためにペイロードに含まれるデータを示す。具体的な実施例において、ＳｔｕｆｆｉｎｇＩｎｄｉｃａｔｏｒフィールドの値が１であれば、伝送パケットがスタッフィングバイトを含み、ＳｔｕｆｆｉｎｇＩｎｄｉｃａｔｏｒフィールドの値が０であれば、伝送パケットがスタッフィングバイトを含まないことを示すことができる。具体的な実施例において、ＳｔｕｆｆｉｎｇＩｎｄｉｃａｔｏｒフィールドは１ビットフィールドであってもよい。

Ｐｏｉｎｔｅｒｆｉｅｌｄフィールドは、当該伝送パケットのペイロード部分において新しいネットワークパケットの開始地点を表示する。具体的な実施例において、Ｐｏｉｎｔｅｒｆｉｅｌｄの値が０ｘ７ＦＦである場合、新しいネットワークパケットの開始地点がないことを示すことができる。また、具体的な実施例において、Ｐｏｉｎｔｅｒｆｉｅｌｄの値が０ｘ７ＦＦでない場合、伝送パケットヘッダーの最後の部分から新しいネットワークパケットの開始地点までのオフセット（ｏｆｆｓｅｔ）値を示すことができる。具体的な実施例において、Ｐｏｉｎｔｅｒｆｉｅｌｄフィールドは１１ビットフィールドであってもよい。

Ｓｔｕｆｆｉｎｇ_Ｂｙｔｅｓフィールドは、固定されたパケット長を維持するためにヘッダーとペイロードデータとの間を埋めるスタッフィングバイトを示す。

このような放送サービスを受信するための放送受信装置の構成については、図３４を参照して説明する。

図３４は、本発明の一実施例に係るＮｅｔｗｏｒｋＰｒｏｔｏｃｏｌフィールドの意味を示す図である。

ＮｅｔｗｏｒｋＰｒｏｔｏｃｏｌフィールドは、ネットワークプロトコルのタイプを示す情報である。具体的な実施例において、ＮｅｔｗｏｒｋＰｒｏｔｏｃｏｌフィールドの値は、ＩＰｖ４プロトコルであるか、それとも、フレームパケットタイプであるかを示すことができる。具体的に、図３４の実施例のように、ＮｅｔｗｏｒｋＰｒｏｔｏｃｏｌフィールドの値が０００である場合、ＩＰｖ４プロトコルを示すことができる。また、具体的に、図３４の実施例のように、ＮｅｔｗｏｒｋＰｒｏｔｏｃｏｌフィールドの値が１１１である場合、ｆｒａｍｅ_ｐａｃｋｅｔ_ｔｙｐｅプロトコルを示すことができる。このとき、ｆｒａｍｅｄ_ｐａｃｋｅｔ_ｔｙｐｅは、ＡＴＳＣＡ／１５３によって定義されたプロトコルであり得る。具体的に、ｆｒａｍｅｄ_ｐａｃｋｅｔ_ｔｙｐｅは、長さに関する情報を示すフィールドを含まないネットワークパケットプロトコルを示すことができる。具体的な実施例において、ＮｅｔｗｏｒｋＰｒｏｔｏｃｏｌフィールドは３ビットフィールドであってもよい。

図３５は、本発明の一実施例に係る放送受信装置の構成を示す。

図３５の実施例において、放送受信装置１００は、放送受信部１１０、インターネットプロトコル（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ、ＩＰ）通信部１３０及び制御部１５０を含む。

放送受信部１１０は、チャネル同期化部（ＣｈａｎｎｅｌＳｙｎｃｈｒｏｎｉｚｅｒ）１１１、チャネルイコライザー（ｃｈａｎｎｅｌｅｑｕａｌｉｚｅｒ）１１３及びチャネルデコーダ（ｃｈａｎｎｅｌｄｅｃｏｄｅｒ）１１５を含む。

チャネル同期化部１１１は、放送信号を受信できる基底帯域（ｂａｓｅｂａｎｄ）でデコーディングが可能なようにシンボル周波数とタイミングを同期化する。

チャネルイコライザー１１３は、同期化された放送信号の歪みを補償する。具体的に、チャネルイコライザー１１３は、マルチパス（ｍｕｌｔｉｐａｔｈ）、ドップラー効果などによる同期化された放送信号の歪みを補償する。

チャネルデコーダ１１５は、歪みが補償された放送信号をデコードする。具体的に、チャネルデコーダ１１５は、歪みが補償された放送信号から伝送フレーム（ｔｒａｎｓｐｏｒｔｆｒａｍｅ）を抽出する。このとき、チャネルデコーダ１１５は、前方誤り訂正（ＦｏｒｗａｒｄＥｒｒｏｒＣｏｒｒｅｃｔｉｏｎ、ＦＥＣ）を行うことができる。

ＩＰ通信部１３０は、インターネット網を介してデータを受信し、送信する。

制御部１５０は、シグナリングデコーダ１５１、伝送パケットインターフェース１５３、広帯域パケットインターフェース１５５、基底帯域動作制御部１５７、共通プロトコルスタック（ＣｏｍｍｏｎＰｒｏｔｏｃｏｌＳｔａｃｋ）１５９、サービスマップデータベース１６１、サービスシグナリングチャネルプロセッシングバッファ（ｂｕｆｆｅｒ）及びパーサー（ｐａｒｓｅｒ）１６３、Ａ／Ｖプロセッサ１６５、放送サービスガイドプロセッサ１６７、アプリケーションプロセッサ１６９及びサービスガイドデータベース１７１を含む。

シグナリングデコーダ１５１は、放送信号のシグナリング情報をデコードする。

伝送パケットインターフェース１５３は、放送信号から伝送パケットを抽出する。このとき、伝送パケットインターフェース１５３は、抽出した伝送パケットからシグナリング情報又はＩＰデータグラムなどのデータを抽出することができる。

広帯域パケットインターフェース１５５は、インターネット網から受信したデータからＩＰパケットを抽出する。このとき、広帯域パケットインターフェース１５５は、ＩＰパケットからシグナリングデータ又はＩＰデータックラムを抽出することができる。

基底帯域動作制御部１５７は、基底帯域から放送情報受信情報を受信することと関連する動作を制御する。

共通プロトコルスタック１５９は、伝送パケットからオーディオ又はビデオを抽出する。

Ａ／Ｖプロセッサ１６５は、オーディオ又はビデオを処理する。

サービスシグナリングチャネルプロセッシングバッファ（ｂｕｆｆｅｒ）及びパーサー（ｐａｒｓｅｒ）１６３は、放送サービスをシグナリングするシグナリング情報をパースし、バッファリングする。具体的に、サービスシグナリングチャネルプロセッシングバッファ及びパーサー１６３は、ＩＰデータグラムから放送サービスをシグナリングするシグナリング情報をパースし、バッファリングすることができる。

サービスマップデータベース１６１は、放送サービスに関する情報を含む放送サービスリストを格納する。

サービスガイドプロセッサ１６７は、地上波放送サービスのプログラムを案内する地上波放送サービスガイドデータを処理する。

アプリケーションプロセッサ１６９は、放送信号からアプリケーション関連情報を抽出し、処理する。

サービスガイドデータベース１７１は、放送サービスのプログラム情報を格納する。

図３６は、本発明の他の実施例に係る放送受信装置の構成を示す。

図３６の実施例において、放送受信装置１００は、放送受信部１１０、インターネットプロトコル（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ、ＩＰ）通信部１３０及び制御部１５０を含む。

放送受信部１１０は、放送受信部１１０が行う複数の機能のそれぞれを行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的に、放送受信部１１０は、種々の半導体部品が一つに集積されるシステムオンチップ（ＳｙｓｔｅｍＯｎＣｈｉｐ、ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサ及びＤ−ＲＡＭなどの半導体とが一つに統合された半導体であってもよい。放送受信部１１０は、物理層モジュール１１９及び物理層ＩＰフレームモジュール１１７を含むことができる。物理層モジュール１１９は、放送網の放送チャネルを介して放送関連信号を受信し、処理する。物理層ＩＰフレームモジュール１１７は、物理層モジュール１１９から取得したＩＰデータグラムなどのデータパケットを特定のフレームに変換する。例えば、物理層モジュール１１９は、ＩＰデータグラムなどをＲＳＦｒａｍｅ又はＧＳＥなどに変換することができる。

ＩＰ通信部１３０は、ＩＰ通信部１３０が行う複数の機能のそれぞれを行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的に、ＩＰ通信部１３０は、種々の半導体部品が一つに集積されるシステムオンチップ（ＳｙｓｔｅｍＯｎＣｈｉｐ、ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサ及びＤ−ＲＡＭなどの半導体とが一つに統合された半導体であってもよい。ＩＰ通信部１３０は、インターネット接近制御モジュール１３１を含むことができる。インターネット接近制御モジュール１３１は、インターネット通信網（ｂｒｏａｄｂａｎｄ）を介してサービス、コンテンツ及びシグナリングデータのうちの少なくともいずれか１つを取得するための放送受信装置１００の動作を制御する。

制御部１５０は、制御部１５０が行う複数の機能のそれぞれを行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的に、制御部１５０は、種々の半導体部品が１つに集積されるシステムオンチップ（ＳｙｓｔｅｍＯｎＣｈｉｐ、ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサ及びＤ−ＲＡＭなどの半導体とが一つに統合された半導体であってもよい。制御部１５０は、シグナリングデコーダ１５１、サービスマップデータベース１６１、サービスシグナリングチャネルパーサー１６３、アプリケーションシグナリングパーサー１６６、アラートシグナリングパーサー１６８、ターゲッティングシグナリングパーサー１７０、ターゲッティングプロセッサ１７３、Ａ／Ｖプロセッサ１６１、アラーティングプロセッサ１６２、アプリケーションプロセッサ１６９、スケジュールドストリーミングデコーダ１８１、ファイルデコーダ１８２、ユーザ要請ストリーミングデコーダ１８３、ファイルデータベース１８４、コンポーネント同期化部１８５、サービス／コンテンツ取得制御部１８７、再分配モジュール１８９、装置マネージャー１９３及びデータシェアリング部１９１のうちの少なくともいずれか１つを含むことができる。

サービス／コンテンツ取得制御部１８７は、放送網又はインターネット通信網を介して取得したサービス、コンテンツ、サービス又はコンテンツと関連するシグナリングデータの取得のための受信機の動作を制御する。

シグナリングデコーダ１５１はシグナリング情報をデコードする。

サービスシグナリングパーサー１６３はサービスシグナリング情報をパースする。

アプリケーションシグナリングパーサー１６６は、サービスと関連するシグナリング情報を抽出し、パースする。このとき、サービスと関連するシグナリング情報は、サービススキャンと関連するシグナリング情報であってもよい。また、サービスと関連するシグナリング情報は、サービスを介して提供されるコンテンツと関連するシグナリング情報であってもよい。

アラートシグナリングパーサー１６８は、アラーティング関連シグナリング情報を抽出し、パースする。

ターゲッティングシグナリングパーサー１７０は、サービス又はコンテンツを個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）するための情報またはターゲッティング情報をシグナリングする情報を抽出し、パースする。

ターゲッティングプロセッサ１７３は、サービス又はコンテンツを個人化するための情報を処理する。

アラーティングプロセッサ１６２は、アラーティング関連シグナリング情報を処理する。

アプリケーションプロセッサ１６９は、アプリケーション関連情報及びアプリケーションの実行を制御する。具体的に、アプリケーションプロセッサ１６９は、ダウンロードされたアプリケーションの状態及びディスプレイパラメータを処理する。

Ａ／Ｖプロセッサ１６１は、デコードされたオーディオ又はビデオ、アプリケーションデータなどに基づいてオーディオ／ビデオのレンダリング関連動作を処理する。

スケジュールドストリーミングデコーダ１８１は、予め放送会社などのコンテンツ提供業者が定めた日程に従ってストリーミングされるコンテンツであるスケジュールドストリーミングをデコードする。

ファイルデコーダ１８２は、ダウンロードされたファイルをデコードする。特に、ファイルデコーダ１８２は、インターネット通信網を介してダウンロードされたファイルをデコードする。

ユーザ要請ストリーミングデコーダ１８３は、ユーザの要請によって提供されるコンテンツ（ＯｎＤｅｍａｎｄＣｏｎｔｅｎｔ）をデコードする。

ファイルデータベース１８４はファイルを格納する。具体的に、ファイルデータベース１８４は、インターネット通信網を介してダウンロードしたファイルを格納することができる。

コンポーネント同期化部１８５は、コンテンツ又はサービスを同期化する。具体的に、コンポーネント同期化部１８５は、スケジュールドストリーミングデコーダ１８１、ファイルデコーダ１８２及びユーザ要請ストリーミングデコーダ１８３のうちの少なくともいずれか１つを介して取得したコンテンツの再生時間などに対する同期化を行う。コンポーネント同期化部１８５は、放送ネットワークと異なる異種ネットワークを介して伝送される異種ストリームと放送ストリームとの同期のための（後述する）情報を含む追加パケットを取得することができる。

サービス／コンテンツ取得制御部１８７は、サービス、コンテンツ、サービス又はコンテンツと関連するシグナリング情報のうちの少なくともいずれか１つを取得するための受信機の動作を制御する。

再分配モジュール１８９は、放送網を介してサービス又はコンテンツを受信できない場合、サービス、コンテンツ、サービス関連情報及びコンテンツ関連情報のうちの少なくともいずれか１つの取得をサポートするための動作を行う。具体的に、外部の管理装置３００にサービス、コンテンツ、サービス関連情報及びコンテンツ関連情報のうちの少なくともいずれか１つを要請することができる。このとき、外部の管理装置３００はコンテンツサーバーであってもよい。

装置マネージャー１９３は、連動可能な外部装置を管理する。具体的に、装置マネージャー１９３は、外部装置の追加、削除及び更新のうちの少なくともいずれか１つを行うことができる。また、外部装置は、放送受信装置１００との接続及びデータ交換が可能である。

データシェアリング部１９１は、放送受信装置１００と外部装置との間のデータ伝送動作を行い、交換関連情報を処理する。具体的に、データシェアリング部１９１は、外部装置にＡ／Ｖデータ又はシグナリング情報を伝送することができる。また、データシェアリング部１９１は、外部装置からＡ／Ｖデータ又はシグナリング情報を受信することができる。

図３７は、本発明の一実施例に係る、次世代放送システムにおいてサービス及び／又はコンテンツを取得する構造を示す図である。

本発明で提案した方案は、次世代放送システムでは、受信機が、サービスあるいはコンテンツを、放送網あるいはインターネット網を介して効率的に取得できるようにする。

同図は、ハイブリッド放送システムでのサービスあるいはコンテンツの取得のための一例を示す。

例えば、サービス０（Ｓｅｒｖｉｃｅ０）は、それぞれ１つのビデオ（ｖｉｄｅｏ）とオーディオ（ａｕｄｉｏ）で構成され、各ビデオ／オーディオは、地上波放送網を介して伝送されるＩＰストリーム（ＩＰｓｔｒｅａｍ）を介して取得することができる。

サービス１（Ｓｅｒｖｉｃｅ１）の場合、ビデオを伝送するＩＰストリーム及びオーディオを伝送するＩＰストリームは一つのＰＬＰを介して伝送されるので、受信機は、当該ＰＬＰをデコードすると、サービス１を取得することができる。

サービスＮ（ＳｅｒｖｉｃｅＮ）の場合、ビデオは地上波放送網を介して伝送されるが、オーディオの場合、インターネット網を介して取得することができる。

上記のように、受信機がサービス０、サービス１、またはサービスＮに含まれるコンポーネントを取得する過程において、前述した本発明の実施例を使用することができる。すなわち、受信機は、サービス０、サービス１、またはサービスＮに含まれるそれぞれのコンポーネントを伝送するＰＬＰを識別して、当該ＰＬＰをデコードし、所望のサービスを取得することができる。

図３８は、本発明の一実施例に係る放送サービスシグナリングテーブルを示す。

放送サービスシグナリングテーブルは、放送サービスを識別する情報、放送サービスの現在の状態を示す情報、放送サービスのネーム、放送サービスのチャネルナンバー、放送サービスに対する保護アルゴリズムが適用されたか否かを示す情報、放送サービスのカテゴリー情報、及び放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報のうちの少なくともいずれか１つを含むことができる。放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報は、それぞれのメディアコンポーネントが当該放送サービスに必須であるか否かを示す情報を含むことができる。また、放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報は、それぞれのコンポーネントと関連する情報を含むことができる。

具体的に、図３８の実施例のように、放送サービスシグナリングテーブルは、ｔａｂｌｅ_ｉｄフィールド、ｓｅｃｔｉｏｎ_ｓｙｎｔａｘ_ｉｎｄｉｃａｔｏｒフィールド、ｐｒｉｖａｔｅ_ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールド、ｔａｂｌｅ_ｉｄ_ｅｘｔｅｎｓｉｏｎフィールド、ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒフィールド、ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールド、ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒｒフィールド、ｎｕｍ_ｓｅｒｖｉｃｅｓフィールド、ｓｅｒｖｉｃｅ_ｉｄフィールド、ｓｅｒｖｉｃｅ_ｓｔａｔｕｓフィールド、ＳＰ_ｉｎｄｉｃａｔｏｒフィールド、ｓｈｏｒｔ_ｓｅｒｖｉｃｅ_ｎａｍｅ_ｌｅｎｇｔｈフィールド、ｓｈｏｒｔ_ｓｅｒｖｉｃｅ_ｎａｍｅフィールド、ｃｈａｎｎｅｌ_ｎｕｍｂｅｒフィールド、ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールド、ｎｕｍ_ｃｏｍｐｏｎｅｎｔｓフィールド、ｅｓｓｅｎｔｉａｌ_ｃｏｍｐｏｎｅｎｔ_ｉｎｄｉｃａｔｏｒフィールド、ｎｕｍ_ｃｏｍｐｏｎｅｎｔ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールド、ｃｏｍｐｏｎｅｎｔ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールド、ｎｕｍ_ｓｅｒｖｉｃｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒｓフィールド、及びｓｅｒｖｉｃｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールドのうちの少なくともいずれか１つを含むことができる。

ｔａｂｌｅ_ｉｄフィールドは、放送サービスシグナリング情報テーブルの識別子を示す。このとき、ｔａｂｌｅ_ｉｄフィールドの値は、ＡＴＳＣＡ／６５で定義されたｒｅｓｅｒｖｅｄｉｄ値のうち１つであってもよい。具体的な実施例において、ｔａｂｌｅ_ｉｄフィールドは８ビットフィールドであってもよい。

ｓｅｃｔｉｏｎ_ｓｙｎｔａｘ_ｉｎｄｉｃａｔｏｒフィールドは、放送サービスシグナリング情報テーブルのＭＰＥＧ−２ＴＳ標準のロング（ｌｏｎｇ）形式のプライベートセクションテーブル（ｐｒｉｖａｔｅｓｅｃｔｉｏｎｔａｂｌｅ）であるか否かを示す。具体的な実施例において、ｓｅｃｔｉｏｎ_ｓｙｎｔａｘ_ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドであってもよい。

ｐｒｉｖａｔｅ_ｉｎｄｉｃａｔｏｒフィールドは、現在のテーブルがプライベートセクション（ｐｒｉｖａｔｅｓｅｃｔｉｏｎ）に該当するか否かを示す。具体的な実施例において、ｐｒｉｖａｔｅ_ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドであってもよい。

ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドは、ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールド以降に含まれたセクションの長さを示す。具体的な実施例において、ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドは１２ビットフィールドであってもよい。

ｔａｂｌｅ_ｉｄ_ｅｘｔｅｎｓｉｏｎフィールドは、ｔａｂｌｅ_ｉｄフィールドと結合して放送サービスシグナリング情報テーブルを識別する値を示す。特に、ｔａｂｌｅ_ｉｄフィールドは、サービスシグナリング情報テーブルのプロトコルバージョンを示すＳＭＴ_ｐｒｏｔｏｃｏｌ_ｖｅｒｓｉｏｎフィールドを含むことができる。具体的な実施例において、ＳＭＴ_ｐｒｏｔｏｃｏｌ_ｖｅｒｓｉｏｎフィールドは８ビットフィールドであってもよい。

ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒフィールドは、サービスシグナリングテーブルのバージョンを示す。放送受信装置１００は、ｖｓｅｒｉｏｎ_ｎｕｍｂｅｒフィールドの値に基づいて、サービスシグナリング情報テーブルの情報を用いるか否かを決定することができる。具体的に、ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒフィールドの値が以前に受信したサービスシグナリングテーブルのバージョンと同一である場合、サービスシグナリングテーブルの情報を用いなくてもよい。具体的な実施例において、ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒフィールドは５ビットフィールドであってもよい。

ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒフィールドは、放送サービスシグナリングテーブルの情報が現在使用可能であるか否かを示す。具体的に、ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒフィールドの値が１である場合、放送サービスシグナリングテーブルの情報が使用可能であることを示すことができる。また、ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒフィールドの値が１である場合、放送サービスシグナリングテーブルの情報を次に使用できることを示すことができる。具体的な実施例において、ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドであってもよい。

ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、現在のセクションの番号を示す。具体的な実施例において、ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは８ビットであってもよい。

ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、最後のセクションの番号を示す。放送サービスシグナリングテーブルの大きさが大きい場合、複数のセクションに分けられて伝送され得る。このとき、放送受信装置１００は、ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドとｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドに基づいて、放送サービスシグナリングテーブルに必要な全てのセクションが受信されたか否かを判断する。具体的な実施例において、ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは８ビットフィールドであってもよい。

ｓｅｒｖｉｃｅ_ｉｄフィールドは、放送サービスを識別する識別子を示す。具体的な実施例において、ｓｅｒｖｉｃｅ_ｉｄフィールドは１６ビットフィールドであってもよい。

ｓｅｒｖｉｃｅ_ｓｔａｔｕｓフィールドは、放送サービスの現在の状態を示す。具体的に、放送サービスが現在利用可能であるか否かを示すことができる。具体的な実施例において、ｓｅｒｖｉｃｅ_ｓｔａｔｕｓフィールドの値が１である場合、放送サービスが現在利用可能であることを示すことができる。具体的な実施例において、放送受信装置１００は、ｓｅｒｖｉｃｅ_ｓｔａｔｕｓフィールドの値に基づいて、当該放送サービスを放送サービスリスト及び放送サービスガイドに表示するか否かを決定することができる。例えば、放送受信装置１００は、当該放送サービスが利用不可能な場合、当該放送サービスを放送サービスリストと放送サービスガイドに表示しなくてもよい。他の具体的な実施例において、放送受信装置１００は、ｓｅｒｖｉｃｅ_ｓｔａｔｕｓフィールドの値に基づいて、当該放送サービスに対する接近を制限することができる。例えば、当該放送サービスが利用不可能な場合、放送受信装置１００は、当該放送サービスに対するチャネルアップ／ダウンキーを用いた接近を制限することができる。具体的な実施例において、ｓｅｒｖｉｃｅ_ｓｔａｔｕｓフィールドは２ビットフィールドであってもよい。

ＳＰ_ｉｎｄｉｃａｔｏｒフィールドは、当該放送サービス内の１つ以上のコンポーネントがサービスプロテクション（ｐｒｏｔｅｃｔｉｏｎ）が適用されたかを示すことができる。例えば、ＳＰ_ｉｎｄｉｃａｔｏｒの値が１である場合、当該放送サービス内の１つ以上のコンポーネントにサービスプロテクションが適用されたことを示すことができる。具体的な実施例において、ＳＰ_ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドであってもよい。

ｓｈｏｒｔ_ｓｅｒｖｉｃｅ_ｎａｍｅ_ｌｅｎｇｔｈフィールドは、ｓｈｏｒｔ_ｓｅｒｖｉｃｅ_ｎａｍｅフィールドの大きさを示す。

ｓｈｏｒｔ_ｓｅｒｖｉｃｅ_ｎａｍｅフィールドは、放送サービスのネームを示す。具体的に、ｓｈｏｒｔ_ｓｅｒｖｉｃｅ_ｎａｍｅフィールドは、放送サービスのネームを要約して表示することができる。

ｃｈａｎｎｅｌ_ｎｕｍｂｅｒフィールドは、当該放送サービスの仮想チャネルナンバーを表示する。

ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールドは、放送サービスのカテゴリーを示す。

ｎｕｍ_ｃｏｍｐｏｎｅｎｔｓフィールドは、当該放送サービスが含むメディアコンポーネントの個数を示す。具体的な実施例において、ｎｕｍ_ｃｏｍｐｏｎｅｎｔフィールドは５ビットフィールドであってもよい。

ｅｓｓｅｎｔｉａｌ_ｃｏｍｐｏｎｅｎｔ_ｉｎｄｉｃａｔｏｒフィールドは、当該メディアコンポーネントが当該放送サービスの再生（ｐｒｅｓｅｎｔａｔｉｏｎ）のために必要な必須のメディアコンポーネントであるかを示す。具体的な実施例において、ｅｓｓｅｎｔｉａｌ_ｃｏｍｐｏｎｅｎｔ_ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドであってもよい。

ｎｕｍ_ｃｏｍｐｏｎｅｎｔ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールドは、ｃｏｍｐｏｎｅｎｔ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールドの個数を示す。具体的な実施例において、ｎｕｍ_ｃｏｍｐｏｎｅｎｔ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールドは４ビットフィールドであってもよい。

ｃｏｍｐｏｎｅｎｔ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールドは、当該コンポーネントに対する付加的な属性を含む。

ｎｕｍ_ｓｅｒｖｉｃｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールドの個数を示す。具体的な実施例において、ｎｕｍ_ｓｅｒｖｉｃｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒｓフィールドは４ビットフィールドであってもよい。

ｓｅｒｖｉｃｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールドは、当該サービスに対する付加的な属性を含む。

サービスシグナリングテーブルは、アンサンブルに関する情報をさらに含むことができる。アンサンブルは、１つ以上のサービスが同一の前方誤り訂正（ＦｏｒｗａｒｄＥｒｒｏｒＣｏｒｒｅｃｔｉｏｎ、ＦＥＣ）が適用されて伝送される場合、１つ以上のサービスの集合を示す。

図３９は、本発明の一実施例に係るｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールドの意味を示す図である。

ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールドは、ＴＶサービス、ラジオサービス、放送サービスガイド、ＲＩサービス及び緊急警告（ＥｍｅｒｇｅｎｃｙＡｌｅｒｔｉｎｇ）のいずれかを示すことができる。例えば、図示の実施例のように、ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールドの値が０ｘ０１である場合、ＴＶサービスを示し、ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールドの値が０ｘ０２である場合、ラジオサービスを示し、ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールドの値が０ｘ０３である場合、ＲＩサービスを示し、ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールドの値が０ｘ０８である場合、サービスガイドを示し、ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールドの値が０ｘ０９である場合、緊急警報を示すことができる。具体的な実施例において、ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙフィールドは６ビットフィールドであってもよい。

図４０は、本発明の他の実施例に係る放送サービスシグナリングテーブルを示す。

具体的に、図４０の実施例のように、放送サービスシグナリングテーブルは、ｎｕｍ_ｅｎｓｅｍｂｌｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒｓフィールド及びｅｎｓｅｍｂｌｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールドをさらに含むことができる。

ｎｕｍ_ｅｎｓｅｍｂｌｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｅｎｓｅｍｂｌｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールドの個数を示す。具体的な実施例において、ｎｕｍ_ｅｎｓｅｍｂｌｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒｓフィールドは４ビットフィールドであってもよい。

ｅｎｓｅｍｂｌｅ_ｌｅｖｅｌ_ｄｅｓｃｒｉｐｔｏｒフィールドは、当該アンサンブルに対する付加的な属性を含む。

また、サービスシグナリングテーブルは、メディアコンポーネントを識別するために、メディアコンポーネントを識別するストリーム識別子情報をさらに含むことができる。

図４１は、本発明の他の実施例に係るストリーム識別子ディスクリプタを示す。

ストリーム識別子情報は、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈフィールド及びｃｏｍｐｏｎｅｎｔ_ｔａｇフィールドのうちの少なくともいずれか１つを含むことができる。

ｄｅｓｃｒｉｐｔｏｒ_ｔａｇフィールドは、当該ディスクリプタがストリーム識別子情報を含むディスクリプタであることを示す。具体的な実施例において、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇフィールドは８ビットフィールドであってもよい。

ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈフィールドは、当該フィールド以降のストリーム識別子情報の長さを示す。具体的な実施例において、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈフィールドは８ビットフィールドであってもよい。

ｃｏｍｐｏｎｅｎｔ_ｔａｇフィールドは、メディアコンポーネントを識別するメディアコンポーネント識別子を示す。このとき、メディアコンポーネント識別子は、当該シグナリング情報テーブル上で他のメディアコンポーネントのメディアコンポーネント識別子と異なる唯一（ｕｎｉｑｕｅ）の値を有することができる。当該具体的な実施例において、ｃｏｍｐｏｎｅｎｔ_ｔａｇフィールドは８ビットフィールドであってもよい。

放送サービスシグナリングテーブルを伝送し、受信する動作については、以下で説明する。

上述した放送サービステーブルをビットストリームの形式で説明したが、具体的な実施例によって、放送サービステーブルはＸＭＬ形式であってもよい。

図４２は、本発明の一実施例に係る放送送信装置が放送サービスシグナリングテーブルを伝送する動作を示す。

本発明の一実施例に係る放送送信装置は、放送信号を送信する送信部、及び放送送信装置の動作を制御する制御部を含むことができる。送信部は、送信部が行う複数の機能のそれぞれを行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的に、送信部は、種々の半導体部品が一つに集積されるシステムオンチップ（ＳｙｓｔｅｍＯｎＣｈｉｐ、ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサ及びＤ−ＲＡＭなどの半導体とが一つに統合された半導体であってもよい。制御部は、制御部が行う複数の機能のそれぞれを行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的に、制御部は、種々の半導体部品が一つに集積されるシステムオンチップ（ＳｙｓｔｅｍＯｎＣｈｉｐ、ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサ及びＤ−ＲＡＭなどの半導体とが一つに統合された半導体であってもよい。

放送送信装置は、制御部を介して、伝送パケットに含めて伝送するデータを取得する（Ｓ１０１）。放送送信装置が伝送するデータは、リアルタイムコンテンツ又はリアルタイムコンテンツと関連するメタデータであってもよい。具体的に、リアルタイムコンテンツは、地上波放送網などを介して伝送される放送Ａ／Ｖコンテンツ、又は放送Ａ／Ｖコンテンツに関連する向上したデータ（ｅｎｈａｎｃｅｍｅｎｔｄａｔａ）であってもよい。

放送送信装置は、制御部を介して取得したデータが、データの伝送のために使用する伝送パケットが含み得る大きさを超えるか否かを判断する（Ｓ１０３）。具体的に、放送送信装置が使用する伝送パケットが、固定されたパケット長を使用するプロトコルをベースとすることができる。このとき、伝送しようとするデータが、パケットがカバーできる大きさを超える場合、円滑なデータの伝送が難しいことがある。また、伝送しようとするデータがパケットに比べて非常に小さい場合、一つのパケットに小さな大きさの１つのデータのみを伝送することは、非効率的なパケット活用となり得る。したがって、上述した非効率性を克服するために、放送送信装置は制御部を介して伝送パケットとデータの大きさを比較する。

もし、放送送信装置が、伝送するデータを、伝送パケットが含むことができない大きさであると判断した場合、放送送信装置は、制御部を介して伝送するデータをセグメンテーション（Ｓｅｇｍｅｎｔａｔｉｏｎ）する（Ｓ１０５）。セグメンテーションされたデータは、複数の伝送パケットに分けられて伝送され得る。そして、複数の伝送パケットは、セグメンテーションされたデータを識別するための情報をさらに含むことができる。更に他の実施例において、セグメンテーションされたデータを識別するための情報は、伝送パケットではなく、別途のデータグラムを介して伝送されてもよい。

放送送信装置は、制御部を介してセグメンテーションされたデータの識別のための値をパケットペイロードに設定する（Ｓ１０７）。

放送送信装置は、制御部を介してセグメンテーションされたデータ又は伝送パケットよりも小さい大きさを有するデータをパケット化（ｐａｃｋｅｔｉｚｉｎｇ）する（Ｓ１０９）。具体的に、放送送信装置は、データを伝送可能な形態に加工する。加工された放送パケットは、パケットヘッダー（Ｐａｃｋｅｔｈｅａｄｅｒ）とパケットペイロード（Ｐａｃｋｅｔｐａｙｌｏａｄ）を含むことができる。また、パケットペイロードは、データとペイロードのヘッダーを含むことができる。ここで、ペイロードヘッダーは、パケットヘッダーと別途に、パケットペイロードに含まれたペイロードデータをシグナリングするためのフィールドである。また、セグメンテーションされたデータを含むパケットペイロードは、ペイロードのヘッダーと共に、セグメンテーションされたデータヘッダーを含むことができる。ここで、セグメンテーションされたデータヘッダーは、ペイロードヘッダーと別途に、パケットペイロードに含まれたペイロードデータをシグナリングするためのフィールドである。

一実施例において、放送送信装置は、一つのデータを一つのパケットにパケット化することができる。他の実施例において、放送送信装置は、複数のデータを一つのパケットにパケット化することができる。更に他の実施例において、放送送信装置は、一つのデータを複数のパケットに分割してパケット化することができる。

上述したように、データの大きさ又はパケットの長さに応じて、パケット化された伝送パケットが変わり得る。したがって、放送送信装置は、互いに異なる伝送パケットを区別可能な形態で伝送する必要がある。一実施例において、放送送信装置は、制御部を介して、伝送パケットのペイロードヘッダーにパケットの形態を示す情報を含めてデータをパケット化することができる。他の一実施例において、放送送信装置の制御部は、ペイロードヘッダーに含まれた情報のみで伝送するデータを区別することが難しい場合に、伝送パケットの種類を識別できる情報をさらに含めてデータをパケット化することができる。

放送送信装置は、送信部を介して、パケット化された放送パケットを伝送する（Ｓ１１１）。一実施例において、放送パケットの伝送は地上波放送網を介して行われてもよい。他の実施例において、放送パケットの伝送はインターネット網を介して行われてもよい。

図４３は、本発明の一実施例に係る放送受信装置がパケット化された放送パケットを受信する動作を示す。

放送受信装置１００は、放送受信部１１０を介して、パケット化された伝送パケットを受信する（Ｓ２０１）。

放送受信装置１００は、制御部１５０を介して、受信された伝送パケットからペイロードヘッダーを抽出する（Ｓ２０３）。制御部１５０は、伝送パケットのペイロードから、データを含むペイロードデータ、及びペイロードデータをシグナリングするペイロードヘッダーを取得することができる。具体的に、放送受信装置１００の制御部１５０は、パケットペイロードに含まれた放送コンテンツ、及び放送コンテンツと関連する向上したコンテンツのうちの少なくとも１つを提供するための付加的な情報を、受信した伝送パケットから抽出することができる。

一実施例において、放送受信装置１００の制御部１５０は、ペイロードヘッダーから、ペイロード誤り判断情報、ペイロード優先順位情報及びペイロードタイプ情報のうちの少なくとも１つを抽出することができる。具体的に、ペイロード誤り判断情報は、放送パケットに含まれたペイロードに誤りが存在するか否か、または当該ペイロードが定められたシンタックス（ｓｙｎｔａｘ）に違反する内容を含んでいるか否かを示す。

また、優先順位情報は、ペイロードに含まれたデータの優先順位を示す。具体的に、優先順位情報は、ペイロードに含まれたデータの属性情報を示す。例えば、ファイルフォーマットメディアデータのシグナリング情報を含んでいるペイロードの場合、当該パケットの優先順位情報は最も高い優先順位に設定されている。

また、ペイロードタイプ情報は、ペイロードデータを含むパケットペイロードのタイプを示す。例えば、放送送信装置が一つのパケットペイロードに一つのデータをパケット化したか、または複数のパケットペイロードに一つのデータを分けてパケット化したかを示すことができる。

放送受信装置１００は、制御部１５０を介して抽出されたペイロードヘッダーに含まれた情報から、ペイロードに含まれたデータがメディアデータであるか否かを判断する（Ｓ２０５）。具体的に、放送受信装置１００の制御部１５０は、パケットヘッダー情報に基づいて、当該パケットに含まれたペイロードの類型を判断することができる。一実施例において、ペイロードの類型は、放送コンテンツ及び放送コンテンツと関連する向上したコンテンツのうちの少なくとも１つを含むメディアデータであり得る。他の実施例において、ペイロードの類型は、メディアデータを提供するのに必要な付加情報を含むメタデータであり得る。

放送受信装置１００の制御部１５０は、ペイロードに含まれたデータがメディアデータであると判断した場合、全体のメディアデータが、受信した一つの伝送パケットに含まれているか否かを判断する（Ｓ２０７）。具体的な実施例において、伝送パケットの長さと全体のメディアデータの大きさに応じて、一つの伝送パケットに全体のメディアデータを放送送信装置がパケット化することができる。他の実施例において、放送送信装置は、全体のメディアデータを分けてそれぞれ互いに異なる伝送パケットにパケット化することができる。したがって、放送受信装置１００の制御部１５０は、コンテンツの出力のための完全なメディアデータを抽出するために、放送パケットの類型をペイロードヘッダーを通じて判断することができる。

一方、本発明の一実施例において、放送受信装置１００の制御部１５０が、ペイロードに含まれたデータがメディアデータではないと判断した場合は、以下、図６６で詳細に説明する。

一つの伝送パケットに全体のメディアデータが含まれていると判断した場合、制御部１５０は、一つのパケットペイロードからメディアデータを抽出する（Ｓ２０９）。一実施例において、放送受信装置１００の制御部１５０は、一つの伝送パケットから一つのメディアデータのみを抽出することができる。他の実施例において、放送受信装置１００の制御部１５０は、一つの伝送パケットから複数のメディアデータを抽出することができる。一方、一つの伝送パケットに全体のメディアデータが含まれていないと判断した場合、制御部１５０は、ペイロードヘッダー及びセグメンテーションデータヘッダーに基づいて、複数のパケットペイロードからメディアデータを抽出する（Ｓ２１１）。具体的に、制御部１５０は、ペイロードヘッダー及びセグメンテーションデータヘッダーから、分けられてパケット化されたメディアデータの情報を取得することができる。したがって、制御部１５０は、取得した情報によって分けられたメディアデータを識別することができる。言い換えると、制御部１５０は、取得した情報によって分けられたメディアデータの順序を取得することができる。制御部１５０は、当該順序に基づいて互いに異なる伝送パケットから取得したメディアデータを組み合わせる（ｃｏｎｃａｔｅｎａｔｅ）ことができる。

放送受信装置１００は、制御部１５０を介してコンテンツを提供する（Ｓ２１３）。一実施例において、制御部１５０は、抽出したメディアデータに基づいてコンテンツを提供することができる。他の実施例において、制御部１５０は、組み合わされたメディアデータに基づいてコンテンツを提供することができる。

制御部１５０は、Ａ／Ｖコンテンツを出力することができる。他の実施例において、放送受信装置１００は、Ａ／Ｖコンテンツと関連する向上したデータ（ｅｎｈａｎｃｅｍｅｎｔｄａｔａ）を出力することもできる。

図４４は、本発明の実施例に係るパケットの構成を示す。

パケットベースのデータ伝送プロトコル上で、各パケットは、通常、図４０に示されたようにパケットヘッダーとパケットペイロードで構成される。パケットヘッダーは、パケットが含んでいるパケットペイロードの情報を含むことができる。パケットペイロードは、放送網又はインターネット網を介して伝送しようとするメディアデータを含むことができる。パケットペイロードが含むメディアデータは、オーディオ、ビデオ、向上したサービス及び付加情報のうちの少なくともいずれか１つであってもよい。

図４５は、本発明の実施例に係るリアルタイムコンテンツ伝送のためのＲＴＰ（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）パケットの構造を示す。

ＲＴＰパケットは、ＲＴＰヘッダー（ＲＴＰＨｅａｄｅｒ）及びＲＴＰペイロード（ＲＴＰＰａｙｌｏａｄ）を含むことができる。また、ＲＴＰヘッダーは、タイムスタンプ（Ｔｉｍｅｓｔａｍｐ）、同期化ソース識別子（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎｓｏｕｒｃｅｉｄｅｎｔｉｆｉｅｒ）及び寄与ソース識別子（Ｃｏｎｔｒｉｂｕｔｉｎｇｓｏｕｒｃｅｉｄｅｎｔｉｆｉｅｒ）のうちの少なくとも１つを含むことができる。

ＲＴＰヘッダーは、Ｖ（ｖｅｒｓｉｏｎ）フィールド、Ｐ（ｐａｄｄｉｎｇ）フィールド、Ｘ（ｅｘｔｅｎｓｉｏｎ）フィールド、ＣＣフィールド、Ｍ（Ｍａｒｋｅｒｂｉｔ）フィールド、ペイロードタイプフィールド、シーケンス番号（ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ）フィールド及びタイムスタンプフィールドのうちの少なくとも１つのフィールドを含むことができる。

Ｖ（ｖｅｒｓｉｏｎ）フィールドは、当該ＲＴＰのバージョン情報を示す。具体的な実施例において、Ｖ（ｖｅｒｓｉｏｎ）フィールドは２ビットであってもよい。

Ｐ（ｐａｄｄｉｎｇ）フィールドは、ペイロード内にパディングビットが存在するか否かを示す。具体的な実施例において、Ｐ（ｐａｄｄｉｎｇ）フィールドは１ビットであってもよい。

Ｘ（ｅｘｔｅｎｓｉｏｎ）フィールドは、ＲＴＰヘッダー内にエクステンションフィールドが存在するか否かを示す。具体的な実施例において、Ｘ（ｅｘｔｅｎｓｉｏｎ）フィールドは１ビットであってもよい。

ＣＣフィールドは、寄与ソース（Ｃｏｎｔｒｉｂｕｔｉｎｇｓｏｕｒｃｅ）の数を示す。具体的な実施例において、ＣＣフィールドは４ビットであってもよい。

Ｍ（Ｍａｒｋｅｒｂｉｔ）フィールドは、ペイロードタイプに応じて互いに異なる意味を示すことができる。例えば、トランスポートオブジェクト（ｔｒａｎｓｐｏｒｔｏｂｊｅｃｔ）がファイルである場合、ファイルの終わりを示すことができる。他の例として、トランスポートがビデオ又はオーディオデータである場合、関連するアクセスユニット（ａｃｃｅｓｓｕｎｉｔ）の最初又は最後のオブジェクトであることを示すことができる。具体的な実施例において、Ｍ（Ｍａｒｋｅｒｂｉｔ）フィールドは１ビットであってもよい。

ペイロードタイプフィールドは、ＲＴＰペイロードのタイプを示す。具体的な実施例において、ペイロードタイプフィールドは７ビットであってもよい。

シーケンス番号フィールドは、ＲＴＰパケットのシーケンスナンバーを示す。具体的な実施例において、シーケンス番号フィールドは１６ビットであってもよい。

タイムスタンプフィールドは、ＲＴＰパケットと関連する時間情報を示すことができる。タイムスタンプフィールドは、ペイロードタイプフィールドの値によって異なって解釈され得る。具体的な実施例において、Ｔｉｍｅｓｔａｍｐフィールドは３２ビットであってもよい。

ＲＴＰペイロードは、ＲＴＰヘッダーのペイロードタイプに応じてオーディオ／ビデオアクセスユニット（ａｃｃｅｓｓｕｎｉｔ）が含まれ得る。例えば、Ｈ．２６４の場合、ＮＡＬ（ｎｅｔｗｏｒｋａｂｓｔｒａｃｔｌａｙｅｒ）ユニットなどが含まれ得る。

図４６は、本発明の一実施例に係るＩＳＯｂａｓｅｍｅｄｉａｆｉｌｅｆｏｒｍａｔ（以下、「ＩＳＯＢＭＦＦ」という）をベースとするメディアファイルフォーマットを示す。

図４６に示されたように、メディアファイルフォーマットは、通常、１つのｆｔｙｐと１つ又はそれ以上のｍｏｏｖ、ｍｏｏｆ及びｍｄａｔを含むことができる。

ｆｔｙｐは、メディアファイルのタイプ及び適合性を示す。ｆｔｙｐは、メディアファイルにおいて可能な限り前部に位置する。

ｍｏｏｖは、全てのメディアデータのためのコンテナである。具体的に、プレゼンテーションのシングルトラック（ｔｒａｃｋ）のためのコンテナボックスである。プレゼンテーションは、１つ又はそれ以上のトラックで構成されてもよい。それぞれのトラックは、プレゼンテーション内で他のトラックと独立している。一実施例において、トラックは、メディアデータを含むことができ、他の実施例において、トラックは、パケット化されたストリーミングプロトコルのための情報を含むことができる。

ｍｄａｔは、メディアデータのコンテナであり、ｍｏｏｆは、ｍｄａｔに関する情報を含んでいる。

図４７は、本発明の一実施例に係るパケットペイロードのペイロードヘッダーの構成を示す。

現在、リアルタイム伝送プロトコルは、ほとんどメディアファイルのアクセスユニット（ａｃｃｅｓｓｕｎｉｔ）などをベースとして伝送している。具体的に、アクセスユニットとは、メディアファイル又はデータを伝送する最小単位を意味する。したがって、メディアファイルフォーマットベースのデータをリアルタイムで伝送する方案に対する考慮が不足している点がある。

本発明の一実施例に係る放送送信装置は、一つの伝送パケットに含まれたペイロードを介して一つのファイルフォーマットベースのメディアデータを伝送することができる。この場合の伝送パケットは、シングルユニットパケット（Ｓｉｎｇｌｅｕｎｉｔｐａｃｋｅｔ）と呼ぶことができる。他の実施例において、放送送信装置は、一つの伝送パケットに含まれたペイロードを介して複数のファイルフォーマットベースのメディアデータを伝送することができる。この場合の伝送パケットは、アグリゲーションパケット（Ａｇｇｒｅｇａｔｉｏｎｐａｃｋｅｔ）と呼ぶことができる。更に他の一実施例に係る放送送信装置は、一つのファイルフォーマットベースのメディアデータを複数の伝送パケットに分けて伝送することができる。この場合の伝送パケットは、フラグメント化されたパケット（Ｆｒａｇｍｅｎｔｅｄｐａｃｋｅｔ）と呼ぶことができる。更に他の実施例において、放送送信装置は、一つの伝送パケットのペイロードを介して、メディアストリームに対する一つ又は複数のメタデータを伝送することができる。更に他の実施例において、放送送信装置は、一つのメタデータを複数の伝送パケットのペイロードを介して伝送することができる。

また、本発明の一実施例に係る放送送信装置は、様々なプロトコルを介してメディアデータを伝送することができる。上述したプロトコルは、リアルタイム伝送プロトコル（ｒｅａｌ−ｔｉｍｅｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（ＲＴＰ））、非同期階層化コーディング（ａｓｙｎｃｈｒｏｎｏｕｓｌａｙｅｒｅｄｃｏｄｉｎｇ（ＡＬＣ））及び階層化コーディング伝送（ｌａｙｅｒｅｄｃｏｄｉｎｇｔｒａｎｓｐｏｒｔ（ＬＣＴ））のうちの少なくともいずれか１つであってもよい。

具体的に、放送送信装置は、伝送パケットのヘッダーにペイロードタイプに関する情報を示すフィールドを挿入し、当該フィールドを介して、ペイロード内にファイルフォーマットベースのメディアデータが含まれていることを示すことができる。例えば、ＲＴＰの場合、ヘッダーのｐａｙｌｏａｄｔｙｐｅフィールドがペイロードのデータタイプを示し、当該フィールドに特定の値をファイルフォーマットベースのメディアデータのためのｐａｙｌｏａｄｔｙｐｅ値として割り当てることができる。そして、この場合、ＲＴＰパケットヘッダーのＭフィールドは、一つのメディアファイルの終わりを含むデータがパケットのペイロードに含まれたとき、１にセットされてもよい。

上述した課題を解決するために、本発明の一実施例に係るペイロードヘッダーは、ペイロードが含むデータ上に誤り又はシンタックス誤りがあるか否かを示す情報、データの優先順位を示す情報、及びデータのタイプを示す情報のうちの少なくとも１つを含むことができる。この場合、ペイロードヘッダーに含まれたペイロードが含むデータ上に誤り又はシンタックス誤りを示す情報をＦフィールドと呼ぶことができる。一実施例において、ペイロードヘッダーに含まれたペイロードが含むデータ上に誤り又はシンタックス誤りを示す情報は、ｆｏｒｂｉｄｄｅｎ_ｚｅｒｏ_ｂｉｔであって、ペイロードが含むデータ上に誤りが発生したり、シンタックス違反が発生する場合、１にセットされてもよい。具体的に、ペイロードヘッダーに含まれたペイロードが含むデータ上に誤り又はシンタックス誤りを示す情報は、１ビットであってもよい。

また、この場合、ペイロードヘッダーに含まれたデータの優先順位を示す情報は、Ｐｒｉｏｒｉｔｙフィールドと呼ぶことができる。一実施例において、データの優先順位を示す情報は、ペイロードデータの優先順位を示すフィールドである。そして、データの優先順位を示す情報は、ペイロードデータがメディアファイルフォーマット上で重要なメタデータを含むか否かを示すことができる。

ＩＳＯＢＭＦＦを例に挙げると、ｆｔｙｐ又はｍｏｏｖなどを含むペイロードデータの場合、データの優先順位を示す情報は、最も高い順位にセットされてもよい。一実施例において、データの優先順位を示す情報は、放送送信装置の制御部を介して、最も高い優先順位（ｈｉｇｈｅｓｔ）、最も高い優先順位に比べて相対的に低い順位（ｍｅｄｉｕｍ）、最も低い優先順位（ｌｏｗ）を示すことができる。この場合、データの優先順位を示す情報は、最も高い優先順位で０ｘ００、最も高い優先順位に比べて相対的に低い順位で０ｘ０１、そして、最も低い優先順位で０ｘ０２に設定されてもよい。上述した設定値は一つの例示に過ぎず、他の任意の値に設定されてもよい。

また、この場合、データのタイプを示す情報をｔｙｐｅフィールドと呼ぶことができる。具体的に、データのタイプを示す情報を介して、放送受信装置１００の制御部１５０は、伝送パケットが一つのパケットで一つのデータを伝送するパケットであるか、一つのパケットで複数の互いに異なるデータを伝送するパケットであるか、または一つのデータを複数個に分けたデータを伝送するパケットであるかを識別することができる。

また、放送受信装置１００の制御部１５０は、データのタイプを示す情報を介して、伝送パケットがコンテンツの時間情報を含むメタデータを伝送するパケットであるか、または伝送パケットがコンテンツの説明情報を含むメタデータを伝送するパケットであるかを識別することができる。

一実施例において、放送送信装置は、一つのパケットで一つのデータを伝送するパケットの場合、データのタイプを示す情報を０ｘ００に設定することができる。また、放送送信装置は、一つのパケットで複数の互いに異なるデータを伝送するパケットの場合、データのタイプを示す情報を０ｘ０１に設定することができる。また、放送送信装置は、一つのデータを分けたデータを伝送するパケットの場合、データのタイプを示す情報を０ｘ０２に設定することができる。

また、放送送信装置は、メディアデータではなく、コンテンツの再生（ｐｒｅｓｅｎｔａｔｉｏｎ）又はデコーディング（ｄｅｃｏｄｉｎｇ）時間情報を含むメタデータをパケット化して伝送することができる。この場合、放送送信装置は、データのタイプを示す情報を０ｘ０３に設定することができる。一方、上述した時間情報をタイムライン（ｔｉｍｅｌｉｎｅ）データと呼ぶことができる。

また、放送送信装置は、コンテンツの説明情報を含むメタデータをパケット化して伝送することができる。この場合、放送送信装置は、データのタイプを示す情報を０ｘ０４に設定することができる。一方、上述した情報をラベリング（ｌａｂｅｌｉｎｇ）データと呼ぶことができる。

しかし、上述した設定値は一つの実施例に過ぎず、本発明が上述した値によって限定されるものではない。具体的な実施例において、ｔｙｐｅフィールドは５ビットであってもよい。

図４８は、一つのパケットに一つのメディアデータがパケット化された伝送パケットのペイロードの構成を示す。

図示のように、一つのパケットに一つのメディアデータが含まれたパケットをシングルユニットパケット（Ｓｉｎｇｌｅｕｎｉｔｐａｃｋｅｔ）と呼ぶことができる。シングルユニットパケットのペイロードは、ペイロードヘッダー及びペイロードデータを含むことができる。ペイロードデータは、一つのファイルフォーマットベースのメディアデータを含むフラグメント化された（ｆｒａｇｍｅｎｔｅｄ）データを含むことができる。一実施例において、伝送プロトコルが固定長の伝送パケットを使用する場合、ペイロードデータは、フラグメント化されたデータ以外にパディング（ｐａｄｄｉｎｇ）ビットをさらに含むことができる。ここで、パディングビットは、伝送パケットにおいてデータで埋めて残った空間を埋めるためのビットを意味する。

図４９は、一つのパケットに一つのメディアデータがパケット化された伝送パケットのペイロードの構成を示す。

同図は、伝送パケットの具体的な例を示す。図示のように、ペイロードヘッダーは、ペイロードが含むデータ上に誤り又はシンタックス誤りがあるか否かを示す情報、データの優先順位を示す情報、及びデータのタイプを示す情報のうちの少なくとも１つを含むことができる。

図示の一例において、ペイロードが含むデータ上に誤り又はシンタックス誤りがあるか否かを示す情報は、誤り及びシンタックス違反がないという内容を示す値を含むことができる。具体的な実施例において、当該値は０であってもよい。

データの優先順位を示す情報は、ペイロードデータ内のメディアファイルがｆｔｙｐなどの重要なデータを含むので、最も高い優先順位を有することができる。上述したように、ｆｔｙｐの場合、メディアファイルをシグナリングするための情報を含むところ、最も高い優先順位を有することができる。具体的な実施例において、最も高い優先順位を示す値は０ｘ００であってもよい。

データのタイプを示す情報は、一つのパケットペイロード内に一つのメディアファイルが全て含まれているので、シングルユニットパケットを示すことができる。具体的な実施例において、データのタイプを示す情報は０ｘ００の値を有することができる。追加的に、メディアファイルの長さと伝送プロトコルに応じて、パディングビットが選択的にペイロードデータに挿入されてもよい。

図５０は、一つのパケットに複数の互いに異なるメディアデータがパケット化された伝送パケットの構成を示す。

上述したパケットは、アグリゲーションパケット（Ａｇｇｒｅｇａｔｉｏｎｐａｃｋｅｔ）と呼ぶことができる。図５０に示したように、一つの伝送パケットのペイロードが複数の互いに異なるファイルフォーマットベースのメディアデータを含む場合、ペイロードデータは複数のアグリゲーションユニット（Ａｇｇｒｅｇａｔｉｏｎｕｎｉｔ）を含むことができる。それぞれのアグリゲーションユニットは、異なるファイルフォーマットベースのメディアデータを含むことができる。追加的に、伝送プロトコルが固定長のパケットを使用する場合、ペイロードデータはパディング（ｐａｄｄｉｎｇ）ビットを含むことができる。

一実施例において、一つのアグリゲーションユニットは、アグリゲーションユニットの長さを示す情報及びアグリゲーションデータのうちの少なくとも１つを含むことができる。この場合、アグリゲーションユニットの長さを示す情報をＡｇｇｒｅｇａｔｉｏｎｕｎｉｔｌｅｎｇｔｈフィールドと呼ぶことができる。具体的な実施例において、アグリゲーションユニットは１６ビットであってもよい。また、アグリゲーションユニットデータは、一つのファイルが含むデータを示す。

図５１は、アグリゲーションユニットの構成を示す他の実施例を示す図である。

一つのアグリゲーションユニットは、追加的に、アグリゲーションユニット内に含まれたファイルのタイプを示す情報をさらに含むことができる。

アグリゲーションのタイプを示す情報は、Ａｇｇｒｅｇａｔｉｏｎｕｎｉｔｔｙｐｅフィールドと呼ぶことができる。具体的な実施例において、この場合、放送送信装置は、アグリゲーションタイプを０ｘ００に設定することができる。

他の実施例において、アグリゲーションタイプは、ＭＰＥＧ−ＤＡＳＨ（）でのセルフイニシアライジングセグメント（Ｓｅｌｆ−ｉｎｉｔｉａｌｉｚｉｎｇＳｅｇｍｅｎｔ）形態のファイルを当該アグリゲーションユニットが含んでいることを示すことができる。ここで、セルフイニシアライジングセグメントは、別途のイニシアライジングセグメントなしに、イニシアライジングセグメントとメディアセグメントを統合したものである。具体的に、メディアセグメントとメディアセグメントのメディア形態を含むことができる。具体的な実施例において、この場合、放送送信装置は、アグリゲーションタイプを０ｘ０１に設定することができる。

更に他の実施例において、アグリゲーションタイプは、ＭＰＥＧ−ＤＡＳＨでのイニシアライジングセグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）形態のファイルを当該アグリゲーションユニットが含んでいることを示すことができる。ここで、イニシアライジングセグメントは、ＩＳＯＢＭＦＦに従うフォーマットである。具体的に、イニシアライジングセグメントはｆｔｙｐ、ｍｏｏｖを含まなければならない。そして、ｍｏｏｆを含んではならない。具体的な実施例において、この場合、放送送信装置は、アグリゲーションタイプを０ｘ０２に設定することができる。

図５２は、フラグメント化されたパケットのペイロードの構成の一実施例を示す。

同図は、一つのメディアデータが複数の伝送パケットに分けられてパケット化された伝送パケット（以下、「フラグメント化されたパケット（Ｆｒａｇｍｅｎｔｅｄｐａｃｋｅｔ）」という）のペイロードの構成を示す。

図示のように、フラグメント化されたパケットのペイロードはフラグメンテーションユニット（Ｆｒａｇｍｅｎｔａｔｉｏｎｕｎｉｔ）を含むことができる。追加的に、フラグメント化されたパケットのペイロードは、伝送プロトコルが固定長のパケットを使用する場合、パディング（Ｐａｄｄｉｎｇ）ビットが含まれ得る。

一実施例において、フラグメンテーションユニット（ＦＵ）は、フラグメンテーションユニットヘッダー（Ｆｒａｇｍｅｎｔａｔｉｏｎｕｎｉｔｈｅａｄｅｒ）及びフラグメンテーションユニットデータ（Ｆｒａｇｍｅｎｔａｔｉｏｎｕｎｉｔｄａｔａ）のうちの少なくともいずれか１つを含むことができる。フラグメンテーションユニットデータは、一つのファイルフォーマットベースのメディアデータの一部分を含むことができる。フラグメンテーションユニットヘッダーはフラグメンテーションユニットデータの情報を含むことができる。

具体的に、フラグメンテーションユニットヘッダーは、フラグメンテーションユニットデータが全体のファイルメディアデータのうち開始部分のデータを含んでいるか否かを示す情報、フラグメンテーションユニットデータが全体のファイルメディアデータのうち終了部分のデータを含んでいるか否かを示す情報、及びフラグメンテーションユニットのタイプを示す情報のうちの少なくともいずれか１つを含むことができる。

一実施例において、全体のファイルメディアデータのうち開始部分のデータを含んでいるか否かを示す情報をＳｔａｒｔｂｉｔフィールドと呼ぶことができる。具体的に、開始部分のデータは、全体のメディアデータの最初のビットを含む全体のデータの一部であってもよい。

例えば、当該ペイロードのフラグメンテーションユニットデータが開始部分のデータを含んでいる場合、放送送信装置は、全体のファイルメディアデータのうち開始部分のデータを含んでいるか否かを示す情報を１に設定することができる。具体的に、全体のファイルメディアデータのうち開始部分のデータを含んでいるか否かを示す情報は１ビットであってもよい。

一実施例において、全体のファイルメディアデータのうち終了部分のデータを含んでいるか否かを示す情報をＥｎｄｂｉｔフィールドと呼ぶことができる。具体的に、終了部分のデータは、全体のメディアデータの最後のビットを含む全体のデータの一部であってもよい。

例えば、当該ペイロードのフラグメンテーションユニットデータが終了部分のデータを含んでいる場合、放送送信装置は、全体のファイルメディアデータのうち終了部分のデータを含んでいるか否かを示す情報を１に設定することができる。具体的に、全体のファイルメディアデータのうち終了部分のデータを含んでいるか否かを示す情報は１ビットであってもよい。

一実施例において、フラグメンテーションユニットのタイプを示す情報は、フラグメンテーションユニットタイプフィールドと呼ぶことができる。

一実施例において、フラグメンテーションユニットタイプは、当該パケットが、ファイルフォーマットベースの基本的なファイルをフラグメンテーションユニットが含んでいることを示すことができる。具体的に、ファイルフォーマットベースの基本的なファイルは、ＩＳＯＢＭＦＦに基づいたファイルフォーマットを有するメディアファイルであってもよい。具体的な実施例において、この場合、放送送信装置は、フラグメンテーションユニットタイプを０ｘ００に設定することができる。

他の実施例において、フラグメンテーションユニットタイプは、ＭＰＥＧ−ＤＡＳＨ（）でのセルフイニシアライジングセグメント形態のファイルを当該フラグメンテーションユニットが含んでいることを示すことができる。具体的な実施例において、この場合、放送送信装置は、フラグメンテーションユニットタイプを０ｘ０１に設定することができる。

更に他の実施例において、フラグメンテーションユニットタイプは、ＭＰＥＧ−ＤＡＳＨでのイニシアライジングセグメント形態のファイルを当該フラグメンテーションユニットが含んでいることを示すことができる。具体的な実施例において、この場合、放送送信装置は、フラグメンテーションユニットを０ｘ０２に設定することができる。

更に他の実施例において、フラグメンテーションユニットタイプは、ＭＰＥＧ−ＤＡＳＨでのメディアセグメント（ｍｅｄｉａｓｅｇｍｅｎｔ）形態のファイルを当該フラグメンテーションユニット（Ｆｒａｇｍｅｎｔａｔｉｏｎｕｎｉｔ）が含んでいることを示すことができる。具体的な実施例において、この場合、放送送信装置は、フラグメンテーションユニットを０ｘ０３に設定することができる。

具体的に、フラグメンテーションユニットタイプを示す情報は６ビットであってもよい。

図５３は、フラグメント化されたパケットのペイロードの構成の他の実施例を示す。

図示の実施例は、伝送パケットのヘッダーに伝送パケットの順序と関連する情報が存在しない場合に適用することができる。

図示のように、フラグメンテーションユニット（ＦＵ）に含まれたフラグメンテーションユニットヘッダーは、フラグメンテーションユニットデータが全体のファイルメディアデータのうち開始部分のデータを含んでいるか否かを示す情報、フラグメンテーションユニットデータが全体のファイルメディアデータのうち終了部分のデータを含んでいるか否かを示す情報、フラグメンテーションユニットのタイプを示す情報、及びフラグメンテーションユニットの全体のデータでの順序を示す情報のうちの少なくとも１つを含むことができる。上述した情報のうちフラグメンテーションユニットの順序を示す情報を除いた残りの情報は、前述した内容と同一である。

フラグメンテーションユニットの順序を示す情報は、Ｆｒａｇｍｅｎｔａｔｉｏｎｎｕｍｂｅｒフィールドと呼ぶこともできる。具体的に、放送送信装置は、ファイルフォーマットベースのメディアデータが複数のフラグメント化されたパケットに分けられた場合、フラグメンテーションユニットの順序を示す情報に値を設定し、当該パケットの順序を割り当てる。具体的に、Ｆｒａｇｍｅｎｔａｔｉｏｎｎｕｍｂｅｒフィールドは８ビットであってもよい。

図５４は、本発明の一実施例において、放送送信装置がＩＳＯＢＭＦＦベースのメディアファイルをフラグメンテーションして複数個のパケットに分けることを示す。

図５４に示されたように、ＩＳＯＢＭＦＦベースのメディアファイルは、ｆｔｙｐ、ｍｏｏｖ、及び複数のｍｏｏｆ及びｍｄａｔを含むことができる。

放送送信装置は、ＩＳＯＢＭＦＦベースのメディアファイルを複数個に分け、それぞれ互いに異なるフラグメンテーションユニットデータに含ませることができる。また、放送送信装置は、ＩＳＯＢＭＦＦベースのメディアファイルを分けると共に、ペイロードヘッダーに関連情報を含ませることができる。

図５５は、放送送信装置がパケット化した第１フラグメンテーションユニットデータの具体的な実施例を示す。

図示のように、本発明の一実施例において、放送送信装置は、ペイロードヘッダーのＦフィールドを、当該パケットに誤り又はシンタックスの誤りがないものと判断し、０に設定する。

また、放送送信装置は、Ｐｒｉｏｒｉｔｙフィールドを、最も高い優先順位を示す値に設定することができる。具体的に、当該値は０ｘ００であってもよい。

また、放送送信装置は、Ｔｙｐｅフィールドを、当該パケットが一つのファイルフォーマットベースのメディアファイルを複数のペイロードに分けて伝送するパケットを示す値に設定することができる。具体的に、当該値は０ｘ０２であってもよい。

ペイロードデータはフラグメンテーションユニットを含むことができ、再びフラグメンテーションユニットは、Ｓｔａｒｔｂｉｔフィールド、Ｅｎｄｂｉｔフィールド、フラグメンテーションユニットタイプフィールド、及びフラグメンテーションユニットデータフィールドを含むことができる。

放送送信装置は、Ｓｔａｒｔｂｉｔフィールドを、当該パケットがメディアファイルの開始データを含む内容を示す値に設定することができる。具体的に、図５４で、第１フラグメンテーションユニットがメディアデータの開始データを含んでいるところ、放送送信装置は、当該内容を示す値をｓｔａｒｔｂｉｔフィールドに設定することができる。

一方、放送送信装置は、図５５で例として挙げている第１フラグメンテーションユニットのＥｎｄｂｉｔフィールドを、メディアファイルの終了データを含んでいないという内容を示す値に設定することができる。具体的な実施例において、放送送信装置は、当該パケットがメディアファイルの終了データを含んでいないという内容を示すために、Ｅｎｄｂｉｔフィールドを０に設定することができる。

一方、放送送信装置は、図５５で例として挙げているフラグメンテーションユニットタイプフィールドを、第１フラグメンテーションユニットがファイルフォーマットベースの基本的な形態のファイルを含んでいるという内容を示す値に設定することができる。具体的に、ファイルフォーマットベースの基本的な形態とは、ＩＳＯＢＭＦＦに従うファイルフォーマットデータであってもよい。具体的な実施例において、放送送信装置は、フラグメンテーションユニットタイプフィールドを０ｘ００に設定して当該内容を示すことができる。

図５６は、フラグメンテーションユニットデータのうち開始データを除いた残りのデータを含むフラグメンテーションユニットの一実施例を示す。

図示のように、本発明の一実施例において、放送送信装置は、ペイロードヘッダーのＦフィールドを、当該パケットに誤り又はシンタックスの誤りがないことを示す値に設定する。具体的な実施例において、放送送信装置は、Ｆフィールドを０に設定することができる。また、放送送信装置は、図５６に示されたペイロードデータが相対的に低い優先順位を有することを示す値にＰｒｉｏｒｉｔｙフィールドを設定する。

具体的な実施例において、第２フラグメンテーションユニットからは、全体のメディアデータをシグナリングするデータを含まなくてもよい。したがって、第１フラグメンテーションユニットよりも優先順位が相対的に低いところ、Ｐｒｉｏｒｉｔｙフィールドが、相対的に低い優先順位を有する値に設定され得る。例えば、当該値は０ｘ０１であってもよい。

また、放送送信装置は、Ｔｙｐｅフィールドを、当該パケットが一つのファイルフォーマットベースのメディアファイルを複数のペイロードに分けて伝送するパケットを示すＦｒａｇｍｅｎｔｅｄｐａｃｋｅｔとして０ｘ０２に設定する。

図５７は、ペイロードデータが、開始データを含むフラグメンテーションユニットデータ及び終了データを含むフラグメンテーションユニットデータを含まない場合のペイロードの構成を示す。

本発明の一実施例において、放送送信装置は、フラグメンテーションユニットデータが開始データ及び終了データを含んでいないところ、ｓｔａｒｔｂｉｔフィールド及びｅｎｄｂｉｔフィールドを、当該情報を示す値に設定することができる。具体的な実施例において、放送送信装置は、ｓｔａｒｔｂｉｔ及びｅｎｄｂｉｔフィールドをいずれも０に設定することができる。

また、放送送信装置は、フラグメンテーションユニットタイプフィールドを、ファイルフォーマットベースの基本的な形態のファイルを含んでいるという内容をフラグメンテーションユニットタイプフィールドの特定の値として設定することができる。具体的に、ファイルフォーマットベースの基本的な形態とは、ＩＳＯＢＭＦＦに従うファイルフォーマットデータであってもよい。具体的な実施例において、放送送信装置は、フラグメンテーションユニットタイプフィールドを０ｘ００に設定して当該内容を示すことができる。パケットに分けられたそれぞれのファイルフォーマットベースのメディアデータは、全体のファイルにおいて固有の順序を有することができる。放送受信装置１００は、制御部１５０を介して分けられたフラグメンテーションユニットデータが全体のデータのうち開始部分を含むことを、Ｓｔａｒｔｂｉｔフィールドに基づいて識別することができる。また、フラグメンテーションユニットデータが全体のデータのうち終了部分を含むことを、Ｅｎｄｂｉｔフィールドに基づいて識別することができる。しかし、Ｓｔａｒｔｂｉｔフィールド及びＥｎｄｂｉｔフィールドのみで識別できない場合があり得る。

フラグメンテーションユニットデータが全体のデータのうち開始データ又は終了データを含んでいない場合、放送受信装置１００は、一実施例において、ペイロードに含まれたフラグメンテーションユニットデータの順序を示す情報を介して当該パケットを識別することができる。具体的に、フラグメンテーションユニットデータの順序を示す情報は、フラグメンテーションナンバーフィールドであってもよい。また、放送送信装置は、当該フラグメンテーションユニットデータの順序を、上述したフラグメンテーションフィールドに設定することができる。

しかし、他の実施例において、伝送パケットは、フラグメンテーションユニットデータの順序情報を含まなくてもよい。この場合、一実施例において、放送送信装置は、パケットヘッダーにフラグメンテーションユニットデータの順序を識別するための情報を挿入することができる。パケットヘッダーに含まれたフラグメンテーションユニットデータの順序を識別するための情報は、シーケンスナンバー（Ｓｅｑｕｅｎｃｅｎｕｍｂｅｒ）フィールドと呼ぶことができる。更に他の実施例において、放送送信装置は、ＩＰデータグラムのオフセット（ｏｆｆｓｅｔ）情報に、フラグメンテーションユニットデータの順序を識別するための情報を挿入することもできる。

図５８は、分けられた全体のメディアデータのうち終了データを含むフラグメンテーションユニットを含むペイロードの構成を示す。具体的に、同図は、ペイロードデータが、開始データを含むフラグメンテーションユニットデータを含んではいないが、終了データを含むフラグメンテーションユニットデータを含む場合のペイロードの構成を示す。

本発明の一実施例において、放送送信装置は、図５８のフラグメンテーションユニットデータが終了データを含んでいるところ、ｓｔａｒｔｂｉｔフィールド及びｅｎｄｂｉｔフィールドを、当該情報を示す値に設定することができる。具体的な実施例において、放送送信装置は、ｓｔａｒｔｂｉｔを０に設定することができる。そして、放送送信装置は、ｅｎｄｂｉｔフィールドを１に設定することができる。

また、放送送信装置は、フラグメンテーションユニットタイプフィールドを、当該パケットが含むメディアデータがＩＳＯＢＭＦＦベースのｆｔｙｐから始まる基本的な形態のファイルを含む内容を示すように設定することができる。具体的な実施例において、放送送信装置は、フラグメンテーションユニットタイプフィールドを０ｘ００に設定することができる。

放送送信装置が伝送パケットを介して伝送できるデータは、上述したメディアデータと共にメタデータ（ｍｅｔａｄａｔａ）があり得る。

メタデータは、メディアデータを提供するために必要な付加情報を示す。以下、図５９乃至図６６では、メタデータを伝送パケットにパケット化して送信及び受信する放送送信装置、放送送信装置の動作方法、放送受信装置及び放送受信装置の動作方法を提案する。

また、以下では、メタデータの一例として、タイムライン（ｔｉｍｅｌｉｎｅ）情報を中心に説明する。タイムライン情報とは、メディアコンテンツのための一連の時間情報である。具体的に、タイムライン情報は、再生（ｐｒｅｓｅｎｔａｔｉｏｎ）又はデコードするための一連の時間情報であってもよい。

また、タイムライン情報は、基本タイムライン（Ｂａｓｅｔｉｍｅｌｉｎｅ）情報を含むことができる。基本タイムラインとは、複数の互いに異なる伝送網を介して伝送されるメディアデータを同期化するために必要な基準タイムラインを意味する。具体的に、第１伝送網を介して伝送されるメディアデータのタイムラインに、第２伝送網を介して伝送されるメディアデータのタイムラインをマップする場合、第１伝送網を介して伝送されるメディアデータのタイムラインが基本タイムラインとなる。

一方、放送送信装置は、メタデータをＸＭＬのフォーマットで表現することができる。また、放送送信装置は、メタデータを、シグナリングテーブルに含まれ得るディスクリプタの形態で表現することもできる。

図５９は、本発明の一実施例に係るメタデータのタイムラインシグナリングテーブルを示す。

本発明の一実施例において、タイムラインシグナリングテーブルは、タイムラインと関連するメタデータであることを示す情報、または当該メタデータがタイムラインコンポーネントアクセスユニット（ｔｉｍｅｌｉｎｅｃｏｍｐｏｎｅｎｔａｃｃｅｓｓｕｎｉｔ）構造を含んでいることを示す情報を含むことができる。上述した情報をｉｄｅｎｔｉｆｉｅｒフィールドと呼ぶことができる。具体的な実施例において、ｉｄｅｎｔｉｆｉｅｒフィールドは８ビットであってもよい。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、タイムラインコンポーネントアクセスユニットのタイムライン情報の長さを示す情報を含むことができる。上述した情報をＡＵ_ｌｅｎｇｔｈフィールドと呼ぶことができる。具体的な実施例において、ＡＵ_ｌｅｎｇｔｈフィールドは３２ビットであってもよい。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、タイムラインコンポーネントアクセスユニットと関連するサービス、及びコンテンツコンポーネントに関する位置情報を含んでいるか否かを示す情報を含むことができる。上述した情報をｌｏｃａｔｉｏｎ_ｆｌａｇフィールドと呼ぶことができる。具体的な実施例において、ｌｏｃａｔｉｏｎ_ｆｌａｇフィールドは１ビットであってもよい。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、タイムラインコンポーネントアクセスユニットが含むタイムスタンプ（ｔｉｍｅｓｔａｍｐ）のバージョン情報を含むことができる。タイムスタンプとは、連続的なタイムラインにおいて当該アクセスユニットが出力されなければならない時間情報を示す。上述した情報をｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎフィールドと呼ぶことができる。具体的な実施例において、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎフィールドは１ビットであってもよい。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、タイムラインコンポーネントアクセスユニットのタイムスタンプタイプ情報を含むことができる。上述した情報をｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールドと呼ぶことができる。

一実施例において、タイムスタンプタイプ情報は、タイムラインコンポーネントアクセスユニットと関連するサービス又はコンテンツコンポーネントのデコーディング時点を示す値が設定されてもよい。具体的に、コンテンツコンポーネントのデコーディング時点は、デコーディングタイムスタンプ（ｄｅｃｏｄｉｎｇｔｉｍｅｓｔａｍｐ）と呼ぶことができる。具体的な一実施例において、放送送信装置は、タイムスタンプタイプ情報を、当該情報がデコーディング時点を示す場合、０ｘ００に設定することができる。

他の実施例において、タイムスタンプタイプ情報は、タイムラインコンポーネントアクセスユニットと関連するサービス又はコンテンツコンポーネントの再生時点を示す値が設定されてもよい。具体的に、コンテンツコンポーネントの再生時点は、プレゼンテーションタイムスタンプ（Ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅｓｔａｍｐ）と呼ぶことができる。具体的な一実施例において、放送送信装置は、タイムスタンプタイプ情報を、当該情報がプレゼンテーション時点を示す場合、０ｘ０１に設定することができる。

一方、具体的な実施例において、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールドは１ビットであってもよい。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、タイムラインコンポーネントアクセスユニットのタイムスタンプフォーマット情報を含むことができる。上述した情報をｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドと呼ぶことができる。

一実施例において、タイムスタンプフォーマット情報は、タイムラインコンポーネントアクセスユニットが含むタイムスタンプがメディアタイム（Ｍｅｄｉａｔｉｍｅ）のフォーマットであることを示すことができる。具体的な実施例において、放送送信装置は、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドを０ｘ００に設定して、当該アクセスユニットのタイムスタンプフォーマットがメディアタイムフォーマットであることを示すことができる。

他の実施例において、タイムスタンプフォーマット情報は、タイムラインコンポーネントアクセスユニットに含まれたタイムスタンプがネットワークタイムプロトコル（Ｎｅｔｗｏｒｋｔｉｍｅｐｒｏｔｏｃｏｌ（ＮＰＴ））のフォーマットであることを示すことができる。具体的な実施例において、放送送信装置は、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドを０ｘ０１に設定して、当該アクセスユニットのタイムスタンプフォーマットがＮＰＴフォーマットであることを示すことができる。

他の実施例によれば、タイムスタンプフォーマット情報は、タイムラインコンポーネントアクセスユニットに含まれるタイムスタンプがＭＰＥＧＤＡＳＨメディアプレゼンテーションタイムのフォーマットであることを示すことができる。特定の実施例によれば、放送送信装置は、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドを０ｘ０２に設定して、当該アクセスユニットのタイムスタンプフォーマットがＭＰＥＧＤＡＳＨメディアプレゼンテーションタイムであることを示すことができる。メディアタイムを示すｍｅｄｉａ_ｔｉｍｅフィールドは、ＭＰＥＦＤＡＳＨのメディアプレゼンテーションタイムを示すことができる。

他の実施例によれば、タイムスタンプフォーマット情報は、タイムラインコンポーネントアクセスユニットに含まれるタイムスタンプがＮＰＴ（ｎｏｗｐｌａｙｉｎｇｔｉｍｅ）のフォーマットであることを示すことができる。特定の実施例によれば、放送送信装置は、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドを０ｘ０３に設定して、当該アクセスユニットのタイムスタンプフォーマットがＮＰＴフォーマットであることを示すことができる。

他の実施例によれば、タイムスタンプフォーマット情報は、タイムラインコンポーネントアクセスユニットに含まれるタイムスタンプがタイムコードのフォーマットであることを示すことができる。特定の実施例によれば、放送送信装置は、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドを０ｘ０４に設定して、当該アクセスユニットのタイムスタンプフォーマットがタイムコードフォーマットであることを示すことができる。また、本発明の特定の実施例によれば、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドは４ビットフィールドであってもよい。

他の実施例によれば、タイムスタンプフォーマット情報は、タイムラインコンポーネントアクセスユニットに含まれるタイムスタンプがＰＴＰ（ｐｒｅｃｉｓｉｏｎｔｉｍｅｐｒｏｔｏｃｏｌ）のフォーマットであることを示すことができる。

他の実施例によれば、タイムスタンプフォーマット情報は、将来の使用のために予備として残した０ｘ０５〜０ｘ０Ｅの値を有する。

他の実施例によれば、タイムスタンプフォーマット情報は、個人使用のためのタイムスタンプフォーマットを示す値（０ｘ０Ｆ）を有することができる。

また、本発明の実施例によれば、タイムラインシグナリングテーブルは、タイムラインコンポーネントアクセスユニットに含まれるタイムライン内の情報と関連するサービス又はコンテンツのコンポーネントに対する位置情報を含むことができる。前記情報は、位置フィールドと呼ぶことができる。位置フィールドは、ＭＰＥＧＤＡＳＨの識別子ＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）又はストリーム、コンテンツコンポーネントまたはサービスのＭＰＤＵＲＬを示すことができる。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、上述した位置情報の長さを示す情報を含むことができる。位置情報の長さを示す情報をｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈフィールドと呼ぶことができる。具体的な実施例において、ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈフィールドは８ビットであってもよい。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、タイムラインマッチングの基準となり得る基本タイムラインのタイムスタンプフォーマットバージョン情報を含むことができる。上述した情報をｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎフィールドと呼ぶことができる。

一実施例において、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎフィールドが０に設定されると、タイムスタンプフォーマットが３２ビットフォーマットを有することを示すことができる。他の一実施例において、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎフィールドが１に設定されると、タイムスタンプフォーマットが６４ビットフォーマットを有することを示すことができる。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、基本タイムラインのタイムスタンプタイプ情報を含むことができる。上述した情報をｏｒｉｇｉｎｅ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールドと呼ぶことができる。

一実施例において、ｏｒｉｇｉｎｅ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールドは、基本タイムラインと関連するサービス又はコンテンツコンポーネントのデコーディング時点を示す値が設定されてもよい。具体的に、コンテンツコンポーネントのデコーディング時点は、デコーディングタイムスタンプ（ｄｅｃｏｄｉｎｇｔｉｍｅｓｔａｍｐ）と呼ぶことができる。具体的な一実施例において、放送送信装置は、当該情報がデコーディング時点を示す場合、ｏｒｉｇｉｎｅ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールドを０ｘ００に設定することができる。

他の実施例において、ｏｒｉｇｉｎｅ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールドは、基本タイムラインと関連するサービス又はコンテンツコンポーネントの再生時点を示す値が設定されてもよい。具体的に、コンテンツコンポーネントの再生時点は、プレゼンテーションタイムスタンプ（Ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅｓｔａｍｐ）と呼ぶことができる。具体的な一実施例において、放送送信装置は、当該情報がプレゼンテーション時点を示す場合、ｏｒｉｇｉｎｅ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールドを０ｘ０１に設定することができる。

本発明の一実施例において、タイムラインシグナリングテーブルは、基本タイムラインに対するタイムスタンプフォーマットを示す情報を含むことができる。上述した情報をｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドと呼ぶことができる。

一実施例において、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドは、基本タイムラインのタイムスタンプがメディアタイム（Ｍｅｄｉａｔｉｍｅ）のフォーマットであることを示すことができる。具体的な実施例において、放送送信装置は、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドを０ｘ００に設定して、当該基本タイムラインのタイムスタンプフォーマットがメディアタイムフォーマットであることを示すことができる。

他の実施例において、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドは、基本タイムラインのタイムスタンプがネットワークタイムプロトコル（Ｎｅｔｗｏｒｋｔｉｍｅｐｒｏｔｏｃｏｌ（ＮＰＴ））のフォーマットであることを示すことができる。具体的な実施例において、放送送信装置は、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドを０ｘ０１に設定して、当該基本タイムラインのタイムスタンプフォーマットがＮＰＴフォーマットであることを示すことができる。

更に他の実施例によれば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドは、基本タイムラインのタイムスタンプがＭＰＥＧＤＡＳＨメディアプレゼンテーションタイムのフォーマットであることを示すことができる。特定の実施例によれば、放送送信装置は、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドを０ｘ０２に設定して、当該基本タイムラインのタイムスタンプフォーマットがＭＰＥＧＤＡＳＨメディアプレゼンテーションタイムであることを示すことができる。

更に他の実施例によれば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドは、基本タイムラインのタイムスタンプがＮＰＴ（ｎｏｗｐｌａｙｉｎｇｔｉｍｅ）のフォーマットであることを示すことができる。特定の実施例によれば、放送送信装置は、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドを０ｘ０３に設定して、当該基本タイムラインのタイムスタンプフォーマットがＮＰＴフォーマットであることを示すことができる。

更に他の実施例によれば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドは、基本タイムラインのタイムスタンプがタイムコードのフォーマットであることを示すことができる。特定の実施例によれば、放送送信装置は、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドを０ｘ０４に設定して、当該基本タイムラインのタイムスタンプフォーマットがタイムコードフォーマットであることを示すことができる。

更に他の実施例によれば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドは、基本タイムラインのタイムスタンプがＰＴＰ（ｐｒｅｃｉｓｉｏｎｔｉｍｅｐｒｏｔｏｃｏｌ）のフォーマットであることを示すことができる。

ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドに対する値（０ｘ０５〜０ｘ０Ｅ）は、将来の使用のために予備として残す。

ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドは、このフィールドが個人使用のために使用されることを示す値（０ｘ０Ｆ）を有することができる。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、タイムラインマッピングの基準となり得る基本タイムラインと関連するサービス及びコンテンツコンポーネントの位置情報を含んでいるか否かを示す情報を含むことができる。上述した情報をｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ_ｆｌａｇフィールドと呼ぶことができる。一実施例において、ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ_ｆｌａｇフィールドが０以外の値に設定される場合、タイムラインＡＵ（ｔｉｍｅｌｉｎｅＡＵ）は、ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈフィールド及びｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎフィールドのうちの少なくともいずれか１つを含むことができる。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、基本タイムラインと関連するサービス又はコンテンツに対する位置情報を含むことができる。上述した情報はｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎフィールドと呼ぶことができる。具体的な一実施例において、ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎフィールドに含まれた情報は、ＩＰアドレス、ポートナンバーまたはＵＲＩ形態であってもよい。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、基本タイムラインと関連するサービス又はコンテンツに対する位置情報の長さ情報を含むことができる。上述した情報をｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈフィールドと呼ぶことができる。具体的な実施例において、ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈフィールドは８ビットであってもよい。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、タイムラインマッピングの基準となる基本タイムラインがメディアタイムの形態である場合、使用可能なタイムスケール（ｔｉｍｅｓｃａｌｅ）の情報を含むことができる。上述した情報をｏｒｉｇｉｎ_ｔｉｍｅｓｃａｌｅフィールドと呼ぶことができる。例えば、ＭＰＥＧ−２ＴＳの場合、タイムスケールは９０００Ｈｚを示すことができる。具体的な実施例において、ｏｒｉｇｉｎ_ｔｉｍｅｓｃａｌｅフィールドは３２ビットであってもよい。

また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムライン上のメディアタイム情報を含むことができる。上述した情報をｏｒｉｇｉｎ_ｍｅｄｉａ_ｔｉｍｅフィールドと呼ぶことができる。一方、ｏｒｉｇｉｎ_ｍｅｄｉａ_ｔｉｍｅフィールドは、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅに応じてその意味が変わり得る。例えば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅがＰＴＳを意味する場合、ｏｒｉｇｉｎ_ｍｅｄｉａ_ｔｉｍｅフィールドは再生時点を示すことができる。他の例として、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅがＤＴＳを意味する場合、ｏｒｉｇｉｎ_ｍｅｄｉａ_ｔｉｍｅフィールドはデコーディング時点を示すことができる。具体的な実施例において、ｏｒｉｇｉｎ_ｍｅｄｉａ_ｔｉｍｅフィールドは、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎフィールドが０に設定された場合、３２ビットであってもよく、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎフィールドが１に設定された場合、６４ビットであってもよい。

また、本発明の一実施例において、タイムラインシグナリングテーブルは、基本タイムラインのタイムスタンプ情報を含むことができる。上述した情報をｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐフィールドと呼ぶことができる。基本タイムラインタイムスタンプ情報は、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドの値に応じて互いに異なるフォーマットのタイムスタンプを示すことができる。また、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールドの値に応じて、基本タイムラインタイムスタンプ情報が互いに異なる意味を示すことができる。例えば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールドがＰＴＳをシグナリングする場合、基本タイムラインタイムスタンプ情報は再生時間を示すことができる。

例えば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールドがＤＴＳを示し、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドが０ｘ０１である場合、当該ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐフィールドは、ＮＴＰで表現されたデコーディング時点を示すことができる。具体的な実施例において、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐフィールドは、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎフィールドが０である場合、３２ビットであってもよく、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎフィールドが１である場合、６４ビットであってもよい。

一実施例において、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔフィールドがリザーブド（ｒｅｓｅｒｖｅｄ）を示す場合、タイムラインＡＵは、ｐｒｉｖａｔｅ_ｄａｔａ_ｌｅｎｇｔｈフィールド及びｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅｓ（）フィールドのうちの少なくともいずれか１つを含むことができる。

ｐｒｉｖａｔｅ_ｄａｔａ_ｌｅｎｇｔｈフィールドは、ｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅｓ（）フィールドのバイト単位の長さを示すことができる。具体的な実施例において、ｐｒｉｖａｔｅ_ｄａｔａ_ｌｅｎｇｔｈフィールドは１６ビットであってもよい。

ｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅｓ（）フィールドは、ｐｒｉｖａｔｅ_ｄａｔａ_ｌｅｎｇｔｈフィールドが示す長さだけｐｒｉｖａｔｅｌｙを定義したり、将来の拡張内容を含むことができる。

図６０は、伝送パケットのペイロードデータに一つのメタデータがパケット化されたペイロードデータの構成を示す。

一実施例において、ペイロードデータはメタデータを含むことができ、メタデータはメディアストリーム関連タイムラインデータを含むことができる。また、一実施例において、放送送信装置が伝送プロトコルとして固定長のパケットを使用する場合、ペイロードデータはパディングビットをさらに含むことができる。

図６１は、伝送パケットのペイロードデータがタイムラインに対するメタデータを含む場合の一実施例を示す。

一実施例において、ペイロードヘッダーは、Ｆフィールド、Ｐｒｉｏｒｉｔｙフィールド及びＴｙｐｅフィールドのうちの少なくとも１つを含むことができる。

一実施例において、放送送信装置は、Ｆフィールドを、ペイロード内に誤りが存在せず、シンタックス違反もないことを示す値に設定することができる。具体的に、放送送信装置は、Ｆフィールドを０に設定することができる。また、放送送信装置は、Ｐｒｉｏｒｉｔｙフィールドを、ペイロードデータがメディアファイル構成の重要なデータを全て含むところ、最も高い優先順位を示す値に設定することができる。具体的に、放送送信装置は、Ｐｒｉｏｒｉｔｙフィールドを０ｘ００に設定することができる。また、放送送信装置は、Ｔｙｐｅフィールドを、ペイロード内にタイムライン情報のメタデータを含む情報を示す値に設定することができる。具体的に、放送送信装置は、Ｔｙｐｅフィールドを０ｘ０３に設定することができる。また、メタデータは、前述したシンタックスを含むことができる。

図６２は、一つの伝送パケットに多数のメタデータがパケット化された場合を示す。

図示のように、一つの伝送パケットが多数のメタデータを含む場合をアグリゲーションパケット（Ａｇｇｒｅｇａｔｉｏｎｐａｃｋｅｔ）と呼ぶことができる。一実施例において、ペイロードデータは、複数のアグリゲーションユニットを含むことができる。

アグリゲーションパケットは、メディアストリーム、ビデオデータのペイロード、またはオーディオデータのペイロードのためのメタデータを含むことができる。

一実施例において、アグリゲーションユニットは、メタデータの長さを示す情報を含むことができる。他の実施例において、アグリゲーションユニットは、メタデータヘッダーフィールドが別途に存在する場合、メタデータヘッダーフィールドとメタデータフィールドの長さの和を示す情報を含むことができる。上述した情報は、ｍｅｔａｄａｔａｌｅｎｇｔｈフィールドと呼ぶことができる。

図６３は、一つの伝送パケットが複数のタイムライン情報を含む場合を示す。

具体的に、一つのメディアストリームに関連してそれぞれ基準が異なる複数個のタイムライン情報を一つの伝送パケットが含んでいる場合を示す。一実施例において、伝送パケットはペイロードヘッダーを含むことができ、ペイロードヘッダーの内容は、図６２の内容と同一である。

また、一実施例において、ペイロードデータは２つのアグリゲーションユニットを含むことができる。しかし、ペイロードデータが含むアグリゲーションユニットの個数は２つ以上であってもよい。

一実施例において、それぞれのアグリゲーションユニットは、図６２に示されたように、ｍｅｔａｄａｔａｌｅｎｇｔｈフィールド、ｍｅｔａｄａｔａｈｅａｄｅｒフィールド及びタイムライン情報を含むメタデータフィールドのうちの少なくともいずれか１つを含むことができる。

しかし、図示の第１アグリゲーションユニットは、第１タイムラインを含むメタデータフィールドを含むことができ、第２アグリゲーションユニットは、第２タイムラインを含むメタデータフィールドを含むことができる。具体的な実施例において、それぞれのタイムラインは、互いに異なる基準に基づいたデータを有することができる。例えば、第１タイムラインは、メディアタイムに基づいたデータを有し、第２タイムラインは、ＮＴＰに基づいたデータを有することができる。

図６４は、一つのメタデータを複数個の伝送パケットに分けてパケット化したパケットペイロードを示す。

一実施例において、一つのメタデータの長さが伝送パケットの長さよりも大きい場合があり得、この場合、放送送信装置は、当該メタデータを複数個の伝送パケットに分けて伝送することができる。図６４に示されたように、伝送パケットは、ペイロードヘッダー、メタデータフラグメントヘッダー及びメタデータフラグメントのうちの少なくとも１つを含むことができる。追加的に、伝送プロトコルが固定長のパケットを使用する場合、伝送パケットはパディングビットを含むこともできる。

図示のように、一実施例において、メタデータフラグメントヘッダーは、当該伝送パケットのペイロードデータに含まれたメタデータフラグメントが全体のメタデータの開始部分を含んでいるか否かを示す情報を含むことができる。具体的に、開始部分のデータは、全体のメディアデータの最初のビットを含む全体のデータの一部であってもよい。上述した情報はｓｔａｒｔｂｉｔフィールドと呼ぶことができる。具体的な実施例において、ｓｔａｒｔｂｉｔフィールドは１ビットであってもよい。一実施例において、放送送信装置は、当該伝送パケットが含んでいるメタデータフラグメントが全体のメタデータの開始部分を含んでいる場合に、ｓｔａｒｔｂｉｔを１に設定することができる。

他の一実施例において、メタデータフラグメントヘッダーは、当該伝送パケットのペイロードデータに含まれたメタデータフラグメントが全体のメタデータの終わり部分を含んでいるか否かを示す情報を含むことができる。具体的に、終わり部分のデータは、全体のメディアデータの最後のビットを含む全体のデータの一部であってもよい。上述した情報はｅｎｄｂｉｔフィールドと呼ぶことができる。具体的な実施例において、ｅｎｄｂｉｔフィールドは１ビットであってもよい。一実施例において、放送送信装置は、当該伝送パケットが含んでいるメタデータフラグメントが全体のメタデータの終わり部分を含んでいる場合に、ｅｎｄｂｉｔを１に設定することができる。

更に他の実施例において、メタデータヘッダーは、メタデータタイプを示す情報を含むことができる。上述した情報はｍｅｔａｄａｔａｔｙｐｅフィールドと呼ぶことができる。具体的な実施例において、メタデータタイプが、当該メタデータフラグメントがタイムライン情報を含んでいることを示すことができる。この場合、放送送信装置は、ｍｅｔａｄａｔａｔｙｐｅフィールドを０ｘ００に設定することができる。更に他の実施例において、メタデータタイプが、当該メタデータフラグメントがラベリング関連メタデータを含んでいることを示すことができる。この場合、放送送信装置は、ｍｅｔａｄａｔａｔｙｐｅフィールドを０ｘ０１に設定することができる。また、具体的な実施例において、ｍｅｔａｄａｔａｔｙｐｅフィールドは５ビットであってもよい。

図６５は、メタデータフラグメントヘッダーの更に他の実施例を示す。

ここで、前述した内容と同一の部分の説明は省略する。

本発明の一実施例において、メタデータフラグメントヘッダーは、当該パケットペイロードに含まれたメタデータフラグメントの順序を示す情報を含むことができる。上述した情報は、Ｆｒａｇｍｅｎｔａｔｉｏｎｎｕｍｂｅｒフィールドと呼ぶことができる。放送受信装置１００は、パケットペイロードに含まれたメタデータフラグメント順序情報に基づいて、当該パケットが何番目のメタデータを含んでいるかを判断することができる。

図６６は、本発明の一実施例に係る放送受信装置が放送パケットを受信する動作を示す。

放送受信装置１００の制御部１５０は、図４３のステップＳ２０５において、ペイロードに含まれたデータがメディアデータではないと判断した場合、一つの伝送パケットに全体のメタデータが含まれているか否かを判断する（Ｓ３０１）。具体的に、制御部１５０は、ペイロードヘッダー情報から、ペイロードに含まれたデータがメディアデータではなくメタデータであることを判断することができる。そして、制御部１５０は、当該メタデータ全体が一つの伝送パケットに全て含まれて伝送されたか否かを判断する。上述したように、一つの伝送パケットに１つ又は複数の互いに異なるメタデータが含まれてもよい。または、一つのメタデータが分けられて複数の互いに異なる伝送パケットに含まれてもよい。

本発明の一実施例において、放送受信装置１００の制御部１５０が、一つの伝送パケットに全体のメタデータが含まれていると判断した場合、制御部１５０は、一つのパケットペイロードからメタデータを抽出する（Ｓ３０３）。具体的に、制御部１５０は、ペイロードヘッダーを抽出し、抽出されたペイロードヘッダーに基づいてメタデータを抽出する。一実施例において、制御部１５０は、一つのパケットペイロードから一つのメタデータを抽出することができる。他の実施例において、制御部１５０は、一つのパケットペイロードから複数のメタデータを抽出することもできる。本発明の更に他の実施例において、放送受信装置１００の制御部１５０が、一つのメタデータが複数の伝送パケットに分けられて含まれていると判断することができる。この場合、制御部１５０は、複数のパケットペイロードからメタデータを抽出する（Ｓ３０５）。具体的な実施例において、一つのメタデータが複数の伝送パケットに分けられてパケット化されてもよい。放送受信装置１００の制御部１５０は、パケットペイロードからメタデータシグナリングデータを取得する。そして、制御部１５０は、取得したシグナリングデータに基づいて複数のパケットペイロードからメタデータを抽出することができる。

放送受信装置１００の制御部１５０は、抽出したメタデータに基づいてコンテンツを提供する（Ｓ３０７）。具体的な実施例において、制御部１５０は、メタデータからコンテンツの再生又はデコーディング時間情報を取得することができる。他の実施例において、制御部１５０は、メタデータからコンテンツを説明する情報を取得することもできる。

図６７は、放送網を介してはＲＴＰプロトコルを用いてビデオストリームを伝送し、インターネット網を介してはファイルフォーマットベースのメディアデータを用いてビデオストリームを伝送する場合を示す。この場合、放送受信装置１００は、タイムライン関連メタデータを含むＲＴＰパケットあるいはＩＰ／ＵＤＰパケットを受信した後、ＲＴＰプロトコルベースのビデオストリームと、ＤＡＳＨベースのビデオストリームとの間のタイムラインをマッチングさせ、関連するストリーム間の復号化及び再生を可能にすることができる。

図６８は、本発明の他の実施例による、タイムラインコンポーネントユニット（ｔｉｍｅｌｉｎｅｃｏｍｐｏｎｅｎｔａｃｃｅｓｓｕｎｉｔ）のシンタックス（ｓｙｎｔａｘ）を示す図である。

タイムラインコンポーネントＡＵ（ＴｉｍｅｌｉｎｅｃｏｍｐｏｎｅｎｔＡＵ）は、放送網あるいはインターネット網を介して伝送されるメディアストリームに関連する追加のメタデータを含むことができる。このようなメタデータのうちメディアストリームと関連するタイムラインに対するメタデータを含むタイムラインコンポーネントＡＵが図示されている。

タイムラインコンポーネントＡＵは、ＸＭＬなどの別の形態のフォーマットで表現されてもよい。

タイムラインコンポーネントＡＵは、ｉｄｅｎｔｉｆｉｅｒ情報、ＡＵ_ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ_ｆｌａｇ情報、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｌａｇ情報、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ情報、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔ情報、ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ情報、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ情報、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔ情報、ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ_ｆｌａｇ情報、ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈ情報、ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ情報、ｏｒｉｇｉｎ_ｔｉｍｅｓｃａｌｅ情報、ｏｒｉｇｉｎ_ｍｅｄｉａ_ｔｉｍｅ情報、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ情報、ｐｒｉｖａｔｅ_ｄａｔａ_ｌｅｎｇｔｈ情報、ｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅｓ（）情報、ｔｉｍｅｓｃａｌｅ情報、ｍｅｄｉａ_ｔｉｍｅ情報、ｔｉｍｅｓｔａｍｐ情報、及び／又はｄａｔａ_ｂｙｔｅｓ（）情報を含むことができる。

前述したタイムラインコンポーネントＡＵのシンタックス（Ｓｙｎｔａｘ）に含まれる情報と同一の名称を有する情報についての説明は、前述した説明で代替する。

Ｉｄｅｎｔｉｆｉｅｒ情報は、タイムラインと関連するメタデータであることを示す識別子、またはタイムラインコンポーネントアクセスユニット（ＡＵ）構造を含んでいることを示す識別子であってもよい。

ＡＵ_ｌｅｎｇｔｈ情報は、タイムラインコンポーネントＡＵが含む情報の長さを示すことができる。

ｌｏｃａｔｉｏｎ_ｆｌａｇ情報は、タイムラインコンポーネントＡＵが含む情報と関連するサービス及びコンテンツコンポーネントなどに対する位置情報を含んでいるか否かを示すことができる。

ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｌａｇ情報は、オリジンタイムスタンプ（ｏｒｉｇｉｎｔｉｍｅｓｔａｍｐ）と関連する情報を含むか否かを示すことができる。

ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ情報は、タイムラインコンポーネントＡＵが含むタイムスタンプのバージョン情報を示すことができる。

ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報は、タイムラインコンポーネントＡＵが含むタイムスタンプのタイプを示すことができる。例えば、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報の値が０ｘ００である場合、関連するサービス／コンテンツコンポーネントのアクセスユニット（ａｃｃｅｓｓｕｎｉｔ）などのデータ（例えば、オーディオアクセスユニット（ａｕｄｉｏａｃｃｅｓｓｕｎｉｔ））のデコーディング時点を示すデコーディングタイムスタンプ（ＤＴＳ）を示すことができ、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報の値が０ｘ０１である場合、関連するサービス／コンテンツコンポーネントなどのアクセスユニットなどのデータ（例えば、オーディオアクセスユニット）の再生時点を示すプレゼンテーションタイムスタンプ（ＰＴＳ）を示すことができる。

ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔ情報は、タイムラインコンポーネントＡＵが含むタイムスタンプのフォーマットを示すことができる。例えば、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔ情報の値が０ｘ００である場合、メディアタイム（ｍｅｄｉａｔｉｍｅ）であることを示し、０ｘ０１である場合、ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０２である場合、ＰＴＰであることを示し、０ｘ０３である場合、タイムコード（ｔｉｍｅｃｏｄｅ）であることを示すことができ、将来の拡張のために０ｘ０４〜０ｘ０Ｆの値をリザーブ（ｒｅｓｅｒｖｅ）することができる。

ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈ情報は、ｌｏｃａｔｉｏｎフィールドに対する長さを示すことができる。

ｌｏｃａｔｉｏｎ情報は、タイムラインコンポーネントＡＵが含む情報と関連するサービス及びコンテンツコンポーネントなどに対する位置情報を示すことができる。位置情報は、ＩＰアドレス／ポートナンバー、あるいはＵＲＩなどの形態で示すことができる。

ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ情報は、タイムラインマッピングの基準となり得る基本タイムライン（ｂａｓｅｔｉｍｅｌｉｎｅ）に対するタイムスタンプフォーマットのバージョンを示すことができる。当該フィールドの値が０である場合、３２ビットフォーマットの形式を、１である場合、６４ビットフォーマットの形式を使用していることを示すことができる。例えば、ビデオストリームが放送網を介して伝達され、オーディオストリームがインターネット網を介して伝送される場合、ビデオストリームにオーディオストリームのタイムラインマッピングを行う場合に基準となる基本タイムラインは、放送網で伝達されるビデオストリームのタイムスタンプとなり得る。このような場合、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎは、放送網を介して伝送されるビデオストリームに対するタイムスタンプ形式を示すことができる。

ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報は、タイムラインマッピングの基準となり得る基本タイムラインに対するタイムスタンプのタイプを示すことができる。例えば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報の値が０ｘ００である場合、基本タイムラインと関連するサービス／コンテンツコンポーネントなどのアクセスユニット（ａｃｃｅｓｓｕｎｉｔ）などのデータ（例えば、オーディオアクセスユニット（ａｕｄｉｏａｃｃｅｓｓｕｎｉｔ））のデコーディング時点を示すデコーディングタイムスタンプ（ＤＴＳ）を示すことができ、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報の値が０ｘ０１である場合、基本タイムラインと関連するサービス／コンテンツコンポーネントなどのアクセスユニットなどのデータ（例えば、オーディオアクセスユニット（ａｕｄｉｏａｃｃｅｓｓｕｎｉｔ））の再生時点を示すプレゼンテーションタイムスタンプ（ＰＴＳ）を示すことができる。

ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔ情報は、タイムラインマッピングの基準となり得る基本タイムラインに対するタイムスタンプのフォーマットを示すことができる。例えば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔ情報の値が０ｘ００である場合、メディアタイム（ｍｅｄｉａｔｉｍｅ）であることを示し、０ｘ０１である場合、ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０２である場合、ＰＴＰであることを示し、０ｘ０３である場合、タイムコードであることを示すことができ、０ｘ０４〜０ｘ０Ｆの値は、将来の拡張のためにリザーブ（ｒｅｓｅｒｖｅ）することができる。

ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ_ｆｌａｇ情報は、タイムラインマッピングの基準となり得る基本タイムラインと関連するサービス及びコンテンツコンポーネントなどに対する位置情報を含んでいるか否かを示すことができる。

ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈ情報は、ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎフィールドに対する長さを示すことができる。

ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ情報は、タイムラインマッピングの基準となり得る基本タイムラインと関連するサービス及びコンテンツコンポーネントなどに対する位置情報を示すことができる。ｏｒｉｇｉｎ_ｌｏｃａｔｉｏｎ情報は、ＩＰアドレス／ポートナンバー、あるいはＵＲＩなどの形態で示すことができる。

ｏｒｉｇｉｎ_ｔｉｍｅｓｃａｌｅ情報は、タイムラインマッピングの基準となる基本タイムラインのメディアタイム（ｍｅｄｉａｔｉｍｅ）の表現時に使用できるタイムスケールを示すことができる。例えば、ＭＰＥＧ−２ＴＳの場合、タイムスケールは９０Ｋ値を有することができる。

ｏｒｉｇｉｎ_ｍｅｄｉａ_ｔｉｍｅ情報は、タイムラインマッピングの基準となる基本タイムライン上でメディアタイムを示すことができる。ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅによって、該当するメディアタイムの意味する内容が異なり得る。例えば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅがＰＴＳである場合、ｏｒｉｇｉｎ_ｍｅｄｉａ_ｔｉｍｅ情報は、再生時点に対するメディアタイムを示すことができ、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅがＤＴＳである場合、ｏｒｉｇｉｎ_ｍｅｄｉａ_ｔｉｍｅ情報は、デコーディング時点に対するメディアタイムを示すことができる。ｏｒｉｇｉｎ_ｍｅｄｉａ_ｔｉｍｅ情報は、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎの値が０である場合に３２ビットで、当該フィールドの値が１である場合に６４ビットで表すことができる。

ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ情報は、タイムラインマッピングの基準となる基本タイムライン上で、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔのフィールド値に応じて互いに異なるフォーマットのタイムスタンプを示すことができ、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅによって、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ情報に該当するタイムスタンプの意味が異なり得る。例えば、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｔｙｐｅがＤＴＳを示し、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔの値が‘０ｘ０１’の場合、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ情報の当該タイムスタンプは、ＮＴＰで表現されたデコーディング時点を示すことができる。ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ情報は、ｏｒｉｇｉｎ_ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎの値が０である場合に３２ビットで、当該フィールドの値が１である場合に６４ビットで表すことができる。

ｐｒｉｖａｔｅ_ｄａｔａ_ｌｅｎｇｔｈ情報は、後続するｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅｓのバイト単位の長さを示すことができる。

ｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅｓ（）情報は、ｐｒｉｖａｔｅ_ｄａｔａ_ｌｅｎｇｔｈの長さだけｐｒｉｖａｔｅｌｙを定義したり、将来の拡張内容を含むことができる領域を示す。

ｔｉｍｅｓｃａｌｅ情報は、メディアタイムの表現時に使用できるタイムスケールを示すことができる。

ｍｅｄｉａ_ｔｉｍｅ情報はメディアタイムを示すことができる。ｔｉｍｅｓｔａｍｐ_ｔｙｐｅによって、ｍｅｄｉａ_ｔｉｍｅ情報に該当するメディアタイムの意味する内容が異なり得る。例えば、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅがＰＴＳである場合、ｍｅｄｉａ_ｔｉｍｅ情報は、再生時点に対するメディアタイムを示すことができる。ｍｅｄｉａ_ｔｉｍｅ情報は、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎの値が０である場合に３２ビットで、当該フィールドの値が１である場合に６４ビットで表すことができる。

ｔｉｍｅｓｔａｍｐ情報は、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔのフィールド値に応じて互いに異なるフォーマットのタイムスタンプを示すことができ、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅによって、ｔｉｍｅｓｔａｍｐ情報に該当するタイムスタンプの意味が異なり得る。例えば、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅがＤＴＳを示し、ｔｉｍｅｓｔａｍｐ_ｆｏｒｍａｔの値が‘０ｘ０１’の場合、ｔｉｍｅｓｔａｍｐ情報に該当するｔｉｍｓｔａｍｐは、ＮＴＰで表現されたデコーディング時点を示すことができる。ｔｉｍｅｓｔａｍｐ情報は、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎの値が０である場合に３２ビットで、当該フィールドの値が１である場合に６４ビットで表すことができる。

ｄａｔａ_ｂｙｔｅｓ（）情報は、将来の拡張内容を含むできるようにするフィールド又は領域を示す。

ＭＰＥＧＤＡＳＨの特定のタイムスケール（例えば、１００００ｈｚ）で表現されるメディアプレゼンテーションタイム（ｍｅｄｉａｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅ）を、ＮＴＰベースのタイムスタンプとマッピングさせることができるようにすることによって、ＲＴＰプロトコルを介して伝達されるオーディオ／ビデオストリームなどのデータと、ＭＰＥＧＤＡＳＨを介して伝達されるオーディオ／ビデオなどのデータとをＮＴＰなどの基本タイムラインをベースとして同期化して、放送コンテンツを復号又は再生することができる。

図６９は、本発明の一実施例に係る、リアルタイムコンテンツ伝送プロトコル上でメディアの同期化をサポートするための伝送パケットフォーマットを示す図である。

リアルタイムコンテンツ伝送をサポートする伝送プロトコル、例えば、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ）の場合、ＲＴＰパケットは、オーディオアクセスユニット又はビデオネットワークアブストラクションレイヤ（ｎｅｔｗｏｒｋａｂｓｔｒａｃｔｉｏｎｌａｙｅｒ；ＮＡＬ）ユニットを含むことができる。ＲＴＰ上で複数のオーディオ／ビデオストリーム間の同期を取って復号及び／又は再生をサポートするためにＲＴＣＰ（ＲＴＰｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ）パケットを用いることができる。送信端で生成する、ＲＴＣＰ（ＲＴＰｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ）パケットは、各ＲＴＰパケットヘッダーに含まれるＲＴＰタイムスタンプとＮＴＰ（Ｎｅｔｗｏｒｋｔｉｍｅｐｒｏｔｏｃｏｌ）との間のマッチング関係を含み、受信端では、当該情報を用いて、ストリーム間の復号化及び再生時間をＮＴＰベースのタイムライン（ｔｉｍｅｌｉｎｅ）にマッチングして同期化を行う。

そのためのＲＴＣＰ送信者報告パケット（ＲＴＣＰｓｅｎｄｅｒｒｅｐｏｒｔｐａｃｋｅｔ）は、Ｖ（ｖｅｒｓｉｏｎ）情報、Ｐ（ｐａｄｄｉｎｇ）情報、受信報告カウント（Ｒｅｃｅｐｔｉｏｎｒｅｐｏｒｔｃｏｕｎｔ；ＲＣ）情報、ペイロードタイプ（ＰａｙｌｏａｄＴｙｐｅ）情報、長さ（Ｌｅｎｇｔｈ）情報、同期化ソース識別子（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎｓｏｕｒｃｅｉｄｅｎｔｉｆｉｅｒ）情報、ＮＴＰタイムスタンプ（ＮＴＰｔｉｍｅｓｔａｍｐ）情報、ＲＴＰタイムスタンプ（ＲＴＰＴｉｍｅｓｔａｍｐ）情報、送信者パケットカウント（ｓｅｎｄｅｒ’ｓｐａｃｋｅｔｃｏｕｎｔ）情報、送信者オクテットカウント（ｓｅｎｄｅｒ’ｓｏｃｔｅｔｃｏｕｎｔ）情報、受信報告ブロック（ｒｅｃｅｐｔｉｏｎｒｅｐｏｒｔｂｌｏｃｋ）、及び／又はプロファイル特定拡張（Ｐｒｏｆｉｌｅ−ｓｐｅｃｉｆｉｃｅｘｔｅｎｓｉｏｎ）を含むことができる。

Ｖ（ｖｅｒｓｉｏｎ）情報は、ＲＴＰプロトコルのバージョン情報を示す。

Ｐ（ｐａｄｄｉｎｇ）情報は、ペイロード内にパディングビットが存在するか否かを示す。

受信報告カウント（ＲＣ）情報は、受信報告（ｒｅｃｅｐｔｉｏｎｒｅｐｏｒｔ）の数を示す。

ペイロードタイプ情報は、ＲＴＣＰパケットのペイロードのタイプを示す。ペイロードタイプ情報は、ペイロードに含まれたものが、送信者報告（ｓｅｎｄｅｒｒｅｐｏｒｔ）、受信報告、またはアプリケーション特定パケット（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃｐａｃｋｅｔ）であることを示すことができる。

長さ情報は、ＲＴＣＰパケットの長さを示す。

同期化ソース識別子情報は、ストリームのソースを識別する識別子である。

ＮＴＰタイムスタンプ情報は、ネットワークタイムプロトコル（ｎｅｔｗｏｒｋｔｉｍｅｐｒｏｔｏｃｏｌ）のタイムスタンプを６４ビットで表現する。

ＲＴＰタイムスタンプ情報は、ＮＴＰタイムスタンプフィールドと関連するＲＴＰタイムスタンプの値を示す。

送信者のパケットカウント情報は、送信を開始した後、このＳＲパケットが生成されるまで送信者によって送信されたＲＴＰデータパケットの総数に対応する。カウントは、送信者がＳＳＲＣ識別子を変更するとリセットされる。

送信者のオクテットカウント情報は、送信を開始した後、このＳＲパケットが生成されるまで送信者によってＲＴＰデータパケットで伝送されるペイロードオクテット（即ち、ヘッダー及びパディングを含まないこと）の総数に対応する。カウントは、送信者がＳＳＲＣ識別子を変更するとリセットされる。このフィールドは、平均ペイロードデータレートを推定するのに使用することができる。

プロファイル特定拡張は、伝送プロトコルプロファイルによって拡張して使用できるフィールドを示すことができる。プロファイルなどに特化された情報などを含むことができるフィールドであって、プロファイルなどによって異なる情報が含まれたり、解釈され得る。

図７０は、本発明の一実施例に係る、プロファイル特定拡張を示す図である。

ＲＴＣＰの送信者報告（ｓｅｎｄｅｒｒｅｐｏｒｔ）パケットのプロファイル特定拡張（ｐｒｏｆｉｌｅ−ｓｐｅｃｉｆｉｃｅｘｔｅｎｓｉｏｎ）フィールドに同一の網を介して伝送される異なる伝送プロトコルパケット、または異なる網を介して伝達される異なる伝送プロトコルベースのパケット（例えば、ブロードバンド（ｂｒｏａｄｂａｎｄ）で伝達されるＭＰＥＧＤＡＳＨセグメントなど）とのタイム同期化をサポートするための情報を追加することができる。当該パケットは、異なる形態で構成され得る。例えば、ＮＴＰタイムスタンプをベースとして、ＮＴＰタイムスタンプを、ＲＴＰタイムスタンプ又はＤＡＳＨメディアプレゼンテーションタイム（ＤＡＳＨｍｅｄｉａｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅ）とマッピングすることができる。

前述したＲＴＣＰ送信者報告パケットに含まれるプロファイル特定拡張は、プロファイルバージョン（Ｐｒｏｆｉｌｅｖｅｒｓｉｏｎ）情報、位置フラグ（ＬｏｃａｔｉｏｎＦｌａｇ）情報、タイムスタンプフォーマット（Ｔｉｍｅｓｔａｍｐｆｏｒｍａｔ）情報、タイムスタンプ（Ｔｉｍｅｓｔａｍｐ）情報、及び／又は位置（Ｌｏｃａｔｉｏｎ）情報を含むことができる。

プロファイルバージョン情報は、プロファイルのバージョン情報を示すことができる。

位置フラグ情報は、位置（ｌｏｃａｔｉｏｎ）フィールドが含まれているか否かを示すことができる。

タイムスタンプフォーマット情報は、含まれたタイムスタンプ（ｔｉｍｅｓｔａｍｐ）フィールドのフォーマットを示すことができる。

例えば、タイムスタンプフォーマット情報の値として０ｘ００、０ｘ０７〜０ｘ０Ｆはリザーブド（ｒｅｓｅｒｖｅｄ）された場合である。タイムスタンプフォーマット情報の値が０ｘ０１である場合、メディアタイム（ｍｅｄｉａｔｉｍｅ）であることを示し、０ｘ０２である場合、ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０３である場合、ＮＰＴ（ｎｏｒｍａｌｐｌａｙｉｎｇｔｉｍｅ）であることを示し、０ｘ０４である場合、ＳＭＰＴＥタイムコード（ＳＭＰＴＥｔｉｍｅｃｏｄｅ）であることを示し、０ｘ０５である場合、９０ＫＨｚベースのタイムスタンプ（ｔｉｍｅｓｔａｍｐ）であることを示し、０ｘ０６である場合、ＧＰＳ時間（ＧＰＳｔｉｍｅ）であることを示すことができる。

タイムスタンプフォーマット情報の値が０ｘ０１である場合、タイムスタンプフィールドのフォーマットがメディアタイムであることを示すことができ、メディアタイムは、ＭＰＥＧＤＡＳＨのメディアプレゼンテーションタイムに該当し得る。

タイムスタンプ情報は、関連するタイミング情報を含むことができる。例えば、タイムスタンプ情報は、関連するＭＰＥＧＤＡＳＨのＭＰＤのプレゼンテーション基準クロック（ｐｒｅｓｅｎｔａｔｉｏｎｒｅｆｅｒｅｎｃｅｃｌｏｃｋ）情報を含むことができる。タイムスタンプ情報は、タイムスケール（ｔｉｍｅｓｃａｌｅ）及び／又は当該タイムスケールベースの基準タイムライン（ｒｅｆｅｒｅｎｃｅｔｉｍｅｌｉｎｅ）などのタイミング情報を含むことができる。

位置情報は、タイムスタンプフィールド値と関連するＭＰＥＧＤＡＳＨのＭＰＤ関連情報（例えば、ＭＰＤｉｄあるいはＵＲＬ）を示すことができる。

その他にも、前述したタイムラインコンポーネントアクセスユニット（ｔｉｍｅｌｉｎｅｃｏｍｐｏｎｅｎｔａｃｃｅｓｓｕｎｉｔ）のシンタックスに含まれる情報がプロファイル特定拡張に含まれ得る。

図７１は、本発明の一実施例に係る、アプリケーション定義ＲＴＣＰパケット（Ａｐｐｌｉｃａｔｉｏｎ−ＤｅｆｉｎｅｄＲＴＣＰＰａｃｋｅｔ）であるＲＴＣＰアプリケーションパケットを示す図である。

ＲＴＣＰパケットは、Ｖ（ｖｅｒｓｉｏｎ）情報、Ｐ（ｐａｄｄｉｎｇ）情報、サブタイプ（Ｓｕｂｔｙｐｅ）情報、ペイロードタイプ（ＰａｙｌｏａｄＴｙｐｅ）情報、長さ（Ｌｅｎｇｔｈ）情報、ネーム（Ｎａｍｅ）情報、及び／又はアプリケーション従属データ（Ａｐｐｌｉｃａｔｉｏｎ−ｄｅｐｅｎｄｅｎｔｄａｔａ）を含むことができる。

サブタイプ情報は、ＲＴＣＰパケットペイロードのサブタイプに関する情報を示すことができる。

ペイロードタイプ情報は、ＲＴＣＰパケットのペイロードのタイプを示す。ペイロードタイプ情報は、ペイロードにアプリケーション特定パケット（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃｐａｃｋｅｔ）が含まれていることを示すことができる。

長さ情報は、ＲＴＣＰパケットの長さを示す。

ネーム情報は、アプリケーションのネームなどの情報を含むことができる。

アプリケーション従属データは、アプリケーション制限的な情報を含むことができる。

図７２は、本発明の一実施例に係る、アプリケーション従属データ（ａｐｐｌｉｃａｔｉｏｎ−ｄｅｐｅｎｄｅｎｔｄａｔａ）を示す図である。

本発明の一実施例によれば、アプリケーション従属データフィールドを用いて、タイム同期化のためのタイミング情報を送信／受信することができる。

アプリケーション従属データフィールドは、データタイプ（ｄａｔａｔｙｐｅ）情報、バージョン（ｖｅｒｓｉｏｎ）情報、位置フラグ（ＬｏｃａｔｉｏｎＦｌａｇ）情報、タイムスタンプフォーマット（Ｔｉｍｅｓｔａｍｐｆｏｒｍａｔ）情報、ＮＴＰタイムスタンプ（ＮＴＰｔｉｍｅｓｔａｍｐ）情報、タイムスタンプ（Ｔｉｍｅｓｔａｍｐ）情報、及び／又は位置（Ｌｏｃａｔｉｏｎ）情報を含むことができる。

データタイプ情報は、当該フィールドに含まれたデータのタイプを示すことができる。

バージョン情報は、当該パケットのプロファイルのバージョン情報を示すことができる。

位置フラグ情報は、当該パケットが位置フィールドを含んでいるか否かを示すことができる。

タイムスタンプフォーマット情報は、含まれたタイムスタンプフィールドのフォーマットを示すことができる。例えば、タイムスタンプフォーマット情報の値のうち、０ｘ００、０ｘ０７〜０ｘ０Ｆは、将来の使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）されたものであってもよい。タイムスタンプフォーマット情報の値が０ｘ０１である場合、メディアタイムであることを示し、０ｘ０２である場合、ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０３である場合、ＮＰＴ（ｎｏｒｍａｌｐｌａｙｉｎｇｔｉｍｅ）であることを示し、０ｘ０４である場合、ＳＭＰＴＥタイムコード（ＳＭＰＴＥｔｉｍｅｃｏｄｅ）であることを示し、０ｘ０５である場合、９０ＫＨｚベースのタイムスタンプであることを示し、０ｘ０６である場合、ＧＰＳ時間であることを示すことができる。

例えば、ＭＰＥＧＤＡＳＨのメディアプレゼンテーションタイム（ｍｅｄｉａｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅ）の場合、タイムスタンプフォーマット情報の値が０ｘ０１であるメディアタイムとして表すことができ、または、他の値をさらに割り当てることで、ＭＰＥＧＤＡＳＨのメディアプレゼンテーションタイムであることを示すこともできる。

ＮＴＰタイムスタンプ情報は、ネットワークタイムプロトコルのタイムスタンプを示す。

タイムスタンプ情報は、関連するタイミング情報を含むことができる。例えば、タイムスタンプ情報は、関連するＭＰＥＧＤＡＳＨのＭＰＤのプレゼンテーション基準クロック（ｐｒｅｓｅｎｔａｔｉｏｎｒｅｆｅｒｅｎｃｅｃｌｏｃｋ）情報を含むことができる。タイムスタンプ情報は、タイムスケール及び／又は当該タイムスケールベースの基準タイムライン（ｒｅｆｅｒｅｎｃｅｔｉｍｅｌｉｎｅ）などのタイミング情報を含むことができる。

前述したアプリケーション従属データ（ａｐｐｌｉｃａｔｉｏｎ−ｄｅｐｅｎｄｅｎｔｄａｔａ）フィールドを用いる場合、放送網としてＲＴＰ送信／受信プロトコルを使用し、インターネット網を介してＭＰＥＧＤＡＳＨベースのメディアデータを送信／受信する場合、ＭＰＥＧＤＡＳＨメディアプレゼンテーションタイムをネットワーク伝送プロトコル（Ｎｅｔｗｏｒｋｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ）のタイムスタンプにマッピングすることができる。オーディオ／ビデオデータのＲＴＰタイムスタンプもまた、ＮＴＰタイムスタンプとマッピングすることができるので、ＲＴＰパケットとＭＰＥＧＤＡＳＨデータとの間の同期化をなし、放送コンテンツの復号及び／又は再生を行うことができる。

図７３は、本発明の実施例として、放送システムに適用できるプロトコルスタックを示す。

地上波放送チャネルにおいて、ストリーミングデータ（例えば、ビデオ、オーディオ、クローズドキャプション）は、ＩＰ／ＵＤＰを介してＲＴＰ又はＡＬＣ／ＬＣＴエクステンションを介して伝達されてもよい。特に、ストリーミングデータのアクセスユニットはＲＴＰを介して伝達されるか、またはストリーミングデータのアクセスユニットのセットを含むＩＳＯＢＭＦＦオブジェクトがＡＬＣ／ＬＣＴエクステンションを介して伝達されてもよい。また、非リアルタイムファイルは、ＡＣＬ／ＬＣＴを介してＦＬＵＴＥを介して伝達されてもよい。また、ＩＰ／ＵＤＰデータグラム又はリンク層シグナリングは、リンク層で暗号化（ｅｎｃａｐｓｕｌａｔｅ）され、暗号化された形態で伝達されてもよい。

ブロードバンドネットワークにおいて、ＭＰＥＧＤＡＳＨはストリーミングデータの伝達をサポートし、ＨＴＴＰはユニキャストチャネルを介したファイル伝達をサポートすることができる。マルチキャストチャネルを介して、ストリーミングデータはＭＰＥＧＤＡＳＨ又はＲＴＰを介して伝達され、ファイルはＦＬＵＴＥを介して伝達され得る。

同図は、クロック基準ストリームを含んで未来の放送システムでのコンテンツ伝達のためのこれらのプロトコルスタックの例を示す。クロック基準ストリームは、様々なソースから提供され得る様々なストリーム（例えば、ビデオ、オーディオまたはデータストリーム）間の基準タイミングを提供するデータまたは情報を含むことができる。

リンク層内の暗号化について、以下でさらに説明する。任意のリンク層暗号化なしに、関連パケットを直接送信できる異なる方法が存在し得る。

リンク層は、ＩＰパケット、ＭＰＥＧ−２ＴＳ及び／又は他のプロトコルパケットの暗号化を提供する。リンク層暗号化を用いて、物理層は、ネットワーク層プロトコルタイプと独立して一つの暗号化パケットフォーマットを処理することができる。基本的に、ネットワーク層パケットは、リンク層パケットのペイロードに変換される。物理層リソースを効率的に使用するために、リンク層パケットへのネットワーク層パケットの連接（ｃｏｎｃａｔｅｎａｔｉｏｎ）及びセグメンテーション（ｓｅｇｍｅｎｔａｔｉｏｎ）が行われてもよい。

連接について、ネットワーク層パケットが小さい場合、リンク層パケットのペイロードはいくつかのネットワーク層パケットを含む。リンク層パケットヘッダーは、連接を行うフィールドを含む。リンク層パケットヘッダーは、ネットワーク層パケットに対する連接が存在するか否かを特定する情報、ネットワーク層パケット間の連接順序を特定する情報及び／又はリンク層パケットで連接されるネットワーク層パケットの数を特定する情報を含むことができる。

セグメンテーション及びリアセンブリ（ｒｅａｓｓｅｍｂｌｙ）について、ネットワーク層パケットが過度に大きいため物理層で処理できない場合、ネットワーク層パケットは２つのセグメントに分割される。リンク層パケットヘッダーは、送信側でのセグメンテーション及び受信側でのリアセンブリを行うフィールドを含む。リンク層パケットヘッダーは、このリンク層パケットのペイロードが含まれ得るネットワーク層パケットを特定する情報、ネットワーク層パケットのセグメンテーションの数を特定する情報、ネットワーク層パケット内のセグメンテーションのそれぞれの順序を特定する情報、及び／又はネットワーク層パケットの最初のセグメンテーション及び／又は最後のセグメンテーションを特定する情報を含むことができる。

オーバーヘッドの減少のために、リンク層は、ＩＰフロー内のオーバーヘッドの減少のための選択的ヘッダー圧縮を提供する。ヘッダー圧縮はＲｏＨＣ（ＲｏｂｕｓｔＨｅａｄｅｒｃｏｍｐｒｅｓｓｉｏｎ）フレームワークに基づくことができる。ＲｏＨＣフレームワークは単方向モードで動作することができる。

リンク層シグナリング伝送について、リンク層は、高速情報チャネル、ＥＡＳ（ＥｍｅｒｇｅｎｃｙＡｌｅｒｔＳｙｓｔｅｍ）メッセージ及び／又はオーバーヘッドの減少のための情報などのリンク層で生成されたシグナリングなどのシグナリング情報の伝送を提供する。

高速情報チャネルを介したシグナリングについて、高速情報チャネルの主な目的は、迅速なチャネルスキャン及びサービス獲得のための必須情報を効果的に伝達することである。この情報は、主に放送サービスと物理データパイプとの間の結合（ｂｉｎｄｉｎｇ）情報を含む。

ＥＡＳシグナリングの伝送について、物理層が、適切な帯域幅を有する特殊緊急警報チャネルをサポートして基本緊急警報メッセージ（例えば、共通警報プロトコルメッセージ）を伝達すると、このチャネルは、緊急警報関連シグナリング及び基本緊急警報メッセージを伝達することができる。追加のメディアファイルは個別データパイプを介して伝達されてもよい。物理層のみが、緊急警報メッセージが利用可能な低帯域幅通知（ｌｏｗｂａｎｄｗｉｄｔｈｎｏｔｉｆｉｃａｔｉｏｎ）をサポートする場合、基本警報メッセージ及び追加のメディアファイルは個別データパイプを介して伝達され得る。これらの場合、個別データパイプが高いロバスト性（ｒｏｂｕｓｔｎｅｓｓ）を有するように構成され得る。

シグナリングの概要、及び未来の放送システムにおいてシグナリング情報を得るために装置が経る「ブートストラップ」プロセスの説明は、以下に記載される。それぞれの放送システムで３つのシグナリングレベルが存在し得る。

（ａ）各サービス（例えば、ネーム、チャネル番号、サービスタイプ）に関する核心情報（ｓｋｅｌｅｔａｌｉｎｆｏｒｍａｔｉｏｎ）を有する放送ストリーム内の少なくとも１つのコンポーネント、及び（ＰＨＹ層が専用物理層パイプを提供せず、このような細部情報に対する専用ＩＰマルチキャストアドレス／ポートが存在しない場合）各サービスに関する細部情報の位置に対するポインタを有する全てのサービスのリスト。このリストは、高速サービススキャンの間、サービステーブルを形成するのに使用することができる。

（ｂ）（サービス位置記述語（ＳｅｒｖｉｃｅＬｏｃａｔｉｏｎＤｅｓｃｒｉｐｔｏｒ）を除いた）Ａ／６５ＶＣＴと類似の放送ストリーム内の少なくとも１つのコンポーネント、又は１つ以上のコンポーネントを含む各サービスに対するＤＡＳＨＭＰＤのＵＲＬ又はＡ／１５３ＳＭＴ内のサービスレベル情報、及び（この情報がサービスレベル情報と同一の位置にない場合）サービスのコンポーネントに関する細部情報の位置に対するポインタを有するそれぞれの属性。

（ｃ）Ａ／１５３ＳＭＴ内のＭＰＥＧ−２ＰＭＴ又はコンポーネントレベル情報と類似の各サービスの各コンポーネントまたはＤＡＳＨＭＰＤの位置及び特性。コンポーネントの位置は、物理チャネル、物理層パイプ、ＩＰマルチキャストアドレス及びポート、及び放送によって伝達されたコンポーネントに対する（適用可能な）ＡＬＣ／ＬＣＴ＋セッションのＴＳＩ、または（ブロードバンドを介して伝達されたコンポーネントと関連するＤＡＳＨＭＰＤ内のＤＡＳＨ表示又はＤＡＳＨ適応セットを示す情報を有する）ブロードバンドを介して伝達されたコンポーネントに対するＤＡＳＨＭＰＤのＵＲＬを含む。このシグナリングの目的で、クロック基準ストリームはサービスのコンポーネントとして見なされる。

視聴者がサービスを選択すると、装置は、サービススキャンの間、レベル（ａ）シグナリングから形成されたサービステーブルで探し、サービスのコンポーネントを見つけることができる物理チャネルを決定する。

その後、装置は、適切な物理チャネルに同調し、レベル（ｂ）及びレベル（ｃ）シグナリングをアクセスして必要な追加の情報を得る。

図７４は、本発明の実施例として、ＲＴＰプレゼンテーション時間から受信機壁時計時間への変換を示す図である。

放送システムは、放送ストリームのリアルタイム連続コンテンツ伝達をサポートすることができる。

放送及びマルチキャスト伝達について、放送及びマルチキャスト−ＲＴＰ及び／又はＡＬＣ／ＬＣＴ＋を通じてＩＳＯＢＭＦＦ−を介した連続コンテンツのリアルタイム伝達に対して２つの異なる方法が記述される。これら２つの方法がサポートされる場合、同一のサービス内で使用することができない。

ＲＴＰ伝達について、ＲＴＰを介した連続コンテンツコンポーネントの伝達が、コンテンツのリアルタイム放送又はマルチキャスト伝達のためにサポートされ得る。このような伝達は、ｔｉｍｅｄ−ｔｅｘｔクローズドキャプション、Ｈ．２６４ビデオ、ＨＥＶＣビデオ、ＨＥＡＡＣオーディオなどの伝達されるメディアのタイプに対する適切な追加ペイロード仕様及びリアルタイムアプリケーション（ＲＴＰ）のための伝送プロトコルに従うことができる。特に、ＲＴＣＰＳＲ（ＲＴＰｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌｓｅｎｄｅｒｒｅｐｏｒｔ）パケットは、放送又はマルチキャストを介して伝達される異なる連続コンテンツコンポーネント間の同期化に使用することができる。

放送を介して受信機に伝達されることは、（プロトコル経路ＲＴＰ／ＩＰ−マルチキャスト／ＵＤＰ／ＩＰを用いる）連続コンポーネントトラックのそれぞれに対する１つの放送ＩＰマルチキャストＲＴＰストリーム、例えば、ビデオ、オーディオ及びクローズドキャプション、及び／又は（プロトコル経路ＲＴＰ／ＩＰ−マルチキャスト／ＵＤＰ／ＩＰを用いる）連続コンポーネントトラックのそれぞれに対する１つの放送ＩＰマルチキャストＲＴＣＰＳＲストリームで構成されてもよい。

放送を介して伝達される１つ以上の連続コンポーネントを同期化するために、次のアプローチを開発することができる。

連続コンポーネントトラックのそれぞれに対して、トラックのためのＲＴＣＰストリーム内のＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）タイムスタンプ（Ｎ（ｉ））及び／又は当該ＲＴＰ（リアルタイム伝送プロトコル）タイムスタンプ（Ｒ（ｉ））を用いて、（ＲＴＰタイムラインに関する）ＲＴＰパケットヘッダー内のプレゼンテーション時間をＮＴＰタイムラインに関するプレゼンテーション時間に変換する。この明細書において、ＮＴＰタイムラインは、タイミングがマッピングされ得る基準タイムラインの例である。ＮＴＰタイムラインは、基準タイムラインで代替されたり、基準タイムラインと結合され得る。基準タイムラインは、ＮＴＰタイムライン、ＧＰＳタイムライン、ＰＴＰ（ＰｒｅｃｉｓｉｏｎＴｉｍｅＰｒｏｔｏｃｏｌ）タイムライン、ＮＰＴ（ＮｏｗＰｌａｙｉｎｇＴｉｍｅ）及び／又はＵＴＣ（ＣｏｏｒｄｉｎａｔｅｄＵｎｉｖｅｒｓａｌＴｉｍｅ）を含む。

ＰＴＲが特定のＲＴＰパケットヘッダー内のプレゼンテーション時間であり、Ｎ（ｉ）及びＲ（ｉ）が最近のＲＴＣＰパケットからの値であれば、変換式は、
ＰＴＮ＝Ｎ（ｉ）＋（ＰＴＲ−Ｒ（ｉ））／（ＲＴＰクロックレート）
である。ここで、ＰＴＮは、ＮＴＰタイムラインに関するプレゼンテーション時間である。

サービスが先に選択され、一つのＲＴＣＰパケットが受信されると、シグナリングされた公称（ｎｏｍｉｎａｌ）ＲＴＰクロックレートがこの計算に使用され得る。より多くのＲＴＣＰパケットが受信されることによって、実際のＲＴＰクロックレートに対するより正確な値が、値
（Ｒ（ｉ＋１）−Ｒ（ｉ））／（Ｎ（ｉ＋１）−Ｎ（ｉ））
から得られる。ここで、Ｒ（ｉ）及びＮ（ｉ）は、ＲＴＣＰパケットからの値であり、Ｒ（ｉ＋１）及びＮ（ｉ＋１）は、次のＲＴＣＰパケットからの値である。図面は、この状況の例を示す。

パケットが受信される時点でＲＴＣＰパケット内のＮＴＰタイムスタンプ（Ｎ（ｉ））を受信機壁時計時間（Ｗ（ｉ））と比較し、それら２つの間の任意のオフセットを決定する。（伝達遅延及び受信機壁時計とサーバーＮＴＰクロックとの間の可能な不一致の組み合わせが、ゼロではないオフセットを誘発し得る。）このオフセットを用いてＲＴＰパケットヘッダー内のプレゼンテーション時間をサーバーＮＴＰタイムラインに関する値（ＰＴＮ）から受信機壁時計クロックタイムラインに関する値（ＰＴＷ）に調節する。

同図は、ＲＴＰパケット内のアクセスユニットのプレゼンテーションタイムスタンプ（ＰＴＲ）からのＮＴＰタイムラインに関するプレゼンテーション時間（ＰＴＮ）へ及び壁時計クロックタイムラインに関するプレゼンテーション時間（ＰＴＷ）への変換を示す。

図７５は、一つのビデオトラック、一つのオーディオトラック及び一つのクローズドキャプショントラックがＲＴＰで放送を介して伝達される場合のプロトコルスタックを示す図である。

一つのビデオトラック、一つのオーディオトラック及び一つのクローズドキャプショントラックがいずれも放送を介して伝達されるとき、放送を介して受信機に伝達されるものが、（プロトコル経路ＲＴＣＰ／ＩＰ−マルチキャスト／ＵＤＰ／ＩＰを用いる）３つのトラック、すなわち、一つのビデオ、一つのオーディオ及び一つのクローズドキャプションのそれぞれに対する一つの放送ＩＰマルチキャストＲＴＰストリーム及び／又は（プロトコル経路ＲＴＣＰ／ＩＰ−マルチキャスト／ＵＤＰ／ＩＰを用いる）３つのトラックのそれぞれに対する一つの放送ＩＰマルチキャストＲＴＣＰＳＲストリームで構成され得る、次の使用ケースを考慮する。

受信機は、シグナリングを用いて３つのＲＴＰストリーム（オーディオ、ビデオ、ＣＣトラック）、及び／又は３つのＲＴＣＰストリーム（オーディオ、ビデオ、ＣＣトラック）のＩＰマルチキャストアドレス及びポートを得ることができる。

受信機は、ビデオ、オーディオ及び／又はクローズドキャプショントラックに対するＲＴＰパケットが到達したとき、放送からそれらを抽出することができる。

受信機は、ビデオ、オーディオ及び／又はクローズドキャプショントラックに対するＲＴＣＰパケットが到達したとき、放送からそれらを抽出することができる。

３つのトラックのそれぞれに対して、受信機は、トラックに対するＲＴＣＰストリーム内のＮＴＰタイムスタンプ（Ｎ（ｉ））及び当該ＲＴＰタイムスタンプ（Ｒ（ｉ））を用いて、（ＲＴＰタイムラインに関する）ＲＴＰパケットヘッダー内のプレゼンテーション時間をＮＴＰタイムラインに関するプレゼンテーション時間に変換することができる。ＰＴＲが特定のＲＴＰパケットヘッダー内のプレゼンテーションであり、Ｎ（ｉ）及びＲ（ｉ）が最近のＲＴＣＰパケットからの値であれば、変換式は、ＰＴＮ＝（Ｎ（ｉ）＋（ＰＴＲ−Ｒ（ｉ））／（ＲＴＰクロックレート）であり、ここで、ＰＴＮは、ＮＴＰタイムラインに関するプレゼンテーション時間である。サービスが先に選択され、一つのＲＴＣＰパケットのみが受信される場合、シグナリングされた公称ＲＴＰクロックレートがこの計算に使用され得る。より多くのＲＴＣＰパケットが受信されることによって、実際のＲＴＰクロックレートに対するより正確な値が、値
（Ｒ（ｉ＋１）−Ｒ（ｉ））／（Ｎ（ｉ＋１）−Ｎ（ｉ））
から得られ、Ｒ（ｉ）及びＮ（ｉ）は、一つのＲＴＣＰパケットからの値であり、Ｒ（ｉ＋１）及びＮ（ｉ＋１）は、次のＲＴＣＰパケットからの値である。図２は、この状況の例を示す。

受信機は、パケットが受信される時点でＲＴＣＰパケット内のＮＴＰタイムスタンプ（Ｎ（ｉ））を受信機壁時計時間（Ｗ（ｉ））と比較し、それらの２つの間の任意のオフセットを決定することができる。（伝達遅延及び受信機壁時計とサーバーＮＴＰクロックとの間の可能な不一致（ｄｉｓｃｒｅｐａｎｃｙ）の組み合わせが、ゼロではないオフセットを誘発し得る。）このオフセットを用いて、ＲＴＰパケットヘッダー内のプレゼンテーション時間をサーバーＮＴＰタイムラインに関する値（ＰＴＮ）から受信機壁時計クロックタイムラインに関する値（ＰＴＷ）に調節する。上述した図面はこの計算の例を提供する。

受信機は、適切な壁時計時間でＲＴＰストリーム内のアクセスユニットを提示することができる。

図７６は、一つのビデオトラック、一つのオーディオトラック及び一つのクローズドキャプショントラックが、ＡＬＣ／ＬＣＴ＋を通じてＩＳＯＢＭＦＦで放送を介して伝達される場合のプロトコルスタックを示す図である。

ＡＬＣ／ＬＣＴ＋（ＡｓｙｎｃｈｒｏｎｏｕｓＬａｙｅｒｅｄＣｏｄｉｎｇ／ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ＋）パケットに含まれるＩＳＯＢＭＦＦ（ＩＳＯｂａｓｅｍｅｄｉａｆｉｌｅｆｏｒｍａｔ）オブジェクトを介した連続コンテンツコンポーネントの伝達が、コンテンツのリアルタイム放送又はマルチキャスト伝達のためにサポートされ得る。ＩＳＯＢＭＦＦオブジェクトは、アプリケーションに応じて特定されるプロファイルによるＭＰＥＧＩＳＯＢＭＦＦによってフォーマットされ得る。ＡＬＣ／ＬＣＴ＋パケットは、追加のＬＣＴヘッダーエクステンションでフォーマットされてプレゼンテーションタイミング情報を伝達することができる。プレゼンテーションタイミング情報は、ＩＳＯＢＭＦＦオブジェクトの開始を含むパケットに対するプレゼンテーションタイムスタンプを含むことができる。このようなプレゼンテーションタイムスタンプは、ＩＳＯＢＭＦＦオブジェクトタイムラインの開始を、次の段落に記載されたタイムベース内の適切なポイントにマップすることができる。ＵＲＬをそれぞれのＩＳＯＢＭＦＦオブジェクトと関連付ける必要がある場合（例えば、ＭＰＤがシグナリングに使用される場合）、それぞれのＩＳＯＢＭＦＦオブジェクトは、コンテンツ−位置フィールドを含むＨＴＴＰ−スタイルヘッダーを有することができる。または、ＩＳＯＢＭＦＦオブジェクトの開始を含むＡＬＣ／ＬＣＴ＋パケットは、関連付けられたＵＲＬを含むＬＣＴエクステンションヘッダーを有することができる。

「放送タイムライン」は、放送又はマルチキャストを介して放送タイムラインクロック基準値を伝送することによって確立され得る。この放送タイムラインは、ＬＣＴヘッダーエクステンション内のプレゼンテーションタイミング情報に対する基準時間ベースとして機能することができる。

ＡＬＣ／ＬＣＴ＋を通じてＩＳＯＢＭＦＦオブジェクトを介してリアルタイム放送又はマルチキャストモードで伝達される１つ以上の連続コンテンツコンポーネントを含む任意のサービスは、個別「タイムベース」コンポーネントを含んでタイムベースを定義して、プレゼンテーションのための基準タイムベースとして機能することができる。このタイムベースコンポーネントは、適切な間隔で送信されるタイムスタンプパケットで構成されてもよい。タイムスタンプは、ＰＣＲ値がＭＰＥＧ−２環境でシステムクロックを確立するのに使用されることと同じ方式でデコーダによって使用され、デコーダ側のシステムクロックを確立できるエンコーダ側のシステムクロックのサンプルを示すことができる。

放送を介して受信機に伝達されることは、（プロトコル経路Ｒｅｆ−Ｃｌｏｃｋ／ＩＰ−マルチキャスト／ＵＤＰ／ＩＰを用いる）放送タイムラインに対するクロック基準タイムスタンプを含む一つの放送ＩＰマルチキャストストリーム及び／又は連続コンポーネントトラック（例えば、ビデオ、オーディオ及びクローズドキャプション）のそれぞれに対する一つの放送ＩＳＯＢＭＦＦストリームで構成されてもよい。

一つの放送ＩＰマルチキャストストリームが（プロトコル経路Ｒｅｆ−Ｃｌｏｃｋ／ＩＰ−マルチキャスト／ＵＤＰ／ＩＰを用いる）放送タイムラインのためのクロック基準時間を含む場合、タイムラインのタイムスケールは通常のクロック時間であってもよい（例えば、クロックは、任意の適切なフォーマットで表現されるサーバーでのＵＴＣ時間であってもよい）。

連続コンポーネントトラックのそれぞれに対する一つの放送ＩＳＯＢＭＦＦストリームが使用される場合、それぞれのＩＳＯＢＭＦＦファイルはＡＬＣ／ＬＣＴ＋オブジェクトとして伝達され得る。

連続コンポーネントトラックのそれぞれに対する一つの放送ＩＳＯＢＭＦＦストリームが使用される場合、ＩＳＯＢＭＦＦファイルの開始を含むＡＬＣ／ＬＣＴ＋パケットは、放送タイムラインに対してＩＳＯＢＭＦＦファイルのタイムラインに対する開始時間を提供するＬＣＴエクステンションヘッダーを有する。

連続コンポーネントトラックのそれぞれに対する一つの放送ＩＳＯＢＭＦＦストリームが使用されるとき、ＵＲＬをそれぞれのＩＳＯＢＭＦＦファイルと関連付ける必要がある場合（例えば、ＭＰＤがシグナリングに使用される場合）、それぞれのＩＳＯＢＭＦＦファイルは、コンテンツ−位置フィールドを含むＨＴＴＰ−スタイルヘッダーを有することができる。または、ＩＳＯＢＭＦＦファイルの開始を含むＡＬＣ／ＬＣＴ＋パケットは、関連付けられたＵＲＬを含むＬＣＴエクステンションヘッダーを有することができる。

一つのビデオトラック、一つのオーディオトラック及び一つのクローズドキャプションがいずれも放送を介して伝達される使用ケースを考慮する。

受信機は、シグナリングを用いてクロック基準ストリームのＩＰマルチキャストアドレス及びポート、及び／又はビデオ、オーディオ及びクローズドキャプショントラックに対するＩＳＯＢＭＦＦストリームを伝達するＡＬＣ／ＬＣＴ＋セッションのためのＴＳＩ（ＴｒａｎｓｐｏｒｔＳｔｒｅａｍＩｄｅｎｔｉｆｉｅｒ）値及びＩＰマルチキャストアドレス及びポートを得ることができる。

受信機は、タイムスタンプが現れたとき、クロック基準ストリームからそれを抽出し、それを用いて放送タイムラインと受信機「壁時計」時間との間のオフセットを決定することができる。

受信機は、ビデオ、オーディオ及びクローズドキャプショントラックのためのＩＳＯＢＭＦＦファイルが現れたとき、それを放送から抽出することができる。

受信機は、前記ステップで決定されたオフセットによって調節されたそれぞれのＢＭＦＦファイルのＡＬＣ／ＬＣＴ＋エクステンションヘッド内のプレゼンテーションタイムスタンプを用いて、それぞれのＩＳＯＢＭＦＦファイルのタイムラインに対する壁時計開始時間を設定することができる。

受信機は、各ＩＳＯＢＭＦＦファイルに対する壁時計開始時間及びファイル内の内部関連タイミング情報に基づいて、適切な壁時計時間にＢＭＦＦファイル内のアクセスユニットを提示することができる。

放送システムは、放送ストリームのユニキャスト伝達をサポートすることができる。

ＭＰＥＧＤＡＳＨ（ＤｙｎａｍｉｃａｄａｐｔｉｖｅｓｔｒｅａｍｉｎｇｏｖｅｒＨＴＴＰ）がＩＳＯＢＭＦＦの仕様によるセグメントと共に、ユニキャストチャネルを介した連続コンポーネントのリアルタイム伝達のためにサポートされ得る。「ライブ」ＤＡＳＨプロファイル及び「事前記録（ｐｒｅ−ｒｅｃｏｒｄｅｄ）」ＤＡＳＨプロファイルは、（線形サービスの一部として又はオンデマンド（ｏｎ−ｄｅｍａｎｄ）サービスの一部として）ライブコンテンツの伝達のために意図されたライブプロファイル及び事前記録されたコンテンツの伝達のために意図された事前記録されたプロファイルと共にこの目的で特定され得る。

固定及びモバイル受信機へのリアルタイム連続コンテンツ伝達のための誤り訂正は物理層でサポートされてもよい。

本発明の実施例としての放送システムは、非リアルタイム（ＮＲＴ）ファイル（又はデータ）伝達をサポートすることができる。

放送又はマルチキャストを介したファイルの非リアルタイム伝達がサポートされてもよい。

ファイルの非リアルタイム伝達のための誤り訂正は、ＦＥＣ（ＦｏｒｗａｒｄＥｒｒｏｒＣｏｒｒｅｃｔｉｏｎ）及び伝達後のリペアーを用いてサポートされてもよい。

ユニキャストを介したファイルの非リアルタイム伝達は、ＨＴＴＰ１．１及びＴＬＳ１．２を介したＨＴＴＰ１．１を介してサポートされてもよい。

コンテンツファイルの非リアルタイム伝達をサポートするために、サポートされるファイルフォーマットを特定する必要がある。特に、他のコンテンツとの同期化が可能なように、連続メディアを含むファイルのファイルフォーマットを特定する必要がある。

図７７は、本発明の実施例として、放送チャネルでＲＴＰを介して伝達される連続メディアコンポーネントと、ブロードバンドを介してＤＡＳＨを介して伝達される連続メディアコンポーネントとの間の同期化の動作例を示す図である。

放送ストリームが、互いに異なる伝送経路を介して、互いに異なるタイプで伝達されてもよい。放送又はマルチキャストを介してリアルタイムで伝達される多数のメディアコンポーネントストリームと、ユニキャストブロードバンドチャネルを介して伝達された映画フラグメントを伝達するＤＡＳＨセグメントとの間の同期化のためのモデルが具現される必要がある。

ＲＴＰ（放送又はマルチキャスト）及びＤＡＳＨ（ユニキャスト）の組み合わせのために、前記説明で記載されたように、ＲＴＰを介して伝達されたそれぞれの連続メディアコンポーネントは、関連するＲＴＣＰＳＲストリームを有することができる。それぞれのＲＴＣＰＳＲパケットは、ＮＴＰクロック基準タイムスタンプ及び当該ＲＴＰクロック基準タイムスタンプを伝達することができ、これは、ＲＴＰタイムラインをＮＴＰタイムラインにマップするのに使用することができる。したがって、（ＲＴＰパケットヘッダー内のＲＴＰプレゼンテーションタイムスタンプによって指示され得る）ＲＴＰストリーム内のアクセスユニットのプレゼンテーション時間は、ＮＴＰタイムラインへのＲＴＰタイムラインのマッピングによって決定され得る。

ＤＡＳＨ（ユニキャスト）を介して伝達されたコンテンツをＲＴＰ（放送又はマルチキャスト）を介して伝達されたコンテンツと同期化するために、ＤＡＳＨメディアプレゼンテーションタイムラインからＮＴＰタイムラインへのマッピングを確立する必要がある。ＤＡＳＨメディアプレゼンテーションタイムラインからＮＴＰタイムラインへのマッピングを確立するのに必要な情報は、放送又はマルチキャストで伝達されてもよい。

同図は、放送チャネルでＲＴＰを介して伝達される連続メディアコンポーネントと、ブロードバンドを介してＤＡＳＨを介して伝達される連続メディアコンポーネントとの間の同期化の動作例を示す。ＮＴＰタイムラインへのＤＡＳＨメディアプレゼンテーションタイムラインと関連する情報のマッピングは、放送又はマルチキャストを介して（例えば、以下の図面で緑色のパケット）伝達されてもよい。

図７８は、本発明の実施例として、放送チャネルでＲＴＰを介して伝達される連続メディアコンポーネントと、ブロードバンドを介してＤＡＳＨを介して伝達される連続メディアコンポーネントとの間の同期化方法を示す図である。

同期化を達成する一つの方法は、ＲＴＣＰフォーマットカスタマイゼーションメカニズムを用いてＲＴＣＰパケットにＤＡＳＨメディアプレゼンテーションクロック基準タイムスタンプを含ませることである。これを、アプリケーション定義ＲＴＣＰパケットと呼ぶことができる。また、ＤＡＳＨメディアプレゼンテーションクロック基準タイムスタンプがＲＴＰクロック基準タイムスタンプ及びＮＴＰクロック基準タイムスタンプと共にＲＴＣＰパケット（特に、送信者報告パケット）に含まれてもよい。

図７９は、本発明の実施例として、アプリケーション定義ＲＴＣＰパケットの例を示す図である。

アプリケーション定義ＲＴＣＰパケットは、Ｖ（バージョン）、Ｐ（パディング）、サブタイプ、ペイロードタイプ、長さ、ネーム及び／又はアプリケーション従属データを含むことができる。アプリケーション従属データは、データタイプ、バージョン、位置フラグ、タイムスタンプフォーマット、ＮＴＰタイムスタンプ、タイムスタンプ及び／又は位置を含むことができる。

Ｖ（バージョン）は、ＲＴＰプロトコルのバージョンを示す。

Ｐ（パディング）は、ペイロード内のパディングビットの存在を示す。

サブタイプは、ＲＴＣＰパケットペイロードのサブタイプ情報を記述する。

ペイロードタイプは、ＲＴＣＰパケットペイロードのタイプを示す。

長さは、ＲＴＣＰパケットの長さを示す。

ネームは、アプリケーション名を含む。

アプリケーション従属データは、アプリケーション従属データを含む。

データタイプは、アプリケーション従属データのタイプ情報を示す。

バージョンは、このアプリケーション従属データのバージョンを示す。

位置フラグは、アプリケーション従属データ内の位置フィールドの存在を示す。

タイムスタンプフォーマットはタイムスタンプフィールドのフォーマットを示す。例えば、次のように互いに異なるフォーマットを示すことができる。例えば、０ｘ００：リザーブド、０ｘ０１：メディアタイム、０ｘ０２：ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）、０ｘ０３：正常再生時間、０ｘ０４：ＳＭＰＴＥタイムコード、０ｘ０５：９０ＫＨｚベースのタイムスタンプ、０ｘ０６：ＧＰＳ時間、０ｘ０７〜０ｘ０Ｆ：リザーブド、ＭＰＥＧＤＡＳＨの場合、このフィールドは、「メディアタイム」を示す０ｘ０１を含むことができる。

ＮＴＰタイムスタンプは、ネットワークタイムプロトコルのタイムスタンプ値を含む。

タイムスタンプは、時間基準クロック情報（例えば、タイムスケール、タイムスケールベースのプレゼンテーションタイムスタンプなど）を含む。例えば、ＭＰＥＧＤＡＳＨの場合、ＤＡＳＨメディアプレゼンテーションクロック基準タイムスタンプを含むことができる。

位置は、関連する位置値、例えば、ＤＡＳＨＭＰＤｉｄ又はＵＲＬを含む。

図８０は、本発明の実施例として、ＲＴＣＰ送信者報告パケットヘッダーの例を示す図である。

ＤＡＳＨメディアプレゼンテーションクロック基準タイムスタンプは、ＲＴＰクロック基準タイムスタンプ及びＮＴＰクロック基準タイムスタンプと共に、ＲＴＣＰパケット（特に、送信者報告パケット）に含まれてもよい。

ＲＴＣＰ送信者報告パケット内に含まれる情報についての説明は、前述の説明を参照することができる。

ＲＴＣＰ送信者報告パケットは、バージョン、位置フラグ、タイムスタンプフォーマット、タイムスタンプ及び／又は位置を含むことができる。

バージョンはプロファイルバージョンを示す。

位置フラグは、プロファイル特定データ内の位置フィールドの存在を示す。

タイムスタンプフォーマットはタイムスタンプフィールドのフォーマットを示す。例えば、次のように互いに異なるフォーマットを示すことができる。例えば、０ｘ００：リザーブド、０ｘ０１：メディアタイム、０ｘ０２：ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）、０ｘ０３：正常再生時間、０ｘ０４：ＳＭＰＴＥタイムコード、０ｘ０５：９０ＫＨｚベースのタイムスタンプ、０ｘ０６：ＧＰＳ時間、０ｘ０７〜０ｘ０Ｆ：リザーブド。

図８１は、本発明の実施例として、ＲＴＰのハイブリッド伝達のためのプロトコルスタックを示す図である。

同期化を達成する他の方法は、放送又はマルチキャストを介して伝達されたサービス内の個別「ＤＡＳＨ−ＮＴＰタイムベースマッピング」コンポーネントを含んでＤＡＳＨメディアプレゼンテーションタイムラインをＮＴＰタイムラインにマップすることである。

放送又はブロードバンドを介して受信機に伝達されることは、（プロトコル経路ＲＴＰ／ＩＰ−マルチキャスト／ＵＤＰ／ＩＰを用いる）放送連続コンポーネントトラック、例えば、ビデオ、オーディオ及びクローズドキャプションのそれぞれに対する一つの放送ＩＰマルチキャストＲＴＰストリーム、（プロトコル経路ＲＴＰ／ＩＰ−マルチキャスト／ＵＤＰ／ＩＰを用いる）放送連続コンポーネントトラックのそれぞれに対する一つの放送ＩＰマルチキャストＲＴＣＰＳＲストリーム、（プロトコル経路ＩＳＯＢＭＦＦ／ＤＡＳＨ／ＨＴＴＰ（Ｓ）／ＴＣＰ／ＩＰ）を用いる）ＤＡＳＨを用いてブロードバンドを介して利用可能な１つ以上の連続コンポーネントトラック、及び／又はＤＡＳＨメディアプレゼンテーションタイムライン上のＮＴＰタイムスタンプ及び当該時間を含む一つの放送ＩＰマルチキャストストリームで構成されてもよい。（概念的に、ＤＡＳＨコンポーネントに対するＲＴＣＰストリームとして考えることができる。）その目的は、（プロトコル経路Ｒｅｆ−Ｃｌｏｃｋｓ／ＩＰ−マルチキャスト／ＵＤＰ／ＩＰを用いて）ＤＡＳＨメディアプレゼンテーションタイムラインをＮＴＰタイムラインにマップすることである。

一つのビデオトラック、一つのオーディオトラック及び一つのクローズドキャプショントラックが放送を介して伝達され、第２オーディオトラックがユニキャストブロードバンドを介して伝達される、次のハイブリッド伝達を使用するケースを考慮することができる。

図面は、この場合のコンテンツ伝達のためのプロトコルスタックを示す。クロスハッチングされた灰色のオーディオトラックはプレゼンテーションに使用されない。

受信機は、シグナリングを用いて、どのオーディオトラックが提示されるか（この場合、代替（ａｌｔｅｒｎａｔｅ）オーディオトラック）を決定し、放送ビデオ及びクローズドキャプションＲＴＰ／ＲＴＣＰストリームのためのＩＰマルチキャストアドレス及びポートを取得し、ＤＡＳＨ−ＮＴＰクロックマッピングストリームのためのＩＰマルチキャストアドレス及びポートを取得し、及び／又は代替オーディオストリームのブロードバンドＤＡＳＨ伝達のためのＭＰＤのＵＲＬを取得することができる。

受信機は、ＭＰＤのＵＲＬを用いてＤＡＳＨＭＰＤを検索することができる。

受信機は、ビデオ及びクローズドキャプショントラックのためのＲＴＰパケットが到達すると、それを放送から抽出することができる。

受信機は、ビデオ及びクローズドキャプショントラックのためのＲＴＣＰパケットが到達すると、それを放送から抽出することができる。

受信機は、ＮＴＰ−ＤＡＳＨクロックマッピングパケットが到達すると、それを抽出することができる。

ビデオ及びクローズドキャプショントラックに対して、ＲＴＰ伝達と同様に、受信機は、トラックに対するＲＴＣＰストリーム内のＮＴＰタイムスタンプ（Ｎ（ｉ））及び当該ＲＴＰタイムスタンプ（Ｒ（ｉ））を用いて、（ＲＴＰタイムラインに関する）ＲＴＰパケットヘッダー内のプレゼンテーション時間をＮＴＰタイムラインに関するプレゼンテーション時間に変換することができる。

受信機は、ＮＴＰ−ＤＡＳＨクロックマッピングパケットを用いて、ＤＡＳＨメディアプレゼンテーションタイムラインをＮＴＰタイムラインにマップすることができる（これらの両タイムラインのタイムスケールは通常のクロック時間であるため、それらの間のオフセットを決定する必要がある）。

受信機は、パケットが受信される時点でＲＴＣＰパケット内のＮＴＰタイムスタンプを受信機壁時計時間と比較し、それらの間の任意のオフセットを決定することができる。（伝達遅延及び受信機壁時計とサーバーＮＴＰクロックとの間の可能な不一致の組み合わせが、ゼロではないオフセットを誘発し得る。）このオフセットを用いて、ＲＴＰパケットヘッダー内のプレゼンテーション時間をＮＴＰタイムラインから受信機壁時計タイムラインに調節し、ＤＡＳＨメディアプレゼンテーションタイムラインとＮＴＰタイムラインとの間のマッピングを調節して、ＤＡＳＨメディアプレゼンテーションタイムラインと受信機壁時計タイムラインとの間のマッピングを得ることができる。

受信機は、適切な壁時計時間でＲＴＰストリーム（ビデオ及びクローズドキャプショントラック）内のアクセスユニットを提示することができる。

前記ステップのマッピングを用いて、受信機は、現在の受信機壁時計時間に対応するＤＡＳＨメディアプレゼンテーションタイムライン内の時間を決定することができる。ＭＰＤを用いて、当該ＤＡＳＨ期間、所望のオーディオトラックを含むＤＡＳＨ表示、ＤＡＳＨセグメント及びそのセグメントのＵＲＬを決定する。

受信機は、そのＤＡＳＨセグメント及び後続のセグメントを検索することができる。そして、前記ステップのマッピングを用いて、適切な壁時計時間にそれらの内のアクセスユニットを提示する。

図８２は、本発明の実施例として、受信機壁時計タイムラインへのＤＡＳＨプレゼンテーション時間の変換を示す図である。

ＤＡＳＨメディアプレゼンテーションタイムラインに関するプレゼンテーション時間（ＰＴＤ）は、ＮＴＰタイムラインに関するプレゼンテーション時間（ＰＴＮ）に変換された後、壁時計時間に対するプレゼンテーション時間（ＰＴＷ）に変換される。

図８３は、本発明の実施例として、ＡＬＣ／ＬＣＴ＋を介して伝達されたコンテンツと、ＤＡＳＨ（ユニキャスト）を介して伝達されたコンテンツとの同期化を示す図である。

本文書に記載されたように、放送タイムラインは、連続コンテンツがＡＬＣ／ＬＣＴ＋を介して伝達される度に確立され、ＡＬＣ／ＬＣＴ＋パケットのＬＣＴヘッダーエクステンション内のプレゼンテーションタイミング情報のための基準タイムベースとして機能することができる。ＤＡＳＨ（ユニキャスト）を介して伝達されたコンテンツと、ＡＬＣ／ＬＣＴ＋（放送又はマルチキャスト）を介して伝達されたコンテンツとを同期化するために、ＤＡＳＨメディアプレゼンテーションタイムラインから放送タイムラインへのマッピングを確立するのに必要な情報が、図示のように放送又はマルチキャストで伝達されてもよい。

情報は、タイムラインコンポーネントＡＵ（又は放送タイムラインパケット又はタイムベースコンポーネント）に対応し得る。

放送網及びインターネットなどの異種網を介して伝送されるストリームが、上述した放送システムの受信機で一つのサービスのために同期化されて使用される可能性がある。例えば、図示のように、ビデオストリームが放送網を介して伝送され、オーディオストリームがインターネットを介して伝送される場合、２つのストリームは１つのサービスのために同期化され、デコーディングされ、再生される必要がある。すなわち、ビデオが放送網を介して取得され、オーディオがインターネットを介して取得されて一つのサービスを用いる。例えば、放送網で提供された言語から異なる言語で記録されたオーディオを用いて同一のコンテンツを見ることを望む視聴者は、インターネットを介して所望の言語で記録された当該コンテンツのオーディオを受信し、受信されたオーディオを使用することができる。

しかし、２つのストリームは互いに異なるタイムラインを有し、したがって、２つのタイムライン間のマッピングを行うメカニズムが必要である。ここで、タイムラインのそれぞれは、各伝送網を介して伝送されたデータ又はコンテンツの再生またはデコーディングのための基準として機能する絶対又は相対時間を示すことができる。サービスにおいて、放送網を介して伝送されるビデオ内に含まれるコンテンツがインターネットを介して伝送されるオーディオに含まれるコンテンツと同一である必要がある。

本実施例は、放送網及びインターネットなどの異種網を介して伝送されたストリーム間の同期化のためにタイムラインコンポーネントを用いる方法及び装置を提案する。タイムラインコンポーネントストリームは、１つ以上のタイムラインコンポーネントアクセスユニット（ＡＵ）を含むことができる。タイムラインコンポーネントＡＵは、タイムラインコンポーネントに隣接して配置されてもよい。

タイムラインコンポーネントＡＵは、インターネットを介して伝送されるストリームのタイムラインが、放送網を介して伝送されるストリームのタイムラインにマップされる例を示す。放送網を介して伝送されるパケットのヘッダーが、放送網を介して伝送されるストリームのタイムラインに関する情報を含む場合、放送網を介して伝送可能なタイムラインコンポーネントＡＵは、異種網（例えば、インターネット）を介して伝送されるストリームのデコーディングタイムスタンプ（ＤＴＳ）、プレゼンテーションタイムスタンプ（ＰＴＳ）などのタイムスタンプ情報を含むことができる。異種網（例えば、インターネット）を介して伝送されるストリームのタイムラインに関する情報がタイムラインコンポーネントＡＵに含まれる場合、異種網（例えば、インターネット）を介して伝送されるストリームのタイムラインに関する情報が放送網を介して伝送されるストリームと同一のパケット構造でパケット化され得る。この方式で、パケットヘッダーに含まれる放送網を介して伝送されるストリームのタイムスタンプが、インターネットを介して伝送されたストリームのタイムスタンプに一対一マッピングされてもよく、両ストリームは、一つのタイムラインで同期化され、デコーディングされ、再生されてもよい。

プレゼンテーションタイムスタンプ（ＰＴＳ）は、視聴者に提示されるとき、プログラムの個別エレメンタリストリーム（例えば、ビデオ、オーディオ、サブタイトル）の同期化を達成するのに使用されるＭＰＥＧ伝送ストリーム、ＭＰＥＧプログラムストリームまたは類似データストリーム内のタイムスタンプメタデータフィールドである。ＰＴＳは、プログラムの全体のクロック基準、プログラムクロック基準（ＰＣＲ）またはシステムクロック基準（ＳＣＲ）に関連する単位で与えられ、また、これは、伝送ストリーム又はプログラムストリームで伝送される。

デコードタイムスタンプ（ＤＴＳ）は、アクセスユニットが受信機バッファーから瞬間的に除去されてデコードされる時間を示す。これは、ピクチャリオーダリング（ｐｉｃｔｕｒｅｒｅｏｒｄｅｒｉｎｇ）がＢピクチャに使用される場合にのみプレゼンテーションタイムスタンプ（ＰＴＳ）と異なる。ＤＴＳが使用されると、ＰＴＳはビットストリームで提供されてもよい。

前記説明は、一つの網を介して伝送されたストリームが、互いに異なるタイムラインを使用する場合に適用することができる。例えば、上述した方式が用いられると、複数の異種網を介して伝送されたストリームを収集し、そのストリームを視聴者に提供するリレイサービス提供者は、互いに異なるストリームの同期化に対するリプロセッシングを直接行う必要がない。

タイムラインコンポーネントＡＵは、ＸＭＬなどの他のフォーマットで表現されてもよい。タイムラインコンポーネントＡＵは、ｉｄｅｎｔｉｆｉｅｒ情報、ｖｅｒｓｉｏｎ情報、ＡＵ_ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ_ｆｌａｇ情報、ＰＴＳ_ｆｌａｇ情報、ＤＴＳ_ｆｌａｇ情報、ｍｅｄｉａ_ｔｉｍｅ_ｆｌａｇ情報、ＮＴＰ_ｔｉｍｅ_ｆｌａｇ情報、ＰＴＰ_ｔｉｍｅ_ｆｌａｇ情報、ｔｉｍｅｃｏｄｅ_ｆｌａｇ情報、ＰＣＲ_ｔｉｍｅ_ｆｌａｇ情報、ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ情報、ｔｉｍｅｓｃａｌｅ情報、ｍｅｄｉａ_ｔｉｍｅ_ＰＴＳ情報、ｍｅｄｉａ_ｔｉｍｅ_ＤＴＳ情報、ＮＴＰ_ｔｉｍｅ_ＰＴＳ情報、ＮＴＰ_ｔｉｍｅ_ＤＴＳ情報、ＰＴＰ_ｔｉｍｅ_ＰＴＳ情報、ＰＴＰ_ｔｉｍｅ_ＤＴＳ情報、ｔｉｍｅｃｏｄｅ_ＰＴＳ情報、ｔｉｍｅｃｏｄｅ_ＤＴＳ情報、ＰＣＲ_ｔｉｍｅ_ＰＴＳ情報及び／又はＰＣＲ_ｔｉｍｅ_ＤＴＳ情報を含むことができる。

ｉｄｅｎｔｉｆｉｅｒ情報は、タイムラインコンポーネントＡＵの構造を固有に示す識別子である。

ｖｅｒｓｉｏｎ情報は、下位ＰＴＳ、ＤＴＳなどのタイムスタンプフィールドの長さを示すことができる。例えば、長さは、バージョン情報が１の値を有するとき、６４ビットに対応し、バージョン情報が０の値を有するとき、３２ビットに対応し得る。

ＡＵ_ｌｅｎｇｔｈ情報は、タイムラインコンポーネントＡＵの長さを示すことができる。

ｌｏｃａｔｉｏｎ_ｆｌａｇ情報は、タイムラインコンポーネントＡＵが外部網を介して伝送されたストリームの位置情報を含むか否かを示す。

ＰＴＳ_ｆｌａｇ情報は、タイムラインコンポーネントＡＵがＰＴＳ値を含むか否かを示す。

ＤＴＳ_ｆｌａｇ情報は、タイムラインコンポーネントＡＵがＤＴＳ値を含むか否かを示す。

ｍｅｄｉａ_ｔｉｍｅ_ｆｌａｇ情報は、メディアタイムフォーマットを有するタイムスタンプが含まれるか否かを示す。

ＮＴＰ_ｔｉｍｅ_ｆｌａｇ情報は、ＮＴＰフォーマットを有するタイムスタンプが含まれるか否かを示す。

ＰＴＰ_ｔｉｍｅ_ｆｌａｇ情報は、ＰＴＰフォーマットを有するタイムスタンプが含まれるか否かを示す。

ｔｉｍｅｃｏｄｅ_ｆｌａｇ情報は、ＳＭＰＴＥ（ｓｏｃｉｅｔｙｏｆｍｏｔｉｏｎｐｉｃｔｕｒｅａｎｄｔｅｌｅｖｉｓｉｏｎｅｎｇｉｎｅｅｒｓ）タイムコードフォーマットを有するタイムスタンプが含まれるか否かを示す。

ＰＣＲ_ｔｉｍｅ_ｆｌａｇ情報は、ＭＰＥＧ−２ＴＳのＰＣＲベースのタイムスタンプが含まれるか否かを示す。

ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈ情報は、位置フィールドの長さを示す。

ｌｏｃａｔｉｏｎ情報は、異種網を介して伝送されるストリームの固有のＩＤ又はＵＲＬを示す。位置情報が固有のＩＤを示す場合、位置情報は、シグナリングデータなどの情報にリンクされることによって使用され得る。

ｔｉｍｅｓｃａｌｅ情報は、メディアタイムスケールを示す。タイムスケール情報は、他の情報によって指示された時間単位を識別する情報である。

ｍｅｄｉａ_ｔｉｍｅ_ＰＴＳ情報は、メディアタイムフォーマットで表現されるＰＴＳを示す。

ｍｅｄｉａ_ｔｉｍｅ_ＤＴＳ情報は、メディアタイムフォーマットで表現されるＤＴＳを示す。

ＮＴＰ_ｔｉｍｅ_ＰＴＳ情報は、ＮＰＴフォーマットで表現されるＰＴＳを示す。

ＮＴＰ_ｔｉｍｅ_ＤＴＳ情報は、ＮＰＴフォーマットで表現されるＤＴＳを示す。

ＰＴＰ_ｔｉｍｅ_ＰＴＳ情報は、ＰＴＰフォーマットで表現されるＰＴＳを示す。

ＰＴＰ_ｔｉｍｅ_ＤＴＳ情報は、ＰＴＰフォーマットで表現されるＤＴＳを示す。

ＰＴＰ_ｔｉｍｅ_ＰＴＳ情報又はＰＴＰ_ｔｉｍｅ_ＤＴＳ情報は、３２ビット、６４ビットまたは８０ビットのサイズを有することができる。

ｔｉｍｅｃｏｄｅ_ＰＴＳ情報は、ＳＭＰＴＥタイムコードフォーマットで表現されるＰＴＳを示す。

ｔｉｍｅｃｏｄｅ_ＤＴＳ情報は、ＳＭＰＴＥタイムコードフォーマットで表現されるＤＴＳを示す。

ＰＣＲ_ｔｉｍｅ_ＰＴＳ情報は、ＰＣＲフォーマットで表現されるＰＴＳを示す。

ＰＣＲ_ｔｉｍｅ_ＤＴＳ情報は、ＰＣＲフォーマットで表現されるＤＴＳを示す。

本発明の実施例によれば、受信機は、タイムラインコンポーネントＡＵに含まれる少なくとも１つのタイムスタンプ情報を位置情報によって識別された外部網内のストリームに適用することによって、放送網を介して伝送されたストリームを異種網を介して伝送されたストリームと同期化することができる。

タイムラインコンポーネントＡＵは、ＸＭＬなどの他のフォーマットで表現されてもよい。タイムラインコンポーネントＡＵは、ｉｄｅｎｔｉｆｉｅｒ情報、ｖｅｒｓｉｏｎ情報、ＡＵ_ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ_ｆｌａｇ情報、ＰＴＳ_ｆｌａｇ情報、ＤＴＳ_ｆｌａｇ情報、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ_ｆｌａｇ情報、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報、ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ情報、ｔｉｍｅｓｃａｌｅ情報、ｍｅｄｉａ_ｔｉｍｅ_ＰＴＳ情報、ｍｅｄｉａ_ｔｉｍｅ_ＤＴＳ情報、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ_ＰＴＳ情報及び／又はｔｉｍｅｓｔａｍｐ_ｔｏ_ＤＴＳ情報（又はｔｉｍｅｓｔａｍｐ_ｔｙｐｅ_ＤＴＳ情報）を含むことができる。

上述したタイムラインコンポーネントＡＵのシンタックスに含まれる情報と同一の用語に対応する情報の説明は、前記説明で代替される。

ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ_ｆｌａｇ情報は、マップされるタイムラインのタイムスタンプフォーマットを示す。例えば、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ_ｆｌａｇ情報が０の値を有するとき、３２ビットフォーマットが使用され、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ_ｆｌａｇ情報が１の値を有するとき、６４ビットフォーマットが使用されることを示すことができる。

ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報は、マップされるタイムラインのタイムスタンプのタイプを示す。例えば、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ情報は、情報が０ｘ００の値を有するとき、タイプがメディアタイムに対応することを示し、情報が０ｘ０１の値を有するとき、タイプがＮＴＰに対応することを示し、情報が０ｘ０２の値を有するとき、タイプがＰＴＰに対応することを示し、情報が０ｘ０３の値を有するとき、タイプがタイムコードに対応することを示す。情報が０ｘ０４〜０ｘ１Ｆの値を有するとき、タイプは後で定義され得、値はリザーブド（ｒｅｓｅｒｖｅｄ）される。

タイムスケール情報は、マップされるタイムラインのメディアタイムを示すタイムスケールを示すことができる。例えば、ＭＰＥＧ−２ＴＳにおいて、タイムスケールは９０Ｋの値を有することができる。

ｍｅｄｉａ_ｔｉｍｅ_ＰＴＳ情報は、マップされるタイムラインのプレゼンテーションタイムスタンプ、すなわち、再生が行われる時点に対するメディアタイムを示すことができる。ｍｅｄｉａ_ｔｉｍｅ_ＰＴＳ情報は、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ_ｆｌａｇの値が０であるとき、３２ビットフォーマットで指示され、その値が１であるとき、６４ビットフォーマットで指示されてもよい。

ｍｅｄｉａ_ｔｉｍｅ_ＤＴＳ情報は、マップされるタイムラインのデコーディングタイムスタンプ、すなわち、デコーディングが行われる時点に対するメディアタイムを示すことができる。ｍｅｄｉａ_ｔｉｍｅ_ＤＴＳ情報は、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ_ｆｌａｇの値が０であるとき、３２ビットフォーマットで指示され、その値が１であるとき、６４ビットフォーマットで指示されてもよい。

ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ_ＰＴＳ情報は、マップされるタイムラインのタイムスタンプタイプによるプレゼンテーションタイムスタンプ、すなわち、再生が行われる時点を示すことができる。ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ_ＰＴＳ情報は、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ_ｆｌａｇの値が０であるとき、３２ビットフォーマットで指示され、その値が１であるとき、６４ビットフォーマットで指示されてもよい。例えば、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールド値がＮＴＰを示す場合、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ_ＰＴＳフィールド値は、ＮＴＰベースの再生時点に対するタイムスタンプ値を有することができる。

ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ_ＤＴＳ情報は、マップされるタイムラインのタイムスタンプタイプによるデコーディングタイムスタンプ、すなわち、デコーディングが行われる時点を示すことができる。ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ_ＤＴＳ情報は、ｔｉｍｅｓｔａｍｐ_ｖｅｒｓｉｏｎ_ｆｌａｇの値が０であるとき、３２ビットフォーマットで指示され、その値が１であるとき、６４ビットフォーマットで指示されてもよい。例えば、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅフィールド値がＮＴＰを示す場合、ｔｉｍｅｓｔａｍｐ_ｔｙｐｅ_ＤＴＳフィールド値は、ＮＴＰベースのデコーディング時点に対するタイムスタンプ値を有することができる。

タイムラインコンポーネントを用いて異種網を介して伝送される伝送ストリーム間のタイムラインの共有を通じた上述した同期化方式において、タイムラインは、放送網伝送ストリームのパケットヘッダーのタイムスタンプをパケットペイロードのタイムラインコンポーネントＡＵに含まれるインターネット伝送ストリームのタイムスタンプに一対一マッピングすることによって共有され得る。

しかし、タイムスタンプ関連情報は、放送網伝送パケットのヘッダーに存在しないことがある。

図示のように、タイムスタンプ関連情報が伝送パケットのヘッダーに存在しない場合、タイムライン内の本来のタイムスタンプに対する追加の情報が必要である。タイムラインは、本来のタイムスタンプをインターネット伝送ストリームのタイムスタンプに一対一マッピングすることによって放送網とインターネットとの間で共有されてもよい。

本来のタイムスタンプ及び異種網（例えば、インターネット）内の伝送ストリームのタイムスタンプに関連する情報が、タイムラインコンポーネントＡＵに含まれてもよい。

本来のタイムスタンプは、基準タイムライン上のタイムスタンプとして定義されてもよい。例えば、上述した実施例において、放送網を介して伝送されるストリームに対するタイムスタンプは、本来のタイムスタンプとして定義されてもよい。

本発明の他の実施例に係るタイムラインコンポーネントＡＵのシンタックスは、上述したタイムラインコンポーネントＡＵのシンタックスに加え、本来のタイムスタンプに関連する情報を含むことができる。

タイムラインコンポーネントＡＵは、ｉｄｅｎｔｉｆｉｅｒ情報、ｖｅｒｓｉｏｎ情報、ＡＵ_ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ_ｆｌａｇ情報、ｏｒｉｇｉｎ_ＰＴＳ_ｆｌａｇ情報、ｏｒｉｇｉｎ_ＤＴＳ_ｆｌａｇ情報、ｏｒｉｇｉｎ_ＰＴＳ情報、ｏｒｉｇｉｎ_ＤＴＳ情報、ｌｏｃａｔｉｏｎ_ｌｅｎｇｔｈ情報、ＰＴＳ_ｆｌａｇ情報、ＤＴＳ_ｆｌａｇ情報、ｍｅｄｉａ_ｔｉｍｅ_ｆｌａｇ情報、ＮＴＰ_ｔｉｍｅ_ｆｌａｇ情報、ＰＴＰ_ｔｉｍｅ_ｆｌａｇ情報、ｔｉｍｅｃｏｄｅ_ｆｌａｇ情報、ＰＣＲ_ｔｉｍｅ_ｆｌａｇ情報、ｌｏｃａｔｉｏｎ_ＵＲＬ_ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ_ＵＲＬ情報、ｔｉｍｅｓｃａｌｅ情報、ｍｅｄｉａ_ｔｉｍｅ_ＰＴＳ情報、ｍｅｄｉａ_ｔｉｍｅ_ＤＴＳ情報、ＮＴＰ_ｔｉｍｅ_ＰＴＳ情報、ＮＴＰ_ｔｉｍｅ_ＤＴＳ情報、ＰＴＰ_ｔｉｍｅ_ＰＴＳ情報、ＰＴＰ_ｔｉｍｅ_ＤＴＳ情報、ｔｉｍｅｃｏｄｅ_ＰＴＳ情報、ｔｉｍｅｃｏｄｅ_ＤＴＳ情報、ＰＣＲ_ｔｉｍｅ_ＰＴＳ情報及び／又はＰＣＲ_ｔｉｍｅ_ＤＴＳ情報を含むことができる。

ｏｒｉｇｉｎ_ＰＴＳ_ｆｌａｇ情報は、タイムラインコンポーネントＡＵがｏｒｉｇｉｎ_ＰＴＳ値を含むか否かを示す。

ｏｒｉｇｉｎ_ＤＴＳ_ｆｌａｇ情報は、タイムラインコンポーネントＡＵがｏｒｉｇｉｎ_ＤＴＳ値を含むか否かを示す。

ｏｒｉｇｉｎ_ＰＴＳ情報は、タイムラインマッピングの基準ベースタイムライン上の現在のパケットのＰＴＳを示す。

ｏｒｉｇｉｎ_ＤＴＳ情報は、タイムラインマッピングの基準ベースタイムライン上の現在のパケットのＤＴＳを示す。

ｌｏｃａｔｉｏｎ_ＵＲＬ_ｌｅｎｇｔｈ情報は、ｌｏｃａｔｉｏｎ_ＵＲＬ情報の長さを示す。

ｌｏｃａｔｉｏｎ_ＵＲＬ情報は、異種網を介して伝送されるストリームのＵＲＬ又は異種網を介して伝送されるストリームを固有に識別する識別子を示すことができる。

受信機は、放送網で伝送ストリームのパケットペイロードからタイムラインコンポーネントＡＵを取得し、タイムラインコンポーネントＡＵ内のｏｒｉｇｉｎ_ＰＴＳ情報及び／又はｏｒｉｇｉｎ_ＤＴＳ情報をパースし、パースされた情報に基づいて、放送網で伝送ストリームのためのタイムスタンプ情報を取得することができる。受信機は、ｏｒｉｇｉｎ_ＰＴＳ情報及び／又はｏｒｉｇｉｎ_ＤＴＳ情報を通じて取得された放送網内の伝送ストリームのタイムスタンプ及びタイムスタンプコンポーネントＡＵに含まれる異種網のためのタイムスタンプに関連する情報を用いて、放送網の伝送ストリームを異種網の伝送ストリームと同期化することができる。

図８４は、本発明の実施例として、ＡＬＣ／ＬＣＴ＋を介して伝達されたコンテンツとＤＡＳＨ（ユニキャスト）を介して伝達されたコンテンツとの同期化方式を示す図である。

ＡＬＣ／ＬＣＴ＋を介して伝達されるそれぞれの連続メディアコンポーネントが、ＡＬＣエクステンションヘッダー内の放送タイムラインクロック基準タイムスタンプを有するか、またはサービスの個別放送「タイムベース」コンポーネントが、適切な間隔で放送タイムラインクロック基準タイムスタンプを伝達することができる。

放送タイムラインクロック基準タイムスタンプがＡＬＣエクステンションヘッダーに含まれる場合、当該ＤＡＳＨメディアプレゼンテーションタイムライン基準タイムスタンプが共に含まれることで、ＤＡＳＨメディアプレゼンテーションタイムラインから放送タイムラインへのマッピングを提供することができる。

放送クロック基準タイムスタンプがサービスの個別放送タイムベースコンポーネントに含まれる場合、当該ＤＡＳＨメディアプレゼンテーションタイムライン基準タイムスタンプが共に個別放送タイムベースコンポーネントに含まれることで、ＤＡＳＨメディアプレゼンテーションタイムラインから放送タイムラインへのマッピングを提供することができる。

放送又はブロードバンドを介して受信機に伝達されることは、「放送タイムライン」に対するクロック基準タイムスタンプ及びＤＡＳＨを用いて（プロトコル経路Ｒｅｆ−Ｃｌｏｃｋｓ／ＩＰ−Ｍｕｌｔｉｃａｓｔ／ＵＤＰ／ＩＰを用いて）ブロードバンドを介して利用可能な代替オーディオストリームのＤＡＳＨメディアプレゼンテーションタイムラインに対する当該タイムスタンプを含む一つの放送ＩＰマルチキャストストリーム、及び連続コンポーネントトラック（例えば、ビデオ、オーディオ及びクローズドキャプション）のそれぞれに対する一つの放送ＩＳＯＢＭＦＦストリームで構成され得る。それぞれのＩＳＯＢＭＦＦファイルは、（プロトコル経路ＩＳＯＢＭＦＦ／ＡＬＣ／ＬＣＴ＋ＩＰ−Ｍｕｌｔｉｃａｓｔ／ＵＤＰ／ＩＰを用いて）ＡＬＣ／ＬＣＴ＋オブジェクト、及び／又は（プロトコル経路ＩＳＯＢＭＦＦ／ＤＡＳＨ／ＨＴＴＰ（Ｓ）／ＴＣＰ／ＩＰを用いて）ＤＡＳＨを用いてブロードバンドを介して利用可能な１つ以上の連続コンポーネントトラックとして伝達され得る。

「放送タイムライン」に対するクロック基準タイムスタンプ及びＤＡＳＨを用いてユニキャストブロードバンドを介して利用可能な代替オーディオストリームのＤＡＳＨメディアプレゼンテーションタイムラインに対する当該タイムスタンプを含む一つの放送ＩＰマルチキャストストリームのために、タイムラインのタイムスケールが通常のクロック時間であり、例えば、クロックは、任意の適切なフォーマット（おそらく、ＮＴＰフォーマット）で表現されるサーバーでのＵＴＣ時間であってもよい。

連続コンポーネントトラック（例えば、ビデオ、オーディオ及びクローズドキャプション）のそれぞれに対する一つの放送ＩＳＯＢＭＦＦストリームに対して、ＩＳＯＢＭＦＦファイルの開始を含むＡＬＣ／ＬＣＴ＋パケットは、「放送タイムライン」に対してＩＳＯＢＭＦＦファイルのタイムラインに対する開始時間を提供するＬＣＴエクステンションヘッダーを有する。ＵＲＬをそれぞれのＩＳＯＢＭＦＦファイルと関連付ける必要がある場合（例えば、ＭＰＤがシグナリングに使用される場合）、それぞれのＩＳＯＢＭＦＦファイルは、コンテンツ−位置フィールドを含むＨＴＴＰ−スタイルヘッダーを有することができる。または、ＩＳＯＢＭＦＦファイルの開始を含むＡＬＣ／ＬＣＴ＋パケットは、関連付けられたＵＲＬを含むＬＣＴエクステンションヘッダーを有することができる。

一つのビデオトラック、一つのオーディオトラック及び／又は一つのクローズドキャプショントラックが放送を介して伝達され、第２オーディオトラックがユニキャストブロードバンドを介して伝達される、次のハイブリッド伝達を使用するケースを考慮する。

図８５は、本発明の実施例として、ＡＬＣ／ＬＣＴ＋を通じてＩＳＯＢＭＦＦのハイブリッド伝達のためのプロトコルスタックを示す図である。

クロスハッチングされた灰色のオーディオトラックはプレゼンテーションに使用されない。

受信機は、シグナリングを用いて、どのオーディオトラックが提示されるか（この場合、代替オーディオトラック）を決定し、ＩＰマルチキャストアドレス及びポート、及びビデオ及びクローズドキャプショントラックを伝達するＡＬＣ／ＬＣＴ＋セッションのためのＴＳＩ値を得、クロック基準／マッピングストリームのためのＩＰマルチキャストアドレス及びポートを得、及び／又は代替オーディオストリームのブロードバンドＤＡＳＨ伝達のためのＭＰＤのＵＲＬを得ることができる。

受信機は、ＭＰＤのＵＲＬを用いてＤＡＳＨＭＰＤを検索（ｒｅｔｒｉｅｖｅ）することができる。

受信機は、タイムスタンプが現れるとき、クロック基準／マッピングストリームからそれを抽出し、それを用いて「放送タイムライン」と受信機「壁時計」タイムラインとの間のオフセットを決定し、ＤＡＳＨメディアプレゼンテーションタイムラインと「放送タイムライン」との間のオフセットを決定することができる。これは、ＤＡＳＨメディアプレゼンテーションタイムラインから受信機「壁時計」タイムラインへのマッピングを招く。

受信機は、ビデオ及びクローズドキャプショントラックに対する放送ＩＳＯＢＭＦＦファイルが現れるとき、放送からそれを抽出することができる。

受信機は、前記ステップで決定されたオフセットによって調節されたそれぞれのＢＭＦＦファイルのＡＬＣ／ＬＣＴ＋エクステンションヘッド内のプレゼンテーションタイムスタンプを用いて、各ＩＳＯＢＭＦＦファイルのタイムラインに対する壁時計開始時間を設定することができる。

受信機は、各ＩＳＯＢＭＦＦファイルのための壁時計開始時間及びファイル内の内部タイミング情報に基づいて、適切な時間に放送ＢＭＦＦファイル内のアクセスユニットを提示することができる。

前記ステップで得たタイムラインマッピングを用いて、受信機は、現在の受信機壁時計時間に対応するＤＡＳＨメディアプレゼンテーションタイムライン内の時間を決定することができる。ＭＰＤを用いて、当該ＤＡＳＨ期間、所望のオーディオトラックを含むＤＡＳＨ表示及びセグメントのＵＲＬを決定する。適切なＤＡＳＨセグメントを検索し、それらを適切な壁時計時間に提示する。

前記２つの方法は、他の伝送プロトコルが放送チャネルに使用されるときに適用することができる。

放送システムは、より多くの情報をユーザに提示するために、リアルタイム連続コンテンツ及びＮＲＴファイルが結合される放送コンテンツを提供することができる。

非リアルタイムファイルからの連続コンテンツのプレイアウト（ｐｌａｙ−ｏｕｔ）とリアルタイムで伝達される連続コンテンツを同期化するために、同期化に対する一般的なアプローチは、ファイルベースのコンテンツのタイムラインをリアルタイム連続コンテンツのタイムラインにマップすることである。

例えば、同期化は、ＲＴＰの場合、ファイルベースのコンテンツのタイムラインをＮＴＰタイムベースにマップしたり、放送／マルチキャストコンテンツの場合、ＡＬＣ／ＬＣＴを介してＩＳＯＢＭＦＦ内の放送タイムラインにマップすることができる。同様に、ファイルからの連続コンテンツのプレイアウトをユニキャストを介して伝達される連続コンテンツと同期化しようとする場合、一般的なアプローチは、ファイルベースのコンテンツのタイムラインをＤＡＳＨメディアプレゼンテーションタイムラインにマップすることである。

ファイルベースのコンテンツのタイムラインを決定する方法は、ファイルフォーマットによって決定される。同期化メカニズムを特定するために、ファイルベースのタイムラインのクロックレート、及びこのタイムラインに対してファイル内の第１プレゼンテーションユニットのプレゼンテーション時間を要求する必要がある。ファイルベースのコンテンツのタイムラインに関するこの情報が決定される方法は、ファイルフォーマットによって決定され得る。タイムラインは、ファイル内の第１プレゼンテーションユニットに対応する開始時間及びクロックレートを特定し、ファイル内の全てのプレゼンテーションユニットは、このタイムラインに対してプレゼンテーション時間を有する。

適切なタイムラインマッピング情報がシグナリングされ得る。ＮＴＰ時間、放送タイムライン時間またはファイルの開始に対応するＤＡＳＨメディアプレゼンテーションタイムライン時間がシグナリングされ得る。これは、ファイル内の任意のプレゼンテーションユニットのプレゼンテーション時間が、このタイムラインに対して計算されるようにすることができる。

放送システムは、サービスシグナリングデータをエンコードして受信機に送信することができ、サービスシグナリングデータは、受信機で放送コンテンツを獲得するのに使用される。

サービスシグナリングをハンドリングできる一つの方法は、サービスモデルを反映する新たなサービスシグナリングデータ構造を定義し、このようなシグナリングの伝達のための適切なメカニズムを特定することである。このようなデータ構造は、連続コンポーネントのリアルタイムユニキャスト伝達をサポートするためにＤＡＳＨＭＰＤファイルを参照する方法を含む必要がある。

サービスシグナリングをハンドリングできる他の方法は、ＤＡＳＨＭＰＤ構造を用いて、リアルタイムで伝達される全ての連続コンポーネントをシグナリングし、これを任意のデータ構造で増加（ａｕｇｍｅｎｔ）させてコンポーネントの他のカテゴリーをシグナリングすることである。

前述した、本発明の方法は、前述した送信機又は受信機によって行うことができる。

本発明の説明は、明瞭化のために、添付の図面のそれぞれを参照して説明するが、添付の図面に示す実施例を併合することによって新しい実施例を設計することもできる。以上の説明で言及した実施例を実行するプログラムが記録されたコンピュータ読み取り可能記録媒体が当業者の必要によって設計されると、これも、添付した特許請求の範囲及びその均等物の範囲に属することができる。

本発明に係る装置及び方法は、以上の説明で言及された実施例の構成及び方法によって制限されない。以上の説明で言及された実施例は、全体的に又は部分的に互いに選択的に結合される方式で構成され、様々な変形が可能である。

また、本発明に係る方法は、ネットワーク装置に提供されるプロセッサ読み取り可能記録媒体でプロセッサ読み取り可能コードとして具現することができる。プロセッサ読み取り可能媒体は、プロセッサによって読み取り可能なデータを格納できるいかなる種類の記録装置も含むことができる。プロセッサ読み取り可能記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサ読み取り可能記録媒体は、ネットワークを介して接続されたコンピュータシステムに分散され、分散方式でプロセッサ読み取り可能コードが格納され、実行されてもよい。

当業者は、本発明の思想及び範囲から逸脱することなく本発明の様々な変形及び変更が可能であることが理解できる。したがって、本発明は、添付した特許請求の範囲及びその均等物の範囲内で提供される本発明の変形及び変更をカバーする。

装置及び方法発明が本明細書に言及されており、それらの装置及び方法発明の説明は相互補完的に適用されてもよい。

様々な実施例が、発明を実施するための形態において記載された。

本発明は、放送信号提供フィールドで有用である。本発明の思想又は範囲から逸脱することく本発明の様々な変形及び変更が可能であるということは当業者にとって自明である。したがって、本発明は、添付した特許請求の範囲及びその均等物の範囲内で提供される本発明の変形及び変更をいずれもカバーするように意図される。

Claims

一つ以上の網を介して放送コンテンツを受信する装置であって、
放送網を介して、前記放送コンテンツの第１部分を含む第１プロトコルパケットを含む放送ストリームを受信する放送網インターフェースと、
異種網を介して、前記放送コンテンツの第２部分を含む第２プロトコルパケットを受信する異種網インターフェースであって、前記放送ストリームは、前記１つ以上の網を介して伝送される異なるプロトコルパケット間の同期化のためのメタデータを含む第３プロトコルパケットをさらに含み、前記第３プロトコルパケットは、第２プロトコルパケットが取得される位置を特定する位置情報を含み、前記第３プロトコルパケットは、前記第１プロトコルパケットが使用される第１タイミングを特定する第１タイミング情報、及び第２プロトコルパケットが使用される第２タイミングを特定する第２タイミング情報をさらに含む、異種網インターフェースと、
前記第３プロトコルパケットに含まれる情報に基づいて前記第１プロトコルパケット及び前記第２プロトコルパケットを用いて前記放送コンテンツを構成するプロセッサと、
を含む、装置。
前記放送ストリームは、前記第１プロトコルパケットと異なるプロトコルを用いる第４プロトコルパケットをさらに含み、
前記第３プロトコルパケットは、前記第４プロトコルパケットが使用される第４タイミングを特定する第４タイミング情報をさらに含む、請求項１に記載の装置。
前記第１プロトコルパケットは、リアルタイムプロトコル（ＲＴＰ）パケットに対応し、
前記第２プロトコルパケットは、ＭＰＥＧＤＡＳＨセグメントを伝達し、
前記第３プロトコルパケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットに対応する、請求項１に記載の装置。
前記プロセッサは、
前記第１タイミング情報によって特定された第１タイミングをＮＴＰタイムラインにマッピングし、
前記位置情報に基づいて取得された前記第２プロトコルパケットに適用される前記第２タイミング情報によって特定された第２タイミングを前記ＮＴＰタイムラインにマッピングし、
前記ＮＴＰタイムラインを用いて前記第１プロトコルパケット及び前記第２プロトコルパケットを同期化することによって前記放送コンテンツを構成する、請求項３に記載の装置。
前記第１タイミング情報は、前記第１プロトコルパケットのＮＴＰタイムスタンプ及びＲＴＰタイムスタンプに対応し、
前記第２タイミング情報は、ＤＡＳＨメディアプレゼンテーション時間情報に対応する、請求項４に記載の装置。
前記第３プロトコルパケットは、前記第２タイミング情報のフォーマットを特定するフォーマット情報をさらに含む、請求項１に記載の装置。
前記プロセッサはさらに、
前記第１プロトコルパケットが受信される時点で前記ＮＴＰタイムスタンプと受信機壁時計時間との間のオフセットを算出し、
前記算出されたオフセットに基づいて前記第１タイミング及び前記第２タイミングを調節し、
前記調節された第１タイミング及び第２タイミングを用いて前記第１プロトコルパケット及び前記第２プロトコルパケットを同期化することによって前記放送コンテンツを構成する、請求項５に記載の装置。
受信機で一つ以上の網を介して放送コンテンツを受信する方法であって、
放送網を介して、前記放送コンテンツの第１部分を含む第１プロトコルパケットを含む放送ストリームを受信するステップと、
異種網を介して、前記放送コンテンツの第２部分を含む第２プロトコルパケットを受信するステップであって、前記放送ストリームは、前記１つ以上の網を介して伝送される異なるプロトコルパケット間の同期化のためのメタデータを含む第３プロトコルパケットをさらに含み、前記第３プロトコルパケットは、第２プロトコルパケットが取得される位置を特定する位置情報を含み、前記第３プロトコルパケットは、前記第１プロトコルパケットが使用される第１タイミングを特定する第１タイミング情報、及び第２プロトコルパケットが使用される第２タイミングを特定する第２タイミング情報をさらに含む、ステップと、
前記第３プロトコルパケットに含まれる情報に基づいて前記第１プロトコルパケット及び前記第２プロトコルパケットを用いて前記放送コンテンツを構成するステップと、
を含む、方法。
前記放送ストリームは、前記第１プロトコルパケットと異なるプロトコルを用いる第４プロトコルパケットをさらに含み、
前記第３プロトコルパケットは、前記第４プロトコルパケットが使用される第４タイミングを特定する第４タイミング情報をさらに含む、請求項８に記載の方法。
前記第１プロトコルパケットは、リアルタイムプロトコル（ＲＴＰ）パケットに対応し、
前記第２プロトコルパケットは、ＭＰＥＧＤＡＳＨセグメントを伝達し、
前記第３プロトコルパケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットに対応する、請求項８に記載の方法。
前記第１タイミング情報によって特定された第１タイミングをＮＴＰタイムラインにマッピングするステップと、
前記位置情報に基づいて取得された前記第２プロトコルパケットに適用される前記第２タイミング情報によって特定された第２タイミングを前記ＮＴＰタイムラインにマッピングするステップと、
前記ＮＴＰタイムラインを用いて前記第１プロトコルパケット及び前記第２プロトコルパケットを同期化することによって前記放送コンテンツを構成するステップと、
をさらに含む、請求項１０に記載の方法。
前記第１タイミング情報は、前記第１プロトコルパケットのＮＴＰタイムスタンプ及びＲＴＰタイムスタンプに対応し、
前記第２タイミング情報は、ＤＡＳＨメディアプレゼンテーション時間情報に対応する、請求項１１に記載の方法。
前記第３プロトコルパケットは、前記第２タイミング情報のフォーマットを特定するフォーマット情報をさらに含む、請求項８に記載の方法。
前記第１プロトコルパケットが受信される時点で前記ＮＴＰタイムスタンプと受信機壁時計時間との間のオフセットを算出するステップと、
前記算出されたオフセットに基づいて前記第１タイミング及び前記第２タイミングを調節するステップと、
前記調節された第１タイミング及び第２タイミングを用いて前記第１プロトコルパケット及び前記第２プロトコルパケットを同期化することによって前記放送コンテンツを構成するステップとをさらに含む、請求項１２に記載の方法。