CN105874759B

CN105874759B - Method and apparatus for transmitting/receiving broadcast signal including robust header compressed packet stream

Info

Publication number: CN105874759B
Application number: CN201480072221.8A
Authority: CN
Inventors: 权祐奭; 高祐奭; 洪性龙; 吴世珍; 文京洙
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2014-01-03
Filing date: 2014-12-31
Publication date: 2020-01-24
Anticipated expiration: 2034-12-31
Also published as: CN105874759A; WO2015102406A1; JP6333983B2; KR20160085868A; EP3090518A4; EP3090518A1; US20170006139A1; JP2017511013A; EP3090518B1; US10523789B2; KR101857666B1

Abstract

A method and apparatus for transmitting and receiving a broadcast signal including a robust header compression (RoHC) packet stream are disclosed. The broadcast signal transmitting method includes: compressing headers of IP packets included in the IP packet stream to generate a RoHC packet stream; extracting a first portion of the RoHC packets included in the generated RoHC packet stream; converting a second portion of the RoHC packet into another type of RoHC packet; reconfiguring a new packet flow including the converted another type of RoHC packet; transmitting the reconfigured packet stream through the first channel; and transmitting the extracted first portion through a second channel.

Description

Method and apparatus for transmitting/receiving broadcast signal including robust header compressed packet stream

Technical Field

The present invention relates to transmission and reception of broadcast signals and, more particularly, to a method and/or apparatus for transmitting and receiving broadcast signals including a robust header compression (RoHC) packet stream.

Background

The IP/UDP/RTP header fields can be generally classified into static, delta, dynamic, and inferred attributes. Static is a field with a fixed value in one end to end the packet stream. This field corresponds to the IP address and the end number. In addition, this field also corresponds to a field such as an RTP or IP version field having a well-known value. A delta is a field having a fixed value that is different from the previous packet. This field corresponds to a separate number. Dynamic is a field that can be changed arbitrarily. This field corresponds to the ID and checksum of the IP packet. The inference corresponds to a field that may be inferred by other header fields such as a length field. The Context Identifier (CID) concept is introduced for conventional header compression schemes. When the compressor first transmits a packet with an uncompressed full header while adding a specific CID thereto, and transmits subsequent packets while omitting header fields with static, dynamic, or inferred attributes of the same CID, the decompressor restores all RTP headers by adding the omitted fields to a compressed header received after the second packet with reference to the initially stored header field information based on the CID. For delta headers, the compressor and decompressor store the most fields of the full header and, when the compressor transmits only the difference values from the previous packet, the decompressor corrects the difference values using the previously stored values to perform recovery.

Robust header compression (RoHC) is a standardized scheme for compressing headers such as IP, UDP, RTP and TCP. In streaming applications, IP, UDP, and RTP all have 40 bytes for IPv4 and 60 bytes for IPv6 overhead. For VoIP, this value is equivalent to 60% of all data transmitted. Such a large overhead may cause a serious problem in a wireless system having a limited bandwidth. With RoHC, 40 bytes or 60 bytes of overhead is compressed to 1 or 3 bytes and decompression is performed after delivery to the decompressor.

In RoHC, header fields are classified as static, dynamic, and inferable. The compression state in the compressor may be defined as initialization and update (IR), First Order (FO), and Second Order (SO), and the decompression state in the decompressor is defined as No Context (NC), Static Context (SC), and Full Context (FC). The RoHC scheme is to start transmission at a low compression rate and to keep a state in which transmission is performed at the highest possible compression rate. When the decompressor cannot perform context initialization or decompression, the state of the compressor returns to IR which is the lowest compression stage, and the compressor transmits the full header in this state. Subsequently, in the FO stage, the compressor omits the static fields. Finally, in the SO phase, all compressible fields are not transmitted. The state of the decompressor can change from NC, the lowest step, to SC and FC steps. At the FC step, the optimal decompression operation is performed.

RoHC performs compression in a scheme where a total header is transmitted at the beginning of transmission and unchanged portions are omitted in the middle of transmission. In case of adopting this scheme by the broadcasting system, the broadcasting receiver may not know when to receive the IP stream, and a receiver that does not know all header information may not recognize the corresponding IP packet.

Disclosure of Invention

Technical problem

An object of the present invention devised to solve the problem lies on a method and/or apparatus for transmitting and receiving a broadcast signal including a RoHC packet stream.

Another object of the present invention devised to solve the problem lies on a method of recovering packets regardless of an access time of a receiver in a unidirectional transmission system.

Another object of the present invention devised to solve the problem lies in a method of transmitting metadata related to RoHC to a decompressor in advance in a unidirectional transmission system.

Another object of the present invention devised to solve the problem lies on a method of transmitting metadata related to RoHC through a separate channel in a unidirectional transmission system.

A further object of the present invention devised to solve the problem lies on a method of extracting information to be transmitted through a separate channel from a RoHC packet stream.

Technical scheme

The object of the present invention can be achieved by providing a broadcast signal transmission method including: compressing headers of IP packets included in the IP packet stream to generate a RoHC packet stream; extracting a first portion of the RoHC packets included in the generated RoHC packet stream; converting a second portion of the RoHC packet into another type of RoHC packet; reconfiguring a new packet flow including the converted another type of RoHC packet; transmitting the reconfigured packet stream through the first channel; and transmitting the extracted first portion through a second channel.

The RoHC packet may correspond to any one selected from among: a first packet including first header information and a payload that are changed every time the packet is changed during streaming; a second packet including second header information, the first header information, and a payload that are changed at a predetermined interval as the packet is changed; and a third packet including third header information that is not changed although the packet is changed during streaming, the first header information, and the payload.

The third packet may further include second header information, the extracting step may include extracting the second header information and the third header information from the third packet included in the generated RoHC packet stream and extracting the second header information from the second packet included in the generated RoHC packet stream, and the converting step may include converting a remaining portion of the third packet excluding the extracted second header information and the extracted third header information into the first packet and converting a remaining portion of the second packet excluding the extracted second header information into the first packet.

The third packet may further include second header information, the extracting step may include extracting the third header information from the third packet included in the generated RoHC packet stream, and the converting step may include converting a remaining portion of the third packet excluding the extracted third header information into the second packet.

The extracting step may include extracting third header information from a third packet included in the generated RoHC packet stream and extracting second header information from a second packet included in the generated RoHC packet stream, and the converting step may include converting a remaining portion of the third packet excluding the extracted third header information into the first packet and converting a remaining portion of the second packet excluding the extracted second header information into the first packet.

The second channel may include a signaling channel for transmitting signaling information and a system channel for transmitting information necessary for system decoding, and at least one selected from between the extracted second header information and the extracted third header information may be transmitted through the signaling channel or the system channel.

In the case where the extracted second header information or the extracted third header information is transmitted through the signaling channel, the second header information or the third header information may be transmitted while being included in the sub-element, and the sub-element may include context identifier information and context profile information for identifying a corresponding RoHC packet flow based on the second header information or the third header information, the context profile information indicating according to which protocol headers of RoHC packets included in the corresponding RoHC packet flow based on the second header information or the third header information have been compressed.

In the case where the extracted second header information or the extracted third header information is transmitted through the system channel, the second header information or the third header information may be transmitted while being included in a payload of the packet, and the packet may include packet type information indicating type information of the packet, indicator information indicating whether information included in the payload is the second header information or the third header information, and length information indicating a length of the payload.

In another aspect of the present invention, there is provided a broadcast signal receiving method including: receiving a reconfigured packet stream through the first channel, the reconfigured packet stream being a new packet stream obtained by extracting a first portion of RoHC packets included in the RoHC packet stream; converting a second portion of the RoHC packet into another type of RoHC packet; and reconfiguring a new packet flow including the converted another type of RoHC packet; receiving the extracted first portion through a second channel; restoring the received reconfigured packet stream to the original RoHC packet stream using the received first portion; decompressing headers of the RoHC packets included in the recovered RoHC packet flow to generate an IP packet flow; and processing the generated IP packet stream to acquire broadcast data.

The third packet may further include second header information, and the recovering step may include: in a case where the second header information and the third header information received while being included in the first portion have the same sequence number, detecting a first packet having the same sequence number as the received second header information and the received third header information, and combining the received second header information and the received third header information with the detected first packet to recover the third packet, and in a case where the received second header information and the received third header information have different sequence numbers, detecting a first packet having the same sequence number as the received second header information and combining the received second header information with the detected first packet to recover the second packet, thereby recovering the received reconfigured packet stream to the original RoHC packet stream.

The third packet may further include second header information, and the recovering step may include: detecting a second packet having the same sequence number as third header information received while being included in the first portion and combining the received second header information and the detected second packet to recover the third packet, thereby recovering the received reconfigured packet stream into the original RoHC packet stream.

The recovering step may include: detecting a first packet having a same sequence number as third header information received while included in the first portion and combining the third header information with the detected first packet to recover the third packet, and detecting a first packet having a same sequence number as second header information received while included in the first portion and combining the received second header information and the detected first packet to recover the second packet, thereby recovering the received reconfigured packet stream into the original RoHC packet stream.

In another aspect of the present invention, there is provided a broadcast signal transmitting apparatus including: a RoHC compressor to compress headers of IP packets included in the IP packet stream to generate a RoHC packet stream; an extracting unit for extracting a first part of the RoHC packets included in the generated RoHC packet stream; a conversion unit for converting a second part of the RoHC packet into another type of RoHC packet; a reconfiguration unit for reconfiguring a new packet flow including the converted another type of RoHC packet; and a transmitting unit for transmitting the reconfigured packet stream through the first channel and the extracted first portion through the second channel.

In another aspect of the present invention, there is provided a broadcast signal receiving apparatus including: a first receiving unit for receiving a reconfigured packet stream, which is a new packet stream obtained by extracting a first part of RoHC packets included in the RoHC packet stream, through a first channel, converting a second part of the RoHC packets into another type of RoHC packets, and reconfiguring the new packet stream including the converted another type of RoHC packets; a second receiving unit for receiving the extracted first part through a second channel; a recovery unit for recovering the received reconfigured packet stream to an original RoHC packet stream using the received first portion; a RoHC decompressor for decompressing headers of RoHC packets included in the recovered RoHC packet stream to generate an IP packet stream; and an IP packet processing unit for processing the generated IP packet stream to acquire broadcast data.

Advantageous effects

According to the present invention, a broadcast signal including a RoHC packet stream can be transmitted and received.

According to the present invention, a transmission packet can be recovered regardless of the access time of a receiver.

According to the present invention, it is possible for a receiver to receive metadata relating to RoHC before reception of real data.

According to the present invention, RoHC-related metadata can be transmitted through a channel different from a real data transmission channel.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the principle of the invention. In the drawings:

fig. 1 illustrates a structure of an apparatus for transmitting a broadcast signal for a future broadcast service according to an embodiment of the present invention.

FIG. 2 illustrates an input formatting block according to one embodiment of the present invention.

Fig. 3 illustrates an input formatting block according to another embodiment of the present invention.

Fig. 4 illustrates an input formatting block according to another embodiment of the present invention.

Fig. 5 illustrates a BICM block according to an embodiment of the present invention.

Fig. 6 illustrates a BICM block according to another embodiment of the present invention.

Fig. 7 illustrates a frame building block according to an embodiment of the present invention.

Fig. 8 illustrates an OFMD generation block according to an embodiment of the present invention.

Fig. 9 illustrates a structure of an apparatus for receiving a broadcast signal for a future broadcast service according to an embodiment of the present invention.

Fig. 10 illustrates a frame structure according to an embodiment of the present invention.

Fig. 11 illustrates a signaling hierarchy of frames according to an embodiment of the present invention.

Fig. 12 illustrates preamble signaling data according to an embodiment of the present invention.

FIG. 13 illustrates PLS1 data according to an embodiment of the invention.

FIG. 14 illustrates PLS2 data according to an embodiment of the invention.

FIG. 15 illustrates PLS2 data according to another embodiment of the invention.

Fig. 16 illustrates a logical structure of a frame according to an embodiment of the present invention.

FIG. 17 illustrates a PLS mapping according to an embodiment of the invention.

FIG. 18 illustrates EAC mapping according to an embodiment of the present invention.

Fig. 19 illustrates an FIC mapping according to an embodiment of the present invention.

Fig. 20 illustrates the type of DP according to an embodiment of the present invention.

Fig. 21 illustrates DP mapping according to an embodiment of the present invention.

Fig. 22 illustrates an FEC structure according to an embodiment of the present invention.

Fig. 23 illustrates bit interleaving according to an embodiment of the present invention.

FIG. 24 illustrates cell-word demultiplexing according to an embodiment of the present invention.

Fig. 25 illustrates time interleaving according to an embodiment of the present invention.

FIG. 26 illustrates the basic operation of a warped row column block interleaver according to an embodiment of the present invention.

FIG. 27 illustrates the operation of a warped row column block interleaver according to another embodiment of the present invention.

FIG. 28 illustrates a diagonal wise read pattern of a warped row column block interleaver according to an embodiment of the present invention.

FIG. 29 illustrates an interleaved XFACBLOCK from each interleaving array according to an embodiment of the invention.

Fig. 30 is a diagram illustrating the structure of a robust header compression (RoHC) packet and an uncompressed Internet Protocol (IP) packet according to an embodiment of the present invention.

Fig. 31 is a view showing a concept of a RoHC packet flow according to an embodiment of the present invention.

Fig. 32 is a view illustrating a context information propagation procedure during transmission of a RoHC packet stream according to an embodiment of the present invention.

Fig. 33 is a view showing a transmitting and receiving system of an IP flow to which an IP header compression scheme is applied according to an embodiment of the present invention.

Fig. 34 is a view illustrating an IP overhead reduction process in a transmitter/receiver according to an embodiment of the present invention.

Fig. 35 is a view illustrating a procedure of reconfiguring RoHC packets to configure a new packet flow according to an embodiment of the present invention.

Fig. 36 is a view illustrating a process of converting IR packets into regular header-compressed packets in a process of reconfiguring RoHC packets to configure a new packet flow according to an embodiment of the present invention.

Fig. 37 is a view illustrating a process of converting IR-DYN packets into regular header-compressed packets in reconfiguring RoHC packets to configure a new packet stream according to an embodiment of the present invention.

Fig. 38 is a view illustrating a process of converting IR packets into IR-DYN packets in a process of reconfiguring RoHC packets to configure a new packet stream according to an embodiment of the present invention.

