特許 6196386 放送信号伝送方法、放送信号受信方法、放送信号伝送装置、放送信号受信装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6196386

(24)【登録日】2017年8月25日

(45)【発行日】2017年9月20日

(54)【発明の名称】放送信号伝送方法、放送信号受信方法、放送信号伝送装置、放送信号受信装置

(51)【国際特許分類】

   H04N 21/236 20110101AFI20170911BHJP

   H04N 21/2381 20110101ALI20170911BHJP

   H04N 21/643 20110101ALI20170911BHJP

   H04H 60/82 20080101ALI20170911BHJP

   H04L 29/08 20060101ALI20170911BHJP

【ＦＩ】

   H04N21/236

   H04N21/2381

   H04N21/643

   H04H60/82

   H04L13/00 307Z

【請求項の数】16

【全頁数】106

(21)【出願番号】特願2016-538877(P2016-538877)

(86)(22)【出願日】2015年7月29日

(65)【公表番号】特表2016-540450(P2016-540450A)

(43)【公表日】2016年12月22日

(86)【国際出願番号】KR2015007918

(87)【国際公開番号】WO2016018066

(87)【国際公開日】20160204

【審査請求日】2016年2月19日

(31)【優先権主張番号】62/031,873

(32)【優先日】2014年8月1日

(33)【優先権主張国】US

(31)【優先権主張番号】62/036,610

(32)【優先日】2014年8月12日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502032105

【氏名又は名称】エルジー エレクトロニクス インコーポレイティド

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100092624

【弁理士】

【氏名又は名称】鶴田 準一

(74)【代理人】

【識別番号】100114018

【弁理士】

【氏名又は名称】南山 知広

(74)【代理人】

【識別番号】100165191

【弁理士】

【氏名又は名称】河合 章

(74)【代理人】

【識別番号】100151459

【弁理士】

【氏名又は名称】中村 健一

(72)【発明者】

【氏名】クォン ウソク

(72)【発明者】

【氏名】オ ソチン

(72)【発明者】

【氏名】ムン キョンソ

【審査官】 久保 光宏

(56)【参考文献】

【文献】 特開２００４−１２９０４２（ＪＰ，Ａ）

【文献】 米国特許第６４３４１２９（ＵＳ，Ｂ１）

【文献】 特表２０１２−５０５６１９（ＪＰ，Ａ）

【文献】 "ETSI TS 102 606 V1.1.1 (2007-10)"，[online], ETSI，２００７年１０月，[平成29年3月3日検索]，インターネット，ＵＲＬ，http://www.etsi.org/deliver/etsi_ts/102600_102699/102606/01.01.01_60/ts_102606v010101p.pdf

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ２１／００−２１／８５８

Ｈ０４Ｈ２０／００−６０／９８

Ｈ０４Ｌ２９／００−２９／１４

Ｈ０４Ｌ１２／７０−１２／９５５

ＣＳＤＢ（日本国特許庁）

ＩＥＥＥＸｐｌｏｒｅ（ＩＥＥＥ）

(57)【特許請求の範囲】

【請求項1】

放送信号を伝送する方法であって、
放送データを含む複数個のインプットパケットを生成するステップと、
前記複数個のインプットパケットを用いて少なくとも一つのリンク層パケットを生成するステップであって、前記リンク層パケットのヘッダーは、パケットタイプ情報及びパケット構成情報を含み、前記パケットタイプ情報は、前記リンク層パケットのペイロードに含まれるインプットパケットのタイプを示し、前記パケット構成情報は、前記リンク層パケットのペイロード構成を示す、ステップと、
前記リンク層パケットを用いて放送信号を生成するステップと、
前記放送信号を伝送するステップと、
を含み、
前記ヘッダーの前記パケットタイプ情報は、前記リンク層パケットに含まれるインプットパケットが拡張されたパケットタイプを有することを示し、
前記ヘッダーは、前記リンク層パケット内の前記複数個のインプットパケットのタイプを示す拡張タイプ情報をさらに含む、放送信号伝送方法。

【請求項2】

前記ペイロードがインプットパケットの分割されたセグメントのうちの一つを含む場合、前記ヘッダーは、前記リンク層パケットに含まれるセグメントの対応するインプットパケット内の順序を示すセグメントシーケンスナンバーの情報をさらに含む、請求項１に記載の放送信号伝送方法。

【請求項3】

前記ヘッダーは、前記リンク層パケットに含まれるセグメントが対応するインプットパケットの最後のセグメントであるか否かを示す最後のセグメント指示子をさらに含む、請求項２に記載の放送信号伝送方法。

【請求項4】

前記ペイロードが前記複数個のインプットパケットを含む場合、前記ヘッダーは、前記リンク層パケットに含まれるインプットパケットの個数を示すカウント情報をさらに含む、請求項１に記載の放送信号伝送方法。

【請求項5】

前記ヘッダーは、前記リンク層パケットに含まれるそれぞれのインプットパケットの長さを示すコンポーネント長さ情報をさらに含む、請求項４に記載の放送信号伝送方法。

【請求項6】

前記コンポーネント長さ情報のそれぞれは、対応するインプットパケットがペイロードに位置する順序と同じ順序でヘッダーに位置する、請求項５に記載の放送信号伝送方法。

【請求項7】

前記ヘッダーの前記パケットタイプ情報は、前記リンク層パケット内の前記複数個のインプットパケットが前記放送データに対するシグナリングデータであることを示し、
前記ヘッダーは、シグナリングタイプ情報、及びシグナリングフォーマット情報をさらに含み、
前記シグナリングタイプ情報は、前記シグナリングデータのタイプを示し、
前記シグナリングフォーマット情報は、前記シグナリングデータのフォーマットを示す、請求項１に記載の放送信号伝送方法。

【請求項8】

前記ペイロードは、一つの全インプットパケットを含み、
前記ヘッダーは、前記リンク層パケットの前記ペイロードの長さを示す長さ情報をさらに含む、請求項１に記載の放送信号伝送方法。

【請求項9】

放送データを含む複数個のインプットパケットを生成する第１モジュールと、
前記複数個のインプットパケットを用いて少なくとも一つのリンク層パケットを生成する第２モジュールであって、前記リンク層パケットのヘッダーは、パケットタイプ情報及びパケット構成情報を含み、前記パケットタイプ情報は、前記リンク層パケットのペイロードに含まれるインプットパケットのタイプを示し、前記パケット構成情報は、前記リンク層パケットのペイロード構成を示す、第２モジュールと、
前記リンク層パケットを用いて放送信号を生成する第３モジュールと、
前記放送信号を伝送する第４モジュールと、
を備え、
前記ヘッダーの前記パケットタイプ情報は、前記リンク層パケットに含まれるインプットパケットが拡張されたパケットタイプを有することを示し、
前記ヘッダーは、前記リンク層パケット内の前記複数個のインプットパケットのタイプを示す拡張タイプ情報をさらに含む、放送信号伝送装置。

【請求項10】

前記ペイロードがインプットパケットの分割されたセグメントのうちの一つを含む場合、前記ヘッダーは、前記リンク層パケットに含まれるセグメントの対応するインプットパケット内の順序を示すセグメントシーケンスナンバーの情報をさらに含む、請求項９に記載の放送信号伝送装置。

【請求項11】

前記ヘッダーは、前記リンク層パケットに含まれるセグメントが対応するインプットパケットの最後のセグメントであるか否かを示す最後のセグメント指示子をさらに含む、請求項１０に記載の放送信号伝送装置。

【請求項12】

前記ペイロードが前記複数個のインプットパケットを含む場合、前記ヘッダーは、前記リンク層パケットに含まれるインプットパケットの個数を示すカウント情報をさらに含む、請求項９に記載の放送信号伝送装置。

【請求項13】

前記ヘッダーは、前記リンク層パケットに含まれるそれぞれのインプットパケットの長さを示すコンポーネント長さ情報をさらに含む、請求項１２に記載の放送信号伝送装置。

【請求項14】

前記コンポーネント長さ情報のそれぞれは、対応するインプットパケットがペイロードに位置する順序と同じ順序でヘッダーに位置する、請求項１３に記載の放送信号伝送装置。

【請求項15】

前記ヘッダーの前記パケットタイプ情報は、前記リンク層パケット内の前記複数個のインプットパケットが前記放送データに対するシグナリングデータであることを示し、
前記ヘッダーは、シグナリングタイプ情報、及びシグナリングフォーマット情報をさらに含み、
前記シグナリングタイプ情報は、前記シグナリングデータのタイプを示し、
前記シグナリングフォーマット情報は、前記シグナリングデータのフォーマットを示す、請求項９に記載の放送信号伝送装置。

【請求項16】

前記ペイロードは、一つの全インプットパケットを含み、
前記ヘッダーは、前記リンク層パケットの前記ペイロードの長さを示す長さ情報をさらに含む、請求項９に記載の放送信号伝送装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、放送信号伝送方法、放送信号受信方法、放送信号伝送装置、放送信号受信装置に関する。

【背景技術】

【0002】

近年、デジタル放送システムにおいてＩＰを用いた放送環境が増加している。次世代放送システムでは放送網とインターネットとを連動して放送サービスを提供するハイブリッド放送システムが構築される見込みである。したがって、既存のＩＰを用いたデジタル放送システムの技術を継承及び発展させる方案が考慮されている。しかしながら、既存のＭＰＥＧ−２ＴＳを用いる既存の放送システムからＩＰ放送システムへと完全に切り替わるには、産業的な側面又は政策的な側面で相当な期間がかかることから、ＩＰ及びＭＰＥＧ−２ ＴＳを同時に支援する放送システムが考慮されなければならない。

【発明の概要】

【発明が解決しようとする課題】

【0003】

したがって、本発明の目的は、次世代放送サービスのための放送信号を伝送、受信することができる放送信号送信装置、放送信号受信装置、および次世代放送サービスのための放送信号を送信、受信する方法を提供することにある。

【課題を解決するための手段】

【0004】

上記の目的及び他の利点を達成するために、本発明の目的によって、ここに含まれて概略的に記載されたように、放送信号送信方法は、放送データを含む複数個のインプットパケットを生成するステップと、上記複数個のインプットパケットを用いて少なくとも一つのリンク層パケット（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ）を生成するステップステップであって、上記リンク層パケットのヘッダーは、パケットタイプ情報及びパケット構成情報を含み、上記パケットタイプ情報は、上記リンク層パケットのペイロードに含まれるインプットパケットのタイプを示し、上記パケット構成情報は、上記リンク層パケットのペイロード構成を示し、上記リンク層パケットを用いて放送信号を生成する、ステップと、上記放送信号を伝送するステップとを有することができる。

【0005】

好適には、上記ペイロードがインプットパケットの分割されたセグメントのうちの一つを含む場合、上記ヘッダーは、上記リンク層パケットに含まれるセグメントの該当のインプットパケット内の順序を示すセグメントシーケンスナンバー情報をさらに含む放送信号伝送方法であってもよい。

【0006】

他の観点で、本発明は放送信号送信装置を提案する。この放送信号送信装置は、放送データを含む複数個のインプットパケットを生成する第１モジュールと、上記複数個のインプットパケットを用いて少なくとも一つのリンク層パケット（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ）を生成する第２モジュールであって、上記リンク層パケットのヘッダーは、パケットタイプ情報及びパケット構成情報を含み、上記パケットタイプ情報は、上記リンク層パケットのペイロードに含まれるインプットパケットのタイプを示し、上記パケット構成情報は、上記リンク層パケットのペイロード構成を示す、第２モジュールと、上記リンク層パケットを用いて放送信号を生成する第３モジュールと、上記放送信号を伝送する第４モジュールとを備えることができる。

【0007】

好適には、上記ペイロードがインプットパケットの分割されたセグメントのうちの一つを含む場合、上記ヘッダーは、上記リンク層パケットに含まれるセグメントの該当のインプットパケット内の順序を示すセグメントシーケンスナンバー情報をさらに含む放送信号伝送装置であってもよい。

【発明の効果】

【0008】

本発明は、効率的な放送信号伝送方法、放送信号受信方法、放送信号伝送装置、放送信号受信装置を提供することができる。

【0009】

また、本発明は、データ伝送効率を向上させ、放送信号送受信の強じん性（Ｒｏｂｕｓｔｎｅｓｓ）を増加させることができる。

【図面の簡単な説明】

【0010】

【図1】本発明の一実施例に係る、ハイブリッドベースの次世代放送システムのためのプロトコルスタック（Ｐｒｏｔｏｃｏｌ Ｓｔａｃｋ）を示す図である。

【図2】本発明の一実施例に係るリンク層（ｌｉｎｋ ｌａｙｅｒ）のインターフェース（ｉｎｔｅｒｆａｃｅ）を示す図である。

【図3】本発明の一実施例に係るリンク層のパケットの構造を示す図である。

【図4】本発明の一実施例に係るパケットタイプエレメントの値に従うパケットのタイプを示す図である。

【図5】本発明の一実施例に係る、リンク層にＩＰパケットが伝達される場合、リンク層のパケットのヘッダーの構造を示す図である。

【図6】本発明の一実施例に係る、Ｃ／Ｓフィールドの値に従う意味とヘッダーの構成情報を示す図である。

【図7】本発明の一実施例に係るカウントフィールドの値に従う意味を示す図である。

【図8】本発明の一実施例に係るＳｅｇ＿Ｌｅｎ＿ＩＤフィールドの値に従う意味及びセグメントの長さを計算する式を示す図である。

【図9】本発明の一実施例に係るノーマルパケット（ｎｏｒｍａｌ ｐａｃｋｅｔ）をカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）する過程及びリンク層パケットの長さを計算する式を示す図である。

【図10】本発明の一実施例に係る連結パケット（ｃｏｎｃａｔｅｎａｔｅｄ ｐａｃｋｅｔ）をカプセル化する過程及びリンク層パケットの長さを計算する式を示す図である。

【図11】本発明の一実施例に係るＩＰｖ４パケットを含む連結パケットの長さを求める過程及びＩＰパケットの長さフィールド（ｌｅｎｇｔｈ ｆｉｅｌｄ）が位置するオフセット（ｏｆｆｓｅｔ）値を計算する式を示す図である。

【図12】本発明の一実施例に係るＩＰｖ６パケットを含む連結パケットの長さを求める過程及びＩＰパケットの長さフィールドが位置するオフセット値を計算する式を示す図である。

【図13】本発明の一実施例に係る分割パケット（ｓｅｇｍｅｎｔｅｄ ｐａｃｋｅｔ）をカプセル化する過程を示す図である。

【図14】本発明の一実施例に係るＩＰパケットの分割（ｓｅｇｍｅｎｔａｔｉｏｎ）過程及びこれによるリンク層パケットのヘッダー情報を示す図である。

【図15】本発明の一実施例に係るＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）を含むＩＰパケットの分割（ｓｅｇｍｅｎｔａｔｉｏｎ）過程を示す図である。

【図16】本発明の一実施例に係るＭＰＥＧ−２ ＴＳ（ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ）がリンク層に入力される場合、リンク層パケットのヘッダー構造を示す図である。

【図17】本発明の一実施例に係るカウントフィールドの値に従うリンク層パケットのペイロードに含まれるＭＰＥＧ−２ ＴＳパケットの個数を示す図である。

【図18】本発明の一実施例に係るＭＰＥＧ−２ ＴＳパケットのヘッダーを示す図である。

【図19】本発明の一実施例に係る送受信機で伝送エラー指示子（Ｔｒａｎｓｐｏｒｔ Ｅｒｒｏｒ Ｉｎｄｉｃａｔｏｒ）フィールドの用途を変更する過程を示す図である。

【図20】本発明の一実施例に係るＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を示す図である。

【図21】本発明の一実施例に係る同じＰＩＤを有するＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を示す図である。

【図22】本発明の一実施例に係る、共通ＰＩＤ除去（Ｃｏｍｍｏｎ ＰＩＤ ｒｅｄｕｃｔｉｏｎ）過程、及び共通ＰＩＤ除去過程を経る場合にリンク層パケットの長さを求める式を示す図である。

【図23】本発明の一実施例に係る、共通ＰＩＤ除去が適用された場合、カウントフィールドの値に従う連結された（ｃｏｎｃａｔｅｎａｔｅｄ）ＭＰＥＧ−２ ＴＳパケットの個数及びこれに従うリンク層パケットの長さを示す図である。

【図24】本発明の一実施例に係るヌルパケット（ｎｕｌｌ ｐａｃｋｅｔ）が含まれたＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を示す図である。

【図25】本発明の一実施例に係る除去されたヌルパケットをカウントする指示子（ｉｎｄｉｃａｔｏｒ）を処理する過程及びこの過程でリンク層パケットの長さを求める式を示す図である。

【図26】本発明の他の実施例に係る、ヌルパケットが含まれたＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を示す図である。

【図27】本発明の一実施例に係る、ヌルパケットを含むストリームにおいて、同じＰＩＤ（ｐａｃｋｅｔ ｉｄｅｎｔｉｆｉｅｒ）を含むＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を示す図である。

【図28】本発明の一実施例に係る、ヌルパケットを含むストリームにおいて、同じＰＩＤを含むＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を経るとき、リンク層パケットの長さを求める式を示す図である。

【図29】本発明の一実施例に係るシグナリング伝送のためのリンク層パケットの構造を示す図である。

【図30】本発明の一実施例に係るフレームドパケット（ｆｒａｍｅｄ ｐａｃｋｅｔ）伝送のためのリンク層パケットの構造を示す図である。

【図31】本発明の一実施例に係るフレームドパケットのシンタックス（ｓｙｎｔａｘ）を示す図である。

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

【図33】本発明の一実施例に係るセクションテーブルの一般的なフォーマットを示す図である。

【図34】本発明の一実施例に係るシグナリングの伝送のためのリンク層パケットの構造を示す図である。

【図35】本発明の一実施例に係る、シグナリングタイプフィールドが示す値に従う意味とシグナリングタイプフィールドに後続する固定ヘッダー及び拡張ヘッダーに関する内容を示す図である。

【図36】本発明の一実施例に係る連結カウント（Ｃｏｎｃａｔｅｎａｔｉｏｎ Ｃｏｕｎｔ）フィールド値に従う、リンク層パケットのペイロードを構成しているデスクリプタの個数を示す図である。

【図37】本発明の一実施例に係る、リンク層パケットのペイロードに入力されたシグナリング情報がセクションテーブルである場合、セクションテーブルをペイロードにカプセル化する過程を示す図である。

【図38】本発明の一実施例に係るネットワーク情報テーブル（ｎｅｔｗｏｒｋ ｉｎｆｏｒｍａｔｉｏｎ ｔａｂｌｅ；ＮＩＴ）のシンタックスを示す図である。

【図39】本発明の一実施例に係るネットワーク情報テーブル（ＮＩＴ）に含まれている伝達システムデスクリプタ（ｄｅｌｉｖｅｒｙ ｓｙｓｔｅｍ ｄｅｓｃｒｉｐｔｏｒ）のシンタックスを示す図である。

【図40】本発明の一実施例に係る高速情報テーブル（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ；ＦＩＴ）のシンタックスを示す図である。

【図41】本発明の一実施例に係るリンク層パケットのペイロードに入力されたシグナリング情報がデスクリプタである場合、デスクリプタをペイロードにカプセル化する過程を示す図である。

【図42】本発明の一実施例に係る高速情報デスクリプタのシンタックスを示す図である。

【図43】本発明の一実施例に係る伝達システムデスクリプタを示す図である。

【図44】本発明の一実施例に係る、リンク層パケットのペイロードに入力されたシグナリング情報がＤＶＢ−ＧＳＥ標準で用いられるＧＳＥ−ＬＬＣ形態である場合、一つのＧＳＥ−ＬＬＣデータを一つのリンク層パケットのペイロードにカプセル化する過程を示す図である。

【図45】本発明の一実施例に係るリンク層パケットのペイロードに入力されたシグナリング情報がＤＶＢ−ＧＳＥ標準で用いられるＧＳＥ−ＬＬＣ形態である場合、一つのＧＳＥ−ＬＬＣデータを複数個のリンク層パケットのペイロードにカプセル化する過程を示す図である。

【図46】本発明の一実施例に係るシグナリング情報送信方法を示す図である。

【図47】本発明の一実施例に係るＲｏＨＣ伝送のためのリンク層パケット（ｌｉｎｋ ｌａｙｅｒ ｐａｃｋｅｔ）のヘッダーを示す図である。

【図48】本発明に係る、リンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃１を示す図である。

【図49】本発明に係る、リンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃２を示す図である。

【図50】本発明に係る、リンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃３を示す図である。

【図51】本発明に係る、リンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃４を示す図である。

【図52】ＭＴＵが１５００である場合において、本発明の一実施例に係るＲｏＨＣ伝送のためのリンク層パケットのヘッダーを示す図である。

【図53】本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃１を示す図である。

【図54】本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃２を示す図である。

【図55】本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃３を示す図である。

【図56】本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃４を示す図である。

【図57】本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃５を示す図である。

【図58】本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃６を示す図である。

【図59】本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃７を示す図である。

【図60】本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーの構造を示す図である。

【図61】本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、各フィールドの値が示すものを示す図である。

【図62】本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、一つのＩＰパケットがリンク層ペイロードに含まれる場合を示す図である。

【図63】本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、複数個のＩＰパケットが連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）されてリンク層ペイロードに含まれる場合を示す図である。

【図64】本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、一つのＩＰパケットが分割（ｓｅｇｍｅｎｔａｔｉｏｎ）されてリンク層ペイロードに含まれる場合を示す図である。

【図65】本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、分割されたセグメントを有するリンク層パケットを示す図である。

【図66】本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、ＣＲＣエンコーディングを活用する方案を示す図である。

【図67】本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケットの構造を示す図である。

【図68】本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、各フィールドの値が示すものを示す図である。

【図69】本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、シグナリング情報が一つのセクションテーブルである場合の構造を示す図である。

【図70】本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、シグナリング情報が一つのデスクリプタである場合の構造を示す図である。

【図71】本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、シグナリング情報が複数個のデスクリプタである場合の構造を示す図である。

【図72】本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、シグナリング情報が複数個のセクションテーブルである場合の構造を示す図である。

【図73】本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、シグナリング情報が別途の長さ値を有しない場合の構造を示す図である。

【図74】本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、一つのシグナリング情報が複数個のセグメントに分割される場合の構造を示す図である。

【図75】本発明の一実施例に係る放送信号を伝送する方法を示す図である。

【図76】本発明の一実施例に係る放送信号を伝送する装置を示す図である。

【図77】本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造を示す図である。

【図78】本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合のＳｉｇｎａｌｉｎｇ＿Ｃｌａｓｓフィールドを示す図である。

【図79】本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合のＳｉｇｎａｌｉｎｇ＿Ｃｌａｓｓフィールド及びＩｎｆｏｒｍａｔｉｏｎ＿Ｔｙｐｅフィールドを示す図である。

【図80】本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合のＳｉｇｎａｌｉｎｇ＿Ｆｏｒｍａｔフィールドを示す図である。

【図81】本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、複数個のシグナリング情報が連結された場合を示す図である。

【図82】本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、複数個のシグナリング情報が連結された場合を示す図である。

【図83】本発明の更に他の実施例に係る、リンク層にフレームドパケットが伝達される場合におけるリンク層パケット構造を示す図である。

【図84】本発明の更に他の実施例に係る、リンク層にフレームドパケットが伝達される場合において、ｅｔｈｅｒｎｅｔ＿ｔｙｐｅフィールドを示す図である。

【図85】本発明の更に他の実施例に係る、リンク層にフレームドパケットが伝達される場合において、一つのインプットパケットがリンク層ペイロードに含まれる場合を示す図である。

【図86】本発明の更に他の実施例に係る、リンク層にフレームドパケットが伝達される場合において、複数個のインプットパケットが連結されてリンク層ペイロードに含まれる場合を示す図である。

【図87】本発明の更に他の実施例に係る、リンク層にフレームドパケットが伝達される場合において、一つのインプットパケットが分割されてリンク層ペイロードに含まれる場合を示す図である。

【図88】本発明の一実施例に係る放送信号を伝送する方法を示す図である。

【図89】本発明の一実施例に係る放送信号を伝送する装置を示す図である。

【発明を実施するための形態】

【0011】

以下、添付図面及び添付図面に記載された内容を参照して本発明の実施例を詳しく説明するが、本発明がこれらの実施例に制限されたり限定されるものではない。

【0012】

本明細書で使われる用語は、本発明における機能を考慮するとともに、可能な限り、現在広く使われている一般的な用語を選択したが、これは、当分野に従事する技術者の意図、慣例又は新しい技術の出現などによって変更されてもよい。また、特定の場合には出願人が任意に選定した用語もあり、この場合、該当する発明の説明部分においてその意味を記載するものとする。したがって、本明細書で使われる用語は、単純な用語の名称ではなく、その実質的な意味と本明細書の全般にわたる内容に基づいて解釈されなければならないことは明らかである。

【0013】

本明細書でいう「シグナリング」とは、放送システム、インターネット放送システム及び／又は放送／インターネット融合システムで提供されるサービス情報（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ；ＳＩ）を伝送／受信することを意味する。サービス情報は、現存の各放送システムから提供される放送サービス情報（例えば、ＡＴＳＣ−ＳＩ及び／又はＤＶＢ−ＳＩ）を含む。

【0014】

本明細書において、「放送信号」は、地上波放送、ケーブル放送、衛星放送、及び／又はモバイル放送の他にも、インターネット放送、ブロードバンド放送、通信放送、データ放送及び／又はＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）などの両方向放送で提供される信号及び／又はデータを含む概念と定義する。

【0015】

本明細書でいう「ＰＬＰ」とは、物理層に属するデータを送信する一定のユニットを意味する。したがって、本明細書で「ＰＬＰ」と命名された内容は、「データユニット」又は「データパイプ（ｄａｔａ ｐｉｐｅ）」に言い換えてもよい。

【0016】

デジタル放送（ＤＴＶ）サービスで活用される有力なアプリケーションの一つとして、放送網とインターネットとの連動を用いたハイブリッド放送サービスを挙げることができる。ハイブリッド放送サービスは、地上波放送網を介して伝送される放送Ａ／Ｖ（Ａｕｄｉｏ／Ｖｉｄｅｏ）コンテンツと関連したエンハンスメントデータ（ｅｎｈａｎｃｅｍｅｎｔ ｄａｔａ）或いは放送Ａ／Ｖコンテンツの一部をインターネットを介して実時間で伝送し、ユーザにとって様々なコンテンツを経験することができる。

【0017】

本発明は、次世代デジタル放送システムにおいて、ＩＰパケット、ＭＰＥＧ−２ ＴＳパケット、その他放送システムで使用可能なパケットを物理層に伝達可能となるようにカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）する方法を提示することを目的とする。また、同じヘッダーフォーマットで第２層シグナリング（ｌａｙｅｒ ２ ｓｉｇｎａｌｉｎｇ）も併せて伝送できるようにする方法も提案する。

【0018】

以下に説明する内容は、装置で具現することができる。例えば、シグナリング処理部、プロトコル処理部、プロセッサ及び／又はパケット生成部で下記の過程を実行することができる。

【0019】

本発明は、次世代放送サービスのための放送信号を送受信できる装置及び方法を提供することを目的とする。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス及びＵＨＤＴＶ（Ｕｌｔｒａ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｔｅｌｅｖｉｓｉｏｎ）サービスなどを含む概念である。本発明は、上述した次世代放送サービスのための放送信号を非ＭＩＭＯ（ｎｏｎ−ＭＩＭＯ（Ｍｕｌｔｉ Ｉｎｐｕｔ Ｍｕｌｔｉ Ｏｕｔｐｕｔ））方式又はＭＩＭＯ方式で処理することを一実施例とすることができる。本発明の一実施例に係る非ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）、ＳＩＳＯ（Ｓｉｎｇｌｅ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）方式などを含むことができる。

【0020】

以下では、説明の便宜のために、ＭＩＳＯ又はＭＩＭＯにおける多重アンテナとして２個のアンテナを取り上げて説明するが、このような本発明の説明は、２個以上のアンテナを使用するシステムにも適用可能である。

【0021】

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

【0022】

本発明では、図１に示すデータリンク（ｄａｔａ ｌｉｎｋ）（カプセル化）部分の構造を提案し、上位層（ｕｐｐｅｒ ｌａｙｅｒ）から伝達されるＭＰＥＧ−２ ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）及び／又はＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットを物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）に伝達する方案を提案する。また、物理層の動作に必要なシグナリング伝達方案を提案し、後に上位層で新しいパケットタイプの伝送が考慮される時、それを物理層に伝達できる基盤を構築する。

【0023】

このプロトコル層（ｐｒｏｔｏｃｏｌ ｌａｙｅｒ）は、データリンク層（Ｄａｔａ Ｌｉｎｋ Ｌａｙｅｒ）、カプセル化層（Ｅｎｃａｐｓｕｌａｔｉｏｎ Ｌａｙｅｒ）、第２層（Ｌａｙｅｒ ２）などの色々な用語と呼ぶことができるが、本発明では、リンク層（ｌｉｎｋ ｌａｙｅｒ）と呼ぶ。実際に本発明を適用するにあたっては、リンク層（ｌｉｎｋ ｌａｙｅｒ）に代替用語を使ってもよく、この層に新しい名称を与えてもよい。

【0024】

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

【0025】

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

【0026】

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

【0027】

図１を参照すると、物理層は、ＡＴＳＣシステム及び／又はＤＶＢシステムのような放送システムで採用する物理的プロトコルを用いることができる。

【0028】

カプセル化層では、物理層から取得した情報から、ＩＰデータグラム（ｄａｔａｇｒａｍ）を取得したり、取得されたＩＰデータグラムを特定フレーム（例えば、ＲＳ Ｆｒａｍｅ、ＧＳＥ−ｌｉｔｅ、ＧＳＥ或いは信号フレームなど）に変換する。ここで、フレームは、ＩＰデータグラムの集合を含むことができる。

【0029】

ＦＡＣ（ｆａｓｔ ａｃｃｅｓｓ ｃｈａｎｎｅｌ）は、サービス及び／又はコンテンツに接近可能にするための情報（例、サービスＩＤとフレーム間のマッピング情報など）を含む。

【0030】

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

【0031】

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

【0032】

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

【0033】

ＲＴＰ／ＲＴＣＰベースＡ／Ｖ、データ（クローズドキャプション（ｃｌｏｓｅｄ ｃａｐｔｉｏｎ）、緊急警報メッセージ（ｅｍｅｒｇｅｎｃｙ ａｌｅｒｔ ｍｅｓｓａｇｅ）など）伝送は、リニアコンテンツの伝送に該当し得る。

【0034】

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

【0035】

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

【0036】

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

【0037】

コンテンツの伝送は、リニアコンテンツ（Ａ／Ｖ、データ（クローズドキャプション、緊急警報メッセージなど）の伝送と非リニアコンテンツ（ＥＳＧ、非同期型データなど）の伝送、ＭＰＥＧ ＤＡＳＨベースメディアセグメント（Ａ／Ｖ、データ）伝送を含む。

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

本発明の他の実施例に係る放送システムは、前述した放送システムに一部を追加したり、一部を変更するものに該当するので、個々の構成に関する説明については前述の放送システムに関する説明を参照されたい。

【0043】

本発明の他の実施例に係る放送システムは、ＭＰＥＧ−２システムとの互換性を維持するシステム構造を含む。例えば、既存のＭＰＥＧ−２システムで送信する線形／非リニアコンテンツをＡＴＳＣ３．０システムで受信及び動作可能なように支援したり、ＡＴＳＣ３．０システムに受信されたデータの形態、すなわち、ＭＰＥＧ−２ ＴＳか或いはＩＰデータグラムかによって、Ａ／Ｖ、データに対する処理を流動的に調節することができる。

【0044】

本発明の他の実施例に係る放送システムのカプセル化層では、物理層から取得した情報／データをＭＰＥＧ−２ ＴＳ或いはＩＰデータグラムに変換したり、或いはＩＰデータグラムを用いて特定フレーム（例えば、ＲＳフレーム、ＧＳＥ−ｌｉｔｅ、ＧＳＥ或いは信号フレームなど）に変換する。

【0045】

本発明の他の実施例に係る放送システムは、放送網を介したサービス／コンテンツの取得のために、ＭＰＥＧ−２ ＴＳか或いはＩＰデータグラムかによって流動的に取得可能にするシグナリング情報を含む。すなわち、放送システムにおいて、シグナリング情報の取得は、ＭＰＥＧ−２ ＴＳベースからシグナリング情報を取得したり、ＵＤＰプロトコルによるデータからシグナリング情報を取得することができる。

【0046】

本発明の放送システムでは、ＭＰＥＧ−２ ＴＳ及び／又はＩＰデータグラムにカプセル化された放送網ベースのリニア／非リニアコンテンツ間の同期化を支援することができる。又は、放送網及びブロードバンドを介してそれぞれ送信されたコンテンツフラグメント間の同期化を支援することができる。例えば、一つのＵＤコンテンツが分離されて放送網とブロードバンドを介して同時に伝送される場合、受信機は、伝送プロトコルに依存するタイムラインを調整し、放送網のコンテンツとブロードバンドのコンテンツとを同期化した後、一つのＵＤコンテンツとして再構成することができる。

【0047】

