JP6325122B2

JP6325122B2 - 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Info

Publication number: JP6325122B2
Application number: JP2016550478A
Authority: JP
Inventors: チャンウォンリ; セチンオ; ウソクコ; キョンソムン; ソンリョンホン
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2014-04-18
Filing date: 2015-04-08
Publication date: 2018-05-16
Anticipated expiration: 2035-04-08
Also published as: US20160337672A1; EP3133817A1; KR20160082241A; US10897636B2; KR20170136005A; KR101805537B1; KR101838083B1; CN106031181A; US11272231B2; WO2015160137A1; US20210144415A1; JP2017512001A; US20220150558A1; US11706467B2; EP3133817A4; CN106031181B

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は、ＰＬＳ１におけるＮＵＭ＿ＦＳＳでシグナルされる。ＦＳＳは、ＰＬＳセルを伝達する特殊なシンボルである。警告性及び遅延時間（ｌａｔｅｎｃｙ）はＰＬＳで重大な事案であるため、ＦＳＳは高いパイロット密度を有し、高速同期化及びＦＳＳ内における周波数のみのインターポレーション（補間）を可能にする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

タイムインターリービングは、ツイストされた行−列ブロックインターリーバである。ｎ番目のタイムインターリービンググループのｓ番目のタイムインターリービングブロックに対して、列の数Ｎ_ｃがＮ_{ｘＢＬＯＣＫ＿ＴＩ}（ｎ，ｓ）と同一であるが、タイムインターリービングメモリの行の数Ｎ_ｒは、セルの数Ｎ_{ｃｅｌｌｓ}と同一である（すなわち、Ｎ_ｒ＝Ｎ_{ｃｅｌｌｓ}）。

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

図２１（ａ）は、タイムインターリーバで書き込み動作を示し、図２１（ｂ）は、タイムインターリーバで読み取り動作を示す。（ａ）に示すように、一番目のＸＦＥＣＢＬＯＣＫはタイムインターリービングメモリの一番目の列に列方向に書き込まれ、二番目のＸＦＥＣＢＬＯＣＫは次の列に書き込まれ、このような動作が続けて行われる。そして、インターリービングアレイで、セルが対角線方向に読み取られる。（ｂ）に示すように、一番目の行から（最左列から始まって行に沿って右に）最後の行まで対角線方向読み取りが行われれる間に、Ｎ_ｒ個のセルが読み取られる。具体的に、ｚ_{ｎ，ｓ，ｉ}（ｉ＝０，．．．，Ｎ_ｒＮ_ｃ）を、順次に読み取られるタイムインターリービングメモリセル位置と仮定すれば、このようなインターリービングアレイにおける読み取り動作は、下記の式のように、行インデックスＲ_{ｎ，ｓ，ｉ}、列インデックスＣ_{ｎ，ｓ，ｉ}、関連したツイストパラメータＴ_{ｎ，ｓ，ｉ}を算出することによって実行される。

ここで、Ｓ_{ｓｈｉｆｔ}は、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（ｎ，ｓ）に関係なく対角線方向読み取り手順に対する共通シフト値であり、シフト値は、下記の式のように、ＰＬＳ２−ＳＴＡＴで与えられたＮ_{ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ}によって決定される。

結果的に、読み取られるセル位置は、座標ｚ_{ｎ，ｓ，ｉ}＝Ｎ_ｒＣ_{ｎ，ｓ，ｉ}＋Ｒ_{ｎ，ｓ，ｉ}によって算出される。

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

より具体的に、図２２は、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（０，０）＝３、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（１，０）＝６、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（２，０）＝５のとき、仮想ＸＦＥＣＢＬＯＣＫを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリでインターリービングアレイを示す。

変数Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（ｎ，ｓ）＝Ｎ_ｒは、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ}より小さい又は等しいだろう。したがって、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（ｎ，ｓ）に関わらず、受信機側で単一メモリデインターリービングを達成するために、ツイストされた行−列ブロックインターリーバ用インターリービングアレイは、仮想ＸＦＥＣＢＬＯＣＫをタイムインターリービングメモリに挿入することによってＮ_ｒ×Ｎ_ｃ＝Ｎ_{ｃｅｌｌｓ}×Ｎ_{ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ}のサイズに設定され、読み取り過程は次の式のように行われる。

タイムインターリービンググループの数は３に設定される。タイムインターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝‘１’、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝‘１’、すなわち、Ｎ_TI＝１、Ｉ_JUMP＝１、Ｐ_I＝１によってＰＬＳ２−ＳＴＡＴデータでシグナルされる。それぞれＮ_cells＝３０であるＸＦＥＣＢＬＯＣＫのタイムインターリービンググループ当たりの数は、それぞれのＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５によってＰＬＳ２−ＤＹＮデータでシグナルされる。ＸＦＥＣＢＬＯＣＫの最大数はＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸによってＰＬＳ２−ＳＴＡＴデータでシグナルされ、

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

より具体的に、図２３は、パラメータＮ'_{ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ}＝７及びＳ_shift＝（７−１）／２＝３を有するそれぞれのインターリービングアレイからの対角線方向読み取りパターンを示す。このとき、上で擬似コードと示した読み取り過程で、

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

図２４は、パラメータＮ'_{ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ}＝７及びＳ_shift＝３を有するそれぞれのインターリービングアレイからインターリーブされたＸＦＥＣＢＬＯＣＫを示す。

以下では、本発明の一実施例として、実時間放送環境でファイルベースマルチメディアコンテンツを伝送するためのファイルの分割生成方法及び消費方法を説明する。

具体的には、本発明の一実施例は、実時間放送環境でファイルベースマルチメディアコンテンツを伝送するためのデータ構成方案を提供する。また、本発明の一実施例は、実時間放送環境でファイルベースマルチメディアコンテンツを伝送するためのファイルの分割生成情報及び消費情報を識別する方法を提供する。また、本発明の一実施例は、実時間放送環境でファイルベースマルチメディアコンテンツを伝送するためのファイルの分割生成方法を提供する。また、本発明の一実施例は、実時間放送環境でファイルベースマルチメディアコンテンツを消費するためのファイルの分割消費方法を提供する。

図２５は、ＦＬＵＴＥプロトコルを用いた場合のデータ処理時間を示す図である。

近年、放送網とインターネット網とを結合したハイブリッド放送サービスが多く提供されている。ハイブリッド放送サービスは、Ａ／Ｖコンテンツを既存の放送網を介して伝送し、Ａ／Ｖコンテンツに関連した付加データをインターネット網を介して提供することができる。また、最近ではＡ／Ｖコンテンツの一部をインターネット網を介して送信するサービスも提供されている。

Ａ／Ｖコンテンツが異種網で伝送されることにより、異種網で伝送されるＡ／Ｖコンテンツデータ間の緊密な結合方法及び容易な相互運用方法が要求される。そのために、放送網及びインターネット網に共に適用可能な共通の伝送方法が必要である。

最近に考慮されている放送網及びインターネット網に共通に適用可能なＡ／Ｖコンテンツの伝送方法の一つは、ファイルベースマルチメディアコンテンツの使用である。ファイルベースマルチメディアコンテンツは拡張性に優れており、伝送プロトコルに対する依存性がないため、既存のインターネット網を介したダウンロード方式の形態で広く用いられている。

このように、放送網とインターネット網との連動に適合しており、大容量ファイルのファイルベースマルチメディアコンテンツを送信するに適したプロトコルがＦＬＵＴＥ（ＦｉｌｅＤｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ）である。

ＦＬＵＴＥは、ＡＬＣベースで単方向ファイルを伝送するためのアプリケーションであり、ファイルを送信する上で必要なファイル自体に関する情報又は伝送のための情報について定義しておいたプロトコルである。ＦＬＵＴＥは、ファイルを送信するにあって、まず、ＦＤＴ（ＦｉｌｅＤｅｌｉｖｅｒｙＴａｂｌｅ）インスタンスの送信を用いて、伝送に必要な情報及び伝送するファイルの様々な属性に関する情報を送った後にファイルを伝送する。

ＡＬＣ（ＡｓｙｎｃｈｒｏｎｏｕｓＬａｙｅｒｅｄＣｏｄｉｎｇ）は、単一送信者が複数の受信者にファイルを送信する間に、複数のチャネルを介して信頼性及び混雑制御が可能なように標準化したプロトコルである。ＡＬＣは、誤り制御のためのＦＥＣ形成ブロック、混雑制御のためのＷＥＢＲＣ形成ブロック、セッション及びチャネル管理のためのＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）形成ブロックを結合したものであり、サービスと必要によってビルディングブロックを構成できるようになっている。

ＡＬＣはコンテンツ伝達プロトコルであり、多数の受信者に非常に効率的な伝送を可能にする。また、ＡＬＣは単方向性を有すると共に、必要によって制限的伝送が可能であり、フィードバックのための特定チャネル及びリソースが不要であるため、無線環境だけでなく、衛星環境のブロードキャストでも用いることができる。ＡＬＣは、フィードバックがないため、信頼性のためにＦＥＣコードスキームを全体的に又は部分的に適用して、信頼できるサービスを提供する。また、伝達しようとするオブジェクトは、適用されるＦＥＣスキームによってＦＥＣエンコーディングを経て伝送ブロックとＦＥＣスキームによって生成された追加のシンボルを構成して伝達される。ＡＬＣのセッションは、一つ以上のチャネルで構成され、複数の受信者は、ネットワーク状態に応じてセッション内のチャネルを選択して所望のオブジェクトを受信する。受信者は自身のコンテンツ受信にのみ専念することができ、他の受信者の状態又はパケット損失にもほとんど影響を受けない。したがって、ＡＬＣは、高い堅固性を有し、マルチレイヤ（ｍｕｌｔｉ−ｌａｙｅｒｅｄ）伝送を用いて安定したコンテンツダウンロードを提供することができる。

ＬＣＴは、信頼性あるコンテンツ伝送（例えば、ＦＬＵＴＥ）及びストリーム伝送プロトコルのための伝送レベルの支援を提供する。ＬＣＴは、受信者に伝達する基本的な情報の内容と特徴に関する情報を提供する。例えば、ＬＣＴは、ＴＳＩ（ＴｒｅａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ）フィールド、ＴＯＩ（ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩＤ）フィールド、及びＣＣＩ（ＣｏｎｇｅｓｔｉｏｎＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）フィールドを含むことができる。

ＴＳＩフィールドは、ＡＬＣ／ＬＣＴセッションを識別する情報を含む。例えば、セッション内のチャネルは、送信者ＩＰアドレス及びＵＤＰポートを用いて識別することができる。ＴＯＩフィールドは、それぞれのファイルオブジェクトを識別する情報を含む。ＣＣＩフィールドは、使用の有無及び混雑制御ブロックの情報を含む。また、ＬＣＴは、拡張ヘッダーで付加情報及びＦＥＣ関連情報を提供することができる。

以上のように、オブジェクト（例えば、ファイルなど）は、ＦＬＵＴＥプロトコルによってパケット化され、これはさらにＡＬＣ／ＬＣＴ方式によってパケット化される。該パケット化されたＡＬＣ／ＬＣＴデータはさらにＵＤＰ方式によってパケット化され、該パケット化されたＡＬＣ／ＬＣＴ／ＵＤＰデータはさらにＩＰ方式によってパケット化されてＡＬＣ／ＬＣＴ／ＵＤＰ／ＩＰデータとなる。

ファイルベースマルチメディアコンテンツは、ＬＣＴのようなコンテンツ伝送プロトコルによってインターネット網の他、放送網でも伝送が可能である。このとき、少なくとも一つのオブジェクト又はファイルで構成されるマルチメディアコンテンツは、ＬＣＴによって、オブジェクト単位又はファイル単位で伝送及び消費されてもよい。具体的に説明すると、下記のとおりである。

図２５の（ａ）を参照すると、ＦＬＵＴＥプロトコルを用いたデータ構造が示されている。例えば、マルチメディアコンテンツは、少なくとも一つのオブジェクトを含むことができる。一つのオブジェクトは、少なくとも一つのフラグメント（Ｆｒａｇｍｅｎｔ１及びＦｒａｇｍｅｎｔ２）を含むことができる。

図２５の（ｂ）を参照すると、ＦＬＵＴＥプロトコルを用いた場合のデータ処理時間が示されている。図２５の（ｂ）で、下端の図は、放送信号送信装置による、一つのオブジェクトに対するエンコーディング開始時間及びエンコーディング終了時間を示しており、中間の図は、放送信号送信装置による、一つのオブジェクトに対する伝送開始時間及び伝送終了時間を示しており、上端の図は、放送信号受信装置による、一つのオブジェクトに対する再生開始時間及び再生終了時間を示している。

放送信号送信装置は、少なくとも一つのフラグメントを含むオブジェクトの生成を終了した後にオブジェクトの伝送を始める。したがって、放送信号送信装置でオブジェクトを生成し始めた時点と伝送し始めた時点との間にＤ_t1だけの伝送待機時間が発生する。

また、放送信号受信装置は、少なくとも一つのフラグメントを含むオブジェクトの受信を終了した後にオブジェクトの再生を始める。したがって、放送信号受信装置でオブジェクトを受信し始めた時点と再生し始めた時点との間にＤ_r1だけの再生待機時間が発生する。

したがって、一つのオブジェクトが放送信号送信装置で伝送されて放送信号受信装置で再生されるまでは、伝送待機時間と再生待機時との和に該当する時間が必要である。これは、放送信号受信装置にとって該当のオブジェクトに初期接近するために非常に長い時間がかかるということを意味する。

以上のように、ＦＬＵＴＥプロトコルを用いる場合、放送信号送信装置はオブジェクト単位でデータを伝送し、このため、放送信号受信装置は一つのオブジェクトに対するデータを全て受信した後に当該オブジェクトを消費せざるを得ないという限界がある。したがって、ＦＬＵＴＥプロトコルを用いたオブジェクトの伝送は実時間放送環境には向いていない。

図２６は、本発明の一実施例に係るＲＯＵＴＥプロトコルスタックを示す図である。

ＩＰベースハイブリッド放送を支援する次世代放送システムの放送サービスは、ビデオデータ、オーディオデータ、字幕データ、シグナリングデータ、ＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）データ、及び／又はＮＲＴコンテンツデータを含むことができる。

ビデオデータ、オーディオデータ及び字幕データなどは、ＩＳＯベースメディアファイル（ＢａｓｅＭｅｄｉａＦｉｌｅ）（以下、ＩＳＯＢＭＦＦ）の形態でカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）することができる。例えば、ＩＳＯＢＭＦＦの形態でカプセル化されたデータは、ＭＰＥＧ（ＭｏｖｉｎｇＰｉｃｔｕｒｅＥｘｐｅｒｔＧｒｏｕｐ）−ＤＡＳＨ（（ＤｙｎａｍｉｃＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇｏｖｅｒＨＴＴＰ）のセグメント或いはＭＭＴ（ＭＰＥＧＭｅｄｉａＴｒａｎｓｐｏｒｔ）のＭＰＵ（Ｍｅｄｉａｐｒｏｃｅｓｓｉｎｇｕｎｉｔ）などの形態に従うことができる。そして、ＩＳＯＢＭＦＦの形態でカプセル化されたデータは、放送網とインターネット網で同一に又は各伝送網の属性によって別個に伝送することができる。

放送網の場合、シグナリングデータ、ＥＳＧデータ、ＮＲＴコンテンツデータ及び／又はＩＳＯＢＭＦＦの形態でカプセル化されたデータは、実時間オブジェクト伝送を支援するアプリケーション層伝送プロトコルパケットにカプセル化することができる。例えば、ＩＳＯＢＭＦＦの形態でカプセル化されたデータは、ＲＯＵＴＥ（Ｒｅａｌ−ＴｉｍｅＯｂｊｅｃｔＤｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ）及びＭＭＴの伝送パケットなどにカプセル化することができる。

ＲＯＵＴＥは、ＩＰマルチキャストネットワークでファイルを伝達するためのプロトコルである。ＲＯＵＴＥプロトコルは、ＡＬＣ（ＡｓｙｎｃｈｒｏｎｏｕｓＬａｙｅｒｅｄＣｏｄｉｎｇ）、大幅に拡張可能なマルチキャスト分配のために設計されたベースプロトコル、ＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）及び他の公知のインターネット標準を用いる。ＲＯＵＴＥは、追加の特徴を有するＦＬＵＴＥの向上及びそれに対する機能的代替物である。

ＲＯＵＴＥは、シグナリングメッセージ、ＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）メッセージ及びＮＲＴコンテンツを伝達する機能を果たす。これは、ストリーミングメディア、例えば、ＭＰＥＧ−ＤＡＳＨメディアセグメントファイルの伝達に特に適している。ＲＯＵＴＥは、ＦＬＵＴＥと比較してデリバリチェーンを介して、より低いエンド−ツウ−エンドレイテンシ（ｅｎｄ−ｔｏ−ｅｎｄｌａｔｅｎｃｙ）を提供する。

ＲＯＵＴＥプロトコルは、任意の種類のオブジェクトの伝達のために提供される一般的な伝送アプリケーションである。これは、場面記述（ｓｃｅｎｅｄｅｓｃｒｉｐｔｉｏｎ）、メディアオブジェクト及びＤＲＭ関連情報を含む豊富なプレゼンテーションを支援する。ＲＯＵＴＥは、特に実時間メディアコンテンツの伝達に適しており、多くの特徴を提供する。

例えば、ＲＯＵＴＥは、別個のメディアコンポーネント、例えば、言語トラック、サブタイトル、代案のビデオビューへの個別伝達及びアクセスを提供する。また、ＲＯＵＴＥは、別個の伝送セッション又は同一のＲＯＵＴＥセッションに対する伝達を可能にすることによって階層的コーディングの支援を提供する。また、ＲＯＵＴＥは、マルチステージを含む柔軟なＦＥＣ保護に対する支援を提供する。また、ＲＯＵＴＥは、ＤＡＳＨの放送及びブロードバンド伝達モード間のＭＰＥＧ−ＤＡＳＨ可能シナジーを有する容易な組合せを提供する。また、ＲＯＵＴＥは、ＲＯＵＴＥ及び／又は伝送セッションに参加するとき、メディアへの迅速なアクセスを提供する。ＲＯＵＴＥは、伝達概念に焦点を合わせることによって大きく拡張可能である。また、ＲＯＵＴＥは、既存のＩＥＴＦプロトコルとの互換性及びＩＥＦＴ−支援（ＩＥＴＦ−ｅｎｄｏｒｓｅｄ）拡張メカニズムの使用を提供する。

ＲＯＵＴＥプロトコルは２個の主要コンポーネントに分離される。第１コンポーネントは、オブジェクトの伝達又はオブジェクトのフロー／収集のためのソースプロトコルである。第２コンポーネントは、ソースプロトコルによって伝達されるデリバリオブジェクト又はデリバリオブジェクトの束（ｂｕｎｄｌｅ）を柔軟に保護するリペア（ｒｅｐａｉｒ）プロトコルである。

ソースプロトコルはリペアプロトコルに独立している。すなわち、ソースプロトコルは、ＲＯＵＴＥリペアプロトコル無しで配置（ｄｅｐｌｏｙ）することができる。リペアは、所定の配置（ｄｅｐｌｏｙｍｅｎｔ）シナリオに対してのみ、例えば、所定の地理的領域内のモバイル受信、所定のサービスなどのためにのみ追加されてもよい。

ソースプロトコルは、３ＧＰＰＴＳ２６．３４６で定義された拡張だけでなく、ＲＦＣ６７２６で定義されたＦＬＵＴＥに合わせて調整されるが、例えば、オブジェクトメタデータとオブジェクトコンテンツが合成（ｃｏｍｐｏｕｎｄ）オブジェクトで併せて伝送され得るＲＦＣ６９６８で定義されたＦＣＡＳＴの一部の原理を用いる。

基本ＦＬＵＴＥプロトコルに加えて、メディアデータ、それによるプロトコルの名の実時間伝達のための最適化された支援が可能な所定の最適化及び制限が追加される。特に、ソースＲＯＵＴＥプロトコルは、オブジェクトベースメディアデータの実時間伝達を提供する。また、ソースＲＯＵＴＥプロトコルは、デリバリオブジェクトの伝送認識パケット化（ｔｒａｎｓｐｏｒｔａｗａｒｅｐａｃｋｅｔｉｚａｔｉｏｎ）だけでなく、メディア認識パケット化のイネーブリング（ｅｎａｂｌｉｎｇ）を含めて柔軟なパケット化を提供する。また、ソースＲＯＵＴＥプロトコルは、ファイル及びデリバリオブジェクトの独立性を提供し、すなわち、デリバリオブジェクトは、ファイルの一部又はファイルのグループであってもよい。

デリバリオブジェクトは、受信機がデリバリオブジェクトを回復してアプリケーションに伝達するので、このプロトコルの重要なコンポーネントである。デリバリオブジェクトは、アプリケーションに対して独立しており（ｓｅｌｆ−ｃｏｎｔａｉｎｅｄ）、一般にアプリケーションに関連した所定の特性（ｐｒｏｐｅｒｔｉｅｓ）、メタデータ及びタイミング関連情報に関連付く。任意の場合、特性は、オブジェクトと共に帯域内で（ｉｎ−ｂａｎｄ）提供され、他の場合、データは、静的又は動的方式で帯域外で（ｏｕｔ−ｏｆ−ｂａｎｄ）伝達される必要がある。デリバリオブジェクトは“ＦＤＴインスタンス”によって記述され、同伴される完全又は部分ファイルを含むことができる。また、デリバリオブジェクトは、ＨＴＴＰエンティティ（ＨＴＴＰエンティティヘッダー及びＨＴＴＰエンティティボディー）及び／又はデリバリオブジェクトのパッケージを含むことができる。

デリバリオブジェクトは、ＦＤＴインスタンスと共に全体ファイル又はファイルのバイト範囲であってもよい。デリバリオブジェクトは、実時間又は非実時間（時間制限伝達又は非時間制限伝達）で伝達することができる。時間制限であれば、所定の実時間及びバッファ制限が適用され、特定拡張ヘッダーが用いられてもよい。動的及び静的メタデータは、デリバリオブジェクト特性を記述するために用いることができる。デリバリオブジェクトは、特定データ構造、特に、ＩＳＯＢＭＦＦ構造で伝達することができる。この場合、メディア認識パケット化又は一般的なパケット化が適用されてもよい。

デリバリフォーマットは、アプリケーションに情報を提供するためにどのフォーマットが用いられるかを特定する。

ＲＯＵＴＥリペアプロトコルはＦＥＣベースであり、伝送層（例えば、ＵＤＰ）及びオブジェクトデリバリ層プロトコル間の追加層として利用可能である。ＦＥＣは、ＲＦＣ６３６３に定義されたＦＥＣフレームワークの概念を再利用するが、ＲＦＣ６３６３のＦＥＣフレームワークとは違い、ＲＯＵＴＥリペアプロトコルはパケットを保護しなく、その代わりに、ソースプロトコルで伝達されたデリバリオブジェクトを保護する。各ＦＥＣソースブロックは、（ＦＬＵＴＥと類似の）単一デリバリオブジェクトのように又はＦＥＣ保護の前にバンドリングされた複数のデリバリオブジェクトによってデリバリオブジェクトの一部として構成されてもよい。ＲＯＵＴＥＦＥＣは、ＲＦＣ５０５２で定義されたものと類似の意味でＦＥＣスキームを利用し、その文書の用語を使う。ＦＥＣスキームは、ＦＥＣエンコーディング及びデコーディングを定義し、ＦＥＣスキームのコンテクストでパケットペイロードデータを識別するために用いられるプロトコルフィールド及び手順を定義する。

ＲＯＵＴＥで、全パケットは、ＲＦＣ５６５１で定義されたＬＣＴパケットである。ソース及びリペアパケットは、ＲＯＵＴＥセッション、ＬＣＴ伝送セッション及び／又はＰＳＩビットのうち少なくとも一つによって区別することができる。別個のＲＯＵＴＥセッションは別個のＩＰ／ＵＤＰポート組合せ上で送信される。別個のＬＣＴ伝送セッションは、ＬＣＴヘッダーで別個のＴＳＩ値を用いる。また、ソース及びリペアパケットが同一のＬＣＴ伝送セッションで伝送されると、ＬＣＴ内のＰＳＩビットによって区別可能である。動作のこのモードは、ＦＬＵＴＥ互換可能配置に最も適している。

ＲＯＵＴＥは、挙動（ｂｅｈａｖｉｏｒ）を伝送及び受信しながら、パケットフォーマットを含むソースプロトコルを定義する。また、ＲＯＵＴＥはリペアプロトコルを定義する。また、ＲＯＵＴＥは、伝送セッション確立のためのメタデータ及びオブジェクトフロー伝達のためのメタデータを定義する。また、ＲＯＵＴＥは、ＭＰＥＧＤＡＳＨ設定及びＲＯＵＴＥへのマッピングに対する推薦を定義し、豊富な高品質の線形ＴＶ放送サービスを可能にする。

ＲＯＵＴＥプロトコルの範囲は、ＬＣＴパケットを用いたデリバリオブジェクト及び関連したメタデータの信頼性ある伝達である。オブジェクトは、デリバリオブジェクトキャッシュ（ＤｅｌｉｖｅｒｙＯｂｊｅｃｔＣａｃｈｅ）を介してプリケーションに利用可能である。このキャッシュの具現は、アプリケーションとは独立している。

ＲＯＵＴＥプロトコルは、デリバリオブジェクトを伝達するＬＣＴパケットのフォーマット及びＦＥＣに基づいたリペアプロトコルを用いたデリバリオブジェクトの信頼性ある伝達に焦点を合わせる。また、ＲＯＵＴＥプロトコルは、デリバリオブジェクトと共にオブジェクトメタデータの定義及び伝達に焦点を合わせてデリバリオブジェクトキャッシュ及びアプリケーション間のインターフェースを可能にする。また、ＲＯＵＴＥプロトコルは、ＲＯＵＴＥ及びＬＣＴセッション記述に焦点を合わせて、そのメタデータと共にオブジェクトの受信を確立する。また、ＲＯＵＴＥプロトコルは、パケットと共に伝達される補助情報の規範的形態（ｎｏｒｍａｔｉｖｅａｓｐｅｃｔｓ）（フォーマット、セマンティクス）に焦点を合わせて、特定のアプリケーションに対する性能、例えば、実時間伝達を最適化する。

また、ＲＯＵＴＥプロトコルは、伝達に用いられる適切なＤＡＳＨフォーマットだけでなく、ＲＯＵＴＥ伝達への特定ＤＡＳＨメディアプレゼンテーションの推薦マッピングを提供する。重要な問題は、ＲＯＵＴＥを用いてＤＡＳＨメディアフォーマットがそのまま用いられうるということである。このアーキテクチャ設計は、集中した（ｃｏｎｖｅｒｇｅｄ）ユニキャスト／ブロードキャストサービスを可能にする。

ＲＯＵＴＥプロトコルの伝送者動作において、ＬＣＴパケットを伝達するＲＯＵＴＥセッションが確立される。これらのパケットは、ソースオブジェクト又はＦＥＣリペアデータを伝送することができる。ソースプロトコルは、一つ以上のＬＣＴセッションで構成され、ＬＣＴセッションのそれぞれは、自身のメタデータと共に、関連したオブジェクトを伝達する。メタデータは、エンティティモード内の合成オブジェクトとして又はパケットヘッダー内のＬＣＴ拡張ヘッダーとして、ＬＳＩＤ（ＬＣＴＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ）で静的又は動的に伝達されてもよい。パケットは、任意のバイト境界でオブジェクトの柔軟なフラグメンテーションを許容する特定ＦＥＣスキームを用いてＡＬＣで伝達される。また、デリバリオブジェクトは、個別的に又はバンドリングされてＦＥＣ保護されてもよい。いずれの場合にも、バンドリングされたオブジェクトはエンコードされ、リペアパケットだけが伝達される。ソースパケットと結合し、これは回復デリバリオブジェクトバンドルを許容する。例えば、それぞれ別個の特性を有する１つ又は複数のリペアフローが生成され、別個のレイテンシ要求事項、別個の保護要求事項などを支援することができる。

ＤＭＤ（ＤｙｎａｍｉｃＭｅｔａＤａｔａ）は、クライアントで動的にＦＤＴ同等記述（ｅｑｕｉｖａｌｅｎｔｄｅｓｃｒｉｐｔｉｏｎ）を生成するメタデータである。これは、エンティティモードではエンティティヘッダーで伝送され、他の伝達モードではＬＣＴヘッダーで送信される。

ＲＯＵＴＥプロトコルは、ソースデータの別個の保護及び伝達スキームを支援する。これはまた、逆互換性モードで配置されてもよいため、ＮＲＴ伝達のための既存のいずれの使用の場合をも支援する。

ＲＯＵＴＥセッションは、ＩＰアドレス／ポート組合せに関連付く。一般に、このようなセッションを参加させることによって、セッションの全パケットを受信することができ、アプリケーションプロトコルを追加のプロセシングに適用することができる。それぞれのＲＯＵＴＥセッションは、１つ又は複数のＬＣＴ伝送セッションで構成される。ＬＣＴ伝送セッションは、ＲＯＵＴＥセッションのサブセットである。メディア伝達のために、ＬＣＴ伝送セッションは一般に、メディアコンポーネント、例えば、ＤＡＳＨリプレゼンテーションを伝送する。ブロードキャストＤＡＳＨの観点で、ＲＯＵＴＥセッションは、一つ以上のＤＡＳＨメディアプレゼンテーションの構成メディアコンポーネントを伝達するＬＣＴ伝送セッションのマルチプレクスとして見なされてもよい。各ＬＣＴ伝送セッション内で、１つ又は複数のオブジェクト、一般に、関連したオブジェクト、例えば、一つのプレゼンテーションと関連したＤＡＳＨセグメントが送信される。それぞれのオブジェクトと共に、メタデータ特性は、オブジェクトがアプリケーションに用いられ得るように伝達される。アプリケーションは、制限されないが、ＤＡＳＨメディアプレゼンテーション、ＨＴＭＬ−５プレゼンテーション又は任意の他のオブジェクト消費（ｏｂｊｅｃｔ−ｃｏｎｓｕｍｉｎｇ）アプリケーションを含む。

ＲＯＵＴＥセッションは、時間的に制限されてもよく、制限されなくてもよい。ＲＯＵＴＥセッションは、１つ又は複数のＬＣＴ伝送セッションを含む。それぞれの伝送セッションは、ＬＣＴヘッダー内の固有ＴＳＩ（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ）値によって固有に識別される。

受信機がＲＯＵＴＥセッションに参加する前に、受信機はＲＯＵＴＥセッション記述（ｄｅｓｃｒｉｐｔｉｏｎ）を得る必要がある。ＲＯＵＴＥセッション記述は、伝送者ＩＰアドレス、セッションに用いられるアドレス及びポート番号、セッションがＲＯＵＴＥセッションであり、全パケットがＬＣＴパケットであるという指示、及び／又はＩＰ／ＵＤＰレベルでセッションに参加して消費する上で必須である他の情報のうち少なくとも一つを含む。

セッション記述はまた、制限的ではないが、ＲＯＵＴＥセッションに用いられるデータレート及びＲＯＵＴＥセッションのデューレーション（ｄｕｒａｔｉｏｎ）に関する任意の情報を含むことができる。

セッション記述は、ＲＦＣ４５６６に定義されたＳＤＰ（ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ）又はＲＦＣ３０２３に定義されたＸＭＬメタデータなどの形態であってもよい。これは、登録セッション制御プロトコル（ｐｒｏｐｒｉｅｔａｒｙｓｅｓｓｉｏｎｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ）を用いて任意のセッション発表プロトコル（ｓｅｓｓｉｏｎａｎｎｏｕｎｃｅｍｅｎｔｐｒｏｔｏｃｏｌ）で伝送されてもよく、スケジューリング情報と共にウェブページ上に位置してもよく、イーメール又は帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）方法によって伝達されてもよい。

伝送セッションは、ＲＯＵＴＥセッション記述に記述されず、ＬＳＩＤ（ＬＣＴＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ）に記述される。伝送セッション（すなわち、ＬＣＴセッション又は簡単にＬＣＴセッション）は、ソースフロー及びリペアフローのいずれか一方又は両方を含むことができる。ソースフローはソースデータを伝送する。また、リペアフローはリペアデータを伝送する。

ＲＯＵＴＥセッションに含まれるＬＣＴ伝送セッションは、ＬＳＩＤによって記述される。特に、ＲＯＵＴＥセッションの各構成ＬＣＴ伝送セッションで伝送されると定義する。それぞれの伝送セッションは、ＬＣＴヘッダー内のＴＳＩによって固有に識別される。

ＬＳＩＤは、このＲＯＵＴＥセッション上で伝送される全ての伝送セッションを記述する。ＬＳＩＤは、ＬＣＴ伝送セッションを含む同じＲＯＵＴＥセッションで伝達されてもよく、ＲＯＵＴＥセッション以外の手段によって、例えば、ユニキャスト又は別個のＲＯＵＴＥセッションで伝達されてもよい。前者の場合、ＬＳＩＤは、ＴＳＩ＝０を有する専用ＬＣＴ伝送セッション上で伝達され、また、ＴＯＩ＝０によって識別されたデリバリオブジェクトであろう。ＴＳＩ＝０上で伝達される任意のオブジェクトに対して、エンティティモードを使用しなければならない。それらのオブジェクトがエンティティモードで伝達されないと、ＬＳＩＤは、受信されたオブジェクトに対する拡張されたＦＤＴを得る前に回復されなければならない。

ＬＳＩＤのインターネットメディアタイプは、ａｐｐｌｉｃａｔｉｏｎ／ｘｍｌ＋ｒｏｕｔｅ＋ｌｓｉｄである。

ＬＳＩＤは、他のデータフラグメントを参照することができる。ＬＳＩＤで参照される任意のオブジェクトはまた、ＴＳＩ＝０上でＬＳＤＩ自体よりはＴＯＩのそれぞれ異なる値をもって伝達されてもよく、専用ＴＳＩ≠０を有する別途のＬＣＴセッション上で伝達されてもよい。

ＬＳＩＤエレメントは、バージョン属性、有効性属性及び／又は満了属性を含むことができる。したがって、ＬＳＩＤエレメントを有効性属性及び満了属性の他、バージョン属性も用いてアップデートすることができる。例えば、所定の伝送セッションは、任意の時間後に終了すればよく、新しいセッションを開始することができる。

バージョン属性は、このＬＳＩＤエレメントのバージョンを示す。バージョンは、記述語がアップデートされる都度、１ずつ増加する。最も高いバージョン番号を有する受信されたＬＳＩＤエレメントが、現在有効なバージョンである。

有効性属性は、ＬＳＩＤエレメントが有効である日付及び／又は時間を示す。有効性属性は存在してもよく、存在しなくてもよい。存在しないと、受信機は、ＬＳＩＤエレメントバージョンが直ちに有効であると仮定しなければならない。

満了属性は、ＬＳＩＤエレメントが満了する日付及び時間を示す。満了属性は存在してもしなくてもよい。存在しないと、受信機は、ＬＳＩＤエレメントが全時間において又は関連した満了値を有する、より新しいＬＳＩＤエレメントが受信されるまで有効であると仮定しなければならない。

ＬＳＩＤエレメントは、少なくとも一つのＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎエレメントを含むことができる。ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎエレメントは、ＬＣＴ伝送セッションに関する情報を提供する。それぞれのＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎエレメントは、ｔｓｉ属性、ＳｏｕｒｃｅＦｌｏｗエレメント及び／又はＲｅｐａｉｒＦｌｏｗエレメントを含むことができる。

ｔｓｉ属性は、伝送セッション識別子を特定する。セッション識別子は０であってはならない。ＳｏｕｒｃｅＦｌｏｗエレメントは、伝送セッション上で伝達されるソースフローの情報を提供する。ＲｅｐａｉｒＦｌｏｗエレメントは、伝送セッション上で伝送されるリペアフローの情報を提供する。

その後、アプリケーション層伝送プロトコルパケットにカプセル化されたデータは、ＩＰ／ＵＤＰ方式によってパケット化されてもよい。ＩＰ／ＵＤＰ方式によってパケット化されたデータはＩＰ／ＵＤＰデータグラムといえるできるが、ＩＰ／ＵＤＰデータグラムは放送信号に含まれて伝送されてもよい。

インターネット網の場合、ＩＳＯＢＭＦＦの形態でカプセル化されたデータは、ストリーミング技法に基づいて受信側に伝達されてもよい。例えば、ストリーミング技法は、ＭＰＥＧ−ＤＡＳＨを含むことができる。

シグナリングデータは、下記のような方法で伝送することができる。

放送網の場合、シグナリングデータは、シグナリングの属性にしたがって、次世代放送伝送システム及び放送網の物理層に伝達される伝送フレーム（又はフレーム）の特定データパイプ（以下ＤＰ）などで伝送することができる。例えば、シグナリング形態は、ビットストリーム又はＩＰ／ＵＤＰデータグラムにカプセル化された形態であってもよい。

インターネット網の場合、シグナリングデータは、受信機の要求に対する応答としてリターンして伝達されてもよい。

ＥＳＧデータ及びＮＲＴコンテンツデータは、下記のような方法で伝送することができる。

放送網の場合、ＥＳＧデータ及びＮＲＴコンテンツデータは、アプリケーション層伝送プロトコルパケットにカプセル化することができる。その後、アプリケーション層伝送プロトコルパケットにカプセル化されたデータを、上述した方式と同様に伝送することができる。

インターネット網の場合、ＥＳＧデータ及びＮＲＴコンテンツデータは、受信機の要求に対する応答としてリターンして伝達されてもよい。

本発明の一実施例に係る放送信号送信装置の物理層（ブロードキャストＰＨＹ及びブロードバンドＰＨＹ）は、前述した図１に示す構造であってもよい。また、放送信号受信装置の物理層は、図９に示す構造であってもよい。

シグナリングデータ及びＩＰ／ＵＤＰデータグラムは、物理層に伝達される伝送層（又はフレーム）の特定データパイプ（以下ＤＰ）で伝送することができる。例えば、入力フォーマットブロック１０００は、シグナリングデータ及びＩＰ／ＵＤＰデータグラムを受信し、それぞれのシグナリングデータ及びＩＰ／ＵＤＰデータグラムを少なくとも一つのＤＰに逆多重化することができる。出力プロセッサ９３００は、入力フォーマットブロック１０００と逆の動作を行うことができる。

以下では、上述したＩＳＯＢＭＦＦの形態でカプセル化されたデータがＲＯＵＴＥの伝送パケットにカプセル化された場合を中心に説明する。

＜実時間ファイル生成、消費のためのデータ構成＞
図２７は、本発明の一実施例に係るファイルベースマルチメディアコンテンツのデータ構造を示す図である。

図２７を参照すると、本発明の一実施例に係るファイルベースマルチメディアコンテンツのデータ構造が示されている。ファイルベースマルチメディアコンテンツとは、少なくとも一つのファイルで構成されているマルチメディアコンテンツを意味する。

放送プログラムのようなマルチメディアコンテンツは、一つのプレゼンテーション（ｐｒｅｓｅｎｔａｔｉｏｎ）で構成することができる。プレゼンテーションは、少なくとも一つのオブジェクト（ｏｂｊｅｃｔ）を含むことができる。例えば、オブジェクトはファイルであってもよい。また、オブジェクトは、少なくとも一つのフラグメント（ｆｒａｇｍｅｎｔ）を含むことができる。

本発明の一実施例に係るフラグメントとは、以前（ｐｒｅｃｅｄｉｎｇ）のデータに対する依存性無しで独立して復号化及び再生され得るデータ単位を意味する。例えば、ビデオデータを含むフラグメントは、ＩＤＲＰｉｃｔｕｒｅで開始し、メディアデータのパーシング（ｐａｒｓｉｎｇ）のためのヘッダー（ｈｅａｄｅｒ）データも以前（ｐｒｅｃｅｄｉｎｇ）のフラグメントに対して依存性を有しない。本発明の一実施例に係るフラグメントは、少なくとも一つの伝送ブロック単位で分割して伝送することができる。

本発明の一実施例に係る伝送ブロックは、以前（ｐｒｅｃｅｄｉｎｇ）のデータに対する依存性無しで独立して符号化及び伝送され得る最小のデータ単位を意味する。また、伝送ブロックは、可変サイズのＧＯＰ単位又はチャンク単位からなる有意なデータ単位であってもよい。例えば、伝送ブロックは、ビデオデータのＧＯＰのように、同一のメディアデータで構成される少なくとも一つのチャンク（ｃｈｕｎｋ）を含むことができる。チャンクとは、コンテンツのセグメントを意味することができる。また、伝送ブロックは、少なくとも一つのソースブロックを含むことができる。

ＧＯＰは、ビデオコーディングで用いられるコーディングを行う基本単位であり、少なくとも一つのＩ−フレームを含むフレームの集合を示す可変サイズのデータ単位である。本発明の一実施例によれば、メディアデータを独立して有意なデータ単位であるオブジェクト内部構造体の単位で伝送するので、ＧＯＰはオープンＧＯＰ及びクローズドＧＯＰを含むことができる。

オープンＧＯＰで、一つのＧＯＰ内にあるＢ−フレームは、隣接したＧＯＰのＩ−フレーム又はＰ−フレームを参照することができる。したがって、オープンＧＯＰは、コーディング効率を非常に高めることができる。クローズドＧＯＰで、Ｂ−フレーム又はＰ−フレームは、当該ＧＯＰ内にあるフレームだけを参照し、該当ＧＯＰ外にあるフレームは参照しない。

伝送ブロックは、少なくとも一つのデータを含むことができ、それぞれのデータは同一又は別個のメディアタイプを有することができる。例えば、メディアタイプはオーディオタイプ及びビデオタイプを含むことができる。すなわち、伝送ブロックは、オーディオ及びビデオの場合のようにそれぞれ異なるメディアタイプを有する少なくとも一つのデータを共に含むことができる。

本発明の一実施例に係るフラグメントは、フラグメントヘッダー及びフラグメントペイロードを含むことができる。

フラグメントヘッダー（ｈｅａｄｅｒ）は、上述したチャンクをパースするためのタイミング（ｔｉｍｉｎｇ）情報及びインデクシング（ｉｎｄｅｘｉｎｇ）情報などを含むことができる。そして、フラグメントヘッダーは少なくとも一つの伝送ブロックで構成されてもよい。例えば、フラグメントヘッダーは、一つの伝送ブロックに含まれてもよい。また、フラグメントペイロードを構成する少なくとも一つのチャンクデータも少なくとも一つの伝送ブロックにそれぞれ含まれてもよい。上述したように、フラグメントヘッダー及びフラグメントペイロードは少なくとも一つの伝送ブロックにそれぞれ含まれてもよい。

本発明の一実施例に係る伝送ブロックは、少なくとも一つのシンボル（ｓｙｍｂｏｌ）に分割することができる。少なくとも一つのシンボルはパケット化されてもよい。例えば、本発明の一実施例に係る放送信号送信装置は、少なくとも一つのシンボルをＬＣＴパケットにパケット化することができる。

本発明の一実施例に係る放送信号送信装置は、パケット化されたデータを放送信号受信装置に伝送することができる。

図２８は、本発明の一実施例に係るデータ構造を適用したＭＰＥＧ−ＤＡＳＨのメディアセグメント構成を示す図である。

図２８を参照すると、本発明の一実施例に係るデータ構造をＭＰＥＧ−ＤＡＳＨのメディアセグメント（ＭｅｄｉａＳｅｇｍｅｎｔ）に適用した実施例が示されている。

本発明の一実施例に係る放送信号送信装置は、サーバーに複数の品質を有しているマルチメディアコンテンツを保有し、ユーザの放送環境及び放送信号受信装置の環境に適したマルチメディアコンテンツを提供することによって、シームレスな実時間ストリーミングサービスを提供することができる。例えば、放送信号送信装置は、ＭＰＥＧ−ＤＡＳＨを用いて実時間ストリーミングサービスを提供することができる。

放送信号送信装置は、ＸＭＬ形態のＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）及び二進化フォーマット形態の伝送用マルチメディアコンテンツであるセグメント（Ｓｅｇｍｅｎｔ）を、ＲＯＵＴＥプロトコルを用いて放送信号受信装置に放送環境及び放送信号受信装置の環境に応じて動的に伝送することができる。

ＭＰＤは階層的な構造となっており、各階層別の構造的機能及び役割などに関する情報を含むことができる。

セグメントはメディアセグメントを含むことができる。メディアセグメントは、ストリーミングサービスを支援するために放送信号受信装置に伝送しようとする品質別、時間別に分離したメディア関連オブジェクト形態のデータ単位を意味する。メディアセグメントは、メディアストリームの情報、少なくとも一つのアクセスユニット、プレゼンテーション時間又はインデックスのような当該セグメント内のメディアプレゼンテーションへの接近方法に関する情報を含むことができる。また、メディアセグメントは、セグメントインデックスによって少なくとも一つのサブセグメントに分割されてもよい。

ＭＰＥＧ−ＤＡＳＨコンテンツは、少なくとも一つのメディアセグメントを含むことができる。メディアセグメントは、少なくとも一つのフラグメントを含むことができる。例えば、フラグメントは、上述したサブセグメントであってもよい。上述したように、フラグメントは、フラグメントヘッダー及びフラグメントペイロードを含むことができる。

フラグメントヘッダーは、セグメントインデックスボックス（ｓｉｄｘ）及びムービーフラグメントボックス（ｍｏｏｆ）を含むことができる。セグメントインデックスボックスは、当該フラグメントの内部に存在するメディアデータの最初のプレゼンテーション時間、データオフセット（ｏｆｆｓｅｔ）及びＳＡＰ（ＳｔｒｅａｍＡｃｃｅｓｓＰｏｉｎｔｓ）情報などを提供することができる。ムービーフラグメントボックスは、メディアデータボックス（ｍｄａｔ）に対するメタデータを含むことができる。例えば、ムービーフラグメントボックスは、フラグメント内メディアデータサンプル（ｓａｍｐｌｅ）のタイミング、インデクシング、デコーディング（ｄｅｃｏｄｉｎｇ）情報などを含むことができる。

フラグメントペイロードは、メディアデータボックス（ｍｄａｔ）を含むことができる。メディアデータボックス（ｍｄａｔ）は、当該メディア構成要素（ビデオ及びオーディオなど）に対する実際メディアデータを含むことができる。

符号化されたメディアデータは、フラグメントペイロードに該当するメディアデータボックス（ｍｄａｔ）内にチャンク単位で含まれる。上述したように、同一トラック（ｔｒａｃｋ）に該当するサンプルは、一つのチャンク内に含まれてもよい。

放送信号送信装置は、フラグメントを分割して少なくとも一つの伝送ブロックを生成することができる。また、放送信号送信装置は、フラグメントヘッダーとペイロードデータとを区分するために、フラグメントヘッダーとペイロードデータを別個の伝送ブロックに含めることができる。

また、放送信号送信装置は、フラグメントペイロード内のデータを分割して伝送するためにチャンク単位で区画された伝送ブロックを生成することができる。すなわち、本発明の一実施例に係る放送信号送信装置は、チャンクの境界と伝送ブロックの境界地点とが一致するように伝送ブロックを生成することができる。

その後、放送信号送信装置は、少なくとも一つの伝送ブロックを分割して少なくとも一つのシンボルを生成することができる。オブジェクト内の全シンボルの長さは同一であってもよい。また、オブジェクト内の全シンボルの長さを同一にするために、伝送ブロックの最後のシンボルはパディング（ｐａｄｄｉｎｇ）バイトを含んでもよい。

その後、放送信号送信装置は、少なくとも一つのシンボルをパケット化することができる。例えば、放送信号送信装置は、少なくとも一つのシンボルに基づいてＬＣＴパケットを生成することができる。

その後、放送信号送信装置は、生成されたＬＣＴパケットを伝送することができる。

本発明の一実施例に係る放送信号送信装置は、フラグメントを生成するために、まずフラグメントペイロードを生成した後に、フラグメントヘッダーを生成する。このとき、放送信号送信装置は、フラグメントペイロード内のメディアデータに該当する伝送ブロックを生成することができる。例えば、メディアデータボックス（ｍｄａｔ）に含まれたメディアデータに該当する少なくとも一つの伝送ブロックは、チャンク単位で順次に生成することができる。その後、放送信号送信装置は、フラグメントヘッダーに該当する伝送ブロックを生成することができる。

放送信号送信装置は、メディアコンテンツを実時間放送で伝送するために、生成された伝送ブロックを生成順で伝送することができる。逆に、本発明の一実施例に係る放送信号受信装置は、フラグメントヘッダーをまずパースした後に、フラグメントペイロードをパースする。

放送信号送信装置は、メディアデータがあらかじめエンコードされたり、又は伝送ブロックがあらかじめ生成された場合には、パーシング順で伝送することができる。

図２９は、本発明の一実施例に係るＲＯＵＴＥプロトコルを用いたデータ処理時間を示す図である。

図２９の（ａ）を参照すると、本発明の一実施例に係るデータ構造が示されている。マルチメディアデータは、少なくとも一つのオブジェクトを含むことができる。それぞれのオブジェクトは、少なくとも一つのフラグメントを含むことができる。例えば、一つのオブジェクトは、２個のフラグメント（Ｆｒａｇｍｅｎｔ１及びＦｒａｇｍｅｎｔ２）を含むことができる。

放送信号送信装置はフラグメントを少なくとも一つの伝送ブロックに分割することができる。伝送ブロックはソースブロックであってもよく、以下ではソースブロックを基準に説明する。

例えば、放送信号送信装置は、フラグメント１を３個のソースブロック（ＳｏｕｒｃｅＢｌｏｃｋ０，ＳｏｕｒｃｅＢｌｏｃｋ１，ＳｏｕｒｃｅＢｌｏｃｋ２）に分割し、フラグメント２を３個のソースブロック（ＳｏｕｒｃｅＢｌｏｃｋ３，ＳｏｕｒｃｅＢｌｏｃｋ４，ＳｏｕｒｃｅＢｌｏｃｋ５）に分割することができる。

放送信号送信装置は、分割されたそれぞれのソースブロックを個別的に伝送することができる。放送信号送信装置は、それぞれのソースブロックが生成された時点又はその直後に生成されたそれぞれのソースブロックの伝送を開始することができる。

例えば、放送信号送信装置は、ソースブロック０（Ｓ₀）をｔ_e0〜ｔ_e1時間で生成した後に、ソースブロック０（Ｓ₀）を伝送することができる。ソースブロック０（Ｓ₀）の伝送開始時点（ｔ_d0）は、ソースブロック０（Ｓ₀）の生成完了時点（ｔ_d0）と同一又は直後であってもよい。同一の方法で、放送信号送信装置はソースブロック１（Ｓ₁）乃至ソースブロック５（Ｓ₅）を生成し、生成されたそれぞれのソースブロックを伝送することができる。

したがって、本発明の一実施例に係る放送信号送信装置では、一つのソースブロックを生成し始めた時点と伝送し始めた時点との間にＤ_t2だけの伝送待機時間が発生し得る。本発明の一実施例に係る放送信号送信装置で発生する伝送待機時間（Ｄ_t2）は、従来の放送信号送信装置で発生する伝送待機時間（Ｄ_t1）に比べてだいぶ減少したものである。したがって、本発明の一実施例に係る放送信号送信装置は、従来の放送信号送信装置に比べて伝送待機時間を減らすことができるという効果がある。

本発明の一実施例に係る放送信号受信装置は、分割されたそれぞれのソースブロックを受信し、受信したソースブロックを組み合わせて少なくとも一つのフラグメントを生成することができる。例えば、放送信号受信装置は、ソースブロック０（Ｓ₀）、ソースブロック１（Ｓ₁）、及びソースブロック２（Ｓ₂）を受信し、受信した３個のソースブロックを組み合わせてフラグメント１を生成することができる。また、放送信号受信装置は、ソースブロック３（Ｓ₃）、ソースブロック４（Ｓ₄）、及びソースブロック５（Ｓ₅）を受信し、受信した３個のソースブロックを組み合わせてフラグメント２を生成することができる。

本発明の一実施例に係る放送信号受信装置は、生成されたそれぞれのフラグメントを個別的に再生することができる。放送信号受信装置は、それぞれのフラグメントが生成された時点又は直後に生成されたそれぞれのフラグメントを再生することができる。又は、放送信号受信装置は、それぞれのフラグメントに該当するソースブロックが全て送信された時点又は直後にそれぞれのフラグメントを再生することができる。

例えば、放送信号受信装置は、ソースブロック０（Ｓ₀）乃至ソースブロック２（Ｓ₂）をｔ_d0〜ｔ_d3時間で受信した後に、フラグメント１を生成することができる。その後、放送信号受信装置は、生成されたフラグメント１を再生することができる。フラグメント１の再生開始時点（ｔ_p0）は、フラグメント１の生成時点と同一又は直後であってもよい。また、フラグメント１の再生開始時点（ｔ_p0）は、ソースブロック２（Ｓ₂）の受信完了時点（ｔ_d3）と同一又は直後であってもよい。

同一の方法で、本発明の一実施例に係る放送信号受信装置は、ソースブロック３（Ｓ₃）乃至ソースブロック５（Ｓ₅）をｔ_d3〜ｔ_d6時間で受信した後に、フラグメント２を生成することができる。その後、放送信号受信装置は、生成されたフラグメント２を再生することができる。

ただし、これに限定されず、本発明の一実施例に係る放送信号受信装置は、ソースブロックを受信し、受信されたソースブロック単位で再生してもよい。

したがって、本発明の一実施例に係る放送信号受信装置では、一つのフラグメントを受信し始めた時点と再生し始めた時点との間にＤ_r2だけの再生待機時間が発生しうる。本発明の一実施例に係る放送信号受信装置で発生する再生待機時間（Ｄ_r2）は、従来の放送信号受信装置で発生する再生待機時間（Ｄ_r1）に比べてだいぶ減少したものである。したがって、本発明の一実施例に係る放送信号受信装置は、従来の放送信号受信装置に比べて再生待機時間を減らすことができるという効果がある。

以上のように、一つの伝送ブロックが放送信号送信装置から伝送されて放送信号受信装置で再生されるまでの時間である伝送待機時間と再生待機時との和をだいぶ減らすことができる。これは、放送信号受信装置にとって該当のオブジェクトへの初期接近時間がだいぶ短縮するということを意味する。

ＲＯＵＴＥプロトコルを用いる場合、放送信号送信装置は、伝送ブロック単位でデータを伝送することができ、放送信号受信装置は、受信されたデータを伝送ブロック単位又はフラグメント単位で再生することができる。その結果、マルチメディアコンテンツの取得からユーザに表示するまでの総時間を短縮することができ、ユーザが放送チャネルに接近した時の初期接近時間を減らすことができる。

したがって、ＲＯＵＴＥプロトコルを用いた伝送ブロックの伝送は、実時間放送環境に適している。

＜ファイル分割生成、消費情報の識別方案＞
図３０は、本発明の一実施例に係るファイルを伝送するためのＬＣＴパケットの構造を示す図である。

アプリケーション層伝送セッションは、ＩＰアドレス及びポート番号の組合せで構成することができる。アプリケーション層伝送セッションがＲＯＵＴＥプロトコルである場合、ＲＯＵＴＥセッションは少なくとも一つのＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）セッションで構成されてもよい。例えば、一つのＬＣＴ伝送セッションで一つのメディアコンポーネントを伝達する場合、一つのアプリケーション層伝送セッションで少なくとも一つのメディアコンポーネントをマルチプレクスして伝送することができる。また、一つのＬＣＴ伝送セッションで少なくとも一つの伝送オブジェクト（Ｔｒａｎｓｐｏｒｔｏｂｊｅｃｔ）を伝達することができる。

図３０を参照すると、アプリケーション層伝送プロトコルがＬＣＴに基づく場合、ＬＣＴパケットの各フィールドは次のような情報を示す。

ＬＣＴパケットは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、予約フィールド（Ｒ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、伝送者現在時間存在フラグフィールド（Ｔ）、予想レジデュアル時間存在フラグ（Ｒ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー延長フィールド、ＦＥＣペイロードＩＤフィールド、及び／又はシンボルエンコーディングフィールドを含むことができる。

ＬＣＴバージョン番号フィールド（Ｖ）は、プロトコルバージョン番号を示す。例えば、このフィールドは、ＬＣＴバージョン番号を示す。ＬＣＴヘッダーのバージョン番号フィールドは、ＲＯＵＴＥバージョン番号フィールドとして解釈しなければならない。ＲＯＵＴＥのこのバージョンは暗示的に、ＬＣＴ形成ブロックのバージョン“１”を用いる。例えば、バージョン番号は‘０００１ｂ’である。

混雑制御フラグフィールド（Ｃ）は、混雑制御情報フィールドの長さを示す。Ｃ＝０は、混雑制御情報（ＣＣＩ）フィールドが３２ビットの長さを有することを示し、Ｃ＝１は、ＣＣＩフィールドが６４ビットの長さを有することを示し、Ｃ＝２は、ＣＣＩフィールドが９６ビットの長さを有することを示し、Ｃ＝３は、ＣＣＩフィールドが１２８ビットの長さを有することを示す。

予約フィールド（Ｒ）は、将来の使用のために予約される。例えば、予約フィールド（Ｒ）は、ＰＳＩ（Ｐｒｏｔｏｃｏｌ−ＳｐｅｃｉｆｉｃＩｎｄｉｃａｔｉｏｎ）フィールドであってもよい。ＰＳＩは、ＬＣＴ上位プロトコルで特定目的の指示子として用いられてもよい。ＰＳＩフィールドは、現在のパケットがソースパケットか又はＦＥＣリペアパケットかを示す。ＲＯＵＴＥソースプロトコルが単にソースパケットを伝達することから、このフィールドは“１０ｂ”に設定されるはずである。

伝送セッション識別子フラグフィールド（Ｓ）は、伝送セッション識別子フィールドの長さを示す。

伝送オブジェクト識別子フラグフィールド（Ｏ）は、伝送オブジェクト識別子フィールドの長さを示す。例えば、オブジェクトは一つのファイルを意味することができ、上記のＴＯＩは各オブジェクトの識別情報であり、ＴＯＩが０であるファイルは、ＦＤＴという。

ハーフワードフラグフィールド（Ｈ）は、ＴＳＩ及びＴＯＩフィールドの長さにハーフワード（ｈａｌｆ−ｗｏｒｄ）（１６ビット）を追加するか否かを示す。

伝送者現在時間存在フィールド（Ｔ）は、伝送者現在時間（ＳＣＴ）フィールドが存在するか否かを示す。Ｔ＝０は、伝送者現在時間（ＳＣＴ）フィールドが存在しないことを示す。Ｔ＝１は、ＳＣＴフィールドが存在することを示す。ＳＣＴは、セッションがどれくらい長く進行されたかを受信機に示すように伝送者によって挿入される。

予想レジデュアル時間存在フラグフィールド（Ｒ）は、予想レジデュアル時間（ＥＲＴ）フィールドが存在するか否かを示す。Ｒ＝０は、予想レジデュアル時間（ＥＲＴ）フィールドが存在しないことを示す。Ｒ＝１は、ＥＲＴフィールドが存在することを示す。ＥＲＴは、セッション／オブジェクト送信がどれくらい長く続くかを受信機に示すように送信者によって挿入される。

クローズセッションフラグフィールド（Ａ）は、セッションが終了したこと又は終了が差し迫っていることを示す。

クローズオブジェクトフラグフィールド（Ｂ）は、伝送中であるオブジェクトが終了したこと又は終了が差し迫っていることを示す。

ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）は、３２ビットワードの単位のＬＣＴヘッダーの全長を示す。

コードポイントフィールド（ＣＰ）は、このパケットによって送信されたペイロードのタイプを示す。ペイロードのタイプによって、追加のペイロードヘッダーが追加され、ペイロードデータをプレフィックス（ｐｒｅｆｉｘ）することができる。

混雑制御情報フィールド（ＣＣＩ）は、層数、論理チャネル数、シーケンス数などの混雑制御情報の伝送に用いられる。ＬＣＴヘッダー内の混雑制御情報フィールドは、要求される混雑制御情報を含む。

伝送セッション識別子フィールド（ＴＳＩ）は、セッションの固有識別子である。ＴＳＩは、特定伝送者からの全セッションの中からセッションを固有に識別する。このフィールドは、ＲＯＵＴＥ内の伝送セッションを識別する。伝送セッションのコンテクストはＬＳＩＤ（ＬＣＴＳｅｓｓｉｏｎＩｎｓｔａｎｃｅｄｅｓｃｒｉｐｔｉｏｎ）によって提供される。

ＬＳＩＤは、ＲＯＵＴＥセッションの各構成ＬＣＴ伝送セッションで伝送されるものを定義する。それぞれの伝送セッションは、ＬＣＴヘッダー内のＴＳＩ（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ）によって固有に識別される。ＬＳＩは、ＬＣＴ伝送セッションを含む同じＲＯＵＴＥセッションで伝送されてもよく、通信網、放送網、インターネット網、ケーブル網、及び／又は衛星網でも伝送されてもよい。ＬＳＩＤが伝送される手段は、これに限定されない。例えば、ＬＳＩＤは、ＴＳＩの値が‘０’である特定ＬＣＴ伝送セッションで伝送されてもよい。ＬＳＩＤは、ＲＯＵＴＥセッションに伝送される全伝送セッションに対するシグナリング情報を含むことができる。ＬＳＩＤは、ＬＳＩＤバージョン情報及びＬＳＩＤの有効性に関する情報を含むことができる。また、ＬＳＩＤは、ＬＣＴ伝送セッションに関する情報を提供する伝送セッション（ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ）情報を含むことができる。伝送セッション情報は、伝送セッションを識別するＴＳＩ情報、当該ＴＳＩで伝送され、ソースデータが伝送されるソースフローに関する情報を提供するソースフロー（ｓｏｕｒｃｅｆｌｏｗ）情報、当該ＴＳＩで伝送され、リペアデータが伝送されるリペアフローに関する情報を提供するリペアフロー（ｒｅｐａｉｒｆｌｏｗ）情報、及び当該伝送セッションに関する追加の特性情報を含む伝送セッションプロパティ（ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｐｒｏｐｅｒｔｙ）情報を含むことができる。

伝送オブジェクト識別子フィールド（ＴＯＩ）は、オブジェクトの固有識別子である。ＴＯＵは、このパケットがセッション内のどのオブジェクトに属するかを示す。このフィールドは、現在のパケットのペイロードがこのセッション内のどのオブジェクトに属するかを示す。オブジェクトへのＴＯＩフィールドのマッピングは、拡張されたＦＤＴによって提供される。

拡張されたＦＤＴは、ファイル伝達データの細部事項を特定する。これは、拡張されたＦＤＴインスタンスである。ＬＣＴパケットヘッダーと共に拡張されたＦＤＴは、デリバリオブジェクトに対するＦＤＴ同等記述を生成するために用いられてもよい。拡張されたＦＤＴを、参照として埋め込み（ｅｍｂｅｄ）又は提供することができる。参照として提供すると、拡張されたＦＤＴは、ＬＳＩＤと独立してアップデートすることができる。参照されると、含まれるソースフローのＴＯＩ＝０上のイン−バンドオブジェクトとして伝達されるはずである。

ヘッダー拡張フィールドは、追加情報の伝送のためのＬＣＴヘッダー拡張部分として用いられる。ヘッダー拡張は、必ずしも用いられないか、可変サイズを有する選択的なヘッダーフィールドを収容するようにＬＣＴで用いられる。

例えば、ＥＸＴ＿ＴＩＭＥ拡張は、いくつかのタイプのタイミング情報を伝達するために用いられる。これは、汎用タイミング情報、すなわち、本文書に記載された伝送者現在時間（ＳＣＴ）、予想レジデュアル時間（ＥＲＴ）及び伝送者最後変更（ＳＬＣ）時間拡張を含む。これはまた、（例えば、単一プロトコル例示化（ｉｎｓｔａｎｔｉａｔｉｏｎ）のために定義された）より狭い適用可能性を有するタイミング情報に用いられてもよく、この場合、個別文書に記載される。

ＦＥＣペイロードＩＤフィールドは、送信ブロック又はエンコーディングシンボルの識別情報を含む。ＦＥＣペイロードＩＤは、上記ファイルがＦＥＣエンコードされた場合の識別子を示す。例えば、ＦＥＣペイロードＩＤは、上記ＦＬＵＴＥプロトコルファイルがＦＥＣエンコードされた場合、これを放送局又は放送サーバーにとって区分するように割り当てることができる。

シンボルエンコーディングフィールドは、送信ブロック又はエンコーディングシンボルのデータを含むことができる。

パケットペイロードは、オブジェクトから生成されたバイトを含む。１よりも多いオブジェクトがセッションで伝送されると、ＬＣＴヘッダー内の送信オブジェクトＩＤ（ＴＯＩ）は、パケットペイロードデータが生成されたオブジェクトを識別するために用いなければならない。

本発明の一実施例に係るＬＣＴパケットは、ヘッダー拡張フィールドの拡張形態である実時間支援拡張フィールド（ＥＸＴ＿ＲＴＳ）を含むことができる。ＥＸＴ＿ＲＴＳは、ファイルの分割生成及び消費情報を含むことができ、以下ではフラグメント情報と表現することができる。本発明の一実施例に係るＬＣＴパケットは、ヘッダー拡張フィールドの拡張形態でＥＸＴ＿ＲＴＳを含むことによって、既存のＬＣＴと交換可能な方法で実時間ファイル伝送及び消費情報を支援することができる。

本発明の一実施例に係るフラグメント情報（ＥＸＴ＿ＲＴＳ）は、ヘッダー拡張タイプフィールド（ＨＥＴ）、フラグメント開始指示器フィールド（ＳＩ）、フラグメントヘッダーフラグフィールド（ＦＨ）、及びフラグメントヘッダー完了指示器フィールド（ＦＣ）を含むことができる。

ヘッダー拡張タイプフィールド（ＨＥＴ）は、当該ヘッダー拡張のタイプを示す。ＨＥＴフィールドは８ビットの整数であってもよい。基本的に、ＬＣＴでは、ＨＥＴが０〜１２７の値を有する場合、３２−ビットワード単位の可変長ヘッダー拡張が存在し、ＨＥＴに後くヘッダー拡張長さフィールド（ＨＥＬ）にその長さを記述する。ＨＥＴが１２８〜２５５の値を有する場合、ヘッダー拡張は３２ビットの固定長を有する。

本発明の一実施例に係るフラグメント情報（ＥＸＴ＿ＲＴＳ）は、３２ビットの固定長を有するので、１２８〜２５５の値のいずれか一つの固有値で当該ヘッダー拡張のタイプを識別することができる。

ＳＩフィールドは、当該ＬＣＴパケットがフラグメントの開始部を含んでいることを示す。放送環境でユーザが当該ファイルベースマルチメディアコンテンツが伝送されるチャネルの任意の時点に接近した場合、最初に受信されるパケットのうち、ＳＩフィールドが０に設定されたパケットは捨て、ＳＩフィールドが１に設定されたパケットからパーシングを始めることによって、パケットの処理効率を上げ、初期遅延時間を短縮させることができる。

ＦＨフィールドは、当該ＬＣＴパケットがフラグメントヘッダー部分を含んでいることを示す。上述したように、フラグメントヘッダーは、生成順序と消費順序がフラグメントペイロードのそれと異なる特性を有する。本発明の一実施例に係る放送信号受信装置は、ＦＨフィールドに基づき、生成順で受信された伝送ブロックを消費順序に合わせて再配列してフラグメントを再生成することが可能になる。

ＦＣフィールドは、当該パケットがフラグメントの最後のデータを含んでいることを示すことができる。例えば、フラグメントペイロードが送信された後にフラグメントヘッダーが伝送される場合、ＦＣフィールドは、フラグメントヘッダーの最後のデータを含んでいることを示すことができる。そして、フラグメントヘッダーが送信された後にフラグメントペイロードが伝送される場合、ＦＣフィールドは、フラグメントペイロードの最後のデータを含んでいることを示すことができる。以下では、フラグメントペイロードがまず送信された後にフラグメントヘッダーが伝送されることを中心に説明する。

放送信号受信装置が、ＦＣフィールドが１に設定されたパケットを受信すると、フラグメントヘッダーの受信が完了したことを認知し、フラグメントヘッダー及びフラグメントペイロードを組み合わせてフラグメントを復元することができる。

パディングバイトフィールド（ＰＢ）は、当該ＬＣＴパケットに含まれたパディングバイト数を示す。既存のＬＣＴでは、一つのオブジェクトに該当する全てのＬＣＴパケットの長さが同一でなければならない。しかし、本発明の一実施例に係るデータ構成方案によって伝送ブロックを分ける場合、毎伝送ブロックの最後のシンボルは、異なる長さを有し得る。このため、本発明の一実施例に係る放送信号送信装置は、パケットの残り部分をパディングバイトで埋めることによって、固定長パケットを用いて既存のＬＣＴと交換可能な方法で実時間ファイル伝送を支援することができる。

予約フィールドは、将来の使用のために予約される。

図３１は、本発明の一実施例に係るファイルを伝送するためのＬＣＴパケットの構造を示す図である。

図３１に示す部分のうち、図３５に示す部分と同一の部分は、図３５で説明した内容と同一であり、以下では差異点を中心に説明するものとする。

図３１を参照すると、本発明の一実施例に係るフラグメント情報（ＥＸＴ＿ＲＴＳ）は、図３５で説明したＦＣフィールドの代わりに、フラグメントヘッダー長フィールド（ＦＨＬ）を含むことができる。

ＦＨＬフィールドは、フラグメントを構成するシンボルの数を示すことによって、フラグメントの受信が完了したか否かに関する情報を提供することができる。ＦＨＬフィールドは、フラグメントヘッダー及びフラグメントペイロードの両方を含むそれぞれのフラグメントに該当する全シンボルの数を示すことができる。また、ＦＨＬフィールドは、フラグメントヘッダー及びフラグメントペイロードのうち、後に伝送されるものの全シンボルの数を示すことができる。

例えば、フラグメントペイロードがまず送信された後にフラグメントヘッダーが伝送される場合、ＦＨＬフィールドは、フラグメントヘッダーに該当する全シンボルの数を示すことができる。このとき、ＦＨＬフィールドはフラグメントヘッダーの長さを示すことができる。

そして、フラグメントヘッダーがまず送信された後にフラグメントペイロードが伝送される場合、ＦＨＬフィールドは、フラグメントペイロードに該当する全シンボルの数を示すことができる。このとき、ＦＨＬフィールドはフラグメントペイロードの長さを示すことができる。

以下では、フラグメントペイロードがまず送信された後にフラグメントヘッダーが伝送される場合を中心に説明する。

本発明の他の実施例に係る放送信号受信装置は、ＦＨＬフィールドに表示されたシンボルの個数に該当するフラグメントヘッダーを含むＬＣＴパケットを受信することができる。放送信号受信装置は、フラグメントヘッダーを含むＬＣＴパケットの受信の回数をチェックすることによって、フラグメントヘッダーの受信が完了したことを識別することができる。又は、放送信号受信装置は、フラグメントヘッダーに該当する伝送ブロックの個数をチェックして、フラグメントヘッダーの受信が完了したことを識別することができる。

＜ファイルの分割生成及び分割消費の識別方法＞
図３２は、本発明の一実施例に係るＦＤＴを用いた実時間放送支援情報シグナリングを示す図である。

上述したように、本発明は、実時間放送環境でファイルベースマルチメディアコンテンツの分割生成及び分割消費に関する情報を識別する方法を提供することを一実施例としている。ファイルベースマルチメディアコンテンツの分割生成及び分割消費に関する情報は、上述したデータ構造及びＬＣＴパケット情報を含むことができる。

放送信号送信装置は、ファイルの分割生成情報及び分割消費情報の識別のために別のシグナリング情報を更に伝送することができる。例えば、シグナリング情報は、メタデータ又は帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）を用いたシグナリング（ｓｉｇｎａｌｉｎｇ）情報を含むことができる。

図３２を参照すると、本発明の一実施例に係る実時間放送支援情報に対するシグナリング情報を送信する方法が示されている。

本発明の一実施例に係る放送信号送信装置は、ＦＤＴ（ＦｉｌｅＤｅｌｉｖｅｒｙＴａｂｌｅ）レベル又はファイルレベルの実時間支援属性を用いてシグナリング情報を伝送することができる。実時間支援が１に設定されている場合、当該ＦＤＴレベル又はファイルレベルで記述しているオブジェクトが上述のデータ構造及びパケット情報を有し、これを用いて、実時間放送環境におけるファイル分割生成及び消費を支援できることを示すことができる。

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

図３３を参照すると、本発明の一実施例に係る放送網を介して、マルチメディアコンテンツを含む放送信号を送信する放送信号送信装置は、シグナリングエンコーダＣ２１００５、送信ブロック生成器Ｃ２１０３０、及び／又は送信器Ｃ２１０５０を含むことができる。

シグナリングエンコーダＣ２１００５は、シグナリング情報を生成することができる。シグナリング情報は、マルチメディアコンテンツを実時間で伝送するか否かを示す情報である。シグナリング情報は、ファイルレベル又はＦＤＴレベルのうち少なくとも一つで上記マルチメディアコンテンツを実時間で送信することを示すことができる。シグナリング情報がファイルレベルでマルチメディアコンテンツを実時間で送信することを示すと、当該ファイルに属する全データを実時間で伝送することができる。また、シグナリング情報がＦＤＴレベルでマルチメディアコンテンツを実時間で送信することを示すと、当該ＦＤＴに属する全ファイル又はデータを実時間で伝送することができる。

シグナリング情報がマルチメディアコンテンツを実時間で送信することを示す場合、送信ブロック生成器Ｃ２１０３０は、マルチメディアコンテンツに含まれるファイルを、独立して符号化して伝送されるデータ単位である少なくとも一つの伝送ブロックに分割することができる。

送信器Ｃ２１０５０は、伝送ブロックを伝送することができる。

より具体的な内容は、以下の図３４で説明する。

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

図３４を参照すると、本発明の一実施例に係る放送網を用いて、マルチメディアコンテンツを含む放送信号を送信する放送信号送信装置は、シグナリングエンコーダ（図示せず）、メディアエンコーダＣ２１０１０、フラグメント生成器Ｃ２１０２０、送信ブロック生成器Ｃ２１０３０、パケタイザＣ２１０４０、及び／又は送信器Ｃ２１０５０を含むことができる。

シグナリングエンコーダ（図示せず）は、シグナリング情報を生成することができる。シグナリング情報は、マルチメディアコンテンツを実時間で伝送するか否かを示す情報である。

メディアエンコーダＣ２１０１０は、マルチメディアコンテンツをエンコードしてメディアデータを生成することができる。以下でメディアデータをデータと表現することができる。

フラグメント生成器Ｃ２１０２０は、マルチメディアコンテンツを構成するそれぞれのファイルを分割して、独立して復号化及び再生されるデータ単位である少なくとも一つのフラグメントを生成することができる。

フラグメント生成器Ｃ２１０２０は、それぞれのフラグメントを構成するフラグメントペイロードを生成した後にフラグメントヘッダーを生成することができる。

フラグメント生成器Ｃ２１０２０は、フラグメントペイロードに該当するメディアデータをバッファすることができる。その後、フラグメント生成器Ｃ２１０２０は、バッファしたメディアデータに基づいて、フラグメントペイロードに該当するチャンク（ｃｈｕｎｋ）を生成することができる。例えば、チャンクは、ビデオデータのＧＯＰのように、同一のメディアデータで構成される可変サイズのデータ単位であってもよい。

フラグメントペイロードに該当するチャンクの生成が完了していないと、フラグメント生成器Ｃ２１０２０は、メディアデータを継けてバッファした後、フラグメントペイロードに該当するチャンクの生成を完了することができる。

フラグメント生成器Ｃ２１０２０は、チャンクを生成する度に、フラグメントペイロードに該当するデータを全てチャンクとして生成したか否かを判断することができる。

フラグメントペイロードに該当するチャンクの生成が完了すると、フラグメント生成器Ｃ２１０２０は、フラグメントペイロードに該当するフラグメントヘッダーを生成することができる。

送信ブロック生成器Ｃ２１０３０は、フラグメントを分割して、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを生成することができる。

本発明の一実施例に係る伝送ブロックは、以前（ｐｒｅｃｅｄｉｎｇ）のデータに対する依存性無しで独立して符号化及び伝送可能な最小のデータ単位を意味する。例えば、伝送ブロックは、ビデオデータのＧＯＰのように、同一のメディアデータで構成される少なくとも一つのチャンクを含むことができる。

本発明の一実施例に係る送信ブロック生成器Ｃ２１０３０は、フラグメントペイロードに該当する伝送ブロックをまず生成した後に、フラグメントヘッダーに該当する伝送ブロックを生成することができる。

送信ブロック生成器Ｃ２１０３０は、フラグメントヘッダーを一つの伝送ブロックとして生成することができる。ただし、これに限定されず、送信ブロック生成器Ｃ２１０３０は、フラグメントヘッダーを少なくとも一つの伝送ブロックとして生成することもできる。

例えば、フラグメント生成器Ｃ２１０２０がそれぞれのフラグメントを構成するフラグメントペイロードを生成した後にフラグメントヘッダーを生成する場合、送信ブロック生成器Ｃ２１０３０は、フラグメントペイロードに該当する伝送ブロックを生成した後、フラグメントヘッダーに該当する伝送ブロックを生成することができる。

ただし、これに限定されず、マルチメディアコンテンツに対してフラグメントヘッダー及びフラグメントペイロードが既に生成されている場合には、フラグメントヘッダーに該当する伝送ブロックをまず生成した後に、フラグメントペイロードに該当する伝送ブロックを生成することもできる。

送信ブロック生成器Ｃ２１０３０は、フラグメントペイロードに該当する伝送ブロックとフラグメントヘッダーに該当する伝送ブロックをそれぞれ別個の伝送ブロックとして生成することができる。

パケタイザＣ２１０４０は、伝送ブロックを同一サイズの少なくとも一つのシンボルに分割して、それぞれの少なくとも一つのシンボルを、少なくとも一つのパケットにパケット化することができる。ただし、これに限定されず、シンボルは、他の装置によって生成されてもよい。本発明の一実施例に係るシンボルの長さは同一であってもよい。ただし、各伝送ブロックの最後のシンボルは、他のシンボルに比べて短い長さを有しうる。

その後、パケタイザＣ２１０４０は、少なくとも一つのシンボルを少なくとも一つのパケットにパケット化することができる。例えば、パケットはＬＣＴパケットであってもよい。パケットは、パケットヘッダー及びパケットペイロードを含むことができる。

パケットヘッダーは、ファイルの分割生成及び分割消費に関する情報を有するフラグメント情報を含むことができる。ファイルの分割生成とは、マルチメディアコンテンツを構成するファイルを、独立してエンコード及び伝送できる少なくとも一つのチャンク又は伝送ブロックに分割して生成することを意味する。ファイルの分割消費とは、受信された少なくとも一つの伝送ブロックを組み合わせて、独立してデコード及び再生できる少なくとも一つのフラグメントを復元し、フラグメント単位で再生することを意味する。また、ファイルの分割消費とは、伝送ブロック単位で再生することを含むことができる。

例えば、フラグメント情報は、パケットがフラグメントの最初のデータを含んでいることを示すＳＩフィールド、パケットがフラグメントヘッダーのデータを含んでいることを示すＦＨフィールド、それぞれのフラグメントに該当する伝送ブロックの生成を完了したことを示すフラグメント完了情報、及びパケットに含まれたパディングバイト数を示すＰＢフィールドのうち少なくとも一つを含むことができる。

そして、フラグメント情報は、当該パケットのヘッダー拡張のタイプを示すＨＥＴ（ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎＴｙｐｅｆｉｅｌｄ）フィールドをさらに含むことができる。

そして、フラグメント完了情報は、パケットがフラグメントヘッダーの最後のデータを含んでいることを示すＦＣフィールド、及びフラグメントヘッダーに該当する全シンボルの数を示すＦＨＬフィールドのうち一つを含むことができる。

フラグメント情報は、パケタイザＣ２１０４０で生成されてもよく、別の装置によって生成されてもよい。以下では、パケタイザＣ２１０４０がフラグメント情報を生成する場合を中心に説明する。

パケタイザＣ２１０４０は、生成されたシンボルがフラグメントの最初のデータを含んでいるか否かを識別することができる。

例えば、パケタイザＣ２１０４０は、生成されたシンボルがフラグメントペイロードの最初のデータを含むか否かを識別することができる。生成されたシンボルがフラグメントペイロードの最初のデータを含んでいると、ＳＩフィールドは‘１’に設定されてもよい。生成されたシンボルがフラグメントペイロードの最初のデータを含んでいないと、ＳＩフィールドは‘０’に設定されてもよい。

パケタイザＣ２１０４０は、生成されたシンボルがフラグメントペイロードのデータを含むか、或いはフラグメントヘッダーのデータを含むかを識別することができる。

例えば、生成されたシンボルがフラグメントペイロードのデータを含むと、ＦＨフィールドは‘１’に設定されてもよい。生成されたシンボルがフラグメントペイロードのデータを含まないと、ＦＨフィールドは‘０’に設定されてもよい。

パケタイザＣ２１０４０は、それぞれのフラグメントに該当する伝送ブロックの生成を完了したか否かを識別することができる。それぞれのフラグメントに該当する伝送ブロックの生成を完了したことを示すフラグメント完了情報は、パケットがフラグメントヘッダーの最後のデータを含んでいることを示すＦＣフィールドを含むことができる。

例えば、生成されたシンボルがフラグメントヘッダーのデータを含み、当該伝送ブロックの最後のシンボルであれば、ＦＣフィールドは‘１’に設定されてもよい。生成されたシンボルがフラグメントヘッダーのデータを含まないか、又は当該伝送ブロックの最後のシンボルでないと、ＦＣフィールドは‘０’に設定されてもよい。

パケタイザＣ２１０４０は、生成されたシンボルが当該伝送ブロックの最後のシンボルであり、他のシンボルと異なる長さを有するシンボルであるかを識別することができる。例えば、他のシンボルは、あらかじめ定められた長さのシンボルであり、他のシンボルと異なる長さを有するシンボルは、他のシンボルに比べて長さの短いシンボルであってもよい。

例えば、生成されたシンボルが当該伝送ブロックの最後のシンボルであり、他のシンボルと異なる長さを有すると、パケタイザＣ２１０４０は、それぞれの伝送ブロックの最後のシンボルに該当するパケットにパディングバイトを挿入することができる。そして、パケタイザＣ２１０４０は、パッキングバイトの数を計算することができる。

そして、ＰＢフィールドは、パディングバイトの数を示すことができる。パディングバイトは、他のシンボルと同一の長さとなるように、他のシンボルに比べて長さの短いシンボルに追加されるバイトである。又は、パディングバイトは、パケットにおいてシンボルを除いた残りの部分であってもよい。

生成されたシンボルが当該伝送ブロックの最後のシンボルでないか、又は他のシンボルと長さが異なると、ＰＢフィールドは‘０’に設定されてもよい。

パケットペイロードは、少なくとも一つのシンボルを含むことができる。以下では、一つのパケットが一つのシンボルを含む場合を中心に説明する。

それぞれの伝送ブロックの最後のシンボルを含むパケットは、少なくとも一つのパディングバイトを含むことができる。

送信器Ｃ２１０５０は、伝送ブロックが生成された順で少なくとも一つのパケットを伝送することができる。

例えば、本発明の一実施例に係る送信器Ｃ２１０５０は、フラグメントペイロードに該当する伝送ブロックをまず送信した後に、フラグメントヘッダーに該当する伝送ブロックを伝送することができる。

ただし、これに限定されず、マルチメディアコンテンツに対してフラグメントヘッダー及びフラグメントペイロードが既に生成されている場合には、本発明の一実施例に係る送信器Ｃ２１０５０は、フラグメントヘッダーに該当する伝送ブロックをまず送信した後に、フラグメントペイロードに該当する伝送ブロックを伝送することもできる。

図３５は、本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間生成及び送信手順を示すフローチャートである。

図３５を参照すると、図３４で上述した放送信号送信装置が放送信号を送信する手順が示されている。

まず、本発明の一実施例に係る放送信号送信装置は、メディアエンコーダＣ２１０１０を用いてマルチメディアコンテンツのエンコーディングを始めることができる（ＣＳ１１１００）。放送信号送信装置は、マルチメディアコンテンツをエンコードしてメディアデータを生成することができる。

その後、放送信号送信装置は、フラグメントペイロードに該当するメディアデータをバッファすることができる（ＣＳ１１２００）。その後、放送信号送信装置は、バッファしたメディアデータに基づいて、フラグメントペイロードに該当するチャンク（ｃｈｕｎｋ）を生成することができる。

フラグメントペイロードに該当するチャンクの生成が完了していないと、放送信号送信装置は、メディアデータを続けてバッファした後に、フラグメントペイロードに該当するチャンクの生成を完了すればよい（ＣＳ１１３００）。

その後、放送信号送信装置は、フラグメント生成器Ｃ２１０２０を用いて、マルチメディアコンテンツを構成するそれぞれのファイルを分割し、独立して復号化及び再生されるデータ単位である少なくとも一つのフラグメントを生成することができる（ＣＳ１１４００）。

放送信号送信装置は、それぞれのフラグメントを構成するフラグメントペイロードを生成した後にフラグメントヘッダーを生成することができる。

放送信号送信装置は、チャンクを生成する度に、フラグメントペイロードに該当するデータを全てチャンクとして生成したか判断することができる。

その後、フラグメントペイロードに該当するチャンクの生成が完了すると、放送信号送信装置は、フラグメントペイロードに該当するフラグメントヘッダーを生成することができる。

その後、放送信号送信装置は、送信ブロック生成器Ｃ２１０３０を用いてフラグメントを分割して、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを生成することができる（ＣＳ１１５００）。

例えば、それぞれのフラグメントを構成するフラグメントペイロードを生成した後にフラグメントヘッダーを生成する場合、放送信号送信装置は、フラグメントペイロードに該当する伝送ブロックを生成した後、フラグメントヘッダーに該当する伝送ブロックを生成することができる。

放送信号送信装置は、フラグメントペイロードに該当する伝送ブロックとフラグメントヘッダーに該当する伝送ブロックを、それぞれ別個の伝送ブロックとして生成することができる。

その後、放送信号送信装置は、パケタイザＣ２１０４０を用いて伝送ブロックを同一サイズの少なくとも一つのシンボルに分割し、それぞれの少なくとも一つのシンボルを少なくとも一つのパケットにパケット化することができる（ＣＳ１１６００、ＣＳ１１７００）。

放送信号送信装置がパケットを生成する手順については図４０で具体的に後述し、ここでは説明を省略するものとする。

その後、放送信号送信装置は、送信器Ｃ２１０５０を用いて伝送ブロックが生成された順で少なくとも一つのパケットを伝送することができる。

図３６は、本発明の一実施例に係る放送信号送信装置がパケタイザを用いてパケットを生成する手順を具体的に示すフローチャートである。

放送信号送信装置は、生成されたシンボルがフラグメントの最初のデータを含んでいるか否か識別することができる（ＣＳ１１７１０）。

例えば、生成されたシンボルがフラグメントペイロードの最初のデータを含んでいると、ＳＩフィールドは‘１’に設定されてもよい（ＣＳ１１７１２）。生成されたシンボルがフラグメントペイロードの最初のデータを含んでいないと、ＳＩフィールドは‘０’に設定されてもよい（ＣＳ１１７１４）。

その後、放送信号送信装置は、生成されたシンボルがフラグメントペイロードのデータを含むか、或いはフラグメントヘッダーのデータを含むかを識別することができる（ＣＳ１１７２０）。

例えば、生成されたシンボルがフラグメントペイロードのデータを含むと、ＦＨフィールドは‘１’に設定されてもよい（ＣＳ１１７２２）。生成されたシンボルがフラグメントペイロードのデータを含まないと、ＦＨフィールドは‘０’に設定されてもよい（ＣＳ１１７２４）。

その後、放送信号送信装置は、それぞれのフラグメントに該当する伝送ブロックの生成を完了したか否かを識別することができる（ＣＳ１１７３０）。

例えば、生成されたシンボルがフラグメントヘッダーのデータを含み、当該伝送ブロックの最後のシンボルであれば、ＦＣフィールドは‘１’に設定されてもよい（ＣＳ１１７３２）。生成されたシンボルがフラグメントヘッダーのデータを含まないか、又は当該伝送ブロックの最後のシンボルでないと、ＦＣフィールドは‘０’に設定されてもよい（ＣＳ１１７３４）。

その後、放送信号送信装置は、生成されたシンボルが当該伝送ブロックの最後のシンボルであり、他のシンボルと異なる長さを有するシンボルであるか識別することができる（ＣＳ１１７４０）。

例えば、生成されたシンボルが当該伝送ブロックの最後のシンボルであり、他のシンボルと異なる長さを有すると、放送信号送信装置は、それぞれの伝送ブロックの最後のシンボルに該当するパケットにパディングバイトを挿入することができる。そして、放送信号送信装置は、パディングバイトの数を計算することができる（ＣＳ１１７４２）。そして、ＰＢフィールドは、パディングバイトの数を示すことができる。

生成されたシンボルが当該伝送ブロックの最後のシンボルでないか、又は他のシンボルと長さが異なると、ＰＢフィールドは‘０’に設定されてもよい（ＣＳ１１７４４）。

パケットペイロードは少なくとも一つのシンボルを含むことができる。

図３７は、本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間生成／送信の手順を示すフローチャートである。

図３７では、図３５及び図３６で説明された内容と実質的に同じ内容については具体的な説明を省略する。

本発明の一実施例に係る放送信号送信装置は、ＦＣフィールドの代わりにＦＨＬフィールドを使用することができる。例えば、上述したフラグメント情報は、それぞれのフラグメントに該当する伝送ブロックの生成を完了したことを示すフラグメント完了情報を含むことができる。そして、フラグメント完了情報は、フラグメントヘッダーに該当する全シンボルの数を示すＦＨＬフィールドを含むことができる。

本発明の一実施例に係る放送信号送信装置は、フラグメントヘッダーのデータを含む伝送ブロックに該当するシンボルの個数を計算してＦＨＬフィールドに記録することができる（ＣＳ１２７２４）。

ＦＨＬフィールドは、フラグメントヘッダー部分に該当する全シンボル数としてフラグメントヘッダーの長さを示す。放送信号受信装置がフラグメントヘッダーの受信が完了したことを識別できるように、ＦＨＬフィールドは、上述したＦＣフィールドの代わりにフラグメント情報に含まれてもよい。

本発明の一実施例に係る放送信号受信装置は、ＦＨＬフィールドに記録された個数だけのフラグメントヘッダーを含むパケットの伝送回数をチェックすることによって、フラグメントヘッダーの受信が完了したか否かを識別することができる。

図３８は、本発明の一実施例に係るファイルベースマルチメディアコンテンツ受信機の構造を示す図である。

図３８を参照すると、本発明の一実施例に係る放送網を用いて、マルチメディアコンテンツを含む放送信号を受信する放送信号受信装置は、受信部（図示せず）、シグナリングデコーダＣ２２００５、送信ブロック再生成器Ｃ２２０３０、及び／又はメディアデコーダＣ２２０６０を含むことができる。

シグナリングデコーダＣ２２００５は、シグナリング情報をデコードすることができる。シグナリング情報は、マルチメディアコンテンツを実時間で伝送するか否かを示す情報である。

シグナリング情報がマルチメディアコンテンツを実時間で送信することを示す場合、送信ブロック再生成器Ｃ２２０３０は、放送信号を組み合わせて、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを復元することができる。

メディアデコーダＣ２２０６０は、伝送ブロックを復号化することができる。

より具体的な内容は、図４４で後述する。

図３９は、本発明の一実施例に係るファイルベースマルチメディアコンテンツ受信機の構造を示す図である。

図３９を参照すると、本発明の一実施例に係る放送信号受信装置は、受信部（図示せず）、シグナリングデコーダ（図示せず）、パケットフィルタＣ２２０１０、パケットデパケタイザＣ２２０２０、送信ブロック再生成器Ｃ２２０３０、フラグメント再生成器Ｃ２２０４０、フラグメントパーサーＣ２２０５０、メディアデコーダＣ２２０６０、及び／又はメディアレンダラＣ２２０７０を含むことができる。

受信部（図示せず）は、放送信号を受信することができる。放送信号は、少なくとも一つのパケットを含むことができる。それぞれのパケットは、フラグメント情報を含むパケットヘッダー、及び少なくとも一つのシンボルを含むパケットペイロードを含むことができる。

パケットフィルタＣ２２０１０は、任意の地点で受信された少なくとも一つのパケットからフラグメントの開始地点を識別し、フラグメントの開始地点からパケット処理を開始可能にする。

パケットフィルタＣ２２０１０は、パケットに含まれたフラグメント情報のＳＩフィールドに基づいてフラグメントの開始地点を識別することができる。パケットフィルタＣ２２０１０は、ＳＩフィールドが、当該パケットがフラグメントの開始部分を含んでいることを示すと、当該パケット以前のパケットを捨て、当該パケットからパケットデパケタイザＣ２２０２０に伝達することができる。

例えば、パケットフィルタＣ２２０１０は、‘１’に設定されたパケット以前のパケットは捨て、‘１’に設定されたパケット以降のパケットをフィルタすることができる。

パケットデパケタイザＣ２２０２０は、少なくとも一つのパケットをデパケット化して、パケットヘッダーに含まれたフラグメント情報及びパケットペイロードに含まれた少なくとも一つのシンボルを抽出することができる。

送信ブロック再生成器Ｃ２２０３０はパケットを組み合わせて、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを復元することができる。復元された伝送ブロックは、フラグメントヘッダーに該当するデータを含むことができ、フラグメントペイロードに該当するデータを含むことができる。

フラグメント再生成器Ｃ２２０４０は、少なくとも一つの伝送ブロックを組み合わせて、フラグメントヘッダー及びフラグメントペイロードの復元を完了した後にフラグメントヘッダー及びフラグメントペイロードを組み合わせて、独立して復号化及び再生されるデータ単位であるフラグメントを復元することができる。

フラグメント再生成器Ｃ２２０４０は、フラグメント情報に基づいて伝送ブロックを組み合わせて、フラグメントペイロード及びフラグメントヘッダーを復元することができる。フラグメント再生成器Ｃ２２０４０は、受信されるパケットの順序でフラグメントペイロードをまず復元した後、フラグメントヘッダーを復元することができる。

ＦＨフィールドが、パケットがフラグメントヘッダーのデータを含んでいることを示すと、フラグメント再生成器Ｃ２２０４０は、フラグメントヘッダーに該当する少なくとも一つの伝送ブロックを組み合わせて、フラグメントヘッダーを復元することができる。

ＦＨフィールドが、パケットがフラグメントヘッダーのデータを含んでいないことを示すと、フラグメント再生成器Ｃ２２０４０は、フラグメントペイロードに該当する少なくとも一つの伝送ブロックを組み合わせて、フラグメントペイロードを復元することができる。

例えば、ＦＨフィールドの値が‘０’である場合、フラグメント再生成器Ｃ２２０４０は、フラグメントペイロードとして判断し、フラグメントペイロードを復元することができる。ＦＨフィールドの値が‘１’である場合、フラグメント再生成器Ｃ２２０４０はフラグメントヘッダーとして判断し、フラグメントヘッダーを復元することができる。

その後、フラグメント再生成器Ｃ２２０４０は、それぞれのフラグメントに該当するフラグメントペイロード及びフラグメントヘッダーの復元を終了すると、復元したフラグメントペイロード及びフラグメントヘッダーを組み合わせてフラグメントを復元することができる。

フラグメント再生成器Ｃ２２０４０がそれぞれのフラグメントに該当するフラグメントペイロード及びフラグメントヘッダーの復元を終了したかを確認する方法としては、下記の２つの方法を挙げることができる。

第一の方法は、フラグメント情報に含まれたＦＣフィールドを用いる方法である。

フラグメント完了情報は、パケットがフラグメントヘッダーの最後のデータを含んでいることを示すＦＣフィールドを含むことができる。ＦＣフィールドが、パケットがフラグメントヘッダーの最後のデータを含んでいることを示すと、フラグメント再生成器Ｃ２２０４０は、それぞれのフラグメントを構成するフラグメントヘッダー及びフラグメントペイロードの受信が完了したと判断し、フラグメントヘッダー及びフラグメントペイロードの復元を完了することができる。

例えば、それぞれのフラグメントを構成するフラグメントペイロードがまず受信された後にフラグメントヘッダーが受信されると、ＦＣフィールドは、当該パケットがフラグメントヘッダーの最後のデータを含んでいることを示すことができる。

したがって、ＦＣフィールドが、当該パケットがフラグメントヘッダーの最後のデータを含んでいることを示すと、フラグメント再生成器Ｃ２２０４０は、フラグメントヘッダーの受信が完了したことを認識し、フラグメントヘッダーを復元する手順を終了すればよい。その後、フラグメント再生成器Ｃ２２０４０は、フラグメントヘッダーとフラグメントペイロードを組み合わせてフラグメントを復元することができる。

ＦＣフィールドが、当該パケットがフラグメントヘッダーの最後の部分のデータを含んでいないことを示すと、放送信号受信装置は、伝送ブロックを復元する手順を反復することができる。

例えば、ＦＣフィールドの値が‘１’でない場合、放送信号受信装置は、伝送ブロックを復元する手順を反復することができる。そして、ＦＣフィールドの値が‘１’である場合、フラグメント再生成器Ｃ２２０４０は、フラグメントヘッダーとフラグメントペイロードを組み合わせてフラグメントを復元することができる。

第二の方法は、フラグメント情報に含まれたＦＨＬフィールドに基づいて、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの復元が完了したか否かを確認することができる。

フラグメント再生成器Ｃ２２０４０は、フラグメントヘッダーのデータを含むパケットの数をカウントすることができる。

フラグメント完了情報は、フラグメントヘッダーに該当する全シンボルの数を示すＦＨＬフィールドをさらに含み、ＦＨＬフィールドに記録された値とフラグメントヘッダーのデータを含むパケットの数とが一致すると、フラグメント再生成器Ｃ２２０４０はフラグメントヘッダー及びフラグメントペイロードの復元を完了することができる。

フラグメント再生成器Ｃ２２０４０がＦＨＬフィールドを用いることに関する具体的な説明は、図４６で後述する。

フラグメントパーサーＣ２２０５０は、復元されたフラグメントをパースすることができる。復元されたフラグメントは、フラグメントヘッダーが前の部分に位置し、フラグメントペイロードが後の部分に位置するため、フラグメントパーサーＣ２２０５０は、フラグメントヘッダーをまずパースした後にフラグメントペイロードをパースすることができる。

フラグメントパーサーＣ２２０５０は、復元されたフラグメントをパースして、少なくとも一つのメディアアクセスユニットを生成することができる。例えば、メディアアクセスユニットは、少なくとも一つのメディアデータを含むことができる。メディアアクセスユニットは、あらかじめ定められたサイズのメディアデータの単位であってもよい。

メディアデコーダＣ２２０６０はフラグメントを復号化することができる。メディアデコーダＣ２２０６０は少なくとも一つのメディアアクセスユニットを復号化してメディアデータを生成することができる。

メディアレンダラＣ２２０７０は、復号化されたメディアデータをレンダリングしてプレゼンテーションすることができる。

図４０は、本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間受信／消費の手順を示す図である。

図３９で説明した内容は、本発明の一実施例に係る放送信号受信方法に同一に適用されてもよい。

図４０を参照すると、本発明の一実施例に係る放送信号受信方法は、少なくとも一つのファイルを含むマルチメディアコンテンツを受信する放送信号受信方法において、少なくとも一つのパケットに分割されたマルチメディアコンテンツを受信し、パケットを組み合わせて、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを復元し、少なくとも一つの伝送ブロックを組み合わせて、フラグメントヘッダー及びフラグメントペイロードの復元を完了した後、フラグメントヘッダー及びフラグメントペイロードを組み合わせて、独立して復号化及び再生されるデータ単位であるフラグメントを復元し、及び／又はフラグメントを復号化することを含むことができる。

まず、本発明の一実施例に係る放送信号受信装置は、受信部（図示せず）を用いて放送信号を受信することができる（ＣＳ２１０１０）。放送信号は、少なくとも一つのパケットを含むことができる。

その後、本発明の一実施例に係る放送信号受信装置は、パケットフィルタＣ２２０１０を用いて、任意の地点で受信された少なくとも一つのパケットからフラグメントの開始地点を識別することができる（ＣＳ２１０２０）。

その後、本発明の一実施例に係る放送信号受信装置は、パケットデパケタイザＣ２２０２０を用いて少なくとも一つのパケットをデパケット化し、パケットヘッダーに含まれたフラグメント情報及びパケットペイロードに含まれた少なくとも一つのシンボルを抽出することができる（ＣＳ２１０３０）。

その後、放送信号受信装置は、送信ブロック再生成器Ｃ２２０３０を用いてパケットを組み合わせて、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを復元することができる（ＣＳ２１０４０）。復元された伝送ブロックは、フラグメントヘッダーに該当するデータを含むことができ、フラグメントペイロードに該当するデータを含むことができる。

その後、本発明の一実施例に係る放送信号受信装置は、フラグメント再生成器Ｃ２２０４０でフラグメント情報に基づいて復元された伝送ブロックがフラグメントヘッダーに該当する伝送ブロックであるか、或いは、フラグメントペイロードに該当する伝送ブロックであるかを識別することができる（ＣＳ２１０５０）。

その後、放送信号受信装置は、復元された伝送ブロックを組み合わせて、フラグメントペイロード及びフラグメントヘッダーを復元することができる。

ＦＨフィールドが、パケットがフラグメントヘッダーのデータを含んでいないことを示すと、放送信号受信装置は、フラグメントペイロードに該当する少なくとも一つの伝送ブロックを組み合わせてフラグメントペイロードを復元することができる（ＣＳ２１０６０）。

ＦＨフィールドがパケットがフラグメントヘッダーのデータを含んでいることを示すと、放送信号受信装置は、フラグメントヘッダーに該当する少なくとも一つの伝送ブロックを組み合わせてフラグメントヘッダーを復元することができる（ＣＳ２１０７０）。

放送信号受信装置は、フラグメント情報に含まれたＦＣフィールドに基づいて、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの復元が完了したか否かを確認することができる（ＣＳ２１０８０）。

ＦＣフィールドが、当該パケットがフラグメントヘッダーの最後のデータを含んでいないことを示すと、放送信号受信装置は、伝送ブロックを復元する手順を反復することができる。

ＦＣフィールドが、当該パケットがフラグメントの最後のデータを含んでいることを示すと、放送信号受信装置は、それぞれのフラグメントの受信が完了したと判断することができる。

したがって、ＦＣフィールドが、パケットがフラグメントヘッダーの最後のデータを含んでいることを示すと、放送信号受信装置は、それぞれのフラグメントを構成するフラグメントヘッダー及びフラグメントペイロードの受信が完了したと判断し、フラグメントヘッダー及びフラグメントペイロードの復元を完了することができる。

その後、放送信号受信装置は、フラグメント再生成器Ｃ２２０４０を用いて、少なくとも一つの伝送ブロックを組み合わせてフラグメントヘッダー及びフラグメントペイロードの復元を完了した後、フラグメントヘッダー及びフラグメントペイロードを組み合わせて、独立して復号化及び再生されるデータ単位であるフラグメントを復元することができる（ＣＳ２１０９０）。

その後、本発明の一実施例に係る放送信号受信装置は、フラグメントパーサーＣ２２０５０を用いて、復元されたフラグメントをパースすることができる（ＣＳ２１０９０）。放送信号受信装置は、復元されたフラグメントをパースして少なくとも一つのメディアアクセスユニットを生成することができる。ただし、これに限定されず、放送信号受信装置は、伝送ブロックをパースして少なくとも一つのメディアアクセスユニットを生成することもできる。

その後、本発明の一実施例に係る放送信号受信装置は、メディアデコーダＣ２２０６０を用いて、少なくとも一つのメディアアクセスユニットを復号化してメディアデータを生成することができる（ＣＳ２１１００）。

その後、本発明の一実施例に係る放送信号受信装置は、メディアレンダラＣ２２０７０を用いて、復号化されたメディアデータをレンダリングしてプレゼンテーションすることができる（ＣＳ２１１１０）。

図４１は、本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間受信／消費の手順を示す図である。

図４１では、図４０で説明された内容と実質的に同じ内容については具体的な説明を省略する。

本発明の一実施例に係る放送信号受信装置は、ＦＨＬフィールドに基づいて、それぞれのフラグメントを構成するフラグメントヘッダー及びフラグメントペイロードの受信が完了したか否かを判断することができる。

本発明の一実施例に係る放送信号受信装置は、フラグメント再生成器Ｃ２２０４０を用いて、フラグメント情報に基づいて復元された伝送ブロックがフラグメントヘッダーに該当する伝送ブロックであるか、或いはフラグメントペイロードに該当する伝送ブロックであるかを識別することができる（ＣＳ２２０５０）。

その後、放送信号受信装置は、復元された伝送ブロックを組み合わせて、フラグメントペイロード及びフラグメントヘッダーをそれぞれ復元することができる。

ＦＨフィールドが、当該パケットがフラグメントペイロードに該当するデータを含んでいることを示すと、放送信号受信装置は、少なくとも一つの伝送ブロックを組み合わせてフラグメントペイロードを復元することができる（ＣＳ２２０６０）。

ＦＨフィールドが、当該パケットがフラグメントヘッダーに該当するデータを含んでいることを示すと、フラグメント再生成器Ｃ２２０４０は、少なくとも一つの伝送ブロックを組み合わせてフラグメントヘッダーを復元することができる（ＣＳ２２０７０）。

その後、放送信号受信装置が、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの復元を完了すると、放送信号受信装置は、復元したフラグメントペイロード及びフラグメントヘッダーを組み合わせてフラグメントを復元することができる。

放送信号受信装置は、フラグメント情報に含まれたＦＨＬフィールドに基づいて、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの復元が完了したか否かを確認することができる。

放送信号受信装置は、それぞれのフラグメントを構成するパケットの数（Ｎ）をカウントすることができる（ＣＳ２２０８０）。例えば、放送信号受信装置は、フラグメントヘッダーのデータを含むパケットの数をカウントすることができる。一つのパケットは少なくとも一つのシンボルを含むことができるが、以下では一つのパケットが一つのシンボルを含む場合を中心に説明する。

ＦＨＬフィールドは、フラグメントを構成するシンボルの数を示すことができる。ＦＨＬフィールドに記録されたシンボルの数に該当する数のパケットが受信されていないと、放送信号受信装置は、伝送ブロックを復元する手順を反復することができる。例えば、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了しないと、放送信号受信装置は伝送ブロックを復元する手順を反復することができる。

フラグメント完了情報は、フラグメントヘッダーに該当する全シンボルの数を示すＦＨＬフィールドをさらに含む。

ＦＨＬフィールドに記録された値とパケットの数が一致すると、放送信号受信装置は、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了したと判断し、フラグメントヘッダー及びフラグメントペイロードの復元を完了することができる（ＣＳ２２０９０）。

例えば、ＦＨＬフィールドは、フラグメントヘッダー及びフラグメントペイロードの両方を含むそれぞれのフラグメントに該当する全シンボルの数を示すことができる。このとき、ＦＨＬフィールドに記録されたシンボルの数に該当する数のパケットが受信されると、放送信号受信装置は、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了したと判断することができる。

例えば、ＦＨＬフィールドは、フラグメントヘッダー及びフラグメントペイロードのうち、後に伝送されるものの全シンボルの数を示すことができる。

それぞれのフラグメントを構成するフラグメントペイロードがまず受信された後にフラグメントヘッダーが受信されると、ＦＨＬフィールドは、フラグメントヘッダーに該当する全シンボルの数を示すことができる。このとき、ＦＨＬフィールドに記録されたシンボルの数と受信されたフラグメントヘッダーに該当するパケットの数とが同一であれば、放送信号受信装置は、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了したと判断することができる。

また、それぞれのフラグメントを構成するフラグメントヘッダーがまず受信された後にフラグメントペイロードが受信されると、ＦＨＬフィールドは、フラグメントペイロードに該当する全シンボルの数を示すことができる。このとき、ＦＨＬフィールドに記録されたシンボルの数と受信されたフラグメントペイロードに該当するパケットの数とが同一であれば、放送信号受信装置は、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了したと判断することができる。

その後、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了すると、放送信号受信装置は、フラグメントヘッダーとフラグメントペイロードとを組み合わせてフラグメントを復元することができる（ＣＳ２２１００）。

以上、本発明の一実施例に係る、可変サイズのデータ単位である伝送ブロックを用いて、放送網でマルチメディアコンテンツを伝送ブロック単位で実時間伝送及び受信する実施例について説明した。

以下では、本発明の他の実施例に係る、オブジェクト内部構造体の境界情報及びタイプ情報を用いて、放送網でマルチメディアコンテンツを可変サイズのオブジェクト内部構造体単位で実時間伝送及び受信する実施例を説明する。

ただし、本発明の他の実施例の構成のうち、本発明の一実施例の構成と同じ名称は、前述した内容を全て含むことができ、その具体的な説明は省略する。また、図１乃至図４１で説明した内容は、以下の図４２乃至図５５にも適用することができる。

＜伝送オブジェクトタイプの識別方案−１＞
図４２は、本発明の他の実施例に係るオブジェクトタイプ情報を含むパケットの構造を示す図である。

本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクトフラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、伝送者現在時間存在フラグフィールド（Ｔ）、予想レジデュアル時間存在フラグフィールド（Ｒ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、ＦＥＣペイロードＩＤフィールド、及び／又はシンボルエンコーディングフィールドを含むことができる。

本発明の他の実施例に係るパケットは、メタデータを含むパケット情報を含むことができる。パケット情報は、ＭＰＥＧ−ＤＡＳＨコンテンツ伝送時に現在パケットが送信しているオブジェクトの類型を示すオブジェクトタイプ情報を含むことができる。オブジェクトタイプ情報は、現在パケット又は同一ＴＯＩが与えられたパケットが送信しているオブジェクトのタイプを示すことができる。

例えば、オブジェクトタイプ情報は、ＬＣＴパケットの開始地点で１２番目のビットに位置する２個の予約ビットを用いてオブジェクトタイプを識別することができる。

ＭＰＥＧ−ＤＡＳＨコンテンツをＬＣＴパケットで伝送する場合、オブジェクトタイプは、レギュラーファイル、初期化セグメント、メディアセグメント及び／又は自己−初期化セグメントを含むことができる。

例えば、オブジェクトタイプ情報の値が“００”であれば、オブジェクトタイプは“レギュラーファイル（ＲｅｇｕｌａｒＦｉｌｅ）”を示し、オブジェクトタイプ情報の値が“０１”であれば、オブジェクトタイプは“初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）”を示し、オブジェクトタイプ情報の値が“１０”であれば、オブジェクトタイプは“メディアセグメント（ＭｅｄｉａＳｅｇｍｅｎｔ）”を示し、オブジェクトタイプ情報の値が“１１”であれば、オブジェクトタイプは“自己−初期化セグメント（Ｓｅｌｆ−ＩｎｉｔｉａｌｉｚｉｎｇＳｅｇｍｅｎｔ）”を示すことができる。

それぞれのオブジェクトタイプ情報が示すオブジェクトのタイプは、送信しているファイルコンテンツによって異なってもよく、オブジェクトタイプ情報の値を定義するスキームは、現在伝送中のセッション又は帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）で別のシグナリング情報の形態で伝送されてもよい。

レギュラーファイルは、マルチメディアコンテンツを構成する一般的なファイルのようなオブジェクト形態のデータ単位である。

初期化セグメントは、リプレゼンテーションに接近するための初期化情報を含むオブジェクト形態のデータ単位である。初期化セグメントは、ファイルタイプボックス（ｆｔｙｐ）及びムービーボックス（ｍｏｏｖ）を含むことができる。ファイルタイプボックス（ｆｔｙｐ）は、ファイルタイプ、ファイルバージョン、及び互換性情報を含むことができる。ムービーボックス（ｍｏｏｖ）は、メディアコンテンツを記述するメタデータを含むことができる。

メディアセグメントは、ストリーミングサービスを支援するために放送信号受信装置で伝送しようとする品質別、時間別に分離したメディア関連オブジェクト形態のデータ単位を意味する。メディアセグメントは、セグメントタイプボックス（ｓｔｙｐ）、セグメントインデックスボックス（ｓｉｄｘ）、ムービーフラグメントボックス（ｍｏｏｆ）、及びメディアデータボックス（ｍｄａｔ）を含むことができる。セグメントタイプボックス（ｓｔｙｐ）は、セグメントの類型情報を含むことができる。セグメントインデックスボックス（ｓｉｄｘ）は、当該メディアセグメントの内部に存在するメディアデータの最初のプレゼンテーション時間、データオフセット（ｏｆｆｓｅｔ）及びＳＡＰ（ＳｔｒｅａｍＡｃｃｅｓｓＰｏｉｎｔｓ）情報などを提供することができる。ムービーフラグメントボックス（ｍｏｏｆ）は、メディアデータボックス（ｍｄａｔ）に対するメタデータを含むことができる。メディアデータボックス（ｍｄａｔ）は、当該メディア構成要素（ビデオ及びオーディオなど）に対する実際メディアデータを含むことができる。

自己−初期化セグメントは、初期化セグメントの情報及びメディアセグメントの情報の両方を含むオブジェクト形態のデータ単位を意味する。

＜伝送オブジェクトタイプの識別方案−２＞
図４３は、本発明の他の実施例に係るオブジェクトタイプ情報を含むパケットの構造を示す図である。

上述した方法に加えて、オブジェクトタイプ情報は、ＬＣＴヘッダー拡張を用いて、現在パケットが送信しているオブジェクトのタイプを識別することができる。ＬＣＴヘッダー拡張を用いるオブジェクトタイプ情報は、ＲＴＰ（ｒｅａｌｔｉｍｅｐｒｏｔｏｃｏｌ）などを含む伝送プロトコルのためのパケットなどに適用することができる。

オブジェクトタイプ情報は、ヘッダー拡張タイプ（ＨＥＴ）フィールド、タイプフィールド、及び／又は予約フィールドを含むことができる。

ＨＥＴフィールドは８ビットの整数であってもよく、当該ヘッダー拡張のタイプを示すことができる。例えば、ＨＥＴフィールドは、１２８〜２５５の値の中から一つの固有値で当該ヘッダー拡張のタイプを識別することができ、この場合、ヘッダー拡張は、３２ビットの固定長を有することができる。

タイプフィールドは、現在ＬＣＴパケット又は同一ＴＯＩが与えられたＬＣＴパケットが送信しているオブジェクトのタイプを示すことができる。以下では、タイプフィールドをオブジェクトタイプ情報と表現することができる。ＭＰＥＧ−ＤＡＳＨコンテンツをＬＣＴパケットで伝送する場合、オブジェクトタイプ情報の値によって、オブジェクトタイプは、レギュラーファイル、初期化セグメント、メディアセグメント、及び自己−初期化セグメントを含むことができる。

例えば、オブジェクトタイプ情報の値が“０ｘ００”であれば、オブジェクトタイプは“レギュラーファイル”を示し、オブジェクトタイプ情報の値が“０ｘ０１”であれば、オブジェクトタイプは“初期化セグメント”を示し、オブジェクトタイプ情報の値が“０ｘ１０”であれば、オブジェクトタイプは“メディアセグメント”を示し、オブジェクトタイプ情報の値が“０ｘ１１”であれば、オブジェクトタイプは“自己−初期化セグメント”を示すことができる。

予約フィールドは、将来の使用のために予約されたフィールドであってもよい。

以下、具体的な内容は上述したとおりであり、その説明を省略する。

図４４は、本発明の他の実施例に係るオブジェクトタイプ情報を用いる放送信号受信装置の構造を示す図である。

放送信号受信装置は、オブジェクトタイプ情報に基づいてオブジェクトのタイプにしたがって別々の手順を行うことができる。すなわち、放送信号送信装置がＬＣＴパケットにオブジェクトタイプ情報を明示して伝送すると、放送信号受信装置は、オブジェクトタイプ情報に基づいて、受信したオブジェクトを識別し、オブジェクトのタイプ別に適切な動作を行うことができる。

本発明の他の実施例に係る放送信号受信装置は、シグナリングデコーダＣ３２００５、パーサーＣ３２０５０、及び／又はデコーダＣ３２０６０を含むことができる。ただし、放送信号受信装置の構成要素はこれに限定されず、上述した構成要素をさらに含んでもよい。

シグナリングデコーダＣ３２００５は、シグナリング情報をデコードすることができる。シグナリング情報は、マルチメディアコンテンツを含む放送信号を放送網を介して実時間で伝送するか否かを示す情報である。

パーサーＣ３２０５０は、オブジェクトタイプ情報に基づいて少なくとも一つのオブジェクトをパースし、リプレゼンテーションに接近するための初期化情報及び少なくとも一つのアクセスユニットを生成することができる。そのために、パーサーＣ３２０５０は、初期化セグメントパーサーＣ３２０５１、メディアセグメントパーサーＣ３２０５２、及び／又は自己−初期化セグメントパーサーＣ３２０５３を含むことができる。初期化セグメントパーサーＣ３２０５１、メディアセグメントパーサーＣ３２０５２、及び自己−初期化セグメントパーサーＣ３２０５３に関する具体的な説明は、次の図面で後述する。

デコーダＣ３２０６０は、初期化情報に基づいて当該デコーダＣ３２０６０を初期化することができる。また、デコーダＣ３２０６０は、少なくとも一つのオブジェクトを復号化することができる。このとき、デコーダＣ３２０６０は、オブジェクトに関する情報を少なくとも一つのアクセスユニットの形態で受信し、デコーダＣ３２０６０は、少なくとも一つのアクセスユニットを復号化してメディアデータを生成することができる。

図４５は、本発明の他の実施例に係るオブジェクトタイプ情報を用いる放送信号受信装置の構造を示す図である。

放送信号受信装置は、パケットフィルタＣ３２０１０、セグメントバッファＣ３２０３０、パーサーＣ３２０５０、デコーディングバッファＣ３２０５９、及び／又はデコーダＣ３２０６０を含むことができる。

パケットフィルタＣ３２０１０は、受信された少なくとも一つのパケットからオブジェクトタイプ情報を識別し、オブジェクトタイプ情報に基づいて、それぞれのオブジェクトのタイプに該当する手順を行えるように分類することができる。

例えば、オブジェクトタイプ情報が“１”であれば、パケットフィルタＣ３２０１０は、ＬＣＴパケットのデータをセグメントバッファＣ３２０３１を介して初期化セグメントパーサーＣ３２０５１に伝達し、オブジェクトタイプ情報が“２”であれば、パケットフィルタＣ３２０１０は、ＬＣＴパケットのデータをセグメントバッファＣ３２０３２を介してメディアセグメントパーサーＣ３２０５２に伝達し、伝送オブジェクトタイプ情報が“３”であれば、パケットフィルタＣ３２０１０は、ＬＣＴパケットのデータをセグメントバッファＣ３２０３３を介して自己−初期化セグメントパーサーＣ３２０５３に伝達することができる。

セグメントバッファＣ３２０３０は、パケットフィルタからＬＣＴパケットのデータを受け取って、あらかじめ定められた時間記憶することができる。セグメントバッファＣ３２０３０は、一つの構成要素で構成されてもよく、複数のセグメントバッファＣ３２０３１，Ｃ３２０３２，Ｃ３２０３３で構成されてもよい。

パーサーＣ３２０５０は、オブジェクトタイプ情報に基づいて少なくとも一つのオブジェクトをパースし、リプレゼンテーションに接近するための初期化情報及び少なくとも一つのアクセスユニットを生成することができる。そのために、パーサーＣ３２０５０は、初期化セグメントパーサーＣ３２０５１、メディアセグメントパーサーＣ３２０５２、及び／又は自己−初期化セグメントパーサーＣ３２０５３を含むことができる。

初期化セグメントパーサーＣ３２０５１は、セグメントバッファＣ３２０３１に記憶された初期化セグメントをパースし、リプレゼンテーションに接近するための初期化情報を生成することができる。また、初期化セグメントパーサーＣ３２０５１は、自己−初期化セグメントパーサーＣ３２０５３から初期化セグメントを受け取って、リプレゼンテーションに接近するための初期化情報を生成することができる。

メディアセグメントパーサーＣ３２０５２は、セグメントバッファＣ３２０３２に記憶されたメディアセグメントをパースし、メディアストリームの情報、少なくとも一つのアクセスユニット、及びプレゼンテーション時間又はインデックスのような当該セグメント内のメディアプレゼンテーションへの接近方法に関する情報を生成することができる。また、メディアセグメントパーサーＣ３２０５２は、自己−初期化セグメントパーサーＣ３２０５３からメディアセグメントを受け取って、メディアストリームの情報、少なくとも一つのアクセスユニット、及びプレゼンテーション時間又はインデックスのような当該セグメント内のメディアプレゼンテーションへの接近方法に関する情報を生成することができる。

自己−初期化セグメントパーサーＣ３２０５３は、セグメントバッファＣ３２０３３に記憶された自己−初期化セグメントをパースし、初期化セグメント及びメディアセグメントを生成することができる。

デコーディングバッファＣ３２０５９は、パーサーＣ３２０５０又はメディアセグメントパーサーＣ３２０５２から少なくとも一つのアクセスユニットを受け取って、あらかじめ定められた時間記憶することができる。

デコーダＣ３２０６０は、初期化情報に基づいて当該デコーダＣ３２０６０を初期化することができる。また、デコーダＣ３２０６０は、少なくとも一つのオブジェクトを復号化することができる。このとき、デコーダＣ３２０６０は、オブジェクトに関する情報を少なくとも一つのアクセスユニットの形態で受信し、少なくとも一つのアクセスユニットを復号化してメディアデータを生成することができる。

上述したように、ＭＰＥＧ−ＤＡＳＨコンテンツを伝送する時、本発明の他の実施例に係る放送信号送信装置は、現在パケットで送信しているオブジェクトのタイプを示すオブジェクトタイプ情報を伝送することができる。また、放送信号受信装置は、オブジェクトタイプ情報に基づいて、受信したパケットからオブジェクトの類型を識別し、各オブジェクトに適切なプロセスを行うことができる。

＜オブジェクト内部構造体のタイプ＞
図４６は、本発明の他の実施例に係るタイプ情報を含むパケットの構造を示す図である。

放送信号送信装置が、独立して有意な単位であるオブジェクト内部構造体（ＯｂｊｅｃｔＩｎｔｅｒｎａｌＳｔｒｕｃｔｕｒｅ）の単位でデータを伝送すると、可変サイズでデータを伝送することができる。したがって、放送信号受信装置が一つのオブジェクトを全て受信する前であっても、オブジェクト内部構造体を受信及び識別すると、放送信号受信装置はオブジェクト内部構造体単位で再生することができる。その結果、マルチメディアコンテンツを放送網を介して実時間で伝送及び再生することができる。本発明の他の実施例によれば、オブジェクト内部構造体を識別するために、タイプ情報（Ｔｙｐｅｉｎｆｏｒｍａｔｉｏｎ）及び境界情報（ＢｏｕｎｄａｒｙＩｎｆｏｒｍａｔｉｏｎ）を用いることができる。

以下では、オブジェクト内部構造体を識別するためのタイプ情報について具体的に説明する。

ＭＰＥＧ−ＤＡＳＨコンテンツを伝送するとき、パケット情報は、ＬＣＴヘッダー拡張を用いてタイプ情報を含むことができる。タイプ情報は、現在パケットが送信しているオブジェクトの内部構造体のタイプを示すことができる。タイプ情報は、オブジェクトタイプ情報との区別のために、内部構造体タイプ情報と呼ぶことができる。タイプ情報は、ＲＴＰ（ｒｅａｌｔｉｍｅｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用することができる。

タイプ情報は、ヘッダー拡張タイプフィールド（ＨＥＴ）、内部ユニットタイプフィールド、及び／又は予約フィールドを含むことができる。

ＨＥＴフィールドは上述したとおりであり、その具体的な説明は省略する。

内部構造体タイプフィールドは、ＬＣＴパケットが送信しているオブジェクト内部構造体のタイプを示すことができる。

オブジェクトはＭＰＥＧ−ＤＡＳＨのセグメントに該当し得るが、オブジェクト内部構造体は、オブジェクトを構成する下位構成要素に該当する。例えば、オブジェクト内部構造体のタイプは、フラグメント、チャンク（ｃｈｕｎｋ）又はＧＯＰ、アクセスユニット、及びＮＡＬユニットを含むことができる。オブジェクト内部構造体のタイプは、これに限定されず、有意な単位をさらに含んでもよい。

フラグメントとは、以前（ｐｒｅｃｅｄｉｎｇ）のデータに対する依存性無しで独立して復号化及び再生可能なデータ単位を意味する。又は、フラグメントは、一対のムービーフラグメントボックス（ｍｏｏｆ）及びメディアデータコンテナボックス（ｍｄａｔ）を含むデータ単位を意味してもよい。例えば、フラグメントは、ＭＰＥＧ−ＤＡＳＨのサブセグメント（Ｓｕｂｓｅｇｍｅｎｔ）に該当してもよく、ＭＭＴのフラグメントに該当してもよい。フラグメントは、少なくとも一つのチャンク又は少なくとも一つのＧＯＰを含むことができる。

チャンクは、同じメディアタイプを有する隣接したサンプルの集合であり、可変サイズのデータ単位である。

ＧＯＰは、ビデオコーディングで用いられるコーディングを行う基本単位であり、少なくとも一つのＩ−フレームを含むフレームの集合を示す可変サイズのデータ単位である。本発明の他の実施例によれば、メディアデータを独立して有意なデータ単位であるオブジェクト内部構造体の単位で伝送するので、ＧＯＰはオープンＧＯＰ及びクローズドＧＯＰを含むことができる。

オープンＧＯＰで、一つのＧＯＰ内にあるＢ−フレームは、隣接したＧＯＰのＩ−フレーム又はＰ−フレームを参照することができる。したがって、オープンＧＯＰは、コーディング効率を大きく向上させることができる。クローズドＧＯＰで、Ｂ−フレーム又はＰ−フレームは、当該ＧＯＰ内にあるフレームだけを参照し、当該ＧＯＰ外にあるフレームは参照しない。

アクセスユニットは、符号化されたビデオ又はオーディオの基本データ単位を意味し、一つの映像フレーム又はオーディオフレームを含むことができる。

ＮＡＬユニットは、ネットワーク機器との通信を考慮して圧縮されたスライスに関する要約情報などが含まれてカプセル化された圧縮されたビデオストリームである。例えば、ＮＡＬユニットスライス、パラメータセット、及びＳＥＩなどのデータをバイト単位でパケット化したデータ単位であってもよい。

以下では、説明の便宜のために、内部構造体タイプフィールドをタイプ情報と表現することができる。

＜オブジェクト内部構造体の境界＞
図４７は、本発明の他の実施例に係る境界情報を含むパケットの構造を示す図である。

以下では、オブジェクト内部構造体を識別するための境界情報について具体的に説明する。

ＭＰＥＧ−ＤＡＳＨコンテンツを伝送するとき、パケット情報は、ＬＣＴヘッダー拡張を用いて境界情報を含むことができる。境界情報は、現在パケットが送信しているオブジェクト内部構造体の境界を示すことができる。境界情報は、ＲＴＰ（ｒｅａｌｔｉｍｅｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用することができる。

境界情報は、ヘッダー拡張タイプフィールド（ＨＥＴ）、開始フラグフィールド（ＳＦ）、予約フィールド、及び／又はオフセットフィールドを含むことができる。

開始フラグフィールド（ＳＦ）は、ＬＣＴパケットがオブジェクト内部構造体の開始地点を含んでいるか否かを示すことができる。

オフセットフィールドは、ＬＣＴパケット内でオブジェクト内部構造体の開始地点の位置を示す位置情報を含むことができる。位置情報は、ＬＣＴパケットのペイロード開始地点からオブジェクト内部構造体の開始地点までのバイト（ｂｙｔｅ）距離を含むことができる。

上述したように、放送信号送信装置は、タイプ情報及び境界情報に基づいて、オブジェクト単位でデータを伝送しないで、可変長のオブジェクト内部構造体の単位でデータを伝送することができる。

放送信号受信装置は、オブジェクト単位でデータを受信して再生するのではなく、可変長のオブジェクト内部構造体の単位でデータを受信して再生することができる。したがって、放送信号受信装置は、タイプ情報及び境界情報に基づいてオブジェクト内部構造体を識別し、受信したオブジェクト内部構造体別に再生することができる。

例えば、放送信号受信装置は、境界情報で表現されたオブジェクト内部構造体の開始と終了地点に該当するパケット又はその間で伝送される少なくとも一つのパケットに含まれたタイプ情報に基づいて、現在オブジェクト内部構造体のタイプを識別することができる。

その結果、放送信号受信装置は、一つのオブジェクトを全て受信する前にも、オブジェクト内部構造体を迅速に識別することができ、実時間再生することができる。

＜伝送オブジェクトとシグナリング情報のマッピング＞
図４８は、本発明の他の実施例に係るマッピング情報を含むパケットの構造を示す図である。

本発明の他の実施例によれば、上述したタイプ情報及び境界情報の他にも、マッピング情報を用いてオブジェクト内部構造体を識別することができる。

ＤＡＳＨコンテンツを伝送するとき、パケット情報は、ＬＣＴヘッダー拡張を用いてマッピング情報を含むことができる。マッピング情報は、現在パケットが送信しているセッション、オブジェクト、及びオブジェクト内部構造体のうち少なくとも一つを、伝送セッション識別子（ＴＳＩ）及び伝送オブジェクト識別子（ＴＯＩ）のうち少なくとも一つにマップさせる情報である。マッピング情報は、ＲＴＰ（ｒｅａｌｔｉｍｅｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用することができる。

本発明の一実施例に係るマッピング情報は、ヘッダー拡張タイプフィールド（ＨＥＴ）、ヘッダー拡張長さフィールド（ＨＥＬ）、及びＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）フィールド（ＵＲＬ）を含むことができる。

ＨＥＬフィールドは、可変長のＬＣＴヘッダー拡張の全長を示す。基本的に、ＬＣＴではＨＥＴが０〜１２７の値を有する場合、３２ビットワード単位の可変長ヘッダー拡張が存在し、ＨＥＴフィールドに続くＨＥＬフィールドは、ＬＣＴヘッダー拡張の全長を３２ビットワード単位で示す。

ＵＲＬフィールドは可変長を有することができ、現在伝送中のセッション、オブジェクト、及びオブジェクト内部構造体のインターネット上の固有アドレスを含むことができる。

以下では、説明の便宜上、ＵＲＬフィールドをマッピング情報と表現することができる。

マッピング情報は、シグナリング情報のＵＲＬを示すことができる。また、マッピング情報は、セッション、オブジェクト、又はオブジェクト内部構造体の固有なアドレスだけでなく、シグナリング情報で割り当てられた識別子を含むことができる。識別子は、ピリオド（ｐｅｒｉｏｄ）ＩＤ、適応セットＩＤ、リプレゼンテーションＩＤ、及びコンポーネントＩＤを含むことができる。したがって、ＭＰＥＧ−ＤＡＳＨコンテンツの場合、マッピング情報は、セグメントＵＲＬ、リプレゼンテーションＩＤ、コンポーネントＩＤ、適応セットＩＤ、及びピリオド（ｐｅｒｉｏｄ）ＩＤなどを含むことができる。

より完璧なマッピングのために、本発明の他の実施例に係るシグナリング情報は、識別子又はオブジェクトのＵＲＬをＴＯＩ又はＴＳＩにそれぞれマップするマッピング情報をさらに含むことができる。すなわち、シグナリング情報は、現在送信しているＴＯＩ及びＴＳＩが、識別子又はオブジェクトのＵＲＬのいずれにマップされるかを示す情報をさらに含むことができる。このとき、マッピング情報は、識別子又はオブジェクトのＵＲＬとＴＯＩ又はＴＳＩとを、１：１、１：多、又は多：１のいずれかでマップする情報であってもよい。

＜伝送セッション及び伝送オブジェクトのグルーピング方案＞
図４９は、本発明の他の実施例に係るグルーピング情報を含むＬＣＴパケットの構造を示す図である。

本発明の他の実施例によれば、上述した方法の他にも、グルーピング情報を用いてオブジェクト内部構造体を識別することができる。

本発明の他の実施例に係るＬＣＴパケットは、セッショングループ識別子フィールド（ＳＧＩ）及び分割された伝送セッション識別子フィールド（ＤＴＳＩ）を含むことができる。ＳＧＩ及びＤＴＳＩは、既存の伝送セッション識別子フィールド（ＴＳＩ）を分割した形態である。

また、本発明の他の実施例に係るＬＣＴパケットは、オブジェクトグループ識別子フィールド（ＯＧＩ）及び分割された伝送オブジェクト識別子フィールド（ＤＴＯＩ）を含むことができる。ＯＧＩ及びＤＴＯＩは、既存の伝送オブジェクト識別子フィールド（ＴＯＩ）を分割した形態である。

Ｓフィールドは、既存のＴＳＩフィールドの長さを示し、Ｏフィールドは、既存のＴＯＩの長さを示し、Ｈフィールドは、既存のＴＳＩフィールド及び既存のＴＯＩフィールドの長さにハーフワード（１６ビット）を追加するか否かを示す。

したがって、ＳＧＩフィールドとＤＴＳＩフィールドとの全長は、既存のＴＳＩフィールドと同一であり、ＳフィールドとＨフィールドの値に基づいて定めることができる。また、ＯＧＩフィールドとＤＴＯＩフィールドとの全長は、既存のＴＯＩフィールドと同一であり、ＯフィールドとＨフィールドの値に基づいて定められてもよい。

本発明の他の実施例によれば、既存のＴＳＩ及びＴＯＩをＳＧＩ、ＤＴＳＩ、ＯＧＩ、及びＤＴＯＩに細分化し、ＳＧＩ、ＤＴＳＩ、ＯＧＩ、及びＤＴＯＩはそれぞれ異なるデータ単位を識別することができる。

ＳＧＩ、ＤＴＳＩ、ＯＧＩ、及びＤＴＯに関する具体的な内容は、次の図面で後述する。

図５０は、本発明の他の実施例に係るセッション及びオブジェクトのグルーピングを示す図である。

メディアプレゼンテーション記述（ＭＰＤ）は、ＭＰＥＧ−ＤＡＳＨコンテンツをストリーミングサービスとして提供するためのエレメントである。例えば、上述したプレゼンテーションは、一つのサービスに対応する概念であり、ＭＰＥＧ−ＤＡＳＨのＭＰＤ及びＭＭＴのパッケージに該当してもよい。ＭＰＤＣ４００００は、少なくとも一つのピリオドを含むことができる。例えば、ＭＰＤＣ４００００は、第１ピリオドＣ４１０００及び第２ピリオドＣ４２０００を含むことができる。

ピリオドは、ＭＰＥＧ−ＤＡＳＨコンテンツを再生時間で区分したエレメントである。利用可能なビットレート、言語、キャプション、及びサブタイトルなどはピリオド内で変わらない。各ピリオドは開始時間情報を含むことができ、ＭＰＤ内で開始時間の昇順で整列されてもよい。例えば、第１ピリオドＣ４１０００は、０〜３０ｍｉｎ区間のエレメントであり、第２ピリオドＣ４２０００は、３０〜６０ｍｉｎ区間のエレメントである。ピリオドは、下位要素として少なくとも一つのＡｄａｐｔａｔｉｏｎＳｅｔ（図示せず）を含むことができる。

ＡｄａｐｔａｔｉｏｎＳｅｔは、相互交替可能なエンコードされたバージョンの少なくとも一つのメディアコンテンツコンポーネントの集合である。ＡｄａｐｔａｔｉｏｎＳｅｔは、下位要素として少なくとも一つのリプレゼンテーションを含むことができる。例えば、ＡｄａｐｔａｔｉｏｎＳｅｔは、第１リプレゼンテーションＣ４１１００、第２リプレゼンテーションＣ４１２００、及び第３リプレゼンテーションＣ４１３００を含むことができる。

リプレゼンテーションは、少なくとも一つのメディアコンテンツコンポーネントの伝送可能なエンコードされたバージョンのエレメントを示し、少なくとも一つのメディアストリームを含むことができる。メディアコンテンツコンポーネントは、ビデオコンポーネント、オーディオコンポーネント、及びキャプションコンポーネントを含むことができる。リプレゼンテーションは、メディアコンテンツコンポーネントの品質に関する情報を含むことができる。したがって、放送信号受信装置は、ネットワーク環境に適応するために一つのＡｄａｐｔａｔｉｏｎＳｅｔ内でリプレゼンテーションを変更することができる。

例えば、第１リプレゼンテーションＣ４１１００は、周波数の帯域幅（ｂａｎｄｗｉｄｔｈ）が５００ｋｂｉｔ／ｓであるビデオコンポーネントであり、第２リプレゼンテーションＣ４１２００は、周波数の帯域幅が２５０ｋｂｉｔ／ｓであるビデオコンポーネントであり、第３リプレゼンテーションＣ４１３００は、周波数の帯域幅が７５０ｋｂｉｔ／ｓであるビデオコンポーネントであってもよい。リプレゼンテーションは、下位要素として少なくとも一つのセグメントを含むことができる。例えば、第１リプレゼンテーションＣ４１１００は、第１セグメントＣ４１１１０、第２セグメントＣ４１１２０、及び第３セグメントＣ４１１３０を含むことができる。

セグメントは、一度のＨＴＴＰ要求で検索（ｒｅｔｒｉｅｖｅ）可能な最大のデータ単位のエレメントを示す。ＵＲＬは、それぞれのセグメントに提供されてもよい。例えば、上述したオブジェクトは、ファイル、初期化セグメント、メディアセグメント、又は自己−初期化セグメントに対応する概念であり、ＭＰＥＧ−ＤＡＳＨのセグメントに該当し、ＭＭＴのＭＰＵに該当し得る。各セグメントは、下位要素として少なくとも一つのフラグメントを含むことができる。例えば、第２セグメントＣ４１１２０は、第１フラグメントＣ４１１２２、第２フラグメントＣ４１１２４、及び第３フラグメントＣ４１１２６を含むことができる。

フラグメントは、以前（ｐｒｅｃｅｄｉｎｇ）のデータに対する依存性無しで独立して復号化及び再生可能なデータ単位を意味する。例えば、フラグメントは、ＭＰＥＧ−ＤＡＳＨのサブセグメント（Ｓｕｂｓｅｇｍｅｎｔ）及びＭＭＴのフラグメントに該当し得る。フラグメントは、少なくとも一つのチャンク又は少なくとも一つのＧＯＰを含むことができる。例えば、第１フラグメントＣ４１１２２は、フラグメントヘッダー及びフラグメントペイロードを含むことができる。フラグメントヘッダーは、セグメントインデックスボックス（ｓｉｄｘ）及びムービーフラグメントボックス（ｍｏｏｆ）を含むことができる。フラグメントペイロードは、メディアデータコンテナボックス（ｍｄａｔ）を含むことができる。メディアデータコンテナボックス（ｍｄａｔ）は、第１チャンク乃至第５チャンクを含むことができる。

上述した本発明の一実施例によれば、ＴＳＩが伝送セッションを識別し、各リプレゼンテーションを各ＴＳＩにマップすることができる。ＴＯＩが伝送セッション内にある伝送オブジェクトを識別し、各セグメントを各ＴＯＩにマップすることができる。

一方、本発明の他の実施例によれば、ＴＳＩをＧＳＩ及びＤＴＳＩに分割し、ＴＯＩをＯＧＩ及びＤＴＯＩに分割して、それぞれのＧＳＩ、ＤＴＳＩ、ＧＯＩ、及びＤＴＯＩをそれぞれ新しいデータ単位にマップしてもよいが、以下の実施例に限定されない。

例えば、ＳＧＩは同一の伝送セッションのグループを識別し、各ピリオドは各ＳＧＩにマップされてもよい。第１ピリオドＣ４１０００は、ＳＧＩの値が“１”にマップされ、第２ピリオドＣ４２０００は、ＳＧＩの値が“２”にマップされてもよい。ＳＧＩの値は、上述した実施例に限定されず、ピリオドを識別する値であるピリオドＩＤと同じ値を有することができる。

ＤＴＳＩは伝送セッションを識別し、各リプレゼンテーションは各ＤＴＳＩにマップされてもよい。第１リプレゼンテーションＣ４１１００は、ＤＴＳＩの値が“１”にマップされ、第２リプレゼンテーションＣ４１２００は、ＤＴＳＩの値が“２”にマップされ、第３リプレゼンテーションＣ４１３００は、ＤＴＳＩの値が“３”にマップされてもよい。ＤＴＳＩの値は、上述した実施例に限定されず、リプレゼンテーションを識別する値であるリプレゼンテーションＩＤと同じ値を有することができる。

ＯＧＩは、伝送セッション内で同一のオブジェクトのグループを識別し、各セグメントは各ＯＧＩにマップされてもよい。第１セグメントＣ４１１１０は、ＯＧＩの値が“１”にマップされ、第２セグメントＣ４１１２０は、ＯＧＩの値が“２”にマップされ、及び第３セグメントＣ４１１３０は、ＯＧＩの値が“３”にマップされてもよい。

ＤＴＯＩはデリバリオブジェクト（ＤｅｌｉｖｅｒｙＯｂｊｅｃｔ）を識別することができる。一つのデリバリオブジェクトは、一つのＩＳＯＢＭＦＦファイル又は一つのＩＳＯＢＭＦＦファイルの一部であってもよい。一つのＩＳＯＢＭＦＦファイルの一部は、フラグメント、ＧＯＰ、チャンク、アクセスユニット、及び／又はＮＡＬユニットを含むことができる。

例えば、フラグメントヘッダー、及びフラグメントペイロードの各チャンク又は各ＧＯＰは、各ＤＴＯＩにマップされてもよい。第１フラグメントＣ４１１２２のヘッダーは、ＤＴＯＩの値が“０”にマップされ、第１フラグメントＣ４１１２２のペイロード内にある第１チャンク乃至第５チャンクは、ＤＴＯＩの値が“１０”乃至“１４”にマップされてもよい。

ＤＴＯＩの場合、与えられた値によって用法を定義することができる。例えば、ＤＴＯＩ値は、オブジェクトの配列順序にしたがって昇順又は降順の値に設定することができる。この場合、放送信号受信装置は、ＤＴＯＩ値に基づいてオブジェクトを再配列し、フラグメント又はセグメントを生成することができる。また、特定のＤＴＯＩの値はフラグメントヘッダーを示すことができる。この場合、放送信号送信装置又は放送信号受信装置は、当該ＤＴＯＩの値に基づいてフラグメントヘッダーの伝送が完了したか否かを判断することができる。

デリバリオブジェクトが一つのセグメントを意味する場合、デリバリオブジェクトのグループは、ＤＡＳＨリプレゼンテーションのようなコンテンツコンポーネントに該当してもよい。この場合、ＤＴＯＩはセグメントにマップされ、ＯＧＩはリプレゼンテーションにマップされてもよい。例えば、ＯＧＩはリプレゼンテーションＩＤ、コンテンツコンポーネントＩＤなどに一対一マップされて、一つのセッション内で伝送されるコンテンツコンポーネントをマルチプレクス／デマルチプレクスするための情報として用いられてもよい。

図５１は、本発明の他の実施例に係るパケット情報を用いた放送信号送信装置の構造を示す図である。

放送信号送信装置は、シグナリングエンコーダＣ３１００５、内部構造体生成器Ｃ３１０３０、パケット情報生成器Ｃ３１０３５及び／又は送信器Ｃ３１０５０を含むことができる。

シグナリングエンコーダＣ３１００５は、マルチメディアコンテンツを含む放送信号を放送網を介して実時間で伝送するか否かを示すシグナリング情報を生成することができる。シグナリング情報は、ファイルレベル又はＦＤＴレベルのうち少なくとも一つでマルチメディアコンテンツを実時間で送信することを示すことができる。シグナリング情報がファイルレベルでマルチメディアコンテンツを実時間で送信することを示すと、当該ファイルに属する全データを実時間で伝送することができる。また、シグナリング情報がＦＤＴレベルでマルチメディアコンテンツを実時間で送信することを示すと、当該ＦＤＴに属する全ファイル又はデータを実時間で伝送することができる。

内部構造体生成器Ｃ３１０３０は、独立して符号化及び復号化されるデータ単位である少なくとも一つのオブジェクト内部構造体を生成することができる。オブジェクト内部構造体は、マルチメディアコンテンツを構成するファイルが少なくとも一つのデータ単位で分割されたものである。

パケット情報生成器Ｃ３１０３５は、シグナリング情報がマルチメディアコンテンツを実時間で送信することを示す場合、オブジェクト内部構造体を識別するメタデータを含むパケット情報を生成することができる。ここで、パケット情報は、マルチメディアコンテンツを送信するパケットに関するメタデータを含み、オブジェクト内部構造体を識別するメタデータを含むことができる。パケット情報は、オブジェクト内部構造体の境界を示す境界情報、及びオブジェクト内部構造体のタイプを示すタイプ情報を含むことができる。

境界情報は、当該パケットにオブジェクト内部構造体の開始地点が含まれているか否かを示す開始フラグ（ＳＦ）フィールド、及び当該パケット内で上記オブジェクト内部構造体の開始地点の位置を示すオフセットフィールドを含むことができる。

オブジェクト内部構造体のタイプは、一対のムービーフラグメントボックス（ｍｏｏｆ）及びメディアデータコンテナボックス（ｍｄａｔ）を含むデータ単位を示すフラグメント、同一のメディアタイプを有する隣接したサンプルの集合を示すチャンク、少なくとも一つのＩ−フレームを含むフレームの集合を示すＧＯＰ、符号化されたビデオ又はオーディオの基本データ単位を示すアクセスユニット、及びバイト（ｂｙｔｅ）単位でパケット化したデータ単位を示すＮＡＬユニットのうち一つを含むことができる。

また、パケット情報は、セッション、オブジェクト、及びオブジェクト内部構造体のうち少なくとも一つを伝送セッション識別子（ＴＳＩ）及び伝送オブジェクト識別子（ＴＯＩ）のうち少なくとも一つにマップさせるマッピング情報を含むことができる。

また、パケット情報は、パケットが送信する伝送オブジェクト及び伝送セッションをグルーピングするグルーピング情報を含むことができる。グルーピング情報は、伝送セッションを識別する分割された伝送セッション識別子（ＤＴＳＩ）フィールド、同一の伝送セッションのグループを識別するセッショングループ識別子（ＳＧＩ）フィールド、伝送オブジェクトを識別する分割された伝送オブジェクト識別子（ＤＴＯＩ）フィールド、及び同一の伝送オブジェクトのグループを識別するオブジェクトグループ識別子（ＯＧＩ）フィールドを含むことができる。ここで、ＳＧＩフィールドは、ＭＰＥＧ−ＤＡＳＨのピリオドエレメントを識別する情報を含み、ＤＴＳＩフィールドは、ＭＰＥＧ−ＤＡＳＨのリプレゼンテーションエレメントを識別する情報を含み、ＯＧＩフィールドは、ＭＰＥＧ−ＤＡＳＨのセグメントエレメントを識別する情報を含み、及びＤＴＯＩフィールドは、ＭＰＥＧ−ＤＡＳＨのチャンクエレメントを識別する情報を含むことができる。

上述したように、パケット情報は、タイプ情報、境界情報、マッピング情報、及びグルーピング情報に基づいて、セッション、オブジェクト、及びオブジェクト内部構造体のうち少なくとも一つを識別することができる。

放送信号送信装置は、パケタイザ（図示せず）をさらに含むことができる。パケタイザは、オブジェクト内部構造体を同一サイズの少なくとも一つのシンボルに分割し、それぞれの少なくとも一つのシンボルを少なくとも一つのパケットにパケット化することができる。ただし、これに限定されず、シンボルは他の装置によって生成されてもよい。本発明の他の実施例に係るシンボルの長さは同一であってもよい。その後、パケタイザは、少なくとも一つのシンボルを少なくとも一つのパケットにパケット化することができる。例えば、パケットはＬＣＴパケットであってもよい。パケットはパケットヘッダー及びパケットペイロードを含むことができる。

パケットヘッダーは、オブジェクト内部構造体を識別するパケット情報を含むことができる。

送信器Ｃ３１０５０は、オブジェクト内部構造体及びパケット情報を含む放送信号を伝送することができる。

図５２は、本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。

以下では、放送信号送信装置と共通する部分は省略し、相違点を中心に説明する。

放送信号受信装置は、パケット情報に基づいてオブジェクト内部構造体を識別し、受信したオブジェクト内部構造体単位で復号化を行うことができる。したがって、放送信号受信装置は、一つのオブジェクトを全て受信しないで、オブジェクト内部構造体だけを受信することでも、オブジェクト内部構造体を再生することができる。

本発明の他の実施例に係る放送信号受信装置は、シグナリングデコーダＣ３２００５、抽出器Ｃ３２０５０、及び／又はデコーダＣ３２０６０を含むことができる。ただし、放送信号受信装置は、上述した構成要素をさらに含んでもよい。

抽出器Ｃ３２０５０は、放送信号からオブジェクト内部構造体を識別し、オブジェクト内部構造体を抽出することができる。抽出器Ｃ３２０５０は、パケット情報に基づいて、一つのオブジェクトが全て受信される前であっても、オブジェクト内部構造体を抽出してデコーダＣ３２０６０に伝達することができる。ただし、オブジェクト内部構造体のタイプによって抽出器Ｃ３２０５０の動作が異なってもよい。上述したパーサーＣ３２０５０は、抽出器Ｃ３２０５０と同じ動作を行うことができ、抽出器Ｃ３２０５０をパーサーＣ３２０５０と表現してもよい。

抽出器Ｃ３２０５０は、タイプ情報及び境界情報に基づいて現在オブジェクト内部構造体のタイプを識別することができる。例えば、抽出器Ｃ３２０５０は、境界情報で表現されたオブジェクト内部構造体の開始と終了地点に該当するパケット又はその間で伝送される少なくとも一つのパケットに含まれたタイプ情報に基づいて、現在オブジェクト内部構造体のタイプを識別することができる。

抽出器Ｃ３２０５０は、オブジェクトバッファ又はセグメントバッファに記憶されたオブジェクト内部構造体であるフラグメント、チャンク又はＧＯＰ、及びアクセスユニットのうち少なくとも一つを抽出することができる。そのために、抽出器Ｃ３２０５０は、アクセスユニットを抽出するＡＵ抽出器Ｃ３２０５６、チャンク又はＧＯＰを抽出するチャンク抽出器Ｃ３２０５７、及びフラグメントを抽出するフラグメント抽出器Ｃ３２０５８をさらに含むことができる。抽出器Ｃ３２０５０の下位構成要素は、次の図面で具体的に後述する。

デコーダＣ３２０６０は、オブジェクト内部構造体を受信し、タイプ情報に基づいて、当該オブジェクト内部構造体をデコードすることができる。このとき、デコーダＣ３２０６０は、オブジェクト内部構造体に関する情報を少なくとも一つのアクセスユニットの形態で受信し、少なくとも一つのアクセスユニットを復号化してメディアデータを生成することができる。

図５３は、本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。

以下では、オブジェクト内部構造体のタイプがアクセスユニットである場合の放送信号受信装置の動作及び構成について説明する。

放送信号受信装置は、パケットデパケタイザＣ２２０２０、セグメントバッファＣ３２０３０、ＡＵ抽出器Ｃ３２０５６、デコーディングバッファＣ３２０５９、及び／又はデコーダＣ３２０６０をさらに含むことができる。

パケットデパケタイザＣ２２０２０は、少なくとも一つのパケットをデパケット化して、パケットヘッダーに含まれたパケット情報を抽出することができる。例えば、パケットデパケタイザＣ２２０２０は、パケットヘッダーに含まれたタイプ情報及び境界情報を抽出することができ、パケットペイロードに含まれた少なくとも一つのシンボルを抽出することができる。少なくとも一つのシンボルは、オブジェクト内部構造体を構成するシンボルであってもよく、オブジェクトを構成するシンボルであってもよい。

パケットデパケタイザＣ２２０２０は、抽出した少なくとも一つのオブジェクト又は少なくとも一つのオブジェクト内部構造体をデコーダＣ３２０６０に伝達することができる。

セグメントバッファＣ３２０３０は、パケットデパケタイザＣ２２０２０からＬＣＴパケットのデータを受け取って、あらかじめ定められた時間記憶することができる。セグメントバッファＣ３２０３０は、オブジェクトバッファＣ３２０３０と表現することができる。また、セグメントバッファＣ３２０３０は、ＡＵ抽出器Ｃ３２０５６、チャンク抽出器（図示せず）、及び／又はフラグメント抽出器（図示せず）をさらに含むことができる。また、セグメントバッファＣ３２０３０は、フラグメントバッファ（図示せず）及び／又はチャンクバッファ（図示せず）をさらに含むことができる。

タイプ情報が、オブジェクト内部構造体のタイプがアクセスユニットであることを示すと、セグメントバッファＣ３２０３０は、ＡＵ抽出器Ｃ３２０５６を含むことができる。ただし、これに限定されず、ＡＵ抽出器Ｃ３２０５６はセグメントバッファＣ３２０３０と独立して存在してもよい。

ＡＵ抽出器Ｃ３２０５６は、境界情報に基づいてセグメントバッファＣ３２０３０に記憶されたアクセスユニットを抽出することができる。例えば、一つのアクセスユニットは、境界情報が示すアクセスユニットの開始地点から次のアクセスユニットの開始地点以前までであってもよい。

その後、ＡＵ抽出器Ｃ３２０５６は、抽出したアクセスユニットをデコーディングバッファＣ３２０５９を通してデコーダＣ３２０６０に伝達することができる。

上述したように、放送信号受信装置が一つのオブジェクトを全て受信しなくても、ＡＵ抽出器Ｃ３２０５６は、タイプ情報及び境界情報に基づいて、当該オブジェクトの内部構造体の受信が完了すると直ちにオブジェクト内部構造体を抽出し、デコーダＣ３２０６０に伝達することができる。

デコーディングバッファＣ３２０５９は、セグメントバッファＣ３２０３０からデータを受け取って、あらかじめ定められた時間記憶することができる。アクセスユニットは、デコーディングバッファＣ３２０５９内でアクセスユニットに与えられた処理時間にデコーダＣ３２０６０又は他の構成要素に伝達されてもよい。このとき、アクセスユニットに、ＰＴＳ（ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅｓｔａｍｐ）などの処理時間に対するタイミング情報は、ＬＣＴヘッダー拡張形態で与えられてもよい。

デコーダＣ３２０６０は、オブジェクト内部構造体を受信し、タイプ情報に基づいて当該オブジェクト内部構造体をデコードすることができる。このとき、デコーダＣ３２０６０は、オブジェクト内部構造体の形態だけでなく、アクセスユニットの形態で当該オブジェクト内部構造体を受信してもよい。

タイプ情報がオブジェクト内部構造体のタイプがアクセスユニットであることを示すと、デコーダＣ３２０６０は、当該オブジェクトを全て受信する前であっても、当該オブジェクトの内部構造体であるアクセスユニットをデコードすることができる。

図５４は、本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。

同図に示す構成要素のうち、上述した構成要素と同じ部分はその内容も同一であるため、その具体的な説明を省略する。

以下では、オブジェクト内部構造体のタイプがチャンク又はＧＯＰである場合の放送信号受信装置の動作及び構成について説明する。放送信号受信装置は、パケットデパケタイザＣ２２０２０、セグメントバッファＣ３２０３０、チャンクバッファＣ３２０３５、デコーディングバッファＣ３２０５９、及び／又はデコーダＣ３２０６０をさらに含むことができる。

パケットデパケタイザＣ２２０２０は、抽出した少なくとも一つのオブジェクト又は少なくとも一つのオブジェクト内部構造体を、セグメントバッファＣ３２０３０を通してデコーダＣ３２０６０に伝達することができる。

セグメントバッファＣ３２０３０は、チャンク抽出器Ｃ３２０５７を含むことができる。また、セグメントバッファＣ３２０３０はチャンクバッファＣ３２０３５をさらに含むことができる。

タイプ情報がオブジェクト内部構造体のタイプがチャンク又はＧＯＰであることを示すと、チャンク抽出器Ｃ３２０５７は、境界情報に基づいて、セグメントバッファＣ３２０３０に記憶されたチャンク又はＧＯＰを抽出することができる。例えば、一つのチャンク又はＧＯＰは、境界情報が示すチャンク又はＧＯＰの開始地点から次のチャンク又はＧＯＰの開始地点以前までであってもよい。チャンク抽出器Ｃ３２０５７は、セグメントバッファＣ３２０３０内に存在してもよく、独立して存在してもよい。

チャンクバッファＣ３２０３５は、少なくとも一つのチャンク又はＧＯＰを受け取って、あらかじめ定められた時間記憶することができる。チャンクバッファＣ３２０３５は、セグメントバッファＣ３２０３０内に存在してもよく、独立して存在してもよい。チャンクバッファＣ３２０３５は、ＡＵ抽出器Ｃ３２０５６をさらに含むことができる。

ＡＵ抽出器Ｃ３２０５６は、チャンクバッファＣ３２０３５に記憶されたチャンク又はＧＯＰから少なくとも一つのアクセスユニットを抽出することができる。その後、抽出された少なくとも一つのアクセスユニットをデコーディングバッファＣ３２０５９を通してデコーダＣ３２０６０に伝達することができる。

タイプ情報がオブジェクト内部構造体のタイプがチャンク又はＧＯＰであることを示すと、デコーダＣ３２０６０は、当該オブジェクトを全て受信する前であっても、当該オブジェクトの内部構造体であるチャンク又はＧＯＰをデコードすることができる。

図５５は、本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。

以下では、オブジェクト内部構造体のタイプがフラグメントである場合の放送信号受信装置の動作及び構成について説明する。放送信号受信装置は、パケットデパケタイザＣ２２０２０、セグメントバッファＣ３２０３０、フラグメントバッファＣ３２０３６、オーディオデコーディングバッファＣ３２０５９−１、ビデオデコーディングバッファＣ３２０５９−２、オーディオデコーダＣ３２０６０−１、及び／又はビデオデコーダＣ３２０６０−２をさらに含むことができる。

パケットデパケタイザＣ２２０２０は、抽出した少なくとも一つのオブジェクト又は少なくとも一つのオブジェクト内部構造体を、オーディオデコーダＣ３２０６０−１及び／又はビデオデコーダＣ３２０６０−２に伝達することができる。

セグメントバッファＣ３２０３００は、フラグメント抽出器Ｃ３２０５８を含むことができる。また、セグメントバッファＣ３２０３０は、フラグメントバッファＣ３２０３６をさらに含むことができる。

タイプ情報がオブジェクト内部構造体のタイプがフラグメントであることを示すと、フラグメント抽出器Ｃ３２０５８は、境界情報に基づいて、セグメントバッファＣ３２０３００に記憶されたフラグメントを抽出することができる。例えば、一つのフラグメントは、境界情報が示すフラグメントの開始地点から次のフラグメントの開始地点以前までであってもよい。フラグメント抽出器Ｃ３２０５８は、セグメントバッファＣ３２０３０内に存在してもよく、独立して存在してもよい。

フラグメントバッファＣ３２０３６はフラグメントを受け取って、あらかじめ定められた時間記憶することができる。フラグメントバッファＣ３２０３６は、セグメントバッファＣ３２０３０内に存在してもよく、独立して存在してもよい。フラグメントバッファＣ３２０３６は、ＡＵ抽出器Ｃ３２０５６をさらに含むことができる。また、フラグメントバッファＣ３２０３６はチャンクバッファ（図示せず）をさらに含むことができる。

ＡＵ抽出器Ｃ３２０５６は、フラグメントバッファＣ３２０３６に記憶されたフラグメントから少なくとも一つのアクセスユニットを抽出することができる。ＡＵ抽出器Ｃ３２０５６は、フラグメントバッファＣ３２０３６内に存在してもよく、独立して存在してもよい。また、放送信号受信装置は、チャンクバッファ（図示せず）をさらに含み、ＡＵ抽出器Ｃ３２０５６は、チャンクバッファに含まれたチャンク又はＧＯＰから少なくとも一つのアクセスユニットを抽出することができる。その後、ＡＵ抽出器Ｃ３２０５６は、抽出された少なくとも一つのアクセスユニットをオーディオデコーダＣ３２０６０−１及び／又はビデオデコーダＣ３２０６０−２に伝達することができる。

デコーディングバッファは、オーディオデコーディングバッファＣ３２０５９−１及び／又はビデオデコーディングバッファＣ３２０５９−２を含むことができる。オーディオデコーディングバッファＣ３２０５９−１は、オーディオに関連したデータを受信し、あらかじめ定められた時間記憶することができる。ビデオデコーディングバッファＣ３２０５９−２は、ビデオに関連したデータを受信し、あらかじめ定められた時間記憶することができる。

タイプ情報がオブジェクト内部構造体のタイプがフラグメントであることを示すと、デコーダは、当該オブジェクトを全て受信する前であっても、当該オブジェクトの内部構造体であるフラグメントをデコードすることができる。デコーダは、オーディオに関連したデータをデコードするオーディオデコーダＣ３２０６０−１及び／又はビデオに関連したデータをデコードするビデオデコーダＣ３２０６０−２をさらに含むことができる。

上述したように、放送信号送信装置は、オブジェクト単位でデータを伝送せず、可変長のオブジェクト内部構造体でデータを伝送することができる。このとき、放送信号送信装置は、送信するオブジェクト内部構造体のタイプ情報及び境界情報を共に伝送することができる。

放送信号受信装置は、オブジェクト単位でデータを受信して再生するのではなく、可変長のオブジェクト内部構造体でデータを受信して再生することができる。したがって、放送信号受信装置は、タイプ情報及び境界情報に基づいて、オブジェクト内部構造体を識別し、受信したオブジェクト内部構造体別に再生することができる。

＜伝送パケットペイロードデータの優先順位識別方案＞
図５６は、本発明の他の実施例に係る優先順位情報を含むパケットの構造を示す図である。

本発明の他の実施例に係るパケットはＲＯＵＴＥパケットであってもよく、ＲＯＵＴＥパケットは、ＡＬＣ／ＬＣＴパケットを表すことができる。ただし、以下では、便宜上、ＲＯＵＴＥパケット及び／又はＡＬＣ／ＬＣＴパケットをＬＣＴパケットと呼ぶものとする。ＲＯＵＴＥによって用いられるＬＣＴパケットフォーマットは、ＡＬＣパケットフォーマット、すなわち、ＬＣＴヘッダーが続くＵＤＰヘッダー及びパケットペイロードが続くＦＥＣペイロードＩＤに従う。

ＬＣＴパケットは、パケットヘッダー及びパケットペイロードを含むことができる。パケットヘッダーは、パケットペイロードに対するメタデータを含むことができる。パケットペイロードは、ＭＰＥＧ−ＤＡＳＨコンテンツのデータを含むことができる。

例えば、パケットヘッダーは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、及び／又はＦＥＣペイロードＩＤフィールドを含むことができる。

また、パケットペイロードはシンボルエンコーディングフィールドを含むことができる。

本発明の他の実施例に係るＬＣＴパケットを構成する各フィールドのうち、前述したフィールドと同じ名称のフィールドは、前述した内容を全て含むことができ、その具体的な説明は前述した説明に代える。

パケットヘッダーは、パケットペイロードの優先順位（Ｐｒｉｏｒｉｔｙ）を示す優先順位情報（Ｐｒｉｏｒｉｔｙ）をさらに含むことができる。優先順位情報は、各パケットの開始地点から１２番目及び１３番目のビットに位置する２ビットを用いてパケットペイロードの優先順位を示すことができる。この場合、２ビットを用いるので、パケットヘッダーのサイズを減らすことができ、効率性を高めることができる。

優先順位情報（Ｐｒｉｏｒｉｔｙ）は、一つのファイルに含まれたＬＣＴパケットのうち、現在ＬＣＴパケットで送信しているパケットペイロードの優先順位を示すことができる。すなわち、優先順位情報は、同一のＴＳＩ又はＴＯＩが与えられたパケットのうち、現在ＬＣＴパケットで送信しているパケットペイロードの相対的優先順位を示すことができる。

例えば、優先順位情報は０〜３の範囲の値を有することができる。優先順位情報が低い値を有するほど、パケットペイロードが全ファイルベースメディアデータを処理する際に優先順位が高いということを示すことができる。逆に、優先順位情報が高い値を有するほど、優先順位が低いということを示すことができる。

ＴＳＩはＬＣＴ伝送セッションを識別することができ、ＴＯＩはデリバリオブジェクト（ＤｅｌｉｖｅｒｙＯｂｊｅｃｔ）を識別することができる。

各ＲＯＵＴＥセッションは、１つ又は複数のＬＣＴ伝送セッションで構成される。ＬＣＴ伝送セッションは、ＲＯＵＴＥセッションのサブセットである。メディア伝達のために、ＬＣＴ伝送セッションは一般に、メディアコンポーネント、例えば、ＭＰＥＧ−ＤＡＳＨリプレゼンテーションを伝達することができる。ブロードキャストＭＰＥＧ−ＤＡＳＨの観点から、ＲＯＵＴＥセッションは、一つ以上のＤＡＳＨメディアプレゼンテーションの構成メディアコンポーネントを送信するＬＣＴ伝送セッションのマルチプレクスとして見なされてもよい。それぞれのＬＣＴ伝送セッション内で、１つ又は複数のデリバリオブジェクト、一般に、関連したデリバリオブジェクト、例えば、一つのリプレゼンテーションに関連したＭＰＥＧ−ＤＡＳＨセグメントが伝達される。それぞれのデリバリオブジェクトと共に、メタデータ特性が伝達され、デリバリオブジェクトがアプリケーションで用いられてもよい。

一つのデリバリオブジェクト（ＤｅｌｉｖｅｒｙＯｂｊｅｃｔ）は、一つのＩＳＯＢＭＦＦファイル又は一つのＩＳＯＢＭＦＦファイルの一部であってもよい。一つのＩＳＯＢＭＦＦファイルの一部は、フラグメント、ＧＯＰ、チャンク、アクセスユニット、及び／又はＮＡＬユニットを含むことができる。

一実施例として、一つのＴＳＩが一つのトラック（ＭＰＥＧ−ＤＡＳＨリプレゼンテーション）にマッチされ、一つのＴＯＩが一つのＩＳＯＢＭＦＦファイルにマッチングされてもよい。また、一つのＩＳＯＢＭＦＦファイルは、‘ｆｔｙｐ’、‘ｍｏｏｖ’、“ｍｏｏｆ”、及び／又は‘ｍｄａｔ’を含むことができる。

‘ｆｔｙｐ’は、ファイルタイプ及び互換性（ｃｏｍｐａｔａｂｉｌｉｔｙ）に関する情報を含んでいるコンテナ（ｃｏｎｔａｉｎｅｒ）である。‘ｍｏｏｖ’は、メディアデータを再生するための全メタデータ（ｍｅｔａｄａｔａ）を含むコンテナである。メディアコンテンツが一つのファイル内で少なくとも一つのメディアデータに分割されたり、又はメディアコンテンツが少なくても一つのファイルに分割された場合、‘ｍｏｏｆ’は、それぞれの分割されたメディアデータに対するメタデータを含むコンテナである。‘ｍｄａｔ’は、オーディオデータ及びビデオデータのようなメディアデータを含む。‘ｍｄａｔ’は、少なくとも一つの‘Ｉ−フレーム’、‘Ｐ−フレーム’、及び／又は‘Ｂ−フレーム’を含むことができる。

‘Ｉ−フレーム’は、ＭＰＥＧで当該フレームの前のフレーム及び後のフレームを使用する時間的圧縮技術を利用せず、他のフレームとは独立して空間的圧縮技術だけを用いて作られるフレームを意味する。‘Ｉ−フレーム’は、イメージから直接コードして生成されるため、インターフロック（ｉｎｔｅｒｂｌｏｃｋ）のみから構成され、ランダムアクセスポイント（ＲａｎｄｏｍＡｃｃｅｓｓＰｏｉｎｔ）の役割を担うことができる。また、‘Ｉ−フレーム’は、時間的動きを予測して生成する‘Ｐ−フレーム’及び／又は‘Ｂ−フレーム’の基準となってもよい。したがって、‘Ｉ−フレーム’が自身のフレームの空間剰余要素だけを減少させて圧縮を行うことにより、‘Ｉ−フレーム’は低い圧縮率を提供する。すなわち、圧縮による結果ビット数は、他のフレームに比べて多いビット数を必要とする。

‘Ｐ−フレーム’は、ＭＰＥＧで時間的に後に出る場面に対して動きを予測して生成した画面を意味する。‘Ｐ−フレーム’は、最も最近の‘Ｉ−フレーム’及び／又は‘Ｂ−フレーム’を参照して、画面間順方向予測のみによって次の画面を予測して得る画面である。したがって、‘Ｐ−フレーム’は、比較的高い圧縮率を提供する。

‘Ｂ−フレーム’は、ＭＰＥＧから時間的に予測して生成する画面のうち、前及び／又は後にある‘Ｐ−フレーム’及び／又は‘Ｉ−フレーム’から両方向の動きをより高精度に予測して生成する予測画面のことをいう。‘Ｂ−フレーム’の場合には、直前の‘Ｉ−フレーム’及び／又は‘Ｐ−フレーム’、現在のフレーム、及び／又は直後に出る‘Ｉ−フレーム’及び／又は‘Ｐ−フレーム’に基づいてコーディング及び／又はデコードされる。このため、コーディング及び／又はデコーディング時間遅延が発生する。しかし、‘Ｂ−フレーム’は、最高の圧縮率を提供し、‘Ｐ−フレーム’及び／又は‘Ｉ−フレーム’のコーディング及び／又はデコーディングのベースとならないため、誤りを伝播しない。

前述したように、一つのＩＳＯＢＭＦＦファイル内の‘ｆｔｙｐ’、‘ｍｏｏｖ’、“ｍｏｏｆ”、及び／又は‘ｍｄａｔ’はそれぞれ優先順位が異なってもよい。したがって、‘ｆｔｙｐ’、‘ｍｏｏｖ’、“ｍｏｏｆ”、及び／又は‘ｍｄａｔ’を含むパケットは同一のＴＳＩ及び／又はＴＯＩを有するが、それぞれ異なる優先順位を有することができる。

例えば、‘ｆｔｙｐ’及び‘ｍｏｏｖ’を含むパケットの優先順位情報は、‘０’の値を有し、‘ｍｏｏｆ’を含むパケットの優先順位情報は、‘１’の値を有し、‘Ｉ−フレーム’を含むパケットの優先順位情報は、‘１’の値を有し、‘Ｐ−フレーム’を含むパケットの優先順位情報は、‘２’の値を有し、及び／又は‘Ｂ−フレーム’を含むパケットの優先順位情報は、‘３’の値を有することができる。

このように、放送信号送信装置は、ＡＶＣ（ＡｄｖａｎｃｅｄＶｉｄｅｏＣｏｄｉｎｇ）／ＨＥＶＣ（ＨｉｇｈＥｆｆｉｃｉｅｎｃｙＶｉｄｅｏＣｏｄｉｎｇ）などのビデオデータを含むＭＰＥＧ−ＤＡＳＨセグメントを伝送する場合、‘ｆｔｙｐ’及び‘ｍｏｏｖ’を含むパケット、‘ｍｏｏｆ’を含むパケット、‘Ｉ−Ｐｉｃｔｕｒｅ’を含むパケット、‘Ｐ−Ｐｉｃｔｕｒｅ’を含むパケット、及び／又は‘Ｂ−Ｐｉｃｔｕｒｅ’を含むパケットの順に、パケットデータの処理のための優先順位を与えることができる。

また、ネットワーク上の中継機及び／又はルータなどの中間ノードは、優先順位情報に基づいて、ネットワークの帯域幅及び／又はサービスの目的によって優先順位の高いパケットを優先して伝送し、優先順位の低いパケットは選択的に伝送することができる。したがって、優先順位情報を様々なサービス状況に容易に適用することができる。

また、放送信号受信装置は、ＡＶＣ／ＨＥＶＣなどのビデオデータを受信する場合に、‘ｆｔｙｐ’、‘ｍｏｏｖ’、‘ｍｏｏｆ’、‘Ｉ−Ｐｉｃｔｕｒｅ’、‘Ｐ−Ｐｉｃｔｕｒｅ’、及び／又は‘Ｂ−Ｐｉｃｔｕｒｅ’の優先順位情報に基づいて、優先順位の高いパケット（すなわち、優先順位情報の値が低いパケット）を優先して抽出し、優先順位の低いパケット（すなわち、優先順位情報の値が高いパケット）を選択的に抽出して、一つのシーケンスを構成することができる。変形された実施例として、放送信号受信装置は、選択的にフレームレートの高いシーケンスを抽出したり、又はフレームレートの低いシーケンスを抽出することができる。

図５７は、本発明の他の実施例に係る優先順位情報を含むパケットの構造を示す図である。

本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、パケットヘッダー及びパケットペイロードを含むことができる。パケットヘッダーは、パケットペイロードに対するメタデータを含むことができる。パケットペイロードは、ＭＰＥＧ−ＤＡＳＨコンテンツのデータを含むことができる。

本発明の他の実施例に係るＬＣＴパケットを構成する各フィールドのうち、前述したフィールドと同じ名称のフィールドは前述した内容を全て含むことができ、その具体的な説明は前述した説明に代える。

パケットヘッダーは、パケットペイロードの優先順位（Ｐｒｉｏｒｉｔｙ）を示す優先順位情報（ＥＸＴ＿ＴＹＰＥ）をさらに含むことができる。優先順位情報（ＥＸＴ＿ＴＹＰＥ）は、ＬＣＴヘッダー拡張を用いて現在パケットが送信しているパケットペイロードの相対的優先順位を示すことができる。ＬＣＴヘッダー拡張を用いる場合、ＬＣＴヘッダー拡張を支援しない放送信号受信装置では、優先順位情報（ＥＸＴ＿ＴＹＰＥ）をスキップすればいいため、拡張性を高めることができる。ＬＣＴヘッダー拡張を用いる優先順位情報（ＥＸＴ＿ＴＹＰＥ）は、ＲＴＰ（ｒｅａｌｔｉｍｅｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用されてもよい。

優先順位情報（ＥＸＴ＿ＴＹＰＥ）は、ヘッダー拡張タイプ（ＨＥＴ）フィールド、優先順位フィールド、及び／又は予約フィールドを含むことができる。実施例によって、優先順位情報（ＥＸＴ＿ＴＹＰＥ）は優先順位フィールドのみを表してもよい。

ＨＥＴフィールドは８ビットの整数であってもよく、当該ヘッダー拡張のタイプを示すことができる。例えば、ＨＥＴフィールドは１２８〜２５５の値のうち一つの固有値で当該ヘッダー拡張のタイプを識別することができ、この場合、ヘッダー拡張は３２ビットの固定長を有することができる。

優先順位フィールドは、一つのファイルに含まれたＬＣＴパケットのうち、現在ＬＣＴパケットで送信しているパケットペイロードの優先順位を示すことができる。また、優先順位フィールドは、同一のＴＳＩ又はＴＯＩが与えられたパケットのうち、現在ＬＣＴパケットで送信しているパケットペイロードの相対的優先順位を示すことができる。

例えば、優先順位情報は、０〜２５５の範囲の値を有することができる。優先順位情報が低い値を有するほど、パケットペイロードが全ファイルベースメディアデータを処理する際に優先順位が高いということを示すことができる。

例えば、‘ｆｔｙｐ’及び‘ｍｏｏｖ’を含むパケットの優先順位情報は‘０’の値を有し、‘ｍｏｏｆ’を含むパケットの優先順位情報は‘１’の値を有し、‘Ｉ−フレーム’を含むパケットの優先順位情報は‘２’の値を有し、‘Ｐ−フレーム’を含むパケットの優先順位情報は‘３’の値を有し、及び／又は‘Ｂ−フレーム’を含むパケットの優先順位情報は‘４’の値を有することができる。

以下、具体的な内容は前述の内容と同一であり、その説明を省略する。

図５８は、本発明の他の実施例に係るオフセット情報を含むパケットの構造を示す図である。

例えば、パケットヘッダーは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、予約フィールド（Ｒｅｓ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、及び／又はＦＥＣペイロードＩＤフィールドを含むことができる。

本発明の他の実施例に係るＬＣＴパケットを構成する各フィールドのうち、前述したフィールドと同じ名称のフィールドは前述の内容を全て含むことができ、その具体的な説明は前述の説明に代える。

パケットヘッダーはオフセット情報をさらに含むことができる。オフセット情報は、現在パケットが送信しているパケットペイロードのファイル内におけるオフセットを示すことができる。オフセット情報は、オフセットをファイルの開始地点からのバイト数で示すことができる。オフセット情報は、ＬＣＴヘッダー拡張の形式であってもよく、ＦＥＣペイロードＩＤフィールドに含まれてもよい。

一実施例として、ＬＣＴパケットがＬＣＴヘッダー拡張の形式でオフセット情報（ＥＸＴ＿ＯＦＳ）を含む場合を説明する。

ＬＣＴヘッダー拡張を用いる場合、ＬＣＴヘッダー拡張を支援しない受信機ではオフセット情報（ＥＸＴ＿ＯＦＳ）をスキップすればいいため、拡張性を高めることができる。ＬＣＴヘッダー拡張を用いるオフセット情報（ＥＸＴ＿ＯＦＳ）は、ＲＴＰ（ｒｅａｌｔｉｍｅｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用されてもよい。

オフセット情報（ＥＸＴ＿ＯＦＳ）は、ヘッダー拡張タイプフィールド（ＨＥＴ）、ヘッダー拡張長さフィールド（ＨＥＬ）、及びオフセット開始フィールド（ＳｔａｒｔＯｆｆｓｅｔ）を含むことができる。実施例によって、オフセット情報（ＥＸＴ＿ＯＦＳ）は、オフセット開始フィールド（ＳｔａｒｔＯｆｆｓｅｔ）だけを表してもよい。

ＨＥＴフィールドは、上述したとおりであり、その具体的な説明は省略する。

ＨＥＬフィールドは、可変長のＬＣＴヘッダー拡張の全長を示す。基本的に、ＬＣＴではＨＥＴが０〜１２７の値を有する場合、３２ビットワード単位の可変長ヘッダー拡張が存在し、ＨＥＴフィールドに続くＨＥＬフィールドは。ＬＣＴヘッダー拡張の全長を３２ビットワード単位で示す。

オフセット開始フィールドは、可変長であってもよく、現在パケットが送信しているパケットペイロードのファイル内におけるオフセットを示すことができる。オフセット開始フィールドはオフセットを、ファイルの開始地点からのバイト数で示すことができる。

ＬＣＴパケットは、ＬＣＴヘッダー拡張の形式だけでなく、ＦＥＣペイロードＩＤフィールドにオフセット情報（ＳｔａｒｔＯｆｆｓｅｔ）を含んでもよい。以下では、ＬＣＴパケットがＦＥＣペイロードＩＤフィールドにオフセット情報を含む場合を説明する。

ＦＥＣペイロードＩＤフィールドは、特定パケットによって伝送されるエンコーディングシンボル及びＦＥＣエンコーディング変換間の関係をＦＥＣデコーダに示す情報を含む。例えば、パケットがソースシンボルを伝送すると、ＦＥＣペイロードＩＤフィールドは、オブジェクトのどのソースシンボルがパケットによって伝送されるかを示す。パケットがリペアシンボルを伝送すると、ＦＥＣペイロードＩＤフィールドは、リペアシンボルがオブジェクトからどのように構成されるかを示す。

ＦＥＣペイロードＩＤフィールドはまた、パケットにその一部が含まれるエンコーディングシンボルのより大きいグループに関する情報を含むことができる。例えば、ＦＥＣペイロードＩＤフィールドは、シンボルが関連付いているソースブロックに関する情報を含むことができる。

ＦＥＣペイロードＩＤは、ソースブロック番号（ＳＢＮ）及び／又はエンコーディングシンボルＩＤ（ＥＳＩ）を含む。ＳＢＮは、パケット内のエンコーディングシンボルが関連付いているソースブロックに対する負でない（ｎｏｎ−ｎｅｇａｔｉｖｅ）整数識別子である。ＥＳＩは、パケット内のエンコーディングシンボルに対する負でない整数識別子である。

本発明の他の実施例に係るＦＥＣペイロードＩＤフィールドは、オフセット情報（ＳｔａｒｔＯｆｆｓｅｔ）をさらに含むことができる。

デリバリオブジェクトのオクテットで開始アドレスを特定したＦＥＣペイロードＩＤフィールドが用いられる。この情報をいくつかの方式で伝送することができる。

第一に、サイズ０に設定されたＦＥＣペイロードＩＤセットを有する単純な新しいＦＥＣスキーム。この場合、パケットは３２ビットを用いてダイレクトアドレス（ｓｔａｒｔｏｆｆｓｅｔ）として全オブジェクトを含むはずである。

第二に、ＳＢＮ及びＥＳＩがシンボルサイズ（Ｔ）と共にオフセット開始（ｓｔａｒｔｏｆｆｓｅｔ）を定義するＲＦＣ６３３０への互換可能な方式でＲＦＣ５４４５に定義されたコンパクトノーコード（Ｎｏ−Ｃｏｄｅ）を用いて広く配置された既存のＦＥＣスキーム。

第三に、ＬＳＩＤは適切なシグナリングを提供し、＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及びＦＥＣＰａｒａｍｅｔｅｒｓエレメントを用いて、上記モードのうちいずれかをシグナリングする。

以下では、オフセット情報の具体的な内容を説明する。

従来のＦＬＵＴＥプロトコルでは、オフセット情報を伝送する必要がなかった。従来のＦＬＵＴＥプロトコルは、オブジェクト（例えば、ファイル）を非実時間で伝送するので、一つのオブジェクトを固定サイズの少なくとも一つのデータに分割して伝送した。

例えば、従来のＦＬＵＴＥプロトコルでは、一つのオブジェクトを固定サイズの少なくとも一つのソースブロック（ＳｏｕｒｃｅＢｌｏｃｋ）に分割し、それぞれのソースブロックを固定サイズの少なくとも一つのシンボルに分割し、それぞれのシンボルにヘッダーを追加してＬＣＴパケット（又はＦＬＵＴＥパケット）を生成した。従来のＦＬＵＴＥプロトコルは、一つのＬＣＴパケットは一つの固定サイズのシンボルだけを含むことができた。

それぞれのソースブロック及び／又はシンボルが固定サイズであるため、受信機は、ソースブロック及び／又はシンボルの識別情報に基づいて、オブジェクト内でそれぞれのソースブロック及び／又はシンボルの位置を認識できた。したがって、受信機は、一つのオブジェクトを構成する全ソースブロック及び／又はシンボルを受信した後、受信したソースブロック及び／又はシンボルの識別情報に基づいてオブジェクトを再構成することができた。

従来のＦＬＵＴＥプロトコルがオブジェクトを非実時間で送信することに対して、本発明の他の実施例に係るＲＯＵＴＥプロトコルは、オブジェクトを可変サイズのデリバリオブジェクト（ＤｅｌｉｖｅｒｙＯｂｊｅｃｔ）に分割し、デリバリオブジェクト単位で実時間で伝送することができる。例えば、ＲＯＵＴＥプロトコルは、オブジェクトを可変サイズのオブジェクト内部構造体（ＯｂｊｅｃｔＩｎｔｅｒｎａｌＳｔｒｕｃｔｕｒｅ）単位で伝送することができる。

一つのデリバリオブジェクト（ＤｅｌｉｖｅｒｙＯｂｊｅｃｔ）は、一つのＩＳＯＢＭＦＦファイル又は一つのＩＳＯＢＭＦＦファイルの一部であってもよい。一つのＩＳＯＢＭＦＦファイルの一部は、フラグメント、ＧＯＰ、チャンク、アクセスユニット、及び／又はＮＡＬユニットを含むことができる。一つのＩＳＯＢＭＦＦファイルの一部は、前述したオブジェクト内部構造体を意味することができる。オブジェクト内部構造体は、独立して有意なデータ単位であり、オブジェクト内部構造体のタイプは、上記に限定されず、有意な単位をさらに含んでもよい。

また、本発明の他の実施例に係るＬＣＴパケットにおいて、それぞれのＬＣＴパケット（ＡＬＣ／ＬＣＴパケット、又はＲＯＵＴＥパケット）は、少なくとも一つのエンコーディングシンボルを含むことができる。すなわち、本発明の他の実施例に係るＲＯＵＴＥプロトコルにおいて、一つのＬＣＴパケットに複数のエンコーディングシンボルを含むことができる。また、それぞれのエンコーディングシンボルは可変サイズを有することができる。

本発明の他の実施例に係るＬＣＴパケットにおいて、それぞれのＴＳＩをそれぞれのトラックにマッチすることができる。例えば、それぞれのＴＳＩを、ビデオトラック、オーディオトラック、及び／又はＭＰＥＧ−ＤＡＳＨのリプレゼンテーションのうち一つにマッチすることができる。また、それぞれのＴＯＩは、それぞれのデリバリオブジェクト（ＤｅｌｉｖｅｒｙＯｂｊｅｃｔ）にマップされてもよい。例えば、ＴＯＩがＭＰＥＧ−ＤＡＳＨのセグメントにマップされる場合、デリバリオブジェクトはＩＳＯＢＭＦＦファイルであってもよい。また、それぞれのＴＯＩは、フラグメント、チャンク（ｃｈｕｎｋ）、ＧＯＰ、アクセスユニット、及び／又はＮＡＬユニットのうち一つにマップされてもよい。

受信機が可変サイズのデリバリオブジェクトの単位で実時間でＬＣＴパケットを受信する場合、受信機は、受信したＬＣＴパケットがオブジェクト内でどの位置に該当するかを認識できない場合がある。例えば、受信機が任意の順でＬＣＴパケットを受信する場合、受信機は、ＬＣＴパケットを順序通りに整列することができず、デリバリオブジェクトを正確に復元及び／又はパースできない場合が発生する。

したがって、本発明の他の実施例に係るオフセット情報は、ファイル（例えば、オブジェクト）内で現在伝送中のパケットペイロードのオフセットを示すことができる。受信機は、オフセット情報に基づいて、現在伝送されているパケットが当該ファイルの最初のデータを有することを認識することができる。また、受信機は、オフセット情報に基づいて、当該デリバリオブジェクトにおいて、現在伝送されているパケットの順序を認識することができる。また、受信機は、オフセット情報に基づいて、現在パケットが送信しているパケットペイロードのファイルにおけるオフセットを認識できる他、現在パケットが送信しているデリバリオブジェクトのファイルにおけるオフセットも認識することができる。

例えば、ＴＳＩはビデオトラック（ＭＰＥＧ−ＤＡＳＨリプレゼンテーション）にマッチされ、ＴＯＩはＩＳＯＢＭＦＦファイル（例えば、オブジェクト）にマッチされてもよい。この場合、デリバリオブジェクト（ＤｅｌｉｖｅｒｙＯｂｊｅｃｔ）はＩＳＯＢＭＦＦファイルを表すことができる。一つのビデオトラック（ＭＰＥＧ−ＤＡＳＨリプレゼンテーション、ＴＳＩ＝１）は、第１オブジェクト（ＴＳＩ＝１，ＴＯＩ＝１）及び第２オブジェクト（ＴＳＩ＝１，ＴＯＩ＝２）を含むことができる。第１オブジェクト（ＴＳＩ＝１，ＴＯＩ＝１）は、順次に、第１パケット（ＴＳＩ＝１，ＴＯＩ＝１，ＳｔａｒｔＯｆｆｓｅｔ＝０）、第２パケット（ＴＳＩ＝１，ＴＯＩ＝１，ＳｔａｒｔＯｆｆｓｅｔ＝２００）、第３パケット（ＴＳＩ＝１，ＴＯＩ＝１，ＳｔａｒｔＯｆｆｓｅｔ＝４００）、第４パケット（ＴＳＩ＝１，ＴＯＩ＝１，ＳｔａｒｔＯｆｆｓｅｔ＝８００）、及び／又は第５パケット（ＴＳＩ＝１，ＴＯＩ＝１，ＳｔａｒｔＯｆｆｓｅｔ＝１０００）を含むことができる。

この場合、オフセット情報（ＳｔａｒｔＯｆｆｓｅｔ）の値が‘０’であれば、当該パケットのパケットペイロードは、当該ファイルの最初のデータを有することができる。第１パケットのオフセット情報（ＳｔａｒｔＯｆｆｓｅｔ）の値が‘０’であることから、受信機は、第１パケットのパケットペイロードが第１オブジェクトの最初のデータを有していると認識することができる。

また、オフセット情報（ＳｔａｒｔＯｆｆｓｅｔ）の値は、当該オブジェクト内でパケットの順序を示すことができる。第１オブジェクト内で第１パケットのオフセット情報から第５パケットのオフセット情報が順次に増加するので、受信機は、第１オブジェクト内で第１パケット乃至第５パケットが順次に配列されるということが認識できる。

したがって、受信機は、オフセット情報に基づいて、それぞれのオブジェクトにおいて受信したＬＣＴパケットを順次に整列し、それぞれのデリバリオブジェクト及び／又はオブジェクトを正確に復元することができる。また、受信機は、オフセット情報に基づいて、それぞれのデリバリオブジェクト及び／又はオブジェクトを正確にパース及び／又はデコードすることができる。

一方、受信機が可変サイズのデリバリオブジェクトの単位で実時間でＬＣＴパケットを受信する場合、受信機は、受信したＬＣＴパケットがオブジェクト（例えば、ファイル）内でどの位置に該当するかを認識できない場合がある。例えば、ＬＣＴパケットが任意の順序で伝送されると、受信機は、受信したＬＣＴパケットのオブジェクト内における正確なオフセットがわからず、ＬＣＴパケットを収集してデリバリオブジェクト及び／又はオブジェクトを正確に復元できなくなるという問題が発生しうる。

例えば、ＴＳＩはビデオトラック（ＭＰＥＧ−ＤＡＳＨリプレゼンテーション）にマッチされ、ＴＯＩはチャンクにマッチされてもよい。この場合、一つのビデオトラック（ＭＰＥＧ−ＤＡＳＨリプレゼンテーション、ＴＳＩ＝１）は、第１オブジェクト（ＴＳＩ＝１）及び第２オブジェクト（ＴＳＩ＝１）を含むことができる。また、第１オブジェクトは第１チャンク（ＴＳＩ＝１，ＴＯＩ＝１）、第２チャンク（ＴＳＩ＝１，ＴＯＩ＝２）、及び／又は第３チャンク（ＴＳＩ＝１，ＴＯＩ＝３）を含み、第２オブジェクトは第４チャンク（ＴＳＩ＝１，ＴＯＩ＝４）及び／又は第５チャンク（ＴＳＩ＝１，ＴＯＩ＝５）を含むことができる。

受信機は、第１チャンクを含む第１パケット（ＴＳＩ＝１，ＴＯＩ＝１，ＳｔａｒｔＯｆｆｓｅｔ＝０）、第２チャンクを含む第２パケット（ＴＳＩ＝１，ＴＯＩ＝２，ＳｔａｒｔＯｆｆｓｅｔ＝２００）、第３チャンクを含む第３パケット（ＴＳＩ＝１，ＴＯＩ＝３，ＳｔａｒｔＯｆｆｓｅｔ＝１０００）、第４チャンクを含む第４パケット（ＴＳＩ＝１，ＴＯＩ＝４，ＳｔａｒｔＯｆｆｓｅｔ＝０）、及び／又は第５チャンクを含む第５パケット（ＴＳＩ＝１，ＴＯＩ＝５，ＳｔａｒｔＯｆｆｓｅｔ＝１０００）を受信することができる。ここでは一つのパケットが一つのチャンクを含むとして説明したが、一つのチャンクが少なくとも一つのパケットを含むことができる。

ＴＯＩがオブジェクト（例えば、ファイル）にマッチされるのではなく、オブジェクトよりも小さいデータ単位であるオブジェクト内部構造体にマッチされると、受信機は、オブジェクトを識別できる別の情報がない限り、オブジェクトを識別することができない。

したがって、受信機は、ＴＳＩ及びＴＯＩだけでは、受信した第１パケット、第２パケット及び／又は第３パケットが第１オブジェクトに属するか、又は第２オブジェクトに属するかを正確に認識することができない。また、受信機は、ＴＳＩ及びＴＯＩだけでは、受信した第４パケット及び／又は第５パケットが第１オブジェクトに属するか、又は第２オブジェクトに属するかが認識できない。

すなわち、受信機は、第１パケット乃至第５パケットが順次に配列されることはＴＳＩ及びＴＯＩに基づいて識別できるが、第３パケットが第１オブジェクトに属するか第２オブジェクトに属するかは、ＴＳＩ及びＴＯＩだけからは識別できない。また、第４パケットが第３パケットの次のパケットであることは、ＴＳＩ及びＴＯＩに基づいて識別できるが、第４パケットが第１オブジェクトに属するか又は第２オブジェクトに属するかは、ＴＳＩ及びＴＯＩだけでは識別できない。

この場合、受信機は、第１パケット、第２パケット、及び／又は第３パケットを受信しても、第１オブジェクトを正確に復元することができない。また、受信機は、第４パケット及び／又は第５パケットを受信しても、第２オブジェクトを正確に復元することができない。その結果、受信機は実時間でコンテンツを再生することができない。

したがって、本発明の他の実施例に係るＬＣＴパケットは、オフセット情報（ＳｔａｒｔＯｆｆｓｅｔ）を提供することを特徴とする。オフセット情報は、オブジェクト内で現在伝送中のパケットペイロードのオフセットを示すことができる。受信機は、オフセット情報に基づいて、同一のオブジェクト内に含まれるオブジェクト内部構造体及び／又はパケットを識別することができる。

オフセット情報の値が‘０’であれば、当該パケットが当該オブジェクトの最初のパケットであることを示す。すなわち、第１パケット及び第４パケットのオフセット情報は‘０’であるから、第１パケット及び第４パケットは別個のオブジェクトに属し、それぞれ、当該オブジェクトの最初のパケットであることを示す。また、受信機は、オフセット情報だけでなく、ＴＳＩ及び／又はＴＯＩに基づいて、第１パケット、第２パケット、及び／又は第３パケットが第１オブジェクトに属し、第４パケット及び／又は第５パケットが第２オブジェクトに属するということを識別することができる。

したがって、受信機は、ＴＳＩ、ＴＯＩ、及び／又はオフセット情報のうち少なくとも一つに基づいて、受信したＬＣＴパケットがそれぞれのオブジェクト内でどの位置に該当するかを識別し、受信したＬＣＴパケットを順に整列することができる。例えば、受信機は、オフセット情報及びＴＯＩが順次に増加するようにパケットを整列することができる。

その後、受信機は、オフセット情報が‘０’であるパケットから次のオフセット情報が‘０’であるパケットの以前パケットまでを一つのオブジェクトとして識別することができる。そして、受信機は、ＴＯＩに基づいて、一つのオブジェクト内でデリバリオブジェクト及び／又はオブジェクト内部構造体を識別することができる。

また、受信機は、それぞれのデリバリオブジェクト及び／又はそれぞれのオブジェクトを正確に復元することができる。

また、受信機は、ＴＳＩ、ＴＯＩ、及び／又はオフセット情報のうち少なくとも一つに基づいて、それぞれのデリバリオブジェクト及び／又はそれぞれのオブジェクトを正確にパース及び／又はデコードすることができる。

前述したように、送信機が、独立して有意な単位であるオブジェクト内部構造体（ＯｂｊｅｃｔＩｎｔｅｒｎａｌＳｔｒｕｃｔｕｒｅ）単位でデータを伝送すると、可変サイズでデータを実時間で伝送することができる。したがって、受信機は、一つのオブジェクトを全て受信する前であっても、オブジェクト内部構造体を受信及び識別すると、オブジェクト内部構造体単位で再生することができる。その結果、ファイル（又はオブジェクト）ベースのマルチメディアコンテンツを放送網を介して実時間で伝送及び再生することができる。

図５９は、本発明の他の実施例に係るＲＡＰ（ＲａｎｄｏｍＡｃｃｅｓｓＰｏｉｎｔ）情報を含むパケットの構造を示す図である。

パケットヘッダーは、ＲＡＰ（ＲａｎｄｏｍＡｃｃｅｓｓＰｏｉｎｔ）情報（Ｐ）をさらに含むことができる。ＲＡＰ情報（Ｐ）は、現在パケットが送信しているパケットペイロードに、ランダムアクセスポイント（ＲＡＰ）に該当するデータが含まれているか否かを示すことができる。ＲＡＰ情報（Ｐ）は、各パケットの開始地点から１２番目又は１３番目のビットに位置する１個のビットを用いて、現在パケットが送信しているパケットペイロードに、ランダムアクセスポイント（ＲＡＰ）に該当するデータが含まれているか否かを示すことができる。この場合、１ビットを使用するので、パケットヘッダーのサイズを減らし、効率性を高めることができる。

ランダムアクセスポイント（ＲＡＰ）は、他のフレームを参照しないで符号化可能であり、且つ、ランダムアクセスが可能な基本フレームを意味する。例えば、‘Ｉ−フレーム’は、ＭＰＥＧで当該フレームの前のフレーム及び後のフレームを使用する時間的圧縮技術を利用せず、他のフレームとは独立して空間的圧縮技術だけを用いて生成されるフレームを意味する。したがって、‘Ｉ−フレーム’は、イメージから直接コードして生成されることから、インターブロック（ｉｎｔｅｒｂｌｏｃｋ）のみから構成され、ランダムアクセスポイント（ＲａｎｄｏｍＡｃｃｅｓｓＰｏｉｎｔ）の役割を担うことができる。

受信器は、ＲＡＰ情報（Ｐ）に基づいて、伝送されているパケットシーケンス（ｓｅｑｕｅｎｃｅ）においてランダムアクセスが可能なパケットを識別することができる。例えば、受信したパケットのペイロードが‘Ｉ−フレーム’に関するデータを含んでいると、ＲＡＰ情報（Ｐ）は、当該パケットがランダムアクセスポイント（ＲＡＰ）に該当するデータを含んでいることを示すことができる。また、受信したパケットのペイロードが‘Ｂ−フレーム’及び／又は‘Ｐ−フレーム’に関するデータを含んでいると、ＲＡＰ情報（Ｐ）は、当該パケットがランダムアクセスポイント（ＲＡＰ）に該当するデータを含んでいないと示すことができる。

受信器が特定時点からＧＯＰデータを順次に受信する時、最初のパケットが‘Ｉ−フレーム’のようにＲＡＰに該当すると、受信機は、当該パケットからデコーディングを始めることができる。しかし、最初のパケットが‘Ｂ−フレーム’及び／又は‘Ｐ−フレーム’のようにＲＡＰに該当しないと、受信機は、当該パケットからデコーディングを始めることができない。この場合、受信機は、ＲＡＰでないパケットはスキップし、続く‘Ｉ−フレーム’のようにＲＡＰに該当するパケットからデコードし始めることができる。

したがって、放送環境におけるチャネルチューニング又はユーザの要求によるシーケンス内の任意地点接近状況において、受信機は、ＲＡＰ情報（Ｐ）に基づいて、ＲＡＰに該当しないパケットはスキップし、ＲＡＰに該当するパケットからデコードするため、パケットの受信及びデコーディング効率を上げることができる。

図６０は、本発明の他の実施例に係るＲＡＰ（ＲａｎｄｏｍＡｃｃｅｓｓＰｏｉｎｔ）情報を含むパケットの構造を示す図である。

また、パケットペイロードは、シンボルエンコーディングフィールドを含むことができる。

パケットヘッダーは、ＲＡＰ（ＲａｎｄｏｍＡｃｃｅｓｓＰｏｉｎｔ）情報（Ｐ）をさらに含むことができる。

ＲＡＰ情報（Ｐ）は、各パケットの開始地点から６番目又は７番目のビットに位置する１個のビットを用いて、現在パケットが送信しているパケットペイロードに、ランダムアクセスポイント（ＲＡＰ）に該当するデータが含まれているか否かを示すことができる。この場合、１ビットを使用するので、パケットヘッダーのサイズを減らすことができ、効率性を高めることができる。

本発明の他の実施例に係るパケットは、パケットヘッダーの６番目又は７番目のビットに位置するビットを用いてＲＡＰ情報（Ｐ）を含むので、パケットヘッダーの１２番目又は１３番目のビットを他の用途に用いることができる。

例えば、パケットは、パケットヘッダーの６番目又は７番目のビットを用いてＲＡＰ情報（Ｐ）を含み、パケットヘッダーの１２番目及び／又は１３番目のビットを用いて、前述したオブジェクトタイプ情報、及び／又は前述した優先順位情報を含むことができる。

図６１は、本発明の他の実施例に係る実時間（ＲｅａｌＴｉｍｅ）情報を含むパケットの構造を示す図である。

送信機は、ＦＤＴ（ＦｉｌｅＤｅｌｉｖｅｒｙＴａｂｌｅ）レベル及び／又はデリバリオブジェクトレベルで定義される実時間情報（Ｔ）を用いて、ＬＣＴパケットが送信しているオブジェクト及び／又はオブジェクト内部構造体が実時間で伝送されるか又は非実時間で伝送されるかを示すことができる。デリバリオブジェクトレベルは、オブジェクトレベル、及び／又はオブジェクト内部構造体レベルを含むことができる。

実時間情報（Ｔ）がＦＤＴレベルで定義されると、実時間情報（Ｔ）は、当該ＦＤＴで記述する全データが実時間で伝送されるか又は非実時間で伝送されるかを示すことができる。例えば、ＬＳＩＤは実時間情報（Ｔ）を含むことができる。また、実時間情報（Ｔ）がＦＤＴレベルで定義されると、実時間情報（Ｔ）は、当該ＦＤＴで記述する全オブジェクトが実時間で伝送されるか非実時間で伝送されるかを示すことができる。ここで、当該ＦＤＴで記述する全オブジェクトは、当該ＬＣＴ伝送セッションに属する全オブジェクトを示すことができる。

また、実時間情報（Ｔ）がデリバリオブジェクトレベルで定義されると、実時間情報（Ｔ）は、当該デリバリオブジェクトに属する全データが実時間で伝送されるか非実時間で伝送されるかを示すことができる。例えば、デリバリオブジェクトがオブジェクトにマッチされる場合、実時間情報（Ｔ）がデリバリオブジェクトレベルで定義されると、実時間情報（Ｔ）は、当該オブジェクトに属する全データが実時間で伝送されるか非実時間で伝送されるかを示すことができる。また、デリバリオブジェクトがオブジェクト内部構造体にマッチされる場合、実時間情報（Ｔ）がデリバリオブジェクトレベルで定義されると、実時間情報（Ｔ）は、当該オブジェクト内部構造体に属する全データが実時間で伝送されるか非実時間で伝送されるかを示すことができる。

一実施例として、実時間情報（Ｔ）がデリバリオブジェクトレベルで定義されると、パケットヘッダーは、実時間（ＲｅａｌＴｉｍｅ）情報（Ｔ）をさらに含むことができる。実時間情報（Ｔ）は、ＬＣＴパケットが送信しているデリバリオブジェクトが実時間（ＲｅａｌＴｉｍｅ）で伝送されるか非実時間（ＮｏｎＲｅａｌＴｉｍｅ）で伝送されるかを示すことができる。

例えば、デリバリオブジェクトはＴＯＩにマッチされるデータ単位であってもよい。また、実時間情報（Ｔ）の値が‘０’であれば、ＬＣＴパケットが送信しているデリバリオブジェクトは非実時間で伝送されることを示すことができ、実時間情報（Ｔ）の値が‘１’であれば、ＬＣＴパケットが送信しているデリバリオブジェクトは実時間で伝送されることを示すことができる。

実時間情報（Ｔ）は、ＴＯＩフィールドの最初のビットを用いて、ＬＣＴパケットが送信しているデリバリオブジェクトが実時間で伝送されるか非実時間で伝送されるかを示すことができる。

前述したように、ＴＯＩフィールドをＯＧＩフィールド及びＤＴＯＩフィールドに分割した場合、実時間情報（Ｔ）は、ＯＧＩフィールドの最初のビットを用いて、ＬＣＴパケットが送信しているデリバリオブジェクトが実時間で伝送されるか非実時間で伝送されるかを示すことができる。

実時間情報（Ｔ）はＴＯＩフィールド及び／又はＯＧＩフィールドの最初のビットに含まれるので、送信機は、一つのＬＣＴ伝送セッション（例えば、ビデオトラック、オーディオトラック、ＭＰＥＧ−ＤＡＳＨのＲｅｐｒｅｓｅｎｔａｔｉｏｎ）内で実時間データ及び非実時間データを共に伝送することができる。例えば、送信機は、一つのＬＣＴ伝送セッション内でオーディオデータ及び／又はビデオデータを実時間で伝送することができ、イメージ及び／又はアプリケーションなどを非実時間で伝送することができる。また、送信機は、一つのＬＣＴ伝送セッション内で一部のデリバリオブジェクトは実時間で伝送し、残りのデリバリオブジェクトは非実時間で伝送することができる。

また、実時間情報（Ｔ）は既存のＴＯＩフィールドの最初のビットに含まれるので、本発明の他の実施例に係るＬＣＴパケットは、既存のＡＬＣ／ＬＣＴ及び／又はＦＬＵＴＥプロトコルとの下位互換性を保障することができる。

図６２は、本発明の他の実施例に係る放送信号送信装置の構造を示す図である。

本発明の他の実施例に係る放送信号送信装置は、デリバリオブジェクト生成器Ｃ５１３００、シグナリングエンコーダＣ５１１００、及び／又は送信器Ｃ３１５００を含むことができる。

デリバリオブジェクト生成器は、ファイルを、ファイルの一部（ａｐａｒｔｏｆｔｈｅｆｉｌｅ）に該当する少なくとも一つのデリバリオブジェクト（ＤｅｌｉｖｅｒｙＯｂｊｅｃｔ）に分割することができる。

シグナリングエンコーダ（ＳｉｇｎａｌｉｎｇＥｎｃｏｄｅｒ）は、デリバリオブジェクトに対するメタデータを含むシグナリング情報をエンコードすることができる。

シグナリング情報は、少なくとも一つのデリバリオブジェクトが少なくても一つのＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）パケットを用いて、単方向チャネル（ｕｎｉｄｉｒｅｃｔｉｏｎａｌｃｈａｎｎｅｌ）を介して実時間で伝送されるか否かを示す実時間情報を含むことができる。

送信器（ｔｒａｎｓｍｉｔｔｅｒ）は、少なくとも一つのデリバリオブジェクト及びシグナリング情報を伝送することができる。

本発明の他の実施例に係る放送信号送信装置は、前述した放送信号送信装置の機能を全て含むことができる。また、シグナリング情報に関する具体的な内容は、前述した内容に代えたり、次の図面で具体的に説明するものとする。

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

放送信号受信装置は放送信号を受信することができる。放送信号は、シグナリングデータ、ＥＳＧデータ、ＮＲＴコンテンツデータ及び／又はＲＴコンテンツデータを含むことができる。

放送信号受信装置は、ＲＯＵＴＥセッション記述に基づいてＲＯＵＴＥセッションに参加（ｊｏｉｎ）することができる。ＲＯＵＴＥセッション記述は、放送信号送信装置のＩＰアドレス、ＲＯＵＴＥセッションのアドレス及びポート番号、当該セッションがＲＯＵＴＥセッションであり、全パケットはＬＣＴパケットであることを示す情報を含むことができる。また、ＲＯＵＴＥセッション記述は、当該セッションをＩＰ／ＵＤＰを用いて参加（ｊｏｉｎ）及び消費（ｃｏｎｓｕｍｅ）するために必要な情報をさらに含むことができる。

その後、放送信号受信装置は、ＲＯＵＴＥセッションに含まれた少なくとも一つのＬＣＴ伝送セッションに関する情報を含んでいるＬＣＴＬＳＩＤ（ＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ）を受信することができる。

その後、放送信号受信装置は、少なくとも一つのＬＣＴ伝送セッションに含まれたマルチメディアコンテンツを受信することができる。マルチメディアコンテンツは少なくとも一つのファイルで構成されてもよい。そして、放送信号受信装置は、ＬＣＴパケットを用いて、単方向チャネルを介してファイルベースのマルチメディアコンテンツを実時間で受信することができる。

そのために、本発明の他の実施例に係る放送信号受信装置は、シグナリングデコーダ（ＳｉｇｎａｌｉｎｇＤｅｃｏｄｅｒ）Ｃ５２１００、デリバリオブジェクトプロセッサ（ＤｅｌｉｖｅｒｙＯｂｊｅｃｔＰｒｏｃｅｓｓｏｒ）Ｃ５２３００、及び／又はデコーダ（Ｄｅｃｏｄｅｒ）Ｃ５２５００を含むことができる。

シグナリングデコーダＣ５２１００は、ファイルの一部（ｐａｒｔｏｆａｆｉｌｅ）に該当する少なくとも一つのデリバリオブジェクトに対するメタデータを含むシグナリング情報をデコードすることができる。

シグナリング情報は、少なくとも一つのデリバリオブジェクトがＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）パケットを用いて単方向チャネルを介して実時間で伝送されるか否かを示す実時間情報を含むことができる。シグナリング情報はＬＳＩＤだけでなく、ＬＣＴパケットの拡張されたヘッダーにも含まれてもよい。

実時間情報は、ＦＤＴ（ＦｉｌｅＤｅｌｉｖｅｒｙＴａｂｌｅ）で定義され、実時間情報は、ＦＤＴで記述する全デリバリオブジェクトが実時間で伝送されるか否かを示すことができる。また、実時間情報は、上記デリバリオブジェクトを識別するＴＯＩ（ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒ）フィールドの最初のビットで定義され、実時間情報は、当該デリバリオブジェクトに属する全データが実時間で伝送されるか否かを示すことができる。

デリバリオブジェクトプロセッサＣ５２３００は、上記少なくとも一つのＬＣＴパケットを収集し、少なくとも一つのデリバリオブジェクトを復元することができる。デリバリオブジェクトプロセッサＣ５２３００は、前述した送信ブロック再生成器Ｃ２２０３０、フラグメント再生成器Ｃ２２０４０、フラグメントパーサーＣ２２０５０、及び／又は抽出器Ｃ３２０５０の機能を含むことができる。

デコーダＣ５２５００は、少なくとも一つのデリバリオブジェクトをデコードすることができる。デコーダＣ５２５００は、デリバリオブジェクトに関する情報を少なくとも一つのアクセスユニットの形態で受け取り、少なくとも一つのアクセスユニットをデコードしてメディアデータを生成することができる。デコーダＣ５２５００は、ファイルの一部に該当するデリバリオブジェクトを受信すると、一つのファイルを全て受信しなくてもデリバリオブジェクトをデコードすることができる。

シグナリング情報は、ファイル内でＬＣＴパケットが送信しているデータのオフセットを示すオフセット情報をさらに含むことができる。デリバリオブジェクトプロセッサＣ５２３００は、オフセット情報に基づいてデリバリオブジェクトを識別することができる。オフセット情報は、オフセットをファイルの開始地点からのバイト数で示すことができる。オフセット情報は、ＬＣＴヘッダー拡張の形式であってもよく、ＦＥＣペイロードＩＤフィールドに含まれてもよい。

放送信号受信装置が可変サイズのデリバリオブジェクトの単位で実時間でＬＣＴパケットを受信する場合、放送信号受信装置は、受信したＬＣＴパケットがオブジェクト内でどの位置に該当するかを認識できないことが発生する。例えば、放送信号受信装置が任意の順でＬＣＴパケットを受信する場合、放送信号受信装置は、ＬＣＴパケットを順序通りに整列できず、デリバリオブジェクトを正確に復元及び／又はパースできない場合が発生する。

したがって、本発明の他の実施例に係るオフセット情報は、ファイル（例えば、オブジェクト）内で現在伝送中のパケットペイロードのオフセットを示すことができる。放送信号受信装置は、オフセット情報に基づいて、現在伝送中のＬＣＴパケットが当該ファイルの最初のデータを有することを認識することができる。また、放送信号受信装置は、オフセット情報に基づいて、当該ファイル及び／又はデリバリオブジェクト内で現在伝送中のＬＣＴパケットの順序を認識することができる。

また、放送信号受信装置は、オフセット情報に基づいて現在ＬＣＴパケットが送信しているパケットペイロードのファイル内におけるオフセットを認識できる他、現在ＬＣＴパケットが送信しているデリバリオブジェクトのファイル内におけるオフセットも認識することができる。

ＴＯＩがオブジェクト（例えば、ファイル）にマッチされるのではなく、オブジェクトよりも小さいデータ単位であるオブジェクト内部構造体にマッチされると、放送信号受信装置は、オブジェクトを識別できる別の情報がない限り、オブジェクトを識別することができない。

したがって、放送信号受信装置は、オフセット情報に基づいて、同一のオブジェクト内に含まれるオブジェクト内部構造体及び／又はＬＣＴパケットを識別することができる。

シグナリング情報は、ＬＣＴパケットがランダムアクセスポイント（ＲａｎｄｏｍＡｃｃｅｓｓＰｏｉｎｔ；ＲＡＰ）に該当するデータを含んでいるか否かを示すＲＡＰ情報をさらに含むことができる。ランダムアクセスポイントは、他のフレームを参照しないで符号化でき、且つランダムアクセスが可能な基本フレームを意味する。

デリバリオブジェクトプロセッサＣ５２３００は、ＲＡＰ情報に基づいて、ランダムアクセスポイントに該当するデータを送信するパケットから始まって少なくとも一つのパケットを収集することができる。

例えば、放送信号受信装置は、特定時点から順次にＧＯＰデータを受信するとき、最初のパケットが‘Ｉ−フレーム’のようにＲＡＰに該当すると、放送信号受信装置は、当該ＬＣＴパケットからデコードし始めることができる。しかし、最初のＬＣＴパケットが‘Ｂ−フレーム’及び／又は‘Ｐ−フレーム’のようにＲＡＰに該当しないと、受信器は、当該ＬＣＴパケットからデコーディングを始めることができない。この場合、放送信号受信装置は、ＲＡＰでないＬＣＴパケットはスキップし、続く‘Ｉ−フレーム’のようにＲＡＰに該当するＬＣＴパケットからデコードし始めることができる。

シグナリング情報は、ＬＣＴパケットが送信しているデータの優先順位を示す優先順位情報（Ｐｒｉｏｒｉｔｙｉｎｆｏｒｍａｔｉｏｎ）をさらに含むことができる。

デリバリオブジェクトプロセッサＣ５２３００は優先順位情報に基づいてＬＣＴパケットを選択的に収集することができる。

放送信号受信装置は、ＡＶＣ／ＨＥＶＣなどのビデオデータを受信する場合に、‘ｆｔｙｐ’、‘ｍｏｏｖ’、‘ｍｏｏｆ’、‘Ｉ−Ｐｉｃｔｕｒｅ’、‘Ｐ−Ｐｉｃｔｕｒｅ’、及び／又は‘Ｂ−Ｐｉｃｔｕｒｅ’の優先順位情報に基づいて、優先順位の高いＬＣＴパケットを優先して抽出し、優先順位の低いＬＣＴパケットを選択的に抽出して、一つのシーケンスを構成することができる。

図６４は、本発明の実施例に係る次世代放送システムのためのプロトコルスタックを示す図である。

本発明に係る放送システムは、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）中心放送ネットワーク及びブロードバンドが結合されたハイブリッド放送システムに対応し得る。

本発明に係る放送システムは、従来のＭＰＥＧ−２ベースの放送システムとの互換性を維持するように設計されていてもよい。

本発明に係る放送システムは、ＩＰ中心放送ネットワーク、ブロードバンドネットワーク及び／又はモバイル通信ネットワーク（又はセルラーネットワーク）の結合に基づくハイブリッド放送システムに対応してもよい。

同図を参照すると、物理層は、ＡＴＳＣシステム及び／又はＤＶＢシステムなどの放送システムで採択された物理プロトコルを用いることができる。例えば、本発明に係る物理層で、送信機／受信機は、地上波放送信号を送受信し、放送データを含む伝送フレームを適宜の形態に変換することができる。

カプセル化層で、ＩＰデータグラムが、物理層から取得された情報から取得されたり、又は取得されたＩＰデータグラムが特定フレーム（例えば、ＲＳフレーム、ＧＳＥ−ｌｉｔｅ、ＧＳＥ又は信号フレーム）に変換される。フレームは、ＩＰデータグラムのセットを含むことができる。例えば、カプセル化層で、送信機が伝送フレーム内の物理層で処理されたデータを含めたり、又は、受信機が物理層から取得された伝送フレームからＭＰＥＧ−２ＴＳ及びＩＰデータグラムを抽出する。

ＦＩＣ（ｆａｓｔｉｎｆｏｒｍａｔｉｏｎｃｈａｎｎｅｌ）は、サービス及び／又はコンテンツにアクセスするために必要な情報（例えば、サービスＩＤ及びフレーム間のマッピング情報）を含む。ＦＩＣをＦＡＣ（ｆａｓｔａｃｃｅｓｓｃｈａｎｎｅｌ）と呼ぶこともできる。

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

本発明に係る放送システムでは、データを、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）の形態で伝送することができる。ＥＳＧ（ＥｌｅｃｔｒｉｃａｌＳｅｒｖｉｃｅＧｕｉｄｅ）、ＮＲＴ（ＮｏｎＲｅａｌＴｉｍｅ）、Ａ／Ｖ（Ａｕｄｉｏ／Ｖｉｄｅｏ）及び／又は一般データをＩＳＯＢＭＦＦの形態で伝送することができる。

放送ネットワークを介したデータの伝送は、線形コンテンツの伝送及び／又は非線形コンテンツの伝送を含むことができる。

ＲＴＰ／ＲＴＣＰベースのＡ／Ｖ及びデータ（字幕、緊急警報メッセージなど）の伝送は、線形コンテンツの伝送に対応してもよい。

ＲＴＰペイロードは、ＮＡＬ（ＮｅｔｗｏｒｋＡｂｓｔｒａｃｔｉｏｎＬａｙｅｒ）を含むＲＴＰ／ＡＶストリームの形態及び／又はＩＳＯベースメディアファイルフォーマットでカプセル化された形態で伝送されてもよい。ＲＴＰペイロードの伝送は、線形コンテンツの伝送に対応してもよい。ＩＳＯベースメディアファイルフォーマットでカプセル化された形態の伝送は、Ａ／Ｖに対するＭＰＥＧＤＡＳＨメディアセグメントなどを含むことができる。

ＦＬＵＴＥベースＥＳＧの伝送、ノン−タイムド（ｎｏｎ−ｔｉｍｅｄ）データの伝送、ＮＲＴコンテンツの伝送は、非線形コンテンツの伝送に対応してもよい。これらは、ＭＩＭＥタイプファイル形態及び／又はＩＳＯベースメディアファイルフォーマットでカプセル化された形態で伝送されてもよい。ＩＳＯベースメディアファイルフォーマットでカプセル化された形態の伝送は、Ａ／Ｖに対するＭＰＥＧＤＡＳＨメディアセグメントなどを含むことができる。

ブロードバンドネットワークを介した伝送は、コンテンツの伝送及びシグナリングデータの伝送とに分割することができる。

コンテンツの伝送は、線形コンテンツ（Ａ／Ｖ及びデータ（字幕、緊急警報メッセージなど）、非線形コンテンツ（ＥＳＧ、ノン−タイムドデータなど）の伝送、及びＭＰＥＧＤＡＳＨベースメディアセグメント（Ａ／Ｖ及びデータ）の伝送を含む。

シグナリングデータの伝送は、放送ネットワークで送信されたシグナリングテーブルを含む（ＭＰＥＧＤＡＳＨのＭＰＤを含む。）伝送であってもよい。

本発明に係る放送システムで、放送ネットワークで伝送される線形／非線形コンテンツ間の同期化、又は放送ネットワークで伝送されるコンテンツ及びブロードバンドで送信されたコンテンツ間の同期化を支援することができる。例えば、一つのＵＤコンテンツが個別に及び同時に放送ネットワーク及びブロードバンドで伝送される場合に、受信機は、伝送プロトコルによってタイムラインを調節し、放送ネットワークを介したコンテンツとブロードバンドを介したコンテンツとを同期化し、一つのＵＤコンテンツとしてコンテンツを再構成することができる。

本発明に係る放送システムのアプリケーション層は、双方向性（ｉｎｔｅｒａｃｔｉｖｉｔｙ）、個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）、第２スクリーン及び自動コンテンツ認識（ＡＣＲ；ａｕｔｏｍａｔｉｃｃｏｎｔｅｎｔｒｅｃｏｇｎｉｔｉｏｎ）などの技術的特性を実現することができる。それらの特性は、ＡＴＳＣ２．０からＡＴＳＣ３．０までの拡張において重要である。例えば、ＨＴＭＬ５を双方向性の特性に用いることができる。

本発明に係る放送システムのプレゼンテーション層で、ＨＴＭＬ及び／又はＨＴＭＬ５は、コンポーネント又はインタラクティブアプリケーション間の空間及び時間的関係を識別するために用いることができる。

本発明で、シグナリングは、コンテンツ及び／又はサービスの効果的な取得を支援するために必要なシグナリング情報を含む。シグナリングデータをバイナリ又はＸＭＬｇｕｄｘｏｆｈで表現することができる。シグナリングデータは、地上波放送ネットワーク又はブロードバンドで送信することができる。

実時間放送Ａ／Ｖコンテンツ及び／又はデータをＩＳＯベースメディアファイルフォーマットなどで表現することができる。この場合、Ａ／Ｖコンテンツ及び／又はデータは、実時間で地上波放送ネットワークを介して送信されてもよく、非実時間でＩＰ／ＵＤＰ／ＦＬＵＴＥに基づいて送信されてもよい。代案として、放送Ａ／Ｖコンテンツ及び／又はデータは、実時間にインターネットでＤＡＳＨ（ＤｙｎａｍｉｃＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇｏｖｅｒＨＴＴＰ）を用いてストリーミングモードでコンテンツを受信したり、又は要求することによって受信することができる。本発明の実施例に係る放送システムで、受信された放送Ａ／Ｖコンテンツ及び／又はデータは結合され、インタラクティブサービス及び第２スクリーンサービスなどの様々な向上したサービスを視聴者に提供することができる。

送信機の物理層（ＢｒｏａｄｃａｓｔＰＨＹ及びＢｒｏａｄｂａｎｄＰＨＹ）は、図１に示した構造を実施例とすることができる。また、受信機の物理層は、図９に示した構造を実施例とすることができる。

シグナリングデータ及びＩＰ／ＵＤＰデータグラムは、物理層に伝達される伝送フレーム（又はフレーム）の特定データパイプ（以下、ＤＰ）で伝送されてもよい。例えば、入力フォーマットブロック１０００は、シグナリングデータ及びＩＰ／ＵＤＰデータグラムを受信し、それぞれのシグナリングデータ及びＩＰ／ＵＤＰデータグラムを少なくとも一つのＤＰに逆多重化することができる。出力プロセッサ９３００は、入力フォーマットブロック１０００と逆の動作を行うことができる。

図６５は、本発明の一実施例に係る、次世代放送システムの受信機を示す図である。

本発明の一実施例に係る受信機は、受信部（図示せず）、チャネル同期化器（ＣｈａｎｎｅｌＳｙｎｃｈｒｏｎｉｚｅｒ）Ｊ３２０１０、チャネル等化器（ＣｈａｎｎｅｌＥｑｕａｌｉｚｅｒ）Ｊ３２０２０、チャネルデコーダ（ＣｈａｎｎｅｌＤｅｃｏｄｅｒ）Ｊ３２０３０、シグナリングデコーダ（ＳｉｇｎａｌｉｎｇＤｅｃｏｄｅｒ）Ｊ３２０４０、ベースバンド動作コントローラ（ＢａｓｅｂａｎｄＯｐｅｒａｔｉｏｎＣｏｎｔｒｏｌｌｅｒ）Ｊ３２０５０、サービスマップデータベース（ＳｅｒｖｉｃｅＭａｐＤＢ）Ｊ３２０６０、伝送パケットインターフェース（ＴｒａｎｓｐｏｒｔＰａｃｋｅｔＩｎｔｅｒｆａｃｅ）Ｊ３２０７０、ブロードバンドパケットインターフェース（ＢｒｏａｄｂａｎｄＰａｃｋｅｔＩｎｔｅｒｆａｃｅ）Ｊ３２０８０、コモンプロトコルスタック処理器（ＣｏｍｍｏｎＰｒｏｔｏｃｏｌＳｔａｃｋ）Ｊ３２０９０、サービスシグナリングチャネルプロセシングバッファ及びパーサー（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＰｒｏｃｅｓｓｉｎｇＢｕｆｆｅｒ＆Ｐａｒｓｅｒ）Ｊ３２１００、Ａ／Ｖプロセッサ（Ａ／ＶＰｒｏｃｅｓｓｏｒ）Ｊ３２１１０、サービスガイドプロセッサ（ＳｅｒｖｉｃｅＧｕｉｄｅＰｒｏｃｅｓｓｏｒ）Ｊ３２１２０、アプリケーションプロセッサ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｃｅｓｓｏｒ）Ｊ３２１３０、及び／又はサービスガイドデータベース（ＳｅｒｖｉｃｅＧｕｉｄｅＤＢ）Ｊ３２１４０を含むことができる。

受信部（図示せず）は放送信号を受信する。

チャネル同期化器Ｊ３２０１０は、ベースバンド（Ｂａｓｅｂａｎｄ）で受信した信号のデコーディングが可能なようにシンボル（ｓｙｍｂｏｌ）周波数とタイミング（ｔｉｍｉｎｇ）を同期化する。ここで、ベースバンドは、放送信号が送／受信される領域を意味する。

チャネル等化器Ｊ３２０２０は、受信された信号に対してチャネル等化を行う。チャネル等化器Ｊ３２０２０はね受信された信号が多重経路（ｍｕｌｔｉｐａｔｈ）、ドップラー効果（Ｄｏｐｐｌｅｒｅｆｆｅｃｔ）などによって歪まれたとき、これを補償する役割を担う。

チャネルデコーダ（ＣｈａｎｎｅｌＤｅｃｏｄｅｒ）Ｊ３２０３０は、受信された信号を有意な伝送フレーム（ｔｒａｎｓｐｏｒｔｆｒａｍｅ）に復旧する。チャネルデコーダＪ３２０３０は、受信した信号に含まれたデータ又は伝送フレームに対して順方向誤り訂正（ｆｏｒｗａｒｄｅｒｒｏｒｃｏｒｒｅｃｔｉｏｎ；ＦＥＣ）を行う。

シグナリングデコーダＪ３２０４０は、受信した信号に含まれたシグナリングデータを抽出してデコードする。ここで、シグナリングデータは、後述するシグナリングデータ及び／又はサービス情報（ＳｅｒｖｉｃｅＩｎｆｏｒｍａｔｉｏｎ；ＳＩ）を含む。

ベースバンド動作コントローラＪ３２０５０は、ベースバンドにおける信号の処理を制御する。

サービスマップデータベースＪ３２０６０は、シグナリングデータ及び／又はサービス情報を記憶する。サービスマップデータベースＪ３２０６０は、放送信号に含まれて伝送されたシグナリングデータ及び／又はブロードバンドパケットに含まれて伝送されたシグナリングデータを記憶することができる。

伝送パケットインターフェースＪ３２０７０は、伝送フレーム又は放送信号から伝送パケットを抽出する。伝送パケットインターフェースＪ３２０７０は、伝送パケット（ｔｒａｎｓｐｏｒｔｐａｃｋｅｔ）からシグナリングデータ又はＩＰデータグラム（ＩＰｄａｔａｇｒａｍ）を抽出する。

ブロードバンドパケットインターフェースＪ３２０８０は、インターネット網を介して放送関連パケットを受信する。ブロードバンドパケットインターフェースＪ３２０８０は、インターネット網を介して取得されたパケット（Ｐａｃｋｅｔ）を抽出し、当該パケットからシグナリングデータ又はＡ／Ｖデータを組合せ又は抽出する。

コモンプロトコルスタック処理器Ｊ３２０９０は、受信したパケットをプロトコルスタックに含まれたプロトコルによって処理する。例えば、コモンプロトコルスタック処理器Ｊ３２０９０は、前述したプロトコルスタックによって、受信したパケットを処理することができる。

サービスシグナリングチャネルプロセシングバッファ及びパーサーＪ３２１００は、受信されたパケットに含まれたシグナリングデータを抽出する。サービスシグナリングチャネルプロセシングバッファ及びパーサーＪ３２１００は、ＩＰデータグラムなどからサービス及び／又はコンテンツのスキャン及び／又は取得に関連したシグナリング情報を抽出し、これをパースする。受信されたパケット内でシグナリングデータは一定の位置又はチャネルに存在してもよい。このような位置又はチャネルを、サービスシグナリングチャネルと命名することができる。例えば、サービスシグナリングチャネルは、特定ＩＰアドレス、ＵＤＰＰｏｒｔナンバー、伝送セッション識別子などを有することができる。受信機は、このような特定ＩＰアドレス、ＵＤＰＰｏｒｔナンバー、伝送セッションなどに伝送されるデータをシグナリングデータと認識することができる。

Ａ／ＶプロセッサＪ３２１１０は、受信されたオーディオ及びビデオデータに対するデコーディング及びプレゼンテーション（ｐｒｅｓｅｎｔａｔｉｏｎ）処理を行う。

サービスガイドプロセッサＪ３２１２０は、受信信号からアナウンスメント（ａｎｎｏｕｎｃｅｍｅｎｔ）情報を抽出し、サービスガイドデータベースＪ３２１４０を管理し、サービスガイド（ｓｅｒｖｉｃｅｇｕｉｄｅ）を提供する。

アプリケーションプロセッサＪ３２１３０は、受信したパケットに含まれたアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）データ及び／又はアプリケーション関連情報を抽出して、これを処理する。

サービスガイドデータベースＪ３２１４０は、サービスガイドデータを記憶する。

図６６は、本発明の実施例に係る放送受信機を示す図である。

本発明の実施例に係る放送受信機は、サービス／コンテンツ取得コントローラＪ２０１０、インターネットインターフェースＪ２０２０、ブロードキャストインターフェースＪ２０３０、シグナリングデコーダＪ２０４０、サービスマップデータベースＪ２０５０、デコーダＪ２０６０、ターゲッティングプロセッサＪ２０７０、プロセッサＪ２０８０、管理部Ｊ２０９０、及び／又は再分配モジュールＪ２１００を含む。同図には、放送受信機の外部及び／又は内部に位置する外部管理装置Ｊ２１１０が示されている。

サービス／コンテンツ取得コントローラＪ２０１０は、ブロードキャスト／ブロードバンドチャネルを介してそれに関連したサービス及び／又はコンテンツ及びシグナリングデータを受信する。代案として、サービス／コンテンツ取得コントローラＪ２０１０は、サービス及び／又はコンテンツ及びこれに関連したシグナリングデータを受信するための制御を行うことができる。

インターネットインターフェースＪ２０２０は、インターネットアクセス制御モジュールを含むことができる。インターネットアクセス制御モジュールはブロードバンドチャネルを介してサービス、コンテンツ及び／又はシグナリングデータを受信する。代案で（に）、インターネットアクセス制御モジュールはサービス、コンテンツ及び／又はシグナリングデータを取得するための受信機の動作を制御できる。

ブロードキャストインターフェースＪ２０３０は、物理層モジュール及び／又は物理層Ｉ／Ｆモジュールを含むことができる。物理層モジュールは、ブロードキャストチャネルを介してブロードキャスト関連信号を受信する。物理層モジュールは、ブロードキャストチャネルを介して受信されたブロードキャスト関連信号を処理（復調、デコーディングなど）する。物理層Ｉ／Ｆモジュールは、物理層モジュールから取得した情報からＩＰデータグラムを取得したり、取得されたＩＰデータグラムを用いて特定フレーム（例えば、ブロードキャストフレーム、ＲＳフレーム又はＧＳＥ）への変換を行う。

シグナリングデコーダＪ２０４０は、ブロードキャストチャネルなどを介して取得されたシグナリングデータ又はシグナリング情報（以下、“シグナリングデータ”という。）をデコードする。

サービスマップデータベースＪ２０５０は、受信機の他の装置（例えば、シグナリングパーサー）によって処理されたシグナリングデータ又はデコードされたシグナリングデータを記憶する。

デコーダＪ２０６０は、受信機に受信されたブロードキャスト信号又はデータをデコードする。デコーダＪ２０６０は、スケジュールされたストリーミングデコーダ、ファイルデコーダ、ファイルデータベース（ＤＢ）、注文型ストリーミングデコーダ、コンポーネント同期化器、警報シグナリングパーサー、ターゲッティングシグナリングパーサー、サービスシグナリングパーサー、及び／又はアプリケーションシグナリングパーサーを含むことができる。

スケジュールされたストリーミングデコーダは、ＩＰデータグラムなどから実時間オーディオ／ビデオ（Ａ／Ｖ）に対するオーディオ／ビデオデータを抽出し、抽出されたオーディオ／ビデオデータをデコードする。

ファイルデコーダは、ＩＰデータグラムからＮＲＴデータ及びアプリケーションなどのファイルタイプデータを抽出し、抽出されたファイルタイプデータをデコードする。

ファイルＤＢは、ファイルデコーダによって抽出されたデータを記憶する。

注文型ストリーミングデコーダは、ＩＰデータグラムから注文型ストリーミングに対するオーディオ／ビデオデータなどを抽出し、抽出されたオーディオ／ビデオデータをデコードする。

コンポーネント同期化器は、スケジュールされたストリーミングデコーダ、ファイルデコーダ及び／又は注文型ストリーミングデコーダによってデコードされたデータに基づいて、コンテンツを構成するエレメント間又はサービスを構成するエレメント間の同期化を取ってコンテンツ又はサービスを構成する。

警報シグナリングパーサーは、ＩＰデータグラムなどからの警報と関連したシグナリング情報を抽出し、抽出されたシグナリング情報をパースする。

ターゲッティングシグナリングパーサーは、ＩＰデータグラムからサービス／コンテンツ個人化又はターゲッティングに関連したシグナリング情報を抽出し、抽出されたシグナリング情報をパースする。ターゲッティング（ｔａｒｇｅｔｉｎｇ）は、特定視聴者の条件を満たすコンテンツ又はサービスを提供するアクションである。すなわち、ターゲッティングは、特定視聴者の条件を満たすコンテンツ又はサービスを識別し、識別されたコンテンツ又はサービスを視聴者に提供するアクションである。

サービスシグナリングパーサーは、ＩＰデータグラムなどからサービス／コンテンツ及び／又はサービススキャンに関連したシグナリング情報を抽出し、抽出されたシグナリング情報をパースする。サービス／コンテンツに関連したシグナリング情報は、放送システム情報及び／又は放送シグナリング情報を含む。

アプリケーションシグナリングパーサーは、ＩＰデータグラムなどからのアプリケーションの取得に関連したシグナリング情報を抽出し、抽出されたシグナリング情報をパースする。アプリケーションの取得に関連したシグナリング情報は、トリガー、ＴＤＯパラメータテーブル（ＴＰＴ）及び／又はＴＤＯパラメータエレメントを含むことができる。

ターゲッティングプロセッサＪ２０７０は、ターゲッティングシグナリングパーサーによってパースされたサービス／コンテンツターゲッティングに関連した情報を処理する。

プロセッサＪ２０８０は、受信されたデータをディスプレイする一連のプロセスを行う。

プロセッサＪ２０８０は、警報プロセッサ、アプリケーションプロセッサ及び／又はＡ／Ｖプロセッサを含むことができる。

警報プロセッサは、警報に関連したシグナリング情報に基づいて警報データを取得するように受信機を制御し、警報データをディスプレイするプロセスを行う。

アプリケーションプロセッサは、アプリケーションに関連した情報を処理し、そのアプリケーションに関連したディスプレイパラメータ及びダウンロードされたアプリケーションの状態を処理する。

Ａ／Ｖプロセッサは、デコードされたオーディオデータ、ビデオデータ及び／又はアプリケーションデータに基づいてオーディオ／ビデオレンダリングに関連した動作を行う。

管理部Ｊ２０９０は、装置マネジャー、及び／又はデータ共有及び通信ユニットを含む。

装置マネジャーは、接続及びデータ交換を含めて、インターロック（ｉｎｔｅｒｌｏｃｋｅｄ）され得る外部装置の追加／削除／更新などの外部装置に対する管理を行う。

データ共有及び通信ユニットは、受信機及び外部装置（例えば、同伴者装置）間のデータ伝送及び交換に関連した情報を処理し、これに関連した動作を行う。伝送可能及び交換可能なデータは、シグナリングデータ、ＰＤＩテーブル、ＰＤＩユーザデータ、ＰＤＩＱ＆Ａ、及び／又はＡ／Ｖデータであってもよい。

再分配モジュールＪ２１００は、受信機がブロードキャスト信号を直接受信できない場合、サービス／コンテンツ及び／又はサービス／コンテンツデータに関連した情報の取得を行う。

外部管理装置Ｊ２１１０は、ブロードキャストサービス／コンテンツを提供する放送受信機の外部に設けられるブロードキャストサービス／コンテンツサーバーなどのモジュールである。外部管理装置として機能するモジュールが放送受信機に提供されてもよい。

図６７は、本発明の一実施例に係る、放送網の伝送ストリームとインターネット網（異種網）の伝送ストリーム間の同期化のためのタイムラインコンポーネント（Ｔｉｍｅｌｉｎｅｃｏｍｐｏｎｅｎｔ）を示す図である。

前述した放送システムの受信機で、放送網及びインターネット網のような異種網を介して伝送されるストリームが、一つのサービスのために同期化して用いられる可能性がある。例えば、図示のように、放送網でビデオストリームが伝送され、インターネット網でオーディオストリームが伝送される場合、両ストリームは、一つのサービスのために同期化して復号化され、再生されなければならない。すなわち、一つのサービスを用いるために、放送網でビデオを取得し、インターネット網でオーディオを取得しなければならない。例えば、同じコンテンツに対して、放送網で提供する言語と異なる言語で製作されたオーディオで視聴したい視聴者は、自身の所望する言語で製作された、該当のコンテンツのオーディオをインターネット網で受信して用いることができる。

しかし、両ストリームは別個のタイムライン（ｔｉｍｅｌｉｎｅ）を有するため、両タイムライン間のマッピングを可能にするメカニズムが必要である。ここで、タイムラインは、各伝送網を介して伝送されるデータ又はコンテンツが再生又は復号される基準となる絶対的な又は相対的な時間を示すことができる。すなわち、放送網を介して伝送されるビデオが示す内容と、インターネット網を介して伝送されるオーディオが示す内容とが、サービス内で一致する必要がある。

本発明の一実施例では、放送網とインターネット網などの異種網を介して伝送されるストリーム間の同期化のためにタイムラインコンポーネントを用いる方法及び装置を提案する。タイムラインコンポーネントストリームは、一つ以上のタイムラインコンポーネントＡＵ（ａｃｃｅｓｓｕｎｉｔ）を含むことができる。タイムラインコンポーネントＡＵは、タイムラインコンポーネント内で、連続して存在することができる。

タイムラインコンポーネントＡＵが、放送網で伝送されるストリームのタイムラインに、インターネット網で伝送されるストリームのタイムラインをマップする例を示している。放送網で伝送されるパケットのヘッダーに、放送網で伝達されるストリームのタイムラインに関する情報が含まれている場合、放送網を介して伝送可能なタイムラインコンポーネントＡＵは、異種網（例えば、インターネット網）を介して伝送されるストリームのＤＴＳ（ＤｅｃｏｄｉｎｇＴｉｍｅＳｔａｍｐ）、ＰＴＳ（ＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅＳｔａｍｐ）などのタイムスタンプ情報などを含むことができる。このような異種網（例えば、インターネット網）を介して伝送されるストリームのタイムラインに関する情報がタイムラインコンポーネントＡＵに含まれる場合、異種網（例えば、インターネット網）を介して伝送されるストリームのタイムラインに関する情報は、放送網を介して伝送されるストリームと同じパケット構造にパケット化することができる。これによって、パケットヘッダーに含まれる放送網の伝送ストリームのタイムスタンプとインターネット網を介して伝達されるストリームのタイムスタンプとを一対一でマップすることができ、両ストリームを一つのタイムラインで同期化して復号化し再生することができる。前述したタイムスタンプ情報は、外部網（例えば、異種網、インターネット網など）で伝送されるストリームのタイムラインを構成するためのタイムラインリファレンス値を意味することもできる。

プレゼンテーションタイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅｓｔａｍｐ；ＰＴＳ）は、視聴者に提示されるとき、プログラムの個別エレメンタリストリーム（例えば、ビデオ、オーディオ、サブタイトル）の同期化を達成するために用いられるＭＰＥＧ伝送ストリーム、ＭＰＥＧプログラムストリーム、又は類似のデータストリーム内のタイムスタンプメタデータフィールドである。ＰＴＳは、プログラムの全クロックリファレンス、プログラムクロックリファレンス（ＰＣＲ）又はシステムクロックリファレンス（ＳＣＲ）に関連した単位で与えられ、これはまた、伝送ストリーム又はプログラムストリームで送信される。

デコードタイムスタンプ（ＤｅｃｏｄｅＴｉｍｅＳｔａｍｐ；ＤＴＳ）は、アクセスユニットが受信機バッファから瞬間的に除去されてデコードされる時間を示す。これは、ピクチャレンダリングがＢピクチャに用いられる場合にのみプレゼンテーションタイムスタンプ（ＰＴＳ）と異なる。ＤＴＳが用いられると、ＰＴＳはビットストリームで提供されてもよい。

前述した内容は、一つの網を介して伝送されるストリームが別個のタイムラインを使用する場合にも同様の適用が可能である。例えば、前述した方法を用いると、複数の異種網を介して伝送されるストリームを集めて視聴者に提供する中継サービス事業者は、別個のストリームに対する同期化のための再処理を直接行う必要がない。

図６８は、本発明の一実施例に係るタイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。

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

タイムラインコンポーネントＡＵは、識別子情報、バージョン情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報、ＰＴＳ＿ｆｌａｇ情報、ＤＴＳ＿ｆｌａｇ情報、ｍｅｄｉａ＿ｔｉｍｅ＿ｆｌａｇ情報、ＮＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報、ＰＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報、ｔｉｍｅｃｏｄｅ＿ｆｌａｇ情報、ＰＣＲ＿ｔｉｍｅ＿ｆｌａｇ情報、ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報、位置情報、タイムスケール情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報、ＮＴＰ＿ｔｉｍｅ＿ＰＴＳ情報、ＮＴＰ＿ｔｉｍｅ＿ＤＴＳ情報、ＰＴＰ＿ｔｉｍｅ＿ＰＴＳ情報、ＰＴＰ＿ｔｉｍｅ＿ＤＴＳ情報、ｔｉｍｅｃｏｄｅ＿ＰＴＳ情報、ｔｉｍｅｃｏｄｅ＿ＤＴＳ情報、ＰＣＲ＿ｔｉｍｅ＿ＰＴＳ情報、及び／又はＰＣＲ＿ｔｉｍｅ＿ＤＴＳ情報を含むことができる。

識別子情報は、タイムラインコンポーネントＡＵの構造を固有に示す識別子である。

バージョン情報は、下位ＰＴＳ、ＤＴＳなどのタイムスタンプフィールドの長さを示すことができる。例えば、バージョン情報の値が１であれば、６４ビット、０であれば、３２ビットの長さを有することができる。

ＡＵ＿ｌｅｎｇｔｈ情報は、タイムラインコンポーネントＡＵの長さを示す。

ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵが外部網を介して伝送されるストリームの位置情報を含んでいるか否かを示す。

ＰＴＳ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵがＰＴＳ値を含んでいるか否かを示す。

ＤＴＳ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵがＤＴＳ値を含んでいるか否かを示す。

ｍｅｄｉａ＿ｔｉｍｅ＿ｆｌａｇ情報は、メディアタイム（ｍｅｄｉａｔｉｍｅ）形式のタイムスタンプを含んでいるか否かを示す。

ＮＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報は、ＮＴＰ形式のタイムスタンプを含んでいるか否かを示す。

ＰＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報は、ＰＴＰ形式のタイムスタンプを含んでいるか否かを示す。

ｔｉｍｅｃｏｄｅ＿ｆｌａｇ情報は、ＳＭＰＴＥタイムコード（ｔｉｍｅｃｏｄｅ）形式のタイムスタンプを含んでいるか否かを示す。

ＰＣＲ＿ｔｉｍｅ＿ｆｌａｇ情報は、ＭＰＥＧ−２ＴＳのＰＣＲベースのタイムスタンプを含んでいるか否かを示す。

ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報は、位置フィールドの長さを示す。

位置情報は、異種網で伝送されるストリームのＵＲＬ又は固有ＩＤを示す。位置情報が固有ＩＤを示す場合、シグナリングデータなどの情報と連動して用いられてもよい。

タイムスケール情報は、メティアタイムスケール（ｍｅｄｉａｔｉｍｅｓｃａｌｅ）を示す。タイムスケール情報は、他の情報が示す時間の単位を識別する情報である。

ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報は、メディアタイム形式で表現されたＰＴＳを示す。

ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報は、メディアタイム形式で表現されたＤＴＳを示す。

ＮＴＰ＿ｔｉｍｅ＿ＰＴＳ情報は、ＮＰＴ形式で表現されたＰＴＳを示す。

ＮＴＰ＿ｔｉｍｅ＿ＤＴＳ情報は、ＮＰＴ形式で表現されたＤＴＳを示す。

ＰＴＰ＿ｔｉｍｅ＿ＰＴＳ情報は、ＰＴＰ形式で表現されたＰＴＳを示す。

ＰＴＰ＿ｔｉｍｅ＿ＤＴＳ情報は、ＰＴＰ形式で表現されたＤＴＳを示す。

ＰＴＰ＿ｔｉｍｅ＿ＰＴＳ又はＰＴＰ＿ｔｉｍｅ＿ＤＴＳ情報は、３２ビット、６４ビット又は８０ビットのいずれかのサイズを有することができる。

ｔｉｍｅｃｏｄｅ＿ＰＴＳ情報は、ＳＭＰＴＥタイムコード形式で表現されたＰＴＳを示す。

ｔｉｍｅｃｏｄｅ＿ＤＴＳ情報は、ＳＭＰＴＥタイムコード形式で表現されたＤＴＳを示す。

ＰＣＲ＿ｔｉｍｅ＿ＰＴＳ情報は、ＰＣＲ形式で表現されたＰＴＳを示す。

ＰＣＲ＿ｔｉｍｅ＿ＤＴＳ情報は、ＰＣＲ形式で表現されたＤＴＳを示す。

本発明の一実施例によれば、受信機は、位置情報によって識別される外部網のストリームに、タイムラインコンポーネントＡＵに含まれる一つ以上のタイムスタンプ情報を適用して、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期を取ることができる。

図６９は、本発明の他の実施例に係る、タイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。

タイムラインコンポーネントＡＵは、識別子情報、バージョン情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報、ＰＴＳ＿ｆｌａｇ情報、ＤＴＳ＿ｆｌａｇ情報、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報、ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報、位置情報、タイムスケール情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＰＴＳ情報、及び／又はｔｉｍｅｓｔａｍｐ＿ｔｏ＿ＤＴＳ情報（又は、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＤＴＳ情報）を含むことができる。

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

ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報は、マップしようとするタイムラインのタイムスタンプ形式を示す。例えば、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報の値が０である場合には、３２ビット形式を用いることを示し、１である場合には、将来６４ビット形式を用いることを示すことができる。

ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報は、マップしようとするタイムラインのタイムスタンプのタイプを示す。例えば、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報の値が、０ｘ００の場合、メディアタイムであることを示し、０ｘ０１の場合、ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０２の場合、ＰＴＰであることを示し、０ｘ０３の場合、タイムコードであることを示し、０ｘ０４−０ｘ１Ｆの場合には、将来に定義することができ、そのために予約されてもよい。

タイムスケール情報は、マップしようとするタイムラインのメディアタイムを表現するタイムスケールを示すことができる。例えば、ＭＰＥＧ−２ＴＳの場合、タイムスケールは９０Ｋ値を有することができる。

ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報は、マップしようとするタイムラインのプレゼンテーションタイムスタンプ、すなわち、再生する時点に対するメディアタイムを示すことができる。ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報は、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇの値が０である場合、３２ビット形式で示し、当該値が１である場合、６４ビットで示すことができる。

ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報は、マップしようとするタイムラインのデコーディングタイムスタンプ、すなわち、デコードする時点に対するメディアタイムを示すことができる。ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報は、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇの値が０である場合には、３２ビットの形式で示し、当該値が１である場合には、６４ビットで示すことができる。

ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＰＴＳ情報は、マップしようとするタイムラインのタイムスタンプタイプによるプレゼンテーションタイムスタンプ、すなわち、再生する時点を示すことができる。ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＰＴＳ情報は、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇの値が０である場合、３２ビットの形式で示し、当該値が１である場合、６４ビットで示すことができる。例えば、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドの値がＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）を示す場合、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＰＴＳフィールド値は、ＮＴＰベース再生時点に対するタイムスタンプ値を有することができる。

ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＤＴＳ情報は、マップしようとするタイムラインのタイムスタンプタイプによるデコーディングタイムスタンプ、すなわち、デコードする時点を示すことができる。ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＤＴＳ情報は、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ値が０である場合、３２ビットの形式で示し、当該値が１である場合、６４ビットで示すことができる。例えば、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドの値がＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）を示す場合、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＰＴＳフィールド値は、ＮＴＰベースデコーディング時点に対するタイムスタンプ値を有することができる。

図７０は、本発明の一実施例に係る、放送網の伝送パケットのタイムスタンプがない場合に、タイムラインコンポーネントを用いて、放送網で伝送されるストリームと、異種網（例えばインターネット網）で伝送されるストリームとの同期を取る方法を示す図である。

前述したタイムラインコンポーネントを用いる、異種網を介して伝送される伝送ストリーム間のタイムライン共有を通じた同期化方法において、タイムライン共有は、放送網の伝送ストリームのパケットヘッダーのタイムスタンプと、パケットペイロードのタイムラインコンポーネントＡＵに含まれるインターネット網の伝送ストリームのタイムスタンプとを一対一マップすることによって行うことができる。

しかしながら、放送網伝送パケットのヘッダーにタイムスタンプ関連情報が存在しない場合がありうる。

同図のように、伝送パケットのヘッダーにタイムスタンプと関連した情報が存在しない場合、タイムラインにおける根源（ｏｒｉｇｉｎ）タイムスタンプに関する追加情報が必要である。放送網とインターネット網とのタイムライン共有は、根源タイムスタンプと前述したインターネット網伝送ストリームのタイムスタンプとを一対一マップすることによって達成することができる。

根源(origin)タイムスタンプと異種網（例えば、インターネット網）の伝送ストリームのタイムスタンプ関連情報は、タイムラインコンポーネントＡＵに含めることができる。

根源タイムスタンプは、基準となるタイムライン上のタイムスタンプと定義することができる。例えば、前述した実施例で、放送網で伝送されるストリームに対するタイムスタンプを根源タイムスタンプと定義することができる。

根源タイムスタンプは、内部網（例えば、放送網）で伝送されるストリームのタイムラインを構成するためのタイムラインリファレンス値を意味することもできる。

図７１は、本発明の他の実施例に係るタイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。

本発明の他の実施例に係るタイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）は、前述したタイムラインコンポーネントＡＵのシンタクスに、根源タイムスタンプに関連した情報をさらに含むことができる。

タイムラインコンポーネントＡＵは、識別子情報、バージョン情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報、ｏｒｉｇｉｎ＿ＰＴＳ＿ｆｌａｇ情報、ｏｒｉｇｉｎ＿ＤＴＳ＿ｆｌａｇ情報、ｏｒｉｇｉｎ＿ＰＴＳ情報、ｏｒｉｇｉｎ＿ＤＴＳ情報、ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報、ＰＴＳ＿ｆｌａｇ情報、ＤＴＳ＿ｆｌａｇ情報、ｍｅｄｉａ＿ｔｉｍｅ＿ｆｌａｇ情報、ＮＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報、ＰＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報、ｔｉｍｅｃｏｄｅ＿ｆｌａｇ情報、ＰＣＲ＿ｔｉｍｅ＿ｆｌａｇ情報、ｌｏｃａｔｉｏｎ＿ＵＲＬ＿ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ＿ＵＲＬ情報、タイムスケール情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報、ＮＴＰ＿ｔｉｍｅ＿ＰＴＳ情報、ＮＴＰ＿ｔｉｍｅ＿ＤＴＳ情報、ＰＴＰ＿ｔｉｍｅ＿ＰＴＳ情報、ＰＴＰ＿ｔｉｍｅ＿ＤＴＳ情報、ｔｉｍｅｃｏｄｅ＿ＰＴＳ情報、ｔｉｍｅｃｏｄｅ＿ＤＴＳ情報、ＰＣＲ＿ｔｉｍｅ＿ＰＴＳ情報、及び／又はＰＣＲ＿ｔｉｍｅ＿ＤＴＳ情報を含むことができる。

前述したタイムラインコンポーネントＡＵのシンタクスに含まれる情報と同じ名称を有する情報に関する説明は、前述した説明に代える。

ｏｒｉｇｉｎ＿ＰＴＳ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵがｏｒｉｇｉｎ＿ＰＴＳ値を含んでいるか否かを示す。

ｏｒｉｇｉｎ＿ＤＴＳ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵが根源ＤＴＳ値を含んでいるか否かを示す。

ｏｒｉｇｉｎ＿ＰＴＳ情報は、タイムラインマッピングの基準となるベースタイムライン上で現在パケットのＰＴＳを示す。

ｏｒｉｇｉｎ＿ＤＴＳ情報は、タイムラインマッピングの基準となるベースタイムライン上で現在パケットのＤＴＳを示す。

ｌｏｃａｔｉｏｎ＿ＵＲＬ＿ｌｅｎｇｔｈ情報は、ｌｏｃａｔｉｏｎ＿ＵＲＬ情報の長さを示す。

ｌｏｃａｔｉｏｎ＿ＵＲＬ情報は、異種網を介して伝送されるストリームのＵＲＬを示すか、又は、異種網を介して伝送されるストリームを固有に識別する識別子を示すことができる。

受信機は、放送網の伝送ストリームのパケットペイロードからタイムラインコンポーネントＡＵを取得し、タイムラインコンポーネントＡＵでｏｒｉｇｉｎ＿ＰＴＳ情報及び／又はｏｒｉｇｉｎ＿ＤＴＳ情報をパーシングし、それらの情報に基づいて、放送網の伝送ストリームに対するタイムスタンプ情報を得ることができる。受信機は、ｏｒｉｇｉｎ＿ＰＴＳ情報及び／又はｏｒｉｇｉｎ＿ＤＴＳ情報を通じて取得した放送網の伝送ストリームのタイムスタンプとタイムラインコンポーネントＡＵに含まれる異種網に対するタイムスタンプ関連情報を用いて、放送網の伝送ストリームと異種網の伝送ストリームとの同期を取ることができる。

図７２は、本発明の他の実施例に係るタイムラインコンポーネントＡＵのシンタクスを示す図である。

同図では、タイムラインコンポーネントＡＵは、放送網或いはインターネット網で伝送されるメディアストリームに関連した追加のメタデータを含むことができる。このようなメタデータのうち、メディアストリーム及び関連タイムラインに対するメタデータを含むタイムラインコンポーネントＡＵを示している。

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

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

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

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

ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｌａｇ情報は、根源タイムスタンプに関連した情報を含むか否かを示すことができる。

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

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

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

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

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

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

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

ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔ情報は、タイムラインマッピングの基準となり得るベースタイムラインに対するタイムスタンプのフォーマットを示すことができる。例えば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔ情報の値が０ｘ００であれば、メディアタイムであることを示し、０ｘ０１であれば、ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、ｔｉｍｅｃｏｄｅであることを示すことができ、０ｘ０４−０ｘ０Ｆの値は、将来の拡張のために予約されてもよい。

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

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

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

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

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

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

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

ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅｓ（）情報は、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈ長さだけ私的に（ｐｒｉｖａｔｅｌｙ）定義したり、将来に拡張内容を含み得る領域を示す。

タイムスケール情報は、メディアタイム表現時に使用できるタイムスケールを示すことができる。

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

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

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

図７３は、本発明の他の実施例に係る、タイムラインリファレンスシグナリング情報を用いて、放送網を介して伝送されるストリームと異種網を介して伝送されるストリーム間の同期を取る方法を示す図である。

前述したように、放送網でビデオストリームが伝送され、インターネット網でオーディオストリームが伝送される場合、両ストリームは一つのサービスのために同期化し、復号及び／又は再生されなければならない。しかし、両ストリームは別個のタイムラインを有するので、両タイムライン間のマッピング（ｍａｐｐｉｎｇ）が可能なメカニズムが必要である。

本発明の他の実施例は、タイムラインリファレンスシグナリング情報を用いて、放送網とインターネット網などの異種網で伝送される少なくとも一つのストリームを同期化することができる。すなわち、前述した放送システムの受信機が、放送網とインターネット網などの異種網で伝送されるストリームを一つのサービスのために同期化して用いることができる。

本発明の他の実施例に係る送信機は、タイムラインリファレンスシグナリング情報を用いて、放送網で伝送されるストリームと異種網で伝送されるストリームを同期化させ得る情報を伝送することができる。そのために、本発明の他の実施例に係る送信機は、シグナリングエンコーダ（ｓｉｇｎａｌｉｎｇｅｎｃｏｄｅｒ）（図示せず）、放送網インターフェース（ｂｒｏａｄｃａｓｔｎｅｔｗｏｒｋｉｎｔｅｒｆａｃｅ）（図示せず）、及び／又は異種網インターフェース（ｈｅｔｅｒｏｇｅｎｅｉｔｙｎｅｔｗｏｒｋｉｎｔｅｒｆａｃｅ）（図示せず）を含むことができる。

シグナリングエンコーダは、少なくとも一つの網を介して伝送されるストリームを同期化するためのメタデータを含むタイムラインリファレンスシグナリング情報をエンコードする。

シグナリングエンコーダは、放送コンテンツの第１部分（例えば、ビデオ情報）及びタイムラインリファレンスシグナリング情報を含む放送ストリーム（ｂｒｏａｄｃａｓｔｓｔｒｅａｍ）をエンコードする第１エンコーダ、及び放送コンテンツの第２部分（例えば、オーディオ情報）を含む異種ストリーム（ｈｅｔｅｒｏｇｅｎｅｉｔｙｓｔｒｅａｍ）をエンコードする第２エンコーダを含むことができる。

タイムラインリファレンスシグナリング情報は、放送ストリーム及び異種ストリームのうち少なくとも一つのタイムライン（ｔｉｍｅｌｉｎｅ）を構成する（ｃｏｎｓｔｉｔｕｔｉｎｇ）少なくとも一つのタイムラインリファレンス情報を含むことができる。

放送網インターフェースは、エンコードされた放送ストリームを放送網で伝送することができる。

異種網インターフェースは、エンコードされた異種ストリームを異種網で伝送することができる。

また、本発明の他の実施例に係る受信機は、タイムラインリファレンスシグナリング情報を用いて、放送網で伝送されるストリームと異種網で伝送されるストリームとを同期化させることができる。そのために、本発明の他の実施例に係る受信機は、放送網インターフェース（ｂｒｏａｄｃａｓｔｎｅｔｗｏｒｋｉｎｔｅｒｆａｃｅ）（図示せず）、異種網インターフェース（ｈｅｔｅｒｏｇｅｎｅｉｔｙｎｅｔｗｏｒｋｉｎｔｅｒｆａｃｅ）（図示せず）、及び／又はプロセッサ（ｐｒｏｃｅｓｓｏｒ）（図示せず）を含むことができる。

放送網インターフェースは、放送コンテンツの第１部分（例えば、ビデオ情報）を含む放送ストリームを放送網で受信することができる。放送網インターフェースは、前述したブロードキャストインターフェースＪ２０３０及び／又は伝送パケットインターフェース（ＴｒａｎｓｐｏｒｔＰａｃｋｅｔＩｎｔｅｒｆａｃｅ）Ｊ３２０７０を含むことができる。

異種網インターフェースは、放送コンテンツの第２部分（例えば、オーディオ情報）を含む異種ストリームを異種網で受信することができる。異種網インターフェースは、前述したインターネットインターフェースＪ２０２０及び／又はブロードバンドパケットインターフェース（ＢｒｏａｄｂａｎｄＰａｃｋｅｔＩｎｔｅｒｆａｃｅ）Ｊ３２０８０を含むことができる。

放送ストリームは、少なくとも一つの網（ｎｅｔｗｏｒｋ）で伝送されるストリームを同期化するためのメタデータを含むタイムラインリファレンスシグナリング情報を含むことができる。タイムラインリファレンスシグナリング情報は、放送ストリーム及び異種ストリームのうち少なくとも一つのタイムラインを構成する少なくとも一つのタイムラインリファレンス情報を含むことができる。

プロセッサは、タイムラインリファレンスシグナリング情報に基づいて、放送ストリーム及び異種ストリームを用いて放送コンテンツを形成（ｃｏｎｆｉｇｕｒｉｎｇ）することができる。プロセッサは、前述したプロセッサＪ２０８０及び／又はＡ／ＶプロセッサＪ３２１１０を含むことができる。

本発明の他の実施例に係る放送ストリームは、パケットヘッダー及び／又はパケットペイロードを含むことができる。パケットヘッダーは、放送ストリームのためのタイムスタンプを含むことができる。パケットペイロードは、タイムラインリファレンスシグナリング情報を含むことができる。ただし、これに限定されず、タイムラインリファレンスシグナリング情報はパケットヘッダーにも含まれてもよい。

タイムラインリファレンスシグナリング情報がパケットペイロードに含まれて伝送される場合、タイムラインリファレンスシグナリング情報は、タイムラインリファレンス情報ＡＵ（ａｃｃｅｓｓｕｎｉｔ）に含まれてもよい。タイムラインコンポーネントＡＵは、タイムラインリファレンス情報ＡＵを含むことができる。ただし、これに限定されず、タイムラインリファレンス情報ＡＵは、タイムラインコンポーネントＡＵと独立して存在してもよい。

タイムラインリファレンスシグナリング情報がパケットヘッダーに含まれて伝送される場合、タイムラインリファレンスシグナリング情報は、拡張されたヘッダー拡張に含まれてもよい。

放送網で伝送されるタイムラインコンポーネントＡＵ及び／又はタイムラインリファレンス情報ＡＵは、内部網である放送網で伝送されるストリームのタイムラインを構成する内部タイムラインリファレンス情報、及び／又は外部網である異種網（例えば、インターネット網）で伝送されるストリームのタイムラインを内部網とマップさせ得る外部タイムラインリファレンス情報を含むことができる。

前述したタイムスタンプは、ＤＴＳ及び／又はＰＴＳのように、デコーディングを始める時間及び／又はプレゼンテーションを始める時間を意味する。したがって、前述したタイムスタンプは、デコーディングタイム及びプレゼンテーションタイムのように特定のイベントが起きる時点だけを示す。

ただし、本発明の他の実施例に係るタイムラインリファレンス情報は、内部網及び／又は外部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。このとき、リファレンスクロック値は、メディアストリームのタイムラインを構成する時点を示す時刻情報を意味する。ここで、タイムラインを構成する時点は、放送システム内であらかじめ定められた時点に該当してもよい。例えば、リファレンスクロック値は、ＤＴＳ、ＰＴＳなどのタイムスタンプ（ｔｉｍｅｓｔａｍｐ）情報及び／又はウォールクロック（ｗａｌｌｃｌｏｃｋ）などを含むことができる。ただし、リファレンスクロック値は必ずしもＤＴＳ及び／又はＰＴＳに限定されない。

また、タイムラインリファレンス情報ＡＵは、放送網伝送ストリームと同じパケット構造でパケット化されてもよい。

本発明の他の実施例によれば、受信機は、タイムラインリファレンス情報ＡＵに基づいて、放送網と異種網（例えば、インターネット網）で伝送される両ストリームを一つのタイムラインで同期化して復号化及び／又は再生することができる。例えば、受信機及び／又はプロセッサは、タイムスタンプ及び／又はタイムラインリファレンスシグナリング情報に基づいて、放送ストリームと異種ストリームを用いて放送コンテンツを構成することができる。受信機及び／又はプロセッサは、内部タイムラインリファレンス情報と外部タイムラインリファレンス情報に基づいて、放送網で伝送されるストリームと異種網で伝送されるストリームをマップすることができる。外部タイムラインリファレンス情報がＤＴＳ及び／又はＰＴＳなどのタイムスタンプ情報を含む場合には、受信機及び／又はプロセッサは、外部タイムラインリファレンス情報と内部網で伝送されるメディアストリームのタイムラインを構成するタイムスタンプ情報に基づいて、放送網で伝送されるストリームと異種網で伝送されるストリームをマップすることができる。

前述した内容は、一つの網で伝送されるストリームが別個のタイムラインを使用する場合にも同様に適用することができる。例えば、異種ストリームが放送ストリームに該当する場合、異種ストリームのタイムラインは放送ストリームのタイムラインと異なってもよい。

前述した方法によれば、複数の異種網で伝送されるストリームを集めて視聴者に提供する中継サービスプロバイダは、別個のストリームを同期化するための再処理を直接行う必要がない。

図７４は、本発明の他の実施例に係る、タイムラインリファレンス情報ＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。

タイムラインリファレンス情報ＡＵは、ＸＭＬなどの他の形態のフォーマットで表現されてもよい。タイムラインリファレンス情報ＡＵは、ＲＰＴ、ＡＬＣ／ＬＣＴなどの様々なメディア伝送プロトコルに適用することができ、プロトコルに適したサービスシグナリング情報と連動して用いることができる。

サービスシグナリング情報は、当該ストリームが内部網又は外部網のタイムラインリファレンスを伝送していることを示す情報、タイムラインリファレンス情報ＡＵに含まれる外部メディアＵＲＬ情報、各種のフィールドを含むか否かを示すフラグ情報、及び／又はタイムスケール情報など、各パケットに共通して適用可能な情報を含むことができる。

具体的には、タイムラインリファレンス情報ＡＵは、ＡＵ＿ｉｄｅｎｔｉｆｉｅｒ情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報、及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を含むことができる。タイムラインリファレンス情報ＡＵが含む情報を、タイムラインリファレンスシグナリング情報と呼ぶことができる。

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

ＡＵ＿ｉｄｅｎｔｉｆｉｅｒ情報は、タイムラインリファレンス情報ＡＵの構造を固有に示す識別子である。

ＡＵ＿ｌｅｎｇｔｈ情報は、タイムラインリファレンス情報ＡＵの長さを示す。

ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが外部網（例えば、インターネット網）で伝送されるストリームのＵＲＬ情報を含んでいるか否かを示す。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが内部タイムラインリファレンス情報を含んでいるか否かを示す。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが外部タイムラインリファレンス情報を含んでいるか否かを示す。

ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈ情報は、外部メディアＵＲＬ情報の長さを示す。例えば、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈ情報は、外部メディアＵＲＬ情報の長さをバイト単位で示すことができる。

ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報は、外部網（例えば、インターネット網）で伝送されるメディアの位置情報、及び／又は固有識別子（識別情報）などの情報を含むことができる。例えば、外部網で伝送されるメディアがＭＰＥＧ−ＤＡＳＨである場合、当該ＭＰＤのＵＲＬ、及び／又はＭＰＤｉｄなどの情報を含むことができる。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報は、内部タイムラインリファレンスのフォーマットを示すことができる。例えば、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報の値が０ｘ００であれば、メディアタイムであることを示し、０ｘ０１であれば、ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、タイムコードであることを示し、０ｘ０４−０ｘ１Ｆであれば、将来に定義すればよく、そのために予約されてもよい。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが内部タイムラインリファレンスに対するタイムスケールを含んでいるか否かを示す。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、内部タイムラインリファレンス値の長さを示す。例えば、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、内部タイムラインリファレンス値の長さをバイト単位（ｂｙｔｅｓ）で示すことができる。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、内部タイムラインリファレンス情報の時間単位を示す。例えば、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、内部タイムラインリファレンス値の時間単位をヘルツ（Ｈｚ）単位で示すことができる。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、内部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報は、外部タイムラインリファレンスのフォーマットを示すことができる。例えば、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報の値が、０ｘ００であれば、メディアタイムであることを示し、０ｘ０１であれば、ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、タイムコードであることを示し、０ｘ０４−０ｘ１Ｆであれば、将来に定義すればよく、そのために予約されてもよい。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが外部タイムラインリファレンスに対するタイムスケールを含んでいるか否かを示す。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、外部タイムラインリファレンス値の長さを示す。例えば、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、外部タイムラインリファレンス値の長さをバイト単位（ｂｙｔｅｓ）で示すことができる。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、外部タイムラインリファレンス情報の時間単位を示す。例えば、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、外部タイムラインリファレンス値の時間単位をヘルツ（Ｈｚ）単位で示すことができる。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、外部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。

本発明の他の実施例によれば、受信機及び／又はプロセッサは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報によって識別される外部網のストリームに、タイムラインコンポーネントＡＵ及び／又はタイムラインリファレンス情報ＡＵに含まれるｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を適用し、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期化を取ることができる。また、受信機及び／又はプロセッサは、外部メディアＵＲＬ情報、タイムラインリファレンス情報、及び／又はタイムスタンプに基づいて、放送ストリームと異種ストリームを用いて放送コンテンツを構成することができる。

図７５は、本発明の他の実施例に係る、タイムラインリファレンス情報ＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。

本発明の他の実施例に係るタイムラインリファレンス情報ＡＵは、少なくとも一つの（又は複数の）ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を含むことができる。また、本発明の他の実施例に係るタイムラインリファレンス情報ＡＵは、少なくとも一つの（又は複数の）ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を含むことができる。

具体的には、タイムラインリファレンス情報ＡＵは、ＡＵ＿ｉｄｅｎｔｉｆｉｅｒ情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報、ｎｂ＿ｏｆ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｉｄｅｎｔｉｆｉｅｒ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報、及び／又はｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を含むことができる。タイムラインリファレンス情報ＡＵが含む情報をタイムラインリファレンスシグナリング情報と呼ぶことができる。

前述したタイムラインリファレンス情報ＡＵのシンタクス（Ｓｙｎｔａｘ）に含まれる情報と同じ名称を有する情報に関する説明は、前述した説明に代えるものとする。

ｎｂ＿ｏｆ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、タイムラインリファレンス情報ＡＵに含まれたタイムラインリファレンス情報の個数を示す。

ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報は、外部網（例えば、インターネット網）で伝送されるメディアの位置情報、及び／又は固有識別子などの情報を含むことができる。例えば、外部網で伝送されるメディアがＭＰＥＧ−ＤＡＳＨである場合、当該ＭＰＤのＵＲＬ、及び／又はＭＰＤｉｄなどの情報を含むことができる。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ情報は、タイムラインリファレンス情報のタイプを示す。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ情報が‘０’であれば、タイムラインリファレンス情報のタイプは内部タイムラインリファレンス情報を示すことができる。また、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ情報が‘１’であれば、タイムラインリファレンス情報のタイプは外部タイムラインリファレンス情報を示すことができる。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｉｄｅｎｔｉｆｉｅｒ情報は、タイムラインリファレンス情報の固有識別子である。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｉｄｅｎｔｉｆｉｅｒ情報は０〜１２７の整数値で割り当てられてもよい。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報は、内部タイムラインリファレンス情報のフォーマット及び／又は外部タイムラインリファレンス情報のフォーマットを示すことができる。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報の値が０ｘ００である場合、フォーマットは、メディアタイムであることを示し、０ｘ０１である場合、フォーマットはＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０２である場合、フォーマットはＰＴＰであることを示し、０ｘ０３である場合、フォーマットはタイムコードであることを示し、０ｘ０４−０ｘ１Ｆである場合、フォーマットは将来に定義すればよく、そのために予約されてもよい。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが内部タイムラインリファレンス情報及び／又は外部タイムラインリファレンス情報に対するタイムスケール情報を含んでいるか否かを示す。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、内部タイムラインリファレンス値の長さ及び／又は外部タイムラインリファレンス値の長さを示す。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、内部タイムラインリファレンス値の長さ及び／又は外部タイムラインリファレンス値の長さをバイト単位（ｂｙｔｅｓ）で示すことができる。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、内部タイムラインリファレンス値の時間単位及び／又は外部タイムラインリファレンス値の時間単位を示す。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、内部タイムラインリファレンス値の時間単位及び／又は外部タイムラインリファレンス値の時間単位をヘルツ（Ｈｚ）単位で示すことができる。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、内部網及び／又は外部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、ｎｂ＿ｏｆ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報に基づいて少なくとも一つの値（又は、複数の値）を有することができる。ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、前述した少なくとも一つのｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報及び／又は少なくとも一つのｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を含むことができる。

本発明の他の実施例によれば、受信機は、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報によって識別される外部網のストリームに、タイムラインコンポーネントＡＵ及び／又はタイムラインリファレンス情報ＡＵに含まれる少なくとも一つのｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を適用して、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期化を取ることができる。具体的に、受信機は、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報によって識別される外部網のストリームに、タイムラインコンポーネントＡＵ及び／又はタイムラインリファレンス情報ＡＵに含まれる少なくとも一つの（又は複数の）ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報及び／又は少なくとも一つの（又は複数の）ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を適用して、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期化を取ることができる。

図７６は、本発明の他の実施例に係る、タイムラインリファレンス情報伝送を支援するＬＣＴパケットの構造を示す図である。

本発明の他の実施例に係る放送ストリームは、ＬＣＴパケットを含むことができる。本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、拡張されたヘッダー拡張に含まれて伝送されてもよい。例えば、本発明の他の実施例に係るＬＣＴパケットは、既存のヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）を拡張してタイムラインリファレンスシグナリング情報をさらに含むことができる。本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、異種網で伝送されるそれぞれのメディアストリームの同期化のための情報である。本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、前述したタイムラインリファレンス情報ＡＵと同一及び／又は類似の情報を含むことができる。前述したタイムラインリファレンスシグナリング情報は、ＲＴＰ（ｒｅａｌｔｉｍｅｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用されてもよい。

本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、前述したプロトコルに適合したサービスシグナリング情報と連動して動作することができる。サービスシグナリング情報は、当該ストリームが内部網及び／又は外部網のタイムラインリファレンスを伝送していることを示す情報、タイムラインリファレンス情報ＡＵに含まれる外部メディアＵＲＬ情報、フラグ情報、及び／又はタイムスケール情報などを含めて、各パケットに共通して適用可能な情報を含むことができる。

本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、予約フィールド（Ｒｅｓ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、ＦＥＣペイロードＩＤフィールド、及び／又はエンコーディングシンボルフィールドを含むことができる。

ＬＣＴバージョン番号フィールド（Ｖ）は、プロトコルバージョン番号を示す。例えば、このフィールドは、ＬＣＴバージョン番号を示す。ＬＣＴヘッダーのバージョン番号フィールドは、ＲＯＵＴＥバージョン番号フィールドとして解釈できる。ＲＯＵＴＥのこのバージョンは、ＬＣＴ形成ブロックのバージョン“１”を暗示的に用いる。例えば、バージョン番号は“０００１ｂ”である。

プロトコル特定指示フィールド（ＰＳＩ）は、ＬＣＴ上位プロトコルにおいて特定目的の指示子として用いられてもよい。ＰＳＩフィールドは、現在パケットがソースパケットであるか又はＦＥＣリペアパケットであるかを示す。ＲＯＵＴＥソースプロトコルが単にソースパケットだけを伝達するので、このフィールドは“１０ｂ”に設定されるはずである。伝送セッション識別子フラグフィールド（Ｓ）は、伝送セッション識別子フィールドの長さを示す。

伝送オブジェクト識別子フラグフィールド（Ｏ）は、伝送オブジェクト識別子フィールドの長さを示す。例えば、オブジェクトは一つのファイルを意味することができ、上記ＴＯＩは、各オブジェクトの識別情報であって、ＴＯＩが０であるファイルは、ＦＤＴという。

ハーフワードフラグフィールド（Ｈ）は、ＴＳＩ及びＴＯＩフィールドの長さにハーフワード（１６ビット）を追加するか否かを示す。

予約フィールド（Ｒｅｓ）は、将来の使用のために予約される。

クローズセッションフラグフィールド（Ａ）は、セッションが終了したこと又は終了が差し迫っていることことを示す。

クローズオブジェクトフラグフィールド（Ｂ）は、伝送中であるオブジェクトが終了したこと又は終了が差し迫っていることことを示す。

ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）は、ＬＣＴヘッダーの全長を３２ビットワードの単位で示す。

コードポイントフィールド（ＣＰ）は、このパケットによって送信されたペイロードのタイプを示す。ペイロードのタイプによって、追加のペイロードヘッダーが追加されてペイロードデータをプレフィックス（ｐｒｅｆｉｘ）する。

伝送セッション識別子フィールド（ＴＳＩ）は、セッションの固有識別子である。ＴＳＩは、特定伝送者からの全セッションのうち一つのセッションを固有に識別する。各ＴＳＩフィールドは、ＭＰＥＧ−ＤＡＳＨの各コンポーネント及び／又はリプレゼンテーションにマップすることができる。

このフィールドは、ＲＯＵＴＥ内の伝送セッションを識別する。伝送セッションのコンテクストはＬＳＩＤ（ＬＣＴＳｅｓｓｉｏｎＩｎｓｔａｎｃｅｄｅｓｃｒｉｐｔｉｏｎ）によって提供される。ＬＳＩＤは、ＲＯＵＴＥセッションの各構成ＬＣＴ伝送セッションで何が伝送されるかを定義する。各伝送セッションは、ＬＣＴヘッダー内の伝送セッション識別子（ＴＳＩ）によって固有に識別される。ＬＳＩＤは、ＬＣＴ伝送セッションを含む同一のＲＯＵＴＥセッションで伝送することができる。通信網、放送網、インターネット網、ケーブル網、及び／又は衛星網で伝送されてもよいが、ＬＳＩＤが伝送される手段はこれらに限定されない。例えば、ＬＳＩＤは、ＴＳＩの値が‘０’である特定ＬＣＴ伝送セッションで伝送されてもよい。ＬＳＩＤは、ＲＯＵＴＥセッションで伝送される全伝送セッションに対するシグナリング情報を含むことができる。ＬＳＩＤは、ＬＳＩＤバージョン情報及びＬＳＩＤの有効性に関する情報を含むことができる。また、ＬＳＩＤは、ＬＣＴ伝送セッションに関する情報を提供する伝送セッション（ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ）情報を含むことができる。伝送セッション情報は、伝送セッションを識別するＴＳＩ情報、当該ＴＳＩで伝送され、ソースデータが伝送されるソースフローに関する情報を提供するソースフロー（ｓｏｕｒｃｅｆｌｏｗ）情報、当該ＴＳＩで伝送され、リペアデータが伝送されるリペアフローに関する情報を提供するリペアフロー（ｒｅｐａｉｒｆｌｏｗ）情報、及び当該伝送セッションに関する追加の特性情報を含む伝送セッションプロパティ（ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｐｒｏｐｅｒｔｙ）情報を含むことができる。

伝送オブジェクト識別子フィールド（ＴＯＩ）は、オブジェクトの固有識別子である。ＴＯＩは、このパケットがセッション内のどのオブジェクトに属するかを示す。各ＴＯＩフィールドは、ＭＰＥＧ−ＤＡＳＨの各セグメントにマップすることができる。ただし、これに限定されず、各ＴＯＩフィールドは、チャンク、ＧＯＰ、及び／又はアクセスユニットのようなＭＰＥＧ−ＤＡＳＨの各セグメントの一部にマップされてもよい。

このフィールドは、現在のパケットのペイロードがこのセッション内のどのオブジェクトに属するかを示す。オブジェクトへのＴＯＩフィールドのマッピングは、拡張されたＦＤＴによって提供される。拡張されたＦＤＴは、ファイル伝達データの細部事項を特定する。これは、拡張されたＦＤＴインスタンスである。ＬＣＴパケットヘッダーと共に拡張されたＦＤＴは、伝達オブジェクトに対するＦＤＴ同等記述（ＦＤＴ−ｅｑｕｉｖａｌｅｎｔｄｅｓｃｒｉｐｔｉｏｎ）を生成するために用いられてもよい。拡張されたＦＤＴは、リファレンスとして埋め込み（ｅｍｂｅｄ）又は提供されてもよい。リファレンスとして提供されると、拡張されたＦＤＴはＬＳＩＤと独立してアップデートされてもよい。これは、参照される場合には、含まれるソースフローのＴＯＩ＝０上のイン−バンド（ｉｎ−ｂａｎｄ）（帯域内）オブジェクトとして伝達されるはずである。

ヘッダー拡張フィールドは、追加情報の伝送のためのＬＣＴヘッダー拡張部分として用いられる。ヘッダー拡張は、必ずしも用いられないか、又は可変サイズを有する選択的ヘッダーフィールドを収容するためにＬＣＴに用いられる。

例えば、ＥＸＴ＿ＴＩＭＥ拡張は、タイミング情報のいくつかの類型を送信するために用いられる。これは、本文書に記述された汎用タイミング情報、すなわち、伝送者現在時間（ＳＣＴ）、予想レジデュアル時間（ＥＲＴ）及び伝送者最後変更（ＳＬＣ）時間拡張を含む。

ＦＥＣペイロードＩＤフィールドは、送信ブロック又はエンコーディングシンボルの識別情報を含む。ＦＥＣペイロードＩＤは、上記ファイルがＦＥＣエンコードされた場合の識別子を示す。例えば、ＦＥＣペイロードＩＤは、上記ＦＬＵＴＥプロトコルファイルがＦＥＣエンコードされた場合、放送局又は放送サーバーがこれを区分するために割り当てることができる。

エンコーディングシンボルフィールドは、送信ブロック又はエンコーディングシンボルのデータを含むことができる。

パケットペイロードは、オブジェクトから生成されたバイトを含む。１よりも多いオブジェクトがセッションで伝送されると、ＬＣＴヘッダー内の送信オブジェクトＩＤ（ＴＯＩ）を、パケットペイロードデータが生成されたオブジェクトを識別するために用いなければならない。

本発明の他の実施例に係るヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）は、ヘッダー拡張タイプフィールド（ＨＥＴ）、ヘッダー拡張長さフィールド（ＨＥＬ）、ＳＣＴハイフィールド、ＳＣＴローフィールド、ＥＲＴフィールド、ＳＬＣフィールド、予約フィールド、伝送者現在時間フィールド、予想レジデュアル時間フィールド、及び／又はセッション最後変更フィールドを含むことができる。また、本発明の他の実施例に係るヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）は使用フィールドを含み、使用フィールドは、ＳＣＴハイフィールド、ＳＣＴローフィールド、ＥＲＴフィールド、ＳＬＣフィールド、及び／又は予約フィールドを含むことができる。

ヘッダー拡張タイプフィールド（ＨＥＴ）は、当該ヘッダー拡張のタイプを示す。ＨＥＴフィールドは８ビットの整数であってもよい。基本的に、ＬＣＴではＨＥＴが０〜１２７の値を有する場合、３２ビットワード単位の可変長ヘッダー拡張が存在し、ＨＥＴに続くヘッダー拡張長さフィールド（ＨＥＬ）にその長さを記述する。ＨＥＴが１２８〜２５５の値を有する場合、ヘッダー拡張は、３２ビット固定長を有する。例えば、本発明の他の実施例に係るＨＥＴフィールドは、‘２’の値を有したり、又は‘１２７’以下の値を有することができ、前述したヘッダー拡張を識別することができる。

ＨＥＬフィールドは、可変長のヘッダー拡張の全長を示す。基本的に、ＬＣＴではＨＥＴが０〜１２７の値を有する場合、３２ビットワード単位の可変長ヘッダー拡張が存在し、ＨＥＴフィールドに続くＨＥＬフィールドは、ヘッダー拡張の全長を３２ビットワード単位で示す。

使用フィールド（Ｕｓｅ）は、次の３２ビット時間値のセマンティクスを示す。

ＳＣＴハイフィールドは、当該ヘッダー拡張に伝送者現在時間フィールドが含まれるか否かを示す。

ＳＣＴローフィールドは、当該ヘッダー拡張に６４ビットの伝送者現在時間フィールドが含まれるか否かを示す。

ＥＲＴフィールドは、当該ヘッダー拡張に予想レジデュアル時間フィールドが含まれるか否かを示す。

ＳＬＣフィールドは、当該ヘッダー拡張にセッション最後変更フィールドが含まれるか否かを示す。

伝送者現在時間フィールドは、伝送ジャー側の現在クロックを示し、このとき、このパケットが伝送されて１ｍｓの単位で測定され、セッションの開始からモジューロ２＾３２単位で計算された。

ＳＣＴハイフィールドが設定されると、関連した３２ビット時間値は、伝送者のウォールクロックの秒単位で時間を示す符号無し整数を提供する。ＮＴＰが用いられる特定の場合、この３２ビットは、１９００年１月１日００：００時ＧＭＴに対して秒単位の時間を示す符号無し整数を提供する（すなわち、全体６４ビットＮＴＰ時間値の最上位３２ビット）。

ＳＣＴ−ローフラグが設定されると、関連した３２ビット時間値は、サブセカンド（ｓｕｂ−ｓｅｃｏｎｄ）精密度を許容するために秒の１／２＾＾３２の倍数を示す符号無し整数を提供する。ＳＣＴ−ローフラグが設定されると、ＳＣＴ−ハイフラグも設定されなければならない。ＮＴＰが用いられる特定の場合、これらの３２ビットは６４ビットＮＴＰタイムスタンプの最下位３２ビットを提供する）。

予想レジデュアル時間フィールドは、１ｍｓの単位で測定された現在オブジェクトの送信のための又は現在セッションのための伝送者予想レジデュアル送信時間を示す。ＥＲＴフィールドを含むパケットがＴＯＩフィールドを含むと、ＥＲＴは、ＴＯＩフィールドに対応するオブジェクトを意味し、或いは、セッションを意味する。

ＥＲＴタイミング情報を含むパケットもＴＯＩフィールドを含むと、ＥＲＴは、ＴＯＩフィールドに対応するオブジェクトを意味し、或いは、セッション内のオブジェクトだけを意味する。ＥＲＴフラグが設定されると、秒の数で表現される。３２ビットはこの秒の数を示す符号無し整数を提供する。

セッション最後変更フィールドは、セッションデータに対する最後の変更が発生したサーバーウォールクロック時間を秒単位で示す。すなわち、これは、伝達セッションに対する最後の（最も最近の）伝送オブジェクトの追加、変更又は除去が発生した時間を示す。変更及び追加の場合、この時間の前に伝送されていない新しいデータが伝送される旨を示す。除去の場合、ＳＬＣは、いくつかの以前データがそれ以上伝送されない旨を示す。ＳＬＣフィールドが設定されると、関連した３２ビット時間値は、時間を秒単位で示す符号無し整数を提供する。ＮＴＰが用いられる特定の場合、これらの３２ビットは、１９００年１月１日００：００時ＧＭＴに対して秒単位の時間を示す符号無し整数を提供する（すなわち、全６４ビットＮＴＰ時間値の最上位３２ビット）。この場合、３２ビット時間の循環（ｗｒａｐａｒｏｕｎｄ）のハンドリングは、ＮＴＰ及びＬＣＴの範囲外にある。任意の場合、ＳＬＣ情報と共にＥＸＴ＿ＴＩＭＥヘッダー拡張を含むパケットも、ＳＣＴハイ情報を含むことが好適であろう。

本発明の他の実施例に係るＬＣＴパケットは、既存のヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）を拡張して、前述したタイムラインリファレンスシグナリング情報（ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報）をさらに含むことができる。

本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、ＩＴＲハイ情報、ＩＴＲロー情報、ＥＴＲハイ情報、ＥＴＲロー情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＩＴＲＳｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＥＴＲＳｃａｌｅ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲＦｏｒｍａｔ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲＦｏｒｍａｔ）、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報（ＵＲＬ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（内部タイムラインリファレンス）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（外部タイムラインリファレンス）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（内部タイムラインリファレンスタイムスケール）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（外部タイムラインリファレンスタイムスケール）、及び／又はｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報（外部メディアＵＲＬ）を含むことができる。

また、本発明の他の実施例に係るヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）は使用情報を含み、使用情報は、ＩＴＲハイ情報、ＩＴＲロー情報、ＥＴＲハイ情報、ＥＴＲロー情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＩＴＲＳｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＥＴＲＳｃａｌｅ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲＦｏｒｍａｔ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲＦｏｒｍａｔ）、及び／又はｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報（ＵＲＬ）をさらに含むことができる。

ＩＴＲハイ情報及び／又はＩＴＲロー情報は、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報と呼ぶことができる。ＥＴＲハイ情報及び／又はＥＴＲロー情報は、前述したｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報と呼ぶことができる。

ＩＴＲＨｉ（ＩｎｔｅｒｎａｌＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅＨｉｇｈＦｌａｇ）情報は、当該ヘッダー拡張に６４ビットのｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（内部タイムラインリファレンス）が含まれるか否かを示す。

ＩＴＲロー（内部タイムラインリファレンスローフラグ）情報は、当該ヘッダー拡張に３２ビットのｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（内部タイムラインリファレンス）が含まれるか否かを示す。

ＥＴＲハイ（外部タイムラインリファレンスハイフラグ）情報は、当該ヘッダー拡張に６４ビットのｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報が含まれるか否かを示す。

ＥＴＲロー（外部タイムラインリファレンスローフラグ）情報は、当該ヘッダー拡張に３２ビットのｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報が含まれるか否かを示す。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＩＴＲＳｃａｌｅ）は、当該ヘッダー拡張に３２ビットのｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報が含まれるか否かを示す。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＥＴＲＳｃａｌｅ）は、当該ヘッダー拡張に３２ビットのｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報が含まれるか否かを示す。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲＦｏｒｍａｔ）は、内部タイムラインリファレンスのフォーマットを示すことができる。例えば、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲＦｏｒｍａｔ）の値が、０ｘ００であれば、メディアタイムであることを示し、０ｘ０１であれば、ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、タイムコードであることを示し、０ｘ０４−０ｘ１Ｆであれば、将来に定義すればよく、そのために予約されてもよい。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲＦｏｒｍａｔ）は、外部タイムラインリファレンスのフォーマットを示すことができる。例えば、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲＦｏｒｍａｔ）の値が、０ｘ００であれば、メディアタイムであることを示し、０ｘ０１であれば、ＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、タイムコードであることを示し、０ｘ０４−０ｘ１Ｆであれば、将来に定義すればよく、そのために予約されてもよい。

ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報（ＵＲＬ）は、当該ヘッダー拡張にｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報（外部メディアＵＲＬ）が含まれるか否かを示すことができる。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（内部タイムラインリファレンス）は、内部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（ＥｘｔｅｒｎａｌＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅ）は、外部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（内部タイムラインリファレンスタイムスケール）は、内部タイムラインリファレンス情報の時間単位を示す。例えば、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、内部タイムラインリファレンス値の時間単位をヘルツ（Ｈｚ）単位で示すことができる。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（外部タイムラインリファレンスタイムスケール）は、外部タイムラインリファレンス情報の時間単位を示す。例えば、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、外部タイムラインリファレンス値の時間単位をヘルツ（Ｈｚ）単位で示すことができる。

ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報（外部メディアＵＲＬ）は、外部網（例えば、インターネット網）で伝送されるメディアの位置情報、及び／又は固有識別子などの情報を含むことができる。例えば、外部網で伝送されるメディアがＭＰＥＧ−ＤＡＳＨである場合、当該ＭＰＤのＵＲＬ、及び／又はＭＰＤｉｄなどの情報を含むことができる。上記フィールドの長さは、ＨＥＬフィールドで識別することができる。

本発明の他の実施例によれば、受信機及び／又はプロセッサは、放送網の放送信号からＬＣＴヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）を取得し、ヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）からタイムラインリファレンスシグナリング情報を取得することができる。また、受信機及び／又はプロセッサは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報によって識別される外部網のストリームに、タイムスタンプ、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報、及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を適用して、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期化を取ることができる。

図７７は、本発明の他の実施例に係る、タイムラインリファレンス情報伝送を支援するＬＣＴパケットの構造を示す図である。

本発明の他の実施例に係るＬＣＴパケットは、既存のヘッダー拡張を拡張してタイムラインリファレンスシグナリング情報（ＥＸＴ＿ＴＲＣ；ＥｘｔｅｎｓｉｏｎｆｏｒＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅＣｌｏｃｋ）を含むことができる。本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、前述したタイムラインリファレンス情報ＡＵと同一及び／又は類似の情報を含むことができる。前述したタイムラインリファレンスシグナリング情報は、ＲＴＰ（ｒｅａｌｔｉｍｅｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用されてもよい。

本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、前述したプロトコルに適したサービスシグナリング情報と連動して動作することができる。サービスシグナリング情報は、当該ストリームが内部網及び／又は外部網のタイムラインリファレンスを伝送していることを示す情報、タイムラインリファレンス情報ＡＵに含まれる外部メディアＵＲＬ情報、フラグ情報、及び／又はタイムスケール情報などを含めて、各パケットに共通して適用可能な情報を含むことができる。

本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、予約フィールド（Ｒｅｓ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、ＦＥＣペイロードＩＤフィールド、及び／又はエンコーディングシンボルフィールドを含むことができる。

本発明の他の実施例に係るＬＣＴパケットは、既存のヘッダー拡張（ＥＸＴ＿ＴＲＣ；ＥｘｔｅｎｓｉｏｎｆｏｒＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅＣｌｏｃｋ）を拡張して、前述したタイムラインリファレンスシグナリング情報をさらに含むことができる。

本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、ＩＴＲハイ情報、ＩＴＲロー情報、ＥＴＲハイ情報、ＥＴＲロー情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＩＴＲＳｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＥＴＲＳｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報（ＵＲＬ）、予約情報（Ｒｅｓ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲＦｏｒｍａｔ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲＦｏｒｍａｔ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（内部タイムラインリファレンス）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（外部タイムラインリファレンス）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（内部タイムラインリファレンスタイムスケール）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（外部タイムラインリファレンスタイムスケール）、及び／又はｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報（外部メディアＵＲＬ）を含むことができる。

また、本発明の他の実施例に係るヘッダー拡張（ＥＸＴ＿ＴＲＣ）は使用情報を含み、使用情報は、ＩＴＲハイ情報、ＩＴＲロー情報、ＥＴＲハイ情報、ＥＴＲロー情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＩＴＲＳｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＥＴＲＳｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報（ＵＲＬ）、Ｒｅｓｅｒｖｅｄ情報（Ｒｅｓ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲＦｏｒｍａｔ）、及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲＦｏｒｍａｔ）をさらに含むことができる。

前述したＬＣＴパケットに含まれる情報と同じ名称を有する情報に関する説明は、前述した説明に代える。

本発明の他の実施例によれば、受信機及び／又はプロセッサは、放送網の放送信号からヘッダー拡張（ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎｓ；ＥＸＴ＿ＴＲＣ）を取得し、ヘッダー拡張（ＥＸＴ＿ＴＲＣ）からタイムラインリファレンスシグナリング情報を取得することができる。また、受信機及び／又はプロセッサは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報によって識別される外部網のストリームに、タイムスタンプ、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報、及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を適用して、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期化を取ることができる。

図７８は、本発明の一実施例に係る、ＤＡＳＨが適用される放送網の伝送ストリームと異種網（例えば、インターネット網）の伝送ストリームとを、タイムラインコンポーネントＡＵを用いて同期化する方法を示す図である。

同図は、タイムラインコンポーネントを用いて、異種網を介した伝送ストリーム間の同期化方案をＤＡＳＨに適用した実施例を示す。本実施例では、ビデオストリームを放送網で伝送し、オーディオストリームをインターネット網で伝送することができる。２つのストリームともＤＡＳＨによってカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）されてサービスされているが、互いに異なる網で伝送されるため、別途のＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）を有する独立したコンテンツ形態として別個のタイムラインを有することができる。

互いに独立したタイムラインを有する２つのストリーム間の同期化のために、タイムラインコンポーネントが放送網で伝送されるＤＡＳＨコンテンツに含まれてもよい。放送網で伝送されるビデオストリーム及びタイムラインコンポーネントストリームは、一つのコンテンツに含まれて一つのタイムラインを共有することができ、タイムラインコンポーネントは、インターネット網で伝送されるオーディオストリームのタイムライン情報を含み、この情報に基づいて受信機は、放送網のタイムラインを用いてインターネット網伝送ストリームを同期化することができる。

ＤＡＳＨコンテンツにおいてタイムラインコンポーネントストリームは、ビデオストリーム又はオーディオストリームと同様に、一つのトラック（ｔｒａｃｋ）として構成されてもよい。タイムラインコンポーネントストリームに対して、ＭＰＤ及びｔｒａｆボックスなどで提供されるタイミング情報を介してそれぞれのＡＵ単位でＤＴＳ、ＰＴＳなどのタイムスタンプが与えられ、放送網タイムラインにマップされてもよい。タイムラインコンポーネントストリームをトラックとして構成するとき、当該トラックがタイムラインコンポーネントストリームを含んでいることを識別可能なシグナリング（ｓｉｇｎａｌｉｎｇ）情報を必要としてもよい。このようなシグナリング情報は、ＩＳＯＢＭＦＦベースのＤＡＳＨ初期化セグメント（ＤＡＳＨｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔ）内のｈｄｌｒボックスに含まれてもよく、含まれたメディアのタイプを示すｈａｎｄｌｅｒ＿ｔｙｐｅと、ｍｉｎｆボックスに含まれるメディアヘッダーボックス、及びメディアストリームの具体的タイプと初期化情報を示すｓｔｓｄボックス内のサンプルエントリ（ＳａｍｐｌｅＥｎｔｒｙ）などとして提供されてもよい。

タイムラインコンポーネントは、ｈｄｌｒボックスに“ｍｅｔａ”というハンドラタイプでメタデータタイプに属することを表現することができ、“ｎｍｈｄ”というヌル（ｎｕｌｌ）メディアヘッダーボックスを含むことができる。

図７９は、本発明の一実施例に係る、ＩＳＯＢＭＦＦ（ＩＳＯｂａｓｅｍｅｄｉａｆｉｌｅｆｏｒｍａｔ）においてタイムラインコンポーネントを識別するためのサンプルエントリを示す図である。

本発明の一実施例によれば、タイムラインコンポーネントを識別するために、ｓｔｓｄボックスに含まれるストリームシグナリング情報を図示のように設定することができる。

タイムラインコンポーネントストリームをファイル内で識別するために、メタデータサンプルエントリの派生型としてＴｉｍｅｌｉｎｅＣｏｍｐｏｎｅｎｔＭｅｔａＤａｔａＳａｍｐｌｅＥｎｔｒｙが定義されてもよい。ＴｉｍｅｌｉｎｅＣｏｍｐｏｎｅｎｔＭｅｔａＤａｔａＳａｍｐｌｅＥｎｔｒｙは、‘ｍｅｔｃ’のような４バイトのタイプを有することができ、上記のようなタイプフィールドを介してファイル内で固有に識別されてもよい。

タイムラインコンポーネントが記述しているストリームの位置ＵＲＬ又はストリームを再生させるまでの初期ディレー（ｄｅｌａｙ）などの初期化及びシグナリングパラメータを“ｍｅｔｃ”サンプルエントリ内に含めることができる。

図８０は、本発明の一実施例に係る、ＩＳＯＢＭＦＦでタイムラインコンポーネントトラックと他のトラックとの依存関係を表現するためのトラックリファレンスタイプボックス（ＴｒａｃｋＲｅｆｅｒｅｎｃｅＴｙｐｅＢｏｘ）を示す図である。

タイムラインコンポーネントをＤＡＳＨセグメントのようなＩＳＯＢＭＦＦベースファイル構造体に含めるために、前述したシグナリング情報に加えて、他のトラックとの依存関係に関する情報をシグナルすることもできる。同図は、トラック間の依存関係を表現するｔｒｅｆボックスを用いて、タイムラインコンポーネントトラックとＤＡＳＨセグメントの他のトラックとの依存関係を表現する実施例を示す。

Ｔｒｅｆボックスは、内部にトラックリファレンスタイプボックスを含む。Ｔｒｅｆボックスは、前述したタイムラインコンポーネントと他のトラックとの依存関係を表現するためのタイプとして、前述したように‘ｍｅｔｌ’というｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅを定義することができる。Ｔｒｅｆボックス内のｔｒａｃｋ＿ＩＤは、参照関係を有するトラックのＩＤを意味する。‘ｍｅｔｌ’リファレンスタイプボックスの定義を用いて、タイムラインコンポーネントとタイムラインを共有する他のトラックとの依存関係を表現することができる。

前述の図面に示したように、前述の‘ｍｅｔｌ’ボックスを含むｔｒｅｆボックスは、タイムラインコンポーネントトラックボックスに含まれ、依存関係にあるビデオトラックのＩＤを‘ｍｅｔｌ’ボックス内に含む。又は、実施例のビデオトラックにｔｒｅｆボックス及び‘ｍｅｔｌ’ボックスが含まれ、‘ｍｅｔｌ’のｔｒａｃｋ＿ＩＤとしてタイムラインコンポーネントトラックのＩＤを含むこともできる。

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

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

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

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

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

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

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

図８２は、本発明の一実施例に係る、ＩＳＯＢＭＦＦにおいてビデオデータ及び／又はオーディオデータに接近する方法を示す図である。

同図には、ＩＳＯＢＭＦＦの構造の一部が示されている。図示のビデオデータ及び／又はオーディオデータに接近する方法は、ローカル再生（ｌｏｃａｌｒｅｐｌａｙ）においてデータ間の同期化を行うことを示している。

受信機は、ＩＳＯファイルで‘ｔｋｈｄ’を用いてトラックを識別する。

受信機は、‘ｈｄｌｒ’（ｈａｎｄｌｅｒ＿ｔｙｐｅ）を用いて、メディアのタイプがオーディオなのか又はビデオなのかを識別することができる。

‘ｓｔｂｌ’ボックスは‘ｓｔｓｄ’ボックス、‘ｓｔｔｓ’ボックス、‘ｃｔｔｓ’ボックス、‘ｓｔｓｃ’ボックス、‘ｓｔｃｏ’ボックス及び／又は‘ｓｔｓｚ’ボックスを含むことができる。

受信機は、‘ｓｔｂｌ’のサンプル記述（ｓａｍｐｌｅｄｅｓｃｒｉｐｔｉｏｎ）（‘ｓｔｓｄ’ボックス）を用いてデコーダを初期化し、これに含まれた情報を用して、ｍｄａｔに含まれたデータ（ｓａｍｐｌｅｓ）をデコードすることができる。

‘ｓｔｔｓ’ボックスは、デコーディング時間（ｄｅｃｏｄｉｎｇｔｉｍｅ）を示す。‘ｓｔｔｓ’ボックスは、デコーディング時間からサンプル番号までのインデクシング（ｉｎｄｅｘｉｎｇ）を可能にする情報を含む。‘ｓｔｔｓ’ボックスは、サンプル番号からのサンプルサイズ、ポインタを提供することができる。

‘ｃｔｔｓ’ボックスは、デコーディング時間とコンポジッション時間（ｃｏｍｐｏｓｉｔｉｏｎｔｉｍｅ）間のオフセット（ｏｆｆｓｅｔ）に関する情報を提供する。

‘ｓｔｓｃ’ボックスは、サンプルを含むチャンク（Ｃｈｕｎｋ）、チャンクの位置、及び／又はサンプルに関連した属性情報を含む。メディアデータ内のサンプルはチャンクにグループ化してもよい。チャンクはそれぞれ別個のサイズを有することができ、一つのチャンク内のサンプルもそれぞれ別個のサイズを有することができる。

‘ｓｔｃｏ’ボックスは、ファイルに含まれるそれぞれのチャンクに対するインデックス（ｉｎｄｅｘ）情報を含むことができる。‘ｓｔｃｏ’ボックスは、メディアファイルに含まれるチャンクの開始のオフセットを提供する。

‘ｓｔｓｚ’ボックスは、サンプルカウント及び各サンプルのバイト単位のサイズを提供するテーブルを含む。これは、メディアデータ自体がアンフレーム（ｕｎｆｒａｍｅｄ）されるようにする。メディア内の全サンプルの数は常にサンプルカウントで示される。‘ｓｔｓｚ’ボックスは、デフォルトサンプルサイズを特定する情報を含むことができる。全サンプルが同一のサイズを有すると、情報はサイズ値を含む。この情報が０に設定されると、サンプルは別個のサイズを有し、それらのサイズはサンプルサイズテーブルに保存される。この情報が０でないと、一定のサンプルサイズを特定し、アレイが続かない。

受信機は、‘ｓｔｂｌ’ボックスに含まれる上記の情報を用いて、ビデオサンプル（ビデオデータ）とオーディオサンプル（オーディオデータ）との同期を取ることができる。

図８３は、本発明の他の実施例に係る、ＩＳＯＢＭＦＦにおいてビデオデータ及び／又はオーディオデータに接近する方法を示す図である。

同図のビデオデータ及び／又はオーディオデータに接近する方法は、ストリーミング（ｓｔｒｅａｍｉｎｇｒｅｐｌａｙ）においてデータ間の同期を取ることを示している。この場合、ビデオデータ及び／又はオーディオデータは、フラグメンテーション（ｆｒａｇｍｅｎｔａｔｉｏｎ）及び／又はセグメンテーション（ｓｅｇｍｅｎｔａｔｉｏｎ）された状態で伝送／受信される。

受信機は、初期化セグメント（ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔ）からファイル復号に必要な基本的な情報を取得する。受信機はＩＳＯファイルで‘ｔｋｈｄ’を用いてトラックを識別する。

受信機は、‘ｍｉｎｆ’ボックスに含まれている現在トラックのメディアの特性情報を用いてデコーダを初期化する。

受信機は、メディアセグメント内の‘ｔｆｈｄ’ボックスを用いて、‘ｔｋｈｄ’によって識別されたトラックに該当するメディアセグメントを識別し、‘ｍｉｎｆ’ボックスのサンプル記述（ｓａｍｐｌｅｄｅｓｃｒｉｐｔｉｏｎ）に該当するサンプル記述インデックスを取得する。

受信機は、‘ｔｆｈｄ’ボックスに含まれたベースデータオフセット情報、‘ｔｒｕｎ’ボックスに含まれたデータオフセット情報、及び／又は‘ｔｒｕｎ’ボックスに含まれたサンプルサイズ情報を用いて、ビデオデータ及び／又はオーディオデータのサンプルを抽出する。

受信機は、‘ｔｒｕｎ’ボックスに含まれたサンプルデューレーション情報とサンプル構成時間オフセット情報を用いて、ビデオデータ及び／又はオーディオデータのサンプル間に同期化を行う。

具体的な放送サービスを伝送する伝送フレームと伝送パケットについては、図８４乃至図８７を介して説明する。

図８４は、本発明の一実施例による放送伝送フレームを示す図である。

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

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

図８４の実施例において、放送伝送装置はＬ１パートを介して放送伝送フレームの構成及びそれぞれのＰＬＰの特性を伝送する。この際、放送受信装置１００はＰ１に基づいてＬ１パートをデコーディングして放送伝送フレームの構成及びそれぞれのＰＬＰの特性を獲得する。

図８４の実施例において、放送伝送装置はＣｏｍｍｏｎＰＬＰパートを介してＰＬＰ間に共通に適用される情報を伝送する。具体的な実施例において、放送伝送フレームはＣｏｍｍｏｎＰＬＰパートを含まなくてもよい。

図８４の実施例において、放送伝送装置は放送サービスに含まれた複数のコンポーネントをインターリーブドＰＬＰパートを介して伝送する。この際、インターリーブドＰＬＰパートは複数のＰＬＰを含む。

図８４の実施例において、放送伝送装置はそれぞれの放送サービスを構成するコンポーネントがそれぞれどのＰＬＯに伝送されるのかをＬ１パートまたはＣｏｍｍｏｎＰＬＰパートを介してシグナリングする。但し、放送受信装置１００が放送サービススキャンのために具体的な放送サービス情報を獲得するためにはインターリーブドＰＬＰパートの複数のＰＬＰを全てデコーディングすべきである。

図８４の実施例とは異なって、放送伝送装置は放送伝送フレームを介して伝送される放送サービスと放送サービスに含まれたコンポーネントに関する情報を含む別途のパートを含む放送伝送フレームを伝送する。この際、放送受信装置１００は別途のパートを介して迅速に放送サービスと放送サービスに含まれたコンポーネントに関する情報を獲得する。これいついては図８５を介して説明する。

図８５は、本発明の他の実施例による放送伝送フレームを示す図である。

図８５の実施例において、放送伝送フレームはＰ１パート、Ｌ１パート、高速情報チャネル（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ、ＦＩＣ）パート、インターリーブドＰＬＰパート及び補助データパートを含む。

ＦＩＣパートを除く他のパートは図８４の実施例と同じである。

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

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

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

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

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

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

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

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

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

図８８は、本発明の一実施例による放送サービスシグナリングテーブルと放送サービス伝送経路シグナリグ情報が放送サービスと放送サービス伝送経路をシグナリングすることを示す図である。

放送サービスシグナリングテーブルは放送サービス情報をシグナリングする。詳しくは、放送サービスが含むメディアコンポーネントをシグナリングする。また、放送サービスシグナリングテーブルは放送サービスと放送サービスが含むメディアコンポーネントの伝送経路をシグナリングする。このため、放送サービスシグナリングテーブルは放送サービス伝送経路シグナリング情報を含む。図８８の実施例において、放送サービスシグナリングテーブルは複数の放送サービスに関する情報を含む。この際、放送サービスシグナリングテーブルは複数の放送サービスそれぞれに含まれた複数のメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報を含む。特に、放送サービスシグナリングテーブルは複数のメディアコンポーネントの伝送経路をシグナリングする放送サービス伝送経路シグナリング情報を含む。例えば、放送サービスシグナリングテーブルを介して放送受信装置１００はサービス（Ｓｅｒｖｉｃｅ０）に含まれるビデオ（Ｖｉｄｅｏ０）が物理階層パイプ（ＰＬＰ０）を介して伝送されることが分かる。また、放送サービスシグナリングテーブルを介して放送受信装置１００はサービス（ＳｅｒｖｉｃｅＮ）に含まれるビデオ（Ａｕｄｅｏ１）がインターネット網を介して伝送されることが分かる。この際、物理階層パイプ（ＰｈｙｓｉｃａｌＬａｙｅｒＰｉｐｅ、ＰＬＰ）は物理階層の上で識別可能な一連の論理的データ伝達経路である。ＰＬＰはデータパイプ（ｄａｔａｐｉｐｅ）など他の用語で称されてもよい。

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

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

詳しくは、図８９の実施例のように放送サービスシグナリングテーブルは、ｔａｂｌｅ＿ｉｄフィールド、ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールド、ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールド、ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールド、ｖｉｓｏｉｎ＿ｎｕｍｂｅｒフィールド、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｎｕｍ＿ｓｅｒｖｉｃｅフィールド、ｓｅｒｖｉｃｅ＿ｉｄフィールド、ｓｅｒｖｉｅｃ＿ｓｔａｔｕｓフィールド、ＳＰ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールド、ｓｈｏｒｔ＿ｓｅｒｖｉｅｃ＿ｎａｍｅフィールド、ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールド、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔｓフィールド、ｅｓｓｅｎｔｉａｌ＿ｃｏｍｐｏｎｅｎｔ＿ｉｎｄｉｃａｔｏｒフィールド、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールド、ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールド、ｎｕｍ＿ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド及びｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドのうち少なくともいずれか一つを含む。

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

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

ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールドは現在のテーブルがｐｒｉｖａｔｅｓｅｃｔｉｏｎに当たるのかを示す。具体的な実施例において、ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。

ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドはｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドの後に含まれたｓｅｃｔｉｏｎの長さを示す。具体的な実施例において、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドは１２ビットである。

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

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

Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは放送サービスシグナリングテーブルの情報が現在使用可能であるのかを示す。詳しくは、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドの値が１であれば放送サービスシグナリングテーブルの情報が使用可能であることを示す。また、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドの値が１であれば放送サービスシグナリングテーブルの情報を次に使用可能であることを示す。具体的な実施例にお知恵、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。

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

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

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

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

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

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

ｓｈｏｒｔ＿ｓｅｒｖｉｅｃ＿ｎａｍｅフィールドは放送サービスの名前を示す。詳しくは、ｓｈｏｒｔ＿ｓｅｒｖｉｅｃ＿ｎａｍｅフィールドは放送サービスの名前を要約して表示する。

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

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

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

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

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

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

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

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

サービスシグナリングテーブルはアンサンブルに関する情報を更に含む。アンサンブルは一つ以上のサービスが同じ前進誤り訂正が適用されて伝送されれば一つ以上のサービスの集合を示す。図９１は、本発明の他の実施例による放送サービスシグナリングテーブルを示す。

詳しくは、図９１の実施例のように放送サービスシグナリングテーブルはｎｕｍ＿ｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドとｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを更に含む。

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

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

また、サービスシグナリングテーブルはメディアコンポーネントを識別するためにメディアコンポーネントを識別するストリーム識別子情報を更に含む。これについては図９２を介して詳しく説明する。

図９２は、本発明の一実施例によるストリーム識別子ディスプリプタを示す図である。

ストリーム識別子情報はｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド及びｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドのうちいずれか一つを含む。

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

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

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

放送サービスシグナリングテーブルを伝送し受信する動作については図９３乃至図９７を介して説明する。

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

図９３は、本発明の一実施例による放送伝送装置が放送サービスシグナルテーブルを伝送する動作を示す図である。

本発明の一実施例による放送伝送装置は、放送信号を伝送する伝送部及び放送伝送装置の動作を制御する制御部を含む。伝送部は伝送部が行う複数の機能それぞれを行う一つまたは複数のプロセッサ、一つまたは複数の回路及び一つまたは複数のハードウェアモジュールを含む。詳しくは、放送受信部１１０は様々な半導体部品が一つに集積されるシステム・オン・チップである。この際、ＳＯＣはグラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとＤＲＡＭなど半導体が一つに統合された半導体であってもよい。制御部は制御部が行う複数の機能それぞれを行う一つまたは複数のプロセッサ、一つまたは複数の回路及び一つまたは複数のハードウェアモジュールを含む。詳しくは、放送受信部１１０は様々な半導体部品が一つに集積されるシステム・オン・チップである。この際、ＳＯＣはグラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとＤＲＡＭなど半導体が一つに統合された半導体であってもよい。

放送伝送装置は制御部を介して伝送パケットに含ませて伝送するデータを獲得するＳ１０１。放送伝送措置が伝送するデータはリアルタイムコンテンツまたはリアルタイムコンテンツに関するメタデータである。詳しくは、リアルタイムコンテンツは地上波放送網などを介して伝送される放送Ａ／Ｖコンテンツまたは放送Ａ／Ｖコンテンツに関する向上されたデータである。

放送伝送装置は、制御部を介して獲得したデータがデータ伝送のために使用する伝送パケットが含められる容量を超過するのか否かを判断するＳ１０３。詳しくは、放送伝送装置が使用する伝送パケットが固定されたパケット長さを使用するプロトコールを基盤にする。この際、伝送しようとするデータがパケットがカバーし得る容量を超えれば円滑なデータの伝送が難しくなる恐れがある。また、伝送しようとするデータがパケットに比べて非常に小さければ、一つのパケットに小容量のデータ一つのみを伝送することは非効率なパケットの活用になりかねない。よって、上述した非効率性を克服するために放送伝送装置は制御部を介して伝送パケットとデータの大きさを比較する。

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

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

一実施例において、放送伝送装置は一つのデータを一つのパケットにパケッタイジングする。他の実施例において、放送伝送装置は複数のデータを一つのパケットにパケッタイジングする。また他の実施例において、放送伝送装置は一つのデータを複数のパケットに彫刻化してパケッタイジングする。

上述したように、データの容量またはパケットの長さに応じてパケッタイジングされた伝送パケットが異なり得る。よって、放送伝送装置は互いに異なる伝送パケットを区別可能な形態に伝送する必要がある。一実施例において、放送伝送装置は制御部を介して伝送パケットのペイロードヘッダにパケットの形態を示す情報を含ませてデータをパケッタイジングする。他の実施例において、放送伝送装置の制御部はペイロードヘッダに含まれた情報のみで伝送するデータを区別することが難しければ、伝送パケットの種類を識別する情報を追加的に含ませてデータをパケッタイジングする。

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

図９４は、本発明の一実施例による放送受信装置がパケッタイジングされた放送パケットを受信する動作を示す図である。

放送受信装置１００は、放送受信部１１０を介してパケッタイジングされた伝送パケットを受信するＳ２０１。

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

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

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

また、ペイロードタイプ情報はペイロードデータを含むパケットペイロードのタイプを示す。例えば、放送伝送装置が一つのパケットペイロードに一つのデータをパケッタイジングしたのか、または複数のパケットペイロードに一つのデータを分けてパケッタイジングしたのか否かを示す。

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

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

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

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

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

Ａ／Ｖコンテンツを出力する。他の実施例において、放送受信装置１００はＡ／Ｖコンテンツに関する向上されたデータを出力してもよい。

図９５は、本発明の実施例によるパケット構成を示す図である。

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

図９６は、本発明の実施例によるリアルタイムコンテンツ伝送のためのＲＴＰパケットの構造を示す図である。

ＲＴＰパケットはＲＰＴＨｅａｄｅｒ及びＲＴＰＰａｙｌｏａｄを含む。更に、ＲＴＰＨｅａｄｅｒはＴｉｍｅｓｔａｍｐ、Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎｓｏｕｒｃｅｉｄｅｎｔｉｆｉｅｒ及びＣｏｎｔｒｉｂｕｔｉｎｇｓｏｕｒｃｅｉｄｅｎｔｉｆｉｅｒのうち少なくとも一つを含む。

ＲＴＰＨｅａｄｅｒはＶ（ｖｅｒｓｉｏｎ）フィールド、Ｐ（ｐａｄｄｉｎｇ）フィールド、Ｘ（ｅｘｔｅｎｓｉｏｎ）フィールド、ＣＣフィールド、Ｍ（Ｍａｒｋｅｒｂｉｔ）フィールド、ＰａｙｌｏａｄＴｙｐｅフィールド、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒフィールド及びＴｉｍｅｓｔａｍｐフィールドのうち少なくとも一つのフィールドを含む。

Ｖフィールドは該当ＲＴＰバージョンの情報を示す。具体的な実施例において、Ｖフィールドは２ビットである。

Ｐフィールドはペイロード内のｐａｄｄｉｎｇビットの存在下非を示す。具体的な実施例において、Ｐフィールドは１ビットである。

ＸフィールドはＲＴＰＨｅａｄｅｒ内のｅｘｔｅｎｓｉｏｎフィールドの存在可否を示す。具体的な実施例において、Ｘフィールドは１ビットである。

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

Ｍ（Ｍａｒｋｅｒｂｉｔ）フィールドはＰａｙｌｏａｄＴｙｐｅに応じて互いに異なる意味を示す。例えば、ｔｒａｎｓｐｏｒｔｏｂｊｅｃｔがファイルであればファイルの最後を示す。他の例として、ｔｒａｎｓｐｏｒｔｏｂｊｅｃｔがビデオまたはオーディオデータであれば関連するａｃｃｅｓｓｕｎｉｔの最初または最後のオブジェクトであることを示す。具体的な実施例において、Ｍフィールドは１ビットである。

ＰａｙｌｏａｄＴｙｐｅフィールドはＲＴＰＰａｙｌｏａｄのタイプを示す。具体的な実施例において、ＰａｙｌｏａｄＴｙｐｅフィールドは７ビットである。

ＳｅｑｕｅｎｃｅＮｕｍｂｅｒフィールドはＲＴＰパケットのシーケンスナンバーを示す。具体的な実施例において、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒフィールドは１６ビットである。

ＴｉｍｅｓｔａｍｐフィールドはＲＴＰパケットに関する時間情報を示す。ＴｉｍｅｓｔａｍｐフィールドはＰａｙｌｏａｄＴｙｐｅフィールドの値に応じて異なるように解析される。具体的な実施例において、Ｔｉｍｅｓｔａｍｐフィールドは３２ビットである。

ＲＴＰＰａｙｌｏａｄはＲＴＰＨｅａｄｅｒのＰａｙｌｏａｄＴｙｐｅに応じてオーディオ／ビデオａｃｃｅｓｓｕｎｉｔが含まれる。例えば、Ｈ．２６４の場合ＮＡＬ（ｎｅｔｗｏｒｋａｂｓｔｒａｃｔｌａｙｅｒ）ｕｎｉｔなどが含まれる。

図９７は、本発明の一実施例によるＩＳＯｂａｓｅｍｅｄｉａｆｏｒｍａｔ（以下、ＩＳＯＢＭＦＦ）を基盤にするメディアファイルフォーマットを示す図である。

図９７に示したように、メディアファイルフォーマットは一般に一つのｆｔｙｐと一つまたはそれ以上のｍｏｏｖ、ｍｏｏｆ及びｍｄａｔを含む。

ｆｔｙｐはメディアファイルのタイプ及び適合性を示す。ｆｔｙｐはメディアファイルでできるだけ前に位置する。

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

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

図９８は、本発明の一実施例によるパケットペイロードのペイロードヘッダの構成を示す図である。

現在、リアルタイム伝送プロトコールは殆どメディアファイルのアクセスユニットなどを基盤に伝送している。詳しくは、アクセスユニットとはメディアファイルまたはデータを伝送する最小単位を意味する。よって、メディアファイルフォーマット基盤のデータをリアルタイムで伝送する方案に関する考慮が不十分なことろがある。

本発明の一実施例による放送伝送装置は、一つの伝送パケットに含まれたペイロードを介して一つのファイルファーマット基盤のメディアデータを伝送する。この場合、伝送パケットはシングルユニットパケット（ｓｉｎｇｌｅｕｎｉｔｐａｃｋｅｔ）であるといえる。他の実施例において、放送伝送装置は一つの伝送パケットに含まれたペイロードを介して複数のファイルフォーマット基盤のメディアデータを伝送する。この場合の伝送パケットはアグリゲーションパケット（Ａｇｇｒｅｇａｔｉｏｎｐａｃｋｅｔ）であるといえる。また他の実施例による放送伝送装置は一つのファイルフォーマット基盤のメディアデータを様々な伝送パケットに分けて伝送する。この場合の伝送パケットはフラッグメンテッドパケット（Ｆｒａｇｍｅｎｔｅｄｐａｃｋｅｔ）であるといえる。更に他の実施例において、放送伝送装置は一つの伝送パケットのペイロードを介してメディアストリームに関する一つまたは複数のメタデータを伝送する。更に他の実施例において、放送伝送装置は一つのメタデータを複数の伝送パケットのペイロードを介して伝送する。

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

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

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

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

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

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

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

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

また、放送伝送装置はメディアデータではなくコンテンツの再生またはデコーティング時間情報を含むメタデータをパケッタイジングして伝送する。この場合、放送伝送装置はデータのタイプを示す情報を０ｘ０３に設定する。一方、上述した時間情報をタイムライン（ｔｉｍｅｌｉｎｅ）データという。

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

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

図９９乃至図１００は、一つのパケットに一つのメディアがパケッタイジングされた伝送パケットのペイロード構成を示す。

図９９に示したように、一つのパケットに一つのメディアデータが含まれたパケットをシングルユニットパケットという。シングルユニットパケットのペイロードはペイロードヘッダとペイロードデータを含む。ペイロードデータは一つのファイルフォーマット基盤のメディアデータを含むフラグメンテッドデータを含む。一実施例において、伝送プロトコールが固定長さの伝送パケットを使用すれば、ペイロードデータはフラグメンテッドデータ以外にパッディングビットを追加に含む。ここで、パッディングビットとは伝送パケットでデータを詰めてから残った空間を詰めるためのビットをいう。

図１００は、図９９に示した伝送パケットの具体的な例を示す図である。図１００に示したように、ペイロードヘッダはペイロードが含むデータ上にエラーまたはシンタックスエラーがあるのか否かを示す情報、データの優先順位を示す情報およびデータのタイプを示す情報のうち少なくとも一つを含む。

図１００に示した一実施例において、ペイロードが含むデータ上にエラーまたはインタックスエラーがあるのか否かを示す情報はエラー及びシンタックスの違反がないとの内容を示す値を含む。具体的な実施例において、該当値は０である。

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

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

図１０１乃至図１０２は、一つのパケットに複数の互いに異なるメディアデータがパケッタイジングされた伝送パケットの構成を示す。上述したパケットはアグリゲーションパケットといえる。図１０１に示したように、一つの伝送パケットのペイロードが複数の互いに異なるファイルフォーマット基盤のメディアデータを含む場合、ペイロードデータは複数のアグリゲーションユニットを含む。それぞれのアグリゲーションユニットは互いに異なるファイルフォーマット基盤のメディアデータを含む。追加に伝送プロトコールが固定長さのパケットを使用すればペイロードデータはパッディングビットを含む。

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

図１０２はアグリゲーションユニットの構成を示す他の実施例であって、一つのアグリゲーションユニットは図１０１の実施例で追加にアグリゲーションユニット内に含まれたファイルのタイプを示す情報を更に含む。

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

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

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

図１０３乃至図１０９は、一つのメディアデータが複数の伝送パケットに分けられてパケッタイジングされた伝送パケット（以下、フラッグメンテッドパケット）のペイロード構成を示す図である。図１０３は、フラッグメントパケットのペイロード構成の一実施例を示す図である。図１０３に示したように、フラッグメンテッドパケットのペイロードはフラグメンテーションユニット（ｆｒａｇｍｅｎｔａｔｉｏｎｕｎｉｔ）を含む。追加にフラグメンテッドパケットのペイロードは伝送プロトコールが固定長さのパケットを使用する場合、パッディングビットが含まれる。

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

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

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

例えば、該当ペイロードのフラグメントユニットが開始部分のデータを含んでいる場合、放送伝送装置は全体ファイルのメディアデータのうち開始部分のデータを含んでいるのか否かを示す情報を１に設定する。詳しくは、全体ファイルンのメディアデータのうち開始部分のデータを含んでいるのか否かを示す情報は１ビットである。

一実施例において、全体ファイルのメディアデータのうち最後の部分のデータを含んでいるのか否かを示す情報をＥｎｄｂｉｔフィールドという。詳しくは、最後の部分のデータは全体メディアデータの最後のビットを含む全体データの一部である。

例えば、該当ペイロードのフラグメンテーションユニットデータが最後の部分のデータを含んでいる場合、放送伝送装置は全体ファイルのメディアデータのうち最後の部分のデータを含んでいるのか否かを示す情報を１に設定する。詳しくは、全体ファイルのメディアデータのうち最後の部分のデータを含んでいるのか否かを示す情報は１ビットである。

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

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

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

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

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

詳しくは、フラグメンテーションユニットタイプを示す情報は６ビットである。

図１０４は、フラグメンテッドパケットのペイロード構成の他の実施例を示す図である。図１０４の実施例は伝送パケットのヘッダに伝送パケットの順番に関する情報が存在しない場合に適用される。

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

フラグメンテーションユニットの順番を示す情報はＦｒａｇｍｅｎｔａｔｉｏｎｎｕｍｂｅｒフィールドという。詳しくは、放送伝送装置はファイルフォーマット基盤のメディアデータが複数のフラッグメンテッドパケットに分けられた場合、フラグメンテーションユニットの順番を示す情報に値を設定して該当パケットの順番を割り当てる。詳しくは、Ｆｒａｇｍｅｎｔａｔｉｏｎｎｕｍｂｅｒフィールドは８ビットである。

図１０５は、本発明の一実施例において、放送伝送装置がＩＳＯＢＭＦＦ基盤のメディアファイルをフラグメンテーションして複数個のパケットに分けることを示す図である。図１０５に示したように、ＩＳＯＢＭＦＦ基盤のメディアファイルはｆｔｙｐ、ｍｏｏｖと複数のｍｏｏｆ及びｍｄａｔを含む。

放送伝送装置はＩＳＯＢＭＦＦ基盤のメディアファイルを複数個に分けてそれぞれ異なるフラグメンテーションユニットデータに含ませる。また、放送伝送装置はＩＳＯＢＭＦＦ基盤のメディアファイルを分けながらペイロードヘッダに関する情報を含ませる。

図１０６は、図１０５の放送伝送装置はパケッタイジングした第１フラグメンテーションユニットデータの具体的な実施例を示す図である。

図１０６に示したように、本発明の一実施例において、放送伝送装置はペイロードのＦフィールドを該当パケットにエラーまたはシンタックスのエラーがないと判断して０に設定する。

また、放送伝送装置はＰｒｉｏｒｉｔｙフィールドを最も高い優先順位を示す値に設定する。詳しくは、該当値は０ｘ００である。

また、放送伝送装置はＴｙｐｅフィールドを該当パケットが一つのファイルフォーマット基盤のメディアファイルを様々なペイロードに分けて伝送するパケットを示す値に設定する。詳しくは、該当値は０ｘ０２である。

ペイロードデータはフラグメンテーションユニットを含み、更にフラグメンテーションユニットはＳｔａｒｔｂｉｔフィールド、フラグメンテーションユニットタイプフィールド及びフラグメンテーションユニットデータフィールドを含む。

放送伝送装置はＳｔａｒｔｂｉｔフィールドを該当パケットがメディアファイルの開始データを含む内容を示す値に設定する。詳しくは、図１０５において第１フラグメンテーションユニットがメディアデータの開始データを含むため、放送伝送装置は該当内容を示す値をＳｔａｒｔｂｉｔフィールドに設定する。

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

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

図１０７乃至図１０９は、図１０５のフラグメンテーションユニットデータのうち開始データを除く残りのデータを含むフラグメンテーションユニットの一実施例を示す図である。

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

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

また、放送伝送装置はＴｙｐｅフィールドを該当パケットが一つのファイルフォーマット基盤のメディアファイルを様々なペイロードに分けて伝送するパケットを示すＦｒａｇｍｅｎｔｅｄｐａｃｋｅｔとして０ｘ０２に設定する。図１０８は、ペイロードデータが開始データを含むフラグメンテーションユニットデータ及び最後のデータを含むフラグメンテーションユニットデータを含まない場合のペイロード構成を示す。

本発明の一実施例において、放送伝送装置は図１０８のフラグメンテーションユニットデータが開始データ及び最後のデータを含んでいないため、Ｓｔａｒｔｂｉｔフィールド及びＥｎｄｂｉｔフィールドを該当情報を示す値として設定する。具体的な実施例において、放送伝送装置はＳｔａｒｔｂｉｔ及びＥｎｄｂｉｔフィールドを全て０に設定する。

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

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

しかし、他の実施例において、伝送パケットはフラグメンテーションユニットデータの順番情報を含まなくてもよい。この場合、一実施例において、放送伝送装置はパケットヘッダにフラグメンテーションユニットデータの順番を識別するための情報を挿入する。パケットヘッダに含まれたフラグメンテーションユニットデータの順番を識別するための情報はシーケンスナンバーフィールドである。他の実施例において、放送伝送装置はＩＰデータグラムのオフセット情報にフラグメンテーションユニットデータの順番を識別するための情報を挿入してもよい。

図１０９は、分けられた全体メディアのうち最後のデータを含むフラグメンテーションユニットを含むペイロードの構成を示す図である。詳しくは、図１０９はペイロードデータが開始データを含むフラグメンテーションユニットデータを含まないが、最後のデータを含むフラグメンテーションユニットデータを含む場合のペイロード構成を示す。

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

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

放送伝送地が伝送パケットを介して伝送するデータは上述したメディアデータと共にメタデータ（ｍｅｔａｄａｔａ）がある。メタデータはメディアデータを提供するために必要な付加情報を示す。以下、図１０７乃至図１１７ではメタデータを伝送パケットにパケッタイジングして伝送及び受信する放送伝送装置は、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提案する。

また、以下ではメタデータの一例としてタイムライン情報を中心に説明する。タイムライン情報とはメディアコンテンツのための一連の時間情報である。詳しくは、タイムライン情報は再生またはデコーディングするための一連の時間情報である。

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

一方、放送伝送装置はメタデータをＸＭＬのフォーマットで表現する。また、放送伝送装置はメタデータをシグナリングテーブルに含まれるデスクリプタの形態に表現してもよい。

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

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

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

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

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

また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットのタイムスタンプのタイプ情報を含む。上述した情報をｌｏｃａｔｉｏｎ＿ｔｙｐｅフィールドという。

一実施例において、タイムラインコンポーネントアクセスユニットに関するサービスまたはコンテンツコンポーネントのデコーディング時点を示す値が設定される。詳しくは、コンテンツコンポーネントのデコーティング時点はデコーティングタイムスタンプ（ｄｅｃｏｄｉｎｇｔｉｍｅｓｔａｍｐ）という。具体的な一実施例において、放送伝送装置はタイムスタンプのタイプ情報を該当情報がデコーディング時点を示せば０ｘ００に設定する。

他の実施例において、タイムラインコンポーネントアクセスユニットに関するサービスまたはコンテンツコンポーネント再生時点を示す値が設定される。詳しくは、コンテンツコンポーネントの再生時点はプレゼンテーションタイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅｓｔａｍｐ）という。具体的な一実施例において、放送伝送装置はタイムスタンプのタイプ情報を該当情報がプレゼンテーション時点を示せば０ｘ０１に設定する。

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

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

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

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

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

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

また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットが含む情報に関するサービスまたはコンテンツのコンポーネントに関する位置情報を含む。上述した情報をｌｏｃａｔｉｏｎフィールドという。

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

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

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

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

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

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

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

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

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

また他のの実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａフィールドは基本タイムラインのタイムスタンプがプレシジョンタイムプロトコール（ＰＴＰ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０２に設定して該当基本タイムラインのタイムスタンプフォーマットがＰＴＰフォーマットであることを示す。

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

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

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

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

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

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

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

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

一実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドがｒｅｓｅｒｖｅｄを示す場合、ｔｉｍｅｌｉｎｅＡＵはｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールド及びｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ（）フィールドのうち少なくとも一つを含む。

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

ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ（）フィールドはｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドが示す長さだけｐｒｉｖａｔｅｌｙを定義するか、後に拡張内容を含む。

図１１１は、伝送パケットのペイロードデータに一つのメタデータがパケット化されたペイロードデータの構成を示す図である。一実施例において、ペイロードデータはメタデータを含み、メタデータはメディアストリーム関連タイムラインデータを含む。また、一実施例において、放送伝送装置が伝送プロトコールに固定長さのパケットを含めばペイロードデータはパディングデータを追加に含む。

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

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

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

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

図１１３に示したように、一つの伝送パケットが多数のメタデータを含む場合イをアグリゲーションパケットという。一実施例において、ペイロードデータは複数のアグリゲーションユニットを含む。

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

図１１４は、一つの伝送パケットが多数個のタイムライン情報を含む場合を示す図である。詳しくは、一つのメディアストリームに関してそれぞれの基準が異なる複数個のタイムライン情報を一つの伝送パケットが含んでいる場合を示す。一実施例において、伝送パケットはペイロードパケットを含むが、ペイロードヘッダの内容は図１１３の内容のようである。

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

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

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

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

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

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

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

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

図１１６は、メタデータフラグメントヘッダの他の実施例を示す図である。ここで、図１１５と同じ部分の説明は省略する。

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

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

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

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

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

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

上述したように、従来の放送伝送装置は伝送パケットに含まれたデータ（またはオブジェクト）の再生に関する時間情報をペイロードに載せて伝送していた。または放送伝送装置は時間情報を伝送するための別途のシグナリングを伝送していた。従来のような方法の場合、別途の伝送パケットまたはパケットペイロードに時間情報を載せるためパケットヘッダの容量または伝送パケットの容量が相対的に小さくなる長所があった。しかし、従来の方法の場合、伝送しようとするデータと別途のパケットで時間情報を伝送するため正確で迅速な同期画面では効率が落ちることがあった。

一方、本発明の実施例ではリアルタイムのコンテンツを支援するための伝送パケットのパケットヘッダにパケットデコーティングまたは再生に関する時間情報を含ませる。よって、該当パケットの時間情報が該当パケットのヘッダに含まれているため、従来の方法に比べ相対的に正確で迅速な同期化が可能になる。特に、本発明の一実施例では上述したデコーディングまたは再生に関する時間情報をパケットヘッダ内の拡張されたヘッダ（ＥｘｔｅｎｄｅｄＨｅａｄｅｒ）に設定して伝送パケットをパケット化する内容を提案する。ここで、拡張されたヘッダは必須ではないが、容量変換が可能な選択的なヘッダフィールドを含むパケットヘッダの一部であってもよい。また、伝送パケットはオブジェクトに基づいて生成され、よって、オブジェクトは伝送パケットを介して伝送しようとする対象になり得る。オブジェクトはセッションに含まれて伝送されてもよい。

図１１９は、本発明の一実施例による伝送パケットの構成を示す図である。図１１９に示した伝送パケットは信頼性のあるデータ伝送を支援する伝送プロトコールを利用する。具体的な実施例において、信頼性のあるデータ伝送プロトコールは非同期階層化コーディング（ＡＬＣ）である。他の実施例において、信頼性のあるデータ伝送プロトコールは階層化コーディング伝送（ＬＣＴ）である。

本発明の一実施例によるパケットヘッダパケットのバージョン情報を含む。詳しくは、該当伝送プロトコールを利用する伝送パケットのバージョン情報を含む。具体的な実施例において、上述した情報はＶフィールドである。また、Ｖフィールドは４ビットである。

また、本発明の一実施例によるパケットヘッダは、混雑制御（ｃｏｎｇｅｓｔｉｏｎｃｏｎｔｒｏｌ）のための情報の長さに関する情報を含む。詳しくは、混雑制御のための情報の長さと混雑制御のための情報の長さの基本単位にかけられる関連する倍数情報を含む。

具体的な実施例において、上述した情報はＣフィールドである。一実施例においてＣフィールドは０ｘ００に設定されるが、この場合、混雑制御のための情報の長さが３２ビットであることを示す。他の実施例においてＣフィールドは０ｘ０１に設定されるが、この場合、混雑制御のための情報の長さが６４ビットである。また他の実施例においてＣフィールドは０ｘ０２に設定されるが、この場合、混雑制御のための情報の長さが９６ビットである。更に他の実施例においてＣフィールドは０ｘ０３に設定されるが、この場合、混雑制御のための情報の長さが１２８ビットである。Ｃフィールドは２ビットである。

また、本発明の一実施例によるパケットヘッダはプロトコールに特化した情報を含む。具体的な実施例において、上述した情報はＰＳＩフィールドである。また、ＰＳＩフィールドは２ビットである。

また、本発明の一実施例によるパケットヘッダは伝送セッションの識別情報を示すフィールドの長さに関する情報を含む。詳しくは、伝送セッションの識別情報を示すフィールドの倍数情報を含む。上述した情報はＳフィールドという。Ｓフィールドは１ビットである。

また、本発明の一実施例によるパケットヘッダは伝送オブジェクトの識別情報を示すフィールドの長さに関する情報を含む。詳しくは、伝送オブジェクトの識別情報を示すフィールドの基本長さにかけられる倍数情報を含む。上述した情報はＯフィールドという。Ｏフィールドは１２ビットである。

また、本発明の一実施例によるパケットヘッダは伝送セッションの識別情報を示すフィールドの長さに関する追加の情報を含む。そして、パケットヘッダは伝送オブジェクトの識別情報を示すフィールドの長さに関する追加の情報を含む。追加の情報はハーフワード（ｈａｌｆ−ｗｏｒｄ）の追加可否情報である。伝送パケットの識別情報を示すフィールド及び伝送オブジェクトの識別情報を示すフィールドは存在すべきであるため、ＳフィールドとＨフィールドまたはＯフィールドとＨフィールドは同時に０（Ｚｅｒｏ）を示すことができない。

また、本発明の一実施例によるパケットヘッダは、セッションが終了されるか終了が迫ることを示す情報を含む。上述した情報をＡフィールドという。具体的な実施例において、Ａフィールドがセッションの終了または終了の切迫を示せば１に設定される。よって、通常Ａフィールドは０に設定される。放送伝送装置がＡフィールドを１に設定する場合、セッションを介して最後のパケットが伝送されていることを示す。Ａフィールドが１に設定されると、放送伝送装置は該当パケットを従う全てのパケットの伝送が終了されるまでＡフィールドを１に維持すべきである。また、放送受信装置はＡフィールドが１に設定される場合、放送伝送装置がセッションを介したパケット伝送をもうすぐ中断することを認識する。つまり、放送受信装置はＡフィールドが１に設定されるとセッションを介してそれ以上のパケット伝送はないと認識する。一実施例において、Ａフィールドは１ビットである。

また、本発明の一実施例によるパケットヘッダは、オブジェクトの伝送が終了されるか終了が迫ることを示す情報を含む。上述した情報をＢフィールドという。具体的な実施例において、放送伝送装置はオブジェクトの伝送終了が迫ればＢフィールドは１に設定される。よって、通常Ｂフィールドは０に設定される。伝送オブジェクトを識別する情報が伝送パケットに存在しなければＢフィールドは１に設定される。そして、アウト・オブ・バンド（ｏｕｔ−ｏｆ−ｂａｎｄ）情報によって識別されたオブジェクト伝送の終了が迫ることを示す。また、Ｂフィールドはオブジェクトのための最後のパケットが伝送されれば１に設定される。また、Ｂフィールドはオブジェクトのための最後の数秒パケットが伝送されれば１に設定される。放送伝送装置は特定オブジェクトのためのパケットのフィールドが１に設定されると、該当パケットを従う全てのパケットの伝送が終了されるまでＢフィールドを１に設定すべきである。放送受信装置１００はＢフィールドが１に設定されると、放送伝送装置がオブジェクトのためのパケットの伝送をもうすぐ中断することを認識する。つまり、放送受信装置１００は１に設定されたＢフィールドからセッションを介したそれ以上のオブジェクトの伝送はないと認識する。一実施例において、Ｂフィールドは１ビットである。

また、本発明の一実施例によるパケットヘッダは、ヘッダの総長さを示す情報を含む。上述した情報をＨＤＲ＿ＬＥＮフィールドという。ＨＤＲ＿ＬＥＮフィールドは３２の倍数ビットである。具体的な実施例において、ＨＤＲ＿ＬＥＮフィールドが５に設定されればパケットヘッダの総長さは３２の５倍数である１６０ビットである。また、ＨＤＲ＿ＬＥＮフィールドは８ビットである。

また、本発明の一実施例によるパケットヘッダは、ヘッダパケットに含まれたペイロードのエンコーディングまたはデコーディングに関する情報を含む。上述した情報をＣｏｄｅｉｎｔフィールドという。一実施例において、Ｃｏｄｅｉｎｔフィールドは８ビットである。

また、本発明の一実施例によるパケットヘッダは、ヘッダの混雑を制御するための情報を含む。上述した情報をＣｏｎｇｅｓｔｉｏｎＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ（以下、ＣＣＩ）フィールドという。具体的な実施例において、ＣＣＩフィールドはＣｕｒｒｅｎｔｔｉｍｅｓｌｏｔｉｎｄｅｘ（ＣＴＳＩ）フィールド、ｃｈａｎｎｅｌｎｕｍｂｅｒフィールド及びｐａｃｋｅｔｓｅｑｕｅｎｃｅｎｕｍｂｅｒフィールドのうち少なくともいずれか一つを含む。

また、本発明の一実施例によるパケットヘッダは、伝送セッションを識別するための情報を含む。上述した情報は伝送セッション識別子（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ（以下、ＴＳＩ））である。また、ＴＳＩ情報を含むパケットヘッダ内のフィールドをＴＳＩフィールドという。

また、本発明の一実施例によるパケットヘッダは、伝送セッションを介して伝送されるオブジェクトを識別するための情報を含む。上述した情報は伝送オブジェクト識別子（ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒ（以下、ＴＯＩ））である。また、ＴＯＩ情報を含むパケットヘッダ内のフィールドをＴＯＩフィールドという。

また、本発明の一実施例によるパケットヘッダは、追加の情報を伝送するための情報を含む。上述した情報をＨｅａｄｅｒＥｘｔｅｎｓｉｏｎフィールドという。一実施例において、追加の情報は伝送オブジェクトの再生に関する時間情報である。他の実施例において、追加の情報は伝送オブジェクトのデコーディングに関する時間情報である。

また、本発明の一実施例による伝送パケットはペイロード識別情報を含む。一実施例において、識別情報はＦｏｒｗａｒｄＥｒｒｏｒＣｏｒｒｅｃｔｉｏｎ（ＦＥＣ）ｓｃｈｅｍｅに関するペイロード識別情報である。ここで、ＦＥＣはＲＦＣ５０１９に定義されているペイロードフォーマットのある類型である。ＦＥＣはＲＴＰまたはＳＲＴＰで使用される。上述した情報はＦＥＣＰａｙｌｏａｄＩＤフィールドという。

一実施例において、ＦＥＣＰａｙｌｏａｄＩＤフィールドはオブジェクトのソースブロックを識別するための情報を含む。上述した情報はＳｏｕｒｃｅｂｌｏｃｋｎｕｍｂｅｒフィールドという。例えば、ＳｏｕｒｃｅｂｌｏｃｋｎｕｍｂｅｒフィールドがＮに設定されるとオブジェクト内のソースブロックは０からＮ−１にナンバリングされる。

他の実施例において、ＦＥＣＰａｙｌｏａｄＩＤフィールドは特定エンコーディングシンボルを識別するための情報を含む。上述した情報はＥｎｃｏｒｄｉｎｇｓｙｍｂｏｌＩＤフィールドという。

また、本発明の一実施例において、伝送パケットはペイロード内のデータを含む。上述したデータを含んでいるフィールドをＥｎｃｏｄｉｎｇｓｙｍｂｏｌ（ｓ）フィールドという。一実施例において、放送受信装置１００はＥｎｃｏｄｉｎｇｓｙｍｂｏｌ（ｓ）フィールドを抽出してオブジェクトを再構成する。詳しくは、パケットペイロードを介して伝送されるソースブロックからＥｎｃｏｄｉｎｇｓｙｍｂｏｌ（ｓ）フィールド内のデータが生成される。

図１２０は、本発明の一実施例によるパケットヘッダの構成示す図である。

リアルタイムコンテンツの伝送を支援するためには、放送受信装置１００が受信した伝送パケットにパケットの属性情報及びデコーディングまたは再生に関するタイミング情報が含まれることが効果的である。よって、上述した課題を解決するために、図１２０に示したようにパケットヘッダが構成される。

図１２０のパケットヘッダは図１１９のパケットヘッダと殆どの構成が同じである。よって、同じ部分の説明は省略する。

本発明の一実施例によるパケットヘッダは伝送のためのオブジェクトタイプを示す情報を含む。上述した情報はｔｙｐｅフィールドという。ｔｙｐｅフィールドは２ビットである。

具体的な実施例において、ｔｙｐｅフィールドは伝送のためのオブジェクトのタイプがレギュラファイル（ｒｅｇｕｌａｒｆｉｌｅ）であることを示す。ここで、レギュラファイルはＩＳＯＢＭＦＦ基盤のメディアファイルである。詳しくは、レギュラファイルはメディアファイルをＩＳＯＢＭＦＦ形式にエンカプセレーションしたものである。この場合、ｔｙｐｅフィールドは０１₍₂₎に設定される。他の実施例において、ｔｙｐｅフィールドは伝送のためのオブジェクトのタイプがＨＴＴＰｅｎｔｉｔｙタイプであることを示す。この場合、ｔｙｐｅフィールドは１０₍₂₎に設定される。また他の実施例において、ｔｙｐｅフィールドは伝送のためのオブジェクトのタイプがオーディオアクセスユニット（Ａｕｄｉｏａｃｃｅｓｓｕｎｉｔ）またはビデオアクセスユニット（Ｖｉｄｅｏａｃｃｅｓｓｕｎｉｔ）であることを示す。また、ｔｙｐｅフィールドはオブジェクトのタイプがネットワーク観念的階層（ＮＡＬ）ユニットであることを示してもよい。この場合、ｔｙｐｅフィールドは１１₍₂₎に設定される。

また、本発明の一実施例によるパケットヘッダは伝送パケットが伝送オブジェクトの最初の部分または最後の部分を含んでいることを示す。伝送パケットが伝送オブジェクトの最初の部分または最後の部分を示すことを示す情報はマーカービット（ｍａｒｋｅｒｂｉｔ））である。具体的な実施例において、マーカービットはＭフィールドである。詳しくは、Ｍフィールドはｔｙｐｅフィールドの値に応じて異なるように解析される。例えば、伝送のためのオブジェクトタイプがファイルであれば該当伝送パケットがファイルの最後の部分を含んでいることを示す。ここで、最後の部分とはファイルの最後のビットを含んでいる部分である。他の例として、伝送のためのオブジェクトタイプがＡＶデータ（ＡｕｄｉｏｏｒＶｉｄｅｏ）であれば該当伝送パケットがアクセスユニットの最初または最後のビットを含んでいることを示す。

図１２１及び図１２２は、時間情報を含む拡張されたヘッダの構成を示す図である。図１２１及び図１２２に示した拡張されたヘッダは図１２０に示したヘッダ拡張フィールドに含まれる。

図１２１に示したように、本発明の一実施例による拡張されたヘッダは拡張されたヘッダのタイプ情報を含む。上述した情報はＨＥＴ（ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎＴｙｐｅ）フィールドという。

また、一実施例による拡張されたヘッダは拡張されたヘッダの長さ情報を含む。上述した情報はＨＥＬ（ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎＬｅｎｇｔｈ）フィールドという。

また、一実施例による拡張されたヘッダは放送伝送装置の現在の時間を示す。つまり、拡張されたヘッダは放送伝送装置の該当パケットの伝送時間情報を含む。例えば、放送伝送装置はサーバである。具体的な実施例において、放送伝送装置の現在の時間を示す情報はＳｅｎｄｅｒＣｕｒｒｅｎｔＴｉｍｅ（以下、ＳＣＴ）フィールドである。

また、一実施例による拡張されたヘッダはＳＣＴフィールドが６４ビットであるのか否かを示す。詳しくは、拡張されたヘッダはＳＣＴフィールドが６４ビットで構成されて拡張されたヘッダに含まれているのか否かを示す。具体的な実施例において、ＳＣＴフィールドが６４ビットであるのか否かを示す情報はＳＣＴＨｉフィールドである。

また、一実施例による拡張されたヘッダはＳＣＴフィールドが３２ビットであるのか否かを示す。詳しくは、拡張されたヘッダはＳＣＴフィールドが３２ビットで構成されて拡張されたヘッダに含まれているのか否かを示す。具体的な実施例において、ＳＣＴフィールドが３２ビットであるのか否かを示す情報はＳＣＴＬｏｗフィールドである。

また、一実施例による拡張されたヘッダは伝送のためのオブジェクトの予想される残余時間情報を含む。上述した情報はＥｘｐｅｃｔｅｄＲｅｓｉｄｕａｌＴｉｍｅ（以下、ＥＲＴ）フィールドという。

また、一実施例による拡張されたヘッダはＥＲＴフィールドが該当パケットに存在するのか否かを示す。該当情報はＥＲＴｆｌａｇフィールドである。

また、一実施例による拡張されたヘッダはセッションが最後に変化した時間情報を含む。上述した情報はＳＬＣフィールドである。

また、一実施例による拡張されたヘッダはＳＬＣフィールドが該当パケットに存在するのか否かを示す。該当情報はＳＬＣｆｌａｇフィールドである。

また、一実施例による拡張されたヘッダは放送伝送装置が利用する伝送プロトコールに応じて拡張して使用し得るフィールドを含む。該当情報はＰＩ−ｓｐｅｃｉｔｉｆＵｓｅフィールドである。

図１２２は、図１２１の拡張されたヘッダに構成を追加した他の実施例による拡張されたヘッダを示す図である。

他の実施例による拡張されたヘッダはパケットペイロードに含まれたデータのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドである。例えば、Ｔｉｍｅｓｔａｍｐフィールドはパケットペイロードに含まれたデータの最初のバイトがデコーディングされる時点に対する情報を含む。他の例として、Ｔｉｍｅｓｔａｍｐフィールドはデータの再生時点に関する情報を含む。加えて、Ｔｉｍｅｓｔａｍｐフィールドはタイムスケール情報またはタイムスケールに基づくタイミング情報を含んでもよい。ここで、タイムスケール情報は伝送オブジェクトのデコーディングまたは再生時点に対する時間を示す単位である。タイムスケールに基づいたタイミング情報である場合、放送受信装置はＴｉｍｅｓｔａｍｐフィールドの値をタイムスケールをかけてデコーディングまたは再生時点に関する情報を獲得する。

他の実施例による拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。メディアタイムは任意のメディアタイムラインによるメディア再生時間である。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。ノーマル再生タイムのフォーマットは再生開始時点から相対的に表現される再生時間であり、これは時、分、秒、秒以下の小数点単位で表現される。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥｔｉｍｅｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ（ＳｏｃｉｅｔｙｏｆＭｏｔｉｏｎＰｉｃｔｕｒｅａｎｄＴｅｌｅｖｉｓｉｏｎＥｎｇｉｎｅｅｒｓ）ｔｉｍｅｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。詳しくは、ＳＭＰＴＥタイムコードはＳＭＰＴＥでビデオの個別的なフレームラベリングのために定義した時間情報形式である。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚ基盤のタイミング情報であることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０５に設定される。

また他の実施例による拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドの構成を示す。タイミング情報の構成を示す情報をＴＳｖｅｒｓｉｏｎフィールドという。例えば、ＴＳｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳｖｅｒｓｉｏｎフィールドは１に設定される。

図１２３乃至図１２６は、本発明の一実施例による拡張されたヘッダの構成を示す図である。詳しくは、図１２３乃至図１２６に示した拡張されたヘッダ構造は伝送のためのオブジェクトタイプ情報及びタイミング情報のうち少なくとも一つを含む。また、該当拡張されたヘッダ構造は上述した拡張されたヘッダフィールドに含まれる。また、コンテンツを伝送するパケットヘッダの一部として称される。

図１２３に示したように、本発明の他の実施例による拡張されたヘッダの構造（ＥＸＴ＿ＯＢＪ＿ＩＮＦＯ）はヘッダ拡張部分のタイプ情報を含む。上述したタイプ情報はＨＥＴフィールドという。また、拡張されたヘッダ構造は拡張部分の長さ情報を含む。上述した長さ情報はＨＥＬフィールドという。また、拡張されたヘッダ構造は伝送オブジェクトのタイプ情報を含む。上述したオブジェクトタイプ情報はＯｂｊｅｃｔｔｙｐｅフィールドという。

具体的な実施例において、Ｏｂｊｅｃｔｔｙｐｅフィールドは伝送オブジェクトがレギュラファイルのタイプであることを示す。ここで、レギュラファイルはＩＳＯＢＭＦＦ基盤のメディアファイルである。詳しくは、レギュラファイルはメディアファイルをＩＳＯＢＭＦＦ形式にエンカプセレーションしたものである。この場合、Ｏｂｊｅｃｔｔｙｐｅフィールドは０ｘ０１に設定される。他の実施例において、Ｏｂｊｅｃｔｔｙｐｅフィールドは伝送オブジェクトがＨＴＴＰｅｎｔｉｔｙタイプであることを示す。この場合、Ｏｂｊｅｃｔｔｙｐｅフィールドは０ｘ０２に設定される。また他の実施例において、Ｏｂｊｅｃｔｔｙｐｅフィールドは伝送オブジェクトがオーディオデータタイプであることを示す。Ｏｂｊｅｃｔｔｙｐｅフィールドは伝送オブジェクトがＡＡＣを基盤にするオーディオデータタイプであることを示す。この際、ＡＡＣに基づくオーディオデータタイプはＡＡＣにエンコーディングされたオーディオデータである。この場合、Ｏｂｊｅｃｔｔｙｐｅフィールドは０ｘ０３に設定される。更に他の実施例において、Ｏｂｊｅｃｔｔｙｐｅフィールドは伝送オブジェクトがビデオデータタイプであることを示す。詳しくは、Ｏｂｊｅｃｔｔｙｐｅフィールドは伝送オブジェクトがＨ．２６４タイプであることを示す。この場合、Ｏｂｊｅｃｔｔｙｐｅフィールドは０ｘ０４に設定される。更に他の実施例において、Ｏｂｊｅｃｔｔｙｐｅフィールドは伝送オブジェクトがＨＥＶＣ基盤のビデオデータタイプであることを示す。この際、ＨＥＶＣ基盤のビデオタイプはＨＥＶＣにエンコーディングされたビデオデータである。この場合、Ｏｂｊｅｃｔｔｙｐｅフィールドは０ｘ０５に設定される。更に他の実施例において、Ｏｂｊｅｃｔｔｙｐｅフィールドは伝送オブジェクトがＩＳＯＢＭＦＦ基盤のファイルタイプであることを示す。この場合、Ｏｂｊｅｃｔｔｙｐｅフィールドは０ｘ０６に設定される。更に他の実施例において、Ｏｂｊｅｃｔｔｙｐｅフィールドは伝送オブジェクトがメタデータであることを示す。この場合、Ｏｂｊｅｃｔｔｙｐｅフィールドは０ｘ０７に設定される。

また、本発明の他の実施例による拡張されたヘッダの構造（ＥＸＴ＿ＯＢＪ＿ＩＮＦＯ）はヘッダ伝送パケットが伝送オブジェクトの最初の部分または最後の部分を含むことを示す。伝送パケットが伝送オブジェクトの最初の部分または最後の部分を示す情報はマーカービットである。具体的な実施例において、マーカービットはＭフィールドである。詳しくは、ＭフィールドはＯｂｊｅｃｔｔｙｐｅフィールドの値に応じて異なるように解析される。例えば、伝送のためのオブジェクトタイプがファイルであれば該当伝送パケットがファイルの最後の部分を含んでいることを示す。ここで、最後の部分とはファイルの最後のビットを含んでいる部分である。他の例として、伝送のためのオブジェクトタイプがＡＶデータであれば該当伝送パケットがアクセスユニットの最初または最後のビットを含んでいることを示す。

また、本発明の他の実施例による拡張されたヘッダの構造（ＥＸＴ＿ＯＢＪ＿ＩＮＦＯ）はパケットペイロードに含まれたデータのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドである。例えば、Ｔｉｍｅｓｔａｍｐフィールドはパケットペイロードに含まれたデータの最初のバイトがデコーディングされる時点に対する情報を含む。他の例として、Ｔｉｍｅｓｔａｍｐフィールドはデータの再生時点に関する情報を含む。加えて、Ｔｉｍｅｓｔａｍｐフィールドはタイムスケール情報またはタイムスケールに基づくタイミング情報を含んでもよい。ここで、タイムスケール情報は伝送オブジェクトのデコーディングまたは再生時点に対する時間を示す単位である。タイムスケールに基づいたタイミング情報である場合、放送受信装置はＴｉｍｅｓｔａｍｐフィールドの値をタイムスケールをかけてデコーディングまたは再生時点に関する情報を獲得する。

図１２４は、図１２３の拡張されたヘッダの構成に一部の構成が追加された他の実施例を示す図である。

図１２４に示したように、本発明の他の実施例による拡張されたヘッダの構造は該当拡張されたヘッダの構造にＴｉｍｅｓｔａｍｐフィールドが存在するのか否かを示す。Ｔｉｍｅｓｔａｍｐフィールドの存在可否を示す情報はＴＳｆｌａｇフィールドという。具体的な実施例において、ＴＳｆｌａｇフィールドが１に設定されればＴＳｆｌａｇフィールドは該当ヘッダ構造にＴｉｍｅｓｔａｍｐフィールドが存在することを示す。

また、本発明の他の実施例による拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。メディアタイムは任意のメディアタイムラインによるメディア再生時間である。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。ノーマル再生タイムのフォーマットは再生開始時点から相対的に表現される再生時間であり、これは時、分、秒、秒以下の小数点単位で表現される。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥｔｉｍｅｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥｔｉｍｅｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚ基盤のタイミング情報であることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０５に設定される。

また、本発明のまた他の実施例による拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドの構成を示す。詳しくは、拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドに含まれたオブジェクトの再生またはデコーディングに関するタイミング情報の構成を示す。上述した情報をＴＳｖｅｒｓｉｏｎフィールドという。例えば、ＴＳｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳｖｅｒｓｉｏｎフィールドは１に設定される。

図１２５は、図１２３の拡張されたヘッダの構成に一部の構成が追加されたまた他の実施例を示す図である。

図１２５に示したように、本発明のまた他の実施例による拡張されたヘッダの構造は伝送オブジェクトに関する付加情報を含む。具体的な実施例において、拡張されたヘッダの構造はオブジェクトの位置情報を含む。例えば、オブジェクトの位置情報はＩＳＯＢＭＦＦを基盤にするセグメントのＵＲＬ情報を示す。詳しくは、オブジェクトの位置情報はＩＳＯＢＭＦＦを基盤にするセグメントをダウロード可能なＵＲＬ情報を示す。この場合、伝送オブジェクトに関する付加情報はＥｘｔｅｎｓｉｏｎフィールドである。

また、本発明の他の実施例による拡張されたヘッダの構造は該当拡張されたヘッダの構造にＥｘｔｅｎｓｉｏｎフィールドが存在するのか以下かを示す。この場合、Ｅｘｔｅｎｓｉｏｎフィールドが存在するのか否かを示す情報はＥｘｔＦｌａｇフィールドという。

図１２６は、図１２３の新たなヘッダの拡張構造がパケットヘッダの一部に使用された一実施例を示す図である。図１２６に示したように、パケットヘッダの一部が伝送オブジェクトのタイミング情報を含む。伝送オブジェクトのタイミング情報を含むパケットヘッダの一部はＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドである。

ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはパケットペイロードに含まれたデータのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドである。例えば、Ｔｉｍｅｓｔａｍｐフィールドはパケットペイロードに含まれたデータの最初のバイトがデコーディングされる時点に対する情報を含む。他の例として、Ｔｉｍｅｓｔａｍｐフィールドはデータの再生時点に関する情報を含む。加えて、Ｔｉｍｅｓｔａｍｐフィールドはタイムスケール情報またはタイムスケールに基づくタイミング情報を含んでもよい。ここで、タイムスケール情報は伝送オブジェクトのデコーディングまたは再生時点に対する時間を示す単位である。タイムスケールに基づいたタイミング情報である場合、放送受信装置はＴｉｍｅｓｔａｍｐフィールドの値をタイムスケールをかけてデコーディングまたは再生時点に関する情報を獲得する。

また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥｔｉｍｅｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥｔｉｍｅｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚ基盤のタイミング情報であることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０５に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＧＰＳｔｉｍｅフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０６に設定される。

また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはＴｉｍｅｓｔａｍｐフィールドのフォーマットの構成を示す。拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドのフォーマットに含まれたオブジェクト再生またはデコーディングに関するタイミング情報の構成を示す。上述した情報をＴＳｖｅｒｓｉｏｎフィールドという。例えば、ＴＳｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳｖｅｒｓｉｏｎフィールドは１に設定される。

また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはタイミング情報に関する追加的な情報を含む。例えば、マッピングされるタイミング情報に関するデータ情報が含まれる。タイミング情報に関する追加の情報はＥｘｔｅｎｓｉｏｎフィールドという。

また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはＥｘｔｅｎｓｉｏｎフィールドの構成に関する情報を含む。詳しくは、Ｅｘｔｅｎｓｉｏｎフィールドには多様な情報が含まれ、多様な情報ごとにフラッグが集合を成している。この場合、フラッグの集合をＥｘｔｆｌａｇフィールドという。

放送受信装置１００が放送受信部を介して受信した伝送オブジェクトが他の形式または他の基準時間を有するタイミング情報と同期化する必要がある。詳しくは、放送受信装置１００は伝送オブジェクトのタイミング情報とは異なる形式または基準時間を有する同期化のための基準になる基本タイムラインに伝送オブジェクトのタイミング情報を同期化すべきである。一実施例において、同期化するタイミング情報は伝送オブジェクトの再生タイミングである。他の実施例において、同期化するタイミング情報は伝送オブジェクトのデコーディングタイミングである。この場合、放送伝送装置は他のタイミング情報と伝送オブジェクトのタイミング情報間のマッピング関係に関する情報を放送受信装置１００に伝送すべきである。上述した課題を解決するための本発明の一実施例において、上述したｔｉｍｅｌｉｎｅ＿ｃｏｍｐｏｎｅｎｔ＿ＡＵを含むメタデータを一つの伝送オブジェクトにして伝送する。

上述した課題を解決するための他の実施例において、上述した拡張されたヘッダは伝送オブジェクトのタイミング情報とは異なる別途のマッピング情報を含む。詳しくは、拡張されたヘッダ（ＥＸＴ＿ＴＩＭＥ＿ＭＡＰ）は伝送オブジェクトのタイムスタンプを他のＴｉｍｅｌｉｅｎにマッピングするための情報を含む。例えば、放送受信装置１００は制御部１５０を介して上述した情報を利用してパケットペイロードの再生時間をＧＰＳタイムにマッピングする。この場合、ＧＰＳタイムが基本タイムラインである。

図１２７は、本発明の一実施例による他のタイミング情報とのマッピングを支援するための拡張されたヘッダの構成を示す図である。

図１２７に示したように、拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥｔｉｍｅｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥｔｉｍｅｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚ基盤のタイミング情報であることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０５に設定される。また、ＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＧＰＳｔｉｍｅフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０６に設定される。

また、拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドのバージョンまたは構成を示す。拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドのフォーマットに含まれたオブジェクト再生またはデコーディングに関するタイミング情報の構成を示す。上述した情報をＴＳｖｅｒｓｉｏｎフィールドという。例えば、ＴＳｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳｖｅｒｓｉｏｎフィールドは１に設定される。

また、拡張されたヘッダは伝送オブジェクトのタイムスタンプがマッピングされるタイムラインのタイミング情報が存在するのか否かを示す。この場合、存在可否を示す情報はＯＴＳｆｌａｇフィールドという。具体的な一実施例において、ＯＴＳｆｌａｇフィールドが１に設定された場合、伝送オブジェクトのタイムスタンプがマッピングされるタイムラインのタイミング情報が存在することを示す。

また、拡張されたヘッダは伝送オブジェクトのタイムスタンプがマッピングされるタイムラインのスタンプフォーマットを示す。詳しくは、伝送オブジェクトのタイムスタンプはオブジェクトの再生時間及びデコーディング時間のうち少なくとも一つである。また、伝送オブジェクトがタイムスタンプとマッピングされるタイムラインは基本タイムラインである。ここで、基本タイムラインは複数の互いに異なるタイムライン間の同期化のために必要な基準タイムラインである。

上述した情報はＯＴＳｆｏｒｍａｔフィールドである。具体的な実施例において、ＯＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがメディアタイムのフォーマットであることを示す。この場合、ＯＴＳｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＯＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＯＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがノーマル再生タイムのフォーマットであることを示す。この場合、ＯＴＳｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＯＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがＳＭＰＴＥｔｉｍｅｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥｔｉｍｅｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＯＴＳｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＯＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプが９０ＫＨｚ基盤のタイミング情報であることを示す。この場合、ＯＴＳｆｏｒｍａｔフィールドは０ｘ０５に設定される。また、ＯＴＳｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがＧＰＳｔｉｍｅフォーマットであることを示す。この場合、ＯＴＳｆｏｒｍａｔフィールドは０ｘ０６に設定される。

また、拡張されたヘッダはオブジェクトのタイムスタンプと伝送オブジェクトのタイムスタンプとマッピングされるタイムラインのタイムスタンプのバージョンまたは構成を示す。詳しくは、伝送オブジェクトのタイムスタンプはオブジェクト再生時間またはデコーディング時間のうち少なくとも一つである。また、伝送オブジェクトのタイムスタンプとマッピングされるタイムラインは基本タイムラインである。ここで、基本タイムラインは複数の互いに異なるタイムライン間の同期化のために必要な基準タイムラインである。

この場合、伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプの構成またはバージョンを示す情報をＯＴＳｖｅｒｓｉｏｎフィールドという。例えば、ＯＴＳｖｅｒｓｉｏｎフィールドは伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプが３２ビットであることを示す。この場合、ＯＴＳｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＯＴＳｖｅｒｓｉｏｎフィールドは伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプが６４ビットであることを示す。この場合、ＯＴＳｖｅｒｓｉｏｎフィールドは１に設定される。

また、拡張されたヘッダは位置情報を含むか否かを示す。この場合、位置情報を含むか否かを示す情報はＬｏｃａｔｉｏｎｆｌａｇフィールドである。例えば、Ｌｏｃａｔｉｏｎｆｌａｇフィールドが１に設定されれば該当拡張されたヘッダに位置情報が含まれていることを示す。

また、拡張されたヘッダは伝送オブジェクトのタイムスタンプ及び伝送オブジェクトのタイムスタンプと伝送オブジェクトのタイムスタンプとマッピングされるタイムラインのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドという。

また、拡張されたヘッダは拡張されたヘッダのタイムスタンプと伝送オブジェクトのタイムスタンプとマッピングされる伝送オブジェクトに関するタイミング情報を含む。上述した情報はＯｒｉｇｉｎｔｉｍｅｓｔａｍｐフィールドという。

また、拡張されたヘッダは伝送オブジェクトのタイムスタンプとマッピングされるタイムラインに関するデータの位置情報を含む。上述した情報はＬｏｃａｔｉｏｎフィールドという。一実施例において、特定ＩＳＯＢＭＦＦ基盤のデータセグメントのタイムラインとマッピングが必要であればＬｏｃａｔｉｏｎフィールドは該当セグメントのＵＲＬを含む。

図１２８は、本発明の一実施例による放送伝送装置の動作方法を示す図である。

放送伝送装置は制御部を介して伝送のためのオブジェクトを獲得するＳ４０１。一実施例において、オブジェクトはＡＶコンテンツである。他の実施例において、オブジェクトはＡＶコンテンツに関する向上されたデータである。

放送伝送装置は制御部を介してオブジェクトの時間情報及びフォーマット情報を獲得するＳ４０３。一実施例において、時間情報は伝送オブジェクトのタイムスタンプである。他の実施例において、時間情報は伝送オブジェクトのタイムスタンプとマッピングされるタイムラインのタイミング情報である。また他の実施例において、時間情報は拡張されたヘッダ構造のタイムスタンプである。更にの実施例において、時間情報は拡張されたヘッダ構造のタイムスタンプとマッピングされる伝送オブジェクトのタイミング情報である。また、フォーマット情報はレギュラファイル、ＨＴＴＰエンティティ及びオーディオまたはビデオアクセスユニットのうち少なくとも一つである。

詳しくは、伝送オブジェクトのタイムスタンプはオブジェクトの再生時間及びデコーディング時間のうち少なくとも一つである。また、伝送オブジェクトがタイムスタンプとマッピングされるタイムラインは基本タイムラインである。ここで、基本タイムラインは複数の互いに異なるタイムライン間の同期化のために必要な基準タイムラインである。例えば、基本タイムラインがＧＰＳｔｉｍｅであってもよく、伝送オブジェクトをＧＰＳｔｉｍｅと同期化するための情報が上述した拡張されたヘッダに含まれてもよい。

放送伝送装置は制御部を介して獲得した時間情報及びフォーマット情報をパケットヘッダに設定して伝送パケットをパケット化するＳ４０５。詳しくは、放送伝送装置の制御部は獲得した時間情報を含むパケットヘッダ及びデータを含むパケットデータを伝送プロトコールに応じてパケット化する。他の実施例において、放送伝送装置は制御部を介してパケットヘッダに選択的に含まれる拡張されたヘッダに時間情報及びフォーマット情報を設定する。

詳しくは、時間情報はオブジェクトの再生時間に関する情報である。再生時間に関する情報は伝送オブジェクトの再生時点（タイミング情報）及びデコーディング時点（タイミング情報）のうち少なくとも一つである。他の実施例において、追加の情報は伝送オブジェクトのタイプ情報である。放送伝送装置は一般的なパケットヘッダに拡張されたヘッダの存在するか否か、拡張されたヘッダの長さ及び拡張されたヘッダのタイプ情報のうち少なくとも一つを設定する。

放送伝送装置は伝送部を介してパケット化された伝送パケットを伝送するＳ４０７。伝送部は伝送パケットを地上波放送網及びインターネット網のうち少なくとも一つを介して伝送する。

図１２９は、本発明の一実施例による放送受信装置の動作方法を示す図である。

放送受信装置１００は放送受信部１１０を介して伝送パケットを受信するＳ４１１。図１２８において、説明のように伝送パケットはパケットヘッダ及びパケットペイロードを含むが、パケットヘッダは拡張されたヘッダを選択的に含む。

放送受信装置１００の制御部１５０は受信した伝送パケットからパケットヘッダ及び拡張されたヘッダを抽出するＳ４１２。具体的な実施例において、制御部１５０は伝送パケットに含まれたパケットヘッダを抽出する。また、パケットヘッダに選択的に含まれる拡張されたヘッダをパケットヘッダから抽出する。

放送受信装置１００の制御部１５０はパケットヘッダに基づいて伝送オブジェクトに関する時間情報及び伝送オブジェクトのフォーマット情報のうち少なくとも一つを獲得するＳ４１３。他の実施例において、制御部１５０はパケットヘッダに選択的に含まれる拡張されたヘッダから前記時間情報及びフォーマット情報のうち少なくとも一つを獲得する。具体的な実施例において、制御部１５０は拡張されたヘッダに基づいて伝送オブジェクトのタイムスタンプを獲得する。また、制御部１５０は伝送オブジェクトのフォーマット情報を獲得する。伝送オブジェクトのフォーマット情報はレギュラファイル、ＨＴＴＰエンティティ及びオーディオまたはビデオアクセスユニットのうち少なくとも一つを示す。ここで、レギュラファイルとはＩＳＯＢＭＦＦ基盤のメディアファイルである。

放送受信装置１００の制御部１５０はパケットヘッダから他の時間情報とマッピングするための情報を獲得できるのか否かを判断するＳ４１４。詳しくは、制御部１５０は該当伝送オブジェクトのための時間情報とマッピングされる他の時間情報がパケットヘッダに存在するのか否かを判断する。他の実施例において、制御部１５０はパケットヘッダに選択的に含まれる拡張されたヘッダから抽出された特定情報に基づいて判断する。

一実施例において、制御部１５０がパケットヘッダから他の時間情報とマッピングするための情報を獲得できると判断した場合、制御部１５０はパケットヘッダからマッピングのための情報を獲得するＳ４１５。ここで、他の時間情報は上述した基本タイムラインのタイミング情報である。また、タイミング情報は伝送オブジェクトの再生タイミング情報及びデコーディングタイミング情報のうち少なくとも一つを含む。具体的な実施例において、制御部１５０はパケットヘッダに基づいて伝送オブジェクトとマッピングされるタイムラインのタイミング情報を獲得する。他の実施例において、制御部１５０はパケットヘッダに基づいてパケットヘッダのタイムスタンプとマッピングされる伝送オブジェクトのタイミング情報を獲得する。また、制御部１５０はパケットヘッダに基づいて伝送オブジェクトとマッピングされるデータの位置情報を獲得する。また他の実施例において、制御部１５０はパケットヘッダに選択的に含まれる拡張されたヘッダからマッピングのための情報を獲得してもよい。

放送受信装置１００の制御部１５０は獲得した時間情報に基づいて伝送オブジェクトを出力するＳ４１６。一実施例において、制御部１５０が他の時間情報とマッピング情報を獲得できなかった場合、該当伝送オブジェクトのタイムスタンプに基づいてオブジェクトを出力する。他の実施例において、制御部１５０が他の時間情報とマッピング情報を獲得した場合、該当マッピング情報及びオブジェクトのタイムスタンプに基づいてオブジェクトを出力する。

図１３０は、伝送パケットの構成に対する情報を含むパケットヘッダの構成を示す図である。

本発明の一実施例によるパケットヘッダは全体の伝送オブジェクトのうち最初または最後の部分のデータがパケットペイロードに含まれていることを示す。この場合、最初または最後の部分のデータが含まれていることを示す情報はマーカービットである。また、マーカービットはＭフィールドである。Ｍフィールドは１ビットである。

また、本発明の一実施例によるパケットヘッダは該当伝送パケットの構成に関する情報を含む。この場合、伝送パケットの構成に関する情報はＴｙｐｅフィールドである。Ｔｙｐｅフィールドは２ビットである。

他の場合、伝送パケットの構成に関する情報はＣｏｄｅｐｏｉｎｔフィールドである。Ｃｏｄｅｐｏｉｎｔフィールドは８ビットである。

具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットがレギュラパケット構造であることを示す。詳しくは、該当パケットが図１１９に示した従来の伝送パケット構造をそのまま使用していることを示す。この場合、伝送パケットはパケットヘッダ、拡張されたヘッダ、パケットペイロード識別子及びデータのうち少なくともいずれか一つを含む。また、放送伝送装置はＴｙｐｅフィールドを０ｘ００に設定する。

また、具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットがペイロードを含んでいないことを示す。詳しくは、該当伝送パケットがパケットヘッダ及び拡張されたヘッダのみを含んでいることを示す。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０１に設定する。

また、具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットが全体の伝送オブジェクトに対するオフセット情報を含むことを示す。ここで、オフセット情報とは該当伝送パケットのエンコーディングシンボルフィールドが含んでいるデータのオフセット情報である。つまり、オフセット情報は全体の伝送オブジェクトから該当伝送パケットの構造と構成は同じであるが、ペイロード識別子フィールドがデータオフセットフィールドに代替される。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０２に設定する。

また、具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットが従来のレギュラ伝送パケットの構造とは異なる構成を含むことを示す。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０３に設定する。具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットがペイロード識別子フィールドを含んでいないことを示す。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０４に設定する。図１３１は、図１３０の伝送パケットの構成を示す図である。図１３１に示したように、Ｔｙｐｅフィールドは伝送パケットの構造を示す。しかし、図１３１に示した伝送パケットに限ることはなく、必ずしも図１３１に設定された値に本発明が限定されることはない。

図１３２は、本発明の一実施例による放送伝送装置の動作方法を示す図である。

放送伝送装置は制御部を介して伝送のためのオブジェクトを獲得する（Ｓ４２１）。一実施例において、伝送パケットの構造は従来のレギュラパケット構造である。他の実施例において、伝送パケットの構造は従来のパケットヘッダ及び拡張されたヘッダののみで構成された構造である。また他の実施例において、伝送パケットの構造は従来のペイロード識別子を代替する構成を含む構造である。更に他の実施例において、伝送パケットの構造はペイロード識別子を含まない構造である。

放送伝送装置は制御部を介して獲得した伝送パケットの構造に基づいて、該当構造の情報を示す値をパケットヘッダに設定して伝送パケットをパケット化する（Ｓ４２３）。詳しくは、制御部は該当構造の情報をＴｙｐｅフィールドに設定する。

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

図１３３は、本発明の一実施例による放送受信装置の動作方法を示す図である。

放送受信装置１００は放送受信部１１０を介して伝送パケットを受信する（Ｓ４３１）。一実施例において、放送受信部１１０は地上波放送網を介して伝送パケットを受信する。他の実施例において、ＩＰコミュニケーションユニット１３０はインターネット網を介して伝送パケットを受信する。

放送受信装置１００は制御部１５０を介して受信した伝送パケットからパケットヘッダを抽出する（Ｓ４３３）。詳しくは、伝送パケットはパケットヘッダ及びパケットペイロードのうち少なくとも一つを含む。よって、制御部１５０は伝送パケットからペイロードをシグナリングするパケットヘッダを抽出する。

放送受信装置１００は抽出したパケットヘッダから伝送パケットの構成情報を獲得する（Ｓ４３５）。詳しくは、パケットヘッダは伝送パケットの構造を示す情報を含む。よって、放送受信装置１００は制御部１５０を介してパケットヘッダから伝送パケットの構造を示す情報を獲得する。一実施例において、伝送パケットの構造は従来のレギュラ伝送パケット構造である。他の実施例において、伝送パケットの構造は従来のパケットヘッダ及び拡張されたヘッダのみを含む構造である。また他の実施例において、伝送パケットの構造はパケットペイロード識別子を代替するオフセット情報を含む構造である。更に他の実施例において、伝送パケットの構造はパケットペイロード識別子を含まない構造である。

図１３４は、本発明の一実施例に係るＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ）を含むタイムラインリファレンス情報ＡＵ（ｔｉｍｅｌｉｎｅｒｅｆｅｒｅｎｃｅｉｎｆｏｒｍａｔｉｏｎＡＵ）を示す図である。

本発明は、前述したタイムラインリファレンス情報ＡＵにＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ）を挿入して送信することを提案する。また、本発明は、前述したＬＣＴパケットフィールドの拡張にＳＰＤを挿入して送信することを提案する。これによって、別個の網（例えば、インターネット網と放送網）で伝送されるメディアストリームのタイムラインを受信機で再構成して円滑に再生することができる。また、ＳＰＤの反映されたタイムラインリファレンス／タイムスタンプを伝送することによって、別個の受信環境に存在する受信機間の同期化を効果的に支援することができる。

ＳＰＤは、外部網又は内部網で伝送されるメディアストリームの生成時点を基準に消費時点までの提案遅延時間を意味することができる。又は、実施例によって、ＳＰＤは、メディアストリームのエンコーディング時点を基準にデコーディング時点までの提案遅延時間を意味することもできる。又は、メディアストリームのランダムアクセス（ＲａｎｄｏｍＡｃｃｅｓｓ）が可能な特定単位を放送ストリームに含めるとき、当該単位の最初のバイトが含まれる時間と当該単位の最後のバイトが含まれる時間との差を意味することもできる。当該データ単位は、ＲＡＰ（ＲａｎｄｏｍＡｃｃｅｓｓＰｏｉｎｔ）を含むことができる。ＳＰＤの基準となる両時点は実施例によって変更されてもよい。ＳＰＤ、すなわち、提案遅延時間は、受信機のバッファタイム（ＢｕｆｆｅｒＴｉｍｅ；ＢＴ）による再生時間の差を補完するために用いることができる。複数個の受信機において、実際のネットワーク帯域（ｐｒａｃｔｉｃａｌｎｅｔｗｏｒｋｂａｎｄｗｉｄｔｈ）が異なることから、バッファタイムも受信機ごとに異なりうる。バッファタイムの差によって、同じメディアデータが伝送側から放送されても、受信機での再生時間はそれぞれ異なりうる。これを補完して、タイムラインリファレンス又はタイムスタンプ値にＳＰＤを反映することによって、いずれの受信機でも同一時間に同一メディアを再生することができる。又は、メディアストリームのランダムアクセスが可能な特定単位が放送ストリームで伝送されるとき、当該単位に含まれた最も早い再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅ）を導出するために用いられてもよい。当該単位に含まれた最も早い再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅ）は、データを搬送するパケットが生成されたサーバーの時間（ＳｅｎｄｅｒＣｕｒｒｅｎｔＴｉｍｅ）、上記ＳＰＤが考慮された再生タイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅｓｔａｍｐ）、及びパケットの実際の受信時間などを考慮して導出することができる。

ＳＰＤは、タイムラインリファレンス情報ＡＵを用いて内部網又は外部網で伝送されるメディアストリームのタイムラインを再構成する時に反映することができる。すなわち、内部網又は外部網のタイムラインを再構成する時、内部網又は外部網のタイムラインリファレンス値からＳＰＤ値を引いて、提案遅延時間が反映されたタイムラインを構成することができる。

また、ＳＰＤは、該当のメディアデータのプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅ）などの情報を含むタイムスタンプが伝達されて同期化が行われる場合に反映することができる。すなわち、タイムスタンプを用いた同期化において、タイムスタンプ値にＳＰＤの値を足して、提案遅延時間が反映された同期化を行うことができる。

前述したように、タイムラインリファレンス情報ＡＵは、別個の網で伝送されるストリーム間の同期化を取るために用いることができる。ここで、図示されたタイムラインリファレンス情報ＡＵは、前述したタイムラインコンポーネントＡＵ（ＴｉｍｅｌｉｎｅｃｏｍｐｏｎｅｎｔＡＵ）、又はタイムラインリファレンス情報ＡＵ（ｔｉｍｅｌｉｎｅｒｅｆｅｒｅｎｃｅｉｎｆｏｒｍａｔｉｏｎＡＵ）の別の実施例であってもよい。

本発明の一実施例に係るＳＰＤを含むタイムラインリファレンス情報ＡＵの各フィールド及び構造を説明する。

ＡＵ＿ｉｄｅｎｔｉｆｉｅｒフィールドは、前述したＡＵ＿ｉｄｅｎｔｉｆｉｅｒ情報を意味することができる。すなわち、ＡＵ＿ｉｄｅｎｔｉｆｉｅｒフィールドは、当該タイムラインリファレンス情報ＡＵを識別することができる。また、ＡＵ＿ｉｄｅｎｔｉｆｉｅｒフィールドは、当該タイムラインリファレンス情報ＡＵがいかなる構造を有するかを識別することもできる。実施例によって、ＡＵ＿ｉｄｅｎｔｉｆｉｅｒフィールドは８ビットのサイズを有することができる。

ＡＵ＿ｌｅｎｇｔｈフィールドは、前述したＡＵ＿ｌｅｎｇｔｈ情報を意味することができる。すなわち、ＡＵ＿ｌｅｎｇｔｈフィールドは、当該タイムラインリファレンス情報ＡＵの長さ情報を含むことができる。このフィールドは、実施例によって、３２ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。

ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇフィールドは、前述したｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報を意味することができる。ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇフィールドは、当該タイムラインリファレンス情報ＡＵがｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドを有するか否かを示すフラグ（ｆｌａｇ）であってもよい。すなわち、このフィールドは、外部網で伝送されるストリームのＵＲＬ情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドは、１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報を意味することができる。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドは、当該タイムラインリファレンス情報ＡＵがｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドを含んでいるか否かを示すフラグであってもよい。すなわち、このフィールドは、内部網のタイムラインリファレンス情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドは、１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。

ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドは、前述したｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報を意味することができる。ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドは、当該タイムラインリファレンス情報ＡＵがｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドを含んでいるか否かを示すフラグであってもよい。すなわち、このフィールドは、外部網のタイムラインリファレンス情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドは、１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。

ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｆｌａｇフィールドは、当該タイムラインリファレンス情報ＡＵがｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙフィールドを含むか否かを示すことができる。すなわち、このフィールドは、ＳＰＤ情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドは、１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙフィールドについては後述する。

フラグフィールド後には、一定のサイズのビットが将来の使用のために残されていてもよい（Ｒｅｓｅｒｖｅｄｆｏｒｆｕｒｔｕｒｅｕｓｅ）。本実施例では、４ビットの空間が将来の使用のために残されている。

タイムラインリファレンス情報ＡＵは、内部網のタイムラインリファレンスに関連した情報をさらに含むことができる。ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇフィールドの値によって、タイムラインリファレンス情報ＡＵは、外部網で伝送されるストリームのＵＲＬ情報をさらに含むことができる。このとき、追加されるフィールドについて説明する。

ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドの長さをバイト単位で表現できる。このフィールドは、８ビットのフィールドであり、ｕｉｍｓｂｆフォーマットであってもよい。

ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドも、タイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドは、外部網で伝送されるメディアの位置情報及び／又は当該メディアの固有識別情報を含むことができる。この情報に基づいて、外部網で伝送されるメディアに接近することができる。例えば、外部網で伝送されるメディアがＤＡＳＨによるメディアである場合、メディアの当該ＭＰＤのＭＰＤＵＲＬ、ＭＰＤＩＤなどの情報がｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドに含まれてもよい。このフィールドは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドが示す値に該当するビット数を有することができる。又は、実施例によって、このフィールドは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドが示す値に８を乗じた分のビット数を有することができる。

タイムラインリファレンス情報ＡＵは、内部網のタイムラインリファレンスに関連した情報をさらに含むことができる。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドの値によって、タイムラインリファレンス情報ＡＵは、内部網のタイムラインに関連した追加フィールドをさらに含むことができる。このとき、追加されるフィールドについて説明する。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールドは、タイムラインリファレンス情報ＡＵに含まれた内部網のタイムラインリファレンス情報のフォーマットを示すことができる。例えば、このフィールドが０ｘ００値を有する場合、内部網のタイムラインリファレンス情報はメディアタイム（ｍｅｄｉａｔｉｍｅ）フォーマット、０ｘ０１値を有する場合にはＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）フォーマット、０ｘ０２値を有する場合にはＰＴＰフォーマット、０ｘ０３値を有する場合にはタイムコード（ｔｉｍｅｃｏｄｅ）フォーマットを示すことができる。０ｘ０４乃至０ｘＦＦ値を有する場合には、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄｆｏｒｆｕｔｕｒｅｕｓｅ）。このフィールドは、８ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドは、タイムラインリファレンス情報ＡＵに内部網のタイムラインリファレンス情報の時間単位（ｔｉｍｅｓｃａｌｅ）が含まれたか否かを示すフラグであってもよい。このフィールドは、１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドは、タイムラインリファレンス情報ＡＵに含まれた内部網のタイムラインリファレンス情報の長さをバイト単位で示すことができる。このフィールドは、７ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールドは、タイムラインリファレンス情報ＡＵに含まれた内部網のタイムラインリファレンス情報の時間単位（ｔｉｍｅｓｃａｌｅ）をＨｚ単位で示すことができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド値によって存在してもしなくてもよい。このフィールドは、３２ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。

ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドは、内部網のタイムラインリファレンス情報を有することができる。このフィールドの値によって、内部網で伝送されるメディアストリームのタイムラインを再構成することができる。このフィールドは、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドが示す値に該当するビット数を有することができる。又は、実施例によって、このフィールドは、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドが示す値に８を乗じた分のビット数を有することもできる。

タイムラインリファレンス情報ＡＵは、外部網のタイムラインリファレンスに関連した情報をさらに含むことができる。ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドの値によって、タイムラインリファレンス情報ＡＵは、外部網のタイムラインに関連した追加フィールドをさらに含むことができる。このとき、追加されるフィールドについて説明する。

この場合、タイムラインリファレンス情報ＡＵは、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールド、及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドがさらに含むことができる。

追加された各フィールドは、外部網で伝送されるメディアストリームに関する情報を有することができる。各フィールドは、前述した内部網で伝送されるメディアストリームに関するフィールドと対応して、類似の動作を行うことができる。ただし、この場合、各フィールドは、内部網ではなく外部網に関する情報を有することができる。

すなわち、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドは、それぞれ、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールド、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールド、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールド、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドと類似の動作を行うことができる。

外部網で伝送されるメディアストリームに関するフィールドはそれぞれ、外部網で伝送されるメディアストリームのフォーマット、時間単位情報の存否、長さ、時間単位、タイムラインリファレンスを示すことができる。

タイムラインリファレンスフィールドＡＵは、ＳＰＤに関連したフィールドをさらに含むことができる。ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｆｌａｇフィールドの値によって、タイムラインリファレンスフィールドＡＵは、ＳＰＤに関連した追加フィールドをさらに含むことができる。このとき、追加されるフィールドについて説明する。

ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドは、当該タイムラインリファレンス情報ＡＵにｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅフィールドが含まれているか否かを示すことができる。ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅフィールドについては後述する。すなわち、このフィールドは、ＳＰＤの時間単位関連情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドが０に設定され、ＳＰＤの時間単位関連情報が存在しない場合に、ＳＰＤの時間単位はノーマルクロック（ｎｏｒｍａｌｃｌｏｃｋ）値で表現されてもよい。このフィールドは１ビットのフィールドであり、ｂｌｓｂｆフォーマットを有することができる。

ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｌｅｎｇｔｈフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。このフィールドは、ＳＰＤの長さをバイト単位で示すことができる。このフィールドは、７ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。

ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。このフィールドは、ＳＰＤの時間単位（ｔｉｍｅｓｃａｌｅ）をＨｚ単位で示すことができる。このフィールドは、前述したｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドの値によってその存否が決定されてもよい。このフィールドは３２ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。

ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。このフィールドは、ＳＰＤ情報を有することができる。すなわち、このフィールドは、外部網又は内部網で伝送されるメディアストリームの生成時点を基準に消費時点までの提案遅延時間情報を含むことができる。タイムラインリファレンス情報ＡＵを用いて内部網／外部網のメディアストリームのタイムラインを再構成する時、それぞれの内部網／外部網のタイムラインリファレンス値からこのフィールドの値を引いた値を反映することができる。これによって、提案遅延時間の反映されたタイムラインを構成することができる。このフィールドは、前述したｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｌｅｎｇｔｈフィールドが示す値に該当するビット数を有することができる。又は、実施例によって、このフィールドは、ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｌｅｎｇｔｈフィールドが示す値に８を乗じた分のビット数を有することもできる。このフィールドはｕｉｍｓｂｆフォーマットを有することができる。

図１３５は、本発明の他の実施例に係るＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ）を含むタイムラインリファレンス情報ＡＵ（ｔｉｍｅｌｉｎｅｒｅｆｅｒｅｎｃｅｉｎｆｏｒｍａｔｉｏｎＡＵ）を示す図である。

図示された他の実施例に係るＳＰＤを含むタイムラインリファレンス情報ＡＵは、複数個の内部網又は外部網のタイムラインリファレンス情報を含むことができる。前述したように、タイムラインリファレンス情報ＡＵは、別個の網で伝送されるメディアストリーム間にタイムラインの同期化を取るために用いることができる。

ＡＵ＿ｉｄｅｎｔｉｆｉｅｒフィールド、ＡＵ＿ｌｅｎｇｔｈフィールド、ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｆｌａｇフィールド、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈフィールド、及び／又はｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドは、前述したとおりである。ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇフィールドは、前述したｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドのような役割を担うことができる。

ｎｂ＿ｏｆ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドは、当該タイムラインリファレンス情報ＡＵに含まれたタイムラインリファレンスの個数を示すことができる。前述したように、本実施例のタイムラインリファレンス情報ＡＵは、複数個のタイムラインリファレンス情報を有することができる。このフィールドは６ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。

ｎｂ＿ｏｆ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドが示す個数分のタイムラインリファレンス関連情報が、タイムラインリファレンス情報ＡＵに含まれてもよい。各タイムラインリファレンスに対して、次のようなフィールドが存在してもよい。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅフィールドは、当該タイムラインリファレンスがいかなるタイプのタイムラインリファレンスであるかを示すことができる。例えば、このフィールドの値が０である場合、当該タイムラインリファレンスが内部網で伝送されるメディアストリームのタイムラインリファレンスであってもよい。また、このフィールドの値が１である場合、当該タイムラインリファレンスが外部網で伝送されるメディアストリームのタイムラインリファレンスであってもよい。このフィールドは１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｉｄｅｎｔｉｆｉｅｒフィールドは、当該タイムラインリファレンスの固有識別子を示すことができる。このフィールドは０〜１２７の整数値で割り当てられてもよい。このフィールドは７ビットのサイズを有し、ｕｉｍｓｂｆフィールドを有することができる。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールドは、当該タイムラインリファレンスのフォーマットを示すことができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールドと同じ方式で当該タイムラインリファレンスのフォーマットを示すことができる。このフィールドは８ビットのサイズを有し、ｕｉｍｓｂｆフォーマットを有することができる。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドは、当該タイムラインリファレンスの時間単位（ｔｉｍｅｓｃａｌｅ）に関する情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドと同じ方式で時間単位関連情報が存在するか否かを示すことができる。このフィールドは１ビットのサイズを有し、ｂｓｌｂｆフォーマットを有することができる。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドは、当該タイムラインリファレンスの長さをバイト単位で示すことができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドと同じ方式で長さを示すことができる。このフィールドは７ビットのサイズを有し、ｕｉｍｓｂｆフォーマットを有することができる。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールドは、当該タイムラインリファレンスの時間単位をＨｚ単位で示すことができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールドと同じ方式で時間単位を示すことができる。このフィールドは３２ビットのサイズを有し、ｕｉｍｓｂｆフォーマットを有することができる。

ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドは、当該タイムラインリファレンスのタイムラインリファレンス値を示すことができる。このフィールド値によって、当該内／外部網で伝送されるメディアストリームのタイムラインを再構成することができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドと同じ方式でタイムラインを示すことができる。このフィールドは、前述したｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドが示す値に該当するビット数を有することができる。又は、実施例によって、このフィールドは、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドが示す値に８を乗じた分のビット数を有することもできる。このフィールドはｕｉｍｓｂｆフォーマットを有することができる。

ＳＰＤと関連したフィールドを前述の構造でタイムラインリファレンス情報ＡＵに含めることができる。ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド、ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｌｅｎｇｔｈフィールド、ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅフィールド及び／又はｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙフィールドは、前述した同名のフィールドと同一であってもよい。

図１３６は、本発明の一実施例に係るＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ）を含むＬＣＴパケット構造を示す図である。

前述したように、ＬＣＴパケットは、タイムラインリファレンス関連情報を伝送することができる。ＬＣＴパケットのヘッダーを拡張して、別個の網で伝送されるメディアストリーム間に同期化のための情報が伝送することができる。提案された構造は、ＲＴＰ（ＲｅａｌＴｉｍｅＰｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用されてもよい。また、提案された構造は、伝送プロトコルに適したサービスシグナリング情報と連動して用いられてもよい。サービスシグナリング情報は、当該ストリームが内部又は外部網のタイムラインリファレンスを伝送していることを示す情報、外部網で伝送されるメディアのＵＲＬ情報、前述した各種フラグ情報、タイムラインリファレンスの時間単位情報など、各パケットに共通して適用可能な情報を含むことができる。

Ｖフィールド、Ｃフィールド、ＰＳＩフィールド、Ｓフィールド、Ｏフィールド、Ｈフィールド、Ｒｅｓフィールド、Ａフィールド、Ｂフィールド、ＨＤＲ＿ＬＥＮフィールド、ＣＰフィールド、ＣＣＩフィールド、ＴＳＩフィールド、ＴＯＩフィールドは、前述したとおりである。

ＨＥＴ（ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎＴｙｐｅ）フィールドは、当該ＬＣＴパケットヘッダーの拡張（ｅｘｔｅｎｓｉｏｎ）タイプを示すことができる。このフィールドは１２７以下の値を割り当てて、ＬＣＴパケットヘッダーの拡張タイプを示すことができる。本実施例では、ＨＥＴフィールドが２の値を有し、ＬＣＴパケットヘッダーがＥＸＴ＿ＴＩＭＥの拡張タイプを有することを示すことができる。

ＨＥＬ（ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎＬｅｎｇｔｈ）フィールドは、当該ＬＣＴパケットヘッダーの拡張の長さを示すことができる。この長さは、３２ビットワード（ｗｏｒｄ）単位で表現することができる。

ＵＳＥフィールドの細部フィールドは、次のとおりである。ＳＣＴＨＩフィールド、ＳＣＴＬｏｗフィールド、ＥＲＴフィールド、ＳＬＣフィールドは、前述したとおりである。

ＩＴＲＨｉ（ＩｎｔｅｒｎａｌＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅＨｉｇｈＦｌａｇ）フィールドは、当該ＬＣＴパケットヘッダーの拡張に、６４ビットの内部タイムラインリファレンスフィールドが含まれることを示すことができる。

ＩＴＲＬｏｗ（ＩｎｔｅｒｎａｌＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅＬｏｗＦｌａｇ）フィールドは、当該ＬＣＴパケットヘッダーの拡張に、３２ビットの内部タイムラインリファレンスフィールドが含まれることを示すことができる。

ＥＴＲＨｉ（ＥｘｔｅｒｎａｌＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅＨｉｇｈＦｌａｇ）フィールドは、当該ＬＣＴパケットヘッダーの拡張に、６４ビットの外部タイムラインリファレンスフィールドが含まれることを示すことができる。

ＥＴＲＬｏｗ（ＥｘｔｅｒｎａｌＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅＬｏｗＦｌａｇ）フィールドは、当該ＬＣＴパケットヘッダーの拡張に、３２ビットの外部タイムラインリファレンスフィールドが含まれることを示すことができる。

ＩＴＲＳｃａｌｅフィールドは、当該ＬＣＴパケットヘッダーの拡張に、３２ビットの内部タイムラインリファレンスタイムスケールフィールドが含まれることを示すことができる。

ＥＴＲＳｃａｌｅフィールドは、当該ＬＣＴパケットヘッダーの拡張に、３２ビットを外部タイムラインリファレンスタイムスケールフィールドが含まれることを示すことができる。

ＩＴＲＦｏｒｍａｔフィールドは、当該ＬＣＴパケットヘッダーの拡張に含まれた内部タイムラインリファレンスフィールドのフォーマットを示すことができる。すなわち、このフィールドは、内部網で伝送されるメディアストリームのタイムラインリファレンスのフォーマットを示すことができる。

ＥＴＲＦｏｒｍａｔフィールドは、当該ＬＣＴパケットヘッダーの拡張に含まれた外部タイムラインリファレンスフィールドのフォーマットを示すことができる。すなわち、このフィールドは、外部網で伝送されるメディアストリームのタイムラインリファレンスのフォーマットを示すことができる。

ＩＴＲＦｏｒｍａｔフィールド及びＥＴＲＦｏｒｍａｔフィールドの値が０ｘ００である場合、当該タイムラインリファレンスはメディアタイム（ｍｅｄｉａｔｉｍｅ）フォーマットを有し、０ｘ０１である場合にはＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）フォーマットを有し、０ｘ０２である場合にはＰＴＰフォーマットを有し、０ｘ０３である場合にはタイムコード（ｔｉｍｅｃｏｄｅ）フォーマットを有することができる。０ｘ０４乃至０ｘ０Ｆの値を有する場合には、将来の使用のために残しておくことができる。

ＵＲＬ（外部メディアＵＲＬフラグ）フィールドは、当該ＬＣＴパケットのヘッダーの拡張に外部メディアＵＲＬフィールドが存在するか否かを示すフラグであってもよい。

ＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙＦｌａｇ）フィールドは、当該ＬＣＴパケットのヘッダーの拡張にＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙフィールドが含まれているか否かを示すフラグであってもよい。

ＳＰＤＳｃａｌｅフィールドは、当該ＬＣＴパケットのヘッダーの拡張にｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙｔｉｍｅｓｃａｌｅフィールドが含まれているか否かを示すフラグであってもよい。このフラグフィールドが０に設定される場合、ｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙｔｉｍｅｓｃａｌｅフィールドが存在しなくてもよい。この場合、ｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙフィールドは、ＳＰＤを秒単位のノーマルクロック（ｎｏｒｍａｌｃｌｏｃｋ）で表現することができる。

ＵＳＥフィールドの余りビットは、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄｆｏｒｆｕｔｕｒｅｕｓｅ）。

ＳｅｎｄｅｒＣｕｒｒｅｎｔＴｉｍｅフィールド、ＥｘｐｅｃｔｅｄＲｅｓｉｄｕａｌＴｉｍｅフィールド、ＳｅｓｓｉｏｎＬａｓｔＣｈａｎｇｅｄフィールドは、前述したとおりである。

ＩｎｔｅｒｎａｌＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅフィールドは、内部網で伝送されるメディアストリームのタイムラインリファレンス情報を示すことができる。このフィールドの値に基づいて、内部網で伝送されるメディアストリームのタイムラインを再構成することができる。前述したＩＴＲＨｉフィールド又はＩＴＲＬｏｗフィールドの値によって、このフィールドが存在するか否かが決定されてもよい。

ＥｘｔｅｒｎａｌＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅフィールドは、外部網で伝送されるメディアストリームのタイムラインリファレンス情報を示すことができる。このフィールドの値に基づいて、外部網で伝送されるメディアストリームのタイムラインを再構成することができる。前述したＥＴＲＨｉフィールド又はＥＴＲＬｏｗフィールドの値によって、このフィールドが存在するか否かが決定されてもよい。

ＩｎｔｅｒｎａｌＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅＴｉｍｅｓｃａｌｅフィールドは、内部網で伝送されるメディアストリームのタイムラインリファレンスの時間単位をＨｚで示すことができる。このフィールドは、前述したＩＴＲＳｃａｌｅフィールドによってその存否が決定されてもよい。

ＥｘｔｅｒｎａｌＴｉｍｅｌｉｎｅＲｅｆｅｒｅｎｃｅＴｉｍｅｓｃａｌｅフィールドは、外部網で伝送されるメディアストリームのタイムラインリファレンスの時間単位をＨｚで示すことができる。このフィールドは、前述したＥＴＲＳｃａｌｅフィールドによってその存否が決定されてもよい。

外部メディアＵＲＬフィールドは、外部網で伝送されるメディアの位置情報及び／又は当該メディアの固有識別情報を含むことができる。この情報に基づいて、外部網で伝送されるメディアに接近することができる。例えば、外部網で伝送されるメディアがＤＡＳＨによるメディアである場合、メディアの当該ＭＰＤのＭＰＤＵＲＬ、ＭＰＤＩＤなどの情報がＵＲＬフィールドに含まれてもよい。

ｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙフィールドは、ＳＰＤ情報を含むことができる。すなわち、外部網又は内部網で伝送されるメディアストリームの生成時点を基準に消費時点までの提案遅延時間を、このフィールドで表現することができる。内部網又は外部網で伝送されるメディアストリームのタイムラインが再構成される時、各タイムラインリファレンス値からこのフィールドの値を引いた値を反映してタイムラインを構成することができる。

ｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙｔｉｍｅｓｃａｌｅフィールドは、前述したｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙフィールドが示すＳＰＤ情報の時間単位を示すことができる。この時間単位は実施例によってＨｚであってもよい。

ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎｓフィールド、ＦＥＣＰａｙｌｏａｄＩＤフィールド、ＥｎｃｏｄｉｎｇＳｙｍｂｏｌ（ｓ）フィールドは、前述したとおりである。

図１３７は、本発明の他の実施例に係るＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ）を含むＬＣＴパケット構造を示す図である。

本実施例は、前述したＳＰＤを含むＬＣＴパケット構造と類似しているが、ＳｅｎｄｅｒＣｕｒｒｅｎｔＴｉｍｅフィールド、ＥｘｐｅｃｔｅｄＲｅｓｉｄｕａｌＴｉｍｅフィールド及び／又はＳｅｓｓｉｏｎＬａｓｔＣｈａｎｇｅｄフィールドが省略されてもよい。このフィールドが省略されることにより、これらのフィールドのフラグフィールドであるＳＣＴＨｉフィールド、ＳＣＴＬｏｗフィールド、ＥＲＴフィールド及び／又はＳＬＣフィールドも省略されてもよい。

省略されたフィールドは、一般目的のタイミング情報であり、内／外部網を介したタイムラインリファレンス情報がＬＣＴパケットに既に含まれており、省略されてもいいわけである。これによって、ＬＣＴパケット構造の効率性を挙げることもできる。

図１３８は、本発明の更に他の実施例に係るＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。

ＡＬＣ／ＬＣＴパケットヘッダーの拡張は様々なタイプを含むことができる。ヘッダーの拡張タイプとして、サーバーのウォールクロック（ｗａｌｌｃｌｏｃｋ）などの時間関連の情報を伝達するヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）を挙げることができる。本実施例は、ＥＸＴ＿ＴＩＭＥの一実施例を示す。

本実施例で、ＨＥＴフィールド、ＨＥＬフィールド、ＳＣＴＨｉフィールド、ＳＣＴＬｏｗフィールド、ＥＲＴフィールド（又はＥＲＴｆｌａｇフィールド）、ＳＬＣフィールド（又はＳＬＣｆｌａｇフィールド）、Ｒｅｓフィールド（又はＲｅｓ．ｂｙＬＣＴフィールド）、ＳＰＤフィールド（又はＳＰＤｆｌａｇフィールド）、ＳｅｎｄｅｒＣｕｒｒｅｎｔＴｉｍｅフィールド、ＥｘｐｅｃｔｅｄＲｅｓｉｄｕａｌＴｉｍｅフィールド、ＳｅｓｓｉｏｎＬａｓｔＣｈａｎｇｅｄフィールド及び／又はＳｕｅｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙＴｉｍｅｓｃａｌｅフィールドは、前述したとおりである。

本実施例のＬＣＴパケット構造は、前述したＳＰＤを含むＬＣＴパケット構造と類似しているが、ＴＳｆｏｒｍａｔフィールド、ＴＳｖｅｒｓｉｏｎフィールド及び／又はＴｉｍｅｓｔａｍｐフィールドをさらに含むことができる。同図でＬＣＴパケット構造の拡張部分以外の部分は省略されている。

ＴＳｆｏｒｍａｔフィールドは、当該ＬＣＴパケットのヘッダー拡張部分に含まれたｔｉｍｅｓｔａｍｐフィールドのフォーマットを示すことができる。例えば、このフィールドの値が０ｘ０１である場合、タイムスタンプはメディアタイム（ｍｅｄｉａｔｉｍｅ）フォーマットを有することができ、０ｘ０２である場合にはＮＴＰフォーマット、０ｘ０３である場合にはノーマルプレイングタイム（ｎｏｒｍａｌｐｌａｙｉｎｇｔｉｍｅ）フォーマット、０ｘ０４である場合にはＳＭＰＴＥタイムコードフォーマット、０ｘ０５である場合には９０ＫＨｚベースのタイムスタンプフォーマットを有することができる。このフィールドの値が０ｘ００又は０ｘ０６乃至０ｘ０Ｆである場合、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄｆｏｒｆｕｔｕｒｅｕｓｅ）。

ＴＳｖｅｒｓｉｏｎフィールドは、当該ＬＣＴパケットのヘッダー拡張部分に含まれたｔｉｍｅｓｔａｍｐフィールドの構成を示すことができる。例えば、このフィールドの値が０である場合、ｔｉｍｅｓｔａｍｐフィールドは３２ビット、１である場合、ｔｉｍｅｓｔａｍｐフィールドは６４ビットであってもよい。実施例によってｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙフィールドとｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙｔｉｍｅｓｃａｌｅフィールドも、このフィールドの値によって同じ方式で長さが定められてもよい。又は、実施例によって、別のフィールドを設けて、ｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙフィールドとｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙｔｉｍｅｓｃａｌｅフィールドの長さを表現してもよい。

ＳＰＤＴｆｌａｇフィールドは、前述したＳＰＤｓｃａｌｅフィールドと同一であってもよい。ただし、実施例によって、このフィールドの値が０に設定される場合、ｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙが存在しないように設定されてもよい。

Ｔｉｍｅｓｔａｍｐフィールドは、当該ＡＬＣ／ＬＣＴパケットのペイロードに含まれたデータに関連したタイミング情報を含むことができる。例えば、このフィールドの値は、ペイロードに含まれたデータの最初のバイトがデコードされる時点に関する情報を示すことができる。また、実施例によって、このフィールドの値は、当該データの再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅ）情報を示すことができる。このフィールドは、タイムスタンプの時間単位及び／又は当該時間単位ベースのタイミング情報などを共に含むことができる。又は、実施例によって、このフィールドは、送信側の現在時間、当該メディアデータのエンコーディング時間、当該メディアデータの最初のバイトがデコードされる時点などのタイミング情報にＳＰＤ（提案遅延時間）を加算した値を有することができる。

ＳｕｅｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙフィールドは、ＳＰＤ情報を含むことができる。このフィールドは、当該ＡＬＣ／ＬＣＴパケットのペイロードデータ又はペイロードデータを含むオブジェクトの生成時点を基準に消費時点までの提案遅延時間を示すことができる。前述したｔｉｍｅｓｔａｍｐフィールドのタイムスタンプ値を同期化に用いるとき、ＳＰＤ値を活用することができる。すなわち、タイムスタンプ値にＳＰＤ値を加算した値を反映して同期化を行うことによって、提案遅延時間の反映された同期化を取ることができる。

図１３９は、本発明の更に他の実施例に係るＳＰＤ（ｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。

本発明は、ＡＬＣ／ＬＣＴパケット構造のヘッダー拡張部分において、新しいヘッダー拡張構造であるＥＸＴ＿ＯＢＪ＿ＩＮＦＯを提案する。この新しいヘッダー拡張構造は、伝送オブジェクトのタイプ関連情報及び／又は当該伝送オブジェクトに関連したタイミング情報などを含むことができる。この新しいヘッダー拡張構造は、ＡＬＣ／ＬＣＴパケットヘッダーの拡張フィールド（ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎ）に含めることができ、コンテンツ伝送プロトコルパケットヘッダーの一部などとして用いることができる。

本実施例はＥＸＴ＿ＯＢＪ＿ＩＮＦＯの一実施例を示す。本実施例で、ＨＥＴフィールド、ＨＥＬフィールド、ＳＰＤフィールド（又はＳＰＤｆｌａｇフィールド）、ＳＤＰＴｆｌａｇフィールド、Ｔｉｍｅｓｔａｍｐフィールド、ＳｕｅｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙフィールド及び／又はＳｕｅｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙＴｉｍｅｓｃａｌｅフィールドは、前述したとおりである。

本実施例のＬＣＴパケット構造は、前述したＳＰＤを含むＬＣＴパケット構造と類似しているが、Ｏｂｊｅｃｔｔｙｐｅフィールド及び／又はＭフィールドがさらに含まれてもよい。同図で、ＬＣＴパケット構造の拡張部分以外の部分は省略されている。

ＯｂｊｅｃｔＴｙｐｅフィールドは、当該伝送オブジェクトのタイプを示すことができる。このフィールドが示す伝送オブジェクトのタイプは、ＲＴＰパケットヘッダーのペイロードタイプ値と類似の値を有することができる。実施例によって、このフィールドの値は、様々な伝送オブジェクトのタイプを示すことができる。例えば、このフィールドの値が０ｘ０１である場合、伝送オブジェクトのタイプは、普通のファイルフォーマット（ｒｅｇｕｌａｒｆｉｌｅ）、０ｘ０２の場合にはＨＴＴＰエンティティ（ｅｎｔｉｔｙ）フォーマット、０ｘ０３の場合にはＡＡＣベースのオーディオデータフォーマット、０ｘ０４の場合にはＨ．２６４ベースのビデオデータフォーマット、０ｘ０５の場合にはＨＥＶＣベースのビデオデータフォーマット、０ｘ０６の場合にはＤＡＳＨセグメント（Ｓｅｇｍｅｎｔ）又はＩＳＯベースメディアファイル（ＩＳＯｂａｓｅｍｅｄｉａｆｉｌｅ）フォーマット、０ｘ０７の場合にはメタデータフォーマットを有することができる。このフィールドの値が０ｘ００又は０ｘ０７以上の値の場合は、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄｆｏｒｆｕｔｕｒｅｕｓｅ）。

Ｍフィールドは、マーカー（ｍａｒｋｅｒ）の役割を担うフィールドであり、ＯｂｊｅｃｔＴｙｐｅフィールドの値によって様々な対象を示すことができる。例えば、ＯｂｊｅｃｔＴｙｐｅフィールドの示すオブジェクトタイプがファイルである場合、Ｍフィールドはそのファイルの始め又は終わりを示すことができる。また、ＯｂｊｅｃｔＴｙｐｅフィールドが示すオブジェクトタイプがビデオ／オーディオデータである場合、Ｍフィールドは、関連したデータユニットの始め又は終わりを示すことができる。Ｍフィールドは、マーカービット（ｍａｒｋｅｒｂｉｔ）フィールドと呼ぶこともできる。

本実施例で、Ｔｉｍｅｓｔａｍｐフィールド、ｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙフィールド及び／又はｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙｔｉｍｅｓｃａｌｅフィールドの長さは、３２、６４ビットなどであって、同じ固定長を有することができる。その長さは、別の長さフィールドで示してもよく、ＨＥＬフィールドで示してもよい。

図１４０は、本発明の更に他の実施例に係るＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。

本実施例は、前述したＥＸＴ＿ＯＢＪ＿ＩＮＦＯの他の構造を提案する。前述したＥＸＴ＿ＯＢＪ＿ＩＮＦＯの構造に比べて、ＴＳｆｌａｇフィールド、ＴＳｆｏｒｍａｔフィールド及び／又はＴＳｖｅｒｓｉｏｎフィールドがさらに含まれてもよい。同図で、ＬＣＴパケット構造の拡張部分以外の部分は省略されている。

ＴＳｆｌａｇフィールドは、当該ヘッダー拡張構造にｔｉｍｅｓｔａｍｐフィールドが存在するか否かを示すフラグであってもよい。実施例によって、このフィールドの値が１である場合、ｔｉｍｅｓｔａｍｐフィールドが存在し、０である場合には存在しなくてもよい。実施例によって、このフィールドの値が示す意味が異なってもよい。

ＴＳｆｏｒｍａｔフィールド、ＴＳｖｅｒｓｉｏｎフィールドは、前述したとおりである。ただし、これらのフィールドは、ＴＳｆｌａｇフィールドが１である場合、すなわち、ｔｉｍｅｓｔａｍｐフィールドが存在すると示される場合において、当該タイムスタンプのフォーマット及びバージョンを示すことができる。

その他の同名のフィールドは、前述したとおりである。

図１４１は、本発明の更に他の実施例に係るＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。

本実施例は、前述したＥＸＴ＿ＯＢＪ＿ＩＮＦＯの更に他の構造を提案する。前述したＥＸＴ＿ＯＢＪ＿ＩＮＦＯの構造に比べて、Ｅｘｔｆｌａｇフィールド及び／又はＥｘｔｅｎｔｉｏｎフィールドをさらに含むことができる。同図で、ＬＣＴパケット構造の拡張部分以外の部分は省略されている。

ＥｘｔＦｌａｇフィールドは、当該ヘッダー拡張構造にｅｘｔｅｎｓｉｏｎフィールドが存在するか否かを示すフラグであってもよい。実施例によって、このフィールドの値が１である場合、ｅｘｔｅｎｓｉｏｎフィールドが存在し、０である場合、存在しなくてもよい。実施例によって、このフィールドの値が示す意味が異なってもよい。

Ｅｘｔｅｎｓｉｏｎフィールドは、当該伝送オブジェクトに関連した付加情報を含むことができる。例えば、伝送オブジェクトのロケーション（ｌｏｃａｔｉｏｎ）情報などが含まれてもよい。ここで、伝送オブジェクトのロケーション情報とは、当該情報が得られる位置情報であり、例えば、ＤＡＳＨセグメントが伝送オブジェクトとして伝送される場合、伝送オブジェクトのロケーションはＤＡＳＨセグメントのＵＲＬであってもよい。このフィールドは、拡張の役割として、伝送オブジェクトと関連した様々な情報が実施例によって追加されてもよい。

その他の同名のフィールドは、前述したとおりである。

図１４２は、本発明の更に他の実施例に係るＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。

本発明は、ＡＬＣ／ＬＣＴパケット構造のヘッダー拡張部分において、新しいヘッダー拡張構造であるＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥを提案する。この新しいヘッダー拡張構造は、メディアデータのタイミング関連情報、タイムスタンプなどの情報を含むことができる。この新しいヘッダー拡張構造は、ＡＬＣ／ＬＣＴパケットヘッダーの拡張フィールド（ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎ）に含めることができ、コンテンツ伝送プロトコルパケットヘッダーの一部などとして用いることができる。

本実施例は、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥの一実施例を示す。ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥの場合、ＥＸＴ＿ＯＢＪ＿ＩＮＦＯと違い、ＯｂｊｅｃｔＴｙｐｅフィールド、Ｍフィールド、ＴＳｆｌａｇフィールドなどが省略されてもよい。同図で、ＬＣＴパケット構造の拡張部分以外の部分は省略されている。

ＴＳｆｏｒｍａｔフィールドは、前述したとおりである。ただし、この場合、このフィールドはその値によって、タイムスタンプがＧＰＳタイムフォーマットを有することを示すこともできる。

ＴＳｖｅｒｓｉｏｎフィールドは、前述したとおりである。ただし、この場合、このフィールドは、タイムスタンプの時間単位情報が存在するか否かをさらに示すこともできる。

ＥｘｔＦｌａｇｓフィールドは、ｅｘｔｅｎｓｉｏｎフィールドが含む細部フィールドに対するフラグフィールドの集合であってもよい。すなわち、このフィールドは、ｅｘｔｅｎｓｉｏｎフィールドの構成を示すことができる。又は、実施例によって、前述したＥｘｔｆｌａｇフィールドのように、ｅｘｔｅｎｔｉｏｎフィールドが存在するか否かを示すこともできる。Ｅｘｔｅｎｓｉｏｎフィールドは、このフィールドの値によってマップされたタイムライン関連情報などの様々な情報を含むことができる。

その他の同名のフィールドは、前述したとおりである。

図１４３は、本発明の更に他の実施例に係るＳＰＤ（ＳｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。

本発明は、ＡＬＣ／ＬＣＴパケット構造のヘッダー拡張部分において、新しいヘッダー拡張構造であるＥＸＴ＿ＴＩＭＥ＿ＭＡＰを提案する。この新しいヘッダー拡張構造は、ＡＬＣ／ＬＣＴパケットヘッダーの拡張フィールド（ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎ）に含めることができ、コンテンツ伝送プロトコルパケットヘッダーの一部などとして用いることができる。

ＥＸＴ＿ＴＩＭＥ＿ＭＡＰは、前述したタイムラインコンポーネントＡＵ又はタイムラインリファレンス情報ＡＵを含むメタデータを一つの伝送オブジェクトで伝達する役割を担うことができる。これは、伝送オブジェクトが他のタイムラインとの同期化を必要とする場合、両タイムライン間のマッピング情報を受信機に伝達するためであってもよい。ＥＸＴ＿ＴＩＭＥ＿ＭＡＰによれば、別の伝送オブジェクトが伝達される必要がなく、ヘッダーの拡張部分にこの構造を挿入して必要な情報を伝達することができる。伝達された情報を用いて、当該パケットのペイロードの再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅ）をＧＰＳタイムなどにマップすることができる。

ＥＸＴ＿ＴＩＭＥ＿ＭＡＰは、ＯＴＳｆｌａｇフィールド、ＯＴＳｆｏｒｍａｔフィールド、ＯＴＳｖｅｒｓｉｏｎフィールド、Ｌｏｃａｔｉｏｎｆｌａｇフィールド、Ｏｒｉｇｉｎａｌｔｉｍｅｓｔａｍｐフィールド、Ｌｏｃａｔｉｏｎフィールドなどをさらに含むことができる。

ＴＳｆｏｒｍａｔフィールドは前述したとおりであるが、実施例によって、このフィールドは、タイムスタンプがＧＰＳタイムフォーマットであることを示すこともできる。

ＯＴＳＦｌａｇフィールドは、当該パケットヘッダー拡張部分にｏｒｉｇｉｎａｌｔｉｍｅｓｔａｍｐフィールドが存在するか否かを示すフラグであってもよい。実施例によって、このフィールドの値が１である場合、ｏｒｉｇｉｎａｌｔｉｍｅｓｔａｍｐフィールドが存在し、０である場合、存在しなくてもよい。実施例によって、このフィールドの値の意味が異なってもよい。

ＯＴＳｆｏｒｍａｔフィールドは、ｏｒｉｇｉｎａｌｔｉｍｅｓｔａｍｐフィールドのフォーマットを示すことができる。実施例によって、このフィールドは様々なタイムスタンプフォーマットを示すことができる。例えば、このフィールドの値が０ｘ０１である場合、タイムスタンプはメディアタイム（ｍｅｄｉａｔｉｍｅ）フォーマットを有することができ、０ｘ０２の場合にはＮＴＰフォーマット、０ｘ０３の場合にはノーマルプレイングタイム（ｎｏｒｍａｌｐｌａｙｉｎｇｔｉｍｅ）フォーマット、０ｘ０４の場合にはＳＭＰＴＥタイムコードフォーマット、０ｘ０５の場合には９０ＫＨｚベースのタイムスタンプフォーマットを有することができる。このフィールドの値が０ｘ００又は０ｘ０６乃至０ｘ０Ｆである場合には、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄｆｏｒｆｕｔｕｒｅｕｓｅ）。

ＯＴＳｖｅｒｓｉｏｎフィールドは、含まれたｏｒｉｇｉｎａｌｔｉｍｅｓｔａｍｐフィールドのバージョン或いは構成を示すことができる。例えば、このフィールドの値が０である場合、ｏｒｉｇｉｎａｌｔｉｍｅｓｔａｍｐフィールドは３２ビット、１である場合、ｏｒｉｇｉｎａｌｔｉｍｅｓｔａｍｐは１６ビットのサイズを有することができる。

ＬｏｃａｔｉｏｎＦｌａｇフィールドは、当該パケットヘッダー拡張部分にｌｏｃａｔｉｏｎフィールドが存在するか否かを示すフラグであってもよい。実施例によって、このフィールドの値が１である場合、ｌｏｃａｔｉｏｎフィールドが存在し、０である場合には存在しなくてもよい。実施例によって、このフィールドの値の意味が異なってもよい。

Ｔｉｍｅｓｔａｍｐフィールドは、前述したとおりである。このフィールドは、ＯｒｉｇｉｎａｌＴｉｍｅｓｔａｍｐフィールドによって表現される伝送オブジェクトのタイムスタンプにマップされるタイムラインのタイムスタンプを含むことができる。このフィールドのタイムスタンプは、ｏｒｉｇｉｎａｌｔｉｍｅｓｔａｍｐフィールドによって表現されるタイムラインにマップすることができる。

ＯｒｉｇｉｎａｌＴｉｍｅｓｔａｍｐフィールドはｔｉｍｅｓｔａｍｐフィールドのタイムスタンプとマッピング関係を有する、伝送オブジェクトのタイムスタンプ情報を含むことができる。このフィールドのタイムスタンプは、ｔｉｍｅｓｔａｍｐフィールドによって表現されるタイムラインにマップすることができる。又は、実施例によって、このフィールドは、送信側の現在時間、当該メディアデータのエンコーディング時間、当該メディアデータの最初のバイトがデコードされる時点などのタイミング情報にＳＰＤ（提案遅延時間）を加算した値を有することができる。

Ｌｏｃａｔｉｏｎフィールドは、マップされるタイムラインに関連したデータのロケーション情報などを含むことができる。例えば、タイムスタンプが特定ＤＡＳＨセグメントのタイムラインにマップされる場合、ＤＡＳＨセグメントに対するＵＲＬ情報がこのフィールドに含まれてもよい。

その他の同名のフィールドは、前述したとおりである。

前述したＬＣＴパケットのヘッダー又はヘッダーの拡張部分の役割を担うために、ＲＯＵＴＥのプレゼンテーションタイムヘッダー（ＥＸＴ＿ＲＯＵＴＥ＿ＰＲＥＳＥＮＴＡＴＩＯＮ＿ＴＩＭＥ）が用いられてもよい。また、実施例によって、前述したＬＣＴパケットのヘッダー又はヘッダーの拡張部分の役割を担うために、ＩＥＴＦのＲＦＣ５６５１、“ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ（ＬＣＴ）ＢｕｉｌｄｉｎｇＢｌｏｃｋ”のＥＸＴ＿ＴＩＭＥヘッダーが用いられてもよい。

前述したＬＣＴパケットのヘッダー又はヘッダーの拡張部分は、ＥＸＴ＿ＲＯＵＴＥ＿ＰＲＥＳＥＮＴＡＴＩＯＮ＿ＴＩＭＥの一実施例であってもよい。また、実施例によって、前述したＬＣＴパケットのヘッダー又はヘッダーの拡張部分は、ＥＸＴ＿ＴＩＭＥヘッダーの一実施例であってもよい。前述したＬＣＴパケットのヘッダー又はヘッダーの拡張部分は、前述したように、タイミング関連情報を伝達することができる。

本発明の更に他の実施例に係るＬＣＴパケットヘッダーは、６４ビットＮＴＰタイムスタンプの３番目、４番目及び５番目のオクテットを表現することができる。この実施例のヘッダーは、ＨＥＴフィールドを有することができ、また、固定長を有することができる。この実施例のヘッダーの値は、ＳＣＴよりも大きくてもよい。この実施例のＬＣＴパケットヘッダーは、総４バイトのサイズを有することができる。

本発明の更に他の実施例に係るＬＣＴパケットヘッダーは、６４ビットＮＴＰタイムスタンプ値を全て有することもできる。この実施例のヘッダーは、ＨＥＴフィールド及び／又はＨＥＬフィールドを有することができる。この実施例のＬＣＴパケットヘッダーは、総１２バイトのサイズを有することができる。したがって、その他のビット数は、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄ）。

図１４４は、本発明の一実施例に係る放送コンテンツを送信する方法を示す図である。

本発明の一実施例に係る放送コンテンツを受信する方法は、放送コンテンツに対する第１メディアストリームを生成する段階、放送コンテンツに対する第２メディアストリームを生成する段階、第１メディアストリームを放送網を介して送信する段階、第２メディアストリームに対する要求を受ける段階、及び／又は第２メディアストリームをインターネット網を介して受信機に送信する段階を含むことができる。

まず、放送コンテンツに対する第１メディアストリームを生成することができる。この過程は、第１モジュールで行うことができる。ここで、第１メディアストリームは、放送網で伝送されるメディアストリームであってもよい。前述した実施例で、内部網で伝送されるメディアストリームが第１メディアストリームに該当してもよい。この第１メディアストリームは、複数個のパケットが連続した形態を有することができる。このうち、少なくとも一つのパケットは時間情報を含むことができる。ここで、時間情報とは、時間に関連した全情報を総称する統合的な概念である。実施例によって、前述したタイミング関連ＬＣＴパケットヘッダーの拡張部分、タイムラインリファレンス情報ＡＵ、タイムラインコンポーネントＡＵなどがこの時間情報に該当し得る。

前述した放送コンテンツに対する第２メディアストリームを生成することができる。この過程は、第２モジュールで行うことができる。ここで、第２メディアストリームは、インターネット網で伝送されるメディアストリームであってもよい。前述した実施例で、外部網で伝送されるメディアストリームが第２メディアストリームに該当してもよい。第１モジュールと第２モジュールとが統合されて一つのモジュールとして動作してもよい。

生成された第１メディアストリームは、放送網を介して受信側に伝送することができる。この過程は、第３モジュールで行うことができる。また、生成された第２メディアストリームは、インターネット網を介して受信側に伝送することができる。この過程は、第４モジュールで行うことができる。第４モジュールは、受信機から第２メディアストリームに対する要求を受け、その要求に応じて受信側に該当のメディアストリームを伝送することができる。このような要求は、前述したｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドによって行うことができる。

本発明の他の実施例に係る放送コンテンツを送信する方法は、前述した第１メディアストリームのパケットが前述した時間情報を含む拡張ヘッダーを含むことができる。この拡張ヘッダーは、前述したＬＣＴパケットヘッダーの拡張部分であってもよい。ここで、前述した時間情報は、第１メディアストリームの再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎｔｉｍｅ）を示すタイムスタンプ情報を含むことができる。このタイムスタンプ情報は、前述したｔｉｍｅｓｔａｍｐフィールドに該当し得る。

本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述した拡張ヘッダーがタイムスタンプの一部だけを含むことができる。前述したように、本発明の一実施例に係る拡張ヘッダーは、６４ビットＮＴＰタイムスタンプの３番目、４番目及び５番目のオクテットを表現することができる。前述した拡張ヘッダーがタイムスタンプの一部だけを含む場合、タイムスタンプの一部のオクテットだけを含むことができる。

本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述した拡張ヘッダーが第２メディアストリームの再生時刻を示すタイムスタンプ情報をさらに含むことができる。ここで、第２メディアストリームの再生時刻を示すタイムスタンプは、前述したｏｒｉｇｉｎａｌｔｉｍｅｓｔａｍｐフィールドによって表現されるタイムスタンプを意味することができる。すなわち、前述したように、拡張ヘッダーは、ｏｒｉｇｉｎａｌｔｉｍｅｓｔａｍｐフィールドをさらに含むことができる。

本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述した拡張ヘッダーが、第１メディアストリームの生成時点から消費時点までの提案遅延時間に関する情報をさらに含むことができる。ここで、提案遅延時間に関する情報は前述したＳＰＤを意味することができる。拡張ヘッダーは、ｓｕｇｇｅｓｔｅｄｐｒｅｓｅｎｔａｔｉｏｎｄｅｌａｙフィールドをさらに含むことができる。受信機は、このＳＰＤをタイムスタンプ値に加算して、ＳＰＤの反映された同期化を取ることができる。

本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述した第１メディアストリームの再生時刻を示すタイムスタンプが、ＳＰＤが既に反映されたタイムスタンプ値を有することができる。タイムスタンプフィールドは、タイムスタンプ値にＳＰＤ値を加算した値を含むことができる。したがって、ＳＰＤの反映された再生時刻を表現することができる。

本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述したパケットがタイムラインリファレンス情報を含んでもよい。リファレンス情報としては、第１メディアストリームのタイムラインを構成する第１タイムラインリファレンス情報及び／又は第２メディアストリームのタイムラインを構成する第２タイムラインリファレンス情報を含むことができる。それぞれのタイムラインリファレンス情報を、各メディアストリームのタイムラインを再構成するために用いることができる。それぞれのタイムラインリファレンスがマップされ、同期化したタイムラインを構成することができる。これを用いて、別個の網で伝送されるメディアストリームを同期化することができる。このようなペイロードを有するパケットは、一般パケットと同じ方式でパケット化されたタイムラインリファレンス情報ＡＵであってもよい。又は、実施例によってこれらのパケットはタイムラインコンポーネントＡＵであってもよい。

本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述したパケットのペイロードが提案遅延時間に関する情報をさらに含んでもよい。この提案遅延時間情報は、第１メディアストリーム及び／又は第２メディアストリームの生成時点から消費時点までの時間を示すことができる。この意味は、実施例によって異なってもよい。前述したように、タイムラインリファレンス値からＳＰＤ値を減算して、ＳＰＤ値の反映されたタイムラインを再構成することができる。

本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述したタイムラインリファレンス情報が、ＳＰＤ値が既に反映されたタイムラインリファレンス値を有することができる。

本発明の更に他の実施例に係る放送コンテンツを送信する方法で、前述した第１メディアストリームが、前述した放送コンテンツのビデオストリームであり、第２メディアストリームは、放送コンテンツのオーディオストリームであってもよい。

本発明の一実施例に係る放送コンテンツを受信する方法を説明する。本発明の一実施例に係る放送コンテンツを受信する方法は、図示を省略した。

本発明の一実施例に係る放送コンテンツを受信する方法は、放送網で第１メディアストリームを受け取る段階、ＵＲＬ情報を用いて要求することによってインターネット網で第２メディアストリームを受け取る段階、第１、第２メディアストリームに対するタイムラインを構成する段階、構成された各タイムラインをマップして、両メディアストリームのタイムラインの同期化を行う段階、及び／又はタイムスタンプ値に基づいて当該メディアデータを特定時刻に再生する段階を含むことができる。

第１メディアストリームを受け取る段階は、第１受信モジュールで行うことができる。ＵＲＬ情報を用いて要求することによってインターネット網で第２メディアストリームを受け取る段階は、第２受信モジュールで行うことができる。第１、第２メディアストリームに対するタイムラインを構成する段階は、第３受信モジュールで行うことができる。構成された各タイムラインをマップして２メディアストリームのタイムラインの同期化を行う段階は、第４受信モジュールで行うことができる。タイムスタンプ値に基づいて当該メディアデータを特定時刻に再生する段階は、第５受信モジュールで行うことができる。ここで、第３受信モジュールと第４受信モジュールとが統合され、一つのモジュールで行うこともできる。

各タイムラインは、メディアストリーム内のタイムラインリファレンス情報ＡＵのタイムラインリファレンス情報によって再構成することができる。このとき、各タイムラインをマップし、各メディアストリームを同期化させることができる。共に伝達されたＳＰＤ情報を用いて、ＳＰＤが反映されたタイムラインを再構成することができる。このとき、タイムラインリファレンス値からＳＰＤ値を減算して、ＳＰＤが反映されてもよい。

また、メディアストリームの各パケットヘッダーにはタイムスタンプ情報が含まれてもよい。このタイムスタンプ情報を用いて各メディアストリームの再生時刻を把握することもできる。共に伝達されたＳＰＤ情報を用いて、ＳＰＤが反映されたタイムスタンプ値を得ることができる。このとき、タイムスタンプ値にＳＰＤ値を加算して、ＳＰＤが反映された当該メディアデータの再生時刻を得ることができる。

前述した段階は、実施例によって省略されてもよく、類似／同一の動作を行う他の段階に代替されてもよい。

図１４５は、本発明の一実施例に係る放送コンテンツを送信する装置を示す図である。

本発明の一実施例に係る放送コンテンツを送信する装置は、第１モジュール、第２モジュール、第３モジュール及び／又は第４モジュールを含むことができる。

各モジュールは、前述した同名の各モジュールと同一であってもよい。第１モジュールはね放送コンテンツに対する第１メディアストリームを生成する段階を行うことができる。第２モジュールは、放送コンテンツに対する第２メディアストリームを生成する段階を行うことができる。第３モジュールは、第１メディアストリームを放送網で送信する段階を行うことができる。第４モジュールは、第２メディアストリームに対する要求を受ける段階、及び／又は２メディアストリームをインターネット網で受信機に送信する段階を行うことができる。

本発明の一実施例に係る放送コンテンツを受信する装置を説明する。この放送コンテンツを受信装置は、図示を省略した。

本発明の一実施例に係る放送コンテンツを受信する装置は、第１受信モジュール、第２受信モジュール、第３受信モジュール、第４受信モジュール及び／又は第５受信モジュールを含むことができる。各モジュールは、前述した同名の各モジュールと同一であってもよい。

前述したモジュールは、実施例によって省略されてもよく、類似／同一の動作を行う他のモジュールに代替されてもよい。

前述した第１モジュール、第２モジュール、第３モジュール、第４モジュール、第１受信モジュール、第２受信モジュール、第３受信モジュール、第４受信モジュール及び／又は第５受信モジュールは、メモリに記憶された連続した実行手順を実行するプロセッサであってもよい。また、前述した第１モジュール、第２モジュール、第３モジュール、第４モジュール、第１受信モジュール、第２受信モジュール、第３受信モジュール、第４受信モジュール及び／又は第５受信モジュールは、装置の内部／外部に設けられるハードウェアエレメントであってもよい。

モジュール又はユニットは、メモリ（又は記憶ユニット）に記憶された連続した実行手順を実行するプロセッサであってもよい。前述した実施例に記述された各段階は、ハードウェア／プロセッサで行うことができる。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明で提示する方法はコードとして実行されてもよい。このコードは、プロセッサで読み取り可能な記憶媒体に書き込むことができ、したがって、装置（ａｐｐａｒａｔｕｓ）が提供するプロセッサで読み取ることができる。

説明の便宜のために各図を区分して説明したが、各図に示した実施例を併合して新しい実施例を実現するように設計することも可能である。そして、通常の技術者の必要によって、以上説明した実施例を実行するためのプログラムが記録されているコンピュータで読み取り可能な記録媒体を設計することも、本発明の権利範囲に属する。

本発明に係る装置及び方法は、以上説明した実施例の構成及び方法が限定的に適用されるものではなく、上述した実施例の様々な変形が可能なように、各実施例の全部又は一部を選択的に組み合せて構成することもできる。

一方、本発明が提案する方法を、ネットワークデバイスに具備された、プロセッサで読み取り可能な記録媒体に、プロセッサで読み取り可能なコードとして具現することができる。プロセッサで読み取り可能な記録媒体は、プロセッサで読み取り可能なデータが記憶されるいずれの種類の記録装置をも含む。プロセッサで読み取り可能な記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサで読み取り可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散され、分散方式でプロセッサで読み取り可能なコードが記憶されて実行されてもよい。

また、以上では、本発明の好適な実施例について図示及び説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨から逸脱しない限度で、当該発明の属する技術の分野における通常の知識を有する者にとって様々な変形実施が可能であることは無論である。これらの変形実施も、本発明の技術的思想や展望から個別的に理解してはならない。

そして、本明細書では物の発明、方法の発明の両方が説明されており、必要によって、両発明の説明を補充的に適用してもよい。

本発明の思想や範囲から逸脱しさい範囲で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むことが意図される。

本明細書で装置及び方法発明が皆言及されて、装置及び方法発明皆の説明はお互い補完して適用されることができる。
〔実施例〕

様々な実施例が、本発明を実施するための形態で説明されている。

本発明は一連の放送信号提供分野で利用される。

Claims

放送コンテンツを送信する方法であって、
前記放送コンテンツの第１メディアストリームと第２メディアストリームを生成するステップであって、前記第１メディアストリームは前記放送コンテンツの第１メディアコンポーネントを伝達し、前記第２メディアストリームは前記放送コンテンツの第２メディアコンポーネントを伝達する、ステップと、
前記放送コンテンツのシグナリングデータストリームを生成するステップと、
前記第１メディアストリームと前記シグナリングデータストリームを、放送網を介して送信するステップと、
受信機から前記第２メディアストリームに対する要求を受信するステップと、
前記第２メディアストリームを、インターネット網を介して前記受信機に送信するステップと、
を含み、
前記第１メディアストリームの伝送パケットは、前記第１メディアコンポーネントの再生時刻を示すタイムスタンプを有する拡張ヘッダを含み、
前記シグナリングデータストリームの伝送パケットは、前記第１メディアコンポーネントのタイムラインを特定するために利用される第１タイムライン情報と、前記第２メディアコンポーネントのタイムラインを特定するために利用される第２タイムライン情報とを有するペイロードを含む、放送コンテンツ伝送方法。
前記第１メディアコンポーネントと前記第２メディアコンポーネントは、前記第１タイムライン情報と前記第２タイムライン情報に基づいた共通のタイムラインに時間整列される、請求項１に記載の放送コンテンツ伝送方法。
前記第１メディアコンポーネントと前記第２メディアコンポーネントは、前記第１タイムライン情報と前記第２タイムライン情報を前記共通のタイムラインにマッピングすることにより時間整列される、請求項２に記載の放送コンテンツ伝送方法。
前記第１メディアコンポーネントは、前記放送コンテンツのビデオコンポーネントであり、
前記第２メディアコンポーネントは、前記放送コンテンツのオーディオコンポーネントである、請求項１に記載の放送コンテンツ伝送方法。
放送コンテンツを送信する装置であって、
前記放送コンテンツの第１メディアストリームと第２メディアストリームを生成するハードウエアプロセッサであって、前記第１メディアストリームは前記放送コンテンツの第１メディアコンポーネントを伝達し、前記第２メディアストリームは前記放送コンテンツの第２メディアコンポーネントを伝達する、ハードウエアプロセッサと、
前記ハードウエアプロセッサは、前記放送コンテンツのシグナリングデータストリームを生成するようにさらに構成され、
前記第１メディアストリームと前記第２メディアストリームを、放送網を介して送信する放送送信機と、
受信機から前記第２メディアストリームに対する要求を受信し、前記第２メディアストリームを、インターネット網を介して前記受信機に送信するネットワークインターフェースと、
を含み、
前記第１メディアストリームの伝送パケットは、前記第１メディアコンポーネントの再生時刻を示すタイムスタンプを有する拡張ヘッダを含み、
前記シグナリングデータストリームの伝送パケットは、前記第１メディアコンポーネントのタイムラインを特定するために利用される第１タイムライン情報と、前記第２メディアコンポーネントのタイムラインを特定するために利用される第２タイムライン情報とを有するペイロードを含む、放送コンテンツ伝送装置。
前記第１メディアコンポーネントと前記第２メディアコンポーネントは、前記第１タイムライン情報と前記第２タイムライン情報に基づいた共通のタイムラインに時間整列される、請求項５に記載の放送コンテンツ伝送装置。
前記第１メディアコンポーネントと前記第２メディアコンポーネントは、前記第１タイムライン情報と前記第２タイムライン情報を前記共通のタイムラインにマッピングすることにより時間整列される、請求項６に記載の放送コンテンツ伝送装置。
前記第１メディアコンポーネントは、前記放送コンテンツのビデオコンポーネントであり、
前記第２メディアコンポーネントは、前記放送コンテンツのオーディオコンポーネントである、請求項５に記載の放送コンテンツ伝送装置。