Fig. 39 is a view showing a procedure of configuration and recovery of a RoHC packet stream in the first configuration mode (configuration mode #1) according to an embodiment of the present invention.

Fig. 40 is a view showing a procedure of configuration and recovery of a RoHC packet stream in the second configuration mode (configuration mode #2) according to an embodiment of the present invention.

Fig. 41 is a view showing a procedure of configuration and recovery of a RoHC packet stream in the third configuration mode (configuration mode #3) according to an embodiment of the present invention.

Fig. 42 is a view illustrating a combination of information that can be delivered out-of-band according to an embodiment of the present invention.

Fig. 43 is a view showing a descriptor configuration including a static chain according to an embodiment of the present invention.

Fig. 44 is a view showing a configuration of a descriptor including a dynamic chain according to an embodiment of the present invention.

Fig. 45 is a view showing a configuration of a packet format including a static chain and a packet format including a dynamic chain according to an embodiment of the present invention.

Fig. 46 is a view illustrating a broadcast signal transmitting method according to an embodiment of the present invention.

Fig. 47 is a view illustrating a broadcast signal receiving method according to an embodiment of the present invention.

Fig. 48 is a view showing the structure of a broadcast signal transmitting apparatus according to an embodiment of the present invention.

Fig. 49 is a view showing a structure of a broadcast signal receiving apparatus according to an embodiment of the present invention.

Detailed Description

Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Detailed description will be given below with reference to the accompanying drawings, which are intended to explain exemplary embodiments of the present invention, and not to show only embodiments that can be implemented according to the present invention. The following detailed description includes specific details in order to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the invention.

Although most terms used in the present invention have been selected from conventional terms widely used in the art, some terms have been arbitrarily selected by the applicant, and their meanings are explained in detail as necessary in the following description. Accordingly, the present invention should be understood based on the intended meaning of the term, rather than its simple name or meaning.

In this specification, "signaling" indicates transmission/reception of Service Information (SI) provided through a broadcasting system, an internet broadcasting system, and/or a broadcasting/internet convergence system. The service information includes broadcast service information (e.g., ATSC-SI and/or DVB-SI) provided through an existing broadcasting system.

In the present specification, "broadcast signal" is defined to include a concept of signals and/or data provided in a bi-directional broadcast such as an internet broadcast, a broadband broadcast, a communication broadcast, a data broadcast, and/or a Video On Demand (VOD) in addition to a terrestrial broadcast, a cable broadcast, a satellite broadcast, and/or a mobile broadcast.

In this specification, "PLP" means a fixed unit for transmitting data belonging to a physical layer. Thus, an element named "PLP" may also be named "data unit" or "data pipe".

One of powerful applications utilized in a digital broadcasting (DTV) service may be a hybrid broadcasting service based on an interlock between a broadcasting network and an internet network. In the hybrid broadcast service, it is possible to,

transmitting enhanced data associated with broadcast audio/video (a/V) content transmitted through a terrestrial broadcast network or a portion of the broadcast a/V content in real time through an internet network enables a user to experience various contents.

An object of the present invention is to propose a method of encapsulating an IP packet, an MPEG-2TS packet, and a packet that can be used in other broadcasting systems so that the packet can be delivered to a physical layer in a next generation digital broadcasting system. In addition, the present invention also proposes a method of transmitting layer 2 signaling in the same header format.

The following process can be implemented by the apparatus. For example, the signaling processing unit, the protocol processing unit, the processor, and/or the packet generating unit may perform the following processes.

The present invention provides an apparatus and method for transmitting and receiving a broadcast signal for a future broadcast service. Future broadcast services according to embodiments of the present invention include terrestrial broadcast services, mobile broadcast services, UHDTV services, and the like.

The apparatus and method for transmission according to an embodiment of the present invention can be classified into a basic profile for a terrestrial broadcast service, a handheld profile for a mobile broadcast service, and an advanced profile for a UHDTV service. In this case, the basic profile can be used as a profile for a terrestrial broadcast service and a mobile broadcast service. That is, the basic profile can be used to define the concept of a profile that includes a mobile profile. This can be changed according to the intention of the designer.

The present invention may process broadcast signals for future broadcast services through non-MIMO (multiple input multiple output) or MIMO according to one embodiment. The non-MIMO scheme according to an embodiment of the present invention may include a MISO (multiple input single output), a SISO (single input single output) scheme, and the like.

Although MISO or MIMO uses two antennas for convenience of description hereinafter, the present invention is applicable to a system using two or more antennas.

The present invention may define that three Physical Layer (PL) profiles (base, handheld, and advanced profiles) are each optimized to minimize receiver complexity while achieving the performance required for a particular use case. The physical layer (PHY) profile is a subset of all configurations that the corresponding receiver will implement.

The three PHY profiles share most of the functional blocks, but differ slightly in specific modules and/or parameters. Additional PHY profiles may be defined in the future. For system evolution, future attributes may also be multiplexed with existing profiles in a single RF channel via Future Extended Frames (FEFs). Details of each PHY profile are described below.

1. Base profile

The base profile represents the primary use case for a fixed receiving device that is typically connected to a rooftop antenna. The base profile also includes portable devices that can be transported to a location, but that belong to a relatively fixed reception category. The use of the base profile may be extended to handheld devices or even vehicles with some improved implementation, however, those use cases are not anticipated for base profile receiver operation.

The target SNR for reception ranges from about 10 to 20dB, which includes the 15dB SNR reception capability of existing broadcast systems (e.g., ATSC a/53). Receiver complexity and power consumption are not as severe as in battery operated handheld devices, which would use a handheld profile. The key system parameters for the base profile are listed in table 1 below.

TABLE 1

[ Table 1]

LDPC codeword length	16K, 64K bits
		Constellation size
	4 ~ 10bpcu (bit for each channel)
		Time deinterleaving memory size	≤2¹⁹Data cell
Pilot pattern	Pilot pattern for fixed reception
		FFT size	16K, 32K point

2. Hand-held profile

Handheld profiles are designed for use in handheld and vehicle-mounted devices that operate on battery power. The device may be moving at pedestrian or vehicular speed. Power consumption and receiver complexity are very important for the implementation of a handheld profile device. The target SNR range for the handheld profile is approximately 0 to 10dB, but can be configured to reach below 0dB when intended for deeper indoor reception.

In addition to low SNR capability, the adaptability of the doppler effect caused by receiver mobility is the most important performance quality of the handheld profile. Key system parameters for the handheld profile are listed in table 2 below.

TABLE 2

[ Table 2]

LDPC codeword length	16K bits
		Constellation size
	2～8bpcu
		Time deinterleaving memory size	≤2¹⁸Data cell
Pilot pattern	Pilot patterns for mobile and indoor reception
		FFT size	8K, 16K point

3. Advanced profiles

Advanced profiles provide the highest channel capacity at the expense of greater implementation complexity. The profile needs to use MIMO transmission and reception, and UHDTV service is a target use case specifically designed for the profile. The increased capacity may also be used to allow an increased number of services at a given bandwidth, for example, multiple SDTV or HDTV services.

The target SNR range for the advanced profile is approximately 20 to 30 dB. MIMO transmission may initially use existing elliptically polarized transmission equipment and in the future extend to full power transversely polarized transmission. Key system parameters for the advanced profile are listed in table 3 below.

TABLE 3

[ Table 3]

LDPC codeword length	16K, 64K bits
		Constellation size
	8～12bpcu
		Time deinterleaving memory size	≤2¹⁹Data cell
Pilot pattern	Pilot pattern for fixed reception
		FFT size	16K, 32K point

In such a case, the base profile can be used as a profile for both a terrestrial broadcast service and a mobile broadcast service. That is, the base profile can be used to define the concept of a profile that includes a mobile profile. Also, the high-level profile can be divided into a high-level profile for a basic profile with MIMO and a high-level profile for a handheld profile with MIMO. Further, the three profiles can be changed according to the designer's intention.

The following terms and definitions may apply to the present invention. The following terms and definitions can be changed according to design.

Auxiliary flow: a sequence of information elements carrying data with modulation and coding not yet defined, which can be used for future extension or by broadcaster or network operator requirements;

basic data pipeline: a data pipe carrying service signaling data;

baseband frame (or BBFRAME): forming a set of input Kbch bits to one FEC encoding process (BCH and LDPC encoding);

cell: modulation value carried by one carrier of an OFDM transmission;

the block to be encoded: one of an LDPC coded block of PLS1 data or an LDPC coded block of PLS2 data;

a data pipeline: a logical channel in the physical layer carrying service data or related metadata, which may carry one or more services or service components.

A data pipeline unit: a basic unit for allocating data cells to DPs in a frame.

Data symbol: OFDM symbols that are not preamble symbols in the frame (frame signaling symbols and frame edge symbols are included in the data symbols);

DP _ ID: this 8-bit field uniquely identifies the DP within the system identified by SYSTME _ ID;

dummy cells: carrying an element of a pseudo-random value used to fill the remaining capacity not used for PLS signalling, DP or auxiliary streams;

emergency alert channel: a portion of a frame carrying EAS information data;

frame: a physical layer slot starting with a preamble and ending with a frame-edge symbol;

a frame repetition unit: a set of frames belonging to the same or different physical layer profiles including FETs, which are repeated eight times in a super frame;

fast information channel: a logical channel in a frame carrying mapping information between a service and a corresponding basic DP;

FECBLOCK: a set of LDPC encoded bits of DP data;

FFT size: a nominal FFT size, used for a particular mode, equal to the active symbol period Ts expressed in the period of the base period T;

frame signaling symbol: in some combination of FFT size, guard interval and scattered pilot pattern, the OFDM symbol with higher pilot density used at the beginning of the frame, which carries part of the PLS data;

frame edge symbol: OFDM symbols with higher pilot density used at the end of the frame in some combination of FFT size, guard interval, and scattered pilot pattern;

frame group: a set of all frames in a superframe having the same PHY profile type.

Future extension frame: a physical layer slot within a superframe that can be used for future extensions, starting with a preamble;

futurecast UTB system: proposed physical layer broadcast system whose input is one or more MPEG2-TS or IP or general streams and whose output is an RF signal;

inlet flow: a stream of data for the ensemble of services delivered to the end user through the system.

Normal data symbols: excluding data symbols for frame signaling and frame edge symbols;

PHY Profile: a subset of all configurations that the corresponding receiver should implement;

PLS: physical layer signalling data consisting of PLS1 and PLS 2;

PLS 1: a first set of PLS data carried in FSS symbols of fixed size, coding and modulation, carrying basic information about the system and parameters required for decoding PLS 2;

note that: PLS1 data is kept constant for the duration of a frame group.

PLS 2: a second set of PLS data transmitted in FSS symbols carrying more detailed PLS data about the system and the DP;

PLS2 dynamic data: PLS2 data which may change dynamically frame by frame;

PLS2 static data: maintaining static PLS2 data for the duration of a frame group;

preamble signaling data: signalling data carried by the preamble symbols and used to identify a basic mode of the system;

leading symbol: fixed length pilot symbols carrying primary PLS data and located at the beginning of a frame;

note that: the preamble symbols are mainly used for fast initial band scanning to detect the system signal, its timing, frequency offset, and FFT size.

Reserved for future use: this document does not define but may define in the future;

superframe: a set of eight frame repeat units;

time interleaving block (TI block): a set of cells in which time interleaving is performed, corresponding to one use of a time interleaver memory;

group TI: the unit on which dynamic capacity allocation for a particular DP is performed, consisting of integers, dynamically changes the number of XFECBLOCKs.

Note that: the TI group may be directly mapped to one frame or may be mapped to a plurality of frames. Which may contain one or more TI blocks.

Type 1 DP: wherein all DPs are mapped to the DPs of the frames of the frame in a TDM manner;

type 2 DP: wherein all DPs are mapped to DPs of a frame of the frame in an FDM manner;

XFCBLOCK: a set of Ncell cells carrying all bits of one LDPC FECBLOCK.

Fig. 1 illustrates a structure of a broadcast signal apparatus for transmitting a broadcast service for a future broadcast service according to an embodiment of the present invention.

An apparatus for transmitting a broadcast signal for a future broadcast service according to an embodiment of the present invention may include an input formatting block 1000, a BICM (bit interleaved coding and modulation) block 1010, a frame construction block 1020, an OFDM (orthogonal frequency division multiplexing) generation block 1030, and a signaling generation block 1040. A description will be given of the operation of each module of the apparatus for transmitting broadcast signals.

IP streams/packets and MPEG2-TS are the main input formats, other stream types are handled as regular streams. In addition to these data inputs, management information is input to control the scheduling and allocation of the respective bandwidth for each input stream. One or more TS streams, IP streams, and/or regular streams are simultaneously allowed to be input.

The input formatting block 1000 is capable of demultiplexing each input stream into one or more data pipes, to each of which a separate coding and modulation is applied. The Data Pipe (DP) is a basic unit for robust control, thereby affecting quality of service (QoS). One or more services or service components may be carried by a single DP. Details of the operation of the input formatting block 1000 will be described later.

A data pipe is a logical channel in the physical layer that carries service data or related metadata, which may carry one or more services or service components.

Further, the data pipe unit: in the frame for allocating data cells to the elementary units of the DP.

In the BICM block 1010, parity data is added for error correction and the encoded bit stream is mapped to complex-valued constellation symbols. The symbols are interleaved across a particular interleaving depth for the corresponding DP. For advanced profiles, MIMO encoding is performed in the BICM block 1010 and additional data paths are added at the output for MIMO transmission. Details of the operation of the BICM block 1010 will be described later.

Frame building block 1020 may map data cells of the incoming DP to OFDM symbols within a frame. After mapping, frequency interleaving is used for frequency domain diversity, in particular, to combat frequency selective fading channels. Details of the operation of the frame building block 1020 will be described later.

After inserting a preamble at the beginning of each frame, the OFDM generation block 1030 may apply conventional OFDM modulation with a cyclic prefix as a guard interval. For antenna spatial diversity, a distributed MISO scheme is applied throughout the transmitter. Furthermore, a peak-to-average power reduction (PAPR) scheme is performed in the time domain. For flexible network planning, this proposal provides a set of different FFT sizes, guard interval lengths and corresponding pilot patterns. The details of the operation of the OFDM generation block 1030 will be described later.

The signaling generation block 1040 is capable of creating physical layer signaling information for each functional block operation. The signaling information is also sent so that the service of interest is properly recovered at the receiver side. Details of the operation of the signaling generation block 1040 will be described later.

Fig. 2, 3 and 4 illustrate an input formatting block 1000 according to an embodiment of the present invention. A description will be given of each figure.

FIG. 2 illustrates an input formatting block according to one embodiment of the present invention. Fig. 2 shows the input formatting module when the input signal is a single input stream.

The input formatting block illustrated in fig. 2 corresponds to an embodiment of the input formatting block 1000 described with reference to fig. 1.

The input to the physical layer may consist of one or more data streams. Each data stream is carried by one DP. The mode adaptation module restricts (slice) the incoming data stream to data fields of a baseband frame (BBF). The system supports three types of input data streams: MPEG2-TS, Internet Protocol (IP), and regular stream (GS). MPEG2-TS is characterized as a fixed length (188 byte) packet, the first byte being a sync byte (0x 47). An IP flow consists of variable length IP datagram packets as signaled within the IP packet header. The system supports both IPv4 and IPv6 for IP flows. The GS may consist of either variable length packets or fixed length packets signaled within the encapsulation packet header.

(a) A mode adaptation block 2000 and a stream adaptation 2010 for the signal DP are shown, and (b) a PLS generation block 2020 and a PLS scrambler 2030 for generating and processing PLS data are shown. A description will be given of the operation of each block.

The input stream splitter splits the input TS, IP, GS streams into multiple services or service component (audio, video, etc.) streams. The mode adaptation module 2010 is composed of a CRC encoder, a BB (baseband) frame limiter, and a BB frame header insertion block.

The CRC encoder provides three types of CRC encoding for error detection at the User Packet (UP) level, namely CRC-8, CRC-16, and CRC-32. The calculated CRC byte is appended after UP. CRC-8 is used for TS streams and CRC-32 is used for IP streams. If the GS stream does not provide CRC encoding, the proposed CRC encoding will be applied.

The BB frame limiter maps the input to an internal logical bit format. The first received bit is defined as the MSB. The BB frame limiter allocates a number of input bits equal to the available data field capacity. To allocate a number of input bits equal to the BBF payload, the UP packet stream is restricted to fit in the data field of the BBF.

The BB frame header insertion module may insert a fixed length BBF header of 2 bytes in front of the BB frame. The BBF header is composed of STUFFI (1 bit), SYNCD (13 bits), and RFU (2 bits). In addition to the fixed 2-byte BBF header, the BBF may also have an extension field (1 or 3 bytes) at the end of the 2-byte BBF header.

Stream adaptation 2010 consists of a padding insertion block and a BB scrambler.

The padding insertion block can insert a padding field into the payload of the BB frame. If the input data to the stream adaptation is sufficient to fill a BB frame, then STUFFI is set to "0" and BBF does not fill a field. Otherwise, the STUFFI is set to "1", and the padding field is inserted immediately after the BBF header. The pad field includes a two-byte pad field header and variable-size pad data.

The BB scrambler scrambles the completed BBF for energy spreading. The scrambling sequence is synchronized with the BBF. The scrambling sequence is generated by a feedback shift register.

The PLS generation block 2020 may generate Physical Layer Signalling (PLS) data. PLS provides the receiver with a means to access the physical layer DP. The PLS data consists of PLS1 data and PLS2 data.

PLS1 data is a first set of PLS data carried, coded and modulated in FSS symbols in frames with a fixed size, which carries essential information about the systems and parameters needed to decode PLS2 data. PLS1 data provides basic transmission parameters including the parameters required to allow reception and decoding of PLS2 data. In addition, PLS1 data remains unchanged for the duration of the frame group.

PLS2 data is a second set of PLS data sent in FSS symbols carrying more detailed PLS data for relations and DPs. PLS2 contains parameters that provide sufficient information for the receiver to decode the desired DP. The PLS2 signalling further consists of two types of parameters, PLS2 static data (PLS2-STAT data) and PLS2 dynamic data (PLS2-DYN data). PLS2 static data is PLS2 data that remains static for the frame group duration, and PLS2 dynamic data is PLS2 data that may change dynamically from frame to frame.

Details of the PLS data will be described later.

The PLS scrambler 2030 may scramble the generated PLS data for energy spreading.

Blocks described above may be omitted or replaced by blocks having similar or identical functions.

The input formatting block illustrated in fig. 3 corresponds to an embodiment of the input formatting block 1000 described with reference to fig. 1.

Fig. 3 illustrates a mode adaptation block of an input formatting block when an input signal corresponds to a plurality of input streams.

The mode adaptation block for processing the input formatting block for multiple input streams may independently process multiple input streams.

Referring to fig. 3, the mode adaptation block for separately processing a plurality of input streams may include an input stream splitter 3000, an input stream synchronizer 3010, a compensation delay block 3020, a null packet deletion block 3030, a header compression block 3040, a CRC encoder 3050, a BB frame limiter (slicer)3060, and a BB header insertion block 3070. A description will be given of each block of the mode adaptation block.

The operations of the CRC encoder 3050, the BB frame limiter 3060, and the BB header insertion block 3070 correspond to the operations of the CRC encoder, the BB frame limiter, and the BB header insertion block described with reference to fig. 2, and thus, descriptions thereof are omitted.

The input stream splitter 3000 may split an input TS, IP, GS stream into multiple services or service component (audio, video, etc.) streams.

The input stream synchronizer 3010 may be referred to as ISSY. ISSY may provide a convenient means for any input data format to guarantee a Constant Bit Rate (CBR) and a constant end-to-end transmission delay. ISSY is always used for the case of multiple DPs carrying TS and is selectively used for multiple DPs carrying GS streams.

The compensating delay block 3020 may delay splitting the TS packet stream after insertion of ISSY information to allow for a TS packet reassembly mechanism without additional memory in the receiver.

The null packet deletion block 3030 is used only for TS input stream situations. Some TS input streams or divided TS streams may have a large number of null packets present in order to provide VBR (variable bit rate) services in CBR TS streams. In this case, in order to avoid unnecessary transmission overhead, null packets may be identified and not transmitted. In the receiver, the removed null packets can be re-inserted in their original exact positions by referring to a Deleted Null Packet (DNP) counter inserted in the transmission, thereby guaranteeing a constant bit rate and avoiding the need for timestamp (PCR) updates.

The header compression block 3040 may provide packet header compression to improve transmission efficiency for TS or IP input streams. Since the receiver may have a priori information about some part of the header, this known information may be deleted in the transmitter.

For a transport stream, the receiver has a priori information about the sync byte configuration (0x47) and the packet length (188 bytes). If the incoming TS stream carries content with only one PID, i.e. for only one service component (video, audio, etc.) or service subcomponent (SVC base layer, SVC enhancement layer, MVC base view or MVC related view), TS packet header compression can be (selectively) applied to the transport stream. If the input stream is an IP stream, IP packet header compression is selectively used.

The modules described above may be omitted or replaced by blocks having similar or identical functions.

The input formatting module illustrated in fig. 4 corresponds to an embodiment of the input formatting block 1000 described with reference to fig. 1.

Fig. 4 illustrates a stream adaptation module of an input formatting module when an input signal corresponds to a plurality of input streams.

Referring to fig. 4, a mode adaptation module for processing a plurality of input streams, respectively, may include a scheduler 4000, a 1-frame delay block 4010, a padding insertion block 4020, in-band signaling 4030, a BB frame scrambler 4040, a PLS generation block 4050, and a PLS scrambler 4060. A description will be given of each block of the stream adaptation module.

The operations of the padding insertion block 4020, the BB frame scrambler 4040, the PLS generation block 4050, and the PLS scrambler 4060 correspond to the operations of the padding insertion block, the BB scrambler, the PLS generation block, and the PLS scrambler described with reference to fig. 2, and thus, descriptions thereof are omitted.

Scheduler 4000 may determine the overall cell allocation across the entire frame from the amount of FECBLOCK (FEC block) per DP. Including the allocation for PLS, EAC and FIC, the scheduler generates a value for PLS2-DYN data, which is sent as a PLS cell or in-band signaling in the FSS of the frame. Details of FECBLOCK, EAC, and FIC will be described later.

The 1-frame delay block 4010 may delay the input data by one transmission frame so that scheduling information on a next frame can be transmitted via a current frame for in-band signaling information to be inserted into the DP.

In-band signaling 4030 may insert an undelayed portion of PLS2 data into the DP of a frame.

The BICM block illustrated in fig. 5 corresponds to an embodiment of the BICM block 1010 described with reference to fig. 1.

As described above, an apparatus for transmitting a broadcast signal for a future broadcast service according to an embodiment of the present invention can provide a terrestrial broadcast service, a mobile broadcast service, a UHDTV service, and the like.

Since QoS (quality of service) depends on service characteristics provided by an apparatus for transmitting broadcast signals for a future broadcast service according to an embodiment of the present invention, data corresponding to the respective services need to be processed via different schemes. Accordingly, the BICM block according to an embodiment of the present invention can independently process a DP input thereto by independently applying SISO, MISO, and MIMO schemes to data pipes respectively corresponding to data paths. Accordingly, the apparatus for transmitting a broadcast signal for a future broadcast service according to an embodiment of the present invention can control the QoS of each service or service component transmitted via each DP.

(a) Shows BICM blocks shared by the base profile and the handheld profile, and (b) shows BICM modules of the advanced profiles.

The BICM block shared by the base profile and the handheld profile and the BICM block of the advanced profile can include a plurality of processing blocks for processing each DP.

A description will be given of each processing module of the BICM block for the base profile and the handheld profile and the BICM block for the advanced profile.

The processing block 5000 of the BICM blocks for the base profile and the hand-held profile may include a data FEC encoder 5010, a bit interleaver 5020, a constellation mapper 5030, an SSD (signal space diversity) coding block 5040, and a time interleaver 5050.

Data FEC encoder 5010 can perform FEC encoding on the input BBF using outer coding (BCH) and inner coding (LDPC) to produce a FECBLOCK process. Outer coding (BCH) is an alternative coding method. Details of the operation of the data FEC encoder 5010 will be described later.

The bit interleaver 5020 may interleave the output of the data FEC encoder 5010 in a combination of LDPC coding and modulation schemes to achieve optimized performance while providing an efficiently executable architecture. Details of the operation of the bit interleaver 5020 will be described later.

The constellation mapper 5030 may modulate each cell word (cell word) from the bit interleaver 5020 in the base and handheld profiles, or cell word from the cell word demultiplexer 5010-1 in the advanced profiles, using QPSK, QAM-16, non-uniform QAM (NUQ-64, NUQ-256, NUQ-1024), or non-uniform constellation (NUC-16, NUC-64, NUC-256, NUC-1024) to give power normalized constellation points el. This constellation mapping is only applicable to DP. Note that QAM-16 and NUQ are square in shape, while NUC has an arbitrary shape. When each constellation is rotated by any multiple of 90 degrees, the rotated constellation overlaps exactly one of its original. This "sense of rotation" symmetry property makes the capacity and average power of the real and imaginary components equal to each other. For each code rate, both NUQ and NUC are specifically defined, and the particular one used is signaled by a parameter DP _ MOD archived in PLS2 data.

SSD coding block 5040 can precode cells in two dimensions (2D), three dimensions (3D), and four dimensions (4D) to improve robustness of reception under difficult fading conditions.

The time interleaver 5050 may operate at the DP level. The parameter of the Time Interleaving (TI) may be set differently for each DP. Details of the operation of the time interleaver 5050 will be described later.

The processing block 5000-1 for the BICM block of the high level profile may include a data FEC encoder, a bit interleaver, a constellation mapper, and a time interleaver. However, unlike processing block 5000, processing module 5000-1 further includes cell word demultiplexer 5010-1 and MIMO encoding module 5020-1.

Further, the operations of the data FEC encoder, the bit interleaver, the constellation mapper, and the time interleaver in processing block 5000-1 correspond to the operations of the data FEC encoder 5010, the bit interleaver 5020, the constellation mapper 5030, and the time interleaver 5050 described, and thus, the description thereof is omitted.

The cell word demultiplexer 5010-1 is used for DP of the high level profile to divide the single cell word stream into dual cell word streams for MIMO processing. Details of the operation of the cell word demultiplexer 5010-1 will be described later.

The MIMO encoding module 5020-1 can process the output of the cell word demultiplexer 5010-1 using a MIMO encoding scheme. The MIMO coding scheme is optimized for broadcast signal transmission. MIMO technology is a desirable way to achieve performance improvement, but it depends on channel characteristics. Especially for broadcasting, a strong LOS component of the channel or a difference in received signal power between two antennas caused by different signal propagation characteristics makes it difficult to obtain a performance gain from MIMO. The proposed MIMO encoding scheme overcomes this problem using rotation-based precoding and phase randomization of one of the MIMO output signals.

MIMO coding is intended for 2x2MIMO systems that require at least two antennas at both the transmitter and receiver. Under this proposal two MIMO coding modes are defined: full-rate spatial multiplexing (FR-SM) and full-rate full-diversity spatial multiplexing (FRFD-SM). FR-SM coding provides performance improvement with a relatively small complexity increase at the receiver side, while FRFD-SM coding provides performance improvement and additional diversity gain with a large complexity increase at the receiver side. The proposed MIMO coding scheme does not impose restrictions on the antenna polarization configuration.

MIMO processing is required for the high-level profile frame, which refers to all DPs processed in the high-level profile frame by the MIMO encoder. MIMO processing is applicable at the DP level. Constellation mapper pair output NUQ (e)_1,iAnd e_2,i) Is fed to the input of a MIMO encoder. The paired MIMO encoder outputs (g1, i and g2, i) are transmitted by the same carrier k and OFDM symbol l of their respective TX antennas.

The above-described modules may be omitted or replaced with modules having similar or identical functions.

The BICM block illustrated in fig. 6 corresponds to an embodiment of the BICM block 1010 described with reference to fig. 1.

Fig. 6 illustrates BICM blocks for protecting Physical Layer Signaling (PLS), an Emergency Alert Channel (EAC), and a Fast Information Channel (FIC). The EAC is a portion of a frame carrying EAS information data, and the FIC is a logical channel in the frame carrying mapping information between the service and the corresponding basic DP. Details of EAC and FIC will be described later.

Referring to fig. 6, a BICM block for protecting PLS, EAC, and FIC may include a PLS FEC encoder 6000, a bit interleaver 6010, a constellation mapper 6020, and a time interleaver 6030.

Further, the PLS FEC encoder 6000 may include a scrambler, a BCH encoding/zero insertion block, an LDPC coding block, and an LDPC parity puncturing block. A description will be given of each block of the BICM block.

A PLS FEC encoder 6000 may encode the scrambled PLS 1/2 data, EAC and FIC sections.

The scrambler may scramble PLS1 data and PLS2 data prior to BCH encoding and shortening and puncturing LDPC encoding.

The BCH encoding/zero insertion block may perform outer encoding on the scrambled PLS 1/2 data using a shortened BCH code for PLS protection and insert zero bits after BCH encoding. For PLS1 data only, the zero-inserted output bits may be transposed before LDPC encoding.

The LDPC coding block may use the LDPC code to code the output of the BCH coding/zero insertion block. To generate a complete codeModule, C_ldpcParity bit, P_ldpcPLS information blocks I inserted from each zero_ldpcIs system coded and appended thereto.

Mathematical formula 1

[ mathematical formula 1]

The LDPC coding parameters for PLS1 and PLS2 are as in table 4 below.

TABLE 4

[ Table 4]

The LDPC parity puncturing block may perform puncturing on PLS1 data and PLS2 data.

When shortening is applied to PLS1 data protection, some LDPC parity bits are punctured after LDPC encoding. Further, for PLS2 data protection, the LDPC parity bits of PLS2 are punctured after LDPC encoding. These punctured bits are not sent.

Bit interleaver 6010 may interleave each of the shortened and punctured PLS1 data and PLS2 data.

A constellation mapper 6020 may map the bit interleaved PLS1 data and PLS2 data onto a constellation.

A time interleaver 6030 is able to interleave the mapped PLS1 data and PLS2 data.

The frame building blocks illustrated in fig. 7 correspond to an embodiment of the frame building blocks 1020 described with reference to fig. 1.

Referring to fig. 7, the frame construction block may include a delay compensation block 7000, a cell mapper 7010, and a frequency interleaver 7020. A description will be given of each block of the frame building block.

The delay compensation block 7000 can adjust the timing between the data pipes and the corresponding PLS data to ensure that they are co-timed (co-timed) at the transmitter side. By accounting for the delay of the data pipe caused by the input formatting block and the BICM block, the PLS data is delayed by the same amount as the data pipe. The delay of the BICM block is mainly due to the time interleaver. The inband signaling data carries the information of the next TI group so that they carry one frame before the DP to be signaled. Accordingly, the delay compensation block delays the in-band signaling data.

The cell mapper 7010 may map PLS, EAC, FIC, DP, auxiliary streams, and dummy cells to active carriers of OFDM symbols in the frame. The basic function of the cell mapper 7010 is to map data cells resulting from TI for each of DP, PLS cells, and EAC/FIC cells, if any, to active OFDM cells corresponding to each of the OFDM symbols within a frame. Service signaling data, such as PSI (program specific information)/SI, can be collected separately and sent over the data pipe. The cell mapper operates according to the dynamic information generated by the scheduler and the configuration of the frame structure. The details of the frame will be described later.

The frequency interleaver 7020 may randomly interleave the data cells received from the cell mapper 7010 to provide frequency diversity. In addition, frequency interleaver 7020 may operate on a unique OFDM symbol pair consisting of two OFDM symbols in order using different interleaving seed orders to obtain the largest interleaving gain in a single frame.

Fig. 8 illustrates an OFDM generation block according to an embodiment of the present invention.

The OFDM generation block illustrated in fig. 8 corresponds to an embodiment of the OFDM generation block 1030 described with reference to fig. 1.

The OFDM generation block modulates an OFDM carrier by the cell generated by the frame construction block, inserts a pilot, and generates a time domain signal for transmission. Further, this block then inserts a guard interval and applies PAPR (peak to average power ratio) reduction processing to generate a final RF signal.

Referring to fig. 8, the frame construction block may include a pilot and reserved tone insertion block 8000, a 2D-eSFN coding block 8010, an IFFT (inverse fast fourier transform) block 8020, a PAPR reduction block 8030, a guard interval insertion block 8040, a preamble insertion module 8050, an other system insertion block 8060, and a DAC block 8070. A description will be given of each block of the frame building block.

The pilot and reserved tone insertion block 8000 may insert pilot and reserved tones.

The various cells within an OFDM symbol are modulated with reference information, called pilots, which have transmitted values that are previously known in the receiver. The information of the pilot cell consists of scattered pilots, continual pilots, edge pilots, FSS (frame signaling symbol) pilots, and FES (frame edge symbol) pilots. Each pilot is transmitted at a particular boosted power level based on the pilot type and pilot pattern. The value of the pilot information is derived from the reference sequence, which is a series of values, one for each transmitted carrier on any given symbol. The pilot may be used for frame synchronization, frequency synchronization, time synchronization, channel estimation, and transmission pattern identification, and may also be used to follow phase noise.

The reference information extracted from the reference sequence is transmitted in scattered pilot cells in each symbol except for the preamble, FSS and FES of the frame. A continuous pilot is inserted in each symbol of the frame. The number and location of the continual pilots depends on both the FFT size and the scattered pilot pattern. Edge carriers are edge pilots in each symbol except the preamble symbol. They are inserted to allow frequency interpolation up to the edges of the spectrum. The FSS pilot is inserted in the FSS and the FES pilot is inserted in the FES. They are inserted to allow temporal interpolation up to the edges of the frame.

The system according to embodiments of the present invention supports SFN networks where the distributed MISO scheme is selectively used to support very robust transmission modes. The 2D-eSFN is a distributed MISO scheme using multiple TX antennas, each located at a different transmitter location in the SFN network.

The 2D-eSFN coding block 8010 may process the 2D-eSFN processing to distort the phase of signals transmitted from multiple transmitters to create both time and frequency diversity in an SFN configuration. Therefore, burst errors due to low flat fading or deep fading for a long time can be mitigated.

The IFFT block 8020 may modulate the output from the 2D-eSFN coding block 8010 using an OFDM modulation scheme. Any cell in the data symbols not designated as pilot (or reserved tone) carries one of the data cells from the frequency interleaver. The cell is mapped to an OFDM carrier.

The PAPR reduction block 8030 may perform PAPR reduction on the input signal using various PAPR reduction algorithms in the time domain.

The guard interval insertion block 8040 may insert a guard interval, and the preamble insertion block 8050 may insert a preamble in front of the signal. Details of the structure of the preamble will be described later. Another system insertion block 8060 may multiplex signals of a plurality of broadcast transmission/reception systems in a time domain so that data of two or more different broadcast transmission/reception systems providing a broadcast service can be simultaneously transmitted in the same RF signal bandwidth. In this case, two or more different broadcast transmission/reception systems refer to systems providing different broadcast services. The different broadcast services may refer to terrestrial broadcast services, mobile broadcast services, and the like. Data related to the corresponding broadcast service may be transmitted via different frames.

The DAC block 8070 may convert an input digital signal into an analog signal and output the analog signal. The signals output from the DAC block 7800 may be transmitted via a plurality of output antennas according to the physical layer profile. The Tx antenna according to an embodiment of the present invention may have vertical or horizontal polarization.

The blocks described above may be omitted or replaced by blocks having similar or identical functions according to design.

An apparatus for receiving a broadcast signal for a future broadcast service according to an embodiment of the present invention may correspond to the apparatus for transmitting a broadcast signal for a future broadcast service described with reference to fig. 1.

An apparatus for receiving a broadcast signal for a future broadcast service according to an embodiment of the present invention may include a synchronization and demodulation module 9000, a frame parsing module 9010, a demapping and decoding module 9020, an output processor 9030, and a signaling decoding module 9040. A description will be given of the operation of each module of the apparatus for receiving a broadcast signal.

The synchronization and demodulation module 9000 may receive input signals via m Rx antennas, perform signal detection and synchronization with respect to a system corresponding to an apparatus for receiving broadcast signals, and perform demodulation corresponding to a process reverse to that performed by the means for transmitting broadcast signals.

The frame parsing module 9010 may parse the input signal frame and extract data through which the service selected by the user is transmitted. If the device for transmitting the broadcast signal performs interleaving, the frame parsing module 9010 may perform deinterleaving corresponding to a reverse process of the interleaving. In this case, the location of the signal and data that need to be extracted may be obtained by decoding the data output from the signaling decoding module 9040 to recover the scheduling information generated by the device for transmitting the broadcast signal.

The demapping and decoding module 9020 may convert the input signal into bit-domain data and then deinterleave it as needed. The demapping and decoding module 9020 may perform demapping on mapping applied for transmission efficiency and correct errors generated on a transmission channel via decoding. In this case, the demapping and decoding module 9020 may obtain transmission parameters necessary for demapping and decode by decoding data output from the signaling decoding module 9040.

The output processor 9030 may perform a reverse process of various compression/signal processing processes applied by a device for transmitting a broadcast signal to improve transmission efficiency. In this case, the output processor 9030 may obtain necessary control information from the data output from the signaling decoding module 9040. The output of the output processor 8300 corresponds to a signal input to the apparatus for transmitting a broadcast signal, and may be an MPEG-TS, an IP stream (v4 or v6), and a normal stream.

The signaling decoding module 9040 may obtain PLS information from the signal demodulated by the synchronization and demodulation module 9000. As described above, the frame parsing module 9010, the demapping and decoding module 9020 and the output processor 9030 may perform their functions using data output from the signaling decoding module 9040.

Fig. 10 illustrates an example configuration of frame types and FRUs in a superframe, (a) illustrates a superframe according to an embodiment of the present invention, (b) illustrates a FRU (frame repeat unit) according to an embodiment of the present invention, (c) illustrates frames of a variable PHY profile in a FRU, and (d) illustrates the structure of the frames.

A superframe may consist of eight FRUs. The FRU is a basic multiplexing unit for TDM of a frame and is repeated eight times in a superframe.

Each frame in the FRU belongs to one of the PHY profiles (base, handheld, advanced) or FEF. The maximum allowed number of frames in a FRU is four, and a given PHY profile may occur anywhere from zero to four times in a FRU (e.g., base, handheld, advanced). The PHY PROFILE definition may be extended with the reserved value of PHY _ PROFILE in the preamble, if desired.

The FEF portion is inserted at the end of the FRU, if included. When the FEF is included in the FRU, the minimum number of FEFs in a superframe is 8. It is not recommended that the FEF portions be adjacent to each other.

One frame is further divided into a number of OFDM symbols and preambles. As shown in (d), a frame includes a preamble, one or more Frame Signaling Symbols (FSS), a normal data symbol, and a Frame Edge Symbol (FES).

The preamble is a special symbol that allows fast Futurecast UTB system signal detection and provides a set of basic transmission parameters for efficient transmission and reception of signals. The detailed description of the preamble will be described later.

The primary purpose of the FSS is to carry PLS data. For fast synchronization and channel estimation and thus fast decoding of PLS data, the FSS has a more dense pilot pattern than ordinary data symbols. The FES has exactly the same pilots as the FSS, which allows for frequency-only interpolation within the FES, and time interpolation for symbols immediately preceding the FES without extrapolation.

Fig. 11 illustrates a signaling hierarchy, which is partitioned into three main parts: preamble signaling data 11000, PLS1 data 11010, and PLS2 data 11020. The purpose of the preamble carried by the preamble symbol in each frame is to indicate the transmission type and basic transmission parameters of the frame. PLS1 allows a receiver to access and decode PLS2 data, which contains parameters for accessing a DP of interest. PLS2 is carried in each frame and is divided into two main parts: PLS2-STAT data and PLS2-DYN data. If necessary, the static and dynamic parts of PLS2 data are followed by padding.

The preamble signalling data bearer requires 21 bits of information to allow the receiver to access the PLS data and track the DP within the frame structure. The details of the preamble signaling data are as follows:

PHY _ PROFILE: the 3-bit field indicates the PHY profile type of the current frame. The mapping of the different PHY profile types is given in table 5 below.

TABLE 5

[ Table 5]

Value of	PHY Profile
		000	Base profile
001	Hand-held profile
		010	Advanced profiles
011～110	Retention
		111	FEF

FFT _ SIZE: the 2-bit field indicates the FFT size of the current frame within a frame group, as described in table 6 below.

TABLE 6

[ Table 6]

Value of	FFT size
		00	8K FFT
01	16K FFT
		10	32K FFT
11	Retention

GI _ FRACTION: the 3-bit field indicates a guard interval fraction value in the current superframe, as described in table 7 below.

TABLE 7

[ Table 7]

Value of	GI_FRACTION
		000	1/5
001	1/10
		010	1/20
011	1/40
		100	1/80
101	1/160
		110～111	Retention

EAC _ FLAG: the 1-bit field indicates whether EAC is provided in the current frame. If the field is set to '1', an Emergency Alert Service (EAS) is provided in the current frame. If this field is set to "0", no EAS is carried in the current frame. This field may be dynamically switched within the superframe.

PILOT _ MODE: the 1-bit field indicates whether the pilot pattern is a moving mode or a fixed mode for the current frame in the current frame group. If the field is set to "0," a mobile pilot pattern is used. If this field is set to "1," a fixed pilot pattern is used.

PAPR _ FLAG: the 1-bit field indicates whether PAPR reduction is used for the current frame in the current frame group. If this field is set to a value of "1", tone reservation is used for PAPR reduction. If this field is set to "0," PAPR reduction is not used.

FRU _ CONFIGURE: the 3-bit field indicates a PHY profile type configuration of a Frame Repetition Unit (FRU) present in the current superframe. In all preambles in the current superframe, all profile types transmitted in the current superframe are identified in this field. The 3-bit field has a different definition for each profile as shown in table 8 below.

TABLE 8

[ Table 8]

RESERVED: this 7-bit field is reserved for future use.

FIG. 13 illustrates PLS1 data according to an embodiment of the invention.

PLS1 data provides basic transmission parameters including parameters required to allow reception and decoding of PLS 2. As mentioned above, PLS1 data remains unchanged for the entire duration of a frame group. The details of the signalling fields of PLS1 data are defined as follows:

PREAMBLE _ DATA: the 20-bit field is a copy of the preamble signaling data except for EAC _ FLAG.

NUM _ FRAME _ FRU: the 2-bit field indicates the number of frames per FRU.

PAYLOAD _ TYPE: the 3-bit field indicates the format of the payload data carried in the group of frames. The PAYLOAD _ TYPE is signaled as shown in Table 9.

TABLE 9

[ Table 9]

Value of	Payload type
		1XX	Transmitting TS streams
X1X	Sending IP flows
		XX1	Sending GS streams

NUM _ FSS: the 2-bit field indicates the number of FSS symbols in the current frame.

SYSTEM _ VERSION: the 8-bit field indicates the version of the transmitted signal format. SYSTEM _ VERSION is divided into two 4-bit fields, which are the primary and secondary VERSIONs.

Major versions: the MSB four-bit byte of the SYSTEM _ VERSION field represents the major VERSION information. Changes in the major version field indicate non-backward compatible changes. The default value is "0000". For the version described under this standard, this value is set to "0000".

Minor version: the LSB four-bit byte of the SYSTEM _ VERSION field represents the minor VERSION information. The changes in the minor version field are backward compatible.

CELL _ ID: this is a 16-bit field that uniquely identifies a geographic cell in an ATSC network. The ATSC cell coverage area may consist of one or more frequencies depending on the number of frequencies used per Futurecast UTB system. This field is set to "0" if the value of CELL _ ID is not known or specified.

NETWORK _ ID: this is a 16-bit field that uniquely identifies the current ATSC network.

SYSTEM _ ID: this 16-bit field uniquely identifies the Futurecast UTB system within the ATSC network. The Futurecast UTB system is a terrestrial broadcast system, whose inputs are one or more input streams (TS, IP, GS), and whose outputs are RF signals. The Futurecast UTB system carries one or more PHY profiles and FEFs, if any. The same Futurecast UTB system can carry different input streams and use different RF frequencies in different geographical areas, allowing local service insertion. The frame structure and scheduling is controlled in one location and is the same for all transmissions within the Futurecast UTB system. One or more Futurecast UTB SYSTEMs may have the same SYSTEM _ ID meaning, i.e., they all have the same physical layer structure and configuration.

The subsequent loop consists of FRU _ PHY _ PROFILE, FRU _ FRAME _ LENGTH, FRU _ Gl _ FRAME, and RESERVED, which are used to represent the FRU configuration and LENGTH of each FRAME type. The loop size is fixed such that four PHY profiles (including FEFs) are signaled within the FRU. If NUM _ FRAME _ FRU is less than 4, the unused fields are filled with zeros.

FRU _ PHY _ PROFILE: this 3-bit field indicates the PHY profile type of the (i +1) th frame (i is the ring index) of the associated FRU. This field uses the same signaling format as shown in table 8.

FRU _ FRAME _ LENGTH: this 2-bit field indicates the length of the (i +1) th frame of the associated FRU. Using FRU _ FRAME _ LENGTH together with FRU _ GI _ FRAME, an accurate value of the FRAME duration can be obtained.

FRU _ GI _ frame: this 3-bit field represents the guard interval fraction value of the (i +1) th frame of the associated FRU. FRU _ GI _ frame is signaled according to table 7.

RESERVED: this 4-bit field is reserved for future use.

The following fields provide parameters for decoding PLS2 data.

PLS2_ FEC _ TYPE: this 2-bit field indicates the FEC type used by PLS2 for protection. The FEC type is signaled according to table 10. Details of the LDPC code will be described later.

Watch 10

[ Table 10]

Content providing method and apparatus	PLS2FEC type
		00	4K-1/4 and 7K-3/10LDPC codes
01～11	Retention

PLS2_ MOD: this 3-bit field indicates the type of modulation used by PLS 2. The modulation type is signaled according to table 11.

TABLE 11

[ Table 11]

Value of	PLS2_MODE
		000	BPSK
001	QPSK
		010	QAM-16
011	NUQ-64
		100～111	Retention

PLS2_ SIZE _ CELL: this 15-bit field represents C_{total_partial_block}The size of the aggregation of fully encoded blocks for PLS2 carried in the current frame set (specified as the number of QAM cells). This value is constant during the entire duration of the current frame group.

PLS2_ STAT _ SIZE _ BIT: this 14-bit field indicates in bits the size of PLS2-STAT for the current frame set. This value is constant during the entire duration of the current frame group.

PLS2_ DYN _ SIZE _ BIT: this 14-bit field indicates in bits the size of PLS2-DYN for the current frame group. This value is constant during the entire duration of the current frame group.

PLS2_ REP _ FLAG: this 1-bit flag indicates whether the PLS2 repetition pattern is used in the current frame set. When this field is set to the value "1", a PLS2 repeat mode is activated. When this field is set to the value "0", PLS2 repeat mode is disabled.

PLS2_ REP _ SIZE _ CELL: this 15-bit field indicates C when repeated using PLS2_{total_partial_blook}The size of the aggregation of the partially encoded blocks of PLS2 (specified as the number of QAM cells) for carrying in each frame of the current frame set. If no repetition is used, the value of this field is equal to 0. This value is constant during the entire duration of the current frame group.

PLS2_ NEXT _ FEC _ TYPE: this 2-bit field indicates the FEC type for PLS2 carried in each frame of the next frame group. The FEC type is signaled according to table 10.

PLS2_ NEXT _ MOD: this 3-bit field indicates the modulation type for PLS2 carried in each frame of the next frame group. The modulation type is signaled according to table 11.

PLS2_ NEXT _ REP _ FLAG: this 1-bit flag indicates whether the PLS2 repetition pattern is used in the next frame group. When this field is set to the value "1", a PLS2 repeat mode is activated. When this field is set to the value "0", PLS2 repeat mode is disabled.

PLS2_ NEXT _ REP _ SIZE _ CELL: this 15-bit field indicates C when repeated using PLS2_{total_partial_blook}The size of the aggregation of the full coded blocks for PLS2 carried in each frame of the next frame group (specified as the number of QAM cells). The value of this field is equal to 0 if no repetition is used in the next frame group. This value is constant during the entire duration of the current frame group.

PLS2_ NEXT _ REP _ STAT _ SIZE _ BIT: this 14-bit field indicates in bits the size of PLS2-STAT for the next frame group. This value is constant in the current frame group.

PLS2_ NEXT _ REP _ DYN _ SIZE _ BIT: this 14-bit field indicates in bits the size of PLS2-DYN for the next frame group. This value is constant in the current frame group.

PLS2_ AP _ MODE: this 2-bit field indicates whether additional parity is provided for PLS2 in the current frame group. This value is constant during the entire duration of the current frame group. The values of this field are given in table 12 below. When this field is set to "00", no further parity is used for PLS2 in the current frame group.

TABLE 12

[ Table 12]

Value of	PLS2-AP mode
		00	Not providing AP
01	AP1 mode
		10～11	Retention

PLS2_ AP _ SIZE _ CELL: this 15-bit field indicates the size of the additional parity bits of PLS2 (specified as the number of QAM cells). This value is constant during the entire duration of the current frame group.

PLS2_ NEXT _ AP _ MODE: this 2-bit field indicates whether additional parity is provided for PLS2 signaling in each frame of the next frame group. This value is constant during the entire duration of the current frame group. Table 12 defines the values of this field.

PLS2_ NEXT _ AP _ SIZE _ CELL: this 15-bit field indicates the size of the additional parity bits of PLS2 (specified as the number of QAM cells) in each frame of the next frame group. This value is constant during the entire duration of the current frame group.

RESERVED: this 32-bit field is reserved for future use.

CRC _ 32: a 32 bit error detection code applied to the entire PLS1 signaling.

FIG. 14 illustrates PLS2 data according to an embodiment of the invention.

FIG. 14 shows PLS2-STAT data of PLS2 data. PLS2-STAT data are identical within a frame group, while PLS2-DYN data provide information specific to the current frame.

Details of the fields of PLS2-STAT data are as follows:

FIC _ FLAG: this 1-bit field indicates whether the FIC is used in the current frame group. If this field is set to "1", the FIC is provided in the current frame. If this field is set to "0", the FIC is not carried in the current frame. This value is constant during the entire duration of the current frame group.

AUX _ FLAG: this 1-bit field indicates whether the auxiliary stream is used in the current frame group. If this field is set to "1", the auxiliary stream is provided in the current frame. If this field is set to "0", no auxiliary stream is carried in the current frame. This value is constant during the entire duration of the current frame group.

NUM _ DP: this 6-bit field indicates the number of DPs carried within the current frame. The value of this field ranges from 1 to 64, and the number of DPs is NUM _ DP + 1.

DP _ ID: this 6-bit field uniquely identifies the DP within the PHY profile.

DP _ TYPE: this 3-bit field indicates the type of DP. These are signaled according to table 13 below.

Watch 13

[ Table 13]

Value of	DP type
		000	DP type 1
001	DP type 2
		010～111	Retention

DP _ GROUP _ ID: this 8-bit field identifies the DP group with which the current DP is associated. This can be used by the receiver to access the DP of the service component related to the particular service, which will have the same DP _ GROUP _ ID.

BASE _ DP _ ID: this 6-bit field indicates a DP carrying service signaling data (such as PSI/SI) used in the management layer. The DP represented by the BASE _ DP _ ID may be either a general DP carrying service signaling data along with service data or a dedicated DP carrying only service signaling data.

DP _ FEC _ TYPE: this 2-bit field indicates the FEC type used by the associated DP. The FEC type is signaled according to table 14 below.

TABLE 14

[ Table 14]

Value of	FEC_TYPE
		00	16K LDPC
01	64K LDPC
		10～11	Retention

DP _ COD: this 4-bit field indicates the code rate used by the associated DP. The code rate is signaled according to table 15 below.

Watch 15

[ Table 15]

Value of	Code rate
		0000	5/15
0001	6/15
		0010	7/15
0011	8/15
		0100	9/15
0101～1111	10/15
		0110	11/15
0111	12/15
		1000	13/15
1001～1111	Retention

DP _ MOD: this 4-bit field represents the modulation used by the associated DP. The modulation is signaled according to table 16 below.

TABLE 16

[ Table 16]

Value of	Modulation
		0000	QPSK
0001	QAM-16
		0010	NUQ-64
0011	NUQ-256
		0100	NUQ-1024
0101	NUC-16
		0110	NUC-64
0111	NUC-256
		1000	NUC-1024
1001～1111	Retention

DP _ SSD _ FLAG: this 1-bit field indicates whether SSD mode is used in the associated DP. If this field is set to a value of "1," SSD is used. If this field is set to a value of "0," the SSD is not used.

Only if PHY _ PROFILE is equal to "010", which represents a high level PROFILE, the following fields occur:

DP _ MIMO: this 3-bit field indicates which type of MIMO encoding process is applied to the associated DP. The type of MIMO encoding process is signaled according to table 17.

TABLE 17

[ Table 17]

Value of	MIMO encoding
		000	FR-SM
001	FRFD-SM
		010～111	Retention

DP _ TI _ TYPE: this 1-bit field indicates the type of time interleaving. A value of "0" indicates that one TI group corresponds to one frame and contains one or more TI blocks. A value of "1" indicates that one TI group is carried in more than one frame and contains only one TI block.

DP _ TI _ LENGTH: the use of this 2-bit field (allowed values are only 1, 2, 4, 8) is determined by the set of values in the DP _ TI _ TYPE field as follows:

if DP _ TI _ TYPE is set to a value of "1", this field indicates P_IThe number of frames to which each TI group is mapped, and one TI block (N) per TI group_TI1). Allowed to have 2-bit fieldP_IThe values are defined in table 18 below.

If DP _ TI _ TYPE is set to a value of "0", this field represents the number of TI blocks NTI of each TI group, and each frame (P)_I1) there is one TI group. Allowed P with 2-bit field_IThe values are defined in table 18 below.