図２は、本発明の一実施例に係るリンク層（ｌｉｎｋ ｌａｙｅｒ）のインターフェース（ｉｎｔｅｒｆａｃｅ）を示す図である。

【0048】

送信機では、デジタル放送で主に使用するＩＰパケット及び／又はＭＰＥＧ−２ ＴＳパケットが入力として受信される場合を考慮することができる。送信機は、将来の次世代放送で使用可能な新しいプロトコルのパケットの構造も支援可能にする。リンク層でカプセル化されたデータとシグナリングは物理層に伝達される。送信機は、伝達されたデータ（シグナリングデータを含む）に対して、放送システムが支援する物理層のプロトコルに合う処理を行って、該当のデータを含む信号（ｓｉｇｎａｌ）を送出する。

【0049】

一方、受信機では、物理層から伝達されたデータとシグナリングを、上位層で処理可能なデータの形態に復元する。受信機は、パケットのヘッダーを読んだり、以下に説明するその他の方法で、物理層から伝達されるパケットがシグナリング（或いはシグナリングデータ）であるか又はデータ（或いはコンテンツデータ）であるかを区別することができる。

【0050】

送信機のリンク層（ｌｉｎｋ ｌａｙｅｒ）から伝達されるシグナリング（すなわち、シグナリングデータ）は、上位層から伝達されて、受信機の上位層に伝達されるべきシグナリング、リンク層で生成されて、受信機のリンク層におけるデータの処理に関する情報を提供するためのシグナリング、及び／又は上位層又はリンク層で生成されるが、物理層で特定データ（例えば、サービス、コンテンツ及び／又はシグナリングデータ）に対する速い探知（ｄｅｔｅｃｔｉｏｎ）のために伝達されるシグナリングを含むことができる。

【0051】

図３は、本発明の一実施例に係るリンク層のパケットの構造を示す図である。

【0052】

本発明の一実施例によれば、リンク層のパケットは、固定ヘッダー（Ｆｉｘｅｄ Ｈｅａｄｅｒ）、拡張ヘッダー（Ｅｘｔｅｎｄｅｄ Ｈｅａｄｅｒ）及び／又はペイロード（ｐａｙｌｏａｄ）を含むことができる。

【0053】

固定ヘッダーは、サイズが固定されたヘッダーである。例えば、固定ヘッダーは、１バイトのサイズを有することができる。拡張ヘッダーは、サイズが変更可能なヘッダーである。固定ヘッダーと拡張ヘッダーに続いて、上位層から伝達されるデータを含むペイロードが位置する。

【0054】

固定ヘッダーは、パケットタイプ（Ｐａｃｋｅｔ ｔｙｐｅ）エレメント（ｅｌｅｍｅｎｔ）及び／又は指示子パート（Ｉｎｄｉｃａｔｏｒ Ｐａｒｔ）エレメントを含むことができる。

【0055】

パケットタイプエレメントは３ビットのサイズを有することができる。パケットタイプエレメントは、上位層（リンク層の上位層）のパケットタイプを識別する。パケットタイプエレメントの値によって識別されるパケットのタイプは後述する。

【0056】

指示子パートエレメントは、ペイロードの構成方法及び／又は拡張ヘッダーの構成情報を含むことができる。指示子パートエレメントが示す構成方法及び／又は構成情報は、パケットのタイプによって異なってもよい。

【0057】

図４は、本発明の一実施例に係るパケットタイプエレメントの値に従うパケットのタイプを示す図である。

【0058】

例えば、パケットタイプエレメントの値が「０００」を有する場合、上位層からリンク層へ伝達されるパケットがＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ４）のパケットであることを示す。

【0059】

パケットタイプエレメントの値が「００１」を有する場合、上位層からリンク層へ伝達されるパケットがＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６）のパケットであることを示す。

【0060】

パケットタイプエレメントの値が「０１０」を有する場合、上位層からリンク層へ伝達されるパケットが圧縮された（Ｃｏｍｐｒｅｓｓｅｄ）ＩＰパケットであることを示す。

【0061】

パケットタイプエレメントの値が「０１１」を有する場合、上位層からリンク層へ伝達されるパケットがＭＰＥＧ−２ ＴＳのパケットであることを示す。

【0062】

パケットタイプエレメントの値が「１０１」を有する場合、上位層からリンク層へ伝達されるパケットがパケット化されたストリーム（Ｐａｃｋｅｔｉｚｅｄ Ｓｔｒｅａｍ）のパケットであることを示す。例えば、パケット化されたストリームは、ＭＰＥＧメディア伝送パケット（ＭＰＥＧ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ ｐａｃｋｅｔ）に該当してもよい。

【0063】

パケットタイプエレメントの値が「１１０」を有する場合、上位層からリンク層へ伝達されるパケットがシグナリング（シグナリングデータ）を伝達するパケットであることを示す。

【0064】

パケットタイプエレメントの値が「１１１」を有する場合、上位層からリンク層へ伝達されるパケットがＦｒａｍｅｄ＿Ｐａｃｋｅｔ＿ｔｙｐｅであることを示すことができる。

【0065】

図５は、本発明の一実施例に係る、リンク層にＩＰパケットが伝達される場合、リンク層のパケットのヘッダーの構造を示す図である。

【0066】

ＩＰパケットがリンク層の入力（ｉｎｐｕｔ）として取り込まれると、パケットタイプエレメントの値は、０００Ｂ（０００の３ビット）又は００１Ｂ（００１の３ビット）となる。

【0067】

ＩＰパケットが入力される場合、リンク層のパケットのヘッダーを参照すると、パケットタイプエレメントに続く指示子パートエレメントは、Ｃ／Ｓ（Ｃｏｎｃａｔｅｎａｔｉｏｎ／Ｓｅｇｍｅｎｔａｔｉｏｎ）フィールド及び／又は３ビットの付加フィールド（以下「付加フィールド」という。）を含むことができる。

【0068】

リンク層のパケットは、パケットタイプエレメントに続く２ビットのＣ／Ｓフィールドによって、固定ヘッダーの付加フィールド及び拡張ヘッダーの情報が決定される。

【0069】

Ｃ／Ｓフィールドは、入力されたＩＰパケットが処理される形態を表示し、それによる拡張ヘッダーの長さに関する情報を内包している。

【0070】

一実施例によれば、Ｃ／Ｓフィールドの値が００Ｂ（００の２ビット）であると、リンク層パケットのペイロードがノーマルパケット（ｎｏｒｍａｌ ｐａｃｋｅｔ）を含む場合に該当する。ノーマルパケットは、入力されたＩＰパケットがそのままリンク層パケットのペイロードとなるということを意味する。この場合、固定ヘッダー部分の付加フィールドは使用されず、後の使用のために予約（ｒｅｓｅｒｖｅ）される。この場合、拡張ヘッダーは用いられなくてもよい。

【0071】

Ｃ／Ｓフィールドの値が０１Ｂ（０１の２ビット）であると、リンク層パケットのペイロードが連結パケット（ｃｏｎｃａｔｅｎａｔｅｄ ｐａｃｋｅｔ）を含む場合に該当する。連結パケットは、一つ以上のＩＰパケットを含む。すなわち、一つ以上のＩＰパケットがリンク層パケットのペイロードに含まれてもよい。このとき、拡張ヘッダーは用いられず、Ｃ／Ｓフィールドに続く付加フィールドはカウントフィールド（ｃｏｕｎｔ ｆｉｅｌｄ）として使用される。カウントフィールドに関する詳細な内容は後述する。

【0072】

Ｃ／Ｓフィールドの値が１０Ｂ（１０の２ビット）であると、ペイロードが分割パケット（ｓｅｇｍｅｎｔｅｄ ｐａｃｋｅｔ）で構成される場合に該当する。分割パケットは、一つのＩＰパケットを複数のセグメントに分け、それらセグメントのうち一つのセグメントを含むパケットである。すなわち、リンク層パケットのペイロードは、ＩＰパケットに含まれる複数のセグメントのいずれか一つを含む。Ｃ／Ｓフィールドに続く付加フィールドはセグメント識別子（ｓｅｇｍｅｎｔ ＩＤ）として使用される。セグメント識別子は、セグメントを固有に識別する情報である。セグメント識別子は、ＩＰパケットが分割（ｓｅｇｍｅｎｔａｔｉｏｎ）された時に与えられるＩＤであって、後でそれぞれ伝送されるセグメントを一つに合わせる場合、同じＩＰパケットの構成要素であることを認知させる。セグメント識別子は３ビットのサイズを有することができ、同時に８個のＩＰパケットの分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を支援する。例えば、一つのＩＰパケットから分割されたセグメントは、同じセグメント識別子を有することができる。この場合、拡張ヘッダーは、１バイトの長さを有することができる。この場合、拡張ヘッダーは、Ｓｅｇ＿ＳＮフィールド（セグメントシーケンス番号フィールド（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ ｆｉｅｌｄ））及び／又はＳｅｇ＿Ｌｅｎ＿ＩＤフィールド（セグメント長識別子（Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ ＩＤ ｆｉｅｌｄ））を含むことができる。

【0073】

Ｓｅｇ＿ＳＮフィールドは、４ビットの長さを有することができ、ＩＰパケットにおいて当該セグメントのシーケンス番号を示す。Ｓｅｇ＿ＳＮフィールドＩＰパケットが分割されたとき、各セグメントの順序を確認するために用いるフィールドである。したがって、一つのＩＰパケットから分割されたペイロードを含むリンク層パケットは同じセグメント識別子（Ｓｅｇ＿ＩＤ）を有するが、異なるＳｅｇ＿ＳＮフィールドの値を有する。Ｓｅｇ＿ＳＮフィールドは４ビットのサイズを有することができ、このとき、一つのＩＰパケットは最大１６個まで分割が可能である。ＩＰパケットをより多数のセグメントに分割するには、Ｓｅｇ＿ＳＮフィールドのサイズを拡張して、セグメントの順序及び／又は個数を示すことができる。

【0074】

Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールドは、４ビットの長さを有することができ、セグメントの長さを識別する識別子である。Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールドの値による実際セグメントの長さは、後述するテーブルによって識別することができる。Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールドの代わりに実際セグメントの長さ値をシグナリングする場合、４ビットのＳｅｇ＿Ｌｅｎ＿ＩＤフィールドを１２ビットのセグメント長フィールド（Ｓｅｇｍｅｎｔ ｌｅｎｇｔｈ ｆｉｅｌｄ）に拡張してもよく、この場合、２バイトの拡張ヘッダーをリンク層パケットに含めることができる。

【0075】

Ｃ／Ｓフィールドの値が１１Ｂ（１１の２ビット）であると、Ｃ／Ｓフィールド値が１０Ｂである場合と同様に、ペイロードが分割パケット（ｓｅｇｍｅｎｔｅｄ ｐａｃｋｅｔ）を含む場合に該当する。ただし、一つのＩＰパケットから分割されたセグメントのうち最後に位置した（最後の順序の）セグメントがペイロードに含まれることを意味する。受信機は、セグメントを集めて一つのＩＰパケットとして再構成する際、Ｃ／Ｓフィールドの値を用いて、最後のセグメントを送信するリンク層パケットを識別し、当該パケットのペイロードに含まれたセグメントをＩＰパケットの最後のセグメントとして認識することができる。Ｃ／Ｓフィールドに続く付加フィールドはセグメント識別子（ｓｅｇｍｅｎｔ ＩＤ）として使用される。この場合、拡張ヘッダーは２バイトの長さを有することができる。拡張ヘッダーは、Ｓｅｇ＿ＳＮフィールド（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ ｆｉｅｌｄ）及び／又はＬ＿Ｓｅｇ＿Ｌｅｎフィールド（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ ｆｉｅｌｄ）を含む。

【0076】

Ｌ＿Ｓｅｇ＿Ｌｅｎフィールド（最後のセグメント長フィールド（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ ｆｉｅｌｄ））は、最後のセグメントの実際長さを示す。Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールドを用いてＩＰパケットの先頭から同じサイズに分割すると、最後のセグメントは、前の他のセグメントのサイズと異なるサイズを有することがある。このため、Ｌ＿Ｓｅｇ＿Ｌｅｎフィールドを用いて、セグメントの長さを直接表示してもよい。Ｌ＿Ｓｅｇ＿Ｌｅｎフィールドの割り当てられたビット数によって異なってもよいが、本願の一実施例に係るビット数の割り当てによれば、Ｌ＿Ｓｅｇ＿Ｌｅｎフィールドは、最後のセグメントの長さが１〜４０９５バイトであることを表示することができる。

【0077】

すなわち、一つのＩＰパケットを複数のセグメントに分割する場合、一定の長さのセグメントに分割することができるが、最後のセグメントの長さはＩＰパケットの長さによって異なってもよい。このため、最後のセグメントの長さを別にシグナリングする必要がある。同一名称を有するフィールドに関する説明は、前述した説明におけるそれを参照すればいい。

【0078】

図６は、本発明の一実施例に係る、Ｃ／Ｓフィールドの値に従う意味とヘッダーの構成情報を示す図である。

【0079】

Ｃ／Ｓフィールドの値が００の場合、ノーマルパケットがリンク層パケットのペイロードに含まれ、付加フィールドは予約（ｒｅｓｅｒｖｅｄ）された状態であることを示す。一方、拡張ヘッダーはリンク層パケットに含まれなくてもよい。この場合、リンク層パケットのヘッダーの総長さは１バイトでよい。

【0080】

Ｃ／Ｓフィールドの値が０１の場合、連結パケットがリンク層パケットのペイロードに含まれ、付加フィールドはカウントフィールドとして用いられてもよい。カウントフィールドに関する内容は後述される。一方、拡張ヘッダーはリンク層パケットに含まれなくてもよい。この場合、リンク層パケットのヘッダーの総長さは、１バイトであってもよい。

【0081】

Ｃ／Ｓフィールドの値が１０の場合、分割パケットがリンク層パケットのペイロードに含まれ、付加フィールドはセグメント識別子（ｓｅｇｍｅｎｔ ＩＤ）として用いられてもよい。一方、拡張ヘッダーがリンク層パケットに含まれてもよい、拡張ヘッダーは、Ｓｅｇ＿ＳＮフィールド及び／又はＳｅｇ＿Ｌｅｎ＿ＩＤフィールドを含むことができる。Ｓｅｇ＿ＳＮフィールド又はＳｅｇ＿Ｌｅｎ＿ＩＤフィールドに関する内容は、前述した説明又は後述する説明に代える。リンク層パケットのヘッダーの総長さは２バイトであってもよい。

【0082】

Ｃ／Ｓフィールドの値が１１の場合、分割パケット（最後のセグメントを含むパケット）がリンク層パケットのペイロードに含まれ、付加フィールドはセグメント識別子（ｓｅｇｍｅｎｔ ＩＤ）として用いられてもよい。一方、拡張ヘッダーがリンク層パケットに含まれてもよい。拡張ヘッダーは、Ｓｅｇ＿ＳＮフィールド及び／又はＬ＿Ｓｅｇ＿Ｌｅｎフィールドを含むことができる。Ｓｅｇ＿ＳＮフィールド又はＬ＿Ｓｅｇ＿Ｌｅｎフィールドに関する内容は、前述した説明又は後述する説明に代える。リンク層パケットのヘッダーの総長さは３バイトであってもよい。

【0083】

図７は、本発明の一実施例に係るカウントフィールドの値に従う意味を示す図である。

【0084】

カウントフィールド（Ｃｏｕｎｔ ｆｉｅｌｄ）は、リンク層パケットのペイロードが連結パケット（Ｃｏｎｃａｔｅｎａｔｅｄ ｐａｃｋｅｔ）を含む場合に用いることができる。カウントフィールドは、いくつのＩＰパケットが一つのペイロードに含まれているか示す。カウントフィールドの値はそのまま連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）されるＩＰパケットの個数を示してもよいが、０個又は１個の連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）は意味がないので、カウントフィールドは、カウントフィールドの値に２を加えた個数のＩＰパケットがペイロードに含まれることを示すことができる。一実施例によれば、カウントフィールドには３ビットを割り当てることができるので、最大９個のＩＰパケットが一つのリンク層パケットのペイロードに含まれていることを示すことができる。より多数のＩＰパケットが一つのペイロードに含まれる必要がある場合、カウントフィールドの長さを拡張したり、拡張ヘッダーで９個以上のＩＰパケットの個数に対してさらにシグナリングしたりしてもよい。

【0085】

図８は、本発明の一実施例に係るＳｅｇ＿Ｌｅｎ＿ＩＤフィールドの値に従う意味及びセグメントの長さを計算する式を示す図である。

【0086】

Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールドは、複数のセグメントのうち最後のセグメントを除外したセグメントの長さを表現するために用いられる。セグメントの長さを表示するために必要とするヘッダーのオーバーヘッド（ｏｖｅｒｈｅａｄ）を減らすために、セグメントが有し得るサイズを１６個に制限することができる。

【0087】

物理層で処理するＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）のコードレート（ｃｏｄｅ ｒａｔｅ）によって決定されているパケットの入力サイズに合わせてセグメントの長さを決定し、これをＳｅｇ＿Ｌｅｎ＿ＩＤフィールドのそれぞれの値に従う長さと指定することができる。例えば、Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールドが有するそれぞれの値に対して、セグメントの長さはあらかじめ定められていてもよい。この場合、Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールドのそれぞれの値によるセグメントの長さに関する情報は送信機で生成されて受信機に伝達され、受信機はこれを保存することができる。一方、Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールドのそれぞれの値に設定されたセグメントの長さが変わってもよいが、この場合には送信機がそれに対する新しい情報を生成して受信機に伝送し、この情報に基づいて、受信機は保存された情報をアップデートすることができる。

【0088】

一方、セグメントの長さによらずに物理層の処理が動作する場合、図示の数式のようにセグメントの長さを求めることもできる。

【0089】

ここで、Ｌｅｎ＿Ｕｎｉｔ（Ｌｅｎｇｔｈ Ｕｎｉｔ）は、セグメント長を表示する基本単位であり、ｍｉｎ＿Ｌｅｎは、セグメントの長さの最小値を意味する。Ｌｅｎ＿Ｕｎｉｔ及びｍｉｎ＿Ｌｅｎは送信機と受信機において常に同じ値を有するべきであり、一度決定された後には変わらない方がシステム運用に効率的である。このような値は、システムの初期化過程において物理層のＦＥＣの処理能力を考慮して決定することができる。例えば、図示によれば、Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールドの値によって表現されるセグメントの長さを示しており、このとき、Ｌｅｎ＿Ｕｎｉｔ値は２５６、ｍｉｎ＿Ｌｅｎ値は５１２である。

【0090】

図９は、本発明の一実施例に係る、ノーマルパケット（ｎｏｒｍａｌ ｐａｃｋｅｔ）をカプセル化する過程及びリンク層パケットの長さを計算する式を示す図である。

【0091】

前述したように、入力されたＩＰパケットが物理層の処理範囲内にあることから、連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）又は分割（ｓｅｇｍｅｎｔａｔｉｏｎ）されない場合にはノーマルパケットにカプセル化されてもよい。下記の内容は、ＩＰｖ４又はＩＰｖ６のＩＰパケットに同一に適用することができる。一つのＩＰパケットがそのままリンク層パケットのペイロードとなり、パケットタイプエレメントの値は０００Ｂ（ＩＰｖ４）又は００１Ｂ（ＩＰｖ６）となり、Ｃ／Ｓフィールドの値は００Ｂ（Ｎｏｒｍａｌ Ｐａｃｋｅｔ）となる。固定ヘッダーの余の３ビットは、後に別の用途に使用するために予備フィールドに設定されてもよい。

【0092】

リンク層パケットの長さは、次のように識別することができる。ＩＰパケットのヘッダーには、ＩＰパケットの長さを示すフィールドが含まれている。長さを示すフィールドは、常に同一の位置に来るので、受信機は、リンク層パケットの先頭（開始部）から一定オフセット（ｏｆｆｓｅｔ）だけ移動した位置のフィールドを確認して、リンク層パケットのペイロードの長さを読み取ることができる。受信機は、ＩＰｖ４の場合にはペイロードの開始点から２バイト、ＩＰｖ６の場合にはペイロードの開始点から４バイトだけ移動した位置で、２バイト長さを有する長さフィールド（ｌｅｎｇｔｈ ｆｉｅｌｄ）を読むことができる。

【0093】

同図の数式を参照すると、ＩＰｖ４の長さフィールド（ｌｅｎｇｔｈ ｆｉｅｌｄ）値をＬ_IPv4とすれば、Ｌ_IPv4は、ＩＰｖ４の全体長を表すので、ここにリンク層パケットのヘッダーの長さＬ_H（１バイト）を加えると、全体リンク層パケットの長さとなる。ここで、Ｌ_Tはリンク層パケットの長さを表す。

【0094】

同図の数式を参照すると、ＩＰｖ６の長さフィールド（ｌｅｎｇｔｈ ｆｉｅｌｄ）値をＬ_IPv6とすれば、Ｌ_IPv6は、ＩＰｖ６のＩＰパケットのペイロードの長さのみを表すので、ここにリンク層パケットのヘッダーの長さと、さらにＩＰｖ６の固定ヘッダーの長さ（４０バイト）を加えると、リンク層パケットの長さとなる。ここで、Ｌ_Tは、リンク層パケットの長さを表す。

【0095】

図１０は、本発明の一実施例に係る、連結パケット（ｃｏｎｃａｔｅｎａｔｅｄ ｐａｃｋｅｔ）をカプセル化する過程及びリンク層パケットの長さを計算する式を示す図である。

【0096】

入力されたＩＰパケットが物理層の処理範囲内に到達しない場合、複数のＩＰパケットを連結して一つのリンク層パケットにカプセル化することができる。下記の内容は、ＩＰｖ４又はＩＰｖ６のＩＰパケットに同様に適用可能である。

【0097】

複数のＩＰパケットがリンク層パケットのペイロードとなり、パケットタイプエレメントの値は０００Ｂ（ＩＰｖ４）又は００１Ｂ（ＩＰｖ６）、Ｃ／Ｓフィールドの値は０１Ｂ（Ｃｏｎｃａｔｅｎａｔｅｄ Ｐａｃｋｅｔ）となる。ここに、いくつのＩＰパケットが一つのペイロードを構成しているかを示す３ビットカウントフィールド（ｃｏｕｎｔ ｆｉｅｌｄ）が続く。

【0098】

受信機が連結パケットの長さを求めるために、ノーマルパケットの場合と類似の方法を用いることができる。カウントフィールドが示す連結されたＩＰパケットの個数をｎ、リンク層パケットのヘッダーの長さをＬ_H、それぞれのＩＰパケットの長さをＬ_k（ここで、１≦ｋ≦ｎ）とすれば、全体リンク層パケットの長さＬ_Tは、同図の数式のように計算することができる。

【0099】

ここで、連結パケットの場合には固定ヘッダーの情報のみあるので、Ｌ_H＝１（ｂｙｔｅ）となり、それぞれのＬ_k（１≦ｋ≦ｎ）値は、連結パケットに含まれるそれぞれのＩＰパケットのヘッダーに存在する長さフィールド（ｌｅｎｇｔｈ ｆｉｅｌｄ）値を読んで確認することができる。受信機は、リンク層パケットのヘッダーが終了し、ペイロードが始まる地点から一定のオフセットを有する位置で最初のＩＰパケットの長さフィールドをパーシングし、この長さフィールドを用いて、最初のＩＰパケットの長さを識別することができる。受信機は、最初のＩＰパケットの長さが終了する地点から一定のオフセットを有する位置で２番目のＩＰパケットの長さフィールドをパーシングし、この長さフィールドを用いて、２番目のＩＰパケットの長さを識別することができる。この方式をリンク層パケットのペイロードに含まれるＩＰパケットの個数だけ反復して、リンク層パケットのペイロードの長さを識別することができる。

【0100】

図１１は、本発明の一実施例に係る、ＩＰｖ４パケットを含む連結パケットの長さを求める過程及びＩＰパケットの長さフィールドが位置するオフセット値を計算する式を示す図である。

【0101】

送信機にとって、ＩＰパケットが入力される時、ＩＰパケットの長さフィールドを読むことが難しくないが、受信機にとっては、リンク層パケットを構成しているＩＰパケットの個数のみをヘッダーから読み取ることができるので、それぞれの長さフィールドの位置が知られていない。しかし、ＩＰパケットのヘッダーには常に同一位置に長さフィールドがあるので、次の方法を用いて長さフィールドの位置を探索し、連結パケットのペイロードに含まれるそれぞれのＩＰパケットの長さを求めることができる。

【0102】

連結パケットのペイロードに含まれるｎ個のＩＰパケットをそれぞれ、ＩＰ₁，ＩＰ₂，…，ＩＰ_k，…，ＩＰ_nとするとき、ＩＰ_kに該当する長さフィールドの位置は、連結パケットのペイロードの開始点からＰ_kバイトだけ離れている位置となる。ここで、Ｐ_k（１≦ｋ≦ｎ）は、連結パケットのペイロード開始点からｋ番目のＩＰパケットの長さフィールドが位置しているオフセット値であり、同図の式のように計算することができる。

【0103】

ここで、ＩＰｖ４のパケットのＰ₁は２バイトとなる。したがって、Ｐ₁から順次にＰ_k値を更新しながら、それに該当するＬ_k値を読んで前述の図１０の数式に適用すると、最終的に連結パケットの長さを求めることができる。

【0104】

図１２は、本発明の一実施例に係る、ＩＰｖ６パケットを含む連結パケットの長さを求める過程及びＩＰパケットの長さフィールドが位置するオフセット値を計算する式を示す図である。

【0105】

ＩＰｖ６パケットが連結される形態でリンク層パケットのペイロードに含まれているとき、ペイロードの長さを求める過程は、次のとおりである。ＩＰｖ６パケットに含まれている長さフィールドは、ＩＰｖ６パケットのペイロードに対する長さ情報であるので、Ｐｖ６の固定ヘッダー長である４０バイトを、長さフィールドが示すＩＰｖ６パケットのペイロード長に加えて、ＩＰｖ６パケットの長さを求めることができる。

【0106】

連結パケットのペイロードに含まれるｎ個のＩＰパケットをそれぞれＩＰ₁，ＩＰ₂，…，ＩＰ_k，…，ＩＰ_nとするとき、ＩＰ_kに該当する長さフィールドの位置は、連結パケットのペイロードの開始点からＰ_kバイトだけ離れている位置となる。ここで、Ｐ_k（１≦ｋ≦ｎ）は、連結パケットのペイロードの開始点からｋ番目のＩＰパケットの長さフィールドが位置しているオフセット値であり、同図の数式によって計算することができる。ここで、ＩＰｖ６の場合、Ｐ₁は４バイトとなる。したがって、Ｐ₁から順次にＰ_k値を更新しながら、それに該当するＬ_k値を読んで前述の図１０の数式に適用すると、最終的に連結パケットの長さを求めることができる。

【0107】

図１３は、本発明の一実施例に係る、分割パケット（ｓｅｇｍｅｎｔｅｄ ｐａｃｋｅｔ）をカプセル化する過程を示す図である。

【0108】

次に説明する内容は、ＩＰｖ４又はＩＰｖ６のＩＰパケットに同一に適用可能である。一つのＩＰパケットが分離されて、複数のリンク層パケットのペイロードとなり、パケットタイプエレメントの値は０００Ｂ（ＩＰｖ４）又は００１Ｂ（ＩＰｖ６）、Ｃ／Ｓフィールドの値はセグメントの構成によって１０Ｂ又は１１Ｂとなる。

【0109】

Ｃ／Ｓフィールドは、ＩＰパケットの最後の部分に該当するセグメントにのみ１１Ｂとなり、余り全てのセグメントには１０Ｂとなる。Ｃ／Ｓフィールドの値は、前述したように、リンク層パケットの拡張ヘッダーに関する情報を知らせることもできる。すなわち、Ｃ／Ｓフィールドの値が１０Ｂの場合には２バイト、１１Ｂの場合には３バイト長のヘッダーを有するようになる。

【0110】

同じＩＰパケットから分割されたことを知らせるために、それぞれのリンク層パケットのヘッダーに含まれるセグメント識別子（Ｓｅｇ＿ＩＤ）値は、いずれも同じ値を有しなければならない。受信機における正常なＩＰパケットの再組合せのためのセグメントの順序情報を知らせるために、順次に増加するＳｅｇ＿ＳＮ値をそれぞれのリンク層パケットのヘッダーに書き込む。

【0111】

ＩＰパケットを分割するとき、前述したように、セグメントの長さを決めて同じ長さに分割を行う。その後、当該長さ情報に合うＳｅｇ＿Ｌｅｎ＿ＩＤ値をヘッダーに書き込む。この場合、最後に位置するセグメントの長さは、前のセグメントの長さと異なることがあり、このため、長さ情報をＬ＿Ｓｅｇ＿Ｌｅｎフィールドを用いて直接表示してもよい。

【0112】

Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールド、Ｌ＿Ｓｅｇ＿Ｌｅｎフィールドを用いて表示する長さ情報は、セグメント、すなわち、リンク層パケットのペイロードに関する情報のみを表示するので、受信機は、全体リンク層パケットの長さ情報を、Ｃ／Ｓフィールドを参考してリンク層パケットのヘッダー長さを、リンク層パケットのペイロード長に加えることによって識別することができる。

【0113】

図１４は、本発明の一実施例に係るＩＰパケットの分割過程及びこれによるリンク層パケットのヘッダー情報を示す図である。

【0114】

同図は、ＩＰパケットが分割されてリンク層パケットにカプセル化される過程で、それぞれのリンク層パケットのヘッダーが有するフィールド値も示している。

【0115】

例えば、ＩＰ層から５５００バイト長さのＩＰパケットがリンク層に入力され、このＩＰパケットが５個のセグメントＳ１，Ｓ２，Ｓ３，Ｓ４，Ｓ５に分けられ、ヘッダーＨ₁，Ｈ₂，Ｈ₃，Ｈ₄，Ｈ₅が追加されて、それぞれのリンク層パケットにカプセル化される。

【0116】

ＩＰｖ４パケットの場合を仮定すると、パケットタイプエレメントの値は０００Ｂに指定することができる。Ｈ₁〜Ｈ₄は、Ｃ／Ｓフィールド値が１０Ｂとなり、Ｈ₅のＣ／Ｓフィールド値は１１Ｂとなる。同じＩＰパケットの構成であることを知らせるセグメント識別子（Ｓｅｇ＿ＩＤ）は、いずれも０００Ｂとなり、Ｓｅｇ＿ＳＮフィールドは、Ｈ₁からＨ５まで順次に００００Ｂから０１００Ｂとなる。

【0117】

５５００バイトを５で割った値は１１００バイトであり、この値と最も近い１０２４バイトの長さにセグメントを構成するとすれば、最後のセグメントであるＳ５の長さは、１４０４バイト（０１０１０１１１１１００Ｂ）となる。このとき、Ｓｅｇ＿Ｌｅｎ＿ＩＤフィールドは、前述した例示によれば、００１０Ｂの値を有することができる。

【0118】

図１５は、本発明の一実施例に係るＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）を含むＩＰパケットの分割過程を示す図である。

【0119】

ＩＰパケットが分割されて受信機に伝達された時、受信機で組み合わせたパケットの完全性を確認可能にするために、送信機は、ＩＰパケットの次にＣＲＣを付加して分割過程を行うことができる。一般にＣＲＣはパケットの最後に追加されるので、分割過程の後、最後のセグメントにＣＲＣが含まれる。

【0120】

受信機は、最後のセグメントの長さを超えるデータを受信する場合、ＣＲＣと認識することができる。又は、ＣＲＣの長さを含む長さを最後のセグメントの長さとしてシグナリングしてもよい。

【0121】

図１６は、本発明の一実施例に係る、ＭＰＥＧ−２ ＴＳ（ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ）がリンク層に入力される場合、リンク層パケットのヘッダー構造を示す図である。

【0122】

パケットタイプエレメントは、ＭＰＥＧ−２ ＴＳパケットがリンク層の入力として入ることを識別する。例えば、このとき、パケットタイプエレメントの値は０１１Ｂを有することができる。

【0123】

同図は、ＭＰＥＧ−２ ＴＳが入力される場合、リンク層パケットのヘッダー構造を示している。ＭＰＥＧ−２ ＴＳパケットがリンク層に入力される場合、リンク層パケットのヘッダーは、パケットタイプエレメント、カウントフィールド、ＰＩ（ＰＩＤ Ｉｎｄｉｃａｔｏｒ）フィールド、及び／又はＤＩ（Ｄｅｌｅｔｅｄ Ｎｕｌｌ Ｐａｃｋｅｔ Ｉｎｄｉｃａｔｏｒ）フィールドを含むことができる。

【0124】

例えば、リンク層パケットのヘッダーのパケットタイプエレメントの次に、２ビット又は３ビットのカウントフィールド、１ビッのトＰＩ（ＰＩＤ Ｉｎｄｉｃａｔｏｒ）フィールド、１ビットＤＩ（Ｄｅｌｅｔｅｄ Ｎｕｌｌ Ｐａｃｋｅｔ Ｉｎｄｉｃａｔｏｒ）フィールドが続く。カウントフィールドに２ビットを使用する場合、余りの１ビットは、後の他の用途のために予約フィールドとして残す。予約フィールドの位置によって、固定ヘッダー部分は図１６の（ａ）乃至（ｄ）のように様々に構成されてもよい。本発明では、（ａ）形態のヘッダーを基準に記述するが、他の形態のヘッダーにも同一の説明を適用することができる。

