(57)【要約】      （修正有）【課題】地上波放送網とインターネット網が連動する次世代ハイブリッド放送をサポートする放送受信装置を提供する。【解決手段】放送受信装置１００は、パケットを介した伝送の対象である伝送オブジェクトを含むパケットペイロードと、前記パケットペイロードをシグナリングするパケットヘッダで区分される伝送パケットを受信する放送受信部１１０と、前記伝送パケットからパケットヘッダを抽出し、抽出されたパケットヘッダから前記伝送オブジェクトの再生またはデコーティング時点に関する第１情報を抽出して、第１情報に基づいて前記伝送オブジェクトを出力する制御部１５０と、を含む。【選択図】図３５
2018207499.tif 000002
【特許請求の範囲】
【請求項１】
パケットを介した伝送の対象である伝送オブジェクトを含むパケットペイロードと前記パケットペイロードをシグナリングするパケットヘッダに区分される伝送パケットを受信する放送受信部と、
前記伝送パケットから前記パケットヘッダを抽出し、前記抽出されたパケットヘッダから前記伝送オブジェクトの再生またはデコーティング時点に関する第１情報を抽出して、前記第１情報に基づいて前記伝送オブジェクトを出力する制御部と、を含む、放送受信装置。
【請求項２】
前記制御部は前記パケットヘッダから前記伝送オブジェクトのタイプを示す第２情報を取得する、請求項１に記載の放送受信装置。
【請求項３】
前記第２情報は前記伝送オブジェクトの前記タイプがＩＳＯ  ＢＭＦＦベースのレギュラーファイルの第１タイプ、ＨＴＴＰによるエンティティ（ｅｎｔｉｔｙ）の第２タイプ及びオーディオ及びビデオアクセスユニットの第３タイプのうち少なくとも一つであることを示す、請求項２に記載の放送受信装置。
【請求項４】
前記第１情報は前記伝送オブジェクトのタイムスタンプを含む第１時間情報及び前記第１時間情報にマッピングされる基本タイムラインのタイムスタンプを含む第２時間情報のうち少なくとも一つを含む、請求項２に記載の放送受信装置。
【請求項５】
前記パケットヘッダは前記第１時間情報にマッピングされる前記基本タイムラインに関するデータの位置情報を含む、請求項４に記載の放送受信装置。
【請求項６】
前記制御部は前記伝送パケットに前記第２時間情報が含まれているかに関する情報を前記パケットヘッダから取得する、請求項２に記載の放送受信装置。
【請求項７】
前記制御部は前記第１時間情報のフォーマット情報及び第２時間情報のフォーマット情報のうち少なくとも一つを前記パケットヘッダから取得する、請求項６に記載の放送受信装置。
【請求項８】
前記制御部は前記第１情報及び第２情報を、前記パケットヘッダの一部として、前記パケットヘッダに選択的に含まれる拡張されたヘッダから取得する、請求項２に記載の放送受信装置。
【請求項９】
前記制御部は前記パケットヘッダから前記伝送パケットの構造タイプの情報を取得する、請求項１に記載の放送受信装置。
【請求項１０】
前記伝送パケットの前記構造タイプはパケットヘッダ、拡張されたヘッダ、ペイロード識別子及びオブジェクトデータを含む第１構造タイプ、パケットヘッダ及び拡張されたヘッダのみを含む第２構造タイプ、パケットヘッダ、拡張されたヘッダ及びオブジェクトデータのみを含む第３構造タイプを含む、請求項９に記載の放送受信装置。
【請求項１１】
前記第１構造タイプはオブジェクトデータのオフセット情報を更に含む、請求項１０に記載の放送受信装置。
【請求項１２】
パケットを介した伝送の対象である伝送オブジェクトを含むパケットペイロードと前記パケットペイロードをシグナリングするパケットヘッダに区分される伝送パケットを受信するステップと、
前記伝送パケットから前記パケットヘッダを抽出するステップと、
前記抽出されたパケットヘッダから前記伝送オブジェクトの再生またはデコーティング時点に関する第１情報を取得するステップと、
前記第１情報に基づいて前記伝送オブジェクトを出力するステップと、を含む、放送受信装置の動作方法。
【請求項１３】
前記パケットヘッダから前記伝送オブジェクトのタイプを示す第２情報を取得するステップを更に含む、請求項１２に記載の放送受信装置の動作方法。
【請求項１４】
前記第１情報は前記伝送オブジェクトのタイムスタンプを含む第１時間情報及び前記第１時間情報にマッピングされる基本タイムラインのタイムスタンプを含む第２時間情報のうち少なくとも一つを含む、請求項１３に記載の放送受信装置の動作方法。
【請求項１５】
前記抽出されたパケットヘッダに基づいて、前記第２時間情報が前記パケットヘッダに含まれているかを決定するステップを更に含む、請求項１２に記載の放送受信装置の動作方法。
【請求項１６】
前記第１情報及び前記第２情報を前記パケットヘッダの一部として、前記パケットヘッダに選択的に含まれる拡張されたヘッダから取得するステップを更に含む、請求項１３に記載の放送受信装置の動作方法。
【請求項１７】
前記パケットヘッダから前記伝送パケットの構造タイプの情報を取得するステップを更に含む、請求項１２に記載の放送受信装置の動作方法。
【請求項１８】
前記伝送パケットの前記構造タイプはパケットヘッダ、拡張されたヘッダ、ペイロード識別子及びオブジェクトデータを含む第１構造タイプ、パケットヘッダ及び拡張されたヘッダのみを含む第２構造タイプ、パケットヘッダ、拡張されたヘッダ及びオブジェクトデータのみを含む第３構造タイプを含む、請求項１７に記載の放送受信装置の動作方法。
【請求項１９】
パケットを介した伝送の対象である伝送オブジェクトを取得し、前記伝送オブジェクトの再生またはデコーティング時点に関する第１情報及び前記伝送オブジェクトのタイプを示す第２情報のうち少なくとも一つを取得し、データをパケット化するために前記取得した第１情報及び第２情報のうち少なくとも一つをパケットヘッダに設定する制御部と、
前記パケット化されたデータを伝送パケットを介して伝送する伝送部と、を含み、
前記制御部は前記第１情報及び前記第２情報を前記パケットヘッダの一部として、前記パケットヘッダに選択的に含まれる拡張されたヘッダに設定する、放送伝送装置。
【請求項２０】
パケットを介した伝送の対象である伝送オブジェクトを取得するステップと、
前記伝送オブジェクトの再生またはデコーティング時点に関する第１情報及び前記伝送オブジェクトのタイプを示す第２情報のうち少なくとも一つを取得するステップと、
伝送パケットをパケット化するために前記取得した第１情報及び第２情報をパケットヘッダに設定するステップと、
前記パケット化された伝送パケットを伝送するステップと、を含む、放送伝送装置の動作方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法に関するものである。
【背景技術】
【０００２】
最近のデジタル放送は、地上波放送網を介してＡ／Ｖを受信しインターネット網を介してＡ／Ｖ及び向上された（Ｅｎｈａｎｃｅｍｅｎｔ）データを受信するようにするハイブリッド放送をサポートするためのサービス及びコンテンツ伝送同期化方式を必要としている。
【０００３】
特に、今後ＤＴＶサービスで活用される有力なアプリケーションのうち一つとして従来の地上波放送網と共にインターネット網との連動を介したハイブリッド放送サービスがある。ハイブリッド放送サービスは地上波放送網を介して伝送される放送コンテンツに関する向上されたデータまたは放送コンテンツの一部をインターネット網を介してリアルタイムに伝送することで、ユーザが多様なコンテンツを経験することができる。よって、放送コンテンツを地上波放送網及びインターネット網両方を介して伝送し受信する放送伝送装置と放送受信装置が必要である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の実施例は、地上波放送網とインターネット網が連動する次世代ハイブリッド放送をサポートする放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【０００５】
特に、本発明の一実施例は放送サービスのリアルタイムのコンテンツ伝送プロトコル上において、メディアファイルフォーマットベースのデータ伝送のための伝送パケットのペイロード（Ｐａｙｌｏａｄ）フォーマットを利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【０００６】
特に、本発明の一実施例は伝送しようとするオブジェクト（Ｏｂｊｅｃｔ）のタイプ（ｔｙｐｅ）及びオブジェクトのタイミング情報を伝送するための伝送パケット構造を利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【０００７】
特に、本発明の一実施例は伝送しようとするオブジェクト別に相異なるタイミング情報をマッピングするための伝送パケット構造を利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【０００８】
特に、本発明の一実施例は伝送パケットを流動的に構成するための伝送パケット構造を利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一実施例による放送受信装置は、パケットを介した伝送の対象である伝送オブジェクトを含むパケットペイロードと前記パケットペイロードをシグナリングするパケットヘッダで区分される伝送パケットを受信する放送受信部と、前記伝送パケットから前記パケットヘッダを抽出し、前記抽出されたパケットヘッダから前記伝送オブジェクトの再生またはデコーティング時点に関する第１情報を抽出して、前記第１情報に基づいて前記伝送オブジェクトを出力する制御部と、を含む。
【００１０】
この際、前記制御部は前記パケットヘッダから前記伝送オブジェクトのタイプを示す第２情報を取得する。
【００１１】
この際、前記第２情報は前記伝送オブジェクトのタイプがＩＳＯ  ＢＭＦＦベースのレギュラーファイルである第１タイプ、ＨＴＴＰによるエンティティ（ｅｎｔｉｔｙ）である第２タイプ及びオーディオまたはビデオアクセスユニットである第３タイプのうち少なくとも一つである。
【００１２】
この際、前記第１情報は前記伝送オブジェクトのタイムスタンプを含む第１時間情報及び前記第１時間情報とマッピングされる基本タイムラインのタイムスタンプを含む第２時間情報のうち少なくとも一つを含む。
【００１３】
この際、前記パケットヘッダは前記第１時間情報とマッピングされる基本タイムラインに関するデータの位置情報を含む。
【００１４】
この際、前記制御部は前記パケットヘッダに前記第２時間情報が含まれているのか否かに関する情報を前記拡張されたヘッダから取得する。
【００１５】
この際、前記制御部は前記第１時間情報のフォーマット情報及び第２時間情報のフォーマット情報のうち少なくとも一つを前記パケットヘッダから取得する。
【００１６】
この際、前記制御部は前記第１情報及び第２情報を前記パケットヘッダの一部として、前記パケットヘッダに選択的に含まれる拡張されたヘッダから取得する。
【００１７】
この際、前記制御部は前記パケットヘッダから前記伝送パケットの構造タイプの情報を取得する。
【００１８】
この際、前記伝送パケットの構造タイプはパケットヘッダ、拡張されたヘッダ、ペイロード識別子及びオブジェクトデータを含む第１構造タイプ、パケットヘッダ及び拡張されたヘッダのみを含む第２構造タイプ、パケットヘッダ、拡張されたヘッダ及びオブジェクトデータのみを含む第３構造タイプを含む。
【００１９】
この際、前記第１構造タイプはオブジェクトデータのオフセット情報を更に含む。
【００２０】
また、本発明の一実施例による放送受信装置の動作方法は、パケットを介した伝送の対象である伝送オブジェクトのデータを含むパケットペイロードと前記パケットペイロードをシグナリングするパケットヘッダで区分される伝送パケットを受信するステップと、前記伝送パケットから前記パケットヘッダを抽出するステップと、前記抽出されたパケットヘッダから前記伝送オブジェクトの再生及びデコーティング時点に関する第１情報を取得するステップと、前記第１情報に基づいて前記伝送オブジェクトを出力するステップと、を含む。
【００２１】
この際、前記動作方法は前記パケットヘッダから前記伝送オブジェクトのタイプを示す第２情報を取得するステップを更に含む。
【００２２】
この際、前記第２情報は前記伝送オブジェクトのタイプがＩＳＯ  ＢＭＦＦベースのレギュラーファイルである第１タイプ、ＨＴＴＰによるエンティティである第２タイプ及びオーディオまたはビデオアクセスユニットである第３タイプのうち少なくとも一つである。
【００２３】
この際、前記第１情報は前記伝送オブジェクトのタイムスタンプを含む第１時間情報及び前記第１時間情報とマッピングされる基本タイムラインのタイムスタンプを含む第２時間情報のうち少なくとも一つを含む。
【００２４】
この際、前記パケットヘッダは前記第１時間情報とマッピングされる基本タイムラインに関するデータの位置情報を含む。
【００２５】
この際、前記動作方法は前記パケットヘッダに前記第２時間情報が含まれているのか否かに関する情報を前記拡張されたヘッダから取得するステップを更に含む。
【００２６】
この際、前記動作方法は前記第１情報及び第２情報を前記パケットヘッダの一部として、前記パケットヘッダに選択的に含まれる拡張されたヘッダから取得するステップを更に含む。
【００２７】
この際、前記動作方法は前記パケットヘッダから前記伝送パケットの構造タイプの情報を取得する。
【００２８】
この際、前記伝送パケットの構造タイプはパケットヘッダ、拡張されたヘッダ、ペイロード識別子及びオブジェクトデータを含む第１構造タイプ、パケットヘッダ及び拡張されたヘッダのみを含む第２構造タイプ、パケットヘッダ、拡張されたヘッダ及びオブジェクトデータのみを含む第３構造タイプを含む。
【００２９】
また、本発明の一実施例による放送伝送装置は、パケットを介した伝送の対象である伝送オブジェクトを取得し、前記伝送オブジェクトの再生及びデコーティング時点に関する第１情報及び前記伝送オブジェクトのタイプを示す第２情報のうち少なくとも一つを取得し、前記取得した第１情報及び第２情報のうち少なくとも一つをパケットヘッダに設定してパケット化する制御部と、前記パケット化されたデータを伝送パケットを介して伝送する伝送部と、を含む。
【００３０】
また、本発明の一実施例による放送伝送装置の動作方法は、パケットを介した伝送の対象である伝送オブジェクトを取得するステップと、前記伝送オブジェクトの再生及びデコーティング時点に関する第１情報及び前記伝送オブジェクトのタイプを示す第２情報のうち少なくとも一つを取得するステップと、前記取得した第１情報及び第２情報をパケットヘッダに設定して伝送パケットをパケット化するステップと、前記パケット化された伝送パケットを伝送するステップと、を含む。
【発明の効果】
【００３１】
本発明の一実施例は、一つの伝送パケットが一つのファイルフォーマットベースのメディアデータまたは多数のファイルフォーマットベースのメディアデータを含む場合、該当伝送パケットを効率的に伝送し受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。
【００３２】
また、本発明の一実施例は、一つの伝送パケットが一つ以上のメタデータを含む場合、該当伝送パケットを効率的に伝送し受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。
【００３３】
特に、本発明の一実施例は、伝送しようとするオブジェクトのタイプ及びオブジェクトのタイミング情報を伝送するための伝送パケット構造を利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。
【００３４】
特に、本発明の一実施例は、伝送しようとするオブジェクト別に相異なるタイミング情報をマッピングするための伝送パケット構造を利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。
【００３５】
特に、本発明の一実施例は、伝送パケットを流動的に構成するための伝送パケット構造を利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。
【図面の簡単な説明】
【００３６】
【図１】本発明の一実施例による次世代放送サービスに関する放送信号送信装置の構造を示す図である。
【図２】本発明の一実施例によるインプットフォーマット（Ｉｎｐｕｔ  ｆｏｒｍａｔｔｉｎｇ、入力フォーマット）モジュールを示す図である。
【図３】本発明の他の一実施例によるインプットフォーマットブロックを示す図である。
【図４】本発明の他の一実施例によるインプットフォーマットブロックを示す図である。
【図５】本発明の一実施例によるＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロックを示す図である。
【図６】本発明の他の一実施例によるＢＩＣＭブロックを示す図である。
【図７】本発明の一実施例によるフレームビルディング（Ｆｒａｍｅ  Ｂｕｉｌｄｉｎｇ、フレーム生成）ブロックを示す図である。
【図８】本発明の一実施例によるＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）生成（ｇｅｎｅｒａｔｉｏｎ）ブロックを示す図である。
【図９】本発明の一実施例による次世代放送サービスに対する放送信号受信装置の構造を示す図である。
【図１０】本発明の一実施例によるフレームの構造を示す図である。
【図１１】本発明の一実施例によるフレームのシグナリング階層構造を示す図である。
【図１２】本発明の一実施例によるプリアンブルシグナリングデータを示す図である。
【図１３】本発明の一実施例によるＰＬＳ１データを示す図である。
【図１４】本発明の一実施例によるＰＬＳ２データを示す図である。
【図１５】本発明の他の一実施例によるＰＬＳ２データを示す図である。
【図１６】本発明の一実施例によるフレームのロジカル（ｌｏｇｉｃａｌ、論理）構造を示す図である。
【図１７】本発明の一実施例によるＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）マッピングを示す図である。
【図１８】本発明の一実施例によるＥＡＣ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｃｈａｎｎｅｌ）マッピングを示す図である。
【図１９】本発明の一実施例によるＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ）マッピングを示す図である。
【図２０】本発明の一実施例によるＤＰタイプを示す図である。
【図２１】本発明の一実施例によるＤＰマッピングを示す図である。
【図２２】本発明の一実施例によるＦＥＣ（ｆｏｒｗａｒｄ  ｅｒｒｏｒ  ｃｏｒｒｅｃｔｉｏｎ）構造を示す図である。
【図２３】本発明の一実施例によるビットインターリービングを示す図である。
【図２４】本発明の一実施例によるセルワード（ｃｅｌｌ−ｗｏｒｄ）デマルチプレキシングを示す図である。
【図２５】本発明の一実施例によるタイムインターリービングを示す図である。
【図２６】本発明の一実施例によるツイストされた行列ブロックインターリーバの基本動作を示す図である。
【図２７】本発明の他の一実施例によるツイストされた行列ブロックインターリーバの基本動作を示す図である。
【図２８】本発明の他の一実施例によるツイストされた行列ブロックインターリーバの対角線方向の読みパターンを示す図である。
【図２９】本発明の一実施例による各インターリービングアレイ（ａｒｒａｙ）からインターリービングされたＸＦＥＣＢＬＯＣＫを示す図である。
【図３０】本発明の一実施例による放送サービスをサポートするためのプロトコルスタック（ｐｒｏｔｏｃｏｌ  ｓｔａｃｋ）を示す図である。
【図３１】本発明の一実施例による放送伝送フレームを示す図である。
【図３２】本発明の他の実施例による放送伝送フレームを示す図である。
【図３３】本発明の一実施例による放送サービスを伝送する伝送パケットの構造を示す図である。
【図３４】本発明の一実施例による放送サービスを伝送する伝送パケットが含むｎｅｔｗｏｒｋ＿ｐｒｏｔｏｃｏｌフィールドが有する値を示す図である。
【図３５】本発明の一実施例による放送受信装置の構成を示す図である。
【図３６】本発明の他の実施例による放送受信装置の構成を示す図である。
【図３７】本発明の一実施例による放送サービスシグナリングテーブルと放送サービス伝送経路シグナリング情報が放送サービスと放送サービス伝送経路をシグナリングすることを示す図である。
【図３８】本発明の一実施例による放送サービスシグナリングテーブルを示す図である。
【図３９】本発明の一実施例による放送サービスシグナリングテーブルが含むｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドが有する値を示す図である。
【図４０】本発明の他の実施例による放送サービスシグナリングテーブルを示す図である。
【図４１】本発明の一実施例によるストリーム識別子デスクリプタを示す図である。
【図４２】本発明の一実施例による放送伝送装置が放送パケットを伝送する動作を示す図である。
【図４３】本発明の一実施例による放送受信装置が放送パケットを受信する動作を示す図である。
【図４４】本発明の実施例によるパケットの構成を示す図である。
【図４５】本発明の実施例によるＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）パケットの構造を示す図である。
【図４６】本発明の一実施例によるＩＳＯ  ｂａｓｅ  ｍｅｄｉａ  ｆｏｒｍａｔ（以下、ＩＳＯ  ＢＭＦＦ）をベースにするメディアファイルフォーマットを示す図である。
【図４７】本発明の一実施例によるパケットペイロードのペイロードヘッダの構成を示す図である。
【図４８】一つのパケットに一つのメディアがパケット化された伝送パケットのペイロード構成を示す図である。
【図４９】一つのパケットに一つのメディアがパケット化された伝送パケットのペイロード構成を示す図である。
【図５０】一つのパケットに複数の相異なるメディアがパケット化された伝送パケットの構成を示す図である。
【図５１】一つのパケットに複数の相異なるメディアがパケット化された伝送パケットの構成を示す図である。
【図５２】一つのメディアデータが複数の伝送パケットに分けられてパケット化された伝送パケット（以下、フラグメンテッドパケット（Ｆｒａｇｍｅｎｔｅｄ  ｐａｃｋｅｔ））のペイロード構成を示す図である。
【図５３】フラグメンテッドパケットのペイロード構成の他の実施例を示す図である。
【図５４】本発明の一実施例において、放送伝送装置がＩＳＯ  ＢＭＦＦベースのメディアファイルをフラグメンテーションして複数個のパケットに分けることを示す図である。
【図５５】図５４の放送伝送装置がパケット化した第１フラグメンテーションユニットデータの具体的な実施例を示す図である。
【図５６】図５４のフラグメンテーションユニットデータのうち開始データを除く残りのデータを含むフラグメンテーションユニットの一実施例を示す図である。
【図５７】図５４のフラグメンテーションユニットデータのうち開始データを除く残りのデータを含むフラグメンテーションユニットの一実施例を示す図である。
【図５８】図５４のフラグメンテーションユニットデータのうち開始データを除く残りのデータを含むフラグメンテーションユニットの一実施例を示す図である。
【図５９】本発明の一実施例によるメタデータのタイムラインシグナリングテーブルを示す図である。
【図６０】伝送パケットのペイロードデータに一つのメタデータがパケット化されたペイロードデータの構成を示す図である。
【図６１】伝送パケットのペイロードデータがタイムラインに対するメタデータを含む場合の実施例を示す図である。
【図６２】一つの伝送パケットに多数のメタデータがパケット化された場合を示す図である。
【図６３】一つの伝送パケットが多数個のタイムライン情報を含む場合を示す図である。
【図６４】一つのメタデータを複数個の伝送パケットに分けてパケット化したパケットペイロードを示す図である。
【図６５】メタデータフラグメントヘッダの他の実施例を示す図である。
【図６６】本発明の一実施例による放送受信装置が放送パケットを受信する動作を示す図である。
【図６７】放送網を介してはＲＴＰプロトコルを利用してビデオストリームを伝送し、インターネット網を介してはファイルフォーマットベースのメディアデータを利用してビデオストリームを伝送する場合を示す図である。
【図６８】本発明の一実施例による伝送パケットの構成を示す図である。
【図６９】本発明の一実施例によるパケットヘッダの構成を示す図である。
【図７０】時間情報を含む拡張されたヘッダの構成を示す図である。
【図７１】時間情報を含む拡張されたヘッダの構成を示す図である。
【図７２】本発明の一実施例による拡張されたヘッダの構成を示す図である。
【図７３】本発明の一実施例による拡張されたヘッダの構成を示す図である。
【図７４】本発明の一実施例による拡張されたヘッダの構成を示す図である。
【図７５】本発明の一実施例による拡張されたヘッダの構成を示す図である。
【図７６】本発明の一実施例による他のタイミング情報とのマッピングをサポートするための拡張されたヘッダの構成を示す図である。
【図７７】本発明の一実施例による放送伝送装置の動作方法を示す図である。
【図７８】本発明の一実施例による放送受信装置の動作方法を示す図である。
【図７９】伝送パケットの構成に対する情報を含むヘッダの構成を示す図である。
【図８０】図７９の伝送パケットの構成を示す図である。
【図８１】本発明の一実施例による放送伝送装置の動作方法を示す図である。
【図８２】本発明の一実施例による放送受信装置の動作方法を示す図である。
【発明を実施するための形態】
【００３７】
以下、添付した図面を参照して本発明の実施例について本発明の属する技術分野における通常の知識を有する者が容易に実施し得るようにより詳しく説明する。しかし、本発明は様々な相異なる形態に実装されてもよく、ここで説明する実施例に限ることはない。そして、図面で本発明を明確に説明するために説明とは関係のない部分は省略しており、明細書全体を通して類似した部分に対しては類似した図面符号を付けている。
【００３８】
また、ある部分がある構成要素を「含む」とする際、これは特に反対する記載がない限り、他の構成要素を除くのではなく他の構成要素を更に含むことを意味する。
【００３９】
本発明の好ましい実施例について具体的に説明し、その例は添付した図面に示す。添付した図面を参照した以下の詳細な説明は本発明の実施例によって実現される実施例のみを示すというより、本発明の好ましい実施例を説明するためのものである。以下の詳細な説明は本発明に対する徹底した理解を提供するために細部事項を含む。しかし、本発明がこのような細部事項なしに実行可能であることは当業者にとって自明である。
【００４０】
本発明で使用される殆どの用語は該当分野で広く使用される一般的なものから選択されているが、一部の用語は出願人によって任意に選択され、その意味は必要に応じて次の説明で詳細に述べている。よって、本発明は用語の単純な名称や意味ではなく用語の意図された意味に基づいて理解すべきである。
【００４１】
本発明は次世代放送サービスに関する放送信号送信及び受信装置及びその方法を提供する。本発明の一実施例による次世代放送サービスは地上波放送サービス、モバイル放送サービス、ＵＨＤ  ＴＶサービスなどを含む。本発明は一実施例によって非ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）またはＭＩＭＯ方式を介して次世代放送サービスに関する放送信号を処理する。本発明の一実施例による非ＭＩＭＯ方式はＭＩＳＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式などを含む。
【００４２】
以下、説明の便宜上、ＭＩＳＯまたはＭＩＭＯ方式は２つのアンテナを使用するが、本発明は２つ以上のアンテナを使用するシステムに適用される。
【００４３】
本発明は特定用途に要求される性能を達成しながら受信器の複雑度を最小化するために最適化された３つのフィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）（ベース（ｂａｓｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）、アドバンスド（ａｄｖａｎｃｅｄ）プロファイル）を定義する。フィジカルプロファイルは該当する受信器が実装すべき全てのサブセットである。
【００４４】
３つのフィジカルプロファイルは殆どの機能ブロックを共有するが、特定ブロック及び／またはパラメータでは多少異なる。後に追加にフィジカルプロファイルが定義されてもよい。システムの発展のために、フューチャープロファイルはＦＥＦ（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ  ｆｒａｍｅ）を介して単一ＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）チャネルに存在するプロファイルとマルチプレキシングされてもよい。各フィジカルプロファイルに関する詳細な内容は後述する。
【００４５】
１．ベースプロファイル
【００４６】
ベースプロファイルは主にルーフトップ（ｒｏｏｆ−ｔｏｐ）アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルはある場所に移動されるが、割と停止された受信範疇に属する携帯用装置も含む。ベースプロファイルの用途は多少改善された実行によってハンドヘルド装置または車両用に拡張されるが、このような使用用途はベースプロファイル受信器の動作では期待されない。
【００４７】
受信のターゲット信号対雑音比の範囲は略１０乃至２０ｄＢであるが、これは従来の放送システム（例えば、ＡＴＳＣ  Ａ／５３）の１５ｄＢ信号対雑音比の受信能力を含む。受信器の複雑度及び消費電力はハンドヘルドプロファイルを使用するバッテリで駆動されるハンドヘルド装置より重要ではない。ベースプロファイルに関する重要システムパラメータを下記表１に示す。
【００４８】
【表１】
2018207499.tif 000003
【００４９】
２．ハンドヘルドプロファイル
【００５０】
ハンドヘルドプロファイルはバッテリ電源で駆動されるハンドヘルド及び車両用装置での使用のために設計される。該当装置は歩行者及び車両速度で移動する。受信器の複雑度だけでなく、消費電力はハンドヘルドプロファイルの装置の実装のために非常に重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は略０乃至１０ｄＢであるが、より低い室内受信のために意図される場合、０ｄＢの下に達するように設定してもよい。
【００５１】
低信号対雑音比の能力だけでなく、受信器の移動性によって現れたドップラー効果に関する復元力はハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに関する重要システムパラメータを下記表２に示す。
【００５２】
【表２】
2018207499.tif 000004
【００５３】
３．アドバンスドプロファイル
【００５４】
アドバンスドプロファイルはより大きい実行複雑度に対する対価としてより高いチャネル能力を提供する。該当プロファイルはＭＩＭＯ送信及び受信を使用することを要求し、ＵＨＤ  ＴＶサービスはターゲット用途であって、そのために該当プロファイルが特別に設計される。向上された能力は与えられた帯域幅でサービス数の増加、例えば多数のＳＤＴＶ及びＨＤＴＶサービスを許容するのにも使用される。
【００５５】
アドバンスドプロファイルのターゲット信号対雑音比は略２０乃至３０ｄＢである。ＭＩＭＯ伝送は、初期には従来の楕円分極の伝送装備を使用し、後に全出力高次分極伝送に拡張される。アドバンスドプロファイルに関する重要システムパラメータを下記表３に示す。
【００５６】
【表３】
2018207499.tif 000005
【００５７】
この場合、ベースプロファイルは地上波放送サービス及びモバイル放送サービス両方に対するプロファイルとして使用される。即ち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために使用される。また、アドバンスドプロファイルはＭＩＭＯを有するベースプロファイルに対するアドバンスドプロファイル及びＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスドプロファイルとして区分される。そして、該当３つのプロファイルは設計者の意図によって変更される。
【００５８】
以下の用語及び定義は本発明に適用される。以下の用語及び定義は設計に応じて変更されてもよい。
【００５９】
補助ストリーム：フューチャーエクステンション（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ、将来の拡張）または放送局やネットワーク運営者によって要求されることで使用されるまだ定義されていない変調及びコーティングのデータを伝達するセルのシーケンス
【００６０】
ベースデータパイプ（ｂａｓｅ  ｄａｔａ  ｐｉｐｅ）：サービスシグナリングデータを伝達するデータパイプ
【００６１】
ベースバンドフレーム（またはＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合
【００６２】
セル（ｃｅｌｌ）：ＯＦＤＭ伝送の一つのキャリアによって伝達される変調値
【００６３】
コーディングブロック（ｃｏｄｅｄ  ｂｌｏｃｋ）：ＰＬＳ１データのＬＤＰＣエンコーディングされたブロックまたはＰＬＳ２データのＬＤＰＣエンコーディングされたブロックのうち一つ
【００６４】
データパイプ（ｄａｔａ  ｐｉｐｅ）：一つまたは多数のサービスまたはサービスコンポーネントを伝達するサービスデータまたは関連するメタデータを伝達する物理層でのロジカルチャネル
【００６５】
データパイプユニット（ＤＰＵ、ｄａｔａ  ｐｉｐｅ  ｕｎｉｔ）：データセルをフレームでのデータパイプに割り当てる基本ユニット
【００６６】
データシンボル（ｄａｔａ  ｓｙｍｂｏｌ）：プリアンブルではなくフレームでのＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（ｅｄｇｅ）シンボルはデータシンボルに含まれる）。
【００６７】
ＤＰ＿ＩＤ：該当８ビットフィールドはＳＹＳＴＥＭ＿ＩＤによって識別されたシステム内でデータパイプを唯一に識別する。
【００６８】
ダミーセル（ｄｕｍｍｙ  ｃｅｌｌ）：ＰＬＳシグナリング、データパイプまたは補助ストリームのために使用されていない残りの容量を詰めるのに使用される擬似ランダム値を伝達するセル
【００６９】
ＥＡＣ（非常警報チャネル）：ＥＡＳ情報データを伝達するフレームの一部
【００７０】
フレーム（ｆｒａｍｅ）：プリアンブルから始まってフレームエッジシンボルで終了される物理層タイムスロット
【００７１】
フレームレペティションユニット（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ、フレーム繰り返し単位）：スーパーフレーム（ｓｕｐｅｒ−ｆｒａｍｅ）で８回繰り返されるＦＥＦを含む同じまたは異なるフィジカルプロファイルに属するフレームの集合
【００７２】
ＦＩＣ（高速情報チャネル）：サービスと該当ベースデータパイプの間におけるマッピング情報を伝達するフレームのロジカルチャネル
【００７３】
ＦＥＣＢＬＯＣＫ：データパイプのＬＤＰＣエンコーディングされたビットの集合
【００７４】
ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同じ特定モードに使用される名目上のＦＦＴサイズ
【００７５】
フレームシグナリングシンボル（ｆｒａｍｅ  ｓｉｇｎａｌｉｎｇ  ｓｙｍｂｏｌ）：ＰＬＳデータの一部を伝達するＦＦＴサイズ、ガードインターバル（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）及びスキャッタ（ｓｃａｔｔｅｒｅｄ）ファイルパターンの特定の組み合わせにおいて、フレームの開始に使用されるより高いパイロット密度を有するＯＦＤＭシンボル
【００７６】
フレームエッジシンボル（ｆｒａｍｅ  ｅｄｇｅ  ｓｙｍｂｏｌ）：ＦＦＴサイズ、ガードインターバル及びスキャッタパイロットパターンの特定の組み合わせにおいて、フレームの端で使用されるより高いパイロット密度を有するＯＦＤＭシンボル
【００７７】
フレームグループ（ｆｒａｍｅ−ｇｒｏｕｐ）：スーパーフレームで同じフィジカルタイプを有する全てのフレームの集合
【００７８】
フューチャーエクステンションフレーム（ｆｕｔｕｒｅ  ｅｘｔｅｎｔｉｏｎ  ｆｒａｍｅ、将来の拡張フレーム）：プリアンブルで始まる、将来の拡張に使用可能なスーパーフレーム内での物理層タイムスロット
【００７９】
フューチャーキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳまたはＩＰ（Ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ）または一般ストリームであり、出力がＲＦシグナルである提案された物理層放送システム。
【００８０】
インプットストリーム（ｉｎｐｕｔ  ｓｔｒｅａｍ、入力ストリーム）：システムによって最終ユーザに伝達されるサービスの調和（ｅｎｓｅｍｂｌｅ）のためのデータのストリーム
【００８１】
ノーマル（ｎｏｒｍａｌ）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除くデータシンボル
【００８２】
フィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）：該当する受信器が実装すべき全ての構造とサブセット
【００８３】
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理層シグナリングデータ
【００８４】
ＰＬＳ１：ＰＬＳ２をデコーティングするのに必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳに伝達されるＰＬＳデータの第１集合
【００８５】
ＮＯＴＥ：ＰＬＳ１データはフレームグループのデュレーション（ｄｕｒａｔｉｏｎ）の間に一定である。
【００８６】
ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳに伝送されるＰＬＳデータの第２集合
【００８７】
ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データ：フレームごとにダイナミックに変化するＰＬＳ２データ
【００８８】
ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データ：フレームのデュレーションの間にスタティックなＰＬＳ２データ
【００８９】
プリアンブルシグナリングデータ（ｐｒｅａｍｂｌｅ  ｓｉｇｎａｌｉｎｇ  ｄａｔａ）：プリアンブルシンボルによって伝達されてシステムの基本モードを確認するのに使用されるシグナリングデータ
【００９０】
プリアンブルシンボル（ｐｒｅａｍｂｌｅ  ｓｙｍｂｏｌ）：基本ＰＬＳデータを伝達し、フレームの開始に位置する固定された長さのパイロットシンボル
【００９１】
ＮＯＴＥ：プリアンブルシンボルはシステム信号、そのタイミング、周波数オフセット及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に使用される。
【００９２】
将来の使用（ｆｕｔｕｒｅ  ｕｓｅ）のためのリザーブド（ｒｅｓｅｒｖｅｄ）：現在の文書で定義されていないが、将来に定義される可能性がある。
【００９３】
スーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）：８つのフレーム反復単位の集合
【００９４】
タイムインターリービングブロック（ｔｉｍｅ  ｉｎｔｅｒｌｉｖｉｎｇ  ｂｌｏｃｋ、ＴＩ  ｂｌｏｃｋ）：タイムインターリーバメモリの一つの用途に当たる、タイムインターリービングが実行されるセルの集合
【００９５】
タイムインターリービンググループ（ｔｉｍｅ  ｉｎｔｅｒｌｉｖｉｎｇ  ｇｒｏｕｐ、ＴＩ  ｇｒｏｕｐ）：整数、ダイナミックに変化するＸＦＥＣＢＬＯＣＫの数で形成された、特定データのパイプに対するダイナミック容量割り当てが実行される単位
【００９６】
ＮＯＴＥ：タイムインターリービンググループは一つのフレームに直接マッピングされるか多数のフレームにマッピングされる。タイムインターリービンググループは一つ以上のタイムインターリービングブロックを含む。
【００９７】
第１タイプデータパイプ（Ｔｙｐｅ  １  ＤＰ）：全てのデータパイプがフレームにＴＤＭ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）方式にマッピングされるフレームのデータパイプ
【００９８】
第２タイプデータパイプ（Ｔｙｐｅ  ２  ＤＰ）：全てのデータパイプがフレームにＦＤＭ方式にマッピングされるフレームのデータパイプ
【００９９】
ＸＦＥＢＬＯＣＫ：一つのＬＤＰＣ  ＦＥＣＢＬＯＣＫの全てのビットを担当するＮｃｅｌｌｓセルの集合
【０１００】
図１は、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
【０１０１】
本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック(Input Format block)１０００、BICM(bit interleaved coding & modulation)ブロック１０１０、フレームビルディングブロック(Frame building block)１０２０、OFDM(orthogonal frequency division multiplexing)生成ブロック(OFDM generation block)１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
【０１０２】
IPストリーム/パケット及びMPEG２-TSは、主なインプットフォーマットであり、他のストリームタイプは一般ストリームとして扱われる。これらのデータ入力に加えて、管理情報が入力されて各入力ストリームに対する該当帯域幅のスケジューリング及び割当を制御する。１つまたは多数のTSストリーム、IPストリーム及び/または一般ストリーム入力が同時に許容される。
【０１０３】
インプットフォーマットブロック１０００は、それぞれの入力ストリームを独立的なコーディング及び変調が適用される１つまたは多数のデータパイプにデマルチプレックスすることができる。データパイプは、堅固性(robustness)制御の基本単位であり、これはQoS(Quality of Service)に影響を及ぼす。１つまたは多数のサービスまたはサービスコンポーネントが１つのデータパイプによって伝達される。インプットフォーマットブロック１０００の詳しい動作は後述する。
【０１０４】
データパイプは１つまたは多数のサービスまたは、サービスコンポーネントを伝達できるサービスデータまたは関連メタデータを伝達する物理層(physical layer)におけるロジカルチャネルである。
【０１０５】
また、データパイプユニットは、１つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
【０１０６】
BICMブロック１０１０で、パリティ(parity)データはエラー訂正のために追加され、エンコーディングされたビットストリームは複素数値のコンステレーションシンボルにマッピングされる。該当シンボルは、該当データパイプに使用される特定インターリービング深さにかけてインターリービングされる。アドバンスドプロファイルにおいて、BICMブロック１０１０でMIMOエンコーディングが実行され、追加データ経路がMIMO伝送のために出力に追加される。BICMブロック１０１０の詳しい動作は後述する。
【０１０７】
フレームビルディングブロック１０２０は、１つのフレーム内で入力データパイプのデータセルをOFDMシンボルにマッピングすることができる。マッピング後、周波数領域ダイバーシティーのために、特に周波数選択的フェーディングチャネルを防止するために、周波数インターリービングが利用される。フレームビルディングブロック１０２０の詳しい動作は後述する。
【０１０８】
プリアンブルを各フレームの始まりに挿入した後、OFDM生成ブロック１０３０は、サイクリックプレフィックス(cyclic prefix)をガードインターバルとして有する既存のOFDM変調を適用することができる。アンテナスペースダイバーシティーのために、分散した(distributed)MISO方式が送信機にかけて適用される。また、PAPR(peak-to-average power ratio)方式が時間領域で実行される。柔軟なネットワーク方式のために、該当提案は多様なFFTサイズ、ガードインターバル長さ、該当パイロットパターンの集合を提供する。OFDM生成ブロック１０３０の詳しい動作は後述する。
【０１０９】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に使用される物理層(physical layer)シグナリング情報を生成することができる。また、該当シグナリング情報は、関心のあるサービスが受信機側で適切に回復するように伝送される。シグナリング生成ブロック１０４０の詳しい動作は後述する。
【０１１０】
図２、３、４は、本発明の実施例に係るインプットフォーマットブロック１０００を示す。各図面について説明する。
【０１１１】
図２は、本発明の一実施例に係るインプットフォーマットブロックを示す。図２は、入力信号が単一入力ストリーム(single input stream)であるときのインプットフォーマットブロックを示す。
【０１１２】
図２に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施例に該当する。
【０１１３】
物理層(physical layer)への入力は、１つまたは多数のデータストリームからなることができる。それぞれのデータストリームは、１つのデータパイプによって伝達される。モードアダプテーション(mode adaptaion)モジュールは、入力されるデータストリームをBBF(baseband frame)のデータフィールドにスライスする。該当システムは、３種類の入力データストリーム、すなわちMPEG２-TS、IP、GS(generic stream)をサポートする。MPEG２-TSは、最初のバイトが同期バイト(０x４７)の固定長(１８８バイト)のパケットを特徴とする。IPストリームは、IPパケットヘッダ内でシグナリングされる可変長IPデータグラムパケットから構成される。該当システムは、IPストリームに対してIPv４とIPv６の両方をサポートする。GSは、カプセル化パケットヘッダ内でシグナリングされる可変長パケットまたは一定の長さパケットから構成される。
【０１１４】
(a)は信号データパイプに対するモードアダプテーション(mode adaptaion)ブロック２０００及びストリームアダプテーション(stream adaptation)２０１０を示し、(b)はPLSデータを生成及び処理するためのPLS生成ブロック２０２０及びPLSスクランブラ２０３０を示す。各ブロックの動作について説明する。
【０１１５】
入力ストリームスプリッタは、入力されたTS、IP、GSストリームを多数のサービスまたはサービスコンポーネント(オーディオ、ビデオなど)ストリームに分割する。モードアダプテーション(mode adaptaion)モジュール２０１０は、CRCエンコーダ、BB(baseband)フレームスライサー、及びBBフレームヘッダ挿入ブロックから構成される。
【０１１６】
CRCエンコーダは、ユーザパケット(user packet、UP)レベルでのエラー検出のための３種類のCRCエンコーディング、すなわちCRC-８、CRC-１６、CRC-３２を提供する。算出されたCRCバイトは、UPの後に添付される。CRC-８はTSストリームに使用され、CRC-３２はIPストリームに使用される。GSストリームがCRCエンコーディングを提供しない場合、提案されたCRCエンコーディングが適用されなければならない。
【０１１７】
BBフレームスライサーは、入力を内部ロジカルビットフォーマットにマッピングする。最初の受信ビットはMSBと定義する。BBフレームスライサーは、使用可能データフィールド容量と同じ数の入力ビットを割り当てる。BBFペイロードと同じ数の入力ビットを割り当てるために、UPストリームがBBFのデータフィールドに適合するようにスライスされる。
【０１１８】
BBフレームヘッダ挿入ブロックは、２バイトの固定長BBFヘッダをBBフレームの前に挿入することができる。BBFヘッダは、STUFFI(１ビット)、SYNCD(１３ビット)、及びRFU(２ビット)から構成される。固定された２バイトBBFヘッダだけでなく、BBFは２バイトBBFヘッダの終わりに拡張フィールド(１または３バイト)を有することができる。
【０１１９】
ストリームアダプテーション(stream adaptation)２０１０は、スタッフィング(stuffing)挿入ブロック及びBBスクランブラから構成される。
【０１２０】
スタッフィング挿入ブロックは、スタッフィングフィールドをBBフレームのペイロードに挿入することができる。ストリームアダプテーション(stream adaptation)に対する入力データがBBフレームを満たすことに十分である場合、STUFFIは０に設定され、BBFはスタッフィングフィールドを有しない。そうでない場合、STUFFIは１に設定され、スタッフィングフィールドはBBFヘッダ直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダ及び可変サイズのスタッフィングデータを含む。
【０１２１】
BBスクランブラは、エネルギー分散のために完全なBBFをスクランブリングする。スクランブリングシーケンスはBBFと同期化される。スクランブリングシーケンスはフィードバックシフトレジスタによって生成される。
【０１２２】
PLS生成ブロック２０２０は、PLSデータを生成することができる。PLSは、受信機でフィジカルレイヤ(physical layer)データパイプに接続できる手段を提供する。PLSデータは、PLS１データ及びPLS２データから構成される。
【０１２３】
PLS１データは、PLS２データのデコーディングに必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームでFSSに伝達されるPLSデータの最初の集合である。PLS１データは、PLS２データの受信及びデコーディングに要請されるパラメータを含む基本送信パラメータを提供する。また、PLS１データは、フレームグループのデュレーションの間一定である。
【０１２４】
PLS２データは、データパイプ及びシステムに関するより詳細なPLSデータを伝達するFSSに伝送されるPLSデータの二番目の集合である。PLS２は、受信機が所望するデータパイプのデコーディングに十分な情報を提供するパラメータを含む。PLS２シグナリングは、さらにPLS２スタティックデータ(PLS２-STATデータ)及びPLS２ダイナミックデータ(PLS２-DYNデータ)の二種類のパラメータから構成される。PLS２スタティックデータは、フレームグループのデュレーションの間スタティックのPLS２データであり、PLS２ダイナミックデータは、フレームごとにダイナミックに変化するPLS２データである。
【０１２５】
PLSデータについての詳しい内容は後述する。
【０１２６】
PLSスクランブラ２０３０は、エネルギー分散のために生成されたPLSデータをスクランブリングすることができる。
【０１２７】
前述したブロックは、省略してもよく、類似または同一機能を有するブロックによって代替することもできる。
【０１２８】
図３は、本発明の他の一実施例に係るインプットフォーマットブロックを示す。
【０１２９】
図３に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施例に該当する。
【０１３０】
図３は、入力信号がマルチインプットストリーム(multi input stream)に該当する場合、インプットフォーマットブロックのモードアダプテーション(mode adaptaion)ブロックを示す。
【０１３１】
マルチインプットストリーム(multi input stream)を処理するためのインプットフォーマットブロックのモードアダプテーション(mode adaptaion)ブロックは、マルチインプットストリームを独立的に処理することができる。
【０１３２】
図３に示すように、マルチインプットストリーム(multi input stream)をそれぞれ処理するためのモードアダプテーション(mode adaptaion)ブロックは、インプットストリームスプリッタ(input stream splitter)３０００、インプットストリームシンクロナイザー(input stream synchronizer)３０１０、補償遅延(compensating delay)ブロック３０２０、ヌルパケット削除ブロック(null packet deletion block)３０３０、ヘッダ圧縮ブロック(header compression block)３０４０、CRCエンコーダ(CRC encoder)３０５０、BBフレームスライサー(BB frame slicer)３０６０、及びBBヘッダ挿入ブロック(BB header insertion block)３０７０を含むことができる。モードアダプテーション(mode adaptaion)ブロックの各ブロックについて説明する。
【０１３３】
CRCエンコーダ３０５０、BBフレームスライサー３０６０、及びBBヘッダ挿入ブロック３０７０の動作は、図２を参照して説明したCRCエンコーダ、BBフレームスライサー、及びBBヘッダ挿入ブロックの動作に該当するので、その説明は省略する。
【０１３４】
インプットストリームスプリッタ３０００は、入力されたTS、IP、GSストリームを多数のサービスまたはサービスコンポーネント(オーディオ、ビデオなど)ストリームに分割する。
【０１３５】
インプットストリームシンクロナイザー３０１０はISSYと呼ぶことができる。ISSYは、いかなる入力データフォーマットに対してもCBR(constant bit rate)及び一定のEnd-to-End伝送遅延を保証する適合な手段を提供することができる。ISSYは、TSを伝達する多数のデータパイプの場合に常に利用され、GSストリームを伝達する多数のデータパイプに選択的に利用される。
【０１３６】
補償遅延(compensating delay)ブロック３０２０は、受信機で追加メモリを必要とせず、TSパケット再結合メカニズムを許容するために、ISSY情報の挿入による分割されたTSパケットストリームを遅延させることができる。
【０１３７】
ヌルパケット削除ブロック３０３０は、TS入力ストリームの場合のみに使用される。いくつかのTS入力ストリームまたは分割されたTSストリームは、VBR(variable bit-rate)サービスをCBR TSストリームに収容するために存在する多数のヌルパケットを有することができる。この場合、不必要な伝送オーバーヘッドを避けるために、ヌルパケットは識別され伝送されないようにすることができる。受信機で、除去されたヌルパケットは、伝送に挿入されたDNP(deleted null-packet、削除されたヌルパケット)カウンターを参照して、本来存在していた正確な場所に再挿入することができ、CBRが保証されタイムスタンプ(PCR)を更新する必要がなくなる。
【０１３８】
ヘッダ圧縮ブロック３０４０は、TSまたはIP入力ストリームに対する伝送効率を増加させるために、パケットヘッダ圧縮を提供することができる。受信機は、ヘッダの特定部分に対するアプリオリ(a priori)情報を持つことがあるので、この既知の情報(known information)は送信機から削除することができる。
【０１３９】
TSに対して、受信機は同期バイト構成(０x４７)及びパケット長さ(１８８バイト)に関するアプリオリ情報を有することができる。入力されたTSが１つのPIDのみを有するコンテンツを伝達すれば、すなわち、１つのサービスコンポーネント(ビデオ、オーディオなど)またはサービスサブコンポーネント(SVCベースレイヤ、SVCエンハンスメントレイヤ、MVCベースビュー、またはMVC依存ビュー)に対してのみ、TSパケットヘッダ圧縮がTSに(選択的に)適用されるようにすることができる。TSパケットヘッダ圧縮は、入力ストリームがIPストリームである場合選択的に使用される。
【０１４０】
前記ブロックは、省略または類似または同一機能を有するブロックで代替することができる。
【０１４１】
図４は、インプットシグナルが複数のインプットストリームに対応するとき、インプットフォーマットモジュールのストリーム適応ブロックを示す。
【０１４２】
図4に示すインプットフォーマット設定ブロックは、図1を参照して説明したインプットフォーマットブロック1000の一実施形態に相当します。
【０１４３】
入力信号は、複数の入力ストリームに対応する場合、図4は、モジュールのフォーマットの入力ストリーム適応ブロックを示す図です。
【０１４４】
図４に示すように、複数のインプットストリームをそれぞれ処理するためのモード適応ブロックは、スケジューラ４０００、１フレーム遅延ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンドシグナリング４０３０、BBフレームスクランブラ４０４０、PLS生成ブロック４０５０、及びPLSスクランブラ４０６０を含むことができる。説明はストリーム適応ブロックのそれぞれのブロックに対して提供される。
【０１４５】
スタッフィングデータブロック４０２０、BBフレームスクランブラ４０４０、PLS生成ブロック４０５０及びPLSスクランブラ４０６０は、図２に図示されたスタッフィング挿入ブロック、BBスクランブラ、PLS生成ブロック及びPLSスクランブラに対応する。従って、それに関する説明は省略する。
【０１４６】
スケジューラ４０００は、それぞれのDPのFECBLOCKの量から全体フレームにわたる全体的なセル割当を決定することができる。PLS、EAC及びFICのための割当を含んで、スケジューラは、フレームのFSS内PLSセルまたはインバンドシグナリングに伝送されるPLS２-DYNデータの値を生成する。FECBLOCK、EAC及びFICに関する詳しい説明は後述する。
【０１４７】
１フレーム遅延ブロック４０１０は、DP内に挿入されるインバンドシグナリング情報のための現在のフレームを介して伝送される次のフレームに対するスケジューリング情報のような１つの伝送フレームによるインプットデータを遅延させることができる。
【０１４８】
インバンドシグナリング４０３０は、フレームのDP内PLS２データの遅延されない部分に挿入される。
【０１４９】
上述したブロックは、類似または同一機能を有するブロックによって省略または代替することができる。
【０１５０】
図５は、本発明の一実施例に係るBICMブロックを示す。
【０１５１】
図５に図示されたBICMブロックは、図１を参照して説明したBICMブロック１０１０の一実施例に該当する。
【０１５２】
上述したように、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、UHDTVサービスなどを提供することができる。
【０１５３】
QoSが本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するので、それぞれのサービスに該当するデータはそれぞれ異なる方式を介して処理されなければならない。従って、本発明の一実施例に係るBICMブロックは、SISO、MISO、MIMO方式をそれぞれのデータ経路に該当するデータパイプに独立的に適用することで、各データパイプを独立的に処理することができる。結果的に、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、それぞれのデータパイプを介して伝送される各サービスまたはサービスコンポーネントに対するQoSを調節することができる。
【０１５４】
(a)はベースプロファイル及びハンドヘルドプロファイルによって共有されるBICMブロックを示し、(b)はアドバンスドプロファイルのBICMブロックを示す。
【０１５５】
ベースプロファイル及びハンドヘルドプロファイルによって共有されるBICMブロック及びアドバンスドプロファイルのBICMブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
【０１５６】
ベースプロファイル及びハンドヘルドプロファイルに対するBICMブロック及びアドバンスドプロファイルに対するBICMブロックのそれぞれの処理ブロックについて説明する。
【０１５７】
ベースプロファイル及びハンドヘルドプロファイルに対するBICMブロックの処理ブロック５０００は、データFECエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパ５０３０、SSD(signal space diversity)エンコーディングブロック５０４０、タイムインターリーバ５０５０を含むことができる。
【０１５８】
データFECエンコーダ５０１０は、外部コーディング(BCH)及び内部コーディング(LDPC)を利用してFECBLOCK手順を生成するために、入力BBFにFECエンコーディングを実行する。外部コーディング(BCH)は、選択的なコーディング方法である。データFECエンコーダ５０１０の具体的な動作については後述する。
【０１５９】
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながらデータFECエンコーダ５０１０の出力をインターリービングして、LDPCコード及び変調方式の組合せで最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作については後述する。
【０１６０】
コンステレーションマッパ５０３０は、QPSK、QAM-１６、不均一QAM(NUQ-６４、NUQ-２５６、NUQ-１０２４)または不均一コンステレーション(NUC-１６、NUC-６４、NUC-２５６、NUC-１０２４)を利用して、ベース及びハンドヘルドプロファイルにおいてビットインターリーバ５０２０からのそれぞれのセルワードを変調したり、アドバンスドプロファイルにおいてセルワードデマルチプレクサ５０１０-１からのセルワードを変調して、パワーが正規化されたコンステレーションポイントelを提供することができる。該当コンステレーションマッピングは、データパイプに対してのみ適用される。NUQが任意の形態を有する反面、QAM-１６及びNUQは正四角形形状を有することが観察される。それぞれのコンステレーションが９０度の倍数だけ回転すれば、回転したコンステレーションは本来のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均パワーがお互いに等しくなる。NUQ及びNUCはいずれも各コードレート(code rate)に対して特別に定義され、使用される特定の１つは、PLS２データに保管されたパラメータDP_MODによってシグナリングされる。
【０１６１】
タイムインターリーバ５０５０は、データパイプレベルで動作することができる。タイムインターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定することができる。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
【０１６２】
アドバンスドプロファイルに対するBICMブロックの処理ブロック５０００-１は、データFECエンコーダ、ビットインターリーバ、コンステレーションマッパ、及びタイムインターリーバを含むことができる。ただし、処理ブロック５０００-１は、セルワードデマルチプレクサ５０１０-１及びMIMOエンコーディングブロック５０２０-１をさらに含むという点で、処理ブロック５０００と区別される。
【０１６３】
また、処理ブロック５０００-１におけるデータFECエンコーダ、ビットインターリーバ、コンステレーションマッパ、タイムインターリーバの動作は、前述したデータFECエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパ５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。
【０１６４】
セルワードデマルチプレクサ５０１０-１は、アドバンスドプロファイルのデータパイプがMIMO処理のために単一セルワードストリームをデュアルセルワードストリームに分離するために使用される。セルワードデマルチプレクサ５０１０-１の具体的な動作に関しては後述する。
【０１６５】
MIMOエンコーディングブロック５０２０-１は、MIMOエンコーディング方式を利用してセルワードデマルチプレクサ５０１０-１の出力を処理することができる。MIMOエンコーディング方式は、放送信号送信のために最適化されている。MIMO技術は、容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に、放送に対して、異なる信号電波特性による２つのアンテナの間の受信信号パワーの差またはチャネルの強いLOSコンポーネントは、MIMOから容量利得を得難くする。提案されたMIMOエンコーディング方式は、MIMO出力信号のうちの１つの位相ランダム化及び回転に基づくプリコーディングを利用してこの問題を克服する。
【０１６６】
MIMOエンコーディングは、送信機及び受信機の両方において少なくとも２つのアンテナを必要とする２x２MIMOシステムのために意図されている。２つのMIMOエンコーディングモードは、本提案であるFR-SM(full-rate spatial multiplexing)及びFRFD-SM(full-rate full-diversity spatial multiplexing)で定義される。FR-SMエンコーディングは、受信機側での比較的小さい複雑度増加で容量増加を提供する反面、FRFD-SMエンコーディングは、受信機側での大きい複雑度増加で容量増加及び追加的なダイバーシティー利得を提供する。提案されたMIMOエンコーディング方式は、アンテナ極性配置を制限しない。
【０１６７】
MIMO処理は、アドバンスドプロファイルフレームに要請されるが、これはアドバンスドプロファイルフレームにおけるすべてのデータパイプが、MIMOエンコーダによって処理されるということを意味する。MIMO処理は、データパイプレベルで適用される。コンステレーションマッパ出力ペア(pair)のNUQ(e１、i及びe２、i)は、MIMOエンコーダの入力に供給される。MIMOエンコーダ出力ペア(g１、i及びg２、i)は、それぞれの送信アンテナの同一キャリアk及びOFDMシンボルlによって伝送される。
【０１６８】
前述したブロックは、省略または類似または同一機能を有するブロックで代替することができる。
【０１６９】
図６は、本発明の他の実施例に係るBICMブロックを示す。
【０１７０】
図６に図示されたBICMブロックは、図１を参照して説明したBICMブロック１０１０の一実施例に該当する。
【０１７１】
図６は、PLS、EAC、及びFICを保護するためのBICMブロックを示す。EACは、EAS情報データを伝達するフレームの一部であり、FICは、サービスと該当するベースデータパイプの間でマッピング情報を伝達するフレームにおけるロジカルチャネルである。EAC及びFICに対する詳細な説明は後述する。
【０１７２】
図６に示すように、PLS、EAC、及びFICを保護するためのBICMブロックは、PLS FECエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパ６０２０を含むことができる。
【０１７３】
また、PLS FECエンコーダ６０００は、スクランブラ、BCHエンコーディング/ゼロ挿入ブロック、LDPCエンコーディングブロック、及びLDPCパリティパンクチャリング(puncturing)ブロックを含むことができる。BICMブロックの各ブロックについて説明する。
【０１７４】
PLS FECエンコーダ６０００は、スクランブリングされたPLS１/２データ、EAC及びFICセクションをエンコーディングすることができる。
【０１７５】
スクランブラは、BCHエンコーディング及びショートニング(shortening)及びパンクチャリングされたLDPCエンコーディング前にPLS１データ及びPLS２データをスクランブリングすることができる。
【０１７６】
BCHエンコーディング/ゼロ挿入ブロックは、PLS保護のためのショートニングされたBCHコードを利用して、スクランブリングされたPLS１/２データに外部エンコーディングを行い、BCHエンコーディング後ゼロビットを挿入することができる。PLS１データに対してのみ、ゼロ挿入の出力ビットがLDPCエンコーディング前にパーミュテーション(permutation)される。
【０１７７】
LDPCエンコーディングブロックは、LDPCコードを利用してBCHエンコーディング/ゼロ挿入ブロックの出力をエンコーディングすることができる。完全なコーディングブロックを生成するために、Cldpc及びパリティビットPldpcはそれぞれのゼロが挿入されたPLS情報ブロックIldpcから組織的にエンコーディングされ、その後に添付される。
【０１７８】
【数１】
2018207499.tif 000006
【０１７９】
PLS１及びPLS２に対するLDPCコードパラメータは、次の表４のようである。
【０１８０】
【表４】
2018207499.tif 000007
【０１８１】
LDPCパリティパンクチャリングブロックは、PLS１データ及びPLS２データに対してパンクチャリングを行うことができる。
【０１８２】
ショートニングがPLS１データ保護に適用されると、一部LDPCパリティビットはLDPCエンコーディング後パンクチャリングされる。また、PLS２データ保護のために、PLS２のLDPCパリティビットがLDPCエンコーディング後パンクチャリングされる。これらパンクチャリングされたビットは伝送されない。
【０１８３】
ビットインターリーバ６０１０は、それぞれのショートニング及びパンクチャリングされたPLS１データ及びPLS２データをインターリービングすることができる。
【０１８４】
コンステレーションマッパ６０２０は、ビットインターリービングされたPLS１データ及びPLS２データをコンステレーションにマッピングすることができる。
【０１８５】
前述したブロックは、省略または類似または同一機能を有するブロックで代替することができる。
【０１８６】
図７は、本発明の一実施例に係るフレームビルディングブロック(frame building block)を示す。
【０１８７】
図７に図示したフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の一実施例に該当する。
【０１８８】
図７に示すように、フレームビルディングブロックは遅延補償ブロック７０００、セルマッパ(cell mapper)７０１０、及び周波数インターリーバ(frequency interleaver)７０２０を含むことができる。フレームビルディングブロックの各ブロックに関して説明する。
【０１８９】
遅延補償ブロック７０００は、データパイプと該当するPLSデータの間のタイミングを調節して、送信機側でデータパイプと該当するPLSデータ間の同時性(co-time)を保証することができる。インプットフォーマットブロック及びBICMブロックによるデータパイプの遅延を対処することで、PLSデータはデータパイプだけ遅延される。BICMブロックの遅延は、主にタイムインターリーバ５０５０によるものである。インバンド(In-band)シグナリングデータは、次のタイムインターリービンググループの情報をシグナリングされるデータパイプより１フレーム前に伝達されるようにすることができる。遅延補償ブロックは、それに合わせてインバンド(In-band)シグナリングデータを遅延させる。
【０１９０】
セルマッパ７０１０は、PLS、EAC、FIC、データパイプ、補助ストリーム、及びダミーセルをフレーム内でOFDMシンボルのアクティブ(active)キャリアにマッピングすることができる。セルマッパ７０１０の基本機能は、それぞれのデータパイプ、PLSセル、及びEAC/FICセルに対するタイムインターリービングによって生成されたデータセルを、存在すれば、１つのフレーム内でそれぞれのOFDMシンボルに該当するアクティブ(active)OFDMセルのアレイにマッピングするものである。(PSI(program specific information)/SIのような)サービスシグナリングデータは、個別的に収集されてデータパイプによって送信される。セルマッパは、フレーム構造の構成及びスケジューラーによって生成されたダイナミックインフォメーション(dynamic information)に応じて動作する。フレームに関する詳しい内容は後述する。
【０１９１】
周波数インターリーバ７０２０は、セルマッパ７０１０から受信されたデータセルをランダムにインターリービングして、周波数ダイバーシティーを提供することができる。また、周波数インターリーバ７０２０は、単一フレームで最大のインターリービング利得を得るために、他のインターリービングシード(seed)順を利用して、２つの順次的なOFDMシンボルから構成されたOFDMシンボルペア(pair)で動作することができる。
【０１９２】
前述したブロックは、省略または類似または同一機能を有するブロックで代替することができる。
【０１９３】
図８は、本発明の一実施例に係るOFDM生成ブロックを示す。
【０１９４】
図８に図示されたOFDM生成ブロックは、図１を参照して説明したOFDM生成ブロック１０３０の一実施例に該当する。
【０１９５】
OFDM生成ブロックは、フレームビルディングブロックによって生成されたセルによってOFDMキャリアを変調して、パイロットを挿入し、伝送のための時間領域信号を生成する。また、該当ブロックは順次ガードインターバルを挿入し、PAPR減少処理を適用して最終RF信号を生成する。
【０１９６】
図８に示すように、OFDM生成ブロックは、パイロット及びリザーブドトーン挿入ブロック(pilot and reserved tone insertion block)８０００、２Ｄ-eSFN(single frequency network)エンコーディングブロック８０１０、IFFT(inverse fast Fourier transform)ブロック８０２０、PAPR減少ブロック８０３０、ガードインターバル挿入ブロック(guard interval insertion block)８０４０、プリアンブル挿入ブロック(preamble insertion block)８０５０、その他システム挿入ブロック８０６０、及びDACブロック８０７０を含むことができる。
【０１９７】
パイロットと予約トーン挿入ブロック8000は、パイロットや予約済みのトーンを挿入することができます。
【０１９８】
OFDMシンボル内の種々のセルが送信値が受信機において事前に知られているパイロットとして既知の基準情報で変調されます。パイロット・セルの情報は、分散パイロット、継続的なパイロット、エッジパイロット、FSS（フレームシグナリングシンボル）のパイロットとPES（フレームエッジシンボル）のパイロットから構成されています。各パイロットは、パイロットタイプとパイロットパターンに応じて特定の昇圧電力レベルで送信されます。パイロット情報の値は、値の系列、任意の所与のシンボルを各送信キャリアのための1つである参照配列に由来します。パイロットは、フレーム同期、周波数同期、時間同期、チャネル推定、および送信モードの識別に使用することができ、また、位相雑音を追跡するために使用することができます。
【０１９９】
参照配列から取られた参照情報は、フレームのプリアンブル、PSS及びPESを除くすべてのシンボルに散乱パイロット・セルで送信されます。継続的なパイロットは、フレームのすべてのシンボルに挿入されます。継続的なパイロットの数及び位置は、PPTの大きさと散乱パイロットパターンの両方に依存します。エッジキャリアは、プリアンブルシンボルを除くすべてのシンボルのエッジパイロットです。これらは、スペクトルの端までの周波数補間を可能にするために挿入されています。PSSパイロットはPSS（複数可）に挿入され、PESパイロットは、PESに挿入されています。これらは、フレームのエッジまでの時間補間を可能にするために挿入されています。
【０２００】
本発明の実施形態に係るシステムは、分散MISO方式が、必要に応じて、非常に強固な伝送モードをサポートするために使用されるSPNのネットワークをサポートします。2D-ESPNは、SPNネットワーク内の異なる送信機サイトに位置して、それぞれが複数の送信アンテナを使用する分散MISO方式です。
【０２０１】
2D-ESPNの符号化ブロック8010は、SPNの設定時間と周波数ダイバーシティーの両方を作成するために、複数の送信機から送信された信号の位相を歪めるために2D-ESPN処理を処理することができます。したがって、低いフラットフェージングや長い時間のために、深いフェージングバーストエラーを軽減することができます。
【０２０２】
IPPTブロック8020は、OPDM変調方式を用いた2D-ESPNの符号化ブロック8010の出力を調節することができます。パイロット（または予約トーンなど）として指定されていないデータシンボルの任意のセルは、周波数インターリーバからのデータセルの1つを運びます。セルは、OPDMキャリアにマップされます。
【０２０３】
PAPR低減ブロック8030は、時間領域内の様々なPAPR低減アルゴリズムを使用して入力信号のPAPR低減を行うことができます。
【０２０４】
ガードインターバル挿入ブロック8040は、ガードインターバルを挿入することができますし、プリアンブル挿入ブロック8050は、信号の前にプリアンブルを挿入することができます。プリアンブルの構造の詳細については後述します。他のシステムの挿入ブロック8060は、放送サービスを提供する二つ以上の異なるブロードキャスト送信/受信システムのデータが同時に同じRP信号帯域幅で送信することができ、時間領域におけるブロードキャスト送信/受信システムの複数の信号を多重化することができます。この場合、2つ以上の異なるブロードキャスト送信/受信システムは、異なるブロードキャストサービスを提供するシステムを指します。異なるブロードキャストサービスは、それぞれの放送サービスに関連するデータは、異なるフレームを介して送信することができる等の地上波放送サービス、モバイル放送サービスを意味することができます。
【０２０５】
DACブロック8070は、アナログ信号と出力アナログ信号に入力されたデジタル信号に変換することができます。DACブロック7800から出力された信号は、物理層プロファイルに応じて複数の出力アンテナを介して送信されることができます。本発明の実施形態に係る送信アンテナは、垂直または水平の極性を有することができます。
【０２０６】
上記ブロックは省略する、又は設計に応じて、類似または同一の機能を有するブロックに置き換えることができます。
【０２０７】
図９は、本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す。
【０２０８】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応する。
【０２０９】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール(synchronization & demodulation module)９０００、フレーム解析モジュール(frame parsing module)９０１０、デマッピング及びデコーディングモジュール(demapping & decoding module)９０２０、出力プロセッサ(output processor)９０３０、及びシグナリングデコーディングモジュール(signaling decoding module)９０４０を含むことができる。放送信号受信装置の各モジュールの動作について説明する。
【０２１０】
同期及び復調モジュール９０００は、m個の受信アンテナを介して入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置によって実行される手順の逆過程に該当する復調を実行することができる。
【０２１１】
フレーム解析モジュール９１００は、入力信号フレームを解析し、ユーザによって選択されたサービスが伝送されるデータを抽出することができる。放送信号送信装置がインターリービングを実行すると、フレーム解析モジュール９１００は、インターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されるべき信号及びデータの位置が、シグナリングデコーディングモジュール９４００から出力されたデータをデコーディングすることで取得され、放送信号送信装置によって生成されたスケジューリング情報が復元される。
【０２１２】
デマッピング及びデコーディングモジュール９２００は、入力信号をビット領域データに変換した後、必要に応じてビット領域データをデインターリービングすることができる。デマッピング及びデコーディングモジュール９２００は、伝送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングを介して伝送チャネルで発生したエラーを訂正することができる。この場合、デマッピング及びデコーディングモジュール９２００は、シグナリングデコーディングモジュール９４００から出力されたデータをデコーディングすることで、デマッピング及びデコーディングのために必要な伝送パラメータを取得することができる。
【０２１３】
出力プロセッサ９３００は、伝送効率を向上させるために、放送信号送信装置によって適用される多様な圧縮/信号処理手順の逆過程を実行することができる。この場合、出力プロセッサ９３００は、シグナリングデコーディングモジュール９４００から出力されたデータから必要な制御情報を取得することができる。出力プロセッサ８３００の出力は、放送信号送信装置に入力される信号に該当し、例えばMPEG-TS、IPストリーム(v４またはv６)及びGSである。
【０２１４】
シグナリングデコーディングモジュール９４００は、同期及び復調モジュール９０００によって復調された信号からPLS情報を取得することができる。上述したように、フレーム解析モジュール９１００、デマッピング及びデコーディングモジュール９２００、出力プロセッサ９３００は、シグナリングデコーディングモジュール９４００から出力されたデータを利用してその機能を実行することができる。
【０２１５】
図１０は、本発明の一実施例に係るフレーム構造を示す。
【０２１６】
図１０は、フレームタイプの構成例及びスーパーフレームにおけるFRU(frame repetition unit、フレーム繰返し単位)を示す。(a)は、本発明の一実施例に係るスーパーフレームを示し、(b)は、本発明の一実施例に係るFRUを示し、(c)はFRUでの多様なフィジカルプロファイル(PHY profile)のフレームを示し、(d)はフレームの構造を示す。
【０２１７】
スーパーフレームは、８個のFRUで構成することができる。FRUはフレームのTDMに対する基本マルチプレックス単位であり、スーパーフレームで８回繰り返される。
【０２１８】
FRUで各フレームは、フィジカルプロファイル(ベース、ハンドヘルド、アドバンスドプロファイル)のうちの１つまたはFEFに属する。FRUでフレームの最大許容数は４であり、与えられたフィジカルプロファイルは、FRUで０回〜４回のいずれかの回数だけ出現できる(例えば、ベース、ベース、ハンドヘルド、アドバンスド)。フィジカルプロファイルの定義は、必要に応じてプリアンブルにおけるPHY_PROFILEのリザーブド値(reserved value)を利用して拡張可能である。
【０２１９】
FEF部分は、含まれる場合FRUの終わりに挿入される。FEFがFRUに含まれる場合、FEFの最大数はスーパーフレームで８である。FEF部分がお互いに隣接することは推奨されない。
【０２２０】
１つのフレームは、多数のOFDMシンボル及びプリアンブルにさらに分離される。(d)に示したように、フレームは、プリアンブル、１つ以上のFSS、ノーマルデータシンボル、FESを含む。
【０２２１】
プリアンブルは、高速フューチャーキャストUTBシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルについての詳しい内容は後述する。
【０２２２】
FSSの主な目的は、PLSデータを伝達することである。高速同期化及びチャネル推定のために、これに伴うPLSデータの高速デコーディングのために、FSSはノーマルデータシンボルより高密度なパイロットパターンを有する。FESはFSSと完全に同一なパイロットを有するが、これはFESの直前のシンボルに対して外挿(extrapolation)なしにFES内での周波数のみの補間(interpolation)及び時間的補間(temporal interpolation)を可能とする。
【０２２３】
図１１は、本発明の一実施例に係るフレームのシグナリング階層構造(signaling hierarchy structure)を示す。
【０２２４】
図１１は、シグナリング階層構造を示すが、これは３つの主な部分であるプリアンブルシグナリングデータ１１０００、PLS１データ１１０１０、及びPLS２データ１１０２０に分割される。各フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータ及び伝送タイプを示すことである。PLS１は、受信機が関心のあるデータパイプに接続するためのパラメータを含むPLS２データに接続してデコーディングすることができるようにする。PLS２は、各フレームごとに伝達され、２つの主な部分であるPLS２-STATデータとPLS２-DYNデータに分割される。PLS２データのスタティック及びダイナミック部分には、必要に応じてパディングがなされる。
【０２２５】
図１２は、本発明の一実施例に係るプリアンブルシグナリングデータを示す。
【０２２６】
プリアンブルシグナリングデータは、受信機がフレーム構造内でPLSデータに接続し、データパイプを追跡できるようにするために必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータについての詳しい内容は、次のようである。
【０２２７】
PHY_PROFILE：該当３ビットフィールドは、現在のフレームのフィジカルプロファイルタイプを示す。異なるフィジカルプロファイルタイプのマッピングは、以下の表５に示す。
【０２２８】
【表５】
2018207499.tif 000008
【０２２９】
FFT_SIZE：該当２ビットフィールドは、以下の表６で説明するように、フレームグループ内で現在のフレームのFFTサイズを示す。
【０２３０】
【表６】
2018207499.tif 000009
【０２３１】
GI_FRACTION：該当３ビットフィールドは、以下の表７で説明するように、現在のスーパーフレームにおけるガードインターバルの一部(fraction)値を示す。
【０２３２】
【表７】
2018207499.tif 000010
【０２３３】
EAC_FLAG：該当１ビットフィールドは、EACが現在のフレームに提供されるのか否かを示す。該当フィールドが１に設定されると、EASが現在のフレームに提供される。該当フィールドが０に設定されると、EASが現在のフレームに伝達されない。該当フィールドは、スーパーフレーム内でダイナミックに転換される。
【０２３４】
PILOT_MODE：該当１ビットフィールドは、現在のフレームグループで現在のフレームに対してパイロットモードがモバイルモードであるのかまたは固定モードであるのかを示す。該当フィールドが０に設定されると、モバイルパイロットモードが使用される。該当フィールドが１に設定されると、固定パイロットモードが使用される。
【０２３５】
PAPR_FLAG：該当１ビットフィールドは、現在のフレームグループで現在のフレームに対してPAPR減少が使用されているのか否かを示す。該当フィールドが１に設定されると、トーン予約(tone reservation)がPAPR減少のために使用される。該当フィールドが０に設定されると、PAPR減少が使用されない。
【０２３６】
FRU_CONFIGURE：該当３ビットフィールドは、現在のスーパーフレームで存在するFRUのフィジカルプロファイルタイプ構成を示す。現在のスーパーフレームですべてのプリアンブルにおける該当フィールドで、現在のスーパーフレームで伝達されるすべてのプロファイルタイプが識別される。該当３ビットフィールドは、以下の表８に示したように、それぞれのプロファイルに対して異なるように定義される。
【０２３７】
【表８】
2018207499.tif 000011
【０２３８】
RESERVED：該当７ビットフィールドは、将来使用のためにリザーブされる(reserved)。
【０２３９】
図１３は、本発明の一実施例に係るPLS１データを示す。
【０２４０】
PLS１データは、PLS２の受信及びデコーディングを可能とするために必要なパラメータを含んだ基本伝送パラメータを提供する。上述したように、PLS１データは、１つのフレームグループの全体デュレーションの間変化しない。PLS１データのシグナリングフィールドの具体的な定義は次のようである。
【０２４１】
PREAMBLE_DATA：該当２０ビットフィールドは、EAC_FLAGを除いたプリアンブルシグナリングデータのコピーである。
【０２４２】
NUM_FRAME_FRU：該当２ビットフィールドは、FRU当たりのフレーム数を示す。
【０２４３】
PAYLOAD_TYPE：該当３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。PAYLOAD_TYPEは、表９に示したようにシグナリングされる。
【０２４４】
【表９】
2018207499.tif 000012
【０２４５】
NUM_FSS：該当２ビットフィールドは、現在のフレームでFSSの数を示す。
【０２４６】
SYSTEM_VERSION：該当８ビットフィールドは、伝送される信号フォーマットのバージョンを示す。SYSTEM_VERSIONは主バージョン及び副バージョンの２つの４ビットフィールドに分離される。
【０２４７】
主バージョン：SYSTEM_VERSIONフィールドのMSBである４ビットは、主バージョン情報を示す。主バージョンフィールドにおける変化は互換が不可能な変化を示す。デフォルト値は００００である。この標準に記述されたバージョンに対して、値が００００に設定される。
【０２４８】
副バージョン：SYSTEM_VERSIONフィールドのLSBである４ビットは、副バージョン情報を示す。副バージョンフィールドにおける変化は互換が可能である。
【０２４９】
CELL_ID：これは、ATSCネットワークで地理的セルを一意に識別する１６ビットフィールドである。ATSCセルカバレッジは、フューチャーキャストUTBシステム当たりに使用される周波数の数に応じて１つ以上の周波数から構成される。CELL_IDの値が知られていないか特定されないと、該当フィールドは０に設定される。
【０２５０】
NETWORK_ID：これは現在のATSCネットワークを一意に識別する１６ビットフィールドである。
【０２５１】
SYSTEM_ID：該当１６ビットフィールドは、ATSCネットワーク内でフューチャーキャストUTBシステムを一意に識別する。フューチャーキャストUTBシステムは、入力が１つ以上の入力ストリーム(TS、IP、GS)であり、出力がRF信号である地上波放送システムである。フューチャーキャストUTBシステムは、存在する場合FEF及び１つ以上のフィジカルプロファイルを伝達する。同一フューチャーキャストUTBシステムは、異なる入力ストリームを伝達し、異なる地理的領域で異なるRFを使用でき、ローカルサービス挿入を許容する。フレーム構造及びスケジューリングは１つの場所で制御され、フューチャーキャストUTBシステム内ですべての伝送に対して同一である。１つ以上のフューチャーキャストUTBシステムは、すべて同一フィジカル構造及び構成を有する同一SYSTEM_IDの意味を持つことができる。
【０２５２】
次のループ(loop)は、各フレームタイプの長さ及びFRU構成を示すFRU_PHY_PROFILE、FRU_FRAME_LENGTH、FRU_GI_FRACTION、RESERVEDから構成される。ループ(loop)のサイズは、FRU内で４つのフィジカルプロファイル(FEF含む)がシグナリングされるように固定される。NUM_FRAME_FRUが４より小さいと、使用されないフィールドはゼロで満たされる。
【０２５３】
FRU_PHY_PROFILE：該当３ビットフィールドは、関連したFRUの(i+１)番目のフレーム(iはループ(loop)インデックス)のフィジカルプロファイルタイプを示す。該当フィールドは、表８に示したものと同一シグナリングフォーマットを用いる。
【０２５４】
FRU_FRAME_LENGTH：該当２ビットフィールドは、関連したFRUの(i+１)番目のフレームの長さを示す。FRU_GI_FRACTIONと一緒にFRU_FRAME_LENGTHを使用すると、フレームデュレーションの正確な値が得られる。
【０２５５】
FRU_GI_FRACTION：該当３ビットフィールドは、関連したFRUの(i+１)番目のフレームのガードインターバルの一部値を示す。FRU_GI_FRACTIONは、表７に従ってシグナリングされる。
【０２５６】
RESERVED：該当４ビットフィールドは、将来使用のためにリザーブされる(reserved)。
【０２５７】
次のフィールドは、PLS２データをデコーディングするためのパラメータを提供する。
【０２５８】
PLS２_FEC_TYPE：該当２ビットフィールドは、PLS２保護によって使用されるFECタイプを示す。FECタイプは、表１０に従ってシグナリングされる。LDPCコードについての詳しい内容は後述する。
【０２５９】
【表１０】
2018207499.tif 000013
【０２６０】
PLS２_MOD：該当３ビットフィールドは、PLS２によって使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。
【０２６１】
【表１１】
2018207499.tif 000014
【０２６２】
PLS２_SIZE_CELL：該当１５ビットフィールドは、現在のフレームグループで伝達されるPLS２に対するすべてのコーディングブロックのサイズ(QAMセルの数として特定される)のCtotal_partial_blockを示す。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２６３】
PLS２_STAT_SIZE_BIT：該当１４ビットフィールドは、現在のフレームグループに対するPLS２-STATのサイズをビット数で示す。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２６４】
PLS２_DYN_SIZE_BIT：該当１４ビットフィールドは、現在のフレームグループに対するPLS２-DYNのサイズをビット数で示す。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２６５】
PLS２_REP_FLAG：該当１ビットフラッグは、PLS２繰返しモードが現在のフレームグループで使用されているのか否かを示す。該当フィールドの値が１に設定されると、PLS２繰返しモードは活性化される。該当フィールドの値が０に設定されると、PLS２繰返しモードは非活性化される。
【０２６６】
PLS２_REP_SIZE_CELL：該当１５ビットフィールドは、PLS２繰返しが使用される場合、現在のフレームグループの各フレームごとに伝達されるPLS２に対する部分コーディングブロックのサイズ(QAMセルの数として特定される)のCtotal_partial_blockを示す。繰返しが使用されない場合、該当フィールドの値は０と同一である。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２６７】
PLS２_NEXT_FEC_TYPE：該当２ビットフィールドは、次のフレームグループの各フレームで伝達されるPLS２に使用されるFECタイプを示す。FECタイプは、表１０に従ってシグナリングされる。
【０２６８】
PLS２_NEXT_MOD：該当３ビットフィールドは、次のフレームグループの各フレームで伝達されるPLS２に使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。
【０２６９】
PLS２_NEXT_REP_FLAG：該当１ビットフラッグは、PLS２繰返しモードが次のフレームグループで使用されているのか否かを示す。該当フィールドの値が１に設定されると、PLS２繰返しモードは活性化される。該当フィールドの値が０に設定されると、PLS２繰返しモードは非活性化される。
【０２７０】
PLS２_NEXT_REP_SIZE_CELL：該当１５ビットフィールドは、PLS２繰返しが使用される場合、次のフレームグループの各フレームごとに伝達されるPLS２に対する全体コーディングブロックのサイズ(QAMセルの数として特定される)のCtotal_full_blockを示す。次のフレームグループで繰返しが使用されない場合、該当フィールドの値は０と同一である。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２７１】
PLS２_NEXT_REP_STAT_SIZE_BIT：該当１４ビットフィールドは、次のフレームグループに対するPLS２-STATのサイズをビット数で示す。該当値は、現在のフレームグループにおいて一定である。
【０２７２】
PLS２_NEXT_REP_DYN_SIZE_BIT：該当１４ビットフィールドは、次のフレームグループに対するPLS２-DYNのサイズをビット数で示す。該当値は、現在のフレームグループにおいて一定である。
【０２７３】
PLS２_AP_MODE：該当２ビットフィールドは、現在のフレームグループでPLS２に対して追加パリティが提供されるのか否かを示す。該当値は、現在のフレームグループの全体デュレーションの間一定である。以下の表１２は、該当フィールドの値を提供する。該当フィールドの値が００に設定されると、現在のフレームグループで追加パリティがPLS２に対して使用されない。
【０２７４】
【表１２】
2018207499.tif 000015
【０２７５】
PLS２_AP_SIZE_CELL：該当１５ビットフィールドは、PLS２の追加パリティビットのサイズ(QAMセルの数として特定される)を示す。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２７６】
PLS２_NEXT_AP_MODE：該当２ビットフィールドは、次のフレームグループの各フレームごとにPLS２シグナリングに対して追加パリティが提供されるのか否かを示す。該当値は、現在のフレームグループの全体デュレーションの間一定である。表１２は、該当フィールドの値を定義する。
【０２７７】
PLS２_NEXT_AP_SIZE_CELL：該当１５ビットフィールドは、次のフレームグループの各フレームごとにPLS２の追加パリティビットのサイズ(QAMセルの数として特定される)を示す。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２７８】
RESERVED：該当３２ビットフィールドは、将来使用のためにリザーブされる(reserved)。
【０２７９】
CRC_３２：全体PLS１シグナリングに適用される３２ビットエラー検出コード。
【０２８０】
図１４は、本発明の一実施例に係るPLS２データを示す。
【０２８１】
図１４は、PLS２データのPLS２-STATデータを示す。PLS２-STATデータは、フレームグループ内で同一である反面、PLS２-DYNデータは、現在のフレームに対して特定の情報を提供する。
【０２８２】
PLS２-STATデータのフィールドについて次に具体的に説明する。
【０２８３】
FIC_FLAG：該当１ビットフィールドは、FICが現在のフレームグループで使用されているのか否かを示す。該当フィールドの値が１に設定されると、FICは現在のフレームで提供される。該当フィールドの値が０に設定されると、FICは現在のフレームで伝達されない。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２８４】
AUX_FLAG：該当１ビットフィールドは、補助ストリームが現在のフレームグループで使用されているのか否かを示す。該当フィールドの値が１に設定されると、補助ストリームは現在のフレームで提供される。該当フィールドの値が０に設定されると、補助フレームは現在のフレームで伝達されない。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２８５】
NUM_DP：該当６ビットフィールドは、現在のフレーム内で伝達されるデータパイプの数を示す。該当フィールドの値は１から６４の間であり、データパイプの数はNUM_DP+１である。
【０２８６】
DP_ID：該当６ビットフィールドは、フィジカルプロファイル内でDPを一意に識別する。
【０２８７】
DP_TYPE：該当３ビットフィールドは、データパイプのタイプを示す。これは、以下の表１３に従ってシグナリングされる。
【０２８８】
【表１３】
2018207499.tif 000016
【０２８９】
DP_GROUP_ID：該当８ビットフィールドは、現在のデータパイプが関連しているデータパイプグループを識別する。これは、受信機が同一DP_GROUP_IDを有するようになる特定サービスと関連しているサービスコンポーネントのデータパイプに接続するために使用される。
【０２９０】
BASE_DP_ID：該当６ビットフィールドは、管理層で使用される(PSI/SIのような)サービスシグナリングデータを伝達するデータパイプを示す。BASE_DP_IDによって示すデータパイプは、サービスデータと一緒にサービスシグナリングデータを伝達するノーマルデータパイプであるか、サービスシグナリングデータだけを伝達する専用データパイプである。
【０２９１】
DP_FEC_TYPE：該当２ビットフィールドは、関連したデータパイプによって使用されるFECタイプを示す。FECタイプは、以下の表１４に従ってシグナリングされる。
【０２９２】
【表１４】
2018207499.tif 000017
【０２９３】
DP_COD：該当４ビットフィールドは、関連したデータパイプによって使用されるコードレート(code rate)を示す。コードレート(code rate)は、以下の表１５に従ってシグナリングされる。
【０２９４】
【表１５】
2018207499.tif 000018
【０２９５】
DP_MOD：該当４ビットフィールドは、関連したデータパイプによって使用される変調を示す。変調は、以下の表１６に従ってシグナリングされる。
【０２９６】
【表１６】
2018207499.tif 000019
【０２９７】
DP_SSD_FLAG：該当１ビットフィールドは、SSDモードが関連したデータパイプで使用されているのか否かを示す。該当フィールドの値が１に設定されると、SSDは使用される。該当フィールドの値が０に設定されると、SSDは使用されない。
【０２９８】
次のフィールドは、PHY_PROFILEがアドバンスドプロファイルを示す０１０と同一であるときのみ現れる。
【０２９９】
DP_MIMO：該当３ビットフィールドは、どのタイプのMIMOエンコーディング処理が関連したデータパイプに適用されるのかを示す。MIMOエンコーディング処理のタイプは、以下の表１７に従ってシグナリングされる。
【０３００】
【表１７】
2018207499.tif 000020
【０３０１】
DP_TI_TYPE：該当１ビットフィールドは、タイムインターリービングのタイプを示す。０の値は、１つのタイムインターリービンググループが１つのフレームに該当し、１つ以上のタイムインターリービングブロックを含むことを示す。１の値は、１つのタイムインターリービンググループが１つより多いフレームで伝達され、１つのタイムインターリービングブロックのみを含むことを示す。
【０３０２】
DP_TI_LENGTH：該当２ビットフィールド(許容値は１、２、４、８のみ)の使用は、次のようなDP_TI_TYPEフィールド内で設定される値によって決定される。
【０３０３】
DP_TI_TYPEの値が１に設定されると、該当フィールドは、それぞれのタイムインターリービンググループがマッピングされるフレームの数であるPIを示し、タイムインターリービンググループ当たり１つのタイムインターリービングブロックが存在する(NTI=１)。該当２ビットフィールドで許容されるPIの値は、以下の表１８に定義される。
【０３０４】
DP_TI_TYPEの値が０に設定されると、該当フィールドはタイムインターリービンググループ当たりタイムインターリービングブロックの数であるNTIを示し、フレーム当たり１つのタイムインターリービンググループが存在する(PI=１)。該当２ビットフィールドで許容されるPIの値は、以下の表１８に定義される。
【０３０５】
【表１８】
2018207499.tif 000021
【０３０６】
DP_FRAME_INTERVAL：該当２ビットフィールドは、関連したデータパイプに対するフレームグループ内でフレーム間隔(IJUMP)を示し、許容値は１、２、４、８(該当する２ビットフィールドは、それぞれ００、０１、１０、１１)である。フレームグループのすべてのフレームに現れないデータパイプに対して、該当フィールドの値は、順次的なフレーム間の間隔と同一である。例えば、データパイプが１、５、９、１３等のフレームに現れると、該当フィールドの値は４に設定される。すべてのフレームに現れるデータパイプに対して、該当フィールドの値は１に設定される。
【０３０７】
DP_TI_BYPASS：該当１ビットフィールドは、タイムインターリーバ５０５０の使用可能性を決定する。データパイプに対してタイムインターリービングが使用されないと、該当フィールド値は１に設定される。反面、タイムインターリービングが使用されると、該当フィールド値は０に設定される。
【０３０８】
DP_FIRST_FRAME_IDX：該当５ビットフィールドは、現在のデータパイプが発生するスーパーフレームの最初のフレームのインデックスを示す。DP_FIRST_FRAME_IDXの値は０から３１の間である。
【０３０９】
DP_NUM_BLOCK_MAX：該当１０ビットフィールドは、該当データパイプに対するDP_NUM_BLOCKSの最大値を示す。該当フィールドの値は、DP_NUM_BLOCKSと同一範囲を有する。
【０３１０】
DP_PAYLOAD_TYPE：該当２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードデータのタイプを示す。DP_PAYLOAD_TYPEは、以下の表１９に従ってシグナリングされる。
【０３１１】
【表１９】
2018207499.tif 000022
【０３１２】
DP_INBAND_MODE：該当２ビットフィールドは、現在のデータパイプがインバンド(In-band)シグナリング情報を伝達するのか否かを示す。インバンド(In-band)シグナリングタイプは、以下の表２０に従ってシグナリングされる。
【０３１３】
【表２０】
2018207499.tif 000023
【０３１４】
DP_PROTOCOL_TYPE：該当２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは、入力ペイロードタイプが選択されると、以下の表２１に従ってシグナリングされる。
【０３１５】
【表２１】
2018207499.tif 000024
【０３１６】
DP_CRC_MODE：該当２ビットフィールドは、CRCエンコーディングがインプットフォーマットブロックで使用されているのか否かを示す。CRCモードは、以下の表２２に従ってシグナリングされる。
【０３１７】
【表２２】
2018207499.tif 000025
【０３１８】
DNP_MODE：該当２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるヌルパケット削除モードを示す。DNP_MODEは、以下の表２３に従ってシグナリングされる。DP_PAYLOAD_TYPEがTS(「００」)ではない場合、DNP_MODEは００の値に設定される。
【０３１９】
【表２３】
2018207499.tif 000026
【０３２０】
ISSY_MODE：該当２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるISSYモードを示す。ISSY_MODEは、以下の表２４に従ってシグナリングされる。DP_PAYLOAD_TYPEがTS(「００」)ではない場合、ISSY_MODEは００の値に設定される。
【０３２１】
【表２４】
2018207499.tif 000027
【０３２２】
HC_MODE_TS：該当２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるTSヘッダ圧縮モードを示す。HC_MODE_TSは、以下の表２５に従ってシグナリングされる。
【０３２３】
【表２５】
2018207499.tif 000028
【０３２４】
HC_MODE_IP：該当２ビットフィールドは、DP_PAYLOAD_TYPEがIP(「０１」)に設定される場合にIPヘッダ圧縮モードを示す。HC_MODE_IPは、以下の表２６に従ってシグナリングされる。
【０３２５】
【表２６】
2018207499.tif 000029
【０３２６】
PID：該当１３ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定され、HC_MODE_TSが０１または１０に設定される場合にTSヘッダ圧縮のためのPID数を示す。
【０３２７】
RESERVED：該当８ビットフィールドは、将来使用のためにリザーブされる(reserved)。
【０３２８】
次のフィールドは、FIC_FLAGが１と同一であるときのみ現れる。
【０３２９】
FIC_VERSION：該当８ビットフィールドは、FICのバージョンナンバーを示す。
【０３３０】
FIC_LENGTH_BYTE：該当１３ビットフィールドは、FICの長さをバイト単位で示す。
【０３３１】
RESERVED：該当８ビットフィールドは、将来使用のためにリザーブされる(reserved)。
【０３３２】
次のフィールドは、AUX_FLAGが１と同一であるときのみ現れる。
【０３３３】
NUM_AUX：該当４ビットフィールドは、補助ストリームの数を示す。ゼロは補助ストリームが使用されないことを示す。
【０３３４】
AUX_CONFIG_RFU：該当８ビットフィールドは、将来使用のためにリザーブされる(reserved)。
【０３３５】
AUX_STREAM_TYPE：該当４ビットは、現在の補助ストリームのタイプを示すための将来使用のためにリザーブされる(reserved)。
【０３３６】
AUX_PRIVATE_CONFIG：該当２８ビットフィールドは、補助ストリームをシグナリングするための将来使用のためにリザーブされる(reserved)。
【０３３７】
図１５は、本発明の他の一実施例に係るPLS２データを示す。
【０３３８】
図１５は、PLS２データのPLS２-DYNを示す。PLS２-DYNデータの値は、１つのフレームグループのデュレーションの間変化できる反面、フィールドのサイズは一定である。
【０３３９】
PLS２-DYNデータのフィールドの具体的な内容は、次のようである。
【０３４０】
FRAME_INDEX：該当５ビットフィールドは、スーパーフレーム内で現在のフレームのフレームインデックスを示す。スーパーフレームの最初のフレームのインデックスは０に設定される。
【０３４１】
PLS_CHANGE_COUNTER：該当４ビットフィールドは、構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、該当フィールド内でシグナリングされる値によって示す。該当フィールドの値が００００に設定されると、これはいかなる予定された変化も予測されないことを意味する。例えば、１の値は次のスーパーフレームに変化があることを示す。
【０３４２】
FIC_CHANGE_COUNTER：該当４ビットフィールドは、構成(すなわち、FICのコンテンツ)が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、該当フィールド内でシグナリングされる値によって示す。該当フィールドの値が００００に設定されると、これはいかなる予定された変化も予測されないことを意味する。例えば、０００１の値は次のスーパーフレームに変化があることを示す。
【０３４３】
RESERVED：該当１６ビットフィールドは、将来使用のためにリザーブされる(reserved)。
【０３４４】
次のフィールドは、現在のフレームで伝達されるデータパイプに関連したパラメータを説明するNUM_DPにおけるループ(loop)に現れる。
【０３４５】
DP_ID：該当６ビットフィールドは、フィジカルプロファイル内でデータパイプを一意に示す。
【０３４６】
DP_START：該当１５ビット(または１３ビット)フィールドは、DPUアドレッシング(addressing)方式を使用してデータパイプの最初の開始位置を示す。DP_STARTフィールドは、以下の表２７に示したように、フィジカルプロファイル及びFFTサイズに応じて異なる長さを有する。
【０３４７】
【表２７】
2018207499.tif 000030
【０３４８】
DP_NUM_BLOCK：該当１０ビットフィールドは、現在のデータパイプに対する現在のタイムインターリービンググループでFECブロックの数を示す。DP_NUM_BLOCKの値は０から１０２３の間にある。
【０３４９】
RESERVED：該当８ビットフィールドは、将来使用のためにリザーブされる(reserved)。
【０３５０】
次のフィールドは、EACに関連したFICパラメータを示す。
【０３５１】
EAC_FLAG：該当１ビットフィールドは、現在のフレームでEACの存在を示す。該当ビットは、プリアンブルでEAC_FLAGと同一値である。
【０３５２】
EAS_WAKE_UP_VERSION_NUM：該当８ビットフィールドは、自動活性化指示のバージョンナンバーを示す。
【０３５３】
EAC_FLAGフィールドが１と同一であれば、次の１２ビットがEAC_LENGTH_BYTEフィールドに割り当てられる。EAC_FLAGフィールドが０と同一であれば、次の１２ビットがEAC_COUNTERに割り当てられる。
【０３５４】
EAC_LENGTH_BYTE：該当１２ビットフィールドは、EACの長さをバイトで示す。
【０３５５】
EAC_COUNTER：該当１２ビットフィールドは、EACが到達するフレームの前のフレームの数を示す。
【０３５６】
次のフィールドは、AUX_FLAGフィールドが１と同一である場合のみ現れる。
【０３５７】
AUX_PRIVATE_DYN：該当４８ビットフィールドは、補助ストリームをシグナリングするための将来使用のためにリザーブされる(reserved)。該当フィールドの意味は、設定可能なPLS２-STATでAUX_STREAM_TYPEの値に依存する。
【０３５８】
CRC_３２：全体PLS２に適用される３２ビットエラー検出コード。
【０３５９】
図１６は、本発明の一実施例に係るフレームの論理(logical)構造を示す。
【０３６０】
上述したように、PLS、EAC、FIC、データパイプ、補助ストリーム、ダミーセルは、フレームでOFDMシンボルのアクティブ(active)キャリアにマッピングされる。PLS１及びPLS２は、まず１つ以上のFSSにマッピングされる。その後、EACが存在する場合、EACセルは直後のPLSフィールドにマッピングされる。次にFICが存在する場合FICセルがマッピングされる。データパイプは、PLS次にマッピングされるか、EACまたはFICが存在する場合、EACまたはFIC以後にマッピングされる。タイプ１データパイプがまずマッピングされ、タイプ２データパイプが次にマッピングされる。データパイプのタイプの具体的な内容は後述する。一部の場合、データパイプはEASに対する一部特殊データまたはサービスシグナリングデータを伝達することができる。補助ストリームまたはストリームは、存在する場合データパイプを次にマッピングし、ここには順次ダミーセルが後を追う。前述した順序、すなわち、PLS、EAC、FIC、データパイプ、補助ストリーム、及びダミーセルの順序で全部一緒にマッピングすると、フレームでセル容量を正確に満たす。
【０３６１】
図１７は、本発明の一実施例に係るPLSマッピングを示す。
【０３６２】
PLSセルは、FSSのアクティブ(active)キャリアにマッピングされる。PLSが占めるセルの数に応じて、１つ以上のシンボルがFSSと指定され、FSSの数NFSSは、PLS１でのNUM_FSSによってシグナリングされる。FSSは、PLSセルを伝達する特殊なシンボルである。堅固性及び遅延時間(latency)は、PLSで重大な問題であるから、FSSは高いパイロット密度を有しており、高速同期化及びFSS内での周波数のみのインターポレーション(interpolation、補間)を可能とする。
【０３６３】
PLSセルは、図１７の例に示したようにトップダウン方式でFSSのアクティブ(active)キャリアにマッピングされる。PLS１セルは、まず最初のFSSの最初のセルからセルインデックスの昇順にマッピングされる。PLS２セルは、PLS１の最後のセルの直後を追い、マッピングは最初のFSSの最後のセルインデックスまで下方向に続く。必要なPLSセルの合計数が１つのFSSのアクティブ(active)キャリアの数を超えると、マッピングは次のFSSに進行し、最初のFSSと完全に同一方式で続けられる。
【０３６４】
PLSマッピングが完了した後、データパイプが次に伝達される。EAC、FICまたは両方とも現在のフレームに存在すれば、EAC及びFICは、PLSとノーマルデータパイプの間に配置される。
【０３６５】
図１８は、本発明の一実施例に係るEACマッピングを示す。
【０３６６】
EACは、EASメッセージを伝達する専用チャネルであり、EASに対するデータパイプに連結される。EASサポートは提供されるが、EAC自体はすべてのフレームに存在してもよく、存在しなくてもよい。EACが存在する場合、EACはPLS２セルの直後にマッピングされる。PLSセルを除いて、FIC、データパイプ、補助ストリームまたはダミーセルのいずれもEACの前に位置しない。EACセルのマッピング手順はPLSと完全に同一である。
【０３６７】
EACセルは、図１８の例に示したようにPLS２の次のセルからセルインデックスの昇順にマッピングされる。EASメッセージの大きさに応じて、図１８に示したようにEACセルは少ないシンボルを占めることができる。
【０３６８】
EACセルは、PLS２の最後のセルの直後を追い、マッピングは最後のFSSの最後のセルインデックスまで下方向に続く。必要なEACセルの合計数が最後のFSSの残っているアクティブ(active)キャリアの数を超えると、EACマッピングは次のシンボルに進行し、FSSと完全に同一方式で続けられる。この場合、EACのマッピングがなされる次のシンボルは、ノーマルデータシンボルであり、これはFSSより多いアクティブ(active)キャリアを有する。
【０３６９】
EACマッピングが完了した後、存在する場合FICが次に伝達される。FICが伝送されないと(PLS２フィールドでシグナリングとして)、データパイプがEACの最後のセルの直後を追う。
【０３７０】
図１９は、本発明の一実施例に係るFICマッピングを示す。
【０３７１】
(a)はEACを伴わないFICセルのマッピングの例を示し、(b)はEACを伴うFICセルのマッピングの例を示す。
【０３７２】
FICは、高速サービス取得及びチャネルスキャンを可能とするために、階層間情報(cross-layer information)を伝達する専用チャネルである。該当情報は、主にデータパイプ間のチャネルバインディング(channel binding)情報及び各放送局のサービスを含む。高速スキャンのために、受信機はFICをデコーディングし、放送局ID、サービス数、BASE_DP_IDのような情報を取得することができる。高速サービス取得のために、FICだけでなくベースデータパイプもBASE_DP_IDを利用してデコーディングすることができる。ベースデータパイプが伝送するコンテンツを除いて、ベースデータパイプはノーマルデータパイプと正確に同一方式でエンコーディングされ、フレームにマッピングされる。従って、ベースデータパイプに対する追加説明が不必要である。FICデータが生成されて管理層で消費される。FICデータのコンテンツは、管理層仕様に説明されたとおりである。
【０３７３】
FICデータは選択的であり、FICの使用はPLS２のスタティックな部分でFIC_FLAGパラメータによってシグナリングされる。FICが使用されると、FIC_FLAGは１に設定され、FICに対するシグナリングフィールドはPLS２のスタティックな部分で定義される。該当フィールドでシグナリングされるのはFIC_VERSIONであり、FIC_LENGTH_BYTE FICはPLS２と同じ変調、コーディング、タイムインターリービングパラメータを用いる。FICは、PLS２_MOD及びPLS２_FECのような同じシグナリングパラメータを共有する。FICデータは存在する場合PLS２の後にマッピングされ、EACが存在する場合EACの直後にマッピングされる。ノーマルデータパイプ、補助ストリーム、またはダミーセルのいずれもFICの前に位置しない。FICセルをマッピングする方法はEACと完全に同一であり、これはまたPLSと同一である。
【０３７４】
PLS後のEACが存在しない場合、FICセルは(a)の例に示したように、PLS２の次のセルからセルインデックスの昇順にマッピングされる。FICデータサイズに応じて、(b)に示したように、FICセルは数個のシンボルに対してマッピングされる。
【０３７５】
FICセルはPLS２の最後のセルの直後を追い、マッピングは最後のFSSの最後のセルインデックスまで下方向に続く。必要なFICセルの合計数が最後のFSSの残っているアクティブ(active)キャリアの数を超えると、残りのFICセルのマッピングは次のシンボルに進行され、これはFSSと完全に同一方式で続けられる。この場合、FICがマッピングされる次のシンボルはノーマルデータシンボルであり、これはFSSより多いアクティブ(active)キャリアを有する。
【０３７６】
EASメッセージが現在のフレームで伝送されると、EACはFICより先にマッピングされ、(b)に示したようにEACの次のセルからFICセルは、セルインデックスの昇順にマッピングされる。
【０３７７】
FICマッピングが完了した後、１つ以上のデータパイプがマッピングされ、以後存在する場合補助ストリーム、ダミーセルが後を追う。
【０３７８】
図２０は、本発明の一実施例に係るDPのタイプを示す。
【０３７９】
(a)はtype１DPを示し、(b)はType２DPを示す。
【０３８０】
前のチャネル、すなわち、PLS、EAC、及びFICがマッピングされ、DPのセルがマッピングされる。DPはマッピング方法によって２つのタイプのうちの１つでカテゴリー化される。
【０３８１】
Type１DP：DPはTDMによってマッピングされる。
【０３８２】
Type２DP：DPはFDMによってマッピングされる。
【０３８３】
PLSの静的なパート内のDP_TYPEフィールドによってDPのタイプが指示される。図２０は、Type１DP及びType２DPのマッピング順序を示す。Type１DPはまずセルインデックスの昇順にマッピングされ、最後のセルインデックスに到達すれば、シンボルインデックスは１つ増加する。次のシンボルで、DPはp=０から始めてセルインデックスの昇順にマッピングが続けられる。１つのフレームで多数のDPが一緒にマッピングされ、Type１DPのそれぞれは、DPのTDMマルチプレックスに似て時間に応じてグルーピングされる。
【０３８４】
Type２DPはまずシンボルインデックスの昇順にマッピングされ、フレームの最後のOFDMシンボルに到達した後、セルインデックスは１つ増加し、シンボルインデックスは最初に利用可能なシンボルに戻り、シンボルインデックスを増加させる。１つのフレーム内で多数のDPをマッピングした後、Type２DPのそれぞれはDPのFMDマルチプレックスに似て周波数に応じてグルーピングされる。
【０３８５】
Type１DP及びType２DPは、１つの制限が必要となると、１つのフレームに共存することができる。Type１DPは常にType２DPに先行する。Type１及びType２を伝送するOFDMセルの総数は、DPの伝送のためのOFDMセルの総数を超過できない。
【０３８６】
【数２】
2018207499.tif 000031
【０３８７】
DDP１は、Type１DPによって占有されたOFDMセルの数である。DDP２はType２DPによって占有されたセルの数である。PLS、EAC、FICはすべてType１DPに応じて同じ方法でマッピングされるので、それらはすべて「Type１マッピングルール」に従う。従って、全体としては、Type１マッピングは常にType２マッピングに先行する。
【０３８８】
図２１は、本発明の一実施例に係るDPマッピングを示す。
【０３８９】
(a)はtype１DPマッピングのためのOFDMセルのアドレス指定を示し、(b)はType２DPのためのマッピングのためのOFDMセルのアドレス指定を示す。
【０３９０】
Type１DP(０、…、DDP１１)マッピングのためのOFDMセルのアドレス指定は、type１DPのアクティブデータセルのために定義される。アドレス指定スキームは、アクティブデータセルによって割り当てられたType１DPのそれぞれのためのTlsからセルの順序を定義する。また、これはPLS２の動的部分内のDPの位置をシグナルするために使用される。
【０３９１】
EAC及びFICなしに、アドレス０は最後のFSSのPLSを伝送する最後のセルに直ちに続くセルを参照する。もし、EACが伝送され、FICが対応するフレーム内にない場合、アドレス０はEACを伝送する最後のセルに直ちに続くセルを参照する。Type１DPのためのアドレス０は(a)に示されたように、２つの異なるケースを考慮して計算される。(a)の例では、PLS、EAC及びFICは全部伝送されると仮定される。EAC及びFICのうちの１つまたは両方ともが省略された場合に拡張が容易である。もしFICですべてのセルをマッピングした後FSS内に残っているセルがある場合、(a)の左側のように示すことができる。
【０３９２】
Type２DP(０、…、DDP２１)マッピングのためのOFDMセルのアドレス指定は、Type２DPのアクティブデータセルのために定義される。アドレス指定スキームは、アクティブデータセルによって割り当てられたType２DPのそれぞれのためのTlsからセルの順序を定義する。また、これはPLS２の動的部分内のDPの位置をシグナルするために使用される。
【０３９３】
(b)に示されたように３つの若干異なるケースが可能である。(b)の左側に示された最初のケースの場合、最後のFSS内のセルはType２マッピングに利用可能である。中間に示された二番目のケースの場合、FICは一般的なシンボルのセルに割り当てられるが、FICセルの数はCFSSより大きくない。(b)の右側に示された三番目のケースの場合、シンボルにマッピングされたFICセルの数がCFSSを超える点を除いて二番目のケースと同一である。
【０３９４】
PLS、EAC及びFICがType１の例のように同じ「type１マッピングルール」に従うので、type１DP がType２DPに先行するケースへの拡張が容易である。
【０３９５】
データパイプユニット（DPU）は、フレーム内のDPにセルを割り当てるための基本単位です。
【０３９６】
DPUは、フレーム内DPを割り当てるためのシグナリングユニットと一緒に定義される。セルマッパ７０１０は、DPのそれぞれのためのTIsによって生成されたセルをマッピングすることができる。タイムインターリーバ５０５０は、TI-ブロックのシリーズ及びセルのセットから構成されるXFECBLOCKの可変数を含むTI-ブロックそれぞれを出力する。XFECBLOCK内のセルの数NcellsはFECBLOCKの大きさ、Nldpc、及びコンステレーションシンボル当たり伝送されたビットの数に従属する。DPUは、PHYプロファイルにサポートされるXFECBLOCK内のセル数のすべての可能な値の最大公約数として定義される。セル内のDPUの長さはLDPUで定義される。PHYプロファイルのそれぞれは、FECBLOCK大きさの異なる組み合わせ及びコンステレーションシンボル当たりの異なるビット数をサポートするので、LDPU はPHYプロファイルに基づいて定義される。
【０３９７】
図２２は、本発明の一実施例に係るFEC構造を示す。
【０３９８】
図２２は、ビットインターリービング前の本発明の一実施例に係るFEC構造を示す。上述したように、データFECエンコーダは、外部コーディング(BCH)及び内部コーディング(LDPC)を利用してFECBLOCK手順を生成するために、入力BBFにFECエンコーディングを実行することができる。図示されたFEC構造はFECBLOCKに該当する。また、FECBLOCK及びFEC構造はLDPCコードワードの長さに該当する同一値を有する。
【０３９９】
図２２に示されたように、BCHエンコーディングがそれぞれのBBF(Kbchビット)に適用された後、LDPCエンコーディングがBCH-エンコーディングされたBBF(Kldpcビット=Nbchビット)に適用される。
【０４００】
Nldpcの値は、６４８００ビット(long FECBLOCK)または１６２００ビット(short FECBLOCK)である。
【０４０１】
以下の表２８及び表２９は、long FECBLOCK及びshort FECBLOCKのそれぞれに対するFECエンコーディングパラメータを示す。
【０４０２】
【表２８】
2018207499.tif 000032
【０４０３】
【表２９】
2018207499.tif 000033
【０４０４】
BCHエンコーディング及びLDPCエンコーディングの具体的な動作は次のようである。
【０４０５】
１２-エラー訂正BCHコードがBBFの外部エンコーディングに使用される。short FECBLOCK及びlong FECBLOCKに対するBBF生成多項式は、すべての多項式を乗算することで得られる。
【０４０６】
LDPCコードは、外部BCHエンコーディングの出力をエンコーディングするために使用される。完成されたBldpc(FECBLOCK)を生成するために、Pldpc(パリティビット)がそれぞれのIldpc(BCH-エンコーディングされたBBF)から組織的にエンコーディングされ、Ildpcに添付される。完成されたBldpc(FECBLOCK)は次の数式で表現される。
【０４０７】
【数３】
2018207499.tif 000034
【０４０８】
long FECBLOCK及びshort FECBLOCKに対するパラメータは、上記表２８及び２９にそれぞれ与えられる。
【０４０９】
long FECBLOCKに対してNldpc-Kldpcパリティビットを計算する具体的な手順は次のようである。
【０４１０】
１）パリティビット初期化
【０４１１】
【数４】
2018207499.tif 000035
【０４１２】
２）パリティチェックマトリックスのアドレスの最初の行で特定されたパリティビットアドレスで最初の情報ビットi０の累算(accumulate)。パリティチェックマトリックスのアドレスの詳細な内容は後述する。例えば、比率１３/１５に対して、
【０４１３】
【数５】
2018207499.tif 000036
【０４１４】
３）次の３５９個の情報ビットis、s=１、２、…、３５９に対して、次の数式を利用してパリティビットアドレスでisを累算(accumulate)。
【０４１５】
【数６】
2018207499.tif 000037
【０４１６】
ここで、xは最初のビットi０に該当するパリティビット累算器のアドレスを示し、Qldpcはパリティチェックマトリックスのアドレスで特定されたコードレート(code rate)依存定数である。前記例である比率１３/１５に対する、従って情報ビットi１に対するQldpc=２４に引き続き、次の動作が実行される。
【０４１７】
【数７】
2018207499.tif 000038
【０４１８】
４）３６１番目情報ビットi３６０に対して、パリティビット累算器のアドレスは、パリティチェックマトリックスのアドレスの二番目行に与えられる。同一方式で、次の３５９個の情報ビットis、s=３６１、３６２、…、７１９に対するパリティビット累算器のアドレスは、数式６を利用して得られる。ここで、xは情報ビットi３６０に該当するパリティビット累算器のアドレス、すなわちパリティチェックマトリックスの二行目のエントリーを示す。
【０４１９】
５）同一方式で、３６０個の新しい情報ビットのすべてのグループに対して、パリティチェックマトリックスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めることに使用される。
【０４２０】
すべての情報ビットが利用された後、最終パリティビットが次のように得られる。
【０４２１】
６）i=１で始まり次の動作を順次実行
【０４２２】
【数８】
2018207499.tif 000039
【０４２３】
ここで、pi、i=０、１、...Nldpc-Kldpc-１の最終コンテンツは、パリティビットpiと同一である。
【０４２４】
【表３０】
2018207499.tif 000040
【０４２５】
表３０を表３１に代替し、long FECBLOCKに対するパリティチェックマトリックスのアドレスをshort FECBLOCKに対するパリティチェックマトリックスのアドレスに代替することを除いて、short FECBLOCKに対する該当LDPCエンコーディング手順は、long FECBLOCKに対するt LDPCエンコーディング手順に従う。
【０４２６】
【表３１】
2018207499.tif 000041
【０４２７】
図２３は、本発明の一実施例に係るビットインターリービングを示す。
【０４２８】
LDPCエンコーダの出力はビット-インターリーブされ、グループ内インターリービング及びQCB(Quasi-Cyclic Block)によるパリティインターリービングから構成される。
【０４２９】
(a)はQCBインターリービングを示し、(b)はグループ内インターリービングを示す。
【０４３０】
【数９】
2018207499.tif 000042
【０４３１】
【数１０】
2018207499.tif 000043
【０４３２】
【表３２】
2018207499.tif 000044
【０４３３】
グループ内インターリービングプロセスは、QCBインターリービング出力のQCブロックNQCB_IGと一緒に実行される。グループ内インターリービングは、３６０列及びNQCB_IG行を使用したグループ内のビットを読み出しまたは書き込みするプロセスを有する。書き込み動作で、QCBインターリービング出力からビットは行方向に書き込まれる。読み出し動作が実行されると、それぞれの行からmビットを列方向に読み出すことが実行される。MはNUCの１及びNUQの２と同一である。
【０４３４】
図２４は、本発明の一実施例に係るセルワードデマルチプレックスを示す。
【０４３５】
(a)は８及び１２bpcu MIMOに対するセルワードデマルチプレックスを示し、(b)は１０bpcu MIMOのためのセルワードデマルチプレックスを示す。
【０４３６】
それぞれのビットインターリービング出力のそれぞれのセルワード(c０、l、c１、l、…、cnmod-１、l)は、１つのXFECBLOCKのためのセルワードデマルチプレックス処理を説明した(a)に示されたように、(d１、０、m、d１、１、m…、d１、Nmod-１、m)及び(d２、０、m、d２、１、m…、d２、Nmod-１、m)でデマルチプレックスされる。
【０４３７】
MIMOエンコーディングのためのNUQの他のタイプを利用する１０bpcu MIMOケースのために、NUQ-１０２４のためのビットインターリーバが再使用される。ビットインターリーバ出力のそれぞれのセルワード(c０、l、c１、l、…、c９、l)は、(b)に示されたように(d１、０、m、d１、１、m…、d１、３、m)及び(d２、０、m、d２、１、m…、d２、５、m)でデマルチプレックスされる。
【０４３８】
図２５は、本発明の一実施例に係るタイムインターリービングを示す。
【０４３９】
(a)〜(c)は、タイムインターリービングモードの例を示す。
【０４４０】
タイムインターリーバは、データパイプレベルで動作する。タイムインターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定することができる。
【０４４１】
PLS２-STATデータの一部に現れる次のパラメータは、タイムインターリービングを構成する。
【０４４２】
DP_TI_TYPE(許容値：０または１)：タイムインターリービングモードを示す。０はタイムインターリービンググループ当たり多数のタイムインターリービングブロック(１つ以上のタイムインターリービングブロック)を有するモードを示す。この場合、１つのタイムインターリービンググループは、１つのフレームに(フレーム間インターリービングなしに)直接マッピングされる。１はタイムインターリービンググループ当たり１つのタイムインターリービングブロックのみを有するモードを示す。この場合、タイムインターリービングブロックは、１つ以上のフレームにかけて拡散される(フレーム間インターリービング)。
【０４４３】
DP_TI_LENGTH：DP_TI_TYPE=「０」である場合、該当パラメータはタイムインターリービンググループ当たりタイムインターリービングブロックの数NTIである。DP_TI_TYPE=「１」である場合、該当パラメータは１つのタイムインターリービンググループから拡散されるフレームの数PIである。
【０４４４】
DP_NUM_BLOCK_MAX(許容値：０〜１０２３)：タイムインターリービンググループ当たりXFECBLOCKの最大数を示す。
【０４４５】
DP_FRAME_INTERVAL(許容値：１、２、４、８)：与えられたフィジカルプロファイルの同じデータパイプを伝達する２つの順次的なフレームの間のフレームの数IJUMPを示す。
【０４４６】
DP_TI_BYPASS(許容値：０または１)：タイムインターリービングがデータフレームに利用されないと、該当パラメータは１に設定される。タイムインターリービングが利用されると、０に設定される。
【０４４７】
さらに、PLS２-DYNデータからのパラメータDP_NUM_BLOCKは、データグループの１つのタイムインターリービンググループによって伝達されるXFECBLOCKの数を示す。
【０４４８】
タイムインターリービングがデータフレームに利用されないと、次のタイムインターリービンググループ、タイムインターリービング動作、タイムインターリービングモードは考慮されない。しかし、スケジューラーからのダイナミック構成情報のための遅延補償ブロックは相変らず必要である。それぞれのデータパイプで、SSD/MIMOエンコーディングから受信したXFECBLOCKは、タイムインターリービンググループでグルーピングされる。すなわち、それぞれのタイムインターリービンググループは、整数個のXFECBLOCKの集合であり、ダイナミックに変化する数のXFECBLOCKを含むことができる。インデックスnのタイムインターリービンググループにあるXFECBLOCKの数は、NxBLOCK_Group(n)で示され、PLS２-DYNデータでDP_NUM_BLOCKとしてシグナリングされる。このとき、NxBLOCK_Group(n)は、最小値０から最大値が１０２３である最大値NxBLOCK_Group_MAX(DP_NUM_BLOCK_MAXに該当)まで変化することができる。
【０４４９】
それぞれのタイムインターリービンググループは、１つのフレームに直接マッピングまたはPI個のフレームにかけて拡散される。また、それぞれのタイムインターリービンググループは、１つ以上(NTI個)のタイムインターリービングブロックに分離する。ここで、それぞれのタイムインターリービングブロックは、タイムインターリーバメモリの１つの使用に該当する。タイムインターリービンググループ内のタイムインターリービングブロックは、若干異なる数のXFECBLOCKを含むことができる。タイムインターリービンググループが多数のタイムインターリービングブロックに分離されると、タイムインターリービンググループは、１つのフレームのみに直接マッピングされる。以下の表３２に示したように、タイムインターリービングには３種類のオプションがある(タイムインターリービングを省略する追加オプション除外)。
【０４５０】
【表３３】
2018207499.tif 000045
【０４５１】
各DPでは、TIメモリは、（SSD/ MIMO符号化ブロックから出力XFECBLOCKs）入力XFECBLOCKsを格納します。入力XFECBLOCKsは次のように定義されているものとします。
【０４５２】
【数１１】
2018207499.tif 000046
【０４５３】
dn,s,r,qは、n番目のTIグループのs番目のTIブロック内r番目XFECBLOCKのq番目のセルであり、SSDの出力とMIMOエンコーディングは、次のように表現される。
【０４５４】
【数１２】
2018207499.tif 000047
【０４５５】
また、時間インターリーバからXFCEブロックとして定義される出力を仮定。
【０４５６】
【数１３】
2018207499.tif 000048
【０４５７】
【数１４】
2018207499.tif 000049
【０４５８】
一般的に、タイムインターリーバは、フレーム生成過程以前にデータパイプデータに対するバッファとしても作用する。これは、それぞれのデータパイプに対して２つのメモリバンクで達成される。最初のタイムインターリービングブロックは最初のバンクに記入される。最初のバンクから読み取られる間、二番目のタイムインターリービングブロックが二番目バンクに記入される。
【０４５９】
【数１５】
2018207499.tif 000050
【０４６０】
図２６は、本発明の一実施例に係るツイスト行列ブロックインターリーバの基本動作を示す。
【０４６１】
【数１６】
2018207499.tif 000051
【０４６２】
【数１７】
2018207499.tif 000052
【０４６３】
【数１８】
2018207499.tif 000053
【０４６４】
【数１９】
2018207499.tif 000054
【０４６５】
結果的に、読み取られるセルの位置は座標
【数２０】
2018207499.tif 000055
によって計算される。
【０４６６】
図２７は、本発明の他の一実施例に係るツイスト行列ブロックインターリーバの動作を示す。
【０４６７】
さらに具体的に、図２７は、
【数２１】
2018207499.tif 000056
であるとき、仮想XFECBLOCKを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリにおいてインターリービングアレイを示す。
【０４６８】
【数２２】
2018207499.tif 000057
【０４６９】
【数２３】
2018207499.tif 000058
【０４７０】
タイムインターリービンググループの数は３に設定される。タイムインターリーバのオプションは、DP_TI_TYPE=「０」、DP_FRAME_INTERVAL=「１」、DP_TI_LENGTH=「１」、すなわちNTI=１、IJUMP=１、PI=１によってPLS２-STATデータでシグナリングされる。それぞれNcells=３０であるXFECBLOCKのタイムインターリービンググループ当たりの数は、それぞれのNxBLOCK_TI(０、０)=３、NxBLOCK_TI(１、０)=６、NxBLOCK_TI(２、０)=５によってPLS２-DYNデータでシグナリングされる。XFECBLOCKの最大数はNxBLOCK_Group_MAXによってPLS２-STATデータでシグナリングされて、これは
【数２４】
2018207499.tif 000059
によってなされる。
【０４７１】
図２８は、本発明の一実施例に係るツイスト行列ブロックインターリーバの対角線方向の読み取りパターンを示す。
【０４７２】
【数２５】
2018207499.tif 000060
【０４７３】
図２９は、本発明の一実施例に係るそれぞれのインターリービングアレイからのインターリービングされたXFECBLOCKを示す。
【０４７４】
図２９は、パラメータ
【数２６】
2018207499.tif 000061
及びSshift=３を有するそれぞれのインターリービングアレイからインターリービングされたXFECBLOCKを示す。
【０４７５】
これは、様々な修正および変更が本発明の精神または範囲から逸脱することなく本発明においてなされ得ることが当業者によって理解されるであろう。したがって、本発明は、修正をカバーし、本発明の変形例は、それらが添付の特許請求の範囲およびその均等物の範囲内に設けられていることを意図しています。
【０４７６】
装置および方法の両方の発明は、本明細書に記載され、装置および方法の両方の発明の説明は、互いに相補的に適用可能であってもよいです。
【０４７７】
図３０は、本発明の一実施例による放送サービスをサポートするためのプロトコルスタックを示す図である。
【０４７８】
本発明の一実施例による放送サービスは視聴覚データ（Ａｕｄｉｏ／Ｖｉｄｅｏ、Ａ／Ｖ）だけでなくＨＴＭＬ５アプリケーション、双方向サービス、ＡＣＲサービス、セカンドスクリーン（ｓｅｃｏｎｄ  ｓｃｒｅｅｎ）サービス、個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）サービスなどの付加サービスを提供する。
【０４７９】
このような放送サービスは地上波、ケーブル衛星などの放送信号である物理層を介して伝送される。また、本発明の一実施例による放送サービスはインターネット通信網（ｂｒｏａｄｂａｎｄ）を介して伝送される。
【０４８０】
放送サービスが地上波、ケーブル衛星などの放送信号である物理層を介して伝送される場合、放送受信装置はエンカプセレーション（ｅｎｃａｐｓｕｌａｔｉｏｎ）されたＭＰＥＧ−２伝送ストリーム（Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ、ＴＳ）とエンカプセレーションされたＩＰデータグラムを放送信号をデモジュレーションして抽出する。放送受信装置はＩＰデータグラムからユーザデータグラムプロトコル（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ、ＵＤＰ）データグラムを抽出する。放送受信装置はＵＤＰデータグラムからシグナリング情報を抽出する。この際、シグナリング情報はＸＭＬ形態である。また、放送受信装置はＵＤＰデータグラムから非同期階層コーディング／階層コーディング伝送（Ａｓｙｎｃｈｏｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ／Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ、ＡＬＣ／ＬＣＴ）パケットを抽出する。放送受信装置はＡＬＣ／ＬＣＴパケットから単方向ファイル伝送（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ、ＦＬＵＴＥ）パケットを抽出する。この際、ＦＬＵＴＥパケットはリアルタイムオーディオ／ビデオ／字幕データ、非リアルタイム（Ｎｏｎ−Ｒｅａｌ  Ｔｉｍｅ，  ＮＲＴ）データと電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ、ＥＳＧ）データを含む。また、放送受信装置はＵＤＰデータグラムからリアルタイム伝送プロトコル（例えば、Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ、ＲＴＣＰ）パケット及びＲＴＰ制御プロトコル（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ、ＲＴＣＰ）パケットを抽出する。放送受信装置はＲＴＰ／ＲＴＣＰパケットのようなリアルタイム伝送パケットからＡ／Ｖデータ及び付加データを抽出する。この際、ＮＲＴデータ、Ａ／Ｖデータ及び付加データのうち少なくともいずれか一つはＩＳＯベースメディアファイルフォーマット（ＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔ、ＩＳＯ  ＢＭＦＦ）の形態である。また、放送受信装置はＭＰＥＧ−２  ＴＳパケットまたはＩＰパケットからＮＲＴデータ、Ａ／Ｖデータ、ＰＳＩ／ＰＳＩＰのようなシグナリング情報を抽出する。この際、シグナリング情報はＸＭＬまたはバイナリの形態である。
【０４８１】
放送サービスがインターネット通信網を介して伝送される場合、放送受信装置はインターネット通信網からＩＰパケットを受信する。放送受信装置はＴＣＰパケットからＨＴＴＰパケットを抽出する。放送受信装置はＨＴＴＰパケットからＡ／Ｖ、付加データ、シグナリング情報などを抽出する。この際、Ａ／Ｖ及び付加データのうち少なくとも少なくともいずれか一つはＩＳＯ  ＢＭＦＦの形態である。また、シグナリング情報はＸＭＬ形態である。
【０４８２】
具体的な放送サービスを伝送する伝送フレームと伝送パケットについては、図３１乃至図３４を参照して説明する。
【０４８３】
図３１は、本発明の一実施例による放送伝送フレームを示す図である。
【０４８４】
図３１の実施例において、放送伝送フレームはＰ１パート、Ｌ１パート、共通ＰＬＰ（Ｃｏｍｍｏｎ  ＰＬＰ）パート、インターリーブされたＰＬＰ（Ｓｃｈｅｄｕｌｅｄ＆Ｉｎｔｅｒｌｅａｖｅｄ  ＰＳＰ’ｓ）パート及び補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）パートを含む。
【０４８５】
図３１の実施例において、放送伝送装置は放送伝送フレーム（ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）のＰ１パートを介して伝送シグナル探知（ｔｒａｎｓｐｏｒｔ  ｓｉｇｎａｌ  ｄｅｔｅｃｔｉｏｎ）のための情報を伝送する。また、放送伝送装置はＰ１パートを介して放送信号チューニングのためのチューニング情報を伝送する。
【０４８６】
図３１の実施例において、放送伝送装置はＬ１パートを介して放送伝送フレームの構成及びそれぞれのＰＬＰの特性を伝送する。この際、放送受信装置１００はＰ１に基づいてＬ１パートをデコーディングして放送伝送フレームの構成及びそれぞれのＰＬＰの特性を取得する。
【０４８７】
図３１の実施例において、放送伝送装置はＣｏｍｍｏｎ  ＰＬＰパートを介してＰＬＰ間に共通に適用される情報を伝送する。具体的な実施例において、放送伝送フレームはＣｏｍｍｏｎ  ＰＬＰパートを含まなくてもよい。
【０４８８】
図３１の実施例において、放送伝送装置は放送サービスに含まれた複数のコンポーネントをインターリーブされたＰＬＰパートを介して伝送する。この際、インターリーブされたＰＬＰパートは複数のＰＬＰを含む。
【０４８９】
図３１の実施例において、放送伝送装置はそれぞれの放送サービスを構成するコンポーネントがそれぞれどのＰＬＰに伝送されるのかをＬ１パートまたはＣｏｍｍｏｎ  ＰＬＰパートを介してシグナリングする。但し、放送受信装置１００が放送サービススキャンのために具体的な放送サービス情報を取得するためにはインターリーブされたＰＬＰパートの複数のＰＬＰを全てデコーディングすべきである。
【０４９０】
図３１の実施例とは異なって、放送伝送装置は放送伝送フレームを介して伝送される放送サービスと放送サービスに含まれたコンポーネントに関する情報を含む別途のパートを含む放送伝送フレームを伝送する。この際、放送受信装置１００は別途のパートを介して迅速に放送サービスと放送サービスに含まれたコンポーネントに関する情報を取得する。これについては図３２を参照して説明する。
【０４９１】
図３２は、本発明の他の実施例による放送伝送フレームを示す図である。
【０４９２】
図３２の実施例において、放送伝送フレームはＰ１パート、Ｌ１パート、高速情報チャネル（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ、ＦＩＣ）パート、インターリーブされたＰＬＰパート及び補助データパートを含む。
【０４９３】
ＦＩＣパートを除く他のパートは図３１の実施例と同じである。
【０４９４】
放送伝送装置はＦＩＣパートを介して高速情報を伝送する。高速情報は伝送フレームを介して伝送される放送ストリームの構成情報（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）、簡略な放送サービス情報及び該当サービス／コンポーネントに関するサービスシグナリングを含む。放送受信装置１００はＦＩＣパートに基づいて放送サービスをスキャンする。詳しくは、放送受信装置１００はＦＩＣパートから放送サービスに関する情報を抽出する。
【０４９５】
図３３は、本発明の一実施例による放送サービスを伝送する伝送パケットの構造を示す図である。
【０４９６】
図３３の実施例において、放送サービスを伝送する伝送パケットはＮｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールド、Ｅｒｒｏｒ  Ｉｎｄｉｃａｔｏｒフィールド、Ｓｔｕｆｆｉｎｇ  Ｉｎｄｉｃａｔｏｒフィールド、Ｐｏｉｎｔｅｒ  ｆｉｅｌｄフィールド、Ｓｔｕｆｆｉｎｇ  ｂｙｔｅｓフィールド及びペイロードデータを含む。
【０４９７】
Ｎｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールドはネットワークプロトコルがどのタイプであるのかを示す。具体的な実施例において、Ｎｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールドの値はＩＰｖ４プロトコルであるのかまたはフレームドパケットタイプであるのかを示す。詳しくは、図３４の実施例のようにＮｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールドの値が０００であればＩＰｖ４プロトコルを示す。また、詳しくは、図３４の実施例のようにＮｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールドの値が１１１であればｆｒａｍｅｄ＿ｐａｃｋｅｔ＿ｔｙｐｅプロトコルを示す。この際、ｆｒａｍｅｄ＿ｐａｃｋｅｔ＿ｔｙｐｅはＡ／１５３によって定義されたプロトコルである。詳しくは、ｆｒａｍｅｄ＿ｐａｃｋｅｔ＿ｔｙｐｅは長さに関する情報を示すフィールドを含まないネットワークパケットプロトコルを示す。具体的な実施例において、Ｎｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌフィールドは３ビットフィールドである。
【０４９８】
Ｅｒｒｏｒ  Ｉｎｄｉｃａｔｏｒフィールドは該当伝送パケットにエラーが検出されたのかを示す。詳しくは、Ｅｒｒｏｒ  Ｉｎｄｉｃａｔｏｒフィールドの値が０であれば該当パケットからエラーが検出されないことを示し、Ｅｒｒｏｒ  Ｉｎｄｉｃａｔｏｒフィールドの値が１であれば該当パケットからエラーが検出されたことを示す。具体的な実施例において、Ｅｒｒｏｒ  Ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【０４９９】
Ｓｔｕｆｆｉｎｇ  Ｉｎｄｉｃａｔｏｒフィールドは該当伝送パケットにスタッフィングバイト（ｓｔｕｆｆｉｎｇ  ｂｙｔｅｓ）が含まれているのかを示す。この際、スタッフィングバイトは固定されたパケットの長さを維持するためにペイロードに含まれるデータを示す。具体的な実施例において、Ｓｔｕｆｆｉｎｇ  Ｉｎｄｉｃａｔｏｒフィールドの値が１であれば伝送パケットがスタッフィングバイトを含み、Ｓｔｕｆｆｉｎｇ  Ｉｎｄｉｃａｔｏｒフィールドの値が０であれば伝送パケットがスタッフィングバイトを含まないことを示す。具体的な実施例において、Ｓｔｕｆｆｉｎｇ  Ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【０５００】
Ｐｏｉｎｔｅｒ  ｆｉｅｌｄフィールドは該当伝送パケットのペイロード部分で新たなネットワークパケットの開始地点を示す。具体的な実施例において、Ｐｏｉｎｔｅｒ  ｆｉｅｌｄフィールドの値が０ｘ７ＦＦであれば新たなネットワークパケットの開始地点がないことを示す。また、具体的な実施例において、Ｐｏｉｎｔｅｒ  ｆｉｅｌｄフィールドの値が０ｘ７ＦＦではなければ伝送パケットヘッダの最後の部分から新たなネットワークパケットの開始地点までのオフセット（ｏｆｆｓｅｔ）値を示す。具体的な実施例において、Ｐｏｉｎｔｅｒ  ｆｉｅｌｄフィールドは１１ビットフィールドである。
【０５０１】
Ｓｔｕｆｆｉｎｇ＿Ｂｙｔｅｓフィールドは、固定されたパケット長さを維持するためにヘッダとペイロードデータの間を詰めるスタッフィングバイトを示す。
【０５０２】
このような放送サービスを受信するための放送受信装置の構成については、図３４を参照して説明する。
【０５０３】
図３５は、本発明の一実施例による放送受信装置の構成を示す図である。
【０５０４】
図３５の実施例において、放送受信装置１００は放送受信部１１０、インターネットプロトコル通信部１３０及び制御部１５０を含む。
【０５０５】
放送受信部１１０はチャネル同期化部（ｃｈａｎｎｅｌ  ｓｙｎｃｈｒｏｎｉｚｅｒ）１１１、チャネルイコライザ（ｃｈａｎｎｅｌ  ｅｑｕａｌｉｚｅｒ）１１３及びチャネルデコーダ（ｃｈａｎｎｅｌ  ｄｅｃｏｄｅｒ）１１５を含む。
【０５０６】
チャネル同期化部１１１は、放送信号を受信する基底帯域（ｂａｓｅｂａｎｄ）でデコーディングが可能になるようにシンボル周波数とタイミングを同期化する。
【０５０７】
チャネルイコライザ１１３は同期化された放送信号の歪みを補償する。詳しくは、チャネルイコライザ１１３はマルチパス（ｍｕｌｔｉｐａｔｈ）、ドップラー効果などによる同期化された信号の歪みを補償する。
【０５０８】
チャネルデコーダ１１５は歪みが補償された信号をデコーディングする。詳しくは、チャネルデコーダ１１５は歪みが補償された放送信号から伝送フレームを抽出する。この際、チャネルデコーダ１１５は前方誤り訂正（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ、ＦＥＣ）を行う。
【０５０９】
ＩＰ通信部１３０はインターネット網を介してデータを受信し伝送する。
【０５１０】
制御部１５０はシグナリングでデコーダ１５１、伝送パケットインタフェース１５３、広帯域パケットインタフェース１５５、基底帯域動作制御部１５７、共通プロトコルスタック（Ｃｏｍｍｏｎ  Ｐｒｏｔｏｃｏｌ  Ｓｔａｃｋ）１５９、サービスマップデータベース１６１、サービスシグナリングチャネルプロセッシングバッファ（ｂｕｆｆｅｒ）及びパーサー（ｐａｒｓｅｒ）１６３、Ａ／Ｖプロセッサ１６５、放送サービスガイドプロセッサ１６７、アプリケーションプロセッサ１６９及びサービスガイドデータベース１７１を含む。
【０５１１】
シグナリングデコーダ１５１は放送信号のシグナリング情報をデコーディングする。
【０５１２】
伝送パケットインタフェース１５３は放送信号から伝送パケットを抽出する。この際、伝送パケットインタフェース１５３は抽出した伝送パケットからシグナリング情報またはＩＰデータグラムなどのデータを抽出する。
【０５１３】
広帯域パケットインタフェース１５５はインターネット網から受信したデータからＩＰパケットを抽出する。この際、広帯域パケットインタフェース１５５はＩＰパケットからシグナリングデータまたはＩＰデータグラムを抽出する。
【０５１４】
基底帯域動作制御部１５７は、基底帯域から放送情報受信情報を受信することに関する動作を制御する。
【０５１５】
共通プロトコルスタック１５９は、伝送パケットからオーディオまたはビデオを抽出する。
【０５１６】
Ａ／Ｖプロセッサ１５９は、オーディオまたはビデオ処理する。
【０５１７】
サービスシグナリングチャネルプロセッシングバッファ及びパーサ１６３は放送サービスをシグナリングするシグナリング情報をパーシングしバッファリングする。詳しくは、シグナリングチャネルプロセッシングバッファ及びパーサ１６３はＩＰデータグラムから放送サービスをシグナリングするシグナリング情報をパーシングしバッファリングする。
【０５１８】
サービスマップデータベース１６５は放送サービスに関する情報を含む放送サービスリストを貯蔵する。
【０５１９】
サービスガイドプロセッサ１６７は、地上波放送サービスのプログラムを案内する地上波放送サービスガイドデータを処理する。
【０５２０】
アプリケーションプロセッサ１６９は、放送信号からアプリケーション関連情報を抽出し処理する。
【０５２１】
サービスガイドデータベース１７１は、放送サービスのプログラム情報を貯蔵する。
【０５２２】
図３６は、本発明の他の実施例による放送受信装置の構成を示す図である。
【０５２３】
図３６は、本発明の他の実施例による放送受信装置の構成を示す図である。
【０５２４】
図３６の実施例において、放送受信装置１００は放送受信部１１０、インターネットプロトコル通信部１３０及び制御部１５０を含む。
【０５２５】
放送受信部１１０は、放送受信部が行う複数の機能それぞれを行う一つまたは複数のプロセッサ、一つまたは複数の回路及び一つまたは複数のハードウェアモジュールを含む。詳しくは、放送受信部１１０は様々な半導体部品が一つに集積されるシステム・オン・チップ（Ｓｙｓｔｅｍ  Ｏｎ  Ｃｈｉｐ、ＳＯＣ）である。この際、ＳＯＣはグラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとＤＲＡＭなど半導体が一つに統合された半導体であってもよい。放送受信部１１０は物理層モジュール１１９、物理層ＩＰフレームモジュール１１７を含む。物理層モジュール１１９は放送網の放送チャネルを介して放送関連信号を受信し処理する。物理層ＩＰフレームモジュール１１７は物理層モジュール１１９から取得したＩＰデータグラムなどのデータパケットを特定フレームに変換する。例えば、物理層モジュール１１９はＩＰデータグラムなどをＲＳ  ＦｒａｍｅまたはＧＳＥなどに変換する。
【０５２６】
ＩＰ通信部１３０は、ＩＰ通信部１３０が行う複数の機能それぞれを行う一つまたは複数のプロセッサ、一つまたは複数の回路及び一つまたは複数のハードウェアモジュールを含む。詳しくは、ＩＰ通信部１３０は様々な半導体部品が一つに集積されるシステム・オン・チップである。この際、ＳＯＣはグラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとＤＲＡＭなど半導体が一つに統合された半導体であってもよい。ＩＰ通信部１３０はインターネット通信網を介してサービス、コンテンツ及びシグナリングデータのうち少なくともいずれか一つを取得するための放送受信装置１００の動作を制御する。
【０５２７】
制御部１５０は、制御部１５０が行う複数の機能それぞれを行う一つまたは複数のプロセッサ、一つまたは複数の回路及び一つまたは複数のハードウェアモジュールを含む。詳しくは、制御部１５０は様々な半導体部品が一つに集積されるシステム・オン・チップである。この際、ＳＯＣはグラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとＤＲＡＭなど半導体が一つに統合された半導体であってもよい。制御部１５０はシグナリングデコーダ１５１、サービスマップデータベース１６１、サービスシグナリングチャネルパーサ１６３、アプリケーションシグナリングパーサ１６６、アラートシグナリングパーサ１６８、ターゲットシグナリングパーサ１７０、ターゲッティングプロセッサ１７３、Ａ／Ｖプロセッサ１６１、アラーティングプロセッサ１６２、アプリケーションプロセッサ１６９、スケジュールドストリーミングデコーダ１８１、ファイルデコーダ１８２、ユーザ要求ストリーミングデコーダ１８３、ファイルデータベース１８４、コンポーネント同期化部１８５、サービス／コンテンツ取得制御部１８７、再分配モジュール１８９、装置マネージャ１９３及びデータシェアリング部１９１のうち少なくともいずれか一つを含む。
【０５２８】
サービス／コンテンツ取得制御部１８７は、放送網またはインターネット通信網を介して取得したサービス、コンテンツ、サービスまたはコンテンツに関するシグナリングデータを取得するための受信器の動作を制御する。
【０５２９】
シグナリングデコーダ１５１は、シグナリング情報をデコーディングする。
【０５３０】
サービスシグナリングパーサ１６３は、サービスシグナリング情報をパーシングする。
【０５３１】
アプリケーションシグナリングパーサ１６６はサービスに関するシグナリング情報を抽出しパーシングする。この際、サービスに関するシグナリング情報はサービススキャンに関するシグナリング情報であってもよい。また、サービスに関するシグナリング情報はサービスを介して提供されるコンテンツに関するシグナリング情報であってもよい。
【０５３２】
アラートシグナリングパーサ１６８は、アラーティングに関するシグナリング情報を抽出しパーシングする。
【０５３３】
ターゲットシグナリングパーサ１７０は、サービスまたはコンテンツを個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）するための情報またはターゲッティング情報をシグナリングする情報を抽出しパーシングする。
【０５３４】
ターゲッティングプロセッサ１７３は、サービスまたはコンテンツを個人化するための情報を処理する。
【０５３５】
アラーティングプロセッサ１６２は、アラーティングに関するシグナリング情報を処理する。
【０５３６】
アプリケーションプロセッサ１６９はアプリケーション関連情報及びアプリケーションの実行を制御する。詳しくは、アプリケーションプロセッサ１６９はダウンロードされたアプリケーションの状態及び表示パラメータを処理する。
【０５３７】
Ａ／Ｖプロセッサ１６１は、デコーディングされたオーディオまたはビデオ、アプリケーションデータなどに基づいてオーディオ／ビデオのレンダリング関連動作を処理する。
【０５３８】
スケジュールドストリーミングデコーダ１８１は、予め放送局などのコンテンツ提供者が決めたスケジュール通りにストリーミングされるコンテンツであるスケジュールドストリーミングをデコーディングする。
【０５３９】
ファイルデコーダ１８２はダウンロードされたファイルをデコーディングする。特に、ファイルデコーダ１８２はインターネット通信網を介してダウンロードされたファイルをデコーディングする。
【０５４０】
ユーザ要求ストリーミングデコーダ１８３は、ユーザの要求によって提供されるコンテンツ（Ｏｎ  Ｄｅｍａｎｄ  Ｃｏｎｔｅｎｔ）をデコーディングする。
【０５４１】
ファイルデータベース１８４はファイルを貯蔵する。詳しくは、ファイルデータベース１８４はインターネット通信網を介してダウンロードしたファイルを貯蔵する。
【０５４２】
コンポーネント同期化部１８５はコンテンツまたはサービスを同期化する。詳しくは、コンポーネント同期化部１８５はスケジュールドストリーミングデコーダ１８１、ファイルデコーダ１８２及びユーザ要求ストリーミングデコーダ１８３のうち少なくともいずれか一つを介して取得したコンテンツの再生時間に関する同期化を行う。
【０５４３】
サービス／コンテンツ取得制御部１８７は、サービス、コンテンツ、サービスまたはコンテンツに関するシグナリング情報のうち少なくともいずれか一つを取得するための受信器の動作を制御する。
【０５４４】
再分配モジュール１８９は放送網を介してサービスまたはコンテンツを受信することができない場合、サービス、コンテンツ、サービス関連情報及びコンテンツ関連情報のうち少なくともいずれか一つの取得をサポートするための動作を行う。詳しくは、外部の装置マネージャ３００にサービス、コンテンツ、サービス関連情報及びコンテンツ関連情報のうち少なくとも一つを要求する。この際、外部の管理装置３００はコンテンツサーバである。
【０５４５】
装置マネージャ１９３は連動可能な外部装置を管理する。詳しくは、装置マネージャ１９３は外部装置の追加、削除及び更新のうち少なくともいずれか一つを行う。また、外部装置は放送受信装置１００との連結及びデータ交換が可能である。
【０５４６】
データシェアリング部１９１は放送受信装置１００と外部装置間のデータ伝送動作を行い、交換関連情報を処理する。詳しくは、データシェアリング部１９１は外部装置にＡ／Ｖデータまたはシグナリング情報を伝送する。また、データシェアリング部１９１は外部装置からＡ／Ｖデータまたはシグナリング情報を受信する。
【０５４７】
図３７は、本発明の一実施例による放送サービスシグナリングテーブルと放送サービス伝送経路シグナリング情報が放送サービスと放送サービス伝送経路をシグナリングすることを示す図である。
【０５４８】
放送サービスシグナリングテーブルは放送サービス情報をシグナリングする。詳しくは、放送サービスが含むメディアコンポーネントをシグナリングする。また、放送サービスシグナリングテーブルは放送サービスと放送サービスが含むメディアコンポーネントの伝送経路をシグナリングする。このため、放送サービスシグナリングテーブルは放送サービス伝送経路シグナリング情報を含む。図３７の実施例において、放送サービスシグナリングテーブルは複数の放送サービスに関する情報を含む。この際、放送サービスシグナリングテーブルは複数の放送サービスそれぞれに含まれた複数のメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報を含む。特に、放送サービスシグナリングテーブルは複数のメディアコンポーネントの伝送経路をシグナリングする放送サービス伝送経路シグナリング情報を含む。例えば、放送サービスシグナリングテーブルを介して放送受信装置１００はサービス（Ｓｅｒｖｉｃｅ）０に含まれるビデオ（Ｖｉｄｅｏ）０が物理層パイプ（ＰＬＰ）０を介して伝送されることが分かる。また、放送サービスシグナリングテーブルを介して放送受信装置１００はサービス（Ｓｅｒｖｉｃｅ）Ｎに含まれるオーディオ（Ａｕｄｉｏ）１がインターネット網を介して伝送されることが分かる。この際、物理層パイプ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ、ＰＬＰ）は物理層の上で識別可能な一連の論理的データ伝達経路である。ＰＬＰはデータパイプ（ｄａｔａ  ｐｉｐｅ）など他の用語で称されてもよい。
【０５４９】
図３８乃至図４３を介して、放送サービスシグナリングテーブルについて詳しく説明する。
【０５５０】
図３８は、本発明の一実施例による放送サービスシグナリングテーブルを示す図である。
【０５５１】
放送サービスシグナリングテーブルは放送サービスを識別する情報、放送サービスの現在状態を示す情報、放送サービスの名前、放送サービスのチャネルナンバー、放送サービスに対する保護アルゴリズムの適用可否を示す情報、放送サービスのカテゴリー情報及び放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報のうち少なくともいずれか一つを含む。放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報はそれぞれのメディアコンポーネントが該当放送サービスに必須であるのかを示す情報を含む。また、放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報はそれぞれのコンポーネントに関する情報を含む。
【０５５２】
詳しくは、図３８の実施例のように放送サービスシグナリングテーブルは、ｔａｂｌｅ＿ｉｄフィールド、ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールド、ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールド、ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールド、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールド、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｎｕｍ＿ｓｅｒｖｉｃｅフィールド、ｓｅｒｖｉｃｅ＿ｉｄフィールド、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールド、ＳＰ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールド、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールド、ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールド、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔｓフィールド、ｅｓｓｅｎｔｉａｌ＿ｃｏｍｐｏｎｅｎｔ＿ｉｎｄｉｃａｔｏｒフィールド、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールド、ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールド、ｎｕｍ＿ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド及びｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドのうち少なくともいずれか一つを含む。
【０５５３】
ｔａｂｌｅ＿ｉｄフィールドは放送サービスシグナリング情報テーブルの識別子を示す。この際、ｔａｂｌｅ＿ｉｄフィールドの値はＡＴＳＣ  Ａ／６５で定義されたｒｅｓｅｒｖｅｄ  ｉｄ値のうち一つである。具体的な実施例において、ｔａｂｌｅ＿ｉｄフィールドは８ビットである。
【０５５４】
ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは放送サービスシグナリング情報テーブルのＭＰＥＧ−２  ＴＳ標準のｌｏｎｇ形式のｐｒｉｖａｔｅ  ｓｅｃｔｉｏｎ  ｔａｂｌｅであるのか否かを示す。具体的な実施例において、ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【０５５５】
ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールドは現在のテーブルがｐｒｉｖａｔｅ  ｓｅｃｔｉｏｎに当たるのかを示す。具体的な実施例において、ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【０５５６】
ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドはｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドの後に含まれたｓｅｃｔｉｏｎの長さを示す。具体的な実施例において、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドは１２ビットである。
【０５５７】
ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドはｔａｂｌｅ＿ｉｄフィールドと結合して放送サービスシグナリング情報テーブルを識別する値を示す。特に、ｔａｂｌｅ＿ｉｄフィールドはサービスシグナリング情報テーブルのプロトコルバージョンを示すＳＭＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドを含む。具体的な実施例において、ＳＭＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは８ビットフィールドである。
【０５５８】
ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドはサービスシグナリングテーブルのバージョンを示す。放送受信装置１００はｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドの値に基づいてサービスシグナリング情報テーブルの情報利用可否を決定する。詳しくは、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドの値が以前に受信したサービスシグナリングテーブルのバージョンと同じであればサービスシグナリングテーブルの情報を利用しなくてもよい。具体的な実施例において、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは５ビットフィールドである。
【０５５９】
Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは放送サービスシグナリングテーブルの情報が現在使用可能であるのかを示す。詳しくは、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドの値が１であれば放送サービスシグナリングテーブルの情報が使用可能であることを示す。また、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドの値が１であれば放送サービスシグナリングテーブルの情報を次に使用可能であることを示す。具体的な実施例において、Ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【０５６０】
ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは現在のセクションの番号を示す。具体的な実施例において、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは８ビットフィールドである。
【０５６１】
ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドが最後のセクションの番号を示す。放送サービスシグナリングテーブルの大きさが大きければ複数のセクションに分けられて伝送される。この際、放送受信装置１００はｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドとｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドに基づいてサービスシグナリングテーブルに必要な全てのセクションの受信可否を判断する。具体的な実施例において、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは８ビットフィールドである。
【０５６２】
ｓｅｒｖｉｃｅ＿ｉｄフィールドは放送サービスを識別する識別子を示す。具体的な実施例において、ｓｅｒｖｉｃｅ＿ｉｄフィールドは１６ビットのフィールドである。
【０５６３】
ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは放送サービスの現在状態を示す。詳しくは、放送サービスが現在利用可能であるのかを示す。具体的な実施例において、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドの値が１であれば放送サービスが現在利用可能であることを示す。具体的な実施例において、放送受信装置１００はｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドの値に基づいて該当放送サービスを放送サービスリスト及び放送サービスガイドに表示するのかを決定する。例えば、放送受信装置１００は該当放送サービスが使用不可能であれば該当放送サービスを放送リストと放送サービスガイドに表示しなくてもよい。他の具体的な実施例において、放送受信装置１００はｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドの値に基づいて該当放送サービスに関するアクセスを制限する。例えば、該当放送サービスが使用不可能であれば放送受信装置１００は該当放送サービスに対するチャネルアップ／ダウンキーを介したアクセスを制限する。具体的な実施例において、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは２ビットフィールドである。
【０５６４】
ＳＰ＿ｉｎｄｉｃａｔｏｒフィールドは該当放送サービス内の一つ以上のコンポーネントにサービスプロテクション（ｐｒｏｔｅｃｔｉｏｎ）が適用されたのかを示す。例えば、ＳＰ＿ｉｎｄｉｃａｔｏｒフィールドの値が１であれば該当放送サービス内の一つ以上のコンポーネントでサービスプロテクションが適用されていることを示す。具体的な実施例において、ＳＰ＿ｉｎｄｉｃａｔｏｒフィールドは１ビットフィールドである。
【０５６５】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドはｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドの大きさを示す。
【０５６６】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは放送サービスの名前を示す。詳しくは、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは放送サービスの名前を要約して表示する。
【０５６７】
ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは放送サービスの仮想のチャネルナンバーを表示する。
【０５６８】
ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは放送サービスのカテゴリーを示す。詳しくは、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドはＴＶサービス、ラジオサービス、放送サービスガイド、ＲＩサービス及び緊急警告（Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔｉｎｇ）のうちいずれか一つを示す。例えば、図３９の実施例のようにｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドの値が０ｘ０１であればＴＶサービスを示し、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドの値が０ｘ０２であればラジオサービスを示し、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドの値が０ｘ０８であればサービスガイドを示し、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドの値が０ｘ０９であれば緊急情報を示す。具体的な実施例において、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは６ビットフィールドである。
【０５６９】
ｎｕｍ＿ｃｏｍｐｏｎｅｎｔｓフィールドは該当放送サービスが含むメディアコンポーネントの個数を示す。具体的な実施例において、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔｓフィールドは５ビットフィールドである。
【０５７０】
ｅｓｓｅｎｔｉａｌ＿ｃｏｍｐｏｎｅｎｔ＿ｉｎｄｉｃａｔｏｒフィールドは該当メディアコンポーネントが該当放送サービス再生（ｐｒｅｓｅｎｔａｔｉｏｎ）のために必要な必須メディアコンポーネントであるのかを示す。具体的な実施例において、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔｓフィールドは１ビットフィールドである。
【０５７１】
ｎｕｍ＿ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドはｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドの個数を示す。具体的な実施例において、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドは４ビットフィールドである。
【０５７２】
ｃｏｍｐｏｎｅｎｔ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドは該当コンポーネントに関する付加的な属性を含む。
【０５７３】
ｎｕｍ＿ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドはｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドの個数を示す。具体的な実施例において、ｎｕｍ＿ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドは４ビットフィールドである。
【０５７４】
ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒフィールドは該当サービスに関する付加的な属性を含む。
【０５７５】
サービスシグナリングテーブルはアンサンブルに関する情報を更に含む。アンサンブルは一つ以上のサービスが同じ前方誤り訂正が適用されて伝送されれば一つ以上のサービスの集合を示す。これについては図４９を参照してより詳しく説明する。
【０５７６】
図４０は、本発明の他の実施例による放送サービスシグナリングテーブルを示す。
【０５７７】
詳しくは、図４０の実施例のように放送サービスシグナリングテーブルはｎｕｍ＿ｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドとｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを更に含む。
【０５７８】
ｎｕｍ＿ｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドはｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドの個数を示す。具体的な実施例において、ｎｕｍ＿ｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドは４ビットフィールドである。
【０５７９】
ｅｎｓｅｍｂｌｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドは該当アンサンブルに関する付加的な属性を含む。
【０５８０】
また、サービスシグナリングテーブルはメディアコンポーネントを識別するためにメディアコンポーネントを識別するストリーム識別子情報を更に含む。これについては図４１を参照して詳しく説明する。
【０５８１】
図４１は、本発明の一実施例によるストリーム識別子ディスクリプタを示す図である。
【０５８２】
ストリーム識別子情報はｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド及びｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドのうちいずれか一つを含む。
【０５８３】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは該当ディスクリプタがストリーム識別子情報を含むディスクリプタであることを示す。具体的な実施例において、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは８ビットフィールドである。
【０５８４】
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは該当フィールドの後のストリーム識別子情報の長さを示す。具体的な実施例において、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは８ビットフィールドである。
【０５８５】
ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドはメディアコンポーネントを識別するメディアコンポーネント識別子を示す。この際、メディアコンポーネント識別子は該当シグナリング情報テーブルの上で他のメディアコンポーネントのメディアコンポーネント識別子とは異なる唯一（ｕｎｉｑｕｅ）の値を有する。本発明の具体的な実施例において、ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドは８ビットフィールドである。
【０５８６】
放送サービスシグナリングテーブルを伝送し受信する動作については図４２乃至図４６を参照して説明する。
【０５８７】
上の放送サービスシグナリングテーブルはビットストリーム形式で説明したが、具体的な実施例によって放送サービスシグナリングテーブルはＸＭＬ形式であってもよい。
【０５８８】
図４２は、本発明の一実施例による放送伝送装置が放送サービスシグナリングテーブルを伝送する動作を示す図である。
【０５８９】
本発明の一実施例による放送伝送装置は、放送信号を伝送する伝送部及び放送伝送装置の動作を制御する制御部を含む。伝送部は伝送部が行う複数の機能それぞれを行う一つまたは複数のプロセッサ、一つまたは複数の回路及び一つまたは複数のハードウェアモジュールを含む。詳しくは、放送受信部１１０は様々な半導体部品が一つに集積されるシステム・オン・チップである。この際、ＳＯＣはグラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとＤＲＡＭなど半導体が一つに統合された半導体であってもよい。制御部は制御部が行う複数の機能それぞれを行う一つまたは複数のプロセッサ、一つまたは複数の回路及び一つまたは複数のハードウェアモジュールを含む。詳しくは、放送受信部１１０は様々な半導体部品が一つに集積されるシステム・オン・チップである。この際、ＳＯＣはグラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとＤＲＡＭなど半導体が一つに統合された半導体であってもよい。
【０５９０】
放送伝送装置は制御部を介して伝送パケットに含ませて伝送するデータを取得するＳ１０１。放送伝送措置が伝送するデータはリアルタイムコンテンツまたはリアルタイムコンテンツに関するメタデータである。詳しくは、リアルタイムコンテンツは地上波放送網などを介して伝送される放送Ａ／Ｖコンテンツまたは放送Ａ／Ｖコンテンツに関する向上されたデータである。
【０５９１】
放送伝送装置は、制御部を介して取得したデータがデータ伝送のために使用する伝送パケットが含められる容量を超過するのか否かを判断するＳ１０３。詳しくは、放送伝送装置が使用する伝送パケットが固定されたパケット長さを使用するプロトコルをベースにする。この際、伝送しようとするデータがパケットがカバーし得る容量を超えれば円滑なデータの伝送が難しくなる恐れがある。また、伝送しようとするデータがパケットに比べて非常に小さければ、一つのパケットに小容量のデータ一つのみを伝送することは非効率なパケットの活用になりかねない。よって、上述した非効率性を克服するために放送伝送装置は制御部を介して伝送パケットとデータの大きさを比較する。
【０５９２】
もし、放送伝送装置が伝送するデータを伝送パケットが含められない容量と判断した場合、放送伝送装置は制御部を介して伝送するデータを分割（Ｓｅｇｍｅｎｔ）するＳ１０７。分割されたデータは複数のパケットに分けられて伝送される。そして、複数の伝送パケットは分割されたデータを識別するための情報を追加的に含む。他の実施例において、分割されたデータを識別するための情報は伝送パケットではなく別途のデータグラムを介して伝送されてもよい。
【０５９３】
放送伝送装置は制御部を介して分割されたデータまたは伝送パケットより小さい容量を有するデータをパケット化（ｐａｃｋｅｔｉｚｉｎｇ）するＳ１０９。詳しくは、放送伝送装置はデータを伝送可能な形態に加工する。加工された放送パケットはパケットヘッダ（Ｐａｃｋｅｔ  ｈｅａｄｅｒ）とパケットペイロード（Ｐａｃｋｅｔ  ｐａｙｌｏａｄ）を含む。また、パケットペイロードはデータとペイロードのヘッダを含む。ここで、ペイロードヘッダはパケットヘッダとは別にパケットペイロードに含まれたペイロードデータをシグナリングするためのフィールドである。また、分割されたデータを含むパケットペイロードはペイロードのヘッダと共に分割されたデータヘッダを含む。ここで、分割されたデータヘッダはペイロードとは別にパケットペイロードに含まれたペイロードデータをシグナリングするためのフィールドである。
【０５９４】
一実施例において、放送伝送装置は一つのデータを一つのパケットにパケット化する。他の実施例において、放送伝送装置は複数のデータを一つのパケットにパケット化する。また他の実施例において、放送伝送装置は一つのデータを複数のパケットに分割してパケット化する。
【０５９５】
上述したように、データの容量またはパケットの長さに応じてパケット化された伝送パケットが異なり得る。よって、放送伝送装置は互いに異なる伝送パケットを区別可能な形態に伝送する必要がある。一実施例において、放送伝送装置は制御部を介して伝送パケットのペイロードヘッダにパケットの形態を示す情報を含ませてデータをパケット化する。他の実施例において、放送伝送装置の制御部はペイロードヘッダに含まれた情報のみで伝送するデータを区別することが難しければ、伝送パケットの種類を識別する情報を追加的に含ませてデータをパケット化する。
【０５９６】
放送伝送装置は伝送部を介してパケット化された放送パケットを伝送するＳ１１１。一実施例において、放送パケットは地上波放送網を介して伝送される。他の実施例において、放送パケットの伝送はインターネット網を介して行われてもよい。
【０５９７】
図４３は、本発明の一実施例による放送受信装置がパケット化された放送パケットを受信する動作を示す図である。
【０５９８】
放送受信装置１００は、放送受信部１１０を介してパケット化された伝送パケットを受信するＳ２０１。
【０５９９】
放送受信装置１００は制御部１５０を介して受信された伝送パケットからペイロードヘッダを抽出するＳ２０３。制御部１５０は伝送パケットのペイロードからデータを含むペイロードデータとデータをシグナリングするペイロードヘッダを取得する。詳しくは、放送受信装置１００の制御部１５０はパケットペイロードに含まれた放送コンテンツ及び放送コンテンツに関する向上されたコンテンツのうち少なくとも一つを提供するための付加的な情報を受信した伝送パケットから抽出する。
【０６００】
一実施例において、放送受信装置１００の制御部１５０はペイロードヘッダからペイロードエラー判断情報、ペイロード優先順位情報及びペイロードタイプ情報のうち少なくとも一つを抽出する。詳しくは、ペイロードエラー判断情報は放送パケットに含まれたペイロードにエラーが存在するのか、または該当ペイロードが決められたシンタックス（ｓｙｎｔａｘ）に違反する内容を含んでいるのか否かを判断する。
【０６０１】
また、優先順位情報はペイロードに含まれたデータの優先順位を示す。詳しくは、優先順位はペイロードに含まれたデータの属性情報を示す。例えば、ファイルフォーマットメディアデータのシグナリング情報を含んでいるペイロードの場合、該当パケットの優先順位情報は最も高い優先順位に設定されている。
【０６０２】
また、ペイロードタイプ情報はペイロードデータを含むパケットペイロードのタイプを示す。例えば、放送伝送装置が一つのパケットペイロードに一つのデータをパケット化したのか、または複数のパケットペイロードに一つのデータを分けてパケット化したのか否かを示す。
【０６０３】
放送受信装置１００は制御部１５０を介して抽出されたペイロードヘッダに含まれた情報からペイロードに含まれたデータがメディアデータであるのか否かを判断するＳ２０５。詳しくは、放送受信装置１００の制御部１５０はパケットヘッダ情報に基づいて該当パケットに含まれたペイロードのタイプを判断する。一実施例において、ペイロードのタイプは放送コンテンツ及び放送コンテンツに関する向上されたコンテンツのうち少なくとも一つを含むメディアデータであってもよい。他の実施例において、ペイロードのタイプはメディアデータを提供するのに必要な付加情報を含むメタデータであってもよい。
【０６０４】
放送受信装置１００の制御部１５０はペイロードに含まれたデータがメディアデータであると判断した場合、全体のメディアデータが受信した一つの伝送パケットに含まれているのか否かを判断するＳ２０７。具体的な実施例において、伝送パケットの長さと全体メディアデータの容量に応じて、放送伝送装置は一つの伝送パケットに全体メディアデータをパケット化する。他の実施例において、放送伝送装置は全体メディアデータを分けてそれぞれ異なる伝送パケットにパケット化する。よって、放送受信装置１００の制御部１５０はコンテンツ出力のための完全なメディアデータを抽出するために放送パケットのタイプをペイロードヘッダを介して判断する。
【０６０５】
一方、本発明の一実施例において、放送受信装置１００の制御部１５０はペイロードに含まれたメディアデータではないと判断した場合は下記図６６で詳しく説明する。
【０６０６】
一つの伝送パケットに全体のメディアデータが含まれていると判断した場合、制御部１５０は一つのパケットペイロードからメディアデータを抽出するＳ２０９。一実施例において、放送受信装置１００の制御部１５０は一つの伝送パケットから一つのメディアデータのみを抽出する。他の実施例において、放送受信装置１００の制御部１５０は一つの伝送パケットから複数のメディアデータを抽出する。一方、一つの伝送パケットに全体のメディアデータが含まれていないと判断した場合、制御部１５０はペイロードヘッダ及びセグメントデータヘッダに基づいて複数のパケットペイロード部からメディアデータを抽出するＳ２１１。詳しくは、制御部１５０はペイロードヘッダ及びセグメントデータヘッダから分けられてパケット化されたメディアデータの情報を取得する。よって、制御部１５０は取得した情報に応じて分けられたメディアデータを識別することができる。つまり、制御部１５０は取得した情報に応じて分けられたメディアデータの順番を取得する。制御部１５０は該当順番に基づいて互いに異なる伝送パケットから取得したメディアデータを連結させる（ｃｏｎｃａｔｅｎａｔｅ）。
【０６０７】
放送受信装置１００は制御部１５０を介してコンテンツを提供するＳ２１３。一実施例において、制御部１５０は抽出したメディアデータに基づいてコンテンツを提供する。他の実施例において、制御部１５０は連結されたメディアデータに基づいてコンテンツを提供する。
【０６０８】
Ａ／Ｖコンテンツを出力する。他の実施例において、放送受信装置１００はＡ／Ｖコンテンツに関する向上されたデータを出力してもよい。
【０６０９】
図４４は、本発明の実施例によるパケット構成を示す図である。
【０６１０】
パケットベースのデータ伝送プロトコルの上において、一般的に各パケットは図４０に示したようにパケットヘッダとパケットペイロードで構成される。パケットヘッダはパケットが含んでいるパケットペイロードの情報を含む。パケットペイロードは放送網またはインターネット網で伝送しようとするメディアデータを含む。パケットペイロードが含むメディアデータはオーディオ、ビデオ、向上されたサービス及び付加情報のうち少なくともいずれか一つである。
【０６１１】
図４５は、本発明の実施例によるリアルタイムコンテンツ伝送のためのＲＴＰパケットの構造を示す図である。
【０６１２】
ＲＴＰパケットはＲＰＴ  Ｈｅａｄｅｒ及びＲＴＰ  Ｐａｙｌｏａｄを含む。更に、ＲＴＰ  ＨｅａｄｅｒはＴｉｍｅｓｔａｍｐ、Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ｓｏｕｒｃｅ  ｉｄｅｎｔｉｆｉｅｒ及びＣｏｎｔｒｉｂｕｔｉｎｇ  ｓｏｕｒｃｅ  ｉｄｅｎｔｉｆｉｅｒのうち少なくとも一つを含む。
【０６１３】
ＲＴＰ  ＨｅａｄｅｒはＶ（ｖｅｒｓｉｏｎ）フィールド、Ｐ（ｐａｄｄｉｎｇ）フィールド、Ｘ（ｅｘｔｅｎｓｉｏｎ）フィールド、ＣＣフィールド、Ｍ（Ｍａｒｋｅｒ  ｂｉｔ）フィールド、Ｐａｙｌｏａｄ  Ｔｙｐｅフィールド、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒフィールド及びＴｉｍｅｓｔａｍｐフィールドのうち少なくとも一つのフィールドを含む。
【０６１４】
Ｖフィールドは該当ＲＴＰバージョンの情報を示す。具体的な実施例において、Ｖフィールドは２ビットである。
【０６１５】
Ｐフィールドはペイロード内のパディングビットの存在の有無を示す。具体的な実施例において、Ｐフィールドは１ビットである。
【０６１６】
ＸフィールドはＲＴＰ  Ｈｅａｄｅｒ内のｅｘｔｅｎｓｉｏｎフィールドの存在の有無を示す。具体的な実施例において、Ｘフィールドは１ビットである。
【０６１７】
ＣＣフィールドはＣｏｎｔｒｉｂｕｔｉｎｇ  ｓｏｕｒｃｅの数を示す。具体的な実施例において、ＣＣフィールドは４ビットである。
【０６１８】
Ｍ（Ｍａｒｋｅｒ  ｂｉｔ）フィールドはＰａｙｌｏａｄ  Ｔｙｐｅに応じて互いに異なる意味を示す。例えば、ｔｒａｎｓｐｏｒｔ  ｏｂｊｅｃｔがファイルであればファイルの最後を示す。他の例として、ｔｒａｎｓｐｏｒｔ  ｏｂｊｅｃｔがビデオまたはオーディオデータであれば関連するアクセスユニット（ａｃｃｅｓｓ  ｕｎｉｔ）の最初または最後のオブジェクトであることを示す。具体的な実施例において、Ｍフィールドは１ビットである。
【０６１９】
Ｐａｙｌｏａｄ  ＴｙｐｅフィールドはＲＴＰ  Ｐａｙｌｏａｄのタイプを示す。具体的な実施例において、Ｐａｙｌｏａｄ  Ｔｙｐｅフィールドは７ビットである。
【０６２０】
Ｓｅｑｕｅｎｃｅ  ＮｕｍｂｅｒフィールドはＲＴＰパケットのシーケンスナンバーを示す。具体的な実施例において、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒフィールドは１６ビットである。
【０６２１】
ＴｉｍｅｓｔａｍｐフィールドはＲＴＰパケットに関する時間情報を示す。ＴｉｍｅｓｔａｍｐフィールドはＰａｙｌｏａｄ  Ｔｙｐｅフィールドの値に応じて異なるように解釈される。具体的な実施例において、Ｔｉｍｅｓｔａｍｐフィールドは３２ビットである。
【０６２２】
ＲＴＰ  ＰａｙｌｏａｄはＲＴＰ  ＨｅａｄｅｒのＰａｙｌｏａｄ  Ｔｙｐｅに応じてオーディオ／ビデオアクセスユニットが含まれる。例えば、Ｈ．２６４の場合ＮＡＬ（ｎｅｔｗｏｒｋ  ａｂｓｔｒａｃｔ  ｌａｙｅｒ）  ｕｎｉｔなどが含まれる。
【０６２３】
図４６は、本発明の一実施例によるＩＳＯ  ｂａｓｅ  ｍｅｄｉａ  ｆｏｒｍａｔ（以下、ＩＳＯ  ＢＭＦＦ）をベースにするメディアファイルフォーマットを示す図である。
【０６２４】
図４６に示したように、メディアファイルフォーマットは一般に一つのｆｔｙｐと一つまたはそれ以上のｍｏｏｖ、ｍｏｏｆ及びｍｄａｔを含む。
【０６２５】
ｆｔｙｐはメディアファイルのタイプ及び適合性を示す。ｆｔｙｐはメディアファイルでできるだけ前に位置する。
【０６２６】
ｍｏｏｖは全てのメディアデータのためのコンテナである。詳しくは、プレゼンテーションのシングルトラック（ｔｒａｃｋ）のためのコンテナボックスである。プレゼンテーションは一つまたはそれ以上のトラックで構成される。それぞれのトラックはプレゼンテーション内で他のトラックとは独立している。一実施例において、トラックはメディアデータを含み、他の実施例において、トラックはパケット化されたストリーミングプロトコルのための情報を含む。
【０６２７】
ｍｄａｔはメディアデータのコンテナであり、ｍｏｏｆはｍｄａｔのための情報を含んでいる。
【０６２８】
図４７は、本発明の一実施例によるパケットペイロードのペイロードヘッダの構成を示す図である。
【０６２９】
現在、リアルタイム伝送プロトコルは殆どメディアファイルのアクセスユニットなどをベースに伝送している。詳しくは、アクセスユニットとはメディアファイルまたはデータを伝送する最小単位を意味する。よって、メディアファイルフォーマットベースのデータをリアルタイムで伝送する方式に関する考慮が不十分なことろがある。
【０６３０】
本発明の一実施例による放送伝送装置は、一つの伝送パケットに含まれたペイロードを介して一つのファイルフォーマットベースのメディアデータを伝送する。この場合、伝送パケットはシングルユニットパケット（ｓｉｎｇｌｅ  ｕｎｉｔ  ｐａｃｋｅｔ）であるといえる。他の実施例において、放送伝送装置は一つの伝送パケットに含まれたペイロードを介して複数のファイルフォーマットベースのメディアデータを伝送する。この場合の伝送パケットはアグリゲーションパケット（Ａｇｇｒｅｇａｔｉｏｎ  ｐａｃｋｅｔ）であるといえる。また他の実施例による放送伝送装置は一つのファイルフォーマットベースのメディアデータを様々な伝送パケットに分けて伝送する。この場合の伝送パケットはフラグメンテッドパケット（Ｆｒａｇｍｅｎｔｅｄ  ｐａｃｋｅｔ）であるといえる。更に他の実施例において、放送伝送装置は一つの伝送パケットのペイロードを介してメディアストリームに関する一つまたは複数のメタデータを伝送する。更に他の実施例において、放送伝送装置は一つのメタデータを複数の伝送パケットのペイロードを介して伝送する。
【０６３１】
また、本発明の一実施例による放送伝送装置は多様なプロトコルを介してメディアデータを伝送する。上述したプロトコルはリアルタイム伝送プロトコル（ｒｅａｌ−ｔｉｍｅ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（ＲＴＰ））、非同期階層化コーディング（ａｓｙｎｃｈｒｏｎｏｕｓ  ｌａｙｅｒｅｄ  ｃｏｄｉｎｇ（ＡＬＤ））及び階層化コーディング伝送（ｌａｙｅｒｅｄ  ｃｏｄｉｎｇ  ｔｒａｎｓｐｏｒｔ（ＬＣＴ））のうち少なくとも一つである。
【０６３２】
詳しくは、放送伝送装置は伝送パケットのヘッダにペイロードタイプに関する情報を示すフィールドを挿入し、該当フィールドを介してペイロード内にファイルフォーマットベースのメディアデータが含まれていることを示す。例えば、ＲＰＴの場合、ヘッダのＰａｙｌｏａｄ  ｔｙｐｅフィールドがペイロードのデータタイプを示し、該当フィールドに特定値をファイルフォーマットベースのメディアデータのためのＰａｙｌｏａｄ  ｔｙｐｅ値として割り当てる。そして、この場合ＲＴＰパケットヘッダのＭフィールドは一つのメディアファイルの最後を含むデータがパケットのペイロードに含まれれば１にセッティングされる。
【０６３３】
上述した課題を解決するため、本発明の一実施例によるペイロードヘッダはペイロードが含むデータの上にエラーまたはシンタックスエラーがあるのか否かを示す情報、データの優先順位を示す情報及びデータのタイプを示す情報のうち少なくとも一つを含む。この場合、ペイロードヘッダに含まれたペイロードが含むデータ上のエラーまたはシンタックスエラーを示す情報をＦフィールドという。一実施例において、ペイロードヘッダに含まれたペイロードが含むデータ上のエラーまたはシンタックスエラーを示す情報はｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔであって、ペイロードが含むデータ上にエラーが発生するかシンタックス違反が発生すれば１にセッティングされる。詳しくは、ペイロードヘッダに含まれたペイロードが含むデータ上にエラーまたはシンタックスエラーを示す情報は１ビットである。
【０６３４】
また、この場合ペイロードヘッダに含まれたデータの優先順位を示す情報はＰｒｉｏｒｉｔｙフィールドといえる。一実施例において、データの優先順位を示す情報はペイロードデータの優先順位を示すフィールドである。そして、データの優先順位を示す情報はペイロードデータがメディアファイルフォーマット上で重要なメタデータを含むのか否かを示す。
【０６３５】
ＩＳＯ  ＢＭＦＦを例に挙げると、ｆｔｙｐまたはｍｏｏｖなどを含むペイロードデータの場合、データの優先順位を示す情報は最も高い順位にセッティングされる。一実施例において、データの優先順位を示す情報は放送伝送装置の制御部を介して、最も高い優先順位（ｈｉｇｈｅｓｔ）、最も高い優先順位に比べ相対的に低い順位（ｍｅｄｉｕｍ）、最も低い順位（ｌｏｗ）を示す。この場合、データの優先順位を示す情報は最も高い優先順位で０ｘ００、最も高い優先順位に比べ相対的に低い順位で０ｘ０１、そして最も低い順位で０ｘ０２に設定される。上述した設定値は一実施例に過ぎず、他の任意の値に設定されてもよい。
【０６３６】
また、この場合データのタイプを示す情報をＴｙｐｅフィールドという。詳しくは、データのタイプを示す情報を介して放送受信装置１００の制御部１５０は伝送パケットが一つのパケットに一つのデータを伝送するパケットであるのか、一つのパケットで複数の互いに異なるデータを伝送するパケットであるのか、または一つのデータを複数個に分けたデータを伝送するパケットであるのかを識別する。
【０６３７】
また、放送受信装置１００の制御部１５０はデータのタイプを示す情報を介して伝送パケットがコンテンツの時間情報を含むメタデータを伝送するパケットであるのか、伝送パケットがコンテンツの説明情報を含むメタデータを伝送するパケットであるのかを識別する。
【０６３８】
一実施例において、放送伝送装置が一つのパケットで一つのデータを伝送するパケットであればデータのタイプを示す情報を０ｘ００に設定する。また、放送伝送装置は一つのパケットで複数の互いに異なるデータを伝送するパケットであればデータのタイプを示す情報を０ｘ０１に設定する。また、放送伝送装置は一つのデータを分けたデータを伝送するパケットであればデータのタイプを示す情報を０ｘ０２に設定する。
【０６３９】
また、放送伝送装置はメディアデータではなくコンテンツの再生またはデコーティング時間情報を含むメタデータをパケット化して伝送する。この場合、放送伝送装置はデータのタイプを示す情報を０ｘ０３に設定する。一方、上述した時間情報をタイムライン（ｔｉｍｅｌｉｎｅ）データという。
【０６４０】
また、放送伝送装置はコンテンツの説明情報を含むメタデータをパケット化して伝送する。この場合、放送伝送装置はデータのタイプを示す情報を０ｘ０４に設定する。一方、上述した情報をラベリング（ｌａｂｅｌｉｎｇ）データという。
【０６４１】
しかし、上述した設定値は一実施例に過ぎず、本発明が上述した値に限ることはない。具体的な実施例において、ｔｙｐｅフィールドは５ビットである。
【０６４２】
図４８乃至図４９は、一つのパケットに一つのメディアがパケット化された伝送パケットのペイロード構成を示す。
【０６４３】
図４８に示したように、一つのパケットに一つのメディアデータが含まれたパケットをシングルユニットパケットという。シングルユニットパケットのペイロードはペイロードヘッダとペイロードデータを含む。ペイロードデータは一つのファイルフォーマットベースのメディアデータを含むフラグメンテッドデータを含む。一実施例において、伝送プロトコルが固定長さの伝送パケットを使用すれば、ペイロードデータはフラグメンテッドデータ以外にパディングビットを追加に含む。ここで、パディングビットとは伝送パケットでデータを詰めてから残った空間を詰めるためのビットをいう。
【０６４４】
図４９は、図４８に示した伝送パケットの具体的な例を示す図である。図４９に示したように、ペイロードヘッダはペイロードが含むデータ上にエラーまたはシンタックスエラーがあるのか否かを示す情報、データの優先順位を示す情報およびデータのタイプを示す情報のうち少なくとも一つを含む。
【０６４５】
図４９に示した一実施例において、ペイロードが含むデータ上にエラーまたはインタックスエラーがあるのか否かを示す情報はエラー及びシンタックスの違反がないとの内容を示す値を含む。具体的な実施例において、該当値は０である。
【０６４６】
データの優先順位を示す情報はペイロードデータ内のメディアファイルがｆｔｙｐなどの重要なデータを含むため最も高い優先順位を有する。上述したように、ｆｔｙｐの場合メディアファイルをシグナリングするための情報を含むため最も高い優先順位を有する。具体的な実施例において、最も高い優先順位を示す値は０ｘ００である。
【０６４７】
データのタイプを示す情報は一つのパケットペイロード内に一つのメディアファイルが全て含まれているためシングルユニットパケットを示す。具体的な実施例において、データのタイプを示す情報は０ｘ００値を有する。追加にメディアファイルの長さと伝送プロトコルに応じてパディングビットが選択的にペイロードデータに挿入される。
【０６４８】
図５０乃至図５１は、一つのパケットに複数の互いに異なるメディアデータがパケット化された伝送パケットの構成を示す。上述したパケットはアグリゲーションパケットといえる。図５０に示したように、一つの伝送パケットのペイロードが複数の互いに異なるファイルフォーマットベースのメディアデータを含む場合、ペイロードデータは複数のアグリゲーションユニットを含む。それぞれのアグリゲーションユニットは互いに異なるファイルフォーマットベースのメディアデータを含む。追加に伝送プロトコルが固定長さのパケットを使用すればペイロードデータはパディングビットを含む。
【０６４９】
一実施例において、一つのアグリゲーションユニットはアグリゲーションユニットの長さを示す情報及びアグリゲーションデータのうち少なくとも一つを含む。この場合、アグリゲーションユニットの長さを示す情報をＡｇｇｒｅｇａｔｉｏｎ  ｕｎｉｔ  ｌｅｎｇｔｈフィールドという。具体的な実施例において、アグリゲーションユニットは１６ビットである。また、アグリゲーションユニットデータは一つのファイルが含むデータを示す。
【０６５０】
図５１はアグリゲーションユニットの構成を示す他の実施例であって、一つのアグリゲーションユニットは図５０の実施例で追加にアグリゲーションユニット内に含まれたファイルのタイプを示す情報を更に含む。
【０６５１】
アグリゲーションのタイプを示す情報をＡｇｇｒｅｇａｔｉｏｎ  ｕｎｉｔ  ｔｙｐｅフィールドという。具体的な実施例において、放送伝送装置はアグリゲーションタイプを０ｘ００に設定する。
【０６５２】
他の実施例において、アグリゲーションタイプはＭＰＥＧ−ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP））におけるセルフ・イニシャライジングセグメント（Ｓｅｌｆ−ｉｎｉｔｉａｌｉｚｉｎｇ  Ｓｅｇｍｅｎｔ）形態のファイルを該当アグリゲーションユニットが含んでいることを示す。ここで、セルフ・イニシャライジングセグメントは別途のイニシャライジングセグメントなしにイニシャライジングセグメントとメディアセグメントを統合したものである。詳しくは、メディアセグメントとメディアセグメントのメディア形態を含む。具体的な実施例において、この場合、放送伝送装置はアグリゲーションタイプを０ｘ０１に設定する。
【０６５３】
更に他の実施例において、アグリゲーションタイプはＭＰＥＧ−ＤＡＳＨにおけるイニシャライジングセグメント形態のファイルを該当アグリゲーションユニットが含んでいることを示す。ここで、イニシャライジングセグメントはＩＳＯ  ＢＭＦＦに従うフォーマットである。詳しくは、イニシャライジングセグメントはｆｔｙｐ、ｍｏｏｖを含むべきである。そして、ｍｏｏｆを含んではならない。具体的な実施例において、この場合、放送伝送装置はアグリゲーションタイプを０ｘ０２に設定する。
【０６５４】
図５２乃至図５８は、一つのメディアデータが複数の伝送パケットに分けられてパケット化された伝送パケット（以下、フラグメンテッドパケット）のペイロード構成を示す図である。図５２は、フラグメンテッドパケットのペイロード構成の一実施例を示す図である。図５２に示したように、フラグメンテッドパケットのペイロードはフラグメンテーションユニット（ｆｒａｇｍｅｎｔａｔｉｏｎ  ｕｎｉｔ）を含む。追加に、フラグメンテッドパケットのペイロードは伝送プロトコルが固定長さのパケットを使用する場合、パディングビットが含まれる。
【０６５５】
一実施例において、フラグメンテーションユニット（ＦＵ）はフラグメンテーションユニットヘッダ（Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｕｎｉｔ  ｈｅａｄｅｒ）及びフラグメンテーションユニットデータ（Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｕｎｉｔ  ｄａｔａ）のうち少なくともいずれか一つを含む。フラグメンテーションユニットデータは一つのファイルフォーマットベースのメディアデータの一部分を含む。フラグメンテーションユニットヘッダはフラグメンテーションユニットデータの情報を含む。
【０６５６】
詳しくは、フラグメンテーションユニットヘッダはフラグメンテーションユニットデータが全体ファイルのメディアデータのうち開始部分のデータを含んでいるのか否かの情報、フラグメンテーションユニットデータが全体ファイルのメディアデータのうち終了部分のデータを含んでいるのか否かを示す情報、及びフラグメンテーションユニットのタイプを示す情報のうち少なくともいずれか一つを含む。
【０６５７】
一実施例において、全体ファイルのメディアデータのうち開始部分のデータを含んでいるのか否かを示す情報をＳｔａｒｔ  ｂｉｔフィールドという。詳しくは、開始部分のデータは全体メディアデータの最初のビットを含む全体データの一部である。
【０６５８】
例えば、該当ペイロードのフラグメントユニットが開始部分のデータを含んでいる場合、放送伝送装置は全体ファイルのメディアデータのうち開始部分のデータを含んでいるのか否かを示す情報を１に設定する。詳しくは、全体ファイルのメディアデータのうち開始部分のデータを含んでいるのか否かを示す情報は１ビットである。
【０６５９】
一実施例において、全体ファイルのメディアデータのうち最後の部分のデータを含んでいるのか否かを示す情報をＥｎｄ  ｂｉｔフィールドという。詳しくは、最後の部分のデータは全体メディアデータの最後のビットを含む全体データの一部である。
【０６６０】
例えば、該当ペイロードのフラグメンテーションユニットデータが最後の部分のデータを含んでいる場合、放送伝送装置は全体ファイルのメディアデータのうち最後の部分のデータを含んでいるのか否かを示す情報を１に設定する。詳しくは、全体ファイルのメディアデータのうち最後の部分のデータを含んでいるのか否かを示す情報は１ビットである。
【０６６１】
一実施例において、フラグメンテーションユニットのタイプを示す情報はフラグメンテーションユニットタイプフィールドという。
【０６６２】
一実施例において、フラグメンテーションユニットタイプは該当パケットがファイルフォーマットベースの基本的なファイルをフラグメンテーションユニットが含んでいることを示す。詳しくは、ファイルフォーマットベースの基本的なファイルはＩＳＯ  ＢＭＦＦをベースにするファイルフォーマットを有するメディアファイルである。具体的な実施例において、放送伝送装置はフラグメンテーションユニットタイプを０ｘ００に設定する。
【０６６３】
他の実施例において、フラグメンテーションユニットタイプはＭＰＥＧ−ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）におけるセルフ・イニシャライジングセグメント形態のファイルを該当フラグメンテーションユニットが含んでいることを示す。具体的な実施例において、この場合、放送伝送装置はフラグメンテーションユニットタイプを０ｘ０１に設定する。
【０６６４】
更に他の実施例において、フラグメンテーションユニットタイプはＭＰＥＧ−ＤＡＳＨにおけるイニシャライジングセグメント形態のファイルを該当フラグメンテーションユニットが含んでいることを示す。具体的な実施例において、この場合、放送伝送装置はフラグメンテーションユニットタイプを０ｘ０２に設定する。
【０６６５】
更に他の実施例において、フラグメンテーションユニットタイプはＭＰＥＧ−ＤＡＳＨにおけるメディアセグメント形態のファイルを該当フラグメンテーションユニットが含んでいることを示す。具体的な実施例において、この場合、放送伝送装置はフラグメンテーションユニットタイプを０ｘ０３に設定する。
【０６６６】
詳しくは、フラグメンテーションユニットタイプを示す情報は６ビットである。
【０６６７】
図５３は、フラグメンテッドパケットのペイロード構成の他の実施例を示す図である。図５３の実施例は伝送パケットのヘッダに伝送パケットの順番に関する情報が存在しない場合に適用される。
【０６６８】
図５３に示したように、フラグメンテーションユニット（ＦＵ）に含まれたフラグメンテーションユニットヘッダはフラグメンテーションユニットデータが全体ファイルのメディアデータのうち開始部分のデータを含んでいるのか否かの情報、フラグメンテーションユニットデータが全体ファイルのメディアデータのうち終了部分のデータを含んでいるのか否かを示す情報、及びフラグメンテーションユニットのタイプを示す情報、及びフラグメンテーションユニットの全体データにおける順番を示す情報のうち少なくともいずれか一つを含む。上述した情報のうちフラグメンテーションユニットの順番を示す情報を除く残りの情報は図５２で説明した通りである。
【０６６９】
フラグメンテーションユニットの順番を示す情報はＦｒａｇｍｅｎｔａｔｉｏｎ  ｎｕｍｂｅｒフィールドという。詳しくは、放送伝送装置はファイルフォーマットベースのメディアデータが複数のフラグメンテッドパケットに分けられた場合、フラグメンテーションユニットの順番を示す情報に値を設定して該当パケットの順番を割り当てる。詳しくは、Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｎｕｍｂｅｒフィールドは８ビットである。
【０６７０】
図５４は、本発明の一実施例において、放送伝送装置がＩＳＯ  ＢＭＦＦベースのメディアファイルをフラグメンテーションして複数個のパケットに分けることを示す図である。図５４に示したように、ＩＳＯ  ＢＭＦＦベースのメディアファイルはｆｔｙｐ、ｍｏｏｖと複数のｍｏｏｆ及びｍｄａｔを含む。
【０６７１】
放送伝送装置はＩＳＯ  ＢＭＦＦベースのメディアファイルを複数個に分けてそれぞれ異なるフラグメンテーションユニットデータに含ませる。また、放送伝送装置はＩＳＯ  ＢＭＦＦベースのメディアファイルを分けながらペイロードヘッダに関する情報を含ませる。
【０６７２】
図５５は、図５４の放送伝送装置はパケット化した第１フラグメンテーションユニットデータの具体的な実施例を示す図である。
【０６７３】
図５５に示したように、本発明の一実施例において、放送伝送装置はペイロードのＦフィールドを該当パケットにエラーまたはシンタックスのエラーがないと判断して０に設定する。
【０６７４】
また、放送伝送装置はＰｒｉｏｒｉｔｙフィールドを最も高い優先順位を示す値に設定する。詳しくは、該当値は０ｘ００である。
【０６７５】
また、放送伝送装置はＴｙｐｅフィールドを該当パケットが一つのファイルフォーマットベースのメディアファイルを様々なペイロードに分けて伝送するパケットを示す値に設定する。詳しくは、該当値は０ｘ０２である。
【０６７６】
ペイロードデータはフラグメンテーションユニットを含み、更にフラグメンテーションユニットはＳｔａｒｔ  ｂｉｔフィールド、フラグメンテーションユニットタイプフィールド及びフラグメンテーションユニットデータフィールドを含む。
【０６７７】
放送伝送装置はＳｔａｒｔ  ｂｉｔフィールドを該当パケットがメディアファイルの開始データを含む内容を示す値に設定する。詳しくは、図５４において第１フラグメンテーションユニットがメディアデータの開始データを含むため、放送伝送装置は該当内容を示す値をＳｔａｒｔ  ｂｉｔフィールドに設定する。
【０６７８】
一方、放送伝送装置は図５５で例示したように第１フラグメンテーションユニットのＥｎｄ  ｂｉｔフィールドをメディアファイルの最後の部分のデータを含んでいないとの内容を示す値に設定する。具体的な実施例において、放送伝送装置は該当パケットがメディアファイルの最後の部分のデータを含んでいないとの内容を示すためにＥｎｄ  ｂｉｔフィールドを０に設定する。
【０６７９】
一方、放送伝送装置は図５５で例示したように第１フラグメンテーションユニットがファイルフォーマットベースの基本的な形態のファイルを含んでいるとの内容をフラグメンテーションユニットタイプフィールドに設定する。詳しくは、ファイルフォーマットベースの基本的な形態とは、ＩＳＯ  ＢＭＦＦに従うファイルフォーマットデータである。具体的な実施例において、放送伝送装置はフラグメンテーションユニットタイプフィールドを０ｘ００に設定し該当内容を示す。
【０６８０】
図５６乃至図５８は、図５４のフラグメンテーションユニットデータのうち開始データを除く残りのデータを含むフラグメンテーションユニットの一実施例を示す図である。
【０６８１】
図５６に示したように、本発明の一実施例において、放送伝送装置はペイロードヘッダのＦフィールドを該当パケットにエラーまたはシンタックスエラーがないことを示す値に設定する。具体的な実施例において、放送伝送装置はＦフィールドを０に設定する。また、放送伝送装置は図５６に示したペイロードデータが相対的に低い優先順位を示すことを示す値としてＰｒｉｏｒｉｔｙフィールドを設定する。
【０６８２】
具体的な実施例において、第２フラグメンテーションユニットからは全体メディアデータをシグナリングするデータを含まない可能性がある。よって、第１フラグメンテーションユニットより優先順位が相対的に低いため、Ｐｒｉｏｒｉｔｙフィールドが相対的に低い優先順位を有する値に設定される。例えば、該当値は０ｘ０１である。
【０６８３】
また、放送伝送装置はＴｙｐｅフィールドを該当パケットが一つのファイルフォーマットベースのメディアファイルを様々なペイロードに分けて伝送するパケットを示すＦｒａｇｍｅｎｔｅｄ  ｐａｃｋｅｔとして０ｘ０２に設定する。図５７は、ペイロードデータが開始データを含むフラグメンテーションユニットデータ及び最後のデータを含むフラグメンテーションユニットデータを含まない場合のペイロード構成を示す。
【０６８４】
本発明の一実施例において、放送伝送装置は図５７のフラグメンテーションユニットデータが開始データ及び最後のデータを含んでいないため、Ｓｔａｒｔ  ｂｉｔフィールド及びＥｎｄ  ｂｉｔフィールドを該当情報を示す値として設定する。具体的な実施例において、放送伝送装置はＳｔａｒｔ  ｂｉｔ及びＥｎｄ  ｂｉｔフィールドを全て０に設定する。
【０６８５】
また、放送伝送装置はフラグメンテーションユニットタイプフィールドを特定値に設定する。詳しくは、ファイルフォーマットベースの基本的な形態とは、ＩＳＯ  ＢＭＦＦに従うファイルフォーマットデータである。具体的な実施例において、放送伝送装置はフラグメンテーションユニットタイプフィールドを０ｘ００に設定し該当内容を示す。パケットに分けられたそれぞれのファイルフォーマットベースのメディアデータは全体ファイルで固有の順番を有する。放送受信装置１００は制御部１５０を介して分けられたフラグメンテーションユニットデータが全体データのうち開始部分を含むことをＳｔａｒｔ  ｂｉｔフィールドに基づいて識別する。また、フラグメンテーションユニットデータが全体データのうち最後の部分を示すことをＥｎｄ  ｂｉｔフィールドに基づいて識別する。しかし、Ｓｔａｒｔ  ｂｉｔフィールド及びＥｎｄ  ｂｉｔフィールドのみでは識別が不可能な場合がある。
【０６８６】
フラグメンテーションユニットデータが全体データのうち開始データまたは最後のデータを含んでいない場合、放送受信装置１００は一実施例においてペイロードに含まれたフラグメンテーションユニットデータの順番を示す情報を介して該当パケットを識別する。詳しくは、フラグメンテーションユニットデータの順番を示す情報はフラグメンテーションナンバーフィールドである。また、放送伝送装置は該当フラグメンテーションユニットデータの順番を上述したフラグメンテーションフィールドに設定する。
【０６８７】
しかし、他の実施例において、伝送パケットはフラグメンテーションユニットデータの順番情報を含まなくてもよい。この場合、一実施例において、放送伝送装置はパケットヘッダにフラグメンテーションユニットデータの順番を識別するための情報を挿入する。パケットヘッダに含まれたフラグメンテーションユニットデータの順番を識別するための情報はシーケンスナンバーフィールドである。他の実施例において、放送伝送装置はＩＰデータグラムのオフセット情報にフラグメンテーションユニットデータの順番を識別するための情報を挿入してもよい。
【０６８８】
図５８は、分けられた全体メディアのうち最後のデータを含むフラグメンテーションユニットを含むペイロードの構成を示す図である。詳しくは、図５８はペイロードデータが開始データを含むフラグメンテーションユニットデータを含まないが、最後のデータを含むフラグメンテーションユニットデータを含む場合のペイロード構成を示す。
【０６８９】
本発明の一実施例において、放送伝送装置は図５８のフラグメンテーションユニットデータが最後のデータを含んでいるため、Ｓｔａｒｔ  ｂｉｔフィールド及びＥｎｄ  ｂｉｔフィールドを該当情報を示す値として設定する。具体的な実施例において、放送伝送装置はＳｔａｒｔ  ｂｉｔフィールドを０に設定する。そして、放送伝送装置はＥｎｄ  ｂｉｔフィールドを１に設定する。
【０６９０】
また、放送伝送装置はフラグメンテーションユニットタイプフィールドを該当パケットを含むメディアデータがＩＳＯ  ＢＭＦＦベースのｆｔｙｐから始まる基本的な形態のファイルを含む内容を示すように設定する。具体的な実施例において、放送伝送装置はフラグメンテーションユニットタイプフィールドを０ｘ００に設定する。
【０６９１】
放送伝送装置が伝送パケットを介して伝送するデータは上述したメディアデータと共にメタデータ（ｍｅｔａｄａｔａ）がある。
【０６９２】
メタデータはメディアデータを提供するために必要な付加情報を示す。以下、図５６乃至図６６ではメタデータを伝送パケットにパケット化して伝送及び受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提案する。
【０６９３】
また、以下ではメタデータの一例としてタイムライン情報を中心に説明する。タイムライン情報とはメディアコンテンツのための一連の時間情報である。詳しくは、タイムライン情報は再生またはデコーディングするための一連の時間情報である。
【０６９４】
また、タイムラインの情報は基本タイムライン（Ｂａｓｅ  ｔｉｍｅｌｉｎｅ）情報を含む。基本タイムラインとは、複数の互いに異なる伝送網を介して伝送されるメディアデータを同期化するために必要な基準タイムラインを意味する。詳しくは、第１伝送網を介して伝送されるメディアデータのタイムラインに第２伝送網を介して伝送されるメディアデータのタイムラインをマッピングする場合、第１伝送網を介して伝送されるメディアデータのタイムラインが基本タイムラインとなる。
【０６９５】
一方、放送伝送装置はメタデータをＸＭＬのフォーマットで表現する。また、放送伝送装置はメタデータをシグナリングテーブルに含まれるデスクリプタの形態に表現してもよい。
【０６９６】
図５９は、本発明の一実施例によるメタデータのタイムラインシグナリングテーブルを示す図である。
【０６９７】
本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインに関するメタデータであることを示す情報または該当メタデータがタイムラインコンポーネントアクセスユニット（ｔｉｍｅｌｉｎｅ  ｃｏｍｐｏｎｅｎｔ  ａｃｃｅｓｓ  ｕｎｉｔ）構造を含んでいることを示す情報を含む。上述した情報をｉｄｅｎｔｉｆｉｅｒフィールドという。具体的な実施例において、ｉｄｅｎｔｉｆｉｅｒフィールドは８ビットである。
【０６９８】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットのタイムライン情報の長さを示す情報を含む。上述した情報をＡＵ＿ｌｅｎｇｔｈフィールドという。具体的な実施例において、ＡＵ＿ｌｅｎｇｔｈフィールドは３２ビットである。
【０６９９】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットに関するサービス及びコンテンツコンポーネントに関する位置情報を含んでいるのか否かを示す情報を含む。上述した情報をｌｏｃａｔｉｏｎ＿ｆｌａｇフィールドという。具体的な実施例において、ｌｏｃａｔｉｏｎ＿ｆｌａｇフィールドは１ビットである。
【０７００】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットが含むタイムスタンプのバージョン情報を含む。タイムスタンプとは連続したタイムラインで該当アクセスユニットが出力されるべき時間情報を示す。上述した情報をｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドという。具体的な実施例において、ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドは１ビットである。
【０７０１】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットのタイムスタンプのタイプ情報を含む。上述した情報をｌｏｃａｔｉｏｎ＿ｔｙｐｅフィールドという。
【０７０２】
一実施例において、タイムラインコンポーネントアクセスユニットに関するサービスまたはコンテンツコンポーネントのデコーディング時点を示す値が設定される。詳しくは、コンテンツコンポーネントのデコーティング時点はデコーティングタイムスタンプ（ｄｅｃｏｄｉｎｇ  ｔｉｍｅｓｔａｍｐ）という。具体的な一実施例において、放送伝送装置はタイムスタンプのタイプ情報を該当情報がデコーディング時点を示せば０ｘ００に設定する。
【０７０３】
他の実施例において、タイムラインコンポーネントアクセスユニットに関するサービスまたはコンテンツコンポーネント再生時点を示す値が設定される。詳しくは、コンテンツコンポーネントの再生時点はプレゼンテーションタイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅｓｔａｍｐ）という。具体的な一実施例において、放送伝送装置はタイムスタンプのタイプ情報を該当情報がプレゼンテーション時点を示せば０ｘ０１に設定する。
【０７０４】
一方、具体的な実施例において、ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドは１ビットである。
【０７０５】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットのタイムラインスタンプフォーマット情報を含む。上述した情報をｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドという。
【０７０６】
一実施例において、タイムスタンプフォーマット情報はタイムラインコンポーネントアクセスユニットが含むタイムスタンプがメディアタイム（Ｍｅｄｉａ  ｔｉｍｅ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ００に設定して該当アクセスユニットのタイムスタンプフォーマットがメディアタイムフォーマットであることを示す。
【０７０７】
他の実施例において、タイムスタンプフォーマット情報はタイムラインコンポーネントアクセスユニットに含まれたタイムスタンプがネットワークタイムプロトコル（ｎｅｔｗｏｒｋ  ｔｉｍｅ  ｐｒｏｔｏｃｏｌ（ＮＴＰ））のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０１に設定して該当アクセスユニットのタイムスタンプフォーマットがＮＴＰフォーマットであることを示す。
【０７０８】
また他の実施例において、タイムスタンプフォーマット情報はタイムラインコンポーネントアクセスユニットが含むタイムスタンプがプレシジョンタイムプロトコル（ｐｒｅｃｉｓｉｏｎ  ｔｉｍｅ  ｐｒｏｔｏｃｏｌ（ＰＴＰ））のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０２に設定して該当アクセスユニットのタイムスタンプフォーマットがＰＴＰフォーマットであることを示す。
【０７０９】
更に他の実施例において、タイムスタンプフォーマット情報はタイムラインコンポーネントアクセスユニットが含むタイムスタンプがタイムコード（ｔｉｍｅｃｏｄｅ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０３に設定して該当アクセスユニットのタイムスタンプフォーマットがタイムコードフォーマットであることを示す。一方、具体的な実施例において、ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドは４ビットである。
【０７１０】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインコンポーネントアクセスユニットが含む情報に関するサービスまたはコンテンツのコンポーネントに関する位置情報を含む。上述した情報をｌｏｃａｔｉｏｎフィールドという。
【０７１１】
また、本発明の一実施例において、タイムラインシグナリングテーブルは上述した位置情報の長さを示す情報を含む。位置情報の長さを示す情報をｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈフィールドという。具体的な実施例において、ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈフィールド８ビットである。
【０７１２】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインマッチングの基準になり得る基本タイムラインのタイムスタンプフォーマットバージョン情報を含む。上述した情報をｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドという。
【０７１３】
一実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが０に設定されればタイムスタンプフォーマットが３２ビットのフォーマットを有することを示す。他の実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが１に設定されればタイムスタンプフォーマットが６４ビットのフォーマットを有することを示す。
【０７１４】
また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムラインのタイムスタンプタイプ情報を含む。上述した情報をｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドという。
【０７１５】
一実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドは基本タイムラインに関するサービスまたはコンテンツコンポーネントのデコーディング時点を示す値が設定される。詳しくは、コンテンツコンポーネントのデコーディング時点はデコーティングタイムスタンプ（ｄｅｃｏｄｉｎｇ  ｔｉｍｅｓｔａｍｐ）という。具体的な一実施例において、放送伝送装置は該当情報がデコーディング時点を示す場合、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドを０ｘ００に設定する。
【０７１６】
他の実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドは基本タイムラインに関するサービスまたはコンテンツコンポーネントの再生時点を示す値が設定される。詳しくは、コンテンツコンポーネントの再生時点はプレゼンテーションタイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎ  ｔｉｍｅｓｔａｍｐ）という。具体的な一実施例において、放送伝送装置は該当情報がプレゼンテーション時点を示す場合、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールド０ｘ０１に設定する。
【０７１７】
本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムラインに対するタイムスタンプフォーマット情報を含む。上述した情報をｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドという。
【０７１８】
一実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドは基本タイムラインのタイムスタンプがメディアタイムのフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ００に設定して該当基本タイムラインのタイムスタンプフォーマットがメディアタイムフォーマットであることを示す。
【０７１９】
他の実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドは基本タイムラインのタイムスタンプがネットワークタイムプロトコル（ＮＴＰ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０１に設定して該当基本タイムラインのタイムスタンプフォーマットがＮＴＰフォーマットであることを示す。
【０７２０】
また他の実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドは基本タイムラインのタイムスタンプがプレシジョンタイムプロトコル（ＰＴＰ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０２に設定して該当基本タイムラインのタイムスタンプフォーマットがＰＴＰフォーマットであることを示す。
【０７２１】
更に他の実施例において、ｏｒｉｇｉｎｅ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドは基本タイムラインのタイムスタンプがタイムコード（ｔｉｍｅｃｏｄｅ）のフォーマットであることを示す。具体的な一実施例において、放送伝送装置はｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドを０ｘ０３に設定して該当基本タイムラインのタイムスタンプフォーマットがタイムコードフォーマットであることを示す。
【０７２２】
また、本発明の一実施例において、タイムラインシグナリングテーブルはタイムラインマッチングの基準になり得る基本タイムラインに関するサービス及びコンテンツコンポーネントの位置情報を含んでいるのか否かを含む情報を含む。上述した情報をｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇフィールドという。一実施例において、ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇフィールドが０以外の値に設定される場合、ｔｉｍｅｌｉｎｅ  ＡＵはｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈフィールド及びｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎフィールドのうち少なくともいずれか一つを含む。
【０７２３】
また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムラインに関するサービスまたはコンテンツに対する位置情報を含む。上述した情報をｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎフィールドという。具体的な一実施例において、ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎフィールドに含まれる情報はＩＰアドレス、ポートナンバーまたはＵＲＩの形態である。
【０７２４】
また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムラインに関するサービス及びコンテンツに対する位置情報の長さの情報を含む。上述した情報をｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈフィールドという。具体的な一実施例において、ｏｒｉｇｉｎ＿ｌｏｃａｔｉｏｎ＿ｌｅｎｇｔｈフィールドは８ビットである。
【０７２５】
また、本発明の一実施例において、タイムラインシグナリングテーブルはマッピングの基本になる基本タイムラインがメディアタイムの形態であれば、使用可能なタイムスケール（ｔｉｍｅ  ｓｃａｌｅ）の情報を含む。上述した情報をｏｒｉｇｉｎ＿ｔｉｍｅｓｃａｌｅフィールドという。例えば、ＭＰＥＧ−２  ＴＳの場合、タイムスケールは９０００Ｈｚを示す。具体的な一実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｃａｌｅフィールドは３２ビットである。
【０７２６】
また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムライン上のメディアタイム情報を含む。上述した情報をｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅフィールドという。一方、ｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅフィールドはｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドに応じてその意味が異なり得る。例えば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドがＰＴＳを意味すればｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅフィールドは再生時点を示す。他の例として、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドがＤＴＳを意味すればｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅフィールドはデコーディング時点を示す。具体的な一実施例において、ｏｒｉｇｉｎ＿ｍｅｄｉａ＿ｔｉｍｅフィールドはｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが０に設定されれば３２ビットであり、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが１に設定されれば６４ビットである。
【０７２７】
また、本発明の一実施例において、タイムラインシグナリングテーブルは基本タイムラインタイムスタンプ情報を含む。上述した情報をｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐフィールドという。基本タイムラインタイムスタンプ情報はｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドの値に応じて互いに異なるフォーマットのタイムスタンプを示す。また、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドの値に応じて基本タイムラインタイムスタンプ情報が互いに異なる意味を示す。例えば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドがＰＴＳをシグナリングすれば基本タイムラインタイムスタンプ情報は再生時間を示す。
【０７２８】
例えば、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドがＤＴＳを示し、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドが０ｘ０１であれば、該当ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｔｙｐｅフィールドはＮＴＰで表現されたデコーディング時点を示す。具体的な一実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐフィールドはｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが０であれば３２ビットであり、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｖｅｒｓｉｏｎフィールドが１であれば６４ビットである。
【０７２９】
一実施例において、ｏｒｉｇｉｎ＿ｔｉｍｅｓｔａｍｐ＿ｆｏｒｍａｔフィールドがｒｅｓｅｒｖｅｄを示す場合、ｔｉｍｅｌｉｎｅ  ＡＵはｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールド及びｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ（）フィールドのうち少なくとも一つを含む。
【０７３０】
ｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドはｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ（）フィールドのバイト単位の長さを示す。具体的な一実施例において、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドは１６ビットである。
【０７３１】
ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ（）フィールドはｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドが示す長さだけｐｒｉｖａｔｅｌｙを定義するか、後に拡張内容を含む。
【０７３２】
図６０は、伝送パケットのペイロードデータに一つのメタデータがパケット化されたペイロードデータの構成を示す図である。一実施例において、ペイロードデータはメタデータを含み、メタデータはメディアストリーム関連タイムラインデータを含む。また、一実施例において、放送伝送装置が伝送プロトコルに固定長さのパケットを含めばペイロードデータはパディングデータを追加に含む。
【０７３３】
図６１は、伝送パケットのペイロードデータがタイムラインに対するメタデータを含む場合の実施例を示す図である。
【０７３４】
図６１に示したように、一実施例において、ペイロードヘッダはＦフィールド、Ｐｒｉｏｒｉｔｙフィールド及びＴｙｐｅフィールドのうち少なくとも一つを含む。
【０７３５】
一実施例において、放送伝送装置はＦフィールドをペイロード内にエラーが存在せずシンタックスの違反もないことを示す値に設定する。詳しくは、放送伝送装置はＦフィールドを０に設定する。また、ペイロードデータがメディアファイル構成の重要なデータを全て含むため、放送伝送装置はＰｒｉｏｒｉｔｙフィールドを最も高い優先順位を示す値に設定する。詳しくは、放送伝送装置はＰｒｉｏｒｉｔｙフィールドを０ｘ００に設定する。また、放送伝送装置はＴｙｐｅフィールドをペイロード内にタイムライン情報のメタデータを含む情報を示す値に設定する。詳しくは、放送伝送装置はＴｙｐｅフィールドを０ｘ０３に設定する。また、メタデータは図５９のシンタックスを含む。
【０７３６】
図６２は、一つの伝送パケットに多数のメタデータがパケット化された場合を示す図である。
【０７３７】
図６２に示したように、一つの伝送パケットが多数のメタデータを含む場合をアグリゲーションパケットという。一実施例において、ペイロードデータは複数のアグリゲーションユニットを含む。
【０７３８】
一実施例において、アグリゲーションユニットはメタデータの長さを示す情報を含む。他の実施例において、アグリゲーションユニットはメタデータヘッダフィールドが別途に存在する場合、メタデータヘッダフィールド及びメタデータフィールドの長さの合計を示す情報を含む。上述した情報はｍｅｔａｄａｔａ  ｌｅｎｇｔｈフィールドという。
【０７３９】
図６３は、一つの伝送パケットが多数個のタイムライン情報を含む場合を示す図である。詳しくは、一つのメディアストリームに関してそれぞれの基準が異なる複数個のタイムライン情報を一つの伝送パケットが含んでいる場合を示す。一実施例において、伝送パケットはペイロードパケットを含むが、ペイロードヘッダの内容は図６２の内容のようである。
【０７４０】
また、一実施例において、ペイロードデータは２つのアグリゲーションユニットを含む。しかし、ペイロードデータが含むアグリゲーションユニットの個数は２つ以上であってもよい。
【０７４１】
一実施例において、それぞれのアグリゲーションユニットは図６２に示したようにｍｅｔａｄａｔａ  ｌｅｎｇｔｈフィールド、ｍｅｔａｄａｔａ  ｈｅａｄｅｒフィールド及びタイムライン情報を含むメタデータフィールドのうち少なくともいずれか一つを含む。
【０７４２】
しかし、図６３に示した第１アグリゲーションユニットは第１タイムラインを含むメタデータフィールドを含み、第２アグリゲーションユニットは第２タイムラインを含むメタデータフィールドを含む。具体的な実施例において、タイムラインは互いに異なる基準に基づくデータを有する。例えば、第１タイムラインはメディアタイムラインに基づくデータを有し、第２タイムラインはＮＴＰに基づくデータを有する。
【０７４３】
図６４は、一つのメタデータを複数個の伝送パケットに分けてパケット化したパケットペイロードを示す図である。
【０７４４】
一実施例において、一つのメタデータの長さが伝送パケットの長さより長いことがあるが、この場合、放送伝送装置は該当メタデータを様々な伝送パケットに分けて伝送する。図６４に示したように、伝送パケットはペイロードヘッダ、メタデータフラグメントヘッダ及びメタデータフラグメントのうち少なくとも一つを含む。追加に伝送プロトコルが固定長さのパケットを使用する場合、伝送パケットはパディングビットを含んでもよい。
【０７４５】
図６４に示したように、一実施例において、メタデータフラグメントヘッダは該当伝送パケットの該当伝送パケットのペイロードデータに含まれたメタデータフラグメントが全体メタデータの開始部分を含んでいるのか否かを示す情報を含む。詳しくは、開始部分のデータは全体メディアデータの最初のビットを含む全体データの一部である。上述した情報はｓｔａｒｔ  ｂｉｔフィールドという。具体的な実施例において、ｓｔａｒｔ  ｂｉｔフィールドは１ビットである。一実施例において、放送伝送装置は該当伝送パケットが含んでいるメタデータフラグメントが全体のメタデータの開始部分を含んでいる場合にｓｔａｒｔ  ｂｉｔフィールドを１に設定する。
【０７４６】
他の一実施例において、メタデータフラグメントヘッダは該当伝送パケットの該当伝送パケットのペイロードデータに含まれたメタデータフラグメントが全体メタデータの終了部分を含んでいるのか否かを示す情報を含む。詳しくは、終了部分のデータは全体メディアデータの最後のビットを含む全体データの一部である。上述した情報はｅｎｄ  ｂｉｔフィールドという。具体的な実施例において、ｅｎｄ  ｂｉｔフィールド１ビットである。一実施例において、放送伝送装置は該当伝送パケットが含んでいるメタデータフラグメントが全体のメタデータの終了部分を含んでいる場合にｅｎｄ  ｂｉｔフィールドを１に設定する。
【０７４７】
また他の実施例において、メタデータヘッダはメタデータタイプを示す情報を含む。上述した情報はｍｅｔａｄａｔａ  ｔｙｐｅフィールドという。具体的な実施例において、メタデータタイプが該当メタデータフラグメントがタイムライン情報を含んでいることを示す。この場合、放送伝送装置はｍｅｔａｄａｔａ  ｔｙｐｅフィールドを０ｘ００に設定する。他の実施例において、メタデータタイプが該当メタデータフラグメントがラベリング関連メタデータを含んでいることを示す。この場合、放送伝送装置はｍｅｔａｄａｔａ  ｔｙｐｅフィールドを０ｘ０１に設定する。また、具体的な実施例において、ｍｅｔａｄａｔａ  ｔｙｐｅフィールドは５ビットである。
【０７４８】
図６５は、メタデータフラグメントヘッダの他の実施例を示す図である。ここで、図６４と同じ部分の説明は省略する。
【０７４９】
本発明の一実施例において、フラグメントヘッダは該当パケットペイロードに含まれたメタデータフラグメントの順番を示す情報を含む。上述した情報はｆｒａｇｍｅｎｔ  ｎｕｍｂｅｒという。放送受信装置１００はパケットペイロードに含まれたメタデータフラグメント順番情報に基づいて該当パケットが何番目のメタデータを含んでいるのかを判断する。
【０７５０】
図６６は、本発明の一実施例による放送受信装置が放送パケットを受信する動作を示す図である。
【０７５１】
放送受信装置１００の制御部１５０は図４３のＳ２０５でペイロードに含まれたデータがメディアデータではないと判断した場合、一つの伝送パケットに全体のメタデータが含まれているのか否かを判断するＳ３０１。詳しくは、制御部１０５はペイロードヘッダ情報からペイロードに含まれたデータがメディアデータではなくメタデータであることを判断する。そして、制御部１５０は該当メタデータの全体が一つの伝送パケットに全て含まれて伝送されたのか否かを判断する。上述したように一つの伝送パケットに一つまたは複数の互いに異なるメタデータが含まれる。または、一つのメタデータが分けられて複数の互いに異なる伝送パケットに含まれる。
【０７５２】
本発明の一実施例において、放送受信装置１００の制御部１５０が一つの伝送パケットに全体のメタデータが含まれていると判断した場合、制御部１５０は一つのパケットペイロードからメタデータを抽出するＳ３０３。詳しくは、制御部１５０はペイロードヘッダを抽出し、抽出したペイロードに基づいてメタデータを抽出する。一実施例において、制御部１５０は一つのパケットペイロードから一つのメタデータを抽出する。他の実施例において、制御部１５０は一つのパケットペイロードから複数のメタデータを抽出してもよい。本発明のまた他の実施例において、放送受信装置１００の制御部１５０が一つのメタデータが複数の伝送パケットに分けられて含まれていると判断することがある。この場合、制御部１５０は複数のパケットペイロードからメタデータを抽出するＳ３０５。具体的な実施例において、一つのメタデータが複数の伝送パケットに分けられてパケット化される。放送受信装置１００の制御部１５０はパケットペイロードからメタデータシグナリングデータを取得する。そして、制御部１５０は取得したシグナリングデータに基づいて複数のパケットペイロードからメタデータを抽出する。
【０７５３】
放送受信装置１００の制御部１５０は抽出したメタデータに基づいてコンテンツを提供するＳ３０７。具体的な一実施例において、制御部１５０はメタデータからコンテンツの再生またはデコーティング時間情報を取得する。また他の実施例において、制御部１５０はメタデータからコンテンツを説明する情報を取得してもよい。
【０７５４】
図６７は、放送網を介してはＲＴＰプロトコルを利用してビデオストリームを伝送し、インターネット網を介してはファイルフォーマットベースのメディアデータを利用してビデオストリームを伝送する場合を示す図である。この場合、放送受信装置１００はタイムライン関連メタデータを含むＲＴＰパケット或いはＩＰ／ＵＤＰパケットを受信した後、ＲＴＰプロトコルベースのオーディオストリームとＤＡＳＨベースのビデオストリーム間のタイムラインをマッチングして関連するストリーム間のデコーディング及び再生を可能にする。
【０７５５】
上述したように、従来の放送伝送装置は伝送パケットに含まれたデータ（またはオブジェクト）の再生に関する時間情報をペイロードに載せて伝送していた。または放送伝送装置は時間情報を伝送するための別途のシグナリングを伝送していた。従来のような方法の場合、別途の伝送パケットまたはパケットペイロードに時間情報を載せるためパケットヘッダの容量または伝送パケットの容量が相対的に小さくなる長所があった。しかし、従来の方法の場合、伝送しようとするデータと別途のパケットで時間情報を伝送するため正確で迅速な同期の観点では効率が落ちることがあった。
【０７５６】
一方、本発明の実施例ではリアルタイムのコンテンツをサポートするための伝送パケットのパケットヘッダにパケットデコーティングまたは再生に関する時間情報を含ませる。よって、該当パケットの時間情報が該当パケットのヘッダに含まれているため、従来の方法に比べ相対的に正確で迅速な同期化が可能になる。特に、本発明の一実施例では上述したデコーディングまたは再生に関する時間情報をパケットヘッダ内の拡張されたヘッダ（Ｅｘｔｅｎｄｅｄ  Ｈｅａｄｅｒ）に設定して伝送パケットをパケット化する内容を提案する。ここで、拡張されたヘッダは必須ではないが、容量変換が可能な選択的なヘッダフィールドを含むパケットヘッダの一部であってもよい。また、伝送パケットはオブジェクトに基づいて生成され、よって、オブジェクトは伝送パケットを介して伝送しようとする対象になり得る。オブジェクトはセッションに含まれて伝送されてもよい。
【０７５７】
図６８は、本発明の一実施例による伝送パケットの構成を示す図である。図６８に示した伝送パケットは信頼性のあるデータ伝送をサポートする伝送プロトコルを利用する。具体的な実施例において、信頼性のあるデータ伝送プロトコルは非同期階層化コーディング（ＡＬＣ）である。他の実施例において、信頼性のあるデータ伝送プロトコルは階層化コーディング伝送（ＬＣＴ）である。
【０７５８】
本発明の一実施例によるパケットヘッダは、パケットのバージョン情報を含む。詳しくは、該当伝送プロトコルを利用する伝送パケットのバージョン情報を含む。具体的な実施例において、上述した情報はＶフィールドである。また、Ｖフィールドは４ビットである。
【０７５９】
また、本発明の一実施例によるパケットヘッダは、輻輳制御（ｃｏｎｇｅｓｔｉｏｎ  ｃｏｎｔｒｏｌ）のための情報の長さに関する情報を含む。詳しくは、輻輳制御のための情報の長さと輻輳制御のための情報の長さの基本単位にかけられる関連する倍数情報を含む。
【０７６０】
具体的な実施例において、上述した情報はＣフィールドである。一実施例においてＣフィールドは０ｘ００に設定されるが、この場合、輻輳制御のための情報の長さが３２ビットであることを示す。他の実施例においてＣフィールドは０ｘ０１に設定されるが、この場合、輻輳制御のための情報の長さが６４ビットである。また他の実施例においてＣフィールドは０ｘ０２に設定されるが、この場合、輻輳制御のための情報の長さが９６ビットである。更に他の実施例においてＣフィールドは０ｘ０３に設定されるが、この場合、輻輳制御のための情報の長さが１２８ビットである。Ｃフィールドは２ビットである。
【０７６１】
また、本発明の一実施例によるパケットヘッダはプロトコルに特化した情報を含む。具体的な実施例において、上述した情報はＰＳＩフィールドである。また、ＰＳＩフィールドは２ビットである。
【０７６２】
また、本発明の一実施例によるパケットヘッダは伝送セッションの識別情報を示すフィールドの長さに関する情報を含む。詳しくは、伝送セッションの識別情報を示すフィールドの倍数情報を含む。上述した情報はＳフィールドという。Ｓフィールドは１ビットである。
【０７６３】
また、本発明の一実施例によるパケットヘッダは伝送オブジェクトの識別情報を示すフィールドの長さに関する情報を含む。詳しくは、伝送オブジェクトの識別情報を示すフィールドの基本長さにかけられる倍数情報を含む。上述した情報はＯフィールドという。Ｏフィールドは１２ビットである。
【０７６４】
また、本発明の一実施例によるパケットヘッダは伝送セッションの識別情報を示すフィールドの長さに関する追加の情報を含む。そして、パケットヘッダは伝送オブジェクトの識別情報を示すフィールドの長さに関する追加の情報を含む。追加の情報はハーフワード（ｈａｌｆ−ｗｏｒｄ）の追加可否情報である。伝送パケットの識別情報を示すフィールド及び伝送オブジェクトの識別情報を示すフィールドは存在すべきであるため、ＳフィールドとＨフィールドまたはＯフィールドとＨフィールドは同時に０（Ｚｅｒｏ）を示すことができない。
【０７６５】
また、本発明の一実施例によるパケットヘッダは、セッションが終了されるか終了が迫ることを示す情報を含む。上述した情報をＡフィールドという。具体的な実施例において、Ａフィールドがセッションの終了または終了の切迫を示せば１に設定される。よって、通常Ａフィールドは０に設定される。放送伝送装置がＡフィールドを１に設定する場合、セッションを介して最後のパケットが伝送されていることを示す。Ａフィールドが１に設定されると、放送伝送装置は該当パケットに続く全てのパケットの伝送が終了されるまでＡフィールドを１に維持すべきである。また、放送受信装置はＡフィールドが１に設定される場合、放送伝送装置がセッションを介したパケット伝送をもうすぐ中断することを認識する。つまり、放送受信装置はＡフィールドが１に設定されるとセッションを介してそれ以上のパケット伝送はないと認識する。一実施例において、Ａフィールドは１ビットである。
【０７６６】
また、本発明の一実施例によるパケットヘッダは、オブジェクトの伝送が終了されるか終了が迫ることを示す情報を含む。上述した情報をＢフィールドという。具体的な実施例において、放送伝送装置はオブジェクトの伝送終了が迫ればＢフィールドは１に設定される。よって、通常Ｂフィールドは０に設定される。伝送オブジェクトを識別する情報が伝送パケットに存在しなければＢフィールドは１に設定される。そして、アウト・オブ・バンド（ｏｕｔ−ｏｆ−ｂａｎｄ）情報によって識別されたオブジェクト伝送の終了が迫ることを示す。また、Ｂフィールドはオブジェクトのための最後のパケットが伝送されれば１に設定される。また、Ｂフィールドはオブジェクトのための最後のパケットが伝送されれば１に設定される。放送伝送装置は特定オブジェクトのためのパケットのフィールドが１に設定されると、該当パケットに続く全てのパケットの伝送が終了されるまでＢフィールドを１に設定すべきである。放送受信装置１００はＢフィールドが１に設定されると、放送伝送装置がオブジェクトのためのパケットの伝送をもうすぐ中断することを認識する。つまり、放送受信装置１００は１に設定されたＢフィールドからセッションを介したそれ以上のオブジェクトの伝送はないと認識する。一実施例において、Ｂフィールドは１ビットである。
【０７６７】
また、本発明の一実施例によるパケットヘッダは、ヘッダの全長を示す情報を含む。上述した情報をＨＤＲ＿ＬＥＮフィールドという。ＨＤＲ＿ＬＥＮフィールドは３２の倍数ビットである。具体的な実施例において、ＨＤＲ＿ＬＥＮフィールドが５に設定されればパケットヘッダの全長は３２の５倍の数である１６０ビットである。また、ＨＤＲ＿ＬＥＮフィールドは８ビットである。
【０７６８】
また、本発明の一実施例によるパケットヘッダは、対応するパケットに含まれたペイロードのエンコーディングまたはデコーディングに関する情報を含む。上述した情報をＣｏｄｅｐｏｉｎｔフィールドという。一実施例において、Ｃｏｄｅｐｏｉｎｔフィールドは８ビットである。
【０７６９】
また、本発明の一実施例によるパケットヘッダは、ヘッダの輻輳を制御するための情報を含む。上述した情報をＣｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ（以下、ＣＣＩ）フィールドという。具体的な実施例において、ＣＣＩフィールドはＣｕｒｒｅｎｔ  ｔｉｍｅ  ｓｌｏｔ  ｉｎｄｅｘ（ＣＴＳＩ）フィールド、ｃｈａｎｎｅｌ  ｎｕｍｂｅｒフィールド及びｐａｃｋｅｔ  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒフィールドのうち少なくともいずれか一つを含む。
【０７７０】
また、本発明の一実施例によるパケットヘッダは、伝送セッションを識別するための情報を含む。上述した情報は伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ（以下、ＴＳＩ））である。また、ＴＳＩ情報を含むパケットヘッダ内のフィールドをＴＳＩフィールドという。
【０７７１】
また、本発明の一実施例によるパケットヘッダは、伝送セッションを介して伝送されるオブジェクトを識別するための情報を含む。上述した情報は伝送オブジェクト識別子（Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ（以下、ＴＯＩ））である。また、ＴＯＩ情報を含むパケットヘッダ内のフィールドをＴＯＩフィールドという。
【０７７２】
また、本発明の一実施例によるパケットヘッダは、追加の情報を伝送するための情報を含む。上述した情報をＨｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎフィールドという。一実施例において、追加の情報は伝送オブジェクトの再生に関する時間情報である。他の実施例において、追加の情報は伝送オブジェクトのデコーディングに関する時間情報である。
【０７７３】
また、本発明の一実施例による伝送パケットはペイロード識別情報を含む。一実施例において、識別情報はＦｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ（ＦＥＣ）  ｓｃｈｅｍｅに関するペイロード識別情報である。ここで、ＦＥＣはＲＦＣ  ５０１９に定義されているペイロードフォーマットのあるタイプである。ＦＥＣはＲＴＰまたはＳＲＴＰで使用される。上述した情報はＦＥＣ  Ｐａｙｌｏａｄ  ＩＤフィールドという。
【０７７４】
一実施例において、ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤフィールドはオブジェクトのソースブロックを識別するための情報を含む。上述した情報はＳｏｕｒｃｅ  ｂｌｏｃｋ  ｎｕｍｂｅｒフィールドという。例えば、Ｓｏｕｒｃｅ  ｂｌｏｃｋ  ｎｕｍｂｅｒフィールドがＮに設定されるとオブジェクト内のソースブロックは０からＮ−１にナンバリングされる。
【０７７５】
他の実施例において、ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤフィールドは特定エンコーディングシンボルを識別するための情報を含む。上述した情報はＥｎｃｏｒｄｉｎｇ  ｓｙｍｂｏｌ  ＩＤフィールドという。
【０７７６】
また、本発明の一実施例において、伝送パケットはペイロード内のデータを含む。上述したデータを含んでいるフィールドをＥｎｃｏｄｉｎｇ  ｓｙｍｂｏｌ（ｓ）フィールドという。一実施例において、放送受信装置１００はＥｎｃｏｄｉｎｇ  ｓｙｍｂｏｌ（ｓ）フィールドを抽出してオブジェクトを再構成する。詳しくは、パケットペイロードを介して伝送されるソースブロックからＥｎｃｏｄｉｎｇ  ｓｙｍｂｏｌ（ｓ）フィールド内のデータが生成される。
【０７７７】
図６９は、本発明の一実施例によるパケットヘッダの構成を示す図である。
【０７７８】
リアルタイムコンテンツの伝送をサポートするためには、放送受信装置１００が受信した伝送パケットにパケットの属性情報及びデコーディングまたは再生に関するタイミング情報が含まれることが効果的である。よって、上述した課題を解決するために、図６９に示したようにパケットヘッダが構成される。
【０７７９】
図６９のパケットヘッダは図６８のパケットヘッダと殆どの構成が同じである。よって、同じ部分の説明は省略する。
【０７８０】
本発明の一実施例によるパケットヘッダは伝送のためのオブジェクトタイプを示す情報を含む。上述した情報はｔｙｐｅフィールドという。ｔｙｐｅフィールドは２ビットである。
【０７８１】
具体的な実施例において、ｔｙｐｅフィールドは伝送のためのオブジェクトのタイプがレギュラーファイル（ｒｅｇｕｌａｒ  ｆｉｌｅ）であることを示す。ここで、レギュラーファイルはＩＳＯ  ＢＭＦＦベースのメディアファイルである。詳しくは、レギュラーファイルはメディアファイルをＩＳＯ  ＢＭＦＦ形式にエンカプセレーションしたものである。この場合、ｔｙｐｅフィールドは０１(2)に設定される。他の実施例において、ｔｙｐｅフィールドは伝送のためのオブジェクトのタイプがＨＴＴＰ  ｅｎｔｉｔｙタイプであることを示す。この場合、ｔｙｐｅフィールドは１０(2)に設定される。また他の実施例において、ｔｙｐｅフィールドは伝送のためのオブジェクトのタイプがオーディオアクセスユニット（Ａｕｄｉｏ  ａｃｃｅｓｓ  ｕｎｉｔ）またはビデオアクセスユニット（Ｖｉｄｅｏ  ａｃｃｅｓｓ  ｕｎｉｔ）であることを示す。また、ｔｙｐｅフィールドはオブジェクトのタイプがネットワーク抽象化層（ＮＡＬ）ユニットであることを示してもよい。この場合、ｔｙｐｅフィールドは１１(2)に設定される。
【０７８２】
また、本発明の一実施例によるパケットヘッダは伝送パケットが伝送オブジェクトの最初の部分または最後の部分を含んでいることを示す。伝送パケットが伝送オブジェクトの最初の部分または最後の部分を示すことを示す情報はマーカービット（ｍａｒｋｅｒ  ｂｉｔ））である。具体的な実施例において、マーカービットはＭフィールドである。詳しくは、Ｍフィールドはｔｙｐｅフィールドの値に応じて異なるように解釈される。例えば、伝送のためのオブジェクトタイプがファイルであれば該当伝送パケットがファイルの最後の部分を含んでいることを示す。ここで、最後の部分とはファイルの最後のビットを含んでいる部分である。他の例として、伝送のためのオブジェクトタイプがＡＶデータ（Ａｕｄｉｏ  ｏｒ  Ｖｉｄｅｏ）であれば該当伝送パケットがアクセスユニットの最初または最後のビットを含んでいることを示す。
【０７８３】
図７０乃至図７１は、時間情報を含む拡張されたヘッダの構成を示す図である。図７０乃至図７１に示した拡張されたヘッダは図６９に示したヘッダ拡張フィールドに含まれる。
【０７８４】
図７０に示したように、本発明の一実施例による拡張されたヘッダは拡張されたヘッダのタイプ情報を含む。上述した情報はＨＥＴ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｔｙｐｅ）フィールドという。
【０７８５】
また、一実施例による拡張されたヘッダは拡張されたヘッダの長さ情報を含む。上述した情報はＨＥＬ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｌｅｎｇｔｈ）フィールドという。
【０７８６】
また、一実施例による拡張されたヘッダは放送伝送装置の現在の時間を示す。つまり、拡張されたヘッダは放送伝送装置の該当パケットの伝送時間情報を含む。例えば、放送伝送装置はサーバである。具体的な実施例において、放送伝送装置の現在の時間を示す情報はＳｅｎｄｅｒ  Ｃｕｒｒｅｎｔ  Ｔｉｍｅ（以下、ＳＣＴ）フィールドである。
【０７８７】
また、一実施例による拡張されたヘッダはＳＣＴフィールドが６４ビットであるのか否かを示す。詳しくは、拡張されたヘッダはＳＣＴフィールドが６４ビットで構成されて拡張されたヘッダに含まれているのか否かを示す。具体的な実施例において、ＳＣＴフィールドが６４ビットであるのか否かを示す情報はＳＣＴ  Ｈｉフィールドである。
【０７８８】
また、一実施例による拡張されたヘッダはＳＣＴフィールドが３２ビットであるのか否かを示す。詳しくは、拡張されたヘッダはＳＣＴフィールドが３２ビットで構成されて拡張されたヘッダに含まれているのか否かを示す。具体的な実施例において、ＳＣＴフィールドが３２ビットであるのか否かを示す情報はＳＣＴ  Ｌｏｗフィールドである。
【０７８９】
また、一実施例による拡張されたヘッダは伝送のためのオブジェクトの予想される残余時間情報を含む。上述した情報はＥｘｐｅｃｔｅｄ  Ｒｅｓｉｄｕａｌ  Ｔｉｍｅ（以下、ＥＲＴ）フィールドという。
【０７９０】
また、一実施例による拡張されたヘッダはＥＲＴフィールドが該当パケットに存在するのか否かを示す。該当情報はＥＲＴ  ｆｌａｇフィールドである。
【０７９１】
また、一実施例による拡張されたヘッダはセッションが最後に変化した時間情報を含む。上述した情報はＳＬＣフィールドである。
【０７９２】
また、一実施例による拡張されたヘッダはＳＬＣフィールドが該当パケットに存在するのか否かを示す。該当情報はＳＬＣ  ｆｌａｇフィールドである。
【０７９３】
また、一実施例による拡張されたヘッダはＥＲＴフィールドが該当パケットに存在するのか否かを示す。該当情報はＥＲＴ  ｆｌａｇフィールドである。
【０７９４】
また、一実施例による拡張されたヘッダは放送伝送装置が利用する伝送プロトコルに応じて拡張して使用し得るフィールドを含む。該当情報はＰＩ−ｓｐｅｃｉｔｉｆ  Ｕｓｅフィールドである。
【０７９５】
図７１は、図７０の拡張されたヘッダに構成を追加した他の実施例による拡張されたヘッダを示す図である。
【０７９６】
他の実施例による拡張されたヘッダはパケットペイロードに含まれたデータのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドである。例えば、Ｔｉｍｅｓｔａｍｐフィールドはパケットペイロードに含まれたデータの最初のバイトがデコーディングされる時点に対する情報を含む。他の例として、Ｔｉｍｅｓｔａｍｐフィールドはデータの再生時点に関する情報を含む。加えて、Ｔｉｍｅｓｔａｍｐフィールドはタイムスケール情報またはタイムスケールに基づくタイミング情報を含んでもよい。ここで、タイムスケール情報は伝送オブジェクトのデコーディングまたは再生時点に対する時間を示す単位である。タイムスケールに基づいたタイミング情報である場合、放送受信装置はＴｉｍｅｓｔａｍｐフィールドの値をタイムスケールをかけてデコーディングまたは再生時点に関する情報を取得する。
【０７９７】
他の実施例による拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳ  ｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。メディアタイムは任意のメディアタイムラインによるメディア再生時間である。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。ノーマル再生タイムのフォーマットは再生開始時点から相対的に表現される再生時間であり、これは時、分、秒、秒以下の小数点単位で表現される。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ（Ｓｏｃｉｅｔｙ  ｏｆ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  ａｎｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｇｉｎｅｅｒｓ）  ｔｉｍｅ  ｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。詳しくは、ＳＭＰＴＥタイムコードはＳＭＰＴＥでビデオの個別的なフレームラベリングのために定義した時間情報形式である。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚベースのタイミング情報であることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０５に設定される。
【０７９８】
また他の実施例による拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドの構成を示す。タイミング情報の構成を示す情報をＴＳ  ｖｅｒｓｉｏｎフィールドという。例えば、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは１に設定される。
【０７９９】
図７２乃至図７５は、本発明の一実施例による拡張されたヘッダの構成を示す図である。詳しくは、図７２乃至図７５に示した拡張されたヘッダ構造は伝送のためのオブジェクトタイプ情報及びタイミング情報のうち少なくとも一つを含む。また、該当拡張されたヘッダ構造は上述した拡張されたヘッダフィールドに含まれる。また、コンテンツを伝送するパケットヘッダの一部として称される。
【０８００】
図７２に示したように、本発明の他の実施例による拡張されたヘッダの構造（ＥＸＴ＿ＯＢＪ＿ＩＮＦＯ）はヘッダ拡張部分のタイプ情報を含む。上述したタイプ情報はＨＥＴフィールドという。また、拡張されたヘッダ構造は拡張部分の長さ情報を含む。上述した長さ情報はＨＥＬフィールドという。また、拡張されたヘッダ構造は伝送オブジェクトのタイプ情報を含む。上述したオブジェクトタイプ情報はＯｂｊｅｃｔ  ｔｙｐｅフィールドという。
【０８０１】
具体的な実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがレギュラーファイルのタイプであることを示す。ここで、レギュラーファイルはＩＳＯ  ＢＭＦＦベースのメディアファイルである。詳しくは、レギュラーファイルはメディアファイルをＩＳＯ  ＢＭＦＦ形式にエンカプセレーションしたものである。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０１に設定される。他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがＨＴＴＰ  ｅｎｔｉｔｙタイプであることを示す。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０２に設定される。また他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがオーディオデータタイプであることを示す。Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがＡＡＣをベースにするオーディオデータタイプであることを示す。この際、ＡＡＣに基づくオーディオデータタイプはＡＡＣにエンコーディングされたオーディオデータである。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０３に設定される。更に他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがビデオデータタイプであることを示す。詳しくは、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドが伝送オブジェクトがＨ．２６４タイプであることを示す。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０４に設定される。更に他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがＨＥＶＣベースのビデオデータタイプであることを示す。この際、ＨＥＶＣベースのビデオタイプはＨＥＶＣにエンコーディングされたビデオデータである。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０５に設定される。更に他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがＩＳＯ  ＢＭＦＦベースのファイルタイプであることを示す。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０６に設定される。更に他の実施例において、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは伝送オブジェクトがメタデータであることを示す。この場合、Ｏｂｊｅｃｔ  ｔｙｐｅフィールドは０ｘ０７に設定される。
【０８０２】
また、本発明の他の実施例による拡張されたヘッダの構造（ＥＸＴ＿ＯＢＪ＿ＩＮＦＯ）はヘッダ伝送パケットが伝送オブジェクトの最初の部分または最後の部分を含むことを示す。伝送パケットが伝送オブジェクトの最初の部分または最後の部分を示す情報はマーカービットである。具体的な実施例において、マーカービットはＭフィールドである。詳しくは、ＭフィールドはＯｂｊｅｃｔ  ｔｙｐｅフィールドの値に応じて異なるように解釈される。例えば、伝送のためのオブジェクトタイプがファイルであれば該当伝送パケットがファイルの最後の部分を含んでいることを示す。ここで、最後の部分とはファイルの最後のビットを含んでいる部分である。他の例として、伝送のためのオブジェクトタイプがＡＶデータであれば該当伝送パケットがアクセスユニットの最初または最後のビットを含んでいることを示す。
【０８０３】
また、本発明の他の実施例による拡張されたヘッダの構造（ＥＸＴ＿ＯＢＪ＿ＩＮＦＯ）はパケットペイロードに含まれたデータのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドである。例えば、Ｔｉｍｅｓｔａｍｐフィールドはパケットペイロードに含まれたデータの最初のバイトがデコーディングされる時点に対する情報を含む。他の例として、Ｔｉｍｅｓｔａｍｐフィールドはデータの再生時点に関する情報を含む。加えて、Ｔｉｍｅｓｔａｍｐフィールドはタイムスケール情報またはタイムスケールに基づくタイミング情報を含んでもよい。ここで、タイムスケール情報は伝送オブジェクトのデコーディングまたは再生時点に対する時間を示す単位である。タイムスケールに基づいたタイミング情報である場合、放送受信装置はＴｉｍｅｓｔａｍｐフィールドの値をタイムスケールをかけてデコーディングまたは再生時点に関する情報を取得する。
【０８０４】
図７３は、図７２の拡張されたヘッダの構成に一部の構成が追加された他の実施例を示す図である。
【０８０５】
図７３に示したように、本発明の他の実施例による拡張されたヘッダの構造は該当拡張されたヘッダの構造にＴｉｍｅｓｔａｍｐフィールドが存在するのか否かを示す。Ｔｉｍｅｓｔａｍｐフィールドが存在するかを示す情報はＴＳ  ｆｌａｇフィールドという。具体的な実施例において、ＴＳ  ｆｌａｇフィールドが１に設定されればＴＳ  ｆｌａｇフィールドは該当ヘッダ構造にＴｉｍｅｓｔａｍｐフィールドが存在することを示す。
【０８０６】
また、本発明の他の実施例による拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳ  ｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。メディアタイムは任意のメディアタイムラインによるメディア再生時間である。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。ノーマル再生タイムのフォーマットは再生開始時点から相対的に表現される再生時間であり、これは時、分、秒、秒以下の小数点単位で表現される。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚベースのタイミング情報であることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０５に設定される。
【０８０７】
また、本発明のまた他の実施例による拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドの構成を示す。詳しくは、拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドに含まれたオブジェクトの再生またはデコーディングに関するタイミング情報の構成を示す。上述した情報をＴＳ  ｖｅｒｓｉｏｎフィールドという。例えば、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは１に設定される。
【０８０８】
図７４は、図７２の拡張されたヘッダの構成に一部の構成が追加されたまた他の実施例を示す図である。
【０８０９】
図７４に示したように、本発明のまた他の実施例による拡張されたヘッダの構造は伝送オブジェクトに関する付加情報を含む。具体的な実施例において、拡張されたヘッダの構造はオブジェクトの位置情報を含む。例えば、オブジェクトの位置情報はＩＳＯ  ＢＭＦＦをベースにするセグメントのＵＲＬ情報を示す。詳しくは、オブジェクトの位置情報はＩＳＯ  ＢＭＦＦをベースにするセグメントをダウンロード可能なＵＲＬ情報を示す。この場合、伝送オブジェクトに関する付加情報はＥｘｔｅｎｓｉｏｎフィールドである。
【０８１０】
また。本発明の他の実施例による拡張されたヘッダの構造は該当拡張されたヘッダの構造にＥｘｔｅｎｓｉｏｎフィールドが存在するのか否かを示す。この場合、Ｅｘｔｅｎｓｉｏｎフィールドが存在するのか否かを示す情報はＥｘｔ  Ｆｌａｇフィールドという。
【０８１１】
図７５は、図７２の新たなヘッダの拡張構造がパケットヘッダの一部に使用された一実施例を示す図である。図７５に示したように、パケットヘッダの一部が伝送オブジェクトのタイミング情報を含む。伝送オブジェクトのタイミング情報を含むパケットヘッダの一部はＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドである。
【０８１２】
ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはパケットペイロードに含まれたデータのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドである。例えば、Ｔｉｍｅｓｔａｍｐフィールドはパケットペイロードに含まれたデータの最初のバイトがデコーディングされる時点に対する情報を含む。他の例として、Ｔｉｍｅｓｔａｍｐフィールドはデータの再生時点に関する情報を含む。加えて、Ｔｉｍｅｓｔａｍｐフィールドはタイムスケール情報またはタイムスケールに基づくタイミング情報を含んでもよい。ここで、タイムスケール情報は伝送オブジェクトのデコーディングまたは再生時点に対する時間を示す単位である。タイムスケールに基づいたタイミング情報である場合、放送受信装置はＴｉｍｅｓｔａｍｐフィールドの値にタイムスケールをかけてデコーディングまたは再生時点に関する情報を取得する。
【０８１３】
また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳ  ｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚベースのタイミング情報であることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０５に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＧＰＳ  ｔｉｍｅフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０６に設定される。
【０８１４】
また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはＴｉｍｅｓｔａｍｐフィールドのフォーマットの構成を示す。拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドのフォーマットに含まれたオブジェクト再生またはデコーディングに関するタイミング情報の構成を示す。上述した情報をＴＳ  ｖｅｒｓｉｏｎフィールドという。例えば、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは１に設定される。
【０８１５】
また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはタイミング情報に関する追加的な情報を含む。例えば、マッピングされるタイミング情報に関するデータ情報が含まれる。タイミング情報に関する追加の情報はＥｘｔｅｎｓｉｏｎフィールドという。
【０８１６】
また、ＥＸＴ＿ＭＥＤＩＡ＿ＴＩＭＥフィールドはＥｘｔｅｎｓｉｏｎフィールドの構成に関する情報を含む。詳しくは、Ｅｘｔｅｎｓｉｏｎフィールドには多様な情報が含まれ、多様な情報ごとにフラッグが集合を成している。この場合、フラッグの集合をＥｘｔ  ｆｌａｇフィールドという。
【０８１７】
放送受信装置１００が放送受信部を介して受信した伝送オブジェクトが他の形式または他の基準時間を有するタイミング情報と同期化する必要がある。詳しくは、放送受信装置１００は伝送オブジェクトのタイミング情報とは異なる形式または基準時間を有する同期化のための基準になる基本タイムラインに伝送オブジェクトのタイミング情報を同期化すべきである。一実施例において、同期化するタイミング情報は伝送オブジェクトの再生タイミングである。他の実施例において、同期化するタイミング情報は伝送オブジェクトのデコーディングタイミングである。この場合、放送伝送装置は他のタイミング情報と伝送オブジェクトのタイミング情報間のマッピング関係に関する情報を放送受信装置１００に伝送すべきである。上述した課題を解決するための本発明の一実施例において、上述したｔｉｍｅｌｉｎｅ＿ｃｏｍｐｏｎｅｎｔ＿ＡＵを含むメタデータを一つの伝送オブジェクトにして伝送する。
【０８１８】
上述した課題を解決するための他の実施例において、上述した拡張されたヘッダは伝送オブジェクトのタイミング情報とは異なる別途のマッピング情報を含む。詳しくは、拡張されたヘッダ（ＥＸＴ＿ＴＩＭＥ＿ＭＡＰ）は伝送オブジェクトのタイムスタンプを他のタイムラインにマッピングするための情報を含む。例えば、放送受信装置１００は制御部１５０を介して上述した情報を利用してパケットペイロードの再生時間をＧＰＳタイムにマッピングする。この場合、ＧＰＳタイムが基本タイムラインである。
【０８１９】
図７６は、本発明の一実施例による他のタイミング情報とのマッピングをサポートするための拡張されたヘッダの構成を示す図である。
【０８２０】
図７６に示したように、拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドのフォーマット情報を含む。上述した情報はＴＳ  ｆｏｒｍａｔフィールドである。具体的な実施例において、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がメディアタイムのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がノーマル再生タイムのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報が９０ＫＨｚベースのタイミング情報であることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０５に設定される。また、ＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＧＰＳ  ｔｉｍｅフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０６に設定される。
【０８２１】
また、拡張されたヘッダはＴｉｍｅｓｔａｍｐフィールドのバージョンまたは構成を示す。拡張されたヘッダの構造はＴｉｍｅｓｔａｍｐフィールドのフォーマットに含まれたオブジェクト再生またはデコーディングに関するタイミング情報の構成を示す。上述した情報をＴＳ  ｖｅｒｓｉｏｎフィールドという。例えば、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが３２ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＴＳ  ｖｅｒｓｉｏｎフィールドはｔｉｍｅｓｔａｍｐフィールドが６４ビットであることを示す。この場合、ＴＳ  ｖｅｒｓｉｏｎフィールドは１に設定される。
【０８２２】
また、拡張されたヘッダは伝送オブジェクトのタイムスタンプがマッピングされるタイムラインのタイミング情報が存在するのか否かを示す。この場合、存在を示す情報はＯＴＳ  ｆｌａｇフィールドという。具体的な一実施例において、ＯＴＳ  ｆｌａｇフィールドが１に設定された場合、伝送オブジェクトのタイムスタンプがマッピングされるタイムラインのタイミング情報が存在することを示す。
【０８２３】
また、拡張されたヘッダは伝送オブジェクトのタイムスタンプがマッピングされるタイムラインのスタンプフォーマットを示す。詳しくは、伝送オブジェクトのタイムスタンプはオブジェクトの再生時間及びデコーディング時間のうち少なくとも一つである。また、伝送オブジェクトがタイムスタンプとマッピングされるタイムラインは基本タイムラインである。ここで、基本タイムラインは複数の互いに異なるタイムライン間の同期化のために必要な基準タイムラインである。
【０８２４】
上述した情報はＯＴＳ  ｆｏｒｍａｔフィールドである。具体的な実施例において、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがメディアタイムのフォーマットであることを示す。この場合、ＯＴＳ  ｆｏｒｍａｔフィールドは０ｘ０１に設定される。また、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれたタイミング情報がＮＴＰのフォーマットであることを示す。この場合、ＴＳ  ｆｏｒｍａｔフィールドは０ｘ０２に設定される。また、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがノーマル再生タイムのフォーマットであることを示す。この場合、ＯＴＳ  ｆｏｒｍａｔフィールドは０ｘ０３に設定される。また、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅのフォーマットであることを示す。ＳＭＰＴＥ  ｔｉｍｅ  ｃｏｄｅはＳＭＰＴＥで定義したタイムコードである。この場合、ＯＴＳ  ｆｏｒｍａｔフィールドは０ｘ０４に設定される。また、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプが９０ＫＨｚベースのタイミング情報であることを示す。この場合、ＯＴＳ  ｆｏｒｍａｔフィールドは０ｘ０５に設定される。また、ＯＴＳ  ｆｏｒｍａｔフィールドは伝送パケットに含まれた伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプがＧＰＳ  ｔｉｍｅフォーマットであることを示す。この場合、ＯＴＳ  ｆｏｒｍａｔフィールドは０ｘ０６に設定される。
【０８２５】
また、拡張されたヘッダはオブジェクトのタイムスタンプと伝送オブジェクトのタイムスタンプとマッピングされるタイムラインのタイムスタンプのバージョンまたは構成を示す。詳しくは、伝送オブジェクトのタイムスタンプはオブジェクト再生時間またはデコーディング時間のうち少なくとも一つである。また、伝送オブジェクトのタイムスタンプとマッピングされるタイムラインは基本タイムラインである。ここで、基本タイムラインは複数の互いに異なるタイムライン間の同期化のために必要な基準タイムラインである。
【０８２６】
この場合、伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプの構成またはバージョンを示す情報をＯＴＳ  ｖｅｒｓｉｏｎフィールドという。例えば、ＯＴＳ  ｖｅｒｓｉｏｎフィールドは伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプが３２ビットであることを示す。この場合、ＯＴＳ  ｖｅｒｓｉｏｎフィールドは０に設定される。他の例として、ＯＴＳ  ｖｅｒｓｉｏｎフィールドは伝送オブジェクトのタイムスタンプとマッピングされるタイムスタンプが６４ビットであることを示す。この場合、ＯＴＳ  ｖｅｒｓｉｏｎフィールドは１に設定される。
【０８２７】
また、拡張されたヘッダは位置情報を含むのか否かを示す。この場合、位置情報を含むのか否かを示す情報はＬｏｃａｔｉｏｎ  ｆｌａｇフィールドである。例えば、Ｌｏｃａｔｉｏｎ  ｆｌａｇフィールドが１に設定されれば該当拡張されたヘッダに位置情報が含まれていることを示す。
【０８２８】
また、拡張されたヘッダは伝送オブジェクトのタイムスタンプ及び伝送オブジェクトのタイムスタンプと伝送オブジェクトのタイムスタンプとマッピングされるタイムラインのタイミング情報を含む。上述した情報はＴｉｍｅｓｔａｍｐフィールドという。
【０８２９】
また、拡張されたヘッダは拡張されたヘッダのタイムスタンプと伝送オブジェクトのタイムスタンプとマッピングされる伝送オブジェクトに関するタイミング情報を含む。上述した情報はＯｒｉｇｉｎ  ｔｉｍｅ  ｓｔａｍｐフィールドという。
【０８３０】
また、拡張されたヘッダは伝送オブジェクトのタイムスタンプとマッピングされるタイムラインに関するデータの位置情報を含む。上述した情報はＬｏｃａｔｉｏｎフィールドという。一実施例において、特定ＩＳＯ  ＢＭＦＦベースのデータセグメントのタイムラインとマッピングが必要であればＬｏｃａｔｉｏｎフィールドは該当セグメントのＵＲＬを含む。
【０８３１】
図７７は、本発明の一実施例による放送伝送装置の動作方法を示す図である。
【０８３２】
放送伝送装置は制御部を介して伝送のためのオブジェクトを取得するＳ４０１。一実施例において、オブジェクトはＡＶコンテンツである。他の実施例において、オブジェクトはＡＶコンテンツに関する向上されたデータである。
【０８３３】
放送伝送装置は制御部を介してオブジェクトの時間情報及びフォーマット情報を取得するＳ４０３。一実施例において、時間情報は伝送オブジェクトのタイムスタンプである。他の実施例において、時間情報は伝送オブジェクトのタイムスタンプとマッピングされるタイムラインのタイミング情報である。また他の実施例において、時間情報は拡張されたヘッダ構造のタイムスタンプである。更に他の実施例において、時間情報は拡張されたヘッダ構造のタイムスタンプとマッピングされる伝送オブジェクトのタイミング情報である。また、フォーマット情報はレギュラーファイル、ＨＴＴＰエンティティ及びオーディオまたはビデオアクセスユニットのうち少なくとも一つである。
【０８３４】
詳しくは、伝送オブジェクトのタイムスタンプはオブジェクトの再生時間及びデコーディング時間のうち少なくとも一つである。また、伝送オブジェクトがタイムスタンプとマッピングされるタイムラインは基本タイムラインである。ここで、基本タイムラインは複数の互いに異なるタイムライン間の同期化のために必要な基準タイムラインである。例えば、基本タイムラインがＧＰＳ  ｔｉｍｅであってもよく、伝送オブジェクトをＧＰＳ  ｔｉｍｅと同期化するための情報が上述した拡張されたヘッダに含まれてもよい。
【０８３５】
放送伝送装置は制御部を介して取得した時間情報及びフォーマット情報をパケットヘッダに設定して伝送パケットをパケット化するＳ４０５。詳しくは、放送伝送装置の制御部は取得した時間情報を含むパケットヘッダ及びデータを含むパケットデータを伝送プロトコルに応じてパケット化する。他の実施例において、放送伝送装置は制御部を介してパケットヘッダに選択的に含まれる拡張されたヘッダに時間情報及びフォーマット情報を設定する。
【０８３６】
詳しくは、時間情報はオブジェクトの再生時間に関する情報である。再生時間に関する情報は伝送オブジェクトの再生時点（タイミング情報）及びデコーディング時点（タイミング情報）のうち少なくとも一つである。他の実施例において、追加の情報は伝送オブジェクトのタイプ情報である。放送伝送装置は一般的なパケットヘッダに、拡張されたヘッダがパケットヘッダに存在するか、拡張されたヘッダの長さ及び拡張されたヘッダのタイプ情報のうち少なくとも一つを設定する。
【０８３７】
放送伝送装置は伝送部を介してパケット化された伝送パケットを伝送するＳ４０７。伝送部は伝送パケットを地上波放送網及びインターネット網のうち少なくとも一つを介して伝送する。
【０８３８】
図７８は、本発明の一実施例による放送受信装置の動作方法を示す図である。
【０８３９】
放送受信装置１００は放送受信部１１０を介して伝送パケットを受信するＳ４１１。図７７において、説明のように伝送パケットはパケットヘッダ及びパケットペイロードを含むが、パケットヘッダは拡張されたヘッダを選択的に含む。
【０８４０】
放送受信装置１００の制御部１５０は受信した伝送パケットからパケットヘッダ及び拡張されたヘッダを抽出するＳ４１２。具体的な実施例において、制御部１５０は伝送パケットに含まれたパケットヘッダを抽出する。また、パケットヘッダに選択的に含まれる拡張されたヘッダをパケットヘッダから抽出する。
【０８４１】
放送受信装置１００の制御部１５０はパケットヘッダに基づいて伝送オブジェクトに関する時間情報及び伝送オブジェクトのフォーマット情報のうち少なくとも一つを取得するＳ４１３。他の実施例において、制御部１５０はパケットヘッダに選択的に含まれる拡張されたヘッダから前記時間情報及びフォーマット情報のうち少なくとも一つを取得する。具体的な実施例において、制御部１５０は拡張されたヘッダに基づいて伝送オブジェクトのタイムスタンプを取得する。また、制御部１５０は伝送オブジェクトのフォーマット情報を取得する。伝送オブジェクトのフォーマット情報はレギュラーファイル、ＨＴＴＰエンティティ及びオーディオまたはビデオアクセスユニットのうち少なくとも一つを示す。ここで、レギュラーファイルとはＩＳＯ  ＢＭＦＦベースのメディアファイルである。
【０８４２】
放送受信装置１００の制御部１５０はパケットヘッダから他の時間情報とマッピングするための情報を取得できるのか否かを判断するＳ４１４。詳しくは、制御部１５０は該当伝送オブジェクトのための時間情報とマッピングされる他の時間情報がパケットヘッダに存在するのか否かを判断する。他の実施例において、制御部１５０はパケットヘッダに選択的に含まれる拡張されたヘッダから抽出された特定情報に基づいて判断する。
【０８４３】
一実施例において、制御部１５０がパケットヘッダから他の時間情報とマッピングするための情報を取得できると判断した場合、制御部１５０はパケットヘッダからマッピングのための情報を取得するＳ４１５。ここで、他の時間情報は上述した基本タイムラインのタイミング情報である。また、タイミング情報は伝送オブジェクトの再生タイミング情報及びデコーディングタイミング情報のうち少なくとも一つを含む。具体的な実施例において、制御部１５０はパケットヘッダに基づいて伝送オブジェクトとマッピングされるタイムラインのタイミング情報を取得する。他の実施例において、制御部１５０はパケットヘッダに基づいてパケットヘッダのタイムスタンプとマッピングされる伝送オブジェクトのタイミング情報を取得する。また、制御部１５０はパケットヘッダに基づいて伝送オブジェクトとマッピングされるデータの位置情報を取得する。また他の実施例において、制御部１５０はパケットヘッダに選択的に含まれる拡張されたヘッダからマッピングのための情報を取得してもよい。
【０８４４】
放送受信装置１００の制御部１５０は取得した時間情報に基づいて伝送オブジェクトを出力するＳ４１６。一実施例において、制御部１５０が他の時間情報とマッピング情報を取得できなかった場合、該当伝送オブジェクトのタイムスタンプに基づいてオブジェクトを出力する。他の実施例において、制御部１５０が他の時間情報とマッピング情報を取得した場合、該当マッピング情報及びオブジェクトのタイムスタンプに基づいてオブジェクトを出力する。
【０８４５】
図７９は、伝送パケットの構成に対する情報を含むパケットヘッダの構成を示す図である。
【０８４６】
本発明の一実施例によるパケットヘッダは全体の伝送オブジェクトのうち最初または最後の部分のデータがパケットペイロードに含まれていることを示す。この場合、最初または最後の部分のデータが含まれていることを示す情報はマーカービットである。また、マーカービットはＭフィールドである。Ｍフィールドは１ビットである。
【０８４７】
また、本発明の一実施例によるパケットヘッダは該当伝送パケットの構成に関する情報を含む。この場合、伝送パケットの構成に関する情報はＴｙｐｅフィールドである。Ｔｙｐｅフィールドは２ビットである。
【０８４８】
他の場合、伝送パケットの構成に関する情報はＣｏｄｅｐｏｉｎｔフィールドである。Ｃｏｄｅｐｏｉｎｔフィールドは８ビットである。
【０８４９】
具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットがレギュラーパケット構造であることを示す。詳しくは、該当パケットが図６８に示した従来の伝送パケット構造をそのまま使用していることを示す。この場合、伝送パケットはパケットヘッダ、拡張されたヘッダ、パケットペイロード識別子及びデータのうち少なくともいずれか一つを含む。また、放送伝送装置はＴｙｐｅフィールドを０ｘ００に設定する。
【０８５０】
また、具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットがペイロードを含んでいないことを示す。詳しくは、該当伝送パケットがパケットヘッダ及び拡張されたヘッダのみを含んでいることを示す。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０１に設定する。
【０８５１】
また、具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットが全体の伝送オブジェクトに対するオフセット情報を含むことを示す。ここで、オフセット情報とは該当伝送パケットのエンコーディングシンボルフィールドが含んでいるデータのオフセット情報である。つまり、オフセット情報は全体の伝送オブジェクトから該当伝送パケットの構造と構成は同じであるが、ペイロード識別子フィールドがデータオフセットフィールドに代替される。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０２に設定する。
【０８５２】
また、具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットが従来のレギュラー伝送パケットの構造とは異なる構成を含むことを示す。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０３に設定する。具体的な一実施例において、Ｔｙｐｅフィールドは該当伝送パケットがペイロード識別子フィールドを含んでいないことを示す。この場合、放送伝送装置はＴｙｐｅフィールドを０ｘ０４に設定する。
【０８５３】
図８０は、図７９の伝送パケットの構成を示す図である。図８０に示したように、Ｔｙｐｅフィールドは伝送パケットの構造を示す。しかし、図８０に示した伝送パケットに限ることはなく、必ずしも図８０に設定された値に本発明が限定されることはない。
【０８５４】
図８１は、本発明の一実施例による放送伝送装置の動作方法を示す図である。
【０８５５】
放送伝送装置は制御部を介して伝送のためのオブジェクトを取得するＳ４２１。一実施例において、伝送パケットの構造は従来のレギュラーパケット構造である。他の実施例において、伝送パケットの構造は従来のパケットヘッダ及び拡張されたヘッダのみで構成された構造である。また他の実施例において、伝送パケットの構造は従来のペイロード識別子を代替する構成を含む構造である。更に他の実施例において、伝送パケットの構造はペイロード識別子を含まない構造である。
【０８５６】
放送伝送装置は制御部を介して取得した伝送パケットの構造に基づいて、該当構造の情報を示す値をパケットヘッダに設定して伝送パケットをパケット化するＳ４２３。詳しくは、制御部は該当構造の情報をＴｙｐｅフィールドに設定する。
【０８５７】
放送伝送装置は伝送部を介してパケット化された伝送パケットを伝送するＳ４２５。一実施例において、伝送部はパケット化された伝送パケットを地上波の放送網で伝送する。他の実施例において、伝送部はパケット化された伝送パケットをインターネット網で伝送してもよい。
【０８５８】
図８２は、本発明の一実施例による放送受信装置の動作方法を示す図である。
【０８５９】
放送受信装置１００は放送受信部１１０を介して伝送パケットを受信するＳ４３１。一実施例において、放送受信部１１０は地上波放送網を介して伝送パケットを受信する。他の実施例において、ＩＰコミュニケーションユニット１３０はインターネット網を介して伝送パケットを受信する。
【０８６０】
放送受信装置１００は制御部１５０を介して受信した伝送パケットからパケットヘッダを抽出するＳ４３３。詳しくは、伝送パケットはパケットヘッダ及びパケットペイロードのうち少なくとも一つを含む。よって、制御部１５０は伝送パケットからペイロードをシグナリングするパケットヘッダを抽出する。
【０８６１】
放送受信装置１００は抽出したパケットヘッダから伝送パケットの構成情報を取得するＳ４３５。詳しくは、パケットヘッダは伝送パケットの構造を示す情報を含む。よって、放送受信装置１００は制御部１５０を介してパケットヘッダから伝送パケットの構造を示す情報を取得する。一実施例において、伝送パケットの構造は従来のレギュラー伝送パケット構造である。他の実施例において、伝送パケットの構造は従来のパケットヘッダ及び拡張されたヘッダのみを含む構造である。また他の実施例において、伝送パケットの構造はパケットペイロード識別子を代替するオフセット情報を含む構造である。更に他の実施例において、伝送パケットの構造はパケットペイロード識別子を含まない構造である。
【０８６２】
これまで実施例に説明された特徴、構造、効果などは本発明の少なくとも一つの実施例に含まれ、必ずしも一つの実施例にのみ限定されることはない。また、各実施例で例示された特徴、構造、効果などは実施例の属する技術分野の通常の知識を有する者によって他の実施例に対しても組み合わせられるか変形されて実施可能なものである。よって、このような組み合わせと変形に関する内容は本発明の範囲に含まれると解釈すべきである。
【０８６３】
これまで実施例を中心に説明したが、これは単なる例示であって本発明を限定するものではなく、本発明の属する分野の通常の知識を有する者であれば本実施例の本質的な特性を逸脱しない範囲内で前記に例示されていない様々な変形と応用が可能であることが分かる。例えば、実施例に具体的に示した各構成要素は変形して実施可能なものである。そして、このような変形と応用に関する差は添付した特許請求の範囲で規定する本発明の範囲に含まれると解釈すべきである。
【図１】
2018207499.tif 000062
【図２】
2018207499.tif 000063
【図３】
2018207499.tif 000064
【図４】
2018207499.tif 000065
【図５】
2018207499.tif 000066
【図６】
2018207499.tif 000067
【図７】
2018207499.tif 000068
【図８】
2018207499.tif 000069
【図９】
2018207499.tif 000070
【図１０】
2018207499.tif 000071
【図１１】
2018207499.tif 000072
【図１２】
2018207499.tif 000073
【図１３】
2018207499.tif 000074
【図１４】
2018207499.tif 000075
【図１５】
2018207499.tif 000076
【図１６】
2018207499.tif 000077
【図１７】
2018207499.tif 000078
【図１８】
2018207499.tif 000079
【図１９】
2018207499.tif 000080
【図２０】
2018207499.tif 000081
【図２１】
2018207499.tif 000082
【図２２】
2018207499.tif 000083
【図２３】
2018207499.tif 000084
【図２４】
2018207499.tif 000085
【図２５】
2018207499.tif 000086
【図２６】
2018207499.tif 000087
【図２７】
2018207499.tif 000088
【図２８】
2018207499.tif 000089
【図２９】
2018207499.tif 000090
【図３０】
2018207499.tif 000091
【図３１】
2018207499.tif 000092
【図３２】
2018207499.tif 000093
【図３３】
2018207499.tif 000094
【図３４】
2018207499.tif 000095
【図３５】
2018207499.tif 000096
【図３６】
2018207499.tif 000097
【図３７】
2018207499.tif 000098
【図３８】
2018207499.tif 000099
【図３９】
2018207499.tif 000100
【図４０】
2018207499.tif 000101
【図４１】
2018207499.tif 000102
【図４２】
2018207499.tif 000103
【図４３】
2018207499.tif 000104
【図４４】
2018207499.tif 000105
【図４５】
2018207499.tif 000106
【図４６】
2018207499.tif 000107
【図４７】
2018207499.tif 000108
【図４８】
2018207499.tif 000109
【図４９】
2018207499.tif 000110
【図５０】
2018207499.tif 000111
【図５１】
2018207499.tif 000112
【図５２】
2018207499.tif 000113
【図５３】
2018207499.tif 000114
【図５４】
2018207499.tif 000115
【図５５】
2018207499.tif 000116
【図５６】
2018207499.tif 000117
【図５７】
2018207499.tif 000118
【図５８】
2018207499.tif 000119
【図５９】
2018207499.tif 000120
【図６０】
2018207499.tif 000121
【図６１】
2018207499.tif 000122
【図６２】
2018207499.tif 000123
【図６３】
2018207499.tif 000124
【図６４】
2018207499.tif 000125
【図６５】
2018207499.tif 000126
【図６６】
2018207499.tif 000127
【図６７】
2018207499.tif 000128
【図６８】
2018207499.tif 000129
【図６９】
2018207499.tif 000130
【図７０】
2018207499.tif 000131
【図７１】
2018207499.tif 000132
【図７２】
2018207499.tif 000133
【図７３】
2018207499.tif 000134
【図７４】
2018207499.tif 000135
【図７５】
2018207499.tif 000136
【図７６】
2018207499.tif 000137
【図７７】
2018207499.tif 000138
【図７８】
2018207499.tif 000139
【図７９】
2018207499.tif 000140
【図８０】
2018207499.tif 000141
【図８１】
2018207499.tif 000142
【図８２】
2018207499.tif 000143
【手続補正書】
【提出日】平成30年7月23日(2018.7.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
伝送パケットを含む放送信号を受信するように構成される放送受信部と、
前記伝送パケットからパケットヘッダを抽出するように構成されるパケット処理部と、を含み、
前記伝送パケットは、伝送オブジェクトを含むパケットペイロードと、前記パケットペイロードをシグナリングするパケットヘッダとで構成され、
前記パケットヘッダは、前記パケットヘッダに含まれるフラッグ情報が特定の値に設定されるとき、リアルタイム配信をサポートするための第１拡張ヘッダを含み、
前記第１拡張ヘッダは、前記拡張ヘッダのタイプを示す値と前記伝送オブジェクトのプレゼンテーションタイムスタンプに関連する第１情報とを含み、
前記プレゼンテーションタイムスタンプは、６４ビットで表され、
前記パケットヘッダは、第２拡張ヘッダをさらに含み、
前記第２拡張ヘッダは、放送伝送装置の現在時間を示す第２情報と、前記伝送オブジェクトのための予想残り時間を示す第３情報とを含む、放送受信装置。
【請求項２】
伝送パケットを含む放送信号を受信するステップと、
前記伝送パケットからパケットヘッダを抽出するステップと、を含み、
前記伝送パケットは、伝送オブジェクトを含むパケットペイロードと、前記パケットペイロードをシグナリングするパケットヘッダとで構成され、
前記パケットヘッダは、前記パケットヘッダに含まれるフラッグ情報が特定の値に設定されるとき、リアルタイム配信をサポートするための第１拡張ヘッダを含み、
前記第１拡張ヘッダは、前記拡張ヘッダのタイプを示す値と前記伝送オブジェクトのプレゼンテーションタイムスタンプに関連する第１情報とを含み、
前記プレゼンテーションタイムスタンプは、６４ビットで表され、
前記パケットヘッダは、第２拡張ヘッダをさらに含み、
前記第２拡張ヘッダは、放送伝送装置の現在時間を示す第２情報と、前記伝送オブジェクトのための予想残り時間を示す第３情報とを含む、放送受信装置の動作方法。
【請求項３】
伝送パケットを生成するステップと、
前記伝送パケットを含む放送信号を送信するステップと、を含み、
前記伝送パケットは、伝送オブジェクトを含むパケットペイロードと、前記パケットペイロードをシグナリングするパケットヘッダとで構成され、
前記パケットヘッダは、前記パケットヘッダに含まれるフラッグ情報が特定の値に設定されるとき、リアルタイム配信をサポートするための第１拡張ヘッダを含み、
前記第１拡張ヘッダは、前記拡張ヘッダのタイプを示す値と前記伝送オブジェクトのプレゼンテーションタイムスタンプに関連する第１情報とを含み、
前記プレゼンテーションタイムスタンプは、６４ビットで表され、
前記パケットヘッダは、第２拡張ヘッダをさらに含み、
前記第２拡張ヘッダは、放送伝送装置の現在時間を示す第２情報と、前記伝送オブジェクトのための予想残り時間を示す第３情報とを含む、放送送信装置の動作方法。
【請求項４】
伝送パケットを生成するように構成される制御部と、
前記伝送パケットを含む放送信号を送信するように構成される送信部と、を含み、
前記伝送パケットは、伝送オブジェクトを含むパケットペイロードと、前記パケットペイロードをシグナリングするパケットヘッダとで構成され、
前記パケットヘッダは、前記パケットヘッダに含まれるフラッグ情報が特定の値に設定されるとき、リアルタイム配信をサポートするための第１拡張ヘッダを含み、
前記第１拡張ヘッダは、前記拡張ヘッダのタイプを示す値と前記伝送オブジェクトのプレゼンテーションタイムスタンプに関連する第１情報とを含み、
前記プレゼンテーションタイムスタンプは、６４ビットで表され、
前記パケットヘッダは、第２拡張ヘッダをさらに含み、
前記第２拡張ヘッダは、放送伝送装置の現在時間を示す第２情報と、ＦＥＣでエンコードされた伝送オブジェクトのための予想残り時間を示す第３情報とを含む、放送送信装置。