Watch 18

[ Table 18]

2 bit field	P_I	N_TI
			00	1	1
01	2	2
			10	4	3
11	8	4

DP _ FRAME _ INTERVAL: this 2-bit field indicates the frame interval (I) within the frame group for the associated DP_JUMP) And the allowed values are 1, 2, 4, 8 (the corresponding 2-bit fields are respectively "00"),"01", "10", or "11"). The value of this field is equal to the interval between successive frames for DPs that do not occur for each frame of the group of frames. For example, if a DP is present on

frames

1, 5, 9, 13, etc., this field is set to "4". This field is set to "1" for DP occurring in each frame.

DP _ TI _ BYPASS: this 1-bit field determines the availability of the time interleaver 5050. If time interleaving is not used for DP, it is set to "1". And if time interleaving is used, it is set to "0".

DP _ FIRST _ FRAME _ IDX: this 5-bit field indicates the index of the first frame of the superframe in which the current DP exists. The value of DP _ FIRST _ FRAME _ IDX ranges from 0 to 31.

DP _ NUM _ BLOCK _ MAX: this 10-bit field indicates the maximum value of DP _ NUM _ BLOCKS for this DP. The value of this field has the same range as DP _ NUM _ BLOCKS.

DP _ PAYLOAD _ TYPE: this 2-bit field indicates the type of payload data carried by a given DP. DP _ PAYLOAD _ TYPE is signaled according to table 19 below.