【0125】

ＭＰＥＧ−２ ＴＳパケットがリンク層に入力される場合（パケットタイプ＝０１１）には、拡張ヘッダーは用いられなくてもよい。

【0126】

カウントフィールドは、いくつのＭＰＥＧ−２ ＴＳパケットがリンク層パケットのペイロードに含まれるかを識別する。一つのＭＰＥＧ−２ ＴＳパケットのサイズは、次世代放送システムの物理層で採択する可能性が高いＦＥＣ技法であるＬＤＰＣ（Ｌｏｗ−ｄｅｎｓｉｔｙ ｐａｒｉｔｙ−ｃｈｅｃｋ）入力サイズに比べて非常に小さいので、基本的にリンク層で連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）されることを考慮することができる。すなわち、一つ以上のＭＰＥＧ−２ ＴＳパケットがリンク層パケットのペイロードに含まれるようにすることができる。ただし、連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）されるＭＰＥＧ−２ ＴＳパケットの個数をいくつかの種類に制限し、これを２ビット又は３ビットで識別することができる。ＭＰＥＧ−２ ＴＳパケットの長さは一定のサイズ（例えば、１８８バイト）を有するので、受信機は、カウントフィールドからリンク層パケットのペイロードのサイズも類推可能である。カウントフィールドの値によってＭＰＥＧ−２ ＴＳパケットの個数を指定する例示については後述する。

【0127】

ＰＩ（Ｃｏｍｍｏｎ ＰＩＤ ｉｎｄｉｃａｔｏｒ）フィールドは、一つのリンク層パケットのペイロードに含まれるＭＰＥＧ−２ ＴＳパケットのＰＩＤ（Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）がすべて同一である場合、１に設定され、そうでない場合には０に設定される。ＰＩ（Ｃｏｍｍｏｎ ＰＩＤ ｉｎｄｉｃａｔｏｒ）フィールドは１ビットサイズを有することができる。

【0128】

ＤＩ（Ｎｕｌｌ Ｐａｃｋｅｔ Ｄｅｌｅｔｉｏｎ Ｉｎｄｉｃａｔｏｒ）フィールドは、ＭＰＥＧ−２ ＴＳパケットに含まれて伝送されるヌルパケットに対する削除処理がされた場合には１に設定され、そうでない場合には０に設定される。ＤＩフィールドは１ビットのサイズを有することができる。ＤＩフィールドが１になる場合、リンク層でヌルパケット削除（Ｎｕｌｌ ｐａｃｋｅｔ ｄｅｌｅｔｉｏｎ）を支援するために、受信機はＭＰＥＧ−２ ＴＳパケットの一部フィールドを再使用することができる。

【0129】

図１７は、本発明の一実施例に係るカウントフィールドの値に従うリンク層パケットのペイロードに含まれるＭＰＥＧ−２ ＴＳパケットの個数を示す図である。

【0130】

カウントフィールドが２ビットであるとき、連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）されるＭＰＥＧ−２ ＴＳパケットの個数は、４つの場合の数が存在可能である。同期バイト（Ｓｙｎｃ ｂｙｔｅ）（４７Ｈ）を除外したリンク層パケットのペイロードのサイズもカウントフィールドによって識別されてもよい。

【0131】

カウントフィールドの値によって割り当てられるＭＰＥＧ−２ ＴＳパケットの個数は、システム設計者によって可変されてもよい。

【0132】

図１８は、本発明の一実施例に係るＭＰＥＧ−２ ＴＳパケットのヘッダーを示す図である。

【0133】

ＭＰＥＧ−２ ＴＳパケットのヘッダーは、同期バイト（Ｓｙｎｃ Ｂｙｔｅ）フィールド、伝送エラー指示子（Ｔｒａｎｓｐｏｒｔ Ｅｒｒｏｒ Ｉｎｄｉｃａｔｏｒ）フィールド、ペイロードユニット開始指示子（ｐａｙｌｏａｄ ｕｎｉｔ ｓｔａｒｔ ｉｎｄｉｃａｔｏｒ）フィールド、伝送優先順位（ｔｒａｎｓｐｏｒｔ ｐｒｉｏｒｉｔｙ）フィールド、ＰＩＤフィールド、伝送スクランブリング制御（ｔｒａｎｓｐｏｒｔ ｓｃｒａｍｂｌｉｎｇ ｃｏｎｔｒｏｌ）フィールド、適応フィールド制御（ａｄａｐｔａｔｉｏｎ ｆｉｅｌｄ ｃｏｎｔｒｏｌ）フィールド及び／又は連続性カウンター（ｃｏｎｔｉｎｕｉｔｙ ｃｏｕｎｔｅｒ）フィールドを含む。

【0134】

同期バイトは、パケットの同期を合わせるためのものであり、リンク層でのカプセル化時には除外されてもよい。同期バイトの直後に位置する伝送エラー指示子（Ｔｒａｎｓｐｏｒｔ Ｅｒｒｏｒ Ｉｎｄｉｃａｔｏｒ；ＥＩ）は、送信機では使用せず、受信機で復旧不可のエラーが発生した時、エラーがあることを上位層に知らせるための目的で使用される。このような目的によって、伝送エラー指示子フィールドは送信機では用いられないビットとなる。

【0135】

伝送エラー指示子フィールドは、ストリームで誤りを訂正できない場合に、復調過程で設定されるフィールドであって、パケットに訂正不可の誤りがあることを知らせるフィールドである。

【0136】

ペイロードユニット開始指示子フィールドは、ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ）又はＰＳＩ（Ｐｒｏｇｒａｍ−ｓｐｅｃｉｆｉｃ ｉｎｆｏｒｍａｔｉｏｎ）が開始されるか否かを識別する。

【0137】

伝送優先順位フィールドは、同じＰＩＤを有する他のパケットに比べて優先順位が高いかを識別する。

【0138】

ＰＩＤフィールドは、パケットを識別する。

【0139】

伝送スクランブリング制御フィールドは、スクランブルを使用するか否か及び／又は奇数又は偶数キーを用いてスクランブルを使用するか否かを識別する。

【0140】

適応フィールド制御フィールドは、アダプテーションフィールドが存在するか否かなどを識別する。

【0141】

連続性カウンターフィールドは、ペイロードパケットのシーケンス番号を示す。

【0142】

図１９は、本発明の一実施例に係る送受信機で伝送エラー指示子フィールドの用途を変更する過程を示す図である。

【0143】

ＤＩフィールドが１になる場合、図示のように、送信機のリンク層で伝送エラー指示子フィールドを削除ポイント指示子（Ｄｅｌｅｔｉｏｎ Ｐｏｉｎｔ Ｉｎｄｉｃａｔｏｒ；ＤＰＩ）フィールドへと用途を変更することができる。削除ポイント指示子（ＤＰＩ）フィールドは、受信機のリンク層でヌルパケット関連処理が完了した後に再び伝送エラー指示子フィールドとして復元される。すなわち、ＤＩフィールドは、ヌルパケット削除が処理されるか否かと、ＭＰＥＧ−２ ＴＳヘッダーの伝送エラー指示子フィールドの用途が変更されるか否かを同時に知らせるフィールドであってもよい。

【0144】

図２０は、本発明の一実施例に係るＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を示す図である。

【0145】

基本的にＭＰＥＧ−２ ＴＳパケットは連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）されることを考慮しているので、一つのリンク層パケットのペイロードに複数個のＭＰＥＧ−２ ＴＳパケットが含まれてもよく、その個数は前述した方法で指定することができる。一つのリンク層パケットのペイロードに含まれるＭＰＥＧ−２ ＴＳパケットの個数をｎとするとき、それぞれのＭＰＥＧ−２ ＴＳパケットはＭ_k（１≦ｋ≦ｎ）と表記することができる。

【0146】

ＭＰＥＧ−２ ＴＳパケットは一般に、４バイトの固定ヘッダーと、１８４バイトのペイロードで構成されている。４バイトのヘッダーのうち１バイトは、同期バイト（ｓｙｎｃ ｂｙｔｅ）であって、常に同じ値（４７Ｈ）を有する。したがって、一つのＭＰＥＧ−２ ＴＳパケット「Ｍ_k」は、１バイトの同期（ｓｙｎｃ）部分（Ｓ）、同期バイト（ｓｙｎｃ ｂｙｔｅ）以外の３バイトの固定ヘッダー部分（Ｈ_k）、及び／又は１８４バイトのペイロード部分（Ｐ_k）を含むことができる（ここで、１≦ｋ≦ｎ）。

【0147】

万一、ＭＰＥＧ−２ ＴＳパケットのヘッダーにアダプテーション（ａｄａｐｔａｔｉｏｎ）フィールドが使用される場合には、アダプテーションフィールドの直前まで固定ヘッダー部分として含め、余りのアダプテーション部分はペイロード部分として含めればよい。

【0148】

入力されるｎ個のＭＰＥＧ−２ ＴＳパケットを［Ｍ₁，Ｍ₂，Ｍ₃，…，Ｍ_n］とすれば、これは、［Ｓ，Ｈ₁，Ｐ₁，Ｓ，Ｈ₂，Ｐ₂，…，Ｓ，Ｈ_n，Ｐ_n］の配列を有するようになる。同期（Ｓｙｎｃ）部分は常に同じ値を有するが、これは、送信機から送信しなくても、受信機で該当の位置を探して再び挿入することができる。したがって、リンク層パケットのペイロードを構成する際、同期部分を除いてパケットのサイズを減らすことができる。このような配列を有するＭＰＥＧ−２ ＴＳパケットの集合をリンク層パケットのペイロードとして構成する時、同期部分は除いてヘッダー部分とペイロード部分を分離して［Ｈ₁，Ｈ₂，…，Ｈ_n，Ｐ₁，Ｐ₂，…，Ｐ_n］に配置する。

【0149】

ＰＩフィールド値が０、ＤＩフィールド値が０である場合、リンク層パケットのペイロードの長さは（ｎ×３）＋（ｎ×１８４）バイトとなり、ここにリンク層パケットのヘッダー長１バイトを加えると、全体リンク層パケット長が求められる。すなわち、受信機はこのような過程から、リンク層パケットの長さを識別することができる。

【0150】

図２１は、本発明の一実施例に係る、同じＰＩＤを有するＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を示す図である。

【0151】

放送データが連続してストリーミング（ｓｔｒｅａｍｉｎｇ）される場合、一つのリンク層パケットに含まれたＭＰＥＧ−２ ＴＳが有するＰＩＤ値がすべて同一である場合が発生してもよい。この場合、反復されるＰＩＤ値を一度に表記してリンク層パケットのサイズを減らすことができる。このとき、リンク層パケットのヘッダーにおけるＰＩ（ＰＩＤ ｉｎｄｉｃａｔｏｒ）フィールドを用いることができる。

【0152】

リンク層パケットのヘッダーのＰＩ（Ｃｏｍｍｏｎ ＰＩＤ Ｉｎｄｉｃａｔｏｒ）値は１に設定される。前述したように、リンク層パケットのペイロード内で、入力されるｎ個のＭＰＥＧ−２ ＴＳパケット［Ｍ₁，Ｍ₂，Ｍ₃，…，Ｍ_n］は、同期部分は除いてヘッダー部分とペイロード部分とを分離して［Ｈ₁，Ｈ₂，…，Ｈ_n，Ｐ₁，Ｐ₂，…，Ｐ_n］に配置することができる。ここで、ＭＰＥＧ−２ ＴＳのヘッダー部分［Ｈ₁，Ｈ₂，…，Ｈ_n」はすべて同一のＰＩＤを有する場合を考慮するので、ＰＩＤは一度のみ表記して伝送しても、受信機では元来のヘッダーとして復元することができる。共通するＰＩＤをＣＰＩＤ（Ｃｏｍｍｏｎ ＰＩＤ）とし、ＭＰＥＧ−２ ＴＳパケットのヘッダーＨ_kからＰＩＤを除外したヘッダーをＨ’_kとすれば（１≦ｋ≦ｎ）、リンク層パケットのペイロードを構成するＭＰＥＧ−２ ＴＳのヘッダー部分［Ｈ₁，Ｈ₂，…，Ｈ_n］を［ＣＰＩＤ，Ｈ’₁，Ｈ’₂，…，Ｈ’_n］に再構成することができる。この過程を共通ＰＩＤ除去（Ｃｏｍｍｏｎ ＰＩＤ ｒｅｄｕｃｔｉｏｎ）と呼ぶことができる。

【0153】

図２２は、本発明の一実施例に係る、共通ＰＩＤ除去過程、及び共通ＰＩＤ除去過程を経る場合におけるリンク層パケットの長さを求める式を示す図である。

【0154】

ＭＰＥＧ−２ ＴＳパケットのヘッダー部分はそれぞれ１３ビットサイズのＰＩＤを含んでいる。リンク層パケットのペイロードを構成するＭＰＥＧ−２ ＴＳパケットがいずれも同一のＰＩＤ値を有すると、連結されるパケットの個数だけＰＩＤが反復される。したがって、元来のＭＰＥＧ−２ ＴＳパケットのヘッダー部分［Ｈ₁，Ｈ₂，…，Ｈ_n］からＰＩＤ部分を除外して［Ｈ’₁，Ｈ’₂，…，Ｈ’_n］に再構成した後、共通するＰＩＤの値をＣＰＩＤ（Ｃｏｍｍｏｎ ＰＩＤ）の値に設定し、ＣＰＩＤを再構成されたヘッダー部分の前に位置させる。

【0155】

ＰＩＤ値は１３ビットの長さを有するが、全体パケットがバイト単位の形態となるには、スタッフィング（ｓｔｕｆｆｉｎｇ）ビットが追加さるてもよい。スタッフィングビットはＣＰＩＤの前又は後の部分に位置可能であり、これは、連結される他のプロトコル層（ｐｒｏｔｏｃｏｌ ｌａｙｅｒ）の構成、又はシステムの具現によって適宜配置すればよい。

【0156】

同じＰＩＤを有するＭＰＥＧ−２ ＴＳパケットのカプセル化の場合には、ＭＰＥＧ−２ ＴＳパケットのヘッダー部分からＰＩＤを除外させてカプセル化過程を行うので、次のようにリンク層パケットのペイロードの長さを求めることができる。

【0157】

図示のように、同期バイトを除外したＭＰＥＧ−２ ＴＳパケットのヘッダーは３バイトの長さを有するが、この長さから１３ビットのＰＩＤ部分を除外すると１１ビットとなる。したがって、ｎ個のパケットが連結されている場合、（ｎ×１１）ビットとなるが、連結されるパケットの個数を８の倍数に設定すると、（ｎ×１１）ビットはバイト単位の長さとなる。また、共通ＰＩＤ長さである１３ビットに３ビット長さのスタッフィングビットを追加して２バイト長さを有するＣＰＩＤ部分として構成することができる。

【0158】

したがって、同じＰＩＤを有するｎ個のＭＰＥＧ−２ ＴＳパケットをカプセル化したリンク層パケットの場合、リンク層パケットのヘッダーの長さをＬ_H、ＣＰＩＤ部分の長さＬ_CPID、リンク層パケットの全体長をＬ_Tとするとき、同図の数式のようにＬＴを求めることができる。

【0159】

図２１に示す実施例に対して、Ｌ_Hは１バイト、Ｌ_CPIDは２バイトとなる。

【0160】

図２３は、本発明の一実施例に係る、共通ＰＩＤ除去が適用された場合、カウントフィールドの値に従う連結されたＭＰＥＧ−２ ＴＳパケットの個数及びそれに従うリンク層パケットの長さを示す図である。

【0161】

連結されるＭＰＥＧ−２ ＴＳパケットの個数が決定された場合、全てのパケットが同じＰＩＤを有する場合、前述の共通ＰＩＤ除去過程が適用されてもよく、関連して説明した数式によって、受信機はリンク層パケットの長さを求めることができる。

【0162】

図２４は、本発明の一実施例に係る、ヌルパケットが含まれたＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を示す図である。

【0163】

ＭＰＥＧ−２ ＴＳパケットの伝送時に、固定された伝送率に合せるために、ヌルパケットが伝送ストリーム内に含まれてもよい。ヌルパケットは、伝送側面ではオーバーヘッドとなる部分であるので、送信機から送信しなくても、受信機でこれを復元することができる。送信機でヌルパケットを削除して送り、受信機では、削除されたヌルパケットの個数と位置を探して復元するために、リンク層パケットのヘッダーにおけるＤＩフィールドを用いることができる。このとき、リンク層パケットのヘッダーのＤＩ値は、１に設定することができる。

【0164】

入力される伝送ストリーム間の任意の位置にヌルパケットが位置するときのカプセル化は、ヌルパケットを除外したｎ個のパケットを順次に連結する形態で行うことができる。ヌルパケットを除外する際には、連続していくつのヌルパケットが除外されたかカウントした値がリンク層パケットのペイロードに含まれてもよく、受信機では、このカウントした値に基づいて元来の位置にヌルパケットを生成して埋め込むことができる。

【0165】

ヌルパケットを除外したｎ個のＭＰＥＧ−２ ＴＳパケットを［Ｍ₁，Ｍ₂，Ｍ₃，…，Ｍ_n］としたとき、ヌルパケットは、Ｍ₁〜Ｍ_nのいずれの位置に現れてもよい。一つのリンク層パケットには０からｎまでの回数でヌルパケットをカウントする部分が現れる。すなわち、一つのリンク層パケットにおいてヌルパケットがカウントされる部分が現れる回数をｐとすれば、ｐの範囲は０からｎまで現れてもよい。

【0166】

それぞれのヌルパケットのカウント値をＣ_mと表示すれば、ｍの範囲は、１≦ｍ≦ｐとなり、ｐ＝０のとき、Ｃ_mは存在しない。それぞれのＣ_mがどのＭＰＥＧ−２ ＴＳパケットの間に位置するかは、前述したように、ＭＰＥＧ−２ ＴＳパケットのヘッダーにおいて、伝送エラー指示子（ＥＩ）を削除ポイント指示子（ＤＰＩ）へと用途変更したフィールドを用いて表示する。

【0167】

本発明で、Ｃ_mは１バイトの長さを有することを提案し、これは、後にパケットの長さに余裕ができるときに拡張されることも考慮することができる。１バイト長のＣ_mは、最大２５６個のヌルパケットをカウントすることができる。ヌルパケットの指示子の役割を担うフィールドがＭＰＥＧ−２ ＴＳパケットのヘッダーに位置しているので、Ｃ_mが示す値に１を加えた数だけヌルパケットが除外されていると計算する。例えば、Ｃ_m＝０の場合に１個のヌルパケット、Ｃ_m＝１２３の場合に１２４個のヌルパケットが除外される。連続したヌルパケットが２５６個を超えると、２５７番目のヌルパケットはノーマルパケットとして処理をし、その後のヌルパケットは、前述した方法によってヌルパケットとして処理をすることができる。

【0168】

図示のように、Ｍ_iとＭ_i+1に該当するＭＰＥＧ−２ ＴＳパケットの間にヌルパケットが位置しており、これをカウントした値をＣ₁とし、Ｍ_jとＭ_j+1に該当するＭＰＥＧ−２ ＴＳパケットの間にヌルパケットが位置しており、これをカウントした値をＣ_pとすれば、実際に伝送順序は［…，Ｍ_i，Ｃ₁，Ｍ_i+1，…，Ｍ_j，Ｃ_p，Ｍ_j+1，…］になり得る。

【0169】

リンク層パケットのペイロードを構成するために、ヌルパケットではなく、ＭＰＥＧ−２ ＴＳパケットのヘッダー部分とペイロード部分とを分離して再配置する過程で、ヌルパケットをカウントした値Ｃ_m（１≦ｍ≦ｐ）は、ＭＰＥＧ−２ ＴＳパケットのヘッダー部分とペイロード部分との間に配置する。すなわち、リンク層パケットのペイロードは、［Ｈ₁，Ｈ₂，…，Ｈ_n，Ｃ₁，…，Ｃ_p，Ｐ₁，Ｐ₂，…，Ｐ_n］のように配置され、受信機では、Ｈ_kにおけるＤＰＩフィールドに現れる順に１バイトずつカウント値を確認し、その個数だけ、元来のＭＰＥＧ−２ ＴＳパケットの順序によってヌルパケットを復元する。

【0170】

図２５は、本発明の一実施例に係る、除去されたヌルパケットをカウントする指示子を処理する過程、及びこの過程でリンク層パケットの長さを求める式を示す図である。

【0171】

ヌルパケットが削除されており、それによるカウント値が存在しているという意味でＤＰＩフィールドの値を設定することができる。同図によれば、複数のＭＰＥＧ−２ ＴＳパケットのヘッダーのうちＨ_iにおけるＤＰＩフィールドの値が１になるということは、Ｈ_iとＨ_i+1との間にヌルパケットが除外されてカプセル化され、それによる１バイトカウント値が、ヘッダー部分とペイロード部分との間に位置しているということを示す。

【0172】

この過程で、リンク層パケットの長さは、同図の数式によって計算することができる。したがって、ヌルパケットの除外過程を経たｎ個のＭＰＥＧ−２ ＴＳパケットをカプセル化したリンク層パケットの場合、リンク層パケットのヘッダーの長さをＬ_H、ヌルパケットをカウントした値Ｃ_m（１≦ｍ≦ｐ）の長さをＬ_Count、リンク層パケットの全体長をＬ_Tとするとき、同図の数式によってＬ_Tを求めることができる。

【0173】

図２６は、本発明の他の実施例に係る、ヌルパケットが含まれたＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を示す図である。

【0174】

ヌルパケットを除外したカプセル化方法の他の実施例として、リンク層パケットのペイロードを構成することができる。本発明の他の実施例では、リンク層パケットペイロードを構成するためにＭＰＥＧ−２ ＴＳパケットのヘッダー部分とペイロード部分とを分離して再配置する過程で、ヌルパケットをカウントした値Ｃ_m（１≦ｍ≦ｐ）をヘッダー部分に位置させ、順序をそのまま維持する。すなわち、それぞれのＭＰＥＧ−２ ＴＳのヘッダーが終了する地点に、ヌルパケットをカウントした値を含めることができる。したがって、受信機は、それぞれのＭＰＥＧ−２ ＴＳヘッダーに含まれたＤＰＩフィールドの値から、ヌルパケットに対する除去が行われたと判断されると、当該ヘッダーの最後に含まれたカウント値を読んで、当該カウント値が示すだけのヌルパケットを再生成してストリームに含めることができる。

【0175】

図２７は、本発明の一実施例に係る、ヌルパケットを含むストリームにおいて、同じＰＩＤを含むＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を示す図である。

【0176】

本発明の一実施例に係る、ヌルパケットを含むストリームにおいて、同じＰＩＤを含むＭＰＥＧ−２ ＴＳパケットをカプセル化する過程は、前述したヌルパケットを除いてリンク層パケットをカプセル化する過程と、同じＰＩＤを有するＭＰＥＧ−２ ＴＳパケットをリンク層パケットにカプセル化する過程とを結合して行うことができる。

【0177】

ヌルパケットは、これを示す別のＰＩＤが割り当てられているので、実際の伝送ストリームにヌルパケットが含まれている場合には、同じＰＩＤとして処理されない。しかし、ヌルパケットに対する除外過程を経た後、ヌルパケットに対してはカウント値のみがリンク層パケットのペイロードに含まれるので、余りのｎ個のＭＰＥＧ−２ ＴＳパケットは同一ＰＩＤを有し、前述した方法で処理可能である。

【0178】

図２８は、本発明の一実施例に係る、ヌルパケットを含むストリームにおいて、同じＰＩＤを含むＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を経るとき、リンク層パケットの長さを求める式を示す図である。

【0179】

ヌルパケットを含むストリームにおいて、同じＰＩＤを含むＭＰＥＧ−２ ＴＳパケットをカプセル化する過程を経るとき、リンク層パケットの長さは、図２２及び／又は図２５の数式から導出することができる。これらの式をまとめて、同図の式で示すことができる。

【0180】

図２９は、本発明の一実施例に係るシグナリング伝送のためのリンク層パケットの構造を示す図である。

【0181】

ＩＰヘッダーカプセル化情報、放送チャネルスキャン情報の更新などに関する情報のように、受信機でＩＰパケット又はＭＰＥＧ−２ ＴＳパケットを受信する前にシグナリング情報を伝達するために、本発明ではリンク層にシグナリング（すなわち、シグナリングデータ）を伝達できるパケット形態を提案する。

【0182】

本発明の実施例によれば、リンク層パケットのヘッダーに含まれたパケットタイプエレメントの値が「１１０Ｂ」である場合、リンク層パケットのペイロードにシグナリングのためのセクションテーブル（又は、デスクリプタ）を含めて伝送することができる。シグナリングセクションテーブルは、従来のＤＶＢ−ＳＩ（ｓｅｒｖｉｃｅ ｉｎｆｏｒｍａｔｉｏｎ）、ＰＳＩ／ＰＳＩＰ、ＮＲＴ（Ｎｏｎ Ｒｅａｌ Ｔｉｍｅ）、ＡＴＳＣ２．０、ＭＨ（Ｍｏｂｉｌｅ／Ｈａｎｄｈｅｌｄ）に含まれるシグナリングテーブル／テーブルセクションを含むことができる。

【0183】

図３０は、本発明の一実施例に係るフレームドパケット（ｆｒａｍｅｄ ｐａｃｋｅｔ）伝送のためのリンク層パケットの構造を示す図である。

【0184】

ＩＰパケット又はＭＰＥＧ−２ ＴＳパケットの他、一般的なネットワークで用いられているパケットもリンク層パケットで伝送することができる。この場合、リンク層パケットにおけるヘッダーのパケットタイプエレメントは「１１１Ｂ」の値を有し、リンク層パケットのペイロードにフレームドパケットが含まれていることを示すことができる。

【0185】

図３１は、本発明の一実施例に係るフレームドパケットのシンタックス（ｓｙｎｔａｘ）を示す図である。

【0186】

フレームドパケットのシンタックスは、ｅｔｈｅｒｎｅｔ＿ｔｙｐｅ、ｌｅｎｇｔｈ、及び／又はｐａｃｋｅｔ（）フィールドを含むことができる。１６ビットであるｅｔｈｅｒｎｅｔ＿ｔｙｐｅフィールドは、ＩＡＮＡレジストリによって、ｐａｃｋｅｔ（）フィールド内のパケットのタイプを識別することができる。ここで、レジスターされた値のみを用いることができる。１６ビットであるｌｅｎｇｔｈフィールドは、ｐａｃｋｅｔ（）構造の全体長をバイト単位で設定することができる。可変長を有するｐａｃｋｅｔ（）フィールドはネットワークパケットを含むことができる。

【0187】

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

【0188】

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

【0189】

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

【0190】

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

【0191】

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

【0192】

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

【0193】

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

【0194】

ベースバンド動作制御器３２０５０は、ベースバンドでの信号の処理を制御する。

【0195】

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

【0196】

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

【0197】

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

【0198】

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

【0199】

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

【0200】

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

【0201】

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

【0202】

アプリケーションプロセッサ３２１３０は、受信したパケットに含まれたアプリケーションデータ及び／又はアプリケーション関連情報を抽出し、これを処理する。

【0203】

サービスガイドデータベース３２１４０はサービスガイドデータを保存する。

【0204】

図３３は、本発明の一実施例に係るセクションテーブルの一般的なフォーマットを示す図である。

【0205】

本発明の一実施例に係るセクションテーブルは、ｔａｂｌｅ＿ｉｄフィールド、ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールド、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールド、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド及び／又はｓｅｃｔｉｏｎ ｄａｔａフィールドを含む。

【0206】

ｔａｂｌｅ＿ｉｄフィールドは、当該テーブルが有する固有のＩＤ値を示す。

【0207】

ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは、当該フィールドに続くテーブルセクションのフォーマットを示す。当該フィールドの値が０であれば、当該テーブルセクションはｓｈｏｒｔフォーマットであることを示す。当該フィールドの値が１であれば、当該テーブルセクションは一般的なｌｏｎｇフォーマットに従う。本発明の一実施例に係る当該フィールド値は、常に固定値１を有することができる。

【0208】

ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドは、当該セクションの長さを示す。当該フィールドの次から当該セクションの最後の部分までの長さをバイト単位で示す。

【0209】

ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、当該テーブルのバージョン（ｖｅｒｓｉｏｎ）を示す。

【0210】

ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドが示す値が１であれば、当該セクションテーブルが有効であることを示し、０であれば、次に伝送されるセクションテーブルが有効であることを示す。

【0211】

ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、当該テーブルを構成するセクションの番号を示す。当該テーブルを構成する最初のセクションである場合、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド値は０と表示され、順次増加すればよい。

【0212】

ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、当該テーブルを構成するセクションのうち最後のセクションの番号を示す。

【0213】

ｓｅｃｔｉｏｎ ｄａｔａフィールドは、当該セクションが含むデータを含む。

【0214】

同図でＳｐｅｃｉｆｉｃ Ｕｓｅと表示したフィールドは、各テーブルによって異なるように構成可能なフィールドを示すことができる。Ｓｐｅｃｉｆｉｃ Ｕｓｅと表示したフィールドに割り当てられるビット数は、そのまま維持されてもよい。

【0215】

図３４は、本発明の一実施例に係る、シグナリングの伝送のためのリンク層パケットの構造を示す図である。

【0216】

本発明の一実施例に係るシグナリング情報をリンク層パケットを用いて送信する場合、パケットタイプエレメントの値は１１０Ｂを示すことができる。

【0217】

同図は、シグナリングが伝送される際、リンク層パケットのヘッダー構造を示している。同図を参照すると、シグナリングを送信する場合、パケットタイプエレメントの後に２ビットのシグナリングタイプフィールド（ｓｉｇｎａｌｉｎｇ ｔｙｐｅ ｆｉｅｌｄ）が存在する。シグナリングタイプフィールドは、伝送すべきシグナリングの形態を示す。シグナリングタイプフィールドによって、続く固定ヘッダー（Ｆｉｘｅｄ Ｈｅａｄｅｒ）の余りの３ビット部分及び拡張ヘッダー（Ｅｘｔｅｎｄｅｄ Ｈｅａｄｅｒ）の情報が決定される。

【0218】

本発明の一実施例に係るシグナリングタイプフィールドが示す値が００Ｂであれば、シグナリングタイプがセクションテーブル形態である場合を示す。セクションテーブルの場合、テーブルに含まれているフィールド内にセクションの分離に関する情報及びセクションの長さに関する情報が含まれているため、リンク層パケットは、別の処理無しで、パケットタイプ及びシグナリングタイプのみを指定して伝送することができる。シグナリングタイプがセクションテーブルの形態である場合、固定ヘッダー部分においてパケットタイプエレメント及びシグナリングタイプフィールドを除く余り３ビットは用いられず、後の使用のために予備されてもよい。シグナリングタイプがセクションテーブル形態である場合、基本的に拡張ヘッダーは用いられないが、リンク層パケットの長さを表示する必要がある場合には、１又は２バイトの拡張ヘッダーが追加され、これは長さフィールド（ｌｅｎｇｔｈ ｆｉｅｌｄ）に用いられてもよい。

【0219】

本発明の一実施例に係るシグナリングタイプフィールドが示す値が０１Ｂである場合は、シグナリングタイプがデスクリプタ形態である場合を示す。一般に、デスクリプタは、セクションテーブルの一部分として用いられるが、簡単なシグナリングに該当することからデスクリプタのみ伝送する際には、当該シグナリングタイプで伝送されてもよい。デスクリプタは、セクションテーブルに比べてその長さが短くてもよいので、複数のデスクリプタが一つのリンク層パケットに含まれて伝送されてもよい。本発明の一実施例に係る固定ヘッダーの指示子パート（ｉｎｄｉｃａｔｏｒ ｐａｒｔ）に該当する３ビットは、一つのリンク層パケットにいくつのデスクリプタが含まれているかを表示するために用いられてもよい。シグナリングタイプがデスクリプタ形態である場合、拡張ヘッダーは用いられず、デスクリプタ内に含まれている当該デスクリプタの長さに関する情報を用いてリンク層パケットの長さを表示することができる。リンク層パケットの長さを別途に表示する必要がある場合には、１又は２バイトの拡張ヘッダーが追加され、これは長さフィールドに用いられてもよい。

【0220】

本発明の一実施例に係るシグナリングタイプフィールド値１０Ｂは、後の別の形態のシグナリングを支援するために残すことができる。

【0221】

本発明の一実施例に係るシグナリングタイプフィールドが示す値が１１Ｂである場合は、シグナリングタイプがＧＳＥ−ＬＬＣである場合を示す。ＧＳＥ−ＬＬＣシグナリングは分離（ｓｅｇｍｅｎｔａｔｉｏｎ）可能な構造を有する。したがって、シグナリングタイプがＧＳＥ−ＬＬＣである場合、固定ヘッダー部分においてパケットタイプエレメント及びシグナリングタイプフィールドを除く余りの３ビットフィールドはｓｅｇｍｅｎｔ ＩＤに用いられてもよい。シグナリングタイプがＧＳＥ−ＬＬＣである場合、２バイトの拡張ヘッダーが追加されてもよく、上述した２バイトの拡張ヘッダーは、４ビットのＳｅｇ＿ＳＮ（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）及び１２ビットの長さフィールド（ｌｅｎｇｔｈ ｆｉｅｌｄ）から構成することができる。

