JP6359680B2 - 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 - Google Patents

放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 Download PDF

Info

Publication number
JP6359680B2
JP6359680B2 JP2016555440A JP2016555440A JP6359680B2 JP 6359680 B2 JP6359680 B2 JP 6359680B2 JP 2016555440 A JP2016555440 A JP 2016555440A JP 2016555440 A JP2016555440 A JP 2016555440A JP 6359680 B2 JP6359680 B2 JP 6359680B2
Authority
JP
Japan
Prior art keywords
packet
link layer
information
header
field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016555440A
Other languages
English (en)
Other versions
JP2017505080A (ja
Inventor
ウソク クォン
ウソク クォン
ミンソン カク
ミンソン カク
セチン オ
セチン オ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of JP2017505080A publication Critical patent/JP2017505080A/ja
Application granted granted Critical
Publication of JP6359680B2 publication Critical patent/JP6359680B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/02—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information
    • H04H60/07—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information characterised by processes or methods for the generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056—Systems characterized by the type of code used
    • H04L1/0071—Use of interleaving
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0072—Error control for data other than payload data, e.g. control data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、放送信号送信装置、放送信号受信装置、及び放送信号送受信方法に関する。
アナログ放送信号の送信が終了するに伴い、デジタル放送信号を送受信するための様々な技術が開発されている。デジタル放送信号は、アナログ放送信号に比べてさらに多くの量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータだけでなく、様々な種類の付加データをさらに含むことができる。
すなわち、デジタル放送システムは、ＨＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）イメージ、マルチチャンネル（ｍｕｌｔｉ ｃｈａｎｎｅｌ、多チャンネル）オーディオ、及び様々な付加サービスを提供することができる。しかし、デジタル放送のためには、大量のデータ伝送に対するデータ伝送効率、送受信ネットワークのロバスト性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装置を考慮したネットワーク柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を向上させなければならない。
本発明の目的によって、ここに含まれて概略的に記載されたように、本発明は、地上波放送網とインターネット網を使用する次世代ハイブリッド放送を支援する環境で、次世代放送サービスを効果的に支援することができるシステム及び関連するシグナリング方案を提案する。
本発明は、サービスの特性に応じてデータを処理して各サービスまたはサービスコンポーネントに対するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を制御することによって、様々な放送サービスを提供することができる。
本発明は、同一のＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）信号帯域幅を介して様々な放送サービスを伝送することによって伝送柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を達成することができる。
本発明によれば、モバイル受信装置を使用したり室内環境にいても、エラーなしにデジタル放送信号を受信可能な放送信号送信及び受信方法及び装置を提供することができる。
本発明は、地上波放送網とインターネット網を使用する次世代ハイブリッド放送を支援する環境で次世代放送サービスを効果的に支援することができる。
本発明のさらなる理解のために含まれ、本出願に含まれ、その一部を構成する添付の図面は、本発明の原理を説明する詳細な説明と共に本発明の実施例を示す。
本発明の一実施例に係る受信機プロトコルスタック（ｒｅｃｅｉｖｅｒ ｐｒｏｔｏｃｏｌ ｓｔａｃｋ）を示した図である。 本発明の一実施例に係るＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）の関係を示した図である。 本発明の一実施例に係るＳＬＴを示した図である。 本発明の一実施例に係るＳＬＳブートストラッピング及びサービスディスカバリー過程を示した図である。 本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示した図である。 本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示した図である。 本発明の一実施例に係るＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示した図である。 本発明の一実施例に係るリンクレイヤプロトコルアーキテクチャーを示した図である。 本発明の一実施例に係るリンクレイヤパケットのベースヘッダーの構造を示した図である。 本発明の一実施例に係るリンクレイヤパケットの追加ヘッダーの構造を示した図である。 本発明の他の実施例に係るリンクレイヤパケットの追加ヘッダーの構造を示した図である。 本発明の一実施例に係る、ＭＰＥＧ−２ ＴＳパケットのためのリンクレイヤパケットのヘッダー構造、及びそのエンカプセレーション過程を示した図である。 本発明の一実施例に係るＩＰヘッダー圧縮において、アダプテーションモードの実施例を示した図である（送信側）。 本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ Ｍａｐｐｉｎｇ Ｔａｂｌｅ）及びＲＯＨＣ−Ｕディスクリプションテーブルを示した図である。 本発明の一実施例に係る送信機側のリンクレイヤの構造を示した図である。 本発明の一実施例に係る受信機側のリンクレイヤの構造を示した図である。 本発明の一実施例に係る、リンクレイヤを介したシグナリング伝送構造を示した図である（送／受信側）。 本発明の一実施例に係るリンクレイヤ（ｌｉｎｋ ｌａｙｅｒ）のインターフェースを示した図である。 本発明の一実施例に係るリンクレイヤの動作モードのうち、ノーマル（Ｎｏｒｍａｌ）モードの動作ダイヤグラムを示した図である。 本発明の一実施例に係るリンクレイヤの動作モードのうち、トランスペアレント（Ｔｒａｎｓｐａｒｅｎｔ）モードの動作ダイヤグラムを示した図である。 本発明の一実施例に係る、リンクレイヤでの送信機及び／又は受信機の動作モードをコントロール（ｃｏｎｔｒｏｌ）する過程を示した図である。 本発明の一実施例に係る、フラグ（ｆｌａｇ）の値によるリンクレイヤでの動作及びフィジカルレイヤ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）に伝達されるパケットの形態を示した図である。 本発明の一実施例に係る送受信機でのＩＰオーバーヘッドリダクション（ＩＰ ｏｖｅｒｈｅａｄ ｒｅｄｕｃｔｉｏｎ）過程を示した図である。 本発明の一実施例に係る、ＲｏＨＣのプロファイル（Ｐｒｏｆｉｌｅｓ）を示した図である。 本発明の一実施例に係る第１構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅ ＃１）に対してＲｏＨＣパケットストリームの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び復元（ｒｅｃｏｖｅｒｙ）過程を示した図である。 本発明の一実施例に係る第２構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅ ＃２）に対してＲｏＨＣパケットストリームの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び復元（ｒｅｃｏｖｅｒｙ）過程を示した図である。 本発明の一実施例に係る第３構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅ ＃３）に対してＲｏＨＣパケットストリームの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び復元（ｒｅｃｏｖｅｒｙ）過程を示した図である。 本発明の一実施例に係る帯域外（Ｏｕｔ ｏｆ Ｂａｎｄ）で伝達できる情報の組み合わせを示した図である。 本発明の一実施例に係る、データパイプ（ｄａｔａ ｐｉｐｅ）を介して伝送されるパケットを示した図である。 本発明の一実施例に係る、リンクレイヤパケット構造のシンタックスを示した図である。 本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーの構造を示した図である。 前述した本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーの構造のシンタックスを示した図である。 本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーにおいて、各フィールドの値が示すものを示した図である。 本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーにおいて、一つのＩＰパケットがリンクレイヤペイロードに含まれる場合を示した図である。 本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーにおいて、複数個のＩＰパケットが連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）してリンクレイヤペイロードに含まれる場合を示した図である。 本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーにおいて、一つのＩＰパケットが分割（ｓｅｇｍｅｎｔａｔｉｏｎ）されてリンクレイヤペイロードに含まれる場合を示した図である。 本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーにおいて、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）されたセグメントを有するリンクレイヤパケットを示した図である。 本発明の一実施例に係るＲｏＨＣ伝送のためのリンクレイヤパケット（ｌｉｎｋ ｌａｙｅｒ ｐａｃｋｅｔ）のヘッダーを示した図である。 本発明の一実施例に係るＲｏＨＣ伝送のためのリンクレイヤパケット（ｌｉｎｋ ｌａｙｅｒ ｐａｃｋｅｔ）のヘッダーのシンタックスを示した図である。 本発明に係る、リンクレイヤパケットを介したＲｏＨＣパケット伝送方法の実施例＃１を示した図である。 本発明に係る、リンクレイヤパケットを介したＲｏＨＣパケット伝送方法の実施例＃２を示した図である。 本発明に係る、リンクレイヤパケットを介したＲｏＨＣパケット伝送方法の実施例＃３を示した図である。 本発明に係る、リンクレイヤパケットを介したＲｏＨＣパケット伝送方法の実施例＃４を示した図である。 本発明の他の実施例に係る、リンクレイヤにシグナリング情報が伝達される場合のリンクレイヤパケットの構造を示した図である。 前述した本発明の他の実施例に係るリンクレイヤにシグナリング情報が伝達される場合のリンクレイヤパケットの構造において、そのシンタックスを示した図である。 本発明の一実施例に係るフレームドパケット（ｆｒａｍｅｄ ｐａｃｋｅｔ）伝送のためのリンクレイヤパケットの構造を示した図である。 前述した本発明の一実施例に係るフレームドパケット伝送のためのリンクレイヤパケットの構造において、そのシンタックスを示した図である。 本発明の一実施例に係るフレームドパケットのシンタックス（ｓｙｎｔａｘ）を示した図である。 本発明の一実施例に係るＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）のシンタックス（ｓｙｎｔａｘ）を示した図である。 本発明の一実施例に係る、非常警報を行う放送システムを示した図である。 本発明の一実施例に係る、ＥＡＴ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｔａｂｌｅ）のシンタックス（ｓｙｎｔａｘ）を示した図である。 本発明の一実施例に係る、リンクレイヤパケットのペイロードに含まれる、ヘッダー圧縮と関連する情報を識別する方法を示した図である。 本発明の一実施例に係る、初期化情報を示した図である。 本発明の一実施例に係る、構成パラメータを示した図である。 本発明の一実施例に係る、スタティックチェーン情報を示した図である。 本発明の一実施例に係る、ダイナミックチェーン情報を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のシンタックスを示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、完全な一つのインプットパケットがリンクレイヤペイロードに含まれた場合を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を、図表で示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、複数個のインプットパケットが連鎖してリンクレイヤペイロードに含まれた場合を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、完全な一つのインプットパケットがリンクレイヤペイロードに含まれた場合を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、そのヘッダーの長さを図表で示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、複数個のインプットパケットが連鎖してリンクレイヤペイロードに含まれた場合を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、複数個のインプットパケットが連鎖してリンクレイヤペイロードに含まれた場合を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、ワード（ｗｏｒｄ）単位の長さ表示を使用する場合におけるリンクレイヤパケットの構造を示した図である。 本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、ワード（ｗｏｒｄ）単位の長さ表示を使用する場合をインプットパケットの数に応じて図表で示した図である。 本発明の一実施例に係る放送信号を送信する方法を示した図である。 本発明の一実施例に係る放送信号を送信する装置を示した図である。
本発明の好ましい実施例について具体的に説明し、その例は添付の図面に示す。添付の図面を参照した以下の詳細な説明は、本発明の実施例によって具現可能な実施例のみを示すためのものではなく、本発明の好ましい実施例を説明するためのものである。以下の詳細な説明は、本発明に対する徹底した理解を提供するために詳細を含む。しかし、本発明がこのような詳細なしにも実行可能であるということは当業者に自明である。
本発明で使用されるほとんどの用語は、当該分野で広く使用される一般的な用語から選択されるが、一部の用語は出願人によって任意に選択され、その意味は、必要に応じて以下の説明で詳細に記載する。したがって、本発明は、用語の単純な名称や意味ではなく、用語の意図された意味に基づいて理解されなければならない。
本発明は、次世代放送サービスに対する放送信号送信及び受信装置及び方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）またはＭＩＭＯ方式で次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）方式などを含むことができる。
図１は、本発明の一実施例に係る受信機プロトコルスタック（ｒｅｃｅｉｖｅｒ ｐｒｏｔｏｃｏｌ ｓｔａｃｋ）を示した図である。
放送網を介したサービスデリバリー（ｂｒｏａｄｃａｓｔ ｓｅｒｖｉｃｅ ｄｅｌｉｖｅｒｙ）において、２つの方法があり得る。
第一の方法は、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）に基づいて、ＭＰＵ（Ｍｅｄｉａ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔｓ）をＭＭＴＰ（ＭＭＴ ｐｒｏｔｏｃｏｌ）を用いて伝送することである。第二の方法は、ＭＰＥＧ ＤＡＳＨに基づいて、ＤＡＳＨセグメントをＲＯＵＴＥ（Ｒｅａｌ ｔｉｍｅ Ｏｂｊｅｃｔ ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）を用いて伝送することである。
ＮＲＴメディア、ＥＰＧデータ、及び他のファイルを含む非時間コンテンツは、ＲＯＵＴＥで伝達される。シグナルは、ＭＭＴＰ及び／又はＲＯＵＴＥを介して伝達できる一方、ブートストラップシグナリング情報はＳＬＴ（ｓｅｒｖｉｃｅ ｌｉｓｔ ｔａｂｌｅ）によって提供される。
ハイブリッドサービスデリバリー（ｈｙｂｒｉｄ ｓｅｒｖｉｃｅ ｄｅｌｉｖｅｒｙ）においては、ＨＴＴＰ／ＴＣＰ／ＩＰ上のＭＰＥＧ ＤＡＳＨがブロードバンド側で用いられる。ＩＳＯ ＢＭＦＦ（ｂａｓｅ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔ）のメディアファイルは、デリバリー、ブロードキャスト及びブロードバンドデリバリーに対するメディアエンカプセレーション及び同期化フォーマットとして使用される。ここで、ハイブリッドサービスデリバリーとは、１つまたはそれ以上のプログラムエレメントがブロードバンドパス（ｐａｔｈ）を介して伝達される場合のことをいえる。
サービスは、３つの機能レイヤを用いて伝達される。これらは、フィジカルレイヤ、デリバリーレイヤ、サービスマネジメントレイヤである。フィジカルレイヤは、シグナル、サービス公知、ＩＰパケットストリームがブロードキャストフィジカルレイヤ及び／又はブロードバンドフィジカルレイヤで伝送されるメカニズムを提供する。デリバリーレイヤは、オブジェクト及びオブジェクトフロートランスポート機能を提供する。これは、ブロードキャストフィジカルレイヤのＵＤＰ／ＩＰマルチキャストで動作するＭＭＴＰまたはＲＯＵＴＥプロトコルによって可能であり、ブロードバンドフィジカルレイヤのＴＣＰ／ＩＰユニキャストでＨＴＴＰプロトコルによって可能である。サービスマネジメントレイヤは、下位であるデリバリー及びフィジカルレイヤによって実行されるリニアＴＶまたはＨＴＭＬ５応用サービスのような全てのサービスを可能にする。
本図において、放送（ｂｒｏａｄｃａｓｔ）側のプロトコルスタック部分は、ＳＬＴとＭＭＴＰを介して伝送される部分、ＲＯＵＴＥを介して伝送される部分とに分けられる。
ＳＬＴは、ＵＤＰ、ＩＰレイヤを経てエンカプセレーションされてもよい。ここで、ＳＬＴについては後述する。ＭＭＴＰは、ＭＭＴで定義されるＭＰＵフォーマットでフォーマットされたデータ、及びＭＭＴＰによるシグナリング情報を伝送することができる。これらデータは、ＵＤＰ、ＩＰレイヤを経てエンカプセレーションされてもよい。ＲＯＵＴＥは、ＤＡＳＨセグメントの形態でフォーマットされたデータとシグナリング情報、そして、ＮＲＴなどのノンタイムド（ｎｏｎ ｔｉｍｅｄ）データを伝送することができる。これらデータも、ＵＤＰ、ＩＰレイヤを経てエンカプセレーションされてもよい。実施例によって、ＵＤＰ、ＩＰレイヤによるプロセシングは一部又は全部省略されてもよい。ここで、図示されたシグナリング情報（ｓｉｇｎａｌｉｎｇ）は、サービスに関するシグナリング情報であり得る。
ＳＬＴとＭＭＴＰを介して伝送される部分、ＲＯＵＴＥを介して伝送される部分は、ＵＤＰ、ＩＰレイヤで処理された後、リンクレイヤ（Ｄａｔａ Ｌｉｎｋ Ｌａｙｅｒ）で再びエンカプセレーションされてもよい。リンクレイヤについては後述する。リンクレイヤで処理された放送データは、フィジカルレイヤでエンコーディング／インターリービングなどの過程を経て放送信号としてマルチキャストされてもよい。
本図において、ブロードバンド（ｂｒｏａｄｂａｎｄ）側のプロトコルスタック部分は、前述したように、ＨＴＴＰを介して伝送されてもよい。ＤＡＳＨセグメントの形態でフォーマットされたデータとシグナリング情報、ＮＲＴなどの情報がＨＴＴＰを介して伝送されてもよい。ここで、図示されたシグナリング情報（ｓｉｇｎａｌｉｎｇ）は、サービスに関するシグナリング情報であってもよい。このデータは、ＴＣＰ、ＩＰレイヤを経てプロセシングされた後、リンクレイヤでエンカプセレーションされてもよい。実施例によって、ＴＣＰ、ＩＰ、リンクレイヤの一部又は全部は省略されてもよい。この後、処理されたブロードバンドデータは、フィジカルレイヤで伝送のための処理を経てブロードバンドにユニキャストされてもよい。
サービスは、全体的にユーザに見せるメディアコンポーネントのコレクションであってもよく、コンポーネントは、種々のメディアタイプのものであってもよく、サービスは、連続的または間欠的であってもよく、サービスは、リアルタイムまたは非リアルタイムであってもよく、リアルタイムサービスはＴＶプログラムのシーケンスで構成されてもよい。
図２は、本発明の一実施例に係るＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）の関係を示した図である。
サービスシグナリングは、サービスディスカバリー及びディスクリプション情報を提供し、２つの機能コンポーネントを含む。これらは、ＳＬＴを介したブートストラップシグナリングとＳＬＳである。これらは、ユーザサービスを発見し、獲得するのに必要な情報を示す。ＳＬＴは、受信機が、基本サービスリストを作成し、各サービスに対するＳＬＳの発見をブートストラップできるようにする。
ＳＬＴは、基本サービス情報の非常に速い獲得を可能にする。ＳＬＳは、受信機が、サービスとそのコンテンツコンポーネントを発見し、これに接続できるようにする。ＳＬＴとＳＬＳの具体的な内容については後述する。
前述したように、ＳＬＴは、ＵＤＰ／ＩＰを介して伝送され得る。このとき、実施例によって、この伝送において最もロバストな（ｒｏｂｕｓｔ）方法を通じて、ＳＬＴに該当するデータが伝達されてもよい。
ＳＬＴは、ＲＯＵＴＥプロトコルによって伝達されるＳＬＳに接近するためのアクセス情報を有することができる。すなわち、ＳＬＴは、ＲＯＵＴＥプロトコルによるＳＬＳにブートストラッピングすることができる。このＳＬＳは、前述したプロトコルスタックにおいてＲＯＵＴＥの上位レイヤに位置するシグナリング情報であって、ＲＯＵＴＥ／ＵＤＰ／ＩＰを介して伝達され得る。このＳＬＳは、ＲＯＵＴＥセッションに含まれるＬＣＴセッションのうち１つを介して伝達され得る。このＳＬＳを用いて、所望のサービスに該当するサービスコンポーネントに接近することができる。
また、ＳＬＴは、ＭＭＴＰによって伝達されるＭＭＴシグナリングコンポーネントに接近するためのアクセス情報を有することができる。すなわち、ＳＬＴは、ＭＭＴＰによるＳＬＳにブートストラッピングすることができる。このＳＬＳは、ＭＭＴで定義するＭＭＴＰシグナリングメッセージ（Ｓｉｇｎａｌｉｎｇ Ｍｅｓｓａｇｅ）によって伝達され得る。このＳＬＳを用いて、所望のサービスに該当するストリーミングサービスコンポーネント（ＭＰＵ）に接近することができる。前述したように、本発明では、ＮＲＴサービスコンポーネントは、ＲＯＵＴＥプロトコルを介して伝達され、ＭＭＴＰによるＳＬＳは、これに接近するための情報も含むことができる。ブロードバンドデリバリーにおいて、ＳＬＳはＨＴＴＰ（Ｓ）／ＴＣＰ／ＩＰで伝達される。
図３は、本発明の一実施例に係るＳＬＴを示した図である。
まず、サービスマネジメント、デリバリー、フィジカルレイヤの各論理的エンティティー間の関係について説明する。
サービスは、２つの基本タイプのうち１つとしてシグナリングされ得る。第一のタイプは、アプリベースのエンハンスメントを有し得るリニアオーディオ／ビデオまたはオーディオのみのサービスである。第二のタイプは、プレゼンテーション及び構成が、サービスの獲得によって実行されるダウンロードアプリケーションによって制御されるサービスである。後者は、アプリベースのサービスと呼ぶこともできる。
サービスのコンテンツコンポーネントを伝達するＭＭＴＰセッション及び／又はＲＯＵＴＥ／ＬＣＴセッションの存在と関連する規則は、次の通りである。
アプリベースのエンハンスメントがないリニアサービスのブロードキャストデリバリーのために、サービスのコンテンツコンポーネントは、（１）１つ以上のＲＯＵＴＥ／ＬＣＴセッション、または（２）１つ以上のＭＭＴＰセッションのうち１つ（両方ともではない）によって伝達され得る。
アプリベースのエンハンスメントがあるリニアサービスのブロードキャストデリバリーのために、サービスのコンテンツコンポーネントは、（１）１つ以上のＲＯＵＴＥ／ＬＣＴセッション、及び（２）０個以上のＭＭＴＰセッションによって伝達され得る。
特定の実施例において、同一のサービスでストリーミングメディアコンポーネントに対するＭＭＴＰ及びＲＯＵＴＥの両者の使用が許容されないことがある。
アプリベースのサービスのブロードキャストデリバリーのために、サービスのコンテンツコンポーネントは１つ以上のＲＯＵＴＥ／ＬＣＴセッションによって伝達され得る。
それぞれのＲＯＵＴＥセッションは、サービスを構成するコンテンツコンポーネントを全体的又は部分的に伝達する１つ以上のＬＣＴセッションを含む。ストリーミングサービスデリバリーにおいて、ＬＣＴセッションは、オーディオ、ビデオ、またはクローズドキャプションストリームのようなユーザサービスの個別コンポーネントを伝達することができる。ストリーミングメディアは、ＤＡＳＨセグメントとしてフォーマットされる。
それぞれのＭＭＴＰセッションは、ＭＭＴシグナリングメッセージまたは全体又は一部のコンテンツコンポーネントを伝達する、１つ以上のＭＭＴＰパケットフローを含む。ＭＭＴＰパケットフローは、ＭＭＴシグナリングメッセージ、またはＭＰＵとしてフォーマットされたコンポーネントを伝達することができる。
ＮＲＴユーザサービスまたはシステムメタデータのデリバリーのために、ＬＣＴセッションは、ファイルベースのコンテンツアイテムを伝達する。これらコンテンツファイルは、ＮＲＴサービスの連続的（タイムド）又は離散的（ノンタイムド）メディアコンポーネント、またはサービスシグナリングやＥＳＧフラグメントのようなメタデータで構成され得る。サービスシグナリングやＥＳＧフラグメントのようなシステムメタデータのデリバリーも、ＭＭＴＰのシグナリングメッセージモードを通じて行われてもよい。
ブロードキャストストリームは、特定の帯域内に集中したキャリア周波数の観点で定義されたＲＦチャンネルの概念である。それは、［地理的領域、周波数］ペアによって識別される。ＰＬＰ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｉｐｅ）は、ＲＦチャンネルの一部に該当する。各ＰＬＰは、特定のモジュレーション及びコーディングパラメータを有する。それは、属しているブロードキャストストリーム内で唯一のＰＬＰＩＤ（ＰＬＰ ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ここで、ＰＬＰはＤＰ（ｄａｔａ ｐｉｐｅ）と呼ぶこともできる。
各サービスは、２つの形態のサービス識別子によって識別される。一方は、ＳＬＴで使用され、ブロードキャスト領域内でのみ唯一のコンパックな形態であり、他方は、ＳＬＳ及びＥＳＧで使用される全世界的に唯一の形態である。ＲＯＵＴＥセッションは、ソースＩＰアドレス、デスティネーションＩＰアドレス、デスティネーションポートナンバーによって識別される。ＬＣＴセッション（それが伝達するサービスコンポーネントと関連する）は、ペアレントＲＯＵＴＥセッションの範囲内で唯一のＴＳＩ（ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ＬＣＴセッションに共通した属性及び個別ＬＣＴセッションに唯一の特定の属性は、サービスレイヤシグナリングの一部であるＳ−ＴＳＩＤ（ｓｅｒｖｉｃｅ−ｂａｓｅｄ ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｎｓｔａｎｃｅ ｄｅｓｃｒｉｐｔｉｏｎ）と呼ばれるＲＯＵＴＥシグナリング構造で与えられる。各ＬＣＴセッションは、１つのＰＬＰを介して伝達される。実施例によって、１つのＬＣＴセッションが複数個のＰＬＰを介して伝達されてもよい。ＲＯＵＴＥセッションの互いに異なるＬＣＴセッションは、互いに異なるＰＬＰに含まれてもよく、そうでなくてもよい。ここで、ＲＯＵＴＥセッションは、複数個のＰＬＰを介して伝達されてもよい。Ｓ−ＴＳＩＤに記述された属性は、各ＬＣＴセッションに対するＴＳＩ値及びＰＬＰＩＤ、デリバリーオブジェクト／ファイルに対するディスクリプタ、アプリケーションレイヤＦＥＣパラメータを含む。
ＭＭＴＰセッションは、デスティネーションＩＰアドレス及びデスティネーションポートナンバーによって識別される。ＭＭＴＰパケットフロー（それが伝達するサービスコンポーネントと関連する）は、ペアレントＭＭＴＰセッションの範囲内で唯一のｐａｃｋｅｔ_ｉｄによって識別される。各ＭＭＴＰパケットフローに共通した属性及びＭＭＴＰパケットフローの特定の属性がＳＬＴに与えられる。各ＭＭＴＰセッションに対する属性は、ＭＭＴＰセッション内で伝達され得るＭＭＴシグナリングメッセージによって与えられる。ＭＭＴＰセッションの互いに異なるＭＭＴＰパケットフローは、互いに異なるＰＬＰに含まれてもよく、そうでなくてもよい。ここで、ＭＭＴＰセッションは、複数個のＰＬＰを介して伝達されてもよい。ＭＭＴシグナリングメッセージに記述された属性は、各ＭＭＴＰパケットフローに対してｐａｃｋｅｔ_ｉｄ値及びＰＬＰＩＤを含む。ここで、ＭＭＴシグナリングメッセージは、ＭＭＴで定義された形態であるか、または後述する実施例によって変形が行われた形態であってもよい。
以下、ＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）について説明する。
この機能に専用であるよく知られているアドレス／ポートを有するＩＰパケットのペイロードに伝達されるシグナリング情報は、ＬＬＳと呼ばれる。このＩＰアドレス及びポートナンバーは、実施例によって異なって設定されてもよい。一実施例において、ＬＬＳは、アドレスが２２４．０．２３．６０であり、デスティネーションポートが４９３７／ｕｄｐであるＩＰパケットに伝達され得る。ＬＬＳは、前述したプロトコルスタック上で、「ＳＬＴ」で表現された部分に位置し得る。ただし、実施例によって、ＬＬＳは、ＵＤＰ／ＩＰレイヤのプロセシングを経ずに、信号フレーム上の別途の物理チャンネル（ｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌ）を介して伝送されてもよい。
ＬＬＳデータを伝達するＵＤＰ／ＩＰパケットは、ＬＬＳテーブルという形態でフォーマットすることができる。ＬＬＳデータを運搬する毎ＵＤＰ／ＩＰパケットの最初のバイトは、ＬＬＳテーブルの開始であり得る。全てのＬＬＳテーブルの最大の長さは、フィジカルレイヤから伝達され得る最も大きいＩＰパケットによって６５，５０７バイトに制限される。
ＬＬＳテーブルは、ＬＬＳテーブルのタイプを識別するＬＬＳテーブルＩＤフィールド、及びＬＬＳテーブルのバージョンを識別するＬＬＳテーブルバージョンフィールドを含むことができる。ＬＬＳテーブルＩＤフィールドが示す値に応じて、ＬＬＳテーブルは、前述したＳＬＴを含むか、またはＲＲＴ（Ｒａｔｉｎｇ Ｒｅｇｉｏｎ Ｔａｂｌｅ）を含むことができる。ＲＲＴは、コンテンツ勧告レーティング（Ｃｏｎｔｅｎｔ Ａｄｖｉｓｏｒｙ Ｒａｔｉｎｇ）に関する情報を有することができる。
以下、ＳＬＴ（Ｓｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ）について説明する。ＬＬＳは、受信機によるサービス獲得のブートストラッピング及び速いチャンネルスキャンを支援するシグナリング情報であり、ＳＬＴは、基本サービスリスティングを構築し、ＳＬＳのブートストラップディスカバリーを提供するために使用されるシグナリング情報のテーブルであり得る。
ＳＬＴの機能は、ＭＰＥＧ−２システムでのＰＡＴ（ｐｒｏｇｒａｍ ａｓｓｏｃｉａｔｉｏｎ ｔａｂｌｅ）及びＡＴＳＣシステムで発見されるＦＩＣ（ｆａｓｔ ｉｎｆｏｒｍａｔｉｏｎ ｃｈａｎｎｅｌ）とほぼ同一である。初めてブロードキャストエミッションを経験する受信機にとって、これは、開始される地点である。ＳＬＴは、受信機が、チャンネル名、チャンネルナンバーなどでそれが受信できる全てのサービスのリストを構築できるようにする、速いチャンネルスキャンを支援する。また、ＳＬＴは、受信機が各サービスに対してＳＬＳを発見できるようにするブートストラップ情報を提供する。ＲＯＵＴＥ／ＤＡＳＨで伝達されるサービスに対して、ブートストラップ情報は、ＳＬＳを伝達するＬＣＴセッションのデスティネーションＩＰアドレス及びデスティネーションポートを含む。ＭＭＴ／ＭＰＵで伝達されるサービスに対して、ブートストラップ情報は、ＳＬＳを伝達するＭＭＴＰセッションのデスティネーションＩＰアドレス及びデスティネーションポートを含む。
ＳＬＴは、ブロードキャストストリームで各サービスに関する次の情報を含むことによって、サービス獲得及び速いチャンネルスキャンを支援する。第一に、ＳＬＴは、視聴者にとって有意義であり、上／下の選択またはチャンネルナンバーを介した初期サービス選択を支援できるサービスリストのプレゼンテーションを許容するのに必要な情報を含むことができる。第二に、ＳＬＴは、各リスティングされたサービスに対してＳＬＳの位置を見つけるのに必要な情報を含むことができる。すなわち、ＳＬＴは、ＳＬＳを伝達する位置（ｌｏｃａｔｉｏｎ）に対するアクセス情報を含むことができる。
図示された本発明の一実施例に係るＳＬＴは、ＳＬＴルートエレメント（ｒｏｏｔ ｅｌｅｍｅｎｔ）を有するＸＭＬドキュメントの形態で表現された。実施例によって、ＳＬＴは、バイナリフォーマットまたはＸＭＬドキュメントの形態で表現することができる。
図示されたＳＬＴのＳＬＴルートエレメントは、＠ｂｓｉｄ、＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎ、＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒ、＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓ、＠ｌａｎｇｕａｇｅ、＠ｃａｐａｂｉｌｉｔｉｅｓ、ＩｎｅｔＳｉｇＬｏｃ及び／又はＳｅｒｖｉｃｅを含むことができる。実施例によって、ＳＬＴルートエレメントは、＠ｐｒｏｖｉｄｅｒＩｄをさらに含むこともできる。実施例によって、ＳＬＴルートエレメントは、＠ｌａｎｇｕａｇｅを含まなくてもよい。
Ｓｅｒｖｉｃｅエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒ、＠ｐｒｏｔｅｃｔｅｄ、＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ、＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ、＠ｈｉｄｄｅｎ、＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅ、ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇ、＠ｓｌｓＰｌｐＩｄ、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ、＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ、＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ＳｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ、＠ｃａｐａｂｉｌｉｔｉｅｓ及び／又はＩｎｅｔＳｉｇＬｏｃを含むことができる。
実施例によって、ＳＬＴの属性またはエレメントは追加／変更／削除されてもよい。ＳＬＴに含まれる各エレメントも、追加的に別途の属性またはエレメントを有することができ、本実施例に係る属性またはエレメントの一部が省略されてもよい。ここで、＠表記されたフィールドは属性（ａｔｔｒｉｂｕｔｅ）に該当し、＠表記されていないフィールドはエレメント（ｅｌｅｍｅｎｔ）に該当し得る。
＠ｂｓｉｄは、全ブロードキャストストリームの識別子である。ＢＳＩＤの値は、地域的レベルで唯一であり得る。
＠ｐｒｏｖｉｄｅｒＩｄは、このブロードキャストストリームの一部又は全体を使用する放送会社のインデックスである。これは選択的な属性である。それが存在しないということは、このブロードキャストストリームが一つの放送会社によって使用されていることを意味する。＠ｐｒｏｖｉｄｅｒＩｄは図示していない。
＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎは、ＳＬＴセクションのバージョンナンバーであり得る。ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎは、ｓｌｔ内で伝達される情報に変化が生じると１ずつ増分し得る。それが最大値に到達すると、０にシフトされる。
＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒは、ＳＬＴの当該セクションのナンバーであって、１からカウントすることができる。すなわち、当該ＳＬＴセクションのセクションナンバーに該当し得る。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。
＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓは、当該セクションが一部であるＳＬＴのセクション（即ち、最大のｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒを有するセクション）の総ナンバーであり得る。ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒとｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓは共に分割で伝送される場合、ＳＬＴの一部の「ＮのＭ部分」を示すと見ることができる。すなわち、ＳＬＴを伝送するにおいて、分割（ｆｒａｇｍｅｎｔａｔｉｏｎ）を通じた伝送を支援できる。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。フィールドが使用されない場合は、ＳＬＴが分割されて伝送されない場合であり得る。
＠ｌａｎｇｕａｇｅは、当該ｓｌｔの場合に含まれるサービスの主言語を示すことができる。実施例によって、このフィールド値は、ＩＳＯで定義される３−キャラクター言語コード（ｔｈｒｅｅ ｃｈａｒａｃｔｅｒ ｌａｎｇｕａｇｅ ｃｏｄｅ）の形態であってもよい。本フィールドは省略されてもよい。
＠ｃａｐａｂｉｌｉｔｉｅｓは、当該ｓｌｔの場合において全てのサービスに対する内容をデコーディングし、有意義に示すために要求されるケイパビリティを示すことができる。
ＩｎｅｔＳｉｇＬｏｃは、どこでブロードバンドを介して外部サーバーから全ての要求されるタイプのデータを獲得できるかを受信機に知らせるＵＲＬを提供することができる。このエレメントは、＠ｕｒｌＴｙｐｅを下位フィールドとしてさらに含むこともできる。この＠ｕｒｌＴｙｐｅフィールドの値に応じて、ＩｎｅｔＳｉｇＬｏｃが提供するＵＲＬのタイプを指示することができる。実施例によって、＠ｕｒｌＴｙｐｅフィールド値が０である場合、ＩｎｅｔＳｉｇＬｏｃはシグナリングサーバーのＵＲＬを提供することができる。＠ｕｒｌＴｙｐｅフィールド値が１である場合、ＩｎｅｔＳｉｇＬｏｃはＥＳＧサーバーのＵＲＬを提供することができる。＠ｕｒｌＴｙｐｅフィールドが、それ以外の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ ｆｏｒ ｆｕｔｕｒｅ ｕｓｅ）。
Ｓｅｒｖｉｃｅフィールドは、各サービスに関する情報を有するエレメントであって、サービスエントリーに該当し得る。ＳＬＴが指示するサービスの数（Ｎ）だけＳｅｒｖｉｃｅエレメントフィールドが存在し得る。以下、Ｓｅｒｖｉｃｅフィールドの下位属性／エレメントについて説明する。
＠ｓｅｒｖｉｃｅＩｄは、当該ブロードキャスト領域の範囲内で当該サービスを唯一に識別する整数であり得る。実施例によって、＠ｓｅｒｖｉｃｅＩｄのスコープ（ｓｃｏｐｅ）は変更されてもよい。＠ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒは、ｓｅｒｖｉｃｅＩｄ属性と同一のサービスＩＤを有するＳＬＴサービス情報のシーケンスナンバーを示す整数であり得る。ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒ値は、各サービスに対して０から始まることができ、当該Ｓｅｒｖｉｃｅエレメントにおいてある属性が変化するたびに１ずつ増分することができる。ＳｅｒｖｉｃｅＩＤの特定の値を有する以前のサービスエレメントに比べていかなる属性値も変化しない場合、ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒは増分しないはずである。ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒフィールドは、最大値に到達した後、０にシフトされる。
＠ｐｒｏｔｅｃｔｅｄは、フラグ情報であって、当該サービスの有意義な再生のための１つまたはそれ以上のコンポーネントが保護された（ｐｒｏｔｅｃｔｅｄ）状態であるかを示すことができる。「１」（真）に設定されると、有意義なプレゼンテーションに必要な１つ以上のコンポーネントが保護される。「０」（偽）に設定されると、当該フラグは、サービスの有意義なプレゼンテーションに必要なコンポーネントが何にも保護されないことを示す。デフォルト値は偽である。
＠ｍａｊｏｒＣｈａｎｎｅｌＮｏは、サービスの「主」チャンネルナンバーを示す整数値である。本フィールドの一実施例は、１から９９９までの範囲を有することができる。
＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、サービスの「副」チャンネルナンバーを示す整数値である。本フィールドの一実施例は、１から９９９までの範囲を有することができる。
＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙは、当該サービスのカテゴリを示すことができる。本フィールドが示す意味は、実施例によって変更されてもよい。一実施例によれば、本フィールドの値が１、２、３である場合、それぞれ当該サービスは、リニアＡ／Ｖサービス（Ｌｉｎｅａｒ Ａ／Ｖ ｓｅｒｖｉｃｅ）、リニアオーディオサービス（Ｌｉｎｅａｒ ａｕｄｉｏ ｏｎｌｙ ｓｅｒｖｉｃｅ）、アプリベースのサービス（ａｐｐ−ｂａｓｅｄ ｓｅｒｖｉｃｅ）に該当し得る。本フィールドの値が０である場合、定義されていないカテゴリのサービスであり得、本フィールドの値が０、１、２、３以外の他の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ ｆｏｒ ｆｕｔｕｒｅ ｕｓｅ）。＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅは、サービスのショートストリングネームであり得る。
＠ｈｉｄｄｅｎは、存在し、「真」に設定される場合、ブール値であり得、これは、サービスがテストや独占使用のためのものであり、通常のＴＶ受信機によっては選択されないことを示す。存在しない場合、デフォルト値は「偽」である。
＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅは、当該サービスによって使用されるＳＬＳのプロトコルのタイプを示す属性であり得る。本フィールドが示す意味は、実施例によって変更されてもよい。一実施例によれば、本フィールドの値が１、２である場合、それぞれ、当該サービスが使用するＳＬＳのプロトコルはＲＯＵＴＥ、ＭＭＴＰであり得る。本フィールドの値が０またはそれ以外の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ ｆｏｒ ｆｕｔｕｒｅ ｕｓｅ）。本フィールドは、＠ｓｌｓＰｒｏｔｏｃｏｌと呼ぶこともできる。
ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇ及びその下位属性／エレメントは、放送シグナリングと関連する情報を提供することができる。ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇエレメントが存在しない場合、ペアレントサービスエレメントのチャイルドエレメントであるＩｎｅｔＳｉｇＬｏｃが存在し得、その属性であるｕｒｌＴｙｐｅはＵＲＬ_ｔｙｐｅ ０ｘ００（ＵＲＬ ｔｏ ｓｉｇｎａｌｉｎｇ ｓｅｒｖｅｒ）を含む。この場合、属性であるｕｒｌは、ｓｅｒｖｉｃｅ_ｉｄがペアレントサービスエレメントに対するｓｅｒｖｉｃｅｄ属性に該当するクエリパラメータｓｖｃ＝＜ｓｅｒｖｉｃｅ_ｉｄ＞を支援する。
または、ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇエレメントが存在しない場合、エレメントＩｎｅｔＳｉｇＬｏｃはｓｌｔルートエレメントのチャイルドエレメントとして存在し得、ＩｎｅｔＳｉｇＬｏｃエレメントの属性ｕｒｌＴｙｐｅはＵＲＬ_ｔｙｐｅ ０ｘ００（ＵＲＬ ｔｏ ｓｉｇｎａｌｉｎｇ ｓｅｒｖｅｒ）を含む。この場合、ＵＲＬ_ｔｙｐｅ０ｘ００に対する属性ｕｒｌは、ｓｅｒｖｉｃｅ_ｉｄがペアレントサービスエレメントのｓｅｒｖｉｃｅＩｄ属性に該当するクエリパラメータｓｖｃ＝＜ｓｅｒｖｉｃｅ_ｉｄ＞を支援する。
＠ｓｌｓＰｌｐＩｄは、当該サービスに対してＳＬＳを伝達するＰＬＰのＰＬＰ ＩＤを示す整数を表現するストリングであり得る。
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓは、当該サービスに対してＳＬＳデータを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４デスティネーションアドレスを含むストリングであり得る。
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔは、当該サービスに対してＳＬＳデータを伝達するパケットのポートナンバーを含むストリングであり得る。前述したように、デスティネーションＩＰ／ＵＤＰ情報によってＳＬＳブートストラッピングを行うことができる。
＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓは、当該サービスに対してＳＬＳデータを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４ソースアドレスを含むストリングであり得る。
＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対してＳＬＳを伝達するために使用されるプロトコルの主バージョンナンバーであり得る。デフォルト値は１である。
＠ＳｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対してＳＬＳを伝達するために使用されるプロトコルの副バージョンナンバーであり得る。デフォルト値は０である。
＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅは、サービスの主言語を示す３文字言語コードであり得る。本フィールド値の形式は、実施例によって変更されてもよい。
＠ｂｒｏａｄｂａｎｄｃｃｅｓｓＲｅｑｕｉｒｅｄは、受信機がサービスの有意義なプレゼンテーションを行うためにブロードバンドアクセスが必要であることを示すブール値であり得る。本フィールドの値がＴｒｕｅである場合、受信機は、有意義なサービス再生のためにブロードバンドにアクセスしなければならず、これは、サービスのハイブリッドデリバリーのケースに該当し得る。
＠ｃａｐａｂｉｌｉｔｉｅｓは、ｓｅｒｖｉｃｅＩｄ属性と同一のサービスＩＤであって、サービスに対する内容をデコーディングし、有意義に示すために要求されるケイパビリティを示すことができる。
ＩｎｅｔＳｉｇＬｏｃは、使用可能な場合、ブロードバンドを介してシグナリングや公知の情報に接続するためのＵＲＬを提供することができる。そのデータタイプは、ＵＲＬがどこにアクセスするかを示す＠ｕｒｌＴｙｐｅ属性を追加する全てのＵＲＬデータタイプの拡張であり得る。本フィールドの＠ｕｒｌＴｙｐｅフィールドが意味することは、前述したＩｎｅｔＳｉｇＬｏｃの＠ｕｒｌＴｙｐｅフィールドが意味することと同一であり得る。属性ＵＲＬ_ｔｙｐｅ ０ｘ００のＩｎｅｔＳｉｇＬｏｃエレメントがＳＬＴのエレメントとして存在する場合、それは、シグナリングメタデータに対してＨＴＴＰ要請を行うために使用され得る。このＨＴＴＰ ＰＯＳＴメッセージボディーにはサービスタームが含まれてもよい。ＩｎｅｔＳｉｇＬｏｃエレメントがセクションレベルで現れる場合、サービスタームは、要請されたシグナリングメタデータオブジェクトが適用されるサービスを示すために使用される。サービスタームが存在しない場合、当該セクションの全てのサービスに対するシグナリングメタデータオブジェクトが要請される。ＩｎｅｔＳｉｇＬｏｃがサービスレベルで現れる場合、所望のサービスを指定するために必要なサービスタームがない。属性ＵＲＬ_ｔｙｐｅ ０ｘ０１のＩｎｅｔＳｉｇＬｏｃエレメントが提供されると、それは、ブロードバンドを介してＥＳＧデータを検索するのに使用することができる。当該エレメントがサービスエレメントのチャイルドエレメントとして現れる場合、ＵＲＬは、当該サービスに対してデータを検索するのに使用することができる。当該エレメントがＳＬＴエレメントのチャイルドエレメントとして現れる場合、ＵＲＬは、当該セクションで全てのサービスに対するＥＳＧデータを検索するのに使用することができる。
ＳＬＴの他の実施例において、ＳＬＴの＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎ、＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒ、＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓ及び／又は＠ｌａｎｇｕａｇｅフィールドは省略されてもよい。
また、前述したＩｎｅｔＳｉｇＬｏｃフィールドは、＠ｓｌｔＩｎｅｔＳｉｇＵｒｉ及び／又は＠ｓｌｔＩｎｅｔＥｓｇＵｒｉフィールドに代替されてもよい。２つのフィールドは、それぞれシグナリングサーバーのＵＲＩ、ＥＳＧサーバーのＵＲＩ情報を含むことができる。ＳＬＴの下位エレメントであるＩｎｅｔＳｉｇＬｏｃフィールド及びＳｅｒｖｉｃｅの下位エレメントであるＩｎｅｔＳｉｇＬｏｃフィールドは、いずれも、前記のような方法で代替されてもよい。
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は各フィールドに関するもので、１は、当該フィールドが必須のフィールドであり、０..１は、当該フィールドがオプショナルフィールドであることを意味し得る。
図４は、本発明の一実施例に係るＳＬＳブートストラッピング及びサービスディスカバリー過程を示した図である。
以下、サービスレイヤシグナリング（ＳＬＳ、Ｓｅｒｖｉｃｅ Ｌａｙｅｒ Ｓｉｇｎａｌｉｎｇ）について説明する。
ＳＬＳは、サービス及びそのコンテンツコンポーネントを発見し、獲得するための情報を提供するシグナリングであり得る。
ＲＯＵＴＥ／ＤＡＳＨについて、各サービスに対するＳＬＳは、コンポーネントのリスト、どこでそれらを獲得できるのか、サービスの有意義なプレゼンテーションのために要求される受信機の性能のようなサービスの特性を記述する。ＲＯＵＴＥ／ＤＡＳＨシステムにおいて、ＳＬＳは、ＵＳＢＤ（ｕｓｅｒ ｓｅｒｖｉｃｅ ｂｕｎｄｌｅ ｄｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ、ＤＡＳＨ ＭＰＤ（ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ）を含む。ここで、ＵＳＢＤまたはＵＳＤ（Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）は、ＳＬＳ ＸＭＬフラグメントのうちの１つであって、サービスの具体的な技術的情報を記述するシグナリングハブとしての役割を果たすことができる。このＵＳＢＤ／ＵＳＤは、３ＧＰＰ ＭＢＭＳで定義されたことよりもさらに拡張されてもよい。ＵＳＢＤ／ＵＳＤの具体的な内容については後述する。
サービスシグナリングは、サービス自体の基本属性、特に、サービスを獲得するために必要な属性に焦点を置く。視聴者のためのサービス及びプログラミングの特徴は、サービスの公知またはＥＳＧデータとして現れる。
各サービスに対して別個のサービスシグナリングを有する場合、受信機は、ブロードキャストストリーム内で伝達される全ＳＬＳをパーシングすることなく所望のサービスに対する適切なＳＬＳを獲得すればよい。
サービスシグナリングの選択的なブロードバンドデリバリーに対して、ＳＬＴは、前述したように、サービスシグナリングファイルが獲得され得るＨＴＴＰ ＵＲＬを含むことができる。
ＬＬＳは、ＳＬＳ獲得をブートストラップするのに使用され、その後、ＳＬＳは、ＲＯＵＴＥセッションまたはＭＭＴＰセッションで伝達されるサービスコンポーネントを獲得するのに使用される。記述された図面は、次のシグナリングシーケンスを示す。受信機は、前述したＳＬＴを獲得し始める。ＲＯＵＴＥセッションで伝達されるｓｅｒｖｉｃｅ_ｉｄによって識別される各サービスは、ＰＬＰＩＤ（＃１）、ソースＩＰアドレス（ｓＩＰ１）、デスティネーションＩＰアドレス（ｄＩＰ１）、及びデスティネーションポートナンバー（ｄＰｏｒｔ１）のようなＳＬＳブートストラッピング情報を提供する。ＭＭＴＰセッションで伝達されるｓｅｒｖｉｃｅ_ｉｄによって識別される各サービスは、ＰＬＰＩＤ（＃２）、デスティネーションＩＰアドレス（ｄＩＰ２）、及びデスティネーションポートナンバー（ｄＰｏｒｔ２）のようなＳＬＳブートストラッピング情報を提供する。
ＲＯＵＴＥを用いたストリーミングサービスデリバリーに対して、受信機は、ＰＬＰ及びＩＰ／ＵＤＰ／ＬＣＴセッションで伝達されるＳＬＳ分割を獲得することができる。反面、ＭＭＴＰを用いたストリーミングサービスデリバリーに対して、受信機は、ＰＬＰ及びＭＭＴＰセッションで伝達されるＳＬＳ分割を獲得することができる。ＲＯＵＴＥを用いたサービスデリバリーに対して、これらＳＬＳ分割は、ＵＳＢＤ／ＵＳＤ分割、Ｓ−ＴＳＩＤ分割、ＭＰＤ分割を含む。それらは一つのサービスと関連がある。ＵＳＢＤ／ＵＳＤ分割は、サービスレイヤの特性を記述し、Ｓ−ＴＳＩＤ分割に対するＵＲＩレファレンス及びＭＰＤ分割に対するＵＲＩレファレンスを提供する。すなわち、ＵＳＢＤ／ＵＳＤは、Ｓ−ＴＳＩＤとＭＰＤをそれぞれ参照することができる。ＭＭＴＰを用いたサービスデリバリーに対して、ＵＳＢＤは、ＭＭＴシグナリングのＭＭＴメッセージを参照し、それのＭＰテーブルは、サービスに属するアセット（ａｓｓｅｔ）のための位置情報及びパッケージＩＤの識別を提供する。ここで、Ａｓｓｅｔとは、マルチメディアデータエンティティーであって、一つのユニークなＩＤに連合され、一つのマルチメディアプレゼンテーションを生成するのに使用されるデータエンティティーを意味し得る。Ａｓｓｅｔは、一つのサービスを構成するサービスコンポーネントに該当し得る。ＭＰＴメッセージは、ＭＭＴのＭＰテーブルを有するメッセージであり、ここで、ＭＰテーブルは、ＭＭＴ Ａｓｓｅｔとコンテンツに関する情報を有する、ＭＭＴパッケージテーブル（ＭＭＴ Ｐａｃｋａｇｅ Ｔａｂｌｅ）であり得る。具体的な内容は、ＭＭＴで定義された通りである。ここで、メディアプレゼンテーションとは、メディアコンテンツのバウンド／アンバウンドされたプレゼンテーションを成立させるデータのコレクションであり得る。
Ｓ−ＴＳＩＤ分割は、一つのサービスと関連するコンポーネント獲得情報と、当該サービスのコンポーネントに該当するＴＳＩ及びＭＰＤで発見されるＤＡＳＨ表現との間のマッピングを提供する。Ｓ−ＴＳＩＤは、ＴＳＩ及び関連するＤＡＳＨ表現識別子の形態のコンポーネント獲得情報、及びＤＡＳＨ表現と関連するＤＡＳＨ分割を伝達するＰＬＰＩＤを提供することができる。ＰＬＰＩＤ及びＴＳＩ値によって、受信機は、サービスからオーディオ／ビデオコンポーネントを収集し、ＤＡＳＨメディア分割のバッファリングを開始した後、適切なデコーディング過程を適用する。
ＭＭＴＰセッションで伝達されるＵＳＢＤリスティングサービスコンポーネントに対して、記述された図面の「Ｓｅｒｖｉｃｅ ＃２」に示したように、受信機は、ＳＬＳを完了するためにマッチングされるＭＭＴ_ｐａｃｋａｇｅ_ｉｄを有するＭＰＴメッセージを獲得する。ＭＰＴメッセージは、各コンポーネントに対する獲得情報及びサービスを含むサービスコンポーネントの完全なリストを提供する。コンポーネント獲得情報は、ＭＭＴＰセッション情報、当該セッションを伝達するＰＬＰＩＤ、当該セッション内のｐａｃｋｅｔ_ｉｄを含む。
実施例によって、例えば、ＲＯＵＴＥの場合、２つ以上のＳ−ＴＳＩＤフラグメントが使用されてもよい。それぞれのフラグメントは、各サービスのコンテンツを伝達するＬＣＴセッションに対するアクセス情報を提供することができる。
ＲＯＵＴＥの場合、Ｓ−ＴＳＩＤ、ＵＳＢＤ／ＵＳＤ、ＭＰＤ、またはこれらを伝達するＬＣＴセッションをサービスシグナリングチャンネルと呼ぶこともできる。ＭＭＴＰの場合、ＵＳＢＤ／ＵＤ、ＭＭＴシグナリングメッセージ、またはこれらを伝達するパケットフローをサービスシグナリングチャンネルと呼ぶこともできる。
図示された実施例とは異なり、一つのＲＯＵＴＥまたはＭＭＴＰセッションは複数個のＰＬＰを介して伝達され得る。すなわち、一つのサービスは一つ以上のＰＬＰを介して伝達されてもよい。前述したように、一つのＬＣＴセッションは一つのＰＬＰを介して伝達され得る。図示されたものとは異なり、実施例によって、一つのサービスを構成するコンポーネントが、互いに異なるＲＯＵＴＥセッションを介して伝達されてもよい。また、実施例によって、一つのサービスを構成するコンポーネントが、互いに異なるＭＭＴＰセッションを介して伝達されてもよい。実施例によって、一つのサービスを構成するコンポーネントが、ＲＯＵＴＥセッションとＭＭＴＰセッションとに分けられて伝達されてもよい。図示してはいないが、一つのサービスを構成するコンポーネントが、ブロードバンドを介して伝達（ハイブリッドデリバリー）される場合もあり得る。
図５は、本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示した図である。
以下、ＲＯＵＴＥに基づいたデリバリーにおいて、サービスレイヤシグナリングについて説明する。
ＳＬＳは、サービス及びそのコンテンツコンポーネントの発見及び接近を可能にするために、受信機に、具体的な技術的な情報を提供する。それは、専用ＬＣＴセッションで伝達されるＸＭＬコーディングされたメタデータ分割の集合を含むことができる。当該ＬＣＴセッションは、前述したように、ＳＬＴに含まれたブートストラップ情報を用いて獲得することができる。ＳＬＳは、サービスレベル毎に定義され、それは、コンテンツコンポーネントのリスト、どのようにそれらを獲得するのか、サービスの有意義なプレゼンテーションを行うために要求される受信機の性能のようなサービスのアクセス情報及び特徴を記述する。ＲＯＵＴＥ／ＤＡＳＨシステムにおいて、リニアサービスデリバリーのために、ＳＬＳは、ＵＳＢＤ、Ｓ−ＴＳＩＤ及びＤＡＳＨ ＭＰＤのようなメタデータ分割で構成される。ＳＬＳ分割は、ＴＳＩ＝０である専用のＬＣＴ伝送セッションで伝達され得る。実施例によって、ＳＬＳフラグメントが伝達される特定のＬＣＴセッション（ｄｅｄｉｃａｔｅｄ ＬＣＴ ｓｅｓｓｉｏｎ）のＴＳＩは、異なる値を有してもよい。実施例によって、ＳＬＳフラグメントが伝達されるＬＣＴセッションが、ＳＬＴまたは他の方法によってシグナリングされてもよい。
ＲＯＵＴＥ／ＤＡＳＨ ＳＬＳは、ＵＳＢＤ及びＳ−ＴＳＩＤメタデータ分割を含むことができる。これらサービスシグナリング分割は、リニア及びアプリケーションに基づいたサービスに適用され得る。ＵＳＢＤ分割は、サービス識別、装置性能情報、サービス及び構成メディアコンポーネントにアクセスするのに要求される他のＳＬＳ分割に対する参照、受信機がサービスコンポーネントの伝送モード（ブロードキャスト及び／又はブロードバンド）を決定できるようにするメタデータを含む。ＵＳＢＤによって参照されるＳ−ＴＳＩＤ分割は、サービスのメディアコンテンツコンポーネントが伝達される１つ以上のＲＯＵＴＥ／ＬＣＴセッションに対する伝送セッションディスクリプション、及び当該ＬＣＴセッションで伝達されるデリバリーオブジェクトのディスクリプションを提供する。ＵＳＢＤ及びＳ−ＴＳＩＤは後述する。
ＲＯＵＴＥに基づいたデリバリーにおけるＳｔｒｅａｍｉｎｇ Ｃｏｎｔｅｎｔ Ｓｉｇｎａｌｉｎｇにおいて、ＳＬＳのストリーミングコンテンツシグナリングコンポーネントはＭＰＤフラグメントに該当する。ＭＰＤは、主にストリーミングコンテンツとしてのＤＡＳＨ分割のデリバリーのためのリニアサービスと関連する。ＭＰＤは、分割ＵＲＬの形態のリニア／ストリーミングサービスの個別メディアコンポーネントに対するソース識別子、及びメディアプレゼンテーション内の識別されたリソースのコンテキストを提供する。ＭＰＤについての具体的な内容は後述する。
ＲＯＵＴＥに基づいたデリバリーにおけるアプリベースのエンハンスメントシグナリングにおいて、アプリベースのエンハンスメントシグナリングは、アプリケーションロジックファイル、局部的にキャッシュされたメディアファイル、ネットワークコンテンツアイテム、または公知のストリームのようなアプリベースのエンハンスメントコンポーネントのデリバリーに属する。アプリケーションはまた、可能な場合、ブロードバンドコネクション上で局部的にキャッシュされたデータを検索することができる。
以下、本図に示されたＵＳＢＤ／ＵＳＤの具体的な内容について説明する。
トップレベルまたはエントリーポイントＳＬＳ分割はＵＳＢＤ分割である。図示されたＵＳＢＤフラグメントは、本発明の一実施例であり、図示されていない基本的なＵＳＢＤフラグメントのフィールドが実施例によってさらに追加されてもよい。前述したように、図示されたＵＳＢＤフラグメントは、拡張された形態であって、基本構造にさらに追加されたフィールドを有することができる。
図示されたＵＳＢＤは、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントはｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、一つのサービスに対するインスタンスであり得る。
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＳｔａｔｕｓ、＠ａｔｓｃ：ｆｕｌｌＭＰＤＵｒｉ、＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅ及び／又はｄｅｌｉｖｅｒｙＭｅｔｈｏｄを含むことができる。
＠ｓｅｒｖｉｃｅＩｄは、ＢＳＩＤの範囲内で唯一のサービスを識別する全世界的に唯一のＵＲＩであり得る。当該パラメータは、ＥＳＧデータ（Ｓｅｒｖｉｃｅ＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ）とリンクするのに使用することができる。
＠ａｔｓｃ：ｓｅｒｖｉｃｅｄは、ＬＬＳ（ＳＬＴ）において該当するサービスエントリーに対するレファレンスである。当該属性の値は、当該エントリーに割り当てられたｓｅｒｖｉｃｅＩｄの値と同一である。
＠ａｔｓｃ：ｓｅｒｖｉｃｅＳｔａｔｕｓは、当該サービスの状態を特定することができる。その値は、当該サービスが活性化されているか、または非活性化されているかを示す。「１」（真）に設定されると、サービスが活性化されていることを示す。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。
＠ａｔｓｃ：ｆｕｌｌＭＰＤＵｒｉは、ブロードキャスト上で選択的に、また、ブロードバンド上で伝達されるサービスのコンテンツコンポーネントに対するディスクリプションを含むＭＰＤ分割を参照することができる。
＠ａｔｓｃ：ｓＴＳＩＤＵｒｉは、当該サービスのコンテンツを伝達する伝送セッションにアクセス関連パラメータを提供するＳ−ＴＳＩＤ分割を参照することができる。
ｎａｍｅは、ｌａｎｇ属性によって与えられるサービスのネームを示すことができる。ｎａｍｅエレメントは、サービスネームの言語を示すｌａｎｇ属性を含むことができる。言語は、ＸＭＬデータタイプに応じて特定することができる。
ｓｅｒｖｉｃｅＬａｎｇｕａｇｅは、サービスの利用可能な言語を示すことができる。言語は、ＸＭＬデータタイプに応じて特定することができる。
ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、受信機が当該サービスのコンテンツの有意義なプレゼンテーションを生成できるように要求されるケイパビリティを特定することができる。実施例によって、本フィールドは、予め定義されたケイパビリティグループを特定してもよい。ここで、ケイパビリティグループは、有意義なプレゼンテーションのためのケイパビリティ属性値のグループであり得る。本フィールドは、実施例によって省略されてもよい。
ｄｅｌｉｖｅｒｙＭｅｔｈｏｄは、アクセスのブロードキャスト及び（選択的に）ブロードバンドモード上でサービスのコンテンツに属する情報に関連するトランスポートのコンテナであり得る。当該サービスに含まれるデータにおいて、そのデータをＮ個とすれば、そのそれぞれのデータに対するデリバリー方法が、このエレメントによって記述され得る。ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント及びｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントを含むことができる。それぞれの下位エレメントは、ｂａｓｅＰａｔｔｅｒｎエレメントを下位エレメントとして有することができる。
ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅは、所属のメディアプレゼンテーションの全ての期間にわたって、サービスに属する当該メディアコンポーネントを含む、多重化または非多重化された形態のブロードキャスト上で伝達されるＤＡＳＨレプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、放送網を介して伝達されるＤＡＳＨレプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味し得る。
ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅは、所属のメディアプレゼンテーションの全ての期間にわたって、サービスに属する構成メディアコンテンツコンポーネントを含む、多重化または非多重化された形態のブロードバンド上で伝達されるＤＡＳＨレプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、ブロードバンドを介して伝達されるＤＡＳＨレプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味し得る。
ｂａｓｅＰａｔｔｅｒｎは、含まれた期間にペアレントレプレゼンテーションのメディア分割を要求するためにＤＡＳＨクライアントによって使用される分割ＵＲＬの全ての部分に対してマッチングされるように受信機によって使用される文字パターンであり得る。マッチは、当該要求されたメディア分割がブロードキャストトランスポート上で伝達されることを暗示する。それぞれのｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントとｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで表現されるＤＡＳＨレプレゼンテーションを受信できるＵＲＬアドレスにおいて、そのＵＲＬの一部分などは特定のパターンを有することができ、そのパターンが本フィールドによって記述され得る。この情報を通じて、一定の部分のデータに対する区分が可能である。提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は各フィールドに関するもので、Ｍは必須のフィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
図６は、本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示した図である。
以下、本図に示されたＳ−ＴＳＩＤの具体的な内容について説明する。
Ｓ−ＴＳＩＤは、サービスのコンテンツコンポーネントを伝達する伝送セッションに対する全体的なセッションディスクリプション情報を提供するＳＬＳ ＸＭＬ分割であり得る。Ｓ−ＴＳＩＤは、サービスのメディアコンテンツコンポーネントが伝達される構成ＬＣＴセッション、及び０個以上のＲＯＵＴＥセッションに対する全体的な伝送セッションディスクリプション情報を含む、ＳＬＳメタデータ分割である。Ｓ−ＴＳＩＤはまた、ＬＣＴセッションで伝達されるコンテンツコンポーネント及びペイロードフォーマットに対する追加情報だけでなく、サービスのＬＣＴセッションで伝達されるデリバリーオブジェクトまたはオブジェクトフローに対するファイルメタデータを含む。
Ｓ−ＴＳＩＤ分割の各インスタンスは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントの＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ属性によってＵＳＢＤ分割で参照される。図示された本発明の一実施例に係るＳ−ＴＳＩＤは、ＸＭＬドキュメントの形態で表現された。実施例によって、Ｓ−ＴＳＩＤは、バイナリフォーマットまたはＸＭＬドキュメントの形態で表現されてもよい。
図示されたＳ−ＴＳＩＤは、Ｓ−ＴＳＩＤルートエレメントを有することができる。Ｓ−ＴＳＩＤルートエレメントは、＠ｓｅｒｖｉｃｅＩｄ及び／又はＲＳを含むことができる。
＠ｓｅｒｖｉｃｅＩＤは、ＵＳＤでサービスエレメントに該当するレファレンスであり得る。当該属性の値は、ｓｅｒｖｉｃｅ_ｉｄの当該値を有するサービスを参照することができる。
ＲＳエレメントは、当該サービスデータを伝達するＲＯＵＴＥセッションに関する情報を有することができる。複数個のＲＯＵＴＥセッションを介してサービスデータ乃至サービスコンポーネントを伝達できるので、本エレメントは１個〜Ｎ個の個数を有することができる。
ＲＳエレメントは、＠ｂｓｉｄ、＠ｓＩｐＡｄｄｒ、＠ｄＩｐＡｄｄｒ、＠ｄｐｏｒｔ、＠ＰＬＰＩＤ及び／又はＬＳを含むことができる。
＠ｂｓｉｄは、ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのコンテンツコンポーネントが伝達されるブロードキャストストリームの識別子であり得る。当該属性が存在しない場合、デフォルトブロードキャストストリームのＰＬＰが当該サービスに対するＳＬＳ分割を伝達することであり得る。その値は、ＳＬＴでｂｒｏａｄｃａｓｔ_ｓｔｒｅａｍ_ｉｄと同一であり得る。
＠ｓＩｐＡｄｄｒは、ソースＩＰアドレスを示すことができる。ここで、ソースＩＰアドレスは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのソースＩＰアドレスであり得る。前述したように、一つのサービスのサービスコンポーネントは、複数個のＲＯＵＴＥセッションを介して伝達されてもよい。そのため、当該Ｓ−ＴＳＩＤが伝達されるＲＯＵＴＥセッションではない他のＲＯＵＴＥセッションでそのサービスコンポーネントが伝送されてもよい。したがって、ＲＯＵＴＥセッションのソースＩＰアドレスを指示するために本フィールドが使用され得る。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションのソースＩＰアドレスであり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションのソースＩＰアドレス値であり得る。この場合、本フィールドはＭ、すなわち、必須のフィールドであり得る。
＠ｄＩｐＡｄｄｒは、デスティネーションＩＰアドレスを示すことができる。ここで、デスティネーションＩＰアドレスは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションＩＰアドレスであり得る。＠ｓＩｐＡｄｄｒで説明したような場合のために、本フィールドは、サービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションＩＰアドレスを指示してもよい。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションのデスティネーションＩＰアドレスであり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションのデスティネーションＩＰアドレス値であり得る。この場合、本フィールドはＭ、すなわち、必須フィールドであり得る。
＠ｄｐｏｒｔは、デスティネーションポートを示すことができる。ここで、デスティネーションポートは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションポートであり得る。＠ｓＩｐＡｄｄｒで説明したような場合のために、本フィールドは、サービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションポートを指示することができる。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションのデスティネーションポートナンバーであり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションのデスティネーションポートナンバー値であり得る。この場合、本フィールドはＭ、すなわち、必須フィールドであり得る。
＠ＰＬＰＩＤは、ＲＳで表現されるＲＯＵＴＥセッションのためのＰＬＰのＩＤであり得る。デフォルト値は、現在のＳ−ＴＳＩＤが含まれたＬＣＴセッションのＰＬＰのＩＤであり得る。実施例によって、本フィールドは、当該ＲＯＵＴＥセッションでＳ−ＴＳＩＤが伝達されるＬＣＴセッションのためのＰＬＰのＩＤ値を有してもよく、当該ＲＯＵＴＥセッションのための全てのＰＬＰのＩＤ値を有してもよい。
ＬＳエレメントは、当該サービスデータを伝達するＬＣＴセッションに関する情報を有することができる。複数個のＬＣＴセッションを介してサービスデータ乃至サービスコンポーネントを伝達できるので、本エレメントは、１個〜Ｎ個の個数を有することができる。
ＬＳエレメントは、＠ｔｓｉ、＠ＰＬＰＩＤ、＠ｂｗ、＠ｓｔａｒｔＴｉｍｅ、＠ｅｎｄＴｉｍｅ、ＳｒｃＦｌｏｗ及び／又はＲｐｒＦｌｏｗを含むことができる。
＠ｔｓｉは、当該サービスのサービスコンポーネントが伝達されるＬＣＴセッションのＴＳＩ値を指示することができる。
＠ＰＬＰＩＤは、当該ＬＣＴセッションのためのＰＬＰのＩＤ情報を有することができる。この値は、基本ＲＯＵＴＥセッション値を上書きしてもよい。
＠ｂｗは、最大の帯域値を指示することができる。＠ｓｔａｒｔＴｉｍｅは当該ＬＣＴセッションのスタートタイム（Ｓｔａｒｔ ｔｉｍｅ）を指示することができる。＠ｅｎｄＴｉｍｅは、当該ＬＣＴセッションのエンドタイム（Ｅｎｄ ｔｉｍｅ）を指示することができる。ＳｒｃＦｌｏｗエレメントは、ＲＯＵＴＥのソースフローに対して記述することができる。ＲｐｒＦｌｏｗエレメントは、ＲＯＵＴＥのリペアフローに対して記述することができる。
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は、各フィールドに関するもので、Ｍは必須フィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
以下、ＲＯＵＴＥ／ＤＡＳＨのためのＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）について説明する。
ＭＰＤは、放送会社によって定められた与えられたデューレーションのリニアサービスに該当するＤＡＳＨメディアプレゼンテーションの公式化されたディスクリプションを含むＳＬＳメタデータ分割である（例えば、ある期間の間の一つのＴＶプログラムまたは連続的なリニアＴＶプログラムの集合）。ＭＰＤのコンテンツは、メディアプレゼンテーション内で識別されたリソースに対するコンテキスト及び分割に対するソース識別子を提供する。ＭＰＤ分割のデータ構造及びセマンティクスは、ＭＰＥＧ ＤＡＳＨによって定義されたＭＰＤに従うことができる。
ＭＰＤで伝達される１つ以上のＤＡＳＨレプレゼンテーションは、ブロードキャスト上で伝達され得る。ＭＰＤは、ハイブリッドサービスの場合のようなブロードバンド上で伝達される追加レプレゼンテーションを記述したり、ブロードキャスト信号悪化（例えば、トンネルの中の走行）によるブロードキャストからブロードキャストへのハンドオフでサービス連続性を支援したりすることができる。
図７は、本発明の一実施例に係るＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示した図である。
リニアサービスのためのＭＭＴ ＳＬＳは、ＵＳＢＤ分割及びＭＰテーブルを含む。ＭＰテーブルは、前述した通りである。ＵＳＢＤ分割は、サービス識別、装置性能情報、サービス及び構成メディアコンポーネントにアクセスするのに要求される他のＳＬＳ分割に対する参照、及び受信機がサービスコンポーネントの伝送モード（ブロードキャスト及び／又はブロードバンド）を決定できるようにするメタデータを含む。ＵＳＢＤによって参照されるＭＰＵコンポーネントに対するＭＰテーブルは、サービスのメディアコンテンツコンポーネントが伝達されるＭＭＴＰセッションに対する伝送セッションディスクリプション、及びＭＭＴＰセッションで伝達されるアセットのディスクリプションを提供する。
ＭＰＵコンポーネントに対するＳＬＳのストリーミングコンテンツシグナリングコンポーネントは、ＭＭＴで定義されたＭＰテーブルに該当する。ＭＰテーブルは、各アセットが単一のサービスコンポーネントに該当するＭＭＴアセットのリスト、及び当該コンポーネントに対する位置情報のディスクリプションを提供する。
ＵＳＢＤ分割は、ＲＯＵＴＥプロトコル及びブロードバンドによってそれぞれ伝達されるサービスコンポーネントに対して、前述したようなＳ−ＴＳＩＤ及びＭＰＤに対する参照も含むことができる。実施例によって、ＭＭＴを通じたデリバリーにおいて、ＲＯＵＴＥプロトコルを介して伝達されるサービスコンポーネントはＮＲＴなどのデータであるので、この場合において、ＭＰＤは用いられなくてもよい。また、ＭＭＴを通じたデリバリーにおいて、ブロードバンドを介して伝達されるサービスコンポーネントはどのＬＣＴセッションを介して伝達されるかに対する情報が必要でないので、Ｓ−ＴＳＩＤは用いられなくてもよい。ここで、ＭＭＴパッケージは、ＭＭＴを用いて伝達される、メディアデータの論理的コレクションであり得る。ここで、ＭＭＴＰパケットは、ＭＭＴを用いて伝達されるメディアデータのフォーマットされたユニットを意味し得る。ＭＰＵ（Ｍｅｄｉａ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）は、独立してデコーディング可能なタイムド／ノン−タイムドデータのジェネリックコンテナを意味し得る。ここで、ＭＰＵでのデータはメディアコーデックアグノスティックである。
以下、本図に示されたＵＳＢＤ／ＵＳＤの具体的な内容について説明する。
図示されたＵＳＢＤフラグメントは、本発明の一実施例であり、図示されていない基本的なＵＳＢＤフラグメントのフィールドが実施例によってさらに追加されてもよい。前述したように、図示されたＵＳＢＤフラグメントは、拡張された形態であって、基本構造にさらに追加されたフィールドを有することができる。
図示された本発明の一実施例に係るＵＳＢＤは、ＸＭＬドキュメントの形態で表現された。実施例によって、ＵＳＢＤは、バイナリフォーマットまたはＸＭＬドキュメントの形態で表現されてもよい。
図示されたＵＳＢＤは、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントはｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであり得る。
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅ、ａｔｓｃ：Ｃｈａｎｎｅｌ、ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔ、ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔ、ａｔｓｃ：ｂｒｏａｄｂａｎｄ Ｃｏｍｐｏｎｅｎｔ及び／又はａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏを含むことができる。
ここで、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、前述したものと同一であり得る。ｎａｍｅフィールドの下のｌａｎｇフィールドも、前述したものと同一であり得る。ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、実施例によって省略されてもよい。
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、実施例によってａｔｓｃ：ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメントをさらに含むことができる。このエレメントはオプショナルエレメントであり得る。ａｔｓｃ：ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇは、コンテンツ諮問順位を特定することができる。本フィールドは図示していない。
ａｔｓｃ：Ｃｈａｎｎｅｌは、サービスのチャンネルに対する情報を有することができる。ａｔｓｃ：Ｃｈａｎｎｅｌエレメントは、＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＧｅｎｒｅ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｃｏｎ及び／又はａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎを含むことができる。＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇは、実施例によって省略されてもよい。
＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏは、サービスの主チャンネルナンバーを示す属性である。
＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、サービスの副チャンネルナンバーを示す属性である。
＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇは、サービスで使用される主要言語を示す属性である。
＠ａｔｓｃ：ｓｅｒｖｉｃｅＧｅｎｒｅは、サービスの主要ジャンルを示す属性である。
＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｃｏｎは、当該サービスを表現するために使用されるアイコンに対するＵＲＬを示す属性である。
ａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、サービスディスクリプションを含み、これは多重言語であってもよい。ａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ及び／又は＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇを含むことができる。
＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔは、サービスのディスクリプションを示す属性である。
＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇは、ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ属性の言語を示す属性である。
ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔは、ＭＰＵの形態で伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄ及び／又は＠ａｔｓｃ：ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄを含むことができる。
＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄは、ＭＰＵとして伝達されるサービスのコンテンツコンポーネントに対するＭＭＴパッケージを参照することができる。
＠ａｔｓｃ：ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄは、ＭＰＵとして伝達されるサービスのコンテンツコンポーネントに合わせて＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄによって参照された後に使用されるＭＭＴパッケージを参照することができる。
ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、ＲＯＵＴＥを介して伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ、＠ｓＴＳＩＤＰｌｐＩｄ、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ、＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ、＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ及び／又は＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを含むことができる。
＠ａｔｓｃ：ｓＴＳＩＤＵｒｉは、当該サービスのコンテンツを伝達する伝送セッションにアクセス関連パラメータを提供するＳ−ＴＳＩＤ分割を参照することができる。このフィールドは、前述したＲＯＵＴＥのためのＵＳＢＤでのＳ−ＴＳＩＤを参照するためのＵＲＩと同一であり得る。前述したように、ＭＭＴＰによるサービスデリバリーにおいても、ＮＲＴなどを介して伝達されるサービスコンポーネントはＲＯＵＴＥによって伝達され得る。そのためのＳ−ＴＳＩＤを参照するために、本フィールドが使用され得る。
＠ｓＴＳＩＤＰｌｐＩｄは、当該サービスに対するＳ−ＴＳＩＤを伝達するＰＬＰのＰＬＰ ＩＤを示す整数を表現するストリングであり得る。（デフォルト：現在のＰＬＰ）
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４デスティネーションアドレスを含むストリングであり得る。（デフォルト：現在のＭＭＴＰセッションのソースＩＰアドレス）
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのポートナンバーを含むストリングであり得る。
＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４ソースアドレスを含むストリングであり得る。
＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対するＳ−ＴＳＩＤを伝達するために使用されるプロトコルの主バージョンナンバーを示すことができる。デフォルト値は１である。
＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対するＳ−ＴＳＩＤを伝達するために使用されるプロトコルの副バージョンナンバーを示すことができる。デフォルト値は０である。
ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔは、ブロードバンドを介して伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。すなわち、ハイブリッドデリバリーを想定したフィールドであり得る。ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｆｕｌｌｆＭＰＤＵｒｉをさらに含むことができる。
＠ａｔｓｃ：ｆｕｌｌｆＭＰＤＵｒｉは、ブロードバンドで伝達されるサービスのコンテンツコンポーネントに対するディスクリプションを含むＭＰＤ分割に対するレファレンスであり得る。
ａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏは、サービスのアベイラブルな（ａｖａｉｌａｂｌｅ）コンポーネントに対する情報を有することができる。それぞれのコンポーネントに対する、タイプ、ロール、名などの情報を有することができる。各コンポーネント（Ｎ個）の数だけ本フィールドが存在することができる。ａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏは、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＴｙｐｅ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＲｏｌｅ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＩｄ及び／又は＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＮａｍｅを含むことができる。
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＴｙｐｅは、当該コンポーネントのタイプを示す属性である。０の値はオーディオコンポーネントを示す。１の値はビデオコンポーネントを示す。２の値はクローズドキャプションコンポーネントを示す。３の値はアプリケーションコンポーネントを示す。４〜７の値は残す。本フィールド値の意味は、実施例によって異なって設定されてもよい。
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＲｏｌｅは、当該コンポーネントの役割及び種類を示す属性である。
オーディオに対して（ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が０と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｃｏｍｐｌｅｔｅ ｍａｉｎ、１＝音楽及び効果（Ｍｕｓｉｃ ａｎｄ Ｅｆｆｅｃｔｓ）、２＝対話（Ｄｉａｌｏｇ）、３＝解説（Ｃｏｍｍｅｎｔａｒｙ）、４＝視覚障害（Ｖｉｓｕａｌｌｙ Ｉｍｐａｉｒｅｄ）、５＝聴覚障害（Ｈｅａｒｉｎｇ Ｉｍｐａｉｒｅｄ）、６＝ボイスオーバー（Ｖｏｉｃｅ−Ｏｖｅｒ）、７−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
オーディオに対して（ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が１と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｐｒｉｍａｒｙ ｖｉｄｅｏ、１＝代替カメラビュー（Ａｌｔｅｒｎａｔｉｖｅ ｃａｍｅｒａ ｖｉｅｗ）、２＝他の代替ビデオコンポーネント（Ｏｔｈｅｒ ａｌｔｅｒｎａｔｉｖｅ ｖｉｄｅｏ ｃｏｍｐｏｎｅｎｔ）、３＝手話挿入（Ｓｉｇｎ ｌａｎｇｕａｇｅ ｉｎｓｅｔ）、４＝Ｆｏｌｌｏｗ ｓｕｂｊｅｃｔ ｖｉｄｅｏ、５＝３Ｄビデオの左側ビュー（３Ｄ ｖｉｄｅｏ ｌｅｆｔ ｖｉｅｗ）、６＝３Ｄビデオの右側ビュー（３Ｄ ｖｉｄｅｏ ｒｉｇｈｔ ｖｉｅｗ）、７＝３Ｄビデオの深さ情報（３Ｄ ｖｉｄｅｏ ｄｅｐｔｈ ｉｎｆｏｒｍａｔｉｏｎ）、８＝Ｐａｒｔ ｏｆ ｖｉｄｅｏ ａｒｒａｙ ＜ｘ，ｙ＞ ｏｆ ＜ｎ，ｍ＞、９＝Ｆｏｌｌｏｗ−Ｓｕｂｊｅｃｔ ｍｅｔａｄａｔａ、１０−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
クローズドキャプションコンポーネントに対して（ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が２と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｎｏｒｍａｌ、１＝Ｅａｓｙ ｒｅａｄｅｒ、２−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性の値が３と７との間であれば、ｃｏｍｐｏｎｅｎｔＲｏｌｅ２５５と同一であり得る。本フィールド値の意味は、実施例によって異なって設定されてもよい。
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇは、当該コンポーネントが保護されるか（例えば、暗号化されるか）を示す属性である。当該フラグが１の値に設定されると、当該コンポーネントは保護される（例えば、暗号化される）。当該フラグが０の値に設定されると、当該コンポーネントは保護されない（例えば、暗号化されない）。存在しない場合、ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性の値は０と同一であると推論される。本フィールド値の意味は、実施例によって異なって設定されてもよい。
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＩｄは、当該コンポーネントの識別子を示す属性である。当該属性の値は、当該コンポーネントに該当するＭＰテーブルにおいてａｓｓｅｔ_ｉｄと同一であり得る。
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＮａｍｅは、当該コンポーネントの人が読み取り可能な名を示す属性である。
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は、各フィールドに関するもので、Ｍは必須のフィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
以下、ＭＭＴのためのＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）について説明する。
ＭＰＤは、放送会社によって定められた与えられたデューレーションのリニアサービスに該当するＳＬＳメタデータ分割である（例えば、一つのＴＶプログラム、またはある期間の間の連続的なリニアＴＶプログラムの集合）。ＭＰＤのコンテンツは、分割に対するリソース識別子、及びメディアプレゼンテーション内で識別されたリソースに対するコンテキストを提供する。ＭＰＤのデータ構造及びセマンティクスは、ＭＰＥＧ ＤＡＳＨによって定義されたＭＰＤに従うことができる。
本発明の実施例において、ＭＭＴＰセッションによって伝達されるＭＰＤは、ハイブリッドサービスの場合のようなブロードバンド上で伝達されるレプレゼンテーションを記述したり、ブロードキャスト信号悪化（例えば、山の下やトンネルの中の走行）によるブロードキャストからブロードキャストへのハンドオフでサービス連続性を支援したりすることができる。
以下、ＭＭＴのためのＭＭＴシグナリングメッセージについて説明する。
ＭＭＴＰセッションがストリーミングサービスを伝達するために使用される場合、ＭＭＴによって定義されたＭＭＴシグナリングメッセージは、ＭＭＴによって定義されたシグナリングメッセージモードに応じてＭＭＴＰパケットによって伝達される。アセットを伝達するＭＭＴＰパケットと同一のｐａｃｋｅｔ_ｉｄ値に設定され得る、アセットに特定のＭＭＴシグナリングメッセージを伝達するＭＭＴＰパケットを除いて、ＳＬＳを伝達するＭＭＴＰパケットのｐａｃｋｅｔ_ｉｄフィールドの値は「００」に設定される。各サービスに対する適切なパケットを参照する識別子は、前述したように、ＵＳＢＤ分割によってシグナリングされる。マッチングするＭＭＴ_ｐａｃｋａｇｅ_ｉｄを有するＭＰＴメッセージは、ＳＬＴでシグナリングされるＭＭＴＰセッション上で伝達され得る。各ＭＭＴＰセッションは、そのセッションに特定のＭＭＴシグナリングメッセージ、またはＭＭＴＰセッションによって伝達される各アセットを伝達する。
すなわち、ＳＬＴで特定のサービスに対するＳＬＳを有するパケットのＩＰデスティネーションアドレス／ポートナンバーなどを特定して、ＭＭＴＰセッションのＵＳＢＤに接近することができる。前述したように、ＳＬＳを運搬するＭＭＴＰパケットのパケットＩＤは、００などの特定の値として指定できる。ＵＳＢＤの前述したパッケージＩＤ情報を用いて、マッチングされるパッケージＩＤを有するＭＰＴメッセージに接近することができる。ＭＰＴメッセージは、後述するように、各サービスコンポーネント／アセットに接近するために使用することができる。
次のＭＭＴＰメッセージは、ＳＬＴでシグナリングされるＭＭＴＰセッションによって伝達され得る。
ＭＰＴメッセージ：このメッセージは、全てのアセットのリスト及びＭＭＴによって定義されたようなそれらの位置情報を含む、ＭＰテーブルを伝達する。アセットがＭＰテーブルを伝達する現ＰＬＰと異なるＰＬＰによって伝達されると、当該アセットを伝達するＰＬＰの識別子は、ＰＬＰ識別子ディスクリプタを使用したＭＰテーブルで提供され得る。ＰＬＰ識別子ディスクリプタについては後述する。
ＭＭＴ ＡＴＳＣ３（ＭＡ３） ｍｅｓｓａｇｅ ｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）：このメッセージは、前述したように、ＳＬＳを含むサービスに特定のシステムメタデータを伝達する。ｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）については後述する。
次のＭＭＴＰメッセージは、必要であれば、ＳＬＴでシグナリングされたＭＭＴＰセッションによって伝達されてもよい。
ＭＰＩメッセージ：このメッセージは、プレゼンテーション情報の全てのドキュメントまたは一部のドキュメントを含む、ＭＰＩテーブルを伝達する。ＭＰＩテーブルと関連するＭＰテーブルは、このメッセージによって伝達され得る。
ＣＲＩ（ｃｌｏｃｋ ｒｅｌａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）メッセージ：このメッセージは、ＮＴＰタイムスタンプとＭＰＥＧ−２ ＳＴＣとの間のマッピングのためのクロック関連情報を含むＣＲＩテーブルを伝達する。実施例によって、ＣＲＩメッセージは当該ＭＭＴＰセッションを介して伝達されなくてもよい。
次のＭＭＴＰメッセージは、ストリーミングコンテンツを伝達する各ＭＭＴＰセッションによって伝達され得る。
仮想的な受信機バッファーモデルメッセージ：このメッセージは、バッファーを管理するために受信機によって要求される情報を伝達する。
仮想的な受信機バッファーモデル除去メッセージ：このメッセージは、ＭＭＴデカプセレーションバッファーを管理するために受信機によって要求される情報を伝達する。
以下、ＭＭＴシグナリングメッセージのうち１つであるｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）について説明する。ＭＭＴシグナリングメッセージであるｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）は、前述した本発明によって、サービスに特定の情報を伝達するために定義される。本シグナリングメッセージは、ＭＭＴシグナリングメッセージの基本的なフィールドであるメッセージＩＤ、バージョン及び／又は長さ（ｌｅｎｇｔｈ）フィールドを含むことができる。本シグナリングメッセージのペイロードには、サービスＩＤ情報、コンテンツタイプ、コンテンツバージョン、コンテンツコンプレッション情報及び／又はＵＲＩ情報が含まれてもよい。コンテンツタイプ情報は、本シグナリングメッセージのペイロードに含まれるデータのタイプを示すことができる。コンテンツバージョン情報は、ペイロードに含まれるデータのバージョンを、コンテンツコンプレッション情報は、当該データに適用されたコンプレッションタイプを示すことができる。ＵＲＩ情報は、本メッセージによって伝達されるコンテンツと関連するＵＲＩ情報を有することができる。
以下、ＰＬＰ識別子ディスクリプタについて説明する。
ＰＬＰ識別子ディスクリプタは、前述したＭＰテーブルのディスクリプタのうち１つとして使用できるディスクリプタである。ＰＬＰ識別子ディスクリプタは、アセットを伝達するＰＬＰに関する情報を提供する。アセットが、ＭＰテーブルを伝達する現在のＰＬＰと異なるＰＬＰによって伝達されると、ＰＬＰ識別子ディスクリプタは、そのアセットを伝達するＰＬＰを識別するために、関連するＭＰテーブルでアセットディスクリプタとして使用され得る。ＰＬＰ識別子ディスクリプタは、ＰＬＰ ＩＤ情報以外にＢＳＩＤ情報をさらに含むこともできる。ＢＳＩＤは、このディスクリプタによって記述されるＡｓｓｅｔのためのＭＭＴＰパケットを伝達するブロードキャストストリームのＩＤであり得る。
図８は、本発明の一実施例に係るリンクレイヤプロトコルアーキテクチャーを示した図である。
以下、リンクレイヤ（Ｌｉｎｋ Ｌａｙｅｒ）について説明する。
リンクレイヤは、フィジカルレイヤとネットワークレイヤとの間のレイヤであり、送信側では、ネットワークレイヤからフィジカルレイヤにデータを伝送し、受信側では、フィジカルレイヤからネットワークレイヤにデータを伝送する。リンクレイヤの目的は、フィジカルレイヤによる処理のために全ての入力パケットタイプを一つのフォーマットで要約すること、まだ定義されていない入力タイプに対する柔軟性、及び将来の拡張可能性を保障することである。また、リンクレイヤ内で処理すれば、例えば、入力パケットのヘッダーにある不必要な情報を圧縮するのにオプションを提供することによって、入力データを効率的に伝送できるように保障する。エンカプセレーション、コンプレッションなどの動作はリンクレイヤプロトコルと呼ばれ、当該プロトコルを用いて生成されたパケットはリンクレイヤパケットと呼ばれる。リンクレイヤは、パケットエンカプセレーション（ｐａｃｋｅｔ ｅｎｃａｐｓｕｌａｔｉｏｎ）、オーバーヘッドリダクション（Ｏｖｅｒｈｅａｄ Ｒｅｄｕｃｔｉｏｎ）及び／又はシグナリング伝送（Ｓｉｇｎａｌｉｎｇ Ｔｒａｎｓｍｉｓｓｉｏｎ）などの機能を行うことができる。
以下、パケットエンカプセレーションについて説明する。リンクレイヤプロトコルは、ＩＰパケット及びＭＰＥＧ−２ ＴＳのようなものを含む全てのタイプのパケットのエンカプセレーションを可能にする。リンクレイヤプロトコルを用いて、フィジカルレイヤは、ネットワークレイヤプロトコルタイプと独立して一つのパケットフォーマットのみを処理すればよい（ここで、ネットワークレイヤパケットの一種としてＭＰＥＧ−２ ＴＳパケットを考慮）。各ネットワークレイヤパケットまたは入力パケットは、ジェネリックリンクレイヤパケットのペイロードに変形する。追加的に、入力パケットのサイズが特に小さいかまたは大きい場合、フィジカルレイヤリソースを効率的に用いるために、連鎖及び分割を行うことができる。
前述したように、パケットエンカプセレーション過程で分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を活用することができる。ネットワークレイヤパケットが大きすぎるため、フィジカルレイヤで容易に処理できない場合、ネットワークレイヤパケットは２つ以上の分割に分けられる。リンクレイヤパケットヘッダーは、送信側で分割を行い、受信側で再結合を行うために、プロトコルフィールドを含む。ネットワークレイヤパケットが分割される場合、各分割は、ネットワークレイヤパケットでの元の位置と同一の順序でリンクレイヤパケットにエンカプセレーションされてもよい。また、ネットワークレイヤパケットの分割を含む各リンクレイヤパケットは、結果的にフィジカルレイヤに伝送されてもよい。
前述したように、パケットエンカプセレーション過程で連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）も活用することができる。リンクレイヤパケットのペイロードが多数のネットワークレイヤパケットを含む程度にネットワークレイヤパケットが十分に小さい場合、リンクレイヤパケットヘッダーは、連鎖を行うためにプロトコルフィールドを含む。連鎖は、多数の小さい大きさのネットワークレイヤパケットを一つのペイロードに結合したものである。ネットワークレイヤパケットが連鎖すれば、各ネットワークレイヤパケットは、元の入力順序と同一の順序でリンクレイヤパケットのペイロードに連鎖することができる。また、リンクレイヤパケットのペイロードを構成する各パケットは、パケットの分割ではない全体パケットであり得る。
以下、オーバーヘッドリダクションについて説明する。リンクレイヤプロトコルの使用により、フィジカルレイヤ上でデータの伝送に対するオーバーヘッドを大きく減少させることができる。本発明に係るリンクレイヤプロトコルは、ＩＰオーバーヘッドリダクション及び／又はＭＰＥＧ−２ ＴＳオーバーヘッドリダクションを提供することができる。ＩＰオーバーヘッドリダクションにおいて、ＩＰパケットは、固定されたヘッダーフォーマットを有しているが、通信環境で必要な一部の情報はブロードキャスト環境で不要なことがある。リンクレイヤプロトコルは、ＩＰパケットのヘッダーを圧縮することによってブロードキャストオーバーヘッドを低減するメカニズムを提供する。ＭＰＥＧ−２ ＴＳオーバーヘッドリダクションにおいて、リンクレイヤプロトコルは、シンクバイト除去、ヌルパケット削除及び／又は共通ヘッダー除去（圧縮）を提供する。まず、シンクバイト除去は、ＴＳパケット当たり１バイトのオーバーヘッドリダクションを提供し、次に、ヌルパケット削除メカニズムは、受信機で再挿入できる方式で１８８バイトのヌルＴＳパケットを除去する。最後に、共通ヘッダー除去メカニズムが提供される。
シグナリング伝送に対して、リンクレイヤプロトコルは、シグナリングパケットのための特定のフォーマットが、リンクレイヤシグナリングを伝送するために提供され得る。これについては後述する。
図示された本発明の一実施例に係るリンクレイヤプロトコルアーキテクチャーにおいて、リンクレイヤプロトコルは、入力パケットとして、ＩＰｖ４、ＭＰＥＧ−２ ＴＳなどのような入力ネットワークレイヤパケットを取る。将来の拡張は、他のパケットタイプとリンクレイヤで入力され得るプロトコルを示す。リンクレイヤプロトコルは、フィジカルレイヤで特定のチャンネルに対するマッピングに関する情報を含む全てのリンクレイヤシグナリングに対するシグナリング及びフォーマットを特定する。図面は、ＡＬＰがどのように様々なヘッダーコンプレッション及び削除アルゴリズムを介して伝送効率を向上させるためにメカニズムを含むかを示す。また、リンクレイヤプロトコルは、基本的に入力パケットをエンカプセレーションすることができる。
図９は、本発明の一実施例に係るリンクレイヤパケットのベースヘッダー構造を示した図である。以下、ヘッダーの構造について説明する。
リンクレイヤパケットは、データペイロードが後続するヘッダーを含むことができる。リンクレイヤパケットのヘッダーは、ベースヘッダーを含むことができ、ベースヘッダーのコントロールフィールドに応じて追加ヘッダーを含むことができる。オプショナルヘッダーの存在は、追加ヘッダーのフラグフィールドから指示される。実施例によって、追加ヘッダー、オプショナルヘッダーの存在を示すフィールドはベースヘッダーに位置してもよい。
以下、ベースヘッダーの構造について説明する。リンクレイヤパケットエンカプセレーションに対するベースヘッダーは階層構造を有する。ベースヘッダーは、２バイトの長さを有することができ、リンクレイヤパケットヘッダーの最小長さである。
図示された本発明の一実施例に係るベースヘッダーは、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド及び／又は長さ（ｌｅｎｇｔｈ）フィールドを含むことができる。実施例によって、ベースヘッダーは、ＨＭフィールド又はＳ／Ｃフィールドをさらに含むことができる。
Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは、リンクレイヤパケットへのエンカプセレーションの前の入力データのパケットタイプまたは元のプロトコルを示す、３ビットのフィールドである。ＩＰｖ４パケット、圧縮されたＩＰパケット（ｃｏｍｐｒｅｓｓｅｄ ＩＰ ｐａｃｋｅｔ）、リンクレイヤシグナリングパケット、及びその他のタイプのパケットが、このようなベースヘッダーの構造を有し、エンカプセレーションされてもよい。ただし、実施例によって、ＭＰＥＧ−２ ＴＳパケットは、これとは異なる特別な構造を有し、エンカプセレーションされてもよい。Ｐａｃｋｅｔ_Ｔｙｐｅの値が「０００」、「００１」、「１００」または「１１１」であると、ＡＬＰパケットの元のデータタイプは、ＩＰｖ４パケット、圧縮ＩＰパケット、リンクレイヤシグナリングまたはエクステンションパケットのうち１つである。ＭＰＥＧ−２ ＴＳパケットがカプセル化されると、Ｐａｃｋｅｔ_Ｔｙｐｅの値は「０１０」であり得る。他のＰａｃｋｅｔ_Ｔｙｐｅフィールドの値は、将来の使用のために残すことができる（ｒｅｓｅｒｖｅｄ ｆｏｒ ｆｕｔｕｒｅ ｕｓｅ）。
Ｐａｙｌｏａｄ_Ｃｏｎｆｉｇｕｒａｔｉｏｎ（ＰＣ）フィールドは、ペイロードの構成を示す１ビットのフィールドであり得る。０の値は、リンクレイヤパケットが一つの全体の入力パケットを伝達し、次のフィールドがＨｅａｄｅｒ_Ｍｏｄｅであることを示すことができる。１の値は、リンクレイヤパケットが１つ以上の入力パケット（連鎖）や大きい入力パケット（分割）の一部を伝達し、次のフィールドがＳｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎであることを示すことができる。
Ｈｅａｄｅｒ_Ｍｏｄｅ（ＨＭ）フィールドは、０に設定される場合、追加ヘッダーがないことを示し、リンクレイヤパケットのペイロードの長さが２０４８バイトよりも小さいことを示す、１ビットのフィールドであり得る。この数値は、実施例によって変更されてもよい。１の値は、下記に定義された１つのパケットのための追加ヘッダーが長さフィールドの次に存在することを示すことができる。この場合、ペイロードの長さは、２０４７バイトよりも大きく、及び／又はオプショナルフィーチャが使用され得る（サブストリーム識別、ヘッダー拡張など）。この数値は、実施例によって変更されてもよい。本フィールドは、リンクレイヤパケットのＰａｙｌｏａｄ_Ｃｏｎｆｉｇｕｒａｔｉｏｎフィールドが０の値を有するときのみ存在し得る。
Ｓｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）フィールドは、０に設定された場合、ペイロードが入力パケットのセグメントを伝達し、下記に定義される分割のための追加ヘッダーが長さフィールドの次に存在することを示す、１ビットのフィールドであり得る。１の値は、ペイロードが１つよりも多い完全な入力パケットを伝達し、下記に定義された連鎖のための追加ヘッダーが長さフィールドの次に存在することを示すことができる。本フィールドは、ＡＬＰパケットのＰａｙｌｏａｄ_Ｃｏｎｆｉｇｕｒａｔｉｏｎフィールドの値が１であるときのみ存在し得る。
長さフィールドは、リンクレイヤパケットによって伝達されるペイロードのバイト単位の長さの１１ＬＳＢｓ（ｌｅａｓｔ ｓｉｇｎｉｆｉｃａｎｔ ｂｉｔｓ）を示す、１１ビットのフィールドであり得る。次の追加ヘッダーにＬｅｎｇｔｈ_ＭＳＢフィールドがあれば、長さフィールドは、Ｌｅｎｇｔｈ_ＭＳＢフィールドに連鎖し、ペイロードの実際の全長を提供するためにＬＳＢとなる。長さフィールドのビット数は、１１ビット以外に他のビットに変更されてもよい。
したがって、次のパケット構造のタイプが可能である。すなわち、追加ヘッダーがない１つのパケット、追加ヘッダーがある１つのパケット、分割されたパケット、連鎖したパケットが可能である。実施例によって、各追加ヘッダーとオプショナルヘッダー、後述するシグナリング情報のための追加ヘッダーとタイプエクステンションのための追加ヘッダーによる組み合わせで、さらに多くのパケット構成が可能である。
図１０は、本発明の一実施例に係るリンクレイヤパケットの追加ヘッダーの構造を示した図である。
追加ヘッダー（ａｄｄｉｔｉｏｎａｌ ｈｅａｄｅｒ）は様々なタイプがあり得る。以下、シングルパケットのための追加ヘッダーについて説明する。
１つのパケットに対する当該追加ヘッダーは、Ｈｅａｄｅｒ_Ｍｏｄｅ（ＨＭ）＝「１」である場合に存在し得る。リンクレイヤパケットのペイロードの長さが２０４７バイトよりも大きいか、またはオプションフィールドが使用される場合、Ｈｅａｄｅｒ_Ｍｏｄｅ（ＨＭ）は１に設定され得る。１つのパケットの追加ヘッダー（ｔｓｉｂ１００１０）は図面に示す。
Ｌｅｎｇｔｈ_ＭＳＢフィールドは、現在のリンクレイヤパケットにおいてバイト単位の全ペイロードの長さのＭＳＢｓ（ｍｏｓｔ ｓｉｇｎｉｆｉｃａｎｔ ｂｉｔｓ）を示すことができる、５ビットのフィールドであり得、全ペイロードの長さを得るために、１１ＬＳＢを含む長さフィールドに連鎖する。したがって、シグナリングできるペイロードの最大長さは６５５３５バイトである。長さフィールドのビット数は、１１ビット以外の他のビットに変更されてもよい。また、Ｌｅｎｇｔｈ_ＭＳＢフィールドも、ビット数が変更されてもよく、これによって、最大に表現可能なペイロードの長さも変更されてもよい。実施例によって、各長さフィールドは、ペイロードではなく全リンクレイヤパケットの長さを示してもよい。
Ｓｕｂ−ｓｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒ Ｆｌａｇ（ＳＩＦ）フィールドは、ＨＥＦ（Ｈｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎ Ｆｌａｇ）フィールドの後にＳＩＤ（ｓｕｂ−ｓｔｒｅａｍ ＩＤ）が存在するか否かを示すことができる、１ビットのフィールドであり得る。リンクレイヤパケットにＳＩＤが存在しなければ、ＳＩＦフィールドは０に設定され得る。リンクレイヤパケットにおいてＨＥＦフィールドの後にＳＩＤが存在すれば、ＳＩＦは１に設定され得る。ＳＩＤについての詳細は後述する。
ＨＥＦフィールドは、１に設定される場合、将来の拡張のために追加ヘッダーが存在することを示すことができる、１ビットのフィールドであり得る。０の値は、この拡張フィールダーが存在しないことを示すことができる。
以下、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）が活用される場合における追加ヘッダーについて説明する。
Ｓｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）＝「０」である場合、追加ヘッダー（ｔｓｉｂ１００２０）が存在し得る。Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒは、リンクレイヤパケットによって伝達される当該分割の順序を示すことができる、５ビットの符号なし整数であり得る。入力パケットの最初の分割を伝達するリンクレイヤパケットに対して、当該フィールドの値は０ｘ０に設定され得る。当該フィールドは、分割される入力パケットに属する各追加セグメント毎に１ずつ増分し得る。
ＬＳＩ（Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒ）は、１に設定される場合、当該ペイロードにある分割が入力パケットの最後のものであることを示すことができる、１ビットのフィールドであり得る。０の値は、それが最後の分割ではないことを示すことができる。
ＳＩＦ（Ｓｕｂ−ｓｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒ Ｆｌａｇ）は、ＳＩＤがＨＥＦフィールドの後に存在するか否かを示すことができる、１ビットのフィールドであり得る。リンクレイヤパケットにＳＩＤが存在しなければ、ＳＩＦフィールドは０に設定され得る。リンクレイヤパケットにおいてＨＥＦフィールドの後にＳＩＤが存在すれば、ＳＩＦは１に設定され得る。
ＨＥＦフィールドは、１に設定される場合、リンクレイヤヘッダーの将来の拡張のために追加ヘッダーの後にオプショナルヘッダー拡張が存在することを示すことができる、１ビットのフィールドであり得る。０の値は、オプショナルヘッダー拡張が存在しないことを示すことができる。
実施例によって、各分割されたセグメントが同一の入力パケットから生成されたことを示すパケットＩＤフィールドが追加されてもよい。このフィールドは、分割されたセグメントが順に伝送されれば必要でないので、省略されてもよい。
以下、連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）が活用される場合における追加ヘッダーについて説明する。
Ｓｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）＝「１」である場合、追加ヘッダー（ｔｓｉｂ１００３０）が存在し得る。
Ｌｅｎｇｔｈ_ＭＳＢは、当該リンクレイヤパケットにおいてバイト単位のペイロードの長さのＭＳＢビットを示すことができる、４ビットのフィールドであり得る。当該ペイロードの最大長さは、連鎖のために３２７６７バイトとなる。前述したものと同様に、詳細な数値は変更されてもよい。
Ｃｏｕｎｔフィールドは、リンクレイヤパケットに含まれたパケットの数を示すことができるフィールドであり得る。リンクレイヤパケットに含まれたパケットの数に該当する２は、当該フィールドに設定され得る。したがって、リンクレイヤパケットにおいて連鎖したパケットの最大値は９である。Ｃｏｕｎｔフィールドがその個数を指示する方法は、実施例毎に異なり得る。すなわち、１から８までの個数が指示されてもよい。
ＨＥＦフィールドは、１に設定される場合、リンクレイヤヘッダーの将来の拡張のために追加ヘッダーの後にオプショナルヘッダー拡張が存在することを示すことができる、１ビットのフィールドであり得る。０の値は、拡張ヘッダーが存在しないことを示すことができる。
Ｃｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈは、各パケットのバイト単位の長さを示すことができる１２ビットのフィールドであり得る。Ｃｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈフィールドは、最後のコンポーネントパケットを除いて、ペイロードに存在するパケットと同一の順序で含まれる。長さフィールドの数は、（Ｃｏｕｎｔ＋１）によって示すことができる。実施例によって、Ｃｏｕｎｔフィールドの値と同一の数の長さフィールドが存在してもよい。リンクレイヤヘッダーが奇数のＣｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈで構成される場合、４個のスタッフィングビットが最後のＣｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈフィールドに後続することができる。これらビットは０に設定され得る。実施例によって、最後の連鎖したインプットパケットの長さを示すＣｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈフィールドは存在しないこともある。この場合、最後の連鎖したインプットパケットの長さは、全ペイロードの長さから、各Ｃｏｍｐｏｎｅｎｔ_ｌｅｎｇｔｈフィールドが示す値の和を引いた長さで指示することができる。
以下、オプショナルヘッダーについて説明する。
前述したように、オプショナルヘッダーは、追加ヘッダーの後ろに追加されてもよい。オプショナルヘッダーフィールドは、ＳＩＤ及び／又はヘッダー拡張を含むことができる。ＳＩＤは、リンクレイヤレベルで特定のパケットストリームをフィルタリングするのに使用される。ＳＩＤの一例は、多数のサービスを伝達するリンクレイヤストリームにおいてサービス識別子の役割を果たす。適用可能な場合、サービスと、サービスに該当するＳＩＤ値との間のマッピング情報はＳＬＴで提供され得る。ヘッダー拡張は、将来の使用のための拡張フィールドを含む。受信機は、自身が理解できない全てのヘッダー拡張を無視し得る。
ＳＩＤは、リンクレイヤパケットに対するサブストリーム識別子を示すことができる８ビットのフィールドであり得る。オプショナルヘッダー拡張があれば、ＳＩＤは、追加ヘッダーとオプショナルヘッダー拡張との間に存在する。
Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）は、下記に定義されたフィールドを含むことができる。
Ｅｘｔｅｎｓｉｏｎ_Ｔｙｐｅは、Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）のタイプを示すことができる８ビットのフィールドであり得る。
Ｅｘｔｅｎｓｉｏｎ_Ｌｅｎｇｔｈは、Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）の次のバイトから最後のバイトまでカウントされるＨｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎ（）のバイトの長さを示すことができる、８ビットのフィールドであり得る。
Ｅｘｔｅｎｓｉｏｎ_Ｂｙｔｅは、Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）の値を示すバイトであり得る。
図１１は、本発明の他の実施例に係るリンクレイヤパケットの追加ヘッダーの構造を示した図である。
以下、シグナリング情報のための追加ヘッダーについて説明する。
リンクレイヤシグナリングがどのようにリンクレイヤパケットに含まれるかは、次の通りである。シグナリングパケットは、ベースヘッダーのＰａｃｋｅｔ_Ｔｙｐｅフィールドが１００と同一であるときに識別される。
図（ｔｓｉｂ１１０１０）は、シグナリング情報のための追加ヘッダーを含むリンクレイヤパケットの構造を示す。リンクレイヤヘッダーだけでなく、リンクレイヤパケットは、シグナリング情報のための追加ヘッダー及び実際のシグナリングデータ自体の２つの追加部分で構成され得る。リンクレイヤシグナリングパケットの全長はリンクレイヤパケットヘッダーに示す。
シグナリング情報のための追加ヘッダーは、次のフィールドを含むことができる。実施例によって一部のフィールドは省略されてもよい。
Ｓｉｇｎａｌｉｎｇ_Ｔｙｐｅは、シグナリングのタイプを示すことができる８ビットのフィールドであり得る。
Ｓｉｇｎａｌｉｎｇ_Ｔｙｐｅ_Ｅｘｔｅｎｓｉｏｎは、シグナリングの属性を示すことができる１６ビットのフィールドであり得る。当該フィールドの詳細はシグナリングの仕様で定義され得る。
Ｓｉｇｎａｌｉｎｇ_Ｖｅｒｓｉｏｎは、シグナリングのバージョンを示すことができる８ビットのフィールドであり得る。
Ｓｉｇｎａｌｉｎｇ_Ｆｏｒｍａｔは、シグナリングデータのデータフォーマットを示すことができる２ビットのフィールドであり得る。ここで、シグナリングフォーマットとは、バイナリ、ＸＭＬなどのデータフォーマットを意味し得る。
Ｓｉｇｎａｌｉｎｇ_Ｅｎｃｏｄｉｎｇは、エンコーディング／コンプレッションフォーマットを特定することができる２ビットのフィールドであり得る。本フィールドは、コンプレッションが行われなかったか、どのような特定のコンプレッションが行われたかを示すことができる。
以下、パケットタイプの拡張のための追加ヘッダーについて説明する。
将来にリンクレイヤによって伝達されるパケットタイプ及び追加プロトコルの無制限に近い数を許容するメカニズムを提供するために、追加ヘッダーが定義される。前述したように、ベースヘッダーでＰａｃｋｅｔ_ｔｙｐｅが１１１である場合、パケットタイプの拡張が使用され得る。図（ｔｓｉｂ１１０２０）は、タイプの拡張のための追加ヘッダーを含むリンクレイヤパケットの構造を示す。
タイプの拡張のための追加ヘッダーは、次のフィールドを含むことができる。実施例によって一部のフィールドは省略されてもよい。
ｅｘｔｅｎｄｅｄ_ｔｙｐｅは、ペイロードとしてリンクレイヤパケットにエンカプセレーションされる入力のプロトコルやパケットタイプを示すことができる、１６ビットのフィールドであり得る。当該フィールドは、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドによって既に定義された全てのプロトコルやパケットタイプに対して使用することができない。
図１２は、本発明の一実施例に係る、ＭＰＥＧ−２ ＴＳパケットのためのリンクレイヤパケットのヘッダーの構造、及びそのエンカプセレーションの過程を示した図である。
以下、入力パケットとしてＭＰＥＧ−２ ＴＳパケットが入力されたとき、リンクレイヤパケットのフォーマットについて説明する。
この場合、ベースヘッダーのＰａｃｋｅｔ_Ｔｙｐｅフィールドは０１０と同一である。各リンクレイヤパケット内で多数のＴＳパケットがエンカプセレーションされてもよい。ＴＳパケットの数は、ＮＵＭＴＳフィールドを介してシグナリングされてもよい。この場合、前述したように、特別なリンクレイヤパケットヘッダーフォーマットが使用されてもよい。
リンクレイヤは、伝送効率を向上させるために、ＭＰＥＧ−２ ＴＳのためのオーバーヘッドリダクションメカニズムを提供する。各ＴＳパケットのシンクバイト（０ｘ４７）は削除され得る。ヌルパケット及び類似のＴＳヘッダーを削除するオプションも提供される。
不必要な伝送オーバーヘッドを避けるために、ＴＳヌルパケット（ＰＩＤ＝０ｘ１ＦＦＦ）を除去することができる。削除されたヌルパケットは、ＤＮＰフィールドを用いて受信機側で復旧することができる。ＤＮＰフィールドは、削除されたヌルパケットのカウントを示す。ＤＮＰフィールドを用いたヌルパケット削除メカニズムは、後述する。
伝送効率をさらに向上させるために、ＭＰＥＧ−２ ＴＳパケットの類似のヘッダーを除去することができる。２つ以上の順次的なＴＳパケットがＣＣ（ｃｏｎｔｉｎｕｉｔｙ ｃｏｕｎｔｅｒ）フィールドを順次増加させ、他のヘッダーフィールドも同一であれば、ヘッダーが最初のパケットで一回伝送され、他のヘッダーは削除される。ＨＤＭフィールドは、ヘッダーが削除されたか否かを示すことができる。共通ＴＳヘッダー削除の詳細な過程は後述する。
３つのオーバーヘッドリダクションメカニズムが全て行われる場合、オーバーヘッドリダクションは、シンク除去、ヌルパケット削除、共通ヘッダー削除の順に行うことができる。実施例によって、各メカニズムが行われる順序は変更されてもよい。また、実施例によって一部のメカニズムは省略されてもよい。
ＭＰＥＧ−２ ＴＳパケットエンカプセレーションを使用する場合のリンクレイヤパケットヘッダーの全体的な構造が図（ｔｓｉｂ１２０１０）に示されている。
以下、図示された各フィールドについて説明する。Ｐａｃｋｅｔ_Ｔｙｐｅは、前述したように、入力パケットのプロトコルタイプを示すことができる３ビットのフィールドであり得る。ＭＰＥＧ−２ ＴＳパケットエンカプセレーションのために、当該フィールドは、常に０１０に設定され得る。
ＮＵＭＴＳ（Ｎｕｍｂｅｒ ｏｆ ＴＳ ｐａｃｋｅｔｓ）は、当該リンクレイヤパケットのペイロードでＴＳパケットの数を示すことができる４ビットのフィールドであり得る。最大１６個のＴＳパケットが一つのリンクレイヤパケットで支援され得る。ＮＵＭＴＳ＝０の値は、１６個のＴＳパケットがリンクレイヤパケットのペイロードによって伝達されることを示すことができる。ＮＵＭＴＳの他の全ての値に対して、同じ数のＴＳパケットが認識される。例えば、ＮＵＭＴＳ＝０００１は、一つのＴＳパケットが伝達されることを意味する。
ＡＨＦ（ａｄｄｉｔｉｏｎａｌ ｈｅａｄｅｒ ｆｌａｇ）は、追加ヘッダーが存在するか否かを示すことができるフィールドであり得る。０の値は、追加ヘッダーが存在しないことを示す。１の値は、１バイト長の追加ヘッダーがベースヘッダーの次に存在することを示す。ヌルＴＳパケットが削除されるか、またはＴＳヘッダーコンプレッションが適用されれば、当該フィールドは１に設定され得る。ＴＳパケットエンカプセレーションのための追加ヘッダーは、次の２つのフィールドで構成され、当該リンクレイヤパケットでのＡＨＦの値が１に設定される場合にのみ存在する。
ＨＤＭ（ｈｅａｄｅｒ ｄｅｌｅｔｉｏｎ ｍｏｄｅ）は、ＴＳヘッダー削除を当該リンクレイヤパケットに適用できるか否かを示す１ビットのフィールドであり得る。１の値は、ＴＳヘッダー削除を適用できることを示す。０の値は、ＴＳヘッダー削除の方法が当該リンクレイヤパケットに適用されないことを示す。
ＤＮＰ（ｄｅｌｅｔｅｄ ｎｕｌｌ ｐａｃｋｅｔｓ）は、当該リンクレイヤパケットの前に削除されたヌルＴＳパケットの数を示す７ビットのフィールドであり得る。最大１２８個のヌルＴＳパケットが削除され得る。ＨＤＭ＝０である場合、ＤＮＰ＝０の値は、１２８個のヌルパケットが削除されることを示すことができる。ＨＤＭ＝１である場合、ＤＮＰ＝０の値は、ヌルパケットが削除されないことを示すことができる。ＤＮＰの他の全ての値に対して、同じ数のヌルパケットが認識される。例えば、ＤＮＰ＝５は、５個のヌルパケットが削除されることを意味する。
前述した各フィールドのビット数は変更可能であり、変更されたビット数に応じて、当該フィールドが指示する値の最小／最大値は変更され得る。これは、設計者の意図によって変更されてもよい。
以下、シンクバイト削除（ＳＹＮＣ ｂｙｔｅ ｒｅｍｏｖａｌ）について説明する。
ＴＳパケットをリンクレイヤパケットのペイロードにカプセル化する場合、各ＴＳパケットの開始からシンクバイト（０ｘ４７）が削除され得る。したがって、リンクレイヤパケットのペイロードにカプセル化されたＭＰＥＧ ２−ＴＳパケットの長さは（元の１８８バイトの代わりに）、常に１８７バイトである。
以下、ヌルパケット削除（Ｎｕｌｌ Ｐａｃｋｅｔ Ｄｅｌｅｔｉｏｎ）について説明する。
伝送ストリーム規則は、送信機のマルチプレクサの出力及び受信機のデマルチプレクサの入力でのビットレートが時間に対して一定であり、終端間の遅延も一定であることを要求する。一部の伝送ストリーム入力信号に対して、ヌルパケットは、一定のビットレートストリームに可変的なビットレートサービスを収容するために存在することができる。この場合、不必要な伝送オーバーヘッドを避けるために、ＴＳヌルパケット（即ち、ＰＩＤ＝０ｘ１ＦＦＦであるＴＳパケット）が除去され得る。この処理は、除去されたヌルパケットが受信機で元の正確な位置に再び挿入され得る方式で実行されるので、一定のビットレートを保障し、ＰＣＲタイムスタンプアップデートを行う必要がなくなる。
リンクレイヤパケットの生成の前に、ＤＮＰと呼ばれるカウンターは、まず、０にリセットされた後に、現在のリンクレイヤパケットのペイロードにエンカプセレーションされる最初のヌルＴＳパケットではない、パケットに先行する各削除されたヌルパケットに対して増分され得る。その後、連続した有用なＴＳパケットのグループが現在のリンクレイヤパケットのペイロードにエンカプセレーションされ、そのヘッダーでの各フィールドの値が決定され得る。生成されたリンクレイヤパケットがフィジカルレイヤに注入された後、ＤＮＰは０にリセットされる。ＤＮＰが最高の許容値に到達する場合、次のパケットもヌルパケットであれば、当該ヌルパケットは有用なパケットに維持され、次のリンクレイヤパケットのペイロードにエンカプセレーションされる。各リンクレイヤパケットは、それのペイロードに少なくとも１つの有用なＴＳパケットを含むことができる。
以下、ＴＳパケットヘッダー削除（ＴＳ Ｐａｃｋｅｔ Ｈｅａｄｅｒ Ｄｅｌｅｔｉｏｎ）について説明する。ＴＳパケットヘッダー削除は、ＴＳパケットヘッダー圧縮と呼ぶこともできる。
２つ以上の順次的なＴＳパケットがＣＣフィールドを順次増加させ、他のヘッダーフィールドも同一であれば、ヘッダーが最初のパケットで一回伝送され、他のヘッダーは削除される。重複したＭＰＥＧ−２ ＴＳパケットが２つ以上の順次的なＴＳパケットに含まれると、ヘッダーの削除は送信機側で適用することができない。ＨＤＭフィールドは、ヘッダーが削除されるか否かを示すことができる。ＴＳヘッダーが削除される場合、ＨＤＭは１に設定され得る。受信機側で、最初のパケットヘッダーを用いて、削除されたパケットヘッダーが復旧され、ＣＣが最初のヘッダーから順に増加することによって復旧される。
図示された実施例（ｔｓｉｂ１２０２０）は、ＴＳパケットのインプットストリームがリンクレイヤパケットにエンカプセレーションされる過程の一実施例である。まず、ＳＹＮＣバイト（０ｘ４７）を有するＴＳパケットからなるＴＳストリームが入力され得る。まず、ＳＹＮＣバイトの削除過程を通じてシンクバイトを削除することができる。この実施例において、ヌルパケット削除は行われないと仮定する。
ここで、図示された８個のＴＳパケットのパケットヘッダーにおいて、ＣＣ、すなわち、Ｃｏｕｎｔｉｎｕｉｔｙ Ｃｏｕｎｔｅｒフィールド値を除いた他の値が全て同一であると仮定する。この場合、ＴＳパケット削除／圧縮を行うことができる。ＣＣ＝１である最初のＴＳパケットのヘッダーのみを残し、残りの７個のＴＳパケットのヘッダーを削除する。処理されたＴＳパケットは、リンクレイヤパケットのペイロードにエンカプセレーションされてもよい。
完成されたリンクレイヤパケットを見ると、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは、ＴＳパケットが入力された場合であるので０１０の値を有することができる。ＮＵＭＴＳフィールドは、エンカプセレーションされたＴＳパケットの個数を示すことができる。ＡＨＦフィールドは、パケットヘッダーの削除が行われたので１に設定され、追加ヘッダーの存在を知らせることができる。ＨＤＭフィールドは、ヘッダーの削除が行われたので１に設定され得る。ＤＮＰは、ヌルパケットの削除が行われなかったので、０に設定され得る。
図１３は、本発明の一実施例に係るＩＰヘッダー圧縮において、アダプテーションモードの実施例を示した図である（送信側）。
以下、ＩＰヘッダー圧縮（ＩＰ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）について説明する。
リンクレイヤにおいて、ＩＰヘッダーコンプレッション／デコンプレッションスキームが提供され得る。ＩＰヘッダーコンプレッションは、ヘッダーコンプレッサー／デコンプレッサー及びアダプテーションモジュールの２つの部分を含むことができる。ヘッダーコンプレッションスキームはＲｏＨＣに基づくことができる。また、放送用途にアダプテーション機能が追加される。
送信機側で、ＲｏＨＣコンプレッサーは、各パケットに対してヘッダーの大きさを減少させる。その後、アダプテーションモジュールは、コンテキスト情報を抽出し、各パケットストリームからシグナリング情報を生成する。受信機側で、アダプテーションモジュールは、受信されたパケットストリームと関連するシグナリング情報をパーシングし、コンテキスト情報を受信されたパケットストリームに添付する。ＲｏＨＣデコンプレッサーは、パケットヘッダーを復旧することによって元のＩＰパケットを再構成する。
ヘッダーコンプレッションスキームは、前述したように、ＲＯＨＣをベースとすることができる。特に、本システムでは、ＲＯＨＣのＵモード（ｕｎｉ ｄｉｒｃｔｉｏｎａｌ ｍｏｄｅ）でＲＯＨＣフレームワークが動作することができる。また、本システムにおいて、０ｘ０００２のプロファイル識別子で識別されるＲＯＨＣ ＵＤＰヘッダーコンプレッションプロファイルが使用され得る。
以下、アダプテーション（Ａｄａｐｔａｔｉｏｎ）について説明する。
単方向リンクを介した伝送の場合、受信機がコンテキストの情報を有していないと、デコンプレッサーは、完全なコンテキストを受信する時まで、受信されたパケットヘッダーを復旧することができない。これは、チャンネル変更遅延及びターンオンディレイ（ｔｕｒｎ−ｏｎ ｄｅｌａｙ）を招くことがある。このような理由で、コンプレッサーとデコンプレッサーとの間のコンフィギュレーションパラメータ及びコンテキスト情報は、常にパケットフローと共に伝送され得る。
アダプテーション機能は、コンフィギュレーションパラメータ及びコンテキスト情報の帯域外伝送を提供する。帯域外伝送は、リンクレイヤシグナリングを通じて行うことができる。したがって、アダプテーション機能は、コンテキスト情報の損失によるデコンプレッションエラー及びチャンネル変更遅延を減少させるために用いられる。
以下、コンテキスト情報（Ｃｏｎｔｅｘｔ Ｉｎｆｏｒｍａｔｉｏｎ）の抽出について説明する。
コンテキスト情報の抽出は、アダプテーションモードに応じて様々な方法で行うことができる。本発明では、以下の３つの実施例について説明する。本発明の範囲は、後述するアダプテーションモードの実施例に限定されない。ここで、アダプテーションモードは、コンテキスト抽出モードと呼ぶこともできる。
アダプテーションモード１（図示せず）は、基本的なＲＯＨＣパケットストリームに対していかなる追加的な動作も加えられていないモードであり得る。すなわち、このモードでアダプテーションモジュールは、バッファーとして動作することができる。したがって、このモードでは、リンクレイヤシグナリングにコンテキスト情報が含まれていない。
アダプテーションモード２（ｔｓｉｂ１３０１０）において、アダプテーションモジュールは、ＲｏＨＣパケットフローからＩＲパケットを検出し、コンテキスト情報（スタティックチェーン）を抽出することができる。コンテキスト情報を抽出した後、各ＩＲパケットは、ＩＲ−ＤＹＮパケットに転換され得る。転換されたＩＲ−ＤＹＮパケットは、元のパケットの代わりに、ＩＲパケットと同一の順序でＲｏＨＣパケットフロー内に含まれて伝送され得る。
アダプテーションモード３（ｔｓｉｂ１３０２０）において、アダプテーションモジュールは、ＲｏＨＣパケットフローからＩＲ及びＩＲ−ＤＹＮパケットを検出し、コンテキスト情報を抽出することができる。スタティックチェーン及びダイナミックチェーンはＩＲパケットから抽出することができ、ダイナミックチェーンはＩＲ−ＤＹＮパケットから抽出することができる。コンテキスト情報を抽出した後、それぞれのＩＲ及びＩＲ−ＤＹＮパケットは圧縮されたパケットに転換され得る。圧縮されたパケットのフォーマットは、ＩＲまたはＩＲ−ＤＹＮパケットの次のパケットと同一であり得る。転換された圧縮パケットは、元のパケットの代わりに、ＩＲまたはＩＲ−ＤＹＮパケットと同一の順序でＲｏＨＣパケットフロー内に含まれて伝送され得る。
シグナリング（コンテキスト）情報は、伝送構造に基づいてエンカプセレーションされ得る。例えば、コンテキスト情報は、リンクレイヤシグナリングにエンカプセレーションされ得る。この場合、パケットタイプ値は１００に設定され得る。
前述したアダプテーションモード２、３に対して、コンテキスト情報に対するリンクレイヤパケットは、１００のＰａｃｋｅｔ Ｔｙｐｅフィールド値を有することができる。また、圧縮されたＩＰパケットに対するリンクレイヤパケットは、００１のＰａｃｋｅｔ Ｔｙｐｅフィールド値を有することができる。これは、それぞれシグナリング情報、圧縮されたＩＰパケットがリンクレイヤパケットに含まれていることを示すもので、前述した通りである。
以下、抽出されたコンテキスト情報を伝送する方法について説明する。
抽出されたコンテキスト情報は、特定のフィジカルデータ経路を介してシグナリングデータと共に、ＲｏＨＣパケットフローと別途に伝送され得る。コンテキストの伝送は、フィジカルレイヤ経路の構成に依存する。コンテキスト情報は、シグナリングデータパイプを介して他のリンクレイヤシグナリングと共に伝送され得る。
すなわち、コンテキスト情報を有するリンクレイヤパケットは、他のリンクレイヤシグナリング情報を有するリンクレイヤパケットと共にシグナリングＰＬＰを介して伝送され得る（Ｐａｃｋｅｔ_Ｔｙｐｅ＝１００）。コンテキスト情報が抽出された圧縮ＩＰパケットは、一般的なＰＬＰを介して伝送され得る（Ｐａｃｋｅｔ_Ｔｙｐｅ＝００１）。ここで、実施例によって、シグナリングＰＬＰは、Ｌ１シグナリングパス（ｐａｔｈ）を意味してもよい。また、実施例によって、シグナリングＰＬＰは、一般的なＰＬＰと区分されず、シグナリング情報が伝送される特定の一般ＰＬＰを意味してもよい。
受信側では、パケットストリームを受信するに先立ち、受信機がシグナリング情報を得る必要がある。受信機が、シグナリング情報を獲得するために最初のＰＬＰをデコーディングすると、コンテキストシグナリングも受信することができる。シグナリングの獲得が行われた後、パケットストリームを受信するためのＰＬＰが選択され得る。すなわち、受信機は、まず、イニシャルＰＬＰを選択して、コンテキスト情報を含めてシグナリング情報を得ることができる。ここで、イニシャルＰＬＰは、前述したシグナリングＰＬＰであり得る。この後、受信機は、パケットストリームを得るためのＰＬＰを選択することができる。これを通じて、コンテキスト情報は、パケットストリームの受信に先立って獲得できる。
パケットストリームを得るためのＰＬＰが選択された後、アダプテーションモジュールは、受信されたパケットフローからＩＲ−ＤＹＮパケットを検出することができる。その後、アダプテーションモジュールは、シグナリングデータにおいてコンテキスト情報からスタティックチェーンをパーシングする。これは、ＩＲパケットを受信することと類似している。同一のコンテキスト識別子に対して、ＩＲ−ＤＹＮパケットはＩＲパケットに復旧され得る。復旧されたＲｏＨＣパケットフローはＲｏＨＣデコンプレッサーに送られる。その後、デコンプレッションが開始され得る。
図１４は、本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ Ｍａｐｐｉｎｇ Ｔａｂｌｅ）及びＲＯＨＣ−Ｕディスクリプションテーブルを示した図である。
以下、リンクレイヤシグナリングについて説明する。
主に、リンクレイヤシグナリングはＩＰレベル下で動作する。受信機側で、リンクレイヤシグナリングは、ＳＬＴ及びＳＬＳのようなＩＰレベルシグナリングよりも先に獲得され得る。したがって、リンクレイヤシグナリングはセッション設定の前に獲得できる。
リンクレイヤシグナリングに対して、入力経路に応じて、インターナルリンクレイヤシグナリング及びエクスターナルリンクレイヤシグナリングの２種類のシグナリングが存在することができる。インターナルリンクレイヤシグナリングは、送信機側でリンクレイヤで生成される。また、リンクレイヤは、外部のモジュールまたはプロトコルからシグナリングを取る。このような種類のシグナリング情報はエクスターナルリンクレイヤシグナリングであると見なされる。一部のシグナリングがＩＰレベルシグナリングに先立って獲得される必要があれば、外部のシグナリングは、リンクレイヤパケットのフォーマットで伝送される。
リンクレイヤシグナリングは、前述したように、リンクレイヤパケットにエンカプセレーションされ得る。リンクレイヤパケットは、バイナリ及びＸＭＬを含んだ全てのフォーマットのリンクレイヤシグナリングを伝達することができる。同一のシグナリング情報がリンクレイヤシグナリングに対して異なるフォーマットで伝送され得る。
インターナルリンクレイヤシグナリングには、リンクマッピングのためのシグナリング情報が含まれてもよい。ＬＭＴは、ＰＬＰに伝達される上位レイヤセッションのリストを提供する。ＬＭＴはまた、リンクレイヤで上位レイヤセッションを伝達するリンクレイヤパケットを処理するための追加情報を提供する。
本発明に係るＬＭＴの一実施例（ｔｓｉｂ１４０１０）が図示された。
ｓｉｇｎａｌｉｎｇ_ｔｙｐｅは、当該テーブルによって伝達されるシグナリングのタイプを示す８ビットの符号なし整数フィールドであり得る。ＬＭＴに対するｓｉｇｎａｌｉｎｇ_ｔｙｐｅフィールドの値は０ｘ０１に設定され得る。
ＰＬＰ_ＩＤは、当該テーブルに該当するＰＬＰを示す８ビットのフィールドであり得る。
ｎｕｍ_ｓｅｓｓｉｏｎは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションの個数を提供する８ビットの符号なし整数フィールドであり得る。ｉｇｎａｌｉｎｇ_ｔｙｐｅフィールドの値が０ｘ０１であれば、当該フィールドは、ＰＬＰでＵＤＰ／ＩＰセッションの個数を示すことができる。
ｓｒｃ_ＩＰ_ａｄｄは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションのソースＩＰアドレスを含む３２ビットの符号なし整数フィールドであり得る。
ｄｓｔ_ＩＰ_ａｄｄは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションのデスティネーションＩＰアドレスを含む３２ビットの符号なし整数フィールドであり得る。
ｓｒｃ_ＵＤＰ_ｐｏｒｔは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションのソースＵＤＰポートナンバーを示す１６ビットの符号なし整数フィールドであり得る。
ｄｓｔ_ＵＤＰ_ｐｏｒｔは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションのデスティネーションＵＤＰポートナンバーを示す１６ビットの符号なし整数フィールドであり得る。
ＳＩＤ_ｆｌａｇは、４個のフィールドＳｒｃ_ＩＰ_ａｄｄ、Ｄｓｔ_ＩＰ_ａｄｄ、Ｓｒｃ_ＵＤＰ_Ｐｏｒｔ、Ｄｓｔ_ＵＤＰ_Ｐｏｒｔによって識別される上位レイヤセッションを伝達するリンクレイヤパケットがそのオプショナルヘッダーにＳＩＤフィールドを有するか否かを示す１ビットのブールフィールドであり得る。当該フィールドの値が０に設定されると、上位レイヤセッションを伝達するリンクレイヤパケットがそのオプショナルヘッダーにＳＩＤフィールドを有さない。当該フィールドの値が１に設定されると、上位レイヤセッションを伝達するリンクレイヤパケットがそのオプショナルヘッダーにＳＩＤフィールドを有することができ、ＳＩＤフィールドの値が、当該テーブルで次のＳＩＤフィールドと同一であり得る。
ｃｏｍｐｒｅｓｓｅｄ_ｆｌａｇは、ヘッダーコンプレッションが、４個のフィールドＳｒｃ_ＩＰ_ａｄｄ、Ｄｓｔ_ＩＰ_ａｄｄ、Ｓｒｃ_ＵＤＰ_Ｐｏｒｔ、Ｄｓｔ_ＵＤＰ_Ｐｏｒｔによって識別される上位レイヤセッションを伝達するリンクレイヤパケットに適用されるか否かを示す１ビットのブールフィールドであり得る。当該フィールドの値が０に設定されると、上位レイヤセッションを伝達するリンクレイヤパケットは、そのベースヘッダーにＰａｃｋｅｔ_Ｔｙｐｅフィールドの０ｘ００の値を有することができる。当該フィールドの値が１に設定されると、上位レイヤセッションを伝達するリンクレイヤパケットは、そのベースヘッダーにＰａｃｋｅｔ_Ｔｙｐｅフィールドの０ｘ０１の値を有することができ、Ｃｏｎｔｅｘｔ_ＩＤフィールドが存在することができる。
ＳＩＤは、４個のフィールドＳｒｃ_ＩＰ_ａｄｄ、Ｄｓｔ_ＩＰ_ａｄｄ、Ｓｒｃ_ＵＤＰ_Ｐｏｒｔ、Ｄｓｔ_ＵＤＰ_Ｐｏｒｔによって識別される上位レイヤセッションを伝達するリンクレイヤパケットに対するサブストリーム識別子を示す８ビットの符号なし整数フィールドであり得る。当該フィールドは、ＳＩＤ_ｆｌａｇの値が１と同一であるときに存在することができる。
ｃｏｎｔｅｘｔ_ｉｄは、ＲＯＨＣ−Ｕディスクリプションテーブルに提供されたＣＩＤ（ｃｏｎｔｅｘｔ ｉｄ）に対するレファレンスを提供する８ビットのフィールドであり得る。当該フィールドは、ｃｏｍｐｒｅｓｓｅｄ_ｆｌａｇの値が１と同一であるときに存在することができる。
本発明に係るＲＯＨＣ−Ｕディスクリプションテーブルの一実施例（ｔｓｉｂ１４０２０）が図示された。前述したように、ＲＯＨＣ−Ｕアダプテーションモジュールは、ヘッダーコンプレッションに関連する情報を生成することができる。
ｓｉｇｎａｌｉｎｇ_ｔｙｐｅは、当該テーブルによって伝達されるシグナリングのタイプを示す８ビットのフィールドであり得る。ＲＯＨＣ−Ｕディスクリプションテーブルに対するｓｉｇｎａｌｉｎｇ_ｔｙｐｅフィールドの値は「０ｘ０２」に設定され得る。
ＰＬＰ_ＩＤは、当該テーブルに該当するＰＬＰを示す８ビットのフィールドであり得る。
ｃｏｎｔｅｘｔ_ｉｄは、圧縮されたＩＰストリームのＣＩＤを示す８ビットのフィールドであり得る。当該システムにおいて、８ビットのＣＩＤは、大きいＣＩＤのために使用することができる。
ｃｏｎｔｅｘｔ_ｐｒｏｆｉｌｅは、ストリームを圧縮するために使用されるプロトコルの範囲を示す８ビットのフィールドであり得る。当該フィールドは省略してもよい。
ａｄａｐｔａｔｉｏｎ_ｍｏｄｅは、当該ＰＬＰでアダプテーションモジュールのモードを示す２ビットのフィールドであり得る。アダプテーションモードについては前述した。
ｃｏｎｔｅｘｔ_ｃｏｎｆｉｇは、コンテキスト情報の組み合わせを示す２ビットのフィールドであり得る。当該テーブルにコンテキスト情報が存在しなければ、当該フィールドは「０ｘ０」に設定され得る。当該テーブルにｓｔａｔｉｃ_ｃｈａｉｎ（）またはｄｙｎａｍｉｃ_ｃｈａｉｎ（）バイトが含まれれば、当該フィールドは「０ｘ０１」または「０ｘ０２」に設定され得る。当該テーブルにｓｔａｔｉｃ_ｃｈａｉｎ（）及びｄｙｎａｍｉｃ_ｃｈａｉｎ（）バイトが全て含まれれば、当該フィールドは「０ｘ０３」に設定され得る。
ｃｏｎｔｅｘｔ_ｌｅｎｇｔｈは、スタティックチェーンバイトシーケンスの長さを示す８ビットのフィールドであり得る。当該フィールドは省略してもよい。
ｓｔａｔｉｃ_ｃｈａｉｎ_ｂｙｔｅ（）は、ＲｏＨＣ−Ｕデコンプレッサーを初期化するために使用されるスタティック情報を伝達するフィールドであり得る。当該フィールドの大きさ及び構造はコンテキストプロファイルに依存する。
ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｂｙｔｅ（）は、ＲｏＨＣ−Ｕデコンプレッサーを初期化するために使用されるダイナミック情報を伝達するフィールドであり得る。当該フィールドの大きさ及び構造はコンテキストプロファイルに依存する。
ｓｔａｔｉｃ_ｃｈａｉｎ_ｂｙｔｅは、ＩＲパケットのサブヘッダー情報として定義することができる。ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｂｙｔｅは、ＩＲパケット及びＩＲ−ＤＹＮパケットのサブヘッダー情報として定義することができる。
図１５は、本発明の一実施例に係る送信機側のリンクレイヤの構造を示した図である。
本実施例は、ＩＰパケットを処理することを仮定した実施例である。送信機側のリンクレイヤは、機能的な観点から、大きく、シグナリング情報を処理するリンクレイヤシグナリング部分、オーバーヘッドリダクション部分、及び／又はエンカプセレーション部分を含むことができる。また、送信機側のリンクレイヤは、リンクレイヤ全体の動作に対する制御及びスケジューリングのためのスケジューラ、及び／又はリンクレイヤの入出力部分などを含むことができる。
まず、上位レイヤのシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）がリンクレイヤに伝達され得る。また、ＩＰレイヤ（ｔｓｉｂ１５１１０）から、ＩＰパケットを含むＩＰストリームがリンクレイヤに伝達され得る。
スケジューラ（ｔｓｉｂ１５０２０）は、前述したように、リンクレイヤに含まれた多数のモジュールの動作を決定し、制御する役割を果たすことができる。伝達されたシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）は、スケジューラ（ｔｓｉｂ１５０２０）によってフィルタリングまたは活用されてもよい。伝達されたシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）のうち、受信機で必要な情報はリンクレイヤシグナリング部分に伝達されてもよい。また、シグナリング情報のうちリンクレイヤの動作に必要な情報は、オーバーヘッドリダクションコントローラー（ｔｓｉｂ１５１２０）またはエンカプセレーションコントローラー（ｔｓｉｂ１５１８０）に伝達されてもよい。
リンクレイヤシグナリング部分は、フィジカルレイヤでシグナリングとして伝送される情報を収集し、これを、伝送に適した形態に変換／構成する役割を果たすことができる。リンクレイヤシグナリング部分は、シグナリングマネジャー（ｔｓｉｂ１５０３０）、シグナリングフォーマッタ（ｔｓｉｂ１５０４０）、及び／又はチャンネルのためのバッファー（ｔｓｉｂ１５０５０）を含むことができる。
シグナリングマネジャー（ｔｓｉｂ１５０３０）は、スケジューラ（ｔｓｉｂ１５０２０）から伝達されたシグナリング情報、及び／又はオーバーヘッドリダクション部分から伝達されたシグナリング及び／又はコンテキスト（ｃｏｎｔｅｘｔ）情報を受信することができる。シグナリングマネジャー（ｔｓｉｂ１５０３０）は、伝達されたデータに対して、各シグナリング情報が伝送される経路を決定することができる。各シグナリング情報は、シグナリングマネジャー（ｔｓｉｂ１５０３０）によって決定された経路で伝達されてもよい。前述したように、ＦＩＣ、ＥＡＳなどの区分されたチャンネルで伝送されるシグナリング情報はシグナリングフォーマッタ（ｔｓｉｂ１５０４０）に伝達され、その他のシグナリング情報はエンカプセレーションバッファー（ｔｓｉｂ１５０７０）に伝達されてもよい。
シグナリングフォーマッタ（ｔｓｉｂ１５０４０）は、別途に区分されたチャンネルを介してシグナリング情報を伝送できるように、関連するシグナリング情報を各区分されたチャンネルに合う形態でフォーマットする役割を果たすことができる。前述したように、フィジカルレイヤには、物理的／論理的に区分された別途のチャンネルがあり得る。これら区分されたチャンネルは、ＦＩＣシグナリング情報や、ＥＡＳ関連情報を伝送するのに使用することができる。ＦＩＣまたはＥＡＳ関連情報は、シグナリングマネジャー（ｔｓｉｂ１５０３０）によって分類されてシグナリングフォーマッタ（ｔｓｉｂ１５０４０）に入力されてもよい。シグナリングフォーマッタ（ｔｓｉｂ１５０４０）は、各情報を、それぞれの別途のチャンネルに合わせてフォーマットすることができる。ＦＩＣ、ＥＡＳ以外にも、フィジカルレイヤが特定のシグナリング情報を別途の区分されたチャンネルを介して伝送するものと設計された場合には、その特定のシグナリング情報のためのシグナリングフォーマッタを追加することができる。このような方式を通じて、リンクレイヤが、様々なフィジカルレイヤに対して互換可能となり得る。
チャンネルのためのバッファー（ｔｓｉｂ１５０５０）は、シグナリングフォーマッタ（ｔｓｉｂ１５０４０）から伝達されたシグナリング情報を、指定された別途のチャンネル（ｔｓｉｂ１５０６０）に伝達する役割を果たすことができる。別途のチャンネルの数、内容は、実施例によって変更されてもよい。
前述したように、シグナリングマネジャー（ｔｓｉｂ１５０３０）は、特定のチャンネルに伝達されないシグナリング情報をエンカプセレーションバッファー（ｔｓｉｂ１５０７０）に伝達することができる。エンカプセレーションバッファー（ｔｓｉｂ１５０７０）は、特定のチャンネルに伝達されないシグナリング情報を受信するバッファーの役割を果たすことができる。
シグナリング情報のためのエンカプセレーション（ｔｓｉｂ１５０８０）は、特定のチャンネルに伝達されないシグナリング情報に対してエンカプセレーションを行うことができる。トランスミッションバッファー（ｔｓｉｂ１５０９０）は、エンカプセレーションされたシグナリング情報を、シグナリング情報のためのＤＰ（ｔｓｉｂ１５１００）に伝達するバッファーの役割を果たすことができる。ここで、シグナリング情報のためのＤＰ（ｔｓｉｂ１５１００）は、前述したＰＬＳ領域を意味し得る。
オーバーヘッドリダクション部分は、リンクレイヤに伝達されるパケットのオーバーヘッドを除去し、効率的な伝送が可能にすることができる。オーバーヘッドリダクション部分は、リンクレイヤに入力されるＩＰストリームの数だけ構成することができる。
オーバーヘッドリダクションバッファー（ｔｓｉｂ１５１３０）は、上位レイヤから伝達されたＩＰパケットの入力を受ける役割を果たすことができる。伝達されたＩＰパケットは、オーバーヘッドリダクションバッファー（ｔｓｉｂ１５１３０）を介してオーバーヘッドリダクション部分に入力されてもよい。
オーバーヘッドリダクションコントローラー（ｔｓｉｂ１５１２０）は、オーバーヘッドリダクションバッファー（ｔｓｉｂ１５１３０）に入力されるパケットストリームに対してオーバーヘッドリダクションを行うか否かを決定することができる。オーバーヘッドリダクションコントローラー（ｔｓｉｂ１５１２０）は、パケットストリーム別にオーバーヘッドリダクションを行うか否かを決定することができる。パケットストリームにオーバーヘッドリダクションが行われる場合、ＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）にパケットが伝達されてオーバーヘッドリダクションが行われ得る。パケットストリームにオーバーヘッドリダクションが行われない場合、エンカプセレーション部分にパケットが伝達され、オーバーヘッドリダクションなしにエンカプセレーションが行われ得る。パケットにオーバーヘッドリダクションを行うか否かは、リンクレイヤに伝達されたシグナリング情報（ｔｓｉｂ１５０１０）によって決定されてもよい。このシグナリング情報は、スケジューラ（ｔｓｉｂ１５０２０）によってエンカプセレーションコントローラー（ｔｓｉｂ１５１８０）に伝達されてもよい。
ＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）は、パケットストリームに対してオーバーヘッドリダクションを行うことができる。ＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）は、パケットのヘッダーを圧縮する動作を行うことができる。オーバーヘッドリダクションには様々な方法を使用することができる。前述した、本発明が提案した方法によってオーバーヘッドリダクションを行うことができる。本実施例は、ＩＰストリームを仮定しており、ＲｏＨＣコンプレシャーと表現したが、実施例によって名称は変更されてもよく、動作も、ＩＰストリームの圧縮に限定されず、全ての種類のパケットのオーバーヘッドリダクションがＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）によって行われてもよい。
パケットストリームコンフィギュレーションブロック（ｔｓｉｂ１５１５０）は、ヘッダーが圧縮されたＩＰパケットのうち、シグナリング領域に伝送される情報とパケットストリームに伝送される情報を分離することができる。パケットストリームに伝送される情報とは、ＤＰ領域に伝送される情報を意味し得る。シグナリング領域に伝送される情報は、シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１５１６０）に伝達されてもよい。パケットストリームに伝送される情報はエンカプセレーション部分に伝送されてもよい。
シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１５１６０）は、シグナリング及び／又はコンテキスト（ｃｏｎｔｅｘｔ）情報を収集し、これをシグナリングマネジャーに伝達することができる。シグナリング及び／又はコンテキスト情報をシグナリング領域に伝送するためである。
エンカプセレーション部分は、パケットをフィジカルレイヤに伝達するのに適した形態でエンキャプシュレートする動作を行うことができる。エンカプセレーション部分は、ＩＰストリームの数だけ構成することができる。
エンカプセレーションバッファー（ｔｓｉｂ１５１７０）は、エンカプセレーションのためにパケットストリームを受信する役割を果たすことができる。オーバーヘッドリダクションが行われた場合、オーバーヘッドリダクションされたパケットを受信し、オーバーヘッドリダクションが行われていない場合、入力されたＩＰパケットをそのまま受信することができる。
エンカプセレーションコントローラー（ｔｓｉｂ１５１８０）は、入力されたパケットストリームに対してエンカプセレーションを行うか否かを決定することができる。エンカプセレーションが行われる場合、パケットストリームはセグメンテーション／コンカチネーション（ｔｓｉｂ１５１９０）に伝達されてもよい。エンカプセレーションが行われない場合、パケットストリームはトランスミッションバッファー（ｔｓｉｂ１５２３０）に伝達されてもよい。パケットをエンカプセレーションするか否かは、リンクレイヤに伝達されたシグナリング情報（ｔｓｉｂ１５０１０）によって決定されてもよい。このシグナリング情報は、スケジューラ（ｔｓｉｂ１５０２０）によってエンカプセレーションコントローラー（ｔｓｉｂ１５１８０）に伝達されてもよい。
セグメンテーション／コンカチネーションブロック（ｔｓｉｂ１５１９０）では、パケットに対して、前述した分割または連鎖作業を行うことができる。すなわち、入力されたＩＰパケットが、リンクレイヤの出力であるリンクレイヤパケットよりも長い場合、一つのＩＰパケットを分割して多数個のセグメントに分けて複数個のリンクレイヤパケットペイロードを作ることができる。また、入力されたＩＰパケットが、リンクレイヤの出力であるリンクレイヤパケットよりも短い場合、複数個のＩＰパケットをつなげて一つのリンクレイヤパケットペイロードを作ることができる。
パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）は、分割及び／又は連鎖されたリンクレイヤパケットの構成情報を有することができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）の情報は、送信機と受信機が同じ情報を有することができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）の情報が送信機と受信機で参照されてもよい。パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）の情報のインデックス値が当該リンクレイヤパケットのヘッダーに含まれてもよい。
リンクレイヤヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、エンカプセレーション過程で発生するヘッダー情報を収集することができる。また、リンクレイヤヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）が有する情報を収集することができる。リンクレイヤヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、リンクレイヤパケットのヘッダーの構造に応じてヘッダー情報を構成することができる。
ヘッダーアタッチメントブロック（ｔｓｉｂ１５２２０）は、セグメンテーション及び／又はコンカチネーションされたリンクレイヤパケットのペイロードにヘッダーを追加することができる。トランスミッションバッファー（ｔｓｉｂ１５２３０）は、リンクレイヤパケットをフィジカルレイヤのＤＰ（ｔｓｉｂ１５２４０）に伝達するためのバッファーの役割を果たすことができる。
各ブロック乃至モジュール及び部分（ｐａｒｔ）は、リンクレイヤにおいて一つのモジュール／プロトコルとして構成されてもよく、複数個のモジュール／プロトコルとして構成されてもよい。
図１６は、本発明の一実施例に係る受信機側のリンクレイヤの構造を示した図である。
本実施例は、ＩＰパケットを処理することを仮定した実施例である。受信機側のリンクレイヤは、機能的な観点から、大きく、シグナリング情報を処理するリンクレイヤシグナリング部分、オーバーヘッドプロセシング部分、及び／又はデカプセレーション部分を含むことができる。また、受信機側のリンクレイヤは、リンクレイヤ全体の動作に対する制御及びスケジューリングのためのスケジューラ、及び／又はリンクレイヤの入出力部分などを含むことができる。
まず、フィジカルレイヤを介して伝送された各情報がリンクレイヤに伝達され得る。リンクレイヤは、各情報を処理して、送信側で処理する前の元の状態に戻した後、上位レイヤに伝達することができる。この実施例において、上位レイヤはＩＰレイヤであってもよい。
フィジカルレイヤで区分された特定のチャンネル（ｔｓｉｂ１６０３０）を介して伝達された情報がリンクレイヤシグナリング部分に伝達され得る。リンクレイヤシグナリング部分は、フィジカルレイヤから受信されたシグナリング情報を判別し、リンクレイヤの各部分に、判別されたシグナリング情報を伝達する役割を果たすことができる。
チャンネルのためのバッファー（ｔｓｉｂ１６０４０）は、特定のチャンネルを介して伝送されたシグナリング情報を受信するバッファーの役割を果たすことができる。前述したように、フィジカルレイヤに物理的／論理的に区分された別途のチャンネルが存在する場合、そのチャンネルを介して伝送されたシグナリング情報を受信することができる。別途のチャンネルから受信した情報が分割された状態である場合、完全な形態の情報になるまで、分割された情報を格納することができる。
シグナリングデコーダ／パーサ（ｔｓｉｂ１６０５０）は、特定のチャンネルを介して受信されたシグナリング情報のフォーマットを確認し、リンクレイヤで活用される情報を抽出することができる。特定のチャンネルを介したシグナリング情報がエンコーディングされている場合にはデコーディングを行うことができる。また、実施例によって、当該シグナリング情報の無欠性などを確認してもよい。
シグナリングマネジャー（ｔｓｉｂ１６０６０）は、多数の経路を介して受信されたシグナリング情報を統合することができる。後述するシグナリングのためのＤＰ（ｔｓｉｂ１６０７０）を介して受信されたシグナリング情報もシグナリングマネジャー（ｔｓｉｂ１６０６０）で統合することができる。シグナリングマネジャー（ｔｓｉｂ１６０６０）は、リンクレイヤ内の各部分に必要なシグナリング情報を伝達することができる。例えば、オーバーヘッドプロセシング部分に、パケットのリカバリーのためのコンテキスト情報などを伝達することができる。また、スケジューラ（ｔｓｉｂ１６０２０）に、制御のためのシグナリング情報を伝達することができる。
シグナリングのためのＤＰ（ｔｓｉｂ１６０７０）を介して、別途の特別なチャンネルで受信されていない一般的なシグナリング情報が受信されてもよい。ここで、シグナリングのためのＤＰとは、ＰＬＳまたはＬ１などを意味し得る。ここで、ＤＰは、ＰＬＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｉｐｅ）と呼ぶこともできる。レセプションバッファー（ｔｓｉｂ１６０８０）は、シグナリングのためのＤＰから伝送されたシグナリング情報を受信するバッファーの役割を果たすことができる。シグナリング情報のデカプセレーションブロック（ｔｓｉｂ１６０９０）では、受信されたシグナリング情報をデカプセレーションすることができる。デカプセレーションされたシグナリング情報は、デカプセレーションバッファー（ｔｓｉｂ１６１００）を経てシグナリングマネジャー（ｔｓｉｂ１６０６０）に伝達されてもよい。前述したように、シグナリングマネジャー（ｔｓｉｂ１６０６０）は、シグナリング情報を組み合わせてリンクレイヤ内の必要な部分に伝達することができる。
スケジューラ（ｔｓｉｂ１６０２０）は、リンクレイヤに含まれた多数のモジュールの動作を決定し、制御する役割を果たすことができる。スケジューラ（ｔｓｉｂ１６０２０）は、レシーバー情報（ｔｓｉｂ１６０１０）及び／又はシグナリングマネジャー（ｔｓｉｂ１６０６０）から伝達された情報を用いて、リンクレイヤの各部分を制御することができる。また、スケジューラ（ｔｓｉｂ１６０２０）は、各部分の動作モードなどを決定することができる。ここで、レシーバー情報（ｔｓｉｂ１６０１０）は、受信機が予め格納していた情報を意味し得る。スケジューラ（ｔｓｉｂ１６０２０）は、チャンネル切り替えなどのようにユーザが変更する情報も用いて、制御に活用することができる。
デカプセレーション部分は、フィジカルレイヤのＤＰ（ｔｓｉｂ１６１１０）から受信されたパケットをフィルタリングし、当該パケットのタイプに応じてパケットを分離する役割を果たすことができる。デカプセレーション部分は、フィジカルレイヤで同時にデコーディングできるＤＰの数だけ構成することができる。
デカプセレーションバッファー（ｔｓｉｂ１６１１０）は、デカプセレーションのためにフィジカルレイヤからパケットストリームを受信するバッファーの役割を果たすことができる。デカプセレーションコントローラー（ｔｓｉｂ１６１３０）は、入力されたパケットストリームに対してデカプセレーションを行うか否かを決定することができる。デカプセレーションが行われる場合、パケットストリームはリンクレイヤヘッダーパーサ（ｔｓｉｂ１６１４０）に伝達されてもよい。デカプセレーションが行われない場合、パケットストリームはアウトプットバッファー（ｔｓｉｂ１６２２０）に伝達されてもよい。デカプセレーションを行うか否かを決定するにおいて、スケジューラ（ｔｓｉｂ１６０２０）から伝達されたシグナリング情報を活用することができる。
リンクレイヤヘッダーパーサ（ｔｓｉｂ１６１４０）は、伝達されたリンクレイヤパケットのヘッダーを確認することができる。ヘッダーを確認することによって、リンクレイヤパケットのペイロードに含まれているＩＰパケットの構成を確認することができる。例えば、ＩＰパケットは、セグメンテーションされているか、またはコンカチネーションされていてもよい。
パケットコンフィギュレーションテーブル（ｔｓｉｂ１６１５０）は、セグメンテーション及び／又はコンカチネーションで構成されるリンクレイヤパケットのペイロード情報を含むことができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１６１５０）の情報は、送信機と受信機が同じ情報を有することができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１６１５０）の情報が送信機と受信機で参照されてもよい。リンクレイヤパケットに含まれたインデックス情報に基づいて、再結合（ｒｅａｓｓｅｍｂｌｙ）に必要な値を見つけることができる。
再結合ブロック（ｒｅａｓｓｅｍｂｌｙ）（ｔｓｉｂ１６１６０）は、セグメンテーション及び／又はコンカチネーションで構成されたリンクレイヤパケットのペイロードを元のＩＰストリームのパケットとして構成することができる。セグメントを一つに集めて一つのＩＰパケットとして再構成したり、コンカチネーションされたパケットを分離して複数個のＩＰパケットストリームとして再構成したりすることができる。再結合されたＩＰパケットは、オーバーヘッドプロセシング部分に伝達されてもよい。
オーバーヘッドプロセシング部分は、送信機で行われたオーバーヘッドリダクションの逆過程として、オーバーヘッドリダクションされたパケットを元のパケットに戻す動作を行うことができる。この動作をオーバーヘッドプロセシングと呼ぶことができる。オーバーヘッドプロセシング部分は、フィジカルレイヤで同時にデコーディングできるＤＰの数だけ構成することができる。
パケットリカバリーバッファー（ｔｓｉｂ１６１７０）は、オーバーヘッドプロセシングを行うためにデカプセレーションされたＲｏＨＣパケット乃至ＩＰパケットを受信するバッファーの役割を果たすことができる。
オーバーヘッドコントローラー（ｔｓｉｂ１６１８０）は、デカプセレーションされたパケットに対してパケットリカバリー及び／又はデコンプレッションを行うか否かを決定することができる。パケットリカバリー及び／又はデコンプレッションが行われる場合、パケットストリームリカバリーブロック（ｔｓｉｂ１６１９０）にパケットが伝達されてもよい。パケットリカバリー及び／又はデコンプレッションが行われない場合、パケットはアウトプットバッファー（ｔｓｉｂ１６２２０）に伝達されてもよい。パケットリカバリー及び／又はデコンプレッションを行うか否かは、スケジューラ（ｔｓｉｂ１６０２０）によって伝達されたシグナリング情報に基づいて決定されてもよい。
パケットストリームリカバリーブロック（ｔｓｉｂ１６１９０）は、送信機で分離されたパケットストリームと、パケットストリームのコンテキスト情報とを統合する動作を行うことができる。これは、ＲｏＨＣデコンプレッサー（ｔｓｉｂ１６２１０）で処理可能なように、パケットストリームを復旧する過程であり得る。この過程で、シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１６２００）からシグナリング情報及び／又はコンテキスト情報を受信することができる。シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１６２００）は、送信機から伝達されたシグナリング情報を判別し、当該コンテキストＩＤに合うストリームにマッピングできるようにパケットストリームリバーカレーブロック（ｔｓｉｂ１６１９０）にシグナリング情報を伝達することができる。
ＲｏＨＣデコンプレッサー（ｔｓｉｂ１６２１０）は、パケットストリームのパケットのヘッダーを復旧することができる。パケットストリームのパケットは、ヘッダーが復旧されることによって元のＩＰパケットの形態に復旧され得る。すなわち、ＲｏＨＣデコンプレッサー（ｔｓｉｂ１６２１０）はオーバーヘッドプロセシングを行うことができる。
アウトプットバッファー（ｔｓｉｂ１６２２０）は、ＩＰレイヤ（ｔｓｉｂ１６２３０）に出力ストリームを伝達するに先立ち、バッファーの役割を果たすことができる。
本発明が提案する送信機と受信機のリンクレイヤは、前述したようなブロック乃至モジュールを含むことができる。これを通じて、リンクレイヤが上位レイヤと下位レイヤに関係なく独立して動作することができ、オーバーヘッドリダクションを効率的に行うことができ、上／下位レイヤなどによって支援可能な機能の確定／追加／除去が容易となり得る。
図１７は、本発明の一実施例に係る、リンクレイヤを介したシグナリング伝送構造を示した図である（送／受信側）。
本発明では、一つの周波数バンド内に複数個のサービスプロバイダー（放送会社）がサービスを提供することができる。また、サービスプロバイダーは、複数個のサービスを伝送することができ、一つのサービスは１つ以上のコンポーネントを含むことができる。ユーザは、サービス単位でコンテンツを受信することを考慮することができる。
本発明は、ＩＰハイブリッド放送を支援するために、複数個のセッションベースの伝送プロトコルが使用されることを仮定する。各プロトコルの伝送構造に基づいて、そのシグナリングパス（ｐａｔｈ）で伝達されるシグナリング情報を決定することができる。各プロトコルは、実施例によって様々な名称が付与されてもよい。
図示された送信側のデータ構造（ｔｓｉｂ１７０１０）において、サービスプロバイダー（Ｂｒｏａｄｃａｓｔｅｒｓ）は複数個のサービス（Ｓｅｒｖｉｃｅ ＃１，＃２，…）を提供することができる。一般に、サービスに対するシグナリングは、一般的な伝送セッションを介して伝送することができるが（Ｓｉｇｎａｌｉｎｇ Ｃ）、実施例によって、特定のセッション（ｄｅｄｉｃａｔｅｄ ｓｅｓｓｉｏｎ）を介して伝送してもよい（Ｓｉｇｎａｌｉｎｇ Ｂ）。
サービスデータ及びサービスシグナリング情報は、伝送プロトコルに従ってエンカプセレーションすることができる。実施例によってＩＰ／ＵＤＰが使用されてもよい。実施例によってＩＰ／ＵＤＰレイヤでのシグナリング（Ｓｉｇｎａｌｉｎｇ Ａ）が追加されてもよい。このシグナリングは省略できる。
ＩＰ／ＵＤＰで処理されたデータはリンクレイヤに入力されてもよい。リンクレイヤでは、前述したように、オーバーヘッドリダクション及び／又はエンカプセレーション過程を行うことができる。ここで、リンクレイヤシグナリングが追加されてもよい。リンクレイヤシグナリングにはシステムパラメータなどが含まれてもよい。リンクレイヤシグナリングについては前述した。
このような処理を経たサービスデータ及びシグナリング情報は、フィジカルレイヤでＰＬＰを介して処理されてもよい。ここで、ＰＬＰはＤＰと呼ぶこともできる。図示された実施例では、Ｂａｓｅ ＤＰ／ＰＬＰが使用される場合を想定しているが、実施例によってＢａｓｅ ＤＰ／ＰＬＰなしに一般的なＤＰ／ＰＬＰのみで伝送が行われてもよい。
図示された実施例では、ＦＩＣ、ＥＡＣなどの特定のチャンネル（ｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌ）が使用されている。ＦＩＣを介して伝達されるシグナリングをＦＩＴ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）、ＥＡＣを介して伝達されるシグナリングをＥＡＴ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｔａｂｌｅ）と呼ぶことができる。ＦＩＴは、前述したＳＬＴと同一であってもよい。このような特定のチャンネルは、実施例によって使用されなくてもよい。特定のチャンネル（Ｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌ）が構成されていない場合、ＦＩＴとＥＡＴは、一般的なリンクレイヤシグナリング伝送方法によって伝送されるか、または他のサービスデータのようにＩＰ／ＵＤＰを経てＰＬＰに伝送されてもよい。
実施例によって、システムパラメータには、送信機関連パラメータ、サービスプロバイダー関連パラメータなどが含まれてもよい。リンクレイヤシグナリングには、ＩＰヘッダー圧縮関連コンテキスト情報、及び／又は当該コンテキストが適用されるデータに対する識別情報が含まれてもよい。上位レイヤのシグナリングには、ＩＰアドレス、ＵＤＰナンバー、サービス／コンポーネント情報、緊急警報（Ｅｍｅｒｇｅｎｃｙ ａｌｅｒｔ）関連情報、サービスシグナリングに対するＩＰ／ＵＤＰアドレス、セッションＩＤなどが含まれてもよい。詳細な実施例については前述した。
図示された受信側のデータ構造（ｔｓｉｂ１７０２０）において、受信機は、全てのＰＬＰをデコーディングすることなく、シグナリング情報を活用して当該サービスに対するＰＬＰのみをデコーディングすることができる。
まず、ユーザが、受信しようとするサービスを選択または変更すると、受信機は、当該周波数にチューニングし、当該チャンネルと関連してＤＢなどに格納している受信機情報を読み込むことができる。受信機のＤＢなどに格納されている情報は、最初のチャンネルスキャンの際にＳＬＴを読み込んで構成されてもよい。
ＳＬＴを受信し、当該チャンネルの情報を受信した後、既存に格納されていたＤＢをアップデートし、ユーザが選択したサービスの伝送経路及びコンポーネント情報を獲得したり、このような情報を獲得するために必要なシグナリングが伝送される経路に対する情報を獲得したりする。ＳＬＴのバージョン情報などを用いて、当該情報の変更がないと判断される場合には、デコーディングまたはパーシング手順を省略することができる。
受信機は、当該放送ストリームにおいて、ＰＬＰのフィジカルシグナリングをパーシングし、当該ＰＬＰ内にＳＬＴ情報があるかどうかを把握することができる（図示せず）。これは、フィジカルシグナリングの特定のフィールドを介して指示されてもよい。ＳＬＴ情報に接近することによって、特定のサービスのサービスレイヤシグナリングが伝送される位置に接近することができる。このサービスレイヤシグナリングは、ＩＰ／ＵＤＰにエンカプセレーションされて伝送セッションを介して伝達されてもよい。このサービスレイヤシグナリングを用いて、当該サービスを構成するコンポーネントに対する情報を獲得することができる。詳細なＳＬＴ−ＳＬＳの構造は、前述した通りである。
すなわち、ＳＬＴを用いて、現在のチャンネルに伝送されている多数のパケットストリーム及びＰＬＰのうち、当該サービスの受信に必要な上位レイヤシグナリング情報（サービスシグナリング情報）を受信するための伝送経路情報を獲得することができる。この伝送経路情報には、ＩＰアドレス、ＵＤＰポートナンバー、セッションＩＤ、ＰＬＰ ＩＤなどが含まれてもよい。ここで、実施例によって、ＩＰ／ＵＤＰアドレスは、ＩＡＮＡまたはシステムで予め指定されている値を使用してもよい。このような情報は、ＤＢ及び共有メモリ接近などの方法で獲得されてもよい。
リンクレイヤシグナリングとサービスデータが同一のＰＬＰを介して伝送されるか、または一つのＰＬＰのみが運用されている場合、ＰＬＰを介して伝達されるサービスデータは、リンクレイヤシグナリングがデコーディングされる間、臨時にバッファーなどの装置に格納されてもよい。
受信しようとするサービスに対するサービスシグナリング情報を用いて、当該サービスが実際に伝送される経路の情報を獲得することができる。また、受信するＰＬＰに対するオーバーヘッドリダクションなどの情報を用いて、受信されるパケットストリームに対してデカプセレーション及びヘッダーリカバリーを行うことができる。
図示された実施例（ｔｓｉｂ１７０２０）では、ＦＩＣ、ＥＡＣが使用され、Ｂａｓｅ ＤＰ／ＰＬＰの概念が想定された。前述したように、ＦＩＣ、ＥＡＣ、Ｂａｓｅ ＤＰ／ＰＬＰの概念は活用されなくてもよい。
図１８は、本発明の一実施例に係るリンクレイヤ（ｌｉｎｋ ｌａｙｅｒ）のインターフェースを示す図である。
図面を参照すると、送信機が、ＩＰパケット及び／又はデジタル放送で使用されるＭＰＥＧ２−ＴＳパケットを入力信号として使用する場合を示す。送信機は、次世代放送システムで使用できる新しいプロトコルでのパケット構造を支援することもできる。リンクレイヤのカプセル化された（ｅｎｃａｐｓｕｌａｔｅｄ）データ及び／又はシグナリング情報は、物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）に伝送されてもよい。送信機は、（シグナリングデータを含むことができる）伝送されたデータを放送システムによって支援される物理層のプロトコルに従って処理し、当該データを含む信号を送信することができる。
一方、受信機は、物理層から受信したデータ及び／又はシグナリング情報を、上位レイヤで処理できる他のデータに復元する。受信機は、パケットのヘッダーを読むことができ、物理層から受信したパケットがシグナリング情報（またはシグナリングデータ）または一般のデータ（またはコンテンツデータ）を含むかどうかを決定することができる。
送信機から伝達されるシグナリング情報（すなわち、シグナリングデータ）は、上位レイヤ（ｕｐｐｅｒ ｌａｙｅｒ）から受信され、受信機の上位レイヤに伝送される必要がある第１シグナリング情報、リンクレイヤで生成され、受信機のリンクレイヤでデータの処理と関連する情報を提供する情報である第２シグナリング情報、及び／又は上位レイヤまたはリンクレイヤで生成され、物理層で特定のデータ（例えば、サービス、コンテンツ、及び／又はシグナリングデータ）を迅速に識別するために伝送される第３シグナリング情報を含むことができる。
一方、本発明の一実施例によれば、リンクレイヤで、上位レイヤから伝達されるパケットに対して、追加的な処理を行うことができる。
上位レイヤから伝達されるパケットがＩＰパケットに該当する場合、送信機は、リンクレイヤでＩＰヘッダー圧縮（ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ）を行うことができる。ＩＰヘッダー圧縮を通じて、ＩＰフロー（ｆｌｏｗ）で、オーバーヘッド（ｏｖｅｒｈｅａｄ）を低減することができる。ＩＰヘッダー圧縮のためにＲｏＨＣ（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）技法を使用することができる。ＲｏＨＣ技法に関しては、ＲＦＣ３０９５及びＲＦＣ５７９５の文書を通じて詳細な内容は補充できる。
本発明の一実施例では、ＲｏＨＣ技法が単方向（ｕｎｉｄｉｒｅｃｔｉｏｎａｌ）モードで動作することができる。これと関連する詳細は後述する。
上位レイヤから伝達されるパケットがＭＰＥＧ−２ ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）パケットである場合、ＭＰＥＧ−２ ＴＳパケットに対してオーバーヘッドリダクション（ｏｖｅｒｈｅａｄ ｒｅｄｕｃｔｉｏｎ）を行うことができる。ＭＰＥＧ−２ ＴＳパケットには、Ｓｙｎｃフィールド、ｎｕｌｌパケット、及び／又はＣｏｍｍｏｎ ＰＩＤ（Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）が含まれてもよく、このようなデータは、それぞれのＴＳパケットにおいて繰り返されるか、または不必要なデータであるため、送信機は、リンクレイヤでこれらデータを削除し、受信機でこれを復元できる情報を生成して受信機に伝送することができる。
送信機は、リンクレイヤで、上位レイヤから伝達されるパケットをエンカプセレーション（ｅｎｃａｐｓｕｌａｔｉｏｎ）することができる。例えば、送信機は、リンクレイヤで、ＩＰパケット、ＭＰＥＧ−２ ＴＳパケット及び／又は他のプロトコルのパケットをエンカプセレーションして、リンクレイヤパケットを生成することができる。リンクレイヤでのエンカプセレーションを通じて、送／受信機のフィジカルレイヤ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ；物理層）では、ネットワークレイヤのプロトコルの種類に関係なく、一つのフォーマットのパケットを処理することができる。この場合、ＭＰＥＧ−２ ＴＳパケットは、ネットワークレイヤのパケットとして見なすことができる。
ネットワークレイヤはリンクレイヤの上位レイヤである。基本的にネットワークレイヤのパケットは、リンクレイヤのパケットのペイロード（ｐａｙｌｏａｄ）に変換されてもよい。本発明の一実施例では、フィジカルレイヤのリソース（ｒｅｓｏｕｒｃｅ）を効率的に使用するために、ネットワークレイヤのパケットに対するコンカチネーション（ｃｏｎｃａｔｅｎａｔｉｏｎ）とセグメンテーション（ｓｅｇｍｅｎｔａｔｉｏｎ）が行われて、リンクレイヤのパケットに含まれてもよい。
リンクレイヤのペイロードが複数のネットワークレイヤのパケットを含むことができる程度に、ネットワークレイヤのパケットの大きさが小さい場合、リンクレイヤのパケットのヘッダー（ｈｅａｄｅｒ）は、コンカチネーションを行うためのプロトコルフィールド（ｐｒｏｔｏｃｏｌ ｆｉｅｌｄ）を含むことができる。コンカチネーションは、複数のネットワークレイヤのパケットを一つのペイロード（リンクレイヤのパケットのペイロード）内で連結するものと定義することができる。
一つのネットワークレイヤのパケットの大きさが、フィジカルレイヤで処理するには大きすぎる場合には、ネットワークレイヤのパケットは、２つまたはそれ以上（ｔｗｏ ｏｒ ｍｏｒｅ）のセグメントに分離されてもよい。リンクレイヤのパケットのヘッダーは、送信側で行われたセグメンテーション（ｓｅｇｍｅｎｔａｔｉｏｎ）を行い、受信側でこれらを再結合（ｒｅａｓｓｅｍｂｌｅ）できるように、必要な情報をプロトコルフィールドの形態で含むことができる。
送信機のリンクレイヤでの処理は、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）、ＥＡＳ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｓｙｓｔｅｍ）メッセージ、及び／又はオーバーヘッドリダクションのための情報のようなリンクレイヤで生成されたシグナリング情報を伝達することを含む。
ＦＩＣは、チャンネルスキャン、及びサービスの迅速な獲得のために必要な情報を含むシグナリング構造である。すなわち、ＦＩＣの主な目的は、迅速なチャンネルスキャン及びサービス獲得のための必須情報を効率的に伝達することにある。ＦＩＣに含まれる情報は、ＤＰ（ｄａｔａ ｐｉｐｅ、またはＰＬＰ）と放送サービスとの間の接続のための情報に該当してもよい。
送信機でのリンクレイヤの処理は、非常警報メッセージ（ｅｍｅｒｇｅｎｃｙ ａｌｅｒｔ ｍｅｓｓａｇｅ）とこれと関連するシグナリング情報を特定のチャンネルを介して伝送することを含む。特定のチャンネルは、フィジカルレイヤで予め定義されたチャンネルに該当してもよい。特定のチャンネルは、ＥＡＣ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｃｈａｎｎｅｌ）と命名してもよい。
図１９は、本発明の一実施例に係るリンクレイヤの動作モードのうち、ノーマル（Ｎｏｒｍａｌ）モードの動作ダイヤグラムを示した図である。
本発明が提案するリンクレイヤは、上位レイヤと下位レイヤとの互換のために、様々な動作モードを有することができる。本発明は、リンクレイヤのノーマルモード及びトランスペアレントモードを提案する。２つの動作モードは、リンクレイヤ内で共存可能であり、どのモードが使用されるかは、シグナリングまたはシステムパラメータを用いて指定されてもよい。実施例によって、２つのモードのいずれか１つのモードのみが具現されてもよい。リンクレイヤに入力されるＩＰレイヤ、ＴＳレイヤなどに応じて、それぞれ異なるモードが適用されてもよい。また、ＩＰレイヤのストリーム別に、ＴＳレイヤのストリーム別に、それぞれ異なるモードが適用されてもよい。
実施例によって、新しい動作モードがリンクレイヤに追加されてもよい。新しい動作モードは、上位レイヤと下位レイヤの構成に基づいて追加されてもよい。新しい動作モードは、上位レイヤと下位レイヤの構成に基づいて異なるインターフェースを含むことができる。新しい動作モードを使用するか否かも、シグナリングまたはシステムパラメータを用いて指定されてもよい。
ノーマルモードでは、データが、リンクレイヤが支援する全ての機能を経て処理された後、フィジカルレイヤに伝達されてもよい。
まず、ＩＰレイヤ、ＭＰＥＧ−２ ＴＳレイヤ、または他の特定のレイヤ（ｔ８９０１０）から各パケットがリンクレイヤに伝達されてもよい。すなわち、ＩＰパケットが、ＩＰレイヤからリンクレイヤに伝達され得る。同様に、ＭＰＥＧ−２ ＴＳパケットがＭＰＥＧ−２ ＴＳレイヤから、特定のパケットが特定のプロトコルレイヤからリンクレイヤに伝達され得る。
各伝達されたパケットは、オーバーヘッドリダクション（ｔ８９０２０）を経たり経なかった後、エンカプセレーション（ｔ８９０３０）を経るようになってもよい。
第一に、ＩＰパケットの場合、オーバーヘッドリダクション（ｔ８９０２０）を経たり経なかった後、エンカプセレーション（ｔ８９０３０）を経るようになってもよい。オーバーヘッドリダクションが行われるか否かは、シグナリングまたはシステムパラメータによって指定されてもよい。実施例によって、各ＩＰストリーム別にオーバーヘッドリダクションが行われてもよく行われなくてもよい。エンカプセレーションされたＩＰパケットはフィジカルレイヤに伝達されてもよい。
第二に、ＭＰＥＧ−２ ＴＳパケットの場合、オーバーヘッドリダクション（ｔ８９０２０）を経てエンカプセレーション（ｔ８９０３０）を経るようになってもよい。ＭＰＥＧ−２ ＴＳパケットの場合も、実施例によってオーバーヘッドリダクション過程が省略されてもよい。しかし、一般的な場合、ＴＳパケットは、先頭にシンクバイト（０ｘ４７）などを有するので、このような固定的なオーバーヘッドを除去することが効率的である。エンカプセレーションされたＴＳパケットはフィジカルレイヤに伝達されてもよい。
第三に、ＩＰまたはＴＳパケットではない他のパケットである場合、オーバーヘッドリダクション（ｔ８９０２０）を経たり経なかった後、エンカプセレーション（ｔ８９０３０）を経るようになってもよい。オーバーヘッドリダクションが行われるか否かは、当該パケットの特性によって決定されてもよい。オーバーヘッドリダクションが行われるか否かは、シグナリングまたはシステムパラメータによって指定されてもよい。エンカプセレーションされたパケットはフィジカルレイヤに伝達されてもよい。
オーバーヘッドリダクション（ｔ８９０２０）過程では、入力されたパケットの大きさを適切な方法を通じて減少させることができる。オーバーヘッドリダクション過程で、入力されたパケットから特定の情報が抽出または生成されてもよい。この特定の情報は、シグナリングと関連する情報であって、シグナリング領域を介して伝送されてもよい。このシグナリング情報は、受信機が、オーバーヘッドリダクション過程で変更された事項を復旧して元のパケットの形態に戻すことができるようにする。このシグナリング情報は、リンクレイヤシグナリング（ｔ８９０５０）に伝達されてもよい。
リンクレイヤシグナリング（ｔ８９０５０）は、オーバーヘッドリダクション過程で抽出／生成されたシグナリング情報の伝送及び管理を行うことができる。フィジカルレイヤは、シグナリングのために物理的／論理的に区分された伝送経路を有することができ、リンクレイヤシグナリング（ｔ８９０５０）は、この区分された伝送経路に合わせてシグナリング情報をフィジカルレイヤに伝達することもできる。ここで、区分された伝送経路には、前述したＦＩＣシグナリング（ｔ８９０６０）またはＥＡＳシグナリング（ｔ８９０７０）などがあり得る。別に区分された伝送経路に伝送されないシグナリング情報は、エンカプセレーション（ｔ８９０３０）を経てフィジカルレイヤに伝達されてもよい。
リンクレイヤシグナリング（ｔ８９０５０）が管理するシグナリング情報には、上位レイヤから伝達されたシグナリング情報、リンクレイヤで生成されたシグナリング情報及び／又はシステムパラメータなどがあり得る。具体的に、上位レイヤから伝達された、結果的に受信機の上位レイヤに伝達されなければならないシグナリング情報、リンクレイヤで生成されて受信機のリンクレイヤの動作に活用されなければならないシグナリング情報、上位レイヤまたはリンクレイヤで生成されて受信機のフィジカルレイヤで迅速なディテクションのために使用されるシグナリング情報などがあり得る。
エンカプセレーション（ｔ８９０３０）されてフィジカルレイヤに伝達されたデータは、ＤＰ（Ｄａｔａ Ｐｉｐｅ）（ｔ８９０４０）を介して伝送されてもよい。ここで、ＤＰは、ＰＬＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｉｐｅ）であってもよい。前述した区分された伝送経路に伝達されるシグナリング情報は、それぞれの伝送経路に伝達されてもよい。例えば、ＦＩＣシグナリングは、フィジカルフレーム内で指定されたＦＩＣチャンネル（ｔ８９０８０）を介して伝送され得る。また、ＥＡＳシグナリングは、フィジカルフレーム内の指定されたＥＡＣチャンネル（ｔ８９０９０）を介して伝送され得る。ＦＩＣまたはＥＡＣなどの特定のチャンネルが存在するという情報は、フィジカルフレームのプリアンブル領域にシグナリングされて伝送されたり、特定のスクランブリングシーケンスを使用してプリアンブルをスクランブリングすることによってシグナリングされてもよい。実施例によって、ＦＩＣシグナリング／ＥＡＳシグナリング情報は、指定された特定のチャンネルではない、一般ＤＰ領域、ＰＬＳ領域またはプリアンブルを介して伝送されてもよい。
受信機は、フィジカルレイヤを介してデータ及びシグナリング情報を受信することができる。受信機は、これを、上位レイヤで処理可能な形態に復元して上位レイヤに伝達することができる。このような過程は、受信機のリンクレイヤで行うことができる。パケットのヘッダーを読むなどの方法で、受信機は、伝送されたパケットがシグナリング情報に関するものか、データに関するものかを区分することができる。また、受信機は、オーバーヘッドリダクションが送信側で行われた場合、オーバーヘッドリダクションを通じてオーバーヘッドが減少したパケットを元のパケットに復旧することができる。この過程で、伝達されたシグナリング情報を活用することができる。
図２０は、本発明の一実施例に係るリンクレイヤの動作モードのうち、トランスペアレント（Ｔｒａｎｓｐａｒｅｎｔ）モードの動作ダイヤグラムを示した図である。
トランスペアレントモードでは、データが、リンクレイヤが支援する機能を経ないか、または一部のみを経た後、フィジカルレイヤに伝達されてもよい。すなわち、トランスペアレントモードでは、上位レイヤから伝達されたパケットが、別途のオーバーヘッドリダクション及び／又はエンカプセレーション過程を経ずにそのままフィジカルレイヤに伝達されてもよい。他のパケットの場合は、必要に応じて、オーバーヘッドリダクション及び／又はエンカプセレーション過程を経ることもできる。トランスペアレントモードは、バイパスモード（ｂｙｐａｓｓ ｍｏｄｅ）と呼ぶことができ、他の名称が付与されてもよい。
実施例によって、パケットの特性及びシステムの運用に基づいて、一部のパケットはノーマルモードで、一部のパケットはトランスペアレントモードで処理されてもよい。
トランスペアレントモードを適用できるパケットは、システムによく知られているタイプのパケットであり得る。フィジカルレイヤで当該パケットに対して処理できる場合、トランスペアレントモードを活用することができる。例えば、よく知られたＴＳまたはＩＰパケットの場合、フィジカルレイヤで別途のオーバーヘッドリダクション及びインプットフォーマッティング過程を経ることができるので、リンクレイヤステップではトランスペアレントモードを活用することができる。トランスペアレントモードが適用され、フィジカルレイヤでインプットフォーマッティングなどを通じてパケットを加工する場合、前述したＴＳヘッダーコンプレッションなどの動作がフィジカルレイヤで行われ得る。反対に、ノーマルモードが適用される場合、加工されたリンクレイヤパケットは、フィジカルレイヤでＧＳパケットとして取り扱われて処理され得る。
トランスペアレントモードでも、シグナリングの伝送を支援する必要がある場合、リンクレイヤシグナリングモジュールをおくことができる。リンクレイヤシグナリングモジュールは、前述したように、シグナリング情報の伝送及び管理を行うことができる。シグナリング情報は、エンカプセレーションされてＤＰを介して伝送され得、区分された伝送経路を有するＦＩＣ、ＥＡＳシグナリング情報は、それぞれＦＩＣチャンネル、ＥＡＣチャンネルを介して伝送され得る。
トランスペアレントモードで、固定されたＩＰアドレス及びＰｏｒｔ番号を使用する方法などを通じて、当該情報がシグナリング情報であるか否かを示すことができる。この場合、当該シグナリング情報をフィルタリングしてリンクレイヤパケットを構成した後、フィジカルレイヤを介して伝送してもよい。
図２１は、本発明の一実施例に係る、リンクレイヤでの送信機及び／又は受信機の動作モードコントロール（ｃｏｎｔｒｏｌ）過程を示した図である。
リンクレイヤの送信機または受信機の動作モードを決定することは、放送システムをより効率的に使用し、放送システムに対する柔軟な設計を可能にする方法となり得る。本発明で提案するリンクレイヤモードをコントロールする方案によれば、システム帯域幅及びプロセシングタイムに対する効率的な運用のためのリンクレイヤのモードを動的に切り替えることができるという効果がある。また、本発明のリンクレイヤモードをコントロールする方案によれば、フィジカルレイヤの変更により、特定のモードに対する支援が必要であるか、またはその反対に特定のモードに対する必要性がなくなった場合、これに対する対処が容易である。また、リンクレイヤモードをコントロールする方案によれば、放送サービスを提供する放送会社で当該サービスに対する伝送方法を指定しようとする場合にも、当該放送会社の要求を放送システムで容易に収容できるという効果がある。
リンクレイヤの動作モードをコントロールするための方案は、リンクレイヤの内部でのみ動作するように構成したり、リンクレイヤの内部でのデータ構造の変化を通じて行うことができる。この場合、ネットワークレイヤ及び／又はフィジカルレイヤで、別途の機能に対する追加具現なしにも、各レイヤの独立した動作を行うことが可能である。本発明で提案するリンクレイヤのモードは、フィジカルレイヤの構造に合わせるためにシステムを変形せずに、シグナリングまたはシステムの内部のパラメータでコントロールが可能である。特定のモードの場合には、当該入力に対する処理が、フィジカルレイヤで支援する場合に限って動作してもよい。
図面は、送信機及び／又は受信機が、ＩＰレイヤ、リンクレイヤ、及びフィジカルレイヤで信号及び／又はデータを処理する流れを示した図である。
リンクレイヤにモードコントロールのための機能ブロック（ハードウェア及び／又はソフトウェアで具現可能）が追加され、パケットを処理するか否かを決定するためのパラメータ及び／又はシグナリング情報を管理する役割を果たすことができる。モードコントロール機能ブロック（Ｍｏｄｅ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎａｌ ｂｌｏｃｋ）が有している情報を用いて、リンクレイヤでは、パケットストリームの処理過程に当該機能（ｆｕｎｃｔｉｏｎ）を行うか否かを判断することができる。
送信機での動作をまず説明する。
送信機は、ＩＰストリームがリンクレイヤに入力されると、モードコントロールパラメータ（ｊ１６００５）を用いてオーバーヘッドリダクション（ｊ１６０２０）を行うか否かを決定する（ｊ１６０１０）。モードコントロールパラメータは、送信機でサービス提供者によって生成されてもよい。モードコントロールパラメータに関する詳細は後述する。
オーバーヘッドリダクション（ｊ１６０２０）が行われる場合、オーバーヘッドリダクションに対する情報を生成し、リンクレイヤシグナリング（ｊ１６０６０）情報に含ませる。リンクレイヤシグナリング（ｊ１６０６０）情報は、モードコントロールパラメータの一部又は全部を含んでもよい。リンクレイヤシグナリング（ｊ１６０６０）情報は、リンクレイヤシグナリングパケットの形態で伝達されてもよい。リンクレイヤシグナリングパケットは、ＤＰにマッピングされて受信機に伝達されてもよいが、ＤＰにマッピングされず、放送信号の一定の領域を介して、リンクレイヤシグナリングパケットの形態で受信機に伝達されてもよい。
オーバーヘッドリダクション（ｊ１６０２０）を経たパケットストリームは、エンカプセレーション（ｊ１６０３０）されてフィジカルレイヤのＤＰに入力される（ｊ１６０４０）。オーバーヘッドリダクションを経ない場合には、再びエンカプセレーションを行うか否かを決定する（ｊ１６０５０）。
エンカプセレーション（ｊ１６０３０）を経たパケットストリームは、フィジカルレイヤのＤＰ（ｊ１６０４０）に入力される。このとき、フィジカルレイヤでは、一般的なパケット（ｌｉｎｋ ｌａｙｅｒ ｐａｃｋｅｔ）に対する処理のための動作を行う。オーバーヘッドリダクション及びエンカプセレーションを経ない場合には、ＩＰパケットが直接フィジカルレイヤに伝達される。このとき、フィジカルレイヤでは、ＩＰパケットに対する処理のための動作を行う。ＩＰパケットが直接伝送される場合には、フィジカルレイヤでＩＰパケット入力を支援する場合に限って動作するようにパラメータを付与することができる。すなわち、モードコントロールパラメータの値を調節して、フィジカルレイヤでＩＰパケットに対する処理を支援しない場合は、ＩＰパケットを直接フィジカルレイヤに伝送する過程が動作しないように設定することができる。
送信機は、このような過程を経た放送信号を受信機に伝送する。
受信機の動作を説明する。
受信機で、ユーザの操作などによるチャンネル変更などの理由で、特定のＤＰが選択され、当該ＤＰでパケットストリームが受信されると（ｊ１６１１０）、パケットストリームのヘッダー及び／又はシグナリング情報を用いて、送信時にどのモードでパケットが生成されたかを確認することができる（ｊ１６１２０）。当該ＤＰに対して、送信時の動作モードが確認されると、リンクレイヤの受信動作過程によってデカプセレーション（ｊ１６１３０）及びオーバーヘッドリダクション（ｊ１６１４０）過程を経て上位レイヤにＩＰパケットが伝達される。オーバーヘッドリダクション（ｊ１６１４０）過程は、オーバーヘッドリカバリー過程を含むことができる。
図２２は、本発明の一実施例に係る、フラグ（ｆｌａｇ）の値によるリンクレイヤでの動作、及びフィジカルレイヤに伝達されるパケットの形態を示した図である。
リンクレイヤの動作モードを決定するために、前述したシグナリング方法を用いることができる。これと関連するシグナリング情報が、受信機に直接的に伝送されてもよい。この場合、前述したシグナリングデータまたはリンクレイヤシグナリングパケットに、後述するモードコントロールと関連する情報が含まれてもよい。
一方、受信機の複雑度を考慮して、リンクレイヤの動作モードを間接的に受信機に知らせる方法があり得る。
Ｏｐｅｒａｔｉｏｎモードのコントロールに対して、次のような２種類のフラグを考慮することができる。
−ＨＣＦ（Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ Ｆｌａｇ）：当該リンクレイヤでヘッダーコンプレッションを適用するか否かを決定するフラグであって、Ｅｎａｂｌｅ、Ｄｉｓａｂｌｅを意味する値を付与することができる。
−ＥＦ（Ｅｎｃａｐｓｕｌａｔｉｏｎ Ｆｌａｇ）：当該リンクレイヤでエンカプセレーションを適用するか否かを決定するフラグであって、Ｅｎａｂｌｅ、Ｄｉｓａｂｌｅを意味する値を付与することができる。ただし、ヘッダーコンプレッション技法によって必ずエンカプセレーションが伴わなければならない場合には、ＥＦをＨＣＦに従属させて定義することができる。
各フラグにマッピングされる値は、Ｅｎａｂｌｅ及びＤｉｓａｂｌｅの表現を含むことができる範囲内でシステム構成に応じて付与することができ、各フラグに割り当てられるビット数も変更可能である。一実施例として、ｅｎａｂｌｅ値を１、ｄｉｓａｂｌｅ値を０にマッピングすることができる。
図示したように、ＨＣＦ、ＥＦの値によって、リンクレイヤに含まれるヘッダーコンプレッション及びエンカプセレーション動作を行うか否か、及びこれによってフィジカルレイヤに伝達されるパケットのフォーマットに対して示したものである。すなわち、本発明の一実施例によれば、受信機は、ＨＣＦ及びＥＦに対する情報から、フィジカルレイヤに入力されるパケットの形態を知ることができる。
図２３は、本発明の一実施例に係る送受信機でのＩＰオーバーヘッドリダクション（ＩＰ ｏｖｅｒｈｅａｄ ｒｅｄｕｃｔｉｏｎ）過程を示した図である。
本発明の一実施例によれば、ＩＰストリームがオーバーヘッドリダクション過程に進入すると、ＲｏＨＣコンプレッサー（Ｌ５０１０）は、当該ストリームに対するヘッダー圧縮を行うことができる。本発明の一実施例は、ヘッダー圧縮アルゴリズムとしてＲｏＨＣ方法を使用することができる。パケットストリームコンフィギュレーション（Ｃｏｎｆｉｇｕｒａｔｉｏｎ）過程（Ｌ５０２０）でＲｏＨＣ過程を経たパケットストリーム（ｐａｃｋｅｔ ｓｔｒｅａｍ）は、ＲｏＨＣパケットの形態によって再構成され、再構成されたＲｏＨＣパケットストリームは、エンカプセレーションレイヤ（Ｌ５０４０）に伝達され、次いで、フィジカルレイヤを介して受信機に伝送され得る。パケットストリームを再構成する過程で生成されたＲｏＨＣコンテキスト情報及び／又はシグナリング情報は、シグナリングジェネレーター（Ｌ５０３０）を介して伝送が可能な形態で作られ、伝送形態によってエンカプセレーションレイヤまたはシグナリングモジュール（Ｌ５０５０）に伝達されてもよい。
本発明の一実施例によれば、受信機は、サービスデータ（ｄａｔａ）に対するストリームとシグナリングチャンネル、または別途のＤＰを介して伝達されるシグナリングデータを受信することができる。シグナリングパーサ（Ｌ５０６０）は、シグナリングデータを受信してＲｏＨＣコンテキスト情報及び／又はシグナリング情報をパーシングし、パーシングされた情報をパケットストリームリカバリー過程（Ｌ５０７０）に伝達することができる。パケットストリームリカバリー過程（Ｌ５０７０）では、受信機は、シグナリングデータに含まれたＲｏＨＣコンテキスト情報及び／又はシグナリング情報を用いて、送信側で再構成されたパケットストリームを、ＲｏＨＣデコンプレッサー（Ｌ５０８０）が圧縮を解除できる形態に復旧することができる。ＲｏＨＣデコンプレッサー（Ｌ５０８０）は、復旧されたＲｏＨＣパケットストリームをＩＰストリームに変換することができ、変換されたＩＰストリームは、ＩＰレイヤを介して上位レイヤに伝達されてもよい。
図２４は、本発明の一実施例に係る、ＲｏＨＣのプロファイル（Ｐｒｏｆｉｌｅｓ）を示した図である。
前述したように、本発明の一実施例によれば、リンクレイヤでの上位パケットに対するヘッダー圧縮のために、ＲｏＨＣを使用することができる。放送網の特性を考慮すると、ＲｏＨＣフレームワーク（ｆｒａｍｅｗｏｒｋ）は、ＲＦＣ ３０９５文書に記述されたように単方向モード（ｕｎｉｄｉｒｅｃｔｉｏｎａｌ ｍｏｄｅ）で動作することができる。ＲｏＨＣフレームワークは、複数のヘッダー圧縮プロファイルを定義している。それぞれのプロファイルは、特定のプロトコルの組み合わせを示し、それぞれのプロファイルを識別するプロファイル識別子（ｉｄｅｎｔｉｆｉｅｒ）は、ＩＡＮＡ（Ｉｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ｎｕｍｂｅｒｓ Ａｕｔｈｏｒｉｔｙ）によって割り当てられてもよい。図示されたプロファイルの一部は、本発明の実施例に係る放送システムで使用することができる。
図２５は、本発明の一実施例に係る第１構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅ ＃１）に対して、ＲｏＨＣパケットストリームの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び復元（ｒｅｃｏｖｅｒｙ）過程を示した図である。
本発明の一実施例に係る送信機でのＲｏＨＣパケットストリームの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）過程は、次の通りである。
本発明の一実施例に係る送信機は、ＲｏＨＣヘッダー情報に基づいて、ＲｏＨＣパケットストリーム（ＲｏＨＣ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１００１０）からＩＲパケット及びＩＲ−ＤＹＮパケットを検出することができる。次に、送信機は、ＩＲ及びＩＲ−ＤＹＮパケットに含まれたシーケンスナンバー（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）を用いて、一般的なヘッダー圧縮されたパケット（Ｇｅｎｅｒａｌ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｅｄ Ｐａｃｋｅｔ）を生成することができる。上述した一般的なヘッダー圧縮されたパケットのタイプに関係なく、一般的なヘッダー圧縮されたパケットは、ＳＮ（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）情報を含むので任意に生成され得る。ここで、ＳＮは、基本的にＲＴＰに存在する情報に該当し、ＵＤＰの場合には、送信機で任意にＳＮを生成して使用することができる。次に、送信機は、該当するＩＲまたはＩＲ−ＤＹＮパケットを、生成された一般的なヘッダー圧縮されたパケットに代えることができ、送信機は、ＩＲパケットからスタティックチェーン（ｓｔａｔｉｃ ｃｈａｉｎ）及びダイナミックチェーン（ｄｙｎａｍｉｃ ｃｈａｉｎ）を抽出することができ、ＩＲ−ＤＹＮパケットからダイナミックチェーンを抽出することができる。抽出されたスタティックチェーン及びダイナミックチェーンは、帯域外（Ｏｕｔ ｏｆ Ｂａｎｄ）（Ｌ１００３０）で伝送されてもよい。送信機は、全てのＲｏＨＣパケットストリームに対して、上述した過程と同一の過程によって、ＩＲ及びＩＲ−ＤＹＮヘッダーを一般的なヘッダー圧縮されたパケットのヘッダーに代えることができ、スタティックチェーン及び／又はダイナミックチェーンを抽出することができる。再構成されたパケットストリーム（Ｒｅｃｏｎｆｉｇｕｒｅｄ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１００２０）は、データパイプ（ｄａｔａ ｐｉｐｅ）を介して伝送されてもよく、抽出されたスタティックチェーン及びダイナミックチェーンは帯域外（Ｌ１００３０）で伝送されてもよい。
本発明の一実施例に係る受信機でＲｏＨＣパケットストリームを復元（ｒｅｃｏｖｅｒｙ）する過程は、次の通りである。
本発明の一実施例に係る受信機は、シグナリング（Ｓｉｇｎａｌｉｎｇ）情報を用いて、受信しようとするストリームのデータパイプを選択することができる。次に、受信機は、データパイプを介して伝送される受信しようとするパケットストリームを受信することができ（Ｒｅｃｅｉｖｅｄ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１００４０）、受信しようとするパケットストリームに該当するスタティックチェーン及びダイナミックチェーンを検出することができる。ここで、スタティックチェーン及び／又はダイナミックチェーンは、帯域外で受信されてもよい（Ｏｕｔ ｏｆ Ｂａｎｄ Ｒｅｃｅｐｔｉｏｎ、Ｌ１００５０）。次に、受信機は、抽出されたスタティックチェーン及びダイナミックチェーンのＳＮを用いて、データパイプを介して伝送されるパケットストリームのうち、上述したスタティックチェーンまたはダイナミックチェーンのＳＮと同一のＳＮを有する一般的なヘッダー圧縮されたパケットを検出することができる。次に、受信機は、検出された一般的なヘッダー圧縮されたパケットをスタティックチェーン及び／又はダイナミックチェーンと結合してＩＲ及び／又はＩＲ−ＤＹＮパケットを構成することができ、構成されたＩＲ及び／又はＩＲ−ＤＹＮパケットはＲｏＨＣデコンプレッサーに伝送されてもよい。また、受信機は、ＩＲパケット、ＩＲ−ＤＹＮパケット及び／又は一般的なヘッダー圧縮されたパケットを含むＲｏＨＣパケットストリーム（ＲｏＨＣ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１００６０）を構成することができ、構成されたＲｏＨＣパケットストリームはＲｏＨＣデコンプレッサーに伝送されてもよい。本発明の一実施例に係る受信機は、ＲｏＨＣパケットストリームを復元するために、スタティックチェーン、ダイナミックチェーン、ＩＲパケット及びＩＲ−ＤＹＮパケットのＳＮ及び／又はＣｏｎｔｅｘｔ ＩＤを用いることができる。
図２６は、本発明の一実施例に係る第２構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅ ＃２）に対して、ＲｏＨＣパケットストリームの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び復元（ｒｅｃｏｖｅｒｙ）過程を示した図である。
本発明の一実施例に係る送信機でのＲｏＨＣパケットストリームの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）過程は、次の通りである。
本発明の一実施例に係る送信機は、ＲｏＨＣヘッダー情報に基づいて、ＲｏＨＣパケットストリーム（ＲｏＨＣ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１１０１０）からＩＲパケット及びＩＲ−ＤＹＮパケットを検出することができる。次に、送信機は、ＩＲ及びＩＲ−ＤＹＮパケットに含まれたシーケンスナンバーを用いて、一般的なヘッダー圧縮されたパケット（Ｇｅｎｅｒａｌ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｅｄ Ｐａｃｋｅｔ）を生成することができる。上述した一般的なヘッダー圧縮されたパケットのタイプに関係なく、一般的なヘッダー圧縮されたパケットは、ＳＮ（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）情報を含むので任意に生成され得る。ここで、ＳＮは、基本的にＲＴＰに存在する情報に該当し、ＵＤＰの場合には、送信機で任意にＳＮを生成して使用することができる。次に、送信機は、該当するＩＲまたはＩＲ−ＤＹＮパケットを、生成された一般的なヘッダー圧縮されたパケットに代えることができ、送信機は、ＩＲパケットからスタティックチェーンを抽出することができ、ＩＲ−ＤＹＮパケットからダイナミックチェーンを抽出することができる。抽出されたスタティックチェーン及びダイナミックチェーンは、帯域外（Ｌ１１０３０）で伝送されてもよい。送信機は、全てのＲｏＨＣパケットストリームに対して、上述した過程と同一の過程によって、ＩＲ及びＩＲ−ＤＹＮヘッダーを一般的なヘッダー圧縮されたパケットのヘッダーに代えることができ、スタティックチェーン及び／又はダイナミックチェーンを抽出することができる。再構成されたパケットストリーム（Ｒｅｃｏｎｆｉｇｕｒｅｄ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１１０２０）は、データパイプを介して伝送されてもよく、抽出されたスタティックチェーン及びダイナミックチェーンは帯域外（Ｌ１１０３０）で伝送されてもよい。
本発明の一実施例に係る受信機でＲｏＨＣパケットストリームを復元（ｒｅｃｏｖｅｒｙ）する過程は、次の通りである。
本発明の一実施例に係る受信機は、シグナリング（Ｓｉｇｎａｌｉｎｇ）情報を用いて、受信しようとするストリームのデータパイプを選択することができる。次に、受信機は、データパイプを介して伝送される受信しようとするパケットストリームを受信することができ（Ｒｅｃｅｉｖｅｄ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１１０４０）、受信しようとするパケットストリームに該当するスタティックチェーン及びダイナミックチェーンを検出することができる。ここで、スタティックチェーン及び／又はダイナミックチェーンは、帯域外で受信されてもよい（Ｏｕｔ ｏｆ Ｂａｎｄ Ｒｅｃｅｐｔｉｏｎ、Ｌ１１０５０）。次に、受信機は、抽出されたスタティックチェーン及びダイナミックチェーンのＳＮを用いて、データパイプを介して伝送されるパケットストリームのうち、上述したスタティックチェーンまたはダイナミックチェーンのＳＮと同一のＳＮを有する一般的なヘッダー圧縮されたパケットを検出することができる。次に、受信機は、検出された一般的なヘッダー圧縮されたパケットをスタティックチェーン及び／又はダイナミックチェーンと結合してＩＲ及び／又はＩＲ−ＤＹＮパケットを構成することができ、構成されたＩＲ及び／又はＩＲ−ＤＹＮパケットはＲｏＨＣデコンプレッサーに伝送されてもよい。また、受信機は、ＩＲパケット、ＩＲ−ＤＹＮパケット及び／又は一般的なヘッダー圧縮されたパケットを含むＲｏＨＣパケットストリーム（ＲｏＨＣ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１１０６０）を構成することができ、構成されたＲｏＨＣパケットストリームはＲｏＨＣデコンプレッサーに伝送されてもよい。本発明の一実施例に係る受信機は、ＲｏＨＣパケットストリームを復元するために、スタティックチェーン、ダイナミックチェーン、ＩＲパケット及びＩＲ−ＤＹＮパケットのＳＮ及び／又はＣｏｎｔｅｘｔ ＩＤを用いることができる。
図２７は、本発明の一実施例に係る第３構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅ ＃３）に対して、ＲｏＨＣパケットストリームの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び復元（ｒｅｃｏｖｅｒｙ）過程を示した図である。
本発明の一実施例に係る送信機でのＲｏＨＣパケットストリームの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）過程は、次の通りである。
本発明の一実施例に係る送信機は、ＲｏＨＣヘッダー情報に基づいて、ＲｏＨＣパケットストリーム（ＲｏＨＣ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１２０１０）からＩＲパケットを検出することができる。次に、送信機は、ＩＲパケットからスタティックチェーンを抽出することができ、ＩＲパケットの構成において、抽出されたスタティックチェーンを除いた残りの部分を用いて、ＩＲパケットをＩＲ−ＤＹＮパケットに変換することができる。送信機は、全てのＲｏＨＣパケットストリームに対して、上述した過程と同一の過程によって、ＩＲパケットのヘッダーをＩＲ−ＤＹＮパケットのヘッダーに代えることができ、スタティックチェーンを抽出することができる。再構成されたパケットストリーム（Ｒｅｃｏｎｆｉｇｕｒｅｄ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１２０２０）は、データパイプを介して伝送されてもよく、抽出されたスタティックチェーンは、帯域外（Ｌ１２０３０）で伝送されてもよい。
本発明の一実施例に係る受信機でＲｏＨＣパケットストリームを復元（ｒｅｃｏｖｅｒｙ）する過程は、次の通りである。
本発明の一実施例に係る受信機は、シグナリング（Ｓｉｇｎａｌｉｎｇ）情報を用いて、受信しようとするストリームのデータパイプを選択することができる。次に、受信機は、データパイプを介して伝送される受信しようとするパケットストリームを受信することができ（Ｒｅｃｅｉｖｅｄ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１２０４０）、受信しようとするパケットストリームに該当するスタティックチェーンを検出することができる。ここで、スタティックチェーンは、帯域外で受信されてもよい（Ｏｕｔ ｏｆ Ｂａｎｄ Ｒｅｃｅｐｔｉｏｎ、Ｌ１２０５０）。次に、受信機は、データパイプを介して伝送されるパケットストリームからＩＲ−ＤＹＮパケットを検出することができる。次に、受信機は、検出されたＩＲ−ＤＹＮパケットをスタティックチェーンと結合してＩＲパケットを構成することができ、構成されたＩＲパケットはＲｏＨＣデコンプレッサーに伝送されてもよい。また、受信機は、ＩＲパケット、ＩＲ−ＤＹＮパケット及び／又は一般的なヘッダー圧縮されたパケットを含むＲｏＨＣパケットストリーム（ＲｏＨＣ Ｐａｃｋｅｔ Ｓｔｒｅａｍ、Ｌ１２０６０）を構成することができ、構成されたＲｏＨＣパケットストリームはＲｏＨＣデコンプレッサーに伝送されてもよい。本発明の一実施例に係る受信機は、ＲｏＨＣパケットストリームを復元するために、スタティックチェーン及びＩＲ−ＤＹＮパケットのＳＮ及び／又はＣｏｎｔｅｘｔ ＩＤを用いることができる。
図２８は、本発明の一実施例に係る帯域外で伝達できる情報の組み合わせを示した図である。
本発明の一実施例によれば、ＲｏＨＣパケットストリームの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）過程で抽出されたスタティックチェーン及び／又はダイナミックチェーンを帯域外で伝達する方法は、大きく、シグナリング（ｓｉｇｎａｌｉｎｇ）を介して伝達する方法、及びシステムデコーディング（ｓｙｓｔｅｍ ｄｅｃｏｄｉｎｇ）に必要なパラメータが伝達されるデータパイプを介して伝達する方法が存在し得る。本発明の一実施例によれば、上述したシステムデコーディングに必要なパラメータが伝達されるデータパイプは、Ｂａｓｅ ＤＰ（Ｄａｔａ Ｐｉｐｅ）と命名することができる。
図示したように、スタティックチェーン及び／又はダイナミックチェーンは、シグナリングまたはＢａｓｅ ＤＰを介して伝達されてもよい。本発明の一実施例によれば、第１伝送モード（Ｔｒａｎｓｐｏｒｔ Ｍｏｄｅ ＃１）〜第３伝送モード（Ｔｒａｎｓｐｏｒｔ Ｍｏｄｅ ＃３）は、第１構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅ ＃１）または第２構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅ ＃２）に使用されてもよく、第４伝送モード（Ｔｒａｎｓｐｏｒｔ Ｍｏｄｅ ＃４）〜第５伝送モード（Ｔｒａｎｓｐｏｒｔ Ｍｏｄｅ ＃５）は、第３構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅ ＃３）に使用されてもよい。
本発明の一実施例によれば、それぞれの構成モード（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅ）及び伝送モード（Ｔｒａｎｓｐｏｒｔ Ｍｏｄｅ）は、別途のシグナリングを介してシステムの状況に合わせてスイッチング（ｓｗｉｔｃｈｉｎｇ）して使用されてもよく、システム設計過程に応じて、一つの構成モード及び一つの伝送モードのみが固定されて使用されてもよい。
図示によれば、第１伝送モード（Ｔｒａｎｓｐｏｒｔ Ｍｏｄｅ ＃１）において、スタティックチェーンはシグナリングを介して伝送されてもよく、ダイナミックチェーンはシグナリングを介して伝送されてもよく、一般的なヘッダー圧縮されたパケット（Ｇｅｎｅｒａｌ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｅｄ Ｐａｃｋｅｔ）はノーマル（Ｎｏｒｍａｌ）データパイプを介して伝送されてもよい。
図示によれば、第２伝送モード（Ｔｒａｎｓｐｏｒｔ Ｍｏｄｅ ＃２）において、スタティックチェーンはシグナリングを介して伝送されてもよく、ダイナミックチェーンはベースデータパイプ（Ｂａｓｅ Ｄａｔａ Ｐｉｐｅ）を介して伝送されてもよく、一般的なヘッダー圧縮されたパケットはノーマルデータパイプを介して伝送されてもよい。
図示によれば、第３伝送モード（Ｔｒａｎｓｐｏｒｔ Ｍｏｄｅ ＃３）において、スタティックチェーンはベースデータパイプを介して伝送されてもよく、ダイナミックチェーンはベースデータパイプを介して伝送されてもよく、一般的なヘッダー圧縮されたパケットはノーマルデータパイプを介して伝送されてもよい。
図示によれば、第４伝送モード（Ｔｒａｎｓｐｏｒｔ Ｍｏｄｅ ＃４）において、スタティックチェーンはシグナリングを介して伝送されてもよく、ダイナミックチェーンはノーマルデータパイプを介して伝送されてもよく、一般的なヘッダー圧縮されたパケットはノーマルデータパイプを介して伝送されてもよい。このとき、ダイナミックチェーンは、ＩＲ−ＤＹＮパケットによって伝送されてもよい。
図示によれば、第５伝送モード（Ｔｒａｎｓｐｏｒｔ Ｍｏｄｅ ＃５）において、スタティックチェーンはベースデータパイプを介して伝送されてもよく、ダイナミックチェーンはノーマルデータパイプを介して伝送されてもよく、一般的なヘッダー圧縮されたパケット（Ｇｅｎｅｒａｌ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｅｄ Ｐａｃｋｅｔ）はノーマルデータパイプを介して伝送されてもよい。このとき、ダイナミックチェーンは、ＩＲ−ＤＹＮパケットによって伝送されてもよい。
図２９は、本発明の一実施例に係る、データパイプを介して伝送されるパケットを示した図である。
本発明の一実施例によれば、リンクレイヤでのパケットの構造を新たに定義して、リンクレイヤの上位レイヤまたはリンクレイヤの下位レイヤのプロトコルの変化に関係なく互換可能なリンクレイヤパケットを生成することができる。
本発明の一実施例に係るリンクレイヤパケットは、ｎｏｒｍａｌ ＤＰ及び／又はｂａｓｅ ＤＰを介して伝送されてもよい。
リンクレイヤパケットは、固定ヘッダー、拡張ヘッダー、及び／又はペイロードを含むことができる。
固定ヘッダーは、大きさが固定されているヘッダーであり、拡張ヘッダーは、上位レイヤのパケットの構成によって大きさの変更が可能なヘッダーである。ペイロードは、上位レイヤのデータが伝送される領域である。
パケットのヘッダー（固定ヘッダー又は拡張ヘッダー）は、パケットのペイロードの種類を表示するフィールドが含まれてもよい。固定ヘッダーの場合、１バイトのうち、最初の３ビット（ｐａｃｋｅｔ ｔｙｐｅ）は、上位レイヤのパケットタイプを識別するデータが含まれてもよく、残りの５ビットは、指示子部分（ｉｎｄｉｃａｔｏｒ ｐａｒｔ）として使用されてもよい。指示子部分は、ペイロードの構成方法、及び／又は拡張ヘッダーの構成情報を識別するデータが含まれてもよく、パケットタイプによって、構成が異なり得る。
図示されたテーブルでは、パケットタイプ（ｐａｃｋｅｔ ｔｙｐｅ）の値による、ペイロードに含まれる上位レイヤのパケットの種類を示している。
システムの構成によって、ペイロードが、ｎｏｒｍａｌ ＤＰを介してはＩＰパケット、及び／又はＲｏＨＣパケットを伝送することができ、ｂａｓｅ ＤＰを介してはシグナリングパケットを伝送することができる。したがって、種々の種類のパケットが混用して伝達される場合にも、パケットタイプの値を付与して、データパケットとシグナリングパケットを区分することもできる。
パケットタイプの値が０００である場合、ＩＰｖ４のＩＰパケットがペイロードに含まれることを示す。
パケットタイプの値が００１である場合、ＩＰｖ６のＩＰパケットがペイロードに含まれることを示す。
パケットタイプの値が０１０である場合、ｃｏｍｐｒｅｓｓｅｄ ＩＰパケットがペイロードに含まれることを示す。ｃｏｍｐｒｅｓｓｅｄ ＩＰパケットには、ヘッダー圧縮が適用されたＩＰパケットが含まれてもよい。
パケットタイプの値が１１０である場合、シグナリングデータを含むパケットがペイロードに含まれることを示す。
パケットタイプの値が１１１である場合、フレームドパケットタイプ（ｆｒａｍｅｄ ｐａｃｋｅｔ ｔｙｐｅ）がペイロードに含まれることを示すことができる。
図３０は、本発明の一実施例に係る、リンクレイヤパケット構造のシンタックスを示した図である。
本図は、前述したデータパイプを介して伝送されるパケットの構造を記述したものである。リンクレイヤパケット（Ｌｉｎｋ ｌａｙｅｒ ｐａｃｋｅｔ（））は、まず、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドを有することができる。
Ｐａｃｋｅｔ_Ｔｙｐｅフィールドの値によって、後続し得るフィールドの構成が変わり得る。図示したように、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドの値が０００又は００１である場合、Ｐａｋｃｅｔ_Ｔｙｐｅフィールドの後にＬｉｎｋ_Ｌａｙｅｒ_Ｐａｃｋｅｔ_Ｈｅａｄｅｒ_ｆｏｒ_ＩＰ（）、すなわち、ＩＰパケットのためのヘッダー構造が位置してもよい。Ｐａｃｋｅｔ_Ｔｙｐｅフィールドの値が０１０である場合、Ｐａｋｃｅｔ_Ｔｙｐｅフィールドの後にＬｉｎｋ_Ｌａｙｅｒ_Ｐａｃｋｅｔ_Ｈｅａｄｅｒ_ｆｏｒ_Ｃｏｍｐｒｅｓｓｅｄ_ＩＰ（）、すなわち、圧縮されたＩＰパケットのためのヘッダー構造が位置してもよい。Ｐａｃｋｅｔ_Ｔｙｐｅフィールドの値が０１１である場合、Ｐａｋｃｅｔ_Ｔｙｐｅフィールドの後にＬｉｎｋ_Ｌａｙｅｒ_Ｐａｃｋｅｔ_Ｈｅａｄｅｒ_ｆｏｒ_ＴＳ（）、すなわち、ＴＳパケットのためのヘッダー構造が位置してもよい。Ｐａｃｋｅｔ_Ｔｙｐｅフィールドの値が１１０である場合、Ｐａｋｃｅｔ_Ｔｙｐｅフィールドの後にＬｉｎｋ_Ｌａｙｅｒ_Ｐａｃｋｅｔ_Ｈｅａｄｅｒ_ｆｏｒ_Ｓｉｇｎａｌｉｎｇ（）、すなわち、シグナリング情報のためのヘッダー構造が位置してもよい。Ｐａｃｋｅｔ_Ｔｙｐｅフィールドの値が１１１である場合、Ｐａｋｃｅｔ_Ｔｙｐｅフィールドの後にＬｉｎｋ_Ｌａｙｅｒ_Ｐａｃｋｅｔ_Ｈｅａｄｅｒ_ｆｏｒ_Ｆｒａｍｅｄ_Ｐａｃｋｅｔ（）、すなわち、フレームドパケットのためのヘッダー構造が位置してもよい。他の値は、将来の使用のために残すことができる（Ｒｅｓｅｒｖｅｄ）。ここで、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドの値による意味は、実施例によって変更されてもよい。
以降には、リンクレイヤパケットのペイロード部分であるＬｉｎｋ_Ｌａｙｅｒ_Ｐａｃｋｅｔ_Ｐａｙｌｏａｄ（）が位置してもよい。
図３１は、本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーの構造を示した図である。
この場合、リンクレイヤパケットのヘッダーは、固定ヘッダー（Ｆｉｘｅｄ ｈｅａｄｅｒ）と拡張ヘッダー（Ｅｘｔｅｎｄｅｄ ｈｅａｄｅｒ）を含むことができる。固定ヘッダーは、１バイトの長さを有することができ、拡張ヘッダーは、固定された長さを有したり可変する値（ｖａｒｉａｂｌｅ）を長さとして有することができる。各ヘッダーの長さは、設計者の意図によって変更されてもよい。
固定ヘッダーは、パケットタイプフィールド、ＰＣフィールド及び／又はカウントフィールドを含むことができる。他の実施例によれば、固定ヘッダーは、パケットタイプフィールド、ＰＣフィールド、ＬＩフィールド及び／又はセグメントＩＤフィールドを含むことができる。
拡張ヘッダーは、セグメントシーケンスナンバー（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）フィールド及び／又はセグメント長さＩＤ（Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ ＩＤ）フィールドを含むことができる。他の実施例によれば、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又は最後のセグメント長さ（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ）フィールドを含むことができる。
固定ヘッダーのフィールドについて説明する。
パケットタイプフィールドは、前述したように、リンクレイヤに入力されるパケットのタイプを示すことができる。ＩＰパケットがリンクレイヤの入力として入る場合、パケットタイプフィールドの値は０００Ｂ又は００１Ｂであってもよい。
ＰＣ（Ｐａｃｋｅｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）フィールドは、後続する固定ヘッダーの残りの部分及び／又は拡張ヘッダーの構成を示すことができる。すなわち、ＰＣフィールドは、入力されたＩＰパケットがどのような形態で処理されたかを示すことができる。したがって、ＰＣフィールドは、拡張ヘッダーの長さに関する情報を内包することができる。
ＰＣフィールドの値が０である場合、これは、リンクレイヤパケットのペイロードが一つのＩＰパケットを含むか、または連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）した２つ以上のＩＰパケットを含むことを意味してもよい。ここで、連鎖とは、短い長さの複数のパケットが一つにつながってペイロードをなすことを意味し得る。
また、ＰＣフィールドの値が０である場合、ＰＣフィールドの後には４ビットのカウントフィールドが後続することができる。ここで、カウントフィールドは、一つのペイロードがいくつの連鎖したＩＰパケットを有しているかを示すことができる。カウントフィールドの値による連鎖したＩＰパケットの個数については後述する。
また、ＰＣフィールドの値が０である場合、リンクレイヤは、拡張ヘッダーを含まなくてもよい。しかし、実施例によって、リンクレイヤパケットの長さが表示される必要がある場合、１−２バイトの拡張ヘッダーが追加されてもよい。この場合、拡張ヘッダーは、リンクレイヤパケットの長さを示すのに活用することができる。
ＰＣフィールドの値が１である場合、これは、リンクレイヤパケットのペイロードが分割されたパケット（ｓｅｇｍｅｎｔｅｄ ｐａｃｋｅｔ）を含むことを意味し得る。ここで、分割されたパケットは、長い長さのＩＰパケットがいくつのセグメントに分けられたことを意味し得る。各分割された断片は、セグメント又は分割されたパケットと呼ぶことができる。すなわち、ＰＣフィールドの値が１である場合、リンクレイヤパケットのペイロードは、一つの分割された断片、すなわち、セグメントを含むことができる。
また、ＰＣフィールドの値が１である場合、ＰＣフィールドの後には、１ビットのＬＩフィールドと３ビットのセグメントＩＤフィールドが後続してもよい。
ＬＩ（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｉｎｄｉｃａｔｏｒ）フィールドは、当該リンクレイヤパケットが分割されたセグメントのうち最後のセグメントを含むか否かを示すことができる。すなわち、ＬＩ値が１である場合、当該リンクレイヤは、分割されたセグメントのうち最後のセグメントを含み、ＬＩ値が０である場合にはそうでない。ＬＩフィールドは、受信機が本来のＩＰパケットを再構成するときに用いることができる。ＬＩフィールドの値は、リンクレイヤパケットの拡張ヘッダーに関する情報を示すこともできる。すなわち、ＬＩフィールドの値が０である場合、拡張ヘッダーの長さは１バイト、ＬＩフィールドの値が１である場合、拡張ヘッダーの長さは２バイトであってもよい。詳細は後述する。
セグメントＩＤフィールドは、当該リンクレイヤパケットが含むセグメントのＩＤを示すことができる。一つのＩＰパケットが分割されるとき、各セグメントには同一のＩＤを与えられることができる。このセグメントＩＤは、受信機が本来のＩＰパケットを再構成するとき、それぞれのセグメントが同一のＩＰパケットの構成要素であることを知ることができるようにする。セグメントＩＤフィールドは３ビットの大きさを有するので、同時に総８個のＩＰパケットの分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を支援することができる。
また、ＰＣフィールドの値が１である場合、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）に関する情報のために拡張ヘッダーを用いることができる。前述したように、拡張ヘッダーは、セグメントシーケンスナンバー、セグメント長さＩＤフィールド、及び／又は最後のセグメント長さ（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ）フィールドなどを含むことができる。
拡張ヘッダーのフィールドについて説明する。
前述したＬＩフィールドが０の値を有する場合、すなわち、リンクレイヤパケットが含むセグメントが最後のセグメントではない場合、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又はセグメント長さＩＤフィールドを含むことができる。
セグメントシーケンスナンバーフィールドは、分割されたパケットが何番目のパケットであるかを示すことができる。したがって、一つのＩＰパケットから分割されたセグメントを有するリンクレイヤパケットは、同一のセグメントＩＤフィールドを有するが、異なるセグメントシーケンスナンバーフィールドを有する。セグメントシーケンスナンバーフィールドは４ビットの大きさを有するので、一つのＩＰパケットは、最大１６個のセグメントに分割され得る。
セグメント長さＩＤフィールドは、最後のセグメント以外のセグメントの長さを示すことができる。最後のセグメント以外のセグメントの長さは同一であってもよい。したがって、これらの長さは、予め指定された長さＩＤを用いて表現することができる。セグメント長さＩＤフィールドは、その長さＩＤを示すことができる。
セグメントの長さは、フィジカルレイヤのＦＥＣコードレートによって決定されているパケットの入力サイズに合わせて設定することができる。すなわち、その入力サイズに合わせてセグメントの長さを決定することができ、そのセグメントの長さが、セグメント長さＩＤによって指定されてもよい。ヘッダーのオーバーヘッドを低減するために、セグメントが有し得る長さは１６個に制限することができる。
セグメントの長さによるセグメント長さＩＤフィールドの値については後述する。
フィジカルレイヤがセグメントの長さに関係なく動作する場合、セグメントの長さは、セグメント長さＩＤと長さユニット（Ｌｅｎ_Ｕｎｉｔ、Ｌｅｎｇｔｈ Ｕｎｉｔ）の積に最小セグメント長さ（ｍｉｎ_Ｌｅｎ、ｍｉｎｉｍｕｍ ｓｅｇｍｅｎｔ ｌｅｎｇｔｈ）を足して求めることができる。ここで、長さユニットは、セグメントの長さを表示する基本単位であり、最小セグメント長さは、セグメントの長さの最小値を意味し得る。長さユニットと最小セグメント長さは、送信機と受信機で常に同じ値を有しなければならず、一度決定されると変わらない方が、システムの運用に効率的である。長さユニットと最小セグメント長さは、システムの初期化過程でフィジカルレイヤのＦＥＣ処理能力を考慮して決定することができる。
前述したＬＩフィールドが１の値を有する場合、すなわち、リンクレイヤパケットが含むセグメントが最後のセグメントである場合、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又は最後のセグメント長さフィールドを含むことができる。
セグメントシーケンスナンバーフィールドは、前述した通りである。
最後のセグメント長さフィールドは、最後のセグメントの長さを直接示すことができる。一つのＩＰパケットが特定の長さを有するセグメントに分割される場合、最後のセグメントは、その長さが他のセグメントと異なり得る。したがって、最後のセグメント長さフィールドが、最後のセグメントの長さを直接示すことができる。最後のセグメント長さフィールドは、１〜４０９５バイトを表示することができる。表示可能なバイト数は、実施例によって変わってもよい。
図３２は、前述した本発明の他の実施例に係るリンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーの構造のシンタックスを示した図である。
リンクレイヤパケットのヘッダー（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ Ｈｅａｄｅｒ（））は、まず、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣ（Ｐａｙｌｏａｄ_Ｃｏｎｆｉｇ）フィールドを有することができる。これについては、前述した通りである。
ＰＣフィールドの値が０である場合、後にＣｏｕｎｔフィールドが位置してもよい。
ＰＣフィールドの値が１である場合、後にＬａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールド、Ｓｅｇｍｅｎｔ_ＩＤフィールド、Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒフィールドが位置してもよい。このとき、Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールドの値によって、その後続部分の構成が変わり得る。Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールドが０である場合、Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒフィールドの後にＳｅｇｍｅｎｔ_Ｌｅｎｇｔｈ_ＩＤフィールドが位置してもよい。Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールドが１である場合、Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒフィールドの後にＬａｓｔ_Ｓｅｇｍｅｎｔ_Ｌｅｎｇｔｈフィールドが位置してもよい。
図３３は、本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーにおいて、各フィールドの値が示すものを示した図である。
前述したように、カウントフィールドの値によって、連鎖したＩＰパケットの数が決定され得る（ｔ６１０１０）。カウントフィールドの値は、そのまま連鎖したＩＰパケットの数を示すこともできるが、０個のパケットが連鎖した場合は意味がない。したがって、カウントフィールドは、カウントフィールドの値に１を足した数のＩＰパケットが連鎖していることを示すことができる。すなわち、表ｔ６１０１０のように、００１０の場合に３個、０１１１の場合に８個のＩＰパケットが連鎖していることが表現され得る。
ここで、カウントフィールドの値が００００である場合、１個のＩＰパケットが連鎖していることを示すが、これは連鎖なしに、リンクレイヤパケットのペイロードが一つのＩＰパケットを含むことを示すことができる。
前述したように、分割されたセグメントの長さは、セグメント長さＩＤフィールドの値によって表現することができる（ｔ６１０２０）。
例えば、セグメント長さＩＤフィールドの値が００００である場合、セグメント長さは５１２バイトであり得る。これは、当該リンクレイヤパケットのペイロードが含むセグメントが最後のセグメントではなく、５１２バイトの長さを有することを意味し得る。このセグメントと同じＩＰパケットから分割された他のセグメントも、最後のセグメントでなければ、５１２バイトの長さを有することができる。
本表では、長さユニットは２５６、最小セグメント長さは５１２の値を有する。したがって、最小のセグメント長さは５１２バイト（セグメント長さＩＤフィールド＝００００）である。また、指定されたセグメントの長さは２５６バイトの間隔を持って増加する。
図３４は、本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーにおいて、一つのＩＰパケットがリンクレイヤペイロードに含まれる場合を示した図である。
一つのＩＰパケットがリンクレイヤペイロードに含まれる場合、すなわち、連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）又は分割（ｓｅｇｍｅｎｔａｔｉｏｎ）が行われない場合を、ノーマルパケットにエンカプセレーションする場合と呼ぶことができる。この場合は、ＩＰパケットがフィジカルレイヤの処理範囲内にある場合であってもよい。
本実施例において、リンクレイヤパケットは、合計１バイトのヘッダーを有することができる。ヘッダーの長さは、実施例によって変更されてもよい。パケットタイプフィールドの値は０００（ＩＰｖ４の場合）、または００１（ＩＰｖ６の場合）であってもよい。ノーマルパケットエンカプセレーション過程は、ＩＰｖ４又はＩＰｖ６に同一に適用することができる。ＰＣフィールドの値は、一つのパケットがペイロードに含まれるので、０であり得る。後続するカウントフィールドは、同様に一つのパケットのみがペイロードに含まれるので、００００の値を有することができる。
本実施例において、リンクレイヤパケットのペイロードは、一つのＩＰパケットをそのまま含むことができる。
本実施例において、リンクレイヤパケットの長さを確認するためには、ＩＰパケットヘッダーの情報を活用することができる。ＩＰパケットのヘッダーには、ＩＰパケットの長さを示すフィールドが含まれている。このフィールドを長さフィールドと呼ぶことができる。この長さフィールドがＩＰパケット内に位置する位置は固定されていてもよい。一つのＩＰパケットがそのままリンクレイヤのペイロードに入るので、リンクレイヤパケットのペイロードの開始から一定のオフセット長さだけ移動した位置に、この長さフィールドが位置することができる。したがって、この長さフィールドを用いて全リンクレイヤのペイロードの長さを知ることができる。
ＩＰｖ４の場合、ペイロード開始点から２バイト、ＩＰｖ６の場合、ペイロード開始点から４バイトだけ移動した位置に、この長さフィールドが位置してもよい。長さフィールドは、２バイトの長さを有することができる。
ＩＰｖ４の場合において、長さフィールドの値をＬIPv4とし、リンクレイヤパケットのヘッダー長さをＬH（１バイト）とすれば、全リンクレイヤパケットの長さ（ＬT）は、図示された数式のように示すことができる（ｔ６２０１０）。ここで、長さフィールドの値ＬIPv4は、ＩＰｖ４パケットの全長を示すことができる。
ＩＰｖ６の場合において、長さフィールドの値をＬIPv6とし、リンクレイヤパケットのヘッダー長さをＬH（１バイト）とすれば、全リンクレイヤパケットの長さ（ＬT）は、図示された数式のように示すことができる（ｔ６２０２０）。ここで、長さフィールドの値ＬIPv6は、ＩＰｖ６パケットのペイロードの長さのみを示すので、全リンクレイヤパケットの長さを求めるためには、ＩＰｖ６パケットの固定ヘッダー長さ（４０バイト）を加算しなければならない。
図３５は、本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーにおいて、複数個のＩＰパケットが連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）してリンクレイヤペイロードに含まれる場合を示した図である。
入力されたＩＰパケットがフィジカルレイヤの処理範囲に到達できない場合、複数個のＩＰパケットを連結して一つのリンクレイヤパケットのペイロードにエンカプセレーションすることができる。
本実施例において、リンクレイヤパケットは、合計１バイトのヘッダーを有することができる。ヘッダーの長さは、実施例によって変更されてもよい。パケットタイプフィールドの値は０００（ＩＰｖ４の場合）、または００１（ＩＰｖ６の場合）であってもよい。本実施例のエンカプセレーション過程は、ＩＰｖ４又はＩＰｖ６に同一に適用することができる。ＰＣフィールドの値は、連鎖した複数個のＩＰパケットがペイロードに含まれるので、０であり得る。後続するカウントフィールドは、連鎖した複数個のＩＰパケットの数を示すことができる（４ビット）。
本実施例において、リンクレイヤパケットのペイロードは、複数個のＩＰパケットを含むことができる。複数個のＩＰパケットは前後で互いに連結されてリンクレイヤパケットのペイロードに含まれてもよい。連鎖方式は、設計者の意図によって変更されてもよい。
本実施例において、リンクレイヤパケットの長さを確認するためには、連鎖したＩＰパケットヘッダーの情報を活用することができる。前述したノーマルパケットエンカプセレーションと同様に、各ＩＰパケットのヘッダーには、そのＩＰパケットの長さを示す長さフィールドが存在し得る。また、この長さフィールドは、ＩＰパケット内で固定された位置に位置してもよい。
したがって、リンクレイヤパケットのヘッダー長さをＬH、それぞれのＩＰパケットの長さをＬk（ここで、ｋは、１より大きいか又は同一であり、ｎより小さいか又は同一である）とすれば、全リンクレイヤパケットの長さ（ＬT）は、図示された数式のように示すことができる（ｔ６３０１０）。すなわち、各ＩＰパケットの長さフィールドが示す各ＩＰパケットの長さを全て合算し、それにリンクレイヤパケットのヘッダー長さを加算すると、全リンクレイヤパケットの長さを求めることができる。Ｌkの値は、各ＩＰパケットのヘッダーの長さフィールドを読んで確認することができる。
図３６は、本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーにおいて、一つのＩＰパケットが分割（ｓｅｇｍｅｎｔａｔｉｏｎ）されてリンクレイヤペイロードに含まれる場合を示した図である。
入力されたＩＰパケットがフィジカルレイヤの処理範囲を超える場合、一つのＩＰパケットは複数個のセグメントに分割されてもよい。各分割されたセグメントは、それぞれのリンクレイヤパケットのペイロードにエンカプセレーションすることができる。
本実施例において、各リンクレイヤパケット（ｔ６４０１０，ｔ６４０２０，ｔ６４０３０）は、固定ヘッダーと拡張ヘッダーを有することができる。各固定ヘッダー及び拡張ヘッダーの長さは、実施例によって変更されてもよい。パケットタイプフィールドの値は０００（ＩＰｖ４の場合）、または００１（ＩＰｖ６の場合）であってもよい。本実施例のエンカプセレーション過程は、ＩＰｖ４又はＩＰｖ６に同一に適用することができる。ＰＣフィールドの値は、分割されたセグメントがペイロードに含まれるので、１であり得る。
最後のセグメント以外のセグメントをペイロードとして有するリンクレイヤパケット（ｔ６４０１０，ｔ６４０２０）は、ＬＩフィールドの値が０であり得、それぞれのセグメントＩＤフィールドは同一の値を有することができる。各セグメントが同じＩＰパケットから分割されたセグメントであるためである。後続するセグメントシーケンスナンバーフィールドは、当該セグメントの順序を示すことができる。ここで、１番目のリンクレイヤパケット（ｔ６４０１０）のセグメントシーケンスフィールド値は、当該リンクレイヤパケットが１番目のセグメントをペイロードとして有することを示すことができる。２番目のリンクレイヤパケット（ｔ６４０２０）のセグメントシーケンスフィールド値は、当該リンクレイヤパケットが２番目のセグメントをペイロードとして有することを示すことができる。セグメント長さＩＤフィールドは、分割されたセグメントの長さを、予め指定された長さＩＤで表現することができる。
最後のセグメントをペイロードとして有するリンクレイヤパケット（ｔ６４０３０）は、ＬＩフィールドの値が１であり得る。ここで、セグメントＩＤフィールドは、他のリンクレイヤパケットと同一であってもよい。最後のセグメントも、同じＩＰパケットから分割されたセグメントであるためである。後続するセグメントシーケンスナンバーフィールドは、当該セグメントの順序を示すことができる。最後のセグメント長さフィールドは、このリンクレイヤパケット（ｔ６４０３０）が有する最後のセグメントの長さを直接示すことができる。
本実施例において、リンクレイヤパケットの長さを確認するためには、セグメント長さＩＤフィールド、または最後のセグメント長さフィールドを活用することができる。各フィールドは、当該リンクレイヤパケットのペイロードの長さのみを示すので、全リンクレイヤパケットの長さを求めるためには、リンクレイヤパケットのヘッダー長さを加算しなければならない。リンクレイヤパケットのヘッダー長さは、前述したように、ＬＩフィールドから知ることができる。
図３７は、本発明の他の実施例に係る、リンクレイヤにＩＰパケットが伝達される場合のリンクレイヤパケットのヘッダーにおいて、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）されたセグメントを有するリンクレイヤパケットを示した図である。
本実施例は、５５００バイトのＩＰパケットが入力として入ったことを仮定する。５５００を５で割った値は１１００であるので、この値と最も近い１０２４バイトの長さで各セグメントを構成することができる。この場合、最後のセグメントは１４０４バイト（０１０１０１１１１１００Ｂ）であり得る。分割されたそれぞれのセグメントをＳ1，Ｓ2，Ｓ3，Ｓ4，Ｓ5と呼ぶことができ、それに該当するヘッダーをそれぞれＨ1，Ｈ2，Ｈ3，Ｈ4，Ｈ5と呼ぶことができる。セグメントにヘッダーが追加してそれぞれのリンクレイヤパケットを生成することができる。
入力されたＩＰパケットがＩＰｖ４パケットである場合、Ｈ1〜Ｈ5のパケットタイプフィールドは０００の値を有することができる。また、Ｈ1〜Ｈ5のＰＣフィールド値は、分割されたパケットをペイロードとして有するので、１であり得る。
Ｈ1〜Ｈ4のＬＩ値は、最後のセグメントをペイロードとして有しないので、０であり得る。Ｈ5のＬＩ値は、最後のセグメントをペイロードとして有するので、１であり得る。Ｈ1〜Ｈ5のＳｅｇ_ＩＤ、すなわち、セグメントＩＤフィールドは、いずれも同一のパケットから分割されたセグメントをペイロードとして有するので、同じ値（０００）を有することができる。
Ｈ1〜Ｈ5のＳｅｇ_ＳＮ、すなわち、セグメントシーケンスナンバーフィールドは、Ｈ1からＨ5まで順に００００Ｂから０１００Ｂと表示することができる。Ｈ1〜Ｈ4のセグメント長さＩＤフィールドは、１０２４バイト長のＩＤに該当する００１０の値を有することができる。Ｈ5のセグメント長さフィールドは、１４０４バイトを示す０１０１０１１１１１００をその値として有することができる。
図３８は、本発明の一実施例に係るＲｏＨＣ伝送のためのリンクレイヤパケットのヘッダーを示した図である。
ＩＰベースの放送環境でも、ＩＰパケットが前述したリンクレイヤパケットに圧縮されて伝送され得る。ＩＰベースの放送システムでストリーミングをする場合に、一般的にＩＰパケットのヘッダー情報がほとんど変わらずに維持され得る。この点を用いてＩＰパケットのヘッダーを圧縮することができる。
ＩＰパケットのヘッダー（＝ＩＰヘッダー）を圧縮する際に、ＲｏＨＣ（（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）技法が主に用いられる。本発明では、ＲｏＨＣパケットがリンクレイヤ（ｌｉｎｋ ｌａｙｅｒ）に入力として入った場合における圧縮（ｅｎｃａｐｓｕｌａｔｉｏｎ）方法を提案する。
ＲｏＨＣパケットがリンクレイヤの入力として入る場合、前述したパケットタイプエレメントの値は０１０Bであり得る。これは、前述したように、上位レイヤからリンクレイヤへ伝達されるパケットがＣｏｍｐｒｅｓｓｅｄ ＩＰパケットであることを示す。
ＲｏＨＣパケットが入力される場合、リンクレイヤパケットのヘッダーは、前述した他のパケットと同様に、固定ヘッダー（Ｆｉｘｅｄ Ｈｅａｄｅｒ）及び／又は拡張ヘッダー（Ｅｘｔｅｎｄｅｄ Ｈｅａｄｅｒ）を含むことができる。
固定ヘッダーは、パケットタイプフィールド及び／又はＰＣ（Ｐａｃｋｅｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）フィールドを含むことができる。固定ヘッダーは、合計１バイトのサイズを有することができる。ここで、パケットタイプフィールドは、Ｃｏｍｐｒｅｓｓｅｄ ＩＰパケットの場合であるから、０１０の値を有することができる。拡張ヘッダーは、実施例によって固定又は可変するサイズを有することができる。
固定ヘッダーのＰＣフィールドは、リンクレイヤパケットのペイロードを構成するＲｏＨＣパケットが処理される形態を示すフィールドであり得る。ＰＣフィールドの値によって、これに後続する固定ヘッダーの残りの部分及び拡張ヘッダーの情報が決定され得る。また、ＰＣフィールドは、ＲｏＨＣパケットが処理される形態による拡張ヘッダーの長さ情報を内包することができる。ＰＣフィールドは、１ビットのサイズを有することができる。
ＰＣフィールドの値が０Bである場合について説明する。
ＰＣフィールドの値が０Bである場合、リンクレイヤパケットのペイロードが、一つのＲｏＨＣパケットで構成されたり、２つ以上のＲｏＨＣパケットの連鎖で構成される場合に該当する。連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）は、複数個の短い長さのパケットがつながって、リンクレイヤパケットのペイロードを構成する場合を意味する。
ＰＣフィールドの値が０Bである場合、ＰＣフィールドの後に１ビットのＣＩ（Ｃｏｍｍｏｎ ＣＩＤ Ｉｎｄｉｃａｔｏｒ）フィールドと３ビットのカウントフィールドが後続することができる。これによって、拡張ヘッダーに共通ＣＩＤ情報と長さパート（ｌｅｎｇｔｈ ｐａｒｔ）が追加され得る。長さパートは、ＲｏＨＣパケットの長さを表示するパートであり得る。
ＣＩ（Ｃｏｍｍｏｎ Ｃｏｎｔｅｘｔ ＩＤ Ｉｎｄｉｃａｔｏｒ）フィールドは、一つのリンクレイヤパケットのペイロードを構成するＲｏＨＣパケットのＣＩＤ（Ｃｏｎｔｅｘｔ ＩＤ）が全て同一である場合、１に設定され、そうでない場合には０に設定されてもよい。ＣＩ値が１である場合、共通したＣＩＤに対するオーバーヘッド処理方法を適用することができる。ＣＩフィールドは１ビットであってもよい。
カウント（ｃｏｕｎｔ）フィールドは、一つのリンクレイヤパケットのペイロードにいくつのＲｏＨＣパケットが含まれているかを示すことができる。すなわち、連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）の場合において、連鎖しているＲｏＨＣパケットの個数をカウントフィールドが示すことができる。カウントフィールドは３ビットであってもよい。したがって、次の表のように、最大８個のＲｏＨＣパケットが一つのリンクレイヤパケットのペイロードに含まれ得る。カウントフィールドが０００の値を有する場合、ＲｏＨＣパケットが連鎖せず、一つのＲｏＨＣパケットがリンクレイヤパケットのペイロードを構成することを意味し得る。
長さパート（Ｌｅｎｇｔｈ ｐａｒｔ）は、前述したように、ＲｏＨＣパケットの長さを表示するパートであり得る。ＲｏＨＣパケットの場合、ＲｏＨＣパケットヘッダーに長さ情報が除去されて入力される。したがって、ＲｏＨＣパケットヘッダー内の長さフィールドを活用することができない。したがって、受信機が当該ＲｏＨＣパケットの長さを知ることができるように、リンクレイヤパケットのヘッダーは長さパートを含むことができる。
ＩＰパケットは、ＭＴＵが決定されていない場合、最大６５５３５バイトの長さを有する。したがって、ＲｏＨＣパケットに対しても最大長さまで支援できるように２バイトの長さ情報が必要である。また、複数のＲｏＨＣパケットが連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）した場合、カウントフィールドで指定した数だけ、長さフィールド（ｌｅｎｇｔｈ ｆｉｅｌｄ）が追加され得る。この場合、長さパートは、複数個の長さフィールドを含むようになる。ただし、１個のＲｏＨＣパケットがペイロードに含まれる場合には、１つの長さフィールドのみが含まれ得る。長さフィールドの配置は、リンクレイヤパケットのペイロードを構成するＲｏＨＣパケットの順序と同一に配置されてもよい。それぞれの長さフィールドはバイト単位の値を有することができる。
共通ＣＩＤ（Ｃｏｍｍｏｎ ＣＩＤ）フィールドは、共通するＣＩＤを伝送するフィールドであり得る。ＲｏＨＣパケットのヘッダー部分には、圧縮されたヘッダー間の関係を確認するためのＣＩＤ（ｃｏｎｔｅｘｔ ＩＤ）が含まれてもよい。このＣＩＤは、安定したリンク（ｌｉｎｋ）状態では同一の値に維持され得る。これによって、一つのリンクレイヤパケットのペイロードに含まれるＲｏＨＣパケットがいずれも同一のＣＩＤを含むこともできる。この場合、オーバーヘッドを低減するために、ペイロードを構成する連鎖したＲｏＨＣパケットのヘッダー部分からＣＩＤを除去し、リンクレイヤパケットのヘッダーに共通ＣＩＤフィールドにその値を表示して伝送することができる。受信機では、共通ＣＩＤフィールドを用いてＲｏＨＣパケットのＣＩＤを組み換えることができる。共通ＣＩＤフィールドがある場合、前述したＣＩフィールドの値は１にならなければならない。
ＰＣフィールドの値が１Bである場合について説明する。
ＰＣフィールドの値が１Bである場合、リンクレイヤパケットのペイロードがＲｏＨＣパケットの分割された（ｓｅｇｍｅｎｔｅｄ）パケットで構成される場合に該当する。ここで、分割されたパケットとは、長い長さのＲｏＨＣパケットを複数個のセグメントに分け、そのうち１つのセグメントがリンクレイヤパケットのペイロードを構成することを意味し得る。
ＰＣフィールドの値が１Bである場合、ＰＣフィールドの後に１ビットのＬＩ（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｉｎｄｉｃａｔｏｒ）フィールドと３ビットのセグメントＩＤフィールドが後続することができる。また、セグメンテーション（ｓｅｇｍｅｎｔａｔｉｏｎ）に関する情報を追加するために、拡張ヘッダーに、セグメントシーケンスナンバー（Ｓｅｇｍｅｎｔ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）フィールド、セグメント長さＩＤ（Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ ＩＤ）フィールド、最後のセグメント長さ（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｌｅｎｇｔｈ）フィールドなどを追加することができる。
ＬＩ（Ｌａｓｔ Ｓｅｇｍｅｎｔ Ｉｎｄｉｃａｔｏｒ）フィールドは、ＲｏＨＣパケットが分割される場合において活用可能なフィールドである。ＲｏＨＣパケットが複数個のセグメントに分割されてもよい。ＬＩ値が１である場合、現在のリンクレイヤパケットに含まれているセグメントが、一つのＲｏＨＣパケットから分けられたセグメントのうち最後に位置したセグメントであることを意味し得る。ＬＩ値が０である場合、現在のリンクレイヤパケットに含まれているセグメントが、最後のセグメントでないことを意味し得る。ＬＩフィールドは、受信機でセグメントを集めて一つのＲｏＨＣパケットとして再構成する際、全てのセグメントが受信されたかを判断するために用いることができる。ＬＩフィールドは１ビットであってもよい。
セグメントＩＤ（Ｓｅｇ_ＩＤ）フィールドは、ＲｏＨＣパケットが分割される場合において、ＲｏＨＣパケットに付与されるＩＤを示すフィールドであり得る。一つのＲｏＨＣパケットから派生したセグメントは、いずれも同一の値のセグメントＩＤを有することができる。受信機は、それぞれ伝送されたセグメントを一つに合わせる場合、セグメントＩＤを用いて、同一のＲｏＨＣパケットの構成要素であるか否かを判断することができる。セグメントＩＤフィールドは３ビットであってもよい。したがって、同時に８個のＲｏＨＣパケットの分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を支援することができる。
セグメントシーケンスナンバー（Ｓｅｇ_ＳＮ）フィールドは、ＲｏＨＣパケットが分割されたとき、各セグメントの順序を確認するために用いられるフィールドであり得る。すなわち、一つのＲｏＨＣパケットから派生したセグメントをペイロードとして有するリンクレイヤパケットは、同じＳｅｇ_ＩＤを有するが、互いに異なるＳｅｇ_ＳＮを有することができる。Ｓｅｇ_ＳＮは４ビットであってもよい。したがって、一つのＲｏＨＣパケットは最大１６個のセグメントに分割可能である。
セグメント長さＩＤ（Ｓｅｇ_Ｌｅｎ_ＩＤ）フィールドは、各セグメントの長さを表現するのに活用することができる。しかし、セグメント長さＩＤフィールドは、複数個のセグメントのうち、最後のセグメントを除いたセグメントの長さを表現するのに用いることができる。最後のセグメントの長さは、後述する最後のセグメント長さフィールドで示すことができる。リンクレイヤパケットのペイロードが、ＲｏＨＣパケットの最後のセグメントでない場合、すなわち、ＬＩの値が０である場合に、セグメント長さＩＤフィールドが存在し得る。
ヘッダーのオーバーヘッドを低減するために、セグメントが有し得る長さは１６個に制限されてもよい。フィジカルレイヤで処理するＦＥＣのコードレート（ｃｏｄｅ ｒａｔｅ）によってパケットの入力サイズが決定されていてもよい。これに基づいてセグメントの長さを決定して、Ｓｅｇ_Ｌｅｎ_ＩＤとして指定することができる。セグメントの長さに関係なくフィジカルレイヤが動作する場合、次のようにセグメントの長さを決定することができる。
ここで、Ｌｅｎ_Ｕｎｉｔ（Ｌｅｎｇｔｈ Ｕｎｉｔ）は、セグメントの長さを表示する基本単位であり、ｍｉｎ_Ｌｅｎは、セグメント長さの最小値を意味し得る。Ｌｅｎ_Ｕｎｉｔとｍｉｎ_Ｌｅｎは、送信機と受信機において同じ値を有しなければならず、一度決定されると変わらない方が、システムの運用に効率的である。また、Ｌｅｎ_Ｕｎｉｔとｍｉｎ_Ｌｅｎは、システムの初期化過程でフィジカルレイヤのＦＥＣの処理能力を考慮して決定することができる。
次の表は、Ｓｅｇ_Ｌｅｎ_ＩＤの値によって表現されるセグメントの長さを整理したものであって、Ｓｅｇ_Ｌｅｎ_ＩＤに割り当てられた長さは一実施例であり、設計者の意図によって変更されてもよい。この実施例では、Ｌｅｎ_Ｕｎｉｔ値は２５６、ｍｉｎ_Ｌｅｎ値は５１２である。
最後のセグメント長さ（Ｌ_Ｓｅｇ_Ｌｅｎ）フィールドは、リンクレイヤパケットのペイロードに含まれたセグメントが、ＲｏＨＣパケットの最後のセグメントである場合に活用されるフィールドである。すなわち、ＬＩフィールドの値が１である場合に活用されるフィールドである。ＲｏＨＣパケットをＳｅｇ_Ｌｅｎ_ＩＤを用いて前部から同じサイズに分割することができる。しかし、この場合、最後のセグメントはＳｅｇ_Ｌｅｎ_ＩＤが示すサイズに分割されない場合がある。したがって、最後のセグメントの長さは、Ｌ_Ｓｅｇ_Ｌｅｎフィールドによって直接的に表示されてもよい。Ｌ_Ｓｅｇ_Ｌｅｎフィールドは、１〜４０９５バイトを表示できる。これは、実施例によって変更されてもよい。
図３９は、本発明の一実施例に係るＲｏＨＣ伝送のためのリンクレイヤパケットのヘッダーのシンタックスを示した図である。
リンクレイヤパケットのヘッダー（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ Ｈｅａｄｅｒ（））は、まず、Ｐａｃｋｅｔ_ＴｙｐｅフィールドとＰＣ（Ｐａｙｌｏａｄ_Ｃｏｎｆｉｇ）フィールドを有することができる。これについては、前述した通りである。
ＰＣフィールドの値が０である場合、Ｃｏｍｍｏｎ_Ｃｏｎｔｅｘｔ_ＩＤ_ＩｎｄｉｃａｔｏｒフィールドとＣｏｕｎｔフィールドが後続することができる。また、Ｃｏｕｎｔフィールドが示す値に基づいて、複数個のＬｅｎｇｔｈフィールドが位置することができる。また、ＣＩフィールドが１である場合、Ｃｏｍｍｏｎ_ＣＩＤフィールドがさらに位置することができる。
ＰＣフィールドの値が１である場合、ＰＣフィールドの後にＬａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールド、Ｓｅｇｍｅｎｔ_ＩＤフィールド、及びＳｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒフィールドが位置することができる。このとき、Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールドの値によってその後部の構成が変わり得る。Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールドが０である場合、Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒフィールドの後にＳｅｇｍｅｎｔ_Ｌｅｎｇｔｈ_ＩＤフィールドが位置することができる。Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールドが１である場合、Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒフィールドの後にＬａｓｔ_Ｓｅｇｍｅｎｔ_Ｌｅｎｇｔｈフィールドが位置することができる。
図４０は、本発明に係る、リンクレイヤパケットを介したＲｏＨＣパケット伝送方法の実施例＃１を示した図である。
本実施例は、ＲｏＨＣパケットがフィジカルレイヤの処理範囲内にあることから、一つのＲｏＨＣパケットがリンクレイヤパケットのペイロードを構成する場合に該当する。この場合、ＲｏＨＣパケットは、連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）又は分割（ｓｅｇｍｅｎｔａｔｉｏｎ）されなくてもよい。
この場合、一つのＲｏＨＣパケットがそのままリンクレイヤパケットのペイロードになってもよい。パケットタイプの値は０１０Bになり、ＰＣフィールドの値は０B、ＣＩフィールドの値は０Bであり得る。前述したカウントフィールドの場合、一つのＲｏＨＣパケットがそのままペイロードを構成するので（１個）、前述したように０００Bの値を有することができる。次いで、ＲｏＨＣパケットの長さを示す２バイトの長さフィールドが後続することができる。この場合、一つのパケットのみがペイロードを構成するので、長さパートは一つの長さフィールドのみを含むことができる。
この実施例で、合計３バイトのリンクレイヤヘッダーが追加されている。したがって、長さフィールドが示すＲｏＨＣパケットの長さがＬバイトであるとすれば、全リンクレイヤパケットの長さはＬ＋３バイトとなる。
図４１は、本発明に係る、リンクレイヤパケットを介したＲｏＨＣパケット伝送方法の実施例＃２を示した図である。
本実施例は、ＲｏＨＣパケットがフィジカルレイヤの処理範囲内に到達しないことから、複数個のＲｏＨＣパケットが連結されてリンクレイヤパケットのペイロードに含まれる場合に該当する（連鎖）。
この場合、ＰＣフィールド及びＣＩフィールドの値は、一つのＲｏＨＣパケットがペイロードに含まれる場合と同一である。次いでカウントフィールドが後続する。カウントフィールドは、前述したように、いくつのＲｏＨＣパケットがペイロードに含まれているかによって００１B〜１１１Bの値を有することができる。
次いで、各２バイトの長さを有する長さフィールドが、カウントフィールドが示す個数だけ位置することができる。各長さフィールドは、各ＲｏＨＣパケットの長さを示すことができる。この長さフィールド（Ｌｅｎｇｔｈ ｆｉｅｌｄ）を長さパート（Ｌｅｎｇｔｈ ｐａｒｔ）と呼ぶことができる。
ここで、カウントフィールドが示す値がｎ個であるとすれば、リンクレイヤパケットのペイロードには、それぞれＬ1，Ｌ2，…，Ｌnの長さを有するＲｏＨＣパケットＲ1，Ｒ2，…，Ｒnが連鎖していてもよい。
総拡張ヘッダーは２ｎバイトの長さを有することができる。リンクレイヤパケットの全長ＬTは、次の式のように表現することができる。
図４２は、本発明に係る、リンクレイヤパケットを介したＲｏＨＣパケット伝送方法の実施例＃３を示した図である。
本実施例は、複数個のＲｏＨＣパケットが連結されてリンクレイヤパケットのペイロードを構成する場合（連鎖）において、連鎖したＲｏＨＣパケットが同じＣＩＤ（Ｃｏｎｔｅｘｔ ＩＤ）を有する場合に該当する。
ＲｏＨＣパケットが同じＣＩＤを有する場合、ＣＩＤを一度だけ表記して伝送しても、受信機では、元通りにＲｏＨＣパケット及びそのヘッダーを復元することができる。したがって、ＲｏＨＣパケットで共通するＣＩＤを抽出して一度だけ伝送することが可能であり、この場合、オーバーヘッドを低減することができる。
この場合、前述したＣＩフィールドの値は１になる。これは、同じＣＩＤに対する処理がなされたことを意味し得る。同じＣＩＤを有するＲｏＨＣパケットを、［Ｒ1，Ｒ2，Ｒ3，…，Ｒn］と表示した。共通するＣＩＤは、共通ＣＩＤ（Ｃｏｍｍｏｎ ＣＩＤ）と呼ぶことができる。ＲｏＨＣパケットのヘッダーにおいてＣＩＤを除いたパケットをＲ’kと表示した（ｋは、１，２，．．．，ｎ）。
リンクレイヤパケットのペイロードはＲ’k（ｋは、１，２，．．．，ｎ）を含むことができる。リンクレイヤパケットの拡張ヘッダーの末尾部分には共通ＣＩＤフィールドが追加されてもよい。共通ＣＩＤフィールドは、共通するＣＩＤを伝送するフィールドであり得る。共通ＣＩＤフィールドは、拡張ヘッダーの一部として伝送されてもよく、リンクレイヤパケットのペイロードの一部として伝送されてもよい。システムの運用に応じて、共通ＣＩＤフィールドの位置を確認できる部分に適宜再配置することが可能である。
共通ＣＩＤフィールドのサイズは、ＲｏＨＣパケットの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）によって変わり得る。
ＲｏＨＣパケットの構成がスモールＣＩＤ構成（Ｓｍａｌｌ ＣＩＤ ｃｏｎｆｉｇｕｒａｔｉｏｎ）である場合、ＲｏＨＣパケットのＣＩＤのサイズは４ビットであり得る。ただし、ＲｏＨＣパケットからＣＩＤを抽出して再配置する場合には、ａｄｄ−ＣＩＤ ｏｃｔｅｔ全体が処理され得る。すなわち、共通ＣＩＤフィールドが１バイトの長さを有することができる。または、ＲｏＨＣパケットから１バイトのａｄｄ−ＣＩＤ ｏｃｔｅｔを抽出した後、４ビットのＣＩＤのみを共通ＣＩＤフィールドに割り当て、残りの４ビットは、将来の活用のために残してもよい。
ＲｏＨＣパケットの構成がラージＣＩＤ構成（Ｌａｒｇｅ ＣＩＤ ｃｏｎｆｉｇｕｒａｔｉｏｎ）である場合、ＲｏＨＣパケットのＣＩＤのサイズは、１バイト又は２バイトの長さを有することができる。ＣＩＤのサイズは、ＲｏＨＣ初期化過程で決定される事項である。ＣＩＤのサイズによって、共通ＣＩＤフィールドは１バイト又は２バイトの長さを有することができる。
本実施例において、リンクレイヤパケットのペイロードの長さは、次のように計算することができる。同じＣＩＤを有するｎ個のＲｏＨＣパケットＲ1，Ｒ2，…，Ｒnの長さをそれぞれＬ1，Ｌ2，…，Ｌnとすることができる。リンクレイヤパケットのヘッダーの長さをＬH、共通ＣＩＤフィールドの長さをＬCID、リンクレイヤパケットの全長をＬTとすれば、ＬHは、次の通りである。
また、ＬTは、次のように計算することができる。
前述したように、ＬCIDは、ＲｏＨＣのＣＩＤ構成によって決定され得る。すなわち、ＬCIDは、スモールＣＩＤ構成の場合に１バイト、ラージＣＩＤ構成の場合に１バイト又は２バイトとすることができる。
図４３は、本発明に係る、リンクレイヤパケットを介したＲｏＨＣパケット伝送方法の実施例＃４を示した図である。
本実施例は、入力されたＲｏＨＣパケットがフィジカルレイヤの処理範囲を超える場合（ｓｅｇｍｅｎｔａｔｉｏｎ）において、分離されたセグメントがそれぞれリンクレイヤパケットのペイロードに圧縮（ｅｎｃａｐｓｕｌａｔｉｏｎ）される場合に該当する。
リンクレイヤパケットのペイロードが分割されたＲｏＨＣパケットで構成されたことを知らせるために、ＰＣフィールドの値は１Bとなる。ＬＩフィールドは、ＲｏＨＣパケットの最後の部分に該当するセグメントをペイロードとして有する場合にのみ１Bとなり、残りの全てのセグメントに対しては０Bとなる。ＬＩフィールドの値は、リンクレイヤパケットの拡張ヘッダーに関する情報を知らせることもできる。すなわち、ＬＩフィールドの値が０Bである場合は１バイト、１Bである場合は２バイトの長さの拡張ヘッダーが追加されてもよい。
同じＲｏＨＣパケットから分割されたことを示すために、Ｓｅｇ_ＩＤ値はいずれも同じ値を有しなければならない。受信機における正常なＲｏＨＣパケット組み換えのためのセグメントの順序情報を示すために、順次増加するＳｅｇ_ＳＮ値がヘッダーに記録されてもよい。
ＲｏＨＣパケットを分割する際、前述したように、セグメントの長さを決定して分割を行うことができる。その長さに合うＳｅｇ_Ｌｅｎ_ＩＤ値がヘッダーに記録されてもよい。最後のセグメントの長さは、前述したように、１２ビットのＬ_Ｓｅｇ_Ｌｅｎフィールドに直接記録されてもよい。
Ｓｅｇ_Ｌｅｎ_ＩＤ、Ｌ_Ｓｅｇ_Ｌｅｎフィールドを用いて表示する長さ情報は、セグメント、すなわち、リンクレイヤパケットのペイロードに関する情報のみを表示する。したがって、全リンクレイヤパケットの長さ情報は、ＬＩフィールドから読み取れるリンクレイヤパケットのヘッダーの長さを加算して計算することができる。
受信側でＲｏＨＣパケットのセグメントを組み換える過程で、組み換えられたＲｏＨＣパケットの無欠性を確認する必要がある。そのために、分割過程でＲｏＨＣパケットの後にＣＲＣが追加されてもよい。一般に、ＣＲＣは、ＲｏＨＣパケットの最後に追加されるので、分割過程の後に最後のセグメントにＣＲＣを含ませることができる。
図４４は、本発明の他の実施例に係る、リンクレイヤにシグナリング情報が伝達される場合のリンクレイヤパケットの構造を示した図である。
この場合、リンクレイヤパケットのヘッダーは、固定ヘッダー（Ｆｉｘｅｄ ｈｅａｄｅｒ）と拡張ヘッダー（Ｅｘｔｅｎｄｅｄ ｈｅａｄｅｒ）を含むことができる。固定ヘッダーは、１バイトの長さを有することができ、拡張ヘッダーは、固定された長さを有したり可変する値（ｖａｒｉａｂｌｅ）を長さとして有することができる。各ヘッダーの長さは、設計者の意図によって変更されてもよい。
固定ヘッダーは、パケットタイプフィールド、ＰＣフィールド及び／又は連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）カウントフィールドを含むことができる。他の実施例によれば、固定ヘッダーは、パケットタイプフィールド、ＰＣフィールド、ＬＩフィールド及び／又はセグメントＩＤフィールドを含むことができる。
拡張ヘッダーは、シグナリングクラスフィールド、情報タイプ（ｉｎｆｏｒｍａｔｉｏｎ ｔｙｐｅ）フィールド及び／又はシグナリングフォーマットフィールドを含むことができる。他の実施例によれば、拡張ヘッダーは、ペイロード長さパートをさらに含むことができる。更に他の実施例によれば、拡張ヘッダーは、セグメントシーケンスナンバーフィールド、セグメント長さＩＤフィールド、シグナリングクラスフィールド、情報タイプフィールド及び／又はシグナリングフォーマットフィールドを含むことができる。更に他の実施例によれば、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又はセグメント長さＩＤフィールドを含むことができる。更に他の実施例によれば、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又は最後のセグメント長さフィールドを含むことができる。
固定ヘッダーのフィールドについて説明する。
パケットタイプフィールドは、前述したように、リンクレイヤに入力されるパケットのタイプを示すことができる。シグナリング情報がリンクレイヤの入力として入る場合、パケットタイプフィールドの値は１１０Ｂであり得る。
ＰＣフィールド、ＬＩフィールド、セグメントＩＤフィールド、セグメントシーケンスナンバーフィールド、セグメント長さＩＤフィールド、最後のセグメント長さフィールドは、前述した通りである。連鎖カウントフィールドは、前述したカウントフィールドと同一である。
拡張ヘッダーのフィールドについて説明する。
ＰＣフィールドが０の値を有する場合、拡張ヘッダーは、シグナリングクラスフィールド、情報タイプフィールド及び／又はシグナリングフォーマットフィールドを含むことができる。また、シグナリングフォーマットフィールドの値によって、拡張ヘッダーはペイロード長さパートをさらに含むことができる。
シグナリングクラスフィールドは、リンクレイヤパケットが含むシグナリング情報がどのようなタイプの情報であるかを示すことができる。シグナリングクラスフィールドが示すシグナリング情報としては、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）情報またはヘッダー圧縮情報などを挙げることができる。シグナリングクラスフィールドが示すシグナリング情報については後述する。
情報タイプフィールドは、シグナリングクラスフィールドが指定するタイプのシグナリング情報に対して、その具体的な事項を示すことができる。情報タイプフィールドが意味するものは、シグナリングクラスフィールドの値によって別に定義されてもよい。
シグナリングフォーマットフィールドは、リンクレイヤパケットが含むシグナリング情報がどのようなフォーマットを有するかを示すことができる。シグナリングフォーマットフィールドが示すフォーマットとしては、セクションテーブル、ディスクリプタまたはＸＭＬなどを挙げることができる。シグナリングフォーマットフィールドが示すフォーマットについては後述する。
ペイロード長さパートは、リンクレイヤパケットのペイロードが含むシグナリング情報の長さを示すことができる。ペイロード長さパートは、連鎖しているそれぞれのシグナリング情報の長さを示す長さフィールドの集合であってもよい。それぞれの長さフィールドは、２バイトのサイズを有することができるが、システムの構成によってサイズは変更されてもよい。ペイロード長さパートの全長は、それぞれの長さフィールドの長さの和で表現することができる。実施例によって、バイトの整列のためのパディングビットが追加されてもよい。この場合、パディングビットの分だけペイロード長さパートの全長が増加し得る。
ペイロード長さパートが存在するか否かは、シグナリングフォーマットフィールドの値によって決定され得る。セクションテーブル及びディスクリプタのように、当該シグナリング情報が当該シグナリング情報の長さ値を有する場合には、別の長さフィールドが省かれてもよい。しかし、別途の長さ値を有しないシグナリング情報の場合は、別の長さフィールドを必要とする。別の長さ値を有しないシグナリング情報の場合、ペイロード長さパートが存在し得る。この場合、ペイロード長さパートは、カウントフィールドの数だけ長さフィールドを含むことができる。
ＰＣフィールドが１であり、ＬＩフィールドが１の値を有する場合、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又は最後のセグメント長さフィールドを含むことができる。ＰＣフィールドが１であり、ＬＩフィールドが０の値を有する場合、拡張ヘッダーは、セグメントシーケンスナンバーフィールド及び／又はセグメント長さＩＤフィールドを含むことができる。
セグメントシーケンスナンバーフィールド、最後のセグメント長さフィールド、セグメント長さＩＤフィールドは、前述した通りである。
ＰＣフィールドが１であり、ＬＩフィールドが０の値を有する場合において、当該リンクレイヤパケットのペイロードが１番目のセグメントであれば、その拡張ヘッダーは付加情報をさらに含むことができる。この付加情報は、シグナリングクラスフィールド、情報タイプフィールド、及び／又はシグナリングフォーマットフィールドを含むことができる。シグナリングクラスフィールド、情報タイプフィールド、シグナリングフォーマットフィールドは、前述した通りである。
図４５は、前述した本発明の他の実施例に係る、リンクレイヤにシグナリング情報が伝達される場合のリンクレイヤパケットの構造において、そのシンタックスを示した図である。
リンクレイヤパケットのヘッダー（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ Ｈｅａｄｅｒ（））は、まず、Ｐａｃｋｅｔ_ＴｙｐｅフィールドとＰＣ（Ｐａｙｌｏａｄ_Ｃｏｎｆｉｇ）フィールドを有することができる。これについては、前述した通りである。
ＰＣフィールドの値が０である場合、ＰＣフィールドの後にＣｏｕｎｔフィールド、Ｓｉｇｎａｌｉｎｇ_Ｃｌａｓｓフィールド、Ｉｎｆｏｒｍａｔｉｏｎ_Ｔｙｐｅフィールド、Ｓｉｇｎａｌｉｎｇ_Ｆｏｒｍａｔフィールドが後続することができる。Ｓｉｇｎａｌｉｎｇ_Ｆｏｒｍａｔフィールドの値が１ｘである場合（１０又は１１）、Ｃｏｕｎｔフィールドが示す値に基づいて、複数個のＬｅｎｇｔｈフィールドが位置することができる。
ＰＣフィールドの値が１である場合、ＰＣフィールドの後にＬａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールド、Ｓｅｇｍｅｎｔ_ＩＤフィールド、及びＳｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒフィールドが位置することができる。このとき、Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールドの値によってその後部の構成が変わり得る。
Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールドが０である場合、Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒフィールドの後にＳｅｇｍｅｎｔ_Ｌｅｎｇｔｈ_ＩＤフィールドが位置することができる。このとき、Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒフィールドの値が００００である場合、その後にＳｉｇｎａｌｉｎｇ_Ｃｌａｓｓフィールド、Ｉｎｆｏｒｍａｔｉｏｎ_Ｔｙｐｅフィールド、Ｓｉｇｎａｌｉｎｇ_Ｆｏｒｍａｔフィールドが位置することができる。
Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒフィールドが１である場合、Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒフィールドの後にＬａｓｔ_Ｓｅｇｍｅｎｔ_Ｌｅｎｇｔｈフィールドが位置することができる。
図４６は、本発明の一実施例に係るフレームドパケット（ｆｒａｍｅｄ ｐａｃｋｅｔ）伝送のためのリンクレイヤパケットの構造を示した図である。
ＩＰパケット又はＭＰＥＧ−２ ＴＳパケット以外にも、一般的なネットワークで使用されているパケットをリンクレイヤパケットを介して伝送することができる。この場合、リンクレイヤパケットのヘッダーのパケットタイプエレメントは「１１１Ｂ」の値を有し、リンクレイヤパケットのペイロードにフレームドパケットが含まれていることを示すことができる。
図４７は、前述した本発明の一実施例に係るフレームドパケット伝送のためのリンクレイヤパケットの構造において、そのシンタックスを示した図である。
リンクレイヤパケットのヘッダー（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ Ｈｅａｄｅｒ（））は、まず、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドを有することができる。これについては、前述した通りである。以降、５ビットを将来の使用のために残すことができる（ｒｅｓｅｒｖｅｄ）。以降にはｆｒａｍｅｄ_ｐａｃｋｅｔ（）と表記された、フレームドパケットが位置することができる。
図４８は、本発明の一実施例に係るフレームドパケットのシンタックス（ｓｙｎｔａｘ）を示した図である。
フレームドパケットのシンタックスは、ｅｔｈｅｒｎｅｔ_ｔｙｐｅ、ｌｅｎｇｔｈ、及び／又はｐａｃｋｅｔ（）フィールドを含むことができる。１６ビットであるｅｔｈｅｒｎｅｔ_ｔｙｐｅフィールドは、ＩＡＮＡレジストリによって、ｐａｃｋｅｔ（）フィールド内のパケットのタイプを識別することができる。ここで、レジスターされた値のみを用いることができる。１６ビットであるｌｅｎｇｔｈフィールドは、ｐａｃｋｅｔ（）構造の全長をバイト単位で設定することができる。可変長を有するｐａｃｋｅｔ（）フィールドはネットワークパケットを含むことができる。
図４９は、本発明の一実施例に係るＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）のシンタックス（ｓｙｎｔａｘ）を示した図である。
ＦＩＣに含まれる情報は、ＦＩＴ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）の形態で伝送されてもよい。
ＦＩＴに含まれる情報は、ＸＭＬの形態及び／又はセクションテーブル（ｓｅｃｔｉｏｎ ｔａｂｌｅ）の形態で伝送されてもよい。
ＦＩＣは、ＦＩＴ_ｄａｔａ_ｖｅｒｓｉｏｎ情報、ｎｕｍ_ｂｒｏａｄｃａｓｔ情報、ｂｒｏａｄｃａｓｔ_ｉｄ情報、ｄｅｌｉｖｅｒｙ_ｓｙｓｔｅｍ_ｉｄ情報、ｂａｓｅ_ＤＰ_ｉｄ情報、ｂａｓｅ_ＤＰ_ｖｅｒｓｉｏｎ情報、ｎｕｍ_ｓｅｒｖｉｃｅ情報、ｓｅｒｖｉｃｅ_ｉｄ情報、ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙ情報、ｓｅｒｖｉｃｅ_ｈｉｄｄｅｎ_ｆｌａｇ情報、ＳＰ_ｉｎｄｉｃａｔｏｒ情報、ｎｕｍ_ｃｏｍｐｏｎｅｎｔ情報、ｃｏｍｐｏｎｅｎｔ_ｉｄ情報、ＤＰ_ｉｄ情報、及び／又はＲｏＨＣ_ｉｎｉｔ_ｄｅｓｃｒｉｐｔｏｒを含むことができる。
ＦＩＴ_ｄａｔａ_ｖｅｒｓｉｏｎ情報は、ｆａｓｔ ｉｎｆｏｒｍａｔｉｏｎテーブルが含むシンタックス（ｓｙｎｔａｘ）及びセマンティクス（ｓｅｍａｎｔｉｃｓ）に対するバージョン情報を示すことができる。これを用いて、受信機は、当該Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎテーブルに含まれたシグナリングを処理するか否かなどを決定することができる。受信機は、この情報を用いて、予め格納していたＦＩＣの情報をアップデートするか否かを決定することができる。
ｎｕｍ_ｂｒｏａｄｃａｓｔ情報は、当該周波数又は伝送されるトランスポートフレーム（ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）を介して放送サービス及び／又はコンテンツを伝送する放送局の数を示すことができる。
ｂｒｏａｄｃａｓｔ_ｉｄ情報は、当該周波数又は伝送されるトランスポートフレームを介して放送サービス及び／又はコンテンツを伝送する放送局固有の識別子を示すことができる。ＭＰＥＧ−２ ＴＳベースのデータを伝送する放送局の場合、ｂｒｏａｄｃａｓｔ_ｉｄは、ＭＰＥＧ−２ ＴＳのｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄと同じ値を有することができる。
ｄｅｌｉｖｅｒｙ_ｓｙｓｔｅｍ_ｉｄ情報は、伝送される放送ネットワーク上で同じ伝送パラメータを適用して処理する放送送信システムに対する識別子を示すことができる。
ｂａｓｅ_ＤＰ_ｉｄ情報は、放送信号内でｂａｓｅ ＤＰを識別する情報である。ｂａｓｅ ＤＰは、ｂｒｏａｄｃａｓｔ_ｉｄに該当する放送局のＰＳＩ／ＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ／Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ）及び／又はオーバーヘッドリダクション（ｏｖｅｒｈｅａｄ ｒｅｄｕｃｔｉｏｎ）などを含むサービスシグナリングを伝達するＤＰを指称してもよい。または、当該放送局内の放送サービスを構成するコンポーネント（ｃｏｍｐｏｎｅｎｔ）をデコーディングできる代表ＤＰを指称してもよい。
ｂａｓｅ_ＤＰ_ｖｅｒｓｉｏｎ情報は、ｂａｓｅ ＤＰを介して伝送されるデータに対するバージョン情報を示すことができる。例えば、ｂａｓｅ ＤＰを介してＰＳＩ／ＳＩなどのサービスシグナリングが伝達される場合、サービスシグナリングの変化が発生する場合にｂａｓｅ_ＤＰ_ｖｅｒｓｉｏｎ情報の値が１ずつ増加し得る。
ｎｕｍ_ｓｅｒｖｉｃｅ情報は、当該周波数又はトランスポートフレーム内でｂｒｏａｄｃａｓｔ_ｉｄに該当する放送局が伝送する放送サービスの個数を示すことができる。
ｓｅｒｖｉｃｅ_ｉｄ情報は、放送サービスを区別できる識別子として用いることができる。
ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙ情報は、放送サービスのカテゴリを示すことができる。当該フィールドが有する値によって、次のような意味を有することができる。ｓｅｒｖｉｃｅ_ｃａｔｅｇｏｒｙ情報の値が、０ｘ０１の場合にＢａｓｉｃ ＴＶ、０ｘ０２の場合にＢａｓｉｃ Ｒａｄｉｏ、０ｘ０３の場合にＲＩ ｓｅｒｖｉｃｅ、０ｘ０８の場合にＳｅｒｖｉｃｅ Ｇｕｉｄｅ、０ｘ０９の場合にＥｍｅｒｇｅｎｃｙ Ａｌｅｒｔｉｎｇであることを示すことができる。
ｓｅｒｖｉｃｅ_ｈｉｄｄｅｎ_ｆｌａｇ情報は、当該放送サービスがｈｉｄｄｅｎであるか否かを示すことができる。サービスがｈｉｄｄｅｎである場合、テストサービス又は独自で用いられるサービスであって、放送受信機では、これを無視するか、またはサービスリストで隠すなどの処理を行うことができる。
ＳＰ_ｉｎｄｉｃａｔｏｒ情報は、サービス保護（Ｓｅｒｖｉｃｅ ｐｒｏｔｅｃｔｉｏｎ）が当該放送サービス内の１つ以上のコンポーネントに適用されるか否かを示すことができる。
ｎｕｍ_ｃｏｍｐｏｎｅｎｔ情報は、当該放送サービスを構成するコンポーネントの個数を示すことができる。
ｃｏｍｐｏｎｅｎｔ_ｉｄ情報は、放送サービス内の当該コンポーネントを区別する識別子として用いることができる。
ＤＰ_ｉｄ情報は、当該コンポーネントが伝送されるＤＰを示す識別子として用いることができる。
ＲｏＨＣ_ｉｎｉｔ_ｄｅｓｃｒｉｐｔｏｒは、オーバーヘッドリダクション及び／又はヘッダーリカバリー（ｈｅａｄｅｒ ｒｅｃｏｖｅｒｙ）と関連する情報を含むことができる。ＲｏＨＣ_ｉｎｉｔ_ｄｅｓｃｒｉｐｔｏｒは、送信端で用いたヘッダー圧縮方式を識別する情報を含むことができる。
図５０は、本発明の一実施例に係る、非常警報を行う放送システムを示した図である。
非常警報を発令する機関（Ａｌｅｒｔ Ａｕｔｈｏｒｉｔｉｅｓ／Ｏｒｉｇｉｎａｔｏｒｓ）からの非常警報関連情報を、放送局（送信機）が受信すると、放送局は、非常警報と関連する情報を、放送システムに合う形態の非常警報シグナリングに変換するか、または非常警報と関連する情報を含む非常警報シグナリングを生成する。この場合、非常警報シグナリングは、ＣＡＰ（Ｃｏｍｍｏｎ Ａｌｅｒｔｉｎｇ Ｐｒｏｔｏｃｏｌ）メッセージを含むことができる。放送局は、受信機に非常警報シグナリングを伝達することができる。この場合、放送局は、一般の放送データが伝送される経路で非常警報シグナリングを伝達することができる。または、放送局は、一般の放送データが伝送される経路とは異なる経路で非常警報シグナリングを伝達してもよい。非常警報シグナリングは、後述したＥＡＴのような形態で生成されてもよい。
受信機は、非常警報シグナリングを受信する。非常警報シグナリングデコーダは、非常警報シグナリングをパーシングし、ＣＡＰメッセージを獲得することができる。受信機は、ＣＡＰメッセージの情報を用いて、非常警報メッセージを生成し、これを視聴者に表示する。
図５１は、本発明の一実施例に係る、ＥＡＴ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｔａｂｌｅ）のシンタックス（ｓｙｎｔａｘ）を示した図である。
ＥＡＣを介して非常警報と関連する情報が伝送されてもよい。ＥＡＣは、前述した特定のチャンネル（ｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌ）に該当し得る。
本発明の一実施例に係るＥＡＴは、ＥＡＴ_ｐｒｏｔｏｃｏｌ_ｖｅｒｓｉｏｎ情報、ａｕｔｏｍａｔｉｃ_ｔｕｎｉｎｇ_ｆｌａｇ情報、ｎｕｍ_ＥＡＳ_ｍｅｓｓａｇｅｓ情報、ＥＡＳ_ｍｅｓｓａｇｅ_ｉｄ情報、ＥＡＳ_ＩＰ_ｖｅｒｓｉｏｎ_ｆｌａｇ情報、ＥＡＳ_ｍｅｓｓａｇｅ_ｔｒａｎｓｆｅｒ_ｔｙｐｅ情報、ＥＡＳ_ｍｅｓｓａｇｅ_ｅｎｃｏｄｉｎｇ_ｔｙｐｅ情報、ＥＡＳ_ＮＲＴ_ｆｌａｇ情報、ＥＡＳ_ｍｅｓｓａｇｅ_ｌｅｎｇｔｈ情報、ＥＡＳ_ｍｅｓｓａｇｅ_ｂｙｔｅ情報、ＩＰ_ａｄｄｒｅｓｓ情報、ＵＤＰ_ｐｏｒｔ_ｎｕｍ情報、ＤＰ_ｉｄ情報、ａｕｔｏｍａｔｉｃ_ｔｕｎｉｎｇ_ｃｈａｎｎｅｌ_ｎｕｍｂｅｒ情報、ａｕｔｏｍａｔｉｃ_ｔｕｎｉｎｇ_ＤＰ_ｉｄ情報、ａｕｔｏｍａｔｉｃ_ｔｕｎｉｎｇ_ｓｅｒｖｉｃｅ_ｉｄ情報、及び／又はＥＡＳ_ＮＲＴ_ｓｅｒｖｉｃｅ_ｉｄ情報を含む。
ＥＡＴ_ｐｒｏｔｏｃｏｌ_ｖｅｒｓｉｏｎ情報は、受信されたＥＡＴが有するプロトコルのバージョン（ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ）を示す。
ａｕｔｏｍａｔｉｃ_ｔｕｎｉｎｇ_ｆｌａｇ情報は、受信機が自動でチャンネル切り替えを行うか否かを知らせる。
ｎｕｍ_ＥＡＳ_ｍｅｓｓａｇｅｓ情報は、ＥＡＴに含まれているメッセージに対する個数を知らせる。
ＥＡＳ_ｍｅｓｓａｇｅ_ｉｄ情報は、それぞれのＥＡＳメッセージを識別する情報である。
ＥＡＳ_ＩＰ_ｖｅｒｓｉｏｎ_ｆｌａｇ情報は、ＥＡＳ_ＩＰ_ｖｅｒｓｉｏｎ_ｆｌａｇ情報の値が０の場合、ＩＰｖ４であることを示し、ＥＡＳ_ＩＰ_ｖｅｒｓｉｏｎ_ｆｌａｇ情報の値が１の場合、ＩＰｖ６であることを示す。
ＥＡＳ_ｍｅｓｓａｇｅ_ｔｒａｎｓｆｅｒ_ｔｙｐｅ情報は、ＥＡＳメッセージが伝達される形態を示す。ＥＡＳ_ｍｅｓｓａｇｅ_ｔｒａｎｓｆｅｒ_ｔｙｐｅ情報の値が０００の場合、ｎｏｔ ｓｐｅｃｉｆｉｅｄ状態であることを示し、ＥＡＳ_ｍｅｓｓａｇｅ_ｔｒａｎｓｆｅｒ_ｔｙｐｅ情報の値が００１の場合、Ｎｏ Ａｌｅｒｔ ｍｅｓｓａｇｅ（ｏｎｌｙ ＡＶ ｃｏｎｔｅｎｔ）であることを示し、ＥＡＳ_ｍｅｓｓａｇｅ_ｔｒａｎｓｆｅｒ_ｔｙｐｅ情報の値が０１０の場合、当該ＥＡＴ内にＥＡＳメッセージが含まれることを示す。そのために、長さフィールドと当該ＥＡＳメッセージに対するフィールドが追加される。ＥＡＳ_ｍｅｓｓａｇｅ_ｔｒａｎｓｆｅｒ_ｔｙｐｅ情報の値が０１１の場合、データパイプを介してＥＡＳメッセージが伝送されることを知らせる。ＥＡＳは、データパイプ内でＩＰデータグラム（ｄａｔａｇｒａｍ）の形態で伝送されてもよい。そのために、ＩＰアドレス、ＵＤＰポート情報、及び伝送されるフィジカルレイヤのＤＰ情報が追加されてもよい。
ＥＡＳ_ｍｅｓｓａｇｅ_ｅｎｃｏｄｉｎｇ_ｔｙｐｅ情報は、非常警報メッセージのエンコーディングタイプ（ｅｎｃｏｄｉｎｇ ｔｙｐｅ）に対する情報を知らせる。例えば、ＥＡＳ_ｍｅｓｓａｇｅ_ｅｎｃｏｄｉｎｇ_ｔｙｐｅ情報の値が０００の場合、ｎｏｔ ｓｐｅｃｉｆｉｅｄであることを示し、ＥＡＳ_ｍｅｓｓａｇｅ_ｅｎｃｏｄｉｎｇ_ｔｙｐｅ情報の値が００１の場合、Ｎｏ Ｅｎｃｏｄｉｎｇであることを示し、ＥＡＳ_ｍｅｓｓａｇｅ_ｅｎｃｏｄｉｎｇ_ｔｙｐｅ情報の値が０１０の場合、ＤＥＦＬＡＴＥ ａｌｇｏｒｉｔｈｍ（ＲＦＣ１９５１）であることを示し、ＥＡＳ_ｍｅｓｓａｇｅ_ｅｎｃｏｄｉｎｇ_ｔｙｐｅ情報の値のうち００１〜１１１は、他のエンコーディングタイプのために予約されてもよい。
ＥＡＳ_ＮＲＴ_ｆｌａｇ情報は、受信される緊急メッセージと関連する、ＮＲＴコンテンツ（ｃｏｎｔｅｎｔｓ）及び／又はＮＲＴデータが存在するかどうかを示す。ＥＡＳ_ＮＲＴ_ｆｌａｇ情報の値が０の場合、ＮＲＴコンテンツ及び／又はＮＲＴデータが、受信した緊急メッセージ（Ｅｍｅｒｇｅｎｃｙ ｍｅｓｓａｇｅ）と関連して存在しないことを示し、ＥＡＳ_ＮＲＴ_ｆｌａｇ情報の値が１の場合、ＮＲＴコンテンツ及び／又はＮＲＴデータが、受信した緊急メッセージと関連して存在することを示す。
ＥＡＳ_ｍｅｓｓａｇｅ_ｌｅｎｇｔｈ情報は、ＥＡＳメッセージの長さを示す。
ＥＡＳ_ｍｅｓｓａｇｅ_ｂｙｔｅ情報は、ＥＡＳメッセージのコンテンツ（ｃｏｎｔｅｎｔ）を含む。
ＩＰ_ａｄｄｒｅｓｓ情報は、ＥＡＳメッセージを伝送するＩＰパケットのＩＰアドレスを示す。
ＵＤＰ_ｐｏｒｔ_ｎｕｍ情報は、ＥＡＳメッセージを伝送するＵＤＰポートナンバーを示す。
ＤＰ_ｉｄ情報は、ＥＡＳメッセージを伝送するデータパイプを識別する。
ａｕｔｏｍａｔｉｃ_ｔｕｎｉｎｇ_ｃｈａｎｎｅｌ_ｎｕｍｂｅｒ情報は、切り替えなければならないチャンネルの番号に対する情報を含む。
ａｕｔｏｍａｔｉｃ_ｔｕｎｉｎｇ_ＤＰ_ｉｄ情報は、当該コンテンツを伝送するデータパイプを識別する情報である。
ａｕｔｏｍａｔｉｃ_ｔｕｎｉｎｇ_ｓｅｒｖｉｃｅ_ｉｄ情報は、当該コンテンツが属するサービスを識別する情報である。
ＥＡＳ_ＮＲＴ_ｓｅｒｖｉｃｅ_ｉｄ情報は、受信される非常警報メッセージと関連するＮＲＴコンテンツ及びデータが伝送される場合、すなわち、ＥＡＳ_ＮＲＴ_ｆｌａｇがｅｎａｂｌｅ状態である場合に、該当するＮＲＴサービスを識別する情報である。
図５２は、本発明の一実施例に係る、リンクレイヤパケットのペイロードに含まれる、ヘッダー圧縮と関連する情報を識別する方法を示した図である。
前述したように、リンクレイヤで上位レイヤから伝達されるパケットに対してヘッダー圧縮が行われる場合、受信機でヘッダーを復元できるように、必要な情報がシグナリングの形態で生成されて受信機に伝送されなければならない。このような情報をヘッダー圧縮シグナリング情報と命名することができる。
ヘッダー圧縮シグナリング情報は、リンクレイヤのパケットのペイロードに含まれてもよい。このとき、送信機は、リンクレイヤのパケットのペイロードに含まれるヘッダー圧縮シグナリング情報の種類を識別する識別情報を、リンクレイヤパケットのヘッダーまたはフィジカルレイヤの伝送パラメータ（物理層のシグナリング情報）に含ませて、受信機に伝送することができる。
一実施例によれば、識別情報の値が「０００」である場合、初期化情報がリンクレイヤパケットのペイロードに含まれることを示すことができる。識別情報の値が「００１」である場合、構成パラメータ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐａｒａｍｅｔｅｒ）がリンクレイヤパケットのペイロードに含まれることを示すことができる。識別情報の値が「０１０」である場合、スタティックチェーン（ｓｔａｔｉｃ ｃｈａｉｎ）情報がリンクレイヤパケットのペイロードに含まれることを示すことができる。識別情報の値が「０１１」である場合、ダイナミックチェーン（ｄｙｎａｍｉｃ ｃｈａｉｎ）情報がリンクレイヤパケットのペイロードに含まれることを示すことができる。
ここで、ヘッダー圧縮シグナリング情報はコンテキスト情報と呼ぶことができる。実施例によって、スタティック又はダイナミックチェーン情報をコンテキスト情報と呼んでもよく、両方ともコンテキスト情報と呼んでもよい。
図５３は、本発明の一実施例に係る、初期化情報を示した図である。
リンクレイヤパケットのペイロードに含まれる初期化情報は、ｎｕｍ_ＲｏＨＣ_ｃｈａｎｎｅｌ情報、ｍａｘ_ｃｉｄ情報、ｌａｒｇｅ_ｃｉｄｓ情報、ｎｕｍ_ｐｒｏｆｉｌｅｓ情報、ｐｒｏｆｉｌｅ（）エレメント、ｎｕｍ_ＩＰ_ｓｔｒｅａｍ情報及び／又はＩＰ_ａｄｄｒｅｓｓ（）エレメントを含むことができる。
ｎｕｍ_ＲｏＨＣ_ｃｈａｎｎｅｌ情報は、ＲｏＨＣチャンネルの数を示す。
ｍａｘ_ｃｉｄ情報は、ＣＩＤの最大値をデコンプレッサー（ｄｅｃｏｍｐｒｅｓｓｏｒ）に知らせるために用いられる。
ｌａｒｇｅ_ｃｉｄ情報は、ブール（Ｂｏｏｌｅａｎ）値を有し、ＣＩＤの構成において、ｓｈｏｒｔ ＣＩＤ（０〜１５）を用いるか、またはｅｍｂｅｄｄｅｄ ＣＩＤ（０〜１６３８３）を用いるかを知らせる。これによって、ＣＩＤを表現するバイトのサイズも共に決定される。
ｎｕｍ_ｐｒｏｆｉｌｅｓ情報は、用いられたＲｏＨＣのプロファイルの数を示す。
ｐｒｏｆｉｌｅ（）エレメントは、ＲｏＨＣでのヘッダーが圧縮されるプロトコルに関する情報を含む。ＲｏＨＣでは、ストリームに対する圧縮及び復旧を可能にするためには、コンプレッサー（ｃｏｍｐｒｅｓｓｏｒ）とデコンプレッサー（ｄｅｃｏｍｐｒｅｓｓｏｒ）が同じプロファイルを有しなければならない。
ｎｕｍ_ＩＰ_ｓｔｒｅａｍ情報は、ＩＰストリームの数を示す。
ＩＰ_ａｄｄｒｅｓｓ（）エレメントは、ヘッダー圧縮が行われたＩＰパケットのＩＰアドレスを含む。
図５４は、本発明の一実施例に係る、構成パラメータを示した図である。
リンクレイヤパケットのペイロードに含まれる構成パラメータは、ＲｏＨＣ_ｃｈａｎｎｅｌ_ｉｄ情報、ｎｕｍ_ｃｏｎｔｅｘｔ情報、ｃｏｎｔｅｘｔ_ｉｄ情報、ｃｏｎｔｅｘｔ_ｐｒｏｆｉｌｅ情報、ｐａｃｋｅｔ_ｃｏｎｆｉｇｕｒａｔｉｏｎ_ｍｏｄｅ情報、及び／又はｃｏｎｔｅｘｔ_ｔｒａｎｓｍｉｓｓｉｏｎ_ｍｏｄｅ情報を含むことができる。
ＲｏＨＣ_ｃｈａｎｎｅｌ_ｉｄ情報は、ＲｏＨＣチャンネルを識別する情報である。
ｎｕｍ_ｃｏｎｔｅｘｔ情報は、ＲｏＨＣのコンテキスト（ｃｏｎｔｅｘｔ）の数を示す。
ｃｏｎｔｅｘｔ_ｉｄ情報は、ＲｏＨＣのコンテキストを識別する情報である。後続するＲｏＨＣ関連フィールドがどのコンテキストに該当するかを表示することができる。ｃｏｎｔｅｘｔ_ｉｄ情報はＣＩＤ（ｃｏｎｔｅｘｔ ｉｄｅｎｔｉｆｉｅｒ）に該当し得る。
ｃｏｎｔｅｘｔ_ｐｒｏｆｉｌｅ情報は、ＲｏＨＣでのヘッダーが圧縮されるプロトコルに関する情報を含む。ＲｏＨＣでは、ストリームに対する圧縮及び復旧を可能にするためには、コンプレッサーとデコンプレッサーが同じプロファイルを有しなければならない。
ｐａｃｋｅｔ_ｃｏｎｆｉｇｕｒａｔｉｏｎ_ｍｏｄｅ情報は、パケットの構成モードを識別する情報である。パケットの構成モードは、前述した通りである。
ｃｏｎｔｅｘｔ_ｔｒａｎｓｍｉｓｓｉｏｎ_ｍｏｄｅ情報は、コンテキストの伝送モードを識別する情報である。コンテキストの伝送モードは、前述した通りである。コンテキストは、一般の放送データが伝送される経路で伝送されてもよく、シグナリング情報の伝送のために割り当てられた経路を介して伝送されてもよい。
図５５は、本発明の一実施例に係る、スタティックチェーン情報を示した図である。
リンクレイヤパケットのペイロードに含まれるスタティックチェーン情報は、ｃｏｎｔｅｘｔ_ｉｄ情報、ｃｏｎｔｅｘｔ_ｐｒｏｆｉｌｅ情報、ｓｔａｔｉｃ_ｃｈａｉｎ_ｌｅｎｇｔｈ情報、ｓｔａｔｉｃ_ｃｈａｉｎ（）エレメント、ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｉｎｃｌ情報、ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｌｅｎｇｔｈ情報及び／又はｄｙｎａｍｉｃ_ｃｈａｉｎ（）エレメントを含むことができる。
ｃｏｎｔｅｘｔ_ｉｄ情報は、ＲｏＨＣのコンテキストを識別する情報である。後続するＲｏＨＣ関連フィールドがどのコンテキストに該当するかを表示することができる。ｃｏｎｔｅｘｔ_ｉｄ情報はＣＩＤ（ｃｏｎｔｅｘｔ ｉｄｅｎｔｉｆｉｅｒ）に該当し得る。
ｃｏｎｔｅｘｔ_ｐｒｏｆｉｌｅ情報は、ＲｏＨＣでのヘッダーが圧縮されるプロトコルに関する情報を含む。ＲｏＨＣでは、ストリームに対する圧縮及び復旧を可能にするためには、コンプレッサーとデコンプレッサーが同じプロファイルを有しなければならない。
ｓｔａｔｉｃ_ｃｈａｉｎ_ｌｅｎｇｔｈ情報は、ｓｔａｔｉｃ_ｃｈａｉｎ（）エレメントの長さを示す。
ｓｔａｔｉｃ_ｃｈａｉｎ（）エレメントは、ＲｏＨＣヘッダー圧縮が行われる過程で、上位レイヤパケットから抽出したスタティックチェーンに属する情報を含む。
ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｉｎｃｌ情報は、ダイナミックチェーン情報が含まれているか否かを識別する情報である。
ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｌｅｎｇｔｈ情報は、ｄｙｎａｍｉｃ_ｃｈａｉｎ（）エレメントの長さを示す。
ｄｙｎａｍｉｃ_ｃｈａｉｎ（）エレメントは、ＲｏＨＣヘッダー圧縮が行われる過程で、上位レイヤパケットから抽出したダイナミックチェーンに属する情報を含む。
図５６は、本発明の一実施例に係る、ダイナミックチェーン情報を示した図である。
リンクレイヤパケットのペイロードに含まれるダイナミックチェーン情報は、ｃｏｎｔｅｘｔ_ｉｄ情報、ｃｏｎｔｅｘｔ_ｐｒｏｆｉｌｅ情報、ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｌｅｎｇｔｈ情報及び／又はｄｙｎａｍｉｃ_ｃｈａｉｎ（）エレメントを含むことができる。
ｃｏｎｔｅｘｔ_ｉｄ情報は、ＲｏＨＣのコンテキストを識別する情報である。後続するＲｏＨＣ関連フィールドがどのコンテキストに該当するかを表示することができる。ｃｏｎｔｅｘｔ_ｉｄ情報はＣＩＤ（ｃｏｎｔｅｘｔ ｉｄｅｎｔｉｆｉｅｒ）に該当し得る。
ｃｏｎｔｅｘｔ_ｐｒｏｆｉｌｅ情報は、ＲｏＨＣでのヘッダーが圧縮されるプロトコルに関する情報を含む。ＲｏＨＣでは、ストリームに対する圧縮及び復旧を可能にするためには、コンプレッサーとデコンプレッサーが同じプロファイルを有しなければならない。
ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｌｅｎｇｔｈ情報は、ｄｙｎａｍｉｃ_ｃｈａｉｎ（）エレメントの長さを示す。
ｄｙｎａｍｉｃ_ｃｈａｉｎ（）エレメントは、ＲｏＨＣヘッダー圧縮が行われる過程で、上位レイヤパケットから抽出したダイナミックチェーンに属する情報を含む。
図５７は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダーの構造を示した図である。
第一に、リンクレイヤパケットに一つの完全なインプットパケットが含まれてエンカプセレーションされた場合の実施例（ｔ５７０１０）を説明する。これは、前述したように、シングルパケットエンカプセレーション（ｓｉｎｇｌｅ ｐａｃｋｅｔ ｅｎｃａｐｓｕｌａｔｉｏｎ）と呼ぶことができる。
この場合（ｔ５７０１０）、リンクレイヤパケットのヘッダーは、前述したＰａｃｋｅｔ_Ｔｙｐｅフィールドとこれに後続するＰＣフィールドから開始されてもよい。ここで、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは、前述したように、リンクレイヤパケットに含まれるインプットパケットのタイプを示すことができる。ここで、ＰＣフィールドは、前述したように、リンクレイヤパケットのペイロード構成を示すことができる。ここで、ＰＣフィールドは、その値によって、一つの完全なパケットがペイロードに含まれているか、またはパケットが連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）してペイロードに含まれているか、または分割（ｓｅｇｍｅｎｔａｔｉｏｎ）されてペイロードに含まれているかを示すことができる。一実施例において、ＰＣフィールドの値が０の場合、リンクレイヤパケットのペイロードには単一の完全なインプットパケットが含まれてもよい。ＰＣフィールドの値が１の場合、リンクレイヤパケットのペイロードには分割又は連鎖したインプットパケットが含まれてもよい。
ＰＣフィールドの後にはＨＭフィールドが後続することができる。ＨＭフィールドは、前述したように、リンクレイヤパケットのヘッダーモードを示すことができる。すなわち、ＨＭフィールドは、前述したように、含まれた単一のインプットパケットが短い（ｓｈｏｒｔ）パケットであるか、または長い（ｌｏｎｇ）パケットであるかを示すことができる。これによって、後続するヘッダー構造が変更され得る。
短いインプットパケットの場合、すなわち、ＨＭフィールドが０の値を有する場合、１１ビットの長さフィールドが存在し得る。この長さフィールドは、リンクレイヤペイロードの長さを示すことができる。
長いインプットパケットの場合、すなわち、ＨＭフィールドが１の値を有する場合、１１ビットの長さフィールドの後に５ビットの追加の長さフィールドが位置してもよい。合計２バイトの長さフィールドは、リンクレイヤペイロードの長さを示すことができる。ここで、１１ビットの長さフィールドまでをベースヘッダーとし、それ以降を追加ヘッダーとして区分することができる。２つの長さフィールドに後続して２ビットのリザーブド（ｒｅｓｅｒｖｅｄ）フィールドとＬＦフィールドが位置してもよい。リザーブドフィールドは、将来の使用のためにビットを残した区間である。ＬＦフィールドは、それに後続してラベル（Ｌａｂｅｌ）フィールドが位置するか否かを示すフラグであり得る。ラベルフィールドは、一種のサブストリームのラベルであって、サブストリームＩＤのように、リンクレイヤレベルで特定の上位レイヤパケットストリームをフィルタリングするのに使用することができる。上位レイヤパケットストリームとサブストリームラベル情報のマッピングは、マッピング情報によって行うことができる。ＬＦフィールドは、前述したＳＩＦフィールドに該当し得る。ラベルフィールドは、前述したＳＩＤフィールドに該当し得る。ここで、ラベルフィールドからはオプショナルヘッダーと呼ぶことができる。ラベルフィールドは、実施例によって３バイトのサイズを有してもよい。
第二に、リンクレイヤパケットに、インプットパケットの一つのセグメントが含まれてエンカプセレーションされた場合の実施例（ｔ５７０２０）を説明する。ここで、セグメントは、一つのインプットパケットが分割されて生成されてもよい。これは、前述したように、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）された場合と呼ぶことができる。
リンクレイヤヘッダーは、同様に、Ｐａｃｋｅｔ_ＴｙｐｅフィールドとＰＣフィールドから開始されてもよい。次いでＳ／Ｃフィールドが位置してもよい。このフィールドは、前述したように、リンクレイヤペイロードに連鎖したインプットパケットが含まれているか、または分割されたセグメントが含まれているかを示すことができる。両ケースに応じて、リンクレイヤヘッダーの構造は変更され得る。
Ｓ／Ｃフィールドが０である場合、すなわち、分割された場合において、Ｓ／Ｃフィールドの後にセグメントＩＤフィールド、セグメントシーケンスナンバーフィールドが順に位置してもよい。最初のセグメント以外のセグメントを含むリンクレイヤパケットに対しては、ＬＩフィールド及び／又はセグメント長さＩＤフィールドが順に位置してもよい。リンクレイヤパケットがその最初のセグメントを含む場合、最初のセグメント長さフィールド及び／又はＬＦフィールドが位置してもよい。すなわち、最初のセグメントを含むリンクレイヤヘッダーにはＬＩフィールドが含まれなくてもよい。ここで、最初のセグメント長さフィールドは、リンクレイヤパケットに含まれた最初のセグメントの長さを直接示すフィールドであり得る。ＬＦフィールドは、前述したように、その値によって、その後にラベルフィールドが位置してもよく、位置しなくてもよい。その他の各フィールドについての説明は、前述した通りである。
第三に、リンクレイヤパケットに、複数個のインプットパケットが連鎖してエンカプセレーションされた場合の実施例（ｔ５７０３０）を説明する。これは、前述したように、連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）した場合と呼ぶことができる。
リンクレイヤヘッダーは、同様に、Ｐａｃｋｅｔ_ＴｙｐｅフィールドとＰＣフィールドから開始されてもよい。分割の場合と同様に、次いでＳ／Ｃフィールドが位置してもよい。それに後続して、前述したカウントフィールドとＬＭフィールドが位置してもよい。ここで、カウントフィールドは、２ビットのフィールドであってもよく、００，０１，１０，１１である場合、それぞれ２，３，４，５個のインプットパケットが連鎖していることを示すことができる。または、前述したように、３ビットのカウントフィールドが使用されてもよい。
ＬＭフィールドは、長さモード（Ｌｅｎｔｈ Ｍｏｄｅ）フィールドであって、短いインプットパケットが連鎖してエンカプセレーションされたか、または長いインプットパケットが連鎖してエンカプセレーションされたかを示すことができる。短いインプットパケットが連鎖した場合に、ＬＭフィールドは０の値を有し、１１ビットの長さフィールドが、連鎖したインプットパケットの個数だけ位置してもよい。長いインプットパケットが連鎖した場合に、ＬＭフィールドは１の値を有し、２バイトの長さフィールドが、連鎖したインプットパケットの個数だけ位置してもよい。ここで、２０４８バイトよりも小さい場合、短いインプットパケットとし、２０４８バイトと同一又は大きい場合、長いインプットパケットとして区分することができる。
実施例によって、短いインプットパケットと長いインプットパケットが混在して連鎖した場合もあり得るが、この場合、短いインプットパケットに対しては１１ビットの長さフィールド、長いインプットパケットに対しては２バイトの長さフィールドが混在して位置してもよい。この長さフィールドは、対応するインプットパケットの順序と同じ順序でヘッダーに位置してもよい。
前述したリンクレイヤパケットのヘッダーの構造において、実施例によって、一部のフィールドが省略されてもよい。また、一部のフィールドが変更又は追加されてもよく、その順序が変わってもよい。
図５８は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のシンタックスを示した図である。
このシンタックスは、前述した、更に他の実施例に係るリンクレイヤパケットのヘッダー構造を示したものである。前述したように、Ｐａｃｋｅｔ_ＴｙｐｅフィールドとＰＣ（Ｐａｙｌｏａｄ_Ｃｏｎｆｉｇ）フィールドが共通に位置してもよい。
ＰＣフィールドの値が０の場合、ヘッダーモードフィールドが位置する。ヘッダーモードフィールドの値が０の場合、１１ビットの長さフィールドが位置してもよい。ヘッダーモードフィールドの値が１の場合、合計２バイトの長さフィールドとＬＦフィールド、リザーブドビットが順に位置してもよい。ＬＦフィールドの値によってＬａｂｅｌフィールドが追加で位置してもよい。
ＰＣフィールドの値が１の場合、Ｓ／Ｃフィールドが位置する。Ｓ／Ｃフィールドの値が０の場合、セグメントＩＤフィールドとセグメントシーケンスナンバーフィールドが位置してもよい。セグメントシーケンスナンバー値が００００の場合、すなわち、最初のセグメントが含まれる場合、最初のセグメント長さフィールドとＬＦフィールドが位置してもよい。ＬＦフィールドの値によって、Ｌａｂｅｌフィールドが追加で位置してもよい。セグメントシーケンスナンバー値が００００以外の値を有する場合、ＬＩフィールドとセグメント長さＩＤフィールドが位置してもよい。
Ｓ／Ｃフィールドの値が１の場合、カウントフィールドとＬＭフィールドが位置してもよい。カウントフィールドの値が示す個数だけ長さフィールドが位置することができ、短いインプットパケットに対しては１１ビットの長さフィールド、長いインプットパケットに対しては２バイトの長さフィールドが位置してもよい。
最後に残る部分に対してはパディングビットが位置してもよい。
前述したリンクレイヤパケットのヘッダー構造において、実施例によって、一部のフィールドが省略されてもよい。また、一部のフィールドが変更又は追加されてもよく、その順序が変わってもよい。
図５９は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、完全な一つのインプットパケットがリンクレイヤペイロードに含まれた場合を示した図である。
第一の実施例（ｔ５９０１０）は、短いシングルパケットエンカプセレーションの場合を示した。前述したように、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド、ＨＭフィールドが位置し、それに後続して１１ビットの長さフィールドが位置してもよい。合計２バイトのヘッダー長さを有することができ、それに後続してリンクレイヤペイロードが位置してもよい。ここで、ＰＣフィールド、ＨＭフィールドは、それぞれ０、０の値を有することができる。
第二の実施例（ｔ５９０２０）は、長いシングルパケットエンカプセレーションの場合を示した。前述したように、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド、ＨＭフィールドが位置し、それに後続して２バイトの長さフィールドが位置してもよい。２バイトの長さフィールドは、前述したように、１１ビットの長さフィールドと追加的な５ビットの長さフィールドが位置したものであってもよい。この長さフィールドは、それぞれＬＳＢパート、ＭＳＢパートを意味し得る。それに後続してリザーブドビットとＬＦフィールドが位置してもよい。合計３バイトのヘッダー長さを有することができ、それに後続してリンクレイヤペイロードが位置してもよい。ここで、ＰＣフィールド、ＨＭフィールド、ＬＦフィールドは、それぞれ０、１、０の値を有することができる。
第三の実施例（ｔ５９０３０）は、長いシングルパケットがエンカプセレーションされた場合において、ラベルフィールドがさらに位置する場合を示した。前述した長いシングルパケットがエンカプセレーションされた場合と同一であるが、ＬＦフィールドは１値を有し、それに後続してラベルフィールドが位置してもよい。
図６０は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を示した図である。
第一の実施例（ｔ６００１０）は、分割されたセグメントのうち最初のセグメントを含むリンクレイヤパケットの構造を示した。前述したように、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド、Ｓ／Ｃフィールドが位置し、それに後続して長さＩＤフィールドとセグメントシーケンスナンバーフィールドが位置してもよい。ここで、ＰＣフィールド、Ｓ／Ｃフィールド、セグメントシーケンスナンバーフィールドは、それぞれ、０、０、００００の値を有することができる。最初のセグメントが含まれたので、最初のセグメント長さフィールドが位置し得る。このフィールドは、前述したように、最初のセグメントの長さを直接示すことができる。それに後続してＬＦフィールドが位置してもよい。
第二の実施例（ｔ６００２０）は、分割されたセグメントのうち、最初又は最後のセグメントではない中間セグメントを含むリンクレイヤパケットの構造を示した。同様に、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド、Ｓ／Ｃフィールドが位置し、それに後続して長さＩＤフィールドとセグメントシーケンスナンバーフィールドが位置してもよい。ここで、ＰＣフィールド、Ｓ／Ｃフィールドは、それぞれ、０、０の値を有することができる。最初のセグメントが含まれなかったのでＬＩフィールドが位置するようになり、最後のセグメントが含まれなかったので、その値は０であり得る。それに後続してセグメント長さＩＤフィールドが位置してもよい。
第三の実施例（ｔ６００３０）は、分割されたセグメントのうち、最後のセグメントを含むリンクレイヤパケットの構造を示した。同様に、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド、Ｓ／Ｃフィールドが位置し、それに後続して長さＩＤフィールドとセグメントシーケンスナンバーフィールドが位置してもよい。ここで、ＰＣフィールド、Ｓ／Ｃフィールドは、それぞれ、０、０の値を有することができる。最初のセグメントが含まれなかったのでＬＩフィールドが位置するようになり、最後のセグメントが含まれたので、その値は１であり得る。それに後続してセグメント長さＩＤフィールドが位置してもよい。
第四の実施例（ｔ６００４０）は、分割されたセグメントのうち最初のセグメントを含むリンクレイヤパケットの構造において、ＬＦフィールドが１である場合を示した。第一の実施例と同一であるが、ＬＦフィールドの値によって、ラベルフィールドがさらに追加されてもよい。
図６１は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を、図表で示した図である。
一つのインプットパケットが総８個に分割された場合を想定した。このセグメントを有する全てのリンクレイヤパケットに対して、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは同じ値を有する。一つのインプットパケットから派生したためである。ＰＣフィールド、Ｓ／Ｃフィールドは、前述した定義通りに、１、０の値を有する。セグメントＩＤフィールドは、同様に一つのインプットパケットから派生したので、同じ値を有する。セグメントシーケンスナンバーフィールドは、各セグメントの順序を示すことができる。実施例によって、３ビットのセグメントシーケンスナンバーフィールドも可能である。
最初のセグメントを有するリンクレイヤパケットは、最初のセグメント長さフィールドが存在することによって、そのペイロードの長さを示すことができる。この場合、ＬＩフィールドとセグメント長さＩＤフィールドは存在しなくてもよい。
最初のセグメントではないセグメントを有するリンクレイヤパケットは、ペイロードの長さを直接示す長さフィールドは存在せず、ＬＩフィールドとセグメント長さＩＤフィールドを有することができる。セグメント長さＩＤフィールドは、前述した指定された長さＩＤのうち１つを選択して値を有するようになり、指定された値によってセグメントの長さを示すことができる。ＬＩフィールドは、最後のセグメントではない場合には０、最後のセグメントである場合には１の値を有することができる。
図６２は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、複数個のインプットパケットが連鎖してリンクレイヤペイロードに含まれた場合を示した図である。
第一の実施例（ｔ６２０１０）は、短いインプットパケットが連鎖してリンクレイヤペイロードに含まれた場合を示した。同様に、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド、Ｓ／Ｃフィールドが位置し、それに後続してカウントフィールドとＬＭフィールドがさらに位置してもよい。前述した定義に従って、ＰＣフィールド、Ｓ／Ｃフィールド、ＬＭフィールドは、それぞれ１、１、０の値を有することができる。
それに後続して、１１ビットの長さフィールドが順次位置してもよい。各連鎖した短いインプットパケットの長さを１つずつ示す長さフィールドは、対応するインプットパケットの順序と同一に順次位置してもよい。最後の長さフィールドまで埋められたとき、８ビットを埋めることができず残った部分はパディング（Ｐ）で埋められてもよい。次いで、各連鎖したインプットパケットが位置してもよい。
第二の実施例（ｔ６２０２０）は、長いインプットパケットが連鎖してリンクレイヤペイロードに含まれた場合を示した。同様に、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド、Ｓ／Ｃフィールドが位置し、それに後続してカウントフィールドとＬＭフィールドがさらに位置してもよい。前述した定義に従って、ＰＣフィールド、Ｓ／Ｃフィールド、ＬＭフィールドは、それぞれ１、１、１の値を有することができる。
それに後続して、２バイトの長さフィールドが順次位置してもよい。各連鎖した長いインプットパケットの長さを１つずつ示す長さフィールドは、対応するインプットパケットの順序と同一に順次位置してもよい。次いで、各連鎖したインプットパケットが位置してもよい。
図６３は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、完全な一つのインプットパケットがリンクレイヤペイロードに含まれた場合を示した図である。
第一の実施例（ｔ６３０１０）と第二の実施例（ｔ６３０２０）は、前述したシングルパケットエンカプセレーションにおけるリンクレイヤパケットのヘッダー構造と同一であり得る。ただし、長いインプットパケットを有する場合に対して、第一の実施例では、２バイトの長さフィールドが含まれるものと表現され、第二の実施例では、１１ビットの長さフィールドと５ビットの追加の長さフィールドが含まれるものと表現された。この場合、各長さフィールドは、長さを示すＬＳＢパートとＭＳＢパートを意味し得る。また、合計２バイトの長さフィールドの後にはリザーブドビットを有するものとなっており、最後のビットは、前述したように、ＬＦフィールドとして活用できる。
第三の実施例（ｔ６３０３０）は、前述したシングルパケットエンカプセレーションにおけるリンクレイヤパケットのヘッダー構造と類似している。短いインプットパケットが含まれる場合は、前述したシングルパケットエンカプセレーションにおけるリンクレイヤパケットのヘッダー構造と同一である。長いインプットパケットが含まれる場合には、５ビットの追加の長さフィールドの代わりに、長さ拡張フィールド（Ｌｅｎｇｔｈ ｅｘｔｅｎｓｉｏｎ）が位置してもよい。
長さ拡張フィールドは、長さ表示の拡張を表現するフィールドであり得る。長さ拡張フィールドは、パケットの構造に応じて、占めるビット数が変更されてもよい。ここでは、説明の便宜のため、２ビットの長さ拡張フィールドを想定して説明する。例えば、長さ拡張フィールドが使用されない場合、すなわち、ＨＭ＝０の場合には、短いインプットパケットがエンカプセレーションされた場合であり、１１ビットの長さフィールドは０〜２０４７バイトの間のペイロード長を示すことができる。長さ拡張フィールドが使用される場合、長さ拡張フィールドの値は、ペイロード長を示す際に、一種のオフセットとして作用することができる。長さ拡張フィールドが００の値を有する場合、１１ビットの長さフィールドが示す値は、２０４８〜４０９５バイトの間のペイロード長を意味するようになる。同様に、長さ拡張フィールドが０１、１０、１１の値を有する場合、１１ビットの長さフィールドが示す値は、それぞれ４０９６〜６１４３、６１４４〜８１９１、８１９２〜１０２３９バイトの間のペイロード長を意味するようになる。例えば、１１ビットの長さフィールドが「１バイトのペイロード長」を示す値を有し、長さ拡張フィールドが００の値を有する場合、これは、ペイロード長が２０４９バイトであるという意味である。また、例えば、１１ビットの長さフィールドが「１バイトのペイロード長」を示す値を有し、長さ拡張フィールドが０１の値を有する場合、これは、ペイロード長が４０９７バイトであるという意味である。これを通じて、長いシングルパケットのエンカプセレーションにも、その長さを示すことができる。
第四の実施例（ｔ６３０４０）は、前述したシングルパケットエンカプセレーションにおけるリンクレイヤパケットのヘッダー構造と同一であり得る。２バイトの長さフィールドは、１１ビットの長さフィールドと追加的な５ビットの長さフィールドに置換されてもよい。この場合、各長さビットは、長さを示すＬＳＢパートとＭＳＢパートを意味し得る。また、ＬＦフィールドの値によってラベルフィールドがさらに位置してもよい。ラベルフィールドの位置は、実施例によって変更されてもよい。
図６４は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、そのヘッダーの長さを図表で示した図である。
短いインプットパケットがシングルパケットエンカプセレーションされる場合において、ＰＣフィールドとＨＭフィールドは、それぞれ０、０の値を有することができる。１１ビットの長さフィールドによって、ヘッダーの全長は２バイトとなり得る。ここで、ｘは、当該ビットにいかなる値が入ってもかまわないということを意味する。例えば、１１ビットの長さフィールドは、ペイロードの長さによって定められる値であるから、ヘッダーの長さとは関係ないので、１１個のｘ（ｘｘｘｘｘｘｘｘｘｘｘ）で表現された。
長いインプットパケットがシングルパケットエンカプセレーションされる場合において、ＰＣフィールドとＨＭフィールドは、それぞれ０、１の値を有することができる。次いで、１１ビットの長さフィールド、５ビットの追加の長さフィールドなどのフィールドがさらに追加され、ヘッダーの全長は３バイトとなり得る。
分割される場合において、各リンクレイヤパケットのＰＣフィールドとＳ／Ｃフィールドは、それぞれ１、０の値を有することができる。最初のセグメントを含むリンクレイヤパケットは、００００のセグメントシーケンスナンバーフィールドを有することができる。本実施例において、ＬＦフィールドは０であってもよい。この場合、ヘッダーの全長は３バイトとなり得る。最初のセグメントではないセグメントを含むリンクレイヤパケットは、４ビットのセグメントシーケンスナンバーフィールドと、これに後続するＬＩフィールドを有することができる。この場合においては、ヘッダーの全長は２バイトとなり得る。
短いインプットパケットが連鎖する場合において、ＰＣフィールドとＳ／Ｃフィールドは、それぞれ１、１の値を有することができる。カウントフィールドは、ｎ個のパケットがエンカプセレーションされたことを示すことができ、この場合、ＬＭフィールドは０の値を有することができる。ヘッダーの全長は、ｎ個の１１ビットの長さフィールドが使用され、ヘッダーの前部に使用された１バイトがあるので、１１ｎ／８＋１バイトで表示することができる。ただし、バイトアラインのために、Ｐビット長のパディングビットの追加が必要な場合もあり、このとき、ヘッダーの長さは（（１１ｎ＋Ｐ）／８＋１）バイトで表示することができる。
長いインプットパケットが連鎖する場合において、ＰＣフィールドとＳ／Ｃフィールドは、それぞれ１、１の値を有することができる。カウントフィールドは、ｎ個のパケットがエンカプセレーションされたことを示すことができ、この場合、ＬＭフィールドは１の値を有することができる。ヘッダーの全長は、ｎ個の２バイト長のフィールドが使用され、ヘッダーの前部に使用された１バイトがあるので、２ｎ＋１バイトで表示することができる。
図６５は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を示した図である。
図示された実施例（ｔ６５０１０）は、前述した本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、分割された場合の構造と類似している。Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド及びＳ／Ｃフィールドが順に位置し、セグメントＩＤフィールド、セグメントシーケンスナンバーフィールドが位置してもよい。ＰＣフィールドとＳＣフィールドは、それぞれ１、０の値を有することができる。最初のセグメントの場合、最初のセグメント長さフィールドを有することができる。最初のセグメント長さフィールドの後の１ビットは、リザーブドビットであってもよく、前述したようにＬＦフィールドが位置してもよい。最初のセグメントではない場合には、ＬＩフィールドとセグメント長さＩＤフィールドが位置してもよい。
これを表で示す場合（ｔ６５０２０）、総５個に分割されたセグメントに対して、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは同じ値を有し、ＰＣフィールド、ＳＣフィールドはそれぞれ１、０の値を有することができる。セグメントＩＤフィールドも同じ値を有することができる。セグメントシーケンスナンバーは、各セグメントの順序を示す値を有することができる。最初のセグメントの場合には、最初のセグメント長さフィールドで長さを示し、ＬＩフィールドは存在しなくてもよい。最初のセグメントではない場合には、セグメント長さＩＤフィールドを使用して長さを示し、ＬＩフィールドは、最後のセグメントであるか否かによって０又は１の値を有することができる。
図６６は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を示した図である。
図示された実施例（ｔ６６０１０）は、前述した本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、分割された場合の構造と類似している。ただし、最初のセグメントではないセグメントを有するリンクレイヤパケットに対して、そのヘッダー構造が変更されてもよい。この場合、ＬＩフィールドの後に、セグメント長さＩＤフィールドの代わりにセグメント長さフィールドが位置してもよい。セグメント長さフィールドは、当該リンクレイヤパケットが有するセグメントの長さを直接示すフィールドであり得る。実施例によって、セグメント長さフィールドは１１ビットの長さを有してもよい。この場合、最初のセグメント長さフィールドも、単純にセグメント長さフィールドと呼ぶこともできる。
これを表で示す場合（ｔ６６０２０）、総５個に分割されたセグメントに対して、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは同じ値を有し、ＰＣフィールド、ＳＣフィールドはそれぞれ１、０の値を有することができる。セグメントＩＤフィールドも、同じ値を有することができる。セグメントシーケンスナンバーは、各セグメントの順序を示す値を有することができる。最初のセグメントであるか否かに関係なく、リンクレイヤペイロードの長さは、セグメント長さフィールドによって示すことができる。ＬＩフィールドは、最初のセグメントの場合には存在しなくてもよいが、最初のセグメントでない場合には存在し得る。ＬＩフィールドは、最後のセグメントであるか否かによって０又は１の値を有することができる。
図６７は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を示した図である。
図示された実施例（ｔ６７０１０）は、前述した本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、分割された場合の構造と類似している。ただし、最初のセグメントではないセグメントを有するリンクレイヤパケットに対して、そのヘッダー構造が変更されてもよい。この場合、ＬＩフィールドはセグメント長さフィールドの後に位置してもよい。セグメント長さフィールドに対しては、前述した通りであり、この場合、最初のセグメント長さフィールドも、単純にセグメント長さフィールドと呼ぶこともできる。
これを表で示す場合（ｔ６７０２０）、総５個に分割されたセグメントに対して、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは同じ値を有し、ＰＣフィールド、ＳＣフィールドはそれぞれ１、０の値を有することができる。セグメントＩＤフィールドも同じ値を有することができる。セグメントシーケンスナンバーは、各セグメントの順序を示す値を有することができる。最初のセグメントであるか否かに関係なく、リンクレイヤペイロードの長さはセグメント長さフィールドによって示すことができる。ＬＩフィールドは、最初のセグメントの場合には存在しなくてもよいが、最初のセグメントではない場合には存在し得る。ＬＩフィールドは、最後のセグメントであるか否かによって０又は１の値を有することができる。
図６８は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、インプットパケットが分割された一つのセグメントがリンクレイヤペイロードに含まれた場合を示した図である。
図示された実施例（ｔ６８０１０）は、前述した本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、分割された場合の構造と類似している。ただし、この場合、最初のセグメントであるか否かに関係なく、統一されたヘッダー構造を使用することができる。セグメントシーケンスナンバーフィールドまでの構造は、前述した通りである。その後に最初のセグメントであるかに関係なくＬＩフィールドが位置し、その後に当該リンクレイヤパケットのペイロード長を示すセグメント長さフィールドが位置してもよい。セグメント長さフィールドに対しては、前述した通りである。本実施例において、セグメントＩＤフィールドは省略されてもよく、セグメント長さフィールドがＳＣフィールドの直後に位置してもよい。また、ＬＩフィールドの後に、前述したＳＩＦフィールドが位置してもよい。
これを表で示す場合（ｔ６８０２０）、総５個に分割されたセグメントに対して、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは同じ値を有し、ＰＣフィールド、ＳＣフィールドはそれぞれ１、０の値を有することができる。セグメントＩＤフィールドも同じ値を有することができる。セグメントシーケンスナンバーは、各セグメントの順序を示す値を有することができる。最初のセグメントであるか否かに関係なくＬＩフィールドが存在し、ＬＩフィールドは、最後のセグメントであるか否かによって０又は１の値を有することができる。各リンクレイヤペイロードの長さは、最初のセグメントであるか否かに関係なく、セグメント長さフィールドによって示すことができる。
図６９は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、複数個のインプットパケットが連鎖してリンクレイヤペイロードに含まれた場合を示した図である。
図示された実施例（ｔ６９０１０）は、前述した本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、連鎖した場合の構造と同一であり得る。Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド及びＳ／Ｃフィールドが順に位置し、カウントフィールドとＬＭフィールドが位置してもよい。ＰＣフィールドとＳＣフィールドは、それぞれ１、０の値を有することができる。ＬＭフィールドの値に応じて、短いパケットがエンカプセレーションされた場合には、１１ビットの長さフィールドが、連鎖した数だけ位置してもよい。長いパケットがエンカプセレーションされた場合には、２バイトの長さフィールドが、連鎖した数だけ位置してもよい。
これを、連鎖したインプットパケットの数に応じて表で示すことができる（ｔ６９０２０）。カウントフィールドの値が００である場合、２個のインプットパケットが連鎖しており、２個の長さフィールドが使用されて２２ビットが使用され、２ビットのパディングがバイトアラインのために使用されてもよい。したがって、ヘッダーの全長は４バイトであり、一つのインプットパケットのためのヘッダー部分は２．０バイトであり得る。
カウントフィールドの値が０１、１０、１１である場合、それぞれ３、４、５個のインプットパケットが連鎖しており、それぞれ３、４、５個の長さフィールドが使用されてそれぞれ３３、４４、５５ビットが使用され、それぞれ７、４、１ビットのパディングがバイトアラインのために使用されてもよい。したがって、ヘッダーの全長はそれぞれ６、７、８バイトであり、一つのインプットパケットのためのヘッダー部分はそれぞれ２．０、１．７５、１．６０バイトであり得る。
図７０は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、複数個のインプットパケットが連鎖してリンクレイヤペイロードに含まれた場合を示した図である。
図示された実施例（ｔ７００１０，ｔ７００２０）は、前述した本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造において、連鎖した場合の構造と類似している。ただし、この場合、前述した構造からＬＭフィールドが省略されてもよい。Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド及びＳ／Ｃフィールドが順に位置し、カウントフィールドが位置してもよい。ＰＣフィールドとＳＣフィールドは、それぞれ１、１の値を有することができる。
図示された実施例（ｔ７００１０）の場合、１１ビットの長さフィールドが、連鎖した数だけ位置してもよい。このとき、１１ビットで表現できる短いインプットパケットに対しては、１１ビットの長さフィールドでその長さが表示される。１１ビットで表現できる長さよりも大きい長さのインプットパケットの場合には、連鎖が使用されるものではなく、前述したシングルパケットエンカプセレーション又は分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を活用できる。すなわち、１１ビットで表現できる大きさを基準として、連鎖が使用されるか又はシングルパケット／分割が使用されるかが既に指定された場合に使用できるリンクレイヤヘッダー構造である。
図示された実施例（ｔ７００２０）の場合、２バイトの長さフィールドが、連鎖した数だけ位置してもよい。２バイトで表現できる長さを有する全てのパケットに対して連鎖を支援するリンクレイヤヘッダー構造である。
これら実施例を、連鎖したインプットパケットの数に応じて表で示すことができる（ｔ７００３０、ｔ７００４０）。この表に対する説明は、前述した通りである。
前述した実施例（ｔ７００１０）に対する表（ｔ７００３０）に対して、例えば、カウントフィールドの値が０００の場合、２個のインプットパケットが連鎖しており、２個の長さフィールドが使用されて２２ビットが使用され、２ビットのパディングがバイトアラインのために使用されてもよい。したがって、ヘッダーの全長は４バイトであり、一つのインプットパケットのためのヘッダー部分は２．０バイトであり得る。また、カウントフィールドの値が００１の場合、３個のインプットパケットが連鎖しており、３個の長さフィールドが使用されて３３ビットが使用され、７ビットのパディングがバイトアラインのために使用されてもよい。したがって、ヘッダーの全長は６バイトであり、一つのインプットパケットのためのヘッダー部分は２．０バイトであり得る。
前述した実施例（ｔ７００２０）に対する表（ｔ７００４０）に対して、例えば、カウントフィールドの値が０００の場合、２個のインプットパケットが連鎖しており、２個の長さフィールドが使用されて４バイトが使用されてもよい。したがって、ヘッダーの全長は５バイトであり、一つのインプットパケットのためのヘッダー部分は２．５０バイトであり得る。また、カウントフィールドの値が００１の場合、３個のインプットパケットが連鎖しており、３個の長さフィールドが使用されて６バイトが使用されてもよい。したがって、ヘッダーの全長は７バイトであり、一つのインプットパケットのためのヘッダー部分は２．３３バイトであり得る。この場合、パディングビットは用いられなくてもよい。
図７１は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、ワード（ｗｏｒｄ）単位の長さ表示を使用する場合におけるリンクレイヤパケットの構造を示した図である。
上位レイヤのパケットの長さがワード（ｗｏｒｄ）単位で生成される場合、長さフィールドをバイト単位で表示せず、ワード単位で表示することができる。すなわち、インプットパケットが４バイト単位の長さを有する場合、リンクレイヤヘッダーをさらに最適化することができる。ワード単位で長さを表示することによって、前述した各長さフィールドが占める大きさをさらに小さくすることができるためである。
ワード単位で長さ表示をする場合におけるリンクレイヤヘッダー構造は、前述した本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造と類似している。各フィールドの位置や構成、動作は、前述した通りである。ただし、それぞれの長さフィールドの大きさはさらに小さくなる。
シングルパケットエンカプセレーションにおいて（ｔ７１０１０）、ペイロードの長さを示すフィールドを２ビット減少させることができる。１１ビットの長さフィールドは９ビットに減少し、２ビットは、将来の活用のために残すことができる（Ｒｅｓｅｒｖｅｄ）。また、長いインプットパケットが使用される場合においても、合計１６ビットの長さフィールドを１４ビットに減少させることができる。すなわち、ＭＳＢとして活用されていた長さフィールドを減少させることができる。９ビットの長さフィールドを用いて、２０４４バイト（５１１ワード）までのインプットパケットの長さを示すことができ、合計１４ビットの長さフィールドを用いて、６４ｋバイト（６５５３２バイト、１６３８３ワード）までのインプットパケットの長さを示すことができる。２ビットは、同様に将来の活用のために残すことができる。この残されたビットは、前述したオプショナルヘッダーが存在するか否かを示す指示子（ＨＥＦフィールド）として使用されてもよい。
分割や連鎖の場合においても（ｔ７１０２０、ｔ７１０３０）、同様に、長さフィールドを最適化することができる。１１ビットのセグメント長さフィールド乃至最初のセグメント長さフィールドは９ビットに減少させることができる。また、各セグメントの長さを示していた１１ビットの長さフィールドと２バイトの長さフィールドも、それぞれ９ビット、１４ビットに減少させることができる。この場合、バイトアラインのためにパディングビットが追加されてもよい。
このような最適化方案は、本発明で説明されるリンクレイヤパケットの構造に全て適用することができる。
図７２は、本発明の更に他の実施例に係るリンクレイヤパケットのヘッダー構造のうち、ワード（ｗｏｒｄ）単位の長さ表示を使用する場合をインプットパケットの数に応じて図表で示した図である。
第一の表（ｔ７２０１０）は、連鎖が使用される場合において、短いインプットパケットを連鎖する場合を示した。カウントフィールドの値が００の場合、２個のインプットパケットが連鎖しており、２個の長さフィールドが使用されて１８ビットが使用され、６ビットのパディングがバイトアラインのために使用されてもよい。したがって、ヘッダーの全長は４バイトであり、一つのインプットパケットのためのヘッダー部分は２．０バイトであり得る。
カウントフィールドの値が０１、１０、１１の場合、それぞれ３、４、５個のインプットパケットが連鎖しており、それぞれ３、４、５個の長さフィールドが使用されてそれぞれ２７、３６、４５ビットが使用され、それぞれ５、４、３ビットのパディングがバイトアラインのために使用されてもよい。したがって、ヘッダーの全長はそれぞれ５、６、７バイトであり、一つのインプットパケットのためのヘッダー部分はそれぞれ１．６７、１．５０、１．４０バイトであり得る。
第二の表（ｔ７２０２０）は、連鎖が使用される場合において、長いインプットパケットを連鎖する場合を示した。カウントフィールドの値が００の場合、２個のインプットパケットが連鎖しており、２個の長さフィールドが使用されて２８ビットが使用され、４ビットのパディングがバイトアラインのために使用されてもよい。したがって、ヘッダーの全長は５バイトであり、一つのインプットパケットのためのヘッダー部分は２．５０バイトであり得る。ワード単位の長さ表示を使用する場合、長いインプットパケットが連鎖する場合でもパディングビットが必要となり得る。
カウントフィールドの値が０１、１０、１１の場合、それぞれ３、４、５個のインプットパケットが連鎖しており、それぞれ３、４、５個の長さフィールドが使用されてそれぞれ４２、５６、７０ビットが使用され、それぞれ６、０、２ビットのパディングがバイトアラインのために使用されてもよい。したがって、ヘッダーの全長はそれぞれ７、８、１０バイトであり、一つのインプットパケットのためのヘッダー部分はそれぞれ２．３３、２．００、２．００バイトであり得る。
図７３は、本発明の一実施例に係る放送信号を送信する方法を示した図である。
本発明の一実施例に係る放送信号を送信する方法は、放送データを含む複数個のインプットパケットを生成する段階、インプットパケットを用いてリンクレイヤパケットを生成する段階、放送信号を生成する段階及び／又は放送信号を送信する段階を含むことができる。
まず、サービスプロバイダー側の第１モジュールは、複数個のインプットパケットを生成することができる（ｔ７３０１０）。ここで、複数個のインプットパケットは、ＭＰＥＧ２−ＴＳパケット、ＩＰパケットまたは特定の形態のパケットであってもよく、将来に定義されて使用されるパケットであってもよい。第１モジュールは、放送データを生成し、これをインプットパケットの形態で生成する特定のモジュールであってもよい。
サービスプロバイダー側の第２モジュールは、複数個のインプットパケットを用いて少なくとも１つのリンクレイヤパケット（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ）を生成することができる（ｔ７３０２０）。これは、前述したリンクレイヤでインプットパケットをエンカプセレーションしてリンクレイヤパケットが生成される過程を含むことができる。ここで、リンクレイヤパケットは、前述した実施例に係るパケット構造を有することができる。
本実施例において、リンクレイヤパケットのヘッダーには、パケットタイプ情報及びペイロード構成情報が含まれてもよい。この情報は、リンクレイヤパケットのヘッダーのベースヘッダーに含まれてもよい。パケットタイプ情報は、リンクレイヤパケットのペイロードに含まれるインプットパケットのタイプを示し、ペイロード構成情報は、リンクレイヤパケットのペイロードの構成を示すことができる。パケットタイプ情報は、前述したパケットタイプフィールド（Ｐａｃｋｅｔ_Ｔｙｐｅ）に、ペイロード構成情報は前述したＰＣフィールドに該当してもよい。
サービスプロバイダー側の第３モジュールは、生成されたリンクレイヤパケットを用いて放送信号を生成することができる（ｔ７３０３０）。これは、フィジカルレイヤでリンクレイヤパケットを用いて各種インターリービング、フレーミングなどの動作が行われることに対応し得る。サービスプロバイダー側の第４モジュールは、生成された放送信号を送信することができる（ｔ７３０４０）。ここで、第４モジュールはアンテナなどに該当してもよい。
本発明の他の実施例に係る放送信号を送信する方法において、ベースヘッダーは、ペイロードの長さを示す第１長さ情報をさらに含むことができる。第１長さ情報は、前述した前述した長さ（ＬＳＢ）フィールドに該当してもよい。
本発明の更に他の実施例に係る放送信号を送信する方法において、ペイロードは、インプットパケットのうち、一つの完全なインプットパケットを含むことができる。すなわち、前述したように、リンクレイヤパケットはシングルインプットパケットを含むことができる。シングルパケットを含む場合、ベースヘッダーは、リンクレイヤパケットのヘッダーが追加ヘッダーをさらに含むか否かを示すヘッダーモード情報をさらに含むことができる。ヘッダーモード情報は、前述したＨＭフィールドに該当してもよい。
本発明の更に他の実施例に係る放送信号を送信する方法において、追加ヘッダーは、第２長さ情報をさらに含むことができる。第２長さ情報は第１長さ情報と連結され、前述した一つの完全なインプットパケットが含まれたペイロードの全長を示すことができる。ここで、第２長さ情報は、前述した長さＭＳＢフィールド（Ｌｅｎｇｔｈ ＭＳＢ）に該当してもよい。本実施例は、ロング（ｌｏｎｇ）シングルパケットがエンカプセレーションされるケースに該当してもよい。
本発明の更に他の実施例に係る放送信号を送信する方法において、追加ヘッダーは、リンクレイヤパケット内にサブストリームＩＤ情報が含まれるか否かを示すサブストリームフラグ情報をさらに含むことができる。サブストリームＩＤ情報は前述したＳＩＤ情報、サブストリームフラグ情報は前述したＳＩＦ情報に該当してもよい。ＳＩＤ情報は、前述したラベル情報に該当してもよい。ＳＩＦ情報は、前述したＬＦフィールドに該当してもよい。
本発明の更に他の実施例に係る放送信号を送信する方法において、ペイロードは、複数個のインプットパケット、または一つのインプットパケットが分割されたセグメントを含むことができる。すなわち、シングルパケットが含まれない場合（ＰＣ＝１）において、リンクレイヤペイロードには、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）された入力パケットまたは連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）した入力パケットが含まれてもよい。この場合、ベースヘッダーは、ペイロードが複数個のインプットパケット又は分割されたセグメントを含むか否かを示す情報をさらに含むことができる。この情報は、前述したＳＣフィールドに該当してもよい。
本発明の更に他の実施例に係る放送信号を送信する方法において、リンクレイヤパケットを生成する段階は、インプットパケットのヘッダーを圧縮する段階、少なくとも１つの圧縮されたインプットパケットからコンテキスト情報を抽出する段階、及びコンテキスト情報と圧縮されたインプットパケットをエンカプセレーションしてリンクレイヤパケットを生成する段階をさらに含むことができる。コンテキスト情報を抽出する段階は、圧縮中の／圧縮されたインプットパケットからスタティック及び／又はダイナミックチェーン情報を抽出する過程であってもよい。この過程の後、コンテキスト情報はリンクレイヤパケットにエンカプセレーションされ、インプットパケットもリンクレイヤパケットにエンカプセレーションされてもよい。本動作は、前述した第２モジュールが行うことができる。または、第２モジュール内のサブモジュールによって行われてもよい。
本発明の更に他の実施例に係る放送信号を送信する方法において、コンテキスト情報を含むリンクレイヤパケットは、圧縮されたインプットパケットと分離されて伝送されてもよい。また、本発明の更に他の実施例に係る放送信号を送信する方法において、コンテキスト情報を含むリンクレイヤパケットは、シグナリングのためのフィジカルパスで伝送されてもよい。リンクレイヤレベルでコンテキスト情報を受信できるように、コンテキスト情報は、別途に伝送されてもよく、特定のチャンネルやＰＬＰを介して伝送されてもよい。また、一般的なフィジカルパスで伝送し、その経路がシグナリングされてもよい。
本発明の更に他の実施例に係る放送信号を送信する方法において、インプットパケットは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケット、圧縮されたＩＰパケット、ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）パケットのうち１つであってもよい。その他にも、インプットパケットは、パケットタイプフィールド及び／又はイーサーネットフィールドによって指示される様々なタイプ／プロトコルのデータであってもよい。
本発明の一実施例に係る放送信号を受信する方法を説明する。この方法は図示していない。
本発明の一実施例に係る放送信号を受信する方法は、放送信号を受信する段階、放送信号のリンクレイヤパケットを獲得する段階及び／又はリンクレイヤパケットを用いてアウトプットパケットを生成する段階を含むことができる。
まず、受信機側の第１モジュールは放送信号を受信することができる。この放送信号は、サービスプロバイダー側で前述した実施例によって送信した放送信号であってもよい。第１モジュールはアンテナ又はチューナーなどの受信装置であってもよい。
受信機側の第２モジュールは、受信した放送信号を用いてリンクレイヤパケットを獲得することができる。リンクレイヤパケットは、前述した通りである。この過程は、受信機側のフィジカルレイヤで放送信号を処理してアウトプットストリームをリンクレイヤに出力する過程に該当してもよい。
その後、受信機側の第３モジュールは、リンクレイヤパケットを処理してアウトプットパケットを生成することができる。ここで、アウトプットパケットは、サービスプロバイダー側でリンクレイヤに伝達されたインプットパケットに該当してもよい。この過程で、リンクレイヤパケットにエンカプセレーションされていたパケットを復旧することができる。この過程は、前述した「インプットパケットを用いてリンクレイヤパケットを生成する段階」の逆過程に該当してもよい。
本発明の実施例に係る放送信号を受信する方法は、前述した本発明の実施例に係る放送信号を送信する方法に対応し得る。放送信号を受信する方法は、放送信号を送信する方法で用いられるモジュールに対応するハードウェアモジュール（例えば、第１、２、３、４モジュールなど）によって行われてもよい。放送信号を受信する方法は、前述した放送信号を送信する方法の実施例に対応する実施例を有することができる。
前述した段階は、実施例によって省略されてもよく、類似／同一の動作を行う別の段階によって代替されてもよい。
図７４は、本発明の一実施例に係る放送信号を送信する装置を示した図である。
本発明の一実施例に係る放送信号を送信する装置は、前述した第１モジュール、第２モジュール、第３モジュール及び／又は第４モジュールを含むことができる。それぞれのブロック、モジュールは、前述した通りである。
本発明の一実施例に係る放送信号を送信する装置及びその内部モジュール／ブロックは、前述した本発明の放送信号を送信する方法の実施例を行うことができる。
本発明の一実施例に係る放送信号を受信する装置を説明する。この装置は図示していない。
本発明の一実施例に係る放送コンテンツを受信する装置は、前述した受信側の第１モジュール、第２モジュール及び／又は第３モジュールを含むことができる。それぞれのブロック、モジュールは、前述した通りである。
本発明の一実施例に係る放送信号を受信する装置及びその内部モジュール／ブロックは、前述した本発明の放送信号を受信する方法の実施例を行うことができる。
前述した装置内部のブロック／モジュールなどは、メモリに格納された連続した過程を実行するプロセッサであってもよく、実施例によって装置の内／外部に位置するハードウェアエレメントであってもよい。
前述したモジュールは、実施例によって省略されてもよく、類似／同一の動作を行う別のモジュールによって代替されてもよい。
モジュール又はユニットは、メモリ（又は、格納ユニット）に記憶された連続した過程を実行するプロセッサであってもよい。前述した実施例に記述された各段階は、ハードウェア／プロセッサによって実行することができる。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明が提示する方法はコードとして具現されるようにするこができる。このコードは、プロセッサが読み出し可能な記憶媒体に書き込まれ、装置（ａｐｐａｒａｔｕｓ）が提供するプロセッサによって読み出されるようにすることができる。
説明の便宜のため、各図を個別に説明したが、各図に開示した実施例を組み合わせて新しい実施例として具現するように設計することも可能である。そして、通常の技術者の必要に応じて、以前に説明された実施例を実行するためのプログラムが記録されているコンピュータで読み出し可能な記録媒体を設計することも、本発明の権利範囲に属する。
本発明に係る装置及び方法は、上述したように、説明された実施例の構成と方法に限定されて適用されるものではなく、上述した実施例は、様々な変形が可能なように、各実施例の全部又は一部が選択的に組み合わされて構成されてもよい。
一方、本発明が提案する方法を、ネットワークデバイスに具備された、プロセッサが読み出し可能な記録媒体に、プロセッサが読み出し可能なコードとして具現することができる。プロセッサが読み出し可能な記録媒体は、プロセッサによって読み出されるデータが格納されるいかなる種類の記録装置をも含む。プロセッサが読み出し可能な記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ格納装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み出し可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散されて、分散方式でプロセッサが読み出し可能なコードが格納され、実行されてもよい。
また、以上では、本発明の好適な実施例について図示及び説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨を逸脱することなく、当該発明の属する技術分野における通常の知識を有する者によって、様々な変形実施が可能であることはもちろんであり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。
そして、当該明細書では、物の発明及び方法の発明の両方が説明されており、必要に応じて、両発明の説明は補充的に適用されてもよい。
本発明の思想や範囲内で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むように意図される。
本明細書において、装置の発明も方法の発明も言及されており、装置及び方法の発明に関する説明は互いに補完して適用可能である。
様々な実施例が、本発明を実施するための最良の形態において説明されている。
本発明は、一連の放送信号提供分野で利用可能である。
本発明の思想や範囲内で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むように意図される。

Claims (16)

  1. 放送データを含む少なくとも１つのインプットパケットを生成するステップと、
    前記少なくとも１つのインプットパケットを用いてリンクレイヤパケットを生成するステップであって、前記リンクレイヤパケットのヘッダーは、パケットタイプ情報及びペイロード構成情報を含むベースヘッダーを含み、前記パケットタイプ情報は、前記リンクレイヤパケットのペイロード内の前記少なくとも１つのインプットパケットのタイプを示し、前記ペイロード構成情報は、前記リンクレイヤパケットのペイロードの構成を示す、ステップと、
    前記リンクレイヤパケットを含む放送信号を生成するステップと、
    前記放送信号を送信するステップと、
    を含み、
    前記ペイロードが単一パケットを含むことを前記ペイロード構成情報が示す場合、前記ベースヘッダーは、ヘッダーモード情報を含み、前記ヘッダーモード情報が特定値を持つ場合、前記単一パケットに対する追加ヘッダーが、前記リンクレイヤパケット内に存在し、
    前記追加ヘッダーは、オプショナルヘッダーが前記リンクレイヤパケット内に存在するか否かを示すフラグ情報を含む、放送信号送信方法。
  2. 前記ベースヘッダーは、前記ペイロードの長さを示す第１長さ情報をさらに含む、請求項１に記載の放送信号送信方法。
  3. 前記追加ヘッダーは第２長さ情報をさらに含み、
    前記第２長さ情報は前記第１長さ情報と連結され、前記単一パケットを含む前記ペイロードの全長を示す、請求項２に記載の放送信号送信方法。
  4. 前記ペイロードは、連結されたインプットパケット、または一つのインプットパケットの一つのセグメントを含み、前記ベースヘッダーは、前記ペイロードが前記連結されたインプットパケット、または前記セグメントを含むかを示す情報をさらに含む、請求項２に記載の放送信号送信方法。
  5. 前記リンクレイヤパケットを生成するステップは、
    前記少なくとも１つのインプットパケットのヘッダーを圧縮するステップと、
    前記圧縮されたヘッダーを有する前記少なくとも１つのインプットパケットからコンテキスト情報を抽出するステップと、
    前記コンテキスト情報及び前記圧縮されたヘッダーを有する前記少なくとも１つのインプットパケットをエンカプセレーションして前記リンクレイヤパケットを生成するステップと、
    を含む、請求項１に記載の放送信号送信方法。
  6. 前記コンテキスト情報を含む前記リンクレイヤパケットは、前記圧縮されたヘッダーを有する前記少なくとも１つのインプットパケットと分離されて伝送される、請求項５に記載の放送信号送信方法。
  7. 前記コンテキスト情報を含む前記リンクレイヤパケットは、シグナリングのためのフィジカルパスで伝送される、請求項５に記載の放送信号送信方法。
  8. 前記少なくとも１つのインプットパケットは、ＩＰパケット、圧縮されたＩＰパケット、またはＴＳパケットである、請求項１に記載の放送信号送信方法。
  9. 放送データを含む少なくとも１つのインプットパケットを生成する第１モジュールと、
    前記少なくとも１つのインプットパケットを用いてリンクレイヤパケットを生成する第２モジュールであって、前記リンクレイヤパケットのヘッダーは、パケットタイプ情報及びペイロード構成情報を含むベースヘッダーを含み、前記パケットタイプ情報は、前記リンクレイヤパケットのペイロード内の前記少なくとも１つのインプットパケットのタイプを示し、前記ペイロード構成情報は、前記リンクレイヤパケットのペイロードの構成を示す、第２モジュールと、
    前記リンクレイヤパケットを含む放送信号を生成する第３モジュールと、
    前記放送信号を送信する第４モジュールと、
    を含み、
    前記ペイロードが単一パケットを含むことを前記ペイロード構成情報が示す場合、前記ベースヘッダーは、ヘッダーモード情報を含み、前記ヘッダーモード情報が特定値を持つ場合、前記単一パケットに対する追加ヘッダーが、前記リンクレイヤパケット内に存在し、
    前記追加ヘッダーは、オプショナルヘッダーが前記リンクレイヤパケット内に存在するか否かを示すフラグ情報を含む、放送信号送信装置。
  10. 前記ベースヘッダーは、前記ペイロードの長さを示す第１長さ情報をさらに含む、請求項９に記載の放送信号送信装置。
  11. 前記追加ヘッダーは第２長さ情報をさらに含み、
    前記第２長さ情報は前記第１長さ情報と連結され、前記単一パケットを含む前記ペイロードの全長を示す、請求項１０に記載の放送信号送信装置。
  12. 前記ペイロードは、連結されたインプットパケット、または一つのインプットパケットの一つのセグメントを含み、前記ベースヘッダーは、前記ペイロードが前記連結されたインプットパケット、または前記セグメントを含むかを示す情報をさらに含む、請求項１０に記載の放送信号送信装置。
  13. 前記第２モジュールは、前記少なくとも１つのインプットパケットのヘッダーを圧縮し、前記圧縮されたヘッダーを有する前記少なくとも１つのインプットパケットからコンテキスト情報を抽出し、前記コンテキスト情報及び前記圧縮されたヘッダーを有する前記少なくとも１つのインプットパケットをエンカプセレーションして前記リンクレイヤパケットを生成する、請求項９に記載の放送信号送信装置。
  14. 前記コンテキスト情報を含む前記リンクレイヤパケットは、前記圧縮されたヘッダーを有する前記少なくとも１つのインプットパケットと分離されて伝送される、請求項１３に記載の放送信号送信装置。
  15. 前記コンテキスト情報を含む前記リンクレイヤパケットは、シグナリングのためのフィジカルパスで伝送される、請求項１３に記載の放送信号送信装置。
  16. 前記少なくとも１つのインプットパケットは、ＩＰパケット、圧縮されたＩＰパケット、またはＴＳパケットである、請求項９に記載の放送信号送信装置。
JP2016555440A 2014-10-20 2015-10-20 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 Active JP6359680B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462066331P 2014-10-20 2014-10-20
US62/066,331 2014-10-20
US201462069257P 2014-10-27 2014-10-27
US62/069,257 2014-10-27
PCT/KR2015/011037 WO2016064150A1 (ko) 2014-10-20 2015-10-20 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018041335A Division JP6556890B6 (ja) 2014-10-20 2018-03-07 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Publications (2)

Publication Number Publication Date
JP2017505080A JP2017505080A (ja) 2017-02-09
JP6359680B2 true JP6359680B2 (ja) 2018-07-18

Family

ID=55761131

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2016555440A Active JP6359680B2 (ja) 2014-10-20 2015-10-20 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
JP2018041335A Expired - Fee Related JP6556890B6 (ja) 2014-10-20 2018-03-07 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2018041335A Expired - Fee Related JP6556890B6 (ja) 2014-10-20 2018-03-07 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Country Status (6)

Country Link
US (3) US10523731B2 (ja)
EP (1) EP3211849A4 (ja)
JP (2) JP6359680B2 (ja)
KR (1) KR101801587B1 (ja)
CN (1) CN105765943B (ja)
WO (1) WO2016064150A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160052313A (ko) * 2014-11-04 2016-05-12 삼성전자주식회사 송신 장치, 수신 장치 및 그 신호 처리 방법
CN106105240B (zh) * 2015-01-21 2019-11-08 Lg电子株式会社 发送广播信号的装置以及发送广播信号的方法
KR102387881B1 (ko) * 2015-04-17 2022-04-18 삼성전자주식회사 방송 서비스를 구성하는 콘텐츠 관련 정보들을 제공하는 방법 및 장치
WO2017217825A1 (ko) * 2016-06-17 2017-12-21 엘지전자(주) 방송 신호 송수신 장치 및 방법
TWI736648B (zh) * 2016-07-15 2021-08-21 美商第一媒體有限責任公司 未來證明之控制發信號
US20190261253A1 (en) * 2016-11-03 2019-08-22 Sharp Kabushiki Kaisha Broadcast identifier signaling
WO2018168455A1 (ja) 2017-03-14 2018-09-20 ソニーセミコンダクタソリューションズ株式会社 送信装置、受信装置、及び、データ処理方法
MX2020004441A (es) * 2017-11-09 2020-08-06 Lg Electronics Inc Dispositivo de transmisión de señal de radiodifusión, método de transmisión de señal de radiodifusión, dispositivo de recepción de señal de radiodifusión, y método de recepción de señal de radiodifusión.

Family Cites Families (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6160808A (en) * 1997-12-18 2000-12-12 3Com Corporation Technique for transmitting incoming multi-link point-to-point (PPP) packet traffic over multiple outgoing links in a multi-link bundle
KR100434270B1 (ko) * 2001-05-30 2004-06-04 엘지전자 주식회사 가전기기 네트워크 제어시스템
US7908388B1 (en) * 2001-11-20 2011-03-15 Nokia Corporation Multicast address to packet identifier mapping for broadcast systems
JP4317403B2 (ja) * 2002-08-09 2009-08-19 パナソニック株式会社 ヘッダ圧縮装置及びヘッダ圧縮方法
KR100884956B1 (ko) * 2002-08-14 2009-02-23 엘지전자 주식회사 비대칭 양방향 패킷데이터 송수신 방법 및 시스템
EP1416682B1 (en) * 2002-10-31 2009-07-29 Alcatel Lucent Methods of processing data packets at layer three level in a telecommunication equipment
US7634582B2 (en) * 2003-12-19 2009-12-15 Intel Corporation Method and architecture for optical networking between server and storage area networks
SE0400288D0 (sv) * 2004-02-11 2004-02-11 Ericsson Telefon Ab L M Improvements in or relating to telecommunication services
JP2006287284A (ja) * 2005-03-31 2006-10-19 Nec Corp 無線通信システム及びそのヘッダ圧縮制御方法
US8368530B1 (en) * 2006-08-02 2013-02-05 A&T Mobility II LLC Network directed cell broadcasts for emergency alert system
KR101091471B1 (ko) * 2006-12-18 2011-12-07 엘지에릭슨 주식회사 이동통신 시스템에서 중계선 제어를 위한 패킷 압축/해제장치 및 그 방법
US20080225766A1 (en) * 2007-03-15 2008-09-18 Interdigital Technology Corporation Method and apparatus for reconfiguring medium access control components in wireless communications
WO2008141169A1 (en) * 2007-05-09 2008-11-20 Entropic Communications, Inc. Aggregating network packets for transmission to a destination node
BRPI0805829B1 (pt) * 2007-05-14 2020-05-26 Samsung Electronics Co., Ltd Método de transmissão de um serviço de difusão móvel, e aparelho para transmissão de um serviço de difusão móvel
KR101405966B1 (ko) * 2007-06-26 2014-06-20 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
KR101405970B1 (ko) * 2007-06-28 2014-06-12 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
US8817780B2 (en) * 2007-08-08 2014-08-26 Maxlinear, Inc. TS packet grooming
US8248910B2 (en) * 2008-01-29 2012-08-21 Nokia Corporation Physical layer and data link layer signalling in digital video broadcast preamble symbols
JP5245761B2 (ja) * 2008-11-26 2013-07-24 富士通株式会社 送信装置、受信装置、送信方法及び受信方法
US8542706B2 (en) * 2008-12-08 2013-09-24 Qualcomm Incorporated Method and apparatus related to packet fragmentation and reconstruction
WO2010077046A2 (en) * 2008-12-30 2010-07-08 Samsung Electronics Co,. Ltd. Method and apparatus for processing packet
EP2378678B1 (en) 2009-01-14 2016-03-30 LG Electronics Inc. Efficient mac header design and communication using same
WO2010082766A2 (ko) 2009-01-14 2010-07-22 엘지전자주식회사 다중 반송파 시스템에서의 무선 장치
US20100232356A1 (en) * 2009-03-16 2010-09-16 Qualcomm Incorporated Layer two segmentation techniques for high data rate transmissions
EP2415220B1 (en) * 2009-04-01 2013-08-21 Koninklijke Philips Electronics N.V. Frame concatenation in wireless uwb devices
KR101147777B1 (ko) 2009-04-14 2012-05-25 엘지전자 주식회사 매체접속제어 프로토콜데이터 유닛 전송방법
EP2452480B1 (en) * 2009-07-08 2018-03-21 Thomson Licensing DTV Backward looking robust header compression receiver
EP2362653A1 (en) * 2010-02-26 2011-08-31 Panasonic Corporation Transport stream packet header compression
US9143271B2 (en) 2010-04-01 2015-09-22 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcast signal receiving apparatus, and broadcast signal transceiving method in a broadcast signal transceiving apparatus
EP2566156A4 (en) 2010-04-28 2015-04-29 Lg Electronics Inc BROADCAST TRANSMITTER, BROADCAST RECEIVER AND METHOD FOR SENDING AND RECEIVING BROADCAST SIGNALS WITH DEVICES FOR TRANSMITTING AND RECEIVING BROADCAST SIGNALS
US20130039278A1 (en) * 2010-05-03 2013-02-14 Nokia Corporation Protocol overhead reduction
EP2601767B1 (en) * 2010-08-03 2018-10-31 Samsung Electronics Co., Ltd Method and base station of communicating packet data units over the gb-interface of a mobile network
CN106027578B (zh) * 2010-11-23 2019-09-17 Lg电子株式会社 广播信号发送设备以及发送广播信号的方法
US8744010B2 (en) * 2011-05-12 2014-06-03 Nokia Corporation Providing signaling information in an electronic service guide
US8929373B2 (en) 2011-09-29 2015-01-06 Intel Corporation Sending packets with expanded headers
WO2013050629A1 (es) 2011-10-05 2013-04-11 Simplicity Works Europe, S.L. Procedimiento de fabricación de calzado
KR101933465B1 (ko) * 2011-10-13 2019-01-11 삼성전자주식회사 이동 통신 시스템에서 패킷 송수신 장치 및 방법
KR101995221B1 (ko) * 2011-11-24 2019-07-16 삼성전자주식회사 통신 시스템에서 패킷 송수신 장치 및 방법
US8938551B2 (en) * 2012-04-10 2015-01-20 Intel Mobile Communications GmbH Data processing device
JP5969689B2 (ja) 2012-04-18 2016-08-17 アクメ パケット インコーポレイテッドＡｃｍｅ Ｐａｃｋｅｔ， Ｉｎｃ． リアルタイム通信のための冗長性
KR102035259B1 (ko) * 2012-04-25 2019-10-22 삼성전자주식회사 디지털 방송 시스템에서 시그널링 정보 송수신 장치 및 방법
US8959325B2 (en) * 2012-06-21 2015-02-17 Breakingpoint Systems, Inc. Systems and methods for booting devices using assigned servers in a multiple-card computing system
US8811401B2 (en) * 2012-06-21 2014-08-19 Breakingpoint Systems, Inc. Binding of network flows to process threads
US20130343380A1 (en) * 2012-06-21 2013-12-26 Rodney S. Canion Flexible port binding for control processor
US8891528B2 (en) * 2012-06-21 2014-11-18 Breakingpoint Systems, Inc. Managing the capture of packets in a computing system
US9236936B2 (en) * 2012-08-31 2016-01-12 Hughes Network Systems, Llc System and method for low-complexity, high-speed preprocessing of encapsulated packets in a broadband communications network
WO2014061488A1 (ja) * 2012-10-17 2014-04-24 ソニー株式会社 データ処理装置、データ処理方法、及び、プログラム
TWM487509U (zh) * 2013-06-19 2014-10-01 杜比實驗室特許公司 音訊處理設備及電子裝置
US9350657B2 (en) * 2013-07-08 2016-05-24 Nicira, Inc. Encapsulating data packets using an adaptive tunnelling protocol
KR102130151B1 (ko) * 2013-07-22 2020-07-03 삼성전자주식회사 송신 장치, 수신 장치 및 그 신호 처리 방법
KR102288500B1 (ko) * 2013-08-05 2021-08-11 삼성전자주식회사 송신 장치, 수신 장치 및 그 제어 방법
KR102284042B1 (ko) * 2013-09-04 2021-07-30 삼성전자주식회사 송신 장치, 수신 장치 및 그 신호 처리 방법
US10432529B2 (en) * 2013-09-19 2019-10-01 Connectivity Systems Incorporated Enhanced large data transmissions and catastrophic congestion avoidance over IPv6 TCP/IP networks
EP2935608A1 (en) * 2013-10-14 2015-10-28 SynAffix B.V. Modified glycoprotein, protein-conjugate and process for the preparation thereof
CN105794174B (zh) * 2014-03-03 2019-06-21 Lg电子株式会社 用于发送/接收广播信号的设备和方法
CN105594216B (zh) * 2014-08-01 2019-02-19 Lg电子株式会社 广播信号发送方法、广播信号发送设备
WO2016072747A1 (en) * 2014-11-04 2016-05-12 Samsung Electronics Co., Ltd. Transmitting apparatus and receiving apparatus and signal processing method thereof
KR102445458B1 (ko) * 2015-02-17 2022-09-21 소니그룹주식회사 송신 장치, 송신 방법, 수신 장치 및 수신 방법

Also Published As

Publication number Publication date
JP2018121347A (ja) 2018-08-02
EP3211849A4 (en) 2018-04-18
KR101801587B1 (ko) 2017-11-27
EP3211849A1 (en) 2017-08-30
JP6556890B2 (ja) 2019-08-07
US11496542B2 (en) 2022-11-08
US20210185108A1 (en) 2021-06-17
US10523731B2 (en) 2019-12-31
CN105765943B (zh) 2019-08-23
KR20160059477A (ko) 2016-05-26
US20160294914A1 (en) 2016-10-06
JP6556890B6 (ja) 2019-11-13
US20200195704A1 (en) 2020-06-18
CN105765943A (zh) 2016-07-13
US10972527B2 (en) 2021-04-06
WO2016064150A1 (ko) 2016-04-28
JP2017505080A (ja) 2017-02-09

Similar Documents

Publication Publication Date Title
US10887277B2 (en) Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal
US11019186B2 (en) Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal
JP6556890B6 (ja) 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
KR101875672B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10856021B2 (en) Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
US11606293B2 (en) Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
KR101823482B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170321

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170619

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170718

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171017

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20171107

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180307

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20180417

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180522

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180620

R150 Certificate of patent or registration of utility model

Ref document number: 6359680

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250