Watch 19

[ Table 19]

Value of	Payload type
		00	TS
01	IP
		10	GS
11	Retention

DP _ input _ MODE: this 2-bit field indicates whether the current DP carries in-band signaling information. The in-band signaling type is signaled according to table 20 below.

Watch 20

[ Table 20]

Value of	In-band mode
		00	No in-band signaling
01	Carrying only in-band PLS
		10	Carrying in-band ISSY only
11	Carrying in-band PLS and in-band ISSY

DP _ progress _ TYPE: this 2-bit field indicates the protocol type of the payload carried by a given DP. When an input payload type is selected, it is signaled according to table 21 below.

TABLE 21

[ Table 21]

DP _ CRC _ MODE: this 2-bit field indicates whether CRC coding is used in the input formatted block. The CRC pattern is signaled according to table 22 below.

TABLE 22

[ Table 22]

Value of	CRC mode
		00	Is not used
01	CRC-8
		10	CRC-16
11	CRC-32

DNP _ MODE: this 2-bit field represents the null packet deletion mode used by the associated DP when DP _ PAYLOAD _ TYPE is set to TS ("00"). DNP _ MODE is signaled according to table 23 below. If DP _ PAYLOAD _ TYPE is not TS ("00"), DNP _ MODE is set to the value "00".

TABLE 23

[ Table 23]

Value of	Null packet deletion mode
		00	Is not used
01	DNP Standard
		10	DNP offset
11	Retention

ISSY _ MODE: this 2-bit field represents the ISSY mode used by the associated DP when DP _ PAYLOAD _ TYPE is set to TS ("00"). ISSY _ MODE is signaled according to table 24 below. If DP _ PAYLOAD _ TYPE is not TS ("00"), ISSY _ MODE is set to a value of "00".

Watch 24

[ Table 24]

Value of	ISSY mode
		00	Is not used
01	ISSY-UP
		10	ISSY-BBF
11	Retention

HC _ MODE _ TS: this 2-bit field indicates the TS header compression mode used by the associated DP when DP _ PAYLOAD _ TYPE is set to TS ("00"). HC _ MODE _ TS is signaled according to table 25 below.

TABLE 25

[ Table 25]

0	Header compression mode
		00	HC_MODE_TS 1
01	HC_MODE_TS 2
		10	HC_MODE_TS 3