【0222】

本発明の一実施例に係るＧＳＥ−ＬＬＣは、Ｇｅｎｅｒｉｃ Ｓｔｒｅａｍ Ｅｎｃａｐｓｕｌａｔｉｏｎ Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌの略語であり、ＯＳＩモデルのデータリンク層における２個の付属層の一つを意味することができる。

【0223】

図３５は、本発明の一実施例に係るシグナリングタイプフィールドが示す値に従う意味とシグナリングタイプフィールドに後続する固定ヘッダー及び拡張ヘッダーに関する内容を示す図である。

【0224】

本発明の一実施例に係るシグナリングタイプフィールドが示す値が００Ｂであると、シグナリングタイプフィールドに続くフィールドは存在しなくてもよい。

【0225】

本発明の一実施例に係るシグナリングタイプフィールドが示す値が０１Ｂであると、連結カウントフィールド（Ｃｏｕｎｔ）がシグナリングタイプフィールドの次に存在することができる。連結カウントフィールドは、シグナリングとしてセクションテーブルではなくデスクリプタのみ伝送される場合に存在するフィールドである。連結カウントフィールドは、いくつのデスクリプタがリンク層パケットのペイロードを構成しているかを示す。連結カウントフィールドに関する詳細な説明は後述する。

【0226】

本発明の一実施例に係るシグナリングタイプフィールドが示す値が１１Ｂである場合、Ｓｅｇ＿ＩＤ（Ｓｅｇｍｅｎｔ ＩＤ）フィールド、Ｓｅｇ＿ＳＮ（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）フィールド及び／又はｌｅｎｇｔｈフィールドがシグナリングタイプフィールドの次に存在することができる。ＤＶＢ＿ＧＳＥを用いて伝送可能なＬＬＣシグナリングデータ（ＬＬＣ ｓｉｇｍａｌｉｎｇ ｄａｔａ）の場合において、ＬＬＣシグナリングデータは自ら分割されてもよい。Ｓｅｇ＿ＩＤ（Ｓｅｇｍｅｎｔ ＩＤ）フィールドは、ＬＬＣデータが分割される場合に、分割されたセグメントを識別するＩＤを示す。送信されたＬＬＣデータのセグメントを一つに合わせる場合、受信側は、Ｓｅｇ＿ＩＤ（Ｓｅｇｍｅｎｔ ＩＤ）フィールドから、各ＬＬＣデータのセグメントが同じＬＬＣデータの構成要素であることがわかる。Ｓｅｇ＿ＩＤ（Ｓｅｇｍｅｎｔ ＩＤ）フィールドは３ビットのサイズを有し、８個のセグメント（ｓｅｇｍｅｎｔａｔｉｏｎ）を識別することができる。Ｓｅｇ＿ＳＮ（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）フィールドは、ＬＬＣデータが分割される場合、各セグメントの順序を示す。ＬＬＣデータの前部には当該データテーブル（ｄａｔａ ｔａｂｌｅ）に対するインデックスが含まれているので、受信機がパケットを受信する時、分割された各セグメントは必ず順次に整列されなければならない。一つのＬＬＣデータから分割されたペイロードを有するリンク層パケットは同じＳｅｇ＿ＩＤを有するが、異なるＳｅｇ＿ＳＮを有することができる。Ｓｅｇ＿ＳＮ（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）フィールドは、４ビットのサイズを有することができる。一つのＬＬＣデータは最大１６個のセグメントに分割可能である。ｌｅｎｇｔｈフィールドは、現在リンク層パケットにおいてペイロードに該当するＬＬＣデータの長さをバイト単位で示す。したがって、リンク層パケットの全体長は、ｌｅｎｇｔｈフィールドが示す値にヘッダー長である３バイトを加えた値となり得る。

【0227】

本発明の一実施例に係るＤＶＢ＿ＧＳＥは、ＤＶＢ−Ｇｅｎｎｅｒｉｃ Ｓｔｒｅａｍ Ｅｎｃａｐｓｕｌａｔｉｏｎの略語であり、ＤＶＢによって定義されたデータリンク層プロトコルを意味することができる。

【0228】

図３６は、本発明の一実施例に係る、連結カウントフィールド値に従う、リンク層パケットのペイロードを構成しているデスクリプタの個数を示す図である。

【0229】

本発明の一実施例によれば、連結カウントフィールド値に１を足した数字の個数分のデスクリプタが一つのリンク層パケットのペイロードを構成すると表示することができる。したがって、連結カウントフィールドに割り当てられたビット数が３ビットであるから、最大８個のデスクリプタが一つのリンク層パケットを構成するようにシグナルすることができる。

【0230】

図３７は、本発明の一実施例に係る、リンク層パケットのペイロードに入力されたシグナリング情報がセクションテーブルである場合に、セクションテーブルをペイロードにカプセル化する過程を示す図である。

【0231】

本発明の一実施例によれば、一つのセクションテーブルがそのままリンク層パケットのペイロードとなってもよく、この場合、パケットタイプエレメントが示す値は１１０Ｂ（ｓｉｇｎａｌｉｎｇ）となり、シグナリングタイプフィールドが示す値は００Ｂ（ｓｅｃｔｉｏｎ ｔａｂｌｅ）となってもよい。同図で、固定ヘッダーでパケットタイプエレメントとシグナリングタイプフィールドを除く余り３ビットは、後に別の用途に用いるために予備（ｒｅｓｅｒｖｅｄ）フィールドとして残すことができる。

【0232】

本発明の一実施例に係るセクションテーブルに含まれたフィールドには、当該セクションの長さを示すフィールドが含まれている。上述した当該セクションの長さを示すフィールドはセクションテーブル内で常に同一位置に存在するので、リンク層パケットのペイロードの開始から一定オフセットだけ移動した位置に存在するフィールドを確認することによって、ペイロードの長さが確認できる。セクションテーブルの場合、ペイロードが始まる部分から１２ビット移動した位置から１２ビットの長さを有するセクション長フィールド（ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈ＿ｆｉｅｌｄ）が存在する。セクション長フィールドは、セクション長フィールドの直後からセクションの最後の部分までの長さを示すことができる。したがって、セクション長フィールドが示す値に、セクション長フィールドに含まれていない部分とリンク層パケットのヘッダー長を足すことによって、全体リンク層パケットの長さを導出することができる。ここで、セクション長フィールドに含まれていない部分（３バイト）は、セクションテーブルにおいてテーブルＩＤフィールド（ｔａｂｌｅ＿ｉｄ ｆｉｅｌｄ）及びセクション長フィールド（ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈ＿ｆｉｅｌｄ）そのものの長さを含む。そして、リンク層パケットのヘッダー長は１バイトであってもよい。すなわち、リンク層パケットの全体長は、セクション長フィールドが示す値に４バイト足した値であってもよい。

【0233】

本発明の一実施例に係る受信装置でセクションテーブルを含むリンク層パケットを受信すると、リンク層パケットの固定ヘッダーの直後に続く８ビット長のテーブルＩＤフィールド（ｔａｂｌｅ＿ｉｄ ｆｉｅｌｄ）値から、受信装置は当該セクションテーブルに関する情報を取得して用いることができる。

【0234】

図３８は、本発明の一実施例に係るネットワーク情報テーブル（ＮＩＴ）のシンタックスを示す図である。

【0235】

本発明の一実施例によれば、リンク層パケットのペイロードにシグナリングのためのセクションテーブルを含めて送信する場合に、セクションテーブルとして、現在の放送ネットワーク関連情報を示すネットワーク情報テーブル（ｎｅｔｗｏｒｋ ｉｎｆｏｒｍａｔｉｏｎ ｔａｂｌｅ）をリンク層パケットのペイロードに含めることができる。

【0236】

本発明の一実施例に係るネットワーク情報テーブル（ｎｅｔｗｏｒｋ ｉｎｆｏｒｍａｔｉｏｎ ｔａｂｌｅ）は、ｔａｂｌｅ＿ｉｄフィールド、ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールド、ｎｅｔｗｏｒｋ＿ｉｄフィールド、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールド、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｎｅｔｗｏｒｋ＿ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｅｎｇｔｈフィールド、ｄｅｓｃｒｉｐｔｏｒ（）、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｌｏｏｐ＿ｌｅｎｇｔｈフィールド、ｂｒｏａｄｃａｓｔ＿ｉｄフィールド、ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄフィールド、ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド及び／又はｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｄｅｓｃｒｉｐｔｏｒ（）を含む。

【0237】

本発明の一実施例に係るネットワーク情報テーブルに含まれたフィールドのうち、前述したセクションテーブルの一般的なフォーマットを示す図面に関する説明の部分で説明したフィールドと同じ名称を有するフィールドに関する説明は、前述した説明に代える。

【0238】

ｎｅｔｗｏｒｋ＿ｉｄフィールドは、現在利用される放送ネットワーク固有の識別子を示す。

【0239】

ｎｅｔｗｏｒｋ＿ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｅｎｇｔｈフィールドは、ネットワークレベルでネットワーク関連情報を記述するデスクリプタの長さを示す。

【0240】

ｄｅｓｃｒｉｐｔｏｒ（）は、ネットワークレベルでネットワーク関連情報を記述するデスクリプタを示す。

【0241】

ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｌｏｏｐ＿ｌｅｎｇｔｈフィールドは、放送ネットワーク上で伝送されるストリーム関連情報の長さを示す。

【0242】

ｂｒｏａｄｃａｓｔ＿ｉｄフィールドは、利用される放送ネットワーク上に存在する放送局固有の識別子を示す。

【0243】

ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄフィールドは、元来利用されていた放送ネットワーク固有の識別子を示す。元来利用されていた放送ネットワークが現在利用されている放送ネットワークと異なる場合に、ＮＩＴはｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄフィールドを用いて、元来利用されていた放送ネットワークに関する情報を含むことができる。

【0244】

ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、現在の放送ネットワーク上における伝達システム（ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ）関連細部情報を記述するデスクリプタの長さを示す。

【0245】

ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｄｅｓｃｒｉｐｔｏｒ（）は、現在の放送ネットワーク上における伝達システム（ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ）関連細部情報を含むデスクリプタを示す。

【0246】

図３９は、本発明の一実施例に係るネットワーク情報テーブル（ＮＩＴ）に含まれている伝達システムデスクリプタのシンタックスを示す図である。

【0247】

本発明の一実施例に係る伝達システムデスクリプタは、伝達システム上で特定放送局が伝達するデータと関連したシグナリングデータなどを伝達するＰＬＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｉｐｅ）の情報を含むことができる。

【0248】

本発明の一実施例に係る伝達システムデスクリプタは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｉｄフィールド、ｂａｓｅ＿ＰＬＰ＿ｉｄフィールド、ｂａｓｅ＿ＰＬＰ＿ｖｅｒｓｉｏｎフィールド及び／又はｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｐａｒａｍｅｔｅｒｓ（）を含む。

【0249】

ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、当該デスクリプタが伝達システムデスクリプタであることを示す識別子を示す。

【0250】

ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、当該デスクリプタの長さを示す。

【0251】

ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｉｄフィールドは、利用される放送ネットワーク固有の伝達システム（ｄｅｌｉｖｅｒｙ ｓｙｓｔｅｍ）識別子を示す。

【0252】

ｂａｓｅ＿ＰＬＰ＿ｉｄフィールドは、ｂｒｏａｄｃａｓｔ＿ｉｄによって識別される特定放送局で送信する放送サービスを構成するコンポーネント（ｃｏｍｐｏｎｅｎｔ）をデコーディングできる代表ＰＬＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｉｐｅ）の識別子を示す。ここで、ＰＬＰは、物理層のデータパイプ（ｄａｔａ ｐｉｐｅ）を意味することができ、特定放送局で送信する放送サービスにはＰＳＩ／ＳＩ情報などが含まれてもよい。

【0253】

ｂａｓｅ＿ＰＬＰ＿ｖｅｒｓｉｏｎフィールドは、ｂａｓｅ＿ＰＬＰ＿ｉｄによって識別されるＰＬＰを介して伝送されるデータの変化によるバージョン情報を示す。例えば、ｂａｓｅ＿ＰＬＰを介してＰＳＩ／ＳＩなどのサービスシグナリングが伝達される場合、ｂａｓｅ＿ＰＬＰ＿ｖｅｒｓｉｏｎフィールド値は、サービスシグナリングの変化が起こる度に１ずつ増加してもよい。

【0254】

ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｐａｒａｍｅｔｅｒｓ（）は、放送伝送システム特性を示すパラメータを含むことができる。パラメータは、帯域幅（ｂａｎｄｗｉｄｔｈ）、ガードインターバル（ｇｕａｒｄ ｉｎｔｅｒｖａｌ）、伝送モード（ｔｒａｎｓｍｉｓｓｉｏｎ ｍｏｄｅ）、中心周波数（ｃｅｎｔｅｒ ｆｒｅｑｕｅｎｃｙ）などを含むことができる。

【0255】

図４０は、本発明の一実施例に係る高速情報テーブル（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ；ＦＩＴ）のシンタックスを示す図である。

【0256】

本発明の一実施例によれば、リンク層パケットのペイロードにシグナリングのためのセクションテーブルを含めて送信する場合に、セクションテーブルとして高速情報テーブル（ＦＩＴ）がリンク層パケットのペイロードに含まれてもよい。高速情報テーブルを用いて本発明の一実施例に係る受信装置は放送サービスを迅速で容易にスキャン及び取得することができる。

【0257】

本発明の一実施例に係る高速情報テーブルは、ｔａｂｌｅ＿ｉｄフィールド、ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールド、ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールド、ＦＩＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールド、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｎｕｍ＿ｂｒｏａｄｃａｓｔフィールド、ｂｒｏａｄｃａｓｔ＿ｉｄフィールド、ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｉｄフィールド、ｂａｓｅ＿ＰＬＰ＿ｉｄフィールド、ｂａｓｅ＿ＰＬＰ＿ｖｅｒｓｉｏｎフィールド、ｎｕｍ＿ｓｅｒｖｉｃｅフィールド、ｓｅｒｖｉｃｅ＿ｉｄフィールド、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、ｓｅｒｖｉｃｅ＿ｈｉｄｄｅｎ＿ｆｌａｇフィールド、ＳＰ＿ｉｎｄｉｃａｔｏｒフィールド、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔフィールド、ｃｏｍｐｏｎｅｎｔ＿ｉｄフィールド及び／又はＰＬＰ＿ｉｄフィールドを含む。

【0258】

本発明の一実施例に係る高速情報テーブルに含まれたフィールドのうち、前述したセクションテーブルの一般的なフォーマットを示す図面に関する説明の部分で説明したフィールドと同じ名称を有するフィールドに関する説明は、前述した説明に代える。

【0259】

ｔａｂｌｅ＿ｉｄフィールドは、当該テーブルがサービスの迅速なスキャンと関連した情報を含んでいることを示し、当該テーブルが高速情報テーブルに該当するということを示す。

【0260】

ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールドは、常に１に設定可能である。

【0261】

ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドは、論理的にｔａｂｌｅ＿ｉｄフィールドの一部に該当し、残っているフィールドのためのスコープ（ｓｃｏｐｅ）を提供することができる。

【0262】

ＦＩＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、高速情報テーブルに含まれた構文シンタックス（ｓｙｎｔａｘ）及び意味（ｓｅｍａｎｔｉｃｓ）に対するバージョン情報を示す。本発明の一実施例に係る受信装置は、ＦＩＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて当該テーブルに含まれたシグナリングを処理するか否かなどを決定することができる。

【0263】

ｎｕｍ＿ｂｒｏａｄｃａｓｔフィールドは、周波数又は伝送されるトランスポートフレーム（ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）を用いて放送サービス又はコンテンツを送信する放送局の個数を示す。

【0264】

ｂｒｏａｄｃａｓｔ＿ｉｄフィールドは、周波数又は伝送されるトランスポートフレーム（ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）を用いて放送サービス又はコンテンツを送信する放送局固有の識別子を示す。ＭＰＥＧ−２ ＴＳベースのデータを送信する放送局の場合、ｂｒｏａｄｃａｓｔ＿ｉｄは、ＭＰＥＧ−２ ＴＳのｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄと同じ値を有することができる。

【0265】

ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｉｄフィールドは、利用される放送ネットワーク上で同じ伝送パラメータを適用して処理する放送伝送システムの識別子を示す。

【0266】

ｂａｓｅ＿ＰＬＰ＿ｉｄフィールドは、ｂｒｏａｄｃａｓｔ＿ｉｄによって識別される特定放送局で送信する放送サービスシグナリングを伝達するＰＬＰの識別子を示す。ｂａｓｅ＿ＰＬＰ＿ｉｄフィールドは、ｂｒｏａｄｃａｓｔ＿ｉｄによって識別される特定放送局で送信する放送サービスを構成するコンポーネントをデコーディングできる代表ＰＬＰの識別子を示す。ここで、ＰＬＰは、物理層のデータパイプを意味することができ、特定放送局で送信する放送サービスにはＰＳＩ／ＳＩ情報などが含まれてもよい。

【0267】

ｂａｓｅ＿ＰＬＰ＿ｖｅｒｓｉｏｎフィールドは、ｂａｓｅ＿ＰＬＰ＿ｉｄによって識別されるＰＬＰを介して伝送されるデータの変化によるバージョン情報を示す。例えば、ｂａｓｅ＿ＰＬＰを介してＰＳＩ／ＳＩなどのサービスシグナリングが伝達される場合、ｂａｓｅ＿ＰＬＰ＿ｖｅｒｓｉｏｎフィールド値は、サービスシグナリングの変化が起こる度に１ずつ増加してもよい。

【0268】

ｎｕｍ＿ｓｅｒｖｉｃｅフィールドは、当該周波数又はトランスポートフレーム（ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）内でｂｒｏａｄｃａｓｔ＿ｉｄによって識別された放送局の送信する放送サービスの個数を示す。

【0269】

ｓｅｒｖｉｃｅ＿ｉｄフィールドは、放送サービスを区別可能な識別子を示す。

【0270】

ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、放送サービスのカテゴリーを示すことができる。例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド値が０ｘ０１であればＢａｓｉｃ ＴＶ、０ｘ０２であればＢａｓｉｃ Ｒａｄｉｏ、０ｘ０３であればＲＩ ｓｅｒｖｉｃｅ、０ｘ０８であればＳｅｖｉｃｅ Ｇｕｉｄｅ、０ｘ０９であればＥｍｅｒｇｅｎｃｙ Ａｌｅｒｔｉｎｇであることを示すことができる。

【0271】

ｓｅｒｖｉｃｅ＿ｈｉｄｄｅｎ＿ｆｌａｇフィールドは、当該放送サービスがＨＩＤＥＮ（ｈｉｄｄｅｎ）か否かを示す。サービスがＨＩＤＥＮの場合、当該サービスはテストサービス又は独自で用いられるサービスに該当するので、本発明の一実施例に係る受信装置は、上述したＨＩＤＥＮ放送サービスを無視したり、サービスリストから隠すことができる。

【0272】

ＳＰ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護（ｓｅｒｖｉｃｅ ｐｒｏｔｅｃｔｉｏｎ）が当該放送サービス内の一つ以上のコンポーネントに適用されるか否かを示す。

【0273】

ｎｕｍ＿ｃｏｍｐｏｎｅｎｔフィールドは、当該放送サービスを構成するコンポーネントの個数を示す。

【0274】

ｃｏｍｐｏｎｅｎｔ＿ｉｄフィールドは、放送サービス内の当該コンポーネントを区別する識別子を示す。

【0275】

ＰＬＰ＿ｉｄフィールドは、放送サービス内で当該コンポーネントが伝送されるＰＬＰを区別する識別子を示す。

【0276】

図４１は、本発明の一実施例に係る、リンク層パケットのペイロードに入力されたシグナリング情報がデスクリプタである場合、デスクリプタをペイロードにカプセル化する過程を示す図である。

【0277】

本発明の一実施例によれば、１つ又は複数のデスクリプタがリンク層パケットのペイロードに含まれてもよく、この場合、パケットタイプエレメントの示す値は１１０Ｂ（ｓｉｇｎａｌｉｎｇ）とし、シグナリングタイプフィールドの示す値は０１Ｂ（ｄｅｓｃｒｉｐｔｏｒ）とすることができる。同図で、固定ヘッダーにおいてパケットタイプエレメントとシグナリングタイプフィールドを除く余り３ビットは、いくつのデスクリプタが一つのリンク層パケットのペイロードに含まれるかを示すカウントフィールド（ｃｏｕｎｔ ｆｉｅｌｄ）となる。一つのリンク層パケットのペイロードには最大８個のデスクリプタを含めることができる。

【0278】

本発明の一実施例によれば、全てのデスクリプタは、デスクリプタの開始部分に１バイトのｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド及び１バイトのｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドを含むことができる。本発明の一実施例によれば、上述したｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドを用いて連結されたパケット（ｃｏｎｃａｔｅｎａｔｅｄ ｐａｃｋｅｔ）の長さを求めることができる。ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、デスクリプタ内で常に同一位置に存在するので、リンク層パケットのペイロードの開始から一定オフセットだけ移動した位置に存在するフィールドを確認することによって、ペイロードの長さを確認することができる。デスクリプタの場合、ペイロードが始まる部分から８ビット移動した位置に、８ビットの長さを有するｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドが存在する。ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、該フィールドの直後からデスクリプタの最後の部分までの長さを示すことができる。したがって、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドが示す値に、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドに含まれていないｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドの長さ（１バイト）及びｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドそのものの長さ（１バイト）を足すことによって、一つのデスクリプタの長さを導出することができる。そして、カウントフィールド（ｃｏｕｎｔ ｆｉｅｌｄ）が示すデスクリプタの個数だけのそれぞれのデスクリプタの長さを足すことによって、全体リンク層パケットの長さを導出することができる。例えば、本発明の一実施例に係るリンク層パケットのペイロードに含まれた２番目のデスクリプタは、ペイロードの開始から１番目のデスクリプタの長さだけ移動した位置で始まり、２番目のデスクリプタが始まる位置から一定オフセットだけ移動した位置に２番目のデスクリプタのｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドが存在し、このフィールドを確認することによって２番目のデスクリプタの全体長を導出することができる。このような過程によって、リンク層パケットのペイロードに含まれた一つ以上のデスクリプタのそれぞれの長さを導出することができ、デスクリプタのそれぞれの長さの和にリンク層パケットのヘッダー長を足すことによって、リンク層パケットの全体長を導出することができる。

【0279】

本発明の一実施例に係る受信装置で一つ以上のデスクリプタを含むリンク層パケットを受信すると、各デスクリプタに含まれた８ビット長のｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド値から、受信装置は各デスクリプタに含まれたシグナリング情報を取得して用いることができる。

【0280】

図４２は、本発明の一実施例に係る高速情報デスクリプタのシンタックスを示す図である。

【0281】

本発明の一実施例によれば、リンク層パケットのペイロードにシグナリングのためのデスクリプタを含めて送信する場合に、高速情報デスクリプタがリンク層パケットのペイロードに含まれてもよい。高速情報デスクリプタを用いて、本発明の一実施例に係る受信装置は放送サービスを迅速で容易にスキャン及び取得することができる。

【0282】

本発明の一実施例に係る高速情報デスクリプタは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ｎｕｍ＿ｂｒｏａｄｃａｓｔフィールド、ｂｒｏａｄｃａｓｔ＿ｉｄフィールド、ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｉｄフィールド、ｂａｓｅ＿ＰＬＰ＿ｉｄフィールド、ｂａｓｅ＿ＰＬＰ＿ｖｅｒｓｉｏｎフィールド、ｎｕｍ＿ｓｅｒｖｉｃｅフィールド、ｓｅｒｖｉｃｅ＿ｉｄフィールド、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、ｓｅｒｖｉｃｅ＿ｈｉｄｄｅｎ＿ｆｌａｇフィールド及び／又はＳＰ＿ｉｎｄｉｃａｔｏｒフィールドを含む。

【0283】

本発明の一実施例に係る高速情報デスクリプタに含まれたフィールドのうち、前述した高速情報テーブルに含まれたフィールドと同じ名称を有するフィールドに関する説明は、前述した高速情報テーブルに関する説明の部分に代える。

【0284】

ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、当該デスクリプタが迅速なサービススキャンと関連した情報を含んでいる高速情報デスクリプタであることを示す。

【0285】

ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、当該デスクリプタの長さを示す。

【0286】

図４３は、本発明の一実施例に係る伝達システムデスクリプタを示す図である。

【0287】

本発明の一実施例によれば、リンク層パケットのペイロードにシグナリングのためのデスクリプタを含めて送信する場合に、伝達システムデスクリプタがリンク層パケットのペイロードに含まれてもよい。伝達システムデスクリプタは、伝達システム上で特定放送局が伝達するデータと関連したシグナリングデータなどを伝達するＰＬＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｉｐｅ）の情報を含むことができる。

【0288】

本発明の一実施例に係る伝達システムデスクリプタは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｉｄフィールド、ｎｕｍ＿ｂｒｏａｄｃａｓｔフィールド、ｂａｓｅ＿ＰＬＰ＿ｉｄフィールド、ｂａｓｅ＿ＰＬＰ＿ｖｅｒｓｉｏｎフィールド、ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｐａｒａｍｅｔｅｒｓ＿ｌｅｎｇｔｈフィールド及び／又はｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｐａｒａｍｅｔｅｒｓ（）を含む。

【0289】

ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、当該デスクリプタが伝達システムデスクリプタであることを示す識別子を示す。

【0290】

ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、当該デスクリプタの長さを示す。

【0291】

ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｉｄフィールドは、利用される放送ネットワーク上で同じ伝送パラメータを使用する伝達システム（ｄｅｌｉｖｅｒｙ ｓｙｓｔｅｍ）を識別する識別子を示す。

【0292】

ｎｕｍ＿ｂｒｏａｄｃａｓｔフィールドは、周波数又は伝送されるトランスポートフレーム（ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）を用いて放送サービス又はコンテンツを送信する放送局の個数を示す。

【0293】

ｂａｓｅ＿ＰＬＰ＿ｉｄフィールドは、ｂｒｏａｄｃａｓｔ＿ｉｄによって識別される特定放送局で送信する放送サービスを構成するコンポーネントをデコーディングできる代表ＰＬＰの識別子を示す。ここで、ＰＬＰは、物理層のデータパイプを意味することができ、特定放送局で送信する放送サービスにはＰＳＩ／ＳＩ情報などが含まれてもよい。

【0294】

ｂａｓｅ＿ＰＬＰ＿ｖｅｒｓｉｏｎフィールドは、ｂａｓｅ＿ＰＬＰ＿ｉｄによって識別されるＰＬＰを介して伝送されるデータの変化によるバージョン情報を示す。例えば、ｂａｓｅ＿ＰＬＰを介してＰＳＩ／ＳＩなどのサービスシグナリングが伝達される場合、ｂａｓｅ＿ＰＬＰ＿ｖｅｒｓｉｏｎフィールド値は、サービスシグナリングの変化が起こる度に１ずつ増加してもよい。

【0295】

ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｐａｒａｍｅｔｅｒｓ＿ｌｅｎｇｔｈフィールドは、当該フィールドに続くｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｐａｒａｍｅｔｅｒｓ（）の長さを示す。

【0296】

ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｐａｒａｍｅｔｅｒｓ（）は、放送伝送システム特性を示すパラメータを含むことができる。パラメータは、帯域幅、ガードインターバル、伝送モード、中心周波数などを含むことができる。

【0297】

本発明の一実施例に係る伝達システムデスクリプタは、前述したネットワーク情報テーブル（ＮＩＴ）に含めて伝送することができる。伝達システムデスクリプタがネットワーク情報テーブルに含まれて伝送される場合に、伝達システムデスクリプタが有するシンタックスについては、ネットワーク情報テーブルに関する説明の部分で前述した。

【0298】

図４４は、本発明の一実施例に係るリンク層パケットのペイロードに入力されたシグナリング情報が、ＤＶＢ−ＧＳＥ標準で用いられるＧＳＥ−ＬＬＣ形態である場合、一つのＧＳＥ−ＬＬＣデータを一つのリンク層パケットのペイロードにカプセル化する過程を示す図である。

【0299】

本発明の一実施例に係るＬＬＣデータは、インデックス（ｉｎｄｅｘ）部分とレコード（ｒｅｃｏｒｄ）部分とに区別可能であり、レコード部分はさらにいくつかのテーブル（ｔａｂｌｅ）に区別可能である。ここで、レコード部分を構成するテーブルの形態は、ＧＳＥテーブル構造を有することができ、一般的なセクションテーブルの構造を有することもできる。

【0300】

同図で、本発明の一実施例に係る一つのＬＬＣデータは一つのリンク層パケットのペイロードになってもよく、この場合、パケットタイプエレメントの示す値は１１０Ｂ（ｓｉｇｎａｌｉｎｇ）とし、シグナリングタイプフィールドの示す値は１１Ｂ（ＧＳＥ−ＬＬＣ）とすることができる。本発明の一実施例に係るＧＳＥ−ＬＬＣ形態のシグナリングを送信する場合、リンク層パケットは、２バイトの拡張ヘッダーを有することができ、上述した２バイトの拡張ヘッダーは、４ビットのＳｅｇ＿ＳＮ（ｓｅｇｍｅｎｔ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）フィールド及び１２ビットの長さ（ｌｅｎｇｔｈ）フィールドから構成することができる。この長さフィールドは、システムの構成によって、リンク層パケット全体の長さを示す値が割り当てられてもよく、リンク層パケットのペイロードのみの長さを示す値が割り当てられてもよい。

【0301】

図４５は、本発明の一実施例に係る、リンク層パケットのペイロードに入力されたシグナリング情報が、ＤＶＢ−ＧＳＥ標準で用いられるＧＳＥ−ＬＬＣ形態である場合に、一つのＧＳＥ−ＬＬＣデータを複数個のリンク層パケットのペイロードにカプセル化する過程を示す図である。

【0302】

本発明の一実施例に係るＬＬＣデータが分割される場合には、同じＬＬＣデータから分割されたことを示すためにＳｅｇ＿ＩＤフィールド値はいずれも同じ値を有することができる。

【0303】

本発明の一実施例に係る受信装置が分割されたＬＬＣデータを受信して順序のとおりに組み替えることができるように、Ｓｅｇ＿ＳＮフィールドには、分割されたセグメントの順序情報が含まれてもよい。一つのＬＬＣデータが一つのリンク層パケットのペイロードに含まれる場合には、Ｓｅｇ＿ＳＮフィールド値を０にすることができる。

【0304】

本発明の一実施例に係る受信装置はＬＬＣインデックス（ｉｎｄｅｘ）部分から、当該Ｓｅｇ＿ＩＤに対するＬＬＣデータが分割されたセグメントの個数を認識できる。

【0305】

図４６は、本発明の一実施例に係るシグナリング情報送信方法を示す図である。

【0306】

本発明の一実施例に係るシグナリング情報送信方法は、シグナリング情報を含むリンク層パケットを生成する段階（Ｓ１７２０１０）、及び／又は生成されたリンク層パケットを送信する段階（Ｓ１７２０２０）を含む。シグナリング情報を含むリンク層パケットを生成する段階（Ｓ１７２０１０）で、リンク層パケットは、固定ヘッダー及びペイロードを含み、シグナリング情報は、放送プログラム及びデータに関する情報と放送プログラム及びデータの受信に必要な情報を含むことができる。そして、シグナリング情報は、リンク層パケットのペイロードに含まれてもよい。上記固定ヘッダーは、本発明の一実施例に係るリンク層パケットのペイロードに含まれたデータの種類を識別するパケットタイプエレメント、及び本発明の一実施例に係るリンク層パケットのペイロードに含まれたシグナリング情報の形態を識別するシグナリングタイプエレメントを含むことができる。送信側は、上述した過程によって生成されたリンク層パケットを伝送する（Ｓ１７２０２０）。上述したリンク層パケット、パケットタイプエレメント及びシグナリングタイプエレメントに関する詳細な説明は、前述した。

【0307】

本発明の他の実施例によれば、上述したシグナリングタイプエレメントによって識別されたシグナリング情報の形態は、セクションテーブルであってもよい。

【0308】

本発明の他の実施例によれば、上述したシグナリングタイプエレメントによって識別されたシグナリング情報の形態は、デスクリプタであってもよい。

【0309】

本発明の他の実施例によれば、上述したシグナリングタイプエレメントによって識別されたシグナリング情報の形態は、ＧＳＥ−ＬＬＣであってもよい。上述したシグナリングタイプエレメントに関する詳細な説明は、前述した。

【0310】

本発明の他の実施例によれば、上述した固定ヘッダーは、一つ以上のデスクリプタが一つのリンク層パケットのペイロードに含まれる場合、一つのリンク層パケットのペイロードに含まれたデスクリプタの個数を示すカウントフィールド（Ｃｏｎｃａｔｅｎａｔｉｏｎ Ｃｏｕｎｔ ｆｉｅｌｄ）を含むことができる。このカウントフィールドに関する詳細な説明は、前述した。

【0311】

