(57)【特許請求の範囲】
【請求項１】
放送信号送信方法であって、
ＲｏＨＣ（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）パケットストリームを生成するために、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットストリームに含まれるＩＰパケットのヘッダーを圧縮するステップであって、
前記ＲｏＨＣパケットストリームは、ＩＲ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ａｎｄ  Ｒｅｆｒｅｓｈ）パケットと、ＩＲ−ＤＹＮ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ａｎｄ  Ｒｅｆｒｅｓｈ−Ｄｙｎａｍｉｃ）パケットと、圧縮されたパケットとを含み、
前記ＩＲパケットは、静的フィールド及び動的フィールドを含み、
前記ＩＲ−ＤＹＮパケットは、前記動的フィールドを含む、ステップと、
前記ＩＲパケットから前記静的フィールドを抽出し、前記ＩＲパケットの残りの部分をＩＲ−ＤＹＮパケットに変換するステップと、
前記ＩＲパケットを取り替える前記変換されたＩＲ−ＤＹＮパケットを含むパケットストリームを再構成するステップと、
ヘッダーとペイロードとを含むシグナリングパケットを生成するステップであって、
前記ペイロードは、前記抽出された静的フィールドを含み、
前記ヘッダーは、前記シグナリングパケットのタイプを識別するパケットタイプフィールドと、前記ペイロードの長さを示す長さフィールドとを含み、
前記ペイロードは、前記ＲｏＨＣパケットストリームを識別するコンテキスト識別情報と、前記ＩＰパケットストリームを圧縮するために使用されたプロトコルの範囲を示すコンテキストプロファイル情報とを含み、
前記シグナリングパケットは、前記静的フィールドが前記ペイロードに含まれるか否かを示すインジケータフィールドを含む、ステップと、
第１チャネルを介して前記再構成されたパケットストリームを送信するステップと、
前記第１チャネルと区別される第２チャネルを介して前記シグナリングパケットを送信するステップと、を含む、方法。
【請求項２】
前記ＩＲパケット及び前記ＩＲ−ＤＹＮパケットから前記動的フィールドを抽出し、前記ＩＲパケットの残りの部分を圧縮されたパケットに変換し、前記ＩＲ−ＤＹＮパケットの残りの部分を圧縮されたパケットに変換するステップであって、
前記再構成されたパケットストリームは、前記ＩＲパケット又は前記ＩＲ−ＤＹＮパケットを取り替える前記変換された圧縮されたパケットを含み、
前記ペイロードは、前記動的フィールドを含み、
前記インジケータフィールドは、前記動的フィールドが前記ペイロードに含まれるか否かをさらに示す、ステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記シグナリングパケットは、特定の物理データパスを介して送信される、請求項１に記載の方法。
【請求項４】
前記第２チャネルは、シグナリング情報を伝送するためのシグナリングチャネルと、システムデコーディングのために必要な伝送情報のためのシステムチャネルとを含み、
前記抽出された静的フィールド及び前記抽出された動的フィールドの少なくとも１つは、前記シグナリングチャネル又は前記システムチャネルを介して伝送される、請求項２に記載の方法。
【請求項５】
放送信号受信方法であって、
第１チャネルを介して再構成されたパケットストリームを受信するステップであって、
前記再構成されたパケットストリームは、ＲｏＨＣ（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）パケットストリームから再構成され、
前記ＲｏＨＣパケットストリームは、ＩＲ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ａｎｄ  Ｒｅｆｒｅｓｈ）パケットと、ＩＲ−ＤＹＮ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ａｎｄ  Ｒｅｆｒｅｓｈ−Ｄｙｎａｍｉｃ）パケットと、圧縮されたパケットとを含み、
前記ＩＲパケットは、静的フィールド及び動的フィールドを含み、
前記ＩＲ−ＤＹＮパケットは、前記動的フィールドを含み、
前記再構成されたパケットストリームは、前記ＩＲパケットから前記静的フィールドを抽出し、前記ＩＲパケットの残りの部分をＩＲ−ＤＹＮパケットに変換するステップにより取得され、
前記再構成されたパケットストリームは、前記ＩＲパケットを取り替える前記変換されたＩＲ−ＤＹＮパケットを含む、ステップと、
前記第１チャネルと区別される第２チャネルを介してシグナリングパケットを受信するステップであって、
前記シグナリングパケットは、ヘッダーとペイロードとを含み、
前記ペイロードは、前記抽出された静的フィールドを含み、
前記ヘッダーは、前記シグナリングパケットのタイプを識別するパケットタイプフィールドと、前記ペイロードの長さを示す長さフィールドとを含み、
前記ペイロードは、前記ＲｏＨＣパケットストリームを識別するコンテキスト識別情報と、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットストリームを圧縮するために使用されたプロトコルの範囲を示すコンテキストプロファイル情報とを含み、
前記シグナリングパケットは、前記静的フィールドが前記ペイロードに含まれるか否かを示すインジケータフィールドを含む、ステップと、
前記静的フィールドを使用して、前記受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元するステップと、
前記復元されたＲｏＨＣパケットストリームに含まれるＲｏＨＣパケットのヘッダーの圧縮を解除して、ＩＰパケットストリームを生成するステップと、
放送データを取得するために、前記生成されたＩＰパケットストリームを処理するステップと、を含む、方法。
【請求項６】
前記再構成されたパケットストリームは、前記ＩＲパケット及び前記ＩＲ−ＤＹＮパケットから前記動的フィールドを抽出するステップと、前記ＩＲパケットの残りの部分を圧縮されたパケットに変換し、前記ＩＲ−ＤＹＮパケットの残りの部分を圧縮されたパケットに変換するステップとにより取得され、
前記再構成されたパケットストリームは、前記ＩＲパケット又は前記ＩＲ−ＤＹＮパケットを取り替える前記変換された圧縮されたパケットを含み、
前記ペイロードは、前記動的フィールドを含み、
前記インジケータフィールドは、前記動的フィールドが前記ペイロードに含まれるか否かをさらに示す、請求項５に記載の方法。
【請求項７】
前記シグナリングパケットは、特定の物理データパスを介して送信される、請求項５に記載の方法。
【請求項８】
前記第２チャネルは、シグナリング情報を伝送するためのシグナリングチャネルと、システムデコーディングのために必要な伝送情報のためのシステムチャネルとを含み、
前記抽出された静的フィールド及び前記抽出された動的フィールドの少なくとも１つは、前記シグナリングチャネル又は前記システムチャネルを介して伝送される、請求項５に記載の方法。
【請求項９】
放送信号送信装置であって、
ＲｏＨＣ（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）パケットストリームを生成するために、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットストリームに含まれるＩＰパケットのヘッダーを圧縮するためのＲｏＨＣコンプレッサであって、
前記ＲｏＨＣパケットストリームは、ＩＲ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ａｎｄ  Ｒｅｆｒｅｓｈ）パケットと、ＩＲ−ＤＹＮ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ａｎｄ  Ｒｅｆｒｅｓｈ−Ｄｙｎａｍｉｃ）パケットと、圧縮されたパケットとを含み、
前記ＩＲパケットは、静的フィールド及び動的フィールドを含み、
前記ＩＲ−ＤＹＮパケットは、前記動的フィールドを含む、ＲｏＨＣコンプレッサと、
前記ＩＲパケットから前記静的フィールドを抽出し、前記ＩＲパケットの残りの部分をＩＲ−ＤＹＮパケットに変換するための変換部と、
前記ＩＲパケットを取り替える前記変換されたＩＲ−ＤＹＮパケットを含むパケットストリームを再構成するための再構成部と、
ヘッダーとペイロードとを含むシグナリングパケットを生成するためのシグナリングパケット生成部であって、
前記ペイロードは、前記抽出された静的フィールドを含み、
前記ヘッダーは、前記シグナリングパケットのタイプを識別するパケットタイプフィールドと、前記ペイロードの長さを示す長さフィールドとを含み、
前記ペイロードは、前記ＲｏＨＣパケットストリームを識別するコンテキスト識別情報と、前記ＩＰパケットストリームを圧縮するために使用されたプロトコルの範囲を示すコンテキストプロファイル情報とを含み、
前記シグナリングパケットは、前記静的フィールドが前記ペイロードに含まれるか否かを示すインジケータフィールドを含む、シグナリングパケット生成部と、
第１チャネルを介して前記再構成されたパケットストリームを送信し、前記第１チャネルと区別される第２チャネルを介して前記シグナリングパケットを送信するための伝送部と、を含む、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送信号の送受信に関し、より詳細には、ＲｏＨＣパケットストリームを含む放送信号の送受信方法及び／又は装置に関する。
【背景技術】
【０００２】
ＩＰ／ＵＤＰ／ＲＴＰヘッダーフィールドは、一般に、ｓｔａｔｉｃ、ｄｅｌｔａ、ｄｙｎａｍｉｃ、ｉｎｆｅｒｒｅｄ属性に分類することができる。ｓｔａｔｉｃは、一つのエンドツーエンド（ｅｎｄ  ｔｏ  ｅｎｄ）パケットストリームで一定の値を有するフィールドであって、ＩＰアドレス及びポート番号が該当し、ＲＴＰ又はＩＰのｖｅｒｓｉｏｎフィールドのようによく知られている値を有するフィールドも該当する。ｄｅｌｔａは、前のパケットとの値差が一定であるフィールドであって、シーケンス番号などが該当する。ｄｙｎａｍｉｃは、無作為に変わるフィールドであって、チェックサム、ＩＰパケットのＩＤなどが該当する。ｉｎｆｅｒｒｅｄは、ｌｅｎｇｔｈフィールドのように他のヘッダーフィールドなどを通じて推論が可能なフィールドが該当する。一般的なヘッダー圧縮技法にはＣＩＤ（ｃｏｎｔｅｘｔ  ｉｄｅｎｔｉｆｉｅｒ）概念が導入されるが、送信側（コンプレッサ）で最初は無圧縮状態のフル（ｆｕｌｌ）ヘッダーを有するパケットに特定ＣＩＤを追加して送り、次回のパケットからは同一のＣＩＤとしてｓｔａｔｉｃ、ｄｅｌｔａ又はｉｎｆｅｒｒｅｄ性質を有するヘッダーフィールドを省略して送ると、受信側（デコンプレッサ）では、ＣＩＤに基づいて最初に保存されたヘッダーフィールド情報を参考にして２番目のパケット以後に受信された圧縮ヘッダーに省略された各フィールドを追加する方式で全体のＲＴＰヘッダーを復元する。ｄｅｌｔａヘッダーの場合、コンプレッサとデコンプレッサがフルヘッダーのほとんどのフィールドを保存してからコンプレッサで前のパケットとの差値のみを伝送すると、デコンプレッサが差値を既存に保存された値に補正する方式で復元される。
【０００３】
ＲｏＨＣ（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）は、ＩＰ、ＵＤＰ、ＲＴＰ、ＴＣＰなどのヘッダーを圧縮する標準化された技法である。ストリーミングアプリケーションにおいて、ＩＰ、ＵＤＰ、ＲＴＰヘッダーのオーバーヘッドは、ＩＰｖ４の場合は４０バイトであり、ＩＰｖ６の場合は６０バイトである。ＶｏｌＰの場合、この数値は全体的に伝送されるデータの６０％に該当する量である。このような過大なオーバーヘッドは、帯域幅が限定された無線システムでは深刻な問題をもたらし得る。ＲｏＨＣを通じて、４０バイト又は６０バイトのオーバーヘッドは１又は３バイトに圧縮され、受信側に伝達された後で圧縮が解除される。
【０００４】
ＲｏＨＣは、ヘッダーフィールドをｓｔａｔｉｃ、ｄｙｎａｍｉｃ、ｉｎｆｅｒａｂｌｅに区分しており、コンプレッサでの圧縮解除状態をＩＲ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ａｎｄ  Ｒｅｆｒｅｓｈ）、ＦＯ（Ｆｉｒｓｔ  Ｏｒｄｅｒ）、ＳＯ（Ｓｅｃｏｎｄ  Ｏｒｄｅｒ）と定義し、デコンプレッサでの圧縮解除状態をＮＣ（Ｎｏ  Ｃｏｎｔｅｘｔ）、ＳＣ（Ｓｔａｔｉｃ  Ｃｏｎｔｅｘｔ）、ＦＣ（Ｆｕｌｌ  Ｃｏｎｔｅｘｔ）と定義する。ＲｏＨＣ技法は、低い圧縮率で伝送を開始し、可能な限り最も高い圧縮率に到逹した状態に維持することであるが、デコンプレッサのコンテキスト初期化又は圧縮解除失敗が発生すると、コンプレッサの状態は最も低い圧縮段階であるＩＲに戻り、この状態でコンプレッサはフルヘッダーを伝送する。その後、ＦＯ段階でコンプレッサはｓｔａｔｉｃフィールドを省略し、最終的にＳＯ段階で圧縮可能な全てのフィールドは伝送されない。デコンプレッサの状態遷移は、最も低い段階であるＮＣからＳＣ及びＦＣ段階に移動可能であり、ＦＣ段階で最適な圧縮解除動作が行われる。
【０００５】
ＲｏＨＣでは、伝送初期は全体のヘッダーを伝送してから、伝送が進められながら変わらない部分は省略する方式で圧縮を進める。このような方式を放送システムに採択する場合、放送受信機は、いずれの時点からＩＰストリームを受信すべきであるかを知ることができず、全体のヘッダー情報を知らない受信機は該当のＩＰパケットを認識できないという問題が発生する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明が達成しようとする課題は、上述した問題を解決するためのものであって、ＲｏＨＣパケットストリームを含む放送信号を送受信する方法及び／又は装置を提供することにある。
【０００７】
さらに、本発明が達成しようとする課題は、単方向伝送システムで受信機の接近時点とは関係なくパケットを復旧できる方法を提供することにある。
【０００８】
さらに、本発明が達成しようとする課題は、単方向伝送システムでＲｏＨＣ関連メタデータを受信側にあらかじめ伝送する方法を提供することにある。
【０００９】
さらに、本発明が達成しようとする課題は、単方向伝送システムでＲｏＨＣ関連メタデータを別途のチャネルを介して伝送する方法を提供することにある。
【００１０】
さらに、本発明が達成しようとする課題は、ＲｏＨＣパケットストリームで別途のチャネルを介して伝送する各情報を抽出する方法を提供することにある。
【課題を解決するための手段】
【００１１】
本発明の一実施例に係る放送信号送信方法は、ＩＰパケットストリームに含まれたＩＰパケットのヘッダーを圧縮することによってＲｏＨＣパケットストリームを生成するステップと、前記生成されたＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットの第１部分を抽出するステップと、前記ＲｏＨＣパケットの第２部分を他のタイプのＲｏＨＣパケットに変換するステップと、前記変換された他のタイプのＲｏＨＣパケットを含む新しいパケットストリームを再構成するステップと、前記再構成されたパケットストリームを第１チャネルを介して伝送するステップと、前記抽出された第１部分を第２チャネルを介して伝送するステップとを含むことができる。
【００１２】
好ましくは、前記ＲｏＨＣパケットは、ストリーミングが行われる間にパケットが変わることによって毎回変わる第１ヘッダー情報及びペイロードを含む第１パケット、パケットが変わることによって一定の間隔を置いて変わる第２ヘッダー情報、前記第１ヘッダー情報及びペイロードを含む第２パケット、及びストリーミングが行われる間にパケットが変わっても変わらない第３ヘッダー情報、前記第１ヘッダー情報及びペイロードを含む第３パケットのうちいずれか一つに該当し得る。
【００１３】
好ましくは、前記第３パケットは前記第２ヘッダー情報をさらに含み、前記抽出するステップは、前記生成されたＲｏＨＣパケットストリームに含まれた第３パケットから第２ヘッダー情報及び第３ヘッダー情報を抽出し、第２パケットから第２ヘッダー情報を抽出し、前記変換するステップは、第３パケットから第２ヘッダー情報及び第３ヘッダー情報が抽出された後で残った部分を第１パケットに変換し、第２パケットから第２ヘッダー情報が抽出された後で残った部分を第１パケットに変換することができる。
【００１４】
好ましくは、前記第３パケットは前記第２ヘッダー情報をさらに含み、前記抽出するステップは、前記生成されたＲｏＨＣパケットストリームに含まれた第３パケットから第３ヘッダー情報を抽出し、前記変換するステップは、第３パケットから第３ヘッダー情報が抽出された後で残った部分を第２パケットに変換することができる。
【００１５】
好ましくは、前記抽出するステップは、前記生成されたＲｏＨＣパケットストリームに含まれた第３パケットから第３ヘッダー情報を抽出し、第２パケットから第２ヘッダー情報を抽出し、前記変換するステップは、第３パケットから第３ヘッダー情報が抽出された後で残った部分を第１パケットに変換し、第２パケットから第２ヘッダー情報が抽出された後で残った部分を第１パケットに変換することができる。
【００１６】
好ましくは、前記第２チャネルは、シグナリング情報を伝送するシグナリングチャネル、及びシステムデコーディングに必要な情報を伝達するシステムチャネルを含み、前記抽出された第２ヘッダー情報及び第３ヘッダー情報のうち少なくともいずれか一つは、前記シグナリングチャネル又はシステムチャネルを介して伝送することができる。
【００１７】
好ましくは、前記抽出された第２ヘッダー情報又は第３ヘッダー情報を前記シグナリングチャネルを介して伝送する場合、前記第２ヘッダー情報又は第３ヘッダー情報はサブエレメントに含まれて伝送され、ここで、前記サブエレメントは、前記第２ヘッダー情報又は第３ヘッダー情報による該当のＲｏＨＣパケットストリームを識別するコンテキスト識別子情報、及び前記第２ヘッダー情報又は第３ヘッダー情報による該当のＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットのヘッダーがいずれのプロトコルまで圧縮されたのかを示すコンテキストプロファイル情報を含むことができる。
【００１８】
好ましくは、前記抽出された第２ヘッダー情報又は第３ヘッダー情報を前記システムチャネルを介して伝送する場合、前記第２ヘッダー情報又は第３ヘッダー情報はパケットのペイロードに含まれて伝送され、ここで、前記パケットは、前記パケットのタイプ情報を示すパケットタイプ情報、及びペイロードに含まれた情報が第２ヘッダー情報であるのか、それとも第３ヘッダー情報であるのかを示すインジケータ情報、及びペイロードの長さを示す長さ情報を含むことができる。
【００１９】
本発明の他の一実施例に係る放送信号受信方法は、第１チャネルを介して再構成されたパケットストリームを受信するステップ―ここで、前記再構成されたパケットストリームは、ＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットの第１部分を抽出し、前記ＲｏＨＣパケットの第２部分を他のタイプのＲｏＨＣパケットに変換し、前記変換された他のタイプのＲｏＨＣパケットを含む新しいパケットストリームを再構成した新しいパケットストリームであり、前記抽出された第１部分を第２チャネルを介して受信する。―と、前記受信された第１部分を用いて前記受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元するステップと、前記復元されたＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットのヘッダーの圧縮を解除することによってＩＰパケットストリームを生成するステップと、前記生成されたＩＰパケットストリームを処理することによって放送データを取得するステップとを含むことができる。
【００２０】
好ましくは、前記ＲｏＨＣパケットは、ストリーミングが行われる間にパケットが変わることによって毎回変わる第１ヘッダー情報及びペイロードを含む第１パケット、パケットが変わることによって一定の間隔を置いて変わる第２ヘッダー情報、前記第１ヘッダー情報及びペイロードを含む第２パケット、及びストリーミングが行われる間にパケットが変わっても変わらない第３ヘッダー情報、前記第１ヘッダー情報及びペイロードを含む第３パケットのうちいずれか一つに該当し得る。
【００２１】
好ましくは、前記第３パケットは前記第２ヘッダー情報をさらに含み、前記復元するステップは、前記第１部分に含まれて受信された第２ヘッダー情報及び第３ヘッダー情報のシーケンス番号が同一である場合、これと同一のシーケンス番号を有する第１パケットを検出し、前記検出された第１パケットに前記受信された第２ヘッダー情報及び第３ヘッダー情報を結合することによって第３パケットを復元し、前記受信された第２ヘッダー情報及び第３ヘッダー情報のシーケンス番号が異なる場合、前記受信された第２ヘッダー情報と同一のシーケンス番号を有する第１パケットを検出し、前記検出された第１パケットに前記受信された第２ヘッダー情報を結合することによって第２パケットを復元し、前記受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元することができる。
【００２２】
好ましくは、前記第３パケットは前記第２ヘッダー情報をさらに含み、前記復元するステップは、前記第１部分に含まれて受信された第３ヘッダー情報と同一のシーケンス番号を有する第２パケットを検出し、前記検出された第２パケットに前記受信された第２ヘッダー情報を結合することによって第３パケットを復元し、前記受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元することができる。
【００２３】
好ましくは、前記復元するステップは、前記第１部分に含まれて受信された第３ヘッダー情報のシーケンス番号と同一のシーケンス番号を有する第１パケットを検出し、前記検出された第１パケットに前記受信された第３ヘッダー情報を結合することによって第３パケットを復元し、前記第１部分に含まれて受信された第２ヘッダー情報と同一のシーケンス番号を有する第１パケットを検出し、前記検出された第１パケットに前記受信された第２ヘッダー情報を結合することによって第２パケットを復元し、前記受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元することができる。
【００２４】
好ましくは、前記第２チャネルは、シグナリング情報を伝送するシグナリングチャネル、及びシステムデコーディングに必要な情報を伝達するシステムチャネルを含み、前記抽出された第２ヘッダー情報及び第３ヘッダー情報のうち少なくともいずれか一つは、前記シグナリングチャネル又はシステムチャネルを介して伝送することができる。
【００２５】
好ましくは、前記抽出された第２ヘッダー情報又は第３ヘッダー情報を前記シグナリングチャネルを介して伝送する場合、前記第２ヘッダー情報又は第３ヘッダー情報はサブエレメントに含まれて伝送され、ここで、前記サブエレメントは、前記第２ヘッダー情報又は第３ヘッダー情報による該当のＲｏＨＣパケットストリームを識別するコンテキスト識別子情報、及び前記第２ヘッダー情報又は第３ヘッダー情報による該当のＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットのヘッダーがいずれのプロトコルまで圧縮されたのかを示すコンテキストプロファイル情報を含むことができる。
【００２６】
好ましくは、前記抽出された第２ヘッダー情報又は第３ヘッダー情報を前記システムチャネルを介して伝送する場合、前記第２ヘッダー情報又は第３ヘッダー情報はパケットのペイロードに含まれて伝送され、ここで、前記パケットは、前記パケットのタイプ情報を示すパケットタイプ情報、ペイロードに含まれた情報が第２ヘッダー情報であるのか、それとも第３ヘッダー情報であるのかを示すインジケータ情報、及びペイロードの長さを示す長さ情報を含むことができる。
【００２７】
本発明の他の一実施例に係る放送信号送信装置は、ＩＰパケットストリームに含まれたＩＰパケットのヘッダーを圧縮することによってＲｏＨＣパケットストリームを生成するＲｏＨＣコンプレッサと、前記生成されたＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットの第１部分を抽出する抽出部と、前記ＲｏＨＣパケットの第２部分を他のタイプのＲｏＨＣパケットに変換する変換部と、前記変換された他のタイプのＲｏＨＣパケットを含む新しいパケットストリームを再構成する再構成部と、前記再構成されたパケットストリームを第１チャネルを介して伝送し、前記抽出された第１部分を第２チャネルを介して伝送する伝送部とを含むことができる。
【００２８】
本発明の他の一実施例に係る放送信号受信装置は、第１チャネルを介して再構成されたパケットストリームを受信する第１受信部―ここで、前記再構成されたパケットストリームは、ＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットの第１部分を抽出し、前記ＲｏＨＣパケットの第２部分を他のタイプのＲｏＨＣパケットに変換し、前記変換された他のタイプのＲｏＨＣパケットを含む新しいパケットストリームを再構成した新しいパケットストリームである。―と、前記抽出された第１部分を第２チャネルを介して受信する第２受信部と、前記受信された第１部分を用いて前記受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元する復元部と、前記復元されたＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットのヘッダーの圧縮を解除することによってＩＰパケットストリームを生成するＲｏＨＣデコンプレッサと、前記生成されたＩＰパケットストリームを処理することによって放送データを取得するＩＰパケット処理部とを含むことができる。
【発明の効果】
【００２９】
本発明によれば、ＲｏＨＣパケットストリームを含む放送信号を送受信できるという効果がある。
【００３０】
本発明によれば、受信機の接近時点とは関係なく、伝送されるパケットを復旧できるという効果がある。
【００３１】
本発明によれば、受信機はＲｏＨＣ関連メタデータを実際のデータの受信前に受信できるという効果がある。
【００３２】
本発明によれば、ＲｏＨＣ関連メタデータを実際のデータが伝送されるチャネルと別個のチャネルを介して伝送できるという効果がある。
【００３３】
本発明の追加の理解を提供するために本出願の一部に含まれたり、その一部を構成する添付の図面は、本発明の実施例を示し、説明と共に本発明の原理を説明する。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施例に係る将来の放送サービスのための放送信号を送信する装置の構造を示す図である。
【図２】本発明の一実施例に係る入力フォーマッティングブロックを示す図である。
【図３】本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。
【図４】本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。
【図５】本発明の一実施例に係るＢＩＣＭブロックを示す図である。
【図６】本発明の他の実施例に係るＢＩＣＭブロックを示す図である。
【図７】本発明の一実施例に係るフレームビルディングブロックを示す図である。
【図８】本発明の実施例に係るＯＦＤＭ生成ブロックを示す図である。
【図９】本発明の実施例に係る将来の放送サービスのための放送信号を受信する装置の構造を示す図である。
【図１０】本発明の実施例に係るフレーム構造を示す図である。
【図１１】本発明の実施例に係るフレームのシグナリング層の構造を示す図である。
【図１２】本発明の実施例に係るプリアンブルシグナリングデータを示す図である。
【図１３】本発明の実施例に係るＰＬＳ１データを示す図である。
【図１４】本発明の実施例に係るＰＬＳ２データを示す図である。
【図１５】本発明の他の実施例に係るＰＬＳ２データを示す図である。
【図１６】本発明の実施例に係るフレームの論理構造を示す図である。
【図１７】本発明の実施例に係るＰＬＳマッピングを示す図である。
【図１８】本発明の実施例に係るＥＡＣマッピングを示す図である。
【図１９】本発明の実施例に係るＦＩＣマッピングを示す図である。
【図２０】本発明の実施例に係るＤＰのタイプを示す図である。
【図２１】本発明の実施例に係るＤＰマッピングを示す図である。
【図２２】本発明の実施例に係るＦＥＣ構造を示す図である。
【図２３】本発明の実施例に係るビットインターリービングを示す図である。
【図２４】本発明の実施例に係るセル―ワードデマルチプレクシングを示す図である。
【図２５】本発明の実施例に係る時間インターリービングを示す図である。
【図２６】本発明の実施例に係るツイスト行―列ブロックインターリーバの基本動作を示す図である。
【図２７】本発明の他の実施例に係るツイスト行―列ブロックインターリーバの動作を示す図である。
【図２８】本発明の実施例に係るツイスト行―列ブロックインターリーバの対角線方向読み取りパターンを示す図である。
【図２９】本発明の実施例に係る各インターリービングアレイからのインターリーブされたＸＦＥＣＢＬＯＣＫを示す図である。
【図３０】本発明の一実施例に係るＲｏＨＣ（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）パケットと圧縮されていないＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットの構造を示した図である。
【図３１】本発明の一実施例に係るＲｏＨＣパケットストリームのコンセプトを示した図である。
【図３２】本発明の一実施例に係るＲｏＨＣパケットストリームの伝送過程中にコンテキスト情報が伝播される過程を示した図である。
【図３３】本発明の一実施例に係るＩＰヘッダー圧縮方式が適用されたＩＰストリームの送受信システムを示した図である。
【図３４】本発明の一実施例に係る送受信機におけるＩＰオーバーヘッド削減（ＩＰ  ｏｖｅｒｈｅａｄ  ｒｅｄｕｃｔｉｏｎ）過程を示した図である。
【図３５】本発明の一実施例に係るＲｏＨＣパケットを再構成し、新しいパケットストリームを構成する過程を示した図である。
【図３６】本発明の一実施例に係るＲｏＨＣパケットを再構成し、新しいパケットストリームを構成する過程でＩＲパケットを一般的なヘッダー圧縮されたパケットに変換する過程を示した図である。
【図３７】本発明の一実施例に係るＲｏＨＣパケットを再構成し、新しいパケットストリームを構成する過程でＩＲ―ＤＹＮパケットを一般的なヘッダー圧縮されたパケットに変換する過程を示した図である。
【図３８】本発明の一実施例に係るＲｏＨＣパケットを再構成し、新しいパケットストリームを構成する過程でＩＲパケットをＩＲ―ＤＹＮパケットに変換する過程を示した図である。
【図３９】本発明の一実施例に係る第１構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃１）に対するＲｏＨＣパケットストリームの構成及び復元過程を示した図である。
【図４０】本発明の一実施例に係る第２構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃２）に対するＲｏＨＣパケットストリームの構成及び復元過程を示した図である。
【図４１】本発明の一実施例に係る第３構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃３）に対するＲｏＨＣパケットストリームの構成及び復元過程を示した図である。
【図４２】本発明の一実施例に係るアウトオブバンド（Ｏｕｔ  ｏｆ  Ｂａｎｄ）を介して伝達できる情報の組合せを示した図である。
【図４３】本発明の一実施例に係る静的チェーン（ｓｔａｔｉｃ  ｃｈａｉｎ）を含むディスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）の構成を示した図である。
【図４４】本発明の一実施例に係る動的チェーン（ｄｙｎａｍｉｃ  ｃｈａｉｎ）を含むディスクリプタの構成を示した図である。
【図４５】本発明の一実施例に係る静的チェーンを含むパケットフォーマット及び動的チェーンを含むパケットフォーマットの構成を示した図である。
【図４６】本発明の一実施例に係る放送信号送信方法を示した図である。
【図４７】本発明の一実施例に係る放送信号受信方法を示した図である。
【図４８】本発明の一実施例に係る放送信号送信装置の構造を示した図である。
【図４９】本発明の一実施例に係る放送信号受信装置の構造を示した図である。
【発明を実施するための形態】
【００３５】
以下、添付の図面及び添付の図面に記載の内容を参照して本発明の実施例を説明するが、本発明が各実施例によって制限又は限定されることはない。 
【００３６】
本発明で使用される用語としては、本発明での機能を考慮しながら、可能な限り広く使用される一般的な用語を選択したが、これは、当分野に携わる技術者の意図、慣例又は新しい技術の出現などによって変わり得る。また、特定の場合は、出願人が任意に選択した用語もあり、この場合、該当する発明の説明部分でその意味を記載する。したがって、本明細書で使用される用語は、単なる用語の名称でなく、その用語が有する実質的な意味と本明細書の全般にわたった内容に基づいて解釈すべきであることを明らかにしておく。
【００３７】
本明細書において、“シグナリング”とは、放送システム、インターネット放送システム及び／又は放送／インターネット融合システムで提供されるサービス情報（Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ；ＳＩ）を伝送／受信することを示す。サービス情報は、現在存在する各放送システムで提供される放送サービス情報（例えば、ＡＴＳＣ―ＳＩ及び／又はＤＶＢ―ＳＩ）を含む。
【００３８】
本明細書において、 “放送信号”とは、地上波放送、ケーブル放送、衛星放送及び／又はモバイル放送の他にも、インターネット放送、ブロードバンド放送、通信放送、データ放送及び／又はＶＯＤ（Ｖｉｄｅｏ  Ｏｎ  Ｄｅｍａｎｄ）などの双方向放送で提供される信号及び／又はデータを含む概念と定義する。
【００３９】
本明細書において、 “ＰＬＰ”とは、物理層に属するデータを伝送する一定のユニットを意味する。したがって、本明細書において“ＰＬＰ”と命名された内容は、“データユニット”又は“データパイプ”に代えて命名されてもよい。
【００４０】
デジタル放送（ＤＴＶ）サービスで活用される有力なアプリケーションの一つとして、放送網とインターネット網との連動を通じたハイブリッド放送サービスを挙げることができる。
【００４１】
ハイブリッド放送サービスは、地上波放送網を介して伝送される放送Ａ／Ｖ（オーディオ／ビデオ）コンテンツに関連したエンハンスメントデータ或いは放送Ａ／Ｖコンテンツの一部をインターネット網を介して実時間で伝送することによって、ユーザが多様なコンテンツを経験できるようにする。
【００４２】
本発明は、次世代デジタル放送システムにおいて、ＩＰパケット、ＭＰＥＧ―２  ＴＳパケット及びその他の放送システムで使用可能なパケットを物理層に伝達できるようにカプセル化する方法を提示することを目的とする。また、同じヘッダーフォーマットでレイヤ２シグナリングを共に伝送できるようにする方法も提案する。
【００４３】
以下で説明する内容は装置で具現することができる。例えば、シグナリング処理部、プロトコル処理部、プロセッサ及び／又はパケット生成部で以下で説明する過程を行うことができる。
【００４４】
以下、添付の図面を参照して本発明の好適な実施例を説明する。添付の図面を参照して以下で説明する詳細な説明は、本発明によって具現し得る実施例だけを示すよりは、本発明の例示的な実施例を説明するためのものである。次の詳細な説明は、本発明の完璧な理解を提供するために特定の細部事項を含む。しかし、本発明は、このような特定の細部事項がなくても実行可能であることは当業者にとって自明である。
【００４５】
本発明で使われる大部分の用語は、本技術で広く使われているものから選択されたが、一部の用語は出願人によって任意に選択されたものもあり、その意味は、必要によって次の説明で詳細に説明する。したがって、本発明は、単なる名称又は意味よりは、用語の意図した意味に基づいて理解しなければならない。
【００４６】
本発明は、将来の放送サービスのための放送信号を送受信する装置及び方法を提供する。本発明の実施例に係る将来の放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非―ＭＩＭＯ（ｎｏｎ―Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）又はＭＩＭＯを通じて将来の放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非―ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式などを含むことができる。
【００４７】
説明の便宜上、以下では、ＭＩＳＯ又はＭＩＭＯが２つのアンテナを使用するが、本発明は、２つ以上のアンテナを用いるシステムに適用されてもよい。
【００４８】
本発明は、特定の使用ケースのために要求される性能を獲得しながら、受信機の複雑度を最小化するのにそれぞれ最適化された３つの物理層（ＰＬ）プロファイル（ベース、ハンドヘルド、及びアドバンスドプロファイル）を定義することができる。物理層（ＰＨＹ）プロファイルは、該当の受信機が具現しなければならない全ての構成のサブセットである。
【００４９】
３つのＰＨＹプロファイルは、大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータにおいてやや異なる。追加のＰＨＹプロファイルが未来に定義されてもよい。システムの進化のために、将来のプロファイルは、ＦＥＦ（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ  ｆｒａｍｅ）を通じて単一ＲＦチャネル内の既存のプロファイルとマルチプレクスされてもよい。以下では、それぞれのＰＨＹプロファイルの細部事項を説明する。
【００５０】
１．ベースプロファイル
【００５１】
ベースプロファイルは、ルーフトップ（ｒｏｏｆ―ｔｏｐ）アンテナに通常接続される固定受信装置に対する主要な使用ケースを示す。ベースプロファイルはある場所に移動してもよいが、比較的停止した受信カテゴリーに属する携帯用装置を含む。ベースプロファイルの使用は、若干の改善された具現例によってハンドヘルド装置又は車両装置に拡張されてもよいが、このような使用ケースはベースプロファイル受信機の動作では期待されない。
【００５２】
受信のターゲットＳＮＲ範囲は略１０ｄＢ乃至２０ｄＢであり、これは、既存の放送システム（例えば、ＡＴＳＣ  Ａ／５３）の１５ｄＢ  ＳＮＲ受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを使用する、バッテリー動作ハンドヘルド装置におけるよりは重要でない。ベースプロファイルに対する重要なシステムパラメータは、以下の表１に列挙される。
【００５３】
【表１】
0006333983.tif 000002
【００５４】
２．ハンドヘルドプロファイル
【００５５】
ハンドヘルドプロファイルは、バッテリー電源で動作するハンドヘルド及び車両用装置に使用されるように設計された。装置は歩行者又は車両の速度で移動することができる。受信機の複雑度のみならず、消費電力は、ハンドヘルドプロファイルの装置の具現に非常に重要である。ハンドヘルドプロファイルのターゲットＳＮＲ範囲は、略０ｄＢ乃至１０ｄＢであるが、より深い室内受信を対象にするとき、０ｄＢ未満に到達するように構成されてもよい。
【００５６】
低いＳＮＲ能力に加えて、受信機の移動度によって誘発されたドップラー効果に対する弾力性は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要なシステムパラメータは、以下の表２に列挙される。
【００５７】
【表２】
0006333983.tif 000003
【００５８】
３．アドバンスドプロファイル
【００５９】
アドバンスドプロファイルは、より多くの具現複雑度を犠牲にし、最も高いチャネル容量を提供する。このプロファイルはＭＩＭＯ送信及び受信の利用を要求し、ＵＨＤＴＶサービスは、このプロファイルが特別に設計されたターゲット使用ケースである。増加した容量も、与えられた帯域幅内で増加した数のサービス、例えば、複数のＳＤＴＶ又はＨＤＴＶサービスを許容するように使用することができる。
【００６０】
アドバンスドプロファイルのターゲットＳＮＲ範囲は、略２０ｄＢ乃至３０ｄＢである。ＭＩＭＯ送信は、初期に既存の楕円偏波（ｅｌｌｉｐｔｉｃａｌｌｙ―ｐｏｌａｒｉｚｅｄ）送信装置を利用できるが、将来はフル電力交差偏波送信（ｆｕｌｌ―ｐｏｗｅｒ  ｃｒｏｓｓ―ｐｏｌａｒｉｚｅｄ  ｔｒａｎｓｍｉｓｓｉｏｎ）に拡張される。アドバンスドプロファイルに対する重要なシステムパラメータは、以下の表３に列挙される。
【００６１】
【表３】
0006333983.tif 000004
【００６２】
この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの全てのためのプロファイルとして用いられてもよい。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルのためのアドバンスドプロファイルと、ＭＩＭＯを有するハンドヘルドプロファイルのためのアドバンスドプロファイルとに分離することができる。また、３つのプロファイルは設計者の意図によって変更されてもよい。
【００６３】
次の用語及び定義を本発明に適用することができる。次の用語及び定義は、設計によって変更されてもよい。
【００６４】
補助ストリーム：まだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンスであって、将来の拡張のために、又はブロードキャスタ又はネットワークオペレータの要求とおりに使用することができる。
【００６５】
ベースデータパイプ：サービスシグナリングデータを伝達するデータパイプ
【００６６】
ベースバンドフレーム（又はＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディングプロセス（ＢＣＨ及びＬＤＰＣエンコーディング）への入力を形成するＫｂｃｈビットのセット
【００６７】
セル：ＯＦＤＭ送信の一つのキャリアによって伝達される変調値
【００６８】
コーディングブロック：ＰＬＳ１データのＬＤＰＣエンコーディングブロック又はＰＬＳ２データのＬＤＰＣエンコーディングブロックのうち一つ
【００６９】
データパイプ：サービスデータ又は関連メタデータを伝達する物理層内の論理チャネルであって、一つ又は複数のサービス又はサービスコンポーネントを伝達することができる。
【００７０】
データパイプ単位：フレーム内のＤＰにデータセルを割り当て得る基本単位
【００７１】
データシンボル：プリアンブルシンボルでなくフレーム内のＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジシンボルはデータシンボルに含まれる。）
【００７２】
ＤＰ＿ＩＤ：この８ビットフィールドは、ＳＹＳＴＥＭ＿ＩＤによって識別されたシステム内のＤＰを固有に識別する。
【００７３】
ダミーセル：ＰＬＳシグナリング、ＤＰ又は補助ストリームに使用されていない残りの容量を満たすのに使用される擬似ランダム値を伝達するセル
【００７４】
非常警報チャネル（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｃｈａｎｎｅｌ；ＥＡＳ）：ＥＡＳ情報データを伝達するフレームの一部
【００７５】
フレーム：プリアンブルによって始まってフレームエッジシンボルによって終了される物理層時間スロット
【００７６】
フレーム受信ユニット：ＦＥＦを含む同一の又は異なる物理層プロファイルに属するフレームセットであって、スーパーフレーム内で８回反復される。
【００７７】
高速情報チャネル：サービスと対応ベースＤＰとの間のマッピング情報を伝達するフレーム内の論理チャネル
【００７８】
ＦＥＣＢＬＯＣＫ：ＤＰデータのＬＤＰＣエンコーディングビットのセット
【００７９】
ＦＦＴサイズ：特定モードに使用される公称ＦＦＴサイズであって、基本期間（ｅｌｅｍｅｎｔａｒｙ  ｐｅｒｉｏｄ）Ｔの周期で表現されるアクティブシンボル期間Ｔｓと同一である。
【００８０】
フレームシグナリングシンボル：ＦＦＴサイズ、保護区間（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）、及び分散型パイロットパターンの所定の組合せでフレームの先頭で使用されるより高いパイロット密度を有するＯＦＤＭシンボルであって、ＰＬＳデータの一部を伝達する。
【００８１】
フレームエッジシンボル：ＦＦＴサイズ、保護区間、及び分散型パイロットパターンの特定組合せでフレームの終わりで使用されるより高いパイロット密度を有するＯＦＤＭシンボル
【００８２】
フレームグループ：スーパーフレーム内の同じＰＨＹプロファイルタイプを有する全フレームのセット
【００８３】
未来拡張フレーム：未来拡張のための使用できるスーパーフレーム内の物理層時間スロットであって、プリアンブルによって始まる。
【００８４】
フューチャキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２―ＴＳ又はＩＰ又は一般ストリームであり、出力がＲＦ信号である、提案された物理層放送システム
【００８５】
入力ストリーム：システムによって最終ユーザに伝達されるサービスの調和（ｅｎｓｅｍｂｌｅ）のためのデータのストリーム
【００８６】
正常データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除いたデータシンボル
【００８７】
ＰＨＹプロファイル：該当の受信機が具現すべき全構成のサブセット
【００８８】
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理層シグナリングデータ
【００８９】
ＰＬＳ１：固定サイズ、コーディング及び変調を有するＦＳＳシンボルで伝達されるＰＬＳデータの第１セットであって、ＰＬＳ２をデコードするのに必要なパラメータだけでなく、システムに関する基本情報を伝達する。
【００９０】
注（ＮＯＴＥ）：フレームグループのデューレーションのためにＰＬＳ１データは一定に維持される。
【００９１】
ＰＬＳ２：ＦＳＳシンボルで送信されるＰＬＳデータの第２セットであって、システム及びＤＰに対するより細部的なＰＬＳデータを伝達する。
【００９２】
ＰＬＳ２動的データ：フレーム別に動的に変化し得るＰＬＳ２データ
【００９３】
ＰＬＳ２静的データ：フレームグループのデューレーションの間に静的に維持されるＰＬＳ２データ
【００９４】
プリアンブルシグナリングデータ：プリアンブルシンボルによって伝達され、システムの基本モードを識別するのに使用されるシグナリングデータ
【００９５】
プリアンブルシンボル：基本ＰＬＳデータを伝達し、フレームの初期に位置する固定長パイロットシンボル
【００９６】
注：プリアンブルシンボルは、主に高速初期バンドスキャンのために使用され、システム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出する。
【００９７】
未来使用のために予約：現在文書では定義されないが、未来に定義されてもよい。
【００９８】
スーパーフレーム：８個のフレーム反復単位のセット
【００９９】
時間インターリービングブロック（ＴＩブロック）：時間インターリーバメモリの一つの用途に対応する時間インターリービングが行われるセルのセット
【０１００】
ＴＩグループ：特定ＤＰのための動的容量割り当てが行われる単位であって、整数、すなわち、動的に変化する数のＸＦＥＣＢＬＯＣＫで構成される。
【０１０１】
注：ＴＩグループは、一つのフレームに直接マップされたり、複数のフレームにマップされてもよい。これは一つ以上のＴＩブロックを含むことができる。
【０１０２】
タイプ１  ＤＰ：全ＤＰがＴＤＭ方式でマップされるフレームのＤＰ
【０１０３】
タイプ２  ＤＰ：全ＤＰがＦＤＭ方式でマップされるフレームのＤＰ
【０１０４】
ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣ  ＦＥＣＢＬＯＣＫの全ビットを伝達するＮcellsセルのセット
【０１０５】
図１は、本発明の実施例に係る将来の放送サービスに対する放送信号を送信する装置の構造を示す図である。
【０１０６】
本発明の実施例に係る将来の放送サービスのための放送信号を送信する装置は、入力フォーマッティングブロック１０００、ＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレーム構造ブロック１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）生成ブロック１０３０、及びシグナリング生成ブロック１０４０を含むことができる。以下では、放送信号を送信する装置の各モジュールの動作について説明する。
【０１０７】
ＩＰストリーム／パケット及びＭＰＥＧ２―ＴＳは、メイン入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。これらのデータ入力に加えて、管理情報が入力され、各入力ストリームに対する該当の帯域幅のスケジューリング及び割り当てを制御する。一つ又は複数のＴＳストリーム、ＩＰストリーム及び／又は一般ストリームの入力が同時に許容される。
【０１０８】
入力フォーマッティングブロック１０００は、それぞれの入力ストリームを、一つ又は複数のデータパイプにデマルチプレクスし、独立コーディング及び変調がデータパイプに適用される。データパイプ（ＤＰ）は、ロバスト性制御のための基本単位であり、これはＱｏＳに影響を及ぼす。一つ又は複数のサービス又はサービスコンポーネントが単一ＤＰによって伝達されてもよい。入力フォーマッティングブロック１０００の動作については後で詳細に説明する。
【０１０９】
データパイプは、サービスデータ又は関連メタデータを伝達する物理層内の論理チャネルであって、一つ又は複数のサービス又はサービスコンポーネントを伝達することができる。
【０１１０】
また、データパイプ単位は、フレーム内のＤＰにデータセルを割り当てる基本ユニットである。
【０１１１】
ＢＩＣＭブロック１０１０において、パリティデータが誤り訂正のために追加され、エンコードされたビットストリームは複素数値星状シンボルにマップされる。シンボルは該当のＤＰに使用される特定インターリービング深さにわたってインターリーブされる。アドバンスドプロファイルに対して、ＭＩＭＯエンコーディングがＢＩＣＭブロック１０１０で行われ、追加のデータ経路はＭＩＭＯ送信のために出力で追加される。ＢＩＣＭブロック１０１０の動作については後で詳細に説明する。
【０１１２】
フレームビルディングブロック１０２０は、入力ＤＰのデータセルをフレーム内のＯＦＤＭシンボルにマップすることができる。マッピング後、周波数インターリービングは、周波数領域ダイバーシチに使用され、特に、周波数選択フェージングチャネルを防止する。フレームビルディングブロック１０２０の動作については後で詳細に説明する。
【０１１３】
各フレームの初期にプリアンブルを挿入した後、ＯＦＤＭ生成ブロック１０３０は、保護区間として循環前置（ｃｙｃｌｉｃ  ｐｒｅｆｉｘ）を有する従来のＯＦＤＭ変調を適用することができる。アンテナ空間ダイバーシチのために、分散型ＭＩＳＯ方式が送信機に適用される。また、ＰＡＰＲ（ｐｅａｋ―ｔｏ―ａｖｅｒａｇｅ  ｐｏｗｅｒ  ｒｅｄｕｃｔｉｏｎ）方式が時間領域で行われる。柔軟なネットワーク計画のために、この提案は、多様なＦＦＴサイズ、保護区間の長さ及び該当のパイロットパターンのセットを提供する。ＯＦＤＭ生成ブロック１０３０の動作については後で詳細に説明する。
【０１１４】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に使用される物理層シグナリング情報を生成することができる。このシグナリング情報はまた、関心のあるサービスが受信側で適切に回復されるように送信される。シグナリング生成ブロック１０４０の動作については後で詳細に説明する。
【０１１５】
図２、図３及び図４は、本発明の実施例に係る入力フォーマッティングブロック１０００を示す。各図について説明する。
【０１１６】
図２は、本発明の一実施例に係る入力フォーマッティングブロックを示す。図２は、入力信号が単一入力ストリームであるときの入力フォーマッティングモジュールを示す。
【０１１７】
図２に示す入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に該当する。
【０１１８】
物理層への入力は、一つ又は複数のデータストリームで構成することができる。それぞれのデータストリームは一つのＤＰによって伝達される。モード適応モジュールは、入ってくるデータストリームをベースバンドフレーム（ＢＢＦ）のデータフィールドにスライスする。システムは、３つのタイプの入力データストリーム、すなわち、ＭＰＥＧ２―ＴＳ、インターネットプロトコル（ＩＰ）、ＧＳ（ｇｅｎｅｒｉｃ  ｓｔｒｅａｍ）を支援する。ＭＰＥＧ２―ＴＳは固定長（１８８バイト）のパケットで特性化され、第１バイトは、シンク（ｓｙｎｃ）バイト（０ｘ４７）である。ＩＰストリームは、ＩＰパケットヘッダー内でシグナルされる可変長ＩＰデータグラムパケットで構成される。システムは、ＩＰストリームのためのＩＰｖ４、ＩＰｖ６を支援する。ＧＳは、カプセル化パケットヘッダー内でシグナルされる可変長パケット又は固定長パケットで構成されてもよい。
【０１１９】
（ａ）は、信号ＤＰのためのモード適応ブロック２０００及びストリーム適応ブロック２０１０を示し、（ｂ）は、ＰＬＳ信号を生成及び処理するＰＬＳ生成ブロック２０２０及びＰＬＳスクランブラ２０３０を示す。各ブロックの動作について説明する。
【０１２０】
入力ストリームスプリッタは、入力ＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分離する。モード適応モジュール２０１０は、ＣＲＣエンコーダ、ＢＢ（ｂａｓｅｂａｎｄ）フレームスライサ、及びＢＢフレームヘッダー挿入ブロックで構成される。
【０１２１】
ＣＲＣエンコーダは、ユーザパケット（ＵＰ）レベル、すなわち、ＣＲＣ―８、ＣＲＣ―１６及びＣＲＣ―３２で誤り訂正のための３つのタイプのＣＲＣエンコーディングを提供する。計算されたＣＲＣバイトは、ＤＰの後に付加される。ＣＲＣ―８はＴＳストリームに使用され、ＣＲＣ―３２はＩＰストリームに使用される。ＧＳストリームがＣＲＣエンコーディングを提供しない場合は、提案されたＣＲＣエンコーディングが適用されなければならない。
【０１２２】
ＢＢフレームスライサは、入力を内部論理ビットフォーマットにマップする。最初に受信されたビットはＭＳＢであると定義される。ＢＢフレームスライサは、利用可能なデータフィールド容量と同数の入力ビットを割り当てる。ＢＢＦペイロードと同数の入力ビットを割り当てるために、ＵＰパケットストリームはＢＢＦのデータフィールドに見合うようにスライスされる。
【０１２３】
ＢＢフレームヘッダー挿入ブロックは、２バイトの固定長のＢＢＦヘッダーを、ＢＢフレームの前に挿入することができる。ＢＢＦヘッダーは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）、及びＲＦＵ（２ビット）で構成される。固定２バイトＢＢＦヘッダーに加えて、ＢＢＦは、２バイトＢＢＦヘッダーの終わりに拡張フィールド（１又は３バイト）を有することができる。
【０１２４】
ストリーム適応ブロック２０１０は、スタッフィング（ｓｔｕｆｆｉｎｇ）挿入ブロック及びＢＢスクランブラで構成される。
【０１２５】
スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリーム適応への入力データがＢＢフレームを満たすのに十分であれば、ＳＴＵＦＦＩは“０”に設定され、ＢＢＦはスタッフィングフィールドを有しない。そうでないと、ＳＴＵＦＦＩが“１”に設定され、スタッフィングフィールドがＢＢＦヘッダーの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダー及び可変サイズのスタッフィングデータを含む。
【０１２６】
ＢＢスクランブラは、エネルギー分散のために完全なＢＢＦをスクランブルする。スクランブリングシーケンスはＢＢＦと同時に発生する。スクランブリングシーケンスはフィードバックされたシフトレジスタによって生成される。
【０１２７】
ＰＬＳ生成ブロック２０２０は、物理層シグナリング（ＰＬＳ）データを生成することができる。ＰＬＳは、受信機に物理層ＤＰにアクセスする手段を提供する。ＰＬＳデータはＰＬＳ１データ及びＰＬＳ２データで構成される。
【０１２８】
ＰＬＳ１データは、固定サイズ、コーディング及び変調を有するフレーム内のＦＳＳシンボルで伝達されるＰＬＳデータの第１セットであって、ＰＬＳ２データをデコードするのに必要なパラメータだけでなく、システムに関する基本情報を伝達する。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするのに要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグループのデューレーションにおいて一定に維持される。
【０１２９】
ＰＬＳ２データは、ＦＳＳシンボルで伝送されるＰＬＳデータの第２セットであって、システム及びＤＰに対するより詳細なＰＬＳデータを伝達する。ＰＬＳ２は、受信機に十分なデータを提供し、所望のＤＰをデコードするパラメータを含む。また、ＰＬＳ２シグナリングは、２つのタイプのパラメータ、すなわち、ＰＬＳ２静的データ（ＰＬＳ２―ＳＴＡＴデータ）及びＰＬＳ２動的データ（ＰＬＳ２―ＤＹＮデータ）で構成される。ＰＬＳ２静的データは、フレームグループのデューレーションにおいて静的に残っているＰＬＳ２データであり、ＰＬＳ２動的データは、フレーム別に動的に変化し得るＰＬＳ２データである。
【０１３０】
ＰＬＳデータの細部事項については後で説明する。
【０１３１】
ＰＬＳスクランブラ２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブルすることができる。
【０１３２】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１３３】
図３は、本発明の他の実施例に係る入力フォーマッティングブロックを示す。
【０１３４】
図３に示す入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に該当する。
【０１３５】
図３は、入力信号が複数の入力ストリームに対応するとき、入力フォーマッティングブロックのモード適応ブロックを示す。
【０１３６】
複数の入力ストリームを処理する入力フォーマッティングブロックのモード適応ブロックは、独立的に複数の入力ストリームを処理することができる。
【０１３７】
図３を参照すると、複数の入力ストリームをそれぞれ処理するモード適応ブロックは、入力ストリームスプリッタ３０００、入力ストリーム同期化器３０１０、補償遅延ブロック３０２０、ヌルパケット削除ブロック３０３０、ヘッド圧縮ブロック３０４０、ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０、及びＢＢヘッダー挿入ブロック３０７０を含むことができる。以下では、モード適応ブロックの各ブロックについて説明する。
【０１３８】
ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０、及びＢＢヘッダー挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサ、及びＢＢヘッダー挿入ブロックに対応するので、その説明は省略する。
【０１３９】
入力ストリームスプリッタ３０００は、入力ＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分離することができる。
【０１４０】
入力ストリーム同期化器３０１０は、ＩＳＳＹと呼ぶことができる。ＩＳＳＹは、任意の入力データフォーマットに対するエンドツーエンド送信遅延及びＣＢＲ（ｃｏｎｓｔａｎｔ  ｂｉｔ  ｒａｔｅ）を保障する適切な手段を提供することができる。ＩＳＳＹは、常にＴＳを伝達する複数のＤＰの場合に使用され、選択的に、ＧＳストリームを伝達するＤＰに使用される。
【０１４１】
補償遅延ブロック３０２０は、ＩＳＳＹ情報の挿入後に分離されたＴＳパケットストリームを遅延させ、受信機内の追加のメモリを要求することなく、ＴＳパケット再結合メカニズムを許容することができる。
【０１４２】
ヌルパケット削除ブロック３０３０は、ＴＳ入力ストリームのケースにのみ使用される。任意のＴＳ入力ストリーム又は分離されたＴＳストリームは、ＣＢＲ  ＴＳストリームにＶＢＲ（ｖａｒｉａｂｌｅ  ｂｉｔ―ｒａｔｅ）サービスを収容するために存在する多数のヌルパケットを有することができる。この場合、不要な送信オーバーヘッドを避けるために、ヌルパケットが識別されて送信されない。受信機で、除去されたヌルパケットは、送信時に挿入されたＤＮＰ（ｄｅｌｅｔｅｄ  ｎｕｌｌ―ｐａｃｋｅｔ）カウンタを参照して、本来にあった正確な場所に再挿入され、一定のビットレートを保証し、タイムスタンプ（ＰＣＲ）更新に対する必要性を避けることができる。
【０１４３】
ヘッド圧縮ブロック３０４０は、パケットヘッダー圧縮を提供し、ＴＳ又はＩＰ入力ストリームに対する送信効率を増加させることができる。受信機が、ヘッダーの所定部分に対する先験的な情報（ａ  ｐｒｉｏｒｉ  ｉｎｆｏｒｍａｔｉｏｎ）を有することができるため、この既知の情報は送信機で削除されてもよい。
【０１４４】
伝送ストリームに対して、受信機は、シンク―バイト構成（０ｘ４７）及びパケット長（１８８バイト）に関する先験的な情報を有する。入力ＴＳストリームが一つのＰＩＤだけを有するコンテンツを伝達すると、すなわち、一つのサービスコンポーネント（ビデオ、オーディオなど）又はサービスサブコンポーネント（ＳＶＣベース層、ＳＶＣエンハンスメント層、ＭＶＣベースビュー、又はＭＶＣ従属ビュー）に対してのみ、ＴＳパケットヘッダー圧縮が（選択的に）伝送ストリームに適用されてもよい。入力ストリームがＩＰストリームであると、ＩＰパケットヘッダー圧縮が選択的に使用される。
【０１４５】
前記のブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１４６】
図４は、本発明の他の実施例に係る入力フォーマッティングブロックを示す。
【０１４７】
図４に示す入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に該当する。
【０１４８】
図４は、入力信号が複数の入力ストリームに対応するとき、入力フォーマッティングモジュールのストリーム適応ブロックを示す。
【０１４９】
図４を参照すると、複数の入力ストリームをそれぞれ処理するためのモード適応ブロックは、スケジューラ４０００、１―フレーム遅延ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンド（Ｉｎ―ｂａｎｄ）シグナリング４０３０、ＢＢフレームスクランブラ４０４０、ＰＬＳ生成ブロック４０５０、及びＰＬＳスクランブラ４０６０を含むことができる。以下では、ストリーム適応ブロックの各ブロックについて説明する。
【０１５０】
スタッフィング挿入ブロック４０２０、ＢＢフレームスクランブラ４０４０、ＰＬＳ生成ブロック４０５０及びＰＬＳスクランブラ４０６０の動作は、図２を参照して説明したスタッフィング挿入ブロック、ＢＢスクランブラ、ＰＬＳ生成ブロック及びＰＬＳスクランブラ４０６０に対応するので、その説明は省略する。
【０１５１】
スケジューラ４０００は、それぞれのＤＰのＦＥＣＢＬＯＣＫの量から全体フレームにわたった全体のセル割り当てを決定することができる。ＰＬＳ、ＥＡＣ及びＦＩＣに対する割り当てを含めて、スケジューラは、ＰＬＳ２―ＤＹＮデータの値を生成し、これは、フレームのＦＳＳ内のインバンドシグナリング又はＰＬＳセルとして送信される。ＦＥＣＢＬＯＣＫ、ＥＡＣ及びＦＩＣの細部事項については後で説明する。
【０１５２】
１―フレーム遅延ブロック４０１０は、入力データを１送信フレームだけ遅延させ、次のフレームに関するスケジューリング情報が、ＤＰに挿入されるインバンドシグナリング情報に関する現フレームを通じて送信されるようにすることができる。
【０１５３】
インバンドシグナリング４０３０は、ＰＬＳ２データの遅延されていない部分をフレームのＤＰに挿入することができる。
【０１５４】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１５５】
図５は、本発明の一実施例に係るＢＩＣＭブロックを示す。
【０１５６】
図５に示すＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の実施例に該当する。
【０１５７】
前述したように、本発明の一実施例に係る将来の放送サービスのための放送信号を送信する装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
【０１５８】
ＱｏＳが本発明の一実施例に係る将来の放送サービスのための放送信号を送信する装置によって提供されるサービスの特性に依存するので、それぞれのサービスに対応するデータは別個の方式で処理される必要がある。したがって、本発明の実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式をデータ経路にそれぞれ対応するデータパイプに独立して適用することによって、そこに入力されたＤＰを独立して処理することができる。結果的に、本発明の実施例に係る将来の放送サービスのための放送信号を送信する装置は、それぞれのＤＰを介して送信されるそれぞれのサービス又はサービスコンポーネントに対するＱｏＳを制御することができる。
【０１５９】
（ａ）は、ベースプロファイル及びハンドヘルドプロファイルによって共有されたＢＩＣＭブロックを示し、（ｂ）は、アドバンスドプロファイルのＢＩＣＭブロックを示す。
【０１６０】
ベースプロファイル及びハンドヘルドプロファイルによって共有されたＢＩＣＭブロック及びアドバンスドプロファイルによって共有されたＢＩＣＭブロックは、それぞれのＤＰを処理する複数の処理ブロックを含むことができる。
【０１６１】
以下では、ベースプロファイル及びハンドヘルドプロファイルのためのＢＩＣＭブロック及びアドバンスドプロファイルのためのＢＩＣＭブロックのそれぞれの処理ブロックについて説明する。
【０１６２】
ベースプロファイル及びハンドヘルドプロファイルのためのＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、星状マッパー５０３０、ＳＳＤ（ｓｉｇｎａｌ  ｓｐａｃｅ  ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、及び時間インターリーバ５０５０を含むことができる。
【０１６３】
データＦＥＣエンコーダ５０１０は、入力ＢＢＦに対してＦＥＣエンコーディングを行い、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成することができる。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の動作の細部事項については後で説明する。
【０１６４】
ビットインターリーバ５０２０は、データＦＥＣエンコーダ５０１０の出力をインターリーブし、効率的に具現可能な構造を提供しながら、ＬＤＰＣコード及び変調方式の組合せによって最適化された性能を達成することができる。ビットインターリーバ５０２０の動作の細部事項については後で説明する。
【０１６５】
星状マッパー５０３０は、ＱＰＳＫ、ＱＡＭ―１６、不均一ＱＡＭ（ＮＵＱ―６４、ＮＵＱ―２５６、ＮＵＱ―１０２４）又は不均一星状（ＮＵＣ―１６、ＮＵＣ―６４、ＮＵＣ―２５６、ＮＵＣ―１０２４）を用いてベース及びハンドヘルドプロファイル内のビットインターリーバ５０２０からのそれぞれのセルワード、及びアドバンスドプロファイル内のセルワードデマルチプレクサ５０１０―１からのセルワードを変調し、パワー正規化星状ポイントを提供することができる。この星状マッピングは、ＤＰに対してのみ適用される。ＱＡＭ―１６及びＮＵＱが方形であるが、ＮＵＱは任意の形状を有する。それぞれの星状が９０度の任意の倍数だけ回転されると、回転された星状は正確に本来の星状と重畳する。この回転―感覚（ｒｏｔａｔｉｏｎ―ｓｅｎｓｅ）対称特性は、実数成分及び虚数成分の平均電力及び容量を互いに同一にする。ＮＵＱ及びＮＵＣは各コードレートに対して特別に定義され、使用される特定の一つは、ＰＬＳ２データで提出されたパラメータ（ＤＰ＿ＭＯＤ）によってシグナルされる。
【０１６６】
ＳＳＤエンコーディングブロック５０４０は、２（２Ｄ）、３（３Ｄ）、４（４Ｄ）次元でセルをプリコードし、異なるフェージング条件下で受信ロバスト性を増加させることができる。
【０１６７】
時間インターリーバ５０５０はＤＰレベルで動作することができる。時間インターリービングのパラメータはそれぞれのＤＰに対して別々に設定されてもよい。時間インターリーバ５０５０の動作の細部事項については後で説明する。
【０１６８】
アドバンスドプロファイルのためのＢＩＣＭブロックの処理ブロック５０００―１は、データＦＥＣエンコーダ、ビットインターリーバ、星状マッパー、及び時間インターリーバを含むことができる。しかし、処理ブロック５０００―１は処理ブロック５０００と区別され、セルワードデマルチプレクサ５０１０―１及びＭＩＭＯエンコーディングブロック５０２０―１をさらに含む。
【０１６９】
また、処理ブロック５０００―１のデータＦＥＣエンコーダ、ビットインターリーバ、星状マッパー及び時間インターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、星状マッパー５０３０、及び時間インターリーバ５０５０に対応するので、その説明は省略する。
【０１７０】
セルワードデマルチプレクサ５０１０―１は、アドバンスドプロファイルのＤＰに使用され、単一セルワードストリームをＭＩＭＯ処理のためのデュアルセルワードストリームに分離する。セルワードデマルチプレクサ５０１０―１の動作の細部事項については後で説明する。
【０１７１】
ＭＩＭＯエンコーディングブロック５０２０―１は、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサ５０１０―１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号の送信のために最適化された。ＭＩＭＯ技術は容量を増加させる優れた方式であるが、チャネル特性に依存する。特にブロードキャスティングに対して、別個の信号伝播特性によって誘発された２つのアンテナ間の受信された信号電力の差又はチャネルの強いＬＯＳ成分は、ＭＩＭＯから容量利得を得ることを困難にさせ得る。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの一つの回転ベースプリコーディングを位相ランダム化を用いてこの問題を克服する。
【０１７２】
ＭＩＭＯエンコーディングは、送信機及び受信機で少なくとも２つのアンテナを必要とする２ｘ２  ＭＩＭＯシステムを目的とすることができる。この提案で、２つのＭＩＭＯエンコーディングモード、すなわち、ＦＲ―ＳＭ（ｆｕｌｌ―ｒａｔｅ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）及びＦＲＦＤ―ＳＭ（ｆｕｌｌ―ｒａｔｅ  ｆｕｌｌ―ｄｉｖｅｒｓｉｔｙ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）が定義される。ＦＲ―ＳＭエンコーディングは、受信機側での比較的小さい複雑度の増加と共に容量増加を提供するが、ＦＲＦＤ―ＳＭエンコーディングは、受信機側での大きい複雑度の増加と共に容量増加及び追加のダイバーシチ利得を提供する。提案されたＭＩＭＯエンコーディング方式は、アンテナ極性構成に対する制限を有さない。
【０１７３】
ＭＩＭＯ処理はアドバンスドプロファイルフレームのために要求することができ、これは、アドバンスドプロファイルフレーム内の全てのＤＰがＭＩＭＯエンコーダによって処理されるということを意味する。ＭＩＭＯ処理はＤＰレベルで適用することができる。星状マッパー出力（ＮＵＱ）のペア（ｅ1,i及びｅ2,i）は、ＭＩＭＯエンコーダの入力に供給することができる。ＭＩＭＯエンコーダ出力のペア（ｇ1,i及びｇ2,i）は、それぞれのＴＸアンテナのＯＦＤＭシンボルｌ及び同一キャリアｋによって送信することができる。
【０１７４】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１７５】
図６は、本発明の他の実施例に係るＢＩＣＭブロックを示す。
【０１７６】
図６に示すＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の実施例に該当する。
【０１７７】
図６は、物理層シグナリング（ＰＬＳ）、非常警戒チャネル（ＥＡＣ）、及び高速情報チャネル（ＦＩＣ）の保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報を伝達するフレームの一部であり、ＦＩＣは、サービスと該当のベースＤＰとの間のマッピング情報を伝達するフレーム内の論理チャネルである。ＥＡＣ及びＦＩＣの細部事項については後で説明する。
【０１７８】
図６を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ  ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及び星状マッパー６０２０を含むことができる。
【０１７９】
また、ＰＬＳ  ＦＥＣエンコーダ６０００は、スクランブラ、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリングブロックを含むことができる。以下では、ＢＩＣＭブロックの各ブロックについて説明する。
【０１８０】
ＰＬＳ  ＦＥＣエンコーダ６０００は、スクランブルされたＰＬＳ  １／２データ、ＥＡＣ及びＦＩＣセクションをエンコードすることができる。
【０１８１】
スクランブラは、ＢＣＨエンコーディング、及び短縮及びパンクチャされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブルすることができる。
【０１８２】
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のために短縮されたＢＣＨコードを用いて、スクランブルされたＰＬＳ  １／２データに対して外部エンコーディングを行い、ＢＣＨエンコーディングの後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ＬＤＰＣエンコーディングの前にゼロ挿入の出力ビットをパーミュテート（ｐｅｒｍｕｔｅ）することができる。
【０１８３】
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコードすることができる。完全なコーディングブロック（Ｃldpc）を生成するために、パリティビット（Ｐldpc）がそれぞれのゼロ挿入ＰＬＳ情報ブロック（Ｉldpc）から組織的にエンコードされ、その後に付加される。
【０１８４】
【数１】
0006333983.tif 000005
【０１８５】
ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の表４のとおりである。
【０１８６】
【表４】
0006333983.tif 000006
【０１８７】
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。
【０１８８】
ＰＬＳ１データ保護に短縮が適用されると、任意のＬＤＰＣパリティビットはＬＤＰＣエンコーディング後にパンクチャされる。また、ＰＬＳ２データの保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディング後にパンクチャされる。これらのパンクチャされたビットは送信されない。
【０１８９】
ビットインターリーバ６０１０は、それぞれの短縮及びパンクチャされたＰＬＳ１データ及びＰＬＳ２データをインターリーブする。
【０１９０】
星状マッパー６０２０は、ビットインターリーブされたＰＬＳ１データ及びＰＬＳ２データを星状にマップすることができる。
【０１９１】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１９２】
図７は、本発明の一実施例に係るフレームビルディングブロックを示す。
【０１９３】
図７に示すフレーム生成ブロックは、図１を参照して説明したフレームビルディングブロック１０２０の実施例に該当する。
【０１９４】
図７を参照すると、フレームビルディングブロックは、遅延補償ブロック７０００、セルマッパー７０１０、及び周波数インターリーバ７０２０を含むことができる。以下では、フレームビルディングブロックの各ブロックについて説明する。
【０１９５】
遅延補償ブロック７０００は、データパイプと対応ＰＬＳデータとの間のタイミングを調節し、送信端で時間が共に合わせられるように保障することができる。ＰＬＳデータは、入力フォーマッティングブロック及びＢＩＣＭブロックによって誘発されたデータパイプの遅延を処理することによって、データパイプと同じ量だけ遅延される。ＢＩＣＭブロックの遅延は主に時間インターリーバ５０５０による。インバンドシグナリングデータは、次のＴＩグループの情報を伝達し、シグナルされるＤＰよりも１フレームだけ速く伝達される。したがって、遅延補償ブロックは、インバンドシグナリングデータを遅延させる。
【０１９６】
セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム、及びダミーセルを、フレーム内のＯＦＤＭシンボルのアクティブキャリアにマップすることができる。セルマッパー７０１０の基本機能は、もしあれば、ＤＰ、ＰＬＳセル、及びＥＡＣ／ＦＩＣセルのそれぞれに対してＴＩによって生成されたデータセルをフレーム内のＯＦＤＭシンボルのそれぞれに対応するアクティブＯＦＤＭセルのアレイにマップすることである。サービスシグナリングデータ（ＰＳＩ（ｐｒｏｇｒａｍ  ｓｐｅｃｉｆｉｃ  ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩ））は、データパイプによって個別的に集めて伝送することができる。セルマッパーは、スケジューラによって生成された動的情報及びフレーム構造の構成によって動作する。フレームの細部事項については後で説明する。
【０１９７】
周波数インターリーバ７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリーブし、周波数ダイバーシチを提供することができる。また、周波数インターリーバ７０２０は、異なるインターリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されるＯＦＤＭシンボルペアに対して動作し、単一フレーム内の最大のインターリービング利得を得ることができる。周波数インターリーバ７０２０の動作の細部事項については後で説明する。
【０１９８】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１９９】
図８は、本発明の実施例に係るＯＦＤＭ生成ブロックを示す。
【０２００】
図８に示すＯＦＤＭ生成ブロックは、図１を参照して説明したＯＦＤＭ生成ブロック１０３０の実施例に該当する。
【０２０１】
ＯＦＤＭ生成ブロックは、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、送信される時間領域信号を生成する。また、このブロックは、順次的に保護区間を挿入し、ＰＡＰＲ（Ｐｅａｋ―ｔｏ―ａｖｅｒａｇｅ  ｐｏｗｅｒ  ｒａｔｉｏ）減少処理を適用することによって最終ＲＦ信号を生成する。
【０２０２】
図８を参照すると、フレームビルディングブロックは、パイロット及び予約トーン挿入ブロック８０００、２Ｄ―ｅＳＦＮエンコーディングブロック８０１０、ＩＦＦＴ（ｉｎｖｅｒｓｅ  ｆａｓｔ  Ｆｏｕｒｉｅｒ  ｔｒａｎｓｆｏｒｍ）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、保護区間挿入ブロック８０４０、プリアンブル挿入ブロック８０５０、その他システム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。以下では、フレームビルディングブロックの各ブロックについて説明する。
【０２０３】
パイロット及び予約トーン挿入ブロック８０００は、パイロット及び予約トーンを挿入することができる。
【０２０４】
ＯＦＤＭシンボル内の様々なセルは公知の基準情報に変調され、パイロットは、受信機で先験的に知られた送信値を有する。パイロットセルの情報は、分散されたパイロット、反復パイロット、エッジパイロット、ＦＳＳ（ｆｒａｍｅ  ｓｉｇｎａｌｌｉｎｇ  ｓｙｍｂｏｌ）パイロット、及びＦＥＳ（ｆｒａｍｅ  ｅｄｇｅ  ｓｙｍｂｏｌ）パイロットで構成される。それぞれのパイロットは、パイロットタイプ及びパイロットパターンによって特定のブースティング電力レベルで送信される。パイロット情報の値は、任意の与えられたシンボル上のそれぞれの送信されたキャリアに対して一連の値である基準シーケンスから導出される。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャネル推定、送信モード識別に使用することができ、さらに、位相雑音をフォロー（ｆｏｌｌｏｗｉｎｇ）するのに使用することができる。
【０２０５】
基準シーケンスから取った基準情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳを除いた全シンボルにおいて分散されたパイロットセルで送信される。反復パイロットは、フレームの全シンボルに挿入される。反復パイロットの数及び位置はＦＦＴサイズ及び分散されたパイロットパターンに依存する。エッジキャリアは、プリアンブルシンボルを除いた全シンボル内のエッジパイロットである。これらは、スペクトルのエッジまで周波数補間を許容するために挿入される。ＦＳＳパイロットはＦＳＳに挿入され、ＦＥＳパイロットはＦＥＳに挿入される。これらはフレームのエッジまで時間補間を許容するために挿入される。
【０２０６】
本発明の実施例に係るシステムは、ＳＦＮネットワークを支援し、分散型ＭＩＳＯ方式は、選択的に非常に堅固な送信モードを支援するのに使用される。２Ｄ―ｅＳＦＮは、複数のＴＸアンテナを用いる分散型ＭＩＳＯ方式であり、それぞれのアンテナはＳＦＮネットワーク内の異なる送信側に配置される。
【０２０７】
２Ｄ―ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシチを生成するために２Ｄ―ｅＳＦＮ処理を行い、複数の送信機から送信された信号の位相を歪ませることができる。したがって、長時間の低いフラットフェージング又は深いフェージングによるバースト誤りを軽減させることができる。
【０２０８】
ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ―ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロット（又は、予約トーン）として指定されていないデータシンボル内の任意のセルは、周波数インターリーバからのデータセルのうち一つを伝達する。セルはＯＦＤＭキャリアにマップされる。
【０２０９】
ＰＡＰＲ減少ブロック８０３０は、時間領域で様々なＰＡＰＲ減少アルゴリズムを用いて入力信号に対するＰＡＰＲ減少を行うことができる。
【０２１０】
保護区間挿入ブロック８０４０は保護区間を挿入することができ、プリアンブル挿入ブロック８０５０は、信号の前にプリアンブルを挿入することができる。プリアンブルの構造の細部事項については後で説明する。他のシステム挿入ブロック８０６０は、時間領域で複数の放送送受信システムの信号をマルチプレクスし、放送サービスを提供する２つ以上の別個の放送送信／受信システムのデータが同一のＲＦ信号帯域で同時に送信され得る。この場合、２つ以上の別個の放送送受信システムとは、別個の放送サービスを提供するシステムのことをいう。別個の放送サービスは、地上波放送サービス、モバイル放送サービスなどを称する。それぞれの放送サービスに関連したデータは別個のフレームを介して送信されてもよい。
【０２１１】
ＤＡＣブロック８０７０は、入力デジタル信号をアナログ信号に変換し、アナログ信号を出力することができる。ＤＡＣブロック８０７０から出力された信号は、物理層プロファイルによって複数の出力アンテナを介して送信されてもよい。本発明の実施例に係るＴＸアンテナは、垂直又は水平の極性を有することができる。
【０２１２】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０２１３】
図９は、本発明の実施例に係る将来の放送サービスのための放送信号を受信する装置の構造を示す。
【０２１４】
本発明の実施例に係る将来の放送サービスのための放送信号を受信する装置は、図１を参照して説明した将来の放送サービスのために放送信号を送信する装置に対応し得る。
【０２１５】
本発明の実施例に係る将来の放送サービスのための放送信号を受信する装置は、同期化及び復調モジュール９０００、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０、及びシグナリングデコーディングモジュール９０４０を含むことができる。以下では、放送信号を受信する装置の各モジュールの動作について説明する。
【０２１６】
同期化及び復調モジュール９０００は、ｍ個のＲｘアンテナを介して入力信号を受信し、放送信号を受信する装置に対応するシステムに対して信号検出及び同期化を行い、放送信号を送信する装置によって行われる手順の逆手順に対応する復調を行うことができる。
【０２１７】
フレームパーシングモジュール９０１０は、入力信号フレームをパースし、ユーザによって選択されたサービスが送信されるデータを抽出することができる。放送信号を送信する装置がインターリービングを行うと、フレームパーシングモジュール９０１０は、インターリービングの逆手順に対応するデインターリービングを行うことができる。この場合、抽出される必要がある信号及びデータの位置は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードし、放送信号を送信する装置によって生成されたスケジューリング情報を回復することによって得ることができる。
【０２１８】
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によってデインターリーブすることができる。デマッピング及びデコーディングモジュール９０２０は、送信効率のために適用されたマッピングに対してデマッピングを行い、デコーディングを通じて送信チャネルに対して生成された誤りを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって、デマッピング及びデコーディングに必要な送信パラメータを得ることができる。
【０２１９】
出力プロセッサ９０３０は、放送信号を送信し、送信効率を改善する装置によって適用される様々な圧縮／信号処理手順の逆手順を行うことができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータから必要な制御情報を得ることができる。出力プロセッサ９０３０の出力は、放送信号を送信する装置に入力される信号に対応し、ＭＰＥＧ―ＴＳ、ＩＰストリーム（ｖ４又はｖ６）及び一般ストリームであってもよい。
【０２２０】
シグナリングデコーディングモジュール９０４０は、同期化及び復調モジュール９０００によって復調された信号からＰＬＳ情報を得ることができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０及び出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。
【０２２１】
図１０は、本発明の一実施例に係るフレーム構造を示す。
【０２２２】
図１０は、スーパーフレーム内のフレームタイプ及びＦＲＵの例示的な構成を示す。（ａ）は、本発明の実施例に係るスーパーフレームを示し、（ｂ）は、本発明の実施例に係るＦＲＵ（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ）を示し、（ｃ）は、ＦＲＵ内の可変ＰＨＹプロファイルのフレームを示し、（ｄ）は、フレームの構造を示す。
【０２２３】
スーパーフレームは８個のＦＲＵで構成することができる。ＦＲＵは、フレームのＴＤＭのための基本マルチプレクシング単位であり、スーパーフレーム内で８回反復される。
【０２２４】
ＦＲＵ内の各フレームはＰＨＹプロファイル（ベース、ハンドヘルド、アドバンスド）及びＦＥＦのうち一つに属する。ＦＲＵ内のフレームの最大許容数は４であり、与えられたＰＨＹプロファイルは、ＦＲＵ（例えば、ベース、ベース、ハンドヘルド、アドバンスド）において０倍〜４倍までの任意の回数だけ示すことができる。ＰＨＹプロファイルの定義は、必要時には、プリアンブル内のＰＨＹ＿ＰＲＯＦＩＬＥの予約値を用いて拡張されてもよい。
【０２２５】
ＦＥＦ部分は、含まれるなら、ＦＲＵの終わりに挿入される。ＦＥＦがＦＲＵに含まれる場合、スーパーフレームにおいてＦＥＦの最小数は８である。ＦＥＦ部分が互いに隣接することは推薦されない。
【０２２６】
また、一つのフレームは、複数のＯＦＤＭシンボル及びプリアンブルに分離される。（ｄ）に示したように、フレームは、プリアンブル、一つ以上のフレームシグナリングシンボル（ＦＳＳ）、正常データシンボル、及びフレームエッジシンボルＦＥＳを含む。
【０２２７】
プリアンブルは、高速フューチャキャストＵＴＢシステム信号検出が可能であり、信号の効率的な送受信のための基本送信パラメータのセットを提供する特殊シンボルである。プリアンブルについては後で詳細に説明する。
【０２２８】
ＦＳＳの主要目的は、ＰＬＳデータを伝達することである。高速同期化及びチャネル推定、及びＰＬＳデータの高速デコーディングのために、ＦＳＳは、正常データシンボルより密集したパイロットパターンを有する。ＦＥＳは正確にＦＳＳと同じパイロットを有し、これは、ＦＥＳ直前のシンボルに対して外挿することなく、ＦＥＳ内の周波数専用補間及び時間補間を可能にする。
【０２２９】
図１１は、本発明の実施例に係るフレームのシグナリング層構造を示す。
【０２３０】
図１１は、３個の主要部分、すなわち、プリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０、及びＰＬＳ２データ１１０２０に分離されたシグナリング層構造を示す。全てのフレームでプリアンブルシンボルによって伝達されるプリアンブルの目的は、そのフレームの送信タイプ及び基本送信パラメータを指示することである。ＰＬＳ１は、受信機がＰＬＳ２データにアクセスして、このデータをデコーティングさせ、これは、関心のあるＤＰにアクセスするパラメータを含む。ＰＬＳ２は全てフレームで伝達され、２つの主要部分、ＰＬＳ２―ＳＴＡＴデータとＰＬＳ２―ＤＹＮデータとに分離される。ＰＬＳ２データの静的及び動的部分には必要時にパディングが続く。
【０２３１】
図１２は、本発明の実施例に係るプリアンブルシグナリングデータを示す。
【０２３２】
プリアンブルシグナリングデータは、フレーム構造内で受信機がＰＬＳデータにアクセスし、ＤＰを追跡させるのに必要な情報の２１ビットを伝達する。プリアンブルシグナリングの細部事項は次のとおりである。
【０２３３】
ＰＨＹ＿ＰＲＯＦＩＬＥ：この３ビットフィールドは、現フレームのＰＨＹプロファイルタイプを示す。異なるＰＨＹプロファイルタイプのマッピングは、以下の表５に与えられる。
【０２３４】
【表５】
0006333983.tif 000007
【０２３５】
ＦＦＴ＿ＳＩＺＥ：この２ビットフィールドは、以下の表６に記載したように、フレームグループ内の現フレームのＦＦＴサイズを示す。
【０２３６】
【表６】
0006333983.tif 000008
【０２３７】
ＧＩ＿ＦＲＡＣＴＩＯＮ：この３ビットフィールドは、以下の表７に記載したように、現スーパーフレーム内の保護区間分数（ｆｒａｃｔｉｏｎ）値を示す。
【０２３８】
【表７】
0006333983.tif 000009
【０２３９】
ＥＡＣ＿ＦＬＡＧ：この１ビットフィールドは、ＥＡＣが現フレームに提供されるか否かを示す。このフィールドが“１”に設定されると、ＥＡＳ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｓｅｒｖｉｃｅ）が現フレームで提供される。このフィールドが“０”に設定されると、ＥＡＳが現フレームで伝達されない。このフィールドはスーパーフレーム内で動的にスイッチされてもよい。
【０２４０】
ＰＩＬＯＴ＿ＭＯＤＥ：この１ビットフィールドは、パイロットモードが現フレームグループ内の現フレームに対してモバイルモードなのか又は固定モードなのかを指示する。このフィールドが“０”に設定されると、モバイルパイロットモードが使用される。フィールドが“１”に設定されると、固定パイロットモードが使用される。
【０２４１】
ＰＡＰＲ＿ＦＬＡＧ：この１ビットフィールドは、ＰＡＰＲ減少が現フレームグループ内の現フレームに使用されるか否かを示す。このフィールドが“１”に設定されると、ＰＡＰＲ減少にトーン予約（ｔｏｎｅ  ｒｅｓｅｒｖａｔｉｏｎ）が使用される。このフィールドが“０”に設定されると、ＰＡＰＲ減少が使用されない。
【０２４２】
ＦＲＵ＿ＣＯＮＦＩＧＵＲＥ：この３ビットフィールドは、現スーパーフレーム内に存在するＦＲＵ（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ）のＰＨＹプロファイルタイプ構成を示す。現スーパーフレームで伝達される全プロファイルタイプは、現スーパーフレーム内の全フレーム内のこのフィールドで識別される。３ビットフィールドは、以下の表８に示すように、それぞれのプロファイルに対する異なる定義を有する。
【０２４３】
【表８】
0006333983.tif 000010
【０２４４】
ＲＥＳＥＲＶＥＤ：この７ビットフィールドは、将来の使用のために予約される。
【０２４５】
図１３は、本発明の実施例に係るＰＬＳ１データを示す。
【０２４６】
ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするのに必要なパラメータを含む基本送信パラメータを提供する。前述したように、ＰＬＳ１データは、一つのフレームグループの全デューレーションにおいて変更されない。ＰＬＳ１データのシグナリングフィールドの詳細な定義は次のとおりである。
【０２４７】
ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：この２０ビットフィールドは、ＥＡＣ＿ＦＬＡＧを除いたプリアンブルシグナリングデータのコピーである。
【０２４８】
ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：この２ビットフィールドは、ＦＲＵ当たりのフレームの数を示す。
【０２４９】
ＰＡＹＬＯＡＤ＿ＴＹＰＥ：この３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを指示する。ＰＡＹＬＯＡＤ＿ＴＹＰＥは、表９に示すようにシグナルされる。
【０２５０】
【表９】
0006333983.tif 000011
【０２５１】
ＮＵＭ＿ＦＳＳ：この２ビットフィールドは、現フレーム内のＦＳＳシンボルの数を示す。
【０２５２】
ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：この８ビットフィールドは、送信された信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは、２つの４ビットフィールド、すなわち、メジャーバージョン及びマイナーバージョンに分離される。
【０２５３】
メジャーバージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢ  ４ビットは、メジャーバージョン情報を示す。メジャーバージョンフィールドの変化は、非―下位―互換（ｎｏｎ―ｂａｃｋｗａｒｄ―ｃｏｍｐａｔｉｂｌｅ）変化を示す。デフォルト値は“００００”である。この標準に記載のバージョンにおいて、値は“００００”に設定される。
【０２５４】
マイナーバージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢ  ４ビットは、マイナーバージョン情報を示す。マイナーバージョンフィールドの変化は、下位互換性である。
【０２５５】
ＣＥＬＬ＿ＩＤ：これは、ＡＴＳＣネットワークで地理的なセルを固有に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジ領域は、フューチャキャストＵＴＢシステムに使用される周波数の数に依存し、一つ以上の周波数で構成されてもよい。ＣＥＬＬ＿ＩＤの値が知られていないか又は特定されていないと、このフィールドは“０”に設定される。
【０２５６】
ＮＥＴＷＯＲＫ＿ＩＤ：これは、現ＡＴＳＣネットワークを固有に識別する１６ビットフィールドである。
【０２５７】
ＳＹＳＴＥＭ＿ＩＤ：この１６ビットフィールドは、ＡＴＳＣネットワーク内のフューチャキャストＵＴＢシステムを固有に識別する。フューチャキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。フューチャキャストＵＴＢシステムは、もしあれば、一つ以上のＰＨＹプロファイル及びＦＥＴを伝達する。同じフューチャキャストＵＴＢシステムは、別個の入力ストリームを伝達することができ、別個の地理的領域で別個のＲＦ周波数を使用してローカルサービス挿入を許容する。フレーム構造及びスケジューリングは一つの場所で制御され、フューチャキャストＵＴＢシステム内で全ての送信に対して同一である。一つ以上のフューチャキャストＵＴＢシステムは、いずれも同一の物理層構造及び構成を有することを意味する同一のＳＹＳＴＥＭ＿ＩＤを有することができる。
【０２５８】
次のループは、各フレームタイプのＦＲＵ構成及び長さを示すが、使用されるＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、及びＲＥＳＥＲＶＥＤで構成される。ループサイズは固定され、４個のＰＨＹプロファイル（ＦＥＦを含む）がＦＲＵ内でシグナルされる。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４より小さいと、使用されていないフィールドはゼロで埋められる。
【０２５９】
ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：この３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目（ｉは、ループインデックスである）のフレームのＰＨＹプロファイルタイプを示す。このフィールドは、表８に示したように、同じシグナリングフォーマットを使用する。
【０２６０】
ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：この２ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを用いて、フレームデューレーションの正確な値が得られる。
【０２６１】
ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：この３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの保護区間分数値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは、表７に従ってシグナルされる。
【０２６２】
ＲＥＳＥＲＶＥＤ：この４ビットフィールドは、将来の使用のために予約される。
【０２６３】
次のフィールドは、ＰＬＳ２データをデコードするパラメータを提供する。
【０２６４】
ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：この２ビットフィールドは、ＰＬＳ２保護によって使用されるＦＥＣタイプを示す。ＦＥＣタイプは、表１０に従ってシグナルされる。ＬＤＰＣコードの細部事項は後で説明する。
【０２６５】
【表１０】
0006333983.tif 000012
【０２６６】
ＰＬＳ２＿ＭＯＤ：この３ビットフィールドは、ＰＬＳ２によって使用される変調タイプを示す。変調タイプは表１１に従ってシグナルされる。
【０２６７】
【表１１】
0006333983.tif 000013
【０２６８】
ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：この１５ビットフィールドは、現フレームグループで伝達されるＰＬＳ２に対するフルコーディングブロック（ｆｕｌｌ  ｃｏｄｅｄ  ｂｌｏｃｋｓ）の集合（ｃｏｌｌｅｃｔｉｏｎ）のサイズ（ＱＡＭセルの数として特定される。）（Ｃtotal_partial_block）を示す。この値は、現フレームグループの全デューレーションにおいて一定である。
【０２６９】
ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：この１４ビットフィールドは、現フレームグループに対するＰＬＳ２―ＳＴＡＴのビットサイズを示す。この値は、現フレームグループの全デューレーションにおいて一定である。
【０２７０】
ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：この１４ビットフィールドは、現フレームグループに対するＰＬＳ２―ＤＹＮのビットサイズを示す。この値は、現フレームグループの全デューレーションにおいて一定である。
【０２７１】
ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：この１ビットフラグは、現フレームグループでＰＬＳ２反復モードが使用されるか否かを示す。このフィールドが値“１”に設定されると、ＰＬＳ２反復モードが活性化される。このフィールドが値“０”に設定されると、ＰＬＳ２反復モードが非活性化される。
【０２７２】
ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２反復が使用されるとき、現フレームグループの全フレームで伝達されるＰＬＳ２に対する部分コーディングブロック（ｐａｒｔｉａｌ  ｃｏｄｅｄ  ｂｌｏｃｋｓ）の集合（ｃｏｌｌｅｃｔｉｏｎ）のサイズ（ＱＡＭセルの数として特定される。）（Ｃtotal_partial_block）を示す。反復が使用されない場合、このフィールドの値は０と同一である。この値は、現フレームグループの全デューレーションにおいて一定である。
【０２７３】
ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：この２ビットフィールドは、次のフレームグループの全フレームで伝達されるＰＬＳ２に使用されるＦＥＣタイプを示す。ＦＥＣタイプは表１０に従ってシグナルされる。
【０２７４】
ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：この３ビットフィールドは、次のフレームグループの全フレームで伝達されるＰＬＳ２に使用される変調タイプを示す。変調タイプは表１１に従ってシグナルされる。
【０２７５】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：この１ビットフラグは、次のフレームグループでＰＬＳ２反復モードが使用されるか否かを示す。このフィールドが値“１”に設定されると、ＰＬＳ２反復モードが活性化される。このフィールドが値“０”に設定されると、ＰＬＳ２反復モードが非活性化される。
【０２７６】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２反復が使用されるとき、次のフレームグループの全フレームで伝達されるＰＬＳ２に対するフルコーディングブロック（ｆｕｌｌ  ｃｏｄｅｄ  ｂｌｏｃｋｓ）の集合（ｃｏｌｌｅｃｔｉｏｎ）のサイズ（ＱＡＭセルの数として特定される。）（Ｃtotal_full_block）を示す。次のフレームグループで反復が使用されない場合、このフィールドの値は０と同一である。この値は現フレームグループの全デューレーションにおいて一定である。
【０２７７】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：この１４ビットフィールドは、次のフレームグループに対するＰＬＳ２―ＳＴＡＴのビットサイズを示す。この値は、現フレームグループで一定である。
【０２７８】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：この１４ビットフィールドは、次のフレームグループに対するＰＬＳ２―ＤＹＮのビットサイズを示す。この値は、現フレームグループで一定である。
【０２７９】
ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：この２ビットフィールドは、現フレームグループ内のＰＬＳ２に追加のパリティが提供されるか否かを示す。この値は、現フレームグループの全デューレーションにおいて一定である。下記の表１２は、このフィールドの値を示す。このフィールドが“００”に設定されると、現フレームグループでＰＬＳ２に対して追加のパリティが使用されない。
【０２８０】
【表１２】
0006333983.tif 000014
【０２８１】
ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２の追加のパリティビットのサイズ（ＱＡＭセルの数として特定される。）を示す。この値は、現フレームグループの全デューレーションにおいて一定である。
【０２８２】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：この２ビットフィールドは、次のフレームグループでＰＬＳ２に追加のパリティが提供されるか否かを示す。この値は、現フレームグループの全デューレーションにおいて一定である。表１２は、このフィールドの値を定義する。
【０２８３】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：この１５ビットフィールドは、次のフレームグループの全フレームでＰＬＳ２の追加のパリティビットのサイズ（ＱＡＭセルの数として特定される。）を示す。この値は、現フレームグループの全デューレーションにおいて一定である。
【０２８４】
ＲＥＳＥＲＶＥＤ：この３２ビットフィールドは、将来の使用のために予約される。
【０２８５】
ＣＲＣ＿３２：全ＰＬＳ１シグナリングに適用される３２ビット誤り検出コード
【０２８６】
図１４は、本発明の実施例に係るＰＬＳ２データを示す。
【０２８７】
図１４は、ＰＬＳ２データのＰＬＳ２―ＳＴＡＴデータを示す。ＰＬＳ２―ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２―ＤＹＮデータは現フレームに特定された情報を提供する。
【０２８８】
ＰＬＳ２―ＳＴＡＴデータのフィールドの細部事項は、次の通りである。
【０２８９】
ＦＩＣ＿ＦＬＡＧ：この１ビットフィールドは、ＦＩＣが現フレームグループに使用されるか否かを示す。このフィールドが“１”に設定されると、ＦＩＣが現フレームで提供される。このフィールドが“０”に設定されると、ＦＩＣが現フレームで伝達されない。この値は、現フレームグループの全デューレーションにおいて一定である。
【０２９０】
ＡＵＸ＿ＦＬＡＧ：この１ビットフィールドは、現フレームグループで補助ストリームが使用されるか否かを示す。このフィールドが“１”に設定されると、補助ストリームは現フレームで提供される。このフィールドが“０”に設定されると、補助フレームが現フレームで伝達されない。この値は、現フレームグループの全デューレーションにおいて一定である。
【０２９１】
ＮＵＭ＿ＤＰ：この６ビットフィールドは、現フレームで伝達されるＤＰの数を示す。このフィールドの値は１〜６４の範囲内にあり、ＤＰの数はＮＵＭ＿ＤＰ＋１である。
【０２９２】
ＤＰ＿ＩＤ：この６ビットフィールドは、ＰＨＹプロファイル内でＤＰを固有に識別する。
【０２９３】
ＤＰ＿ＴＹＰＥ：この３ビットフィールドは、ＤＰのタイプを示す。これは、下記の表１３に従ってシグナルされる。
【０２９４】
【表１３】
0006333983.tif 000015
【０２９５】
ＤＰ＿ＧＲＯＵＰ＿ＩＤ：この８ビットフィールドは、現ＤＰが関連しているＤＰグループを識別する。これは、受信機が特定サービスと関連しているサービスコンポーネントのＤＰにアクセスするのに使用することができ、これらＤＰは、同じＤＰ＿ＧＲＯＵＰ＿ＩＤを有する。
【０２９６】
ＢＡＳＥ＿ＤＰ＿ＩＤ：この６ビットフィールドは、管理層で使用されるサービスシグナリングデータ（ＰＳＩ／ＳＩ）を伝達するＤＰを示す。ＢＡＳＥ＿ＤＰ＿ＩＤで指示されたＤＰは、サービスシグナリングデータのみを伝達する専用ＤＰ、又はサービスデータと共にサービスシグナリングデータを伝達する正常ＤＰであってもよい。
【０２９７】
ＤＰ＿ＦＥＣ＿ＴＹＰＥ：この２ビットフィールドは、関連したＤＰによって使用されるＦＥＣタイプを示す。ＦＥＣタイプは、下記の表１４に従ってシグナルされる。
【０２９８】
【表１４】
0006333983.tif 000016
【０２９９】
ＤＰ＿ＣＯＤ：この４ビットフィールドは、関連したＤＰによって使用されるコードレートを示す。コードレートは、以下の表１５に従ってシグナルされる。
【０３００】
【表１５】
0006333983.tif 000017
【０３０１】
ＤＰ＿ＭＯＤ：この４ビットフィールドは、関連したＤＰによって使用される変調を示す。変調は、以下の表１６に従ってシグナルされる。
【０３０２】
【表１６】
0006333983.tif 000018
【０３０３】
ＤＰ＿ＳＳＤ＿ＦＬＡＧ：この１ビットフィールドは、ＳＳＤモードが関連したＤＰで使用されるか否かを示す。このフィールドが値“１”に設定されると、ＳＳＤが使用される。このフィールドが値“０”に設定されると、ＳＳＤが使用されない。
【０３０４】
ＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す“０１０”と同一である場合にのみ次のフィールドが表れる。
【０３０５】
ＤＰ＿ＭＩＭＯ：この３ビットフィールドは、関連したＤＰにいずれのタイプのＭＩＭＯエンコーディングプロセスが適用されるのかを示す。ＭＩＭＯエンコーディングプロセスタイプは、表１７に従ってシグナルされる。
【０３０６】
【表１７】
0006333983.tif 000019
【０３０７】
ＤＰ＿ＴＩ＿ＴＹＰＥ：この１ビットフィールドは、時間インターリービングのタイプを示す。“０”の値は、一つのＴＩグループが一つのフレームに対応し、一つ以上のＴＩブロックを含むことを示す。“１”の値は、一つのＴＩグループが１より多いフレームで伝達され、ただ一つのＴＩブロックのみを含むことを示す。
【０３０８】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：２ビットフィールドの使用（許容される値は、ただ１、２、４、８である。）は、次のようにＤＰ＿ＴＩ＿ＴＹＰＥフィールド内に設定される値によって決定される。
【０３０９】
ＤＰ＿ＴＩ＿ＴＹＰＥが値“１”に設定されると、このフィールドは、ＰＩ、すなわち、各ＴＩグループがマップされるフレームの数を示し、ＴＩグループ当たりに一つのＴＩブロックがある（ＮTI＝１）。２ビットフィールドを有する許容されたＰI値は、以下の表１８で定義される。
【０３１０】
ＤＰ＿ＴＩ＿ＴＹＰＥが“０”に設定されると、このフィールドは、ＴＩグループ当たりのＴＩブロックの数（ＮTI）を示し、フレーム当たりに一つのＴＩグループがある（ＰI＝１）。２ビットフィールドを有する許容されたＰI値は、以下の表１８で定義される。
【０３１１】
【表１８】
0006333983.tif 000020
【０３１２】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：この２ビットフィールドは、関連したＤＰに対するフレームグループ内のフレーム区間（ＩJUMP）を示し、許容される値は１、２、４、８である（対応する２ビットフィールドはそれぞれ“００”、“０１”、“１０”、“１１”である）。フレームグループの全フレームで表れないＤＰに対して、このフィールドの値は、連続的なフレーム間の間隔と同一である。例えば、ＤＰがフレーム１、５、９、１３などで表れると、このフィールドは“４”に設定される。全フレームで表れるＤＰに対して、このフィールドは“１”に設定される。
【０３１３】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：この１ビットフィールドは、時間インターリーバ５０５０の利用可能性を決定する。ＤＰに対して時間インターリービングが使用されないと、これは“１”に設定される。時間インターリービングが使用されると、これは“０”に設定される。
【０３１４】
ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：この５ビットフィールドは、現ＤＰが発生するスーパーフレームの第１フレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は、０〜３１の範囲内にある。
【０３１５】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：この１０ビットフィールドは、このＤＰに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。このフィールドの値はＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同じ範囲を有する。
【０３１６】
ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：この２ビットフィールドは、与えられたＤＰによって伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは、以下の表１９に従ってシグナルされる。
【０３１７】
【表１９】
0006333983.tif 000021
【０３１８】
ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：この２ビットフィールドは、現ＤＰがインバンドシグナリング情報を伝達するか否かを示す。インバンドシグナリングタイプは、以下の表２０に従ってシグナルされる。
【０３１９】
【表２０】
0006333983.tif 000022
【０３２０】
ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：この２ビットフィールドは、与えられたＤＰによって伝達されるペイロードのプロトコルタイプを示す。入力ペイロードタイプが選択されると、以下の表２１に従ってシグナルされる。
【０３２１】
【表２１】
0006333983.tif 000023
【０３２２】
ＤＰ＿ＣＲＣ＿ＭＯＤＥ：この２ビットフィールドは、入力フォーマッティングブロックでＣＲＣエンコーディングが使用されるか否かを示す。ＣＲＣモードは、以下の表２２に従ってシグナルされる。
【０３２３】
【表２２】
0006333983.tif 000024
【０３２４】
ＤＮＰ＿ＭＯＤＥ：この２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（“００”）に設定されるとき、関連したＤＰによって使用されるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、以下の表２３に従ってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（“００”）でなければ、ＤＮＰ＿ＭＯＤＥは値“００”に設定される。
【０３２５】
【表２３】
0006333983.tif 000025
【０３２６】
ＩＳＳＹ＿ＭＯＤＥ：この２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（“００”）に設定されるとき、関連したＤＰによって使用されるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、以下の表２４に従ってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（“００”）でなければ、ＩＳＳＹ＿ＭＯＤＥは値“００”に設定される。
【０３２７】
【表２４】
0006333983.tif 000026
【０３２８】
ＨＣ＿ＭＯＤＥ＿ＴＳ：この２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（“００”）に設定されるとき、関連したＤＰによって使用されるＴＳヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、以下の表２５に従ってシグナルされる。
【０３２９】
【表２５】
0006333983.tif 000027
【０３３０】
ＨＣ＿ＭＯＤＥ＿ＩＰ：この２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（“０１”）に設定されるときのＩＰヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは、以下の表２６に従ってシグナルされる。
【０３３１】
【表２６】
0006333983.tif 000028
【０３３２】
ＰＩＤ：この１３ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（“００”）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが“０１”又は“１０”に設定されるときのＴＳヘッダー圧縮のためのＰＩＤ番号を示す。
【０３３３】
ＲＥＳＥＲＶＥＤ：この８ビットフィールドは、将来の使用のために予約される。
【０３３４】
ＦＩＣ＿ＦＬＡＧが“１”と同一である場合にのみ次のフィールドが表れる。
【０３３５】
ＦＩＣ＿ＶＥＲＳＩＯＮ：この８ビットフィールドは、ＦＩＣのバージョン番号を示す。
【０３３６】
ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：この１３ビットフィールドは、ＦＩＣのバイト長さを示す。
【０３３７】
ＲＥＳＥＲＶＥＤ：この８ビットフィールドは、将来の使用のために予約される。
【０３３８】
ＡＵＸ＿ＦＬＡＧが“１”と同一である場合にのみ次のフィールドが表れる。
【０３３９】
ＮＵＭ＿ＡＵＸ：この４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが使用されないことを示す。
【０３４０】
ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：この８ビットフィールドは、将来の使用のために予約される。
【０３４１】
ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：この４ビットは、現補助ストリームのタイプを示すための将来の使用のために予約される。
【０３４２】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：この２８ビットフィールドは、補助ストリームをシグナルするための将来の使用のために予約される。
【０３４３】
図１５は、本発明の他の実施例に係るＰＬＳ２データを示す。
【０３４４】
図１５は、ＰＬＳ２データのＰＬＳ２―ＤＹＮデータを示す。ＰＬＳ２―ＤＹＮデータの値は一つのフレームグループのデューレーションにおいて変化してもよいが、フィールドのサイズは一定に維持される。
【０３４５】
ＰＬＳ２―ＤＹＮデータのフィールドの細部事項は、次のとおりである。
【０３４６】
ＦＲＡＭＥ＿ＩＮＤＥＸ：この５ビットフィールドは、スーパーフレーム内の現フレームのフレームインデックスを示す。スーパーフレームの第１フレームのインデックスは“０”に設定される。
【０３４７】
ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：この４ビットフィールドは、構成が変更される前のスーパーフレームの数を示す。構成において変更された次のスーパーフレームは、このフィールド内でシグナルされる値によって指示される。このフィールドが値“００００”に設定されると、スケジュールされた変化が予想されないことを意味し、値“１”は、次のスーパーフレームで変化があることを意味する。
【０３４８】
ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：この４ビットフィールドは、構成（すなわち、ＦＩＣの内容）が変更される前のスーパーフレームの数を示す。構成において変更された次のスーパーフレームは、このフィールド内でシグナルされる値によって指示される。このフィールドが値“００００”に設定されると、スケジュールされた変化が予想されないことを意味し、値“０００１”は、次のスーパーフレームで変化があることを意味する。
【０３４９】
ＲＥＳＥＲＶＥＤ：この１６ビットフィールドは、将来の使用のために予約される。
【０３５０】
ＮＵＭ＿ＤＰを通じてループで次のフィールドが表れ、これは、現フレームで伝達されるＤＰと関連したパラメータを示す。
【０３５１】
ＤＰ＿ＩＤ：この６ビットフィールドは、ＰＨＹプロファイル内のＤＰを固有に指示する。
【０３５２】
ＤＰ＿ＳＴＡＲＴ：この１５ビット（又は１３ビット）フィールドは、ＤＰＵアドレシング方式を用いて第１ＤＰの開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、以下の表２７に示すように、ＰＨＹプロファイル及びＦＦＴサイズによって異なる長さを有する。
【０３５３】
【表２７】
0006333983.tif 000029
【０３５４】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：この１０ビットフィールドは、現ＤＰに対する現ＴＩグループ内のＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値は、０〜１０２３の範囲内にある。
【０３５５】
ＲＥＳＥＲＶＥＤ：この８ビットフィールドは、将来の使用のために予約される。
【０３５６】
次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。
【０３５７】
ＥＡＣ＿ＦＬＡＧ：この１ビットフィールドは、現フレーム内のＥＡＣの存在を示す。このビットは、プリアンブル内のＥＡＣ＿ＦＬＡＧと同じ値である。
【０３５８】
ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：この８ビットフィールドは、ウェイクアップ指示のバージョン番号を示す。
【０３５９】
ＥＡＣ＿ＦＬＡＧフィールドが“１”に等しいと、次の１２ビットはＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドに対して割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが“０”に等しいと、次の１２ビットはＥＡＣ＿ＣＯＵＮＴＥＲに対して割り当てられる。
【０３６０】
ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：この１２ビットフィールドは、ＥＡＣのバイト長さを示す。
【０３６１】
ＥＡＣ＿ＣＯＵＮＴＥＲ：この１２ビットフィールドは、ＥＡＣが到達するフレーム前のフレームの数を示す。
【０３６２】
ＡＵＸ＿ＦＬＡＧフィールドが“１”と同一である場合にのみ次のフィールドが表れる。
【０３６３】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：この４８ビットフィールドは、補助ストリームをシグナルするための将来の使用のために予約される。このフィールドの意味は、構成可能なＰＬＳ２―ＳＴＡＴ内のＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。
【０３６４】
ＣＲＣ＿３２：全ＰＬＳ２に適用される３２ビット誤り検出コード。
【０３６５】
図１６は、本発明の実施例に係るフレームの論理構造を示す。
【０３６６】
前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム及びダミーセルは、フレーム内のＯＦＤＭシンボルのアクティブキャリアにマップされる。ＰＬＳ１及びＰＬＳ２は、初めには一つ以上のＦＳＳにマップされる。その後、もしあれば、ＥＡＣセルがＰＬＳフィールドの直後にマップされ、その後、もしあれば、ＦＩＣセルがマップされる。もしあれば、ＤＰは、ＰＬＳ又はＥＡＣ、ＦＩＣ後にマップされる。タイプ１  ＤＰが初めて続き、その次にタイプ２  ＤＰが続く。ＤＰのタイプの細部事項は後で説明する。任意の場合、ＤＰは、ＥＡＳのための任意の特殊データ又はサービスシグナリングデータを伝達することができる。もしあれば、補助ストリーム又はストリームがＤＰに続き、その後、ダミーセルが続く。これらの全てを前述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム、及びダミーセルの順にマップすると、フレーム内のセル容量を正確に満たす。
【０３６７】
図１７は、本発明の実施例に係るＰＬＳマッピングを示す。
【０３６８】
ＰＬＳセルは、ＦＳＳのアクティブキャリアにマップされる。ＰＬＳによって占有されたセルの数に依存し、一つ以上のシンボルがＦＳＳとして指定され、ＦＳＳの数（ＮFSS）は、ＰＬＳ１内のＮＵＭ＿ＦＳＳによってシグナルされる。ＦＳＳは、ＰＬＳセルを伝達する特殊シンボルである。ロバスト性及びレイテンシ（ｌａｔｅｎｃｙ）はＰＬＳの重要な問題であるため、ＦＳＳは、ＦＳＳ内の周波数専用補間及び高速同期化を許容するより高い密度のパイロットを有する。
【０３６９】
ＰＬＳセルは、図１７の例に示すように、トップ―ダウン（ｔｏｐ―ｄｏｗｎ）方式でＮFSS個のＦＳＳのアクティブキャリアにマップされる。ＰＬＳ１セルは、まず、セルインデックスの昇順で第１ＦＳＳの第１セルからマップされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後にマップされ、第１ＦＳＳの最後のセルインデックスまでマッピングが下向きに続く。要求されるＰＬＳセルの全数が一つのＦＳＳのアクティブキャリアの数を超えると、マッピングは次のＦＳＳに進められ、第１ＦＳＳと正確に同じ方式で続けて行われる。
【０３７０】
ＰＬＳマッピングが完了した後、ＤＰが次に伝達される。ＥＡＣ、ＦＩＣ、又は両方が現フレームに存在すると、これらはＰＬＳと“正常”ＤＰとの間に配置される。
【０３７１】
図１８は、本発明の実施例に係るＥＡＣマッピングを示す。
【０３７２】
ＥＡＣは、ＥＡＳメッセージを伝達する専用チャネルであり、ＥＡＳに対するＤＰにリンクされる。ＥＡＳ支援は提供されるが、ＥＡＣ自体は全てのフレームに存在してもよく、存在しなくてもよい。もしあれば、ＥＡＣは、ＰＬＳ２セルの直後にマップされる。ＥＡＣがＰＬＳセル以外にＦＩＣ、ＤＰ、補助ストリーム及びダミーセルのうちいずれの後にも来ない。ＥＡＣセルのマッピング手順はＰＬＳと正確に同一である。
【０３７３】
ＥＡＣセルは、図１８に示すように、セルインデックスの昇順でＰＬＳ２の次のセルからマップされる。ＥＡＳメッセージの大きさによって、ＥＡＣセルは、図１８に示すように、いくつかのシンボルを占める。
【０３７４】
ＥＡＣセルは、ＰＬＳ２の最後のセルの直後にマップされ、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向きに続けて行われる。要求されるＥＡＣセルの全数が最後のＦＳＳの残りのアクティブキャリアの数を超えると、マッピングは次のシンボルに進められ、ＦＳＳと正確に同じ方式で続けて行われる。この場合のマッピングのための次のシンボルは正常データシンボルであり、これは、ＦＳＳより多くのアクティブキャリアを有する。
【０３７５】
ＥＡＣマッピングが完了した後、存在するなら、ＦＩＣが次に伝達される。（ＰＬＳ２フィールドでシグナリングされることによって）ＦＩＣが送信されないと、ＤＰはＥＡＣの最後のセルの直後にマップされる。
【０３７６】
図１９は、本発明の実施例に係るＦＩＣマッピングを示す。
【０３７７】
（ａ）は、ＥＡＣ無しのＦＩＣセルの例示的なマッピングを示し、（ｂ）は、ＥＡＣがあるＦＩＣセルの例示的なマッピングを示す。
【０３７８】
ＦＩＣは、高速サービス取得及びチャネルスキャンを可能にする層間（ｃｒｏｓｓ―ｌａｙｅｒ）情報に対する専用チャネルである。この情報は主に、各ブロードキャスタのＤＰとサービスとの間の情報を結合するチャネルを含む。高速スキャンのために、受信機はＦＩＣをデコードし、ブロードキャスタＩＤ、サービスの数、及びＢＡＳＥ＿ＤＰ＿ＩＤなどの情報を取得することができる。高速サービスの取得のために、ＦＩＣに加えて、ベースＤＰをＢＡＳＥ＿ＤＰ＿ＩＤを用いてデコードすることができる。伝達される内容以外に、ベースＣＰは、正常ＤＰと正確に同じ方式でエンコードされ、フレームにマップされる。したがって、ベースＤＰに対して追加の説明は要求されない。ＦＩＣデータが生成されて管理層で消費される。ＦＩＣデータの内容は、管理層の説明書に記載したとおりである。
【０３７９】
ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２の静的部分内のＦＩＣ＿ＦＬＡＧパラメータによってシグナルされる。ＦＩＣが使用されると、ＦＩＣ＿ＦＬＡＧが“１”に設定され、ＦＩＣのためのシグナリングフィールドは、ＰＬＳ２の静的部分で定義される。このフィールドでは、ＦＩＣ＿ＶＥＲＳＩＯＮ及びＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥがシグナルされる。ＦＩＣは、ＰＬＳ２と同じ変調、コーディング及び時間インターリービングパラメータを用いる。ＦＩＣは、ＰＬＳ２＿ＭＯＤ及びＰＬＳ２＿ＦＥＣなどの同一のシグナリングパラメータを共有する。もしあれば、ＦＩＣデータは、ＰＬＳ２又は、もしあれば、ＥＡＣの直後にマップされる。ＦＩＣは、任意の正常ＤＰ、補助ストリーム、又はダミーセルの後にマップされない。ＦＩＣセルをマップする方法は、ＥＡＣと正確に同一であり、これはＰＬＳと同一である。
【０３８０】
ＰＬＳ後にＥＡＣがないと、ＦＩＣセルは、（ａ）の例に示すように、セルインデックスの昇順でＰＬＳ２の次のセルからマップされる。ＦＩＣデータサイズによって、ＦＩＣセルは、（ｂ）に示すように、数個のシンボルにわたってマップされてもよい。
【０３８１】
ＦＩＣセルは、ＰＬＳ２の最後のセルの直後にマップされ、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向きに続けて行われる。要求されるＦＩＣセルの全数が最後のＦＳＳの残りのアクティブキャリアの数を超えると、マッピングは次のシンボルに進められ、ＦＳＳと正確に同じ方式で続けて行われる。この場合のマッピングのための次のシンボルは、ＦＳＳより多くのアクティブキャリアを有する正常データシンボルである。
【０３８２】
ＥＡＳメッセージが現フレームで送信されると、ＥＡＣはＦＩＣに先行し、ＦＩＣセルは、（ｂ）に示すように、セルインデックスの昇順でＥＡＣの次のセルからマップされる。
【０３８３】
ＦＩＣマッピングが完了した後、一つ以上のＤＰがマップされ、その後、もしあれば、補助ストリーム及びダミーセルがマップされる。
【０３８４】
図２０は、本発明の実施例に係るＤＰのタイプを示す。
【０３８５】
図２０の（ａ）はタイプ１  ＤＰを示し、（ｂ）はタイプ２  ＤＰを示す。
【０３８６】
先行チャネル、すなわち、ＰＬＳ、ＥＡＣ及びＦＩＣがマップされた後、ＤＰのセルがマップされる。ＤＰは、マッピング方法によって２つのタイプのうち一つに分類される。
【０３８７】
タイプ１  ＤＰ：ＤＰはＴＤＭによってマップされる。
【０３８８】
タイプ２  ＤＰ：ＤＰはＦＤＭによってマップされる。
【０３８９】
ＤＰのタイプは、ＰＬＳ２の静的部分でＤＰ＿ＴＹＰＥフィールドによって指示される。図２０は、タイプ１  ＤＰ及びタイプ２  ＤＰのマッピング順序を示す。タイプ１  ＤＰは、まず、セルインデックスの昇順でマップされ、最後のセルインデックスに到達した後、シンボルインデックスが１ずつ増加する。次のシンボル内で、ＤＰはｐ＝０からセルインデックスの昇順で続けてマップされる。一つのフレームで共にマップされる複数のＤＰで、タイプ１  ＤＰのそれぞれは、ＤＰのＴＤＭマルチプレクシングと類似に、時間でグループ化される。
【０３９０】
タイプ２  ＤＰは、まず、シンボルインデックスの昇順でマップされ、フレームの最後のＯＦＤＭシンボルに到達した後、セルインデックスは１ずつ増加し、シンボルインデックスは第１利用可能なシンボルに戻り、そのシンボルインデックスから増加する。一つのフレームで複数のＤＰを共にマップした後、タイプ２  ＤＰのそれぞれは、ＤＰのＦＤＭマルチプレクシングと類似に、周波数でグループ化される。
【０３９１】
一つの制限が必要であれば、すなわち、タイプ１  ＤＰが常にタイプ２  ＤＰに先行すると、タイプ１  ＤＰ及びタイプ２  ＤＰはフレーム内で共存し得る。タイプ１及びタイプ２  ＤＰを伝達するＯＦＤＭセルの全数は、ＤＰの送信のために利用可能なＯＦＤＭセルの全数を超えることができない。
【０３９２】
【数２】
0006333983.tif 000030
【０３９３】
ここで、ＤDP1は、タイプ１  ＤＰが占めるＯＦＤＭセルの数であり、ＤDP2は、タイプ２  ＤＰが占めるＯＦＤＭセルの数である。ＰＬＳ、ＥＡＣ、ＦＩＣがいずれもタイプ１  ＤＰと同じ方式でマップされるため、これらはいずれも、“タイプ１マッピング規則”にしたがう。したがって、タイプ１マッピングは常にタイプ２マッピングに先行する。
【０３９４】
図２１は、本発明の実施例に係るＤＰマッピングを示す。
【０３９５】
（ａ）は、タイプ１  ＤＰをマップするためのＯＦＤＭセルのアドレシングを示し、（ｂ）は、タイプ２  ＤＰをマップするためのＯＦＤＭセルのアドレシングを示す。
【０３９６】
タイプ１  ＤＰ（０，ＤDP1―１）をマップするためのＯＦＤＭセルのアドレシングは、タイプ１  ＤＰのアクティブデータセルのために定義される。アドレシング方式は、タイプ１  ＤＰのそれぞれに対するＴＩからのセルがアクティブデータセルに割り当てられる順序を定義する。これはまた、ＰＬＳ２の動的部分内のＤＰの位置をシグナルするのに用いられる。
【０３９７】
ＥＡＣ及びＦＩＣ無しで、アドレス０は、最後のＦＳＳ内のＰＬＳを伝達する最後のセルの直後のセルを称する。ＥＡＣが送信され、ＦＩＣが該当のフレームで存在しないと、アドレス０は、ＥＡＣを伝達する最後のセルの直後のセルを称する。ＦＩＣが該当のフレームで送信されると、アドレス０は、ＦＩＣを伝達する最後のセルの直後のセルを称する。タイプ１  ＤＰに対するアドレス０は、（ａ）に示すように、２つの異なるケースを考慮して算出することができる。（ａ）の例で、ＰＬＳ、ＥＡＣ及びＦＩＣは全て送信されると仮定する。ＥＡＣ及びＦＩＣのいずれか一つ又は両方が省略される場合への拡張は容易である。（ａ）の左図に示すように、ＦＩＣまでの全てのセルをマップした後、ＦＳＳ内に残りのセルが残っている。
【０３９８】
タイプ２  ＤＰ（０，…，ＤDP2―１）をマップするＯＦＤＭセルのアドレシングは、タイプ２  ＤＰのアクティブデータセルのために定義される。アドレシング方式は、タイプ２  ＤＰのそれぞれに対するＴＩからのセルがアクティブデータセルに割り当てられる順序を定義する。これはまた、ＰＬＳ２の動的部分内のＤＰの位置をシグナルするのに用いられる。
【０３９９】
（ｂ）に示すように、３つのやや異なるケースが可能である。（ｂ）の左図に示す第１ケースでは、最後のＦＳＳ内のセルは、タイプ２  ＤＰに用いられる。中央の図に示す第２ケースでは、ＦＩＣが正常シンボルのセルを占めるが、そのシンボル上のＦＩＣセルの数はＣFSSより少ない。（ｂ）の右図に示す第３のケースは、そのシンボル上にマップされたＦＩＣセルの数がＣFSSを超えるという点を除けば、第２ケースと同一である。
【０４００】
ＰＬＳ、ＥＡＣ及びＦＩＣは、タイプ１  ＤＰと同じ“タイプ１マッピング規則”にしたがうので、タイプ１  ＤＰがタイプ２  ＤＰに先行する場合への拡張は簡単である。
【０４０１】
データパイプ単位（ＤＰＵ）は、データセルをフレーム内のＤＰに割り当てる基本単位である。
【０４０２】
ＤＰＵは、フレーム内にＤＰを位置させるシグナリング単位として定義される。セルマッパー７０１０は、ＤＰのそれぞれに対するＴＩによって生成されたセルをマップすることができる。時間インターリーバ５０５０は、一連のＴＩブロックを出力し、それぞれのＴＩブロックは、セルのセットで構成される可変数のＸＦＥＣＢＬＯＣＫを含む。ＸＦＥＣＢＬＯＣＫ内のセルの数（Ｎcells）は、ＦＥＣＢＬＯＣＫサイズ（Ｎldpc）及び星状シンボル当たりの送信ビット数に依存する。ＤＰＵは、与えられたＰＨＹプロファイルで支援されるＸＦＥＣＢＬＯＣＫ内のセルの数の全ての可能な値の最も大きい共通除数（ｄｉｖｉｓｏｒ）（Ｎcells）として定義される。セル内のＤＰＵの長さはＬDPUと定義される。それぞれのＰＨＹプロファイルがＦＥＣＢＬＯＣＫサイズ及び星状シンボル当たりに異なる数の異なる組合せを支援するので、ＬDPUは、ＰＨＹプロファイルに基づいて定義される。
【０４０３】
図２２は、本発明の実施例に係るＦＥＣ構造を示す。
【０４０４】
図２２は、ビットインターリービング前の本発明の実施例に係るＦＥＣ構造を示す。前述したように、データＦＥＣエンコーダは、入力ＢＢＦに対してＦＥＣエンコーディングを行い、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成することができる。図示されたＦＥＣ構造はＦＥＣＢＬＯＣＫに対応する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに対応する同一の値を有する。
【０４０５】
図２２に示すように、ＢＣＨエンコーディングはそれぞれのＢＢＦ（Ｋbchビット）に適用され、ＬＤＰＣエンコーディングはＢＣＨ―エンコーディングＢＢＦ（Ｋldpcビット＝Ｎbchビット）に適用される。
【０４０６】
Ｎldpcの値は、６４８００ビット（長いＦＥＣＢＬＯＣＫ）又は１６２００ビット（短いＦＥＣＢＬＯＣＫ）である。
【０４０７】
以下の表２８及び表２９は、それぞれ長いＦＥＣＢＬＯＣＫ及び短いＦＥＣＢＬＯＣＫに対するＦＥＣエンコーディングパラメータを示す。
【０４０８】
【表２８】
0006333983.tif 000031
【０４０９】
【表２９】
0006333983.tif 000032
【０４１０】
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの動作の細部事項は、次のとおりである。
【０４１１】
１２―誤り訂正ＢＣＨコードはＢＢＦの外部エンコーディングに用いられる。短いＦＥＣＢＬＯＣＫ及び長いＦＥＣＢＬＯＣＫに対するＢＢＦ生成器多項式は、全ての多項式を共に乗算することによって得られる。
【０４１２】
ＬＤＰＣコードは、外部ＢＣＨエンコーディングの出力をエンコードするのに用いられる。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐldpc（パリティビット）はそれぞれのＩldpc（ＢＣＨ−エンコードされたＢＢＦ）から体系的にエンコードされ、Ｉldpcに付加される。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）は、次の数式で表現される。
【０４１３】
【数３】
0006333983.tif 000033
【０４１４】
長いＦＥＣＢＬＯＣＫ及び短いＦＥＣＢＬＯＣＫに対するパラメータは、それぞれ前記表２８及び表２９に与えられる。
【０４１５】
長いＦＥＣＢＬＯＣＫに対するＮldpc−Ｋldpcを算出する細部手順は、次のとおりである。
【０４１６】
１）パリティビット初期化
【０４１７】
【数４】
0006333983.tif 000034
【０４１８】
２）パリティチェックマトリクスのアドレスの第１行で特定されたパリティビットアドレスで第１情報ビット（ｉ0）を累算する。パリティチェックマトリクスのアドレスの細部事項は後で説明する。例えば、レート１３／１５に対して、
【０４１９】
【数５】
0006333983.tif 000035
【０４２０】
３）次の３５９個の情報ビット（ｉs）（ｓ＝１，２，…，３５９）が、次の数式を用いてパリティビットで累算される。
【０４２１】
【数６】
0006333983.tif 000036
【０４２２】
ここで、ｘは、第１ビット（ｉ0）に対応するパリティビット累算器のアドレスを示し、Ｑldpcは、パリティチェックマトリクスのアドレスで特定されたコードレート従属定数である。継続して例を挙げると、レート１３／１５に対してＱldpc＝２４であり、したがって、情報ビット（ｉ1）に対して次の動作が行われる。
【０４２３】
【数７】
0006333983.tif 000037
【０４２４】
４）３６１番目の情報ビット（ｉ360）に対して、パリティビット累算器のアドレスは、パリティチェックマトリクスのアドレスの第２行に与えられる。同様の方式で、次の３５９個の情報ビット（ｉs）（ｓ＝３６１，３６２，…，７１９）に対するパリティビット累算器のアドレスは、数式６を用いて得られ、ここで、ｘは、情報ビット（ｉ360）に対応するパリティビット累算器のアドレス、パリティチェックマトリクスのアドレスの第２行内のエントリを示す。
【０４２５】
５）同様の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティチェックマトリクスのアドレスからの新しい行が、パリティビット累算器のアドレスを探すのに用いられる。
【０４２６】
全情報ビットが利用された後、最終パリティビットが次のように得られる。
【０４２７】
６）ｉ＝１から始まって次の動作を順次行う。
【０４２８】
【数８】
0006333983.tif 000038
【０４２９】
ここで、ｐi（ｉ＝０，１，．．．Ｎldpc−Ｋldpc−１）の最終内容は、パリティビット（ｐi）と同一である。
【０４３０】
【表３０】
0006333983.tif 000039
【０４３１】
短いＦＥＣＢＬＯＣＫに対するこのＬＤＰＣエンコーディング手順は表３０及び表３１に代えて、長いＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスのアドレスを短いＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスのアドレスに代えることを除けば、長いＦＥＣＢＬＯＣＫに対するｔ  ＬＤＰＣエンコーディング手順にしたがう。
【０４３２】
【表３１】
0006333983.tif 000040
【０４３３】
図２３は、本発明の実施例に係るビットインターリービングを示す。
【０４３４】
ＬＤＰＣエンコーダの出力はビットインターリーブされ、これは、パリティインターリービング、その後のＱＣＢ（ｑｕａｓｉ―ｃｙｃｌｉｃ  ｂｌｏｃｋ）インターリービング、及び内部グループインターリービングで構成される。
【０４３５】
（ａ）はＱＣＢインターリービングを示し、（ｂ）は内部グループインターリービングを示す。
【０４３６】
ＦＥＣＢＬＯＣＫは、パリティインターリーブすることができる。パリティインターリービングの出力において、ＬＤＰＣコードワードは、長いＦＥＣＢＬＯＣＫ内の１８０個の隣接するＱＣブロック、及び短いＦＥＣＢＬＯＣＫ内の４５個の隣接するＱＣブロックで構成される。長い又は短いＦＥＣＢＬＯＣＫ内のそれぞれのＱＣブロックは、３６０ビットで構成される。パリティインターリーブされたＬＤＰＣコードワードは、ＱＣＢインターリービングによってインターリーブされる。ＱＣＢインターリービングの単位はＱＣブロックである。パリティインターリービングの出力におけるＱＣブロックは、図２３に示すように、ＱＣＢインターリービングによってパーミュテートされ、ここで、ＦＥＣＢＬＯＣＫの長さによってＮcells＝６４８００／ηmod又は１６２００／ηmodである。ＱＣＢインターリービングパターンは、変調タイプ及びＬＤＰＣコードレートの各組合せに固有である。
【０４３７】
ＱＣＢインターリービング後、内部グループインターリービングは、以下の表３２に定義された変調タイプ及び順序（ηmod）によって行われる。一つの内部グループに対するＱＣブロックの数（ＮQCB_IG）も定義される。
【０４３８】
【表３２】
0006333983.tif 000041
【０４３９】
内部グループインターリービングプロセスは、ＱＣＢインターリービング出力のＮQCB_IG個のＱＣブロックで行われる。内部グループインターリービングは、３６０個の列及びＮQCB_IG個の行を用いて内部グループのビットを書き込み及び読み取りするプロセスを有する。書き込み動作で、ＱＣＢインターリービング出力からのビットが行方向に書き込まれる。読み取り動作は、列方向に行われ、各行からｍ個のビットを読み取り、ここで、ｍはＮＵＣに対して１に等しく、ＮＵＱに対して２に等しい。
【０４４０】
図２４は、本発明の実施例に係るセル―ワードデマルチプレクシングを示す。
【０４４１】
（ａ）は、８及び１２ｂｐｃｕ  ＭＩＭＯに対するセル―ワードデマルチプレクシングを示し、（ｂ）は、１０ｂｐｃｕ  ＭＩＭＯに対するセル―ワードデマルチプレクシングを示す。
【０４４２】
（ａ）に示すように、ビットインターリービング出力のそれぞれのセルワード（ｃ0,l，ｃ1,l，…，ｃηmod―1,l）は、（ｄ1,0,m，ｄ1,1,m…，ｄ1,ηmod―1,m）及び（ｄ2,0,m，ｄ2,1,m…，ｄ2,ηmod―1,m）にデマルチプレクスされ、これは、一つのＸＦＥＣＢＬＯＣＫに対するセル―ワードデマルチプレクシングプロセスを示す。
【０４４３】
ＭＩＭＯエンコーディングのための異なるタイプのＮＵＱを利用した１０ｂｐｃｕ  ＭＩＭＯケースに対して、ＮＵＱ―１０２４に対するビットインターリーバが再使用される。（ｂ）に示すように、ビットインターリーバ出力のそれぞれのセルワード（ｃ0,l，ｃ1,l，…，ｃ9,l）は、（ｄ1,0,m，ｄ1,1,m…，ｄ1,3,m）及び（ｄ2,0,m，ｄ2,1,m…，ｄ2,5,m）にデマルチプレクスされる。
【０４４４】
図２５は、本発明の実施例に係る時間インターリービングを示す。
【０４４５】
（ａ）乃至（ｃ）は、ＴＩモードの例を示す。
【０４４６】
時間インターリーバは、ＤＰレベルで動作する。時間インターリービング（ＴＩ）のパラメータはそれぞれのＤＰに対して別々に設定されてもよい。
【０４４７】
ＰＬＳ２―ＳＴＡＴデータの一部に現れる次のパラメータはＴＩを構成する。
【０４４８】
ＤＰ＿ＴＩ＿ＴＹＰＥ（許容値：０又は１）：ＴＩモードを示す。“０”は、ＴＩグループ当たりに複数のＴＩブロック（１より多いＴＩブロック）を有するモードを示す。この場合、一つのＴＩグループは一つのフレームに直接マップされる（インターフレームインターリービングでない）。“１”は、ＴＩグループ当たりに一つのＴＩブロックだけを有するモードを示す。この場合、ＴＩブロックは、１より多くのフレームに拡散され得る（インターフレームインターリービング）。
【０４４９】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＰ＿ＴＩ＿ＴＹＰＥ＝“０”であれば、このパラメータは、ＴＩグループ当たりのＴＩブロックの数（ＮTI）である。ＤＰ＿ＴＩ＿ＴＹＰＥ＝“１”に対して、このパラメータは、一つのＴＩグループから拡散されたフレームの数（ＰI）である。
【０４５０】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容値：０乃至１０２３）：ＴＩグループ当たりのＸＦＥＣＢＬＯＣＫの最大数を示す。
【０４５１】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容値：１，２，４，８）：与えられたＰＨＹプロファイルの同一のＤＰを伝達する２つの連続的なフレーム間のフレームの数（ＩJUMP）を示す。
【０４５２】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容値：０又は１）：時間インターリービングがＤＰに用いられないと、このパラメータは“１”に設定される。時間インターリービングが用いられると、“０”に設定される。
【０４５３】
さらに、ＰＬＳ２―ＤＹＮデータからのパラメータ（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ）は、ＤＰの一つのＴＩグループによって伝達されたＸＦＥＣＢＬＯＣＫの数を示すのに使用される。
【０４５４】
時間インターリービングがＤＰに用いられないと、次のＴＩグループ、時間インターリービング動作、及びＴＩモードは考慮されない。しかし、スケジューラからの動的構成情報に対する補償ブロックは依然として必要である。それぞれのＤＰで、ＳＳＤ／ＭＩＭＯエンコーディングから受信されたＸＦＥＣＢＬＯＣＫは、ＴＩグループにグループ化される。すなわち、それぞれのＴＩグループは整数のＸＦＥＣＢＬＯＣＫのセットであり、動的に可変する数のＸＦＥＣＢＬＯＣＫを含む。インデックスのＴＩグループ内のＸＦＥＣＢＬＯＣＫの数（ｎ）は、ＮxBLOCK_Group（ｎ）で表示され、ＰＬＳ２―ＤＹＮデータのＤＰ＿ＮＵＭ＿ＢＬＯＣＫとしてシグナルされる。このとき、ＮxBLOCK_Group（ｎ）は、最小値から、最も大きい値が１０２３である最大値（ＮxBLOCK_Group_MAX）（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに対応）まで変化してもよい。
【０４５５】
それぞれのＴＩグループは、一つのフレームに直接マップされたり、ＰIフレームにわたって拡散される。それぞれのＴＩグループは、１より多いＴＩブロック（ＮTI）に分離され、それぞれのＴＩブロックは、時間インターリーバメモリの一つの用途に対応する。ＴＩグループ内のＴＩブロックは、やや異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。ＴＩグループが複数のＴＩブロックに分離されると、一つのフレームにのみ直接マップされる。以下の表３３に示すように、（時間インターリービングをスキップする追加のオプションを除いて）時間インターリービングのための３つのオプションが存在する。
【０４５６】
【表３３】
0006333983.tif 000042
【０４５７】
それぞれのＤＰで、ＴＩメモリは、入力ＸＦＥＣＢＬＯＣＫ（ＳＳＤ／ＭＩＭＯエンコーディングブロックからの出力ＸＦＥＣＢＬＯＣＫ）を保存する。入力ＸＦＥＣＢＬＯＣＫは、
【０４５８】
【数９】
0006333983.tif 000043
と定義され、
【０４５９】
ここで、ｄn,s,r,qは、ｎ番目のＴＩグループのｓ番目のＴＩブロック内のｒ番目のＸＦＥＣＢＬＯＣＫのｑ番目のセルであり、次のようにＳＳＤ及びＭＩＭＯエンコーディングの出力を示す。
【０４６０】
【数１０】
0006333983.tif 000044
【０４６１】
また、時間インターリーバからの出力ＸＦＥＣＢＬＯＣＫは、次のように定義されると仮定する。
【０４６２】
【数１１】
0006333983.tif 000045
【０４６３】
ここで、ｈn,s,iは、ｎ番目のＴＩグループのｓ番目のＴＩブロック内のｉ番目の出力セル（ｉ＝０，．．．，ＮxBLOCK_TI（ｎ，ｓ）×Ｎcells−１）である。
【０４６４】
一般に、時間インターリーバは、フレームビルディングプロセスの前にＤＰデータのためのバッファとして動作する。これは、それぞれのＤＰに対する２個のメモリバンクによって達成される。第１ＴＩブロックは第１バンクに書き込まれる。第１バンクが読み取られる間に、第２ＴＩブロックが第２バンクに書き込まれる。
【０４６５】
ＴＩは、ツイスト行―列ブロックインターリーバである。ｎ番目のＴＩグループのｓ番目のＴＩブロックに対して、ＴＩメモリの行（Ｎr）の数はセルの数（Ｎcells）と同一である。すなわち、Ｎr＝Ｎcellsであるが、列の数（Ｎc）は、数（ＮxBLOCK_TI（ｎ，ｓ））と同一である。
【０４６６】
図２６は、本発明の実施例に係るツイスト行―列ブロックインターリーバの基本動作を示す。
【０４６７】
（ａ）は、時間インターリーバでの書き込み動作を示し、（ｂ）は、時間インターリーバでの読み取り動作を示す。（ａ）に示すように、第１ＸＦＥＣＢＬＯＣＫはＴＩメモリの第１列に列方向に書き込まれ、第２ＸＦＥＣＢＬＯＣＫは次の列に書き込まれる。その後、インターリービングアレイで、セルは対角線方向に読み取られる。第１行（最左列から始まって行に沿って右に）最後の行まで対角線方向読み取りが行われれる間に、（ｂ）に示すようにセルが読み取られる。具体的に、順次読み取られるＴＩメモリセル位置としてｚn,s,i（ｉ＝０，．．．，ＮrＮc）を想定し、このようなインターリービングアレイにおける読み取り動作は、下記の数式のように、行インデックス（Ｒn,s,i）、列インデックス（Ｃn,s,i）、及び関連したツイストパラメータ（Ｔn,s,i）を算出することによって行われる。
【０４６８】
【数１２】
0006333983.tif 000046
【０４６９】
ここで、Ｓshiftは、ＮxBLOCK_TI（ｎ，ｓ）に関係なく、対角線方向読み取りプロセスに対する共通シフト値であり、次の数式のように、ＰＬＳ２―ＳＴＡＴに与えられたＮxBLOCK_TI_MAXによって決定される。
【０４７０】
【数１３】
0006333983.tif 000047
【０４７１】
結果的に、読み取られるセル位置は、ｚn,s,i＝ＮrＣn,s,i＋Ｒn,s,iとして座標によって算出される。
【０４７２】
図２７は、本発明の他の実施例に係るツイスト行―列ブロックインターリーバの基本動作を示す。
【０４７３】
特に、図２７は、ＮxBLOCK_TI（０，０）＝３、ＮxBLOCK_TI（１，０）＝６、ＮxBLOCK_TI（２，０）＝５のとき、仮想ＸＦＥＣＢＬＯＣＫを含めて、それぞれのＴＩグループに対するＴＩメモリ内のインターリービングアレイを示す。
【０４７４】
可変数（ＮxBLOCK_TI（ｎ，ｓ）＝Ｎr）は、Ｎ’xBLOCK_TI_MAXより小さいか等しい。したがって、受信側で単一メモリデインターリービングを達成するために、ＮxBLOCK_TI（ｎ，ｓ）に関わらず、ツイスト行―列ブロックインターリーバ用インターリービングアレイは、仮想ＸＦＥＣＢＬＯＣＫをＴＩメモリに挿入することによってＮr×Ｎc＝Ｎcells×Ｎ’xBLOCK_TI_MAXのサイズに設定され、読み取りプロセスは次の数式で達成される。
【０４７５】
【数１４】
0006333983.tif 000048
【０４７６】
ＴＩグループの数は３に設定される。時間インターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝‘１’、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝‘１’、すなわち、ＮTI＝１、ＩJUMP＝１、ＰI＝１によってＰＬＳ２―ＳＴＡＴデータでシグナルされる。ＴＩグループ当たりにそれぞれがＮcells＝３０を有するＸＦＥＣＢＬＯＣＫの数は、それぞれＮxBLOCK_TI（０，０）＝３、ＮxBLOCK_TI（１，０）＝６、ＮxBLOCK_TI（２，０）＝５によってＰＬＳ２―ＤＹＮデータでシグナルされる。ＸＦＥＣＢＬＯＣＫの最大数はＮxBLOCK_Group_MAXによってＰＬＳ２―ＳＴＡＴデータでシグナルされ、これは次を誘導する。「ＮxBLOCK_Group_MAX／ＮTI」＝ＮxBLOCK_TI_MAX＝６
【０４７７】
図２８は、本発明の実施例に係るツイスト行―列ブロックインターリーバの対角線方向読み取りパターンを示す。
【０４７８】
特に、図２８は、Ｎ’xBLOCK_TI_MAX＝７及びＳshift＝（７−１）／２＝３のパラメータを有するそれぞれのインターリービングアレイからの対角線方向読み取りパターンを示す。前記疑似コードと示した読み取りプロセスで、Ｖi≧ＮcellsＮxBLOCK_TI（ｎ，ｓ）であれば、Ｖiの値はスキップされ、Ｖiの次の算出値が用いられる。
【０４７９】
図２９は、本発明の実施例に係るそれぞれのインターリービングアレイからのインターリーブされたＸＦＥＣＢＬＯＣＫを示す。
【０４８０】
図２９は、Ｎ’xBLOCK_TI_MAX＝７及びＳshift＝３のパラメータを有するそれぞれのインターリービングアレイからインターリーブされたＸＦＥＣＢＬＯＣＫを示す。
【０４８１】
図３０は、本発明の一実施例に係るＲｏＨＣ（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）パケットと圧縮されていないＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットの構造を示した図である。
【０４８２】
本発明の一実施例に係るＩＰパケットＬ１０１０は、ＩＰヘッダー、ＵＤＰヘッダー（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ  Ｈｅａｄｅｒ）、ＲＴＰヘッダー（Ｒｅａｌｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ  Ｈｅａｄｅｒ）及び／又はペイロードを含むことができる。
【０４８３】
本発明の一実施例に係るＩＰヘッダー、ＵＤＰヘッダー及びＲＴＰヘッダーの全長は略４０バイトであり得る。
【０４８４】
本発明の一実施例に係るＲｏＨＣパケットＬ１０２０は、ＲｏＨＣヘッダー及び／又はペイロードを含むことができる。
【０４８５】
本発明の一実施例に係るＲｏＨＣヘッダーは、ＩＰパケットのヘッダーを圧縮したものであって、ＲｏＨＣヘッダーの長さは略１バイトであり得る。
【０４８６】
本発明の一実施例によれば、ＲｏＨＣは、全体のヘッダーを一つのコンテキストＩＤで表示することができる。ＲｏＨＣは、伝送初期には全体のヘッダーを伝送してから、伝送が進められる間にコンテキストＩＤ及び主要情報のみを残し、変わらない部分は省略する方式で圧縮を進めることができる。
【０４８７】
本発明の一実施例によれば、ＩＰストリーミング時には、ＩＰバージョン、ＩＰソースアドレス、ＩＰ目的地アドレス（ｄｅｓｔｉｎａｔｉｏｎ  ａｄｄｒｅｓｓ）、ＩＰフラグメントフラグ（ｆｒａｇｍｅｎｔ  ｆｌａｇ）、ＵＤＰソースポート、ＵＤＰ目的地ポート（ｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ）などは、ストリーミングが行われる間にほとんど変わらない場合がある。上述した各フィールドのように、ストリーミングが行われる間にほとんど変わらないフィールドを静的フィールド（ｓｔａｔｉｃ  ｆｉｅｌｄ）と命名することができる。本発明の一実施例に係るＲｏＨＣは、このような静的フィールドを１回伝送した後、しばらく追加的に伝送しない場合がある。本発明の一実施例は、静的フィールドを１回伝送した後、しばらく追加的に伝送しないことをＩＲ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｒｅｆｒｅｓｈ）状態と命名することができ、各静的フィールドを伝送するパケットをＩＲパケットと命名することができる。さらに、本発明の一実施例によれば、随時に変動するが、一定の時間の間維持されるフィールドは動的フィールド（ｄｙｎａｍｉｃ  ｆｉｅｌｄ）と命名することができ、本発明の一実施例は、上述した動的フィールドを別途に追加的に伝送することができる。本発明の一実施例によれば、動的フィールドを伝送するパケットは、ＩＲ―ＤＹＮパケットと命名することができる。本発明の一実施例によれば、ＩＲパケット及びＩＲ―ＤＹＮパケットは既存のヘッダーの全ての情報を収容しているので、既存のヘッダーに類似するサイズを有することができる。
【０４８８】
本発明の一実施例によれば、伝送されるＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットデータのオーバーヘッドを減少させるためにＩＰパケットのヘッダー部分を圧縮する方法を使用することができる。本発明の一実施例によれば、ＩＰパケットヘッダー圧縮技法のうちＲｏＨＣ技法を使用することができ、ＲｏＨＣ技法は、無線区間での信頼性を確保することができる。ＲｏＨＣ技法は、ＤＶＢ―ＮＧＨ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ  ―  Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｈａｎｄｈｅｌｄ)などの放送システム及びＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）などの移動通信システムで使用することができる。ＲｏＨＣ技法は、ＩＰパケットのヘッダーを圧縮して伝送する技法であるが、ＵＤＰ及び／又はＲＴＰパケットに対しても使用することができる。
【０４８９】
本発明の一実施例によれば、ＲｏＨＣは、全体のヘッダーを一つのコンテキストＩＤとして表示することができる。ＲｏＨＣは、伝送初期に全体のヘッダーを伝送してから、伝送が進められる間にコンテキストＩＤ及び主要情報のみを残し、変わらない部分は省略する方式で圧縮を進めることができる。上述したＲｏＨＣ方式を放送システムに適用する場合、放送受信機はいずれの時点からＩＰストリームを受信すべきであるかを知ることができなく、全体のヘッダー情報を知っていない一般受信機は、該当のＩＰパケットを認識することができない。本発明の一実施例は、放送システムに使用されるシグナリングを用いて上述した問題を解決することができる。
【０４９０】
本発明の一実施例は、次世代デジタル放送システムで効率的なＩＰパケットの伝送を支援するためにＩＰヘッダー圧縮方法を提供することができる。
【０４９１】
本発明の他の一実施例によれば、ＲｏＨＣ技法をＦＬＵＴＥ基盤のプロトコルのパケットに適用することができる。本発明の一実施例に係るＦＬＵＴＥ／ＡＬＣ／ＬＣＴパケットにＲｏＨＣ技法を適用するためには、パケットヘッダーを静的フィールド、動的フィールド及び推論可能なフィールド（ｉｎｆｅｒａｂｌｅ  ｆｉｅｌｄ）に分類しなければならない。本発明の一実施例に係るＦＬＵＴＥ／ＡＬＣ／ＬＣＴパケットにおいて、静的フィールドは、ＬＣＴバージョン番号（Ｖ）、混雑制御フラグ (Ｃ)、伝送セッション識別子フラグ (Ｓ)、ハーフワードフラグ（Ｈ）、混雑制御情報（ＣＣＩ）、伝送セッション識別（ＴＳＩ）及び／又は予想残余伝送時間（ＥＲＴ）を含むことができる。ＬＣＴバージョン番号（Ｖ）は、４ビットフィールドとしてＬＣＴプロトコルのバージョン番号を示すことができ、このフィールドは１に固定することができる。混雑制御フラグ（Ｃ）は、２ビットフィールドとして混雑制御サイズを示し、値によって３２、６４、９６、１２８ビットのサイズを有することができる。伝送セッション識別子フラグ（Ｓ）は、１ビットフィールドとして、ＴＳＩのサイズを示すことができる変数であって、３２*Ｓ＋１６*Ｈのサイズを有することができる。ハーフワードフラグ（Ｈ）は、１ビットフィールドとして、ＴＳＩとＴＯＩのサイズを示すことができる共通した変数を示すことができる。混雑制御情報（ＣＣＩ）は、３２、６４、９６又は１２８ビットのサイズを有することができ、受信者が伝送されるセッション内のパケットの混雑制御をするのに使用される値であって、層の個数、論理チャネルの個数、シーケンス番号を含み、送信者と受信者との間の経路の利用可能な帯域幅の処理量を参照するのに使用することができる。伝送セッション識別（ＴＳＩ）は、１６、３２又は４８ビットのサイズを有することができ、特定の送信者からセッションを区分するための識別子を示すことができる。予想残余伝送時間（ＥＲＴ）は、０又は３２ビットフィールドであって、受信が有効な時間を示すことができる。本発明の一実施例に係るＦＬＵＴＥ／ＡＬＣ／ＬＣＴパケットにおいて、動的フィールドは、伝送オブジェクト識別子フラグ（Ｏ）、クローズセッションフラグ（Ａ）、クローズオブジェクトフラグ（Ｂ）、ＬＣＴヘッダー長（ＨＤＲ＿ＬＥＮ)、コードポイント（ＣＰ）、伝送者現在時間（ＳＣＴ）及び／又はソースブロック番号（ＳＢＮ）を含むことができる。伝送オブジェクト識別子フラグ（Ｏ）は、２ビットフィールドとして、ＴＯＩのサイズを示すことができる変数であって、３２*Ｏ＋１６*Ｈのサイズを有することができる。クローズセッションフラグ（Ａ）は、１ビットフィールドであって、一般に０に設定し、セッションパケット伝送の終了時に１に設定することができる。クローズオブジェクトフラグ（Ｂ）は、１ビットフィールドであって、一般に０に設定し、データ（オブジェクト）パケット伝送の終了時に１に設定することができる。ＬＣＴヘッダー長（ＨＤＲ＿ＬＥＮ）は、８ビットフィールドであって、ＬＣＴのヘッダーを３２ビットとして表現することができる。コードポイント（ＣＰ）は、８ビットフィールドであって、データタイプを示すことができる��伝送者現在時間（ＳＣＴ）は、０又は３２ビットフィールドであって、送信側で受信機にデータを伝送した時間を示すことができる。ソースブロック番号（ＳＢＮ）は、３２ビットフィールドであって、生成されたペイロード内のエンコーディングシンボルのソースブロックを識別することができる。本発明の一実施例に係るＦＬＵＴＥ／ＡＬＣ／ＬＣＴパケットにおいて、推論可能なフィールドは、伝送オブジェクト識別（ＴＯＩ）、ＦＥＣペイロードＩＤ、エンコーディングシンボルＩＤ（ＥＳＩ）及び／又はエンコーディングシンボルを含むことができる。伝送オブジェクト識別（ＴＯＩ）は、１６、３２、４８、６４、８０、９６又は１１２ビットを有するフィールドであって、受信者からデータ（オブジェクト）を区分するための識別子を示すことができる。ＦＥＣペイロードＩＤの長さとフォーマットはＦＥＣエンコーディングＩＤによって設定され、このフィールドはＦＥＣビルディングブロック内に含ませることができる。エンコーディングシンボルＩＤ（ＥＳＩ）は、３２ビットフィールドであって、ペイロード内のソースブロックから生成された特別なエンコーディングシンボルを識別することができる。エンコーディングシンボルは、受信機がデータを再形成するための分割されたデータであって、分割されたサイズによって可変的なサイズを有することができる。
【０４９２】
図３１は、本発明の一実施例に係るＲｏＨＣパケットストリームのコンセプトを示した図である。
【０４９３】
この図面に示したように、ＩＲパケットに含まれて伝送される静的フィールド及びＩＲ―ＤＹＮパケットに含まれて伝送される動的フィールドは、必要時のみに伝送することができ、その他のパケットは、略１バイト〜２バイトの情報でのみ構成されたヘッダー圧縮されたパケットの形態で伝送することができる。
【０４９４】
本発明の一実施例によれば、上述したＲｏＨＣパケットストリームコンセプトを通じてパケット当たり３０バイト以上のヘッダー長を減少させることができる。ヘッダー圧縮されたパケットは、圧縮されたヘッダーの形態によってタイプ０、タイプ１及びタイプ２に分類することができる。本発明の一実施例に係るＲｏＨＣパケットの使用に対する内容は、既存の標準文書に従うことができる。
【０４９５】
図３２は、本発明の一実施例に係るＲｏＨＣパケットストリームの伝送過程中にコンテキスト情報が伝播される過程を示した図である。
【０４９６】
この図面に示したように、フルコンテキスト情報（ｆｕｌｌ  ｃｏｎｔｅｘｔ  ｉｎｆｏ）はＩＲパケットに含ませることができ、アップデートされたコンテキスト情報（ｕｐｄａｔｅｄ  ｃｏｎｔｅｘｔ  ｉｎｆｏ）はＩＲ―ＤＹＮパケットに含ませることができる。また、ＩＲパケット及びＩＲ―ＤＹＮパケットを除いたヘッダー圧縮されたパケットはコンテキスト情報（ｃｏｎｔｅｘｔ  ｉｎｆｏ）を含まない場合がある。
【０４９７】
本発明の一実施例によれば、フィードバックチャネルがない単方向伝送の場合、ＩＲ情報を有していない受信機は、次のＩＲパケットを受信し、フルコンテキストを構成できるまでＲｏＨＣストリームをデコードすることができない。すなわち、この図面において、ターンオン（Ｔｕｒｎ  Ｏｎ）で表示された部分から受信機がＲｏＨＣストリームを受信する場合、受信機は、次のＩＲパケットを受信するまでＲｏＨＣストリームをデコードすることができない。本発明の一実施例は、上述した問題を解決するためにＩＲ情報を別途のシグナリングチャネルを介して伝送することができる。
【０４９８】
本発明の一実施例によれば、伝送されるＲｏＨＣパケットが正常にデコードされるためには、ＲｏＨＣ構成情報、初期パラメータ及び／又はＩＲパケット情報（フルコンテキスト情報）が必要である場合がある。
【０４９９】
本発明の一実施例によれば、ＩＰ伝送のオーバーヘッドを減少させ、効率的な伝送を具現するために、ＩＰヘッダー圧縮方法でヘッダー圧縮されたパケットはインバンドで伝送し、変わらないヘッダー情報を収容している静的チェーンを含むＩＲパケット及びコンテキストアップデートのための動的チェーンはアウトオブバンドで伝送することができる。このとき、受信機で受信された各パケットは、伝送前の順序とおりに復旧することができる。
【０５００】
図３３は、本発明の一実施例に係るＩＰヘッダー圧縮方式が適用されたＩＰストリームの送受信システムを示した図である。
【０５０１】
本発明の一実施例によれば、それぞれのＩＰストリームが別個のＤＰ（Ｄａｔａ  Ｐｉｐｅ）に入っていくように構成することができる。このとき、ヘッダー圧縮と関連する情報（Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ  Ｉｎｆｏ）は、Ｌ２シグナリング伝送過程を通じて受信機に伝送することができ、ヘッダー圧縮と関連する情報は、受信機で受信したＩＰヘッダー圧縮方式が適用されたＩＰストリームを再び元のＩＰストリームに復旧するために使用することができる。ヘッダー圧縮と関連する情報は、カプセル化してＤＰに伝送することができる。このとき、ヘッダー圧縮と関連する情報は、物理層の構造によって正常のＤＰに伝送したり、シグナリング伝送のためのＤＰ（Ｂａｓｅ  ＤＰ）に伝送することができる。さらに、ヘッダー圧縮と関連する情報は、物理層で支援する場合、別途のシグナリングチャネルを介して伝送することができる。
【０５０２】
本発明の一実施例によれば、ＩＰ―ＤＰマッピング情報（ＩＰ―ＤＰ  ｍａｐｐｉｎｇ  ｉｎｆｏ）は、Ｌ２シグナリング伝送過程を通じて受信機に伝送することができ、ＩＰ―ＤＰマッピング情報は、受信機で受信したＤＰからＩＰストリームを復旧するために使用することができる。ＩＰ―ＤＰマッピング情報は、カプセル化してＤＰに伝送することができる。このとき、ＩＰ―ＤＰマッピング情報は、物理層の構造によって正常のＤＰに伝送したり、シグナリング伝送のためのＤＰ（Ｂａｓｅ  ＤＰ）に伝送することができる。さらに、ＩＰ―ＤＰマッピング情報は、物理層で支援する場合、別途のシグナリングチャネルを介して伝送することができる。
【０５０３】
この図面に示したように、送信側で多重化されたＩＰストリーム（Ｍｕｘｅｄ  ＩＰ  Ｓｔｒｅａｍ）は、ＩＰフィルタＬ４０１０によって一つ以上のＩＰストリームに分けることができる。それぞれのＩＰストリームは、ＩＰヘッダー圧縮方案Ｌ４０２０によって圧縮することができ、カプセル化過程Ｌ４０３０を経てそれぞれのＤＰに伝送することができる。このとき、Ｌ２シグナリング生成器Ｌ４０４０は、ヘッダー圧縮と関連する情報及び／又はＩＰ―ＤＰマッピング情報を含むシグナリング情報を生成することができ、生成されたシグナリング情報は、カプセル化された過程を経てベースＤＰを介して受信側に伝送したり、シグナリングフォーマッティング過程Ｌ４０５０を経てシグナリングチャネルＬ４０６０を介して受信側に伝送することができる。
【０５０４】
この図面に示したように、受信側で受信された各ＤＰは、シグナリングパーサＬ４０７０によってパースされたＩＰ―ＤＰマッピング情報によってそれぞれのＩＰストリームに復旧することができる。デカプセル化過程Ｌ４０８０を経たＩＰストリームは、Ｌ２シグナリングパーサＬ４０９０によってパースされたヘッダー圧縮と関連する情報によってＩＰヘッダー圧縮方案が適用される前のＩＰストリームに復旧することができる。
【０５０５】
図３４は、本発明の一実施例に係る送受信機におけるＩＰオーバーヘッド削減過程を示した図である。
【０５０６】
本発明の一実施例によれば、ＩＰストリームがオーバーヘッド削減過程に進入すると、ＲｏＨＣコンプレッサＬ５０１０は、該当のストリームに対するヘッダー圧縮を行うことができる。本発明の一実施例は、ヘッダー圧縮アルゴリズムとしてＲｏＨＣ方法を使用することができる。パケットストリーム構成過程Ｌ５０２０でＲｏＨＣ過程を経たパケットストリームは、ＲｏＨＣパケットの形態によって再構成することができ、再構成されたＲｏＨＣパケットストリームは、カプセル化層Ｌ５０４０に伝達することができ、続いて、物理層を介して受信機に伝送することができる。パケットストリームを再構成する過程で生じたＲｏＨＣコンテキスト情報及び／又はシグナリング情報は、シグナリング生成器Ｌ５０３０を通じて伝送が可能な形態に作られ、伝送形態によってカプセル化層又はシグナリングモジュールＬ５０５０に伝達することができる。
【０５０７】
本発明の一実施例によれば、受信機は、サービスデータに対するストリーム、及びシグナリングチャネル又は別途のＤＰで伝達されるシグナリングデータを受信することができる。シグナリングパーサＬ５０６０は、シグナリングデータを受信し、ＲｏＨＣコンテキスト情報及び／又はシグナリング情報をパースし、パースされた情報をパケットストリーム復元過程Ｌ５０７０で伝達することができる。パケットストリーム復元過程Ｌ５０７０では、受信機は、シグナリングデータに含まれたＲｏＨＣコンテキスト情報及び／又はシグナリング情報を用いて送信側で再構成されたパケットストリームを、ＲｏＨＣデコンプレッサＬ５０８０が圧縮を解除できる形態に復旧することができる。ＲｏＨＣデコンプレッサＬ５０８０は、復旧されたＲｏＨＣパケットストリームをＩＰストリームに変換することができ、変換されたＩＰストリームはＩＰ層を介して上位層に伝達することができる。
【０５０８】
図３５は、本発明の一実施例に係るＲｏＨＣパケットを再構成し、新しいパケットストリームを構成する過程を示した図である。
【０５０９】
本発明は、３つの構成モードを含むことができる。
【０５１０】
本発明の一実施例である第１構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃１）Ｌ６０１０によれば、第１構成モードは、ＩＲパケットから静的チェーン及び動的チェーンを抽出することができ、該当パケットの残りの部分を、一般的なヘッダー圧縮されたパケットに変換することができる。第１構成モードは、ＩＲ―ＤＹＮパケットから動的チェーンを抽出することができ、該当パケットの残りの部分を、一般的なヘッダー圧縮されたパケットに変換することができる。第１構成モードは、一般的なヘッダー圧縮されたパケットをそのまま伝送することができる。
【０５１１】
本発明の他の一実施例である第２構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃２）Ｌ６０２０によれば、第２構成モードは、ＩＲパケットから静的チェーンのみを抽出することができ、該当パケットの残りの部分を、一般的なヘッダー圧縮されたパケットに変換することができる。第２構成モードは、ＩＲ―ＤＹＮパケットから動的チェーンを抽出することができ、該当パケットの残りの部分を、一般的なヘッダー圧縮されたパケットに変換することができる。第２構成モードは、一般的なヘッダー圧縮されたパケットをそのまま伝送することができる。
【０５１２】
本発明の他の一実施例である第３構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃３）Ｌ６０３０によれば、第３構成モードは、ＩＲパケットから静的チェーンを抽出することができ、該当パケットの残りの部分をＩＲ―ＤＹＮパケットに変換することができる。第３構成モードは、ＩＲ―ＤＹＮパケットをそのまま伝送することができ、一般的なヘッダー圧縮されたパケットをそのまま伝送することができる。
【０５１３】
図３６は、本発明の一実施例に係るＲｏＨＣパケットを再構成し、新しいパケットストリームを構成する過程でＩＲパケットを一般的なヘッダー圧縮されたパケットに変換する過程を示した図である。
【０５１４】
本発明の一実施例に係るＩＲパケットＬ７０１０は、パケットタイプ、コンテキストＩＤ、プロファイル、ＣＲＣ、静的チェーン、動的チェーン及び／又はペイロードを含むことができる。パケットタイプは、当該ＩＲパケットのタイプを示すことができる。例えば、この図面において、ＩＲパケットのパケットタイプは１１１１１１０Ｄを示すことができ、最後のＤは、該当パケットに動的チェーンが含まれているか否かを示すことができる。コンテキストＩＤは８ビットを使用することができ、より多くのビットを使用することができる。コンテキストＩＤは、該当パケットが伝送されるチャネルを識別することができる。コンテキストＩＤは、ＣＩＤ（ｃｏｎｔｅｘｔ  ｉｄｅｎｔｉｆｉｅｒ）と命名することができ、送信側（コンプレッサ）で最初は無圧縮状態のフルヘッダーを有するパケットに特定ＣＩＤを追加して送り、次回のパケットからは同一のＣＩＤとして静的、動的又は推論可能な性質を有するヘッダーフィールドを省略して送ると、受信側（デコンプレッサ）ではＣＩＤに基づいて最初に保存されたヘッダーフィールド情報を参考にして２番目のパケット以後に受信された圧縮ヘッダーに省略された各フィールドを追加する方式で全体のＲＴＰヘッダーを復元することができる。プロファイルは、パケットタイプが識別するＩＲパケットのプロファイルを示すことができる。ＣＲＣは、誤りチェックのためのＣＲＣコードを示すことができる。静的チェーンは、ストリーミングが行われる間にほとんど変わらない情報を示すことができる。例えば、ＩＰストリーミング時には、ＩＰバージョン、ＩＰソースアドレス、ＩＰ目的地アドレス、ＩＰフラグメントフラグ、ＵＤＰソースポート、ＵＤＰ目的地ポートなどを静的チェーンに含ませることができる。動的チェーンは、随時に変動するが、一定時間の間に維持される情報を示すことができる。ペイロードは、伝送しようとするデータを含むことができる。
【０５１５】
本発明の一実施例に係る一般的なヘッダー圧縮されたパケットＬ７０２０は、ＴＳ（Ｔｉｍｅ  Ｓｔａｍｐ）、ＳＮ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）、ＣＲＣ及び／又はペイロードを含むことができる。本発明の一実施例に係る一般的なヘッダー圧縮されたパケットは、パケットタイプ１に該当するＵＯ―１パケットに該当し得る。ＴＳ（Ｔｉｍｅ  Ｓｔａｍｐ）は、時間同期化のためのタイムスタンプ情報を示すことができる。ＳＮ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）は、各パケットの順序を示す情報を示すことができる。ＣＲＣは、誤りチェックのためのＣＲＣコードを示すことができる。ペイロードは、伝送しようとするデータを含むことができる。
【０５１６】
本発明の一実施例によれば、ＩＲパケットＬ７０１０から静的チェーン及び動的チェーンを抽出することができ、抽出された静的チェーン及び動的チェーンはアウトバンドＬ７０３０を介して伝送することができる。一般的なヘッダー圧縮されたパケットＬ７０２０に含まれたＴＳ（Ｔｉｍｅ  Ｓｔａｍｐ）及びＳＮ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）は、ＩＲパケットＬ７０１０に含まれた動的チェーンの情報を用いて再エンコードすることができ、一般的なヘッダー圧縮されたパケットＬ７０２０に含まれたＣＲＣは、ＩＲパケットＬ７０１０に含まれたＣＲＣと別個に再び計算することができる。
【０５１７】
図３７は、本発明の一実施例に係るＲｏＨＣパケットを再構成し、新しいパケットストリームを構成する過程でＩＲ―ＤＹＮパケットを、一般的なヘッダー圧縮されたパケットに変換する過程を示した図である。
【０５１８】
本発明の一実施例に係るＩＲ―ＤＹＮパケットＬ８０１０は、パケットタイプ、コンテキストＩＤ、プロファイル、ＣＲＣ、動的チェーン及び／又はペイロードを含むことができる。パケットタイプは、当該ＩＲ―ＤＹＮパケットのタイプを示すことができる。例えば、この図面において、ＩＲ―ＤＹＮパケットのパケットタイプは１１１１１０００を示すことができる。コンテキストＩＤは、８ビットを使用することができ、より多くのビットを使用することができる。コンテキストＩＤは、該当ＩＲ―ＤＹＮパケットが伝送されるチャネルを識別することができる。プロファイルは、パケットタイプが識別するＩＲ―ＤＹＮパケットのプロファイルを示すことができる。ＣＲＣは、誤りチェックのためのＣＲＣコードを示すことができる。動的チェーンは、随時に変動するが、一定時間の間に維持される情報を示すことができる。ペイロードは、伝送しようとするデータを含むことができる。
【０５１９】
本発明の一実施例に係る一般的なヘッダー圧縮されたパケットＬ８０２０は、ＴＳ（Ｔｉｍｅ  Ｓｔａｍｐ）、ＳＮ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）、ＣＲＣ及び／又はペイロードを含むことができ、これに対しては既に説明した。
【０５２０】
本発明の一実施例によれば、ＩＲ―ＤＹＮパケットＬ８０１０から動的チェーンを抽出することができ、抽出された動的チェーンはアウトオブバンドＬ８０３０を介して伝送することができる。一般的なヘッダー圧縮されたパケットＬ８０２０に含まれたＴＳ（Ｔｉｍｅ  Ｓｔａｍｐ）及びＳＮ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）は、ＩＲ―ＤＹＮパケットＬ８０１０に含まれた動的チェーンの情報を用いて再エンコードすることができ、一般的なヘッダー圧縮されたパケットＬ８０２０に含まれたＣＲＣは、ＩＲ―ＤＹＮパケットＬ８０１０に含まれたＣＲＣと別個に再び計算することができる。
【０５２１】
図３８は、本発明の一実施例に係るＲｏＨＣパケットを再構成し、新しいパケットストリームを構成する過程でＩＲパケットをＩＲ―ＤＹＮパケットに変換する過程を示した図である。
【０５２２】
本発明の一実施例に係るＩＲパケットＬ９０１０及びＩＲ―ＤＹＮパケットＬ９０２０に対しては既に説明した。
【０５２３】
本発明の一実施例によれば、ＩＲパケットＬ９０１０のパケットタイプは、ＩＲ―ＤＹＮパケットＬ９０２０に該当するパケットタイプ値に変更することができる。ＩＲパケットＬ９０１０から静的チェーンを抽出することができ、抽出された静的チェーンはアウトオブバンドＬ９０３０を介して伝送することができる。ＩＲパケットＬ９０１０に含まれたフィールドのうちパケットタイプ及び静的チェーンを除いた残りのフィールドは、ＩＲ―ＤＹＮパケットＬ９０２０で同一に使用することができる。
【０５２４】
本発明の一実施例によれば、ＲｏＨＣパケットを再構成し、新しいパケットストリームを構成する過程で使用されるフィールドと関連したエンコーディング及び計算方法は、関連標準に含まれた内容に従うことができ、その他の方法を適用することができる。
【０５２５】
図３９は、本発明の一実施例に係る第１構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃１）に対するＲｏＨＣパケットストリームの構成及び復元過程を示した図である。
【０５２６】
本発明の一実施例に係る送信機におけるＲｏＨＣパケットストリームの構成過程は、次の通りである。
【０５２７】
本発明の一実施例に係る送信機は、ＲｏＨＣヘッダー情報に基づいてＲｏＨＣパケットストリームＬ１００１０からＩＲパケット及びＩＲ―ＤＹＮパケットを検出することができる。次に、送信機は、ＩＲ及びＩＲ―ＤＹＮパケットに含まれたシーケンス番号を用いて一般的なヘッダー圧縮されたパケットを生成することができる。上述した一般的なヘッダー圧縮されたパケットが如何なるタイプであっても、一般的なヘッダー圧縮されたパケットはＳＮ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）情報を含むので、任意に生成することができる。ここで、ＳＮは、基本的にＲＴＰに存在する情報に該当し、ＵＤＰの場合は、送信機で任意にＳＮを生成して使用することができる。次に、送信機は、該当するＩＲ又はＩＲ―ＤＹＮパケットを、生成された一般的なヘッダー圧縮されたパケットに取り替えることができ、送信機は、ＩＲパケットから静的チェーン及び動的チェーンを抽出することができ、ＩＲ―ＤＹＮパケットから動的チェーンを抽出することができる。抽出された静的チェーン及び動的チェーンはアウトオブバンドＬ１００３０を介して伝送することができる。送信機は、全てのＲｏＨＣパケットストリームに対して上述した過程と同一の過程によってＩＲ及びＩＲ―ＤＹＮヘッダーを一般的なヘッダー圧縮されたパケットのヘッダーに取り替えることができ、静的チェーン及び／又は動的チェーンを抽出することができる。再構成されたパケットストリームＬ１００２０は、データパイプを介して伝送することができ、抽出された静的チェーン及び動的チェーンはアウトオブバンドＬ１００３０を介して伝送することができる。
【０５２８】
本発明の一実施例に係る受信機においてＲｏＨＣパケットストリームを復元する過程は、次の通りである。
【０５２９】
本発明の一実施例に係る受信機は、シグナリング情報を用いて受信しようとするストリームのデータパイプを選択することができる。次に、受信機は、データパイプで伝送される受信しようとするパケットストリーム（Ｒｅｃｅｉｖｅｄ  Ｐａｃｋｅｔ  Ｓｔｒｅａｍ）Ｌ１００４０を受信することができ、受信しようとするパケットストリームに該当する静的チェーン及び動的チェーンを検出することができる。ここで、静的チェーン及び／又は動的チェーンはアウトオブバンドを介して受信することができる（Ｏｕｔ  ｏｆ  Ｂａｎｄ  Ｒｅｃｅｐｔｉｏｎ）Ｌ１００５０。次に、受信機は、抽出された静的チェーン及び動的チェーンのＳＮを用いてデータパイプを介して伝送されるパケットストリームのうち、上述した静的チェーン又は動的チェーンのＳＮと同じＳＮを有する一般的なヘッダー圧縮されたパケットを検出することができる。次に、受信機は、検出された一般的なヘッダー圧縮されたパケットを静的チェーン及び／又は動的チェーンと結合することによってＩＲ及び／又はＩＲ―ＤＹＮパケットを構成することができ、構成されたＩＲ及び／又はＩＲ―ＤＹＮパケットはＲｏＨＣデコンプレッサに伝送することができる。また、受信機は、ＩＲパケット、ＩＲ―ＤＹＮパケット及び／又は一般的なヘッダー圧縮されたパケットを含むＲｏＨＣパケットストリームＬ１００６０を構成することができ、構成されたＲｏＨＣパケットストリームはＲｏＨＣデコンプレッサに伝送することができる。本発明の一実施例に係る受信機は、ＲｏＨＣパケットストリームを復元するために静的チェーン、動的チェーン、ＩＲパケット及びＩＲ―ＤＹＮパケットのＳＮ及び／又はコンテキストＩＤを用いることができる。
【０５３０】
図４０は、本発明の一実施例に係る第２構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃２）に対するＲｏＨＣパケットストリームの構成及び復元過程を示した図である。
【０５３１】
本発明の一実施例に係る送信機におけるＲｏＨＣパケットストリームの構成過程は、次の通りである。
【０５３２】
本発明の一実施例に係る送信機は、ＲｏＨＣヘッダー情報に基づいてＲｏＨＣパケットストリームＬ１１０１０からＩＲパケット及びＩＲ―ＤＹＮパケットを検出することができる。次に、送信機は、ＩＲ及びＩＲ―ＤＹＮパケットに含まれたシーケンス番号を用いて一般的なヘッダー圧縮されたパケットを生成することができる。上述した一般的なヘッダー圧縮されたパケットが如何なるタイプであっても、一般的なヘッダー圧縮されたパケットはＳＮ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）情報を含むので、任意に生成することができる。ここで、ＳＮは、基本的にＲＴＰに存在する情報に該当し、ＵＤＰの場合は、送信機で任意にＳＮを生成して使用することができる。次に、送信機は、該当するＩＲ又はＩＲ―ＤＹＮパケットを、生成された一般的なヘッダー圧縮されたパケットに取り替えることができ、送信機は、ＩＲパケットから静的チェーンを抽出することができ、ＩＲ―ＤＹＮパケットから動的チェーンを抽出することができる。抽出された静的チェーン及び動的チェーンはアウトオブバンドＬ１１０３０を介して伝送することができる。送信機は、全てのＲｏＨＣパケットストリームに対して上述した過程と同一の過程によってＩＲ及びＩＲ―ＤＹＮヘッダーを一般的なヘッダー圧縮されたパケットのヘッダーに取り替えることができ、静的チェーン及び／又は動的チェーンを抽出することができる。再構成されたパケットストリームＬ１１０２０はデータパイプを介して伝送することができ、抽出された静的チェーン及び動的チェーンはアウトオブバンドＬ１１０３０を介して伝送することができる。
【０５３３】
本発明の一実施例に係る受信機でＲｏＨＣパケットストリームを復元する過程は、次の通りである。
【０５３４】
本発明の一実施例に係る受信機は、シグナリング情報を用いて受信しようとするストリームのデータパイプを選択することができる。次に、受信機は、データパイプで伝送される受信しようとするパケットストリーム（Ｒｅｃｅｉｖｅｄ  Ｐａｃｋｅｔ  Ｓｔｒｅａｍ）Ｌ１１０４０を受信することができ、受信しようとするパケットストリームに該当する静的チェーン及び動的チェーンを検出することができる。ここで、静的チェーン及び／又は動的チェーンはアウトオブバンドを介して受信することができる（Ｏｕｔ  ｏｆ  Ｂａｎｄ  Ｒｅｃｅｐｔｉｏｎ）Ｌ１１０５０。次に、受信機は、抽出された静的チェーン及び動的チェーンのＳＮを用いてデータパイプを介して伝送されるパケットストリームのうち上述した静的チェーン又は動的チェーンのＳＮと同一のＳＮを有する一般的なヘッダー圧縮されたパケットを検出することができる。次に、受信機は、検出された一般的なヘッダー圧縮されたパケットを静的チェーン及び／又は動的チェーンと結合することによってＩＲ及び／又はＩＲ―ＤＹＮパケットを構成することができ、構成されたＩＲ及び／又はＩＲ―ＤＹＮパケットはＲｏＨＣデコンプレッサに伝送することができる。また、受信機は、ＩＲパケット、ＩＲ―ＤＹＮパケット及び／又は一般的なヘッダー圧縮されたパケットを含むＲｏＨＣパケットストリームＬ１１０６０を構成することができ、構成されたＲｏＨＣパケットストリームはＲｏＨＣデコンプレッサに伝送することができる。本発明の一実施例に係る受信機は、ＲｏＨＣパケットストリームを復元するために静的チェーン、動的チェーン、ＩＲパケット及びＩＲ―ＤＹＮパケットのＳＮ及び／又はコンテキストＩＤを用いることができる。
【０５３５】
図４１は、本発明の一実施例に係る第３構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃３）に対するＲｏＨＣパケットストリームの構成及び復元過程を示した図である。
【０５３６】
本発明の一実施例に係る送信機におけるＲｏＨＣパケットストリームの構成過程は、次の通りである。
【０５３７】
本発明の一実施例に係る送信機は、ＲｏＨＣヘッダー情報に基づいてＲｏＨＣパケットストリームＬ１２０１０からＩＲパケットを検出することができる。次に、送信機は、ＩＲパケットから静的チェーンを抽出することができ、ＩＲパケットの構成のうち抽出された静的チェーンを除いた残りの部分を用いてＩＲパケットをＩＲ―ＤＹＮパケットに変換することができる。送信機は、全てのＲｏＨＣパケットストリームに対して上述した過程と同一の過程によってＩＲパケットのヘッダーをＩＲ―ＤＹＮパケットのヘッダーに取り替えることができ、静的チェーンを抽出することができる。再構成されたパケットストリームＬ１２０２０は、データパイプを介して伝送することができ、抽出された静的チェーンはアウトオブバンドＬ１２０３０を介して伝送することができる。
【０５３８】
本発明の一実施例に係る受信機においてＲｏＨＣパケットストリームを復元する過程は、次の通りである。
【０５３９】
本発明の一実施例に係る受信機は、シグナリング情報を用いて受信しようとするストリームのデータパイプを選択することができる。次に、受信機は、データパイプで伝送される受信しようとするパケットストリーム（Ｒｅｃｅｉｖｅｄ  Ｐａｃｋｅｔ  Ｓｔｒｅａｍ）Ｌ１２０４０を受信することができ、受信しようとするパケットストリームに該当する静的チェーンを検出することができる。ここで、静的チェーンは、アウトオブバンドを介して受信することができる（Ｏｕｔ  ｏｆ  Ｂａｎｄ  Ｒｅｃｅｐｔｉｏｎ）Ｌ１２０５０。次に、受信機は、データパイプを介して伝送されるパケットストリームのうちＩＲ―ＤＹＮパケットを検出することができる。次に、受信機は、検出されたＩＲ―ＤＹＮパケットを静的チェーンと結合することによってＩＲパケットを構成することができ、構成されたＩＲパケットはＲｏＨＣデコンプレッサに伝送することができる。また、受信機は、ＩＲパケット、ＩＲ―ＤＹＮパケット及び／又は一般的なヘッダー圧縮されたパケットを含むＲｏＨＣパケットストリームＬ１２０６０を構成することができ、構成されたＲｏＨＣパケットストリームはＲｏＨＣデコンプレッサに伝送することができる。本発明の一実施例に係る受信機は、ＲｏＨＣパケットストリームを復元するために静的チェーン及びＩＲ―ＤＹＮパケットのＳＮ及び／又はコンテキストＩＤを用いることができる。
【０５４０】
図４２は、本発明の一実施例に係るアウトオブバンドで伝達できる情報の組合せを示した図である。
【０５４１】
本発明の一実施例によれば、ＲｏＨＣパケットストリームの構成過程で抽出された静的チェーン及び／又は動的チェーンをアウトオブバンドで伝達する方法としては、大きく分けて、シグナリングを介して伝達する方法、及びシステムデコーディングに必要なパラメータが伝達されるデータパイプを介して伝達する方法が存在し得る。本発明の一実施例によれば、上述したシステムデコーディングに必要なパラメータが伝達されるデータパイプは、ベースＤＰ（Ｄａｔａ  Ｐｉｐｅ）と命名することができる。
【０５４２】
この図面に示したように、静的チェーン及び／又は動的チェーンは、シグナリング又はベースＤＰを介して伝達することができる。本発明の一実施例によれば、第１伝送モード（Ｔｒａｎｓｐｏｒｔ  Ｍｏｄｅ＃１）〜第３伝送モード（Ｔｒａｎｓｐｏｒｔ  Ｍｏｄｅ＃３）は、第１構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃１）又は第２構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃２）に使用することができ、第４伝送モード（Ｔｒａｎｓｐｏｒｔ  Ｍｏｄｅ＃４）〜第５伝送モード（Ｔｒａｎｓｐｏｒｔ  Ｍｏｄｅ＃５）は第３構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｏｄｅ＃３）に使用することができる。
【０５４３】
本発明の一実施例によれば、それぞれの構成モード及び伝送モードは、別途のシグナリングを介してシステムの状況に合わせてスイッチして使用することができ、システム設計過程によって一つの構成モード及び一つの伝送モードのみを固定して使用することができる。
【０５４４】
この図面に示したように、第１伝送モード（Ｔｒａｎｓｐｏｒｔ  Ｍｏｄｅ＃１）で、静的チェーンはシグナリングを介して伝送することができ、動的チェーンはシグナリングを介して伝送することができ、一般的なヘッダー圧縮されたパケットは正常の（Ｎｏｒｍａｌ）データパイプを介して伝送することができる。
【０５４５】
この図面に示したように、第２伝送モード（Ｔｒａｎｓｐｏｒｔ  Ｍｏｄｅ＃２）で、静的チェーンはシグナリングを通じて伝送することができ、動的チェーンはベースデータパイプを介して伝送することができ、一般的なヘッダー圧縮されたパケットは正常のデータパイプを介して伝送することができる。
【０５４６】
この図面に示したように、第３伝送モード（Ｔｒａｎｓｐｏｒｔ  Ｍｏｄｅ＃３）で、静的チェーンはベースデータパイプを介して伝送することができ、動的チェーンはベースデータパイプを介して伝送することができ、一般的なヘッダー圧縮されたパケットは正常のデータパイプを介して伝送することができる。
【０５４７】
この図面に示したように、第４伝送モード（Ｔｒａｎｓｐｏｒｔ  Ｍｏｄｅ＃４）で、静的チェーンはシグナリングを介して伝送することができ、動的チェーンは正常のデータパイプを介して伝送することができ、一般的なヘッダー圧縮されたパケットは正常のデータパイプを介して伝送することができる。このとき、動的チェーンはＩＲ―ＤＹＮパケットによって伝送することができる。
【０５４８】
この図面に示したように、第５伝送モード（Ｔｒａｎｓｐｏｒｔ  Ｍｏｄｅ＃５）で、静的チェーンはベースデータパイプを介して伝送することができ、動的チェーンは正常のデータパイプを介して伝送することができ、一般的なヘッダー圧縮されたパケットは、正常のデータパイプを介して伝送することができる。このとき、動的チェーンはＩＲ―ＤＹＮパケットによって伝送するされることができる。
【０５４９】
図４３は、本発明の一実施例に係る静的チェーンを含むディスクリプタの構成を示した図である。
【０５５０】
本発明の一実施例によれば、静的チェーンをシグナリングで伝送するために、シグナリングで伝送できる伝送フォーマットが必要であり、ディスクリプタの形態がこれに該当し得る。
【０５５１】
本発明の一実施例に係る静的チェーンを含むディスクリプタは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ｃｏｎｔｅｘｔ＿ｉｄフィールド、ｃｏｎｔｅｘｔ＿ｐｒｏｆｉｌｅフィールド、ｓｔａｔｉｃ＿ｃｈａｉｎ＿ｌｅｎｇｔｈフィールド及び／又はｓｔａｔｉｃ＿ｃｈａｉｎ（）フィールドを含むことができる。
【０５５２】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、このディスクリプタが静的チェーンを含むディスクリプタであることを示すことができる。
【０５５３】
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、このディスクリプタの長さを示すことができる。
【０５５４】
ｃｏｎｔｅｘｔ＿ｉｄフィールドは、該当するＲｏＨＣパケットストリームに対するコンテキストＩＤを示すことができる。コンテキストＩＤの長さは、システム初期構成過程で決定することができる。このフィールドは、コンテキスト識別子情報と命名することができ、静的フィールド又は動的フィールドによる該当ＲｏＨＣパケットストリームを識別することができる。
【０５５５】
ｃｏｎｔｅｘｔ＿ｐｒｏｆｉｌｅフィールドは、該当するＲｏＨＣパケットストリームの圧縮プロトコル情報を示すことができる。すなわち、該当ＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットのヘッダーがいずれのプロトコルまで圧縮されたのかを示すことができる。
【０５５６】
ｓｔａｔｉｃ＿ｃｈａｉｎ＿ｌｅｎｇｔｈフィールドは、後に来る静的チェーン（）の長さをバイト単位で示すことができる。ここで、このディスクリプタが一つの静的チェーンのみを含む場合、このフィールドは上述したｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドに取り替えることができる。
【０５５７】
ｓｔａｔｉｃ＿ｃｈａｉｎ（）フィールドは、静的チェーンに対する情報を含むことができる。
【０５５８】
図４４は、本発明の一実施例に係る動的チェーンを含むディスクリプタの構成を示した図である。
【０５５９】
本発明の一実施例によれば、動的チェーンをシグナリングで伝送するために、シグナリングで伝送できる伝送フォーマットが必要であり、ディスクリプタの形態がこれに該当し得る。
【０５６０】
本発明の一実施例に係る動的チェーンを含むディスクリプタは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ｃｏｎｔｅｘｔ＿ｉｄフィールド、ｃｏｎｔｅｘｔ＿ｐｒｏｆｉｌｅフィールド、ｄｙｎａｍｉｃ＿ｃｈａｉｎ＿ｌｅｎｇｔｈフィールド及び／又はｄｙｎａｍｉｃ＿ｃｈａｉｎ（）フィールドを含むことができる。
【０５６１】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、このディスクリプタが動的チェーンを含むディスクリプタであることを示すことができる。
【０５６２】
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、このディスクリプタの長さを示すことができる。
【０５６３】
ｃｏｎｔｅｘｔ＿ｉｄフィールドは、該当するＲｏＨＣパケットストリームに対するコンテキストＩＤを示すことができる。コンテキストＩＤの長さはシステム初期構成過程で決定することができる。
【０５６４】
ｃｏｎｔｅｘｔ＿ｐｒｏｆｉｌｅフィールドは、該当するＲｏＨＣパケットストリームの圧縮プロトコル情報を示すことができる。
【０５６５】
ｄｙｎａｍｉｃ＿ｃｈａｉｎ＿ｌｅｎｇｔｈフィールドは、後に来る動的チェーン（）の長さをバイト単位で示すことができる。ここで、このディスクリプタが一つの動的チェーンのみを含む場合、このフィールドは上述したｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドに取り替えることができる。
【０５６６】
ｄｙｎａｍｉｃ＿ｃｈａｉｎ（）フィールドは、動的チェーンに対する情報を含むことができる。
【０５６７】
図４５は、本発明の一実施例に係る静的チェーンを含むパケットフォーマット及び動的チェーンを含むパケットフォーマットの構成を示した図である。
【０５６８】
本発明の一実施例によれば、静的チェーン及び／又は動的チェーンをベースＤＰで伝送するために、パケットの形態で伝送できる伝送フォーマットが必要であり、この図面によるパケットフォーマットの形態がこれに該当し得る。
【０５６９】
本発明の一実施例に係る静的チェーン及び／又は動的チェーンをパケットフォーマットで構成するために、該当の静的チェーン及び／又は動的チェーンに対する情報を知らせることができるヘッダーを追加することができる。追加されたヘッダーは、パケットタイプフィールド、静的／動的チェーンインジケータフィールド及び／又はペイロード長フィールドを含むことができる。本発明の一実施例に係るパケットが静的チェーン及び／又は動的チェーンを具体的に指示しにくい構造を有する場合、このパケットのペイロードに上述した静的チェーン又は動的チェーンを含むディスクリプタの情報をそのまま含ませることができる。
【０５７０】
本発明の一実施例に係る静的チェーンを含むパケットフォーマットは、パケットタイプフィールド、静的チェーンインジケータフィールド、ペイロード長フィールド及び／又は静的チェーンバイトフィールドを含むことができる。
【０５７１】
パケットタイプフィールドは、このパケットのタイプ情報を示すことができる。
【０５７２】
静的チェーンインジケータフィールドは、ペイロードを構成する情報が静的チェーンであるのか、それとも動的チェーンであるのかを示すことができる。
【０５７３】
ペイロード長フィールドは、静的チェーンを含むペイロードの長さを示すことができる。
【０５７４】
静的チェーンバイトフィールドは、このパケットのペイロードに含まれる静的チェーン情報を示すことができる。
【０５７５】
本発明の一実施例に係る動的チェーンを含むパケットフォーマットは、パケットタイプフィールド、動的チェーンインジケータフィールド、ペイロード長フィールド及び／又は動的チェーンバイトフィールドを含むことができる。
【０５７６】
パケットタイプフィールドは、このパケットのタイプ情報を示すことができる。
【０５７７】
動的チェーンインジケータフィールドは、ペイロードを構成する情報が静的チェーンであるのか、それとも動的チェーンであるのかを示すことができる。
【０５７８】
ペイロード長フィールドは、動的チェーンを含むペイロードの長さを示すことができる。
【０５７９】
動的チェーンバイトフィールドは、このパケットのペイロードに含まれる動的チェーン情報を示すことができる。
【０５８０】
図４６は、本発明の一実施例に係る放送信号送信方法を示した図である。
【０５８１】
本発明の一実施例に係る放送信号送信方法は、次のような順序に従うことができる。まず、送信側は、ＩＰパケットストリームに含まれたＩＰパケットのヘッダーを圧縮し、ＲｏＨＣパケットストリームを生成することができる（ＳＬ１７０１０）。次に、送信側は、生成されたＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットの第１部分を抽出することができる（ＳＬ１７０２０）。本発明の一実施例によれば、上述した第１部分はＲｏＨＣパケットの静的フィールド及び／又は動的フィールドを示すことができる。これに対しては、図３５、図３９、図４０、図４１に対する説明部分で詳細に説明した。次に、送信側は、ＲｏＨＣパケットの第２部分を他のタイプのＲｏＨＣパケットに変換することができる（ＳＬ１７０３０）。ここで、第２部分は、ＲｏＨＣパケットから第１部分を抽出した後で残った部分を意味することができる。本発明の一実施例によれば、後述するが、ＲｏＨＣパケットは３つのタイプに分けることができる。これに対しては後で詳細に説明し、上述した他のタイプのＲｏＨＣパケットは、３つのタイプのうち他のタイプのＲｏＨＣパケットを意味することができる。これに対しては、図３６、図３７、図３８に対する説明部分で詳細に説明した。次に、送信側は、変換された他のタイプのＲｏＨＣパケットを含む新しいパケットストリームを再構成することができる（ＳＬ１７０４０）。これに対しては、図３９、図４０、図４１の説明部分で詳細に説明した。次に、再構成されたパケットストリームを第１チャネルを介して伝送し、上述した第１部分を第２チャネルを介して伝送することができる（ＳＬ１７０５０）。これに対しては、図４２〜図４５の説明部分で詳細に説明した。
【０５８２】
本発明の他の一実施例によれば、上述したＲｏＨＣパケットは、ストリーミングが行われる間にパケットが変わることによって毎回変わる第１ヘッダー情報及びペイロードを含む第１パケット、パケットが変わることによって一定の間隔を置いて変わる第２ヘッダー情報、前記第１ヘッダー情報及びペイロードを含む第２パケット、及びストリーミングが行われる間にパケットが変わっても変わらない第３ヘッダー情報、前記第１ヘッダー情報及びペイロードを含む第３パケットのうちいずれか一つに該当し得る。ここで、第１ヘッダー情報は、ＲｏＨＣパケットの全体のヘッダーから静的フィールド及び動的フィールドを除いた残りの部分を意味することができる。よって、第１ヘッダー情報及びペイロードを含む第１パケットは、一般的なヘッダー圧縮されたパケットを示すことができる。ここで、第２ヘッダー情報は、動的フィールドを意味することができる。よって、第２ヘッダー情報、第１ヘッダー情報及びペイロードを含む第２パケットはＩＲ―ＤＹＮパケットを示すことができる。ここで、第３ヘッダー情報は、静的フィールドを意味することができる。よって、第３ヘッダー情報、第１ヘッダー情報及びペイロードを含む第３パケットはＩＲパケットを示すことができる。本発明の一実施例によれば、ＩＲパケットは、動的フィールドを含んでもよく、動的フィールドを含まなくてもよい。本発明の一実施例によれば、静的フィールドは静的チェーンと命名することができ、動的フィールドは動的チェーンと命名することができる。これに対しては、図３０〜図３２の説明部分で詳細に説明した。
【０５８３】
本発明の他の一実施例によれば、第３パケットは第２ヘッダー情報をさらに含み、上述した抽出ステップで、送信側は、生成されたＲｏＨＣパケットストリームに含まれた第３パケットから第２ヘッダー情報及び第３ヘッダー情報を抽出することができ、生成されたＲｏＨＣパケットストリームに含まれた第２パケットから第２ヘッダー情報を抽出することができる。また、上述した変換するステップで、送信側は、第３パケットから第２ヘッダー情報及び第３ヘッダー情報が抽出された後で残った部分を第１パケットに変換することができ、第２パケットから第２ヘッダー情報が抽出された後で残った部分を第１パケットに変換することができる。これに対しては、図３６及び図３９の説明部分で詳細に説明した。
【０５８４】
本発明の他の一実施例によれば、第３パケットは第２ヘッダー情報をさらに含み、上述した抽出ステップで、送信側は、生成されたＲｏＨＣパケットストリームに含まれた第３パケットから第３ヘッダー情報を抽出することができる。また、上述した変換するステップで、送信側は、第３パケットから第３ヘッダー情報が抽出された後で残った部分を第２パケットに変換することができる。これに対しては、図３８及び図４１の説明部分で詳細に説明した。
【０５８５】
本発明の他の一実施例によれば、上述した抽出ステップで、送信側は、生成されたＲｏＨＣパケットストリームに含まれた第３パケットから第３ヘッダー情報を抽出することができ、生成されたＲｏＨＣパケットストリームに含まれた第２パケットから第２ヘッダー情報を抽出することができる。また、上述した変換するステップで、送信側は、第３パケットから第３ヘッダー情報が抽出された後で残った部分を第１パケットに変換することができ、第２パケットから第２ヘッダー情報が抽出された後で残った部分を第１パケットに変換することができる。これに対しては、図３７及び図４０の説明部分で詳細に説明した。
【０５８６】
本発明の他の一実施例によれば、上述した第２チャネルは、シグナリング情報を伝送するシグナリングチャネル、及びシステムデコーディングに必要な情報を伝達するシステムチャネルを含むことができ、本発明の一実施例に係る第２ヘッダー情報及び／又は第３ヘッダー情報は、シグナリングチャネル又はシステムチャネルを介して伝送することができる。本発明の一実施例によれば、上述したシグナリングチャネルは、アウトオブバンドチャネルであって、シグナリング情報が伝送されるチャネルを示すことができる。また、上述したシステムチャネルは、アウトオブバンドチャネルであって、ベースデータパイプを示すことができる。これに対しては、図４２の説明部分で詳細に説明した。
【０５８７】
本発明の他の一実施例によれば、上述した第２ヘッダー情報又は第３ヘッダー情報をシグナリングチャネルで伝送する場合、第２ヘッダー情報又は第３ヘッダー情報はサブエレメントに含ませて伝送することができる。ここで、本発明の一実施例に係るサブエレメントは、上述した第２ヘッダー情報又は第３ヘッダー情報による該当のＲｏＨＣパケットストリームを識別するコンテキスト識別子情報、及び前記第２ヘッダー情報又は第３ヘッダー情報による該当のＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットのヘッダーがいずれのプロトコルまで圧縮されたのかを示すコンテキストプロファイル情報を含むことができる。ここで、本発明の一実施例に係るサブエレメントはディスクリプタを示すことができる。これに対しては、図４３の説明部分で詳細に説明した。
【０５８８】
本発明の他の一実施例によれば、上述した第２ヘッダー情報又は第３ヘッダー情報をシステムチャネルで伝送する場合、第２ヘッダー情報又は第３ヘッダー情報はパケットのペイロードに含ませて伝送することができる。ここで、本発明の一実施例に係るパケットは、上述したパケットのタイプ情報を示すパケットタイプ情報、ペイロードに含まれた情報が第２ヘッダー情報であるのか、それとも第３ヘッダー情報であるのかを示すインジケーター情報及び／又はペイロードの長さを示す長さ情報を含むことができる。これに対しては、図４５の説明部分で詳細に説明した。
【０５８９】
図４７は、本発明の一実施例に係る放送信号受信方法を示した図である。
【０５９０】
本発明の一実施例に係る放送信号受信方法は、次の順序に従うことができる。まず、受信側は、第１チャネルを介して再構成されたパケットストリームを受信することができる（ＳＬ１８０１０）。ここで、本発明の一実施例に係る再構成されたパケットストリームは、ＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットの第１部分を抽出し、前記ＲｏＨＣパケットの第２部分を他のタイプのＲｏＨＣパケットに変換し、前記変換された他のタイプのＲｏＨＣパケットを含む新しいパケットストリームを再構成した新しいパケットストリームを示すことができる。次に、受信側は、抽出された第１部分を第２チャネルを介して受信することができる。これに対しては、図３５〜図４１の説明部分で詳細に説明した（ＳＬ１８０２０）。次に、受信側は、受信された第１部分を用いて受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元することができる（ＳＬ１８０３０）。これに対しては、図３９〜図４１の説明部分で詳細に説明した。次に、受信側は、復元されたＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットのヘッダーの圧縮を解除し、ＩＰパケットストリームを生成することができる（ＳＬ１８０４０）。これに対しては、図３４の説明部分で詳細に説明した。次に、生成されたＩＰパケットストリームを処理し、放送データを取得することができる（ＳＬ１８０５０）。
【０５９１】
本発明の他の一実施例によれば、上述したＲｏＨＣパケットは、ストリーミングが行われる間にパケットが変わることによって毎回変わる第１ヘッダー情報及びペイロードを含む第１パケット、パケットが変わることによって一定の間隔を置いて変わる第２ヘッダー情報、前記第１ヘッダー情報及びペイロードを含む第２パケット、及びストリーミングが行われる間にパケットが変わっても変わらない第３ヘッダー情報、前記第１ヘッダー情報及びペイロードを含む第３パケットのうちいずれか一つに該当し得る。ここで、第１ヘッダー情報は、ＲｏＨＣパケットの全体のヘッダーから静的フィールド及び動的フィールドを除いた残りの部分を意味することができる。よって、第１ヘッダー情報及びペイロードを含む第１パケットは、一般的なヘッダー圧縮されたパケットを示すことができる。ここで、第２ヘッダー情報は、動的フィールドを意味することができる。よって、第２ヘッダー情報、第１ヘッダー情報及びペイロードを含む第２パケットはＩＲ―ＤＹＮパケットを示すことができる。ここで、第３ヘッダー情報は、静的フィールドを意味することができる。よって、第３ヘッダー情報、第１ヘッダー情報及びペイロードを含む第３パケットはＩＲパケットを示すことができる。本発明の一実施例によれば、ＩＲパケットは、動的フィールドを含んでもよく、動的フィールドを含まなくてもよい。本発明の一実施例によれば、静的フィールドは、静的チェーンと命名することができ、動的フィールドは動的チェーンと命名することができる。これに対しては、図３０〜図３２の説明部分で詳細に説明した。
【０５９２】
本発明の他の一実施例によれば、第３パケットは第２ヘッダー情報をさらに含み、上述した復元ステップで、受信側は、上述した第１部分に含まれて受信された第２ヘッダー情報及び第３ヘッダー情報のシーケンス番号が同一である場合、受信された再構成されたパケットストリームに含まれた各パケットのうち、上述した第２ヘッダー情報及び第３ヘッダー情報のシーケンス番号と同一のシーケンス番号を有する第１パケットを検出することができ、検出された第１パケットに第２ヘッダー情報及び第３ヘッダー情報を結合することによって第３パケットを復元することができる。その一方、受信側は、上述した第１部分に含まれて受信された第２ヘッダー情報及び第３ヘッダー情報のシーケンス番号が異なる場合、受信された再構成されたパケットストリームに含まれた各パケットのうち、上述した第２ヘッダー情報と同一のシーケンス番号を有する第１パケットを検出することができ、検出された第１パケットに第２ヘッダー情報を結合することによって第２パケットを復元することができる。このような過程を通じて、受信側は、受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元することができる。これに対しては、図３６及び図３９の説明部分で詳細に説明した。
【０５９３】
本発明の他の一実施例によれば、第３パケットは第２ヘッダー情報をさらに含み、上述した復元ステップで、受信側は、受信された再構成されたパケットストリームに含まれた各パケットのうち、第１部分に含まれて受信された第３ヘッダー情報と同一のシーケンス番号を有する第２パケットを検出することができ、検出された第２パケットに受信された第２ヘッダー情報を結合することによって第３パケットを復元することができる。このような過程を通じて、受信側は、受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元することができる。これに対しては、図３８及び図４１の説明部分で詳細に説明した。
【０５９４】
本発明の他の一実施例によれば、上述した復元ステップで、受信側は、受信された再構成されたパケットストリームに含まれた各パケットのうち、第１部分に含まれて受信された第３ヘッダー情報のシーケンス番号と同一のシーケンス番号を有する第１パケットを検出することができ、検出された第１パケットに受信された第３ヘッダー情報を結合することによって第３パケットを復元することができる。また、受信側は、受信された再構成されたパケットストリームに含まれた各パケットのうち、第１部分に含まれて受信された第２ヘッダー情報と同一のシーケンス番号を有する第１パケットを検出し、検出された第１パケットに受信された第２ヘッダー情報を結合することによって第２パケットを復元することができる。このような過程を通じて、受信側は、受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元することができる。これに対しては、図３７及び図４０の説明部分で詳細に説明した。
【０５９５】
本発明の他の一実施例によれば、上述した第２チャネルは、シグナリング情報を伝送するシグナリングチャネル、及びシステムデコーディングに必要な情報を伝達するシステムチャネルを含むことができ、本発明の一実施例に係る第２ヘッダー情報及び／又は第３ヘッダー情報は、シグナリングチャネル又はシステムチャネルを介して伝送することができる。本発明の一実施例によれば、上述したシグナリングチャネルは、アウトオブバンドチャネルであって、シグナリング情報が伝送されるチャネルを示すことができる。また、上述したシステムチャネルは、アウトオブバンドチャネルであって、ベースデータパイプを示すことができる。これに対しては、図４２の説明部分で詳細に説明した。
【０５９６】
本発明の他の一実施例によれば、上述した第２ヘッダー情報又は第３ヘッダー情報をシグナリングチャネルで伝送する場合、第２ヘッダー情報又は第３ヘッダー情報はサブエレメントに含ませて伝送することができる。ここで、本発明の一実施例に係るサブエレメントは、上述した第２ヘッダー情報又は第３ヘッダー情報による該当のＲｏＨＣパケットストリームを識別するコンテキスト識別子情報、及び前記第２ヘッダー情報又は第３ヘッダー情報による該当のＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットのヘッダーがいずれのプロトコルまで圧縮されたのかを示すコンテキストプロファイル情報を含むことができる。ここで、本発明の一実施例に係るサブエレメントはディスクリプタを示すことができる。これに対しては、図４３の説明部分で詳細に説明した。
【０５９７】
本発明の他の一実施例によれば、上述した第２ヘッダー情報又は第３ヘッダー情報をシステムチャネルで伝送する場合、第２ヘッダー情報又は第３ヘッダー情報はパケットのペイロードに含ませて伝送することができる。ここで、本発明の一実施例に係るパケットは、上述したパケットのタイプ情報を示すパケットタイプ情報、ペイロードに含まれた情報が第２ヘッダー情報であるのか、それとも第３ヘッダー情報であるのかを示すインジケーター情報及び／又はペイロードの長さを示す長さ情報を含むことができる。これに対しては、図４５の説明部分で詳細に説明した。
【０５９８】
図４８は、本発明の一実施例に係る放送信号送信装置の構造を示した図である。
【０５９９】
本発明の一実施例に係る放送信号送信装置Ｌ１９０６０は、ＲｏＨＣコンプレッサＬ１９０１０、抽出部Ｌ１９０２０、変換部Ｌ１９０３０、再構成部Ｌ１９０４０及び／又は伝送部Ｌ１９０５０を含むことができる。
【０６００】
ＲｏＨＣコンプレッサＬ１９０１０は、ＩＰパケットストリームに含まれたＩＰパケットのヘッダーを圧縮し、ＲｏＨＣパケットストリームを生成することができる。
【０６０１】
抽出部Ｌ１９０２０は、生成されたＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットの第１部分を抽出することができる。
【０６０２】
変換部Ｌ１９０３０は、ＲｏＨＣパケットの第２部分を他のタイプのＲｏＨＣパケットに変換することができる。
【０６０３】
再構成部Ｌ１９０４０は、変換された他のタイプのＲｏＨＣパケットを含む新しいパケットストリームを再構成することができる。
【０６０４】
伝送部Ｌ１９０５０は、再構成されたパケットストリームを第１チャネルを介して伝送し、上述した第１部分を第２チャネルを介して伝送することができる。
【０６０５】
本発明の一実施例に係る放送信号送信装置Ｌ１９０６０の各構成要素に対しては、上述した図３４及び図４６の説明部分で詳細に説明した。
【０６０６】
図４９は、本発明の一実施例に係る放送信号受信装置の構造を示した図である。
【０６０７】
本発明の一実施例に係る放送信号受信装置Ｌ２００６０は、第１受信部Ｌ２００１０、第２受信部Ｌ２００２０、復元部Ｌ２００３０、ＲｏＨＣデコンプレッサＬ２００４０及び／又はＩＰパケット処理部Ｌ２００５０を含むことができる。
【０６０８】
第１受信部Ｌ２００１０は、第１チャネルを介して再構成されたパケットストリームを受信することができる。ここで、再構成されたパケットストリームは、ＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットの第１部分を抽出し、ＲｏＨＣパケットの第２部分を他のタイプのＲｏＨＣパケットに変換し、変換された他のタイプのＲｏＨＣパケットを含む新しいパケットストリームを再構成した新しいパケットストリームであり得る。
【０６０９】
第２受信部Ｌ２００２０は、抽出された第１部分を第２チャネルを介して受信することができる。
【０６１０】
復元部Ｌ２００３０は、受信された第１部分を用いて受信された再構成されたパケットストリームを元のＲｏＨＣパケットストリームに復元することができる。
【０６１１】
ＲｏＨＣデコンプレッサＬ２００４０は、復元されたＲｏＨＣパケットストリームに含まれたＲｏＨＣパケットのヘッダーの圧縮を解除し、ＩＰパケットストリームを生成することができる。
【０６１２】
ＩＰパケット処理部Ｌ２００５０は、生成されたＩＰパケットストリームを処理し、放送データを取得することができる。
【０６１３】
本発明の一実施例に係る放送信号受信装置Ｌ２００６０の各構成要素に対しては、上述した図３４及び図４７の説明部分で詳細に説明した。
【０６１４】
上述したステップは、設計によって省略したり、類似又は同一の機能を行うステップに取り替えることができる。
【０６１５】
本発明の説明は、明瞭化のために、添付の図面のそれぞれを参照して説明するが、添付の図面に示す実施例を併合することによって新しい実施例を設計することもできる。前記説明で言及した実施例を実行するプログラムが記録されたコンピュータ読み取り可能記録媒体が当業者の必要によって設計されると、これも、添付した特許請求の範囲及びその均等物の範囲に属することができる。
【０６１６】
本発明に係る装置及び方法は、以上の説明で言及された実施例の構成及び方法によって制限されない。以上の説明で言及された実施例は、全体的に又は部分的に互いに選択的に結合される方式で構成され、様々な変形が可能である。
【０６１７】
また、本発明に係る方法は、ネットワーク装置に提供されるプロセッサ読み取り可能記録媒体でプロセッサ読み取り可能コードとして具現することができる。プロセッサ読み取り可能媒体は、プロセッサによって読み取り可能なデータを記憶できるいかなる種類の記録装置も含むことができる。プロセッサ読み取り可能記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ―ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサ読み取り可能記録媒体は、ネットワークを介して接続されたコンピュータシステムに分散され、分散方式でプロセッサ読み取り可能コードが記憶されて実行されてもよい。
【０６１８】
当業者は、本発明の思想及び範囲から逸脱することなく本発明の様々な変形及び変更が可能であることを認識できる。したがって、本発明は、添付した特許請求の範囲及びその均等物の範囲内で提供される本発明の変形及び変更をカバーする。
【０６１９】
装置及び方法発明が本明細書に言及されており、これらの装置及び方法発明の説明は相互補完的に適用されてもよい。
【実施例】
【０６２０】
様々な実施例が、本発明を実施するための形態において記載された。
【産業上の利用可能性】
【０６２１】
本発明は、一連の放送信号提供分野で用いられる。
【０６２２】
本発明の思想又は範囲から逸脱することなく本発明で様々な変形及び変更が可能であるということは当業者にとって自明である。したがって、本発明は、添付した特許請求の範囲及びその同等範囲内で提供される本発明の変更及び変形を含むように意図される。
【図１】
0006333983.tif 000049
【図２】
0006333983.tif 000050
【図３】
0006333983.tif 000051
【図４】
0006333983.tif 000052
【図５】
0006333983.tif 000053
【図６】
0006333983.tif 000054
【図７】
0006333983.tif 000055
【図８】
0006333983.tif 000056
【図９】
0006333983.tif 000057
【図１０】
0006333983.tif 000058
【図１１】
0006333983.tif 000059
【図１２】
0006333983.tif 000060
【図１３】
0006333983.tif 000061
【図１４】
0006333983.tif 000062
【図１５】
0006333983.tif 000063
【図１６】
0006333983.tif 000064
【図１７】
0006333983.tif 000065
【図１８】
0006333983.tif 000066
【図１９】
0006333983.tif 000067
【図２０】
0006333983.tif 000068
【図２１】
0006333983.tif 000069
【図２２】
0006333983.tif 000070
【図２３】
0006333983.tif 000071
【図２４】
0006333983.tif 000072
【図２５】
0006333983.tif 000073
【図２６】
0006333983.tif 000074
【図２７】
0006333983.tif 000075
【図２８】
0006333983.tif 000076
【図２９】
0006333983.tif 000077
【図３０】
0006333983.tif 000078
【図３１】
0006333983.tif 000079
【図３２】
0006333983.tif 000080
【図３３】
0006333983.tif 000081
【図３４】
0006333983.tif 000082
【図３５】
0006333983.tif 000083
【図３６】
0006333983.tif 000084
【図３７】
0006333983.tif 000085
【図３８】
0006333983.tif 000086
【図３９】
0006333983.tif 000087
【図４０】
0006333983.tif 000088
【図４１】
0006333983.tif 000089
【図４２】
0006333983.tif 000090
【図４３】
0006333983.tif 000091
【図４４】
0006333983.tif 000092
【図４５】
0006333983.tif 000093
【図４６】
0006333983.tif 000094
【図４７】
0006333983.tif 000095
【図４８】
0006333983.tif 000096
【図４９】
0006333983.tif 000097