11	HC_MODE_TS 4

HC _ MODE _ IP: this 2-bit field indicates the IP header compression mode when DP _ PAYLOAD _ TYPE is set to IP ("01"). HC _ MODE _ IP is signaled according to table 26 below.

Watch 26

[ Table 26]

Value of	Header compression mode
		00	Without compression
01	HC_MODE_IP 1
		10～11	Retention

PID: this 13-bit field indicates the PID number used for TS header compression when DP _ PAYLOAD _ TYPE is set to TS ("00") and HC _ MODE _ TS is set to "01" or "10".

RESERVED: this 8-bit field is reserved for future use.

The following fields only occur when FIC _ FLAG is equal to "1":

FIC _ VERSION: this 8-bit field indicates the version number of the FIC.

FIC _ LENGTH _ BYTE: this 13-bit field represents the length of the FIC in bytes.

RESERVED: this 8-bit field is reserved for future use.

The following fields only occur when AUX _ FLAG is equal to "1":

NUM _ AUX: this 4-bit field indicates the number of auxiliary streams. Zero indicates that the auxiliary stream is not used.

AUX _ CONFIG _ RFU: this 8-bit field is reserved for future use.

AUX _ STREAM _ TYPE: this 4 bits are reserved for future use to indicate the type of the current auxiliary stream.

AUX _ PRIVATE _ CONFIG: this 28-bit field is reserved for future use in signaling the auxiliary stream.

FIG. 15 illustrates PLS2 data according to another embodiment of the invention.

FIG. 15 shows PLS2-DYN data of PLS2 data. The value of PLS2-DYN data may vary during the duration of a frame group while the size of the field remains constant.

Details of the fields of PLS2-DYN data are as follows:

FRAME _ INDEX: this 5-bit field indicates the frame index of the current frame within the superframe. The index of the first frame of the superframe is set to "0".

PLS _ CHANGE _ coder: this 4-bit field indicates the number of preceding superframes in which the configuration will change. The next superframe with changes in configuration is represented by the value signaled in this field. If this field is set to the value "0000", this means that no scheduled change is foreseen: for example, a value of "1" indicates that there is a change in the next superframe.

FIC _ CHANGE _ COUNTER: this 4-bit field indicates the number of front superframes in which the configuration (i.e., the content of the FIC) will vary. The next superframe with changes in configuration is represented by the value signaled in this field. If this field is set to the value "0000", this means that no scheduled change is foreseen: for example, a value of "0001" indicates that there is a change in the next superframe.

RESERVED: this 16-bit field is reserved for future use.

The following fields, which describe the parameters associated with the DP carried in the current frame, appear in the loop over NUM _ DP.

DP _ ID: this 6-bit field uniquely represents the DP within the PHY profile.

DP _ START: this 15-bit (or 13-bit) field indicates the start position of the first DP using the DPU addressing scheme. The DP _ START field has different lengths according to the PHY profile and FFT size as shown in table 27 below.

Watch 27

[ Table 27]

DP _ NUM _ BLOCK: this 10-bit field indicates the number of FEC blocks in the current TI group for the current DP. The value of DP _ NUM _ BLOCK ranges from 0 to 1023.

RESERVED: this 8-bit field is reserved for future use.

The following fields represent FIC parameters associated with EAC.

EAC _ FLAG: this 1-bit field indicates the presence of EAC in the current frame. This bit is the same value in the preamble as EAC _ FLAG.

EAS _ WAKE _ UP _ VERSION _ NUM: this 8-bit field represents the version number of the wake-up indication.

If the EAC _ FLAG field is equal to "1", the following 12 bits are allocated for the EAC _ LENGTH _ BYTE field. If the EAC _ FLAG field is equal to "0", the following 12 bits are allocated for EAC _ COUNTER.

EAC _ LENGTH _ BYTE: this 12-bit field represents the length of the EAC in bytes.

EAC _ COUNTER: this 12-bit field indicates the number of frames before the frame at which the EAC arrives.

The following fields occur only if the AUX _ FLAG field is equal to "1":

AUX _ prior _ DYN: this 48-bit field is reserved for future use in signaling the auxiliary stream. The meaning of this field depends on the value of AUX _ STREAM _ TYPE in the configurable PLS 2-STAT.

CRC _ 32: a 32 bit error detection code which is applied to the entire PLS 2.

As mentioned above, PLS, EAC, FIC, DP, auxiliary streams and dummy cells are mapped to active carriers of OFDM symbols in a frame. PLS1 and PLS2 are first mapped to one or more FSSs. Then, after the PLS field, EAC cells, if any, are mapped directly, followed by FIC cells, if any. After PLS or EAC, FIC, the DP is next mapped, if any. Type 1DP follows first, and type 2DP follows next. The type details of the DP will be described later. In some cases, the DP may carry some specific data for EAS or service signaling data. The auxiliary stream follows the DP, if any, followed by dummy cells. The PLS, EAC, FIC, DP, auxiliary stream and dummy data cells are mapped together according to the above mentioned order, filling exactly the cell size in the frame.

FIG. 17 illustrates a PLS mapping according to an embodiment of the invention.

The PLS cell is mapped to the active carrier of the FSS. Depending on the number of cells occupied by PLS, one or more symbols are designated as FSS, and the number N of FSS_FSSSignaled by NUM _ FSS in PLS 1. FSS is a special symbol used to carry PLS cells. Since robustness and delay are important issues in PLS, FSS has a high density of pilots that allow fast synchronization and frequency-only interpolation within the FSS.

PLS cells are mapped to N in a top-down manner as shown in the example in FIG. 17_FSSActive carrier of FSS. PLS1 cells are first mapped from the first cell of the first FSS in increasing order of cell index. The PLS2 unit immediately follows the last cell of PLS1 and continues mapping down until the last cell index of the first FSS. If the total number of PLS cells needed exceeds the number of active carriers of one FSS, the mapping proceeds to the next FSS and continues in exactly the same way as the first FSS.

After PLS mapping is complete, DP is carried over next. If EAC, FIC or both are present in the current frame, they are placed between PLS and the "normal" DP.

The EAC is a dedicated channel for carrying EAS messages and is linked to a DP for EAS. EAS support is provided, however, EAC may or may not be present in every frame itself. EAC is mapped immediately after PLS2 unit, if any. The EAC does not precede any of the FIC, DP, auxiliary stream or dummy cell, except for the PLS cell. The procedure for mapping EAC cells is exactly the same as PLS.

The EAC cells are mapped from the next cell of PLS2 in increasing order of cell index as shown in the example of fig. 18. Depending on the EAS message size, the EAC cell may occupy several symbols as shown in fig. 18.

The EAC cell immediately follows the last cell of PLS2 and continues to map down until the last cell index of the last FSS. If the total number of EAC cells needed exceeds the number of remaining active carriers for the last FSS, the mapping proceeds to the next symbol and continues in exactly the same manner as FSS. In this case, the next symbol for mapping is a normal data symbol, which has a more efficient carrier than FSS.

After EAC mapping is completed, if any exists, the FIC is carried next. If the FIC is not sent (as signaled in PLS2 field), the DP immediately follows the last cell of the EAC.

Fig. 19 illustrates an FIC mapping according to an embodiment of the present invention

(a) Shows an example mapping for FIC information elements without EAC, and (b) shows an example mapping for FIC information elements with EAC.

The FIC is a dedicated channel for carrying cross-layer information to allow fast service acquisition and channel scanning. This information mainly includes channel bonding information between the DP and the service of each broadcaster. For fast scanning, the receiver may decode the FIC and obtain information such as a broadcaster ID, a service number, and a BASE _ DP _ ID. For fast service acquisition, the basic DP may be decoded using BASE _ DP _ ID in addition to FIC. The base DP is encoded and mapped to frames in exactly the same way as the normal DP, except for the content it carries. Therefore, no additional description is required for the basic DP. FIC data is generated and consumed in the management layer. The content of the FIC data is described in the management layer specification.

FIC data is optional and the use of FIC is signaled by FIC _ FLAG parameters in the static part of PLS 2. If FIC is used, FIC _ FLAG is set to "1" and the signaling field for FIC is defined in the static portion of PLS 2. Signaled in this field are FIC _ VERSION and FIC _ LENGTH _ BYTE. The FIC uses the same modulation, coding and time interleaving parameters as PLS 2. The FIC shares the same signaling parameters, such as PLS2_ MOD and PLS2_ FEC. FIC data, if any, is mapped immediately after PLS2 or EAC. The FIC is not directed by any normal DP, auxiliary streams or dummy cells. The method of mapping FIC cells is exactly the same as that of EAC and also the same as that of PLS.

Without EAC after PLS, FIC cells are mapped from the next element of PLS2 in increasing order of cell index as shown by example in (a). Depending on the FIC data size, the FIC information element may be mapped over several symbols, as shown in (b).

The FIC cell immediately follows the last cell of PLS2 and continues mapping down until the last cell index of the last FSS. If the total number of FIC cells needed exceeds the number of remaining active carriers for the last FSS, the mapping proceeds to the next symbol and continues in exactly the same manner as FSS. In this case, the next symbol for mapping is a normal data symbol, which has a more active carrier than FSS.

If the EAS message is transmitted in the current frame, the EAC precedes the FIC, and FIC cells are mapped from the next unit of the EAC in increasing order of cell index as shown in (b).

After FIC mapping is complete, one or more DPs are mapped, followed by auxiliary streams, if any, and dummy cells.

(a) Type 1DP is shown and (b) type 2DP is shown.

After the previous channels, i.e., PLS, EAC, and FIC, are mapped, the cells of DP are mapped. The DP is classified into one of two types according to the mapping method:

type 1 DP: DP mapping over TDM

Type 2 DP: DP mapping with FDM

The TYPE of DP is indicated by the DP _ TYPE field in the static part of PLS 2. Fig. 20 illustrates the mapping order of type 1DP and type 2 DP. The type 1DP is first mapped in the increasing order of cell indexes, and then, after reaching the last cell index, the symbol index is increased by 1. In the next symbol, DP continues mapping in increasing order of cell indices starting from p ═ 0. Each of the type 1 DPs is grouped in time with the number of DPs mapped in common in one frame, similar to TDM multiplexing of DPs.

The type 2DP is first mapped in an increasing order of symbol index, then after reaching the last OFDM symbol of the frame, the cell index is increased by 1, and the symbol index is recalls to the first available symbol and then increases from the symbol index. After mapping the number of DPs together in one frame, each of the type 2 DPs is grouped together in frequency, similar to FDM multiplexing of DPs.

If desired, type 1DP and type 2DP may be present in the frame at the same time, with a limit: type 1DP always precedes type 2 DP. The total number of OFDM cells carrying type 1 and type 2DP cannot exceed the total number of OFDM cells available for DP transmission.

Mathematical formula 2

[ mathematical formula 2]

D_DP1+D_DP2≤D_DP

Here DDP1 is the number of OFDM cells occupied by type 1DP and DDP2 is the number of cells occupied by type 2 DP. Since PLS, EAC, FIC are all mapped in the same way as type 1DP, they all follow the "type 1 mapping rule". Thus, in general, type 1 mapping always precedes type 2 mapping.

(a) Addressing OFDM cells for mapping type 1DP is shown, and (b) addressing OFDM cells for mapping for type 2 DP.

The addressing of the OFDM cells for mapping type 1DP (0, …, DDP1-1) defines the active data cells for type 1 DP. The addressing scheme defines the order in which cells from T1 for each of the type 1 DPs are assigned to active data cells. It is also used to signal the position of the DP in the dynamic part of PLS 2.

In the absence of an EAC and FIC, address 0 refers to the cell immediately following the last cell carrying PLS in the last FSS. If the EAC is transmitted and the FIC is not in the corresponding frame, address 0 refers to the cell immediately following the last cell carrying the EAC. If the FIC is transmitted in the corresponding frame, address 0 refers to the cell immediately following the last cell carrying the FIC. Address 0 for type 1DP may be calculated considering two different situations as shown in (a). In the example of (a), PLS, EAC and FIC are assumed to be all transmissions. Extensions to the case where either or both of the EAC and FIC are omitted are explicit. After mapping all cells up to FIC as shown on the left side of (a), if there are cells remaining in FSS.

Addressing of OFDM cells for mapping type 2DP (0, …, DDP2-1) is defined for active data cells of type 2 DP. The addressing scheme defines the order in which cells from the TI for each of the type 2DP are allocated to active data cells. It is also used to signal the position of the DP in the dynamic part of PLS 2.

Three slightly different cases as shown in (b) are allowable. For the first scenario shown on the left side of (b), the cell in the last FSS is available for type 2DP mapping. For the second case shown in the middle, the FIC occupies a cell of the ordinary symbol, however, the number of FIC cells on the symbol is not greater than C_FSS. Except that the number of FIC cells mapped on the symbol exceeds C_FSSExcept that the third case shown on the right side of (b) is the same as the second case.

The extension to the case of type 1DP before type 2DP is simple, since PLS, EAC and FIC follow the same "type 1 mapping rules" as type 1 DP.

A Data Pipe Unit (DPU) is a basic unit for distributing data cells to DPs in frames.

A DPU is defined as a signaling unit for locating a DP in a frame. The cell mapper 7010 may map cells generated by TI for each DP. Time interleaver 5050 outputs a series of time interleaversAnd each TI block includes a variable number of XFECBLOCK, which in turn is made up of a group of cells. Number of cells N in XFCBLOCK_cellsDependent on FECBLOCK size N_ldpcAnd the number of transmitted bits per constellation symbol. The DPU is defined as the number N of cells in XFCBLOCK supported in a given PHY profile_cellsThe largest remainder among all possible values of (a). The length of the DPU in cells is defined as L_DPU. Because each PHY profile supports a combination of FECBLOCK size and a maximum different number of bits per constellation symbol, L is defined based on the PHY profile_DPU。

Fig. 22 illustrates an FEC structure according to an embodiment of the present invention before bit interleaving. As mentioned above, the data FEC encoder may perform FEC encoding on the input BBF using outer coding (BCH) and inner coding (LDPC) to generate the FECBLOCK process. The illustrated FEC structure corresponds to FECBLOCK. Further, the FECBLOCK and FEC structures have the same value corresponding to the LDPC codeword length.

BCH coding is applied to each BBF (K)_bchBits) and then LDPC coding is applied to the BCH coded BBF (K)_ldpcBit N_bchBits) as illustrated in fig. 22.

N_ldpcIs either 64800 bits (long FECBLOCK) or 16200 bits (short FECBLOCK).

Table 28 and table 29 below show FEC coding parameters for long FECBLOCK and short FECBLOCK, respectively.

Watch 28

[ Table 28]

Watch 29

[ Table 29]

The details of the operations of BCH encoding and LDPC encoding are as follows:

the 12-error correction BCH code is used for outer coding of the BBF. The BCH generating polynomials for short and long FECBLOCK are obtained by multiplying all polynomials together.

LDPC codes are used to encode the output of the outer BCH codes. To generate complete B_ldpc(FECBLOCK)，P_ldpc(parity bits) from each I_ldpc(BCH coded BBF) is system coded and appended to I_ldpc. The complete bldpc (fecblock) is expressed as the following mathematical formula.

Mathematical formula 3

[ mathematical formula 3]

The parameters for long and short FECBLOCK are given in tables 28 and 29 above, respectively.

Calculating N for Long FECBLOCK_ldpc–K_ldpcThe detailed procedure for the parity bits is as follows:

1) the parity-check bits are initialized and,

mathematical formula 4

[ mathematical formula 4]

2) Accumulating a first information bit i at a parity bit address specified in a first row of addresses of a parity check matrix₀. Details of the address of the parity check matrix will be described later. For example, for rate 13/15:

mathematical formula 5

[ math figure 5]

3) For the next 359 information bits,

i

_s1, 2, … 359, used to

The following mathematical formula accumulates i at the parity bit address_s。

Mathematical formula 6

[ mathematical formula 6]

{x+(s mod 360)×Q_ldpc}mod(N_ldpc-K_ldpc)

Where x denotes the address of the parity bit accumulator corresponding to the first bit i0, and Q_IdpcIs a code rate dependent constant specified in the address of the parity check matrix. Continuing the example, for rate 13/15, Q_IdpcThus, for the information bit i1, the following operations are performed:

mathematical formula 7

[ math figure 7]

4) For the 361 st information bit i₃₆₀The address of the parity bit accumulator is given in the second row of the address of the parity check matrix. In a similar manner, 359 information bits i for the following are obtained using expression 6_sIs 361, 362, … 719, where x denotes the address of the parity bit accumulator corresponding to the information bit i₃₆₀I.e., an entry in the second row of the address of the parity check matrix.

5) In a similar manner, for each group of 360 new information bits, a new row from the address of the parity check matrix is used to find the address of the parity bit accumulator.

After all information bits are exhausted, the last parity bit is obtained as follows:

6) the following operations are sequentially performed starting with i-1.

Mathematical formula 8

[ mathematical formula 8]

Where p is_iThe last content of (a), i ═ 0,1_Idpc-K_Idpc-1, equal to parity bit p_i。

Watch 30

[ Table 30]

Code rate	Q	_ldpc
			5/15	120
6/15	108
		7/15	96
8/15	84
		9/15	72
10/15	60
		11/15	48
12/15	36
		13/15	24

This LDPC encoding process for short FECBLOCK is according to the LDPC encoding process for long FECBLOCK, except that table 30 is replaced with table 31, and the address of the parity check matrix for long FECBLOCK is replaced with the address of the parity check matrix for short FECBLOCK.

Watch 31

[ Table 31]

Code rate	Q	_ldpc
			5/15	30
6/15	27
		7/15	24
8/15	21
		9/15	18
10/15	15
		11/15	12
12/15	9
		13/15	6

The output of the LDPC encoder is bit interleaved, which consists of parity interleaving followed by quasi-cyclic block (QCB) interleaving and inter-group interleaving.

(a) Quasi-cyclic block (QCB) interleaving is shown, and (b) inter-group interleaving is shown.