本発明の他の実施例によれば、上述した固定ヘッダーは、ＧＳＥ−ＬＬＣデータが一つ以上のセグメントに分割され、一つ以上のセグメントのうち一つのセグメントが一つのリンク層パケットのペイロードに含まれる場合、リンク層パケットのペイロードに含まれたセグメントが属しているＧＳＥ−ＬＬＣデータを識別するセグメント識別エレメントを含むことができる。このセグメント識別エレメントに関する詳細な説明は、前述した。

【0312】

本発明の他の実施例によれば、上述したリンク層パケットは、拡張ヘッダーを含むことができ、この拡張ヘッダーは、上述したＧＳＥ−ＬＬＣデータの組み換えのために必要なリンク層パケットのペイロードに含まれたセグメントの順序情報を示すセグメント順序エレメント、及び／又は上記リンク層パケットの全体長を示すパケット長さエレメントを含むことができる。上記セグメント順序エレメント及びパケット長さエレメントに関する詳細な説明は、前述した。

【0313】

本発明の他の実施例によれば、上述したリンク層パケットの全体長は、リンク層パケットのヘッダー長とリンク層パケットのペイロード長とを合算した値を示し、ペイロードにセクションテーブルが含まれる場合、上述したリンク層パケットのペイロード長は、リンク層パケットのペイロードを構成するセクションテーブルの長さを示すことができる。上述したセクションテーブルの長さは、上記セクションテーブルの開始部分から一定オフセットだけ移動した位置に存在するセクション長フィールドが示す値、上記一定オフセット及び上記セクション長フィールドの長さを合算した値を示すことができる。上述したセクション長フィールドは、上述したセクション長フィールドの直後から当該セクションの最後の部分までの長さを示すことができる。本発明の一実施例に係る上記一定オフセットは、セクションテーブルに含まれたｔａｂｌｅ＿ｉｄフィールド長（８ビット）、ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールド長（１ビット）、Ｓｐｅｃｉｆｉｃ Ｕｓｅフィールド長（１ビット）及びｒｅｓｅｒｖｅｄフィールド長（２ビット）を合算した値である１２ビットであってもよい。上述したリンク層パケットのペイロード長を求める方法に関する詳細な説明は、前述した。

【0314】

本発明の他の実施例によれば、上述したリンク層パケットのペイロードには、迅速なサービススキャン及び取得のためのシグナリング情報を含む高速情報テーブル又は高速情報デスクリプタが含まれてもよい。この高速情報テーブル及び高速情報デスクリプタに関する詳細な説明は、前述した。

【0315】

図４７は本発明の一実施例に係るＲｏＨＣ伝送のためのリンク層パケット（ｌｉｎｋ ｌａｙｅｒ ｐａｃｋｅｔ）のヘッダーを示す図である。

【0316】

ＩＰベースの放送環境でも、ＩＰパケットが前述したリンク層パケットに圧縮されて伝送されてもよい。ＩＰベースの放送システムでストリーミングをする場合に、一般にＩＰパケットのヘッダー情報がほとんど変わらないで維持されてもよい。この点を用いてＩＰパケットのヘッダーを圧縮することができる。

【0317】

ＩＰパケットのヘッダー（＝ＩＰヘッダー）を圧縮する際に、ＲｏＨＣ（（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）技法が主に用いられている。本発明では、ＲｏＨＣパケットがリンク層（ｌｉｎｋ ｌａｙｅｒ）に入力として取り込まれた場合における圧縮（ｅｎｃａｐｓｕｌａｔｉｏｎ）方法を提案する。

【0318】

ＲｏＨＣパケットがリンク層の入力として入る場合、前述したパケットタイプエレメントの値は０１０_Bでよい。これは、前述したように、上位層からリンク層へ伝達されるパケットが圧縮されたＩＰ（ｃｏｍｐｒｅｓｓｅｄ ＩＰ）パケットであることを示す。

【0319】

ＲｏＨＣパケットが入力される場合、リンク層パケットのヘッダーは、前述した他のパケットと同様に、固定ヘッダー（Ｆｉｘｅｄ Ｈｅａｄｅｒ）及び／又は拡張ヘッダー（Ｅｘｔｅｎｄｅｄ Ｈｅａｄｅｒ）を含むことができる。

【0320】

固定ヘッダーは、パケットタイプフィールド及び／又はＰＣ（Ｐａｃｋｅｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）フィールドを含むことができる。固定ヘッダーは、合計１バイトのサイズを有することができる。ここで、パケットタイプフィールドは、圧縮されたＩＰパケットの場合であるから、０１０の値を有することができる。拡張ヘッダーは、実施例によって固定又は可変するサイズを有することができる。

【0321】

固定ヘッダーのＰＣフィールドは、リンク層パケットのペイロードを構成するＲｏＨＣパケットが処理される形態を示すフィールドであってもよい。ＰＣフィールドの値によって、これに続く固定ヘッダーの残り部分及び拡張ヘッダーの情報を決定することができる。また、ＰＣフィールドは、ＲｏＨＣパケットが処理される形態による拡張ヘッダーの長さ情報を内包することができる。ＰＣフィールドは、１ビットのサイズを有することができる。

【0322】

ＰＣフィールドの値が０_Bの場合について説明する。

【0323】

ＰＣフィールドの値が０_Bの場合、リンク層パケットのペイロードが一つのＲｏＨＣパケットで構成されたり、２つ以上のＲｏＨＣパケットで連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）される場合に該当する。連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）は、複数個の短い長さのパケットがつながって、リンク層パケットのペイロードを構成することを意味する。

【0324】

ＰＣフィールドの値が０_Bの場合、ＰＣフィールドの次に１ビットのＣＩ（Ｃｏｍｍｏｎ ＣＩＤ Ｉｎｄｉｃａｔｏｒ）フィールドと３ビットのカウントフィールドが続いてもよい。このため、拡張ヘッダーに共通ＣＩＤ情報と長さパート（ｌｅｎｇｔｈ ｐａｒｔ）が追加されてもよい。長さパートは、ＲｏＨＣパケットの長さを表示するパートであってもよい。

【0325】

ＣＩ（Ｃｏｍｍｏｎ Ｃｏｎｔｅｘｔ ＩＤ Ｉｎｄｉｃａｔｏｒ）フィールドは、一つのリンク層パケットのペイロードを構成するＲｏＨＣパケットのＣＩＤ（Ｃｏｎｔｅｘｔ ＩＤ）がすべて同一である場合、１に設定され、そうでない場合には０に設定されてもよい。ＣＩ値が１である場合、共通したＣＩＤに対するオーバーヘッド処理方法を適用することができる。ＣＩフィールドは１ビットであってもよい。

【0326】

カウントフィールドは、一つのリンク層パケットのペイロードにいくつのＲｏＨＣパケットが含まれているかを示すことができる。すなわち、連結の場合において、連結されているＲｏＨＣパケットの個数をカウントフィールドが示すことができる。カウントフィールドは３ビットであってもよい。したがって、次の表のように、最大８個のＲｏＨＣパケットが一つのリンク層パケットのペイロードに含まれてもよい。カウントフィールドが０００の値を有する場合、ＲｏＨＣパケットが連結されず、一つのＲｏＨＣパケットがリンク層パケットのペイロードを構成することを意味できる。

【表1】

【0327】

長さパート（Ｌｅｎｇｔｈ ｐａｒｔ）は、前述したように、ＲｏＨＣパケットの長さを表示するパートであってもよい。ＲｏＨＣパケットの場合、ＲｏＨＣパケットヘッダーに長さ情報が除去されて入力される。このため、ＲｏＨＣパケットヘッダー内の長さフィールドを活用することができない。したがって、受信機に当該ＲｏＨＣパケットの長さを知らせるために、リンク層パケットのヘッダーは長さパートを含むことができる。

【0328】

ＩＰパケットは、ＭＴＵが決定されていない場合、最大６５５３５バイト長を有する。したがって、ＲｏＨＣパケットに対しても最大長さまで支援できるように２バイトの長さ情報が必要である。また、複数のＲｏＨＣパケットが連結された場合、カウントフィールドで指定した数だけ、長さフィールドが追加されてもよい。この場合、長さパートは、複数個の長さフィールドを含むようになる。ただし、１個のＲｏＨＣパケットがペイロードに含まれる場合には、１つの長さフィールドのみが含まれてもよい。長さフィールドの配置は、リンク層パケットのペイロードを構成するＲｏＨＣパケットの順序と同一にすることができる。それぞれの長さフィールドはバイト単位の値を有することができる。

【0329】

共通ＣＩＤ（Ｃｏｍｍｏｎ ＣＩＤ）フィールドは、共通するＣＩＤを送信するフィールドであってもよい。ＲｏＨＣパケットのヘッダー部分には、圧縮されたヘッダー間の関係を確認するためのＣＩＤ（ｃｏｎｔｅｘｔ ＩＤ）が含まれてもよい。このＣＩＤは、安定したリンク（ｌｉｎｋ）状態では同一値に維持可能である。このため、一つのリンク層パケットのペイロードに含まれるＲｏＨＣパケットがいずれも同一ＣＩＤを含んでもよい。の場合、オーバーヘッドを減らすために、連結されたペイロードを構成するＲｏＨＣパケットのヘッダー部分からＣＩＤを除去し、リンク層パケットのヘッダーにおいて共通ＣＩＤフィールドにその値を表示して伝送してもよい。受信機では、共通ＣＩＤフィールドを用いてＲｏＨＣパケットのＣＩＤを組み換えることができる。共通ＣＩＤフィールドがある場合、前述したＣＩフィールドの値は１にならなければならない。

【0330】

ＰＣフィールドの値が１_Bの場合について説明する。

【0331】

ＰＣフィールドの値が１_Bの場合、リンク層パケットのペイロードがＲｏＨＣパケットの分割された（ｓｅｇｍｅｎｔｅｄ）パケットで構成される場合に該当する。ここで、分割されたパケットとは、長い長さのＲｏＨＣパケットを複数個のセグメントに分け、そのうち一つのセグメントがリンク層パケットのペイロードを構成することを意味できる。

【0332】

ＰＣフィールドの値が１_Bの場合、ＰＣフィールドの次に１ビットのＬＩ（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｉｎｄｉｃａｔｏｒ）フィールドと３ビットのセグメントＩＤフィールドが続くことができる。また、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）に関する情報を追加するために、拡張ヘッダーに、セグメントシーケンスナンバー（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）フィールド、セグメント長ＩＤ（Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ ＩＤ）フィールド、最後のセグメント長（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ）フィールドなどを追加することができる。

【0333】

ＬＩ（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｉｎｄｉｃａｔｏｒ）フィールドは、ＲｏＨＣパケットが分割される場合において活用可能なフィールドである。ＲｏＨＣパケットが複数個のセグメントに分割されてもよい。ＬＩ値が１の場合、現在リンク層パケットに含まれているセグメントが、一つのＲｏＨＣパケットから分けられたセグメントのうち、最後に位置したセグメントであることを意味することができる。ＬＩ値が０の場合、現在リンク層パケットに含まれているセグメントが、最後のセグメントでないことを意味できる。ＬＩフィールドは、受信機でセグメントを集めて一つのＲｏＨＣパケットとして再構成する際、全てのセグメントが受信されたかを判断するために用いることができる。ＬＩフィールドは１ビットであってもよい。

【0334】

セグメントＩＤ（Ｓｅｇ＿ＩＤ）フィールドは、ＲｏＨＣパケットが分割される場合において、ＲｏＨＣパケットに与えられるＩＤを示すことができる。一つのＲｏＨＣパケットから分離されたセグメントはいずれも同一値のセグメントＩＤを有することができる。受信機は、それぞれ伝送されたセグメントを一つに合わせる際、セグメントＩＤから、同じＲｏＨＣパケットの構成要素であるか否かを判断できる。セグメントＩＤフィールドは３ビットであってもよい。したがって、同時に８個のＲｏＨＣパケットの分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を支援することができる。

【0335】

セグメントシーケンスナンバー（Ｓｅｇ＿ＳＮ）フィールドは、ＲｏＨＣパケットが分割されたとき、各セグメントの順序を確認するために用いることができる。すなわち、一つのＲｏＨＣパケットから分離されたセグメントをペイロードとして有するリンク層パケットは、同じＳｅｇ＿ＩＤを有するが、異なるＳｅｇ＿ＳＮを有することができる。Ｓｅｇ＿ＳＮは４ビットであってもよい。このため、一つのＲｏＨＣパケットは最大１６個のセグメントに分割可能である。

【0336】

セグメント長ＩＤ（Ｓｅｇ＿Ｌｅｎ＿ＩＤ）フィールドは、各セグメントの長さを示すことができる。ただし、セグメント長ＩＤフィールドは、複数個のセグメントのうち、最後のセグメント以外のセグメントの長さを表現するために用いることができる。最後のセグメントの長さは、後述する最後のセグメント長フィールドで示すことができる。リンク層パケットのペイロードが、ＲｏＨＣパケットの最後のセグメントでない場合、すなわち、ＬＩの値が０である場合に、セグメント長ＩＤフィールドが存在できる。

【0337】

ヘッダーのオーバーヘッドを減らすために、セグメントが有し得る長さは１６個に制限されてもよい。物理層で処理するＦＥＣのコードレート（ｃｏｄｅ ｒａｔｅ）によってパケットの入力サイズが決定されていてもよい。これに基づいてセグメントの長さを決定して、Ｓｅｇ＿Ｌｅｎ＿ＩＤとして指定することができる。セグメントの長さとは無関係に物理層が動作する場合、次のようにセグメントの長さを決定することができる。

【数1】

【0338】

ここで、Ｌｅｎ＿Ｕｎｉｔ（Ｌｅｎｇｔｈ Ｕｎｉｔ）は、セグメントの長さを表示する基本単位であり、ｍｉｎ＿Ｌｅｎは、セグメント長の最小値を意味できる。Ｌｅｎ＿Ｕｎｉｔとｍｉｎ＿Ｌｅｎは、送信機と受信機において同じ値を有するべきであり、一度決定されると変わらない方が、システムの運用に効率的である。また、Ｌｅｎ＿Ｕｎｉｔとｍｉｎ＿Ｌｅｎは、システムの初期化過程で物理層のＦＥＣの処理能力を考慮して決定することができる。

【0339】

次の表は、Ｓｅｇ＿Ｌｅｎ＿ＩＤの値によって表現されるセグメントの長さを整理したものであり、Ｓｅｇ＿Ｌｅｎ＿ＩＤに割り当てられた長さは一実施例であり、設計者の意図によって変更されてもよい。この実施例では、Ｌｅｎ＿Ｕｎｉｔ値は２５６、ｍｉｎ＿Ｌｅｎ値は５１２である。

【表2】

【0340】

最後のセグメント長（Ｌ＿Ｓｅｇ＿Ｌｅｎ）フィールドは、リンク層パケットのペイロードに含まれたセグメントが、ＲｏＨＣパケットの最後のセグメントである場合に用いられるフィールドである。すなわち、ＬＩフィールド値が１の場合に活用されるフィールドである。ＲｏＨＣパケットをＳｅｇ＿Ｌｅｎ＿ＩＤを用いて前部から同じサイズに分割することができる。しかし、この場合、最後のセグメントはＳｅｇ＿Ｌｅｎ＿ＩＤが示すサイズに分割されない場合がある。したがって、最後のセグメントの長さは、Ｌ＿Ｓｅｇ＿Ｌｅｎフィールドによって直接表示されてもよい。Ｌ＿Ｓｅｇ＿Ｌｅｎ フィールドは、１〜４０９５バイトを表示できる。これは実施例によって変更されてもよい。

【0341】

図４８は、本発明に係る、リンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃１を示す図である。

【0342】

本実施例は、ＲｏＨＣパケットが物理層の処理範囲内にあることから、一つのＲｏＨＣパケットがリンク層パケットのペイロードを構成する場合に該当する。この場合、ＲｏＨＣパケットは、連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）又はセグメンテーション（ｓｅｇｍａｎｔａｔｉｏｎ）されなくてもよい。

【0343】

この場合、一つのＲｏＨＣパケットがそのままリンク層パケットのペイロードになってもよい。パケットタイプの値は０１０_Bになり、ＰＣフィールドの値は０_B，ＣＩフィールド値は０_Bでよい。前述したカウントフィールドの場合、一つのＲｏＨＣパケットがそのままペイロードを構成するので（１個）、前述したように０００_Bの値を有することができる。次に、ＲｏＨＣパケットの長さを示す２バイトの長さフィールドが続いてもよい。この場合、一つのパケットのみがペイロードを構成するので、長さパートは一つの長さフィールドのみを含むことができる。

【0344】

この実施例で、総３バイトのリンク層ヘッダーが追加されている。したがって、長さフィールドが示すＲｏＨＣパケットの長さがＬバイトであるとすれば、リンク層パケットの全体長さはＬ＋３バイトとなる。

【0345】

図４９は、本発明に係る、リンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃２を示す図である。

【0346】

本実施例は、ＲｏＨＣパケットが物理層の処理範囲内に到達しないことから、複数個のＲｏＨＣパケットが連結されてリンク層パケットのペイロードに含まれるケースに該当する（連結）。

【0347】

この場合、ＰＣフィールド及びＣＩフィールドの値は、一つのＲｏＨＣパケットがペイロードに含まれる場合と同一である。その次にカウントフィールドがつながる。カウントフィールドは、前述したように、いくつのＲｏＨＣパケットがペイロードに含まれているかによって００１_B〜１１１_Bの値を有することができる。

【0348】

続いて、各２バイトの長さを有する長さフィールドが、カウントフィールドが示す個数だけ位置することができる。各長さフィールドは、各ＲｏＨＣパケットの長さを示すことができる。この長さフィールド（Ｌｅｎｇｔｈ ｆｉｅｌｄ）を長さパート（Ｌｅｎｇｔｈ ｐａｒｔ）と呼ぶことができる。

【0349】

ここで、カウントフィールドが示す値がｎ個であるとすれば、リンク層パケットのペイロードには、それぞれＬ₁，Ｌ₂，…，Ｌ_nの長さを有するＲｏＨＣパケットＲ₁，Ｒ₂，…，Ｒ_nが連結されていてもよい。

【0350】

総拡張ヘッダーは２ｎバイトの長さを有することができる。リンク層パケットの全体長Ｌ_Tは、次の式のように表現することができる。

【数2】

【0351】

図５０は、本発明に係る、リンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃３を示す図である。

【0352】

本実施例は、複数個のＲｏＨＣパケットが連結されてリンク層パケットのペイロードを構成する場合（連結）において、連結されたＲｏＨＣパケットが同じＣＩＤ（Ｃｏｎｔｅｘｔ ＩＤ）を有する場合に該当する。

【0353】

ＲｏＨＣパケットが同じＣＩＤを有する場合、ＣＩＤを一度だけ表記して伝送しても、受信機では元来のままＲｏＨＣパケット及びそのヘッダーを復元することができる。したがって、ＲｏＨＣパケットで共通するＣＩＤを抽出して一度だけ送信することが可能であり、これによって、オーバーヘッドを減らすことができる。

【0354】

この場合、前述したＣＩフィールドの値は１になる。これは、同じＣＩＤに対する処理がなされたことを意味できる。同じＣＩＤを有するＲｏＨＣパケットを、［Ｒ₁，Ｒ₂，Ｒ₃，…，Ｒ_n］と表示した。共通するＣＩＤは、共通ＣＩＤ（Ｃｏｍｍｏｎ ＣＩＤ）と呼ぶことができる。ＲｏＨＣパケットのヘッダーにおいてＣＩＤを除いたパケットをＲ’_kと表示した（ｋは、１，２，．．．，ｎ）。

【0355】

リンク層パケットのペイロードは、Ｒ’_k（ｋは、１，２，．．．，ｎ）を含むことができる。リンク層パケットの拡張ヘッダーの末尾部分には共通ＣＩＤフィールドが追加されてもよい。共通ＣＩＤフィールドは、共通するＣＩＤを示すことができる。共通ＣＩＤフィールドは、拡張ヘッダーの一部として伝送されてもよく、リンク層パケットのペイロードの一部として伝送されてもよい。システムの運用に応じて、共通ＣＩＤフィールドの位置を確認できる部分に適宜再配置することが可能である。

【0356】

共通ＣＩＤフィールドのサイズは、ＲｏＨＣパケットの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）によって可変してもよい。

【0357】

ＲｏＨＣパケットの構成がスモールＣＩＤ構成（Ｓｍａｌｌ ＣＩＤ ｃｏｎｆｉｇｕｒａｔｉｏｎ）である場合、ＲｏＨＣパケットのＣＩＤのサイズは、４ビットの長さを有することができる。ただし、ＲｏＨＣパケットからＣＩＤを抽出して再配置する場合には、ａｄｄ−ＣＩＤオクテット全体が処理されてもよい。すなわち、共通ＣＩＤフィールドが１バイトの長さを有することができる。又は、ＲｏＨＣパケットから１バイトのａｄｄ−ＣＩＤオクテットを抽出した後、４ビットのＣＩＤのみを共通ＣＩＤフィールドに割り当て、余り４ビットは、後に活用するために残してもよい。

【0358】

ＲｏＨＣパケットの構成がラージＣＩＤ構成（Ｌａｒｇｅ ＣＩＤ ｃｏｎｆｉｇｕｒａｔｉｏｎ）である場合、ＲｏＨＣパケットのＣＩＤサイズは、１バイト又は２バイトの長さを有することができる。ＣＩＤのサイズは、ＲｏＨＣ初期化過程で決定される。ＣＩＤのサイズによって、共通ＣＩＤフィールドは１バイト又は２バイトの長さを有することができる。

【0359】

本実施例で、リンク層パケットのペイロードの長さは、次のように計算することができる。同じＣＩＤを有するｎ個のＲｏＨＣパケットＲ₁，Ｒ₂，…，Ｒ_nの長さをそれぞれＬ₁，Ｌ₂，…，Ｌ_nとすることができる。リンク層パケットのヘッダーの長さをＬ_H、共通ＣＩＤフィールドの長さをＬ_CID、リンク層パケットの全体長をＬ_Tとすれば、Ｌ_Hは、次のとおりである。

【数3】

【0360】

また、Ｌ_Tは、次のように計算することができる。

【数4】

【0361】

前述したように、Ｌ_CIDは、ＲｏＨＣのＣＩＤ構成によって決定することができる。すなわち、Ｌ_CIDは、スモールＣＩＤ構成の場合に１バイト、ラージＣＩＤ構成の場合には１バイト又は２バイトとすることができる。

【0362】

図５１は、本発明に係る、リンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃４を示す図である。

【0363】

本実施例は、入力されたＲｏＨＣパケットが物理層の処理範囲を超える場合（ｓｅｇｍｅｎｔａｔｉｏｎ）において、分離されたセグメントがそれぞれリンク層パケットのペイロードに圧縮（ｅｎｃａｐｓｕｌａｔｉｏｎ）される場合に該当する。

【0364】

リンク層パケットのペイロードが分割されたＲｏＨＣパケットで構成されたことを知らせるために、ＰＣフィールドの値は１_Bになる。ＬＩフィールドは、ＲｏＨＣパケットの最後の部分に該当するセグメントをペイロードとして有する場合にのみ１_Bになり、余りの全てのセグメントに対しては０_Bになる。ＬＩフィールドの値は、リンク層パケットの拡張ヘッダーに関する情報を知らせることもできる。すなわち、ＬＩフィールドの値が０_Bの場合には１バイト、１_Bの場合は２バイト長の拡張ヘッダーが追加されてもよい。

【0365】

同じＲｏＨＣパケットから分割されたことを示すために、Ｓｅｇ＿ＩＤ値はいずれも同じ値を有することができる。受信機における正常なＲｏＨＣパケット組み換えのためのセグメントの順序情報を示すために、順次に増加するＳｅｇ＿ＳＮ値がヘッダーに記録されてもよい。

【0366】

ＲｏＨＣパケットを分割する際、前述したように、セグメントの長さを決めて分割を行うことができる。その長さに合うＳｅｇ＿Ｌｅｎ＿ＩＤ値がヘッダーに記録されてもよい。最後のセグメントの長さは、前述したように、１２ビットのＬ＿Ｓｅｇ＿Ｌｅｎフィールドに直接記録されてもよい。

【0367】

Ｓｅｇ＿Ｌｅｎ＿ＩＤ、Ｌ＿Ｓｅｇ＿Ｌｅｎフィールドを用いて表示する長さ情報は、セグメント、すなわち、リンク層パケットのペイロードに関する情報のみを表示する。このため、全体リンク層パケットの長さ情報は、ＬＩフィールドから読み取れるリンク層パケットのヘッダー長を足して計算することができる。

【0368】

受信側でＲｏＨＣパケットのセグメントを組み換える過程で、組み換えられたＲｏＨＣパケットの完全性を確認する必要がある。そのために、分割過程でＩＰパケットに続いてＣＲＣが追加されてもよい。一般に、ＣＲＣは、ＲｏＨＣパケットの最後に追加されるので、分割過程の後に最後のセグメントにＣＲＣを含めることができる。

【0369】

図５２は、ＭＴＵが１５００である場合において、本発明の一実施例に係るＲｏＨＣ伝送のためのリンク層パケットのヘッダーを示す図である。

【0370】

一般に、ビデオ及びオーディオストリーミング時に、ＲｏＨＣ技法を適用することができる。このとき、ＩＰパケットのＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ:最大伝送単位）を１５００バイトに設定することができる。これは、ＲｏＨＣパケットも１５００バイトよりは小さい長さを有するということを意味する。

【0371】

前述したように、固定ヘッダーのＰＣフィールドは、リンク層パケットのペイロードを構成するＲｏＨＣパケットが処理される形態を示すことができる。ＰＣフィールドの値によって、これに続く固定ヘッダーの残り部分及び拡張ヘッダーの情報を決定することができる。また、ＰＣフィールドは、ＲｏＨＣパケットが処理される形態による拡張ヘッダーの長さ情報を内包することができる。ＰＣフィールドは、１ビットのサイズを有することができる。

【0372】

ＰＣフィールドの値が０_Bの場合について説明する。

【0373】

ＰＣフィールドの値が０_Bの場合、リンク層パケットのペイロードが一つのＲｏＨＣパケットで構成されたり、ＲｏＨＣパケットの分割された（ｓｅｇｍｅｎｔｅｄ）パケットで構成される場合に該当する。ＰＣフィールドにＳＩフィールドが続いている。ＳＩ（Ｓｅｇｍｅｎｔ Ｉｎｄｉｃａｔｏｒ）フィールドは、リンク層パケットのペイロードが一つのＲｏＨＣパケットで構成されたか、又はＲｏＨＣパケットのセグメントで構成されたかを示すことができる。このＳＩフィールド値によって、固定ヘッダー及び拡張ヘッダー部分のフィールドを決定することができる。

【0374】

ＳＩフィールドは、前述したように、リンク層パケットのペイロードが一つのＲｏＨＣパケットで構成されたか、又はＲｏＨＣパケットのセグメントで構成されたかを示すことができる。０の場合、一つのＲｏＨＣパケットで構成されたことを意味し、１の場合は、ＲｏＨＣパケットのセグメントで構成されたことを意味できる。ＳＩフィールドは、１バイトの長さを有することができる。

【0375】

セグメントＩＤ（Ｓｅｇ＿ＩＤ）フィールドは、ＲｏＨＣパケットが分割される場合において、ＲｏＨＣパケットに与えられるＩＤを示すことができる。これは、前述したＳｅｇ＿ＩＤフィールドと同一である。

【0376】

セグメントシーケンスナンバー（Ｓｅｇ＿ＳＮ）フィールドは、ＲｏＨＣパケットが分割されたとき、各セグメントの順序を確認するために用いることができる。これは、前述したＳｅｇ＿ＳＮフィールドと同一である。

【0377】

ＬＩ（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｉｎｄｉｃａｔｏｒ）フィールドは、ＲｏＨＣパケットが分割されたとき、現在リンク層パケットに含まれているセグメントが、ＲｏＨＣパケットから分割されたセグメントのうち、最後に位置したセグメントであるか否かを示すことができる。これは、前述したＬＩフィールドと同一である。

【0378】

セグメント長ＩＤ（Ｓｅｇ＿Ｌｅｎ＿ＩＤ）フィールドは、各セグメントの長さを表現するために用いることができる。これは、前述したＳｅｇ＿Ｌｅｎ＿ＩＤフィールドと同一である。ただし、前述とは違い、セグメントが有し得る長さを、１６個ではなく８個に制限することができる。この場合、Ｓｅｇ＿Ｌｅｎ＿ＩＤの値によって表現されるセグメントの長さは、次の表のように整理できる。Ｓｅｇ＿Ｌｅｎ＿ＩＤに割り当てられた長さは一実施例であり、設計者の意図によって変更されてもよい。この実施例では、Ｌｅｎ＿Ｕｎｉｔ値は６４、ｍｉｎ＿Ｌｅｎ値は２５６である。

【表3】

【0379】

最後のセグメント長（Ｌ＿Ｓｅｇ＿Ｌｅｎ）フィールドは、最後のセグメントの長さを表現するために用いることができる。これは、前述したＬ＿Ｓｅｇ＿Ｌｅｎフィールドと同一である。ただし、前述した場合とは違い、Ｌ＿Ｓｅｇ＿Ｌｅｎフィールドは１〜２０４８バイトを表示できる。これは実施例によって変更されてもよい。

【0380】

ＰＣフィールドの値が１_Bの場合について説明する。

【0381】

ＰＣフィールドの値が１_Bの場合、

【0382】

リンク層パケットのペイロードが２つ以上のＲｏＨＣパケットが連結される場合に該当する。ＰＣフィールドに１ビットのＣＩ（Ｃｏｍｍｏｎ ＣＩＤ Ｉｎｄｉｃａｔｏｒ）フィールドと３ビットのカウントフィールドが続いている。これによって、拡張ヘッダーに共通ＣＩＤ情報と長さパート（ｌｅｎｇｔｈ ｐａｒｔ）を追加することができる。

【0383】

ＣＩ（Ｃｏｍｍｏｎ Ｃｏｎｔｅｘｔ ＩＤ Ｉｎｄｉｃａｔｏｒ）フィールドは、一つのリンク層パケットのペイロードを構成するＲｏＨＣパケットのＣＩＤ（Ｃｏｎｔｅｘｔ ＩＤ）がすべて同一であるか否かを示すフィールドである。これは、前述したＣＩフィールドと同一である。

【0384】

カウントフィールドは、一つのリンク層パケットのペイロードにいくつのＲｏＨＣパケットが含まれているかを示すことができる。前述したカウントフィールドとは違い、０００値は２個のＲｏＨＣパケットが連結されていることを意味することができる。カウントフィールド値が１１１の場合、９個以上のＲｏＨＣパケットが連結されたことを示すことができる。これを整理すると、次の表のとおりとなる。

【表4】

【0385】

長さパート（Ｌｅｎｇｔｈ ｐａｒｔ）は、ＲｏＨＣパケットの長さを示すことができる。長さパートは、前述したように、複数個の長さフィールドを含むことができる。各長さフィールドは、各ＲｏＨＣパケットの長さを示すことができる。

【0386】

この実施例で、ＭＴＵは１５００バイトであるから、長さフィールドには、これを表示するための最小のビット数である１１ビットを割り当てることができる。１１ビットで２０４８バイトまで表示できるので、後で、必要時にＭＴＵが２０４８バイトまで拡張される場合にも、本発明で提示する方法を用いることができる。長さフィールドは、長さを直接表示してもよく、別の値をマッピングして長さを表示してもよい。前述したように、カウントフィールドで指定した数だけ長さフィールドを追加することができる。

【0387】

拡張長さパート（Ｅｘｔｅｎｄｅｄ Ｌｅｎｇｔｈ Ｐａｒｔ）は、連結されたＲｏＨＣパケットの個数が９個又はそれ以上である場合に、９番目の以降のＲｏＨＣパケットの長さを表示するために用いることができる。すなわち、カウントフィールド値が１１１_Bの場合に活用することができる。拡張長さパートは、１１ビットの長さフィールドと１ビットのＸフィールドを含むことができる。これら両フィールドは交互に位置すればよい。

【0388】

共通ＣＩＤ（Ｃｏｍｍｏｎ ＣＩＤ）フィールドは、共通するＣＩＤを伝送することができる。これは、前述した共通ＣＩＤフィールドと同一であってもよい。

【0389】

図５３は、本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃１を示す図である。

【0390】

本実施例は、ＭＴＵが１５００である場合において、ＰＣフィールドは１であり、カウント値は１１１_Bでない場合に該当し得る。

【0391】

この場合、長さパートは、前述したように、カウントフィールド値が指定する個数だけの長さフィールドを有することができる。一つの長さフィールドは１１ビットであるから、長さフィールドの個数によって、パディングビットが追加されてもよい。すなわち、カウントフィールドが指定する個数の値がｋ、一つの長さフィールドサイズをｓ（ｂｉｔ）とすれば、全体長さパートの長さＬ_LPは、次のように計算することができる。

【数5】

【0392】

また、長さパートに追加されるパディングビットのサイズは、次のように計算することができる。

【数6】

【0393】

前述したように、長さフィールドの長さｓは１１ビットでよい。これを用いて長さパート、パディングビットのサイズを整理すると、次のとおりである。

【表5】

【0394】

図５４は、本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃２を示す図である。

