JP6301497B2 - 放送信号伝送装置、及び放送信号伝送方法 - Google Patents

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

Info

Publication number
JP6301497B2
JP6301497B2 JP2016563768A JP2016563768A JP6301497B2 JP 6301497 B2 JP6301497 B2 JP 6301497B2 JP 2016563768 A JP2016563768 A JP 2016563768A JP 2016563768 A JP2016563768 A JP 2016563768A JP 6301497 B2 JP6301497 B2 JP 6301497B2
Authority
JP
Japan
Prior art keywords
packet
link layer
field
header
information
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
JP2016563768A
Other languages
English (en)
Other versions
JP2017512036A (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 JP2017512036A publication Critical patent/JP2017512036A/ja
Application granted granted Critical
Publication of JP6301497B2 publication Critical patent/JP6301497B2/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
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • 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/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0006—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format
    • H04L1/0007—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format by modifying the frame length
    • H04L1/0008—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format by modifying the frame length by supplementing frame payload, e.g. with padding bits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2592—Translation of Internet protocol [IP] addresses using tunnelling or encapsulation
    • 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/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0226—Mapping or translating multiple network management protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/20—Support for services
    • H04L49/201—Multicast operation; Broadcast operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/20—Support for services
    • H04L49/205—Quality of Service based
    • 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
    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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
    • 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
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • 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]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • 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/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

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 (14)

  1. 放送サービスのサービスデータを生成するステップと、
    前記サービスデータを少なくとも一つの伝送ストリームの複数個の伝送パケットにエンカプセレーションするステップと、
    前記少なくとも一つの伝送ストリームの複数個の伝送パケットを複数個のリンクレイヤーパケット（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ）にエンカプセレーションするステップであって、前記複数個のリンクレイヤーパケットのそれぞれは、ベースヘッダーを含み、前記複数個のリンクレイヤーパケットの少なくとも一つは、前記ベースヘッダーの後に付加された追加ヘッダーをさらに含む、ステップと、
    前記ベースヘッダーは、対応するリンクレイヤーパケットに含まれる伝送パケットのタイプを示す情報を含み、
    前記追加ヘッダーは、第１の指示情報（ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）と第２の指示情報（ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を含み、
    前記第１の指示情報は、前記対応するリンクレイヤーパケットにより伝達される伝送ストリームを識別するサブストリーム識別子が存在するか否かを示し、
    前記第２の指示情報は、ヘッダー拡張が存在するか否かを示し、
    前記第１指示情報が前記サブストリーム識別子が存在することを示す時、前記サブストリーム識別子は、前記第２指示情報の後に存在し、
    前記複数個のリンクレイヤーパケットを用いて放送信号を生成するステップと、
    前記放送信号を送信するステップと、
    を含む、放送信号伝送方法。
  2. 前記第１の指示情報が、前記サブストリーム識別子が存在することを示し、前記第２の指示情報がヘッダー拡張があることを示す時、前記サブストリーム識別子は、第２の指示情報と前記ヘッダー拡張との間に存在する、請求項１に記載の放送信号伝送方法。
  3. 前記複数個のリンクレイヤーパケットの他の一つは、リンクマッピングテーブルを含み、
    前記リンクマッピングテーブルは、一つのＰＬＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｉｐｅ）で伝達される前記少なくとも一つの伝送ストリームに関する情報を含む、請求項１に記載の放送信号伝送方法。
  4. 前記リンクマッピングテーブルは、前記一つのＰＬＰの識別子をさらに含み、
    前記少なくとも一つの伝送ストリームに関する情報は、前記対応する伝送ストリームのＩＰアドレス及びＵＤＰポート番号についての情報を含む、請求項３に記載の放送信号伝送方法。
  5. 前記少なくとも一つの伝送ストリームに関する情報は、サブストリーム識別子フラグフィールドをさらに含み、
    前記サブストリーム識別子フラグフィールドは、前記対応する伝送ストリームを伝達するリンクレイヤーパケットが第１のサブストリーム識別子を含むか否かを示す、請求項４に記載の放送信号伝送方法。
  6. 前記少なくとも一つの伝送ストリームに関する情報は、第２のサブストリーム識別子をさらに含み、
    前記第２のサブストリーム識別子は、前記第１のサブストリーム識別子と同じ値を有する、請求項５に記載の放送信号伝送方法。
  7. 前記ベースヘッダーは、前記対応するリンクレイヤーパケットのペイロードの構成を示す情報をさらに含み、
    前記追加ヘッダーは、前記対応するリンクレイヤーパケットの構成に基づいた前記対応するリンクレイヤーパケットについての追加情報を含み、
    前記追加ヘッダーは、前記ベースヘッダーの後に位置する、請求項１に記載の放送信号伝送方法。
  8. 放送サービスのサービスデータを生成する第１モジュールと、
    前記サービスデータを少なくとも一つの伝送ストリームの複数個の伝送パケットにエンカプセレーションする第２モジュールと、
    前記少なくとも一つの伝送ストリームの複数個の伝送パケットを複数個のリンクレイヤーパケット（Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔ）にエンカプセレーションする第３モジュールであって、前記複数個のリンクレイヤーパケットのそれぞれは、ベースヘッダーを含み、前記複数個のリンクレイヤーパケットの少なくとも一つは、前記ベースヘッダーの後に付加された追加ヘッダーを含む、第３モジュールと、
    を備え、
    前記ベースヘッダーは、対応するリンクレイヤーパケットに含まれる伝送パケットのタイプを示す情報を含み、
    前記追加ヘッダーは、第１の指示情報（ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）と第２の指示情報（ｉｎｄｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を含み、
    前記第１の指示情報は、前記対応するリンクレイヤーパケットにより伝達される伝送ストリームを識別するサブストリーム識別子が存在するか否かを示し、
    前記第２の指示情報は、ヘッダー拡張が存在するか否かを示し、
    前記第１指示情報が前記サブストリーム識別子が存在することを示す時、前記サブストリーム識別子は、前記第２指示情報の後に存在し、
    前記第３モジュールは、前記複数個のリンクレイヤーパケットを用いて放送信号を生成し、前記放送信号を伝送する、放送信号伝送装置。
  9. 前記第１の指示情報が、前記サブストリーム識別子が存在することを示し、前記第２の指示情報がヘッダー拡張があることを示す時、前記サブストリーム識別子は、第２の指示情報と前記ヘッダー拡張との間に存在する、請求項８に記載の放送信号伝送装置。
  10. 前記複数個のリンクレイヤーパケットの他の一つは、リンクマッピングテーブルを含み、
    前記リンクマッピングテーブルは、一つのＰＬＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｉｐｅ）によって伝達される前記少なくとも一つの伝送ストリームに関する情報を含む、請求項８に記載の放送信号伝送装置。
  11. 前記リンクマッピングテーブルは、前記一つのＰＬＰの識別子をさらに含み、
    前記少なくとも一つの伝送ストリームに関する情報は、前記対応する伝送ストリームのＩＰアドレス及びＵＤＰポート番号についての情報を含む、請求項１０に記載の放送信号伝送装置。
  12. 前記少なくとも一つの伝送ストリームに関する情報は、サブストリーム識別子フラグフィールドをさらに含み、
    前記サブストリーム識別子フラグフィールドは、前記対応する伝送ストリームを伝達するリンクレイヤーパケットが第１のサブストリーム識別子を含むか否かを示す、請求項１１に記載の放送信号伝送装置。
  13. 前記少なくとも一つの伝送ストリームに関する情報は、第２のサブストリーム識別子をさらに含み、
    前記第２のサブストリーム識別子は、前記第１のサブストリーム識別子と同じ値を有する、請求項１２に記載の放送信号伝送装置。
  14. 前記ベースヘッダーは、前記対応するリンクレイヤーパケットのペイロードの構成を示す情報をさらに含み、
    前記追加ヘッダーは、前記対応するリンクレイヤーパケットの構成に基づいた前記対応するリンクレイヤーパケットについての追加情報を含み、
    前記追加ヘッダーは、前記ベースヘッダーの後に位置する、請求項８に記載の放送信号伝送装置。