The FECBLOCK may be parity interleaved. At the output of parity interleaving, the LDPC codeword consists of 180 adjacent QC blocks in long FECBLOCK and 45 adjacent QC blocks in short FECBLOCK. Each QC block in long or short FECBLOCK consists of 360 bits. The parity-interleaved LDPC codeword is interleaved by QCB interleaving. The unit of QCB interleaving is a QC block. The QC blocks at the output of parity interleaving are rearranged by QCB interleaving as illustrated in FIG. 23, here according to FECBLOCK length, N_cells＝64800/η_modOr 16200/eta_mod. The QCB interleaving mode is unique to each combination of modulation type and LDPC code rate.

After QCB interleaving, interclass interleaving is performed according to the modulation type and order (η mod), which is defined in table 32 below. Also defining the number N of QC blocks for a group_{QCB_IG}。

Watch 32

[ Table 32]

Modulation type	η_mod	N_{QCB_LG}
			QAM-16	4	2
NUC-16	4	4
			NUQ-64	6	3
NUC-64	6	6
			NUQ-256	8	4
NUC-256	8	8
			NUQ-1024	10	5
NUC-1024	10	10

Intergroup interleaving process N output is QCB interleaved_{QCB_IG}And executing the QC block. Interclass interleaving has the use of 360 columns and N_{QCB_IG}The process of row writing and reading bits within a group. In a write operation, the bits from the QCB interleaved output are line-wise written. The read operation is performed column-wise to read out m bits from each row, where m equals 1 for NUC and 2 for NUQ.

Figure 24 illustrates cell word demultiplexing according to an embodiment of the present invention.

Fig. 24(a) shows cell word demultiplexing for 8 and 12bpcu MIMO, and (b) shows cell word demultiplexing for 10bpcu MIMO.

Each cell word (c) of the bit interleaved output_0,l,c_1,l,...,c_ηmod-1,l) Is demultiplexed into (d) as shown in (a)_1,0,m,d_1,1,m...d_1,ηmod-1,m) And (d)_2,0,m,d_2,1,m...,d_2,ηmod-1,m) It describes the cell word demultiplexing process for one XFECBLOCK.

For the 10bpcu MIMO case using different types of NUQ for MIMO coding, the bit interleaver for NUQ-1024 is reused. Each cell word (c) output by the bit interleaver_0,l,c_1,l...,c_9,l) Is demultiplexed into (d)_1,0,m,d_1,1,m...d_1,3,m) And (d)_2,0,m,d_2,1,m...d_2,3,m) As shown in (b).

(a) To (c) show examples of the TI mode.

The time interleaver operates at the DP level. The parameter of the Time Interleaving (TI) may be set differently for each DP.

The following parameters, TI, appear in the part of PLS2-STAT data:

DP _ TI _ TYPE (permissible value: 0 or 1): indicates a TI mode; "0" denotes a mode in which each TI group has a plurality of TI blocks (more than one TI block). In this case, one TI group is directly mapped to one frame (no inter-frame interleaving). "1" indicates a mode with only one TI module per TI group. In this case, the TI block may be extended over more than one frame (inter-frame interleaving).

DP _ TI _ LENGTH: if DP _ TI _ TYPE is "0", this parameter is the number NTI of TI blocks per TI group. For DP _ TI _ TYPE ═ 1 ", this parameter is the number of frames PI extended from one TI group.

DP _ NUM _ BLOCK _ MAX (allowed values: 0 to 1023): representing the maximum number of XFECBLOCK per TI group.

DP _ FRAME _ INTERVAL (allowed values: 1, 2, 4, 8): representing frame I between two consecutive frames carrying the same DP of a given PHY profile_JUMPThe number of (2).

DP _ TI _ BYPASS (allowed value: 0 or 1): this parameter is set to "1" if time interleaving is not used for DP. If time interleaving is used, it is set to "0".

In addition, the parameter DP _ NUM _ BLOCK from PLS2-DYN data is used to indicate the number of XFACCLOCKs carried by one TI group of DPs.

When time interleaving is not used for DP, the subsequent TI group, time interleaving operation, and TI mode are not considered. However, a delay compensation block for dynamic configuration information from the scheduler will still be needed. In each DP, XFECBLOCK received from SSD/MIMO encoding is grouped into TI groups. That is, each TI group is a set of an integer number of XFECBLOCKs, and will contain a dynamically variable number of XFECBLOCKs. The number of XFCBLOCKs in the TI group at index N is defined by N_{xBLocK_Group}(n) and is signaled as DP _ NUM _ BLOCK in PLS2-DYN data. Note that N_{xBLocK_Group}(N) the maximum value N, which can range from the minimum value 0 to its maximum value of 1023_{xBLocK_Group_MAX}(corresponding to DP _ NUM _ BLOCK _ MAX) change.

Each TI group is either directly mapped onto one frame or extended over PI frames. Each TI group is also divided into more than one TI module (NTI), where each TI block corresponds to one use of the time interleaver memory. The TI blocks within a TI group may contain a slightly different number of XFECBLOCK. If a TI group is divided into TI blocks, it is directly mapped to only one frame. As shown in table 33 below, there are three options for time interleaving (in addition to the additional option of skipping time interleaving).

Watch 33

[ Table 33]

In each DP, the TI memory stores an input XFECBLOCK (output XFECBLOCK from the SSD/MIMO coding block). Assume that the input XFACBLOCK is defined as:

where d is_n.s.r.qIs the q-th cell of the r-th XFECBLOCK in the s-th TI block of the n-th TI group and represents the output of SSD and MIMO coding as follows:

further, assume that XFECBLOCK from the output of the time interleaver is defined as:

where h is_n,s,iIs the i-th output unit (for i ═ O.., N.) in the s-th TI block of the N-th TI group_{xBLOCK_TI}(n，s)×N_cells-1)。

Typically, the time interleaver will also function as a buffer for DP data prior to the frame set up process. This is achieved by two repositories for each DP. The first TI block is written to the first bank. The second TI block is written to the second bank while the first bank is being read, and so on.

TI is a twisted two column block interleaver. For the s-th TI block of the N-th TI group, the number of rows N of the TI memory_rIs equal to cell N_cellsIs the number of (i.e., N)_r＝N_cellsThe number of simultaneous columns N_cEqual to the number N_{xBL0CK_TI}(n,s)。

Fig. 26 illustrates a basic operation of a twisted row-column block interleaver according to an embodiment of the present invention.

(a) A write operation in the time interleaver is shown, and a read operation in the time interleaver is shown in part (b) of fig. 26. The first XFECBLOCK is written to the first column of the TI memory in a column-wise manner, and the second XFECBLOCK is written to the next column, and so on, as shown in (a). However, in the interleaved array, cells are read out in a diagonal fashion. During a diagonal manner of reading from the first row (rightwardly along the row starting with the leftmost column) to the last row, the cell is readAnd (c) as shown in (b). In detail, assume z_n，s，i(i＝0，...，N_iN_c) As TI memory cell locations to be read sequentially, by calculating the row index R of the expression_n，S，iColumn index C_n，S，iAnd the associated distortion parameter T_n，S，iA read process with such a correction array is performed.

Mathematical formula 9

[ mathematical formula 9]

Wherein S_shiftIs a common shift value for a diagonal mode read process, no matter N_{xBLOCK_TI}How (N, s) and by the expression N given in PLS2-STAT_{xBLOCK_TI}(n, s).

Mathematical formula 10

[ mathematical formula 10]

For the

As a result, by being z_n，s，i＝N_vC_n，s，i+R_n，s，iThe coordinates of which calculate the cell location to be read.

Fig. 27 illustrates the operation of a twisted row-column block interleaver according to another embodiment of the present invention.

More specifically, fig. 27 illustrates an interleaved array of TI memories for respective TI groups, including when N_{xBLOCK_TI}(0，０)＝3、N_{xBLOCK_TI}(1，0)＝6、N_{xBLOCK_TI}(2,0) ═ 5 virtual XFECBLOCK.

Variable number N_{xBLOCK_TI}(n，s)＝N_rWill be less than or equal to N'_{xBLOCK_TI_MAX}. Therefore, in order to actualizeNow a single memory de-interleaving at the receiver side, no matter N_{xBLOCK_TI}How (N, s) the interleave array for use in a twisted row-column block interleaver is set to N by inserting a virtual XFAC BLOCK into the TI memory_r×N_c＝N_cells×N′_{xBLOCK_TI_MAX}And completes the reading process as the following expression.

Mathematical formula 11

[ mathematical formula 11]

The number of TI groups is set to 3. By DP _ TI _ TYPE ═ 0 ', DP _ FRAME _ INTERVAL ═ 1 ', and DP _ TI _ LENGTH ═ 1 ', i.e., N_TI＝1、 I_JUMP1, and P_IThe time interleaver option is signaled in PLS2-STAT data as 1. Each of the TI groups has N_cellsThe number of XFECBLOCK of 30 is respectively passed through N_{xBLOCK_TI}(0,0)＝3、N_{xBLOCK_TI}(1,0)＝6、N_{xBLOCK_TI}(2,0) ═ 5 is signaled in the PLS2-DYN data. By N_{xBLOCK_Groyp_MAx}The maximum number of XFCBLOCKs signaled in the PLS-STAT data, which results in

Fig. 28 illustrates a diagonal-wise read pattern of a distorted row-column block according to an embodiment of the present invention.

More specifically, FIG. 28 shows a graph from having N'_{xBLOCK_TI_MAX}7 and S_shiftA diagonal read pattern for each interleaved array of parameters (7-1)/2-3. Note that during a read as shown by the pseudo-code above, if V is_i≥N_cellsN_{xBLOCK_TI}(n, s), then the value of Vi is skipped and the next calculated V is used_iThe value of (c).

FIG. 29 illustrates an interleaved XFACBLOCK for each interleaved array according to an embodiment of the invention.

FIG. 29 is a drawing representation of a chip from having N'_{xBLOCK_TT_MAX}7 and S_shiftInterleaved XFECBLOCK for each interleaved array of parameters 3.

Fig. 30 is a view illustrating the structure of a robust header compression (RoHC) packet and an uncompressed Internet Protocol (IP) packet according to an embodiment of the present invention.

The IP packet L1010 according to an embodiment of the present invention may include an IP header, a user datagram protocol header (UDP header), a real-time transport protocol header (RTP header), and/or a payload.

The IP header, UDP header, and RTP header according to an embodiment of the present invention may have a total length of about 40 bytes.

The RoHC packet L1020 according to an embodiment of the invention may include a RoHC header and/or a payload.

The RoHC packet according to the embodiment of the present invention is a header obtained by compressing a header of an IP packet. A RoHC packet may have a length of about 1 byte.

According to embodiments of the present invention, RoHC may indicate a total header as one context ID. RoHC can perform compression in a scheme of transmitting a total header at the beginning of transmission and omitting unchanged changes except for a context ID and main information in the middle of transmission.

According to embodiments of the present invention, at the time of an IP flow, the IP version, IP source address, IP destination address, IP fragmentation flag, UDP source port, UDP destination port, and so on may be hardly changed. A field that is hardly changed during a stream like the above-described field may be named a static field. After transmitting the static field once, RoHC according to embodiments of the invention may not temporarily further transmit such static field. Embodiments of the present invention may name a state in which a static field is not further transmitted for a while after being transmitted once as an Initialization Refresh (IR) state, and a packet in which a static field is transmitted as an IR packet. In addition, according to an embodiment of the present invention, a field that is changed at any time but is maintained for a predetermined time may be named a dynamic field. Embodiments of the present invention may further communicate the dynamic field described above. According to an embodiment of the present invention, the packet conveying the dynamic field may be named an IR-DYN packet. According to an embodiment of the present invention, the IR packet and the IR-DYN packet may have a size similar to a conventional header because the IR packet and the IR-DYN packet contain all information of the conventional header.

According to an embodiment of the present invention, a method of compressing a header portion of an IP packet to reduce overhead of Internet Protocol (IP) packet data to be transmitted may be used. According to the embodiments of the present invention, the RoHC scheme, which is an IP packet header compression scheme, can be used, and the RoHC scheme can ensure reliability in a wireless section. The RoHC scheme may be used in a broadcasting system such as digital video broadcasting-next generation handheld (DVB-NGH) and a mobile communication system such as Long Term Evolution (LTE). The RoHC scheme may be used for UDP and/or RTP packets, although the RoHC scheme is a scheme for compressing and transmitting a header of an IP packet.

According to embodiments of the present invention, RoHC may indicate a total header as one context ID. RoHC can perform compression in a scheme of transmitting a total header at the beginning of transmission and omitting an unchanged portion except for a context ID and main information in the middle of transmission. In the case where the above RoHC scheme is applied to a broadcast system, a broadcast receiver may not be aware of receiving an IP stream and a general receiver, which does not know all header information, may not recognize a corresponding IP packet. Embodiments of the present invention may solve the above problems using signaling used in a broadcast system.

Embodiments of the present invention may provide an IP header compression method for supporting efficient transmission of IP packets in a next generation digital broadcasting system.

According to another embodiment of the present invention, the RoHC scheme may be applied to packets based on the FLUTE protocol. To apply the RoHC scheme to the FLUTE/ALC/LCT packet according to an embodiment of the present invention, the packet header may be classified into a static field, a dynamic field, and an inferable field. In a FLUTE/ALC/LCT packet according to an embodiment of the present invention, the static field may include an LCT version number (V), a congestion control flag (C), a delivery session identifier flag (S), a halfword flag (H), Congestion Control Information (CCI), a delivery session identification (TSI), and/or an expected residual transfer time (ERT). The LCT version number (V) may be a 4-bit field indicating the version number of the LCT protocol. This field may be fixed to 1. The congestion control flag (C) may be a 2-bit field indicating the size of congestion control. This field may have a size of 32, 64, 96, or 128 bits depending on the value. The transmission session identifier flag (S) may be a 1-bit field of a variable that may indicate the size of the TSI. This field may have a size of 32 × S +16 × H. The halfword flag (H) may be a 1-bit field, which may be a common variable indicating TSI and TOI. The Congestion Control Information (CCI) may have a size of 32, 64, 96, or 128 bits. This field may be a value used for congestion control packets in the session being transmitted by the receiver. This field may include the number of layers, the number of logical channels, and the sequence number. This field may be used to reference the throughput of the available bandwidth of the path between the transmitter and the receiver. The Transmission Session Identification (TSI) may have a size of 16, 32 or 48 bits. This field may indicate an identifier that identifies the session from a particular transmitter. The expected residual transfer time (ERT) is a 0 or 32-bit field indicating the time during which reception is valid. In the FLUTE/ALC/LCT packet according to an embodiment of the present invention, the dynamic field may include a transport object identifier flag (O), a closed session flag (a), a closed object flag (B), an LCT header length (HDR LEN), a Code Point (CP), a transmitter current time (SCT), and/or a Source Block Number (SBN). The transport object identifier flag (O) may be a 2-bit field, which may be a variable indicating the size of the TOI. This field may have a size of 32 x O +16 x H. The closed session flag (a) may be a 1-bit field. This field may be set to 0 in general. This field may be set to 1 when the transfer of the session packet is completed. The closed object flag (B) may be a 1-bit field. This field may be set to 0 in general. This field may be set to 1 when the transfer of the data (object) packet is completed. The LCT header length (HDR LEN) may be an 8-bit field. This field may express the header as a 32-bit LCT. A Code Point (CP) may be an 8-bit field indicating a data type. The Sender Current Time (SCT) may be a 0 or 32 bit field indicating the time during which the sender transmitted data to the receiver. The Source Block Number (SBN) may be a 32-bit field. This field may identify the source block of the encoding symbol in the payload being generated. In FLUTE/ALC/LCT packets according to embodiments of the present invention, the inferable fields may include a Transport Object Identification (TOI), FEC payload ID, Encoding Symbol ID (ESI), and/or encoding symbol. The Transport Object Identification (TOI) may be a field with 16, 32, 48, 64, 80, 96, or 112 bits indicating an identifier to identify data (objects) from a receiver. The length and format of the FEC payload ID may be set by the FEC encoding ID. This field may be included in the FEC building block. The encoding symbol id (esi) may be a 32-bit field that identifies a particular encoding symbol generated from a source block of the payload. The code symbols may be partitioned data that the receiver reforms into data and have a variable size based on the partitioned size.

As shown in this drawing, only a static field transmitted when included in an IR packet and a dynamic field transmitted when included in an IR-DYN packet may be transmitted when needed. Other packets may be transmitted in the form of header-compressed packets that include only 1 to 2 bytes of information.

According to embodiments of the present invention, it is possible to reduce the header of 30 bytes or more per packet by the above-described concept of RoHC packet flow. The header-compressed packet may be classified into type 0, type 1, and type 2 according to the form of the compressed header. The use of RoHC packets according to embodiments of the invention may follow conventional standard literature.

As shown in this figure, full context information may be included in the IR packet and updated context information may be included in the IR-DYN packet. In addition, the packet excluding header compression of the IR packet and the IR-DYN packet may not include context information.

According to embodiments of the invention, for a unidirectional transmission without a feedback channel, a receiver without IR information may not decode the RoHC stream until the next IR packet is received to configure the full context. That is, in this figure, in case that the receiver receives the RoHC stream from the portion indicated by being turned On (Turn On), the receiver may not decode the RoHC stream until the next IR packet is received. Embodiments of the present invention can transmit IR information through a separate signaling channel so that the above-described problems are solved.

According to embodiments of the present invention, RoHC configuration information, initial parameters, and/or IR packet information (full context information) may be needed in order to normally decode a transmitted RoHC packet.

According to an embodiment of the present invention, header-compressed packets compressed using an IP header compression scheme may be transmitted in-band, and IP packets including a static chain containing header information that is not changed and a dynamic chain for context update may be transmitted out-of-band, so that overhead of IP transmission is reduced and efficient transmission is achieved. At this time, the packets received through the receiver before transmission may be sequentially recovered.

According to embodiments of the invention, the IP may be configured to enter different Data Pipes (DPs). At this time, the header compression information may be transmitted to the receiver through the L2 signaling process, and the header compression information may be used to restore the IP stream, to which the IP header compression scheme is applied, received through the receiver to the original IP stream. The header compression information may be encapsulated and transmitted to the DP. At this time, the header compression information may be transferred to a normal DP or a DP for signaling transfer (basic DP) according to the structure of the physical layer. In addition, header compression may be transmitted through a separate signaling channel with support through the physical layer.