【0395】

本実施例は、ＭＴＵが１５００である場合において、ＰＣフィールドは１であり、カウント値は１１１_Bである場合に該当し得る。この場合、前述したように、拡張長さパートを追加することができる。

【0396】

この場合、拡張長さパートの前に位置する長さパートは、１１ビットの長さフィールドを８個含むので、総１１バイトの長さを有することができる。カウント値が１１１であるので、拡張長さパートには少なくとも一つの長さフィールドが存在しなければならない。

【0397】

拡張長さパートは、前述したように、１１ビットの長さフィールドと１ビットのＸフィールドを含むことができる。これら両フィールドは交互に位置すればよい。拡張長さパートの長さフィールドは、長さパートの長さフィールドと同一に運用されてもよい。

【0398】

Ｘフィールドは、次に長さフィールドがさらに続くか否かを示すことができる。Ｘフィールドの値が０の場合、それ以上の長さフィールドが追加されないことを意味できる。Ｘフィールドの値が１の場合、少なくとも一つの長さフィールドとＸフィールドが続くことを意味することができる。したがって、Ｘフィールドの値が０になるまで拡張長さパートは増加し続く。Ｘフィールドの個数だけペイロードに位置するＲｏＨＣパケットの個数も追加されることがわかる。

【0399】

拡張長さパートにおいて、１の値を有するＸフィールドの個数をｍとし、一つの長さフィールドのサイズをｓ（ｂｉｔ）とすれば、拡張長さパートの長さＬ_ELPを次のように計算することができる。

【数7】

【0400】

拡張長さパートも、バイト単位の処理のためにパディングビットを有することができる。拡張長さパートに追加されるパディングビットのサイズは、次のように計算することができる。

【数8】

【0401】

長さフィールドの個数が奇数の場合には４ビットのパディングビットが追加され、偶数の場合にはパディングビットは追加されなくてもよい。

【0402】

図５５は、本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃３を示す図である。

【0403】

本実施例は、ＭＴＵが１５００である場合において、ＲｏＨＣパケットが物理層の処理範囲内にあることから、一つのＲｏＨＣパケットがリンク層パケットのペイロードを構成する場合に該当する。

【0404】

この場合、一つのＲｏＨＣパケットをそのままリンク層パケットのペイロードとすることができる。パケットタイプの値は０１０_B、ＰＣフィールドの値は０_B、ＳＩフィールド値は０_Bとすることができる。前述した長さパートが続いてもよい。ここで、長さパートは、一つの長さフィールドを有することができる。長さフィールドは１１ビットであってもよい。この１１ビットのために、固定ヘッダーの３ビットと拡張ヘッダーの１バイトを一つの長さフィールドのために用いることができる。

【0405】

この場合、総２バイトのリンク層ヘッダーが追加される。したがって、長さフィールドが示すＲｏＨＣパケットの長さがＬバイトであるとすれば、総リンク層パケットの長さはＬ＋２バイトとなる。

【0406】

図５６は、本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃４を示す図である。

【0407】

本実施例は、ＭＴＵが１５００である場合において、入力されたＲｏＨＣパケットが物理層の処理範囲を超える場合（ｓｅｇｍｅｎｔａｔｉｏｎ）において、分離されたセグメントがそれぞれリンク層パケットのペイロードに圧縮（ｅｎｃａｐｓｕｌａｔｉｏｎ）される場合に該当する。

【0408】

分割されたことを示すためにＳＩフィールド値を１とすることができる。

【0409】

前述したように、Ｓｅｇ＿ＩＤ値は、いずれも同じ値を有しなければならず、Ｓｅｇ＿ＳＮ値は順次に増加する値を有しなければならない。ＬＩフィールドは、最後のセグメントである場合にのみ１の値を有し、その他の場合は０の値を有することができる。また、Ｓｅｇ＿Ｌｅｎ＿ＩＤ、Ｌ＿Ｓｅｇ＿Ｌｅｎフィールドを用いて各セグメントの長さを表示することができる。詳細な長さ表示方法は、前述したとおりである。

【0410】

全体リンク層パケットの長さ情報は、ＬＩフィールドから読み取れるリンク層パケットのヘッダー長を足すことによって計算することができる。また、受信側でＲｏＨＣパケットのセグメントを組み換える過程における完全性を確認するために、ＣＲＣが追加されてもよい。このＣＲＣは、最後のセグメントに追加することができる。

【0411】

図５７は、本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃５を示す図である。

【0412】

本実施例は、ＭＴＵが１５００である場合において、ＲｏＨＣパケットが物理層の処理範囲内に到達しておらず、複数個のＲｏＨＣパケットが連結されてリンク層パケットのペイロードに含まれるケースに該当する（連結）。

【0413】

本実施例は、ＲｏＨＣパケットが８個以下に連結された場合に該当してもよい。この場合、拡張長さパートは省かれてもよい。ＰＣフィールド値は１、ＣＩフィールド値は０となっている。カウントフィールドの値は、前述したように、０００_B〜１１０_Bを有することができる。

【0414】

ここで、カウントフィールドの示す値をｎ個とすれば、リンク層パケットのペイロードには、それぞれＬ₁，Ｌ₂，…，Ｌ_nの長さを有するＲｏＨＣパケットＲ₁，Ｒ₂，…，Ｒ_nが連結されていてもよい。各長さフィールドは、１１ビットの長さを有することができる。必要な場合、長さフィールドにパディングビットが続いてもよい。

【0415】

全体リンク層パケットの長さＬ_Tは、次のとおりである。

【数9】

【0416】

ここで、Ｌ_LPは、全体長さパートの長さを表し、Ｌ_kは、各ＲｏＨＣパケットの長さを表す。

【0417】

図５８は、本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃６を示す図である。

【0418】

本実施例は、ＭＴＵが１５００である場合において、ＲｏＨＣパケットが物理層の処理範囲内に到達されておらず、複数個のＲｏＨＣパケットが連結されてリンク層パケットのペイロードに含まれる場合に該当する（連結）。

【0419】

ただし、本実施例は、ＲｏＨＣパケットが９個以上連結された場合に該当し得る。この場合、長さパートの他、拡張長さパートも必要となる。前述したように、カウントフィールドは１１１の値を有することができる。

【0420】

拡張長さパートにおいて、１の値を有するＸフィールドの個数をｍとすれば、リンク層パケットのペイロードに連結されるＲｏＨＣパケットの個数ｎは、８＋（ｍ＋１）となる。このとき、全体リンク層パケットの長さＬ_Tは、次のとおりである。

【数10】

【0421】

ここで、Ｌ_LPは、全体長さパートの長さを表し、Ｌ_kは、各ＲｏＨＣパケットの長さを表す。ここで、Ｌ_ELPは、全体拡張長さパートの長さを表す。

【0422】

図５９は本発明に係る、ＭＴＵが１５００である場合におけるリンク層パケットを用いたＲｏＨＣパケット伝送方法の実施例＃７を示す図である。

【0423】

本実施例は、ＭＴＵが１５００である場合において、複数個のＲｏＨＣパケットが連結されてリンク層パケットのペイロードを構成する場合（連結）に該当し得る。ただし、本実施例は、連結されたＲｏＨＣパケットが同じＣＩＤ（Ｃｏｎｔｅｘｔ ＩＤ）を有する場合に該当する。

【0424】

この場合、前述したＣＩフィールドの値は１になる。これは、同じＣＩＤに対する処理がなされたということを意味できる。同じＣＩＤを有するＲｏＨＣパケットを［Ｒ₁，Ｒ₂，Ｒ₃，…，Ｒ_n］と表示した。共通するＣＩＤは、共通ＣＩＤ（Ｃｏｍｍｏｎ ＣＩＤ）と呼ぶことができる。ＲｏＨＣパケットのヘッダーにおいてＣＩＤを除くパケットをＲ’_kと表示した（ｋは、１，２，．．．，ｎ）。

【0425】

リンク層パケットのペイロードは、Ｒ’_k（ｋは、１，２，．．．，ｎ）を含むことができる。リンク層パケットの拡張ヘッダーの末尾部分には共通ＣＩＤフィールドが追加されてもよい。共通ＣＩＤフィールドは、共通するＣＩＤを伝送することができる。共通ＣＩＤフィールドは、拡張ヘッダーの一部として伝送されてもよく、リンク層パケットのペイロードの一部として伝送されてもよい。システムの運用によって、共通ＣＩＤフィールドの位置を確認できる部分に適宜再配置することが可能である。

【0426】

共通ＣＩＤフィールドのサイズは、ＲｏＨＣパケットの構成によって可変してもよい。

【0427】

ＲｏＨＣパケットの構成がスモールＣＩＤ構成（Ｓｍａｌｌ ＣＩＤ ｃｏｎｆｉｇｕｒａｔｉｏｎ）である場合、ＲｏＨＣパケットのＣＩＤサイズは４ビットの値を有することができる。ただし、ＲｏＨＣパケットからＣＩＤを抽出して再配置する場合には、ａｄｄ−ＣＩＤオクテット全体が処理されてもよい。すなわち、共通ＣＩＤフィールドが１バイトの長さを有することができる。又は、ＲｏＨＣパケットから１バイトのａｄｄ−ＣＩＤオクテットを抽出した後、４ビットのＣＩＤのみを共通ＣＩＤフィールドに割り当て、余り４ビットは後に活用するために残すこともできる。

【0428】

ＲｏＨＣパケットの構成がラージＣＩＤ構成（Ｌａｒｇｅ ＣＩＤ ｃｏｎｆｉｇｕｒａｔｉｏｎ）である場合、ＲｏＨＣパケットのＣＩＤサイズは、１バイト又は２バイト長を有することができる。ＣＩＤのサイズは、ＲｏＨＣ初期化過程で決定される。ＣＩＤのサイズによって、共通ＣＩＤフィールドは１バイト又は２バイトの長さを有することができる。

【0429】

この場合、リンク層パケットの全体長Ｌ_Tは、次のように計算することができる。

【数11】

【0430】

ここで、Ｌ_CIDは、共通ＣＩＤフィールドの長さを意味できる。前述したように、Ｌ_CIDは、ＲｏＨＣのＣＩＤ構成によって決定されてもよい。

【0431】

同様の方法によって、ｎが９以上である場合（カウントフィールドの値が１１１_Bである場合）には、リンク層パケットの全体長Ｌ_Tを次のように計算することができる。

【数12】

【0432】

同様に、ここで、Ｌ_CIDは、共通ＣＩＤフィールドの長さを意味できる。

【0433】

図６０は、本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーの構造を示す図である。

【0434】

この場合、リンク層パケットのヘッダーは、固定ヘッダー（Ｆｉｘｅｄ ｈｅａｄｅｒ）と拡張ヘッダー（Ｅｘｔｅｎｄｅｄ ｈｅａｄｅｒ）を含むことができる。固定ヘッダーは１バイトの長さを有することができ、拡張ヘッダーは、固定された長さを有したり可変する値（ｖａｒｉａｂｌｅ）を長さとして有することができる。各ヘッダーの長さは設計者の意図によって変更されてもよい。

【0435】

固定ヘッダーは、パケットタイプフィールド、ＰＣフィールド及び／又はカウントフィールドを含むことができる。他の実施例によれば、固定ヘッダーは、パケットタイプフィールド、ＰＣフィールド、ＬＩフィールド及び／又はセグメントＩＤフィールドを含むことができる。

【0436】

拡張ヘッダーは、セグメントシーケンスナンバー（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）フィールド及び／又はセグメント長ＩＤ（Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ ＩＤ）フィールドを含むことができる。他の実施例によれば、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又は最後のセグメント長（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ）フィールドを含むことができる。

【0437】

固定ヘッダーのフィールドについて説明する。

【0438】

パケットタイプフィールドは、前述したように、リンク層に入力されるパケットのタイプを示すことができる。ＩＰパケットがリンク層の入力として入る場合、パケットタイプフィールドは０００_B又は００１_Bの値を有することができる。

【0439】

ＰＣ（Ｐａｃｋｅｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）フィールドは、続く固定ヘッダーの残り部分及び／又は拡張ヘッダーの構成を示すことができる。すなわち、ＰＣフィールドは、入力されたＩＰパケットがいかなる形態で処理されたかを示すことができる。したがって、ＰＣフィールドは、拡張ヘッダーの長さに関する情報を内包することができる。

【0440】

ＰＣフィールドの値が０の場合、これは、リンク層パケットのペイロードが一つのＩＰパケットを含んだり、連結された２つ以上のＩＰパケットを含むことを意味できる。ここでいう連結とは、短い長さの複数のパケットが一つにつながってペイロードを構成することを意味できる。

【0441】

また、ＰＣフィールドの値が０の場合、ＰＣフィールドには４ビットのカウントフィールドが続いてもよい。ここで、カウントフィールドは、一つのペイロードがいくつの連結されたＩＰパケットを有するかを示すことができる。カウントフィールドの値による連結されたＩＰパケットの個数については後述する。

【0442】

また、ＰＣフィールドの値が０の場合、リンク層は拡張ヘッダーを含まなくてもよい。ただし、実施例によって、リンク層パケットの長さが表示される必要がある場合、１−２バイトの拡張ヘッダーが追加されてもよい。この場合、拡張ヘッダーは、リンク層パケットの長さを示すために用いることができる。

【0443】

ＰＣフィールドの値が１の場合、これは、リンク層パケットのペイロードが分割されたパケット（ｓｅｇｍｅｎｔｅｄ ｐａｃｋｅｔ）を含むことを意味することができる。ここで、分割されたパケットは、長い長さのＩＰパケットがいくつかのセグメントに分けられたことを意味することができる。各分割された断片を、セグメント又は分割されたパケットと呼ぶことができる。すなわち、ＰＣフィールドの値が１の場合、リンク層パケットのペイロードは一つの分割された断片、すなわち、セグメントを含むことができる。

【0444】

また、ＰＣフィールドの値が１の場合、ＰＣフィールドには１ビットのＬＩフィールドと３ビットのセグメントＩＤフィールドが続いてもよい。

【0445】

ＬＩ（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｉｎｄｉｃａｔｏｒ）フィールドは、当該リンク層パケットが分割されたセグメントのうち、最後のセグメントを含むか否かを示すことができる。すなわち、ＬＩ値が１の場合、当該リンク層は、分割されたセグメントのうち最後のセグメントを含み、ＬＩ値が０の場合にはそうでない。ＬＩフィールドは、受信機が本来のＩＰパケットを再構成する時に用いることができる。ＬＩフィールドの値は、リンク層パケットの拡張ヘッダーに関する情報を示すこともできる。すなわち、ＬＩフィールド値が０の場合、拡張ヘッダーの長さは１バイト、ＬＩフィールド値が１の場合には、拡張ヘッダーの長さは２バイトであってもよい。その詳細は後述する。

【0446】

セグメントＩＤフィールドは、当該リンク層パケットが含むセグメントのＩＤを示すことができる。一つのＩＰパケットが分割されるとき、各セグメントには同じＩＤを与えることができる。このセグメントＩＤは、受信機が本来のＩＰパケットを再構成する時、それぞれのセグメントが同じＩＰパケットの構成要素であることを知らせることができる。セグメントＩＤフィールドは３ビットのサイズを有するので、同時に総８個のＩＰパケットの分割を支援することができる。

【0447】

また、ＰＣフィールドの値が１の場合、分割に関する情報のために拡張ヘッダーを用いることができる。前述したように、拡張ヘッダーは、セグメントシーケンスナンバー、セグメント長ＩＤフィールド、及び／又は最後のセグメント長フィールドなどを含むことができる。

【0448】

拡張ヘッダーのフィールドについて説明する。

【0449】

前述したＬＩフィールドが０の値を有する場合、すなわち、リンク層パケットに含まれているセグメントが最後のセグメントでない場合、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又はセグメント長ＩＤフィールドを含むことができる。

【0450】

セグメントシーケンスナンバーフィールドは、分割されたパケットが何番目のパケットであるかを示すことができる。したがって、一つのＩＰパケットから分割されたセグメントを有するリンク層パケットは、同じセグメントＩＤフィールドを有するが、異なるセグメントシーケンスナンバーフィールドを有する。セグメントシーケンスナンバーフィールドは４ビットのサイズを有するので、一つのＩＰパケットは最大１６個のセグメントに分割され得る。

【0451】

セグメント長ＩＤフィールドは、最後のセグメント以外のセグメントの長さを示すことができる。最後のセグメント以外のセグメントの長さは同一であってもよい。したがって、これらの長さは、既に指定された長さＩＤを用いて表現してもよい。セグメント長ＩＤフィールドは、その長さＩＤを示すことができる。

【0452】

セグメントの長さは、物理層のＦＥＣコードレートによって決定されているパケットの入力サイズに基づいて設定することができる。すなわち、その入力サイズに合わせてセグメントの長さを決定することができ、そのセグメント長はセグメント長ＩＤによって指定されてもよい。ヘッダーのオーバーヘッドを減らすために、セグメントが有し得る長さは１６個に制限されてもよい。

【0453】

セグメントの長さによるセグメント長ＩＤフィールドの値については後述する。

【0454】

物理層がセグメントの長さとは無関係に動作する場合、セグメントの長さはセグメント長ＩＤと長さユニット（Ｌｅｎ＿Ｕｎｉｔ、Ｌｅｎｇｔｈ Ｕｎｉｔ）の積に最小セグメント長（ｍｉｎ＿Ｌｅｎ、ｍｉｎｉｍｕｍ ｓｅｇｍｅｎｔ ｌｅｎｇｔｈ）を足して求めることができる。ここで、長さユニットは、セグメントの長さを表示する基本単位であり、最小セグメント長は、セグメント長の最小値を意味できる。長さユニットと最小セグメント長は、送信機と受信機で常に同じ値を有しなければならず、一度決定されると変わらない方が、システム運用に効率的である。長さユニットと最小セグメント長は、システムの初期化過程で物理層のＦＥＣ処理能力を考慮して決定することができる。

【0455】

上記ＬＩフィールドが１の値を有する場合、すなわち、リンク層パケットに含まれているセグメントが最後のセグメントである場合、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又は最後のセグメント長フィールドを含むことができる。

【0456】

セグメントシーケンスナンバーフィールドは、前述したとおりである。

【0457】

最後のセグメント長フィールドは、最後のセグメントの長さを直接示すことができる。一つのＩＰパケットが特定長さを有するセグメントに分割される場合、最後のセグメントは、他のセグメントと異なる長さを有することがある。このため、最後のセグメント長フィールドは最後のセグメントの長さを直接示すことができる。最後のセグメント長フィールドは１−４０９５バイトを表示することができる。表示可能なバイト数は、実施例によって異なってもよい。

【0458】

図６１は、本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、各フィールドの値が示すものを示す図である。

【0459】

前述したように、カウントフィールドの値によって連結されたＩＰパケットの個数を決定することができる（ｔ６１０１０）。カウントフィールドの値はそのまま連結されたＩＰパケットの個数を示すこともできるが、０個のパケットが連結された場合は意味がない。このため、カウントフィールドは、カウントフィールドの値に１を足した個数のＩＰパケットが連結されていることを示すことができる。すなわち、表ｔ６１０１０のように、００１０の場合に３個、０１１１の場合に８個のＩＰパケットが連結されていると表現することができる。

【0460】

ここで、カウントフィールドの値が００００の場合、１個のＩＰパケットが連結されていることを示すが、これは連結無しで、リンク層パケットのペイロードが一つのＩＰパケットを含むことを示すことができる。

【0461】

前述したように、分割されたセグメントの長さは、セグメント長ＩＤフィールドの値によって表現することができる（ｔ６１０２０）。

【0462】

例えば、セグメント長ＩＤフィールドの値が００００の場合、５１２バイトのセグメント長を有することができる。これは、当該リンク層パケットのペイロードが含むセグメントが最後のセグメントではなく、５１２バイトの長さを有することを意味できる。このセグメントと同じＩＰパケットから分割された他のセグメントも、最後のセグメントでなければ、５１２バイトの長さを有することができる。

【0463】

この表では、長さユニットは２５６、最小セグメント長は５１２の値を有する。したがって、最小のグメント長は５１２バイト（セグメント長ＩＤフィールド＝００００）である。また、指定されたセグメントの長さは２５６バイトの間隔で増加する。

【0464】

図６２は、本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、一つのＩＰパケットがリンク層ペイロードに含まれる場合を示す図である。

【0465】

一つのＩＰパケットがリンク層ペイロードに含まれる場合、すなわち、連結又は分割が行われない場合を、ノーマルパケットにカプセル化する場合と呼ぶことができる。この場合は、ＩＰパケットが物理層の処理範囲内にある場合であってもよい。

【0466】

本実施例で、リンク層パケットは、総１バイトのヘッダーを有することができる。ヘッダーの長さは、実施例によって変更されてもよい。パケットタイプフィールドは０００（ＩＰｖ４の場合）、又は００１（ＩＰｖ６の場合）の値を有することができる。ノーマルパケットカプセル化過程は、ＩＰｖ４又はＩＰｖ６に同一に適用することができる。ＰＣフィールドの値は、一つのパケットがペイロードに含まれるので、０を有することができる。後続するカウントフィールドは、同様に一つのパケットのみがペイロードに含まれるので、００００の値を有することができる。

【0467】

本実施例で、リンク層パケットのペイロードは、一つのＩＰパケットをそのまま含むことができる。

【0468】

本実施例で、リンク層パケットの長さを確認するためには、ＩＰパケットヘッダーの情報を活用することができる。ＩＰパケットのヘッダーには、ＩＰパケットの長さを示すフィールドが含まれている。このフィールドを長さフィールドと呼ぶことができる。この長さフィールドがＩＰパケット内に位置する位置は固定されていてもよい。一つのＩＰパケットがそのままリンク層のペイロードに含まれるので、リンク層パケットのペイロードの開始から一定オフセットの長さだけ移動した位置に、この長さフィールドが位置することができる。したがって、この長さフィールドから、全体リンク層のペイロード長を求めることができる。

【0469】

ＩＰｖ４の場合、ペイロード開始点から２バイト、ＩＰｖ６の場合、ペイロード開始点から４バイトだけ移動した位置に、この長さフィールドが位置可能である。長さフィールドは２バイトの長さを有することができる。

【0470】

ＩＰｖ４の場合において、長さフィールドの値をＬ_IPv4とし、リンク層パケットのヘッダー長をＬ_H（１バイト）とすれば、全体リンク層パケットの長さ（Ｌ_T）は、同図の数式のように示すことができる（ｔ６２０１０）。ここで、長さフィールドの値Ｌ_IPv4は、ＩＰｖ４パケットの全体長を示すことができる。

【0471】

ＩＰｖ６の場合において、長さフィールドの値をＬ_IPv6とし、リンク層パケットのヘッダー長をＬ_H（１バイト）とすれば、全体リンク層パケットの長さ（Ｌ_T）は、同図の数式のように示すことができる（ｔ６２０２０）。ここで、長さフィールドの値Ｌ_IPv6は、ＩＰｖ６パケットのペイロードの長さのみを示すので、全体リンク層パケットの長さを求めるためには、ＩＰｖ６パケットの固定ヘッダー長（４０バイト）をさらに加えければならない。

【0472】

図６３は、本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、複数個のＩＰパケットが連結されてリンク層ペイロードに含まれる場合を示す図である。

【0473】

入力されたＩＰパケットが物理層の処理範囲に到達していない場合、複数個のＩＰパケットを連結して一つのリンク層パケットのペイロードにカプセル化することができる。

【0474】

本実施例で、リンク層パケットは、総１バイトのヘッダーを有することができる。ヘッダーの長さは、実施例によって変更されてもよい。パケットタイプフィールドは０００（ＩＰｖ４の場合）、又は００１（ＩＰｖ６の場合）の値を有することができる。本実施例のカプセル化過程はＩＰｖ４又はＩＰｖ６に同一に適用可能である。ＰＣフィールドは、連結された複数個のＩＰパケットがペイロードに含まれるので、０の値を有することができる。続くカウントフィールドは、連結された複数個のＩＰパケットの個数を示すことができる（４ビット）。

【0475】

本実施例で、リンク層パケットのペイロードは、複数個のＩＰパケットを含むことができる。複数個のＩＰパケットが前後で互いに連結されてリンク層パケットのペイロードに含まれるようにすることができる。連結する方式は、設計者の意図によって変更されてもよい。

【0476】

本実施例で、リンク層パケットの長さを確認するためには、連結されたＩＰパケットヘッダーの情報を活用することができる。前述したノーマルパケットカプセル化と同様に、各ＩＰパケットのヘッダーには、そのＩＰパケットの長さを示す長さフィールドが存在可能である。また、これらの長さフィールドは、ＩＰパケット内で固定された位置にすることができる。

【0477】

したがって、リンク層パケットのヘッダー長をＬ_H、それぞれのＩＰパケットの長さをＬ_k（ここで、ｋは、１より大きい又は等しく、ｎより小さい又は等しい）とすれば、全体リンク層パケットの長さ（Ｌ_T）は、同図の数式のように示すことができる（ｔ６３０１０）。すなわち、各ＩＰパケットの長さフィールドが示す各ＩＰパケットの長さをすべて合算し、ここにリンク層パケットのヘッダー長を足すと、全体リンク層パケットの長さを求めることができる。Ｌ_kの値は、各ＩＰパケットのヘッダーの長さフィールドから読み取ることができる。

【0478】

図６４は、本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、一つのＩＰパケットが分割されてリンク層ペイロードに含まれる場合を示す図である。

【0479】

入力されたＩＰパケットが物理層の処理範囲を超える場合、一つのＩＰパケットは複数個のセグメントに分割されてもよい。各分割されたセグメントは、それぞれのリンク層パケットのペイロードにカプセル化することができる。

【0480】

本実施例で、各リンク層パケット（ｔ６４０１０，ｔ６４０２０，ｔ６４０３０）は、固定ヘッダーと拡張ヘッダーを有することができる。各固定ヘッダー及び拡張ヘッダーの長さは、実施例によって変更されてもよい。パケットタイプフィールドは、０００（ＩＰｖ４の場合）、又は００１（ＩＰｖ６の場合）の値を有することができる。本実施例のカプセル化過程は、ＩＰｖ４又はＩＰｖ６に同一に適用可能である。ＰＣフィールドは、分割されたセグメントがペイロードに含まれるので、１の値を有することができる。

【0481】

最後のセグメント以外のセグメントをペイロードとして有するリンク層パケット（ｔ６４０１０，ｔ６４０２０）は、ＬＩフィールドは０の値を有することができ、それぞれのセグメントＩＤフィールドは同じ値を有することができる。各セグメントが同じＩＰパケットから分割されたセグメントであるためである。続くセグメントシーケンスナンバーフィールドは、当該セグメントの順序を示すことができる。ここで、１番目のリンク層パケット（ｔ６４０１０）のセグメントシーケンスフィールド値は、当該リンク層パケットが１番目のセグメントをペイロードとして有することを示すことができる。２番目のリンク層パケット（ｔ６４０２０）のセグメントシーケンスフィールド値は、当該リンク層パケットが２番目のセグメントをペイロードとして有することを示すことができる。セグメント長ＩＤフィールドは、分割されたセグメントの長さを、既に指定された長さＩＤで表現することができる。

【0482】

最後のセグメントをペイロードとして有するリンク層パケット（ｔ６４０３０）は、ＬＩフィールドが１の値を有することができる。ここで、セグメントＩＤフィールドは、他のリンク層パケットと同一であってもよい。最後のセグメントも、同一のＩＰパケットから分割されたセグメントであるためである。続くセグメントシーケンスナンバーフィールドは、当該セグメントの順序を示すことができる。最後のセグメント長フィールドは、このリンク層パケット（ｔ６４０３０）が有する最後のセグメントの長さを直接示すことができる。

【0483】

本実施例で、リンク層パケットの長さを確認するためには、セグメント長ＩＤフィールド又は最後のセグメント長フィールドを活用することができる。各フィールドは、当該リンク層パケットのペイロードの長さのみを示すので、全体リンク層パケットの長さを求めるためには、リンク層パケットのヘッダー長も合算しなければならない。リンク層パケットのヘッダー長は、前述したように、ＬＩフィールドから読み取ることができる。

【0484】

図６５は、本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、分割されたセグメントを有するリンク層パケットを示す図である。

【0485】

本実施例は、５５００バイトのＩＰパケットが入力として入ったと仮定する。５５００を５で割った値は１１００であるので、この値に最も近い１０２４バイトの長さで各セグメントを構成することができる。この場合、最後のセグメントは、１４０４バイト（０１０１０１１１１１００_B）となる。分割されたそれぞれのセグメントをＳ₁，Ｓ₂，Ｓ₃，Ｓ₄，Ｓ₅と呼ぶことができ、それに該当するヘッダーをそれぞれ、Ｈ₁，Ｈ₂，Ｈ₃，Ｈ₄，Ｈ₅と呼ぶことができる。セグメントにヘッダーを追加してそれぞれのリンク層パケットを生成することができる。

【0486】

入力されたＩＰパケットがＩＰｖ４パケットである場合、Ｈ₁乃至Ｈ₅のパケットタイプフィールドは０００の値を有することができる。また、Ｈ₁乃至Ｈ₅のＰＣフィールドは、分割されたパケットをペイロードとして有するので、１の値を有することができる。

【0487】

Ｈ₁乃至Ｈ₄のＬＩは、最後のセグメントをペイロードとして有しないので、０の値を有することができる。Ｈ₅のＬＩは、最後のセグメントをペイロードとして有するので、１の値を有することができる。Ｈ₁乃至Ｈ₅のＳｅｇ＿ＩＤ、すなわち、セグメントＩＤフィールドは、いずれも同一パケットから分割されたセグメントをペイロードとして有するので、同じ値（０００）を有することができる。

【0488】

Ｈ₁乃至Ｈ₅のＳｅｇ＿ＳＮ、すなわち、セグメントシーケンスナンバーフィールドは、Ｈ₁からＨ₅までを順に００００_Bから０１００_Bと表示することができる。Ｈ₁乃至Ｈ₄のセグメント長ＩＤフィールドは、１０２４バイト長のＩＤに該当する００１０の値を有することができる。Ｈ₅のセグメント長フィールドは、１４０４バイトを示す０１０１０１１１１１００をその値として有することができる。

【0489】

図６６は、本発明の他の実施例に係る、リンク層にＩＰパケットが伝達される場合におけるリンク層パケットのヘッダーにおいて、ＣＲＣエンコーディングを活用する方案を示す図である。

【0490】

ＩＰパケットが分割されてリンク層パケットとして処理される場合、受信機では、複数個のリンク層パケットを受信し、本来のＩＰパケットとして組み換えなければならない。受信機は組み換えたＩＰパケットの完全性を確認する必要がある。

【0491】

そのために、ＣＲＣエンコーディングを活用することができる。ＩＰパケットが分割される前に、ＩＰパケットの後にＣＲＣを追加することができる。ＣＲＣを追加したＩＰパケットが分割される場合、最後のセグメントを含むリンク層パケットは、ＣＲＣまで含むことができる。受信機は、ＣＲＣを確認し、エラーなしで組み換えに成功したか否かを判断できる。

【0492】

一般に、ＣＲＣは、パケットの最後に追加されるか、実施例によって他の位置に追加されてもよい。

【0493】

図６７は、本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケットの構造を示す図である。

【0494】

この場合、リンク層パケットのヘッダーは、固定ヘッダー（Ｆｉｘｅｄ ｈｅａｄｅｒ）と拡張ヘッダー（Ｅｘｔｅｎｄｅｄ ｈｅａｄｅｒ）を含むことができる。固定ヘッダーは、１バイトの長さを有することができ、拡張ヘッダーは、固定された長さを有してもよく、可変する値（ｖａｒｉａｂｌｅ）を有してもよい。各ヘッダーの長さは設計者の意図によって変更されてもよい。

【0495】

固定ヘッダーは、パケットタイプフィールド、ＰＣフィールド及び／又は連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）カウントフィールドを含むことができる。他の実施例によれば、固定ヘッダーは、パケットタイプフィールド、ＰＣフィールド、ＬＩフィールド及び／又はセグメントＩＤフィールドを含むことができる。

【0496】

拡張ヘッダーは、シグナリングクラスフィールド、情報タイプ（ｉｎｆｏｒｍａｔｉｏｎ ｔｙｐｅ）フィールド及び／又はシグナリングフォーマットフィールドを含むことができる。他の実施例によれば、拡張ヘッダーは、ペイロード長パートをさらに含むことができる。更に他の実施例によれば、拡張ヘッダーは、セグメントシーケンスナンバーフィールド、セグメント長ＩＤフィールド、シグナリングクラスフィールド、情報タイプフィールド及び／又はシグナリングフォーマットフィールドを含むことができる。更に他の実施例によれば、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又はセグメント長ＩＤフィールドを含むことができる。更に他の実施例によれば、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又は最後のセグメント長フィールドを含むことができる。

【0497】

固定ヘッダーのフィールドについて説明する。

【0498】

パケットタイプフィールドは、前述したように、リンク層に入力されるパケットのタイプを示すことができる。シグナリング情報がリンク層の入力として入る場合、パケットタイプフィールドは１１０_Bの値を有することができる。

【0499】