JP2016563768A 2014-12-10 2015-12-08 放送信号伝送装置、及び放送信号伝送方法 Active JP6301497B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462090352P 2014-12-10 2014-12-10
US62/090,352 2014-12-10
US201462090860P 2014-12-11 2014-12-11
US62/090,860 2014-12-11
PCT/KR2015/013364 WO2016093586A1 (ko) 2014-12-10 2015-12-08 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Publications (2)

Publication Number Publication Date
JP2017512036A JP2017512036A (ja) 2017-04-27
JP6301497B2 true JP6301497B2 (ja) 2018-03-28

Family

ID=56107700

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016563768A Active JP6301497B2 (ja) 2014-12-10 2015-12-08 放送信号伝送装置、及び放送信号伝送方法

Country Status (6)

Country Link
US (3) US10057211B2 (ja)
EP (1) EP3070949A4 (ja)
JP (1) JP6301497B2 (ja)
KR (2) KR101764635B1 (ja)
CN (1) CN105981318B (ja)
WO (1) WO2016093586A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6692057B2 (ja) 2014-12-10 2020-05-13 パナソニックＩｐマネジメント株式会社 送信方法、受信方法、送信装置及び受信装置
EP3242457B1 (en) * 2015-01-02 2019-12-11 LG Electronics Inc. Broadcast signal transmission apparatus, broadcast signal receiving apparatus, broadcast signal transmission method, and broadcast signal receiving method
US10574375B2 (en) 2015-03-04 2020-02-25 Sony Corporation Transmission device, transmission method, reception device, and reception method
WO2016144031A1 (ko) * 2015-03-11 2016-09-15 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10735563B2 (en) * 2015-08-07 2020-08-04 Sharp Kabushiki Kaisha Systems and methods for data transmission based on a link layer packet structure
CA3082203C (en) 2015-10-23 2022-11-08 Sharp Kabushiki Kaisha Signaling method, receiving method signaling device, and receiving device
US20180026846A1 (en) * 2016-07-19 2018-01-25 Qualcomm Incorporated Compatible channel bonding service management
MX2019004780A (es) * 2016-11-04 2019-08-05 Sharp Kk Señalizacion dinamica de eventos.
DE102017204181A1 (de) * 2017-03-14 2018-09-20 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Sender zum Emittieren von Signalen und Empfänger zum Empfangen von Signalen
KR102373478B1 (ko) * 2017-09-19 2022-03-11 한국전자통신연구원 케이블 방송망을 통한 ip 기반 방송 데이터 전송 방법 및 장치
KR102418146B1 (ko) 2017-11-09 2022-07-07 엘지전자 주식회사 방송 송신 장치, 방송 송신 방법, 방송 수신 장치 및 방송 수신 방법
US10965786B2 (en) 2018-10-31 2021-03-30 At&T Intellectual Property I, L.P. Adaptive fixed point mapping for uplink and downlink fronthaul
CN109639555B (zh) * 2018-12-29 2021-03-02 Oppo广东移动通信有限公司 链路层报文生成方法、链路层报文生成装置及终端设备
KR102145528B1 (ko) * 2019-03-15 2020-08-18 주식회사 로와시스 Atsc 3.0 수신장비용 alp표준 자동 전환 장치 및 방법
US20220311814A1 (en) * 2021-03-29 2022-09-29 Tencent America LLC Techniques for signaling multiple audio mixing gains for teleconferencing and telepresence for remote terminals
WO2024070652A1 (ja) * 2022-09-26 2024-04-04 ソニーグループ株式会社 送信装置、送信方法、受信装置、及び、受信方法

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1146713B1 (en) * 2000-03-03 2005-04-27 NTT DoCoMo, Inc. Method and apparatus for packet transmission with header compression
JP3617967B2 (ja) * 2001-09-28 2005-02-09 松下電器産業株式会社 ヘッダ圧縮パケット受信装置及び方法
US7647421B2 (en) * 2002-08-20 2010-01-12 Nokia Corporation Extension header compression
WO2005015857A1 (en) * 2003-08-08 2005-02-17 Samsung Electronics Co., Ltd. Method and apparatus for configuring protocols for a multimedia broadcast/multicast service
WO2005043856A1 (fr) * 2003-10-30 2005-05-12 Utstarcom (China) Co. Ltd. Dispositif et procede de transfert sans fil de paquets ip en temps reel a l'aide d'une technique d'en-tete de compression
KR100770857B1 (ko) * 2004-02-12 2007-10-26 삼성전자주식회사 멀티미디어 방송/멀티캐스트 서비스 시스템에서 헤더 복원 동작을 재개하는 방법
US7876695B2 (en) * 2006-03-07 2011-01-25 Telefonaktiebolaget Lm Ericsson (Publ) Communication station and method providing flexible compression of data packets
US8948206B2 (en) * 2006-08-31 2015-02-03 Telefonaktiebolaget Lm Ericsson (Publ) Inclusion of quality of service indication in header compression channel
US8750334B2 (en) * 2006-10-02 2014-06-10 Motorola Mobility Llc Link layer assisted robust header compression context update management
MX2009004942A (es) * 2007-05-14 2009-06-03 Samsung Electronics Co Ltd Metodo y aparato para transmitir radiodifusion, metodo y aparato para recibir radiodifusion.
US8081603B2 (en) * 2007-07-18 2011-12-20 Qualcomm Incorporated Compression static and semi-static context transfer
KR101435842B1 (ko) 2007-08-24 2014-09-01 엘지전자 주식회사 디지털 방송 수신기 및 그 제어 방법
US8358670B2 (en) 2008-12-30 2013-01-22 Samsung Electronics Co., Ltd. Method and apparatus for processing packet
CN102484643B (zh) * 2009-07-08 2015-11-25 汤姆森特许公司 后向鲁棒性首标压缩接收器
WO2011136574A2 (ko) 2010-04-28 2011-11-03 엘지전자 주식회사 방송 신호 송신기, 방송 신호 수신기, 및 방송 신호 송/수신기에서 방송 신호 송수신 방법
CN106027578B (zh) 2010-11-23 2019-09-17 Lg电子株式会社 广播信号发送设备以及发送广播信号的方法
CN102036307B (zh) * 2010-12-17 2016-04-13 中兴通讯股份有限公司 鲁棒性头压缩中提高上下文更新报文健壮性的方法和装置
KR20140043237A (ko) * 2012-09-27 2014-04-08 한국전자통신연구원 방송 신호 송신 장치 및 방법
US10541777B2 (en) 2012-10-17 2020-01-21 Saturn Licensing Llc Data processing device, data processing method, and program
KR102130151B1 (ko) * 2013-07-22 2020-07-03 삼성전자주식회사 송신 장치, 수신 장치 및 그 신호 처리 방법
KR102288500B1 (ko) * 2013-08-05 2021-08-11 삼성전자주식회사 송신 장치, 수신 장치 및 그 제어 방법
US9602245B2 (en) * 2014-05-21 2017-03-21 Samsung Electronics Co., Ltd. Transmitting apparatus and interleaving method thereof
US10367921B2 (en) * 2014-10-30 2019-07-30 Sony Corporation Transmission apparatus, transmission method, reception apparatus, and reception method
WO2016072747A1 (en) * 2014-11-04 2016-05-12 Samsung Electronics Co., Ltd. Transmitting apparatus and receiving apparatus and signal processing method thereof
US10193803B2 (en) * 2014-11-11 2019-01-29 Samsung Electronics Co., Ltd. Transmitting apparatus, receiving apparatus and controlling method thereof
KR101814401B1 (ko) * 2014-11-20 2018-01-04 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
KR101956036B1 (ko) * 2014-12-08 2019-03-08 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Also Published As

Publication number Publication date
US10887277B2 (en) 2021-01-05
US10057211B2 (en) 2018-08-21
JP2017512036A (ja) 2017-04-27
EP3070949A4 (en) 2017-09-27
US20180367502A1 (en) 2018-12-20
KR20170091166A (ko) 2017-08-08
US10454885B2 (en) 2019-10-22
CN105981318A (zh) 2016-09-28
KR20160084833A (ko) 2016-07-14
CN105981318B (zh) 2019-08-09
KR101764635B1 (ko) 2017-08-03
KR101823486B1 (ko) 2018-03-14
EP3070949A1 (en) 2016-09-21
US20200014657A1 (en) 2020-01-09
US20160359803A1 (en) 2016-12-08
WO2016093586A1 (ko) 2016-06-16

Similar Documents

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

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170130

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170509

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170727

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: 20180206

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180228

R150 Certificate of patent or registration of utility model

Ref document number: 6301497

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