According to an embodiment of the present invention, the IP-DP mapping information may be transmitted to the receiver through the L2 signaling procedure, and the IP-DP mapping information may be used to restore an IP stream from a DP received through the receiver. The IP-DP mapping information may be encapsulated and transmitted to the DP. At this time, the IP-DP mapping information may be transferred to a normal DP or a DP for signaling transfer (basic DP) according to the structure of the physical layer. In addition, the IP-DP mapping information may be transmitted through a separate signaling channel in case of support through a physical layer.

As shown in this drawing, the IP stream multiplexed by the compressor can be divided into one or more IP streams by an IP filter L4010. Each IP flow may be compressed by the IP header compression scheme L4020 and may be transmitted to each DP by the encapsulation process L4030. At this time, the L2 signaling generator L4040 may generate signaling information including header compression information and/or IP-DP mapping information. The generated signaling information may be encapsulated and communicated to the decompressor over the base DP or may go through a signaling formatting process L4050 and communicated to the decompressor over a signaling channel L4060.

As illustrated in the present drawing, the DP received through the decompressor by the IP-DP mapping information parsed by the signaling parser L4070 may be restored to a corresponding IP stream. The IP flow that has undergone the decapsulation process L4080 before the IP header compression scheme is applied through the header compression information parsed by the L2 signaling parser L4090 may be restored to an IP flow.

According to an embodiment of the present invention, when an IP flow enters an overhead reduction procedure, the RoHC compressor L5010 may perform header compression for the corresponding flow. Embodiments of the present invention may use the RoHC method as a header compression algorithm. In the packet flow configuration procedure L5020, a packet flow that has undergone the RoHC procedure according to the form of the RoHC packet can be reconfigured. The reconfigured RoHC packet stream may be delivered to encapsulation layer L5040 and then transmitted to a receiver over a physical layer. The RoHC context information and/or signalling information generated in the reconfiguration packet stream can be made in transmittable form by a signalling generator L5030 and delivered to the encapsulation layer or signalling module L5050 in accordance with the transmitted form.

According to an embodiment of the present invention, a receiver may receive a stream of service data and signaling data for delivery through a signaling channel or a separate DP. The signaling parser L5060 may receive signaling data to parse the RoHC context information and/or signaling information and deliver the parsed information to the packet flow recovery process L5070. In the packet flow recovery procedure L5070, the receiver may recover the packet flow reconfigured by the compressor to a form in which the RoHC decompressor L5080 can decompress the packet flow using the RoHC context information and/or signaling information included in the signaling data. The RoHC decompressor L5080 can convert the recovered RoHC packet stream into an IP stream. The converted IP flow may be delivered to an upper layer through an IP layer.

The present invention may include three configuration modes.