ＰＣフィールド、ＬＩフィールド、セグメントＩＤフィールド、セグメントシーケンスナンバーフィールド、セグメント長ＩＤフィールド、最後のセグメント長フィールドは、前述したとおりである。連結カウントフィールドは、前述したカウントフィールドと同一である。

【0500】

拡張ヘッダーのフィールドについて説明する。

【0501】

ＰＣフィールドが０の値を有する場合、拡張ヘッダーは、シグナリングクラスフィールド、情報タイプフィールド及び／又はシグナリングフォーマットフィールドを含むことができる。また、シグナリングフォーマットフィールドの値によって、拡張ヘッダーはペイロード長パートをさらに含んでもよい。

【0502】

シグナリングクラスフィールドは、リンク層パケットが含むシグナリング情報がいかなるタイプの情報であるかを示すことができる。シグナリングクラスフィールドが示すシグナリング情報としては、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）情報又はヘッダー圧縮情報などを挙げることができる。シグナリングクラスフィールドが示すシグナリング情報については後述する。

【0503】

情報タイプフィールドは、シグナリングクラスフィールドが指定するタイプのシグナリング情報に対して、その具体的な事項を示すことができる。情報タイプフィールドが意味するものは、シグナリングクラスフィールドの値によって別に定義されてもよい。

【0504】

シグナリングフォーマットフィールドは、リンク層パケットが含むシグナリング情報がいかなるフォーマットを有するか示すことができる。シグナリングフォーマットフィールドが示すフォーマットとしては、セクションテーブル、デスクリプタ又はＸＭＬなどを挙げることができる。シグナリングフォーマットフィールドが示すフォーマットについては後述する。

【0505】

ペイロード長パートは、リンク層パケットのペイロードが含むシグナリング情報の長さを示すことができる。ペイロード長パートは、連結されているそれぞれのシグナリング情報の長さを示す長さフィールドの集合であってもよい。それぞれの長さフィールドは、２バイトのサイズを有することができるが、システムの構成によってサイズは変更されてもよい。ペイロード長パートの全体長は、それぞれの長さフィールドの長さの和と表現することができる。実施例によって、バイトの整列のためのパディングビットが追加されてもよい。この場合、パディングビット分だけペイロード長パートの全体長が増加してもよい。

【0506】

ペイロード長パートが存在するか否かは、シグナリングフォーマットフィールドの値によって決定することができる。セクションテーブル及びデスクリプタのように、当該シグナリング情報が当該シグナリング情報の長さ値を有する場合には、別の長さフィールドが省かれてもよい。しかし、別の長さ値を有しないシグナリング情報の場合は、別の長さフィールドを必要とする。別の長さ値を有しないシグナリング情報の場合、ペイロード長パートが存在すればよい。この場合、ペイロード長パートは、カウントフィールドの数だけ長さフィールドを含むことができる。

【0507】

ＰＣフィールドが１であり、ＬＩフィールドが１の値を有する場合、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又は最後のセグメント長フィールドを含むことができる。ＰＣフィールドが１であり、ＬＩフィールドが０の値を有する場合、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又はセグメント長ＩＤフィールドを含むことができる。

【0508】

セグメントシーケンスナンバーフィールド、最後のセグメント長フィールド、セグメント長ＩＤフィールドは、前述したとおりである。

【0509】

ＰＣフィールドが１であり、ＬＩフィールドが０の値を有する場合において、当該リンク層パケットのペイロードが１番目のセグメントであれば、その拡張ヘッダーは付加情報をさらに含むことができる。この付加情報は、シグナリングクラスフィールド、情報タイプフィールド、及び／又はシグナリングフォーマットフィールドを含むことができる。シグナリングクラスフィールド、情報タイプフィールド、シグナリングフォーマットフィールドは、前述したとおりである。

【0510】

図６８は、本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、各フィールドの値が示す意味を示す図である。

【0511】

前述したように、リンク層パケットが含むシグナリング情報のタイプは、シグナリングクラスフィールドによって表現することができる（ｔ６８０１０）。

【0512】

例えば、シグナリングクラスフィールド値が０００の場合、シグナリング情報はＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）のためのシグナリング情報であることを意味できる。シグナリングクラスフィールド値が００１の場合、シグナリング情報は、緊急状況警報（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ）のためのシグナリング情報であってもよい。シグナリングクラスフィールド値が０１０の場合、シグナリング情報はヘッダー圧縮のためのシグナリング情報であってもよい。シグナリングクラスフィールド値が０１１乃至１１０の場合は、後に利用可能なシグナリング情報タイプのために残すことを意味できる。シグナリングクラスフィールド値が１１１の場合、種々のシグナリング情報がリンク層パケットに含まれていることを意味できる。

【0513】

シグナリングクラスフィールドが示し得るシグナリング情報値は、実施例によって異なってもよい。

【0514】

前述したように、リンク層パケットが含むシグナリング情報のフォーマットは、シグナリングフォーマットフィールドによって表現されてもよい（ｔ６８０２０）。

【0515】

例えば、シグナリングフォーマットフィールド値が００の場合、シグナリング情報はセクションテーブルの形態でペイロードに含まれることを意味できる。シグナリングフォーマットフィールド値が０１の場合、シグナリング情報はデスクリプタの形態でペイロードに含まれることを意味できる。シグナリングフォーマットフィールド値が１０の場合、シグナリング情報はＸＭＬの形態でペイロードに含まれることを意味できる。シグナリングフォーマットフィールド値が１１の場合、シグナリング情報はその他の形態でペイロードに含まれることを意味できる。

【0516】

シグナリングフォーマットフィールドが示し得るフォーマットは、実施例によって異なってもよい。

【0517】

図６９は、本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、シグナリング情報が一つのセクションテーブルである場合の構造を示す図である。

【0518】

本実施例では、一つのセクションテーブルが一つのリンク層パケットにカプセル化される場合を仮定する。

【0519】

本実施例で、リンク層パケットのヘッダーは、１１０値を有するパケットタイプフィールドを含むことができる。一つのシグナリング情報がリンク層パケットのペイロードに含まれるので、ＰＣフィールドは０、連結カウントフィールドは００００の値を有することができる。シグナリングクラスフィールド及び情報タイプフィールドは、当該セクションテーブルが有するデータによる値を有することができる。シグナリング情報がセクションテーブルであるので、シグナリングフォーマットフィールドは００の値を有することができる。

【0520】

本実施例で、リンク層パケットのペイロードは、入力されたセクションテーブルがそのまま位置してもよい。

【0521】

本実施例で、リンク層パケットの長さを確認するためには、セクションテーブルの情報を活用することができる。前述したように、セクションテーブルのフィールドには、当該セクションテーブルの長さを示すフィールドが含まれていてもよい。このフィールドを長さフィールドと呼ぶことができる。この長さフィールドのセクションテーブル内における位置は固定されていてもよい。一つのセクションテーブルがそのままリンク層のペイロードに含まれるので、リンク層パケットのペイロードの開始から一定オフセットの長さだけ移動した位置に、この長さフィールドが位置可能である。したがって、この長さフィールドから、全体リンク層のペイロード長を読み取ることができる。セクションテーブルの場合、ペイロードの開始点から１２ビット移動した位置に、１２ビットの長さフィールドが位置すればよい。この長さフィールドをＳｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドと呼ぶことができる。

【0522】

長さフィールドの値Ｌ_sectionは、長さフィールドの直後からセクションテーブルの最後までの長さを示すことができる。したがって、セクションテーブルの残り部分の３バイトと、リンク層パケットヘッダー長の２バイトを加えると、全体リンク層パケットの長さとなる。すなわち、リンク層パケット全体長Ｌ_Tは、Ｌ_section＋５バイトでよい。

【0523】

受信機が本実施例のリンク層パケットを受信すると、シグナリングクラスフィールド及び／又は情報タイプフィールドなどを用いて当該シグナリング情報（セクションテーブル）を処理することができる。また、受信機は、セクションテーブル内のテーブルＩＤ（８ビット）値を確認して、当該シグナリング情報を処理することができる。

【0524】

図７０は、本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、シグナリング情報が一つのデスクリプタである場合の構造を示す図である。

【0525】

本実施例では、一つのデスクリプタが一つのリンク層パケットにカプセル化される場合を仮定する。

【0526】

本実施例で、リンク層パケットのヘッダー情報は、一つのセクションテーブルがカプセル化される場合と同一であってもよい。ただし、シグナリングクラスフィールド及び情報タイプフィールドは、当該デスクリプタが有するデータによる値を有することができる。また、シグナリング情報がデスクリプタであるので、シグナリングフォーマットフィールドは０１の値を有することができる。

【0527】

本実施例で、リンク層パケットのペイロードは、入力されたデスクリプタがそのまま位置してもよい。

【0528】

本実施例で、リンク層パケットの長さを確認するためには、デスクリプタの情報を用いることができる。これは、前述した一つのセクションテーブルがカプセル化される場合と同様である。ただし、デスクリプタ内の、当該デスクリプタの長さを示すフィールドの位置は異なってもよい。デスクリプタの場合、長さフィールドがペイロードの開始点から８ビット離れて位置し、８ビットの長さを有することができる。これを用いて、全体リンク層パケットの長さを求めることができる。

【0529】

受信機が本実施例のリンク層パケットを受信すると、シグナリングクラスフィールド及び／又は情報タイプフィールドなどを用いて当該シグナリング情報（デスクリプタ）を処理するこができる。また、受信機は、デスクリプタのデスクリプタタグ（８ビット）を確認して、当該シグナリング情報を処理することができる。

【0530】

図７１は、本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、シグナリング情報が複数個のデスクリプタである場合の構造を示す図である。

【0531】

本実施例で、リンク層パケットのペイロードには複数個のデスクリプタが連結してカプセル化されてもよい。

【0532】

本実施例のリンク層パケットヘッダーは、１１０値を有するパケットタイプフィールド、０値を有するＰＣフィールドを含むことができる。連結カウントフィールドは、いくつのデスクリプタが連結されたかを示すことができる。シグナリングクラスフィールド及び情報タイプフィールドは、当該デスクリプタが有するデータによる値を有することができる。シグナリング情報がデスクリプタであるので、シグナリングフォーマットフィールドは、０１の値を有することができる。

【0533】

本実施例のリンク層パケットの全体長は、ＩＰパケットが連結されている場合と類似の方法で計算することができる。ペイロードの開始点から順次に、カウントフィールドが示す数だけのデスクリプタの長さフィールド（ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ）値を読み取ることができる。読み取った値をすべて合算してリンク層パケットの全体ペイロード長を求めることができる。ここにリンク層パケットのヘッダー長を足して全体リンク層パケットの長さを求めることができる。

【0534】

図７２は、本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、シグナリング情報が複数個のセクションテーブルである場合の構造を示す図である。

【0535】

本実施例で、リンク層パケットのペイロードには複数個のセクションテーブルが連結してカプセル化されてもよい。

【0536】

本実施例のリンク層パケットヘッダーは、１１０値を有するパケットタイプフィールド、０値を有するＰＣフィールド、連結されたセクションテーブルの個数を示す連結カウントフィールドを含むことができる。シグナリングクラスフィールド及び情報タイプフィールドは、当該セクションテーブルが有するデータによる値を有することができる。シグナリング情報がセクションテーブルであるので、シグナリングフォーマットフィールドは００の値を有することができる。

【0537】

本実施例のリンク層パケットの全体長は、前述したデスクリプタが連結されている場合と類似の方法で求めることができる。前述したように、セクションテーブルの場合、セクションテーブルの開始点から１２ビット移動して１２ビットの長さフィールドが位置できる。この長さフィールドに余りのセクションテーブルの長さを足して全体セクションテーブルの長さを求めることができる。それぞれの全体セクションテーブル長さを合算すると、連結されたセクションテーブルの全体長、すなわち、リンク層パケットのペイロードの長さが求められる。ここにリンク層パケットのヘッダー長を足して全体リンク層パケットの長さを求めることができる。

【0538】

図７３は、本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、シグナリング情報が別途の長さ値を有しない場合の構造を示す図である。

【0539】

本実施例は、前述したシグナリングフォーマットフィールドが、当該シグナリング情報がＸＭＬ又は別途の長さ値を有しないシグナリング情報であることを示す場合に該当し得る。前述したように、この場合、拡張ヘッダーはペイロード長パートをさらに含むことができる。

【0540】

本実施例のヘッダーは、１１０の値を有するパケットフィールド、０値を有するＰＣフィールド、連結されたシグナリング情報の個数を示す連結カウントフィールドを含むことができる。続くシグナリングクラスフィールド及び情報タイプフィールドは、当該シグナリング情報が有するデータによる値を有することができる。シグナリング情報がＸＭＬ又は別途のシグナリング情報であるから、シグナリングフォーマットフィールドは、１０又は１１の値を有することができる。

【0541】

追加されたペイロード長パートは、前述したように、複数個の長さフィールドを含むことができる。各長さフィールドは、各シグナリング情報の長さを示すことができる。したがって、連結カウントフィールドが示す個数だけの長さフィールドが存在できる。長さフィールドはそれぞれ２バイトの長さを有することができる。長さフィールドの長さは、システムの構成によって変更されてもよい。リンク層パケットにはバイト整列のためのパディングビットがさらに追加されてもよい。

【0542】

本実施例で、全体リンク層パケットの長さを求めるためには、長さフィールドを活用することができる（ｔ７３０１０）。連結カウンターフィールドの値が意味する個数がｎ個の場合、総２＊ｎバイトのペイロード長パートをヘッダーに追加することができる。また、連結されたシグナリング情報Ｓ₁，Ｓ₂，…，Ｓ_nの長さを示す各長さフィールドの値をＬ₁，Ｌ₂，…，Ｌ_nとし、リンク層パケットのヘッダー長を２バイトとすれば、全体リンク層パケットの長さＬ_Tは、同図の数式のように表現できる（ｔ７３０１０）。

【0543】

図７４は、本発明の他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、一つのシグナリング情報が複数個のセグメントに分割される場合の構造を示す図である。

【0544】

入力されたシグナリング情報が物理層の処理範囲を超える場合、一つのシグナリング情報は、複数個のセグメントに分割されてもよい。各分割されたセグメントは、それぞれのリンク層パケットのペイロードにカプセル化することができる。

【0545】

本実施例の構造は、前述したＩＰパケットが分割された場合と類似のヘッダー構造を有することができる。パケットタイプフィールドは、シグナリング情報が入力された場合であるから、１１０値を有することができる。ＰＣフィールド、ＬＩフィールド、セグメントＩＤフィールド、セグメントシーケンスナンバーフィールド、セグメント長ＩＤフィールド、最後のセグメント長フィールドは、前述したＩＰパケットが分割された場合のとおりである。

【0546】

本実施例の場合、前述したＩＰパケットが分割された場合と違い、最初のパケットが付加情報をさらに含むことができる（ｔ７４０１０）。この付加情報は、前述したように、シグナリングクラスフィールド、情報タイプフィールド、及び／又はシグナリングフォーマットフィールドを含むことができる。これらの付加情報は、受信機がセグメントをすべて受信した場合、当該シグナリング情報に対する処理を可能にさせる。

【0547】

ＬＩフィールド値とセグメントシーケンスナンバーフィールドとの組合せからリンク層パケットの拡張ヘッダーに関する情報を読み取ることができる。ＬＩフィールド値が０であり、セグメントシーケンスナンバーフィールド値が００００である場合（すなわち、最初のセグメントである場合）、拡張ヘッダーの長さは２バイトでよい。ＬＩフィールド値が０であり、セグメントシーケンスナンバーフィールド値が００００でない場合、拡張ヘッダーの長さは１バイトであってもよい。ＬＩフィールド値が１の場合、拡張ヘッダーの長さは２バイトであってもよい。

【0548】

全体リンク層パケットの長さは、セグメント長ＩＤフィールド又は最後のセグメント長フィールドから読み取ったセグメントの長さに、リンク層パケットヘッダーの長さを足して求めることができる。

【0549】

ＩＰパケットが分割される場合と同様に、シグナリング情報が分割される場合にもＣＲＣエンコーディングを活用することができる。シグナリング情報の最後にＣＲＣが追加されてもよい。このＣＲＣは、受信機がシグナリング情報を組み換える時、組み換えの完全性を確認するために用いることができる。ＣＲＣの追加されたシグナリング情報が分割される場合、最後のセグメントを含むリンク層パケットはＣＲＣも含むことができる。

【0550】

一般にＣＲＣはパケットの最後に追加されるが、実施例によって他の位置に追加されてもよい。

【0551】

図７５は、本発明の一実施例に係る放送信号を伝送する方法を示す図である。

【0552】

本発明の一実施例に係る放送信号を伝送する方法は、放送データをシグナリングする複数個のシグナリング情報を生成する段階（ｔ７５０１０）、上記複数個のシグナリング情報を用いてリンク層パケットを生成する段階（ｔ７５０２０）、上記リンク層パケットを用いて放送信号を生成する段階（ｔ７５０３０）及び／又は上記放送信号を伝送する段階（ｔ７５０４０）を含むことができる。

【0553】

まず、複数個のシグナリング情報を生成することができる（ｔ７５０１０）。ここで、複数個のシグナリング情報は、リンク層を介して伝送される他の放送データをシグナリングするために用いることができる。シグナリング情報の内容、種類は、実施例によって変更されてもよい。複数個のシグナリング情報を生成する段階は、後述する第１モジュールで行うことができる。

【0554】

生成された複数個のシグナリング情報を用いてリンク層パケットを生成することができる（ｔ７５０２０）。この段階は、前述した複数個のシグナリング情報を連結してリンク層パケットを生成する過程に対応可能である。前述したように、リンク層パケットは、リンク層ヘッダーとリンク層ペイロードを含むことができる。リンク層ヘッダーは、パケットタイプフィールド、パケット構成フィールド、カウントフィールドを含み、パケットタイプフィールドは、リンク層ペイロードが含む情報がシグナリング情報であることを示すことができる。上記パケット構成フィールドは、リンク層ペイロードが複数個のシグナリング情報を含むか否かを示し、カウントフィールドは、リンク層ペイロードが含む複数個のシグナリング情報の個数を示すことができる。連結される場合であるから、複数個のシグナリング情報は連結されてリンク層ペイロードに含まれる。

【0555】

ここで、リンク層ヘッダーは、文脈によって、前述した固定ヘッダー又は拡張ヘッダーを意味したり、又は固定ヘッダーと拡張ヘッダーを含む全体ヘッダーを意味できる。パケット構成フィールドは、前述したＰＣフィールドを意味できる。リンク層ペイロードは、リンク層パケットのペイロードを意味できる。リンク層パケットを生成する段階は、後述する第２モジュールで行うことができる。

【0556】

生成されたリンク層パケットを用いて放送信号を生成することができる（ｔ７５０３０）。物理層では、リンク層で生成されたリンク層パケットに一連のエンコーディング、モジュレーションなどを加えることができる。リンク層パケットを用いて、入力パケット／入力シグナリング情報の種類にかからわず、物理層は物理層プロセシングを行うことができる。一連の物理層プロセシングによって放送信号を生成することができる。放送信号を生成する段階は、後述する第３モジュールで行うことができる。

【0557】

放送信号をアンテナを介して受信機に伝送することができる（ｔ７５０４０）。放送信号は、放送網を介して伝送することができ、伝送される方法は、実施例によって変更されてもよい。放送信号を伝送する段階は、後述する第３モジュールで行うことができる。

【0558】

本発明の他の実施例に係る放送信号を伝送する方法は、リンク層ヘッダーが、シグナリングクラスフィールド、情報タイプフィールド及びシグナリングフォーマットフィールドをさらに含むことができる。シグナリングクラスフィールドは、シグナリング情報がシグナリングする対象を示し、情報タイプフィールドは、シグナリング情報に関するデータを含み、シグナリングフォーマットフィールドは、シグナリング情報のフォーマットを示すことができる。シグナリングクラスフィールド、情報タイプフィールド及びシグナリングフォーマットフィールドは、前述したとおりである。

【0559】

本発明の更に他の実施例に係る放送信号を伝送する方法は、シグナリングフォーマットフィールドが、リンク層ペイロードが含む複数個のシグナリング情報が複数個のセクションテーブルであることを示すことができる。これは、シグナリングフォーマットフィールドが示すシグナリング情報のフォーマットがセクションテーブルであることを意味できる。

【0560】

本発明の更に他の実施例に係る放送信号を伝送する方法は、リンク層ヘッダーの長さが、シグナリングフォーマットフィールドの値によって決定されてもよい。すなわち、前述したように、シグナリングフォーマットフィールドの値によってリンク層ヘッダーがペイロード長パートをさらに含むか否かが決定されるためである。また、リンク層ペイロードの長さは、複数個のセクションテーブルのセクション長フィールドの値によって決定されてもよい。前述したように、セクションテーブルには、固定された位置にセクション長フィールドが存在できる。リンク層ペイロードの長さは、これらのセクション長フィールドが示す値の和に基づいて計算することができる。

【0561】

本発明の更に他の実施例に係る放送信号を伝送する方法は、複数個のセクションテーブルのセクション長フィールドがリンク層ペイロード上に順次に位置してもよい。前述したように、セクションテーブルが連結されている場合、間隔をおいてセクション長フィールドがリンク層ペイロード内に並べられてもよい。各長さフィールドは、各セクションテーブルの開始点から固定した位置に位置できる。各セクションテーブルの長さは変更されてもよいので、各長さフィールド間の距離は互いに異なってもよい。前述したように、セクション長フィールドは、当該セクションテーブルの長さを示すことができる。

【0562】

本発明の更に他の実施例に係る放送信号を伝送する方法は、シグナリングフォーマットフィールドが、リンク層ペイロードが含む複数個のシグナリング情報が複数個のデスクリプタであることを示すことができる。これは、複数個のデスクリプタが連結されてペイロードを構成する場合であり、前述したようにシグナリングフォーマットフィールドがこれを示すことができる。

【0563】

本発明の更に他の実施例に係る放送信号を伝送する方法は、リンク層ヘッダーが、複数個のペイロード長フィールドを含むペイロード長パートをさらに含むことができる。これらのペイロード長フィールドは、前述したペイロード長パート内の長さフィールドを意味できる。前述したように、各ペイロード長フィールドはそれぞれの複数個のシグナリング情報の長さを示すことができる。これは、リンク層パケットに含まれるシグナリング情報が、別途の長さフィールドがない場合に該当し得る。

【0564】

本発明の更に他の実施例に係る放送信号を伝送する方法は、リンク層ヘッダーにペイロード長パートがさらに含まれるか否かが、シグナリングフォーマットフィールドの値によって決定されてもよい。リンク層パケットに含まれるシグナリング情報が、別途の長さフィールドがない場合において、シグナリングフォーマットフィールドの値は１ｘに該当し得る。したがって、シグナリングフォーマットフィールドの値から、ペイロード長パートが存在するか否かが把握できる。

【0565】

本発明の更に他の実施例に係る放送信号を伝送する方法は、前述した分割が行われる場合に該当する方法であってもよい。この場合の放送信号を伝送する方法は、放送データをシグナリングするシグナリング情報を生成する段階、上記シグナリング情報を用いてリンク層パケット（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ）を生成する段階、上記リンク層パケットを用いて放送信号を生成する段階、及び／又は上記放送信号を伝送する段階を含むことができる。各段階は順に、第１モジュール、第２モジュール、第３モジュール、第３モジュールで行うことができる。

【0566】

この場合の放送信号を伝送する方法において、リンク層パケットは、リンク層ヘッダーとリンク層ペイロードを含み、リンク層ペイロードは、シグナリング情報が分割されたセグメントのうちの一つを含むことができる。リンク層ヘッダーは、パケットタイプフィールド、パケット構成フィールドを含み、パケットタイプフィールドは、リンク層ペイロードが含む情報がシグナリング情報であることを示すことができる。パケット構成フィールドは、リンク層ペイロードがシグナリング情報が分割されたセグメントのうちの一つを含むか否かを示すことができる。

【0567】

本発明の更に他の実施例に係る放送信号を伝送する方法は、リンク層ペイロードが含むセグメントが、分割されたセグメントのうち最初のセグメントである場合、リンク層ヘッダーがシグナリングクラスフィールド、情報タイプフィールド及びシグナリングフォーマットフィールドをさらに含むことができる。シグナリングクラスフィールドは、シグナリング情報がシグナリングする対象を示し、情報タイプフィールドは、シグナリング情報に関するデータを含み、シグナリングフォーマットフィールドは、シグナリング情報のフォーマットを示すことができる。シグナリングクラスフィールド、情報タイプフィールド及びシグナリングフォーマットフィールドは、前述したとおりである。

【0568】

これらの段階は、実施例によって省略してもよく、類似／同一の動作を行う別の段階に置き換えてもよい。

【0569】

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

【0570】

本発明の一実施例に係る放送信号を伝送する装置は、第１モジュールｔ７６０１０、第２モジュールｔ７６０２０及び／又は第３モジュールｔ７６０３０を含むことができる。

【0571】

第１モジュールｔ７６０１０は、複数個のシグナリング情報を生成することができる。第１モジュールは、前述した放送データをシグナリングする複数個のシグナリング情報を生成する段階に該当する過程を行うことができる。また、分割が行われる場合に関する実施例における第１モジュールは、前述した放送データをシグナリングするシグナリング情報を生成する段階に該当する過程を行うことができる。

【0572】

第２モジュールｔ７６０２０は、生成された複数個のシグナリング情報を用いてリンク層パケットを生成することができる。第２モジュールは、前述した複数個のシグナリング情報を用いてリンク層パケットを生成する段階に該当する過程を行うことができる。また、分割が行われる場合に関する実施例における第２モジュールは、前述したシグナリング情報を用いてリンク層パケット（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ）を生成する段階に該当する過程を行うことができる。

【0573】

第３モジュールｔ７６０３０は、生成されたリンク層パケットを用いて放送信号を生成することができる。また、第３モジュールは、生成された放送信号を伝送することができる。第３モジュールは、前述したリンク層パケットを用いて放送信号を生成する段階及び放送信号を伝送する段階に該当する動作を行うことができる。また、分割が行われる場合に関する実施例における第３モジュールは、前述したリンク層パケットを用いて放送信号を生成する段階及び放送信号を伝送する段階に該当する動作を行うことができる。

【0574】

前述した第１モジュール、第２モジュール、第３モジュールは、メモリ（又は、保存ユニット）に保存された連続した過程を実行するプロセッサであってもよい。また、前述した第１モジュール、第２モジュール、第３モジュールは、装置の内部／外部に位置するハードウェアエレメントであってもよい。

【0575】

これらのモジュールは、実施例によって省略してもよく、類似／同一の動作を行う別のモジュールに置き換えてもよい。

【0576】

図７７は、本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造を示す図である。

【0577】

本発明は、シグナリング情報をリンク層パケットを用いて伝送するためのリンク層パケット構造を提案する。この場合、前述したパケットタイプフィールドは１１０の値を有することができる。この構造を用いてシグナリング情報をリンク層でカプセル化することができる。

【0578】

同図の構造ｔ７７０１０において、パケットタイプフィールド（Ｐａｃｋｅｔ Ｔｙｐｅ）、ＰＣフィールド、ＬＩフィールド、セグメントＩＤフィールド（Ｓｅｇｍｅｎｔ ＩＤ）、セグメントシーケンスナンバーフィールド（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）、セグメント長ＩＤフィールド（Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ ＩＤ）、最後のセグメント長フィールド（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ）は、前述したとおりである。連結カウントフィールド（Ｃｏｎｃａｔｅｎａｔｉｏｎ Ｃｏｕｎｔ）は、前述したカウントフィールドと同一である。

【0579】

構造ｔ７７０１０におけるヘッダーは、Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）をさらに含むことができる。

【0580】

Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）は、シグナリング情報を送信するリンク層パケットにおいて追加されるフィールドの集合であってもよい。Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）は、リンク層ペイロードを構成しているシグナリング情報に関する具体的な情報を含むことができる。シグナリング情報がマルチプレクシングされて伝送される場合、当該シグナリング情報が処理されるか否かに対する決定と、それぞれのシグナリング情報がどのシグナリング処理モジュールに伝達されるべきかなどを決定するために、このフィールドを用いることができる。

【0581】

Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）は、リンク層ペイロードにシグナリング情報が含まれる場合に追加することができ、シグナリング情報のための追加ヘッダーと呼ぶこともできる。実施例によって、このパートはその内部に含まれるフィールドの構成が変更されてもよい。本実施例で、このパートは、１バイトのサイズを有するが、実施例によって別のサイズを有してもよい。実施例によって、複数個のシグナリング情報が連結されてペイロードに含まれる場合、カウントフィールドが示す数だけのＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）が追加されてもよい。

【0582】

リンク層ペイロードに複数個のシグナリング情報が連結されて含まれる場合、各シグナリング情報の長さを示すＳｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドが追加されてもよい。Ｓｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドは、連結されたシグナリング情報の個数だけ、すなわち、カウントフィールドが示す数だけ存在できる。各Ｓｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドは、それぞれのシグナリング情報の長さを示すことができる。ここで、ペイロードに含まれるシグナリング情報の順序と同じ順序でＳｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドが位置してもよい。Ｓｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドは、Ｃｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈフィールドと呼ぶことができ、構造ｔ７７０１０では、Ｓｉｇｎａｌｉｎｇ＿ＬｅｎｇｔｈフィールドがＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）の次に位置するが、この順序は逆転されてもよい。また、この実施例では、Ｓｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドが２バイトのサイズを有するが、これは、実施例によって変更されてもよく、バイト整列のためのパディングビットがさらに追加されてもよい。

【0583】

Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）は、様々に構成可能であるが、実施例として２の構造ｔ７７０２０，ｔ７７０３０を示す。本発明は、この実施例に限定されない。

【0584】

第一の構造ｔ７７０２０で、Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）は、シグナリングクラスフィールド（Ｓｉｇｎａｌｉｎｇ＿Ｃｌａｓｓ）及び／又はシグナリングフォーマットフィールド（Ｓｉｇｎａｌｉｎｇ＿Ｆｏｒｍａｔ）を含むことができる。シグナリング情報に対する別の属性（ａｔｔｒｉｂｕｔｅ）を示す必要がないか、又はシグナリング情報自体に該当情報を持っている場合に用いることができる。

【0585】

第二の構造ｔ７７０３０において、Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）は、シグナリングクラスフィールド、情報タイプフィールド（Ｉｎｆｏｒｍａｔｉｏｎ＿Ｔｙｐｅ）及び／又はシグナリングフォーマットフィールドを含むことができる。シグナリング情報に関するより具体的な情報を示すために、情報タイプフィールドが追加されてもよい。

【0586】

実施例によって、両構造に、当該シグナリング情報のバージョンを示すシグナリングバージョンフィールドがさらに含まれてもよい。また、実施例によって、両構造に、当該シグナリング情報のエンコーディング／圧縮フォーマットを示すシグナリングエンコーディングフィールドがさらに含まれてもよい。また、実施例によって、一つのシグナリングフォーマットのみが用いられたり、シグナリング情報のための別途のプロトコルが存在してシグナリングフォーマットがいずれも同一である場合、シグナリングフォーマットフィールドは省略されてもよい。上記の各実施例では各フィールドのビット数が決められているが、これは一実施例に過ぎず、そのビット数は変更されてもよい。

【0587】

シグナリングクラスフィールド、情報タイプフィールド、シグナリングフォーマットフィールドは、前述したとおりである。ここで、シグナリングクラスフィールドはＳｉｇｎａｌｉｎｇ＿Ｔｙｐｅフィールド、情報タイプフィールドはＳｉｇｎａｌｉｎｇ＿Ｔｙｐｅ＿Ｅｘｔｅｎｓｉｏｎフィールド、シグナリングフォーマットフィールドはＳｉｎｇｎａｌｉｎｇ＿Ｆｏｒｍａｔフィールドと呼ぶことができる。

【0588】

図７８は、本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合のＳｉｇｎａｌｉｎｇ＿Ｃｌａｓｓフィールドを示す図である。

【0589】

前述したシグナリングクラスフィールドの実施例による意味を示している。シグナリングクラスフィールドが４ビットである場合と３ビットである場合に、それぞれそのフィールドが示すシグナリング情報のタイプが指定されている。このフィールドが示すとおりに、リンク層ペイロードに含まれるシグナリング情報のタイプを示すことができる。このフィールド値の指定は、実施例によって変更されてもよい。

【0590】

シグナリングクラスフィールドが００００又は０００の値を有する場合、当該リンク層ペイロードは、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）などの速いチャネルスキャンのためのシグナリング情報を含むことができる。又は、当該リンク層ペイロードは、サービス取得（Ｓｅｒｖｉｃｅ Ａｃｑｕｉｓｉｔｉｏｎ）のためのシグナリング情報を含むことができる。

【0591】

シグナリングクラスフィールドが０００１又は００１の値を有する場合、当該リンク層ペイロードは、ＥＡＳ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｓｙｓｔｅｍ）などの緊急状況警報（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ）のためのシグナリング情報を含むことができる。

【0592】

シグナリングクラスフィールドが００１０又は０１０の値を有する場合、当該リンク層ペイロードは、ヘッダー圧縮に関連するシグナリング情報を含むことができる。

【0593】

