(57)【特許請求の範囲】
【請求項１】
放送コンテンツを送信する方法であって、
前記放送コンテンツの第１メディアストリームと第２メディアストリームを生成するステップであって、前記第１メディアストリームは前記放送コンテンツの第１メディアコンポーネントを伝達し、前記第２メディアストリームは前記放送コンテンツの第２メディアコンポーネントを伝達する、ステップと、
前記放送コンテンツのシグナリングデータストリームを生成するステップと、
前記第１メディアストリームと前記シグナリングデータストリームを、放送網を介して送信するステップと、
受信機から前記第２メディアストリームに対する要求を受信するステップと、
前記第２メディアストリームを、インターネット網を介して前記受信機に送信するステップと、
を含み、
前記第１メディアストリームの伝送パケットは、前記第１メディアコンポーネントの再生時刻を示すタイムスタンプを有する拡張ヘッダを含み、
前記シグナリングデータストリームの伝送パケットは、前記第１メディアコンポーネントのタイムラインを特定するために利用される第１タイムライン情報と、前記第２メディアコンポーネントのタイムラインを特定するために利用される第２タイムライン情報とを有するペイロードを含む、放送コンテンツ伝送方法。
【請求項２】
前記第１メディアコンポーネントと前記第２メディアコンポーネントは、前記第１タイムライン情報と前記第２タイムライン情報に基づいた共通のタイムラインに時間整列される、請求項１に記載の放送コンテンツ伝送方法。
【請求項３】
前記第１メディアコンポーネントと前記第２メディアコンポーネントは、前記第１タイムライン情報と前記第２タイムライン情報を前記共通のタイムラインにマッピングすることにより時間整列される、請求項２に記載の放送コンテンツ伝送方法。
【請求項４】
前記第１メディアコンポーネントは、前記放送コンテンツのビデオコンポーネントであり、
前記第２メディアコンポーネントは、前記放送コンテンツのオーディオコンポーネントである、請求項１に記載の放送コンテンツ伝送方法。
【請求項５】
放送コンテンツを送信する装置であって、
前記放送コンテンツの第１メディアストリームと第２メディアストリームを生成するハードウエアプロセッサであって、前記第１メディアストリームは前記放送コンテンツの第１メディアコンポーネントを伝達し、前記第２メディアストリームは前記放送コンテンツの第２メディアコンポーネントを伝達する、ハードウエアプロセッサと、
前記ハードウエアプロセッサは、前記放送コンテンツのシグナリングデータストリームを生成するようにさらに構成され、
前記第１メディアストリームと前記第２メディアストリームを、放送網を介して送信する放送送信機と、
受信機から前記第２メディアストリームに対する要求を受信し、前記第２メディアストリームを、インターネット網を介して前記受信機に送信するネットワークインターフェースと、
を含み、
前記第１メディアストリームの伝送パケットは、前記第１メディアコンポーネントの再生時刻を示すタイムスタンプを有する拡張ヘッダを含み、
前記シグナリングデータストリームの伝送パケットは、前記第１メディアコンポーネントのタイムラインを特定するために利用される第１タイムライン情報と、前記第２メディアコンポーネントのタイムラインを特定するために利用される第２タイムライン情報とを有するペイロードを含む、放送コンテンツ伝送装置。
【請求項６】
前記第１メディアコンポーネントと前記第２メディアコンポーネントは、前記第１タイムライン情報と前記第２タイムライン情報に基づいた共通のタイムラインに時間整列される、請求項５に記載の放送コンテンツ伝送装置。
【請求項７】
前記第１メディアコンポーネントと前記第２メディアコンポーネントは、前記第１タイムライン情報と前記第２タイムライン情報を前記共通のタイムラインにマッピングすることにより時間整列される、請求項６に記載の放送コンテンツ伝送装置。
【請求項８】
前記第１メディアコンポーネントは、前記放送コンテンツのビデオコンポーネントであり、
前記第２メディアコンポーネントは、前記放送コンテンツのオーディオコンポーネントである、請求項５に記載の放送コンテンツ伝送装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送信号送信装置、放送信号受信装置、及び放送信号送受信方法に関する。
【背景技術】
【０００２】
アナログ放送信号送信が終了することにより、デジタル放送信号を送受信するための様々な技術が開発されている。デジタル放送信号は、アナログ放送信号に比べてより多量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータに加えて、種々の付加データも含むことができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
すなわち、デジタル放送システムは、ＨＤ（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ）イメージ、マルチチャネル（ｍｕｌｔｉ  ｃｈａｎｎｅｌ；多チャネル）オーディオ、及び様々な付加サービスを提供することができる。しかし、デジタル放送のためには、多量のデータ伝送に対するデータ伝送効率、送受信ネットワークの堅固性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装置を考慮したネットワーク柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を向上させなければならない。
【課題を解決するための手段】
【０００４】
目的及び他の利点を達成するために、本発明の目的によって、ここに含まれて概略的に記載されたように、放送信号送信方法は、第１モジュールが放送コンテンツに対する第１メディアストリームを生成するステップであって、第１メディアストリームは複数個のパケットを含み、少なくとも一つの前記パケットは時間情報を含む、ステップと、第２モジュールが前記放送コンテンツに対する第２メディアストリームを生成するステップと、第３モジュールが前記第１メディアストリームを放送網を介して送信するステップと、第４モジュールが受信機から前記第２メディアストリームに対する要求を受信するステップと、前記第４モジュールが前記第２メディアストリームをインターネット網を介して受信機に送信するステップと、を含む放送コンテンツ伝送方法であってもよい。
【０００５】
好適には、少なくとも一つのパケットは、前記時間情報を含む拡張ヘッダーを含み、前記時間情報は、前記第１メディアストリームの再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅ）を示すタイムスタンプ情報を含む放送コンテンツ伝送方法であってもよい。
【０００６】
好適には、拡張ヘッダーは、前記タイムスタンプの一部だけを含む放送コンテンツ伝送方法であってもよい。
【０００７】
好適には、拡張ヘッダーは、前記第２メディアストリームの再生時刻を示すタイムスタンプ情報をさらに含む放送コンテンツ伝送方法であってもよい。
【０００８】
好適には、拡張ヘッダーは、前記第１メディアストリームの生成時点から消費時点までの提案遅延時間に関する情報をさらに含む放送コンテンツ伝送方法であってもよい。
【０００９】
好適には、第１メディアストリームの再生時刻を示すタイムスタンプは、前記提案遅延時間が反映された第１メディアストリームの再生時刻値を示す放送コンテンツ伝送方法であってもよい。
【００１０】
好適には、少なくとも一つのパケットのペイロードは、前記第１メディアストリームのタイムラインを構成する第１タイムラインリファレンス情報、及び前記第２メディアストリームのタイムラインを構成する第２タイムラインリファレンス情報を含む放送コンテンツ伝送方法であってもよい。
【００１１】
好適には、少なくとも一つのパケットのペイロードは、前記第１メディアストリーム及び前記第２メディアストリームの生成時点から消費時点までの提案遅延時間に関する情報をさらに含む放送コンテンツ伝送方法であってもよい。
【００１２】
好適には、第１タイムラインリファレンス情報及び前記第２タイムラインリファレンス情報は、前記提案遅延時間が反映された値を有する放送信号コンテンツ方法であってもよい。
【００１３】
好適には、第１メディアストリームは、前記放送コンテンツのビデオストリームであり、前記第２メディアストリームは、前記放送コンテンツのオーディオストリームである、放送コンテンツ伝送方法であってもよい。
【００１４】
他の観点で、本発明は、放送信号送信装置を提案する。この放送信号送信装置は、放送コンテンツに対する第１メディアストリームを生成する第１モジュールであって、第１メディアストリームは複数個のパケットを含み、少なくとも一つの前記パケットは時間情報を含む、第１モジュールと、前記放送コンテンツに対する第２メディアストリームを生成する第２モジュールと、前記第１メディアストリームを放送網を介して送信する第３モジュールと、受信機から前記第２メディアストリームに対する要求を受信し、前記第２メディアストリームをインターネット網を介して受信機に送信する第４モジュールと、を含む放送コンテンツ伝送装置であってもよい。
【００１５】
好適には、少なくとも一つのパケットは、前記時間情報を含む拡張ヘッダーを含み、前記時間情報は、前記第１メディアストリームの再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅ）を示すタイムスタンプ情報を含む放送コンテンツ伝送装置であってもよい。
【００１６】
好適には、拡張ヘッダーは前記タイムスタンプの一部だけを含む放送コンテンツ伝送装置であってもよい。
【００１７】
好適には、拡張ヘッダーは前記第２メディアストリームの再生時刻を示すタイムスタンプ情報をさらに含む放送コンテンツ伝送装置であってもよい。
【００１８】
好適には、拡張ヘッダーは前記第１メディアストリームの生成時点から消費時点までの提案遅延時間に関する情報をさらに含む放送コンテンツ伝送装置であってもよい。
【００１９】
好適には、第１メディアストリームの再生時刻を示すタイムスタンプは、前記提案遅延時間が反映された第１メディアストリームの再生時刻値を示す、放送コンテンツ伝送装置であってもよい。
【００２０】
好適には、少なくとも一つのパケットのペイロードは、前記第１メディアストリームのタイムラインを構成する第１タイムラインリファレンス情報、及び前記第２メディアストリームのタイムラインを構成する第２タイムラインリファレンス情報を含む放送コンテンツ伝送装置であってもよい。
【００２１】
好適には、少なくとも一つのパケットのペイロードは、前記第１メディアストリーム及び前記第２メディアストリームの生成時点から消費時点までの提案遅延時間に関する情報をさらに含む放送コンテンツ伝送装置であってもよい。
【００２２】
好適には、第１タイムラインリファレンス情報及び前記第２タイムラインリファレンス情報は、前記提案遅延時間が反映された値を有する放送信号コンテンツ装置であってもよい。
【００２３】
好適には、第１メディアストリームは前記放送コンテンツのビデオストリームであり、前記第２メディアストリームは前記放送コンテンツのオーディオストリームである、放送コンテンツ伝送装置であってもよい。
【発明の効果】
【００２４】
本発明は、サービス特性によってデータを処理して各サービス又はサービスコンポーネントに対するＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を制御することによって様々な放送サービスを提供することができる。
【００２５】
本発明は、同じＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）信号帯域幅で様々な放送サービスを伝送することによって伝送柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を達成することができる。
【００２６】
本発明は、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ−Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ−Ｏｕｔｐｕｔ）システムを用いてデータ伝送効率及び放送信号の送受信堅固性（Ｒｏｂｕｓｔｎｅｓｓ）を向上させることができる。
【００２７】
本発明によれば、モバイル受信装置を使用していたり又は室内環境にいても、誤り無しでデジタル放送信号を受信できる放送信号送信及び受信方法並びに装置を提供することができる。
【図面の簡単な説明】
【００２８】
本発明の更なる理解を助けるために含まれ、且つ本出願に含まれてその一部を構成する添付の図面は、本発明の原理を説明する詳細な説明と共に本発明の実施例を示す。
【図１】本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す図である。
【図２】本発明の一実施例に係るインプットフォーマット（Ｉｎｐｕｔ  ｆｏｒｍａｔｔｉｎｇ；入力フォーマット）ブロックを示す図である。
【図３】本発明の他の実施例に係るインプットフォーマット（入力フォーマット）ブロックを示す図である。
【図４】本発明の一実施例に係るＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロックを示す図である。
【図５】本発明の他の実施例に係るＢＩＣＭブロックを示す図である。
【図６】本発明の一実施例に係るフレームビルディング（Ｆｒａｍｅ  Ｂｕｉｌｄｉｎｇ；フレーム生成）ブロックを示す図である。
【図７】本発明の一実施例に係るＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）ジェネレーション（ｇｅｎｅｒａｔｉｏｎ；生成）ブロックを示す図である。
【図８】本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す図である。
【図９】本発明の一実施例に係るフレーム構造を示す図である。
【図１０】本発明の一実施例に係るフレームのシグナリング階層構造を示す図である。
【図１１】本発明の一実施例に係るプリアンブルシグナリングデータを示す図である。
【図１２】本発明の一実施例に係るＰＬＳ１データを示す図である。
【図１３】本発明の一実施例に係るＰＬＳ２データを示す図である。
【図１４】本発明の他の実施例に係るＰＬＳ２データを示す図である。
【図１５】本発明の一実施例に係るフレームのロジカル（ｌｏｇｉｃａｌ；論理）構造を示す図である。
【図１６】本発明の一実施例に係るＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｌｉｎｇ）マッピングを示す図である。
【図１７】本発明の一実施例に係るＥＡＣ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｃｈａｎｎｅｌ）マッピングを示す図である。
【図１８】本発明の一実施例に係るＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ）マッピングを示す図である。
【図１９】本発明の一実施例に係るＦＥＣ（ｆｏｒｗａｒｄ  ｅｒｒｏｒ  ｃｏｒｒｅｃｔｉｏｎ）構造を示す図である。
【図２０】本発明の一実施例に係るタイムインターリービングを示す図である。
【図２１】本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す図である。
【図２２】本発明の他の実施例に係るツイストされた行−列ブロックインターリーバの動作を示す図である。
【図２３】本発明の一実施例に係るツイストされた行−列ブロックインターリーバの対角線方向読み取りパターンを示す図である。
【図２４】本発明の一実施例に係る各インターリービングアレイ（ａｒｒａｙ）からインターリービングされたＸＦＥＣＢＬＯＣＫを示す図である。
【図２５】ＦＬＵＴＥプロトコルを用いた場合のデータ処理時間を示す図である。
【図２６】本発明の一実施例に係るＲＯＵＴＥプロトコルスタックを示す図である。
【図２７】本発明の一実施例に係るファイルベースマルチメディアコンテンツのデータ構造を示す図である。
【図２８】本発明の一実施例に係るデータ構造を適用したＭＰＥＧ−ＤＡＳＨのメディアセグメント構成を示す図である。
【図２９】本発明の一実施例に係るＲＯＵＴＥプロトコルを用いたデータ処理時間を示す図である。
【図３０】本発明の一実施例に係るファイルを伝送するためのＬＣＴパケットの構造を示す図である。
【図３１】本発明の一実施例に係るファイルを伝送するためのＬＣＴパケットの構造を示す図である。
【図３２】本発明の一実施例に係るＦＤＴを用いた実時間放送支援情報シグナリングを示す図である。
【図３３】本発明の一実施例に係る放送信号送信装置を示す構成図である。
【図３４】本発明の一実施例に係る放送信号送信装置を示す構成図である。
【図３５】本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間生成及び送信手順を示すフローチャートである。
【図３６】本発明の一実施例に係る放送信号送信装置がパケタイザを用いてパケットを生成する手順を具体的に示すフローチャートである。
【図３７】本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間生成／送信手順を示すフローチャートである。
【図３８】本発明の一実施例に係るファイルベースマルチメディアコンテンツ受信機の構造を示す図である。
【図３９】本発明の一実施例に係るファイルベースマルチメディアコンテンツ受信機の構造を示す図である。
【図４０】本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間受信／消費手順を示す図である。
【図４１】本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間受信／消費手順を示す図である。
【図４２】本発明の他の実施例に係るオブジェクトタイプ情報を含むパケットの構造を示す図である。
【図４３】本発明の他の実施例に係るオブジェクトタイプ情報を含むパケットの構造を示す図である。
【図４４】本発明の他の実施例に係るオブジェクトタイプ情報を用いる放送信号受信装置の構造を示す図である。
【図４５】本発明の他の実施例に係るオブジェクトタイプ情報を用いる放送信号受信装置の構造を示す図である。
【図４６】本発明の他の実施例に係るタイプ情報を含むパケットの構造を示す図である。
【図４７】本発明の他の実施例に係る境界情報を含むパケットの構造を示す図である。
【図４８】本発明の他の実施例に係るマッピング情報を含むパケットの構造を示す図である。
【図４９】本発明の他の実施例に係るグルーピング情報を含むＬＣＴパケットの構造を示す図である。
【図５０】本発明の他の実施例に係るセッション及びオブジェクトのグルーピングを示す図である。
【図５１】本発明の他の実施例に係るパケット情報を用いた放送信号送信装置の構造を示す図である。
【図５２】本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。
【図５３】本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。
【図５４】本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。
【図５５】本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。
【図５６】本発明の他の実施例に係る優先順位情報を含むパケットの構造を示す図である。
【図５７】本発明の他の実施例に係る優先順位情報を含むパケットの構造を示す図である。
【図５８】本発明の他の実施例に係るオフセット情報を含むパケットの構造を示す図である。
【図５９】本発明の他の実施例に係るＲＡＰ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）情報を含むパケットの構造を示す図である。
【図６０】本発明の他の実施例に係るＲＡＰ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）情報を含むパケットの構造を示す図である。
【図６１】本発明の他の実施例に係る実時間（Ｒｅａｌ  Ｔｉｍｅ）情報を含むパケットの構造を示す図である。
【図６２】本発明の他の実施例に係る放送信号送信装置の構造を示す図である。
【図６３】本発明の他の実施例に係る放送信号受信装置の構造を示す図である。
【図６４】本発明の実施例に係る次世代放送システムのためのプロトコルスタックを示す図である。
【図６５】本発明の一実施例に係る、次世代放送システムの受信機を示す図である。
【図６６】本発明の一実施例に係る、放送網の伝送ストリームとインターネット網（異種網）の伝送ストリーム間の同期化のためのタイムラインコンポーネント（Ｔｉｍｅｌｉｎｅ  ｃｏｍｐｏｎｅｎｔ）を示す図である。
【図６７】本発明の一実施例に係るタイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。
【図６８】は、本発明の他の実施例に係る、タイムラインコンポーネントＡＵのシンタクスを示す図である。
【図６９】本発明の一実施例に係る、放送網伝送パケットのタイムスタンプがない場合に、タイムラインコンポーネントを用いた、放送網を介して伝送されるストリームと異種網（例えばインターネット網）を介して伝送されるストリーム間の同期化方法を示す図である。
【図７０】本発明の他の実施例に係るタイムラインコンポーネントＡＵのシンタクスを示す図である。
【図７１】本発明の他の実施例に係るタイムラインコンポーネントＡＵのシンタクスを示す図である。
【図７２】本発明の他の実施例に係るタイムラインコンポーネントＡＵのシンタクスを示す図である。
【図７３】本発明の他の実施例に係る、タイムラインリファレンスシグナリング情報を用いた、放送網を介して伝送されるストリームと異種網を介して伝送されるストリーム間の同期化方法を示す図である。
【図７４】本発明の他の実施例に係る、タイムラインリファレンス情報ＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。
【図７５】本発明の他の実施例に係る、タイムラインリファレンス情報ＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。
【図７６】本発明の他の実施例に係る、タイムラインリファレンス情報伝送を支援するＬＣＴパケットの構造を示す図である。
【図７７】本発明の他の実施例に係る、タイムラインリファレンス情報伝送を支援するＬＣＴパケットの構造を示す図である。
【図７８】本発明の一実施例に係る、ＤＡＳＨが適用される放送網の伝送ストリームと異種網（例えば、インターネット網）の伝送ストリーム間の、タイムラインコンポーネントＡＵを用いた同期化方法を示す図である。
【図７９】本発明の一実施例に係る、ＩＳＯ  ＢＭＦＦ（ＩＳＯ  ｂａｓｅ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔ）においてタイムラインコンポーネントを識別するためのサンプルエントリー（Ｓａｍｐｌｅ  Ｅｎｔｒｙ）を示す図である。
【図８０】本発明の一実施例に係る、ＩＳＯ  ＢＭＦＦにおいてタイムラインコンポーネントトラックと他のトラックとの依存関係を表現するためのトラックリファレンスタイプボックス（Ｔｒａｃｋ  Ｒｅｆｅｒｅｎｃｅ  Ｔｙｐｅ  Ｂｏｘ）を示す図である。
【図８１】本発明の一実施例に係る、次世代放送システムでサービス及び／又はコンテンツを取得する構造を示す図である。
【図８２】本発明の一実施例に係る、ＩＳＯ  ＢＭＦＦにおいてビデオデータ及び／又はオーディオデータに接近する方法を示す図である。
【図８３】本発明の他の実施例に係る、ＩＳＯ  ＢＭＦＦにおいてビデオデータ及び／又はオーディオデータに接近する方法を示す図である。
【図８４】本発明の一実施例による放送伝送フレームを示す図である。
【図８５】本発明の他の実施例による放送伝送フレームを示す図である。
【図８６】本発明の一実施例による放送サービスを伝送する伝送パケットの構造を示す図である。
【図８７】本発明の一実施例による放送サービスを伝送する伝送パケットが含むｎｅｔｗｏｒｋ＿ｐｒｏｔｏｃｏｌフィールドが有する値を示す図である。
【図８８】本発明の一実施例による放送サービスシグナリングテーブルと放送サービス伝送経路シグナリグ情報が放送サービスと放送サービス伝送経路をシグナリングすることを示す図である。
【図８９】本発明の一実施例による放送サービスシグナリングテーブルを示す図である。
【図９０】本発明の一実施例による放送サービスシグナリングテーブルが含むｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドが有する値を示す図である。
【図９１】本発明の他の実施例による放送サービスシグナリングテーブルを示す図である。
【図９２】本発明の一実施例によるストリーム識別子デスクリプタを示す図である。
【図９３】本発明の一実施例による放送伝送装置が放送パケットを伝送する動作を示す図である。
【図９４】本発明の一実施例による放送受信装置が放送パケットを受信する動作を示す図である。
【図９５】本発明の実施例によるパケットの構成を示す図である。
【図９６】本発明の実施例によるＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）パケットの構造を示す図である。
【図９７】本発明の一実施例によるＩＳＯ  ｂａｓｅ  ｍｅｄｉａ  ｆｏｒｍａｔ（以下、ＩＳＯ  ＢＭＦＦ）を基盤にするメディアファイルフォーマットを示す図である。
【図９８】本発明の一実施例によるパケットペイロードのペイロードヘッダの構成を示す図である。
【図９９】一つのパケットに一つのメディアがパケット化された伝送パケットのペイロード構成を示す図である。
【図１００】一つのパケットに一つのメディアがパケット化された伝送パケットのペイロード構成を示す図である。
【図１０１】一つのパケットに複数の相異なるメディアがパケット化された伝送パケットの構成を示す図である。
【図１０２】一つのパケットに複数の相異なるメディアがパケット化された伝送パケットの構成を示す図である。
【図１０３】一つのメディアデータが複数の伝送パケットに分けられてパケット化された伝送パケット（以下、フラグメンテッドパケット（Ｆｒａｇｍｅｎｔｅｄ  ｐａｃｋｅｔ））のペイロード構成を示す図である。
【図１０４】フラグメンテッドパケットのペイロード構成の他の実施例を示す図である。
【図１０５】本発明の一実施例において、放送伝送装置がＩＳＯ  ＢＭＦＦ基盤のメディアファイルをフラグメンテーションして複数個のパケットに分けることを示す図である。
【図１０６】図１０５の放送伝送装置がパケット化した第１フラグメンテーションユニットデータの具体的な実施例を示す図である。
【図１０７】図１０５のフラグメンテーションユニットデータのうち開始データを除く残りのデータを含むフラグメンテーションユニットの一実施例を示す図である。
【図１０８】図１０５のフラグメンテーションユニットデータのうち開始データを除く残りのデータを含むフラグメンテーションユニットの一実施例を示す図である。
【図１０９】図１０５のフラグメンテーションユニットデータのうち開始データを除く残りのデータを含むフラグメンテーションユニットの一実施例を示す図である。
【図１１０】本発明の一実施例によるメタデータのタイムラインシグナリングテーブルを示す図である。
【図１１１】伝送パケットのペイロードデータに一つのメタデータがパケット化されたペイロードデータの構成を示す図である。
【図１１２】伝送パケットのペイロードデータがタイムラインに対するメタデータを含む場合の実施例を示す図である。
【図１１３】一つの伝送パケットに多数のメタデータがパケット化された場合を示す図である。
【図１１４】一つの伝送パケットが多数個のタイムライン情報を含む場合を示す図である。
【図１１５】一つのメタデータを複数個の伝送パケットに分けてパケット化したパケットペイロードを示す図である。
【図１１６】メタデータフラグメントヘッダの他の実施例を示す図である。ここで、図１１５と同じ部分の説明は省略する。
【図１１７】本発明の一実施例による放送受信装置が放送パケットを受信する動作を示す図である。
【図１１８】放送網を介してＲＴＰプロトコールを利用してビデオストリームを伝送し、インターネット網を介してファイルフォーマット基盤のメディアデータを利用してビデオストリームを伝送する場合を示す図である。
【図１１９】本発明の一実施例による伝送パケットの構成を示す図である。
【図１２０】本発明の一実施例によるパケットヘッダの構成を示す図である。
【図１２１】時間情報を含む拡張されたヘッダの構成を示す図である。
【図１２２】時間情報を含む拡張されたヘッダの構成を示す図である。
【図１２３】本発明の一実施例による拡張されたヘッダの構成を示す図である。
【図１２４】本発明の一実施例による拡張されたヘッダの構成を示す図である。
【図１２５】本発明の一実施例による拡張されたヘッダの構成を示す図である。
【図１２６】本発明の一実施例による拡張されたヘッダの構成を示す図である。
【図１２７】本発明の一実施例による他のタイミング情報とのマッピングを支援するための拡張されたヘッダの構成を示す図である。
【図１２８】本発明の一実施例による放送伝送装置の動作方法を示す図である。
【図１２９】本発明の一実施例による放送受信装置の動作方法を示す図である。
【図１３０】伝送パケットの構成に対する情報を含むヘッダの構成を示す図である。
【図１３１】図１３０の伝送パケットの構成を示す図である。
【図１３２】本発明の一実施例による放送伝送装置の動作方法を示す図である。
【図１３３】本発明の一実施例による放送受信装置の動作方法を示す図である。
【図１３４】本発明の一実施例に係るＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を含むタイムラインリファレンス情報ＡＵ（ｔｉｍｅｌｉｎｅ  ｒｅｆｅｒｅｎｃｅ  ｉｎｆｏｒｍａｔｉｏｎ  ＡＵ）を示す図である。
【図１３５】本発明の他の実施例に係るＳＰＤを含むタイムラインリファレンス情報ＡＵ（ｔｉｍｅｌｉｎｅ  ｒｅｆｅｒｅｎｃｅ  ｉｎｆｏｒｍａｔｉｏｎ  ＡＵ）を示す図である。
【図１３６】本発明の一実施例に係るＳＰＤを含むＬＣＴパケット構造を示す図である。
【図１３７】本発明の他の実施例に係るＳＰＤを含むＬＣＴパケット構造を示す図である。
【図１３８】本発明の更に他の実施例に係るＳＰＤを含むＬＣＴパケット構造の拡張部分を示す図である。
【図１３９】本発明の更に他の実施例に係るＳＰＤを含むＬＣＴパケット構造の拡張部分を示す図である。
【図１４０】本発明の更に他の実施例に係るＳＰＤを含むＬＣＴパケット構造の拡張部分を示す図である。
【図１４１】本発明の更に他の実施例に係るＳＰＤを含むＬＣＴパケット構造の拡張部分を示す図である。
【図１４２】本発明の更に他の実施例に係るＳＰＤを含むＬＣＴパケット構造の拡張部分を示す図である。
【図１４３】本発明の更に他の実施例に係るＳＰＤを含むＬＣＴパケット構造の拡張部分を示す図である。
【図１４４】本発明の一実施例に係る放送コンテンツを送信する方法を示す図である。
【図１４５】本発明の一実施例に係る放送コンテンツを送信する装置を示す図である。
【発明を実施するための形態】
【００２９】
本発明の好適な実施例について具体的に説明し、その例を添付の図面に図示する。添付の図面を参照している下記の詳細な説明は、本発明の実施例によって具現可能な実施例を限定するものではなく、本発明の好適な実施例を説明するためのものである。下記の詳細な説明は、本発明に関する徹底した理解を提供するために細部事項を含む。ただし、当業者にとってこのような細部事項無しにも本発明を実行できるということは明らかである。
【００３０】
本発明では、当該分野で広く使われている一般的な用語を選択するが、一部の用語は出願人によって任意に選択されてもよく、その意味は必要時に、該当する部分で詳しく説明するものとする。したがって、本発明は、用語の単純な名称又は意味ではなく、意図する用語の意味に基づいて理解されなければならない。
【００３１】
本発明は、次世代放送サービスに対する放送信号送信及び受信装置並びに方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）又はＭＩＭＯ方式を用いて次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式などを含むことができる。
【００３２】
以下では、説明の便宜のために、ＭＩＳＯ又はＭＩＭＯ方式が２つのアンテナを用いるとするが、本発明は、２つ以上のアンテナを用いるシステムに適用されてもよい。本発明は、特定の用途に要求される性能を達成しながら、受信機の複雑度を最小化するために、最適化された３つのフィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）（ベース（ｂａｓｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）、アドバンスド（ａｄｖａｎｃｅｄ）プロファイル）を定義することができる。フィジカルプロファイルは、該当する受信機が具現しなければならない全ての構造のサブセットである。
【００３３】
３つのフィジカルプロファイルは、大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータではやや異なる。後でフィジカルプロファイルがさらに定義されてもよい。システムの発展のために、ヒューチャプロファイルは、ＦＥＦ（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ  ｆｒａｍｅ）を通じて単一ＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）チャネルに存在するプロファイルとマルチプレクスされてもよい。各フィジカルプロファイルに関する詳細な内容は後述する。
【００３４】
１．ベースプロファイル
ベースプロファイルは主にループトップ（ｒｏｏｆ−ｔｏｐ）アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルはある場所に移動してもよいが、比較的停止した受信範ちゅうに属する携帯用装置も含むことができる。ベースプロファイルの用途は、若干の改善された実行によってハンドヘルド装置又は車両用に拡張されてもよいが、このような使用用途はベースプロファイル受信機動作では期待されない。
【００３５】
受信のターゲット信号対雑音比の範囲は略１０乃至２０ｄＢであるが、これは、既存放送システム（例えば、ＡＴＳＣ  Ａ／５３）の１５ｄＢ信号対雑音比の受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを使用する、バッテリーで駆動するハンドヘルド装置におけるよりは重要でない。ベースプロファイルに対する重要システムパラメータが、下記の表１に記載されている。
【００３６】
【表１】
0006325122.tif 000002
【００３７】
２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリー電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。当該装置は歩行者又は車両の速度で移動することができる。受信機複雑度も消費電力も、共にハンドヘルドプロファイルの装置の具現のために非常に重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は、略０乃至１０ｄＢであるが、より低い室内受信のために意図された場合、０ｄＢ未満となるように設定されてもよい。
【００３８】
低い信号対雑音比能力だけでなく、受信機移動性によって現れたドップラー効果に対する復原力は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要システムパラメータが下記の表２に記載されている。
【００３９】
【表２】
0006325122.tif 000003
【００４０】
３．アドバンスドプロファイル
アドバンスドプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。当該プロファイルはＭＩＭＯ送信及び受信を用いることを要求し、ＵＨＤＴＶサービスはターゲット用途であり、そのために、当該プロファイルが特別に設計される。向上した能力は、与えられた帯域幅でサービス数の増加、例えば、複数のＳＤＴＶ又はＨＤＴＶサービスを許容するために用いることができる。
【００４１】
アドバンスドプロファイルのターゲット信号対雑音比の範囲は、略２０乃至３０ｄＢである。ＭＩＭＯ伝送は、初期には既存の楕円分極伝送装備を使用し、将来には全出力交差分極伝送へと拡張されてもよい。アドバンスドプロファイルに対する重要システムパラメータが下記の表３に記載されている。
【００４２】
【表３】
0006325122.tif 000004
【００４３】
この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方に対するプロファイルとして用いられてもよい。すなわち、ベースプロファイルを、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルに対するアドバンスドプロファイルとＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスドプロファイルとに区別することができる。そして、該当の３つのプロファイルは設計者の意図によって変更されてもよい。
【００４４】
次の用語及び定義を本発明に適用することができる。次の用語及び定義は、設計によって変更されてもよい。
【００４５】
補助ストリーム：ヒューチャエクステンション（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ、将来拡張）又は放送会社やネットワーク運営者によって要求されることによって用いられ得る、まだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス
【００４６】
ベースデータパイプ（ｂａｓｅ  ｄａｔａ  ｐｉｐｅ）：サービスシグナリングデータを伝達するデータパイプ
【００４７】
ベースバンドフレーム（又は、ＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合
【００４８】
セル（ｃｅｌｌ）：ＯＦＤＭ伝送の一つのキャリアによって伝達される変調値
【００４９】
コーディングブロック（ｃｏｄｅｄ  ｂｌｏｃｋ）：ＰＬＳ１データのＬＤＰＣエンコードされたブロック又はＰＬＳ２データのＬＤＰＣエンコードされたブロックの一つ
【００５０】
データパイプ（ｄａｔａ  ｐｉｐｅ）：１つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連したメタデータを伝達する物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）におけるロジカルチャネル
【００５１】
データパイプユニット（ＤＰＵ，ｄａｔａ  ｐｉｐｅ  ｕｎｉｔ）：データセルをフレームにおけるデータパイプに割り当て得る基本ユニット
【００５２】
データシンボル（ｄａｔａ  ｓｙｍｂｏｌ）：プリアンブルシンボル以外のフレームにおけるＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（ｅｄｇｅ）シンボルはデータシンボルに含まれる。）
【００５３】
ＤＰ＿ＩＤ：当該８ビットフィールドは、ＳＹＳＴＥＭ＿ＩＤによって識別されたシステム内でデータパイプを唯一に識別する。
【００５４】
ダミーセル（ｄｕｍｍｙ  ｃｅｌｌ）：ＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｌｉｎｇ）シグナリング、データパイプ、又は補助ストリームのために用いられないで残っている容量を満たすために用いられる擬似ランダム値を伝達するセル
【００５５】
ＦＡＣ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｃｈａｎｎｅｌ、非常警報チャネル）：ＥＡＳ情報データを伝達するフレームの一部
【００５６】
フレーム（ｆｒａｍｅ）：プリアンブルによって始まってフレームエッジシンボルによって終了される物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）タイムスロット
【００５７】
フレームレピティションユニット（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ；フレーム反復単位）：スーパーフレーム（ｓｕｐｅｒ−ｆｒａｍｅ）で８回反復されるＦＥＦを含む同一又は別個のフィジカルプロファイルに属するフレームの集合
【００５８】
ＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ；高速情報チャネル）：サービスと該当のベースデータパイプとのマッピング情報を伝達するフレームにおいてロジカルチャネル
【００５９】
ＦＥＣＢＬＯＣＫ：データパイプデータのＬＤＰＣエンコードされたビットの集合
【００６０】
ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同一である特定モードに用いられる名目上のＦＦＴサイズ
【００６１】
フレームシグナリングシンボル（ｆｒａｍｅ  ｓｉｇｎａｌｉｎｇ  ｓｙｍｂｏｌ）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、ガードインターバル（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）、及びスキャッタ（ｓｃａｔｔｅｒｅｄ）パイロットパターンの特定組合せにおいてフレームの開始で用いられるより高いパイロット密度を有するＯＦＤＭシンボル
【００６２】
フレームエッジシンボル（ｆｒａｍｅ  ｅｄｇｅ  ｓｙｍｂｏｌ）：ＦＦＴサイズ、ガードインターバル、及びスキャッタパイロットパターンの特定組合せにおいてフレームの終わりで用いられるより高いパイロット密度を有するＯＦＤＭシンボル
【００６３】
フレームグループ（ｆｒａｍｅ−ｇｒｏｕｐ）：スーパーフレームで同じフィジカルプロファイルタイプを有する全フレームの集合
【００６４】
ヒューチャエクステンションフレーム（ｆｕｔｕｒｅ  ｅｘｔｅｎｔｉｏｎ  ｆｒａｍｅ；将来拡張フレーム）：プリアンブルによって始まる、将来拡張に用いられ得るスーパーフレームにおける物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）タイムスロット
【００６５】
ヒューチャキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳ、ＩＰ（Ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ）、又は一般ストリームであり、出力がＲＦシグナルである、提案された物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）放送システム
【００６６】
インプットストリーム（ｉｎｐｕｔ  ｓｔｒｅａｍ；入力ストリーム）：システムによって最終ユーザに伝達されるサービスの調和（ｅｎｓｅｍｂｌｅ）のためのデータのストリーム
【００６７】
ノーマル（ｎｏｒｍａｌ）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボル以外のデータシンボル
【００６８】
フィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）：該当する受信機が具現すべき全ての構造のサブセット
【００６９】
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理層シグナリングデータ
【００７０】
ＰＬＳ１：ＰＬＳ２をデコードするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（ｆｒａｍｅ  ｓｉｇｎａｌｌｉｎｇ  ｓｙｍｂｏｌ）で伝達されるＰＬＳデータの一番目の集合
【００７１】
ＮＯＴＥ：ＰＬＳ１データがフレームグループのデューレーション（ｄｕｒａｔｉｏｎ）において一定である。
【００７２】
ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合
【００７３】
ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ；動的）データ：フレームごとにダイナミック（動的）に変化するＰＬＳ２データ
【００７４】
ＰＬＳ２スタティック（ｓｔａｔｉｃ；静的）データ：フレームグループのデューレーションでスタティック（静的）であるＰＬＳ２データ
【００７５】
プリアンブルシグナリングデータ（ｐｒｅａｍｂｌｅ  ｓｉｇｎａｌｉｎｇ  ｄａｔａ）：プリアンブルシンボルによって伝達され、システムの基本モードを確認するために用いられるシグナリングデータ
【００７６】
プリアンブルシンボル（ｐｒｅａｍｂｌｅ  ｓｙｍｂｏｌ）：基本ＰＬＳデータを伝達し、フレームの先頭に位置する固定された長さのパイロットシンボル
【００７７】
ＮＯＴＥ：プリアンブルシンボルがシステム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に用いられる。
【００７８】
将来使用（ｆｕｔｕｒｅ  ｕｓｅ）のためにリザーブド（ｒｅｓｅｒｖｅｄ）：現在文書で定義されないが、将来に定義されてもよい。
【００７９】
スーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）：８個のフレーム反復単位の集合
【００８０】
タイムインターリービングブロック（ｔｉｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ  ｂｌｏｃｋ；ＴＩ  ｂｌｏｃｋ）：タイムインターリーバメモリの一つの用途に該当する、タイムインターリービングが実行されるセルの集合
【００８１】
タイムインターリービンググループ（ｔｉｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ  ｇｒｏｕｐ；ＴＩ  ｇｒｏｕｐ）：整数、ダイナミック（動的）に変化するＸＦＥＣＢＬＯＣＫの数からなる、特定データパイプに対するダイナミック（動的）容量割り当てが実行される単位
【００８２】
ＮＯＴＥ：タイムインターリービンググループが一つのフレームに直接マップされたり、複数のフレームにマップされてもよい。タイムインターリービンググループは一つ以上のタイムインターリービングブロックを含むことができる。
【００８３】
タイプ１データパイプ（Ｔｙｐｅ１ＤＰ）：全データパイプがフレームにＴＤＭ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）方式でマップされるフレームのデータパイプ
【００８４】
タイプ２データパイプ（Ｔｙｐｅ２ＤＰ）：全データパイプがフレームにＦＤＭ方式でマップされるフレームのデータパイプ
【００８５】
ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣ  ＦＥＣＢＬＯＣＫの全ビットを伝達するＮｃｅｌｌｓセルの集合
【００８６】
図１は、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
【００８７】
本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック（Ｉｎｐｕｔ  Ｆｏｒｍａｔ  ｂｌｏｃｋ）１０００、ＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレームビルディングブロック（Ｆｒａｍｅ  ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）ジェネレーションブロック（ＯＦＤＭ  ｇｅｎｅｒａｔｉｏｎ  ｂｌｏｃｋ）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
【００８８】
ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳは、主要入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。それらのデータ入力に加えて、管理情報が入力され、各入力ストリームに対する該当の帯域幅のスケジューリング及び割り当てを制御する。１つ又は複数のＴＳストリーム、ＩＰストリーム及び／又は一般ストリーム入力が同時に許容される。
【００８９】
インプットフォーマットブロック１０００は、それぞれの入力ストリームを、独立したコーディング及び変調が適用される１つ又は複数のデータパイプにデマルチプレクスすることができる。データパイプは、堅固性（ｒｏｂｕｓｔｎｅｓｓ）制御のための基本単位であり、これはＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）に影響を及ぼす。１つ又は複数のサービス又はサービスコンポーネントが一つのデータパイプによって伝達されてもよい。インプットフォーマットブロック１０００の詳細な動作は後述する。
【００９０】
データパイプは、１つ又は複数のサービス又はサービスコンポーネントを伝達できるサービスデータ又は関連メタデータを伝達する物理層におけるロジカルチャネルである。
【００９１】
また、データパイプユニットは、一つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
【００９２】
インプットフォーマットブロック１０００で、パリティ（ｐａｒｉｔｙ）データは誤り訂正のために追加され、エンコードされたビットストリームは複素数値コンステレーションシンボルにマップされる。当該シンボルは該当のデータパイプに用いられる特定インターリービング深さにわたってインターリーブされる。アドバンスドプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ伝送のために出力に追加される。ＢＩＣＭブロック１０１０の詳細な動作は後述する。
【００９３】
フレームビルディングブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマップすることができる。マッピング後、周波数領域ダイバーシチのために、特に、周波数選択的フェージングチャネルを防止するために周波数インターリービングが用いられる。フレームビルディングブロック１０２０の詳細な動作は後述する。
【００９４】
プリアンブルを各フレームの先頭に挿入した後、ＯＦＤＭジェネレーションブロック１０３０は、サイクリックプレフィクス（ｃｙｃｌｉｃ  ｐｒｅｆｉｘ）をガードインターバルとして有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシチのために、分散された（ｄｉｓｔｒｉｂｕｔｅｄ）ＭＩＳＯ方式が送信機にわたって適用される。また、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ  ｐｏｗｅｒ  ｒａｔｉｏ）方式が時間領域で実行される。柔軟なネットワーク方式のために、当該提案は様々なＦＦＴサイズ、ガードインターバルの長さ、該当のパイロットパターンの集合を提供する。ＯＦＤＭジェネレーションブロック１０３０の詳細な動作は後述する。
【００９５】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層シグナリング情報を生成することができる。当該シグナリング情報はまた、関心のあるサービスが受信機側で適切に復旧されるように送信される。シグナリング生成ブロック１０４０の詳細な動作は後述する。
【００９６】
図２、図３、図４は、本発明の実施例に係るインプットフォーマットブロック１０００を示す。各図について説明する。
【００９７】
図２は、本発明の一実施例に係るインプットフォーマットブロックを示す。図２は、入力信号が単一入力ストリーム（ｓｉｎｇｌｅ  ｉｎｐｕｔ  ｓｔｒｅａｍ）であるときのインプットフォーマットブロックを示す。
【００９８】
図２に示すインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施例に該当する。
【００９９】
物理層への入力は、１つ又は複数のデータストリームで構成される。それぞれのデータストリームは一つのデータパイプによって伝達される。モードアダプテーション（ｍｏｄｅ  ａｄａｐｔａｉｏｎ；モード適応）モジュールは、入力されるデータストリームをＢＢＦ（ｂａｓｅｂａｎｄ  ｆｒａｍｅ）のデータフィールドにスライスする。当該システムは３種類の入力データストリーム、すなわち、ＭＰＥＧ２−ＴＳ、ＩＰ、ＧＳ（ｇｅｎｅｒｉｃ  ｓｔｒｅａｍ）を支援する。ＭＰＥＧ２−ＴＳは、最初のバイトが同期バイト（０ｘ４７）である固定された長さ（１８８バイト）のパケットを特徴とする。ＩＰストリームは、ＩＰパケットヘッダー内でシグナルされる可変長ＩＰデータグラムパケットで構成される。当該システムは、ＩＰストリームに対してＩＰｖ４、ＩＰｖ６の両方を支援する。ＧＳは、カプセル化パケットヘッダー内でシグナルされる可変長のパケット又は一定の長さのパケットで構成されてもよい。
【０１００】
（ａ）は、信号データパイプに対するモードアダプテーション（モード適応）ブロック２０００、及びストリームアダプテーション（ｓｔｒｅａｍ  ａｄａｐｔａｔｉｏｎ；ストリーム適応）２０１０を示し、（ｂ）は、ＰＬＳデータを生成及び処理するためのＰＬＳ生成ブロック２０２０、及びＰＬＳスクランブラ２０３０を示す。各ブロックの動作について説明する。
【０１０１】
入力ストリームスプリッタは、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。モードアダプテーション（モード適応）モジュール２０１０は、ＣＲＣエンコーダ、ＢＢ（ｂａｓｅｂａｎｄ）フレームスライサ、及びＢＢフレームヘッダー挿入ブロックで構成される。
【０１０２】
ＣＲＣエンコーダは、ユーザパケット（ｕｓｅｒ  ｐａｃｋｅｔ；ＵＰ）レベルでの誤り検出のための３種類のＣＲＣエンコーディング、すなわち、ＣＲＣ−８、ＣＲＣ−１６、ＣＲＣ−３２を提供する。算出されたＣＲＣバイトは、ＵＰ後に付加される。ＣＲＣ−８はＴＳストリームに用いられ、ＣＲＣ−３２はＩＰストリームに用いられる。ＧＳストリームがＣＲＣエンコーディングを提供しない場合には、提案されたＣＲＣエンコーディングが適用されなければならない。
【０１０３】
ＢＢフレームスライサは、入力を内部ロジカルビットフォーマットにマップする。最初の受信ビットはＭＳＢと定義する。ＢＢフレームスライサは、可用データフィールド容量と同数の入力ビットを割り当てる。ＢＢＦペイロードと同数の入力ビットを割り当てるために、ＵＰストリームがＢＢＦのデータフィールドに見合うようにスライスされる。
【０１０４】
ＢＢフレームヘッダー挿入ブロックは、２バイトの固定された長さのＢＢＦヘッダーを、ＢＢフレームの前に挿入することができる。ＢＢＦヘッダーは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）、及びＲＦＵ（２ビット）で構成される。固定された２バイトＢＢＦヘッダーだけでなく、ＢＢＦは、２バイトＢＢＦヘッダーの終わりに拡張フィールド（１又は３バイト）を有することができる。
【０１０５】
ストリームアダプテーション（ストリーム適応）２０１０は、スタッフィング（ｓｔｕｆｆｉｎｇ）挿入ブロック及びＢＢスクランブラで構成される。スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリームアダプテーション（ストリーム適応）に対する入力データがＢＢフレームを満たすのに十分であれば、ＳＴＵＦＦＩは０に設定され、ＢＢＦはスタッフィングフィールドを有しない。そうでないと、ＳＴＵＦＦＩは１に設定され、スタッフィングフィールドはＢＢＦヘッダーの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダー及び可変サイズのスタッフィングデータを含む。
【０１０６】
ＢＢスクランブラは、エネルギー分散のために完全なＢＢＦをスクランブルする。スクランブリングシーケンスはＢＢＦと同期化される。スクランブリングシーケンスはフィードバックシフトレジスターによって生成される。
【０１０７】
ＰＬＳ生成ブロック２０２０は、ＰＬＳデータを生成することができる。ＰＬＳは、受信機でフィジカルレイヤ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）データパイプに接続できる手段を提供する。ＰＬＳデータはＰＬＳ１データ及びＰＬＳ２データで構成される。
【０１０８】
ＰＬＳ１データは、ＰＬＳ２データをデコードするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームでＦＳＳで伝達されるＰＬＳデータの一番目の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするために要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグループのデューレーションにおいて一定である。
【０１０９】
ＰＬＳ２データは、データパイプ及びシステムに関するさらに詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコードする上で十分な情報を提供するパラメータを含む。ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（静的）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２ダイナミック（動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータでさらに構成される。ＰＬＳ２スタティック（静的）データは、フレームグループのデューレーションでスタティック（静的）であるＰＬＳ２データであり、ＰＬＳ２ダイナミック（動的）データは、フレームごとにダイナミック（動的）に変化するＰＬＳ２データである。
【０１１０】
ＰＬＳデータに関する詳細な内容は後述する。
【０１１１】
ＰＬＳスクランブラ２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブルすることができる。
【０１１２】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１１３】
図３は、本発明の他の実施例に係るインプットフォーマットブロックを示す。
【０１１４】
図３に示すインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施例に該当する。
【０１１５】
図３は、入力信号がマルチインプットストリーム（ｍｕｌｔｉ  ｉｎｐｕｔ  ｓｔｒｅａｍ；複数の入力ストリーム）に該当する場合、インプットフォーマットブロックのモードアダプテーション（モード適応）ブロックを示す。
【０１１６】
マルチインプットストリーム（複数の入力ストリーム）を処理するためのインプットフォーマットブロックのモードアダプテーション（モード適応）ブロックは、複数の入力ストリームを独立して処理することができる。
【０１１７】
図３を参照すると、マルチインプットストリーム（複数の入力ストリーム）をそれぞれ処理するためのモードアダプテーション（モード適応）ブロックは、インプットストリームスプリッタ（ｉｎｐｕｔ  ｓｔｒｅａｍ  ｓｐｌｉｔｔｅｒ）３０００、インプットストリームシンクロナイザ（ｉｎｐｕｔ  ｓｔｒｅａｍ  ｓｙｎｃｈｒｏｎｉｚｅｒ）３０１０、コンペンセーティングディレイ（ｃｏｍｐｅｎｓａｔｉｎｇ  ｄｅｌａｙ；補償遅延）ブロック３０２０、ヌルパケット削除ブロック（ｎｕｌｌ  ｐａｃｋｅｔ  ｄｅｌｅｔｉｏｎ  ｂｌｏｃｋ）３０３０、ヘッダーコンプレションブロック（ｈｅａｄｅｒ  ｃｏｍｐｒｅｓｓｉｏｎ  ｂｌｏｃｋ）３０４０、ＣＲＣエンコーダ（ＣＲＣ  ｅｎｃｏｄｅｒ）３０５０、ＢＢフレームスライサ（ＢＢ  ｆｒａｍｅ  ｓｌｉｃｅｒ）３０６０、及びＢＢヘッダー挿入ブロック（ＢＢ  ｈｅａｄｅｒ  ｉｎｓｅｒｔｉｏｎ  ｂｌｏｃｋ）３０７０を含むことができる。モードアダプテーション（モード適応）ブロックの各ブロックについて説明する。
【０１１８】
ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０、及びＢＢヘッダー挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサ、及びＢＢヘッダー挿入ブロックの動作に該当するので、その説明は省略する。
【０１１９】
インプットストリームスプリッタ３０００は、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。
【０１２０】
インプットストリームシンクロナイザ３０１０は、ＩＳＳＹと呼ぶことができる。ＩＳＳＹは、いかなる入力データフォーマットに対しても、ＣＢＲ（ｃｏｎｓｔａｎｔ  ｂｉｔ  ｒａｔｅ）及び一定の終端間伝送（ｅｎｄ−ｔｏ−ｅｎｄ  ｔｒａｎｓｍｉｓｓｉｏｎ）遅延を保障するに適した手段を提供することができる。ＩＳＳＹは、ＴＳを伝達する複数のデータパイプの場合に常に用いられ、ＧＳストリームを伝達する複数のデータパイプに選択的に用いられる。
【０１２１】
コンペンセーティングディレイ（補償遅延）ブロック３０２０は、受信機でさらにメモリを必要とせずにＴＳパケット再結合メカニズムを許容するために、ＩＳＳＹ情報の挿入に続く分割されたＴＳパケットストリームを遅延させることができる。
【０１２２】
ヌルパケット削除ブロック３０３０は、ＴＳインプットストリームの場合にのみ用いられる。一部のＴＳインプットストリーム又は分割されたＴＳストリームは、ＶＢＲ（ｖａｒｉａｂｌｅ  ｂｉｔ−ｒａｔｅ）サービスをＣＢＲ  ＴＳストリームに収容するために、存在する多数のヌルパケットを有することができる。この場合、不要な伝送オーバーヘッドを避けるために、ヌルパケットは確認されて伝送されなくてもよい。受信機で、除去されたヌルパケットは、伝送に挿入されたＤＮＰ（ｄｅｌｅｔｅｄ  ｎｕｌｌ−ｐａｃｋｅｔ；削除されたヌルパケット）カウンタを参照して元の正確な場所に再挿入可能であるため、ＣＢＲが保障され、タイムスタンプ（ＰＣＲ）更新が不要になる。
【０１２３】
ヘッダーコンプレションブロック３０４０は、ＴＳ又はＩＰインプットストリームに対する伝送効率を増加させるために、パケットヘッダーコンプレションを提供することができる。受信機は、ヘッダーの特定部分に対する先験的な（ａ  ｐｒｉｏｒｉ）情報を有することができるため、この知られた情報（ｋｎｏｗｎ  ｉｎｆｏｒｍａｔｉｏｎ）は送信機で削除されてもよい。
【０１２４】
ＴＳに対して、受信機は同期バイト構成（０ｘ４７）及びパケット長（１８８バイト）に関する先験的な情報を有することができる。入力されたＴＳが一つのＰＩＤだけを有するコンテンツを伝達すると、すなわち、一つのサービスコンポーネント（ビデオ、オーディオなど）又はサービスサブコンポーネント（ＳＶＣベースレイヤ、ＳＶＣエンハンスメントレイヤ、ＭＶＣベースビュー、又はＭＶＣ依存ビュー）に対してのみ、ＴＳパケットヘッダーコンプレションがＴＳに（選択的に）適用されてもよい。ＴＳパケットヘッダーコンプレションは、インプットストリームがＩＰストリームである場合に選択的に用いられる。上記のブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１２５】
図４は本発明の一実施例に係るＢＩＣＭブロックを示す。
【０１２６】
図４に示すＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭ ブロック１０１０の一実施例に該当する。
【０１２７】
前述したように、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
【０１２８】
ＱｏＳが本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するので、それぞれのサービスに該当するデータは別個の方式で処理されなければならない。したがって、本発明の一実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式をそれぞれのデータ経路に該当するデータパイプに独立して適用することによって、各データパイプを独立して処理することができる。結果的に、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、それぞれのデータパイプで伝送される各サービス又はサービスコンポーネントに対するＱｏＳを調節することができる。
【０１２９】
（ａ）は、ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロックを示し、（ｂ）は、アドバンスドプロファイルのＢＩＣＭブロックを示す。
【０１３０】
ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロック及びアドバンスドプロファイルのＢＩＣＭブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
【０１３１】
ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロック及びアドバンスドプロファイルに対するＢＩＣＭブロックの各処理ブロックについて説明する。
【０１３２】
ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー（ｍａｐｐｅｒ）５０３０、ＳＳＤ（ｓｉｇｎａｌ  ｓｐａｃｅ  ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、タイムインターリーバ５０５０を含むことができる。
【０１３３】
データＦＥＣエンコーダ５０１０は、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の具体的な動作については後述する。
【０１３４】
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながら、データＦＥＣエンコーダ５０１０の出力をインターリーブし、ＬＤＰＣコード及び変調方式の組合せによって最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作については後述する。
【０１３５】
コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）又は不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いてベース及びハンドヘルドプロファイルでビットインターリーバ５０２０からの各セルワードを変調したり、アドバンスドプロファイルでセルワードデマルチプレクサ５０１０−１からのセルワードを変調し、パワーの正規化されたコンステレーションポイントｅlを提供することができる。当該コンステレーションマッピングは、データパイプに対してのみ適用される。ＮＵＱが任意の形態を有するのに対し、ＱＡＭ−１６及びＮＵＱは正方形を有することが観察される。それぞれのコンステレーションが９０度の倍数だけ回転されると、回転されたコンステレーションは元のものと正確に重なる。回転対称特性によって失敗及び虚数コンポーネントの容量及び平均パワーが互いに同一となる。ＮＵＱ及びＮＵＣはいずれも各コードレート（ｃｏｄｅ  ｒａｔｅ）に対して特別に定義され、用いられる特定の一つは、ＰＬＳ２データに保管されたパラメータＤＰ＿ＭＯＤによってシグナルされる。
【０１３６】
タイムインターリーバ５０５０はデータパイプレベルで動作することができる。タイムインターリービングのパラメータはそれぞれのデータパイプに対して別々に設定されてもよい。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
【０１３７】
アドバンスドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、及びタイムインターリーバを含むことができる。
【０１３８】
ただし、処理ブロック５０００−１は、セルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含むという点で処理ブロック５０００と区別される。
【０１３９】
また、処理ブロック５０００−１におけるデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、タイムインターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。
【０１４０】
セルワードデマルチプレクサ５０１０−１は、アドバンスドプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離するために用いられる。セルワードデマルチプレクサ５０１０−１の具体的な動作に関しては後述する。
【０１４１】
ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号の送信のために最適化されている。ＭＩＭＯ技術は容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に放送に対して、別個の信号伝搬特性による両アンテナ間の受信信号パワー差又はチャネルの強いＬＯＳコンポーネントは、ＭＩＭＯから容量利得を得ることを困難にさせる。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの一つの位相ランダム化及び回転ベースプリコーディングを用いてこの問題を克服する。
【０１４２】
ＭＩＭＯエンコーディングは、送信機及び受信機の両方で少なくとも２つのアンテナを必要とする２ｘ２ＭＩＭＯシステムのために意図される。２つのＭＩＭＯエンコーディングモードは、本提案であるＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）及びＦＲＦＤ−ＳＭ（ｆｕｌｌ−ｒａｔｅ  ｆｕｌｌ−ｄｉｖｅｒｓｉｔｙ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）で定義される。ＦＲ−ＳＭエンコーディングは、受信機側での比較的小さい複雑度増加から容量増加を提供するが、ＦＲＦＤ−ＳＭエンコーディングは、受信機側での大きい複雑度増加から容量増加及び追加的なダイバーシチ利得を提供する。提案されたＭＩＭＯエンコーディング方式は、アンテナ極性配置を制限しない。
【０１４３】
ＭＩＭＯ処理はアドバンスドプロファイルフレームに要求されるが、これは、アドバンスドプロファイルフレームにおける全てのデータパイプがＭＩＭＯエンコーダによって処理されるということを意味する。ＭＩＭＯ処理はデータパイプレベルで適用される。コンステレーションマッパー出力のペア（ｐａｉｒ；対）であるＮＵＱ（ｅ1,i及びｅ2,i）は、ＭＩＭＯエンコーダの入力として供給される。ＭＩＭＯエンコーダ出力ペア（対）（ｇ1,i及びｇ2,i）は、それぞれの送信アンテナの同一キャリアｋ及びＯＦＤＭシンボルｌによって送信される。
【０１４４】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１４５】
図５は、本発明の他の実施例に係るＢＩＣＭブロックを示す。
【０１４６】
図５に示すＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。
【０１４７】
図５は、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報データを伝達するフレームの一部であり、ＦＩＣは、サービスと該当するベースデータパイプとの間でマッピング情報を伝達するフレームにおけるロジカルチャネルである。ＥＡＣ及びＦＩＣに関する詳細な説明は後述する。
【０１４８】
図５を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ  ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパー６０２０を含むことができる。
【０１４９】
また、ＰＬＳ  ＦＥＣエンコーダ６０００は、スクランブラ、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）ブロックを含むことができる。ＢＩＣＭブロックの各ブロックについて説明する。
【０１５０】
ＰＬＳ  ＦＥＣエンコーダ６０００は、スクランブルされたＰＬＳ１／２データ、ＥＡＣ及びＦＩＣセクションをエンコードすることができる。
【０１５１】
スクランブラは、ＢＣＨエンコーディング及びショートニング（ｓｈｏｒｔｅｎｉｎｇ）及びパンクチャされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブルすることができる。
【０１５２】
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いて、スクランブルされたＰＬＳ１／２データに外部エンコーディングを行い、ＢＣＨエンコーディングの後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ゼロ挿入の出力ビットをＬＤＰＣエンコーディングの前にパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）することができる。
【０１５３】
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコードすることができる。完全なコーディングブロックを生成するために、Ｃldpc及びパリティビットＰldpcは、それぞれのゼロが挿入されたＰＬＳ情報ブロックＩldpcから組織的にエンコードされ、その後に付加される。
【０１５４】
【数１】
0006325122.tif 000005
【０１５５】
ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の表４のとおりである。
【０１５６】
【表４】
0006325122.tif 000006
【０１５７】
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。
【０１５８】
ショートニングがＰＬＳ１データ保護に適用されると、一部のＬＤＰＣパリティビットはＬＤＰＣエンコーディング後にパンクチャされる。また、ＰＬＳ２データ保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディング後にパンクチャされる。それらのパンクチャされたビットは伝送されない。
【０１５９】
ビットインターリーバ６０１０は、それぞれのショートニング及びパンクチャされたＰＬＳ１データ及びＰＬＳ２データをインターリーブすることができる。
【０１６０】
コンステレーションマッパー６０２０は、ビットインターリーブされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマップすることができる。
【０１６１】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１６２】
図６は、本発明の一実施例に係るフレームビルディングブロック（ｆｒａｍｅ  ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）を示す。
【０１６３】
図６に示すフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の一実施例に該当する。
【０１６４】
図６を参照すると、フレームビルディングブロックは、ディレイコンペセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ；遅延補償）ブロック７０００、セルマッパー（ｃｅｌｌ  ｍａｐｐｅｒ）７０１０、及びフリークエンシインターリーバ（ｆｒｅｑｕｅｎｃｙ  ｉｎｔｅｒｌｅａｖｅｒ）７０２０を含むことができる。フレームビルディングブロックの各ブロックに関して説明する。
【０１６５】
ディレイコンペセーション（遅延補償）ブロック７０００は、データパイプと該当するＰＬＳデータとの間のタイミングを調節し、送信機側でデータパイプと該当するＰＬＳデータ間の同時性（ｃｏ−ｔｉｍｅ）を保障することができる。インプットフォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことによって、ＰＬＳデータはデータパイプだけ遅延される。ＢＩＣＭブロックの遅延は主にタイムインターリーバ５０５０に起因する。インバンド（Ｉｎ−ｂａｎｄ）シグナリングデータは、次のタイムインターリービンググループの情報を、シグナルされるデータパイプよりも１フレーム先に伝達されるようにすることができる。ディレイコンペセーション（遅延補償）ブロックは、それに応じてインバンド（Ｉｎ−ｂａｎｄ）シグナリングデータを遅延させる。
【０１６６】
セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルを、フレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップすることができる。セルマッパー７０１０の基本機能は、それぞれのデータパイプ、ＰＬＳセル、及びＥＡＣ／ＦＩＣセルに対するタイムインターリービングによって生成されたデータセルを、存在するなら、一つのフレーム内でそれぞれのＯＦＤＭシンボルに該当するアクティブ（ａｃｔｉｖｅ）ＯＦＤＭセルのアレイにマップすることである。（ＰＳＩ（ｐｒｏｇｒａｍ  ｓｐｅｃｉｆｉｃ  ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩのような）サービスシグナリングデータは個別的に収集され、データパイプによって送られてもよい。セルマッパーは、フレーム構造の構成及びスケジューラによって生成されたダイナミックインフォメーション（ｄｙｎａｍｉｃ  ｉｎｆｏｒｍａｔｉｏｎ；動的情報）によって動作する。フレームに関する詳細な内容は後述する。
【０１６７】
フリークエンシインターリーバ７０２０は、セルマッパー７０１０から受信したデータセルをランダムにインターリーブして周波数ダイバーシチを提供することができる。また、フリークエンシインターリーバ７０２０は、単一フレームで最大のインターリービング利得を得るために、他のインターリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（対）で動作することができる。
【０１６８】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１６９】
図７は、本発明の一実施例に係るＯＦＤＭジェネレーションブロックを示す。
【０１７０】
図７に示すＯＦＤＭジェネレーションブロックは、図１を参照して説明したＯＦＤＭジェネレーションブロック１０３０の一実施例に該当する。
【０１７１】
ＯＦＤＭジェネレーションブロックは、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは、順次にガードインターバルを挿入し、ＰＡＰＲ減少処理を適用して最終ＲＦ信号を生成する。
【０１７２】
図７を参照すると、ＯＦＤＭジェネレーションブロックは、パイロット及びリザーブドトーン挿入ブロック（ｐｉｌｏｔ  ａｎｄ  ｒｅｖｓｅｒｖｅｄ  ｔｏｎｅ  ｉｎｓｅｒｔｉｏｎ  ｂｌｏｃｋ）８０００、２Ｄ−ｅＳＦＮ（ｓｉｎｇｌｅ  ｆｒｅｑｕｅｎｃｙ  ｎｅｔｗｏｒｋ）エンコーディングブロック８０１０、ＩＦＦＴ（ｉｎｖｅｒｓｅ  ｆａｓｔ  Ｆｏｕｒｉｅｒ  ｔｒａｎｓｆｏｒｍ）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、ガードインターバル挿入ブロック（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ  ｉｎｓｅｒｔｉｏｎ  ｂｌｏｃｋ）８０４０、プリアンブル挿入ブロック（ｐｒｅａｍｂｌｅ  ｉｎｓｅｒｔｉｏｎ  ｂｌｏｃｋ）８０５０、その他システム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。
【０１７３】
システム挿入ブロック８０６０は、放送サービスを提供する２つ以上の別個の放送送信／受信システムのデータが同一のＲＦ信号帯域で同時に伝送され得るように、時間領域で複数の放送送信／受信システムの信号をマルチプレクスすることができる。ここで、２つ以上の別個の放送送信／受信システムとは、別個の放送サービスを提供するシステムのことをいう。別個の放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。
【０１７４】
図８は、本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す。
【０１７５】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応し得る。
【０１７６】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ＆  ｄｅｍｏｄｕｌａｔｉｏｎ  ｍｏｄｕｌｅ）９０００、フレームパーシングモジュール（ｆｒａｍｅ  ｐａｒｓｉｎｇ  ｍｏｄｕｌｅ）９０１０、デマッピング及びデコーディングモジュール（ｄｅｍａｐｐｉｎｇ  ＆  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）９０２０、出力プロセッサ（ｏｕｔｐｕｔ  ｐｒｏｃｅｓｓｏｒ）９０３０、及びシグナリングデコーディングモジュール（ｓｉｇｎａｌｉｎｇ  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）９０４０を含むことができる。放送信号受信装置の各モジュールの動作について説明する。
【０１７７】
同期及び復調モジュール９０００は、ｍ個の受信アンテナを通じて入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置によって実行される手順の逆手順に該当する復調を実行することができる。
【０１７８】
フレームパーシングモジュール９０１０は、入力信号フレームをパースし、ユーザによって選択されたサービスが伝送されるデータを抽出することができる。放送信号送信装置がインターリービングを実行すると、フレームパーシングモジュール９０１０は、インターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されるべき信号及びデータの位置がシグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって取得され、放送信号送信装置によって生成されたスケジューリング情報を復元することができる。
【０１７９】
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によって、それらのビット領域データをデインターリーブすることができる。デマッピング及びデコーディングモジュール９０２０は、伝送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングを通じて伝送チャネルで発生した誤りを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって、デマッピング及びデコーディングのために必要な伝送パラメータを取得することができる。
【０１８０】
出力プロセッサ９０３０は、伝送効率を向上させるために、放送信号送信装置によって適用される様々な圧縮／信号処理手順の逆手順を実行することができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータで必要な制御情報を取得することができる。出力プロセッサ９０３０の出力は、放送信号送信装置に入力される信号に該当し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４又はｖ６）及びＧＳであってもよい。
【０１８１】
シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００によって復調された信号からＰＬＳ情報を取得することができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。
【０１８２】
図９は、本発明の一実施例に係るフレーム構造を示す。
【０１８３】
図９は、フレームタイムの構成例及びスーパーフレームにおけるＦＲＵ（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ；フレーム反復単位）を示す。（ａ）は、本発明の一実施例に係るスーパーフレームを示し、（ｂ）は、本発明の一実施例に係るＦＲＵを示し、（ｃ）は、ＦＲＵにおける様々なフィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）のフレームを示し、（ｄ）は、フレームの構造を示す。
【０１８４】
スーパーフレームは８個のＦＲＵを含むことができる。ＦＲＵは、フレームのＴＤＭに対する基本マルチプレクシング単位であり、スーパーフレームで８回反復される。
【０１８５】
ＦＲＵにおいて各フレームはフィジカルプロファイル（ベース、ハンドヘルド、アドバンスドプロファイル）のいずれか一つ又はＦＥＦに属する。ＦＲＵにおいてフレームの最大許容数は４であり、与えられたフィジカルプロファイルは、ＦＲＵにおいて０回乃至４回の回数を有することができる（例えば、ベース、ベース、ハンドヘルド、アドバンスド）。フィジカルプロファイル定義は、必要時には、プリアンブルにおけるＰＨＹ＿ＰＲＯＦＩＬＥのリザーブド値を用いて拡張されてもよい。
【０１８６】
ＦＥＦ部分は、含まれるなら、ＦＲＵの終わりに挿入される。ＦＥＦがＦＲＵに含まれる場合、ＦＥＦの最大数はスーパーフレームにおいて８である。ＦＥＦ部分が互いに隣接することは推奨されない。
【０１８７】
一つのフレームは、複数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に示すように、フレームは、プリアンブル、一つ以上のＦＳＳ、ノーマルデータシンボル、ＦＥＳを含む。
【０１８８】
プリアンブルは、高速ヒューチャキャストＵＴＢシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルに関する詳細な内容は後述する。
【０１８９】
ＦＳＳの主な目的は、ＰＬＳデータを伝達することである。高速同期化及びチャネル推定のために、これによるＰＬＳデータの高速デコーディングのために、ＦＳＳは、ノーマルデータシンボルに比べてより高密度のパイロットパターンを有する。ＦＥＳはＦＳＳと全く同じパイロットを有するが、これは、ＦＥＳ直前のシンボルに対して外挿（ｅｘｔｒａｐｏｌａｔｉｏｎ）無しで、ＦＥＳ内における周波数だけのインターポレーション（補間）及び時間的補間（ｔｅｍｐｏｒａｌ  ｉｎｔｅｒｐｏｌａｔｉｏｎ）を可能にする。
【０１９０】
図１０は、本発明の一実施例に係るフレームのシグナリング階層構造（ｓｉｇｎａｌｉｎｇ  ｈｉｅｒａｒｃｈｙ  ｓｔｒｕｃｔｕｒｅ）を示す。
【０１９１】
図１０は、シグナリング階層構造を示すが、これは、３個の主要部分であるプリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０、及びＰＬＳ２データ１１０２０に分割される。毎フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータ及び伝送タイプを示すことである。ＰＬＳ１は、受信機が関心のあるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコーディング可能にさせる。ＰＬＳ２は毎フレームごとに伝達され、２つの主要部分であるＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータとに分割される。ＰＬＳ２データのスタティック（静的）及びダイナミック（動的）部分には必要時にパディングが続く。
【０１９２】
図１１は、本発明の一実施例に係るプリアンブルシグナリングデータを示す。
【０１９３】
プリアンブルシグナリングデータは、受信機がフレーム構造内でＰＬＳデータに接続し、データパイプを追跡できるようにするために必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータに関する詳細な内容は、次のとおりである。
【０１９４】
ＰＨＹ＿ＰＲＯＦＩＬＥ：当該３ビットフィールドは、現フレームのフィジカルプロファイルタイプを示す。各フィジカルプロファイルタイプのマッピングは、下記の表５のように与えられる。
【０１９５】
【表５】
0006325122.tif 000007
【０１９６】
ＦＦＴ＿ＳＩＺＥ：当該２ビットフィールドは、下記の表６で説明したとおり、フレームグループ内で現フレームのＦＦＴサイズを示す。
【０１９７】
【表６】
0006325122.tif 000008
【０１９８】
ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、下記の表７で説明したとおり、現スーパーフレームにおけるガードインターバルの一部（ｆｒａｃｔｉｏｎ）値を示す。
【０１９９】
【表７】
0006325122.tif 000009
【０２００】
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＥＡＣが現フレームで提供されるか否かを示す。当該フィールドが１に設定されると、ＥＡＳが現フレームで提供される。当該フィールドが０に設定されると、ＥＡＳが現フレームで伝達されない。当該フィールドはスーパーフレーム内でダイナミック（動的）に転換されてもよい。
【０２０１】
ＰＩＬＯＴ＿ＭＯＤＥ：当該１ビットフィールドは、現フレームグループで現フレームに対してパイロットモードがモバイルモードなのか又は固定モードなのかを示す。当該フィールドが０に設定されると、モバイルパイロットモードが用いられる。当該フィールドが１に設定されると、固定パイロットモードが用いられる。
【０２０２】
ＰＡＰＲ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームグループで現フレームに対してＰＡＰＲ減少が用いられるか否かを示す。当該フィールドが１に設定されると、トーン予約（ｔｏｎｅ  ｒｅｓｅｒｖａｔｉｏｎ）がＰＡＰＲ減少のために用いられる。当該フィールドが０に設定されると、ＰＡＰＲ減少が用いられない。
【０２０３】
ＦＲＵ＿ＣＯＮＦＩＧＵＲＥ：当該３ビットフィールドは、現スーパーフレームで存在するＦＲＵのフィジカルプロファイルタイプ構成を示す。現スーパーフレームで全プリアンブルにおける当該フィールドにおいて、現スーパーフレームで伝達される全プロファイルタイプが識別される。当該３ビットフィールドは、下記の表８に示すように、それぞれのプロファイルに対して別々に定義される。
【０２０４】
【表８】
0006325122.tif 000010
【０２０５】
ＲＥＳＥＲＶＥＤ：当該７ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２０６】
図１２は、本発明の一実施例に係るＰＬＳ１データを示す。
【０２０７】
ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするために必要なパラメータを含む基本伝送パラメータを提供する。前述したように、ＰＬＳ１データは、一つのフレームグループの全デューレーションで変化しない。ＰＬＳ１データのシグナリングフィールドの具体的な定義は次のとおりである。
【０２０８】
ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：当該２０ビットフィールドは、ＥＡＣ＿ＦＬＡＧ以外のプリアンブルシグナリングデータのコピーである。
【０２０９】
ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：当該２ビットフィールドは、ＦＲＵ当たりのフレーム数を示す。
【０２１０】
ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは、表９に示すようにシグナルされる。
【０２１１】
【表９】
0006325122.tif 000011
【０２１２】
ＮＵＭ＿ＦＳＳ：当該２ビットフィールドは、現フレームでＦＳＳの数を示す。
【０２１３】
ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、伝送される信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは、主バージョン及び副バージョンの２つの４ビットフィールドに分離される。
【０２１４】
主バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢである４ビットは、主バージョン情報を示す。主バージョンフィールドにおける変化は、互換が不可能な変化を示す。デフォルト値は００００である。当該標準で述べているバージョンに対して、値が００００に設定される。
【０２１５】
副バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢである４ビットは、副バージョン情報を示す。副バージョンフィールドにおける変化は、互換が可能である。
【０２１６】
ＣＥＬＬ＿ＩＤ：これは、ＡＴＳＣネットワークで地理的セルを唯一に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジは、ヒューチャキャストＵＴＢシステム当たりに用いられる周波数の数によって一つ以上の周波数で構成されてもよい。ＣＥＬＬ＿ＩＤの値が知られないか又は特定されないと、当該フィールドは０に設定される。
【０２１７】
ＮＥＴＷＯＲＫ＿ＩＤ：これは、現ＡＴＳＣネットワークを唯一に識別する１６ビットフィールドである。
【０２１８】
ＳＹＳＴＥＭ＿ＩＤ：該当１６ビットフィールドは、ＡＴＳＣネットワーク内でヒューチャキャストＵＴＢシステムを唯一に識別する。ヒューチャキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。ヒューチャキャストＵＴＢシステムは、存在するなら、ＦＥＦ及び一つ以上のフィジカルプロファイルを伝達する。同じヒューチャキャストＵＴＢシステムは、別個の入力ストリームを伝達し、別個の地理的領域で別個のＲＦを用いることができ、ローカルサービス挿入を許容する。フレーム構造及びスケジューリングは一つの場所で制御され、ヒューチャキャストＵＴＢシステム内で全ての伝送に対して同一である。一つ以上のヒューチャキャストＵＴＢシステムはいずれも同一のフィジカル構造及び構成を有するという同一のＳＹＳＴＥＭ＿ＩＤ意味を有することができる。
【０２１９】
次のループ（ｌｏｏｐ）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、ＲＥＳＥＲＶＥＤで構成される。ループ（ｌｏｏｐ）サイズは、ＦＲＵ内で４個のフィジカルプロファイル（ＦＥＦを含む）がシグナルされるように固定される。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４よりも小さいと、用いられないフィールドはゼロで埋められる。
【０２２０】
ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレーム（ｉはループ（ｌｏｏｐ）インデックス）のフィジカルプロファイルタイプを示す。当該フィールドは表８に示すものと同じシグナリングフォーマットを用いる。
【０２２１】
ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：当該２ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを用いると、フレームデューレーションの正確な値が得られる。
【０２２２】
ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームのガードインターバルの一部の値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは、表７に従ってシグナルされる。
【０２２３】
ＲＥＳＥＲＶＥＤ：当該４ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２２４】
次のフィールドは、ＰＬＳ２データをデコードするためのパラメータを提供する。
【０２２５】
ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、ＰＬＳ２保護によって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、表１０に従ってシグナルされる。ＬＤＰＣコードに関する詳細な内容は後述する。
【０２２６】
【表１０】
0006325122.tif 000012
【０２２７】
ＰＬＳ２＿ＭＯＤ：当該３ビットフィールドは、ＰＬＳ２によって用いられる変調タイプを示す。変調タイプは表１１に従ってシグナルされる。
【０２２８】
【表１１】
0006325122.tif 000013
【０２２９】
ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、現フレームグループで伝達されるＰＬＳ２に対する全コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣtotal_partial_blockを示す。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２３０】
ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２３１】
ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２３２】
ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
【０２３３】
ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、現フレームグループの毎フレームごとに伝達されるＰＬＳ２に対する部分コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣtotal_partial_blockを示す。反復が用いられない場合、当該フィールドの値は０と同一である。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２３４】
ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられるＦＥＣタイプを示す。ＦＥＣタイプは表１０に従ってシグナルされる。
【０２３５】
ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：当該３ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられる変調タイプを示す。変調タイプは表１１に従ってシグナルされる。
【０２３６】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが次のフレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
【０２３７】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、次のフレームグループの毎フレームごとに伝達されるＰＬＳ２に対する全コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣtotal_full_blockを示す。次のフレームグループで反復が用いられない場合、当該フィールドの値は０と同一である。当該値は現フレームグループの全デューレーションにおいて一定である。
【０２３８】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループにおいて一定である。
【０２３９】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループにおいて一定である。
【０２４０】
ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、現フレームグループでＰＬＳ２に対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全デューレーションにおいて一定である。下記の表１２は当該フィールドの値を提供する。当該フィールドの値が００に設定されると、現フレームグループで追加パリティがＰＬＳ２に対して用いられない。
【０２４１】
【表１２】
0006325122.tif 000014
【０２４２】
ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２４３】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２シグナリングに対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全デューレーションにおいて一定である。表１２は、当該フィールドの値を定義する。
【０２４４】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２４５】
ＲＥＳＥＲＶＥＤ：該当３２ビットフィールドは将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２４６】
ＣＲＣ＿３２：全ＰＬＳ１シグナリングに適用される３２ビット誤り検出コード
【０２４７】
図１３は、本発明の一実施例に係るＰＬＳ２データを示す。
【０２４８】
図１３は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２−ＤＹＮデータは現フレームに対して特定の情報を提供する。
【０２４９】
ＰＬＳ２−ＳＴＡＴデータのフィールドに対して次に具体的に説明する。
【０２５０】
ＦＩＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＦＩＣが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＦＩＣは現フレームで提供される。当該フィールドの値が０に設定されると、ＦＩＣは現フレームで伝達されない。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２５１】
ＡＵＸ＿ＦＬＡＧ：当該１ビットフィールドは、補助ストリームが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、補助ストリームは現フレームで提供される。当該フィールドの値が０に設定されると、補助フレームは現フレームで伝達されない。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２５２】
ＮＵＭ＿ＤＰ：該当６ビットフィールドは、現フレーム内で伝達されるデータパイプの数を示す。当該フィールドの値は１〜６４であり、データパイプの数はＮＵＭ＿ＤＰ＋１である。
【０２５３】
ＤＰ＿ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内でＤＰを唯一に識別する。
【０２５４】
ＤＰ＿ＴＹＰＥ：当該３ビットフィールドはデータパイプのタイプを示す。これは、下記の表１３に従ってシグナルされる。
【０２５５】
【表１３】
0006325122.tif 000015
【０２５６】
ＤＰ＿ＧＲＯＵＰ＿ＩＤ：当該８ビットフィールドは、現データパイプが関連しているデータパイプグループを識別する。これは、受信機が同じＤＰ＿ＧＲＯＵＰ＿ＩＤを有する特定サービスと関連しているサービスコンポーネントのデータパイプに接続するために用いられてもよい。
【０２５７】
ＢＡＳＥ＿ＤＰ＿ＩＤ：当該６ビットフィールドは、管理階層で用いられる（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ＿ＤＰ＿ＩＤで示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達するノーマルデータパイプであってもよく、サービスシグナリングデータだけを伝達する専用データパイプであってもよい。
【０２５８】
ＤＰ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、関連したデータパイプによって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、下記の表１４に従ってシグナルされる。
【０２５９】
【表１４】
0006325122.tif 000016
【０２６０】
ＤＰ＿ＣＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられるコードレート（ｃｏｄｅ  ｒａｔｅ）を示す。コードレート（ｃｏｄｅ  ｒａｔｅ）は、下記の表１５に従ってシグナルされる。
【０２６１】
【表１５】
0006325122.tif 000017
【０２６２】
ＤＰ＿ＭＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられる変調を示す。変調は、下記の表１６に従ってシグナルされる。
【０２６３】
【表１６】
0006325122.tif 000018
【０２６４】
ＤＰ＿ＳＳＤ＿ＦＬＡＧ：当該１ビットフィールドは、ＳＳＤモードが関連したデータパイプで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＳＳＤが用いられる。当該フィールドの値が０に設定されると、ＳＳＤは用いられない。
【０２６５】
次のフィールドは、ＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す０１０と同一である場合にのみ表される。
【０２６６】
ＤＰ＿ＭＩＭＯ：当該３ビットフィールドは、どのタイプのＭＩＭＯエンコーディング処理が関連したデータパイプに適用されるかを示す。ＭＩＭＯエンコーディング処理のタイプは、下記の表１７に従ってシグナルされる。
【０２６７】
【表１７】
0006325122.tif 000019
【０２６８】
ＤＰ＿ＴＩ＿ＴＹＰＥ：当該１ビットフィールドは、タイムインターリービングのタイプを示す。０の値は、一つのタイムインターリービンググループが一つのフレームに該当し、一つ以上のタイムインターリービングブロックを含むことを示す。１の値は、一つのタイムインターリービンググループが一つよりも多いフレームで伝達され、一つのタイムインターリービングブロックのみを含むことを示す。
【０２６９】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：当該２ビットフィールド（許容された値は、１、２、４、８のみである。）の使用は、次のようなＤＰ＿ＴＩ＿ＴＹＰＥフィールド内で設定される値によって決定される。
【０２７０】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が１に設定されると、当該フィールドは、それぞれのタイムインターリービンググループがマップされるフレームの数であるＰIを示し、タイムインターリービンググループ当たりに一つのタイムインターリービングブロックが存在する（ＮTI＝１）。当該２ビットフィールドで許容されるＰＩの値は、下記の表１８に定義される。
【０２７１】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が０に設定されると、当該フィールドは、タイムインターリービンググループ当たりのタイムインターリービングブロックの数ＮTIを示し、フレーム当たりに一つのタイムインターリービンググループが存在する（ＰI＝１）。当該２ビットフィールドで許容されるＰIの値は、下記の表１８に定義される。
【０２７２】
【表１８】
0006325122.tif 000020
【０２７３】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：当該２ビットフィールドは、関連したデータパイプに対するフレームグループ内でフレーム間隔（ＩJUMP）を示し、許容された値は１，２，４，８（該当する２ビットフィールドはそれぞれ００，０１，１０，１１）である。フレームグループの全フレームに現れないデータパイプに対して、当該フィールドの値は、順次的なフレーム間の間隔と同一である。例えば、データパイプが１，５，９，１３などのフレームで現れると、当該フィールドの値は４に設定される。全フレームに現れるデータパイプに対して、当該フィールドの値は１に設定される。
【０２７４】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：当該１ビットフィールドは、タイムインターリーバ５０５０の可用性を決定する。データパイプに対してタイムインターリービングが用いられないと、当該フィールド値は１に設定される。一方、タイムインターリービングが用いられると、当該フィールド値は０に設定される。
【０２７５】
ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：当該５ビットフィールドは、現データパイプが発生するスーパーフレームの最初のフレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は、０〜３１である。
【０２７６】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：当該１０ビットフィールドは、当該データパイプに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。当該フィールドの値はＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同じ範囲を有する。
【０２７７】
ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは、下記の表１９に従ってシグナルされる。
【０２７８】
【表１９】
0006325122.tif 000021
【０２７９】
ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：当該２ビットフィールドは、現データパイプがインバンド（Ｉｎ−ｂａｎｄ）シグナリング情報を伝達するか否かを示す。インバンド（Ｉｎ−ｂａｎｄ）シグナリングタイプは、下記の表２０に従ってシグナルされる。
【０２８０】
【表２０】
0006325122.tif 000022
【０２８１】
ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは、入力ペイロードタイプが選択されると、下記の表２１に従ってシグナルされる。
【０２８２】
【表２１】
0006325122.tif 000023
【０２８３】
ＤＰ＿ＣＲＣ＿ＭＯＤＥ：当該２ビットフィールドは、ＣＲＣエンコーディングがインプットフォーマットブロックで用いられるか否かを示す。ＣＲＣモードは、下記の表２２に従ってシグナルされる。
【０２８４】
【表２２】
0006325122.tif 000024
【０２８５】
ＤＮＰ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、下記の表２３に従ってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＤＮＰ＿ＭＯＤＥは００の値に設定される。
【０２８６】
【表２３】
0006325122.tif 000025
【０２８７】
ＩＳＳＹ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、下記の表２４に従ってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＩＳＳＹ＿ＭＯＤＥは００の値に設定される。
【０２８８】
【表２４】
0006325122.tif 000026
【０２８９】
ＨＣ＿ＭＯＤＥ＿ＴＳ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるＴＳヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、下記の表２５に従ってシグナルされる。
【０２９０】
【表２５】
0006325122.tif 000027
【０２９１】
ＨＣ＿ＭＯＤＥ＿ＩＰ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（‘０１’）に設定される場合に、ＩＰヘッダーコンプレションモードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは、下記の表２６に従ってシグナルされる。
【０２９２】
【表２６】
0006325122.tif 000028
【０２９３】
ＰＩＤ：当該１３ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが０１又は１０に設定される場合に、ＴＳヘッダー圧縮のためのＰＩＤ数を示す。
【０２９４】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２９５】
次のフィールドは、ＦＩＣ＿ＦＬＡＧが１と同一である場合にのみ現れる。
【０２９６】
ＦＩＣ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、ＦＩＣのバージョンナンバーを示す。
【０２９７】
ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１３ビットフィールドは、ＦＩＣの長さをバイト単位で示す。
【０２９８】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２９９】
次のフィールドは、ＡＵＸ＿ＦＬＡＧが１と同一である場合にのみ現れる。
【０３００】
ＮＵＭ＿ＡＵＸ：当該４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが用いられないことを示す。
【０３０１】
ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：当該８ビットフィールドは将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０３０２】
ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：当該４ビットは、現補助ストリームのタイプを示すための将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０３０３】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：該当２８ビットフィールドは、補助ストリームをシグナリングするための将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０３０４】
図１４は、本発明の他の実施例に係るＰＬＳ２データを示す。
【０３０５】
図１４は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は一つのフレームグループのデューレーションで変化してもよいが、フィールドのサイズは一定である。
【０３０６】
ＰＬＳ２−ＤＹＮデータのフィールドの具体的な内容は、次のとおりである。
【０３０７】
ＦＲＡＭＥ＿ＩＮＤＥＸ：当該５ビットフィールドは、スーパーフレーム内で現フレームのフレームインデックスを示す。スーパーフレームの最初のフレームのインデックスは０に設定される。
【０３０８】
ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナルされる値で示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、１の値は、次のスーパーフレームに変化があることを示す。
【０３０９】
ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成（すなわち、ＦＩＣのコンテンツ）が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナルされる値で示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、０００１の値は、次のスーパーフレームに変化があるということを示す。
【０３１０】
ＲＥＳＥＲＶＥＤ：当該１６ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０３１１】
次のフィールドは、現フレームで伝達されるデータパイプと関連したパラメータを説明するＮＵＭ＿ＤＰにおけるループ（ｌｏｏｐ）に現れる。
【０３１２】
ＤＰ＿ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内でデータパイプを唯一に示す。
【０３１３】
ＤＰ＿ＳＴＡＲＴ：当該１５ビット（又は、１３ビット）フィールドは、ＤＰＵアドレシング（ａｄｄｒｅｓｓｉｎｇ）技法を用いてデータパイプの最初のの開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、下記の表２７に示すように、フィジカルプロファイル及びＦＦＴサイズによって別個の長さを有する。
【０３１４】
【表２７】
0006325122.tif 000029
【０３１５】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：当該１０ビットフィールドは、現データパイプに対する現タイムインターリービンググループでＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値は、０〜１０２３である。
【０３１６】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０３１７】
次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。
【０３１８】
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームでＥＡＣの存在を示す。該当ビットはプリアンブルでＥＡＣ＿ＦＬＡＧと同じ値である。
【０３１９】
ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：当該８ビットフィールドは、自動活性化指示のバージョンナンバーを示す。
【０３２０】
ＥＡＣ＿ＦＬＡＧフィールドが１に等しいと、次の１２ビットがＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドに割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが０に等しいと、次の１２ビットがＥＡＣ＿ＣＯＵＮＴＥＲに割り当てられる。
【０３２１】
ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１２ビットフィールドは、ＥＡＣの長さをバイトで示す。
【０３２２】
ＥＡＣ＿ＣＯＵＮＴＥＲ：当該１２ビットフィールドは、ＥＡＣが到達するフレーム以前のフレームの数を示す。
【０３２３】
次のフィールドは、ＡＵＸ＿ＦＬＡＧフィールドが１と同一である場合にのみ現れる。
【０３２４】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：当該４８ビットフィールドは、補助ストリームをシグナリングするための将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。当該フィールドの意味は、設定可能なＰＬＳ２−ＳＴＡＴでＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。
【０３２５】
ＣＲＣ＿３２：全ＰＬＳ２に適用される３２ビット誤り検出コード。
【０３２６】
図１５は、本発明の一実施例に係るフレームのロジカル（ｌｏｇｉｃａｌ）構造を示す。
【０３２７】
前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、ダミーセルは、フレームでＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳ１及びＰＬＳ２は、初めには一つ以上のＦＳＳにマップされる。その後、ＥＡＣが存在すると、ＥＡＣセルは直後のＰＬＳフィールドにマップされる。次にＦＩＣが存在すると、ＦＩＣセルがマップされる。データパイプはＰＬＳの次にマップされるか、或いは、ＥＡＣ又はＦＩＣが存在すると、ＥＡＣ又はＦＩＣの後にマップされる。タイプ１データパイプが最初にマップされ、その次にタイプ２データパイプがマップされる。データパイプのタイプの具体的な内容は後述する。一部の場合に、データパイプは、ＥＡＳに対する一部の特殊データ又はサービスシグナリングデータを伝達することができる。補助ストリーム又はストリームは、存在するなら、データパイプの次にマップされ、ここには順にダミーセルが続く。前述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルの順で全て共にマップすると、フレームでセル容量を正確に満たす。
【０３２８】
図１６は、本発明の一実施例に係るＰＬＳマッピングを示す。
【０３２９】
ＰＬＳセルは、ＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳが占めるセルの数によって、一つ以上のシンボルがＦＳＳとして指定され、ＦＳＳの数ＮFSSは、ＰＬＳ１におけるＮＵＭ＿ＦＳＳでシグナルされる。ＦＳＳは、ＰＬＳセルを伝達する特殊なシンボルである。警告性及び遅延時間（ｌａｔｅｎｃｙ）はＰＬＳで重大な事案であるため、ＦＳＳは高いパイロット密度を有し、高速同期化及びＦＳＳ内における周波数のみのインターポレーション（補間）を可能にする。
【０３３０】
ＰＬＳセルは、図１６の例に示すように、下向き方式でＦＳＳのアクティブキャリアにマップされる。ＰＬＳ１セルははじめは、最初のＦＳＳの最初のセルからセルインデックスの昇順でマップされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後に続き、マッピングは、最初のＦＳＳの最後のセルインデックスまで下向き方式で続く。必要なＰＬＳセルの全数が一つのＦＳＳのアクティブキャリアの数を超えると、マッピングは次のＦＳＳに進行され、最初のＦＳＳと全く同じ方式で続けて行われる。
【０３３１】
ＰＬＳマッピングが完了した後、データパイプが次に伝達される。ＥＡＣ、ＦＩＣ、又は両方が現フレームに存在すると、ＥＡＣ及びＦＩＣは、ＰＬＳとノーマルデータパイプとの間に配置される。
【０３３２】
図１７は、本発明の一実施例に係るＥＡＣマッピングを示す。
【０３３３】
ＥＡＣは、ＥＡＳメッセージを伝達する専用チャネルであり、ＥＡＳに対するデータパイプに連結される。ＥＡＳ支援は提供されるが、ＥＡＣ自体は全てのフレームに存在してもよく、存在しなくてもよい。ＥＡＣが存在すると、ＥＡＣは、ＰＬＳ２セルの直後にマップされる。ＰＬＳセルを除けば、ＦＩＣ、データパイプ、補助ストリーム又はダミーセルのいずれもＥＡＣの前に位置しない。ＥＡＣセルのマッピング手順はＰＬＳと全く同一である。
【０３３４】
ＥＡＣセルは、図１７の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順でマップされる。ＥＡＳメッセージの大きさによって、図１８に示すように、ＥＡＣセルは、少ないシンボルを占めることができる。
【０３３５】
ＥＡＣセルは、ＰＬＳ２の最後のセルの直後に続き、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向き方式で続けて行われる。必要なＥＡＣセルの全数が最後のＦＳＳの残っているアクティブキャリアの数を超えると、ＥＡＣマッピングは次のシンボルに進行され、ＦＳＳと全く同じ方式で続けて行われる。この場合、ＥＡＣのマッピングがなされる次のシンボルは、ノーマルデータシンボルであり、これは、ＦＳＳに比べてより多いアクティブキャリアを有する。
【０３３６】
ＥＡＣマッピングが完了した後、存在するなら、ＦＩＣが次に伝達される。ＦＩＣが伝送されないと（ＰＬＳ２フィールドでシグナリングによって）、データパイプがＥＡＣの最後のセルの直後に続く。
【０３３７】
図１８は、本発明の一実施例に係るＦＩＣマッピングを示す。
【０３３８】
（ａ）は、ＥＡＣ無しのＦＩＣセルのマッピングの例を示し、（ｂ）は、ＥＡＣと共にＦＩＣセルのマッピングの例を示す。
【０３３９】
ＦＩＣは、高速サービス取得及びチャネルスキャンを可能にするために層間情報（ｃｒｏｓｓ−ｌａｙｅｒ  ｉｎｆｏｒｍａｔｉｏｎ）を伝達する専用チャネルである。当該情報は主に、データパイプ間のチャネルバインディング（ｃｈａｎｎｅｌ  ｂｉｎｄｉｎｇ）情報及び各放送会社のサービスを含む。高速スキャンのために、受信機はＦＩＣをデコードし、放送会社ＩＤ、サービス数、ＢＡＳＥ＿ＤＰ＿ＩＤのような情報を取得することができる。高速サービスの取得のために、ＦＩＣだけでなくベースデータパイプもＢＡＳＥ＿ＤＰ＿ＩＤを用いてデコードすることができる。ベースデータパイプが伝達するコンテンツを除いて、ベースデータパイプは、ノーマルデータパイプと全く同じ方式でエンコードされてフレームにマップされる。したがって、ベースデータパイプに関する追加説明は不要である。ＦＩＣデータが生成されて管理階層で消費される。ＦＩＣデータのコンテンツは、管理階層の仕様に説明されたとおりである。
【０３４０】
ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２のスタティック（静的）である部分でＦＩＣ＿ＦＬＡＧパラメータによってシグナルされる。ＦＩＣが用いられると、ＦＩＣ＿ＦＬＡＧは１に設定され、ＦＩＣに対するシグナリングフィールドは、ＰＬＳ２のスタティック（静的）である部分で定義される。当該フィールドでシグナルされるものはＦＩＣ＿ＶＥＲＳＩＯＮであり、ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ．ＦＩＣは、ＰＬＳ２と同じ変調、コーディング、タイムインターリービングパラメータを用いる。ＦＩＣは、ＰＬＳ２＿ＭＯＤ及びＰＬＳ２＿ＦＥＣのような同一のシグナリングパラメータを共有する。ＦＩＣデータは、存在するなら、ＰＬＳ２の後にマップされるか、ＥＡＣが存在すると、ＥＡＣの直後にマップされる。ノーマルデータパイプ、補助ストリーム、又はダミーセルのいずれもＦＩＣの前に位置しない。ＦＩＣセルをマップする方法は、ＥＡＣと全く同一であり、これはさらにＰＬＳと同一である。
【０３４１】
ＰＬＳの後にＥＡＣが存在しない場合、ＦＩＣセルは、（ａ）の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順でマップされる。ＦＩＣデータサイズによって、（ｂ）に示すように、ＦＩＣセルは数個のシンボルに対してマップされる。
【０３４２】
ＦＩＣセルは、ＰＬＳ２の最後のセルの直後に続き、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向き方式で続けて行われる。必要なＦＩＣセルの全数が最後のＦＳＳの残っているアクティブキャリアの数を超えると、マッピングは次のシンボルに進行され、これはＦＳＳと全く同じ方式で続けて行われる。この場合、ＦＩＣがマップされる次のシンボルはノーマルデータシンボルであり、これはＦＳＳに比べてより多いアクティブキャリアを有する。
【０３４３】
ＥＡＳメッセージが現フレームで伝送されると、ＥＡＣはＦＩＣよりも先にマップされ、（ｂ）に示すように、ＥＡＣの次のセルから、ＦＩＣセルはインデックスの昇順でマップされる。
【０３４４】
ＦＩＣマッピングが完了した後、一つ以上のデータパイプがマップされ、その後、存在するなら、補助ストリーム、ダミーセルが続く。
【０３４５】
図１９は、本発明の一実施例に係るＦＥＣ構造を示す。
【０３４６】
図１９は、ビットインターリービング前の本発明の一実施例に係るＦＥＣ構造を示す。前述したように、データＦＥＣエンコーダは外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行することができる。図示されたＦＥＣ構造は、ＦＥＣＢＬＯＣＫに該当する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに該当する同一の値を有する。
【０３４７】
図１９に示すように、ＢＣＨエンコーディングがそれぞれのＢＢＦ（Ｋbchビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコードされたＢＢＦ（Ｋldpcビット＝Ｎbchビット）に適用される。
【０３４８】
Ｎldpcの値は、６４８００ビット（ロングＦＥＣＢＬＯＣＫ）又は１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。
【０３４９】
下記の表２８及び表２９は、ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫのそれぞれに対するＦＥＣエンコーディングパラメータを示す。
【０３５０】
【表２８】
0006325122.tif 000030
【０３５１】
【表２９】
0006325122.tif 000031
【０３５２】
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの具体的な動作は、次のとおりである。
【０３５３】
１２−誤り訂正ＢＣＨコードがＢＢＦの外部エンコーディングに用いられる。ショートＦＥＣＢＬＯＣＫ及びロングＦＥＣＢＬＯＣＫに対するＢＢＦ生成多項式は、全ての多項式を乗算することによって得られる。
【０３５４】
ＬＤＰＣコードは、外部ＢＣＨエンコーディングの出力をエンコードするために用いられる。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐldpc（パリティビット）がそれぞれのＩldpc（ＢＣＨ−エンコードされたＢＢＦ）から組織的にエンコードされ、Ｉldpcに付加される。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）は、次の式で表現される。
【０３５５】
【数２】
0006325122.tif 000032
【０３５６】
ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは、上記の表２８及び表２９にそれぞれ与えられる。
【０３５７】
ロングＦＥＣＢＬＯＣＫに対してＮldpc−Ｋldpcパリティビットを計算する具体的な手順は次のとおりである。
【０３５８】
１）パリティビット初期化
【０３５９】
【数３】
0006325122.tif 000033
【０３６０】
２）パリティーチェックマトリクスのアドレスの一番目の行で特定されたパリティビットアドレスで一番目の情報ビットｉ0を累算する（ａｃｃｕｍｕｌａｔｅ）。パリティーチェックマトリクスのアドレスの詳細な内容は後述する。例えば、比率１３／１５に対して、
【０３６１】
【数４】
0006325122.tif 000034
【０３６２】
３）次の３５９個の情報ビットｉs、ｓ＝１，２，…，３５９に対して、次の式を用いてパリティビットアドレスでｉsを累算する。
【０３６３】
【数５】
0006325122.tif 000035
【０３６４】
ここで、ｘは、最初のビットｉ0に該当するパリティビット累算器のアドレスを示し、Ｑldpcは、パリティーチェックマトリクスのアドレスで特定されたコードレート（ｃｏｄｅ  ｒａｔｅ）依存定数である。上記の例である、比率１３／１５に対する、したがって情報ビットｉ1に対するＱldpc＝２４に続いて、次の動作が実行される。
【０３６５】
【数６】
0006325122.tif 000036
【０３６６】
４）３６１番目の情報ビットｉ360に対して、パリティビット累算器のアドレスは、パリティーチェックマトリクスのアドレスの２番目の行に与えられる。同様の方式で、次の３５９個の情報ビットｉs、ｓ＝３６１，３６２，…，７１９に対するパリティビット累算器のアドレスは、式６を用いて得られる。ここで、ｘは情報ビットｉ360に該当するパリティビット累算器のアドレス、すなわち、パリティーチェックマトリクスの２番目の行のエントリを示す。
【０３６７】
５）同様の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティーチェックマトリクスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めるために用いられる。
【０３６８】
全情報ビットが利用された後、最終パリティビットが次のように得られる。
【０３６９】
６）ｉ＝１から始まって次の動作を順次に実行する
【０３７０】
【数７】
0006325122.tif 000037
ここで、ｐi、ｉ＝０，１，．．．Ｎldpc−Ｋldpc−１の最終コンテンツは、パリティビットｐiと同一である。
【０３７１】
【表３０】
0006325122.tif 000038
【０３７２】
表３０を表３１に代え、ロングＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスをショートＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスに代えることを除けば、ショートＦＥＣＢＬＯＣＫに対する当該ＬＤＰＣエンコーディング手順は、ロングＦＥＣＢＬＯＣＫに対するｔ  ＬＤＰＣエンコーディング手順にしたがう。
【０３７３】
【表３１】
0006325122.tif 000039
図２０は、本発明の一実施例に係るタイムインターリービングを示す。
【０３７４】
（ａ）乃至（ｃ）は、タイムインターリービングモードの例を示す。
【０３７５】
タイムインターリーバは、データパイプレベルで動作する。タイムインターリービングのパラメータはそれぞれのデータパイプに対して別々に設定されてもよい。
【０３７６】
ＰＬＳ２−ＳＴＡＴデータの一部に現れる次のパラメータは、タイムインターリービングを構成する。
【０３７７】
ＤＰ＿ＴＩ＿ＴＹＰＥ（許容された値：０又は１）：タイムインターリービングモードを示す。０は、タイムインターリービンググループ当たりに複数のタイムインターリービングブロック（一つ以上のタイムインターリービングブロック）を有するモードを示す。この場合、一つのタイムインターリービンググループは一つのフレームに（フレーム間インターリービング無しで）直接マップされる。１は、タイムインターリービンググループ当たりに一つのタイムインターリービングブロックだけを有するモードを示す。この場合、タイムインターリービングブロックは、一つ以上のフレームにわたって拡散される（フレーム間インターリービング）。
【０３７８】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’であれば、当該パラメータは、タイムインターリービンググループ当たりのタイムインターリービングブロックの数ＮTIである。ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘１’である場合、当該パラメータは、一つのタイムインターリービンググループから拡散されるフレームの数ＰIである。
【０３７９】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容された値：０乃至１０２３）：タイムインターリービンググループ当たりのＸＦＥＣＢＬＯＣＫの最大数を示す。
【０３８０】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容された値：１，２，４，８）：与えられたフィジカルプロファイルの同一のデータパイプを伝達する２つの順次的なフレーム間のフレームの数ＩJUMPを示す。
【０３８１】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容された値：０又は１）：タイムインターリービングがデータフレームに用いられないと、当該パラメータは１に設定される。タイムインターリービングが用いられると、０に設定される。
【０３８２】
さらに、ＰＬＳ２−ＤＹＮデータからのパラメータＤＰ＿ＮＵＭ＿ＢＬＯＣＫは、データグループの一つのタイムインターリービンググループによって伝達されるＸＦＥＣＢＬＯＣＫの数を示す。
【０３８３】
タイムインターリービングがデータフレームに用いられないと、次のタイムインターリービンググループ、タイムインターリービング動作、タイムインターリービングモードは考慮されない。しかし、スケジューラからのダイナミック（動的）構成情報のためのディレイコンペセーション（遅延補償）ブロックは依然として必要である。それぞれのデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫは、タイムインターリービンググループにグルーピングされる。すなわち、それぞれのタイムインターリービンググループは整数個のＸＦＥＣＢＬＯＣＫの集合であり、ダイナミック（動的）に変化する数のＸＦＥＣＢＬＯＣＫを含むはずである。インデックスｎのタイムインターリービンググループにあるＸＦＥＣＢＬＯＣＫの数は、ＮxBLOCK_Group（ｎ）で示し、ＰＬＳ２−ＤＹＮデータでＤＰ＿ＮＵＭ＿ＢＬＯＣＫとしてシグナルされる。このとき、ＮxBLOCK_Group（ｎ）は、最小値０から、最大の値が１０２３である最大値ＮxBLOCK_Group_MAX（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに該当）まで変化してもよい。
【０３８４】
それぞれのタイムインターリービンググループは、一つのフレームに直接マップされたり、ＰI個のフレームにわたって拡散される。また、それぞれのタイムインターリービンググループは、一つ以上（ＮTI個）のタイムインターリービングブロックに分離される。ここでそれぞれのタイムインターリービングブロックは、タイムインターリーバメモリの一つの使用に該当する。タイムインターリービンググループ内のタイムインターリービングブロックは、やや異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。タイムインターリービンググループが複数のタイムインターリービンググループに分離されると、タイムインターリービンググループは一つのフレームにのみ直接マップされる。下記の表３２に示すように、タイムインターリービングには３つのオプションがある（タイムインターリービングを省略する追加オプションを除く）。
【０３８５】
【表３２】
0006325122.tif 000040
【０３８６】
一般に、タイムインターリーバは、フレーム生成手順の前にデータパイプデータに対するバッファとしても働くはずである。これは、それぞれのデータパイプに対して２個のメモリバンクによって達成される。最初のタイムインターリービングブロックは一番目のバンクに書き込まれる。一番目のバンクから読み取られる間に、２番目のタイムインターリービングブロックが２番目のバンクに書き込まれる。
【０３８７】
タイムインターリービングは、ツイストされた行−列ブロックインターリーバである。ｎ番目のタイムインターリービンググループのｓ番目のタイムインターリービングブロックに対して、列の数ＮｃがＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）と同一であるが、タイムインターリービングメモリの行の数Ｎｒは、セルの数Ｎｃｅｌｌｓと同一である（すなわち、Ｎｒ＝Ｎｃｅｌｌｓ）。
【０３８８】
図２１は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す。
【０３８９】
図２１（ａ）は、タイムインターリーバで書き込み動作を示し、図２１（ｂ）は、タイムインターリーバで読み取り動作を示す。（ａ）に示すように、一番目のＸＦＥＣＢＬＯＣＫはタイムインターリービングメモリの一番目の列に列方向に書き込まれ、二番目のＸＦＥＣＢＬＯＣＫは次の列に書き込まれ、このような動作が続けて行われる。そして、インターリービングアレイで、セルが対角線方向に読み取られる。（ｂ）に示すように、一番目の行から（最左列から始まって行に沿って右に）最後の行まで対角線方向読み取りが行われれる間に、Ｎｒ個のセルが読み取られる。具体的に、ｚｎ，ｓ，ｉ（ｉ＝０，．．．，ＮｒＮｃ）を、順次に読み取られるタイムインターリービングメモリセル位置と仮定すれば、このようなインターリービングアレイにおける読み取り動作は、下記の式のように、行インデックスＲｎ，ｓ，ｉ、列インデックスＣｎ，ｓ，ｉ、関連したツイストパラメータＴｎ，ｓ，ｉを算出することによって実行される。
【０３９０】
【数８】
0006325122.tif 000041
ここで、Ｓｓｈｉｆｔは、ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）に関係なく対角線方向読み取り手順に対する共通シフト値であり、シフト値は、下記の式のように、ＰＬＳ２−ＳＴＡＴで与えられたＮｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸによって決定される。
【０３９１】
【数９】
0006325122.tif 000042
結果的に、読み取られるセル位置は、座標ｚｎ，ｓ，ｉ＝ＮｒＣｎ，ｓ，ｉ＋Ｒｎ，ｓ，ｉによって算出される。
【０３９２】
図２２は、本発明の他の実施例に係る、ツイストされた行−列ブロックインターリーバの動作を示す。
【０３９３】
より具体的に、図２２は、ＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５のとき、仮想ＸＦＥＣＢＬＯＣＫを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリでインターリービングアレイを示す。
【０３９４】
変数ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）＝Ｎｒは、ＮｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸより小さい又は等しいだろう。したがって、ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）に関わらず、受信機側で単一メモリデインターリービングを達成するために、ツイストされた行−列ブロックインターリーバ用インターリービングアレイは、仮想ＸＦＥＣＢＬＯＣＫをタイムインターリービングメモリに挿入することによってＮｒ×Ｎｃ＝Ｎｃｅｌｌｓ×ＮｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸのサイズに設定され、読み取り過程は次の式のように行われる。
【０３９５】
【数１０】
0006325122.tif 000043
【０３９６】
タイムインターリービンググループの数は３に設定される。タイムインターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝‘１’、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝‘１’、すなわち、ＮTI＝１、ＩJUMP＝１、ＰI＝１によってＰＬＳ２−ＳＴＡＴデータでシグナルされる。それぞれＮcells＝３０であるＸＦＥＣＢＬＯＣＫのタイムインターリービンググループ当たりの数は、それぞれのＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５によってＰＬＳ２−ＤＹＮデータでシグナルされる。ＸＦＥＣＢＬＯＣＫの最大数はＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸによってＰＬＳ２−ＳＴＡＴデータでシグナルされ、
【０３９７】
【数１１】
0006325122.tif 000044
【０３９８】
図２３は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの対角線方向読み取りパターンを示す。
【０３９９】
より具体的に、図２３は、パラメータＮ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ＝７及びＳshift＝（７−１）／２＝３を有するそれぞれのインターリービングアレイからの対角線方向読み取りパターンを示す。このとき、上で擬似コードと示した読み取り過程で、
【数１２】
0006325122.tif 000045
【０４００】
図２４は、本発明の一実施例に係るそれぞれのインターリービングアレイからのインターリービングされたＸＦＥＣＢＬＯＣＫを示す。
【０４０１】
図２４は、パラメータＮ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ＝７及びＳshift＝３を有するそれぞれのインターリービングアレイからインターリーブされたＸＦＥＣＢＬＯＣＫを示す。
【０４０２】
以下では、本発明の一実施例として、実時間放送環境でファイルベースマルチメディアコンテンツを伝送するためのファイルの分割生成方法及び消費方法を説明する。
【０４０３】
具体的には、本発明の一実施例は、実時間放送環境でファイルベースマルチメディアコンテンツを伝送するためのデータ構成方案を提供する。また、本発明の一実施例は、実時間放送環境でファイルベースマルチメディアコンテンツを伝送するためのファイルの分割生成情報及び消費情報を識別する方法を提供する。また、本発明の一実施例は、実時間放送環境でファイルベースマルチメディアコンテンツを伝送するためのファイルの分割生成方法を提供する。また、本発明の一実施例は、実時間放送環境でファイルベースマルチメディアコンテンツを消費するためのファイルの分割消費方法を提供する。
【０４０４】
図２５は、ＦＬＵＴＥプロトコルを用いた場合のデータ処理時間を示す図である。
【０４０５】
近年、放送網とインターネット網とを結合したハイブリッド放送サービスが多く提供されている。ハイブリッド放送サービスは、Ａ／Ｖコンテンツを既存の放送網を介して伝送し、Ａ／Ｖコンテンツに関連した付加データをインターネット網を介して提供することができる。また、最近ではＡ／Ｖコンテンツの一部をインターネット網を介して送信するサービスも提供されている。
【０４０６】
Ａ／Ｖコンテンツが異種網で伝送されることにより、異種網で伝送されるＡ／Ｖコンテンツデータ間の緊密な結合方法及び容易な相互運用方法が要求される。そのために、放送網及びインターネット網に共に適用可能な共通の伝送方法が必要である。
【０４０７】
最近に考慮されている放送網及びインターネット網に共通に適用可能なＡ／Ｖコンテンツの伝送方法の一つは、ファイルベースマルチメディアコンテンツの使用である。ファイルベースマルチメディアコンテンツは拡張性に優れており、伝送プロトコルに対する依存性がないため、既存のインターネット網を介したダウンロード方式の形態で広く用いられている。
【０４０８】
このように、放送網とインターネット網との連動に適合しており、大容量ファイルのファイルベースマルチメディアコンテンツを送信するに適したプロトコルがＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ）である。
【０４０９】
ＦＬＵＴＥは、ＡＬＣベースで単方向ファイルを伝送するためのアプリケーションであり、ファイルを送信する上で必要なファイル自体に関する情報又は伝送のための情報について定義しておいたプロトコルである。ＦＬＵＴＥは、ファイルを送信するにあって、まず、ＦＤＴ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ）インスタンスの送信を用いて、伝送に必要な情報及び伝送するファイルの様々な属性に関する情報を送った後にファイルを伝送する。
【０４１０】
ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ）は、単一送信者が複数の受信者にファイルを送信する間に、複数のチャネルを介して信頼性及び混雑制御が可能なように標準化したプロトコルである。ＡＬＣは、誤り制御のためのＦＥＣ形成ブロック、混雑制御のためのＷＥＢＲＣ形成ブロック、セッション及びチャネル管理のためのＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）形成ブロックを結合したものであり、サービスと必要によってビルディングブロックを構成できるようになっている。
【０４１１】
ＡＬＣはコンテンツ伝達プロトコルであり、多数の受信者に非常に効率的な伝送を可能にする。また、ＡＬＣは単方向性を有すると共に、必要によって制限的伝送が可能であり、フィードバックのための特定チャネル及びリソースが不要であるため、無線環境だけでなく、衛星環境のブロードキャストでも用いることができる。ＡＬＣは、フィードバックがないため、信頼性のためにＦＥＣコードスキームを全体的に又は部分的に適用して、信頼できるサービスを提供する。また、伝達しようとするオブジェクトは、適用されるＦＥＣスキームによってＦＥＣエンコーディングを経て伝送ブロックとＦＥＣスキームによって生成された追加のシンボルを構成して伝達される。ＡＬＣのセッションは、一つ以上のチャネルで構成され、複数の受信者は、ネットワーク状態に応じてセッション内のチャネルを選択して所望のオブジェクトを受信する。受信者は自身のコンテンツ受信にのみ専念することができ、他の受信者の状態又はパケット損失にもほとんど影響を受けない。したがって、ＡＬＣは、高い堅固性を有し、マルチレイヤ（ｍｕｌｔｉ−ｌａｙｅｒｅｄ）伝送を用いて安定したコンテンツダウンロードを提供することができる。
【０４１２】
ＬＣＴは、信頼性あるコンテンツ伝送（例えば、ＦＬＵＴＥ）及びストリーム伝送プロトコルのための伝送レベルの支援を提供する。ＬＣＴは、受信者に伝達する基本的な情報の内容と特徴に関する情報を提供する。例えば、ＬＣＴは、ＴＳＩ（Ｔｒｅａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド、ＴＯＩ（Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  ＩＤ）フィールド、及びＣＣＩ（Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）フィールドを含むことができる。
【０４１３】
ＴＳＩフィールドは、ＡＬＣ／ＬＣＴセッションを識別する情報を含む。例えば、セッション内のチャネルは、送信者ＩＰアドレス及びＵＤＰポートを用いて識別することができる。ＴＯＩフィールドは、それぞれのファイルオブジェクトを識別する情報を含む。ＣＣＩフィールドは、使用の有無及び混雑制御ブロックの情報を含む。また、ＬＣＴは、拡張ヘッダーで付加情報及びＦＥＣ関連情報を提供することができる。
【０４１４】
以上のように、オブジェクト（例えば、ファイルなど）は、ＦＬＵＴＥプロトコルによってパケット化され、これはさらにＡＬＣ／ＬＣＴ方式によってパケット化される。該パケット化されたＡＬＣ／ＬＣＴデータはさらにＵＤＰ方式によってパケット化され、該パケット化されたＡＬＣ／ＬＣＴ／ＵＤＰデータはさらにＩＰ方式によってパケット化されてＡＬＣ／ＬＣＴ／ＵＤＰ／ＩＰデータとなる。
【０４１５】
ファイルベースマルチメディアコンテンツは、ＬＣＴのようなコンテンツ伝送プロトコルによってインターネット網の他、放送網でも伝送が可能である。このとき、少なくとも一つのオブジェクト又はファイルで構成されるマルチメディアコンテンツは、ＬＣＴによって、オブジェクト単位又はファイル単位で伝送及び消費されてもよい。具体的に説明すると、下記のとおりである。
【０４１６】
図２５の（ａ）を参照すると、ＦＬＵＴＥプロトコルを用いたデータ構造が示されている。例えば、マルチメディアコンテンツは、少なくとも一つのオブジェクトを含むことができる。一つのオブジェクトは、少なくとも一つのフラグメント（Ｆｒａｇｍｅｎｔ１及びＦｒａｇｍｅｎｔ２）を含むことができる。
【０４１７】
図２５の（ｂ）を参照すると、ＦＬＵＴＥプロトコルを用いた場合のデータ処理時間が示されている。図２５の（ｂ）で、下端の図は、放送信号送信装置による、一つのオブジェクトに対するエンコーディング開始時間及びエンコーディング終了時間を示しており、中間の図は、放送信号送信装置による、一つのオブジェクトに対する伝送開始時間及び伝送終了時間を示しており、上端の図は、放送信号受信装置による、一つのオブジェクトに対する再生開始時間及び再生終了時間を示している。
【０４１８】
放送信号送信装置は、少なくとも一つのフラグメントを含むオブジェクトの生成を終了した後にオブジェクトの伝送を始める。したがって、放送信号送信装置でオブジェクトを生成し始めた時点と伝送し始めた時点との間にＤt1だけの伝送待機時間が発生する。
【０４１９】
また、放送信号受信装置は、少なくとも一つのフラグメントを含むオブジェクトの受信を終了した後にオブジェクトの再生を始める。したがって、放送信号受信装置でオブジェクトを受信し始めた時点と再生し始めた時点との間にＤr1だけの再生待機時間が発生する。
【０４２０】
したがって、一つのオブジェクトが放送信号送信装置で伝送されて放送信号受信装置で再生されるまでは、伝送待機時間と再生待機時との和に該当する時間が必要である。これは、放送信号受信装置にとって該当のオブジェクトに初期接近するために非常に長い時間がかかるということを意味する。
【０４２１】
以上のように、ＦＬＵＴＥプロトコルを用いる場合、放送信号送信装置はオブジェクト単位でデータを伝送し、このため、放送信号受信装置は一つのオブジェクトに対するデータを全て受信した後に当該オブジェクトを消費せざるを得ないという限界がある。したがって、ＦＬＵＴＥプロトコルを用いたオブジェクトの伝送は実時間放送環境には向いていない。
【０４２２】
図２６は、本発明の一実施例に係るＲＯＵＴＥプロトコルスタックを示す図である。
【０４２３】
ＩＰベースハイブリッド放送を支援する次世代放送システムの放送サービスは、ビデオデータ、オーディオデータ、字幕データ、シグナリングデータ、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）データ、及び／又はＮＲＴコンテンツデータを含むことができる。
【０４２４】
ビデオデータ、オーディオデータ及び字幕データなどは、ＩＳＯベースメディアファイル（Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ）（以下、ＩＳＯ  ＢＭＦＦ）の形態でカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）することができる。例えば、ＩＳＯ  ＢＭＦＦの形態でカプセル化されたデータは、ＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）−ＤＡＳＨ（（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）のセグメント或いはＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）のＭＰＵ（Ｍｅｄｉａ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）などの形態に従うことができる。そして、ＩＳＯ  ＢＭＦＦの形態でカプセル化されたデータは、放送網とインターネット網で同一に又は各伝送網の属性によって別個に伝送することができる。
【０４２５】
放送網の場合、シグナリングデータ、ＥＳＧデータ、ＮＲＴコンテンツデータ及び／又はＩＳＯ  ＢＭＦＦの形態でカプセル化されたデータは、実時間オブジェクト伝送を支援するアプリケーション層伝送プロトコルパケットにカプセル化することができる。例えば、ＩＳＯ  ＢＭＦＦの形態でカプセル化されたデータは、ＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）及びＭＭＴの伝送パケットなどにカプセル化することができる。
【０４２６】
ＲＯＵＴＥは、ＩＰマルチキャストネットワークでファイルを伝達するためのプロトコルである。ＲＯＵＴＥプロトコルは、ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ）、大幅に拡張可能なマルチキャスト分配のために設計されたベースプロトコル、ＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）及び他の公知のインターネット標準を用いる。ＲＯＵＴＥは、追加の特徴を有するＦＬＵＴＥの向上及びそれに対する機能的代替物である。
【０４２７】
ＲＯＵＴＥは、シグナリングメッセージ、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）メッセージ及びＮＲＴコンテンツを伝達する機能を果たす。これは、ストリーミングメディア、例えば、ＭＰＥＧ−ＤＡＳＨメディアセグメントファイルの伝達に特に適している。ＲＯＵＴＥは、ＦＬＵＴＥと比較してデリバリチェーンを介して、より低いエンド−ツウ−エンドレイテンシ（ｅｎｄ−ｔｏ−ｅｎｄ  ｌａｔｅｎｃｙ）を提供する。
【０４２８】
ＲＯＵＴＥプロトコルは、任意の種類のオブジェクトの伝達のために提供される一般的な伝送アプリケーションである。これは、場面記述（ｓｃｅｎｅ  ｄｅｓｃｒｉｐｔｉｏｎ）、メディアオブジェクト及びＤＲＭ関連情報を含む豊富なプレゼンテーションを支援する。ＲＯＵＴＥは、特に実時間メディアコンテンツの伝達に適しており、多くの特徴を提供する。
【０４２９】
例えば、ＲＯＵＴＥは、別個のメディアコンポーネント、例えば、言語トラック、サブタイトル、代案のビデオビューへの個別伝達及びアクセスを提供する。また、ＲＯＵＴＥは、別個の伝送セッション又は同一のＲＯＵＴＥセッションに対する伝達を可能にすることによって階層的コーディングの支援を提供する。また、ＲＯＵＴＥは、マルチステージを含む柔軟なＦＥＣ保護に対する支援を提供する。また、ＲＯＵＴＥは、ＤＡＳＨの放送及びブロードバンド伝達モード間のＭＰＥＧ−ＤＡＳＨ可能シナジーを有する容易な組合せを提供する。また、ＲＯＵＴＥは、ＲＯＵＴＥ及び／又は伝送セッションに参加するとき、メディアへの迅速なアクセスを提供する。ＲＯＵＴＥは、伝達概念に焦点を合わせることによって大きく拡張可能である。また、ＲＯＵＴＥは、既存のＩＥＴＦプロトコルとの互換性及びＩＥＦＴ−支援（ＩＥＴＦ−ｅｎｄｏｒｓｅｄ）拡張メカニズムの使用を提供する。
【０４３０】
ＲＯＵＴＥプロトコルは２個の主要コンポーネントに分離される。第１コンポーネントは、オブジェクトの伝達又はオブジェクトのフロー／収集のためのソースプロトコルである。第２コンポーネントは、ソースプロトコルによって伝達されるデリバリオブジェクト又はデリバリオブジェクトの束（ｂｕｎｄｌｅ）を柔軟に保護するリペア（ｒｅｐａｉｒ）プロトコルである。
【０４３１】
ソースプロトコルはリペアプロトコルに独立している。すなわち、ソースプロトコルは、ＲＯＵＴＥリペアプロトコル無しで配置（ｄｅｐｌｏｙ）することができる。リペアは、所定の配置（ｄｅｐｌｏｙｍｅｎｔ）シナリオに対してのみ、例えば、所定の地理的領域内のモバイル受信、所定のサービスなどのためにのみ追加されてもよい。
【０４３２】
ソースプロトコルは、３ＧＰＰ  ＴＳ  ２６．３４６で定義された拡張だけでなく、ＲＦＣ６７２６で定義されたＦＬＵＴＥに合わせて調整されるが、例えば、オブジェクトメタデータとオブジェクトコンテンツが合成（ｃｏｍｐｏｕｎｄ）オブジェクトで併せて伝送され得るＲＦＣ６９６８で定義されたＦＣＡＳＴの一部の原理を用いる。
【０４３３】
基本ＦＬＵＴＥプロトコルに加えて、メディアデータ、それによるプロトコルの名の実時間伝達のための最適化された支援が可能な所定の最適化及び制限が追加される。特に、ソースＲＯＵＴＥプロトコルは、オブジェクトベースメディアデータの実時間伝達を提供する。また、ソースＲＯＵＴＥプロトコルは、デリバリオブジェクトの伝送認識パケット化（ｔｒａｎｓｐｏｒｔ  ａｗａｒｅ  ｐａｃｋｅｔｉｚａｔｉｏｎ）だけでなく、メディア認識パケット化のイネーブリング（ｅｎａｂｌｉｎｇ）を含めて柔軟なパケット化を提供する。また、ソースＲＯＵＴＥプロトコルは、ファイル及びデリバリオブジェクトの独立性を提供し、すなわち、デリバリオブジェクトは、ファイルの一部又はファイルのグループであってもよい。
【０４３４】
デリバリオブジェクトは、受信機がデリバリオブジェクトを回復してアプリケーションに伝達するので、このプロトコルの重要なコンポーネントである。デリバリオブジェクトは、アプリケーションに対して独立しており（ｓｅｌｆ−ｃｏｎｔａｉｎｅｄ）、一般にアプリケーションに関連した所定の特性（ｐｒｏｐｅｒｔｉｅｓ）、メタデータ及びタイミング関連情報に関連付く。任意の場合、特性は、オブジェクトと共に帯域内で（ｉｎ−ｂａｎｄ）提供され、他の場合、データは、静的又は動的方式で帯域外で（ｏｕｔ−ｏｆ−ｂａｎｄ）伝達される必要がある。デリバリオブジェクトは“ＦＤＴインスタンス”によって記述され、同伴される完全又は部分ファイルを含むことができる。また、デリバリオブジェクトは、ＨＴＴＰエンティティ（ＨＴＴＰエンティティヘッダー及びＨＴＴＰエンティティボディー）及び／又はデリバリオブジェクトのパッケージを含むことができる。
【０４３５】
デリバリオブジェクトは、ＦＤＴインスタンスと共に全体ファイル又はファイルのバイト範囲であってもよい。デリバリオブジェクトは、実時間又は非実時間（時間制限伝達又は非時間制限伝達）で伝達することができる。時間制限であれば、所定の実時間及びバッファ制限が適用され、特定拡張ヘッダーが用いられてもよい。動的及び静的メタデータは、デリバリオブジェクト特性を記述するために用いることができる。デリバリオブジェクトは、特定データ構造、特に、ＩＳＯ  ＢＭＦＦ構造で伝達することができる。この場合、メディア認識パケット化又は一般的なパケット化が適用されてもよい。
【０４３６】
デリバリフォーマットは、アプリケーションに情報を提供するためにどのフォーマットが用いられるかを特定する。
【０４３７】
ＲＯＵＴＥリペアプロトコルはＦＥＣベースであり、伝送層（例えば、ＵＤＰ）及びオブジェクトデリバリ層プロトコル間の追加層として利用可能である。ＦＥＣは、ＲＦＣ６３６３に定義されたＦＥＣフレームワークの概念を再利用するが、ＲＦＣ６３６３のＦＥＣフレームワークとは違い、ＲＯＵＴＥリペアプロトコルはパケットを保護しなく、その代わりに、ソースプロトコルで伝達されたデリバリオブジェクトを保護する。各ＦＥＣソースブロックは、（ＦＬＵＴＥと類似の）単一デリバリオブジェクトのように又はＦＥＣ保護の前にバンドリングされた複数のデリバリオブジェクトによってデリバリオブジェクトの一部として構成されてもよい。ＲＯＵＴＥ  ＦＥＣは、ＲＦＣ５０５２で定義されたものと類似の意味でＦＥＣスキームを利用し、その文書の用語を使う。ＦＥＣスキームは、ＦＥＣエンコーディング及びデコーディングを定義し、ＦＥＣスキームのコンテクストでパケットペイロードデータを識別するために用いられるプロトコルフィールド及び手順を定義する。
【０４３８】
ＲＯＵＴＥで、全パケットは、ＲＦＣ５６５１で定義されたＬＣＴパケットである。ソース及びリペアパケットは、ＲＯＵＴＥセッション、ＬＣＴ伝送セッション及び／又はＰＳＩビットのうち少なくとも一つによって区別することができる。別個のＲＯＵＴＥセッションは別個のＩＰ／ＵＤＰポート組合せ上で送信される。別個のＬＣＴ伝送セッションは、ＬＣＴヘッダーで別個のＴＳＩ値を用いる。また、ソース及びリペアパケットが同一のＬＣＴ伝送セッションで伝送されると、ＬＣＴ内のＰＳＩビットによって区別可能である。動作のこのモードは、ＦＬＵＴＥ互換可能配置に最も適している。
【０４３９】
ＲＯＵＴＥは、挙動（ｂｅｈａｖｉｏｒ）を伝送及び受信しながら、パケットフォーマットを含むソースプロトコルを定義する。また、ＲＯＵＴＥはリペアプロトコルを定義する。また、ＲＯＵＴＥは、伝送セッション確立のためのメタデータ及びオブジェクトフロー伝達のためのメタデータを定義する。また、ＲＯＵＴＥは、ＭＰＥＧ  ＤＡＳＨ設定及びＲＯＵＴＥへのマッピングに対する推薦を定義し、豊富な高品質の線形ＴＶ放送サービスを可能にする。
【０４４０】
ＲＯＵＴＥプロトコルの範囲は、ＬＣＴパケットを用いたデリバリオブジェクト及び関連したメタデータの信頼性ある伝達である。オブジェクトは、デリバリオブジェクトキャッシュ（Ｄｅｌｉｖｅｒｙ  Ｏｂｊｅｃｔ  Ｃａｃｈｅ）を介してプリケーションに利用可能である。このキャッシュの具現は、アプリケーションとは独立している。
【０４４１】
ＲＯＵＴＥプロトコルは、デリバリオブジェクトを伝達するＬＣＴパケットのフォーマット及びＦＥＣに基づいたリペアプロトコルを用いたデリバリオブジェクトの信頼性ある伝達に焦点を合わせる。また、ＲＯＵＴＥプロトコルは、デリバリオブジェクトと共にオブジェクトメタデータの定義及び伝達に焦点を合わせてデリバリオブジェクトキャッシュ及びアプリケーション間のインターフェースを可能にする。また、ＲＯＵＴＥプロトコルは、ＲＯＵＴＥ及びＬＣＴセッション記述に焦点を合わせて、そのメタデータと共にオブジェクトの受信を確立する。また、ＲＯＵＴＥプロトコルは、パケットと共に伝達される補助情報の規範的形態（ｎｏｒｍａｔｉｖｅ  ａｓｐｅｃｔｓ）（フォーマット、セマンティクス）に焦点を合わせて、特定のアプリケーションに対する性能、例えば、実時間伝達を最適化する。
【０４４２】
また、ＲＯＵＴＥプロトコルは、伝達に用いられる適切なＤＡＳＨフォーマットだけでなく、ＲＯＵＴＥ伝達への特定ＤＡＳＨメディアプレゼンテーションの推薦マッピングを提供する。重要な問題は、ＲＯＵＴＥを用いてＤＡＳＨメディアフォーマットがそのまま用いられうるということである。このアーキテクチャ設計は、集中した（ｃｏｎｖｅｒｇｅｄ）ユニキャスト／ブロードキャストサービスを可能にする。
【０４４３】
ＲＯＵＴＥプロトコルの伝送者動作において、ＬＣＴパケットを伝達するＲＯＵＴＥセッションが確立される。これらのパケットは、ソースオブジェクト又はＦＥＣリペアデータを伝送することができる。ソースプロトコルは、一つ以上のＬＣＴセッションで構成され、ＬＣＴセッションのそれぞれは、自身のメタデータと共に、関連したオブジェクトを伝達する。メタデータは、エンティティモード内の合成オブジェクトとして又はパケットヘッダー内のＬＣＴ拡張ヘッダーとして、ＬＳＩＤ（ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）で静的又は動的に伝達されてもよい。パケットは、任意のバイト境界でオブジェクトの柔軟なフラグメンテーションを許容する特定ＦＥＣスキームを用いてＡＬＣで伝達される。また、デリバリオブジェクトは、個別的に又はバンドリングされてＦＥＣ保護されてもよい。いずれの場合にも、バンドリングされたオブジェクトはエンコードされ、リペアパケットだけが伝達される。ソースパケットと結合し、これは回復デリバリオブジェクトバンドルを許容する。例えば、それぞれ別個の特性を有する１つ又は複数のリペアフローが生成され、別個のレイテンシ要求事項、別個の保護要求事項などを支援することができる。
【０４４４】
ＤＭＤ（Ｄｙｎａｍｉｃ  ＭｅｔａＤａｔａ）は、クライアントで動的にＦＤＴ同等記述（ｅｑｕｉｖａｌｅｎｔ  ｄｅｓｃｒｉｐｔｉｏｎ）を生成するメタデータである。これは、エンティティモードではエンティティヘッダーで伝送され、他の伝達モードではＬＣＴヘッダーで送信される。
【０４４５】
ＲＯＵＴＥプロトコルは、ソースデータの別個の保護及び伝達スキームを支援する。これはまた、逆互換性モードで配置されてもよいため、ＮＲＴ伝達のための既存のいずれの使用の場合をも支援する。
【０４４６】
ＲＯＵＴＥセッションは、ＩＰアドレス／ポート組合せに関連付く。一般に、このようなセッションを参加させることによって、セッションの全パケットを受信することができ、アプリケーションプロトコルを追加のプロセシングに適用することができる。それぞれのＲＯＵＴＥセッションは、１つ又は複数のＬＣＴ伝送セッションで構成される。ＬＣＴ伝送セッションは、ＲＯＵＴＥセッションのサブセットである。メディア伝達のために、ＬＣＴ伝送セッションは一般に、メディアコンポーネント、例えば、ＤＡＳＨリプレゼンテーションを伝送する。ブロードキャストＤＡＳＨの観点で、ＲＯＵＴＥセッションは、一つ以上のＤＡＳＨメディアプレゼンテーションの構成メディアコンポーネントを伝達するＬＣＴ伝送セッションのマルチプレクスとして見なされてもよい。各ＬＣＴ伝送セッション内で、１つ又は複数のオブジェクト、一般に、関連したオブジェクト、例えば、一つのプレゼンテーションと関連したＤＡＳＨセグメントが送信される。それぞれのオブジェクトと共に、メタデータ特性は、オブジェクトがアプリケーションに用いられ得るように伝達される。アプリケーションは、制限されないが、ＤＡＳＨメディアプレゼンテーション、ＨＴＭＬ−５プレゼンテーション又は任意の他のオブジェクト消費（ｏｂｊｅｃｔ−ｃｏｎｓｕｍｉｎｇ）アプリケーションを含む。
【０４４７】
ＲＯＵＴＥセッションは、時間的に制限されてもよく、制限されなくてもよい。ＲＯＵＴＥセッションは、１つ又は複数のＬＣＴ伝送セッションを含む。それぞれの伝送セッションは、ＬＣＴヘッダー内の固有ＴＳＩ（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）値によって固有に識別される。
【０４４８】
受信機がＲＯＵＴＥセッションに参加する前に、受信機はＲＯＵＴＥセッション記述（ｄｅｓｃｒｉｐｔｉｏｎ）を得る必要がある。ＲＯＵＴＥセッション記述は、伝送者ＩＰアドレス、セッションに用いられるアドレス及びポート番号、セッションがＲＯＵＴＥセッションであり、全パケットがＬＣＴパケットであるという指示、及び／又はＩＰ／ＵＤＰレベルでセッションに参加して消費する上で必須である他の情報のうち少なくとも一つを含む。
【０４４９】
セッション記述はまた、制限的ではないが、ＲＯＵＴＥセッションに用いられるデータレート及びＲＯＵＴＥセッションのデューレーション（ｄｕｒａｔｉｏｎ）に関する任意の情報を含むことができる。
【０４５０】
セッション記述は、ＲＦＣ４５６６に定義されたＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）又はＲＦＣ３０２３に定義されたＸＭＬメタデータなどの形態であってもよい。これは、登録セッション制御プロトコル（ｐｒｏｐｒｉｅｔａｒｙ  ｓｅｓｓｉｏｎ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ）を用いて任意のセッション発表プロトコル（ｓｅｓｓｉｏｎ  ａｎｎｏｕｎｃｅｍｅｎｔ  ｐｒｏｔｏｃｏｌ）で伝送されてもよく、スケジューリング情報と共にウェブページ上に位置してもよく、イーメール又は帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）方法によって伝達されてもよい。
【０４５１】
伝送セッションは、ＲＯＵＴＥセッション記述に記述されず、ＬＳＩＤ（ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）に記述される。伝送セッション（すなわち、ＬＣＴセッション又は簡単にＬＣＴセッション）は、ソースフロー及びリペアフローのいずれか一方又は両方を含むことができる。ソースフローはソースデータを伝送する。また、リペアフローはリペアデータを伝送する。
【０４５２】
ＲＯＵＴＥセッションに含まれるＬＣＴ伝送セッションは、ＬＳＩＤによって記述される。特に、ＲＯＵＴＥセッションの各構成ＬＣＴ伝送セッションで伝送されると定義する。それぞれの伝送セッションは、ＬＣＴヘッダー内のＴＳＩによって固有に識別される。
【０４５３】
ＬＳＩＤは、このＲＯＵＴＥセッション上で伝送される全ての伝送セッションを記述する。ＬＳＩＤは、ＬＣＴ伝送セッションを含む同じＲＯＵＴＥセッションで伝達されてもよく、ＲＯＵＴＥセッション以外の手段によって、例えば、ユニキャスト又は別個のＲＯＵＴＥセッションで伝達されてもよい。前者の場合、ＬＳＩＤは、ＴＳＩ＝０を有する専用ＬＣＴ伝送セッション上で伝達され、また、ＴＯＩ＝０によって識別されたデリバリオブジェクトであろう。ＴＳＩ＝０上で伝達される任意のオブジェクトに対して、エンティティモードを使用しなければならない。それらのオブジェクトがエンティティモードで伝達されないと、ＬＳＩＤは、受信されたオブジェクトに対する拡張されたＦＤＴを得る前に回復されなければならない。
【０４５４】
ＬＳＩＤのインターネットメディアタイプは、ａｐｐｌｉｃａｔｉｏｎ／ｘｍｌ＋ｒｏｕｔｅ＋ｌｓｉｄである。
【０４５５】
ＬＳＩＤは、他のデータフラグメントを参照することができる。ＬＳＩＤで参照される任意のオブジェクトはまた、ＴＳＩ＝０上でＬＳＤＩ自体よりはＴＯＩのそれぞれ異なる値をもって伝達されてもよく、専用ＴＳＩ≠０を有する別途のＬＣＴセッション上で伝達されてもよい。
【０４５６】
ＬＳＩＤエレメントは、バージョン属性、有効性属性及び／又は満了属性を含むことができる。したがって、ＬＳＩＤエレメントを有効性属性及び満了属性の他、バージョン属性も用いてアップデートすることができる。例えば、所定の伝送セッションは、任意の時間後に終了すればよく、新しいセッションを開始することができる。
【０４５７】
バージョン属性は、このＬＳＩＤエレメントのバージョンを示す。バージョンは、記述語がアップデートされる都度、１ずつ増加する。最も高いバージョン番号を有する受信されたＬＳＩＤエレメントが、現在有効なバージョンである。
【０４５８】
有効性属性は、ＬＳＩＤエレメントが有効である日付及び／又は時間を示す。有効性属性は存在してもよく、存在しなくてもよい。存在しないと、受信機は、ＬＳＩＤエレメントバージョンが直ちに有効であると仮定しなければならない。
【０４５９】
満了属性は、ＬＳＩＤエレメントが満了する日付及び時間を示す。満了属性は存在してもしなくてもよい。存在しないと、受信機は、ＬＳＩＤエレメントが全時間において又は関連した満了値を有する、より新しいＬＳＩＤエレメントが受信されるまで有効であると仮定しなければならない。
【０４６０】
ＬＳＩＤエレメントは、少なくとも一つのＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎエレメントを含むことができる。ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎエレメントは、ＬＣＴ伝送セッションに関する情報を提供する。それぞれのＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎエレメントは、ｔｓｉ属性、ＳｏｕｒｃｅＦｌｏｗエレメント及び／又はＲｅｐａｉｒＦｌｏｗエレメントを含むことができる。
【０４６１】
ｔｓｉ属性は、伝送セッション識別子を特定する。セッション識別子は０であってはならない。ＳｏｕｒｃｅＦｌｏｗエレメントは、伝送セッション上で伝達されるソースフローの情報を提供する。ＲｅｐａｉｒＦｌｏｗエレメントは、伝送セッション上で伝送されるリペアフローの情報を提供する。
【０４６２】
その後、アプリケーション層伝送プロトコルパケットにカプセル化されたデータは、ＩＰ／ＵＤＰ方式によってパケット化されてもよい。ＩＰ／ＵＤＰ方式によってパケット化されたデータはＩＰ／ＵＤＰデータグラムといえるできるが、ＩＰ／ＵＤＰデータグラムは放送信号に含まれて伝送されてもよい。
【０４６３】
インターネット網の場合、ＩＳＯ  ＢＭＦＦの形態でカプセル化されたデータは、ストリーミング技法に基づいて受信側に伝達されてもよい。例えば、ストリーミング技法は、ＭＰＥＧ−ＤＡＳＨを含むことができる。
【０４６４】
シグナリングデータは、下記のような方法で伝送することができる。
【０４６５】
放送網の場合、シグナリングデータは、シグナリングの属性にしたがって、次世代放送伝送システム及び放送網の物理層に伝達される伝送フレーム（又はフレーム）の特定データパイプ（以下ＤＰ）などで伝送することができる。例えば、シグナリング形態は、ビットストリーム又はＩＰ／ＵＤＰデータグラムにカプセル化された形態であってもよい。
【０４６６】
インターネット網の場合、シグナリングデータは、受信機の要求に対する応答としてリターンして伝達されてもよい。
【０４６７】
ＥＳＧデータ及びＮＲＴコンテンツデータは、下記のような方法で伝送することができる。
【０４６８】
放送網の場合、ＥＳＧデータ及びＮＲＴコンテンツデータは、アプリケーション層伝送プロトコルパケットにカプセル化することができる。その後、アプリケーション層伝送プロトコルパケットにカプセル化されたデータを、上述した方式と同様に伝送することができる。
【０４６９】
インターネット網の場合、ＥＳＧデータ及びＮＲＴコンテンツデータは、受信機の要求に対する応答としてリターンして伝達されてもよい。
【０４７０】
本発明の一実施例に係る放送信号送信装置の物理層（ブロードキャストＰＨＹ及びブロードバンドＰＨＹ）は、前述した図１に示す構造であってもよい。また、放送信号受信装置の物理層は、図９に示す構造であってもよい。
【０４７１】
シグナリングデータ及びＩＰ／ＵＤＰデータグラムは、物理層に伝達される伝送層（又はフレーム）の特定データパイプ（以下ＤＰ）で伝送することができる。例えば、入力フォーマットブロック１０００は、シグナリングデータ及びＩＰ／ＵＤＰデータグラムを受信し、それぞれのシグナリングデータ及びＩＰ／ＵＤＰデータグラムを少なくとも一つのＤＰに逆多重化することができる。出力プロセッサ９３００は、入力フォーマットブロック１０００と逆の動作を行うことができる。
【０４７２】
以下では、上述したＩＳＯ  ＢＭＦＦの形態でカプセル化されたデータがＲＯＵＴＥの伝送パケットにカプセル化された場合を中心に説明する。
【０４７３】
＜実時間ファイル生成、消費のためのデータ構成＞
図２７は、本発明の一実施例に係るファイルベースマルチメディアコンテンツのデータ構造を示す図である。
【０４７４】
図２７を参照すると、本発明の一実施例に係るファイルベースマルチメディアコンテンツのデータ構造が示されている。ファイルベースマルチメディアコンテンツとは、少なくとも一つのファイルで構成されているマルチメディアコンテンツを意味する。
【０４７５】
放送プログラムのようなマルチメディアコンテンツは、一つのプレゼンテーション（ｐｒｅｓｅｎｔａｔｉｏｎ）で構成することができる。プレゼンテーションは、少なくとも一つのオブジェクト（ｏｂｊｅｃｔ）を含むことができる。例えば、オブジェクトはファイルであってもよい。また、オブジェクトは、少なくとも一つのフラグメント（ｆｒａｇｍｅｎｔ）を含むことができる。
【０４７６】
本発明の一実施例に係るフラグメントとは、以前（ｐｒｅｃｅｄｉｎｇ）のデータに対する依存性無しで独立して復号化及び再生され得るデータ単位を意味する。例えば、ビデオデータを含むフラグメントは、ＩＤＲ  Ｐｉｃｔｕｒｅで開始し、メディアデータのパーシング（ｐａｒｓｉｎｇ）のためのヘッダー（ｈｅａｄｅｒ）データも以前（ｐｒｅｃｅｄｉｎｇ）のフラグメントに対して依存性を有しない。本発明の一実施例に係るフラグメントは、少なくとも一つの伝送ブロック単位で分割して伝送することができる。
【０４７７】
本発明の一実施例に係る伝送ブロックは、以前（ｐｒｅｃｅｄｉｎｇ）のデータに対する依存性無しで独立して符号化及び伝送され得る最小のデータ単位を意味する。また、伝送ブロックは、可変サイズのＧＯＰ単位又はチャンク単位からなる有意なデータ単位であってもよい。例えば、伝送ブロックは、ビデオデータのＧＯＰのように、同一のメディアデータで構成される少なくとも一つのチャンク（ｃｈｕｎｋ）を含むことができる。チャンクとは、コンテンツのセグメントを意味することができる。また、伝送ブロックは、少なくとも一つのソースブロックを含むことができる。
【０４７８】
ＧＯＰは、ビデオコーディングで用いられるコーディングを行う基本単位であり、少なくとも一つのＩ−フレームを含むフレームの集合を示す可変サイズのデータ単位である。本発明の一実施例によれば、メディアデータを独立して有意なデータ単位であるオブジェクト内部構造体の単位で伝送するので、ＧＯＰはオープンＧＯＰ及びクローズドＧＯＰを含むことができる。
【０４７９】
オープンＧＯＰで、一つのＧＯＰ内にあるＢ−フレームは、隣接したＧＯＰのＩ−フレーム又はＰ−フレームを参照することができる。したがって、オープンＧＯＰは、コーディング効率を非常に高めることができる。クローズドＧＯＰで、Ｂ−フレーム又はＰ−フレームは、当該ＧＯＰ内にあるフレームだけを参照し、該当ＧＯＰ外にあるフレームは参照しない。
【０４８０】
伝送ブロックは、少なくとも一つのデータを含むことができ、それぞれのデータは同一又は別個のメディアタイプを有することができる。例えば、メディアタイプはオーディオタイプ及びビデオタイプを含むことができる。すなわち、伝送ブロックは、オーディオ及びビデオの場合のようにそれぞれ異なるメディアタイプを有する少なくとも一つのデータを共に含むことができる。
【０４８１】
本発明の一実施例に係るフラグメントは、フラグメントヘッダー及びフラグメントペイロードを含むことができる。
【０４８２】
フラグメントヘッダー（ｈｅａｄｅｒ）は、上述したチャンクをパースするためのタイミング（ｔｉｍｉｎｇ）情報及びインデクシング（ｉｎｄｅｘｉｎｇ）情報などを含むことができる。そして、フラグメントヘッダーは少なくとも一つの伝送ブロックで構成されてもよい。例えば、フラグメントヘッダーは、一つの伝送ブロックに含まれてもよい。また、フラグメントペイロードを構成する少なくとも一つのチャンクデータも少なくとも一つの伝送ブロックにそれぞれ含まれてもよい。上述したように、フラグメントヘッダー及びフラグメントペイロードは少なくとも一つの伝送ブロックにそれぞれ含まれてもよい。
【０４８３】
本発明の一実施例に係る伝送ブロックは、少なくとも一つのシンボル（ｓｙｍｂｏｌ）に分割することができる。少なくとも一つのシンボルはパケット化されてもよい。例えば、本発明の一実施例に係る放送信号送信装置は、少なくとも一つのシンボルをＬＣＴパケットにパケット化することができる。
【０４８４】
本発明の一実施例に係る放送信号送信装置は、パケット化されたデータを放送信号受信装置に伝送することができる。
【０４８５】
図２８は、本発明の一実施例に係るデータ構造を適用したＭＰＥＧ−ＤＡＳＨのメディアセグメント構成を示す図である。
【０４８６】
図２８を参照すると、本発明の一実施例に係るデータ構造をＭＰＥＧ−ＤＡＳＨのメディアセグメント（Ｍｅｄｉａ  Ｓｅｇｍｅｎｔ）に適用した実施例が示されている。
【０４８７】
本発明の一実施例に係る放送信号送信装置は、サーバーに複数の品質を有しているマルチメディアコンテンツを保有し、ユーザの放送環境及び放送信号受信装置の環境に適したマルチメディアコンテンツを提供することによって、シームレスな実時間ストリーミングサービスを提供することができる。例えば、放送信号送信装置は、ＭＰＥＧ−ＤＡＳＨを用いて実時間ストリーミングサービスを提供することができる。
【０４８８】
放送信号送信装置は、ＸＭＬ形態のＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）及び二進化フォーマット形態の伝送用マルチメディアコンテンツであるセグメント（Ｓｅｇｍｅｎｔ）を、ＲＯＵＴＥプロトコルを用いて放送信号受信装置に放送環境及び放送信号受信装置の環境に応じて動的に伝送することができる。
【０４８９】
ＭＰＤは階層的な構造となっており、各階層別の構造的機能及び役割などに関する情報を含むことができる。
【０４９０】
セグメントはメディアセグメントを含むことができる。メディアセグメントは、ストリーミングサービスを支援するために放送信号受信装置に伝送しようとする品質別、時間別に分離したメディア関連オブジェクト形態のデータ単位を意味する。メディアセグメントは、メディアストリームの情報、少なくとも一つのアクセスユニット、プレゼンテーション時間又はインデックスのような当該セグメント内のメディアプレゼンテーションへの接近方法に関する情報を含むことができる。また、メディアセグメントは、セグメントインデックスによって少なくとも一つのサブセグメントに分割されてもよい。
【０４９１】
ＭＰＥＧ−ＤＡＳＨコンテンツは、少なくとも一つのメディアセグメントを含むことができる。メディアセグメントは、少なくとも一つのフラグメントを含むことができる。例えば、フラグメントは、上述したサブセグメントであってもよい。上述したように、フラグメントは、フラグメントヘッダー及びフラグメントペイロードを含むことができる。
【０４９２】
フラグメントヘッダーは、セグメントインデックスボックス（ｓｉｄｘ）及びムービーフラグメントボックス（ｍｏｏｆ）を含むことができる。セグメントインデックスボックスは、当該フラグメントの内部に存在するメディアデータの最初のプレゼンテーション時間、データオフセット（ｏｆｆｓｅｔ）及びＳＡＰ（Ｓｔｒｅａｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔｓ）情報などを提供することができる。ムービーフラグメントボックスは、メディアデータボックス（ｍｄａｔ）に対するメタデータを含むことができる。例えば、ムービーフラグメントボックスは、フラグメント内メディアデータサンプル（ｓａｍｐｌｅ）のタイミング、インデクシング、デコーディング（ｄｅｃｏｄｉｎｇ）情報などを含むことができる。
【０４９３】
フラグメントペイロードは、メディアデータボックス（ｍｄａｔ）を含むことができる。メディアデータボックス（ｍｄａｔ）は、当該メディア構成要素（ビデオ及びオーディオなど）に対する実際メディアデータを含むことができる。
【０４９４】
符号化されたメディアデータは、フラグメントペイロードに該当するメディアデータボックス（ｍｄａｔ）内にチャンク単位で含まれる。上述したように、同一トラック（ｔｒａｃｋ）に該当するサンプルは、一つのチャンク内に含まれてもよい。
【０４９５】
放送信号送信装置は、フラグメントを分割して少なくとも一つの伝送ブロックを生成することができる。また、放送信号送信装置は、フラグメントヘッダーとペイロードデータとを区分するために、フラグメントヘッダーとペイロードデータを別個の伝送ブロックに含めることができる。
【０４９６】
また、放送信号送信装置は、フラグメントペイロード内のデータを分割して伝送するためにチャンク単位で区画された伝送ブロックを生成することができる。すなわち、本発明の一実施例に係る放送信号送信装置は、チャンクの境界と伝送ブロックの境界地点とが一致するように伝送ブロックを生成することができる。
【０４９７】
その後、放送信号送信装置は、少なくとも一つの伝送ブロックを分割して少なくとも一つのシンボルを生成することができる。オブジェクト内の全シンボルの長さは同一であってもよい。また、オブジェクト内の全シンボルの長さを同一にするために、伝送ブロックの最後のシンボルはパディング（ｐａｄｄｉｎｇ）バイトを含んでもよい。
【０４９８】
その後、放送信号送信装置は、少なくとも一つのシンボルをパケット化することができる。例えば、放送信号送信装置は、少なくとも一つのシンボルに基づいてＬＣＴパケットを生成することができる。
【０４９９】
その後、放送信号送信装置は、生成されたＬＣＴパケットを伝送することができる。
【０５００】
本発明の一実施例に係る放送信号送信装置は、フラグメントを生成するために、まずフラグメントペイロードを生成した後に、フラグメントヘッダーを生成する。このとき、放送信号送信装置は、フラグメントペイロード内のメディアデータに該当する伝送ブロックを生成することができる。例えば、メディアデータボックス（ｍｄａｔ）に含まれたメディアデータに該当する少なくとも一つの伝送ブロックは、チャンク単位で順次に生成することができる。その後、放送信号送信装置は、フラグメントヘッダーに該当する伝送ブロックを生成することができる。
【０５０１】
放送信号送信装置は、メディアコンテンツを実時間放送で伝送するために、生成された伝送ブロックを生成順で伝送することができる。逆に、本発明の一実施例に係る放送信号受信装置は、フラグメントヘッダーをまずパースした後に、フラグメントペイロードをパースする。
【０５０２】
放送信号送信装置は、メディアデータがあらかじめエンコードされたり、又は伝送ブロックがあらかじめ生成された場合には、パーシング順で伝送することができる。
【０５０３】
図２９は、本発明の一実施例に係るＲＯＵＴＥプロトコルを用いたデータ処理時間を示す図である。
【０５０４】
図２９の（ａ）を参照すると、本発明の一実施例に係るデータ構造が示されている。マルチメディアデータは、少なくとも一つのオブジェクトを含むことができる。それぞれのオブジェクトは、少なくとも一つのフラグメントを含むことができる。例えば、一つのオブジェクトは、２個のフラグメント（Ｆｒａｇｍｅｎｔ１及びＦｒａｇｍｅｎｔ２）を含むことができる。
【０５０５】
放送信号送信装置はフラグメントを少なくとも一つの伝送ブロックに分割することができる。伝送ブロックはソースブロックであってもよく、以下ではソースブロックを基準に説明する。
【０５０６】
例えば、放送信号送信装置は、フラグメント１を３個のソースブロック（Ｓｏｕｒｃｅ  Ｂｌｏｃｋ  ０，Ｓｏｕｒｃｅ  Ｂｌｏｃｋ  １，Ｓｏｕｒｃｅ  Ｂｌｏｃｋ  ２）に分割し、フラグメント２を３個のソースブロック（Ｓｏｕｒｃｅ  Ｂｌｏｃｋ  ３，Ｓｏｕｒｃｅ  Ｂｌｏｃｋ  ４，Ｓｏｕｒｃｅ  Ｂｌｏｃｋ  ５）に分割することができる。
【０５０７】
放送信号送信装置は、分割されたそれぞれのソースブロックを個別的に伝送することができる。放送信号送信装置は、それぞれのソースブロックが生成された時点又はその直後に生成されたそれぞれのソースブロックの伝送を開始することができる。
【０５０８】
例えば、放送信号送信装置は、ソースブロック０（Ｓ0）をｔe0〜ｔe1時間で生成した後に、ソースブロック０（Ｓ0）を伝送することができる。ソースブロック０（Ｓ0）の伝送開始時点（ｔd0）は、ソースブロック０（Ｓ0）の生成完了時点（ｔd0）と同一又は直後であってもよい。同一の方法で、放送信号送信装置はソースブロック１（Ｓ1）乃至ソースブロック５（Ｓ5）を生成し、生成されたそれぞれのソースブロックを伝送することができる。
【０５０９】
したがって、本発明の一実施例に係る放送信号送信装置では、一つのソースブロックを生成し始めた時点と伝送し始めた時点との間にＤt2だけの伝送待機時間が発生し得る。本発明の一実施例に係る放送信号送信装置で発生する伝送待機時間（Ｄt2）は、従来の放送信号送信装置で発生する伝送待機時間（Ｄt1）に比べてだいぶ減少したものである。したがって、本発明の一実施例に係る放送信号送信装置は、従来の放送信号送信装置に比べて伝送待機時間を減らすことができるという効果がある。
【０５１０】
本発明の一実施例に係る放送信号受信装置は、分割されたそれぞれのソースブロックを受信し、受信したソースブロックを組み合わせて少なくとも一つのフラグメントを生成することができる。例えば、放送信号受信装置は、ソースブロック０（Ｓ0）、ソースブロック１（Ｓ1）、及びソースブロック２（Ｓ2）を受信し、受信した３個のソースブロックを組み合わせてフラグメント１を生成することができる。また、放送信号受信装置は、ソースブロック３（Ｓ3）、ソースブロック４（Ｓ4）、及びソースブロック５（Ｓ5）を受信し、受信した３個のソースブロックを組み合わせてフラグメント２を生成することができる。
【０５１１】
本発明の一実施例に係る放送信号受信装置は、生成されたそれぞれのフラグメントを個別的に再生することができる。放送信号受信装置は、それぞれのフラグメントが生成された時点又は直後に生成されたそれぞれのフラグメントを再生することができる。又は、放送信号受信装置は、それぞれのフラグメントに該当するソースブロックが全て送信された時点又は直後にそれぞれのフラグメントを再生することができる。
【０５１２】
例えば、放送信号受信装置は、ソースブロック０（Ｓ0）乃至ソースブロック２（Ｓ2）をｔd0〜ｔd3時間で受信した後に、フラグメント１を生成することができる。その後、放送信号受信装置は、生成されたフラグメント１を再生することができる。フラグメント１の再生開始時点（ｔp0）は、フラグメント１の生成時点と同一又は直後であってもよい。また、フラグメント１の再生開始時点（ｔp0）は、ソースブロック２（Ｓ2）の受信完了時点（ｔd3）と同一又は直後であってもよい。
【０５１３】
同一の方法で、本発明の一実施例に係る放送信号受信装置は、ソースブロック３（Ｓ3）乃至ソースブロック５（Ｓ5）をｔd3〜ｔd6時間で受信した後に、フラグメント２を生成することができる。その後、放送信号受信装置は、生成されたフラグメント２を再生することができる。
【０５１４】
ただし、これに限定されず、本発明の一実施例に係る放送信号受信装置は、ソースブロックを受信し、受信されたソースブロック単位で再生してもよい。
【０５１５】
したがって、本発明の一実施例に係る放送信号受信装置では、一つのフラグメントを受信し始めた時点と再生し始めた時点との間にＤr2だけの再生待機時間が発生しうる。本発明の一実施例に係る放送信号受信装置で発生する再生待機時間（Ｄr2）は、従来の放送信号受信装置で発生する再生待機時間（Ｄr1）に比べてだいぶ減少したものである。したがって、本発明の一実施例に係る放送信号受信装置は、従来の放送信号受信装置に比べて再生待機時間を減らすことができるという効果がある。
【０５１６】
以上のように、一つの伝送ブロックが放送信号送信装置から伝送されて放送信号受信装置で再生されるまでの時間である伝送待機時間と再生待機時との和をだいぶ減らすことができる。これは、放送信号受信装置にとって該当のオブジェクトへの初期接近時間がだいぶ短縮するということを意味する。
【０５１７】
ＲＯＵＴＥプロトコルを用いる場合、放送信号送信装置は、伝送ブロック単位でデータを伝送することができ、放送信号受信装置は、受信されたデータを伝送ブロック単位又はフラグメント単位で再生することができる。その結果、マルチメディアコンテンツの取得からユーザに表示するまでの総時間を短縮することができ、ユーザが放送チャネルに接近した時の初期接近時間を減らすことができる。
【０５１８】
したがって、ＲＯＵＴＥプロトコルを用いた伝送ブロックの伝送は、実時間放送環境に適している。
【０５１９】
＜ファイル分割生成、消費情報の識別方案＞
図３０は、本発明の一実施例に係るファイルを伝送するためのＬＣＴパケットの構造を示す図である。
【０５２０】
アプリケーション層伝送セッションは、ＩＰアドレス及びポート番号の組合せで構成することができる。アプリケーション層伝送セッションがＲＯＵＴＥプロトコルである場合、ＲＯＵＴＥセッションは少なくとも一つのＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）セッションで構成されてもよい。例えば、一つのＬＣＴ伝送セッションで一つのメディアコンポーネントを伝達する場合、一つのアプリケーション層伝送セッションで少なくとも一つのメディアコンポーネントをマルチプレクスして伝送することができる。また、一つのＬＣＴ伝送セッションで少なくとも一つの伝送オブジェクト（Ｔｒａｎｓｐｏｒｔ  ｏｂｊｅｃｔ）を伝達することができる。
【０５２１】
図３０を参照すると、アプリケーション層伝送プロトコルがＬＣＴに基づく場合、ＬＣＴパケットの各フィールドは次のような情報を示す。
【０５２２】
ＬＣＴパケットは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、予約フィールド（Ｒ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、伝送者現在時間存在フラグフィールド（Ｔ）、予想レジデュアル時間存在フラグ（Ｒ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー延長フィールド、ＦＥＣペイロードＩＤフィールド、及び／又はシンボルエンコーディングフィールドを含むことができる。
【０５２３】
ＬＣＴバージョン番号フィールド（Ｖ）は、プロトコルバージョン番号を示す。例えば、このフィールドは、ＬＣＴバージョン番号を示す。ＬＣＴヘッダーのバージョン番号フィールドは、ＲＯＵＴＥバージョン番号フィールドとして解釈しなければならない。ＲＯＵＴＥのこのバージョンは暗示的に、ＬＣＴ形成ブロックのバージョン“１”を用いる。例えば、バージョン番号は‘０００１ｂ’である。
【０５２４】
混雑制御フラグフィールド（Ｃ）は、混雑制御情報フィールドの長さを示す。Ｃ＝０は、混雑制御情報（ＣＣＩ）フィールドが３２ビットの長さを有することを示し、Ｃ＝１は、ＣＣＩフィールドが６４ビットの長さを有することを示し、Ｃ＝２は、ＣＣＩフィールドが９６ビットの長さを有することを示し、Ｃ＝３は、ＣＣＩフィールドが１２８ビットの長さを有することを示す。
【０５２５】
予約フィールド（Ｒ）は、将来の使用のために予約される。例えば、予約フィールド（Ｒ）は、ＰＳＩ（Ｐｒｏｔｏｃｏｌ−Ｓｐｅｃｉｆｉｃ  Ｉｎｄｉｃａｔｉｏｎ）フィールドであってもよい。ＰＳＩは、ＬＣＴ上位プロトコルで特定目的の指示子として用いられてもよい。ＰＳＩフィールドは、現在のパケットがソースパケットか又はＦＥＣリペアパケットかを示す。ＲＯＵＴＥソースプロトコルが単にソースパケットを伝達することから、このフィールドは“１０ｂ”に設定されるはずである。
【０５２６】
伝送セッション識別子フラグフィールド（Ｓ）は、伝送セッション識別子フィールドの長さを示す。
【０５２７】
伝送オブジェクト識別子フラグフィールド（Ｏ）は、伝送オブジェクト識別子フィールドの長さを示す。例えば、オブジェクトは一つのファイルを意味することができ、上記のＴＯＩは各オブジェクトの識別情報であり、ＴＯＩが０であるファイルは、ＦＤＴという。
【０５２８】
ハーフワードフラグフィールド（Ｈ）は、ＴＳＩ及びＴＯＩフィールドの長さにハーフワード（ｈａｌｆ−ｗｏｒｄ）（１６ビット）を追加するか否かを示す。
【０５２９】
伝送者現在時間存在フィールド（Ｔ）は、伝送者現在時間（ＳＣＴ）フィールドが存在するか否かを示す。Ｔ＝０は、伝送者現在時間（ＳＣＴ）フィールドが存在しないことを示す。Ｔ＝１は、ＳＣＴフィールドが存在することを示す。ＳＣＴは、セッションがどれくらい長く進行されたかを受信機に示すように伝送者によって挿入される。
【０５３０】
予想レジデュアル時間存在フラグフィールド（Ｒ）は、予想レジデュアル時間（ＥＲＴ）フィールドが存在するか否かを示す。Ｒ＝０は、予想レジデュアル時間（ＥＲＴ）フィールドが存在しないことを示す。Ｒ＝１は、ＥＲＴフィールドが存在することを示す。ＥＲＴは、セッション／オブジェクト送信がどれくらい長く続くかを受信機に示すように送信者によって挿入される。
【０５３１】
クローズセッションフラグフィールド（Ａ）は、セッションが終了したこと又は終了が差し迫っていることを示す。
【０５３２】
クローズオブジェクトフラグフィールド（Ｂ）は、伝送中であるオブジェクトが終了したこと又は終了が差し迫っていることを示す。
【０５３３】
ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）は、３２ビットワードの単位のＬＣＴヘッダーの全長を示す。
【０５３４】
コードポイントフィールド（ＣＰ）は、このパケットによって送信されたペイロードのタイプを示す。ペイロードのタイプによって、追加のペイロードヘッダーが追加され、ペイロードデータをプレフィックス（ｐｒｅｆｉｘ）することができる。
【０５３５】
混雑制御情報フィールド（ＣＣＩ）は、層数、論理チャネル数、シーケンス数などの混雑制御情報の伝送に用いられる。ＬＣＴヘッダー内の混雑制御情報フィールドは、要求される混雑制御情報を含む。
【０５３６】
伝送セッション識別子フィールド（ＴＳＩ）は、セッションの固有識別子である。ＴＳＩは、特定伝送者からの全セッションの中からセッションを固有に識別する。このフィールドは、ＲＯＵＴＥ内の伝送セッションを識別する。伝送セッションのコンテクストはＬＳＩＤ（ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ）によって提供される。
【０５３７】
ＬＳＩＤは、ＲＯＵＴＥセッションの各構成ＬＣＴ伝送セッションで伝送されるものを定義する。それぞれの伝送セッションは、ＬＣＴヘッダー内のＴＳＩ（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）によって固有に識別される。ＬＳＩは、ＬＣＴ伝送セッションを含む同じＲＯＵＴＥセッションで伝送されてもよく、通信網、放送網、インターネット網、ケーブル網、及び／又は衛星網でも伝送されてもよい。ＬＳＩＤが伝送される手段は、これに限定されない。例えば、ＬＳＩＤは、ＴＳＩの値が‘０’である特定ＬＣＴ伝送セッションで伝送されてもよい。ＬＳＩＤは、ＲＯＵＴＥセッションに伝送される全伝送セッションに対するシグナリング情報を含むことができる。ＬＳＩＤは、ＬＳＩＤバージョン情報及びＬＳＩＤの有効性に関する情報を含むことができる。また、ＬＳＩＤは、ＬＣＴ伝送セッションに関する情報を提供する伝送セッション（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ）情報を含むことができる。伝送セッション情報は、伝送セッションを識別するＴＳＩ情報、当該ＴＳＩで伝送され、ソースデータが伝送されるソースフローに関する情報を提供するソースフロー（ｓｏｕｒｃｅ  ｆｌｏｗ）情報、当該ＴＳＩで伝送され、リペアデータが伝送されるリペアフローに関する情報を提供するリペアフロー（ｒｅｐａｉｒ  ｆｌｏｗ）情報、及び当該伝送セッションに関する追加の特性情報を含む伝送セッションプロパティ（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｐｒｏｐｅｒｔｙ）情報を含むことができる。
【０５３８】
伝送オブジェクト識別子フィールド（ＴＯＩ）は、オブジェクトの固有識別子である。ＴＯＵは、このパケットがセッション内のどのオブジェクトに属するかを示す。このフィールドは、現在のパケットのペイロードがこのセッション内のどのオブジェクトに属するかを示す。オブジェクトへのＴＯＩフィールドのマッピングは、拡張されたＦＤＴによって提供される。
【０５３９】
拡張されたＦＤＴは、ファイル伝達データの細部事項を特定する。これは、拡張されたＦＤＴインスタンスである。ＬＣＴパケットヘッダーと共に拡張されたＦＤＴは、デリバリオブジェクトに対するＦＤＴ同等記述を生成するために用いられてもよい。拡張されたＦＤＴを、参照として埋め込み（ｅｍｂｅｄ）又は提供することができる。参照として提供すると、拡張されたＦＤＴは、ＬＳＩＤと独立してアップデートすることができる。参照されると、含まれるソースフローのＴＯＩ＝０上のイン−バンドオブジェクトとして伝達されるはずである。
【０５４０】
ヘッダー拡張フィールドは、追加情報の伝送のためのＬＣＴヘッダー拡張部分として用いられる。ヘッダー拡張は、必ずしも用いられないか、可変サイズを有する選択的なヘッダーフィールドを収容するようにＬＣＴで用いられる。
【０５４１】
例えば、ＥＸＴ＿ＴＩＭＥ拡張は、いくつかのタイプのタイミング情報を伝達するために用いられる。これは、汎用タイミング情報、すなわち、本文書に記載された伝送者現在時間（ＳＣＴ）、予想レジデュアル時間（ＥＲＴ）及び伝送者最後変更（ＳＬＣ）時間拡張を含む。これはまた、（例えば、単一プロトコル例示化（ｉｎｓｔａｎｔｉａｔｉｏｎ）のために定義された）より狭い適用可能性を有するタイミング情報に用いられてもよく、この場合、個別文書に記載される。
【０５４２】
ＦＥＣペイロードＩＤフィールドは、送信ブロック又はエンコーディングシンボルの識別情報を含む。ＦＥＣペイロードＩＤは、上記ファイルがＦＥＣエンコードされた場合の識別子を示す。例えば、ＦＥＣペイロードＩＤは、上記ＦＬＵＴＥプロトコルファイルがＦＥＣエンコードされた場合、これを放送局又は放送サーバーにとって区分するように割り当てることができる。
【０５４３】
シンボルエンコーディングフィールドは、送信ブロック又はエンコーディングシンボルのデータを含むことができる。
【０５４４】
パケットペイロードは、オブジェクトから生成されたバイトを含む。１よりも多いオブジェクトがセッションで伝送されると、ＬＣＴヘッダー内の送信オブジェクトＩＤ（ＴＯＩ）は、パケットペイロードデータが生成されたオブジェクトを識別するために用いなければならない。
【０５４５】
本発明の一実施例に係るＬＣＴパケットは、ヘッダー拡張フィールドの拡張形態である実時間支援拡張フィールド（ＥＸＴ＿ＲＴＳ）を含むことができる。ＥＸＴ＿ＲＴＳは、ファイルの分割生成及び消費情報を含むことができ、以下ではフラグメント情報と表現することができる。本発明の一実施例に係るＬＣＴパケットは、ヘッダー拡張フィールドの拡張形態でＥＸＴ＿ＲＴＳを含むことによって、既存のＬＣＴと交換可能な方法で実時間ファイル伝送及び消費情報を支援することができる。
【０５４６】
本発明の一実施例に係るフラグメント情報（ＥＸＴ＿ＲＴＳ）は、ヘッダー拡張タイプフィールド（ＨＥＴ）、フラグメント開始指示器フィールド（ＳＩ）、フラグメントヘッダーフラグフィールド（ＦＨ）、及びフラグメントヘッダー完了指示器フィールド（ＦＣ）を含むことができる。
【０５４７】
ヘッダー拡張タイプフィールド（ＨＥＴ）は、当該ヘッダー拡張のタイプを示す。ＨＥＴフィールドは８ビットの整数であってもよい。基本的に、ＬＣＴでは、ＨＥＴが０〜１２７の値を有する場合、３２−ビットワード単位の可変長ヘッダー拡張が存在し、ＨＥＴに後くヘッダー拡張長さフィールド（ＨＥＬ）にその長さを記述する。ＨＥＴが１２８〜２５５の値を有する場合、ヘッダー拡張は３２ビットの固定長を有する。
【０５４８】
本発明の一実施例に係るフラグメント情報（ＥＸＴ＿ＲＴＳ）は、３２ビットの固定長を有するので、１２８〜２５５の値のいずれか一つの固有値で当該ヘッダー拡張のタイプを識別することができる。
【０５４９】
ＳＩフィールドは、当該ＬＣＴパケットがフラグメントの開始部を含んでいることを示す。放送環境でユーザが当該ファイルベースマルチメディアコンテンツが伝送されるチャネルの任意の時点に接近した場合、最初に受信されるパケットのうち、ＳＩフィールドが０に設定されたパケットは捨て、ＳＩフィールドが１に設定されたパケットからパーシングを始めることによって、パケットの処理効率を上げ、初期遅延時間を短縮させることができる。
【０５５０】
ＦＨフィールドは、当該ＬＣＴパケットがフラグメントヘッダー部分を含んでいることを示す。上述したように、フラグメントヘッダーは、生成順序と消費順序がフラグメントペイロードのそれと異なる特性を有する。本発明の一実施例に係る放送信号受信装置は、ＦＨフィールドに基づき、生成順で受信された伝送ブロックを消費順序に合わせて再配列してフラグメントを再生成することが可能になる。
【０５５１】
ＦＣフィールドは、当該パケットがフラグメントの最後のデータを含んでいることを示すことができる。例えば、フラグメントペイロードが送信された後にフラグメントヘッダーが伝送される場合、ＦＣフィールドは、フラグメントヘッダーの最後のデータを含んでいることを示すことができる。そして、フラグメントヘッダーが送信された後にフラグメントペイロードが伝送される場合、ＦＣフィールドは、フラグメントペイロードの最後のデータを含んでいることを示すことができる。以下では、フラグメントペイロードがまず送信された後にフラグメントヘッダーが伝送されることを中心に説明する。
【０５５２】
放送信号受信装置が、ＦＣフィールドが１に設定されたパケットを受信すると、フラグメントヘッダーの受信が完了したことを認知し、フラグメントヘッダー及びフラグメントペイロードを組み合わせてフラグメントを復元することができる。
【０５５３】
パディングバイトフィールド（ＰＢ）は、当該ＬＣＴパケットに含まれたパディングバイト数を示す。既存のＬＣＴでは、一つのオブジェクトに該当する全てのＬＣＴパケットの長さが同一でなければならない。しかし、本発明の一実施例に係るデータ構成方案によって伝送ブロックを分ける場合、毎伝送ブロックの最後のシンボルは、異なる長さを有し得る。このため、本発明の一実施例に係る放送信号送信装置は、パケットの残り部分をパディングバイトで埋めることによって、固定長パケットを用いて既存のＬＣＴと交換可能な方法で実時間ファイル伝送を支援することができる。
【０５５４】
予約フィールドは、将来の使用のために予約される。
【０５５５】
図３１は、本発明の一実施例に係るファイルを伝送するためのＬＣＴパケットの構造を示す図である。
【０５５６】
図３１に示す部分のうち、図３５に示す部分と同一の部分は、図３５で説明した内容と同一であり、以下では差異点を中心に説明するものとする。
【０５５７】
図３１を参照すると、本発明の一実施例に係るフラグメント情報（ＥＸＴ＿ＲＴＳ）は、図３５で説明したＦＣフィールドの代わりに、フラグメントヘッダー長フィールド（ＦＨＬ）を含むことができる。
【０５５８】
ＦＨＬフィールドは、フラグメントを構成するシンボルの数を示すことによって、フラグメントの受信が完了したか否かに関する情報を提供することができる。ＦＨＬフィールドは、フラグメントヘッダー及びフラグメントペイロードの両方を含むそれぞれのフラグメントに該当する全シンボルの数を示すことができる。また、ＦＨＬフィールドは、フラグメントヘッダー及びフラグメントペイロードのうち、後に伝送されるものの全シンボルの数を示すことができる。
【０５５９】
例えば、フラグメントペイロードがまず送信された後にフラグメントヘッダーが伝送される場合、ＦＨＬフィールドは、フラグメントヘッダーに該当する全シンボルの数を示すことができる。このとき、ＦＨＬフィールドはフラグメントヘッダーの長さを示すことができる。
【０５６０】
そして、フラグメントヘッダーがまず送信された後にフラグメントペイロードが伝送される場合、ＦＨＬフィールドは、フラグメントペイロードに該当する全シンボルの数を示すことができる。このとき、ＦＨＬフィールドはフラグメントペイロードの長さを示すことができる。
【０５６１】
以下では、フラグメントペイロードがまず送信された後にフラグメントヘッダーが伝送される場合を中心に説明する。
【０５６２】
本発明の他の実施例に係る放送信号受信装置は、ＦＨＬフィールドに表示されたシンボルの個数に該当するフラグメントヘッダーを含むＬＣＴパケットを受信することができる。放送信号受信装置は、フラグメントヘッダーを含むＬＣＴパケットの受信の回数をチェックすることによって、フラグメントヘッダーの受信が完了したことを識別することができる。又は、放送信号受信装置は、フラグメントヘッダーに該当する伝送ブロックの個数をチェックして、フラグメントヘッダーの受信が完了したことを識別することができる。
【０５６３】
＜ファイルの分割生成及び分割消費の識別方法＞
図３２は、本発明の一実施例に係るＦＤＴを用いた実時間放送支援情報シグナリングを示す図である。
【０５６４】
上述したように、本発明は、実時間放送環境でファイルベースマルチメディアコンテンツの分割生成及び分割消費に関する情報を識別する方法を提供することを一実施例としている。ファイルベースマルチメディアコンテンツの分割生成及び分割消費に関する情報は、上述したデータ構造及びＬＣＴパケット情報を含むことができる。
【０５６５】
放送信号送信装置は、ファイルの分割生成情報及び分割消費情報の識別のために別のシグナリング情報を更に伝送することができる。例えば、シグナリング情報は、メタデータ又は帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）を用いたシグナリング（ｓｉｇｎａｌｉｎｇ）情報を含むことができる。
【０５６６】
図３２を参照すると、本発明の一実施例に係る実時間放送支援情報に対するシグナリング情報を送信する方法が示されている。
【０５６７】
本発明の一実施例に係る放送信号送信装置は、ＦＤＴ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ）レベル又はファイルレベルの実時間支援属性を用いてシグナリング情報を伝送することができる。実時間支援が１に設定されている場合、当該ＦＤＴレベル又はファイルレベルで記述しているオブジェクトが上述のデータ構造及びパケット情報を有し、これを用いて、実時間放送環境におけるファイル分割生成及び消費を支援できることを示すことができる。
【０５６８】
図３３は、本発明の一実施例に係る放送信号送信装置を示す構成図である。
【０５６９】
図３３を参照すると、本発明の一実施例に係る放送網を介して、マルチメディアコンテンツを含む放送信号を送信する放送信号送信装置は、シグナリングエンコーダＣ２１００５、送信ブロック生成器Ｃ２１０３０、及び／又は送信器Ｃ２１０５０を含むことができる。
【０５７０】
シグナリングエンコーダＣ２１００５は、シグナリング情報を生成することができる。シグナリング情報は、マルチメディアコンテンツを実時間で伝送するか否かを示す情報である。シグナリング情報は、ファイルレベル又はＦＤＴレベルのうち少なくとも一つで上記マルチメディアコンテンツを実時間で送信することを示すことができる。シグナリング情報がファイルレベルでマルチメディアコンテンツを実時間で送信することを示すと、当該ファイルに属する全データを実時間で伝送することができる。また、シグナリング情報がＦＤＴレベルでマルチメディアコンテンツを実時間で送信することを示すと、当該ＦＤＴに属する全ファイル又はデータを実時間で伝送することができる。
【０５７１】
シグナリング情報がマルチメディアコンテンツを実時間で送信することを示す場合、送信ブロック生成器Ｃ２１０３０は、マルチメディアコンテンツに含まれるファイルを、独立して符号化して伝送されるデータ単位である少なくとも一つの伝送ブロックに分割することができる。
【０５７２】
送信器Ｃ２１０５０は、伝送ブロックを伝送することができる。
【０５７３】
より具体的な内容は、以下の図３４で説明する。
【０５７４】
図３４は、本発明の一実施例に係る放送信号送信装置を示す構成図である。
【０５７５】
図３４を参照すると、本発明の一実施例に係る放送網を用いて、マルチメディアコンテンツを含む放送信号を送信する放送信号送信装置は、シグナリングエンコーダ（図示せず）、メディアエンコーダＣ２１０１０、フラグメント生成器Ｃ２１０２０、送信ブロック生成器Ｃ２１０３０、パケタイザＣ２１０４０、及び／又は送信器Ｃ２１０５０を含むことができる。
【０５７６】
シグナリングエンコーダ（図示せず）は、シグナリング情報を生成することができる。シグナリング情報は、マルチメディアコンテンツを実時間で伝送するか否かを示す情報である。
【０５７７】
メディアエンコーダＣ２１０１０は、マルチメディアコンテンツをエンコードしてメディアデータを生成することができる。以下でメディアデータをデータと表現することができる。
【０５７８】
フラグメント生成器Ｃ２１０２０は、マルチメディアコンテンツを構成するそれぞれのファイルを分割して、独立して復号化及び再生されるデータ単位である少なくとも一つのフラグメントを生成することができる。
【０５７９】
フラグメント生成器Ｃ２１０２０は、それぞれのフラグメントを構成するフラグメントペイロードを生成した後にフラグメントヘッダーを生成することができる。
【０５８０】
フラグメント生成器Ｃ２１０２０は、フラグメントペイロードに該当するメディアデータをバッファすることができる。その後、フラグメント生成器Ｃ２１０２０は、バッファしたメディアデータに基づいて、フラグメントペイロードに該当するチャンク（ｃｈｕｎｋ）を生成することができる。例えば、チャンクは、ビデオデータのＧＯＰのように、同一のメディアデータで構成される可変サイズのデータ単位であってもよい。
【０５８１】
フラグメントペイロードに該当するチャンクの生成が完了していないと、フラグメント生成器Ｃ２１０２０は、メディアデータを継けてバッファした後、フラグメントペイロードに該当するチャンクの生成を完了することができる。
【０５８２】
フラグメント生成器Ｃ２１０２０は、チャンクを生成する度に、フラグメントペイロードに該当するデータを全てチャンクとして生成したか否かを判断することができる。
【０５８３】
フラグメントペイロードに該当するチャンクの生成が完了すると、フラグメント生成器Ｃ２１０２０は、フラグメントペイロードに該当するフラグメントヘッダーを生成することができる。
【０５８４】
送信ブロック生成器Ｃ２１０３０は、フラグメントを分割して、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを生成することができる。
【０５８５】
本発明の一実施例に係る伝送ブロックは、以前（ｐｒｅｃｅｄｉｎｇ）のデータに対する依存性無しで独立して符号化及び伝送可能な最小のデータ単位を意味する。例えば、伝送ブロックは、ビデオデータのＧＯＰのように、同一のメディアデータで構成される少なくとも一つのチャンクを含むことができる。
【０５８６】
本発明の一実施例に係る送信ブロック生成器Ｃ２１０３０は、フラグメントペイロードに該当する伝送ブロックをまず生成した後に、フラグメントヘッダーに該当する伝送ブロックを生成することができる。
【０５８７】
送信ブロック生成器Ｃ２１０３０は、フラグメントヘッダーを一つの伝送ブロックとして生成することができる。ただし、これに限定されず、送信ブロック生成器Ｃ２１０３０は、フラグメントヘッダーを少なくとも一つの伝送ブロックとして生成することもできる。
【０５８８】
例えば、フラグメント生成器Ｃ２１０２０がそれぞれのフラグメントを構成するフラグメントペイロードを生成した後にフラグメントヘッダーを生成する場合、送信ブロック生成器Ｃ２１０３０は、フラグメントペイロードに該当する伝送ブロックを生成した後、フラグメントヘッダーに該当する伝送ブロックを生成することができる。
【０５８９】
ただし、これに限定されず、マルチメディアコンテンツに対してフラグメントヘッダー及びフラグメントペイロードが既に生成されている場合には、フラグメントヘッダーに該当する伝送ブロックをまず生成した後に、フラグメントペイロードに該当する伝送ブロックを生成することもできる。
【０５９０】
送信ブロック生成器Ｃ２１０３０は、フラグメントペイロードに該当する伝送ブロックとフラグメントヘッダーに該当する伝送ブロックをそれぞれ別個の伝送ブロックとして生成することができる。
【０５９１】
パケタイザＣ２１０４０は、伝送ブロックを同一サイズの少なくとも一つのシンボルに分割して、それぞれの少なくとも一つのシンボルを、少なくとも一つのパケットにパケット化することができる。ただし、これに限定されず、シンボルは、他の装置によって生成されてもよい。本発明の一実施例に係るシンボルの長さは同一であってもよい。ただし、各伝送ブロックの最後のシンボルは、他のシンボルに比べて短い長さを有しうる。
【０５９２】
その後、パケタイザＣ２１０４０は、少なくとも一つのシンボルを少なくとも一つのパケットにパケット化することができる。例えば、パケットはＬＣＴパケットであってもよい。パケットは、パケットヘッダー及びパケットペイロードを含むことができる。
【０５９３】
パケットヘッダーは、ファイルの分割生成及び分割消費に関する情報を有するフラグメント情報を含むことができる。ファイルの分割生成とは、マルチメディアコンテンツを構成するファイルを、独立してエンコード及び伝送できる少なくとも一つのチャンク又は伝送ブロックに分割して生成することを意味する。ファイルの分割消費とは、受信された少なくとも一つの伝送ブロックを組み合わせて、独立してデコード及び再生できる少なくとも一つのフラグメントを復元し、フラグメント単位で再生することを意味する。また、ファイルの分割消費とは、伝送ブロック単位で再生することを含むことができる。
【０５９４】
例えば、フラグメント情報は、パケットがフラグメントの最初のデータを含んでいることを示すＳＩフィールド、パケットがフラグメントヘッダーのデータを含んでいることを示すＦＨフィールド、それぞれのフラグメントに該当する伝送ブロックの生成を完了したことを示すフラグメント完了情報、及びパケットに含まれたパディングバイト数を示すＰＢフィールドのうち少なくとも一つを含むことができる。
【０５９５】
そして、フラグメント情報は、当該パケットのヘッダー拡張のタイプを示すＨＥＴ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｔｙｐｅ  ｆｉｅｌｄ）フィールドをさらに含むことができる。
【０５９６】
そして、フラグメント完了情報は、パケットがフラグメントヘッダーの最後のデータを含んでいることを示すＦＣフィールド、及びフラグメントヘッダーに該当する全シンボルの数を示すＦＨＬフィールドのうち一つを含むことができる。
【０５９７】
フラグメント情報は、パケタイザＣ２１０４０で生成されてもよく、別の装置によって生成されてもよい。以下では、パケタイザＣ２１０４０がフラグメント情報を生成する場合を中心に説明する。
【０５９８】
パケタイザＣ２１０４０は、生成されたシンボルがフラグメントの最初のデータを含んでいるか否かを識別することができる。
【０５９９】
例えば、パケタイザＣ２１０４０は、生成されたシンボルがフラグメントペイロードの最初のデータを含むか否かを識別することができる。生成されたシンボルがフラグメントペイロードの最初のデータを含んでいると、ＳＩフィールドは‘１’に設定されてもよい。生成されたシンボルがフラグメントペイロードの最初のデータを含んでいないと、ＳＩフィールドは‘０’に設定されてもよい。
【０６００】
パケタイザＣ２１０４０は、生成されたシンボルがフラグメントペイロードのデータを含むか、或いはフラグメントヘッダーのデータを含むかを識別することができる。
【０６０１】
例えば、生成されたシンボルがフラグメントペイロードのデータを含むと、ＦＨフィールドは‘１’に設定されてもよい。生成されたシンボルがフラグメントペイロードのデータを含まないと、ＦＨフィールドは‘０’に設定されてもよい。
【０６０２】
パケタイザＣ２１０４０は、それぞれのフラグメントに該当する伝送ブロックの生成を完了したか否かを識別することができる。それぞれのフラグメントに該当する伝送ブロックの生成を完了したことを示すフラグメント完了情報は、パケットがフラグメントヘッダーの最後のデータを含んでいることを示すＦＣフィールドを含むことができる。
【０６０３】
例えば、生成されたシンボルがフラグメントヘッダーのデータを含み、当該伝送ブロックの最後のシンボルであれば、ＦＣフィールドは‘１’に設定されてもよい。生成されたシンボルがフラグメントヘッダーのデータを含まないか、又は当該伝送ブロックの最後のシンボルでないと、ＦＣフィールドは‘０’に設定されてもよい。
【０６０４】
パケタイザＣ２１０４０は、生成されたシンボルが当該伝送ブロックの最後のシンボルであり、他のシンボルと異なる長さを有するシンボルであるかを識別することができる。例えば、他のシンボルは、あらかじめ定められた長さのシンボルであり、他のシンボルと異なる長さを有するシンボルは、他のシンボルに比べて長さの短いシンボルであってもよい。
【０６０５】
例えば、生成されたシンボルが当該伝送ブロックの最後のシンボルであり、他のシンボルと異なる長さを有すると、パケタイザＣ２１０４０は、それぞれの伝送ブロックの最後のシンボルに該当するパケットにパディングバイトを挿入することができる。そして、パケタイザＣ２１０４０は、パッキングバイトの数を計算することができる。
【０６０６】
そして、ＰＢフィールドは、パディングバイトの数を示すことができる。パディングバイトは、他のシンボルと同一の長さとなるように、他のシンボルに比べて長さの短いシンボルに追加されるバイトである。又は、パディングバイトは、パケットにおいてシンボルを除いた残りの部分であってもよい。
【０６０７】
生成されたシンボルが当該伝送ブロックの最後のシンボルでないか、又は他のシンボルと長さが異なると、ＰＢフィールドは‘０’に設定されてもよい。
【０６０８】
パケットペイロードは、少なくとも一つのシンボルを含むことができる。以下では、一つのパケットが一つのシンボルを含む場合を中心に説明する。
【０６０９】
それぞれの伝送ブロックの最後のシンボルを含むパケットは、少なくとも一つのパディングバイトを含むことができる。
【０６１０】
送信器Ｃ２１０５０は、伝送ブロックが生成された順で少なくとも一つのパケットを伝送することができる。
【０６１１】
例えば、本発明の一実施例に係る送信器Ｃ２１０５０は、フラグメントペイロードに該当する伝送ブロックをまず送信した後に、フラグメントヘッダーに該当する伝送ブロックを伝送することができる。
【０６１２】
ただし、これに限定されず、マルチメディアコンテンツに対してフラグメントヘッダー及びフラグメントペイロードが既に生成されている場合には、本発明の一実施例に係る送信器Ｃ２１０５０は、フラグメントヘッダーに該当する伝送ブロックをまず送信した後に、フラグメントペイロードに該当する伝送ブロックを伝送することもできる。
【０６１３】
図３５は、本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間生成及び送信手順を示すフローチャートである。
【０６１４】
図３５を参照すると、図３４で上述した放送信号送信装置が放送信号を送信する手順が示されている。
【０６１５】
まず、本発明の一実施例に係る放送信号送信装置は、メディアエンコーダＣ２１０１０を用いてマルチメディアコンテンツのエンコーディングを始めることができる（ＣＳ１１１００）。放送信号送信装置は、マルチメディアコンテンツをエンコードしてメディアデータを生成することができる。
【０６１６】
その後、放送信号送信装置は、フラグメントペイロードに該当するメディアデータをバッファすることができる（ＣＳ１１２００）。その後、放送信号送信装置は、バッファしたメディアデータに基づいて、フラグメントペイロードに該当するチャンク（ｃｈｕｎｋ）を生成することができる。
【０６１７】
フラグメントペイロードに該当するチャンクの生成が完了していないと、放送信号送信装置は、メディアデータを続けてバッファした後に、フラグメントペイロードに該当するチャンクの生成を完了すればよい（ＣＳ１１３００）。
【０６１８】
その後、放送信号送信装置は、フラグメント生成器Ｃ２１０２０を用いて、マルチメディアコンテンツを構成するそれぞれのファイルを分割し、独立して復号化及び再生されるデータ単位である少なくとも一つのフラグメントを生成することができる（ＣＳ１１４００）。
【０６１９】
放送信号送信装置は、それぞれのフラグメントを構成するフラグメントペイロードを生成した後にフラグメントヘッダーを生成することができる。
【０６２０】
放送信号送信装置は、チャンクを生成する度に、フラグメントペイロードに該当するデータを全てチャンクとして生成したか判断することができる。
【０６２１】
その後、フラグメントペイロードに該当するチャンクの生成が完了すると、放送信号送信装置は、フラグメントペイロードに該当するフラグメントヘッダーを生成することができる。
【０６２２】
その後、放送信号送信装置は、送信ブロック生成器Ｃ２１０３０を用いてフラグメントを分割して、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを生成することができる（ＣＳ１１５００）。
【０６２３】
例えば、それぞれのフラグメントを構成するフラグメントペイロードを生成した後にフラグメントヘッダーを生成する場合、放送信号送信装置は、フラグメントペイロードに該当する伝送ブロックを生成した後、フラグメントヘッダーに該当する伝送ブロックを生成することができる。
【０６２４】
放送信号送信装置は、フラグメントペイロードに該当する伝送ブロックとフラグメントヘッダーに該当する伝送ブロックを、それぞれ別個の伝送ブロックとして生成することができる。
【０６２５】
その後、放送信号送信装置は、パケタイザＣ２１０４０を用いて伝送ブロックを同一サイズの少なくとも一つのシンボルに分割し、それぞれの少なくとも一つのシンボルを少なくとも一つのパケットにパケット化することができる（ＣＳ１１６００、ＣＳ１１７００）。
【０６２６】
放送信号送信装置がパケットを生成する手順については図４０で具体的に後述し、ここでは説明を省略するものとする。
【０６２７】
その後、放送信号送信装置は、送信器Ｃ２１０５０を用いて伝送ブロックが生成された順で少なくとも一つのパケットを伝送することができる。
【０６２８】
図３６は、本発明の一実施例に係る放送信号送信装置がパケタイザを用いてパケットを生成する手順を具体的に示すフローチャートである。
【０６２９】
放送信号送信装置は、生成されたシンボルがフラグメントの最初のデータを含んでいるか否か識別することができる（ＣＳ１１７１０）。
【０６３０】
例えば、生成されたシンボルがフラグメントペイロードの最初のデータを含んでいると、ＳＩフィールドは‘１’に設定されてもよい（ＣＳ１１７１２）。生成されたシンボルがフラグメントペイロードの最初のデータを含んでいないと、ＳＩフィールドは‘０’に設定されてもよい（ＣＳ１１７１４）。
【０６３１】
その後、放送信号送信装置は、生成されたシンボルがフラグメントペイロードのデータを含むか、或いはフラグメントヘッダーのデータを含むかを識別することができる（ＣＳ１１７２０）。
【０６３２】
例えば、生成されたシンボルがフラグメントペイロードのデータを含むと、ＦＨフィールドは‘１’に設定されてもよい（ＣＳ１１７２２）。生成されたシンボルがフラグメントペイロードのデータを含まないと、ＦＨフィールドは‘０’に設定されてもよい（ＣＳ１１７２４）。
【０６３３】
その後、放送信号送信装置は、それぞれのフラグメントに該当する伝送ブロックの生成を完了したか否かを識別することができる（ＣＳ１１７３０）。
【０６３４】
例えば、生成されたシンボルがフラグメントヘッダーのデータを含み、当該伝送ブロックの最後のシンボルであれば、ＦＣフィールドは‘１’に設定されてもよい（ＣＳ１１７３２）。生成されたシンボルがフラグメントヘッダーのデータを含まないか、又は当該伝送ブロックの最後のシンボルでないと、ＦＣフィールドは‘０’に設定されてもよい（ＣＳ１１７３４）。
【０６３５】
その後、放送信号送信装置は、生成されたシンボルが当該伝送ブロックの最後のシンボルであり、他のシンボルと異なる長さを有するシンボルであるか識別することができる（ＣＳ１１７４０）。
【０６３６】
例えば、生成されたシンボルが当該伝送ブロックの最後のシンボルであり、他のシンボルと異なる長さを有すると、放送信号送信装置は、それぞれの伝送ブロックの最後のシンボルに該当するパケットにパディングバイトを挿入することができる。そして、放送信号送信装置は、パディングバイトの数を計算することができる（ＣＳ１１７４２）。そして、ＰＢフィールドは、パディングバイトの数を示すことができる。
【０６３７】
生成されたシンボルが当該伝送ブロックの最後のシンボルでないか、又は他のシンボルと長さが異なると、ＰＢフィールドは‘０’に設定されてもよい（ＣＳ１１７４４）。
【０６３８】
パケットペイロードは少なくとも一つのシンボルを含むことができる。
【０６３９】
図３７は、本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間生成／送信の手順を示すフローチャートである。
【０６４０】
図３７では、図３５及び図３６で説明された内容と実質的に同じ内容については具体的な説明を省略する。
【０６４１】
本発明の一実施例に係る放送信号送信装置は、ＦＣフィールドの代わりにＦＨＬフィールドを使用することができる。例えば、上述したフラグメント情報は、それぞれのフラグメントに該当する伝送ブロックの生成を完了したことを示すフラグメント完了情報を含むことができる。そして、フラグメント完了情報は、フラグメントヘッダーに該当する全シンボルの数を示すＦＨＬフィールドを含むことができる。
【０６４２】
本発明の一実施例に係る放送信号送信装置は、フラグメントヘッダーのデータを含む伝送ブロックに該当するシンボルの個数を計算してＦＨＬフィールドに記録することができる（ＣＳ１２７２４）。
【０６４３】
ＦＨＬフィールドは、フラグメントヘッダー部分に該当する全シンボル数としてフラグメントヘッダーの長さを示す。放送信号受信装置がフラグメントヘッダーの受信が完了したことを識別できるように、ＦＨＬフィールドは、上述したＦＣフィールドの代わりにフラグメント情報に含まれてもよい。
【０６４４】
本発明の一実施例に係る放送信号受信装置は、ＦＨＬフィールドに記録された個数だけのフラグメントヘッダーを含むパケットの伝送回数をチェックすることによって、フラグメントヘッダーの受信が完了したか否かを識別することができる。
【０６４５】
図３８は、本発明の一実施例に係るファイルベースマルチメディアコンテンツ受信機の構造を示す図である。
【０６４６】
図３８を参照すると、本発明の一実施例に係る放送網を用いて、マルチメディアコンテンツを含む放送信号を受信する放送信号受信装置は、受信部（図示せず）、シグナリングデコーダＣ２２００５、送信ブロック再生成器Ｃ２２０３０、及び／又はメディアデコーダＣ２２０６０を含むことができる。
【０６４７】
シグナリングデコーダＣ２２００５は、シグナリング情報をデコードすることができる。シグナリング情報は、マルチメディアコンテンツを実時間で伝送するか否かを示す情報である。
【０６４８】
シグナリング情報がマルチメディアコンテンツを実時間で送信することを示す場合、送信ブロック再生成器Ｃ２２０３０は、放送信号を組み合わせて、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを復元することができる。
【０６４９】
メディアデコーダＣ２２０６０は、伝送ブロックを復号化することができる。
【０６５０】
より具体的な内容は、図４４で後述する。
【０６５１】
図３９は、本発明の一実施例に係るファイルベースマルチメディアコンテンツ受信機の構造を示す図である。
【０６５２】
図３９を参照すると、本発明の一実施例に係る放送信号受信装置は、受信部（図示せず）、シグナリングデコーダ（図示せず）、パケットフィルタＣ２２０１０、パケットデパケタイザＣ２２０２０、送信ブロック再生成器Ｃ２２０３０、フラグメント再生成器Ｃ２２０４０、フラグメントパーサーＣ２２０５０、メディアデコーダＣ２２０６０、及び／又はメディアレンダラＣ２２０７０を含むことができる。
【０６５３】
受信部（図示せず）は、放送信号を受信することができる。放送信号は、少なくとも一つのパケットを含むことができる。それぞれのパケットは、フラグメント情報を含むパケットヘッダー、及び少なくとも一つのシンボルを含むパケットペイロードを含むことができる。
【０６５４】
シグナリングデコーダＣ２２００５は、シグナリング情報をデコードすることができる。シグナリング情報は、マルチメディアコンテンツを実時間で伝送するか否かを示す情報である。
【０６５５】
パケットフィルタＣ２２０１０は、任意の地点で受信された少なくとも一つのパケットからフラグメントの開始地点を識別し、フラグメントの開始地点からパケット処理を開始可能にする。
【０６５６】
パケットフィルタＣ２２０１０は、パケットに含まれたフラグメント情報のＳＩフィールドに基づいてフラグメントの開始地点を識別することができる。パケットフィルタＣ２２０１０は、ＳＩフィールドが、当該パケットがフラグメントの開始部分を含んでいることを示すと、当該パケット以前のパケットを捨て、当該パケットからパケットデパケタイザＣ２２０２０に伝達することができる。
【０６５７】
例えば、パケットフィルタＣ２２０１０は、‘１’に設定されたパケット以前のパケットは捨て、‘１’に設定されたパケット以降のパケットをフィルタすることができる。
【０６５８】
パケットデパケタイザＣ２２０２０は、少なくとも一つのパケットをデパケット化して、パケットヘッダーに含まれたフラグメント情報及びパケットペイロードに含まれた少なくとも一つのシンボルを抽出することができる。
【０６５９】
送信ブロック再生成器Ｃ２２０３０はパケットを組み合わせて、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを復元することができる。復元された伝送ブロックは、フラグメントヘッダーに該当するデータを含むことができ、フラグメントペイロードに該当するデータを含むことができる。
【０６６０】
フラグメント再生成器Ｃ２２０４０は、少なくとも一つの伝送ブロックを組み合わせて、フラグメントヘッダー及びフラグメントペイロードの復元を完了した後にフラグメントヘッダー及びフラグメントペイロードを組み合わせて、独立して復号化及び再生されるデータ単位であるフラグメントを復元することができる。
【０６６１】
フラグメント再生成器Ｃ２２０４０は、フラグメント情報に基づいて伝送ブロックを組み合わせて、フラグメントペイロード及びフラグメントヘッダーを復元することができる。フラグメント再生成器Ｃ２２０４０は、受信されるパケットの順序でフラグメントペイロードをまず復元した後、フラグメントヘッダーを復元することができる。
【０６６２】
ＦＨフィールドが、パケットがフラグメントヘッダーのデータを含んでいることを示すと、フラグメント再生成器Ｃ２２０４０は、フラグメントヘッダーに該当する少なくとも一つの伝送ブロックを組み合わせて、フラグメントヘッダーを復元することができる。
【０６６３】
ＦＨフィールドが、パケットがフラグメントヘッダーのデータを含んでいないことを示すと、フラグメント再生成器Ｃ２２０４０は、フラグメントペイロードに該当する少なくとも一つの伝送ブロックを組み合わせて、フラグメントペイロードを復元することができる。
【０６６４】
例えば、ＦＨフィールドの値が‘０’である場合、フラグメント再生成器Ｃ２２０４０は、フラグメントペイロードとして判断し、フラグメントペイロードを復元することができる。ＦＨフィールドの値が‘１’である場合、フラグメント再生成器Ｃ２２０４０はフラグメントヘッダーとして判断し、フラグメントヘッダーを復元することができる。
【０６６５】
その後、フラグメント再生成器Ｃ２２０４０は、それぞれのフラグメントに該当するフラグメントペイロード及びフラグメントヘッダーの復元を終了すると、復元したフラグメントペイロード及びフラグメントヘッダーを組み合わせてフラグメントを復元することができる。
【０６６６】
フラグメント再生成器Ｃ２２０４０がそれぞれのフラグメントに該当するフラグメントペイロード及びフラグメントヘッダーの復元を終了したかを確認する方法としては、下記の２つの方法を挙げることができる。
【０６６７】
第一の方法は、フラグメント情報に含まれたＦＣフィールドを用いる方法である。
【０６６８】
フラグメント完了情報は、パケットがフラグメントヘッダーの最後のデータを含んでいることを示すＦＣフィールドを含むことができる。ＦＣフィールドが、パケットがフラグメントヘッダーの最後のデータを含んでいることを示すと、フラグメント再生成器Ｃ２２０４０は、それぞれのフラグメントを構成するフラグメントヘッダー及びフラグメントペイロードの受信が完了したと判断し、フラグメントヘッダー及びフラグメントペイロードの復元を完了することができる。
【０６６９】
例えば、それぞれのフラグメントを構成するフラグメントペイロードがまず受信された後にフラグメントヘッダーが受信されると、ＦＣフィールドは、当該パケットがフラグメントヘッダーの最後のデータを含んでいることを示すことができる。
【０６７０】
したがって、ＦＣフィールドが、当該パケットがフラグメントヘッダーの最後のデータを含んでいることを示すと、フラグメント再生成器Ｃ２２０４０は、フラグメントヘッダーの受信が完了したことを認識し、フラグメントヘッダーを復元する手順を終了すればよい。その後、フラグメント再生成器Ｃ２２０４０は、フラグメントヘッダーとフラグメントペイロードを組み合わせてフラグメントを復元することができる。
【０６７１】
ＦＣフィールドが、当該パケットがフラグメントヘッダーの最後の部分のデータを含んでいないことを示すと、放送信号受信装置は、伝送ブロックを復元する手順を反復することができる。
【０６７２】
例えば、ＦＣフィールドの値が‘１’でない場合、放送信号受信装置は、伝送ブロックを復元する手順を反復することができる。そして、ＦＣフィールドの値が‘１’である場合、フラグメント再生成器Ｃ２２０４０は、フラグメントヘッダーとフラグメントペイロードを組み合わせてフラグメントを復元することができる。
【０６７３】
第二の方法は、フラグメント情報に含まれたＦＨＬフィールドに基づいて、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの復元が完了したか否かを確認することができる。
【０６７４】
フラグメント再生成器Ｃ２２０４０は、フラグメントヘッダーのデータを含むパケットの数をカウントすることができる。
【０６７５】
フラグメント完了情報は、フラグメントヘッダーに該当する全シンボルの数を示すＦＨＬフィールドをさらに含み、ＦＨＬフィールドに記録された値とフラグメントヘッダーのデータを含むパケットの数とが一致すると、フラグメント再生成器Ｃ２２０４０はフラグメントヘッダー及びフラグメントペイロードの復元を完了することができる。
【０６７６】
フラグメント再生成器Ｃ２２０４０がＦＨＬフィールドを用いることに関する具体的な説明は、図４６で後述する。
【０６７７】
フラグメントパーサーＣ２２０５０は、復元されたフラグメントをパースすることができる。復元されたフラグメントは、フラグメントヘッダーが前の部分に位置し、フラグメントペイロードが後の部分に位置するため、フラグメントパーサーＣ２２０５０は、フラグメントヘッダーをまずパースした後にフラグメントペイロードをパースすることができる。
【０６７８】
フラグメントパーサーＣ２２０５０は、復元されたフラグメントをパースして、少なくとも一つのメディアアクセスユニットを生成することができる。例えば、メディアアクセスユニットは、少なくとも一つのメディアデータを含むことができる。メディアアクセスユニットは、あらかじめ定められたサイズのメディアデータの単位であってもよい。
【０６７９】
メディアデコーダＣ２２０６０はフラグメントを復号化することができる。メディアデコーダＣ２２０６０は少なくとも一つのメディアアクセスユニットを復号化してメディアデータを生成することができる。
【０６８０】
メディアレンダラＣ２２０７０は、復号化されたメディアデータをレンダリングしてプレゼンテーションすることができる。
【０６８１】
図４０は、本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間受信／消費の手順を示す図である。
【０６８２】
図３９で説明した内容は、本発明の一実施例に係る放送信号受信方法に同一に適用されてもよい。
【０６８３】
図４０を参照すると、本発明の一実施例に係る放送信号受信方法は、少なくとも一つのファイルを含むマルチメディアコンテンツを受信する放送信号受信方法において、少なくとも一つのパケットに分割されたマルチメディアコンテンツを受信し、パケットを組み合わせて、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを復元し、少なくとも一つの伝送ブロックを組み合わせて、フラグメントヘッダー及びフラグメントペイロードの復元を完了した後、フラグメントヘッダー及びフラグメントペイロードを組み合わせて、独立して復号化及び再生されるデータ単位であるフラグメントを復元し、及び／又はフラグメントを復号化することを含むことができる。
【０６８４】
まず、本発明の一実施例に係る放送信号受信装置は、受信部（図示せず）を用いて放送信号を受信することができる（ＣＳ２１０１０）。放送信号は、少なくとも一つのパケットを含むことができる。
【０６８５】
その後、本発明の一実施例に係る放送信号受信装置は、パケットフィルタＣ２２０１０を用いて、任意の地点で受信された少なくとも一つのパケットからフラグメントの開始地点を識別することができる（ＣＳ２１０２０）。
【０６８６】
その後、本発明の一実施例に係る放送信号受信装置は、パケットデパケタイザＣ２２０２０を用いて少なくとも一つのパケットをデパケット化し、パケットヘッダーに含まれたフラグメント情報及びパケットペイロードに含まれた少なくとも一つのシンボルを抽出することができる（ＣＳ２１０３０）。
【０６８７】
その後、放送信号受信装置は、送信ブロック再生成器Ｃ２２０３０を用いてパケットを組み合わせて、独立して符号化及び伝送されるデータ単位である少なくとも一つの伝送ブロックを復元することができる（ＣＳ２１０４０）。復元された伝送ブロックは、フラグメントヘッダーに該当するデータを含むことができ、フラグメントペイロードに該当するデータを含むことができる。
【０６８８】
その後、本発明の一実施例に係る放送信号受信装置は、フラグメント再生成器Ｃ２２０４０でフラグメント情報に基づいて復元された伝送ブロックがフラグメントヘッダーに該当する伝送ブロックであるか、或いは、フラグメントペイロードに該当する伝送ブロックであるかを識別することができる（ＣＳ２１０５０）。
【０６８９】
その後、放送信号受信装置は、復元された伝送ブロックを組み合わせて、フラグメントペイロード及びフラグメントヘッダーを復元することができる。
【０６９０】
ＦＨフィールドが、パケットがフラグメントヘッダーのデータを含んでいないことを示すと、放送信号受信装置は、フラグメントペイロードに該当する少なくとも一つの伝送ブロックを組み合わせてフラグメントペイロードを復元することができる（ＣＳ２１０６０）。
【０６９１】
ＦＨフィールドがパケットがフラグメントヘッダーのデータを含んでいることを示すと、放送信号受信装置は、フラグメントヘッダーに該当する少なくとも一つの伝送ブロックを組み合わせてフラグメントヘッダーを復元することができる（ＣＳ２１０７０）。
【０６９２】
放送信号受信装置は、フラグメント情報に含まれたＦＣフィールドに基づいて、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの復元が完了したか否かを確認することができる（ＣＳ２１０８０）。
【０６９３】
ＦＣフィールドが、当該パケットがフラグメントヘッダーの最後のデータを含んでいないことを示すと、放送信号受信装置は、伝送ブロックを復元する手順を反復することができる。
【０６９４】
ＦＣフィールドが、当該パケットがフラグメントの最後のデータを含んでいることを示すと、放送信号受信装置は、それぞれのフラグメントの受信が完了したと判断することができる。
【０６９５】
例えば、それぞれのフラグメントを構成するフラグメントペイロードがまず受信された後にフラグメントヘッダーが受信されると、ＦＣフィールドは、当該パケットがフラグメントヘッダーの最後のデータを含んでいることを示すことができる。
【０６９６】
したがって、ＦＣフィールドが、パケットがフラグメントヘッダーの最後のデータを含んでいることを示すと、放送信号受信装置は、それぞれのフラグメントを構成するフラグメントヘッダー及びフラグメントペイロードの受信が完了したと判断し、フラグメントヘッダー及びフラグメントペイロードの復元を完了することができる。
【０６９７】
ＦＣフィールドが、当該パケットがフラグメントヘッダーの最後の部分のデータを含んでいないことを示すと、放送信号受信装置は、伝送ブロックを復元する手順を反復することができる。
【０６９８】
その後、放送信号受信装置は、フラグメント再生成器Ｃ２２０４０を用いて、少なくとも一つの伝送ブロックを組み合わせてフラグメントヘッダー及びフラグメントペイロードの復元を完了した後、フラグメントヘッダー及びフラグメントペイロードを組み合わせて、独立して復号化及び再生されるデータ単位であるフラグメントを復元することができる（ＣＳ２１０９０）。
【０６９９】
その後、本発明の一実施例に係る放送信号受信装置は、フラグメントパーサーＣ２２０５０を用いて、復元されたフラグメントをパースすることができる（ＣＳ２１０９０）。放送信号受信装置は、復元されたフラグメントをパースして少なくとも一つのメディアアクセスユニットを生成することができる。ただし、これに限定されず、放送信号受信装置は、伝送ブロックをパースして少なくとも一つのメディアアクセスユニットを生成することもできる。
【０７００】
その後、本発明の一実施例に係る放送信号受信装置は、メディアデコーダＣ２２０６０を用いて、少なくとも一つのメディアアクセスユニットを復号化してメディアデータを生成することができる（ＣＳ２１１００）。
【０７０１】
その後、本発明の一実施例に係る放送信号受信装置は、メディアレンダラＣ２２０７０を用いて、復号化されたメディアデータをレンダリングしてプレゼンテーションすることができる（ＣＳ２１１１０）。
【０７０２】
図４１は、本発明の一実施例に係るファイルベースマルチメディアコンテンツの実時間受信／消費の手順を示す図である。
【０７０３】
図４１では、図４０で説明された内容と実質的に同じ内容については具体的な説明を省略する。
【０７０４】
本発明の一実施例に係る放送信号受信装置は、ＦＨＬフィールドに基づいて、それぞれのフラグメントを構成するフラグメントヘッダー及びフラグメントペイロードの受信が完了したか否かを判断することができる。
【０７０５】
本発明の一実施例に係る放送信号受信装置は、フラグメント再生成器Ｃ２２０４０を用いて、フラグメント情報に基づいて復元された伝送ブロックがフラグメントヘッダーに該当する伝送ブロックであるか、或いはフラグメントペイロードに該当する伝送ブロックであるかを識別することができる（ＣＳ２２０５０）。
【０７０６】
その後、放送信号受信装置は、復元された伝送ブロックを組み合わせて、フラグメントペイロード及びフラグメントヘッダーをそれぞれ復元することができる。
【０７０７】
ＦＨフィールドが、当該パケットがフラグメントペイロードに該当するデータを含んでいることを示すと、放送信号受信装置は、少なくとも一つの伝送ブロックを組み合わせてフラグメントペイロードを復元することができる（ＣＳ２２０６０）。
【０７０８】
ＦＨフィールドが、当該パケットがフラグメントヘッダーに該当するデータを含んでいることを示すと、フラグメント再生成器Ｃ２２０４０は、少なくとも一つの伝送ブロックを組み合わせてフラグメントヘッダーを復元することができる（ＣＳ２２０７０）。
【０７０９】
その後、放送信号受信装置が、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの復元を完了すると、放送信号受信装置は、復元したフラグメントペイロード及びフラグメントヘッダーを組み合わせてフラグメントを復元することができる。
【０７１０】
放送信号受信装置は、フラグメント情報に含まれたＦＨＬフィールドに基づいて、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの復元が完了したか否かを確認することができる。
【０７１１】
放送信号受信装置は、それぞれのフラグメントを構成するパケットの数（Ｎ）をカウントすることができる（ＣＳ２２０８０）。例えば、放送信号受信装置は、フラグメントヘッダーのデータを含むパケットの数をカウントすることができる。一つのパケットは少なくとも一つのシンボルを含むことができるが、以下では一つのパケットが一つのシンボルを含む場合を中心に説明する。
【０７１２】
ＦＨＬフィールドは、フラグメントを構成するシンボルの数を示すことができる。ＦＨＬフィールドに記録されたシンボルの数に該当する数のパケットが受信されていないと、放送信号受信装置は、伝送ブロックを復元する手順を反復することができる。例えば、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了しないと、放送信号受信装置は伝送ブロックを復元する手順を反復することができる。
【０７１３】
フラグメント完了情報は、フラグメントヘッダーに該当する全シンボルの数を示すＦＨＬフィールドをさらに含む。
【０７１４】
ＦＨＬフィールドに記録された値とパケットの数が一致すると、放送信号受信装置は、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了したと判断し、フラグメントヘッダー及びフラグメントペイロードの復元を完了することができる（ＣＳ２２０９０）。
【０７１５】
例えば、ＦＨＬフィールドは、フラグメントヘッダー及びフラグメントペイロードの両方を含むそれぞれのフラグメントに該当する全シンボルの数を示すことができる。このとき、ＦＨＬフィールドに記録されたシンボルの数に該当する数のパケットが受信されると、放送信号受信装置は、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了したと判断することができる。
【０７１６】
例えば、ＦＨＬフィールドは、フラグメントヘッダー及びフラグメントペイロードのうち、後に伝送されるものの全シンボルの数を示すことができる。
【０７１７】
それぞれのフラグメントを構成するフラグメントペイロードがまず受信された後にフラグメントヘッダーが受信されると、ＦＨＬフィールドは、フラグメントヘッダーに該当する全シンボルの数を示すことができる。このとき、ＦＨＬフィールドに記録されたシンボルの数と受信されたフラグメントヘッダーに該当するパケットの数とが同一であれば、放送信号受信装置は、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了したと判断することができる。
【０７１８】
また、それぞれのフラグメントを構成するフラグメントヘッダーがまず受信された後にフラグメントペイロードが受信されると、ＦＨＬフィールドは、フラグメントペイロードに該当する全シンボルの数を示すことができる。このとき、ＦＨＬフィールドに記録されたシンボルの数と受信されたフラグメントペイロードに該当するパケットの数とが同一であれば、放送信号受信装置は、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了したと判断することができる。
【０７１９】
その後、それぞれのフラグメントを構成するフラグメントペイロード及びフラグメントヘッダーの受信が完了すると、放送信号受信装置は、フラグメントヘッダーとフラグメントペイロードとを組み合わせてフラグメントを復元することができる（ＣＳ２２１００）。
【０７２０】
以上、本発明の一実施例に係る、可変サイズのデータ単位である伝送ブロックを用いて、放送網でマルチメディアコンテンツを伝送ブロック単位で実時間伝送及び受信する実施例について説明した。
【０７２１】
以下では、本発明の他の実施例に係る、オブジェクト内部構造体の境界情報及びタイプ情報を用いて、放送網でマルチメディアコンテンツを可変サイズのオブジェクト内部構造体単位で実時間伝送及び受信する実施例を説明する。
【０７２２】
ただし、本発明の他の実施例の構成のうち、本発明の一実施例の構成と同じ名称は、前述した内容を全て含むことができ、その具体的な説明は省略する。また、図１乃至図４１で説明した内容は、以下の図４２乃至図５５にも適用することができる。
【０７２３】
＜伝送オブジェクトタイプの識別方案−１＞
図４２は、本発明の他の実施例に係るオブジェクトタイプ情報を含むパケットの構造を示す図である。
【０７２４】
本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクトフラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、伝送者現在時間存在フラグフィールド（Ｔ）、予想レジデュアル時間存在フラグフィールド（Ｒ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、ＦＥＣペイロードＩＤフィールド、及び／又はシンボルエンコーディングフィールドを含むことができる。
【０７２５】
本発明の他の実施例に係るパケットは、メタデータを含むパケット情報を含むことができる。パケット情報は、ＭＰＥＧ−ＤＡＳＨコンテンツ伝送時に現在パケットが送信しているオブジェクトの類型を示すオブジェクトタイプ情報を含むことができる。オブジェクトタイプ情報は、現在パケット又は同一ＴＯＩが与えられたパケットが送信しているオブジェクトのタイプを示すことができる。
【０７２６】
例えば、オブジェクトタイプ情報は、ＬＣＴパケットの開始地点で１２番目のビットに位置する２個の予約ビットを用いてオブジェクトタイプを識別することができる。
【０７２７】
ＭＰＥＧ−ＤＡＳＨコンテンツをＬＣＴパケットで伝送する場合、オブジェクトタイプは、レギュラーファイル、初期化セグメント、メディアセグメント及び／又は自己−初期化セグメントを含むことができる。
【０７２８】
例えば、オブジェクトタイプ情報の値が“００”であれば、オブジェクトタイプは“レギュラーファイル（Ｒｅｇｕｌａｒ  Ｆｉｌｅ）”を示し、オブジェクトタイプ情報の値が“０１”であれば、オブジェクトタイプは“初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）”を示し、オブジェクトタイプ情報の値が“１０”であれば、オブジェクトタイプは“メディアセグメント（Ｍｅｄｉａ  Ｓｅｇｍｅｎｔ）”を示し、オブジェクトタイプ情報の値が“１１”であれば、オブジェクトタイプは“自己−初期化セグメント（Ｓｅｌｆ−Ｉｎｉｔｉａｌｉｚｉｎｇ  Ｓｅｇｍｅｎｔ）”を示すことができる。
【０７２９】
それぞれのオブジェクトタイプ情報が示すオブジェクトのタイプは、送信しているファイルコンテンツによって異なってもよく、オブジェクトタイプ情報の値を定義するスキームは、現在伝送中のセッション又は帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）で別のシグナリング情報の形態で伝送されてもよい。
【０７３０】
レギュラーファイルは、マルチメディアコンテンツを構成する一般的なファイルのようなオブジェクト形態のデータ単位である。
【０７３１】
初期化セグメントは、リプレゼンテーションに接近するための初期化情報を含むオブジェクト形態のデータ単位である。初期化セグメントは、ファイルタイプボックス（ｆｔｙｐ）及びムービーボックス（ｍｏｏｖ）を含むことができる。ファイルタイプボックス（ｆｔｙｐ）は、ファイルタイプ、ファイルバージョン、及び互換性情報を含むことができる。ムービーボックス（ｍｏｏｖ）は、メディアコンテンツを記述するメタデータを含むことができる。
【０７３２】
メディアセグメントは、ストリーミングサービスを支援するために放送信号受信装置で伝送しようとする品質別、時間別に分離したメディア関連オブジェクト形態のデータ単位を意味する。メディアセグメントは、セグメントタイプボックス（ｓｔｙｐ）、セグメントインデックスボックス（ｓｉｄｘ）、ムービーフラグメントボックス（ｍｏｏｆ）、及びメディアデータボックス（ｍｄａｔ）を含むことができる。セグメントタイプボックス（ｓｔｙｐ）は、セグメントの類型情報を含むことができる。セグメントインデックスボックス（ｓｉｄｘ）は、当該メディアセグメントの内部に存在するメディアデータの最初のプレゼンテーション時間、データオフセット（ｏｆｆｓｅｔ）及びＳＡＰ（Ｓｔｒｅａｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔｓ）情報などを提供することができる。ムービーフラグメントボックス（ｍｏｏｆ）は、メディアデータボックス（ｍｄａｔ）に対するメタデータを含むことができる。メディアデータボックス（ｍｄａｔ）は、当該メディア構成要素（ビデオ及びオーディオなど）に対する実際メディアデータを含むことができる。
【０７３３】
自己−初期化セグメントは、初期化セグメントの情報及びメディアセグメントの情報の両方を含むオブジェクト形態のデータ単位を意味する。
【０７３４】
＜伝送オブジェクトタイプの識別方案−２＞
図４３は、本発明の他の実施例に係るオブジェクトタイプ情報を含むパケットの構造を示す図である。
【０７３５】
上述した方法に加えて、オブジェクトタイプ情報は、ＬＣＴヘッダー拡張を用いて、現在パケットが送信しているオブジェクトのタイプを識別することができる。ＬＣＴヘッダー拡張を用いるオブジェクトタイプ情報は、ＲＴＰ（ｒｅａｌｔｉｍｅ  ｐｒｏｔｏｃｏｌ）などを含む伝送プロトコルのためのパケットなどに適用することができる。
【０７３６】
オブジェクトタイプ情報は、ヘッダー拡張タイプ（ＨＥＴ）フィールド、タイプフィールド、及び／又は予約フィールドを含むことができる。
【０７３７】
ＨＥＴフィールドは８ビットの整数であってもよく、当該ヘッダー拡張のタイプを示すことができる。例えば、ＨＥＴフィールドは、１２８〜２５５の値の中から一つの固有値で当該ヘッダー拡張のタイプを識別することができ、この場合、ヘッダー拡張は、３２ビットの固定長を有することができる。
【０７３８】
タイプフィールドは、現在ＬＣＴパケット又は同一ＴＯＩが与えられたＬＣＴパケットが送信しているオブジェクトのタイプを示すことができる。以下では、タイプフィールドをオブジェクトタイプ情報と表現することができる。ＭＰＥＧ−ＤＡＳＨコンテンツをＬＣＴパケットで伝送する場合、オブジェクトタイプ情報の値によって、オブジェクトタイプは、レギュラーファイル、初期化セグメント、メディアセグメント、及び自己−初期化セグメントを含むことができる。
【０７３９】
例えば、オブジェクトタイプ情報の値が“０ｘ００”であれば、オブジェクトタイプは“レギュラーファイル”を示し、オブジェクトタイプ情報の値が“０ｘ０１”であれば、オブジェクトタイプは“初期化セグメント”を示し、オブジェクトタイプ情報の値が“０ｘ１０”であれば、オブジェクトタイプは“メディアセグメント”を示し、オブジェクトタイプ情報の値が“０ｘ１１”であれば、オブジェクトタイプは“自己−初期化セグメント”を示すことができる。
【０７４０】
予約フィールドは、将来の使用のために予約されたフィールドであってもよい。
【０７４１】
以下、具体的な内容は上述したとおりであり、その説明を省略する。
【０７４２】
図４４は、本発明の他の実施例に係るオブジェクトタイプ情報を用いる放送信号受信装置の構造を示す図である。
【０７４３】
放送信号受信装置は、オブジェクトタイプ情報に基づいてオブジェクトのタイプにしたがって別々の手順を行うことができる。すなわち、放送信号送信装置がＬＣＴパケットにオブジェクトタイプ情報を明示して伝送すると、放送信号受信装置は、オブジェクトタイプ情報に基づいて、受信したオブジェクトを識別し、オブジェクトのタイプ別に適切な動作を行うことができる。
【０７４４】
本発明の他の実施例に係る放送信号受信装置は、シグナリングデコーダＣ３２００５、パーサーＣ３２０５０、及び／又はデコーダＣ３２０６０を含むことができる。ただし、放送信号受信装置の構成要素はこれに限定されず、上述した構成要素をさらに含んでもよい。
【０７４５】
シグナリングデコーダＣ３２００５は、シグナリング情報をデコードすることができる。シグナリング情報は、マルチメディアコンテンツを含む放送信号を放送網を介して実時間で伝送するか否かを示す情報である。
【０７４６】
パーサーＣ３２０５０は、オブジェクトタイプ情報に基づいて少なくとも一つのオブジェクトをパースし、リプレゼンテーションに接近するための初期化情報及び少なくとも一つのアクセスユニットを生成することができる。そのために、パーサーＣ３２０５０は、初期化セグメントパーサーＣ３２０５１、メディアセグメントパーサーＣ３２０５２、及び／又は自己−初期化セグメントパーサーＣ３２０５３を含むことができる。初期化セグメントパーサーＣ３２０５１、メディアセグメントパーサーＣ３２０５２、及び自己−初期化セグメントパーサーＣ３２０５３に関する具体的な説明は、次の図面で後述する。
【０７４７】
デコーダＣ３２０６０は、初期化情報に基づいて当該デコーダＣ３２０６０を初期化することができる。また、デコーダＣ３２０６０は、少なくとも一つのオブジェクトを復号化することができる。このとき、デコーダＣ３２０６０は、オブジェクトに関する情報を少なくとも一つのアクセスユニットの形態で受信し、デコーダＣ３２０６０は、少なくとも一つのアクセスユニットを復号化してメディアデータを生成することができる。
【０７４８】
図４５は、本発明の他の実施例に係るオブジェクトタイプ情報を用いる放送信号受信装置の構造を示す図である。
【０７４９】
放送信号受信装置は、パケットフィルタＣ３２０１０、セグメントバッファＣ３２０３０、パーサーＣ３２０５０、デコーディングバッファＣ３２０５９、及び／又はデコーダＣ３２０６０を含むことができる。
【０７５０】
パケットフィルタＣ３２０１０は、受信された少なくとも一つのパケットからオブジェクトタイプ情報を識別し、オブジェクトタイプ情報に基づいて、それぞれのオブジェクトのタイプに該当する手順を行えるように分類することができる。
【０７５１】
例えば、オブジェクトタイプ情報が“１”であれば、パケットフィルタＣ３２０１０は、ＬＣＴパケットのデータをセグメントバッファＣ３２０３１を介して初期化セグメントパーサーＣ３２０５１に伝達し、オブジェクトタイプ情報が“２”であれば、パケットフィルタＣ３２０１０は、ＬＣＴパケットのデータをセグメントバッファＣ３２０３２を介してメディアセグメントパーサーＣ３２０５２に伝達し、伝送オブジェクトタイプ情報が“３”であれば、パケットフィルタＣ３２０１０は、ＬＣＴパケットのデータをセグメントバッファＣ３２０３３を介して自己−初期化セグメントパーサーＣ３２０５３に伝達することができる。
【０７５２】
セグメントバッファＣ３２０３０は、パケットフィルタからＬＣＴパケットのデータを受け取って、あらかじめ定められた時間記憶することができる。セグメントバッファＣ３２０３０は、一つの構成要素で構成されてもよく、複数のセグメントバッファＣ３２０３１，Ｃ３２０３２，Ｃ３２０３３で構成されてもよい。
【０７５３】
パーサーＣ３２０５０は、オブジェクトタイプ情報に基づいて少なくとも一つのオブジェクトをパースし、リプレゼンテーションに接近するための初期化情報及び少なくとも一つのアクセスユニットを生成することができる。そのために、パーサーＣ３２０５０は、初期化セグメントパーサーＣ３２０５１、メディアセグメントパーサーＣ３２０５２、及び／又は自己−初期化セグメントパーサーＣ３２０５３を含むことができる。
【０７５４】
初期化セグメントパーサーＣ３２０５１は、セグメントバッファＣ３２０３１に記憶された初期化セグメントをパースし、リプレゼンテーションに接近するための初期化情報を生成することができる。また、初期化セグメントパーサーＣ３２０５１は、自己−初期化セグメントパーサーＣ３２０５３から初期化セグメントを受け取って、リプレゼンテーションに接近するための初期化情報を生成することができる。
【０７５５】
メディアセグメントパーサーＣ３２０５２は、セグメントバッファＣ３２０３２に記憶されたメディアセグメントをパースし、メディアストリームの情報、少なくとも一つのアクセスユニット、及びプレゼンテーション時間又はインデックスのような当該セグメント内のメディアプレゼンテーションへの接近方法に関する情報を生成することができる。また、メディアセグメントパーサーＣ３２０５２は、自己−初期化セグメントパーサーＣ３２０５３からメディアセグメントを受け取って、メディアストリームの情報、少なくとも一つのアクセスユニット、及びプレゼンテーション時間又はインデックスのような当該セグメント内のメディアプレゼンテーションへの接近方法に関する情報を生成することができる。
【０７５６】
自己−初期化セグメントパーサーＣ３２０５３は、セグメントバッファＣ３２０３３に記憶された自己−初期化セグメントをパースし、初期化セグメント及びメディアセグメントを生成することができる。
【０７５７】
デコーディングバッファＣ３２０５９は、パーサーＣ３２０５０又はメディアセグメントパーサーＣ３２０５２から少なくとも一つのアクセスユニットを受け取って、あらかじめ定められた時間記憶することができる。
【０７５８】
デコーダＣ３２０６０は、初期化情報に基づいて当該デコーダＣ３２０６０を初期化することができる。また、デコーダＣ３２０６０は、少なくとも一つのオブジェクトを復号化することができる。このとき、デコーダＣ３２０６０は、オブジェクトに関する情報を少なくとも一つのアクセスユニットの形態で受信し、少なくとも一つのアクセスユニットを復号化してメディアデータを生成することができる。
【０７５９】
上述したように、ＭＰＥＧ−ＤＡＳＨコンテンツを伝送する時、本発明の他の実施例に係る放送信号送信装置は、現在パケットで送信しているオブジェクトのタイプを示すオブジェクトタイプ情報を伝送することができる。また、放送信号受信装置は、オブジェクトタイプ情報に基づいて、受信したパケットからオブジェクトの類型を識別し、各オブジェクトに適切なプロセスを行うことができる。
【０７６０】
＜オブジェクト内部構造体のタイプ＞
図４６は、本発明の他の実施例に係るタイプ情報を含むパケットの構造を示す図である。
【０７６１】
放送信号送信装置が、独立して有意な単位であるオブジェクト内部構造体（Ｏｂｊｅｃｔ  Ｉｎｔｅｒｎａｌ  Ｓｔｒｕｃｔｕｒｅ）の単位でデータを伝送すると、可変サイズでデータを伝送することができる。したがって、放送信号受信装置が一つのオブジェクトを全て受信する前であっても、オブジェクト内部構造体を受信及び識別すると、放送信号受信装置はオブジェクト内部構造体単位で再生することができる。その結果、マルチメディアコンテンツを放送網を介して実時間で伝送及び再生することができる。本発明の他の実施例によれば、オブジェクト内部構造体を識別するために、タイプ情報（Ｔｙｐｅ  ｉｎｆｏｒｍａｔｉｏｎ）及び境界情報（Ｂｏｕｎｄａｒｙ  Ｉｎｆｏｒｍａｔｉｏｎ）を用いることができる。
【０７６２】
以下では、オブジェクト内部構造体を識別するためのタイプ情報について具体的に説明する。
【０７６３】
ＭＰＥＧ−ＤＡＳＨコンテンツを伝送するとき、パケット情報は、ＬＣＴヘッダー拡張を用いてタイプ情報を含むことができる。タイプ情報は、現在パケットが送信しているオブジェクトの内部構造体のタイプを示すことができる。タイプ情報は、オブジェクトタイプ情報との区別のために、内部構造体タイプ情報と呼ぶことができる。タイプ情報は、ＲＴＰ（ｒｅａｌｔｉｍｅ  ｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用することができる。
【０７６４】
タイプ情報は、ヘッダー拡張タイプフィールド（ＨＥＴ）、内部ユニットタイプフィールド、及び／又は予約フィールドを含むことができる。
【０７６５】
ＨＥＴフィールドは上述したとおりであり、その具体的な説明は省略する。
【０７６６】
内部構造体タイプフィールドは、ＬＣＴパケットが送信しているオブジェクト内部構造体のタイプを示すことができる。
【０７６７】
オブジェクトはＭＰＥＧ−ＤＡＳＨのセグメントに該当し得るが、オブジェクト内部構造体は、オブジェクトを構成する下位構成要素に該当する。例えば、オブジェクト内部構造体のタイプは、フラグメント、チャンク（ｃｈｕｎｋ）又はＧＯＰ、アクセスユニット、及びＮＡＬユニットを含むことができる。オブジェクト内部構造体のタイプは、これに限定されず、有意な単位をさらに含んでもよい。
【０７６８】
フラグメントとは、以前（ｐｒｅｃｅｄｉｎｇ）のデータに対する依存性無しで独立して復号化及び再生可能なデータ単位を意味する。又は、フラグメントは、一対のムービーフラグメントボックス（ｍｏｏｆ）及びメディアデータコンテナボックス（ｍｄａｔ）を含むデータ単位を意味してもよい。例えば、フラグメントは、ＭＰＥＧ−ＤＡＳＨのサブセグメント（Ｓｕｂｓｅｇｍｅｎｔ）に該当してもよく、ＭＭＴのフラグメントに該当してもよい。フラグメントは、少なくとも一つのチャンク又は少なくとも一つのＧＯＰを含むことができる。
【０７６９】
チャンクは、同じメディアタイプを有する隣接したサンプルの集合であり、可変サイズのデータ単位である。
【０７７０】
ＧＯＰは、ビデオコーディングで用いられるコーディングを行う基本単位であり、少なくとも一つのＩ−フレームを含むフレームの集合を示す可変サイズのデータ単位である。本発明の他の実施例によれば、メディアデータを独立して有意なデータ単位であるオブジェクト内部構造体の単位で伝送するので、ＧＯＰはオープンＧＯＰ及びクローズドＧＯＰを含むことができる。
【０７７１】
オープンＧＯＰで、一つのＧＯＰ内にあるＢ−フレームは、隣接したＧＯＰのＩ−フレーム又はＰ−フレームを参照することができる。したがって、オープンＧＯＰは、コーディング効率を大きく向上させることができる。クローズドＧＯＰで、Ｂ−フレーム又はＰ−フレームは、当該ＧＯＰ内にあるフレームだけを参照し、当該ＧＯＰ外にあるフレームは参照しない。
【０７７２】
アクセスユニットは、符号化されたビデオ又はオーディオの基本データ単位を意味し、一つの映像フレーム又はオーディオフレームを含むことができる。
【０７７３】
ＮＡＬユニットは、ネットワーク機器との通信を考慮して圧縮されたスライスに関する要約情報などが含まれてカプセル化された圧縮されたビデオストリームである。例えば、ＮＡＬユニットスライス、パラメータセット、及びＳＥＩなどのデータをバイト単位でパケット化したデータ単位であってもよい。
【０７７４】
予約フィールドは、将来の使用のために予約されたフィールドであってもよい。
【０７７５】
以下では、説明の便宜のために、内部構造体タイプフィールドをタイプ情報と表現することができる。
【０７７６】
＜オブジェクト内部構造体の境界＞
図４７は、本発明の他の実施例に係る境界情報を含むパケットの構造を示す図である。
【０７７７】
以下では、オブジェクト内部構造体を識別するための境界情報について具体的に説明する。
【０７７８】
ＭＰＥＧ−ＤＡＳＨコンテンツを伝送するとき、パケット情報は、ＬＣＴヘッダー拡張を用いて境界情報を含むことができる。境界情報は、現在パケットが送信しているオブジェクト内部構造体の境界を示すことができる。境界情報は、ＲＴＰ（ｒｅａｌｔｉｍｅ  ｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用することができる。
【０７７９】
境界情報は、ヘッダー拡張タイプフィールド（ＨＥＴ）、開始フラグフィールド（ＳＦ）、予約フィールド、及び／又はオフセットフィールドを含むことができる。
【０７８０】
ＨＥＴフィールドは上述したとおりであり、その具体的な説明は省略する。
【０７８１】
開始フラグフィールド（ＳＦ）は、ＬＣＴパケットがオブジェクト内部構造体の開始地点を含んでいるか否かを示すことができる。
【０７８２】
予約フィールドは、将来の使用のために予約されたフィールドであってもよい。
【０７８３】
オフセットフィールドは、ＬＣＴパケット内でオブジェクト内部構造体の開始地点の位置を示す位置情報を含むことができる。位置情報は、ＬＣＴパケットのペイロード開始地点からオブジェクト内部構造体の開始地点までのバイト（ｂｙｔｅ）距離を含むことができる。
【０７８４】
上述したように、放送信号送信装置は、タイプ情報及び境界情報に基づいて、オブジェクト単位でデータを伝送しないで、可変長のオブジェクト内部構造体の単位でデータを伝送することができる。
【０７８５】
放送信号受信装置は、オブジェクト単位でデータを受信して再生するのではなく、可変長のオブジェクト内部構造体の単位でデータを受信して再生することができる。したがって、放送信号受信装置は、タイプ情報及び境界情報に基づいてオブジェクト内部構造体を識別し、受信したオブジェクト内部構造体別に再生することができる。
【０７８６】
例えば、放送信号受信装置は、境界情報で表現されたオブジェクト内部構造体の開始と終了地点に該当するパケット又はその間で伝送される少なくとも一つのパケットに含まれたタイプ情報に基づいて、現在オブジェクト内部構造体のタイプを識別することができる。
【０７８７】
その結果、放送信号受信装置は、一つのオブジェクトを全て受信する前にも、オブジェクト内部構造体を迅速に識別することができ、実時間再生することができる。
【０７８８】
＜伝送オブジェクトとシグナリング情報のマッピング＞
図４８は、本発明の他の実施例に係るマッピング情報を含むパケットの構造を示す図である。
【０７８９】
本発明の他の実施例によれば、上述したタイプ情報及び境界情報の他にも、マッピング情報を用いてオブジェクト内部構造体を識別することができる。
【０７９０】
ＤＡＳＨコンテンツを伝送するとき、パケット情報は、ＬＣＴヘッダー拡張を用いてマッピング情報を含むことができる。マッピング情報は、現在パケットが送信しているセッション、オブジェクト、及びオブジェクト内部構造体のうち少なくとも一つを、伝送セッション識別子（ＴＳＩ）及び伝送オブジェクト識別子（ＴＯＩ）のうち少なくとも一つにマップさせる情報である。マッピング情報は、ＲＴＰ（ｒｅａｌｔｉｍｅ  ｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用することができる。
【０７９１】
本発明の一実施例に係るマッピング情報は、ヘッダー拡張タイプフィールド（ＨＥＴ）、ヘッダー拡張長さフィールド（ＨＥＬ）、及びＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）フィールド（ＵＲＬ）を含むことができる。
【０７９２】
ＨＥＴフィールドは上述したとおりであり、その具体的な説明は省略する。
【０７９３】
ＨＥＬフィールドは、可変長のＬＣＴヘッダー拡張の全長を示す。基本的に、ＬＣＴではＨＥＴが０〜１２７の値を有する場合、３２ビットワード単位の可変長ヘッダー拡張が存在し、ＨＥＴフィールドに続くＨＥＬフィールドは、ＬＣＴヘッダー拡張の全長を３２ビットワード単位で示す。
【０７９４】
ＵＲＬフィールドは可変長を有することができ、現在伝送中のセッション、オブジェクト、及びオブジェクト内部構造体のインターネット上の固有アドレスを含むことができる。
【０７９５】
以下では、説明の便宜上、ＵＲＬフィールドをマッピング情報と表現することができる。
【０７９６】
マッピング情報は、シグナリング情報のＵＲＬを示すことができる。また、マッピング情報は、セッション、オブジェクト、又はオブジェクト内部構造体の固有なアドレスだけでなく、シグナリング情報で割り当てられた識別子を含むことができる。識別子は、ピリオド（ｐｅｒｉｏｄ）ＩＤ、適応セットＩＤ、リプレゼンテーションＩＤ、及びコンポーネントＩＤを含むことができる。したがって、ＭＰＥＧ−ＤＡＳＨコンテンツの場合、マッピング情報は、セグメントＵＲＬ、リプレゼンテーションＩＤ、コンポーネントＩＤ、適応セットＩＤ、及びピリオド（ｐｅｒｉｏｄ）ＩＤなどを含むことができる。
【０７９７】
より完璧なマッピングのために、本発明の他の実施例に係るシグナリング情報は、識別子又はオブジェクトのＵＲＬをＴＯＩ又はＴＳＩにそれぞれマップするマッピング情報をさらに含むことができる。すなわち、シグナリング情報は、現在送信しているＴＯＩ及びＴＳＩが、識別子又はオブジェクトのＵＲＬのいずれにマップされるかを示す情報をさらに含むことができる。このとき、マッピング情報は、識別子又はオブジェクトのＵＲＬとＴＯＩ又はＴＳＩとを、１：１、１：多、又は多：１のいずれかでマップする情報であってもよい。
【０７９８】
＜伝送セッション及び伝送オブジェクトのグルーピング方案＞
図４９は、本発明の他の実施例に係るグルーピング情報を含むＬＣＴパケットの構造を示す図である。
【０７９９】
本発明の他の実施例によれば、上述した方法の他にも、グルーピング情報を用いてオブジェクト内部構造体を識別することができる。
【０８００】
本発明の他の実施例に係るＬＣＴパケットは、セッショングループ識別子フィールド（ＳＧＩ）及び分割された伝送セッション識別子フィールド（ＤＴＳＩ）を含むことができる。ＳＧＩ及びＤＴＳＩは、既存の伝送セッション識別子フィールド（ＴＳＩ）を分割した形態である。
【０８０１】
また、本発明の他の実施例に係るＬＣＴパケットは、オブジェクトグループ識別子フィールド（ＯＧＩ）及び分割された伝送オブジェクト識別子フィールド（ＤＴＯＩ）を含むことができる。ＯＧＩ及びＤＴＯＩは、既存の伝送オブジェクト識別子フィールド（ＴＯＩ）を分割した形態である。
【０８０２】
Ｓフィールドは、既存のＴＳＩフィールドの長さを示し、Ｏフィールドは、既存のＴＯＩの長さを示し、Ｈフィールドは、既存のＴＳＩフィールド及び既存のＴＯＩフィールドの長さにハーフワード（１６ビット）を追加するか否かを示す。
【０８０３】
したがって、ＳＧＩフィールドとＤＴＳＩフィールドとの全長は、既存のＴＳＩフィールドと同一であり、ＳフィールドとＨフィールドの値に基づいて定めることができる。また、ＯＧＩフィールドとＤＴＯＩフィールドとの全長は、既存のＴＯＩフィールドと同一であり、ＯフィールドとＨフィールドの値に基づいて定められてもよい。
【０８０４】
本発明の他の実施例によれば、既存のＴＳＩ及びＴＯＩをＳＧＩ、ＤＴＳＩ、ＯＧＩ、及びＤＴＯＩに細分化し、ＳＧＩ、ＤＴＳＩ、ＯＧＩ、及びＤＴＯＩはそれぞれ異なるデータ単位を識別することができる。
【０８０５】
ＳＧＩ、ＤＴＳＩ、ＯＧＩ、及びＤＴＯに関する具体的な内容は、次の図面で後述する。
【０８０６】
図５０は、本発明の他の実施例に係るセッション及びオブジェクトのグルーピングを示す図である。
【０８０７】
メディアプレゼンテーション記述（ＭＰＤ）は、ＭＰＥＧ−ＤＡＳＨコンテンツをストリーミングサービスとして提供するためのエレメントである。例えば、上述したプレゼンテーションは、一つのサービスに対応する概念であり、ＭＰＥＧ−ＤＡＳＨのＭＰＤ及びＭＭＴのパッケージに該当してもよい。ＭＰＤ  Ｃ４００００は、少なくとも一つのピリオドを含むことができる。例えば、ＭＰＤ  Ｃ４００００は、第１ピリオドＣ４１０００及び第２ピリオドＣ４２０００を含むことができる。
【０８０８】
ピリオドは、ＭＰＥＧ−ＤＡＳＨコンテンツを再生時間で区分したエレメントである。利用可能なビットレート、言語、キャプション、及びサブタイトルなどはピリオド内で変わらない。各ピリオドは開始時間情報を含むことができ、ＭＰＤ内で開始時間の昇順で整列されてもよい。例えば、第１ピリオドＣ４１０００は、０〜３０ｍｉｎ区間のエレメントであり、第２ピリオドＣ４２０００は、３０〜６０ｍｉｎ区間のエレメントである。ピリオドは、下位要素として少なくとも一つのＡｄａｐｔａｔｉｏｎＳｅｔ（図示せず）を含むことができる。
【０８０９】
ＡｄａｐｔａｔｉｏｎＳｅｔは、相互交替可能なエンコードされたバージョンの少なくとも一つのメディアコンテンツコンポーネントの集合である。ＡｄａｐｔａｔｉｏｎＳｅｔは、下位要素として少なくとも一つのリプレゼンテーションを含むことができる。例えば、ＡｄａｐｔａｔｉｏｎＳｅｔは、第１リプレゼンテーションＣ４１１００、第２リプレゼンテーションＣ４１２００、及び第３リプレゼンテーションＣ４１３００を含むことができる。
【０８１０】
リプレゼンテーションは、少なくとも一つのメディアコンテンツコンポーネントの伝送可能なエンコードされたバージョンのエレメントを示し、少なくとも一つのメディアストリームを含むことができる。メディアコンテンツコンポーネントは、ビデオコンポーネント、オーディオコンポーネント、及びキャプションコンポーネントを含むことができる。リプレゼンテーションは、メディアコンテンツコンポーネントの品質に関する情報を含むことができる。したがって、放送信号受信装置は、ネットワーク環境に適応するために一つのＡｄａｐｔａｔｉｏｎＳｅｔ内でリプレゼンテーションを変更することができる。
【０８１１】
例えば、第１リプレゼンテーションＣ４１１００は、周波数の帯域幅（ｂａｎｄｗｉｄｔｈ）が５００ｋｂｉｔ／ｓであるビデオコンポーネントであり、第２リプレゼンテーションＣ４１２００は、周波数の帯域幅が２５０ｋｂｉｔ／ｓであるビデオコンポーネントであり、第３リプレゼンテーションＣ４１３００は、周波数の帯域幅が７５０ｋｂｉｔ／ｓであるビデオコンポーネントであってもよい。リプレゼンテーションは、下位要素として少なくとも一つのセグメントを含むことができる。例えば、第１リプレゼンテーションＣ４１１００は、第１セグメントＣ４１１１０、第２セグメントＣ４１１２０、及び第３セグメントＣ４１１３０を含むことができる。
【０８１２】
セグメントは、一度のＨＴＴＰ要求で検索（ｒｅｔｒｉｅｖｅ）可能な最大のデータ単位のエレメントを示す。ＵＲＬは、それぞれのセグメントに提供されてもよい。例えば、上述したオブジェクトは、ファイル、初期化セグメント、メディアセグメント、又は自己−初期化セグメントに対応する概念であり、ＭＰＥＧ−ＤＡＳＨのセグメントに該当し、ＭＭＴのＭＰＵに該当し得る。各セグメントは、下位要素として少なくとも一つのフラグメントを含むことができる。例えば、第２セグメントＣ４１１２０は、第１フラグメントＣ４１１２２、第２フラグメントＣ４１１２４、及び第３フラグメントＣ４１１２６を含むことができる。
【０８１３】
フラグメントは、以前（ｐｒｅｃｅｄｉｎｇ）のデータに対する依存性無しで独立して復号化及び再生可能なデータ単位を意味する。例えば、フラグメントは、ＭＰＥＧ−ＤＡＳＨのサブセグメント（Ｓｕｂｓｅｇｍｅｎｔ）及びＭＭＴのフラグメントに該当し得る。フラグメントは、少なくとも一つのチャンク又は少なくとも一つのＧＯＰを含むことができる。例えば、第１フラグメントＣ４１１２２は、フラグメントヘッダー及びフラグメントペイロードを含むことができる。フラグメントヘッダーは、セグメントインデックスボックス（ｓｉｄｘ）及びムービーフラグメントボックス（ｍｏｏｆ）を含むことができる。フラグメントペイロードは、メディアデータコンテナボックス（ｍｄａｔ）を含むことができる。メディアデータコンテナボックス（ｍｄａｔ）は、第１チャンク乃至第５チャンクを含むことができる。
【０８１４】
チャンクは、同じメディアタイプを有する隣接したサンプルの集合であり、可変サイズのデータ単位である。
【０８１５】
上述した本発明の一実施例によれば、ＴＳＩが伝送セッションを識別し、各リプレゼンテーションを各ＴＳＩにマップすることができる。ＴＯＩが伝送セッション内にある伝送オブジェクトを識別し、各セグメントを各ＴＯＩにマップすることができる。
【０８１６】
一方、本発明の他の実施例によれば、ＴＳＩをＧＳＩ及びＤＴＳＩに分割し、ＴＯＩをＯＧＩ及びＤＴＯＩに分割して、それぞれのＧＳＩ、ＤＴＳＩ、ＧＯＩ、及びＤＴＯＩをそれぞれ新しいデータ単位にマップしてもよいが、以下の実施例に限定されない。
【０８１７】
例えば、ＳＧＩは同一の伝送セッションのグループを識別し、各ピリオドは各ＳＧＩにマップされてもよい。第１ピリオドＣ４１０００は、ＳＧＩの値が“１”にマップされ、第２ピリオドＣ４２０００は、ＳＧＩの値が“２”にマップされてもよい。ＳＧＩの値は、上述した実施例に限定されず、ピリオドを識別する値であるピリオドＩＤと同じ値を有することができる。
【０８１８】
ＤＴＳＩは伝送セッションを識別し、各リプレゼンテーションは各ＤＴＳＩにマップされてもよい。第１リプレゼンテーションＣ４１１００は、ＤＴＳＩの値が“１”にマップされ、第２リプレゼンテーションＣ４１２００は、ＤＴＳＩの値が“２”にマップされ、第３リプレゼンテーションＣ４１３００は、ＤＴＳＩの値が“３”にマップされてもよい。ＤＴＳＩの値は、上述した実施例に限定されず、リプレゼンテーションを識別する値であるリプレゼンテーションＩＤと同じ値を有することができる。
【０８１９】
ＯＧＩは、伝送セッション内で同一のオブジェクトのグループを識別し、各セグメントは各ＯＧＩにマップされてもよい。第１セグメントＣ４１１１０は、ＯＧＩの値が“１”にマップされ、第２セグメントＣ４１１２０は、ＯＧＩの値が“２”にマップされ、及び第３セグメントＣ４１１３０は、ＯＧＩの値が“３”にマップされてもよい。
【０８２０】
ＤＴＯＩはデリバリオブジェクト（Ｄｅｌｉｖｅｒｙ  Ｏｂｊｅｃｔ）を識別することができる。一つのデリバリオブジェクトは、一つのＩＳＯ  ＢＭＦＦファイル又は一つのＩＳＯ  ＢＭＦＦファイルの一部であってもよい。一つのＩＳＯ  ＢＭＦＦファイルの一部は、フラグメント、ＧＯＰ、チャンク、アクセスユニット、及び／又はＮＡＬユニットを含むことができる。
【０８２１】
例えば、フラグメントヘッダー、及びフラグメントペイロードの各チャンク又は各ＧＯＰは、各ＤＴＯＩにマップされてもよい。第１フラグメントＣ４１１２２のヘッダーは、ＤＴＯＩの値が“０”にマップされ、第１フラグメントＣ４１１２２のペイロード内にある第１チャンク乃至第５チャンクは、ＤＴＯＩの値が“１０”乃至“１４”にマップされてもよい。
【０８２２】
ＤＴＯＩの場合、与えられた値によって用法を定義することができる。例えば、ＤＴＯＩ値は、オブジェクトの配列順序にしたがって昇順又は降順の値に設定することができる。この場合、放送信号受信装置は、ＤＴＯＩ値に基づいてオブジェクトを再配列し、フラグメント又はセグメントを生成することができる。また、特定のＤＴＯＩの値はフラグメントヘッダーを示すことができる。この場合、放送信号送信装置又は放送信号受信装置は、当該ＤＴＯＩの値に基づいてフラグメントヘッダーの伝送が完了したか否かを判断することができる。
【０８２３】
デリバリオブジェクトが一つのセグメントを意味する場合、デリバリオブジェクトのグループは、ＤＡＳＨリプレゼンテーションのようなコンテンツコンポーネントに該当してもよい。この場合、ＤＴＯＩはセグメントにマップされ、ＯＧＩはリプレゼンテーションにマップされてもよい。例えば、ＯＧＩはリプレゼンテーションＩＤ、コンテンツコンポーネントＩＤなどに一対一マップされて、一つのセッション内で伝送されるコンテンツコンポーネントをマルチプレクス／デマルチプレクスするための情報として用いられてもよい。
【０８２４】
図５１は、本発明の他の実施例に係るパケット情報を用いた放送信号送信装置の構造を示す図である。
【０８２５】
放送信号送信装置は、シグナリングエンコーダＣ３１００５、内部構造体生成器Ｃ３１０３０、パケット情報生成器Ｃ３１０３５及び／又は送信器Ｃ３１０５０を含むことができる。
【０８２６】
シグナリングエンコーダＣ３１００５は、マルチメディアコンテンツを含む放送信号を放送網を介して実時間で伝送するか否かを示すシグナリング情報を生成することができる。シグナリング情報は、ファイルレベル又はＦＤＴレベルのうち少なくとも一つでマルチメディアコンテンツを実時間で送信することを示すことができる。シグナリング情報がファイルレベルでマルチメディアコンテンツを実時間で送信することを示すと、当該ファイルに属する全データを実時間で伝送することができる。また、シグナリング情報がＦＤＴレベルでマルチメディアコンテンツを実時間で送信することを示すと、当該ＦＤＴに属する全ファイル又はデータを実時間で伝送することができる。
【０８２７】
内部構造体生成器Ｃ３１０３０は、独立して符号化及び復号化されるデータ単位である少なくとも一つのオブジェクト内部構造体を生成することができる。オブジェクト内部構造体は、マルチメディアコンテンツを構成するファイルが少なくとも一つのデータ単位で分割されたものである。
【０８２８】
パケット情報生成器Ｃ３１０３５は、シグナリング情報がマルチメディアコンテンツを実時間で送信することを示す場合、オブジェクト内部構造体を識別するメタデータを含むパケット情報を生成することができる。ここで、パケット情報は、マルチメディアコンテンツを送信するパケットに関するメタデータを含み、オブジェクト内部構造体を識別するメタデータを含むことができる。パケット情報は、オブジェクト内部構造体の境界を示す境界情報、及びオブジェクト内部構造体のタイプを示すタイプ情報を含むことができる。
【０８２９】
境界情報は、当該パケットにオブジェクト内部構造体の開始地点が含まれているか否かを示す開始フラグ（ＳＦ）フィールド、及び当該パケット内で上記オブジェクト内部構造体の開始地点の位置を示すオフセットフィールドを含むことができる。
【０８３０】
オブジェクト内部構造体のタイプは、一対のムービーフラグメントボックス（ｍｏｏｆ）及びメディアデータコンテナボックス（ｍｄａｔ）を含むデータ単位を示すフラグメント、同一のメディアタイプを有する隣接したサンプルの集合を示すチャンク、少なくとも一つのＩ−フレームを含むフレームの集合を示すＧＯＰ、符号化されたビデオ又はオーディオの基本データ単位を示すアクセスユニット、及びバイト（ｂｙｔｅ）単位でパケット化したデータ単位を示すＮＡＬユニットのうち一つを含むことができる。
【０８３１】
また、パケット情報は、セッション、オブジェクト、及びオブジェクト内部構造体のうち少なくとも一つを伝送セッション識別子（ＴＳＩ）及び伝送オブジェクト識別子（ＴＯＩ）のうち少なくとも一つにマップさせるマッピング情報を含むことができる。
【０８３２】
また、パケット情報は、パケットが送信する伝送オブジェクト及び伝送セッションをグルーピングするグルーピング情報を含むことができる。グルーピング情報は、伝送セッションを識別する分割された伝送セッション識別子（ＤＴＳＩ）フィールド、同一の伝送セッションのグループを識別するセッショングループ識別子（ＳＧＩ）フィールド、伝送オブジェクトを識別する分割された伝送オブジェクト識別子（ＤＴＯＩ）フィールド、及び同一の伝送オブジェクトのグループを識別するオブジェクトグループ識別子（ＯＧＩ）フィールドを含むことができる。ここで、ＳＧＩフィールドは、ＭＰＥＧ−ＤＡＳＨのピリオドエレメントを識別する情報を含み、ＤＴＳＩフィールドは、ＭＰＥＧ−ＤＡＳＨのリプレゼンテーションエレメントを識別する情報を含み、ＯＧＩフィールドは、ＭＰＥＧ−ＤＡＳＨのセグメントエレメントを識別する情報を含み、及びＤＴＯＩフィールドは、ＭＰＥＧ−ＤＡＳＨのチャンクエレメントを識別する情報を含むことができる。
【０８３３】
上述したように、パケット情報は、タイプ情報、境界情報、マッピング情報、及びグルーピング情報に基づいて、セッション、オブジェクト、及びオブジェクト内部構造体のうち少なくとも一つを識別することができる。
【０８３４】
放送信号送信装置は、パケタイザ（図示せず）をさらに含むことができる。パケタイザは、オブジェクト内部構造体を同一サイズの少なくとも一つのシンボルに分割し、それぞれの少なくとも一つのシンボルを少なくとも一つのパケットにパケット化することができる。ただし、これに限定されず、シンボルは他の装置によって生成されてもよい。本発明の他の実施例に係るシンボルの長さは同一であってもよい。その後、パケタイザは、少なくとも一つのシンボルを少なくとも一つのパケットにパケット化することができる。例えば、パケットはＬＣＴパケットであってもよい。パケットはパケットヘッダー及びパケットペイロードを含むことができる。
【０８３５】
パケットヘッダーは、オブジェクト内部構造体を識別するパケット情報を含むことができる。
【０８３６】
送信器Ｃ３１０５０は、オブジェクト内部構造体及びパケット情報を含む放送信号を伝送することができる。
【０８３７】
図５２は、本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。
【０８３８】
以下では、放送信号送信装置と共通する部分は省略し、相違点を中心に説明する。
【０８３９】
放送信号受信装置は、パケット情報に基づいてオブジェクト内部構造体を識別し、受信したオブジェクト内部構造体単位で復号化を行うことができる。したがって、放送信号受信装置は、一つのオブジェクトを全て受信しないで、オブジェクト内部構造体だけを受信することでも、オブジェクト内部構造体を再生することができる。
【０８４０】
本発明の他の実施例に係る放送信号受信装置は、シグナリングデコーダＣ３２００５、抽出器Ｃ３２０５０、及び／又はデコーダＣ３２０６０を含むことができる。ただし、放送信号受信装置は、上述した構成要素をさらに含んでもよい。
【０８４１】
シグナリングデコーダＣ３２００５は、シグナリング情報をデコードすることができる。シグナリング情報は、マルチメディアコンテンツを含む放送信号を放送網を介して実時間で伝送するか否かを示す情報である。
【０８４２】
抽出器Ｃ３２０５０は、放送信号からオブジェクト内部構造体を識別し、オブジェクト内部構造体を抽出することができる。抽出器Ｃ３２０５０は、パケット情報に基づいて、一つのオブジェクトが全て受信される前であっても、オブジェクト内部構造体を抽出してデコーダＣ３２０６０に伝達することができる。ただし、オブジェクト内部構造体のタイプによって抽出器Ｃ３２０５０の動作が異なってもよい。上述したパーサーＣ３２０５０は、抽出器Ｃ３２０５０と同じ動作を行うことができ、抽出器Ｃ３２０５０をパーサーＣ３２０５０と表現してもよい。
【０８４３】
抽出器Ｃ３２０５０は、タイプ情報及び境界情報に基づいて現在オブジェクト内部構造体のタイプを識別することができる。例えば、抽出器Ｃ３２０５０は、境界情報で表現されたオブジェクト内部構造体の開始と終了地点に該当するパケット又はその間で伝送される少なくとも一つのパケットに含まれたタイプ情報に基づいて、現在オブジェクト内部構造体のタイプを識別することができる。
【０８４４】
抽出器Ｃ３２０５０は、オブジェクトバッファ又はセグメントバッファに記憶されたオブジェクト内部構造体であるフラグメント、チャンク又はＧＯＰ、及びアクセスユニットのうち少なくとも一つを抽出することができる。そのために、抽出器Ｃ３２０５０は、アクセスユニットを抽出するＡＵ抽出器Ｃ３２０５６、チャンク又はＧＯＰを抽出するチャンク抽出器Ｃ３２０５７、及びフラグメントを抽出するフラグメント抽出器Ｃ３２０５８をさらに含むことができる。抽出器Ｃ３２０５０の下位構成要素は、次の図面で具体的に後述する。
【０８４５】
デコーダＣ３２０６０は、オブジェクト内部構造体を受信し、タイプ情報に基づいて、当該オブジェクト内部構造体をデコードすることができる。このとき、デコーダＣ３２０６０は、オブジェクト内部構造体に関する情報を少なくとも一つのアクセスユニットの形態で受信し、少なくとも一つのアクセスユニットを復号化してメディアデータを生成することができる。
【０８４６】
図５３は、本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。
【０８４７】
以下では、オブジェクト内部構造体のタイプがアクセスユニットである場合の放送信号受信装置の動作及び構成について説明する。
【０８４８】
放送信号受信装置は、パケットデパケタイザＣ２２０２０、セグメントバッファＣ３２０３０、ＡＵ抽出器Ｃ３２０５６、デコーディングバッファＣ３２０５９、及び／又はデコーダＣ３２０６０をさらに含むことができる。
【０８４９】
パケットデパケタイザＣ２２０２０は、少なくとも一つのパケットをデパケット化して、パケットヘッダーに含まれたパケット情報を抽出することができる。例えば、パケットデパケタイザＣ２２０２０は、パケットヘッダーに含まれたタイプ情報及び境界情報を抽出することができ、パケットペイロードに含まれた少なくとも一つのシンボルを抽出することができる。少なくとも一つのシンボルは、オブジェクト内部構造体を構成するシンボルであってもよく、オブジェクトを構成するシンボルであってもよい。
【０８５０】
パケットデパケタイザＣ２２０２０は、抽出した少なくとも一つのオブジェクト又は少なくとも一つのオブジェクト内部構造体をデコーダＣ３２０６０に伝達することができる。
【０８５１】
セグメントバッファＣ３２０３０は、パケットデパケタイザＣ２２０２０からＬＣＴパケットのデータを受け取って、あらかじめ定められた時間記憶することができる。セグメントバッファＣ３２０３０は、オブジェクトバッファＣ３２０３０と表現することができる。また、セグメントバッファＣ３２０３０は、ＡＵ抽出器Ｃ３２０５６、チャンク抽出器（図示せず）、及び／又はフラグメント抽出器（図示せず）をさらに含むことができる。また、セグメントバッファＣ３２０３０は、フラグメントバッファ（図示せず）及び／又はチャンクバッファ（図示せず）をさらに含むことができる。
【０８５２】
タイプ情報が、オブジェクト内部構造体のタイプがアクセスユニットであることを示すと、セグメントバッファＣ３２０３０は、ＡＵ抽出器Ｃ３２０５６を含むことができる。ただし、これに限定されず、ＡＵ抽出器Ｃ３２０５６はセグメントバッファＣ３２０３０と独立して存在してもよい。
【０８５３】
ＡＵ抽出器Ｃ３２０５６は、境界情報に基づいてセグメントバッファＣ３２０３０に記憶されたアクセスユニットを抽出することができる。例えば、一つのアクセスユニットは、境界情報が示すアクセスユニットの開始地点から次のアクセスユニットの開始地点以前までであってもよい。
【０８５４】
その後、ＡＵ抽出器Ｃ３２０５６は、抽出したアクセスユニットをデコーディングバッファＣ３２０５９を通してデコーダＣ３２０６０に伝達することができる。
【０８５５】
上述したように、放送信号受信装置が一つのオブジェクトを全て受信しなくても、ＡＵ抽出器Ｃ３２０５６は、タイプ情報及び境界情報に基づいて、当該オブジェクトの内部構造体の受信が完了すると直ちにオブジェクト内部構造体を抽出し、デコーダＣ３２０６０に伝達することができる。
【０８５６】
デコーディングバッファＣ３２０５９は、セグメントバッファＣ３２０３０からデータを受け取って、あらかじめ定められた時間記憶することができる。アクセスユニットは、デコーディングバッファＣ３２０５９内でアクセスユニットに与えられた処理時間にデコーダＣ３２０６０又は他の構成要素に伝達されてもよい。このとき、アクセスユニットに、ＰＴＳ（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅ  ｓｔａｍｐ）などの処理時間に対するタイミング情報は、ＬＣＴヘッダー拡張形態で与えられてもよい。
【０８５７】
デコーダＣ３２０６０は、オブジェクト内部構造体を受信し、タイプ情報に基づいて当該オブジェクト内部構造体をデコードすることができる。このとき、デコーダＣ３２０６０は、オブジェクト内部構造体の形態だけでなく、アクセスユニットの形態で当該オブジェクト内部構造体を受信してもよい。
【０８５８】
タイプ情報がオブジェクト内部構造体のタイプがアクセスユニットであることを示すと、デコーダＣ３２０６０は、当該オブジェクトを全て受信する前であっても、当該オブジェクトの内部構造体であるアクセスユニットをデコードすることができる。
【０８５９】
図５４は、本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。
【０８６０】
同図に示す構成要素のうち、上述した構成要素と同じ部分はその内容も同一であるため、その具体的な説明を省略する。
【０８６１】
以下では、オブジェクト内部構造体のタイプがチャンク又はＧＯＰである場合の放送信号受信装置の動作及び構成について説明する。放送信号受信装置は、パケットデパケタイザＣ２２０２０、セグメントバッファＣ３２０３０、チャンクバッファＣ３２０３５、デコーディングバッファＣ３２０５９、及び／又はデコーダＣ３２０６０をさらに含むことができる。
【０８６２】
パケットデパケタイザＣ２２０２０は、抽出した少なくとも一つのオブジェクト又は少なくとも一つのオブジェクト内部構造体を、セグメントバッファＣ３２０３０を通してデコーダＣ３２０６０に伝達することができる。
【０８６３】
セグメントバッファＣ３２０３０は、チャンク抽出器Ｃ３２０５７を含むことができる。また、セグメントバッファＣ３２０３０はチャンクバッファＣ３２０３５をさらに含むことができる。
【０８６４】
タイプ情報がオブジェクト内部構造体のタイプがチャンク又はＧＯＰであることを示すと、チャンク抽出器Ｃ３２０５７は、境界情報に基づいて、セグメントバッファＣ３２０３０に記憶されたチャンク又はＧＯＰを抽出することができる。例えば、一つのチャンク又はＧＯＰは、境界情報が示すチャンク又はＧＯＰの開始地点から次のチャンク又はＧＯＰの開始地点以前までであってもよい。チャンク抽出器Ｃ３２０５７は、セグメントバッファＣ３２０３０内に存在してもよく、独立して存在してもよい。
【０８６５】
チャンクバッファＣ３２０３５は、少なくとも一つのチャンク又はＧＯＰを受け取って、あらかじめ定められた時間記憶することができる。チャンクバッファＣ３２０３５は、セグメントバッファＣ３２０３０内に存在してもよく、独立して存在してもよい。チャンクバッファＣ３２０３５は、ＡＵ抽出器Ｃ３２０５６をさらに含むことができる。
【０８６６】
ＡＵ抽出器Ｃ３２０５６は、チャンクバッファＣ３２０３５に記憶されたチャンク又はＧＯＰから少なくとも一つのアクセスユニットを抽出することができる。その後、抽出された少なくとも一つのアクセスユニットをデコーディングバッファＣ３２０５９を通してデコーダＣ３２０６０に伝達することができる。
【０８６７】
タイプ情報がオブジェクト内部構造体のタイプがチャンク又はＧＯＰであることを示すと、デコーダＣ３２０６０は、当該オブジェクトを全て受信する前であっても、当該オブジェクトの内部構造体であるチャンク又はＧＯＰをデコードすることができる。
【０８６８】
図５５は、本発明の他の実施例に係るパケット情報を用いる放送信号受信装置の構造を示す図である。
【０８６９】
同図に示す構成要素のうち、上述した構成要素と同じ部分はその内容も同一であるため、その具体的な説明を省略する。
【０８７０】
以下では、オブジェクト内部構造体のタイプがフラグメントである場合の放送信号受信装置の動作及び構成について説明する。放送信号受信装置は、パケットデパケタイザＣ２２０２０、セグメントバッファＣ３２０３０、フラグメントバッファＣ３２０３６、オーディオデコーディングバッファＣ３２０５９−１、ビデオデコーディングバッファＣ３２０５９−２、オーディオデコーダＣ３２０６０−１、及び／又はビデオデコーダＣ３２０６０−２をさらに含むことができる。
【０８７１】
パケットデパケタイザＣ２２０２０は、抽出した少なくとも一つのオブジェクト又は少なくとも一つのオブジェクト内部構造体を、オーディオデコーダＣ３２０６０−１及び／又はビデオデコーダＣ３２０６０−２に伝達することができる。
【０８７２】
セグメントバッファＣ３２０３００は、フラグメント抽出器Ｃ３２０５８を含むことができる。また、セグメントバッファＣ３２０３０は、フラグメントバッファＣ３２０３６をさらに含むことができる。
【０８７３】
タイプ情報がオブジェクト内部構造体のタイプがフラグメントであることを示すと、フラグメント抽出器Ｃ３２０５８は、境界情報に基づいて、セグメントバッファＣ３２０３００に記憶されたフラグメントを抽出することができる。例えば、一つのフラグメントは、境界情報が示すフラグメントの開始地点から次のフラグメントの開始地点以前までであってもよい。フラグメント抽出器Ｃ３２０５８は、セグメントバッファＣ３２０３０内に存在してもよく、独立して存在してもよい。
【０８７４】
フラグメントバッファＣ３２０３６はフラグメントを受け取って、あらかじめ定められた時間記憶することができる。フラグメントバッファＣ３２０３６は、セグメントバッファＣ３２０３０内に存在してもよく、独立して存在してもよい。フラグメントバッファＣ３２０３６は、ＡＵ抽出器Ｃ３２０５６をさらに含むことができる。また、フラグメントバッファＣ３２０３６はチャンクバッファ（図示せず）をさらに含むことができる。
【０８７５】
ＡＵ抽出器Ｃ３２０５６は、フラグメントバッファＣ３２０３６に記憶されたフラグメントから少なくとも一つのアクセスユニットを抽出することができる。ＡＵ抽出器Ｃ３２０５６は、フラグメントバッファＣ３２０３６内に存在してもよく、独立して存在してもよい。また、放送信号受信装置は、チャンクバッファ（図示せず）をさらに含み、ＡＵ抽出器Ｃ３２０５６は、チャンクバッファに含まれたチャンク又はＧＯＰから少なくとも一つのアクセスユニットを抽出することができる。その後、ＡＵ抽出器Ｃ３２０５６は、抽出された少なくとも一つのアクセスユニットをオーディオデコーダＣ３２０６０−１及び／又はビデオデコーダＣ３２０６０−２に伝達することができる。
【０８７６】
デコーディングバッファは、オーディオデコーディングバッファＣ３２０５９−１及び／又はビデオデコーディングバッファＣ３２０５９−２を含むことができる。オーディオデコーディングバッファＣ３２０５９−１は、オーディオに関連したデータを受信し、あらかじめ定められた時間記憶することができる。ビデオデコーディングバッファＣ３２０５９−２は、ビデオに関連したデータを受信し、あらかじめ定められた時間記憶することができる。
【０８７７】
タイプ情報がオブジェクト内部構造体のタイプがフラグメントであることを示すと、デコーダは、当該オブジェクトを全て受信する前であっても、当該オブジェクトの内部構造体であるフラグメントをデコードすることができる。デコーダは、オーディオに関連したデータをデコードするオーディオデコーダＣ３２０６０−１及び／又はビデオに関連したデータをデコードするビデオデコーダＣ３２０６０−２をさらに含むことができる。
【０８７８】
上述したように、放送信号送信装置は、オブジェクト単位でデータを伝送せず、可変長のオブジェクト内部構造体でデータを伝送することができる。このとき、放送信号送信装置は、送信するオブジェクト内部構造体のタイプ情報及び境界情報を共に伝送することができる。
【０８７９】
放送信号受信装置は、オブジェクト単位でデータを受信して再生するのではなく、可変長のオブジェクト内部構造体でデータを受信して再生することができる。したがって、放送信号受信装置は、タイプ情報及び境界情報に基づいて、オブジェクト内部構造体を識別し、受信したオブジェクト内部構造体別に再生することができる。
【０８８０】
＜伝送パケットペイロードデータの優先順位識別方案＞
図５６は、本発明の他の実施例に係る優先順位情報を含むパケットの構造を示す図である。
【０８８１】
本発明の他の実施例に係るパケットはＲＯＵＴＥパケットであってもよく、ＲＯＵＴＥパケットは、ＡＬＣ／ＬＣＴパケットを表すことができる。ただし、以下では、便宜上、ＲＯＵＴＥパケット及び／又はＡＬＣ／ＬＣＴパケットをＬＣＴパケットと呼ぶものとする。ＲＯＵＴＥによって用いられるＬＣＴパケットフォーマットは、ＡＬＣパケットフォーマット、すなわち、ＬＣＴヘッダーが続くＵＤＰヘッダー及びパケットペイロードが続くＦＥＣペイロードＩＤに従う。
【０８８２】
ＬＣＴパケットは、パケットヘッダー及びパケットペイロードを含むことができる。パケットヘッダーは、パケットペイロードに対するメタデータを含むことができる。パケットペイロードは、ＭＰＥＧ−ＤＡＳＨコンテンツのデータを含むことができる。
【０８８３】
例えば、パケットヘッダーは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、及び／又はＦＥＣペイロードＩＤフィールドを含むことができる。
【０８８４】
また、パケットペイロードはシンボルエンコーディングフィールドを含むことができる。
【０８８５】
本発明の他の実施例に係るＬＣＴパケットを構成する各フィールドのうち、前述したフィールドと同じ名称のフィールドは、前述した内容を全て含むことができ、その具体的な説明は前述した説明に代える。
【０８８６】
パケットヘッダーは、パケットペイロードの優先順位（Ｐｒｉｏｒｉｔｙ）を示す優先順位情報（Ｐｒｉｏｒｉｔｙ）をさらに含むことができる。優先順位情報は、各パケットの開始地点から１２番目及び１３番目のビットに位置する２ビットを用いてパケットペイロードの優先順位を示すことができる。この場合、２ビットを用いるので、パケットヘッダーのサイズを減らすことができ、効率性を高めることができる。
【０８８７】
優先順位情報（Ｐｒｉｏｒｉｔｙ）は、一つのファイルに含まれたＬＣＴパケットのうち、現在ＬＣＴパケットで送信しているパケットペイロードの優先順位を示すことができる。すなわち、優先順位情報は、同一のＴＳＩ又はＴＯＩが与えられたパケットのうち、現在ＬＣＴパケットで送信しているパケットペイロードの相対的優先順位を示すことができる。
【０８８８】
例えば、優先順位情報は０〜３の範囲の値を有することができる。優先順位情報が低い値を有するほど、パケットペイロードが全ファイルベースメディアデータを処理する際に優先順位が高いということを示すことができる。逆に、優先順位情報が高い値を有するほど、優先順位が低いということを示すことができる。
【０８８９】
ＴＳＩはＬＣＴ伝送セッションを識別することができ、ＴＯＩはデリバリオブジェクト（Ｄｅｌｉｖｅｒｙ  Ｏｂｊｅｃｔ）を識別することができる。
【０８９０】
各ＲＯＵＴＥセッションは、１つ又は複数のＬＣＴ伝送セッションで構成される。ＬＣＴ伝送セッションは、ＲＯＵＴＥセッションのサブセットである。メディア伝達のために、ＬＣＴ伝送セッションは一般に、メディアコンポーネント、例えば、ＭＰＥＧ−ＤＡＳＨリプレゼンテーションを伝達することができる。ブロードキャストＭＰＥＧ−ＤＡＳＨの観点から、ＲＯＵＴＥセッションは、一つ以上のＤＡＳＨメディアプレゼンテーションの構成メディアコンポーネントを送信するＬＣＴ伝送セッションのマルチプレクスとして見なされてもよい。それぞれのＬＣＴ伝送セッション内で、１つ又は複数のデリバリオブジェクト、一般に、関連したデリバリオブジェクト、例えば、一つのリプレゼンテーションに関連したＭＰＥＧ−ＤＡＳＨセグメントが伝達される。それぞれのデリバリオブジェクトと共に、メタデータ特性が伝達され、デリバリオブジェクトがアプリケーションで用いられてもよい。
【０８９１】
一つのデリバリオブジェクト（Ｄｅｌｉｖｅｒｙ  Ｏｂｊｅｃｔ）は、一つのＩＳＯ  ＢＭＦＦファイル又は一つのＩＳＯ  ＢＭＦＦファイルの一部であってもよい。一つのＩＳＯ  ＢＭＦＦファイルの一部は、フラグメント、ＧＯＰ、チャンク、アクセスユニット、及び／又はＮＡＬユニットを含むことができる。
【０８９２】
一実施例として、一つのＴＳＩが一つのトラック（ＭＰＥＧ−ＤＡＳＨリプレゼンテーション）にマッチされ、一つのＴＯＩが一つのＩＳＯ  ＢＭＦＦファイルにマッチングされてもよい。また、一つのＩＳＯ  ＢＭＦＦファイルは、‘ｆｔｙｐ’、‘ｍｏｏｖ’、“ｍｏｏｆ”、及び／又は‘ｍｄａｔ’を含むことができる。
【０８９３】
‘ｆｔｙｐ’は、ファイルタイプ及び互換性（ｃｏｍｐａｔａｂｉｌｉｔｙ）に関する情報を含んでいるコンテナ（ｃｏｎｔａｉｎｅｒ）である。‘ｍｏｏｖ’は、メディアデータを再生するための全メタデータ（ｍｅｔａｄａｔａ）を含むコンテナである。メディアコンテンツが一つのファイル内で少なくとも一つのメディアデータに分割されたり、又はメディアコンテンツが少なくても一つのファイルに分割された場合、‘ｍｏｏｆ’は、それぞれの分割されたメディアデータに対するメタデータを含むコンテナである。‘ｍｄａｔ’は、オーディオデータ及びビデオデータのようなメディアデータを含む。‘ｍｄａｔ’は、少なくとも一つの‘Ｉ−フレーム’、‘Ｐ−フレーム’、及び／又は‘Ｂ−フレーム’を含むことができる。
【０８９４】
‘Ｉ−フレーム’は、ＭＰＥＧで当該フレームの前のフレーム及び後のフレームを使用する時間的圧縮技術を利用せず、他のフレームとは独立して空間的圧縮技術だけを用いて作られるフレームを意味する。‘Ｉ−フレーム’は、イメージから直接コードして生成されるため、インターフロック（ｉｎｔｅｒ  ｂｌｏｃｋ）のみから構成され、ランダムアクセスポイント（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）の役割を担うことができる。また、‘Ｉ−フレーム’は、時間的動きを予測して生成する‘Ｐ−フレーム’及び／又は‘Ｂ−フレーム’の基準となってもよい。したがって、‘Ｉ−フレーム’が自身のフレームの空間剰余要素だけを減少させて圧縮を行うことにより、‘Ｉ−フレーム’は低い圧縮率を提供する。すなわち、圧縮による結果ビット数は、他のフレームに比べて多いビット数を必要とする。
【０８９５】
‘Ｐ−フレーム’は、ＭＰＥＧで時間的に後に出る場面に対して動きを予測して生成した画面を意味する。‘Ｐ−フレーム’は、最も最近の‘Ｉ−フレーム’及び／又は‘Ｂ−フレーム’を参照して、画面間順方向予測のみによって次の画面を予測して得る画面である。したがって、‘Ｐ−フレーム’は、比較的高い圧縮率を提供する。
【０８９６】
‘Ｂ−フレーム’は、ＭＰＥＧから時間的に予測して生成する画面のうち、前及び／又は後にある‘Ｐ−フレーム’及び／又は‘Ｉ−フレーム’から両方向の動きをより高精度に予測して生成する予測画面のことをいう。‘Ｂ−フレーム’の場合には、直前の‘Ｉ−フレーム’及び／又は‘Ｐ−フレーム’、現在のフレーム、及び／又は直後に出る‘Ｉ−フレーム’及び／又は‘Ｐ−フレーム’に基づいてコーディング及び／又はデコードされる。このため、コーディング及び／又はデコーディング時間遅延が発生する。しかし、‘Ｂ−フレーム’は、最高の圧縮率を提供し、‘Ｐ−フレーム’及び／又は‘Ｉ−フレーム’のコーディング及び／又はデコーディングのベースとならないため、誤りを伝播しない。
【０８９７】
前述したように、一つのＩＳＯ  ＢＭＦＦファイル内の‘ｆｔｙｐ’、‘ｍｏｏｖ’、“ｍｏｏｆ”、及び／又は‘ｍｄａｔ’はそれぞれ優先順位が異なってもよい。したがって、‘ｆｔｙｐ’、‘ｍｏｏｖ’、“ｍｏｏｆ”、及び／又は‘ｍｄａｔ’を含むパケットは同一のＴＳＩ及び／又はＴＯＩを有するが、それぞれ異なる優先順位を有することができる。
【０８９８】
例えば、‘ｆｔｙｐ’及び‘ｍｏｏｖ’を含むパケットの優先順位情報は、‘０’の値を有し、‘ｍｏｏｆ’を含むパケットの優先順位情報は、‘１’の値を有し、‘Ｉ−フレーム’を含むパケットの優先順位情報は、‘１’の値を有し、‘Ｐ−フレーム’を含むパケットの優先順位情報は、‘２’の値を有し、及び／又は‘Ｂ−フレーム’を含むパケットの優先順位情報は、‘３’の値を有することができる。
【０８９９】
このように、放送信号送信装置は、ＡＶＣ（Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）／ＨＥＶＣ（Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）などのビデオデータを含むＭＰＥＧ−ＤＡＳＨセグメントを伝送する場合、‘ｆｔｙｐ’及び‘ｍｏｏｖ’を含むパケット、‘ｍｏｏｆ’を含むパケット、‘Ｉ−Ｐｉｃｔｕｒｅ’を含むパケット、‘Ｐ−Ｐｉｃｔｕｒｅ’を含むパケット、及び／又は‘Ｂ−Ｐｉｃｔｕｒｅ’を含むパケットの順に、パケットデータの処理のための優先順位を与えることができる。
【０９００】
また、ネットワーク上の中継機及び／又はルータなどの中間ノードは、優先順位情報に基づいて、ネットワークの帯域幅及び／又はサービスの目的によって優先順位の高いパケットを優先して伝送し、優先順位の低いパケットは選択的に伝送することができる。したがって、優先順位情報を様々なサービス状況に容易に適用することができる。
【０９０１】
また、放送信号受信装置は、ＡＶＣ／ＨＥＶＣなどのビデオデータを受信する場合に、‘ｆｔｙｐ’、‘ｍｏｏｖ’、‘ｍｏｏｆ’、‘Ｉ−Ｐｉｃｔｕｒｅ’、‘Ｐ−Ｐｉｃｔｕｒｅ’、及び／又は‘Ｂ−Ｐｉｃｔｕｒｅ’の優先順位情報に基づいて、優先順位の高いパケット（すなわち、優先順位情報の値が低いパケット）を優先して抽出し、優先順位の低いパケット（すなわち、優先順位情報の値が高いパケット）を選択的に抽出して、一つのシーケンスを構成することができる。変形された実施例として、放送信号受信装置は、選択的にフレームレートの高いシーケンスを抽出したり、又はフレームレートの低いシーケンスを抽出することができる。
【０９０２】
図５７は、本発明の他の実施例に係る優先順位情報を含むパケットの構造を示す図である。
【０９０３】
本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、パケットヘッダー及びパケットペイロードを含むことができる。パケットヘッダーは、パケットペイロードに対するメタデータを含むことができる。パケットペイロードは、ＭＰＥＧ−ＤＡＳＨコンテンツのデータを含むことができる。
【０９０４】
例えば、パケットヘッダーは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、及び／又はＦＥＣペイロードＩＤフィールドを含むことができる。
【０９０５】
また、パケットペイロードはシンボルエンコーディングフィールドを含むことができる。
【０９０６】
本発明の他の実施例に係るＬＣＴパケットを構成する各フィールドのうち、前述したフィールドと同じ名称のフィールドは前述した内容を全て含むことができ、その具体的な説明は前述した説明に代える。
【０９０７】
パケットヘッダーは、パケットペイロードの優先順位（Ｐｒｉｏｒｉｔｙ）を示す優先順位情報（ＥＸＴ＿ＴＹＰＥ）をさらに含むことができる。優先順位情報（ＥＸＴ＿ＴＹＰＥ）は、ＬＣＴヘッダー拡張を用いて現在パケットが送信しているパケットペイロードの相対的優先順位を示すことができる。ＬＣＴヘッダー拡張を用いる場合、ＬＣＴヘッダー拡張を支援しない放送信号受信装置では、優先順位情報（ＥＸＴ＿ＴＹＰＥ）をスキップすればいいため、拡張性を高めることができる。ＬＣＴヘッダー拡張を用いる優先順位情報（ＥＸＴ＿ＴＹＰＥ）は、ＲＴＰ（ｒｅａｌｔｉｍｅ  ｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用されてもよい。
【０９０８】
優先順位情報（ＥＸＴ＿ＴＹＰＥ）は、ヘッダー拡張タイプ（ＨＥＴ）フィールド、優先順位フィールド、及び／又は予約フィールドを含むことができる。実施例によって、優先順位情報（ＥＸＴ＿ＴＹＰＥ）は優先順位フィールドのみを表してもよい。
【０９０９】
ＨＥＴフィールドは８ビットの整数であってもよく、当該ヘッダー拡張のタイプを示すことができる。例えば、ＨＥＴフィールドは１２８〜２５５の値のうち一つの固有値で当該ヘッダー拡張のタイプを識別することができ、この場合、ヘッダー拡張は３２ビットの固定長を有することができる。
【０９１０】
優先順位フィールドは、一つのファイルに含まれたＬＣＴパケットのうち、現在ＬＣＴパケットで送信しているパケットペイロードの優先順位を示すことができる。また、優先順位フィールドは、同一のＴＳＩ又はＴＯＩが与えられたパケットのうち、現在ＬＣＴパケットで送信しているパケットペイロードの相対的優先順位を示すことができる。
【０９１１】
例えば、優先順位情報は、０〜２５５の範囲の値を有することができる。優先順位情報が低い値を有するほど、パケットペイロードが全ファイルベースメディアデータを処理する際に優先順位が高いということを示すことができる。
【０９１２】
例えば、‘ｆｔｙｐ’及び‘ｍｏｏｖ’を含むパケットの優先順位情報は‘０’の値を有し、‘ｍｏｏｆ’を含むパケットの優先順位情報は‘１’の値を有し、‘Ｉ−フレーム’を含むパケットの優先順位情報は‘２’の値を有し、‘Ｐ−フレーム’を含むパケットの優先順位情報は‘３’の値を有し、及び／又は‘Ｂ−フレーム’を含むパケットの優先順位情報は‘４’の値を有することができる。
【０９１３】
予約フィールドは、将来の使用のために予約されたフィールドであってもよい。
【０９１４】
以下、具体的な内容は前述の内容と同一であり、その説明を省略する。
【０９１５】
図５８は、本発明の他の実施例に係るオフセット情報を含むパケットの構造を示す図である。
【０９１６】
本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、パケットヘッダー及びパケットペイロードを含むことができる。パケットヘッダーは、パケットペイロードに対するメタデータを含むことができる。パケットペイロードは、ＭＰＥＧ−ＤＡＳＨコンテンツのデータを含むことができる。
【０９１７】
例えば、パケットヘッダーは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、予約フィールド（Ｒｅｓ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、及び／又はＦＥＣペイロードＩＤフィールドを含むことができる。
【０９１８】
また、パケットペイロードはシンボルエンコーディングフィールドを含むことができる。
【０９１９】
本発明の他の実施例に係るＬＣＴパケットを構成する各フィールドのうち、前述したフィールドと同じ名称のフィールドは前述の内容を全て含むことができ、その具体的な説明は前述の説明に代える。
【０９２０】
パケットヘッダーはオフセット情報をさらに含むことができる。オフセット情報は、現在パケットが送信しているパケットペイロードのファイル内におけるオフセットを示すことができる。オフセット情報は、オフセットをファイルの開始地点からのバイト数で示すことができる。オフセット情報は、ＬＣＴヘッダー拡張の形式であってもよく、ＦＥＣペイロードＩＤフィールドに含まれてもよい。
【０９２１】
一実施例として、ＬＣＴパケットがＬＣＴヘッダー拡張の形式でオフセット情報（ＥＸＴ＿ＯＦＳ）を含む場合を説明する。
【０９２２】
ＬＣＴヘッダー拡張を用いる場合、ＬＣＴヘッダー拡張を支援しない受信機ではオフセット情報（ＥＸＴ＿ＯＦＳ）をスキップすればいいため、拡張性を高めることができる。ＬＣＴヘッダー拡張を用いるオフセット情報（ＥＸＴ＿ＯＦＳ）は、ＲＴＰ（ｒｅａｌｔｉｍｅ  ｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用されてもよい。
【０９２３】
オフセット情報（ＥＸＴ＿ＯＦＳ）は、ヘッダー拡張タイプフィールド（ＨＥＴ）、ヘッダー拡張長さフィールド（ＨＥＬ）、及びオフセット開始フィールド（Ｓｔａｒｔ  Ｏｆｆｓｅｔ）を含むことができる。実施例によって、オフセット情報（ＥＸＴ＿ＯＦＳ）は、オフセット開始フィールド（Ｓｔａｒｔ  Ｏｆｆｓｅｔ）だけを表してもよい。
【０９２４】
ＨＥＴフィールドは、上述したとおりであり、その具体的な説明は省略する。
【０９２５】
ＨＥＬフィールドは、可変長のＬＣＴヘッダー拡張の全長を示す。基本的に、ＬＣＴではＨＥＴが０〜１２７の値を有する場合、３２ビットワード単位の可変長ヘッダー拡張が存在し、ＨＥＴフィールドに続くＨＥＬフィールドは。ＬＣＴヘッダー拡張の全長を３２ビットワード単位で示す。
【０９２６】
オフセット開始フィールドは、可変長であってもよく、現在パケットが送信しているパケットペイロードのファイル内におけるオフセットを示すことができる。オフセット開始フィールドはオフセットを、ファイルの開始地点からのバイト数で示すことができる。
【０９２７】
ＬＣＴパケットは、ＬＣＴヘッダー拡張の形式だけでなく、ＦＥＣペイロードＩＤフィールドにオフセット情報（Ｓｔａｒｔ  Ｏｆｆｓｅｔ）を含んでもよい。以下では、ＬＣＴパケットがＦＥＣペイロードＩＤフィールドにオフセット情報を含む場合を説明する。
【０９２８】
ＦＥＣペイロードＩＤフィールドは、特定パケットによって伝送されるエンコーディングシンボル及びＦＥＣエンコーディング変換間の関係をＦＥＣデコーダに示す情報を含む。例えば、パケットがソースシンボルを伝送すると、ＦＥＣペイロードＩＤフィールドは、オブジェクトのどのソースシンボルがパケットによって伝送されるかを示す。パケットがリペアシンボルを伝送すると、ＦＥＣペイロードＩＤフィールドは、リペアシンボルがオブジェクトからどのように構成されるかを示す。
【０９２９】
ＦＥＣペイロードＩＤフィールドはまた、パケットにその一部が含まれるエンコーディングシンボルのより大きいグループに関する情報を含むことができる。例えば、ＦＥＣペイロードＩＤフィールドは、シンボルが関連付いているソースブロックに関する情報を含むことができる。
【０９３０】
ＦＥＣペイロードＩＤは、ソースブロック番号（ＳＢＮ）及び／又はエンコーディングシンボルＩＤ（ＥＳＩ）を含む。ＳＢＮは、パケット内のエンコーディングシンボルが関連付いているソースブロックに対する負でない（ｎｏｎ−ｎｅｇａｔｉｖｅ）整数識別子である。ＥＳＩは、パケット内のエンコーディングシンボルに対する負でない整数識別子である。
【０９３１】
本発明の他の実施例に係るＦＥＣペイロードＩＤフィールドは、オフセット情報（Ｓｔａｒｔ  Ｏｆｆｓｅｔ）をさらに含むことができる。
【０９３２】
デリバリオブジェクトのオクテットで開始アドレスを特定したＦＥＣペイロードＩＤフィールドが用いられる。この情報をいくつかの方式で伝送することができる。
【０９３３】
第一に、サイズ０に設定されたＦＥＣペイロードＩＤセットを有する単純な新しいＦＥＣスキーム。この場合、パケットは３２ビットを用いてダイレクトアドレス（ｓｔａｒｔ  ｏｆｆｓｅｔ）として全オブジェクトを含むはずである。
【０９３４】
第二に、ＳＢＮ及びＥＳＩがシンボルサイズ（Ｔ）と共にオフセット開始（ｓｔａｒｔ  ｏｆｆｓｅｔ）を定義するＲＦＣ６３３０への互換可能な方式でＲＦＣ５４４５に定義されたコンパクトノーコード（Ｎｏ−Ｃｏｄｅ）を用いて広く配置された既存のＦＥＣスキーム。
【０９３５】
第三に、ＬＳＩＤは適切なシグナリングを提供し、＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及びＦＥＣＰａｒａｍｅｔｅｒｓエレメントを用いて、上記モードのうちいずれかをシグナリングする。
【０９３６】
以下では、オフセット情報の具体的な内容を説明する。
【０９３７】
従来のＦＬＵＴＥプロトコルでは、オフセット情報を伝送する必要がなかった。従来のＦＬＵＴＥプロトコルは、オブジェクト（例えば、ファイル）を非実時間で伝送するので、一つのオブジェクトを固定サイズの少なくとも一つのデータに分割して伝送した。
【０９３８】
例えば、従来のＦＬＵＴＥプロトコルでは、一つのオブジェクトを固定サイズの少なくとも一つのソースブロック（Ｓｏｕｒｃｅ  Ｂｌｏｃｋ）に分割し、それぞれのソースブロックを固定サイズの少なくとも一つのシンボルに分割し、それぞれのシンボルにヘッダーを追加してＬＣＴパケット（又はＦＬＵＴＥパケット）を生成した。従来のＦＬＵＴＥプロトコルは、一つのＬＣＴパケットは一つの固定サイズのシンボルだけを含むことができた。
【０９３９】
それぞれのソースブロック及び／又はシンボルが固定サイズであるため、受信機は、ソースブロック及び／又はシンボルの識別情報に基づいて、オブジェクト内でそれぞれのソースブロック及び／又はシンボルの位置を認識できた。したがって、受信機は、一つのオブジェクトを構成する全ソースブロック及び／又はシンボルを受信した後、受信したソースブロック及び／又はシンボルの識別情報に基づいてオブジェクトを再構成することができた。
【０９４０】
従来のＦＬＵＴＥプロトコルがオブジェクトを非実時間で送信することに対して、本発明の他の実施例に係るＲＯＵＴＥプロトコルは、オブジェクトを可変サイズのデリバリオブジェクト（Ｄｅｌｉｖｅｒｙ  Ｏｂｊｅｃｔ）に分割し、デリバリオブジェクト単位で実時間で伝送することができる。例えば、ＲＯＵＴＥプロトコルは、オブジェクトを可変サイズのオブジェクト内部構造体（Ｏｂｊｅｃｔ  Ｉｎｔｅｒｎａｌ  Ｓｔｒｕｃｔｕｒｅ）単位で伝送することができる。
【０９４１】
一つのデリバリオブジェクト（Ｄｅｌｉｖｅｒｙ  Ｏｂｊｅｃｔ）は、一つのＩＳＯ  ＢＭＦＦファイル又は一つのＩＳＯ  ＢＭＦＦファイルの一部であってもよい。一つのＩＳＯ  ＢＭＦＦファイルの一部は、フラグメント、ＧＯＰ、チャンク、アクセスユニット、及び／又はＮＡＬユニットを含むことができる。一つのＩＳＯ  ＢＭＦＦファイルの一部は、前述したオブジェクト内部構造体を意味することができる。オブジェクト内部構造体は、独立して有意なデータ単位であり、オブジェクト内部構造体のタイプは、上記に限定されず、有意な単位をさらに含んでもよい。
【０９４２】
また、本発明の他の実施例に係るＬＣＴパケットにおいて、それぞれのＬＣＴパケット（ＡＬＣ／ＬＣＴパケット、又はＲＯＵＴＥパケット）は、少なくとも一つのエンコーディングシンボルを含むことができる。すなわち、本発明の他の実施例に係るＲＯＵＴＥプロトコルにおいて、一つのＬＣＴパケットに複数のエンコーディングシンボルを含むことができる。また、それぞれのエンコーディングシンボルは可変サイズを有することができる。
【０９４３】
本発明の他の実施例に係るＬＣＴパケットにおいて、それぞれのＴＳＩをそれぞれのトラックにマッチすることができる。例えば、それぞれのＴＳＩを、ビデオトラック、オーディオトラック、及び／又はＭＰＥＧ−ＤＡＳＨのリプレゼンテーションのうち一つにマッチすることができる。また、それぞれのＴＯＩは、それぞれのデリバリオブジェクト（Ｄｅｌｉｖｅｒｙ  Ｏｂｊｅｃｔ）にマップされてもよい。例えば、ＴＯＩがＭＰＥＧ−ＤＡＳＨのセグメントにマップされる場合、デリバリオブジェクトはＩＳＯ  ＢＭＦＦファイルであってもよい。また、それぞれのＴＯＩは、フラグメント、チャンク（ｃｈｕｎｋ）、ＧＯＰ、アクセスユニット、及び／又はＮＡＬユニットのうち一つにマップされてもよい。
【０９４４】
受信機が可変サイズのデリバリオブジェクトの単位で実時間でＬＣＴパケットを受信する場合、受信機は、受信したＬＣＴパケットがオブジェクト内でどの位置に該当するかを認識できない場合がある。例えば、受信機が任意の順でＬＣＴパケットを受信する場合、受信機は、ＬＣＴパケットを順序通りに整列することができず、デリバリオブジェクトを正確に復元及び／又はパースできない場合が発生する。
【０９４５】
したがって、本発明の他の実施例に係るオフセット情報は、ファイル（例えば、オブジェクト）内で現在伝送中のパケットペイロードのオフセットを示すことができる。受信機は、オフセット情報に基づいて、現在伝送されているパケットが当該ファイルの最初のデータを有することを認識することができる。また、受信機は、オフセット情報に基づいて、当該デリバリオブジェクトにおいて、現在伝送されているパケットの順序を認識することができる。また、受信機は、オフセット情報に基づいて、現在パケットが送信しているパケットペイロードのファイルにおけるオフセットを認識できる他、現在パケットが送信しているデリバリオブジェクトのファイルにおけるオフセットも認識することができる。
【０９４６】
例えば、ＴＳＩはビデオトラック（ＭＰＥＧ−ＤＡＳＨリプレゼンテーション）にマッチされ、ＴＯＩはＩＳＯ  ＢＭＦＦファイル（例えば、オブジェクト）にマッチされてもよい。この場合、デリバリオブジェクト（Ｄｅｌｉｖｅｒｙ  Ｏｂｊｅｃｔ）はＩＳＯ  ＢＭＦＦファイルを表すことができる。一つのビデオトラック（ＭＰＥＧ−ＤＡＳＨリプレゼンテーション、ＴＳＩ＝１）は、第１オブジェクト（ＴＳＩ＝１，ＴＯＩ＝１）及び第２オブジェクト（ＴＳＩ＝１，ＴＯＩ＝２）を含むことができる。第１オブジェクト（ＴＳＩ＝１，ＴＯＩ＝１）は、順次に、第１パケット（ＴＳＩ＝１，ＴＯＩ＝１，Ｓｔａｒｔ  Ｏｆｆｓｅｔ＝０）、第２パケット（ＴＳＩ＝１，ＴＯＩ＝１，Ｓｔａｒｔ  Ｏｆｆｓｅｔ＝２００）、第３パケット（ＴＳＩ＝１，ＴＯＩ＝１，Ｓｔａｒｔ  Ｏｆｆｓｅｔ＝４００）、第４パケット（ＴＳＩ＝１，ＴＯＩ＝１，Ｓｔａｒｔ  Ｏｆｆｓｅｔ＝８００）、及び／又は第５パケット（ＴＳＩ＝１，ＴＯＩ＝１，Ｓｔａｒｔ  Ｏｆｆｓｅｔ＝１０００）を含むことができる。
【０９４７】
この場合、オフセット情報（Ｓｔａｒｔ  Ｏｆｆｓｅｔ）の値が‘０’であれば、当該パケットのパケットペイロードは、当該ファイルの最初のデータを有することができる。第１パケットのオフセット情報（Ｓｔａｒｔ  Ｏｆｆｓｅｔ）の値が‘０’であることから、受信機は、第１パケットのパケットペイロードが第１オブジェクトの最初のデータを有していると認識することができる。
【０９４８】
また、オフセット情報（Ｓｔａｒｔ  Ｏｆｆｓｅｔ）の値は、当該オブジェクト内でパケットの順序を示すことができる。第１オブジェクト内で第１パケットのオフセット情報から第５パケットのオフセット情報が順次に増加するので、受信機は、第１オブジェクト内で第１パケット乃至第５パケットが順次に配列されるということが認識できる。
【０９４９】
したがって、受信機は、オフセット情報に基づいて、それぞれのオブジェクトにおいて受信したＬＣＴパケットを順次に整列し、それぞれのデリバリオブジェクト及び／又はオブジェクトを正確に復元することができる。また、受信機は、オフセット情報に基づいて、それぞれのデリバリオブジェクト及び／又はオブジェクトを正確にパース及び／又はデコードすることができる。
【０９５０】
一方、受信機が可変サイズのデリバリオブジェクトの単位で実時間でＬＣＴパケットを受信する場合、受信機は、受信したＬＣＴパケットがオブジェクト（例えば、ファイル）内でどの位置に該当するかを認識できない場合がある。例えば、ＬＣＴパケットが任意の順序で伝送されると、受信機は、受信したＬＣＴパケットのオブジェクト内における正確なオフセットがわからず、ＬＣＴパケットを収集してデリバリオブジェクト及び／又はオブジェクトを正確に復元できなくなるという問題が発生しうる。
【０９５１】
例えば、ＴＳＩはビデオトラック（ＭＰＥＧ−ＤＡＳＨリプレゼンテーション）にマッチされ、ＴＯＩはチャンクにマッチされてもよい。この場合、一つのビデオトラック（ＭＰＥＧ−ＤＡＳＨリプレゼンテーション、ＴＳＩ＝１）は、第１オブジェクト（ＴＳＩ＝１）及び第２オブジェクト（ＴＳＩ＝１）を含むことができる。また、第１オブジェクトは第１チャンク（ＴＳＩ＝１，ＴＯＩ＝１）、第２チャンク（ＴＳＩ＝１，ＴＯＩ＝２）、及び／又は第３チャンク（ＴＳＩ＝１，ＴＯＩ＝３）を含み、第２オブジェクトは第４チャンク（ＴＳＩ＝１，ＴＯＩ＝４）及び／又は第５チャンク（ＴＳＩ＝１，ＴＯＩ＝５）を含むことができる。
【０９５２】
受信機は、第１チャンクを含む第１パケット（ＴＳＩ＝１，ＴＯＩ＝１，Ｓｔａｒｔ  Ｏｆｆｓｅｔ＝０）、第２チャンクを含む第２パケット（ＴＳＩ＝１，ＴＯＩ＝２，Ｓｔａｒｔ  Ｏｆｆｓｅｔ＝２００）、第３チャンクを含む第３パケット（ＴＳＩ＝１，ＴＯＩ＝３，Ｓｔａｒｔ  Ｏｆｆｓｅｔ＝１０００）、第４チャンクを含む第４パケット（ＴＳＩ＝１，ＴＯＩ＝４，Ｓｔａｒｔ  Ｏｆｆｓｅｔ＝０）、及び／又は第５チャンクを含む第５パケット（ＴＳＩ＝１，ＴＯＩ＝５，Ｓｔａｒｔ  Ｏｆｆｓｅｔ＝１０００）を受信することができる。ここでは一つのパケットが一つのチャンクを含むとして説明したが、一つのチャンクが少なくとも一つのパケットを含むことができる。
【０９５３】
ＴＯＩがオブジェクト（例えば、ファイル）にマッチされるのではなく、オブジェクトよりも小さいデータ単位であるオブジェクト内部構造体にマッチされると、受信機は、オブジェクトを識別できる別の情報がない限り、オブジェクトを識別することができない。
【０９５４】
したがって、受信機は、ＴＳＩ及びＴＯＩだけでは、受信した第１パケット、第２パケット及び／又は第３パケットが第１オブジェクトに属するか、又は第２オブジェクトに属するかを正確に認識することができない。また、受信機は、ＴＳＩ及びＴＯＩだけでは、受信した第４パケット及び／又は第５パケットが第１オブジェクトに属するか、又は第２オブジェクトに属するかが認識できない。
【０９５５】
すなわち、受信機は、第１パケット乃至第５パケットが順次に配列されることはＴＳＩ及びＴＯＩに基づいて識別できるが、第３パケットが第１オブジェクトに属するか第２オブジェクトに属するかは、ＴＳＩ及びＴＯＩだけからは識別できない。また、第４パケットが第３パケットの次のパケットであることは、ＴＳＩ及びＴＯＩに基づいて識別できるが、第４パケットが第１オブジェクトに属するか又は第２オブジェクトに属するかは、ＴＳＩ及びＴＯＩだけでは識別できない。
【０９５６】
この場合、受信機は、第１パケット、第２パケット、及び／又は第３パケットを受信しても、第１オブジェクトを正確に復元することができない。また、受信機は、第４パケット及び／又は第５パケットを受信しても、第２オブジェクトを正確に復元することができない。その結果、受信機は実時間でコンテンツを再生することができない。
【０９５７】
したがって、本発明の他の実施例に係るＬＣＴパケットは、オフセット情報（Ｓｔａｒｔ  Ｏｆｆｓｅｔ）を提供することを特徴とする。オフセット情報は、オブジェクト内で現在伝送中のパケットペイロードのオフセットを示すことができる。受信機は、オフセット情報に基づいて、同一のオブジェクト内に含まれるオブジェクト内部構造体及び／又はパケットを識別することができる。
【０９５８】
オフセット情報の値が‘０’であれば、当該パケットが当該オブジェクトの最初のパケットであることを示す。すなわち、第１パケット及び第４パケットのオフセット情報は‘０’であるから、第１パケット及び第４パケットは別個のオブジェクトに属し、それぞれ、当該オブジェクトの最初のパケットであることを示す。また、受信機は、オフセット情報だけでなく、ＴＳＩ及び／又はＴＯＩに基づいて、第１パケット、第２パケット、及び／又は第３パケットが第１オブジェクトに属し、第４パケット及び／又は第５パケットが第２オブジェクトに属するということを識別することができる。
【０９５９】
したがって、受信機は、ＴＳＩ、ＴＯＩ、及び／又はオフセット情報のうち少なくとも一つに基づいて、受信したＬＣＴパケットがそれぞれのオブジェクト内でどの位置に該当するかを識別し、受信したＬＣＴパケットを順に整列することができる。例えば、受信機は、オフセット情報及びＴＯＩが順次に増加するようにパケットを整列することができる。
【０９６０】
その後、受信機は、オフセット情報が‘０’であるパケットから次のオフセット情報が‘０’であるパケットの以前パケットまでを一つのオブジェクトとして識別することができる。そして、受信機は、ＴＯＩに基づいて、一つのオブジェクト内でデリバリオブジェクト及び／又はオブジェクト内部構造体を識別することができる。
【０９６１】
また、受信機は、それぞれのデリバリオブジェクト及び／又はそれぞれのオブジェクトを正確に復元することができる。
【０９６２】
また、受信機は、ＴＳＩ、ＴＯＩ、及び／又はオフセット情報のうち少なくとも一つに基づいて、それぞれのデリバリオブジェクト及び／又はそれぞれのオブジェクトを正確にパース及び／又はデコードすることができる。
【０９６３】
前述したように、送信機が、独立して有意な単位であるオブジェクト内部構造体（Ｏｂｊｅｃｔ  Ｉｎｔｅｒｎａｌ  Ｓｔｒｕｃｔｕｒｅ）単位でデータを伝送すると、可変サイズでデータを実時間で伝送することができる。したがって、受信機は、一つのオブジェクトを全て受信する前であっても、オブジェクト内部構造体を受信及び識別すると、オブジェクト内部構造体単位で再生することができる。その結果、ファイル（又はオブジェクト）ベースのマルチメディアコンテンツを放送網を介して実時間で伝送及び再生することができる。
【０９６４】
図５９は、本発明の他の実施例に係るＲＡＰ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）情報を含むパケットの構造を示す図である。
【０９６５】
本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、パケットヘッダー及びパケットペイロードを含むことができる。パケットヘッダーは、パケットペイロードに対するメタデータを含むことができる。パケットペイロードは、ＭＰＥＧ−ＤＡＳＨコンテンツのデータを含むことができる。
【０９６６】
例えば、パケットヘッダーは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、予約フィールド（Ｒｅｓ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、及び／又はＦＥＣペイロードＩＤフィールドを含むことができる。
【０９６７】
また、パケットペイロードはシンボルエンコーディングフィールドを含むことができる。
【０９６８】
本発明の他の実施例に係るＬＣＴパケットを構成する各フィールドのうち、前述したフィールドと同じ名称のフィールドは前述の内容を全て含むことができ、その具体的な説明は前述の説明に代える。
【０９６９】
パケットヘッダーは、ＲＡＰ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）情報（Ｐ）をさらに含むことができる。ＲＡＰ情報（Ｐ）は、現在パケットが送信しているパケットペイロードに、ランダムアクセスポイント（ＲＡＰ）に該当するデータが含まれているか否かを示すことができる。ＲＡＰ情報（Ｐ）は、各パケットの開始地点から１２番目又は１３番目のビットに位置する１個のビットを用いて、現在パケットが送信しているパケットペイロードに、ランダムアクセスポイント（ＲＡＰ）に該当するデータが含まれているか否かを示すことができる。この場合、１ビットを使用するので、パケットヘッダーのサイズを減らし、効率性を高めることができる。
【０９７０】
ランダムアクセスポイント（ＲＡＰ）は、他のフレームを参照しないで符号化可能であり、且つ、ランダムアクセスが可能な基本フレームを意味する。例えば、‘Ｉ−フレーム’は、ＭＰＥＧで当該フレームの前のフレーム及び後のフレームを使用する時間的圧縮技術を利用せず、他のフレームとは独立して空間的圧縮技術だけを用いて生成されるフレームを意味する。したがって、‘Ｉ−フレーム’は、イメージから直接コードして生成されることから、インターブロック（ｉｎｔｅｒ  ｂｌｏｃｋ）のみから構成され、ランダムアクセスポイント（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）の役割を担うことができる。
【０９７１】
受信器は、ＲＡＰ情報（Ｐ）に基づいて、伝送されているパケットシーケンス（ｓｅｑｕｅｎｃｅ）においてランダムアクセスが可能なパケットを識別することができる。例えば、受信したパケットのペイロードが‘Ｉ−フレーム’に関するデータを含んでいると、ＲＡＰ情報（Ｐ）は、当該パケットがランダムアクセスポイント（ＲＡＰ）に該当するデータを含んでいることを示すことができる。また、受信したパケットのペイロードが‘Ｂ−フレーム’及び／又は‘Ｐ−フレーム’に関するデータを含んでいると、ＲＡＰ情報（Ｐ）は、当該パケットがランダムアクセスポイント（ＲＡＰ）に該当するデータを含んでいないと示すことができる。
【０９７２】
受信器が特定時点からＧＯＰデータを順次に受信する時、最初のパケットが‘Ｉ−フレーム’のようにＲＡＰに該当すると、受信機は、当該パケットからデコーディングを始めることができる。しかし、最初のパケットが‘Ｂ−フレーム’及び／又は‘Ｐ−フレーム’のようにＲＡＰに該当しないと、受信機は、当該パケットからデコーディングを始めることができない。この場合、受信機は、ＲＡＰでないパケットはスキップし、続く‘Ｉ−フレーム’のようにＲＡＰに該当するパケットからデコードし始めることができる。
【０９７３】
したがって、放送環境におけるチャネルチューニング又はユーザの要求によるシーケンス内の任意地点接近状況において、受信機は、ＲＡＰ情報（Ｐ）に基づいて、ＲＡＰに該当しないパケットはスキップし、ＲＡＰに該当するパケットからデコードするため、パケットの受信及びデコーディング効率を上げることができる。
【０９７４】
図６０は、本発明の他の実施例に係るＲＡＰ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）情報を含むパケットの構造を示す図である。
【０９７５】
本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、パケットヘッダー及びパケットペイロードを含むことができる。パケットヘッダーは、パケットペイロードに対するメタデータを含むことができる。パケットペイロードは、ＭＰＥＧ−ＤＡＳＨコンテンツのデータを含むことができる。
【０９７６】
例えば、パケットヘッダーは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、予約フィールド（Ｒｅｓ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、及び／又はＦＥＣペイロードＩＤフィールドを含むことができる。
【０９７７】
また、パケットペイロードは、シンボルエンコーディングフィールドを含むことができる。
【０９７８】
パケットヘッダーは、ＲＡＰ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）情報（Ｐ）をさらに含むことができる。
【０９７９】
本発明の他の実施例に係るＬＣＴパケットを構成する各フィールドのうち、前述したフィールドと同じ名称のフィールドは前述の内容を全て含むことができ、その具体的な説明は前述の説明に代える。
【０９８０】
ＲＡＰ情報（Ｐ）は、各パケットの開始地点から６番目又は７番目のビットに位置する１個のビットを用いて、現在パケットが送信しているパケットペイロードに、ランダムアクセスポイント（ＲＡＰ）に該当するデータが含まれているか否かを示すことができる。この場合、１ビットを使用するので、パケットヘッダーのサイズを減らすことができ、効率性を高めることができる。
【０９８１】
本発明の他の実施例に係るパケットは、パケットヘッダーの６番目又は７番目のビットに位置するビットを用いてＲＡＰ情報（Ｐ）を含むので、パケットヘッダーの１２番目又は１３番目のビットを他の用途に用いることができる。
【０９８２】
例えば、パケットは、パケットヘッダーの６番目又は７番目のビットを用いてＲＡＰ情報（Ｐ）を含み、パケットヘッダーの１２番目及び／又は１３番目のビットを用いて、前述したオブジェクトタイプ情報、及び／又は前述した優先順位情報を含むことができる。
【０９８３】
図６１は、本発明の他の実施例に係る実時間（Ｒｅａｌ  Ｔｉｍｅ）情報を含むパケットの構造を示す図である。
【０９８４】
本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、パケットヘッダー及びパケットペイロードを含むことができる。パケットヘッダーは、パケットペイロードに対するメタデータを含むことができる。パケットペイロードは、ＭＰＥＧ−ＤＡＳＨコンテンツのデータを含むことができる。
【０９８５】
例えば、パケットヘッダーは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、予約フィールド（Ｒｅｓ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、及び／又はＦＥＣペイロードＩＤフィールドを含むことができる。
【０９８６】
また、パケットペイロードはシンボルエンコーディングフィールドを含むことができる。
【０９８７】
本発明の他の実施例に係るＬＣＴパケットを構成する各フィールドのうち、前述したフィールドと同じ名称のフィールドは前述の内容を全て含むことができ、その具体的な説明は前述の説明に代える。
【０９８８】
送信機は、ＦＤＴ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ）レベル及び／又はデリバリオブジェクトレベルで定義される実時間情報（Ｔ）を用いて、ＬＣＴパケットが送信しているオブジェクト及び／又はオブジェクト内部構造体が実時間で伝送されるか又は非実時間で伝送されるかを示すことができる。デリバリオブジェクトレベルは、オブジェクトレベル、及び／又はオブジェクト内部構造体レベルを含むことができる。
【０９８９】
実時間情報（Ｔ）がＦＤＴレベルで定義されると、実時間情報（Ｔ）は、当該ＦＤＴで記述する全データが実時間で伝送されるか又は非実時間で伝送されるかを示すことができる。例えば、ＬＳＩＤは実時間情報（Ｔ）を含むことができる。また、実時間情報（Ｔ）がＦＤＴレベルで定義されると、実時間情報（Ｔ）は、当該ＦＤＴで記述する全オブジェクトが実時間で伝送されるか非実時間で伝送されるかを示すことができる。ここで、当該ＦＤＴで記述する全オブジェクトは、当該ＬＣＴ伝送セッションに属する全オブジェクトを示すことができる。
【０９９０】
また、実時間情報（Ｔ）がデリバリオブジェクトレベルで定義されると、実時間情報（Ｔ）は、当該デリバリオブジェクトに属する全データが実時間で伝送されるか非実時間で伝送されるかを示すことができる。例えば、デリバリオブジェクトがオブジェクトにマッチされる場合、実時間情報（Ｔ）がデリバリオブジェクトレベルで定義されると、実時間情報（Ｔ）は、当該オブジェクトに属する全データが実時間で伝送されるか非実時間で伝送されるかを示すことができる。また、デリバリオブジェクトがオブジェクト内部構造体にマッチされる場合、実時間情報（Ｔ）がデリバリオブジェクトレベルで定義されると、実時間情報（Ｔ）は、当該オブジェクト内部構造体に属する全データが実時間で伝送されるか非実時間で伝送されるかを示すことができる。
【０９９１】
一実施例として、実時間情報（Ｔ）がデリバリオブジェクトレベルで定義されると、パケットヘッダーは、実時間（Ｒｅａｌ  Ｔｉｍｅ）情報（Ｔ）をさらに含むことができる。実時間情報（Ｔ）は、ＬＣＴパケットが送信しているデリバリオブジェクトが実時間（Ｒｅａｌ  Ｔｉｍｅ）で伝送されるか非実時間（Ｎｏｎ  Ｒｅａｌ  Ｔｉｍｅ）で伝送されるかを示すことができる。
【０９９２】
例えば、デリバリオブジェクトはＴＯＩにマッチされるデータ単位であってもよい。また、実時間情報（Ｔ）の値が‘０’であれば、ＬＣＴパケットが送信しているデリバリオブジェクトは非実時間で伝送されることを示すことができ、実時間情報（Ｔ）の値が‘１’であれば、ＬＣＴパケットが送信しているデリバリオブジェクトは実時間で伝送されることを示すことができる。
【０９９３】
実時間情報（Ｔ）は、ＴＯＩフィールドの最初のビットを用いて、ＬＣＴパケットが送信しているデリバリオブジェクトが実時間で伝送されるか非実時間で伝送されるかを示すことができる。
【０９９４】
前述したように、ＴＯＩフィールドをＯＧＩフィールド及びＤＴＯＩフィールドに分割した場合、実時間情報（Ｔ）は、ＯＧＩフィールドの最初のビットを用いて、ＬＣＴパケットが送信しているデリバリオブジェクトが実時間で伝送されるか非実時間で伝送されるかを示すことができる。
【０９９５】
実時間情報（Ｔ）はＴＯＩフィールド及び／又はＯＧＩフィールドの最初のビットに含まれるので、送信機は、一つのＬＣＴ伝送セッション（例えば、ビデオトラック、オーディオトラック、ＭＰＥＧ−ＤＡＳＨのＲｅｐｒｅｓｅｎｔａｔｉｏｎ）内で実時間データ及び非実時間データを共に伝送することができる。例えば、送信機は、一つのＬＣＴ伝送セッション内でオーディオデータ及び／又はビデオデータを実時間で伝送することができ、イメージ及び／又はアプリケーションなどを非実時間で伝送することができる。また、送信機は、一つのＬＣＴ伝送セッション内で一部のデリバリオブジェクトは実時間で伝送し、残りのデリバリオブジェクトは非実時間で伝送することができる。
【０９９６】
また、実時間情報（Ｔ）は既存のＴＯＩフィールドの最初のビットに含まれるので、本発明の他の実施例に係るＬＣＴパケットは、既存のＡＬＣ／ＬＣＴ及び／又はＦＬＵＴＥプロトコルとの下位互換性を保障することができる。
【０９９７】
図６２は、本発明の他の実施例に係る放送信号送信装置の構造を示す図である。
【０９９８】
本発明の他の実施例に係る放送信号送信装置は、デリバリオブジェクト生成器Ｃ５１３００、シグナリングエンコーダＣ５１１００、及び／又は送信器Ｃ３１５００を含むことができる。
【０９９９】
デリバリオブジェクト生成器は、ファイルを、ファイルの一部（ａ  ｐａｒｔ  ｏｆ  ｔｈｅ  ｆｉｌｅ）に該当する少なくとも一つのデリバリオブジェクト（Ｄｅｌｉｖｅｒｙ  Ｏｂｊｅｃｔ）に分割することができる。
【１０００】
シグナリングエンコーダ（Ｓｉｇｎａｌｉｎｇ  Ｅｎｃｏｄｅｒ）は、デリバリオブジェクトに対するメタデータを含むシグナリング情報をエンコードすることができる。
【１００１】
シグナリング情報は、少なくとも一つのデリバリオブジェクトが少なくても一つのＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）パケットを用いて、単方向チャネル（ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  ｃｈａｎｎｅｌ）を介して実時間で伝送されるか否かを示す実時間情報を含むことができる。
【１００２】
送信器（ｔｒａｎｓｍｉｔｔｅｒ）は、少なくとも一つのデリバリオブジェクト及びシグナリング情報を伝送することができる。
【１００３】
本発明の他の実施例に係る放送信号送信装置は、前述した放送信号送信装置の機能を全て含むことができる。また、シグナリング情報に関する具体的な内容は、前述した内容に代えたり、次の図面で具体的に説明するものとする。
【１００４】
図６３は、本発明の他の実施例に係る放送信号受信装置の構造を示す図である。
【１００５】
放送信号受信装置は放送信号を受信することができる。放送信号は、シグナリングデータ、ＥＳＧデータ、ＮＲＴコンテンツデータ及び／又はＲＴコンテンツデータを含むことができる。
【１００６】
放送信号受信装置は、ＲＯＵＴＥセッション記述に基づいてＲＯＵＴＥセッションに参加（ｊｏｉｎ）することができる。ＲＯＵＴＥセッション記述は、放送信号送信装置のＩＰアドレス、ＲＯＵＴＥセッションのアドレス及びポート番号、当該セッションがＲＯＵＴＥセッションであり、全パケットはＬＣＴパケットであることを示す情報を含むことができる。また、ＲＯＵＴＥセッション記述は、当該セッションをＩＰ／ＵＤＰを用いて参加（ｊｏｉｎ）及び消費（ｃｏｎｓｕｍｅ）するために必要な情報をさらに含むことができる。
【１００７】
その後、放送信号受信装置は、ＲＯＵＴＥセッションに含まれた少なくとも一つのＬＣＴ伝送セッションに関する情報を含んでいるＬＣＴ  ＬＳＩＤ（Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）を受信することができる。
【１００８】
その後、放送信号受信装置は、少なくとも一つのＬＣＴ伝送セッションに含まれたマルチメディアコンテンツを受信することができる。マルチメディアコンテンツは少なくとも一つのファイルで構成されてもよい。そして、放送信号受信装置は、ＬＣＴパケットを用いて、単方向チャネルを介してファイルベースのマルチメディアコンテンツを実時間で受信することができる。
【１００９】
そのために、本発明の他の実施例に係る放送信号受信装置は、シグナリングデコーダ（Ｓｉｇｎａｌｉｎｇ  Ｄｅｃｏｄｅｒ）Ｃ５２１００、デリバリオブジェクトプロセッサ（Ｄｅｌｉｖｅｒｙ  Ｏｂｊｅｃｔ  Ｐｒｏｃｅｓｓｏｒ）Ｃ５２３００、及び／又はデコーダ（Ｄｅｃｏｄｅｒ）Ｃ５２５００を含むことができる。
【１０１０】
シグナリングデコーダＣ５２１００は、ファイルの一部（ｐａｒｔ  ｏｆ  ａ  ｆｉｌｅ）に該当する少なくとも一つのデリバリオブジェクトに対するメタデータを含むシグナリング情報をデコードすることができる。
【１０１１】
シグナリング情報は、少なくとも一つのデリバリオブジェクトがＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）パケットを用いて単方向チャネルを介して実時間で伝送されるか否かを示す実時間情報を含むことができる。シグナリング情報はＬＳＩＤだけでなく、ＬＣＴパケットの拡張されたヘッダーにも含まれてもよい。
【１０１２】
実時間情報は、ＦＤＴ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ）で定義され、実時間情報は、ＦＤＴで記述する全デリバリオブジェクトが実時間で伝送されるか否かを示すことができる。また、実時間情報は、上記デリバリオブジェクトを識別するＴＯＩ（Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ）フィールドの最初のビットで定義され、実時間情報は、当該デリバリオブジェクトに属する全データが実時間で伝送されるか否かを示すことができる。
【１０１３】
デリバリオブジェクトプロセッサＣ５２３００は、上記少なくとも一つのＬＣＴパケットを収集し、少なくとも一つのデリバリオブジェクトを復元することができる。デリバリオブジェクトプロセッサＣ５２３００は、前述した送信ブロック再生成器Ｃ２２０３０、フラグメント再生成器Ｃ２２０４０、フラグメントパーサーＣ２２０５０、及び／又は抽出器Ｃ３２０５０の機能を含むことができる。
【１０１４】
デコーダＣ５２５００は、少なくとも一つのデリバリオブジェクトをデコードすることができる。デコーダＣ５２５００は、デリバリオブジェクトに関する情報を少なくとも一つのアクセスユニットの形態で受け取り、少なくとも一つのアクセスユニットをデコードしてメディアデータを生成することができる。デコーダＣ５２５００は、ファイルの一部に該当するデリバリオブジェクトを受信すると、一つのファイルを全て受信しなくてもデリバリオブジェクトをデコードすることができる。
【１０１５】
シグナリング情報は、ファイル内でＬＣＴパケットが送信しているデータのオフセットを示すオフセット情報をさらに含むことができる。デリバリオブジェクトプロセッサＣ５２３００は、オフセット情報に基づいてデリバリオブジェクトを識別することができる。オフセット情報は、オフセットをファイルの開始地点からのバイト数で示すことができる。オフセット情報は、ＬＣＴヘッダー拡張の形式であってもよく、ＦＥＣペイロードＩＤフィールドに含まれてもよい。
【１０１６】
放送信号受信装置が可変サイズのデリバリオブジェクトの単位で実時間でＬＣＴパケットを受信する場合、放送信号受信装置は、受信したＬＣＴパケットがオブジェクト内でどの位置に該当するかを認識できないことが発生する。例えば、放送信号受信装置が任意の順でＬＣＴパケットを受信する場合、放送信号受信装置は、ＬＣＴパケットを順序通りに整列できず、デリバリオブジェクトを正確に復元及び／又はパースできない場合が発生する。
【１０１７】
したがって、本発明の他の実施例に係るオフセット情報は、ファイル（例えば、オブジェクト）内で現在伝送中のパケットペイロードのオフセットを示すことができる。放送信号受信装置は、オフセット情報に基づいて、現在伝送中のＬＣＴパケットが当該ファイルの最初のデータを有することを認識することができる。また、放送信号受信装置は、オフセット情報に基づいて、当該ファイル及び／又はデリバリオブジェクト内で現在伝送中のＬＣＴパケットの順序を認識することができる。
【１０１８】
また、放送信号受信装置は、オフセット情報に基づいて現在ＬＣＴパケットが送信しているパケットペイロードのファイル内におけるオフセットを認識できる他、現在ＬＣＴパケットが送信しているデリバリオブジェクトのファイル内におけるオフセットも認識することができる。
【１０１９】
ＴＯＩがオブジェクト（例えば、ファイル）にマッチされるのではなく、オブジェクトよりも小さいデータ単位であるオブジェクト内部構造体にマッチされると、放送信号受信装置は、オブジェクトを識別できる別の情報がない限り、オブジェクトを識別することができない。
【１０２０】
したがって、放送信号受信装置は、オフセット情報に基づいて、同一のオブジェクト内に含まれるオブジェクト内部構造体及び／又はＬＣＴパケットを識別することができる。
【１０２１】
シグナリング情報は、ＬＣＴパケットがランダムアクセスポイント（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ；ＲＡＰ）に該当するデータを含んでいるか否かを示すＲＡＰ情報をさらに含むことができる。ランダムアクセスポイントは、他のフレームを参照しないで符号化でき、且つランダムアクセスが可能な基本フレームを意味する。
【１０２２】
デリバリオブジェクトプロセッサＣ５２３００は、ＲＡＰ情報に基づいて、ランダムアクセスポイントに該当するデータを送信するパケットから始まって少なくとも一つのパケットを収集することができる。
【１０２３】
例えば、放送信号受信装置は、特定時点から順次にＧＯＰデータを受信するとき、最初のパケットが‘Ｉ−フレーム’のようにＲＡＰに該当すると、放送信号受信装置は、当該ＬＣＴパケットからデコードし始めることができる。しかし、最初のＬＣＴパケットが‘Ｂ−フレーム’及び／又は‘Ｐ−フレーム’のようにＲＡＰに該当しないと、受信器は、当該ＬＣＴパケットからデコーディングを始めることができない。この場合、放送信号受信装置は、ＲＡＰでないＬＣＴパケットはスキップし、続く‘Ｉ−フレーム’のようにＲＡＰに該当するＬＣＴパケットからデコードし始めることができる。
【１０２４】
シグナリング情報は、ＬＣＴパケットが送信しているデータの優先順位を示す優先順位情報（Ｐｒｉｏｒｉｔｙ  ｉｎｆｏｒｍａｔｉｏｎ）をさらに含むことができる。
【１０２５】
デリバリオブジェクトプロセッサＣ５２３００は優先順位情報に基づいてＬＣＴパケットを選択的に収集することができる。
【１０２６】
放送信号受信装置は、ＡＶＣ／ＨＥＶＣなどのビデオデータを受信する場合に、‘ｆｔｙｐ’、‘ｍｏｏｖ’、‘ｍｏｏｆ’、‘Ｉ−Ｐｉｃｔｕｒｅ’、‘Ｐ−Ｐｉｃｔｕｒｅ’、及び／又は‘Ｂ−Ｐｉｃｔｕｒｅ’の優先順位情報に基づいて、優先順位の高いＬＣＴパケットを優先して抽出し、優先順位の低いＬＣＴパケットを選択的に抽出して、一つのシーケンスを構成することができる。
【１０２７】
図６４は、本発明の実施例に係る次世代放送システムのためのプロトコルスタックを示す図である。
【１０２８】
本発明に係る放送システムは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）中心放送ネットワーク及びブロードバンドが結合されたハイブリッド放送システムに対応し得る。
【１０２９】
本発明に係る放送システムは、従来のＭＰＥＧ−２ベースの放送システムとの互換性を維持するように設計されていてもよい。
【１０３０】
本発明に係る放送システムは、ＩＰ中心放送ネットワーク、ブロードバンドネットワーク及び／又はモバイル通信ネットワーク（又はセルラーネットワーク）の結合に基づくハイブリッド放送システムに対応してもよい。
【１０３１】
同図を参照すると、物理層は、ＡＴＳＣシステム及び／又はＤＶＢシステムなどの放送システムで採択された物理プロトコルを用いることができる。例えば、本発明に係る物理層で、送信機／受信機は、地上波放送信号を送受信し、放送データを含む伝送フレームを適宜の形態に変換することができる。
【１０３２】
カプセル化層で、ＩＰデータグラムが、物理層から取得された情報から取得されたり、又は取得されたＩＰデータグラムが特定フレーム（例えば、ＲＳフレーム、ＧＳＥ−ｌｉｔｅ、ＧＳＥ又は信号フレーム）に変換される。フレームは、ＩＰデータグラムのセットを含むことができる。例えば、カプセル化層で、送信機が伝送フレーム内の物理層で処理されたデータを含めたり、又は、受信機が物理層から取得された伝送フレームからＭＰＥＧ−２ＴＳ及びＩＰデータグラムを抽出する。
【１０３３】
ＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ）は、サービス及び／又はコンテンツにアクセスするために必要な情報（例えば、サービスＩＤ及びフレーム間のマッピング情報）を含む。ＦＩＣをＦＡＣ（ｆａｓｔ  ａｃｃｅｓｓ  ｃｈａｎｎｅｌ）と呼ぶこともできる。
【１０３４】
本発明に係る放送システムは、インターネットプロトコル（ＩＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、送信制御プロトコル（ＴＣＰ）、ＡＬＣ／ＬＣＴ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ／Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）、ＲＣＰ／ＲＴＣＰ（Ｒａｔｅ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）及びＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）などのプロトコルを用いることができる。これらのプロトコル間のスタックは、同図に示す構造を参照すればよい。
【１０３５】
本発明に係る放送システムでは、データを、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）の形態で伝送することができる。ＥＳＧ（Ｅｌｅｃｔｒｉｃａｌ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）、ＮＲＴ（Ｎｏｎ  Ｒｅａｌ  Ｔｉｍｅ）、Ａ／Ｖ（Ａｕｄｉｏ／Ｖｉｄｅｏ）及び／又は一般データをＩＳＯＢＭＦＦの形態で伝送することができる。
【１０３６】
放送ネットワークを介したデータの伝送は、線形コンテンツの伝送及び／又は非線形コンテンツの伝送を含むことができる。
【１０３７】
ＲＴＰ／ＲＴＣＰベースのＡ／Ｖ及びデータ（字幕、緊急警報メッセージなど）の伝送は、線形コンテンツの伝送に対応してもよい。
【１０３８】
ＲＴＰペイロードは、ＮＡＬ（Ｎｅｔｗｏｒｋ  Ａｂｓｔｒａｃｔｉｏｎ  Ｌａｙｅｒ）を含むＲＴＰ／ＡＶストリームの形態及び／又はＩＳＯベースメディアファイルフォーマットでカプセル化された形態で伝送されてもよい。ＲＴＰペイロードの伝送は、線形コンテンツの伝送に対応してもよい。ＩＳＯベースメディアファイルフォーマットでカプセル化された形態の伝送は、Ａ／Ｖに対するＭＰＥＧ  ＤＡＳＨメディアセグメントなどを含むことができる。
【１０３９】
ＦＬＵＴＥベースＥＳＧの伝送、ノン−タイムド（ｎｏｎ−ｔｉｍｅｄ）データの伝送、ＮＲＴコンテンツの伝送は、非線形コンテンツの伝送に対応してもよい。これらは、ＭＩＭＥタイプファイル形態及び／又はＩＳＯベースメディアファイルフォーマットでカプセル化された形態で伝送されてもよい。ＩＳＯベースメディアファイルフォーマットでカプセル化された形態の伝送は、Ａ／Ｖに対するＭＰＥＧ  ＤＡＳＨメディアセグメントなどを含むことができる。
【１０４０】
ブロードバンドネットワークを介した伝送は、コンテンツの伝送及びシグナリングデータの伝送とに分割することができる。
【１０４１】
コンテンツの伝送は、線形コンテンツ（Ａ／Ｖ及びデータ（字幕、緊急警報メッセージなど）、非線形コンテンツ（ＥＳＧ、ノン−タイムドデータなど）の伝送、及びＭＰＥＧ  ＤＡＳＨベースメディアセグメント（Ａ／Ｖ及びデータ）の伝送を含む。
【１０４２】
シグナリングデータの伝送は、放送ネットワークで送信されたシグナリングテーブルを含む（ＭＰＥＧ  ＤＡＳＨのＭＰＤを含む。）伝送であってもよい。
【１０４３】
本発明に係る放送システムで、放送ネットワークで伝送される線形／非線形コンテンツ間の同期化、又は放送ネットワークで伝送されるコンテンツ及びブロードバンドで送信されたコンテンツ間の同期化を支援することができる。例えば、一つのＵＤコンテンツが個別に及び同時に放送ネットワーク及びブロードバンドで伝送される場合に、受信機は、伝送プロトコルによってタイムラインを調節し、放送ネットワークを介したコンテンツとブロードバンドを介したコンテンツとを同期化し、一つのＵＤコンテンツとしてコンテンツを再構成することができる。
【１０４４】
本発明に係る放送システムのアプリケーション層は、双方向性（ｉｎｔｅｒａｃｔｉｖｉｔｙ）、個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）、第２スクリーン及び自動コンテンツ認識（ＡＣＲ；ａｕｔｏｍａｔｉｃ  ｃｏｎｔｅｎｔ  ｒｅｃｏｇｎｉｔｉｏｎ）などの技術的特性を実現することができる。それらの特性は、ＡＴＳＣ２．０からＡＴＳＣ３．０までの拡張において重要である。例えば、ＨＴＭＬ５を双方向性の特性に用いることができる。
【１０４５】
本発明に係る放送システムのプレゼンテーション層で、ＨＴＭＬ及び／又はＨＴＭＬ５は、コンポーネント又はインタラクティブアプリケーション間の空間及び時間的関係を識別するために用いることができる。
【１０４６】
本発明で、シグナリングは、コンテンツ及び／又はサービスの効果的な取得を支援するために必要なシグナリング情報を含む。シグナリングデータをバイナリ又はＸＭＬ  ｇｕｄｘｏｆｈで表現することができる。シグナリングデータは、地上波放送ネットワーク又はブロードバンドで送信することができる。
【１０４７】
実時間放送Ａ／Ｖコンテンツ及び／又はデータをＩＳＯベースメディアファイルフォーマットなどで表現することができる。この場合、Ａ／Ｖコンテンツ及び／又はデータは、実時間で地上波放送ネットワークを介して送信されてもよく、非実時間でＩＰ／ＵＤＰ／ＦＬＵＴＥに基づいて送信されてもよい。代案として、放送Ａ／Ｖコンテンツ及び／又はデータは、実時間にインターネットでＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）を用いてストリーミングモードでコンテンツを受信したり、又は要求することによって受信することができる。本発明の実施例に係る放送システムで、受信された放送Ａ／Ｖコンテンツ及び／又はデータは結合され、インタラクティブサービス及び第２スクリーンサービスなどの様々な向上したサービスを視聴者に提供することができる。
【１０４８】
送信機の物理層（Ｂｒｏａｄｃａｓｔ  ＰＨＹ及びＢｒｏａｄｂａｎｄ  ＰＨＹ）は、図１に示した構造を実施例とすることができる。また、受信機の物理層は、図９に示した構造を実施例とすることができる。
【１０４９】
シグナリングデータ及びＩＰ／ＵＤＰデータグラムは、物理層に伝達される伝送フレーム（又はフレーム）の特定データパイプ（以下、ＤＰ）で伝送されてもよい。例えば、入力フォーマットブロック１０００は、シグナリングデータ及びＩＰ／ＵＤＰデータグラムを受信し、それぞれのシグナリングデータ及びＩＰ／ＵＤＰデータグラムを少なくとも一つのＤＰに逆多重化することができる。出力プロセッサ９３００は、入力フォーマットブロック１０００と逆の動作を行うことができる。
【１０５０】
図６５は、本発明の一実施例に係る、次世代放送システムの受信機を示す図である。
【１０５１】
本発明の一実施例に係る受信機は、受信部（図示せず）、チャネル同期化器（Ｃｈａｎｎｅｌ  Ｓｙｎｃｈｒｏｎｉｚｅｒ）Ｊ３２０１０、チャネル等化器（Ｃｈａｎｎｅｌ  Ｅｑｕａｌｉｚｅｒ）Ｊ３２０２０、チャネルデコーダ（Ｃｈａｎｎｅｌ  Ｄｅｃｏｄｅｒ）Ｊ３２０３０、シグナリングデコーダ（Ｓｉｇｎａｌｉｎｇ  Ｄｅｃｏｄｅｒ）Ｊ３２０４０、ベースバンド動作コントローラ（Ｂａｓｅｂａｎｄ  Ｏｐｅｒａｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ）Ｊ３２０５０、サービスマップデータベース（Ｓｅｒｖｉｃｅ  Ｍａｐ  ＤＢ）Ｊ３２０６０、伝送パケットインターフェース（Ｔｒａｎｓｐｏｒｔ  Ｐａｃｋｅｔ  Ｉｎｔｅｒｆａｃｅ）Ｊ３２０７０、ブロードバンドパケットインターフェース（Ｂｒｏａｄｂａｎｄ  Ｐａｃｋｅｔ  Ｉｎｔｅｒｆａｃｅ）Ｊ３２０８０、コモンプロトコルスタック処理器（Ｃｏｍｍｏｎ  Ｐｒｏｔｏｃｏｌ  Ｓｔａｃｋ）Ｊ３２０９０、サービスシグナリングチャネルプロセシングバッファ及びパーサー（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｃｈａｎｎｅｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｂｕｆｆｅｒ  ＆  Ｐａｒｓｅｒ）Ｊ３２１００、Ａ／Ｖプロセッサ（Ａ／Ｖ  Ｐｒｏｃｅｓｓｏｒ）Ｊ３２１１０、サービスガイドプロセッサ（Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ  Ｐｒｏｃｅｓｓｏｒ）Ｊ３２１２０、アプリケーションプロセッサ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｃｅｓｓｏｒ）Ｊ３２１３０、及び／又はサービスガイドデータベース（Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ  ＤＢ）Ｊ３２１４０を含むことができる。
【１０５２】
受信部（図示せず）は放送信号を受信する。
【１０５３】
チャネル同期化器Ｊ３２０１０は、ベースバンド（Ｂａｓｅｂａｎｄ）で受信した信号のデコーディングが可能なようにシンボル（ｓｙｍｂｏｌ）周波数とタイミング（ｔｉｍｉｎｇ）を同期化する。ここで、ベースバンドは、放送信号が送／受信される領域を意味する。
【１０５４】
チャネル等化器Ｊ３２０２０は、受信された信号に対してチャネル等化を行う。チャネル等化器Ｊ３２０２０はね受信された信号が多重経路（ｍｕｌｔｉｐａｔｈ）、ドップラー効果（Ｄｏｐｐｌｅｒ  ｅｆｆｅｃｔ）などによって歪まれたとき、これを補償する役割を担う。
【１０５５】
チャネルデコーダ（Ｃｈａｎｎｅｌ  Ｄｅｃｏｄｅｒ）Ｊ３２０３０は、受信された信号を有意な伝送フレーム（ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）に復旧する。チャネルデコーダＪ３２０３０は、受信した信号に含まれたデータ又は伝送フレームに対して順方向誤り訂正（ｆｏｒｗａｒｄ  ｅｒｒｏｒ  ｃｏｒｒｅｃｔｉｏｎ；  ＦＥＣ）を行う。
【１０５６】
シグナリングデコーダＪ３２０４０は、受信した信号に含まれたシグナリングデータを抽出してデコードする。ここで、シグナリングデータは、後述するシグナリングデータ及び／又はサービス情報（Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ；ＳＩ）を含む。
【１０５７】
ベースバンド動作コントローラＪ３２０５０は、ベースバンドにおける信号の処理を制御する。
【１０５８】
サービスマップデータベースＪ３２０６０は、シグナリングデータ及び／又はサービス情報を記憶する。サービスマップデータベースＪ３２０６０は、放送信号に含まれて伝送されたシグナリングデータ及び／又はブロードバンドパケットに含まれて伝送されたシグナリングデータを記憶することができる。
【１０５９】
伝送パケットインターフェースＪ３２０７０は、伝送フレーム又は放送信号から伝送パケットを抽出する。伝送パケットインターフェースＪ３２０７０は、伝送パケット（ｔｒａｎｓｐｏｒｔ  ｐａｃｋｅｔ）からシグナリングデータ又はＩＰデータグラム（ＩＰ  ｄａｔａｇｒａｍ）を抽出する。
【１０６０】
ブロードバンドパケットインターフェースＪ３２０８０は、インターネット網を介して放送関連パケットを受信する。ブロードバンドパケットインターフェースＪ３２０８０は、インターネット網を介して取得されたパケット（Ｐａｃｋｅｔ）を抽出し、当該パケットからシグナリングデータ又はＡ／Ｖデータを組合せ又は抽出する。
【１０６１】
コモンプロトコルスタック処理器Ｊ３２０９０は、受信したパケットをプロトコルスタックに含まれたプロトコルによって処理する。例えば、コモンプロトコルスタック処理器Ｊ３２０９０は、前述したプロトコルスタックによって、受信したパケットを処理することができる。
【１０６２】
サービスシグナリングチャネルプロセシングバッファ及びパーサーＪ３２１００は、受信されたパケットに含まれたシグナリングデータを抽出する。サービスシグナリングチャネルプロセシングバッファ及びパーサーＪ３２１００は、ＩＰデータグラムなどからサービス及び／又はコンテンツのスキャン及び／又は取得に関連したシグナリング情報を抽出し、これをパースする。受信されたパケット内でシグナリングデータは一定の位置又はチャネルに存在してもよい。このような位置又はチャネルを、サービスシグナリングチャネルと命名することができる。例えば、サービスシグナリングチャネルは、特定ＩＰアドレス、ＵＤＰ  Ｐｏｒｔナンバー、伝送セッション識別子などを有することができる。受信機は、このような特定ＩＰアドレス、ＵＤＰ  Ｐｏｒｔナンバー、伝送セッションなどに伝送されるデータをシグナリングデータと認識することができる。
【１０６３】
Ａ／ＶプロセッサＪ３２１１０は、受信されたオーディオ及びビデオデータに対するデコーディング及びプレゼンテーション（ｐｒｅｓｅｎｔａｔｉｏｎ）処理を行う。
【１０６４】
サービスガイドプロセッサＪ３２１２０は、受信信号からアナウンスメント（ａｎｎｏｕｎｃｅｍｅｎｔ）情報を抽出し、サービスガイドデータベースＪ３２１４０を管理し、サービスガイド（ｓｅｒｖｉｃｅ  ｇｕｉｄｅ）を提供する。
【１０６５】
アプリケーションプロセッサＪ３２１３０は、受信したパケットに含まれたアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）データ及び／又はアプリケーション関連情報を抽出して、これを処理する。
【１０６６】
サービスガイドデータベースＪ３２１４０は、サービスガイドデータを記憶する。
【１０６７】
図６６は、本発明の実施例に係る放送受信機を示す図である。
【１０６８】
本発明の実施例に係る放送受信機は、サービス／コンテンツ取得コントローラＪ２０１０、インターネットインターフェースＪ２０２０、ブロードキャストインターフェースＪ２０３０、シグナリングデコーダＪ２０４０、サービスマップデータベースＪ２０５０、デコーダＪ２０６０、ターゲッティングプロセッサＪ２０７０、プロセッサＪ２０８０、管理部Ｊ２０９０、及び／又は再分配モジュールＪ２１００を含む。同図には、放送受信機の外部及び／又は内部に位置する外部管理装置Ｊ２１１０が示されている。
【１０６９】
サービス／コンテンツ取得コントローラＪ２０１０は、ブロードキャスト／ブロードバンドチャネルを介してそれに関連したサービス及び／又はコンテンツ及びシグナリングデータを受信する。代案として、サービス／コンテンツ取得コントローラＪ２０１０は、サービス及び／又はコンテンツ及びこれに関連したシグナリングデータを受信するための制御を行うことができる。
【１０７０】
インターネットインターフェースＪ２０２０は、インターネットアクセス制御モジュールを含むことができる。インターネットアクセス制御モジュールはブロードバンドチャネルを介してサービス、コンテンツ及び／又はシグナリングデータを受信する。代案で（に）、インターネットアクセス制御モジュールはサービス、コンテンツ及び／又はシグナリングデータを取得するための受信機の動作を制御できる。
【１０７１】
ブロードキャストインターフェースＪ２０３０は、物理層モジュール及び／又は物理層Ｉ／Ｆモジュールを含むことができる。物理層モジュールは、ブロードキャストチャネルを介してブロードキャスト関連信号を受信する。物理層モジュールは、ブロードキャストチャネルを介して受信されたブロードキャスト関連信号を処理（復調、デコーディングなど）する。物理層Ｉ／Ｆモジュールは、物理層モジュールから取得した情報からＩＰデータグラムを取得したり、取得されたＩＰデータグラムを用いて特定フレーム（例えば、ブロードキャストフレーム、ＲＳフレーム又はＧＳＥ）への変換を行う。
【１０７２】
シグナリングデコーダＪ２０４０は、ブロードキャストチャネルなどを介して取得されたシグナリングデータ又はシグナリング情報（以下、“シグナリングデータ”という。）をデコードする。
【１０７３】
サービスマップデータベースＪ２０５０は、受信機の他の装置（例えば、シグナリングパーサー）によって処理されたシグナリングデータ又はデコードされたシグナリングデータを記憶する。
【１０７４】
デコーダＪ２０６０は、受信機に受信されたブロードキャスト信号又はデータをデコードする。デコーダＪ２０６０は、スケジュールされたストリーミングデコーダ、ファイルデコーダ、ファイルデータベース（ＤＢ）、注文型ストリーミングデコーダ、コンポーネント同期化器、警報シグナリングパーサー、ターゲッティングシグナリングパーサー、サービスシグナリングパーサー、及び／又はアプリケーションシグナリングパーサーを含むことができる。
【１０７５】
スケジュールされたストリーミングデコーダは、ＩＰデータグラムなどから実時間オーディオ／ビデオ（Ａ／Ｖ）に対するオーディオ／ビデオデータを抽出し、抽出されたオーディオ／ビデオデータをデコードする。
【１０７６】
ファイルデコーダは、ＩＰデータグラムからＮＲＴデータ及びアプリケーションなどのファイルタイプデータを抽出し、抽出されたファイルタイプデータをデコードする。
【１０７７】
ファイルＤＢは、ファイルデコーダによって抽出されたデータを記憶する。
【１０７８】
注文型ストリーミングデコーダは、ＩＰデータグラムから注文型ストリーミングに対するオーディオ／ビデオデータなどを抽出し、抽出されたオーディオ／ビデオデータをデコードする。
【１０７９】
コンポーネント同期化器は、スケジュールされたストリーミングデコーダ、ファイルデコーダ及び／又は注文型ストリーミングデコーダによってデコードされたデータに基づいて、コンテンツを構成するエレメント間又はサービスを構成するエレメント間の同期化を取ってコンテンツ又はサービスを構成する。
【１０８０】
警報シグナリングパーサーは、ＩＰデータグラムなどからの警報と関連したシグナリング情報を抽出し、抽出されたシグナリング情報をパースする。
【１０８１】
ターゲッティングシグナリングパーサーは、ＩＰデータグラムからサービス／コンテンツ個人化又はターゲッティングに関連したシグナリング情報を抽出し、抽出されたシグナリング情報をパースする。ターゲッティング（ｔａｒｇｅｔｉｎｇ）は、特定視聴者の条件を満たすコンテンツ又はサービスを提供するアクションである。すなわち、ターゲッティングは、特定視聴者の条件を満たすコンテンツ又はサービスを識別し、識別されたコンテンツ又はサービスを視聴者に提供するアクションである。
【１０８２】
サービスシグナリングパーサーは、ＩＰデータグラムなどからサービス／コンテンツ及び／又はサービススキャンに関連したシグナリング情報を抽出し、抽出されたシグナリング情報をパースする。サービス／コンテンツに関連したシグナリング情報は、放送システム情報及び／又は放送シグナリング情報を含む。
【１０８３】
アプリケーションシグナリングパーサーは、ＩＰデータグラムなどからのアプリケーションの取得に関連したシグナリング情報を抽出し、抽出されたシグナリング情報をパースする。アプリケーションの取得に関連したシグナリング情報は、トリガー、ＴＤＯパラメータテーブル（ＴＰＴ）及び／又はＴＤＯパラメータエレメントを含むことができる。
【１０８４】
ターゲッティングプロセッサＪ２０７０は、ターゲッティングシグナリングパーサーによってパースされたサービス／コンテンツターゲッティングに関連した情報を処理する。
【１０８５】
プロセッサＪ２０８０は、受信されたデータをディスプレイする一連のプロセスを行う。
【１０８６】
プロセッサＪ２０８０は、警報プロセッサ、アプリケーションプロセッサ及び／又はＡ／Ｖプロセッサを含むことができる。
【１０８７】
警報プロセッサは、警報に関連したシグナリング情報に基づいて警報データを取得するように受信機を制御し、警報データをディスプレイするプロセスを行う。
【１０８８】
アプリケーションプロセッサは、アプリケーションに関連した情報を処理し、そのアプリケーションに関連したディスプレイパラメータ及びダウンロードされたアプリケーションの状態を処理する。
【１０８９】
Ａ／Ｖプロセッサは、デコードされたオーディオデータ、ビデオデータ及び／又はアプリケーションデータに基づいてオーディオ／ビデオレンダリングに関連した動作を行う。
【１０９０】
管理部Ｊ２０９０は、装置マネジャー、及び／又はデータ共有及び通信ユニットを含む。
【１０９１】
装置マネジャーは、接続及びデータ交換を含めて、インターロック（ｉｎｔｅｒｌｏｃｋｅｄ）され得る外部装置の追加／削除／更新などの外部装置に対する管理を行う。
【１０９２】
データ共有及び通信ユニットは、受信機及び外部装置（例えば、同伴者装置）間のデータ伝送及び交換に関連した情報を処理し、これに関連した動作を行う。伝送可能及び交換可能なデータは、シグナリングデータ、ＰＤＩテーブル、ＰＤＩユーザデータ、ＰＤＩ  Ｑ＆Ａ、及び／又はＡ／Ｖデータであってもよい。
【１０９３】
再分配モジュールＪ２１００は、受信機がブロードキャスト信号を直接受信できない場合、サービス／コンテンツ及び／又はサービス／コンテンツデータに関連した情報の取得を行う。
【１０９４】
外部管理装置Ｊ２１１０は、ブロードキャストサービス／コンテンツを提供する放送受信機の外部に設けられるブロードキャストサービス／コンテンツサーバーなどのモジュールである。外部管理装置として機能するモジュールが放送受信機に提供されてもよい。
【１０９５】
図６７は、本発明の一実施例に係る、放送網の伝送ストリームとインターネット網（異種網）の伝送ストリーム間の同期化のためのタイムラインコンポーネント（Ｔｉｍｅｌｉｎｅ  ｃｏｍｐｏｎｅｎｔ）を示す図である。
【１０９６】
前述した放送システムの受信機で、放送網及びインターネット網のような異種網を介して伝送されるストリームが、一つのサービスのために同期化して用いられる可能性がある。例えば、図示のように、放送網でビデオストリームが伝送され、インターネット網でオーディオストリームが伝送される場合、両ストリームは、一つのサービスのために同期化して復号化され、再生されなければならない。すなわち、一つのサービスを用いるために、放送網でビデオを取得し、インターネット網でオーディオを取得しなければならない。例えば、同じコンテンツに対して、放送網で提供する言語と異なる言語で製作されたオーディオで視聴したい視聴者は、自身の所望する言語で製作された、該当のコンテンツのオーディオをインターネット網で受信して用いることができる。
【１０９７】
しかし、両ストリームは別個のタイムライン（ｔｉｍｅｌｉｎｅ）を有するため、両タイムライン間のマッピングを可能にするメカニズムが必要である。ここで、タイムラインは、各伝送網を介して伝送されるデータ又はコンテンツが再生又は復号される基準となる絶対的な又は相対的な時間を示すことができる。すなわち、放送網を介して伝送されるビデオが示す内容と、インターネット網を介して伝送されるオーディオが示す内容とが、サービス内で一致する必要がある。
【１０９８】
本発明の一実施例では、放送網とインターネット網などの異種網を介して伝送されるストリーム間の同期化のためにタイムラインコンポーネントを用いる方法及び装置を提案する。タイムラインコンポーネントストリームは、一つ以上のタイムラインコンポーネントＡＵ（ａｃｃｅｓｓ  ｕｎｉｔ）を含むことができる。タイムラインコンポーネントＡＵは、タイムラインコンポーネント内で、連続して存在することができる。
【１０９９】
タイムラインコンポーネントＡＵが、放送網で伝送されるストリームのタイムラインに、インターネット網で伝送されるストリームのタイムラインをマップする例を示している。放送網で伝送されるパケットのヘッダーに、放送網で伝達されるストリームのタイムラインに関する情報が含まれている場合、放送網を介して伝送可能なタイムラインコンポーネントＡＵは、異種網（例えば、インターネット網）を介して伝送されるストリームのＤＴＳ（Ｄｅｃｏｄｉｎｇ  Ｔｉｍｅ  Ｓｔａｍｐ）、ＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｔｉｍｅ  Ｓｔａｍｐ）などのタイムスタンプ情報などを含むことができる。このような異種網（例えば、インターネット網）を介して伝送されるストリームのタイムラインに関する情報がタイムラインコンポーネントＡＵに含まれる場合、異種網（例えば、インターネット網）を介して伝送されるストリームのタイムラインに関する情報は、放送網を介して伝送されるストリームと同じパケット構造にパケット化することができる。これによって、パケットヘッダーに含まれる放送網の伝送ストリームのタイムスタンプとインターネット網を介して伝達されるストリームのタイムスタンプとを一対一でマップすることができ、両ストリームを一つのタイムラインで同期化して復号化し再生することができる。前述したタイムスタンプ情報は、外部網（例えば、異種網、インターネット網など）で伝送されるストリームのタイムラインを構成するためのタイムラインリファレンス値を意味することもできる。
【１１００】
プレゼンテーションタイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅｓｔａｍｐ；ＰＴＳ）は、視聴者に提示されるとき、プログラムの個別エレメンタリストリーム（例えば、ビデオ、オーディオ、サブタイトル）の同期化を達成するために用いられるＭＰＥＧ伝送ストリーム、ＭＰＥＧプログラムストリーム、又は類似のデータストリーム内のタイムスタンプメタデータフィールドである。ＰＴＳは、プログラムの全クロックリファレンス、プログラムクロックリファレンス（ＰＣＲ）又はシステムクロックリファレンス（ＳＣＲ）に関連した単位で与えられ、これはまた、伝送ストリーム又はプログラムストリームで送信される。
【１１０１】
デコードタイムスタンプ（Ｄｅｃｏｄｅ  Ｔｉｍｅ  Ｓｔａｍｐ；ＤＴＳ）は、アクセスユニットが受信機バッファから瞬間的に除去されてデコードされる時間を示す。これは、ピクチャレンダリングがＢピクチャに用いられる場合にのみプレゼンテーションタイムスタンプ（ＰＴＳ）と異なる。ＤＴＳが用いられると、ＰＴＳはビットストリームで提供されてもよい。
【１１０２】
前述した内容は、一つの網を介して伝送されるストリームが別個のタイムラインを使用する場合にも同様の適用が可能である。例えば、前述した方法を用いると、複数の異種網を介して伝送されるストリームを集めて視聴者に提供する中継サービス事業者は、別個のストリームに対する同期化のための再処理を直接行う必要がない。
【１１０３】
図６８は、本発明の一実施例に係るタイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。
【１１０４】
タイムラインコンポーネントＡＵは、ＸＭＬなどの他の形態のフォーマットで表現されてもよい。
【１１０５】
タイムラインコンポーネントＡＵは、識別子情報、バージョン情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報、ＰＴＳ＿ｆｌａｇ情報、ＤＴＳ＿ｆｌａｇ情報、ｍｅｄｉａ＿ｔｉｍｅ＿ｆｌａｇ情報、ＮＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報、ＰＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報、ｔｉｍｅｃｏｄｅ＿ｆｌａｇ情報、ＰＣＲ＿ｔｉｍｅ＿ｆｌａｇ情報、ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報、位置情報、タイムスケール情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報、ＮＴＰ＿ｔｉｍｅ＿ＰＴＳ情報、ＮＴＰ＿ｔｉｍｅ＿ＤＴＳ情報、ＰＴＰ＿ｔｉｍｅ＿ＰＴＳ情報、ＰＴＰ＿ｔｉｍｅ＿ＤＴＳ情報、ｔｉｍｅｃｏｄｅ＿ＰＴＳ情報、ｔｉｍｅｃｏｄｅ＿ＤＴＳ情報、ＰＣＲ＿ｔｉｍｅ＿ＰＴＳ情報、及び／又はＰＣＲ＿ｔｉｍｅ＿ＤＴＳ情報を含むことができる。
【１１０６】
識別子情報は、タイムラインコンポーネントＡＵの構造を固有に示す識別子である。
【１１０７】
バージョン情報は、下位ＰＴＳ、ＤＴＳなどのタイムスタンプフィールドの長さを示すことができる。例えば、バージョン情報の値が１であれば、６４ビット、０であれば、３２ビットの長さを有することができる。
【１１０８】
ＡＵ＿ｌｅｎｇｔｈ情報は、タイムラインコンポーネントＡＵの長さを示す。
【１１０９】
ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵが外部網を介して伝送されるストリームの位置情報を含んでいるか否かを示す。
【１１１０】
ＰＴＳ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵがＰＴＳ値を含んでいるか否かを示す。
【１１１１】
ＤＴＳ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵがＤＴＳ値を含んでいるか否かを示す。
【１１１２】
ｍｅｄｉａ＿ｔｉｍｅ＿ｆｌａｇ情報は、メディアタイム（ｍｅｄｉａ  ｔｉｍｅ）形式のタイムスタンプを含んでいるか否かを示す。
【１１１３】
ＮＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報は、ＮＴＰ形式のタイムスタンプを含んでいるか否かを示す。
【１１１４】
ＰＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報は、ＰＴＰ形式のタイムスタンプを含んでいるか否かを示す。
【１１１５】
ｔｉｍｅｃｏｄｅ＿ｆｌａｇ情報は、ＳＭＰＴＥタイムコード（ｔｉｍｅｃｏｄｅ）形式のタイムスタンプを含んでいるか否かを示す。
【１１１６】
ＰＣＲ＿ｔｉｍｅ＿ｆｌａｇ情報は、ＭＰＥＧ−２  ＴＳのＰＣＲベースのタイムスタンプを含んでいるか否かを示す。
【１１１７】
ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報は、位置フィールドの長さを示す。
【１１１８】
位置情報は、異種網で伝送されるストリームのＵＲＬ又は固有ＩＤを示す。位置情報が固有ＩＤを示す場合、シグナリングデータなどの情報と連動して用いられてもよい。
【１１１９】
タイムスケール情報は、メティアタイムスケール（ｍｅｄｉａ  ｔｉｍｅｓｃａｌｅ）を示す。タイムスケール情報は、他の情報が示す時間の単位を識別する情報である。
【１１２０】
ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報は、メディアタイム形式で表現されたＰＴＳを示す。
【１１２１】
ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報は、メディアタイム形式で表現されたＤＴＳを示す。
【１１２２】
ＮＴＰ＿ｔｉｍｅ＿ＰＴＳ情報は、ＮＰＴ形式で表現されたＰＴＳを示す。
【１１２３】
ＮＴＰ＿ｔｉｍｅ＿ＤＴＳ情報は、ＮＰＴ形式で表現されたＤＴＳを示す。
【１１２４】
ＰＴＰ＿ｔｉｍｅ＿ＰＴＳ情報は、ＰＴＰ形式で表現されたＰＴＳを示す。
【１１２５】
ＰＴＰ＿ｔｉｍｅ＿ＤＴＳ情報は、ＰＴＰ形式で表現されたＤＴＳを示す。
【１１２６】
ＰＴＰ＿ｔｉｍｅ＿ＰＴＳ又はＰＴＰ＿ｔｉｍｅ＿ＤＴＳ情報は、３２ビット、６４ビット又は８０ビットのいずれかのサイズを有することができる。
【１１２７】
ｔｉｍｅｃｏｄｅ＿ＰＴＳ情報は、ＳＭＰＴＥタイムコード形式で表現されたＰＴＳを示す。
【１１２８】
ｔｉｍｅｃｏｄｅ＿ＤＴＳ情報は、ＳＭＰＴＥタイムコード形式で表現されたＤＴＳを示す。
【１１２９】
ＰＣＲ＿ｔｉｍｅ＿ＰＴＳ情報は、ＰＣＲ形式で表現されたＰＴＳを示す。
【１１３０】
ＰＣＲ＿ｔｉｍｅ＿ＤＴＳ情報は、ＰＣＲ形式で表現されたＤＴＳを示す。
【１１３１】
本発明の一実施例によれば、受信機は、位置情報によって識別される外部網のストリームに、タイムラインコンポーネントＡＵに含まれる一つ以上のタイムスタンプ情報を適用して、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期を取ることができる。
【１１３２】
図６９は、本発明の他の実施例に係る、タイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。
【１１３３】
タイムラインコンポーネントＡＵは、ＸＭＬなどの他の形態のフォーマットで表現されてもよい。
【１１３４】
タイムラインコンポーネントＡＵは、識別子情報、バージョン情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報、ＰＴＳ＿ｆｌａｇ情報、ＤＴＳ＿ｆｌａｇ情報、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報、ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報、位置情報、タイムスケール情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＰＴＳ情報、及び／又はｔｉｍｅｓｔａｍｐ＿ｔｏ＿ＤＴＳ情報（又は、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＤＴＳ情報）を含むことができる。
【１１３５】
前述したタイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）に含まれる情報と同じ名称を有する情報に関する説明は、前述した説明に代える。
【１１３６】
ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報は、マップしようとするタイムラインのタイムスタンプ形式を示す。例えば、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報の値が０である場合には、３２ビット形式を用いることを示し、１である場合には、将来６４ビット形式を用いることを示すことができる。
【１１３７】
ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報は、マップしようとするタイムラインのタイムスタンプのタイプを示す。例えば、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報の値が、０ｘ００の場合、メディアタイムであることを示し、０ｘ０１の場合、ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）であることを示し、０ｘ０２の場合、ＰＴＰであることを示し、０ｘ０３の場合、タイムコードであることを示し、０ｘ０４−０ｘ１Ｆの場合には、将来に定義することができ、そのために予約されてもよい。
【１１３８】
タイムスケール情報は、マップしようとするタイムラインのメディアタイムを表現するタイムスケールを示すことができる。例えば、ＭＰＥＧ−２  ＴＳの場合、タイムスケールは９０Ｋ値を有することができる。
【１１３９】
ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報は、マップしようとするタイムラインのプレゼンテーションタイムスタンプ、すなわち、再生する時点に対するメディアタイムを示すことができる。ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報は、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇの値が０である場合、３２ビット形式で示し、当該値が１である場合、６４ビットで示すことができる。
【１１４０】
ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報は、マップしようとするタイムラインのデコーディングタイムスタンプ、すなわち、デコードする時点に対するメディアタイムを示すことができる。ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報は、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇの値が０である場合には、３２ビットの形式で示し、当該値が１である場合には、６４ビットで示すことができる。
【１１４１】
ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＰＴＳ情報は、マップしようとするタイムラインのタイムスタンプタイプによるプレゼンテーションタイムスタンプ、すなわち、再生する時点を示すことができる。ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＰＴＳ情報は、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇの値が０である場合、３２ビットの形式で示し、当該値が１である場合、６４ビットで示すことができる。例えば、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドの値がＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）を示す場合、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＰＴＳフィールド値は、ＮＴＰベース再生時点に対するタイムスタンプ値を有することができる。
【１１４２】
ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＤＴＳ情報は、マップしようとするタイムラインのタイムスタンプタイプによるデコーディングタイムスタンプ、すなわち、デコードする時点を示すことができる。ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＤＴＳ情報は、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ値が０である場合、３２ビットの形式で示し、当該値が１である場合、６４ビットで示すことができる。例えば、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドの値がＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）を示す場合、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ＿ＰＴＳフィールド値は、ＮＴＰベースデコーディング時点に対するタイムスタンプ値を有することができる。
【１１４３】
図７０は、本発明の一実施例に係る、放送網の伝送パケットのタイムスタンプがない場合に、タイムラインコンポーネントを用いて、放送網で伝送されるストリームと、異種網（例えばインターネット網）で伝送されるストリームとの同期を取る方法を示す図である。
【１１４４】
前述したタイムラインコンポーネントを用いる、異種網を介して伝送される伝送ストリーム間のタイムライン共有を通じた同期化方法において、タイムライン共有は、放送網の伝送ストリームのパケットヘッダーのタイムスタンプと、パケットペイロードのタイムラインコンポーネントＡＵに含まれるインターネット網の伝送ストリームのタイムスタンプとを一対一マップすることによって行うことができる。
【１１４５】
しかしながら、放送網伝送パケットのヘッダーにタイムスタンプ関連情報が存在しない場合がありうる。
【１１４６】
同図のように、伝送パケットのヘッダーにタイムスタンプと関連した情報が存在しない場合、タイムラインにおける根源（ｏｒｉｇｉｎ）タイムスタンプに関する追加情報が必要である。放送網とインターネット網とのタイムライン共有は、根源タイムスタンプと前述したインターネット網伝送ストリームのタイムスタンプとを一対一マップすることによって達成することができる。
【１１４７】
根源(origin)タイムスタンプと異種網（例えば、インターネット網）の伝送ストリームのタイムスタンプ関連情報は、タイムラインコンポーネントＡＵに含めることができる。
【１１４８】
根源タイムスタンプは、基準となるタイムライン上のタイムスタンプと定義することができる。例えば、前述した実施例で、放送網で伝送されるストリームに対するタイムスタンプを根源タイムスタンプと定義することができる。
【１１４９】
根源タイムスタンプは、内部網（例えば、放送網）で伝送されるストリームのタイムラインを構成するためのタイムラインリファレンス値を意味することもできる。
【１１５０】
図７１は、本発明の他の実施例に係るタイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。
【１１５１】
本発明の他の実施例に係るタイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）は、前述したタイムラインコンポーネントＡＵのシンタクスに、根源タイムスタンプに関連した情報をさらに含むことができる。
【１１５２】
タイムラインコンポーネントＡＵは、識別子情報、バージョン情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報、ｏｒｉｇｉｎ＿ＰＴＳ＿ｆｌａｇ情報、ｏｒｉｇｉｎ＿ＤＴＳ＿ｆｌａｇ情報、ｏｒｉｇｉｎ＿ＰＴＳ情報、ｏｒｉｇｉｎ＿ＤＴＳ情報、ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報、ＰＴＳ＿ｆｌａｇ情報、ＤＴＳ＿ｆｌａｇ情報、ｍｅｄｉａ＿ｔｉｍｅ＿ｆｌａｇ情報、ＮＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報、ＰＴＰ＿ｔｉｍｅ＿ｆｌａｇ情報、ｔｉｍｅｃｏｄｅ＿ｆｌａｇ情報、ＰＣＲ＿ｔｉｍｅ＿ｆｌａｇ情報、ｌｏｃａｔｉｏｎ＿ＵＲＬ＿ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ＿ＵＲＬ情報、タイムスケール情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＰＴＳ情報、ｍｅｄｉａ＿ｔｉｍｅ＿ＤＴＳ情報、ＮＴＰ＿ｔｉｍｅ＿ＰＴＳ情報、ＮＴＰ＿ｔｉｍｅ＿ＤＴＳ情報、ＰＴＰ＿ｔｉｍｅ＿ＰＴＳ情報、ＰＴＰ＿ｔｉｍｅ＿ＤＴＳ情報、ｔｉｍｅｃｏｄｅ＿ＰＴＳ情報、ｔｉｍｅｃｏｄｅ＿ＤＴＳ情報、ＰＣＲ＿ｔｉｍｅ＿ＰＴＳ情報、及び／又はＰＣＲ＿ｔｉｍｅ＿ＤＴＳ情報を含むことができる。
【１１５３】
前述したタイムラインコンポーネントＡＵのシンタクスに含まれる情報と同じ名称を有する情報に関する説明は、前述した説明に代える。
【１１５４】
ｏｒｉｇｉｎ＿ＰＴＳ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵがｏｒｉｇｉｎ＿ＰＴＳ値を含んでいるか否かを示す。
【１１５５】
ｏｒｉｇｉｎ＿ＤＴＳ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵが根源ＤＴＳ値を含んでいるか否かを示す。
【１１５６】
ｏｒｉｇｉｎ＿ＰＴＳ情報は、タイムラインマッピングの基準となるベースタイムライン上で現在パケットのＰＴＳを示す。
【１１５７】
ｏｒｉｇｉｎ＿ＤＴＳ情報は、タイムラインマッピングの基準となるベースタイムライン上で現在パケットのＤＴＳを示す。
【１１５８】
ｌｏｃａｔｉｏｎ＿ＵＲＬ＿ｌｅｎｇｔｈ情報は、ｌｏｃａｔｉｏｎ＿ＵＲＬ情報の長さを示す。
【１１５９】
ｌｏｃａｔｉｏｎ＿ＵＲＬ情報は、異種網を介して伝送されるストリームのＵＲＬを示すか、又は、異種網を介して伝送されるストリームを固有に識別する識別子を示すことができる。
【１１６０】
受信機は、放送網の伝送ストリームのパケットペイロードからタイムラインコンポーネントＡＵを取得し、タイムラインコンポーネントＡＵでｏｒｉｇｉｎ＿ＰＴＳ情報及び／又はｏｒｉｇｉｎ＿ＤＴＳ情報をパーシングし、それらの情報に基づいて、放送網の伝送ストリームに対するタイムスタンプ情報を得ることができる。受信機は、ｏｒｉｇｉｎ＿ＰＴＳ情報及び／又はｏｒｉｇｉｎ＿ＤＴＳ情報を通じて取得した放送網の伝送ストリームのタイムスタンプとタイムラインコンポーネントＡＵに含まれる異種網に対するタイムスタンプ関連情報を用いて、放送網の伝送ストリームと異種網の伝送ストリームとの同期を取ることができる。
【１１６１】
図７２は、本発明の他の実施例に係るタイムラインコンポーネントＡＵのシンタクスを示す図である。
【１１６２】
同図では、タイムラインコンポーネントＡＵは、放送網或いはインターネット網で伝送されるメディアストリームに関連した追加のメタデータを含むことができる。このようなメタデータのうち、メディアストリーム及び関連タイムラインに対するメタデータを含むタイムラインコンポーネントＡＵを示している。
【１１６３】
タイムラインコンポーネントＡＵは、ＸＭＬなどの他の形態のフォーマットで表現されてもよい。
【１１６４】
タイムラインコンポーネントＡＵは、識別子情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｌａｇ情報、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ情報、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報、ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔ情報、ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報、位置情報、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ情報、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔ情報、ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報、ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報、ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ情報、ｏｒｉｇｉｎ＿ｔｉｍｅｓｃａｌｅ情報、ｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅ情報、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ情報、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈ情報、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅｓ（）情報、タイムスケール情報、ｍｅｄｉａ＿ｔｉｍｅ情報、タイムスタンプ情報、及び／又はｄａｔａ＿ｂｙｔｅｓ（）情報を含むことができる。
【１１６５】
前述したタイムラインコンポーネントＡＵのシンタクスに含まれる情報と同じ名称を有する情報に関する説明は、前述した説明に代える。
【１１６６】
識別子情報は、タイムラインに関連したメタデータであることを示す識別子、或いはタイムラインコンポーネントアクセスユニット（ＡＵ）構造を含んでいることを示す識別子であってもよい。
【１１６７】
ＡＵ＿ｌｅｎｇｔｈ情報は、タイムラインコンポーネントＡＵが含む情報の長さを示すことができる。
【１１６８】
ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報は、タイムラインコンポーネントＡＵが含む情報に関連したサービス及びコンテンツコンポーネントなどに対する位置情報を含んでいるか否かを示すことができる。
【１１６９】
ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｌａｇ情報は、根源タイムスタンプに関連した情報を含むか否かを示すことができる。
【１１７０】
ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ情報は、タイムラインコンポーネントＡＵが含むタイムスタンプのバージョン情報を示すことができる。
【１１７１】
ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報は、タイムラインコンポーネントＡＵが含むタイムスタンプのタイプを示すことができる。例えば、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報の値が０ｘ００である場合、関連したサービス／コンテンツコンポーネントのアクセスユニットなどのデータ（例えば、オーディオアクセスユニット）のデコーディング時点を示すデコーディングタイムスタンプ（ＤＴＳ）を示すことができ、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報の値が０ｘ０１である場合、関連したサービス／コンテンツコンポーネントなどのアクセスユニットなどのデータ（例えば、オーディオアクセスユニット）の再生時点を示すプレゼンテーションタイムスタンプ（ＰＴＳ）を示すことができる。
【１１７２】
ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔ情報は、タイムラインコンポーネントＡＵが含むタイムスタンプのフォーマットを示すことができる。例えば、ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔ情報の値が０ｘ００であれば、メディアタイムであることを示し、０ｘ０１の場合、ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、ｔｉｍｅｃｏｄｅであることを示すことができ、将来の拡張のために０ｘ０４−０ｘ０Ｆの値を予約することができる。
【１１７３】
ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報は、位置フィールドに対する長さを示すことができる。
【１１７４】
位置情報は、タイムラインコンポーネントＡＵが含む情報に関連したサービス及びコンテンツコンポーネントなどに対する位置情報を示すことができる。位置情報は、ＩＰアドレス／ポートナンバー、或いはＵＲＩなどの形態で示すことができる。
【１１７５】
ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ情報は、タイムラインマッピングの基準となり得るベースタイムラインに対するタイムスタンプフォーマットのバージョンを示すことができる。当該フィールド値が０である場合、３２ビットフォーマットの形式を用いていることを示し、１である場合には、６４ビットフォーマットの形式を用いていることを示すことができる。例えば、ビデオストリームが放送網を介して伝達され、オーディオストリームがインターネット網を介して伝送される場合、ビデオストリームにオーディオストリームのタイムラインマップする時に基準となるベースタイムラインは、放送網で伝達されるビデオストリームのタイムスタンプとすることができる。この場合、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎは、放送網で伝送されるビデオストリームに対するタイムスタンプ形式を示すことができる。
【１１７６】
ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報は、タイムラインマッピングの基準となり得るベースタイムラインに対するタイムスタンプのタイプを示すことができる。例えば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報の値が０ｘ００である場合、ベースタイムラインに関連したサービス／コンテンツコンポーネントなどのアクセスユニットなどのデータ（例えば、オーディオアクセスユニット）のデコーディング時点を示すデコーディングタイムスタンプ（ＤＴＳ）を示すことができ、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅ情報の値が０ｘ０１である場合、ベースタイムラインに関連したサービス／コンテンツコンポーネントなどのアクセスユニットなどのデータ（例えば、オーディオアクセスユニット）の再生時点を示すプレゼンテーションタイムスタンプ（ＰＴＳ）を示すことができる。
【１１７７】
ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔ情報は、タイムラインマッピングの基準となり得るベースタイムラインに対するタイムスタンプのフォーマットを示すことができる。例えば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔ情報の値が０ｘ００であれば、メディアタイムであることを示し、０ｘ０１であれば、ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、ｔｉｍｅｃｏｄｅであることを示すことができ、０ｘ０４−０ｘ０Ｆの値は、将来の拡張のために予約されてもよい。
【１１７８】
ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報は、タイムラインマッピングの基準となり得るベースタイムラインに関連したサービス及びコンテンツコンポーネントなどに対する位置情報を含んでいるか否かを示すことができる。
【１１７９】
ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈ情報は、ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎフィールドに対する長さを示すことができる。
【１１８０】
ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ情報は、タイムラインマッピングの基準となり得るベースタイムラインに関連したサービス及びコンテンツコンポーネントなどに対する位置情報を示すことができる。ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ情報は、ＩＰアドレス／ポートナンバー、或いはＵＲＩなどの形態で示すことができる。
【１１８１】
ｏｒｉｇｉｎ＿ｔｉｍｅｓｃａｌｅ情報は、タイムラインマッピングの基準となるベースタイムラインのメディアタイムの表現時に使用できるタイムスケール（ｔｉｍｅ  ｓｃａｌｅ）を示すことができる。例えば、ＭＰＥＧ−２  ＴＳの場合、タイムスケールは９０Ｋ値を有することができる。
【１１８２】
ｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅ情報は、タイムラインマッピングの基準となるベースタイムライン上でメディアタイムを示すことができる。ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅによって該当のメディアタイムの意味する内容が異なってもよい。例えば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅがＰＴＳである場合、ｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅ情報は、再生時点に対するメディアタイムを示すことができ、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅがＤＴＳである場合、ｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅ情報は、デコーディング時点に対するメディアタイムを示すことができる。ｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅ情報は、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ値が０である場合、３２ビットで示すことができ、当該フィールド値が１である場合、６４ビットで示すことができる。
【１１８３】
ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ情報は、タイムラインマッピングの基準となるベースタイムライン上でｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔのフィールド値によって別々のフォーマットのタイムスタンプを示すことができ、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅによって、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ情報に該当するタイムスタンプの意味が異なってもよい。例えば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅがＤＴＳを示し、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔの値が‘０ｘ０１’である場合、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ情報の該当のタイムスタンプは、ＮＴＰで表現されたデコーディング時点を示すことができる。ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ情報は、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ値が０である場合、３２ビットで示し、当該フィールド値が１である場合、６４ビットで示すことができる。
【１１８４】
ｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈ情報は、後続するｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅｓのバイト単位の長さを示すことができる。
【１１８５】
ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅｓ（）情報は、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈ長さだけ私的に（ｐｒｉｖａｔｅｌｙ）定義したり、将来に拡張内容を含み得る領域を示す。
【１１８６】
タイムスケール情報は、メディアタイム表現時に使用できるタイムスケールを示すことができる。
【１１８７】
ｍｅｄｉａ＿ｔｉｍｅ情報は、メディアタイムを示すことができる。ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅによって、ｍｅｄｉａ＿ｔｉｍｅ情報に該当するメディアタイムの意味する内容が異なってもよい。例えば、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅがＰＴＳである場合、ｍｅｄｉａ＿ｔｉｍｅ情報は、再生時点に対するメディアタイムを示すことができる。ｍｅｄｉａ＿ｔｉｍｅ情報は、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ値が０である場合、３２ビットで示し、当該フィールド値が１である場合、６４ビットで示すことができる。
【１１８８】
タイムスタンプ情報は、ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔのフィールド値によって別々のフォーマットのタイムスタンプを示すことができ、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅによって、タイムスタンプ情報に該当するタイムスタンプの意味が異なってもよい。例えば、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅがＤＴＳを示し、ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔの値が‘０ｘ０１’である場合、タイムスタンプ情報に該当するタイムスタンプは、ＮＴＰで表現されたデコーディング時点を示すことができる。タイムスタンプ情報は、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎ値が０である場合、３２ビットで示し、当該フィールド値が１である場合、６４ビットで示すことができる。
【１１８９】
ｄａｔａ＿ｂｙｔｅｓ（）情報は、将来に拡張内容を含むフィールド又は領域を示す。
【１１９０】
図７３は、本発明の他の実施例に係る、タイムラインリファレンスシグナリング情報を用いて、放送網を介して伝送されるストリームと異種網を介して伝送されるストリーム間の同期を取る方法を示す図である。
【１１９１】
前述したように、放送網でビデオストリームが伝送され、インターネット網でオーディオストリームが伝送される場合、両ストリームは一つのサービスのために同期化し、復号及び／又は再生されなければならない。しかし、両ストリームは別個のタイムラインを有するので、両タイムライン間のマッピング（ｍａｐｐｉｎｇ）が可能なメカニズムが必要である。
【１１９２】
本発明の他の実施例は、タイムラインリファレンスシグナリング情報を用いて、放送網とインターネット網などの異種網で伝送される少なくとも一つのストリームを同期化することができる。すなわち、前述した放送システムの受信機が、放送網とインターネット網などの異種網で伝送されるストリームを一つのサービスのために同期化して用いることができる。
【１１９３】
本発明の他の実施例に係る送信機は、タイムラインリファレンスシグナリング情報を用いて、放送網で伝送されるストリームと異種網で伝送されるストリームを同期化させ得る情報を伝送することができる。そのために、本発明の他の実施例に係る送信機は、シグナリングエンコーダ（ｓｉｇｎａｌｉｎｇ  ｅｎｃｏｄｅｒ）（図示せず）、放送網インターフェース（ｂｒｏａｄｃａｓｔ  ｎｅｔｗｏｒｋ  ｉｎｔｅｒｆａｃｅ）（図示せず）、及び／又は異種網インターフェース（ｈｅｔｅｒｏｇｅｎｅｉｔｙ  ｎｅｔｗｏｒｋ  ｉｎｔｅｒｆａｃｅ）（図示せず）を含むことができる。
【１１９４】
シグナリングエンコーダは、少なくとも一つの網を介して伝送されるストリームを同期化するためのメタデータを含むタイムラインリファレンスシグナリング情報をエンコードする。
【１１９５】
シグナリングエンコーダは、放送コンテンツの第１部分（例えば、ビデオ情報）及びタイムラインリファレンスシグナリング情報を含む放送ストリーム（ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍ）をエンコードする第１エンコーダ、及び放送コンテンツの第２部分（例えば、オーディオ情報）を含む異種ストリーム（ｈｅｔｅｒｏｇｅｎｅｉｔｙ  ｓｔｒｅａｍ）をエンコードする第２エンコーダを含むことができる。
【１１９６】
タイムラインリファレンスシグナリング情報は、放送ストリーム及び異種ストリームのうち少なくとも一つのタイムライン（ｔｉｍｅｌｉｎｅ）を構成する（ｃｏｎｓｔｉｔｕｔｉｎｇ）少なくとも一つのタイムラインリファレンス情報を含むことができる。
【１１９７】
放送網インターフェースは、エンコードされた放送ストリームを放送網で伝送することができる。
【１１９８】
異種網インターフェースは、エンコードされた異種ストリームを異種網で伝送することができる。
【１１９９】
また、本発明の他の実施例に係る受信機は、タイムラインリファレンスシグナリング情報を用いて、放送網で伝送されるストリームと異種網で伝送されるストリームとを同期化させることができる。そのために、本発明の他の実施例に係る受信機は、放送網インターフェース（ｂｒｏａｄｃａｓｔ  ｎｅｔｗｏｒｋ  ｉｎｔｅｒｆａｃｅ）（図示せず）、異種網インターフェース（ｈｅｔｅｒｏｇｅｎｅｉｔｙ  ｎｅｔｗｏｒｋ  ｉｎｔｅｒｆａｃｅ）（図示せず）、及び／又はプロセッサ（ｐｒｏｃｅｓｓｏｒ）（図示せず）を含むことができる。
【１２００】
放送網インターフェースは、放送コンテンツの第１部分（例えば、ビデオ情報）を含む放送ストリームを放送網で受信することができる。放送網インターフェースは、前述したブロードキャストインターフェースＪ２０３０及び／又は伝送パケットインターフェース（Ｔｒａｎｓｐｏｒｔ  Ｐａｃｋｅｔ  Ｉｎｔｅｒｆａｃｅ）Ｊ３２０７０を含むことができる。
【１２０１】
異種網インターフェースは、放送コンテンツの第２部分（例えば、オーディオ情報）を含む異種ストリームを異種網で受信することができる。異種網インターフェースは、前述したインターネットインターフェースＪ２０２０及び／又はブロードバンドパケットインターフェース（Ｂｒｏａｄｂａｎｄ  Ｐａｃｋｅｔ  Ｉｎｔｅｒｆａｃｅ）Ｊ３２０８０を含むことができる。
【１２０２】
放送ストリームは、少なくとも一つの網（ｎｅｔｗｏｒｋ）で伝送されるストリームを同期化するためのメタデータを含むタイムラインリファレンスシグナリング情報を含むことができる。タイムラインリファレンスシグナリング情報は、放送ストリーム及び異種ストリームのうち少なくとも一つのタイムラインを構成する少なくとも一つのタイムラインリファレンス情報を含むことができる。
【１２０３】
プロセッサは、タイムラインリファレンスシグナリング情報に基づいて、放送ストリーム及び異種ストリームを用いて放送コンテンツを形成（ｃｏｎｆｉｇｕｒｉｎｇ）することができる。プロセッサは、前述したプロセッサＪ２０８０及び／又はＡ／ＶプロセッサＪ３２１１０を含むことができる。
【１２０４】
本発明の他の実施例に係る放送ストリームは、パケットヘッダー及び／又はパケットペイロードを含むことができる。パケットヘッダーは、放送ストリームのためのタイムスタンプを含むことができる。パケットペイロードは、タイムラインリファレンスシグナリング情報を含むことができる。ただし、これに限定されず、タイムラインリファレンスシグナリング情報はパケットヘッダーにも含まれてもよい。
【１２０５】
タイムラインリファレンスシグナリング情報がパケットペイロードに含まれて伝送される場合、タイムラインリファレンスシグナリング情報は、タイムラインリファレンス情報ＡＵ（ａｃｃｅｓｓ  ｕｎｉｔ）に含まれてもよい。タイムラインコンポーネントＡＵは、タイムラインリファレンス情報ＡＵを含むことができる。ただし、これに限定されず、タイムラインリファレンス情報ＡＵは、タイムラインコンポーネントＡＵと独立して存在してもよい。
【１２０６】
タイムラインリファレンスシグナリング情報がパケットヘッダーに含まれて伝送される場合、タイムラインリファレンスシグナリング情報は、拡張されたヘッダー拡張に含まれてもよい。
【１２０７】
放送網で伝送されるタイムラインコンポーネントＡＵ及び／又はタイムラインリファレンス情報ＡＵは、内部網である放送網で伝送されるストリームのタイムラインを構成する内部タイムラインリファレンス情報、及び／又は外部網である異種網（例えば、インターネット網）で伝送されるストリームのタイムラインを内部網とマップさせ得る外部タイムラインリファレンス情報を含むことができる。
【１２０８】
前述したタイムスタンプは、ＤＴＳ及び／又はＰＴＳのように、デコーディングを始める時間及び／又はプレゼンテーションを始める時間を意味する。したがって、前述したタイムスタンプは、デコーディングタイム及びプレゼンテーションタイムのように特定のイベントが起きる時点だけを示す。
【１２０９】
ただし、本発明の他の実施例に係るタイムラインリファレンス情報は、内部網及び／又は外部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。このとき、リファレンスクロック値は、メディアストリームのタイムラインを構成する時点を示す時刻情報を意味する。ここで、タイムラインを構成する時点は、放送システム内であらかじめ定められた時点に該当してもよい。例えば、リファレンスクロック値は、ＤＴＳ、ＰＴＳなどのタイムスタンプ（ｔｉｍｅｓｔａｍｐ）情報及び／又はウォールクロック（ｗａｌｌ  ｃｌｏｃｋ）などを含むことができる。ただし、リファレンスクロック値は必ずしもＤＴＳ及び／又はＰＴＳに限定されない。
【１２１０】
また、タイムラインリファレンス情報ＡＵは、放送網伝送ストリームと同じパケット構造でパケット化されてもよい。
【１２１１】
本発明の他の実施例によれば、受信機は、タイムラインリファレンス情報ＡＵに基づいて、放送網と異種網（例えば、インターネット網）で伝送される両ストリームを一つのタイムラインで同期化して復号化及び／又は再生することができる。例えば、受信機及び／又はプロセッサは、タイムスタンプ及び／又はタイムラインリファレンスシグナリング情報に基づいて、放送ストリームと異種ストリームを用いて放送コンテンツを構成することができる。受信機及び／又はプロセッサは、内部タイムラインリファレンス情報と外部タイムラインリファレンス情報に基づいて、放送網で伝送されるストリームと異種網で伝送されるストリームをマップすることができる。外部タイムラインリファレンス情報がＤＴＳ及び／又はＰＴＳなどのタイムスタンプ情報を含む場合には、受信機及び／又はプロセッサは、外部タイムラインリファレンス情報と内部網で伝送されるメディアストリームのタイムラインを構成するタイムスタンプ情報に基づいて、放送網で伝送されるストリームと異種網で伝送されるストリームをマップすることができる。
【１２１２】
前述した内容は、一つの網で伝送されるストリームが別個のタイムラインを使用する場合にも同様に適用することができる。例えば、異種ストリームが放送ストリームに該当する場合、異種ストリームのタイムラインは放送ストリームのタイムラインと異なってもよい。
【１２１３】
前述した方法によれば、複数の異種網で伝送されるストリームを集めて視聴者に提供する中継サービスプロバイダは、別個のストリームを同期化するための再処理を直接行う必要がない。
【１２１４】
図７４は、本発明の他の実施例に係る、タイムラインリファレンス情報ＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。
【１２１５】
タイムラインリファレンス情報ＡＵは、ＸＭＬなどの他の形態のフォーマットで表現されてもよい。タイムラインリファレンス情報ＡＵは、ＲＰＴ、ＡＬＣ／ＬＣＴなどの様々なメディア伝送プロトコルに適用することができ、プロトコルに適したサービスシグナリング情報と連動して用いることができる。
【１２１６】
サービスシグナリング情報は、当該ストリームが内部網又は外部網のタイムラインリファレンスを伝送していることを示す情報、タイムラインリファレンス情報ＡＵに含まれる外部メディアＵＲＬ情報、各種のフィールドを含むか否かを示すフラグ情報、及び／又はタイムスケール情報など、各パケットに共通して適用可能な情報を含むことができる。
【１２１７】
具体的には、タイムラインリファレンス情報ＡＵは、ＡＵ＿ｉｄｅｎｔｉｆｉｅｒ情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報、及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を含むことができる。タイムラインリファレンス情報ＡＵが含む情報を、タイムラインリファレンスシグナリング情報と呼ぶことができる。
【１２１８】
前述したタイムラインコンポーネントＡＵのシンタクス（Ｓｙｎｔａｘ）に含まれる情報と同じ名称を有する情報に関する説明は、前述した説明に代えるものとする。
【１２１９】
ＡＵ＿ｉｄｅｎｔｉｆｉｅｒ情報は、タイムラインリファレンス情報ＡＵの構造を固有に示す識別子である。
【１２２０】
ＡＵ＿ｌｅｎｇｔｈ情報は、タイムラインリファレンス情報ＡＵの長さを示す。
【１２２１】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが外部網（例えば、インターネット網）で伝送されるストリームのＵＲＬ情報を含んでいるか否かを示す。
【１２２２】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが内部タイムラインリファレンス情報を含んでいるか否かを示す。
【１２２３】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが外部タイムラインリファレンス情報を含んでいるか否かを示す。
【１２２４】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈ情報は、外部メディアＵＲＬ情報の長さを示す。例えば、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈ情報は、外部メディアＵＲＬ情報の長さをバイト単位で示すことができる。
【１２２５】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報は、外部網（例えば、インターネット網）で伝送されるメディアの位置情報、及び／又は固有識別子（識別情報）などの情報を含むことができる。例えば、外部網で伝送されるメディアがＭＰＥＧ−ＤＡＳＨである場合、当該ＭＰＤのＵＲＬ、及び／又はＭＰＤ  ｉｄなどの情報を含むことができる。
【１２２６】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報は、内部タイムラインリファレンスのフォーマットを示すことができる。例えば、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報の値が０ｘ００であれば、メディアタイムであることを示し、０ｘ０１であれば、ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、タイムコードであることを示し、０ｘ０４−０ｘ１Ｆであれば、将来に定義すればよく、そのために予約されてもよい。
【１２２７】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが内部タイムラインリファレンスに対するタイムスケールを含んでいるか否かを示す。
【１２２８】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、内部タイムラインリファレンス値の長さを示す。例えば、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、内部タイムラインリファレンス値の長さをバイト単位（ｂｙｔｅｓ）で示すことができる。
【１２２９】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、内部タイムラインリファレンス情報の時間単位を示す。例えば、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、内部タイムラインリファレンス値の時間単位をヘルツ（Ｈｚ）単位で示すことができる。
【１２３０】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、内部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。
【１２３１】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報は、外部タイムラインリファレンスのフォーマットを示すことができる。例えば、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報の値が、０ｘ００であれば、メディアタイムであることを示し、０ｘ０１であれば、ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、タイムコードであることを示し、０ｘ０４−０ｘ１Ｆであれば、将来に定義すればよく、そのために予約されてもよい。
【１２３２】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが外部タイムラインリファレンスに対するタイムスケールを含んでいるか否かを示す。
【１２３３】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、外部タイムラインリファレンス値の長さを示す。例えば、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、外部タイムラインリファレンス値の長さをバイト単位（ｂｙｔｅｓ）で示すことができる。
【１２３４】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、外部タイムラインリファレンス情報の時間単位を示す。例えば、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、外部タイムラインリファレンス値の時間単位をヘルツ（Ｈｚ）単位で示すことができる。
【１２３５】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、外部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。
【１２３６】
本発明の他の実施例によれば、受信機及び／又はプロセッサは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報によって識別される外部網のストリームに、タイムラインコンポーネントＡＵ及び／又はタイムラインリファレンス情報ＡＵに含まれるｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を適用し、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期化を取ることができる。また、受信機及び／又はプロセッサは、外部メディアＵＲＬ情報、タイムラインリファレンス情報、及び／又はタイムスタンプに基づいて、放送ストリームと異種ストリームを用いて放送コンテンツを構成することができる。
【１２３７】
図７５は、本発明の他の実施例に係る、タイムラインリファレンス情報ＡＵのシンタクス（Ｓｙｎｔａｘ）を示す図である。
【１２３８】
本発明の他の実施例に係るタイムラインリファレンス情報ＡＵは、少なくとも一つの（又は複数の）ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を含むことができる。また、本発明の他の実施例に係るタイムラインリファレンス情報ＡＵは、少なくとも一つの（又は複数の）ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を含むことができる。
【１２３９】
具体的には、タイムラインリファレンス情報ＡＵは、ＡＵ＿ｉｄｅｎｔｉｆｉｅｒ情報、ＡＵ＿ｌｅｎｇｔｈ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇ情報、ｎｂ＿ｏｆ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈ情報、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｉｄｅｎｔｉｆｉｅｒ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報、及び／又はｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を含むことができる。タイムラインリファレンス情報ＡＵが含む情報をタイムラインリファレンスシグナリング情報と呼ぶことができる。
【１２４０】
前述したタイムラインリファレンス情報ＡＵのシンタクス（Ｓｙｎｔａｘ）に含まれる情報と同じ名称を有する情報に関する説明は、前述した説明に代えるものとする。
【１２４１】
ＡＵ＿ｉｄｅｎｔｉｆｉｅｒ情報は、タイムラインリファレンス情報ＡＵの構造を固有に示す識別子である。
【１２４２】
ＡＵ＿ｌｅｎｇｔｈ情報は、タイムラインリファレンス情報ＡＵの長さを示す。
【１２４３】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが外部網（例えば、インターネット網）で伝送されるストリームのＵＲＬ情報を含んでいるか否かを示す。
【１２４４】
ｎｂ＿ｏｆ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、タイムラインリファレンス情報ＡＵに含まれたタイムラインリファレンス情報の個数を示す。
【１２４５】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈ情報は、外部メディアＵＲＬ情報の長さを示す。例えば、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈ情報は、外部メディアＵＲＬ情報の長さをバイト単位で示すことができる。
【１２４６】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報は、外部網（例えば、インターネット網）で伝送されるメディアの位置情報、及び／又は固有識別子などの情報を含むことができる。例えば、外部網で伝送されるメディアがＭＰＥＧ−ＤＡＳＨである場合、当該ＭＰＤのＵＲＬ、及び／又はＭＰＤ  ｉｄなどの情報を含むことができる。
【１２４７】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ情報は、タイムラインリファレンス情報のタイプを示す。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ情報が‘０’であれば、タイムラインリファレンス情報のタイプは内部タイムラインリファレンス情報を示すことができる。また、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ情報が‘１’であれば、タイムラインリファレンス情報のタイプは外部タイムラインリファレンス情報を示すことができる。
【１２４８】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｉｄｅｎｔｉｆｉｅｒ情報は、タイムラインリファレンス情報の固有識別子である。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｉｄｅｎｔｉｆｉｅｒ情報は０〜１２７の整数値で割り当てられてもよい。
【１２４９】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報は、内部タイムラインリファレンス情報のフォーマット及び／又は外部タイムラインリファレンス情報のフォーマットを示すことができる。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報の値が０ｘ００である場合、フォーマットは、メディアタイムであることを示し、０ｘ０１である場合、フォーマットはＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）であることを示し、０ｘ０２である場合、フォーマットはＰＴＰであることを示し、０ｘ０３である場合、フォーマットはタイムコードであることを示し、０ｘ０４−０ｘ１Ｆである場合、フォーマットは将来に定義すればよく、そのために予約されてもよい。
【１２５０】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報は、タイムラインリファレンス情報ＡＵが内部タイムラインリファレンス情報及び／又は外部タイムラインリファレンス情報に対するタイムスケール情報を含んでいるか否かを示す。
【１２５１】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、内部タイムラインリファレンス値の長さ及び／又は外部タイムラインリファレンス値の長さを示す。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈ情報は、内部タイムラインリファレンス値の長さ及び／又は外部タイムラインリファレンス値の長さをバイト単位（ｂｙｔｅｓ）で示すことができる。
【１２５２】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、内部タイムラインリファレンス値の時間単位及び／又は外部タイムラインリファレンス値の時間単位を示す。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、内部タイムラインリファレンス値の時間単位及び／又は外部タイムラインリファレンス値の時間単位をヘルツ（Ｈｚ）単位で示すことができる。
【１２５３】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、内部網及び／又は外部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。例えば、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、ｎｂ＿ｏｆ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報に基づいて少なくとも一つの値（又は、複数の値）を有することができる。ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報は、前述した少なくとも一つのｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報及び／又は少なくとも一つのｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を含むことができる。
【１２５４】
本発明の他の実施例によれば、受信機は、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報によって識別される外部網のストリームに、タイムラインコンポーネントＡＵ及び／又はタイムラインリファレンス情報ＡＵに含まれる少なくとも一つのｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を適用して、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期化を取ることができる。具体的に、受信機は、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報によって識別される外部網のストリームに、タイムラインコンポーネントＡＵ及び／又はタイムラインリファレンス情報ＡＵに含まれる少なくとも一つの（又は複数の）ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報及び／又は少なくとも一つの（又は複数の）ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を適用して、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期化を取ることができる。
【１２５５】
図７６は、本発明の他の実施例に係る、タイムラインリファレンス情報伝送を支援するＬＣＴパケットの構造を示す図である。
【１２５６】
本発明の他の実施例に係る放送ストリームは、ＬＣＴパケットを含むことができる。本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、拡張されたヘッダー拡張に含まれて伝送されてもよい。例えば、本発明の他の実施例に係るＬＣＴパケットは、既存のヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）を拡張してタイムラインリファレンスシグナリング情報をさらに含むことができる。本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、異種網で伝送されるそれぞれのメディアストリームの同期化のための情報である。本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、前述したタイムラインリファレンス情報ＡＵと同一及び／又は類似の情報を含むことができる。前述したタイムラインリファレンスシグナリング情報は、ＲＴＰ（ｒｅａｌｔｉｍｅ  ｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用されてもよい。
【１２５７】
本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、前述したプロトコルに適合したサービスシグナリング情報と連動して動作することができる。サービスシグナリング情報は、当該ストリームが内部網及び／又は外部網のタイムラインリファレンスを伝送していることを示す情報、タイムラインリファレンス情報ＡＵに含まれる外部メディアＵＲＬ情報、フラグ情報、及び／又はタイムスケール情報などを含めて、各パケットに共通して適用可能な情報を含むことができる。
【１２５８】
本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、予約フィールド（Ｒｅｓ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフラグフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、ＦＥＣペイロードＩＤフィールド、及び／又はエンコーディングシンボルフィールドを含むことができる。
【１２５９】
ＬＣＴバージョン番号フィールド（Ｖ）は、プロトコルバージョン番号を示す。例えば、このフィールドは、ＬＣＴバージョン番号を示す。ＬＣＴヘッダーのバージョン番号フィールドは、ＲＯＵＴＥバージョン番号フィールドとして解釈できる。ＲＯＵＴＥのこのバージョンは、ＬＣＴ形成ブロックのバージョン“１”を暗示的に用いる。例えば、バージョン番号は“０００１ｂ”である。
【１２６０】
混雑制御フラグフィールド（Ｃ）は、混雑制御情報フィールドの長さを示す。Ｃ＝０は、混雑制御情報（ＣＣＩ）フィールドが３２ビットの長さを有することを示し、Ｃ＝１は、ＣＣＩフィールドが６４ビットの長さを有することを示し、Ｃ＝２は、ＣＣＩフィールドが９６ビットの長さを有することを示し、Ｃ＝３は、ＣＣＩフィールドが１２８ビットの長さを有することを示す。
【１２６１】
プロトコル特定指示フィールド（ＰＳＩ）は、ＬＣＴ上位プロトコルにおいて特定目的の指示子として用いられてもよい。ＰＳＩフィールドは、現在パケットがソースパケットであるか又はＦＥＣリペアパケットであるかを示す。ＲＯＵＴＥソースプロトコルが単にソースパケットだけを伝達するので、このフィールドは“１０ｂ”に設定されるはずである。伝送セッション識別子フラグフィールド（Ｓ）は、伝送セッション識別子フィールドの長さを示す。
【１２６２】
伝送オブジェクト識別子フラグフィールド（Ｏ）は、伝送オブジェクト識別子フィールドの長さを示す。例えば、オブジェクトは一つのファイルを意味することができ、上記ＴＯＩは、各オブジェクトの識別情報であって、ＴＯＩが０であるファイルは、ＦＤＴという。
【１２６３】
ハーフワードフラグフィールド（Ｈ）は、ＴＳＩ及びＴＯＩフィールドの長さにハーフワード（１６ビット）を追加するか否かを示す。
【１２６４】
予約フィールド（Ｒｅｓ）は、将来の使用のために予約される。
【１２６５】
クローズセッションフラグフィールド（Ａ）は、セッションが終了したこと又は終了が差し迫っていることことを示す。
【１２６６】
クローズオブジェクトフラグフィールド（Ｂ）は、伝送中であるオブジェクトが終了したこと又は終了が差し迫っていることことを示す。
【１２６７】
ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）は、ＬＣＴヘッダーの全長を３２ビットワードの単位で示す。
【１２６８】
コードポイントフィールド（ＣＰ）は、このパケットによって送信されたペイロードのタイプを示す。ペイロードのタイプによって、追加のペイロードヘッダーが追加されてペイロードデータをプレフィックス（ｐｒｅｆｉｘ）する。
【１２６９】
混雑制御情報フィールド（ＣＣＩ）は、層数、論理チャネル数、シーケンス数などの混雑制御情報の伝送に用いられる。ＬＣＴヘッダー内の混雑制御情報フィールドは、要求される混雑制御情報を含む。
【１２７０】
伝送セッション識別子フィールド（ＴＳＩ）は、セッションの固有識別子である。ＴＳＩは、特定伝送者からの全セッションのうち一つのセッションを固有に識別する。各ＴＳＩフィールドは、ＭＰＥＧ−ＤＡＳＨの各コンポーネント及び／又はリプレゼンテーションにマップすることができる。
【１２７１】
このフィールドは、ＲＯＵＴＥ内の伝送セッションを識別する。伝送セッションのコンテクストはＬＳＩＤ（ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ）によって提供される。ＬＳＩＤは、ＲＯＵＴＥセッションの各構成ＬＣＴ伝送セッションで何が伝送されるかを定義する。各伝送セッションは、ＬＣＴヘッダー内の伝送セッション識別子（ＴＳＩ）によって固有に識別される。ＬＳＩＤは、ＬＣＴ伝送セッションを含む同一のＲＯＵＴＥセッションで伝送することができる。通信網、放送網、インターネット網、ケーブル網、及び／又は衛星網で伝送されてもよいが、ＬＳＩＤが伝送される手段はこれらに限定されない。例えば、ＬＳＩＤは、ＴＳＩの値が‘０’である特定ＬＣＴ伝送セッションで伝送されてもよい。ＬＳＩＤは、ＲＯＵＴＥセッションで伝送される全伝送セッションに対するシグナリング情報を含むことができる。ＬＳＩＤは、ＬＳＩＤバージョン情報及びＬＳＩＤの有効性に関する情報を含むことができる。また、ＬＳＩＤは、ＬＣＴ伝送セッションに関する情報を提供する伝送セッション（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ）情報を含むことができる。伝送セッション情報は、伝送セッションを識別するＴＳＩ情報、当該ＴＳＩで伝送され、ソースデータが伝送されるソースフローに関する情報を提供するソースフロー（ｓｏｕｒｃｅ  ｆｌｏｗ）情報、当該ＴＳＩで伝送され、リペアデータが伝送されるリペアフローに関する情報を提供するリペアフロー（ｒｅｐａｉｒ  ｆｌｏｗ）情報、及び当該伝送セッションに関する追加の特性情報を含む伝送セッションプロパティ（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｐｒｏｐｅｒｔｙ）情報を含むことができる。
【１２７２】
伝送オブジェクト識別子フィールド（ＴＯＩ）は、オブジェクトの固有識別子である。ＴＯＩは、このパケットがセッション内のどのオブジェクトに属するかを示す。各ＴＯＩフィールドは、ＭＰＥＧ−ＤＡＳＨの各セグメントにマップすることができる。ただし、これに限定されず、各ＴＯＩフィールドは、チャンク、ＧＯＰ、及び／又はアクセスユニットのようなＭＰＥＧ−ＤＡＳＨの各セグメントの一部にマップされてもよい。
【１２７３】
このフィールドは、現在のパケットのペイロードがこのセッション内のどのオブジェクトに属するかを示す。オブジェクトへのＴＯＩフィールドのマッピングは、拡張されたＦＤＴによって提供される。拡張されたＦＤＴは、ファイル伝達データの細部事項を特定する。これは、拡張されたＦＤＴインスタンスである。ＬＣＴパケットヘッダーと共に拡張されたＦＤＴは、伝達オブジェクトに対するＦＤＴ同等記述（ＦＤＴ−ｅｑｕｉｖａｌｅｎｔ  ｄｅｓｃｒｉｐｔｉｏｎ）を生成するために用いられてもよい。拡張されたＦＤＴは、リファレンスとして埋め込み（ｅｍｂｅｄ）又は提供されてもよい。リファレンスとして提供されると、拡張されたＦＤＴはＬＳＩＤと独立してアップデートされてもよい。これは、参照される場合には、含まれるソースフローのＴＯＩ＝０上のイン−バンド（ｉｎ−ｂａｎｄ）（帯域内）オブジェクトとして伝達されるはずである。
【１２７４】
ヘッダー拡張フィールドは、追加情報の伝送のためのＬＣＴヘッダー拡張部分として用いられる。ヘッダー拡張は、必ずしも用いられないか、又は可変サイズを有する選択的ヘッダーフィールドを収容するためにＬＣＴに用いられる。
【１２７５】
例えば、ＥＸＴ＿ＴＩＭＥ拡張は、タイミング情報のいくつかの類型を送信するために用いられる。これは、本文書に記述された汎用タイミング情報、すなわち、伝送者現在時間（ＳＣＴ）、予想レジデュアル時間（ＥＲＴ）及び伝送者最後変更（ＳＬＣ）時間拡張を含む。
【１２７６】
ＦＥＣペイロードＩＤフィールドは、送信ブロック又はエンコーディングシンボルの識別情報を含む。ＦＥＣペイロードＩＤは、上記ファイルがＦＥＣエンコードされた場合の識別子を示す。例えば、ＦＥＣペイロードＩＤは、上記ＦＬＵＴＥプロトコルファイルがＦＥＣエンコードされた場合、放送局又は放送サーバーがこれを区分するために割り当てることができる。
【１２７７】
エンコーディングシンボルフィールドは、送信ブロック又はエンコーディングシンボルのデータを含むことができる。
【１２７８】
パケットペイロードは、オブジェクトから生成されたバイトを含む。１よりも多いオブジェクトがセッションで伝送されると、ＬＣＴヘッダー内の送信オブジェクトＩＤ（ＴＯＩ）を、パケットペイロードデータが生成されたオブジェクトを識別するために用いなければならない。
【１２７９】
本発明の他の実施例に係るヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）は、ヘッダー拡張タイプフィールド（ＨＥＴ）、ヘッダー拡張長さフィールド（ＨＥＬ）、ＳＣＴハイフィールド、ＳＣＴローフィールド、ＥＲＴフィールド、ＳＬＣフィールド、予約フィールド、伝送者現在時間フィールド、予想レジデュアル時間フィールド、及び／又はセッション最後変更フィールドを含むことができる。また、本発明の他の実施例に係るヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）は使用フィールドを含み、使用フィールドは、ＳＣＴハイフィールド、ＳＣＴローフィールド、ＥＲＴフィールド、ＳＬＣフィールド、及び／又は予約フィールドを含むことができる。
【１２８０】
ヘッダー拡張タイプフィールド（ＨＥＴ）は、当該ヘッダー拡張のタイプを示す。ＨＥＴフィールドは８ビットの整数であってもよい。基本的に、ＬＣＴではＨＥＴが０〜１２７の値を有する場合、３２ビットワード単位の可変長ヘッダー拡張が存在し、ＨＥＴに続くヘッダー拡張長さフィールド（ＨＥＬ）にその長さを記述する。ＨＥＴが１２８〜２５５の値を有する場合、ヘッダー拡張は、３２ビット固定長を有する。例えば、本発明の他の実施例に係るＨＥＴフィールドは、‘２’の値を有したり、又は‘１２７’以下の値を有することができ、前述したヘッダー拡張を識別することができる。
【１２８１】
ＨＥＬフィールドは、可変長のヘッダー拡張の全長を示す。基本的に、ＬＣＴではＨＥＴが０〜１２７の値を有する場合、３２ビットワード単位の可変長ヘッダー拡張が存在し、ＨＥＴフィールドに続くＨＥＬフィールドは、ヘッダー拡張の全長を３２ビットワード単位で示す。
【１２８２】
使用フィールド（Ｕｓｅ）は、次の３２ビット時間値のセマンティクスを示す。
【１２８３】
ＳＣＴハイフィールドは、当該ヘッダー拡張に伝送者現在時間フィールドが含まれるか否かを示す。
【１２８４】
ＳＣＴローフィールドは、当該ヘッダー拡張に６４ビットの伝送者現在時間フィールドが含まれるか否かを示す。
【１２８５】
ＥＲＴフィールドは、当該ヘッダー拡張に予想レジデュアル時間フィールドが含まれるか否かを示す。
【１２８６】
ＳＬＣフィールドは、当該ヘッダー拡張にセッション最後変更フィールドが含まれるか否かを示す。
【１２８７】
予約フィールド（Ｒｅｓ）は、将来の使用のために予約される。
【１２８８】
伝送者現在時間フィールドは、伝送ジャー側の現在クロックを示し、このとき、このパケットが伝送されて１ｍｓの単位で測定され、セッションの開始からモジューロ２＾３２単位で計算された。
【１２８９】
ＳＣＴハイフィールドが設定されると、関連した３２ビット時間値は、伝送者のウォールクロックの秒単位で時間を示す符号無し整数を提供する。ＮＴＰが用いられる特定の場合、この３２ビットは、１９００年１月１日００：００時ＧＭＴに対して秒単位の時間を示す符号無し整数を提供する（すなわち、全体６４ビットＮＴＰ時間値の最上位３２ビット）。
【１２９０】
ＳＣＴ−ローフラグが設定されると、関連した３２ビット時間値は、サブセカンド（ｓｕｂ−ｓｅｃｏｎｄ）精密度を許容するために秒の１／２＾＾３２の倍数を示す符号無し整数を提供する。ＳＣＴ−ローフラグが設定されると、ＳＣＴ−ハイフラグも設定されなければならない。ＮＴＰが用いられる特定の場合、これらの３２ビットは６４ビットＮＴＰタイムスタンプの最下位３２ビットを提供する）。
【１２９１】
予想レジデュアル時間フィールドは、１ｍｓの単位で測定された現在オブジェクトの送信のための又は現在セッションのための伝送者予想レジデュアル送信時間を示す。ＥＲＴフィールドを含むパケットがＴＯＩフィールドを含むと、ＥＲＴは、ＴＯＩフィールドに対応するオブジェクトを意味し、或いは、セッションを意味する。
【１２９２】
ＥＲＴタイミング情報を含むパケットもＴＯＩフィールドを含むと、ＥＲＴは、ＴＯＩフィールドに対応するオブジェクトを意味し、或いは、セッション内のオブジェクトだけを意味する。ＥＲＴフラグが設定されると、秒の数で表現される。３２ビットはこの秒の数を示す符号無し整数を提供する。
【１２９３】
セッション最後変更フィールドは、セッションデータに対する最後の変更が発生したサーバーウォールクロック時間を秒単位で示す。すなわち、これは、伝達セッションに対する最後の（最も最近の）伝送オブジェクトの追加、変更又は除去が発生した時間を示す。変更及び追加の場合、この時間の前に伝送されていない新しいデータが伝送される旨を示す。除去の場合、ＳＬＣは、いくつかの以前データがそれ以上伝送されない旨を示す。ＳＬＣフィールドが設定されると、関連した３２ビット時間値は、時間を秒単位で示す符号無し整数を提供する。ＮＴＰが用いられる特定の場合、これらの３２ビットは、１９００年１月１日００：００時ＧＭＴに対して秒単位の時間を示す符号無し整数を提供する（すなわち、全６４ビットＮＴＰ時間値の最上位３２ビット）。この場合、３２ビット時間の循環（ｗｒａｐ  ａｒｏｕｎｄ）のハンドリングは、ＮＴＰ及びＬＣＴの範囲外にある。任意の場合、ＳＬＣ情報と共にＥＸＴ＿ＴＩＭＥヘッダー拡張を含むパケットも、ＳＣＴハイ情報を含むことが好適であろう。
【１２９４】
本発明の他の実施例に係るＬＣＴパケットは、既存のヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）を拡張して、前述したタイムラインリファレンスシグナリング情報（ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報）をさらに含むことができる。
【１２９５】
本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、ＩＴＲハイ情報、ＩＴＲロー情報、ＥＴＲハイ情報、ＥＴＲロー情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＩＴＲ Ｓｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＥＴＲ  Ｓｃａｌｅ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲ  Ｆｏｒｍａｔ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲ  Ｆｏｒｍａｔ）、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報（ＵＲＬ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（内部タイムラインリファレンス）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（外部タイムラインリファレンス）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（内部タイムラインリファレンスタイムスケール）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（外部タイムラインリファレンスタイムスケール）、及び／又はｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報（外部メディアＵＲＬ）を含むことができる。
【１２９６】
また、本発明の他の実施例に係るヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）は使用情報を含み、使用情報は、ＩＴＲハイ情報、ＩＴＲロー情報、ＥＴＲハイ情報、ＥＴＲロー情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＩＴＲ Ｓｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＥＴＲ  Ｓｃａｌｅ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲ  Ｆｏｒｍａｔ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲ  Ｆｏｒｍａｔ）、及び／又はｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報（ＵＲＬ）をさらに含むことができる。
【１２９７】
ＩＴＲハイ情報及び／又はＩＴＲロー情報は、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報と呼ぶことができる。ＥＴＲハイ情報及び／又はＥＴＲロー情報は、前述したｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報と呼ぶことができる。
【１２９８】
ＩＴＲ  Ｈｉ（Ｉｎｔｅｒｎａｌ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅ  Ｈｉｇｈ  Ｆｌａｇ）情報は、当該ヘッダー拡張に６４ビットのｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（内部タイムラインリファレンス）が含まれるか否かを示す。
【１２９９】
ＩＴＲロー（内部タイムラインリファレンスローフラグ）情報は、当該ヘッダー拡張に３２ビットのｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（内部タイムラインリファレンス）が含まれるか否かを示す。
【１３００】
ＥＴＲハイ（外部タイムラインリファレンスハイフラグ）情報は、当該ヘッダー拡張に６４ビットのｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報が含まれるか否かを示す。
【１３０１】
ＥＴＲロー（外部タイムラインリファレンスローフラグ）情報は、当該ヘッダー拡張に３２ビットのｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報が含まれるか否かを示す。
【１３０２】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＩＴＲ Ｓｃａｌｅ）は、当該ヘッダー拡張に３２ビットのｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報が含まれるか否かを示す。
【１３０３】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＥＴＲ  Ｓｃａｌｅ）は、当該ヘッダー拡張に３２ビットのｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報が含まれるか否かを示す。
【１３０４】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲ  Ｆｏｒｍａｔ）は、内部タイムラインリファレンスのフォーマットを示すことができる。例えば、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲ  Ｆｏｒｍａｔ）の値が、０ｘ００であれば、メディアタイムであることを示し、０ｘ０１であれば、ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、タイムコードであることを示し、０ｘ０４−０ｘ１Ｆであれば、将来に定義すればよく、そのために予約されてもよい。
【１３０５】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲ  Ｆｏｒｍａｔ）は、外部タイムラインリファレンスのフォーマットを示すことができる。例えば、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲ  Ｆｏｒｍａｔ）の値が、０ｘ００であれば、メディアタイムであることを示し、０ｘ０１であれば、ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）であることを示し、０ｘ０２であれば、ＰＴＰであることを示し、０ｘ０３であれば、タイムコードであることを示し、０ｘ０４−０ｘ１Ｆであれば、将来に定義すればよく、そのために予約されてもよい。
【１３０６】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報（ＵＲＬ）は、当該ヘッダー拡張にｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報（外部メディアＵＲＬ）が含まれるか否かを示すことができる。
【１３０７】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（内部タイムラインリファレンス）は、内部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。
【１３０８】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（Ｅｘｔｅｒｎａｌ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅ）は、外部網で伝送されるメディアストリームのタイムラインを構成するリファレンスクロック値を示す。
【１３０９】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（内部タイムラインリファレンスタイムスケール）は、内部タイムラインリファレンス情報の時間単位を示す。例えば、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、内部タイムラインリファレンス値の時間単位をヘルツ（Ｈｚ）単位で示すことができる。
【１３１０】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（外部タイムラインリファレンスタイムスケール）は、外部タイムラインリファレンス情報の時間単位を示す。例えば、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報は、外部タイムラインリファレンス値の時間単位をヘルツ（Ｈｚ）単位で示すことができる。
【１３１１】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報（外部メディアＵＲＬ）は、外部網（例えば、インターネット網）で伝送されるメディアの位置情報、及び／又は固有識別子などの情報を含むことができる。例えば、外部網で伝送されるメディアがＭＰＥＧ−ＤＡＳＨである場合、当該ＭＰＤのＵＲＬ、及び／又はＭＰＤ  ｉｄなどの情報を含むことができる。上記フィールドの長さは、ＨＥＬフィールドで識別することができる。
【１３１２】
本発明の他の実施例によれば、受信機及び／又はプロセッサは、放送網の放送信号からＬＣＴヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）を取得し、ヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）からタイムラインリファレンスシグナリング情報を取得することができる。また、受信機及び／又はプロセッサは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報によって識別される外部網のストリームに、タイムスタンプ、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報、及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を適用して、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期化を取ることができる。
【１３１３】
図７７は、本発明の他の実施例に係る、タイムラインリファレンス情報伝送を支援するＬＣＴパケットの構造を示す図である。
【１３１４】
本発明の他の実施例に係るＬＣＴパケットは、既存のヘッダー拡張を拡張してタイムラインリファレンスシグナリング情報（ＥＸＴ＿ＴＲＣ；Ｅｘｔｅｎｓｉｏｎ  ｆｏｒ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅ  Ｃｌｏｃｋ）を含むことができる。本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、前述したタイムラインリファレンス情報ＡＵと同一及び／又は類似の情報を含むことができる。前述したタイムラインリファレンスシグナリング情報は、ＲＴＰ（ｒｅａｌｔｉｍｅ  ｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用されてもよい。
【１３１５】
本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、前述したプロトコルに適したサービスシグナリング情報と連動して動作することができる。サービスシグナリング情報は、当該ストリームが内部網及び／又は外部網のタイムラインリファレンスを伝送していることを示す情報、タイムラインリファレンス情報ＡＵに含まれる外部メディアＵＲＬ情報、フラグ情報、及び／又はタイムスケール情報などを含めて、各パケットに共通して適用可能な情報を含むことができる。
【１３１６】
本発明の他の実施例に係るパケットはＬＣＴパケットであってもよく、ＬＣＴパケットは、ＬＣＴバージョン番号フィールド（Ｖ）、混雑制御フラグフィールド（Ｃ）、プロトコル特定指示フィールド（ＰＳＩ）、伝送セッション識別子フラグフィールド（Ｓ）、伝送オブジェクト識別子フラグフィールド（Ｏ）、ハーフワードフラグフィールド（Ｈ）、予約フィールド（Ｒｅｓ）、クローズセッションフラグフィールド（Ａ）、クローズオブジェクトフィールド（Ｂ）、ＬＣＴヘッダー長フィールド（ＨＤＲ＿ＬＥＮ）、コードポイントフィールド（ＣＰ）、混雑制御情報フィールド（ＣＣＩ）、伝送セッション識別子フィールド（ＴＳＩ）、伝送オブジェクト識別子フィールド（ＴＯＩ）、ヘッダー拡張フィールド、ＦＥＣペイロードＩＤフィールド、及び／又はエンコーディングシンボルフィールドを含むことができる。
【１３１７】
本発明の他の実施例に係るＬＣＴパケットは、既存のヘッダー拡張（ＥＸＴ＿ＴＲＣ；Ｅｘｔｅｎｓｉｏｎ  ｆｏｒ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅ  Ｃｌｏｃｋ）を拡張して、前述したタイムラインリファレンスシグナリング情報をさらに含むことができる。
【１３１８】
本発明の他の実施例に係るタイムラインリファレンスシグナリング情報は、ＩＴＲハイ情報、ＩＴＲロー情報、ＥＴＲハイ情報、ＥＴＲロー情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＩＴＲ Ｓｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＥＴＲ  Ｓｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報（ＵＲＬ）、予約情報（Ｒｅｓ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲ  Ｆｏｒｍａｔ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲ  Ｆｏｒｍａｔ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（内部タイムラインリファレンス）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報（外部タイムラインリファレンス）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（内部タイムラインリファレンスタイムスケール）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ情報（外部タイムラインリファレンスタイムスケール）、及び／又はｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報（外部メディアＵＲＬ）を含むことができる。
【１３１９】
また、本発明の他の実施例に係るヘッダー拡張（ＥＸＴ＿ＴＲＣ）は使用情報を含み、使用情報は、ＩＴＲハイ情報、ＩＴＲロー情報、ＥＴＲハイ情報、ＥＴＲロー情報、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＩＴＲ Ｓｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ情報（ＥＴＲ  Ｓｃａｌｅ）、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報（ＵＲＬ）、Ｒｅｓｅｒｖｅｄ情報（Ｒｅｓ）、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＩＴＲ  Ｆｏｒｍａｔ）、及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔ情報（ＥＴＲ  Ｆｏｒｍａｔ）をさらに含むことができる。
【１３２０】
前述したＬＣＴパケットに含まれる情報と同じ名称を有する情報に関する説明は、前述した説明に代える。
【１３２１】
本発明の他の実施例によれば、受信機及び／又はプロセッサは、放送網の放送信号からヘッダー拡張（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎｓ；ＥＸＴ＿ＴＲＣ）を取得し、ヘッダー拡張（ＥＸＴ＿ＴＲＣ）からタイムラインリファレンスシグナリング情報を取得することができる。また、受信機及び／又はプロセッサは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ情報によって識別される外部網のストリームに、タイムスタンプ、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報、及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ情報を適用して、放送網で伝送されるストリームと異種網で伝送されるストリームとの同期化を取ることができる。
【１３２２】
図７８は、本発明の一実施例に係る、ＤＡＳＨが適用される放送網の伝送ストリームと異種網（例えば、インターネット網）の伝送ストリームとを、タイムラインコンポーネントＡＵを用いて同期化する方法を示す図である。
【１３２３】
同図は、タイムラインコンポーネントを用いて、異種網を介した伝送ストリーム間の同期化方案をＤＡＳＨに適用した実施例を示す。本実施例では、ビデオストリームを放送網で伝送し、オーディオストリームをインターネット網で伝送することができる。２つのストリームともＤＡＳＨによってカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）されてサービスされているが、互いに異なる網で伝送されるため、別途のＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を有する独立したコンテンツ形態として別個のタイムラインを有することができる。
【１３２４】
互いに独立したタイムラインを有する２つのストリーム間の同期化のために、タイムラインコンポーネントが放送網で伝送されるＤＡＳＨコンテンツに含まれてもよい。放送網で伝送されるビデオストリーム及びタイムラインコンポーネントストリームは、一つのコンテンツに含まれて一つのタイムラインを共有することができ、タイムラインコンポーネントは、インターネット網で伝送されるオーディオストリームのタイムライン情報を含み、この情報に基づいて受信機は、放送網のタイムラインを用いてインターネット網伝送ストリームを同期化することができる。
【１３２５】
ＤＡＳＨコンテンツにおいてタイムラインコンポーネントストリームは、ビデオストリーム又はオーディオストリームと同様に、一つのトラック（ｔｒａｃｋ）として構成されてもよい。タイムラインコンポーネントストリームに対して、ＭＰＤ及びｔｒａｆボックスなどで提供されるタイミング情報を介してそれぞれのＡＵ単位でＤＴＳ、ＰＴＳなどのタイムスタンプが与えられ、放送網タイムラインにマップされてもよい。タイムラインコンポーネントストリームをトラックとして構成するとき、当該トラックがタイムラインコンポーネントストリームを含んでいることを識別可能なシグナリング（ｓｉｇｎａｌｉｎｇ）情報を必要としてもよい。このようなシグナリング情報は、ＩＳＯ  ＢＭＦＦベースのＤＡＳＨ初期化セグメント（ＤＡＳＨ  ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ）内のｈｄｌｒボックスに含まれてもよく、含まれたメディアのタイプを示すｈａｎｄｌｅｒ＿ｔｙｐｅと、ｍｉｎｆボックスに含まれるメディアヘッダーボックス、及びメディアストリームの具体的タイプと初期化情報を示すｓｔｓｄボックス内のサンプルエントリ（Ｓａｍｐｌｅ  Ｅｎｔｒｙ）などとして提供されてもよい。
【１３２６】
タイムラインコンポーネントは、ｈｄｌｒボックスに“ｍｅｔａ”というハンドラタイプでメタデータタイプに属することを表現することができ、“ｎｍｈｄ”というヌル（ｎｕｌｌ）メディアヘッダーボックスを含むことができる。
【１３２７】
図７９は、本発明の一実施例に係る、ＩＳＯ  ＢＭＦＦ（ＩＳＯ  ｂａｓｅ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔ）においてタイムラインコンポーネントを識別するためのサンプルエントリを示す図である。
【１３２８】
本発明の一実施例によれば、タイムラインコンポーネントを識別するために、ｓｔｓｄボックスに含まれるストリームシグナリング情報を図示のように設定することができる。
【１３２９】
タイムラインコンポーネントストリームをファイル内で識別するために、メタデータサンプルエントリの派生型としてＴｉｍｅｌｉｎｅ  Ｃｏｍｐｏｎｅｎｔ  ＭｅｔａＤａｔａ  ＳａｍｐｌｅＥｎｔｒｙが定義されてもよい。Ｔｉｍｅｌｉｎｅ  Ｃｏｍｐｏｎｅｎｔ  ＭｅｔａＤａｔａ  ＳａｍｐｌｅＥｎｔｒｙは、‘ｍｅｔｃ’のような４バイトのタイプを有することができ、上記のようなタイプフィールドを介してファイル内で固有に識別されてもよい。
【１３３０】
タイムラインコンポーネントが記述しているストリームの位置ＵＲＬ又はストリームを再生させるまでの初期ディレー（ｄｅｌａｙ）などの初期化及びシグナリングパラメータを“ｍｅｔｃ”サンプルエントリ内に含めることができる。
【１３３１】
図８０は、本発明の一実施例に係る、ＩＳＯ  ＢＭＦＦでタイムラインコンポーネントトラックと他のトラックとの依存関係を表現するためのトラックリファレンスタイプボックス（Ｔｒａｃｋ  Ｒｅｆｅｒｅｎｃｅ  Ｔｙｐｅ  Ｂｏｘ）を示す図である。
【１３３２】
タイムラインコンポーネントをＤＡＳＨセグメントのようなＩＳＯ  ＢＭＦＦベースファイル構造体に含めるために、前述したシグナリング情報に加えて、他のトラックとの依存関係に関する情報をシグナルすることもできる。同図は、トラック間の依存関係を表現するｔｒｅｆボックスを用いて、タイムラインコンポーネントトラックとＤＡＳＨセグメントの他のトラックとの依存関係を表現する実施例を示す。
【１３３３】
Ｔｒｅｆボックスは、内部にトラックリファレンスタイプボックスを含む。Ｔｒｅｆボックスは、前述したタイムラインコンポーネントと他のトラックとの依存関係を表現するためのタイプとして、前述したように‘ｍｅｔｌ’というｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅを定義することができる。Ｔｒｅｆボックス内のｔｒａｃｋ＿ＩＤは、参照関係を有するトラックのＩＤを意味する。‘ｍｅｔｌ’リファレンスタイプボックスの定義を用いて、タイムラインコンポーネントとタイムラインを共有する他のトラックとの依存関係を表現することができる。
【１３３４】
前述の図面に示したように、前述の‘ｍｅｔｌ’ボックスを含むｔｒｅｆボックスは、タイムラインコンポーネントトラックボックスに含まれ、依存関係にあるビデオトラックのＩＤを‘ｍｅｔｌ’ボックス内に含む。又は、実施例のビデオトラックにｔｒｅｆボックス及び‘ｍｅｔｌ’ボックスが含まれ、‘ｍｅｔｌ’のｔｒａｃｋ＿ＩＤとしてタイムラインコンポーネントトラックのＩＤを含むこともできる。
【１３３５】
図８１は、本発明の一実施例に係る、次世代放送システムにおいてサービス及び／又はコンテンツを取得する構造を示す図である。
【１３３６】
本発明で提案した方案は、次世代放送システムでは、受信機がサービス或いはコンテンツを放送網或いはインターネット網を介して効率的に取得できるようにする。
【１３３７】
同図は、ハイブリッド放送システムにおいてサービス或いはコンテンツを取得するための一例を示す。
【１３３８】
例えば、サービス０（Ｓｅｒｖｉｃｅ  ０）は、一つのビデオ（ｖｉｄｅｏ）及び一つのオーディオ（ａｕｄｉｏ）で構成され、ビデオ／オーディオはそれぞれ、地上波放送網で伝送されるＩＰストリーム（ＩＰ  ｓｔｒｅａｍ）を介して取得することができる。
【１３３９】
サービス１（Ｓｅｒｖｉｃｅ  １）の場合、ビデオを送信するＩＰストリームとオーディオを送信するＩＰストリームとが一つのＰＬＰを介して伝送されるため、受信機は当該ＰＬＰをデコードしてサービス１を取得することができる。
【１３４０】
サービスＮ（Ｓｅｒｖｉｃｅ  Ｎ）の場合、ビデオは地上波放送網で伝送されるが、オーディオはインターネット網で取得することができる。
【１３４１】
このように受信機がサービス０、サービス１、又はサービスＮに含まれているコンポーネントを取得する過程で、前述した本発明の実施例を用いることができる。すなわち、受信機は、サービス０、サービス１、又はサービスＮに含まれたそれぞれのコンポーネントを送信するＰＬＰを識別し、当該ＰＬＰをデコードして所望のサービスを取得することができる。
【１３４２】
図８２は、本発明の一実施例に係る、ＩＳＯ  ＢＭＦＦにおいてビデオデータ及び／又はオーディオデータに接近する方法を示す図である。
【１３４３】
同図には、ＩＳＯ  ＢＭＦＦの構造の一部が示されている。図示のビデオデータ及び／又はオーディオデータに接近する方法は、ローカル再生（ｌｏｃａｌ  ｒｅｐｌａｙ）においてデータ間の同期化を行うことを示している。
【１３４４】
受信機は、ＩＳＯファイルで‘ｔｋｈｄ’を用いてトラックを識別する。
【１３４５】
受信機は、‘ｈｄｌｒ’（ｈａｎｄｌｅｒ＿ｔｙｐｅ）を用いて、メディアのタイプがオーディオなのか又はビデオなのかを識別することができる。
【１３４６】
‘ｓｔｂｌ’ボックスは‘ｓｔｓｄ’ボックス、‘ｓｔｔｓ’ボックス、‘ｃｔｔｓ’ボックス、‘ｓｔｓｃ’ボックス、‘ｓｔｃｏ’ボックス及び／又は‘ｓｔｓｚ’ボックスを含むことができる。
【１３４７】
受信機は、‘ｓｔｂｌ’のサンプル記述（ｓａｍｐｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ）（‘ｓｔｓｄ’ボックス）を用いてデコーダを初期化し、これに含まれた情報を用して、ｍｄａｔに含まれたデータ（ｓａｍｐｌｅｓ）をデコードすることができる。
【１３４８】
‘ｓｔｔｓ’ボックスは、デコーディング時間（ｄｅｃｏｄｉｎｇ  ｔｉｍｅ）を示す。‘ｓｔｔｓ’ボックスは、デコーディング時間からサンプル番号までのインデクシング（ｉｎｄｅｘｉｎｇ）を可能にする情報を含む。‘ｓｔｔｓ’ボックスは、サンプル番号からのサンプルサイズ、ポインタを提供することができる。
【１３４９】
‘ｃｔｔｓ’ボックスは、デコーディング時間とコンポジッション時間（ｃｏｍｐｏｓｉｔｉｏｎ  ｔｉｍｅ）間のオフセット（ｏｆｆｓｅｔ）に関する情報を提供する。
【１３５０】
‘ｓｔｓｃ’ボックスは、サンプルを含むチャンク（Ｃｈｕｎｋ）、チャンクの位置、及び／又はサンプルに関連した属性情報を含む。メディアデータ内のサンプルはチャンクにグループ化してもよい。チャンクはそれぞれ別個のサイズを有することができ、一つのチャンク内のサンプルもそれぞれ別個のサイズを有することができる。
【１３５１】
‘ｓｔｃｏ’ボックスは、ファイルに含まれるそれぞれのチャンクに対するインデックス（ｉｎｄｅｘ）情報を含むことができる。‘ｓｔｃｏ’ボックスは、メディアファイルに含まれるチャンクの開始のオフセットを提供する。
【１３５２】
‘ｓｔｓｚ’ボックスは、サンプルカウント及び各サンプルのバイト単位のサイズを提供するテーブルを含む。これは、メディアデータ自体がアンフレーム（ｕｎｆｒａｍｅｄ）されるようにする。メディア内の全サンプルの数は常にサンプルカウントで示される。‘ｓｔｓｚ’ボックスは、デフォルトサンプルサイズを特定する情報を含むことができる。全サンプルが同一のサイズを有すると、情報はサイズ値を含む。この情報が０に設定されると、サンプルは別個のサイズを有し、それらのサイズはサンプルサイズテーブルに保存される。この情報が０でないと、一定のサンプルサイズを特定し、アレイが続かない。
【１３５３】
受信機は、‘ｓｔｂｌ’ボックスに含まれる上記の情報を用いて、ビデオサンプル（ビデオデータ）とオーディオサンプル（オーディオデータ）との同期を取ることができる。
【１３５４】
図８３は、本発明の他の実施例に係る、ＩＳＯ  ＢＭＦＦにおいてビデオデータ及び／又はオーディオデータに接近する方法を示す図である。
【１３５５】
同図のビデオデータ及び／又はオーディオデータに接近する方法は、ストリーミング（ｓｔｒｅａｍｉｎｇ  ｒｅｐｌａｙ）においてデータ間の同期を取ることを示している。この場合、ビデオデータ及び／又はオーディオデータは、フラグメンテーション（ｆｒａｇｍｅｎｔａｔｉｏｎ）及び／又はセグメンテーション（ｓｅｇｍｅｎｔａｔｉｏｎ）された状態で伝送／受信される。
【１３５６】
受信機は、初期化セグメント（ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ）からファイル復号に必要な基本的な情報を取得する。受信機はＩＳＯファイルで‘ｔｋｈｄ’を用いてトラックを識別する。
【１３５７】
受信機は、‘ｈｄｌｒ’（ｈａｎｄｌｅｒ＿ｔｙｐｅ）を用いて、メディアのタイプがオーディオなのか又はビデオなのかを識別することができる。
【１３５８】
受信機は、‘ｍｉｎｆ’ボックスに含まれている現在トラックのメディアの特性情報を用いてデコーダを初期化する。
【１３５９】
受信機は、メディアセグメント内の‘ｔｆｈｄ’ボックスを用いて、‘ｔｋｈｄ’によって識別されたトラックに該当するメディアセグメントを識別し、‘ｍｉｎｆ’ボックスのサンプル記述（ｓａｍｐｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ）に該当するサンプル記述インデックスを取得する。
【１３６０】
受信機は、‘ｔｆｈｄ’ボックスに含まれたベースデータオフセット情報、‘ｔｒｕｎ’ボックスに含まれたデータオフセット情報、及び／又は‘ｔｒｕｎ’ボックスに含まれたサンプルサイズ情報を用いて、ビデオデータ及び／又はオーディオデータのサンプルを抽出する。
【１３６１】
受信機は、‘ｔｒｕｎ’ボックスに含まれたサンプルデューレーション情報とサンプル構成時間オフセット情報を用いて、ビデオデータ及び／又はオーディオデータのサンプル間に同期化を行う。
【１３６２】
具体的な放送サービスを伝送する伝送フレームと伝送パケットについては、図８４乃至図８７を介して説明する。
【１３６３】
図８４は、本発明の一実施例による放送伝送フレームを示す図である。
【１３６４】
図８４の実施例において、放送伝送フレームはＰ１パート、Ｌ１パート、共通ＰＬＰ（Ｃｏｍｍｏｎ  ＰＬＰ）パート、インターリーブドＰＬＰ（Ｓｃｈｅｄｕｌｅｄ＆Ｉｎｔｅｒｌｅａｖｅｄ  ＰＳＰ’ｓ）パート及び補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）パートを含む。
【１３６５】
図８４の実施例において、放送伝送装置は放送伝送フレーム（ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）のＰ１パートを介して伝送シグナル探知（ｔｒａｎｓｐｏｒｔ  ｓｉｇｎａｌ  ｄｅｔｅｃｔｉｏｎ）のための情報を伝送する。また、放送伝送装置はＰ１パートを介して放送信号チューニングのためのチューニング情報を伝送する。
【１３６６】
図８４の実施例において、放送伝送装置はＬ１パートを介して放送伝送フレームの構成及びそれぞれのＰＬＰの特性を伝送する。この際、放送受信装置１００はＰ１に基づいてＬ１パートをデコーディングして放送伝送フレームの構成及びそれぞれのＰＬＰの特性を獲得する。
【１３６７】
図８４の実施例において、放送伝送装置はＣｏｍｍｏｎ  ＰＬＰパートを介してＰＬＰ間に共通に適用される情報を伝送する。具体的な実施例において、放送伝送フレームはＣｏｍｍｏｎ  ＰＬＰパートを含まなくてもよい。
【１３６８】
図８４の実施例において、放送伝送装置は放送サービスに含まれた複数のコンポーネントをインターリーブドＰＬＰパートを介して伝送する。この際、インターリーブドＰＬＰパートは複数のＰＬＰを含む。
【１３６９】
図８４の実施例において、放送伝送装置はそれぞれの放送サービスを構成するコンポーネントがそれぞれどのＰＬＯに伝送されるのかをＬ１パートまたはＣｏｍｍｏｎ  ＰＬＰパートを介してシグナリングする。但し、放送受信装置１００が放送サービススキャンのために具体的な放送サービス情報を獲得するためにはインターリーブドＰＬＰパートの複数のＰＬＰを全てデコーディングすべきである。
【１３７０】
図８４の実施例とは異なって、放送伝送装置は放送伝送フレームを介して伝送される放送サービスと放送サービスに含まれたコンポーネントに関する情報を含む別途のパートを含む放送伝送フレームを伝送する。この際、放送受信装置１００は別途のパートを介して迅速に放送サービスと放送サービスに含まれたコンポーネントに関する情報を獲得する。これいついては図８５を介して説明する。
【１３７１】
図８５は、本発明の他の実施例による放送伝送フレームを示す図である。
【１３７２】
図８５の実施例において、放送伝送フレームはＰ１パート、Ｌ１パート、高速情報チャネル（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ、ＦＩＣ）パート、インターリーブドＰＬＰパート及び補助データパートを含む。
【１３７３】
ＦＩＣパートを除く他のパートは図８４の実施例と同じである。
【１３７４】
放送伝送装置はＦＩＣパートを介して高速情報を伝送する。高速情報は伝送フレームを介して伝送される放送ストリームの構成情報（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）、簡略な放送サービス情報及び該当サービス／コンポーネントに関するサービスシグナリングを含む。放送受信装置１００はＦＩＣパートに基づいて放送サービスをスキャンする。詳しくは、放送受信装置１００はＦＩＣパートから放送サービスに関する情報を抽出する。
【１３７５】
図８６は、本発明の一実施例による放送サービスを伝送する伝送パケットの構造を示す図である。
【１３７６】
図８６の実施例において、放送サービスを伝送する伝送パケットはＮｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールド、Ｅｒｒｏｒ  Ｉｎｄｉｃａｔｏｒフィールド、Ｓｔｕｆｆｉｎｇ  Ｉｎｄｉｃａｔｏｒフィールド、Ｐｏｉｎｔｅｒ  ｆｉｅｌｄフィールド、Ｓｔｕｆｆｉｎｇ  ｂｙｔｅｓフィールド及びペイロードデータを含む。
【１３７７】
Ｎｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールドはネットワークプロトコールがどのタイプであるのかを示す。具体的な実施例において、Ｎｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールドの値はＩＰｖ４プロトコールであるのかまたはフレームドパケットタイプであるのかを示す。詳しくは、図８７の実施例のようにＮｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールドの値が０００であればＩＰｖ４プロトコールを示す。また、詳しくは、図８７の実施例のようにＮｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールドの値が１１１であればｆｒａｍｅｄ＿ｐａｃｋｅｔ＿ｔｙｐｅプロトコールを示す。この際、ｆｒａｍｅｄ＿ｐａｃｋｅｔ＿ｔｙｐｅはＡ／１５３によって定義されたプロトコールである。詳しくは、ｆｒａｍｅｄ＿ｐａｃｋｅｔ＿ｔｙｐｅは長さに関する情報を示すフィールドを含まないネットワークパケットプロトコールを示す。具体的な実施例において、Ｎｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールドは３ビットフィールドである。
【１３７８】
Ｅｒｒｏｒ  Ｉｎｄｉｃａｔｏｒフィールドは該当伝送パケットにエラーが検出されたのかを示す。詳しくは、Ｅｒｒｏｒ  Ｉｎｄｉｃａｔｏｒフィールドの値が０であれば該当パケットからエラーが検出されないことを示し、Ｅｒｒｏｒ  Ｉｎｄｉｃａｔｏｒフィールドの値が１であれば該当パケットからエラーが検出されたことを示す。具体的な実施例において、Ｅｒｒｏｒ  Ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【１３７９】
Ｓｔｕｆｆｉｎｇ  Ｉｎｄｉｃａｔｏｒフィールドは該当伝送パケットにスタッフィングバイト（ｓｔｕｆｆｉｎｇ  ｂｙｔｅｓ）が含まれているのかを示す。この際、スタッフィングバイトは固定されたパケットの長さを維持するためにペイロードに含まれるデータを示す。具体的な実施例において、Ｓｔｕｆｆｉｎｇ  Ｉｎｄｉｃａｔｏｒフィールドの値が１であれば伝送パケットがスタッフィングバイトを含み、Ｓｔｕｆｆｉｎｇ  Ｉｎｄｉｃａｔｏｒフィールドの値が０であれば伝送パケットがスタッフィングバイトを含まないことを示す。具体的な実施例において、Ｓｔｕｆｆｉｎｇ  Ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【１３８０】
Ｐｏｉｎｔｅｒ  ｆｉｅｌｄフィールドは該当伝送パケットのペイロード部分で新たなネットワークパケットの開始地点を示す。具体的な実施例において、Ｐｏｉｎｔｅｒ  ｆｉｅｌｄフィールドの値が０ｘ７ＦＦであれば新たなネットワークパケットの開始地点がないことを示す。また、具体的な実施例において、Ｐｏｉｎｔｅｒ  ｆｉｅｌｄフィールドの値が０ｘ７ＦＦではなければ伝送パケットヘッダの最後の部分から新たなネットワークパケットの開始地点までのオフセット（ｏｆｆｓｅｔ）値を示す。具体的な実施例において、Ｐｏｉｎｔｅｒ  ｆｉｅｌｄフィールドは１１ビットフィールドである。
【１３８１】
Ｓｔｕｆｆｉｎｇ＿Ｂｙｔｅｓフィールドは、固定されたパケット長さを維持するためにヘッダとペイロードデータの間を詰めるスタッフィングバイトを示す。
【１３８２】
このような放送サービスを受信するための放送受信装置の構成については、図８７を介して説明する。
【１３８３】
図８８は、本発明の一実施例による放送サービスシグナリングテーブルと放送サービス伝送経路シグナリグ情報が放送サービスと放送サービス伝送経路をシグナリングすることを示す図である。
【１３８４】
放送サービスシグナリングテーブルは放送サービス情報をシグナリングする。詳しくは、放送サービスが含むメディアコンポーネントをシグナリングする。また、放送サービスシグナリングテーブルは放送サービスと放送サービスが含むメディアコンポーネントの伝送経路をシグナリングする。このため、放送サービスシグナリングテーブルは放送サービス伝送経路シグナリング情報を含む。図８８の実施例において、放送サービスシグナリングテーブルは複数の放送サービスに関する情報を含む。この際、放送サービスシグナリングテーブルは複数の放送サービスそれぞれに含まれた複数のメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報を含む。特に、放送サービスシグナリングテーブルは複数のメディアコンポーネントの伝送経路をシグナリングする放送サービス伝送経路シグナリング情報を含む。例えば、放送サービスシグナリングテーブルを介して放送受信装置１００はサービス（Ｓｅｒｖｉｃｅ  ０）に含まれるビデオ（Ｖｉｄｅｏ  ０）が物理階層パイプ（ＰＬＰ  ０）を介して伝送されることが分かる。また、放送サービスシグナリングテーブルを介して放送受信装置１００はサービス（Ｓｅｒｖｉｃｅ  Ｎ）に含まれるビデオ（Ａｕｄｅｏ  １）がインターネット網を介して伝送されることが分かる。この際、物理階層パイプ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ、ＰＬＰ）は物理階層の上で識別可能な一連の論理的データ伝達経路である。ＰＬＰはデータパイプ（ｄａｔａ  ｐｉｐｅ）など他の用語で称されてもよい。
【１３８５】
図８９は、本発明の一実施例による放送サービスシグナリングテーブルを示す図である。
【１３８６】
放送サービスシグナリングテーブルは放送サービスを識別する情報、放送サービスの現在状態を示す情報、放送サービスのネーム、放送サービスのチャネルナンバー、放送サービスに対する保護アルゴリズムの適用可否を示す情報、放送サービスのカテゴリー情報及び放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報のうち少なくともいずれか一つを含む。放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報はそれぞれのメディアコンポーネントが該当放送サービスに必須的であるのかを示す情報を含む。また、放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報はそれぞれのコンポーネントに関する情報を含む。
【１３８７】
詳しくは、図８９の実施例のように放送サービスシグナリングテーブルは、ｔａｂｌｅ＿ｉｄフィールド、ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールド、ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールド、ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールド、ｖｉｓｏｉｎ＿ｎｕｍｂｅｒフィールド、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｎｕｍ＿ｓｅｒｖｉｃｅフィールド、ｓｅｒｖｉｃｅ＿ｉｄフィールド、ｓｅｒｖｉｅｃ＿ｓｔａｔｕｓフィールド、ＳＰ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールド、ｓｈｏｒｔ＿ｓｅｒｖｉｅｃ＿ｎａｍｅフィールド、ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールド、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔｓフィールド、ｅｓｓｅｎｔｉａｌ＿ｃｏｍｐｏｎｅｎｔ＿ｉｎｄｉｃａｔｏｒフィールド、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールド、ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールド、ｎｕｍ＿ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド及びｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドのうち少なくともいずれか一つを含む。
【１３８８】
ｔａｂｌｅ＿ｉｄフィールドは放送サービスシグナリング情報テーブルの識別子を示す。この際、ｔａｂｌｅ＿ｉｄフィールドの値はＡＴＳＣ  Ａ／６５で定義されたｒｅｓｅｒｖｅｄ  ｉｄ値のうち一つである。具体的な実施例において、ｔａｂｌｅ＿ｉｄフィールドは８ビットである。
【１３８９】
ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは放送サービスシグナリング情報テーブルのＭＰＥＧ−２  ＴＳ標準のｌｏｎｇ形式のｐｒｉｖａｔｅ  ｓｅｃｔｉｏｎ  ｔａｂｌｅであるのか否かを示す。具体的な実施例において、ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【１３９０】
ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールドは現在のテーブルがｐｒｉｖａｔｅ  ｓｅｃｔｉｏｎに当たるのかを示す。具体的な実施例において、ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【１３９１】
ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドはｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドの後に含まれたｓｅｃｔｉｏｎの長さを示す。具体的な実施例において、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドは１２ビットである。
【１３９２】
ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドはｔａｂｌｅ＿ｉｄフィールドと結合して放送サービスシグナリング情報テーブルを識別する値を示す。特に、ｔａｂｌｅ＿ｉｄフィールドはサービスシグナリング情報テーブルのプロトコールバージョンを示すＳＭＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドを含む。具体的な実施例において、ＳＭＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは８ビットフィールドである。
【１３９３】
ｖｉｓｏｉｎ＿ｎｕｍｂｅｒフィールドはサービスシグナリングテーブルのバージョンを示す。放送受信装置１００はｖｉｓｏｉｎ＿ｎｕｍｂｅｒフィールドの値に基づいてサービスシグナリング情報テーブルの情報利用可否を決定する。詳しくは、ｖｉｓｏｉｎ＿ｎｕｍｂｅｒフィールドの値が以前に受信したサービスシグナリングテーブルのバージョンと同じであればサービスシグナリングテーブルの情報を利用しなくてもよい。具体的な実施例において、ｖｉｓｏｉｎ＿ｎｕｍｂｅｒフィールドは５ビットフィールドである。
【１３９４】
Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは放送サービスシグナリングテーブルの情報が現在使用可能であるのかを示す。詳しくは、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドの値が１であれば放送サービスシグナリングテーブルの情報が使用可能であることを示す。また、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドの値が１であれば放送サービスシグナリングテーブルの情報を次に使用可能であることを示す。具体的な実施例にお知恵、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【１３９５】
ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは現在のセクションの番号を示す。具体的な実施例において、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは８ビットフィールドである。
【１３９６】
ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドが最後のセクションの番号を示す。放送サービスシグナリングテーブルの大きさが大きければ複数のセクションに分けられて伝送される。この際、放送受信装置１００はｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドとｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドに基づいてサービスシグナリングテーブルに必要な全てのセクションの受信可否を判断する。具体的な実施例において、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは８ビットフィールドである。
【１３９７】
ｓｅｒｖｉｃｅ＿ｉｄフィールドは放送サービスを識別する識別子を示す。具体的な実施例において、ｓｅｒｖｉｃｅ＿ｉｄフィールドは１６ビットのフィールドである。
【１３９８】
ｓｅｒｖｉｅｃ＿ｓｔａｔｕｓフィールドは放送サービスの現在状態を示す。詳しくは、放送サービスが現在利用可能であるのかを示す。具体的な実施例において、ｓｅｒｖｉｅｃ＿ｓｔａｔｕｓフィールドの値が１であれば放送サービスが現在利用可能であることを示す。具体的な実施例において、放送樹脂装置１００はｓｅｒｖｉｅｃ＿ｓｔａｔｕｓフィールドの値に基づいて該当放送サービスを放送サービスリスト及び放送サービスガイドに表示するのかを決定する。例えば、放送受信装置１００は該当放送サービスが使用不可能であれば該当放送サービスを放送リストと放送サービスガイドに表示しなくてもよい。他の具体的な実施例において、放送受信装置１００はｓｅｒｖｉｅｃ＿ｓｔａｔｕｓフィールドの値に基づいて該当放送サービスに関する接近を制限する。例えば、該当放送サービスが使用不可能であれば放送受信装置１００は該当放送サービスに対するチャネルアップ／ダウンキーを介した接近を制限する。具体的な実施例において、ｓｅｒｖｉｅｃ＿ｓｔａｔｕｓフィールドは２ビットフィールドである。
【１３９９】
ＳＰ＿ｉｎｄｉｃａｔｏｒフィールドは該当放送サービス内の一つ以上のコンポーネントにサービスプロテクション（ｐｒｏｔｅｃｔｉｏｎ）が適用されたのかを示す。例えば、ＳＰ＿ｉｎｄｉｃａｔｏｒフィールドの値が１であれば該当放送サービス内の一つ以上のコンポーネントでサービスプロテクションが適用されていることを示す。具体的な実施例において、ＳＰ＿ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【１４００】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドはｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドの大きさを示す。
【１４０１】
ｓｈｏｒｔ＿ｓｅｒｖｉｅｃ＿ｎａｍｅフィールドは放送サービスの名前を示す。詳しくは、ｓｈｏｒｔ＿ｓｅｒｖｉｅｃ＿ｎａｍｅフィールドは放送サービスの名前を要約して表示する。
【１４０２】
ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは放送サービスの仮想のチャネルナンバーを表示する。
【１４０３】
ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは放送サービスのカテゴリーを示す。詳しくは、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドはＴＶサービス、ラジオサービス、放送サービスガイド、ＲＩサービス及び緊急警告（Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔｉｎｇ）のうちいずれか一つを示す。例えば、ず３９の実施例のようにｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドの値が０ｘ０１であればＴＶサービスを示し、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドの値が０ｘ０２であればラジオサービスを示し、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドの値が０ｘ０８であればサービスガイドを示し、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドの値が０ｘ０９であれば緊急情報を示す。具体的な実施例において、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは６ビットフィールドである。
【１４０４】
ｎｕｍ＿ｃｏｍｐｏｎｅｎｔｓフィールドは該当放送サービスが含むメディアコンポーネントの個数を示す。具体的な実施例において、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔｓフィールドは５ビットフィールドである。
【１４０５】
ｅｓｓｅｎｔｉａｌ＿ｃｏｍｐｏｎｅｎｔ＿ｉｎｄｉｃａｔｏｒフィールドは該当メディアコンポーネントが該当放送サービス再生（ｐｒｅｓｅｎｔａｔｉｏｎ）のために必要な必須メディアコンポーネントであるのかを示す。具体的な実施例において、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔｓフィールドは１ビットフィールドである。
【１４０６】
ｎｕｍ＿ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドはｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドの個数を示す。具体的な実施例において、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドは４ビットフィールドである。
【１４０７】
ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドは該当コンポーネントに関する付加的な属性を含む。
【１４０８】
ｎｕｍ＿ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドはｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドじの個数を示す。具体的な実施例において、ｎｕｍ＿ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドは４ビットフィールドである。
【１４０９】
ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドは該当サービスに関する付加的な属性を含む。
【１４１０】
サービスシグナリングテーブルはアンサンブルに関する情報を更に含む。アンサンブルは一つ以上のサービスが同じ前進誤り訂正が適用されて伝送されれば一つ以上のサービスの集合を示す。図９１は、本発明の他の実施例による放送サービスシグナリングテーブルを示す。
【１４１１】
詳しくは、図９１の実施例のように放送サービスシグナリングテーブルはｎｕｍ＿ｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドとｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを更に含む。
【１４１２】
ｎｕｍ＿ｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドはｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドの個数を示す。具体的な実施例において、ｎｕｍ＿ｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドは４ビットフィールドである。
【１４１３】
ｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドは該当アンサンブルに関する付加的な属性を含む。
【１４１４】
また、サービスシグナリングテーブルはメディアコンポーネントを識別するためにメディアコンポーネントを識別するストリーム識別子情報を更に含む。これについては図９２を介して詳しく説明する。
【１４１５】
図９２は、本発明の一実施例によるストリーム識別子ディスプリプタを示す図である。
【１４１６】
ストリーム識別子情報はｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド及びｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドのうちいずれか一つを含む。
【１４１７】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは該当ｄｅｓｃｒｉｐｔｏｒがストリーム識別子情報を含むｄｅｓｃｒｉｐｔｏｒであることを示す。具体的な実施例において、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは８ビットフィールドである。
【１４１８】
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは該当フィールドの後のストリーム識別子情報の長さを示す。具体的な実施例において、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは８ビットフィールドである。
【１４１９】
ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドはメディアコンポーネントを識別するメディアコンポーネント識別子を示す。この際、メディアコンポーネント識別子は該当シグナリング情報テーブルの上で他のメディアコンポーネントのメディアコンポーネント識別子とは異なる唯一（ｕｎｉｑｕｅ）の値を有する。該当具体的な実施例において、ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドは８ビットフィールドである。
【１４２０】
放送サービスシグナリングテーブルを伝送し受信する動作については図９３乃至図９７を介して説明する。
【１４２１】
前記では放送サービスシグナリングテーブルをビットストリーム形式に説明したが、具体的な実施例によって放送サービスシグナリングテーブルはＸＭＬ形式であってもよい。
【１４２２】
図９３は、本発明の一実施例による放送伝送装置が放送サービスシグナルテーブルを伝送する動作を示す図である。
【１４２３】
本発明の一実施例による放送伝送装置は、放送信号を伝送する伝送部及び放送伝送装置の動作を制御する制御部を含む。伝送部は伝送部が行う複数の機能それぞれを行う一つまたは複数のプロセッサ、一つまたは複数の回路及び一つまたは複数のハードウェアモジュールを含む。詳しくは、放送受信部１１０は様々な半導体部品が一つに集積されるシステム・オン・チップである。この際、ＳＯＣはグラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとＤＲＡＭなど半導体が一つに統合された半導体であってもよい。制御部は制御部が行う複数の機能それぞれを行う一つまたは複数のプロセッサ、一つまたは複数の回路及び一つまたは複数のハードウェアモジュールを含む。詳しくは、放送受信部１１０は様々な半導体部品が一つに集積されるシステム・オン・チップである。この際、ＳＯＣはグラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとＤＲＡＭなど半導体が一つに統合された半導体であってもよい。
【１４２４】
放送伝送装置は制御部を介して伝送パケットに含ませて伝送するデータを獲得するＳ１０１。放送伝送措置が伝送するデータはリアルタイムコンテンツまたはリアルタイムコンテンツに関するメタデータである。詳しくは、リアルタイムコンテンツは地上波放送網などを介して伝送される放送Ａ／Ｖコンテンツまたは放送Ａ／Ｖコンテンツに関する向上されたデータである。
【１４２５】
放送伝送装置は、制御部を介して獲得したデータがデータ伝送のために使用する伝送パケットが含められる容量を超過するのか否かを判断するＳ１０３。詳しくは、放送伝送装置が使用する伝送パケットが固定されたパケット長さを使用するプロトコールを基盤にする。この際、伝送しようとするデータがパケットがカバーし得る容量を超えれば円滑なデータの伝送が難しくなる恐れがある。また、伝送しようとするデータがパケットに比べて非常に小さければ、一つのパケットに小容量のデータ一つのみを伝送することは非効率なパケットの活用になりかねない。よって、上述した非効率性を克服するために放送伝送装置は制御部を介して伝送パケットとデータの大きさを比較する。
【１４２６】
もし、放送伝送装置が伝送するデータを伝送パケットが含められない容量と判断した場合、放送伝送装置は制御部を介して伝送するデータをセグメンテーション（Ｓｅｇｍｅｔａｔｉｏｎ）するＳ１０７。セグメンテーションされたデータは複数のパケットに分けられて伝送される。そして、複数の伝送パケットはセグメンテーションされたデータを識別するための情報を追加的に含む。他の実施例において、セグメンテーションされたデータを識別するための情報は伝送パケットではなく別途のデータグラムを介して伝送されてもよい。
【１４２７】
放送伝送装置は制御部を介してセグメンテーションされたデータまたは伝送パケットより小さい容量を有するデータをパケッタイジング（ｐａｃｋｅｔｉｚｉｎｇ）するＳ１０９。詳しくは、放送伝送装置はデータを伝送可能な形態に加工する。加工された放送パケットはパケットヘッダ（Ｐａｃｋｅｔ  ｈｅａｄｅｒ）とパケットペイロード（Ｐａｃｋｅｔ  ｐａｙｌｏａｄ）を含む。また、パケットペイロードはデータとペイロードのヘッダを含む。ここで、ペイロードヘッダはパケットヘッダとは別にパケットペイロードに含まれたペイロードデータをシグナリングするためのフィールドである。また、セグメンテーションされたデータを含むパケットペイロードはペイロードのヘッダと共にセグメンテーションされたデータヘッダを含む。ここで、セグメンテーションされたデータヘッダはペイロードとは別にパケットペイロードに含まれたペイロードデータをシグナリングするためのフィールドである。
【１４２８】
一実施例において、放送伝送装置は一つのデータを一つのパケットにパケッタイジングする。他の実施例において、放送伝送装置は複数のデータを一つのパケットにパケッタイジングする。また他の実施例において、放送伝送装置は一つのデータを複数のパケットに彫刻化してパケッタイジングする。
【１４２９】
上述したように、データの容量またはパケットの長さに応じてパケッタイジングされた伝送パケットが異なり得る。よって、放送伝送装置は互いに異なる伝送パケットを区別可能な形態に伝送する必要がある。一実施例において、放送伝送装置は制御部を介して伝送パケットのペイロードヘッダにパケットの形態を示す情報を含ませてデータをパケッタイジングする。他の実施例において、放送伝送装置の制御部はペイロードヘッダに含まれた情報のみで伝送するデータを区別することが難しければ、伝送パケットの種類を識別する情報を追加的に含ませてデータをパケッタイジングする。
【１４３０】
放送伝送装置は伝送部を介してパケッタイジングされた放送パケットを伝送するＳ１１１。一実施例において、尚早パケットは地上波放送網を介して行われる。他の実施例において、放送パケットの伝送はインターネット網を介して行われてもよい。
【１４３１】
図９４は、本発明の一実施例による放送受信装置がパケッタイジングされた放送パケットを受信する動作を示す図である。
【１４３２】
放送受信装置１００は、放送受信部１１０を介してパケッタイジングされた伝送パケットを受信するＳ２０１。
【１４３３】
放送受信装置１００は制御部１５０を介して受信された伝送パケットからペイロードヘッダを抽出するＳ２０３。制御部１５０は伝送パケットのペイロードからデータを含むペイロードデータとデータをシグナリングするペイロードヘッダを獲得する。詳しくは、放送受信装置１００の制御部１５０はパケットペイロードに含まれた放送コンテンツ及び放送コンテンツに関する向上されたコンテンツのうち少なくとも一つを提供するための付加的な情報を受信した伝送パケットから抽出する。
【１４３４】
一実施例において、放送受信装置１００の制御部１５０はペイロードヘッダからペイロードエラー判断情報、ペイロード優先順位情報及びペイロードタイプ情報のうち少なくとも一つを抽出する。詳しくは、ペイロードエラー判断情報は放送パケットに含まれたペイロードにエラーが存在するのか、または該当ペイロードが決められたシンタックス（ｓｙｎｔａｘ）を違反する内容を含んでいるのか否かを判断する。
【１４３５】
また、優先順位情報はペイロードに含まれたデータの優先順位を示す。詳しくは、優先順位はペイロードに含まれたデータの属性情報を示す。例えば、ファイルフォーマットメディアデータのシグナリング情報を含んでいるペイロードの場合、該当パケットの優先順位情報は最も高い優先順位に設定されている。
【１４３６】
また、ペイロードタイプ情報はペイロードデータを含むパケットペイロードのタイプを示す。例えば、放送伝送装置が一つのパケットペイロードに一つのデータをパケッタイジングしたのか、または複数のパケットペイロードに一つのデータを分けてパケッタイジングしたのか否かを示す。
【１４３７】
放送受信装置１００は制御部１５０を介して抽出されたペイロードヘッダに含まれた情報からペイロードに含まれたデータがメディアデータであるのか否かを判断するＳ２０５。詳しくは、放送受信装置１００の制御部１５０はパケットヘッダ情報に基づいて該当パケットに含まれたペイロードの類型を判断する。一実施例において、ペイロードの類型は放送コンテンツ及び放送コンテンツに関する向上されたコンテンツのうち少なくとも一つを含むメディアデータであってもよい。他の実施例において、ペイロードの類型はメディアデータを提供するのに必要な付加情報を含むメタデータであってもよい。
【１４３８】
放送受信装置１００の制御部１５０はペイロードに含まれたデータがメディアデータであると判断した場合、全体のメディアデータが受信した一つの伝送パケットに含まれているのか否かを判断するＳ２０７。具体的な実施例において、伝送パケットの長さと全体メディアデータの容量に一つの伝送パケットに全体メディアデータを放送伝送装置がパケッタイジングする。他の実施例において、放送伝送装置は全体目メディアデータを分けてそれぞれ異なる伝送パケットにパケッタイジングする。よって、放送受信装置１００の制御部１５０はコンテンツ出力のための完全な目でライデータを抽出するために放送パケットの類型をペイロードヘッダを介して判断する。
【１４３９】
一方、本発明の一実施例において、放送受信装置１００の制御部１５０はペイロードに含まれたメディアデータではないと判断したば場合は下記図１１７で詳しく説明する。
【１４４０】
一つの伝送パケットに全体のメディアデータが含まれていると判断した場合、制御部１５０は一つのパケットペイロードからメディアデータを抽出する。Ｓ２０９。一実施例において、放送受信装置１００の制御部１５０は一つの伝送パケットから一つのメディアデータのみを抽出する。他の実施例において、放送受信装置１００の制御部１５０は一つの伝送パケットから複数のメディアデータを抽出する。一方、一つの伝送パケットに全体のメディアデータが含まれていないと判断した場合、制御部１５０はペイロードヘッダ及びセグメンテーションデータヘッダに基づいて複数のパケットペイロード部からメディアデータを抽出するＳ２１１。詳しくは、制御部１５０はペイロードヘッダ及びセグメンテーションデータヘッダから分けられてパケッタイジングされたメディアデータの情報を獲得する。よって、制御部１５０は獲得した情報に応じて分けられたメディアデータを識別することができる。つまり、制御部１５０は獲得した情報に応じて分けられたメディアデータの順番を獲得する。制御部１５０は該当順番に基づいて互いに異なる伝送パケットから獲得したメディアデータを組み合わせる（ｃｏｎｃａｔｅｎａｔｅ）。
【１４４１】
放送受信装置１００は制御部１５０を介してコンテンツを提供するＳ２１３。一実施例において、制御部１５０は抽出したメディアデータに基づいてコンテンツを提供する。他の実施例において、制御部１５０は組み合わせられたメディアデータに基づいてコンテンツを提供する。
【１４４２】
Ａ／Ｖコンテンツを出力する。他の実施例において、放送受信装置１００はＡ／Ｖコンテンツに関する向上されたデータを出力してもよい。
【１４４３】
図９５は、本発明の実施例によるパケット構成を示す図である。
【１４４４】
パケット基盤のデータ伝送プロトコールの上において、各パケット一般に図９１に示したようにパケットヘッダとパケットペイロードで構成される。パケットヘッダはパケットが含んでいるパケットペイロードの情報を含む。パケットペイロードは放送網またはインターネット網で伝送しようとするメディアデータを含む。パケットペイロードが含むメディアデータはオーディオ、ビデオ、向上されたサービス及び付加情報のうち少なくともいずれか一つである。
【１４４５】
図９６は、本発明の実施例によるリアルタイムコンテンツ伝送のためのＲＴＰパケットの構造を示す図である。
【１４４６】
ＲＴＰパケットはＲＰＴ  Ｈｅａｄｅｒ及びＲＴＰ  Ｐａｙｌｏａｄを含む。更に、ＲＴＰ  ＨｅａｄｅｒはＴｉｍｅｓｔａｍｐ、Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ｓｏｕｒｃｅ  ｉｄｅｎｔｉｆｉｅｒ及びＣｏｎｔｒｉｂｕｔｉｎｇ  ｓｏｕｒｃｅ  ｉｄｅｎｔｉｆｉｅｒのうち少なくとも一つを含む。
【１４４７】
ＲＴＰ  ＨｅａｄｅｒはＶ（ｖｅｒｓｉｏｎ）フィールド、Ｐ（ｐａｄｄｉｎｇ）フィールド、Ｘ（ｅｘｔｅｎｓｉｏｎ）フィールド、ＣＣフィールド、Ｍ（Ｍａｒｋｅｒ  ｂｉｔ）フィールド、Ｐａｙｌｏａｄ  Ｔｙｐｅフィールド、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒフィールド及びＴｉｍｅｓｔａｍｐフィールドのうち少なくとも一つのフィールドを含む。
【１４４８】
Ｖフィールドは該当ＲＴＰバージョンの情報を示す。具体的な実施例において、Ｖフィールドは２ビットである。
【１４４９】
Ｐフィールドはペイロード内のｐａｄｄｉｎｇビットの存在下非を示す。具体的な実施例において、Ｐフィールドは１ビットである。
【１４５０】
ＸフィールドはＲＴＰ  Ｈｅａｄｅｒ内のｅｘｔｅｎｓｉｏｎフィールドの存在可否を示す。具体的な実施例において、Ｘフィールドは１ビットである。
【１４５１】
ＣＣフィールドはＣｏｎｔｒｉｂｕｔｉｎｇ  ｓｏｕｒｃｅの数を示す。具体的な実施例において、ＣＣフィールドは４ビットである。
【１４５２】
Ｍ（Ｍａｒｋｅｒ  ｂｉｔ）フィールドはＰａｙｌｏａｄ  Ｔｙｐｅに応じて互いに異なる意味を示す。例えば、ｔｒａｎｓｐｏｒｔ  ｏｂｊｅｃｔがファイルであればファイルの最後を示す。他の例として、ｔｒａｎｓｐｏｒｔ  ｏｂｊｅｃｔがビデオまたはオーディオデータであれば関連するａｃｃｅｓｓ  ｕｎｉｔの最初または最後のオブジェクトであることを示す。具体的な実施例において、Ｍフィールドは１ビットである。
【１４５３】
Ｐａｙｌｏａｄ  ＴｙｐｅフィールドはＲＴＰ  Ｐａｙｌｏａｄのタイプを示す。具体的な実施例において、Ｐａｙｌｏａｄ  Ｔｙｐｅフィールドは７ビットである。
【１４５４】
Ｓｅｑｕｅｎｃｅ  ＮｕｍｂｅｒフィールドはＲＴＰパケットのシーケンスナンバーを示す。具体的な実施例において、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒフィールドは１６ビットである。
【１４５５】
ＴｉｍｅｓｔａｍｐフィールドはＲＴＰパケットに関する時間情報を示す。ＴｉｍｅｓｔａｍｐフィールドはＰａｙｌｏａｄ  Ｔｙｐｅフィールドの値に応じて異なるように解析される。具体的な実施例において、Ｔｉｍｅｓｔａｍｐフィールドは３２ビットである。
【１４５６】
ＲＴＰ  ＰａｙｌｏａｄはＲＴＰ  ＨｅａｄｅｒのＰａｙｌｏａｄ  Ｔｙｐｅに応じてオーディオ／ビデオａｃｃｅｓｓ  ｕｎｉｔが含まれる。例えば、Ｈ．２６４の場合ＮＡＬ（ｎｅｔｗｏｒｋ  ａｂｓｔｒａｃｔ  ｌａｙｅｒ）  ｕｎｉｔなどが含まれる。
【１４５７】
図９７は、本発明の一実施例によるＩＳＯ  ｂａｓｅ  ｍｅｄｉａ  ｆｏｒｍａｔ（以下、ＩＳＯ  ＢＭＦＦ）を基盤にするメディアファイルフォーマットを示す図である。
【１４５８】
図９７に示したように、メディアファイルフォーマットは一般に一つのｆｔｙｐと一つまたはそれ以上のｍｏｏｖ、ｍｏｏｆ及びｍｄａｔを含む。
【１４５９】
ｆｔｙｐはメディアファイルのタイプ及び適合性を示す。ｆｔｙｐはメディアファイルでできるだけ前に位置する。
【１４６０】
ｍｏｏｖは全てのメディアデータのためのコンテナである。詳しくは、プレゼンテーションのシングルトラック（ｔｒａｃｋ）のためのコンテナボックスである。プレゼンテーションは一つまたはそれ以上のトラックで構成される。それぞれのトラックはプレゼンテーション内で他のトラックとは独立している。一実施例において、トラックはメディアデータを含み、他の実施利例において、トラックはパケッタイジングされたストリーミングプロトコールのための情報を含む。
【１４６１】
ｍｄａｔはメディアデータのコンテナであり、ｍｏｏｆはｍｄａｔのための情報を含んでいる。
【１４６２】
図９８は、本発明の一実施例によるパケットペイロードのペイロードヘッダの構成を示す図である。
【１４６３】
現在、リアルタイム伝送プロトコールは殆どメディアファイルのアクセスユニットなどを基盤に伝送している。詳しくは、アクセスユニットとはメディアファイルまたはデータを伝送する最小単位を意味する。よって、メディアファイルフォーマット基盤のデータをリアルタイムで伝送する方案に関する考慮が不十分なことろがある。
【１４６４】
本発明の一実施例による放送伝送装置は、一つの伝送パケットに含まれたペイロードを介して一つのファイルファーマット基盤のメディアデータを伝送する。この場合、伝送パケットはシングルユニットパケット（ｓｉｎｇｌｅ  ｕｎｉｔ  ｐａｃｋｅｔ）であるといえる。他の実施例において、放送伝送装置は一つの伝送パケットに含まれたペイロードを介して複数のファイルフォーマット基盤のメディアデータを伝送する。この場合の伝送パケットはアグリゲーションパケット（Ａｇｇｒｅｇａｔｉｏｎ  ｐａｃｋｅｔ）であるといえる。また他の実施例による放送伝送装置は一つのファイルフォーマット基盤のメディアデータを様々な伝送パケットに分けて伝送する。この場合の伝送パケットはフラッグメンテッドパケット（Ｆｒａｇｍｅｎｔｅｄ  ｐａｃｋｅｔ）であるといえる。更に他の実施例において、放送伝送装置は一つの伝送パケットのペイロードを介してメディアストリームに関する一つまたは複数のメタデータを伝送する。更に他の実施例において、放送伝送装置は一つのメタデータを複数の伝送パケットのペイロードを介して伝送する。
【１４６５】
また、本発明の一実施例による放送伝送装置は多様なプロトコールを介してメディアデータを伝送する。上述したプロトコールはリアルタイム伝送プロトコール（ｒｅａｌ−ｔｉｍｅ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（ＲＴＰ））、非同期階層化コーディング（ａｓｙｎｃｈｒｏｎｏｕｓ  ｌａｙｅｒｅｄ  ｃｏｄｉｎｇ（ＡＬＤ））及び階層化コーディング伝送（ｌａｙｅｒｅｄ  ｃｏｄｉｎｇ  ｔｒａｎｓｐｏｒｔ（ＬＣＴ））のうち少なくとも一つである。
【１４６６】
詳しくは、放送伝送装置は伝送パケットのヘッダにペイロードタイプに関する情報を示すフィールドを挿入し、該当フィールドを介してペイロード内にファイルフォーマット基盤のメディアデータが含まれていることを示す。例えば、ＲＰＴの場合、ヘッダのＰａｙｌｏａｄ  ｔｙｐｅフィールドがペイロードのデータタイプを示し、該当フィールドに特定値をファイルフォーマット基盤のメディアデータのためのＰａｙｌｏａｄ  ｔｙｐｅ値として割り当てる。そして、この場合ＲＴＰパケットヘッダのＭフィールドは一つのメディアファイルの最後を含むデータがパケットのペイロードに含まれれば１にセッティングされる。
【１４６７】
上述した課題を解決するため、本発明の一実施例によるペイロードヘッダはペイロードが含むデータの上にエラーまたはシンタックスエラーがあるのか否かを示す情報、データの優先順位を示す情報及びデータのタイプを示す情報のうち少なくとも一つを含む。この場合、ペイロードヘッダに含まれたペイロードが含むデータ上のエラーまたはシンタックスエラーを示す情報をＦフィールドという。一実施例において、ペイロードヘッダに含まれたペイロードが含むデータ上のエラーまたはシンタックスエラーを示す情報はｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔであって、ペイロードが含むデータ上にエラーが発生するかシンタックス違反が発生すれば１にセッティングされる。詳しくは、ペイロードヘッダに含まれたペイロードが含むデータ上にエラーまたはシンタックスエラーを示す情報は１ビットである。
【１４６８】
また、この場合ペイロードヘッダに含まれたデータの優先順位を示す情報はＰｒｉｏｒｉｔｙフィールドといえる。一実施例において、データの優先順位を示す情報はペイロードデータの優先順位を示すフィールドである。そして、データの優先順位を示す情報はペイロードデータがメディアファイルフォーマット上で重要なメタデータを含むか否かを示す。
【１４６９】
ＩＳＯ  ＢＭＦＦを例に挙げると、ｆｔｙｐまたはｍｏｏｖなどを含むペイロードデータの場合、データの優先順位を示す情報は最も高い順位にセッティングされる。一実施例において、データの優先順位を示す情報は放送伝送装置の制御部を介して、最も高い優先順位（ｈｉｇｈｅｓｔ）、最も高い優先順位に比べ相対的に低い順位（ｍｅｄｉｕｍ）、最も低い順位（ｌｏｗ）を示す。この場合、データの優先順位を示す情報は最も高い優先順位で０ｘ００、最も高い優先順位に比べ相対的に低い順位で０ｘ０１、そして最も低い順位で０ｘ０２に設定される。上述した設定値は一実施例に過ぎず、他の任意の値に設定されてもよい。
【１４７０】
また、この場合データのタイプを示す情報をＴｙｐｅフィールドという。詳しくは、データのタイプを示す情報を介して放送受信装置１００の制御部１５０は伝送パケットが一つのパケットに一つのデータを伝送するパケットであるのか、一つのパケットで複数の互いに異なるデータを伝送するパケットであるのか、または一つのデータを複数個に分けたデータを伝送するパケットであるのかを識別する。
【１４７１】
また、放送受信装置１００の制御部１５０はデータのタイプを示す情報を介して伝送パケットがコンテンツの時間情報を含むメタデータを伝送するパケットであるのか、伝送パケットがコンテンツの説明情報を含むメタデータを伝送するパケットであるのかを識別する。
【１４７２】
一実施例において、放送伝送装置が一つのパケットで一つのデータを伝送するパケットであればデータのタイプを示す情報を０ｘ００に設定する。また、放送伝送装置は一つのパケットで複数の互いに異なるデータを伝送するパケットであればデータのタイプを示す情報を０ｘ０１に設定する。また、放送伝送装置は一つのデータを分けたデータを伝送するパケットであればデータのタイプを示す情報を０ｘ０２に設定する。
【１４７３】
また、放送伝送装置はメディアデータではなくコンテンツの再生またはデコーティング時間情報を含むメタデータをパケッタイジングして伝送する。この場合、放送伝送装置はデータのタイプを示す情報を０ｘ０３に設定する。一方、上述した時間情報をタイムライン（ｔｉｍｅｌｉｎｅ）データという。
【１４７４】
また、放送伝送装置はコンテンツの説明情報を含むメタデータをパケッタイジングして伝送する。この場合、放送伝送装置ははデータのタイプを示す情報を０ｘ０４に設定する。一方、上述した情報をラベリング（ｌａｂｅｌｉｎｇ）データという。
【１４７５】
しかし、上述した設定値は一実施例に過ぎず、本発明が上述した値に限ることはない。具体的な実施例において、ｔｙｐｅフィールドは５ビットである。
【１４７６】
図９９乃至図１００は、一つのパケットに一つのメディアがパケッタイジングされた伝送パケットのペイロード構成を示す。
【１４７７】
図９９に示したように、一つのパケットに一つのメディアデータが含まれたパケットをシングルユニットパケットという。シングルユニットパケットのペイロードはペイロードヘッダとペイロードデータを含む。ペイロードデータは一つのファイルフォーマット基盤のメディアデータを含むフラグメンテッドデータを含む。一実施例において、伝送プロトコールが固定長さの伝送パケットを使用すれば、ペイロードデータはフラグメンテッドデータ以外にパッディングビットを追加に含む。ここで、パッディングビットとは伝送パケットでデータを詰めてから残った空間を詰めるためのビットをいう。
【１４７８】
図１００は、図９９に示した伝送パケットの具体的な例を示す図である。図１００に示したように、ペイロードヘッダはペイロードが含むデータ上にエラーまたはシンタックスエラーがあるのか否かを示す情報、データの優先順位を示す情報およびデータのタイプを示す情報のうち少なくとも一つを含む。
【１４７９】
図１００に示した一実施例において、ペイロードが含むデータ上にエラーまたはインタックスエラーがあるのか否かを示す情報はエラー及びシンタックスの違反がないとの内容を示す値を含む。具体的な実施例において、該当値は０である。
【１４８０】
データの優先順位を示す情報はペイロードデータ内のメディアファイルがｆｔｙｐなどの重要なデータを含むため最も高い優先順位を有する。上述したように、ｆｔｙｐの場合メディアファイルをシグナリングするための情報を含むため最も高い優先順位を有する。具体的な実施例において、最も高い優先順位を示す値は０ｘ００である。
【１４８１】
データのタイプを示す情報は一つのパケットペイロード内に一つのメディアファイルが全て含まれているためシングルユニットパケットを示す。具体的な実施例において、データのタイプを示す情報は０ｘ００値を有する。追加にメディアファイルの長さと伝送プロトコールに応じてパッディングビットが選択的にペイロードデータに挿入される。
【１４８２】
図１０１乃至図１０２は、一つのパケットに複数の互いに異なるメディアデータがパケッタイジングされた伝送パケットの構成を示す。上述したパケットはアグリゲーションパケットといえる。図１０１に示したように、一つの伝送パケットのペイロードが複数の互いに異なるファイルフォーマット基盤のメディアデータを含む場合、ペイロードデータは複数のアグリゲーションユニットを含む。それぞれのアグリゲーションユニットは互いに異なるファイルフォーマット基盤のメディアデータを含む。追加に伝送プロトコールが固定長さのパケットを使用すればペイロードデータはパッディングビットを含む。
【１４８３】
一実施例において、一つのアグリゲーションユニットはアグリゲーションユニットの長さを示す情報及びアグリゲーションデータのうち少なくとも一つを含む。この場合、アグリゲーションユニットの長さを示す情報をＡｇｇｒｅｇａｔｉｏｎ  ｕｎｉｔ  ｌｅｎｇｔｈフィールドという。具体的な実施例において、アグリゲーションユニットは１６ビットである。また、アグリゲーションユニットデータは一つのファイルが含むデータを示す。
【１４８４】
図１０２はアグリゲーションユニットの構成を示す他の実施例であって、一つのアグリゲーションユニットは図１０１の実施例で追加にアグリゲーションユニット内に含まれたファイルのタイプを示す情報を更に含む。
【１４８５】
アグリゲーションのタイプを示す情報をＡｇｇｒｅｇａｔｉｏｎ  ｕｎｉｔ  ｔｙｐｅフィールドという。具体的な実施例において、放送伝送装置はアグリゲーションタイプを０ｘ００に設定する。
【１４８６】
他の実施例において、アグリゲーションタイプはＭＰＥＧ−ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP））におけるセルフ・イニシアライジングセグメント（Ｓｅｌｆ−ｉｎｉｔｉａｌｉｚｉｎｇ  Ｓｅｇｍｅｎｔ）形態のファイルを該当アグリゲーションユニットが含んでいることを示す。ここで、セルフ・イニシアライジングセグメントは別途のイニシアライジングセグメントなしにイニシアライジングセグメントとメディアセグメントを統合したものである。詳しくは、メディアセグメントとメディアセグメントのメディア形態を含む。具体的な実施例において、この場合、放送伝送装置はアグリゲーションタイプを０ｘ０１に設定する。
【１４８７】
更に他の実施例において、アグリゲーションタイプはＭＰＥＧ−ＤＡＳＨにおけるイニシアライジングセグメント形態のファイルを該当アグリゲーションユニットが含んでいることを示す。ここで、イニシアライジングセグメントはＩＳＯ  ＢＭＦＦに従うフォーマットである。詳しくは、イニシアライジングセグメントはｆｔｙｐ、ｍｏｏｖを含むべきである。そして、ｍｏｏｆを含んではならない。具体的な実施例において、この場合、放送伝送装置はアグリゲーションタイプを０ｘ０２に設定する。
【１４８８】
図１０３乃至図１０９は、一つのメディアデータが複数の伝送パケットに分けられてパケッタイジングされた伝送パケット（以下、フラッグメンテッドパケット）のペイロード構成を示す図である。図１０３は、フラッグメントパケットのペイロード構成の一実施例を示す図である。図１０３に示したように、フラッグメンテッドパケットのペイロードはフラグメンテーションユニット（ｆｒａｇｍｅｎｔａｔｉｏｎ  ｕｎｉｔ）を含む。追加にフラグメンテッドパケットのペイロードは伝送プロトコールが固定長さのパケットを使用する場合、パッディングビットが含まれる。
【１４８９】
一実施例において、フラグメンテーションユニット（ＦＵ）はフラグメンテーションユニットヘッダ（Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｕｎｉｔ  ｈｅａｄｅｒ）及びフラグメンテーションユニットデータ（Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｕｎｉｔ  ｄａｔａ）のうち少なくともいずれか一つを含む。フラグメンテーションユニットデータは一つのファイルフォーマット基盤のメディアデータの一部分を含む。フラグメンテーションユニットデータは一つのファイルフォーマット基盤のメディアデータの一部分を含む。フラグメンテーションユニットヘッダはフラグメンテーションユニットデータの情報を含む。
【１４９０】
詳しくは、フラグメンテーションユニットヘッダはフラグメンテーションユニットデータが全体ファイルのメディアデータのうち開始部分のデータを含んでいるのか否かの情報、フラグメンテーションユニットデータが全体ファイルのメディアデータのうち終了部分のデータを含んでいるのか否かを示す情報、及びフラグメンテーションユニットのタイプを示す情報のうち少なくともいずれか一つを含む。
【１４９１】
一実施例において、全体ファイルのメディアデータのうち開始部分のデータを含んでいるのか否かを示す情報をＳｔａｒｔ  ｂｉｔフィールドという。詳しくは、開始部分のデータは全体メディアデータの最初のビットを含む全体データの一部である。
【１４９２】
例えば、該当ペイロードのフラグメントユニットが開始部分のデータを含んでいる場合、放送伝送装置は全体ファイルのメディアデータのうち開始部分のデータを含んでいるのか否かを示す情報を１に設定する。詳しくは、全体ファイルンのメディアデータのうち開始部分のデータを含んでいるのか否かを示す情報は１ビットである。
【１４９３】
一実施例において、全体ファイルのメディアデータのうち最後の部分のデータを含んでいるのか否かを示す情報をＥｎｄ  ｂｉｔフィールドという。詳しくは、最後の部分のデータは全体メディアデータの最後のビットを含む全体データの一部である。
【１４９４】
例えば、該当ペイロードのフラグメンテーションユニットデータが最後の部分のデータを含んでいる場合、放送伝送装置は全体ファイルのメディアデータのうち最後の部分のデータを含んでいるのか否かを示す情報を１に設定する。詳しくは、全体ファイルのメディアデータのうち最後の部分のデータを含んでいるのか否かを示す情報は１ビットである。
【１４９５】
一実施例において、フラグメンテーションユニットのタイプを示す情報はフラグメンテーションユニットタイプフィールドという。
【１４９６】
一実施例において、フラグメンテーションユニットタイプは該当パケットがファイルフォーマット基盤の基本的なファイルをフラグメンテーションユニットが含んでいることを示す。詳しくは、ファイルフォーマット基盤の基本的なファイルはＩＳＯ  ＢＭＦＦを基盤にするファイルフォーマットを有するメディアファイルである。具体的な実施例において、放送伝送装置はフラグメンテーションユニットタイプを０ｘ００に設定する。
【１４９７】
他の実施例において、フラグメンテーションユニットタイプはＭＰＥＧ−ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP））におけるセルフ・イニシアライジングセグメント形態のファイルを該当フラグメンテーションユニットが含んでいることを示す。具体的な実施例において、この場合、放送伝送装置はフラグメンテーションユニットタイプを０ｘ０１に設定する。
【１４９８】
更に他の実施例において、フラグメンテーションユニットタイプはＭＰＥＧ−ＤＡＳＨにおけるイニシアライジングセグメント形態のファイルを該当フラグメンテーションユニットが含んでいることを示す。具体的な実施例において、この場合、放送伝送装置はフラグメンテーションユニットタイプを０ｘ０２に設定する。
【１４９９】
更に他の実施例において、フラグメンテーションユニットタイプはＭＰＥＧ−ＤＡＳＨにおけるメディアセグメント形態のファイルを該当フラグメンテーションユニットが含んでいることを示す。具体的な実施例において、この場合、放送伝送装置はフラグメンテーションユニットタイプを０ｘ０３に設定する。
【１５００】
詳しくは、フラグメンテーションユニットタイプを示す情報は６ビットである。
【１５０１】
図１０４は、フラグメンテッドパケットのペイロード構成の他の実施例を示す図である。図１０４の実施例は伝送パケットのヘッダに伝送パケットの順番に関する情報が存在しない場合に適用される。
【１５０２】
図１０４に示したように、フラグメンテーションユニット（ＦＵ）に含まれたフラグメンテーションユニットヘッダはフラグメンテーションユニットデータが全体ファイルのメディアデータのうち開始部分のデータを含んでいるのか否かの情報、フラグメンテーションユニットデータが全体ファイルのメディアデータのうち終了部分のデータを含んでいるのか否かを示す情報、及びフラグメンテーションユニットのタイプを示す情報、及びフラグメンテーションユニットが全体データにおける順番を示す情報のうち少なくともいずれか一つを含む。上述した情報のうちフラグメンテーションユニットの順番を示す情報を除く残りの情報は図１０３で説明した通りである。
【１５０３】
フラグメンテーションユニットの順番を示す情報はＦｒａｇｍｅｎｔａｔｉｏｎ  ｎｕｍｂｅｒフィールドという。詳しくは、放送伝送装置はファイルフォーマット基盤のメディアデータが複数のフラッグメンテッドパケットに分けられた場合、フラグメンテーションユニットの順番を示す情報に値を設定して該当パケットの順番を割り当てる。詳しくは、Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｎｕｍｂｅｒフィールドは８ビットである。
【１５０４】
図１０５は、本発明の一実施例において、放送伝送装置がＩＳＯ  ＢＭＦＦ基盤のメディアファイルをフラグメンテーションして複数個のパケットに分けることを示す図である。図１０５に示したように、ＩＳＯ  ＢＭＦＦ基盤のメディアファイルはｆｔｙｐ、ｍｏｏｖと複数のｍｏｏｆ及びｍｄａｔを含む。
【１５０５】
放送伝送装置はＩＳＯ  ＢＭＦＦ基盤のメディアファイルを複数個に分けてそれぞれ異なるフラグメンテーションユニットデータに含ませる。また、放送伝送装置はＩＳＯ  ＢＭＦＦ基盤のメディアファイルを分けながらペイロードヘッダに関する情報を含ませる。
【１５０６】
図１０６は、図１０５の放送伝送装置はパケッタイジングした第１フラグメンテーションユニットデータの具体的な実施例を示す図である。
【１５０７】
図１０６に示したように、本発明の一実施例において、放送伝送装置はペイロードのＦフィールドを該当パケットにエラーまたはシンタックスのエラーがないと判断して０に設定する。
【１５０８】
また、放送伝送装置はＰｒｉｏｒｉｔｙフィールドを最も高い優先順位を示す値に設定する。詳しくは、該当値は０ｘ００である。
【１５０９】
また、放送伝送装置はＴｙｐｅフィールドを該当パケットが一つのファイルフォーマット基盤のメディアファイルを様々なペイロードに分けて伝送するパケットを示す値に設定する。詳しくは、該当値は０ｘ０２である。
【１５１０】
ペイロードデータはフラグメンテーションユニットを含み、更にフラグメンテーションユニットはＳｔａｒｔ  ｂｉｔフィールド、フラグメンテーションユニットタイプフィールド及びフラグメンテーションユニットデータフィールドを含む。
【１５１１】
放送伝送装置はＳｔａｒｔ  ｂｉｔフィールドを該当パケットがメディアファイルの開始データを含む内容を示す値に設定する。詳しくは、図１０５において第１フラグメンテーションユニットがメディアデータの開始データを含むため、放送伝送装置は該当内容を示す値をＳｔａｒｔ  ｂｉｔフィールドに設定する。
【１５１２】
一方、放送伝送装置は図１０６で例示したように第１フラグメンテーションユニットのＥｎｄ  ｂｉｔフィールドをメディアファイルの最後の部分のデータを含んでいないとの内容を示す値に設定する。具体的な実施例において、放送伝送装置は該当パケットがメディアファイルの最後の部分のデータを含んでいないとの内容を示すためにＥｎｄ  ｂｉｔフィールドを０に設定する。
【１５１３】
一方、放送伝送装置は図１０６で例示したように第１フラグメンテーションユニットがファイルフォーマット基盤の基本的な形態のファイルを含んでいるとの内容をフラグメンテーションユニットタイプフィールドに設定する。詳しくは、ファイルフォーマット基盤の基本的な形態とは、ＩＳＯ  ＢＭＦＦに従うファイルフォーマットデータである。具体的な実施例において、放送伝送装置はフラグメンテーションユニットタイプフィールドを０ｘ００に設定し該当内容を示す。
【１５１４】
図１０７乃至図１０９は、図１０５のフラグメンテーションユニットデータのうち開始データを除く残りのデータを含むフラグメンテーションユニットの一実施例を示す図である。
【１５１５】
図１０７に示したように、本発明の一実施例において、放送伝送装置はペイロードヘッダのＦフィールドを該当パケットにエラーまたはシンタックスエラーがないことを示す値に設定する。具体的な実施例において、放送伝送装置はＦフィールドを０に設定する。また、放送伝送装置は図１０７に示したペイロードデータが相対的に低い優先順位を示すことを示す値としてＰｒｉｏｒｉｔｙフィールドを設定する。
【１５１６】
具体的な実施例において、第２フラグメンテーションユニットからは全体メディアデータをシグナリングするデータを含まない可能性がある。よって、第１フラグメンテーションユニットより優先順位が相対的に低いため、Ｐｒｉｏｒｉｔｙフィールドが相対的に低い優先順位を有する値に設定される。例えば、該当値は０ｘ０１である。
【１５１７】
また、放送伝送装置はＴｙｐｅフィールドを該当パケットが一つのファイルフォーマット基盤のメディアファイルを様々なペイロードに分けて伝送するパケットを示すＦｒａｇｍｅｎｔｅｄ  ｐａｃｋｅｔとして０ｘ０２に設定する。図１０８は、ペイロードデータが開始データを含むフラグメンテーションユニットデータ及び最後のデータを含むフラグメンテーションユニットデータを含まない場合のペイロード構成を示す。
【１５１８】
本発明の一実施例において、放送伝送装置は図１０８のフラグメンテーションユニットデータが開始データ及び最後のデータを含んでいないため、Ｓｔａｒｔ  ｂｉｔフィールド及びＥｎｄ  ｂｉｔフィールドを該当情報を示す値として設定する。具体的な実施例において、放送伝送装置はＳｔａｒｔ  ｂｉｔ及びＥｎｄ  ｂｉｔフィールドを全て０に設定する。
【１５１９】
また、放送伝送装置はフラグメンテーションユニットタイプフィールドを特定値に設定する。詳しくは、ファイルフォーマット基盤の基本的な形態とは、ＩＳＯ  ＢＭＦＦに従うファイルフォーマットデータである。具体的な実施例において、放送伝送装置はフラグメンテーションユニットタイプフィールドを０ｘ００に設定し該当内容を示す。パケットに分けられたそれぞれのファイルフォーマット基盤のメディアデータは全体ファイルで固有の順番を有する。放送受信装置１００は制御部１５０を介して分けられたフラグメンテーションユニットデータが全体データのうち開始部分を含むことをＳｔａｒｔ  ｂｉｔフィールドに基づいて識別する。また、フラグ面でーションユニットデータが全体データのうち最後の部分を示すことをＥｎｄ  ｂｉｔフィールドに基づいて識別する。しかし、Ｓｔａｒｔ  ｂｉｔフィールド及びＥｎｄ  ｂｉｔフィールドのみでは識別が不可能な場合がある。
【１５２０】
フラグメンテーションユニットデータが全体データのうち開始データまたは最後のデータを含んでいない場合、放送受信装置１００は一実施例においてペイロードに含まれたフラグメンテーションユニットデータの順番を示す情報を介して該当パケットを識別する。詳しくは、フラグメンテーションユニットデータの順番を示す情報はフラグメンテーションナンバーフィールドである。マタ、放送伝送装置は該当フラグメンテーションユニットデータの順番を上述したフラグメンテーションフィールドに設定する。
【１５２１】
しかし、他の実施例において、伝送パケットはフラグメンテーションユニットデータの順番情報を含まなくてもよい。この場合、一実施例において、放送伝送装置はパケットヘッダにフラグメンテーションユニットデータの順番を識別するための情報を挿入する。パケットヘッダに含まれたフラグメンテーションユニットデータの順番を識別するための情報はシーケンスナンバーフィールドである。他の実施例において、放送伝送装置はＩＰデータグラムのオフセット情報にフラグメンテーションユニットデータの順番を識別するための情報を挿入してもよい。
【１５２２】
図１０９は、分けられた全体メディアのうち最後のデータを含むフラグメンテーションユニットを含むペイロードの構成を示す図である。詳しくは、図１０９はペイロードデータが開始データを含むフラグメンテーションユニットデータを含まないが、最後のデータを含むフラグメンテーションユニットデータを含む場合のペイロード構成を示す。
【１５２３】
本発明の一実施例において、放送伝送装置はず５８のフラグメンテーションユニットデータが最後のデータを含んでいるため、Ｓｔａｒｔ  ｂｉｔフィールド及びＥｎｄ  ｂｉｔフィールドを該当情報を示す値として設定する。具体的な実施例において、放送伝送装置はＳｔａｒｔ  ｂｉｔフィールドを０に設定する。そして、放送伝送装置はＥｎｄ  ｂｉｔフィールドを１に設定する。
【１５２４】
また、放送伝送装置はフラグメンテーションユニットタイプフィールドを該当パケットが含むメディアデータがＩＳＯ  ＢＭＦＦ基盤のｆｔｙｐから始まる基本的な形態のファイルを含む内容を示すように設定する。具体的な実施例において、放送伝送装置はフラグメンテーションユニットタイプフィールドを０ｘ００に設定する。
【１５２５】
放送伝送地が伝送パケットを介して伝送するデータは上述したメディアデータと共にメタデータ（ｍｅｔａｄａｔａ）がある。メタデータはメディアデータを提供するために必要な付加情報を示す。以下、図１０７乃至図１１７ではメタデータを伝送パケットにパケッタイジングして伝送及び受信する放送伝送装置は、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提案する。
【１５２６】
また、以下ではメタデータの一例としてタイムライン情報を中心に説明する。タイムライン情報とはメディアコンテンツのための一連の時間情報である。詳しくは、タイムライン情報は再生またはデコーディングするための一連の時間情報である。
【１５２７】
また、タイムラインの情報は基本タイムライン（Ｂａｓｅ  ｔｉｍｅｌｉｎｅ）情報を含む。基本タイムラインとは、複数の互いに異なる伝送網を介して伝送されるメディアデータを同期化するために必要な基準タイムラインを意味する。詳しくは、第１伝送網を介して伝送されるメディアデータのタイムラインに第２伝送網を介して伝送されるメディアデータのタイムラインをマッピングする場合、第１伝送網を介して伝送されるメディアデータのタイムラインが基本タイムラントなる。
【１５２８】
一方、放送伝送装置はメタデータをＸＭＬのフォーマットで表現する。また、放送伝送装置はメタデータをシグナリングテーブルに含まれるデスクリプタの形態に表現してもよい。
【１５２９】
図１１０は、本発明の一実施例によるメタデータのタイムラインシグナリングテーブルを示す図である。
【１５３０】
本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインに関するメタデータであることを示す情報または該当マタデータがタイムラインコンポーネントアクセスユニット（ｔｉｍｅｌｉｎｅ  ｃｏｍｐｏｎｅｎｔ  ａｃｃｅｓｓ  ｕｎｉｔ）構造を含んでいることを示す情報を含む。上述した情報をｉｄｅｎｔｉｆｉｅｒフィールドという。具体的な実施例において、ｉｄｅｎｔｉｆｉｅｒフィールドは８ビットである。
【１５３１】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットのタイムライン情報の長さを示す情報を含む。上述した情報をＡＵ＿ｌｅｎｇｔｈフィールドという。具体的な実施例において、ＡＵ＿ｌｅｎｇｔｈフィールドは３２ビットである。
【１５３２】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットに関するサービス及びコンテンツコンポーネントに関する位置情報を含んでいるのか否かを示す情報を含む。上述した情報をｌｏｃａｔｉｏｎ＿ｆｌａｇフィールドという。具体的な実施例において、ｌｏｃａｔｉｏｎ＿ｆｌａｇフィールドは１ビットである。
【１５３３】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットが含むタイムスタンプのバージョン情報を含む。タイムスタンプとは連続したタイムラインで該当アクセスユニットが出力されるべき時間情報を示す。上述した情報をｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドという。具体的な実施例において、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドは１ビットである。
【１５３４】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットのタイムスタンプのタイプ情報を含む。上述した情報をｌｏｃａｔｉｏｎ＿ｔｙｐｅフィールドという。
【１５３５】
一実施例において、タイムラインコンポーネントアクセスユニットに関するサービスまたはコンテンツコンポーネントのデコーディング時点を示す値が設定される。詳しくは、コンテンツコンポーネントのデコーティング時点はデコーティングタイムスタンプ（ｄｅｃｏｄｉｎｇ  ｔｉｍｅｓｔａｍｐ）という。具体的な一実施例において、放送伝送装置はタイムスタンプのタイプ情報を該当情報がデコーディング時点を示せば０ｘ００に設定する。
【１５３６】
他の実施例において、タイムラインコンポーネントアクセスユニットに関するサービスまたはコンテンツコンポーネント再生時点を示す値が設定される。詳しくは、コンテンツコンポーネントの再生時点はプレゼンテーションタイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅｓｔａｍｐ）という。具体的な一実施例において、放送伝送装置はタイムスタンプのタイプ情報を該当情報がプレゼンテーション時点を示せば０ｘ０１に設定する。
【１５３７】
一方、具体的な実施例において、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドは１ビットである。
【１５３８】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットのタイムラインスタンプフォーマット情報を含む。上述した情報をｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドという。
【１５３９】
一実施例において、タイムスタンプフォーマット情報はタイムラインコンポーネントアクセスユニットが含むタイムスタンプがメディアタイム（Ｍｅｄｉａ  ｔｉｍｅ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ００に設定して該当アクセスユニットのタイムスタンプフォーマットがメディアタイムフォーマットであることを示す。
【１５４０】
他の実施例において、タイムスタンプフォーマット情報はタイムラインコンポーネントアクセスユニットに含まれたタイムスタンプがネットワークタイムプロトコール（ｎｅｔｗｏｒｋ  ｔｉｍｅ  ｐｒｏｔｏｃｏｌ（ＮＴＰ））のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０１に設定して該当アクセスユニットのタイムスタンプフォーマットがＮＴＰフォーマットであることを示す。
【１５４１】
また他の実施例において、タイムスタンプフォーマット情報はタイムラインコンポーネントアクセスユニットが含むタイムスタンプがプレシジョンタイムプロトコール（ｐｒｅｃｉｓｉｏｎ  ｔｉｍｅ  ｐｒｏｔｏｃｏｌ（ＰＴＰ））のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０２に設定して該当アクセスユニットのタイムスタンプフォーマットがＰＴＰフォーマットであることを示す。
【１５４２】
更に他の実施例において、タイムスタンプフォーマット情報はタイムラインコンポーネントアクセスユニットが含むタイムスタンプがタイムコード（ｔｉｍｅｃｏｄｅ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０３に設定して該当アクセスユニットのタイムスタンプフォーマットがタイムコードフォーマットであることを示す。一方、具体的な実施例において、ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールド４ビットである。
【１５４３】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットが含む情報に関するサービスまたはコンテンツのコンポーネントに関する位置情報を含む。上述した情報をｌｏｃａｔｉｏｎフィールドという。
【１５４４】
また、本発明の一実施例において、タイムラインシグナリングテーブルは上述した位置情報の長さを示す情報を含む。位置情報の長さを示す情報をｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈフィールドという。具体的な実施例において、ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈフィールド８ビットである。
【１５４５】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインマッチングの基準になり得る基本タイムラインのタイムスタンプフォーマットバージョン情報を含む。上述した情報をｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドという。
【１５４６】
一実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが０に設定されればタイムスタンプフォーマットが３２ビットのフォーマットを有することを示す。他の実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが１に設定されればタイムスタンプフォーマットが６４ビットのフォーマットを有することを示す。
【１５４７】
また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムラインのタイムスタンプタイプ情報を含む。上述した情報をｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドという。
【１５４８】
一実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドは基本タイムラインに関するサービスまたはコンテンツコンポーネントのデコーディング時点を示す値が設定される。詳しくは、コンテンツコンポーネントのデコーディング時点はデコーティングタイムスタンプ（ｄｅｃｏｄｉｎｇ  ｔｉｍｅｓｔａｍｐ）という。具体的な一実施例において、放送伝送装置は該当情報がデコーディング時点を示す場合、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドを０ｘ００に設定する。
【１５４９】
他の実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドは基本タイムラインに関するサービスまたはコンテンツコンポーネントの再生時点を示す値が設定される。詳しくは、コンテンツコンポーネントの再生時点はプレゼンテーションタイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅｓｔａｍｐ）という。具体的な一実施例において、放送伝送装置は該当情報がプレゼンテーション時点を示す場合、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールド０ｘ０１に設定する。
【１５５０】
本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムラインに対するタイムスタンプフォーマット情報を含む。上述した情報をｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドという。
【１５５１】
一実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａフィールドは基本タイムラインのタイムスタンプがメディアタイムのフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａフィールドを０ｘ００に設定して該当基本タイムラインのタイムスタンプフォーマットがメディアタイムフォーマットであることを示す。
【１５５２】
他の実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａフィールドは基本タイムラインのタイムスタンプがネットワークタイムプロトコール（ＮＴＰ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａフィールドを０ｘ０１に設定して該当基本タイムラインのタイムスタンプフォーマットがＮＴＰフォーマットであることを示す。
【１５５３】
また他のの実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａフィールドは基本タイムラインのタイムスタンプがプレシジョンタイムプロトコール（ＰＴＰ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０２に設定して該当基本タイムラインのタイムスタンプフォーマットがＰＴＰフォーマットであることを示す。
【１５５４】
更に他のの実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａフィールドは基本タイムラインのタイムスタンプがタイムコード（ｔｉｍｅｃｏｄｅ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０３に設定して該当基本タイムラインのタイムスタンプフォーマットがタイムコードフォーマットであることを示す。
【１５５５】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインマッチングの基準になり得る基本タイムラインに関するサービス及びコンテンツコンポーネントの位置情報を含んでいるのか否かを含む情報を含む。上述した情報をｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇフィールドという。一実施例において、ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇフィールドが０以外の値に設定される場合、ｔｉｍｅｌｉｎｅ  ＡＵはｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈールド及びｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎフィールドのうち少なくともいずれか一つを含む。
【１５５６】
また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムラインに関するサービスまたはコンテンツに対する位置情報を含む。上述した情報をｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎフィールドという。具体的な一実施例において、ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎフィールドに含まれる情報はＩＰアドレス、ポートナンバーまたはＵＲＩの形態である。
【１５５７】
また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムラインに関するサービス及びコンテンツに対する位置情報の長さの情報を含む。上述した情報をｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈフィールドという。具体的な一実施例において、ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈフィールドは８ビットである。
【１５５８】
また、本発明の一実施例において、タイムラインシグナリングテーブルはマッピングの基本になる基本タイムラインがメディアタイムの形態であれば、使用可能なタイムスケール（ｔｉｍｅ  ｓｃａｌｅ）の情報を含む。上述した情報をｏｒｉｇｉｎ＿ｔｉｍｅｓｃａｌｅフィールドという。例えば、ＭＰＥＧ−２  ＴＳの場合、タイムスケールは９０００Ｈｚを示す。具体的な一実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｃａｌｅフィールドは３２ビットである。
【１５５９】
また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムライン上のメディアタイム情報を含む。上述した情報をｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅフィールドという。一方、ｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅフィールドはｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドに応じてその意味が異なり得る。他とば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドがＰＴＳを意味すればｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅフィールドは再生時点を示す。他の例として、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドがＤＴＳを意味すればｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅフィールドはデコーディング時点を示す。具体的な一実施例において、ｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅフィールドはｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが０に設定されれば３２ビットであり、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが１に設定されれば６４ビットである。
【１５６０】
また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムラインタイムスタンプ情報を含む。上述した情報をｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐフィールドという。基本タイムラインタイムスタンプ情報はｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドの値に応じて互いに異なるフォーマットのタイムスタンプを示す。また、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドの値に応じて基本タイムラインタイムスタンプ情報が互いに異なる意味を示す。例えば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドがＰＴＳをシグナリングすれば基本タイムラインタイムスタンプ情報は再生時間を示す。
【１５６１】
例えば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドがＤＴＳを示し、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドが０ｘ０１であれば、該当ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドはＮＴＰで表現されたデコーディング時点を示す。具体的な一実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐフィールドはｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが０であれば３２ビットであり、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが１であれば６４ビットである。
【１５６２】
一実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドがｒｅｓｅｒｖｅｄを示す場合、ｔｉｍｅｌｉｎｅ  ＡＵはｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールド及びｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ（）フィールドのうち少なくとも一つを含む。
【１５６３】
ｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドはｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ（）フィールドのバイト単位の長さを示す。具体的な一実施例において、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドは１６ビットである。
【１５６４】
ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ（）フィールドはｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドが示す長さだけｐｒｉｖａｔｅｌｙを定義するか、後に拡張内容を含む。
【１５６５】
図１１１は、伝送パケットのペイロードデータに一つのメタデータがパケット化されたペイロードデータの構成を示す図である。一実施例において、ペイロードデータはメタデータを含み、メタデータはメディアストリーム関連タイムラインデータを含む。また、一実施例において、放送伝送装置が伝送プロトコールに固定長さのパケットを含めばペイロードデータはパディングデータを追加に含む。
【１５６６】
図１１２は、伝送パケットのペイロードデータがタイムラインに対するメタデータを含む場合の実施例を示す図である。
【１５６７】
図１１２に示したように、一実施例において、ペイロードヘッダはＦフィールド、Ｐｒｉｏｒｉｔｙフィールド及びＴｙｐｅフィールドのうち少なくとも一つを含む。
【１５６８】
一実施例において、放送伝送装置はＦフィールドをペイロード内にエラーが存在せずｓｙｎｔａｘの違反もないことを示す値に設定する。詳しくは、放送伝送装置はＦフィールドを０に設定する。また、放送伝送装置はＰｒｉｏｒｉｔｙフィールドをペイロードデータがメディアファイル構成の重要なデータを全て含むため、最も高い優先順位を示す値に設定する。詳しくは、放送伝送装置はＰｒｉｏｒｉｔｙフィールドを０ｘ００に設定する。また、放送伝送装置はＴｙｐｅフィールドをペイロード内にタイムライン情報のメタデータを含む情報を示す値に設定する。詳しくは、放送伝送装置はＴｙｐｅフィールドを０ｘ０３に設定する。また、メタデータは図１１０のシンタックスを含む。
【１５６９】
図１１３は、一つの伝送パケットに多数のメタデータがパケット化された場合を示す図である。
【１５７０】
図１１３に示したように、一つの伝送パケットが多数のメタデータを含む場合イをアグリゲーションパケットという。一実施例において、ペイロードデータは複数のアグリゲーションユニットを含む。
【１５７１】
一実施例において、アグリゲーションユニットはメタデータの長さを示す情報を含む。他の実施例において、アグリゲーションユニットはメタデータヘッダフィールドが別途に存在する場合、メタデータヘッダフィールド及びメタデータフィールドの長さの合計を示す情報を含む。上述した情報はｍｅｔａｄａｔａ  ｌｅｎｇｔｈフィールドという。
【１５７２】
図１１４は、一つの伝送パケットが多数個のタイムライン情報を含む場合を示す図である。詳しくは、一つのメディアストリームに関してそれぞれの基準が異なる複数個のタイムライン情報を一つの伝送パケットが含んでいる場合を示す。一実施例において、伝送パケットはペイロードパケットを含むが、ペイロードヘッダの内容は図１１３の内容のようである。
【１５７３】
また、一実施例において、ペイロードデータは２つのアグリゲーションユニットを含む。しかし、ペイロードデータが含むアグリゲーションユニットの個数は２つ以上であってもよい。
【１５７４】
一実施例において、それぞれのアグリゲーションユニットは図１１３に示したようにｍｅｔａｄａｔａ  ｌｅｎｇｔｈフィールド、ｍｅｔａｄａｔａ  ｈｅａｄｅｒフィールド及びタイムライン情報を含むメタデータフィールドのうち少なくともいずれか一つを含む。
【１５７５】
しかし、図１１４に示した第１アグリゲーションユニットは第１タイムラインを含むメタデータフィールドを含み、第２アグリゲーションユニットは第２タイムラインを含むメタデータフィールドを含む。具体的な実施例において、タイムラインは互いに異なる基準に基づくデータを有する。例えば、第１タイムラインはメディアタイムラインに基づくデータを有し、第２タイムラインはＮＴＰに基づくデータを有する。
【１５７６】
図１１５は、一つのメタデータを複数個の伝送パケットに分けてパケット化したパケットペイロードを示す図である。
【１５７７】
一実施例において、一つのメタデータの長さが伝送パケットの長さより長いことがあるが、この場合、放送伝送装置は該当メタデータを様々な伝送パケットに分けて伝送する。図１１５に示したように、伝送パケットはペイロードヘッダ、メタデータフラッグメントヘッダ及びメタデータフラッグメントのうち少なくとも一つを含む。追加に伝送プロトコールが固定長さのパケットを使用する場合、伝送パケットはパッディングビットを含んでもよい。
【１５７８】
図１１５に示したように、一実施例において、メタデータフラッグメントヘッダは該当伝送パケットの該当伝送パケットのペイロードデータに含まれたメタデータフラッグメントが全体メタデータの開始部分を含んでいるのか否かを示す情報を含む。詳しくは、開始部分のデータは全体メディアデータの最初のビットを含む全体データの一部である。上述した情報はｓｔａｒｔ  ｂｉｔフィールドという。具体的な実施例において、ｓｔａｒｔ  ｂｉｔフィールド１ビットである。一実施例において、放送伝送装置は該当伝送パケットが含んでいるメタデータフラッグメントが全体のメタデータの開始部分を含んでいる場合にｓｔａｒｔ  ｂｉｔフィールドを１に設定する。
【１５７９】
他の一実施例において、メタデータフラッグメントヘッダは該当伝送パケットの該当伝送パケットのペイロードデータに含まれたメタデータフラッグメントが全体メタデータの終了部分を含んでいるのか否かを示す情報を含む。詳しくは、終了部分のデータは全体メディアデータの最後のビットを含む全体データの一部である。上述した情報はｅｎｄ  ｂｉｔフィールドという。具体的な実施例において、ｅｎｄ  ｂｉｔフィールド１ビットである。一実施例において、放送伝送装置は該当伝送パケットが含んでいるメタデータフラッグメントが全体のメタデータの終了部分を含んでいる場合にｅｎｄ  ｂｉｔフィールドを１に設定する。
【１５８０】
また他の実施例において、メタデータヘッダはメタデータタイプを示す情報を含む。上述した情報はｍｅｔａｄａｔａ  ｔｙｐｅフィールドという。具体的な実施例において、メタデータタイプが該当メタデータフラッグメントがタイムライン情報を含んでいることを示す。この場合、放送伝送装置はｍｅｔａｄａｔａ  ｔｙｐｅフィールドを０ｘ００に設定する。他の実施例において、メタデータタイプは該当メタデータフラッグメントがラベリング関連メタデータを含んでいることを示す。この場合、放送伝送装置はｍｅｔａｄａｔａ  ｔｙｐｅフィールドを０ｘ０１に設定する。また、具体的な実施例において、ｍｅｔａｄａｔａ  ｔｙｐｅフィールドは５ビットである。
【１５８１】
図１１６は、メタデータフラグメントヘッダの他の実施例を示す図である。ここで、図１１５と同じ部分の説明は省略する。
【１５８２】
本発明の一実施例において、フラッグメントヘッダは該当パケットペイロードに含まれたメタデータフラッグメントの順番を示す情報を含む。上述した情報はｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒという。放送受信装置１００はパケットペイロードに含まれたメタデータフラッグメント順番情報に基づいて該当パケットが何番目のメタデータを含んでいるのかを判断する。
【１５８３】
図１１７は、本発明の一実施例による放送受信装置が放送パケットを受信する動作を示す図である。
【１５８４】
放送受信装置１００の制御部１５０は図９４のＳ２０５でペイロードに含まれたデータがメディアデータではないと判断した場合、一つの伝送パケットに全体のメタデータが含まれているのか否かを判断するＳ３０１。詳しくは、制御部１０５はペイロードヘッダ情報からペイロードに含まれたデータがメディアデータではなくメタデータであることを判断する。そして、制御部１５０は該当メタデータの全体が一つの伝送パケットに全て含まれて伝送されたのか否かを判断する。上述したように一つの伝送パケットに一つまたは複数の互いに異なるメタデータが含まれる。または、一つのメタデータが分けられて複数の互いに異なる伝送パケットに含まれる。
【１５８５】
本発明の一実施例において、放送受信装置１００の制御部１５０が一つの伝送パケットに全体のメタデータが含まれていると判断した場合、制御部１５０は一つのパケットペイロードからメタデータを抽出するＳ３０３。詳しくは、制御部１５０はペイロードヘッダを抽出し、抽出したペイロードに基づいてメタデータを抽出する。一実施例において、制御部１５０は一つのパケットペイロードから一つのメタデータを抽出する。他の実施例において、制御部１５０は一つのパケットペイロードから複数のメタデータを抽出してもよい。本発明のまた他の実施例において、放送受信装置１００の制御部１５０が一つのメタデータが複数の伝送パケットに分けられて含まれていると判断することがある。この場合、制御部１５０は複数のパケットペイロードからメタデータを抽出するＳ３０５。具体的な実施例において、一つのメタデータが複数の伝送パケットに分けられてパケット化される。放送受信装置１００の制御部１５０はパケットペイロードからメタデータシグナリングデータを獲得する。そして、制御部１５０は獲得したシグナリングデータに基づいて複数のパケットペイロードからメタデータを抽出する。
【１５８６】
放送受信装置１００の制御部１５０は抽出したメタデータに基づいてコンテンツを提供するＳ３０７。具体的な一実施例において、制御部１５０はメタデータからコンテンツの再生またはデコーティング時間情報を獲得する。また他の実施例において、制御部１５０はメタデータからコンテンツを説明する情報を獲得してもよい。
【１５８７】
図１１８は、放送網を介してはＲＴＰプロトコールを利用してビデオストリームを伝送し、インターネット網を介してはファイルフォーマット基盤のメディアデータを利用してビデオストリームを伝送する場合を示す図である。この場合、放送受信装置１００はタイムライン関連メタデータを含むＲＴＰパケット或いはＩＰ／ＵＤＰパケットを受信した後、ＲＴＰプロトコール基盤のオーディオストリームとＤＡＳＨ基盤のビデオストリーム間のタイムラインをマッチングして関連するストリーム間の復号化及び再生を可能にする。
【１５８８】
上述したように、従来の放送伝送装置は伝送パケットに含まれたデータ（またはオブジェクト）の再生に関する時間情報をペイロードに載せて伝送していた。または放送伝送装置は時間情報を伝送するための別途のシグナリングを伝送していた。従来のような方法の場合、別途の伝送パケットまたはパケットペイロードに時間情報を載せるためパケットヘッダの容量または伝送パケットの容量が相対的に小さくなる長所があった。しかし、従来の方法の場合、伝送しようとするデータと別途のパケットで時間情報を伝送するため正確で迅速な同期画面では効率が落ちることがあった。
【１５８９】
一方、本発明の実施例ではリアルタイムのコンテンツを支援するための伝送パケットのパケットヘッダにパケットデコーティングまたは再生に関する時間情報を含ませる。よって、該当パケットの時間情報が該当パケットのヘッダに含まれているため、従来の方法に比べ相対的に正確で迅速な同期化が可能になる。特に、本発明の一実施例では上述したデコーディングまたは再生に関する時間情報をパケットヘッダ内の拡張されたヘッダ（Ｅｘｔｅｎｄｅｄ  Ｈｅａｄｅｒ）に設定して伝送パケットをパケット化する内容を提案する。ここで、拡張されたヘッダは必須ではないが、容量変換が可能な選択的なヘッダフィールドを含むパケットヘッダの一部であってもよい。また、伝送パケットはオブジェクトに基づいて生成され、よって、オブジェクトは伝送パケットを介して伝送しようとする対象になり得る。オブジェクトはセッションに含まれて伝送されてもよい。
【１５９０】
図１１９は、本発明の一実施例による伝送パケットの構成を示す図である。図１１９に示した伝送パケットは信頼性のあるデータ伝送を支援する伝送プロトコールを利用する。具体的な実施例において、信頼性のあるデータ伝送プロトコールは非同期階層化コーディング（ＡＬＣ）である。他の実施例において、信頼性のあるデータ伝送プロトコールは階層化コーディング伝送（ＬＣＴ）である。
【１５９１】
本発明の一実施例によるパケットヘッダパケットのバージョン情報を含む。詳しくは、該当伝送プロトコールを利用する伝送パケットのバージョン情報を含む。具体的な実施例において、上述した情報はＶフィールドである。また、Ｖフィールドは４ビットである。
【１５９２】
また、本発明の一実施例によるパケットヘッダは、混雑制御（ｃｏｎｇｅｓｔｉｏｎ  ｃｏｎｔｒｏｌ）のための情報の長さに関する情報を含む。詳しくは、混雑制御のための情報の長さと混雑制御のための情報の長さの基本単位にかけられる関連する倍数情報を含む。
【１５９３】
具体的な実施例において、上述した情報はＣフィールドである。一実施例においてＣフィールドは０ｘ００に設定されるが、この場合、混雑制御のための情報の長さが３２ビットであることを示す。他の実施例においてＣフィールドは０ｘ０１に設定されるが、この場合、混雑制御のための情報の長さが６４ビットである。また他の実施例においてＣフィールドは０ｘ０２に設定されるが、この場合、混雑制御のための情報の長さが９６ビットである。更に他の実施例においてＣフィールドは０ｘ０３に設定されるが、この場合、混雑制御のための情報の長さが１２８ビットである。Ｃフィールドは２ビットである。
【１５９４】
また、本発明の一実施例によるパケットヘッダはプロトコールに特化した情報を含む。具体的な実施例において、上述した情報はＰＳＩフィールドである。また、ＰＳＩフィールドは２ビットである。
【１５９５】
また、本発明の一実施例によるパケットヘッダは伝送セッションの識別情報を示すフィールドの長さに関する情報を含む。詳しくは、伝送セッションの識別情報を示すフィールドの倍数情報を含む。上述した情報はＳフィールドという。Ｓフィールドは１ビットである。
【１５９６】
また、本発明の一実施例によるパケットヘッダは伝送オブジェクトの識別情報を示すフィールドの長さに関する情報を含む。詳しくは、伝送オブジェクトの識別情報を示すフィールドの基本長さにかけられる倍数情報を含む。上述した情報はＯフィールドという。Ｏフィールドは１２ビットである。
【１５９７】
また、本発明の一実施例によるパケットヘッダは伝送セッションの識別情報を示すフィールドの長さに関する追加の情報を含む。そして、パケットヘッダは伝送オブジェクトの識別情報を示すフィールドの長さに関する追加の情報を含む。追加の情報はハーフワード（ｈａｌｆ−ｗｏｒｄ）の追加可否情報である。伝送パケットの識別情報を示すフィールド及び伝送オブジェクトの識別情報を示すフィールドは存在すべきであるため、ＳフィールドとＨフィールドまたはＯフィールドとＨフィールドは同時に０（Ｚｅｒｏ）を示すことができない。
【１５９８】
また、本発明の一実施例によるパケットヘッダは、セッションが終了されるか終了が迫ることを示す情報を含む。上述した情報をＡフィールドという。具体的な実施例において、Ａフィールドがセッションの終了または終了の切迫を示せば１に設定される。よって、通常Ａフィールドは０に設定される。放送伝送装置がＡフィールドを１に設定する場合、セッションを介して最後のパケットが伝送されていることを示す。Ａフィールドが１に設定されると、放送伝送装置は該当パケットを従う全てのパケットの伝送が終了されるまでＡフィールドを１に維持すべきである。また、放送受信装置はＡフィールドが１に設定される場合、放送伝送装置がセッションを介したパケット伝送をもうすぐ中断することを認識する。つまり、放送受信装置はＡフィールドが１に設定されるとセッションを介してそれ以上のパケット伝送はないと認識する。一実施例において、Ａフィールドは１ビットである。
【１５９９】
また、本発明の一実施例によるパケットヘッダは、オブジェクトの伝送が終了されるか終了が迫ることを示す情報を含む。上述した情報をＢフィールドという。具体的な実施例において、放送伝送装置はオブジェクトの伝送終了が迫ればＢフィールドは１に設定される。よって、通常Ｂフィールドは０に設定される。伝送オブジェクトを識別する情報が伝送パケットに存在しなければＢフィールドは１に設定される。そして、アウト・オブ・バンド（ｏｕｔ−ｏｆ−ｂａｎｄ）情報によって識別されたオブジェクト伝送の終了が迫ることを示す。また、Ｂフィールドはオブジェクトのための最後のパケットが伝送されれば１に設定される。また、Ｂフィールドはオブジェクトのための最後の数秒パケットが伝送されれば１に設定される。放送伝送装置は特定オブジェクトのためのパケットのフィールドが１に設定されると、該当パケットを従う全てのパケットの伝送が終了されるまでＢフィールドを１に設定すべきである。放送受信装置１００はＢフィールドが１に設定されると、放送伝送装置がオブジェクトのためのパケットの伝送をもうすぐ中断することを認識する。つまり、放送受信装置１００は１に設定されたＢフィールドからセッションを介したそれ以上のオブジェクトの伝送はないと認識する。一実施例において、Ｂフィールドは１ビットである。
【１６００】
また、本発明の一実施例によるパケットヘッダは、ヘッダの総長さを示す情報を含む。上述した情報をＨＤＲ＿ＬＥＮフィールドという。ＨＤＲ＿ＬＥＮフィールドは３２の倍数ビットである。具体的な実施例において、ＨＤＲ＿ＬＥＮフィールドが５に設定されればパケットヘッダの総長さは３２の５倍数である１６０ビットである。また、ＨＤＲ＿ＬＥＮフィールドは８ビットである。
【１６０１】
また、本発明の一実施例によるパケットヘッダは、ヘッダパケットに含まれたペイロードのエンコーディングまたはデコーディングに関する情報を含む。上述した情報をＣｏｄｅｉｎｔフィールドという。一実施例において、Ｃｏｄｅｉｎｔフィールドは８ビットである。
【１６０２】
また、本発明の一実施例によるパケットヘッダは、ヘッダの混雑を制御するための情報を含む。上述した情報をＣｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ（以下、ＣＣＩ）フィールドという。具体的な実施例において、ＣＣＩフィールドはＣｕｒｒｅｎｔ  ｔｉｍｅ  ｓｌｏｔ  ｉｎｄｅｘ（ＣＴＳＩ）フィールド、ｃｈａｎｎｅｌ  ｎｕｍｂｅｒフィールド及びｐａｃｋｅｔ  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒフィールドのうち少なくともいずれか一つを含む。
【１６０３】
また、本発明の一実施例によるパケットヘッダは、伝送セッションを識別するための情報を含む。上述した情報は伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ（以下、ＴＳＩ））である。また、ＴＳＩ情報を含むパケットヘッダ内のフィールドをＴＳＩフィールドという。
【１６０４】
また、本発明の一実施例によるパケットヘッダは、伝送セッションを介して伝送されるオブジェクトを識別するための情報を含む。上述した情報は伝送オブジェクト識別子（Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ（以下、ＴＯＩ））である。また、ＴＯＩ情報を含むパケットヘッダ内のフィールドをＴＯＩフィールドという。
【１６０５】
また、本発明の一実施例によるパケットヘッダは、追加の情報を伝送するための情報を含む。上述した情報をＨｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎフィールドという。一実施例において、追加の情報は伝送オブジェクトの再生に関する時間情報である。他の実施例において、追加の情報は伝送オブジェクトのデコーディングに関する時間情報である。
【１６０６】
また、本発明の一実施例による伝送パケットはペイロード識別情報を含む。一実施例において、識別情報はＦｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ（ＦＥＣ）  ｓｃｈｅｍｅに関するペイロード識別情報である。ここで、ＦＥＣはＲＦＣ  ５０１９に定義されているペイロードフォーマットのある類型である。ＦＥＣはＲＴＰまたはＳＲＴＰで使用される。上述した情報はＦＥＣ  Ｐａｙｌｏａｄ  ＩＤフィールドという。
【１６０７】
一実施例において、ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤフィールドはオブジェクトのソースブロックを識別するための情報を含む。上述した情報はＳｏｕｒｃｅ  ｂｌｏｃｋ  ｎｕｍｂｅｒフィールドという。例えば、Ｓｏｕｒｃｅ  ｂｌｏｃｋ  ｎｕｍｂｅｒフィールドがＮに設定されるとオブジェクト内のソースブロックは０からＮ−１にナンバリングされる。
【１６０８】
他の実施例において、ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤフィールドは特定エンコーディングシンボルを識別するための情報を含む。上述した情報はＥｎｃｏｒｄｉｎｇ  ｓｙｍｂｏｌ  ＩＤフィールドという。
【１６０９】
また、本発明の一実施例において、伝送パケットはペイロード内のデータを含む。上述したデータを含んでいるフィールドをＥｎｃｏｄｉｎｇ  ｓｙｍｂｏｌ（ｓ）フィールドという。一実施例において、放送受信装置１００はＥｎｃｏｄｉｎｇ  ｓｙｍｂｏｌ（ｓ）フィールドを抽出してオブジェクトを再構成する。詳しくは、パケットペイロードを介して伝送されるソースブロックからＥｎｃｏｄｉｎｇ  ｓｙｍｂｏｌ（ｓ）フィールド内のデータが生成される。
【１６１０】
図１２０は、本発明の一実施例によるパケットヘッダの構成示す図である。
【１６１１】
リアルタイムコンテンツの伝送を支援するためには、放送受信装置１００が受信した伝送パケットにパケットの属性情報及びデコーディングまたは再生に関するタイミング情報が含まれることが効果的である。よって、上述した課題を解決するために、図１２０に示したようにパケットヘッダが構成される。
【１６１２】
図１２０のパケットヘッダは図１１９のパケットヘッダと殆どの構成が同じである。よって、同じ部分の説明は省略する。
【１６１３】
本発明の一実施例によるパケットヘッダは伝送のためのオブジェクトタイプを示す情報を含む。上述した情報はｔｙｐｅフィールドという。ｔｙｐｅフィールドは２ビットである。
【１６１４】
具体的な実施例において、ｔｙｐｅフィールドは伝送のためのオブジェクトのタイプがレギュラファイル（ｒｅｇｕｌａｒ  ｆｉｌｅ）であることを示す。ここで、レギュラファイルはＩＳＯ  ＢＭＦＦ基盤のメディアファイルである。詳しくは、レギュラファイルはメディアファイルをＩＳＯ  ＢＭＦＦ形式にエンカプセレーションしたものである。この場合、ｔｙｐｅフィールドは０１(2)に設定される。他の実施例において、ｔｙｐｅフィールドは伝送のためのオブジェクトのタイプがＨＴＴＰ  ｅｎｔｉｔｙタイプであることを示す。この場合、ｔｙｐｅフィールドは１０(2)に設定される。また他の実施例において、ｔｙｐｅフィールドは伝送のためのオブジェクトのタイプがオーディオアクセスユニット（Ａｕｄｉｏ  ａｃｃｅｓｓ  ｕｎｉｔ）またはビデオアクセスユニット（Ｖｉｄｅｏ  ａｃｃｅｓｓ  ｕｎｉｔ）であることを示す。また、ｔｙｐｅフィールドはオブジェクトのタイプがネットワーク観念的階層（ＮＡＬ）ユニットであることを示してもよい。この場合、ｔｙｐｅフィールドは１１(2)に設定される。
【１６１５】
また、本発明の一実施例によるパケットヘッダは伝送パケットが伝送オブジェクトの最初の部分または最後の部分を含んでいることを示す。伝送パケットが伝送オブジェクトの最初の部分または最後の部分を示すことを示す情報はマーカービット（ｍａｒｋｅｒ  ｂｉｔ））である。具体的な実施例において、マーカービットはＭフィールドである。詳しくは、Ｍフィールドはｔｙｐｅフィールドの値に応じて異なるように解析される。例えば、伝送のためのオブジェクトタイプがファイルであれば該当伝送パケットがファイルの最後の部分を含んでいることを示す。ここで、最後の部分とはファイルの最後のビットを含んでいる部分である。他の例として、伝送のためのオブジェクトタイプがＡＶデータ（Ａｕｄｉｏ  ｏｒ  Ｖｉｄｅｏ）であれば該当伝送パケットがアクセスユニットの最初または最後のビットを含んでいることを示す。
【１６１６】
図１２１及び図１２２は、時間情報を含む拡張されたヘッダの構成を示す図である。図１２１及び図１２２に示した拡張されたヘッダは図１２０に示したヘッダ拡張フィールドに含まれる。
【１６１７】
図１２１に示したように、本発明の一実施例による拡張されたヘッダは拡張されたヘッダのタイプ情報を含む。上述した情報はＨＥＴ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｔｙｐｅ）フィールドという。
【１６１８】
また、一実施例による拡張されたヘッダは拡張されたヘッダの長さ情報を含む。上述した情報はＨＥＬ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｌｅｎｇｔｈ）フィールドという。
【１６１９】
また、一実施例による拡張されたヘッダは放送伝送装置の現在の時間を示す。つまり、拡張されたヘッダは放送伝送装置の該当パケットの伝送時間情報を含む。例えば、放送伝送装置はサーバである。具体的な実施例において、放送伝送装置の現在の時間を示す情報はＳｅｎｄｅｒ  Ｃｕｒｒｅｎｔ  Ｔｉｍｅ（以下、ＳＣＴ）フィールドである。
【１６２０】
また、一実施例による拡張されたヘッダはＳＣＴフィールドが６４ビットであるのか否かを示す。詳しくは、拡張されたヘッダはＳＣＴフィールドが６４ビットで構成されて拡張されたヘッダに含まれているのか否かを示す。具体的な実施例において、ＳＣＴフィールドが６４ビットであるのか否かを示す情報はＳＣＴ  Ｈｉフィールドである。
【１６２１】
また、一実施例による拡張されたヘッダはＳＣＴフィールドが３２ビットであるのか否かを示す。詳しくは、拡張されたヘッダはＳＣＴフィールドが３２ビットで構成されて拡張されたヘッダに含まれているのか否かを示す。具体的な実施例において、ＳＣＴフィールドが３２ビットであるのか否かを示す情報はＳＣＴ  Ｌｏｗフィールドである。
【１６２２】
また、一実施例による拡張されたヘッダは伝送のためのオブジェクトの予想される残余時間情報を含む。上述した情報はＥｘｐｅｃｔｅｄ  Ｒｅｓｉｄｕａｌ  Ｔｉｍｅ（以下、ＥＲＴ）フィールドという。
【１６２３】
また、一実施例による拡張されたヘッダはＥＲＴフィールドが該当パケットに存在するのか否かを示す。該当情報はＥＲＴ  ｆｌａｇフィールドである。
【１６２４】
また、一実施例による拡張されたヘッダはセッションが最後に変化した時間情報を含む。上述した情報はＳＬＣフィールドである。
【１６２５】
また、一実施例による拡張されたヘッダはＳＬＣフィールドが該当パケットに存在するのか否かを示す。該当情報はＳＬＣ  ｆｌａｇフィールドである。
【１６２６】
また、一実施例による拡張されたヘッダは放送伝送装置が利用する伝送プロトコールに応じて拡張して使用し得るフィールドを含む。該当情報はＰＩ−ｓｐｅｃｉｔｉｆ  Ｕｓｅフィールドである。
【１６２７】
図１２２は、図１２１の拡張されたヘッダに構成を追加した他の実施例による拡張されたヘッダを示す図である。
【１６２８】
他の実施例による拡張されたヘッダはパケットペイロードに含まれたデータのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドである。例えば、Ｔｉｍｅｓｔａｍｐフィールドはパケットペイロードに含まれたデータの最初のバイトがデコーディングされる時点に対する情報を含む。他の例として、Ｔｉｍｅｓｔａｍｐフィールドはデータの再生時点に関する情報を含む。加えて、Ｔｉｍｅｓｔａｍｐフィールドはタイムスケール情報またはタイムスケールに基づくタイミング情報を含んでもよい。ここで、タイムスケール情報は伝送オブジェクトのデコーディングまたは再生時点に対する時間を示す単位である。タイムスケールに基づいたタイミング情報である場合、放送受信装置はＴｉｍｅｓｔａｍｐフィールドの値をタイムスケールをかけてデコーディングまたは再生時点に関する情報を獲得する。
【１６２９】
他の実施例による拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳ  ｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。メディアタイムは任意のメディアタイムラインによるメディア再生時間である。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。ノーマル再生タイムのフォーマットは再生開始時点から相対的に表現される再生時間であり、これは時、分、秒、秒以下の小数点単位で表現される。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ（Ｓｏｃｉｅｔｙ  ｏｆ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  ａｎｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｇｉｎｅｅｒｓ）  ｔｉｍｅ  ｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。詳しくは、ＳＭＰＴＥタイムコードはＳＭＰＴＥでビデオの個別的なフレームラベリングのために定義した時間情報形式である。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚ基盤のタイミング情報であることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０５に設定される。
【１６３０】
また他の実施例による拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドの構成を示す。タイミング情報の構成を示す情報をＴＳ  ｖｅｒｓｉｏｎフィールドという。例えば、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは１に設定される。
【１６３１】
図１２３乃至図１２６は、本発明の一実施例による拡張されたヘッダの構成を示す図である。詳しくは、図１２３乃至図１２６に示した拡張されたヘッダ構造は伝送のためのオブジェクトタイプ情報及びタイミング情報のうち少なくとも一つを含む。また、該当拡張されたヘッダ構造は上述した拡張されたヘッダフィールドに含まれる。また、コンテンツを伝送するパケットヘッダの一部として称される。
【１６３２】
図１２３に示したように、本発明の他の実施例による拡張されたヘッダの構造（ＥＸＴ＿ＯＢＪ＿ＩＮＦＯ）はヘッダ拡張部分のタイプ情報を含む。上述したタイプ情報はＨＥＴフィールドという。また、拡張されたヘッダ構造は拡張部分の長さ情報を含む。上述した長さ情報はＨＥＬフィールドという。また、拡張されたヘッダ構造は伝送オブジェクトのタイプ情報を含む。上述したオブジェクトタイプ情報はＯｂｊｅｃｔ  ｔｙｐｅフィールドという。
【１６３３】
具体的な実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがレギュラファイルのタイプであることを示す。ここで、レギュラファイルはＩＳＯ  ＢＭＦＦ基盤のメディアファイルである。詳しくは、レギュラファイルはメディアファイルをＩＳＯ  ＢＭＦＦ形式にエンカプセレーションしたものである。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０１に設定される。他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがＨＴＴＰ  ｅｎｔｉｔｙタイプであることを示す。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０２に設定される。また他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがオーディオデータタイプであることを示す。Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがＡＡＣを基盤にするオーディオデータタイプであることを示す。この際、ＡＡＣに基づくオーディオデータタイプはＡＡＣにエンコーディングされたオーディオデータである。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０３に設定される。更に他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがビデオデータタイプであることを示す。詳しくは、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがＨ．２６４タイプであることを示す。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０４に設定される。更に他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがＨＥＶＣ基盤のビデオデータタイプであることを示す。この際、ＨＥＶＣ基盤のビデオタイプはＨＥＶＣにエンコーディングされたビデオデータである。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０５に設定される。更に他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがＩＳＯ  ＢＭＦＦ基盤のファイルタイプであることを示す。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０６に設定される。更に他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがメタデータであることを示す。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０７に設定される。
【１６３４】
また、本発明の他の実施例による拡張されたヘッダの構造（ＥＸＴ＿ＯＢＪ＿ＩＮＦＯ）はヘッダ伝送パケットが伝送オブジェクトの最初の部分または最後の部分を含むことを示す。伝送パケットが伝送オブジェクトの最初の部分または最後の部分を示す情報はマーカービットである。具体的な実施例において、マーカービットはＭフィールドである。詳しくは、ＭフィールドはＯｂｊｅｃｔ  ｔｙｐｅフィールドの値に応じて異なるように解析される。例えば、伝送のためのオブジェクトタイプがファイルであれば該当伝送パケットがファイルの最後の部分を含んでいることを示す。ここで、最後の部分とはファイルの最後のビットを含んでいる部分である。他の例として、伝送のためのオブジェクトタイプがＡＶデータであれば該当伝送パケットがアクセスユニットの最初または最後のビットを含んでいることを示す。
【１６３５】
また、本発明の他の実施例による拡張されたヘッダの構造（ＥＸＴ＿ＯＢＪ＿ＩＮＦＯ）はパケットペイロードに含まれたデータのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドである。例えば、Ｔｉｍｅｓｔａｍｐフィールドはパケットペイロードに含まれたデータの最初のバイトがデコーディングされる時点に対する情報を含む。他の例として、Ｔｉｍｅｓｔａｍｐフィールドはデータの再生時点に関する情報を含む。加えて、Ｔｉｍｅｓｔａｍｐフィールドはタイムスケール情報またはタイムスケールに基づくタイミング情報を含んでもよい。ここで、タイムスケール情報は伝送オブジェクトのデコーディングまたは再生時点に対する時間を示す単位である。タイムスケールに基づいたタイミング情報である場合、放送受信装置はＴｉｍｅｓｔａｍｐフィールドの値をタイムスケールをかけてデコーディングまたは再生時点に関する情報を獲得する。
【１６３６】
図１２４は、図１２３の拡張されたヘッダの構成に一部の構成が追加された他の実施例を示す図である。
【１６３７】
図１２４に示したように、本発明の他の実施例による拡張されたヘッダの構造は該当拡張されたヘッダの構造にＴｉｍｅｓｔａｍｐフィールドが存在するのか否かを示す。Ｔｉｍｅｓｔａｍｐフィールドの存在可否を示す情報はＴＳ  ｆｌａｇフィールドという。具体的な実施例において、ＴＳ  ｆｌａｇフィールドが１に設定されればＴＳ  ｆｌａｇフィールドは該当ヘッダ構造にＴｉｍｅｓｔａｍｐフィールドが存在することを示す。
【１６３８】
また、本発明の他の実施例による拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳ  ｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。メディアタイムは任意のメディアタイムラインによるメディア再生時間である。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。ノーマル再生タイムのフォーマットは再生開始時点から相対的に表現される再生時間であり、これは時、分、秒、秒以下の小数点単位で表現される。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚ基盤のタイミング情報であることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０５に設定される。
【１６３９】
また、本発明のまた他の実施例による拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドの構成を示す。詳しくは、拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドに含まれたオブジェクトの再生またはデコーディングに関するタイミング情報の構成を示す。上述した情報をＴＳ  ｖｅｒｓｉｏｎフィールドという。例えば、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは１に設定される。
【１６４０】
図１２５は、図１２３の拡張されたヘッダの構成に一部の構成が追加されたまた他の実施例を示す図である。
【１６４１】
図１２５に示したように、本発明のまた他の実施例による拡張されたヘッダの構造は伝送オブジェクトに関する付加情報を含む。具体的な実施例において、拡張されたヘッダの構造はオブジェクトの位置情報を含む。例えば、オブジェクトの位置情報はＩＳＯ  ＢＭＦＦを基盤にするセグメントのＵＲＬ情報を示す。詳しくは、オブジェクトの位置情報はＩＳＯ  ＢＭＦＦを基盤にするセグメントをダウロード可能なＵＲＬ情報を示す。この場合、伝送オブジェクトに関する付加情報はＥｘｔｅｎｓｉｏｎフィールドである。
【１６４２】
また、本発明の他の実施例による拡張されたヘッダの構造は該当拡張されたヘッダの構造にＥｘｔｅｎｓｉｏｎフィールドが存在するのか以下かを示す。この場合、Ｅｘｔｅｎｓｉｏｎフィールドが存在するのか否かを示す情報はＥｘｔ  Ｆｌａｇフィールドという。
【１６４３】
図１２６は、図１２３の新たなヘッダの拡張構造がパケットヘッダの一部に使用された一実施例を示す図である。図１２６に示したように、パケットヘッダの一部が伝送オブジェクトのタイミング情報を含む。伝送オブジェクトのタイミング情報を含むパケットヘッダの一部はＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドである。
【１６４４】
ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはパケットペイロードに含まれたデータのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドである。例えば、Ｔｉｍｅｓｔａｍｐフィールドはパケットペイロードに含まれたデータの最初のバイトがデコーディングされる時点に対する情報を含む。他の例として、Ｔｉｍｅｓｔａｍｐフィールドはデータの再生時点に関する情報を含む。加えて、Ｔｉｍｅｓｔａｍｐフィールドはタイムスケール情報またはタイムスケールに基づくタイミング情報を含んでもよい。ここで、タイムスケール情報は伝送オブジェクトのデコーディングまたは再生時点に対する時間を示す単位である。タイムスケールに基づいたタイミング情報である場合、放送受信装置はＴｉｍｅｓｔａｍｐフィールドの値をタイムスケールをかけてデコーディングまたは再生時点に関する情報を獲得する。
【１６４５】
また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳ  ｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚ基盤のタイミング情報であることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０５に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＧＰＳ  ｔｉｍｅフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０６に設定される。
【１６４６】
また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはＴｉｍｅｓｔａｍｐフィールドのフォーマットの構成を示す。拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドのフォーマットに含まれたオブジェクト再生またはデコーディングに関するタイミング情報の構成を示す。上述した情報をＴＳ  ｖｅｒｓｉｏｎフィールドという。例えば、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは１に設定される。
【１６４７】
また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはタイミング情報に関する追加的な情報を含む。例えば、マッピングされるタイミング情報に関するデータ情報が含まれる。タイミング情報に関する追加の情報はＥｘｔｅｎｓｉｏｎフィールドという。
【１６４８】
また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはＥｘｔｅｎｓｉｏｎフィールドの構成に関する情報を含む。詳しくは、Ｅｘｔｅｎｓｉｏｎフィールドには多様な情報が含まれ、多様な情報ごとにフラッグが集合を成している。この場合、フラッグの集合をＥｘｔ  ｆｌａｇフィールドという。
【１６４９】
放送受信装置１００が放送受信部を介して受信した伝送オブジェクトが他の形式または他の基準時間を有するタイミング情報と同期化する必要がある。詳しくは、放送受信装置１００は伝送オブジェクトのタイミング情報とは異なる形式または基準時間を有する同期化のための基準になる基本タイムラインに伝送オブジェクトのタイミング情報を同期化すべきである。一実施例において、同期化するタイミング情報は伝送オブジェクトの再生タイミングである。他の実施例において、同期化するタイミング情報は伝送オブジェクトのデコーディングタイミングである。この場合、放送伝送装置は他のタイミング情報と伝送オブジェクトのタイミング情報間のマッピング関係に関する情報を放送受信装置１００に伝送すべきである。上述した課題を解決するための本発明の一実施例において、上述したｔｉｍｅｌｉｎｅ＿ｃｏｍｐｏｎｅｎｔ＿ＡＵを含むメタデータを一つの伝送オブジェクトにして伝送する。
【１６５０】
上述した課題を解決するための他の実施例において、上述した拡張されたヘッダは伝送オブジェクトのタイミング情報とは異なる別途のマッピング情報を含む。詳しくは、拡張されたヘッダ（ＥＸＴ＿ＴＩＭＥ＿ＭＡＰ）は伝送オブジェクトのタイムスタンプを他のＴｉｍｅｌｉｅｎにマッピングするための情報を含む。例えば、放送受信装置１００は制御部１５０を介して上述した情報を利用してパケットペイロードの再生時間をＧＰＳタイムにマッピングする。この場合、ＧＰＳタイムが基本タイムラインである。
【１６５１】
図１２７は、本発明の一実施例による他のタイミング情報とのマッピングを支援するための拡張されたヘッダの構成を示す図である。
【１６５２】
図１２７に示したように、拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳ  ｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚ基盤のタイミング情報であることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０５に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＧＰＳ  ｔｉｍｅフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０６に設定される。
【１６５３】
また、拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドのバージョンまたは構成を示す。拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドのフォーマットに含まれたオブジェクト再生またはデコーディングに関するタイミング情報の構成を示す。上述した情報をＴＳ  ｖｅｒｓｉｏｎフィールドという。例えば、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは１に設定される。
【１６５４】
また、拡張されたヘッダは伝送オブジェクトのタイムスタンプがマッピングされるタイムラインのタイミング情報が存在するのか否かを示す。この場合、存在可否を示す情報はＯＴＳ  ｆｌａｇフィールドという。具体的な一実施例において、ＯＴＳ  ｆｌａｇフィールドが１に設定された場合、伝送オブジェクトのタイムスタンプがマッピングされるタイムラインのタイミング情報が存在することを示す。
【１６５５】
また、拡張されたヘッダは伝送オブジェクトのタイムスタンプがマッピングされるタイムラインのスタンプフォーマットを示す。詳しくは、伝送オブジェクトのタイムスタンプはオブジェクトの再生時間及びデコーディング時間のうち少なくとも一つである。また、伝送オブジェクトがタイムスタンプとマッピングされるタイムラインは基本タイムラインである。ここで、基本タイムラインは複数の互いに異なるタイムライン間の同期化のために必要な基準タイムラインである。
【１６５６】
上述した情報はＯＴＳ  ｆｏｒｍａｔフィールドである。具体的な実施例において、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがメディアタイムのフォーマットであることを示す。この場合、ＯＴＳ  ｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがノーマル再生タイムのフォーマットであることを示す。この場合、ＯＴＳ  ｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＯＴＳ  ｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプが９０ＫＨｚ基盤のタイミング情報であることを示す。この場合、ＯＴＳ  ｆｏｒｍａｔフィールドは０ｘ０５に設定される。また、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがＧＰＳ  ｔｉｍｅフォーマットであることを示す。この場合、ＯＴＳ  ｆｏｒｍａｔフィールドは０ｘ０６に設定される。
【１６５７】
また、拡張されたヘッダはオブジェクトのタイムスタンプと伝送オブジェクトのタイムスタンプとマッピングされるタイムラインのタイムスタンプのバージョンまたは構成を示す。詳しくは、伝送オブジェクトのタイムスタンプはオブジェクト再生時間またはデコーディング時間のうち少なくとも一つである。また、伝送オブジェクトのタイムスタンプとマッピングされるタイムラインは基本タイムラインである。ここで、基本タイムラインは複数の互いに異なるタイムライン間の同期化のために必要な基準タイムラインである。
【１６５８】
この場合、伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプの構成またはバージョンを示す情報をＯＴＳ  ｖｅｒｓｉｏｎフィールドという。例えば、ＯＴＳ  ｖｅｒｓｉｏｎフィールドは伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプが３２ビットであることを示す。この場合、ＯＴＳ  ｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＯＴＳ  ｖｅｒｓｉｏｎフィールドは伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプが６４ビットであることを示す。この場合、ＯＴＳ  ｖｅｒｓｉｏｎフィールドは１に設定される。
【１６５９】
また、拡張されたヘッダは位置情報を含むか否かを示す。この場合、位置情報を含むか否かを示す情報はＬｏｃａｔｉｏｎ  ｆｌａｇフィールドである。例えば、Ｌｏｃａｔｉｏｎ  ｆｌａｇフィールドが１に設定されれば該当拡張されたヘッダに位置情報が含まれていることを示す。
【１６６０】
また、拡張されたヘッダは伝送オブジェクトのタイムスタンプ及び伝送オブジェクトのタイムスタンプと伝送オブジェクトのタイムスタンプとマッピングされるタイムラインのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドという。
【１６６１】
また、拡張されたヘッダは拡張されたヘッダのタイムスタンプと伝送オブジェクトのタイムスタンプとマッピングされる伝送オブジェクトに関するタイミング情報を含む。上述した情報はＯｒｉｇｉｎ  ｔｉｍｅ  ｓｔａｍｐフィールドという。
【１６６２】
また、拡張されたヘッダは伝送オブジェクトのタイムスタンプとマッピングされるタイムラインに関するデータの位置情報を含む。上述した情報はＬｏｃａｔｉｏｎフィールドという。一実施例において、特定ＩＳＯ  ＢＭＦＦ基盤のデータセグメントのタイムラインとマッピングが必要であればＬｏｃａｔｉｏｎフィールドは該当セグメントのＵＲＬを含む。
【１６６３】
図１２８は、本発明の一実施例による放送伝送装置の動作方法を示す図である。
【１６６４】
放送伝送装置は制御部を介して伝送のためのオブジェクトを獲得するＳ４０１。一実施例において、オブジェクトはＡＶコンテンツである。他の実施例において、オブジェクトはＡＶコンテンツに関する向上されたデータである。
【１６６５】
放送伝送装置は制御部を介してオブジェクトの時間情報及びフォーマット情報を獲得するＳ４０３。一実施例において、時間情報は伝送オブジェクトのタイムスタンプである。他の実施例において、時間情報は伝送オブジェクトのタイムスタンプとマッピングされるタイムラインのタイミング情報である。また他の実施例において、時間情報は拡張されたヘッダ構造のタイムスタンプである。更にの実施例において、時間情報は拡張されたヘッダ構造のタイムスタンプとマッピングされる伝送オブジェクトのタイミング情報である。また、フォーマット情報はレギュラファイル、ＨＴＴＰエンティティ及びオーディオまたはビデオアクセスユニットのうち少なくとも一つである。
【１６６６】
詳しくは、伝送オブジェクトのタイムスタンプはオブジェクトの再生時間及びデコーディング時間のうち少なくとも一つである。また、伝送オブジェクトがタイムスタンプとマッピングされるタイムラインは基本タイムラインである。ここで、基本タイムラインは複数の互いに異なるタイムライン間の同期化のために必要な基準タイムラインである。例えば、基本タイムラインがＧＰＳ  ｔｉｍｅであってもよく、伝送オブジェクトをＧＰＳ  ｔｉｍｅと同期化するための情報が上述した拡張されたヘッダに含まれてもよい。
【１６６７】
放送伝送装置は制御部を介して獲得した時間情報及びフォーマット情報をパケットヘッダに設定して伝送パケットをパケット化するＳ４０５。詳しくは、放送伝送装置の制御部は獲得した時間情報を含むパケットヘッダ及びデータを含むパケットデータを伝送プロトコールに応じてパケット化する。他の実施例において、放送伝送装置は制御部を介してパケットヘッダに選択的に含まれる拡張されたヘッダに時間情報及びフォーマット情報を設定する。
【１６６８】
詳しくは、時間情報はオブジェクトの再生時間に関する情報である。再生時間に関する情報は伝送オブジェクトの再生時点（タイミング情報）及びデコーディング時点（タイミング情報）のうち少なくとも一つである。他の実施例において、追加の情報は伝送オブジェクトのタイプ情報である。放送伝送装置は一般的なパケットヘッダに拡張されたヘッダの存在するか否か、拡張されたヘッダの長さ及び拡張されたヘッダのタイプ情報のうち少なくとも一つを設定する。
【１６６９】
放送伝送装置は伝送部を介してパケット化された伝送パケットを伝送するＳ４０７。伝送部は伝送パケットを地上波放送網及びインターネット網のうち少なくとも一つを介して伝送する。
【１６７０】
図１２９は、本発明の一実施例による放送受信装置の動作方法を示す図である。
【１６７１】
放送受信装置１００は放送受信部１１０を介して伝送パケットを受信するＳ４１１。図１２８において、説明のように伝送パケットはパケットヘッダ及びパケットペイロードを含むが、パケットヘッダは拡張されたヘッダを選択的に含む。
【１６７２】
放送受信装置１００の制御部１５０は受信した伝送パケットからパケットヘッダ及び拡張されたヘッダを抽出するＳ４１２。具体的な実施例において、制御部１５０は伝送パケットに含まれたパケットヘッダを抽出する。また、パケットヘッダに選択的に含まれる拡張されたヘッダをパケットヘッダから抽出する。
【１６７３】
放送受信装置１００の制御部１５０はパケットヘッダに基づいて伝送オブジェクトに関する時間情報及び伝送オブジェクトのフォーマット情報のうち少なくとも一つを獲得するＳ４１３。他の実施例において、制御部１５０はパケットヘッダに選択的に含まれる拡張されたヘッダから前記時間情報及びフォーマット情報のうち少なくとも一つを獲得する。具体的な実施例において、制御部１５０は拡張されたヘッダに基づいて伝送オブジェクトのタイムスタンプを獲得する。また、制御部１５０は伝送オブジェクトのフォーマット情報を獲得する。伝送オブジェクトのフォーマット情報はレギュラファイル、ＨＴＴＰエンティティ及びオーディオまたはビデオアクセスユニットのうち少なくとも一つを示す。ここで、レギュラファイルとはＩＳＯ  ＢＭＦＦ基盤のメディアファイルである。
【１６７４】
放送受信装置１００の制御部１５０はパケットヘッダから他の時間情報とマッピングするための情報を獲得できるのか否かを判断するＳ４１４。詳しくは、制御部１５０は該当伝送オブジェクトのための時間情報とマッピングされる他の時間情報がパケットヘッダに存在するのか否かを判断する。他の実施例において、制御部１５０はパケットヘッダに選択的に含まれる拡張されたヘッダから抽出された特定情報に基づいて判断する。
【１６７５】
一実施例において、制御部１５０がパケットヘッダから他の時間情報とマッピングするための情報を獲得できると判断した場合、制御部１５０はパケットヘッダからマッピングのための情報を獲得するＳ４１５。ここで、他の時間情報は上述した基本タイムラインのタイミング情報である。また、タイミング情報は伝送オブジェクトの再生タイミング情報及びデコーディングタイミング情報のうち少なくとも一つを含む。具体的な実施例において、制御部１５０はパケットヘッダに基づいて伝送オブジェクトとマッピングされるタイムラインのタイミング情報を獲得する。他の実施例において、制御部１５０はパケットヘッダに基づいてパケットヘッダのタイムスタンプとマッピングされる伝送オブジェクトのタイミング情報を獲得する。また、制御部１５０はパケットヘッダに基づいて伝送オブジェクトとマッピングされるデータの位置情報を獲得する。また他の実施例において、制御部１５０はパケットヘッダに選択的に含まれる拡張されたヘッダからマッピングのための情報を獲得してもよい。
【１６７６】
放送受信装置１００の制御部１５０は獲得した時間情報に基づいて伝送オブジェクトを出力するＳ４１６。一実施例において、制御部１５０が他の時間情報とマッピング情報を獲得できなかった場合、該当伝送オブジェクトのタイムスタンプに基づいてオブジェクトを出力する。他の実施例において、制御部１５０が他の時間情報とマッピング情報を獲得した場合、該当マッピング情報及びオブジェクトのタイムスタンプに基づいてオブジェクトを出力する。
【１６７７】
図１３０は、伝送パケットの構成に対する情報を含むパケットヘッダの構成を示す図である。
【１６７８】
本発明の一実施例によるパケットヘッダは全体の伝送オブジェクトのうち最初または最後の部分のデータがパケットペイロードに含まれていることを示す。この場合、最初または最後の部分のデータが含まれていることを示す情報はマーカービットである。また、マーカービットはＭフィールドである。Ｍフィールドは１ビットである。
【１６７９】
また、本発明の一実施例によるパケットヘッダは該当伝送パケットの構成に関する情報を含む。この場合、伝送パケットの構成に関する情報はＴｙｐｅフィールドである。Ｔｙｐｅフィールドは２ビットである。
【１６８０】
他の場合、伝送パケットの構成に関する情報はＣｏｄｅｐｏｉｎｔフィールドである。Ｃｏｄｅｐｏｉｎｔフィールドは８ビットである。
【１６８１】
具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットがレギュラパケット構造であることを示す。詳しくは、該当パケットが図１１９に示した従来の伝送パケット構造をそのまま使用していることを示す。この場合、伝送パケットはパケットヘッダ、拡張されたヘッダ、パケットペイロード識別子及びデータのうち少なくともいずれか一つを含む。また、放送伝送装置はＴｙｐｅフィールドを０ｘ００に設定する。
【１６８２】
また、具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットがペイロードを含んでいないことを示す。詳しくは、該当伝送パケットがパケットヘッダ及び拡張されたヘッダのみを含んでいることを示す。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０１に設定する。
【１６８３】
また、具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットが全体の伝送オブジェクトに対するオフセット情報を含むことを示す。ここで、オフセット情報とは該当伝送パケットのエンコーディングシンボルフィールドが含んでいるデータのオフセット情報である。つまり、オフセット情報は全体の伝送オブジェクトから該当伝送パケットの構造と構成は同じであるが、ペイロード識別子フィールドがデータオフセットフィールドに代替される。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０２に設定する。
【１６８４】
また、具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットが従来のレギュラ伝送パケットの構造とは異なる構成を含むことを示す。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０３に設定する。具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットがペイロード識別子フィールドを含んでいないことを示す。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０４に設定する。図１３１は、図１３０の伝送パケットの構成を示す図である。図１３１に示したように、Ｔｙｐｅフィールドは伝送パケットの構造を示す。しかし、図１３１に示した伝送パケットに限ることはなく、必ずしも図１３１に設定された値に本発明が限定されることはない。
【１６８５】
図１３２は、本発明の一実施例による放送伝送装置の動作方法を示す図である。
【１６８６】
放送伝送装置は制御部を介して伝送のためのオブジェクトを獲得する（Ｓ４２１）。一実施例において、伝送パケットの構造は従来のレギュラパケット構造である。他の実施例において、伝送パケットの構造は従来のパケットヘッダ及び拡張されたヘッダののみで構成された構造である。また他の実施例において、伝送パケットの構造は従来のペイロード識別子を代替する構成を含む構造である。更に他の実施例において、伝送パケットの構造はペイロード識別子を含まない構造である。
【１６８７】
放送伝送装置は制御部を介して獲得した伝送パケットの構造に基づいて、該当構造の情報を示す値をパケットヘッダに設定して伝送パケットをパケット化する（Ｓ４２３）。詳しくは、制御部は該当構造の情報をＴｙｐｅフィールドに設定する。
【１６８８】
放送伝送装置は伝送部を介してパケット化された伝送パケットを伝送する（Ｓ４２５）。一実施例において、伝送部はパケット化された伝送パケットを地上波の放送網で伝送する。他の実施例において、伝送部はパケット化された伝送パケットをインターネット網で伝送してもよい。
【１６８９】
図１３３は、本発明の一実施例による放送受信装置の動作方法を示す図である。
【１６９０】
放送受信装置１００は放送受信部１１０を介して伝送パケットを受信する（Ｓ４３１）。一実施例において、放送受信部１１０は地上波放送網を介して伝送パケットを受信する。他の実施例において、ＩＰコミュニケーションユニット１３０はインターネット網を介して伝送パケットを受信する。
【１６９１】
放送受信装置１００は制御部１５０を介して受信した伝送パケットからパケットヘッダを抽出する（Ｓ４３３）。詳しくは、伝送パケットはパケットヘッダ及びパケットペイロードのうち少なくとも一つを含む。よって、制御部１５０は伝送パケットからペイロードをシグナリングするパケットヘッダを抽出する。
【１６９２】
放送受信装置１００は抽出したパケットヘッダから伝送パケットの構成情報を獲得する（Ｓ４３５）。詳しくは、パケットヘッダは伝送パケットの構造を示す情報を含む。よって、放送受信装置１００は制御部１５０を介してパケットヘッダから伝送パケットの構造を示す情報を獲得する。一実施例において、伝送パケットの構造は従来のレギュラ伝送パケット構造である。他の実施例において、伝送パケットの構造は従来のパケットヘッダ及び拡張されたヘッダのみを含む構造である。また他の実施例において、伝送パケットの構造はパケットペイロード識別子を代替するオフセット情報を含む構造である。更に他の実施例において、伝送パケットの構造はパケットペイロード識別子を含まない構造である。
【１６９３】
図１３４は、本発明の一実施例に係るＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を含むタイムラインリファレンス情報ＡＵ（ｔｉｍｅｌｉｎｅ  ｒｅｆｅｒｅｎｃｅ  ｉｎｆｏｒｍａｔｉｏｎ  ＡＵ）を示す図である。
【１６９４】
本発明は、前述したタイムラインリファレンス情報ＡＵにＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を挿入して送信することを提案する。また、本発明は、前述したＬＣＴパケットフィールドの拡張にＳＰＤを挿入して送信することを提案する。これによって、別個の網（例えば、インターネット網と放送網）で伝送されるメディアストリームのタイムラインを受信機で再構成して円滑に再生することができる。また、ＳＰＤの反映されたタイムラインリファレンス／タイムスタンプを伝送することによって、別個の受信環境に存在する受信機間の同期化を効果的に支援することができる。
【１６９５】
ＳＰＤは、外部網又は内部網で伝送されるメディアストリームの生成時点を基準に消費時点までの提案遅延時間を意味することができる。又は、実施例によって、ＳＰＤは、メディアストリームのエンコーディング時点を基準にデコーディング時点までの提案遅延時間を意味することもできる。又は、メディアストリームのランダムアクセス（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ）が可能な特定単位を放送ストリームに含めるとき、当該単位の最初のバイトが含まれる時間と当該単位の最後のバイトが含まれる時間との差を意味することもできる。当該データ単位は、ＲＡＰ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）を含むことができる。ＳＰＤの基準となる両時点は実施例によって変更されてもよい。ＳＰＤ、すなわち、提案遅延時間は、受信機のバッファタイム（Ｂｕｆｆｅｒ  Ｔｉｍｅ；ＢＴ）による再生時間の差を補完するために用いることができる。複数個の受信機において、実際のネットワーク帯域（ｐｒａｃｔｉｃａｌ  ｎｅｔｗｏｒｋ  ｂａｎｄｗｉｄｔｈ）が異なることから、バッファタイムも受信機ごとに異なりうる。バッファタイムの差によって、同じメディアデータが伝送側から放送されても、受信機での再生時間はそれぞれ異なりうる。これを補完して、タイムラインリファレンス又はタイムスタンプ値にＳＰＤを反映することによって、いずれの受信機でも同一時間に同一メディアを再生することができる。又は、メディアストリームのランダムアクセスが可能な特定単位が放送ストリームで伝送されるとき、当該単位に含まれた最も早い再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅ）を導出するために用いられてもよい。当該単位に含まれた最も早い再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅ）は、データを搬送するパケットが生成されたサーバーの時間（Ｓｅｎｄｅｒ  Ｃｕｒｒｅｎｔ  Ｔｉｍｅ）、上記ＳＰＤが考慮された再生タイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅｓｔａｍｐ）、及びパケットの実際の受信時間などを考慮して導出することができる。
【１６９６】
ＳＰＤは、タイムラインリファレンス情報ＡＵを用いて内部網又は外部網で伝送されるメディアストリームのタイムラインを再構成する時に反映することができる。すなわち、内部網又は外部網のタイムラインを再構成する時、内部網又は外部網のタイムラインリファレンス値からＳＰＤ値を引いて、提案遅延時間が反映されたタイムラインを構成することができる。
【１６９７】
また、ＳＰＤは、該当のメディアデータのプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅ）などの情報を含むタイムスタンプが伝達されて同期化が行われる場合に反映することができる。すなわち、タイムスタンプを用いた同期化において、タイムスタンプ値にＳＰＤの値を足して、提案遅延時間が反映された同期化を行うことができる。
【１６９８】
前述したように、タイムラインリファレンス情報ＡＵは、別個の網で伝送されるストリーム間の同期化を取るために用いることができる。ここで、図示されたタイムラインリファレンス情報ＡＵは、前述したタイムラインコンポーネントＡＵ（Ｔｉｍｅｌｉｎｅ  ｃｏｍｐｏｎｅｎｔ  ＡＵ）、又はタイムラインリファレンス情報ＡＵ（ｔｉｍｅｌｉｎｅ  ｒｅｆｅｒｅｎｃｅ  ｉｎｆｏｒｍａｔｉｏｎ  ＡＵ）の別の実施例であってもよい。
【１６９９】
本発明の一実施例に係るＳＰＤを含むタイムラインリファレンス情報ＡＵの各フィールド及び構造を説明する。
【１７００】
ＡＵ＿ｉｄｅｎｔｉｆｉｅｒフィールドは、前述したＡＵ＿ｉｄｅｎｔｉｆｉｅｒ情報を意味することができる。すなわち、ＡＵ＿ｉｄｅｎｔｉｆｉｅｒフィールドは、当該タイムラインリファレンス情報ＡＵを識別することができる。また、ＡＵ＿ｉｄｅｎｔｉｆｉｅｒフィールドは、当該タイムラインリファレンス情報ＡＵがいかなる構造を有するかを識別することもできる。実施例によって、ＡＵ＿ｉｄｅｎｔｉｆｉｅｒフィールドは８ビットのサイズを有することができる。
【１７０１】
ＡＵ＿ｌｅｎｇｔｈフィールドは、前述したＡＵ＿ｌｅｎｇｔｈ情報を意味することができる。すなわち、ＡＵ＿ｌｅｎｇｔｈフィールドは、当該タイムラインリファレンス情報ＡＵの長さ情報を含むことができる。このフィールドは、実施例によって、３２ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。
【１７０２】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇフィールドは、前述したｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇ情報を意味することができる。ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇフィールドは、当該タイムラインリファレンス情報ＡＵがｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドを有するか否かを示すフラグ（ｆｌａｇ）であってもよい。すなわち、このフィールドは、外部網で伝送されるストリームのＵＲＬ情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドは、１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。
【１７０３】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報を意味することができる。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドは、当該タイムラインリファレンス情報ＡＵがｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドを含んでいるか否かを示すフラグであってもよい。すなわち、このフィールドは、内部網のタイムラインリファレンス情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドは、１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。
【１７０４】
ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドは、前述したｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇ情報を意味することができる。ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドは、当該タイムラインリファレンス情報ＡＵがｅｘｔｅｒｎａｌ  ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドを含んでいるか否かを示すフラグであってもよい。すなわち、このフィールドは、外部網のタイムラインリファレンス情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドは、１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。
【１７０５】
ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｆｌａｇフィールドは、当該タイムラインリファレンス情報ＡＵがｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙフィールドを含むか否かを示すことができる。すなわち、このフィールドは、ＳＰＤ情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドは、１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙフィールドについては後述する。
【１７０６】
フラグフィールド後には、一定のサイズのビットが将来の使用のために残されていてもよい（Ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｒｔｕｒｅ  ｕｓｅ）。本実施例では、４ビットの空間が将来の使用のために残されている。
【１７０７】
タイムラインリファレンス情報ＡＵは、内部網のタイムラインリファレンスに関連した情報をさらに含むことができる。ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｆｌａｇフィールドの値によって、タイムラインリファレンス情報ＡＵは、外部網で伝送されるストリームのＵＲＬ情報をさらに含むことができる。このとき、追加されるフィールドについて説明する。
【１７０８】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドの長さをバイト単位で表現できる。このフィールドは、８ビットのフィールドであり、ｕｉｍｓｂｆフォーマットであってもよい。
【１７０９】
ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドも、タイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドは、外部網で伝送されるメディアの位置情報及び／又は当該メディアの固有識別情報を含むことができる。この情報に基づいて、外部網で伝送されるメディアに接近することができる。例えば、外部網で伝送されるメディアがＤＡＳＨによるメディアである場合、メディアの当該ＭＰＤのＭＰＤ  ＵＲＬ、ＭＰＤ  ＩＤなどの情報がｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドに含まれてもよい。このフィールドは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドが示す値に該当するビット数を有することができる。又は、実施例によって、このフィールドは、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドが示す値に８を乗じた分のビット数を有することができる。
【１７１０】
タイムラインリファレンス情報ＡＵは、内部網のタイムラインリファレンスに関連した情報をさらに含むことができる。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドの値によって、タイムラインリファレンス情報ＡＵは、内部網のタイムラインに関連した追加フィールドをさらに含むことができる。このとき、追加されるフィールドについて説明する。
【１７１１】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールドは、タイムラインリファレンス情報ＡＵに含まれた内部網のタイムラインリファレンス情報のフォーマットを示すことができる。例えば、このフィールドが０ｘ００値を有する場合、内部網のタイムラインリファレンス情報はメディアタイム（ｍｅｄｉａ  ｔｉｍｅ）フォーマット、０ｘ０１値を有する場合にはＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）フォーマット、０ｘ０２値を有する場合にはＰＴＰフォーマット、０ｘ０３値を有する場合にはタイムコード（ｔｉｍｅｃｏｄｅ）フォーマットを示すことができる。０ｘ０４乃至０ｘＦＦ値を有する場合には、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。このフィールドは、８ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。
【１７１２】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドは、タイムラインリファレンス情報ＡＵに内部網のタイムラインリファレンス情報の時間単位（ｔｉｍｅ  ｓｃａｌｅ）が含まれたか否かを示すフラグであってもよい。このフィールドは、１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。
【１７１３】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドは、タイムラインリファレンス情報ＡＵに含まれた内部網のタイムラインリファレンス情報の長さをバイト単位で示すことができる。このフィールドは、７ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。
【１７１４】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールドは、タイムラインリファレンス情報ＡＵに含まれた内部網のタイムラインリファレンス情報の時間単位（ｔｉｍｅ  ｓｃａｌｅ）をＨｚ単位で示すことができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド値によって存在してもしなくてもよい。このフィールドは、３２ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。
【１７１５】
ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドは、内部網のタイムラインリファレンス情報を有することができる。このフィールドの値によって、内部網で伝送されるメディアストリームのタイムラインを再構成することができる。このフィールドは、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドが示す値に該当するビット数を有することができる。又は、実施例によって、このフィールドは、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドが示す値に８を乗じた分のビット数を有することもできる。
【１７１６】
タイムラインリファレンス情報ＡＵは、外部網のタイムラインリファレンスに関連した情報をさらに含むことができる。ｅｘｔｅｒｎａｌ  ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｌａｇフィールドの値によって、タイムラインリファレンス情報ＡＵは、外部網のタイムラインに関連した追加フィールドをさらに含むことができる。このとき、追加されるフィールドについて説明する。
【１７１７】
この場合、タイムラインリファレンス情報ＡＵは、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールド、及び／又はｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドがさらに含むことができる。
【１７１８】
追加された各フィールドは、外部網で伝送されるメディアストリームに関する情報を有することができる。各フィールドは、前述した内部網で伝送されるメディアストリームに関するフィールドと対応して、類似の動作を行うことができる。ただし、この場合、各フィールドは、内部網ではなく外部網に関する情報を有することができる。
【１７１９】
すなわち、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドは、それぞれ、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールド、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールド、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールド、ｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドと類似の動作を行うことができる。
【１７２０】
外部網で伝送されるメディアストリームに関するフィールドはそれぞれ、外部網で伝送されるメディアストリームのフォーマット、時間単位情報の存否、長さ、時間単位、タイムラインリファレンスを示すことができる。
【１７２１】
タイムラインリファレンスフィールドＡＵは、ＳＰＤに関連したフィールドをさらに含むことができる。ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｆｌａｇフィールドの値によって、タイムラインリファレンスフィールドＡＵは、ＳＰＤに関連した追加フィールドをさらに含むことができる。このとき、追加されるフィールドについて説明する。
【１７２２】
ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドは、当該タイムラインリファレンス情報ＡＵにｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅフィールドが含まれているか否かを示すことができる。ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅフィールドについては後述する。すなわち、このフィールドは、ＳＰＤの時間単位関連情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドが０に設定され、ＳＰＤの時間単位関連情報が存在しない場合に、ＳＰＤの時間単位はノーマルクロック（ｎｏｒｍａｌ  ｃｌｏｃｋ）値で表現されてもよい。このフィールドは１ビットのフィールドであり、ｂｌｓｂｆフォーマットを有することができる。
【１７２３】
ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｌｅｎｇｔｈフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。このフィールドは、ＳＰＤの長さをバイト単位で示すことができる。このフィールドは、７ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。
【１７２４】
ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。このフィールドは、ＳＰＤの時間単位（ｔｉｍｅ  ｓｃａｌｅ）をＨｚ単位で示すことができる。このフィールドは、前述したｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドの値によってその存否が決定されてもよい。このフィールドは３２ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。
【１７２５】
ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙフィールドがタイムラインリファレンス情報ＡＵにさらに含まれてもよい。このフィールドは、ＳＰＤ情報を有することができる。すなわち、このフィールドは、外部網又は内部網で伝送されるメディアストリームの生成時点を基準に消費時点までの提案遅延時間情報を含むことができる。タイムラインリファレンス情報ＡＵを用いて内部網／外部網のメディアストリームのタイムラインを再構成する時、それぞれの内部網／外部網のタイムラインリファレンス値からこのフィールドの値を引いた値を反映することができる。これによって、提案遅延時間の反映されたタイムラインを構成することができる。このフィールドは、前述したｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｌｅｎｇｔｈフィールドが示す値に該当するビット数を有することができる。又は、実施例によって、このフィールドは、ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｌｅｎｇｔｈフィールドが示す値に８を乗じた分のビット数を有することもできる。このフィールドはｕｉｍｓｂｆフォーマットを有することができる。
【１７２６】
図１３５は、本発明の他の実施例に係るＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を含むタイムラインリファレンス情報ＡＵ（ｔｉｍｅｌｉｎｅ  ｒｅｆｅｒｅｎｃｅ  ｉｎｆｏｒｍａｔｉｏｎ  ＡＵ）を示す図である。
【１７２７】
図示された他の実施例に係るＳＰＤを含むタイムラインリファレンス情報ＡＵは、複数個の内部網又は外部網のタイムラインリファレンス情報を含むことができる。前述したように、タイムラインリファレンス情報ＡＵは、別個の網で伝送されるメディアストリーム間にタイムラインの同期化を取るために用いることができる。
【１７２８】
ＡＵ＿ｉｄｅｎｔｉｆｉｅｒフィールド、ＡＵ＿ｌｅｎｇｔｈフィールド、ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｆｌａｇフィールド、ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬ＿ｌｅｎｇｔｈフィールド、及び／又はｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドは、前述したとおりである。ｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇフィールドは、前述したｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドのような役割を担うことができる。
【１７２９】
ｎｂ＿ｏｆ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドは、当該タイムラインリファレンス情報ＡＵに含まれたタイムラインリファレンスの個数を示すことができる。前述したように、本実施例のタイムラインリファレンス情報ＡＵは、複数個のタイムラインリファレンス情報を有することができる。このフィールドは６ビットのサイズを有することができ、ｕｉｍｓｂｆフォーマットを有することができる。
【１７３０】
ｎｂ＿ｏｆ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドが示す個数分のタイムラインリファレンス関連情報が、タイムラインリファレンス情報ＡＵに含まれてもよい。各タイムラインリファレンスに対して、次のようなフィールドが存在してもよい。
【１７３１】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅフィールドは、当該タイムラインリファレンスがいかなるタイプのタイムラインリファレンスであるかを示すことができる。例えば、このフィールドの値が０である場合、当該タイムラインリファレンスが内部網で伝送されるメディアストリームのタイムラインリファレンスであってもよい。また、このフィールドの値が１である場合、当該タイムラインリファレンスが外部網で伝送されるメディアストリームのタイムラインリファレンスであってもよい。このフィールドは１ビットのサイズを有することができ、ｂｓｌｂｆフォーマットを有することができる。
【１７３２】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｉｄｅｎｔｉｆｉｅｒフィールドは、当該タイムラインリファレンスの固有識別子を示すことができる。このフィールドは０〜１２７の整数値で割り当てられてもよい。このフィールドは７ビットのサイズを有し、ｕｉｍｓｂｆフィールドを有することができる。
【１７３３】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールドは、当該タイムラインリファレンスのフォーマットを示すことができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｆｏｒｍａｔフィールドと同じ方式で当該タイムラインリファレンスのフォーマットを示すことができる。このフィールドは８ビットのサイズを有し、ｕｉｍｓｂｆフォーマットを有することができる。
【１７３４】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドは、当該タイムラインリファレンスの時間単位（ｔｉｍｅ  ｓｃａｌｅ）に関する情報がタイムラインリファレンス情報ＡＵに含まれているか否かを示すことができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールドと同じ方式で時間単位関連情報が存在するか否かを示すことができる。このフィールドは１ビットのサイズを有し、ｂｓｌｂｆフォーマットを有することができる。
【１７３５】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドは、当該タイムラインリファレンスの長さをバイト単位で示すことができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドと同じ方式で長さを示すことができる。このフィールドは７ビットのサイズを有し、ｕｉｍｓｂｆフォーマットを有することができる。
【１７３６】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールドは、当該タイムラインリファレンスの時間単位をＨｚ単位で示すことができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｉｍｅｓｃａｌｅフィールドと同じ方式で時間単位を示すことができる。このフィールドは３２ビットのサイズを有し、ｕｉｍｓｂｆフォーマットを有することができる。
【１７３７】
ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドは、当該タイムラインリファレンスのタイムラインリファレンス値を示すことができる。このフィールド値によって、当該内／外部網で伝送されるメディアストリームのタイムラインを再構成することができる。このフィールドは、前述したｉｎｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールド、ｅｘｔｅｒｎａｌ＿ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅフィールドと同じ方式でタイムラインを示すことができる。このフィールドは、前述したｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドが示す値に該当するビット数を有することができる。又は、実施例によって、このフィールドは、ｔｉｍｅｌｉｎｅ＿ｒｅｆｅｒｅｎｃｅ＿ｌｅｎｇｔｈフィールドが示す値に８を乗じた分のビット数を有することもできる。このフィールドはｕｉｍｓｂｆフォーマットを有することができる。
【１７３８】
ＳＰＤと関連したフィールドを前述の構造でタイムラインリファレンス情報ＡＵに含めることができる。ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇフィールド、ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｌｅｎｇｔｈフィールド、ｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙ＿ｔｉｍｅｓｃａｌｅフィールド及び／又はｓｕｇｇｅｓｔｅｄ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｌａｙフィールドは、前述した同名のフィールドと同一であってもよい。
【１７３９】
図１３６は、本発明の一実施例に係るＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を含むＬＣＴパケット構造を示す図である。
【１７４０】
前述したように、ＬＣＴパケットは、タイムラインリファレンス関連情報を伝送することができる。ＬＣＴパケットのヘッダーを拡張して、別個の網で伝送されるメディアストリーム間に同期化のための情報が伝送することができる。提案された構造は、ＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）などの伝送プロトコルのためのパケットなどに適用されてもよい。また、提案された構造は、伝送プロトコルに適したサービスシグナリング情報と連動して用いられてもよい。サービスシグナリング情報は、当該ストリームが内部又は外部網のタイムラインリファレンスを伝送していることを示す情報、外部網で伝送されるメディアのＵＲＬ情報、前述した各種フラグ情報、タイムラインリファレンスの時間単位情報など、各パケットに共通して適用可能な情報を含むことができる。
【１７４１】
Ｖフィールド、Ｃフィールド、ＰＳＩフィールド、Ｓフィールド、Ｏフィールド、Ｈフィールド、Ｒｅｓフィールド、Ａフィールド、Ｂフィールド、ＨＤＲ＿ＬＥＮフィールド、ＣＰフィールド、ＣＣＩフィールド、ＴＳＩフィールド、ＴＯＩフィールドは、前述したとおりである。
【１７４２】
ＨＥＴ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｔｙｐｅ）フィールドは、当該ＬＣＴパケットヘッダーの拡張（ｅｘｔｅｎｓｉｏｎ）タイプを示すことができる。このフィールドは１２７以下の値を割り当てて、ＬＣＴパケットヘッダーの拡張タイプを示すことができる。本実施例では、ＨＥＴフィールドが２の値を有し、ＬＣＴパケットヘッダーがＥＸＴ＿ＴＩＭＥの拡張タイプを有することを示すことができる。
【１７４３】
ＨＥＬ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｌｅｎｇｔｈ）フィールドは、当該ＬＣＴパケットヘッダーの拡張の長さを示すことができる。この長さは、３２ビットワード（ｗｏｒｄ）単位で表現することができる。
【１７４４】
ＵＳＥフィールドの細部フィールドは、次のとおりである。ＳＣＴ  ＨＩフィールド、ＳＣＴ  Ｌｏｗフィールド、ＥＲＴフィールド、ＳＬＣフィールドは、前述したとおりである。
【１７４５】
ＩＴＲ  Ｈｉ（Ｉｎｔｅｒｎａｌ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅ  Ｈｉｇｈ  Ｆｌａｇ）フィールドは、当該ＬＣＴパケットヘッダーの拡張に、６４ビットの内部タイムラインリファレンスフィールドが含まれることを示すことができる。
【１７４６】
ＩＴＲ  Ｌｏｗ（Ｉｎｔｅｒｎａｌ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅ  Ｌｏｗ  Ｆｌａｇ）フィールドは、当該ＬＣＴパケットヘッダーの拡張に、３２ビットの内部タイムラインリファレンスフィールドが含まれることを示すことができる。
【１７４７】
ＥＴＲ  Ｈｉ（Ｅｘｔｅｒｎａｌ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅ  Ｈｉｇｈ  Ｆｌａｇ）フィールドは、当該ＬＣＴパケットヘッダーの拡張に、６４ビットの外部タイムラインリファレンスフィールドが含まれることを示すことができる。
【１７４８】
ＥＴＲ  Ｌｏｗ（Ｅｘｔｅｒｎａｌ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅ  Ｌｏｗ  Ｆｌａｇ）フィールドは、当該ＬＣＴパケットヘッダーの拡張に、３２ビットの外部タイムラインリファレンスフィールドが含まれることを示すことができる。
【１７４９】
ＩＴＲ  Ｓｃａｌｅフィールドは、当該ＬＣＴパケットヘッダーの拡張に、３２ビットの内部タイムラインリファレンスタイムスケールフィールドが含まれることを示すことができる。
【１７５０】
ＥＴＲ  Ｓｃａｌｅフィールドは、当該ＬＣＴパケットヘッダーの拡張に、３２ビットを外部タイムラインリファレンスタイムスケールフィールドが含まれることを示すことができる。
【１７５１】
ＩＴＲ  Ｆｏｒｍａｔフィールドは、当該ＬＣＴパケットヘッダーの拡張に含まれた内部タイムラインリファレンスフィールドのフォーマットを示すことができる。すなわち、このフィールドは、内部網で伝送されるメディアストリームのタイムラインリファレンスのフォーマットを示すことができる。
【１７５２】
ＥＴＲ  Ｆｏｒｍａｔフィールドは、当該ＬＣＴパケットヘッダーの拡張に含まれた外部タイムラインリファレンスフィールドのフォーマットを示すことができる。すなわち、このフィールドは、外部網で伝送されるメディアストリームのタイムラインリファレンスのフォーマットを示すことができる。
【１７５３】
ＩＴＲ  Ｆｏｒｍａｔフィールド及びＥＴＲ  Ｆｏｒｍａｔフィールドの値が０ｘ００である場合、当該タイムラインリファレンスはメディアタイム（ｍｅｄｉａ  ｔｉｍｅ）フォーマットを有し、０ｘ０１である場合にはＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）フォーマットを有し、０ｘ０２である場合にはＰＴＰフォーマットを有し、０ｘ０３である場合にはタイムコード（ｔｉｍｅ  ｃｏｄｅ）フォーマットを有することができる。０ｘ０４乃至０ｘ０Ｆの値を有する場合には、将来の使用のために残しておくことができる。
【１７５４】
ＵＲＬ（外部メディアＵＲＬフラグ）フィールドは、当該ＬＣＴパケットのヘッダーの拡張に外部メディアＵＲＬフィールドが存在するか否かを示すフラグであってもよい。
【１７５５】
ＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ  Ｆｌａｇ）フィールドは、当該ＬＣＴパケットのヘッダーの拡張にＳｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙフィールドが含まれているか否かを示すフラグであってもよい。
【１７５６】
ＳＰＤ  Ｓｃａｌｅフィールドは、当該ＬＣＴパケットのヘッダーの拡張にｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙ  ｔｉｍｅｓｃａｌｅフィールドが含まれているか否かを示すフラグであってもよい。このフラグフィールドが０に設定される場合、ｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙ  ｔｉｍｅｓｃａｌｅフィールドが存在しなくてもよい。この場合、ｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙフィールドは、ＳＰＤを秒単位のノーマルクロック（ｎｏｒｍａｌ  ｃｌｏｃｋ）で表現することができる。
【１７５７】
ＵＳＥフィールドの余りビットは、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。
【１７５８】
Ｓｅｎｄｅｒ  Ｃｕｒｒｅｎｔ  Ｔｉｍｅフィールド、Ｅｘｐｅｃｔｅｄ  Ｒｅｓｉｄｕａｌ  Ｔｉｍｅフィールド、Ｓｅｓｓｉｏｎ  Ｌａｓｔ  Ｃｈａｎｇｅｄフィールドは、前述したとおりである。
【１７５９】
Ｉｎｔｅｒｎａｌ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅフィールドは、内部網で伝送されるメディアストリームのタイムラインリファレンス情報を示すことができる。このフィールドの値に基づいて、内部網で伝送されるメディアストリームのタイムラインを再構成することができる。前述したＩＴＲ  Ｈｉフィールド又はＩＴＲ  Ｌｏｗフィールドの値によって、このフィールドが存在するか否かが決定されてもよい。
【１７６０】
Ｅｘｔｅｒｎａｌ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅフィールドは、外部網で伝送されるメディアストリームのタイムラインリファレンス情報を示すことができる。このフィールドの値に基づいて、外部網で伝送されるメディアストリームのタイムラインを再構成することができる。前述したＥＴＲ  Ｈｉフィールド又はＥＴＲ  Ｌｏｗフィールドの値によって、このフィールドが存在するか否かが決定されてもよい。
【１７６１】
Ｉｎｔｅｒｎａｌ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅ  Ｔｉｍｅｓｃａｌｅフィールドは、内部網で伝送されるメディアストリームのタイムラインリファレンスの時間単位をＨｚで示すことができる。このフィールドは、前述したＩＴＲ  Ｓｃａｌｅフィールドによってその存否が決定されてもよい。
【１７６２】
Ｅｘｔｅｒｎａｌ  Ｔｉｍｅｌｉｎｅ  Ｒｅｆｅｒｅｎｃｅ  Ｔｉｍｅｓｃａｌｅフィールドは、外部網で伝送されるメディアストリームのタイムラインリファレンスの時間単位をＨｚで示すことができる。このフィールドは、前述したＥＴＲ  Ｓｃａｌｅフィールドによってその存否が決定されてもよい。
【１７６３】
外部メディアＵＲＬフィールドは、外部網で伝送されるメディアの位置情報及び／又は当該メディアの固有識別情報を含むことができる。この情報に基づいて、外部網で伝送されるメディアに接近することができる。例えば、外部網で伝送されるメディアがＤＡＳＨによるメディアである場合、メディアの当該ＭＰＤのＭＰＤ  ＵＲＬ、ＭＰＤ  ＩＤなどの情報がＵＲＬフィールドに含まれてもよい。
【１７６４】
ｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙフィールドは、ＳＰＤ情報を含むことができる。すなわち、外部網又は内部網で伝送されるメディアストリームの生成時点を基準に消費時点までの提案遅延時間を、このフィールドで表現することができる。内部網又は外部網で伝送されるメディアストリームのタイムラインが再構成される時、各タイムラインリファレンス値からこのフィールドの値を引いた値を反映してタイムラインを構成することができる。
【１７６５】
ｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙ  ｔｉｍｅｓｃａｌｅフィールドは、前述したｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙフィールドが示すＳＰＤ情報の時間単位を示すことができる。この時間単位は実施例によってＨｚであってもよい。
【１７６６】
Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎｓフィールド、ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤフィールド、Ｅｎｃｏｄｉｎｇ  Ｓｙｍｂｏｌ（ｓ）フィールドは、前述したとおりである。
【１７６７】
図１３７は、本発明の他の実施例に係るＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を含むＬＣＴパケット構造を示す図である。
【１７６８】
本実施例は、前述したＳＰＤを含むＬＣＴパケット構造と類似しているが、Ｓｅｎｄｅｒ  Ｃｕｒｒｅｎｔ  Ｔｉｍｅフィールド、Ｅｘｐｅｃｔｅｄ  Ｒｅｓｉｄｕａｌ  Ｔｉｍｅフィールド及び／又はＳｅｓｓｉｏｎ  Ｌａｓｔ  Ｃｈａｎｇｅｄフィールドが省略されてもよい。このフィールドが省略されることにより、これらのフィールドのフラグフィールドであるＳＣＴ  Ｈｉフィールド、ＳＣＴ  Ｌｏｗフィールド、ＥＲＴフィールド及び／又はＳＬＣフィールドも省略されてもよい。
【１７６９】
省略されたフィールドは、一般目的のタイミング情報であり、内／外部網を介したタイムラインリファレンス情報がＬＣＴパケットに既に含まれており、省略されてもいいわけである。これによって、ＬＣＴパケット構造の効率性を挙げることもできる。
【１７７０】
図１３８は、本発明の更に他の実施例に係るＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。
【１７７１】
ＡＬＣ／ＬＣＴパケットヘッダーの拡張は様々なタイプを含むことができる。ヘッダーの拡張タイプとして、サーバーのウォールクロック（ｗａｌｌ  ｃｌｏｃｋ）などの時間関連の情報を伝達するヘッダー拡張（ＥＸＴ＿ＴＩＭＥ）を挙げることができる。本実施例は、ＥＸＴ＿ＴＩＭＥの一実施例を示す。
【１７７２】
本実施例で、ＨＥＴフィールド、ＨＥＬフィールド、ＳＣＴ  Ｈｉフィールド、ＳＣＴ  Ｌｏｗフィールド、ＥＲＴフィールド（又はＥＲＴ  ｆｌａｇフィールド）、ＳＬＣフィールド（又はＳＬＣ  ｆｌａｇフィールド）、Ｒｅｓフィールド（又はＲｅｓ．ｂｙ  ＬＣＴフィールド）、ＳＰＤフィールド（又はＳＰＤ  ｆｌａｇフィールド）、Ｓｅｎｄｅｒ  Ｃｕｒｒｅｎｔ  Ｔｉｍｅフィールド、Ｅｘｐｅｃｔｅｄ  Ｒｅｓｉｄｕａｌ  Ｔｉｍｅフィールド、Ｓｅｓｓｉｏｎ  Ｌａｓｔ  Ｃｈａｎｇｅｄフィールド及び／又はＳｕｅｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ  Ｔｉｍｅｓｃａｌｅフィールドは、前述したとおりである。
【１７７３】
本実施例のＬＣＴパケット構造は、前述したＳＰＤを含むＬＣＴパケット構造と類似しているが、ＴＳ  ｆｏｒｍａｔフィールド、ＴＳ  ｖｅｒｓｉｏｎフィールド及び／又はＴｉｍｅｓｔａｍｐフィールドをさらに含むことができる。同図でＬＣＴパケット構造の拡張部分以外の部分は省略されている。
【１７７４】
ＴＳ  ｆｏｒｍａｔフィールドは、当該ＬＣＴパケットのヘッダー拡張部分に含まれたｔｉｍｅｓｔａｍｐフィールドのフォーマットを示すことができる。例えば、このフィールドの値が０ｘ０１である場合、タイムスタンプはメディアタイム（ｍｅｄｉａ  ｔｉｍｅ）フォーマットを有することができ、０ｘ０２である場合にはＮＴＰフォーマット、０ｘ０３である場合にはノーマルプレイングタイム（ｎｏｒｍａｌ  ｐｌａｙｉｎｇ  ｔｉｍｅ）フォーマット、０ｘ０４である場合にはＳＭＰＴＥタイムコードフォーマット、０ｘ０５である場合には９０ＫＨｚベースのタイムスタンプフォーマットを有することができる。このフィールドの値が０ｘ００又は０ｘ０６乃至０ｘ０Ｆである場合、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。
【１７７５】
ＴＳ  ｖｅｒｓｉｏｎフィールドは、当該ＬＣＴパケットのヘッダー拡張部分に含まれたｔｉｍｅｓｔａｍｐフィールドの構成を示すことができる。例えば、このフィールドの値が０である場合、ｔｉｍｅｓｔａｍｐフィールドは３２ビット、１である場合、ｔｉｍｅｓｔａｍｐフィールドは６４ビットであってもよい。実施例によってｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙフィールドとｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙ  ｔｉｍｅｓｃａｌｅフィールドも、このフィールドの値によって同じ方式で長さが定められてもよい。又は、実施例によって、別のフィールドを設けて、ｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙフィールドとｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙ  ｔｉｍｅｓｃａｌｅフィールドの長さを表現してもよい。
【１７７６】
ＳＰＤＴ  ｆｌａｇフィールドは、前述したＳＰＤ  ｓｃａｌｅフィールドと同一であってもよい。ただし、実施例によって、このフィールドの値が０に設定される場合、ｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙが存在しないように設定されてもよい。
【１７７７】
Ｔｉｍｅｓｔａｍｐフィールドは、当該ＡＬＣ／ＬＣＴパケットのペイロードに含まれたデータに関連したタイミング情報を含むことができる。例えば、このフィールドの値は、ペイロードに含まれたデータの最初のバイトがデコードされる時点に関する情報を示すことができる。また、実施例によって、このフィールドの値は、当該データの再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅ）情報を示すことができる。このフィールドは、タイムスタンプの時間単位及び／又は当該時間単位ベースのタイミング情報などを共に含むことができる。又は、実施例によって、このフィールドは、送信側の現在時間、当該メディアデータのエンコーディング時間、当該メディアデータの最初のバイトがデコードされる時点などのタイミング情報にＳＰＤ（提案遅延時間）を加算した値を有することができる。
【１７７８】
Ｓｕｅｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙフィールドは、ＳＰＤ情報を含むことができる。このフィールドは、当該ＡＬＣ／ＬＣＴパケットのペイロードデータ又はペイロードデータを含むオブジェクトの生成時点を基準に消費時点までの提案遅延時間を示すことができる。前述したｔｉｍｅｓｔａｍｐフィールドのタイムスタンプ値を同期化に用いるとき、ＳＰＤ値を活用することができる。すなわち、タイムスタンプ値にＳＰＤ値を加算した値を反映して同期化を行うことによって、提案遅延時間の反映された同期化を取ることができる。
【１７７９】
図１３９は、本発明の更に他の実施例に係るＳＰＤ（ｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。
【１７８０】
本発明は、ＡＬＣ／ＬＣＴパケット構造のヘッダー拡張部分において、新しいヘッダー拡張構造であるＥＸＴ＿ＯＢＪ＿ＩＮＦＯを提案する。この新しいヘッダー拡張構造は、伝送オブジェクトのタイプ関連情報及び／又は当該伝送オブジェクトに関連したタイミング情報などを含むことができる。この新しいヘッダー拡張構造は、ＡＬＣ／ＬＣＴパケットヘッダーの拡張フィールド（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ）に含めることができ、コンテンツ伝送プロトコルパケットヘッダーの一部などとして用いることができる。
【１７８１】
本実施例はＥＸＴ＿ＯＢＪ＿ＩＮＦＯの一実施例を示す。本実施例で、ＨＥＴフィールド、ＨＥＬフィールド、ＳＰＤフィールド（又はＳＰＤ  ｆｌａｇフィールド）、ＳＤＰＴ  ｆｌａｇフィールド、Ｔｉｍｅｓｔａｍｐフィールド、Ｓｕｅｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙフィールド及び／又はＳｕｅｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ  Ｔｉｍｅｓｃａｌｅフィールドは、前述したとおりである。
【１７８２】
本実施例のＬＣＴパケット構造は、前述したＳＰＤを含むＬＣＴパケット構造と類似しているが、Ｏｂｊｅｃｔ  ｔｙｐｅフィールド及び／又はＭフィールドがさらに含まれてもよい。同図で、ＬＣＴパケット構造の拡張部分以外の部分は省略されている。
【１７８３】
Ｏｂｊｅｃｔ  Ｔｙｐｅフィールドは、当該伝送オブジェクトのタイプを示すことができる。このフィールドが示す伝送オブジェクトのタイプは、ＲＴＰパケットヘッダーのペイロードタイプ値と類似の値を有することができる。実施例によって、このフィールドの値は、様々な伝送オブジェクトのタイプを示すことができる。例えば、このフィールドの値が０ｘ０１である場合、伝送オブジェクトのタイプは、普通のファイルフォーマット（ｒｅｇｕｌａｒ  ｆｉｌｅ）、０ｘ０２の場合にはＨＴＴＰエンティティ（ｅｎｔｉｔｙ）フォーマット、０ｘ０３の場合にはＡＡＣベースのオーディオデータフォーマット、０ｘ０４の場合にはＨ．２６４ベースのビデオデータフォーマット、０ｘ０５の場合にはＨＥＶＣベースのビデオデータフォーマット、０ｘ０６の場合にはＤＡＳＨセグメント（Ｓｅｇｍｅｎｔ）又はＩＳＯベースメディアファイル（ＩＳＯ  ｂａｓｅ  ｍｅｄｉａ  ｆｉｌｅ）フォーマット、０ｘ０７の場合にはメタデータフォーマットを有することができる。このフィールドの値が０ｘ００又は０ｘ０７以上の値の場合は、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。
【１７８４】
Ｍフィールドは、マーカー（ｍａｒｋｅｒ）の役割を担うフィールドであり、Ｏｂｊｅｃｔ  Ｔｙｐｅフィールドの値によって様々な対象を示すことができる。例えば、Ｏｂｊｅｃｔ  Ｔｙｐｅフィールドの示すオブジェクトタイプがファイルである場合、Ｍフィールドはそのファイルの始め又は終わりを示すことができる。また、Ｏｂｊｅｃｔ  Ｔｙｐｅフィールドが示すオブジェクトタイプがビデオ／オーディオデータである場合、Ｍフィールドは、関連したデータユニットの始め又は終わりを示すことができる。Ｍフィールドは、マーカービット（ｍａｒｋｅｒ  ｂｉｔ）フィールドと呼ぶこともできる。
【１７８５】
本実施例で、Ｔｉｍｅｓｔａｍｐフィールド、ｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙフィールド及び／又はｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙ  ｔｉｍｅｓｃａｌｅフィールドの長さは、３２、６４ビットなどであって、同じ固定長を有することができる。その長さは、別の長さフィールドで示してもよく、ＨＥＬフィールドで示してもよい。
【１７８６】
図１４０は、本発明の更に他の実施例に係るＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。
【１７８７】
本実施例は、前述したＥＸＴ＿ＯＢＪ＿ＩＮＦＯの他の構造を提案する。前述したＥＸＴ＿ＯＢＪ＿ＩＮＦＯの構造に比べて、ＴＳ  ｆｌａｇフィールド、ＴＳ  ｆｏｒｍａｔフィールド及び／又はＴＳ  ｖｅｒｓｉｏｎフィールドがさらに含まれてもよい。同図で、ＬＣＴパケット構造の拡張部分以外の部分は省略されている。
【１７８８】
ＴＳ  ｆｌａｇフィールドは、当該ヘッダー拡張構造にｔｉｍｅｓｔａｍｐフィールドが存在するか否かを示すフラグであってもよい。実施例によって、このフィールドの値が１である場合、ｔｉｍｅｓｔａｍｐフィールドが存在し、０である場合には存在しなくてもよい。実施例によって、このフィールドの値が示す意味が異なってもよい。
【１７８９】
ＴＳ  ｆｏｒｍａｔフィールド、ＴＳ  ｖｅｒｓｉｏｎフィールドは、前述したとおりである。ただし、これらのフィールドは、ＴＳ  ｆｌａｇフィールドが１である場合、すなわち、ｔｉｍｅｓｔａｍｐフィールドが存在すると示される場合において、当該タイムスタンプのフォーマット及びバージョンを示すことができる。
【１７９０】
その他の同名のフィールドは、前述したとおりである。
【１７９１】
図１４１は、本発明の更に他の実施例に係るＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。
【１７９２】
本実施例は、前述したＥＸＴ＿ＯＢＪ＿ＩＮＦＯの更に他の構造を提案する。前述したＥＸＴ＿ＯＢＪ＿ＩＮＦＯの構造に比べて、Ｅｘｔ  ｆｌａｇフィールド及び／又はＥｘｔｅｎｔｉｏｎフィールドをさらに含むことができる。同図で、ＬＣＴパケット構造の拡張部分以外の部分は省略されている。
【１７９３】
Ｅｘｔ  Ｆｌａｇフィールドは、当該ヘッダー拡張構造にｅｘｔｅｎｓｉｏｎフィールドが存在するか否かを示すフラグであってもよい。実施例によって、このフィールドの値が１である場合、ｅｘｔｅｎｓｉｏｎフィールドが存在し、０である場合、存在しなくてもよい。実施例によって、このフィールドの値が示す意味が異なってもよい。
【１７９４】
Ｅｘｔｅｎｓｉｏｎフィールドは、当該伝送オブジェクトに関連した付加情報を含むことができる。例えば、伝送オブジェクトのロケーション（ｌｏｃａｔｉｏｎ）情報などが含まれてもよい。ここで、伝送オブジェクトのロケーション情報とは、当該情報が得られる位置情報であり、例えば、ＤＡＳＨセグメントが伝送オブジェクトとして伝送される場合、伝送オブジェクトのロケーションはＤＡＳＨセグメントのＵＲＬであってもよい。このフィールドは、拡張の役割として、伝送オブジェクトと関連した様々な情報が実施例によって追加されてもよい。
【１７９５】
その他の同名のフィールドは、前述したとおりである。
【１７９６】
図１４２は、本発明の更に他の実施例に係るＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。
【１７９７】
本発明は、ＡＬＣ／ＬＣＴパケット構造のヘッダー拡張部分において、新しいヘッダー拡張構造であるＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥを提案する。この新しいヘッダー拡張構造は、メディアデータのタイミング関連情報、タイムスタンプなどの情報を含むことができる。この新しいヘッダー拡張構造は、ＡＬＣ／ＬＣＴパケットヘッダーの拡張フィールド（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ）に含めることができ、コンテンツ伝送プロトコルパケットヘッダーの一部などとして用いることができる。
【１７９８】
本実施例は、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥの一実施例を示す。ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥの場合、ＥＸＴ＿ＯＢＪ＿ＩＮＦＯと違い、Ｏｂｊｅｃｔ  Ｔｙｐｅフィールド、Ｍフィールド、ＴＳ  ｆｌａｇフィールドなどが省略されてもよい。同図で、ＬＣＴパケット構造の拡張部分以外の部分は省略されている。
【１７９９】
ＴＳ  ｆｏｒｍａｔフィールドは、前述したとおりである。ただし、この場合、このフィールドはその値によって、タイムスタンプがＧＰＳタイムフォーマットを有することを示すこともできる。
【１８００】
ＴＳ  ｖｅｒｓｉｏｎフィールドは、前述したとおりである。ただし、この場合、このフィールドは、タイムスタンプの時間単位情報が存在するか否かをさらに示すこともできる。
【１８０１】
Ｅｘｔ  Ｆｌａｇｓフィールドは、ｅｘｔｅｎｓｉｏｎフィールドが含む細部フィールドに対するフラグフィールドの集合であってもよい。すなわち、このフィールドは、ｅｘｔｅｎｓｉｏｎフィールドの構成を示すことができる。又は、実施例によって、前述したＥｘｔ  ｆｌａｇフィールドのように、ｅｘｔｅｎｔｉｏｎフィールドが存在するか否かを示すこともできる。Ｅｘｔｅｎｓｉｏｎフィールドは、このフィールドの値によってマップされたタイムライン関連情報などの様々な情報を含むことができる。
【１８０２】
その他の同名のフィールドは、前述したとおりである。
【１８０３】
図１４３は、本発明の更に他の実施例に係るＳＰＤ（Ｓｕｇｇｅｓｔｅｄ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｌａｙ）を含むＬＣＴパケット構造の拡張部分を示す図である。
【１８０４】
本発明は、ＡＬＣ／ＬＣＴパケット構造のヘッダー拡張部分において、新しいヘッダー拡張構造であるＥＸＴ＿ＴＩＭＥ＿ＭＡＰを提案する。この新しいヘッダー拡張構造は、ＡＬＣ／ＬＣＴパケットヘッダーの拡張フィールド（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ）に含めることができ、コンテンツ伝送プロトコルパケットヘッダーの一部などとして用いることができる。
【１８０５】
ＥＸＴ＿ＴＩＭＥ＿ＭＡＰは、前述したタイムラインコンポーネントＡＵ又はタイムラインリファレンス情報ＡＵを含むメタデータを一つの伝送オブジェクトで伝達する役割を担うことができる。これは、伝送オブジェクトが他のタイムラインとの同期化を必要とする場合、両タイムライン間のマッピング情報を受信機に伝達するためであってもよい。ＥＸＴ＿ＴＩＭＥ＿ＭＡＰによれば、別の伝送オブジェクトが伝達される必要がなく、ヘッダーの拡張部分にこの構造を挿入して必要な情報を伝達することができる。伝達された情報を用いて、当該パケットのペイロードの再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅ）をＧＰＳタイムなどにマップすることができる。
【１８０６】
ＥＸＴ＿ＴＩＭＥ＿ＭＡＰは、ＯＴＳ  ｆｌａｇフィールド、ＯＴＳ  ｆｏｒｍａｔフィールド、ＯＴＳ  ｖｅｒｓｉｏｎフィールド、Ｌｏｃａｔｉｏｎ  ｆｌａｇフィールド、Ｏｒｉｇｉｎａｌ  ｔｉｍｅｓｔａｍｐフィールド、Ｌｏｃａｔｉｏｎフィールドなどをさらに含むことができる。
【１８０７】
ＴＳ  ｆｏｒｍａｔフィールドは前述したとおりであるが、実施例によって、このフィールドは、タイムスタンプがＧＰＳタイムフォーマットであることを示すこともできる。
【１８０８】
ＯＴＳ  Ｆｌａｇフィールドは、当該パケットヘッダー拡張部分にｏｒｉｇｉｎａｌ  ｔｉｍｅｓｔａｍｐフィールドが存在するか否かを示すフラグであってもよい。実施例によって、このフィールドの値が１である場合、ｏｒｉｇｉｎａｌ  ｔｉｍｅｓｔａｍｐフィールドが存在し、０である場合、存在しなくてもよい。実施例によって、このフィールドの値の意味が異なってもよい。
【１８０９】
ＯＴＳ  ｆｏｒｍａｔフィールドは、ｏｒｉｇｉｎａｌ  ｔｉｍｅｓｔａｍｐフィールドのフォーマットを示すことができる。実施例によって、このフィールドは様々なタイムスタンプフォーマットを示すことができる。例えば、このフィールドの値が０ｘ０１である場合、タイムスタンプはメディアタイム（ｍｅｄｉａ  ｔｉｍｅ）フォーマットを有することができ、０ｘ０２の場合にはＮＴＰフォーマット、０ｘ０３の場合にはノーマルプレイングタイム（ｎｏｒｍａｌ  ｐｌａｙｉｎｇ  ｔｉｍｅ）フォーマット、０ｘ０４の場合にはＳＭＰＴＥタイムコードフォーマット、０ｘ０５の場合には９０ＫＨｚベースのタイムスタンプフォーマットを有することができる。このフィールドの値が０ｘ００又は０ｘ０６乃至０ｘ０Ｆである場合には、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。
【１８１０】
ＯＴＳ  ｖｅｒｓｉｏｎフィールドは、含まれたｏｒｉｇｉｎａｌ  ｔｉｍｅｓｔａｍｐフィールドのバージョン或いは構成を示すことができる。例えば、このフィールドの値が０である場合、ｏｒｉｇｉｎａｌ  ｔｉｍｅｓｔａｍｐフィールドは３２ビット、１である場合、ｏｒｉｇｉｎａｌ  ｔｉｍｅｓｔａｍｐは１６ビットのサイズを有することができる。
【１８１１】
Ｌｏｃａｔｉｏｎ  Ｆｌａｇフィールドは、当該パケットヘッダー拡張部分にｌｏｃａｔｉｏｎフィールドが存在するか否かを示すフラグであってもよい。実施例によって、このフィールドの値が１である場合、ｌｏｃａｔｉｏｎフィールドが存在し、０である場合には存在しなくてもよい。実施例によって、このフィールドの値の意味が異なってもよい。
【１８１２】
Ｔｉｍｅｓｔａｍｐフィールドは、前述したとおりである。このフィールドは、Ｏｒｉｇｉｎａｌ  Ｔｉｍｅｓｔａｍｐフィールドによって表現される伝送オブジェクトのタイムスタンプにマップされるタイムラインのタイムスタンプを含むことができる。このフィールドのタイムスタンプは、ｏｒｉｇｉｎａｌ  ｔｉｍｅｓｔａｍｐフィールドによって表現されるタイムラインにマップすることができる。
【１８１３】
Ｏｒｉｇｉｎａｌ  Ｔｉｍｅｓｔａｍｐフィールドはｔｉｍｅｓｔａｍｐフィールドのタイムスタンプとマッピング関係を有する、伝送オブジェクトのタイムスタンプ情報を含むことができる。このフィールドのタイムスタンプは、ｔｉｍｅｓｔａｍｐフィールドによって表現されるタイムラインにマップすることができる。又は、実施例によって、このフィールドは、送信側の現在時間、当該メディアデータのエンコーディング時間、当該メディアデータの最初のバイトがデコードされる時点などのタイミング情報にＳＰＤ（提案遅延時間）を加算した値を有することができる。
【１８１４】
Ｌｏｃａｔｉｏｎフィールドは、マップされるタイムラインに関連したデータのロケーション情報などを含むことができる。例えば、タイムスタンプが特定ＤＡＳＨセグメントのタイムラインにマップされる場合、ＤＡＳＨセグメントに対するＵＲＬ情報がこのフィールドに含まれてもよい。
【１８１５】
その他の同名のフィールドは、前述したとおりである。
【１８１６】
前述したＬＣＴパケットのヘッダー又はヘッダーの拡張部分の役割を担うために、ＲＯＵＴＥのプレゼンテーションタイムヘッダー（ＥＸＴ＿ＲＯＵＴＥ＿ＰＲＥＳＥＮＴＡＴＩＯＮ＿ＴＩＭＥ）が用いられてもよい。また、実施例によって、前述したＬＣＴパケットのヘッダー又はヘッダーの拡張部分の役割を担うために、ＩＥＴＦのＲＦＣ５６５１、“Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ（ＬＣＴ）  Ｂｕｉｌｄｉｎｇ  Ｂｌｏｃｋ”のＥＸＴ＿ＴＩＭＥヘッダーが用いられてもよい。
【１８１７】
前述したＬＣＴパケットのヘッダー又はヘッダーの拡張部分は、ＥＸＴ＿ＲＯＵＴＥ＿ＰＲＥＳＥＮＴＡＴＩＯＮ＿ＴＩＭＥの一実施例であってもよい。また、実施例によって、前述したＬＣＴパケットのヘッダー又はヘッダーの拡張部分は、ＥＸＴ＿ＴＩＭＥヘッダーの一実施例であってもよい。前述したＬＣＴパケットのヘッダー又はヘッダーの拡張部分は、前述したように、タイミング関連情報を伝達することができる。
【１８１８】
本発明の更に他の実施例に係るＬＣＴパケットヘッダーは、６４ビットＮＴＰタイムスタンプの３番目、４番目及び５番目のオクテットを表現することができる。この実施例のヘッダーは、ＨＥＴフィールドを有することができ、また、固定長を有することができる。この実施例のヘッダーの値は、ＳＣＴよりも大きくてもよい。この実施例のＬＣＴパケットヘッダーは、総４バイトのサイズを有することができる。
【１８１９】
本発明の更に他の実施例に係るＬＣＴパケットヘッダーは、６４ビットＮＴＰタイムスタンプ値を全て有することもできる。この実施例のヘッダーは、ＨＥＴフィールド及び／又はＨＥＬフィールドを有することができる。この実施例のＬＣＴパケットヘッダーは、総１２バイトのサイズを有することができる。したがって、その他のビット数は、将来の使用のために残しておくことができる（Ｒｅｓｅｒｖｅｄ）。
【１８２０】
図１４４は、本発明の一実施例に係る放送コンテンツを送信する方法を示す図である。
【１８２１】
本発明の一実施例に係る放送コンテンツを受信する方法は、放送コンテンツに対する第１メディアストリームを生成する段階、放送コンテンツに対する第２メディアストリームを生成する段階、第１メディアストリームを放送網を介して送信する段階、第２メディアストリームに対する要求を受ける段階、及び／又は第２メディアストリームをインターネット網を介して受信機に送信する段階を含むことができる。
【１８２２】
まず、放送コンテンツに対する第１メディアストリームを生成することができる。この過程は、第１モジュールで行うことができる。ここで、第１メディアストリームは、放送網で伝送されるメディアストリームであってもよい。前述した実施例で、内部網で伝送されるメディアストリームが第１メディアストリームに該当してもよい。この第１メディアストリームは、複数個のパケットが連続した形態を有することができる。このうち、少なくとも一つのパケットは時間情報を含むことができる。ここで、時間情報とは、時間に関連した全情報を総称する統合的な概念である。実施例によって、前述したタイミング関連ＬＣＴパケットヘッダーの拡張部分、タイムラインリファレンス情報ＡＵ、タイムラインコンポーネントＡＵなどがこの時間情報に該当し得る。
【１８２３】
前述した放送コンテンツに対する第２メディアストリームを生成することができる。この過程は、第２モジュールで行うことができる。ここで、第２メディアストリームは、インターネット網で伝送されるメディアストリームであってもよい。前述した実施例で、外部網で伝送されるメディアストリームが第２メディアストリームに該当してもよい。第１モジュールと第２モジュールとが統合されて一つのモジュールとして動作してもよい。
【１８２４】
生成された第１メディアストリームは、放送網を介して受信側に伝送することができる。この過程は、第３モジュールで行うことができる。また、生成された第２メディアストリームは、インターネット網を介して受信側に伝送することができる。この過程は、第４モジュールで行うことができる。第４モジュールは、受信機から第２メディアストリームに対する要求を受け、その要求に応じて受信側に該当のメディアストリームを伝送することができる。このような要求は、前述したｅｘｔｅｒｎａｌ＿ｍｅｄｉａ＿ＵＲＬフィールドによって行うことができる。
【１８２５】
本発明の他の実施例に係る放送コンテンツを送信する方法は、前述した第１メディアストリームのパケットが前述した時間情報を含む拡張ヘッダーを含むことができる。この拡張ヘッダーは、前述したＬＣＴパケットヘッダーの拡張部分であってもよい。ここで、前述した時間情報は、第１メディアストリームの再生時刻（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅ）を示すタイムスタンプ情報を含むことができる。このタイムスタンプ情報は、前述したｔｉｍｅｓｔａｍｐフィールドに該当し得る。
【１８２６】
本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述した拡張ヘッダーがタイムスタンプの一部だけを含むことができる。前述したように、本発明の一実施例に係る拡張ヘッダーは、６４ビットＮＴＰタイムスタンプの３番目、４番目及び５番目のオクテットを表現することができる。前述した拡張ヘッダーがタイムスタンプの一部だけを含む場合、タイムスタンプの一部のオクテットだけを含むことができる。
【１８２７】
本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述した拡張ヘッダーが第２メディアストリームの再生時刻を示すタイムスタンプ情報をさらに含むことができる。ここで、第２メディアストリームの再生時刻を示すタイムスタンプは、前述したｏｒｉｇｉｎａｌ  ｔｉｍｅｓｔａｍｐフィールドによって表現されるタイムスタンプを意味することができる。すなわち、前述したように、拡張ヘッダーは、ｏｒｉｇｉｎａｌ  ｔｉｍｅｓｔａｍｐフィールドをさらに含むことができる。
【１８２８】
本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述した拡張ヘッダーが、第１メディアストリームの生成時点から消費時点までの提案遅延時間に関する情報をさらに含むことができる。ここで、提案遅延時間に関する情報は前述したＳＰＤを意味することができる。拡張ヘッダーは、ｓｕｇｇｅｓｔｅｄ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｌａｙフィールドをさらに含むことができる。受信機は、このＳＰＤをタイムスタンプ値に加算して、ＳＰＤの反映された同期化を取ることができる。
【１８２９】
本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述した第１メディアストリームの再生時刻を示すタイムスタンプが、ＳＰＤが既に反映されたタイムスタンプ値を有することができる。タイムスタンプフィールドは、タイムスタンプ値にＳＰＤ値を加算した値を含むことができる。したがって、ＳＰＤの反映された再生時刻を表現することができる。
【１８３０】
本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述したパケットがタイムラインリファレンス情報を含んでもよい。リファレンス情報としては、第１メディアストリームのタイムラインを構成する第１タイムラインリファレンス情報及び／又は第２メディアストリームのタイムラインを構成する第２タイムラインリファレンス情報を含むことができる。それぞれのタイムラインリファレンス情報を、各メディアストリームのタイムラインを再構成するために用いることができる。それぞれのタイムラインリファレンスがマップされ、同期化したタイムラインを構成することができる。これを用いて、別個の網で伝送されるメディアストリームを同期化することができる。このようなペイロードを有するパケットは、一般パケットと同じ方式でパケット化されたタイムラインリファレンス情報ＡＵであってもよい。又は、実施例によってこれらのパケットはタイムラインコンポーネントＡＵであってもよい。
【１８３１】
本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述したパケットのペイロードが提案遅延時間に関する情報をさらに含んでもよい。この提案遅延時間情報は、第１メディアストリーム及び／又は第２メディアストリームの生成時点から消費時点までの時間を示すことができる。この意味は、実施例によって異なってもよい。前述したように、タイムラインリファレンス値からＳＰＤ値を減算して、ＳＰＤ値の反映されたタイムラインを再構成することができる。
【１８３２】
本発明の更に他の実施例に係る放送コンテンツを送信する方法は、前述したタイムラインリファレンス情報が、ＳＰＤ値が既に反映されたタイムラインリファレンス値を有することができる。
【１８３３】
本発明の更に他の実施例に係る放送コンテンツを送信する方法で、前述した第１メディアストリームが、前述した放送コンテンツのビデオストリームであり、第２メディアストリームは、放送コンテンツのオーディオストリームであってもよい。
【１８３４】
本発明の一実施例に係る放送コンテンツを受信する方法を説明する。本発明の一実施例に係る放送コンテンツを受信する方法は、図示を省略した。
【１８３５】
本発明の一実施例に係る放送コンテンツを受信する方法は、放送網で第１メディアストリームを受け取る段階、ＵＲＬ情報を用いて要求することによってインターネット網で第２メディアストリームを受け取る段階、第１、第２メディアストリームに対するタイムラインを構成する段階、構成された各タイムラインをマップして、両メディアストリームのタイムラインの同期化を行う段階、及び／又はタイムスタンプ値に基づいて当該メディアデータを特定時刻に再生する段階を含むことができる。
【１８３６】
第１メディアストリームを受け取る段階は、第１受信モジュールで行うことができる。ＵＲＬ情報を用いて要求することによってインターネット網で第２メディアストリームを受け取る段階は、第２受信モジュールで行うことができる。第１、第２メディアストリームに対するタイムラインを構成する段階は、第３受信モジュールで行うことができる。構成された各タイムラインをマップして２メディアストリームのタイムラインの同期化を行う段階は、第４受信モジュールで行うことができる。タイムスタンプ値に基づいて当該メディアデータを特定時刻に再生する段階は、第５受信モジュールで行うことができる。ここで、第３受信モジュールと第４受信モジュールとが統合され、一つのモジュールで行うこともできる。
【１８３７】
各タイムラインは、メディアストリーム内のタイムラインリファレンス情報ＡＵのタイムラインリファレンス情報によって再構成することができる。このとき、各タイムラインをマップし、各メディアストリームを同期化させることができる。共に伝達されたＳＰＤ情報を用いて、ＳＰＤが反映されたタイムラインを再構成することができる。このとき、タイムラインリファレンス値からＳＰＤ値を減算して、ＳＰＤが反映されてもよい。
【１８３８】
また、メディアストリームの各パケットヘッダーにはタイムスタンプ情報が含まれてもよい。このタイムスタンプ情報を用いて各メディアストリームの再生時刻を把握することもできる。共に伝達されたＳＰＤ情報を用いて、ＳＰＤが反映されたタイムスタンプ値を得ることができる。このとき、タイムスタンプ値にＳＰＤ値を加算して、ＳＰＤが反映された当該メディアデータの再生時刻を得ることができる。
【１８３９】
前述した段階は、実施例によって省略されてもよく、類似／同一の動作を行う他の段階に代替されてもよい。
【１８４０】
図１４５は、本発明の一実施例に係る放送コンテンツを送信する装置を示す図である。
【１８４１】
本発明の一実施例に係る放送コンテンツを送信する装置は、第１モジュール、第２モジュール、第３モジュール及び／又は第４モジュールを含むことができる。
【１８４２】
各モジュールは、前述した同名の各モジュールと同一であってもよい。第１モジュールはね放送コンテンツに対する第１メディアストリームを生成する段階を行うことができる。第２モジュールは、放送コンテンツに対する第２メディアストリームを生成する段階を行うことができる。第３モジュールは、第１メディアストリームを放送網で送信する段階を行うことができる。第４モジュールは、第２メディアストリームに対する要求を受ける段階、及び／又は２メディアストリームをインターネット網で受信機に送信する段階を行うことができる。
【１８４３】
本発明の一実施例に係る放送コンテンツを受信する装置を説明する。この放送コンテンツを受信装置は、図示を省略した。
【１８４４】
本発明の一実施例に係る放送コンテンツを受信する装置は、第１受信モジュール、第２受信モジュール、第３受信モジュール、第４受信モジュール及び／又は第５受信モジュールを含むことができる。各モジュールは、前述した同名の各モジュールと同一であってもよい。
【１８４５】
前述したモジュールは、実施例によって省略されてもよく、類似／同一の動作を行う他のモジュールに代替されてもよい。
【１８４６】
前述した第１モジュール、第２モジュール、第３モジュール、第４モジュール、第１受信モジュール、第２受信モジュール、第３受信モジュール、第４受信モジュール及び／又は第５受信モジュールは、メモリに記憶された連続した実行手順を実行するプロセッサであってもよい。また、前述した第１モジュール、第２モジュール、第３モジュール、第４モジュール、第１受信モジュール、第２受信モジュール、第３受信モジュール、第４受信モジュール及び／又は第５受信モジュールは、装置の内部／外部に設けられるハードウェアエレメントであってもよい。
【１８４７】
モジュール又はユニットは、メモリ（又は記憶ユニット）に記憶された連続した実行手順を実行するプロセッサであってもよい。前述した実施例に記述された各段階は、ハードウェア／プロセッサで行うことができる。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明で提示する方法はコードとして実行されてもよい。このコードは、プロセッサで読み取り可能な記憶媒体に書き込むことができ、したがって、装置（ａｐｐａｒａｔｕｓ）が提供するプロセッサで読み取ることができる。
【１８４８】
説明の便宜のために各図を区分して説明したが、各図に示した実施例を併合して新しい実施例を実現するように設計することも可能である。そして、通常の技術者の必要によって、以上説明した実施例を実行するためのプログラムが記録されているコンピュータで読み取り可能な記録媒体を設計することも、本発明の権利範囲に属する。
【１８４９】
本発明に係る装置及び方法は、以上説明した実施例の構成及び方法が限定的に適用されるものではなく、上述した実施例の様々な変形が可能なように、各実施例の全部又は一部を選択的に組み合せて構成することもできる。
【１８５０】
一方、本発明が提案する方法を、ネットワークデバイスに具備された、プロセッサで読み取り可能な記録媒体に、プロセッサで読み取り可能なコードとして具現することができる。プロセッサで読み取り可能な記録媒体は、プロセッサで読み取り可能なデータが記憶されるいずれの種類の記録装置をも含む。プロセッサで読み取り可能な記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサで読み取り可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散され、分散方式でプロセッサで読み取り可能なコードが記憶されて実行されてもよい。
【１８５１】
また、以上では、本発明の好適な実施例について図示及び説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨から逸脱しない限度で、当該発明の属する技術の分野における通常の知識を有する者にとって様々な変形実施が可能であることは無論である。これらの変形実施も、本発明の技術的思想や展望から個別的に理解してはならない。
【１８５２】
そして、本明細書では物の発明、方法の発明の両方が説明されており、必要によって、両発明の説明を補充的に適用してもよい。
【１８５３】
本発明の思想や範囲から逸脱しさい範囲で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むことが意図される。
【１８５４】
本明細書で装置及び方法発明が皆言及されて、装置及び方法発明皆の説明はお互い補完して適用されることができる。
〔実施例〕
【１８５５】
様々な実施例が、本発明を実施するための形態で説明されている。
【産業上の利用可能性】
【１８５６】
本発明は一連の放送信号提供分野で利用される。
【１８５７】
本発明の思想や範囲から逸脱しさい範囲で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むことが意図される。
【図１】
0006325122.tif 000046
【図２】
0006325122.tif 000047
【図３】
0006325122.tif 000048
【図４】
0006325122.tif 000049
【図５】
0006325122.tif 000050
【図６】
0006325122.tif 000051
【図７】
0006325122.tif 000052
【図８】
0006325122.tif 000053
【図９】
0006325122.tif 000054
【図１０】
0006325122.tif 000055
【図１１】
0006325122.tif 000056
【図１２】
0006325122.tif 000057
【図１３】
0006325122.tif 000058
【図１４】
0006325122.tif 000059
【図１５】
0006325122.tif 000060
【図１６】
0006325122.tif 000061
【図１７】
0006325122.tif 000062
【図１８】
0006325122.tif 000063
【図１９】
0006325122.tif 000064
【図２０】
0006325122.tif 000065
【図２１】
0006325122.tif 000066
【図２２】
0006325122.tif 000067
【図２３】
0006325122.tif 000068
【図２４】
0006325122.tif 000069
【図２５】
0006325122.tif 000070
【図２６】
0006325122.tif 000071
【図２７】
0006325122.tif 000072
【図２８】
0006325122.tif 000073
【図２９】
0006325122.tif 000074
【図３０】
0006325122.tif 000075
【図３１】
0006325122.tif 000076
【図３２】
0006325122.tif 000077
【図３３】
0006325122.tif 000078
【図３４】
0006325122.tif 000079
【図３５】
0006325122.tif 000080
【図３６】
0006325122.tif 000081
【図３７】
0006325122.tif 000082
【図３８】
0006325122.tif 000083
【図３９】
0006325122.tif 000084
【図４０】
0006325122.tif 000085
【図４１】
0006325122.tif 000086
【図４２】
0006325122.tif 000087
【図４３】
0006325122.tif 000088
【図４４】
0006325122.tif 000089
【図４５】
0006325122.tif 000090
【図４６】
0006325122.tif 000091
【図４７】
0006325122.tif 000092
【図４８】
0006325122.tif 000093
【図４９】
0006325122.tif 000094
【図５０】
0006325122.tif 000095
【図５１】
0006325122.tif 000096
【図５２】
0006325122.tif 000097
【図５３】
0006325122.tif 000098
【図５４】
0006325122.tif 000099
【図５５】
0006325122.tif 000100
【図５６】
0006325122.tif 000101
【図５７】
0006325122.tif 000102
【図５８】
0006325122.tif 000103
【図５９】
0006325122.tif 000104
【図６０】
0006325122.tif 000105
【図６１】
0006325122.tif 000106
【図６２】
0006325122.tif 000107
【図６３】
0006325122.tif 000108
【図６４】
0006325122.tif 000109
【図６５】
0006325122.tif 000110
【図６６】
0006325122.tif 000111
【図６７】
0006325122.tif 000112
【図６８】
0006325122.tif 000113
【図６９】
0006325122.tif 000114
【図７０】
0006325122.tif 000115
【図７１】
0006325122.tif 000116
【図７２】
0006325122.tif 000117
【図７３】
0006325122.tif 000118
【図７４】
0006325122.tif 000119
【図７５】
0006325122.tif 000120
【図７６】
0006325122.tif 000121
【図７７】
0006325122.tif 000122
【図７８】
0006325122.tif 000123
【図７９】
0006325122.tif 000124
【図８０】
0006325122.tif 000125
【図８１】
0006325122.tif 000126
【図８２】
0006325122.tif 000127
【図８３】
0006325122.tif 000128
【図８４】
0006325122.tif 000129
【図８５】
0006325122.tif 000130
【図８６】
0006325122.tif 000131
【図８７】
0006325122.tif 000132
【図８８】
0006325122.tif 000133
【図８９】
0006325122.tif 000134
【図９０】
0006325122.tif 000135
【図９１】
0006325122.tif 000136
【図９２】
0006325122.tif 000137
【図９３】
0006325122.tif 000138
【図９４】
0006325122.tif 000139
【図９５】
0006325122.tif 000140
【図９６】
0006325122.tif 000141
【図９７】
0006325122.tif 000142
【図９８】
0006325122.tif 000143
【図９９】
0006325122.tif 000144
【図１００】
0006325122.tif 000145
【図１０１】
0006325122.tif 000146
【図１０２】
0006325122.tif 000147
【図１０３】
0006325122.tif 000148
【図１０４】
0006325122.tif 000149
【図１０５】
0006325122.tif 000150
【図１０６】
0006325122.tif 000151
【図１０７】
0006325122.tif 000152
【図１０８】
0006325122.tif 000153
【図１０９】
0006325122.tif 000154
【図１１０】
0006325122.tif 000155
【図１１１】
0006325122.tif 000156
【図１１２】
0006325122.tif 000157
【図１１３】
0006325122.tif 000158
【図１１４】
0006325122.tif 000159
【図１１５】
0006325122.tif 000160
【図１１６】
0006325122.tif 000161
【図１１７】
0006325122.tif 000162
【図１１８】
0006325122.tif 000163
【図１１９】
0006325122.tif 000164
【図１２０】
0006325122.tif 000165
【図１２１】
0006325122.tif 000166
【図１２２】
0006325122.tif 000167
【図１２３】
0006325122.tif 000168
【図１２４】
0006325122.tif 000169
【図１２５】
0006325122.tif 000170
【図１２６】
0006325122.tif 000171
【図１２７】
0006325122.tif 000172
【図１２８】
0006325122.tif 000173
【図１２９】
0006325122.tif 000174
【図１３０】
0006325122.tif 000175
【図１３１】
0006325122.tif 000176
【図１３２】
0006325122.tif 000177
【図１３３】
0006325122.tif 000178
【図１３４】
0006325122.tif 000179
【図１３５】
0006325122.tif 000180
【図１３６】
0006325122.tif 000181
【図１３７】
0006325122.tif 000182
【図１３８】
0006325122.tif 000183
【図１３９】
0006325122.tif 000184
【図１４０】
0006325122.tif 000185
【図１４１】
0006325122.tif 000186
【図１４２】
0006325122.tif 000187
【図１４３】
0006325122.tif 000188
【図１４４】
0006325122.tif 000189
【図１４５】
0006325122.tif 000190