According to the first configuration mode (configuration mode #1) L6010, which is an embodiment of the present invention, the first configuration mode may extract a static chain and a dynamic chain from an IP packet and convert the remaining part of the corresponding packet into a normal header-compressed packet. The first configuration mode may transmit conventional header compressed packets without any change.

According to the second configuration mode (configuration mode #2) L6020 which is another embodiment of the present invention, the second configuration mode can extract only static chains from an IP packet and convert the remaining part of the corresponding packet into a normal header-compressed packet. The second configuration mode may extract the dynamic chain from the IR-DYN packet and convert the remaining portion of the corresponding packet into a regular header compressed packet. The second configuration mode may transmit the normal header compressed packet without any change.

According to a third configuration mode (configuration mode #3) L6030 which is another embodiment of the present invention, the third configuration mode can extract a static chain from an IP packet and convert the remaining part of the corresponding packet into an IP-DYN packet. The third configuration mode may transmit IR-DYN packets without any change and regular header compressed packets without any change.

An IR packet L7010 according to embodiments of the present invention may include a packet type, a context ID, a profile, a CRC, a static chain, a dynamic chain, and/or a payload. The packet type may indicate the type of the corresponding IR packet. For example, in this figure, the packet type of the IR packet may indicate 1111110D, and the last D may indicate whether a dynamic chain is included in the corresponding packet. The context ID may use 8 bits or more. The context ID may identify a channel through which the corresponding packet is transmitted. The context ID may be named a Context Identifier (CID). When the compressor transmits a packet with an uncompressed full header while a specific CID is added and transmits subsequent packets while omitting header fields with static, dynamic, or inferred attributes having the same CID, the decompressor can recover all RTP packets by adding the omitted fields to a compressed header received after the second packet with reference to the initially stored header field information based on the CID. The profile may indicate a profile of the IR packet identified by the packet type. The CRC may indicate a CRC code for error checking. A static chain may indicate information that is hardly changed during a stream. For example, an IP version, an IP source address, an IP destination address, an IP fragmentation flag, a UDP source port, a UDP destination port, and the like may be included in the static chain during IP streaming. The dynamic chain may indicate information that is changed at any time but is maintained for a predetermined time. The payload may include data to be transmitted.

The conventional header compressed packet L7020 according to an embodiment of the present invention may include a Timestamp (TS), a Sequence Number (SN), a CRC, and/or a payload. A conventional header compressed packet according to an embodiment of the present invention may correspond to a UO-1 packet corresponding to packet type 1. A Time Stamp (TS) may indicate time stamp information for time synchronization. The Sequence Number (SN) may indicate information of a sequence of the packet. The CRC may indicate a CRC code for error checking. The payload may include data to be transmitted.

According to an embodiment of the present invention, the static and dynamic chains may be extracted from the IR packet L7010 and the extracted static and dynamic chains may be transmitted through the out-of-band L7030. The Time Stamp (TS) and the Sequence Number (SN) included in the conventional header-compressed packet L7020 using the information of the dynamic chain included in the IR packet L7010 may be re-encoded. Separately from the CRC included in the IR packet L7010, the CRC included in the conventional header compressed packet L7020 may be recalculated.

An IR-DYN packet L8020 according to embodiments of the present invention may include a packet type, a context ID, a profile, a CRC, a dynamic chain, and/or a payload. The packet type may indicate the type of the corresponding IR-DYN packet. For example, in the present figure, the packet type of the IR-DYN packet may indicate 11111000. The context ID may use 8 bits or more. The context ID may identify the channel through which the corresponding IR-DYN packet is transmitted. The profile may indicate a profile of the IR-DYN packet identified by the packet type. The CRC may indicate a CRC code for error checking. The dynamic chain may indicate information that is changed at any time but is maintained for a predetermined time. The payload may include data to be transmitted.

A conventional header compressed packet L8020 according to an embodiment of the present invention may include a Timestamp (TS), a Sequence Number (SN), a CRC, and/or a payload as previously described.

According to an embodiment of the present invention, the dynamic chain may be extracted from the IR-DYN packet L8010 and the extracted dynamic chain may be transferred through the out-of-band L8030. The Time Stamp (TS) and the Sequence Number (SN) included in the conventional header compressed packet L8020 can be re-encoded using the information of the dynamic chain included in the IR-DYN packet L8010. Separately from the CRC included in the IR-DYN packet L8010, the CRC included in the normal header compression packet L8020 may be recalculated.

The IR packet L9010 and the IR-DYN packet L9020 according to the embodiment of the present invention are previously described in detail.

According to an embodiment of the present invention, the packet type of the IR packet L9010 may become a packet type value corresponding to the IR-DYN packet L9020. The static chain may be extracted from the IR packet L9010 and may be transmitted through the out-of-band L9030. The remaining fields included in the IR packet L9010 excluding the packet type and static chain may be used identically in the IR-DYN packet L9020.

According to embodiments of the present invention, coding and calculation methods related to fields used in reconfiguring RoHC packets to configure a new packet stream may be applied following relevant standard literature or other methods.

A configuration procedure of a RoHC packet stream in a transmitter according to an embodiment of the present invention is as follows.

A transmitter according to an embodiment of the present invention can detect IR packets and IR-DYN packets from RoHC packet stream L10010 based on RoHC header information. Next, the transmitter may generate a normal header compressed packet using sequence numbers included in the IR packet and the IR-DYN packet. Since the conventional header-compressed packet includes Sequence Number (SN) information regardless of what type the conventional header-compressed packet has, the conventional header-compressed packet may be arbitrarily generated. The SN may correspond to information that occurs substantially in RTP. For UDP, the transmitter may arbitrarily generate and use a SN. Next, the transmitter may replace the corresponding IR or IR-DYN packet with the generated regular header compressed packet. The transmitter may extract the static chain and the dynamic chain from the IR packet and the dynamic chain from the IR-DYN packet. The extracted static and dynamic chains may be transmitted through out-of-band L10030. For all RoHC packet streams, the transmitter may replace the headers of the IR and IR-DYN packets with the headers of the regular header compressed packets and extract the static and/or dynamic chains by the same procedure as described above. The reconfigured packet stream L10020 may be transmitted through a data pipe and the extracted static and dynamic chains may be transmitted through the out-of-band L10030.

A recovery procedure of a RoHC packet stream in a receiver according to an embodiment of the present invention is as follows.

A receiver according to an embodiment of the present invention may select a data pipe of a stream to be received using signaling information. Next, the receiver may receive a packet stream (received packet stream, L10040) to be received, transmitted through the data pipe, and detect a static chain and a dynamic chain corresponding to the packet stream to be received. The static chains and/or the dynamic chains may be received out-of-band (out-of-band reception, L10050). Next, the receiver may detect a conventional header-compressed packet having the same SN as the above-described static chain or dynamic chain from a packet stream transmitted through the data pipe using the extracted SNs of the static chain and dynamic chain. Next, the receiver may combine the detected regular header compressed packets with the static chain and/or dynamic chain to configure the IR and/or IR-DYN packets. The configured IR and/or IR-DYN packets may be communicated to a RoHC decompressor. In addition, the receiver may configure a RoHC packet stream L10060 that includes IR packets, IR-DYN packets, and/or regular header compressed packets. The configured RoHC packet stream can be communicated to a RoHC decompressor. A receiver according to embodiments of the invention can use the static chains, dynamic chains, and SN and/or context IDs of IR packets and IR-DYN packets to recover the RoHC packet stream.

A transmitter according to an embodiment of the present invention can detect IR packets and IR-DYN packets from RoHC packet stream L11010 based on RoHC header information. Next, the transmitter may generate a normal header compressed packet using sequence numbers included in the IR packet and the IR-DYN packet. Since the conventional header-compressed packet includes Sequence Number (SN) information regardless of what type the conventional header-compressed packet has, the conventional header-compressed packet may be arbitrarily generated. The SN may correspond to information that occurs substantially in RTP. For UDP, the transmitter may arbitrarily generate and use a SN. Next, the transmitter may replace the corresponding IR or IR-DYN packet with the generated regular header compressed packet. The transmitter may extract the static chain and the dynamic chain from the IR packet and the dynamic chain from the IR-DYN packet. The extracted static and dynamic chains may be transmitted through out-of-band L11030. For all RoHC packet streams, the transmitter may replace the headers of the IR and IR-DYN packets with the headers of the regular header compressed packets and extract the static and/or dynamic chains by the same procedure as described above. The reconfigured packet stream L11020 may be transmitted through a data pipe and the extracted static and dynamic chains may be transmitted through an out-of-band L11030.

A receiver according to an embodiment of the present invention may select a data pipe of a stream to be received using signaling information. Next, the receiver may receive a packet stream (received packet stream, L11040) to be received, transmitted through the data pipe, and detect a static chain and a dynamic chain corresponding to the packet stream to be received. The static chain and/or the dynamic chain may be received out-of-band (out-of-band reception, L11050). Next, the receiver may detect a conventional header-compressed packet having the same SN as the above-described static chain or dynamic chain from a packet stream transmitted through the data pipe using the extracted SNs of the static chain and dynamic chain. Next, the receiver may combine the detected regular header compressed packets with the static chain and/or dynamic chain to configure the IR and/or IR-DYN packets. The configured IR and/or IR-DYN packets may be communicated to a RoHC decompressor. In addition, the receiver may configure a RoHC packet stream L11060 that includes IR packets, IR-DYN packets, and/or regular header compressed packets. The configured RoHC packet stream can be communicated to a RoHC decompressor. A receiver according to embodiments of the invention can use the static chains, dynamic chains, and SN and/or context IDs of IR packets and IR-DYN packets to recover the RoHC packet stream.

A transmitter according to an embodiment of the present invention can detect IR packets and IR-DYN packets from the RoHC packet stream L12010 based on RoHC header information. Next, the transmitter may extract the static chain from the IR packet and convert the IR packet into an IR-DYN packet using the remaining portion of the IR packet excluding the extracted static chain. For all RoHC packet streams, the transmitter may replace the header of the IR packet with the header of the IR-DYN packet and extract the static chain by the same procedure as described above. The reconfigured packet stream L12020 may be transmitted through a data pipe and the extracted static chain may be transmitted through the out-of-band L12030.

A receiver according to an embodiment of the present invention may select a data pipe of a stream to be received using signaling information. Next, the receiver may receive a packet stream (received packet stream, L12040) to be received, transmitted through the data pipe, and detect a static chain corresponding to the packet stream to be received. The static chain may be received out-of-band (out-of-band reception, L12050). Next, the receiver may detect IR-DYN packets from the stream of packets transmitted through the data pipe. Next, the receiver may combine the detected IR-DYN packet with the static chain sum to configure the IR packet. The configured IR packets may be transmitted to a RoHC decompressor. In addition, the receiver may configure a RoHC packet stream L12060 that includes IR packets, IR-DYN packets, and/or regular header compressed packets. The configured RoHC packet stream can be communicated to a RoHC decompressor. A receiver according to embodiments of the invention can use the static chain and SN and/or context ID of the IR-DYN packet to recover the RoHC packet stream.

According to an embodiment of the present invention, a method of delivering static chains and/or dynamic chains extracted during configuration of a RoHC packet flow out-of-band may basically comprise: a delivery method through signaling and a delivery method through a data pipe, by which parameters necessary for system decoding are delivered. According to an embodiment of the present invention, the data pipe through which parameters necessary for system decoding are delivered may be named a basic Data Pipe (DP).

As illustrated in the present drawing, a static chain and/or a dynamic chain may be delivered by signaling or basic DP. According to the embodiment of the present invention, the first transfer mode (transfer mode #1) to the third transfer mode (transfer mode #3) may be used in the first configuration mode (configuration mode #1) or the second configuration mode (configuration mode #2), and the fourth transfer mode (transfer mode #4) and the fifth transfer mode (transfer mode #5) may be used in the third configuration mode (configuration mode # 3).

According to the embodiments of the present invention, the respective configuration modes and transmission modes can be switched and used by separate signaling based on the situation of the system, and only one configuration mode and one transmission mode can be fixed and used according to the design process of the system.

As shown in the present drawing, in the first transfer mode (transfer mode #1), a static chain may be transferred through signaling, a dynamic chain may be transferred through signaling, and a normal header-compressed packet may be transferred through a normal data pipe.

As illustrated in the present drawing, in the second transfer mode (transfer mode #2), the static chain may be transferred through signaling, the dynamic chain may be transferred through the basic data pipe, and the normal header-compressed packet may be transferred through the normal data pipe.

As illustrated in the present drawing, in the third transfer mode (transfer mode #3), the static chain may be transferred through the elementary data pipe, the dynamic chain may be transferred through the elementary data pipe, and the normal header-compressed packet may be delivered through the normal data pipe.

As illustrated in the present drawing, in the fourth transfer mode (transfer mode #4), the static chain may be transferred through signaling, the dynamic chain may be transferred through the basic data pipe, and the normal header-compressed packet may be transferred through the normal data pipe. At this time, the dynamic chain may be transmitted through an IR-DYN packet.

As illustrated in the present drawing, in the fifth transfer mode (transfer mode #5), the static chain may be transferred through the basic data pipe, the dynamic chain may be transferred through the normal data pipe, and the normal header-compressed packet may be transferred through the normal data pipe. At this time, the dynamic chain may be transmitted through an IR-DYN packet.

Fig. 43 is a view showing a configuration of a descriptor including a static chain according to an embodiment of the present invention.

According to embodiments of the present invention, a transport format for transmission through signaling may be required to transmit a static chain through descriptor form in corresponding signaling.

A descriptor including a static chain according to an embodiment of the present invention may include a descriptor _ tag field, a descriptor _ length field, a context _ id field, a context _ profile field, a static _ chain _ length field, and/or a static _ chain () field.

The descriptor _ tag field may indicate that this descriptor is a descriptor including a static chain.

The descriptor _ length field may indicate the length of this descriptor.

The context _ ID field may indicate a context ID for the corresponding RoHC packet stream. The length of the context ID may be decided during initial configuration of the system. This field may be named context identifier information and identifies the corresponding RoHC packet flow based on a static field or a dynamic field.

The context _ profile field may indicate compression protocol information of the corresponding RoHC packet stream. That is, this field can indicate a protocol in which headers of RoHC packets included in the corresponding RoHC packet stream have been compressed.

The static _ chain _ length field may indicate the length of the following static chain () in bytes. In the case where this descriptor includes only one static chain, this field may be replaced by the above-described descriptor _ length field.

The static _ chain () field may indicate information for a static chain.

According to embodiments of the present invention, a transport format for signaling may be required to allow a dynamic chain to be signaled correspondingly in a descriptor form.

A descriptor including a dynamic chain according to an embodiment of the present invention may include a descriptor _ tag field, a descriptor _ length field, a context _ id field, a context _ profile field, a dynamic _ chain _ length field, and/or a dynamic _ chain () field.

The descriptor _ tag field may indicate that this descriptor may include a descriptor of a dynamic chain.

The descriptor _ length field may indicate the length of this descriptor.

The context _ ID field may indicate a context ID for the corresponding RoHC packet stream. The length of the context ID may be decided during initial configuration of the system.

The context _ profile field may indicate compression protocol information of the corresponding RoHC packet stream.

The static _ chain _ length field may indicate the length of the following dynamic chain () in bytes. In the case where this descriptor includes only one dynamic chain, this field may be replaced by the above-described descriptor _ length field.

The dynamic _ chain () field may indicate information for a dynamic chain.

Fig. 45 is a view showing a configuration of a packet including a packet format of a static chain and a packet including a packet format of a dynamic chain according to an embodiment of the present invention.

According to an embodiment of the present invention, a transmission format for transmission in the form of a packet may be required to transmit a static chain and/or a dynamic chain in a corresponding basic DP by the packet format shown in the present drawing.

In order to configure a static chain and/or a dynamic chain according to an embodiment of the present invention in a packet format, a header for notification of information on the corresponding static chain and/or dynamic chain may be added. The added header may include a packet type field, a static/dynamic link indicator field, and a payload length field. In the case where a packet according to an embodiment of the present invention has a structure in which it is difficult to indicate a static chain and/or a dynamic chain in detail, information including the above-described descriptor of the static chain or the dynamic chain may be included in the payload of this packet.

A packet format including a static chain according to an embodiment of the present invention may include a packet type field, a static chain indicator field, a payload length field, and/or a static chain byte field.

The packet type field may indicate type information of this packet.

The static chain indicator field may indicate whether information constituting the payload is a static chain or a dynamic chain.

The payload length field may indicate the length of the payload including the static chain.

The static chain byte field may indicate information of the static chain included in the payload of this packet.

A packet format including a dynamic chain according to an embodiment of the present invention may include a packet type field, a dynamic chain indicator field, a payload length field, and/or a dynamic chain byte field.

The packet type field may indicate type information of this packet.

The dynamic chain indicator field may indicate whether information constituting the payload is a static chain or a dynamic chain.

The payload length field may indicate the length of the payload including the dynamic chain.

The dynamic chain byte field may indicate information of the dynamic chain included in the payload of this packet.

The broadcast signal transmitting method according to the embodiment of the present invention may be performed in the following order. First, the compressor may compress headers of IP packets included in the IP packet stream to generate a RoHC packet stream (SL 17010). Next, the compressor may extract a first portion of RoHC packets included in the generated RoHC packet stream (SL 17020). The first part described above may indicate the static fields and/or the dynamic fields of the RoHC packet previously described in detail with reference to fig. 35, 39, 40 and 41, according to an embodiment of the present invention. Next, the compressor may convert the second portion of the RoHC packet into another type of RoHC packet (SL 17030). The second portion may mean the remaining portion of the RoHC packet excluding the extracted first portion. According to an embodiment of the present invention, RoHC packets can be divided into three types, which will be described below. The another type of RoHC packet described above may mean a RoHC packet having one of the three types described in detail previously with reference to fig. 36, 37, and 38. Next, the compressor may reconfigure a new packet stream including the converted another type of RoHC packets described in detail previously with reference to fig. 39, 40, and 41 (SL 17040). Next, the compressor may transmit the reconfigured packet stream through the first channel and the above-described first part (SL17050) through the second channel, which was previously described in detail with reference to fig. 42 to 45.

According to another embodiment of the present invention, the RoHC packet described above may correspond to any one selected from among: a first packet including first header information and a payload that are changed every time the packet is changed during streaming; a second packet including second header information, the first header information, and a payload that are changed at a predetermined interval as the packet is changed; and a third packet including third header information that is not changed although the packet is changed during streaming, the first header information, and the payload. The first header information may mean the remaining portion of all headers of the RoHC packet excluding the static field and the dynamic field. Thus, the first packet comprising the first header information and the payload may indicate a conventional header compressed packet. The second header information may mean a dynamic field. Thus, the second packet including the second header information, the first header information, and the payload may indicate an IR-DYN packet. The third header information may mean a static field. Accordingly, the third packet including the third header information, the first header information, and the payload may indicate an IR packet. According to embodiments of the present invention, an IR packet may or may not include a dynamic field. According to embodiments of the present invention, the static field may be named a static chain and the dynamic chain may be named a dynamic chain, as previously described in detail with reference to fig. 30-32.

According to another embodiment of the present invention, the third packet may further include second header information, and the compressor may extract the second header information and the third header information from the third packet included in the generated RoHC packet stream and extract the second header information from the second packet included in the generated RoHC packet stream at the above-described extracting step. In addition, in the above-described conversion step, the compressor may convert the remaining part of the third packet excluding the extracted second header information and third header information into the first packet and convert the remaining part of the second packet excluding the extracted second header information into the first packet, which was previously described in detail with reference to fig. 36 and 39.

According to another embodiment of the present invention, the third packet may further include second header information, and the compressor may extract the third header information from the third packet included in the generated RoHC packet stream in the above-described extracting step. In addition, at the above-described converting step, the compressor may convert the remaining part of the third packet excluding the extracted third header information into the second packet, which was previously described in detail with reference to fig. 38 and 41.

According to another embodiment of the present invention, at the above-described extracting step, the compressor may extract third header information from a third packet included in the generated RoHC packet stream, and extract second header information from a second packet included in the generated RoHC packet stream. In addition, in the above-described conversion step, the compressor may convert the remaining part of the third packet excluding the extracted third header information into the first packet and convert the remaining part of the second packet excluding the extracted second header information into the first packet, which was previously described in detail with reference to fig. 37 and 40.

According to another embodiment of the present invention, the second channel may include a signaling channel for transmitting signaling information and a system channel for transmitting information necessary for system decoding. The second header information and/or the third header information according to an embodiment of the present invention may be transmitted through a signaling channel or a system channel. According to an embodiment of the present invention, the above signaling channel may indicate an out-of-band channel, which may be a channel for transmitting signaling information, and the system channel may indicate an out-of-band channel, which may be a basic data channel, as previously described in detail with reference to fig. 42.

According to another embodiment of the present invention, in case that the above-mentioned second header information or third header information is transmitted through a signaling channel, the second header information or third header information may be transmitted while being included in the sub-element. The subelement according to an embodiment of the present invention can include context identifier information and context profile information for identifying a corresponding RoHC packet flow based on the second header information or the third header information described above, the context profile information indicating according to which protocol headers of RoHC packets included in the corresponding RoHC packet flow based on the second header information or the third header information have been compressed. The sub-element according to an embodiment of the present invention may indicate a descriptor, which was previously described in detail with reference to fig. 43.

According to still another embodiment of the present invention, in the case where the above-described second header information or third header information is transmitted through a system channel, the second header information or third header information may be transmitted while being included in a payload of a packet. The packet according to an embodiment of the present invention may include packet type information indicating type information of the packet, indicator information indicating whether information included in the payload is second header information or third header information, and/or length information indicating a length of the payload, which was previously described in detail with reference to fig. 45.

The broadcast signal receiving method according to the embodiment of the present invention may be performed in the following order. First, the decompressor may receive a reconfigured packet stream through a first channel (SL 18010). The reconfigured packet flow according to an embodiment of the present invention may indicate a new packet flow obtained by extracting a first part of RoHC packets included in the RoHC packet flow, converting a second part of the RoHC packets into another type of RoHC packets, and reconfiguring the new packet flow including the converted another type of RoHC packets. Next, the decompressor may receive the extracted first part through the second channel (SL18020) described in detail previously with reference to fig. 35 to 41. Next, the decompressor may restore the received reconfigured packet stream to the original RoHC packet stream using the received first portion described in detail previously with reference to fig. 39-41 (SL 18030). Next, the decompressor may decompress the headers of the RoHC packets included in the recovered RoHC packet stream to generate an IP packet stream (SL18040), described in detail previously with reference to fig. 34. Next, the decompressor may process the generated IP packet stream to acquire broadcast data (SL 18050).

According to another embodiment of the present invention, the third packet may further include second header information, and in the above-described restoring step, in a case where the received second header information and third header information have the same sequence number while being included in the above-described first portion, the decompressor may detect a first packet having the same sequence number as the second header information and third header information from among packets included in the received reconfigured packet stream, and combine the second header information and third header information with the detected first packet to restore the third packet. On the other hand, in the case where the received second header information and third header information have different sequence numbers while being included in the above-described first portion, the decompressor may detect a first packet having the same sequence number as the second header information from among packets included in the received configured packet stream, and combine the second header information and the detected first packet to recover the second packet. Through this procedure, the decompressor can restore the received reconfigured packet stream to the original RoHC packet stream, as previously described in detail with reference to fig. 36 and 39.

According to another embodiment of the present invention, the third packet may further include second header information, and in the recovering step described above, the decompressor may detect a second packet having the same sequence number as the third header information received while being included in the first portion from the reconfigured packet stream received, and combine the received header information and the detected second packet to recover the third packet. Through this procedure, the decompressor can restore the received reconfigured packet stream to the original RoHC packet stream, which was previously described in detail with reference to fig. 38 and 41.

According to another embodiment of the present invention, at the above-described recovering step, the decompressor may detect, from the packets included in the received reconfigured packet stream, a first packet having the same sequence number as the third header information received while being included in the first section, and combine the received third header information and the detected first packet to recover the third packet. In addition, the decompressor may detect a first packet having the same sequence number as second header information received while being included in the first portion from a packet included in the received reconfigured packet stream, and combine the received second header information and the detected first packet to recover the second packet. Through this procedure, the decompressor can restore the received reconfigured packet stream to the original RoHC packet stream, which was previously described with reference to fig. 37 and 40.

The broadcast signal transmitting apparatus L19060 according to an embodiment of the present invention may include a RoHC compressor L19010, an extraction unit L19020, a conversion unit L19030, a reconfiguration unit L19040, and/or a transmission unit L19050.

The RoHC compressor L19010 can extract a first portion of RoHC packets included in the generated RoHC packet stream.

The extraction unit L19020 may extract a first part of the RoHC packets included in the generated RoHC packet stream.

The conversion unit L19030 can convert the second portion of the RoHC packet into another type of RoHC packet.

The reconfiguration unit L19040 can reconfigure a new packet stream including the converted another type of RoHC packet.

The transmitting unit L19050 may transmit the reconfigured packet stream through the first channel and the first portion through the second channel.

The components of the broadcast signal transmitting apparatus L19060 according to the embodiment of the present invention are previously described in detail with reference to fig. 34 and 46.

The broadcast signal receiving apparatus L20060 according to an embodiment of the present invention may include a first receiving unit L20010, a second receiving unit L20020, a recovery unit L20030, a RoHC decompressor L20040, and/or an IP packet processing unit L20050.

The first receiving unit L20010 may receive the reconfigured packet stream through the first channel. The reconfigured packet flow may be a new packet flow obtained by extracting a first portion of the RoHC packets included in the RoHC packet flow, converting a second portion of the RoHC packets into RoHC packets of another type, and reconfiguring the new packet flow including the converted RoHC packets of the another type.

The second receiving unit L20020 may receive the extracted first part through the second channel.

The recovery unit L20030 can use the received first part to recover the received reconfigured packet stream to the original RoHC packet stream.

The RoHC decompressor L20040 can decompress the headers of the RoHC packets included in the recovered RoHC packet stream to generate an IP packet stream.

The IP packet processing unit L20050 can process the generated IP packet stream to acquire broadcast data.

The components of the broadcast receiving signal receiving apparatus L20060 according to the embodiment of the present invention are previously described in detail with reference to fig. 34 and 37.

The above-described steps can be omitted or replaced by steps performing similar or identical functions according to design.

Although the description of the present invention is explained with reference to each drawing for the sake of clarity, a new embodiment can be designed by combining the embodiments shown in the drawings with each other. Also, if a computer-readable recording medium recording a program for executing the embodiments mentioned in the foregoing description is designed by those skilled in the art as necessary, it may be within the scope of the appended claims and their equivalents.

The apparatus and method according to the present invention may not be limited to the configurations and methods of the embodiments mentioned in the foregoing description. Also, the embodiments mentioned in the foregoing description can be configured in such a manner as to be selectively combined with each other in whole or in part so that various modifications can be made to the embodiments.

In addition, the method according to the present invention can be implemented using processor-readable code in a processor-readable recording medium configured to the network device. The processor-readable medium may include all kinds of recording devices capable of storing processor-readable data. The processor-readable medium may include one of ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc., and may also include implementations of carrier wave types such as transmission via the internet. Further, when the recording medium readable by the processor is distributed to computer systems connected through a network, the processor readable code may be stored or executed according to the distributed system.

It will be understood by those skilled in the art that various modifications and changes may be made in the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Both device and method inventions are referred to in this specification and the descriptions of both device and method inventions may be complementarily applied to each other.

Modes for carrying out the invention

Various embodiments have been described in terms of the best mode for carrying out the invention.

Industrial applicability

The present invention is useful in a range of broadcast signal providing fields.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims

1. A broadcast signal transmitting method, comprising:

compressing headers of IP packets included in an Internet protocol IP packet stream to generate an initialization refresh IR packet, an IR dynamic IR-DYN packet, and a compressed packet,

wherein the IR packet includes static chain information and dynamic chain information, and the IR-DYN packet includes dynamic chain information;

processing the IR packet, the IR-DYN packet, and the compressed packet, the processing performing a first processing in a first mode or a second processing in a second mode,

wherein the first processing includes:

extracting context information from the IR packet and the IR-DYN packet, wherein the extracted context information includes the static chain information and the dynamic chain information in the IR packet and the dynamic chain information in the IR-DYN packet; and

converting the IR packet and the IR-DYN packet into compressed packets,

wherein the second processing comprises:

extracting context information from the IR packet, wherein the extracted context information includes the static chain information in the IR packet, and

converting the IR packet into an IR-DYN packet:

generating signaling data comprising mode information and the context information, wherein the mode information is to indicate the first mode or the second mode; and

transmitting a broadcast signal including the signaling data and the service data,

wherein the service data includes the compressed packet and the converted compressed packet generated in the first mode, and

wherein the service data includes the IR-DYN packet generated in the second mode, the converted IR-DYN packet, and the generated compressed packet.

2. The method of claim 1, wherein the broadcast signal comprises a plurality of data pipes, wherein one of the plurality of data pipes carries signaling data comprising the mode information and the context information, and wherein a remaining portion of the plurality of data pipes carries the service data.

3. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,

wherein the signaling data further comprises information for identifying the context and information for identifying a range of protocols used to compress the IP packet flow.

4. A broadcast signal receiving method, comprising:

receiving a broadcast signal including signaling data and service data, wherein the signaling data includes mode information and context information;

processing the signaling data and the service data, wherein the processing performs a first process in response to mode information indicating a first mode or performs a second process in response to mode information indicating a second mode,

wherein the first processing includes:

acquiring the context information from the signaling data, wherein the received service data comprises a plurality of compressed packets, and the acquired context information comprises static chain information and dynamic chain information for restoring an IR packet, and dynamic chain information for restoring an IR-DYN packet; and

recovering the IR packet based on the obtained static chain information and dynamic chain information and a compressed packet of the plurality of compressed packets, and recovering the IR-DYN packet based on the obtained dynamic chain information and a compressed packet of the plurality of compressed packets; and

wherein the second processing comprises:

obtaining the context information from the signaling data, wherein the received service data comprises a plurality of IR-DYN packets and compressed packets, and the obtained context information comprises static chain information for recovering the IR packets, an

Retrieving the IR packet based on the obtained static chain information and an IR-DYN packet of the plurality of IR-DYN packets; and

the processed service data is decompressed to generate an IP packet stream comprising IP packets.

5. The method of claim 4, wherein the broadcast signal comprises a plurality of data pipes, wherein one of the plurality of data pipes carries signaling data comprising the mode information and the context information, and wherein a remaining portion of the plurality of data pipes carries the service data.

6. The method of claim 4, wherein the first and second light sources are selected from the group consisting of,

wherein the signaling data further comprises information identifying the context and information identifying a range of protocols used to compress the IP packet flow.

7. The method of claim 4, further comprising:

the generated IP packet stream is processed to acquire broadcast data.

8. A broadcast signal transmitting apparatus comprising:

a RoHC compressor to compress headers of IP packets included in an IP packet stream to generate an IR packet, an IR-DYN packet, and a compressed packet, wherein the IR packet includes static chain information and dynamic chain information, and the IR-DYN packet includes dynamic chain information;

a processor for processing the IR packet, the IR-DYN packet, and the compressed packet, wherein the processor performs a first process in a first mode or a second process in a second mode,

wherein the first processing is to:

extracting context information from the IR packet and the IR-DYN packet, wherein the extracted context information includes static chain information and dynamic chain information in the IR packet and dynamic chain information in the IR-DYN packet; and

converting the IR packet and the IR-DYN packet into compressed packets,

wherein the second processing is to:

extracting context information from the IR packet, wherein the extracted context information comprises static chain information in the IR packet, an

Converting the IR packet into an IR-DYN packet:

a signaling packet generator for generating signaling data containing mode information and the context information, wherein the mode information is to indicate the first mode or the second mode; and

a transmitting unit for transmitting a broadcast signal including signaling data and service data,

9. The device of claim 8, wherein the broadcast signal comprises a plurality of data pipes, wherein one of the plurality of data pipes carries signaling data comprising the mode information and the context information, and wherein a remaining portion of the plurality of data pipes carries the service data.

10. The apparatus as set forth in claim 8, wherein,

11. A broadcast signal receiving apparatus comprising:

a tuner receiving a broadcast signal including signaling data and service data, wherein the signaling data includes mode information and context information;

a first processor that processes the signaling data and the service data, wherein the first processor performs a first process in response to mode information indicating a first mode or performs a second process in response to mode information indicating a second mode,

wherein the first processing is to:

wherein the second processing is to:

obtaining the context information from the signaling data, wherein the received service data comprises a plurality of IR-DYN packets and compressed packets, and the obtained context information comprises static chain information for recovering IR packets, an

a decompressor that decompresses the processed service data to generate an IP packet stream comprising IP packets.

12. The device of claim 11, wherein the broadcast signal comprises a plurality of data pipes, wherein one of the plurality of data pipes carries signaling data including the mode information and the context information, and wherein a remaining portion of the plurality of data pipes carries the service data.

13. The apparatus of claim 11, wherein the signaling data further comprises information identifying the context and information identifying a range of protocols used to compress the IP packet stream.

14. The apparatus of claim 11, further comprising:

a second processor that processes the generated IP packet stream to obtain broadcast data.