シグナリングクラスフィールドが００１１−１１１０又は０１１−１１０の値を有する場合、当該リンク層ペイロードがいかなるシグナリング情報を有するかは、後の使用のために残すことができる（Ｒｅｓｅｒｖｅｄ ｆｏｒ ｆｕｔｕｒｅ ｕｓｅ）。これによって、後に追加可能なシグナリング情報を指定することができる。

【0594】

シグナリングクラスフィールドが１１１１又は１１１の値を有する場合、当該リンク層ペイロードは複数個のシグナリング情報を含むことができる。すなわち、特定シグナリング情報ではなく、種々のシグナリング情報が集まって一つのリンク層パケットとして伝送される場合、シグナリングクラスフィールドの特定値（１１１１又は１１１）で示すことができる。

【0595】

図７９は、本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合のＳｉｇｎａｌｉｎｇ＿Ｃｌａｓｓフィールド及びＩｎｆｏｒｍａｔｉｏｎ＿Ｔｙｐｅフィールドを示す図である。

【0596】

情報タイプフィールドがＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）に追加される場合、その情報タイプフィールドの値が有し得る意味を示している。本実施例は、シグナリングクラスフィールドと情報タイプフィールドがそれぞれ３ビットである場合を想定しているが、各フィールドの長さは、前述したように、実施例によって変更されてもよい。情報タイプフィールドが示すとおりに、リンク層ペイロードに含まれるシグナリング情報のタイプによる具体的情報を示すことができる。このフィールド値の指定は、実施例によって変更されてもよい。

【0597】

シグナリングクラスフィールドが０００の値を有する場合、当該リンク層ペイロードは、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）などの速いチャネルスキャンのためのシグナリング情報又はサービス取得（Ｓｅｒｖｉｃｅ Ａｃｑｕｉｓｉｔｉｏｎ）のためのシグナリング情報を含むことができる。このとき、情報タイプフィールドが０００の値を有する場合は当該シグナリング情報はサービススキャンのためのシグナリング情報、１１１の値を有する場合はサービス取得のためのシグナリング情報であることを示すことができる。情報タイプフィールドが０１０−１１１の値を有する場合は、後の使用のために残すことができる（Ｒｅｓｅｒｖｅｄ）。

【0598】

シグナリングクラスフィールドが００１の値を有する場合、当該リンク層ペイロードは、ＥＡＳ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｓｙｓｔｅｍ）などの緊急状況警報（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ）のためのシグナリング情報を含むことができる。このとき、情報タイプフィールドが０００の値を有する場合、当該シグナリング情報は緊急状況を知らせる緊急アラームメッセージ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｍｅｓｓａｇｅ）、００１の値を有する場合、当該シグナリング情報は緊急アラームメッセージのリンク情報、０１０の値を有する場合、当該シグナリング情報は自動チューニング情報、０１１の値を有する場合、当該シグナリング情報はＮＲＴサービス情報、１１１の値を有する場合、当該シグナリング情報は受信機を活性化させるウェークアップ（Ｗａｋｅ ｕｐ）指示情報であってもよい。情報タイプフィールドが１００−１１０の値を有する場合は、後の使用のために残すことができる（Ｒｅｓｅｒｖｅｄ）。

【0599】

シグナリングクラスフィールドが０１０の値を有する場合、当該リンク層ペイロードはヘッダー圧縮に関連したシグナリング情報を含むことができる。このとき、情報タイプフィールドが０００の値を有する場合、当該シグナリング情報は初期化情報、００１の値を有する場合、当該シグナリング情報は構成情報（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐａｒａｍｅｔｅｒｓ）、０１０の値を有する場合、当該シグナリング情報はスタティックチェーン（Ｓｔａｔｉｃ Ｃｈａｉｎ）、０１１の値を有する場合、当該シグナリング情報はダイナミックチェーン（Ｄｙｎａｍｉｃ Ｃｈａｉｎ）であってもよい。情報タイプフィールドが１００−１１１の値を有する場合は、後の使用のために残すことができる（Ｒｅｓｅｒｖｅｄ）。

【0600】

シグナリングクラスフィールドが０１１−１１０の値を有する場合、情報タイプフィールドの全ての値（０００−１１１）は、後の使用のために残すことができる（Ｒｅｓｅｒｖｅｄ ｆｏｒ ｆｕｔｕｒｅ ｕｓｅ）。これによって、後に追加可能なシグナリング情報を指定することができる。

【0601】

シグナリングクラスフィールドが１１１の値を有する場合、当該リンク層ペイロードは複数個のシグナリング情報を含むことができる。この場合、シグナリング情報に対する具体的属性も一つに決めることができず、０００のデフォルト値で示すことができる。余りの値（００１−１１１）は、後の使用のために残すことができる。

【0602】

図８０は、本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合のＳｉｇｎａｌｉｎｇ＿Ｆｏｒｍａｔフィールドを示す図である。

【0603】

シグナリングフォーマットフィールドの値によるシグナリングのフォーマットを示す。シグナリングフォーマットフィールドがそれぞれ４ビット、２ビットである場合を想定したが、前述したように、これは実施例によって変更されてもよい。シグナリングフォーマットフィールドの値によって当該シグナリング情報のフォーマットを示すことができる。このフィールド値の指定は、実施例によって変更されてもよい。

【0604】

当該シグナリング情報は、４ビットのシグナリングフォーマットフィールドが００００値を有するときＡＴＳＣシグナリングフォーマット、０００１値を有するときセクションテーブル、００１０値を有するときデスクリプタ、００１１値を有するときＸＭＬ、１１１１値を有するときその他（ｏｔｈｅｒ）のフォーマットを有することができる。シグナリングフォーマットフィールドが０１００−１１１０の値を有する場合は、後の使用のために残すことができる。

【0605】

当該シグナリング情報は、２ビットのシグナリングフォーマットフィールドが００値を有するときＡＴＳＣシグナリングフォーマット、０１値を有するときセクションテーブル、１０値を有するときデスクリプタ、１１値を有するときその他（ｏｔｈｅｒ）のフォーマットを有することができる。

【0606】

シグナリング情報のフォーマットによってＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）のフィールド間においてビット数が調整されてもよい。また、シグナリングフォーマットフィールドのビット数によって、後に拡張性を重視するか（多いビット数）、放送システムで実際に用いられるシグナリングフォーマットのみを指定するか（少ないビット数）が決定されてもよい。

【0607】

その他のフォーマット（Ｏｔｈｅｒ）は、前述したシグナリングクラスフィールドが「Ｍｕｌｔｉｐｌｅ ｓｉｇｎａｌｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ」の場合に用いることができる。すなわち、複数のシグナリングフォーマットが混合して連結されている場合、又は別途のシグナリングフォーマットの指定無しで、シグナリングをパーシングするモジュールで処理が可能な場合に用いることができる。

【0608】

図８１は、本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、複数個のシグナリング情報が連結された場合を示す図である。

【0609】

同図の構造は、前述したシグナリング情報に対するリンク層パケット構造のうち、複数個のシグナリング情報が連結された場合を具体的に示している。この構造で、ビット、バイトで表示された各フィールドのサイズは、実施例によって変更されてもよい。

【0610】

リンク層パケットのヘッダーには、前述したフィールドが位置すればよい。パケットタイプフィールドが、シグナリング情報がペイロードに含まれることを示し、パケット構成フィールドがペイロードの構成を示すことができる。カウントフィールドは、連結された複数個のシグナリング情報の個数（ｎ）を示すことができる。実施例によって、リンク層ペイロードの全体長を示す長さ情報パートがカウントフィールドの前にさらに位置してもよい。また、該当ペイロードが連結による構成であるか、分割による構成であるかを示す指示子がさらに位置してもよい。

【0611】

リンク層パケットのヘッダーは、前述したＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）を含むことができる。Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）は、前述したように様々な構造を有することができる（ｔ８１０１０，ｔ８１０２０）。受信機が当該リンク層パケットを受信すると、ヘッダーのＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）情報を用いて当該シグナリング情報を処理することができる。

【0612】

リンク層パケットのヘッダーは、連結されたそれぞれのシグナリング情報の長さを示すＳｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドをさらに含むことができる。Ｓｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドは、前述したとおりである。この構造では、Ｓｉｇｎａｌｉｎｇ＿ＬｅｎｇｔｈフィールドがＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）の次に位置しているが、この順序は逆転されてもよい。また、この実施例では、Ｓｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドが２バイトのサイズを有するか、これは実施例によって変更されてもよい。また、バイト整列のためのパディングビットがさらに追加されてもよい。

【0613】

Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）は、前述した実施例によって様々な構成を有することができる（ｔ８１０１０，ｔ８１０２０）。シグナリングクラスが異なる複数のシグナリング情報が一つのリンク層パケットで伝送される場合を仮定して説明する。

【0614】

この場合、シグナリングクラスフィールドは、１１１１又は１１１の値を有することができる。シグナリングフォーマットフィールドは、連結されているシグナリング情報のフォーマットを有することができる。例えば、当該リンク層パケットがＡＴＳＣシステムに適用されると、グナリングフォーマットフィールドは００００又は００の値を有することができる。情報タイプフィールドが存在する場合には、情報タイプフィールドは、デフォルト値である０００の値を有することができる。この場合、受信機では、この情報タイプフィールドの値を処理しなくてもよい。

【0615】

ヘッダーの先頭部におけるフィールドが１バイト、Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）が１バイト、Ｓｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドがそれぞれ２バイトである実施例であると仮定し、それぞれのシグナリング情報の長さをＬ_kとすれば（ｋ＝１，２，３，．．．，ｎ）、全体リンク層パケットの長さＬ_Tは、同図の数式のように表現することができる（ｔ８１０３０）。

【0616】

図８２は、本発明の更に他の実施例に係る、リンク層にシグナリング情報が伝達される場合におけるリンク層パケット構造において、複数個のシグナリング情報が連結された場合を示す図である。

【0617】

前述した複数個のシグナリング情報が連結された場合と同一であるが、本実施例は、それぞれのシグナリング情報に対するＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）とＳｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドが存在している。カウントフィールドが示す個数によって、続くＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）とＳｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドの個数を決定することができ、その順序は、連結された当該シグナリング情報の順序と同一にすることができる。実施例によって、それぞれのＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）が前部に集まって位置し、それぞれのＳｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドが後部に集まって位置してもよい。また、実施例によって、Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）とＳｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドの順序とが互いに変わってもよい。

【0618】

一対のＳｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）とＳｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドによって、それぞれのシグナリング情報に対する表現が可能である。受信機は、当該リンク層パケットを受信すると、各シグナリング情報を確認して、それぞれのシグナリング情報を個別に処理することができる。

【0619】

Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）は、前述した実施例によって様々な構成を有することができる（ｔ８２０１０，ｔ８２０２０）。シグナリングクラスが異なる複数のシグナリング情報が一つのリンク層パケットで伝送される場合を仮定して説明する。

【0620】

異なるシグナリング情報に対して個別の表示が可能な構造であるから、各シグナリング情報に対してシグナリングクラスフィールド、情報タイプフィールド、シグナリングフォーマットフィールドをそれぞれ指定することができる。このとき、シグナリングクラスフィールド値のうち「ｍｕｌｔｉｐｌｅ ｓｉｇｎａｌｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ」を示す値は用いられる必要がなく、該当値は他の意味に代えてもよい。

【0621】

ヘッダーの先頭部におけるフィールドが１バイト、Ｓｉｇｎａｌｉｎｇ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｐａｒｔ（）が１バイトであり、Ｓｉｇｎａｌｉｎｇ＿Ｌｅｎｇｔｈフィールドがそれぞれ２バイトである実施例であると仮定し、それぞれのシグナリング情報の長さをＬ_kとすれば（ｋ＝１，２，３，．．．，ｎ）、全体リンク層パケットの長さＬ_Tは、同図の数式のように表現することができる（ｔ８２０３０）。

【0622】

図８３は、本発明の更に他の実施例に係る、リンク層にフレームドパケットが伝達される場合におけるリンク層パケット構造を示す図である。

【0623】

本発明は、ＩＰ又はＭＰＥＧ−２ ＴＳなどの放送パケットではなく、一般的なネットワークで使われているイーサネット（Ｅｔｈｅｒｎｅｔ）パケットに対して、これをリンク層パケットを用いて伝送するためのリンク層パケット構造を提案する。また、当該イーサネットパケットに対するプロトコルタイプを表示する方案を提案する。この場合、前述したパケットタイプフィールドは１１１の値を有することができる。この構造を用いてイーサネットパケットをリンク層でカプセル化することができる。これらのイーサネットパケットを、フレームドパケットと呼ぶこともできる。

【0624】

同図の構造で、パケットタイプフィールド（Ｐａｃｋｅｔ Ｔｙｐｅ）、ＰＣフィールド、ＬＩフィールド、セグメントＩＤフィールド（Ｓｅｇｍｅｎｔ ＩＤ）、セグメントシーケンスナンバーフィールド（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）、セグメント長ＩＤフィールド（Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ ＩＤ）、最後のセグメント長フィールド（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ）は、前述したとおりである。連結カウントフィールド（Ｃｏｎｃａｔｅｎａｔｉｏｎ Ｃｏｕｎｔ）は、前述したカウント（Ｃｏｕｎｔ）フィールドと同一である。

【0625】

この構造のヘッダーは、イーサネットタイプ（Ｅｔｈｅｒｎｅｔ Ｔｙｐｅ）フィールドをさらに含むことができる。

【0626】

イーサネットタイプフィールドは、フレームドパケットを伝送するリンク層パケットにおいてさらに追加されるフィールドであってもよい。イーサネットタイプフィールドは、リンク層ペイロードを構成しているフレームドパケットのタイプ又はプロトコルに関する具体的な情報を含むことができる。ここで、プロトコルは、ＩＡＮＡに登録されている値を指定することができる。イーサネットタイプフィールドは、タイプエクステンションのための追加ヘッダーと呼ぶこともできる。本実施例で、このフィールドは２バイト又は変更可能な（ｖａｒｉａｂｌｅ）サイズを有することができる。

【0627】

実施例によって、複数個のフレームドパケットが連結されてペイロードに含まれる場合、カウントフィールドが示す数だけのイーサネットタイプフィールドが追加されてもよい。また、それぞれのフレームドパケットの長さを示す長さフィールドが、カウントフィールドが示す数だけ追加されてもよい。これらの長さフィールドの集合をペイロード長パート（Ｐａｙｌｏａｄ ｌｅｎｇｔｈ ｐａｒｔ）と呼ぶこともできる。

【0628】

ここで、ペイロードに含まれるフレームドパケットの順序と同一の順序で長さフィールドが位置してもよい。この長さフィールドは、Ｃｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈフィールドと呼ぶことができる。この構造では、長さフィールドがイーサネットタイプフィールドの次に位置するが、この順序は逆転されてもよい。また、実施例によって、長さフィールドは２バイトのサイズを有してもよく、他のサイズを有しもよい。また、バイト整列のためのパディングビットがさらに追加されてもよい。

【0629】

一つのフレームドパケットが分割される場合には、イーサネットタイプフィールドは最初のセグメントにのみ追加されてもよい。受信機で最初のセグメントのイーサネットタイプフィールド値を用いて元来のフレームドパケットに組み合わせることができるためである。

【0630】

図８４は、本発明の更に他の実施例に係る、リンク層にフレームドパケットが伝達される場合において、ｅｔｈｅｒｎｅｔ＿ｔｙｐｅフィールドを示す図である。

【0631】

前述したように、イーサネットタイプフィールドは、リンク層ペイロードを構成しているフレームドパケットのプロトコル又はタイプを示すことができる。同図の表は、主要プロトコルに対してＩＡＮＡで定義しているイーサネットタイプ値を示している。

【0632】

例えば、イーサネットタイプフィールドの値が０ｘ０８００の場合、フレームドパケットはＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ４（ＩＰｖ４）タイプのパケットであり、０ｘ０８０６の場合、Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＡＲＰ）タイプ、０ｘ０８４２の場合、Ｗａｋｅ−ｏｎ−ＬＡＮタイプである。イーサネットタイプフィールドが示すフレームドパケットのプロトコル又はタイプは様々に構成可能であり、本発明はこの実施例に限定されない。

【0633】

図８５は、本発明の更に他の実施例に係る、リンク層にフレームドパケットが伝達される場合において、一つのインプットパケットがリンク層ペイロードに含まれる場合を示す図である。

【0634】

入力されたフレームドパケットが物理層の処理範囲内にあることから、連結又は分割されないで一つのリンク層ペイロードをそのまま構成する場合を想定する。

【0635】

各フィールドは、前述したとおりである。この実施例で、パケットタイプフィールドは１１１、ＰＣフィールドは０の値を有することができる。カウントフィールドは００００の値を有することができる。実施例によって、一つのパケットがペイロードを構成する場合にはカウントフィールドが省略されてもよい。

【0636】

ヘッダーは、イーサネットタイプフィールド及び／又はペイロード長パートを含むことができる。実施例によって、これら両フィールドの順序は互いに変わってもよい。イーサネットタイプフィールドは、ペイロードに含まれたフレームドパケットのプロトコル又はタイプを示すことができる。ペイロード長パートは、一つの長さフィールドを含むことができ、フレームドパケットの長さ、すなわち、全体ペイロードの長さを示すことができる。

【0637】

実施例によって、各フィールドの長さは可変してもよいが、この実施例では５バイトがリンク層ヘッダーに使われているので、フレームドパケットの長さをＬバイトとすれば、全体リンク層パケットの長さはＬ＋５バイトとなる。

【0638】

図８６は、本発明の更に他の実施例に係る、リンク層にフレームドパケットが伝達される場合において、複数個のインプットパケットが連結されてリンク層ペイロードに含まれる場合を示す図である。

【0639】

入力されたフレームドパケットが物理層の処理範囲に到達していない場合、それぞれのフレームドパケットは連結されてリンク層ペイロードに含まれてもよい。

【0640】

各フィールドは、前述したとおりである。ここで、イーサネットタイプフィールドと長さフィールドの構成によって様々なリンク層ヘッダー構造が可能である。

【0641】

第一の構造（図示せず）は、同じイーサネットタイプを有するフレームドパケットが連結されてペイロードに含まれた場合の構造である。この場合、リンク層ヘッダーは１つのイーサネットタイプフィールドを含むことができる。このイーサネットタイプフィールドは、当該フレームドパケットのプロトコル／タイプを示すことができる。イーサネットタイプフィールドの前又は後に複数個の長さフィールドが位置してもよい。これらの長さフィールドは、それぞれの連結されたフレームドパケットの長さを示すことができる。

【0642】

第二の構造（ｔ８６０１０）は、それぞれ異なるイーサネットタイプを有するフレームドパケットが連結されてペイロードに含まれた場合の構造である。この場合、連結されたフレームドパケットの個数と同じ数のイーサネットタイプフィールドと長さフィールドをヘッダーに含むことができる。それぞれのイーサネットタイプフィールドと長さフィールドは順に、当該フレームドパケットのタイプと長さを示すことができる。ヘッダーの先頭部におけるフィールドが１バイト、イーサネットタイプフィールドがそれぞれ２バイトであり、長さフィールドがそれぞれ２バイトである実施例であると仮定し、それぞれのフレームドパケットの長さをＬ_kとすれば（ｋ＝１，２，３，．．．，ｎ）、全体リンク層パケットの長さＬ_Tは、同図の数式のように表現することができる（ｔ８６０２０）。

【0643】

第三の構造（ｔ８６０３０）は、それぞれ異なるイーサネットタイプを有するフレームドパケットが連結されてペイロードに含まれた場合の構造の他の実施例である。この場合も、連結されたフレームドパケットの個数と同じ数のイーサネットタイプフィールドと長さフィールドをヘッダーに含むことができる。ここで、それぞれのイーサネットタイプフィールドと長さフィールドは交互にヘッダーに位置してもよい。同図の構造では、フレームドパケット＃１に対するイーサネットタイプフィールド＃１と長さフィールド＃１とが対を成してヘッダーに含まれている。実施例によって、長さフィールドがイーサネットタイプフィールドの前に位置してもよい。各対の順序は、連結されたフレームドパケットの順序と同一にすることができる。

【0644】

図８７は、本発明の更に他の実施例に係る、リンク層にフレームドパケットが伝達される場合において、一つのインプットパケットが分割されてリンク層ペイロードに含まれる場合を示す図である。

【0645】

入力されたフレームドパケットが物理層の処理範囲を超える場合、一つのフレームドパケットが複数個のセグメントに分離されてもよい。各フィールドは、前述したとおりである。ＩＰパケットが分割される場合と同様に、フレームドパケットが分割される場合にもＣＲＣエンコーディングを活用することができる。フレームドパケットの最後にＣＲＣを追加することができる。このＣＲＣは、受信機がフレームドパケットを組み換える際、組み換えの完全性を確認するために用いることができる。ＣＲＣの追加されたフレームドパケットが分割される場合、最後のセグメントを含むリンク層パケットはＣＲＣも含むことができる。

【0646】

一般にＣＲＣはパケットの最後に追加されるが、実施例によって、他の位置に追加されてもよい。

【0647】

前述した実施例で、分割される場合、セグメント長ＩＤフィールド、最後のセグメント長フィールドの値によってリンク層ペイロードの長さを計算することができた。ただし、実施例によって、単にリンク層ヘッダーにリンク層ペイロードの長さを示すフィールドを置いてもよい。このような方法は、一つの入力パケットがペイロードに含まれる場合にも、連結される場合にも利用可能である。

【0648】

図８８は、本発明の一実施例に係る放送信号を伝送する方法を示す図である。

【0649】

本発明の一実施例に係る放送信号を伝送する方法は、放送データを含む複数個のインプットパケットを生成する段階、インプットパケットを用いてリンク層パケットを生成する段階、放送信号を生成する段階及び／又は放送信号を伝送する段階を含むことができる。

【0650】

まず、サービスプロバイダー側の第１モジュールは、複数個のインプットパケットを生成することができる（ｔ８８０１０）。ここで、複数個のインプットパケットはＭＰＥＧ２−ＴＳパケット、ＩＰパケット又は特定形態のパケットであってもよく、将来定義されて用いられるパケットであってもよい。第１モジュールは、放送データを生成し、これをインプットパケットの形態で生成する特定モジュールであってもよい。

【0651】

サービスプロバイダー側の第２モジュールは、複数個のインプットパケットを用いて少なくとも一つのリンク層パケット（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ）を生成することができる（ｔ８８０２０）。これは、前述したリンク層でインプットパケットをカプセル化してリンク層パケットが生成される過程に該当してもよい。ここで、リンク層パケットは、前述した実施例によるパケット構造を有することができる。

【0652】

本実施例で、リンク層パケットのヘッダーは、パケットタイプ情報及びパケット構成情報を含むことができる。パケットタイプ情報は、リンク層パケットのペイロードに含まれるインプットパケットのタイプを示し、パケット構成情報はリンク層パケットのペイロード構成を示すことができる。パケットタイプ情報は、前述したパケットタイプフィールド（Ｐａｃｋｅｔ＿Ｔｙｐｅ）に、パケット構成情報は前述したパケット構成フィールド（ＰＣ）に該当してもよい。

【0653】

サービスプロバイダー側の第３モジュールは、生成されたリンク層パケットを用いて放送信号を生成することができる（ｔ８８０３０）。これは、物理層でリンク層パケットを用いて各種インターリービング、フレーミングなどの動作が行われることに対応してもよい。サービスプロバイダー側の第４モジュールは、生成された放送信号を伝送することができる。ここで、第４モジュールはアンテナなどに該当してもよい。

【0654】

本発明の他の実施例に係る放送信号を伝送する方法は、ペイロードがインプットパケットの分割されたセグメントのうちの一つを含む場合、ヘッダーは、リンク層パケットに含まれるセグメントの当該インプットパケットにおける順序を示すセグメントシーケンスナンバー情報をさらに含むことができる。これは、前述した分割に該当する場合であってもよい。セグメントシーケンスナンバー情報は、前述したセグメントシーケンスナンバーフィールド（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）に該当してもよい。

【0655】

本発明の更に他の実施例に係る放送信号を伝送する方法において、ヘッダーは、リンク層パケットに含まれるセグメントが当該インプットパケットの最後のセグメントであるか否かを示す最後のセグメント指示子をさらに含むことができる。これは、前述した分割に該当する場合であってもよい。ここで、最後のセグメント指示子は、前述した最後のセグメント長フィールド（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ）に該当してもよい。

【0656】

本発明の更に他の実施例に係る放送信号を伝送する方法において、ペイロードが複数個のインプットパケットを含む場合、ヘッダーは、リンク層パケットに含まれるインプットパケットの個数を示すカウント情報をさらに含むことができる。これは、前述した連結に該当する場合であってもよい。ここで、カウント情報は、前述したカウントフィールドに該当してもよい。

【0657】

本発明の更に他の実施例に係る放送信号を伝送する方法において、ヘッダーは、リンク層パケットに含まれるそれぞれのインプットパケットの長さを示すコンポーネント長さ情報をさらに含むことができる。これは、前述した連結に該当する場合であってもよい。ここで、コンポーネント長さ情報は、前述したインプットパケットに対するそれぞれの長さフィールドに該当してもよい。

【0658】

本発明の更に他の実施例に係る放送信号を伝送する方法において、コンポーネント長情報は、当該インプットパケットがペイロードに位置する順序と同じ順序でヘッダーに位置してもよい。これは、前述した連結に該当する場合であってもよい。この実施例は、それぞれの長さフィールドが連結されたインプットパケットの順序と同じ順序で位置して、それぞれのインプットパケットの長さを示す場合に該当し得る。

【0659】

本発明の更に他の実施例に係る放送信号を伝送する方法において、複数個のインプットパケットは、放送データに対するシグナリングデータを含むことができる。この場合、ヘッダーは、シグナリングタイプ情報、シグナリングタイプ拡張情報及びシグナリングフォーマット情報をさらに含むことができる。シグナリングタイプ情報は、シグナリングデータのタイプを示し、シグナリングタイプ拡張情報は、シグナリングデータの属性を示し、シグナリングフォーマット情報は、シグナリングデータのフォーマットを示すことができる。この情報はそれぞれ、前述したシグナリングクラスフィールド、情報タイプフィールド、シグナリングフォーマットフィールドに該当してもよい。

【0660】

本発明の更に他の実施例に係る放送信号を伝送する方法において、ヘッダーのパケットタイプ情報は、リンク層パケットに含まれるインプットパケットが拡張パケットであることを示し、ヘッダーは、拡張パケットのプロトコル又はタイプを示す拡張タイプ情報をさらに含むことができる。これは、前述した実施例のうち、リンク層にフレームドパケットが伝達されるケースに該当してもよい。この場合、前述したパケットタイプフィールドは１１１の値を有することができる。ここで、拡張パケットは、前述したフレームドパケット又はイーサネットパケットであってもよい。ここで、拡張タイプ情報は、前述したイーサネットタイプフィールドに該当してもよい。

【0661】

本発明の更に他の実施例に係る放送信号を伝送する方法において、ペイロードは一つのインプットパケットを含み、ヘッダーは、リンク層パケットのペイロード長を示す長さ情報をさらに含むことができる。これは、前述したシングルパケット、すなわち、一つのインプットパケットが分割／連結無しでペイロードにそのまま含まれる場合に該当してもよい。ここで、長さ情報は、前述したペイロードの長さを示す長さフィールドに該当してもよい。

【0662】

本発明の一実施例に係る放送信号を受信する方法を説明する。この方法の図示は省略するものとする。

【0663】

本発明の一実施例に係る放送信号を受信する方法は、放送信号を受信する段階、放送信号のリンク層パケットを取得する段階及び／又はリンク層パケットを用いてアウトプットパケットを生成する段階を含むことができる。

【0664】

まず、受信機側の第１モジュールは、放送信号を受信することができる。この放送信号は、サービスプロバイダー側で前述の実施例によって送信した放送信号であってもよい。第１モジュールはアンテナ又はチューナーなどの受信装置であってもよい。

【0665】

受信機側の第２モジュールは、受信した放送信号を用いてリンク層パケットを取得すことができる。リンク層パケットは、前述したとおりである。この過程は、受信機側の物理層で放送信号を処理してアウトプットストリームをリンク層に出力する過程に該当し得る。

【0666】

その後、受信機側の第３モジュールは、リンク層パケットを処理してアウトプットパケットを生成することができる。ここで、アウトプットパケットは、サービスプロバイダー側でリンク層に伝達されたインプットパケットに該当してもよい。この過程で、リンク層パケットにカプセル化されていたパケットを復旧することができる。この過程は、前述した「インプットパケットを用いてリンク層パケットを生成する段階」の逆過程に該当し得る。

【0667】

本発明の一実施例に係る放送信号を受信する方法及びこの方法の他の実施例において、リンク層パケットは、前述した構造／情報を有することができる。すなわち、前述したサービスプロバイダー側の実施例で説明したリンク層パケット構造又はそれに含まれるフィールド／情報は、放送信号を受信する方法の実施例にも同様に適用可能である。

【0668】

これらの段階は、実施例によって省略されてもよく、類似／同一の動作を行う別の段階に置き換えてもよい。

【0669】

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

【0670】

本発明の一実施例に係る放送信号を伝送する装置は、前述した第１モジュール、第２モジュール、第３モジュール及び／又は第４モジュールを含むことができる。各モジュールは、前述したとおりである。

【0671】

本発明の一実施例に係る放送信号を伝送する装置及びその内部モジュール／ブロックは、前述した本発明の放送信号を伝送する方法の実施例を行うことができる。

【0672】

本発明の一実施例に係る放送信号を受信する装置を説明する。本発明の一実施例に係る放送信号を受信する装置は、図示を省略するものとする。

【0673】

本発明の一実施例に係る放送コンテンツを受信する装置は、前述した第１モジュール、第２モジュール及び／又は第３モジュールを含むことができる。各モジュールは、前述したとおりである。

【0674】

本発明の一実施例に係る放送信号を受信する装置及びその内部モジュール／ブロックは、前述した本発明の放送信号を受信する方法の実施例を行うことができる。

【0675】

前述した放送信号を伝送する装置及び放送信号を受信する装置内部のブロック／モジュールなどは、メモリに保存された連続した過程を実行するプロセッサであってもよく、実施例によって装置の内部／外部に位置するハードウェアエレメントであってもよい。

【0676】

前述したモジュールは、実施例によって省略してもよく、類似／同一の動作を行う他のモジュールに代えてもよい。

【0677】

モジュール又はユニットは、メモリ（又は、保存ユニット）に記憶された連続した過程を実行するプロセッサであってもよい。前述した実施例に記述された各段階は、ハードウェア／プロセッサによって実行することができる。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明が提示する方法はコードとして具現されるようにするこができる。このコードは、プロセッサが読み出し可能な記憶媒体に書き込まれ、装置（ａｐｐａｒａｔｕｓ）が提供するプロセッサによって読み出されるようにすることができる。

【0678】

説明の便宜のために、各図を個別に説明したが、各図に開示した実施例を組み合わせて新しい実施例として具現するように設計することも可能である。そして、通常の技術者の必要に応じて、以前に説明された実施例を実行するためのプログラムが記録されているコンピュータで読み出し可能な記録媒体を設計することも、本発明の権利範囲に属する。

【0679】

本発明に係る装置及び方法は、上述したように、説明された実施例の構成と方法に限定されず、上述した実施例は様々な変形が可能である。したがって、各実施例の全て又は一部を選択的に組み合わせて他の実施例を構成してもよい。

【0680】

一方、本発明が提案する方法を、ネットワークデバイスに具備された、プロセッサが読み出し可能な記録媒体に、プロセッサが読み出し可能なコードとして具現することができる。プロセッサが読み出し可能な記録媒体は、プロセッサによって読み出されるデータが記憶されるいずれの種類の記録装置をも含む。プロセッサが読み出し可能な記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されてもよい。また、プロセッサが読み出し可能な記録媒体は、ネットワークに接続しているコンピュータシステムに分散されて、分散方式でプロセッサが読み出し可能なコードが記憶されて実行されてもよい。

【0681】

以上、本発明の好適な実施例について図示及び説明してきたが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨から逸脱することなく、当該発明の属する技術の分野における通常の知識を有する者にとって様々な変形実施が可能であることは無論であり、これらの変形実施は、本発明の技術的思想や展望から分離して理解してはならない。

【0682】

そして、当該明細書では物の発明、方法の発明の両方が説明されており、必要によって、両発明の説明は補充的に適用されてもよい。

【0683】

本発明の思想や範囲内で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むように意図される。

【0684】

本明細書で、装置の方法も方法の発明も言及されており、装置及び方法の発明に関する説明は互いに補完して適用可能である。

【0685】

様々な実施例が、本発明を実施するための形態において説明されている。

【産業上の利用可能性】

【0686】

本発明は、放送信号伝送方法、放送信号受信方法、放送信号伝送装置、放送信号受信装置に関連した一連の産業分野で産業上利用可能性を有する。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】

【図49】

【図50】

【図51】

【図52】

【図53】

【図54】

【図55】

【図56】

【図57】

【図58】

【図59】

【図60】

【図61】

【図62】

【図63】

【図64】

【図65】

【図66】

【図67】

【図68】

【図69】

【図70】

【図71】

【図72】

【図73】

【図74】

【図75】

【図76】

【図77】

【図78】

【図79】

【図80】

【図81】

【図82】

【図83】

【図84】

【図85】

【図86】

【図87】

【図88】

【図89】